[소프트웨어공학] 2. Planning

📖 Project Planning

 

 Project Planning

 

- 프로젝트 계획에는 작업을 여러 부분으로 나누어 프로젝트 팀 구성원에게 할당하고, 발생할 수 있는 문제를 예상하고 해당 문제에 대한 잠정적 해결 방안을 준비하는 작업이 포함됨.

- 프로젝트 시작 시 생성된 프로젝트 계획은 프로젝트가 어떻게 진행될 것인가를 프로젝트 팀과 고객이 소통할 때, 프로젝트 진행 상황을 평가할 때 사용

 

 

 Planning stages

 

1. 제안 단계

 - 소프트웨어 시스템을 개발 혹은 공급하는 계약을 얻기 위해 입찰할 때

ex) 어떠한 프로젝트 / sw 를 만들고 싶다 제안할 때

 

2. 프로젝트 시작 단계 동안

 - 누가 프로젝트에서 일할 것인지, 프로젝트를 어떻게 작업들로 나눌 것인지, 자원을 어떻게 할당할 것인지에 대한 계획 수립

 

3. 프로젝트 내내 주기적으로

 - 개발하는 동안 얻은 경험과 새로운 정보를 반영하여 계획을 수정

 

 

 Proposal planning

 

 - 소프트웨어에 대한 완전한 요구사항이 없으므로 계획 필요

 - 제안 단계에서의 계획 목적은 고객에게 시스템의 가격을 책정하는데 사용될 정보 제공 (for 고객과의 소통)

 

 

 Software Pricing

 

💡 Software Pricing

 - 개발자가 소프트웨어 시스템 만들기 위해 필요한 비용 파악 위해 소프트웨어 가격 추정해야함

  + 하드웨어, 소프트웨어, 출장, 교육 및 노력 비용 고려

 - 개발 비용과 고객에게 청구되는 가격의 관계는 단순하지 않음 (개발비용이 늘어난 만큼 고객 청구 가격이 올라가는 건 아닌..?)

 - 조직적, 경제적, 정치적, 비즈니스적 고려 사항이 폭넓게 고려되어야 함

 

💡Factors affecting software pricing (Factor: Description) 

  - 시장 기회: 소프트웨어 시장의 새로운 영역에 진입하기 위해 가격을 낮게 책정할 수 있음. 한 프로젝트에서 낮은 이윤을 수용하면 나중에 더 많은 이윤에 대한 기회를 조직에게 제공 가능. 얻어진 경험들도 새 제품 개발에 도움

 

  - 계약 조건: 어떤 고객은 개발자가 소스 코드에 대한 소유권을 보유하고 그것을 다른 프로젝트에 재사용하는 것을 허용하고 싶을 수 있다. 그러면 책정되는 가격은 개발자에 대한 소스 코드 가치를 반영하여 낮아질 수 있다. 

  ex) 고객 A가 개발자에게 소스 코드 소유권을 주겠다고 함. 그러면 그 개발자는 해당 소스 코드를 다른 프로젝트나 고객에게 재사용할 수 있음. 개발자는 같은 코드를 앞으로 여러 프로젝트에 재사용하여 또 이득을 낼 수 있기 때문에, 이번 프로젝트에서는 가격을 낮춰줄 수 있음. 

 

 - 요구사항 변동성: 요구사항이 변경될 것 같으면 조직은 계약을 수주하기 위해 가격을 낮출 것. 계약을 수주한 이후에는 요구사항 변경에 대한 높은 가격을 부과할 수 있다. 즉 출시는 저렴하게 하고, 나중에 변동되는 요구사항에 따라 요금 부과

 

 - 재정 건정성: 재정적 문제를 가진 기업들은 계약을 수주하기 위해 가격을 낮게 책정할 수 있음. 폐업보다는 적은 이윤. 어려운 경제 상황에서는 이윤보다 현금 유동성이 더 중요. 

 

- 비용 추정의 불확실성: 조직이 자신의 비용 추정에 대해 확신하지 못한다면, 비상 상황에 대비해 정상적인 이윤보다 높게 가격을 책정할 수 있음.

 

 

 Plan-driven development

 

