Embedded Files
약어정리
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의 품질 특성을 정의함과 동시에, 측정 방법 및 이들 특성의 평가를 위한 수용 기준에 영향을 미침.
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.
2.2.
2.3.
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 계획에 포함됨.
검증과 확인(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 활동 절차, 활동간 상호작용 뿐 아니라 결함 보고 및 문서화 요구사항을 기술함.
검토와 감사(Reviews and Audits)
IEEE12207에서는 검토와 감사를 개별적 토픽으로 다룸. 검토 및 감사 프로세스는 IEEE12207에서 폭넓게 정의하며, 세부 사항은 IEEE1028-97에서 찾아볼 수 있음. IEEE1028에서는 검토와 감사를 5개 유형으로 나눔.
􀂊 관리 검토(Management reviews)
􀂊 기술 검토(Technical reviews)
􀂊 인스펙션(Inspections)
􀂊 워크쓰루(Walk-throughs)
􀂊 감사(Audits)
관리 검토(Management Reviews)
"관리 검토의 목적은 프로세스의 감시(monitor)와 계획과 일정 상태의 결정, 요구사항과 시스템 할당의 확정(confirm), 또는 관리 접근법의 목적 부합성에 대한 평가임"[IEEE1028-97]. 관리 검토는 변경 사항의 결정 및 S/W 프로젝트 중 요구되는 바른 활동을 지원함. 또한 계획, 일정, 요구사항의 적합성을 결정하고 이들에 대한 진행상태 및 일관성을 감시함. 본 검토는 다음과 같은 문서와 함께 수행되기도 : 감사 보고서, 진척 보고서, V&V 보고서, 다양한 유형의 계획서(위험 관리, 프로젝트 관리, S/W 형상 관리, S/W 안정성, 위험 평가).
기술 검토(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)가 수행됨. 기술 검토는 조사 수행 목록에 나열된 모든 활동이 끝났을 때 완료됨.
인스펙션(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)는 인스펙션의 기본적인 도구임. 발견된 변칙은 결과 목록에 분류되며, 해당 팀은 결과 목록을 통해 완전성과 정확성을 검토하게 됨. 인스펙션 종료 결정은 다음 세 가지 기준 중 하나에 부합되었을 때 이루어짐.
수용. 재 작업이 필요 없거나 최소한의 재 작업 만을 요구(Accept with no, or at most minor, reworking)
재작업 검증 이후 수용(Accept with rework verification)
재 인스펙션(Reinspect; 부적합. 재 작업 이후 인스펙션을 다시 수행해야)
인스펙션 미팅은 보통 몇 시간을 소요하는 한편 기술 검토 및 감사는 더 넓은 범위를 다루며 더 많은 시간을 소요함.
워크쓰루(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) 기법임.
감사(Audits)
"감사의 목적은 S/W 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차에 대해 준수하고 있는지 여부를 독립적으로 평가하는 데 있음"[IEEE1028-97]. 감사는 공식적으로 구성되는 활동으로, 감사 참여자는 특정 역할, 즉 감사 지휘자(lead auditor), 감사자(auditor), 기록자(recorder) 또는 발기자(initiator) 등이 부여되며, 피감사 조직의 대표도 포함됨. 감사는 비준수 사항의 사례(instance)를 식별하고 해당 팀으로 하여금 교정 활동(corrective action)을 요구하는 보고서를 만들어냄.
IEEE1028-97에서 보이듯이, 검토와 감사에 대한 다양한 공식적 이름이 존재하지만, 중요한 점은 이들 활동이 모든 제품에 대해서, 개발과 유지보수 프로세스의 모든 단계에서 이루어질 수 있다는 것임.
실제적 고려사항(Practical Considerations)
Page updated
Google Sites
Report abuse