📍 Chapter 2 : 애플리케이션 결함 조치

---

🍀 Section 1 | 결함 관리

1. 결함의 정의

• 프로그램과 명세서 간의 차이, 업무 내용의 불일치
• 기대 결과와 실제 관찰 결과 간의 차이

2. 결함 관리 프로세스

프로세스	설명
⓵ 결함 관리 계획	전체 프로세스에서 결함 관리에 대한 일정, 인력, 업무 프로세스를 확보하여 계획을 수립한다.
⓶ 결함 기록	테스터는 발견된 결함에 대한 정보를 결함 관리 DB에 기록한다.
⓷ 결함 검토	등록된 결함에 있어서 주요 내용을 검토하고, 결함을 수정할 개발자에게 전달한다.
⓸ 결함 수정	개발자는 할당된 결함의 프로그램을 수정한다.
⓹ 결함 재확인	테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행한다.
⓺ 결함 상태 추적 및 모니터링 활동	결함 관리 팀장은 결함 관리 DB를 이용하여 대시보드 또는 게시판 형태의 서비스를 제공한다.
⓻ 최종 결함 분석 및 보고서 작성	발견된 결함에 대한 내용과 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료한다.

3. 결함의 상태 및 추적

❗️ 영어도 같이 외우도록 하자잇

상태 및 추적	설명
⓵ 결함 등록(Open)	테스터와 품질 관리(QA) 담당자에 의해 결함이 처음 발견되어 등록되었지만, 아직 분석이 되지 않은 상태
⓶ 결함 검토(Reviewed)	등록된 결함을 담당 모듈 개발자, 테스터, 프로그램 리더, 품질 관리(QA) 담당자와 검토하는 상태
⓷ 결함 할당(Assigned)	결함의 영향 분석 및 수정을 위해 개발자와 문제 해결 담당자에게 할당된 상태
⓸ 결함 수정(Resolved)	개발자에 의해 결함이 수정 완료된 상태
⓹ 결함 조치 보류(Deferred)	수정이 필요한 결함이지만 현재 수정이 불가능해서 연기된 상태. 우선순위, 일정 등을 고려하여 재오픈을 준비하는 상태
⓺ 결함 종료(Closed)	발견된 결함이 해결되고 테스터와 품질 관리(QA) 담당자에 의해 종료 승인을 한 상태
⓻ 결함 해제(Clarified)	테스터, 프로그램 리더, 품질 관리(QA) 담당자가 결함을 검토한 결과, 결함이 아니라고 판명된 경우

4. 결함 분류

• 결함을 분석하는 단계에서 아래와 같은 유형으로 나누어야 한다.
• 시스템 결함, 기능 결함, GUI 결함, 문서 결함 등 크게 4가지의 유형으로 분류 된다.

1) 시스템 결함

• 애플리케이션 환경과 DB 처리에서 발생하는 결함을 말한다.

결함 형태	설명
비정상적인 종료 및 중단	특정 기능 실행 시 응용 프로그램의 작동 정지, 종료, 시스템 다운이 되는 경우
응답 시간 지연	응용 프로그램 작동 후 조회 또는 보고서 출력 시 지연되는 경우와 메모리 부족, 하드웨어와 소프트웨어의 비일관성으로 발생되는 경우
DB 에러	응용 프로그램 작동 후 사용자 데이터의 등록, 수정, 삭제, 조회가 정상적으로 작동하지 않는 경우

2) 기능 결함

• 기획, 설계, 업무 시나리오 단계에서 발생된 결함을 말한다.

결함 형태	설명
요구사항 미반영/불일치	요구사항에 명시된 기능이 응용 프로그램에 구현되지 않은 경우와 다르게 구현되어 작동하는 경우
부정확한 비즈니스 프로세스	기능 자체는 수행되나 내부 프로세스 로직의 문제로 부정확한 결과를 내는 경우
스크립트 에러	특정 기능 실행 시 웹 브라우저에서 스크립트 오류가 발생하는 경우
타 시스템 연동 시 오류	기존 시스템과의 연동을 통해 데이터를 주고받는 과정에서 오류가 발생하는 경우

