Chatpter 09 품질 01 품질의 이해 02 품질 요소와 품질 평가 모델 03 제품 품질 특성 평가 모델 04 프로세스 품질 특성 평가 모델 05 대표적인 프로세스 능력 평가 모델 06 품질 관리 요약 연습문제

품질의 개념에 대해 알아본다. 제품 품질 특성에 따른 평가 모델에 대해 알아본다. 프로세스 품질 특성에 따른 평가 모델에 대해 알아본다. 품질 관리에 대해 알아본다.

Section 01 품질의 이해

1. 품질과 소프트웨어 품질(1) 품질 하드웨어 품질 물건이 얼마나 좋은지, 나쁜지를 나타내는 정도 사용자의 요구 사항을 규격서에 서술하고, 이 규격서대로 만들면 큰 문제가 없다. 만든 제품이 규격서대로 작동하는지 테스트하는 것도 비교적 용이 개발된 제품이 규격서대로 만들어지면 사용자가 만족할 만한, 품질이 좋은 하드웨어

1. 품질과 소프트웨어 품질(2) 소프트웨어 소프트웨어 품질 정의 HW(규격서) vs SW(요구 분석 명세서) 하드웨어의 규격서보다 소프트웨어의 요구 분석 명세서를 작성하는 것이 훨씬 어렵다. 소프트웨어 품질 정의 ‘사용자의 요구와 부합되는 정도’ 개발자 관점에서의 좋은 소프트웨어 결함 없는 프로그램 요구 분석 명세서대로 만든 소프트웨어 • US DoD: 개발된 소프트웨어가 사용자의 요구 사항을 만족할 수 있는 능력 • IEEE: - 소프트웨어가 필요한 속성을 보유하고 있는 정도 - 사용자의 기대 수준을 만족할 수 있는 정도를 결정하는 소프트웨어의 특성

2. 관점에 따른 품질(1)

2. 관점에 따른 품질(2) 프로젝트 관리자 관점의 좋은 소프트웨어 개발자 관점의 좋은 소프트웨어 추가 부담(기간, 비용)이 발생하지 않는 소프트웨어 개발자 관점의 좋은 소프트웨어 개발하기 쉽고 사용 중 내용 추가 및 코드 수정이 쉽고 편리하게 변경 가능한 소프트웨어 코딩 표준에 맞게 개발된 프로그램 유지보수자 관점의 좋은 소프트웨어 작성된 코드가 코딩 규칙 및 표준을 따르고 주석문이 많이 포함된 소프트웨어 가독성이 높고 쉽게 이해할 수 있게 개발된 소프트웨어

2. 관점에 따른 품질(3) 구매 담당자 관점의 좋은 소프트웨어 사용자 관점의 좋은 소프트웨어 값이 싼 소프트웨어 배우기 쉽고, 사용하기 편리하며, 다양한 기능을 제공하고, 응답 시간이 빠른 소프트웨어 첫 사용자나 숙련된 사용자 모두 만족하는 소프트웨어

3. 품질 목표(1) 품질 좋은 소프트웨어가 되려면 처음부터 품질을 고려한 계획을 세운다. 품질 요구 사항에 대한 명세서가 작성되어야 한다. 단계별로 생산되는 산출물도 검사 항목에 따라 철저히 점검해야 한다. 품질을 보증할 수 있는 프로세스를 마련해, 품질을 체크할 수 있는 과정을 명확히 한다.

3. 품질 목표(2)

Section 02 품질 요소와 품질 평가 모델

0. 품질 특성

1. McCall의 품질 요소

1-1 제품 운영 제품 운영product operation ① 정확성correctness ② 효율성efficiency 개발된 SW가 고객이 사용해도 될 만큼 적합한지의 여부를 판단할 수 있는 품질 요소 ① 정확성correctness 개발된 소프트웨어가 사용자의 기능적 요구 사항을 담은 프로그램 명세서와 얼마나 일치하는지를 나타낸다. ② 효율성efficiency 사용자가 요구하는 기능을 수행하는 데CPU와 메모리 같은 자원을 얼마나 사용하는가와 관련된 특성이다 ③ 무결성integrity 허가 받지 않은 사용자가 데이터 접근을 통해 변경을 시도했을 때 얼마나 보호할 수 있는지를 나타낸다.

