기능(Feature)이란 무엇일까요? 조금은 학문적으로 정의해 보겠습니다.

• 시스템이 해야 할 일을 추상적으로 설명한 것
• 마케팅을 위해 유사한 다른 시스템의 기능과 비교하여 우리의 시스템의 특징을 표현한 것

네, 참으로 추상적입니다. 그리고 어렵죠? 그래서 Feature는 요구도출시 명확하게 도출되지 않을 수도 있습니다. 다행스럽게도 이 Feautre를 찾아볼 수 있는 방법이 있습니다. 우리가 프로젝트를 수행하게 되는 전/후 과정을 살펴보면 참조할 수 있는 몇몇 문서를 발견할 수 있습니다.

• RFP(Request For Proposal)
• RFP(Request For Information)
• 제안서
• 유스케이스 & 보충명세

내부 프로젝트에서는 이런 것이 없다구요? 네. 맞습니다. 그래서 내부 프로젝트에서는 비전(Vision)이란 문서를 만드는 것이 적합할 것 같습니다.. 그럼 비전 문서에는 어떤것이 들어가야 할까요? 우리가 이 프로젝트를 하는 이유, 이 프로젝트를 통해서 얻을 수 있는 이득과 같은 것을 작성하시면 됩니다. 방법론에서는 아직 비전에 대해서 명확하게 정의내리지 못했으므로 여기까지만 설명드리도록 하겠습니다.

기능(Feature)을 도출하였다면 우리가 개발하는 시스템에 부합하는 것인지 확인이 필요합니다. Feature는 뜬금없이 나오는 것이 아닙니다. 동의하실지는 모르겠지만 이해당사자의 요구(Need)에 기반하여 도출되는 것입니다. 따라서 Feature가 어느 요구(Need)로부터 왔는지 확인할 필요가 있으며 그렇지 않은 것이 있다면 우리는 Feature를 잘못 도출한 것이라고 할 수 있습니다.

기능(Feature)이 이해당사자의 요구(Need)로부터 도출되었음이 확인 되었다면 이들간의 추적관계를 기록할 필요가 있습니다. 우리는 이것을 "요구사항추적"이라고 합니다. 요구사항추적은 형상&변경에서 자세하게 설명하겠습니다.

기능목록의 예시는 다음과 같습니다.

ID	설명	이해당사자요구	우선순위	등급	대상릴리즈	상태
FEAT-001	임직원의 가동율 파악	NEED-001, NEED-003	상	1	#1	수락
FEAT-002	임직원의 개인역량 파악	NEED-001, NEED-002	상	2	#2	수락

다음에는 용어에 대해 설명드리겠습니다.

우리는 흔히 이해당사자를 고객사의 현업뿐이라고 생각하고 있지만 명확한 의미에서의 이해당사자는 해당 프로젝트에서 이해관계(정보를 제공, 결과를 사용, 결과를 만드는)를 가지고 있는 모든 사람들을 의미합니다.

내 부 프로젝트인 경우에 흔히 "고객이 없다."라고 얘기하기도 합니다. 하지만 내부 프로젝트에서도 고객은 있습니다. 프로젝트는 프로젝트를 만든 사람(대표이사, 임원 등)이 있습니다. 이제 아시겠죠? 프로젝트를 만든 사람이 바로 이해당사자의 유형 중 하나인 고객입니다.

프로젝트 이해당사자를 도출하는 일반적인 방법은 다음의 질문을 자신에게 던져보는 것입니다.

• 이 프로젝트 발주의 최종 권한자는 누구인가?
• 이 프로젝트에 직접적으로 참여하는 사람 또는 역할은 누구인가?
• 이 프로젝트의 결과물인 소프트웨어를 사용하는 사람 또는 역할은 누구인가?
• 이 프로젝트의 결과물인 소프트웨어를 만드는 사람 또는 역할은 누구인가?
  

위의 질문에 대한 대표적인 대답의 예는 다음과 같습니다.

