chap. 4 소프트웨어 관리 -...

Software Engineering

Ⓒ2014 SELAB

Chap. 4 소프트웨어 관리

2014 Software Engineering Chapter 4. 임베디드 소프트웨어 관리

2

목 차

• 소프트웨어 관리

• 소프트웨어 일정 관리

• 소프트웨어 예산 관리

• 계획서 작성


3

4.1 소프트웨어 관리(1)

• 소프트웨어 관리

– 프로젝트 개발 계획을 책임지며 주어진 시간과 예산안에

요구사항대로 결과가 나올 수 있도록 관리하는 것

• 관리 대상

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

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

– 위험 관리: 위험 식별, 위험 투영(추정), 위험 평가, 위험 관리


4

4.1 소프트웨어 관리(2)

• 프로젝트 관리를 위한 핵심적 관리대상(3P)

– 사람(People) : 인적 자원

• 선임 매니저, 프로젝트 매니저, 실무자, 최종 사용자

– 프로세스(Process) : 작업 계획

• 소프트웨어 개발에 필요한 기본 골격을 제공

– 문제 (Problem) : 문제 인식

• 프로젝트를 시작하기 전에 처리해야 될 문제를 분석하고, 기술과 관리상의 제약사항이

식별되어야 함

• 문제를 분석할 때 소프트웨어 범위를 결정하는데, 이때 내용, 정보 목적, 기능과 성능

그리고 제약 조건 등을 고려함

• 소프트웨어 관리가 어려운 이유

– 생산물이 무형

– s/w 개발 과정에 대한 확실한 이해가 어려움

– 대형 소프트웨어 시스템은 “one-off” 프로젝트 경향


5

진행 상황 관찰, 비용과 진행과정

의 차이 비교

일정 계획, 문제점 예측, 해결책 준비

프로젝트 수행에 필요한

예산 규모 예측

관리 활동

• 각 프로젝트에 공통적으로 포함되는 관리 활동

제안서 작성

프로젝트 비용 산정

프로젝트 계획과 스케줄링

프로젝트 감독과 검토

프로젝트 조직 구성

보고서 작성과 발표

프로젝트 내용, 비용,

추진 일정, 타당성 등

프로젝트 수행에 필요한

인적 요소의 조직 구성

프로젝트 상황에

관해 보고할 책임


6

프로젝트 계획 및 예측(1)

• 소프트웨어 개발 및 관리 활동을 효과적으로 수행하기 위해

– 먼저 개발 목표와 실시 과정에 대한 계획을 수립한 후 수립된 계획에

따라 개발 및 관리 활동을 통제

• 프로젝트 계획

– 프로젝트가 실행되기 전에 필요한 자원, 비용, 일정, 성능 등을 예측하는

작업

– 신뢰성 있게 예측하는 방법

• 이미 수행된 유사 프로젝트 참조

• 프로젝트를 작은 단위로 분리하여 예측

• 경험적 예측 모델을 활용


7


• 프로젝트 계획을 수립하는 목적

– 프로젝트에 필요한 정보를 모아서 합리적인 추정이 가능

– 목표, 요구사항, 제약사항 등을 분명하게 할 수 있음

– 관리자가 필요 자원, 비용, 일정 등을 합리적으로 예측 가능

– 소프트웨어 개발 과정에 잠재된 위험성을 최소화 할 수 있음

• 프로젝트 계획 수립 시 가장 먼저 고려해야 하는 요소

– 프로젝트의 규모 파악

– 과거 정보의 이용 가능성

– 위험성(Risk)

– 구조적 불확실성의 정도 등

개발 공정과 제품 생산에 대한 계획을

신중히 세우지 않으면, 개발 과정 중

제품 비용 증가, 품질 저하 등이

일어날 수 있음


8


• 프로젝트 계획 수립 단계

– 문제 정의

• 소프트웨어 개발 영역 결정(소프트웨어의 기능, 성능, 신뢰도 등)

– 추진 전략 수립

– 개발 계획 수립

• 계획 수립 후의 산출물

– 시스템 정의서, 프로젝트 계획서


9

관리 구조 - 계층형 팀(1)

• 계층형 팀(Hierarchy Teams) = 혼합형 팀

– 프로젝트 책임자가 여러명의 프로그래머를 목적에 맞게 작은

그룹으로 나누고, 각 그룹마다 중간 관리자를 두는 계층형 관리

방식


관리 구조 - 계층형 팀(2)

– 특징

• 책임 프로그래머 팀과 민주적 팀의 중간 형태

• 5~7명의 중급 프로그래머를 작은 그룹으로 만들어 고급 프로그래머가

관리하게 만들고 모든 그룹을 프로젝트 리더가 관리하도록 하는 기법

