Cần lập kế hoạch gì trước khi bắt đầu phát triển dự án? [đóng cửa]

Giả sử tôi đã nhận được các thông số kỹ thuật cho một dự án từ một khách hàng và bây giờ là lúc bắt đầu phát triển nó. Thông thường, tôi chỉ bắt đầu với mô-đun đầu tiên (thường là đăng ký người dùng) và sau đó đi từ mô-đun này sang mô-đun tiếp theo. Tôi chỉ lập kế hoạch trong đầu ngay trước khi tôi bắt đầu mô-đun hoạt động như thế nào, nhưng không có kế hoạch trước đó.

Tuy nhiên, tôi nghĩ sẽ tốt hơn nếu tôi xem qua thông số kỹ thuật và lên kế hoạch hệ thống sẽ hoạt động như thế nào trước khi tôi mã hóa nó, ví dụ các thành phần chính là gì, chúng sẽ tương tác như thế nào, v.v. không chắc chắn chính xác những gì tôi nên lập kế hoạch.

Để cho một ý tưởng tốt hơn về những gì tôi đang yêu cầu, tôi nên-

a) Chia dự án thành các thành phần,

b) Lập kế hoạch tương tác của họ, ví dụ tôi có nên làm sơ đồ lớp, viết bài kiểm tra đơn vị, v.v.?

Có ý kiến ​​gì không?

Khi bạn có đặc quyền bắt đầu một dự án mới, bạn có một khung vẽ trống - điều này vừa thú vị vừa gây nản lòng cùng một lúc. Tôi làm việc trong các lần lặp và đây là cách tôi phân chia công việc:

• Bắt đầu với các mục tiêu cho dự án. Mục tiêu nhất thiết là mơ hồ nhất, nhưng giúp bạn tập trung vào những gì khách hàng hoặc người dùng dự định làm với phần mềm. Vào cuối ngày, bạn muốn thỏa mãn những mục tiêu đó - ngay cả khi điều đó có nghĩa là bỏ đi một số tính năng thực sự thú vị.
• Sau đó, tôi bắt đầu chia ứng dụng thành các tên miền phụ. Có lẽ có hàng trăm cách khác nhau để làm điều này, đó là lý do tại sao chúng ta bắt đầu với các mục tiêu dự án. Chúng tôi muốn chia nhỏ ứng dụng thành một số hệ thống con liên quan hỗ trợ các mục tiêu đó. Điều này giúp chúng tôi tập trung vào nhiệm vụ tiếp theo.
• Xác định cách thức và thời điểm các hệ thống con cần tương tác. Chúng tôi không xử lý các chi tiết, chỉ là thông tin cấp cao để đảm bảo chúng tôi có một hệ thống tích hợp các hệ thống con. Bạn cần một ý tưởng chung về điều này để bạn có thể đưa ra các chi tiết hỗ trợ các mục tiêu chung cho dự án.
• Chỉ cung cấp chi tiết cho hệ thống con tôi đang làm việc tại thời điểm này (tương tự như chiến lược hiện tại của bạn). Tôi đã biết hệ thống con này cần tương tác với các hệ thống con khác như thế nào, nhưng tôi có thể cần phải tìm ra một vài lựa chọn thay thế để nó có ý nghĩa nhất. Mỗi hệ thống con được phân tách bằng một giao diện, vì vậy tôi có thể điều chỉnh việc thực hiện càng nhiều càng tốt mà không phá vỡ toàn bộ hệ thống.
• Xem lại cách mọi thứ được triển khai trong hệ thống con hiện tại của tôi so với cách nó được triển khai trong các hệ thống con khác. Mọi cách tiếp cận không nhất quán là điều người dùng phải học. Sẽ ổn thôi nếu chúng ta đang nói về một khái niệm hoàn toàn mới. Vì khả năng sử dụng, chúng tôi không muốn có 5 cách khác nhau để xóa thông tin hiện tại đơn giản vì chúng tôi lười biếng. Sử dụng lại các yếu tố giao diện người dùng giống nhau là cách nhanh nhất để làm cho ứng dụng trực quan hơn. Học ba khái niệm dễ hơn nhiều so với học 20.