1-2 제품 개선 제품 개선product revision ① 유지보수성maintainability 소프트웨어를 변경하기 쉽고 편하게 만든 정도를 나타내는 품질 요소 ① 유지보수성maintainability 사용 중인 소프트웨어를 얼마나 쉽게 변경할 수 있는지, 또 변경한 후에도 문제없이 안정적으로 운영되는지를 나타낸다. ② 유연성flexibility 운영 환경의 변화에 따라 새로운 기능을 쉽게 추가할 수 있는지, 다른 환경에 적용할 수 있도록 운용되는 프로그램을 얼마나 쉽게 수정할 수 있는지를 나타낸다. ③ 테스트 용이성testability 사용자가 요구하는 기능을 만족할 만큼 잘 수행하고 있는지에 대해 얼마나 쉽고, 철저하게 테스트할 수 있는지를 나타낸다.

1-3 제품 변환 제품 변환product transition ① 상호운용성interoperability 개발된 소프트웨어의 활용도를 높이려 할 때, 쉽게 할 수 있는 정도를 나타내는 품질 요소 ① 상호운용성interoperability 다른 소프트웨어와 얼마나 쉽게 연계 또는 결합하여 정보를 교환할 수 있는지를 나타낸다. ② 재사용성reusability 시스템의 일부나 전체를 다른 애플리케이션에서도 얼마나 쉽게 사용할 수 있는지를 나타낸다. ③ 이식성portability 하드웨어 또는 운영체제와 같은 환경에서 또 다른 환경으로 옮겨도 환경 변화에 무리 없이 잘 작동할 수 있도록 프로그램을 수정하여 이식하는 것이 얼마나 쉬운가를 나타낸다

2. 품질 평가 표준 모델(1) ① 제품 품질 특성 평가 ② 프로세스 품질 특성 평가 완성된 제품에 대한 평가 ISO/IEC 9126에서 제시하는 모델이 소프트웨어 품질에 대한 표준적인 모델 ② 프로세스 품질 특성 평가 소프트웨어 제품의 개발 프로세스를 평가 소프트웨어 개발 과정의 각 단계마다 평가

2. 품질 평가 표준 모델(2)

Section 03 제품 품질 특성 평가 모델

1. 제품 품질 특성 평가 제품 품질 특성 평가 모델 개발된 최종 산출물인 소프트웨어 제품이 사용자의 의도대로 기능을 수행하는지 평가

1-1 ISO/IEC9126 모델(1) 품질 특성과 용도 분류

1-1 ISO/IEC9126 모델(2) ① ISO/IEC 9126-1(품질 모델) ② ISO/IEC 9126-2(외부 품질) 6가지 품질 특성과 소프트웨어 제품의 품질 평가를 위한 프레임워크를 정의 ② ISO/IEC 9126-2(외부 품질) 개발자를 위한 표준 개발자/평가자/구매자가 품질 특성에 대해 사용할 수 있는 external metrics 제공 사용자/평가자/구매자/개발자들이 테스트 단계와 운영 중에 SW를 평가하고 보고서를 작성할 수 있도록 도와준다. 완성된 소프트웨어의 성능, 오류 발생, 사용 용이성 등이 여기에 해당

