sw품질관리 Flashcards
안전, 보안, 품질
[안전] 내부 위험요인으로부터 시스템을 보호
[보안] 불법적이거나 악의적인 외부 위협으로부터 시스템을 보호하는 활동
[품질] 요구사항이 시스템에 정확히 구현되었는지 여부의 정도
[비교] (안전/보안/품질)
- 보호대상(관점) : 생명, 재산피해, 환경 / 시스템, 정보 유출 / 사용자 불편, 성능
- 위험 발생 원인 : 안전 요구사항 누락 및 설계 오류, 검증 부족 / 접근제어 오류, 취약성, 보안 시스템 미흡 / 구현 오류, 테스트 미흡
- 대상 시스템 : 오작동시 안전사고로 연결되는 시스템 / 침입 보호 시스템 / 모든 형태 소프트웨어
- 구현 시스템 : 항공,열차 제어 시스템 / IDS,IPS, DDoS 대응 장비 /
* 최근 Safety Critical SW 활용 확산에 따라 안전 기능 요구 증가. 사전 진단을 통한 위험원 제거 필요
SW 품질 관리
[정의] 주어진 요구를 만족하는 제품 혹은 서비스 질을 보존하는데 필요한 제반 기법화 활동
[목적] 기술 평가, 자원평가, 프로세스 평가, 제품평가
[품질 관리 기법] (계통보)
- 품질 계획 : 원가 편익 분석, 벤치마킹, 실험 계획법, 품질 비용 분석
- 품질 통제 : 파레토 분석, 산점도 분석, 특성 요인도 분석, 히스토그램, 체크시트, 층별 분석, 그래프
- 품질 보증 : Review, Inspection , Walk-through
품질통제
[정의] 프로젝트 결과가 품질기준을 준수하는지 결정하기 위해 감시하고 기록하며 성과를 평가하고 권고안을 제시하는 활동
* 품질 허용 범위, 지표 관리, 통제, 산출물 검사
[주요도구] (현원자)(파체히 특산층 관리)
- 현상파악 도구 : 파레토도, 체크시트, 히스토그램
- 원인분석 도구 : 특성요인도, 산점도, 층별
- 자료관리 도구 : 관리도(그래프)
[산출물] 단위 테스트 결과서, 통합 테스트 결과서, 설치 테스트 결과서 , 실행 테스트 이행률
품질보증
[정의] 요구사항과 개발된 산출물이 일치하는지 확인하기 위한 요구사항 적합성 검증 및 보장 활동
* 프로세스 준수 여부, 절차, 표준 준수 ( IEEE 610, 1991)
[주요도구] Management Review, Technical Review, Inspection, Walk-Through, V&V, 시험평가
[수행절차] (계엔측문통) 1. 계획(대상, 산출물) → 2.엔지니어링 활동 검토(개발, 프로세스) → 3.측정/평가 → 4.문서화 → 5.승인/통보
[보증활동] (형문이품위) 형상(식통감기, CCB), 문서(체크리스트, 요구사항추적표) 이슈(문제, 인시던트), 품질(통제, Review), 위험(원인FTA, 도출FMEA)
[산출물] 시정조치 결과서, 확인서, 시정조치 계획서
품질보증 활동
[개념] SW의 개발 프로세스, 요구 및 품질 표준을 만족시키기 위한 비용 효율적인 프로세스와 방법을 개발, 검증하는 계획적이고 체계적인 활동
[수행관점]
- 프로세스 측면 : 개발 프로세스와 방법론 정의 및 설적 모니터링
- Product 측면 : 품질 특성, 메트릭, 지표, 표준 정의 및 체크리스 기반 품질 확인
[SW 품질 보증 활동 유형]
- 프로세스와 표준 정의 : 프레임워크 구축, 가이드라인 정의
- 품질 관리 : 품질 계획 수립, 품질 제어
- 프로세스 개선 : 프로세스 측정, 프로세스 개선 조치 제안
* SW 의 복잡화, 대형화 및 MSA 적용 확산에 따른 효과적 품질보증을 위한 방안 수립 필요
[효율화 방안]
- 품질 점검 자동화 : 1) DevOps, DevSecOps 기반 품질점검 프로세스 자동화, 2) SW 정적분석/기능/성능/취약점 점검 기능 자동화 및 모니터링 -> Git, Jira, PMD, JMeter, SonarQube, Junit 등 자동화 도구 활용
* 국내 SP 인증을 활용하여 조직 품질관리 수준 내재화 및 지속적 개선 필요
품질비용
[정의] SW 개발 시 오류 감소 위한 품질 확보 비용과 실패 비용을 더하여 품질활동을 원가로 계산한 비용
* 품질비용 = 예방비용 + 평가비용+ 내/외부 실패비용
[목표] 적절한 예방/평가비용을 투입해서 실패비용 최소화
[유형] (예평내외)
<투자비용> 일정 품질을 달성하기 위해 투자하는 비용
1. 예방 비용 : 결함 예방을 위한 비용
2. 평가 비용 : 제품 품질 확인/검증을 위한 비
<실패비용> 품질 결여로 인해 파생된 비용
3. 내부 실패비용 : 제품 인도 전 결함 수정 비용
4. 외부 실패비용 : 고객에게 인도 후 제품이나 서비스를 수정하는데 드는 비용
</실패비용></투자비용>
코드 품질 향상 기법
[정의] 인스펙션, 정적분석, 페어 프로그래밍 기법활용, 코딩 작성후 결함 및 프로그램 정확성 검증 위한 코드 품질 확보 기법
[특징] Snow-Ball Effect 예방 (실행전 조기 결함 검증) , 품질 이슈 점검 (결함, 효율성, 코딩 표준 준수여부 검사)
[기법]
- 코드 인스펙션 : Rule-Set 기반 Formal Review 기법 (체크리스트, 우선순위 선정)
- 정적 분석 : 정적분석 SW도구 (코드 인스펙션 전 수행 , 도구(McCabe, QAC++))
- 페어 프로그램 : 프로그래머 두명이 머신 공유, 코딩 /리뷰 역할 분담 및 교환 통한 향상기법 (TDD)
Mccabe 회전 복잡도
[정의] 소스코드 복잡도의 정량 표현을 위해 제어 흐름을 그래프로 표현하는 측정 지표
[특징] 정량지표, 구조적 평가 기법, 간접 측정 방식
[측정 기법]
- 계산식 : V(G) = E - N + 2(N: 노드 수, E: 간선 수), V(G) = P + 1(P: 조건분기 수)
- 그래프 구성 : Node, Edge
- 그래프 표현 : Sequence, While, Until, If-Else
[평가지표]
- 1~10: 구조적 코드, 11~20: 다소 복잡, 21 ~ 50: 매우 복잡, 50 이상 : 테스트 불가
[품질 보증을 위한 복잡도 관리 방안]
- 직/간접 정량적 측정 (회전 복잡도, Halstead, LOC 측정) → 복잡도 관리 → 방법론/도구 활용
[방법론] TDD, Code Inspector, PMD Sonarqube
* ISO26262, MISRA에서 SW안전성을 위해 복잡도 측정 요구
* McCabe 단점 보완한 Modified, Strict Cyclomatic Complexity 이용, 복잡도 측정 가능 (Modified: Case문 복잡도는 무조건 1로 지정, Strict: 복합 if문 모두 계산)
FTR(정형기술검토)
[정의] 명세서, 소스 기반 동료검토 통한 조기 결함발견 목적, 정적분석 기법
[효과]
- 결함 조기발견, 수정 통한 품질 향상, 수정 비용 최소화, 커뮤니케이션 향상
- 페이건(Pagan) 인스펙션 : 투입되는 인력 최소화 효과, 품질 비용 감소 및 개발 단축 효과 획득
* ISO/IEC 29119-2 정적 테스트 프로세스를 기반으로 수행하며, 목적에 따른 Review 유형 활용 필요
[수행절차] 계획 → 사전준비 → 개별검토 → 검토회의→ 재작업 → 후속조치
[수행원리]
1. 요구사항 검토에서 인수테스트 최종검토까지 SDLC 모든 단계에서 수행
2. 개발초기에 수행할수록 오류비용 감소
3. 검토 끝에서 모든 FTR 참가자들은 산출물의 승인, 거절을 결정해야 함
4. 승인절차를 거쳐 단계별 기준선이 설정되며, 형상통제의 시작점이 됨
기능 점수
[리드] 최종 사용자 입장에서 SW 규모를 측정
[정의] 사용자가 요구하는 기능을 데이터 기능과 트랜잭션 기능으로 구분하고 평균복잡도를 사용하여 정량적으로 산정하는 SW 규모 산정 기법
[측정요소]
- ILF : 내부 논리 파일
- EIF : 외부 연계 파일
- EI : 추가, 수정, 삭제, 상태 변경
- EO : 외부 출력
- EQ : 외부 조회
* 기능점수방식으로 SW개발규모 산정방법은 간이법이외에 정통법이 존재
[FP 규모산정 절차] (유경 데트 미인조)
1. 계산 유형 결정 : 개발 프로젝트, 개선 프로젝트, 어플리케이션 비용 산정
2. 계산 범위 및 경계 식별 : SW의 사업 범위와 어플리케이션의 ILF,EIF를 구분하여 경계 식별
3. 데이터 기능 계산 (ILF, EIF) : DET/RET 식별 -> 복잡도 산정 -> 기능점수 산정
4. 트랜잭션 기능 계산(EI, EO, EQ) : DET/RET 식별 -> 복잡도 산정 -> 기능점수 산정
5. 미조정 기능점수 결정
6. 2에서 값 조정 인자 결정 : 보정계수(5개)(개발 규모, 연계 복잡성, 성능 요구 수준, 다중 사이트 운영성, 보안성)
7. 조정 기능점수 결정(AFP)
정규법과 간이법
[정의] SW 기능을 논리적 관점에서 식별, 기능 유형별 수량과 성능 및 품질요인 영향도를 고려한 사용자 관점의 SW 규모 측정 방법
[특징] 기능 중심의 산정 방법(사용자 중심), 초기 사업 규모 예측 가능
* 측정 항목 및 복잡도 적용 방식 등 산정 기법에 따라 간이법과 정통법으로 구분
[비교] 정규법 vs 간이법
- 사용 목적 : 상세한 기능점수 측정 / 개략적인 견적 산정
- 측정 항목 : 데이터 기능(ILF, EIF), 트랜젝션 기능 / 데이터 기능, 트랜젝션 기능
- 복잡도 적용 : 기능별 복잡도 계산 적용 / 평균 복잡도 적용
- 장점 : 정확한 SW 규모 측정 및 다양한 활용 가능 / 신속한 규모측정 가능
- 단점 : 사업초기 적용 어려움 / 제한적 데이터 재활용
- 적용 시기 : SW개발, 유지보수 규모산정시 분석, 설계단계 이후 / 예산 수립, 제안 단계 적용
* 기능점수는 데이터 기능과 트랜잭션 기능의 합으로 산정, 보정계수를 통해 조정하여 활용
