소프트웨어 공학 (13), Project planning

Project planning

---

0. Overview

1) Project Planning

- 돈을 받고 다른 사람에게 소프트웨어를 판매하는 것과 plan-based approach를 통해 개발하는 것을 가정해 이번 챕터를 설명하고자 한다.

- 돈을 받고 소프트웨어를 짠다는 것은 Project planning, Quality management, Configuration management에 대한 내용은 매우 중요하다. Agile 개발 프로세스를 따른다면 위의 내용을 하는 것에 큰 의미를 두지 않을 수 있다. 그렇다하더라도 이를 반영해 스스로 점검할 수 있는 부분이 존재한다.

- 제조 중심의 회사들이 소프트웨어에 적용하려고 했지만 실패했던 Man-Month 신화와 같이 돈을 받고 수직적인 구조 속에서 소프트웨어 개발을 하는 회사에서 개발할 때에는 필요한 내용이 된다. 

- 소프트웨어 개발을 위한 사람, 자원 등이 필요하다.

- 소프트웨어를 개발하기 위해 어떤 일이 일어나야하는지 잘게 쪼개야한다. 이를 어떤 사람에 할당할 것인지 파악하고, 그 사람이 얼마만큼 해야하는지 정해야한다. 만약 사람이 없다면 사람들이 얼만큼 필요한지 예측해야한다.

- 계획 중에 고려해야할 위험 요소들을 예측해서 이를 중요도에 따라 분류/정리한다.

- 위험 요소들을 예측하고, 대응 방법도 고려해야한다.

- 문제가 없다면 돈이 쌓일 것이고, 리스크가 많아진다면 사람과 자원 등 소모되는 것이 매우 많아지기에 미리 계획해야한다.

- 결국 사전에 자원/인력/환경 등을 계획해야한다. 이에 따라 얼만큼 비용이 소모되는지 커뮤니케이션의 자료로 사용된다. 결국 이는 대내외적인 사람들과 대화하는 수단이 된다.

- 이후 계획에 따라서 프로젝트를 진행하고, 계약이 이루어지거나 체크하는 작업이 된다.

- 규모가 큰 곳으로 가면 PL(Project Leader)이 따로 있어서 프로젝트를 관리하는 그룹이 있는 경우도 있고, 회사 내부적으로 agile에 익숙하다면 개발자 각각이 이러한 역할을 하는 곳이 있다.

2) Planning stages

- planning은 한번만 세우고 끝나지 않는다. 가지고 있는 정보의 양과 질, 더불어서 커뮤니케이션을 해야하는 대상이 단계별로 다르기에 여러 번에 걸쳐서 일어난다.

(1) Proposal stage

- 프로젝트를 제안하는 단계

- 고객에게 어떤 일을 해야하고, 소요되는 자원/사람/시간 등에 대해 설명한다.

- 당신이 요구하는 소프트웨어를 얼만큼의 가격에 제공할 수 있는지, 가격과 기간 등에 대해 설명하는 단계가 된다.

 

(2) Project startup phase

- 프로젝트 이후에는 프로젝트에 관련된 세부적인 내용들을 정하는 단계

- 고객으로부터 돈을 받았기에 해야할 일을 정의하고 이것들이 단계별로 이뤄질 것이다. 

- 이는 sprial 모델로 해서, 정해진 일을 어떤 우선순위에 맞춰서 진행할지 정해야한다.

- 이후 개발자를 투입해서 얼만큼의 기간동안 누가 맡아서 진행할 것인지 정한다.

 

(3) Periodically throughout the project

- 일이 잘 진행되지 않을 수도 있지만 비용, 사람, 기간은 맞춰야한다. 즉, 계획대로 일이 잘 굴러갈 수 있도록 끊임없이 모니터링해야하고, 예측된 문제가 발생한다면 이를 해결하면서 진행해야한다.

 

 

3) Proposal planning

