Liệu phương pháp kiểm thử phần mềm dựa vào dữ liệu thiếu sót?


45

Đó là một thực tế nổi tiếng trong công nghệ phần mềm rằng chi phí sửa lỗi tăng theo cấp số nhân trong quá trình phát triển sau này mà lỗi được phát hiện. Điều này được hỗ trợ bởi dữ liệu được xuất bản trong Code Complete và được điều chỉnh trong nhiều ấn phẩm khác.

Tuy nhiên, hóa ra dữ liệu này không bao giờ tồn tại . Dữ liệu được trích dẫn bởi Code Complete rõ ràng không cho thấy mối tương quan về chi phí / thời gian phát triển và các bảng được công bố tương tự chỉ cho thấy mối tương quan trong một số trường hợp đặc biệt và đường cong phẳng trong các trường hợp khác (nghĩa là không tăng chi phí).

Có dữ liệu độc lập nào để chứng thực hoặc bác bỏ điều này không?

Và nếu đúng (nghĩa là nếu đơn giản là không có dữ liệu để hỗ trợ chi phí cao hơn theo cấp số nhân này cho các lỗi được phát hiện muộn), thì điều này ảnh hưởng đến phương pháp phát triển phần mềm như thế nào?


Điều này nghe có vẻ hợp lý, vì có lỗi được phát hiện sau này trong hầu hết các trường hợp cũng liên quan đến hỏng dữ liệu. Hơn nữa, việc dữ liệu bị hỏng sẽ khiến các doanh nghiệp tốn kém rất nhiều nếu điều đó được phát hiện sau này trong quá trình sửa lỗi.
EL Yusubov

8
@ElYusubov Nó thực sự. Nhưng lẽ thường có thể rất lừa dối. Tâm trí của chúng ta dễ bị lừa bởi logic rõ ràng khi nó thực sự ngược lại. Đó là lý do tại sao kỹ thuật phần mềm dựa trên bằng chứng rất quan trọng.
Konrad Rudolph


2
Đối với hồ sơ (và được đề cập trong câu trả lời của tôi), đề cập sớm nhất về điều này tôi đã có thể tìm thấy là tốt trước khi Mã hoàn thành. Công trình của Fagan và Stephenson (độc lập) năm 1976 là tài liệu tham khảo sớm nhất về điều này mà tôi có thể tìm thấy. Phiên bản đầu tiên của Code Complete không được xuất bản cho đến năm 1993, gần 20 năm sau. Tôi hy vọng rằng công việc của Barry Boehm trong những năm 1980 đã dẫn đến sự phổ biến của ý tưởng này - công việc của Boehm rất có ảnh hưởng đến quy trình công nghệ phần mềm vào những năm 1980 và thậm chí vào cuối những năm 2000.
Thomas Owens

1
Điều quan trọng là bất kỳ tuyên bố nào về thống kê kỹ thuật phần mềm đều sai, bao gồm cả điều này. (Các lỗi bạn tìm thấy sau đó nói chung là các lỗi phức tạp hơn và sửa chữa chúng trở nên phức tạp hơn bởi "điều khiển" đưa ra tái sửa cuối hạn..)
Daniel R Hicks

Câu trả lời:


25

Liệu phương pháp kiểm thử phần mềm dựa vào dữ liệu thiếu sót?

Vâng, quỷ dị. Kiểm tra chi phí thay đổi đường cong linh hoạt cho thấy rằng một phần công việc của Kent Beck trên XP (tôi không chắc đó là một phần động lực của anh ta hay sự biện minh của anh ta) là "làm phẳng đường cong" của chi phí khiếm khuyết, dựa trên kiến ​​thức về " đường cong số mũ nằm phía sau bảng Code Complete. Vì vậy, có, làm việc trên ít nhất một phương pháp - một phương pháp đã phổ biến nhất để phát triển thử nghiệm đầu tiên - ít nhất là một phần dựa trên dữ liệu thiếu sót.

Có dữ liệu độc lập nào để chứng thực hoặc bác bỏ điều này không?