1-1 ISO/IEC9126 모델(3) ③ ISO/IEC 9126-3(내부 품질) ④ ISO/IEC 9126-4(사용 품질) 구매자를 위한 표준 개발자/평가자/구매자가 제품 품질을 평가할 수 있도록 도와주며, 제품 완성 전 미리 품질의 문제점들을 지적해준다. 품질 특성에 대하여 사용할 수 있는 내부 메트릭스(internal metrics)를 제공 ④ ISO/IEC 9126-4(사용 품질) 사용자를 위한 표준으로 사용 품질(quality in use)을 정의 제품이 특정 환경에서 사용될 때 사용자의 작업 효율성, 생산성, 안정성, 만족도 등 사용자의 요구를 충족시키는 정도 제품이 고객에게 인도된 후 소프트웨어 자체의 특성보다 사용해본 결과를 토대로 사용자가 측정

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(1)

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(2) ① 기능성functionality 개발된 소프트웨어가 특정 조건에서 사용될 때 개발 전에 의도했던 대로 정확하게 사용자의 요구를 만족하는 기능을 제공하는지 여부를 나타낸다.

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(3) ② 신뢰성reliability 소프트웨어를 믿고 사용할 수 있는지 여부를 나타낸다.

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(4) ③ 사용성usability 편리한 기능을 제공하는 정도를 나타낸다.

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(5) ④ 효율성efficiency

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(6) ⑤ 유지보수 용이성maintainability

1-2 ISO/IEC9126의 품질 특성 및 하위 특성(7) ⑥ 이식성portability

2. ISO/IEC 14598 모델 ISO/IEC 14598information technology-software product evaluation 소프트웨어 공급자와 구매자 사이에서 소프트웨어 개발 과정 또는 개발된 제품의 품질을 객관적으로 평가하기 위한 방법과 절차를 정의한 국제 표준 규격

2-1 ISO/IEC 14598의 특성 ISO/IEC 14598의 특성 • 반복성repeatability : 특정 제품을 동일한 평가자(기관)가 동일 기준을 적용하여 평가 했을 때 동일 한 결과가 나와야 한다. • 재생산성reproducibility : 특정 제품을 다른 평가자(기관)가 동일 기준을 적용하여 평 가했을 때 동 일한 결과가 나와야 한다. • 공정성impartiality : 평가가 특정한 결과를 내기 위해 불공정한 편견이 없어야 한다. • 객관성: 평가는 주관적 판단을 최소화하고 객관적 자료를 근거로 해야 한다. • ISO/IEC 9126 표준 준수: ISO/IEC 9126에 규정한 표준을 준수한다. • 규정하지 않는 내용: 품질 평가의 측정 기술, 측정 결과의 해석 방법 등은 규정하고 있 지 않다

2-2 ISO/IEC 14598의 제품 품질 측정 및 평가 방법(1) 소프트웨어 제품의 품질 평가를 수행하기 위한 일반적인 개요로 범위와 용어를 정의 ISO/IEC 14598과 ISO/IEC 9126의 관계 설명 개발자/평가자/구매자가 사용할 수 있는 평가 프로세스와 평가 모듈에 대한 로드맵 제공 ② 계획과 관리(ISO/IEC 14598-2) 품질 평가 척도를 프로젝트 성격에 따라 선정하고 적용하기 위한 제품 품질 측정 계획의 준비와 구현에 대해 다루고 있다. 제품 평가 기능을 지원하기 위한 요구 사항과 안내 지침을 포함한 전체적인 사항을 제공 ③ 개발자를 위한 프로세스(ISO/IEC 14598-3) 소프트웨어 개발 단계에서 알아야 할 개발자 준수 사항으로, 개발자가 개발 과정 및 최종 소프트웨어 제품의 품질 평가에 사용할 수 있는 방법을 제공

2-2 ISO/IEC 14598의 제품 품질 측정 및 평가 방법(2) 소프트웨어 제품을 구매하기 위한 계획을 수립할 때 사용하는 구매자용 프로세스 구매자가 상용 소프트웨어 제품을 구매하는 과정에서 소프트웨어 제품의 품질 평가에 사용할 수 있는 방법 제공 ⑤ 평가자를 위한 프로세스(ISO/IEC 14598-5) 품질 전문가를 위한 프로세스로, 평가자가 개발 과정 및 최종 소프트웨어 제품의 품질 평가를 수행할 때 사용 ⑥ 평가 모듈(ISO/IEC 14598-6) 개발자/구매자/평가자가 소프트웨어 제품의 품질을 평가할 때 사용할 수 있도록 평가 모델에 대한 기본적인 가이드와 이론적인 모델 제공 평가 모듈을 개발하여 문서화하고 검증하는 지침 제공

2-3 ISO/IEC 14598의 제품 품질 평가 절차

