어쨌건간에 흘러가는 者

[주의 사항]
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 프로세스 수립 및 발생 가능성 높은 문제의 식별에 도움이 됨.

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

[주의 사항]
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 으로 이어집니다...

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

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

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 로 이어집니다...

 

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

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

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

 

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

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

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

Introduction
생명주기의 유지보수 단계(phase)는 보증(warranty) 기간 또는 인수의 후-구현(post-implementation) 단계를 따라 시작되지만, 유지보수 활동은 좀더 일찍 시작됨.
그간 유지보수는 S/W 생명 주기의 주요 활동임에도 불구하고 대부분의 조직에서 타 활동에 비해 덜 중요시 되었지만, 이제는 S/W 개발에 투자하기 보다는 기 운용되는 S/W를 최대한 유지하려고 하기에 주목 받고 있음. Y2K 문제는 S/W 유지보수에 좀더 관심을 갖게 하였고, Open Source 패러다임은 타인에 의해 개발된 개발물에 대한 유지보수의 필요성을 더욱 부각시켜.
본 안내서는 S/W 유지보수를 비용-효과적인 S/W 지원에 요구되는 활동의 총체로 정의함. 본 활동은 인수 후(post delivery) 활동 뿐 아니라 인수 이전 단계에서도 수행됨. 인수 이전 단계의 활동은 유지보수를 위한 인수 후 운영 계획 및 이전(transition) 활동을 위한 세부계획 결정(logistics determination)을 포함함. 인수 후 활동에는 S/W 수정, 훈련, 운영 및 help desk와의 연계(interface)가 포함됨. S/W 유지보수 KA는 모든 타 SWE 측면과 연계됨.

Breakdown of topic

1. S/W 유지보수 기본(Software Maintenance Fundamentals)
본 섹션은 S/W 유지보수의 역할과 범위를 이해하는 데 요구되는 하부 기반 형성을 이루는 개념과 용어를 소개함. 본 섹션은 또한 유지보수의 필요성에 대한 정의와 강조를 이룸. S/W 유지보수의 카테고리는 기반 의미의 이해를 위해 중요.
1.1. 정의 및 용어(Definitions and Terminology)
IEEE1219 S/W 유지보수 표준에서 S/W 유지보수는, 인수 후 S/W 제품 수정을 통한 결함 교정, 성능 또는 타 속성의 향상 또는 변경된 환경에 대한 제품의 적응으로 정의되며, 인수 이전의 유지보수 활동에 대해서도 다룸.
S/W 생명주기에 관한 IEEE 12207 표준은 유지보수를 주요 생명주기 공정의 하나로 다루며, "문제 또는 향상 요구에 대한 코드 및 관련 문서의 변경. 기존 S/W 제품의 완전성(integrity) 유지를 위한 수정"의 프로세스로 기술함.
ISO/IEC 14764, S/W 유지보수의 국제표준에서는 IEEE12207과 동일한 정의를 따르며 계획과 같은 인수 이전의 유지보수 활동을 강조함.
1.2. 유지보수의 본성(Nature of Maintenance)
S/W 유지보수는 운영 생명주기를 통해 S/W 제품을 다룸(sustain). 수정 요구는 로그로 남겨지고 추적되며, 제안된 변경의 영향 결정, 코드 및 타 S/W 인공물(artifact)의 수정, 시험 수행 및 새 버전이 인도됨. 또한 사용자에 대한 훈련과 일일 지원이 이루어짐. 유지보수는 개발보다 더 넓은 영역을 다룸.
IEEE 12207에서 S/W 유지보수의 주요 활동을 다음과 같이 식별함; 프로세스 구현, 문제 및 수정 분석, 수정 구현, 수정 검토/승인, 이전(migration), 폐기. 이들 활동은 3.2 유지보수 활동에서 다룸.
유지보수자(maintainer)는 개발자의 S/W에 대한 지식을 배우며, 개발자와의 계약이나 유지보수자의 조기 개입은 유지보수 노력을 줄이는 데 도움이 됨.
1.3. 유지보수의 필요성(Need for Maintenance)
유지보수는 사용자 요구사항을 지속적으로 만족시키기 위해 필요하며, 어떤 S/W 생명 주기 모형을 사용한 S/W 개발에도 적용됨. 시스템은 수정적(corrective) 및 비 수정적 S/W 행동으로 인해 변경됨. 유지보수의 목적으로,
 ○ 결함 교정(correct)
 ○ 설계 향상
 ○ 구현 향상
 ○ 타 시스템과의 연동(interface)
 ○ 타 H/W, S/W, 시스템의 기능 사용을 위한 프로그램 적용
 ○ 기존(legacy) S/W 이전(migrate)
 ○ S/W 폐기가 있음.
유지보수자의 활동은 네 개의 주요 활동으로 요약됨.
 ○ S/W의 일일 기능에 대한 제어 유지보수
 ○ S/W 수정에 대한 제어 유지보수
 ○ 기존 기능의 완전화(perfecting)
 ○ S/W 성능의 수용 불가한 수준으로 낮아짐에 대한 방지
1.4. 유지보수 비용의 주요 용처(Majority of Maintenance Costs)
S/W 유지보수는 S/W 생명주기를 위한 재정적 자원 주된 부분을 소비함. 유지보수에 대한 일반적 인식은 단순히 결함 수정에 불과하지만, 각종 연구와 조사에 따르면, S/W 유지보수 노력의 80% 이상이 비수정적 활동에 사용됨.
S/W 유지보수는 교정(correction) 뿐 아니라 그룹의 향상에도 결부되는데, 이 점 역시 높은 교정 비용의 한 원인임. S/W 유지보수 카테고리의 이해 및 시스템의 유지보수성에 미치는 인자에 대한 이해 역시 S/W 유지보수 비용 구조의 이해에 도움이 됨. 본 인자의 기술/비기술적 내용은 다음과 같음
 ○ 응용프로그램의 유형
 ○ S/W의 새로움 정도(novelty)
 ○ S/W 유지보수 스태프의 능력
 ○ S/W 생명 기간
 ○ H/W 특성
 ○ S/W 설계, 작성, 문서화, 시험 품질
1.5. S/W의 진화(Evolution of Software)
유지보수는 진화적 개발로서, 유지보수 결정은 시간이 지나면서 시스템(및 S/W)에 어떤 일이 벌어졌는지를 이해하는 데서 출발함. 유지보수는 결코 끝나지 않고 지속된다는 점을 제외하면 개발의 연장으로 바라볼 수도. 진화에 따라 복잡도는 증대됨(따로 복잡도 감소를 위한 활동을 이루지 않는 이상.)
S/W 는 정규적 행동과 경향을 보이기에 측정이 가능함. 유지보수 노력을 추정하기 위한 예측 모형이 개발되어, 유용한 관리 도구가 존재함.
1.6. 유지보수 카테고리(Categories of Maintenance)
ISO/IEC 14764는 S/W 유지보수를 네 개의 카테고리로 나눔.
- 교정적 유지보수 : S/W 제품에 대한 반응적 수정으로, 인수 이후에 발견된 문제를 교정하기 위함.
- 적응적 유지보수 : 인수 이후의 S/W 제품에 대한 수정으로, S/W 제품이 변화된/변화 진행중인 환경에서 사용 가능하도록 하는 데 목적이 있음.
- 완전적 유지보수 : 성능 및 유지보수성 향상을 위한 인수 이후의 S/W에 대한 수정.
- 예방적 유지보수 : S/W 제품에서 결함이 드러나기 전에 사전에 탐지 및 교정하는 데 목적을 둠.
IEEE 14764는 Table 1에서처럼, 적응적/완전적 유지보수를 향상 카테고리로, 교정적/예방적 유지보수를 교정 카테고리로 묶음. 가장 나중에 나타난 예방적 유지보수는 안전성이 중요(critical)할 경우에 종종 수행됨.

2. S/W 유지보수의 주요 이슈(Key Issues in Software Maintenance)
유지보수는 그 자체를 위한 기술 및 관리 이슈를 낳는데, 500K 줄의 코드에서 결함을 찾는 것은 한가지 예. 또한 제한된 자원의 효율적 운용, 다음 배포를 위한 코딩 중의 미래를 위한 배포 계획, 현 배포에 대한 응급 패치 역시 여기에 속함. 이들 사항은 아래 네 개의 토픽으로 정리됨
 ○ 기술적 이슈
 ○ 관리적 이슈
 ○ 비용 추정
 ○ 측정
2.1. 기술적 이슈(Technical Issues)
1. 제한된 이해(Limited understanding)
제한된 이해란 S/W 기술자가 변화 또는 교정이 요구되는 S/W의 위치를 얼마나 빨리 이해할 수 있는지를 뜻함. 약 40 ~ 60%의 유지보수 노력이 이해에 사용된다는 연구가 있어, S/W 이해는 매우 중요.
텍스트 기반의 표현, 즉 소스코드의 이해는 더 어려운데, S/W 개발자의 설명 및 관련 문서가 없는 상황에서의 S/W의 변화 추적은 이의 한 예. 따라서 S/W 기술자는 초기에 S/W에 대한 이해도가 낮을 가능성이 크며 이를 해결하는 데 많은 노력이 요구됨.
2. 시험(Testing)
재귀 시험은 중요한 유지보수 활동이지만 이를 위한 시간을 얻기란 어려움. 또한 유지보수 팀 멤버 각각이 동시에 각기 다른 문제를 다룰 경우에 대한 조정(coordinating) 시험 역시 문제. 또한 S/W가 중요 기능을 수행할 경우에는 이를 offline으로 만들어 시험하는 것도 불가능. S/W 시험 KA의 2.2.6. 회귀 시험에서 이에 대한 문제를 다룸.
3. 영향 분석(Impact analysis)
영향 분석은 기 S/W의 변화에 따른 영향 분석을 어떻게, 비용 효과적으로 이룰지에 대해 다룸. 유지보수자는 S/W의 구조와 내용에 대해 사전 파악하여, 영향 분석, 즉 변화 요구가 미치는 시스템 및 S/W 및 이를 위한 자원을 추정해야 하며, 이에 따른 위험도 역시 결정해야 함.
수정 요구(MR; modification request) 또는 문제 보고(PR; Problem Report)라고 불리는 변화 요구는 먼저 S/W 용어로 분석 및 번역되어야 하며, 이는 S/W 형상 관리 공정에 변화 요구가 입력된 후에 수행됨. 영향 분석의 목적으로는,
 ○ 작업의 계획 및 구현(implement)을 위한 변화 범위 결정
 ○ 해당 작업 수행에 필요한 자원에 대한 정확한 추정 개발
 ○ 요구된 변화의 비용/이익 분석
 ○ 타인과의 변화로 인한 복잡도에 대한 논의
문제의 중요도(severity)는 문제 해결 방법 및 시점 결정에 종종 사용되며, 이후에 S/W 기술자는 영향을 받는 컴포넌트를 식별함. 여러 잠재적 해결책이 제시되며, 최선의 방법으로 권고안이 만들어짐.
유지보수를 감안한 S/W 설계는 영향 분석에 많은 도움이 됨. S/W 형상 관리 KA 참조.
4. 유지보수성(Maintainability)
IEEE610.12-90에서 정의하는 유지보수성이란 특정 요구사항을 만족시키기 위한 유지보수, 향상, 적응, 교정의 쉬운 정도이며, ISO/IEC는 이를 품질 특정의 하나로 정의함(ISO9126-1).
유지보수성의 하위 특성은 S/W 개발 활동 중에 지정,검토, 제어되어야 하며, 이는 유지보수 비용을 줄이기 위함임. 하지만 이는 달성되기 어려운 사항인데, S/W 개발자는 유지보수 요구사항보다는 타 요소에 더 많은 집중하기 마련이기 때문. 이는 시스템 문서의 빈약함으로 나타나 프로그램 이해와 영향 분석의 난해성의 가장 큰 원인으로 작용. 
시스템적, 성숙된 프로세스, 기법 및 도구는 시스템의 유지보수성에 많은 기여를 함.
2.2. 관리 이슈(Management Issues)
1. 조직 목표로의 정렬(Alignment with organizational objectives)
조직 목표는 S/W 유지보수 활동에 대한 투자의 성과를 어떻게 이끌어내는지에 대해 기술. 
S/W 개발은 주안점은 시간과 예산에 맞춰 사용자의 요구를 달성 및 인수에 있는 반면(프로젝트 기반), S/W 유지보수는 S/W 생명의 연장에 있으며,  S/W 갱신과 향상이 필요한 사용자의 요구에 의해 주도됨. 이들 두 가지 목적 모두에서 ROI는 명확하지 않음.
2. 유지보수자 형성(staffing)
스태핑은 S/W 유지보수를 위한 인력을 어떻게 끌어들이고 유지하느냐를 뜻함. 유지보수는 그다지 매력적인 작업으로 비춰지지 않음. S/W 유지보수 인원은 "2등 시민(second-class citizens)"으로 비춰져 사기(morale)에 안좋은 영향을 미친다는 연구 결과가 있음.
3. 프로세스(Process)
S/W 프로세스 수준에서 유지보수 활동은 S/W 개발과 많은 부분에서 공유되는 동시에(ex. S/W 형상 관리), S/W 개발에는 없는 다양한 활동이 있으며, 이들 활동이 바로 관리를 요구함.
4. 유지보수의 조직적 측면(Organizational aspects of maintenance)
조직적 측면이란 S/W 유지보수에서의 조직 및 기능의 책임에 대한 식별 방법을 뜻함. 유지보수는 해당 S/W 개발자 또는 타 인원으로 수행될 수도 있는데, 이들 두 선택지에 대한 결정은 상황에 따라 달라짐. 핵심은 조직의 구조에 상관없이 유지보수 책임을 부여하는 것임.
5. 외주(Outsourcing)
유지보수의 외주는 주요 산업으로 발전했지만, 보통 본 선택지는 비즈니스 상 덜 중요한 부문에서 사용되거나(해당 회사 그들의 핵심 사업에서 제어권을 상실하지 않기 위해.), 유지보수 전략 통제 방법을 찾았을 때만 유지보수 보수를 수행함. 
유지보수의 주요 부각 점 중 하나는 유지보수 서빙의 범위 및 계약 상세 사항을 결정하는 것임. 자료에 의하면 50%의 외주 업체가 명확한 SLA 없이 서비스를 제공하며, 이들 업체는 보통 계약 관계에 이르기까지 S/W를 평가하는 데 수 개월이 걸림.
2.3. 유지보수 비용 추정(Maintenance Cost Estimation)
계획에 있어 비용 추정은 S/W 유지보수의 중요한 측면임.
1. 비용 추정(Cost estimation)
2.1.3 영향 분석에서 비용 추정을 이룸. 유지보수 비용 추정은 많은 기술/비기술 인자에 의해 영향을 받아. ISO/IEC 14764에서는 "S/W 유지보수를 위한 자원 추정의 가장 인기있는 접근법은 parametric 모형과 경험의 사용이다"라고 하며, 종종 이들 둘은 조합되어 사용됨.
2. Parametric 모형(Parametric models)
본 모형은 이전 프로젝트의 데이터를 사용함. 기능 점수(Function Points)는 한 예.
3. 경험 기반 모형(Experience)
전문가 판단(ex. 델파이 기법의 사용을 통해)의 형태인 경험, 유추, WBS(Work Breakdown Structure)는 parametric 모형에서 데이터를 늘리기 위해 사용됨.  유지보수 추정에 대한 최고의 접근법은 경험적 데이터와 실험의 조합으로, 이들 데이터는 프로그램 측정의 결과로 제공되어야.
2.4. S/W 유지보수 측정(Software Maintenance Measurement)
네 개의 카테고리로 SEI가 식별한 S/W 측정기준, 즉 크기, 노력, 일정, 품질은 보편적으로 받아들여짐. 이들 측정기준은 유지보수자의 좋은 시작점임. 공정 및 제품 측정은 SWE 공정 KA에서 논하며, S/W 측정 프로그램은 SWE 관리 KA에서 논함.
1. 특정 측정(Specific Measures)
유지보수자는 어떤 측정기준이 해당 조직에 알맞은지를 결정해야. IEEE1219-98, ISO9126-1은 S/W 유지보수 측정 프로그램에 좀더 특화된 측정기준을 제시하는데, 이들은 유지보수성의 네 가지 부특성 각각에 대한 측정기준을 포함함.
 분석가능성(Analyzability) : 실패의 원인 또는 결핍, 수정 부분 식별에 필요한 유지보수자의 노력을 측정
 변경가능성(Changeability) : 특정 수정을 수행하는 데 연계된 유지보수자의 노력을 측정
 시험가능성(Testability) : 수정된 S/W를 시험하는데 요구되는 노력을 측정
S/W 유지보수성에 대한 몇몇 측정기준은 상용 도구를 통해 얻기도 함.

3. 유지보수 공정(Maintenance Process)
3.1. 유지보수 공정(Maintenance Processes)
유지보수 공정은 필요한 활동 및 이들 활동에 필요한 세부 입/출력을 제공하며, 이들은 IEEE 1219 및 ISO/IEC 14764에 기술됨.
IEEE1219에 기술된 유지보수 공정 모형은 인수-후 단계에서 시작되며, 유지보수를 위한 계획 등에 대해 논의함. Figure 2는 본 공정을 나타냄.

Figure 2. The IEEE1219-98 유지보수 공정 활동

ISO/IEC 14764 [ISO14764-99]는 IEEE 12207.0-96 유지보수 공정을 다듬은 것으로, ISO/IEC 유지보수 공정은 약간 다르게 취합되었다는 점을 제외하고는 IEEE의 것과 유사함. Figuire 3은 ISO/IEC의 유지보수 공정 활동임 

Figure 3. ISO/IEC 14764-00 S/W 유지보수 공정

