2장 소프트웨어 프로젝트 관리

정보처리기사 필기 - 4과목 소프트웨어 공학

2장 소프트웨어 프로젝트 관리

117 프로젝트 관리의 개요

① 프로젝트 관리의 개념

· 프로젝트 관리는 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동

· 프로젝트 관리는 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등의 작업을 통제하는 것으로 소프트웨어 생명 주기의 전 과정에 걸쳐 진행됨

· 소프트웨어 프로젝트를 성공적으로 수행하기 위해서는 수행할 작업의 범위, 필요한 자원, 수행 업무, 이정표, 비용 추진 일정들을 알아야 함

※ 프로젝트 관리는 제한된 시간과 비용으로 좋은 품질의 시스템을 개발하여 고객에게 제공함

② 프로젝트 관리 대상

· 계획 관리 : 프로젝트 계획, 비용 산정, 일정 계획, 조직 계획

· 품질 관리 : 품질 통제, 품질 보증

· 위험 관리 : 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치

※ 효과적인 프로젝트 관리를 위한 3P(3대 요소)

· 사람(People) : 프로젝트 관리에서 가장 기본이 되는 인적 자원

· 문제(Problem) : 사용자 입장에서 문제를 분석하여 인식함

· 프로세스(Process) : 소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조(Framework)

③ 프로젝트 관리의 구성 단계

[그림 1] 프로젝트 관리의 구성 단계

① 프로젝트 계획 수립

· 프로젝트의 목적을 기술하고, 이를 달성하기 위해 필요한 업무와 성취해야 할 일들을 결정

· 프로젝트를 정의하고 프로젝트 일정 계획, 소요 자원 예측, 위험 평가, 프로젝트에 대한 승인 얻어냄

② 프로젝트 가동

· 프로젝트가 수행될 환경을 구성학 프로젝트에 참여할 인력을 교육시킴

· 프로젝트를 진행할 조직을 구성하고 각 팀원을 선발함

③ 프로젝트 통제

· 계획 대비 프로젝트의 척도를 점검하고, 변경 사항을 승인하는 등의 작업 수행

(척도 : 시스템, 컴포넌트(구성 요소) 또는 프로세스가 요구된 속성을 어느 정도 만족하는 가에 대한 수량적인 측정치)

· 프로젝트 전 기간 동안 수행됨

④ 프로젝트 종료

· 수행 결과의 완전성을 점검하고 프로젝트 종료 

118 프로젝트 계획 수립

① 프로젝트 계획 수립의 개요

프로젝트 계획은 프로젝트가 수행되기 전에 소프트웨어 개발 영역 결정, 필요한 자원, 비용, 일정 등을 예측하는 작업

· 관리자가 자원, 비용, 일정 등을 합리적으로 예측할 수 있도록 프로젝트 틀(Framework)를 제공

· 프로젝트 계획 수립을 통해 소프트웨어 개발 과정에서 발생할 수 있는 여러 가지 위험성을 최소화할 수 있음

· 프로젝트 계획 수립 후에는 시스템 정의서와 프로젝트 계획서가 산출됨

· 프로젝트 계획에 따라 소프트웨어의 품질이 결정되므로, 계획 단계에서 프로젝트 관리자의 임무는 매우 중요함

※ 시스템 정의서에 포함되는 내용 : 문제 기술, 시스템 정당화, 프로젝트 목표, 제약 사항, 추진 전략 등

※ 프로젝트 계획서에 포함되는 내용 : 생명 주기 모델, 기본 일정, 예산, 팀의 구성, 관리 기준, 완료 조건 등

② 시스템 개발 영역(Scope, 범위) 결정

· 프로젝트 계획 수립의 첫 번째 임무로, 개발될 소프트웨어의 영역을 결정

· 소프트웨어의 개발 영역을 결정하는 주요 요소에는 처리될 데이터와 소프트웨어에 대한 기능, 성능, 제약 조건, 인터페이스 및 신뢰도 등

※ 제약 조건 : 외부 하드웨어, 가용 메모리, 다른 시스템들에 의해 소프트웨어에 가해진 제한 사항

※ 인터페이스에 포함되는 사항

· 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 프로세서나 하드웨어

· 운영체제, 서브루틴 패키지와 같이 새로운 소프트웨어에 연결되어야 하는 소프트웨어

· 키보드나 기타 I/O 장치들을 통하여 소프트웨어를 사용하는 사람

· 순서적인 연산에 의해 소프트웨어를 실행하는 절차 

