Có thể tạo Tài liệu Thiết kế Phần mềm sau khi phát triển được không?


11

Tôi hiện đang làm việc để tốt nghiệp cho các nghiên cứu "Phát triển phần mềm" của mình, trong đó tôi phải phát triển phần mềm phức tạp riêng lẻ trong một công ty bên ngoài. Tất cả điều này cần phải được thực hiện một cách có cấu trúc, tạo ra tất cả các tài liệu tương ứng.

Đối với dự án này, tôi đã chọn làm việc với các tài liệu tiêu chuẩn của IEEE: Tài liệu yêu cầu phần mềm (SRS), Tài liệu kiến ​​trúc phần mềm (SAD) và Tài liệu thiết kế phần mềm (SDD). Mặc dù được dạy khác ở trường, đối với dự án này, tôi đã chọn tạo SDD sau khi phát triển (thay vì trước đó). Lý do của tôi là:

Công ty nơi tôi thực tập đã cho tôi hướng dẫn để tạo ra một phần mềm phức tạp, đáp ứng một số yêu cầu nhất định, theo cách thử nghiệm. Do số lượng tự do mà họ đã cho tôi trong định nghĩa dự án, gần như không có gì là chắc chắn trước đó và tốt nhất có thể gặp phải khi thử nghiệm trong quá trình phát triển. Ngoài ra, tôi đang tạo phần mềm theo cách riêng lẻ , nó sẽ không có lợi cho bất kỳ ai khác trong công ty để tôi thực hiện Thiết kế phần mềm này trước đó. Làm điều đó trước sẽ chỉ khiến tôi mất rất nhiều thời gian để thay đổi nó sau này, vì tôi có thể chắc chắn rằng với những điều không chắc chắn trong dự án, thiết kế mà tôi thực hiện trước đó sẽ phải thay đổi rất nhiều . Điều này cảm thấy phản tác dụng với tôi.

Đây có phải là một biện minh tốt để tạo SDD sau khi phát triển? Nếu không, sẽ có bất kỳ biện minh tốt cho điều đó?

Chỉnh sửa: Lý do để tạo SDD sau đó sẽ là để các nhà phát triển trong tương lai tiếp tục dự án. Tôi sẽ không thể hoàn thành toàn bộ dự án trong thời gian tốt nghiệp của mình, vì vậy các nhà phát triển khác sẽ phải tiếp tục với cơ sở mã hiện tại.


2
Nếu bạn phải thay đổi SDD "rất nhiều" trong / sau khi phát triển, thì có lẽ nó có quá nhiều chi tiết.
Freedomn-m


Trứng hoặc gà - thứ xuất hiện đầu tiên là thứ mà các nhà triết học dành nỗ lực. SDD và phần mềm hoàn chỉnh (phức tạp) phải giống nhau, chúng phát triển cùng nhau.
mattnz

Đối với tôi nó không hoạt động để tài liệu sau đó. Nó quá nhàm chán với tôi. Tôi cần phải viết trong khi tôi đang thiết kế. Phác thảo SDD cũng là một loại vịt cao su: bạn cần giải thích thiết kế và điều đó sẽ phát hiện ra vấn đề sớm.
jos

Câu trả lời:


17

Trong thiết kế phần mềm IEEE Std 1016 Phần 3.1 theo ngữ cảnh, bạn có thể tìm thấy đoạn này:

Một SDD có thể được chuẩn bị và sử dụng trong nhiều tình huống thiết kế. Thông thường, SDD được chuẩn bị để hỗ trợ phát triển một mục phần mềm để giải quyết vấn đề, trong đó vấn đề này đã được thể hiện dưới dạng tập hợp các yêu cầu. Nội dung của SDD sau đó có thể được truy tìm theo các yêu cầu này. Trong các trường hợp khác, SDD được chuẩn bị để hiểu một hệ thống hiện có thiếu tài liệu thiết kế. Trong các trường hợp như vậy, một SDD được chuẩn bị sao cho thông tin quan tâm được nắm bắt, tổ chức, trình bày và phổ biến cho tất cả các bên quan tâm. Thông tin quan tâm này có thể được sử dụng để lập kế hoạch, phân tích, triển khai và phát triển hệ thống phần mềm, bằng cách xác định và giải quyết các mối quan tâm thiết kế thiết yếu.

Các tác giả của IEEE Std 1016 nhận ra rằng SDD có thể không được tạo trước. Người ta có thể được tạo sau khi hệ thống phần mềm tồn tại để nắm bắt thông tin cho các bên quan tâm.

Mục 1.1 Phạm vi cũng cung cấp một số thông tin thú vị:

Tiêu chuẩn này không quy định các phương pháp cụ thể cho thiết kế, quản lý cấu hình hoặc đảm bảo chất lượng.

