소프트웨어 품질보증

13. 소프트웨어 품질보증

13.1 소프트웨어 품질(quality): 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측정 가능한 기능 및 특성 (소프트웨어가 지닌 바람직한 속성의 정도, 성능이 향상되는 것은 아님)

 

- 품질의 분류

설계 품질	설계자가 한 품목을 위해 규정한 특성 (요구사항을 지키는)
일치 품질	설계 내용들이 개발 과정에서 지켜지는 정도 (구현된 정도)

 

- 품질 관리 (quality control): 주어진 요구사항에 맞는 소프트웨어를 개발하기 위해 소프트웨어 개발의 전 과정 동안에 이루어지는 모든 활동과 그 활동의 결과로 생산되는 산출물(program)에 대한 품질을 통제하고 보증하기 위한 작업.

 

▷ 품질보증

- 관점: 입장에 따른 품질보증 (소프트웨어를 보는)

- 개발자: 개발과 디버깅이 제대로 되었는지

- 검사자: 검증이 제대로 됐는지

- 사용자(발주자): 확인 (원하는 대로 만들어졌는지)

- 품질보증 확인자: 품질보증

 

13.1.1 품질 표준(목표): 명확하게 정의된 소프트웨어의 특성을 의미하며, 소프트웨어의 품질을 평가하는 기준 항목으로 사용

 

- 소프트웨어의 운영적인 특성, 변경 수용 능력, 새로운 환경에 대한 소프트웨어의 적용 능력에 따라 분류

 

품질목표 - McCall의 품질 목표(3가지) [내용도 알면 좋음]

구분	품질표준	의미
소프트웨어 운영 특성 (제품 운영)	정확성 (correctness)	사용자의 요구 기능을 충족시키는 정도
	신뢰성 (reliability)	정확하고 일관된 결과(똑같은 입력을 n번하여 일정할 때)를 얻기 위해 요구된 기능을 오류 없이 수행하는 정도
	효율성 (effeciency)	자원 자체를 최소로 사용하여 하고자 했던 목적을 달성할 수 있어야 함
	무결성 (integrity)	허용되지 않는 사용(허가받지 않은, 프로그램 내에 있으면 안될 기능/필요없는 기능)이나 자료의 변경을 제어하는 정도(임의 변경/허용X 접근 등)
	사용 용이성(유용성) (usability)	쉽게 말해 사용하기 쉽게 만들어져야 한다. 적절한 사용자 인터페이스와 문서를 가지고 있어야 함
소프트웨어 변경수용 능력 (제품 개조)	유지보수성 (maintainability)	변경 및 오류 사항의 교정에 대한 노력을 최소화해야 함
	유연성 (flexibility)	쉽게 수정할 수 있어야 한다.
	시험 역량(검사성) (testability)	의도된 기능(요구된)이 수행하도록 보장되는지 시험/확인하는 것
소프트웨어 적용 능력 (제품 전이)	이식성 (portability)	다양한 하드웨어나 운영체제에서도 운용 가능할 수 있도록
	재사용성 (reusability)	다른 목적으로 다른 시스템이나 프로그램에서 쓸 수 있도록
	상호 운용성 (interoperability)	정보 교환이 가능하도록

13.1.2 소프트웨어 품질보증(SQA, Software Quality Assurance): 어떠한 소프트웨어가 이미 설정된 요구사항과 일치하는가를 확인하는 데 필요한 개발 단계 전체에 걸친 계획적이고 체계적인 작업

 

- 소프트웨어 개발 초기에 특성과 요구사항을 철저히 파악해 품질 목표를 설정, 목표에 따라 충족 여부를 점검하고, 개발 후에는 디버깅과 시험 과정을 거침 [즉, 모든 과정에 대한 품질 관리 과정을 두고 지켜졌는지 확인하는 것]

 

13.1.3 정형 기술 검토(FTR, Formal Technical review): 가장 일반적인 검토 방법이고 소프트웨어 기술자(개발자)들에 의해 수행되는 품질보증 활동

 

- 정형 기술 검토의 유형에는 검토 회의(Walkthrough), 검열(Inspections) 등이 있으며 이는 모두 회의 형태로 수행

 

검토	- 소프트웨어 품질보증을 위해서 검토 작업이 필요 - 검토는 분석과 설계, 구현 등 개발 단계 동안의 오류와 결함을 발견하여 정제시키는 역할을 함

▷ 목적

- 검토 중인 소프트웨어가 해당 요구사항과 일치하는지 검증

- 소프트웨어가 미리 정해진 표준에 따라 표현되고 있는지 확인하고, 기능과 로직에 오류가 있는지 확인

