개발 후 소프트웨어 디자인 문서 작성이 정당화 될 수 있습니까?

저는 현재 "소프트웨어 개발"연구를 위해 졸업하고 있는데 외부 회사에서 복잡한 소프트웨어를 개별적으로 개발해야합니다. 이 모든 것은 구조화 된 방식으로 수행되어 모든 해당 문서를 작성해야합니다.

이 프로젝트에서는 IEEE 표준 문서 인 SRS (Software Requirements Document), SAD (Software Architecture Documents) 및 SDD (Software Design Document)를 사용하기로 결정했습니다. 학교에서 다르게 가르쳤지만,이 프로젝트를 위해 개발 후 (이전이 아닌) SDD를 작성하기로 선택했습니다 . 내 추론은 :

제가 인턴쉽을하는 회사는 실험적인 방식으로 특정 요구 사항을 만족시키는 복잡한 소프트웨어를 작성하라는 지시를 받았습니다. 그들이 프로젝트 정의에서 나에게 준 자유의 양 때문에, 거의 확실하지 않으며 개발 프로세스를 실험하는 동안 가장 잘 만날 수 있습니다. 또한 저는 개별적인 방식으로 소프트웨어 를 작성하고 있습니다 .이 소프트웨어 디자인을 사전에 만드는 것은 회사의 다른 누구에게도 도움이되지 않습니다. 프로젝트의 불확실성으로 인해 사전에 만든 디자인이 많이 변경되어야 한다는 것을 확신 할 수 있기 때문에 미리 변경하면 나중에 변경하는 데 많은 시간이 소요됩니다 . 이것은 나에게 역효과를 느낀다.

개발 후 SDD를 작성하는 것이 좋은 이유입니까? 그렇지 않다면, 그에 대한 정당한 근거가 있습니까?

편집 : 나중에 SDD를 작성하는 이유는 미래 개발자가 프로젝트를 계속하기 위해서입니다. 졸업 기간 동안 전체 프로젝트를 완료 할 수 없으므로 다른 개발자가 현재 코드베이스를 계속 사용해야합니다.

IEEE Std 1016 Section 3.1 소프트웨어 설계와 관련하여 다음 단락을 찾을 수 있습니다.

다양한 디자인 상황에서 SDD를 준비하고 사용할 수 있습니다. 일반적으로 SDD는 문제를 해결하기위한 소프트웨어 항목 개발을 지원하기 위해 준비되며이 문제는 일련의 요구 사항으로 표현됩니다. 그런 다음 SDD의 내용을 이러한 요구 사항으로 추적 할 수 있습니다. 다른 경우에는 설계 문서가없는 기존 시스템을 이해하기 위해 SDD가 준비됩니다. 그러한 경우, 관심 정보가 모든 이해 당사자에게 포착, 조직, 제시 및 전파되도록 SDD가 준비됩니다. 이 관심 정보는 필수 설계 문제를 식별하고 해결함으로써 소프트웨어 시스템의 계획, 분석, 구현 및 진화에 사용될 수 있습니다.

IEEE Std 1016의 저자는 SDD가 사전에 작성 될 수 없음을 인식합니다. 소프트웨어 시스템이 존재하면 이해 당사자를위한 정보를 캡처하기 위해 생성 될 수 있습니다.

섹션 1.1 범위는 몇 가지 흥미로운 정보를 제공합니다.

이 표준은 설계, 구성 관리 또는 품질 보증에 대한 특정 방법론을 규정하지 않습니다.

이 질문의 맥락에서 핵심 단어는 "구성 관리"입니다. 구성 관리는 작성중인 소프트웨어 시스템뿐만 아니라 관련 문서에도 적용됩니다.

개인적인 상황과 많은 상황에서 SDD를 미리 만드는 것은 낭비입니다. David Arno의 대답 은 내가 정답이라고 생각하는 것에 가깝습니다. 소프트웨어 시스템의 진정한 디자인은 코드입니다. 그러나 "SDD before create"또는 "SDD after create"만이 유일한 옵션은 아닙니다. 세 번째 옵션이 있습니다-소프트웨어 시스템으로 SDD를 발전시킵니다.

IEEE Std 1016과 같은 표준을 따르는 경우 SDD에 대한 요구 사항이 있습니다. 특히이 표준의 섹션 4는 보유하고있는 컨텐츠를 정의합니다. 설계 결정을 진행하면서 다양한 관점, 뷰 및 오버레이를 작성하십시오. 결정을 내릴 때 디자인의 이론적 근거를 파악하십시오.

이를 통해 이해 당사자는 코드를 파지 않고도 소프트웨어 디자인의 진화를 따를 수 있습니다. 물론 사람들은 의견이나 제안을 할 수 있습니다. SDD를 업데이트하는 경우 진행 상황을 추적하고 접근 방식에 대한 피드백을 조기에 제공하여 SDD뿐만 아니라 제품에 통합 할 수 있습니다. 프로젝트를 전환 할 때 소프트웨어 코드와 SDD가 동기화되어 있으면 누군가가 쉽게 작업을 수행하고 작업을 수행 할 수 있어야합니다.