Trong bối cảnh của câu hỏi này, các từ khóa là "quản lý cấu hình". Quản lý cấu hình không chỉ áp dụng cho hệ thống phần mềm được tạo, mà bất kỳ tài liệu liên quan nào.

Trong tình huống cá nhân của bạn và trong nhiều tình huống, việc tạo SDD lên phía trước là một sự lãng phí. Câu trả lời của David Arno gần giống như những gì tôi sẽ xem là câu trả lời đúng. Thiết kế thực sự của hệ thống phần mềm của bạn là mã. Tuy nhiên, bạn "tạo SDD trước" hoặc "tạo SDD sau" không phải là lựa chọn duy nhất của bạn. Bạn có tùy chọn thứ ba - phát triển SDD với hệ thống phần mềm.

Nếu bạn đang tuân theo một tiêu chuẩn, chẳng hạn như IEEE Std 1016, bạn có các yêu cầu đối với SDD. Cụ thể, Phần 4 của tiêu chuẩn này xác định nội dung mà bạn có. Khi bạn làm việc thông qua các quyết định thiết kế, hãy bắt đầu tạo các quan điểm, quan điểm và lớp phủ khác nhau. Khi bạn đưa ra quyết định, nắm bắt cơ sở thiết kế cho họ.

Điều này sẽ cho phép các bên quan tâm theo dõi sự phát triển của thiết kế phần mềm mà không cần phải đào sâu vào mã. Tất nhiên, mọi người có thể có ý kiến ​​hoặc đề xuất. Nếu bạn đang cập nhật SDD, họ có thể theo dõi tiến trình của bạn và đưa ra phản hồi về cách tiếp cận sớm, sau đó bạn có thể kết hợp vào sản phẩm cũng như SDD. Khi bạn chuyển khỏi dự án, nếu mã phần mềm và SDD đồng bộ, ai đó sẽ có thể dễ dàng lên tàu và nhận công việc.


Tôi thực sự nhầm lẫn ISO và IEEE, nó thực sự phải là IEEE. Cảm ơn bạn đã trích dẫn một số ý kiến ​​từ chính các tác giả của IEEE Std. Tùy chọn "thứ ba" này thực sự là lựa chọn tốt nhất. Thật tệ, chúng tôi không bao giờ dạy nó theo cách đó.
Simon Baars

@SimonBaars Tôi không ngạc nhiên. Nếu bạn được dạy về các tiêu chuẩn, chẳng hạn như các tiêu chuẩn của IEEE và ISO, thì hầu như luôn luôn trong bối cảnh thác nước / điều khiển theo kế hoạch. Khi bạn tìm hiểu về các phương pháp phát triển lặp và tăng dần, bạn có xu hướng không tìm hiểu về các tiêu chuẩn này. Tuy nhiên, các phiên bản mới hơn của các tiêu chuẩn IEEE có xu hướng xem xét các phương pháp lặp và tăng dần (nhanh nhẹn) và chúng thường có thể được áp dụng ngay cả trong các môi trường này.
Thomas Owens

8

Nếu tất cả những gì bạn đang tìm kiếm từ SDD là để giao tiếp thiết kế với người khác, thì có, bạn có thể tạo nó sau khi phát triển. Chỉ có điều, sau đó nó được gọi là tài liệu.

Tuy nhiên, tôi muốn chỉ ra rằng SDD cũng có thể phục vụ mục đích khác. Nó cũng có thể giúp bạn suy luận về thiết kế và đảm bảo bạn "thất bại nhanh". Đây là một điều tốt, đặc biệt là nếu nhiều thứ không chắc chắn trước đó bởi vì bạn có thể loại bỏ các phương pháp không hoạt động trong toàn bộ quá trình thực hiện sớm. Nó cũng có thể ngăn bạn sớm tập trung vào các chi tiết kỹ thuật, bằng cách không mã hóa bất cứ điều gì cho đến khi bạn tìm ra thiết kế.

Tôi khuyên bạn ít nhất nên thực hiện một nỗ lực tại SDD trước đó. Nếu bạn gặp phải những điều mà bạn không chắc chắn mọi thứ sẽ hoạt động như thế nào, thì bạn có thể tạo ra những nguyên mẫu nhỏ cho những vấn đề bạn đang cố gắng giải quyết. Điều này sẽ cung cấp cho bạn kinh nghiệm trong việc giải quyết các vấn đề cụ thể cho dự án của bạn, điều này sẽ có lợi cho chất lượng của giải pháp hoàn chỉnh trong thời gian dài.


SDD sẽ được gọi là gì nếu được tạo trước và duy trì trong suốt dự án?
Simon Baars

Chỉ là SDD :)
Jonathan van de Veen

Bạn có đề nghị đổi tên nó để tránh sự hiểu lầm của các giám sát viên?
Simon Baars

