DA: 프로젝트 진행과 진행에 따른 적절한 산출물 관리

Kosta -

2012년 '소프트웨어 구축을 위한 산출물 작성 및 표준 가이드 2' 라는 강의를 듣고

정리함

1. 소프트웨어 개발 단계

분석단계 - 설계 단계 - 구현단계 - 제품 인도단계
※ 이중 구현단계부터 수업에 포함되어 있음

2. 각 단계별 적절한 산출물들

2-1) 분석 단계

(1)요구사항 정의서(범위 확인, 관리에 꼭 필요한 사항임)

<1>요구사항 정의서가 기초가됨
요구사항 분석서, 또는 설명서, 기술서, Usecase 명세서로 작성

(2)시스템 분석서(H/W, S/W(구성하는 시스템까지 포함), APP, DATA)

-> 재구축 프로젝트를 진행시 꼭 필요한 문서

(3)요구사항 추적표 or Matrix

(요구사항이 누락없이 반영되어 있는지 확인하는 문서)

2-2) 설계 단계

(1) DB 표준가이드

(Object 정의서, table 정의서)(밑에 6-1번 항목으로 세분화함)
<1>DB Modeling Guide, DB 설계표준, 용어사전, 도메인 정의서 로 발전
<2> 데이터 전환(기존 DB를 재사용시 작성)설계서 또는 기술서
or 초기 Data 계획서

(2) APP 표준가이드(사용자 화면 설계서, 인터페이스, Srory Board)

<1> 웹 스타일 가이드(WSG), 개발표준, 보고서 표준, 화면 표준

(3) 인터페이스 표준

(APP과 System 과의 정보 송수신 등 연계 내용을 작성하는 문서)

(4) 추가 (DB+APP)관계 표현 - CRUD Matrix

(이는 분석, 설계 단계 중에 1회 정도 작성함)

2-3) 구현 단계(Test 단계?)

(1) 개요(V&V모델(Verification 을 위한 Validation(확인)활동))

(2) Verification(전 단계에서 다음단계로 진행시 확인하는 방법)

: Peer Review Inspection
(각 단계말에 진행, 실 프로젝트에서는 전담)

(3) 통합 테스트 방식 : 상향식, 하향식, 빅뱅, 샌드위치 보통4가지 사용

(단순 인지 지식)

(4) 모든 테스트 진행 순서 : 계획 -> 실행 -> 구현 -> 실행 -> 계획단계로.

★각 테스트 결과는 위에 있는 단계가 진행될때 산출되어야 한다.★

(5) 종류

<1> 총괄 Test
(모든 test 내용을 한 파일에 죄다 넣을수도 있고
간단하게 작성할수도 있고 하위 내용으로 대체하기도 한다.)
<2> Test 계획서(Test조직 구성, 환경구성, 조치 절차 등을 기술)
<3> Test 설계서(TestCase 시나리오 작성을 위한 계획 문서)
테스트 기법or 방법론 정하기
(Black Box, White Box, 경험기반, 오류기반, 등등)
커버리지 정도, 테스트 경로 등을 지정
<4> Test Case (단위 테스트용)
<5> Test Case 시나리오(통합 test 이상급부터 적용)
<6> Test 결과서 (전체 test 계획, 실행과 결과, 후속 조치 내용들의 결과)
<7> Log(단순 로그)
<8> Tracking(결함 추적서) : 테스트 fail은 어떤 내용인지, 또
해당 fail에 따른 조치 내역들이 종합 정리된 내용

⊙ 개발 방법론 정하기

2000년도 이후 재사용성, 생산성, 품질을 높이는 방법을 중심으로 여러 개발

방법론이 발전함
(구조적 방법론, 정보공학, 객체지향, CBD, 애자일, 스크럼, ......)
이중 한국에서는 관리기법1, 마르미1~4(3은 CBD, 4는 임베디드 시스템 전용)
등을 문서화함

2012년에는 정보화지원산업통합 방법론 이라는 방법으로 (예제 문서포함)

개발하도록 제시함(CBD SW 개발 방법론)

2-4) 제품 인도 단계

(1) 사용자 교육훈련(계획, 결과)

(2) 메뉴얼 작성

<1> 사용자(user)지침서
<2> 관리자 (application) : user 관리 방법, 에러 발생시 유형 파악 및 조치 방법
<3> 운영자(System 운영 측면 관리자WEB, WAS, DB)

(3) 전개(이행)계획서, 결과서

(솔루션을 기존 솔루션을 대체하거나 새로 시작하는 단계에서 작성)
포함 내용 : 신규 서비스 도입/전환, 연계 서비스 협조
전개 추진 계획, 일정, 협조, (리허설 포함)

2-5) 기타 단계별 포함되지 않은 내용중 필요한 보고서 종류들

(1) 대안 분석서, 정보기술 검토 보고서, 소프트웨어 아키텍처 정의서?

분석 단계에서 문제 해결위해 기존 사용한 해결 방안 제시 할때
많이 사용됨, 수시 사용 가능

(2) GAP 분석 정의서, 처리서