- 일관된 방식으로 개발되도록 함

- 프로젝트를 보다 용이하게 관리하도록 하기 위해 사용

 

▷ 검토 지침 사항 [암기하면서 볼 필요X 훑어]

- 제품의 검토에만 집중 (만들어진 소프트웨어 그 자체)

- 의제를 제한해 진행

- 논쟁과 반박을 제한

- 해결책과 개선책에 대해 논하지 않음

- 참가수 제한과 사전 준비를 강요 (검토 자료 제공)

- 체크 리스트를 개발

- 검토 과정/결과 재검토

 

13.1.3.1 검토 회의(Walkthrough)

- 소프트웨어 개발의 각 단계에서 개최하는 기술 평가 회의, 소프트웨어 구성 요소와 같은 작은 단위를 검토 (전체X)

- 오류의 조기 검출을 목적으로 함

- 오류는 회의 기간 동안 해결하는 게 아닌 회의 후에 해결

- 3~5명이 참여하고 회의 시간은 2시간 이내

 

▷ 검토 회의 참가자: 검토 책임자, 검토자, 제작자 (일반적 구성)

 

구조적 검토 회의 (structured walkthrough)

프로젝트에 참여한 사람들이 회의 절차와 핵심 사항을 체계적으로 다룸으로써 개발 단계에서 작성된 문서와 프로그램을 조사하고 문제점을 찾아내는 과정

 

13.1.3.2 검열(Inspections, 심사)

- 검토 회의를 발전시킨 형태, 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하고 개선하는 데 사용

- '검열' 팀은 관련 분야에 대해 훈련을 받은 소수의 요원으로 구성되며, 검열자는 검열 항목에 대한 체크 리스트를 이용해 작업을 수행

 

13.1.3.3 기타 품질보증 활동 [✔용어들은 기억해줘야 한다, 구분할 수 있어야 함]

검증✔ (verification)	설계의 과정이 옳은지, 프로그램이나 하드웨어에 오류가 있는지 확인 (= 오류 찾기 / 개발자가 함)
확인✔ (validation)	올바른 제품을 생산하도록 정의, 분석이 잘 되었는지 검사 (= 오류 찾기 / 검사자가 함)
인증✔ (certification)	사용자 보호 입장의 전문가가 소프트웨어 품질을 확인하는 활동 (= 오류 찾기 / 사용자가 함)
소프트웨어 시험 (test)	오류를 찾기 위해 프로그램을 수행시키는 활동
오류 수정 (debugging)	노출된 오류의 본질을 정확히 진단하고 바르게 고치는 활동

 

13.2 소프트웨어의 위험 관리

위험 관리(risk analysis): 프로젝트 추진 과정에서 예상되는 각종 돌발 상황(위험)을 미리 예상하고 이에 대한 적절한 대책을 수립하는 일련의 활동을 의미

 

- 위험은 불확실성¹과 손실²을 내재하는데, 이러한 위험의 불확실성을 감소시키고 손실에 대비하는 작업이 위험 관리이다. (1. 위험은 발생할 수 있지만, 그렇지 않을 수도 있음 / 2. 위험이 실제 발생되면 원하지 않는 결과나 손실이 발생)

- 위험을 식별한 후 발생 확률을 산정, 그 영향에 대해 추측해 해당 위험에 대비하는 계획을 마련

 

13.2.1 위험의 범주

프로젝트 위험 (project risk)	프로젝트 계획을 위협하는 것, 일정이 지연되고 비용이 증가
기술 위험 (technical risk)	소프트웨어의 품질이나 시기를 위협하는 것, 구현이 어려워지거나 불가능하게 됨
비즈니스 위험 (business risk)	소프트웨어의 생존 가능성을 위협하는 것, 사용자들이 원치 않는 제품이나 전력에 맞지 않는 제품 등을 개발

 

13.2.2 위험의 종류

- 위험의 종류는 Charette에 의해 다음과 같이 제안

알려진 위험 (known risk)	프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견될 수 있는 위험
예측 가능한 위험 (predictable risk)	과거 경험으로부터 예측할 수 있는 위험 (가장 주의해야 하는 위험 - 예측하여 위험이 없도록 해야 함, 아래에 상세 서술)
예측 불가능한 위험 (unpredictable risk)	사전에 예측이 힘든 위험

 

- 예측 가능한 위험 항목

제품 크기	적절한 규모를 해야 함
비즈니스 영향	관리나 영업에 대한 위험
고객 특성	사용자(고객)들의 니즈 정확히 파악
프로세스 정의	개발 과정상의 위험
개발 환경	도구나 지원상의 위험 (운영체제의 바뀜 등)
기술진의 규모와 경험	인원수, 기술에 대한 역량/경험 등

 