Về cơ bản, cách tiếp cận xác định dần dần một dự án từ mức rất cao đến thiết kế chi tiết hơn đã phục vụ tốt cho tôi. Ngay cả các tương tác giữa các hệ thống con cũng được tinh chỉnh khi bạn thực sự cố gắng thực hiện chúng. Đó là một điều tốt.

Tôi nghĩ sẽ tốt hơn nếu tôi xem qua thông số kỹ thuật

Đúng. Ý tưởng tốt.

lên kế hoạch hệ thống sẽ hoạt động như thế nào trước khi tôi mã hóa nó.

Tốt Làm nhiều hơn thế.

các thành phần chính là gì,

Thông minh.

họ sẽ tương tác như thế nào

Chính xác.

Tôi chỉ không chắc chắn chính xác những gì tôi nên lập kế hoạch.

Làm thế nào bạn có thể không chắc chắn khi bạn đã liệt kê một loạt các công cụ? Nếu đó là những điều liên quan đến bạn, tại sao không chỉ tập trung vào những điều đó?

Đọc mô hình xem 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Arch Architectural_View_Model

Đọc về khung Zachman: http://en.wikipedia.org/wiki/Zachman_Framework

Đó là những gì bạn cần lập kế hoạch.

Làm thế nào tôi nên a) Chia dự án thành các thành phần,

Sử dụng các mẫu thiết kế được áp dụng rộng rãi cho các dự án tương tự khác.

Khi nghi ngờ, hãy đọc bản thiết kế J2EE để biết ý tưởng.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

Làm thế nào tôi nên b) Lập kế hoạch tương tác của họ, ví dụ tôi có nên làm sơ đồ lớp, viết bài kiểm tra đơn vị, vv ..?

Đúng. Ý tưởng tốt, tất cả.

Điều quan trọng nhất cần làm: xem xét các thông số kỹ thuật, tương tác với khách hàng để có được thông số kỹ thuật tinh tế hơn.

Các yêu cầu chắc chắn là không đầy đủ, mơ hồ hoặc không chính xác. Sự lãng phí lớn nhất của thời gian là làm sai. Khách hàng không phải là những người thiết kế phần mềm chuyên nghiệp và không thể hy vọng sẽ giỏi trong việc phát triển một tập hợp các yêu cầu tốt.

Vì vậy, bạn nên xem lại thông số kỹ thuật, phỏng vấn khách hàng và tìm hiểu xem đây có phải là thứ anh ấy / cô ấy thực sự cần và muốn, và có đủ khả năng, v.v.

Phát triển các trường hợp thử nghiệm / sử dụng và xem xét với khách hàng. Nếu một yêu cầu không thể kiểm chứng, hãy ném nó ra.

Phát triển thiết kế và đảm bảo nếu tất cả các mảnh hoạt động chính xác mà theo lý thuyết nó sẽ làm những gì bạn cần.

Phát triển một nguyên mẫu kiến ​​trúc kiểm tra tất cả các công nghệ được sử dụng trong mọi lớp mà bỏ qua chức năng. Bạn đang thử nghiệm kiến ​​trúc, không phải là đặc điểm kỹ thuật chức năng. Có kiến ​​trúc sai sẽ có nghĩa là bạn phải viết lại mọi thứ, vì vậy việc có được kiến ​​trúc đúng là rất quan trọng. Hãy chắc chắn rằng nó có thể đáp ứng yêu cầu của bạn về tốc độ, hiệu quả, bảo mật, v.v.

Bạn chắc chắn muốn có một số thiết kế tại chỗ trước khi bạn bắt đầu viết mã.

Khi bạn đã có điều đó, tôi thường thích thực hiện giai đoạn kiến ​​trúc ban đầu trước tiên để xác định cách các lớp ứng dụng của bạn khớp với nhau. Điều này sẽ bao gồm các công cụ xương sống như bảo mật và đăng nhập.

Sau đó, tôi xây dựng 1 tính năng từ trên xuống dưới để bạn thực hiện một cái gì đó hoàn toàn.

Rồi đi từ đó.

Mọi điều

Lập kế hoạch cho tất cả, dễ dàng thay đổi nó trên giấy hơn một phần của nó đã được mã hóa, bạn có được một cơ sở tuyệt vời cho tài liệu và nhiều lợi ích khác.