소프트웨어 프로젝트 계획은 발생가능성이 있는 문제점들을 분석하여 이를 해결하기 위한 방안을 모색하고, 이 결과를 바탕으로 프로젝트 관리에 필요한 사항을 설정하는 것이다.
소프트웨어 계획수립의 목적
소프트웨어 개발 일정의 지연, 비용 초과, 품질 저하, 유지비용의 증가 등과 같은 문제는 계획의 부재에서 기인하는 경우가 많다. 개발 일정을 지키면서 좋은 품질의 소프트웨어를 개발하기 위해 소프트웨어 계획수립이 필요하다.
소프트웨어 개발과정을 계획하는 것은 소프트웨어를 개발하여 설치될 때 까지 어떤 일들이, 누구에 의하여, 언제 행해져야 하는지를 정하는 것을 말한다. 계획은 다음과 같은 5가지 작업으로 구성된다.
1. 문제와 범위를 이행하고 정의
2. 노력 추정
3. 필요한 작업을 정의하고 순서를 결정 (일정계획)
4. 위험분석
5. 계획서 작성
계획 단계에서는 충분한 정보가 없고 이해의 부족 때문에 정확한 예측이 어렵고, 일정을 계획하지 못하는 경우도 있다. 따라서 초기의 계획은 프로젝트를 진행하면서 현실성 있게 변경될 수 있어야 한다.
소프트웨어 프로젝트 자원
인적자원
관리자, 선임(고급)기술진, 하급 기술진으로 구성된다.
| 관리자 | 계획 수립, 조직구성, 소프트웨어 작업을 수행하는 실무자를 관리 |
| 선임(고급) 기술진 | 프로젝트 계획, 요구분석, 설계, 검사 등 모든 단계에 참여한다 |
| 하급 기술진 | 선임 기술진을 지원하며 생명주기 설계, 구현 단계에서 활동한다. |
재사용 가능 소프트웨어 자원
컴포넌트 기반의 소프트웨어 공학(CBSE ; Component-Based Software Engineering)은 재사용을 강조한다. 컴포넌트는 쉽게 참조하기 위해 카탈로그가 만들어져야 하고 쉽게 응용하기 위해 표준화되어야 하며, 쉽게 통합하기 위해 확인되어야 한다.
계획이 진행되어 감에 따라 고려해야 할 Bennatan의 4가지 소프트웨어 자원범주는 다음과 같다
| 규격 부품들 | 제 3자가 개발하였거나 과거의 프로젝트에서 구할 수 있는 기존의 소프트웨어를 의미 사용 규격 부품은 제3자에게서 구입할 수 있고, 현재의 프로젝트에 당장 사용 가능하다. |
| 충분히 경험하여 잘 알고 있는 부품들 | 현재 프로젝트에서 제작하고 있는 소프트웨어와 유사한 과거의 프로젝트에서 개발한 기존의 명세서들, 설계, 코드 또는 테스트 데이터 현재의 프로젝트 팀원들은 이 부품이 표현하는 응용분야에 대해 충분히 경험하고 잘 알고 있다. 그러므로 이러한 부품들을 수정하는 것은 위험부담이 상대적으로 낮다. |
| 부분적으로 경험이 있는 부품들 | 현재 제작하고 있는 소프트웨어와 관계는 있으나, 대대적인 수정이 요구되는 과거의 프로젝트에서 개발된 명세서, 설계, 또는 테스트 데이터들을 말한다. 현재 소프트웨어의 팀원들은 이 부품들이 표현하는 응용분야에 대해 제한된 경험만을 가지고 있다. |
| 새로운 부품들 | 현재 프로젝트의 특정한 요구 때문에 소프트웨어 팀이 제작해야 하는 소프트웨어 부품을 말한다. |
환경자원
소프트웨어 공학환경(SEE ; Software Engineering Environment)은 소프트웨어 프로젝트를 지원하는 환경으로서, 하드웨어와 소프트웨어 모두를 반영한다. 하드웨어는 양질의 소프트웨어 공학 실무에서 산출되는 산출물을 생산하는 데 필요한 도구(소프트웨어)를 지원하는 플랫폼을 제공한다.
소프트웨어 프로젝트 추정
비용과 노력 추정 모델 (경험적 추정, 델파이, 코코모, 기능점수)
하향식(top down) 산정방법
| 종류 | 설명 |
| 전문가의 감정 | 경험과 지식을 갖춘 2명 이상의 전문가가 판단하는 방법 간편하고 신뢰감을 준다 낙관적, 비과학적 (기술적 요인을 간과하기 쉽다), 객관성 부여의 어려움(개인적 차이가 크다 |
| 델파이(delphi)식 산정 | 전문가 + 익명의 조정자로 구성되어, 권위적 환경의 역량을 최소화, 그룹회의의 부작용을 극복하는 기법이다. 여러 전문가들이 여러 시선에서 산정하여 합의를 도출하는 방식이기 때문에 산정의 정확성을 높일 수 있다. 여러 전문가들과 기법을 동원해야 한다. |
상향식 (bottom up) 산정방법
| 종류 | 설명 |
| PERT | Project Evaluation and Reivew Techinique LOC (Line of Code; 원시 코드 라인 수)를 산정하는 데에 사용된다. |
| COCOMO | COnstuctive COst MOdel 시스템을 구성하고 있는 모듈과 서브시스템 비용의 합계로서, 소프트웨어 시스템의 추정비용을 계산하는 기법 |
| 기능점수(function point)모델 | 소프트웨어 시스템이 가지는 기능을 정량화한 것으로, 각 기능에 대한 가중치를 부여하여 요소별 가중치를 합하고 소프트웨어 규모나 복잡도, 난이도를 산출하는 모델이다. |
PERT
작업예측치(E) = { 최적치 + (4 * 근접치) + 최악치 } / 6
작업편방편차 = { (최악치 - 최적치) / 6 }^2
프로그램 평가 및 검토 기술에 이용한다.
통계 모형을 적용하여 개발 task에 대해 가장 정확한 시간을 추정하게 해 준다
노력(인월) = 개발기간 * 투입인원 = LOC / 1인당 월평균 생산 코드 라인 수
개발비용 = 노력(인월) * 단위비용(1인당 평균 인건비)
개발기간 = 노력(인월) / 투입 인원
생산성 = LOC / 노력(인월)
유지 보수비용 측정에도 이용 가능하다.
COCOMO(COnstructive COst Model)
시스템을 구성하고 있는 모듈과 서브시스템 비용의 합계로서 소프트웨어 시스템의 추정비용을 계산하는 비용 산정 방법이다.
정의
1. 보엠(Boehm)이 제한한 원시 프로그램의 규모에 의한 방법
2. 먼저 완성될 시스템의 규모(line of code)를 추정하고 이를 준비된 식에 대입하여 소요 될 인원 예측
3. 1981년에 초기 모델 제안, 1995년 COCOMO 2로 확장
4. 세 가지 단계로 구성
4-1. 프로그램 규모를 예측한 후 추정식에 대입하여 개발 노력의 초벌 예측값을 구한다.
4-2. 프로젝트에 대한 15가지 속성에 대하여 가중치를 결정한다.
4-3. 초벌 예측값에 가중치를 곱하여 노력 추정치를 보정한다.
특징
1. 소프트웨어의 종류에 따라 책정되는 비용 산정 방식이 다르며, 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정된다.
2. LOC와 FP, 기반측정방법이 '분해 기법'을 사용한 반면, COCOMO 모델은 '경험적 추정 모형'을 나타낸다.
3. 제품의 복잡도에 따라 조직형, 반분리형, 내장형으로 분류하고 제품의 원시 명령어의 수에 의한 PM(person month; 인월)을 단위로 비용 산정 예측 방식을 제안한다.
4. 소프트웨어 개발비용 산정 기법 중 미리 준비된 식과 표를 이용하여 비용을 산정할 수 있는 알고리즘 기법이다.
| 유형 | 공식 | 설명 |
| 조직형 (단순형) | PM = 2.4 X (KDSI)^1.05 | 소규모 팀이 개발하는 잘 알려진 응용 시스템 |
| 반분리형 | PM = 3.0 X (KDSI)^1.12 | 단순형과 임베디드의 중간형으로 트랜젝션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 |
| 내장형 (embedded) | PM = 3.6 X (KDSI)^1.20 | 하드웨어가 포함된 실시간 시스템 |
COCOMO의 장단점
1. 비용 요소의 통제가 가능하다.
2. 노력승수의 조정이 가능하다.
3. 다변량 노력 조정계수를 사용하므로 한 요소가 변경되면 다른 요소도 따라서 변경된다.
4. 소프트웨어 라인 수를 입력해야 하는 것은 COCOMO의 가장 큰 약점으로 지적되는데, 라인 수의 예측 자체가 힘들기 때문이다.
COCOMO II
bS^c = 기초 소요능력 예측값
m(X) = 비용승수의 벡터
COCOMO II 는 재사용, 요구분석, 요구변경을 반영할 수 있는 모델이다.
특징
1. 소프트웨어 개발 프로젝트의 진행된 정도에 따라 3가지 다른 모델을 제시한다.
2. 개발 초기에 LOC를 예측하는 것이 어렵기 때문에 다양한 규모척도를 이용한다.
3. 1단계는 애플리케이션 결합 단계로, 프로토타입을 작성하는 단계이며, 화면이나 출력 등의 사용자 인터페이스, 3세대 언어 컴포넌트 갯수를 세어 응용점수를 계산한다.
4. 2단계는 초기 설계 단계로, 자세한 규모와 기능을 파악하는 것이 가능하기 때문에, 1단계보다 정확한 예측이 가능하다. 기능점수(function point)를 통해 소프트웨어 규모를 측정한다.
5. 3단계는 설계 이후 단계로 기능점수와 LOC를 규모척도로 이용한다.
6. 재사용, 요구분석, 요구변경을 반영한 모델이다.
기능점수 (function point)
소프트웨어 시스템이 가지는 기능을 정량화한 것으로, 각 기능에 대한 가중치를 부여하여 요소별 가중치를 합하고 소프트웨어 규모나 복잡도, 난이도를 산출하는 모델.
기능점수는 개발자 입장과는 무관하며, 최종 사용자 입장에서 소프트웨어 규모를 견적하는 값이다. 기능점수의 견적 측정 구조는 사용자 입장에서 본 외부 입력(external input type), 외부 출력(external output types), 외부 조회(external inquiry types), 내부 논리 파일(internal logic file types), 외부 인터페이스 파일(external interface file types)등의 5가지 유형을 나누어 각 기능의 복잡도를 고려하여 측정한다.
상향식 / 하향식 비교
| 상향식 | 하향식 |
| 처음에 각 모듈 또는 서브시스템을 개발하는 비용을 산정하고, 합산하여 전체 비용 산정 시스템 차원의 비용은 고려하지 않을 수도 있다. 업무분류구조, 연산방식에 의한 비용 산정 방법 등 |
전체 시스템 차원에서 비용 산정 시스템 차원의 비용에 초점 인력비용은 유사한 과거 프로젝트의 비용을 검사함으로써 추정 개발 모듈에 대한 여러 가지 기술적인 요인을 간과할 수 있음 전문가의 감정, 그룹에 의한 산정, 델파이 비용 산정 기법 등 |
자동추정도구
SLIM
소프트웨어 생명주기에 대한 Reyleigh-Norden 곡선과 Putnam 측정 모델을 기초로 한 자동 비용 시스템, PERT 기법을 적용한다
ESTIMACS
프로젝트 및 개인별 요소를 수용하여 기능 요소 측정방법 이용
다양한 프로젝트와 개인별 요소를 수용하도록 개발된 기능 요소 측정방법을 이용한 매크로 측정 모델이다.
소프트웨어 프로젝트 일정계획
인간-작업관계 및 업무정의 분배.
일정계획의 결과로서는 작업의 분할, 작업들 간의 관계, 인적 물적자원 배정 들을 일정에 따라 보여주는 도표들을 포함한다. 일정계획을 세운 후 실제 인도 시점을 개발조직에서 결정하는 것이 좋으나, 경우에 따라서는 시스템을 인도할 시점이 정해져 있어 불가피하게 정해진 일정에 맞도록 비용과 자원으로 배분해야 하는 경우도 있다.
작업의 분할
요구사항 명세에 기초하여 전체 작업을 소작업으로 분할한다.
작업의 명세화
분할된 소작업들에 대해 일의 양, 필요한 산출물과 컴퓨터 자원 등을 결정한다.
작업진행 순서의 정의
분할된 소작업들 중에서는 동시에 작업할 수 있는 작업들도 존재하며, 작업들 간 선행관계가 존재하여 순서에 따라 진행해야 하는 작업도 존재한다. 따라서, 작업들의 특성, 우선순위, 설정된 이정표 및 입출력물에 기초하여 작업의 수행순서를 정해야 한다.
인력 배정
작업의 양과 특성에 맞도록 개발자를 배정한다.
작업비용의 산정
각 작업에 대한 명세화 과정, 진행순서의 결정, 인력 배정이 끝나면 작업을 종료하는데 필요한 비용을 산정한다.
개발 일정의 수립
각 작업별로 개발기간을 결정하고 작업들 간의 선후관계를 고려하여 각 작업의 시작 시점과 종료 시점을 설정한다.
일정계획방법
PERT/CPM
분할된 작업들 간의 연관성을 기초로 하여 가능한 한 빠른 시간 안에 프로젝트 일정을 종료하기 위해 사용한다.
PERT(Program Evaluation and Review Technique)
행위 네트워크(activity netwrok) 또는 선행 (precedence) 다이어그램이라고도 한다.
작업의 소요시간이 명확하지 않을 때에는 일정계획에 불확실성을 고려한다.
PERT 도표는 사이클을 갖지 않는 방향성 그래프이며, AOE(Activity on Edge)와 AOV(Activity on Vertex) 네트워크의 두 가지 형태가 있다.
CPM
예산과 개발과정을 최적화하려는 일정계획방법으로, 임계경로 방법에 의한 프로젝트 최단 완료시간을 구하는 데 사용한다.
임계경로 (critical path)
전체 프로젝트의 작업 경로중 가장 긴 시간이 걸리는 경로
간트 차트(Gantt Chart)
프로젝트를 이루는 소작업별로 언제 시작하고 언제 끝나야 하는지를 한눈에 볼 수 있도록 그린 프로젝트 일정표.
각 공정들이 언제 시작하고 종료되는지를 막대 도표로 표시한다.
중간 목표 미달성시 이유와 기간을 알 수 있고 사용자와의 문제점이나 예산의 초과 등을 관리할 수 있으나, 작업들 사이의 관계를 직접 보여주지 못하고 계획이 세분화되어 있지 않기 때문에 변화에 대한 적응력이 떨어진다. 또한 작업경로를 표시할 수 없기 때문에 프로젝트 작업을 발견하는데 도움을 주지 못한다.
조직계획
분산형 팀 구성
팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대하여 같은 그룹의 일원으로 책임을 진다. 따라서 다른 사람의 일을 같이 검토하고 이해하므로 이런 팀 구성방식을 민주적(egoless) 팀 구성이라고 한다.
의사소통 수: n(n-1) / 2
장점
팀 구성원의 만족도를 높이고, 엔지니어들이 프로젝트에 대하여 더 적극적으로 행동하게 하며 팀 구성원간 의사교류를 활성화 시키므로, 복잡하고 이해하기 어려운 문제가 많은 장기 프로젝트에 적합하다.
단점
대규모의 문제에는 적합하지 않으며, 의사교환을 위한 비용이 크고 개인의 생산성을 떨어트린다.
모든 구성원이 만족할만한 해결 방안을 찾는 것이 어렵다.
중앙 집중형 팀 구성
팀 구성원이 관리자의 명령에 따라 일하고 결과를 보고하는 방식이다.
한 사람에 의하여 통제할 수 있는 비교적 소규모 책임 프로그래머 팀이다.
팀 구성원
| 책임 프로그래머 | 프로젝트 계획, 요구분석과 설계, 중요한 부분의 프로그래밍 등, 모든 기술적 판단을 내린다 |
| 프로그래머 | 원시 코드를 작성하고 테스팅, 디버깅 및 문서작업을 담당 |
| 프로그램 사서 | 프로그램 리스트, 설계 문서, 테스트 계획 등을 관리한다 |
| 보조 프로그래머 | 책임 프로그래머를 보좌하여 여러가지 기술적인 문제에 대해 자문한다. |
장/단점
| 장점 | 단점 |
| 책임 프로그래머의 리드에 따라 의사결정이 이루어지기 때문에 의사결정 경로가 짧아진다 프로그램 개발과정이 신속하다. |
책임 프로그래머의 개인 능력에 크게 의존한다 |
혼합형 팀 구성
중앙 집중형과 분산형의 단점을 피하기 위해 혼합한 형태, 5~7명의 중급 프로그래머를 작은 그룹으로 만들어 고급 프로그래머가 관리하게 하고 모든 그룹을 프로젝트 리더가 관리하도록 하는 방법이다.
장/단점
| 장점 | 단점 |
| 팀 구성원 사이의 효율적인 의사소통을 위해 의사교환경로를 과감히 줄일 수 있다. | 기술 인력이 관리를 담당하게 되므로 좋은 개발 경험을 사장시킬 수 있다. 기술 인력이 조직, 인력 및 업무를 관리해야한다 |
'cs' 카테고리의 다른 글
| network - 무선랜 (0) | 2022.07.29 |
|---|---|
| 인공지능 - 생성 시스템 (0) | 2022.07.26 |
| network - 유선랜 (0) | 2022.07.24 |
| 인공지능 - 퍼지이론 (0) | 2022.07.22 |
| network - 데이터링크 계층에서 다중 접근 방식 (0) | 2022.07.19 |
