어쨌건간에 흘러가는 者

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 3/3

어쨌건간에 — Tue, 23 Feb 2010 23:41:22 +0900

[주의 사항]
IEEE에서 제작한 본 SWEBOK에는 무시하기 어려운 비판론이 제기된 상황입니다. 주된 비판 주체로 초기에 본 문서 제작에 참여했다 철수한 ACM이 있으며, Grady Booch, Cen Kaner가 보입니다. 비판의 핵심은 본 문서가 주장하는 바인 'Generally accepted'가 사실이 아니라는 점과 본 문서와 밀접히 연계된 licensing(CSDP)의 무효성입니다.

상기 비판론을 염두하여 문서에 대한 내용을 받아들이길 권장합니다.

Translated/Summarized by Anyflow (anyflow@gmail.com / anyflow.net)

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 2/3 에서 계속합니다...

3. 실제적 고려사항(Practical Considerations)

SQM(Software Quality Management)는 S/W 프로세스, 제품, 자원의 모든 측면에 적용됨. SQM은 프로세스와 프로세스 소유자, 이들 프로세스에 필요한 사항, 프로세스 측정 및 해당 결과물, 피드백 경로(channel)를 정의함. SQM 프로세스는 다양한 활동으로 구성됨.

3.1. S/W 품질 요구사항(S/W Quality Requirements)

1. 영향 인자(Influence factors)

다양한 인자가 SQM 활동 및 기법의 계획, 관리, 선택에 영향을 미침:

- S/W가 내재될 시스템의 도메인(안전-중대(safety-critical), 임무(role)-중대, 업무(business)-중대)

- 시스템 및 S/W 요구사항

- 시스템에서 사용될 상업적(외부) 또는 표준(내부) 컴포넌트

- 적용 대상의 특정 S/W 공학 표준

- 개발, 유지보수, 품질 평가 및 향상에 사용될 방법 및 S/W 도구

- 모든 프로세스의 예산, 스태프, 프로젝트 조직, 계획, 일정

- 예정 사용자 및 예정된 시스템 사용법

- 시스템 통합 수준

이들 인자에 대한 정보는 SQM 프로세스의 구성 및 문서화 방법과 SQM 활동 선택 방법, 필요로 하는 자원 및 무엇이 노력(effort)에 제한을 부가하는지에 영향을 미침.

2. 의존가능성(dependability)

시스템 실패가 극도로 심각한 결과를 초래할 경우, 전체 의존가능성(H/W, S/W 및 인간)은 기본 기능(basic functionality)에 앞서는 품질 요구사항임. S/W 의존가능성은 장애 내성(fault tolerance), 안전(safety), 보안(security) 및 사용성과 같은 특성을 포함하며 신뢰성 또한 의존가능성으로 표현되는 척도임(ISO9126).

The body of literature for systems must be highly dependable (“high confidence” or “high integrity systems”). Terminology for traditional mechanical and electrical systems which may not include software has been imported for discussing threats or hazards, risks, system integrity, and related concepts, and may be found in the references cited for this section.

3. S/W의 무결성(integrity) 수준

무결성 수준은 가능한 S/W 실패 결과와 실패 확률에 기반하여 결정됨. 안전 또는 보안이 중요한 S/W의 경우, 안전성 위험 분석 또는 보안 위협 분석과 같은 기법을 사용하여 잠재적 문제점 식별을 이루는 계획 활동 개발에 사용되기도. 비슷한 S/W의 실패 사례 분석도 결함 발견과 품질 평가(assess)에 어떤 기법이 도움이 되는지 식별하는 데 도움이 됨. IEEE1012-98에서는 무결성 수준(ex. 무결성 등급(gradation of integrity))을 제안함.

3.2. 결함 특성화(Defect Characterization)

SQM 프로세스는 결함을 찾아냄. 이들 결함에 대한 특성화를 통해, 제품을 이해하고 프로세스/제품의 교정(correction)을 촉진하며 프로젝트 관리/고객에게로 프로세스/제품의 상태를 알릴 수 있게 됨. 많은 결함 분류체계가 존재함과 동시에 결함 또는 실패의 분류체계에 대한 합의 시도가 있었음에도, 문헌에 따르면 이들 중 사용되는 체계는 소수임.

결함(이상현상) 특성화는 감사 및 검토에서도 사용되며, 검토 리더는 종종 팀원이 제공한 이상현상 목록을 검토 미팅에서 이용하기도.

설계 기법과 언어가 진화하고 S/W 기술 전체가 진보함에 따라 새로운 결함 군이 나타나고 이전에 정의된 군(class)을 해석하기 위한 쉽지 않은 노력이 요구됨. 결함을 추적할 때 S/W 기술자의 관심은 결함 개수 뿐 아니라 종류에 대해서도 이루어짐. 분류를 통하지 않은 정보 자체만으로는 결함의 원인을 식별하는 데 별 의미가 없는데, 이는 문제(들)에 대해 분류가 이루어져야 이들에 대한 어떠한 결정을 이룰 수 있기 때문. 핵심은 조직과 S/W 기술자에게 의미 있는 결함 분류 체계(taxonomy)를 수립하는 것임.

SQM을 통해 S/W 개발과 유지보수의 전 단계에서 나타나는 정보에 대한 발견을 이룸. 보통 "결함(defect)"란 단어가 사용될 때는 아래 정의된 대로 "장애(fault)"을 지칭하게 됨. 하지만 다른 문화와 표준에서는 얼마간 다른 의미로 사용되기도 하기도. IEEE610.12-90에서는 몇몇 사항을 다음과 같이 정의함.

- 오류(Error) : "컴퓨팅의 결과와 올바른(correct) 결과 간의... 차이"

- 장애(Fault) : "컴퓨터 프로그램 내에서의 바르지 않은(incorrect) 단계, 프로세스 또는 데이터 정의"

- 실패(Failure) : "장애의 (바르지 않은) 결과"

