mecㆍviewer v1.4 :: lm2001020228_소프트웨어공학+활용.pdf

대분류/20
정보통신

중분류/01
정보기술

소분류/02
정보기술개발

세분류/02
응용SW엔지니어링

능력단위/28

NCS학습모듈

소프트웨어공학 활용

LM2001020228_16v4

[NCS-학습모듈의 위치]

대분류

정보 통신

중분류

정보 기술

소분류

정보 기술 개발

세분류

SW아키텍처

능력단위

학습모듈명

응용SW
엔지니어링

요구사항 확인

임베디드SW
엔지니어링

데이터 입출력 구현

DB엔지니어링

통합 구현

NW엔지니어링

정보시스템 이행

보안엔지니어링

제품소프트웨어 패키징

UI/UX엔지니어링

서버프로그램 구현

시스템SW
엔지니어링

인터페이스 구현

빅데이터
플랫폼구축

애플리케이션 배포

핀테크
엔지니어링

프로그래밍 언어 활용

데이터아키텍트

응용 SW 기초 기술 활용

애플리케이션 리팩토링

인터페이스 설계

애플리케이션 요구사항 분석

기능 모델링

애플리케이션 설계

정적모델 설계

동적모델 설계

화면 설계

화면 구현

애플리케이션 테스트 관리

애플리케이션 테스트 수행

소프트웨어공학 활용

소프트웨어개발 방법론 활용

차 례

학습모듈의 개요

학습 1. CASE 도구 활용하기

1-1. CASE 도구 선정

1-2. CASE 도구 활용

• 교수・학습 방법

• 평가

학습 2. 품질요구사항 확인하기

2-1. 품질 표준과 평가 기준 정의

2-2. 개발 공정과 제품 품질 점검

• 교수・학습 방법

• 평가

참고 자료

활용 서식

소프트웨어공학 활용 학습모듈의 개요

학습모듈의 목표

응용 소프트웨어 개발과 프로세스 적용과 관련된 지식을 익혀 소프트웨어의 완전성을 보장하고,

소프트웨어 품질을 평가하기 위해 CASE 도구와 형상 관리를 통해 소프트웨어공학 기술을 적용

할 수 있다.

선수학습

소프트웨어공학, SW품질관리, 요구사항 확인(2001020201_16v3), 애플리케이션 테스트 관리

(2001020226_16v4), 애플리케이션 테스트 수행(2001020227_16v4)

학습모듈의 내용체계

학습

학습 내용

NCS 능력단위 요소

코드번호

요소 명칭

1. CASE 도구

활용하기

1-1. CASE 도구 선정

2001020228_16v4.1

CASE 도구 활용하기

1-2. CASE 도구 활용

2. 품질요구사항

확인하기

2-1. 품질 표준과 평가 기준 정의

2001020228_16v4.2

품질요구사항

확인하기

2-2. 개발 공정과 제품 품질 점검

핵심 용어

소프트웨어공학, 소프트웨어 개발, CASE 도구, 품질요구사항, 품질 표준, 품질 평가 항목, 개발

공정 품질, 응용 소프트웨어 제품 품질, 결함관리

학습 1 CASE 도구 활용하기

학습 2

품질요구사항 확인하기

1-1. CASE 도구 선정

학습 목표

• 개발하고자 하는 응용 소프트웨어에 적용할 개발 방법론을 지원하는 최적의 CASE

도구를 선정할 수 있다.

필요 지식 /

 CASE 도구(Computer Aided Software Engineering Tool)

1. CASE 도구 개요

CASE 도구(Computer Aided Software Engineering Tool)

CASE는 컴퓨터 지원 시스템공학이라고도 하며 소프트웨어 개발 프로세스의 전 과정에서 자

동화를 지원하는 소프트웨어 도구를 활용함으로써 개발자의 반복적인 작업량을 줄이는 것을

목표로 한다. 여기서 CASE 도구는 소프트웨어 품질과 생산성을 향상시키는 데 도움을 주는

시스템 또는 도구를 의미한다.

CASE 도구를 사용하면 소프트웨어공학의 개발 방법론들을 컴퓨터를 이용하여 구현함으로

써 소프트웨어 개발 계획 수립, 요구사항 분석 및 설계, 개발 및 테스트, 유지 보수까지

소프트웨어 개발의 전 과정을 자동화할 수 있다. 이로써 응용 소프트웨어의 개발과 유지

보수 생산성을 향상시키고 개발된 소프트웨어에 대한 신뢰성을 향상시키고자 하는 목적으

로 CASE 도구를 사용한다.

2. CASE 도구 등장 배경

- 소프트웨어의 생산성을 향상시켜 소프트웨어의 위기를 해결하기 위해 도구를 사용함.

- 소프트웨어공학적인 접근 방법으로 원리를 적용하고 체계적으로 작업하여 개발 및 유지

보수 업무를 자동화함.

- 컴퓨터 분야의 기술 발전으로 인해 크고 복잡한 소프트웨어 개발 요구가 증가함에 따라

체계적으로 개발할 수 있는 자동화된 도구를 도입함.

3. CASE 도구의 목표

(1) 소프트웨어 품질 향상

(2) 소프트웨어 개발 전 과정 자동화

(3) 응용 소프트웨어 개발 및 유지 보수 생산성 향상

(4) 응용 소프트웨어 점진적 개발 지원

(5) 응용 소프트웨어 재활용성 제고

(6) 표준화된 문서 생성과 개발 팀 간의 정보 공유 및 협업 지원

 CASE 도구 종류

1. 계층적 분류

깁슨(Michel L.Gibson) 교수는 다음과 같이 CASE를 상위(upper) CASE와 하위(lower) CASE,

통합(integrated) CASE로 분류한다.

구분

설명

주요 기능

상위 CASE

요구 분석과 설계 단계를 지원하는

도구. 요구 분석 후에 명세서를 작성

하고 설계하는 과정을 지원하는 도구

여러 가지 방법론을 지원하

는 다이어그램 작성 기능

모델의 정확성, 일관성을

확인하기 위한 오류 검증

기능

프로토타이핑 지원 기능

설계 자료 사전 기능

하위 CASE

코드를 작성하고 테스트하며 문서화

하는 과정에 도움을 주는 도구

프로그래밍 지원 기능(코드

생성 및 편집, 컴파일러 등)

코드 자동 생성 기능

테스트 도구(정적 및 동적

분석, 회귀 테스트 등)

통합 CASE

소프트웨어 개발 주기 전체 과정을

지원하기 위하여 공통의 정보 저장소

와 통일된 사용자 인터페이스로 도구

들을 통합한 것

그래픽 기능

프로토타이핑과 명세화 기능

설계 기능

프로그래밍 및 테스트 기능

공동 정보 저장소 기능

<표 1-1> CASE 도구 계층적 분류

2. 기능적 분류

CASE 도구들을 제공 기능 중심으로 분류하면 <표 1-2>와 같이 분류할 수 있다.

구분

설명

프로세스

모델링 및 관리

도구

프로세스가 더욱 잘 이해될 수 있도록 프로세스의 핵심 요소들을 표현하는 데

사용하는 도구. 업무 프로세스와 업무 활동, 해당 활동을 수행하는 주체를 정의

하고 프로세스 기술들(descriptions)로 연결하는 기능을 제공함.

프로젝트 계획

수립 도구

프로젝트 업무(Work)와 기간 및 비용을 추산하거나 프로젝트 수행 계획 수립을

지원하는 도구. 프로젝트 업무 분해도(work breakdown structure)를 작성하거나

업무 태스크 네트워크를 만들고 상호 의존성을 표현하고 병렬 가능 태스크를

식별할 수 있음.

위험 분석 도구

프로젝트 수행 시 발생할 수 있는 위험을 식별하고 완화, 감시 및 관리할 수 있

도록 위험을 식별하고 분석할 수 있도록 지원하는 도구

요구사항 관리

도구

사용자 요구사항에 대한 명세를 저장하고 분류 및 추적 관리를 지원하는 도구

품질보증 도구

프로젝트 표준 준수 여부 점검 및 소스 코드 감시 기능 제공

데이터베이스

관리 도구

데이터베이스를 생성하고 활용할 수 있도록 데이터 관리 기능과 사용자, 접근

관리 기능 제공

소프트웨어

형상관리 도구

형상 항목을 식별하고 버전 통제하고 변경 통제 및 감사, 상태 보고 기능 제공

분석 및 설계

도구

데이터와 기능 및 행위, 아키텍처, 인터페이스 등 구축될 시스템의 모델을 생성

하고 관리하는 기능 제공

프로토타이핑 &

시뮬레이션

도구

시스템을 구축하기 전에 시스템 사용자/고객들이 시스템의 기능과 운영 모습들

을 예측할 수 있도록 시뮬레이션하는 기능 제공

화면 설계 및

개발 도구

메뉴와 버튼, 화면 구조, 아이콘 등 소프트웨어 컴포넌트를 기반으로 화면 설계

와 제작을 지원하는 도구

프로그래밍

도구

프로그램 언어들을 지원하는 컴파일러, 편집기 및 디버거, 데이터베이스 연계

등의 기능을 지원

통합 및 테스트

도구

테스트 데이터 확보, 정적 및 동적 분석, 모의 시험, 테스트 관리 기능 등을 제

공하는 도구

리엔지니어링

도구

소스 코드를 입력으로 받아 도형적인 구조화를 통해 분석 및 설계 과정을 지원

하는 도구

<표 1-2> CASE 도구의 기능적 분류

3. 소프트웨어 개발 수명 주기에 따른 분류

소프트웨어 개발 수명 주기에 따라 활용되는 CASE 도구들을 분류하면 다음과 같다.

[그림 1-1] 소프트웨어 개발 수명 주기에 따른 CASE 도구 분류

 CASE 도구 도입의 성패 요인

1. 도입의 성공 요인

- CASE 도구에 대한 정확한 이해를 바탕으로 도입한다.

- CASE 도구 활용을 위해 필요한 교육과 컨설팅을 충분히 고려한다.

- CASE 도구를 조직의 활용 목적에 맞게 수정 개발(Customizing)이 필요한지 인식한다.

- 소프트웨어 개발 프로젝트와 사용자 능력 수준, 개발 환경에 맞는 도구를 선정한다.

2. 도입의 실패 요인

- CASE 도구가 모든 것을 자동화하는 환상적 도구라는 잘못된 기대를 한다.

- CASE 도구를 사용할 사용자들의 능력 수준을 무시하고 도입한다.

- 일관성 없는 개발 방법론 및 CASE 도구를 사용한 경험을 바탕으로 지나친 기대를 한다.

- 많은 기능을 제공하는 CASE 도구를 선호한다.

- 공급자의 기술 지원 능력과 사후 지원 제도가 미비한 CASE 도구를 도입한다.

3. 도입 시 고려 사항

(1) CASE 도구 도입 목적 명확화

CASE 도구를 도입하여 해결해야 하는 업무를 파악하고 도입 목적을 명확하게 정의한

다. 도입 목적을 명확하게 정의하지 못할 경우, 도입 전·후의 효과에 대한 측정을 수

행하기 어렵다.

(2) 소프트웨어 개발 방법론에 적합한 CASE 도구 선택

소프트웨어 개발 시 적용할 개발 방법론을 지원할 수 있는 CASE 도구를 선정한다.

(3) 조직 및 프로젝트 구성원 고려

CASE 도구를 사용할 조직 또는 프로젝트 구성원의 CASE 도구 활용 수준을 고려하여

선정한다. CASE 도구 도입 후 활용하기 위해 필요한 교육 시간과 소프트웨어 유지 보

수 인력의 재배치에 따른 추가 교육 등을 고려한다.

수행 내용 / CASE 도구 선정하기

재료·자료

• 정보통신단체표준(1999). TTA.IS-14471

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

