Kiểm điểm phần mềm
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.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
