백자의 블로그

기출문제

I. SW 프로세스 품질 개선 모델, CMMI의 개요

가. CMMI(Capability Maturity Model Intergration)의 개념

- 시스템과 SW영역을 하나의 프로세스 개선 툴로 통합시켜 기업의 프로세스 개선활동에 광범위한 적용성을 제공하는 모델

- 소프트웨어 개발 및 유지보수에 있어 프로세스 관리방법과 품질개선 개념을 적용하여 조직의 개선을 위한 모델

- 카네기 멜론대학 소프트웨어 공학연구소가 개발한 여러 CMM모델을 통합하고 있는 통합모델

- SW 개발 능력 및 성숙도에 대한 평가와 지속적인 품질 개선 모델

II. CMMI의 구성 및 모델구조

가. CMMI의 구성

나. CMMI 지식체계

III. CMMI의 종류

구분	Staged Representation (단계적 표현)	Continuous Representation (연속적 표현)
설명	- 가장 기초적인 관리 절차 로부터 상위 수준으로 향상되기 위해 필요한 실무까지 수행되어야 할 프로세스를 단계별로 제시 - 조직 간 비교를 가능하게 하는 단일한 등급 체계 제공	- 조직의 비즈니스 목적을 충족시키고, 위험 요소를 완화시키는데 중요한 개선 사항의 순서를 정하여 적용 시킬 수 있음 - Capability Level을 이용 하여 프로세스 영역(PA) 별로 성숙도 평가 가능
특징	- 성숙도 수준으로 조직간 비교 모델 - 단일등급체계 평가 결과 이므로 이해 하기 쉬운 프로세스 개선 결과 제시 - 입증 순서로 개선 활동 제공	- 능력 수준을 프로세스에 적용 - 해당 프로세스 영역의 능력 수준을 결정 하므로 프로세스 개선에 유연한 접근 방식 - 우선 순위 기준 능력 수준 개선 가능
Process Area	Maturity Level로 그룹화	Capability Level 그룹화
예제모델	SW-CMM(단계적 표현) Level별 KPI, Bottom-Up	SE-CMM(연속적 표현) SPICE와 호환가능,Top-Down
성숙도 평가	1 ~ 5단계(SW-CMM과 유사)	0 ~ 3단계(SPICE와 유사)
표현방법

I. 프로세스 개선 De facto 표준, CMMI V2.0의 개요

가. CMMI 2.0(Capability Maturity Model Integration)의 정의

- 빠른 현실 비즈니스 환경에 적응하며, 조직의 성과를 잘 반영할 수 있도록 변경된 프로세스 개선 참조 모델

- 2018년 3월 모델 발표 이후, 2019년부터 심사 서비스 시작(2020년 4월부터 V2.0 심사 결과만 허용)

나. 주요 변경 사항

- ① CMMI 채택 ROI 입증: 성과 및 효율성에 초점, ② 최신 트렌드 반영: agile, 보안, 안전 반영,

③ 심사 가치 증대: Sustainment Appraisal 도입, ④ View 도입: 사용자 친화적 모델

II. CMMI V2.0의 구조도와 구성 설명

가. CMMI V2.0의 구조도

나. CMMI V2.0의 구성 설명

- Practice Level 별 Capability의 향상이 Performance 개선이 되도록 구성

III. CMMI V2.0 Practice level

Practice Level			Performance Objective
Level 5	Optimizing		성과 최적화
Level 4	Quantitatively Managed		성과 예측 및 개선
Level 3	Defined		조직 성과 초점
Level 2	Managed		프로젝트 성과 초점
Level 1	Initial		성과 이슈 집중
Level 0	Incomplete		성과 미고려

- Practice 레벨 별 Capability의 향상이 Performance 개선이 되도록 구성

“끝”

[기타자료]

* PA 변경 내용(CMMI-DEV)

[영어 항목과 비교 공부]

기출문제

I. SW 품질 특성과 품질평가 Metrics를 정의한 국제표준, ISO/IEC 25010

가. ISO/IEC 25010의 정의

- 소프트웨어의 품질특성과 품질평가 척도(Metrics)을 정의한 국제표준

- 사용자 관점의 소프트웨어 품질특성에 대한 표준

나. ISO/IEC 25010의 특징

II. ISO/IEC 25010의 구조 및 품질특성

가. ISO/IEC 25010의 구조

• 소프트웨어 품질특성을 8개의 주특성과 31개의 부특성으로 분류

나. ISO/IEC 25010의 내ᆞ외부 품질특성

다. ISO/IEC 25010의 사용 품질특성

“끝”

<참고>

 ISO/IEC 9126 , ISO/IEC 25010으로 개정 요약

기출문제

I. 사용자 요구사항에 부합하는 산출물 생성을 위한, 품질통제의 개요

가. 품질통제(Quality Control)의 정의

- 프로젝트 결과가 관련 품질 기준을 준수하는지를 결정하기 위해 감시하고 기록하면서 성과를 평가하고 권고안을 제시하는 활동

나. 품질통제의 목적

1) 프로젝트에서 품질이 낮거나 요구사항에 맞지 않는 제품 품질의 원인을 식별해서 원인을 제거하는 활동