• CASE 도구(SW설계 지원 도구, SW 개발 지원 도구, SW 테스트 지원 도구 등)

안전 ･ 유의 사항

• 조직 내에 CASE 도구 도입 목표와 도입 정책이 이미 정의되어 있다면 그것을 활용한다.

• 도입할 CASE 도구의 수가 적거나 후보가 정의되어 있다면 평가 과정을 바로 수행한다.

• 검토 대상 CASE 도구들의 현재 상태와 멀지 않은 장래에 발생할 수 있는 변화 사항(업그

레이드 일정 등)을 반드시 확인해야 한다.

수행 순서

 응용 SW 개발 및 유지 보수 업무를 위해 필요한 CASE 도구 도입 목표를 정하고, CASE

도구 선정 및 도입을 위한 정책과 계획을 수립한다.

1. CASE 도구 도입 목표를 설정한다.

응용 SW 개발 및 유지 보수 업무에 대한 목표를 달성하는 데 도움을 줄 수 있는 최적의

CASE 도구를 선정하기 위해 CASE 도구 선정 목표를 정의한다.

(1) 응용 SW 개발 프로젝트의 전체 목표와 개발 단계별 세부 목표, 유지 보수 업무 목

표 등을 정의한 문서들을 검토하여 정리한다.

[그림 1-2] 응용 SW 개발 및 유지 보수 프로젝트 목표 사례

(2) 응용 SW 개발자 및 유지 보수 담당자, 프로젝트 관리자 또는 업무 책임자들을 대

상으로 인터뷰 또는 설문조사를 통해 CASE 도구 도입 요구사항과 CASE 도구 도입

시 기대 목표를 수집한다.

CASE 도구 도입 요구사항 인터뷰 질문지

인터뷰 대상자 :

직책 :

근무 부서 :

귀하의 업무 수행 중에 부딪히는 문제가 있다면 무엇입니까?

그러한 문제를 향후에도 겪게 되리라고 생각하십니까?

그 문제를 효과적으로 취급하는 데 필요한 CASE 도구가 있습니까?

해당 CASE 도구를 도입할 경우 업무 생산성이 얼마나 향상될 것으로 기대합니까?

담당하는 업무가 SW 품질과 관련 있습니까?

SW 품질 확보를 위해 도입하고자 하는 CASE 도구가 있습니까?

<표 1-3> CASE 도구 도입을 위한 요구사항 조사 인터뷰 문항 예시

CASE 도구 도입 요구사항 조사 설문지

안녕하십니까?

본 설문조사는 CASE 도구에 대한 사용 현황을 파악하고 향후 IT업무 생산성 제고 및

품질 개선을 위한 방안을 모색하기 위한 조사입니다.

모든 응답 내용과 관련된 개인적 사항은 철저히 비밀이 지켜지며 오직 CASE 도구 사용

현황 파악과 개선 요구사항 수집을 위한 통계적 목적으로만 사용될 것입니다.

바쁘시더라도 이 설문조사가 회사와 우리들 모두를 위한 것임을 생각하시어 정성껏

솔직한 의견을 표명해 주시면 감사하겠습니다.

OOOO년 OO월 OO일

IT기획팀 팀장

응답자 :

직책 :

근무 부서 :

다음 질문의 각 항목들을 읽고 귀하께서 생각하시는 가장 적절한

번호에 O표해 주시기 바랍니다.

①
매

우
그
렇

지
않
다

②
그

렇
지
않

다

③
보

통
이
다

④
그

렇
다

⑤
매

우
그
렇

다

귀하의 업무에 CASE 도구를 사용하고 있습니까?

①예 ②아니오

사용하고 있는 CASE 도구가 있다면 기술해 주십시오.

CASE 도구를 도입할 경우 업무 생산성이 향상될 것으로 기대합니까?

① ② ③ ④ ⑤

CASE 도구를 도입할 경우 SW 제품 품질이 향상될 것으로 기대합니까?

① ② ③ ④ ⑤

도입할 경우 담당하는 업무 생산성이 향상될 것으로 보이는 CASE 도구가
있으면 기술해 주십시오.

SW 품질 확보를 위해 도입하고자 하는 CASE 도구가 있으면 기술해 주십

시오.

<표 1-4> CASE 도구 도입을 위한 요구사항 조사 설문지 문항 예시

(3) 응용 SW 개발 및 유지 보수 업무 목표 달성을 위해 필요한 CASE 도구 유형과 기

대 목표를 정리한다.

[그림 1-3] 업무 목표 달성을 위해 필요한 CASE 도구 유형과 기대 효과 사례

2. CASE 도구 선정 및 도입 정책을 정의한다.

CASE 도구 목표를 달성하기 위해 CASE 도구 선정 및 도입 시 활용할 수 있는 지침과 프

로세스를 정의하고 인력과 자금 등 필요 자원을 정의한다.

(1) 조직에서 사용하고 있는 SW 구매 정책 또는 구매 관련 규정과 지침 등 관련 문서

를 검토하고, CASE 도구 선정 및 도입에 대한 지침과 프로세스를 정의한다.

[그림 1-4] 구매 관련 규정 예시

구매 업무 절차

① 수요 부서에서 품명, 규격, 수량, 용도를 명기하여 구매 팀에 요청하며 구매에 필요

한 시방서, 카탈로그, 도면, 견본, 견적서 등의 참고 자료를 첨부하여야 한다.

② 물품 구매의 경우 자산 팀의 협조 결재를 득하여 청구하여야 한다.

③ 정보화 기자재의 구매는 정보인프라 팀, 영상 음향 장비의 구매는 자산 팀의 협조를

득하여 청구하여야 한다.

④ 공사 계약은 시설 팀을 경유하여 청구하여야 한다.

⑤ 청구 총액이 100만원 이상인 경우 예산 부서의 협조 결재를 득하여 구매 청구하여야

한다.

<표 1-5> 구매 업무 절차 예시

[그림 1-5] 소프트웨어 도입 기준 예시
출처: 국가법령정보센터 행정기관 및 공공기관 정보시스템 구축・운영 지침(www.law.go.kr). 2017. 8. 3

스크린샷.

구분

설명

요구사항 정의

CASE 도구 도입을 위한 조직의 업무 목표 정의

CASE 도구 도입 요구사항 식별 및 정의

CASE 도구 조사

도입 가능한 CASE 도구 조사

제약사항 식별 및 검토

내부 개발 가능성 검토

CASE 도구 평가

도구 평가 기준 준비

기능 및 관련 기술 평가 및 검토

도구 및 공급사 평가 실시

파일럿 시범 적용

파일럿 프로젝트 선정

도구 시범 적용

도구 도입 요구사항 만족 여부 평가

시범 적용을 통한 문제점 도출 및 해결 방안 검토

CASE 도구 선택

도구 선택 기준 정의

도구 선택 기준에 의한 평가 및 선택

CASE 도구 구입

및 배포

도구 도입 및 배포 계획 수립

구매 절차에 따른 도구 구입

도구 배포를 위한 전담 조직 할당 및 관련 인프라 구축

도구 교육/훈련 계획 수립 및 실시

도구 설치 및 환경 구축

도구 사용 현황 모니터링 및 성공 사례 공유

<표 1-6> CASE 도구 도입 프로세스 예시

(2) 조직의 예산 담당자의 확인 또는 예산 계획서 참조를 거쳐 CASE 도구 선정 및 도

입에 사용할 수 있는 예산 규모를 파악한다.

(3) CASE 도구 선정 과정에 참여할 인력과 지원 및 자문 인력을 선정한 후 의사 결정

자의 승인을 받는다. 필요 시 유관 부서에 협조 요청을 보낸다.

부서

직책

성명

사번

근무 경력

담당 역할

기획

사원

박OO

20170612

선정 담당자

기획

대리

김OO

20160612

선정 담당자

개발

차장

이OO

20150612

지원 담당

개발

과장

박OO

20140612

자문 담당

운영

부장

나OO

20130612

자문 담당

<표 1-7> CASE 도구 선정 담당자 및 자문 인력 명단 예시

(4) CASE 도구 선정 및 도입 정책에 대한 보고서를 작성하고 의사 결정자의 승인을 받는다.

[그림 1-6] CASE 도구 선정 및 도입 정책에 대한 보고서 작성 예시

3. CASE 도구 선정 및 도입 계획을 수립한다.

CASE 도구를 도입하기 위해 필요한 도입 목표와 도입 대상, CASE 도구 선정 기간, 분석

및 선정 방법과 담당 조직 및 인력, 필요 예산 등을 기술한 계획서를 작성한다.

(1) 도입 대상과 CASE 도구 조사 및 분석 기간, 시범 테스트 기간 등을 고려하여 CASE

도구 선정에 필요한 기간을 산정한다.

(2) CASE 도구 선정 및 도입 계획서를 작성한다.

CASE 도구 도입 목표와 CASE 도구 선정 및 도입 정책, 소요 기간 및 조직 정보를 기

반으로 CASE 도구 선정 및 도입 계획서를 작성한다.

[그림 1-7] CASE 도구 선정 및 도입 계획서 목차 예시

(3) CASE 도구 선정 및 도입 계획서를 의사 결정자에게 보고하고 승인을 받은 후 유관

부서 또는 관련자들에게 배포한다.

 응용 SW 개발 및 유지 보수 업무에 사용 가능한 CASE 도구들을 조사하여 용도와 기능에

따라 분류한 후 CASE 도구 조사서를 작성한다.

1. 응용 SW 개발 및 유지 보수 업무에 사용되는 모든 CASE 도구를 조사하여 목록화한다.

개발 사례 조사 또는 상용 제품 홍보 자료 등 다양한 자료 조사를 통해 응용 SW 개발 및

유지 보수에 활용하는 CASE 도구들을 수집하여 CASE 도구 목록을 작성한다.

[그림 1-8] 응용 SW 개발 단계별 CASE 도구 종류 예시

[그림 1-9] 응용 SW 개발 및 테스트 통합 환경에 대한 CASE 도구 종류 예시

2. 동종 업무 또는 유사 프로젝트에서 활용했던 CASE 도구, 이미 활용하고 있는 CASE 도

구 들을 조사하여 목록화한다.

활용 사례가 많거나 동종 업무에서 활용하고 있는 CASE 도구, 또는 사용 중인 CASE 도

구 들을 대상으로 상세 조사를 수행할 수 있도록 조사 대상 CASE 도구 목록을 정리한다.

3. 조사 대상 CASE 도구 목록에 있는 CASE 도구들의 용도와 제공 기능, 도입 비용 등을

조사하여 정리한다.

보유하고 있는 CASE 도구나 오픈소스 CASE 도구의 경우 직접 설치해서 기능을 조사하고,

그렇지 않은 경우 제품 설명 자료나 관련 교재 등을 이용해서 조사한다.

분류

도구 명

라이선스

언어

유사 기관

활용 사례

기존 사용

경험

요구사항관리

JFeature

CPL

요구사항관리

JFequisite

EPL

구현

Eclipse CDT

EPL

C/C++

<표 1-8> 조사 대상 CASE 도구 목록 예시

4. CASE 도구 조사 내용을 용도와 기능, 개발 방법론과 활용 시기, 활용 시 특이 사항 등

에 따라 분류하고 CASE 도구 목록을 정리한다.

CASE 도구 활용을 위해 필요한 정보(용도, 기능, 도입 비용, 특이 사항 등)를 기준으로

CASE 도구들을 분류하고 일목요연하게 정리한다.

도구 명

용도

라이선스

비용

대상 언어

개발 방법/제한 사항

AAA

요구사항 관리

CPL

BBB

요구사항 관리

EPL

CCC

설계/모델링

BSD

객체지향 설계

DDD

설계/모델링

GPL

DDF

DB 관리

CPL

객체지향 DB

DDE

DB 관리

CPL

관계형 DB

EEE

구현

GPL3

