Có tốn kém đáng kể để sửa một lỗi ở cuối dự án không?


21

Trong một bài đăng trên blog của Andrew Hay , các tiên đề sau đã được đặt ra:

Chi phí cao hơn đáng kể để sửa một lỗi ở cuối dự án mà nó sửa để sửa cùng một lỗi trước đó trong dự án.

Tuy nhiên, điều này dường như không chắc chắn, đặc biệt là sau khi đọc một bài đăng trên blog về Ít sai và dữ liệu tôi thấy để sao lưu nó là rất cũ.

Đây có phải là tiên đề chính xác ngày hôm nay?


@StefanHendriks Các ý kiến ​​trong bài viết được liên kết của bạn từ Morendil thực sự bao gồm mọi thứ bạn có thể hỏi; IMHO. Thông tin tuyệt vời đấy.
Aaron McIver

@AaronMcIver ý định của tôi là có nhiều người biết đến điều này. Giống như truyền bá và tăng cơ hội nhận được dữ liệu thực. Tôi không tìm kiếm một cuộc thảo luận thực sự; những người tuyệt vời đang được tổ chức tại bài viết (như bạn cũng đã tìm ra :)).
Stefan Hendriks

2
Xin chào Stefan, đây không phải là một bảng thảo luận, cũng không phải là hộp xà phòng: Tôi đã xóa bình luận của bạn khỏi câu hỏi. Chúng tôi có thể giúp giải thích các khía cạnh của phát triển phần mềm, nhưng nếu bạn đang muốn sử dụng trang web này như một phương tiện để quảng bá ý tưởng của mình hoặc chia sẻ các bài đăng trên blog mà bạn thích, thì bạn đã ở sai chỗ.

Mặc dù điều này chắc chắn có liên quan đến lập trình, nhưng bản chất của câu hỏi thực sự có thể làm cho nó phù hợp hơn trên các nhà phê bình.stackexchange.com.
StriplingWar Warrior

Câu trả lời:


16

Dữ liệu cứng duy nhất tôi từng thấy là Boehm và Papaccio, Hiểu và kiểm soát chi phí phần mềm .

Điều này bắt nguồn từ năm 1988 và là một nghiên cứu về khoảng 80 dự án phần mềm. Họ kết luận rằng một quyết định được đưa ra sớm và sửa chữa muộn có thể tốn 50-200 lần so với những gì nó có nếu được sửa sớm. Nhưng loại quyết định rất sớm mà họ đang nói đến là hệ điều hành nào sẽ chạy và sử dụng ngôn ngữ và cơ sở dữ liệu nào.

Vì vậy, những con số này có thể bị quá tải đối với sự phát triển phần mềm ngày nay. Tuy nhiên, bây giờ chúng tôi có rất nhiều kinh nghiệm trong lĩnh vực này và chúng tôi biết theo bản năng rằng nó vẫn đúng đến một điểm.

Trong cực đoan, chúng tôi biết rằng nếu thất bại trong các yêu cầu được bắt gặp ngay trước khi chúng tôi đi vào sản xuất, điều này gây ra rất nhiều việc làm lại và khiến dự án bị trì hoãn hoặc thực sự bị hủy bỏ, nếu nó đã bị bắt trước khi bất kỳ công việc nào được thực hiện, chúng tôi Tôi đã ổn.

Chỉnh sửa: Doc Brown làm cho một điểm tốt trong bình luận của mình.

Nghiên cứu của Boehm đã được thực hiện trên các dự án của COBOL và FORTRAN trong thời gian biên dịch và thời gian chạy chậm một cách lố bịch. Tôi đã bắt đầu sự nghiệp của mình vào đầu những năm 90 trên COBOL và chu trình biên dịch và kiểm thử thường mất nhiều thời gian đến mức đáng để thử nghiệm mã khô trước khi trải qua chu kỳ (hoặc ít nhất là trong giai đoạn xây dựng, chỉ trong trường hợp bạn có thể bắt một cái gì đó và hủy nó sớm, tiết kiệm cho mình một giờ hoặc lâu hơn).

Đổi lại, các ông chủ của chúng tôi thường cười trước những lời phàn nàn của chúng tôi bởi vì cách đây không lâu họ thường phải mang một hộp thẻ đục lỗ được sắp xếp bằng tay đến phòng máy chủ và để nó ở đó trong một ngày.

Vì vậy, nó là chắc chắn hơn đúng thì hơn bây giờ.

