변경 관리:
프로젝트는 진행되어가면서 새로운 산출물들이 축적되고, 축적된 산출물들은 계쏙해서 버전 업이 된다. 이렇게 변경되는 산출물들을 관리하는 것이 형상관리다.
시스템은 소프트웨어 개발 생명주기의 모든 단계에서 변경이 일어나고, 시스템을 변경하고자 하는 용구는 개발 생명주기 동안 지속적으로 일어날 것이다.
변경의 요인
1. 업무 환경의 변화
1. 새로운 기능의 추가와 같이 고객의 요구의 변경
2. 시장 여건의 변경
3. 예산과 일정 계획 등에서의 변경
2. 기술 환경의 변화
1. 하드웨어의 사용 및 운영체제의 변경
버전관리:
1. full model change - 1.0 -> 2.0으로 바뀌는 경우
2. minor change - 1.1 -> 1.2, 1.1.1 -> 1.1.2로 바뀌는 경우
형상관리
1. 개발중 발생하는 모든 산출물들이 변경됨으로써 점차 변해다근 소프트웨어 혀어상을 체계적으로 관리하고 유지하는 기법
2. 소프트웨어 개발 생명주기 전반에 걸쳐 생성되는 모든 산출물의 종합 및 변경 과정을 체계적으로 관리하고 유지하는 일련의 개발 관리 활동
3. IEEE-Std-1042
형상관리 절차를 중심으로 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화 하고, 그러한 특성에 대한 변경을 공식적으로 통제하고, 변경 처리 상태를 기록 및 보고하고, 명시된 요구 사항에 부합하는지 확인하는 일련의 사항에 대해 기술적, 행정적인 지침과 관리적인 감독, 감시 활동을 포함한 사후 관리를 적용하는 원칙.
4. 형상 관리 수행 절차
4.1 형상 식별
형상 관리의 가장 밑바탕이 되는 활동
프로젝트 계획 시 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정
-형상 항목 선정
제품 개발 초기 단계에 관리 방법이나 변경에 대한 통제 여부에 따라 산출물을 구분하고, 이중 변경에 대한 통제가 필요한 산출물을 선정
-형상 식별자 규칙 선정
어떤 프로젝트에서 사용되는 파일인지, 어떤 내용의 문서인지, 버전이 어떻게 되는지를 같은 작업을 하는 소속 팀원들 끼리 한눈에 알아볼 수 있도록 이름을 명명하는 규칙
- 베이스라인 기준 선정
베이스라인baseline: 소프트웨어 개발 과정 중 특정 시점에 만들어진 산출물의 집합
4.2 형상 통제
형상 목록의 변경 요구를 겈토 및 승인하여 현재의 소프트웨어 기준선에 반영될 수 있도록 통제하는 일련의 과정
- 변경 요청: 고객/개발자는 변경사항 발생 시 변경 요청서 작성 -> 변경 관리 담당자에세 제출
- 변경 심사: 고객/개발자가 변경요청서 제출 -> 현상통제위원회의 검토 -> 수락/거절 결정
- 변경 확인:
-변경 완료: 개정 이력들과 함께 새로운 버전 번호 부여
-형상통제위원회: 변경된 내역 확인 및 승인 후 체크임
-저장소에 새로이 저장된 변경 항목: 다시 베이스 라인으로 수립
4.3 형상 상태 보고
베이스라인으로 설정된 형상 항목 구조와 변경 상태 기록 -> 관련된 사람들에세 보고
형상 상태 보고 내용: 플젝에서의 변경 횟수, 최근 SW항목의 릴리즈 버전, 릴리스 식별자, 횟수, 베이스라인 상태, 변경 제어 상태, 형상통제위원회 활동내역
4.4 형상감사
형상감사(configuration audit)
-형상 관리 계획서 대로 형상 관리가 진행되고 있는지, 형상 항목의 변경이 요구 사항에 맞도록 제대로 이뤄졌는지 들을 살펴보는 활동
-단계별 베이스라인의 적정성과 무결성을 평가하고 승인
감사내용:
승인된 변경 요청이 제대로 반영되었는지 검증, 승인되지 않은 내용이 혹시 반영되었는지 검증, 승인된 변경과 관련된 항목들이 갱신되었는지 검증.
유지보수의 분류
1. 수정 유지보수
-개발된 소프트웨어를 사용자가 인도받은 후 사용하면서 발견되는 요류를 잡는 것
-개발 과정에서 미처 바로잡비 못한 오류를 유지보수 단계에서 해결하는 것
2. 적응 유지보수
-개발된 소프트웨어가 처음 설치된 곳에서 문제없이 실행되다가 환경이 바뀌어도 이에 맞도록 수정, 보완하는 것
3. 기능 보강 유지보수
- 변경이 필요할 떄 하게 되는 유지보수
4. 예방 유지보수
-미리 예상되거나 예측되는 오류를 찾아 수정하는 것