- 실수(Mistake) : "바르지 않은 결과를 내게 하는 인간의 행동"

S/W 장애의 결과로서 테스트 중 발견된 실패 역시 본 섹션에서 논의되었듯 결함의 일부임.

신뢰성 모형은 S/W 시험 또는 S/W 서비스 중에 수집된 실패 데이터를 통해 만들어지며, 따라서 이는 미래의 실패 예측과 시험 종료 시점 결정을 돕는 데 사용될 수 있음.

SQM 조사 결과로 이어지는 활동 중 하나는 시험(examination) 중에 제품 결함을 제거하는 것임. 결함 추적 및 제거 뿐 아니라, 조사 결과 분석 및 요약, 측정 기법을 통한 제품과 프로세스의 향상 등의 활동을 통해 SQM 활동 가치를 최대한 이끌어내게 됨.

프로세스 향상은 S/W 공학 프로세스 KA에서 주로 다루며, SQM 프로세스는 이를 위한 정보 소스 역할을 담당.

SQM 이행 중에 발견된 데이터의 부적절성 및 결함은 기록되어야 하며, 이들 정보 및 이슈, 결정 대상의 기록을 위해 기술 검토, 감사, 인스펙션 및 기록기(recorder)가 사용됨. 이 때 자동화 도구는 결함 정보 추출에 도움이 됨. 결함에 관한 데이터는 SCR(Software Change Request; S/W 변경 요청) 양식에 수집 및 기록되며 이후 분석 도구를 통해 데이터베이스에 (자동 / 수동적으로) 저장됨. 결함 보고서는 조직 관리를 위해서도 제공됨.

3.3. S/W 품질 관리 기법(Software Quality Management Techniques)

SQM 기법은 다양한 형태로 분류 가능: 정적, 인간-집중적(people-intensive), 분석적, 동적

1. 정적 기법(Static Techniques)

- 정적 기법에는 S/W 실행을 제외한 프로젝트 문서, S/W 및 S/W 제품에 관한 타 정보에 대한 검사(examination)가 있음. 이들 기법은 3.3.2에서 정의된 인간-집중적 활동을 포함하거나 3.3.3에서 정의하는 분석적 활동을 포함할 수도 있으며, 자동화 도구의 지원 여부에 상관 없이 개개인에 의해 수행됨.

2. 인간-집중적 기법(People-intensive techniques)

인간-집중적 기법은 검토, 감사를 포함하며 공식 미팅(formal meeting)에서 비공식 모임(informal gathering), 책상머리에서의 검사(desk-check situation) 등 다양한 상황을 포괄하지만, (보통, 적어도) 둘 또는 그 이상의 인원이 관여되어야. 사전 준비는 반드시 필요. 검사 중에 인원 이외에 필요로 하는 자원으로 검토목록(checklist) 및 분석적 기법/시험 결과가 있음. 검토 및 감사를 참조.

3. 분석적 기법(Analytical techniques)

S/W 기술자는 보통 분석적 기법을 적용하는데, 때론 여러 S/W 기술자가 동일 기법을 사용하더라도 적용되는 제품 부위는 각기 다름. 도구 주도적 기법이 있는가 하면, 어떤 기법은 수동적(manual)임. 또, 어떤 기법은 결함에 대한 직접적 조사를 이루지만, 이는 보통 타 기법에 대한 지원을 위해 사용됨. 또한 전체 품질 분석의 일부로 다양한 평가를 이루는 기법도 있는데, 그 예로 복잡도 분석, 제어 흐름 분석, 알고리즘 기반(algorithmic) 분석이 있음.

각 분석 유형마다 주어진 목적이 다르며, 모든 프로젝트에 이들 유형 모두가 적용되는 것은 아님. 지원 기법의 예로 복잡도 분석이 있는데, 이는 개발/시험/유지보수에 설계 또는 구현에 필요 이상으로 복잡한지 여부를 판별하는데 유용하며, 해당 분석 결과는 시험 케이스(test case) 개발에 사용되기도. 제어 흐름 분석과 같은 결함-발견 기법은 타 활동 지원에 유용함. 여러 알고리즘이 내재된 S/W에서는 알고리즘 기반 분석이 중요한데, 이는 부정확한 알고리즘이 심각한 결과를 초래할 수 있기 때문.

좀더 정형적인 분석적 기법은 정형 방법(formal method)으로 알려져 있으며, 이는 S/W 요구사항 및 설계의 검증에 사용됨. 여기서는 S/W의 중요 부분에 정확성 증명이 적용되며, 주로 특정 보안성 및 안전성을 요구하는 중대 시스템의 핵심 부분을 검증하는 데 사용됨.

4. 동적 기법(Dynamic techniques)

개발과 유지보수에 수행되는 다양한 동적 기법은 일반적으로 시험(test)이지만, 시뮬레이션(simulation), 모델 체킹(model checking) 및 심볼 실행(symbol execution) 역시 동적 기법으로 분류됨. 코드 읽기는 정적 기법이지만 숙련된 S/W 기술자는 이를 읽어나가면서 코드를 실행할 수도 있기에, 이 경우 코드 읽기 역시 동적 기법으로 이해할 수도 있음. 분류화에 있어 이 같은 불일치는 조직의 각기 다른 역할의 인원이 이들 기법을 각기 달리 적용함을 나타냄.

따라서 몇몇 시험 기법은 프로젝트 조직에 따라 개발 프로세스, SQA 프로세스 또는 V&V 프로세스에서 수행될 수도 있음. SQM 계획은 이들 중 시험(test)에 집중하기 때문에, 본 섹션에서는 시험에 대해 언급함.

5. 시험(Testing)

SQA 및 V&V에서 기술하는 보증 프로세스는 S/W 요구사항 명세에 관계된 모든 산출물에 대한 검사를 이루어 산출물의 추적성, 일관성, 완전성, 정확성과 성능을 확인함. 본 확인에는 개발 및 유지보수의 산출물 및 결과의 수집, 분석 및 측정을 포함함. SQA는 적절한 시험 유형이 계획, 개발 및 구현되었는지 여부와 V&V 프로세스에서 시험 계획, 전략, 케이스 및 절차가 개발되었는지 여부를 확인함.