③ 자원 추산

소프트웨어 개발에 필요한 자원을 예측하는 것

인적 자원	· 소프트웨어 프로젝트에 필요한 인원수 및 조직 결정  · 소프트웨어 개발 영역을 평가하고, 개발을 수행하는 데 필요한 기술들을 선택함으로써 인적 자원 예측이 시작됨
재사용 소프트웨어 자원	재사용을 원하는 소프트웨어의 컴포넌트(구성 요소) 결정
환경 자원	소프트웨어 개발에 필요한 하드웨어와 소프트웨어 환경을 의미하는 것으로, 하드웨어와 소프트웨어가 필요한 시기 결정

④ 소프트웨어 프로젝트 추산

소프트웨어 프로젝트 추산은 프로젝트 수행에 필요한 비용을 예측하는 것으로 신뢰할 만한 비용을 예측하기 위해서 다음과 같은 방법 사용

· 프로젝트 관리의 후반가지 프로젝트 예측을 가능한 한 연기함

· 이미 수행된 유사 프로젝트 참고

· 프로젝트를 상대적으로 잘게 분리하여 예측하는 분해 기법 사용

· 하나 이상의 경험적 예측(실험) 모델을 활용

· 자동화 도구를 도입하여 활용

⑤ 프로젝트 계획 수립 시 고려사항

· 프로젝트 복잡도

· 프로젝트 규모

· 구조적 불확실성의 정도

· 과거 정보의 가용성

· 위험성

119 소프트웨어 프로젝트 추산

① 소프트웨어 프로젝트 추산의 개요

소프프웨어 프로젝트 추산은 프로젝트를 수행하는 데 필요한 소프트웨어의 직·간접적인 비용을 예측하는 작업

· 소프트웨어 공학 분야 중에서 가장 어렵고 오차 발생이 심한 작업

· 소프트웨어 개발 단계에서 확인되지 않거나 고려하지 못한 요소들이 많기 때문에 정확한 비용을 예측하기는 어려움

· 소프트웨어의 측정 요소

직접 측정 요소	노력, LOC(원시 코드 라인 수), 투입 인원, 문서수 등
간접 측정 요소	생산성, 복잡성, 효율성, 품질, 신뢰성, 유지 보수성 등

② 프로젝트 비용 결정 요소

프로젝트 요소

어떤 소프트웨어를 개발할 것인가에 따라 비용이 달라질 수 있음

· 제품의 복잡도 : 소프트웨어의 종류(응용·유틸리티·시스템 소프트웨어 등)에 따라

· 시스템의 크기 : 소프트웨어의 규모(대형·소형 소프트웨어)에 따라

· 요구되는 신뢰도 : 신뢰도는 프로그램이 일정한 기간 내에 주어진 조건하에서 필요한 기능을 수행하는 정도를 의미

자원 요소

소프트웨어 개발에 필요한 각종 자원들의 투자정도에 따라 비용이 달라질 수 있음

· 인적 자원 : 관리자, 개발자의 능력 혹은 자질

· 하드웨어 자원 : 개발 장비나 워드프로세서, 프린터와 같은 보조 장비

· 소프트웨어 자원 : 언어 분석기, 문서화 도구, 요구 분석기 등과 같은 개발 지원 도구

생산성 요소

· 개발자의 능력: 전문 분야에 대한 지식, 유사 분야에 대한 경험, 응용 분야에 대한 이해도, 책임감, 창의력 등

· 개발 기간 : 소프트웨어를 개발하는 기간

120 비용 산정 기법

① 하향식 비용 산정 기법

과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법

· 프로젝트 전체 비용을 산정한 후 각 작업별로 비용을 세분화함

· 하향식 비용 산정 기법에는 전문가 감정 기법, 델파이 기법 등이 있음

전문가 감정 기법

조직 내에 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법

· 가장 편리하고 신속하게 비용 산정 가능, 의뢰자로부터 믿음을 얻을 수 있음

· 새로운 프로젝트에는 과거의 프로젝트와 다른 요소들이 있다는 것을 간과할 수 있음

· 새로운 프로젝트와 유사한 프로젝트에 대한 경험이 없을 수 있음

· 개인적이고 주관적일 수 있음

델파이 기법

전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법

· 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성됨

· 비용 산정 순서

① 조정자는 각 비용 산정 요원에게 시스템 정의서와 산정한 비용 내역을 기록할 서식 제공

② 산정 요원들은 정의서를 분석하여 익명으로 그들 나름대로의 비용 산정