• 프로젝트 발주사의 CEO/CTO/CIO
• 프로젝트 발주사의 PMO
• 프로젝트 발주사의 프로젝트 TFT 멤버
  
• 프로젝트 수행 결과인 소프트웨어를 사용하는 사용자
• 프로젝트 수행팀(PM, 비즈니스/시스템분석가, 시스템설계자, 개발자 등)

이해당사자 분석은 다음과 같은 절차로 수행합니다.

1. 이해당사자 요약: 이해당사자는 대부분 사람이 아닌 역할입니다. 따라서, 사람이 아닌 역할을 중심으로 생각해야 합니다.

   이해당사자	설명	영향
   경영진	프로젝트를 발주하고 프로젝트의 최종 결과물을 확인합니다.	프로젝트 후원
   프로젝트 수행팀	이해당사자의 요구를 도출하고 이를 기반으로 프로그램을 개발합니다.	프로젝트 수행
   임직원	프로그램을 사용하여 태스크를 할당/수락/수행/완료합니다.	최종 결과물 사용

   
   
2. 이해당사자 대표 식별: 이해당사자가 역할이므로 해당 역할을 수행하는 사람은 최소 1명에서 N명이 될 것입니다. 이렇게 많은 사람을 만나서 그들이 얘기하는 요구를 모두 식별하는 것은 현실적으로 어렵습니다. 가끔은 이들의 요구가 서로 상충되기도 합니다. 그리고 고객사에서도 많은 사람들을 프로젝트에 참여시키지도 않습니다. 따라서 이해당사자 역할을 대표하는 사람 몇명을 프로젝트에 참여시킵니다. 여기서는 이해당사자를 대표하는 사람(대부분 프로젝트 TFT 멤버)을 식별하고 그들이 프로젝트 전체 활동중에서 참여해야 하는 활동에 대해 정의하고 그들에게 설명합니다.
   

   대표이름	연락처	이해당자사 유형	권한수준	책임
   나경영	010-1111-1111 ceo@a.com	경영진		요구도출 인수테스트
   나피엠	010-2222-2222 pm@b.com	프로젝트 수행팀		요구도출 분석 설계 구현 테스트 배포
   나직원	010-333-3333 emp@a.com	임직원		요구도출 인수테스트

   
   
3. 이해당사자 요구 식별: 이해당사자 대표는 그들이 대표하는 이해당사자들과 얘기하여 해당 역할이 요구하는 것을 얘기해줘야 하는 의무를 가집니다. 그리고 우리들은 이해당사자 대표가 얘기하는 요구를 들어줄 필요가 있으며 때로는 그들이 필요로 하는 것을 얘기할 수 있도록 이끌어줘야 합니다.
   

   ID	요구명	설명	근거	수익성
   NEED-001	임직원의 태스크 수행 현황 모니터링	임직원이 처리하는 태스크에 대한 현황 및 통계	회의록-2011.11.12	상
   NEED-002	임직원의 태스크 수행 역량 모니터링	임직원의 개발 태스크 처리 역량	회의록-2011.11.12	상
   NEED-003	임직원이 프로젝트에 참여하는 비율	임직원이 프로젝트에 참여하고 있는 비율에 대한 통계	회의록-2011.11.12	중

   
   
   

요구도출에서 무엇보다 중요한 것은 이해당사자를 이해하는 것입니다.

이해당사자의 요구를 어떻게 잘 이해할 수 있을까요? 이해당사자의 요구를 한번에 그것도 명확하게 이해할 수 있는 방법이 있으면 얼마나 좋을까요? 하지만 현실은 그렇지 않습니다.

폭포수방법론에서는 이해당사자의 요구를 한번에 그것도 명확하게 수집할 수 있다고 가정하였습니다. 그래서 그 시절에는 요구수집(Gathering)이라는 말을 썼습니다. 그런데 이 Gathering이라는 말에는 근본적인 오류가 있습니다. 그 오류는 바로 이해당사자는 자신의 요구를 다 알고 있으며 이를 잘 표현할 수 있으니 요구를 잘 받아적기(Gathering)만 하면 된다는 것입니다.

