태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?

2013.06.03 23:37 by 전규현


잠시 후 Google blogger로 이동됩니다.






소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 


그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?

남이 작성한 SRS를 보면 도움이 될까? 

가상으로 한번 써보면 도움이 될까? 

케이스별로 얼마나 도움이 될지 알아보자.


1%


스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?

1%정도 밖에 도움이 안된다.

남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다.


10%


그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면 어떻게 될까? 10% 정도는 도움이 될 수 있다. SRS에 포함된 수많은 내용 중에는 실제 상황이 아니면 도저히 생각해 낼 수 없는 부분들이 많다. 이런 부분은 가상의 프로젝트에서는 배우기 어렵다.


30%


이미 끝난 프로젝트의 SRS를 적어보는 것은 어떨까? 나중에 혹시 유지보수에 도움이 되지 않을까? 별 도움이 되지 않는다. 

SRS는 원래 개발하기 전에 개발을 빠르게 하기 위해서 적는 것이다. 이미 종료된 프로젝트라면 적을 수 없는 부분이 많다. 또한 꼼꼼하게 적지도 않게 된다. 미리 적는 SRS처럼은 절대로 적을 수가 없다.

이미 코딩까지 끝났기 때문에 창의적인 생각이 필요한 Interface 등은 제대로 적기 어렵다. 현재 상태를 Reverse Engineering으로 적는다고 해도 깨끗하게 적을 수 없을 뿐더러 뒤죽박죽이라서 적어봐야 아무 의미 없는 경우가 대부분이다. 또는 SRS를 작성하면서 필요한 커뮤니케이션 스킬, 분석 능력, 인터뷰 능력 등은 전혀 익힐 수가 없다. 이러한 것을 빼고 내용만 일부 Dump하는 것은 Template을 익히는 것밖에 기대하기 어렵다.


100%


SRS 작성하는 법, 스펙을 작성하는 법, 요구사항을 분석하는 법을 제대로 배우려면 크던, 작던 실제 프로젝트에서 SRS를 적어봐야 한다. 어떠한 프로젝트도 SRS의 모든 챕터를 다 커버하는 것은 없다. 따라서 하나의 프로젝트에서의 경험은 상당히 제한적이다. 오랜 기간동안 여러 프로젝트의 SRS를 작성해봐야 배울 수 있다.


따라서 일단 실제 프로젝트에서 작성해보는 것이 가장 좋은 방법이다. 물론 피아노를 코치없이 배울 수 없듯이 경험이 많은 선배나 전문가의 도움을 받는 것은 꼭 필요하다.


image by Nuwandalice

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. 개발 경력을 꽤 되는데 SRS 는 적어 본 적이 없는 SRS 초보자입니다.

    지난 번 SRS 강의를 들으며 나름대로 이해(or 오해 ^^) 한 바가 있는데요.

    SRS 는 템플릿이 아니고 "글을 잘 써야 한다" 는 말씀에서 느끼는 바가 있어서요.

    요즈음은 "나는 기술자가 아니라 소설가이다" 라는 자기 최면을 걸어 놓고 '나름 SRS(?)' 쓰는 걸 시도하고 있습니다.

    맥락을 전혀 모르는 독자들에게 내가 고민 했던 것, 하고 싶은 말을 충실히 적는 글짓기 연습부터 하고 있는 셈이지요.

    문장력이 좀 생기면 그때 가서 템플릿에 맞추어 볼 생각입니다.

    우리 회사 개발자들은 제 '나름 SRS'에 시큰둥 하고요.

    마케팅/기획 쪽 분들은 아주 좋아 하시더군요. ^^

넣는 것 보다 빼는 것이 더 어렵다.

2013.05.14 23:29 by 전규현


잠시 후 Google blogger로 이동됩니다.







초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.


성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.


고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.


이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.


기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.


이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.


기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다. 


하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.


스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.


그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.


1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.


image by Kingfox