③ 조정자는 산정 요원들의 반응을 요약하여 배포함

④ 산정 요원들은 이전에 산정한 결과를 이용하여 다시 익명으로 산정

⑤ 요원들 간의 의견이 거의 일치할 때까지 이 과정을 반복

② 상향식 비용 산정 기법

상향식 비용 산정 기법은 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법

· 상향식 비용 산정 기법에는 LOC(원시 코드 라인 수) 기법, 개발 단계별 인월수 기법, 수학적 산정 기법

LOC(원시 코드 라인 수) 기법

LOC 기법은 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 작관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법

※ 비관치 : 가장 많이 측정된 코드 라인 수 / 낙관치 : 가장 적게 측정된 코드 라인 수 / 기대치 : 측정된 모든 코드 라인의 평균

· 측정이 용이하고 이해하기 쉬워 가장 많이 사용됨

· 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용 상정

예측치 = (a+4m+b)/6 (단, a:낙관치, b:비관치, c:기대치(중간치))

· 산정 공식

- 노력(인월) = 개발 기간 × 투입 인원

= LOC / 1인당 월 평균 생산 코드 라인 수

- 개발 비용 = 노력(인월) × 단위 비용(1인당 월평균 인권비)

- 개발 기간 = 노력(인월) / 투입 인원

- 생산성 = LOC / 노력(인월)

개발 단계별 인월수(Effort Per Tack)기법

· LOC 기법을 보완하기 위한 기법으로, 각 기능을 구현시키는 데 필요한 노력(인월)을 생명 주기의 각 단계별로 산정

· LOC 기법보다 더 정확함

121 수학적 산정 기법

① 수학적 산정 기법의 개요

· 수학적 산정 기법은 상향식 비용 산정 기법을 경험적 추정 모형, 실험적 추정 모형이라고도 하며, 개발 비용 산정의 자동화를 목표로 함

· 수학적 산정 기법에는 COCOMO 모형, Putnam 모형, 기능 점수(FP) 모형 등이 있으며 각 모형에서는 지정된 공식을 사용하여 비용 산정

· 비용을 자동으로 산정하기 위해 사용되는 공식은 과거 유사한 프로젝트를 기반으로하여 경험적으로 유도된 것

② COCOMO 모형 개요

COCOMO(COnstructive COst MOdel) 모형은 보헴(Boehm)이 제안한 것으로 원시 프로그램의 규모인 LOC에 의한 비용 산정 기법

· 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식(공식)에 대입하여 비용 산정

· 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용되고 있음

· 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정됨

· 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력으로 나타남

③ COCOMO의 소프트웨어 개발 유형

소프트웨어 개발 유형은 소프트웨어의 복잡도 혹은 원시 프로그램의 규모에 따라 조직형, 반분리형, 내장형으로 분류됨

· 조직형(Organic Model)

- 조직형은 기관 내부에서 개발된 중·소 규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리용으로 5만(50KDSI)라인 이하의 소프트웨어를 개발하는 유형

※ KDSI(Kilo Delivered Source Instruction) : 전체 라인 수를 1,000라인 단위로 묶은 것으로 KLOC(Kilo LOC)와 같은 의미

- 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합

- 비용 산정 공식

노력(MM) = 2.4 × (KDSI)1.05    개발기간(TDEV) = 2.5 × (MM)0.38

· 반분리형(Semi-Detached Model)

- 반분리형은 조직형과 내장형의 중간형으로 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형

- 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합

- 비용 산정 공식

노력(MM) = 3.0 × (KDSI)1.12    개발기간(TDEV) = 2.5 × (MM)0.35

· 내장형(Embedded Model)

- 내장형은 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형

- 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

- 비용 산정 공식

노력(MM) = 3.6 × (KDSI)1.20     개발기간(TDEV) = 2.5 × (MM)0.32

④ COCOMO 모형의 종류

COCOMO는 비용 산정 단계 및 적용 변수의 구체화 정도에 따라 기본, 중간, 발전형으로 구분

· 기본(Basic)형 COCOMO

기본형 COCOMO는 소프트웨어의 크기(생산 코드 라인 수)와 개발 유형만을 이용하여 비용을 산정하는 모형

- 산정 공식

▶ 개발 노력(Effort, MM, PM) = a × (KDSI)b

▶ 개발 기간(TDEV) = c × (MM)d

▶ 적정 투입 인원(FPS) = MM / TDEV

▶ 인적 비용(COST) = MM × 1인당 월평균 급여

