[소프트웨어공학] 프로젝트 관리와 비용추정

소프트웨어 관리는 소프트웨어 공학의 필수적인 부분이다. 좋은 관리라고 해서 프로젝트의 성공을 보장할 수는 없다. 그러나 나쁜 관리는 프로젝트를 실패로 이끈다. 

소프트웨어 관리자는 프로젝트 개발을 계획하고 일정을 관리하는 책임을 진다. 소프트웨어 관리자는 다른 공학과 구별된다.

1. 소프트웨어 제품은 형태가 없다.

소프트웨어 제품 관리자는 프로젝트 진척사항을 볼 수 없다. 그들은 프로젝트 진척사항을 점검할 수 있는 문서를 생성하는 사람에게 의존한다.

2. 표준화된 프로세스가 없다.

소프트웨어 프로세스는 조직에 따라 매우 가변적이다. 

3. 대규모 소프트웨어 프로젝트는 대개 일회성(one-off)프로세스이다.

대규모 소프트웨어 프로젝트는 대개 어 방향에서 이전 프로젝트와 다르다.

이런 문제 때문에 소프트웨어 프로젝트가 연기되고 예산을 초과하고 일정이 지연되는 것이 자연스럽다. 이러한 어려움에도 불구하고 소프트웨어 프로젝트가 적기에 주어진 예산에 완성되어 출하되는 것이 놀라운 일이다. 

## 관리 활동

소프트웨어 관리자를 위한 표준 작업 기술 문서를 작성하는 것은 불가능하다. 작업은 조직과 개발 중인 소프트웨어 제품에 따라 극히 다양하다. 그러나 대부분의 관리자는 다음 관리 항목에 대해 일부 또는 전부를 책임진다.

* 제안서 작성

* 프로젝트 계획 수립 및 일정 관리

* 프로젝트 비용 산정

* 프로젝트 감시 및 검토

* 인력 선발 및 평가

* 보고서 작성 및 발표

# Project Plan

프로젝트 시작 단계에 생성하고 프로젝트의 진행정도를 파악하는데 도움을 준다.

계획의 종류

# Planning Process

MileStone이란 획을 긋는 주요일정을 말한다. 즉, 어제와 오늘이 다른 일을 말한다.

Deliveries 란 아웃풋 중 고객에게 전달 될것을 말한다. (요구사항명세서, 사용메뉴얼 등)

cf> 프로토타입 : 아웃풋이지만 고객에게 줄 필요가 없는 것 (회의록 등)

# Task, durations, dependencies

Effort는 소프트웨어 공학에서 쓰이는 모호한 단위이다. (비용아님)

persons-day 는 한 사람이 일했을 시 소요되는 일 수 이다.

이것은 모호한단위로 man month라고도 한다. ex) 15 men month

Dependencies는 이 Task를 하기위해 완료되어야 할 Task를 말한다. T3는 T1이 끝나는 때 하는 것이고 Milestone1인 것이다.

# Bar chart & Activity chart

Activity차트나 Bar 차트같은 것들은 MS에서 제공하는 관리도구를 이용하면 쉽게 그릴 수 있다.

Jane의 할당량을 보자. 거의 모든 날짜에 일을 한다. 그렇다면 Jane의 일의 난이도는 어때야 할까?

관리자에 입장에서는 Task가 쉬워야 한다. 난이도가 높은 일들을 저렇게 긴 기간동안 한다면 실수할 확률이 높기 때문이다.

Mary의 할당량을 보자. 짧은 기간에 짧은 일을 한다. 난이도가 굉장히 높을 것이다. 매우 전문적인 일이여서 Mary밖에 할 수가 없다. 회사의 중역이다.

하지만 오히려 이부분이 bottleneck이 될 수도 있다. 전문적인 부분에서 오류가 날 수도 있다.

# Agile Planning

고객의 우선순위 및 요구사항 변화를 수용하기 쉽도록 계획한다.