13.2.3 위험 관리의 절차: 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치 순.

 

▷ 위험 식별(risk identification): 위험 요소를 파악하는 작업

▷ 위험 분석 및 평가

- 프로젝트에 내재한 위험 요소 인식/영향을 분석하는 활동, 위험 추산(risk estimation) 작업을 통해 수행

- 가능한 모든 위험 요소와 영향을 분석해 의사결정에 반영

- 위험 요소에 대해 효과적이지 못한 관리는 프로젝트 실패의 결과를 가져올 수 있다.

- 위험을 추산해 위험표(risk table)를 작성해 활용

ex.

위험 내용	위험 범주(종류)	발생 확률	영향력	위험 감시 및 조치
기술력 부족	BU	60%	2
제품 규모의 추적 낮음	PS	30%	3
…	…	…	…

▷ 위험 관리 계획

위험을 예방하고 위험 발생 시 대책을 준비

▷ 위험 감시 및 조치

위험 회피 (risk avoidance)	위험 관리에 대한 최상의 전략으로 위험이 발생될 것을 예상해 회피
위험 감시 (risk monitoring)	위험 요소 징후들에 대해 계속적으로 인지하는 것
위험 관리(risk management) 및 비상 계획(contingency plan) 수립	위험 회피 전략이 실패할 경우 위험에 대해 관리/대비 해 비상 계획을 세움

 

★13.3 소프트웨어의 유지보수 [중요! SDLC에서 가장 많은, 80%를 차지함]

▷ 유지보수(maintenance): 개발된 소프트웨어의 품질을 항상 최상의 상태로 유지하기 위한 것으로, 소프트웨어 개발 단계 중 가장 많은 노력과 비용이 투입되는 단계

- 유지보수는 소프트웨어가 사용자에게 인수되어 설치된 후 발생하는 모든 공학적 작업

- 유지보수를 용이하게 하려면 시험 용이성, 이해성, 수정 용이성, 이식성 등이 고려되어야 함

★유지보수는 수정(corrective, 하자) 보수, 적응(adaptive, 환경) 보수, 완전화(perfective, 기능) 보수, 예방(preventive, 미래) 보수 활동으로 구분할 수 있고, 이 활동으로 소프트웨어 수명을 연장시키는 작업 [유지보수의 종류 4가지 기억하기]

 

★ 유지보수의 분류

수정 보수	21%	검사 단계에서 발견하지 못한 잠재적인 오류를 찾아 수정하는 활동으로 오류의 수정과 진단을 포함
적응 보수	25%	소프트웨어의 수정 기간 중 발생하는 환경의 변화(하드웨어, 운영체제 등)를 적응 시켜주는 것
완전화 보수	50%	본래의 기능에 새로운 기능을 추가하거나 성능을 개선함 (완전하게 만드는 작업)
예방 보수	4%	미래에 발생할 거라 예상되는 문제를 미리 수정해주는 것들을 일컬음 (=소프트웨어 재공학)

* 전체 유지 보수를 100%라 할 때, 각자 비중의 퍼센티지

 

13.3.1 유지보수의 과정

① 유지보수 요구: 유지보수 활동이 필요한 경우에 수행

② 현 시스템에 대한 이해: 오류가 어디에서 어떻게 발생했는지를 확인함

③ 수정 및 시험: 테스트를 통해 제대로 수정되었는지 확인

 

13.3.2 유지보수의 문제점 [실제로도 쉽지 않은 이유..]

- 다른 사람이 개발한 소프트웨어는 이해하기 어렵고, 소프트웨어 개발자들은 이직률이 높기 때문에 이미 개발된 소프트웨어에 대한 전문적인 설명을 들을 수 없다.

- 소프트웨어에 대한 변경이 자주 발생하기 때문에 변경된 내용을 문서화를 반드시 해야한다.

- 소프트웨어에 대한 적절한 문서가 없거나 문서의 질이 형편없을 수 있다.

- 대부분의 소프트웨어는 변경 가능하도록 설계되지 않는다.

 

▷ 유지보수의 부작용 [기억하기!]

코딩 부작용	코딩 내용의 변경으로 인해 발생하는 부작용
자료 부작용	자료나 자료 구조의 변경으로 인해 발생하는 부작용
문서화 부작용	자료 코드에 대한 변경이 설계문서나 사용자가 사용하는 매뉴얼에 적용되지 않을 때 발생하는 부작용

☞ 즉 문서화는 필수적으로 따라줘야 한다는 것.