· 중간(Intermediate)형 COCOMO

중간형 COCOMO는 기본형의 공식을 토대로 사용하나, 다음 4가지 특성의 15가지 요인에 의해 비용을 산정하는 모형

- 제품의 특성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도

- 컴퓨터의 특성 : 수행 시간의 제한, 기억장소의 제한, 가상 기계의 안정성, Turn Around Time

- 개발 요원의 특성 : 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프로그래머의 능력, 프로그래밍 언어의 경험

- 프로젝트 특성 : 소프트웨어도구의 이용, 프로젝트 개발 일정, 최신 프로그래밍 기법의 이용

- 산정 공식

▶ 개발 노력(MM) = 기본 COCOMO의 MM × 요인별 노력 승수

▶ 개발 기간(TDEV) = c × (MM)d

▶ 적정 투입 인원(FPS) = MM / TDEV

▶ 인적 비용(COST) = MM × 1인당 월평균 급여

· 발전(Detailed)형 COCOMO

발전형 COCOMO는 중간형을 보완하여 만들어진 방법으로 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형

- 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용

- 산정 공식 : 중간형 산정 공식을 그대로 사용하되, 노력 승수를 다음과 같이 적용하여 산정

노력 승수 = 개발 공정별 노력 승수 × 개발 공정별 가중치

⑤ Putnam 모형

Putnam 모형은 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해주는 모형

· Putnam이 제안한 것으로 생명 주기 예측 모형이라고도 함

· 시간에 따른 함수로 표현되는 Rayleigh - Norden 곡선의 노력 분포도를 기초로 함

· 대형 프로젝트의 노력 분포 산정에 이용되는 기법

· 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소

· 산정 공식

개발 노력(MM) = L3 / (CK3 · Td4)

(L : 원시 코드 라인 수, Td : 개발 기간, CK : 환경 상수(빈약 환경=2,000, 좋은 환경=8,000, 최적 환경=12,000))

⑥ 기능 점수(FP) 모형

· 기능 점수 모형은 Albrecht가 제안한 것으로, 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법

기능점수(FP) = 총 기능 점수 × [0.65 + (0.1 × 총 영향도)]

· 최근에 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가 받고 있음

· 기능별 가중치

소프트웨어 기능 증대 요인	가중치
	단순	보통	복잡
자료 입력(입력 양식)	3	4	6
정보 출력(출력 보고서)	4	5	7
명령어(사용자 질의수)	3	4	5
데이터 파일	7	10	15
필요한 외부 루틴과의 인터페이스	5	7	10

※ 자동화 추정 도구

· SLIM : Rayleigh - Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구

· ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

122 프로젝트 일정 계획

① 개요

프로젝트 일정 계획은 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하며, 소작업의 순서와 일정을 정하는 것

· 소프트웨어 개발 기간의 지연을 방지하고 프로젝트가 계획대로 진행되도록 일정을 계획

· 계획된 일정은 프로젝트의 진행을 관리하는 데 기초 자료가 됨

· 계획된 일정과 프로젝트의 진행도를 비교하여 차질이 있을 경우 여러 조치를 통해 조정 가능

· 프로젝트 일정 계획을 위해서는 WBS, PERT/CPM, 간트 차트 등이 사용됨

② 기본 원칙

· 분할 : 프로젝트는 관리 가능한 여러 개의 작업들로 분할되어야 함

· 상호 의존성 : 분할된 각 작업들 간에 어떤 관계가 있는지 상호 의존성이 결정되어야 함

· 시간 할당 : 각 직업에 시간을 할당해야 함

· 노력 확인 : 소프트웨어 개발에 참여할 팀원들에 맞게 시간이 할당되었는지 확인해야 함

· 책임성 : 계획된 작업은 특정 팀에게 할당되어야 함

· 정의된 산출물·이정표 : 각 작업들은 정의된 산출물과 이정표를 가지고 있어야 함

③ 사람-노력 관계와 노력 분배

사람-노력 관계

· 소규모의 개발 프로젝트에서는 한 사람이 요구사항을 분석하고 설계, 코딩, 테스트까지 수행 가능

· 프로젝트 크기가 증가할수록 더 많은 사람들이 참여해야 함

· 프로젝트 진행중에 새로운 인력을 투입할 경우 작업 적응 기간과 부작용으로 인해 일정을 더욱 지연시키고, 프로젝트에 혼란을 가져오게 됨

※ Brooks의 법칙 : 프로젝트 진행주엥 새로운 인력을 투입하면 일정이 더 지연됨