Vâng, chắc chắn có dữ liệu khác mà bạn có thể tìm đến - nghiên cứu lớn nhất mà tôi biết là phân tích các khiếm khuyết được thực hiện tại Máy bay Hughes như một phần của chương trình đánh giá CMM của họ . Báo cáo từ đó cho thấy chi phí khiếm khuyết phụ thuộc vào giai đoạn của chúng như thế nào : mặc dù dữ liệu trong báo cáo đó không bao gồm các phương sai nên bạn cần cảnh giác khi rút ra quá nhiều kết luận "điều này tốn kém hơn điều đó". Bạn cũng nên lưu ý rằng, độc lập với phương pháp luận, đã có những thay đổi về công cụ và kỹ thuật giữa những năm 1980 và ngày nay gọi sự liên quan của những dữ liệu này thành câu hỏi.

Vì vậy, giả sử rằng chúng ta vẫn có một vấn đề biện minh cho những con số này:

Điều này ảnh hưởng đến phương pháp phát triển phần mềm như thế nào?

Thực tế là chúng tôi đã dựa vào những con số không thể xác minh được đã không ngăn cản mọi người tiến bộ dựa trên giai thoại và kinh nghiệm: giống như cách mà nhiều giao dịch học nghề chính được học. Tôi không nghĩ rằng có một Tạp chí xây dựng dựa trên bằng chứng trong thời trung cổ, nhưng toàn bộ các tòa nhà lớn, ấn tượng và lâu dài vẫn được xây dựng với một số thành công có thể quan sát được. Điều đó có nghĩa là chúng tôi chủ yếu dựa trên thực tiễn của chúng tôi về "những gì làm việc cho tôi hoặc những người tôi đã gặp"; không có điều gì xấu, nhưng có lẽ không phải là cách hiệu quả nhất để cải thiện một lĩnh vực hàng triệu người cung cấp nền tảng của thời đại công nghệ hiện nay.

Tôi thấy thất vọng vì trong một môn học kỹ thuật được gọi là không có nền tảng tốt hơn trong chủ nghĩa kinh nghiệm và tôi nghi ngờ (mặc dù rõ ràng không thể chứng minh) rằng chúng ta sẽ có thể tiến bộ tốt hơn, rõ ràng hơn trong việc cải thiện các kỹ thuật và phương pháp của mình nền tảng đó tại chỗ - giống như y học lâm sàng dường như đã được chuyển đổi bằng thực hành dựa trên bằng chứng. Điều đó dựa trên một số giả định lớn mặc dù:

  • rằng bản chất độc quyền của hầu hết thực hành kỹ thuật phần mềm không ngăn chặn đủ dữ liệu hữu ích và có liên quan;
  • rằng các kết luận rút ra từ những dữ liệu này thường được áp dụng (vì công nghệ phần mềm là một nghề lành nghề, phương sai cá nhân về kinh nghiệm, khả năng và sở thích có thể ảnh hưởng đến khả năng ứng dụng đó);
  • rằng các kỹ sư phần mềm "trong lĩnh vực" có thể và có động lực để sử dụng các kết quả thu được; và
  • rằng chúng tôi thực sự biết những câu hỏi mà chúng tôi phải hỏi ở nơi đầu tiên. Đây rõ ràng là điểm lớn nhất ở đây: khi chúng ta nói về việc cải tiến công nghệ phần mềm, chúng ta muốn cải thiện điều gì? Đo lường là gì? Liệu cải thiện phép đo đó thực sự cải thiện kết quả, hay nó chơi trò chơi hệ thống? Ví dụ, giả sử ban quản lý tại công ty tôi quyết định chúng tôi sẽ giảm tỷ lệ giữa chi phí dự án thực tế và chi phí dự án dự đoán. Tôi chỉ có thể bắt đầu nhân tất cả các ước tính chi phí của mình với một yếu tố mờ nhạt và tôi đã đạt được "mục tiêu" đó. Sau đó nó có nên trở thành thông lệ công nghiệp tiêu chuẩn để đánh bại tất cả các ước tính?

Câu trả lời meta tuyệt vời về kỹ thuật dựa trên bằng chứng. Cảm ơn.
Konrad Rudolph

4
Chết tiệt, tôi mới nhận ra rằng thứ này đang đi thẳng từ miệng ngựa. Hehe. Tuyệt vời.
Konrad Rudolph

1
Tôi có cảm giác rằng mọi người diễn giải việc sử dụng "dữ liệu thiếu sót" là "hoàn toàn sai sự thật, điều ngược lại là đúng", nhưng tôi có cảm giác rằng vị trí của bạn chỉ đơn giản là chỉ ra rằng nó có thể không đúng sự thật. Điều này có đúng không?
Daniel B