C/ C++

FFF

구현

EPL

Java

GGG

테스팅

CPL

C/C++

HHH

테스팅

CPL

Java

I I

테스팅

EUPL

C/C++,

Jave

KKK

빌드

EPL

LLL

빌드

APL2

Java

MMM

형상 관리

GPL

NNN

형상 관리

GPL2

<표 1-10> CASE 도구 기능적 분류

CASE 도구 명

작업 관리 도구A

CASE 도구 용도

작업 관리

라이선스

GPL

도입 비용

CASE 도구

실행 화면

(주요 기능)

주요 기능

작업 등록, 변경, 추적, 통보 등

문서 관리, 파일 관리, 이메일 연계 등

장점

간략한 일정 관리 가능

웹 서버를 기반으로 다수의 작업자들이 협업할 수 있음.

프로젝트 단위, 사용자 단위 권한 관리 가능

작업 진행 상태를 이메일로 통보할 수 있음.

단점

자원 투입률을 관리할 수 없음.

휴일 등록 기능 없음.

작업 단위로 작업 시간을 설정할 수 없음.

선후행 작업에 대한 조건 설정 기능이 없음.

<표 1-9> CASE 도구 조사서 예시

 CASE 도구 목록과 CASE 도구 조사서를 기반으로 정성 및 정량 평가를 실시하고 도입할

CASE 도구를 선정한다.

CASE 도구 선정 기준을 정의하고 기준에 따라 평가를 수행한 후, 평가 점수가 높은 순으

로 시험 프로젝트를 수행하고 최종적으로 도입할 CASE 도구를 선정한다.

1. CASE 도구 도입 목표와 도입 정책과 지침 등을 참고하여 CASE 도구 평가 기준을 정의한다.

CASE 도구 도입을 통한 목표 달성 가능성과 기술 측면, 가격, 활용 사례, 판매자 지원 사

항, 유지 보수 편의성, 도입 편의성 등의 평가 항목을 선정하고 항목별로 평가 방법을 정

의한다.

CASE 도구 도입을 위한 평가서

평가자 :

직책 :

근무 부서 :

다음 질문의 각 평가 항목별로 가장 적절한 번호를 기록해 주시기

바랍니다.

①
매
우

그
렇
지

않
다

②
그
렇

지
않
다

③
보
통

이
다

④
그
렇

다

⑤
매
우

그
렇
다

CASE 도구 도입 목표 달성

CASE 도구 제공 기능의 우수성

CASE 도구 성능 우수성

당사 업무 적합성(개발 방법론 적합성)

기존 환경과의 융합

판매자 지원

총점

<표 1-11> CASE 도구 평가서 예시

2. CASE 도구 목록에 있는 CASE 도구들을 평가하고 평가 점수가 높은 순으로 3개의 도구

를 후보로 선정한다.

도구 명

용도

라이선스

비용

대상 언어

개발 방법/제한 사항

OOO

품질 관리

EPL

Java

PPP

품질 관리

GPL

QQQ

이슈 관리

BSD

SSS

백로그 관리

GPL

Agile 개발 지원

RRR

프로젝트 관리

GPL3

TTT

스프린트 관리

GPL

Agile 개발 지원

CASE 도구 후보

라이선스

GPN GPL 2.0

GNU GPL 3.0

CPAR 1.0

Windows/Linux/Mac

실행 환경

DBMS, Apache Web

Web, Standalone

JRE 1.5, Standalone

주요 기능

프로젝트 관리, 이슈

관리, 문서 관리, 협업

기능

프로젝트 관리

장점

작업 일정, 작업 상태

관리, 작업자 할당

기능 편리

진척률 관리, 작업

시간 관리 기능 편리

인력 자원 관리, 비용

관리 기능 편리

<표 1-12> CASE 도구 후보 예시

3. CASE 도구를 사용할 사용자와 의사 결정자들을 대상으로 CASE 도구 평가 결과와 후보 목

록을 공개하고 토론을 통해 평가 결과를 재검토하고 최종적으로 CASE 도구를 선정한다.

(1) 논의를 통해 후보로 선정된 CASE 도구에 대한 적합성 테스트 실시 여부를 결정한다.

사용 경험이 없는 CASE 도구나 업그레이드된 CASE 도구의 경우 기능과 성능, 시스템

전환에 따른 문제 발생 여부를 검토하기 위해 소규모 프로젝트 또는 파일럿 프로젝트

에 도입해서 테스트를 실시한다.

(2) 적합성 테스트를 실시할 경우, 평가 점수가 높은 순서로 제품 판매처와 협의하여

테스트 계획을 수립하고 시험 테스트를 수행한다.

(가) 제품 판매처와 협의해서 CASE 도구 제공 가능 시기, 설치 및 사용 교육 일정,

지원 담당자 정보 등을 확인한다.

(나) 적합성 테스트를 수행하기 위한 파일럿 프로젝트를 선정한다.

파일럿 프로젝트는 앞으로 진행할 예정이거나 현재 진행하고 있는 프로젝트에서

주요 업무 및 핵심 기능들을 선별하여 구성한다.

(다) 적합성 테스트를 수행할 조직을 구성한다.

응용 SW 개발 또는 유지 보수 실무자와 책임자, 기술 전문가와 네트워크 전문가

등 인프라 담당자, 프로젝트 관리자 등 관련된 이해관계자들을 골고루 참여시킨다.

(라) 적합성 테스트를 수행하고, 평가 기준에 따라 평가 결과와 테스트 과정에서 식

별된 문제점들을 포함하여 적합성 테스트 결과 보고서를 작성한다.

도구 성능과 기능 편의성, 방법론 적합성, 전환 유연성, 안전성 등에 대한 평가 결

과와 문제점을 포함하여 결과 보고서를 작성한다.

(마) CASE 도구 사용자와 주요 의사 결정자들에게 적합성 테스트 결과 보고서를 배

포하고, 적합성 테스트 참여자와 CASE 도구 사용자 대표, 주요 의사 결정자들

이 토론을 통해 해당 CASE 도구 도입 여부를 최종 결정한다.

(바) 적합성 테스트 결과 해당 CASE 도구를 도입하지 않기로 결정한 경우, 차상위

후보를 대상으로 적합성 테스트 계획을 수립하고 CASE 도구 최종 선정 과정을

재 수행한다.

(3) 적합성 테스트를 실시하지 않을 경우, 평가 결과 검토 회의를 통해 CASE 후보 목록

에 대한 평가 결과를 검토하고 평가 점수가 높은 도구를 최종적으로 선정한다.

수행 tip

• CASE 도구 선정 업무의 규모와 자원 현황에 따라

“  응용 SW 개발 및 유지 보수 업무를 위해 필

요한 CASE 도구 도입 목표를 정하고 CASE 도구 선

정 및 도입을 위한 정책과 계획을 수립한다.”과정

은 생략하거나 일부 내용을 간략하게 작성한다.

1-2. CASE 도구 활용

학습 목표

• CASE 도구가 제공하는 다양한 기능들 중 응용 소프트웨어 개발 시 활용할 기능을

식별할 수 있다.

• CASE 도구 활용을 위한 절차와 표준을 정의하고 CASE 도구 사용 중 발생하는 이슈

를 해결할 수 있다.

필요 지식 /

 업무 매뉴얼

업무 매뉴얼은 지침, 가이드, 핸드북의 명칭으로도 쓰인다.

업무 매뉴얼(Manual)

업무 수행 시 동일 목표를 달성하기 위해 표준화된 업무 처리 방법이나 순서에 따라 업무를 수

행할 수 있도록 표준화한 업무 수행 지침서를 말하며, 소책자, 편람, 안내서, 사용 설명서를 의

미하기도 한다.

1. 업무 매뉴얼 작성 목표

업무 매뉴얼 작성 목표는 업무 처리 방식/절차의 표준화를 통해 사무 생산성 향상을 도모

하는 것이다.

[그림 1-10] 업무 매뉴얼 작성 목표

(1) 업무 가시화를 통한 현행 업무 처리 방법의 문제점 제거

(2) 업무 처리 방식에 대한 지속적인 개선으로 업무 생산성 극대화

(3) 필요 인력 산정을 위한 기초 자료 확보

(4) 신입 및 전입 직원에 대한 OJT 기초 자료 제공

(5) 사무 자동화를 위한 기초 자료 확보

2. 업무 매뉴얼 구성 요소

업무 매뉴얼에는 일반적으로 다음 사항이 포함된다.

구성 요소

세부 내용

서론

업무 매뉴얼의 필요성, 목적과 구성 내용

업무 개요

업무 매뉴얼에서 다루고 있는 업무의 개요

단계별/기능별 점검 사항

업무의 성격에 따라 단계와 시기 또는 기능별 처리 방법이나

점검 사항을 제시

서식 / 템플릿

업무에 필요한 서식이나 템플릿의 예

성공 및 실패 요인

업무 운영 시 참고할 수 있는 주요 성공 요인, 장애 요인과 해

결 방법을 실제 사례와 함께 제시

참고 자료

업무에 유용하게 활용할 수 있는 각종 참고 자료

Q&A

예상되는 질문과 답변

<표 1-13> 업무 매뉴얼 구성 요소

 이슈 관리

- 이슈와 위험의 상관관계

이슈(Issue, Problem)와 위험(Risk)

이슈(Issue, 혹은 Problem)는 프로젝트 목표 달성에 영향을 가져올 수 있는 “발생된(Realized)”

위험으로 정의되며, 위험은 아직 발생되지 않았으나 발생할 가능성(Probability)이 있는 것, 발생

할 경우 프로젝트 수행에 중요한 영향(Impact)을 가져올 수 있는 것, 적절하게 대처할 경우 기회

(Opportunity)가 될 수도 있는 위험을 말한다.

- 이슈는 하고 싶은 것이 될 수도 있고, 고객이 요청하는 것일 수도 있고, 제거해야 할 것

이거나, 잘못된 부분에 대한 인식 등 다양한 형태로 존재하며 이미 발생한 문제점이기

때문에 반드시 해결해야 한다.

1. 이슈 관리 방법

식별된 이슈를 목록화하여 관리하고, 처리할 우선순위와 이슈 처리 담당자를 지정하고, 이

슈 해결 상황을 모니터링하는 일련의 행위를 이슈 관리라고 한다.

2. 이슈 관리 시스템 (Issue Tracking System)

프로젝트 수행 과정에서 사용하는 이슈 관리 시스템은 이슈를 적절하게 관리할 수 있도록

만들어진 시스템을 말한다. 주로 제공하는 기능은 테스트 시 발생된 버그나 사용자 요구

사항 및 이슈 처리 작업 내용 등이 있을 때 해당 시스템에 등록하고, 개발자와 테스터나

관련 담당자들이 작업 진행 상황을 기록하는 기능이다. 인터넷 상의 게시판과 비슷하게

해당 이슈에 대한 이슈 제목, 이슈 유형, 담당자, 우선순위 등의 속성을 지정하고 내용을

등록할 수 있다.

진행 과정에서 식별한 이슈 처리 결과를 시스템에 등록하고 이슈 해결 작업이 끝나면 이

슈를 종료한다. 이미 해결한 이슈에 대해서 다시 문제가 생기면 관리할 수 있는 기능을

제공한다.

수행 내용 / CASE 도구 활용하기

재료·자료

• 정보통신단체표준(1999). TTA.IS-14471

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

• CASE 도구(SW설계 지원 도구, SW 개발 지원 도구, SW 테스트 지원 도구 등)

안전 ･ 유의 사항

• 판매처에서 제공한 CASE 도구 사용 가이드라 해도 직접 사용해 보고 조직에 맞게 작성한다.

• CASE 도구 유지 보수를 위한 업무 매뉴얼은 작성 후 운영 담당자 검토를 통해 최적화한다.

