이미지출처 : www.secc.org.eg
Quality
- Small ‘q‘: 제품의 품질
- Big ‘Q’ : 제품을 개발하는 절차, 고객의 만족도 등을 고려한 품질
- 향상방법3가지
# 사람에 투자
# 프로세스에 투자 (효율이 좋다)
# 도구나 기법에 투자
- Software Engineering 에서 말하는 품질을 확보하기 위한 수단
# 소프트웨어 형상관리(SCM)
# 프로젝트 관리(PM)
# 데이터 관리(SQE)
- 관리 계획
1. 목적 & 범위
2. 프로젝트 내에서의 SQA 활동 계획
3. 양적 절차관리에 대한 계획
4. 결함방지를 위한 계획
소프트웨어 공학의 목적 - 많은 사람들이 함께 개발을
할 때 더욱 큰 효과를 내기 위함
구현 -> 설계 -> 분석 -> 테스팅 -> 유지보수 · 재사용성 (생산성, 품질)
효율적인 설계, 분석
- 일반성(Generality)과 향상성(Incrementality)고려 필요
- ‘무엇에 중점을 둘 것인가’ 고려 필요(Ex.Risk, Bussiness Value)
# Liner ->Incremental
# Rigid ->Flexible
# Monolitic-> Interactive
CMMI
1. INITIAL(실행) | |
2. REPEATABLE(관리) – 반복 가능 | 기본적인 프로젝트 관리 |
3. DEFINED(정의) | 프로세스 표준화 |
4. MANAGED – 개량화 가능 | 정량적인 관리(수치화 시킴) |
5. OPTIMIZING(5) 지속적인 프로세스 개선 | 체계적인 계획으로 overhead를 처리해야 한다. |
유지보수 활동
- 수정되는 것(Corrective) : 20%
- 환경의 변화에 맞추는 것 (Adaptive) : 20%
- 잘 돌아가는 것을 더 완벽하게 만드는 것 (Perfective): 80%
프로세스 적용 시 성공 사례를 가지고 유연하게 적용해야 한다.
- 조직에 맞는지 검토 후 적용 가능성을 탐색
- Risk를 가지고 단계적으로 완화시키는 활동을 해야 한다.
Inspection
정의
- ‘무엇을개선할 수 있는가’를 찾는 활동 (WHAT)
- 사람에 대한 평가가 아니라 조직관점의 성능을 평가하는 것
- 조직의 문화를 바꾸는 것!
- 모호한 것을 명확하게 함
특징 & 방법
- 결함 발견 및 데이터 수집
- 산출물에 대한 전문지식 교환
- 해결안 지양(결함을 찾는데 주력)
-&Defect를 빨리 찾을수록 fix 비용
소요 감소
- Inspection의 데이터를 통해 업무에 집중 가능
- 테스팅은 결함의 존재 여부만 식별하는데 반해, 결함의 내용과 위치를 식별
- 코드 인스펙션은 컴파일이 문제없이 되었을 때
- 사전 준비를 철저히 하고 회의 시작
- 2시간이 넘지 않게 함
- 데이터를 수집하여 차후 inspection시history로 참고
# 데이터의 오염 (정보의 조작이 일어날 수 있다.)
팀 크기
- 인원은 3~7명이 좋다. (4명적절)
- Code Inspection시Producer를 제외한 2명의 Inspector가적절
-&Document Inspection시 2명보다많은 Inspector가 요구됨.
- Moderator는 Reader또는 Recoder를 겸임 할 수 있음.
단계
- Planning
# 역할 선정
# 일정 잡음, inspection 그룹만 참여하도록
# 일정에 Inspection 일정 계획을 task마다
추가.
# Code Inspection
## Unit Test 이전에 실시
- Overview
# 검토 대상 산출물에 대한 설명
# 산출물의 이전버전에 대한 Inspection이 실시된 적이 없는 경우
# 한명의 Engineer가 산출물을 작성한 경우
# 새로운 기술이 도입되거나, 복잡도가 높은 경우
- Preparation
# Checklist, Rule Set(코딩 규칙등)과 같은 도구를 사용해
대상 산출물의 완전성과 시정대상 여부 및 적절성을 판단
# 이 과정을 거치지 않는다면 Walkthrough.
# 일반적인 규칙에 어긋나는 것들(타이핑 에러, 스펠링 틀림, 포멧이상 등)은 Typo list로 제공
# Reader와 Recorder에게 매우 중요한 단계
# 미팅의 2.6배정도 시간이 소요
# Defect를 많이 발견하기 위해 여러 번 검토 하는
것이 좋다.
- Meeting
# 정리하는 시간.
# Inspection Summary Report 작성
- Rework
# 각종 보고서를 가지고 최종 산출물 작성
# 시간의 제약을 두어야 함
- Follow-up
# 프로세스 수행이 적절히 이루어 졌는지 검증하는 단계
- Causal Analysis
# Process Brainstorming 단계
역할
- Reader(Presenter) : 산출물에 대해서
설명하는 역할
- Recorder : Defect, 이슈 및 기타 내용을 기록하는 역할을 수행함
- Verifier : 최종확인 작업
- Producer : 산출물 작성자
- Moderator : Inspection 총괄
성공적인
Inspection 을 위해
- 관리자들에게 약속을 받음
- 데이터 수집 및 분석
# 알맞은 수집 양식을
작성 하는 것이 중요
- 훈련
Inspection
Metric
- Defect.Density : 산출물의 품질을 평가함.
[Defects.Found.Total /Size.Actual] Inspection 대상 산출물의 단위당 발견된 Defect수
- Defect.Corrected.Total : Defect당 평균 Rework Effort를 계산
[Defect.Corrected.Major + Defects.Corrected.Minor] Correct된 (Major+Minor) Defect
- Defect.Found.Total : Inspection의 효과성(Effectiveness)과 효율성(Efficiency)을 평가
[Defects.Found.Major + Defects.Found.Minor] 발견된
(Major+Minor) Defect
- Effort.Inspection : 근무 시간 또는 금액으로 Inspection의
전체 비용을 계산함.
[Effort.Planning + Effort.Overview + Effort.Preparation + Effort.Meeting +
Effort.Rework] Inspection을 수행하는데 투입된 Effort 합계
- Effort.per.Defect : 프러덕트 Life-Cycle의
Inspection 이후 단계에서 발견되는 Defect의 처리 비용과, Inspection에서 발견된 Defect의 비용을 비교함.
[(Effort.Planning + Effort.Overview + Effort.Preparation + Effort.Meeting)/Defects.Found.Total]
Defect를 발견하는데 투입된 전체 근무 시간의 평균
- Effort.per.Unit.Size
: 프로젝트에서 발생하는 산출물들을 Inspection하는데 소요되는 비용을 견적
[Effort.Inspection / Size.Actual] Inspection 산출물의 기본 단위당 투입된 시간의 평균값
- Percent.Inspected : Inspection Planning의 정확도를 평가
[100*Size.Actual / Size.Planned ] 실제로 Inspection을
수행한 산출물에 대한 계획 대비 비율
- Percent.Majors : Inspection의 초점이 Major Defect인지 Minor Defect 인지 판단
[100 * Defects.Found.Major / Defects.Found.Total] 전체
Defect중에서 Major Defect의 비율
- Rate.Inspection : 향후의 Inspection Effort를 계획하는데 사용
[Size.Actual / Time.Meeting] Inspection
Meeting 시간당 수행된 산출물의 평균 분량
- Rate.Preparation : 향후의 Inspection Effort를 계획하는데 사용
[Size.Planned / (Effort.Preparation / Number.of.Inspectors)] Inspector들이 Preparation의 단위 시간당 처리한 산출물의 평균 분량
- Rework.per.Defect : Inspection의 Benefit을 판단하기 위해, 프러덕트 Life-Cycle의
Inspection이후 단계에서 발견된 Defect를 처리하는데 소요되는 비용과 비교
[Effort.Rework / Defects.Corrected.Total] 1개의 Defect를
처리하고 검증하는데 필요한 시간의 평균값
결함 발견하는데 소요 시간
- 테스팅 : 4 hours / fault
- 인스펙션 : 1 hour / fault
Peer Review의 3대
장벽
지식(Knowledge), 변화 거부 (Resistance to Change), 조직 문화 (Culture)
Testing
제한된 테스트 케이스를 가지고, 신뢰성을 높인다.(테스트는 100% 될 수 없다.)
- Error : 사람이 한 실수
- Fault : Error로 인해 발생된 문제점
Correct -> Reliable -> Safe -> Robust
Test Planning
- ‘무엇을 테스트 할 것인가’(WHAT)
- ‘테스트를 어떻게 할 것인가’(HOW)
- 설계, 개발 단계에서 진행하는 것이다.
Testing Techniques
Structural (Whitebox)
Test – 코드를 보는 테스트
Coverage
- Statement Coverage : 모든 라인을 거쳐 가는지 확인
- Path Coverage : 가능한 모든 길을 확인
- Branch Coverage : 조건문의 양쪽 가지를 다 통과하는지 확인
- Condition Coverage : 조건이 True일 때 , False일 때를 모두 확인
Functional(Blackbox) Test
- 문서(코드 이외에 알 수 있는 모든 정보들) 위주의 테스트
- Equivalence Partitioning : 비슷한 그룹으로 나눔
- Boundary Value Coverage : 경계를 기준으로 확인
# 경계 -> 경계안 -> 경계밖 -> 중간 -> 겹치는 경계
- Special value
Coverage : 알려진 값을 기준으로 확인
Testing Phases
Unit Testing – 모듈 중심
Integration Testing – 인터페이스 중심
System Testing –환경 고려
Regression Testing – 버전 변경 시 바뀐 부분이 제대로 바뀌었는지 확인을 위해
Non-Functional Testing도 고려해야 한다.
대량의 데이터를 처리할 때 유용한 툴
- 정규 표현식(Regular Expression)
- Flex (The Fast Lexical Analyzer)
TimeTracker
- 실제 일하는 시간을 체크하여 업무 효율을 증가 시킬 수 있다.
도표
Control Chart – Control 영역을 설정하여, 품질을 관리 할 수 있다.
Pareto Chart – 가장 높은 Bar가 전체적 문제 해결을 위해 가정 공헌도가 큼을 의미
Run Chart – 시간의 순서에 따라서 데이터의 변동 상태를 보여준다.
Scatter Diagram – 상관관계를 볼 때 사용
용어정리
80-20 Rule - 20%의 부분에서 80%의 문제가 발생한다
Heuristics – 경험적 지식
GQM(Goal, Question& Answer, Metrics)
- Goal을 달성하기 위한 질문과 답변을 통하여 기준이 되는 데이터를 찾는 것
FAULT
- ERROR(Review 시점에 발견한 것) + DEFECT(Review시점 이후에 발견한것)
PMO(Project Management Office) – Project의
전체적인 일정을 수립하고, 지켜가야 할 원칙을 설정하고,
Project 성공을 위한 수행전략을 수립하고, 전체적인 예산과 인력을 관리
SQA(Software Quality Assurance) – 세팅된 프로세스를 가지고, 잘 따라가고 있는가를 관찰하는 그룹 [감사]
EPG(Engineering Process Group) – 조직의 프로세스의 개선을 위한 그룹 [재정]
COQ(Cost Of Quality) - Review, Rework, Etc / Total Effort
COPQ(Cost Of Poor Quality) - Rework / Total Effort
QPM – Process Control + Process Improvement : Use Statistical techniques
=>
Stable Process + Capable Process
LOC(Line Of Code)
ReqB(Requirement Book)
SPMP(Software Project Management Plan)
SCMP(Software Configuration Management Plan)
SQMP(Software Quality Assurance Plan)
CMMI(Capability Maturity Model Integration)
Reference
Peer Reviews in Software, Karl
E.Wiegers, Addison-Wesley
Computer based software inspection
———————————————————————
4일간의 Software Quality Assurance & SW Testing 교육
재미있는 이야기가 많았다.
by 月風
