Tìm hiểu về chất lượng phần mềm

Phần mềm và lỗi phần mềm

Phần mềm là một tập các dữ liệu hoặc tài liệu hướng dẫn cho máy tính có thể thực hiện được.

Lỗi phần mềm là một error, fault hoặc failure trong chương tình hoặc hệ thống máy tính dẫn đến tạo ra kết quả không chính xác hoặc không mong muốn hoặc một kết quả không lường trước được. Lỗi phần mềm được chia thành 3 dạng:

Error (lỗi): Lỗi xảy ra khi có hành động của con người dẫn đến kết quả sai. Error hay còn được gọi là mistake.
Fault (sai sót): Lỗi xay ra khi có khuyết điểm trong thành phần hoặc hệ thống dẫn đến hành thành phần hoặc hệ thống thực hiện không đúng chức năng của nó. Fault hay còn được gọi là bug, defect.
Failure (Hỏng): Lỗi xảy ra khi kết quả sai lệch với mong muốn của người dùng hoặc đặc tả của sản phẩm.

Các nguyên nhân gây ra lỗi phần mềm

Có rất rất nhiều nguyên nhân dẫn đến 1 phần mềm bị lỗi, dưới đây mình sẽ liệt kê ra các nguyên nhân kinh điển nhất:

1. Lỗi khi định nghĩa yêu cầu

Thường được xem như nguồn gốc của lỗi phần mềm.
- Định nghĩa yêu cầu lỗi: Định nghĩa sai, ví dụ công thức sai.
Định nghĩa không đầy đủ : Yêu cầu không rõ ràng.
Thiếu yêu cầu.
Yêu cầu không cần thiết:
- Nhiều dự án có những yêu cầu mà không bao giờ dùng đến.
- Ảnh hưởng tới ngân sách, độ phức tạp, thời gian phát triển, …

2. Lỗi thiết kế logic

Sai thuật toán, sai công thức tính toán.
Bỏ sót mốt số case trong các trường hợp.
Không xử lý triệt để logic.
Định nghĩa tiến trình: các tiến trình trong hệ thống không phản ánh chính xác tiến trình nghiệp vụ.
Đây là lỗi thủ tục, và không phải là một phần của hệ thống…
Bỏ sót các trạng thái phần mềm, thí dụ đăng tải dữ liệu có phê duyệt nhưng không có thu hồi (luồng không khép kín).
Bỏ sót các định nghĩa liên quan tới các phản ứng khi có hành động không hợp lệ trong phần mềm có code để phát hiện ra các hành động không hợp lệ nhưng không thiết kế các hành động đáp trả của phần mềm. Ví dụ: chuông cảnh báo,…

3. Sai phạm có chủ ý với phần mềm

Tác nhân chủ yếu là Dev.
Dev có thể bỏ qua một số function do áp lực về mặt thời gian, tài chính.
Dev tái sử dụng code mà không test lại.
Dev tự ý cải tiến một số function mà không báo trước.

4. "Gap" giữa giữa Dev và Client

Hiểu sai các tài liệu yêu cầu.
Hiểu sai tài liệu khi bị thay đổi.
Đội khi cùng một vấn đề nhưng Dev hiểu một đường còn Client hiểu một kiểu khác.
Thuật ngữ của Dev và Client khác nhau, cần có một domain language để trám vào khoảng trống (brige gap).

5. Lỗi lập trình

Chủ yếu là lỗi liên quan đến coding
Lỗi cú pháp
Lỗi logic
Lỗi run time

6. Không tuân thủ các hướng dẫn viết code và tài liệu

Không tuân thủ theo các khuôn mẫu templates (structure)
Không tuân thủ theo các chuẩn coding (attribute names…)
(Standards and Integration Branch)
- Các chương trình khác phải chạy được trong môi trường!
- Data Elements và Codes: AFM 300-4;
- Tài liệu hướng dẫn và chỉ dẫn vận hành; AFDSDCM 300-8, …
Đội SQA: kiểm thử không chỉ sự thực thi của phần mềm mà còn chuẩn coding, tài liệu hướng dẫn, thông báo được hiển thị, tài nguyên cần thiết, đặt tên tài nguyên (file names, program names,…)

7. Thiếu sót của quá trình kiểm thử

Là một phần của tiến trình phát triển nhưng thường xuyên bị cắt xén!
Kế hoạch test không đầy đủ: Không test hết các phần của ứng dụng hoặc test qua loa!
Không phát hiện được lỗi tài liệu, báo cáo.
Không phát hiện được chính xác lỗi do mô tả mập mờ về lỗi đó.
Không đủ thời gian để sửa lỗi.

8. Lỗi giao diện người dùng và thủ tục

Các thủ tục chỉ dẫn cho người dùng cach thao tac cần thiết với từng bước của tiến trình. Chúng rất quan trọng với cac phần mềm phức tạp đòi hỏi tiến trình gồm nhiều bước liên tiếp nhau, mỗi bước xử lý nhiều kiểu dữ liệu khac nhau và cho phép kiểm tra cac kết quả trung gian.

9. Lỗi tài liệu

Lỗi trong thiết kế tài liệu.
Lỗi trong tài liệu hướng dẫn sử dụng, online help.
Liệt kê những chức năng không tồn tại: Đã từng lập kế hoạch phát triển, nhưng hoãn và chưa kịp sửa tài liệu.
Thông báo lỗi vô nghĩa.
Đặc tả (Specification): đặc tả lỗi, không đầy đủ, không nhất quan.
Thiết kế (Design): lỗi cơ bản trong thiết kế phần mềm. Cài đặt (Code): lỗi lập trình, mã độc (malicious code).
Hệ thống hỗ trợ: Ngôn ngữ lập trình nghèo nàn, trình biên dịch có lỗi…
Kiểm thử không đầy đủ: kiểm thử chưa xong, kiểm chứng nghèo nàn,…