3. ISO/IEC 12119 모델(1) ISO/IEC 12119information technology-software packages-quality requirements and testing 패키지 소프트웨어의 일반적인 제품 품질 요구 사항 및 테스트를 위한 국제 표준 규격 규격 내용: 품질, 지침, 세부 인증 요건 사항: 명확화, 유사 문서 정의, 변경(가능)성, 환경 명세, 보안성 구성: 제품 설명서, 사용자 문서, 실행 프로그램 첫 번째 평가 대상: - 패키지 소프트웨어 - 제품 문서, 사용자 문서, 프로그램/데이터에 명시된 요구 사항 두 번째 평가 대상: 패키지 SW와 최종 제품 및 중간 산출물을 포함하는 수주 개발 SW 셋째 평가 대상: 패키지 SW와 최종 제품 및 개발/유지보수 과정을 포함한 수주 개발 SW 테스트 대상: 소프트웨어 제품 명세서, 사용자 매뉴얼, 사용자 요구 테스트 결과서 등 주요 테스트 평가 항목: 기능성, 신뢰성, 사용성, 이식성 등 평가 척도: ISO 9126-2, ISO 9126-3(품질 메트릭), ISO 12119(테스트 방법)

3. ISO/IEC 12119 모델(2) 평가 절차와 SW 패키지 품질 요구사항 및 테스트 모델

4. ISO/IEC 25000 모델(1) ISO/IEC 25000, SQuaRESoftware Quality and Requirement Evaluation 사용자들에게 유용하도록 여러 표준 문서를 통합하고 재구성하여 만든 국제 표준 문서 소프트웨어 품질 평가 모델로부터 시작해 전체적인 품질 평가를 위한 표준 방안 제시

4. ISO/IEC 25000 모델(2) ISO/IEC 25000 구성도

Section 04 프로세스 품질 특성 평가 모델

0. 프로세스 품질 제품 품질의 비유 프로세스 품질의 비유 프로세스 품질 좋은 수돗물을 마시려면 무엇보다 수질 자체가 좋아야 한다. 프로세스 품질의 비유 가정까지 오는 수도관이 오래되어 녹슬거나 파손되었으면 깨끗한 물을 마실 수 없다. 프로세스 품질 소프트웨어 제품의 최종 품질에 영향을 줄 수 있는 소프트웨어 개발과정에 대한 품질 • 품질 시스템 보증을 위한 ISO 9000 모델 • 소프트웨어 생명주기 프로세스 표준을 위한 ISO 12207 모델 • 소프트웨어 프로세스 능력 평가를 위한 CMMI와 SPICE(ISO 15504) 모델

1. ISO/IEC 9000 모델의 품질 요소(1) ISO 9000 국제 표준화 기구ISO가 정한 품질 관리와 품질 보증을 위한 모델 해당 제품이나 서비스 설계에서부터 생산 시설, 시험 검사 등 전반에 걸쳐 규격준수 여부를 확인해 인증 목적: 제품의 품질을 객관적으로 인증 받아 사용자에게 신뢰감을 주는 것

1. ISO/IEC 9000 모델의 품질 요소(2) ISO 9000 모델의 특징 • SDLC의 과정에 대한 품질 보증 모델이다. • 소프트웨어 개발을 목표로 구체화되지 않았다. • 소프트웨어에 적용할 수 있는 일반 원리를 설정한다. • 품질 프로세스의 다양한 측면을 기술한다. • 기업이 정의해야 하는 조직의 표준과 절차를 나열한다. • 조직의 품질 매뉴얼로 문서화한다. • 사용되어야 하는 품질 프로세스를 정의하지 않는다. • 공급자와 구매자 간의 관리 책임을 명시한다.

2. 프로세스 표준을 위한 ISO 12207 모델(1) ISO 12207 소프트웨어 개발 생명주기 프로세스인 소프트웨어 생성부터 폐기까지의 프로세스에 해당 구성: 기본 생명주기, 지원 생명주기, 조직 생명주기 기본 생명주기 프로세스: 소프트웨어의 획득, 공급, 개발, 운영, 유지보수 프로세스를 체계적으로 관리하기 위한 life cycle process standard를 제공 실무자들에게 공통 사항에 대한 프레임워크를 제공