하지만 현실은 어떤가요? 소프트웨어 개발을 완료한 후 이해당사자에게 보여주면 이해당사자는 "음.. 이게 아니라 이런 거였는데요..."라는 말을 자주 합니다. 이런 일이 계속 발생하다 보니 요구수집에 대한 가정에 오류가 있다는 것을 깨달은 선각자들은 요구수집이란 단어에서 요구도출(Elicitation)이라는 단어로 변경했습니다. 즉, 이해당사자는 자신의 요구가 무엇인지 잘 알고 있지 못하고 이를 표현할 수 있는 역량도 부족하다는 것입니다. 그래서 소프트웨어 업계에 종사하는 우리들이 이해당사자의 요구를 잘 끌어내 줘야 한다는 것입니다.

앞서 설명했듯이 요구 도출은 단순히 고객과 얘기하고 그 결과를 기록(Gathergin)하는 것이 아니라 그들이 요구하는 것을 뽑아내야(Elicitation)한다는 것입니다. 요구도출이라는 것이 매우 복잡하고 어려운 주제이다 보니 공학적으로 접근해 보자는 시도를 하기 시작했으며 그 결과로 "요구공학"이란 개념이 나타났습니다.

그럼 공학이란 무엇일까요? 쉽게 설명하자면 공학이란 문제를 체계적으로 접근해서 정답에 가까워지려는 노력입니다. 체계적으로 접근하려고 하다보니 절차(프로세스)가 있고 그 절차에서 정리해야 하는 것을 정의하게 됩니다.

요구도출 프로세스에 대해 알아보기 전에 이해당사자의 요구를 잘 도출하려면 어떤 지식이 필요할까요?

• 첫번째로 비즈니스(업무)를 잘 이해해야 합니다. 우리는 이것을 "도메인"이라고 부릅니다.
• 두번째로 소프트웨어와 소프트웨어가 개발되는 과정을 이해하고 있어야 합니다.
  

"요구공학"에 기반하여 이해당사자의 요구를 도출하는 과정(프로세스 & 방법론)에 대해 알아보겠습니다. 논리적 설명을 위해서 순차적으로 설명을 드리겠지만 요구도출은 1~6까지 서로 유기적이고 상호보완적인 관계를 가지면서 함께 작성되어야 하므로 이를 꼭 기억하셔야 합니다. 하지만 고객은 이러한 절차에 대해서 잘 알지 못하고 이해하기도 힘들며 이해하려고 하지 않으므로 고객에게 이 절차를 설명하려 하지 마시고 프로젝트 팀내에서만 이 절차를 주지하시고 진행해야 할 겁니다. 요구도출의 절차는 다음과 같습니다.

1. 이해당사자 분석
2. 기능(Feature)목록 작성
3. 용어집 작성
4. 유스케이스모델조사
5. 유스케이스명세서 작성
6. 보충명세서 작성

(위의 절차를 미리 읽으셨으면 아래의 내용을 읽을 필요는 없습니다. 아래는 현재 작업영역인 요구도출에서 전체적인 뷰를 제공하기 위함입니다.) 이제 이런 체계적인 접근법으로 요구를 잘 도출했으면 어떻게 정리해야 할까요?

1. 이해당사자에 대해 정리합니다.
2. 이해당사자는 너무 많으니 이를 대표하여 대화할 대표자에 대해 정리합니다.
3. 이해당사자가 소프트웨어를 개발하려고 하는지에 대한 이유(요구)를 정리합니다.
4. 이해당사자가 왜 소프트웨어를 개발하려고 하는지 정리되었으면 개발하는 소프트웨어의 특징(Feature)을 정리할 수 있습니다.
5. 이제 이해당사자와 우리가 대화할 수 있는 용어를 정리하여 대화의 물꼬를 틉니다.
6. 이해당사자와 대화를 통해 시스템이 제공해야 하는 기능을 유스케이스로 정리합니다.
7. 시스템이 기능을 제공하는데 부과되는 제약(품질속성)을 정리합니다.

