프로세스 품질의 종류
ISO/IEC 12207
- ISO/IEC 12207 소프트웨어 생명주기 프로세스는 프로세스 중심의 각 활동 및 역할에 대해 기술
- 소프트웨어와 관련된 조직/사람, 소프트웨어 획득자, 공급자, 개발자, 운영자, 유지보수자, 품질보증 관리자, 사용자 등 각자의 입장에서 수행해야 할 일을 정의, 지속적으로 개선시키기 위한 활동
기본 생명주기 프로세스
| 프로세스 | 내용 |
| 획득 | 소프트웨어를 획득하는 획득자 또는 획득조직이 수행할 활동을 정의 |
| 공급 | 소프트웨어를 공급하는 공급자 또는 공급조직이 수행할 활동을 정의 |
| 개발 | 소프트웨어를 정의하고 개발하는 개발자 또는 개발조직이 수행할 활동을 정의 |
| 운영 | 사용자를 위하여 실제 환경에서 컴퓨터 시스템의 운영 서비스를 제공하는 운영자 또는 운영조직이 수행할 활동을 정의 |
| 유지보수 | 소프트웨어의 유지보수 서비스를 제공하는 유지보수자 또는 유지보수조직이 수행할 활동을 정의 |
지원 생명주기 프로세스
| 프로세스 | 내용 |
| 문서화 | 생명주기 프로세스에 의하여 산출되는 정보의 기록을 위한 활동 정 |
| 품질보증 | 소프트웨어 제품 및 프로세스가 명시된 요구사항에 적합하여 이미 수립된 계획에 따르고 있음을 객관적으로 보증하기 위한 활동을 정의 |
| 형상관리 | 구성관리 활동을 정의 |
| 검증 | 소프트웨어 프로젝트에 따라 다양한 깊이로 소프트웨어 제품을 검증하기 위한 활동을 정의 |
| 확인 | 소프트웨어 프로젝트의 소프트웨어 제품을 확인하기 위한 활동을 정의 |
| 문제해결 | 개발, 운영, 유지보수 또는 다른 프로세스 활동 수행 중에 발견된 부적합 사항을 포함한 문제점을 분석, 제거하기 위한 프로세스를 정의 |
| 합동검토 | 활동의 상태 및 제품을 평가하기 위한 활동을 정의 |
| 감사 | 요구사항, 계획 및 계약에 대하여 적합성을 결정하기 위한 활동 정의 |
조직 생명주기 프로세스
| 프로세스 | 내용 |
| 기반구조 | 생명주기 프로세스의 기본구조를 확립하기 위한 기본 활동을 정의 |
| 관리 | 생명주기 프로세스 동안 프로젝트 관리를 포함한 기본적인 관리 활동을 정의 |
| 개선 | 조직 생명주기 프로세스의 확립, 측정, 통제, 개선을 위해서 수행하는 기본 활동을 정의 |
| 훈련 | 적절하게 훈련된 요원을 제공하기 위한 활동을 정의 |
CMM (Capability Maturity Model)
- CMM은 1992년 미국방성의 지원으로 설립된 카네기멜론 대학의 소프트웨어공학 연구소(SEI, Software Engineering Institute)가 프로세스 성숙도를 위한 프레임워크로 제시한 모델
- 개발 전 과정의 프로세스의 기능, 성능 수준, 조직 구성, 인력 등을 종합적으로 평가
목적
- 현재의 프로세스 상태를 벤치마킹하고 어떤 부분을 향상시킬 것인지 전략을 선택하여 프로세스를 개선하려는 소프트웨어 개발 조직에 도움이 되기 위하여 제정
- 고객 관점: 개발 업체의 능력과 수준을 검증하는 수단
- 개발 업체 관점: 업무 프로세스 개선방향, 내용을 결정하는 객관적 검증 수단
특징
- 소프트웨어 개발 공정 및 조직의 성숙도를 초기, 반복기능, 정의, 관리, 최적화 등 5개 등급으로 분류하여 프로세스 개선활동을 지원
- CMM 모델의 각 프로세스는 영역별 활동 조건, 목표, 실행, 제도화, 활동, 기반구조 등을 설명함l 프로세스 성숙도가 높을수록 제품과 서비스의 품질도 향상된다는 이론
CMM의 5단계 (프로세스 성숙단계)
- 수준1: 초기
- 프로세스가 거의 정의되어 있지 않음
- 프로세스의 성과를 예측할 수 없는 상태
- 수준2: 반복
- 기초적인 project 관리를 위한 process가 확립되어 있어서 비용, 일정, 기능의 추적 가능
- 기초적인 통계관리가 가능한 상태
- 수준3: 정의
- 소프트웨어 프로세스가 문서화되고 표준화되어서 이것을 조직 내에서 표준으로 통합할 수 있고 그룹 간 코디네이션이 이루어짐
- 프로세스가 잘 정의/이해되고 프로젝트 관리도 실행되는 상태·표준화, 일관된 프로세스
- 수준4: 관리
- 소프트웨어 프로젝트 및 프로세스의 품질을 측정 및 분석하고 수정함으로써 품질개선, 프로세스 개선이 가능한 상태
- 프로세스와 제품의 정량적 관리․평가
- 수준5: 최적화
- 프로세스 관리를 통한 질적·양적으로 지속적으로 개선되는 프로세스
- 결함을 방지할 목적으로 프로세스의 약점과 강점을 미리 파악하는 수단을 갖춤
SPICE(ISO/IEC 15504)
- SPICE(Software Process Improvement and Capability dEtermination)는 소프트웨어 프로세스 평가를 위한 국제 표준을 제정하는 국제적인 표준화 프로젝트
- ISO 12207 소프트웨어 생명주기 프로세스를 참고
SPICE의 3가지 목적
- 개발 기관이 프로세스 개선을 위하여 스스로 평가
- 기관에서 정한 요구조건을 만족하는지 개발 조직이 스스로 평가
- 계약을 맺기 위하여 수탁 기관의 프로세스를 평가
SPICE의 프로세스 수행 단계
- Level 0: 불완전(Incomplete) 수준: 프로세스 목적 달성의 전반적인 실패단계
- Level 1: 수행(Performed) 수준: 프로세스의 목적이 전반적으로 이루어진 단계
- Level 2: 관리(Managed) 수준: 프로세스의 계획 및 추적이 수행되는 문서화 단계
- Level 3: 확립(Established) 수준: 소프트웨어공학 기본 원칙에 정의된 프로세스를 수행하고 관리
- Level 4: 예측(Predictable) 수준: 목표 달성을 위해 정의된 프로세스가 일정한 통제 하에 일관되게 수행
- Level 5: 최적화(Optimizing) 수준: 현재와 미래의 경영목표에 맞는 최적화된 프로세스를 수행
프로세스 영역
- 고객・공급자 프로세스: 소프트웨어를 개발하여 고객에게 제공하고 소프트웨어를 정확하게 운용하고 사용하도록 지원하기 위한 프로세스
- 엔지니어링(공학) 프로세스: 시스템과 소프트웨어 제품을 개발하는 모든 프로세스
- 지원 프로세스: 문서화, 형상관리, 품질보증, 검증, 확인, 검토 등 개발 활동을 지원하는 프로세스
- 관리 프로세스: 일반적인 소프트웨어 프로젝트에서 일어나는 관리 활동으로, 프로젝트 관리, 품질관리, 위험관리 등의 프로세스
- 조직 프로세스: 조직의 업무 목적을 수립하고 조직이 업무 목적을 달성하기 위하여 도움을 주는 프로세스
SPICE 이차원 모델
CMMi (Capability Maturity Model integration)
- CMM의 여러 모델 간에 존재하는 상이한 용어와 평가 방법에 대한 통합이 필요
- CMM의 개발 산출물이 ISO/IEC 15504(SPICE)와 호환성을 갖도록 하기 위함
- 소프트웨어 프로세스 성숙도 모형인 CMM에서 소프트웨어, 시스템, 제품을 모두 지원하는 프레임워크로 확장된 모델
성숙도 단계
- ① 실행되지 않음(not performed, 0단계): 프로세스 영역과 관련된 하나 이상의 목표가 만족되지 않음
- ② 실행됨(performed, 1단계): 프로세스 영역과 관련된 목표가 만족되고, 모든 프로세스에 대해 실행된 작업 범위가 명백하게 나타나고 팀 구성원 사이에 전달
- ③ 관리됨(managed, 2단계): 각 프로세스가 사용되어야 할 때를 정의하는 조직의 정책이 존재
- ④ 정의됨(defined, 3단계): 조직의 표준화와 프로세스의 전개에 초점을 맞춤
- ⑤ 정량적으로 관리됨(quantitatively managed, 4단계): 수집된 프로세스와 제품 측정치를 활용하여 프로젝트 활동이 정량적으로 관리 통제되고 성과 예측이 가능
- ⑥ 최적화됨(optimizing, 5단계): 지속적인 개선에 치중
단계적(staged) CMMi 모델
- 소프트웨어 CMM 모델에 적합하며 조직의 시스템 개발과 관리 프로세스가 평가되어 1~5의 성숙도 수준을 할당
- 각 수준에서 달성되어야 하는 목표를 기술
연속적(Continuous) CMMi 모델
- 소프트웨어 SPICE 모델에 적합하고, 더 세분화된 분류가 가능함
- 24개의 프로세스 영역에 대해 0부터 5까지의 등급을 부여
소프트웨어 품질관리
- 소프트웨어의 문제점을 최대한 많이 조기에 발견하여 발견된 문제들을 시정 및 조치하는 것
소프트웨어 품질관리 단계
- 계획단계 (품질계획수립): 적용할 품질의 표준을 식별하고 적용할 방법을 결정하는 활동
- 실행단계 (품질보증활동): 소프트웨어 제품과 요구사항이 일치하는지의 검토를 제3자의 입장에서 수행
- 통제단계 (품질통제활동): 소프트웨어의 개발, 운영, 유지보수에 있어 자체적으로 품질활동을 수행
검토회의 (Review)
- 참여자: 검토 책임자, 모든 검토자, 제작자
- 소프트웨어 품질보증의 대표적인 품질관리 활동
- 인간에 의해 진행되는 에러 검출 과정
워크스루 (Walkthrough)
- 개발자가 소집한 전문가들에 의해 개발자의 작업이 비공식적으로 검토
- 소프트웨어의 특정 부분을 검토하는 데 목적을 두며, 상세설계 부분에 대해 검토
검열 (Inspection)
- 워크스루를 좀 더 구조적이고, 체계적으로 발전시킨 공식적인 검토회의
- 인스펙션 과정: 계획 > 사전교육 > 준비 > 인스펙션 회의 > 수정 > (다시 계획 or) 후속조치
소프트웨어 매트릭스
- 소프트웨어가 보유하고 있는 특성, 품질 혹은 속성의 크기나 정도의 계량적인 척도
- 소프트웨어 매트릭스는 일정계획, 비용예측, 품질 보증, 위험성 분석 등에 사용
- 소프트웨어 특성을 이용하여 규모와 복잡도를 산정하는 방식
측정 방법
- 직접 측정(direct measures): 비용, 실행속도, LOC(lines of code), 노력, 메모리 크기, 오류의 수(결함 수)
- 간접 측정(indirect measures): 기능성(functionality), 효율성(efficiency), 품질(quality), 신뢰성(reliability), 복잡성(complexity), 유지보수성(maintainability) 등
McCabe의 소프트웨어 복잡도
- 제어 흐름에 대한 그래프에서 영역의 수를 계산하여 품질을 측정하는 방법
- McCabe(1976)가 제안한 순환복잡도(Cyclomatic Complexity)
- IF-THEN-ELSE, DO WHILE, DO UNTIL, CASE 등의 의사결정 개수
- AND, OR, NOT 등의 조건수로 표현
- McCabe의 복잡도에 따른 소프트웨어 품질 평가
- 복잡도가 5 이하：매우 간단한 프로그램
- 복잡도가 5∼10：매우 구조적이며 안정된 프로그램
- 복잡도가 20 이상：문제 자체가 매우 복잡하거나 구조가 필요 이상으로 복잡한 프로그램
- 복잡도가 50 이상：매우 비구조적이며 불안정한 프로그램
신뢰성 (Reliability)
- 소프트웨어 제품의 품질을 평가하는 척도
- 일정 시간 동안에 주어진 조건 하에서 원하는 기능을 고장 없이 실행할 수 있는 프로그램 능력
신뢰성을 위한 프로그래밍 기법
- 결함 회피 (fault avoidance)
- 결함 허용 (fault tolerance)
- 결함 복구 (fault recovery)
- 예외 처리 (exception handling)
- 결함 방지 (fault prevention)
- 방어적 프로그래밍 (defensive programming)
