2009-04-17 33 views
6

Các dấu hiệu cho thấy phần mềm sắp chết là gì?Các dấu hiệu của phần mềm chết


Làm cách nào để nhà phát triển tìm thấy cảnh báo sớm để lưu một phần mềm khỏi bị chết?

Từ quan điểm của người dùng, tôi nghĩ rằng điều đó khá rõ ràng - Những gì họ không thể sử dụng hiệu quả, họ sẽ chuyển vào thùng rác.

Ngoài ra, phần mềm có thể chết vì mã của nó - kiến ​​trúc, kiểu mã hóa, kích thước của cơ sở mã, tổ chức mã hóa và chất lượng của các lập trình viên.

Tôi muốn biết cách nghe các dấu hiệu của phần mềm chết và thực hiện các hành động khắc phục. Bất kỳ phần mềm ví dụ nổi tiếng nào đều chết vì không có nhà phát triển nào lắng nghe các dấu hiệu? Bất kỳ ví dụ về phần mềm chết đang được lưu?

Trả lời

16

Bất kỳ điều nào sau đây là rõ ràng dấu hiệu cho thấy hệ thống của bạn nằm trong danh sách các loài nguy cấp:

  • điểm duy nhất của thất bại được phép tồn tại (chỉ có một người hiểu nó)
  • Tài không được phân bổ của Ban Giám đốc để sửa chữa các khiếm khuyết
  • Không phát triển tích cực trong vòng sáu tháng
  • Không chu kỳ phát hành trong một năm
  • sản phẩm nhà cung cấp tiềm ẩn/thư viện đi ra ngoài hỗ trợ
  • Tài nguyên đưa ra một dự án và không được thay thế hơn hai lần trong một phần tư
  • thay đổi môi trường (khối lượng cao hơn của người sử dụng ví dụ) không được điều đình lại
  • Hiệu suất không đo và điều chỉnh không thường xuyên xảy ra (làm giảm hiệu suất)
  • thay đổi cơ sở hạ tầng đang hiện ra lờ mờ (OS, DB, PHẦN CỨNG)
  • người dùng đã tạo ra quanh công việc do sai sót, thất vọng, hoặc lỗi trong hệ thống của bạn
  • người dùng cơ sở đang giảm

cách để giữ cho một dự án quan trọng:

  • Tham gia quản lý của bạn một cách cởi mở và trực tiếp
  • giá Báo cáo khiếm khuyết một cách chính xác và định lượng chúng về mặt chi phí để quản lý
  • Tự động hóa càng nhiều các xây dựng, kiểm tra, các chu trình đóng gói và triển khai như bạn có thể
  • Modularize hệ thống càng nhiều càng tốt
  • Có các chỉ số rõ ràng tại chỗ và điều chỉnh ứng dụng nếu cần thiết
  • Hiểu những gì người dùng của bạn thấy là quan trọng nhất và giải quyết những nhu cầu đó

Trên thư viện phần mềm trở về từ cõi chết, tôi phải cung cấp băng đầu tiên cho số Objective-C.

+1

Điều duy nhất tôi sẽ thêm vào danh sách là khi hiệu suất trở nên quá chậm mà khách hàng rời khỏi hoặc người dùng đang phát triển các giải pháp riêng của họ trong Access hoặc Excel. – HLGEM

+0

Có vẻ như một trang từ "playbook" của BlackBerry;) – DevNull

10

Chèn trò đùa thú vị trên Windows tại đây.

Có thực sự một số dấu hiệu:

  • tăng khiếm khuyết tỷ lệ xuất hiện
  • cao hơn chi phí cho mỗi khiếm khuyết sửa chữa chi phí
  • cao hơn cho mỗi tính năng mới

Tất cả những đề nghị cao hơn entropy trong mã, tức là, một tỷ lệ tín hiệu thấp đến tiếng ồn.

Có một số cách để tấn công điều này; có lẽ cách hiệu quả nhất là xác định các mô-đun có tỷ lệ lỗi cao - lỗi có khuynh hướng có phân phối Pareto, nghĩa là 20 phần trăm của mô-đun chiếm tới 80% các lỗi. Bạn xây dựng một khung làm việc thử nghiệm cho các mô-đun này, và thực hiện lại chúng từ một trang sạch, xây dựng các bài kiểm tra tốt (sử dụng các khung kiểm thử đơn vị, v.v.), sau đó lắp chúng trở lại vào hệ thống tổng thể.

3

Không sửa lỗi nghiêm trọng sớm. Giả sử bạn gửi một phiên bản mới có lỗi ảnh hưởng đến 10% người dùng. Nếu bạn không sửa chữa nó kịp thời và gửi một phiên bản cố định, những người dùng này sẽ không thể sử dụng đầy đủ chương trình và sẽ tìm kiếm thay thế. Khi bạn cuối cùng gửi phiên bản cố định bị trì hoãn, chúng sẽ biến mất.

0

Thước đo duy nhất tính là số xuất phát từ "góc nhìn người dùng" mà bạn tham chiếu ở trên.

Các ứng cử viên có khả năng nhất là:
1. Yêu cầu hỗ trợ tăng và
2. Giảm giá.

3

Khi nhà phát triển đưa ra lý do _NOT_ để liên lạc hoặc hỗ trợ phần mềm.

0

Đọc blog này từ Jeff Atwood (một trong những tác giả của trang web này). Một đọc tuyệt vời trên một phần mềm chết.

http://www.codinghorror.com/blog/archives/001252.html

+0

Tôi đã làm và câu hỏi bắt nguồn từ việc đọc blog và quan sát một số mẫu trong vai trò quản lý của tôi. Tôi làm theo blog codinghorror. –

6

tôi tin rằng phần mềm đang hấp hối từ "lý do kỹ thuật" nội dường như bạn có trong tâm trí là tương đối hiếm. Tôi không thể nghĩ ra bất kỳ ví dụ nào; có lẽ Delphi (mặc dù đó không phải là chết, chỉ xấu ốm yếu).

Có vẻ như xa phổ biến hơn cho phần mềm để được chết vì

  • Các phần cứng hoặc hệ điều hành cơ bản trở nên lỗi thời và các phần mềm không thực hiện quá trình chuyển đổi (WordPerfect, Lotus 1-2-3)
  • Một sản phẩm cạnh tranh cung cấp tính năng vượt trội trong khi các nhà lãnh đạo thị trường trì trệ do tự mãn (Amiga)
  • phần mềm này trở nên lỗi thời qua "thay đổi mô hình" (Encarta)

Trong khi hai điểm đầu tiên có lẽ thường là một phần do lỗi của vấn đề chất lượng (làm cho nó quá chậm và tốn kém để phản ứng với những thay đổi của thị trường), thì điểm thứ hai không phải là.

+0

Điểm tuyệt vời. –

Các vấn đề liên quan