3
@DanielB Đúng. Cho tôi thấy bằng chứng rằng nó thực sự sai và tôi có thể thay đổi suy nghĩ của mình; đến lúc đó tôi chỉ biết rằng nó không phải là được trình diễn ngay.

1
@GrahamLee Tôi thấy quan điểm của bạn (chỉ cần nghĩ rằng phrasing có thể đã được một chút tích cực không cần thiết). Vì tò mò, tôi đã tìm thấy bài báo Fagan ở đây và nó viết "... cho phép làm lại ... gần nguồn gốc của chúng ... rẻ hơn 10 đến 100 lần so với nếu nó được thực hiện trong nửa cuối của quy trình". Tôi không thấy bất kỳ trích dẫn gần văn bản này mặc dù.
Daniel B

8

Về phần tôi, câu trả lời cho "phương pháp này ảnh hưởng đến phương pháp phát triển phần mềm như thế nào" là "không nhiều".

Cho dù bị bắt bởi nhà phát triển hay người dùng cuối, có phải mất thêm tiền để sửa nó sau khi người dùng bị bắt hay không, thực tế vẫn là một lỗi đã được tìm thấy trong hệ thống. Nếu bị nhà phát triển bắt gặp, hy vọng đó là cách khắc phục nhanh. Hy vọng tương tự giữ cho các lỗi bị bắt bởi người dùng.

Bất kể chi phí giờ nhà phát triển thực tế để sửa lỗi do người dùng cuối bắt gặp, vẫn có chi phí vô hình để duy trì khuôn mẫu mà các lập trình viên mút vào những gì họ làm. Khi người dùng tìm thấy lỗi, đó là lỗi của nhà phát triển. Do đó, mỗi lỗi mà người dùng cuối tìm thấy sẽ làm giảm sự tự tin của người dùng đối với hệ thống. Nó giống như tham quan một ngôi nhà bạn muốn mua, và nhìn thấy một vết nước hiển thị trên trần nhà ở một góc của ngôi nhà. Điều đó, bản thân nó, là một sửa chữa dễ dàng, nhưng bạn tự hỏi điều gì đã gây ra nó, và những gì khác mà nguyên nhân gốc rễ có thể đã ảnh hưởng. Sự an tâm của bạn có giá trị gì? Bạn có thể phải xé các bức tường trở lại các đinh tán và kiểm tra trực quan mọi thứ để đảm bảo vết bẩn từ một sự cố bị cô lập đã được khắc phục. Biết rằng đó có thể là một khả năng không làm bạn rất tự tin khi ở nhà. Tương tự

Những chi phí vô hình này được tránh càng sớm thì lỗi được phát hiện, đó là mục đích đã nêu của các phương pháp theo kiểu TDD. Một lỗi được bắt gặp trong khi gõ bởi nhà phát triển hoặc đối tác trong một cặp, một lỗi bị bắt khi biên dịch hoặc một lỗi bị kiểm tra đơn vị / tích hợp (lớp được thêm bởi TDD), là một lỗi mà người dùng không bao giờ phải biết, đó là lỗi của bạn người quản lý dự án không bao giờ phải xin lỗi và bạn không cần phải rút ra bất cứ điều gì bạn đang làm ngay trong giây này để chuyển bánh răng sang chế độ sửa lỗi trên một phần của hệ thống mà bạn nghĩ rằng mình đã bỏ lại hàng tuần trước đây


3
Câu trả lời thú vị. Tôi cố gắng để người dùng của tôi hiểu rằng phát triển là một quá trình lặp đi lặp lại hoặc cả tinh chỉnh và cải thiện. Tôi có thể cung cấp cho họ một cái gì đó rất nhanh và nếu họ thấy có vấn đề hoặc muốn cải thiện, tôi cũng có thể chuyển những thay đổi đó rất nhanh (vài phút hoặc vài giờ, không phải ngày hay tuần). Hệ thống trở nên ổn định hơn theo thời gian, nhưng họ tin tưởng vào quá trình phát triển và kết quả cuối cùng, thay vì quy trình đặc tả và bản dựng đầu tiên. (tất nhiên phụ thuộc vào môi trường mà bạn làm việc - Tôi đang viết dòng ứng dụng kinh doanh nên nếu chúng bị hỏng, chúng sẽ được sửa).
Kirk Broadhurst