저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. 저는 하위버전 호환성을 유지하는 것이 매우 중요하다고 생각합니다.

    고객사에서 제품을 상위버전으로 업그레이드 했을 때 서비스가 안되는 부분이 생긴다면 이는 재앙에 가깝습니다.

    조엘이 쓴 책에서도 MS 가 하위버전 호환을 유지하기 위해 얼마나 노력을 많이 했는지 언급되었던 것으로 기억합니다.

    새버전 출시 시 마케팅 자료나 영업자료에서 그 기능을 삭제하는 것은 가능하지만 제품에서 물리적으로 삭제가 되는 것은 아니라고 생각합니다.

  2. 공감합니다.

    소프트웨어 업그레이드 시 하위호환을 유지하기 위해서 많은 노력을 들이게 됩니다. 정말 잘 설계를 해서 꾸준히 하위 호환성을 유지하기도 하고 Migration 기능을 제공하기도 합니다.

    여기서 지적하는 것은 기존의 기능을 무작성 빼자는 것이 아니고 전략적인 생각없이 경쟁 회사들의 기능과 특정 고객이 원하는 기능을 잔뜩 포함해서 키친씽크를 만들지 말자는 얘기입니다.

    하위호환성을 유지하면서도 기존 기능을 없애거나 새로운 형태로 진화시키는 일은 종종 있습니다. 결국 기획팀에서 전략을 제대로 수립해야 겠죠.

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.

2013.03.14 19:05 by 전규현


잠시 후 Google blogger로 이동됩니다.







소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다.

소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다


하지만 우리나라에서 "요구사항분석" 역량을 제대로 갖춘 개발자를 만나보는 것은 매우 어렵습니다. "요구사항분석"은 교과서를 통해서 배울 수 없고 실전을 통해서 익혀야 하는데 우리나라는 자수성가한 개발자들로부터 시작되고 이어져 왔기 때문에 이를 가르쳐 줄 수가 없었습니다. 대기업에서는 대규모 방법론이나 비싼 툴을 사용하여 "요구사항분석"을 해보려고 하는데 아무리 비싼 골프채가 있어도 골프를 잘치는 것은 딴 얘기이듯이 툴이 이것을 해결해주지는 않습니다.


결국은 요구사항분석의 핵심을 꺠닫고 꾸준히 현실 프로젝트에서 경험을 쌓아가는 것이 유일한 방법입니다. 그래서 그 실전적인 방법을 공유하고자 세미나를 개최합니다. 많은 성원 부탁합니다. 


시간과 장소는 아래 URL 참조하세요. 


http://projectresearch.co.kr/2013/03/11/대한민국-개발자들이여-깨어나라-올바른-sw-개발-방법/


