Có nhiều cách để đánh giá chất lượng phần mềm như nó đáp ứng các yêu cầu tốt thế nào, nó hữu dụng cho người dùng thế nào, và số lỗi được tìm ra khi kiểm thử. Tuy nhiên, với nhiều người phát triển, chất lượng thường là điều cuối cùng họ kiểm trước khi đưa ra cho khách hàng. Phần lớn việc kiểm chất lượng được thực hiện trong pha kiểm thử và điều đó thường là quá trễ. Bạn càng nhận diện lỗi sớm, càng dễ và càng đỡ tốn phí cho sửa lỗi.

Theo nhiều khảo cứu, mỗi lần một lỗi lọt sang pha tiếp, nó tăng độ phức tạp lên theo thừa số 5 và tăng chi phí sửa lên thừa số 10. Chẳng hạn, một lỗi tốn $10 để sửa trong pha thiết kết, $100 để sửa trong pha viết mã và $1000 để sửa trong pha kiểm thử và $10,000 để sửa sau khi đưa ra cho khách hàng.  

Vì yêu cầu sai có thể làm tăng độ phức tạp trong thiết kế và viết mã lên nhiều lần, bằng việc giám sát chất lượng trong toàn bộ qui trình phát triển, người quản lí dự án có thể quyết định liệu có tiếp tục phát triển hay thay vì thế thiết kế lại và sửa lỗi. Thỉnh thoảng tốt hơn cả là bắt đầu lại dự án thay vì tiếp tục sửa lỗi vì phần mềm quá phức tạp và khó thay đổi. Trong các pha phát triển phần mềm, người quản lí dự án phải có khả năng theo dõi các lỗi trong từng pha để phán xét chất lượng của phần mềm vào mọi lúc được cho. Đến cuối từng pha, người quản lí dự án phải đánh giá cả chất lượng và tính đầy đủ để xác định liệu dự án có nên chuyển sang pha tiếp hay không. Cách tốt nhất là dùng danh sách kiểm ở cuối từng pha vòng đời.

Khi một lỗi được tìm ra, người quản lí dự án phải ghi lại nó trong sổ kí sự lỗi. Nó sẽ được cho một con số để cho phép nó được tham chiếu tới từ lúc tạo ra cho tới lúc giải quyết. Điều quan trọng là lỗi được cho một kiểu ưu tiên nào đó phản ánh độ nghiêm trọng của nó. Ưu tiên này sẽ xác định khi nào nó cần được sửa và liệu lỗi này có là đủ nghiêm trọng tác động tới lịch biểu không. Từng lỗi đều nên được phân công cho một người phát triển và sau khi nó được sửa, đảm bảo chất lượng phải chắc rằng nó được kiểm thử đầy đủ và được ghi lại trong sổ sự kí lỗi (mở, đóng). Một yếu tố phẩm chất quan trọng khác là tỉ lệ theo đó lỗi này được tìm ra. Điển hình tỉ lệ tìm ra cao được mong đợi trong các pha phát triển sớm, tỉ lệ này nên giảm đi qua thời gian khi nhiều lỗi trong chúng đã được sửa.

Người quản lí dự án cũng phải đánh giá nguyên nhân của lỗi để xác định chức năng hay mô đun nào của phần mềm có nhiều lỗi nhất. Bằng việc biết các khu vực sinh lỗi này, người quản lí có hành động như tăng nhiều kiểm thử hơn trong những khu vực nào đó của mã; thiết kế lại chức năng hay mô đun; hay phân công những người có kinh nghiệm hơn để làm việc trên các khu vực sinh lỗi.

Các công ti theo dõi lỗi và tổ chức chúng dựa trên độ nghiêm trọng, ưu tiên và các tiêu chí khác có thể cải tiến đáng kể chất lượng của họ. Bằng việc thường xuyên đánh giá về chất lượng vào bất kì lúc nào trong vòng đời phát triển, họ có thể cải tiến chất lượng và giảm lỗi với niềm tin lớn, biết rõ rằng mọi nỗ lực đã được được thực hiện để tìm và sửa lỗi.

—-English version—-

Improving software quality

There are several ways to evaluate software quality such as how well it meets requirements, how useful to users, and the number of defects found during testing. However, to many software developers, quality is usually the last thing they check before release to customer. Most quality checks are done during testing phase and it is usually too late. The early you can identify defect, the easier and less costly to fix a defect. According to several studies, every time a defect passes into the next phase, it increases the complexity by a factor of 5 and the fixing cost by a factor of 10. For example, a defect costs $1 to fix in requirements phase will cost $10 to fix in design phase, $100 to fix in coding phase and $1000 to fix during testing phase and $10,000 to fix after release to customer.

Since a wrong requirement can increase complexity in design and code many times, by monitor quality throughout the development process, project managers can decide whether to continue the development or redesign and correct defects instead. Sometime it is better to restart the project rather than continue to fix defect as the software is too complex and difficult to change. During software development phases, project manager must have the ability to track defects in each phase in order to judge the quality of the software at any given time. At the end of each phase, project manager must evaluate both the quality and the completeness to determine whether the project should move to the next phase or not. The best way is to use checklists at the end of each lifecycle phase.

When a defect has been found, project manager must record it in a defect log. It will be assigned a number that allows it to be referenced from creation through resolution. It is important that the defect be given some type of priority that reflects its severity. This priority will determine when it needs to be fixed and whether the defect is serious enough to impact the schedule. Each defect should be assigned to a developer to fix and after it is fixed, quality assurance must make sure that it is fully tested and record the status in the defect log (Open, close). Another important quality factor is the rate at which defects are found. Typically a high find rate is expected during early phases of development, the rate should decrease over time as many of them have been fixed.

Project manager must also evaluate the causes of defects to determine which of its software functions or modules have the most defects. By knowing these error-prone area, manager can take action such as increase more testing in certain areas of the code; redesign a function or module; or assign more experienced developers to work on defect-prone areas.

Companies that track defects and organize them based on severity, priority and other criteria can improve their quality significantly. By constantly evaluate quality at any given time in the development lifecycle, they can improve their quality and reduce defects with greater confidence, knowing that every effort has been made to find and fix defects.