Tôi sẽ mở đầu điều này với thực tế là hầu hết những gì tôi tìm thấy đến từ những năm 1970 và đầu những năm 1980. Trong thời gian này, các mô hình quy trình tuần tự phổ biến hơn nhiều so với các phương pháp lặp và / hoặc tăng dần (mô hình Xoắn ốc hoặc các phương pháp nhanh). Phần lớn công việc này được xây dựng trên các mô hình tuần tự này. Tuy nhiên, tôi không nghĩ rằng sẽ phá hủy mối quan hệ, nhưng một trong những lợi ích của phương pháp lặp / tăng dần là giải phóng các tính năng (toàn bộ lát cắt dọc của ứng dụng) một cách nhanh chóng và khắc phục các vấn đề trong đó trước khi phụ thuộc vào từng giai đoạn cao.
Tôi vừa lấy bản sao Kinh tế Kỹ thuật phần mềm và tìm thấy một tài liệu tham khảo về dữ liệu đằng sau biểu đồ này trong Chương 4. Ông trích dẫn "Kiểm tra thiết kế và mã để giảm lỗi trong phát triển chương trình" của ME Fagan ( IEEE , PDF từ UMD ), EB "Quản lý công nghệ phần mềm" của Daly, "Phân tích tài nguyên được sử dụng trong phát triển phần mềm hệ thống tự vệ" ( ACM ) và "một số dự án TRW" của WE Stephenson .
... Chi phí tương đối của việc sửa lỗi phần mềm (hoặc thực hiện các thay đổi phần mềm khác) là một chức năng của giai đoạn trong đó việc sửa chữa hoặc thay đổi được thực hiện. Nếu một lỗi yêu cầu phần mềm được phát hiện và sửa chữa trong giai đoạn kế hoạch và yêu cầu, việc sửa lỗi là một vấn đề tương đối đơn giản để cập nhật đặc tả yêu cầu. Nếu cùng một lỗi không được sửa chữa cho đến giai đoạn bảo trì, việc sửa chữa bao gồm một kho lớn hơn nhiều về thông số kỹ thuật, mã, hướng dẫn sử dụng và bảo trì và tài liệu đào tạo.
Hơn nữa, sửa chữa muộn liên quan đến một quá trình phê duyệt và kiểm soát thay đổi chính thức hơn nhiều, và một hoạt động rộng lớn hơn nhiều để xác nhận lại sự điều chỉnh. Các yếu tố này kết hợp để làm cho lỗi thường đắt hơn 100 lần để sửa trong giai đoạn bảo trì trên các dự án lớn so với trong giai đoạn yêu cầu.
Bohem cũng đã xem xét hai dự án nhỏ hơn, ít chính thức hơn và thấy chi phí tăng, nhưng ít quan trọng hơn nhiều so với 100 lần được xác định trong các dự án lớn hơn. Với biểu đồ, sự khác biệt dường như lớn hơn 4 lần để khắc phục khiếm khuyết yêu cầu sau khi hệ thống hoạt động so với trong giai đoạn yêu cầu. Ông quy cho điều này là hàng tồn kho nhỏ hơn bao gồm các dự án và hình thức giảm dẫn đến khả năng thực hiện đơn giản hơn cố định nhanh hơn.
Dựa trên Boehm trong Kinh tế Kỹ thuật phần mềm, bảng trong Code Complete khá cồng kềnh (mức thấp của các phạm vi thường quá cao). Chi phí để thực hiện bất kỳ thay đổi nào trong giai đoạn thực sự là 1. Ngoại suy từ Hình 4-2 trong Kinh tế Kỹ thuật phần mềm, một thay đổi yêu cầu phải là 1,5-2,5 lần về kiến trúc, 2,5-10 trong mã hóa, 4-20 trong thử nghiệm và 4 - 4 100 trong bảo trì. Số lượng phụ thuộc vào quy mô và độ phức tạp của dự án cũng như hình thức của quy trình được sử dụng.
Trong Phụ lục E của Barry Boehm và Richard Turner Cân bằng nhanh nhẹn và Kỷ luật có một phần nhỏ về những phát hiện thực nghiệm liên quan đến chi phí thay đổi.
Đoạn mở đầu trích dẫn Lập trình cực đoan của Kent Beck Giải thích, trích dẫn Beck. Nó nói rằng nếu chi phí thay đổi tăng chậm theo thời gian, các quyết định sẽ được đưa ra càng muộn càng tốt và chỉ những gì cần thiết mới được thực hiện. Điều này được gọi là "đường cong phẳng" và nó là thứ thúc đẩy Lập trình cực đoan. Tuy nhiên, những gì tài liệu trước đây tìm thấy là "đường cong dốc", với các hệ thống nhỏ (<5 KSLOC) có thay đổi 5: 1 và các hệ thống lớn có thay đổi 100: 1.
Phần này trích dẫn Trung tâm Kỹ thuật phần mềm dựa trên kinh nghiệm của Đại học Maryland (được tài trợ bởi Quỹ khoa học quốc gia). Họ đã thực hiện tìm kiếm các tài liệu có sẵn và thấy rằng các kết quả có xu hướng xác nhận tỷ lệ 100: 1, với một số kết quả cho thấy phạm vi từ 70: 1 đến 125: 1. Thật không may, đây thường là các dự án "thiết kế lớn lên phía trước" và được quản lý theo cách thức liên tục.
Có các mẫu "dự án Java thương mại nhỏ" chạy bằng Lập trình cực đoan. Đối với mỗi Câu chuyện, số lượng nỗ lực sửa lỗi, thiết kế mới và tái cấu trúc đã được theo dõi. Dữ liệu cho thấy khi hệ thống được phát triển (nhiều câu chuyện của người dùng được triển khai), nỗ lực trung bình có xu hướng tăng theo tỷ lệ không tầm thường. Nỗ lực tái cấu trúc tăng khoảng 5% và nỗ lực sửa chữa nỗ lực tăng khoảng 4%.
Điều tôi đang học là sự phức tạp của hệ thống đóng một vai trò lớn trong số lượng nỗ lực cần thiết. Bằng cách xây dựng các lát dọc thông qua hệ thống, bạn làm chậm tốc độ của đường cong bằng cách thêm từ từ phức tạp thay vì thêm nó vào các cọc. Thay vì xử lý hàng loạt các yêu cầu phức tạp theo sau là một kiến trúc cực kỳ phức tạp, tiếp theo là một triển khai cực kỳ phức tạp, v.v., bạn bắt đầu rất đơn giản và thêm vào.
Điều này có tác động gì đến chi phí để khắc phục? Cuối cùng, có lẽ không nhiều. Tuy nhiên, nó có những lợi thế cho phép kiểm soát nhiều hơn sự phức tạp (thông qua việc quản lý nợ kỹ thuật). Ngoài ra, việc phân phối thường xuyên thường được kết hợp với nhanh có nghĩa là dự án có thể kết thúc sớm hơn - thay vì giao "hệ thống", các phần được phân phối cho đến khi nhu cầu kinh doanh được thỏa mãn hoặc thay đổi mạnh mẽ rằng một hệ thống mới (và do đó là một dự án mới) là cần thiết.
Các số liệu và mô hình của Stephen Kan trong Kỹ thuật chất lượng phần mềm có một phần trong Chương 6 về hiệu quả chi phí của việc loại bỏ khuyết tật pha.
Ông bắt đầu bằng cách trích dẫn bài báo năm 1976 của Fagan (cũng được trích dẫn trong Kinh tế Kỹ thuật phần mềm) để nói rằng việc làm lại trong thiết kế cấp cao (kiến trúc hệ thống), thiết kế cấp thấp (thiết kế chi tiết) và việc thực hiện có thể rẻ hơn từ 10 đến 100 lần hơn công việc được thực hiện trong quá trình kiểm tra mức thành phần và hệ thống.
Ông cũng trích dẫn hai ấn phẩm, từ 1982 và 1984, bởi Freedman và Weinberg thảo luận về các hệ thống lớn. Đầu tiên là "Sổ tay hướng dẫn, kiểm tra và đánh giá kỹ thuật" và thứ hai là "Đánh giá, hướng dẫn và kiểm tra". Việc áp dụng các đánh giá sớm trong chu kỳ phát triển có thể giảm số lỗi xảy ra trong các giai đoạn thử nghiệm xuống 10 lần. Việc giảm số lượng lỗi này dẫn đến giảm chi phí kiểm tra từ 50% đến 80%. Tôi sẽ phải đọc các nghiên cứu chi tiết hơn, nhưng có vẻ như chi phí cũng bao gồm việc tìm kiếm và sửa chữa các khiếm khuyết.
Một nghiên cứu năm 1983 của Remus, "Xác nhận phần mềm tích hợp trong quan điểm kiểm tra / đánh giá", đã nghiên cứu chi phí loại bỏ các khiếm khuyết trong các giai đoạn khác nhau, cụ thể là kiểm tra thiết kế / kiểm tra mã, kiểm tra và bảo trì, sử dụng dữ liệu từ Phòng thí nghiệm Santa Teresa của IBM ở California. Các kết quả được trích dẫn cho thấy tỷ lệ chi phí là 1:20:82. Đó là, một khiếm khuyết được tìm thấy trong kiểm tra thiết kế hoặc mã có chi phí thay đổi là 1. Nếu cùng một lỗi thoát ra trong thử nghiệm, nó sẽ tốn kém hơn 20 lần. Nếu nó thoát khỏi tất cả các cách để người dùng, nó sẽ nhân nhiều chi phí để sửa cho tối đa 82. Kan, sử dụng dữ liệu mẫu từ cơ sở Rochester, Minnessota của IBM, thấy chi phí loại bỏ lỗi cho dự án AS / 400 là tương tự lúc 1:13:92. Tuy nhiên, ông chỉ ra rằng sự gia tăng chi phí có thể là do sự khó khăn tăng lên để tìm ra một khiếm khuyết.
Các ấn phẩm của Gilb năm 1993 ( "Kiểm tra phần mềm" ) và 1999 ("Tối ưu hóa đặc tả kỹ thuật phần mềm và quy trình kiểm soát chất lượng") về kiểm tra phần mềm được đề cập để chứng thực các nghiên cứu khác.
Thông tin bổ sung có thể được tìm thấy trong trang của Construx về Tăng chi phí khuyết tật , cung cấp một số tài liệu tham khảo về việc tăng chi phí sửa chữa khuyết tật. Cần lưu ý rằng Steve McConnell, tác giả của Code Complete, đã thành lập và làm việc cho Construx.
Gần đây tôi đã nghe một cuộc nói chuyện, Real Software Engineering , được đưa ra bởi Glenn Vanderburg tại Hội nghị Lone Star Ruby năm 2010. Anh ấy đã nói chuyện tương tự tại Hội nghị Scotland Ruby và Erubycon năm 2011, QCon San Francisco năm 2012 và Hội nghị Kiến trúc phần mềm O'Reilly vào năm 2015 . Tôi chỉ nghe Hội nghị Lone Star Ruby, nhưng cuộc nói chuyện đã phát triển theo thời gian khi ý tưởng của anh ấy được cải tiến.
Venderburg gợi ý rằng tất cả các dữ liệu lịch sử này thực sự đang hiển thị chi phí để sửa chữa các khiếm khuyết khi thời gian tiến triển, không nhất thiết là một dự án chuyển qua các giai đoạn. Nhiều dự án được kiểm tra trong các bài báo và sách đã đề cập trước đây là các dự án "thác nước" tuần tự, trong đó giai đoạn và thời gian di chuyển cùng nhau. Tuy nhiên, một mô hình tương tự sẽ xuất hiện trong các dự án lặp và gia tăng - nếu một khiếm khuyết được đưa vào trong một lần lặp, thì việc sửa chữa trong lần lặp đó sẽ tương đối rẻ tiền. Tuy nhiên, khi các bước lặp tiến triển, rất nhiều điều xảy ra - phần mềm trở nên phức tạp hơn, mọi người quên một số chi tiết nhỏ về làm việc trong các mô-đun cụ thể hoặc các phần của mã, yêu cầu thay đổi. Tất cả những điều này sẽ làm tăng chi phí sửa chữa khuyết điểm.
Tôi nghĩ rằng điều này có lẽ gần với thực tế hơn. Trong một dự án thác nước, chi phí tăng lên vì số lượng hiện vật cần được sửa chữa do một vấn đề ngược dòng. Trong các dự án lặp và gia tăng, chi phí tăng lên do sự gia tăng độ phức tạp trong phần mềm.