• 초보자와 경험자를 분리하여 경험자는 초보자에게 작업을 지시하고,

초보자는 지시에 따라 작업을 하고 경험자에게 보고하는 형식으로

대규모 프로젝트에 적합

• 모든 구성원들은 상하 좌우 구성원들과 유기적인 관계를 가짐

• 가장 우수한 프로그래머가 관리자로 승진할 경우 2중의 부정적 효과가

발생

– 유능한 프로그래머가 반드시 유능한 관리자는 아님

– 오히려 숙련된 프로그래머만 잃어버리는 결과를 가져올 수 있음

10


11

관리 구조 - 책임 프로그래머 팀(1)

• 책임 프로그래머 팀(Chief programmer team) = 중앙 집중형 팀

– 책임 프로그래머가 요구분석 및 설계, 중요 부분의 프로그래밍 및

기술적 판단을 담당하는 중앙 집중형 관리 방법

프로그래머

프로젝트 행정관

도구장

문서 편집장

언어/시스템 전문가

테스터

책임

프로그래머

백업

프로그래머

라이브러리안 외부

communication

전문가들



– 특징

• 한 사람에 의하여 통제할 수 있는 비교적 작은 규모의 소프트웨어

개발에 적합

• 책임 프로그래머의 능력에 따라 의사결정이 이루어지는 팀 구성

– 의사결정 경로가 줄어 개발 과정이 신속

– 초보 프로그래머의 훈련을 위한 좋은 조직

– 책임프로그래머의 개인 능력에 크게 의존하는 팀 구성 방식

• 책임 프로그래머의 기술적, 관리적 능력에 민감

12



– 팀 구성원

• 책임 프로그래머(Chief Programmer)

– 프로젝트 계획, 요구분석과 설계, 중요한 부분의 프로그래밍 등

모든 기술적 판단을 내림

– 경험이 많고 필요한 자격 요건을 갖춘 사람

• 프로그래머(Application programmer)

– 책임 프로그래머 지시에 따른 원시코드 작성, 테스트, 디버깅,

문서 작성 등을 담당

• 라이브러리안(Librarian, 프로그램 사서)

– 프로그램 리스트, 설계 문서, 테스트 계획 등을 관리

– 프로젝트와 관련된 모든 사무적인 기능을 담당

• 백업 프로그래머(Backup programmer)

– 여러 기술적인 문제에 대한 자문 등의 책임 프로그래머의 업무

지원

13


14

관리 구조 – 민주적 팀

• 민주적 팀(Democratic Teams) = 분산형 팀

– 목표 설정과 의사 결정은 팀원 모두의 의견을 따르며, 개개인의

의사를 최대한 존중하는 분산형 관리 방법

– 특징

• 각 요원이 의사 결정에 자유롭게 참여할 수 있으며, 구성원 모두가

동등한 책임과 권한을 가짐

• 팀 구성 방법 들 중 가장 많은 의사소통 경로를 가짐

• 복잡한 장기 프로젝트에 적합

– 팀 구성원의 작업 만족도를 높이고 이직률을 낮게 하며,

팀 구성원 사이의 의사 교류를 활성화시키므로

• 대규모 프로젝트에는 부적합

– 불필요한 의사 교환으로 의사결정 시간이 지연

– 프로젝트를 이끌 책임자의 부재로 인해

개인의 책임, 권한을 약화시킴


15

관리 구조 – SWAT 팀

• SWAT 팀(Skilled With Advanced Tools Teams)

– SWAT는 Skilled With Advanced Tools를 의미

• 특정 도구나 경험에 매우 능숙한 사람들을 모아서 그 도구나

경험으로 문제를 해결하는 것

– 특징

• RAD(Rapid Application Development)와 같이 점진적 소프트웨어

개발 방식을 갖는 프로젝트에서 이용

• 주로 4, 5명으로 구성되는 소규모의 팀

• 대화채널은 매우 단순하며 형식적

• 절차적인 회의 보다는 서로 일상생활에서처럼 한 사무실에서 대화

• 브레인스토밍(brain storming)과 같은 형식으로 대화

• SWAT 리더는 관리자이며 개발자


16

프로그래머 생산성(1)

• 프로그래머 생산성 평가 이유

– 생산성 평가 없이 프로젝트 스케줄링(일정)이 불가능

– 개선된 소프트웨어 공학의 실제적이고 관리적인 기법의 몇 가지 장점은 생명주기 전 과정에 걸쳐서 실제 사용하여 생산성이 향상되었다는 결과를 보여줌으로써 증명될 수 있으므로

– 소프트웨어는 무형이기 때문에 직접적으로 생산성을 측정할 수 없으므로, 실제 평가 대상은 개발비용임

• 프로그래머 생산성 측정 방법