• 기존에 사용하던 CASE 도구와 새로 채택한 CASE 도구의 사용법이 많이 달라 교체할 때

학습 시간이 오래 걸릴 것으로 예상되는 경우에는 사용자 대상 교육을 강화한다.

수행 순서

 채택된 CASE 도구가 제공하는 기능과 사용자를 식별하고, 업무 매뉴얼을 작성한다.

해당 CASE 도구가 제공하는 기능과 활용 업무를 기반으로 활용 조직/사용자, 유지 보수

조직/담당자를 정의하고 업무 매뉴얼을 작성한다.

1. CASE 도구가 제공하는 기능을 검토하고 활용할 기능을 식별하여 목록화한다.

CASE 도구 선정 과정에서 작성한 CASE 도구 조사서의 내용을 참고하되 CASE 도구를 직

접 사용하면서 응용 SW 개발 및 유지 보수 과정에서 사용할 기능만을 선별한다.

주요 기능

세부 기능

주요 기능

세부기 능

데이터 표준화

관리

용어

모델 관리

모델표준준수체크

단어

모델정보조회

도메인

뷰조회

유사어

모델표준화준수율

미사용목록조회

모델표준불일치

신청결과현황

모델용어조회

통합 코드 관리

통합코드관리

데이터베이스

관리

테이블조회

통합코드컬럼매핑

DBMS표준준수체크

코드도메인조회

DBMS컬럼

인스턴스조회

DBMS이력

데이터 정합성

관리

검증기준

변경 영향

관리

변경영향분석

업무로직검증기준

연관테이블조회

RI검증기준

검증결과

검증세부결과

검증통계

검증세부통계

<표 1-14> 메타데이터 관리 도구 기능 목록 예시

2. CASE 도구의 활용 기능별로 표준 사용 가이드를 작성한다.

CASE 도구 사용자들이 쉽게 이해할 수 있으면서, 업무 표준을 준수할 수 있도록 기능별로

입력물과 출력물, 산출물 이름 작성 표준(Naming Standard)과 사용 과정 등을 포함한다.

(1) CASE 도구 판매처에서 제공하는 기본 매뉴얼이나 설명 자료 등을 수집하여 검토한다.

(2) 응용 SW 개발 또는 유지 보수 과정에서 수행하는 실제 사례를 기반으로 해당 기능

을 직접 사용하면서 화면을 캡처한다.

(3) 입력 자료와 출력 자료, 처리 화면과 유의 사항을 포함하여 해당 기능에 대한 활용

가이드를 작성한다.

[그림 1-11] 메타데이터 관리 시스템 초기 화면 예시

① 대분류메뉴

메타로 관리하게 될 최상위 레벨의 업무 구분

② 소분류메뉴

대분류메뉴에 속하는 하위 업무

③ 검색조건영역

검색을 원하는 조건(예: 용어명, 용어영문명, 신청자 등)을 입력 및 선택 후 검색버튼을

클릭하여 검색을 수행한다.

④ 조회결과영역

검색 조건에 따라 검색을 수행하여 결과 값을 조회한다.

⑤ 상세결과영역

조회 결과 영역에 나온 결과 값에 대한 상세 및 연관된 다른 정보를 조회한다.

⑥ 처리버튼

신규, 수정, 삭제, 엑셀 등 조회 이외의 처리가 필요한 경우 처리버튼을 통해 처리한다.

[그림 1-12] 메타데이터 관리 시스템 초기 화면에 대한 설명 예시

[그림 1-13] 메타데이터 관리 시스템의 용어 신규 화면 예시

1단계 : 용어를 생성하기 위하여 단어를 조회한다. 조회는 형태소 단위의 ‘기금’, ‘지

급’, ‘금액’ 순으로 한다. 1단계에서는 ‘기금’을 조회한다.

ü 검색항목명에서 ‘기금’을 조회하면 조회영역에 ‘기금’에 대한 등록 단어 개수와 도

메인 개수가 조회된다.

ü 조회 결과를 선택하면 단어 탭에 ‘기금’이 포함된 단어가 조회된다. 만약 ‘기금’이

포함된 도메인이 존재한다면 도메인 탭에 도메인 정보가 조회된다.

ü 단어 탭에서 기금을 선택하면 선택된 단어와 조합된 표준용어 탭에 조회된다. 이때 만약

단어 탭에 ‘기금지급’이라는 합성어 형태의 단어가 조회된다면 합성어 우선 정책에 따

라 ‘기금지급’을 선택해야 한다.

2단계 : ‘지급’을 조회한다.

ü 용어신규 탭에서 ‘지급’을 조회하면 조회 영역에 ‘지급’에 대한 등록 단어 개수와

도메인 개수가 조회된다.

ü 조회 결과를 선택하면 단어 탭에 ‘지급’이 포함된 단어가 조회된다. 만약 ‘지급’이

포함된 도메인이 존재한다면 도메인 탭에 도메인 정보가 조회된다.

ü 단어 탭에서 ‘지급’을 선택하면 선택된 단어와 조합된 표준용어 탭에 조회된다. 이때

선택된 단어 탭에는 ‘기금’과 ‘지급’이 조회되며, 동시에 조합된 표준용어 탭에는 용

어 ‘기금지급’과 영문명 ‘INCA_DFR’이 조회된다.

3단계 : ‘금액’을 조회한다.

이하 생략

[그림 1-14] 메타데이터 관리 시스템의 용어 신규 화면 설명 예시

(4) CASE 도구 활용 가이드를 대표 사용자 그룹과 유관 부서에 배포한 후 검토 의견을

받아 수정한다.

3. CASE 도구 설치 및 운영을 위한 업무 매뉴얼을 작성한다.

CASE 도구 유지 보수 담당자들이 참고할 수 있는 설치 및 모니터링, 운영을 위한 환경

설정 방법, 자주 발생하는 문제 상황 등을 포함하여 운영 담당자를 위한 업무 매뉴얼을

작성한다.

(1) CASE 도구 판매처에서 제공하는 운영 매뉴얼이나 설명 자료, 조직 내에서 사용하고

있는 유사한 CASE 도구의 업무 매뉴얼 등을 수집하여 정리한다.

(2) 유지 보수 업무 프로세스를 파악하고 업무 활동을 상세히 정리한다.

(3) 업무 활동에서 CASE 도구의 관리자 기능을 사용할 경우, 해당 CASE 도구를 직접

사용하면서 화면을 캡처한다.

(4) 관리자 기능에 대해 입력 자료와 출력 자료, 처리 화면과 유의 사항을 포함하여 해

당 기능에 대한 활용 가이드를 작성한다.

(5) CASE 도구 판매처에서 자주 발생하는 문제 상황과 대처 방안에 대한 자료를 받거

나 설명을 듣고 문서화한다.

(6) 유지 보수 업무 프로세스와 업무 활동, CASE 도구의 관리자 기능 활용 가이드와 자

주 발생하는 문제 상황에 대처 방안을 종합하여 업무 매뉴얼을 작성한다.

(7) 운영 업무 매뉴얼을 유지 보수 담당자들과 유관 부서에 배포한 후 검토 의견을 받

아 수정한다.

 CASE 도구에 대해 사용자 교육과 유지 보수 담당자 교육을 실시한다.

해당 CASE 도구를 사용할 사용자 명단과 유지 보수자 명단을 확보한 후 교육 계획을 수

립하고, 교육 일정에 따라 교육을 실시한다.

1. 사용자 또는 유지 보수 교육 대상을 식별하고 목록화한다.

교육 대상자의 규모가 클 경우 여러 차례로 나누어 집체 교육을 실시하거나 온라인 교육

으로 대체해야 하므로 사용자와 유지 보수 그룹을 명확하게 식별해야 한다.

교육 명

세부 내용

교육 기간

교육 방법

교육 대상

프레임워크

•프레임워크의 이해

•프레임워크를 활용한 개발 방법

2일

온사이트

교육

개발자

미들웨어

•미들웨어에 대한 이해 및 사용법

1일

온사이트

교육

개발자

<표 1-15> 교육 대상과 교육 내용 목록 예시

2. 교육생 규모를 기반으로 교육 방법과 횟수, 교육 시간과 강사, 교육 장소 등을 포함하

여 교육 계획을 수립한다.

CASE 도구 사용자 교육은 조직 내부에서 강사를 섭외할 수 있으나, 유지 보수 교육은 판

매 업체와 협의해서 교육 계획을 수립한다.

(1) 교육생 규모와 교육 효과를 고려하여 온라인 교육 또는 오프라인 교육을 선택한다.

(2) 교육 방법과 수강생 규모와 수강 가능 일정 등을 고려하여 교육 일정을 수립한다.

(가) 온라인 교육의 경우, 교육 콘텐츠 생성 기간과 온라인 교육 시스템 준비 기간

을 산정하여 교육 일정을 수립한다.

(나) 오프라인 교육의 경우, 교육 수강생 규모를 기반으로 교육 회차를 나누고, 회차

별 교육 일시에 따라 수강생을 모집한다.

(3) 교육 일정에 따라 교육 강사와 교육 장소를 섭외한다.

(가) 유지 보수 담당자 교육의 경우, CASE 도구 판매처와 연락하여 적절한 강사를

섭외한다.

(나) 사용자 교육의 경우, 조직 내에 적절한 강사가 없을 때에는 CASE 도구 판매처

또는 전문 교육 기관에 의뢰한다.

(4) 사용자 가이드와 유지 보수 업무 매뉴얼 등 관련 자료를 교육 강사에게 전달하고

강의 교안을 작성하게 한다.

(5) 교육 일정에 따라 교육 내용 공지 및 교구재와 간식 등을 준비하고 교육을 진행한다.

UI 툴

•UI 개발 툴 교육

2일

온사이트

교육

개발자

운영자

프로젝트 관

리 툴

•OPENPMS 교육

•형상 관리 툴

4시간

온사이트

교육

개발자

운영자

패키지 툴

•패키지 툴 교육

2일

온사이트

교육

운영자

DBMS 관리

•데이터베이스 운영 관련

•DBMS 설치 및 운영 방법

2일

온사이트

교육

운영자

[그림 1-15] 교육 홍보 예시

[그림 1-16] 교육생 간식 진열 예시

(가) 실습 교육의 경우, 컴퓨터를 사용할 수 있는 교육 장소를 섭외하고 사전에 해

당 CASE 도구를 설치한다.

[그림 1-17] 실습용 강의실 예시

[그림 1-18] 실습용 컴퓨터와 칠판, 스크린 예시

(나) 교육 수행 현황을 모니터링하고, 교육 만족도 조사를 통해 개선 사항을 도출하

여 차기 교육에 반영한다.

Ⅰ. CASE 도구 사용자 교육

①
매
우
그
렇
지
않
다

②
그
렇
지
않
다

③
보
통
이
다

④
그
렇
다

⑤
매
우
그
렇
다

■ 전반적 교육과정에 대한 만족도

1. 교육은 규정된 시간을 지키며 진행 되었습니까?

2. 교수자는 교육내용을 알기 쉽게 설명해 주었습니

까?

3. 교수자는 학습자가 수업에 적극적으로 참여하도록

유도하며 동기를 부여하였습니까?

4. 수업전반에 걸쳐 교수와의 소통이 원활하였습니까?

■ 교육내용에 대한 만족도

1. 본 수업을 통해 CASE 도구 사용을 위한 기초 개념

습득에 도움이 되었습니까?

2. 교육 프로그램의 난이도는 적당하였습니까?

3. CASE 도구 활용 능력을 키우는데 도움이 되었습니

까?

4. 본인이 참여한 교육의 후속 및 심화 프로그램에 계

속 참여할 생각이 있습니까?

I . 교육 운영

①
매
우
그
렇
지
않
다

②
그
렇
지
않
다

③
보
통
이
다

④
그
렇
다

⑤
매
우
그
렇
다