시험은 S/W 시험 KA에서 논의되지만, 두 가지 시험 유형이 SQA와 V&V 영역에 포함되는데, 이는 이들 유형이 프로젝트에 사용된 자재(material)에 대한 책임을 지기 때문.

- 프로젝트에서 사용될 도구에 대한 평가 및 시험

-

프로젝트에서 사용될 컴포넌트 및 COTS 제품 준수성(comformance) 시험 또는 준수성 시험 검토

때론 독립적 V&V 조직이 시험 프로세스를 모니터링하고, 실제 실행 목격을 통한 특정 절차에 따른 수행 여부를 확인하기도. 또다시 V&V는 시험 자체를 평가하기 위해 사용될 수도 있음 : 시험 계획 및 절차의 적합성, 결과의 적합 및 정확성을 기반으로.

V&V 조직에서 수행하는 시험의 또 다른 유형은 third-party 시험으로서 여기서 Third Party란 개발자가 아닌 동시에 해당 제품 개발에 관여하지도 않음. 대신 third-party는 어떤 권위체(authority)로에게서 부여 받은 신뢰를 바탕으로 하는 독립적 기관(설비; facility)임. 본 시험의 목적은 제품이 특정 요구사항을 만족하는지 여부 판단에 있음.

3.4. S/W 품질 측정(Software Quality Measurement)

S/W 제품 품질 모형은 종종 제품에서 추출한 각 품질 특성의 정도를 결정케 하는 측정을 포함함.

측정이 적절히 선택되었을 경우, 다양한 방법으로 S/W 품질 향상을 유도하며 관리 중 이루어지는 의사결정 프로세스(decision-making process)에 유용함. 또한 S/W 프로세스의 문제 영역과 병목지점을 찾는데 도움이 되며, SQA 및 장기 프로세스 품질 향상을 위한 S/W 기술자의 작업 품질 평가에 유용함.

S/W가 점점 발전해감에 따라 품질에 대한 질의는 S/W의 동작 여부에서 측정 가능 품질 목표 수립에 얼마나 유용한지에 대한 사항으로 나아감.측정이 SQM을 직접적으로 지원하는 부문이 좀더 있는데, 여기에는 시험 종료 시기 결정도 포함. 본 용도로서 신뢰성 모형과 벤치마크가 있는데 이들 둘 모두 결함 및 실패 데이터를 이용함.

SQM 프로세스 비용은 프로젝트 구성 시 언제나 부각되는 이슈임. 이를 위해 종종 일반 비용 모형(generic models of cost)가 사용되는데, 이는 결함 발견 시점과 결함 수정에 소요되는 노력 수준에 기반함. 프로젝트 데이터 역시 더 나은 비용 결정에 도움이 됨(S/W 공학 프로세스 및 S/W 공학 관리 KA 참조).

SQM 보고서(Report) 자체는 본 프로세스 뿐 아니라 전체 S/W 생명주기 프로세스의 향상에 가치 있는 정보를 제공함.

품질 특성 및 제품 기능의 측정은 그 자체로 유용하여(ex. 결함 개수 또는 결함 비율), 수학적/도식적 기법이 측정 해석을 위해 적용될 수도. 이들은 다음과 같이 분류 가능

- 통계-기반(Statistically-based). Ex. Pareto analysis, run charts, scatter plots, normal distribution

- 통계적 시험. Ex. the binomial test, chisquared test

- 트렌드 분석(Trend analysis)

- 예측. Ex. 신뢰성 모형

통계 기반 기법 및 시험은 S/W 제품에서 더 많이 문제를 일으키는 영역에 대한 식별을 가능케 함. 차트 및 그래프는 의사결정자로 하여금 가장 필요로 해 보이는 자원에 집중 가능토록 하는 가시화 도구임. 트렌드 분석은 시험 등에서 스케줄이 고려되지 않았다는 점 또는 어떤 결함 군의 문제가 개발 중에 수정되지 않으면 문제가 심각해질 수 있음을 나타냄. 예측 기법은 시험 일정 수립 및 실패 예측에 도움이 됨. 측정에 대한 보편적 논의는 S/W 공학 프로세스 및 S/W 공학 관리 KA에서 이루며, 시험 측정에 대한 심화된 정보는 S/W 시험 KA에서 다룸.

시험 커버리지 측정은 시험 활동이 얼마나 남았는지 예상 및 남겨진 잠재적 결함의 예측에 도움이 됨. 이들 측정 방법을 통해 결함 프로파일은 각 application 도메인 별로 개발 가능함. 이후 해당 조직 내에서 차기 S/W 시스템을 준비할 경우 본 프로파일은 SQM 프로세스 수립 및 발생 가능성 높은 문제의 식별에 도움이 됨.

이와 비슷하게 벤치마크 또는 해당 도메인의 전형적 결함 집계는 제품의 인도 가능 시점 결정에 유용함.

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 2/3

어쨌건간에 — Tue, 23 Feb 2010 23:18:26 +0900

[주의 사항]
IEEE에서 제작한 본 SWEBOK에는 무시하기 어려운 비판론이 제기된 상황입니다. 주된 비판 주체로 초기에 본 문서 제작에 참여했다 철수한 ACM이 있으며, Grady Booch, Cen Kaner가 보입니다. 비판의 핵심은 본 문서가 주장하는 바인 'Generally accepted'가 사실이 아니라는 점과 본 문서와 밀접히 연계된 licensing(CSDP)의 무효성입니다.

상기 비판론을 염두하여 문서에 대한 내용을 받아들이길 권장합니다.

Translated/Summarized by Anyflow (anyflow@gmail.com / anyflow.net)

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 1/3 에서 계속합니다...