이와 같이 요구도출을 잘 수행하였다면 도출된 요구 그리고 이와 관련된 내용을 정리할 산출물은 다음과 같습니다.

• 이해당사자분석
• 기능(Feature)목록
• 용어집
• 유스케이스모델조사
• 유스케이스명세서(N개)
• 보충명세서
  

다음에는 이해당사자 분석에 대해 설명드리겠습니다.

"새 술은 새 부대에..."라는 말이 있습니다. 프로젝트를 수행함에 있어서 개인의 역량은 그 무엇보다 중요합니다. 하지만 팀원이 이해할 수 없는 개인 역량을 서로에게 강제할 수는 없을 것입니다. 이를 해결하는 가장 쉽고 빠른 방법은 공통의 지식(다수의 세미나, 다수의 개발 관련 서적에서 공통으로 다루고 있는 이론적 배경 및 기법)을 습득하는 것이라 생각합니다.

우선 여러분께서 가지고 계신 경험 및 지식은 개인의 역량으로 접어 두시고 서로를 이해하기 위해 방법론을 새로운 시작으로 바라봐 주시기 바랍니다.

물론 프로젝트를 수행하다 보면 제가 설명드리는 것에 없는 활동과 산출물을 만들어야 하는 경우가 반드시 생깁니다. 그리고 대부분의 프로젝트에서 반드시 제출해야 하는 산출물이 계속되어 발견되면 방법론에 공식적인 활동과 산출물로 추가하시면 됩니다.

PM 역할을 수행하시는 분들께서는 별도의 관리프로세스가 필요하지 않느냐는 질문을 하실 수도 있습니다. 프로젝트를 잘 수행하기 위해서는 관리자의 역량 또한 매우 중요합니다. 하지만 관리는 개발을 잘 알고 있어야 합니다. 그래야만 피(P)해야 하는 것이 무엇이고 막(M)아야 하는 것이 무엇인지 결정할 수 있습니다. 그리고 프로젝트 인도물로 관리 산출물을 제출하는 문서는 극히 일부분입니다. 이런 이유에서 저는 관리 프로세스를 별도로 두지 않습니다.

마지막으로 산출물과 인도물이 있습니다. 산출물은 프로젝트를 수행하면서 생산되는 모든 문서와 소스 파일을 의미하고 인도물은 산출물 중에서 고객에게 전달되는 서브세트입니다. 제가 소개하는 방법론은 고객에게 착 달라붙은 문서 작성은 지양하며 프로젝트 후반에 고객을 위한 인도물로 산출물을 별도로 정리하는 것으로 규정하였습니다. 이를 통해서 얻을 수 있는 대표적인 장점은 다음과 같습니다.

• 우리가 가지고 있는 대부분의 프로젝트 산출물은 일관된 모습을 갖추게 됩니다.
• 프로젝트 중반에 투입된 수행팀 팀원은 특정 폴더에 가면 미리 약속된 문서를 볼 수 있으므로 프로젝트를 파악하는 시간이 단축됩니다.
• 중복되기는 하지만 프로젝트를 종료한 후에 다른 사람이 하자보수를 해야 하는데 그 당시 팀원이 모두 다른 프로젝트 에 투입되었거나 퇴사하였다면 시스템의 전반적인 모습을 빨리 파악할 수 있습니다.
  

방법론을 이해하기 위해서는 배경이 되는 프로세스 프레임워크인 UP의 배경을 이해할 필요가 있습니다. 다음에서 UP가 집중하는 문제점과 이를  해결하기 위한 특징에 대해 설명합니다.

• 컴포넌트 기반 아키텍처 중심(향후 설명 추가 예정)
  
• 유스케이스 주도(향후 설명 추가 예정)
• 반복 및 점증적 개발 모델(향후 설명 추가 예정)

방법론에서 필요로 하는 선수 지식은 다음과 같습니다.

• UML(Unified Modeling Language) - 소프트웨어를 표현하기 위한 표준 표기법입니다.

