Chất lượng các các phần mềm được đánh giá dựa trên những chỉ tiêu hay tiêu chí nào?
Chỉ một câu hỏi đơn giản nhưng lại có rất nhiều những định nghĩa khác nhau. Đó chính là bởi vì đối với mỗi người, họ lại có những quan điểm riêng để đánh giá một phần mềm thế nào là có ích với họ, từ đó sinh ra các tiêu chí riêng về chất lượng phần mềm. Đây cũng chính là câu hỏi dành cho các lập trình viên mỗi khi bắt đầu một dự án mới: phần mềm mà họ tạo ra sẽ sinh ra giá trị đối với ai, và đối với họ thì giá trị là thế nào? Đối với lập trình viên, chất lượng source code là quan trọng, còn đối với end-user thì chất lượng của application là quan trọng.
Mục đích của phần mềm sẽ qui định ra thước đo chất lượng phần mềm đó.
I.Khái niệm
1. Chất lượng phần mềm:
⧭Chất lượng sản phẩm:Khả năng phù hợp với requirement specification(những yêu cầu về thông số kĩ thuật) và program specification (liên quan đến độ tin cậy của phần mềm)
⧭Khả năng mở rộng (scalability) là một loại mở rộng nằm trong extensibility, đối với một phần mềm thì scalability của phần mềm đó thể hiện khả năng có thể đáp ứng của phần mềm khi áp dụng vào các hệ thống,máy móc từ nhỏ đến lớn.
⧭Tính chính xác(correctness) thể hiện sự chính xác khi algorithm đối chiếu với specification. Chằng hạn khi nói đến tính chính xác của function là muốn nói đến tính chính xác liên quan đến input và output của algorithm (có nghĩa là: đối với mỗi một input thì phải có một output chính xác).
⧭Tính bảo toàn (data integrity) thể hiện sự bảo đảm các dữ liệu không xảy ra trường hợp thiếu sót. Điều này có nghĩa là khi thực hiện một loạt các thao tác như chuyển tiếp(transmission), lưu trữ(storage), tìm kiếm (search), data sẽ được tập hợp lại và phải duy trì được chất lượng của data như đã kì vọng từ mục đích của thao tác đó. Nói một cách ngắn gọn thì tính bảo toàn data có nghĩa là data phải bảo đảm được truy cập data một cách nhất quán chính xác.
⧭Không có bug.
⧭Fault tolerant system: là hệ thống vẫn tiếp tục chạy bình thường nếu như có một phần nào đó của phần mềm bị lỗi.
⧭Tính mở rộng (extensibility) có đặc trưng về mặt thiết kế là có thể thêm những chức năng phụ trợ vào những chức năng sẵn có, và về sau có khả năng nâng cao hiệu suất của chúng.
⧭Tính duy trì (maitainability) là khả năng có thể phục hồi được, có thể duy trì được những tính năng đã được yêu cầu đối với các điều kiện sử dụng được cung cấp trong trường hợp cần bảo trì những thứ có sử dụng phần mềm.
⧭Software documentation.
2. Chất lượng của source code:
Đối với máy tính thì việc source code được viết clean như thế nào cũng không có ý nghĩa gì. Tuy nhiên, đối với con người, việc duy trì lập trình như thế nào là một điều vô cùng quan trọng. Các cách lập trình đều nhấn mạnh vào các qui ước của ngôn ngữ lập trình và việc đọc hiểu code, nâng cao tính duy trì của source code và đơn giản hóa việc debug cũng như fix. Trong khái niệm viết code sao cho tốt bao gồm cả việc code được phân chia thành những từng phần giúp ta có thể quản lý được chúng một cách logic.⧭Khả năng đọc hiểu: code được viết sao cho người khác đọc có thể hiểu được.
⧭Software maintainance được hiểu là qui trình vừa cải thiện, tối ưu hóa phần mềm đó, đồng thời fix bug. Software test , debug, fix bug, cải tiến, dễ transplant.
⧭Không quá phức tạp.
⧭Không quá cần thiết những resource như CPU, bộ nhớ.
⧭Cảnh báo trên lint hoặc compile.
⧭Comment thích hợp.
⧭Phương pháp nâng cao chất lượng: refactoring.
II. Các chỉ tiêu chính và phụ dể đánh giá chất lượng của phần mềm
Độ tin cậy của phần mlaềm là một khái niệm vô cùng quan trọng trong thước đo chất lượng của phần mềm. Trong quality có những khái niệm chủ quan, nhưng độ tin cậy của phần mềm là một yếu tố được đo theo những tiêu chuẩn khách quan. Những tiêu chuẩn đo này được gọi là software metric. Việc cải thiện độ tin cậy của phần mềm trong thực tế sẽ được thực hiện tùy theo áp lực biến những phát triển phần mềm thành những thứ dễ hiểu hơn, chứ không phải là yêu cầu doanh thu. Tuy nhiên, cùng với sự phát triển của ngành công nghệ thông tin, yêu cầu của người sử dụng đối với các phần mềm ngày càng cao, việc bảo đảm độ tin cậy của phần mềm gắn liền với doanh thu.Cùng với sự phát triển của thời đại, các tính năng để xem xét chất lượng của phần mềm đã được biến các nhân tố phụ như khả năng bảo mật và khả năng vận hành đồng thời thành các nhân tố chính của chất lượng phần mềm: độ tin cậy, khả năng sử dụng, hiệu suất, tính duy trì, tính di chuyển, bảo mật, tính chức năng, khả năng vận hành đồng thời.
1.Tính chức năng:
⧭Tính chính xác
⧭Tính vận hành đồng thời
⧭Tính bảo mật
⧭Tính toàn vẹn
⧭Tính tích hợp Tiêu chuẩn tính chức năng
2.Tính tin cậy:
⧭Tính chín chắn
⧭Tính cho phép gây tổn hại
⧭Tính phục hồi
⧭Tính tích hợp tiêu chuẩn độ tin cậy
3.Tính sử dụng:
⧭Tính thấu hiểu
⧭Tính học tập
⧭Tính thao tác
⧭Tính hấp dẫn
⧭Tính tích hợp tiêu chuẩn tính sử dụng
4.Tính hiệu suất
⧭Tính hiệu suất thời gian
⧭Tính hiệu suất tài nguyên
⧭Tính hiệu suất
⧭Tính tích hợp tiêu chuẩn tính hiệu suất
5.Tính duy trì
⧭Tính phân tích
⧭Tính thay đổi
⧭Tính ổn định
⧭Tính thử nghiệm
⧭Tính tích hợp tiêu chuẩn tính duy trì
6.Tính di động
⧭Tính thích ứng
⧭Tính lắp đặt
⧭Tính cùng tồn tại
⧭Tính thay thế
⧭Tính tích hợp tiêu chuẩn tính di động
III.Chất lượng lúc sử dụng: Tính hiệu quả, tính sản xuất, tính an toàn, tính hài lòng.
Giải thích định nghĩa của các nhân tố trong chất lượng của phần mềm
1.Khả năng có thể hiểu được (understandability)
Sản phẩm phần mềm có mục đích phần mềm rõ ràng: đạt yêu cầu có thể hiểu. Yếu tố này không chỉ đơn giản định nghĩa mục đích mà cả bản thiết kế và tài liệu dành cho người dùng cũng cần thiết phải được viết một cách dễ hiểu. Tùy vào người dùng giả định mà yếu tố này trở nên quan trọng đến mức độ nào . Ví dụ như nếu là sản phẩm phần mềm dành cho lập trình viên thì không cần thiết phải viết rõ ràng đến mức cho người bình thường hỏi.
2.Tính bảo toàn: (completement)
Sản phẩm có thể thực hiện các chức năng, và các chức năng đó đáp ứng đủ yêu cầu của mục đích. Ví dụ như khi cần dùng đến thư mục bên ngoài thì ít nhất cũng phải hiển thị ra tài liệu bao gồm cách thức có được thư viện đó hay là cũng cần thiết hiển thị những thông tin liên quan đến version.
3.Tính đơn giản:
Có nghĩa là không có những thông tin thừa thãi. Đây là một điều rất quan trọng trong môi trường bị hạn chế dung lượng bộ nhớ. Ngoài ra, việc giảm thiểu số dòng code cũng có nhiều ý nghĩa nên tính đơn giản rất quan trọng. Tính đơn giản sẽ được cải thiện khi subroutine hóa những chỗ mà xuất hiện lặp đi lặp lại code thực hiện những chức năng khác nhau.
4. Tính di dộng:
Có nghĩa là những thao tác thực hiện trong các máy tính có cấu hình khác nhau đều được thực hiện một cách đơn giản. Tính di động liên quan đến điểm khác biệt của phần cứng (PC và Mac) và tính di động liên quan đến sự khác nhau của OS (Mac OS và GNU/Linux).
5. Tính nhất quán:
Có nghĩa là kí hiệu khi viết code và các từ ngữ chuyên ngành phải nhất quán.
6.Tính duy trì:
Có nghĩa là sự đơn giản khi cần cải thiện nhằm đáp ứng các yêu cầu mới. Một phần mềm có tính duy trì tốt là một phần mềm có đầy đủ các document, không phức tạp, có dung lượng bộ nhớ và hiệu năng đủ đáp ứng yêu cầu.
7.Tính kiểm tra:
Có nghĩa là tiêu chuẩn chấp nhận rõ ràng, và có thể đánh giá được hiệu suất. Tính kiểm tra trong giai đoạn thiết kế trở nên quan trọng. Ngoài ra, đối với những thiết kế phức tạp thì sẽ khiến khả năng của tính kiểm tra trở nên kém hơn.
8. Tính sử dụng:
Có nghĩa là phần mềm có tiện lợi đối với người dùng hay không. và quan trọng là user interface.
9.Tính tin cậy
Có nghĩa là để phòng tránh các lỗi gây ảnh hưởng đến user, phần mềm có thực hiện đầy đủ mục đích của chức năng hay không. Khi cần thiết thì phần mềm cần phải tiếp tục được chạy mặc dù có phát sinh lỗi đi chăng nữa. Điều này gọi là Robustness.
10.Mức độ của cấu trúc hóa:
Các bộ phận cấu thành trở thành một mẫu đồng nhất. Những phần mềm được viết bằng ngôn ngữ cấu trúc hóa như Pascal thường thể hiện đặc tính này rất tốt.
11. Tính hiệu suất:
Có nghĩa là lúc đã hoàn thành mục đích, không sử dụng resource một cách vô ích. Resource trong trường hợp này chính là thời gian sử dụng bộ xử lý và lượng bộ nhớ đã sử dụng.
12.Security:
Có nghĩa là bảo vệ dữ liệu khỏi việc bị truy cập trái phép và có khả năng chống lại những hành động với mục đích xấu. Điều này còn liên quan đến cấu trúc bảo mật của máy tính như mã hóa hoặc là kiểm soát truy cập.
IV. Một vài câu hỏi
Theo như nhiều metrics hay được sử dụng thì những phần mềm có ít bug được đánh giá cao hơn nhiều so với phần mềm có nhiều bug. Bạn hãy xem những câu hỏi dưới đây khi sử dụng Metrics vào
trong thực tế thì sẽ có tác dụng như thế nào nhé:
⧭Loại bug nào có nhiều? Liệu đó có thể hiện rằng phần mềm bạn tạo ra không đúng vói mục đích của phần mềm theo yêu cầu khách hàng hay không? Hay không đúng với qui mô hoặc độ phức tạp của phần mềm?
⧭Tầm nghiêm trọng của bug đó đến mức nào? Tùy vào mức ảnh hưởng đến người sử dụng và mức độ nghiêm trọng của tổn hại mà chúng có thể đo lường được hay không? Nếu không thể đo lường được thì chất lượng của sản phẩm tốt hơn khi có 100 bug hay là 1000 bug.
⧭Trong trường hợp mà số lượng bug ngày càng giảm, điều này có ý nghĩa gì? Ví dụ như chất lượng của phần mềm cải thiện so với lúc trước thì làm thế nào để biết được điều đó? Là do không thực hiện cải tiến nữa so với lúc trước? Hoặc là QA Tester thay đổi người nên không tìm được nhiều bug như lúc trước? Hay là do cả team cố ý báo cáo ít hơn về số bug?
🔺Câu hỏi cuối cùng thể hiện độ khó về mặt quản lý. Phần mềm là thứ do con người tạo ra, chính vì thế những metrics của phần mềm sẽ theo một khía cạnh nào đó sẽ đo lường được hành vi của con người. Nếu như team phát triển phần mềm nhận được một lợi ích nào đó khi giảm thiểu việc báo cáo số bug thì họ có xu hướng thực hiện điều đó. Một trong số đó chính là tìm cách thoát khỏi "hệ thống" truy tìm bug , nếu có 4,5 bug thì chỉ rút gọn thành 1 bug, không báo cáo lỗi nhỏ và giảm được lượng công việc phải thực hiện. Chính vì thế chúng ta không thể đo lường được theo như chúng ta muốn. Dù là vô ý hay cố ý thì các lập trình viên hoặc QA không tìm ra được nguyên nhân thì khả năng đó có thể xảy ra. Ví dụ như phòng quản lý bảo đảm chất lượng dự đoán biểu đồ bug trong việc phát triển phần mềm mới , so sánh với số bug trong thực tế và ước tính số bug còn lại. Nếu như đúng như đã ước tính thì số bug thực tế sẽ ít hơn so với số bug đã ước tính so với số bug đã dự đoán. Nếu như không có báo cáo số bug theo như dự đoán thì sản phẩm đó sẽ không được sản xuất. Team đó sẽ không báo cáo với số bug ít hơn thực tế. Tuy nhiên nếu như dự đoán không chính xác thì số bug thực tế nhiều hơn so với số bug đã dự đoán, điều đó gây hại cho họ và chính vì thế rất có khả năng họ sẽ báo cáo số bug ít hơn so với thực tế.
🔺Những tác nhân ảnh hưởng đến chất lượng của phần mềm thường khó có thể đo lương được. Tuy nhiên, ngoài việc làm rõ làm thế nào chúng thỏa mãn được các thông số theo bản kĩ thuật ngoài các chức năng của sản phẩm thì cần thiết phải có một phương pháp đo lường nào đó. Ví dụ: tính tin cậy là một yếu tố để đánh giá chất lượng phần mềm nhưng không thể cứ để nguyên như vậy mà đánh giá được. Tuy nhiên thì liên quan đến thuộc tính độ tin cậy thì có tồn tại thước đo như thế ví dụ như MTBF, tỷ lệ phát sinh tổn hại, tính khả dụng của hệ thống. Đồng thời, tính di chuyển được thể hiện bẳng con số của platform nằm trong chương trình.
🔺Dưới đây là các câu hỏi giúp chúng ta có thể sử dụng khi đánh giá chất lượng của phần mềm, từ đó dựa trên cơ sở này để cho điểm.
⧭Khả năng có thể hiểu
Tên biến có thể hiện một cách chính xác cấu trúc hoặc chức năng đó không? Đọc những comment và ý nghĩa của code đó có rõ ràng không, dễ hiểu không? Chức năng của cấu tạo data có được phân chia hay không?
⧭Tính bảo toàn
Hệ thống bình thường có bao gồm các chương trình con không được cung cấp không?Có đầy đủ toàn bộ những parameter cần thiết hay không? Có đầy đủ những data buộc phải nhập vào program không?
⧭Tính đơn giản
Có bao gồm những code không được chạy hay không? Có những code dự phòng hay không? Có xảy ra chuyện có cho chạy nhiều lần một cách vô nghĩa những code nên chạy ngoài vòng lặp thay vì trong vòng lặp hay không?
⧭Tính di chuyển
Có phụ thuộc vào những hệ thống hoặc những library chỉ có trong platform hay không? Code phụ thuộc vào platform có được viết rõ ràng hay không?
⧭Tính nhất quán
Tên của một biến có thông dụng và có thể được sử dụng trong nhiều trường hợp? Biểu hiện của hằng số có nhất quán hay không? Có đang chạy bằng các toán tử đồng nhất hay không? Lùi đầu dòng có nhất quán hay không?
⧭Tính bảo toàn
Một phần dung lượng của bộ nhớ có được giữ sẵn lại để phòng cho sự mở rộng trong tương lai hay không? Mức độ tích tụ của mỗi mô-đun có thích hợp hay không? Có thể dễ dàng xử lý trong trường hợp thay đổi cấu trúc dữ liệu hay không. Nếu như có sự thay đổi về chức năng thì có cần thiết thay đổi cấu trúc tổng thể không? (hay điều này cũng phụ thuộc vào nội dung thay đổi?)
⧭Tính kiểm tra
Cấu trúc của code có phức tạp hay không? Giai đoạn thiết kế chi tiết thì pseudocode có được hiển thị hay không? Mức độ trừu tượng của pseudocode ra sao?
⧭Tính sử dụng
Có sử dụng GUI không? Có hệ thống trợ giúp online hay không? Có cẩm nang người dùng hay không? Những thông báo lỗi có dễ hiểu hay không?
⧭Tính tin tưởng
Đã kiểm tra những giá trị giới hạn hay chưa?
⧭Tính hiệu suất
Thời gian chạy đã tối ưu hóa hay chưa? Block code được sử dụng lặp đi lặp lại có được subroutine hóa hay chưa? Có xảy ra rủi ro về bộ nhớ hay không?
⧭Bảo mật
Dữ liệu và tự bản thân chương trình đó có được bảo vệ khỏi những truy cập trái phép hay không? Người sử dụng có thể thay đổi chính sách bảo mật được không? Có xây dựng một cấu trúc bảo mật thích hợp hay không? Code của cơ chế bảo mật có chính xác không? Có thiết kế giả định một cuộc tấn công hay không?
Link dưới đây liệt kê chi tiết các đặc tính chất lượng và chỉ tiêu để đo lường chúng.
https://goo.gl/nk6311
0 Comments:
Post a Comment