Tuy nhiên, gần đây, tôi đã thấy các blog sử dụng lại hình dung của Steve McConnell về vấn đề này ( ref , ngày 1996) như thể biểu đồ đó thực sự dựa trên những con số khó. Không phải vậy. Đó là một hình dung, để giải thích quan điểm của mình một cách đơn giản.

Tôi nghĩ rằng tiền đề của Morendil, trong bài viết mà OP trích dẫn, là một điều tốt. Khoa học chúng ta có về chủ đề này còn nghèo nàn và lỗi thời và chưa được coi là canon. Nhưng tôi cũng nghĩ rằng nó giữ vững và nghe có vẻ đúng bởi vì chúng ta biết từ kinh nghiệm cay đắng rằng nó vẫn đúng, ít nhất là đến một điểm. Và tôi nghĩ rằng "kỷ luật bệnh hoạn" kịch tính của anh ấy không làm anh ấy ủng hộ.


3
+1. Tôi nghĩ người ta nên nói thêm rằng nghiên cứu của Boehm đã được thực hiện tại thời điểm mà chi phí xây dựng và triển khai các bản phát hành lỗi cao hơn nhiều so với hiện nay.
Doc Brown

@DocBrown: Điểm tốt. Thêm. Cùng với một lùm xùm hơn nữa.
pdr

+1 để tham khảo thực sự, +1 cho trực quan hóa (quá tệ, tôi chỉ có thể đưa ra một điểm.) Câu trả lời tuyệt vời, cảm ơn!
Stefan Hendriks

15

Mặc dù tôi không biết về bất kỳ dữ liệu cứng hoặc bằng chứng nào khác để hỗ trợ cho tuyên bố này, ở mức tối thiểu , tôi cho rằng đó là lẽ thường.

Nghĩ về nó theo cách này .. Nếu bạn có một hệ thống phức tạp với các hệ thống con phụ thuộc lẫn nhau (như hầu hết các ứng dụng không tầm thường làm), hãy nghĩ về các vấn đề có thể là kết quả của những thay đổi được thực hiện đối với bất kỳ một trong các hệ thống. Nếu hệ thống con được chứng minh là đúng (thông qua kiểm tra đơn vị và các loại tương tự) và cố định sớm, số lượng các lỗi sẽ được gây ra do knock-ons mình đang giảm nhẹ chỉ đơn giản bằng cách sửa chữa sớm.

Ngoài ra, nếu bạn sửa lỗi sớm, việc triển khai vẫn còn mới mẻ trong tâm trí của nhà phát triển. Tùy thuộc vào độ dài của bất kỳ dự án cụ thể nào, nếu cuối cùng bạn đang sửa lỗi, nhà phát triển sẽ cần dành thời gian để tìm hiểu những gì họ đã viết và (có lẽ) cách các hệ thống con mà mã của họ phụ thuộc vào hoạt động. Thời gian học lại này = $.


1
Vì vậy, về cơ bản, chúng ta đang nói về số lượng nỗ lực để sửa lỗi sau này (hoặc sớm hơn). Tôi có thể nghĩ về các yếu tố khác làm cho lỗi đắt hơn nếu được sửa sau này. Nhưng điều đó phụ thuộc vào định nghĩa của bạn về lỗi. Có lẽ đó là một cái gì đó để được thỏa thuận đầu tiên. Trong cuốn sách của tôi, đó cũng là một "kỳ vọng không phù hợp trong phiên bản này". Giống như, một chức năng bị thiếu. Điều này có thể chi phí tiền thật, vì vậy nó rõ ràng hơn sau đó. Một số tính năng mặc dù có thể không có giá cao hơn (như đối với các trang web, CSS thay đổi?) Bây giờ sớm hơn. Hoặc, không nhiều hơn đáng kể. Tuy nhiên, tôi không có dữ liệu.
Stefan Hendriks

@StefanHendriks: Chúng tôi đang nói về cả số lượng nỗ lực cũng như các lỗi mới phát sinh do các bản sửa lỗi được yêu cầu. Bạn có thể phải đào sâu vào các bài đăng dự án (những người đã sử dụng cả hai phương pháp) để có được dữ liệu thực tế.
Demian Brecht

2
@AaronMcIver: Việc tôi rút ra từ bài viết không phải là phương pháp nào tốt hơn, mà là nghiên cứu và dữ liệu cứng được sử dụng để sao lưu yêu cầu và giải thích sai trong các báo cáo tiếp theo. Mặc dù câu trả lời của tôi không dựa trên dữ liệu công khai, nhưng nó dựa trên hơn 10 năm kinh nghiệm chuyên môn xử lý các hệ thống rất phức tạp.
Demian Brecht

