05. 프로젝트 계획

소프트웨어공학에서의 계획

• K) 체계적인 계획을 세우는 방법, 개발 비용 산정, 기능 점수 방법, 프로젝트 일정, 위험 분석 방법
• 프로젝트의 목표를 달성하기 위해 자원, 일정 계획, 구성원 등 프로젝트의 모든 활동을 구체화한 청사진이다.
• 프로젝트 실행의 지침(guide)과 같다.

 

계획 이전

• 발주자(프로젝트를 진행하고자 하는 사람): 제안요청서(RFP)를 작성하여 개발 업체에 제시한다. 이를 입찰 공고라고 한다.
• 후보 개발업체: 제안요청서를 기초로 개발 계획이 담긴 제안서를 제출한다
• 발주자: 개발 회사를 선정하고 발주자-개발회사의 계약을 진행한다
• 일반적으로 국제적 대형 프로젝트는 IEEE 국제 표준 규격에 따라 일을 진행한다.

계획 단계

• 계약 체결: 프로젝트 헌장이 공식 승인이다. 프로젝트가 공식적으로 시작되면 프로젝트 헌장에 정보가 기록되고 승인된다.
• 계획 단계는 시작 승인을 받아 프로젝트 실행을 원활하게 하기 위해 전략을 세우고 문서화하는 과정이다. 프로젝트 관리자(PM)을 중심으로 계획을 수립하고 범위, 비용, 일정을 개발한다.

 

1. 개발 계획

• 비용, 기간, 자원을 계획해야한다.
• 계획없이 개발을 하면 일정 지연, 비용 초과, 품질 저하 등의 유지보수 비용이 증가한다.

2. 문제 정의 (목표) (정하면 범위가 알아서 나뉘어짐)

• 개발의 첫 작업이다.
• 무엇을 개발할 것인지, 어디까지 개발할 것인지 결정한다.
• 이것을 프로젝트의 초기 타당성과 초기 계획을 작성할때 기초로 활용한다.
• 문제 정의를 하려면 개발하려는 영역에 대한 배경 지식이 필요하다.
• 문제를 파악하기 위해 현재 운영중인 시스템을 사용해본다.
• 실무 담당자와 만나 자료를 수집, 분석한다.

3. 타당성 분석

• 경제적 타당성
  : 경영자는 투자 효율성에 관심을 가짐
    분석가는 투자대비 효과를 검토하여 경영자에게 정보 제공
    시장을 분석하여 시장성을 확인하고 개발 여부를 판단함
• 기술적 타당성
  : 현재 기술로 요구 기능을 구현할 수 있는지 확인
    하드웨어 성능이 괜찮은지 확인
    개발자의 기술력이 문제 없는지 확인
• 법적 타당성
  : 개발용 도구 사용이 법적으로 문제가 없는지 확인
    지적 소유권, 프로그램 보호법이 강화되었으므로 법적인 문제 검토

4. 개발비용 산정

• 소프트웨어는 전자제품 생산, 건축에 비해 개발 비용을 예측하기 힘들다.
• 결과물이 눈에 보이지 않고, 인력 중심이기 때문이다. 
• 개발자의 능력에 따라 기간과 품질에 영향이 가기 때문이다.
• 개발 프로세스가 다양하여 표준화, 자동화가 어렵고 따라서 생산성과 품질이 다양하다.
• 프로그램 자질(프로그래머 실력), 소프트웨어 복잡도(배경지식 필요), 소프트웨어 규모, 가용 시간, 신뢰도 수준, 기술 수준(고급언어)이 개발 비용에 영향을 미친다.

 

 

개발비용 산정 비법에는 세가지가 있다.

