소프트웨어의 품질을 어떻게 보장 받을 수 있을까 ? 소프트웨어 품질경영 설명하기 전 품질 높은 소프트웨어란 무엇인가 ? 소프트웨어의 품질을 어떻게 보장 받을 수 있을까 ? 품질보증(Quality Assurance)이란, 소프트웨어의 프로세스와 제품에 대 한 품질을 관리하고 향상시키는 작업이다. 본 강의에서 무엇을 얻을 것인가 ? 첫째, 품질이란 둘째, 품질 보증 활동 셋째, 제품 품질 넷째, 소프트웨어 검사(Inspection)

1. 품질 개념 01 품 질 개 념

사용자가 원하는 기능을 제공하여 유용하게 사용 할 수 있고 신뢰상이 높고 필요에 따라 계속 발전하는 소프트웨어를 말한다. 품질이란 ? 1. 품질 개념 좋은 품질의 소프트웨어란 ? 첫째, 사용자 관점 사용자가 원하는 기능을 제공하여 유용하게 사용 할 수 있고 신뢰상이 높고 필요에 따라 계속 발전하는 소프트웨어를 말한다. 둘째, 개발자 관점 좋은 설계 구조를 가지며 쉽게 유지보수 할 수 있고, 테스트가 용이하고 환경에 맞도록 변경 가능한 소프트웨어를 말한다. 품질 측정 가시화의 어려움 - 구체적으로 원하는 수준의 품질인지를 판단하는 것 - 다른 소프트웨어와의 품질을 비교하는 것

둘째, 협의의 개념 : 결함 없는 소프트웨어, 요구사항에 맞는 소프트웨어 광의의 개념 품질 의미 1. 품질 개념 소프트웨어 품질의 2가지 의미 - 소프트웨어 품질 첫째, 광의의 개념 : 고객 만족 둘째, 협의의 개념 : 결함 없는 소프트웨어, 요구사항에 맞는 소프트웨어 광의의 개념 정확하고 성능이 좋은 것은 물론이며 고객이 원하는 바로 그것, 탁월성을 보 여서 사용하면서 만족을 얻을 만한 것이 되어야 한다. 예 : 토탈상품, 시그마운동 등 협의의 개념 개발자의 입장으로 국한 할 수 있고 개발자의 생각하는 품질의 개념은 SW가 요구를 만족 하느냐 못하느냐 여부를 판단하는 것

(6)시그마운동이란 ? (6) 시그마 운동 - 초일류기업 기준으로 만들어짐 1. 품질 개념 (6)시그마운동이란 ? - 초일류기업 기준으로 만들어짐 - 모토로라 근무하던 Mikel J. Harry의해 1987년 창안 - 전자기기 근무 중, 품질을 획기적으로 향상 방법을 생각하던 중에 “통계 지식”을 활용하자는 착안 - 통계적 기법과 70년대 말 Robert W. Galvin의 품질개선운동과 결합하 여 탄생한 것이 (6)시그마 운동이다. - 6시그마운동은 Texas Instrument(1988), ABB(1993), GE(1995) IBM, SONY, NOKIA 등에서 성공적으로 적용하였음 - 그리스문자인 시그마는 “통계적 용어”로는 표준편차를 의미하며 Error 나 Miss의 발생확률을 가르키는 통계학적 용어

(6)시그마운동이란 ? (6) 시그마 운동 - 통계학적으로 백만 번에 3-4회 오류가 발생하는 수준을 6시그마로 규정 1. 품질 개념 (6)시그마운동이란 ? - 통계학적으로 백만 번에 3-4회 오류가 발생하는 수준을 6시그마로 규정 - 5시그마는 백만 번에 233회 - 4시스마는 백만 번에 6,210회 - 6시그마는 실제 업무상 실현 가능한 가장 낮은 오류로 인정된다. - 경영혁신 수단으로서 6시그마 운동은 제품설계 제조 및 서비스의 오류를 최소화해 규격상한과 하한이 품질 중심으로 부터 6시그마로 하겠다는 목 표를 가짐 - 통계용어에 불과한 6시그마를 기업경영이 도달해야 할 목표치로 설정하 는 것이 6시그마운동의 출발점임 - 6시그마의 목표달성을 위해 필요한 도구는 “6시그마기법”, 그 기법을 활용해 회사 전체가 하나가 되어 추진하는 활동을 “6시그마 활동”이라 고 부름