1
BTW Tôi không đồng ý rằng các thay đổi CSS không bị như vậy. Hãy thử khắc phục sự cố bố cục khi bạn có tất cả các pixel khác hoàn hảo và bạn sẽ thấy rằng bạn có thể phải phá vỡ nhiều thứ
Andrea

1
@DppyBrecht Câu trả lời của bạn rất chủ quan, đó là lý do tại sao tôi hỏi. Đó là suy đoán và một cảm giác ruột. Trong khi những người chắc chắn có thể giữ trọng lượng, vấn đề là nó có thể thường xuyên hơn không phải là một đại diện không chính xác của thực tế như bài viết chỉ ra. Sử dụng ý thức chung làm tiêu chí của bạn về lý do tại sao nó có thể chi phí nhiều hơn cũng có thể được đảo ngược. Bạn có thể lập luận rằng số lượng cá nhân liên quan đến sửa lỗi có thể là yếu tố thực sự khiến nó tốn kém hơn hay không, coi thường nỗ lực thực tế của các nhà phát triển.
Aaron McIver

12

Tôi nghi ngờ rằng hoàn toàn có thể đưa ra một cách đo lường khoa học cứng nhắc này - có quá nhiều yếu tố khác liên quan và không có hai dự án nào có thể so sánh đủ để phục vụ nhiều hơn nghiên cứu trường hợp. Tư duy logic sẽ giúp bạn đi một chặng đường dài. Một vài lập luận:

  • Tổng số lượng mã trong một dự án có xu hướng phát triển về cuối. Bạn chờ đợi sửa lỗi càng lâu, cơ sở mã hóa mà bạn phải chạm vào càng lớn.
  • Chất lượng của mã mới được thêm vào một dự án giảm dần về cuối, ít nhất là nếu có áp lực (thường là nhất định): thời hạn thấp thoáng khiến mọi người ném các thực tiễn tốt nhất lên tàu chỉ để giao hàng đúng giờ. Điều này có nghĩa là bạn càng sửa lỗi sau, mã càng xấu bạn phải sàng lọc.
  • Mặc dù việc sao chép mã thường không được chấp nhận, nó luôn xảy ra và vì nó dễ sao chép-dán, nhưng khó hợp nhất lại các phần mã trùng lặp, số lượng mã được sao chép thường tăng lên trong suốt vòng đời của một dự án. Mã dán nhiều bản sao hơn có nghĩa là khả năng cao hơn là lỗi của bạn sẽ bị trùng lặp và cần được tìm thấy và sửa chữa nhiều lần (và do đó, khả năng cao hơn là một số sự cố xảy ra không được chú ý).
  • Sửa lỗi là một thay đổi đối với một cơ sở mã; bạn hy vọng sẽ làm cho mọi thứ tốt hơn, nhưng một sự thay đổi luôn mang đến rủi ro. Một thay đổi gây ra vấn đề nghiêm trọng trong một dự án kéo dài hàng tháng nên để lại nhiều khoảng trống để quản lý thiệt hại, nhưng hai ngày trước khi vận chuyển, bạn gặp rắc rối nghiêm trọng.
  • Bản thân lỗi tồn tại càng lâu, càng có nhiều khả năng các phần khác của ứng dụng bắt đầu dựa vào hành vi sai trái của nó. Sau đó, khi bạn sửa nó, bạn đột nhiên giải phóng một loạt các lỗi thứ cấp trong mã mà không mong đợi chức năng của bạn thực sự cung cấp kết quả được ghi lại chính xác.

+1. Câu trả lời chính xác. Sao chép và dán mã có lỗi tạo ra nhiều lỗi hơn tùy thuộc vào các mô-đun phụ thuộc vào nó.
Karthik Sreenivasan

2

Đây là công cụ cơ bản được chấp nhận từ kỹ thuật hệ thống - và nó áp dụng cho bất kỳ hình thức phát triển kỹ thuật nào (có thể là xây dựng cầu, tên lửa, tàu chiến hoặc phần mềm).

Về cơ bản, chi phí của mọi thứ tăng lên khoảng một bậc khi bạn chuyển qua các giai đoạn phát triển.

Một cái gì đó có giá 10 đô la để sửa chữa tại thời điểm hình thành ý tưởng ...

