• Vui lòng đọc nội qui diễn đàn để tránh bị xóa bài viết
  • Tìm kiếm trước khi đặt câu hỏi

Tiêu chí nào để đánh giá chất lượng một phần mềm

Nơi trao đổi, hỏi đáp về hướng đối tượng (OOP - Object-Oriented Programming), không giới hạn về ngôn ngữ lập trình
HaiPT
VIP
VIP
Bài viết: 252
Ngày tham gia: T.Tư 07/09/2005 4:02 pm
Đến từ: Hải Phòng
Has thanked: 1 time
Been thanked: 12 time
Liên hệ:

Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi HaiPT » T.Ba 17/01/2012 3:32 pm

Như tiêu đề, mời các bạn...thảo luận


Phạm Hải
Quản trị dự án ,Chuyên gia đào tạo
Đại học FPT

Hình đại diện của người dùng
xuanquy_th
Guru
Guru
Bài viết: 792
Ngày tham gia: T.Ba 05/08/2008 9:15 pm
Đến từ: Thanh Hoá
Has thanked: 1 time
Been thanked: 10 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi xuanquy_th » T.Ba 17/01/2012 6:17 pm

Theo tôi thì vấn đề này sẽ được khẳng định từ những người trực tiếp sử dụng.
Khi Chúa Trời đóng cánh cửa này lại, Ngài sẽ mở một cánh cửa khác cho ta.
Nhưng ta thường nhìn quá lâu vào cánh cửa đã đóng nên không thấy được có một cánh cửa khác đang mở ra cho ta!!!

HaiPT
VIP
VIP
Bài viết: 252
Ngày tham gia: T.Tư 07/09/2005 4:02 pm
Đến từ: Hải Phòng
Has thanked: 1 time
Been thanked: 12 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi HaiPT » T.Ba 17/01/2012 7:08 pm

Có thể chủ đề còn hơi rộng, mình thu gọn lại như sau :)
Làm phần mềm cũng như xây một cái nhà, cần có thiết kế tốt..
Thiết kế tốt ở đây là gì , ở mức độ cao nhất, kiến trúc phần mềm sẽ phải mô tả hình dạng của phần mềm đó, ở tầng thứ hai chúng ta quan tâm tới business domain của nó , và tầng thứ ba là các component, pakage cấu thành nên cái phần mềm đó! Đấy là cái mình muốn thảo luận!
Cụ thể : Các tiêu chỉ nào để đánh giá chất lượng của source code của một application là tốt ?
Phạm Hải
Quản trị dự án ,Chuyên gia đào tạo
Đại học FPT

HaiPT
VIP
VIP
Bài viết: 252
Ngày tham gia: T.Tư 07/09/2005 4:02 pm
Đến từ: Hải Phòng
Has thanked: 1 time
Been thanked: 12 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi HaiPT » T.Ba 31/01/2012 9:59 am

MOD move lại này vào box OOP nhé!
Phạm Hải
Quản trị dự án ,Chuyên gia đào tạo
Đại học FPT

HaiPT
VIP
VIP
Bài viết: 252
Ngày tham gia: T.Tư 07/09/2005 4:02 pm
Đến từ: Hải Phòng
Has thanked: 1 time
Been thanked: 12 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi HaiPT » T.Tư 22/02/2012 7:29 pm

Trả lời :
Có hai tiêu chí để đánh giá chất lượng của một phần mêm, đây là hai tiêu chí đã được áp dụng cho lập trình hướng thủ tục nhưng vẫn còn dùng tốt với lập trình hướng đối tượng ( có một số mở rông) .
Hai tiêu chí đó là :
- Kết dính ( sự liên kết để cùng focus đến mục đích trung tâm của các dòng code , data trong module )
- Ghép cặp ( độ phụ thuộc lẫn nhau giữa các module )
Mong rằng qua bài viết sẽ giúp các bạn trả lời hiểu được các vấn đề:
- Tìm hiểu các nguyên lý coding, design partern ở mức cơ bản nhất
- Tại sao lại cần các mô hình trong SE ( eg : MVC, MVVM, MVP, 3 layer ?)
- Và thế giới rộng lớn của kỹ thuật kiểm thử chương trình !
Tất cả đều base trên hai khái niệm trên !
(... còn tiếp ... )
Phạm Hải
Quản trị dự án ,Chuyên gia đào tạo
Đại học FPT

Hình đại diện của người dùng
Kỳ Nam
Guru
Guru
Bài viết: 510
Ngày tham gia: CN 12/08/2007 8:47 pm
Đến từ: Qui Nhơn
Been thanked: 1 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi Kỳ Nam » T.Sáu 24/02/2012 9:59 pm

với em code chất lượng tốt thì cần: đơn giản, khả năng mở rộng, khả năng xách qua platform / môi trường khác, hiệu quả

để có được đơn giản, mở rộng, portable

+ giữa các class, file ít có sự phụ thuộc lẫn nhau, những trường hợp phụ thuộc qua lại ( 2 chiều ) là cần tránh liền ko để dây dưa ngày càng nặng hơn

+ tách biệt giữa các nhiệm vụ: model, logic, giao diện, ...

