Day_15. 기말고사 – Final Exam

기말고사 실시

Day_14. Class wrap up & 기말고사 공지

Class wrap up & 기말고사의 공지

Day_13. S/W product quality measurement

Reliability measure
=신뢰성의 측정
=지정된 환경에서 동작하는 정도
=내/외부로 나뉜다

Maturity measure	정상 운용시 신뢰성의 측정
Availability measure	시스템 상에서 복구에 걸리는 시간
Fault tolerance measure	시스템 장애 환경에서 버틸 수 있는 능력
Recover ability measure	시스템 상에서 다시 복구되는 능력

Security measure

Confidentiality	기밀성으로 권한이 있는 사람만 접근이 가능한 정도
Integrity	시스템의 무결성 측정
Non-repudiation	부인방지 서비스의 정확성
Accountability measure	감사/추적의 용이성과 완전성
Authenticity	인증의 용이성과 정확성

Maintain ability measure
=유지보수성 – 예정된 유지 보수가 수정하기 좋은 능력을 측정

Modularity	컴포넌트가 개별적으로 구성되어 있는가 변경시 영향이 적은 수준
Reusability	자원의 재사용 능력 코딩룰의 준수 수준
Analysis ability	변경이 발생시 시스템에 미치는 영향을 측정 가능한 정도
Modifiability	기존 시스템에 영향을 최소화 하면서 변경 할 수 있는정도
Testability	시스템에 test 기준을 잡아서 평가 하는 것 내/외 부로 나누어서 확인한다

Portability measure
=이식성의 측정
=기존 이용시스템에서 다른 곳으로 이전이 가능한 정도

Adaptability	적응성 – 제품이나 시스템을 다양하게 적용되는 정도
Install ability	특정환경에서 설치/ 삭제가 효율적으로 진행되는 정도
Replace ability	제품을 동일 환경/목적에서 다른 s/w로 교체가 가능한 정도, 소요 시간이 중요

Day_12. S/W product quality measurement

S/W measurement 정의
=지속적 개선 목적으로 s/w process 적용
=s/w 제품의 평가 / 품질관리 / 생산성 평가 관리 지원을 위해 project 에서 측정


4 key measurement process activities
=established and subtain commitment


s/w metric
=주어진 속성을 가지는 정량적 척도
=정성적/정량적 으로 나뉠수 있는데 이중 정량적 척도를 의미
=s/w product – dynamic/static metric
=s/w process

s/w product metric	Dynamic metric
	Static metric
s/w process metric

s/w metric type

Internal	조기 품질 문제 식별
External	사용자 관점
Hybrid	Function point 별
Project	PM 이 주로 사용

S/W metric 의 장/단점

장점	s/w 개발 투입 노력 추정, 품질 명세
	SDLC Phase 에 따라 상황/ 품질을 적용
단점	메트릭 적용의 어려움
	과거 경험 data 기반, 유효성 검증의 어려움

ISO 25020 Quality measurement division
=품질 측정을 하기 위한 framework 를 지정

S/W 제품의 측정 가능한 quality characteristic은 quality measure 과 연계
=4가지 요소

Measurement function	Measurement method
Quality measure element	Quality measure