Thật không may, bằng chứng ban đầu - rằng các lỗi yêu cầu được tìm thấy khi sản phẩm được đưa vào trường sẽ tốn kém hơn so với các lỗi thực hiện được tìm thấy khi sản phẩm được đưa vào trường - ngụ ý cần phải xác nhận tốt hơn, không phải xác minh tốt hơn. TDD - sử dụng thử nghiệm để xác minh sản phẩm theo các yêu cầu - đơn giản là không liên quan đến việc tìm kiếm các lỗi này.
Pete Kirkham

6

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 RubyErubycon năm 2011, QCon San Francisco năm 2012Hộ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.


@AresresF. một trong những vấn đề tôi tìm thấy khi theo dõi những trích dẫn này là vấn đề mà Bossavit mô tả là vấn đề "kim trong đống cỏ khô" trong cuốn sách bạn liên kết. Trích dẫn một cuốn sách là một sự xáo trộn lớn - ngay cả khi nó vẫn được in khi bạn đọc trích dẫn, bạn đã có vài trăm trang để đọc tìm kiếm một mẩu nhỏ ủng hộ yêu cầu của tác giả trích dẫn.

3

Nó chỉ đơn giản là logic.

Lỗi được phát hiện trong spec.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Như bạn có thể thấy lỗi phát hiện càng muộn thì càng có nhiều người tham gia thì càng phải thực hiện lại nhiều công việc và trong bất kỳ môi trường "bình thường" nào, công việc giấy tờ và quan liêu tăng theo cấp số nhân khi bạn đạt UAT.

Đây là tất cả mà không bao gồm các chi phí mà doanh nghiệp có thể phải chịu do lỗi trong phần mềm sản xuất (mất doanh số, đặt hàng quá nhiều, bị hack của khách hàng, v.v.)

Tôi không nghĩ có ai từng quản lý để viết một hệ thống không tầm thường, không bao giờ có lỗi trong sản xuất, nhưng, bất cứ điều gì bạn có thể làm để bắt lỗi sớm sẽ giúp bạn tiết kiệm thời gian và công sức trong thời gian dài. Đánh giá đặc điểm kỹ thuật, đánh giá mã, kiểm tra đơn vị rộng rãi, sử dụng các lập trình viên khác nhau để viết các bài kiểm tra, v.v ... đều là những phương pháp đã được chứng minh là bắt lỗi sớm.


2
Điều này chỉ bao gồm một trường hợp: lỗi được phát hiện trong spec, tức là một lỗi được đưa ra ngay từ đầu. Nhưng các lỗi có thể được đưa vào trong tất cả các giai đoạn phát triển (bao gồm sửa lỗi sau triển khai) và sửa các lỗi đó sẽ dễ dàng hơn đáng kể vì chúng có thể sẽ ảnh hưởng đến một phần nhỏ hơn của hệ thống.
Konrad Rudolph

2
Nhưng vấn đề là sửa lỗi có thể có tác dụng phụ không mong muốn, vì vậy trừ khi bạn hoàn toàn có thể đảm bảo sửa lỗi sẽ chỉ ảnh hưởng đến một bộ phụ cụ cụ thể mà bạn đang mắc kẹt với việc làm lại SIT UAT, v.v. thay đổi.
James Anderson

2
Tôi vẫn không tin rằng điều này cho thấy rằng các lỗi sẽ luôn tốn kém hơn để khắc phục khi được phát hiện muộn. Tôi cho rằng một lỗi sẽ tốn kém hơn để sửa chữa trong thời gian qua sau khi được giới thiệu . Tức là một lỗi được giới thiệu muộn, được phát hiện ngay sau đó và được sửa chữa rẻ hơn một lỗi được giới thiệu rất sớm và được phát hiện sớm (nhưng với độ trễ dài hơn trong trường hợp đầu tiên). Ít nhất tôi có thể tưởng tượng rằng đây là cách nó hoạt động.
Konrad Rudolph

