[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)

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

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