3) GUI(Graphical User Interface) 결함

• 사용자 화면 설계에서 발생된 결함을 말한다.

결함 형태	설명
응용 프로그램의 UI 비일관성	프로젝트에서 정의한 UI 표준과 상이하게 구현된 경우
부정확한 커서/메시지	커서의 위치가 입력 대상의 첫 번째 필드에 위치해 있지 않거나, 탭 시퀀스가 순차적으로 동작하지 않는 경우. 각 기능에서 제공하는 메시지 내용이 부정확한 내용을 보여주는 경우.
데이터 타입의 표시 오류	입력 필드에 지정된 형식과 다르게 입력해도 저장이 되는 경우와 입력 필드에 유효하지 않은 데이터(Invalid Data)를 입력했을 때 오류가 나는 경우

4) 문서 결함

• 기획자, 사용자, 개발자 간의 의사소통과 기록이 원활하지 않은 경우에 발생하는 결함을 말한다.
• 사용자의 온라인/오프라인 메뉴얼의 불일치, 요구사항 분석서와 기능 요구사항의 불일치로 인한 불완전한 상태의 문서로 발생한 결함을 말한다.

5. 결함 심각도

• 겨러 개의 결함 중 전체 시스템에 결함이 미치는 영향을 레벨별로 나눈다.
• 우선 순위 : High ⇒ Medium ⇒ Low

심각도	설명
High	‧ 시스템이 중단(또는 다운)되어 더 이상 프로세스를 진행할 수 없게 만드는 결함
	‧ 시스템의 핵심 요구사항 미구현, 시스템 다운, 장시간 시스템 응답 지연, 시스템 복구 후 데이터 왜곡 등
Medium	‧ 시스템의 흐름에 영향을 미치는 결함
	‧ 부정확한 기능, 부정확한 업무 프로세스, 데이터 필드 형식의 오류, DB 에러, 보안 관련 오류 등
Low	‧ 시스템의 흐름에는 영향을 미치지 않지만, 상황에 맞지 않는 용도와 화면 구성(Configuration) 등의 결함
	‧ 부정확한 GUI 및 메시지, 에러 시 메시지 미출력, 화면상의 문법/철자 오류 등

---

🚀 예상문제

1) 이것은 프로그램과 명세서 간의 차이 즉, 업무 내용 불일치이다. 사용자가 기대하는 기대치를 만족하지 못할 때 변경이 필요한 모든 것을 이것이라 하는데 이것을 쓰시오.

• 답 : 결함

2) 결함의 상태 및 추적 단계 중 하나로 개발자에 의해 결함의 수정이 완료된 상태를 무엇이라 하는지 쓰시오.

• 답 : 결함 수정(Resolved)

3) 다음 중 결함 분류 유형으로 올바르지 않은 것을 골라 쓰시오.

ㄱ. 실행 결과 결함
ㄴ. 시스템 결함
ㄷ. GUI 결함
ㄹ. 기능 결함

• 답 : ㄱ

---

🍀 Section 2 | 결함 조치

1. 소프트웨어 테스트 기법

💡 키워드

• 단위 테스트 : 컴포넌트, 모듈
• 통합 테스트 : 상호작용
• 시스템 테스트 : 총괄
• 인수 테스트 : 최종

1) 단위 테스트 기법

• 테스트 가능한 단위인 컴포넌트나 모듈 내의 결함을 찾고 기능을 검증하기 위한 테스트
• 대표적으로 Junit과 Mock 테스트 기법이 있다.

💡 xunit

• 다양한 코드 중심의 테스트 프레임워크
• 소프트웨어의 함수, 클래스 등 서로 다른 구성 단위를 검사한다.
• Java(Junit), C++(Cppunit), .NET(Nunit)

💡 Mock 테스트

• 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해놓고 테스트하는 기법