Sẽ có giá khoảng 100 đô la nếu bạn cần cập nhật thông số kỹ thuật ....

Hoặc chi phí khoảng 1000 đô la nếu một cái gì đó được triển khai và bạn cần thực hiện các thay đổi tại thời điểm đó (và cập nhật thông số kỹ thuật, và có được sự chấp thuận, v.v.) nhưng nó đã không trải qua một số loại thử nghiệm chấp nhận / bán giảm giá chính thức

Hoặc chi phí khoảng 10000 đô la nếu một cái gì đó được triển khai và khách hàng chấp nhận, và bạn cần thực hiện thay đổi tại thời điểm đó (và cập nhật thông số kỹ thuật, và có được sự chấp thuận, kiểm tra lại và chạy lại sự chấp nhận và đủ điều kiện của khách hàng, v.v.)

Và chi phí sau khi triển khai / triển khai / đưa vào dịch vụ thậm chí còn nhiều hơn nữa.

Ví dụ rất nhiều và dễ hiểu chúng: một hệ thống ngân hàng với sự thay đổi phạm vi nghiêm trọng được thực hiện sau khi bạn có 25.000 nhân viên sử dụng nó sẽ tốn một gói trong thời gian đào tạo lại ... trước khi bạn thậm chí xem xét phạm vi, mã hóa, kiểm tra, hồi quy, v.v ...

NGHIÊM TÚC số dặm của bạn sẽ khác nhau: chi phí và tác động của việc thay đổi trang web thương mại điện tử làm ấm sock của Fred Nurke có phần khác với chi phí thay đổi phần mềm trên máy tính điều khiển máy bay.


1
Giả sử, bạn cung cấp mỗi tháng một bản phát hành phần mềm mới cho người dùng của bạn (hoặc chỉ là các bản vá, như MS làm điều đó cho Windows). Bây giờ hai lỗi xuất hiện, một lỗi đã được đưa vào phần mềm hai năm trước, một lỗi được giới thiệu vào tháng trước. Chi phí sửa hai lỗi đó và triển khai bản phát hành mới có thể gần như giống nhau. Chi phí sửa chữa các vấn đề gây ra bởi bất kỳ lỗi nào trong số đó có thể là một điều khác nhau, nhưng điều đó phụ thuộc rất nhiều vào chính lỗi đó.
Doc Brown

Không hoàn toàn giống như vậy - đó là sau khi vận chuyển. Chi phí sau khi vận chuyển tương tự nhau về độ lớn (tất cả đều cần cập nhật, thử nghiệm, triển khai.) Điều tôi chỉ ra ở trên là chi phí leo thang đáng kể sau khi phát hành.
quick_now

1
"hậu phát hành" là trạng thái hợp lệ đối với phần mềm nhúng, ở mức độ đối với phần mềm thu nhỏ và cũng dành cho phần mềm được phát triển theo mô hình thác nước (sai lầm!). Các loại phần mềm khác được phát triển và phát hành tăng dần, thời gian "hậu phát hành" hầu như rất nhỏ so với tuổi thọ của sản phẩm. Đây là trường hợp cụ thể cho các ứng dụng web.
Doc Brown

Nó có thể là trường hợp cho các ứng dụng web nhưng đó không phải là toàn bộ vũ trụ. Còn máy giặt thì sao? Ô tô? Tên lửa? Hệ điều hành PC? Trạm điện? PLC chạy nhà máy xi măng? Trên và trên và trên danh sách đi.
quick_now

2

Tôi không có quyền truy cập vào dữ liệu cứng hoặc sự kiện, vì vậy tôi chỉ có thể cung cấp cho bạn những quan sát giai thoại lượm lặt được từ 20 năm qua của tôi trong CNTT.

Tôi tin rằng có một sự khác biệt lớn giữa cách mà hầu hết các nhà phát triển tạo ra phần mềm ngày nay so với 20 năm trước. Với phong trào Agile đã đạt được rất nhiều động lực, đặc biệt là trong 5-6 năm qua, tôi đã thấy một sự thay đổi thực sự trong thái độ tại nơi làm việc. Nhiều đến mức chất lượng của những gì chúng ta làm dường như tăng lên theo từng bước nhảy vọt mỗi năm, và với mỗi dự án khi chúng ta áp dụng những bài học mà chúng ta đã học được từ dự án vào dự án. Các quy trình tinh gọn kết hợp với sự tập trung vào phát triển thử nghiệm đầu tiên đã phát triển từ rất gây tranh cãi đến phổ biến. Vì vậy, rất nhiều để đến với nhiều công ty ngày nay, nếu bạn không thoải mái với Agile, bạn sẽ gặp may nếu họ không cho bạn thấy cánh cửa.