– Code line/Month ⇒ 가장 일반적인 방법

– Object Instruction/Month

– Page/Month

– Test case/Month



• Code line/Month : 한 달간 프로그래머가 작성한 코드의 라인 – 프로젝트를 완성하기 위해 필요한 소스코드의 전체 라인 수를 한 달간

프로그래머가 사용한 전체 시간으로 나눈 것으로 계산됨

– 분석, 설계, 코딩, 테스팅, 문서화의 시간이 모두 포함

– 문제점

• Jones 문제 제시

– “코드의 라인이 무엇을 의미하는지를 정확히 결정할 수 없다.”

» 프로그램은 선언문, 실행문, 주석문으로 이루어졌고, 코드의 라인을 확장하는 매크로 명령어도 포함

– 코드 라인에 대해 서로 다르게 정의

» 실행문만 간주하는 경우, 실행문과 선언문만 간주하는 경우, 문장의 종류에 상관없이 빈 라인만 제외한 모든 라인을 간주하는 경우

– 이러한 경우, 프로그램 생산성에 대한 공정한 측정 방법이 쉽게 비교될 수 없음

17

코딩은 전체개발 시간에 비해 상대적으로 작음


18


• 고 수준 언어와 저 수준 언어의 개발시간

– 저급언어 프로그램은 고급언어 프로그램보다 라인수가 많음 => 고급

언어를 사용하는 프로그래머보다 저급언어를 사용하는 프로그래머가

생산성이 더 높게 나타남

– 코딩 시간이 프로젝트를 수행하는 데 필요한 시간의 절반보다도 훨씬

적음에도 불구하고 생산성이 코딩 단계에 의해 좌우되는 것은 모순



• 예) 어셈블리 언어 5,000라인 vs 고급언어 1,500라인

• 수량이나 시간으로 표현되는 모든 생산성 측정 방법의 문제점

– 완성된 시스템의 품질을 고려하지 않음

• 코드 생산성 향상이 시스템 유지보수 비용을 감소시키지 않는다는 것을 의미

– 소프트웨어 개발 기간 중 코딩에 소요되는 시간은 일부

– 프로그래밍 언어의 수준에 따라 생산성의 차이가 큼

19

어셈블리 언어 고수준 언어

분석 3주 3주

설계 5주 5주

코딩 8주 4주

테스팅 10주 6주

크기 5,000라인 1,500라인

노력 28주 20주

생산성 714/월 300/월


20


• 생산성에 영향을 주는 요소

– 사용자 인터페이스의 복잡성

– 요구사항 정의 시 사용자의 참여 여부

– 팀의 전체적인 경험 정도

– 프로그래머가 실제 프로그램 개발에 사용한 총 시간


4.2 소프트웨어 일정 계획(1)

• 프로젝트 일정 계획

– 프로젝트 일정 계획은 소프트웨어 관리자가 필요로 하는 일

– 소 작업 중에서 병행처리가 가능할 수 있도록 작업과 일정계획들

사이의 상호 종속 관계를 고려

– CPM(Critical Path Method) 기법을 사용하여 소 작업 사이의

상관관계를 고려하여 프로젝트의 총 소요 시간을 계산

– 일정을 예측할 때 관리자는 프로젝트의 모든 단계에서 문제가

없다고는 가정하지 않음

• 잠재적인 문제나 애로점들을 예견하고, 우발적인 연산을 준비하기

위하여 -> 이정표, 재검토, 개발노력의 진전을 정확히 반영하는

명세화 작업을 시도

21


22


• 프로젝트 이정표(Project Milestones) – 프로젝트 개발 과정 중 구분된 단계의 끝을 의미

– 해당 작업의 완료 확인 후 다음 단계로 진행

– 상급자에게 작업 완료에 따른 보고서 제시

– 예)

• 잘된 이정표 예 : “상위 설계 완료”, “테스트 계획 형식화”

• 잘못된 이정표 : “코딩 80%완료” -> 정확한 의미 파악 X

– 생명주기의 보고서 작성 이정표


23


• 일정 계획(Scheduling)

– 개발 프로젝트의 프로세스를 이루는 소작업들을 파악해 내고

그 순서와 일정을 정하는 것

• 소프트웨어 개발 기간이 지연되는 것을 예방하고 프로젝트가 계획된

순서대로 진행되도록 일정을 계획

– 소 작업 사이의 상관 관계(한 작업의 종료 후 시작 가능한

작업)들을 고려하여 프로젝트에 걸리는 총 기간 산출

– 일정 계획을 표현하는 도구 : WBS, PERT/CPM, Gantt Chart 등

– 일정 계획서 : 프로젝트 진행을 관리하는 기초 자료



• 일정 계획 수립 순서

① 소프트웨어 개발모형을 결정하고 각 단계에 필요한 작업을

