프로젝트의 단계 - 분석단계

전통적으로 가장 선호되는 개발 관리 방법론은 폭포수(waterfall) 방법론이다.

 

폭포에서 떨어진 물이 폭포 위로 거슬러 올라갈 수 없는것처럼 이론적으로는 각 단계의 선이 명확하게 그어진다.

프로젝트는 기본적으로 분석, 설계, 구현, 테스트, 운영의 단계를 거치며 완성된다.

 

1. 분석단계

 

'요구사항의 도출 및 기술'을 하는 단계이다.

 

사실 모든 프로젝트에서 가장 중요한 단계라고 할 수 있다. 

고객이 도대체 뭘 하고 싶은건지. 뭘 만들고 싶은건지. 어떻게 사용하고 싶은건지... 등등 

다르게 '니즈파악' 이라고도 많이 하지...

 

아무튼 아마도 프로젝트 기간 초반 고객과 설계/기획자가 가장 긴밀하게 소통해야 하는 기간이다.

 

이 단계의 완료를 위해 다음과 같은 산출물을 작성하게 된다.

 

• 개발표준 정의서
• 현행시스템 분석서
• 요구사항 정의서
• 요구사항 추적 매트릭스
• 시스템다이어그램
• 과업대비표
• 용어사전

 

이중 가장 중요한건 머니머니해도 요구사항 정의서이다.

작은 프로젝트는 대부분의 산출물을 생략하기도 한다.

하지만 적어도 실패하지 않으려면 이 요구사항 정의서만큼은 꼭 작성해서 고객과 협의하고 단계를 매조지할 필요가 있다.

반응형

• 개발표준 정의서

SI 프로젝트에서 사용되는 개발언어부터 데이터베이스와 프로젝트에 사용되는 각종 프로그램 등을 사전에 정의한다.

(간단하게 예를 들면, JAVA + MySQL + Spring + UI 개발 플랫폼 등을 정의하는 것이다)

또, TABLE, 컬럼 및 항목명, 프로그램명 등의 명명 규칙도 사전에 정의하여 개발자들이 참조할 수 있도록 한다.

혼자서 설계, 개발, 테스트에 운영까지 할 때는 필요 없을지도 모르지만, 일반적인 프로젝트는 다수의 개발자가 투입되고 투입시기 또한 제각각일 때가 많다. 이렇게 사전에 개발가이드를 작성함으로써 개발자들이 투입 초기에 겪을 혼란과 시간의 로스를 줄일 수 있다.

 

 

• 현행시스템 분석서

완전히 처음 기획서부터 시작하는 프로젝트도 있지만, 이보다는 기존에 운영 중이거나 1차 개발한 시스템을 고도화하는 프로젝트가 훨씬 많다. 

그런데 이전에 구축했던 개발팀이 프로젝트를 이어서 하지 못하고 새로운 팀이 구성되어 프로젝트를 진행할 때가 있다.

(관공서 프로젝트가 대체로 이런 식이다. SI 프로젝트 수행사 입장에선 장기 프로젝트를 계획할 수가 없으니 별로 환영할 만한 일은 아니지만...)

이럴 때 새로 투입된 팀은 이전 시스템을 분석하고 이를 바탕으로 새로 구현될 시스템의 개발 방향과 공수 등을 계획할 수 있는 것이다. 특히, 현재 운영 중인 시스템에 대한 개발에서 솔루션의 변경 등의 이슈로 데이터 저장구조가 완전히 달라지는 경우가 있다. 이러면 개발계획과 함께 데이터이관계획을 함께 수립해야한다. 

이를 바탕으로 갭분석서가 작성될것이고, 과업수행서와 요구사항정의서 등도 현행시스템 분석을 바탕으로 이루어지게 된다. 

 

 

SI사업은 새롭게 시작이 되는 경우도 있지만, 연차사업으로 수 년 간 진행을 하기도 한다. 이 때 새로운 사업의 진행을 맡은 업체는 이전 시스템의 구성에 대해 명확하게 파악을 하고, 이에 대한 내용을 모든 구성원들과 공유해야 할 필요가 있다. 이를 위해 현행시스템분석서를 작성하게 되며 이 문서에는 기존 시스템의 시스템 구성부터 데이터베이스 테이블 구성에 이르기까지 전반적인 기존 시스템에 대한 내용을 기재한다. 시스템이 운영되고 있는 경우에는 운영과 관련된 정보 역시 문서에 기재할 필요가 있다.

728x90

 

• 요구사항 정의서

요구사항 정의서는 의뢰자, 즉 고객과 작업자, 즉 개발 수행사간 합의한 업무의 범위와 상세 기능들을 명확하고 완전한 형태로 명시하여 문서화한 것이다.

한 마디로 고객의 니즈를 정확하고 자세하게 기술한 문서..

통상 프로젝트 시작 전 기술협상과 킥오프 미팅 워크샵 등을 거쳐 구현가능한 기능을 추리고 업무 또는 구현의 우선순위 등을 조정하는 과정을 거쳐 확정된다. 

 

향후 구축이 완료되고 검수 과정에서 매우 중요한 문서이다.

 

말로 하면 간단하지만... 이게 생각만큼 간단하지 않은게.... 고객 또한 본인이 뭘 해야하는지, 어떤 기능을 개발해야 하는지 정확히 모른다는데 문제가 출발한다. 사실 정확하게 말하면 고객은 원하는 바는 명확하다. 다만 기획자와 개발자에 표현하는데 어려움을 느끼고 있는 것이다.

기획자들은 그래서 담당자들과의 대화에서 단어 하나, 장표 하나도 놓치지 않고 수집하고 분석하여

요구사항과 과업표를 만드는데 심혈을 기울인다.

이 요구사항 파악이 제대로 안되면... 최악에는 완료단계에 처음부터 다시!를 외치게 될 지도 모를 일이다.

 

그래서 요구사항 정의서에는 고객의 요구사항을 정의한다기 보다는, 기획의도를 정확히 반영해야 한다.

기능은 크게 '사용자'용인지/'관리자'용인지를 구분하고, 

서비스 메뉴명과 구현 또는 필요기능을 명시한다. 

우선순위 등을 지정하기도 하는데, 필수요건과 부가기능 등으로 표기하기도 한다.