- 고객에게 돈을 받고 소프트웨어를 납품하는 것이기에 비용 산출이 중요하다. 돈을 주고 소프트웨어를 개발하는 것은 수의게약을 하기도 하지만 경쟁방식으로 진행하는 경우가 대부분이다. 

- 돈을 가지고 있는 사람이 내부적으로 한계가 있으니 감당가능한 비용을 대부분 공표하고 개발사는 요구사항을 만족해서 이를 납품하고자 한다.

- Agile도 이러한 방식을 하긴하지만 사람에 더 초점을 맞추기에 살짝 다른 면이 있다. 

- 고객을 처음 만나서 요구사항을 받는 것이기에 대부분의 회사들이 돈과 요구사항을 제시한다. 이를 고객이 스스로 작성해서 문서화한다. 즉, 고객이 미리 작성한 요구사항과 허용가능한 최대 가격, 데드라인을 기반으로 해서 계획을 만들고 나름의 가격을 정하게된다.

- 소프트웨어 개발 비용이 들어가고, 전문적으로 프로그램을 만드는 사람에 대한 비용과, 별도의 간접비, 필요한 소프트웨어 등등도 비용에 포함된다.

 

- 고객이 처음 제시한 요구사항을 시스템에 관해서 더 디테일하게 조절하는 과정이 수반된다. 이에 따라 더 디테일한 요구사항이 만들어지고 이후 프로젝트를 시작하는 플랜을 세운다.

- 돈과 어떤 사람이 투입될지에 대해 즉, 인적/물적 자원을 어떻게 투입할지 정하게 된다.

- 결국 뒷부분에서 과제가 제대로 굴러가는지 보게된다.

- 돈을 받고 작업하는 것이기에 Agile도 유사하게 필요한 과정이다.

- 대부분의 회사에서 고객에게 직접 돈을 받아오는 것은 아니지만 내부적으로 팀원을 받고, 회사 내 자원을 쓰기 위해서 팀장으로서 회사에 proposal 하는 경우가 많다.

 

4) Project startup planning

- Agile인 경우에는 프로젝트 스타트업이 돈에 민감하지는 않지만 분명, 회사에 있는 사람과 돈을 쓰기 때문에 매 sprint마다 이를 산출하는 과정이 유사하게 존재한다.

 

 

5) Development planning

- plann based approach는 정해진 기간에 정해진 결과가 나와야한다. 이에 따라 주기적으로 결과가 나와야한다. 돈과 고객의 시간이 타이트하기에 프로젝트의 일정, 위험, 돈 등에 대한 부분을 조율하며 기간에 맞춰 소프트웨어를 개발한다.

- Agile은 sprint를 하면서 이 과정이 녹아있다.

 

---

1. Software pricing

소프트웨어의 가격을 제시하는 법

1) Software Pricing

(1) Overview

- 가격을 매길 때 고려해야하는 사항

- 같은 요구사항에 대해 정해진 최대 기한과, 최대 비용을 매기더라도 경쟁사마다 다른 가격과 기간을 제안할 수 있다.

- 소프트웨어 가격이 왜 이렇게 다를 수 있을지, 누군가에게 개발을 의뢰할 때 정치적인 관점에서 바라볼 수 있다.

- 요구사항이 굉장히 큰 레벨에서 있다.

- 프로젝트를 진행할 때 돈을 준다면 사람에 대한 비용을 계산하는 것이 매우 많은 비중을 차지한다. 

- 교육비, 여행, 사무용품, 하드웨어 비용 등등 매겨진다.

- 소프트웨어 가격은 누가 개발하고, 왜 개발하냐에 따라 달라질 수 있다. 비록 기술적으로 요구사항을 정의하고 합리적인 기간과 비용을 설정하더라도 돈을 받아서 개발하고자하는 조직, 회사 등이 조직적/경제적/정치적/비즈니스적인 이유에 의해 가격은 변동될 수 있다.

- 필요로 하는 요구사항 기간에 딱 맞는 비용을 산출하는 경우가 많지는 없고, 리스크에 대해 고려해서 비용을 산출하는 것이 중요하다. 

 

