논리적 및 물리적 아키텍처 다이어그램 업데이트

여러 개발자가있는 분산 시스템과 관련된 모든 소프트웨어 개발 프로젝트에서 논리적 및 물리적 아키텍처 다이어그램을 사용하는 것이 가장 좋은 방법이지만 필자의 경험에 따르면이 다이어그램은 항상 프로젝트 시작시 유지 관리가 시작되지만 프로젝트가 출시 될 때 업데이트되지 않습니다. 유지 보수 단계가 시작됩니다.

분산 프로세스가 많은 복잡한 프로젝트의 경우, 모든 사람이 모든 지식을 가지고 있지 않기 때문에 초기 릴리스 이전에도 다이어그램이 오래되거나 부정확 한 경향이 있습니다.

이러한 배경을 바탕으로 커뮤니티에 다음과 같은 질문을하고 싶습니다.

1. 정확하고 최신의 논리적 및 물리적 아키텍처 다이어그램을 보유하는 것이 얼마나 중요합니까?
2. 최신 상태를 유지하는 데 도움이되는 도구와 프로세스가 있습니까?
3. 최신 정보를 유지할 책임은 누구에게 있습니까? 시스템 관리자, 개발자 및 QA 팀은 어떻게 기여할 수 있습니까?

나는 시간 제약과 자원 문제로 실제 세계에 살고 있기 때문에 대부분의 소프트웨어 설명서가 무시되거나 오래된 이유를 이해하지만 이러한 조건에서도 데이터베이스 다이어그램을 작성하여 최신 상태로 유지해야한다고 절대적으로 주장합니다. 일반적인 관계형 모델이 아니며 문서, 키-값 쌍 또는 JSON / XML 구조를 가진 엔티티로 구성된 경우 해당 항목의 오브젝트 모델도 작성 및 유지 보수해야합니다. 프로젝트의 문서화 노력에 다른 모든 것이 실패하면 최소한 데이터베이스 다이어그램 및 / 또는 객체 모델을 사용하여 프런트 엔드로 돌아가서 진행 상황을 파악할 수 있습니다.

소프트웨어 문서를 작성하고 유지 관리하는 데는 여러 가지 옵션이 있지만 내가 가장 좋아하는 것 중 하나는 Enterprise Architect입니다. 포괄적이고 관계는 사례, 시퀀스 다이어그램, 클래스 다이어그램 등을 사용합니다.

이 일을 담당하는 사람은 팀의 노력이라고 생각합니다. 그것을하는 것을 완전히 즐기는 사람은 거의 없지만해야합니다. 프로젝트의 아키텍트 또는 기술 책임자는 궁극적으로 프로젝트를 책임지고 작업을 적절하게 위임해야합니다.