1. 교육 시설 및 장소에 만족하셨습니까?

2. 전반적인 운영에 만족하셨습니까?

3. 교육 시간 및 진행기간은 적절하였습니까?

<표 1-16> 교육생 반응 평가를 위한 평가문항 예시

 CASE 도구 사용 시 발생할 수 있는 문제 상황에 대한 처리 담당자 및 처리 프로세스를

수립하고, 사용 현황을 모니터링한다.

CASE 도구 사용 시 자주 발생하는 문제점과 대처 방안은 제품 판매처에서 제공받아서 정

리하고, 예상치 않은 문제 상황에 대한 처리 프로세스 및 담당자를 정의해서 문제 발생

시 신속하게 대응할 수 있도록 한다.

1. CASE 도구 판매처로부터 자주 발생하는 문제, 또는 문제로 오인식되는 경우에 대한 안

내 자료를 제공받아 정리한다.

2. 예상되지 않은 문제 상황을 처리하도록 프로세스를 수립하고 단계별로 담당자를 정하여

이슈를 처리한다.

(1) 조직 내에 이슈 관리 시스템이 있을 경우, 해당 시스템을 기반으로 이슈 처리 프로

세스를 정리한다.

이슈 관리 시스템이 없을 경우, 워드프로세서 기반으로 이슈 관리 목록을 만들고 이슈

조사, 이슈 등록, 이슈 분석, 이슈 해결 및 종료 등과 같이 단계별로 관리한다.

[그림 1-19] 이슈 관리 프로세스 예시

(2) CASE 도구 사용 현황을 모니터링하고 이슈 발생 시 이슈를 등록하고 분석한다.

(3) 이슈 해결 회의가 필요할 경우, 이해관계자들을 소집하여 해결 방안을 논의하고 처

리한다.

[그림 1-20] 이슈 해결 프로세스와 관련된 이슈 관리 조직 예시

[그림 1-21] 이슈 해결 방안 논의 회의 예시

(4) 이슈가 해결된 경우, 이슈 해결에 대한 상세 내용을 시스템 또는 이슈 관리 대장에

등록한다.

[그림 1-22] 이슈 관리 대장 예시

(5) 자주 발생하거나 문제 발생 시 영향이 클 경우에는 재발생했을 때 참고할 수 있도

록 이슈 해결 가이드를 작성한다.

학습1

교수·학습 방법

교수 방법

• CASE 도구가 무엇인지 설명하고 CASE 도구의 종류를 사례를 통해 설명한다.

• 응용 SW 개발 및 유지 보수 업무에서 CASE 도구를 도입할 경우 기대 효과를 사례를 들

어 설명한다.

• 응용 SW 개발 및 유지 보수 업무별로 활용 가능한 CASE 도구들을 나열하고 핵심 기능을

간략하게 설명한다.

• CASE 도구 선정에 있어 자료 수집, 평가 절차, 평가 기준, 비교 평가 방법 등을 예를 들어

설명한다.

• CASE 도구 기능 조사서와 평가 결과 보고서, CASE 도구 사용자 매뉴얼, 이슈 관리 계획

등 주요 보고서를 학습자가 직접 작성하도록 지도한다.

• CASE 도구 목록과 기능 조사서 양식, 평가지, 사용자 매뉴얼, 이슈관리 프로세스 등 CASE

도구 선정과 활용 업무에 관련된 양식을 목록화하고 샘플 양식을 학습자에게 제시한다.

학습 방법

• CASE 도구의 정의와 CASE 도구의 종류를 학습한다.

• 응용 SW 개발 및 유지 보수 업무에서 CASE 도구를 도입할 경우의 기대 효과를 학습한다.

• 응용 SW 개발 및 유지 보수 업무별로 활용 가능한 CASE 도구들과 주요 기능을 학습한다.

• CASE 도구 선정을 자료 수집 및 평가 절차, 평가 기준과 비교 평가 방법을 학습한다.

• CASE 도구 기능 조사서와 평가 결과 보고서, CASE 도구 사용자 매뉴얼, 이슈 관리 계획

등 주요 보고서를 직접 작성하면서 실전 활용 능력을 습득한다.

• CASE 도구 목록과 기능 조사서 양식, 평가지, 사용자 매뉴얼, 이슈관리 프로세스 등 CASE

도구 선정과 활용 업무에 관련된 문서 작성 실습을 통해 충분히 숙지한다.

학습1

평 가

평가 준거

• 평가자는 학습자가 학습 목표를 성공적으로 달성하였는지를 평가해야 한다.

• 평가자는 다음 사항을 평가해야 한다.

학습 내용

학습 목표

성취수준

상

중

하

CASE 도구 선정

- 개발하고자 하는 응용 소프트웨어에 적용할 개발 방

법론을 지원하는 최적의 CASE 도구를 선정할 수 있

다.

CASE 도구 활용

- CASE 도구가 제공하는 다양한 기능들 중 응용 소프트

웨어 개발 시 활용할 기능을 식별할 수 있다.

- CASE 도구 활용을 위한 절차와 표준을 정의하고

CASE 도구 사용 중 발생하는 이슈를 해결할 수 있다.

평가 방법

• 문제해결 시나리오

학습 내용

평가 항목

성취수준

상

중

하

CASE 도구 선정

- CASE 도구 도입 목표와 도입 정책 식별 능력

- CASE 도구 선정 계획 수립 능력

- CASE 도구 기능 정리 및 분류 능력

- CASE 도구 평가 기준과 방법 정의 능력

- CASE 도구 평가 능력

- CASE 도구 선정 결과 보고 능력

CASE 도구 활용

- CASE 도구 사용 매뉴얼 작성 능력

- CASE 도구 사용과 관련된 문제 관리 계획 수립 능력

- 선정된 CASE 도구의 기능 인지 및 활용 능력

• 사례연구

학습 내용

평가 항목

성취수준

상

중

하

CASE 도구 선정

- CASE 도구 도입 목표와 도입 정책 식별 능력

- CASE 도구 선정 계획의 문제점 분석 능력

- CASE 도구 기능 식별 및 분류 능력

- CASE 도구 평가 기준과 방법의 문제점 분석 능력

- CASE 도구 평가 결과 분석 능력

CASE 도구 활용

- CASE 도구 사용 매뉴얼 문제점 분석 능력

- CASE 도구 사용과 관련된 문제 관리 계획 분석 능력

피드백

1. 문제해결 시나리오

- 실습 과정에서 문제해결 시나리오를 제시하고 평가 항목별로 학습자가 수행한 내용을 검

토하여 수행 내용의 문제점을 식별하고 문제 유형별로 모범 답안을 제시한다.

- 학습자의 평가 결과가 ‘하’에 해당하는 경우, 모범 답안을 참조하여 수행 내용을 재작

성하게 한다.

- 학습자의 평가 결과가 ‘상’에 해당하는 경우, 다른 학습자들에게 발표 또는 설명하는

시간을 통해 다른 학습자의 실력 향상에 도움을 줄 수 있도록 한다.

2. 사례연구

- 평가를 위해 CASE 도구 선정 및 활용 사례를 배포하고, 평가 항목별로 학습자가 분석한

내용을 평가하고 부족한 부분에 대해 학습자가 이해할 수 있도록 설명한 후, 분석 결과

를 재작성하게 한다.

- 분석 결과를 재작성할 시간이 부족할 경우 또는 학습자의 평가 결과가 ‘하’에 해당하

는 경우, 모범 답안을 제시해서 부족한 부분을 보완할 수 있도록 한다.

- 학습자의 평가 결과가 ‘상’에 해당하는 경우, 다른 학습자들에게 발표 또는 설명하는

시간을 통해 다른 학습자의 실력 향상에 도움을 줄 수 있도록 한다.

학습 1

CASE 도구 활용하기

학습 2 품질요구사항 확인하기

2-1. 품질 표준과 평가 기준 정의

학습 목표

• 요구사항 명세서에 기술된 요구사항을 바탕으로 품질 표준을 정의하고 품질 평가

항목과 지침을 제공할 수 있다.

• 요구사항 명세서에 기술된 요구사항들이 품질 표준에 따라 올바르게 기술되었는지

를 검증하기 위한 품질 특성과 평가 기준을 제공할 수 있다.

필요 지식 /

 소프트웨어 품질 요구사항

1. 소프트웨어 요구사항 명세서

소프트웨어 요구사항 명세서는 소프트웨어 요구사항을 체계적이고 명확하게 정의한 문서

이다. 고객과 개발자가 협의를 통하여 공통의 목표와 기대를 기술하고 소프트웨어 제품이

나 서비스에 대한 개발 기준선을 제공하므로 요구사항 명세서는 명확하고 완전하게 정의

되어야 한다. 이를 통해 개발 프로세스 이전에 결함을 발견할 수 있으며 높은 생산성과

노력 투자 절감을 확보할 수 있다.

(1) 소프트웨어 요구사항 명세서 구성요소

소프트웨어 요구사항 명세서는 다음과 같은 항목들을 포함하여 구성할 수 있다.

구성요소

세부 내용

요구사항 고유번호

요구사항 추적 관리를 위해 표준 번호 체계에 따라 부여한

고유번호

요구사항 명칭

요구사항 이름

요구사항 분류

요구사항 분류 기준에 따른 분류명을 기술함.

요구사항 정의

요구사항의 세부 내용을 대표적으로 표현할 수 있도록 기술함.

요구사항 세부 내용

요구사항의 구체적인 내용을 기술함.

산출 정보

해당 요구사항을 통해 산출되는 결과물 또는 정보를 표기함.

관련 산출물

분석

요구사항 정의 및 분석

요구사항 검토

요구 명세 검토

요구와 관련된 메트릭과 지표

평가

프로토타이핑

모델 검토

요구사항 정의서, 요구사항 명세서

유스케이스 명세서

프로세스 정의서

인터페이스 정의서

요구사항 추적표

설계

기본 설계

상세 설계

소프트웨어 설계 리뷰, 인스펙

션, 워크스루

설계 관련 메트릭과 지표 평가

소프트웨어 통합 테스트 계획

클래스 설계서

컴포넌트 설계서

인터페이스 설계서

아키텍처 설계서

UI(화면) 설계서

데이터베이스 설계서

ERD, 테이블 목록, 테이블 정의서

프로그램 목록

개발 표준 정의서

테스트 계획서(단계별 또는 총괄)

단위 테스트 케이스/시나리오

통합 테스트 케이스/시나리오

시스템 테스트 케이스/시나리오

구현,

테스트

구현

단위 테스트

통합 테스트

시스템 테스트

코드 리뷰, 인스펙션, 워크스루

정적 분석 체킹

메트릭과 지표 평가

코딩 표준 준수 여부 체크

프로그램 소스코드

단위 테스트 결과서

통합 테스트 결과서

시스템 테스트 결과서

결함/오류 보고서

시스템 이행 계획서

운영,

유지 보수

시스템 및 서비스 운영,

유지 보수 검토, 반영

변경 분석 및 제어

회귀 테스트

시스템 이행 결과서

사용자 매뉴얼, 운영자 매뉴얼

프로젝트 완료 보고서

<표 2-12> 품질 요구사항을 반영한 개발 공정 예시

2. 소프트웨어 제품의 품질을 평가하고 관리하기 위해 프로젝트 관리 프로세스와 품질 관

리 프로세스를 검토하고 조정한다.

품질 요구사항에서 요청하는 사항을 반영하여 기존에 작성된 프로젝트 관리 프로세스나

품질 관리 프로세스를 수정한다.

(1) 품질 관리 프로세스를 검토하고 조정한다.

[그림 2-7] 품질 관리 프로세스 예시

(2) 프로젝트 관리 프로세스를 검토하고 조정이 필요한 프로세스를 선택하여 수정한다.

[그림 2-8] 프로젝트 관리 프로세스 목록 예시