분해하여 WBS(Work Breakdown Structure)로 표현

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

③ CPM 네트워크에 각 작업 소요 기간을 정하고 프로젝트 완료에

필요한 최소기간을 산출

④ 프로젝트의 규모 산출 방법(예:COCOMO 모형)을 사용하여

소요되는 MM(Man-Month)를 구하고, 이것을 기초로 기간을

산출하여 CPM 네트워크와 비교한 후 수정

⑤ 확정된 결과를 간트 차트(Gannt chart)로 작성

24


25


• WBS(Work Breakdown Structure : 작업 분류 구조)

– 프로젝트 전체 작업을 여러 개의 작은 관리 단위인 소 작업으로 분할하여

계층적으로 기술한 업무 구조

– 특징

• 하향식(Top-down)계층 구조로 나타낼 수 있음

• 큰 단위의 일을 소단위의 일로 분해하기 위한

도구로 사용

• 관리 가능한 규모의 소 작업은 업무 지시를 위한

단위가 됨

• 간단한 전체적인 프로젝트의 윤곽을 보여주며

간트 차트에서 활동(activity)이나 작업의 기준이 됨

• WBS에서 프로젝트 관리자는 소 작업에 대한 작업

소요 일을 측정해야 함



• 프로젝트를 효율적으로 진행하기 위한 일정 계획을 수립하는 기술

– PERT(Program Evaluation and Review Technique : 프로그램 평가와 검토

기술)

– CPM(Critical Path Method : 임계 경로 방법)

• PERT (Program Evaluation and Review Technique : 프로그램

평가와 검토 기술)

– 프로젝트에 필요한 전체 작업의 상호 관계를 나타내는 네트워크

• 프로젝트의 작업들과 작업들 사이의 관계를 그래프로 표현

– 각 작업의 불확실성을 고려하여 낙관적일 때, 가능성이 있을 때, 비관적일

때로 나누어 각 단계별로 종료시기를 결정하는 방법

– 작업들이 계획되기 전에 작업들 사이의 의존관계를 보여주기 위해 개발

26



• CPM (Critical Path Method : 임계 경로 방법)

– 경비(예산)와 개발 일정(기간)을 최적화 하려는 일정 계획 방법

• 시간과 비용을 고려해서 최적화하는 방법 즉, 최소의 비용으로 최대의 효과를 위한

방법

– 특징

• 임계 경로(Critical Path) : CPM 네트워크에서 가장 긴 경로, 프로젝트 진행에

필요한 총 기간

• 프로젝트 최단 완료시간을 구하는데 사용

• 프로젝트에 대한 업무를 네트워크로 구성하여 프로젝트 시작부터 끝까지 수행해야

할 업무들에 대해 그림이나 표 형태로 표현하는 네트워크(CPM Network)를

이용하여 주요 핵심 경로(최장 경로)를 측정하는 도표

• 작업들 사이의 병행작업을 계획할 수 있으며, 프로젝트 종료 시점 추정에 유리

• WBS를 구성하고 있는 관리 단위들의 상호 의존성을 분석하여 각 공정 간의 선행

관계와 작업의 소요기간을 나타내는 프로젝트 네트워크

• 각 작업에 필요한 가장 근접한 시간을 예측하는 것으로 정확한 시간 측정은 어려움

27



• 간트 차트(Gantt Chart )

– 프로젝트 작업을 수평적으로 일정에 따라 표현해주는 일정표

– 특징

• 개발 과정 전 단계를 한눈에 파악할 수 있음

• 작업의 병행 처리 과정을 인식시켜 줌

• 프로젝트의 각 공정들이 언제 시작하고 종료되는지를 막대 도표로 표시

• 각 단계별로 진행 사항을 알 수 있도록 표시한 프로젝트 일정 계획 및

이정표로 생명주기 단계, 일정 계획(작업 일정), 이정표, 작업 기간 등이

포함

• 프로젝트에 대한 작업 일정을 보여주는 것이지 작업을 발견해 내는 데

도움을 주지는 못함

• CPM 네트워크 : 작업이 적시에 진행되는지를 점검하는데 사용

• 간트 차트 : 자원의 활용 및 인원 배치에 도움을 줌

28


29


10일

< 소 작업 리스트>

< CPM 네트워크>

T5,


30


가능 경로 기간(일)

시작-T1-M1-T3-M4-T9-M6-T11-M8-T12-완료 55

시작-T1-M3-T6-M4-T9-M6-T11-M8-T12-완료 45

시작-T1-M1-T7-M7-T10-완료 43

시작-T2-M3-T6-M4-T9-M6-T11-M8-T12-완료 52

시작-T2-M2-T5-M7-T10-완료 40

