흔히들 개발자들은 이공계 출신이 많아 문서화 시키는데 약하다고 한다.
헐...
한마디로 공돌이들이기때문에 문서화 시키는것이 어렵다고하는데...
그렇다면 수많은 RFC표준과 같은 기술문서들은 출처가 어디인가?
바꿔 말해서 문과계열이 문서화하면 더 잘한다는 이야긴가?

당췌 말도 안되는 선입견 그자체인것이다.
현재 사용되는 문서 템플릿 자체가 어렵다. 더군다나 수많은 방법론의 등장으로 더 복잡한 체계를 가지고 있고 CMM을 보면 더 황당하다.
결국 문서만 생성하고 관리하는 인력이 더 필요해지고 사람이 많아질수록 커뮤니케이션에 더 많은 문제를 만나게 된다.

다시말해 문서의 체계를 바꿔야지 결코 현재의 문서 폭풍(Paper Storm)속에서 제대로 문서를 작성하고 설계하거나 하는 것은 요원한 일 그자체인것이다.

S/W개발에서 최대의 명제는 "쪼게서 하나씩 구현하고 합쳐라" (Division & Conquer)인것이다.

어느 방법론이든지 "분석, 설계, 테스트, 배포" 4단계를 벗어날 수 없는 이유중 하나이다.
근례에 들어 ERP업체들의 경우는 분석자체와 설계를 고객에게 맡겨버리는 사례가 있는데 아주 바람직한 방법이라 생각한다.
고객이 업무 플로우를 그리고 원하는 화면을 만들어서 개발사에 주면 개발사는 그것대로 DB만 구성하고 화면하고 로직은 연동하면 끝이다.
이렇게 되면 설계가 잘못됐느니 분석이 잘못됐느니.. (지들이 시간없다고 지랄할때는 언제고.. 쩝..) 또는 잦은미팅에 두서없는 이야기하는 것 자체를 원천봉쇄해 버릴수 있다.
또한 미리 개발자들이 투입되서 손가락 빨고 있는 것 자체도 막아버릴수 있으니 고객입장에서도 인건비 절감이 가능해지는 것이다.
더군다나 쓸사람들이 자기네 쓸 시스템을 만들었으니 누가 뭐라 그래도 자기네 시스템 아닌가?

따라서, 소프트웨어 공학역시 고객의 눈에 맞춰야 한다.
고객이란 작자들이 소프트웨어 공학에 대해 알 필요도 없고 왠간한 웹화면은 이제 엄청난 눈높이를 자랑하는데 여기에 맞추자면 별수 없지 않는가?
"그게 왜 안돼? 내가 홈피 만들어도 더 잘만들겠다"고 우기는 고객에게 그럼 니가 직접 만들어봐라라며 싸울 필요도 없고 요구사항이 명확해 지지 않겠는가?

복잡한 문서보다는 고객이 그린 그림대로 정확히 만들어지는가에 Focus가 맞춰져야지 보지도 않는 수많은 문서 쏟아내봐야 무슨 소용있겠는가?

그런 의미에서 나는 이런 문서만 있으면 되지 않겠는가 싶다.

1. 업무플로우 (고객 그림)
- 웹시스템에서 웹화면만큼 명확한 기준이 있겠는가? 웹화면기준으로 업무흐름을 그리게 하자.

2. 화면설계 (고객 그림)
- 흐름도에 있는 화면을 하나씩 상세하게 설명하도록 하게 하자.

3. 시스템/DB설계 (개발자 그림)
- 시스템설계 시스템의 네트워크 아웃라인, 컴포넌트 구성과 디렉토리(폴더)별 프로그램의 위치를 설명하도록 하자. DB는 화면설계에서 Entity를 뽑아 내도록 하자.

4. 테스트결과 (화면설계대로 작동하는지 확인하는 공동작업)
- 화면설계대로 화면이 구현됐는지 확인하고 고객에게 싸인하라고 하자.

5. 매뉴얼 (업무플로우와 화면설계, DB설계에 최종 업데이트해서 반영)
- 매뉴얼은 시스템 매뉴얼과 S/W매뉴얼로 구성하고 시스템 매뉴얼은 시스템의 기동과 종료, 미들웨어 작동방법까지 서술하자, S/W매뉴얼은 고객이 만든 업무플로우대로 화면설계 그대로 가져와서 배치하자(순서대로...) 약간의 주석은 필수다.

* 실사용자에게 참고용으로 주는 객체모음집


심플하게 좀 살자. ㅡㅡ;;