- 계획 주도 혹은 계획 기반 개발은 개발 프로세스가 상세하게 계획된 소프트웨어 공학 접근법

 + 계획 주도 개발은 소프트웨어 공학 관리 기법을 기반으로 하여 대형 소프트웨어 개발 프로젝트의 '전통적인' 방식

- 프로젝트 계획은 수행될 작업들, 담당할 사람들, 개발 일정, 작업 산출물을 기록하는 것

- 관리자들은 프로젝트 의사 결정을 지원하고 진행 상황을 측정하는 수단으로 계획 사용

 

💡Plan-driven development - 장점과 단점

 - 장점: 초기의 계획 수립이 조직의 이슈들(투입 가능 직원, 다른 프로젝트)을 고려할 수 있게 함. 잠재적인 문제들과 종속성들이 프로젝트 진행 중일 때가 아닌 프로젝트 시작 전 발견됨

 - 단점: 소프트웨어 개발/사용 환경 변화 때문에 많은 초기의 결정들을 수정해야함.

 

 

 Project plans

 

- 계획 주도 개발 프로젝트의 프로젝트 계획은 작업을 수행하기 위해 이용 가능한 자원, 작업 분할, 일정을 설정해야함. 

- 계획 상세: 소개, 프로젝트 조직, 리스크 분석, 하드웨어와 소프트웨어 자원 요구사항, 작업 분할, 프로젝트 일정, 모니터링 및 보고 기법

 

💡 Project plan supplements (Plan: Description)

 - 품질 계획: 사용될 품질 절차와 표준 서술

 - 검증 계획: 시스템 검증을 위해 사용될 접근법, 자원, 일정 서술

 - 형상 관리 계획: 사용되는 형상 관리 절차와 구조들 서술

  ex) 소스 코드 버전 관리 어떻게 할건지? -> github

 - 유지보수 계획: 유지보수 요구사항, 비용, 노력 예측

 - 인력 개발 계획: 팀 구성원의 기술과 경험을 개발할 방법 기술 ex) 세미나, 학회...

 

 

 The planning process

 

 - 프로젝트 계획 수립은 프로젝트 시작 단계에서 최초의 프로젝트 계획을 만들 때 사작하는 반복적인 프로세스

 - 계획 변경은 필연적

  + 프로젝트 동안 더 많은 정보를 얻게 되면서 요구사항, 일정, 리스크 변경 등을 반영하기 위해 정기적으로 계획 갱신해야함

  + 비즈니스 목표를 변경하면 계획도 변경됨. 다시 계획을 세워야 할 수도.

 

 

 Project scheduling

 

- 프로세스 일정 관리(scheduling)는 프로젝트 내용을 분리된 작업들로 구성하는 방법. 각각의 작업이 실행되는 시기와 방법을 결정

- 각 작업을 완료하는데 필요한 시간과 노력 추정, 작업을 수행할 인원 예상

- 각 작업을 완료하는데 필요한 자원들(디스크 공간, HW 확보하는 동안의 시간, 출장 예산)도 생각해야함

 

💡Project scheduling activities

 - 프로젝트 관련 총 업무를 분리된 작업으로 나누고, 각 작업을 완료하는데 필요한 시간과 자원 추정하는 것

 - 작업을 병행적으로 구성하여 인력 최적 활용

 - 지연 방지를 위해 작업들 간 종속성 최소화 (A 끝나고 B 이런 관계 최소화)

 - 프로젝트 관리자의 경험과 상식에 의존

 

💡Milestones and deliverables

 - Milestones: 테스트를 위한 시스템 인계와 같이 진행 상황을 평가할 수 있는 일종의 지점

 - Delieverables: 고객에게 전달되는 작업 산출물 

  ex) 시스템 요구사항 문서

 

 

💡The project scheduling process

 

 

- 요구사항과 설계 정보 -> 해야할 일 정의 -> 종속성 확인 -> 자원 추정 -> 사람 할당 -> 프로젝트 차트 생성  -> 프로젝트 스케줄 설명 바차트

 

