Giữ sơ đồ Kiến trúc logic và Vật lý được cập nhật


11

Trong bất kỳ dự án phát triển phần mềm nào liên quan đến các hệ thống phân tán có nhiều nhà phát triển, có sơ đồ Kiến trúc logic và Vật lý là cách tốt nhất nhưng theo kinh nghiệm của tôi, các sơ đồ này luôn bắt đầu được duy trì tốt khi bắt đầu dự án nhưng không được cập nhật khi dự án được phát hành và các giai đoạn bảo trì đá vào.

Đối với các dự án phức tạp có nhiều quy trình phân tán, các sơ đồ có xu hướng bị lỗi thời hoặc không chính xác thực sự nhanh chóng ngay cả trước khi phát hành ban đầu vì không ai có tất cả kiến ​​thức.

Dựa trên nền tảng này, tôi muốn hỏi các câu hỏi sau đây cho cộng đồng:

  1. Làm thế nào quan trọng là có sơ đồ Kiến trúc logic và Vật lý chính xác và cập nhật?
  2. Có công cụ và quy trình nào có thể giúp cập nhật chúng không?
  3. Ai nên chịu trách nhiệm cho việc cập nhật chúng? Làm thế nào để quản trị viên, nhà phát triển và nhóm QA có thể đóng góp?


Bài báo cho thấy rằng đây nên là một phần của "tài liệu có thể giao được" để nó được coi trọng. Đây có nên là các mục được tạo ra như là một phần của tồn đọng và là một phần của việc giao hàng không?
ARau

Câu trả lời:


5

Tôi sống trong thế giới thực với các hạn chế về thời gian và các vấn đề tài nguyên, vì vậy tôi hiểu tại sao hầu hết các tài liệu phần mềm bị bỏ qua hoặc bị lỗi thời, nhưng ngay cả trong những điều kiện đó, tôi hoàn toàn khẳng định rằng sơ đồ cơ sở dữ liệu được tạo và giữ nguyên. Nếu đó không phải là một mô hình quan hệ thông thường và bao gồm các thực thể có tài liệu, cặp giá trị khóa hoặc cấu trúc JSON / XML, thì mô hình đối tượng của các mục đó cũng sẽ được tạo và duy trì. Nếu tất cả những điều khác không thành công trên các nỗ lực tài liệu của một dự án, ít nhất một sơ đồ cơ sở dữ liệu và / hoặc mô hình đối tượng sẽ cho phép một người làm việc ngược về phía trước để tìm hiểu điều gì đang xảy ra.

Có nhiều tùy chọn để tạo và duy trì tài liệu phần mềm, nhưng một trong những mục yêu thích của tôi là Enterprise Architect. Nó toàn diện và liên kết với nhau sử dụng các trường hợp, sơ đồ trình tự, sơ đồ lớp và các thứ khác.

Đối với những người chịu trách nhiệm cho việc này, tôi coi đó là một nỗ lực của nhóm. Rất ít người thích làm việc đó, nhưng nó phải được thực hiện. Kiến trúc sư hoặc lãnh đạo công nghệ trong một dự án cuối cùng phải chịu trách nhiệm về nó, giao nhiệm vụ một cách thích hợp.

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.