Thời gian dành cho yêu cầu và ảnh hưởng của nó đến thời gian phát triển và thành công của dự án

Có bằng chứng nào cho thấy rằng thời gian dành cho việc viết lên, hoặc suy nghĩ về các yêu cầu sẽ có bất kỳ ảnh hưởng nào đến thời gian phát triển không? Nghiên cứu được thực hiện bởi Standish (1995) cho thấy rằng các yêu cầu không đầy đủ một phần (13,1%) đã góp phần vào sự thất bại của các dự án. Có nghiên cứu nào được thực hiện cho thấy thời gian dành cho phân tích yêu cầu sẽ có bất kỳ ảnh hưởng nào đến thời gian phát triển của dự án, hoặc dự án sẽ thành công như thế nào.

Xem Mã hoàn thành, của Steve McConnell, Bảng 3-1. Ông so sánh chi phí trung bình để sửa lỗi dựa trên thời điểm chúng được giới thiệu và phát hiện. Phát hiện tại thời điểm xây dựng tốn gấp 5-10 lần so với phát hiện tại thời điểm yêu cầu và gấp 10 - 100 lần sau khi phát hành.

Bảng này dựa trên các nguồn sau:

1. "Kiểm tra thiết kế và mã để giảm lỗi trong phát triển chương trình" (Fagan 1976)

2. Loại bỏ lỗi phần mềm (Dunn 1984)

3. "Cải tiến quy trình phần mềm trên máy bay Hughes" (Humphrey, Snyder và WIllis 1991)

và nhiều hơn nữa

Vâng, có rất nhiều nghiên cứu về chủ đề này. Tất nhiên, câu hỏi quá chung chung để trả lời cho tất cả các loại dự án phát triển phần mềm, nhưng có bằng chứng từ một số bối cảnh ủng hộ quan điểm cho rằng phân tích yêu cầu đúng sẽ có tác động tích cực đến giai đoạn thực hiện. Bằng chứng này đã được thu thập một phần thành "luật" và đây là ba ví dụ:

Luật kính: Sự thiếu hụt yêu cầu là nguồn gốc của các thất bại của dự án.

Luật này được hỗ trợ bởi bằng chứng nghiên cứu trường hợp từ các dự án phát triển phần mềm lớn. Glass nhận thấy rằng trong những trường hợp thất bại, có quá nhiều yêu cầu, chúng không ổn định do những thay đổi muộn, và chúng mơ hồ và không đầy đủ.

Điều này cho thấy rằng có một mối quan hệ giữa chất lượng yêu cầu và kết quả dự án.

Luật đầu tiên của Boehm: Lỗi thường xuyên nhất trong các yêu cầu và hoạt động thiết kế và càng đắt thì càng bị loại bỏ sau này.

Điều này cũng được hỗ trợ bởi bằng chứng nghiên cứu trường hợp và góp phần trả lời câu hỏi theo cách sau: thực hiện đúng các yêu cầu sẽ giảm số lỗi trong hệ thống và sửa lỗi trước khi bắt đầu thực hiện sẽ ít tốn kém hơn so với việc săn chúng xuống khi triển khai đã bắt đầu (hoặc tệ hơn, khi hệ thống đã được vận chuyển).

Định luật thứ hai của Boehm: Tạo mẫu (đáng kể) làm giảm yêu cầu và lỗi thiết kế, đặc biệt là đối với giao diện người dùng.

Điều này được hỗ trợ bởi các thí nghiệm được kiểm soát trong bối cảnh sinh viên. Một cách giải thích có thể là các yêu cầu và giai đoạn thiết kế không cần phải hoàn toàn dựa trên tài liệu và lý thuyết. Thay vào đó, việc thực hiện tạo mẫu như là một phần của các giai đoạn yêu cầu và thiết kế - phần này dành thời gian và suy nghĩ về các yêu cầu - sẽ ảnh hưởng đến thành công của dự án và thời gian thực hiện.

Ngoài ra còn có nhiều bằng chứng khác cho thấy các điểm theo cùng một hướng: dành thời gian cho việc chuẩn bị thực hiện sẽ được đền đáp dưới hình thức ít rủi ro hơn và ít cơ hội vượt tiến độ do bất ngờ. Mặc dù câu hỏi không phải là về thử nghiệm, nhưng sự chuẩn bị thích hợp cũng ảnh hưởng tích cực đến thử nghiệm.

Các tài liệu tham khảo cho các luật này là:

Định luật kính: Kính, RL: Runaways phần mềm. Bài học rút ra từ những thất bại của dự án phần mềm lớn. Thượng Yên River, NJ: Hội trường Prentice 1998

Định luật đầu tiên của Boehm: Boehm, BW, McClean, RK, Urfrig, DB: Một số kinh nghiệm với thiết bị hỗ trợ tự động để thiết kế phần mềm đáng tin cậy quy mô lớn. IEEE Trans về Kỹ thuật phần mềm 1, 1 (1975), 125 Điện133

Định luật thứ hai của Boehm: Boehm, BW, Grey, TE, Seewaldt, T.: Nguyên mẫu Versus Chỉ định: Một thí nghiệm đa hướng. IEEE Trans về Kỹ thuật phần mềm 10, 3 (1984), 290 Từ302

Ngoài ra, tài liệu tham khảo sau đây có thể được quan tâm: Endres, A. và Rombach, D. Cẩm nang Kỹ thuật phần mềm và hệ thống. Quan sát thực nghiệm, luật và lý thuyết. Sê-ri Fraunhofer IESE về Kỹ thuật phần mềm. Addison Wesley, 2003.