소프트웨어 개발에 있어 문서의 범위

글쓴이: gilsion / 작성시간: 월, 2006/03/27 - 9:35오후

소프트웨어를 개발하여 납품까지 함에있어 MIL-STD-498 이나 DO178 과 같은 규격에 맞추어 문서를 작성해야 하는 일은 따분하기 그지없는 일입니다.

이런 문서작업이 업무에 얼마나 도움이 될지 개발자의 입장에서는 의문스럽기 짝이 없었으나 실지로 다른이가 개발중이던 소프트웨어를 인계 받거나, 세월이 지난후 다시 작업을 하거나, 납품에 있어 증빙자료로 첨부 되거나, 알고리즘을 보존하는 등의 부분에 있어 상당한 도움이 되는걸 경험했습니다. 어느것 하나 빠지면 안될것 같은 문서들 뿐인듯 합니다.

하지만 수주한 소프트웨어의 납품물 범위를 벗어나서 사내추진 소프트웨어의 경우 시간적인 여유때문에 이러한 문서들을 전부 챙길수는 없는 노릇입니다. 요구사항 명세서 정도는 근근히 챙깁니다만 불만이 많습니다.

여러분들은 소프트웨어 개발을 진행할때 어느정도의 범위까지 문서를 작성하고 계신가요?

실제로 어느정도까지 꼼꼼히 챙겼으나 쓸모가 없었다던지, 꼼꼼히 안챙겨서 손해를 봤다던지 하는 이야기도 듣고 싶습니다.

Forums:

토론, 토의

프로젝트 기획서

글쓴이: cyberpd / 작성시간: 화, 2006/03/28 - 8:24오전

프로젝트 기획서 달랑 한 개입니다. -_-
제 나름대로 저를 위해서 문서를 만들고 있지만, 공식문서도 아니고 다른 사람이 보는일도 없습니다. -_-

-= 우주인류감시위원회 =-

프로젝트를 문서만

글쓴이: lovejin0309 / 작성시간: 화, 2006/03/28 - 10:43오전

문서를 중요시하고 있습니다.

프로젝트를 문서만 보고 다시 만들 수 있을 정도로 작성합니다. 1만 라인짜리 프로젝트에 문서만 500페이지가 넘습니다. 단순히 문서 작성에 목적을 두지 않고 이 문서를 보는 사람이 프로젝트를 이해 할 수 있도록 작성합니다. 이 함수는 이런 이런 이유가 있어서 작성했으며 이런 이런 방식으로 동작한다. 주의할 점은 이런점이고 개선해야 할 점은 이런 점이지만 이런 이유로 지금은 이렇게 작성했으며 앞으로는 이런 방향으로 나가야 한다는 점까지 세세히 적어 놓습니다. 또한 소스 자체에도 함수마다 Changlog를 일일히 남깁니다. 그래야 이 함수의 초기 목적이 무엇이었는데 이런 식으로 변해 갔다는 것을 알 수 있기 때문입니다.

어디서 근무하시는지

글쓴이: scari / 작성시간: 화, 2006/03/28 - 1:22오후

lovejin0309님, 어디서 근무하시는지 너무 부럽습니다.
문서는 커녕, 소스도 제대로 남아있지 않은 환경에서 업무를 인수받은 아픈 추억이 떠오르는군요.
확실히 이상적인 케이스라고 생각합니다.

하지만 개발자들에게 친숙한 환경을 제공하는 훌륭한 문서화 도구들이 널려있음에도 불구하고,
문서화에 들어가는 시간과 노력은 분명 개발 일정에서 한 귀퉁이를 잡아먹습니다.
이를 개발 노력의 일부로 인정하지 않으려는 많은 경영진들은 어떻게 설득해야 할까요?

뭔가 정치적인 문제가 더 이슈가 될 것 같다는 생각입니다.

http://scari.net

중요하지만 시간이...

글쓴이: Gargoyle / 작성시간: 화, 2006/03/28 - 12:00오후