💡 Scheduling problems

 - 문제 난이도와 그에 따른 솔루션 개발 비용을 추정하는 것은 어려움

 - 생산성은 작업 수행 인원 수에 비례하지 않음

  ex) 고급 개발자 5명이 초급 개발자 10명보다 낫다.

 - 늦은 프로젝트에 사람을 추가하면 커뮤니케이션 오버헤드로 인해 더 늦어짐

  ex) 새로운 내용 가르치는 시간이 더 든다.

 - 예상치 못한 일 항상 발생. 계획에서 항상 비상 상황 예상해야함. 

 

💡 Shedule representation

 - 일반적으로 프로젝트 일정 표현 위해 그래픽 표기법 사용

 - 그래픽 표기법은 프로젝트를 작업별로 분류한 것을 보여줌. 이 작업들이 너무 작아선 안됨. 약 1-2주는 소요되도록.

 - 바 차트(간트 차트):  달력 기반으로 일정을 보여줌

working days: 5

 

 - 액티비티 차트: 작업 종속성과 임계 경로(critical path)를 보여줌. 임계 경로란 액티비티 그래프에서 가장 긴 긴 경로를 고려함으로써 프로젝트를 완료하는데 필요한 최소 시간을 추정할 수 있음. 

 

T - task (해야할 작업), M - output (산출물)

 

💡 Tasks, durations, and dependencies

이 자료로 바차트와 액티비티 차트를 그림. person-days는 하루에 투입해야하는 사람 수를 의미한다. 

 

 

 

💡 Staff allocation chart

 - 작업에 누구를 투입할 것인지에 대한 차트

 

 

📖 Cost Estimation

 

 Estimate uncertainty

 

 

과정이 나아갈수록 추정 불확실성이 낮아진다는 의미? 

 

 

 Estimation techniques

 

 조직은 소프트웨어 노력과 비용 추정을 해야함

 

💡 비용 추정에 사용 가능한 기술 두가지

  - 경험 기반 기법: 관리자의 과거 프로젝트 경험과 애플린케이션 도메인을 근거로 노력 요구사항에 대한 추정을 함. 관리자는 노력 요구사항이 미래에 어떻게 될 것일까에 대한 정보에 근거한 판단을 함.

  - 알고리즘 비용 모델: 노력 추정을 위해 제품 속성 추정치, 프로세스 특성, 참여한 직원들의 경험을 근거(투입되는 사람들의 특성)로 하는 공식적 접근법 사용. 경험보다는 객관적으로 (대기업이 자주 사용)

 

=> 두가지 방법 모두 주관을 반영하긴 함

 

💡 경험 기반 기법

 - 과거 프로젝트의 경험과 이러한 프로젝트에서 sw 개발 활동에 들인 노력에 기반한 판단에 의존

 - 산출물들과 개발될 sw 컴포넌트 또는 시스템들을 식별

  + 산출물: 고객에게 제공되는 결과물

  + 컴포넌트: sw를 구성하는 개별 모듈, 기능

 - 식별된 결과물을 문서화하고, 개별적으로 추정하여 필요한 총 노력 계산

 - 기술이 변화하면 이전 추정 경험이 도움이 되지 않을 수도 있음

 - 단점 : 프로젝트 예산을 정하는데 사용되고, 예산 상의 수치가 실현되도록 제품 조정 (예산에 맞추어 제품 품질 조정)

 

 

💡 알고리즘 비용 모델

 - 프로젝트 크기의 추정치, 개발되는 소프트웨어의 유형, 다른 팀, 프로세스, 제품 요인들을 근거로 하는 수학적 공식 사용

   Effort = A x Size^B X M

   (A: 조직에 종속적인 상수, B: 소프트웨어의 복잡도, M: 제품과 프로세스 및 사람 속성을 반영하는 승수)

 - 비용 추정에 가장 일반적으로 사용하는 제품 속성은 코드 크기

 - 대부분의 모델들이 유사하지만, A,B,M에 대해 다른 값을 가짐

 

 

 Estimation accuracy

 

 - 소프트웨어 시스템의 크기는 완성되어야 정확하게 알 수 있음

 - 최종 크기에 영향을 미치는 요소 -> COTS와 컴포넌트의 사용, 프로그래밍 언어

  *COTS: 상용 기성 소프트웨어. 맞춤 개발 없이 이미 개발된 상태로 판매되는 소프트웨어. 모듈 사서 API 호출하여 사용

  *컴포넌트: 외부 혹은 이전에 사용한 컴포넌트

 - 개발 프로세스가 진행됨에 따라 크기 추정치가 더 정확해짐

 -  M과 M에 기여하는 요인들의 추정치는 주관적, 추정자의 판단에 따라 달라짐

 