Vì vậy, những gì đã có tác động này. Trước hết, tôi đã nhận thấy rằng các vấn đề thường được xác định sớm hơn nhiều. Thông thường, nếu vấn đề không quá lớn, đôi khi có thể bị hoãn vô thời hạn. Trong một số ít trường hợp, tôi đã thấy các lỗi được cho là tầm thường trở thành vấn đề nghiêm trọng khi được giải quyết sau đó, vì một số vấn đề cơ bản trở nên rõ ràng không được xem xét tại thời điểm đó. Đôi khi điều này có thể dẫn đến một chu kỳ sửa chữa rút ra và có thể tốn kém ở một mức độ nào đó, nhưng chi phí đó thường được đo lường ít hơn về mặt nguồn cung ứng và thường xuyên hơn về tác động đến mối quan hệ giữa khách hàng và nhà phát triển. Khách hàng đang dần quen với lối suy nghĩ Agile này, nó trả lại kết quả cho họ nhanh hơn nhiều so với ngày xưa, với các bước chạy phát triển lặp đi lặp lại cao và quay vòng nhanh giữa các yêu cầu và thực hiện, vì vậy họ đã mong đợi rất nhiều trong chúng ta. Và đối với các lỗi thực tế có liên quan, thời gian để sửa lỗi thường bị giảm đi rất nhiều do có một bộ kiểm tra vững chắc để hỗ trợ các thay đổi và khả năng tạo các thử nghiệm mới để cung cấp các giải pháp và hiểu biết mới đến các vấn đề được báo cáo.

Nhìn chung, có vẻ như toàn bộ nỗ lực sửa lỗi đã giảm trong hầu hết các trường hợp nếu có một bộ kiểm tra mạnh mẽ và các quy trình để đảm bảo kiểm tra vẫn là trọng tâm của những gì nhà phát triển làm, nhưng chi phí thực tế trong một số cách đã chuyển một phần ít nhất là từ việc thực hiện, sang các lĩnh vực khác của doanh nghiệp, bởi vì trong một số cách, trọng tâm cũng đã chuyển từ cung và cầu thuần túy sang quản lý quan hệ.

Một điều nữa đã trở nên rõ ràng, đó là bản năng ruột thịt của chúng ta vài năm trước cho thấy rằng Agile sẽ làm giảm chu kỳ bảo trì của chúng ta đã được chứng minh ở mức độ cả đúng và sai. Theo đúng nghĩa là kiểm thử rắn đã giúp gỡ lỗi và sửa mã của chúng tôi ở mức độ lớn dễ dàng hơn và giảm tổng số lỗi phát hành thành mã sản xuất và sai theo nghĩa là chúng tôi hiện đang làm việc chăm chỉ hơn để tránh cần phải duy trì mã kế thừa, bằng cách liên tục tái cấu trúc mã và cải thiện kiến ​​trúc sao cho chúng ta cần phát triển các sản phẩm mới hoàn toàn từ đầu.

Vì vậy, cuối cùng, điều này có nghĩa gì đối với câu hỏi của OP? Chà, điều đó có nghĩa là câu trả lời thực sự không quá khô khan như chúng ta từng nghĩ nó có thể xảy ra. 15 năm trước, tôi có thể đã trả lời câu hỏi là , nhưng bây giờ tôi cảm thấy thực tế hơn khi nói rằng thực sự quá khó để đo lường bằng thực nghiệm, bởi vì bản chất của những gì chúng tôi làm để phát triển phần mềm đã thay đổi rất nhiều so với khi chúng tôi bắt đầu tự hỏi câu hỏi của OP hồi đó. Theo một cách nào đó, chúng ta càng nâng cao các kỹ thuật và kỹ năng của mình như một ngành công nghiệp, câu hỏi càng phát triển từ một câu trả lời dứt khoát, đến mức tôi nghi ngờ rằng trong một số năm ngắn chúng ta sẽ nói rằng nó không thành vấn đề khi chúng tôi sửa lỗi, bởi vì các thử nghiệm và quy trình của chúng tôi sẽ mạnh mẽ hơn rất nhiều, thời gian sửa lỗi sẽ ít bị chi phối bởi các nỗ lực tiết kiệm ngân sách của chúng tôi và nhiều ưu tiên hơn để đáp ứng nhu cầu của khách hàng và chi phí tương đối sẽ trở nên gần như vô nghĩa theo ngữ cảnh.

