태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

2013/05/14 23:29 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





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


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


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


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


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


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


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


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


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


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


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


image by Kingfox





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

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

Trackback Address: http://allofsoftware.net/trackback/310 관련글 쓰기
  1. 저는 하위버전 호환성을 유지하는 것이 매우 중요하다고 생각합니다.

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

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

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

  2. 공감합니다.

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

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

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

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

2013/03/14 19:05 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





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

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


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


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


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


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


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




image by naotakem

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

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

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

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

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

  4. Blog Icon
    권인호

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

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

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

2012/09/24 06:00 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




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


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


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


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


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


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


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


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


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


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


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


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


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


image by explainthatstuff


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



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

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

Trackback Address: http://allofsoftware.net/trackback/280 관련글 쓰기

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

2012/08/30 01:40 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



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


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

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

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


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

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


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

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


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


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


1. 시장 상황의 변경

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

3. 기술 환경의 변화

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

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

6. 경영진의 변덕

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


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


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


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


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


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


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


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


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


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


image by  m.a.r.c.


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


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

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

Trackback Address: http://allofsoftware.net/trackback/279 관련글 쓰기
  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 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



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


이 경우 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



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

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

Trackback Address: http://allofsoftware.net/trackback/270 관련글 쓰기

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

2012/01/27 23:51 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss 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 

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

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

Trackback Address: http://allofsoftware.net/trackback/251 관련글 쓰기
  1. Blog Icon
    althea

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

  2. 안녕하세요. althea

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

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

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

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

2011/11/14 06:20 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image by ッ Zach Hoeken ッ


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

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

Trackback Address: http://allofsoftware.net/trackback/246 관련글 쓰기
  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 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



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

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

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

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

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

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

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

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

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

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

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

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

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

Trackback Address: http://allofsoftware.net/trackback/241 관련글 쓰기
  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 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Trackback Address: http://allofsoftware.net/trackback/225 관련글 쓰기
  1. Blog Icon
    M

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

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

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

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

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

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

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

  6. Blog Icon

    비밀댓글입니다

  7. Blog Icon
    정도유

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

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

개발문서를 만들기는 했는데 업데이트가 안되는 이유

2010/03/24 20:07 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


필자는 여러 소프트웨어 회사들의 컨설팅을 진행하면서 먼저 회사의 분석을 위해서 그 동안 소프트웨어를 개발하면서 만들어 놓은 문서를 요구합니다. 사실 문서만 봐도 회사의 개발현황을 대부분 알 수 있습니다.

그런데, 제대로 작성된 문서를 제시하는 회사는 거의 없다시피 합니다. 물론 Wiki나 Google Docs등의 온라인 문서를 포함해서 제대로 작성된 문서는 거의 없습니다. 가끔 문서를 제시하는 회사들이 있기는 하나 수년간 전혀 업데이트를 하지 않아서 쓸모가 없어진 것들 뿐입니다. 

정리를 해보면 다음과 같습니다. 

  • 문서가 아예 없거나 없다시피 한 회사
  • 몇 년동안 업데이트 안된 문서들만 있는 회사 (오늘의 주제)
  • 쓸모없는 문서들을 너무 많이 만든 회사 

야심차게 문서 한번 잘 만들어보겠다고 결심하고 개발 시에 문서를 열심히 만든 후에 소프트웨어는 계속 업그레이드가 되는데 문서는 과거에 머물러 있는 경우에 대해서 얘기를 해보겠습니다.

이런 문서는 죽은 문서입니다.

내용이 맞는지 틀리는지 확인이 안되는 문서는 혼동을 일으킬 수 있습니다.
이런 일이 발생하는 이유는 여러 가지가 있지만 대표적인 이유로는 진짜 문서가 필요해서 만들었다기 보다는 문서가 필요하다고 하니까, 또는 위해서 시켜서 만들었는데, 막상 개발에 크게 도움이 안되고, 단순히 문서를 만들었다는데 의의를 두는 경우가 있습니다. 또, 문서를 너무 잘(많이) 만들어서 소프트웨어가 업그레이드 될 때마다 문서를 갱신하려고 하니 초기 개발 때에 비하여 유지보수 시는 급하게 개발하는 요청이 많아서 미처 문서까지 갱신할 시간이 없는 경우도 있습니다.

이런 경우 모두다 "문서를 위한 문서"인 경우입니다.

문서가 진짜 필요해서 만든 경우가 아니라는 얘기입니다. 역량이 충분히 성숙되기 전에 문서 작성 문화를 정착하려면 어떻게 해야 할까요?

문서를 적게 만들어야 합니다. 