노력 분배

· 예측된 노력을 각 개발 과정에 분배할 때는 40-20-40 규칙으 권장하며, 이는 분석과 설계에 40%, 코딩에 20%, 테스트에 40%를 분배

· 일반적으로 노력은 요구 분석이 10~25%, 설계가 20~25%, 코딩이 15~25%, 테스팅과 디버깅이 30~40%를 차지함

④ WBS(Work Breakdown Structure, 업무 분류 구조)

WBS는 개발 프로젝트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조

· 일정 계획의 첫 단계에서 작업을 분할할 때 사용되는 방법

· 계획 관리 단계에서 일정 계획과 인력 계획, 비용 산정의 기준이 됨

· 프로젝트 진행중에 발생하는 모든 작업을 알 수 있음

· 제품의 계층 구조 또는 프로세스의 계층 구조로 나타냄

⑤ PERT/CPM의 개요

PERT/CPM 네트워크는 프로젝트의 지연을 방지하고 계획대로 진행되게 하기 위한 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해 자원의 제약하에 비용을 적게 사용하면서 초단시간 내 계획 완성을 위한 프로젝트 일정 방법

·  프로젝트 개발 기간을 결정하는 임계 경로를 제공(임계경로 : 하나의 제품을 개발하기 위한 여러 경로 중 제품이 완성되기까지, 가장 많은 기간을 소요하는 경로)

· 통계적 모델을 적용해서 개별 작업에 대한 가장 근접한 시간을 측정하는 기준이 됨

· 각 작업에 대한 시작 시간을 정의하여 작업들 간의 경계 시간을 계산할 수 있게 함

※ PERT와 CPM 모두 일정 관리를 위해 개발된 기법으로 PERT는 주로 소요 시간 예측이 어려운 경우, CPM은 소요 시간이 확실한 경우에 이용※ PERT/CPM 네트워크를 통해 계산될 수 있는 경계 시간들

· 모든 선행 작업들이 가능한 한 최단시간 내에 완성될 때 한 작업이 시작될 수 있는 가장 빠른 시간

· 최소의 프로젝트 완료 시간이 지연되기 전에 자업 개시를 위한 가장 늦은 시간

· 가장 빠른 완료 시간 : 가장 빠른 개시 시각과 작업 기간의 합

· 가장 늦은 완료 시간 : 가장 늦은 개시 시각과 작업 기간의 합

· 총 자유 시간 : 네트워크 임계 경로를 일정대로 유지하기 위해 작업에 허용된 잉여 시간의 양인 전체 여유 시간

⑥ PERT(Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)

PERT는 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크로 각 작업별로 낙관적인 경우, 가능성이 있는 경우, 비관적인 경우로 나누어 각 단계별 종료 시기를 결정하는 방법

· 과거에 경험이 없어서 소요 기간 예측이 어려운 소프트웨어에서 사용

· 노드와 간선으로 구성되며 원 노드에는 작업을, 간선(화살표)에는 낙관치, 기대치, 비관치를 표시

· 결정 경로, 작엄데 대한 경계 시간, 작업 간의 상호 관련성등을 알 수 있음

· 작업 예측치를 계산하는 PERT 공식

작업 예측치 = (비관치+4×기대치+낙관치/6)    평방 편차 = [(비관치-낙관치)/6]2

⑦ CPM(Criticla Path Method, 임계 경로 기법)

CPM은 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법

· CPM은 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄

· 원형 노드가 각 작업을 의미하며 각 작업 이름과 소요 기간을 표시하고, 박스 노드는 이정표를 의미하며 박스 노드 위에는 예상 완료 시간을 표시

· 간선을 나타내는 화살표의 흐름에 따라 각 작업이 진행되며, 전 작업이 완료된 후 다음 작업을 진행할 수 있음

· 각 작업의 순서와 의존 관계, 어느 작업이 동시에 수행될 수 있는지를 한눈에 볼 수 있음

· 경영층의 과학적인 의사 결정을 지원하며, 효과적인 프로젝트의 통제를 가능하게 해줌

※ CPM 네트워크를 사용한 일정 계획의 순서

① 프로젝트의 규모 추정

② 각 단계에서 필요한 작업들을 분할

③ 각 작업의 상호 의존 관계를 CPM 네트워크로 나타냄

④ 일정 계획을 간트 차트로 나타냄

⑧ 간트 차트(Gantt Chart)

간트 차트는 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로제트 일정표로, 시간선차트라고도 함