ISO/IEC 14764의 주요 S/W 유지보수 활동은 다음과 같이 세부적으로 나뉨.
 ○ 공정 구현(process Implementation)
 ○ 문제 및 수정 분석(Problem and Modification Analysis)
 ○ 수정 구현(Modification Implementation)
 ○ 유지보수 검토/승인(Maintenance Review/Acceptance
 ○ 이전(Migration)
 ○ S/W 폐기(Software Retirement)
이들 이외에 타 모형도 존재하며 이 중 agile 방법론은 가벼운 공정을 추구하는데, 이는 빠른 유지보수 서비스의 순환(turn-around)의 지속적으로 증가하는 요구에 따라 부각된 것임.
3.2. 유지보수 활동(Maintenance Activities)
이미 논의되었던 바와 같이 유지보수 활동은 S/W 개발과 유사하여, 유지보수자는 분석, 설계, 코딩, 시험 및 문서화를 수행해야 하며, 개발 활동에서처럼 요구사항을 추적하여 기준선 변경에 따라 문서를 갱신해야. ISO/IEC 14764 표준은 유지보수자가 유사한 개발 공정을 참조할 때 반드시 그의 지정된 요구에 맞게 적용해야 한다고 권고함. 하지만 S/W 유지보수의 경우 몇몇 활동은 S/W 유지보수에 고유한 활동임.
1. 고유 활동(Unique activities)
S/W 유지보수에만 존재하는 공정, 활동 및 프랙티스가 많아. 다음은 그 예임.
 ○ 전이(Transition) : S/W가 점진적으로 개발자에서 유지보수자로 넘어가는 동안에 벌어지는 일련의 활동 절차.
 ○ 수정 요구 수락/거부(Modification Request acceptance/rejection) : 크기/노력/복잡도가 결부된 몇몇 수정 요구는 유지보수자에게 거부되고 개발자에게 넘겨지기도.
 ○ 영향 분석(Impact Analysis) : 2.1.3 섹션 참고
 ○ S/W 지원(Software Support) : 정보 요구에 관계된 사용자로의 도움(ex. 비즈니스 규칙, 검증, 데이터 의미, 임의 요구/보고)
 ○ 서비스 수준 합의(SLAs; Service Level Agreements) : SLAs와 특화된(도메인 지정적) 유지보수자에게 책임이 부가되는 유지보수 계약
2. 지원 활동(Supporting activities)
유지보수자는 S/W 유지보수 계획, S/W 형상 관리, V&V, S/W 품질 보증(SQA), 검토, 감사, 사용자 훈련 등의 지원 활동을 수행함. 유지보수자 훈련 또한 필요로 함.
3. 유지보수 계획 활동(Maintenance planning activity)
S/W 유지보수의 중요 활동은 계획이며 유지보수자는 여러 계획 측면에 관련한 이슈를 염두해야.
 ○ 업무 계획(조직 수준)
 ○ 유지보수 계획(전이 수준)
 ○ 배포/버전 계획(S/W 수준)
 ○ 개별 S/W 변경 요구 계획(요구 수준)
개별 요구 수준에서의 계획은 영향 분석 기간에 이루어지고, 배포/버전 계획 활동에서 유지보수자는 다음과 같은 활동이 요구됨.
 ○ 각 요구에 대한 가능 일자 산정
 ○ 뒤따르는 배포/버전의 내용에 대한 사용자와의 합의
 ○ 잠재적 충돌 식별 및 대안 마련
 ○ 해당 배포의 위험 평가 및 문제 발생 상황에 대한 대비책 마련
 ○ 모든 이해당사자로의 알림(inform)
S/W 개발은 몇 달에서 몇 년의 한정된 기간 내 이루어지는 반면, 유지보수는 보통 여러 해에 걸쳐 지속되므로, 자원의 산정은 유지보수 계획의 핵심 요소임. 자원은 반드시 개발자의 프로젝트 계획 예산에 포함되어야. 
S/W 유지보수 계획은 새 시스템의 개발 결정으로 시작해야 하고 품질 목표를 고려해야 함. 또한, 유지보수 개념 문서(concept document)가 유지보수 계획에 따라 마련되어야 하는데, 여기에는,
 ○ S/W 유지보수 범위
 ○ S/W 유지보수 공정의 적용
 ○ S/W 유지보수 조직의 식별
 ○ S/W 유지보수 비용의 추정이 포함됨.
다음 단계는 해당 S/W의 유지보수 계획의 마련임. 본 계획은 S/W 개발 중에 준비되어야 하고 사용자가 어떻게 S/W 수정을 요구할지 및 어떻게 문제를 알릴지를 적시하여야. S/W 유지보수 계획은 IEEE 1219 및 ISO/IEC 14764에서 다루며, ISO/IEC 14764는 본 계획에 대한 안내를 제공함.
마지막으로 최고 수준의 단계에서, 유지보수 조직은 업무 계획 활동(경비, 예산, 인적 자원)을 타 조직의 모든 부서에서와 마찬가지로 수행하여야.
4. S/W 형상 관리(Software configuration management)
IEEE 1219에서는 S/W 형상 관리를 유지보수 공정의 핵심 요소로 기술함. S/W 형상 관리 절차는 검증, 확인 및 식별, 권한 설정(authorize), 구현에 요구되는 각 단계에 대한 감사, 그리고 S/W 제품 배포를 규정함.
단순히 수정 요구 또는 문제 보고 추적으로는 충분하지 않아, S/W 제품과 발생된 변경은 반드시 통제되어야 함. 본 통제는 승인된 S/W 형상 관리(SCM; Software Configuration Management) 공정의 구현 및 강제를 통해 이루어짐. SCM의 세부 사항은 S/W 형상 관리 KA에서 다루며, 여기서는 S/W 변경 사항이 제출, 평가, 승인되는 프로세스에 대해 논함. S/W 유지보수에 대한 SCM은 S/W 개발에 대한 SCM과는 달라, 운영 S/W의 작은 변화라도 반드시 통제되어야 함. SCM 공정은 기 마련된 형상 관리 계획 및 운영 절차에 따라 구현되고, 유지보수자는 형상 통제 위원회(CCB; Configuration Control Boards)에 참여하여 다음 배포/버전의 내용을 결정함.
5. S/W 품질(Software Quality)
S/W 유지보수를 통해 품질이 향상될 것이라는 단순한 희망으로는 충분치 않아, 유지보수 공정 지원을 위한 계획이 마련되고 공정이 구현되어야 함. S/W 품질 보증(SQA; Software Quality Assurance), V&V, 검토 및 감사를 위한 활동 및 기법은 원하는 수준의 품질을 달성하기 위한 타 공정과 조화를 이룰 수 있게 선택되어야. 유지보수자가 일시적(instance) 시험 문서 및 시험 결과를 위해 S/W 개발의 공정, 기법 및 인도물을 적용하는 것 역시 추천됨(IEEE14764).
세부 사항은 S/W 품질 KA 참조.

4. 유지보수 기법(Techniques for Maintenance)
4.1. 프로그램 이해(Program Comprehension)
프로그래머는 변경 사항을 구현하기 위해 프로그램 읽기 및 이해에 적지 않은 시간을 보내는데, 코드 브라우저(browsers)는 프로그램 이해를 위한 핵심 도구임. 명료하고 간결한 문서 역시 프로그램 이해에 많은 도움이 됨.
4.2. 재공학(Re-engineering)
재공학은 S/W를 새 형태(form)으로 재구성하기 위한 S/W의 시험(examination) 및 변경(alteration)으로 정의되며, 뒤로 이어지는 새 형태의 구현 역시 포함함. 재공학은 가장 급진적(그리고 비싼)인 변경이지만, 소규모 변경에도 수행되기도. 재공학은 유지보수성 향상이 아니라 노후된 기존(legacy) S/W를 교체하기 위해 종종 사용됨.
4.3. 역공학(Reverse Engineering)
역공학은 S/W의 컴포넌트와 이들간 상호관계 식별 및 또 다른 형태 또는 더 높은 추상 수준에 대한 표현물에 대한 생산을 위한 S/W 분석 공정임. 역공학은 수동적 속성을 지녀, S/W를 변경하거나 새로운 S/W를 만드는 활동이 아님. 역공학은 제품 소스코드의 호출 그래프와 제어 흐름도의 생산에 초점이 맞춰짐. 
역공학의 종류로, 재문서화(redocumentation) 및 설계 복구가 있으며, 리팩토링(refactoring)은 S/W 행동 변경을 배재한 상태에서 프로그램에 대한 재조직화를 통한 변형(transformation)으로, 프로그램 구조 향상을 위한 역공학의 한 형태임. 데이터 역공학은 요 몇 년간 주목을 받아왔는데, 이는 물리 데이터베이스에서 논리 스키마를 복구하는 활동임.

 

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

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

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

Introduction
시험(Test)는 제품 품질 평가, 향상 및 결함/문제 식별을 위해 수행하는 활동.
시험의 구성은 유한(Finite) 개의 테스트케이스을 기반으로 프로그램 행동에 대한 동적(Dynamic) 검증(verification)을 통해 이루어지며, 테스트케이스는 기대되는(Expected) 행동에 대한 무한 실행 영역(infinite executions domain)에서 알맞게 선택(select)됨. 여기서 굵은 글씨는 시험의 핵심 특성을 나타냄.
 ○ 동적(Dynamic) : 시험은 언제나 입력 값에 대한 실행임을 암시. 이에 대비되는 것은 S/W 품질 KA에 기술된 정적(static) 기술
 ○ 유한(Finite) : 단순한 프로그램에서 조차도 이론적으로는 매우 많은 테스트케이스를 만들 수 있어, 극단적으로 하자면 시험에 수개월 또는 수년을 소비할 수도. 따라서 시험은 언제나 제한된 자원과 일정, 무제한 시험 요구사항 간의 trade-off가 있어야.
 ○ 선택(Selected) : 시험집합(test set)을 어떻게 선택하느냐에 따라서 테스트 기술이 나뉘기에, 선택 기준(criteria)을 식별하는 것이 핵심. 가장 적절한 선택 기준 설정이란 복잡한 문제로서, 실전에서는 이를 위해 위험 분석 기술과 시험 공학 기술(test engineering expertise)를 적용함.
 ○ 기대(Expected) : 프로그램 실행 결과에 대한 수용 가능 여부를 판단할 수 있어야. 사용자의 기대(검증을 위한 시험; testing for validation) 또는 명세(검증을 위한 시험; testing for verification), 암시적 요구사항에 기반한 예상된 행동에 비추어 검사되어야 함. S/W 요구사항 KA의 6.4. 인수 테스트와 연계
시험의 목적은 더 이상 단순히 코딩 후 결함 검출(detecting failure)에 머무르지 않고, 개발/유지보수 전 영역에 걸친 제품 구현의 일부로 인지됨. 실제로 시험 계획 및 설계 활동은 S/W 설계자의 잠재적 약점(설계에서의 간과, 모순, 누락 등)을 보완하는데 유용.
품질에 대한 고려는 위험/문제 예방의 한 방법임(문제의 수정보다는 회피가 더 났다는 점에 기반하여)에 비추어 볼 때, 시험은 해당 예방의 유효성 ㅈ을 위한 수단임. 전 영역에 걸친 시험의 성공에도 불구하고 S/W는 결함(fault)를 가질 수 있는데, 배포 이후 발생된 S/W 결함에 대한 해결은 유지보수 활동을 통해 해결함.
S/W 품질 관리 기술은 정적 기법(비 코드 실행)과 동적 기법(코드 실행)으로 나뉘며, 시험은 동적 기법에 중점을 둠(S/W 품질 KA의 3.3. S/W 품질 관리 기법 참조).
S/W 시험은 S/W 작성 KA(3.4. 작성 시험 참조)과도 연계되어, 단위 및 통합 시험은 특히나 그러함.

Breakdown of topic

1. S/W 시험 기본(Software Testing Fundamentals)
1.1. 시험 관련 용어(Testing related Terminology) - IEEE610.12-90
S/W 오류(error) : 인간이 만들어 낸 문법적/논리적 실수로 인한 부분 또는 전체적으로 부정확(incorrect)한 코드 영역.
S/W 결함(Fault, Defect)이란 S/W 실패의 원인이며, S/W 실패(Failure)는 관찰된 원치 않은 결과임. 시험은 실패를 드러내는 반면, 결함은 제거 대상.
1.2. 핵심 이슈(Key Issues)
1. 시험 선택 기준 / 시험 적합 기준(또는 중지 규칙) (Test selection criteria / Test adequacy criteria)
시험 선택 기준은 적합한 테스트케이스를 결정하기 위한 수단임과 동시에, 선택된 테스트 수트가 적합한지 여부를 검사하는 데 사용(즉, 시험이 중지될 수 있는지 여부에 대한 결정)
2. 시험 유효성 / 시험 목적(Testing effectiveness / Objectives for testing)
시험은 프로그램 실행 예에 대한 관찰임. 선택된 동일 시험은 각기 다른 목적으로 사용 가능
3. 결함 식별을 위한 시험(Testing for defect identification)
결함 식별을 위한 시험의 성공 요소는 해당 시험이 시스템을 실패시킬 수 있는지 여부. 이는 S/W가 명세와 타 설계 속성을 S/W가 준수하는지 여부를 보여주기 위한 시험과는 달라, 여기서는 실패가 나타나지 않아야 성공임.
4. 오라클(oracle) 문제
오라클이란 프로그램이 주어진 시험에서 올바르게 동작하는지 여부를 결정하는 (인간 또는 기계적) agent로서, 통과(pass), 실패(fail)이란 용어를 사용. 다양한 종류가 있음.
5. 시험의 이론적/실제적 한계(Theoretical and practical limitations of testing)
통과된 시험에 대한 신뢰성 수준 문제. 시험은 문제를 드러낼 뿐이지 S/W의 완전성을 증명할 수는 없음. 이는 실제 S/W에 대한 완전한 시험이란 불가능하기 때문으로, 시험은 위험에 기반하여 수행되어야 하며, 따라서 위험 관리 전략의 한 방법으로도 볼 수 있음.
6. 실행 불가능 경로 문제(The problem of infeasible paths)
어떤 입력 데이터로도 실행 불가능한 제어 흐름 경로는 경로 기반 시험, 특히 코드 기반 시험 기법에 기반한 자동적 시험에서의 주요 문제임.
7. 시험 가능성(Testability)
S/W 시험 가능성의 뜻은 두 가지. 하나는 주어진 시험 범위 기준에 대한 시험 수행의 용이성이며, 다른 하나는 시험을 통해 S/W 실패를 일으킬 가능성임.
1.3. 시험과 타 활동 간 관계(Relationships of Testing to Other Activities)
S/W 시험은 정적 S/W 품질 관리 기법, 정확성(correctness)의 증명, 디버깅, 프로그래밍에 관련이 있지만 다름. S/W 품질 분석가의 관점으로 바라보는 편이 좋음.

2. 시험 수준(Test Levels)
2.1. 시험 대상(The Target of the Test)
S/W 시험은 개발 및 유지보수 공정 전체의 각기 다른 수준에서 수행되기에 대상 역시 다양해짐(모듈, 모듈 그룹, 전체 시스템 등). 이는 세 개의 대단위 시험 단계, 즉 단위, 통합, 시스템 시험으로 개념적 구분을 이룰 수 있음.
1. 단위 시험(unit testing; IEEE1008-87) : 분리하여 시험 가능한 S/W 조각의 기능을 검증하는 활동. 이는 각각의 부 프로그램 또는 강결합된 단위로 묶인 더 큰 컴포넌트 역시 이에 포함된다는 의미임. 본 시험은 종종 대상 코드에 대해 프로그래머가 디버깅 도구를 사용하여 이룸.
2. 통합 시험(Integration testing) : S/W 컴포넌트간 상호작용을 검증하는 과정. 고전적 통합 시험 전략인 상/하향식 전략은 전통적 계층 구조의 S/W에 적용하는 반면, 현대적 시스템 통합 전략은 아키텍처 주도(Architecture-driven) 방식으로서, 식별된 기능적 분류(functional threads)에 따라 S/W 컴포넌트 또는 부시스템을 통합하는 방식임.
통합 시험은 연속적 활동으로서, 각 단계에서 S/W 기술자는 하위(lower-level)가 아닌 현재 통합하는 수준에 눈높이를 맞춤. 작은 S/W가 아니라면, '빅뱅' 전략보다는 체계적/점증적 통합 시험이 많이 쓰임
3. 시스템 시험(System testing) : 시스템 시험은 전체 시스템의 행동에 관계하여, 주요 기능적 실패는 단위 및 통합 시험에서 이미 식별되어야 함. 본 시험은 주로 보안, 속도, 정확성, 신뢰성 등의 비기능적 요구사항 준수 여부와 외부 모듈(운용 환경, 타 응용프로그램 등)과의 연동을 위한 외부 인터페이스에 대한 검사에 초점을 둠.
2.2. 시험 목적(Objectives of Testing)
시험은 다양한 목적을 갖고 수행되며, 목적이 정확성을 요구할 경우 정량적 수단을 통해 이룸.시험은 여러 속성을 검증(verify)하는 데 목적을 둠. 기능 요구사항의 구현 정확성 검사(conformance/correctness/functional test)를 위해 테스트케이스가 설계되기도 하지만, 비기능 요구사항(성능, 신뢰성, 사용성 등)의 속성 역시 검사 대상임. 시험 목적은 시험 대상에 따라 달라짐.
1. 인수(Acceptance)/자격(qualification) 시험
인수 시험은 고객의 요구사항에 시스템이 부합하는지를 검사. 고객이 본 시험에 해당하는 특정 작업을 지정/수행할 수도. 시험 활동에는 개발자가 결부될 수도 있음.
2. 설치(installation) 시험
보통 인수 시험이 완료된 후 수행되어 대상 환경으로의 설치에 대한 검증(verify)임. H/W 형상 요구사항에 따라 시스템 시험이 한번 더 수행되는 것으로 볼 수도 있어. 설치 절차 역시 검증 대상.
3. 알파(alpha) / 베타(beta) 시험
S/W를 풀기(release) 전에 소규모의 잠재적 사용자 대표 집단에 트라이얼(trial)로 사용케 하는 것으로, 해당 사용자가 내부(in-house) 멤버일 경우 알파, 외부일 경우에는 베타 시험임. 이들 사용자는 사용 후 문제를 보고함. 본 시험은 종종 통제 밖으로 벋어나 시험 계획에 반드시 포함되지는 않음
4. 부합(conformance) / 기능(Functional) / 정확성(Correctness) 시험
S/W가 자신의 명세에 맞게 동작하는지 여부를 검증하는데 목적을 둠.
5. 신뢰도 성취 및 평가(Reliability achievement and evaluation)
결함을 식별하는 수단으로서 시험은 신뢰도 향상을 위한 한 수단임. 반면, 운영 프로파일(operational profile), 신뢰도에 대한 통계적 측정기준을 따라 무작위로 생성한 테스트케이스를 도출할 수도. 신뢰도 증대 모델을 통해 위 두 목적을 동시에 성취 가능함(4.1.4. 생명 시험(Life test), 신뢰도 평가 절 참조)
6. 회귀(regression) 시험
수정이 의도하지 않은 영향을 미치는지 여부를 검증하기 위한 시스템 또는 컴포넌트에 대한 선택적 재시험임(IEEE10.12-90), 실제에서의 본 시험은 이전에 통과한 시험이 여전히 유효한지 여부에 대한 판단.
회귀 시험의 수준과 이에 필요한 자원 간에는 언제나 trade-off가 요구됨.
'2.1. 시험 대상'의 모든 시험 수준에서 수행될 수 있으며, 기능/비기능 요구사항 모두에 적용됨.
7. 성능(performance) 시험
용량 및 반응 시간 등의 지정된 성능 요구사항에 부합하는지 여부에 대한 검증. 내부 프로그램 및 시스템 한계에 대한 시험인 부피 시험(volume testing; 일정량의 데이터를 갖고 성능을 시험)은 성능 시험의 일종.
8. 스트레스(stress) 시험
S/W를 설계 부하(design load)의 최고치 또는 그 이상에서 수행
9. Back-to-back 시험
단일 시험집합을 단일 S/W 제품의 두 버전에 수행하여 그 결과를 비교
10. 복구(recovery) 시험
본 시험의 목적은 재해(disaster) 이후의 S/W 재시작 능력에 대한 검증임
11. 형상(configuration) 시험
S/W가 다양한 사용자를 위해 만들어졌을 경우, 다양한 특정 형상에서의 S/W 수행 능력을 분석함.
12. 사용성(usability) 시험
S/W 및 해당 문서에 대해, 최종 사용자의 사용/학습이 얼마나 용이한지 여부를 평가. 또한 S/W의 기능이 사용자 작업에 대한 지원에 얼마나 유효한지 여부와 사용자의 오류에 대한 복구 능력 역시 평가 대상
13. 시험 주도 개발(TDD; Test-driven development)
TDD 그 자체로는 시험 기법은 아니지만, 시험을 요구사항 명세 문서의 대용으로 하여 S/W가 요구사항을 정확히 구현하는지 여부를 검증하는 수단으로 사용.


3. 시험 기법(Test Techniques)
시험의 목적 중 하나는 잠재적 실패(failure)를 최대한 많이 발견함에 있어, 많은 기법이 이를 위해 개발됨. 이러한 기법의 기반 원칙은 프로그램 행동의 대표적 집합 식별을 최대한 조직적(systematic)으로 이루는 것이나, 모든 기법을 분류할 공통된 기반은 찾기 어려움.
S/W 설계 및 코드가 어떻게 이루어졌는지에 대한 정보에 의존하는 시험을 가리켜 White-box(또는 glassbox) 시험이라 부르는 반면, 입/출력 행동에 기반할 경우에는 Black-box 시험이라 칭함.
3.1. 시험자의 직관 및 경험 기반(Based on Tester's Intuition and Experience)
1. 임의(Ad hoc) 시험
S/W 기술자의 기술, 직관 및 경험에 따라 임의로 시험을 수행. 가장 넓게 사용되는 기법
정형적 기법으로는 포착하기 어려운 특정 시험에 유용
2. 탐험적(Exploratory) 시험
동시적 습득, 시험 설계, 시험 수행으로 정의되는 본 시험은, 시험이 시험 계획에 따라 먼저 정의되기 보다는 동적으로 설계, 수행, 수정됨을 뜻함.
본 시험의 효과는 S/W 기술자의 지식에 좌우되며, 본 지식은 다양한 소스 즉, 시험 중에 관찰된 제품 행동, 응용프로그램에 대한 친숙도, 실패 과정, 가능한 결함 및 실패 유형, 특정 제품에 연계된 위험 등에서 추출됨.
3.2. 명세 기반(Specification-based)
1. 동등 분할(Equivalence partitioning)
입력 영역(domain)이 특정 관계에 따라 동등한 부집단으로 나뉘어 각 부집단에 대해 시험을 이룸
2. 경계값 분석(Boundary-value analysis)
변수의 입력 영역에 대한 경계 부근에 테스트케이스 지정. 본 시험은 많은 결함이 입력의 극한 값 주위에 집중되는 경향이 있다는 기반 원리를 따름.  본 기법의 확장으로 강건성(robustness) 시험이 있는데, 이는 변수의 입력 영역 바깥에서 테스트케이스를 선택하여 예상하지 못하거나 잘못된 입력에 대해 프로그램의 강건성을 검사함.
3. 결정표(Decision table)
결정표란 조건(입력)과 이에 따른 활동(출력) 간 논리적 연관성을 나타냄. 테스트케이스는 조건과 활동에 대한 모든 가능한 조합을 고려하여 추출. 이에 관계된 기법으로 원인-결과 그래프(cause-effect graph)가 있음.
4. 유한상태 기계 기반(Finite-state machine-based)
프로그램을 유한 상태 기계로 모델링하여, 이에 대한 상태와 변이를 다루기 위해 테스트가 선택됨.
5. 정형 명세 기반 시험(Testing from formal specifications)
정형 언어 기반의 명세에서는 기능 테스트케이스를 자동 도출 가능케 하고, 시험 결과를 검사(check)하기 위한 참조 출력/오라클을 제공. 모델 기반 또는 대수적(algebraic) 명세로부터 테스트케이스를 추출하기 위한 방법이 따로 존재함.
6. 임의 시험(Random testing)
시험이 순수하게 임의적으로 생성되어, '3.5.1. 운영 프로파일'의 그것으로 이루어지는 통계적 시험과는 다름. 그럼에도 불구하고 본 시험은 명세 기반으로 분류되는데, 이는 임의의 값 선택 시 최소한 입력 영역 내에서 이루어지기 때문.
3.3. 코드 기반(Code-based)
1. 제어 흐름 기반 기준(Control-flow-based criteria)
프로그램 내 모든 문장과 문장 블록 또는 이들간 특정 조합을 다루는(covering) 데 목적을 두어, 조건/결정 커버리지 등의 여러 커버러지(coverage) 기준이 제안됨. 
가장 강력한 제어 흐름 기반 기준은 경로(path) 시험으로서, 흐름도(flowgraph)의 모든 입구-출구 제어 흐름 경로를 실행함. 본 시험은 일반적으로 현실적이지 않기에(loop로 인해), 문장/분기/조건/결정 시험과 같은 덜 엄격한 시험이 사용되는 경향이 있음.
이러한 시험은 %로 측정됨(ex. 모든 분기가 한번이라도 시험에 의해 수행되면 100% 분기 커버리지가 성취(achieve)되었다고 표현함)
2. 데이터 흐름 기반 기준(Data flow-based criteria)
데이터 흐름 기반 시험에서, 조건 흐름도(control flowgraph)에는 어떻게 프로그램 변수가 정의, 비정의, 사용되었는지가 표기됨. 가장 강력한 기준인 전 정의-사용(all definition-use) 경로의 경우, 모든 변수에 대해 정의부터 사용까지의 전 segment가 실행됨. 요구되는 경로의 수를 줄이기 위해 상대적으로 약한 전략인 전-정의(all-definitions) 또는 전-사용(all-use) 경로가 사용됨.
3. 코드 기반 시험 참조 모델(Reference models for code-based testing) - 흐름도(flowgraph), 호출도(call graph)
코드 기반 기법에서는 프로그램의 제어 구조가 도식화(graphical)되어 표현됨. 흐름도는 직접도(directed graph)로서, 노드와 아크(arc)는 프로그램의 요소에 대응함. 예를 들어, 노드는 문장 또는 한 흐름의 문장(uninterrupted sequences of statement)을, 아크는 노드간 제어의 전이(transfer)를 나타낼 수 있음.
3.4. 결함 기반(Fault-based)
정형화의 각기 다른 수준에서 결함 기반 시험 기법은 가능한 또는 기정의된 결함을 드러낼 목적으로 테스트케이스를 고안함.
1. 오류 추측(Error guessing)
오류 추측 기법에서의 테스트케이스는 S/W 기술자에 의해 특별히 설계되어, 프로그램 내에 가장 그럴듯한(? Plausible) 오류를 이해하기 위해 사용됨. 이를 위한 가장 쓸만한 정보는 이전 프로젝트에서 발견된 결함 이력과 S/W 기술자의 전문 기술(expertise)임.
2. 변이 시험(Mutation testing)
변이(mutant)는 시험 내에서의 (구문 변화를 통한) 아주 작은 수정 버전으로, 모든 테스트케이스는 원 버전과 모든 변이 버전 모두에 수행됨; 만약 테스트케이스가 프로그램과 변이와의 차이를 성공적으로 식별하면, 해당 변이는 '죽었음(killed)'이라 함. 변이 시험은 원래 테스트 집합(4.2 참조)을 평가하기 위한 기법이지만 그 자체로도 시험 기준이 되는데, 이는 충분한 수의 변이가 죽을 때까지 테스트를 임의적으로 생성/수행하거나, 살아있는 변이를 죽이기 위해 특별히 설계함으로 이룸. 변이 시험의 기반 가정인 결합 효과(coupling effect)란 단순 구문적 결함을 찾음으로써 실재의 좀더 복잡한 결함을 찾는 것임. 본 기법을 좀더 효과적으로 수행하기 위해서는 시스템적인 방법으로 많은 수의 변이를 자동 생성해야.
3.5. 사용 기반(Usage-based)
1. 운영 프로파일(Operational profile)
신뢰성 평가를 시험을 위해 시험환경은 S/W의 운영 환경에 최대한 가까워야. 핵심은 관찰한 시험 결과를 통해 실제 사용되는 시기에서의 신뢰성을 추론하는 것임. 이를 위해 입력으로는 확률적으로 분산되거나 실제 운영 시의 발생 가능한 값이 할당되어야.
2. S/W 신뢰성 공학적 시험(SRET; Software Reliability Engineered Testing)
SRET는 전체 개발 공정을 둘러싸는 시험 기법으로, 여기서 시험은 '신뢰도 목표, 기대되는 상대적 사용 및 현장에서의 각기 다른 기능의 임계(criticality)를 기반으로 설계 및 안내'됨.
3.6. 응용 프로그램의 본성 기반(Based on Nature of Application)
상기 기법은 모든 종류의 S/W에 적용되는 반면, 어떤 응용프로그램은 시험 도출에 추가적 노하우를 요구하기도. 아래 나열된 시험은 응용프로그램의 본성에 기반한 특화된 시험임.
 ○ 개체 지향 시험(Object-oriented testing)
 ○ 컴포넌트 기반 시험(Component-based testing)
 ○ 웹 기반 시험(Web-based testing)
 ○ GUI 시험(GUI testing)
 ○ 동시적 프로그램 시험(Testing of concurrent programs)
 ○ 프로토콜 적합 시험(Protocol conformance testing)
 ○ 실시간 시스템 시험(Testing of real-time systems)
 ○ 안전-중대 시스템 시험(Testing of safety-critical systems)
3.7. 기법 선택 및 조합(Selecting and Combining Techniques)
1. 기능 및 구조(Functional and structural)
명세 기반 및 코드 기반 시험 기법은 종종 기능 vs 구조 시험으로 대비되지만, 이들 두 접근법은 상호간에 대안적이라기보다는 상보적인 관계에 있음. 실제로 이들은 각기 다른 소스의 정보를 사용하고 각기 다른 문제에 집중하므로 조합해서 사용될 수 있음.
2. 결정적 vs 임의적(Deterministic vs random)
테스트케이스는 기 정의된 다양한 기법 또는 분산된 입력에서 추출된 값(신뢰성 시험 등에서 사용)을 따르는 결정적 방법으로 선택될 수 있는 반면, 여러 분석적/경험적 비교의 경우, 더 효과적인 접근법을 이루는 조건의 분석을 위해 수행됨.


4. 시험 관련 측정기준(Test related measures)
종종 시험 기법과 목적을 혼동하는 경우가 있는데, 시험 '기법'은 시험 목적 성취를 위한 조력자임. 예를 들어 분기 커버러지는 '기법'으로, 특정 분기 커버리지 측정기준이 시험 자체의 목적으로 받아들여져서는 안됨. 명시적으로 구분되어야 할 것은 관찰된 시험 결과를 기반으로 프로그램 평가를 가능케 하는 시험 관련 측정기준과, 시험 집합에 대한 완전성을 평가하는 것임. 관련 토픽은 SWE 관리 KA의 부영역인 6-SWE 측정기준과 SWE 공정 KA의 부영역인 4-공정 및 제품 측정기준.
4.1. 시험 하의 프로그램 평가(Evaluation of the Program Under Test)
1. 시험 계획과 설계를 위한 프로그램 측정(Program measurements to aid in planning and designing testing)
프로그램 크기, 구조에 기반한 측정기준은 시험 안내를 위해 사용됨. 또한 구조적 측정기준은 프로그램 모듈 간 측정기준(모듈간 호출 회수를 통한)을 포함함.
2. 결함 유형, 분류, 통계(Fault types, classification, and statistics)
어떤 유형의 결함이 시험 중 발견되는지 및 이전에 발생했던 결함에 비한 상대적 회수를 아는 것이 중요하여, 이를 통해 품질 예측 및 공정 향상(process improvement)를 이룰 수 있음. S/W 품질 KA의 3.2 결함 특성화 참조.
3. 결함 밀도(density)
유형 기반의 결함 분류 및 회수 측정을 통해 시험 중의 프로그램을 평가할 수 있어. 각각의 결함 군에 대해, 발견된 결함 개수 및 프로그램의 크기 간 결함 밀도는 비율(ratio)로 측정됨.
4. 생명 시험(Life test), 신뢰도 평가
신뢰도 성취 및 평가(2.2.5)를 통한 S/W 신뢰도의 통계적 측정기준은 제품 및 시험의 중지 여부에 대한 평가에 사용 가능.
5. 신뢰도 성장 모형(Reliability growth models)
신뢰도 성장 모형은 신뢰도 성취 및 평가(2.2.5)하에 관찰한 실패에 기반하여 신뢰도 예측을 가능케 함. 일반적으로 본 모형은 결함이 고쳐졌음(fix)을 가정하는데, 따라서 보통 제품의 신뢰도는 증가하는 경향을 보임. 본 모형 종류는 실패 회수(failure-count) 모형과 실패 간 시간(time-between-failure) 모형이 있음.
4.2. 수행된 시험의 평가(Evaluation of the Tests Performed)
1. 커버리지/완전도(thoroughness) 측정
여러 시험 적합성 기준은 테스트케이스가 프로그램 또는 명세에서 식별된 요소 집합을 시스템적으로 수행해야 함을 요구함. 실행된 시험의 완전성을 평가하기 위해 시험자는 전체 요소에 대한 다뤄진 요소 비율을 동적으로 측정함으로 다뤄진(coverage) 요소를 감시(monitor)할 수 있음. 프로그램 흐름도 내의 다뤄진 분기에 대한 비율을 측정하거나, 명세 문서에 나열된 기능 요구사항 비율에 대한 측정기준은 이에 대한 한 예. 코드 기반 적합성 기준은 시험 중의 프로그램에 대한 적절한 도구(instrumentation)을 요구.
2. 결함 뿌리기(seeding)
일부 결함은 시험 전에 인위적으로 삽입되기도. 이를 통해 시험이 수행될 때 삽입된 이들 결함 뿐 아니라 이미 있었던 결함 역시 발견될 수 있음. 이론적으로 어느, 그리고 얼마나 많이 인위적 결함이 발견되었는지에 따라서, 시험 유효성이 평가되고 남겨진 순수 결함이 추정될 수 있음. 여기서 중요한 것은 결함이 분산되어 뿌려지고 대표성을 지녀야 한다는 것. 또한 결함이 후에 남겨져 위험을 유발할 수 있으므로 조심스럽게 본 기법을 사용해야 한다는 점임.
3. 변이 점수(Mutation score)
변이 시험에서 생성된 변이에 대한 죽은 변이의 비율은 수행된 시험 집합의 효과성 측정에 이용됨.
4. 기법간 비교 및 상대적 효과
여러 문건에서 시험 기법 간 상대적 효과성을 비교하는데, 여기서 중요한 것은 평가 속성에 대해 정확히 인식해야 한다는 것. 예를 들어 '효과성'의 정확한 의미는, 첫 실패를 발견하기까지의 수행된 시험 회수, 시험을 통해 발견된 결함 개수, 신뢰도 향상 정도 로 해석될 수 있음. 분석 및 경험적 기법 비교는 위 효과성 기준에 따라 이루어짐.


5. 시험 공정(Test Process)
시험 개념, 전략, 기법, 측정기준은 기 정의/제어된, 인간에 의해 수행되는 공정으로 통합될 필요가 있음. 또한 시험 공정은 시험 활동을 지원하고, 시험 팀에게 시험 전 과정에 대해 비용 효과적인 목적 달성 가능하도록 안내하는 역할을 함.
5.1. 실제적 고려사항(Practical Considerations)
1. 태도/비이기적 프로그래밍(attitudes and egoless programming)
시험을 성공적으로 이끄는 매우 중요한 요소는 협력적 태도임. 관리자에게는 개발/유지보수 중의 실패 발견에 대해 우호적인 분위기를 만들 임무가 있음. 코드에 대한 소유 개념을 갖지 않도록 하여, 그들의 코드로 인한 실패의 책임감을 느끼지 않도록 하는 것은 한 예.
2. 시험 안내(Test guides)
다양한 목적에서 시험 공정이 안내될 수 있음. 예를 들어 위험 기반 시험의 경우, 시험 전략의 우선순위화 및 집중화를 위해 제품 위험이 이용되고, 시나리오 기반 시험에서는 테스트 케이스가 특정 S/W 시나리오에 기반하여 정의됨.
3. 시험 공정 관리(Test process management)
각기 다른 수준의 시험 활동은 생명주기의 주요 일부가 되는 잘 정의된 프로세스로 구성해야(사람, 도구, 정책, 측정기준과 함께). IEEE12207에서 시험은 독립적 프로세스로 기술되지는 않지만 시험 활동에 대한 원칙은 타 주요 생명주기 및 지원 프로세스에 포함됨. IEEE 1074에서 시험은 전체 생명 주기의 핵심으로서 타 평가 활동과 함께 묶임.
4. 시험 문서화 및 작업 제품(work products)
문서화는 시험 공정 정형화의 핵심 부분으로, IEEE829-98은 시험 문서와 문서 간 또는 시험 공정 간 관계를 기술. 시험 문서는 시험 계획, 시험 설계 명세, 시험 절차(procedure) 명세, 테스트케이스 명세, 시험 로그, 시험 사건 및 문제 보고를 포함. 시험 하의 S/W는 시험 항목으로서 문서화되어야 하며, SWE의 타 문서와 동일한 수준의 품질로 지속적으로 갱신되어야.
5. 내부 vs 독립적 시험 팀(Internal vs independent test team)
시험 공정의 정형화는 시험 팀 조직의 정형화를 수반함. 시험 팀은 프로젝트 팀의 내부 멤버, 외부 멤버 모두가 될 수 있어. 비용, 일정, 조직의 성숙도 수준, 응용프로그램의 중대성이 (멤버 결정에 대한) 결정의 고려 요소.
6. 비용/노력 추정 및 타 공정 측정(Cost/effort estimation and other process measures)
시험이 요구하는 자원에 관계된 여러 측정 요소 및 다양한 시험 단계(test phase)의 상대적 결함 발견 효과성이 시험 공정의 제어 및 향상을 위해 사용될 수 있어. 이들 시험의 측정기준은 지정된/수행된/통과한/실패한 테스트케이스의 개수와 같은 면을 다룰 수 있어. 시험 단계 보고서 평가는 근원 분석과 결합하여 결함 발견에 대한 시험 공정의 효과성을 초기에 평가할 수 있으며, 이러한 평가는 위험 분석과 연계됨 게다가 시험에 사용할만한 자원은 응용프로그램의 사용/중대성과 비례하여야. 각기 다른 기법은 각기 다른 비용을 요구하고 제품 신뢰성의 각기 다른 수준을 만들어냄.
7. 종료(Termination)
완료된 코드 커버리지나 기능적 완전성, 예상 결함 밀도, 운영 신뢰도와 같은 완전성(Thoroughness) 측정기준은 유용하기는 하지만 충분하지는 않음. 종료 결정은 잠재적 실패로 인한 비용과 위험에 대한 고려를 요구함. 1.2.1 시험 선택 기준 및 시험 적합성 기준 참조.
8. 시험 재사용 및 시험 패턴(Test reuse and test patterns)
조직적이고 비용 효과적인 방법으로 시험 또는 유지보수를 수행하기 위해, 각종 시험 수단은 시스템적으로 재사용되어야. 이러한 시험 문건의 저장소는 S/W 형상 관리의 통제하에 있어야 S/W 요구사항/설계의 변경이 시험의 영역에 반영될 수 있음. 
특정 환경 하의 특정 응용프로그램 유형을 시험하기 위한 시험 솔루션이 도입되는데, 여기에는 비슷한 프로젝트에서 재사용하기 위해 문서화를 이루는 시험 패턴을 형성.
5.2. 시험 활동(Test Activities)
시험 활동에 대한 성공적 관리는 S/W 형상 관리 프로세스에 달림.
1. 계획(Planning)
타 프로젝트 관리 측면과 마찬가지로 시험 활동 역시 계획되어야. 시험 계획의 주요 측면에는 인력 배치, 시험 도구 관리, 원치 않은 결과에 대한 계획이 포함됨. 하나 이상의 S/W 기준선이 설정될 경우 주요 계획 고려 사항으로, 시험 환경이 적절한 구성을 이루는지를 검증하기 위한 시간과 노력임.
2. 테스트케이스 생성(Test-case generation)
테스트케이스의 생성은 수행될 시험 수준 및 특정 시험 기법에 기반함. 테스트케이스는 S/W 형상 관리의 통제하에 있어야 하며 각 시험에 대한 기대 결과를 포함하여야.
3. 시험 환경 개발(Test environment development)
시험 환경은 SWE 도구와 호환성을 이루어야. 이는 테스트케이스를 개발 및 제어할 뿐 아니라 로깅 및 기대 결과, 스크립트 및 타 시험관련 자료를 복구 가능하여야.
4. 실행(Execution)
시험 수행에는 과학적 실험의 기본 원칙을 지켜야. 시험 중의 모든 것들은 타인이 해당 결과를 재현 가능하기에 충분하도록 수행 및 문서화되어야. 따라서 시험은 명확히 정의된 버전을 사용한 문서화된 절차에 따라 수행되어야.
5. 시험 결과 평가(Test results evaluation)
시험 결과는 해당 시험이 성공적인지 여부를 판별할 수 있도록 평가되어야. 대부분의 경우에서 '성공적'이란 S/W가 의도한 대로 수행되고 무시할 수 없는 예기지 않은 결과(major unexpected outcomes)도 보이지 않음을 뜻함. 모든 예기치 않은 결과가 반드시 결함인 것은 아니어 단순 잡음으로 판명할 수도. 실패를 제거에는 격리,식별,기술을 통한 분석과 디버깅 노력이 요구됨. 시험결과가 특히 중요할 경우 정형 검토 위원회(formal review board)가 소집되어 이를 평가할 수도.
6. 문제 보고/시험 로그(Problem reporting/Test log)
시험 활동은 시험 수행 시기, 시험 수행 주체, 시험 때의 S/W 형상 형태를 식별하기 위해 테스트 로그로 남겨질 수도. 예기지 않은/부정확한 시험 결과는 문제 보고 시스템에 기록되고, 해당 데이터는 이후 디버깅 및 문제 해결을 위한 기반을 이룸. 또한 결함으로 분류되지 않은 비정상 요소(anomaly) 역시 이후를 위해 문서화될 수도. 시험 보고서는 변경 관리 요구 공정의 입력 요소임(S/W 형상 관리 KA, 3 S/W 형상 통제 참조).
7. 결함 추적(Defect tracking)
실패를 통해 얻은 결함은 해당 S/W에 언제 발생했는지, 어떤 오류(error)가 결함을 야기했는지(미약하게 정의된 요구사항, 부정확한 변수 선언, 메모리 누수, 프로그래밍 구문 오류 등), 언제 처음 발견되었는지를 결정하기 위한 분석 소스가 됨. 결함 추적 정보는 SWE의 어떤 측면이 향상되어야 하고 얼마나 이전 분석과 시험이 효과적이었는지를 결정하기 위해 사용.

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

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

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

Introduction
S/W 작성이란 용어는 코딩, 검증, 단위/통합 시험 및 디버깅의 조합을 통해 동작 가능하고 의미 있는 S/W를 뜻함.
모든 KA와 연계되지만 가장 관련 있는 KA는 설계와 시험으로, 작성은 설계의 출력임과 동시에 시험의 입력임.
작성에 앞서 세부 설계가 이루어지지만 많은 설계 작업이 작업 활동 자체에서 이루어짐
작성 전체에 걸쳐 단위/통합 시험이 이루어짐
S/W 작성은 보통 다수의 관리가 필요한 구성 항목(소스 파일, 컨텐츠, 테스트케이스 등)을 만들어냄. 그러므로 S/W 구성 KA 역시 S/W 작성 KA와 연계됨
S/W 작성은 도구와 방법에 크게 종속되어 가장 도구에 집중되는 KA이므로 SWE 도구 및 방법 KA와도 연계
모든 KA에서 S/W 품질이 중요함과 동시에 코드는 S/W 프로젝트의 최종 전달물이므로 S/W 품질도 연계
SWE의 관련 규율(discipline) 중 S/W 작성 KA는 알고리즘과 세부 코딩 작업이란 컴퓨터 과학 영역의 것에 관계됨. 또한 프로젝트 관리하고도 연계됨.

Breakdown of topics

1. S/W 작성 기본(Software Construction Fundamentals)
S/W 작성 기본에는 아래 나열된 목록이 포함되어, 첫 3개 개념은 작성 뿐 아니라 설계에도 적용됨.
1.1. 복잡도 최소화(Minimizing Complexity)
인간의 의도를 컴퓨터에 옮기기는 인간의 제한된 능력인 기억력에 의존함. 이로 인해 S/W 작성의 가장 큰 동력은 복잡도의 최소화에 있음. 복잡도를 줄이는 것은 S/W 작성에 대한 검증과 시험 프로세스에 특히나 중요.
S/W 작성에서 복잡도를 줄인다는 것은 코드를 단순하고 읽기 쉽게 작성한다는 것임(not clever but simple, readable).
또한 1.4 작성 표준에서 논의하는 표준을 사용하고 '3.3 코딩'에서 요약하는 많은 기법을 사용하는 것 역시 복잡도를 줄이는 방법임. '3.5 작성 품질'의 작성-집중(construction-focused) 품질 기법 또한 복잡도를 줄이는 방법임.
1.2. 변화 예상(Anticipating Change)
S/W는 변하기 마련이며 변화의 예상은 S/W 작성의 많은 면에 영향을 줌. S/W는 외부 환경 변화를 피할 수 없음. 변화 예상은 3.3. 코딩 토픽의 많은 기법을 통해 이룸.
1.3. 검증 가능 작성(Constructing for Verification)
검증 가능 작성이란 S/W를 만들 때 S/W 구현, 시험 및 운영 중에 결함을 미리 발견 가능하도록 구현함을 뜻함. 구현 가능 작성을 가능케 하는 기법은 코드 검토, 단위 시험, 시험 자동화를 지원하는 코드 구성, 복잡 요소 제한 및 난해한 언어 구조 제한을 지원함.
1.4. 작성에서의 표준(Standards in Construction)
작성 이슈에 직접적 영향을 미치는 표준으로,
 ○ 의사소통 방법(ex. 문서 형식 및 내용에 대한 표준)
 ○ 프로그래밍 언어(ex. Java나 C++과 같은 언어 표준)
 ○ 플랫폼(ex. OS 호출을 위한 API 표준)
 ○ 도구(ex. UML과 같은 도식적 표기를 위한 표준)이 있음.
외부 표준 사용 : 작성은 작성 언어, 작성 도구, 기술적 인터페이스 및 S/W 작성과 타 KA 간 상호작용을 위한 타 표준의 사용에 영향을 받음. 표준에는 IEEE나 ISO와 같은 국제 조직이나 H/W, S/W 인터페이스 명세를 다루는 OMG이 있음.
내부 표준 사용 : 표준은 조직 협력 수준에서의 조직 기반이나 특정 프로젝트에서 사용하기 위해 생성됨. 이들 표준은 그룹 활동 조정, 복잡도 감소, 변화 예상, 검증 가능 작성을 지원.

2. 작성 관리(Managing Construction)
2.1. 작성 모형(Construction Models)
S/W 개발을 위한 다양한 모형이 있는데, 이들 중 몇몇은 타 모형에 비해 작성을 좀더 강조함.
폭포수나 단계적 인수 생명주기 모형 등의 몇몇 모형은 작성 관점으로 보았을 때 좀더 선형적이며, 이들에서의 작성 단계는 주루 코딩을 강조함.
진화적 프로토타이핑, XP, 스크럼 등의 좀더 반복적 모델에서는 작성이 요구사항이나 설계, 계획과 병행하여 이루어지거나 중복되기도. 이들 접근법에서는 설계, 코딩 및 시험 활동이 섞여, 각 활동의 조합을 작성으로 다룸.
결론적으로 '작성'이란 각 생명주기 모형에 따라 달라짐.
2.2. 작성 계획(Construction Planning)
작성 방법의 선택은 계획 활동의 핵심으로, 본 선택은 작성 선결조건의 수행 여부 범위까지 영향을 미침. 작성 접근법은 복잡도 감소, 변화 예상, 검증을 위한 작성을 위한 프로젝트의 능력에 영향을 미치며, 이들 각각의 목표는 요구사항 및 설계단계 프로세스에서도 중요시 되는데, 이들 프로세스 역시 작성 기법 선택의 영향을 받음.
작성 계획은 선택한 방법에 따라 컴포넌트의 생성 및 통합 순서, S/W 품질 관리 공정, 작업 할당 및 타 작업을 정의
2.3. 작성 측정기준(Construction Measurement)
수많은 작성 활동 및 산출물, 즉 코드 개발, 수정, 재사용, 파기, 코드 복잡도, 코드 인스펙션 통계, 결함-수정/결함-발견 비율, 노력, 일정 등 모두 측정 대상임. 이들 측정물은 작성 관리, 작성 중 품질 검증, 작성 공정 향상 등 다양한 부분에서 유용함. SWE 공정 KA 참조.


3. 실제적 고려사항(Practical Considerations)
작성은 임의적이고 혼돈적인 실세계의 제한조건을 받아들이고 정확히 실행해야 하는 활동임. 실세계의 제한조건에 근접하기 위해 작성은 타 KA보다 실제적 고려사항의 영향을 더 많이 받으며, 본 영역에서 SWE는 가장 공예적(craft-like)이게 됨.
3.1. 작성 설계(Construction design)
몇몇 프로젝트에서는 작성에 설계 활동이 이루어지는데, 이는 실세계의 문제가 야기하는 변경 불가능한 제한조건에 기인함. 물리적 구조를 만드는 작성자(construction worker)가 소규모 수정을 통해 기존 계획에서 발생한 예상치 못한 차이(gap)를 메우는 데 적응해야 하는 듯이, S/W 작성자 역시 수정을 통해 S/W 설계의 세부 사항에 살을 붙여야 함.
작성 단계에서의 설계 세부 활동은 S/W 설계 KA의 그것과 본질적으로 동일하지만, 좀더 작은 규모에 적용된다는 점이 다름.
3.2. 작성 언어(Construction Languages)
작성 언어는 인간이 컴퓨터에 실행 가능한 문제 해결책을 지정 가능한 모든 형태의 의사소통을 포함함. 가장 단순한 작성 언어는 구성(configuration) 언어, 즉 기 정의된 일정의 옵션을 통해 새 S/W 설치를 가능케 하는 언어임. Windows와 Unix의 텍스트 기반 구성 파일이나 메뉴 스타일은 이에 대한 한 예임
툴킷(toolkit; 응용프로그램에 특화된 재사용부의 통합 집합(integrated set)) 언어 역시 구성 언어보다는 복잡하지만 작성 언어로서, 스크립트(script)가 여기에 포함됨.
프로그래밍 언어는 가장 유연한 형태의 작성 언어로, 특정 응용 영역 및 개발 프로세스에 대한 최소한의 정보만을 지니기에 효과적인 사용을 위해 훈련과 기술(skill)을 요구함. 본 언어에 사용되는 일반적 표기법은 다음과 같이 세 가지로 분류됨.
 ○ 언어적(linguistic)
 ○ 정형적(formal)
 ○ 시각적(visual)
언어적 표기법은 복잡한 S/W 작성을 표현하는 데 텍스트의 단어적 열(word-like string)과 이들의 조합인 문장적 구문(sentence-like syntax) 패턴을 사용하며, 적절히 사용될 경우 직관적인 이해를 가능케 하는 강력한 의미론적 함축을 가능케 함. 
정형적 표기법은 덜 직관적이지만 각 단어와 텍스트 문자열에 정확하고, 명확하며, 정형적(또는 수학적)인 정의가 담김. 정형 작성 표기법과 정형 기법(formal method)은 시스템 프로그래밍, 즉 정확성, 시간 행동(time behavior), 시험용이성(testability)이 중요시되는 영역의 핵심임. 정형 작성은 또한 정확히 정의된 방법, 즉 많은 자연어 기반 작성이 보이는 모호함을 제거하기 위한 조합 심볼을 사용.
시각적 표기법은 직접적이고 시각적 해석 및 S/W의 하부요소를 나타내는 시각적 요소(entity)의 배치에 사용. 시각적 요소의 이동 기반한 본 표기법은 복잡한 문장 구성에는 적합하지 않지만, 프로그램의 시각적 인터페이스에 대한 제작(build) 및 조정(adjust)과 일찍이 정의된 세부 행동에 대한 프로그래밍이 주를 이룰 경우 유용함.
3.3. 코딩(Coding)
다음과 같은 사항이 S/W 작성의 코딩 활동에 적용됨
- 이해 용이한 소스 코드의 생산 기법. 여기에는 네이밍(naming)과 소스 코드 배치(layout)이 포함
- 클래스, 열거형, 변수, 명명된 상수 및 이들과 유사한 요소(entity)
- 제어 구조의 사용
- 오류 조건 처리 - 계획된 오류 및 예외 포함
- 코드 수준의 보안 허점 방지
- 배제(exclusion) 메커니즘을 통한 자원 사용 및 직렬적 자원(쓰래드, DB lock 등) 접근 원칙
- 소스 코드 구성(organization; 문장, 루틴, 클래스, 패키지 등에 대한)
- 코드 문서화
- 코드 튜닝(tuning)
3.4. 작성 시험(Construction Testing)
작성 시에는 S/W 기술자에 의해 단위 및 통합 시험이 수행됨. 작성 시험의 목적은 코드에 결함이 삽입된 시간과 결함이 발견된 시간의 차이를 줄이는 데 있음. 작성 시험은 코드가 작성된 후 수행되기도 하며 코드 작성 전에 테스트케이스가 만들어지기도 함.
Construction testing typically involves a subset of types of testing, which are described in the Software Testing KA. For instance, construction testing does not typically include system testing, alpha testing, beta testing, stress testing, configuration testing, usability testing, or other, more specialized kinds of testing.
두 가지 표준이 있음. 하나는 IEEE 829-1998, IEEE Standard for Software Test Documentation이고, 다른 하나는 1008-1987, IEEE Standard for Software Unit Testing임. 본 시험에 상응하는 S/W 시험 KA는 2.1.1 단위 시험 및 2.1.2 통합 시험임.
3.5. 재사용(Reuse)
IEEE1517-99에서는 "S/W 재사용은 라이브러리(libraries of assets)의 생성과 사용 이상을 요구한다. S/W 재사용은 재사용 프로세스 및 활동을 S/W 생명주기에 통합하는 정형적 활동을 요구한다."라고 논함. 하지만 재사용은 S/W 작성에 매우 중요하므로 본 장에 포함.
S/W 작성에서 코딩과 시험 중 재사용이 관계되는 작업으로는
 ○ 재사용 단위, 데이터베이스, 시험 절차 또는 시험 데이터의 선택
 ○ 코드 또는 시험 재사용성의 평가
 ○ 새 코드, 시험 절차 또는 시험 데이터에 대한 재사용 정보에 대한 보고가 있음.
3.6. 작성 품질(Construction Quality)
코드 품질을 검증할 수많은 기법이 있는데, 작성에서 사용되는 주요 기법으로는,
 ○ 단위 시험 및 통합 시험(3.4. 작성 시험에서 논의됨)
 ○ 시험 선도 개발(Test-first development; S/W 시험 KA의 2.2 시험 목적 참조)
 ○ 코드 단계화(Code stepping)
 ○ 단언문(assert) 사용
 ○ 디버깅
 ○ 기술 검토(Technical reviews; S/W 품질 KA의 3.3 기술 검토 참조)
 ○ 정적 분석(Static analysis; IEEE1028. S/W 품질 KA의 3.3. 검토 및 감사 참조) 이 있음.
기법은 S/W의 본성과 S/W 기술자의 스킬에 따라 선택됨. 
작성 품질 활동은 코드 및 소규모 설계 등의 코드에 밀접히 관련된 산출물에 집중됨.
3.7. 통합(Integration)
작성 중 핵심 활동 중 하나로 각기 나뉜 루틴, 클래스, 컴포넌트, 하위 시스템을 통합하는 것임. 또한 어떤 S/W 시스템은 타 S/W 또는 H/W 시스템과 통합되어야 하기도 함. 통합에 관련한 사항으로, 통합 대상 컴포넌트의 순서화, 임시 버전을 지원하기 위한 비계(scaffold) 생성, 통합 전의 컴포넌트에 대한 시험 및 품질 작업의 수준 결정, 임시 버전에 대한 시험 시점 결정이 있음.

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

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

Introduction
IEEE 610.12-90에 의하면, '설계'란 아키텍처, 컴포넌트, 인터페이스 및 시스템 또는 컴포넌트의 기타 특성을 정의하는 과정과 해당 과정의 결과임. 프로세스 관점에서 보면, S/W 설계는 작성(construction)의 기반이 되는 S/W 내부 구조에 대한 기술을 얻기 위해 요구사항을 분석하는 SWE 생명주기 활동임. S/W 설계는 컴포넌트로 분해되고 조직화된 방법을 기술한 S/W 아키텍처와 이들 컴포넌트간의 interface를 기술하며, 이는 실제 작성이 가능한 수준의 세밀도로 표현되어야 함.
솔루션에 대한 청사진의 역할을 하여 본 모델을 통해 다양한 요구사항을 충족 가능한지 여부를 분석, 평가하여 결정을 이루도록 함.
설계 프로세스를 통해 다양한 솔루션 및 trade-off에 대한 시험 및 평가를 이룰 뿐 아니라 작성과 시험의 시작점의 역할을 수행.
표준에서는(IEEE 12207 등의) S/W 설계 과정을 두 개의 활동으로 나눔
 ○ S/W 아키텍처 설계(Architectural Design; top level Design이라 부르기도) : S/W의 최상위 구조와 조직을 기술하고 다양한 컴포넌트를 식별
 ○ S/W 세부 설계(detailed design) : 각각의 컴포넌트에 대해 작성이 가능하도록 기술


Breakdown of topics

1. S/W 설계 기본(Software Design Fundamentals)

1.1. 일반 설계 개념(General Design Concepts)
설계가 관여되는 영역은 S/W 뿐 아니라 문제 해결, 목표, 제한조건, 대안, 대표 등 다양함
1.2. S/W 설계의 컨텍스트(The context of software design)
S/W 설계의 역할을 이해하기 위해서는 컨텍스트 - SWE 생명 주기에서 설계의 주변 타 영역 : 요구사항 분석, S/W 구성, 테스트 등 - 를 이해하는 것이 중요.
1.3. S/W 설계 공정(The software design process)
일반적으로 두 개의 과정, 즉 아키텍처 설계와 상세 설계로 나눔.
 ○ S/W 아키텍처 설계(Architectural Design; top level Design이라 부르기도)
1.4. S/W의 최상위 구조와 조직을 기술하고 다양한 컴포넌트를 식별
 ○ S/W 세부 설계(detailed design)
각각의 컴포넌트에 대해 작성(construction)이 가능하도록 해당 컴포넌트의 행위를 기술.
1.5. 가능화 기술(Enabling techniques)
'원칙'을 뜻하는 본 토픽은 다양한 S/W 설계 접근법과 개념의 기본을 이룸.
1. 추상화(Abstraction)
이질적인 정보를 제외하여 동일한 부분만을 취하는 과정. S/W 설계에서 추상화는 매개변수화(parameterization)과 명세화(specification)임. 명세화에 의한 추상화는 procedural 추상화, data 추상화 그리고 제어(control; iteration) 추상화를 이루게 됨.
2. 결합(coupling)과 응집(cohesion)
결합은 모듈간 관계력(the strength of the relationships)로 정의되며 응집은 요소가 모듈을 어떻게 이루는지로 정의됨.
3. 분할(Decomposition)와 모듈화(modularization)
대규모 S/W를 독립적 소규모 부분으로 나누는 것으로, 보통 목표는 컴포넌트의 각기 다른 기능 또는 책임을 위치시키는 데 있음.
4. 캡슐화(Encapsulation) / 정보 은닉(Information hiding)
추상에 대한 요소 및 내부 세부 사항을 한 데 묶고(grouping and packaging) 세부 요소에 접근 불가능하도록 함을 뜻함.
5. 인터페이스와 구현의 분리(Separation of interface and implementation)
Client에 공개된 인터페이스를 지정하고 컴포넌트 구현의 방법에 대해서는 격리하는 기법
6. 충분성(sufficiency), 완전성(completeness), 근원성(primitiveness)
이들 속성은 S/W 컴포넌트가 추상물에 대한 모든 중요 특성을 갖추고 있음을 뜻함.


2. S/W 설계의 핵심 이슈(Key Issues in Software Design)
횡단 관심(cross-cutting concerns)의 기능을 이루는 aspect에 대하여(aspect; S/W의 기능적 분해에 따른 단위가 아닌, 컴포넌트의 성능이나 의미론(semantics)에 시스템적 방법으로 영향을 주는 속성). 아래 토픽의 나열은 알파벳 순서. (aspect이외의 사항에 대해서는 '1.4. 가능화 기술'이나 '6 S/W 설계 전략 및 방법'을 따름)

2.1. 동시성(concurrency)
S/W를 프로세스, 작업(task), 스래드(Thread)로 나누는 방법 및 효율성, 원자성, 일치성(synchronization) 및 일정 이슈에 관계된 사항을 다룸.
2.2. 사건의 제어 및 다루기(Control and handling of events)
암시적 실행(invocation) 및 콜백(call-back)와 같은 메커니즘을 통해, 데이터와 제어 흐름을 구성하는 방법과 반응적(reactive)/일시적(temporal) 사건을 처리하는 방법에 대해 기술.
2.3. 컴포넌트의 배분(Distribution of components)
H/W에 S/W를 배분하는 방법, 컴포넌트간 통신 방법, 이질적 S/W를 다룸에 있어 미들웨어를 어떻게 사용할지에 대해 기술
2.4. 오류(error) 및 예외 처리와 결함 복구(Fault tolerance)
결함(fault) 방지 및 복구, 예외 조건에 대한 처리에 대하여.
2.5. 상호작용(Interaction)과 표현(Presentation)
사용자와 표현계층 간에 상호작용을 위해 어떻게 구조 및 조직화를 이룰지에 대하여(예를 들어, MVC 접근법을 통해 표현계층과 업무 논리를 분리하기 등)
2.6. 데이터 지속성(Data persistence)
긴 수명의 데이터를 다루는 방법에 대하여.


3. S/W 구조 및 아키텍처(Software structures and Architecture)
1990년대 중반부터 S/W 아키텍처에 대한 일반적(generic) 패턴이 나타났으며, 이들의 최종 목적은 재사용에 있음.
3.1. 아키텍처 구조 및 관점(Architectural structures and viewpoints)
View란 S/W 시스템의 특정 속성을 보여주는 S/W 아키텍처의 단면으로서, 각각의 view는 S/W 설계에 연계된 각기 다른 이슈를 포함함. 예를 들어,
 ○ 논리 뷰(logical view)는 기능적 요구사항을 나타내고,
 ○ 공정 뷰(process view)는 동시성 이슈를 나타내며,
 ○ 물리 뷰(physical view)는 배분(distribution) 이슈를 보여주고,
 ○ 개발 뷰(development view)는 설계가 구현단위로 어떻게 분해되는지를 보여줌.
위와는 다른 용어로, 행위/기능적/구조적/데이터 모델링 뷰도 존재.
정리하자면, S/W 설계란 설계 공정을 통해 만들어지고 상대적 의존/독립적 뷰로 구성된 다면적 구조물(multi-faceted artifact)임.
3.2. 아키텍처 스타일(Architectural styles - macroarchitectural patterns)
아키텍처 스타일이란 아키텍처에 부과된 일련의 제한조건으로서, 이들 조건을 만족시키는 일련의 아키텍처 모임(아키텍처의 아키텍처)을 정의함(a set of constraints on an architecture that defines a set or family of architectures that satisfies them). 따라서 아키텍처 스타일은 S/W의 고수준 조직(macroarchitecture)를 제공하는 메타모델로 바라볼 수 있음. 종류로서,
 ○ 일반 구조(General structure) : layers, pipes and filters, blackboard
 ○ 분산 시스템(Distributed systems) : C/S, threetiers, broker
 ○ 상호작용 시스템(interactive systems) : MVC, PAC(Presentation-Abstraction-Control)
 ○ 적응적 시스템(Adaptive systems) : micro-kernel, reflection
 ○ 기타 : batch, interpreter, process control, rule-based 등이 있음.
3.3. 설계 패턴(Design patterns - microarchitectural patterns)
간단히 이야기해서 설계 패턴이란 특정 컨텍스트 내의 일반적(common) 문제에 대한 일반적(common) 해결법임. Macro 수준의 패턴을 논하는 아키텍처 스타일에 비해 micro 수준을 논함. 종류로서,
 ○ 생성 패턴(builder, factory, prototype, singleton)
 ○ 구조 패턴(adaptor, bridge, composite, decorator, façade, flyweight, proxy)
 ○ 행위 패턴(command, interpreter, iterator, mediator, observer, state, strategy, template, visitor)가 있음
3.4. 프로그램과 프레임워크의 일족(Families of Programs and Frameworks)
S/W 설계와 컴포넌트에 대한 재사용을 가능케 하는 또 다른 방법으로서, S/W 일족을 설계하는 SPL(Software Product Lines)이 있음. 이는 해당 일족(family)의 멤버 사이에서 일반성(commonality)을 식별하고, 가변성(variability)을 위한 재사용/커스터마이징 가능 컴포넌트를 사용함으로 이룸.
OO 프로그래밍에서 이에 관련된 주요 개념은 프레임워크임 : hot spot이라 불리는 특정 플러그인의 실행을 통해 확장 가능한, 부분적으로 완성된 S/W 하위 시스템(subsystem)4. S/W 설계 품질 분석 및 평가(Software Design Quality Analysis and Evaluation)


4.1. 품질 속성(Quality attributes)
고품질의 설계를 얻기 위해서는 여러 품질 속성을 고려해야. 가능성(~ilities)을 나타내는 요소로 maintainability, portability, testability, traceability가 있으며, 상태(~ness)를 나타내는 요소로, correctness, robustness 및 'fitness of purpose' 등이 있음.
 ○ Run-time에 나타나는 속성: performance, security, availability, functionality, usability
 ○ 비 run-time 요소: modifiability, portability, reusability, integrability, testability
 ○ 이들은 아키텍처에 내재된 품질(conceptual integrity, correctness, completeness, buildability)에 관계됨.
4.2. 품질 분석 및 평가 기법(Quality analysis and evaluation techniques)
S/W 설계 품질을 검증하기 위한 다양한 도구와 기법이 존재
 ○ S/W 설계 검토(review) : 종종 그룹을 지어 설계물의 품질을 검증(verify and ensure)하는 비형식/반형식적 기법. 설계 검토, 인스펙션, 시나리오 기반 기법, 요구사항 추적 등.
 ○ 정적 분석 : 형식/반형식적 정적(비 실행) 분석으로서, 설계 평가를 위해 수행(오류-트리 분석 또는 자동화된 교차검토(cross checking)이 있음)
 ○ 시뮬레이션/프로토타이핑 : 설계 평가를 위한 동적 기법(ex. 성능 시뮬레이션, 타당성 프로토타이핑)
4.3. 측정기준(Measures)
측정기준은 S/W 설계의 크기, 구조, 품질 등의 다양한 면을 평가하기 위해 사용함. 대부분의 측정기준은 설계 접근법에서 기인하며 크게 두 개의 카테고리로 분류됨.
 ○ 기능지향(Function-oriented(structured)) 설계 측정기준 : 기능적 분할을 통해 설계 구조를 얻으며 때론 계층도(Hierarchical diagram)라 일컫는 구조 차트(structure chart)가 대표적
 ○ 개체지향(Object-oriented) 설계 측정기준 : 클래스 다이어그램이 대표적. 측정은 각 클래스의 속성에 대해 이루어짐.


5. S/W 설계 표기법(Software Design Notations)
많은 표기법이 각각의 상황(구조/행위, 아키텍처/세부 등)에 맞게 존재함.
5.1. 구조 기술(Structural descriptions - static view)
주요 컴포넌트를 식별함과 동시에 이들이 어떻게 상호작용하는지를 기술
 ○ 아키텍처 기술 언어(ADL; Architectural Description Language) : 텍스트 기반의 (형식적; formal)언어로 컴포넌트와 연결자(connector)를 통해 아키텍처를 기술
 ○ 클래스 & 개체 다이어그램 : 클래스 간 또는 개체 간 관계 기술
 ○ 컴포넌트 다이어그램 : 컴포넌트 간 관계 기술(component; 물리적이고 교체 가능한 시스템의 일부로, 일련의 interface를 구현, 제공, 준수)
 ○ CRCs(Class responsibility collaborator cards) : 컴포넌트(또는 클래스)의 이름과 해당 책임, 관련 컴포넌트 이름을 기입하는 데 사용
 ○ ERD(Entity-relationship diagram) : 정보시스템에 저장된 데이터에 대한 개념 모델을 표현
 ○ IDL(Interface description language) : 프로그래밍적 언어로 S/W 컴포넌트의 인터페이스를 정의
 ○ Jackson structure diagram : 순차, 선택, 반복을 통해 데이터 구조를 기술
 ○ Structure Chart : 프로그램 내 모듈 간 호출 구조를 기술
5.2. 행동 기술(Behavior descriptions - dynamic view)
대부분은 세부 설계 과정 중에 사용됨.
 ○ Activity diagrams : 활동(activity; 상태 기계 내에서의 비 원자적/계속적(on-going) 실행)에서 활동으로 이루어지는 제어 흐름을 보여줌
 ○ Collaboration diagrams : 개체 간 일어나는 상호작용을 표현하여 특히 객체, 연결 및 연결 내에서 발생하는 메시지 교환을 강조.
 ○ DFDs(Data flow diagrams) : 프로세스 간 데이터 흐름을 표현
 ○ Decision tables & diagrams : 조건과 행동의 복잡한 조합을 표현
 ○ Flowcharts & structured flowcharts : 제어 흐름과 수행될 관련 행동을 기술
 ○ Sequence diagrams : 개체 간 상호작용을 표현하지만 여기서는 메시지의 시간 순서에 중점을 둠
 ○ State transition & state-chart diagrams : 상태 기계 내에서의 상태 변이에 대한 제어 흐름을 표현
 ○ 정형 명세 언어 : 수학적 기본 표기법을 사용하여 엄격하고 추상적으로 S/W 컴포넌트의 인터페이스 및 행위를 표현. 종종 사전/사후 조건을 사용
 ○ 의사코드 및 PDLs(Program design language) : 구조적 프로그래밍을 띈 언어로 세부 설계 단계에서 프로시저의 행위를 기술


6. S/W 설계 전략 및 방법(Software Design Strategies and Methods)
다양한 설계 전략(strategy)이 일반적인 반면, 방법(method)은 특화되어 그 방법만의 표기법과 프로세스, guideline을 제공함. 이들 방법은 지식 전달의 수단과 S/W 개발 팀의 공용 프레임워크의 역할을 담당. [SWE 도구 및 방법 KA와 연계됨]
6.1. 일반 전략(General Strategies)
분할과 정복, 단계적 정제(stepwise refinement), 하향식/상향식, 데이터 추상화/정보 은닉, heuristic 사용, 패턴 및 패턴 언어 사용, 반복/점증 접근법의 사용 등
6.2. 기능 지향 설계(Function-oriented(Structured) Design)
분할을 중점으로 S/W의 주요 기능을 식별하고 하향식 방법으로 이들을 정제하는 기법. 구조적 분석 이후 수행되어 DFD 및 관련 프로세스 기술을 만들어냄.
다양한 전략(transformation analysis, transaction analysis 등)과 heuristic(fan-in/fan-out, 영향 범위 vs 제어 범위 등)은 DFD를 구조 차트로 표현되는 S/W 아키텍처로 변환하는 데 사용.
6.3. 개체 지향 설계(Object-oriented design)
1980 중반의 Object-based design(명사:object, 동사:method, 형용사:attribute)에서 시작하여, 추상과 다형이 핵심인 Object Oriented Design, 메타 정보가 정의되고 접근되는(reflection을 통해) CBD까지 이름.
OO Design은 데이터 추상화에서 출발하지만, 책임 주도 설계는 OO 설계의 대안으로 제안됨.
6.4. 데이터 구조 중심 설계(Data-structure centered designed)
Jackson, Warnier-Orr 등이 대표적인 본 방법은 기능이 아닌 데이터 구조 중심적임. 데이터 구조에 대한 입출력 기술(Jackson's 구조도)을 시작한 이후 프로그램의 해당 데이터 구조에 맞춰 제어 구조를 개발.
6.5. 컴포넌트 기반 설계(Component-based design)
S/W 컴포넌트란 잘 정의된 interface를 갖고, 독립적으로 구성/배포 가능한 의존성을 기반으로 만들어진 독립 단위임. 재사용 극대화에 초점.
6.6. 기타 방법(other methods)
다른 방법도 존재하지만 주류는 아님 : formal & rigorous 방법 및 transformational methods)

Introduction
S/W 요구사항 KA(Knowledge Area)는 S/W 요구사항의 추출, 분석, 명세, 명세로 이루어져. 이들 활동이 적절히 이루어지지 않으면 SWE(Software Engineering) 프로젝트가 심각하게 취약해짐은 S/W 산업계에 잘 알려진 사실임.
S/W 요구사항은 S/W 제품에 대한 요구와 제한사항을 표현하여 실세계 문제의 해결책에 대한 일부를 담당.
'요구 공학'이란 용어는 많이 사용되지만, 일관성을 위해 여기서는 사용되지 않음. 전체에 걸쳐 '공학(engineering)'이란 용어는 'S/W 공학'을 제외하고는 사용되지 않을 것임
KA 분할(KA breakdown)는 IEEE12207에서 언급한 요구사항 활동 섹션과 호환됨.
문제는 제시된 분할(breakdown)이 폭포수적(waterfall-like) 프로세스를 연상시킨다는 건데, 이를 방지하기 위해 '요구사항 공정' 장은 요구사항 공정에 대한 고수준 조감(overview)을 제시.
또 다른 분류 방법으로 제품 기반 구조(시스템 요구사항, S/W 요구사항, 프로토타입, Use Case 등)에 기반하는 방법이 있음. 하지만 프로세스 기반 분할은 요구사항 공정이 복잡하고 강하게 엮인 활동(순차적, 동시적 모두)인 사실을 강조하는 데 유효.
S/W 요구사항 KA는 S/W 설계, 시험, 유지보수, 구성관리, SWE 관리, SWE 공정, 품질 KA에 연계됨.

Breakdown of topics

1. S/W 요구사항 기본(Software Requirements Fundamentals)
1.1. S/W 요구사항의 정의(Definition of a Software Requirement)
A property which must be exhibited by software developed or adapted to solve a particular problem
특정 문제를 해결하기 위해, S/W 개발 또는 적용을 통해 외부로 드러나야 하는 속성
요구사항은 주어진 자원 내에서 반드시 검증 가능하여야(verifiable)
1.2. 제품 및 공정 요구사항(Product & Process Requirements)
Product Requirement : 개발될 S/W 자체에 관계
Process Requirement : S/W 개발의 제한사항(constraint)에 관계(ex. 당 S/W는 Ada로 개발되어야)
1.3. 기능 및 비기능 요구사항(Functional & Non-functional Requirements)
Functional Requirements : S/W가 수행할 기능을 기술
Non-functional Requirements : 해당 솔루션을 제한(constrain)하기 위해 행동(act)하는 것. 제한(constraint) 또는 품질(quality) 요구사항으로 불리기도
1.4. 창발적 속성(Emergent Properties)
단일 컴포넌트로는 드러나지 않고 해당 S/W의 여러 컴포넌트간 상호작용을 통해 나타나는 속성 및 요구사항. 본 속성은 본질적으로 시스템 아키텍처에 의존함.
1.5. 정량적 요구사항(Quantifiable Requirements)
S/W 요구사항은 최대한 명확하게 표현하여 모호함을 최대한 배제하여야.
1.6. 시스템 및 S/W 요구사항
시스템 : 정의된 목적을 달성하기 위한 요소간 조합(combination)의 상호작용. 요소에는 H/W, S/W, firmware, 사람, 정보, 기술, facilities, 서비스 및 타 지원 요소가 포함됨(INCOSE00 : International Council on Systems Engineering)
시스템 요구사항 : 시스템을 전체로 바라본 요구사항. 때때로 사용자 요구사항이 되기도.


2. 요구사항 공정(Requirements Process)
2.1. 공정 모형(Process Models)
SDLC의 개별적 초기(discrete front-end) 활동이라기보다는 프로젝트 초기에 시작되어 생명주기 전체에 걸쳐 정제되는(refined; 반복?) 활동
S/W 요구사항을 형상 항목으로 식별하고, SDLC 상의 타 산출물과 동일한 형상관리 활동(practice)를 통해 관리하는 활동
조직과 프로젝트 배경구조(context)에 적용되어야(needs to be adapted)
2.2. 공정 활동자(Process Actors)
수행 주체 : 사용자, 시장 분석가, Regulator, S/W 기술자 등의 다양한 이해당사자가 결부됨. 따라서 trade-off 가 필수. 이해 당사자를 식별하고, 이들의 이해를 분석하고 이들의 요구를 추출해야 함.
2.3. 공정 지원 및 관리(Process Support and Management)
요구사항 프로세스에서 요구되고 소비되는 프로젝트 관리 자원. 이는 SWE 관리 지식 영역(KA)의 초기 및 범위 정의를 다루는 첫 부 영역(sub-area)를 위한 배경을 수립함. 주요 목적은 2.1.에서 식별한 프로세스 활동 및 비용, 인력, 훈련, 도구 간의 연계(link) 수립에 있음
2.4. 프로세스 품질 및 향상(Improvement)
요구사항 프로세스가 수행하는 주요 역할을 비용과 S/W 제품의 시간선(timeliness), 그리고 S/W에 대한 customer의 만족으로서 나타냄. S/W 품질 KA와 SWE 프로세스 KA와 깊은 연계.
주요 토픽으로,
 ○ 프로세스 향상 표준 및 모델을 통한 요구사항 프로세스
 ○ 요구사항 프로세스 측정 및 벤치마크
 ○ 향상 계획 및 구현


3. 요구사항 추출(Requirements Elicitation)
3.1. 요구사항 소스(Requirements Sources)
S/W에 영향을 주는 모든 잠재적 Source의 식별이 중요. 따라서 다양한 Source의 인지 및 이들을 관리할 Framework이 필요. 주요 핵심으로서, 다음과 같은 것이 있음. 
목표(Goal), 도메인 지식(Domain Knowledge), 이해당사자(Stakeholder), 운영 환경(The operational environment), 조직 환경(Organizational environment)
3.2. 추출 기술(Elicitation Techniques)
인터뷰, 시나리오(use case는 가장 흔한 유형임. Topic 4.2 개념 모델링과 연계), 프로토타입(topic 6.2. 프로토타이핑과 연계), 촉진 미팅(facilitated meetings; 혼자보다는 다수가 요구사항으로의 직관력을 높힘. 요구사항간의 충돌 조정 기능도. 브레인스토밍), 관찰(비즈니스가 이루어지는 조직 환경으로 뛰어들어 느끼기)


4. 요구사항 분석(Requirements Analysis)
요구사항 간 충돌의 식별 및 해결 / S/W의 범위 및 S/W가 환경과 어떻게 상호작용하는지 / S/W 요구사항을 유도하기 위해 시스템 요구사항에 공들이기(elaborate)
SADT와 같은 개념적 모델링으로 압축되어, 여기에는 요구사항 trade-off를 위한 분류, 협상 등이 포함
4.1. 요구사항 분류(Requirements Classification)
다양한 차원으로 분류될 수 있어.
 ○ 기능/비기능 요구사항
 ○ 소스에 의해서 : 고수준 요구사항, 창발적 속성, 이해당사자 또는 타 자원
 ○ 제품/프로세스 요구사항
 ○ 요구사항 우선순위, 범위, 변화 여부 : 휘발성(volatility)/안정성(stability)
 ○ 조직의 일반 프랙티스 및 application 자체
요구사항 분류와 요구사항 속성간에는 강한 오버랩이 존재
4.2. 개념 모델링(Conceptual Modeling) - IEEE 1320.1 for functional modeling, IEEE 1320.2 for information modeling
실세계 문제에 대한 모델 개발은 요구사항 분석의 핵심. 해결책의 제시보다는 문제의 이해에 중점을 둠. 따라서 이는 실세계의 관계 및 의존성을 반영한 문제 영역의 Entity에 대한 모델을 포함.
다양한 모델이 있는데, 이들은 데이터와 제어 흐름, 상태 모델, 이벤트 추적, 사용자 상호작용, 객체 모델, 데이터 모델 등이 있음.  선택 기준은 아래와 같음
 ○ 문제의 특성, 기술자의 기술수준, 프로세스 요구사항, 해당 모델을 지원하는 기법, 지원 도구의 수준
거의 모든 경우에서 개념 모델링은 외부 환경과의 상호작용을 기술하는 S/W 컨텍스트 구축을 시작함.
모델링은 주로 널리 퍼진 표기법(notation; UML 등)으로 이루어짐.
이산 수학에 기반한 정형 모델링은 논리적 추론을 가능케 하며 이는 특화된 영역에서 사용됨. 주로 고객 또는 표준, 타 모델링 기법에 비해 이점이 있을 때 사용
4.3. 아키텍처 설계(Architectural Design) 및 요구사항 할당(Requirements Allocation) - IEEE 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
시스템 또는 S/W 설계 프로세스와 중첩되어, S/W 설계 KA의 S/W 구조와 아키텍처 부영역과 밀접히 연계됨.
요구사항 분석 프로세스는 요구사항 충족을 구체적으로 담당하는 컴포넌트의 식별을 요구하며 이는 아키텍처 설계의 일부. 컴포넌트 식별이 바로 요구사항 할당임.
할당은 요구사항의 세부 분석을 수행. 여러 요구사항이 컴포넌트에 할당되면, 컴포넌트간 상호작용에 의해 타 요구사항이 어떻게 충족되는지를 파악 가능.
아키텍처 설계는 개념 모델링과 비슷하기는 하나 실세계 영역의 엔티티와 S/W 컴포넌트 간 mapping은 명확하지 않음. 따라서 명확히 분리되는 영역임. 허나 사용되는 표기법은 거의 공통적임.
4.4. 요구사항 협상(Requirements Negotiation)
다른 말로는 충돌 해결(conflict resolution)임. 이해당사자간 또는 자원과 요구사항 간 조정을 요구하므로, 대부분의 경우에서 사안에 대해 S/W 기술자 단독적 결정은 현명치 못한 처사. 이해 당사자가 함께 모여 trade-off를 이루도록 해야.
본 과정은 요구사항 분석의 결과에 따라 발생하나 확인 단계에서도 나타남.


5. 요구사항 명세(Requirements Specification)
'명세'란 제품의 설계 목표에 수치적 값 또는 제한의 할당을 의미하는데, 전형적으로 물리적 시스템은 그러한 값이 상대적으로 적은 반면, S/W는 요구사항이 매우 많기에 초점은 대량의 요구사항 간 상호작용의 복잡도 관리에 대해 수치적 양화(量化; quantification)에 있음. 
따라서 SWE에서의 요구사항 명세란 시스템적으로 검토, 평가 및 승인이 가능한 문서적 산출물(production) 또는 이에 상응한 전자적 산출물을 뜻함. 특히 복잡한 시스템에서는 3가지의 문서, 즉 시스템 정의, 시스템 요구사항, S/W 요구사항이 수반됨.
5.1. 시스템 정의 문서(System Definition Document) - IEEE 1362, Concept of Operations Document
사용자 요구사항 문서(the user requirements document) 또는 운용 개념(concept of operations)으로 알려지기도.
도메인 관점에서 고수준 요구사항을 정의함. 사용자/고객이 독자층에 포함되기에 도메인 언어로 기술되어야.
내용 : 시스템의 전체 목표에 대한 배경 정보, 시스템 요구사항, 대상 환경, 제한 조건, 가정, 비기능 요구사항. 시스템 컨텍스트를 표현하기 위한 개념 모델과 사용자 시나리오, 주요 도메인 엔티티, 데이터, 정보, workflow를 포함하기도.
5.2. 시스템 요구사항 명세(System Requirements Specification) - IEEE1233-98
시스템 요구사항에서 S/W 요구사항이 도출된 후, S/W 컴포넌트의 요구사항이 지정됨.
5.3. S/W 요구사항 명세(S/W Requirements Specification) - IEEE 1465(ISO/IEC 12119와 유사), IEEE 830 for the production and content of the SRS
S/W가 할 일에 대한 고객과 계약자(CONTRACTOR) 또는 공급자간 합의의 기반이 됨. S/W 요구사항 정의 문서와 통합되기도.
S/W 설계 전에 엄격한 요구사항 평가(assessment)를 수행함으로 재설계의 위험을 제거.
제품 가격, 위험, 일정 산정을 위한 현실적 기반을 제공
조직은 자체적인 V&V 계획을 위해 사용할 수도
시스템 인수 및 S/W 향상(enhancement)를 위한 기반
S/W 요구사항은 종종 자연어로 기술되나, SRS에서는 정형 또는 준 정형 기술로 보강되기도. 표기법의 선정은 최대한 정확하고 자세하게 기술할 수 있으면 됨.
SRS의 품질과 타 프로젝트 변수(예산, 인수, 성능, 일정 등)와 연계하기 위한 다양한 품질 지표(quality indicator)가 있으며, 이들 지표에는 크기, 가독성, 명세, 깊이, 문서 구조 등이 포함됨.


6. 요구사항 확인(Requirements Validation)
요구사항 문서는 V&V 대상으로 S/W 기술자의 요구사항 이해 여부를 확인(validate)하고 기업 표준 준수, 이해 가능성, 일관성, 완전성을 검증(verify)함. 정형 표기는 일관성과 완전성을 증명하는데 이점을 가짐. 고객과 개발 측 대표를 포함한 이해당사자가 검토.
요구사항 프로세스에서 명시적인 일정을 가져, 자원이 투입되기 전에 문제를 걸러내는 데 목적이 있음.
6.1. 요구사항 검토(Requirements Reviews) - IEEE 1028
확인(validation)의 가장 보편적 의미는 인스펙션 또는 검토임. 검토자는 그룹을 이루어 오류, 가정(assumption)에서의 문제, 명확성, 표준 준수 여부 등을 확인.
6.2. 프로토타이핑(Prototyping)
S/W 기술자의 요구사항 해석 여부 확인 및 새 요구사항 추출을 위한 대표적 수단.
요구사항 확인 외의 다양한 용도로 사용 가능하며, S/W 기술자의 가정을 해석하고 feedback을 받기에 좋음. 하지만 치장된 표현물 및 품질 문제로 인해 주요 기반 기능에 대한 초점을 흐리게 하는 단점을 내포.
6.3. 모델 확인(Model Validation)
분석 프로세스 중 개발된 모델 역시 확인 대상. 정형 명세 표기의 경우, 명세 속성을 증명하는 정형 추론을 사용 가능함.
6.4. 승인 시험(Acceptance Test)
요구사항 문서의 핵심 속성은 최종 제품이 요구사항 문서를 만족하는지 여부를 확인 가능토록 하는데 있음. 본 확인이 불가능하면 요구사항 문서는 단지 'wish'에 불과함. 따라서 각 요구사항을 어떻게 검증(verify)할지를 계획하는 절차, 즉 인수 테스트 케이스 설계는 매우 중요.
비기능 요구사항에 대한 인수 테스트 식별 및 설계는 어렵기에, 먼저 정량적으로 표현함으로 분석이 시작되어야.


7. 실제적 고려사항(Practical Considerations)
요구사항 프로세스는 SDLC 전체에 걸치며, 변화 관리 및 요구사항의 유지보수, 즉 현 S/W의 상태를 mirroring하는 것은 SWE 프로세스 성공의 핵심임.
많은 조직이 요구사항 문서화를 불필요하게 생각하나 이들 조직이 커갈 수록, 그리고 그들의 고객이 많아질 수록, 제품이 진화할 수록, 제품의 변경에 따른 영향을 평가하기 위해 이를 중요시 하게 됨.
7.1. 요구사항 프로세스의 반복적 속성(Iterative Nature of Requirements Process)
대규모 프로젝트에서 완벽하게 이해되고 명세화된 요구사항이란 미신에 가까움. 요구사항 프로세스 각각은 설계 및 획득 결정(procurement decision)이 충분히 가능할 때까지 반복적으로 이루어짐.
대부분의 경우에서 요구사항에 대한 이해는 설계와 개발이 진행되면서 이루어짐. 따라서 요구사항의 개정이 생명주기 중에 일어남. 요구사항이 변화함은 요구 공학의 이해에 대한  가장 핵심적인 사항임. 이는 분석 과정에서의 오류에서도 기인하지만 주로 '환경'의 변화로 인해 발생. 변화는 관리되어야 하며 이는 검토와 승인 과정을 통해 수행되어야. 이를 위해 요구사항의 추적, 영향 분석, S/W 구성 관리가 요구됨.
따라서 요구사항 프로세스는 S/W 개발의 초기(front-end) 작업이 아니라 전체 생명 주기로 퍼짐.
7.2. 변화 관리(Change Management)
변화 관리는 요구사항 관리의 핵심. S/W 구성 관리 KA와 밀접히 엮임
7.3. 요구사항 속성(Requirements Attributes)
요구사항은 요구되는 사항에 대한 명세 뿐 아니라 요구사항의 관리 및 해석을 돕기 위한 부가 정보로 구성됨. 무엇보다도 중요한 요구사항 속성을 요구사항을 명확하게 식별하는 것.
7.4. 요구사항 추적(Requirements Tracing)
추적의 핵심은 요구사항의 영향 예측 및 요구사항의 근원 파악임. 추적은 요구사항의 변화에 대한 영향 분석을 위한 기반이 됨.
또한 요구사항 추적을 통해 해당 요구사항에 대한 설계 엔티티까지 다가갈 수 있어야.
요구사항 추적 결과는 요구사항의 복잡한 DAG(directed acyclic graph)를 형성함
7.5. 요구사항 측정(Measuring Requirements) - IEEE 14143.1 the concept of FSM
계량화는 요구사항의 변화의 정도, 개발 및 유지보수 작업의 비용 등을 평가하는데 유용.
FSM(Function Size Measurement)은 기능 요구사항의 크기를 평가하는 기술.

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

12. Rapid application development(RAD)
- 데이터에 집중된 비즈니스 응용(application), 즉 DB로부터의 정보를 표현하는 응용에 주로 사용
- RAD 환경 도구 : DB 프로그래밍 언어, Interface 생성기, 오피스 응용 프로그램과의 연결, 리포트 생성기, 대화식 개발에 알맞는 Visual programming 도구

13. Visual development
- 단위가 작은 재사용 가능 S/W 컴포넌트의 통합에 의존하는 RAD 기법
- Visual Basic같은 스크립트 언어를 사용
- 대규모 컴포넌트가 기정의, 기구현되어 있음
- 특정 응용 요구사항에 맞도록 재구성될(tailored) 수도
- COTS(Commercial Off-the-Shelf; 상용 기성품) 기반 개발이라 부르기도. 기성품을 재구성(configure)하고 연결
- 복합 문서(Compound documents)
  1) 사용자 조작(computation)이 가능한 능동 요소(active element)가 내장된 문서. 복합 문서 자체는 각기 다른 응용을 통합하는 역할
  2) 각각의 능동 요소는 특정 응용과 연결되어 해당 요소 선택시 활성화됨