• 하향식 산정 기법
  : 큰 부분을 보고 대충 비용 산정을 하고 세부적으로 그 비용을 나누는 기법이다.
    전문가 판단 기법과 델파이 기법이 있다.
  
  전문가 판단 기법은 전문가에게 개발 비용 산정을 맡기는 것으로, 비과학적이나 신뢰성이 높아 많이 사용된다. 주로 빨리 개발비를 산정해야하는 경우에 많이 사용된다. 수학적 계산 방법보다 경험에만 의존할 경우 부정확하다는 단점이 있다. 이를 보완한 것이 델파이 기법이다.
  델파이 기법은 여러명의 전문가가 비용 산정을 하면 조정자가 그 의견을 낭독한다. 조정자는 중재자 역할을 하는 사람으로, 한명이다. 전문가 의견이 일치하면 비용을 결정하고, 그렇지 않다면 다시 여러명의 전문가가 비용을 산정한다.
  
  
• 상향식 산정 기법
  : 세부 작업 단위별로 비용을 산정한 후 전체 비용을 합산하는 기법이다. 이 방법 역시 경험에만 의존할 경우 부적합할 수 있다. 원시 코드 라인 수(LOC) 기법과 개발 단계별 노력(effort per task) 기법이 있다.
  
  원시 코드 라인 수 기법은 코드가 몇 라인으로 되어있는지 세는 것으로, 비관치(최대), 낙관치(최소), 중간치(보통)을 측정한 후 예측치를 구해 M/M과 비용을 산정한다. M/M은 man/month, 즉 한달에 몇명이 투입되는가를 나타낸다. 하지만 실제 소프트웨어 개발에서는 코딩뿐만 아니라 요구 분석과 설계 과정에서도 많은 인력과 자원이 필요하다. 특히 운영체제, 하드웨어 부분이라면. 그래서 이를 보완한 것이 계발 단계별 노력 기법이다.
  개발 단계별 노력 기법은 개발 생명주기의 각 단계별로 노력(M/M)을 산정한다. 코딩만 보고 산정하는 LOC보단 정확하다.

 

• 수학적 산정 기법
  : 상향식 비용 산정 기법에 속한다. 경험적 추정 기법, 실험적 추정 기법이라고도 불린다.
   COCOMO 방법, Putnam 방법, 기능 점수(FP, function point) 산정 방법이 있다.
  
  COCOMO 방법은 세단계로 나뉜다.
  1) 가중치 반영하기: LOC를 추정한 후 소프트웨어 유형에 따라 비용 산정 공식에 대입하여 M/M를 산정한다. 실시간 처리, 제어가 필요한 시스템 프로그램이 가장 난이도가 높기 때문에 가중치도 높다. 단순형 < 중간형 < 내장형 순서로 가중치가 높다.
  2) 보정 계수 반영하기: 가중치가 반영된 M/M에 노력 조정 수치(어느정도 노력을 해야하는지)를 반영하여 P/M을 계산한다. P/M은 Person/Month는 M/M과 비슷한 건데, 단위를 그렇게 자세하게 알 필요는 없다.
  3) 총 개발 기간 산정하기: 계산된 P/M에 동일 상수를 적용하여 총 개발 기간을 산정한다.
  
  Putnam 방법은 주로 대형 프로젝트에 사용되고, 노력의 분포를 가정하는 방법이다. 별로 안 중요하므로 의미만 알면 된다.
  
  기능 점수 산정 방법은 기능(입출력, 데이터베이스 테이블, 인터페이스, 조회 등)을 중심으로 점수를 구하여 비용을 산정한다. 라인 수와 무관하게 기능이 많으면 복잡하다고 판단한다. 사용자 입장에서 소프트웨어의 기능을 정량화하여 개발 비용을 산정하는 것이다. 기능 점수란, 소프트웨어 기능의 크기를 측정하는 단위이다. 즉, 소프트웨어의 기능이 얼마나 복잡한가를 상대적인 점수로 표현하는 것이다. ex) 정부에서 프로젝트 RFP를 낼 때
  
  이 방법을 사용하면 사용자의 요구 사항만으로 기능을 추출하여 측정할 수 있다.(실제 구현 방법과 무관) 또한 객관적인 요구 사항만으로 측정이 가능하고 계획 단계뿐만 아니라 분석, 설계, 구현 단계에서도 사용 가능하다. 하지만, 목표를 보고 어떤 기능이 필요할지 뽑아내는 높은 분석 능력이 필요하고 기능 점수 전문가도 필요하다. 또한, 내부에서 처리하는 로직이 복잡한 소프트웨어에는 부적합하다는 단점이 있다. 개발 규모를 예측하는 데 적합하다.
  
  소프트웨어 기능은 데이터 기능, 트랜잭션 기능으로 나뉘고 데이터 기능은 내부 논리파일, 외부 연계파일로 나뉜다. 트랙잭션 기능은 외부 입력, 외부 출력, 외부 조회로 나뉘는데 외부는 사람이 될 수도 있고 다른 프로그램일수도 있다.
  
  기능 점수 산정 방법은 두가지로 나뉘는데, 정규 기능 점수법이 간이 기능 점수법에 비해 더 정확하다. 설계 단계 이후에 사용하면 좋다. 기능 도출 -> 유형별 복잡도 계산 -> 기능 점수 산정의 과정을 거친다. 간이 기능 점수법은 기획 및 발주 단계에서 사용된다. 기능 도출 -> 평균 복잡도 적용(내부 논리파일, 외부 연계파일, 외부 입력, 외부 출력, 외부 조회에 적용된 복잡도 가중치 평균값) -> 기능 점수 산정의 과정을 거친다. 계획 ppt 53쪽 보기
  
  데이터 기능 점수 계산: 내부 논리 파일의 개수와 외부 연계 파일의 개수를 계산하여 각각의 평균 복잡도(가중치)에 따라 데이터 기능 점수가 결정된다.
  트랜잭션 기능 점수 계산: 트랙잭션 기능에는 입력, 출력, 조회가 있다.
  미조정 기능 점수 계산: 데이터 기능 점수 + 트랜잭션 기능 점수. 단순히 기능적인 요구 사항에 대해서만 계산한 것으로, 여러가지 특성에 대한 고려는 하지 않았다. 
  보정 전 개발 원가 계산: 미조정 기능 점수 * 기능 점수당 단가
  보정 후 기능 점수 계산: 1) 애플리케이션 유형 보정 계수:소프트웨어 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정
                                  2) 규모 보정 계수: 규모에 따라 값을 보정함
                                  3) 언어 보정 계수: 개발 언어에 따른 보정 계수 적용
                                  4) 품질/특성 보정 계수
  
  
  