· 중간 목표 미달성시 그 이유과 기간을 예측할 수 있게 함

· 사용자와의 문제점이나 예산의 초과 지출 등도 관리 가능

· 자원 배치와 인원 계획에 유용하게 사용됨

· 다양한 형태로 변경하여 사용 가능

· 작업 경로는 표시할 수 없으며, 계획의 변화에 대한 적응성이 약함

· 계획 수립 또는 수정 때 주관적 수치에 기울어지기 쉬움

· 간트 차트는 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있음

· 수평 막대의 길이는 각 작업의 기간을 나타냄

123 프로젝트 조직 구성 계획

① 프로젝트 조직 구성 계획

· 프로젝트 조직 구성 계획은 프로젝트를 수행하기 위해 참여하는 각 구성원들의 역할을 할당하고 서로 어떤 방법을 통해 협력할 것인가를 정의하는 것

· 프로젝트를 완성하기 위해서는 프로젝트 단위로 팀을 구성하여 수행함

· 프로젝트 수행 기간, 작업의 특성, 팀 구성원 사이의 의사 교류 횟수에 의해팀 구성 방법이 달라질 수 있음

· 프로젝트 팀 구성은 의사 결정권이 누구에게 있느냐에 따라 분산형 팀 구성, 중앙 집중형 팀 구성, 계층적 팀 구성으로 나눌 수 있음

② 분산형 팀 구성

분산형 팀 구성은 팀원 모두가 의사 결정에 참여하는 비이기적인 구성 방식으로, 민주주의식 팀 구성이라고도 함

· 의사 결정을 민주주의식으로 하여 팀 구성원의 참여도와 작업 만족도를 높이고 이직률을 낮게 함

· 팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대하여 같은 그룹의 일원으로서 책임을 짐

· 여러 사람이 의사를 교류하므로 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트 개발에 적합

· 링 모양의 구조를 가지며 이는 모든 구성원이 동등한 레벨에 있음을 보여줌

· 팀 구성 방법 중 가장 많은 의사 소통 경로를 갖는 구조

의사 소통 경로의 수 = n(n-1)/2

· 다양한 의사 교류오 인해 의사 결정 시간이 늦어지고, 개개인의 생산성 및 책임감이 낮아질 수 있음

③ 중앙 집중형 팀 구성

중앙 집중형 팀 구성은 한 관리자가 의사 결정을 하고 팀 구성원들은 그 결정에 따르는 구성 방식으로, 책임 프로그래머 팀 구성이라고 함

· 프로젝트 수행에 따른 모든 권한과 책임을 한 명의 관리자(책임(고급) 프로그래머)에게 위임하고, 기술 및 관리 지원을 위해 인력을 투입하는 형태

· 책임 프로그래머에 따라 의사 결정이 이루어지기 때문에 의사 결정이 빠르고, 의사 교환 경로를 줄일 수 있음

· 한 사람에 의해 통제할 수 있는 비교적 소규모 프로젝트에 적합

· 프로젝트의 성공은 책임 프로그래머의 능력에 달려 있음

· 중앙 집중형 팀 구성에서 각 구성원의 역할

구성원	역할
책임(고급) 프로그래머	요구 분석 및 설계, 중요한 기술적 판단, 프로그래머에게 작업 지시 및 배분 등
프로그래머	책임 프로그래머의 지시에 따른 원시 코드 작성, 테스트, 디버깅, 문서 작성 등
프로그램 사서	프로그램 리스트, 설계 문서, 테스트 계획 등을 관리
보조 프로그래머	책임 프로그래머의 업무 지원, 여러 가지 기술적인 문제에 대한 자문, 사용자와 품질 보증 담당자 등의 섭외, 책임 프로그래머 감독하에 분석, 설계, 구현 담당

④ 계층적 팀 구성

계층적 팀 구성은 분산형 팀 구성과 중앙 집중형 팀 구성을 혼합한 형태로, 혼합형 팀 구성이라고 함

· 5~7명의 초급 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리하게 함

· 경험자와 초보자를 구별함

· 프로젝트 리더와 고급 프로그래머에게 지휘 권한을 부여하고, 의사 교환은 초급 프로그래머와 고급 프로그래머로 분산함

· 기술 인력이 관리를 담당하게 되어 좋은 기술력을 사장시킬 수 있으며, 기술 인력이 업무 관리 능력을 갖춰야 한다는 단점이 있음

124 소프트웨어 품질 보증

① 소프트웨어 품질과 품질 관리

