Mọi người phát triển phần mềm đều muốn dự án của họ được đúng thời gian, trong ngân sách và có chất lượng cao. Vậy mà nhiều dự án tiếp tục bị chậm, chi phí cao, chất lượng thấp, với ít chức năng hơn được yêu cầu.

Có nhiều lí do nhưng hiển nhiên nhất là số lượng lỗi cao cần phải được loại bỏ. Lỗi được tạo ra trong toàn thể vòng đời dự án nhưng thường được tìm thấy khi kiểm thử. Vào lúc này, dự án gần hoàn thành cho nên người phát triển vội vàng sửa chúng nhanh chóng nhất có thể được. Vấn đề là khi bạn sửa lỗi vội vàng, bạn có thể chèn thêm lỗi khác điều đòi hỏi thêm kiểm thử. Nhiều kiểm thử làm cho dự án chậm và tốn thêm.

Theo nghiên cứu của Ts. Barry Boehm tại đại học Nam California (USC) chi phí để sửa lỗi là quãng 65% tổng chi phí dự án. Do đó, để cải tiến chất lượng và chi phí của dự án phần mềm, người quản lí phải giải quyết vấn đề lỗi. Cách tốt nhất để loại bỏ lỗi là dùng kiểm điểm phần mềm hay kĩ thuật giám định sớm trong vòng đời. Ts. Barry Boehm thấy rằng về trung bình, tốn $1 để loại bỏ lỗi ở cuối pha yêu cầu, sẽ tốn $10 ở pha thiết kế, $100 trong pha viết mã, $1000 trong pha kiểm thử, và trên $10,000 khi người dùng tìm ra lỗi.

Theo Watt Humphrey thuộc Viện kĩ nghệ phần mềm (SEI) tại Carnegie Mellon, người phát triển trung bình có thể lập trình quãng 300 dòng mã một ngày nhưng tạo ra 100 lỗi cứ mỗi 1000 dòng mã. Việc tìm và chữa yêu cầu xấp xỉ 4 tới 10 giờ cho mỗi lỗi cho nên với mỗi 8 giờ viết mã, có thể cần thêm 20 tới 30 giờ để kiểm thử, phát hiện và loại bỏ lỗi. Đó là lí do tại sao nhiều dự án phần mềm bị chậm và tốn phí thêm.

Kiểm điểm phần mềm không mới nhưng không được dùng thường xuyên như nó đáng phải vậy. Lí do là đơn giản: Nhiều người phát triển không muốn người khác biết về lỗi của họ, họ có xu hướng kiểm điểm công việc của mình bên trong nhóm nhỏ các bạn bè rồi che giấu các lỗi để cho họ có thể sửa chúng về sau. Tuy nhiên, dự án phần mềm bao giờ cũng bận rộn với nhiều hoạt động cho nên người phát triển không có thời gian để sửa các lỗi của họ. Đôi khi họ quên các lỗi cho nên các lỗi cứ tiếp tục chuyển từ pha này sang pha khác cho tới thời gian kiểm thử những người kiểm thử mới có thể tìm ra chúng. Có những người quản lí dự án coi phát triển phần mềm là viết mã và bất kì “hoạt động không viết mã’ nào cũng đều là phí thời gian. Họ tin kiểm thử là nơi mọi người nhận diện và sửa lỗi cho nên họ không cổ vũ cho kiểm điểm phần mềm. Họ không biết rằng sửa lỗi xuất hiện về sau làm tốn kém thêm và mất thời gian thêm cho dự án, càng nhiều lỗi, càng tốn tiền loại bỏ chúng.

Nếu người phát triển phạm sai lầm nhưng người kiểm thử tìm được chúng về sau trong khi kiểm thử, người phát triển không bao giờ biết tại sao và khi nào họ đã phạm phải những sai lầm đó. Kiểm điểm phần mềm được thiết kế để tiến hành ở cuối pha phát triển để cho người phát triển biết đích xác họ đã làm gì. Chẳng hạn, kiểm điểm yêu cầu thường để trắc nghiệp tính đầy đủ của nhu cầu của khách hàng; kiểm điểm kiến trúc được dùng để kiểm nghiệm thuộc tính chất lượng liên kết với hệ thống phần mềm; kiểm điểm thiết kế được dự định để chỉ ra rằng thiết kế là đầy đủ tới mức kĩ lưỡng nào đó. Kiểm điểm mã là để trắc nghiệm rằng chương trình tuân theo thiết kế logic và không sai lầm viết mã nào bị phạm phải.