방법론의 작업영역은 UP에서 정의한 것과 같이 10개의 작업영역으로 구분합니다.

• 비즈니스 모델링 - 정리중입니다.
  
• 요구도출 - 이해당사자와 이해당자사 대표, 그들의 니즈 그리고 시스템을 특징지을 수 있는 기능(Feature)을 식별합니다. 그리고 이것을 구체적으로 유스케이스와 보충명세서로 정리합니다.
  
• 분석 - 시스템에 필요한 도메인 모델을 만듭니다. 그리고 유스케이스 분석(사용자인터페이스, 시스템인터페이스?)을 통해서 시스템의 구체적인 기능을 도메인 객체와 연결지어 분석합니다. 식별되 기능을 비즈니스 컴포넌트의 책임으로 할당합니다. 이를 기반으로 소프트웨어아키텍처를 정의합니다.
  
• 설계 - 비즈니스 컴포넌트의 책임을 달성하기 위하녀 컴포넌트 내부를 설계합니다. 분석에서 식별된 사용자인터페이스와 시스템인터페이스(비즈니스 컴포넌트 포함)간의 협력을 정의합니다.
  
• 구현 - 모두 잘 아시는 부분으로 실제 코드를 작성합니다. 단위/통합 테스트를 함께 수행합니다.
  
• 테스트 - 유스케이스를 기반으로 인수테스트 케이스를 작성하고 이제 필요한 테스트데이터를 함께 정의합니다. 그리고 효율적인 테스트를 위하여 테스트케이스의 수행 순서인 테스트시나리오를 정의하고 인수테스트를 수행합니다.
  
• 배포 - CI(Jenkins + Ant)를 이용하여 개발계(?)에 반영을 자동화합니다.
  
• 환경 - 프로젝트 수행과 관련된 참고자료, 여러가지 가이드 문서를 작성하여 보관합니다.
  
• 관리 - 프로젝트의 단계 계확 및 단계 완료 검토 및 단계 중에 수행하는 반복 계획/결과를 정리합니다.
  
• 형상&변경 - 형상은 Subversion을 이용하고 V1.0과 같은 것은 SVN의 Revision을 이용합니다. 구현이 완료된 유스케이스 또는 새로운 기능의 요청을 추적합니다.
  

다음에는 실제 요구도출 개요를 설명드리도록 하겠습니다.

프로세스나 방법론을 공부하신 분들이라면 RUP(Rational Unified Process)라는 것을 많이 들어보셨을 겁니다. 인터넷에서 RUP로 검색해 보면 아주 많은 자료를 보실 수 있습니다. 하지만 대부분이 요약 수준의 자료뿐이라 그 진실(?)을 이해하는데는 한계가 있습니다. 그렇다고 그 자료가 가치가 없다는 것은 아닙니다. 좀 더 깊숙한 내면을 보기에는 어렵다는 것입니다.

앞으로 설명할 소프트웨어 개발 과정도 UP(앞으로 UP라고 언급하는 것들은 UP와 RUP를 포괄적으로 의미합니다.)를 기반으로 합니다. 따라서 UP에 대해 간략하게 설명하는 것이 필요하다고 생각합니다. 그래서 우선 UP에 대해서 간략히 설명하고자 합니다. 좀 더 깊이 있는 이해를 하고 싶은신 분들께서는 마지막에 관련 도서나 자료를 정리하니 그 목록에서 선택해서 보시면 될 것 같습니다.

우선 프로세스와 방법론에 대해서 말씀드려 보겠습니다. 제 주변 분들은 프로세스와 방법론이 같은 것이라고 오해를 많이 하고 계십니다. 저는 프로세스와 방법론을 다르게 보고 있으며 가장 큰 차이는

• 프로세스: 일을 처리하는 절차(순서)
• 방법론: 일을 처리하는데 사용하는 기법
  