2. S/W 품질 관리 프로세스(Software Quality Management Processes)

SQM(Software Quality Management)는 S/W 프로세스, 제품, 자원의 모든 측면에 적용됨. SQM은 프로세스와 프로세스 소유자, 이들 프로세스에 필요한 사항, 프로세스 측정 및 해당 결과물, 피드백 경로(channel)를 정의함. SQM 프로세스는 다양한 활동으로 구성됨.

S/W 품질 계획에는 다음과 같은 사항이 관련됨: (1) 품질 특성 용어를 통한 필요 제품 정의(SWE 관리 KA 참조) (2) 요구된 제품 제작(achieve)을 위한 프로세스 계획. 이는 SQM 프로세스 자체를 위한 계획과는 구분되는데, SQM 프로세스 계획은 해당 계획 하에 만들어진 실제 구현물이 아닌 기 계획된 품질 특성을 평가(assess)함. S/W 제품이 얼마나 고객과 이해 당사자 요구를 만족시킬지/시키는지, 이들에게 얼마나 가치를 제공할지, S/W 요구사항을 충족시키는데 요구되는 S/W 품질을 얼마나 제공할 지가 (여기에 속함; 원문에는 본 문장이 없음)

SQM은 최종 제품 뿐 아니라 중간 산출물 또한 평가함. 몇몇 SQM 프로세스가 IEEE12207.0-96에 다음과 같이 정의됨.

- 품질 보증 프로세스(Quality assurance process)

-

검증 프로세스(Verification process)

-

확인 프로세스(Validation process)

-

검토 프로세스(Review process)

-

감사 프로세스(Audit process)

이들 프로세스 공통적으로 품질을 강조하고 잠재적 문제 발견에 관심을 두지만, 강조점은 각기 다름. 또한 SQM 프로세스는 SWE 프로세스 전체 품질 지표를 포함하는 관리에 대한 일반적 정보를 제공함. SWE 프로세스 KA와 SWE 관리 KA에서는 S/W 개발 조직을 위한 품질 프로그램에 대해 논하며, SQM은 이들 KA에서 다루는 사항에 대한 관련 피드백을 제공.

SQM 프로세스는 S/W 계획(ex. 관리, 개발, 형상 관리) 방법, 지정된 요구사항에 대한 중간 및 최종 제품의 충족 방법을 알리는 작업과 기법으로 구성됨. 이들 작업을 통한 결과는 교정 활동을 수행하기 전에 보고서로 취합되며, SQM 프로세스의 관리를 통해 해당 보고서가 정확한지 여부를 확인하게 됨.

SQM 프로세스 간에는 밀접한 연관성이 있음. 따라서 이들은 중첩되기도 하며 때로는 합쳐(combine)지기도.

위험 관리 또한 S/W 품질을 위해 중요한 역할을 담당함. 확립된 위험 분석과 S/W 생명주기 프로세스 관리 기법은 고품질의 제품을 위한 잠재력을 증가시킴. SWE 관리 KA의 위험 관리를 참조할 것.

2.1. S/W 품질 보증(SQA; Software Quality Assurance)

SQA는 S/W 제품과 프로세스가 프로젝트 생명 주기 내에서 다음과 같은 사항을 통해 요구사항을 만족시키도록 함: 고품질의 S/W임을 신뢰 가능토록 하는 활동에 대한 계획, 강제화, 수행. 본 뜻은 문제가 명확하고 적절하게 명시되고(state) 솔루션의 요구사항이 절절히 정의 및 표현되었음을 확인하는 것임. SQA가 추구하는 바인 제품 개발과 유지보수 전체에 걸친 품질 유지에 있어, 이는 문제와 숨겨진 필수 기능을 초기에 식별 가능케 하는 다양한 활동을 각 단계마다 수행함을 통해 이룸. 프로세스에 관한 SQA의 역할은 계획된 프로세스가 적절한지, 이후 계획에 따라 구현되는지, 그리고 관련 측정 프로세스가 적절한 조직에 제공되는지에 대한 확인에 있음.

SQA 계획은 다음과 같은 사항을 확인하기 위해 사용할 수단을 정의 : 특정 제품을 위해 개발된 S/W가 사용자의 요구사항을 만족시키는지 및 프로젝트 제한사항 내에서 가능한 최고의 품질을 이루는지 여부. 이를 이루기 위해 먼저 품질 대상이 명확히 정의되고 이해되어야 함. 또한 S/W 관리, 개발, 유지보수 계획을 고려하여야.

품질 활동 각각은 해당 비용/자원 요구사항과 전체 관리 목표, 그리고 해당 목표에 관련한 일정과 함께 S/W 공학 관리, 개발 또는 유지보수 계획 내에서 설계됨. SQA 계획은 S/W 형상 관리 계획과 일관성을 유지하여야. SQA 계획에서 식별될 것으로는 문서, 표준, 프랙티스, 프로젝트 전체에 적용되는 규정(convention), 그리고 이들을 검사(check)하고 정확성과 준수성을 감시(monitor)할 방법임. 측정, 통계적 기법, 문제 보고 및 수정(correction) 활동을 위한 절차, 도구, 기법, 방법론, 물리적 미디어에 대한 보안, 훈련, 그리고 SQL 보고 및 문서화 역시 SQA 계획에서의 식별 대상임. 이 뿐 아니라, SQA 계획은 타 종류의 S/W 활동(ex. 프로젝트에 사용될 공급자 S/W나 COTS(Commercial off-the-shelf) S/W의 획득, 설치, 인수 이후의 서비스) 계획에 대한 품질 보증 활동에 대해서도 주의(address)를 기울임. 또한 S/W 품질에 주요 영향을 미치는 보고 및 관리 활동 뿐 아니라 수용 기준 역시 SQA 계획에 포함됨.

2.2. 검증과 확인(Verification and Validation)