[그림 2-9] 인스펙션 프로세스 정의 예시

순서

활동

설명

인스펙션

계획 수립

인스펙션 진행자는 품질 활동 계획에 의거하여 검토 대상 산출물의 작성이

완료되는 시점에 인스펙션 계획을 수립하고 관련 프로젝트 팀원에게

통보한다.

- 참여자 선정 및 역할 할당(검토자, 산출물 작성자, 서기)

- 장소 및 일정 확정

- 산출물 검토 시 준비 사항(검토 산출물, 참조 산출물, 산출물 검토

체크리스트, 착수/종료 기준 등) 확인

착수 회의

실시

인스펙션 진행자는 착수 회의를 실시한다.

- 관련자에 따라 On-line으로 착수 회의를 대신할 수도 있다(메일, 쪽지, 공지

등).

- 인스펙션에 대한 교육이 필요하다면 착수 회의 시 같이 실시하도록 한다.

개별 검토

검토자들은 배포한 산출물에 대해 검토를 실시하여 결함 후보를 도출한다.

결함 후보, 질문 사항 등 발견된 것들을 개별 검토 Log에 기재한다.

- 개별 검토 Log는 정확한 위치, 결함 내용이 식별될 수 있도록 명확히

기재한다.

- 체크리스트는 검토 보조 자료일 뿐 절대적인 지침은 아니다.

합동 검토

검토자는 합동 검토 전에 개별 검토 Log를 인스펙션 진행자에게 제출하고

인스펙션 진행자는 개별 검토가 충분히 이루어져서 합동 검토를 할 수 있는

수준인지 확인한다.

인스펙션 진행자, 검토자, 산출물 작성자가 함께 검토를 수행하고 최종적으로

결함 여부를 결정한다.

- 결함 여부에 대한 논쟁이 있다면 인스펙션 진행자가 최종 결함 여부를

결정한다.

서기는 시정 조치서를 작성하여 인스펙션 진행자에게 전달한다.

<표 2-13> 인스펙션 프로세스 상세 절차 정의 예시

3. 개발 공정 단계별의 산출물별로 산출물 양식, 작성 규칙 등을 포함하는 제품 표준을 정

의한다.

제품 표준은 개발 주기 동안 산출해야 할 소프트웨어 결과물의 구조, 표현, 형식, 확인

및 검증을 위한 체크리스트 등을 포함한다.

(1) 개발 프로젝트에 적용할 공통 표준을 정의한다.

(가) 문서 명명 표준을 정의한다.

소프트웨어 분석, 설계, 개발 시에 작성되는 각종 산출물 및 통제 ID의 명명 규칙

(Naming Rules)을 정의하여 분석, 설계, 개발 작업이 일관성 있고 정확하게 수행되

도록 한다. 프로젝트 진행 중 표준화해야 하는 명명 규칙 발생 시에는 해당 내용을

표준에 추가한다.

1) 문서ID 명명 규칙을 정의한다.

보고용 문서(회의록, 주간/월간 보고서, 단계 보고 등) 및 개발 공정 산출물이

아닌 경우는 별도의 문서ID를 부여하지 않는다.

[그림 2-10] 문서ID 명명 규칙 예시

순서

활동

설명

시정 조치

수행

산출물 작성자는 인스펙션 결과를 분석하여 결함에 대한 시정 조치 계획을

수립한 후 조치를 수행한다.

시정 조치가 완료되면 시정 조치서에 조치 내역을 기재하고 인스펙션

진행자에게 통보한다.

보완 결과

확인

인스펙션 진행자는 시정 조치서 상의 보완 작업 완료 여부를 확인한다.

인스펙션 진행자 판단 하에 필요 시 보완 완료된 산출물에 대한 재검토를

실시한다.

확인이 완료된 산출물은 형상 통제 절차에 따라 형상 관리 서버에 등록한다.

보고 및

측정

인스펙션 진행자는 인스펙션 결과를 PM 및 관련자에게 보고하고 측정

항목을 기록한다.

QCO는 인스펙션이 종료되었음을 확인한다.

2) 문서 파일 명명 규칙을 정의한다.

문서가 프로젝트 관리 도구에서 작성 및 관리되는 경우에는 해당 도구에서 자

동으로 생성되는 파일 명명 규칙을 따른다.

[그림 2-11] 문서 파일 명명 규칙 예시

(나) 프로젝트 수행 시 지속적인 관리가 필요한 항목에 대해 부여하는 통제ID 부여

규칙을 정의한다.

[그림 2-12] 통제ID 부여 규칙 예시

(다) 산출물을 포함한 모든 프로젝트 문서에 대한 작성 표준을 정의한다.

문서의 페이지 설정, 표지, 문서 개정 이력, 목차, 본문 서식 등에 대한 표준을 정

의한다.

1) 페이지 설정 규칙을 정의한다.

[그림 2-13] 페이지 설정 기준 예시

2) 문서 표지 작성 규칙을 정의한다.

제목 : 문서 명을 기재한다.

문서ID : 문서ID 명명 규칙에 정의된 문서ID를 기재한다.

VERSION : 해당 문서가 변경된 최근 Version을 기재한다.

작성일 : 문서 최종 작성일을 기재한다.

로고 : 고객사 로고, 수행사 로고

[그림 2-14] 문서 표지 작성 규칙 예시

3) 개정 이력 작성 규칙을 정의한다.

첫 작성한 문서에 대해서는 0.7로 버전 기재

내부 품질 검토 대상 산출물인 경우 검토 결과 시정 조치 후 0.8로 버전 기재

PMO 검토 완료 후(시정 조치 완료) 고객에게 제출되는 모든 문서는 0.9 버전으

로 제출

고객의 승인을 득한 문서(시정 조치 완료)에 대해 버전 1.0으로 지칭(최초 베이

스라인)

베이스라인 설정 이후 공식 통제(변경 요청, 품질 검토 등)에 의해 수정 시에

는 버전을 0.1씩 올려서 지칭

다음 단계에 베이스라인을 변경하는 경우에는 버전을 1.0씩 올림.

고객에게 제출하지 않는 관리본 문서는 최초 제정 시 버전 1.0으로 지칭하고

단계 내 개정 시에는 0.1씩, 단계를 넘겨 개정 시에는 1.0씩 올림.

[그림 2-15] 문서 개정이력 작성 규칙 예시

4) 머리말 및 꼬리말 작성 규칙을 정의한다.

머리말, 꼬리말은 맑은 고딕, 보통, 9 Point로 작성한다.

페이지 번호는 문서에 따라 일련번호(예 : 1, 2, 3), 장 번호-일련번호(예 : I -4),

일련번호/총 페이지 수(예 : 1/7) 등으로 부여한다.

표지에는 머리말, 꼬리말을 적용하지 않는다.

Tool을 사용한 산출물의 경우는 Tool에서 제공하는 형식에 따른다.

머리말, 꼬리말 구성은 다음과 같다.

[그림 2-16] 머리말, 꼬리말 작성 규칙 예시

5) 문서 내용에 대한 표준 서식을 정의한다.

구분

서식 유형

글꼴

크기

속성

정렬

비고

제목 1

맑은 고딕

굵게

좌측 정렬

제목 2

1.1

맑은 고딕

굵게

좌측 정렬

제목 3

1.1.1

맑은 고딕

굵게

좌측 정렬

제목 4

1.1.1.1

맑은 고딕

굵게

좌측 정렬

본문 번호 1

(1)

맑은 고딕

보통

좌측 정렬

본문 번호 2

맑은 고딕

보통

좌측 정렬

본문 번호 3

가 .

맑은 고딕

보통

좌측 정렬

본문

맑은 고딕

보통

좌측 정렬

강조점 1

○

맑은 고딕

보통

좌측 정렬

한 수준 내리기

강조점 2

−

맑은 고딕

보통

좌측 정렬

두 수준 내리기

강조점 3

￭

맑은 고딕

보통

좌측 정렬

세 수준 내리기

표 /그림

제목

< >

맑은 고딕

보통

가운데 정렬

표 /그림 하단

중앙에 기재

표 헤더

표

헤더

맑은 고딕

굵게

가운데 정렬

바탕 : 회색

표 내용

표

내용

맑은 고딕

보통

필요에 따라

적용

표 개요 1

−

맑은 고딕

보통

필요에 따라

적용

필요에 따라

변형하여 사용할

수 있음.

표 개요 2



맑은 고딕

보통

필요에 따라

적용

필요에 따라

변형하여 사용할

수 있음.

<표 2-14> 문서 표준 서식 예시

(2) 개발 공정 단계별로 생성되는 산출물에 대한 표준을 정의한다.

산출물 표준은 양식, 작성 표준, 가이드로 구성한다.

구성

설명

필수 여부

사용 예

양식

Template

비정형 양식으로 기본 서식 및

목차가 정의되어 있는 양식

필수

테스트계획서_양식.ppt

Form

정형 양식으로 작성 항목이

고정되어 있는 양식

필수

요구사항정의서_양식.xls

작성

표준

Standard

산출물의 작성 항목에 대한

작성 방법 설명

필수

유스케이스정의서_작성

표준.ppt

가이드

Guide

산출물/액티비티에 대한

상세한 가이드라인

선택

유스케이스모델링가이

드.doc

<표 2-15> 산출물 표준의 구성

(가) 소프트웨어 개발 프로젝트에서 사용했던 산출물 표준 양식을 참조하여 개발 공

정 단계별로 산출물 양식을 작성한다.

요구사항 정의서

업무구분

자동차보험

업무대분류

보상처리

작성일

0000.00.00

작성자

홍길동

요구ID

요구사항명

요구사항 상세내용

유형 요청자 IT담당자 출처구분 우선순위 수용여부 비고

RQ-B-001

고객상담이

력등록

콜센터 상담원과 보상처
리 직원 간 상담이력 공유
를 위한 기능 구현　

기

능

김길

동　

나IT　

회의록

_0000_

00_00

RQ-B-002

간편접수정

보 등록

간편접수를 통해 현장출
동할 수 있는 기능 구현

기

능　

나길

동　

김IT　

회의록

_0000_

00_00

. .

<표 2-16> 요구사항 정의서 산출물 작성 예시

(나) 산출물 작성 시 참조할 수 있도록 산출물별로 가이드를 작성한다.

산출물 양식에 포함된 구성요소별로 작성 방법이나 기준을 포함하도록 가이드를

작성한다.

1. 요구ID : 업무별 ID 부여 규칙을 참조하여 작성한다.

- 요구ID 체계 : YG-업무대분류ID(2자리)업무중분류ID(2자리)-999(시리얼3자리)

- 업무 분류 기준 : 표준업무구분 참조

2. 유형 : 고객 요구사항에 대한 요건을 [기능/기술/인터페이스/기타] 관점으로 분류하

여 기재한다.

-기능 : 시스템에서 필요한 기능 및 동작/행위를 직접적으로 기술한 요구사항(관련된

업무 규칙과 데이터 정의를 포함함.)

-기술 : 시스템 인프라, 소프트웨어 인프라, 개발 환경 및 운영 환경에 관련된 요구

사항

-인터페이스 : 시스템과 외부 간의 연결, 시스템 간의 연결에 관련된 요구사항

-기타 : 위의 분류 사항을 제외한, 고객이 생각하는 시스템에 대한 직접/간접적인 요

구사항들

3. 요청자 : 요구사항을 요청한 고객 담당자를 기재한다.

4. IT담당자 : 요구사항에 대해 분석/설계를 담당할 개발자를 기재한다.

5. 출처 구분 : 요구사항이 도출되는 근거 자료를 기재한다.

6. 우선순위 : 해당 요구사항의 우선순위를 평가하여 H/M/L로 기재한다.

7. 수용 여부: 수용 여부에 대하여 기재한다.

8. 비고 : 기타 내용을 기재한다.