품질 품질 요소 유지보수성 융통성 테스트 용이성 이식성 재사용성 상호운용성 제품 개정 제품 전환 제품 운용 정확성 신뢰성 1. 품질 개념 유지보수성 융통성 테스트 용이성 이식성 재사용성 상호운용성 제품 개정 제품 전환 품질 제품 운용 정확성 신뢰성 효율성 통합성 사용성

품질 요소 소프트웨어 품질 특성의 3가지 차원 1. 품질 개념 커뮤니케이션 사용성 정확성 제품 운용 신뢰성 품 질 제 어 를 위 한 메 트 릭 스 일관성 효율성 장치효율성 접근가능성 재사용성 완전성 구조적 유지보수성 제품 개정 간결성 이식성 장치독립성 테스트용이성 자기실명적 추상적

품질 요소 1. 품질 개념 ISO9126의 소프트웨어 (제품) 품질 특성(국제표준)

소프트웨어 특성과 품질관계 소프트웨어 특성에 따라 품질에 대한 요구는 매우 다르다. 1. 품질 개념 소프트웨어 특성에 따라 품질에 대한 요구는 매우 다르다. 예제 : 증권거래 시스템 : 기능성, 신뢰성, 사용성, 변경용이성 예제 : 임베디드 시스템 : 신뢰성, 효율성 소프트웨어 유형에 따른 중요도가 다른 사례

소프트웨어의 결함이 인명과 재산에 치명적인 시스템 소프트웨어 특성과 품질관계 1. 품질 개념 소프트웨어의 결함이 인명과 재산에 치명적인 시스템 - 신뢰성, 정확성, 테스트 용이성, 예 : 원자력 발전소, 방사선 치료기 긴 수명을 요구하는 시스템 - 유지보수성, 이식성, 융통성, 예 : 전자정부시스템, 전자도서관 실시간 응용 분야의 소프트웨어 - 효율성, 신뢰성, 정확성, 예 : 통신시스템, 유도 미사일 보안이 중요한 응용시스템 - 다른 시스템과의 연동이 필요한 상호운용성, 예 : 은행결재시스템, 증권거래 시스템

소프트웨어 특성과 품질관계 제품 품질 프로세스 품질 과거에는 제품의 품질을 중요시 했으나 현재는 프로세스의 품질을 중시한다. 1. 품질 개념 제품 품질 - 소프트웨어 자체의 품질을 의미한다. - 수돗물 비교 : 수돗물 자체의 품질, 즉, 맛, 색깔, 유해성분 등… - 일반적으로 생각하는 품질을 의미한다. 프로세스 품질 - 소프트웨어를 개발하는 과정의 품질을 의미한다. - 수돗물 비교 : 수돗물을 전달하는 파이프의 청결도, 정수장의 위치 등… - 과정의 품질이 좋지 않으면 궁극적으로 제품의 품질이 나쁘다는 인식에서 출발한다. - 프로세스의 품질이 높으면, 소프트웨어에 내재된 잠재적인 오류를 줄일 수 있다. 과거에는 제품의 품질을 중요시 했으나 현재는 프로세스의 품질을 중시한다.

제품 품질 소프트웨어 자체를 의미하는지 ? 소프트웨어를 대하는 입장에서 품질의 정의가 달라진다. 1. 품질 개념 소프트웨어 자체를 의미하는지 ? 소프트웨어를 대하는 입장에서 품질의 정의가 달라진다. - 구매자 : 외부로 나타나는 “품질요소”로 이해한다. 예(오류횟수, 판매횟수 ..) - 유지보수 엔지니어 : 제조과정에 내재된 내부 특성을 중시한다. 예(함수, 재사용 가능한가 ..) 관련 표준 : ISO 9126, ISO 14598

개발과정이 소프트웨어 품질에 많은 영향을 준다는 주장 제품 품질 1. 품질 개념 개발과정이 소프트웨어 품질에 많은 영향을 준다는 주장 개발 및 유지보수하는 프로세스의 품질이 제품 자체의 품질 못지 않게 중요하다는 입장 향상 방안 - 특정 오류가 언제 어디서 발견되는가 ? - 어떻게 하면 개발 과정에 오류를 조기에 발견 할 수 있는가 ? - 어떻게 하면 오류에 대한 내성이 있는 시스템, 즉 오류가 소프트웨어를 정지 시키는 확률이 적은 시스템을 만들 수 있는가 ? - 프로세스가 좋은 품질을 보장하는 더 효율적이며, 효과적으로 다룬 방법론이 있는가 ? 관련 표준 : ISO SPICE, 미국방성의 CMM