S/W V&V란 제품 수명주기 전체에 걸쳐 S/W 제품을 평가(assess)하기 위한 규율화된 접근법임. V&V 노력은 품질 기반으로 S/W가 형성되는지와 해당 S/W가 사용자 요구사항을 충족시키는지에 중점을 둠(IEEE1059-93).

V&V는 S/W 제품 품질에 직접적으로 관여하여, 시험 기법을 사용하여 결함을 발견하고 중간 제품을 평가하는데, 이 경우, S/W 생명주기 프로세스의 중간 과정이 해당 평가 대상임.

또한 V&V 프로세스는 개발 또는 유지보수 활동을 통한 제품이 해당 활동의 요구사항을 준수하는지 여부와 최종 S/W 제품이 주어진 목적 및 사용자 요구사항을 만족시키는지를 결정. 검증(Verification)은 제품이 제대로 만들어지는지를 확인하는 시도로, 생산 활동의 결과물이 이전 활동에서 부여된 명세를 따르는지에 중점을 둠. 확인(Validation)은 바른 제품이 만들어졌는지를 확인하는 시도로, 제품이 의도한 목적을 충족시키는지를 판단. 검증과 확인 프로세스 모두 개발 또는 유지보수 초기 단계에서 수행됨.

V&V 계획의 목적은 각각의 자원, 역할, 책임을 명확히 할당하는 데 있음. 따라서 V&V 계획 문서는 다양한 자원, 역할, 활동 및 기법/도구를 기술함. IEEE1012-98, IEEE1059-93는 V&V 계획에 무엇이 지정되는지를 지정함. 또한 본 계획은 관리, 의사소통, 정책, V&V 활동 절차, 활동간 상호작용 뿐 아니라 결함 보고 및 문서화 요구사항을 기술함.

2.3. 검토와 감사(Reviews and Audits)

IEEE12207에서는 검토와 감사를 개별적 토픽으로 다룸. 검토 및 감사 프로세스는 IEEE12207에서 폭넓게 정의하며, 세부 사항은 IEEE1028-97에서 찾아볼 수 있음. IEEE1028에서는 검토와 감사를 5개 유형으로 나눔.

- 관리 검토(Management reviews)

- 기술 검토(Technical reviews)

- 인스펙션(Inspections)

- 워크쓰루(Walk-throughs)

- 감사(Audits)

1. 관리 검토(Management Reviews)

"관리 검토의 목적은 프로세스의 감시(monitor)와 계획과 일정 상태의 결정, 요구사항과 시스템 할당의 확정(confirm), 또는 관리 접근법의 목적 부합성에 대한 평가임"[IEEE1028-97]. 관리 검토는 변경 사항의 결정 및 S/W 프로젝트 중 요구되는 바른 활동을 지원함. 또한 계획, 일정, 요구사항의 적합성을 결정하고 이들에 대한 진행상태 및 일관성을 감시함. 본 검토는 다음과 같은 문서와 함께 수행되기도 : 감사 보고서, 진척 보고서, V&V 보고서, 다양한 유형의 계획서(위험 관리, 프로젝트 관리, S/W 형상 관리, S/W 안정성, 위험 평가).

2. 기술 검토(Technical Reviews)

"기술 검토의 목적은 S/W 제품이 의도된 사용에 적합한지 여부를 결정하기 위한 S/W 제품의 평가임. 본 목적은 승인된 명세와 표준에 대한 불일치성의 식별에 있음. 본 활동의 결과로, 제품이 명세에 부합(meet)하고 표준을 따르는지(adhere) 및 변경이 통제되고 있는지를 확인할 수 있는 증거 기반의 관리가 제공되어야"[IEEE1028-97]

기술 검토에서는 역할이 명시적으로 지정됨 : 결정자(decision-maker), 검토 리더(leader), 기록자(recorder), 검토 활동을 지원하기 위한 기술 스태프(staff). 기술 검토를 진행하기 위해서는 다음과 같은 필수적 입력 사항이 요구됨.

- 목적 진술(Statement of objectives)

- 대상 S/W 제품(A specific software product)

- 대상 프로젝트 관리 계획(The specific project management plan)

- 해당 제품에 관계된 이슈 사항(The issues list associated with this product)

- 기술 검토 절차(The technical review procedure)

해당 팀은 검토 절차를 따름. 또한 기술적 자격을 갖춘 인원이 제품 개관을 발표하고 한번 이상의 미팅을 통해 검사(examination)가 수행됨. 기술 검토는 조사 수행 목록에 나열된 모든 활동이 끝났을 때 완료됨.

3. 인스펙션(Inspections)

"인스펙션의 목적은 S/W 제품 변칙(anomaly)의 검출 및 식별임"[IEEE1028-97]. 검토와 대비되는 두 개의 주요 차이점으로,

- 인스펙션 팀의 모든 멤버에 대한 관리적 위치(management position)을 지닌 단일 인원이 있어, 이는 인스펙션에 참여하지 않음.

- 인스펙션은 인스펙션 훈련을 받은 중립적 촉진자(impartial facilitator)에 의해 주도됨.

또한, S/W 인스펙션은 검토와는 달리, 언제나 중간 또는 최종 산출물의 저자가 있음.

인스펙션에는 인스펙션 인도자(leader), 기록자(recorder), 독자(reader) 및 2 ~ 5 명의 인스펙터(inspector)가 포함됨. 인스펙션 팀은 각기 다른 전문가(expertise)로 구성될 수 있어, 여기에는 도메인 전문가, 설계 방법 전문가 또는 언어 전문가 등이 포함됨.

인스펙션은 보통 제품의 상대적 소규모 부위 단위로 수행됨. 각 팀 멤버는 검토 미팅에 앞서 S/W 제품과 검토 입력물에 대해 시험을 이루어야 하는데, 본 시험에는 제품의 소규모 부위 또는 전체 제품의 특정 단면(ex. 인터페이스)에 대한 분석적 기법(3.3.3 참조)이 적용되기도. 발견된 변칙은 문서화되어 인스펙션 주도자에게 제출되어야.