Nhưng như tôi nói, đây không phải là bằng chứng hỗ trợ dữ liệu cứng, chỉ là những quan sát của tôi trong vài năm qua, và ruột của tôi nói với tôi rằng sẽ có nhiều sự khôn ngoan hơn để cải thiện cách chúng ta làm việc.


1

Các lỗi ban đầu sẽ lan truyền đến các bộ phận khác của hệ thống, vì vậy khi bạn sửa lỗi, bạn có thể buộc phải viết lại một số phần của hệ thống dựa vào chính lỗi đó.

Ngoài ra, theo thời gian, bạn sẽ biết được một số phần của chương trình được xây dựng như thế nào và bạn sẽ cần phải tự nhắc nhở mình. Đó là một dạng nợ kỹ thuật (nếu bạn vội vàng thực hiện dự án trong giai đoạn đầu, bạn sẽ gặp vấn đề với việc hoàn thành nó vì các phím tắt bạn đã thực hiện).

Nó đơn giản như vậy và không có gì để chứng minh.

Tôi nghĩ rằng bạn đang cố gắng gấp rút dự án nhanh nhất có thể để trình bày một số giải pháp làm việc cho nhân viên của bạn. Tin tốt là bạn sẽ có nó rất nhanh, tin xấu là bạn có thể sẽ không bao giờ hoàn thành nó nếu không viết lại hoàn toàn nếu bạn cứ viết tào lao nhanh nhất có thể và lên kế hoạch sửa chữa mọi thứ trong vài tháng. Bạn có thể thậm chí sẽ không thể cấu trúc lại điều này.


Vâng, tất cả đều có ý nghĩa. Mặc dù, tôi tự hỏi nếu điều này là khác biệt đáng kể với sửa chữa sau này. Vâng, bạn cần phải học lại công cụ một chút. Tuy nhiên, có lẽ bằng cách không phát hành sớm hơn, bạn đã mất nhiều tiền hơn chi phí để khắc phục vấn đề này. Điều đó sẽ làm cho vấn đề này rẻ hoặc đắt để khắc phục? Ngay cả khi nó là công việc ít hơn vì nó là lúc ban đầu?
Stefan Hendriks

2
Sửa chữa hệ thống đã phát hành phức tạp hơn nhiều. Bạn không thể chỉ viết lại cấu trúc dữ liệu chẳng hạn. Bạn sẽ cần cung cấp cho người dùng một số cách để di chuyển dữ liệu của họ. Một lần nữa, nếu bạn phát hành quá sớm, bạn sẽ gặp rắc rối, thay vì sửa lỗi, bạn sẽ lãng phí thời gian để viết mã di chuyển. Có thể bạn mất một số tiền, tốt hơn là mất khách hàng vì bán cho họ phần mềm tệ hại.
Slawek

>> ... bạn cần phải học lại công cụ một chút ... Các trường hợp cạnh đặc biệt làm cho điều này khó khăn và không tầm thường. Các tương tác bên ngoài ngay lập tức bị lãng quên nhanh chóng trừ khi bạn có một đặc tả kỹ lưỡng, chính xác và được duy trì .
DaveE

1

Chà, có lẽ tôi không thể đưa cho bạn bằng chứng dứt khoát mà bạn yêu cầu, nhưng tôi có thể liên quan đến một sự cố khá gần đây từ công việc của tôi.

Chúng tôi đã thêm một tính năng cung cấp khả năng quản lý quy trình làm việc cho sản phẩm của mình. Các công cụ tiêu biểu của BDUF, thông số kỹ thuật được ký tắt và được khách hàng chấp thuận. Thực hiện để spec. Khiếu nại từ ngày 1 khi triển khai.

Chúng tôi đã không thực hiện một hướng dẫn sử dụng thực sự với khách hàng, chỉ cần nói những gì họ muốn. Kết quả: hàng trăm giờ làm lại - phân tích, thiết kế, thực hiện và QA phải được làm lại. Tất cả vì thông số kỹ thuật bỏ lỡ trường hợp sử dụng cụ thể. Một lỗi trong đặc tả, nếu bạn muốn.