Những loại hiểu lầm mà bạn đang mong đợi sẽ xảy ra?
Jonathan van de Veen

8
@SimonBaars: có thực sự như vậy một sự khác biệt lớn giữa "Thiết kế phần mềm Document" hoặc "Phần mềm thiết kế tài liệu ation "?
Doc Brown

2

Tài liệu thiết kế chi tiết thực sự mà bạn sẽ tạo là mã. Nó chính xác cho trình biên dịch biết cách xây dựng ứng dụng của bạn. Như vậy, thiết kế của bạn không thể hoàn thành cho đến khi bản dựng cuối cùng trước khi vận chuyển.

Bất kỳ tài liệu thiết kế nào khác mà bạn tạo, chẳng hạn như SDD, sẽ cần cập nhật sau khi bạn hoàn thành thiết kế (mã). Do đó, có một lý do thuyết phục để viết SDD sau đó: bạn chỉ phải thực hiện một lần.

Đối trọng rõ ràng với điều này là, "bạn có thường xuyên viết SDD sau sự kiện này không? Ứng dụng được vận chuyển, do đó bạn không muốn dành thời gian làm tài liệu ở giai đoạn đó. Nhưng điều này áp dụng như nhau để cập nhật một cái hiện có. Điều nào tệ hơn, không có SDD hay SDD nào sai và không đáng tin?

Có hai lý do để viết nó trước mặc dù. Đầu tiên, nó có thể là một yêu cầu bắt buộc đối với bạn để làm như vậy (không hay; nhưng nó xảy ra). Thứ hai, tạo một tài liệu như vậy có thể giúp bạn xây dựng một chiến lược tổng thể cho thiết kế. Nhưng điều đó có thể làm tốt như nhau bằng cách vẽ hình ảnh, ghi chú nguệch ngoạc vv một cách không chính thức. Và vì nó sẽ cần viết lại sau này, có rất nhiều lợi ích cho cách tiếp cận "nhanh và bẩn" đối với quy trình thiết kế vĩ mô đi trước đó.


The app is shipped, so you aren't likely to want to spend time documenting at that stage. Trong trường hợp này, ứng dụng sẽ không được hoàn thiện trong thời gian tốt nghiệp của tôi, vì vậy chúng tôi cần tài liệu cho các nhà phát triển khác để có thể tiếp tục phát triển sản phẩm.
Simon Baars

0

Đối với tôi, nó sẽ không phải là một cuộc tranh luận tốt.

Nếu thực sự cần thiết, tôi sẽ tranh luận với sự tập trung mạnh mẽ vào phát triển nguyên mẫu để hiểu rõ hơn về một miền có vấn đề chưa biết. Tuy nhiên, ngay cả trong những trường hợp đó, một số phần của thiết kế sẽ hữu ích trước đây.


0

Có một trường hợp được thực hiện để làm điều đó lên phía trước nào . Bởi vì bạn đang làm điều này để tìm hiểu về việc viết tài liệu như thế này. Bỏ qua công việc này bởi vì nó có thể không cần 100% ở đây có nghĩa là bạn bỏ qua việc học.

Một sự thỏa hiệp có thể là viết nó trong khi thực hiện. Trước mỗi thành phần / mô-đun / màn hình hoặc phân mục khác của chương trình của bạn, bạn cần suy nghĩ về cách bạn sẽ thực hiện nó. Sau đó, bạn thêm các quyết định của bạn vào tài liệu thiết kế của bạn và sau đó thực hiện chúng.

Nếu bất cứ điều gì thay đổi sau đó, bạn cập nhật tài liệu.

Điều này có một số lợi thế so với viết sau khi thực tế:

  • Bạn sẽ học cách cập nhật tài liệu thiết kế khi yêu cầu thay đổi, một thói quen hữu ích

  • Bạn sẽ học cách suy nghĩ về thiết kế trước khi thực hiện

  • Nó không nhàm chán đến mức nhàm chán như viết tài liệu thiết kế sau khi thực tế là

  • Nếu bạn hết thời gian, bạn sẽ có một tài liệu thiết kế mô tả những gì bạn có cho đến nay để người khác có thể tiếp tục công việc của bạn

  • Nó không phải là làm thêm nhiều theo cách này

  • Khi dự án của bạn tiếp tục, bạn có thể không chắc chắn về lý do tại sao chính bạn đã làm điều gì đó hai tháng trước, và bạn sẽ có ghi chú của bạn để nói với bạn.


-2

Tài liệu thiết kế hệ thống, bản ghi các yêu cầu cơ bản cộng với (các tính năng mới) cập nhật khi dự án tiến lên phía trước với các thuộc tính giải pháp và thiết kế mới. Duy trì cho đến khi dự án / giải pháp đã được giao. Hữu ích, nó truyền đạt cho tất cả các liên quan.

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.