2) Factors affecting software pricing

(1) Contractual terms

- 소스코드를 개발사가 보유하며 다른 프로젝트를 할 때에도 이를 쓸 수 있게 소스코드의 소유권을 인정해준다면 가격은 저렴해질 수 있다. 즉, 소스코드의 소유권에 따라 금액은 달라질 수 있다.

 

(2) Cost estimate uncertainty

- 요구사항이 모호하거나 신생업체의 경우 소프트웨어 금액 산정이 모호할 수 있기에 비용이 증가하거나 낮아질 수 있다. 조직이 계산 산출에 서투르거나 리스크를 놓치면 비용을 내려갈 수 있다. 이때 예측하지 못한 리스크가 발생할 경우에는 소프트웨어 개발을 다시 진행해야할 수도 있다. 따라서 이에 대한 적정선을 지켜야한다.

 

(3) Financial health

- 개발자의 회사의 재무가 부실한 경우에는 수주를 따야하기에 가격을 낮추는 경우가 많다. 하지만 개발 가능한 회사가 자사 밖에 없다면 가격을 올릴수도 있다.

 

(4) Market opportunity

- 새로운 시장에 진입하고 싶은 신생회사나 들어오고자하는 기존회사는 첫번째 계약이 있어야지 계약을 이을 수 있다. 즉, 초도 계약이 매우 중요하다. 이에 따라 처음 계약을 수주하기 위해서 수익이 거의 없거나 적자를 감수하며 시장에 들어오는 기회가 많다. 하지만 적자를 내는 회사에 대해서는 A급 엔지니어를 투입하지 않을 수 있다. 이에 따라 인적자원을 투입하는지 확인할 필요가 있다.

 

(5) Requirements volatility

- 요구사항의 불안정성(휘발성)으로 요구사항이 변할 수 있는데 소프트웨어 개발 기간이 긴 소프트웨어는 반드시 변할수밖에 없다. 이를 수주하는 개발자 입장에서 요구사항이 바뀌거나 늘어나면 돈을 많이 받겠다고 제안한다. 이때 요구사항을 너무 방만하게, 너무 단기간에 대한 예측으로 제안한 경우에는 비용이 증가할 수 밖에 없다.

- 가격이 처음에는 낮지만 이후에는 늘어날 수도 있다.

- 요구사항을 자주 바꾸는 경우에는 이번 소프트웨어 개발 비용도 늘어날 수 있지만 이후에도 늘어날 수 있다.

 

 

3) Pricing strategies

(1) Under pricing

- 새로운 시장에 진입하기 위해 가격을 낮추는 경우나 미래에 대한 이익을 위해 회사 조직원 유지를 위해 가격을 낮추는 경우가 존재한다.

 

(2) Increased pricing

- 일반적으로는 가격을 높일 수밖에 없다. 처음엔 낮은 가격을 준 뒤, 추가 요청이 많아진 경우에는 가격을 높히는 경우가 존재한다.

 

 

4) Pricing to win

- 고객들이 믿고 가격을 지불할 수 있도록 이를 산출해야한다.

- 리스크를 고려하지 않을 때 가격이 낮아질 수 있고, 리스크가 발생했을 때 등을 고려해 가격 산출을 진행해야한다.

 

 

---

2. Plan-driven development

1) Plan-driven development

(1) overview

- 기본적으로 plan-based development를 취하고 있는데, 돈을 받고 소프트웨어를 납품하거나 제조업체, 소프트웨어 규모가 큰 조직에서 사용한다.

- 프로젝트 계획이란 어떤 일을 해야하는지, 누가 해야하는지, 어떤 사람을 고용해야하는지, 스케줄은 어떻게 잡아야하는지, 결과물은 어떤 것을 만들어야하는지 정하는 것이다.

- 중간 과정에서 많은 문서가 나올 수 있는데, 실제 개발 과정은 agile이라면 스프린트에 의해 나오는 소프트웨어가 될 것이다. 매니저는 이를 일정 관리에 사용한다. PL 팀에서도 관리할 수 있고, 파트장이 이를 이끌 수 있다.

 