- 문제점
  1) 팀 기반 개발에 알맞지 않음
  2) 명시적 시스템 아키텍처가 없음
  3) 프로그램 부위간 복잡한 의존성이 유지보수 문제를 일으킬 수도

14. S/W 프로토타이핑(Prototyping)
- 개념을 보여주고(demonstrate), 설계 선택사항(option)을 시험해보기 위한 개발할 시스템의 초기 버전
- 용도는,
  1) 요구공학 프로세스 : 요구사항 추출 및 검증을 위해
  2) 설계 프로세스 : 선택사항 시험 및 UI 설계 개발을 위해
  3) 테스트 프로세스 : back-to-back 테스트 수행을 위해
- 장점
  1) 시스템 사용성 향상
  2) 사용자의 실제 필요에 더욱 근접
  3) 설계 품질 향상
  4) 유지보수성 향상
  5) 개발 노력(effort)의 절감
  6) back-to-back 테스트가 가능해짐15. 폐기용 프로토타입(Throw-away prototypes)
- 프로토타입은 개발 후 폐기되어야 : 제조 시스템(production system)을 위한 적절한 기반이 되지 못하기 때문에
  1) (보안성, 신뢰성 등의) 비기능적 요구사항을 만족시키기 위해 프로토타입을 손질할(tune) 수 없음
  2) 일반적으로 프로토타입에 대한 문서는 없음
  3) 프로토타입의 구조는 보통 많은 변경으로 인해 낙후됨(degraded)
  4) 프로토타입은 조직의 품질 기준(표준)에 미치지 못하는 경우가 다반사

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

