Index
1. 소프트웨어 품질 개요와 분류
1.1. 소프트웨어 품질 개요
•
품질의 정의
◦
제품이나 서비스가 가지는 수월성에 관한 종합적 특성
◦
생산자 입장
▪
명시된 요구사항을 만족시키는 정도
◦
고객의 입장
▪
고객의 기대나 사용목적에 부합하는 정도
•
소프트웨어 품질
◦
소프트웨어 공학 목표 중 하나
◦
명확히 기술된 요구사항을 만족하고 묵시적인 좋은 품질 특성을 가지고 있어야함
1.2. 품질 관점
•
사용자 관점
◦
제품의 신뢰성, 효율성, 사용 용이성
•
개발자 관점
◦
검증 가능성, 유지보수성, 이식성
•
관리자 관점
◦
프로세스의 생산성과 제어 용이성
1.3. 소프트웨어 품질의 분류
•
내부 특성이 외부 특성에 영향을 줌
◦
외부 특성과 내부 특성이 분명히 구분되는 것은 아님
•
프로세스의 품질이 제품의 품질에 영향을 줄 수 있음
◦
제품과 함께 프로세스의 품질도 중요
•
외부 특성
◦
사용자 관점
◦
실행을 통해 행위를 측정하여 평가 가능
◦
신뢰성, 사용성
•
내부 특성
◦
개발자 관점
◦
개발자가 외부 특성을 개선하고자 할 때 도움을 줌
◦
개발 문서나 코드에 대해 정적을 측정하여 평가
•
제품 특성
◦
제품이 가지는 특성
◦
고객 관점에서 제품이란 고객에게 전달 되는 것
◦
개발자는 요구사항, 설계문서, 소스코드, 사용자 메뉴얼 등을 모두 제품으로 생각함
•
프로세스 특성
◦
체계적인 프로세스가 정외되지 개발 과정에 적용되는 것
◦
프로세스 품질은 소프트웨어 제품 품질에 영향을 줌
◦
프로세스 품질 관리 개선을 위한 노력이 필요함
2. 소프트웨어 제품의 품질 표준
2.1. 제품의 품질 표준 - ISO/IEC 9126
•
소프트웨어 제품의 품질 분류와 메트릭 정의 표준
•
사용자 관점에 따라 제품의 품질 특성을 6가지로 분류
◦
기능성 - 요구사항 만족 능력
◦
신뢰성 - 성능 수준을 유지하는 능력
◦
사용성 - 시스템을 사용하는데 드는 노력과 사용자의 평가
◦
효율성 - 성능 수준과 자원 사이의 관계
◦
유지보수성 - 유지/수정에 얼마나 노력이 드는지
◦
이식성 - 스프트웨어 환경 이식 가능한지?
2.2. 외부 메트릭과 내부 메트릭
•
외부 메트릭 (9126-2)
◦
완성된 소프트웨어를 실행하여 제품의 품질 측정
•
내부 메트릭 (9126-3)
◦
개발 과정에서 나오는 소프트웨어 산출물의 품질 측정
2.3. 사용 품질
•
사용 품질 관련 4가지 특성과 메트릭을 정의함 (9126-4)
◦
실제 사용 환경에서 효율성, 생산성, 안전성, 만족성을 가지고 명시된 목표를 달성하는 소프트웨어 제품의 능력
•
사용자가 느끼는 제품의 실제 효과
•
소프트웨어 자체 특성이 아니라 사용해본 결과를 사용자가 측정
2.4. ISO/IEC 25000
•
SQuaRE
◦
Software product Quality Requirements and Evaluation)
◦
품질 관리
◦
품질 모델
◦
품질 메트릭
◦
품질 요구사항
◦
품질 평가
2.5. 맥콜의 제품 품질 특성
•
11개의 품질 요인 제시
◦
제품 운영
▪
정확성, 신뢰성, 효율성, 무결성, 사용성
◦
제품 개선
▪
유지보수성, 시험성, 유연성
◦
제품 전이
▪
이식성, 재사용성, 상호운영성
•
23개의 품질 기준을 제시 (개발자 관점의 내부 품질 기준)
•
메트릭 제시
◦
품질 기준 정략 측정 방법과 단위
3. 프로세스 품질 표준
3.1. 프로세스 품질 표준
•
품질 목표의 달성을 위해 고품질 소프트웨어의 개발을 유도하는 시스템 필요
•
원칙과 실무지침을 갖춘 성숙한 개발 프로세스가 필요
•
SPICE - ISO/IEC 15504
◦
프로세스 평가 프레임워크
•
ISO/IEC - 12207
◦
생명주기 프로세스의 공통 프레임워크
•
CMMI
◦
조직 프로세스 역량 성숙도 평가 및 개선 모델
•
ISO 9001
◦
조직 품질 경영 체제 도입 & 프로세스 품질 인증 획득을 위한 모델
3.2. ISO 9000 시리즈
•
품질 경영을 위한 기본 요소를 규정하고 실천을 위한 활동 지침 제시
•
ISO 9000
•
ISO 9001 - 품질 관리 시스템 요건 설명
•
특징
◦
프로세스 평가보다 품질 관리 자체에 중점
◦
평가 등급화 X
◦
ISO 9001 인증 여부만 결정
3.3. CMMI
•
조직의 개발 프로세스 역량과 성숙도를 평가하는 모델로 프로세스 개선을 위한 프레임워크
•
프로세스 구축, 평가, 개선을 위한 프레임워크 제공
•
ISO 9001과 ISO 15504(SPICE)의 관심사를 포함한 통합 모델
•
모델 구조
◦
단계적 모델 (성숙도 수준 평가)
▪
조직 전체의 프로세스 성숙도를 1~5 수준으로 평가
◦
연속적 모델 (역량 수준 평가)
▪
20여 개의 실무 영역에 대해 각각 0~3사이의 등급 부여
3.4. CMMI 모델 구성 요소
•
개발을 위한 CMMI-DEV는 20개의 실무영역(PA)로 구성됨
◦
평가 영역이 여러개의 실무 영역으로 구분됨
◦
실무영역은 4개의 범주, 9개의 역량 영역(CA)로 분류됨
◦
범주 - 이행(Doing), 관리(Managing), 지원(Enabiing), 개선(Improving)
3.5. CMMI와 평가
•
연속적 모델 (역량 수준 평가)
◦
20여 개의 실무 영역에 대해 각각 0~3사이의 등급 부여
◦
실행되지 않음(incompleted) / 초기(initial) / 관리됨(managed) / 정의됨(defined)
•
단계적 모델 (성숙도 수준 평가)
◦
조직 전체의 프로세스 성숙도를 1~5 수준으로 평가
◦
수준 1 - 초기 상태 (Initial)
◦
수준 2 - 관리됨 (Managed)
▪
기본적인 프로젝트 관리 프로세스가 구축되어 관리됨
◦
수준 3 - 정의됨 (Defined)
▪
조직 특성에 맞는 표준 프로세스가 존재
◦
수준 4 - 양적으로 관리됨 (Qauntitatively Manged)
▪
프로젝트 활동이 정량적으로 관리되고 통제됨
◦
수준 5 - 최적화 됨 (Optimizing)
▪
지속적인 개선 활동이 정착됨
4. 소프트웨어 품질 보증
4.1. 소프트웨어 품질 보증(SQA)
•
소프트웨어 품질 요구가 만족됨을 보증하는 품질 관리 활동
◦
기대했던 기능과 성능을 보일것임을 고객에게 보증하는 것
•
품질 보증 활동 예
◦
개발팀이 준수해야하는 제품과 프로세스의 표준을 정학 시스템에 요구되는 품질 속성 정의
4.2. 품질 보중 계획
•
SQA 작업 수행을 위한 로드맵으로 품질 보증 프로세스와 방법을 정하는 일
◦
적정 시점에 산출물들의 만들어지는지 확인
◦
품질을 만족하는지 검토
•
SQA 계획의 구성
◦
품질 보증 조직의 구성
◦
제품과 품질 프로세스 표준
◦
검토와 감사 방법
◦
테스트 계획과 절차
◦
형상 관리 방법, 위험 관리 방법 등
4.3. 품질 제어 (QC)
•
SQA
◦
소프트웨어 테스트
◦
소프트웨어 형상 관리
◦
품질 제어
•
품질 제어
◦
개발 프로세스, 코드 및 관련 문서가 품질 보증 절차에 따라 수행되고 표준을 따르며 품질 목표를 ㄹ만족하도록 필요한 활동을 취하는 것
◦
검토를 통해 결함을 제거하는 작업
•
cf) 품질 제어와 품질 보증
◦
품질 제어 - 결함 발견 하고 수정하는 것이 목표, 제품을 대상
◦
품질 보증 - 사전 예방, 프로세스를 대상
4.4. 확인과 검증 (V&V)
•
요구사항 명세서의 검토, 설계 문서와 코드의 검사, 프로그램 테스트를 모두 포함하는 개념
•
확인 (Verification)
◦
소프트웨어가 명세서와 일치하는지 검사하는 것
•
검증 (Validation)
◦
소프트웨어가 고객의 기대를 충적하는지 검사하는 것
•
요구사항이 잘못 작성된 경우. 요구사항은 만족하지만 고객의 기대를 만족하지 못하는 경우가 있음
•
정적인 검토 방법과 동적인 소프트웨어 테스트가 보완적으로 사용
4.5. 검토
•
정적 테스트
◦
프로그램을 실행하지 않고 검토
◦
정적 분석 도구를 사용하여 분석 가능
◦
소프트웨어 요소가 요구 명세서와 일치하는 지 확인
•
검토 방법
◦
공식 기술 검토 (FTR)
▪
검토 공식적 회의
◦
인스펙션 (Inspection)
▪
FTR 전에 작성자가 아닌 다른 동료나 전문가 팀이 검토
▪
오류 발견이 초점
▪
설계 문서나 코드를 요구사항이나 표준과 비교 검사하여 오류를 찾아내는 조직화되고 형식을 갖춘 검토 방법
◦
코드 워크스루 (Code Walkthrough)
▪
코드상의 경로를 따라가면서 결함을 찾음
▪
작성자 본인이 다른 구성원가 질의 응답
5. 신뢰도
5.1. 신뢰도 정의
•
의도된 기능을 고장없이 실행할 수 있는 프로그램 능력
◦
고장 없이 정확하게 작동할 확률
•
신뢰도는 사용 환경과 고장의 결과에 따라 다르게 인식될 수 있음
◦
내재된 결함이 있더라도 고장으로 연결되지 않을 수 있음
◦
고장의 결과가 심각하지 않다면 신뢰성 있다고 할 수 있음
5.2. 신뢰도 메트릭
•
MTTF (Mean Time To Failures)
◦
가동되어 고장이 발생할 때까지의 평균 시간 (평균 수명)
◦
고장의 복구를 고려하지 않음
◦
ex) MTTF = (a1 + a2 + a3) / 3
•
MTBF (Mean Time Betwween Failures)
◦
고장이 수리되어 가동된 후 다시 고장이 일어날때 사이의 평균 간격 (MTTF)
◦
고장의 복구 고려
◦
또는 MTTF에 평균 복구 시간 (MTTR)을 더한 것으로 정의함
◦
ex) MTBF - ((a1 + a2 + a3) + (r1 + r2 + r3)) / 3
•
AVAIL (가용성)
◦
시스템이 가동될 확률. 전체 시간에서 가용한 시간의 비율
◦
논스톱 시스템의 신뢰도 측정에 사용
◦
가용성을 높이려면 고장 발생 후 빠른 복구가 필요함
◦
AVAIL = MTBF / (MTBF + MTTR) = (a1 + a2 + a3) /(a1 + a2 + a3 + r1 + r2 +r3)
•
ROCOF (Rate of Occurances Of Failures)
◦
고장의 발생 비율
◦
규칙적이고 빈번한 서비스 요청이 들어오는 시스템의 신뢰도 측정
◦
ex) 예약 시스템의 ROCOF가 0.002라면 1000회 요청에서 2회의 오류 발생