2. 프로세스 표준을 위한 ISO 12207 모델(2)

Section 05 대표적인 프로세스 능력 평가 모델

1. 표준 프로세스의 필요성(1) 표준 프로세스 소프트웨어 개발에서 레시피, 하나의 매뉴얼, 내비게이션과 같은 역할 조직원들이 우왕좌왕 해매는 시간을 줄여주고 생산성을 높인다. 기준과 목표, 방향을 제시해주기 때문에 업무 처리 프로세스가 명확하고 계획적이며 결과를 충분히 예측할 수 있다.

1. 표준 프로세스의 필요성(2) CMMICapability Maturity Model Integration 조직의 프로세스 개선을 위해 개발 기업에 표준 프로세스를 만들 수 있는 지침을 제시하고, 그 기준이 된다. 어떤 조직이 표준 프로세스를 사용하고 지속적으로 개선한다면 조직의 업무 수행 능력 및 품질 향상 현재 조직의 표준 프로세스 수준을 잘 파악 향후 개선 방향 판단 가능 프로젝트의 정량적 목표 및 계획 수립 가능 최종 목표 달성 예측 가능 → 소프트웨어 공학의 목표인 개발의 생산성 향상과 품질 향상을 꾀할 수 있다.

2. CMMI 모델(1) C: 능력Capability M: 성숙도Maturity M: 모델Model 능력: 개발 목표(주어진 기간, 정해진 비용, 고품질 등)를 달성할 수 있는 힘 M: 성숙도Maturity 성숙(사전적 의미): ‘생물의 발육이 완전히 이루어짐’, ‘몸과 마음이 자라서 어른스럽게 됨’, ‘경험이나 습관을 쌓아 익숙해짐’ 등으로, 다 자라서(완성되어) 책임감이 있는 느낌을 준다. 성숙도가 높은 조직: 책임감이 있는 조직으로서 개발 과정에서 객관적이고 정량적인 근거에 따라 프로세스가 측정되고 지속적인 개선이 이루어지는 조직 M: 모델Model 프로세스를 감사(audit)하는 의미로 사용, 기준대로 하고 있는지, 그렇지 않은지를 검사 CMMI는 그 기준을 제시하고 있는데 그것이 ‘수행 지침(best practice)’이라는 모델

2. CMMI 모델(2) I: 통합Integration CMMI 여러 가지 프로세스의 기준을 하나로 통합했다는 의미 소프트웨어 개발 생명주기의 각 단계를 통합한 모델이라는 의미 CMMI 조직의 프로세스에 대한 가이드이자 기준 ‘능력’과 ‘성숙도’로 조직의 프로세스를 측정하고 평가하는 모델의 통합 버전인 프로세스 개선 성숙도 모델

2. CMMI 모델(3) 성숙도가 높은 조직과 낮은 조직의 특징

3. CMMI의 구성(1) CMMI 5단계

3. CMMI의 구성(2)

3. CMMI의 구성(3) CMMI 프로세스 영역의 구조도

3. CMMI의 구성(4) 일반 목표와 수행 지침 세부 목표와 수행 지침 목표: 모든 프로세스 영역에 공통으로 적용되는 목표 일반 목표 달성: 해당 프로세스의 활동들이 조직에 내재화되어 자연스럽게 수행될 수 있음 수행 지침: 일반적인 목표를 만족시키기 위해 수행해야 하는 활동이 무엇인지를 설명 세부 목표와 수행 지침 목표: 특정 프로세스 영역에만 적용되는 좁은 의미의 구체적인 목표 수행 지침: 세부적인 목표를 만족시키기 위해 수행해야 하는 활동이 무엇인지를 설명