* Release Planning: 몇 달 단위로 먼저 예측한다.(long-term outlook), 시스템 릴리즈시 포함되어야 하는 feature를 결정한다.

* Iteration Planning: a shorter term outlook, 시스템의 다음 번 increment를 계획하는데 초점을 둔다., 2~4주 term을 둔다.

## 비용추정 (Estimation Technique)

프로젝트 비용 산정과 프로젝트 일정 추정을 보통 함께 수행된다. 소프트웨어 개발 프로젝트의 총 비용을 계산하는데 관련된 세 개의 매개변수가 있다. 

* 유지보수를 포함한 하드웨어와 소프트웨어 비용

* 교통비와 훈련 장비

* 인건비(소프트웨어 엔지니어에게 지급되는 비용)

대부분의 프로젝트에서 인건비(effort cost)가 가장 많은 비중을 차지한다. 인건비에는 다음과 같은 내용도 포함된다.

* 사무실 임대료, 난방, 조명료 등

* 회계사, 경영사, 청소원같은 지원인력의 비용

* 네트워킹 통신 비용

* 도서실, 오락실 같은 기본 시설비

* 연금, 의료보험과 같은 사회 보장 비용과 종업원 연금

이러한 총 경비는 소프트웨어 엔지니어들의 급여의 최소한 2배이다. 프로젝트 관리자는 비용과 일정의 추정치들을 정기적으로 갱신해야 한다. 

# Experience based approaches

관리자가 과거 경험한 프로젝트 및 응용 분야를 바탕으로 추정한다. 단순한 경험이 아니라 문서화, DB화가 되어 있기 때문에 가능하다.

# Algorithmic cost modeling

제품이 갖춰야 하는 속성에 기초하여 프로젝트 수행에 필요한 effort를 공식을 통해 추정한다.

소프트웨어 비용 산정을 위한 가장 일반적인 형태의 알고리즘 비용 산정 모델은 다음과 같이 표현될 수 있다.

A는 조직의 지역적인 실무 경험과 개발되는 소프트웨어의 유형에 좌우되는 상수 인자이다. 신생기업이면 A를 높인다.

B는 대게 1과 1.5 사이에 있다. 

M은 소프트웨에 관한 정확성, 요구사항과 개발팀의 경험과 같은 프로세스, 제품 그리고 개발 속성들을 결합하여 만든 것이다. (기능만으로 1만라인과 성능 보안이 추가된 1만라인은 다른 것이기 때문에 이 값이 조정된다)

Size는 코드의 크기이다. (10line과 20line은 2배의 gap이 있다. 하지만 20line과 2만line은 1만배인가? 아니다. 관계 복잡성을 고려해야 한다.)

# COCOMO 모델

코코모 모델은 매우 많은 소프트웨어 프로젝트로부터 데이터를 수집하여 유도된 실험 모델이다. 

서브모델중 가장 정확한 모델은 Post-architecture model (포트스 아키텍쳐 모델)이다.

B의 값은 프로젝트 복잡도 수주노가 관련된다. 프로젝트가 더욱 복잡해짐에 따라, 시스템 크기의 증가는 더욱 큰 영향을 미치게 된다. 

1) 조직이 이러한 유형의 프로젝트에 대한 예전의 경험이 있음을 나타낸다. 낮음은 예전의 경험이 없다는 것이다.

2) 개발 과정에서의 융통성의 정도를 나타낸다. 매우 낮음의 의미는 사전에 기술한 프로세스가 이용된다는 것이고 극히 높음은 고객이 일반적인 목표만을 설정했다는 것이다.

3) 시행된 위험 분석의 정도를 나타낸다. 매우 낮음은 분석이 없음을 나타내고 극히 높음은 완전하고 철저한 분석을 의미한다.

4) 개발팀이 서로를 얼마나 잘 알고 함께 일하는가를 나타낸다. 매우 낮음은 상호작용이 전혀 없음을 의미하고 극히 높음은 의사소통 문제가 없는 효율적인 팀을 의미한다.

5) 조직의 프로세스 성숙도를 나타낸다.