서으이 2020. 12. 2. 11:06
728x90
반응형

 

SI 사업을 준비하는 단계부터 진행하고 마무리하는 과정에서 나오는 문서나 자료를 의미합니다.

사업과 시스템 구축에 관련된 모든 내용을 항목별로 일목요연하게 정리함으로써, 현 시스템에 대한 이해를 돕는 것은 물론, 향후 시스템을 수정할 때나 다른 수행부서/업체가 사업을 맡게 될 때 참고할 수 있는 자료를 만들어내고자 하는 것이 목적입니다.

보통 사업 초반에 사업을 발주한 기관과 사업을 수행하는 업체가 협의하여 그 목록과 범위를 정하게 됩니다.

 

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. 테이블 정의서

테이블 필드와 설명, 바이트수 등을 표기합니다.

 

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. 기타


DB구축 산출물

준비단계 산출물

DB구축을 준비하는 단계에서 나오는 산출물

  • DB구축 계획서구축 대상과 일정에 관한 내용을 담은 계획서
  • 현행 DB구축 목록현재 DB에 등록된 데이터
  • DB구축 일정표구축 일정에 대한 계획표
  • DB 품질활동계획표 대한 계획표

구축 단계 산출물

DB를 구축하는 단계에서 나오는 산출물

  • 원시데이터목록 - DB로 구축하기 위한 원 데이터 목록
  • 원시자료 확보 방안원시자료를 확보하기 위한 방안을 기재한 문서
  • DB구축 데이터 목록로 구축한 데이터 목록
  • 워크시트 - DB를 구축하는 과정에서 정리한 작업문서
  • DB 품질활동결과보고서의 구축 과정에서 잘 구축이 되었는지 확인한 결과 문서

검수 단계 산출물

구축된 DB를 검수하는 단계에서 나오는 산출물

  • DB구축검수활동보고서 - DB에 최종적으로 구축된 데이터에 대한 검수 보고서
  • 검수확인서 - 최종 검수 결과서

 

728x90
반응형