인스펙션 중 인도자(leader)는 세션을 열어 모두가 준비되었는지를 검증해야. 이상(anomaly)과 질문이 담긴 체크리스트(checklist)는 인스펙션의 기본적인 도구임. 발견된 변칙은 결과 목록에 분류되며, 해당 팀은 결과 목록을 통해 완전성과 정확성을 검토하게 됨. 인스펙션 종료 결정은 다음 세 가지 기준 중 하나에 부합되었을 때 이루어짐.

1. 수용. 재 작업이 필요 없거나 최소한의 재 작업 만을 요구(Accept with no, or at most minor, reworking)

2. 재작업 검증 이후 수용(Accept with rework verification)

3. 재 인스펙션(Reinspect; 부적합. 재 작업 이후 인스펙션을 다시 수행해야)

인스펙션 미팅은 보통 몇 시간을 소요하는 한편 기술 검토 및 감사는 더 넓은 범위를 다루며 더 많은 시간을 소요함.

4. 워크쓰루(Walk-throughs)

"워크쓰루의 목적은 S/W 제품의 평가임. 워크쓰루는 S/W 제품에 관계된 인원에 대한 교육 목적으로 수행될 수도"[IEEE1028-97]. 워크쓰루의 주요 목적으로,

- 변칙 발견(find anomalies)

- S/W 제품 향상(improve the software product)

- 대안 구현물 고려(consider alternative implementations)

- 표준과 명세에 대한 준수성 평가(evaluate conformance to standards and specifications)

워크쓰루는 인스펙션과 유사하지만 보통 덜 공식적으로(formally) 수행됨. 워크쓰루는 주로 S/W 기술자로 구성되어, 자신의 작업물에 대한 팀동료의 검토 기회 부여 목적으로, 일종의 확인(assurance) 기법임.

5. 감사(Audits)

"감사의 목적은 S/W 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차에 대해 준수하고 있는지 여부를 독립적으로 평가하는 데 있음"[IEEE1028-97]. 감사는 공식적으로 구성되는 활동으로, 감사 참여자는 특정 역할, 즉 감사 지휘자(lead auditor), 감사자(auditor), 기록자(recorder) 또는 발기자(initiator) 등이 부여되며, 피감사 조직의 대표도 포함됨. 감사는 비준수 사항의 사례(instance)를 식별하고 해당 팀으로 하여금 교정 활동(corrective action)을 요구하는 보고서를 만들어냄.

IEEE1028-97에서 보이듯이, 검토와 감사에 대한 다양한 공식적 이름이 존재하지만, 중요한 점은 이들 활동이 모든 제품에 대해서, 개발과 유지보수 프로세스의 모든 단계에서 이루어질 수 있다는 것임.

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 3/3 으로 이어집니다...

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 1/3

어쨌건간에 — Tue, 23 Feb 2010 00:23:56 +0900

Translated/Summarized by Anyflow (anyflow@gmail.com / anyflow.net)

Introduction

많은 조직에서 품질이란 용어를 달리 정의해왔는데, Phil Crosby는 '사용자 요구사항으로의 일치(conformance)'로, Watts Humphrey는 '사용하기에 알맞은 뛰어난 수준의 달성'이라 함. 한편 IBM은 '시장-주도 품질(market-driven quality)'란 용어를 만들었는데, 이는 전체 고객의 만족 달성이란 생각에 기반하며, 또 다른 조직에서 만든 '고객-주도 품질'이란 비슷한 용어 역시 고객 만족이 주요 고려사항으로 포함됨을 나타냄. 최근 ISO9001-00에서는 품질을 '요구사항을 달성(fulfill)하기 위한 고유 특성(inherent characteristics) 집합의 수준'이라 정의.

S/W 품질에 대한 고려는 생명주기 프로세스를 초월하여, SWE 활동 전체에 편재되어 많은 타 KA에서 고려됨. 본 장이 다루는 대상은 평가 대상의 S/W에 대한 실행을 요구하지 않는 정적(static) 기법을 다루며 동적(dynamic) 기법은 S/W 시험 KA에서 다룸.

Breakdown of topics

1. S/W 품질 기본(Software Quality Fundamentals)

품질 요구사항의 합의를 이루기 위해서는 품질의 많은 측면에 대해 정식으로 정의 및 논의를 이루어야.

S/W 요구사항은 필요한 S/W의 품질 특성을 정의함과 동시에, 측정 방법 및 이들 특성의 평가를 위한 수용 기준에 영향을 미침.

1.1 SWE 문화 및 규범(Software Engineering Culture and Ethics)

S/W 기술자는 S/W 품질 활동(commitment)을 그들의 문화의 일부로 받아들여야.

규범(Ethics)은 S/W 품질, 문화 및 S/W 기술자의 태도에 의미 있는 영향을 미침.

1.2. 품질의 가치 및 비용(Value and Costs of Quality)

"품질"이란 용어는 보이는 것처럼 그리 간단하지는 않아, 모든 공학 제품(engineered product)의 경우에서 제품의 특정 관점에 관계되고 기대되는 여러 품질이 있는데, 이들은 제품 요구사항이 만들어진(set down) 시점에서 논의 및 결정됨. 품질 특성(characteristic)은 요구될 수도, 아니 요구될 수도 있으며, 또한 더 높은/낮은 수준으로 요구될 수도 있고 이들 간에 트레이드오프가 이루어질 수도. 품질 비용은 예방 비용, 평가(appraisal) 비용, 내부 실패 비용, 외부 실패 비용 등으로 나뉠 수 있음.