Mock 테스트 종류	설명
Dummy	객체의 전달에만 사용되고 실제로는 사용되지 않으며, 주로 매개 변수 목록을 채우는 데 쓰임
Fake	실제로 동작하도록 구현되지만, 보통 바른 구현을 위해 실제 환경과는 다르게 구현할 수 있음
Stubs	테스트를 위해 미리 준비한 응답만을 제공하는 것. 그 외의 상황에 대해서는 정상적인 작동을 하지 못하는 것
Mocks	스펙을 통해 정의된 응답을 받고 다른 응답을 받을 경우 예외를 발생하도록 구현되어 있으며, 응답에 대한 확인을 수행하는 역할

2) 통합 테스트 기법

• 전체 시스템이 통합 완료될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인하고, 하드웨어와 소프트웨어 구성요소 간의 상호작용을 테스트하는 것이 주요 목적
• 업무 간의 연계성과 상호 운영성 중심의 테스트 수행

설계 기법

설계 기법	설명
테스트 설계	개발된 소프트웨어나 시스템의 요구사항, 요구사항 명세서, 업무 구조, 시스템 구조 등을 기반으로 소프트웨어의 어떤 부분을 어떻게 접근하여 테스트할지에 대한 테스트 상황과 방법을 파악하는 것
테스트 구현	테스트 설계를 구체화시켜 테스트 케이스를 도출하고 작성하는 것
테스트 설계 방법	테스트 상황과 방법을 구체화 시키기 위한 수단 및 도구

설계 방법

설계 방법	설명
보다 작은 케이스	‧ 동등 클래스(Equivalence Class)
	‧ 한 자리 정수를 더하는 프로그램인 경우, "1+1, 1+2, ..., 9+9"까지 81가지 케이스는 모두 동등한 경우이다.
	‧ 위의 경우를 모두 모아서 몇 가지 케이스만 테스트하면 되는 경우
보다 많은 버그 찾기	경계 테스트(Boudary Test)
	‧ 위의 동등 클래스 중 대표 클래스를 뽑을 때 가장자리, 즉 경계값을 뽑는 경우

3) 시스템 테스트 기법

• 시스템 테스트 업무의 진행 전체를 총괄할 수 있도록 절차 및 각 프로세스별 세부 업무를 알아야한다.
• 결과에 대한 분석 및 해결 방안을 제시할 수 있어야 한다.
• 부하 및 성능 테스트, 장애 복구 테스트, 보안 테스트가 있다.

4) 인수 테스트 기법

• 최종 사용자가 요구한 기능이 제대로 반영되었는지, 인수 조건에 만족하는지를 테스트 하는 기법
• 요구 기능 만족 여부, 사용 편리성에 대하여 실제 운영 환경에서 실행되며, 고객이 주도하는 테스트

2. 결함 관리의 이해

1) 결함 관련 용어

용어	설명
⓵ 에러(Error)	‧ 소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정확한 결과
	‧ 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등
⓶ 오류(Fault)	‧ 프로그램 코드 상에 존재하는 것으로 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생
	‧ 잘못된 연산자가 사용된 경우에 프로그램 이 서브루틴으로부터의 에러 리턴을 점검하는 코드가 누락된 것
⓷ 실패(Failure)	‧ 정상적인 프로그램과 비정상적인 프로그램의 실행 결과 차이
	‧ 프로그램 실행 중에 프로그램의 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.
⓸ 결함(Defect)	‧ 버그, 에러, 오류, 실패, 프로그램실행에 대한 문제점, 프로그램 개선 사항 등의 전체를 포괄하는 용어

2) 결함 판단 기준

결함의 판단은 기능 명세서를 기준으로 한다.

⓵ 기능 명세서에 가능하다고 명시된 동작을 수행하지 않는 경우
⓶ 기능 명세서에 불가능하다고 명시된 동작을 수행하는 경우
⓷ 기능 명세서에 명시되어 있지 않은 동작을 수행하는 경우
⓸ 기능 명세서에 명시되어 있지 않지만 수행해야 할 동작을 수행하지 않는 경우
⓹ 테스터의 시각에서 볼 때 문제가 있다고 판단되는 경우(이해하기 어려움, 까다로운 기능, 비정상적으로 느린 기능 등)