참석하실 분들 댓글 달아주시고, 여기(http://onoffmix.com/event/13214)로 신청하시면 됩니다.




image by naotakem

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. 꼭 회사차원의 컨설팅을 받아보고 싶었는데
    개인적인 교육수강기회가 생겨서 너무 좋습니다.
    다음날 교육도 맘에 들더군요..
    신청해버리고 말았습니다... ㅎㅎㅎ

  2. 안녕하세요.
    꼭 듣고 싶은 세미나인데 정원이 차서 참가가 힘드네요 ㅠ
    온오프믹스쪽에 문의해보니 그 쪽에선 결제대행만 하기 때문에 인원 조정은 주최자에게 직접 문의해야 한다고 하시더군요.
    서서 들어도 좋으니 인원을 늘려 주실 수는 없는지 문의드립니다.

  3. 안녕하세요.
    세미나 장소의 공간이 한계가 있고 대기가 40명이 넘어서 인원을 늘려서 해결이 어려울 것 같습니다. 다음 기회에 참여을 하시면 어떨까요?

  4. Blog Icon
    권인호

    네.. 어쩔 수 없지요.
    꼭 가까운 시일 내에 다음 기회가 있기를 희망합니다.
    답변 감사드립니다.

  5. 세미나 잘 들었습니다.
    高僧을 모시고 禪問答 하는 시간 같았습니다.
    어떠한 질문에도 거침없이 답변을 쏟아내시는 모습이 인상적이었고요.
    저도 열심히 SRS의 道 를 닦아서 解脫 에 이르러 보겠습니다.

  6. Blog Icon

    비밀댓글입니다

소프트웨어 개발시 일을 작게 쪼개야 하는 이유

2012.09.24 06:00 by 전규현


잠시 후 Google blogger로 이동됩니다.






대부분의 소프트웨어는 수명에서 수백명, 많게는 수천명이 같이 개발한다. 그래서 효과적으로 일을 나눠서 개발할 수 있어야 한다. 심지어는 혼자서 개발을 할 때도 일을 쪼개야 한다. 


왜 일은 쪼개야 하고 어떻게 쪼개야 하는것일까? 대부분의 다른 산업 분야는 일을 잘 쪼깬다. 시계하나를 개발해도 각 부품을 따로 개발해서 조립한다. 따로 개발하기 전에 이미 어떻게 연결이 되는지 인터페이스를 완벽하게 정의하고 개발한다. 그렇지 않으며 나중에 조립이 안되서 처음부터 다시 개발해야 할 수도 있다.


소프트웨어 프로젝트에서 일을 서로 어떻게 나눠서 개발을 하고 있는지 생각해보자. 


흔히 사용하는 방법이 화면 단위로 일을 나누는 것이다. 이 방법은 일을 나누기는 쉬워보이지만 문제가 많다. 나눠서 한 일이 서로 통합이 잘 안되고, 서로 중복된 개발도 많이 하게 된다. 다 개발해 놓고 서로 맞추는데 많은 시간을 소모하곤 한다.


일을 효과적으로 쪼개는 방법은 프로그램을 컴포넌트 단위로 잘 쪼개는 것이다. 컴포넌트는 특정 일을 담당하는 모듈로서 Class일 수도 있고, Class의 집합일 수도 있고, 함수의 집합일 수도 있다. 형태는 별로 중요하지 않다. 중요한 것은 컴포넌트의 외부 인터페이스가 간단하고 명료하게 잘 정의가 되면 되는 것이다.


분석/설계 과정에서 컴포넌트의 인터페이스가 잘 정의되면 많은 개발자들이 일을 나눠서 할 수 있게 된다. 10명이 개발을 하다가 시간이 부족하여 5명을 추가로 더 투입해도 큰 문제없이 개발이 가능하다.


서로 의존성이 있는 모듈들을 동시에 개발할 수 있게 된다. 특정 컴포넌트의 개발이 완료되어야 동작하는 모듈도 인터페이스가 확정되어 있으면 미리 개발을 할 수 있다. 개발 기간이 단축되는 것이다. 물론 모든 모듈이 다 개발되어야 테스트가 가능하지만 구현은 미리 해 놓을 수 있다.


또, 일부 모듈은 외주를 주는 것도 가능해진다.


이렇게 소프트웨어를 컴포넌트로 잘 나누게 되면 그 과정에서 문서화가 되고 서로 리뷰를 통해서 문제점을 발견하고 가장 뛰어난 아키텍처를 만들 수 있다. 또한 작업의 단위가 작아야 일정을 충분히 예측할 수 있다.


코딩을 시작하기 전에 이미 문서를 통해서 검증이 되고 공유가 된다. 그래야 변경이 최소화되고 가장 빠르게 소프트웨어를 개발할 수 있다.


분석 과정에서 부터 이미 주요 컴포넌트를 나누는 작업이 시작되고 외부 인터페이스를 정의하게 된다. 설계의 정도는 프로젝트마다 매우 다르지만 컴포넌트를 좀더 작게 나누고 function prototype까지 정의를 하면 설계가 완성된다. 간단한 프로젝트인 경우에는 스펙에서 정의한 컴포넌트와 인터페이스만 가지고 별도의 자세한 설계 없이 구현이 가능하다.


이렇게 일을 쪼개는 이유는 소프트웨어를 가장 빨리 개발하기 위한 것이다. 그렇지 않고 그냥 대충 일을 나눠서 서로 뭉쳐서 긴밀하게 의논해가면서 개발을 하는 것이 더 빨라 보인다고 생각하는 사람들이 매우 많다. 이 방법은 초기에 빠른 결과물을 보여주어서 초반에는 빨라 보이지만 결국 통합에서 지연되고 많은 재작업으로 시간을 소비하고 버그를 더 많이 만들어내어서 또 지연된다.


당장 코딩부터 시작하기 보다 생각을 더 많이 해서 컴포넌트를 잘 나눠 일을 쪼개서 재작업을 최소화하고 한번에 구현을 해 내는 것이 소프트웨어를 개발하는 가장 빠른 방법이다.


image by explainthatstuff


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.



저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 컴포넌트

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

2012.08.30 01:40 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.


1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.


위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."


위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.


99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.


스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.


1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구


이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.


프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.


변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.


변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.


변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.


이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.


또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.


스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 


스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.


image by  m.a.r.c.


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 스펙

  1. Blog Icon
    SI PL

    Budget, Time은 변경할 생각이 없으면서, 요구사항은 수용해야한다고 생각하는 고객이 문제입니다.

    프로세스를 FM대로 하려면 고객도 FM에 따라주면 좋겠지만, 그런 고객은 못만나 보았습니다.

    아키텍처에 영향을 미칠정도의 요구사항변경은 On Time, on budget에서는 무리라는건...

    변경관리를 하지 않아도 파악되어야 한다고 생각합니다.

    아키텍처에 영향이 없는 폰트변경, 버튼위치변경 요청까지 명문화하여 관리하기엔 인생은 그리 길지 않은것 같습니다.

  2. SI PL님 안녕하세요.

    스펙을 토대로 계약을 해야 하는데, 우리나라는 계약 후에 스펙을 작성하기 때문에 스펙 변경에 전혀 부담을 없어하죠. 그게 가장 큰 문제 중에 하나라고 생각합니다. 오타수정이나 누가봐도 너무 사소한 변경은 상식적으로 변경관리하지 않는 것이 맞으나 미 국방부 프로젝트라면 그런 것도 허용하지 않죠. ^^

    우리나라에서는 환경이 열악한 것은 사실인 것 같습니다. 그래도 이미 그런 것을 알고 감수를 하면서 프로젝트에 뛰어 든 것이지요. 그래서 사실 SI 프로젝트의 수익성이 그렇게 좋지 않습니다. 10건 성공해도 큰것 1건 폭탄을 맞으면 적자가 나기도 합니다. 그래서 분리발주를 법제화하려고 하는 이유중 하나입니다. 모든 것의 전제 조건은 분석 역량이 뛰어나야 하는 것인데 아직 해야 할 일이 많습니다.

  3. Blog Icon
    KIH

    들고온 스펙이 너무 허접하면 어쩌죠..?ㅎㅎ

  4. 안녕하세요. KIH
    약간 헷갈리네요. 고객이 준 스펙이 허접하다는 얘기 인가요?
    개발을 의뢰했는데 개발사가 스펙을 허접하게 작성했다는 얘기인가요?

    첫번째로 생각하고 의견을 말씀드리겠습니다. 일반적으로 고객은 스펙을 작성하지 않습니다. 고객이 스펙까지 다 작성하고 설계/구현만 발주하는 경우는 많지 않습니다. 고객이 소프트웨어 회사인 경우는 종종 있는 경우 입니다.

    분리발주인 경우 스펙을 작성하는 분석 프로젝트를 별도로 발주하기 때문에 스펙이 잘 작성된다고 봐야 겠죠.

    보통 프로젝트인 경우 고객이 스펙을 작성하지 않습니다. 설령 스펙이라는 이름으로 준 문서도 "요구사항"으로 보면 됩니다.
    요구사항과 스펙은 다릅니다. 고객이 허접한 스펙을 주면 분석을 다시 해서 스펙을 작성해야 하는 상황입니다. 원하시는 답이 되었는지 모르겠네요. ^^

개발자의 취향

2012.08.02 06:24 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다.


이 경우 Architecture상의 심각한 문제점을 내포하게 된다.


제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다.


Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 


이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.

그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에 심각한 문제를 초래하기도 한다.


그럼 어떻게 하면 이런 잘못된 결정을 막을 수 있을까? 답은 의외로 간단하다. 분석을 제대로 하는 것이다. 제대로된 스펙문서에는 최종 결론 뿐만 아니라 그런 결정에 이르게 된 근거와 의논 과정도 적어야 한다. 그래야 스펙을 읽는 사람들이 의문가 이의를 제기하지 않는다.


예를 들면 다음과 같은 것들이 있다.

  • 현재는 Windows만 지원하지만 3년안에 Mac을 지원할 가능성이 90%라서 엔진은 ANSI-C로 개발을 하고 UI를 QT Framework를 이용한다.
  • Java와 C로 모두 개발이 가능하고, 프로젝트 리더가 C언어를 더 좋아하지만, 기존 제품들이  Java로 되어 있고 회사에 Java개발자가 대부분이므로 Java를 선택한다.
  • 회사에 자연어 처리 전문가가 있지만 자연어 처리 엔진의 직접 개발 비용과 상용라이브러리를 구매했을 때를 비교했다. 10년 후까지의 유지보수 비용을 고려하여 자체 개발보다는 상용라이브러리 구매를 선택했다.
  • 현재 프로젝트는 아이폰/아이패드 용으로만 계획을 세웠지만, 영업부서와 논의결과 안드로이드를 지원할 가능성이 있어서 제품의 난이도가 그렇게 높지 않아서 Adobe Air를 사용하기로 했다.
이러한 결정 과정은 프로젝트를 진행하면 수십가지 또는 수백 번 진행이 된다. 스펙문서에는 이러한 결정과정까지 적어야 정확한 내용이 된다. 또한 중간에 상황이 변경되면 신속하게 영향평가를 할 수 있고 스펙을 변경할 수 있다.

소프트웨어 프로젝트는 개발자의 취향대로 진행되는 것이고 합리적인 근거를 바탕으로한 Architecture 결정에 따라 진행되어야 한다.

Image by kevin dooley



저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 분석, 설계

스펙을 제대로 작성하는 것은 구식이다?

2012.01.27 23:51 by 전규현


잠시 후 Google blogger로 이동됩니다.







'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다.

스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것을 판에 박힌 절차라고 생각하고 부정하기도 한다. 그런 주장을 하는 사람들은 이 방법은 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 

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. Blog Icon
    althea

    매번 글 재밌게 읽고 있습니다.
    스펙을 정확하진 않더라도 간략히나마 추릴수 있는 방법은 어떤건가요?
    항상 혼자서 취미 및 공부로 코팅하는 저는 어떤 프로그램을 짜고나서 결과는 생각처럼 움직이지만 더 구조적인 방법이 생각나서 다시 만들까 매일 고민합니다ㅡㅜ

  2. 안녕하세요. althea

    스펙은 개발이 가능한 수준에서 가장 간략하게 적는 것이 중요합니다. 본인이 개발할 것이면 그냥 Text파일로 간단히 정리하는 것도 좋습니다. 형식은 구애받지 마세요.

    흔히 스펙을 기능명세로 착각하는 경우가 많은데 스펙에는 회사의 목표, 비즈니스 전략, 비기능, 인터페이스, 환경 등 여러가지가 적힙니다.

    개발해 놓고 나중에 아키텍처 개선이 생각나는 것은 스펙에서 충분히 아키텍처를 고민하지 못했거나 경험이 적은 제품이라서 개발해보지 않고 미리 좋은 아키텍처를 생각하기 어려운 경우 입니다. 이런 경험이 쌓여서 나중 제품의 아키텍처는 점점 좋아집니다. 그래서 경험이 많은 개발자들이 좋은 아키텍처를 만듭니다.

프로토타입을 재활용하면 될까? 안될까?

2011.11.14 06:20 by 전규현


잠시 후 Google blogger로 이동됩니다.





며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다.

2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?

소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.

여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.

필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.

그 이유는 다음과 같은 것들이 있다.
  • 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다. 
  • 보통 에러처리와 약간의 버그는 무시한다.
  • 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
  • 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
  • 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다. 
따라서 재사용 가능하도록 만든다면 낭비가 될 수 있다.

보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.

제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.

그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다. 

그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.
  • 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
  • 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
  • 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
  • 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
  • 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.
 사실 아주 작은 제품이나 소수의 팀이 개발하는 제품이 아니라면 위의 모든 것을 가정하기는 대단히 어렵다.

스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다. 

어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.

스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.

이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.

프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.

단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.

Image by ッ Zach Hoeken ッ


 
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. 저는 프로토타입은 2가지 경우에 사용한다고 생각합니다.

    1.고객과의 의사소통용(UI가 주가되는 프로토타입)
    2.기술검증용

    1번의 경우야 말할것도 없이 요구분석이 끝나면 버려야 하는 것이죠.
    2번의 경우는 기술검증이 실패하면 어차피 버려질 코드입니다.
    물론 성공했을때에 코드를 정리하여야 하지만 프로토타입을 만들때 발생하는 실패리스크에 비하면 그렇다하게 큰 리스크라고 보기는 힘든것 같습니다.

    물론 프로토타입을 만들면서 발생한 이슈나 기술에 대한 이해가 떨어지는 상태로 만든부분은 주석으로 표시를 해두는정도의 정성은 있어야 한다고 생각합니다.

    이 포스트에서 지적하신대로 자신의 코드에 저도 집착 합니다 ㅎㅎ;;그래서 테스트는 했지만 스팩아웃된경우 따로 정리해놨다가 블로그에 올리곤 하죠.
    최소한 다음번에 같은 검증을 하지 않아도 되게 정리해두는것도 좋은 생각인것 같습니다.

  2. 안녕하세요. 당근천국님

    여기서 UI프로토타입은 전혀 언급하지 않았습니다. ^^ 별이슈가 없거든요.

    현재 프로젝트의 특성이나 조직의 상황을 고려하여 가장 적절한 방법을 택하신 것으로 이해가 됩니다. ^^

  3. Blog Icon
    아무것도모름

    좋은 글 잘 보았습니다. 저도 SW 분야에서 근무한지가 두자리 숫자를 좀 넘어가면서
    쓰신 내용에 대해서 감성적으로, 이성적으로 공감을 하는데요....

    국내 현실은 너무나 무지한 것 같습니다. 모든 프로젝트가 그렇지만 일정, 리소스가 부족한데
    비해 '우아한' 행위 - 불필요한 임원보고, 언론플레이용 데몬스트레이션 등 - 에다가 정작 개발하고자
    하는 서비스/제품은 말도 안되고 유저 입장에서는 뭥미할만한 것인데 기획/UI는 수시로 변경하면서
    실제 개발에 드는 시간은 쉽게 잡아먹고 마는 현실이....--;;

    프로토타입을 대함에 있어서 고객은 '프로토타입'과 '실제 제품'의 차이를 인지하지 못하는 경우가
    허다하다고 봅니다. 저도 수없이 많이 겪어봐서 사실...좀 회의적이긴 한데요...프로토타입을 통한
    기술 혹은 시제품 정도의 검증으로 인식하게 하려면 어떤 방법이 있을까요?

    일하면서 성격이 시니컬하게 변하는 걸 느끼고 있어서....희망적인 뭔가가 있기를 기대하면서
    살고 있습니다.

    항상 좋은 글 감사합니다.

  4. 안녕하세요.

    그래서 소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것이 스펙을 쓰는 겁니다. 즉 분석이 어렵다는 얘기죠.

    UI프로토타입의 경우 그럴듯한 화면을 보여주면 개발이 거의 된 것으로 착각하는 경우가 있습니다. 그래서 몇몇 UI프로토타입 툴들은 진짜 프로토타입처럼 찌글찌글하게 보여주는 것들이 있습니다. 딱 단순히 프로토타입인것을 알게 됩니다.

    마인드를 바꿔야 하는데 다른 사람의 생각을 바꾸는 것이 쉽지는 않죠.

    제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 사서 읽어보라고 해보세요. 여기에 관련된 거의 모든 내용이 이해하기 쉽게 정리되어 있습니다.

  5. Blog Icon
    MdadKight

    버리지 못 할 것 같으면 실용주의 프로그래머에 나왔던 예광탄 방식을 활용해볼 수도 있습니다.

프로토타입이란?

2011.11.03 03:16 by 전규현


잠시 후 Google blogger로 이동됩니다.





프로토타입 (경제/경영)

양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다.

by 다음 백과사전 (http://100.daum.net)

소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다.

이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다.
스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 경우가 있다. 스펙이 이렇게 불분명한 부분이 가득하다면 십중팔구 프로젝트는 산으로 갈 것이다.

그래서 스펙을 쓰면서 나중에 코딩에 들어가기 전에 미리 한번 만들어보는 것이다. 이렇게 만드는 프로토타입은 되는지 안되는지만 검증을 하는 것이므로 최대한 간단하게 만든다.

회사의 코딩 규칙을 따르지도 않고
에러 처리도 제대로 하지 않고
주석도 달 필요가 없다.

제대로 개발하려면 1주일 이상 걸릴 것도 몇시간에 걸쳐서 되는지만 확인해보는 것이다.
그렇기 때문에 이때 작성한 소스코드는 버리는 것이다. 절대 재활용하면 안된다. 규칙도 따르지 않고 에러처리도 안되고 주석도 없는 코드를 재활용하는 것은 대단히 불안한 일이다.

이렇게 검증을 해나가면서 스펙을 적으면 프로젝트가 계획된 시간에 끝날 가능성이 점점 높아지게 된다.

그렇다고 모든 내용을 다 검증해가면서 스펙을 적을 수는 없다. 어떤 항목은 된다는 감을 믿고 그냥 적어야 할 때도 있다. 모든 것을 다 검증하면 비용과 시간이 너무 많이 들기 때문이다. 따라서 검증할 것을 적당히 조율하면서 어느정도 Risk도 감수를 하면서 프로젝트를 진행해야 한다. 이때 발생한 Risk는 별도의 Risk 관리를 통해서 제어를 해야 한다.

프로젝트는 "해봤더니 안되더라"가 아니다.
그렇다고 모든 것을 검증하면서 할 수는 더욱 없다.
적절한 프로토타입을 통한 검증과 적절한 Risk관리를 병행하는 것이 가장 효율적이다.

Image by Randomskk
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. 프로토 타입 코드는 가능성을 타진하는 것이니 품질에서는 상관없이, 오로지 가능성 타진에 초점을 둬야 하고, 그 때 쓴 코드는 절대로 재활용해서는 안되고, 폐기 처분 해야 한다!!!
    항상 이 말을 하는데도, 담당자들은 뭐가 아쉬운지, 재활용하려고 하네요... Copy & Paste 신공이 있는데 왜 못 쓰게 하냐고...

    "모든 로직은 네 머리 속에 있잖아... 너를 믿어..." 라고 말해줍니다.

  2. 안녕하세요. 디밥님

    Copy & Paste는 지옥의 시작이라는 것을 알아야 하는데 말이죠.

  3. copy & paste 와 reuse의 차이점이 무얼까 갑자기 고민이 들게 되네요 ㅎㅎ

    프로토타입이라고 해서 거기에 들어가는 라이브러리나 함수이름들이
    실제 개발시에 사용하지 않는것도 아니고 단지 예외처리부분이 빠졌을 뿐 실제 작성될 코드와 거의
    코어로직은 동일할텐데 다시 백지에서 부터 개발하라고 한다면
    개발자에게 조금 잔인한 처사 같은데요 ㅠ.ㅠ

  4. 구차니님 안녕하세요.

    Copy & Paste의 진정한 지옥은 소스코드를 여기저기 복사해서 회사에 비슷한 소스가 여러벌 존재하는 것이죠.

    프로토타입은 버린다고 생각하고 만드는 것이지만, 그 Logic은 다시 쓸 수 있죠.
    그렇다고 프로토타입을 만들 때 복사해서 쓸 것을 예상해서 코딩 규칙도 지키고 제대로 하려면 시간이 더 많이 걸립니다.
    백지부터 타입을 하는 것은 아니죠. ^^
    가장 빠르게 검증 목적으로 만든 경우는
    기존 소스코드를 그대로 붙여 넣기를 할 수는 없고, 붙여넣더라도 함수이름도 다 바뀌고 90%는 바뀔 겁니다.
    프로토타입이 재사용이 충분히 가능하도록 잘 만들어졌다면 시간을 좀 많이 쏟은 것이 아닌가 생각해볼 필요도 있을 것 같습니다.

  5. 저는 프로토타입을 꼼꼼하게 만드는 사람을 많이 봤습니다 ㅡ.-;;;
    프로토타입만드는데 변수명하나하나까지 고민하죠;;

    속으로
    "그 정성으로 주석이나 재대로 달라고!!!"
    라는 생각을 했습니다.

  6. 당근천국님 안녕하세요.
    동감입니다.

  7. 프로토타입의 재사용에 대해서는 의견이 분분할 수 밖에 없을것 같습니다. 코딩을 많이 하다보면, 변수 이름, 함수 이름등은 당연히 다시 사용할만큼의 이름을 가질 것 같습니다. 코딩 규칙도 마찬가지구요. 주석이야 없을 수 있다고 하지만, 경험자에 의해서 잘 만들어진 프로토타입의 소스는 다시 쓸 가치가 있을 것 같습니다.

    꼭 버려야만한다고 생각하지는 않습니다.

  8. zelon님 안녕하세요.

    이분법으로 얘기하기 어렵지만 원칙은 있습니다. 이에 관련된 글을 한번 올릴께요.

    감사합니다.

스펙에 있어서는 안될 표현들

2011.06.20 19:06 by 전규현


잠시 후 Google blogger로 이동됩니다.





필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다.

스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다.

사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다. 비즈니스 관련된 부분은 예외이다. 

그럼 스펙을 작성할 때 피해야 할 표현들에는 어떤 것이 있나 알아보자.

SMTP를 지원해야 하다.
지원한다는 말은 대단히 모호한 표현이다.  지원해야 하는 범위를 아주 구체적으로 기술해야 한다.

1~5의 값을 가진다.
1,2,3,4,5인지? 1,3,5인지? 1~5의 float값인지? 그 정밀도와 가질 수 있는 값을 정확하게 기술해야 한다.

데이터를 효율적으로 저장해야 한다.
효율적이라는 표현은 모호한 단어로서 피해야 한다. 메모리나 CPU 자원 대비 효율적인지,  Storage 용량을 적게 차지해야 하는지, 성능이 중요한지 구체적으로 적어야 한다. 또한 정확하게 요구되는 수준을 수치로 표시하는 것이 좋다.

사과, 배, 복숭아 등등을 지원해야 한다.
등등은 사용해서는 안된다. 지원해야 하는 모든 항목을 다 나열해야 한다.

기존의 값과 동일하다.
기존이 무엇인지 구체적으로 명시를 하고 해당 문서가 있으면 Link를 걸어줘야 한다.

충분한 메모리를 할당해야 한다.
충분하다는 것이 정확하게 얼마인지를 명시해야 한다.

사용자에게 친숙한 화면을 제공해야 한다.
어떠한 사용자가 친숙함을 느끼기 위해서 제공해야 하는 정확한 요구를 구체적으로 설명해야 한다.

일반적인 조건을 모두 만족해야 한다.
일반적인 조건을 구체적으로 기술해야 한다. 또한 일반적이지 않은 상황에서 시스템이 어떻게 되는지도 설명이 되어야 한다.

필요한 경우 메모리를 추가로 할당한다.
필요한 경우를 정확하게 판단할 수 있는 조건을 구체적으로 설명해야 한다. 수치가 나오면 좋다.

이외에도 수많은 표현들이 있다. 개발자라면 적어도 개발문서에서 이런 표현들이 나오지 않도록 항상 조심하는 습관을 갖는 것이 좋겠다. 이것도 하루아침에 이뤄지지 않는다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
churl
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석

  1. Blog Icon
    M

    모호한 표현을 피하고 구체적으로 기술해야 된다가 핵심이군요. 두 번 물어보게 만들지 않게 한다도 통하는 말일듯 해요.

  2. 안녕하세요. M님
    습관이 중요합니다.

  3. 글 내용에도 있지만, Business Logic에 해당하는 부분은 열외이기는 하지만, 기술적인 부분과 섞여 있을 때가 난감합니다. 보통의 경우 SRS를 확정지으려고 하지 않고, 자꾸 뒤로 미루는 경우가 많거든요.

    개발자들도, 실제 개발에 쓰는 용어와 고객과의 대화시에 쓰는 용어를 구별해서 썼으면 좋겠는데... 개발할 때 두리뭉실 하는 경우가 많네요. 이러면 안되는데...

    또한가지 개발자들이 자주 놓치는 부분이 "단위" 표기 입니다. 시간인지 분인지, Kg인지 g 인지 등등 이 점이 굉장히 중요하다고 생각하는데, 의외로 많이들 놓치더군요.

  4. 디밥님 안녕하세요.
    개발자들은 결정을 하지 않고 자꾸 뒤로 미루려는 성향이 있습니다. 하지만 뒤로 미룰수록 더 복잡하고 비용이 많이 들기 때문에 미리 결정할 수 있는 것들은 최대한 빨리 결정해서 확정을 하는 것이 중요합니다.
    좋은 의견 감사합니다.

  5. 개발용 문서를 보면 확실이
    이전 버전과 동일 이라는 말 만큼 짜증나는 문장도 없는것 같아요 ㅋ

  6. Blog Icon

    비밀댓글입니다

  7. Blog Icon
    정도유

    스펙을 주고 외주개발한다는 가정하에 작성하는 것이 좋습니다.
    그리고 문서든 코드이든 Review를 하는 것이 가장 좋습니다.
    Review는 SE 분야에서 연구자와 실무자가 모두 품질 향상에 도움이 된다고 인정한 유일한 툴입니다.

  8. 정도유님 안녕하세요.
    이말을 제대로 이해하고 있는 개발자나 경영자는 정말로 만나보고 어렵습니다. ^^

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바