시작-T4-M2-T5-M7-T10-완료 35

시작-T4-M5-T8-완료 35

– 임계 경로(critical path)

: T1-M1-T3-M4-T9-M6-T11-M8-T12 (55일)


31


< 간트 차트>


32


< 프로그래머/태스크 할당>

< 스텝 할당 도표>


33

4.2 소프트웨어 일정 계획(13) - 문제

1. 이 프로젝트의 일정계획을 위한 CPM 네트워크를 그리시오.

2. 임계 경로(Critical Path)를 찾고 최소 완료시간을 계산하시오.


34

4.3 소프트웨어 예산 계획(1)

• 소프트웨어 예산 계획

– 프로젝트 수행에 필요한 예산의 규모를 예측하는 작업

• 소프트웨어 계획 단계에서 정확한 비용 예측

– 알려지지 않은 요소가 산재 ⇒ 매우 어려움

– 계약을 위해서 뿐만 아니라 프로젝트의 scheduling을

위해서도 필수적

– 소프트웨어 생명주기를 통해 계속적인 통제와 조정이 필요


35




• Boehm(1981)에 의해 제시된 소프트웨어 비용 산정 방법

– 알고리즘 모델(algorithmic cost modeling) :

• 특정한 소프트웨어 척도와 프로젝트 비용과 과거의 정보를 바탕으로 개발된 모델

• 소프트웨어 개발 비용에 영향을 미치는 중요한 변수를 한 개 또는 여러 개의 수식에 대입하여

비용 추정하는 방법

– 전문가의 판단(expert judgment) : 전문가의 판단에 의한 소프트웨어 비용 산정

– 유추에 의한 산정(estimation by analogy) : 기존에 작업했던 프로젝트를 유추해서 프로젝트

비용 산정

– 파킨슨의 법칙(Parkinson's law) : 작업은 가능한 시간 내에서는 계속되고 비용이 있으면 다

쓰게 된다는 의미

– 능력별 지급(pricing to win) : 프로젝트에 대해 지불할 수 있는 비용 그 자체로 산정, 실제

상황에 가장 공통적인 비용 산정 방법

– 하향식 산정(top-down estimation) : 제품의 전체적인 특성을 고려하여 결정되고 이 비용은

각 구성 부분에 할당

– 상향식 산정 (bottom-up estimation) : 각 구성의 비용이 산정되고, 이 비용이 전부 더해져

최종적인 비용이 산출

36



• 비용 결정 요소

– 소프트웨어 제품의 비용에 영향을 미치는 요소

• 프로젝트 자체 요소, 자원 요소, 생산성 요소

1) 프로젝트 자체 요소(project factors)

• 무엇을 개발해야 하는가에 따라 소요경비는 크게 좌우되고, 문제의

복잡도(complexity), 시스템의 크기(size), 요구되는

신뢰도(reliability) 등

– 예) 소프트웨어 복잡도와 개발 비용

37



2) 자원요소 (resource factors)

• 개발에 필요한 각종 자원들의 투자 정도에 따라 개발비용은 크게 달라질

수 있음

• 자원의 종류 : 인적자원, 하드웨어 자원, 소프트웨어 자원

3) 생산성 요소 (productivity factors)

• 프로젝트에 대한 자원의 투자가 어떠한 결과를 나타내느냐는 것이

생산성을 의미

• 소프트웨어 생산성은 MM(Man-Month) 당 제작되는 평균 원시코드

라인수로 정의

• 이를 결정하는 요소들은 개발자의 능력, 경험 및 주어진 개발기간 등

다양함

38


소프트웨어 비용 산출 방법(1)

1. 하향식 산정 방법

– 전체 시스템 차원에서 비용을 산정하고 서브 모델의 비용을 산정하는 방법

– 일반적으로 가장 많이 사용되는 방법이며, 경험과 전문지식이 많은

개발자들이 참여한 회의에서 토론을 통하여 산정(과거 유사한 프로젝트

비용을 검사함으로써 추정)

1) 전문가의 판단(expert judgment)

• 소프트웨어 개발 기술에 관한 경험이 많은 전문가의 판단에 따라 비용을 산출하는

방법

– 경험과 지식을 갖춘 2명 이상의 전문가에게 의뢰

• 장점 : 간편함, 신뢰감을 줌

• 단점 : 낙관적, 비과학적(기술적 요인을 간과하기 쉬움), 객관성 부여의

어려움(개인적 차이가 큼)

– 사소한 문제로 인한 결정이나 그룹 내의 한 사람에 의한 독단으로 가면 문제가 발생

39



2) 델파이(Delphi)식 산정 방법

• 회의의 부작용을 방지하면서 전문가의 의견 일치를 얻기 위하여 1948년

랜드사(Rand Co.)에서 개발