3. 테스트 격언(Testing Axioms)

1) 소프트웨어를 완벽하게 테스트 하는것은 불가능하다.

• 가능한 입력과 출력의 수가 너무 많다.
• 소프트웨어 명세서와 결함이 주관적이다.

2) 소프트웨어 테스트는 위험을 동반하는 훈련이다.

• 가능한 모든 테스트 시나리오와 테스트 케이스를 테스트하지 않는다는 것은 위험을 감수하기로 했다는 것과 같다.
• 테스터는 중요한 것과 중요하지 않은 것을 현명하게 구분해야 한다.

3) 테스트 작업으로 결함이 존재하지 않는다는 사실을 입증할 수 없다.

• 테스트를 통해 소프트웨어에 결함이 없다는 것을 보장할 수 없다.
• 테스트 결과에 결함이 없다는 뜻
• 테스트 결과에 없더라도 결함이 없다는 것이 아니다.

4) 아래와 같은 사유로 인하여 발견한 모든 결함을 수정할 수는 없다.

• 타이트한 작업 일정
• 외부적인 요인으로 결함이 아님에도 결함으로 판단되는 경우
  • 테스트 환경 미비, 사용자 환경 자체 장애, 법률 또는 규정 변경 등
• 각각의 프로그램 간의 결합도가 높아 고치기 위험한 결함
• 현실에서 발생할 가능성(자연재해)이 낮아 고칠 가치가 없는 결함

5) 발견한 결함이 많을수록 남아 있는 결함의 수도 많아.

4. 소프트웨어 테스터

1) 역할

• 결함을 가능한 빨리 발견
• 결함이 수정 및 보완되었는지 확인

2) 요구 능력

• 탐구심과 문제 해결력
• 창의력을 발휘하여 결함을 찾기 위한 새로운 접근법 사용
• 가능한 한도 내에서 적당한 수준의 완벽성 추구
• 개발자에게 그들의 작품에 결함이 있다는 말을 조리있게 할 것

🚀 예상문제

1) 다음 빈칸에 알맞은 용어를 작성하시오.

용어	설명
( ⓵ )	소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정확한 결과로, 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등이 있다.
( ⓶ )	프로그램 코드 상에 존재하는 것으로 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생한다.
( ⓷ )	정상적인 프로그램과 비정상적인 프로그램의 실행 결과 차이를 의미하며, 프로그램 실행 중에 프로그램의 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.
( ⓸ )	버그, 에러, 오류, 실패, 프로그램 실행에 대한 문제점, 프로그램 개선 사항 등의 전체를 포괄하는 용어이다.

• 답
  • ⓵ : 에러(Error)
  • ⓶ : 오류(Fault)
  • ⓷ : 실패(Failure)
  • ⓸ : 결함(Defect)

2) 다음 Mock 테스트 중 빈칸에 들어가는 유형을 작성하시오.

Mock 테스트 종류	설명
Dummy	객체의 전달에만 사용되고 실제로는 사용되지 않으며, 주로 메게 변수 목록을 채우는 데 쓰임
( ? )	실제로 동작하도록 구현되지만, 보통 바른 구현을 위해 실제 환경과는 다르게 구현할 수 있음
Stubs	테스트를 위해 미리 준비한 응답만을 제공하는 것. 그 외의 상황에 대해서는 정상적인 작동을 하지 못하는 것
Mocks	스펙을 통해 정의된 응답을 받고 다른 응답을 받을 경우 예외를 발생하도록 구현되어 있으며, 응답에 대한 확인을 수행하는 역할

• 답 : Fake

---

🍀 Section 3 | 결함 조치 관리

1. 프로그램 코드 검토 기법

1) 소프트웨어 인스펙션의 개요

💡 소프트웨어 인스펙션(Software Inspection)

• Code Inspection 외에도 설계 및 설계 산출물까지 포괄하는 개념이다.

