스펙을 제대로 작성하는 것은 구식이다?
2012/01/27 23:51 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다.
이것을 부정한다면 무엇을 만들지도 모르는 상태에서 무조건 코딩부터 시작하는 것이 가장 좋은 방법이라고 주장하는 것과 다를 바가 없다.
image by Lichfield District Council
RSS Feed
'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다.
스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것을 판에 박힌 절차라고 생각하고 부정하기도 한다. 그런 주장을 하는 사람들은 이 방법은 Waterfall 방식으로 구닥다리이며 요즘은 Agile 등의 최신 방법으로 개발을 하기 때문에 과거처럼 스펙을 작성하지 않는다고 한다.
이렇게 주장하는 사람들에게 반문해보고 싶은 것이 있다.
"스펙을 한번이라도 제대로 작성해 본적이 있는가?"
이런 생각을 하는 것 자체가 스펙을 제대로 이해하고 있지 못하다는 반증이다.
왜냐하면 스펙이 무엇인지 제대로 이해하고 있다면 이런 말이 나올 수가 없다.
지금 그렇게 부정하는 스펙을 작성하지 않아서 개발을 잘하고 있는가?
99% 이상의 개발자는 죽을 때까지 제대로 된 Waterfall 방식의 개발을 한번도 해볼 기회가 없다. 그러면서도 과거에 Waterfall 방식으로 개발을 했다고 착각을 하는 것이다. Waterfall 방식을 참고하여 약간 응용을 한 것 뿐이다.
Waterfall 방식이 다른 모든 SW 개발 Lifecycle의 모델이 되는 이유는 소프트웨어는 나중에 고치기가 정말로 어렵기 때문이다. 빌딩 올리는 것과 별 차이가 없다. 즉, 코딩을 다 해놓은 다음에 설계나 스펙을 바꾸는 것은 10배, 100배 비용이 많이 드는 것이다. 아무리 최신 기술을 적용해도 이는 별로 나아지지 않는다.
따라서 그중에서 가장 앞단에 있는 스펙이 가장 중요한 것이다.
스펙을 작성하는데 있어서 가장 중요한 것은 필요한 만큼 적절하게 적는 것이다. 단계 별로 작성할 수도 있고, Unit test로 작성할 수도 있고 방법의 선택은 자유이다. 가장 효과적인 방법을 선택하면 그만인 것이다.
문제는 적는 방법이 아니고 그 내용이다. 대부분 스펙을 작성하지 못하고 어려워하고 반대하는 사람들의 공통점은 스펙에 무엇을 적는지 모른다는 것이다. 그렇기 때문에 아무리 잘 적으려고 해도 잘 안되는 것이다. 정리를 잘하고 예쁘게 적는 것은 추후 문제이다.
실제로 필자는 여러 회사의 다양한 프로젝트의 스펙(SRS)를 대신 적어준 경험이 있다. 해당 분야의 Domain 지식이 부족한 나는 해당 분야의 전문가들을 인터뷰하고 의논해가면서 스펙을 적는다. 대부분은 Domain 지식에 대해서는 훤하지만 스펙에 어떻게 적어야 하는지 모르고 있다. 즉, 지식은 있지만 스펙은 모르는 것이다. 스펙을 적는 방법에 대해서 구체적으로 적는 방법을 얘기하면 책 몇권도 모자르기 때문에 여기서 다 적을 수는 없다.
한마디로 요약하면 적어 놓은 스펙을 보고 설계/구현이 가능해야 하는 것이다.
조금만 더 설명하면 시스템을 기능, UI, Architecture의 뷰로 설명하고 비즈니스 요구사항, 비기능 요구사항 등을 포함해야 한다.
스펙을 제대로 작성하는다는 것은 수십/수백페이지에 달하는 Template를 채우는 작업이 아니다. 어떤 SW를 만드는 것인지 정의 하는 것이다. 방법은 여러가지고 있고 그중에서 가장 효과적인 것을 선택하는 것이다.
이것을 부정한다면 무엇을 만들지도 모르는 상태에서 무조건 코딩부터 시작하는 것이 가장 좋은 방법이라고 주장하는 것과 다를 바가 없다.
image by Lichfield District Council
'프로젝트 > 요구사항분석' 카테고리의 다른 글
| 스펙을 제대로 작성하는 것은 구식이다? (2) | 2012/01/27 |
|---|---|
| 프로토타입을 재활용하면 될까? 안될까? (5) | 2011/11/14 |
| 프로토타입이란? (8) | 2011/11/03 |
| 스펙에 있어서는 안될 표현들 (8) | 2011/06/20 |
| 개발문서를 만들기는 했는데 업데이트가 안되는 이유 (16) | 2010/03/24 |
| SRS에 대한 인식의 변화 (10) | 2009/11/13 |
Trackback Address: http://allofsoftware.net/trackback/251
매번 글 재밌게 읽고 있습니다.
스펙을 정확하진 않더라도 간략히나마 추릴수 있는 방법은 어떤건가요?
항상 혼자서 취미 및 공부로 코팅하는 저는 어떤 프로그램을 짜고나서 결과는 생각처럼 움직이지만 더 구조적인 방법이 생각나서 다시 만들까 매일 고민합니다ㅡㅜ
안녕하세요. althea
스펙은 개발이 가능한 수준에서 가장 간략하게 적는 것이 중요합니다. 본인이 개발할 것이면 그냥 Text파일로 간단히 정리하는 것도 좋습니다. 형식은 구애받지 마세요.
흔히 스펙을 기능명세로 착각하는 경우가 많은데 스펙에는 회사의 목표, 비즈니스 전략, 비기능, 인터페이스, 환경 등 여러가지가 적힙니다.
개발해 놓고 나중에 아키텍처 개선이 생각나는 것은 스펙에서 충분히 아키텍처를 고민하지 못했거나 경험이 적은 제품이라서 개발해보지 않고 미리 좋은 아키텍처를 생각하기 어려운 경우 입니다. 이런 경험이 쌓여서 나중 제품의 아키텍처는 점점 좋아집니다. 그래서 경험이 많은 개발자들이 좋은 아키텍처를 만듭니다.