• 전문가의 판단 방법의 단점을 보완한 방법

• 전문가들이 편견이나 분위기에 지배 받지 않도록 조정자(coordinator)를 필요로 함

• 델파이식 비용 산정 방법의 진행과정

① 조정자가 시스템 정의서와 비용 산출 양식을 전문가들에게 제공

② 조정자는 전문가들이 비용 산출에 관한 토의를 위한 회의를 소집

③ 전문가들은 익명으로 각자의 산정 작업을 완료

④ 조정자는 그룹 산정과 개인 산정에 관한 내용을 요약하여 제시

⑤ 조정자는 산정내용의 차이가 많을 때, 그 문제에 초점을 맞추어 회의를 소집

⑥ 전문가들은 다시 익명으로 산정 작업을 실시

– 의견의 일치를 이룰 때까지 이 과정을 반복

40



2. 상향식 산정 방법

– 서브 시스템의 개발비를 산정한 후에 합산하여 전체 시스템의

비용을 산정하는 방법

– 하향식 방법의 비과학성을 보완

– 개발할 시스템을 작업분류구조(WBS)로 정의하고, 각 구성요소에

대한 산정을 독립적으로 실시한 후 이를 합산하는 방식

• 프로젝트를 위한 소 작업에 소요되는 기간을 구하고, 여기에

투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건비를

계산

41



1) 원시코드 라인 수(line of code) 기법

• WBS상에서 분해된 시스템의 기능들을 각각 필요한 원시코드 라인수로 산정함

• 가장 효율적인 방안은, 프로젝트 관리 목적으로 대두된 PERT(project evaluation

and review technique)의 예측공식을 이용하는 것

– 확률론에서 배타분포도에 근거하여 낙관치, 기대치 및 비관치의 확률적 집합으로

예측치와 이의 편방편차를 산출

2) 개발단계별 노력산정 기법

• 시스템의 각 기능의 구현에 필요한 노력을 각 생명주기의 단계별로 산정하여

원시코드 라인 수 기법보다 더 정확성을 기하고자 하는 방법

• 인건비는 전문가마다 다를 수 있으므로 이를 개발비 산정에 반영시키는 목적도

있음

– 예) 평균 인건비는 MM당 200만원, 시스템 분석가나 설계자는 MM당 250만원,

프로그래머나 테스터는 MM당 150만원

42



3. COCOMO (Constructive COst Model) 방법

– Boehm(1981), 원시 프로그램의 규모에 의한 비용산출 방법

– 실제 소프트웨어 개발 프로젝트들의 기록을 통계 분석한 결과로 산출

– 진행 예정인 프로젝트의 여러 특성들을 고려할 수 있도록 개발자에게 융통성 부여

• 소프트웨어 제품, 프로젝트 형태, 개발 환경, 개발 인력 요소에 따라 15개의 특성 값이 부여

– 완성될 시스템의 규모(LOC)를 추정하고 이를 준비된 공식에 대입하여 투입 노력(MM)과

개발기간(TDEV) 예측

– 특징

• 소프트웨어 개발비용 산정 기법 중에서 미리 준비된 식과 표를 이용하여 비용을 산정할 수 있는

알고리즘 방식 기법

• LOC와 FP 기반 측정 방법이 “분해기법”을 사용한 반면, COCOMO 모델은 “경험적 추정

모형”을 나타냄

• 제품의 복잡도에 따라 organic 소프트웨어, semidetached 소프트웨어, embedded

소프트웨어로 분류하며, 제품의 원시 명령어의 수에 의한 PM(Person/Months)를 단위로 비용

산정 예측 방식을 제안

– PM(Person/Months) : 프로젝트를 개발하는데 필요한 프로그래머 인원/월(MM)의 관계

– KDSI(thousands of delivered source instruction) : 제품의 최종 원시코드의 명령어 수

43



– 제품 복잡도에 따른 프로젝트 개발 모델(3가지 유형)

44

유형 설명

Organic mode

• 50KDSI(5만 라인) 이하의 프로젝트

• 일반 응용 프로그램

– 과학기술 계산용, 급여관리 프로그램, 일반 업무용 등

Semidetached mode

• 300KDSI(30만 라인) 이하의 프로젝트

• 개발지원도구

– 컴파일러, 워드프로세서 등

Embedded mode

• 300KDSI(30만 라인) 이상의 프로젝트

• 시스템 프로그램

– 운영체제, 통신 모니터 등

– 시스템 소프트웨어, 하드웨어, 소프트웨어, 운영제약이 하나의 시스템으로 형성되는 항공기 운항제어 시스템과 같은 초대형 규모의 시스템


45


– 비용 추정 단계 및 적용 변수의 구체화 정도에 따른 분류

Basic

