Xây dựng một để ném đi so với hiệu ứng hệ thống thứ hai

Một mặt có một lời khuyên là "Xây dựng một để vứt đi". Chỉ sau khi hoàn thành một hệ thống phần mềm và nhìn thấy sản phẩm cuối cùng, chúng tôi mới nhận ra điều gì đã sai trong giai đoạn thiết kế và hiểu cách chúng tôi nên thực sự làm nó.

Mặt khác, có "hiệu ứng hệ thống thứ hai" nói rằng hệ thống thứ hai cùng loại được thiết kế thường tồi tệ hơn hệ thống thứ nhất; có nhiều tính năng không phù hợp với dự án đầu tiên và bị đẩy sang phiên bản thứ hai thường dẫn đến quá phức tạp và quá kỹ thuật.

Không phải ở đây có một số mâu thuẫn giữa các nguyên tắc này? Quan điểm chính xác về các vấn đề là gì và đâu là ranh giới giữa hai điều này?

Tôi tin rằng những "thực hành tốt" này đã được quảng bá trước tiên trong cuốn sách bán kết The Manical Tháng của Fred Brooks.

Tôi biết rằng một số vấn đề này được giải quyết bằng các phương pháp Agile, nhưng sâu xa hơn, vấn đề vẫn là các nguyên tắc vẫn đứng vững; ví dụ, chúng tôi sẽ không thực hiện thay đổi thiết kế quan trọng 3 lần chạy nước rút trước khi đi vào hoạt động.

Xây dựng một để vứt bỏ xuất phát từ "không biết những gì bạn không biết" khi bắt đầu, vì vậy bạn học khi bạn đi những gì bạn nên làm khi bắt đầu.

Hiệu ứng hệ thống thứ hai đến từ "bây giờ biết những gì bạn chưa biết, tuy nhiên không biết những gì bạn vẫn chưa biết" tức là Hiệu ứng hệ thống thứ hai đến từ việc cố gắng xây dựng một hệ thống lớn hơn, sáng hơn, phức tạp hơn so với hệ thống đầu tiên, mà không có kiến ​​thức cần thiết khi bắt đầu - nghe rất giống những gì xảy ra với hệ thống đầu tiên.

Do đó hiệu ứng hệ thống thứ hai không mâu thuẫn. Xây dựng một hệ thống thứ hai với chức năng tương tự như hệ thống thứ nhất là (theo hiểu biết của tôi) không bao giờ được thực hiện. Hệ thống thứ hai luôn phải "tốt hơn", do đó phức tạp hơn, do đó, các vấn đề tương tự về cơ bản với hệ thống thứ nhất được mong đợi - điều đó sẽ bị loại bỏ.

Vì vậy, xây dựng một để ném đi, ném nó và xây dựng lại mà không mở rộng phạm vi và bạn sẽ không gặp vấn đề hệ thống thứ hai. (Điều này có xu hướng được thực hiện thường xuyên hơn trên các hành tinh có bầu trời tím, biển hồng và lợn bay.)

Vấn đề bạn đang đề cập có nghĩa là một số thứ đã bị bỏ qua, do đó hệ thống kết quả đã bị lỗi. Hãy để tôi mô tả một số bước còn thiếu:

Quản lý chất lượng - Làm ngay lần đầu tiên! Không bao giờ sử dụng bất kỳ hack, hoặc thỏa hiệp tạm thời. Sẽ không có làm lại cần thiết. Tất cả các tài nguyên được sử dụng hiệu quả và mọi thứ bạn làm là một đóng góp thích hợp cho dự án.

Phân tích khả thi - Khám phá nhu cầu kinh doanh. Tạo một trường hợp kinh doanh cho dự án.

Kế hoạch dự án - Xác định rõ ràng phạm vi ban đầu của bạn, lập kế hoạch cách giải pháp sẽ được phân phối, tạo đường cơ sở, bám sát kế hoạch. Đừng dành thời gian cho bất cứ điều gì không phải trên con đường quan trọng.

Yêu cầu Kỹ thuật - Khai thác các yêu cầu kinh doanh (nghĩa là nắm bắt các quy trình kinh doanh và xác định các hoạt động kinh doanh nào cần được hỗ trợ bởi hệ thống máy tính, dịch các hoạt động kinh doanh 1: 1 sang các trường hợp sử dụng hệ thống). Xác thực & xác minh! (chúng ta đang xây dựng điều đúng đắn phải không? Chúng ta đang xây dựng điều đúng không?) Tất cả các yêu cầu phải được liên kết với nhu cầu kinh doanh ban đầu.

Thiết kế phần mềm - Dịch các trường hợp sử dụng và mô hình miền thành thiết kế thành phần và kiến ​​trúc giải pháp. Tất cả các thành phần phải được liên kết với các yêu cầu từ RE.

Thực hiện - Mã phần mềm như trong thiết kế. Tất cả các mã phải được liên kết với các thành phần từ SD.

Xác thực - Kiểm tra đơn vị, kiểm tra tích hợp, hiệu suất, ... (tất cả các trường hợp sử dụng từ RE bây giờ sẽ cần phải được kiểm tra)

Đây là một số khía cạnh chính của một quy trình phần mềm. Các hoạt động được đề cập là một phần của Kỹ thuật phần mềm. Đây là cách bạn xây dựng giải pháp phần mềm phù hợp cho nhu cầu kinh doanh thực sự và bạn xây dựng nó đúng thời gian, dựa trên ngân sách, để đặc tả.

Tra cứu các điều khoản này để xây dựng phần mềm tốt hơn và để có được nó ngay lần đầu tiên:

• Phân tích khả thi (đặc biệt là cách xây dựng trường hợp kinh doanh)
• Quản lý dự án (đặc biệt là Kế hoạch dự án và Đăng ký rủi ro với giảm thiểu rủi ro)
• Yêu cầu Kỹ thuật (khơi gợi, phân tích, đặc điểm kỹ thuật, xác nhận)
• Thiết kế phần mềm (UML và kỹ thuật phần mềm dựa trên thành phần)
• Xây dựng phần mềm (mẫu thiết kế, khung, lập trình phòng thủ)
• Xác nhận phần mềm (kiểm tra đơn vị, UAT, v.v.)