7. 애자일 기법(Agile Methods)
- 기존의 개발 접근법에 대한 불만,즉 계획 수립, 설계, 문서화에 대한 부하(overhead)에 대한 반기로 시작
- 설계와 문서화보다는 S/W 자체(특히 코드)에 초점을 두도록
- 점증적 접근법에 기반
- 빠르게 변화, 진화해가는 요구사항에 대한 신속한 S/W의 배포
- 주로 소/중규모 비즈니스 시스템이나 PC 제품이 알맞음
- XP는 가장 잘 알려진 애자일 기법 중 하나

8. 애자일의 원칙
- 고객 참여(Customer involvement) : 고객은 요구사항 개발 및 운선순위 결정, 시스템의 반복(iteration)을 평가
- 점증적 인도(Incremental delivery) : 고객이 지정한 요구사항이 포함된 점증 단계를 기반으로 s/w가 개발되고 인도됨
- 사람은 프로세스가 아님(People not process) : 기정의된 프로세스를 강요하지 않음. 개발자 및 개발팀 만의 방식, 그들의 기술을 인정
- 변화를 포용(Embrace change) : 요구사항의 변화를 받아들이고 ,변화 수용 가능한 시스템을 설계
- 단순성 유지(Maintain simplicity) : S/W 및 개발 프로세스 모두에서 단순성에 초점을. 수시로 시스템에 남겨진 복잡성을 제거하도록