· 소프트웨어 품질(Quality) : 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측적 가능한 기능 및 특성을 의미

설계 품질	설계자가 한 품목을 위해 규정한 특성
일치 품질	설계 내용이 개발 과정에서 지켜지는 정도

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

② 품질 표준(목표)

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

구분	품질 표준	의미
소프트웨어 운영 특성	정확성	사용자의 요구 기능을 충족시키는 정도
	신뢰성	정확하고 일관된 결과를 얻기 위해 요구된 기능을 오류 없이 수행하는 정도
	효율성	요구되는 기능을 수행하기 위한 필요한 자원의 소요 정도로, 소프트웨어가 자원을 쓸데없이 낭비하지 않아야 함
	무결성	허용되지 않는 사용이나 자료의 변경을 제어하는 정도
	사용 용이성	사용에 필요한 노력을 최소화하고 쉽게 사용할 수 있는 정도로, 소프트웨어는 적절한 사용자 인터페이스와 문서를 가지고 있어야 함
소프트웨어 변경 수용 능력	유지보수성	변경 및 오류 사항의 교정에 대한 노력을 최소화하는 정도로, 사용자의 기능 변경의 필요성을 만족하기 위하여 소프트웨어를 진화하는 것이 가능해야 함
	유연성	소프트웨어를 얼마만큼 쉽게 수정할 수 있는가 하는 정도
	시험 역량	의도된 기능이 수행되도록 보장하기 위해 프로그램을 시험할 수 있는 정도
소프트웨어 적응 능력	이식성	다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
	재사용성	전체나 일부 소프트웨어를 다른 목적으로 사용할 수 있는가 하는 정도
	상호 운용성	다른 소프트웨어와 정보를 교환할 수 있는 정도

③ 소프트웨어 품질 보증(SQA; Software Quality Assurance)

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

· 소프트웨어 품질 보증 활동은 소프트웨어 개발 초기에 소프트웨어의 특성과 요구사항을 철저히 파악하여 품질 목표를 설정하고, 개발 단계에서는 정형 기술 검토를 통하여 품질 목표의 충족 여부를 점검하며, 개발 후에는 디버깅과 시험 과정을 거침

 

④ 정형 기술 검토의 개요(FTR; Formal Technicla Review)

· 정형 기술 검토는 가장 일반적인 검토 방법으로 소프트웨어 기술자들에 의해 수행되는 소프트웨어 품질 보증 활동

· 정형 기술 검토 유형에는 검토 회의, 겸열 등이 있으며 이는 모두 회의 형태로 수행됨

목적

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

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

· 소프트웨어가 균일한 방식으로 개발되도록

· 프로젝트를 보다 용이하게 관리하도록

⑤ 정형 기술 검토의 지침 사항

· 제품의 검토에만 집중

· 의제를 제한하여 진행

· 논쟁과 반박을 제한

· 문제 영역을 명확히 표현

· 해결책이나 개선책에 대해서는 논하지 말라

· 참가자의 수를 제한하고 사전 준비를 강요

· 검토될 확률이 있는 각 제품에 대한 체크 리스트를 개발

· 자원과 시간 일정을 할당

· 모든 검토자들을 위해 의미있는 훈련을 행하라

· 검토자들은 사전에 작성한 메모를 공유

· 검토의 과정과 결과를 재검토

⑥ 정형 기술 검토 유형

검토 회의(Walkthrough)

· 소프트웨어 개발의 각 단계에서는 개척하는 기술 평가 회의로, 소프트웨어 구성 요소와 같은 작은 단위를 검토하는 것

· 오류의 조기 검출을 목적으로 하며 발견된 오류는 문서화

· 검출된 오류는 검토 회의 기간 동안에 해결하지 않고 미뤄 두었다가 검토 회의 후에 해결

· 3~5명이 검토에 참여해야 하며 검토 회의 시간은 두 시간 이내로 해야 함

· 검토를 위한 자료를 미리 배포하여 검토하도록 하며, 미리 검토하는 시간은 2시간 이내

검열(Inspections, 심사)

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

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

125 소프트웨어의 신뢰성과 가용성

① 소프트웨어의 신뢰성과 가용성

· 신뢰성 : 프로그램이 주어진 환경에서 주어진 시간 동안 오류 없이 작동활 확률

· 소프트웨어의 품질을 평가하는 다른 품질 표준과는 달리 과거의 자료와 개발상의 자료를 이용하여 측정과 예측 가능