Tìm hiểu về chất lượng phần mềm

Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức, cá nhân khác nhau. Trong phạm vi của bài viết này trình bày một số định nghĩa tiêu biểu.

1. Định nghĩa theo IEEE(1991):

Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả.

Theo định nghĩa thứ nhất của IEEE: chúng ta sẽ bị phụ thuộc quá nhiều vào tài liệu đặc tả của yêu cầu, dẫn đến nếu xác định yêu cầu bị sai, thiếu thì một phần mềm được làm đúng với đặc tả chưa chắc đã là một phần mềm có chất lượng. Trên thực tế, tài liệu đặc tả được khách hàng xác nhận. Do vậy, lỗi đặc tả sẽ không bị coi và không ảnh hưởng tới chất lượng phần mềm. Đây là điều ta cần xem xét.

Định nghĩa 2: Chất lượng phần mềm là mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu và sự mong đợi của khách hàng hay người sử dụng.

Theo định nghĩa thứ hai của IEEE: nhấn mạnh vào việc làm thỏa mãn khách hàng. Đôi khi khách hàng có thể đưa ra những mong muốn hết sức vô lý và có thể thay đổi yêu cầu phần mềm nhiều lần, thậm chí thay đổi ngay trong giai đoạn cuối. Điều này gây nhiều khó khăn cho việc phát triển phần mềm. Trên thực tế, nhiều vấn đề lớn có thể được phát hiện ra quá muộn. Khách hàng lại không hài lòng.

2. Định nghĩa theo Roger Pressman

Chất lượng phần mềm là sự phù hợp của các yêu cầu cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần mềm được ghi lại rõ ràng bằng tài liệu với các đặc tính ngầm định của tất cả các phần mềm được phát triển chuyên nghiệp.

Định nghĩa của Pressman đề xuất ba yêu cầu với chất lượng phần mềm phải được đáp ứng khi phát triển phần mềm:

Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượng đầu ra của phần mềm.
Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trong hợp đồng.
Các đặc tính ngầm định cần được đáp ứng trong quá trình phát triển cho dù không được nói đến rõ ràng trong hợp đồng.

Đảm bảo chất lượng phần mềm

Định nghĩa theo Daniel Galin: Đảm bảo chất lượng phần mềm (Software Quality Assurance) là tập hợp các hành động cần thiết được lên kế hoạch một cách hệ thống nhằm đem lại sự tin cậy rằng quá trình phát triển phần mềm phù hợp để đáp ứng các yêu cầu chức năng, kỹ thuật cũng như các yêu cầu quản lý theo lịch trình đã thiết lập và hoạt động trong giới hạn ngân sách.

Từ những khái niệm cơ bản trên, McCall đã đề ra 11 tiêu chí cho đảm bảo chất lượng phần mềm, được chia thành 3 loại

Tiêu chí vận hành sản phẩm (Product operation factors): Hệ thống có chạy tốt không, có dễ sử dụng không?
- Correctness (Tính đúng đắn): đặc tả về độ chính xác, sự toàn vẹn của output.
- Reliability (Tính tin cậy): Đề cập tới lỗi khi cung cấp dịch vụ, thí dụ như tỉ lệ lỗi, thời gian hệ thống chết.
- Efficiency (Tính hiệu quả): Đề cập tới tài nguyên phần cứng cần để thực hiện các chức năng của phần mềm.
- Integrity (Tính toàn vẹn): Đề cập tới bảo mật của hệ thống với việc ngăn chặn truy cập trái phép.
- Usability (Tính khả dụng): Đề cập tới quy mô nguồn lực để đào tạo nhân viên mới sử dụng hệ thống.
Tiêu chí sửa đổi sản phầm (Product revision factors): Hệ thống có dễ dàng sửa lỗi không, dễ dàng kiểm thử không?
- Maintainability: Mức công sức cần để bảo trì khi có lỗi, kiến trúc các module như thế nào.
- Flexibility: Đề cập tới nguồn lực để thay đổi phần mềm khi khách hàng thay đổi.
- Testability: Có hỗ trợ test hay không: tạo file log, backup.
Tiêu chí chuyển giao sản phầm (Product transition factors): Hệ thống có dễ dàng chuyển đổi sang các phần cứng không, có thể tái sử dụng không?
- Portability: Nếu phần mềm cài ở môi trường mới, có giữ được các tính năng như cũ không.
- Reusability: Có thể tái sử dụng các module nhỏ không.
- Interoperability: Phần mềm có cần Interface với các hệ thống đã có.

Tổng kết

Trên đây là là một số chia sẻ của tác giả về 1 vấn đề nằm ngoài việc code hằng ngày của các dev. Hy vọng mỗi dev có thể dành 1 chút thời gian, tạm gác lại công việc code để có thể suy nghĩ về một số khía cạnh khác trong quá trình phát triền phần mềm. Và 1 trong những khía cạnh không thể bỏ qua đó là đảm bảo chất lượng phần mềm.

Nguồn bài viết: bài viết được tổng hợp và trích từ các nguồn
https://viblo.asia/p/tong-quan-ve-dam-bao-chat-luong-phan-mem-al5XRBbLRqPe
https://viblo.asia/p/tim-hieu-ve-chat-luong-phan-mem-63vKjXvkl2R
https://viblo.asia/p/tim-hieu-ve-dam-bao-chat-luong-phan-mem-bWrZnayYKxw