Giải quyết các lỗi sẽ mang lại lợi ích chi phí lớn nhất [đóng]

Tôi muốn có một ý tưởng về việc phân loại các lỗi dựa trên việc giải quyết nó dễ dàng như thế nào và nó sẽ mang lại cho tôi bao nhiêu lợi ích. ví dụ: nếu có một lỗi sẽ mất một giờ (đóng tệp kép, v.v.) để giải quyết so với lỗi khác mất một ngày (lỗi phân đoạn). Nhưng nếu việc giải quyết lỗi đầu tiên không quan trọng lắm, thì có lẽ tôi sẽ làm việc với lỗi thứ hai.

Có tài liệu nghiên cứu nào phân loại lỗi dựa trên lợi ích chi phí hoặc số liệu tương tự không?

Giả sử có thể phân loại lỗi dựa trên các đặc điểm lỗi, ví dụ như lỗ hổng bảo mật, lỗi bộ nhớ, lỗi logic, v.v. Ở khía cạnh khác, có thể có các tham số như độ khó (dễ, trung bình, khó). Có kích thước khác tôi nên tìm kiếm. Để đơn giản hóa mọi thứ, tôi có thể giả sử hai điều:

1. Mọi lập trình viên trong nhóm đều có khả năng giải quyết bất kỳ lỗi nào như nhau
2. Không có thời hạn

Hệ thống theo dõi lỗi điển hình có hai, có thể ba trường xác định tỷ lệ lợi ích chi phí lỗi:

1. Ưu tiên (được chỉ định bởi chủ doanh nghiệp)
2. Mức độ nghiêm trọng (phân loại lỗi - quan trọng đến thấp)
3. Giờ dự kiến ​​(dự đoán sẽ mất bao lâu để làm)

Như bạn lưu ý, điều này không xác định lỗi nào là lỗi quan trọng.

Hệ thống được đưa ra trong PEF / REV: Một số liệu theo dõi lỗi đa chiều bổ sung thêm thông tin về các thành phần kinh doanh và nhà phát triển để lợi ích chi phí lỗi.

Tất cả các giá trị nằm trên thang 1 .. N (cùng giá trị trên cùng cho mỗi).

PEF được xác định bởi doanh nghiệp:

• P ain - Con bọ đau đến mức nào
• E ffort - Mất bao nhiêu nỗ lực để khắc phục lỗi
• Yêu cầu F - Mức độ thường xuyên xảy ra lỗi

REV đến từ nhà phát triển:

• R isk - Cách khắc phục rủi ro cho hệ thống
• E ffort - Có bao nhiêu nỗ lực để sửa lỗi
• Khả năng xóa V - Dễ dàng xác minh sửa lỗi

Ví dụ, nếu bạn gặp sự cố hiếm khi xảy ra, dễ dàng khắc phục (bật tự động lưu), đó có thể là PEF là 7.1,1 (điểm 9). Trong khi sửa lỗi, nó có thể liên quan đến thay đổi mô-đun lõi và có REV là 9,3,2 (điểm 14).

Mặt khác, bạn có thể có một sự phiền toái luôn luôn tồn tại (3,3,9 - điểm 15) có một sửa chữa tầm thường (1,1,3 - điểm 5).

Trong ví dụ này, sự khó chịu có vẻ là một điều tốt hơn về chi phí / lợi ích để làm việc.

Vấn đề bạn đang mô tả là rất phổ biến và câu trả lời tốt nhất có thể là "sử dụng cảm giác ruột của bạn".

Tôi thường chia các lỗi theo ba loại: Sự cố, Làm phiền, Mỹ phẩm (chúng có thể được gọi là 1, 2, 3 - điều đó không thực sự quan trọng) và sau đó đưa ra ước tính tổng thể về thời gian cần thiết để sửa mọi lỗi (tất cả các lỗi phải có một ước tính cập nhật thô mọi lúc).

Khi giải quyết các lỗi Crashing> Annoying> Cosmetic và sau đó tôi chỉ cần thực hiện một "công việc ngắn nhất trước" để có được thông lượng ban đầu càng nhiều càng tốt.

Tôi thấy RẤT khó để tính bất kỳ loại lợi ích tài chính trực tiếp nào từ việc giải quyết bất kỳ lỗi nào - trừ khi đó là một công việc được trả lương rất chặt chẽ.

Một lưu ý bạn có thể cần là bạn thực sự nên sống đến điểm thứ năm trong Bài kiểm tra Joel - điều này có thể bị ảnh hưởng bởi quy mô nhóm và phân phối giữa các vấn đề "địa phương" khác - nhưng nói chung đó là một dấu hiệu của thực tiễn tốt.

Một xem xét khác có thể là loại thử nghiệm hoặc tổ chức thử nghiệm phát hiện ra lỗi, khi cố gắng xác định tác động và chi phí của lỗi và sửa lỗi. Kiểm tra đơn vị hoặc chức năng có thể chỉ ra một cái gì đó trong thiết kế cần phải thay đổi, và do đó sửa sớm sẽ dễ dàng hơn và ít tốn kém hơn sau này. Kiểm tra hệ thống hoặc tích hợp có thể chỉ ra điều gì đó ảnh hưởng đến nhiều khách hàng hơn. Và kiểm tra tiêu chuẩn, trong khi thường là một điều gì đó không quan trọng đối với một tập hợp lớn khách hàng, có thể dẫn đến mất chứng nhận nếu không được sửa chữa và có tác động tiêu cực đến doanh nghiệp.