이래저래 웹 관련 업무를 근 4~5년 정도 해왔습니다. 문서의 중요함은 절실하게 느끼고 있긴 합니다만 MIL-STD-498 이나 DO178 같은 규격이 무엇인지를 모릅니다. --; 요구사항, 기획서, 화면설계서 같은 것이야 기획자가 전담하기에 프로그램 설명과 스키마 정도만 작성하고 있습니다. 세부적인 부분들은 소스에 주석을 다는 정도이고요.

문서만 보더라도 전체를 이해할 수 있게 작성해야 함을 알고는 있지만 개발 도중 수시로 변경되는 요구사항과 하루에도 두어번씩 추가되는 요구사항들 때문에 문서작업은 결국 뒷전으로 미루기 일쑤였습니다. (바쁠 때엔 주석조차 달지 않고 그냥 넘어가는 경우도 다반사였고 다음날 스스로가 작성한 소스를 분석해서 작성하는 어처구니 없는 일도 몇번 겪어 봤습니다. --; )

매번 다른 사람들의 소스 보면서 한 숨도 많이 쉬었었는데 아마도 제가 작성한 소스를 보면서 한 숨 지을 분들도 많았을 것 같군요. ^^;;; 이거 정말 고쳐야 할 나쁜 버릇인데 말입니다. 매번 프로젝트 막바지엔 진이 빠져서 널부러지니 원... --;

음..

글쓴이: ssif / 작성시간: 화, 2006/03/28 - 4:13오후

이를 개발 노력의 일부로 인정하지 않으려는 많은 경영진들은 어떻게 설득해야 할까요?

경영진의 문제도 있기는 합니다.그러나 팀장마저 그런다면 정말 대책없는 상황입니다.
봄들판에서다

봄들판에서다

서식이라도..

글쓴이: _Anonymous / 작성시간: 화, 2006/03/28 - 9:35오후

작성하고 싶어도 서식을 몰라서 못하는 경우가 많을듯 합니다.
이 주제를 통해 많이 배우고 싶은데 알려주시면 감사하겠습니다.

개발하는

글쓴이: gilsion / 작성시간: 화, 2006/03/28 - 10:56오후

개발하는 소프트웨어의 특성, 정립되어 있지 않은 개발 절차, 혹은 업무 중요도 등의 이유로 문서화가 잘 되지 않는다고 보여집니다.

그 이유야 어찌되었든 본인을 위해서, 차후 개발자를 위해서, 또한 회사를 위해서 체계적으로 문서를 작성하라고 하는것은 몇번씩 강조해도 지나치지 않은듯 합니다.

당장이라도 문서작업을 하고 싶은데 필요한 문서들의 목록이나 작성요령을 모르신다면 MIL-STD-498 을 소개해 드립니다.

Google 에서 상기명으로 검색을 하면 처음에 아래의 링크가 검색됩니다.

http://www.pogner.demon.co.uk/mil_498/

아쉽게도 한글화 된 자료는 인터넷으로 쉽게 구할수가 없군요
좌측메뉴 아래쪽에 보면 문서목록(DIDs)이 있습니다. 소프트웨어 특성에 맞게 몇몇 문서는 제외하고 작성을 하면 될것이고, 각 문서별 링크를 클릭하면 TOC 별 작성방법도 명시되어 있습니다. 아래가 MIL-STD-498 에서 제시하는 문서의 목록입니다.

Software Development Plan (SDP)
Software Installation Plan (SIP)
Software Transition Plan (STrP)
Operational Concept Description (OCD)
System/Subsystem Specification (SSS)
System/Subsystem Design Description (SSDD)
Software Requirements Specification (SRS)
Interface Requirements Specification (IRS)
Software Design Description (SDD)
Interface Design Description (IDD)
Database Design Description (DBDD)
Software Test Plan (STP)
Software Test Description (STD)
Software Test Report (STR)
Software Product Specification (SPS)
Software Version Description (SVD)
Software User Manual (SUM)
Software Center Operator Manual (SCOM)
Software Input/Output Manual (SIOM)
Computer Operation Manual (COM)
Computer Programming Manual (CPM)
Firmware Support Manual (FSM)