9. 애자일의 문제점
- 고객은 전적으로, 계속하여 프로세스에 참여하기 어려움
- 개발팀 구성원이 집중적인 참여를 요구하는 애자일의 특성에 맞지 않을 수도
- 다수의 이해관계자(stackholder)가 있을 경우 우선순위 변경이 어려워짐
- 단순성 유지는 추가적 작업을 요구
- 내재화된 점증적 명세화 작업으로 인해, 명사가 포함된 계약서 작성이 난해. 따라서 타 외부 개발 조직과의 co-work이 어려워질 수도

10. Extreme Programming(XP)
- 가장 잘 알려지고, 가장 많이 사용되는 애자일 기법
- 반복적 개발과 같은 좋은 실무 관행과 고객 참여을 극한(extreme)까지 밀고 나감
  1) 새로운 버전이 하루에도 몇 번씩 빌드될 수 있음
  2) 매 2주마다 각 점증적 단계가 고객에게 인도
  3) 매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정
11. Extreme programming Practices
- 점증적 계획(Incremental planning) : 시토리 카드를 이용, 작업으로 분할. 이들 작업은 스케줄링과 비용 산정의 근간. 시간을 고려하여 우선순위 결정
- 소규모 릴리즈(Small releases) : 비즈니스 가치를 제공하는 최소한의 유용한 기능을 먼저 개발. 릴리즈를 자주, 점증적으로 수행
- 단순한 설계(Simple design) : 현재의 요구사항을 충족하는 충분한 설계를
- 테스트 주도 개발(Test driven development): 구현 이전에 자동화된 단위 테스트 프레임워크를 통해 테스트 킷을 먼저 작성
- 리팩토링(Refactoring) : 계속적으로, 최대한 많이 코드를 리팩토링. 단순성, 유지보수성 증가
- 짝 프로그래밍(Pair programming) : 짝으로 팀을 이뤄 함께 개발. 서로가 상대의 작업을 검사(checking)하도록. 비공식적 검토(Informal review)가 자연스럽게 이루어짐
- 집단적 소유(Collective ownership) : 짝이 시스템의 모든 영역을 맡음으로 고립된 비 개발 영역이 없도록. 누구든지 변경 코드 변경 가능
- 계속적 통합(Continuous integration) : 작업이 완료되자마자 전체 시스템에 통합되도록. 이후 모든 단위 테스트를 통과해야
- 유지 가능한 속도(Sustainable pace) : 초과 근무는 낮은 품질, 보통의 생산성 만을 양성할 뿐
- 현장의 고객(On-site customer) : 고객은 개발팀의 일원. 전적으로 개발에 시간을 할당하여 시스템 요구사항을 전달할 책임이 고객에게 존재

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. 신속 S/W 개발(Rapid S/W development)
- 비즈니스 환경의 빠른 변화, 비즈니스는 새로운 기회와 도전에 신속히 응답해야. Time-to-market
- 이 경우, 신속한 개발과 인도는 종종 S/W 시스템에 관한 가장 중요한 요구사항
- 위와 같은 배경 기반의 비즈니스 영역에서는 주요 기능이 정상적으로 동작하기만 하면 빠른 인도의 장점이 낮은 품질이란 단점을 상쇄
- 요구사항
  1) 환경의 변화로 인해 안정적이고 일관적인 시스템 요구사항에 도달하기가 매우 어려움
  2) 따라서 waterfall 모델은 비현실적, 오직 반복적(iterative) 명세와 인도에 기반을 둔 개발 방법론만이 S/W를 신속하게 인도하는 유일한 방법