요구사항에 대한 수용에 대하여 기존 솔루션의 적합성을 확인
(솔루션 도입시 많이 사용)

(3) 시스템 설치 계획서, 결과서

시스템 구입시(참고 : CBD 소프트웨어 표준산출물)

(4) 장비 설치 계획서, 확인서, 납품 내역서

필요한 장비 설치시

(5) 교육훈련 계획서, 그리고 결과서

3. 표준 작업

표준은 프로젝트 시작(S_day 1일차부터 전담자 배정)
표준 작업 정리된후 해당 업무를 담당했던 인원은 개발환경 구축, 공통 구현 모듈

구현 시작 기타 개발 진행전 교육-> 개발 시작후 서포트 및 테스트 환경 구축

혹은 기타 구현 부분 진행 -> 개발시 놀지 않도록 업무 배정 가능, 안정된 품질 확보 가능

3-1) DB표준

(1) 용어표준 :

용어사전(for databse Modeling)
(영문풀네임, 축약영문, 한글명, 등록자, 등록일)
=> 용어사전 내용으로 Colmum작성 하면 가독성 높아짐,
DB모델러가 관리 및 통제
도메인 정의서
(영문명(여부), 한글명(여부), 값의 범위, 값의 길이, type)
(모델링 단계에서 수정시 자동화도구가 있음)

(2) 모델링 (ERD) :

정규화, Entity(Entity group), Relationship, tool 사용법, table관계, 정규화
Entity Table
Attribute Column
Record Row or Tuple
논리모델 물리모델

<1> 우선 논리 모델(DBMS 고려 안함) 이 만들어지고
(분석 단계에서 작성) -entity 상계 설계+코드 설계가 포함
<2> 이후 물리모델(특정 DB모델이 적용됨)이 만들어진다.
(설계 단계에서 작성)
-테이블 물리 및 분산 설계, 성능 고려 설계, 오브젝트 설계가 포함
CRUD Matrix도 포함
<3> 물리모델이 작성되는 과정중 정규화 를 진행
1차 : 반복속성 제거
2차 부분함수 종속성 제거
(key 2가지일때 a,b key중 한가지만 가지고도 100% 구별되는
비식별자가 있을때 부분함수 종속성 이라고 함 -> table 따로 떼줘야 함)
3차 이행함수 종속성 제거
(비식별자가 종속성 A값에 의해 B값 결정에 영향주면 해당)
반정규화 : 중복 허용
(성능, App단순화 또는 안정성 목적으로 실시)(가장 최소화 해야함)

(3) 설계 표준(object설계) :

용어 및 정의서(Table, colum, View, SP,SF, User)(물리적인 부분)
<1> 분류규칙 및 명명규칙(거의 고정되어 쓰던걸 쓰는편임)
<1> 설계 가이드(table)
PK, UK, 등 지정 가이드, 인덱스 지정 가이드 등

(4) SQL 작성가이드 :

Query(작성순서, 성능 향상을 고려한 내용 가이드, 설계 단계)
DBMS 종류, 버전에 따라 발전시켜야 됨

(5) 산출물 작성 가이드(DB설계에 의한 산출물 리스트)

데이터 베이스 설계 표준 모델링, 명명규칙, SQL작성 기준, 가이드
데이터 베이스 설계서 - 설계 표준을 기초로 작성 테이블,
인텍스 뷰 구현위한 설계
코드 정의서 - 공통 사용코드 구조, 내용
스키마, 테이블 정의서 - 테이블 구조 정의, 설계
인덱스 정의서 - 쿼리 속도 향상 위한 인덱스 정의, 설계
오브젝트 정의서 - 뷰, 사용자, 프로시져, 함수, 패키지, 시퀀스, 트리거
등을 정의, 설계
테이블 용량산정 - 각 적정 파라미터 테이블, db 크기 설정

☆구현 에 의한 표준 구분

☆기능에 의한 표준 구분 (ex)
화면표준

- UI/UX표준
개발표준

- jsp / java script / java / xml
- package / folder
- exception / error(AOP(aspect oriented programing)로 가능)
- Message(AOP로 가능)
- log
- page navigation(AOP로 가능)
- 솔루션 가이드(SNS, FAX, 보안인증 처리, 권한 처리)
- 배치가이드
- 보안가이드
- 개발환경 구성가이드
- code inspection 가이드

3-2) 소프트웨어 개발 표준

(1) 프레임워크 구성요소 표준화(가장 중요)

(2) 웹스타일 가이드 표준 (화면, 보고서도 포함가능)

(3) 개발표준(분류규칙, 명명규칙, 코딩규칙) : 각 언어별로 작성되야함

(4) 공통 컴퍼넌트 및 기능(공통 요소 기술)

(구현하여 쓸수 있도록 공급해야함 포함되는 사항은)
<1> 문자열, 숫자관련, 날짜 관련, 파일, 디렉토리 관련, 암,복호화 관련 함수들 정의 필요
<2> 윈도우(팝업), 웹에디터, 코드명 조회 등
<3> 컴포넌트 : 파일 업, 다운로드, 엑셀 업, 다운로드, 채번처리, Ajax처리, ListBox 처리

