Có vài phương pháp để nhận diện các lỗi trong phát triển phần mềm: Review (duyệt lại), walkthrough (rà lại) và inspection (kiểm định, hoặc thẩm định). Hiệu quả nhất là phương pháp thẩm định phần mềm (có tên gọi Fagan) vì nó được Michael Fagan của IBM phát triển trong những năm 70.
Theo phương pháp này, thẩm định phải là nhiệm vụ chính thức (formal); tài liệu được thẩm định phải được chuẩn bị và đáp ứng các tiêu chí đầu vào của thẩm định; và những người làm thẩm định phải có đủ tư cách khách quan và năng lực, cũng như phải sắp xếp được thời gian và địa điểm để tiến hành giống như các giám thị chấm thi. Hãy tưởng tượng về kế hoạch sắp xếp một buổi nửa ngày cho các chuyên gia thẩm định liên tục trong 4 tiếng đồng hồ và chỉ tập trung một nhiệm vụ duy nhất, đó là tìm ra các vấn đề (defect) của tài liệu. Họ sẽ có nửa giờ để họp "focus group", trao đổi thông tin và tổng hợp các nhiệm vụ con.
Lưu ý nhiệm vụ thẩm định không hoàn toàn tập trung tìm lỗi chính tả của tài liệu. Giả định rằng tiêu chí cho đầu vào thẩm định là: các lỗi chính tả là không có, hoặc rất ít. Tiêu chí đầu vào thứ hai là tài liệu phải đúng mẫu (template), ví dụ tài liệu Software Specification không thể lẫn với Software Design hay Business Blueprint. Chúng ta có thể định nghĩa thêm các tiêu chí thứ 3, 4, ... n...
Tiêu chí thêm:
- Team size: khoảng 3-4 người
- Thành phần: Developer/Tester từ các dự án tương tự
- Người thẩm định không phải là tác giả tài liệu.
- Phải đảm bảo mức độ chồng chéo (overlap) gần như ít xảy ra hoặc ở mức vừa phải.
- Phải đảm bảo các vùng thông tin quan trọng nhất trong tài liệu đặt trong tầm ngắm của công tác thẩm định.
Có các vai trò chính thức cho từng người tham gia và họ phải được đào tạo về phương pháp này (người dẫn, người ghi, giám định viên, tác giả là tối thiểu). Những người tham gia phải kiểm điểm tài liệu trước cuộc họp (ít nhất vài ngày). Mục đích chính của họp giám định chỉ là để tìm lỗi KHÔNG tìm giải pháp. Sau giám định, tác giả của công việc (tức là người phát triển) phải làm lại sửa mọi lỗi. Có phiên họp theo dõi nơi người dẫn giám định, người đảm bảo chất lượng hay thỉnh thoảng toàn tổ giám định sẽ kiểm điểm để thẩm tra rằng mọi lỗi đã được sửa và không lỗi phụ nào đã bị đưa vào.
Nhiệm vụ của thẩm định không phải là tìm lỗi (của lập trình viên, của tác giả tài liệu), mà là tìm ra khiếm khuyết (defect) của quy trình và nhiệm vụ đã triển khai.
Kiểm điểm và duyệt thảo không chính thức như giám định nhưng chúng hữu dụng và có thể được dùng bên cạnh giám định chính thức. Về căn bản cuộc duyệt thảo là kiểm điểm của nhóm về bất kì sản phẩm kĩ thuật nào bởi những người làm việc trong cùng dự án. (Có thể là người lập trình, người thiết kế, người phát triển hay bất kì ai có thể được tham gia vào các pha đa dạng của dự án) nhìn vào công việc của ai đó và đưa ra lời bình luận liên quan tới các lỗi. Vì là không chính thức, buổi duyệt thảo không nên bao gồm người quản lí dự án, giám đốc, hay người dùng. Lí do cho buổi duyệt thảo là để nhận diện lỗi nhanh nhất có thể được. Buổi duyệt thảo có thể xảy ra vào bất kì lúc nào và bất kì đâu trong việc phát triển sản phẩm phần mềm.
6 bước thẩm định theo phương pháp Fagan:
- Kế hoạch: Planning
Nhiệm vụ thẩm định được lên kế hoạch tỉ mỉ bởi người điều hành (thẩm định viên trưởng). - Mở đầu: Overview (1-to-n meeting)
Thẩm định viên trưởng sẽ mô tả bối cảnh ra đời của tài liệu (spec) hoặc sản phẩm (phần mềm). - Chuẩn bị (thẩm định cá nhân): Preparation (individual inspection)
Mỗi thành viên kiểm tra từng phần để xác định các khiếm khuyết có thể xảy ra. - Thẩm định: Inspection (n-to-n meeting)
Trong cuộc họp này, người đọc rà qua từng phần một và những người kiểm tra chỉ ra những khiếm khuyết ở từng phần. - Tiến hành vòng 2: Rework
Thực hiện các thay đổi theo kế hoạch hành động từ cuộc họp kiểm tra. - Theo sát hành động: Follow-up
Những đề xuất thay đổi của các chuyên gia được kiểm tra để đảm bảo mọi thứ đều chính xác.
Kiểm điểm là chính thức hơn duyệt thảo nhưng không chính thức bằng giám định. Kiểm điểm thường được tiến hành vào cuối từng pha trong vòng đời phát triển phần mềm như kiểm điểm yêu cầu, kiểm điểm kiến trúc, hay kiểm điểm thiết kế. Mục đích của kiểm điểm là để chắc rằng mọi thứ cần được thực hiện trong một pha vòng đời là được thực hiện cho nên người phát triển có thể đi tiếp sang pha sau. Như một điểm kiểm tổng quát, nó có thể không bắt được lỗi như giám định. Kiểm điểm có sự tham gia của người quản lí, giám đốc hay khách hàng và người dùng.
TIGO PMO - Quản lý và đánh giá chất lượng phần mềm