[그림 2-17] 요구사항 정의서 가이드 내용 예시

 요구사항 품질 검증을 위한 품질 특성과 평가 항목, 평가 기준을 정의한다.

소프트웨어 요구사항 품질 평가 항목 표준(TTAK.KO-11.0103) 등과 같은 요구사항 품질 모

델을 참조하여 요구사항 품질 관리를 위한 품질 특성과 평가 항목, 평가 기준을 정의한다.

1. 표준 품질 모델을 참조하여 요구사항 품질 관리와 관련된 품질 특성과 평가 항목을 정의한다.

표준 품질 모델의 품질 특성과 평가 항목들을 검토하여 현재 상황에 맞는 품질 특성과 평가 항목

을 선택한다.

품질 특성

평가 항목

평가 내용

완전성

기능 완전성

요구사항 명세서의 요구사항 중 누락된 기능 요구사항이

존재하는지 여부

품질 완전성

요구사항 명세서의 요구사항 중 누락된 비기능 요구사항이

존재하는지 여부

기능 설계

완전성

설계 명세서 상에 식별된 설계 항목 중 누락된 기능

요구사항이 존재하는지 여부

품질 설계

완전성

설계 명세서 상에 식별된 설계 항목 중 누락된 비기능

요구사항이 존재하는지 여부

정확성

기능 정확성

요구사항 명세서의 기능 요구사항 중 논리적으로 정확하게

기술한 명세의 작성 비율

품질 정확성

요구사항 명세서의 비기능 요구사항 중 논리적으로 정확하게

기술한 명세의 작성 비율

기능 설계

정확성

설계 명세서의 기능 설계 항목 중 논리적으로 정확하게 기술한

명세의 작성 비율

품질 설계

정확성

설계 명세서의 비기능 설계 항목 중 논리적으로 정확하게

기술한 명세의 작성 비율

명확성

요구사항

명확성

요구사항 산출물에 기술한 용어가 이해관계자들에게 모호하지

않고 명확하게 의미 전달되는지 여부

설계 명확성

설계 산출물에 기술한 용어가 이해관계자들에게 모호하지 않고

명확하게 의미 전달되는지 여부

일관성

요구사항

내부 일관성

요구사항 명세서의 요구 명세 항목의 연관 및 종속 관계가

있는 항목 간의 불일치가 존재하는지 여부

요구사항

전방 일관성

요구사항 명세서와 요구 명세 이전 단계의 산출물 간의 연관

항목 중 불일치가 존재하는지 여부

요구사항

후방 일관성

요구사항 명세서와 요구 명세 이후 단계의 산출물 간의 연관

항목 중 불일치가 존재하는지 여부

검증

가능성

요구사항

검증 가능성

요구사항 명세서 상에 명세에 대한 검증 기준 및 방법을

제시하였는지 여부

설계 검증

가능성

설계 명세서 상에 명세에 대한 검증 기준 및 방법을

제시하였는지 여부

<표 2-17> 요구사항 품질 관리와 관련된 품질 특성과 평가 항목 예시

2. 요구사항 품질 평가 항목별로 측정 방법과 측정 값의 범위, 대상 산출물 등 품질 평가

기준을 정의한다.

품질 평가 항목에 대해 객관적이고 정량적인 평가를 할 수 있는 표준화된 소프트웨어 품질

측정 방법(메트릭)을 정의한다. 품질 측정 메트릭은 특정 값을 계산하는 방법을 기술한다.

품질 특성

평가 항목

평가 내용

수정

용이성

요구사항

수정 용이성

요구사항 명세 항목이 쉽게 식별되고 원하는 수정이 용이하게

반영되며 수정에 대한 영향도 분석이 용이하게 이루어지는지

여부

설계 수정

용이성

설계 명세 항목이 쉽게 식별되고 원하는 수정이 용이하게

반영되며 수정에 대한 영향도 분석이 용이하게 이루어지는지

여부

추적성

요구사항

내부 추적성

요구사항 명세서 내의 식별된 요구 명세 항목의 연관 관계 및

종속 관계가 있는 항목 간의 추적 관계를 식별하였는지 여부

요구사항

전방 추적성

요구사항 명세서와 요구 명세 이전 단계의 산출물 간의 연관

항목 중 추적 관계를 식별하였는지 여부

요구사항

후방 추적성

요구사항 명세서와 요구 명세 이후 단계의 산출물 간의 연관

항목 중 추적 관계를 식별하였는지 여부

이해

가능성

요구사항

이해 가능성

요구사항 산출물에 기술한 문장이 표준 형식을 따르며 적절한

문법을 따르고 있으며 다중 문장을 배제하여 용이하게 이해

가능한지 여부

설계 이해

가능성

설계 산출물에 기술한 문장이 표준 형식을 따르며 적절한

문법을 따르고 있으며 다중 문장을 배제하여 용이하게 이해

가능한지 여부

품질 특성

평가 항목

측정 방법

측정 범위

대상 산출물

완전성

기능 완전성

X=(도출된 기능 요구사항의

수)/(전체 사용자 기능

요구사항의 수)

0<=X<=1

RFP, 과업수행

계획서, 회의록,

요구사항 목록,

요구사항 명세서

품질 완전성

X=(도출된 비기능 요구사항의

수)/(전체 사용자 비기능

요구사항의 수)

0<=X<=1

RFP, 과업수행

계획서, 회의록,

요구사항 목록,

요구사항 명세서

기능 설계

완전성

X=(설계된 기능 요구사항의

수)/(전체 사용자 기능

요구사항의 수)

0<=X<=1

RFP, 과업수행

계획서, 회의록,

요구사항 목록,

요구사항 명세서,

설계 목록, 설계

명세서

<표 2-18> 요구사항 품질 평가 항목별 측정 방법 예시

수행 tip

• 표준 품질 모델을 참조하여 현재 프로젝트에 적합한

품질 특성과 측정 방법을 선택한다.

• 품질 목표 달성 여부 점검을 위해 메트릭과 함께 측

정 지표를 정의한다.

품질 특성

평가 항목

측정 방법

측정 범위

대상 산출물

정확성

기능 정확성

X=(논리적으로 정확하게 기술한

기능 요구사항의 수)/(도출된

세부 기능 요구사항의 수)

0<=X<=1

요구사항 목록,

요구사항 명세서

품질 정확성

X=(논리적으로 정확하게 기술한

비기능 요구사항의 수)/(도출된

세부 비기능 요구사항의 수)

0<=X<=1

요구사항 목록,

요구사항 명세서

기능 설계

정확성

X=(논리적으로 정확하게 기술한

기능 설계 항목의 수)/(작성된

세부 기능 설계 항목의 수)

0<=X<=1

설계 목록, 설계

명세서

명확성

요구사항

명확성

X=(해당 점검표에서 검사 결과

F/P/N의 점수 집계)/(해당

점검표의 평가 대상 항목의 점수

합계)

0<=X<=1

요구사항 명세서를

포함한 요구 분석

산출물

설계 명확성

X=(해당 점검표에서 검사 결과

F/P/N의 점수 집계)/(해당

점검표의 평가 대상 항목의 점수

합계)

0<=X<=1

설계 명세서를

포함한 설계

산출물

일관성

요구사항

내부 일관성

X=1-(연관된 요구사항 간 충돌

건수)/(도출된 요구사항 내 연관

건수)

0<=X<=1

요구사항 목록,

요구사항 명세서,

요구사항 추적표

요구사항

전방 일관성

X=1-(요구사항과 전방 요구사항

충돌 건수)/(도출된 요구사항과

전방 산출물 간의 연관 건수)

0<=X<=1

RFP, 과업수행

계획서, 회의록,

요구사항 목록,

요구사항 명세서,

요구사항 추적표

2-2. 개발 공정과 제품 품질 점검

학습 목표

• 개발 공정 품질 관점에서 표준 준수 여부를 확인하고, 응용 소프트웨어 제품 품질

관점에서 결함을 식별하여 해결할 수 있다.

필요 지식 /

 소프트웨어 개발 공정 평가 표준

소프트웨어 개발 공정이란 소프트웨어를 개발하고 유지하는 작업 흐름(Work-flow)에 적용

되는 활동, 방법, 규칙 등을 말한다. 개발 공정 품질 관점에서 표준 준수 여부는 작업 흐

름 또는 프로세스 각 단계에서 품질 평가 항목을 측정하고, 품질 향상을 위한 표준, 규제,

규칙을 준수하는지 확인하는 것이다.

소프트웨어의 품질과 생산성 향상을 위해 개발 공정 평가 모델을 수립하고, 평가를 통해

개발 공정을 지속적으로 개선할 필요가 있다. 개발 공정 평가 모델은 개발 부서에서는 개

발 공정을 개선하는 데 적용되며, 평가 부서에서는 개발 조직의 개발 능력과 지원 능력

평가를 위한 기준으로 적용되고, 발주 부서에서는 적정한 개발 능력을 갖춘 개발 기관 선

정에 적용된다.

1. CMM(Capability Maturity Model) & CMMI(Capability Maturity Model Integration)

CMM은 1991년 미 국방성의 지원에 의해 카네기멜론대학의 SEI(Software Engineering

Institute)에서 개발되어 미 국방성을 비롯한 NASA 등 미국 내 정부 기관과 통신 업체 및

소프트웨어 개발 업체 등에서 개발 공정 평가 모델로 적용되고 있다. CMMI는 개발 능력

측정 기준과 SW 프로세스 평가 기준을 제공함으로써 개발 조직의 성숙 수준을 평가할 수

있는 프로세스 모델로 개발되었다. 프로세스 관리, 프로젝트 관리, 엔지니어링, 지원의 네

영역을 레벨1 Initial부터 Managed, Defined, Quantitatively Managed, 그리고 가장 높은 수

준의 레벨5 Optimizing까지 5단계로 평가한다.

2. ISO/IEC 15504(SPICE: Software Process Improvement and Capability dEtermination)

영국 국방부 제안에 의해 시작되었으며 소프트웨어 개발 업체의 구매, 개발, 운용 부서에

서 수행되는 계획 수립, 개발, 관리, 감시 및 제어 공정 등에 대한 개선 및 평가 표준을

마련하기 위해 추진되었다. SPICE에서 정의하고 있는 프로세스는 5개의 범주로 구분되며

이들의 능력 수준은 각 수준별 측정 관점에 따라 레벨0 불완전 수준부터 레벨5 최적까지

6개의 수준으로 구분된다.

3. 소프트웨어 프로세스 품질 인증(Software Process 인증)

국내 소프트웨어 업체의 소프트웨어 사업 수행 능력 강화와 부실 방지를 목적으로, 5개

영역, 17개 평가 항목, 70개 세부 평가 항목으로 구성된 소프트웨어 개발 단계별 작업 절

차 및 산출물 관리 역량 등을 분석함으로써 소프트웨어 개발 프로세스 역량 수준을 평가

하고, 2개 등급(2등급, 3등급)으로 인증한다.

 품질 점검 기법

소프트웨어 개발 공정과 개발 제품이 설정된 품질 요구에 부합하는지 확인하는 품질 보증

활동을 확인과 검증이라 한다. 확인(Verification)은 “소프트웨어를 올바로 만들었는가?”

라는 물음에 관한 것이고, 검증(Validation)은 “올바른 소프트웨어를 만들었는가?”라는 물

음에 관한 것이다. 즉 확인은 개발 공정이 정확하게 수행되었는지 확인하는 것이고, 검증

은 정확한 제품이 만들었는지 확인하는 것이다.

1. 정적 검증과 동적 검증

검증은 정적 검증과 동적 검증으로 나눌 수 있다. 정적 검증은 소프트웨어를 실행하지 않

고 제품의 정확성을 체크하는 방법이고, 동적 검증은 제품이나 프로토타입을 실행하는 방

법이다. 일례로 소프트웨어 테스팅은 시스템이나 컴포넌트를 실행하기 위한 동적 확인 방