2) Pros and Cons

- 본인이 하는 업무에 대해 적절한 선에서 이를 고려해 조절하는 것이 중요하다.

 

(1) Pros

- 무슨 일을 하던지 계획은 반드시 필요하고, 조직적으로 자원 투입이 필요하기에 이를 확인하기 위한 용도이다. 미리 리스크를 예측해서 고민하는 것은 당연한 일이다. 정도의 차이에 따라 의미가 있을수도 없을수도 있다.

- 장기간에 걸쳐서 만드는 경우 이를 지지할 수 밖에 없다.

 

(2) Cons

- 위의 작업이 소프트웨어 이전에 제조를 만들 때는 굉장히 의미있는 작업들이었지만 소프트웨어와는 살짝 다를 수 있다는 의견이 있을 수 있다.

 

3) Project plans

- 단계별로 어떤 내용이 들어갈지 정하는 것이 중요하다. 

- 리스크는 어떤 점이 있으며, 필요한 하드웨어나 소프트웨어 자원 등을 나열하고 해야할 일을 정한다.

- 일을 사람에 매핑하고, 선후관계나 의존관계 등을 염두해서 스케줄링을 해야한다. 이후 모니터링하고, 리포트하는 작업이 이루어진다.

 

4) Project plan supplements

(1) Configuration managemnet plan

- 개발 도구 툴 등을 통일화하고 관리한다.

 

(2) Deployment plan

- 반드시 들어가야하는 내용일수도 있다.

- 언제까지 배포할지, 제공할지 등 들어가야한다.

 

(3) Maintenance plan

 

(4) Quality plan

 

(5) Validation plan

 

- 결과물을 명확하하는 것이 중요하다.

 

5) The planning process

- 각 단계마다 계획을 하는 것이 중요하다. Agile은 각 스프린트마다 계획을 수정할 수도 있다.

- 계획이 변경되는 것은 항상 있을 수 있다는 것을 인지한다.

- 변경이 발생할 때마다, 주기적으로 변경사항을 찾고, 반영하고 이에 따른 스케줄, 인적 자원, 하드웨어 자원 등을 넣는다.

- 요구사항이 주어진대로만 짜지 않고, 어떤 목적으로 소프트웨어를 성취할 것인지 고민해서 본인 스스로가 소프트웨어를 짜는 목적과 비즈니스 트랜드를 고민하고 제안 및 반영할 수 있도록 해야한다.

 

 

The Project planning process

- 제한요건들을 반드시 확인하고, 리스크를 미리 확인해야한다. 또한 개발 과제가 정상적으로 되었을 때 어느 시점에서 어떤 결과물이 산출되어야하는지 정해야한다.

- 위의 과정들은 고객과 소프트웨어를 만들기 전에 함께 정한다. 이후 디테일한 프로젝트 스케줄을 세운다. 이때 프로젝트 플래너들이 회사 내 다른 팀에서 올수도 있다. 

- 이후 작업을 하고, 모니터링을 한 후 문제가 없다면 프로젝트를 종료하고, 그렇지 않으면 계속 반복할 것이다.

- 프로젝트를 바꿔야할 정도로 심각한 문제가 발생한다면 리스크를 해결하는 것에 초점을 맞추거나 프로젝트 계획을 다시 짜야할 수도 있다. 

 

cf) Planning assumptions

- 초보들이 주로 저지르는 실수 중 리스크를 생각하지 못하고 너무 이상적으로만 짜는 경우가 존재한다. 이는 현실적으로 짜야한다. 즉, 리스크를 고려하지 않거나 인위적으로 긍정적인 일정만 제시하는 경우가 발생할 수 있다.

- 그렇다고 부정적으로 바라볼 것은 아니다.

- 리스크는 발생할 수밖에 없기에 미리 대안을 찾으면 문제가 발생했을 때 대응하기 용이하다.