2. 품질보증 활동 02 품질보증 활동

품질 보증 활동의 내용 제품 품질 조직 : 품질 보증을 수행하는 조직의 구성과 역할은 ? 2. 품질보증 활동 품질 보증 활동의 내용 조직 : 품질 보증을 수행하는 조직의 구성과 역할은 ? 계획 : 품질 보증 활동을 어떻게 계획 할 것인가 ? 작업 : 품질 보증은 구체적으로 어떤 작업을 통해 수행할 것인가 ?

개념 : 소프트웨어 제품이나 아이템이 정해진 요구에 적합하다는 것을 보장하는데 품질 보증 활동 2. 품질보증 활동 개념 : 소프트웨어 제품이나 아이템이 정해진 요구에 적합하다는 것을 보장하는데 필요한 계획적이고 체계적인 활동 (IEEE 610, 1991) 일반적인 품질 보증 작업 1. 소프트웨어 품질 확보를 위한 요구 제정 (각종 요구사항 제정 및 관리에 초점) 2. 소프트웨어를 개바르 운용, 유지보수하기 위한 방법론, 프로세스, 절차의 제정과 실행 (개발과정을 관리하는데 초점) 3. 소프트웨어 제품이 품질을 평가하고 관련 문서, 프로세스, 품질에 영향을 미치는 활동을 평가하기 위한 방법론, 프로세스, 절차의 제정과 실행 (제품 자체의 품질 관리에 초점)

품질 보증 활동 2. 품질보증 활동

소프트웨어 품질 보증 활동과 개발 조직의 구분 필요 품질 보증 활동 - 조직 2. 품질보증 활동 소프트웨어 품질 보증 활동과 개발 조직의 구분 필요 1. 품질 평가와 관리를 위한 객관적인 시각 요구 2. (기준 이하의) 작업의 반복 또는 개선 유도 소프트웨어 품질 보증 작업의 활동 1. 관리적 활동 : 개발 조직의 표준화 방법론을 잘 따르도록 하는 것 2. 기술적 활동 : 방법론을 잘 정의 하는 것

품질 보증 활동 - 계획 2. 품질보증 활동 소프트웨어 품질 보증 활동의 시작

품질 보증 활동 - 작업 2. 품질보증 활동

3. 프로세스 품질 03 프로세스 품질

프로세스 품질 내용 소프트웨어 프로세스 평가 모델 3. 프로세스 품질 - 미국 정부 회계국 발표 : 1991 전세계의 대형 프로젝트 성공률이 1% - 프로세스 : 개발을 위한 질서 있고 경험에 의한 규칙있는 인력.기술.절차.도구가 합쳐져 통합된 작업 - 프로세스에 의해서 소프트웨어의 품질을 높일 수 있다. - “소프트웨어 시스템의 품질은 그것을 개발하는데 사용되는 프로세스의 품질에 좌우되다. (험프리) 소프트웨어 프로세스 평가 모델 - 미 국방성의 CMM - IEEE SPICE

CMM (Capability Maturity Model) 3. 프로세스 품질 배경 - 1992sus 미국방성의 지원으로 설립된 CMU의 SEI 연구소가 제시 - 1998년 버전 2.0으로 발전 목적 - 현재의 프로세스 상태를 벤치마킹하고 어떤 부분을 향상 시킬 것인지를 전략을 선택하여 프로세스를 개선하려는 소프트웨어 개발 조직에 도움을 주기 위함 특징 - 안정된 작업에 초점을 두어 공격적으로 활동함으로써, 개발 조직의 계속적인 프로세스 향상 도모 - 소프트웨어 엔지니어링 및 관리를 조직에 정착 사용방법(이유) 2가지 -미래의 고객이 소프트웨어 공급자의 강점과 약점 파악 - 개발자 스스로 프로세스 능력 평가 후 개선방향 설정

CMM 레벨 종류와 주요 프로세스 영역 3. 프로세스 품질