COCOMO

• 프로젝트 크기나 특성과는 관계없이 원시코드 라인수 만으로 비용을 계산 • 소프트웨어 크기나 개발 모듈에 의해 산정(LOC에 의존)

Intermediate COCOMO

• Basic COCOMO을 토대로 계산하나, 다음 4가지 특성의 15가지 요인 을 가미하여 곱한 가중치 계수(노력승수) 사용

a. 제품의 속성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도 b. 컴퓨터의 속성 : 수행시간의 제한, 기억장소의 제한, 가상기계의 안정성,

turnaround 시간 c. 개발요원 속성 : 분석가 능력, 개발 분야 경험, 가상기계의 경험, 프로그

래머의 능력, 프로그램 언어의 경험 d. 프로젝트 속성 : 소프트웨어 도구의 이용, 프로젝트 개발 일정, 소프트웨

어 공학의 활용도

Detailed COCOMO

• 시스템을 모듈, 서브 시스템으로 세분하여 Intermediate COCOMO 방식 적용 • 소프트웨어 환경과 구성요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용 • Intermediate COCOMO 산정 공식을 그대로 사용하되, 노력승수 = 개발 공정별 노력승수 * 개발 공정별 가중치


46


• Basic COCOMO

– 추정된 LOC를 프로그램 크기에 대한 함수로 표현해서

소프트웨어 개발 노력(MM)과 개발 기간(TDEV)을 계산

– 소프트웨어를 개발하는데 드는 노력 : MM = a(KDSI)b

– 프로젝트를 완성하는데 요구되는 시간 : TDEV = c(E)d

– 프로젝트 산정을 시작하는데 유용하지만 프로젝트 크기와 유형을

제외하고는 프로젝트에 영향을 미치는 많은 요인들이 제외

개발 유형 투입 노력(MM) 개발 기간(TDEV)

Organic MM = 2.4*(KDSI)1.05 TDEV=2.5*(MM)0.38

Semidetached MM = 3.0*(KDSI)1.12 TDEV=2.5*(MM)0.35

Embedded MM = 3.6*(KDSI)1.20 TDEV=2.5*(MM)0.32


47


• 예1) 32,000 DSI (=32 KDSI)로 예상되는 Organic mode의

소프트웨어 프로젝트

– MM = 2.4 * (32)1.05 = 91 man-months

– TDEV = 2.5 * (91)0.38 = 14 개월

– FSP = MM/TDEV = 91/14 = 6.5 ≒ 7명

– 생산성 = DSI/MM = 32,000/91

= 351.648… ≒ 352LOC/MM

• 한 달에 일 할 수 있는 날을 22일로 가정

• 352/22=16 ⇒ 한 사람이 하루에 약 16 라인 작성

• 예2) 128,000 DSI의 크기인 embedded mode 소프트웨어

프로젝트

– MM, TDEV, FSP, 생산성, 한 사람이 하루에 작성할 명령문 라인수


48


• Intermediate COCOMO : Basic COCOMO의 확장

– 4가지 종류 15개의 요인을 적용하여 계산

• 제품의 특성

– 요구되는 소프트웨어 신뢰도(RELY) Reliability

– Database 크기(DATA) Database size

– 제품의 복잡도(CPLX) Complexibility

• 컴퓨터의 특성 : 소프트웨어 생산성에 영향을 주는 Hardware의 제한조건

– 수행시간의 제한(TIME) Constant of performance time

– 기억장소의 제한(STOR) Constant of storage

– 가상기계의 안전성(VIRT) Safely of Virtual Machine

– Computer의 Turnaround 시간(TURN) Turnaround time of computer

• 개인의 특성

– 분석가의 능력(ACAP) Analysis capability

– 개발분야의 경험(AEXP) Area of Experience

– 가상기계의 경험(VEXP) Experience of Virtual Machine

– Programmer의 능력(PCAP) Capability of programmer

– Programming language의 경험(LEXP) Experience of programming language

• 프로젝트 특성

– 최신 Programming 기법의 이용(MODP) Modern Programming

– 소프트웨어 도구(TOOL) Tool

– 요구되는 개발일정(SCED) Schedule


49


– 15가지 특성에 따른 승수값


50


• Intermediate COCOMO에서의 비용 예측 절차

① 명목개발노력(Nominal Development Effort) 추정

② 시스템 개발에 따른 15가지 특성을 고려하여 노력승수 결정

③ 개발노력 추정

• 개발노력 = 명목개발노력*노력승수

④ 총 투입 MM(개발노력)을 TDEV(개발기간)로 나누면 적정투입인원수가 산출

• FSP=MM/TDEV

⑤ FSP와 TDEV를 이용하여 소요인건비를 산출

• COST = FSP * TDEV * 월 평균 임금