품질 측정의 기준(measure

Functional completeness	기능의 완성성 기술집합의 구현 정도 Functional coverage – 얼마나 완성 되었는가
Functional correctness	Functional correctness =제품이나 시스템이 정확히 제공 하는가
Functional appropriateness	Functional appropriateness of usage objective =사용 목적의 적합성 , 사용자가 요구하는 기능수의 완성성 Functional appropriateness of system =전체 사용목표의 활성에서 만족 정도

성능 측정 기준 3가지

Time behavior	응답 시간의 만족도
Resource utilization	시스템 구동시 사용하는 자원의 양
Capacity	시스템의 최대 한계 수용량

Compatibility measure

Co-existence measure	공존해서 s/w를 사용 가능한 비율
Inter perability measure	2개 이상의 system 정보 교환시 사용 비율

Usability measure
==내 외부 사용성으로 나눠서 사용한다
==정성적 평가가 많음/ 이를 정량적으로 바꿔주는 방법이 필요하다

Appropriateness Recognizability	사용자 시스템 사용 용의성
Learn ability measure	사용자 도움말의 존재성
User interface aesthetics	사용자 인터페이스 심미성
Accessibility measure	얼마나 많은 범위에서 사용이 가능한가
Operability measure	운동 & 제어가 용이한 수준
User error protection measure	사용자 오류를 방지

Day_11. S/W Quality and Requirement

Requirement driven development
=software quality comformance of requirement
=이때 S/W 의 품질 – 요구사항의 만족 수준


핵심
=V&V model 에서 개발시 test는 요구사항을 기반으로 수행해야 한다


RDD= Requirement Drivel Development
=새로운 요구사항과 기존 요구 사항의 교체등이 중요
==Requirement Deffect 로 인해 전체 s/w의 질이 떨어지는 software crisis 가 올 수 있다
=요구사항이 부정확하기 때문에 발생한다는 의미
=요구사항의 부정확 -> 범위의 침범 –> Requirement creeping -> 시간 & 범위 증가 -> 부정확한 test & 검증이 어려움 ->시스템의 fail


요구 사항의 특성
=명시 / 묵시적 요구항으로 나뉠수 있으며 언제나 같이 진행


요구사항의 결함 3가지

목적성 결함	Concept error
이래성 관련 결함	Spec error
연결성 관련 결함	Implementation error – 개발자 실수의 bug

RBT - Requirement Based Test
=요구사항을 기반으로 Test case 를 짠다

Requirement	Test requirement
Design	Test design
Implementation	Test implementation
Delivery

Background of RBT
=S/W requirement defect – 프로젝트 실패
=s/w test coverage – 너무 많은 test / 변경 관리의 실패
=s/w test limit – 무작위 조합 , 감에 의해 시행 한다
=무작위 test (brute force) – 꿈 같은 test, 모든 조합에 대해 test 하는것


RBT의 goal
=최대의 결함을 찾기 위해 최적의 test coverage생성
=모든 기능 요구 사항을 검증할 최소 수의 test 를 생성
=조기 결함 방지 및 예방


RBT의 특징
=Well definel STS 를 가질것이라고 가정하지 않는다


개발 & TEST의 특징
=Rule Of 50:50 – technique knowledge : business knowledge
=예측 가능한 test 의 범위 계획
=하나의 단위가 준비되는 즉시 test를 시작


RBT의 전략
=명시된 요구사항에 대해 적어도 1개의 test 실시
=명시된 요구사항은 실체로 모두 사용되지 않는다
==20:80 의 원리
==50%는 아예 사용되지 않으며 30%는 가끔 사용되고 20%만이 자주 사용된다
==요구사항 우선순위가 아주 중요함
=1Test case = 1 requirement 로 1:1관계가 되어야 한다
=요구사항이 test가 가능하게 되어 있는가


좋은 test process characteristic

timely test	요구사항 작성시 시작
effective test	시스템적 test 구성
Efficiency test	자동화 & 최소 test case
Manageable test	정량적 식별 가능한 메트릭 제공

RBT Process activities

Requirement verification	Scope 지정/ 사용자 요구사항 결함 검토 Testcase requirement 대응
Defining test / completion criteria	구체적이며 정량화 가능한 목표 무섯을 어떻게 test 할지 지정 Test ability – 얼마나 쉽게 test가 가능한가
Design test case	기능과 동일한 test case 정의 / cause effect graph 중목이 발생하는 상황을 방지 =5가지 input 특징 =초기상태/test data/input data/예상결과/실제결과

Verify rest case quality
=stakeholder 전체의 검토


Implementation test case
=설계 / 코드 검토 (code inspection)


Manage test case
=요구사항과 rest case 추적성 관리
=결함 추적 & 관리 / test case 저장소 build
==기능 & 비기능 요구사항을 모두 포함한다

Day_10. ISO 25000 – S/W Quality in use model

S/W Quality in use model 의 operation environment
=품질 & 사용자 & 작업 & 사회적 환경이 특성에 의해 결정
=5가지 특성
==Effectiveness, efficiency, satisfaction, freedom from risk, context coverage


5가지 특성의 확인

Effectiveness	사용자가 시스템을 이용해 결과를 만들떄 정확성 & 안전성
Efficiency	사용자가 목표 달성시 사용하는 자원의 양 – 노력 대비의 결과 – ROI 가 중요
SATISFACTION	사용결과 목표 달성시 만족하는 정도 제품이나 시스템이 생각한대로 작동하는 정도 사용자가 시스템 사용시 느끼는 만족도 신체적 만족도 ==정량화가 어려운 특징이 있음
Freedom from risk	잠재적 위험의 제거 수준 사람들의 잠재적 위험 제거 재산의 위험 제거 수준
Context coverage	상황완전성-최초 명시된 사용환경에서 만족성 – spec sheet 내에서 작동성 Flexibility 처음 지정 상황이 아닌 사용환경 변경시의 작동성 =spec sheet 이상에서 작동성

Product quality model 보다 quality in use model 이 바라보는 범위가 더 방대하다
=두가지 모두 check list 로 만들어서 사용한다
=사용대상, 목적에 따라 포함하는 영역이 다르기 때문에 모든 품질을 정하는 것은 불가능 하다


가장 중요한 요소
=quality model 의 작성 / 4가지 단계

Quality goal 작성	왜 이것을 사용해야 하는지 정함
Quality characteristic
Sub characteristic
Metric 작성

Product model vs stakeholder
=product model = stakeholder needs 를 수집하기 위해 framework 제공

기본 사용자	기본 목표를 달성하기 위한 시스템과의 상호 작용
보조 사용자	지원 제공 – 컨텐츠 제공자,시스템,보안 관리자,분석가,설계자
간접 사용자	출력은 받지만 system 과 상호 작용하지 않는 사람

Day_09. ISO 25000 (Square) Model

ISO Quality Model generation

1st Generation	ISO – 9126
2nd Generation	ISO - 25000

ISO – 25000 등장배경
=Technology 중심 – 소비자 이해자 stackholder 관점 중심으로의 이동
=SDLC -> SPLC 로의 관점 변화
=Product definition -> development -> product in use


ISO 19288
=S/W life cycle process 의 등장

ISO – 9126	3가지 ISO 종합 – ISO 25000
ISO – 14598
ISO - 15288

ISO – 25000의 목적
=요구사항의 정의
=측정 & 평가
=Requirement measure Evaluate


ISO – 25000의 structure
=4+1 structure
==4개의 module 이 합처진 것 – 2503 + 2501 + 2502 + 2504


Iso 25000의 특징
=요구사항의 제대로 된 반영을 Evaluation 하는게 핵심
=제품의 특징을 계층적으로 분석해서 측정 – 제품의 특징을 구분하고 서브특징을 정의한다


=8가지 특성

Function suitability	Performance efficiency
Compatibility	Usability
Reliability	Security
Maintainability	portability

 

Functional suitability	기능적 완전성 / 정확성 / 적합성	s/w가 무엇을 제공하는가
Performance efficiency	시간 반응성 , 자원 활용성 , 용량	s/w가 최적의 리소스를 사용하는가
Compatibility	공존성 , 상호 운용성	Cross flatform 에서 작동하나,다른 제품과 데이터를 공유할수 있는가
Usability	적절 인식/학습/운영성	특정 사용자가 특정 조건에서 s/w를 사용 가능한가
Usability	사용자 오류방지,사용자 인터페이스 접근성	사용자가 특정 조건에서 s/w를 사용 가능한가
Reliability	성숙도/가용성/결함 허용성 , 복구성	s/w가 정상적으로 작동 하는가
Security	기밀/무결/부인방지/책임/진위성	s/w가 정보와 data를 보호 하는가
Maintainability	모듈/재사용/분석/수집/테스트	환경의 변화에 적응하고 수정/개선이 가능한가
Portability	적응/설치/교체	s/w를 다양한 환경에서 사용이 가능한가

Day_08. S/W Quality Model

S/W Quality management의 정의
=process 하에서 일어나 규정을 지켜서 만들었는지 확인 하는 것

품질 모델의 목적
=시스템 품질의 정형화 –품질 요구사항의 기술과 품질 평가의 기반구조를 제공하는 특성들과 관계의 집합
=등장 이유 – 품질 개념의 모호성 품질 속성의 정의 , 품질 측정 기준 정의


품질의 관점 2가지

Process	기능과 요구사항이 만족하게 하기 위한 Process 와 완성 제품인 Product
Product

3가지 관점을 통과하는 ISO 시리즈

9000	Quality Management System
25000	Product Quality
12207	Process Quality

3 step of ISO

9126 / 25000	Basic Standard
12207	Best Practice
CMMI / SPICE	Improvement

Quality Model 의 4가지 관점

반복성	Repeatability
재생성	Reproduct ability
공정성	Impartiality
객관성	Objectivity – 결과는 주관전 판단을 줄여야 한다

품질요소에 영향을 주는 Factor

목적(Objective)	대상(Subjective)
주체	시기(Moment)
방법(Techniquies)	자원(cost/benefits)

Model framework

Quality	충족해야할 품질
Quality factor	시스템 외부에서 모임 , 사용자/관리자 중심 – 추상성
Quality Sub Factor	시스템 내부품질 / 개발자 중심 – 구체화 되었음
Metric	품질측정 방법 / 척도 – 평가자 품질 /기본이 됨

품질 모델은 대부분 상호 보완 – 어떤것은 충돌 – 적임을 기억해야 함


S/W 품질 모델의 세대(Generation)

1st generation	ISO - 9126 / 14598 / 12119
2nd Generation	ISO – 25000 SQUARE model

ISO-9126 특징
=사용자 관점의 S/W특징
=계측 구조의 모형
=측정 등급부여 평가의 방법(How)는 제공하지 않는다


품질 특성의 측정
=객관적 평가를 가능하게 하기 위해
=Matric 의 중요성 / 모든 단계에서 적용
=분석 – 설계- 구현 – 시험 – 군영등의 단계에 모두 측정 기능이 필요


Process 의 생명주기에 따른 품질
=Process quality – Internal quality – External quality – quality in use
--모두 상호 보완 되는 특징을 가지고 있다

Day_07. 중간고사 – Midterm Exam

중간고사 실시

Day_06. S/W Verification & Validation

V모델 – Verification & Validation
=검증 & 확인 의 방법론
=특정 s/w가 특정 목적에 부합 한다고 해서 결함이 없는게 아니다
=V&V 는 전체 S/W의 생명 주기에 적용된다
=목적 : 결함을 발견 하는 것 ( 해결이 아니다)
=SYSTEM 이 활용 가능한지 확인 하는것
==verification – 코드개발 완료까지 (검증)
==validation – 코드개발 완료부터 (확인)


검증 – verification
=특정 개발 단계에서 모든 요구사항을 충족 하는지 확인 하는 것
=static testing – Review, 요구사항 문서 , spec시트 , 산출물


확인 – validation
=최종 제품이 고객의 요구사항을 충족하는지 확인
=Dynamic testion – prototype source code


Static test
=결함의 예방이 최고
=발견한 결함의 발견 & 수정
=결함 충격의 감소
=개발자가 결과물을 review 해서 s/w결함을 발견


Artifacts inspection ( 요구사항/설계/코드/Test)
=실행하지 않고 문서로 Review
=Review 의 이유 – 가장 effective 한 것을 탐색한다
==요구사항 inspection을 하지 않으면 결함을 가지고 시스템을 만들기 시작하게 된다


Static test 방법
=Formal approach – technical review , inspection
=informal approach – 동료와의 workthrough , 동료 검토


Static test 3 method

Checklist based reading technique	체크리스트 기반 모든 유형의 결함을 다루지 못한다 잠재적 문제/결함을 생략한다 지속적 update가 필요
Defect based reading	결함의 유형에 집중 결함 분류 과정 =결함을 동료에 질문 - 체크리스트에 파생된 시나리오 작성 - 검토자에게 분배 – 탐지 Domain 지식이 매주 중요
Perspective based reading	발견한 defect 중복 최소화 다양한 stakeholder 관점에서 sw 문서 조사 역할에 의존하는 관점 식별

S/W Inspection
=early , quickly , cheaply – 에러 발생 시점에 가장 가까운 시기에 제기
=design / code 단계에서 실시하면 가장 좋은 효율이 나온다
==단계에 따라서 사용하는 기술이 모두 다르다
==inspection을 하고 test를 진행해야 한다
==90%이상의 비율에서 inspection의 효과가 가장 뛰어나다
=quality 와 test는 포함관계 , test는 품질안에 들어간다
=IEEE 기준은 매우 허들이 높아서 기간과 비용이 많이 든다


Dynamic test
=요구사항 검증을 통한 산출물과의 구조적 검증
=Error 가 없는 System 은 없다
=요구사항 검증 – 기능/비기능/정형/사용자 검증


Debugging
=Test 와의 차이점 – 노출된 결함의 제거
=inspection – 결과로 오류 원인 탐색
=deduction – 원인을 나열하고 사실을 규명
=backtracking – 오류 발견 시점에서 역행한다


Top – 4 TYPE of S/W Testing

Functional	Basic functions working well Easy navigation Error handling Accessibility
UI/UX	Usefulness Ease Accuracy Appeal
Security	Data protection Interface bugs and holes Admin access
Load	Response time Performance under various loads

낮은 품질의 이유
=낮은 품질은 그렇게 개발 되었기 때문이다


Test 의 속성
=TEST에 의존하면 안된다
==Test는 품질의 개선이 아닌 품질의 확인이다
==통상 Test는 개발의 5배 정도의 노력이 투입된다


Test 준비물

Process	Result의 통일성
Tool	상황에 맞는 Tool 을 따로 설정해라
Methology	Test 방법론 / 설계방식 – ex)test design
Standard	표준은 많으나 보통 ISO 29119를 사용

TDD – Test driven Development
=Code를 생성하기 전에 Test 하기
===??어떻게 진행하는가?

Step - 1	Code 작성전 test case 제작
Step – 2	Test에 해당하는 code 작성
Step – 3	제작된 code가 Test 잘 되는지 확인한다
Step – 4	Step – 1 으로 돌아간다