, 달력 등을 구현하여 유지하고 필요시 통일하여 쓸수 있도록 해야함
<4> 주요 처리 기능 : 중복전송방지, 예외 오류, 메시지, 트랜젝션, 로그, 세션, 페이징

, 권한 처리
<5> 연계 솔루션 : ipin, sms발송, 자동, 대량 메일, Fax발송,
<6> 웹출력(보안 포함), 인증처리 부분
<7> DRM, EDMS, EAI 등 연계 솔루션 인터페이스
<8> 다른 요소 기술과 결합 방식

(5) 개발환경 구성 및 가이드

<1> 개발할수 있는 환경 설치 가이드 <- 개발자가 참고
ex) 클라이언트(JDK, Eclips, WebLogic),
개발서버(CVS, SVN,(Web, Was,DB)),
테스트 서버(CVS, SVN,(Web, Was,DB)), 운영서버1,2,3 ......
로 구분하여 진행
--> 그러면 개발자는 개발후 테스트 서버에서 테스트 하고 되겠다 싶으면
형상관리 서버에 등록 후
TEST 조직이 있는 상용전 테스트 서버에서 운영해보고
일정 시간을 정해서 업데이트를 시행(각 운영서버에 상용화 시작)
테스트 서버는 운영 서버의 자료를 일정 시간별로 업데이트 시킨후
환경 구성을 일치시킨다.
<2> 서버, 테스트 서버, 형상관리 툴 및 방법, IDE, WAS,
Web Reporting Tool, 등 가이드 등을 개발자에게 제공
<3> 프레임워크 가이드(프레임워크 관리자가 확인할 사항)

3-3) 연계 표준 : 시큐어 코딩 가이드

(계발단계에서 교육 되도록 사전 준비)

(1) 연계 유형 : 연계 방식과 아키텍처를 정하기 위한 기준

연계 유형(단방향?, 양방향?), 연계 범위(내부시스템?, 외부와 연계?)
송수신 정보범위
(개인정보포함?, 변경된 데이터가 오고가는?, 단순정보 보여주기?)
연계 방식(솔루션은?, 보안 수준은?), 연계 빠르기
(실시간?, 근실시간?, 배치만?)
연계 시스템 아키텍처, 테이블 구조는?, 연계모듈 기능
(데이터 검색, 자료형식 변환, 암복호화, 로그기록, 모니터링 기능

, 데이터 수신, 데이터 전송)

(3) 연계 문서 표준 : 정해진 연계 유형을 가지고 구체화하여 표준을 정함

명명규칙, 분류규칙, 인터페이스 목록, 인터페이스 문서 구조 및 코드 정의
연계 코드(다른 DB에 대한 연계는?
송수신 모니터링 확인절차(모니터링 요원이 업무하는 절차)
(모니터링의 정합성 확인 정의, 오류 유형 구분, 오류별로 조치방법 정의)
연계 처리 절차 (송수신 내용의 추가, 변경 발생시 등록 및 적용절차)

(3) APP 개발간 꼭 필요한문서를 정의

<1> 프레임워크 설계서, 구성요소(개발표준 정의서의 기초가됨)
<2> 개발표준 정의서(프레임워크 관리자가 참조, 밑의 3가지의 기초가됨)
<3> 개발가이드, 솔루션 가이드(3가지는 개발자가 참고할만한 문서)
<4> 개발환경구성 가이드
<5> 웹 스타일 가이드, 화면표준(보고서 표준 포함)

4. 기타 확인 사항들

시스템 아키텍쳐 :

각종 DB서버 및 서버 구성과 각 서버간 관계, 여기에 구성 OS 포함
소프트웨어 아키텍처 : 소프트웨어 구성요소와 구성요소와 관계를 설계한 문서
==> 사용자가 입력한 내용이 어느 클래스에서 처리되고 있는지에 대한
구조도 혹은 설계도(class 구조)
SoftWare Archtecture Style : 소프트웨어 아키텍쳐 중에서
특성 표준 속성(재사용성 강화, 속도 개선)을 만족하는
소프트웨어 아키텍처

아직 구현하지 않은 소프트웨어 아키텍쳐는 아키텍쳐

프레임워크 : 소프트웨어 아키텍처를 가져다 구현할수 있도록
준비한 틀 프레임워크는 소프트웨어 아키텍쳐를
포함하는 개념

(어느정도 구현해놔서 해당 아키텍쳐를 준수하면서 개발할수 있는 상태)
플랫폼 : .new , J2EE , 시스템 아키텍쳐,
소프트웨어 아키텍쳐를 쓸수있도록
구현해둔 일종의 인프라 시스템
플랫폼위에 프레임워크가 돌아가는 것으로 보인다.

4-2) 방법론(애자일 중심으로만 설명함)

애자일 방법론 : 중간 산출물, 고객의 변화에 유연한 대응
RFP 방법론 : 고객 변화 통제가 목적
정의서 : 분석 단계에서 작성
설계서 : 설계 단계에서 작성

2015년 4월 1일 수요일

프로젝트 진행과 진행에 따른 적절한 산출물 관리