· 하드웨어 신뢰성 측정의 기본 이론을 근거로 측정

· 가용성(신뢰도)는 한 프로그램이 주어진 시점에서 요구사항에 따라 운영되는 확률

② 신뢰성과 가용성 측정

· 소프트웨어의 간단한 신뢰성 측정은 MRBF 이용

· 가용성(신뢰도) 측정 : 시스템의 총 운용 시간 중 정상적으로 가동된 시간의 비율

126 위험 관리

① 위럼 관리(Risk Analysis)

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

· 위험은 불확실성과 손실을 내재하고 있는데, 위험 관리는 이러한 위험의 불확실성을 감소시키고 손실에 대비하는 작업

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

· 취험 관리의 절차는 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치 순

② 위험의 범주

· 프로젝트 위험 : 프로젝트 계획을 위협하는 것으로, 일정이 지연되고 비용이 증가

· 기술 위험 : 소프트웨어의 품질이나 시기를 위협하는 것으로, 구현이 어려워지거나 불가능하게 됨

· 비즈니스 위험 : 소프트웨어의 생존 가능성을 위협하는 것으로, 원치 않는 제품이나 전략에 맞지 않는 제품 등을 개발

③ 위험의 종류

· 소프트웨어 개발 시 일반적인 위험 요소에는 인력 부족, 예산 관리, 일정 관리, 사용자 요구사항 변경등이 있으며, 이중 가장 대표적인 위험 요소는 사용자 요구사항 변경

위험의 종류(Charette에 의해 제안)

· 알려진 위험 : 프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견될 수 있는 위험

· 예측 가능한 위험 : 과거 경험으로부터 예측할 수 있는 위험

· 예측 불가능한 위험 : 사전 예측이 매우 어려운 위험

④ 위험 식별(Risk Identification)

알려지거나 예측 가능한 위험 요소를 파악하는 작업으로, 위험 항목 점검 목록을 작성하여 활용

⑤ 위험 분석 및 평가

· 위험 분석은 프로젝트에 내재한 위험 요소를 인식하고 그 영향을 분석하는 활동으로, 위험 추산 작업을 통해 수행됨

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

· 위험 요소에 대해 효과적이지 못한 관리는 프로젝트를 실패하는 결과도 가져올 수 있음

· 위험 추산을 위해 위험표를 작성하여 활용 

⑥ 위험 관리 계획

위험을 예방하고 위험 발생 시 대책을 준비하여 문서화하는 작업

⑦ 위험 감시 및 조치

위험 내용을 항상 감시하고 실제 발생 시 조치하는 것으로 다음과 같은 전략 사용

· 위험 회피 : 위험 관리에 대한 최상의 전략으로 위험이 발생될 것을 예상하고 회피하는 것

· 위험 감시 : 위험 요소 징후들에 대하여 계속적으로 인지하는 것

· 위험 관리 및 비상 계획 수립 : 위험 회피 전략이 실패할 경우 위험에 대해 관리하고 대비책과 비상 계획을 세움

127 소프트웨어 형상 관리

① 형상 관리

형상 관리(SCM; Software Configuration Management)는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동

· 소프트웨어 변경의 원인을 아아내고 제어하며 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보하는 작업

· 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동으로, 유지보수 단계에서도 수행됨

· 형상 관리는 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 함

② 소프트웨어 형상 항목(SCI; Software Configuration Item)

· 시스템 명세서

· 소프트웨어 프로젝트 계획서

· 소프트웨어 요구사항 명세와 실행 가능한 프로토타입

· 예비 사용자 매뉴얼

· 설계 명세서

· 원시 코드 목록

· 테스트 계획, 절차, 시험 사례, 결과

· 운영과 설피에 필요한 매뉴얼

· 실행 프로그램

· 데이터베이스 기술서 : 스키마, 파일 구조, 초기 내용

· 구축된 사용자 매뉴얼

· 유지 보수 문서 : 변경 요청서, 변경 처리 보고서

· 소프트웨어 공학을 위한 표준과 절차

③ 형상 관리 기능

· 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업

· 버전 제어 : 소프트웨어 처리 시 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구를 결합시키는 작업

· 변경 제어 : 식별된 형상 항목의 변경 요구를 검토하여 현재의 기준선이 잘 반영될 수 있도록 조정하는 작업

· 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업

· 형상 상태 보고 : 형상의 식별, 통제, 감사 자업의 결과를 기록·관리하고 보고서를 작성하는 작업

출처 : 2017 시나공 정보처리기사 필기