소프트웨어 개발 과정이 임시 방편적이며 무질서한 상태이다. 프로세스가 정확히 정의되어 있지 않고 개인의 능력에 의존한다. CMM 레벨 1 : 초보단계(Initial) 3. 프로세스 품질 소프트웨어 개발 과정이 임시 방편적이며 무질서한 상태이다. 프로세스가 정확히 정의되어 있지 않고 개인의 능력에 의존한다. 소프트웨어 개발이나 유지보수를 위한 개발 조직의 환경이 불안하다. 조직 내에 관리 부재로 소프트웨어 품질 손상 우려가 있다. 심각한 경우 계획된 절차를 뛰어넘어 코딩과 테스트 작업으로 전환된다. 납기일을 맞추기 위하여 프로세스의 품질 보증 작업을 무시한다. 프로세스의 입력과 과정이 정해져 있지 않아 작업 결과의 예측이 불가능하다. 유사한 작업에 대한 프로젝트가 반복하여 진행되더라도 개발 생산성이나 품질에 큰 차이가 난다.

CMM 레벨 2 : 반복단계 (Repeatable) 3. 프로세스 품질 기본적인 프로젝트 관리 프로세스를 확립한다. 비용 일정 기능에 대한 예측과 추적이 가능하다. 요구되는 프로세스 원칙들이 지켜져서 같은 문제에 대한 개발이 반복될 때 쉽게 성공이 가능하다. 조직은 소프트웨어 프로젝트 관리를 위한 정책을 입안하고 절차들을 생행한다. 새 프로젝트의 계획과 관리는 개인적인 경험보다는 과거의 데이터에 의존한다. 소프트웨어 프로젝트를 효과적으로 관리하는 프로세스가 전사적으로 잘 정착되어 있다. 프로젝트 관리자는 소프트웨어 비용과 일정, 기능을 추적할 수 있고 문제가 발생하면 바로 인식한다. 소프트웨어 요구와 이를 만족하기 위하여 개발된 결과물은 반드시 테크하고 일치 하는지를 확인한다. 소프트웨어 프로젝트 표준이 잘 정의되어 있고 조직이 표준을 잘 준수 하고 있는지 확인한다. 원리 원칙을 준수한다.

관리와 엔지니어링을 위한 소프트웨어 프로세스가 문서화되어 규격으로 만들어져 있다. CMM 레벨 3 : 정의 단계 (Defined) 3. 프로세스 품질 관리와 엔지니어링을 위한 소프트웨어 프로세스가 문서화되어 규격으로 만들어져 있다. 기관 전체가 표준 소프트웨어 프로세스를 따른다. 기관 내에 소프트웨어 엔지니어링 프로세스 그룹이 조직되어 소프트웨어 프로세스를 전담한다. SPEG는 스탭과 관리자를 위하여 부여된 역할을 잘 수행하기 위한 지식과 기술을 가르치는 교육도 담당한다. 표준화와 일관성이 잘 지켜진다. 소프트웨어 엔지니어링과 관리 활동이 안정적이며 성공적으로 되풀이 될 수 있다. 개발공정, 비용, 일정, 기능이 통제되고 있고 소프트웨어 품질에 대하여 추적이 가능하다. 이러한 프로세스 능력은 소프트웨어 프로세스가 잘 정의되고 전체 조직이 작업과 역할, 의무를 잘 이해하고 있기 때문에 가능하다.

소프트웨어 프로세스와 제품의 품질에 대한 자새한 측정이 이루어진다. CMM 레벨 4 : 관리 단계 (Managed) 3. 프로세스 품질 소프트웨어 프로세스와 제품의 품질에 대한 자새한 측정이 이루어진다. 즉 소프트웨어 프로세스와 제품이 정량적으로 이해되고 통제된다. 조직은 소프트웨어 제품과 프로세스에 대한 정량적인 목표를 세운다. 제품에서의 모든 작업은 생산성과 품질 측면에서 측정하고 프로젝트에서 정의된 프로세스에 대하여 데이터를 모으고 분석하여 소프트웨어 프로세스 데이터베이스에 저장한다. 잘 정의되고 일관된 측정 방법에 의하여 소프트웨어 프로세스를 측정한다. 프로세스 수행성과의 편차를 허영하는 범위 안으로 줄여 제품과 프로세스를 관리한다. 프로세스가 측정되고 정해진 범위 내에서 이루어지므로 프로세스 성과를 정확히 예측할 수 있다. 기관은 이를 통하여 프로세스와 제품에 대한 품질이 추세를 예측한다. 만일 정해진 범위를 벗어 날 때는 바로 잡기 위한 조치를 취하여 품질 예측 가능성이 높아진다.

