개발 프로젝트 산출물 정리

[출처] http://egloos.zum.com/kaludin/v/2860718

개발 프로젝트 산출물 정리

프로젝트 산출물 관련..

양식파일도 추가.

 

 

프로젝트 산출물 양식 다운로드 : project_deliverables.zip

 

 

 

출처 : http://pooh4880.blog.me/100130534653

 

 

 

1. 분석
   1.1. 현업요구사항정의서
        : 해당 프로젝트를 수행하는 가장 기본이 되며 고객의 needs을 담고 있는 문서입니다.

          이를 통해 다양한 스펙산정이 가능합니다. 이부분에서 요구ID를 도출합니다.

   1.2. 기능챠트
        : 현업요구사항을 근간으로 큰 카테고리를 만들어 한눈에 해당 프로젝트가 무슨 일을 하는

          것인지 보여줄 있습니다.
          * 이부분은 개발방법론에 따라 유스케이스다이어그램으로 대치할 수도 있을 것으로

            판단되어지고, 기능챠트와 같이 가도 무관하다는 판단입니다.
   1.3. 프로세스 정의서
        : 기능챠트를 기준으로 각각의 프로세스를 보여줍니다. 때에 따라 확대된 프로세스의

         표현도 가능합니다.
         * 개발방법론에 따라 시퀀스다이어그램을 넣어도 무방하다는 판단입니다.
   1.4. 인터페이스정의서
        : 상기 현업요구사항정의서,기능챠트,프로세스정의서를 근간으로하여 레가시 및 대외계

          시스템, 웹서비스 등 어떤식으로 인터페이스를 해야 한다는 정의를 담고 있습니다. 
   1.5. 기타

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. 통합테스트 시나리오
        : 설계단에서 하기는 많은 어려움이 있지만, 단위테스트를 근간으로 고객의 요청을 좀더

          보완하여 통합테스트시나리오를 작성합니다. 고객의 싸인은 필수입니다.
   2.9. 기타
 
3. 개발
   3.1. 소스코드(개발원시코드)
        : 말그대로 오류수정까지 끝난 원시코드 자체를 말합니다.
   3.2. 단위테스트 결과서
        : 단위테스트시나리오를 기준으로 테스트한 결과를 보여줍니다. 아마도 많은 문제점을

          안고 있고, 이 과정을 통해 고객의 요구사항도 많은 변동이 있는 시점입니다.
          * 변경요청서도 필요할 시점입니다.
   3.3. 결함/오류보고서
        : 단위테스트를 통해 알게된 에러의 원인과 수정에 대한 내용을 나타냅니다.

          이를 통해 오류코드정의서를 뽑아내고 보완합니다.
   3.4. 오류코드 정의서
        : 해당시스템에서 발생할 수 있는 오류들을 코드화하여 보여줍니다.
   3.5. 통합테스트 결과서
        : 단위테스트를 통해 보완된 내용들을 포함하고, 통합테스트시나리오의 보완을 통해

          실시된 통합테스트 결과를 보여줍니다. 개발을 완료했냐 안했냐의 잣대가 되는 문서로서

          고객의 싸인이 가장 필요한 부분입니다. 이부분에서 반려가 일어나면 위의과정을 반복해야

          합니다.
   3.6. 시스템 이행계획서
        : 통합테스트가 끝나면 Standby하고 있는 시스템에 소프트웨어,하드웨어 기타 등을 몇월,

          며칠, 몇시에 누구누구가 무엇을 가지고 옵져버는 누구이며 어떻게 이행을 할 것인지

          등을 표현합니다.
   3.7. 기타
 
4. 구현
   4.1. 시스템 이행결과서
        : 시스템 이행계획서를 통해 이행된 결과를 확인받는 문서입니다.
   4.2. 사용자매뉴얼
        : 사용자화면이 있을 경우 나오는 매뉴얼입니다.일반적인 조작법을 기록하며, 화면 등을

          예시합니다.
   4.3. 운영자매뉴얼
        : 시스템전반에 관한 모든 내용을 담고 있습니다. 분석,설계,개발 절차에서 나오는 문서를

          담고 있습니다.
   4.4. 교육(인수)명세서
        : 사용자매뉴얼 및 운영자매뉴얼을 중심으로 해당 담당자 및 사용자에게 시스템전반 및

          세부사항을 교육/인수한후 싸인받는 문서입니다.
   4.5. 개발산출물별 검사리스트
        : 예시된 산출물들이 이상없이 인수되었는지를 개별로 체크한후 고객의 싸인을 받는

          문서입니다.
   4.6. 프로젝트 완료보고서
        : 최종적으로 개발한 내용, 인도물, 하드웨어, 고객대표, 개발자대표싸인을 받음으로써

          명실상부한 프로젝트 완료보고서입니다.
   4.7. 기타