- 스케줄은 바뀔 수 없기에 문제가 발생하면 관련된 사람들과 논의를 해야한다. 하지만 생각치못한 대형 리스크가 터지면 이는 투명하게 모두에게 공개해야지 관련된 사람들도 파악할 수 있다.

 

Risk mitigation

- 미리 예측해서 최대한 없앨 수 있는 방안을 마련해 투입해야한다.

- 당연히 재계획을 짜야한다면 다시 짜야하고 고객과의 대화가 필요하다면 대화를 해야한다.

 

---

3. Project scheduling

1) Project scheduling

- 잘게 쪼갠 일을 누가하는지, 얼마의 시간이 걸릴지 일 별로 정의한다.

- 테스크별로 투입될 사람, 기간, 인적/물적 자원을 계획하고, 테스크 간에 관계를 통해 결과물을 도출한다.

- 정리된 일들이 있고, 이에 대한 시간, 이를 위해 필요한 리소스가 있으니 이를 하나의 항목으로 가진다. 상호작용이 없으면 독립적으로 이루어질 수 있지만 다른 것들과의 관계가 있다면 이를 고려해야한다. 연관성에 의해 일들의 선후관계를 정의해야하고, 최대한 디팬던시를 줄이는 방향으로 해야한다. 앞의 일이 지연되면 뒤의 일도 지연될 수밖에 없다. 

- 대부분의 일은 선후관계가 있다. 프로젝트를 많이 해본 사람일수록 매번 놓치는 문제나 발생가능한 문제들을 경험적으로 알 수 있다.

 

2) Project scheduling process

- 사람과 자원을 필요할 때에 시작부터 끝날 때까지 스케줄링한 것이다.

- 이를 보기 편하게 그림을 그려서 사용한다. 

- Gant chart를 만드는 것이 스케줄링을 통해 도출해야할 결과물이다.

 

3) Project scheduling problems

- Top down에서의 문제점이 많이 발생한다. 

- 기술적/조직적/인적/환경적인 부분들에 대해 추정하는 것 자체가 힘들다. 

- 소프트웨어 작업인 경우에는 어떤 사람이 몇명이 해야할지 고려하기도 어렵다. 얼만큼의 사람이 필요한지도 고민이다.

- 사람이 로봇은 아니기에 인력을 많이 투입한다고 보장되는 것은 아니다.

- 돌발 상황이 발생할 수 있고, 이를 투명하게 관리해야한다.

 

 

4) schedule presentation

(1) 개요

- Graphical notation: 엑셀이나 MS 프로젝트 등을 사용한다.

 - 스크럼을 할 떄 하나의 스프린트가 다양한 액션 아이템으로 이루어져있는데, 이를 구성하는 액션 아이템은 작아져야한다. 우리가 정의하는 태스크와 액션아이템은 적절한 사이즈(2~4주)를 사용하는 게 좋다.

- 간트차트에서 확인한 것처럼 calendar based로 접근하기에 y축은 통상 시간으로 계산한다.

- 일들 간의 선후관계를 볼 수 있어야한다.

- 어떤 일에 대한 시간, 사람의 수, 무엇이 도출되어야하는지 등을 알아야한다.

 

(2) MileStone and deliverables

- 어떤 날짜에 어떤 결과물이 나오는지 정하는 기준표로 이를 보고 확인할 수 있다.

 

 

(3) Tasks, durations, and dependencies

- 태스크가 나열되고 태스크 별로 인원, 디팬던시가 적혀있고, 데드라인과 딜리버러도 추가할 수 있다.

 

(4) Activity bar chart

- 선후관계도 적혀있다.

- action item 기준으로 적혀있다.

 

(5) staff allocation chart

- 사람에 대한 플래닝이다.

- 플래닝의 결과물은 스케줄표이다.

 

---

4. Agile planning

1) Agile

- 큰그림을 그리기보단 반복적으로 개발을 해서 설계와 개발을 진행한다.