Điều đó nói rằng, chỉ vì một tổ chức kiểm tra cụ thể có lỗi kiểm tra không nên tự động tạo ra lỗi "nghiêm trọng". Ví dụ, có thể có một sự cám dỗ để nói điều gì đó như "tất cả các kiểm tra hệ thống phải vượt qua trước khi vận chuyển, do đó, bất kỳ kiểm tra hệ thống nào tự động không dẫn đến một lỗi nghiêm trọng / nghiêm trọng." Hy vọng rằng không có tổ chức nào đưa ra tuyên bố đó (tiêu chí thoát kiểm tra tốt là một cuộc thảo luận khác), nhưng vấn đề là "mức độ nghiêm trọng" của lỗi nên được đánh giá về tác động của nó đối với khách hàng, sản phẩm hoặc hình ảnh công ty thay vì ở đâu hoặc khi nào được phát hiện.

Một cách có thể để giải quyết đó là phân biệt giữa "mức độ nghiêm trọng" và "mức độ khẩn cấp". Ví dụ, khi ngày phát hành gần đến, có thể có áp lực thời gian để xác định xem một lỗi rõ ràng có mức độ nghiêm trọng thấp hơn có thể ảnh hưởng đến một tập hợp lớn khách hàng hay không, khiến cho lỗi này trở nên "cấp bách" hơn và nâng cao công việc đối với lỗi đó ở trên (một số) khác ít nhất cho đến khi quyết định đó có thể được thực hiện. Một sự cân bằng hợp lý giữa hai người, cùng với kinh nghiệm và phán đoán tốt, sẽ giúp định hướng nơi dành thời gian và công sức.

Ngoài những gì người khác đã nói về việc phân loại các lỗi, v.v., cũng xem xét việc xem xét Khớp nối liên kết (Ca) để xác định mức độ nghiêm trọng mà một lỗi cụ thể có thể đại diện. Nếu bạn có một lỗi trong một mô-đun có số lượng Ca cao, tôi có thể xem xét sửa lỗi đó trước vì nó có thể mang lại lợi ích cho các thành phần khác trong hệ thống. Ca giúp bạn xác định mức độ trách nhiệm và các mô-đun có trách nhiệm với các lỗi trong đó làm tổn thương toàn bộ ứng dụng (đọc thêm về Ca tại đây: http://www.ibm.com/developerworks/java/l Library / j-cq04256 / index.html ).

Với ý nghĩ đó, chúng tôi có xu hướng phân loại lỗi và ưu tiên chúng dựa trên tác động của chúng đối với khách hàng. Khách hàng của bạn sẽ thay đổi, nhưng việc họ tham gia vào cuộc thảo luận cuối cùng sẽ thúc đẩy những lỗi nào cần được khắc phục so với những người khác. Điều đó không thực sự khoa học, nhưng với tư cách là một nhóm chúng tôi có xu hướng thống nhất về mức độ ưu tiên và phân loại lỗi, mọi người đều có ý kiến ​​về "những cái lớn" (tất cả các bên liên quan đều có thể đưa ra đầu vào), và chúng tôi xếp chồng lên nhau từ đó.

Bạn không thể xác định chi phí thực tế của tất cả các lỗi. Một số bạn có thể, đối với nhiều người, rất khó để định lượng. Ví dụ: giả sử bạn có một lỗi dẫn đến tất cả các văn bản trên các nút bị sai lệch một chút. Nó làm cho sản phẩm 1.0 của bạn trông hơi cẩu thả. Điều này không khiến chương trình của bạn bị sập hoặc người dùng của bạn bị mất dữ liệu. Có lẽ là một lỗi khá rẻ, phải không?

Bây giờ, điều gì sẽ xảy ra nếu mọi khách hàng của bạn nhận thấy vấn đề này và mọi người đánh giá đều đề cập đến vấn đề đó trong các đánh giá về sản phẩm của bạn. Và nếu lỗi này xảy ra từ phiên bản 1.0 đến 1.1 và 1.2. Công ty của bạn bây giờ có thể có tiếng là hơi cẩu thả trong kiểm soát chất lượng. Lỗi đơn giản này có thể đắt đến mức nào về doanh số bị mất tiềm năng cho công ty của bạn cho các sản phẩm trong tương lai? Hoặc, điều này có thể ảnh hưởng đến đánh giá mà sản phẩm của bạn nhận được - sản phẩm của bạn có thể đáp ứng hoàn hảo nhu cầu của khách hàng, nhưng chỉ nhận được 9 trên 10 vì nó trông hơi cẩu thả.

Vì vậy, bạn không chỉ cần xem xét chi phí của một lỗi cụ thể về chi phí phải sửa và nó ảnh hưởng trực tiếp đến người dùng, mà bạn phải xem xét nó trong bối cảnh lớn hơn về cách nó ảnh hưởng đến nhận thức về sản phẩm của bạn trên thị trường, và nhận thức đó ảnh hưởng đến doanh số trong tương lai như thế nào.

Điều này có vẻ xa vời nhưng nó không. Tại thời điểm tôi viết bài này, bạn có thể truy cập một trang web khác trên web có bài viết về cách Apple đã di chuyển "1" trên biểu tượng lịch của họ qua một hoặc hai pixel. Nếu bạn thực hiện tìm kiếm, bạn sẽ thấy một số bài viết tiêu cực về lỗi nhỏ này. Tất nhiên, điều này không ảnh hưởng trực tiếp đến lợi nhuận của Apple, nhưng họ tự quảng cáo là đỉnh cao của thiết kế tốt, do đó, có một lỗi thiết kế ảnh hưởng đến nhận thức đó, dù chỉ một chút.