51


• 예) Micro computer상에서 개발하는 Embedded 유형의 소프트웨어

– 조건1) Intermediate COCOMO 모델의 노력승수는 아래 값을 제외하고

모두 중간 등급(1)의 값

• RELY 1.15, STOR 1.21, TIME 1.10, TOOL 1.10

– 조건2) Basic COCOMO에 의해 산정된 노력 개발(MM) = 45 MM

– 조건3) 월 평균 임금 : $7,000

– 개발노력 = 명목개발노력 * 노력승수

= 45 * 1.15 * 1.21 * 1.10 * 1.10 = 76 Man-Months

– 개발일정 = 2.5 * (76)0.32 = 9.99 … ≒ 10 개월

– 적정투입인원 = 76/10 = 7.6 ≒ 8명

– 비용(cost) = FSP * TDEV * 월평균 임금 = 8 * 10 * 7000 = $560,000


52


– 장점

• 비교적 정확한 모델

• 소프트웨어 개발비 견적에 유연성 부여

– 단점

• 소프트웨어 제품을 하나의 개체로 보고 승수들을 전체적으로 적용

– 대부분의 대형 시스템은 서로 상이한 서브시스템으로 구성

– 서로 적용되어야 하는 개발 유형이 다를 수 있음

» 일부분은 Organic mode이고, 일부분은 Embedded mode인 경우도 있음

» 일부분에 대해서는 신뢰도가 매우 높아야 하고, 일부분에 대해서는 신뢰도가

낮아도 되는 경우도 있음


53


• Detailed COCOMO

– Intermediate COCOMO의 보완

– 전체 시스템을 서브시스템 또는 모듈 단위로 분리하여

Intermediate COCOMO 적용

– MM, TDEV의 계산은 Intermediate COCOMO와 동일

– 노력승수의 결정 = 개발 공정별 노력승수* 개발 공정별 가중치

– 전체 시스템의 비용 = SUM(각 서브 시스템의 비용)



• COCOMO는 간단한 수식이므로 쉽게 도구로 구현 가능

– 예) KDSI 및 Development Mode 등 기본 입력을 선택

54



4. Putnam 추정 모형 (생명주기 예측 모형)

– 동적 다변수 모델(동적 모델) : 각 개발기간마다 소요 인력을 독립적으로 산정

가능함

– 시간에 대한 함수로 대형 프로젝트의 노력 분포 산정에 이용

5. 기능 점수(Function Point) 모형

– 소프트웨어의 각 기능에 대하여 가중치를 부여하여 요인별 가중치를

합산하여 소프트웨어의 규모나 복잡도, 난이도를 산출하는 모형

– 최근에는 유용성과 간편성 때문에 관심이 집중되고 있으며, 기능 점수 기법은

라인 수에 기반을 두지 않는 방법

– 정보처리 규모는 사용자 입장에서 본 시스템의 기능을 외부입력, 외부출력,

외부조회, 내부 논리파일, 외부 인터페이스 파일 등의 5가지 유형으로 나누어

각 기능의 복잡도를 고려하여 측정

55


위험 분석 및 관리

• 위험 분석 및 관리

– 소프트웨어 팀이 앞으로의 개발에 대한 불확실성을 이해하고

관리해주는 단계

– 위험 분석 : 프로젝트에 내재된 위험 요소를 인식하고 그 영향을

분석하여 이를 관리하는 활동

– 위험(risk)

• 프로젝트 진행 중에 발생하여 프로젝트의 정상적인 납기, 원가 및 품질

등에 영향을 줄 수 있는 모든 사건

• 프로젝트 진행 중 식별되고 관리 및 해결되어야 할 프로젝트 관리 요소

– 일정 지연 위험은 작업 사이의 의존도를 제한함으로써 낮출 수 있음

56


57

4.4 계획서 작성

• 소프트웨어 개발 계획서

– 프로젝트 관리자, 기술진, 고객에게 프로젝트의 범위와 자원을

상호 협의할 수 있도록 하기 위해 작성

– 프로젝트의 성격이나 사용자의 요구에 따라 다양

– 구성 1. 개요

1.1 프로젝트 개요

1.2 프로젝트 범위 및 목표

1.3 용어, 약어

2. 자원 및 일정 예측

2.1 인력

2.2 비용

2.3 일정

3. 프로젝트 구성

3.1 작업 구성

3.2 조직 구성

4. 관리 계획

4.1 변경관리

4.2 위험 관리

4.3 비용 및 진행 관리

5. 기술 계획

5.1 개발 방법론

5.2 문서화

6. 회의 일정 및 진행방법

7. 개발 환경

8. 테스트 방법

9. 유지보수

10. 부록


58

chap. 4 소프트웨어 관리 -...

Documents