라고 생각합니다. 조금 더 설명을 해 보자면 프로세스는 "어떤 자료가 있으면 그 자료를 참고해서 어떤 일을 해서 어떤 결과물을 내 놓는다."라는 것을 중심으로 설명합니다. 우리가 잘 알고 있는 업무 처리 방법이라고 생각하시면 될 것 같습니다. 방법론은 그 어떤 일을 하는데 어떤 기법을 사용하는지를 설명하는 것입니다. 따라서 기법이 추가되면 그 기법에 따라서 결과물(산출물)의 내용이 바뀝니다. 그런데 여기서 방법론을 설명하려고 하니 결국 절차(프로세스)로 설명할 수 밖에 없습니다.  그러다 보니 자연스럽게 방법론이 프로세스라는 개념을 포함하게 됩니다. 결국 프로세스와 방법론이 같은 것이라는 오해가 생기는 게 아닐까 생각합니다.

이제 UP를 간략히 살펴보겠습니다. UP는 누가 만들었고 이런 역사적인 내용은 각설하고 UP를 이해하는데 필요한(대부분은 인터넷에서 찾을 수 있는) 것을 그리고 믾이 접했을 만한 그림으로 다른 분들과 같은 요약 수준에서 설명해 보겠습니다. 하지만 조금은 다르게...

위의 그림은 소프트웨어를 개발하는데 소요되는 시간과 작업영역(흔히 부르는 요구/분석/설계/구현/테스트/배포)과의 관계를 한눈에 보여주는 그림입니다. 우리가 이 그림을 통해서 유추할 수 있는 것은 다음과 같습니다.

• 소프트웨어는 반복적으로 개발한다 - 폭포수 모델이 이해하기 쉽긴 하지만 소프트웨어는 반복을 통해 개발한다.
  
• 시간이 지나면서 우리가 집중해야 하는 역영은 변한다 - 그림에서 각 색이 칠해져 있는 부분이 우리의 노력을 집중하는 정도를 의미합니다. 즉, 프로젝트 초반에는 비즈니스 모델링(다루지 않음)과 요구도출에 상당히 많은 노력을 기울임을 알 수 있습니다. 그렇다고 분석/설계/구현/테스트/배포를 수행하지 않는 것은 아닙니다.
  
• 요구/분석/설계/구현/테스트/배포가 단계(Phase)는 아니다 - 맨 위에 보시면 Inception, Elaboration, Construnction, Transition이라는 단어가 나옵니다. 우리는 요구단계, 분석단계, 설계단계 이렇게 부르는데 UP에서의 단계는 다르다는 것을 알 수 있습니다. 물론 폭포수 모델로 간다면 요구단계, 분석단계라는 말이 틀린 것은 아닐 겁니다.
  
• 소프트웨어 개발의 시작부터 모든 영역의 활동을 수행한다 - 중복되지만 시간이 지나도 대부분의 활동을 모두 수행합니다. 단, 시간이 지나면서 그 비중이 요구도출 > 분석/설계 > 구현 > 테스트 > 배포로 이동할 뿐입니다.
• 시간 축에서 볼때 Construction 단계가 가장 많은 비중을 차지한다 - 개인적으로 너무 공감하는 부분입니다. 소프트웨어는 개발(실제 코딩)하는 시간이 절대적으로 많아야 합니다. 아무리 요구도출, 분석/설계를 잘 한다고 해도 구현 시점에는 앞서 수행한 것을 변경해야 하는 경우가 생깁니다.
  

위의 그림을 반복과 함께 설명하고 있는 그림을 추가로 넣어 봤습니다.

이 그림은 세번의 반복을 통해 소프트웨어를 개발하는 것을 예시로 들고 있습니다.

• 반복 #1(개발 초반) - 비즈니스 모델링, 요구도출, 분석/설계에 많은 비중을 차지합니다. 지속적으로 언급되지만 여기서 구현, 테스트, 배포도 합니다. 우리가 생각하는 실제 테스트와 배포를 하지 않을 수도 있지만 테스트와 배포에 관련된 활동을 합니다. 예를들어, 테스트케이스 설계 방법을 결정한다거나 요즘 유행하는 CI(Continuous Integration)를 위한 환경을 구축할 수도 있습니다.
  