- 스프린트 내부로 들어왔을 때 스크럼을 사용하면 매일매일 결정한다. plan-based와는 달리 매일매일의 scrum, 2 ~ 4주로 이루어지는 functionality를 정한다. 

- 앞선 내용들에 대해 상당히 매칭하기 어렵다.

- Agile은 최소한 몇 달 정도에 해당하는 개발이 이루어지기에 릴리즈에 대한 플래닝이 필요하다. 어느 시점에 어느 소프트웨어가 나와야한다를 나열한다. Release planning. 또한 각각의 스프린트를 뛰는 중 우선 순위에 따라 동작할 Iteration plaaning. -> 아래는 스프린트에 대한 내용이다.

- 한번에 개발을 모두 완료하는 경우는 거의 없다.

- 개발해야할 백로그가 잔뜩 있을 때 스프린트로 쪼개거나 데일리 스크럼을 통해 진행되었는지, 서스팬드 됐는지, 다음에는 뭐해야하는지, 변동 사항이 발생하면 뭐해야하는지 정해야한다.

- XP(extreme Programming): 전통적인 agile 기법으로 유저스토리를 사용하기에 어떤 유저스토리를 먼저 개발해야하는지 미리 정해야한다.

- Agile의 스크립과 다른 부분에 대한 설명

 

2) Story based planning

- 시나리오, usecase와 비슷하게 기능들이 들어가있는 하나의 이야기라고 볼 수 있다.

- 스토리가 완성되면 하나의 시나리오가 펼쳐지는 정도로 이해하는게 중요하다.

- 스토리에는 구현해야하는 피처들이 들어가 있다. 스토리가 풀세트로 구현되면 시스템이 완성된다.

- 어떤 스토리를 구현하는데 얼마의 시간이 걸리고, 어떤 것을 우선개발할 것인가를 정한다.

- 상관관계, 우선순위 등을 고려해 가장 많이 시간이 걸릴 것을 순위에 올린다.

- 얼마나 많은 관심을 기울여하는가 affort point라는 점수를 매긴다. 이를 매겨서 숫자로 표현한다. 시간값을 환산하여 사용한다.

- velocity는 주어진 시간 내에 할 수 있는 일들에 대한 역량, velocity 내에서도 스토리에 대한 숫자, 스토리만큼의 숫자 등을 차감해가면서 사용할 수 있다.

- 스토리의 복잡도 등을 감안해서 만든다. 

- 우리 팀이 주어진 시간 내에 할 수 있는 velocity가 있으니 velocity만큼의 능력 안에서 affort point를 처리해나간다.

 

3) The planning game

- 스토리를 정리해서 개발할 피처 셋을 구한다. 

- 어느 스토리가 얼만큼의 노력이 들어가야할지 포인트를 매기는 작업을 한다.

- 주어진 시간 내에 할 수 있는 능력 안에서 얼만큼 스토리를 구할 수 있는지 환산한다.

- 구현 및 replaning을 반복해서 작업하고, 이를 하나의 스토리 내에 있는 세부적인 피처를 나눠서 누구에게 언제 할당할지 정한다.

- 어떤 스토리들이 상관관계가 있는지 등을 확인하고 작업을 세운다. 이후 구현해야하는 아이템을 정한다. scrum은 7시간 동안 작업할 내용을 플래닝한다.

 

4) Release and iteration planning

- Release planning: 어떤 피처가 스토리 내에서 구현되어야하는지, 하나의 릴리즈 안에서 구현해야하는 스토리가 있고, 얼마만의 에포트가 들어가야하는 지 등 순위를 매긴다.

- 스토리는 이터레이션 작업에 의해 선택되고 구현된다. 스토리는 2~3주 정도 내에 구현할 수 잇는 것을 상정한다. like scrum. 스크럼과 비슷하다.

- 주어진 능력이 제한되어있기에 velocity 내에서 얼만큼 구현할 수 있는지 예측한다.

 

5) task allocation