@KonradRudolph Bạn có thể giải thích? Bài đăng này cũng khá nhiều sự hiểu biết của tôi, và tôi không hiểu tại sao thời gian lại quan trọng nhưng giai đoạn thì không. Đối với tôi, thước đo thời gian trong một dự án là giai đoạn hiện tại của bạn (và đôi khi việc lặp lại theo thời gian của bạn để trải qua tất cả các giai đoạn). Tôi không thấy sự khác biệt giữa công việc được thực hiện trong Ngày 3 của thiết kế chi tiết và Ngày 300 - sản phẩm công việc thiết kế chi tiết chưa được sử dụng để tạo ra bất kỳ sản phẩm công việc nào khác, do đó, một lỗi trong thiết kế chi tiết chỉ tồn tại ở một nơi và chỉ đòi hỏi một sự thay đổi ở đó Tôi không thấy ngày trôi qua quan trọng như thế nào.
Thomas Owens

3
@Thomas Tôi chỉ đưa ra giả thuyết. Nhưng thời gian là vấn đề bởi vì hầu hết các đoạn mã hoặc tính năng đặc tả được giới thiệu sẽ ảnh hưởng đến nhiều thành phần hơn khi thời gian trôi qua, trừ khi chúng có tính chuyên môn cao và không có gì khác sẽ phụ thuộc vào chúng, trực tiếp hoặc gián tiếp. Vì vậy, một lỗi tồn tại lâu dài, bất kể nó được đưa vào giai đoạn nào, sẽ có khả năng ảnh hưởng đến nhiều bộ phận của hệ thống và việc loại bỏ nó đòi hỏi phải đảm bảo rằng không có thành phần nào khác bị phá vỡ bởi quá trình đó.
Konrad Rudolph

2

Tôi tin rằng đây là và luôn luôn là về quản lý rủi ro và kinh tế. Chi phí giảm số lượng khuyết tật so với giá trị hiện tại của tác động của các khiếm khuyết trong tương lai là gì. Quỹ đạo của con chim màu vàng hơi tắt trong Angry Birds không đánh đồng quỹ đạo của một tên lửa hành trình Tomahawk đang tắt. Các nhà phát triển phần mềm trong cả hai dự án không thể đưa ra quyết định dựa trên bảng đó. Về vấn đề này, không có gì thay đổi.

Cách tôi nghĩ rằng điều này có xu hướng hoạt động là thông qua phản hồi, các lỗi đắt tiền trong lĩnh vực này khiến các công ty thắt chặt quy trình chất lượng của họ trong khi không có khiếu nại từ lĩnh vực này khiến các công ty nới lỏng nó. Vì vậy, theo thời gian, các công ty phát triển phần mềm sẽ có xu hướng hội tụ hoặc dao động xung quanh một cái gì đó phù hợp với họ (+/-). Code Complete có thể ảnh hưởng đến một số giá trị ban đầu hoặc có thể kéo các công ty hơi theo cách này hay cách khác. Một công ty dành quá nhiều nỗ lực để loại bỏ các khiếm khuyết mà không ai có thể nhận thấy có lẽ sẽ mất việc kinh doanh cho một đối thủ cạnh tranh có cách tiếp cận tối ưu hơn. Mặt khác, một công ty phát hành các sản phẩm lỗi cũng sẽ bị phá sản.

Một số giấy tờ có liên quan từ một tìm kiếm nhanh (đọc các giấy tờ đầy đủ, nghiên cứu thêm và hình thành ý kiến ​​của riêng bạn):

Một tổng quan tài liệu hệ thống về nghiên cứu chi phí chất lượng phần mềm (2011)

"Mặc dù cộng đồng đã phát triển sự hiểu biết đúng đắn về cấu trúc của lĩnh vực nghiên cứu, nhưng việc xác thực theo kinh nghiệm thường thiếu. Chỉ khoảng một phần ba các bài viết được phân tích trình bày một nghiên cứu trường hợp hoặc kết quả thực nghiệm sâu rộng hơn. Điều này dường như không đủ cho nghiên cứu chi phí chất lượng phần mềm. , dựa vào dữ liệu định lượng để tạo ra những phát hiện mới. Do đó, cần có những cách tiếp cận mới để thu thập dữ liệu chi phí chất lượng, cũng như hợp tác mạnh mẽ hơn giữa ngành công nghiệp và nghiên cứu để cung cấp dữ liệu đó. "

Đánh giá chi phí chất lượng phần mềm (1998)

"Cuối cùng, chúng tôi đã thấy rằng điều quan trọng là phải giám sát chi phí tuân thủ và sự không phù hợp của phần mềm để các chính sách tuân thủ có thể được điều chỉnh để giảm tổng chi phí cho chất lượng phần mềm."