• 반복 #2(개발 중반) - 분석/설계와 구현 그리고 테스트가 개발에서 많은 비중을 차지합니다. 비즈니스 모델링과 요구도출도 계속 수행하지만 이전 반복보다는 비중이 많이 줄어 들었음을 알 수 있습니다. 아마도 이 시점이 되면 미처 찾지 못한 요구사항을 간간히 발견하는 정도가 되지 않을까 생각합니다.
  
• 반복 #3(개발 마무리) - 이제 대부분의 요구사항이 도출되어 구현되었으면 테스트에 좀더 많은 노력을 기울입니다. 테스트에서 나온 결함을 가지고 분석/설계와 구현을 다시 검토하고 소프트웨어를 변경합니다. 그리고 실 사용자가 사용해 볼 수 있도록 개발계와 운영계에 배포가 활발히 진행됩니다.
  

폭포수와 반복 개발에 대해 질문을 하실 수 있을 것 같아서 추가로 설명해 보겠습니다.

• 제가 몸담고 있는 회사도 대부분 폭포수 모델처럼 일을 합니다. 즉, 일정도 폭포수, 진척률도 폭포수, 테스트도 시스템 배포 전에 몰아서 합니다. 즉, 처음에 요구도출을 합니다. 그리고 화면설계서를 작성하고 개발자들과 모여서 리뷰를 합니다. 그리고 디자이너가 화면을, 퍼블리셔가 HTML/CSS를 그리고 마지막으로 개발자가 여기에 로직을 붙입니다. 마지막으로 테스트를 하고 운영 서버에 배포합니다.
  
• 네, 일은 폭포수처럼 합니다. 그런데 가만히 보면 화면설계 리뷰를 할 때 개발자들이 많은 질문을 던집니다. 그러면 앞선 작업을 하신 담당자 분들이 다시 고민을 하고 고객과 얘기해서 화면설계를 변경합니다. 그리고 테스트 후에 발견된 결함들을 개발자에게 넘겨서 수정하도록 합니다. 여기서 제가 말씀드리고 싶은 것은 행정적(?)으로는 폭포수이지만 실제 수행하는 것은 반복적 요소가 절대적으로 더 많다는 것입니다. 즉, 우리는 폭포수라는 계획 아래에서 반복적 개발을 하고 있다고 보입니다.

두번째 그림은 시간이 지나면서 우리가 어떤 영역에 리소스를 투입하고 있는지를 보여줍니다. 앞서 언급했지만 우리의 리소스(저희 회사의 경우는 대부분이 HR)는 실제 코드작성을 제일 많이하는 Contrunction에 집중해야 한다는 것을 알 수 있습니다.

이상으로 제가 앞으로 설명할 UP에 대해서 간략하게 설명해 봤습니다. 그것도 제 방식으로 설명해 봤습니다. 지금까지 설명한 것이 실제 개발과는 직접적으로 연관이 없고 관리와 연관되어 보일 수도 있습니다. 하지만 큰 맥락에서 보면 소프트웨어 개발 과정에 대한 현실과 진실은 이해할 필요가 있다고 생각합니다.

물론, "현실에서는 불가능해!"라고 하시는 분도 계실거고 진짜로 "불가능 한 경우"가 있을 수 있습니다. 소프트웨어를 제대로(?) 개발해야 한다면 우리가 수행하는 방식을 바꿀 필요가 있고 어느 순간 짠~하고 해결하는 것이 아니라 체계적이고 논리적으로 사고하는 노력이 필요하다고 생각합니다. 저는 그렇게 생각합니다. 최종 판단은 이 글을 읽으신 분들께 넘기도록 하겠습니다.

설명에 도움이된 참고자료는 다음과 같습니다.

• Unified Software Development Process, 1999, Addison-Wesley Professional, Ivar Jacobson, Grady Booch, James Rumbaugh
• The Rational Unified Process An Introduction, 2003, 인터비전, 신인철 역
  
• Rational Unified Process, IBM