💡 코드 인스펙션(Code Inspection)

• 대체 불가능한 테스트
• 통계 왈, 인스펙션을 적절히 잘 수행하면 에러 90%를 찾을 수 있다.

💡 워크스루(Walkthrough)

• 코드의 품질을 평가하고 개선하기 위한 목적으로 수행되는 검토 기법
• 검토 회의라고도 한다.

• 적절한 인스펙션은 소프트웨어 개발의 전체 수명 주기에 걸친 리소스 절감과 그에 따른 비용 감소, 산출물의 품질을 항상 시킬 수 있다.

인스펙션을 해야하는 비즈니스적인 이유

• 결함을 빨리 찾을 수록 수정(fix) 비용이 적게 든다.
• 인스펙션의 데이터를 통해 업무에 집중할 수 있다.
• 인스펙션을 함으로써 교차 교육(Cross-training)을 돕는다.
• 제품의 re-engineering이 가능한 영역을 식별하도록 돕는다.

2) 소프트웨어 인스펙션 중점 항목

품질 보증(QA)의 역할

• 프로젝트에서 소프트웨어 인스펙션 업무를 담당 및 실시
• 아키텍트가 각 단계에서 원활한 업무 수행을 위해 지원을 해야한다.

아키텍트의 역할

• 코드 인스펙션의 프로세스 전반과 각 단계별 수행 업무 등을 전체적으로 이해할 필요가 있다.
• 아래와 같이 검토 절차에서 Overview와 Rework가 잘 수행될 수 있도록 지원해야 한다.
  • 자동 코드 인스펙션을 위한 환경 지원, 계획 수립 지원 활동
  • 체크리스트 정합성 검토 지원 활동
  • 인스펙션 결과 리뷰 참석
  • 발견된 결함을 수정하기 위한 개발자 리딩 지원 활동

3) 코드 인스펙션 태스크별 수행 내용

⓵ 코드 인스펙션 프로세스

구분	수행 단계	주요 내용
자동 수행	1. 범위 계획(Caplacity Plan)	인스펙션의 범위와 범위 선정 기준 결정
	2. 시작(Overview)	자동 인스펙션 수행
준비 단계	3. 준비(Preparation)	계획서 작성, 체크리스트 작성, 계획 공지, 대상 산출물 준비
이행 단계	4. 인스펙션 회의(Inspection Meeting)	사전 검토 실시, 미팅 실시
시정 조치	5. 재작업(Rework)	개발 원작자가 직접 작업
	6. 후속 처리(Follow-Up)	결과서 작성 및 보고

⓶ 코드 인스펙션 태스트별 수행 내용

구분	작업	수행 내용	산출물
자동 수행	1. 자동 인스펙션 수행	‧ 전수 검사, Quality metric, 결함 분석	코드 인스펙션 결과
준비 단계	2. 계획서 작성	‧ 일정 및 관련자, 대상 산출물 및 준비물 정의	인스펙션 계획서
	3. 체크리스트 작성	‧ 표준 체크리스트를 테일러링하여 인스펙션 체크리스트 작성	인스펙션 체크리스트
	4. 계획 공지	‧ 메일이나 공지를 통해 관련자에게 사전 공지
	5. 대상 산출물 준비	‧ 산출물 작성자가 인스펙션 시 필요한 자료를 준비
이행 단계	6. 착수 회의 실시	‧ 진행자는참여자에게 검토 주안점, 검토 방법, 역할 등을 교육
		‧ 작업자는 대상 산출물 및 참조 자료에 대한 개요 소개
	7. 사전 검토 실시	‧ 산출물, 체크리슽, 사전 검토서 양식 배포	인스펙션 결과서
		‧ 참여자별로 자료를 개별 검토하여 발견된 부적합 사항 기록
	8. 미팅 실시	‧ 사전 검토에서 발견한 부적합 사항 검증
		‧ 미팅에서 발견된 부적합 사항 추가 기재
		‧ 부적합 사항 목록 정리 또는 조치 계획 수립
	9. 결과 정리	‧ 진행자는 최종 확정된 결함 내용을 인스펙션 결과서에 정리한 후 작성자에게 배포