2. RAD 프로세스의 특성
- 명세, 설계, 구현 프로세스가 동시에 이루어짐. 상세 명세는 없으며 설계 문서는 최소화됨
- 시스템은 일련은 점증적 단계(증분; increment)를 통해 개발됨. 최종 사용자는 개발에 참여하여 각 점증 단계를 평가하며, 이후 점증 단계를 위한 제안을 함
- 시스템 UI는 일반적으로 반복적 개발 시스템을 이용하여 개발됨
3. 점증적 개발(Incremental development)의 장점
- 고객 서비스의 신속한 인도(accelerated delivery of customer services) : 각 점증 단계(증분; increment)는 고객의 가장 높은 우선순위의 기능을 인도
- 시스템에 대한 사용자의 참여 : 사용자는 개발에 참여하여 시스템이 좀더 그들의 요구에 다가서고, 사용자는 시스템에 대해 더 나은 만족을 얻을 수 있음

4. 점증적 개발의 문제점
- 관리 문제(Management problem) : 문서가 없으므로 상황 파악이 어려움
- 계약 문제(Contractual problem) : 명세가 없으므로 명세 이외의 타 형식의 문서를 사용해야
- 검증 문제(Validation problem) : 명세가 없으면, 어떤 기준으로 시스템을 테스트할 것인가
- 유지보수 문제(Maintenance problem) : 계속적인 변경은 S/W 구조에 문제를 일으키고(corrupt), 이로써 S/W는 새로운 요구에 대한 변경과 진화가 어려워짐

5. 프로토타이핑(Prototyping)
- 일부 대규모 시스템에서는 점증적 반복 개발과 인도는 비현실적. 특히 다수의 팀이 각가 다른 위치에서 일할 경우
- 실험적 시스템을 개발하는 프로토타이핑을 통해 요구사항의 타당성(실제 사용할만한지 여부 판단) 체계화(formulate)를 위한 기반을 세울 수 있음. 시스템 명세가 만들어지면(agreed) 프로토타입은 폐기됨(throw away)