S/W 프로젝트에 담긴 동기는 가치를 담은 S/W의 생성이며 본 가치는 비용으로 정량화 될 수도 있음. 고객은 최대 비용을 마음에 두고, 그 대가로 S/W의 본 기본 목적이 충족되기를 기대하게 됨. 또한 고객은 S/W의 품질에 대해서도 일정 기대를 갖게 될 수도 있지만, 품질 이슈 또는 이에 관계된 비용 문제에 대해서는 아무 것도 모를 수도. S/W에서 특성(characteristic)이란 단순이 부가적(decorative)인 것일까, 또는 핵심적인 것일까. 이에 대한 대답이 그 중간에 있다면 항시 그래왔듯이, 이는 고객을 결정 프로세스의 일부로 참여시키고 비용과 이익에 대해 전부 알리느냐의 문제가 됨. 이상적으로 보자면, 이들 결정의 대부분은 S/W 요구사항 프로세스에서 이루게 되지만, S/W 생명주기 전체에 걸쳐 이슈가 나타나기 마련임. 따라서, 이들 결정을 이루는 방법에 대해서는 명확히 정의된 규칙은 없지만, S/W 기술자는 품질 대안과 이에 대한 비용에 대해 준비를 하여야.

1.3. 모형과 품질의 특성(Models and Quality Characteristics)

S/W 품질 특성에 대한 용어는 택소노미(또는 S/W 품질 모형)마다 달라, 각 모형은 각기 상이한 계층 수준 및 특성 개수를 가짐. S/W 품질 특성(characteristic, attribute) 모형은 S/W 제품 품질에 대한 논의, 계획 및 수준 정의(rate)에 유용한데, ISO9126-01에서는 S/W 제품 품질에 관한 3개의 모형, 즉 내부 품질, 외부 품질, 사용 중 품질을 정의하고, ISO14598-98에서 관련 내용을 논함

1.3.1. SWE 프로세스 품질(Software engineering process quality)

- S/W 품질 관리 및 SWE 프로세스 품질은 S/W 제품 품질과 직접적인 관계를 맺음. S/W 조직의 능력을 평가하는 모형과 기준은 주로 조직적/관리적 고려측면을 반영하는데, 이는 SWE 관리 및 SWE 프로세스 KA에서 다룸.

- 프로세스 품질과 제품 품질을 완전히 구분하는 것은 물론 불가능하지만, 프로세스 품질은 S/W 제품 품질 특성에 영향을 미쳐 결국 고객이 느끼게 될 사용 상 품질에 영향을 미치게 됨.

- 주요 품질 표준에는 TicKIT과 ISO9003-4와 함께하는 ISO9001-00이 있음. 품질 관리에 관련한 프로세스 영역으로, a) 프로세스 및 제품 품질 보증, b) 프로세스 검증(verification), c) 프로세스 확인(validation)이 있으며, CMMi에서는 검토(review)와 감사(audit)를 확인 과정으로 넣는데, IEEE12207.0-96에서는 이들을 독립적 프로세스 영역으로 다룸.

- ISO9001과 CMMi 중 어느 것을 품질 확인에 사용할 것인지에 대해 많은 논쟁이 있었는데, 결론적으로 이들 둘은 상호보완적이어, ISO9001 인증은 CMMi에서 더 높은 수준의 성숙도를 얻는데 크게 도움이 됨.

1.3.2. S/W 제품 품질(Software product quality)

- S/W 기술자는 무엇보다도 해당 S/W의 실제 목적을 결정해야 하는데, 이는 결국 고객의 요구사항에서 오며, 여기에는 단순히 기능적 요구사항 뿐 아니라 품질 요구사항까지 함께하게 됨. 따라서, S/W 기술자는 명시적으로 드러나지 않은 품질 요구사항까지 추출할 책임이 있을 뿐 아니라 품질이 얼마나 중요한지, 얼마나 얻기 어려운지 또한 논할 책임이 있음. S/W 품질에 관계된 모든 프로세스는(예를 들어, 품질 수립, 검토, 향상 등) 이들 요구사항을 염두한 상태에서 설계되어야 하며, 추가적 비용 역시 함께 지출되어야.

- ISO9126-01 표준에서는 3개 품질 모형 중 2개, 즉 관련 품질 특성 및 부특성과 S/W 제품 품질 평가를 위한 측정기준을 정의함.

- '제품'이란 용어는 최종 S/W 제품을 빌드하기 위해 사용된 모든 프로세스의 산출물을 포함. 이에 대한 예로, 전체 시스템의 요구사항 명세, 시스템의 S/W 컴포넌트에 대한 요구사항 명세, 설계 모듈, 코드, 시험 문서화 및 품질 분석 작업의 결과로 만들어진 보고서 등이 있어. 품질에 관련한 대부분의 행동이 S/W 및 시스템의 성능에 연계된 기술이지만, 괜찮다 싶은 SWE 프랙티스는 SWE 프로세스 전체에 걸쳐 중간 제품에 대한 품질 평가를 요구함.

1.4 품질 향상(Quality Improvement)

S/W 제품 품질은 지속적 향상을 이루는 반복적 프로세스를 통해 향상될 수 있는데, 여기에는 관리 통제, 코디네이션(coordination), 많은 병렬적 프로세스, 즉 (1)S/W 생명주기 프로세스, (2)오류/결함 검출, 제거, 예방 프로세스, (3)품질 향상 프로세스로부터의 피드백이 요구됨.

품질 향상 이면에서는 예방 및 초기 오류 검출, 지속적 향상, 고객의 관심(focus)을 통한 품질 기반 빌드라는 이론과 개념이 존재. 이들 개념은 프로세스 품질이 제품 품질에 직결한다는 경험에 기반.

PDCA(Plan, Do, Check, Act)의 전체 품질 관리 프로세스와 같은 접근법은 품질 목표가 담긴 도구이고, 관리 활동에서는 프로세스와 제품 평가 및 결과 식별을 이룸. 이후 세부 활동 및 적정 기간 내 수행 가능한 향상 프로젝트를 식별하는 향상 프로그램이 개발됨.

PDCA(Plan, Do, Check, Act)의 종합 품질 관리(TQM; Total Quality Management)와 같은 접근법은 품질 목표를 이룰 수 있는 도구임.

