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.
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에서 보이듯이, 검토와 감사에 대한 다양한 공식적 이름이 존재하지만, 중요한 점은 이들 활동이 모든 제품에 대해서, 개발과 유지보수 프로세스의 모든 단계에서 이루어질 수 있다는 것임.
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 프로세스 수립 및 발생 가능성 높은 문제의 식별에 도움이 됨.
이와 비슷하게 벤치마크 또는 해당 도메인의 전형적 결함 집계는 제품의 인도 가능 시점 결정에 유용함.