요즘에는 기술 설계 문서에 대해 동료들이 사용하는 도구 및 표준을 알고 싶습니다.기술 설계 문서 용 도구 및 표준
내 회사에서 우리는 클라이언트 - 서버 win-apps만을 제공 할 때 우리는 디자인 문서를위한 단어 템플릿을 가지고있었습니다. 우리의 템플릿은 항상 데이터베이스 다이어그램, UI 모형, 필드 매핑, 기능 설명 등으로 시작되었습니다. Word 및 Visio를 사용하면 충분했습니다. 그러나 요즘 우리는 Wiki, UML 다이어그램, 프로토 타입 도구 등을 결합하고 있습니다. 표준 및 도구에 대한 강력한 정책이 없습니다. 프로젝트 당 주어진 순간에 적합한 도구 및 표준 세트를 선택할 수있는 자유를 건축가에게주기에 좋다고 생각합니까? 또는 회사가이를 시행하고 표준화해야합니까?
모든 디자인 문서의 배경은 모든 관련자에게 명확한 의사 소통입니다. 따라서 건축가가 선택한 도구가 무엇이든, 완성 된 제품은 이제 모든 관련자와 나중에 유지 관리자가 읽을 필요가 있습니다. 따라서 몇 가지 표준 툴을 선택하는 것이 합리적입니다.
즉, 디자인 문서는 일반적으로 프로젝트 나 시스템을 시작하고 사용하는 데 사용됩니다. 그 후 잘 문서화 된 코드와 몇 가지 기본 문서로 충분해야합니다. 아마도 문서 작성 조직에 더 많은 관심을 기울여 사람들이 미래에 찾고있는 것을 쉽게 찾을 수 있습니다. 문서를 저장하기위한 일종의 표준 저장소 구조/시스템을 시행하는 데 도움이 될 수 있지만 문서화를 위해 모든 종류의 템플릿을 반드시 주장 할 필요는 없습니다. 콘텐츠가 아니라 도구에 집중하십시오.
귀하의 프로젝트가 쿠키 커터가 아니라면 최선의 작업 조합을 적용하는 것이 좋습니다. 즉, 다소 느슨한 (거친 지침) 또는 좁은 (특정 상황에 적용) 표준이 보증됩니다.
리드 개발자 또는 팀 구성원 (나중에 기록 될 수 있음) 간의 철저한 토론은 제 생각에는 어떤 문서보다 훨씬 중요합니다. 그들에게 도구를 선택할 수있는 모든 자유를 주며 초기에 고급 기술 결정에 대한 간단한 요약 만 작성하도록 요청하십시오. 이것은 나중에 프로젝트의 기초가 될 수 있습니다. 기술 설계 문서가 너무 빨리 구식이되어 작성하는 데 너무 많은 시간이 걸립니다.
디자인 시간을 문서화하는 방법을 설명하는 아키텍처 시간에 지정된 도구 및 표준 집합이 있어야한다고 생각합니다. 이러한 것들을 문서화하는 표준을 갖는 것이 정말로 중요합니다. 그렇지 않으면, 그들은 길가에 떨어지는 경향이있다. 디자인 문서가 이질적이라면 실제로 디자인에 대해 가장 많이 알아야하는 사람들이 정말로 필요할 때 실제로 필요한 디자인 정보를 찾지 못할 수도 있습니다.
즉 도구 및 표준의 선택은 전적으로 각기 다른 조직에 달려 있습니다. 조직을 위해 작동하는 것은 무엇이든 그들에게 적합합니다. 표준 (그리고 도구, 어느 정도까지)에 일관성이있는 한, 개별 조직을 위해 선택된 것은 무엇이든간에 그것들에 적합합니다. 결정을 내리고 시행해야합니다.
불행히도 아무도 정말로 귀하의 질문에 대답하지 않았습니다. 나는 여기에서 더 새로운 것 및 더 나은 것보다는 Visio보다는 서핑을하고있다 :) –