2) 주요 이해관계자의 요구사항에 맞는 작업과 산출물인지를 확인하여 결과적으로 최종 승인을 얻는 것

II. 품질통제의 7가지 도구

가. 품질통제 4가지 도구(PMP 6 Edition)

구분	도구	설명
원인분석 단계 활용 도구	특성요인도 (인과관계도)	- Cause and Effect Diagram, Fishbone Diagram, Ishikawa Diagram - 결과(특성)와 그것에 영향을 미친 원인(요인)을 계통적으로 나타냄
	산점도 (산포도, Scatter Diagram)	- 영향을 주는 2개 인자간의 관계를 파악하기 위한 도구 - 두 변수에 대해서 특성(결과)과 요인(원인)의 관계를 규명하고 이 관계를 시각적으로 표현하고자 할 때 사용 - 강한 정비례 관계(양(+)상관) : X가 증가하면 Y도 증가 강한 반비례 관계(음(-)상관) : X가 증가하면 Y는 감소 관계가 없는 것(무상관) : X가 증가해도 Y에 영향이 없음
자료관리 단계 활용도구	관리도 (Control Chart)	- 공정이 일정한 품질 수준을 유지하는가를 판정하는 도구 - In Control : random variation은 발생하지만, 통제할 수 있는 special variation은 없는 상태 - Out of Control : 결과가 상한선(UCL)이나 하한선(LCL)을 벗어나는 경우
현상파악 단계 활용 도구	히스토그램 ( Histogram)	- 범위를 몇 개의 구간으로 나누어 막대그래프로 작성 - 데이터의 분포의 형태를 쉽게 파악하기 위한 용도

나. 품질통제 3가지 도구(PMP 6 Edition 제외분)

현상파악 단계 활용 도구	파레토 차트 (Pareto Diagram)	- 문제의 중점화, 우선순위 파악을 위한 도구 - 문제 원인은 “사소한 다수(trivial many)”와 중요한 “소수(vital few)”로 분류 - 중요한 20% 원인이 전체 문제의 80%를 발생 (20:80 법칙)
	체크 시트	- Check Sheet - 데이터 수집, 문제 분석을 효율적으로 실시하기 위한 도구 - 간단히 체크해서 결과를 쉽게 알 수 있도록 만든 도표
원인분석 단계 활용 도구	층별	- Stratification - 불량 요인마다 데이터를 구분해서 잡는 도구 - 전체 데이터를 두 개 이상의 관련 있는 부분집합으로 나누어 분석함으로써 문제의 가능한 원인을 규명하려는 기법 - 부분집합을 층이라 하고 층으로 나누는 것을 층별 또는 층별화라 함

* [기존 5판]에서 수정된 부분

도구		개념도		설명
흐름도	- Flow Chart		- 하나의 프로세스에서 어떤 단계로 수행할 수 있는 가능성을 입력과 출력으로 표현

III. 신 QC 7가지 도구

- 주로 언어 데이터와 같은 정성적 데이터를 분석하고 정리하는 데 사용되는 도구

도구	개념도	설명
친화도		- 다량의 아이디어를 유사성이나 연관성에 따라 묶는 방법
연관도		- 인과관계를 설명함으로써 복잡한 문제의 여러 다른 측면의 연결관계를 분석하는데 이용되는 도구
매트릭스도	- 매트릭스 형태의 표에 가중치와 평가 점수를 배열된 표에 기입하여 데이터를 알아보기 쉽게 표 또는 그림으로 나타내기 위한 도구	- 제품이나 서비스를 비교 혹은 평가하여 중요도를 나타내는데 효과적임
매트릭스 데이터 해석법		- 블록 다이어그램을 이용하여 각 블록의 상황을 구분하여 표현하는 데 효과적 - 주로 4-Block 또는 9-Block으로 구분하는 그림이 많이 활용됨
계통도		- 설정된 목표를 달성하기 위해 목적과 수단의 계열을 계통적으로 전개하여 최적의 목적 달성 수단을 찾고자 하는 방법
PDPC	- Process Decision Program Chart	- 프로젝트의 진행과정에서 발생할 수 있는 여러 가지 우발적인 상황들을 가정하고, 그러한 상황들에 신속히 대처할 수 있는 대응책들을 강구하여 표현하는 기법
애로우다이어그램		- Arrow Diagram - 여러 가지 복잡한 순서를 목적이 달성될 때까지의 작업순서와 시간 배정을 나타낸 것 - 순서와 서로의 관계가 하나의 화살표로 표시 예) 최적의 일정계획을 위한 진척도 관리

VI. 품질 통제 ITO

품질관리

기출문제

I. 사용자 요구사항을 만족시키기 위한 체계적인 활동, 품질관리(Quality Management)의 개요

- 품질 프로세스의 개선사항 촉진을 위해 품질 요구사항, 적절한 품질기준을 적용하고 감사하는 활동

II. 품질관리 프로세스 및 기법

가. 품질관리 프로세스

나. 품질관리 도구 및 수집기법

III. 품질관리 ITO