시정 조치	10. 보완 작업 실시	‧ 작성자는 각 결함에 대한 보완 작업 실시
	11. 시정 조치 결과 확인	‧ 진행자는 보완 완료 여부를 확인(필요 시 재검토)
	12. 결과 보고	‧ 진행자는 결과서를 작성하고 관련자에게 보고	인스펙션 결과서

용어

• 테일러링(Tailering)
  • 방법론 맞춤화
  • 프로젝트의 특성과 상황(규모, 복잡도, 기술 등)에 맞춰 표준화된 소프트웨어 개발 방법론의 절차, 기법, 산출물 등을 수정·보완하는 작업

⓷ 코드 인스펙션의 프로세스와 수행 내용

자동 코드 인스펙션

• 전체 개발된 프로그램을 대상으로 자동 인스펙션 수행

수동 코드 인스펙션

• 자동 코드 인스펙션 코드 중 에러가 많은 경우
• 업무 중에 복잡한 처리 로직이 있는 경우
• 처음 투이되는 개발자의 산출물

⓸ 코드 인스펙션 수행 시 고려사항

• 기능적으로 이상이 없는 소스코드를 대상으로 검증한다.
  • 일반적으로 인스펙션의 목적은 개발 가이드에 따른 표준 준수성을 파악하기 위함에 있기 때문
• 인스펙션의 효과는 다양하지만, 실제적으로 테스트 전 결함 발견에 따른 이익을 수행팀원들이 인식하는 것이 가장 크다고 할 수 있다.

💡 인스펙션의 효과

• 개발 가이드에 따른 체크 항목 파악
• 결함 유형 파악에 따른 차후 코딩 시 유념
• 다른 개발자의 기술 습득
• etc

4) 인스펙션과 워크스로의 차이점

구분	인스펙션	워크스루
목적	결함 파악 및 제거	산출물 평가 및 개선
수행 조건	완성도가 기준 이상일 때	팀이나 관리자가 필요할 때
결함 수정 여부	모든 결함은 제거되어야함	저자 결정
변경 사항 검증	진행자가 재작업 결과 확인	저자 결정
검토자 인원	3~6명	2~7명
참여자	동료	기술 전문가 및 동료
검토 인도자	교육받은 진행자(Moderator)	저자
검토 준비 여부	체크리스트를 이용한 검토	일반적으로 준비하지 않음
검토 분량	적고 상세함	많음
검토 속도	느림	빠름
발표자	검토자(Reader)	저자
지표 수집 여부	모든 검토자들이 기록함	하지 않음
보고서	결함 리스트 및 측정 지표	약식 보고서 또는 회의록
데이터 측정 여부	필수	권장 사항
체크리스트 사용 여부	사용함	사용 안함

💡 동료 검토(Peer Review)

• 2~3명이 진행하는 리뷰 형태
• 작성자가 명세서 내용을 직접 설명하고, 이해 관계자들(동료)이 설명을 들으면서 결함을 발견하는 기법

💡 인스펙션(Inspection)

• 명세서 작성자를 제외한 다른 검토 전문가들이 확인하면서 결함을 발견하는 형태
• 저자가 아닌 훈련된 중재가 주도하는 기법

💡 워크스루(Walkthrough)

• 검토 자료를 회의 전에 배포하여 사전 검토한 후 짧은 시간 동안 저자가 직접 회의를 주도하는 형태
• 리뷰를 통해 오류를 조기에 검출하는데 목적을 둔 검증 기법

2. 형상 관리 및 구성요소

1) 소프트웨어 형상 관리의 정의

• 소프트웨어 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동
• 소프트웨어 프로세스의 모든 출력물 정보, 컴퓨터 프로그램, 컴퓨터 프로그램 설명 문서, 데이터 등