Management sponsorship supports process and product evaluations and the resulting findings. Then, an -improvement program is developed identifying detailed actions and improvement projects to be addressed in a

feasible time frame. Management support implies that each improvement project has enough resources to achieve the goal defined for it. Management sponsorship must be solicited frequently by implementing proactive communication activities. The involvement of work groups, as well as middle-management support and

resources allocated at project level, are discussed in the Software Engineering Process KA.

[SWEBOK 2004 요약/번역] 11. S/W 품질(Software Quality) 2/3 로 이어집니다...

Guns N' Roses 공연 후기

어쨌건간에 — Tue, 15 Dec 2009 20:29:41 +0900

6시 공연 시작 예정이 7시로 늦춰지더니만, 오프닝 시작은 8시. 울나라 두 팀이 총 3곡을 부른 20분이 지난 이후, 무려 한시간 10분여를 가득 매운 스탠딩 석에서 마냥 기다리려니 허리가 쑤시지 않을려야 않을 수가 없었다는. 나도 이제 나이가 있는데 말야. 뭐 나 뿐인가? 본 공연의 관중 나이를 따지자면 난 중간 즈음에 속한다. 개중 머리가 벗겨진 아저씨도 보이더만.
근데 왠걸, 9시 반 경부터의 두 시간 여 공연을 위해 똑같은 자리에서 똑같이 서있었는데, 끝난 이후에는 언제 아팠냐는 듯이 다시금 멀쩡해지는 건 역시 액슬의 힘이던가? 그 만큼 만족했다는 뜻이다.

공연 타이틀이 Appetite for destruction도 아니고 Use your illusion도 아닌 Chinese Democracy임을 감안한다면, 본 신보의 곡을 적지 않게 배치했다는 것은 놀랄 일도, 그들을 탓할 일도 아니다. 본 신보 곡이 나올 때의 반응이 뜨겁지 않으리란 것은 예상했던 바이지만 '썰렁'까지 해질 줄이야. 곡을 따라부르고 있는 나를 신기한, 아니 얼마간은 이상한 듯이 쳐다보는 주위의 시선은 상당히 당황스러웠던 부분 중 하나. 아쉬웠던 건 본 앨범 중 가장 좋아하던 Prostitute가 빠졌다는 건데, 꽤나 긴 러닝 타임이나 얼마간 단조 냄새를 풍기는 곡 성격을 감안하자면 예상되기도 했던 부분이다.

한명이 더 늘어난 3명의 기타리스트 중 DJ Ashba가 상당히나 인상적이었는데 포스트 슬래시라고 불러도 그다지 이상하지 않을 듯한... 아우라, 실력(?), 외모. 액슬의 소개에 이어 진행된 그의 정면 스피커 위 기타 쏠로가 Sweet Child O'Mine으로 바뀌던 그 순간의 그 짜릿함은!

액슬의 목소린 최고 수준. 그 찢어지는 목소리 자체가 맘에 안든다면 할 말 없고, 첫 곡부터 목청껏 불러 제끼길래 이거 얼마나 갈까 싶었는데, 그 고주파 목소릴 마지막 곡까지의 계속된 고음 영역에서도 꾸준하게 유지했다는 데 상당히 놀라웠다. 이에 비교되는 한 옥타브 내려간 김빠진 액슬의 모습은 타 공연 실황에서 어렵지 않게 찾아 볼 수 있다.
왕년 꽃미남의 아우라가 아닌 Meat Loaf를 연상시키는 돼지 모습에 실망했다면, 이를 기대한 그 마음의 철부지스러움을 탓해야 한다. 액슬의 나이 이제 쉰을 바라본다. 고음역을 한청 부르짖은 후 잠시 허릴 잡고 힘들어하는 그의 '퍼포먼스'는 그간의 고압적 카리스마가 아닌 인간적 유머를 보이고자 하는 그의 마음을 다분히 보이는데, 난 당시 이 모습을 보고 '이제야 철들었군'하고 '잘못' 생각했다(공연 지연의 원인이 전날 도착이란 약속을 펑크내고 당일 그 시간에야 대만에서 도착했기 때문이었다는 이야길 나중에 접하고는, 그 생각을 바로 접었다~ ㅋ)

예상외로 빠진 곡으로 Don't Cry, Civil War, Catcher In the Rye 및 Use Your Illusion의 상당수 곡들.
예상 밖으로 들어간 곡은 상당 수의 Appetite for Destruction의 것들,
가장 아쉬웠던 곡으로는 Estranged, Prostitute, Don't Cry.

한줄 결론. 액슬이 있기에 Guns N' Roses다.

p.s.
1. 대중음악 평론가란 명함을 앞에 걸고 글빨 속에 본 공연에 대한 악감정을 표출한 글이 보이는데, 딱 한 마디 해주고 싶다. 그 따위로 글을 쓰니 평론가란 직업이 욕을 먹는 거라고. 강산도 두 번이나 변해가려는 십 수년전의 GNR 모습이란 자신의 잣대에 공연이 들어맞지 않았다고 힘껏 내려깐 그 글은 사실 '악플'에 다름 아니다. 개인적으로 꽤나 즐겨 찾던 신문 사이트에 이 어이없는 욕이 포스트되는 꼴을 보자니,,, 후훔.

2. 위의 사진은 iphone으로 찍은 건데, 줌이 안되니 액슬이 코딱지 만하게 나왔다. 똥돼지가 열심히 뛰어다니는 모습이 꽤나 귀여워 보였다는... ㅋ

[SWEBOK 2004 요약/번역] 7. S/W 형상관리(Configuration Management)

어쨌건간에 — Sat, 28 Nov 2009 12:58:37 +0900

Translated/Summarized by Anyflow (anyflow@gmail.com / anyflow.net)

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에 대한 매핑 및 다양한 대상 플랫폼 및 고객 환경의 정보 유지임.