일정 계획(=스케줄 관리, 해야할 일 나열, 일단 작업이 있어야함)

• 작업 분할 구조도(WBS): 목표를 달성하기 위해 필요한 업무를 세분화하는 작업. 프로젝트 구성 요소들을 계층 구조로 분류하는 것이다. 범위(scope) 관리를 위한 계획서에 작성한다. 사용자와 개발자 간에 의사소통 도구로 사용되며 프로젝트 업부 내역을 가시화한 것이라 관리가 편하다. 또한 팀원의 책임과 역할을 분명히 할 수 있다.
• 작업 패키지: 계층 구조에서 최하위에 있는 항목을 말한다. 최하위 항목을 단위로 간트차트를 작성한다.
• 네트워크 차트: WBS를 보고 CPM network 일정을 작성한다. WBS의 작업 순서, 소요 시간등을 네트워크 형태의 그래프로 표현한 후 중점 관리해야하는 작업을 명확히하는 데 사용한다.
  1) CPM 네트워크를 그린다
  2) ES값을 구한다 (ES: 해당 작업을 시작할 수 있는 가장 빠른 시점)
  3) EF값을 구한다 (EF: ES로 시작했을때 가장 빠른 완료 시간. 즉, ES+작업 소요 시간)
  4) LS값을 구한다 (LS: 가장 늦게 시작할 수 있는 시간. 역순으로 봐야함)
  5) LF값을 구한다 (LF: LS에 시작해 작업을 완료한 시간, 즉 LS+작업 소요 시간)
  6) ST값을 구한다 (ST: 여유 시간. 여유시간 없는 애들이 늦어지면 전체 일정에 문제가 생기기때문)
  7) 임계 경로를 구한다 (critical path, 전체 프로젝트 일정을 마감하는 데 중요한 것들. 여유시간이 0인 애들)