Day_00. Course Overview

수업에 사용할 TextBook 은 따로 없음


S/W 개발의 3가지 관점
=비용, 시간, 사용자 만족도


이번 수업의 3가지 목표
=S/W 품질관리 이해 , SDLC 단계별 품질 관리 , S/W 품질 모델


V&V 모델 – Verification & Validation Model)

=V&V 모델에서 중요한 포인트
==잘못된 요구사항 정의는 모든 것을 망친다
==요구사항 정의를 검증하는 인수 테스트가 가장 최종이기 때문에 요구사항 정의를 잘 하지 못하면 프로젝트를 모두 엎어야 하기 때문이다



Course Syllabus
=SW Quality Management
=SE Based SW Quality
=SW Product quality Model
=SW Process Quality Model


Definition Of S/W Quality – researcher
==Crosby – conformance to requirements or specifications
==Juran – fitness for use
==Deming – Quality of conformance , performance , design
==Feigenbaum – point of Enterprise(전사적 관점에서) product , service, marketing


Definition Of S/W Quality – Organization
==IEEE,ISO,DOD – 기관마다 다르지만 공통적으로 지적하는 부분
===사용자가 명시/묵시적으로 원하는 것을 SW제품이 만족시키는 정도
====요구사항을 정량적으로 평가해서 만족하는지 볼 수 있는 정도



S/W 품질의 특징
=개발자, 사용자가 바라보는 품질의 관점이 다르기 때문에 주의해야함

S/W 품질의 관리 영역
=제안 – 개발 – 유지보수 – S/W폐기 까지의 모든 사이클을 관리 해야 한다



Aspects of S/W Quality – S/W 품질 관점



Process – 프로세스 관점
==Meeting delivery dates - 납기일
==Meeting budgets – 프로젝트 예산
==Repeatable development process – 지속 가능한 개발 프로세스



Structural – 구조적 관점
==testability – 테스트 가능구조
==Maintainability – 유지보수
==understandability – 가독성
==efficiency - 효율성
==security – 보안성



Functional – 기능적 관점
==Meeting the specified requirements – 요구사항 충족
==Creating software that as few defects – 결함이 적은 S/W
==Good enough performance – 좋은 성능
==Ease of learning and ease of use – 배우기 쉽고 사용하기 쉬운S/W



Sponsors – 고객, 발주처



Sponsors
==Create business value – 비즈니스 가치 생성
==a board view of SW quality – S/W 품질
==connection between quality & risk – 품질과 위험의 관계



Development Team
==structural quality – 낮은 품질에서 발생하는 문제
==functional quality – 구현할 기능의 조절
==process quality – 품질 측정 방식 고안



Users
==functional – 기능적 관점
==process – 프로세스적 관점
===don’t care structural quality – 구조적 관점은 고려하지 않는다, 사용자는 내부 S/W설계 부분을 볼 수 없기 때문



S/W 품질관리의 요소
=3P – Process , Product , People
==최소한의 노력과 비용으로 최대의 품질을 만드는 활동



S/W 품질의 표준이 필요한 이유
=비 가시성
=최적화가 어려움(가용성 & 보안성의 균형 ex)침해사고가 발생시 서버를 내리고 고쳐야 하는데 서버를 내리면 가용성이 하락한다

=글로 서술하기 어렵다



s/w품질 관리를 어렵게 하는 2가지 이유
=user needs change
==고객 요구사항의 변경
==불완전/일치 품질 요구사항 명세

=Quality culture
==품질 평가 체계의 미흡
==측정 대상의 불분명한 정의
==평가결과 분석시 모호한 평가결과


Umbrella Activity
=우산 아래 있으면 비를 맞지 않는 것처럼 품질활동을 지키는 활용
==명확한 요구사항의 명세와 평가
===S/W를 정확히 정의할 수 있어야 품질도 정확히 정의가 가능하기 때문