프로세스에 대한 정량적인 피드백과 획기적인 아이디어와 기술로 지속적인 프로세스를 향상 시킨다. CMM 레벨 5 : 최적 단계 (Optimizing) 3. 프로세스 품질 프로세스에 대한 정량적인 피드백과 획기적인 아이디어와 기술로 지속적인 프로세스를 향상 시킨다. 프로젝트 프로세스의 생산성 향상을 위하여 오래된 기술과 방법론은 적절히 퇴출 시킨다. 전체 조직이 지속적인 프로세스 개선을 위하여 초점을 맞춘다. 결함을 방지할 목적으로 프로세스의 약점과 강점을 미리 파악하는 수단을 가지고 있다. 소프트웨어 프로세스의 효율성에 대한 데이터를 사용하여 새로운 기술의 도입과 소프트웨어 프로세스의 변경에 의한 비용과 수익을 분석한다. 최고의 소프트웨어 엔지니어링 기술을 찾아내고 이를 이용하여 혁신을 추구한다. 소프트웨어 프로세스를 평가하며 결함이 재발되는 것을 방지하며 노하우를 다른 프로젝트에 전수한다. 개발 기관이 프로세스 능력의 범위를 향상 시키기 위하여 계속 노력하며 이를 통하여 프로젝트 단위 프로세스 성과도 향상된다.

가장 기본적이고 중요한 기반구조 및 활동을 나타낸다. 예) 프로젝트 계획 영역의 핵심 실무 활동 CMM 핵심 실무 활동(Key Practices) 3. 프로세스 품질 필요한 업무 활동을 자세하게 표현한다. 가장 기본적이고 중요한 기반구조 및 활동을 나타낸다. 예) 프로젝트 계획 영역의 핵심 실무 활동 - 비용산정, 라이프사이클의 정의,일정과 투입 자원에 대한 계획의 문서화 핵심 실무 활동에 대하여 CMM은 활동 항목만 나열하고 있으며 이를 어떤 방법으로 수행하여야 하는지는 언급하지 않고 있다.

Software Process Improvement and Capability dEtermination SPICE 3. 프로세스 품질 Software Process Improvement and Capability dEtermination 소프트웨어 프로세스 평가를 위한 국제 표준을 제정하는 국제적인 표준화 프로젝트 1995년 ISI/IEC15504 라는 규격으로 완성 목적 - 개발기관이 프로세스 개선을 위하여 스스로 평가 - 기관에서 정한 요구조건을 만족하는지 개발 조직이 스스로 평가 - 계약을 맺기 위하여 수탁 기관의 프로세스 평가

SPICE vs CMM 유사점 차이점 - 프로세스 심사를 위한 참조 모형을 제공 - 개발 성숙도에 따라 차별화된 수준을 정의 3. 프로세스 품질 유사점 - 프로세스 심사를 위한 참조 모형을 제공 - 개발 성숙도에 따라 차별화된 수준을 정의 - 각 수준의 특징을 제시하여 기관의 수준을 판단하는 기준 제공 차이점 - 성숙도 레벨과 심사 영역의 구분 CMM : 레벨 1부터 5까지 다섯 단계의 성숙도 수준을 정의 SPICS : 레벨 0부터 5까지의 여섯개 수준으로 나누어 정의 - 능력 평가 방법 CMM : 프로세스 능력을 여러 분야에 걸처 하나의 레벨로 평가하는 일차원적 구조 SPICS : 각 프로세스 영역 마다 능력에 대한 평가를 별도로 할 수 있는 이차원적 구조

SPICS의 이차원 모델 예제 3. 프로세스 품질

SPICS 프로세스 영역 고객 공급자 프로세스 엔지니어링 프로세스 3. 프로세스 품질 고객 공급자 프로세스 - 소프트웨어를 개발하여 고객에게 제공하고 소프트웨어를 정확하게 운용하고 사용하도록 지원하기 위한 프로세스 - 예, 발주, 공급자 신청, 고객인수, 요구사항 도출, 공급, 운영 등 엔지니어링 프로세스 - 시스템과 소프트웨어 제품을 개발하는 모든 프로세스, 즉 요구분석, 설계 및 실험, 구축 등의 프로세스 - 예, 요구분석, 설계 및 실험, 구축, 통합 등