Tôi đã thấy những điều tương tự trong các công việc trước đây khi ai đó trong chuỗi đưa ra các giả định khác với các giả định của người dùng cuối. Các lỗi mã hóa thẳng tương đối dễ xử lý nếu bị phát hiện gần khi chúng xảy ra, nhưng các lỗi thiết kế có thể giết chết toàn bộ hệ thống.


1

Nếu bạn sửa lỗi sau khi phát hành, thì bạn có chi phí tìm và sửa lỗi - việc này có thể hoặc không mất thêm thời gian / chi phí để thực hiện phát hành bài. Tuy nhiên, bạn có một vòng kiểm tra Tích hợp, kiểm tra hồi quy, kiểm tra UA, các hoạt động phát hành, v.v ... sẽ cần phải được tính đến. Trừ khi sửa lỗi đi kèm với một số bản sửa lỗi khác hoặc cập nhật phiên bản, bạn sẽ có thêm chi phí cho các hoạt động kiểm tra và phát hành có thể tránh được bằng cách bao gồm sửa lỗi trong bản phát hành ban đầu - bởi vì các chi phí này sẽ được chia sẻ qua một số sửa lỗi / cập nhật / tính năng.

Cũng xem xét chi phí mà lỗi sẽ gây ra khi sử dụng, nếu chỉ là mỹ phẩm, thì có lẽ không thành vấn đề, nhưng lỗi chức năng hoặc hiệu suất có thể tạo ra chi phí với các hoạt động hỗ trợ hoặc giảm năng suất hoặc tính toán không chính xác.


1

Hỏi Intel rằng Pentium Bug có giá bao nhiêu, Ariane 5 Rocket là một ví dụ điển hình khác. Những lỗi này đã được sửa vào cuối dự án. Tôi đã làm việc trên một hệ thống trong đó "nỗ lực" phát hành phần mềm có ngân sách là 6 con số. Trong những trường hợp cực đoan này, thật dễ dàng để xem chi phí. Trong các trường hợp khác (hầu hết?), Chi phí bị che khuất bởi tiếng ồn, nhưng nó vẫn còn đó.

Không có nghi ngờ rằng lỗi tốn tiền trong khi chúng tồn tại. Một mục, báo cáo lỗi, mất thời gian để biên dịch, xử lý và đóng dưới dạng song công, thời gian là tiền bạc - do đó, một lỗi mở tạo ra chi phí liên tục. do đó, phải sửa lỗi trì hoãn có chi phí cao hơn sửa chúng sớm hơn.

Nếu một lỗi thoát ra ngoài tự nhiên, chi phí có một bước nhảy khôn ngoan ...... Là "Kết thúc dự án" trước hay sau khi phát hành phần mềm?


Lỗi phần mềm trong thế giới nhúng chắc chắn là nhiều tốn kém để sửa chữa vào cuối dự án. Hãy tưởng tượng bạn phải thu hồi xe vì một số lỗi phần mềm trong mô-đun điều khiển động cơ.
tehnyit

Các lỗi bạn đề cập không được tìm thấy sớm và do đó không được sửa sớm.

@ Thorbjørn Bạn thực sự đúng - mặc dù không tìm thấy sớm các lỗi chúng tôi đã chèn sớm (Trong trường hợp The Ariane Rocket, lỗi đã được chèn trước khi dự án thậm chí được bắt đầu, vì chúng đã sử dụng lại mã hiện có.). Chi phí tỷ lệ thuận với thời gian giữa việc chèn và sửa lỗi được triển khai, không liên quan gì khi nó được tìm thấy hoặc sửa chữa (Hầu hết các nhà phát triển xem xét nó đã được sửa khi bản vá nằm trong cơ sở mã. Lỗi không được sửa cho đến khi người dùng cuối đã cài đặt ). Tất cả điều này chỉ là IMHO mặc dù - tôi không có bằng chứng để hỗ trợ nó.
mattnz

1

Tôi đã từng đọc một bài viết có hai điểm thú vị (tiếc là các tài liệu tham khảo mà tôi có đã mất từ ​​lâu, vì vậy tôi sẽ chỉ nêu ra ở đây). Điểm đầu tiên họ đưa ra là khoảng 50% tất cả các lỗi được đưa ra trong đặc tả yêu cầu và khoảng 90% tất cả các lỗi được tìm thấy trong các bài kiểm tra UAT hoặc System.