3. CMMI의 구성(5) 필수 구성 요소 예상 구성 요소 정보 제공 구성 요소 조직이 프로세스 영역을 만족시키기 위해 무엇을 성취해야 하는지를 기술하는 구성 요소 세부 목표와 일반 목표가 이에 해당 예상 구성 요소 조직이 필수 구성 요소를 성취하기 위해 전형적으로 무엇을 구현해야 하는지를 기술 이 구성 요소들은 누가 평가를 수행하고 개선을 구현하는지를 가이드 일반 수행 지침과 세부 수행 지침이 이에 해당 정보 제공 구성 요소 필수 구성 요소와 예상 구성 요소에 접근할 수 있도록 돕는 세부 내용을 제공 예제 작업 산출물, 하위 지침, 일반 수행 지침의 정책, 입문 노트, 관련 프로세스 영역 등이 이에 해당

4. CMMI의 평가 방법 단계적 표현staged representation 방법의 성숙 단계maturity level 평가 방법 연속적 표현continuous representation 방법의 능력 단계capability level

4-1 단계적 표현 방법의 성숙 단계(1) 성숙 단계 조직에서 해당 업무를 얼마나 체계적으로 수행하고 있는지를 나타내며, 지표로는 1에서 5까지 5단계로 구분하여 사용

4-1 단계적 표현 방법의 성숙 단계(2) 성숙도 단계별 프로세스 영역

4-1 단계적 표현 방법의 성숙 단계(3) CMMI 모델의 단계적 표현

4-1 단계적 표현 방법의 성숙 단계(4) 초기initial 단계 : 프로세스 없음

4-1 단계적 표현 방법의 성숙 단계(5) 초기initial 단계 : 프로세스 없음 ① 프로세스가 정확히 정의 안됨 개발자 임의로 프로세스 정의 및 수시로 바꿈 통제가 불가능하고 비공식적이며 수행 결과도 예측하기 어렵다. 프로젝트 리더의 능력에 따른 프로젝트 성공, 실패 개인 역량이 뛰어난 한두 명에 의해 프로젝트의 결과가 결정 ② 개발 조직: 팀 협업 안됨, 적시에 교육 훈련 제공 안됨, 체계적 관리 안됨, 개발과 유지보수를 위한 조직 환경의 뒷받침이 불안정 ③ 개발 과정: 무질서, 계획과 일정 구별 못함, 진척 상황 측정 안됨 제품개발 과정 추적 및 통제 안됨 임시방편으로 처리. 계획된 절차 없이 개발 시간에 쫓김 분석/설계 없이 바로 코딩

4-1 단계적 표현 방법의 성숙 단계(6) 관리managed 단계: 프로젝트 별로 프로세스 존재

4-1 단계적 표현 방법의 성숙 단계(7) 관리managed 단계: 프로젝트 별로 프로세스 존재 ① 기본 프로세스 확립 프로젝트 예산, 일정, 기능에 대해 추적 및 예측이 가능 문제가 발생 시: 규칙화되고 훈련된 프로세스에 따라 움직임 결과물에 대해 사용자의 요구를 만족시키는지 확인 가능 프로세스 원칙이 잘 지켜짐 개인 경험보다는 과거의 축적된 데이터를 참조함 ② 개발 조직: 프로젝트 관리를 위한 정책을 세우고 절차들을 실행 ③ 개발 과정: 기본 프로젝트 관리 통제 체계가 확립 됨 요구 사항이 명확하게 문서로 작성 프로젝트 계획과 진행 상황 추적 가능

4-1 단계적 표현 방법의 성숙 단계(8) 정의defined 단계 : 조직 차원의 표준 프로세스 존재

4-1 단계적 표현 방법의 성숙 단계(9) 정의defined 단계 : 조직 차원의 표준 프로세스 존재 ① 표준화된 프로세스 존재 개별 프로젝트: 제공된 가이드를 참조로 표준 프로세스를 수정하여 활용 조직 전체: 표준 프로세스를 따름 ② 조직 내: 소프트웨어 프로세스를 전담하기 위한 SEPG 존재 SEPG: 관리자를 위한 기술 교육 실시 ③ 개발 과정: 표준 프로세스를 사용하여 개발 공정, 비용, 일정 등을 통제 가능 소프트웨어 품질 또한 추적 가능하여 관리 활동이 전반적으로 안정적 잘 지켜지는 표준화와 일관성으로 프로세스 안정화