Kiểm điểm phần mềm điển hình bao gồm sáu bước: 1) Bước lập kế hoạch bao gồm nhận diện tài liệu cần kiểm điểm, lựa chọn người kiểm điểm và thu xếp nơi họp và thời gian họp, 2) Bước đào tạo bao gồm đào tạo tất cả những người kiểm điểm và vai trò và trách nhiệm của họ. 3) Bước chuẩn bị bao gồm cho phép có thời gian cho từng người kiểm điểm kiểm điểm lại tài liệu và nhận diện lỗi tiềm năng.  4) Bước kiểm điểm bao gồm nơi họp để tổ tụ tập thảo luận lỗi được tìm thấy. Mục đích của kiểm điểm là đi tới thoả thuận về những lỗi đã được tìm ra nhưng không sửa chúng trong khi kiểm điểm. Người lãnh đạo kiểm điểm hướng dẫn hoạt động này và yêu cầu người kiểm điểm, những người đã kiểm điểm tài liệu này trong pha chuẩn bị, thảo luận về tài liệu này theo cách hệ thống. Lỗi được tìm ra được ghi lại. 5) Bước sửa chữa bao gồm việc để thời gian cho tác giả của tài liệu bị lỗi để sửa chúng và 6) Bước theo dõi nơi người quản lí dự án hay đảm bảo chất lượng trắc nghiệm rằng mọi lỗi đã được sửa và không lỗi phụ đã được đưa vào.

Bằng việc sửa lỗi ở cuối từng pha phát triển, người phát triển học về những sai lầm của mình cho nên họ không phạm phải chúng lần nữa. Bằng việc không cho phép lỗi truyền sang pha sau, người quản lí dự án có thể được đảm bảo rằng họ không phải sửa nhiều lỗi vào cuối dự án khi thời gian đang căng thẳng. Bằng loại bỏ hầu hết lỗi sớm sủa, người kiểm thử có thể hội tụ nhiều hơn vào các khía cạnh khác của sản phẩm phần mềm như chức năng và thuộc tính chất lượng thay vì nhận diện lỗi. Bằng hiểu ích lợi của kiểm điểm phần mềm để cải tiến lịch biểu dự án, chi phí và chất lượng, người quản lí dự án phải động viên nhiều cuộc kiểm điểm phần mềm và đạt tới thành công hơn.

—-English version—-

Blog245-software review

Every software developer wants their project to be on time, within cost, and have high quality. Yet many projects continue to be late, higher costs, low quality, with less function than required. There are many reasons but the most obvious is the high amount of defect that must be removed. Defects are created throughout the project life cycle but usually found during testing. At this time, the project is near completion so developers are hurrying to fix them as quick as they can. The problem is when you fix defects in a hurry, you may insert another defect which require more testing. More testing makes project late and costs more.

According to the study of Dr. Barry Boehm at University of Southern California (USC) the costs of fixing defects is about 65% of total project costs. Therefore, to improve the quality and the cost of software projects, manager must solve the defects issue. The best way to remove defects is using the software reviews or inspection technique earlier in the life cycle. Dr. Barry Boehm found that on the average, it costs $1 to remove a defect at the end of requirements phase, it will cost $10 at design phase, $100 during coding phase, $1000 in test phase, and over $10,000 when a user finds a defect.

According Watt Humphrey of the Software Engineering Institute (SEI) at Carnegie Mellon, an average developer can program about 300 lines of code per day but makes 100 defects for every 1000 lines of code. The finding and fixing require approximately 4 to 10 hours per defect so for each 8 hours of coding, it may require another 20 to 30 hours for testing, finding, and removing defects. That is why many software projects are late and costs more.

Software review is not new but not use often as it should. The reason is simple: Many developers do not want others to know about their defects, they tend to review their works within a small group of friends then hide defects so they can fix them later. However, software project is always busy with many activities so developers do not have time to fix their defects. Sometime they forget about their defects so defects continue to pass from one phase to another until testing time where testers may find them. There are project managers who consider software development is coding and any “non-coding activity” is a waste of time. They believe testing is the place where people identify and fix defect so they do not encourage software reviews. They do not know that fixing defect late incurs additional costs and time to the project, the more defects the higher the cost to remove them.

If developers make mistakes but testers find them later during testing, developers never know why and when they made those mistakes. Software reviews are designed to conduct at the end of each development phase so developers know exactly what they did. For example, Requirements review is used to verify the completeness of the customer’s needs; Architecture review is used to validate the quality attributes associated with software system; Design review is intended to show that a design is complete to a certain level of elaboration. Code review is to verify that the program is following the logical design and no coding mistake is made.

Typical software review consists of six steps: 1) Planning step consists of the identification of material to be reviewed, select reviewers and arrange meeting place and time, 2) Training step includes the training of all reviewers and their roles and responsibilities. 3) Preparing step includes allowing time for each reviewer to review materials and identify potential defects.  4) Reviewing step consists of a meeting place where the team gather to discuss defects found. The goal of the review is to have agreement on the found defects but not to fix them during the review. A review leader leads the activity and ask reviewers who have reviewed the materials during the preparing phase to discuss the material in a systematic fashion. Defects found are recorded. 5) Fixing step consists of allowing time for the author of the defect material to fix their defects and 6) Follow-up step where project manager or quality assurance verifies that all defects have been fixed and no additional defects have been introduced.

By fixing defects at the end of each development phase, developers learn about their mistakes so they do not make them again. By not allow defects to pass into the next phase, project managers can be assured that they do not have to fix a lot of defects at the end of the project where time is critical. By removing most defects early, testers can focus more on other aspects of the software product such as functionality and quality attributes rather than identify defects. By understand benefits of software reviews to improve project schedule, costs and quality, project manager should encourage more software reviews and achieve more success.