SPICS 프로세스 영역 지원 프로세스 관리 프로세스 조직 프로세스 3. 프로세스 품질 지원 프로세스 - 문서화, 형상관리, 품질 보증, 검증, 확인, 검토 등의 개발 활동 지원 프로세스 관리 프로세스 - 일반적인 소프트웨어 프로젝트에서 일어나는 관리 활동 - 예, 프로젝트 관리, 품질 관리, 위험관리 등 조직 프로세스 - 조직의 업무 목적을 수립하고 이를 달성하기 위하여 도움을 주는 프로세스 - 예, 프로세스의 정의, 심사, 개선, 인적자원관리, 기반 구조, 측정, 재사용

SPICS 6단계 능력수준 레벨 0 (미완성 단계) 레벨 1(실행 단계) - 목표 달성에 실패하는 경우가 많다. 3. 프로세스 품질 레벨 0 (미완성 단계) - 목표 달성에 실패하는 경우가 많다. - 쉽게 생각할 수 있는 프로세스의 작업 산출물이나 결과가 존재하지 않은 수준이다. 레벨 1(실행 단계) - 프로세스가 성공적으로 완수하기 위하여 철저하게 계획적이거나 추적되지 않을 수도 있다. - 철저한 관리가 수행되어야 한다는 것을 인지하고 있으며 더 강화된 노력에 대하여 동의한다. - 구별된 산출물이 존재하고 이들을 근거로 목표 달성 여부가 결정된다.

SPICS 6단계 능력수준 레벨 2 (관리 단계) 레벨 3(확립 단계) 3. 프로세스 품질 레벨 2 (관리 단계) - 정해진 절차에 따라 산출물을 내며 모든 작업이 계획되고 추적된다. - 산출물은 명시된 표준과 요구사항에 부합한다. - 레벨 1과 차이점 : 정해진 시간과 자원 한도 안에서 프로세스를 수행, 정해진 품질 요구 사항을 만족하는 산출물 레벨 3(확립 단계) - 소프트웨어 엔지니어링 원리에 근거하여 프로세스를 정의, 이를 이용하여 프로세스를 수행하고 관리한다. - 정의된 프로세스가 표준화 되어 있고 문서화 되어 있다. - 모든 프로세스는 표준 프로세스에 맞도록 조정하여 승인 받은 후 사용한다. - 레벨 2와의 차이점 : 프로세스에 정의된 성과를 달성 할 수 있도록 표준으로 정의된 프로세스를 사용한다.

SPICS 6단계 능력수준 레벨 4 (예측 단계) - 일정한 통제 범위 내에서 일관성 있게 수행한다. 3. 프로세스 품질 레벨 4 (예측 단계) - 일정한 통제 범위 내에서 일관성 있게 수행한다. - 프로세스를 수행한 후 자세한 측정값을 수집하고 분석한다. - 프로세스 능력의 정량적 이해, 수행 예측 그리고 관리 할 수 있다. - 작업 후 산출물의 품질도 정량적으로 알 수 있다. - 레벨 3과의 차이점 : 정해진 성과를 달성하기 위하여 표준 프로세스를 수행하며 그 결과는 일정한 한도 내에서 통제된다.

SPICS 6단계 능력수준 레벨 5 (최적화 단계) 3. 프로세스 품질 레벨 5 (최적화 단계) - 현재 프로젝트만이 아니라 미래에 수행될 프로세스에 대하여도 목표를 잘 만족 시킬 수 있다. - 수립된 목표에 따라 프로세스를 수행할 때 달성할 정량적인 효율 목표를 설정한다. - 목표에 대하여 지속적으로 프로세스에 대한 모니터링이 가능하다. - 결과를 분석하여 지속적인 개선을 할 수 있다. - 최적화를 위한 혁신적인 아이디어와 기술은 시범적으로 적용하여 도입한다. - 레벨4와 차이점 : 현재와 미래의 프로젝트를 성공적으로 완성시키기 위하여 정의된 표준 프로세스가 계속적으로 향상되기 위하여 역동적인 변화 및 시도가 있다.

4. 제품 품질 04 제 품 품 질