적게 만들면서도 개발에 유용해야 합니다. 그래야 문서를 만드는 일이 프로젝트에 큰 부담이 되지 않고, 추후 업데이트가 가능해집니다.

오래 되어서 쓸모 없어진 문서를 책꽂이에 잔뜩 꽂아 놓고 "옛날에는 문서를 열심히 만들었는데"하고 회상 하십니까? 지금은 그렇게 하고 있지 않다면 효과적이지 않은 방법으로 문서를 만들면서 조직 내에 정착되지 못한 겁니다. 문서 작성을 문화로 정착하려면 "작고 효율적으로 문서 만드는 법"을 익혀야 합니다.

왠만한 크기의 프로젝트도 문서는 한 두 개로 충분합니다. 스펙문서(SRS)와 경우에 따라서 설계문서 정도를 만들면 됩니다. 스펙문서는 요구사항을 분석하는 방법, 꼭 필요한 내용을 적는 방법, 리뷰하는 방법 등을 익혀야 합니다. 요즘은 스펙을 적는 방법에 있어서 다양한 시도들을 하고 있지만, 방법은 조금씩 달라도 꼭 필요한 내용을 빠짐없이 효과적으로 적어야 합니다.

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

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

Trackback Address: http://allofsoftware.net/trackback/182 관련글 쓰기
  1. 저는 문서를 적게 만드는 것 보다는,
    doxygen이나 ea 또는 여러 툴들을 병행해서,
    문서 작업을 별도로 하지 않아도 항상 up-to-date 하게 만드는 것도 좋은 방법이라고 생각이 듭니다.

    셋팅하는게 귀찮지만 말이죠. 한번 하면 인수인계나, 관리할때 편하거든요.. :)

  2. 안녕하세요. PatternLoad님

    Doxygen이나 JavaDoc을 이용하는 것은 Low level design 문서 용도로 아주 좋은 방법이죠. 귀찮더라도 이런 규칙은 프로젝트 초기부터 정하게되면 모두 따르도록 어느정도 강제가 필요합니다. 하지만 Doxygen도 업데이트 안하는 경우도 있더군요. - -;

    스펙은 또다른 이슈입니다. 다른 방법이 별로 없습니다. 툴을 이용하는 것도 분석 작업과 업데이트를 대신해주지는 않습니다.

  3. 예 그렇죠. 스펙은 아무래도 서로 협의하고 조율해야 되는 부분이니깐요. 정말 게으름과 싸워 이기는 문제는 힘들죠.. 전 SparxSystems의 Enterprise Architect로 이러한 환경을 통합할려고 노력하고 있습니다. 툴이 대신 업데이트 해주지 않아도, 어느정도 연관성을 충분히 잡아주는것 같습니다. 물론 이런일도 꽤 번거로운건 사실이죠.. :)

  4. 저는 문서에 대한 활용도(접근성 및 검색 용이성)가 높다면 그만큼 최신 내용으로 업데이트 될 가능성이 클거라고 봅니다. 이전 회사에서는 항상 MS워드로 문서를 만들고 게시판에 등록시키도록 강요했습니다. 지식검색시스템을 구축해놓고 윗분들이 보기에 좋은 형상을 만들어 놓은거죠. 하지만 실무에서는 검색도 안되고 접근도 용이하지 않았습니다 (다운로드해서 업데이트 해서 다시 올리고..ㅡㅡ)
    전 외부 공개용 문서(메뉴얼등)를 제외하고는 쉽게 활용가능한 툴을 쓰자고 제안했었습니다. 그 방안으로 위키를 제안했었는데 묵살당했죠...ㅋㅋㅋ 로우레벨 문서는 저도 doxygen이 좋은듯..

  5. 안녕하세요. 청하님
    문서를 작성하기 어려우면 툴은 더욱 쓰기 어려운 측면이 있습니다. 결국은 어디다기 쓰느냐보다도 무엇을 어떻게 쓰느냐가 핵심입니다. 또한 몇십년전부터 이런 시스템이 없었을 때도 문서를 작성하는데 문제가 있는 것은 아니었습니다.
    저도 이런 시스템을 도입하는데는 긍정적으로 생각합니다. 다만 문서를 먼저 쓰고 리뷰하는 것을 할 줄 알아야 됩니다.

  6. 위키는 위키문법의 장벽이 무시 못하고
    그래서 fckeditor + mediawiki 혹은 fckeditor + dokuwiki로 하려고 했는데
    아무도 안하시더라구요 ㅠ.ㅠ


    언젠가 한번 doxygen을 시도해봐야할꺼 같아요..

  7. 안녕하세요. 구차니님
    그렇게 쉽게 바뀌면 정말 좋겠습니다. ^^
    사람들은 바꾸려고 하지 않는 것이 습성입니다. 일단 익숙하지 않아서 불편해하고, 바꾼다고 나아진다는 확인이 없고, 일이 더 많아지고 귀찮아질까봐 바꾸지 않습니다.
    Doxygen도 시도해보고 알아봐 놓는 것은 좋으나 혼자서 열심히 하다가는 혼자만 바쁘고 그 결실은 다 같이 나눠가지다가 금방 포기하고 맙니다. 이런 것은 회사차원에서 강제성을 가지고 추진해야합니다.

  8. Blog Icon
    koraper

    저도 작년부터 설치형 게시판, fckeditor + mediawiki 등등등 문서 정리를 위해서 많은 것을 시도해 보고 있는데 강제가 없으면 중간에 잘 안되더군요.
    그래서, 전략을 좀 수정했습니다. 우선 제가 강제 할 수있는 프로젝트 팀부터 고과에 반영한다고 엄포를 놓아서 조금씩 해보고 있습니다.^^;
    이게 성과가 잘 나오면 전사적 도입도 시도 할 수 있을 것 같아서요....
    항상 제가 고민하는 내용을 시의적절하게 포스팅해 주셔서 감사합니다.

  9. 안녕하세요. koraper님
    전사적인 시행이 어렵다면 시범프로젝트에서 성공사례를 보여주고 설득하는 것도 오래걸리기는 하지만 좋은 방법입니다.

  10. 변화되는 것은 사람의 활동이고 좀 처럼 변화되지 않는 것은 문서라고 생각해 봅니다.
    으쌰으쌰 해서 잘 된 문서를 만들었다고 해도 이 후에 누가 사용할지 ,또는 어떤 환경요소에 따라서 처음 문서제작의 의미가 살아나거나 또는 죽거나 하는것 같아요.
    경험적으론.. 대 다수의 프로젝트가 말씀하신것처럼 '문서을 위한 문서'가 대부분이었던 것 같습니다. 또는 윗선에 보여주기 위한 방편이 많았던 것이 분명했습니다.

    이를 개선해 보고자.. DDD에서 말하는 Context Map이라던지, Context Integration과 같이 시간이 지남에 따라 문맥이 흐려지는 것을 막기 위한 전략도 어느정도 타당성이 있어 보이지만..(이게 과연 현실적으로 가능할지..이론적인 것만은 아닌지 더 경험해 봐야만 하는 그런 종류의 것인것 같습니다.)
    문서작업을 대부분 싫어해서도 그렇고, 윗선에 보여주기위한 문화라던지, 아니면 문서나 소프트웨어를 인질극으로 삼으려고 하는 사람에겐.. 여간 귀찮은 장애물이 되지 않을까 합니다.

    프로젝트 진행이나 의사소통이 하도 되질 않아, 어느정도 강제적인 강압도 필요한 적도 있었습니다. 하지만만 지속적인 강압은 제일 좋지 않은 결과를 낸 것 같은 아쉬운도 많이 남았습니다.

    항상 저도 이와 같은 고민을 하고 살아요. 어떻게 하면 개선할 수 있을까? 어떻게 하면 모순을 없앨 수 있을까? 정작 중요한것은 개인의 실력일까 아니면 팀웍 콘트롤일까? 신기술이 중요할까 아니면, 타당성 있는 기술이 중요할까 등등..

    규현님 글보면 어찌 제 생각이랑 일치한지~

  11. moova님 안녕하세요.
    그래서 항상 개발 문화를 강조합니다.
    자연스럽게 무슨 일을 하던지 문서화를 하는 수준까지 되어야 합니다.
    꼭 필요한 소수의 문서를 알맞게 만드는 것이지요.
    말로 때우는 방식은 더이상 안됩니다.
    그렇게 문서를 만드는 것이 가장 빨리 개발하는 방법이라는 것을 깨달아야 합니다.

  12. SRS가 업데이트가 되지 않고 공유도 안되면서 Test Case 문서랑 매치 하려니 여간 답답한 일이 아닐 수 없지요. 뭐 제가 파견 나가 있는 삼X전자 또한 뭐 해당 문제들이 비일비재 합지요.

  13. hoya님 안녕하세요.
    그런 케이스는 거의 주먹구구 방식과 다를바 없습니다. 삼X전자에서는 뭔가 체계를 갖추고 근사하게 개발을 하고 있다고 착각할지 모르지만 실리콘밸리의 구멍가게 소프트웨어 회사보다도 못하다는 것을 아직도 깨닫고 있지 못합니다.
    그러면서 우리나라의 중소 소프트웨어 회사들의 씨를 말리고 있죠.

  14. 기존 문서에 대한 고정 관념을 좀 버렸으면 합니다.
    프로젝트를 진행 하다 보면 문서 관리에 대해서 반드시 MS의
    word나 ppt 등 특정 파일 포맷으로만 관리 하려고 합니다.
    물론 이런 포맷이 쓰이는 문서도 있지만 이틀에서 벗어나면
    문서가 아닌 것으로 생각해서 도입을 하지 않습니다.
    저런 형식적인 문서보다 차라리 사내에 허접한 게시판 하나
    를 만들어서 히스토리 관리 하는게 더 실용적이라고 생각이
    듭니다.

  15. 안녕하세요.
    맞습니다. 어디에 적느냐가 아니고 내용을 작성하는게 중요하죠.
    내용을 적을 능력이 없는 사람들은 또 어디에 적더라도 안되기는 마찬가지입니다. 그래서 안된다고 툴만 찾아다기 보다는 무엇을 어떻게 적을지 배워서 꾸준히 해보는 것이 중요합니다.

  16. Blog Icon
    토토제작

    2011년-사설토토제작 판매

    ❤직접 눈으로 확인하시고 결정하세요

    토토사이트 전용 자바 프로그래머와 전문 디자인너 로 구성되어 빠른 제작과 지속적으로 유지보수 및 서버운영까지 풀 서비스 하고 있습니다 한번 고객은 또 다른 분으로 연결되고 서버 및 유지보수에 안정된 관리로 인정받고 제 구매를 해주시는 믿음과 실력으로 인정받고 있는 작업장 입니다 *사설토토

    사용자 패이지

    고급스러운 이미지와 다양한 기능으로 유저에게 보다 신뢰 있게 다가 갈수 있도록 전문 디자인너가 충분한 상당 후 제작해 드립니다 또 요즘 무엇이 인기이고 유행인지를 꾸준히 파악하고 한발 앞서 실행과 유행을 창조하고 있다고 자부합니다
    (참고로 원하시는 사이트 디자인 100% 똑같이 도 가능합니다)


    관리자 패이지

    자동방식과, 엑셀방식. 수동방식 모두 겸비한 최신형 버전입니다
    저희가 직접 자바언어로 제작해서 판매하고 있습니다
    즉 돌고 도는 소스가 아님을 분명히 말씀 드립니다 또 직접 제작한 소스라 수정 및 유지보수가 원활합니다 기능은 너무 많아서 여기서는 생략 하겠습니다 오셔서 상담 받으시고 직접 조작해보시면 됩니다 *사설토토


    계약절차

    1번 제작사이트의 요구사항을 문서로 만들어서 주세요 ( 기능, 디자인, 로고 )
    2번 계약금 100만원 입금
    3번 서버계약 ( 일본서버,미국서버,홍콩서버 선택 )
    4번 세팅 및 디자인 작업
    5번 중도금 100만원
    6번 완성확인 후 잔금처리
    7번 유지보수 및 서버 관리 ( 선택 )


    사이트 제작비용은 총 4백입니다
    서버 관리는 원하시는 분에서만 월 소정에 관리비 받고 관리해 드립니다(도메인 등록, 서버세팅, 서버이전, 아이피 변경, 등등 24시간 관리해 드립니다)
    총 제작기간은 1주일에서 상항에 따라 2주 정도 입니다

    @소스언어는 자바입니다
    @상담시 프로그래머인 제가 통화합니다
    @직원&투자자 소개 및 동업자 연결시켜 드립니다



    msn 메신저 toto8949@hotmail.com

    msn 메신저 모르신 분
    검색창에 msn메신저 설치 검색하시고 설치하시면 됩니다.
    홍콩서버,미국서버,일본서버,사설토토제작

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

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

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

소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다. 소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다 하지만 우리나라에서 "요구사항분석" 역량을 제대..

투명한 개발 문화의 효과

흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자. 투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다. 거의 모든 결정의 과정 및..

소프트웨어공학은 실전이다.

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다. 2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요. 알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스..

거의 다 만들었어요.

"거의 다 만들어서 2주후에 개발이 끝나요" 이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다. 개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다. 하지만 이런 대화는 여..

고쳤으니 테스트 해주세요.

여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자. 첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다. 테스트 한사이클을 도는데 2주일이 걸린다고 생각..

인해전술이 오히려 프로젝트를 망친다.

일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다. 프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다. 많은 인력을..

1:10:100 rule
1:10:100 rule 2013/02/05

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다. 성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고..

티끌모아 태산 (개발 시간 절약하기)

성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다. 하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이..

재택근무가 가능한가?

우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효..