Điểm thứ hai họ có là với mỗi giai đoạn trong mô hình V, chi phí đã tăng gấp 10 lần. Cho dù yếu tố này có chính xác hay không, tôi thấy loại không liên quan nhưng lỗi đắt nhất là khi thiết kế của bạn dựa trên giả định không chính xác. Điều này dẫn đến một số lượng lớn viết lại. Tất cả các mã hoạt động vì giả định đó nhưng không thành công khi áp dụng giả định chính xác sẽ phải viết lại.

Tôi đã trải nghiệm toàn bộ mô hình miền phải được viết lại do một giả định không chính xác trong các đặc tả yêu cầu. Nếu một lỗi như vậy được phát hiện sớm, tức là khi xem xét các thông số kỹ thuật yêu cầu, chi phí rất thấp. Trong trường hợp cụ thể này, nó sẽ mất mười dòng văn bản. Trong trường hợp được tìm thấy trong UAT (vì đây là), chi phí là rất lớn (trong ví dụ đã cho, chi phí dự án đã tăng thêm 50%)


1

Không có dữ liệu thống kê, nhưng kinh nghiệm cá nhân:

Mã điều khiển động cơ tên lửa tôi đang làm việc có một dòng như thế powerCutoff = someCondition && debugOptions.cutoffIsAllowed;. Tùy chọn mặc định là không cho phép cắt. Bản dựng 'cuối cùng' được cho là để xóa tất cả các tùy chọn gỡ lỗi, vì vậy dòng đã được sửa đổi thành powerCutoff = someCondition;.

Bạn đã bắt lỗi trong quá trình xem lại mã? Chúng tôi đã không. Lần đầu tiên tình trạng kích hoạt xảy ra trong thử nghiệm gây ra sự cắt đứt bất ngờ chỉ là vài tháng trước chuyến bay đầu tiên.

Lỗi này sẽ có giá chưa đến một giờ nếu nó bị bắt trong khi xem xét. Nó có thể mất một hoặc hai ngày nếu nó bị bắt trong quá trình tích hợp, gây ra một lần thử nghiệm lặp lại. Nếu nó bị bắt trong khi đủ điều kiện chính thức, nó có thể mất một hoặc hai tuần bằng cách gây ra một loạt thử nghiệm hoàn chỉnh khởi động lại với một bản dựng mới.

Như nó là, chi phí cân bằng. Đầu tiên chúng tôi thiết kế và chạy thử nghiệm để xác định xem đơn vị bay thậm chí có thể kích hoạt điều kiện hay không. Sau khi nó được xác định là khả năng thực sự, đã có chi phí cho kỹ thuật, quản lý và phân tích khách hàng về cách khắc phục tốt nhất, phát hành bản dựng mới, tạo và thực hiện kế hoạch kiểm tra hồi quy mới, thử nghiệm hệ thống trong nhiều đơn vị và mô phỏng. Tất cả trong tất cả nó có giá hàng ngàn nếu không phải hàng chục ngàn giờ. Cộng với 15 phút ban đầu để thực sự thay đổi mã đúng.


0

Đáng buồn thay, giống như nhiều thứ, nó phụ thuộc.

Nếu một thông báo hộp thoại bị sai chính tả, nó có thể là 'tầm thường' để sửa (chuỗi cập nhật, xây dựng lại / gói, triển khai lại). Hoặc nếu bố cục cần cập nhật, sửa đổi tệp .css có thể là đủ.

Nếu lỗi là đầu ra của một phương thức quan trọng có hơn 100 thông số kỹ thuật và bằng chứng là sai, thì việc điều tra có thể mất nhiều giờ hoặc nhiều ngày. Đây là những gì mà 'tiên đề' cũ đề cập đến, và những gì, trong số những thứ khác, TDD và nhanh nhẹn đang cố gắng tránh (thất bại sớm và rõ ràng, tiến bộ an toàn, yada).

Từ kinh nghiệm gần đây của tôi với các nhóm đa scrum trong một dự án, 'lỗi' thường là các vấn đề hợp nhất / tích hợp chỉ xuất hiện ở cuối phiên bản khi các nhánh tính năng được phát huy ổn định. Đây là những điều tồi tệ nhất, vì các cuộc xung đột thường đòi hỏi sự hỗ trợ của nhóm trong khi các đội đang ở trong tình trạng hỗn loạn để hoàn thành các mục tiêu của riêng họ, nhưng tôi không biết rằng chúng đắt hơn các lỗi khác, vì chúng xảy ra khi chúng xảy ra: vào cuối Phát hành, nhưng trong thời gian sớm nhất họ có thể. Đó là những gì làm cho họ tồi tệ nhất.

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.