내부 품질 (internal Quality) 제품 품질 측정 4. 제품 품질 메트릭스 수치적 가시화 방법이 필요 내부 품질 (internal Quality) - 외부 환경의 영향을 받지 않고 객관적으로 특정 할 수 있는 특성 - 프로그램의 크기, 제어 흐름의 복잡도, 모듈의 응집력, 결합도 등에 대하여서는 객관적으로 특정이 가능하다. 외부 품질 (External Quality) - 외부 환경 요소 (사용자, 평가자, 운영 환경 등)에 따라 달라 질 수 있다. - 정확한 메트릭스가 어렵다.

ISO 9126의 제품 품질 측정 내부 메트릭스 (내부 품질) 외부 메트릭스 (외부 품질) 품질 수준 4. 제품 품질 내부 메트릭스 (내부 품질) - 개발단계에서 생성되는 요구분석, 설계, 원시코드와 같은 비샐행 결과물을 사용하여 품질을 측정한다. 외부 메트릭스 (외부 품질) - 완성된 소프트웨어의 성능, 오루 발생, 사용 용이성 등의 시스템 동작을 품질로 측정한다. 품질 수준

시간을 측정하는 차입 : 시스템 성능 측정, 개발 노력 측정 소프트웨어에서 적용하는 일반적 메트릭스 4. 제품 품질 크기를 특정하는 타입 - 소프트웨어의 추상적 기능 단위, 원시코드 한 줄, 모듈 단위 시간을 측정하는 차입 : 시스템 성능 측정, 개발 노력 측정 카운트 타입 : 오류의 수, 프로그램의 구조적 복잡도, 변경 횟수 등

ISO의 외부 품질 메트릭스 예 4. 제품 품질

5. 제품검사(Inspection) 05 제품검사(Inspection)

인스펙션 (Inspection) 1976년 Fagan의 논문에 기반 소프트웨어 품질 보증에 탁월한 효과 사전에 적은 노력으로 결함 발견 - 한 마디로 설계서, 코드 등의 중간 결과물을 검사하여 결함을 발견하는 작업이다. - 타인에 의한 인스펙션은 궁극적으로 수준 높은 디버깅이 가능하도록 한다.

인스펙션을 준비하는 동안 예상되는 결함을 찾아내고 이를 회의에서 확인 발견된 아이템이 실제 결함이라는 사실을 확인 하기 위하여 인스펙션 (Inspection) - 목적 5. 제품검사(Inspection) 인스펙션을 준비하는 동안 예상되는 결함을 찾아내고 이를 회의에서 확인 발견된 아이템이 실제 결함이라는 사실을 확인 하기 위하여 결함이 있다는 사실을 기록하기 위하여 개발자가 수정하도록 기록을 제시하기 위하여

인스펙션 (Inspection) – 부수적 목적 프로그래밍 품질을 향상 시키기 위하여 다음 개발 단계를 위한 기술적 기초를 제공하기 위하여 라이프 사이클 비용을 낮추기 위하여 테스트 작업의 효율을 높이기 위하여 프로그램의 유지보수성을 인식하기 위하여 소프트웨어 관리의 시작과 종료에 도움을 주기 위하여

인스펙션 (Inspection) 과정 5. 제품검사(Inspection) 크게 6단계로 구성된다.

인스펙션 (Inspection) 과정 - 계획 인스펙션 팀을 정한다. 팀 구성원이 인스펙션을 잘 준비 할 수 있는지 확인한다. 인스펙션을 할 대상이 지켜야 할 구격을 준수하고 있는지 확인 한다. 체크 리스트를 이용하여 인스펙션 착수 조건에 부합하는지 결정한다. 사전 교육의 필요성을 결정한다. 인스펙션 회의 장소를 결정하고 확보한다. 인스펙션 팀 일정과 장소를 예약한다. 인스펙션 팀 구성원과 관계자에게 회의 시간과 장소를 알린다. 인스펙션 팀 구성원에게 검토 역할을 할당한다.

인스펙션 (Inspection) 과정 – 사전 교육 인스펙션 팀 구성원을 대상으로 설계자/개발자가 수행하는 간단한 형태의 교육이다. 소프트웨어 (설계서 혹은 코드)를 간단히 설명한다. 어떤 작업이 어떻게 수행되었는지를 설명한다. 어떤 인터페이스가 있으며 기능은 무엇인지 설명한다. 사전 교육은 생략될 수 있으며, 실행 여부는 인스펙션 주재자의 판단에 맡긴다.