Hành vi chi phí của lỗi phần mềm (2004)

Tóm tắt ... "Các nghiên cứu hiện tại cố gắng cập nhật kiến ​​thức của chúng tôi về cách khắc phục lỗi và chi phí sửa chữa chúng (hoặc thay vào đó, khiến chúng không bị ảnh hưởng) ảnh hưởng đến chi phí cuối cùng của phần mềm" ... " với từng giai đoạn mà chúng chưa được giải quyết "

Phạm vi kiểm tra và khuyết tật sau xác minh: Một nghiên cứu nhiều trường hợp (2009)

"Chúng tôi cũng thấy rằng nỗ lực thử nghiệm tăng theo cấp số nhân với phạm vi thử nghiệm, nhưng việc giảm các vấn đề tại hiện trường tăng tuyến tính với phạm vi thử nghiệm. Điều này cho thấy rằng đối với hầu hết các dự án, mức độ bao phủ tối ưu có thể sẽ thiếu 100%."

Thu hẹp khoảng cách giữa quy trình kiểm thử phần mềm và giá trị doanh nghiệp: Một nghiên cứu điển hình (2009)


0

Tôi không thể trả lời phần đầu tiên của câu hỏi, vì đơn giản là tôi chưa kiểm tra. Nhưng tôi có thể tạo ra một câu trả lời cho câu hỏi thứ hai của bạn, và có lẽ gợi ý về một câu trả lời có thể cho câu hỏi thứ nhất.

Không cần phải nói rằng một số yếu tố quan trọng nhất trong chi phí sửa lỗi, ngăn chặn bản chất khó sử dụng các công cụ phát triển, là sự phức tạp nội tại của sản phẩm và người dùng có thể hiểu sản phẩm đó tốt đến mức nào.

Tập trung vào mã thứ hai, với giả định rằng mã thường được viết và duy trì bởi các nhà phát triển có khả năng xử lý sự phức tạp nội tại của mã của họ (có thể không hoàn toàn đúng và có thể đáng để tranh luận về chính nó), tôi dám đề xuất rằng tầm quan trọng của cricital trong bảo trì, và do đó trong việc sửa lỗi, là khả năng của người bảo trì để hiểu mã đã nói.

Khả năng hiểu mã được tăng cường đáng kể bằng cách sử dụng các công cụ kỹ thuật phần mềm đã được chứng minh, thật không may, chủ yếu được sử dụng không đúng hoặc không đúng cách. Sử dụng mức độ trừu tượng, mô đun hóa, tăng cường sự gắn kết mô-đun và giảm khớp nối mô-đun là những công cụ quan trọng để đối phó với sự phức tạp cần sử dụng đúng cách. Mã hóa cho các giao diện, hoặc, trong OOP, tránh việc sử dụng quá mức kế thừa so với thành phần, đóng gói theo tính năng, là một số kỹ thuật thường không được chú ý đầy đủ trong mã hóa.

Tôi tin rằng thực tế cạnh tranh trong ngành đặt một lực lượng tiêu cực vào việc sử dụng các phương pháp nâng cao chất lượng để phát triển phần mềm, giữ chất lượng nội tại của phần mềm là thước đo thành công liên tục.

Do đó, tôi tin rằng, trong ngành công nghiệp, phần mềm có xu hướng chịu nhiều chi phí sửa lỗi hơn khi nó phát triển lớn hơn. Trong các sản phẩm như vậy, lỗi trở nên khó sửa hơn theo thời gian vì hệ thống trở nên khó hiểu hơn khi nó phát triển. Các mối quan tâm được giới thiệu bởi mỗi tính năng được kết hợp quá mức với các mối quan tâm khác, làm cho dễ hiểu. Hoặc, mức độ trừu tượng phù hợp đã không được sử dụng, khiến cho người bảo trì khó có thể xây dựng một mô hình phù hợp của hệ thống và lý do về nó. Thiếu tài liệu chắc chắn không giúp được gì.

Có những ngoại lệ. Tôi chắc chắn rằng Google không hoạt động theo tốc độ của mình mà không có một số thực tiễn vững chắc được các nhà phát triển xuất sắc ủng hộ. Và những người khác có khả năng trong tình huống tương tự. Nhưng đối với đa số các phần mềm, tôi sẽ không ngạc nhiên nếu dữ liệu đã làm trên thực tế xác nhận yêu cầu bồi thường trong Code Complete .