법이다. 인스펙션, 워크스루, 동료 검토는 정적 확인과 검증 기법으로 널리 사용되고 있다.

2. 인스펙션

1970년대 초 IBM의 마이클 페이건에 의해 정립된 개념으로 소프트웨어 요구, 설계, 원시

코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방

법이다. 소프트웨어의 품질을 높이는 방법 중 하나이며 결과물 자체의 품질과 결과물을

만들어 내는 과정도 인스펙션에 포함된다.

(1) 인스펙션 대상

요구사항, 설계 등의 문서 산출물, 개발 단계의 소스코드 등이 인스펙션 대상에 포함

된다.

(2) 인스펙션 원칙

인스펙션은 발견된 결함에 대한 해결책을 찾는 것이 아니라, 결함이 있다는 사실을 합

의하는 것이 주목적이다.

인스펙션 주재자는 결함을 발견하는 데 집중한다. 해결책을 찾는 것은 설계자나 프로

그래머의 역할임을 인식하고 담당자의 권한을 존중하여 인스펙션 회의가 길어지지 않

도록 조정(통상 2시간 이내)한다.

(3) 인스펙션 참여자

참여자

역할

주재자

•

인스펙션 팀의 실제적인 매니저

•

인스펙션 팀과 코드를 작성한 개발 팀 간의 인터페이스를 담당,

필요한 리소스와 인프라를 확보

•

인스펙션에 대한 프로세스 정의와 산출물의 정리

•

인스펙션한 결과에 대해서 테스트가 필요할 때 테스팅 환경을

확보하고 관련 인력을 섭외

•

고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최

•

가장 중요한 역할 중의 하나는 인스펙션이 언제 끝날 것인지(Exit

Criteria)의 정의

개발자

•

인스펙션에 필요한 자료를 제출

•

만약 자료를 제출하지 않았다면 자료 직접 내용을 설명하거나 자료에

관한 질문에 대답함.

•

회의 내용을 신중히 듣고 토의에 적극적으로 참가

•

회의가 끝난 후, 검출된 오류 내용에 대해 후속 조치를 수행

제출자

•

객관적이고 정확하게, 개발자를 대신하여 검토될 생산물의 자료를

제출

•

인스펙션 회의 동안 개발자보다 좀 더 객관적인 입장에서 의견 제시

<표 2-19> 인스펙션 참여자 역할

(4) 인스펙션 절차

[그림 2-18] 인스펙션 절차

단계

수행 활동

Planning

- 인스펙션 주재자가 인스펙션의 작업과 과정을 확립하는 단계

- 팀, 일정, 장소 예약, 인스펙션 대상과 자료 준비

Overview

- 소프트웨어를 간단히 설명하거나 어떤 작업이 어떻게

수행되었는지, 어떤 인터페이스가 있는지 설명

- 사전 교육을 할 것인지 안 할 것인지는 인스펙션 주재자가 판단

Preparation

- 인스펙션 팀 멤버가 인스펙션 자료를 받고, 인스펙션 회의를 통보 받은

때부터 시작

- 회의 통지는 리뷰할 자료의 분량과 복잡도에 따라 인스펙션 준비에

필요한 최소 소요 시간을 고려하여 결정

Meeting

- 발견한 결함을 팀 구성원이 모여 논의하는 것

- 결함이 발견되면 서로 토론하는 방식으로 진행

- 결함을 발견하는 것으로 제한하고 해결책을 논의하지 않음.

- 해산 시에는 주재자가 발견한 결함에 대하여 종합하여 재시행(Rework)

여부, 인스펙션 유형 등을 작성자에게 전달함.

<표 2-20> 인스펙션 절차

3. 워크스루(Walkthrough)

워크스루는 가상의 입력에 대하여 원시 코드의 수행을 문장 하나씩 짚어 보는 작업으로,

데이터 정의 부분, 매뉴얼, 명세 등 프로그램이 아닌 부분도 검토 대상이 된다.

(1) 워크스루 목적

소프트웨어의 특정 부분을 검토하는 것을 말하며, 각각의 상세 설계 내용에 대해 검토

한다. 시스템 개발의 각 단계마다 실시하는 기술적인 검토 회의의 형태로, 오류를 조

기 검출하는 데 목적을 두고 있다. 정형 검토 방법보다는 덜 정형적이나, 계획된 검토

회의로서는 효율적인 방법이다. 실행 시간은 짧으며, 참여자의 수도 소규모이다.

(2) 워크스루 특징

• 비정형적인, 일종의 아이디어 회의로서 비정기적이고 수시로 실시한다.

• 검토 자료의 사전 배포와 검토, 짧은 시간의 회의로, 주로 사례에 대한 정보 공유나

동료들과의ﾠ아이디어 수집을 위해서 사용한다.

• 오류 검출에 목적이 있으며, 오류의 문서화를 수행하고 해결책은 미룬다.

• 발표자만 유일하게 리뷰를 주관하고 발표하는 역할을 하며,ﾠ다른 참여 인원들은 아

무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다.

• 개발 팀보다는 품질 관리자(QA)나 시스템 운영 팀에서 장애 사례나 버그 수정 사례

등의 정보 교환을 목적으로 하는 것이 좋다.

4. 동료 검토(Peer Review)

동료 검토는 2~3명(주로 2명)이 진행하는 코드 리뷰의 형태를 말한다. 코드 리뷰는 코드

작성자가 모니터를 보면서 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를

제안하거나 결함을 발견하는 형태로 진행된다. 사전 준비가 거의 필요 없고, 필요할 때마

다 자주 사용할 수 있는 리뷰 방법으로 주로 시니어(Senior) 개발자(사수)가 주니어(Junior)

개발자를 멘토링할 때 사용할 수 있다. 주니어 개발자에 대한 교육과 함께, 주니어 개발자

가 양산한 코드에 대한 품질을 관리할 수 있다. 시니어 개발자의 리뷰 역량에 따라서 결

과물의 품질이 달라질 수 있고, 시니어 개발자의 시간 투여량이 많아 시니어 개발자의 참

여도가 떨어질 수 있다.

단계

수행 활동

Rework

- 다시 작업하는 과정으로, 발견된 결함을 면밀히 살펴보고 필요한

부분을 수정

- 인스펙션이 다시 필요하다고 결정되면 인스펙션을 다시 준비함.

Fol ow-up

- 인스펙션에서 발견된 모든 결함이 수정되었는지 확인하는 것으로

인스펙션 주재자가 함.

- 검사가 모두 끝나면 소프트웨어 품질 관리자에게 종합 보고를 제출하고

인스펙션을 종료

 결함관리 기법

소프트웨어의 품질을 보증하고 향상시키기 위해서는 검증 및 확인(Verification and

Validation) 결과 또는 테스트 수행 결과 발견된 결함을 식별, 분석하여 결함을 제거하고,

이로 인해 변경되는 설계 및 소스 버전과 이력 관리가 필요하다.

1. 결함(Defect) 구분

결함은 다양하게 정의되며, 일반적으로 요구사항을 충족시키지 못하게 하는 원인에 따라

아래와 같이 구분할 수 있다.

- 요구사항에 명시되어 있는데 구현되지 않은 경우

- 요구사항대로 구현되었는데 정상 동작하지 않는 경우

- 요구사항에 명시되어 있지 않은데 구현되어 있는 경우, 즉 의도하지 않은 기능이 구현

되어 있는 경우

- 요구사항에는 명시되어 있지 않고, 구현되어 있는 부분에서 정상 동작하지 않는 경우

2. 결함 유형

요구사항 명세의 표준 미준수/불명확/불완전 등의 ‘요구사항 분석 관련 결함’, 설계 표

준 미준수 및 불명확, 인터페이스 불일치 등의 ‘설계서 결함’, 코딩 표준 미준수, 인터

페이스 결함, 데이터 결함 등의 ‘구현 단계에서 유입되는 결함’이 있다.

3. 결함 해결 방법

발견된 결함에 대해서 결함 관리 시스템을 통해 해결한다. 결함이 발견되면 결함 관리 시

스템에 등록(Bug Open)하고, 결함의 중요도와 심각도를 검토한 후, 수정 여부를 결정

(Triage)한다. 수정(Bug Fix)된 결함에 대해서 수정이 제대로 되었는지, 수정으로 인해 다

른 결함이 생성(Side Effect)되지는 않았는지 확인(Regression or Confirm Test)하는 과정을

수행한다.

수행 내용 / 개발 공정과 제품 품질 점검하기

재료·자료

• SW 제품 품질 국제 표준(ISO/IEC 9126, IEEE1061, ISO/IEC 14598, ISO 9000 등)

• SW 프로세스 품질 국제 표준(ISO15504, ISO/IEC 12207 등)

• 소프트웨어 품질 요구사항 작성 지침(정보통신단체표준 TTAK.KO-11.0112)

• 소프트웨어 표준적합성 평가 절차(정보통신단체표준 TTAS.KO-11.0077)

• 표준적합성 평가도구 요구사항(정보통신단체표준 TTAS.KO-11.0061)

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

안전 ･ 유의 사항

• 품질활동 계획서는 프로젝트수행 계획서와 전사품질관리 표준을 기반으로 작성한다.

• 품질 검토 조직 구성 시 테스트 전문가와 업무 전문가, 전사 품질 관리자를 포함한다.

수행 순서

 개발 공정과 제품 품질 관리를 위한 주기적인 점검 계획을 수립한다.

프로젝트 개발 공정 개선과 산출물 및 개발 소프트웨어의 품질을 향상하기 위한 품질 관

리 활동을 주기적으로 수행할 수 있도록 점검 계획을 수립한다.

1. 품질 관리 활동을 수행할 조직을 구성하고 담당 역할과 책임을 명시한다.

소속 구분

담당자

역할 및 책임

전사 품질관리조직

품질관리 책임자

품질 관리 방침 설정, 수립, 승인

프로세스 관리자

개발 방법론 개선, 운영, 교육

품질관리 실무자

제품 출하 검사 수행, 품질 활동 지원

<표 2-21> 품질 관리 활동 조직의 역할과 책임 예시

2. 품질 목표를 확인하고 조정한다.

프로젝트 수행 초기에 명확하게 정의하지 않았던 품질 목표는 분석이나 설계 단계를 진행하면서 구체적으로 정의한다.

소속 구분

담당자

역할 및 책임

시스템 운영조직

TA 조직

프로젝트 개발/운영 기술 아키텍처 설계 및 구축

지원

기술적 이슈 및 위험 요소 해결 지원

성능 테스트 및 튜닝 지원

SA 조직

소프트웨어 아키텍처 설계 및 개발 지원

소프트웨어 설계 전략 및 방안 정립

프로젝트 수행조직

프로젝트 관리자

프로젝트 품질 관리 계획 승인, 품질 보증 책임

품질 활동 시정 조치 지휘, 의사 결정 사항 보고

품질 관리자

품질 활동 계획 수립, 방법론 수립 및 교육, 표준 및

절차 이행 확인 및 관리

형상 관리자

형상 관리 프로세스와 계획 수립

형상 관리 수행 및 통제 실시

기술 아키텍처 설계 및 구축, 성능 테스트 및 튜닝

소프트웨어 아키텍처 설계 및 구축, 개발 표준 수립

데이터 모델링 표준 수립, 데이터 모델 검토

테스트 관리자

테스트 계획 수립, 테스트 진행 관리

개발자

산출물 품질 검토 및 시정 조치, 제품 검사 결과

시정 조치, 테스트 수행

사용자 그룹

인수 책임자

품질 요구사항 총괄 관리 및 승인

요구사항 조정 및 변경에 대한 의사 결정

시스템 사용자

사용자 요구사항 정의, 단계별 고객 검토, 기능

완성도 검사

품질 특성

요구사항

측정 지표

측정식

측정 시기