인스펙션 (Inspection) 과정 – 준비 인스펙션 팀 구성원이 해당자료를 받았고 인스펙션 회의를 통고 받았을 때 부터 시작한다. 모든 자료는 회의 5일전에 한번에 전달한다. 인스펙션 팀 구성원은 각자 발표할 자료를 준비한다. 이해하기 어려운 부분은 표시하고 자료를 검토하여 결함을 발견한다. 지정된 기록 양식에 기록한다. 준비에 소요되는 시간을 기록한다.

인스펙션 (Inspection) 과정 – 회의 발견된 잘못 된 점을 팀 구성원이 모여 논의한다. 인스펙션 회의는 두 시간을 초과하지 말아야 한다. 인스펙션을 준비한 시간을 기록하고 발견한 것에 대해 토론한다. 결함으로 판단되면 기록하고 종류를 구별한다. 해결책은 논의하지 않는다. (해결책은 제품 작성자의 의무이자 권한으로 남는다.) 회의 후에 참여자들의 결함 기록을 회수한다. 발견한 결함을 종합하고 준비기간과 인스펙션 기간을 기록한 후 인스펙션의 재시행 여부, 인스펙션의 유형 등을 작성자에게 알리고 폐회한다.

인스펙션 (Inspection) 과정 – 수정 담당자(설계자, 개발자)는 결함의 내용을 충분히 이해한 뒤, 작업을 면밀히 살펴 보고 수정한다. 인스펙션이 다시 필요하다고 결정하면 인스펙션을 다시 준비 한다. (제품이 만들어지고 나면, 결함을 수정하는데 큰 비용이 필요함으로 가능한 인스펙션 단계에서 많은 결함을 찾아내어 해결 되어야 한다.

인스펙션 (Inspection) 과정 – 후속조치 인스펙션 주재자는 인스펙션에서 발견된 모든 결함이 바르게 수정되었는지 확인한다. 수정 결과는 통신 수단을 이용하는 것 보다는 직접 만나서 검사한다. 소프트웨어 품질 관리자에게 종합 보고서를 제출하고 종료한다.

인스펙션 (Inspection) 종류 – 시스템 설계 인스펙션 목적 : 모듈의 전반적인 설계나 기능을 점검 주된 관심사 : 소프트웨어 요구, 성능 명세 관련 사항과 인터페이스 설계 시스템 설계 명세서에 포함된 인스펙션 대상 - 설계작업의 입력(계약 등) - 하드웨어 자원에 대한 기능 할당 - 기능 흐름 - 타이밍, 동기화에 대한 설계 - 인터페이스 - 분할 과정 - 모듈 별 설계 정의

인스펙션 종류 – 상세 설계 인스펙션 시스템 전체 설계 목적을 반영하도록 각 모듈의 설계가 잘 되었는가 검사 5. 제품검사(Inspection) 시스템 전체 설계 목적을 반영하도록 각 모듈의 설계가 잘 되었는가 검사

인스펙션 종류 – 코드 인스펙션 전제 인스펙션 목적 - 새로 작성된 프로그램이나 다른 시스템에서 개발되었으나 수정된 것 5. 제품검사(Inspection) 전제 - 새로 작성된 프로그램이나 다른 시스템에서 개발되었으나 수정된 것 - 컴파일 오류가 없는 것이 확인된 프로그램만이 코드 인스펙션이 가능 인스펙션 목적 - 코드가 요구 명세, 설계 명세, 인터페이스 명세에 적합한지 검사 - 설계가 정확이 프로그래밍 언어로 바뀌었는지 점검 - 코드의 품질을 동료가 점검 - 오류를 조기에 파악 - 코드가 모듈 사이의 인터페이스 요구를 만족하는지 검사

인스펙션 종류 – 코드 인스펙션 인스펙션 목적(계속) - 모듈 테스트 명세서 미리 검토 5. 제품검사(Inspection) 인스펙션 목적(계속) - 모듈 테스트 명세서 미리 검토 - 적당한 테스트 도구와 환경이 있는지 확인 - 모듈 테스트를 착수할 수 있는지 결정 - 소프트웨어 제품이 계약, 국제 표준, 규칙에 맞는지 점검

공학박사 박병형 pph@metam.co.kr 011)9742-0086 61