- 2~3주 정도 분량의 스토리를 구성하는 여러개의 테스크로 구분한다. 하나의 테스크는 4~16시간 정도로 분할될 수 있다.

- 테스크 자체가 누구에게 언제 할당되고, 언제 끝날지에 대한 얘기를 반복적으로 얘기한다. 이에 따라 공감대를 형성할 수 있고, 개발자가 사인업을 하기에 책임감도 가질 수 있다.

 

6) Software delivery

- XP에서 강조하는 부분은 우리가 날짜를 정하고 그 날짜에 대해 마일스톤을 정하면 스케줄을 연장하지 않는다는 점이다. 일정을 뒤로 보내지 않고, 구현을 못하면 다음 페이즈에서 구현을 한다. 

- Agile의 정신이 매일 소프트웨어를 릴리즈하는 것이 이상적이기에 이를 반영한 것이다.

 

7) Agile planning difficulties

- 전통적인 소프트웨어 엔지니어링에서 한 얘기이다.

- Agile은 시장이나 기술의 트렌드를 수시로 반영하고, 개발 과정에서 방향이나 골격을 자유자재로 바꿀 수 있다. 고객의 피드백도 웰컴해야한다. 결국 플랜이 어렵다. 

- 고객이 피드백을 주고, 고객이 생각을 달리하면 일정을 바꿔야한다. 이때 우선순위도 바뀌면 일정을 완전히 바꿀 수 있다.

- 고객이 Agile에 친숙하지 않을 수 있기에 Agile에 맞게 개발 일정이 바뀌었을 때 이에 불편할 수 있다. 하지만 Agile도 마일스톤과 같이 큰 그림은 그린다. 고객은 각각의 release만 맞추면 그다지 얘기하는 경우가 많지 않을 수 있다. 다만 문서가 나오지 않으니 해당 부분에서는 불만이 나올 수 있다. 고객도 scrum 미팅에 참가할 수 있기에 동적인 피드백도 가능하긴하다.

 

8) Agile planning applicability

- 팀인원이 적고 액티베이티브하고, 스스로 동기부여할 수 있는 사람의 경우에는 맞다.

- 규모가 큰 프로젝트, 다양한 회사가 함께 있다면 전체적인 운영은 plan based로 합의하고, 본인 팀으로 들어갔을 때에는 agile을 하는 경우가 많을 것이다.

---

5. Estimation techniques

1) Estimation techniques

- Top-down approach에서 가장 중요한 것은 돈이다.

- 필요한 사람 수, 그들의 능력, 얼마나 투입되는지, 필요한 하드웨어/소프트웨어 자원, 출장비, 교육비 등등을 고려하여 어떤 식으로 비용을 계산하느냐가 중요하다. 

- Algorithmic cost modeling을 하는 것을 지향하고자 하지만 Experience-based techniques를 더 많이 한다.

 

Estimate uncertainty

- 결국 정확하게 추정할 수 있는 것은 구현을 할 때 쯤이다.  언제 비용을 추정하느냐에 따라 불확실성은 달라질 수 있다. 

- Feasibility에 비용을 추산할 경우에는 불확실성이 매우 크다.

 

2) Experience based approaches

- 프로젝트 관리를 하는 것도 굉장히 중요하다. 수많은 경험을 통해 새로운 과제를 산출한다.

- 시간이 흘러서 기술이 일부 바뀌지만 과제는 비슷하게 이루어질 때 경험을 사용하는 것은 가능하다.

- 똑같은 소프트웨어가 아닌 비슷하지만 다른 소프트웨어를 만드는 것이기에 프로젝트 리더가 중심이 되어 관련자들과의 토의를 해서 이를 정한다.

- 똑같은 부분은 가져오고 바뀐 부분에 대해 고려해 비용을 추산한다.

- 처음해보는 경우에는 추정이 틀릴 가능성이 높다. 이러한 경우에는 시행착오를 경험하게 될 것이다.

 

3) Algorithmic cost modeling