SDD에서 찾고자하는 모든 것이 다른 사람들과 디자인을 전달하는 것이라면 개발 후에 만들 수 있습니다. 단지 문서화라고합니다.

그러나 SDD가 다른 목적으로도 사용될 수 있다고 지적하고 싶습니다. 또한 디자인에 대해 추론하고 "빠르게 실패"할 수 있도록 도와줍니다. 특히 전체 구현에서 초기에 작동하지 않는 접근 방식을 버릴 수 있기 때문에 많은 것들이 미리 확실치 않은 경우에 이는 좋은 방법입니다. 또한 디자인을 알아낼 때까지 아무것도 코딩하지 않음으로써 기술적 인 세부 사항에 집중하는 것을 방지 할 수 있습니다.

적어도 미리 SDD를 시도해 보라고 조언합니다. 일이 어떻게 작동하는지 잘 모르는 것에 부딪 치면 해결하려는 문제의 작은 프로토 타입을 만들 수 있습니다. 이는 장기적으로 완벽한 솔루션의 품질에 도움이되는 프로젝트의 특정 문제를 해결 한 경험을 제공합니다.

당신이 만들 진정한 세부 설계 문서 중 하나는 코드입니다. 컴파일러에게 응용 프로그램 작성 방법을 정확하게 알려줍니다. 따라서 배송 전에 최종 빌드 한 번까지 디자인을 완료 할 수 없습니다.

디자인 (코드)을 완료 한 후 SDD와 같은 다른 디자인 문서를 업데이트해야합니다. 따라서 나중에 SDD를 작성해야하는 강력한 이유가 있습니다. 한 번만 수행하면됩니다.

이것에 대한 명백한 반박은 " 이벤트가 끝난 후 얼마나 자주 SDD를 작성 합니까?"입니다. 앱이 제공되므로 해당 단계에서 문서화하는 데 시간을 소비하지 않을 것입니다. 그러나 이것은 기존 업데이트와 동일하게 적용됩니다. SDD 또는 SDD가 잘못되어 신뢰할 수없는 것은 무엇입니까?

미리 작성해야하는 두 가지 이유가 있습니다. 첫째, 그렇게하는 것이 강제적 인 요구 사항 일 수 있습니다 (좋은 것은 아니지만 발생합니다). 둘째, 이러한 문서를 작성하면 디자인에 대한 전반적인 전략을 수립하는 데 도움이됩니다. 그러나 그것은 비공식적 인 방식으로 그림을 그리거나 메모를 작성함으로써 똑같이 잘 할 수 있습니다. 나중에 다시 작성해야하므로 초기 매크로 디자인 프로세스에 대한 "빠르고 더러운"접근 방식에는 많은 이점이 있습니다.

나에게는 좋은 주장이 아니다.

실제로 필요한 경우 알려지지 않은 문제 영역을 더 잘 이해하기 위해 프로토 타입 개발에 중점을 둘 것입니다. 그러나 이러한 경우에도 일부 디자인은 이전에 유용했을 것입니다.

어쨌든 그것을 앞장서 서 할 수있는 경우가있다 . 이와 같은 문서 작성 에 대해 배우기 위해이 작업을 수행하고 있기 때문 입니다. 이 작업이 100 % 필요하지 않기 때문에이 작업을 건너 뛰면 학습을 건너 뜁니다.

구현 하는 동안 작성하는 것이 타협 일 수 있습니다 . 프로그램의 각 구성 요소 / 모듈 / 화면 또는 다른 세분화 전에 프로그램을 만드는 방법에 대해 생각해야합니다. 그런 다음 결정을 디자인 문서에 추가 한 다음 구현하십시오.

나중에 변경 사항이 있으면 문서를 업데이트하십시오.

이것은 사실 이후의 글쓰기와 비교하여 몇 가지 장점이 있습니다.

• 요구 사항이 변경 될 때 설계 문서를 업데이트하는 방법을 배우고 유용한 습관

• 구현하기 전에 디자인에 대해 생각하는 법을 배웁니다.

• 사실 후에 디자인 문서를 작성하는 것만 큼 지루하지는 않습니다.

• 시간이 부족한 경우 다른 사람이 작업을 계속할 수 있도록 지금까지 가지고있는 것을 설명하는 디자인 문서가 있습니다.

• 이 방법으로 많은 추가 작업이 아닙니다.

• 프로젝트가 진행됨에 따라 2 개월 전에 왜 그런 일을했는지 ​​확실하지 않을 수 있습니다.

프로젝트가 새로운 디자인 및 솔루션 속성으로 진행함에 따라 기본 요구 사항과 (새로운 기능) 업데이트가 기록 된 시스템 디자인 문서. 프로젝트 / 솔루션이 전달 될 때까지 유지됩니다. 유용하며 모든 관련자와 통신합니다.