Introduction
시스템은 특정 기능 또는 기능 집합을 완수하기 위해 조직된 컴포넌트의 모음으로 정의됨(IEEE 610.12-90). 시스템의 형상 은 H/W, 펌웨어, S/W 또는 이들 간 조합을 기술 문서화하고 제품으로 드러나게 하는 기능적 그리고/또는 물리적 특성임. 또한 시스템의 형상 은 특정 목적을 수행하기 위해, 지정된 빌드 절차에 따라 조합된 H/W, 펌웨어, S/W의 특정 버전 모음으로 생각할 수도. 이제, 형상 관리(CM)란, 특정 시점의 시스템 형상 식별을 위한 규칙(discipline)으로, 그 목적은 형상의 변경을 시스템적으로 통제하고 시스템 생명주기 전체에 걸쳐 형상의 완전성(integrity)과 추적성을 유지하는 데 있음. 정형적으로 형상 관리를 정의하자면, "다음과 같은 사항에 대한 기술적, 관리적 지시(direction) 및 감독(surveillance) : 형상 항목의 기능적/물리적 특성의 식별 및 문서화, 변경 과정 및 상태 구현에 대한 기록 및 보고, 지정된 요구사항에 대한 준수 여부 확인".
S/W 형상 관리(SCM; Software Configuration Management)는 S/W 생명 주기를 지원하여, 프로젝트 관리, 개발 및 유지보수 활동, 보증 활동, 최종 제품의 고객 및 사용자에 이익을 줌. 형상 관리의 개념은 통제 대상의 모든 항목에 적용되지만 H/W CM과 S/W CM 간에 구현 상 상이점이 얼마간 존재.
SCM은 S/W 품질 보증(SQA)와 밀접히 관계하여, S/W 품질 KA에서 정의된 바에 따르면 SQA 공정은 프로젝트 생명주기에서의 제품 및 공정을 보증하는데, 이들 제품 및 공정은 S/W 품질 신뢰성을 부여하기 위한 일련의 활동을 계획, 강제, 수행을 통해 이루어야. SCM 활동은 이러한 SQA 목표의 달성에 도움을 주며 몇몇 프로젝트 컨텍스트에서는 SQA 요구사항에서 특정 SCM 활동을 기술하기도.
SCM 활동으로는 SCM 공정 관리 및 계획, S/W 형상 식별, 통제, 상태 기록, 감사 및 S/W 릴리즈(release) 관리 및 인도(delivery)가 있음. Figuire 1은 이들 활동을 나타내고 있음.
SCM은 타 모든 KA와 연계되는데, 이는 형상 관리의 항목(object)이 SWE 공정 전체에 걸쳐 생산 및 사용되기 때문.
Breakdown of topic
1. S/W 형상 공정 관리(Management of the SCM Process)
SCM은 제품의 진화와 완전성을 다음을 통해서 통제함: 요소 식별, 변화 관리 및 통제, 검증(verify), 기록 및 형상 정보의 보고. S/W 기술자의 입장에서 보자면 SCM은 개발과 변경 구현 활동을 촉진함. 성공적 SCM 구현은 주의 깊은 계획과 관리를 요하는데, 이는 결국 조직 컨텍스트, 제한조건, SCM 공정의 설계 및 구현이 필요함을 뜻함.
1.2. SCM 공정의 제한조건 및 안내(Constraint and Guidance for SCM Process)
SCM 공정에 영향을 미치는 제한조건 및 안내는 다양한 소스로부터 출발함. 기업 또는 조직 수준에 선행하는 정책 및 절차가 해당 프로젝트에 대한 SCM 공정에 영향을 미칠 수 있으며, 획득자와 공급자간 계약 또한 그러함. 예를 들어, 특정 형상 감사가 필요하다거나 특정 항목을 CM 대상으로 지정할 수도. S/W가 공공 안전에 영향을 미칠 경우 외부 규제가 제한사항으로 포함되기도 하며, S/W 생명 주기 역시 그러함.
SCM 공정 설계 및 구현에 대한 안내는 'best practice'를 통해 얻을 수도.
1.3. SCM 계획(Planning for SCM)
SCM 공정 계획은 조직 컨텍스트, 제한조건, 일반적으로 수용되는 안내, 프로젝트의 본성(ex. 크기 및 중요도)과 일관되어야. 주로 다뤄지는 활동으로, S/W 형상 식별, 통제, 상태 기록, 감사 및 S/W 릴리즈 관리 및 인도(delivery)임. 이와 함께 고려될 사항으로, 조직 및 책임, 자원과 일정, 도구 선택과 구현, 벤더와 하청업체 통제, interface 통제가 있음. 계획 활동의 결과는 SCM 계획(SCMP; SQL 검토 및 감사의 주제)에 기록됨.
1.
SCM 조직 및 책임
SCM 활동 및 작업 수행 주체를 명확하게 하기 위해 조직이 명확히 식별되어야. 주어진 SCM 활동 또는 작업에 대한 책임은 조직 엔티티 각각에 할당되어야. SCM에 대한 전체 감사 및 보고 경로(channel) 역시 식별되어야 하는데, 이는 프로젝트 관리 또는 품질 보증 계획 단계에서 이루기도.
2.
SCM 자원 및 일정
스태프와 도구 식별 역시 SCM 계획 활동 중 하나. 본 활동은 SCM 작업 순서(sequence)의 수립 및 프로젝트 관리 계획 단계에서 수립된 일정/마일스톤과의 관계 식별을 부각시킴. 계획 구현 및 새로운 스태프 훈련을 위한 훈련 요구사항 역시 지정됨.
3.
도구 선택 및 구현
SCM 활동을 위한 도구, 절차는 다양함. 상황을 따른다면, 이들 도구 기능(capability)은 다음과 같은 도구의 조합을 통해 만들어짐: 여러 매뉴얼 도구(manual tools), 단일 SCM 기능을 위한 자동화 도구, 일정 범위의 SCM 기능을 통합하는 자동화 도구, 여러 SWE 공정(ex. SCM, 개발, V&V 등)의 요구를 충족시키는 통합 도구 환경(Integrated tool environment). 자동화 도구 지원은 프로젝트 크기가 커지고 복잡해짐에 따라 점점 중요해짐과 동시에 점점 수립이 어려워지는데, 이들 도구가 지원하는 기능은 다음과 같음.
•
SCM 라이브러리
•
S/W 변경 요구(SCR; Software change request) 및 승인 절차
•
코드(및 관계 작업 도구) 및 변경 관리 작업
•
S/W 문서화 관리 및 추적
•
S/W 빌드 수행
•
S/W 릴리즈 및 인도 관리 및 추적
이들 도구는 프로세스 향상을 위한 측정요소 역시 제공하는데, 이에 관계된 측정기준, 즉 프로젝트 관리 지표 및 품질 지표 7가지로는 변경 트래픽(traffic) 및 안정성(stability), 파손(Breakage) 및 모듈화(modularity), 재작업(rework) 및 적응성(adaptability), 그리고 MTBF(mean time between failures)와 성숙도(Maturity)가 있음. Figure 3은 SCM 활동에 대한 도구 기능 및 절차의 매핑 관계를 보여줌.
위 예제에서 코드 관리 시스템은 S/W 라이브러리 운영에 대해 라이브러리 요소에 대한 접근 통제를 통해 지원하고, 여러 사용자의 활동을 조정(coordinate)하고, 운영 절차 강제를 돕고 있음. 또한, S/W 생성 및 릴리즈 해당 라이브러리에 담긴 S/W 요소에 대한 문서화 생성 공정을 지원하는 도구가 있고, SCR 관리 도구는 통제 대상 S/W 항목에 대한 변경 통제 절차를 지원하며, 어떤 도구는 DB 관리, 관리/개발/품질 보증 활동 관리에 대한 보고 기능을 갖추기도 함. 위에서 언급한 것처럼 이들 도구는 SCM 시스템으로 통합되어 결국 타 S/W 활동과 긴밀한 관계를 이룸.
계획에서 S/W 기술자는 해당 프로젝트에 맞는 SCM 도구를 선택하게 되는데, 이에 대한 고려 사항으로 이들 도구의 구현 시 문화 변경(culture change) 등이 요구될 경우 이슈가 발생할 수도. SCM 도구에 관한 자세한 설명은 SWE 도구 및 방법 KA를 잠조.
4.
벤더/하위 계약자 통제(Vendor/Subcontractor control)
SCM 계획에는 컴파일러 등의 외부에서 획득한 도구에 대해서도 어떻게 형상항목으로 다룰지, 변경에 대한 평가, 관리 방법을 고려해야.
하위 계약자에 대해서도 유사한 고려가 필요. 이 경우 SCM 요구사항이 하위 계약자의 SCM 공정에 하위 계약의 일부로 부여되고 준수성 감독(monitoring compliance) 역시 수립되어야. 효과적인 준수성 감독을 위해 어떤 SCM 정보가 가능한지에 대해서도 고려가 필요.
5.
상호작용 통제(interface control)
S/W가 타 S/W 또는 H/W와 상호작용(interface)을 이룰 경우, 이들 중 하나가 변경을 이루더라도 다른 하나에 영향을 미치게 됨. SCM 공정 계획에서는 상호작용을 이루는 항목에 대한 식별 방법과 이들 항목에 대한 변경에 대해 어떻게 관리 및 소통을 이룰지를 고려하여야. SCM의 역할은 상호작용 명세 및 통제 계획, 통제 문서에 대한 더 큰, 시스템 수준 공정의 일부가 될 수 있으며, 이 경우 SCM 계획은 시스템 수준 공정의 배경 내에서 이루어짐.
1.4. S/W 형상 관리 계획(SCMP; Software Configuration Management Plan)
SCM 계획에 대한 결과는 SCMP, 즉 SCM 공정 참조 역할을 이루는 유효 문서(living document)에 기록됨. 본 문서는 S/W 생명 주기 내내 관리되며, SCMP의 작성에는 보통 어떻게 특정 요구사항을 정의하고 일일 활동 기반으로 어떻게 수행할지 등의 하위 세부 절차가 개발됨.
계획 활동에서 만들어진 정보를 기반으로 한 SCMP의 생성/유지보수 안내는 다양한 소스에서 얻을 수 있는데, IEEE828-98은 한 예. 본 참조 문서는 SCMP에 부과되는 제한 사항을 논하며, SCMP에 포함될 6개 카테고리로 이루어진 SCM 정보를 정의, 기술함.
•
소개(Introduction; 목적, 범위, 사용 용어)
•
SCM 관리(조직, 책임, 권한, 적용 정책, 지시(directive), 절차
•
SCM 활동(형상 식별, 통제 등)
•
SCM 자원(도구, 물리적 자원, 인적 자원)
•
SCMP 유지보수
1.5. SCM 감독(Surveillance of SCM)
SCM 절차가 구현되고 나면, 일정 수준의 감독(surveillance)를 통해 해당 SCM이 목표하는 바를 적절히 수행하는지를 확인해야. SQA 요구사항에는 지정된 SCM 프로세스 및 절차의 준수 여부 확인이 있을 수도 있는데, 이는 SCM 권한(authority)과 연계되어, 준수성 감사 활동의 일부인 SQA 권한이 본 감독을 수행할 수도 있음.
프로세스 제어 기능(capability)을 갖춘 통합 SCM 도구는 본 감독을 더욱 쉽게 하는데, 감독 요구사항과 SCM 프로세스 적응 지원에 관한 부분은 도구 선정의 중요 기준임.
1.
SCM 측정기준과 측정(SCM measures and measurement)
SCM 측정기준은 진화하는 제품에 대한 특정 정보 또는 SCM 프로세스의 기능에 대한 통찰의 제공을 목적으로 설계되기도. SCM 프로세스를 감시(monitor)하는 목적 중 하나는 프로세스 향상의 기회를 발견하는 데 있음. 측정은 현 프로세스를 특징지을 수 있으며, SCM 활동 효과성 감시를 위한 수단이 되기도. 측정결과 분석은 프로세스 변화 및 해당 SCMP 갱신을 이끄는 통찰을 제공하기도.
S/W 라이브러리와 다양한 SCM 도구는 SCM 프로세스의 특징을 추출하기 위한 소스 및 프로젝트/관리 정보를 제공함.
감독 시 초점은 측정 자체가 아닌 측정을 통해 얻는 통찰에 있어야. 프로세스와 제품 측정은 SWE 프로세스 KA에서 , S/W 측정 프로그램은 SWE 관리 KA에서 다룸.
2.
프로세스 내 SCM 감사(In-process audits of SCM)
SWE 프로세스 동안 감사는 특정 형상 항목에 대한 현 상태의 파악 또는 SCM 프로세스 구현 평가를 위해 수행되기도. SCM의 프로세스 내(In-process) 감사를 통해 선택한 프로세스를 감시하기 위한 좀더 정형적인(formal) 메커니즘을 제공함과 동시에 SQA 기능(function)과 조합을 이룰 수도.
2. S/W 형상 식별(S/W Configuration Identification)
S/W 형상 식별은 통제할 항목을 식별하고, 이들 항목과 해당 항목의 버전을 위한 스키마를 수립하며, 통제 대상 항목의 수집과 관리에 사용할 도구와 기술을 수립하는 활동임. 본 활동은 타 SCM 활동의 기초가 됨.
2.1. 제어 대상 항목 식별(Identifying Items to be Controlled)
변경 통제의 첫 단계는 통제 대상 항목의 식별임. 본 활동은 시스템 형상의 컨텍스트 내에서 S/W 형상을 이해하고, S.W 형상 항목을 선택하며, S/W 항목 명명(labeling) 전략 수립 및 이들 간 관계, 기준선(baseline) 식별임.
1.
S/W 형상(Software configuration)
S/W 형상은 기술 문서 및 제품 내에 내재할 S/W의 기능적, 물리적 특성임(IEEE 610.12-90). 이는 S/W 형상의 일부로 바라볼 수도
2.
S/W 형상 항목(Software configuration item)
S/W 형상 항목(SCI; Software configuration item)은 형상 관리를 위해 지정된 S/W의 총체이며 SCM 프로세스 내에서 단일 엔티티로 다뤄짐(IEEE610.12-90). 코드 자체를 포함한 다양한 항목이 SCM을 통해 통제되어, 계획, 명세 및 설계 문서, 시험 관련물(matrial), S/W 도구, 소스 및 실행 코드, 코드 라이브러리, 데이터 및 데이터 딕셔너리, 설치/유지보수/운영/사용 문서화가 여기에 포함됨.
SCI의 선택은 프로젝트 통제를 위한 적절한 가시성과 관리 가능한 수준의 통제 항목 개수 간 균형을 이루기 위한 중요한 프로세스임.
3.
S/W 형상 항목 관계(Software configuration item relationships)
선택된 SCI 간의 구조적 관계와 이에 연속된 부분은 타 SCM 활동 또는 작업, 즉 S/W 빌드, 변경 영향 분석 등에 영향을 미치며, 추적성 지원을 위해서도 중요. SCI 스키마 식별 설계 시에는 S/W 구조에 대한 식별 항목의 매핑 뿐 아니라, S/W 항목과 이들간 관계 진화의 지원에 대해서도 고려해야.
4.
S/W 버전(Software version)
S/W 항목은 S/W 프로젝트가 진행됨에 따라 진화함. S/W 항목의 버전은 특별히 식별/지정된 항목으로, 진화한 항목의 상태로 생각할 수도. 리비전(revision)은 항목의 새 버전으로 이전 버전을 교체하는 의도가 포함되며, 배리언트(variant)는 이전 버전의 교체 없이 형상에 포함되는 새 버전임.
5.
기준선(Baseline)
S/W 기준선이란 S/W 생명주기 내의 특정 시간에 정식으로(formally) 지정되고 고정된 S/W 형상 항목의 모음으로, 본 용어는 합의하에 구성된 S/W 형상 항목의 특정 버전을 지칭할 때에도 사용함. 두 경우 모드에서 기준선은 정식 변경 통제 절차를 통해서만 변경 가능하며, 기준선과 기준선에 대해 승인된 모든 변경은 현재 승인된 형상을 나타냄.
일반적으로 사용되는 기준선에는 기능(functional), 할당(allocated), 개발(developmental), 제품(product) 기준선이 있어. 기능 기준선은 검토된 시스템 요구사항에 대응하고, 할당 기준선은 검토된 S/W 요구사항 명세 및 S/W 인터페이스 요구사항 명세에 대응. 또한 개발 기준선은 S/W 생명 주기 내 특정 시간의 진화 중인 S/W 형상을 표현함. 본 기준선의 변경 권한은 기본적으로 개발 조직에 부여되나, 타 조직(ex. SCM 또는 시험 팀)과 공유될 수도. 제품 기준선은 시스템 통합을 위해 인수된 S/W 완성품에 대응하며 일반적으로 SCMP에서 식별됨.
6.
S/W 형상 항목 획득(Acquiring software configuration items)
SCM 통제 하의 S/W 형상 항목은 각기 다른 시간에 위치함, 이는 이들 항목과 특정 기준선의 연계가 S/W 생명 주기 내 특정 시점에 이루어짐을 의미함. 사건 트리거(triggring event)란 정형 검토(formal review)와 같은 정식 수용 작업(acceptance task) 형태(form)의 완료를 뜻함. Figure 4는 생명주기가 진행됨에 따라 기준선 기반 항목의 발전을 보여주는데, 본 그림은 폭포수 모형에서만 통용됨에 유의할 것. S/W 변경 요구(SCR)는 3.1 S/W 변경 요구, 평가, 승인 절에서 기술됨.
SCI 획득 이후, 항목의 변경은 해당 SCI와 관련 기준선에 대한 적합성을 나타내도록, 또한 SCMP에 계획된 대로 정식 승인 절차를 거쳐야. 승인 이후 해당 항목은 적절한 절차를 거쳐 S/W 기준선에 통합됨.
2.2. S/W 라이브러리(Software Library)
S/W 라이브러리란 S/W 개발, 사용, 유지보수를 돕기 위해 설계된 통제 하의 S/W 모음 및 관련 문서임(IEEE610.12-90). 이는 또한 S/W 배포 관리 및 인도 활동에도 이용되는 등, 여러 형태의 라이브러리가 사용될 수 있는데, 이들 각각은 S/W 항목의 특정 성숙도 수준에 대응함. 예를 들어, 워킹 라이브러리(working library)는 코딩을 지원하고, 프로젝트 지원 라이브러리(project support library)는 시험을 지원하며, 마스터 라이브러리(master library)는 완료 제품 지원에 사용됨. 적절한 SCM 통제 수준은 각각의 라이브러리와 연계됨. 접근 제어(Access control)과 백업 장비로 대표되는 보안은 라이브러리 관리의 핵심 측면임.
각 라이브러리에 사용되는 도구는 SCI 통제와 라이브러리 접근 통제 등의 SCM 통제를 지원해야 하는데, 예컨데 워킹 라이브러리 수준에서 도구는 개발자, 유지보수자 및 SCM을 위한 코드 관리 기능을 지원하여야. 통제 수준이 높아질 수록 접근은 더욱 제한적이어, SCM이 주요 사용자가 됨.
또한 이들 라이브러리는 작업과 프로세스 측정을 위한 중요 정보원이 되기도
3. S/W 형상 통제(S/W Configuration Control)
S/W 형상 통제는 S/W 생명 주기 내에서의 변경 관리에 관계됨. 본 활동은 변경 대상 결정 프로세스, 특정 변경 승인 권한, 변경 사항의 구현, 프로젝트 요구사항에 대한 정형 편차(formal deviation) 개념 및 요구 사항의 포기(waiver)를 다룸. 본 활동 중 추출된 정보는 변경 트래픽, 파손, 재작업 측면에 대한 측정에 도움이 됨.
3.1. S/W 변경의 요구, 평가, 승인(Requesting, Evaluating and Approving Software Changes)
통제 항목에 대한 변경 관리의 첫 단계는 변경 대상의 결정임. S/W 변경 요구 프로세스(Figure 5 참조)는 다음과 같은 사항에 대해 정형적 절차를 제공함; 변경 요구의 제출/기록, 잠재적 비용 및 제안된 변경 영향도의 평가, 제안된 변경의 승인, 수정, 반려.
S/W 형상 항목 변경 요구는 S/W 생명 주기 내 모든 시점/주체에 의해 나타나며, 해결책과 변경 우선순위가 함께 하기도. 변경 요구 소스 중 한 예는 문제 보고서(Problem Report)임. 또한 소스의 종류에 상관 없이 변경 유형(ex, 결함 또는 향상)은 SCR에 기록되곤 하며, 이를 통해 변경 유형에 따라 결함을 추적하고 변경 사항을 취합할 기회를 갖게 됨.
SCR을 얻게 되면, (영향 분석으로 알려진) 기술 평가를 통해 해당 변경 요구를 수용할 만한지 여부를 판단케 하는 수정 범위를 결정하게 되는데, 이때 S/W(또는 H/W까지) 간 관계에 대한 이해도가 중요한 역할을 담당함. 마지막으로, 해당 기준선 및 관련 SCI, 해당 변경의 본성에 관계하는 기 수립된 권위 조직이, 변경 요구의 기술적/관리적 측면을 평가하고 제안된 변경을 수용, 수정, 거절, 연기함.
1.
S/W 형상통제위원회(CCB; Software Configuration Control Board)
제안된 변경에 대한 수용 또는 거절 권한은 보통 형상통제위원회(CCB)라 일컫는 엔티티에 부여되며, 작은 프로젝트에서의 본 권한은 다수의 인원으로 구성된 위원회보다는 리더 또는 특정 인원에 부여됨. 변경 권한은 여러 수준으로 나뉠 수 있어 이는 여러 기준, 즉 해당 항목의 중요도, 변경의 성격(ex. 예산 및 일정에 대한 영향), 생명 주기 내의 현재 위치에 따라 달라짐. 여러 CCB의 구성 방법 역시 이들 기준에 따라 다양함(그 중에도 단일 SCM 대표는 항상 존재). CCB의 권한이 엄격히 S/W로 제한될 경우 이를 가리켜 S/W 형상통제위원회(SCCB)라 하며, 본 CCB의 활동은 S/W 감사 또는 검토에 치중됨.
2.
S/W 변경 요구 프로세스(Software change request process)
효과적으로 S/W 변경 요구(SCR; Software Change Request) 프로세스를 이루기 위해서는 변경 요구 생성, 변경 프로세스 흐름의 강제, CCB 결정의 획득 및 변경 프로세스 정보의 보고를 위한 지원도구 및 절차를 사용해야. 또한 본 도구의 기능(capability)과 문제 보고 시스템의 연계는 보고된 문제의 해결책을 추적하는 데 많은 도움이 됨.
3.2. S/W 변경 구현(Implementing Software Changes)
승인된 SCR은 기 정의된 S/W 절차 및 일정에 따라 구현되는데, 많은 SCR이 동시에 구현될 수 있기 때문에 SCR과 연계된 S/W 버전과 기준선의 추적을 위한 수단이 요구됨. 변경 프로세스 종료 부에서는 완료된 변경에 대한 형상 감사와 S/W 품질 검증(verification)이 수행되는데, 본 활동에는 승인된 변경만이 적용되었는지 여부에 대한 검증도 포함됨. 변경 요구 프로세스는 보통 변경에 대한 SCM 승인 정보의 문서화 역시 함께 이룸.
변경의 실제 구현은 라이브러리 도구에 의해 지원되는데, 본 도구의 기능으로 버전 관리 및 코드 저장소 지원이 있음. 최소한 이들 도구는 체크 인/아웃과 관련 버전 제어 기능을 지원함. 좀더 강력한 도구는 병렬적 개발 및 지리적으로 분산 환경을 지원하기도. 또한 이들 도구는 독립적 SCM 그룹의 통제 아래 특화 응용프로그램으로 지정되기도 하며, SWE 환경의 핵심부가 되기도.
3.3. 편차와 포기(Deviations and Waivers)
SWE 노력에 부가된 제한조건 또는 개발 활동 중 만들어진 명세에는 생명 주기 중 지정된 시점에 충족될 수 없는 조항(provision)이 있을 수 있음. 편차(deviation)란 특정 조항에 대한 개발에 앞서 해당 조항에서 벋어나도 괜찮음을 나타내는 권한임. 포기(waiver)란…(deviation is an authorization to depart from a provision prior to the development of the item. A waiver is an authorization to use an item, following its development, that departs from the provision in some way) 두 경우 모두에서 정형 프로세스는 조항에 대한 편차 및 포기(waiver)의 승인 취득을 위해 사용됨.
4. S/W 형상상태기록(SCSA; Software Configuration Status Accounting)
S/W 형상상태기록이란 효과적인 S/W 형상 관리를 위한 기록(recording) 및 보고임.
4.1. S/W 형상 상태 정보(Software Configuration Status Information)
S/W 형상상태기록(SCSA) 활동에는 생명주기 진행 중 필요 정보의 획득 및 보고를 위한 시스템의 설계 및 운용이 있음. 여느 정보 시스템에서와 마찬가지로, 형상의 진화를 위한 관리 대상인 형상 상태 정보는 반드시 식별, 수집 및 유지보수가 이루어져야 하는데, 다양한 이들 정보 및 측정은 SCM 프로세스 지원과 관리/SWE/타 관련 활동의 형상 상태 보고 등 다양한 용도로 사용됨. 정보의 유형에는 승인된 형상 식별 요소 뿐 아니라 식별 요소, 변경에 대한 현 구현 상태, 편차, 포기(waiver) 등이 포함됨.
SCSA 데이터 컬렉션 및 작업 보고를 수립하기 위해서는 자동화 도구의 지원이 필요함. 본 도구로서 데이터베이스라던가 독립적(standalone) 도구 또는 통합 도구 환경 등이 있음.
4.2. S/W 형상 상태 보고(Software Configuration Status Reporting)
보고된 정보는 다양한 조직적/프로젝트 요소, 즉 개발팀, 유지보수 팀, 프로젝트 관리, S/W 품질 활동 등에 사용될 수 있음. 보고는 특정 질문에 대한 답을 산출하는 질의(query) 또는 기 설계된 보고서의 주기적 산출물(production) 형식이 될 수도. 생명주기 중 상태기록에 의해 만들어진 정보는 품질 보증 기록이 될 수도 있음.
본 정보는 현 형상 상태에 대한 보고 뿐 아니라 SCSA를 통해 얻은 정보는 관리 이윤/개발/SCM에 대한 기조 자료가 됨. SCI에 대한 변경 요구 횟수 및 변경 요구 구현에 요구되는 평균 시간 등은 이에 대한 좋은 예임.
5. S/W 형상 감사(Software Configuration Auditing)
S/W 감사란 S/W 제품과 프로세스가 규제(regulation), 표준, 안내선(guideline), 계획, 절차에 대한 준수성(conformance) 평가하는 활동임(IEEE1208-97). 감사는 다양한 감사자의 역할 및 책임으로 구성된 프로세스에 따라 수행되기에, 각각의 감사 활동은 주의 깊게 계획되어야. 감사에는 짧은 기간 내 다양한 작업을 수행하기 위해 다수의 인원이 결부되기도 하며, 계획과 수행에 대한 지원 도구는 해당 프로세스 수행에 많은 도움이 됨.
S/W 형상 감사 활동에는 요청된 기능적/물리적 특성을 만족시키기 위한 항목의 범위 결정이 포함되기도 하는데, 본 비공식적 감사는 생명 주기에서의 주안점이 되기도. 주요 계약(governing contract)에는 기능적 형상 감사(FCA; Functional Configuration Audit)과 물리적 형상 감사(PCA; Physical Configuration Audit)란 두 개의 공식 감사가 요구되기도. 위 세 가지 감사는 제품 기준선 수립을 위한 사전 조건을 이룸.
5.1. S/W 기능 형상 감사(S/W FCA; Software Functional Configuration Audit)
S/W FCA의 목적은 S/W 항목이 주요 명세와 일관되는지의 여부 확인에 있음. S/W V&V(Verification and Validation) 활동 산출물은 본 감사를 위한 핵심 입력 값이 됨.
5.2. S/W 물리적 형상 감사(S/W PCA; Software Physical Configuration Audit)
S/W PCA의 목적은 설계 및 참조 문서가 만들어진 S/W 제품과 일관되는지 여부 확인에 있음.
5.3. S/W 기준선의 내부 공정 감사(In-Process Audits of a Software Baseline)
위에서도 언급했듯이, 감사는 특정 형상 항목의 현 상태를 조사하기 위해 개발 프로세스 중에 수행될 수 있어. 이 경우 감사는 예제 기준선 항목에 적용되는데, 본 목적은 성능의 명세 준수성의 확인 또는 개발 기준선에 맞도록 문서가 지속적으로 진화해가는지 여부의 확인에 있음.
6. S/W 릴리즈 관리 및 인도(Software Release Management and Delivery)
본 컨텍스트에서 '릴리즈(release)' 란 용어는 S/W 형상 항목에 대한 개발 활동 외부로의 분배(distribute)를 뜻하며, 여기에는 고객으로의 릴리즈 뿐 아니라 내부 릴리즈 역시 포함됨. S/W 항목의 각기 다른 버전이 인도(delivery) 가능할 경우(즉 각기 다른 플랫폼의 버전이라던가 각기 다른 기능성(capability)를 지닌 버전 등), 종종 특정 버전 및 패키지의 재생성이 이루어지곤 함.
S/W 라이브러리는 릴리즈와 인도 작업의 핵심 요소임.
6.1. S/W 빌드(Software Building)
S/W 빌드란 적절한 형상 데이터를 통해, S/W 형상 항목의 바른(correct) 버전을 결합(combine)하여, 고객 또는 시험 팀 등의 타 수취자에게 인도(delivery)하기 위해 실행(executable) 프로그램으로 만드는 것을 뜻함. H/W나 펌웨어가 결부된 시스템의 경우, 실행 프로그램은 시스템 빌드 팀으로 인도됨. 빌드 명령(instruction)은 적합한 빌드 단계가 올바른 순서로 수행될 수 있도록 함. 또한 새로운 릴리즈를 위해 S/W 빌드가 이루어질 경우, SCM에 요구되는 사항으로 이전 릴리즈의 재생성 기능이 있는데, 이는 복구(recovery), 시험, 유지보수 또는 추가적 릴리즈를 위한 것임.
S/W는 컴파일러와 같은 지원 도구를 통해 빌드 되는데, 이때 해당 도구는 이전 빌드 S/W 형상 항목의 복사본을 재생성할 수 있어야. 이를 위해 지원 도구 및 관련 빌드 명령 버전 역시 SCM 통제 하에 있어야.
이들 도구는 S/W 항목의 정확한 버전 선택에 유용한데, 이를 통해 주어진 대상 환경에 맞는 버전 선택 및 적절한 형상 데이터를 통한 선택된 버전의 S/W 빌드 프로세스 자동화가 편리함. 특히 대규모의 병렬적/분산 개발 환경에서는 본 도구가 필수적임. 대부분의 SWE 환경은 본 기능을 갖추고 있으며, 스크립트 언어 또는 그래픽 기반의 등의 다양한 종류가 있음.
제품의 빌드 및 빌드 프로세스는 S/W 품질 검증 대상이 되기도. 빌드 프로세스에서 추출된 산출물은 이후를 위한 참조 데이터로 필요로 하게 되며, 때로는 품질 보증을 위한 기록이 되기도 함.
6.2. S/W 릴리즈 관리(Software Release Management)
S/W 릴리즈 관리 활동에는 제품 요소, 즉 실행 프로그램, 문서, 릴리즈 노트, 형상 데이터의 식별, 패키징, 인도가 포함됨. 제품 변경이 지속적으로 이루어질 경우, 고려해야 할 사항 중 하나는 릴리즈의 발행(issue) 시점의 결정이며, 문제의 심각성과 이전 릴리즈의 결함 밀도 측정 결과가 본 결정에 미치는 주요 인자임. 패키징 작업에서는 어떤 제품 항목을 인도할 것인지를 식별한 후, 이들 항목에 대한 올바른 배리언트의 선택이 이루어짐. 릴리즈의 물리적 내용이 담긴 정보는 버전 기술 문서(version description document)라 하는 한편, 릴리즈 노트는 보통 새 기능, 알려진 문제, 적절한 제품 운용을 위한 플랫폼 요구사항을 기술함. 또한 패키지에는 설치 및 업그레이드 안내서가 담김. 마지막으로, 릴리즈 관리 활동에는 여러 고객 및 대상 시스템에 배포된 제품의 추적이 있음.
상기 릴리즈 관리는 관련 지원 도구를 통해 효과적으로 이룰 수 있으며, 본 도구의 주요 기능 중 하나는 각 릴리즈와 SCR에 대한 매핑 및 다양한 대상 플랫폼 및 고객 환경의 정보 유지임.