4-1 단계적 표현 방법의 성숙 단계(10) 정량적 관리(quantitatively managed) 단계: 측정 가능한 정량적 프로세스 SW 프로세스 수치화, 계량화 철저한 관리 성과 예측 가능 제품의 품질

4-1 단계적 표현 방법의 성숙 단계(11) 최적화optimizing 단계 : 프로세스를 지속적으로 개선 지금까지 조직 차원에서 사용해오던 표준 프로세스를 개선하여 최적화 표준 프로세스 검토 후 보완 및 최신 기술 반영 지속적 프로세스 개선 개선된 프로세스를 전 조직이 사용

4-2 연속적 표현 방법의 능력 단계(1) 능력 단계 프로세스 영역 능력 수준을 측정하는 연속적 표현 모델 해당 조직의 각 프로세스 영역에 대한 능력이 얼마나 되는지를 나타냄 프로세스 영역별 능력 수준을 확인 잘되는 영역, 떨어지는 영역 구별 파악 가능

4-2 연속적 표현 방법의 능력 단계(2) 프로세스 영역별 능력 수준 점검의 이점 떨어지는 프로세스 영역: 집중 관리 가능 중요한 프로세스 영역: 집중적으로 자원 투입 능력 수준 향상

5. SPICE(ISO 15504) 모델(1) SPICE 모델 소프트웨어 프로세스 평가를 위한 프레임워크를 제공 정보 시스템 분야에 특화된 품질 표준이자 인증 규격의 역할

5. SPICE(ISO 15504) 모델(2) SPICE 모델의 프로세스 수행 능력 단계

Section 06 품질 관리

0. 품질 관리 품질 관리quality management 품질 통제quality control 개발의 각 단계에서 일어나는 모든 활동과 활동 중에 생성되는 여러 산출물을 통제하고 보증하여 품질을 관리하기 위한 활동 품질 통제 품질 관리 품질 보증 품질 통제quality control 품질 절차와 표준을 개발자들이 준수하도록 프로세스를 정의하고 규정을 만드는 것 목적: 품질 좋은 소프트웨어를 만들기 위함

1. 품질 보증(1) IEEE 정의 품질 보증quality assurance 정의 • 개발된 소프트웨어가 사용자의 요구를 만족시킨다는 것을 보장하는 데 필요한 계획적이고 체계적인 활동 • 개발된 소프트웨어가 기술적인 요구 사항과 일치하는가를 적절하게 확인하는 데 필요한 체계적이고도 계획적인 유형의 활동 소프트웨어의 결함을 줄여 품질 좋은 소프트웨어를 만들기 위해, 사용자가 요구하는 품질 수준을 파악하고 이를 어떻게 달성할 수 있는지를 정의하는 개발 단계 전역에 걸친 체계적인 작업

1. 품질 보증(2) 품질 보증 활동 개발 과정 전·후의 품질 보증 작업 개발 단계 전역에 걸쳐 품질에 영향을 미치는 문제점을 조기에 발견하여 제거하는 것 개발된 소프트웨어의 품질이 목표한 수준에 있다는 것을 보증 소프트웨어 개발 단계 전역에 걸쳐 적용되는 보호 활동umbrella activity 개발 과정 전·후의 품질 보증 작업

1. 품질 보증(3) 품질 보증의 기대 효과 품질 보증의 문제점 • 개발 체계 및 품질 환경 적립 - 명확한 요구 사항 정립 및 검토와 개발 기법의 표준화로 프로그램의 이해도 증진 - 문서 작성의 표준화 유도와 품질 정보의 체계적 관리로 유사 문제점 재발 방지 • 개발 시스템 품질 향상 - 개발 초기 단계에서 문제점 발견 및 보완 - 객관적 품질 평가로 사용성 증대 • 품질 보증에 대한 인식 부족 • 품질 요원을 중요시하지 않는 시각에 따른 경험 많은 품질 보증 요원의 부족 • 품질 보증에 대한 제도의 표준화와 절차 확립의 부족

1. 품질 보증(4) IEEE의 품질 보증 계획서