I. 프로젝트 품질관리 계획 수립의 개념

- 프로젝트 품질 관리 계획은 프로젝트, 산출물과 품질 요구사항이 어떻게 동작하는지 관련된 사항을 문서화하는 기준으로, 품질요구사항을 일치화 하는 프로세스

(특징) : 품질시스템 요구사항파악, 품질보증/통제 절차 파악, 품질통제 절차 파악

II. 프로젝트 품질관리 계획 수립 프로세스 및 구성요소

가. 프로젝트 품질관리 계획 수립 프로세스

나. 프로젝트 품질관리 계획 수립 구성요소

III. 프로젝트 품질관리 계획 수립 ITO

기출문제

I. 사용자 신뢰성 확보를 위한 성능 테스트 개요

가. 성능 테스트 정의

- 시스템에 요구되는 성능에 대해 시스템의 처리 능력을 검증하는 테스트

- 사용자가 시스템을 사용하기에 성능상 문제 여부를 검증하는 테스트

나. 성능 테스트의 기본 원리 Little's law

- ‘공간 내에 머무는 객체 수(L)’는 ‘객체의 공간유입량(λ)’과 ‘객체가 머무는 시간(W)’에 비례한다.

  즉 L = λW이다.

- 시스템의 성능(TPS)는 트랜잭션을 발생시키는 사용자(Active User)를 평균응답시간

  (Mean ResponseTime)으로 나눈 값이다.

- TPS(Transaction Per Second) = AU(Active User) / MRT(평균응답시간(Mean Response Time))

II. 성능 테스트의 개념도 및 용어설명

가. 성능 테스트 개념도

나. 성능 테스트 용어설명

III. 성능 테스트의 유형 및 구성요소, 절차, 구성 환경

가. 성능 테스트의 유형

나. 성능 테스트의 구성 요소

다. 성능 테스트의 구성 환경

[참고]소프트웨어 성능 테스트의 기본 원리 Little’s law

Multiple-V, 상태기반 테스트, 리스크기반 테스트, 명세기반 테스트

기출문제

I. Embedded 시스템 Testing의 개념

- 마이크로 프로세서 또는 마이크로 컨트롤러를 내장하여 제작자가 의도한 특수 기능만을 수행하도록 제작된 컴퓨팅 장치를 테스트 하는 기법

II. Embedded 시스템 테스트 모델 및 기법

가. 테스트 모델

모델	동작원리	설명
Dess-V		- 상위에서는 통합검증을 수행하고, 하위에서 SW 상세 검증하는 모델 - H/W의 테스팅 연계 부분을 별도로 고려하여 테스트를 수행
Multiple V		- V 모델 기반한 모델로 임베디드 시스템 개발 방식을 정형화한 개발모델 - 임베디드 시스템은 모델 -> 시제품(Prototype) -> 최종제품 단계로 진화 - 제품의 진화하는 단계마다 V-model의 활동 전체를 수행

- 기본적인 V모델에서 신뢰성을 높이기 위해 다양한 V-모델의 반복을 통해서 다양한 유형의 테스팅 기법을 이용

* 모델 - PC를 통해 요구된 시스템의 행위를 모의 테스트

* 프로토타입 - 모델로부터 소스 코드를 생성하고 실험용 하드웨어에 소스코드를 이식

* 최종제품 - 실제 하드웨어에 소스 코드 이식

나. Embedded 시스템 소프트웨어 테스트 기법

다. 임베디드 시스템 하드웨어 테스트 기법

• 소프트웨어의 의존도 증가로 기법 자체가 소프트웨어 테스팅으로 융합되어 발전 진화함

기출문제

Ⅰ. 테스터의 지적 능력을 극대화 및 Agile 방법론 대응을 위한 경험기반 테스팅의 개요

- 테스터의 과거 유사 시스템 개발 및 기술 경험을 기반으로 직감적으로 테스트하는 기법

Ⅱ. 경험기반 테스팅의 주요 기법

- 경험기반 테스팅 기법 중 대표적으로 탐색적 테스팅 기법이 많이 활용되고 있음

[참고] 리스트 기반 테스팅

I. 효과적인 경험기반 테스팅 수행 전략

가. 리스크 기반 전략과 연계한 경험기반 테스팅 수행

- 경험기반 테스팅은 테스트 대상에 비해서 테스트 자원이 부족한 경우, 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위한 테스트 전략이 필요 시 많이 활용되며, 리스크 기반 전략과 연계해 테스팅을 수행

- STA(Severs Test Area): 반드시 테스트 - STTA(Strong Test Area): 테스트 - ITA(Intensive Test Area): 테스트 - FTA(Fundamental Test Area): 테스트하지 않을 수 있음

- 장애발생가능성, 장애로 인한 영향도를 판단하여 해당 영역별로 테스팅 수행 전략 마련

나. 리스크 기반과 연계한 경험기반 테스팅 수행 전략

- 해당 분야의 경험이 많고, 도메인 지식이 높으며, 고객의 요구사항을 정확히 파악하고 있을 시 효과적  

[참고] 탐색적 테스팅과 경험기반 테스팅의 비교