💡 Size related measures

1. 코드 라인(LOC)

 - 시스템의 크기와 문서의 양 사이에 선형 관계 가정

 - 동일 기능 구현시 low level 언어에서 더 많은 코드 필요

 - 코드 라인으로 생산성 측정을 하는 것은 장황한 코드를 작성하는 프로그래머가 더 생산적임을 시사

  -> 간결하게 더 잘 작성한 코드가 있을 수 있어 오판단 가능성이 있음

 

2. 기능 점수(Function-points)

 - 프로그램 특성의 조합 기반 (4가지 특성 이용하여 FP 계산)

  * 외부 입출력, 사용자 상호작용, 외부 인터페이스, 시스템에서 사용하는 파일

 - 각 유형 요소에 연관된 가중치 존재.

 - UFP 계산

 

 - 기술 복잡도 항목(TCF) 계산 (UFP에 곱해주어 보정)

 - 14가지 기술적 요소를 평가하고, 각 요소에 0~5 사이 점수를 부여함

DI: 영향도

 - UFP와 TCF로 FP 계산

 

 - 코드 크기 = AVC x FP

 * AVC: 평균 코드 줄 수(Average number of lines of code, AVC)

 *AVC value: 어셈블리 언어 (2-300 LOC/FP), 데이터베이스 프로그래밍 SQL (2-40 LOC/FP)

 

 

 Algorithmic cost modeling: The COCOMO model

 

- 프로젝트 경험에 기반한 실증적 모델

 - 문서화 잘 돼있으며, 특정 소프트웨어 업체와 관계없이 '독립적' 모델

 - 1981년 초기 버전 "COCOMO-81"부터 다양한 인스턴스화 거쳐 COCOMO 2까지 오랜 역사

 - COCOMO 2는 소프트웨어 개발, 재사용에 대한 다양한 접근 방식 고려

 

💡 COCOMO 2 models

 - 소프트웨어 개발에 대한 현대적 접근법들에 근거하여 더 자세한 추정치를 생성하는 여러 서브 모델 포함

 - COCOMO 2 서브 모델

  ① 애플리케이션 결합 모델: 기존 컴포넌트 이용(재사용)하여 소프트웨어 구성할 때 사용

  ② 초기 설계 모델: 요구사항이 도출된 이후 시스템 설계 초기 단계동안 사용

  ③ 재사용 모델: 재사용 가능 구성 요소를 통합하는 노력을 계산할 때 사용

  ④ 포스트 아키텍처 모델: 시스템 아키텍처가 설계되고, 시스템에 대한 추가 정보가 제공되면 사용

 

💡 COCOMO 2 model - 초기 설계 모델 (Early design model)

  - 요구사항이 동의된 후 만들어지는 추정

  - 거의 COCOMO-81 모델 활용

 

PM: Person Month

 

  - Multipliers는 개발자, 비기능 요구사항, 플랫폼 개발에 대한 친숙함을 반영함

 

 

💡 COCOMO 81

  - 개발 노력을 측정 (한 달마다 한 사람의)

   * KDSI product 길이 측정 (1KDSI: 1,000 LOC)

   * product의 개발 모드 결정 (개발 어려움의 level) : simple mode(작고 간단), moderate mode(보통), embedded mode(복잡)

  - Nominal effort 계산

 

  - Development effort = Nominal effort x M

 

 - SW 만드는데 10KDSI, moderate mode

  => Nomial effort = 3.0*(10)^1.12 = 39.54

       Development Effort Multiplier M (EM 노력 승수)= 1.35

       Development effort = 39.54 * 1.35 = 53.379 ≒ 53 PM (person-month)

 

∴ 이 결과를 가진 프로젝트에 사람 6명을 투입하면 9개월짜리 프로젝트가 됨(1인이 100% 전념한다 가정). 만약 6명의 월급이 총 3000이면 9개월짜리니, 3000*9 = 27,000 -> 2억 7000만원 비용이 드는 프로젝트임.