구분	설명
소프트웨어 형상 관리	소프트웨어 엔지닝어링 프로젝트 개시에서 소프트웨어 소멸 시점까지의 활동
소프트웨어 지원	소프트웨어가 고객에게 인도되고 운영되는 시점에서 발생하는 소프트웨어 엔지니어링 활동

2) 기준선과 소프트웨어 형상 관리 항목

⓵ 기준선(Baseline)

• 변경을 통제하게 해준다.
• 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕
• 정식의 변경 통제 절차를 통해서만 변경 가능하다.

⓶ 소프트웨어 형상 관리 항목(SCI)

• Sofeware Configuration Item
• 소프트웨어 형상과 개발 도구의 합성으로 개발 단계별 기준선을 기준으로 형상 항목을 관리한다.

개발 단계	기준선(간결)	소프트웨어 형상 항목(자세)
계획	사용자 요구사항	시스템 명세서, 개발 계획서, 구성 관리 계획서, 품질 평가 계획서, 개발 표준 및 절차 메뉴얼
요구 분석	사용자 요구 기능이 하위 시스템 간에 어떻게 분배되는가 여부	자료 흐름도, 자료 사전, 자료 흐름도 명세서
설계	개발 전 설계 명세	입출력 명세서, 화면 설계서, 초기 사용자 메뉴얼, 초기 시스템 메뉴얼, 자료 구조도, 시스템 구조도
구현	시험 계획서	원시 코드, 목적 코드, 실해 코드, 단위 시험 보고서
시스템 통합 및 시험	제품	통합 시험 보고서, 기능/성능/과부하 시험 보고서, 인증 시험 보고서
설치 및 운영	운영	목적/실행 코드, 운영자 메뉴얼, 사용자 메뉴얼

3) 형상 관리의 주요 활동

주요 기능	설명
형상 식별	형상 관리 대상을 구분하고 관리 목록 번호 부여
버전 관리	진화 그래프 등을 통해 SCI의 버전 부여 및 갱신
변경 통제	SCI에 대한 접근 및 동기화 제어
형상 감사	SCI 무결성을 평가하여 공식적으로 승인
상태 보고	개발자와 유지 보수자에게 변경 사항을 공지

4) 형상 관리 도구

💡 형상 관리 도구

• 소프트웨어 변경 과정, 처리 상태를 기록 및 보고
• 부합하는 해당 사항에 대하여 추적, 통제, 관리
• 품질 향상 및 안정성을 높이는 데에 지원하는 도구

형상 관리 도구	설명
CVS(Concurrent Version System)	‧ 가장 오래된 형상 관리 도구 중 하나
	‧ 서버는 단순한 명령 구조를 가진다는 장점이 있고, 테스트 기반의 코드만 지원한다는 단점도 있다.
SVN(Subversion)	‧ CVS의 단점을 보완해 현재 가장 대중화 된 도구 중 하나
	‧ 다양한 GUI 도구가 존재하고, 압축을 통해 서버의 공간을 절약할 수 있다.
Git	‧ 리눅스 커널 개발을 위해 만든 형상 관리 시스템
	‧ CVS와 SVN의 단점을 모두 보완하는 장점이 있다.
	‧ 중앙 집중형이 아닌 분산형 방식으로 스스로 저장 공간이 필요하다.
	‧ 개념이 다르므로 개발자에게 학습할 시간이 필요하다.

🚀 예상문제

1) 다음 보기에서 설명하는 용어를 작성하시오.

• 전문가가 하는 가장 공식적인 검토 방법
• 체크리스트를 기반으로 검토

• 답 :인스펙션(Inspection)

2) 산출물을 검토하고 결함을 찾아내기 위하여 요구사항 명세서를 미리 배포하여 사전 검토한 후 오류를 조기에 검출하는데 목적을 두는 검토 방법을 무엇이라고 하는지 쓰시오.

• 답 :워크스루(Walkthrough)

3) 소프트웨어 변경 과정 및 처리 상태를 기록/보고하고 소프트웨어의 안전성을 높이는 데에 지원하는 도구를 무엇ㅇ이라고 하는지 쓰시오.

• 답 :형상 관리 도구