để đạt được mấy cái đó thì đầu tiên cần nhận thức trong đầu, sau đó áp dùng mấy pattern (nếu hiệu quả) vd event driven, inversion of control, mvvm, ...

hồi đi làm em thấy nhiều người cứ mở mồm ra là MVC , 3 layer... nghe kinh hồn lắm, nhưng rất ít ai biết mục đích của nó là gì, cuối cùng chỉ biết áp dụng máy móc, bằng cách đặt tên, phân chia thư mục, assembly..., còn code thì là 1 rừng các mối quan hệ chằn chịt tùy vào khối lượng công việc

tóm lại, để viết được code có chất lượng thì khó, nhưng để biết chất lượng code thì rất dễ, chỉ cần kiểm tra sự phức tạp của code, thể hiện ở sự phụ thuộc giữa các thành phần của code. nhiều phần mềm phục vụ việc này, như nDepend cho .NET

HaiPT
VIP
VIP
Bài viết: 252
Ngày tham gia: T.Tư 07/09/2005 4:02 pm
Đến từ: Hải Phòng
Has thanked: 1 time
Been thanked: 12 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi HaiPT » T.Sáu 24/02/2012 11:14 pm

Yes, ý của Kỳ Nam đều là 2 đặc tính anh nêu ở trên , tuy nhiên cần định nghĩa một cách cụ thể để lính mới còn học bài bản thôi , vì có thể nhiều người hiểu và đã áp dụng nhưng chưa thể gọi tên cụ thể là gì !
Ví dụ Kỳ Nam đã viết :
"+ giữa các class, file ít có sự phụ thuộc lẫn nhau, những trường hợp phụ thuộc qua lại ( 2 chiều ) là cần tránh liền ko để dây dưa ngày càng nặng hơn"

==> Đây chính là sự "Ghép cặp" , tuy nhiên phần tiếp anh sẽ nói chi tiết hơn, ghép cặp có bao nhiêu loại, cụ thể và cách áp dụng

+ tách biệt giữa các nhiệm vụ: model, logic, giao diện, ...

==> Đây là định nghĩa " kết dính" , các phần trong module ( data, code ) phải hướng về mục đích chung tâm, ví dụ: không nên cho 1 module thực hiện 2 nghiệm vụ , hoặc trong DAL mà lẳng thêm logic chẹking rule vào thì bất hợp lý, kết dính cũng có một số level cần mô tả kỹ !
Các mô hình, patern , refactoring... tất tần tật đều base trên các nguyên lý cơ bản này !
Phạm Hải
Quản trị dự án ,Chuyên gia đào tạo
Đại học FPT

HaiPT
VIP
VIP
Bài viết: 252
Ngày tham gia: T.Tư 07/09/2005 4:02 pm
Đến từ: Hải Phòng
Has thanked: 1 time
Been thanked: 12 time
Liên hệ:

Re: Tiêu chí nào để đánh giá chất lượng một phần mềm

Gửi bàigửi bởi HaiPT » T.Bảy 03/03/2012 10:15 am

Về cơ bản kiến trúc phần mềm ở level cao nhất nó mô tả hình dạng và cấu trúc phần mềm , ở level thứ hai nó mô tả mục đích sử dụng của phần mềm và ở level thứ ba thì nó mô tả kiến trúc của các module , pakage, component, class, patern.... Hầu hết các tài liệu thiết kế đều phải mô tả được các level trên của một phần mềm bằng cách dùng các UML diagram ! Tuy nhiên ở trong bài viết này tôi chủ yếu nói về tầng thứ 3 của KTPM và cách đánh giá chi tiết dưới góc nhìn của một developer , not solution architect !
Hai tiêu chí được dùng để đánh giá chất lượng phần mềm đã được áp dụng từ thời lập trình hướng thủ tục nhưng vẫn còn dùng tốt cho OOP đó là : độ kết dính và ghép cặp!
- Kết dính :
Là sự liên kết để của các item trong module để cùng focus đến mục đích trung tâm, các item bao gồm : các dòng code , data trong module, các lênh call đển method khác ..etc
- Ghép cặp ( độ phụ thuộc lẫn nhau giữa các module )
Nguyên tắc số một của một kiến trúc phần mềm tốt là tằng độ kết dính và giảm độ ghép cặp ! Tất cả cả nguyên lý Refactoring, Design đều base trên nguyên tắc này !
I. Độ kết dính ( Cohension )
Có nhiều mức độ kết dính :
Kết dính ngẫu nhiên – coincidental cohesion
Kết dính logic – logical cohesion
Kết dính thời gian – temporal cohesion
Kết dính quy trình – procedural cohesion
Kết dính tuần tự – sequential cohesion
Kết dính thông tin – communication cohesion
Kết dính chức năng – functional cohesion
COHENSION.jpg

( còn tiếp )
Phạm Hải
Quản trị dự án ,Chuyên gia đào tạo
Đại học FPT


Quay về “Lập trình hướng đối tượng (OOP)”

Đang trực tuyến

Đang xem chuyên mục này: Bing [Bot]1 khách