이번에는 프로젝트 단계별 액티비티와 산출물에 대해서 간단히 정리해 보겠습니다.
프로젝트를 진행하기로 계약이 되었다고 가정하고 일반석인 분석/설계/개발/구현 단계를 보겠습니다.
1. 분석
1.1. 요구사항정의서
: 해당 프로젝트를 수행하는 가장 기본이 되며 고객의 needs을 담고 있는 문서입니다.
이를 통해 다양한 스펙산정이 가능합니다. 이 부분에서 요구ID를 도출합니다.
1.2. 기능챠트
: 현업요구사항을 근간으로 큰 카테고리를 만들어 한눈에 해당 프로젝트가 무슨 일을 하는 것인지 보여줄 있습니다.
* 개발방법론에 따라 유스케이스다이어그램으로 대치할 수도 있을 것으로 판단되어지고, 기능챠트와 같이 가도 무관하다는 판단입니다.
1.3. 프로세스 정의서
: 기능챠트를 기준으로 각각의 프로세스를 보여줍니다. 때에 따라 확대된 프로세스의 표현도 가능합니다.
* 개발방법론에 따라 시퀀스다이어그램을 넣어도 무방하다는 판단입니다.
1.4. 인터페이스정의서
: 상기 현업요구사항정의서,기능챠트,프로세스정의서를 근간으로 하여 레가시 및 대외계 시스템, 웹서비스 등
어떤 식으로 인터페이스를 해야 한다는 정의를 담고 있습니다.
[출처] 특허청 SW개발방법론 업무 흐름도
2. 설계
2.1. UI(화면)설계서
: 웹App 혹은 CS App 든 간에 고객이 사용하고자 하는 화면단을 보여주는 문서입니다.
2.2. ERD
: 해당 업무의 DB를 생성하고 테이블간의 상관 관계를 표현하는 문서로 더 이상 설명이 필요 없으리라 믿습니다.
2.3. 테이블목록
: 테이블정의서도 있지만, 테이블목록은 관리자가 한눈에 시스템을 구성하고 있는 DB
테이블을 보여준다는 측면에서 필수라는 판단입니다.
2.4. 테이블정의서
: 테이블필드 value와 설명, 바이트 수 등을 표기합니다.
2.5. 프로그램 목록
: 실직적으로 설계단계에 프로그램목록이 나오지 않지만 일단 설계 단계에 넣는 것이 타당한 것 같습니다.
* 개발방법론에 따라 클래스다이어그램, 컨포넌트명세서, 클래스정의서 등도 포함 될 수 있을 것 같습니다.
2.6. 개발표준 정의서
: 변수명, brace, 클래스네임,파일명,규칙 등 코딩관련 규칙을 정의함으로써 일선 담당자가
소스코드를 확인해도 눈에 익숙할 수 있게 하기 위한 문서입니다.
2.7. 단위테스트 시나리오
: 분석,설계의 기본적인 요건이 충적되면 이쯤하여 단위테스트시나리오가 나와야 할 것 같습니다. 아마도 고객의 싸인이 필요한 부분일 것입니다.
2.8. 통합테스트 시나리오
: 설계단에서 하기는 많은 어려움이 있지만, 단위테스트를 근간으로 고객의 요청을 좀더 보완하여 통합테스트시나리오를 작성합니다. 고객의 싸인은 필수입니다.
[출처] 특허청 SW개발방법론 업무 흐름도
3. 개발
3.1. 소스코드
: 말 그대로 오류수정까지 끝난 원시코드 자체를 말합니다.
3.2. 단위테스트 결과서
: 단위테스트시나리오를 기준으로 테스트한 결과를 보여줍니다. 아마도 많은 문제점을 안고 있고, 이 과정을 통해 고객의 요구사항도 많은 변동이 있는 시점입니다.
* 변경요청서도 필요할 시점입니다.
3.3. 결함/오류보고서
: 단위테스트를 통해 알게 된 에러의 원인과 수정에 대한 내용을 나타냅니다. 이를 통해 오류코드정의서를 뽑아내고 보완합니다.
3.4. 오류코드 정의서
: 해당시스템에서 발생할 수 있는 오류들을 코드화하여 보여줍니다.
3.5. 통합테스트 결과서
: 단위테스트를 통해 보완된 내용들을 포함하고, 통합테스트시나리오의 보완을 통해 실시된 통합테스트 결과를 보여줍니다. 개발을 완료했냐 안했냐의 잣대가 되는 문서로서 고객의 싸인이 가장 필요한 부분입니다. 이부분에서 반려가 일어나면 위의과정을 반복해야합니다.
3.6. 시스템 이행계획서
: 통합테스트가 끝나면 Standby하고 있는 시스템에 소프트웨어,하드웨어 기타 등을 몇월, 며칠, 몇 시에 누구누구가 무엇을 가지고 옵져버는 누구이며 어떻게 이행을 할 것인지 등을 표현합니다.
[출처] 특허청 SW개발방법론 업무 흐름도
4. 구현
4.1. 시스템 이행결과서
: 시스템 이행계획서를 통해 이행된 결과를 확인 받는 문서입니다.
4.2. 사용자매뉴얼
: 사용자화면이 있을 경우 나오는 매뉴얼입니다.일반적인 조작법을 기록하며, 화면 등을 예시합니다.
4.3. 운영자매뉴얼
: 시스템전반에 관한 모든 내용을 담고 있습니다. 분석,설계,개발 절차에서 나오는 문서를 담고 있습니다.
4.4. 교육(인수)명세서
: 사용자매뉴얼 및 운영자매뉴얼을 중심으로 해당 담당자 및 사용자에게 시스템전반 및 세부사항을 교육/인수한 후 싸인 받는 문서입니다.
4.5. 개발산출물별 검사리스트
: 예시된 산출물들이 이상 없이 인수되었는지를 개별로 체크한 후 고객의 싸인을 받는 문서입니다.
4.6. 프로젝트 완료보고서
: 최종적으로 개발한 내용, 인도물, 하드웨어, 고객대표, 개발자대표싸인을 받음으로써 명실상부한 프로젝트 완료보고서입니다.
[출처] 특허청 SW개발방법론 업무 흐름도
1. 분석단계
분석단계에서는 주로 기존 시스템 분석하면서 자료 모으고 현업들과 인터뷰나 회의하면서 무엇을 만들지 요구를 들어주는 단계입니다. 인터뷰와 회의나 워크샵을 통해서 요건을 듣고 요구사항을 정의하고 나면프로세스(업무흐름)와 데이터를 모델링합니다. 때에 따라서는 전체화면에 대한 프로토타입이나 HTML MockUp을 만들기도 합니다.
[그림: 분석단계 (출처: SI 프로젝트 전문가로 가는 길)]
2. 설계단계
설계단계에서는 분석에서 모델링한 결과물을 기초로 하여 개발에 필요한 것들을 설계합니다. 주로 데이터베이스와 화면을 설계하고 공통모듈과 단위 프로그램 기능을 정의합니다. 이때 테스트 계획을 수립하거나 시나리오를 작성하기도 하지만 보통은 개발이 완료되는 시점에서 만드는 경우도 있습니다.
[그림: 설계단계 (출처: SI 프로젝트 전문가로 가는 길)]
3. 개발단계
개발단계에서는 개발환경을 설정하고 보통은 공통모듈을 먼저 개발하거나 이미 구현된 공통기능을 사용합니다. 그리고 나서 설계한 단위 프로그램과 화면을 표준과 가이드에 따라 코딩하고 디버깅하며 계획된 일정에 따라 작업을 합니다. 작업이 완료되면 테스트를 실시하는데 먼저 화면 하나 하나의 기능이 잘 되는지 단위테스트를 실시합니다. 그리고 화면간의 연계나 전반적인 프로세스가 잘 진행되는지 프로그램과 화면을 결합하여 통합테스트를 실시합니다. 프로젝트에 따라서 품질이나 성능테스트를 하는 경우도 있지만 보통은 단위/통합을 하고서 품질서버나 운영서버에 이관을 합니다.
[그림: 개발단계 (출처: SI 프로젝트 전문가로 가는 길)]
4. 구현단계
구현/이관 단계에서는 실제로 운영을 가정하는 서버나 실제 운영서버에 릴리즈(배포)를 하고서 그동안 만든 화면과 프로그램에 대해서 앞으로 사용하게될 현장 사람들에게 교육을 합니다. 이때 작성한 화면에 대한 메뉴얼을 작성하기도 하고 실제 교육을 담당하는 경우도 있는데 보통은 메뉴얼 작성을 도와주고 교육은 PI가 작성해준 매뉴얼을 바탕으로 현업들에게 교육을 합니다.
[그림: 구현단계 (출처: SI 프로젝트 전문가로 가는 길)]
그리고 아래는 단계별 액티비티와 태스크에 따른 산출물 입니다.
다른 곳에 게재할 경우에는 반드시 원저작자의 출처를 밝혀 주세요. *^^*