6. 점증적 개발과 프로토타이핑
- 점증적 개발의 목적은 최종 사용자에게 실제 동작하는(working) 시스템을 인도함에 있음. 개발은 가장 잘 이해된 요구사항을 바탕으로 시작됨.
- 프로토타이핑의 목적은 시스템 요구사항의 검증 또는 추출임. 프로토타이핑 프로세스는 잘 이해되지 않은 이해사항에서 시작.

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

7. CMMI(Capability Maturity Model Integration) framework
- 조직의 개발 프로세스 역량 성숙도(Capability maturity)를 평가하는 SEI(Software Engineering Institute)가 제안한 통합 모델
- 목표 : 다양한 기업에 걸쳐 광범위하게 적용될 수 있도록 프로세스 개선을 위한 프레임워크 제공
- 프로세스 역량 평가 : 평가의 수단으로 기획된 본 모델은 조직의 프로세스가 best practice를 따르도록 발전
- 두 개의 기본 모델 : staged model & continuous model
  1) staged model : S/W CMM에 적합하고 조직의 시스템 개발과 관리 프로세스를 평가하여 1부터 5까지의 성숙도 수준을 할당하도록 구성
  2) continuous model : 더 세분화된 분류. 24개의 프로세스 영역에 대해 1부터 6까지의 등급을 부여

참고 : CMMI의 분야별 모델
- SW-CMM : S/W 개발 및 유지보수 능력 향상
- SE-CMM : 시스템 공학 분야 기본 요소
- IPD-CMM : 프로젝트 간 협동과 통합 프로젝트 개발 프로세스 개선
- P-CMM : 인적 자원 역량 수준
- SA-CMM : S/W 획득과정 역량

8. CMMI model components
- 프로세스 영역(Process areas) : 24개의 프로세스 영역으로 나뉘어 프로세스 역량과 개선 사항을 식별한다. 이들은 4개의 그룹, 즉 프로세스 관리, 프로젝트 관리, 엔지니어링, 지원으로 나뉜다.
- 목표(Goals) : 조직이 달성해야 하는 바람직한 상태의 추상화된 표현. 각 프로세스 영역은 해당하는 특정 목표가 있고, 해당 영역에 관한 바람직한 상태가 정의된다. 또한 좋은 관례를 제도화하는 데 필요한 일반 목표를 정의한다.
- 관례(Practices) : 목표를 달성하기 위한 방법의 표현. 이들 관례는 권장사항일 뿐이지 의무 사항이 아니다.

목표와 연관 프로세스 영역의 예:
목표 : 프로젝트의 성과나 결과가 계획보다 현격하게 어긋날 때 마무리를 위한 수정 활동을 관리한다 / 해당 프로세스 영역 : 프로젝트 모니터링과 통제의 특정 목표
목표 : 프로세스정의된 고프로세스로 제도화된다 / 해당 프로세스 영역 : 일반 목표

9. CMMI 평가
- 조직의 프로세스를 조사하여 각 프로세스 영역에서 성숙도 수준과 관련한 6점 척도(6-point scale)을 매긴다.
  1) 실행되지 않음(not performed) : 프로세스 영역과 관련한 하나 이상의 목표를 만족하지 못함
  2) 실행됨(Performed) : 프로세스 영역에 관련한 목표를 만족하고, 해당 프로세스 내의 작업 범위가 명백히 나타나며 팀원 사이에 전달됨.
  3) 관리됨(Managed) : 조직의 정책, 문서화된 계획, 자원 관리와 프로세스 모니터링 절차가 존재
  4) 정의됨(Defined) : 조직의 표준화와 프로세스 전개에 초점
  5) 양적으로 관리됨(Quantitatively managed) : 하위 프로세스(sub process)를 제어하기 위한 통계적 방법과 정량적 방법이 사용됨. 즉, 수집된 프로세스와 제품 측정치가 프로세스 개선에 이용되어야.
  6) 최적화됨(Optimizing) : 프로세스와 제품 측정치를 이용. 추세가 분석되고 업무의 변화에 따른 프로세스 수정이 이루어짐

참고: CMM에서는...
1) 초기(Initial) : 근본적으로 통제되지 않음
2) 반복(Repeatable) : 제품 관리 절차가 정의, 사용됨
3) 정의됨(Defined) : 프로세스 관리 절차 및 전략이 정의, 사용됨
4) 관리됨(Managed) : 품질 관리 전략이 정의, 사용됨
5) 최적화됨(Optimizing) : 프로세스 개선 전략이 정의, 사용됨

CMM은 CMMI에 비해 1) 관례가 모델 수준에 연관되어 타 수준의 관례를 사용할 수 없고, 2) 연속적이기보다는 이산적이며, 3) 목표보다는 관례 지향적이란 문제를 내포하고 있음

10. 단계적(Staged) CMMI 모델
- S/W CMM과 호환
- 각 성숙 수준 마다 해당 프로세스 영역과 목표가 존재
- 단계 : Initial > Managed > Defined > Quantitatively managed > Optimizing
- 장점 : S/W CMM과의 호환, 조직에 필요한 분명한 개선 경로를 정의
- 단점 : 낮은 수준의 관례를 도입하기 전에 높은 수준의 관례를 도입하는 것이 더욱 적절할  경우, CMMI는 조직의 역량에 오해하기 쉬운 그림을 제시(CMM의 단점과 동일)
11. 연속적(Continuous) CMMI 모델
- 매우 조밀한 모델로서, 관례를 개별적 또는 그룹으로 고려하여 각 관례의 사용을 평가, 따라서 성숙도 평가는 단일 값이 아닌 각 영역 내에서의 해당 조직에 대한 값의 집합 형태
- leveling이 프로젝트 전체가 아닌 각 프로세스 영역 별로 나뉨(5개의 level은 staged model과 동일)
- 평가 결과는 각 프로세스 영역을 나타내는 역량 프로파일과 해당 역량 평가
- 장점 : 조직 자신의 필요와 요구에 따라 개선하기 위한 프로세스를 선택 가능. 단계적 모델에 비해 유연

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

4. 프로세스 측정(Process measurement)
- 정량적 프로세스 데이터는 가능한한 모든 곳에서 수집되어야 : 프로세스 표준이 없는 조직에서는 측정 대상을 알아내기 힘듬. 따라서 측정이 이루어지기 전에 프로세스를 먼저 정의해야
- 프로세스 측정은 프로세스 개선 평가에 사용되어야 : 이는 측정이 개선을 유도한다는 뜻이 아님. 개선 자체가 조직의 목표가 되어야.
- 프로세스 측정의 분류
  1) 프로세스 활동이 완료되기까지 걸린 시간. e.g. 캘린더 시간
  2) 프로세스 또는 특정 활동에 필요한 리소스. e.g. 총 工數(person-days)량.
  3) 특정 이벤트 발행 횟수. e.g. 발견된 결함 개수
- 프로세스 측정은 측정 대상을 식별하는 것이 가장 어려움. GQM 패러다임은 무엇을 측정할지, 어떻게 이용되어야 하는지를 판단하는 데 유익.
  1) Goal(목표) : 조직이 성취하고자 하는 것은 무엇인가?
  2) Questions(질문) : 목표에 관계된 불확실한 영역에 대한 질문
  3) Metrics(척도) : 질문에 대해 답변하기 위해 측정치가 수집되어야.

5. 프로세스 분석과 모델링(Process analysis and modelling)
- 기존 프로세스를 연구하여 해당 프로세스에 대한 추상 모델을 개발
- 당 모델은 보통 graphical하게 표현됨. 여러 뷰가 요구됨
- 해당 모델을 분석하여 프로세스의 문제를 분석. 분석에는 프로세스 행동에 대한 이해당사자와의 의논과 가능한 프로세스 변경 발견을 포함함
- 프로세스 분석 기술
  1) 기존의 프로세스 모델과 프로세스 표준 분석
  2) 설문과 인터뷰
  3) 민속학 연구
- 프로세스 모델 요소 : 활동(activity), 프로세스(process), 산출물(input, output), 조건(condition), 역할(role), 예외(exception), 통신(communication)
- 프로세스 예외 : 프로세스 모델은 이상적 상황만을 기술. 프로젝트 관리자는 예외를 처리할 책임이 있으며, 이를 통해 프로세스는 동적으로 변경 가능해야

6. 프로세스 변경(Process change)
- 기존의 프로세스에 대한 수정. 새로운 프랙티스, 방법론 또는 프로세스의 소개, 프로세스 행동의 순서 변경, 산출물의 도입 또는 제거, 새로운 역할 및 책임 도입 등이 포함
- 변경은 반드시 축정 가능한 목표에 의해 이루어져야
- 프로세스 변경 단계
  1) 프로세스 개선 사항 식별(Identify improvements)
  2) 우선순위 결정(Prioritise improvements)
  3) 프로세스 변경 도입(Introduce process change)
  4) 프로세스 변경 훈련(Train engineers)
  5) 변경 조정(Tune process change)

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. 프로세스 개선 개요
- 현재의 프로세스 이해 및 제품의 품질을 향상시키고, 비용 절감하거나 스케줄을 앞당기기 위해 프로세스를 변경하는 행위
- 대부분의 프로세스 개선은 결함 제거에 초점이 맞춰지나, 다른 프로세스 속성도 주요 목적에 속함
- 프로세스 속성(attribute)의 예 : 이해가능성, 가시성, 지원가능성(CASE 도구를 통한 지원 가능 여부), 수용가능성(해당 프로세스가 엔지니어에게), 신뢰성(제품 오류를 유발하지 않도록), 강건성(예기치 않은 문제로 프로세스가 중단되는 일이 없도록), 유지보수성(프로세스 자체의), 신속성
- 프로세스 개선 단계(세 단계가 사이클을 이루면서 개선이 이루어짐)
  1) 프로세스 측정 : 현재 프로세스의 속성을 측정. 측정치가 바로 개선을 위한 baseline
  2) 프로세스 분석 : 현 프로세스 평가 및 bottleneck과 취약점을 식별
  3) 프로세스 변경 : 분석을 통해 식별한 부분에 대한 변경

2. 프로세스 및 제품 품질
- 프로세스 품질 향상은 제품 품질 향상에 직결
- 제조의 경우 프로세스는 주된 품질 결정자(determinant)이나, 설계 기반 활동의 경우 설계자(designer)의 능력 등 기타 요소가 관계됨.
- 주요 제품 품질 인자 : 프로세스 품질 / 개발 기술(developement technology) / people quality / 비용, 시간, 스케줄
  1) 대규모 프로젝트에서는 프로세스 품질이 key factor
  2) 소규모 프로젝트에서는 개발자의 역량 및 개발 기술이 key factor
  3) 위 두 경우 모두에서 비현실적 schedule은 제품 품질 저하에 직결

3. 프로세스 분류
- 비정형(informal) : 상세 프로세스 모델이 없음. 개발 팀은 그들만의 방식을 선택. e.g. 프로토타입, 단기 lifetime 시스템, 4GL 비즈니스 시스템, 소/중규모 시스템
- 관리(managed) : 개발 프로세스를 이끌 프로세스 모델이 정의됨. e.g. 대규모 시스템, 장기 lifetime 제품
- 방법적(Methodical) : RUP와 같은 특정 개발 방법론이 프로세스를 지원. e.g. well-understood application domain, re-engineered system.
- 지원(supported) : 자동화된 CASE 도구가 프로세스를 지원

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

11. 품질 제어(Quality control)
- S/W 개발 프로세스를 검사하여 절차와 표준을 따르는지 여부를 판단
- 품질 제어의 두 가지 유형
  1) 품질 검토(review)
  2) 자동 S/W 평가 : S/W 측정 및 특정 척도와의 비교 포함

12. 품질 검토(Quality review)
- 제품 및 프로세스 검증을 위한 주요 방법
- 특정 팀이 잠재적 문제를 찾기 위해 프로세스의 전과정 또는 시스템과 해당 문서를 검사
- 목적 : 시스템의 결함과 비일관성의 발견
- 코드, 설계, 명세, 테스트 계획, 문서, 표준 등이 검토 대상
- 품질 검토의 기능
  1) 품질 관리 : 일반적 품질 관리 프로세스의 일부
  2) 프로젝트 관리 : 프로젝트 관리자에게 S/W 품질에 대한 정보를 제공
  3) 훈련 및 소통 : 제품 지식이 개발팀 멤버 간에 전달됨
- 검토 프로세스 : 검토 팀 선택 -> 장소 및 시간 선정 -> 문서 배포 -> 검토 수행 -> 검토 문서(form) 생성
- 검토 결과 : No action, Refer for repair, Reconsider, Overall design 등으로 분류하여 고객에게 전달해야 함.

참고:
검토(review)에는 여러 종류가 있음 : 1) 결함 제거를 위한 inspection(제품 대상), 2) 진행 검토(제품 및 프로세스 대상), 3) 품질 검토(제품 및 문서 대상)

12. S/W 측정(measurement)과 (측정을 위한) 척도(metric)
- S/W 제품 또는 프로세스의 속성(attribute)에 대한 수치를 끌어내어 이를 척도와 비교하는 행위
- S/W 시스템, 프로세스, 관련 문서 등 모든 부분에 측정
- 제품 속성(attribute)을 예측(predict)하거나 S/W 프로세스를 제어(control)하는 데 사용
- 예측에는 두 개의 속성이 존재 : 내부 속성 / 외부 속성
13. 제품 측정 프로세스(Product measurement process)
- S/W 측정 프로세스는 품질 제어 프로세스의 일부
- 본 프로세스 실행 중 모인 데이터는 조직적 리소스(organisational resource)로 관리되어야 : 측정 DB가 수립 시 프로젝트간 비교가 가능
- 절차 : 측정 항목 선택 -> 평가할 컴포넌트 선택 -> 컴포넌트 특성 측정 -> 비정상 측정 항목 식별 -> 비정상 컴포넌트 분석

14. 제품 척도(Product metrics)
- 품질 척도는 제품 품질을 예측할 수 있어야
- 제품 척도의 종류
  1) 동적 척도 : 프로그램 실행 시 모인 측정치. 효율성과 신뢰성 평가에 도움. S/W 품질 속성에 직접적 관계됨.
  2) 정적 척도 : 시스템 표현(설계, 문서 등)으로 만들어진 측정치. 복잡성, 이해가능성, 유지보수성 평가에 도움. S/W 품질 속성에 간접적 관계됨. e.g. Fan-in/out(한 함수 내에서 호출하는 다른 함수의 수를 측정-in의 경우), 코드 길이, 사이클로매틱 복잡도(제어 복잡도), 식별자의 길이, 포그 색인(단어의 평균 길이를 측정)
  3) 개체 지향 척도 : 정적 척도의 일부(?). 상속 트리의 깊이, Method fan-in/out, Weighted fan in/out, overriding 개수
- 특정 척도는 프로젝트, QA팀의 목표, S/W 유형에 좌우 : 조직 자신에 가장 적합한 척도를 발견하기 위해 실험해야

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

8. ISO 9000
- 품질 관리 시스템을 위한 국제 표준 집합
- 제조업에서 서비스업에 이르기까지의 광범위한 조직에 적용
- ISO 9001은 ISO 9000 표준 집합의 일부. 제품의 설계, 개발, 유지보수에 이르기까지의 전 프로세스에 적용됨
- 각 조직은 범용 모델인 ISO 9001 표준을 이용하여 조직의 품질 프로세스 문서로 구체화(instantiate)하여 사용하여야
- ISO 9000 인증은 제조 프로세스의 품질에 대한 인증이지, 제품 자체 품질에 대한 인증이 아님.

9. 문서화 표준
- 문서는 S/W의 구체적 표시이므로 매우 중요
- 문서화 표준의 세가지 유형
  1) 문서화 프로세스 표준 : 문서의 생성, 검증, 관리에 대해 기술
  2) 문서 표준 : 문서의 식별, 구조, 표현, 갱신에 대해 기술
  3) 문서 교환 표준 : 전자 문서의 호환성에 대해 기술

10. 품질 계획(Quality Planning)
- 원하는 제품 품질을 설정하고 이를 어떻게 평가할지, 그리고 주요 품질 특성이 무엇인지를 정의
- 반드시 품질 평가 프로세스를 정의하여야
- 어떤 조직 표준을 적용할지, 언제 필요한지, 사용할 새로운 표준을 정의해야
- 품질 계획의 구조 : 제품 개요, 제품 계획, 제품 설명, 품질 목표, 위험 및 위험 관리
- S/W 품질 특성 : 안정성, 이해가능성, 이식성, 보안성, 시험용이성, 사용성, 신뢰성, 적용성, 재사용성, 복원성, 모듈성, 효율성, 강건성, 복잡성, 학습성

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. S/W 품질 관리(Quality management)
- S/W가 요구 수준(표준)의 품질에 도달했음을 확인
- 적절한 품질 표준과 절차(procedure)를 정의
- 품질은 모두의 책임임을 나타내는 '품질 문화'를 개발

2. S/W에서 품질이란 무엇인가?
- 품질이란 단순히 제품이 자신의 명세에 만족함을 의미한다.
- 위 정의는 다음의 사항에서 문제점이 있다.
  1) 고객의 품질 요구사항(효율성, 신뢰성 등)와 개발자의 품질 요구사항(유지보수성, 재사용성 등) 간에 빚어지는 마찰
  2) 특정 품질 요구사항은 모호함을 띄므로, 지정이 어려움.
  3) S/W 명세는 일반적으로 불완전하며 종종 일관적이지 못함. 그러나 명세가 완전할 때까지 진행되는 일은 없음 : 품질에 대한 타협이 일어남.

3. 품질 관리의 영역
- 품질 관리는 특히 대규모의 복잡한 시스템에서 중요. 품질 문서화는 개발 프로세스에 대한 기록이며, 개발 팀이 변경됨에 따른 개발 불연속성에 대한 해결책으로 작용.
- 작은 시스템 개발에서는 문서화보다는 품질 문화를 이루는 것이 중요.

4. 품질 관리 활동
- 품질 보증(Quality Assurance) : 조직적 절차와 품질에 대한 표준을 수립
- 품질 계획(Quality Planning) : 적용가능한 절차와 해당 프로젝트에 맞는 표준을 선정, 이를 필요에 따라 수정
- 품질 제어(Quality Control) : 절차와 표준이 S/W 개발 팀에 의해 준수되고 있음을 확인
- 품질 관리는 프로젝트 관리와 분명히 분리되고, 독립적이어야 함.

5. 프로세스와 제품 품질
- 프로세스에서의 설계와 창조성, 유지 보수성 등 측정이 쉽지 않은 S/W 개발 속성으로 인해 S/W의 경우는 프로세스와 제품 품질 간 관계가 매우 복잡
- 그러나 제품의 품질은 프로세스에 의해 크게 영향을 받음이 경험적으로 증명됨.
- 어떻게 검토(review)를 이룰지, 형상 관리는 어떻게 이룰지 등의 프로세스 표준 정의가 필요.
6. 품질 보증과 표준
- 표준은 효과적 품질 관리의 핵심
- 품질 보증 프로세스의 일환으로 설정 가능한 두가지 유형의 표준 : 제품 표준, 프로세스 표준
  1) 제품 표준 : 모든 컴포넌트가 보여야 할 특징을 정의. e.g 설계 검토 형식, 요구사항 문서 구조, 메서드 헤더 양식, 프로그래밍 스타일, 프로젝트 계획 양식 등.
  2) 프로세스 표준 : S/W 프로세스에서 수행되어야 할 사항을 정의. e.g. 설계 검토 시행, 버전 릴리스 프로세스, 프로젝트 계획 승인 프로세스 등

7. 표준의 중요성
- 베스트 프랙티스를 포함함. 지난 실수를 반복하지 않도록
- 품질 보증 프로세스의 프레임워크 : 표준 준수 검사를 포함함
- 연속성을 제공 : 새로운 스태프는 사용되고 있는 표준을 이해함으로 조직을 이해할 수 있음.

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

