Một sinh viên hỏi tôi: “Thầy có thể nói cho em sự khác biệt giữa duyệt thảo, kiểm điểm và giám định phần mềm không. Phương pháp nào là tốt hơn và tại sao có nhiều phương pháp thế?”

Đáp: Có vài phương pháp để nhận diện các lỗi trong phát triển phần mềm (kiểm điểm, duyệt thảo và giám định). Hiệu quả nhất là giám định chính thức phần mềm hay giám định 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, giám định phải là chính thức; tài liệu định để được giám định phải được chuẩn bị và đáp ứng các tiêu chí đầu vào giám định; và những người làm giám định phải có đủ tư cách, cũng như có thời gian và nơi chốn phải được thu xếp trước về thời gian. 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.

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.

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.

Tôi đã viết chi tiết về những phương pháp này trong blog này, xin đọc chúng.

—-English version—-

Software inspection, review, and walkthrough

A student asked me: “Can you tell me the differences between software walkthrough, review, and inspection. Which method is better and why there are so many of them?

Answer: There are several methods to identify defects during the software development. (Review, walkthrough and Inspection) The most effective is software formal inspection or Fagan inspection as it was developed by Michael Fagan of IBM in the 70s. According to this method, inspection must be formal; materials to be inspected must be prepared and meet the inspection entry criteria; and people who inspect must be qualified, as well as the time and place must be arranged ahead of time. There are formal roles for each participant and they must be trained in the method. (Moderator, Recorder, Inspectors, Author as minimum) The participants must review the materials ahead of the meeting (At least few days). The main purpose of the inspection meeting is only to find defects NOT solution. After the inspection, the author of the work (i.e., developer) must rework all defects. There is a follow up session where the inspection moderator, quality assurance or sometime the entire inspection team will review to verify that all defects have been fixed and no additional defects have been introduced.

Reviews and Walkthroughs are not as formal as Inspection but they are useful and can be used in addition to formal inspections. Basically a walkthrough is a group review of any technical product by people who work on the same project. (It could be programmers, designers, developers, or anyone who may be involved in various phases of the project) to look into someone ‘s work and made comments regarding defects. As a non-formal, a walkthrough should not include the project managers, the director, or users. The reason for walkthrough is to identify errors as quickly as possible. A walkthrough can take place at anytime and anywhere in the development of a software product.

A review is more formal than a walkthrough but not as formal as an inspection. Reviews that are usually conducted at the end of each phase in the software development lifecycle such as requirements review, architecture review, or design review. The purpose of reviews is to make sure that everything that need to be done in a lifecycle phase are done so developers can go on to the next phase. As a general checking point, it may not catch errors as an inspection. Review does involve the project manager, the director or customers and users.

I have written in detail about these methods in this blog, please read them.