Tôi đứng trước câu trả lời của tôi ngay cả với đánh giá tiêu cực. Gần đây tôi đã phỏng vấn một ứng viên duy trì công cụ ngân hàng trực tuyến của một trong những ngân hàng hàng đầu. Trong khi trò chuyện thông thường, anh đề nghị không sử dụng nó, vì sử dụng lại bản sao-dán nặng và cấu trúc kém chất lượng. Ở một công việc trước đây, tôi là một nhà phát triển tại một công ty viết các công cụ phân tích cho các ngân hàng như Lehman, MS, UBS và chúng tôi phải đóng vai trò là chuyên gia tên miền, tìm ra điều tiếp theo để đưa vào chi nhánh khác từ hầu hết các tài liệu thưa thớt. Ngay cả khi không đồng ý với các thông lệ cụ thể, thông điệp tổng thể lại: ngành công nghiệp là đúng.
Mihai Danila

-1

Một câu trả lời khác! Lần này để giải quyết câu hỏi tiêu đề "Liệu morhtodoligy phần mềm có dựa vào dữ liệu thiếu sót không".

Câu trả lời thực sự là "không có dữ liệu". Vì không có khối lượng dữ liệu đáng tin cậy lớn về các dự án phần mềm, có những khiếm khuyết, thời gian thành công để tiếp thị, v.v.

Tất cả các nỗ lực để thu thập dữ liệu đó đã bị thiếu, thiếu sót về mặt thống kê hoặc ,, cụ thể đối với một dự án cụ thể, không thể đưa ra kết luận chung từ đó.

Hơn nữa, tôi không nghĩ sẽ có bao giờ, quá trình phát triển phần mềm quá chủ quan và trơn trượt khi đo lường nghiêm ngặt. Các tổ chức được sắp xếp tốt nhất để thu thập dữ liệu đó (các nhà tích hợp hệ thống và nhà tích hợp hệ thống lớn) biết trong lòng họ rằng bất kỳ số liệu nào thu thập được từ hiệu suất của họ sẽ rất xấu hổ.

Các tổ chức duy nhất công bố số liệu về chi phí và thành công của các dự án phần mềm
là các cơ quan chính phủ, và sau đó chỉ vì họ phải, và, vâng, những con số này rất xấu hổ cho dù họ có xoa bóp các con số đến mức nào.

Vì vậy, trong kết luận, tất cả các nghiên cứu phần mềm nhất thiết phải hoàn toàn chủ quan vì không có dữ liệu thực tế để dựa vào kết luận khách quan.


1
Không, tôi không mua cái này. Trước hết, đó dữ liệu mặc dù bạn có thể đúng rằng nó sai lầm. Nhưng điều này đòi hỏi một sự phê phán riêng lẻ của từng bộ dữ liệu, không phải là sự bác bỏ chung. Và tôi vô cùng nghi ngờ về sự ganh đua rằng sẽ không bao giờ có dữ liệu và những lý do như vậy là quá chủ quan. Đó thực chất là một cuộc tranh luận từ sự thiếu trí tưởng tượng . Tôi không giả vờ rằng thu thập số liệu thống kê đáng tin cậy ở đây là dễ dàng, nhưng tôi cho rằng nó hoàn toàn khả thi. Trong các lĩnh vực khác, cách các hệ thống phức tạp hơn được phân tích thành công.
Konrad Rudolph

@Konrad - lấy thứ gì đó cơ bản và đơn giản như "đếm lỗi", một số cửa hàng đếm lỗi thử nghiệm đơn vị, một số cửa hàng không bắt đầu theo dõi lỗi cho đến UAT, một số cửa hàng chỉ theo dõi lỗi trong mã, một số cửa hàng bao gồm tài liệu, cấu hình và kịch bản triển khai trong quá trình theo dõi lỗi của họ. Có màu nền sai được tính là một khiếm khuyết? Một số dự án sẽ theo dõi nó như một khiếm khuyết, những người khác sẽ bỏ qua nó.
James Anderson

Đó là tất cả các vấn đề đơn phương - tức là có thể giải quyết được. Họ không đặt những ràng buộc cơ bản vào những gì có thể, họ chỉ thêm những khó khăn cần giải quyết.
Konrad Rudolph
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.