16. The COCOMO Model
- An empirical model based on project experience
- Long history from initial version published in 1981(COCOMO-81) through various instantiations to COCOMO2
- COCOMO2 takes into account different approaches to S/W development, reuse, etc.

17. COCOMO2
- COCOMO81 was developed with the assumptions that a waterfall process would be used and all S/W would be developed from scratch
- COCOMO2 incorporates a range of sub-models that produce increasingly detailed S/W estimates
- The sub-models in COCOMO2
  1) Application composition model : Used when S/W iscomposed from existing parts, based on number of Application Points
  2) Early design model : used when requirements are available but design has not yet started, based on number of Function Points
  3) Reuse model : used to compute the effort of integrating reusable components, based on reused or generated LOC
  4) Post-architecture model : used once the system architecture has been designed and more information about the system is available, based on LOC

18. Application composition model
- Supports prototyping projects and projects where there is extensive reuse
- based on standard estimates of developer productivity in application(object) points/month
- takes CASE tool use into account
- PM = (NAP * (1 - %REUSE/10)) / PROD. PM is the effort in Person-Month(工數), NAP is the number of application points, %REUSE is the amount of reused codes and PROD is productivity(unit : LOC/PM)

19. Early design model (Early prototyping model)
- Estimates can be made after the requirements have been agreed
- based on a standard formular for algorithmic models
  1) PM = A * Size^B * M
  2) A is 2.94 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on novelty of the project development flexibility, risk management approaches and the process maturity
  3) M is multiplier that reflect the capability of developer and the non-functional requirements

20. The reuse model
- takes into account reusable code that requires little or no change and has to be adapted to be integrated with new code
- two versions :
  1) Black-box reuse(non-modification of source code).
  2) White -box reuse(code is modified)
- Non-linear model. The more reusable code, the code decreased.
- For generated code : PM = (ASLOC * AT)/ATPROD
  1) ASLOC is the number of lines of generated code(unit : LOC)
  2) AT is the percentage of code automatically generated
  3) ATPROD is the productivity of engineers in integrating this code(e.g. 2400 LOC/PM)

21. Post architecture model
- uses the same formula as the early design model but with 17 rather than 7 associated multipliers.
- The code size is estimated as
  1) Number of lines of new code to be developed
  2) estimate of equivalent number of lines of new code computing using the reuse model
  3) An estimate of the number of lines of code that have to be modified according to requirements changes
- Due to its complexity, most company would not adapt this model

22. Project duration and staffing
- As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required
- Calendar time can be estimated using a COCOMO2 formula
  1) TDEV = 3 * PM^(0.33 + 0.2 * (B - 1.01))
  2) B is exponent computed as discussed above (B is for the early prototyping model)
- The time required is independent of the number of people working on the project. The key is on the net effort

23. Staffing requirements
- Staff required can't be computed by dividing the development time by the required schedule
- The number of people working on a project varies depending on the phase of the project
- The more people who work on the project, the more total effort is usually required
- A very rapid build-up of people often correlates with schedule slippage

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

9. Function points
- based on a combination of program characteristics
  1) External inputs and outputs
  2) User interactions
  3) External interfaces
  4) Files used by the system
- A weight is associated. * UFC = ∑(number of elements of given type * weight), UFC means Unadjusted Function point Count.
- Productivity is estimated by functions point per person-month
- can be used to estimate LOC depending on the average number of LOC per FP for a given language. LOC = AVC(language dependent factor) * number of function points
- are very subjective. They depend on the estimator. Automatic function-point counting is impossible

10. Object points
- (alternatively named application points) are an alternative to function points for 4GL
- The number of objects in a program is a weighted estimate of the number of
  1) Seperate screens
  2) Reports that are produced by the system
  3) Program modules that must be developed to supplement the database code
- easier to estimate from a specification than function points. So it is commonly used at a fairly early point in SDLC

11. Factors affecting productivity
- Application domain experience
- Process quality
- Project size
- Technology support
- Work environment (refer to Managing people)

12. Estimation techniques
- No simple way to make an accurate estimate of the effort
- Project cost estimates may be self-fulfilling : The estimation defines the budget and the product is adjusted to meet the budget
- Due to changing technologies, prev estimating experience does not carry over to new systems
- Estimation should be based on several methods
- If these do not return approximately the same result, more information for estimation is required
- Pricing to win is sometimes the only applicable method

13. Technique types
  1) Algorithmic cost modeling : based on historical cost information. Effort = A * Size^B * M (A is an organisation-dependent constant, Size is S/W size or fuction, object points, B reflects the disproportionate effort for larget projects(1 ~ 1.5) and M is a multiplier reflecting product, process, peple attributes)
  2) Expert judgement : Several experts on the proposed S/W development techniques and the application domain are consulted
  3) Estimation by analogy : is applicable when other projects in the same application domain have been completed
  4) Parkinson's Law : estimated via mon-month. The cost is determined by available resources rather than by objective assessment.
  5) Pricing to win : the estimated effort depends on customer's budget and not on the S/W functionality

14. Top-down and bottom-up estimation
- Any of these approaches may be used top-down or bottom-up
  1) Top-down : estimation starts at the system level. Usable without knowledge of the system architecture and the components. It may result underestimation of the cost of soving difficult low-level technical problems
  2) Bottom-up : starts at the component level. Usable when the architecture of the system is known and components identified. It may result underestimate the cost of system level activities such as integration and documentation

15. Project Uncertainty

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Fundamental estimation question
- How much effort is required to complete an activity?
- How much calendar time is need to complete an activity?
- What is the total cost of an activity?

2. Software cost components and pricing
- H/W and S/W costs
- Effort costs (the dominant factor in most projects) : salaries, social and insurance costs.
- Effort costs must take overheads into account : heating, lighting, networking, shared facilities, etc.
- No simple relationship between the development cost and the price charged to the customer
- Broader organisational, economic, political and business considerations influence the price charged

4. Software pricing factors
- Market opportunity
- Cost estimate uncertainty : contingency increase its price
- Source code ownership : to customer or developer or hybrid
- Requirements volatility
- Financial health of the developer

5. Software productivity
- A measure of the rate at which individual engineers produce software and documentation
- Not quality-oriented although assourance is a factor in productivity assessment

6. Productivity measures
- Size related measures : based on some output from the S/W process. e.g LOC, KLOC
- Function-related measures : based on an estimate of the functionality of the delivered S/W. e.g. Function-points, Object-points

7. Lines of code (LOC)
- assumes thate there is a linear relationship between system size and volume of documentation
- The more verbose the programmer, the highter the productivity

8. Productivity comparisons : The lower level the language, the more productive the programmer : More code on lower level language

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

7. Managing groups
- Most S/W engineering is a group activity
- Factors influencing group working
  1) group composition : Balance of the personality types is important(especially, people with interaction-oriented personality. They can detect and defuse tensions)
  2) group cohesiveness : Team spirit encouraged through openness with information, social events, developing a group identity and territory, explicit team-building activities
  3) group communication : Essential for effective group working. Information must be exchanged on the status of work, design decisions and changes to previous decisions
  4) group organisation : Informalities on small S/W engineering group, hierarchical stucture on large group

8. Informal group
- The group acts as a whole and comes to a consensus on decisions affecting the system
- The group leader serves as the external interface of the group but does not allocate specific work items
- Tasks are allocated according to ability and experience
- This approach is successful for groups where all members are experienced and competent
- e.g. Extream programming group

9. Working environments
- The physical workplace provision has an important effect on individual productivity and satisfaction : Comport, privacy, facilities
- Health and safety considerations must be taken into account : Lighting, heating, furniture

10. P-CMM(People Capability Maturity Model)
- is a framework for improving the capabilities of staff in an organisation
- Five stage model
  1) Initial : Ad-hoc people management
  2) Repeatable : Policies developed
  3) Defined : Standardised people management across the organisation
  4) Managed : Quantitative goals for people management in place
  5) Optimizing : Continuous focus on improving individual competence and workforce motivation

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. People in the process
- People are an organisation's most important assets
- The tasks of a maanger are essentially people-oriented, no understanding of people, no successful management

2. People management factors
- Consistency : Team members should all be treated in a comparable way without favourites or discrimination
- Respect : Diffenent team members have different skills and these differences should be respected
- Inclusion : Involve all team members and make sure that people's views are considered
- Honesty : You should always be honest about what is going well and what is going badly in a project

3. Lessons
- selection staff : An important project management task is team selection
- Skills such as UI design and H/W interfacing are in short supply
- Introducing new skills to recent graduates
- Technical proficency may be less importnat than social skills

4. Staff selection factors
- Application domain experience
- Platform experience
- Programming language experience
- Problem solving ability
- Educational background
- Communication ability
- Adaptability
- Attitude
- Personality

5. Motivating people
- Motivation is a complex issue, there are different types of motivation based on : Physical need, personal needs(respect, self-esteem), social needs(team spirits)

6. Personality types
- Motivation should also take into account different personality types :
  1) Task oriented : motivated by task itself
  2) Self oriented : motivated by achieving self-objective
  3) Interaction oriented : motivated by co-work

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Test case design
- The goal of test case design is to create a set of tests that are effective in validation and defect testing
- Use experience and guidelines to design test cases in defect testing
- Design approaches
  1) Requirements-based testing
  2) Partition testing
  3) Structural testing
  4) Path testing

2. Requirements based testing
- A general principle of requirments engineering is that requirements should be tesable
- is a validation testing technique where you consider each requirement
- derive a set of tests for that requirement

3. Partition testing
- Equivalence partitioning is a way of discovering test cases - all cases in a partition should behave in the same way
- Input data and output results often fall into different classes where all members of a class are related
- Each of these classes in an equivalence partition or domain where the program behaves in an equivalent way for each class member
- Test cases should be chosen from each partition

4. Structural testing
- Sometime called white-box testing
- Derivation of test cases according to program structure. Knowledge of the program is used to identify addtional test cases
- Objective is to exercise all program statements(not all path combinations)

5. Path testing
- The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once
- The starting point ofr path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control
- A dynamic program analyser may be used to check that paths have been executed

6. Test automation
- Testing is an expensive process phase
- Test automation tools are called as testing workbench
- Most testing workbenches are open systems because testing needs are organisation-specific
- Scripts may be developed for UI simulators and patterns for test data generators

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. The testing process
- Component testing(unit testing)
  1) Testing of individual program compoents
  2) Usually the responsibility of the component developer
- System testing
  1) Testing of groups of components integrated to create a system or sub-system
  2) The responsibility of an independent testing team
  3) Tests are based on a system specification

2. Testing progress goals
- Validation testing : demonstrate the S/W meets its requirements. A successful test shows that the system operates as intended
- Defect testing : discover faults or defects in the S/W. A successful test exposes defects in the system

3. Testing policies
- Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossible
- Testing policies define the approach to be used in selecting system tests. e.g. All functions accessed throught menus should be tested

4. System testing
- Involves integrating components to create a system or sub-system
- Two phases of testing : Integration testing, Release testing

5. Integration testing
- The test team have access to the system source code
- The system is tested when components are integrated
- To simplify error localisation, system should be incrementally integrated

6. Release testing
- The process of testing a release of a system that will be distributed to customers
- Primary goal is to increase the supplier's confidence that the system meets its requirements
- Release testing is usually black-box or functional testing : based on the system specification only

7. using UML
- Use cases can be a basis for deriving the tests for a system. They help identify operations to be tested and help design the required test cases
- From an associated sequence diagram, the I/O to be created for the tests can be identified

8. Performance testing
- test emergent properties of system, such as performance and reliability
- In test plan, the load is steadily increased untiil system performance becomes unacceptable

9. Stress testing
- Exercises the system beyond its maximum design load
- Stressing the system test failur behaviour. Systems should not fail catastrophically

10. Component testing
- Component or unit testing is the process of testing individual components in isolation
- It is a defect testing process

11. Interface testing
- Objectives are to detect faults due to interface errors or invalid assumptions about interfaces
- Particularly impotant for OOD

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Verification and formal methods
- Formal methods used on mathematical specification of the system
- Formal methods are the ultimate static verification technique
- They involve detailed mathematical analysis of the specification and any develop formal arguments that a program conforms to its mathematical specification

2. Formal methods pros/cons
pros:
- mathematical specification by detailed analysis likely to uncover errors
- detect implementation errors before testing when the program is analysed alongside the specification
cons:
- require specialised notations that cannot be understood by domain experts
- Very expensive to develop a specification
- It may be possible to reach the same level of confidence in a program more cheaply using other V&V techniques

3. Cleanroom S/W development
- The name is derived from the 'Cleanroom' process in semiconductor fabrication. The philosophy is defect avoidance rather than defect removal
- based on
  1) Incremental development
  2) Formal specification
  3) Static verification using correctness arguments
  4) Statistical testing to determine program reliability

4. Cleanroom process

5. Formal specification and inspections
- The state based model is a system specification and the inspection process checks the program against this model
- The programming approach is defined so that correspondence between the model and the system is clear
- Mathematical arguments (not proofs) are used to increase confidence in the inspection process

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. S/W inspections
- These involve people examining the source representation with the aim of discovering anomalies and defects
- not require system execution(used before implementation)
- are applied to any representation of the system(requirements, design, configuration data, test data, etc.)

2. Inspection and testing
- They are complementary and not opposing verification techniques
- Both should be used during the V&V process
- Inspections can check conformance with a specification but not conformance with the customer's real requirements
- Inpections cannot check non-functional characteristics such as performance, usability, etc.

3. Program inspections
- Formalised approach to document reviews
- intended explicitly for defect detection (not correction)
- Defects may be logical errors, anomalies in the code

4. Inspection process
- Planning -> Overview ->Individual preparation -> Inspection meeting -> Rework ->Follow-up

5. Inspection procedure
- System overview presented to inspection team
- Code and associated documents are distributed to inspection team in advance
- Inspection takes place and discovered errors are noted
- Modifications are made to repair discovered errors
- Re-inspection may or may not be required

6. Inspection roles
- Author or owner : The programmer responsible for producing the program or document, fixing defects discovered
- Inspector : Find errors, ommisions and inconsistencies in programs and documents
- Reader : Presents the code or document at an inspection meeting
- Scribe : Records the results of the inspection meeting
- Chairman or moderator : Manages the process and reports process result to chief moderator
- Chief moderator : Responsible for inspection process imporvements, checklist updating, standards development, etc.

7. Inspection checklists
- Checklist of common errors should be used to drive the inspection
- prone to depend on programming language
- The 'weaker' the type checking, the larger the checklist
- e.g. Initialisation, constant naming, loop termination, array bounds, etc.

8. Inspection rate
- 500 statements/hour during overview
- 90 ~ 125 statements/hour can be inspected
- Inspecting 500 lines(overview) costs about 4 man/hours effort
- Inspection is therefore an expensive process

9. Automated static analysis
- Static analysers are S/W tools for source text processing
- They parse the program text and try to discover potentially erroneus conditions
- Very effective as an aid to inspections but not a replacement for inspections

10. Fault class that static analysis checks
- data faults, control faults, I/O faults, Interface faults, storage management faults

11. Use of static analysis
- More cost-effective for WEAK TYPING language(like C), less for STRONG TYPE CHECKING language(like JAVA)

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Verification vs validation
- Verification : "Are we building the product right?". conform to its specification
- Validation : "Are we building the right product?". do what the user really requires

2. The V&V process
- Whole life-cycle process : V&V must be applied at each stage in the S/W process
- Principal objectives
  1) The discovery of defects in a system
  2) The assessment of whether or not the system is useful and useable in an operational situation

3. V&V goals
- V&V should establish confidence that the S/W is fit for purpose
- This does NOT mean completely free of defects

4. V&V confidence (leveling of confidence)
- depends on system's purpose, user expectations and marketing environment
1) S/W function : The level of confidence dependes on how critical the S/W is to an organisation
2) User expectations : User may have low expectations of certain kinds of S/W
3) Marketing environment : Getting a product to market early may be more important than finding defects in the program

5. Static and dynamic verification
- S/W inspections : concerned with analysis of the static system representation to discover problems(static verification)
- S/W testing : concerned with exercising and observing product behaviour(dynamic verification)

6. Program testing
- reveal the presence of errors NOT their absence
- The only validation technique for non-functional requirements as the S/W has to be executed to see how it behaves(??)
- Types of testing
  1) Defect testing : tests designed to discover system defects
  2) Validation testing : intended to show that the S/W meets its requirements

7. Testing and debugging
- V&V is concerned with establishing the existence of defects in a program.
- Debugging is concerned with locating and repairing these errors

8. V-model of development

9. S/W test plan (things to consider)
- Test testing process
- Requirements traceability
- Tested items
- Testing schedule
- Test recording procedures
- H/W and S/W requirements
- Constraints

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Object-oriented development
- Object-oriented analysis, design and programming are related but distincted.
- OOA is concerned with developing an object model of the application domain.
- OOD is cencerned with developing an object-oriented system model to implement requirements
- OOP is cencerned with realising an OOD using an OO programming language

2. Characteristics of OOD
- Objects are abstractions of real-world or system entities and manage themselves
- indenpendent with each other, encapsulate state, communicate by message passing

3. Objects and object classes
- Objects are entities in a S/W system which represent instances of real-world and system entities
- Object classes are templates for objects

4. UML
- An integration of notations which describe object oriented analysis and designs
- De facto standard for object oriented modelling

5. Object communication
- Conceptually, objects communicate by message passing
- In practice, messages are often implemented by procedure calls(procedure name and parameter list)

6. Generalisation and inheritance
- Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes)
- A sub-class inherits the attributes and operations from its super class and may add new methods or atributes of its own
- Advantages : Inheritance classify entities, make reuse mechanism at both the design & the programming level, and provide organisational knowledge about domains and systems.

7. An object-oriented design process : Structured design processes
- involve developing a number of differnet system models
- require a lot of effort for development and maintenance of these models
- For small systems, this may not be cost-effiective
- However, for large systems developed by different groups design models are an essential communication mechanism

8. Process stages
1) Define system context and model of system use : A static model that describes other systems in the environment, a dynamic model that describes how the system interacts with its environment(Use Case used)
2) Design the system architecture : e.g. layered architecture(several layered sub-system composition). There should normally be no more than 7 entities in an architectural model
3) Identify the principal system objects:
  - Grammatical approach (based on natural lagnuage)
  - idenfitying concrete things in the application domain
  - Behavioural approach (what participates in what behaviour)
  - Scenario-based analysis (objects in scenario)
4) Develop design models
  - Static model : show relationships between object classes
  - Dynamic model : show relationships between objects
  - e.g. sub-system model, sequence model, state machine model(statechart), use-case models, aggregation, generalisation model, etc.
5) Object interface specification
  - Object interfaces have to be specified so that the object and other components can be designed in parallel
  - UML uses class diagram

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Generic application architecture is configured and adapted to create a system that meets specific requirements

2. Application types
- Data processing applications : process data in batches, are composed of input, output, process components. DFD(Data Flow Diagram) used. e.g. Billing, Payroll systems.
- Transaction processing applications : data-centered, transaction management middleware is used. Data flow through database -> middleware -> terminal.
- Event processing systems : The architecture has to handle unpredictable event timing. e.g. Editing system(like word processors), Real-time systems.
- Language processing systems : The systems are composed of lexical analyser, symbol table, syntax analyser, syntax tree, semantic analyser, code generator. e.g. Compilers, Command interpreters.

3. Transaction processing applications
- Layered architecture is used, commonly.
- Information system architecture
   1) Generic layered architecture
   2) Layers are the user interface, user communications, information retrieval, system database
- Resource allocation systems
   1) manage a fixed amount of some resource (like football game tickets, etc.) and allocate it to users.
   2) e.g. E-commerce system, Reservation system.