계획 (프로젝트 관리와 계획) Part 1

계획

체계적이고 명확한 계획을 위한 6가지

1. 문제 정의
2. 타당성 분석
3. 소프트웨어 개발 비용 산정
4. 일정 계획
5. 위험 분석

문제 정의

- 어떤 것을 개발할 것인지 명확히 정의

- 개발 범위를 정함

문제 정의시 필요한 것

- 기존에 존재하는 비슷한 종류의 시스템 사용해보기

- 개발하고자 하는 영역의 배경지식 필요

타당성 분석

- 경제적 타당성

- 기술적 타당성

- 법적 타당성

경제적 타당성

- 경영자 : 기업에 얼마나 많은 이윤을 남겨줄지,투자효율성을 분석

- 시장 조사를 통해 시장성 분석

- 이를 통해 프로젝트를 진행할지 결정

기술적 타당성

- 현재의 기술로 소프트웨어를 개발할 수 있는지 검증

- 하드웨어 성능이 개발에 지장이 없는지 검증

- 개발자의 기술이 문제가 없는지 검증

법적 타당성

- 개발용 소프트웨어와 도구들이 사용에 법적 문제가 없는지 검토

개발 비용 산정

- 하드웨어보다 소프트웨어의 개발 비용 산정이 어려움

-> 하드웨어 : 제품이 명확하고 부품이 정해져 있음

-> 소프트웨어 : 개발자의 능력에 따라 품질의 차이가 큼
                         개발 프로세스가 다양하여 표준화나 자동화가 힘듦

                         언제 끝날 지, 몇명이 투입 되어야 할지 확정하기 어려움 (반복)

- 어렵지만 대략적으로 해야 함 (정확한 비용이 아니라도)

개발 비용에 영향을 주는 요소

- 프로그래머 능력

- 소프트웨어의 크기

- 소프트웨어의 복잡도

- 가용 시간 (소프트웨어 운영 시간)

- 기술 수준

- 요구되는 신뢰도 수준 (작은 게임에서의 오류 vs 금융 시스템에서의 오류)

개발 비용 산정 기법 - 하향식 산정 기법

- 프로그램 규모를 예측하고 과거의 유사 경험을 바탕으로  회의를 통하여 개발 인력과 기간을 산정

- top-down 방식

- 전문가 판단 기법, 델파이 기법

전문가 판단 기법

- 소프트웨어 개발 비용을 산정할 때 경험이 많은 전문가의 의견을 듣고 결정

- 장점 : 신뢰성있는 결정을 할 수 있음, 편리함

             짧은 시간안에 비용을 산정해야할 때 좋음

- 단점 : 경험에만 너무 의존하여 부정확한 판단을 내릴 수 있음

            과거 프로그램과 비슷하다고 생각하여 새로운 프로젝트를 과소평가할 수 있음

            너무 전문가에게 의존하는 방법임

- 단점 보완 : 델파이 기법

델파이 기법

- 전문가의 경험을 중요시 하는 것은 전문가 판단 기법과 동일함

- 전문가의 편견이나 분위기에 영향을 받지 않도록 조정자를 둠

- 전문가와 조정자의 의견이 일치할 때 까지 비용 산정

- 경험에 너무 의존한다는 단점은 똑같음

개발 비용 산정 기법 - 상향식 산정 기법

- 전체 프로젝트의 세부 작업별로 비용을 산정한 후 통합하는 방법

- 원시 코드 라인 수 기법, 개발 단계별 노력 기법

원시 코드 라인 수(Line of Code, LOC) 기법

 

- 원시 코드의 비관치, 낙관치, 중간치를 측정 후 예측치를 구함

- 장점 : 심플함

- 단점 : 요구사항 분석이나 설계와 같은 비코딩적 요소를 고려하지 않음

개발 단계별 노력 기법

- 원시 코드 라인 수 기법은 전체 코드 라인 수만 예측하지 요구 분석이나 설계와 같은 것은 고려하지 않음

- 각 기능을 구현하는 데 필요한 M/M을 소프트웨어 개발 생명 주기의 단계별로 산정

   M/M : Man Month, 프로젝트에 투입되는 월 인원 (프로젝트를 한 달에 끝내기 위해 필요한 인원)

- 참여 이벤트 비용과 같은 다른 비용은 고려하지 않음

개발 비용 산정 기법 - 수학적 산정 기법

- 앞의 2가지보다 더 디테일한 방법

COCOMO (COnstructive COst MOdel)

COCOMO PM(M/M) 계산

- 단순형 : 복잡도와 난이도가 비교적 높지 않은 소프트웨어

- 중간형 : 운영체제, 데이터베이스 관리 프로그램

- 내장형 : 하드웨어가 포함된 최상위 규모 실시간 처리 시스템 

               ( 하드웨어가 있는 프로그램이면 연동이 잘 되어야하기 때문에 난이도가 올라감 )

COCOMO 노력 조정 수치 추가

- EAF(Effort Adjustment Factor) : 노력 조정 수치 (프로젝트의 특징 고려)

- EAF 요소가 하나 이상이라면 곱함

COCOMO 총 개발 기간 계산

- 왜 프로젝트가 단순할수록 더 기간이 길어지는가?

   -> 단순할수롣 체계가 잡혀있지 않기 때문에 더 오래걸림

COCOMO 방법의 한계

- 계획 단계에서 원시 코드의 라인 수를 정확하게 예측할 수 없음

기능 점수 산정 방법

- 언어의 종류, 개발자의 수준, 알고리즘에 따라 코드의 라인 수가 달라짐

- 라인 수와 무관하게 기능이 많으면 규모도 크고 복잡도가 높다고 판단

- 기능수(함수의 입출력)를 고려

   ( 프로그래밍 언어 종류는 관계 없음  -> 지금 고려할 대상 아님 )

장점

- 구현 기술, 구현 언어, 개발자의 능력과 관계 없이 일관성있게 규모를 제공할 수 있음

- 객관적인 요구 사항만 가지고 측정 (코드 길이에 영향을 받지 않음)

단점

- 높은 분석 능력 필요 (기능 점수 전문가 필요)

- 실제 개발과 다를 수 있음