- 수학적 공식을 만들려고 노력을 많이 했지만 실제로 이를 반영하기는 어려웠다.

- 입력 파라미터가 존재하고, 금액 산출에서의 요인에서 가장 중요한 부분은 코드의 사이즈이다. 돈을 받을 때 코드 사이즈가 크면 더 많은 돈을 받는다. 이에 따라 갑론을박이 많다. 엉성한 코드가 더 많은 돈을 받을 수 있기에 문제가 많다고 한다.

- 프로그래밍 랭귀지가 서로 다르면 코드 길이도 다르고, 재사용도 고려한다, 분산 시스템인 경우에 코드 사이즈가 다를 수 있다.  이에 따라 이를 고려하기도 한다. 

- 하지만 너무 복잡하고 가정도 많고, 입력 파라미터가 적절하게 맞는지 의문이 들수도 있다.

- 하지만 소프트웨어는 계산 공식대로 나오지도 않는다. 

- 큰 회사들이나 중요한 회사들에서는 모든 것을 고려해야하기에 이를 쓰기도 한다.

 

---

6. COCOMO cost modeling

1) COCOMO cost modeling

- Man-Month와 라인수를 가지고, 얼마나 많은 사람이 얼마나 많은 라인을 가지고 하는지를 고려한다.

- KOSA에서는 소프트웨어 사업 대가 가이드가 있다. 즉, 대한민국에서 갑이 을에게 소프트웨어 개발 의뢰를 하고, 을은 가이드라인에 따라 예산을 수립하고 돈을 요청한다.

- SI 회사나 용역을 받는 회사로 간다면 우리나라에서는 KOSA의 대가 산정 가이드에 의해 주로 비용 산정을 해야한다. 

- 공공분야는 공공의 이익을 위해 한다. 인식 조사를 했는데, 아직도 인력을 기준으로 계산한다. 계산이 쉽기 때문에 그러하다. 이에 따라 을의 입장에서는 비용을 산정할 때는 머리수와 프로그램 크기를 가지고 하는 경우가 많다.

- 소프트웨어 업계에서 Man-Month를 하는 것은 문제가 있지만 이를 개선하기에는 어렵다. 

- 을이 소프트웨어를 짜는 것은 능력에 대한 기준이 적기에 소프트웨어 회사들의 평균 임금은 높지 않다. 본인의 서비스를 하며, 본인이 필요로 하는 부분에 대해 소프트웨어를 짤 때는 돈을 많이 받지만 앞 쪽에서 본 산출 방식을 따르면 돈을 제대로 받기 어렵다는 단점이 있다. 

- 용역을 하는 회사로서 돈을 더 많이 줄 때 이러한 부분들이 이슈가 된다. 

 

요약

- 소프트웨어의 가격을 정하기 위해 플래닝을 했다. 우리가 해야할 일을 언제부터 언제까지 어떤 리소스를 사용하는지에 대한 얘기를 한다. 가격이 중요한 것은 프로젝트 플래닝의 상당수가 누군가로부터 돈을 받아서 개발하기 위해 플래닝을 하는 경우가 많았다. 

- 프로젝트 스케줄링을 하는 것은 워크 아이템을 정해서 언제부터 언제까지 누가 일을 하고, 주요 결과물에 대해 마일스톤을 정한다.

- Agile도 어느정도의 플래닝은 필요했다. Agile을 실제 개발하는 경우가 일반적이라 하더라도 내가 만든 소프트웨어가 독립적으로 돌아간다면 Agile을 쓸 수는 있지만 대규모로 하거나 여러 회사가 참여하면 엄브렐라로 plan based를 정할수밖에 없다.

- estimation에서 정성적/정량적인 접근이 있으며 수학적인 기법에서 COCOMO 기법이 존재한다. 

- 우리나라에서는 소프트웨어 사업 대가산정 가이드라인이 있어서 을이 갑에게 얼만큼 받는지 요청하지만 인력수나 라인수로 이를 판단하기에 논란이 많다. 평균 임금이 높지도 않게 된다.