[소프트웨어공학] 23장 Project planning

-> 누군가 만든 소프트웨어를 고객에게 돈을 받고 제공한다.

-> 고객의 요구를 받아서 개발 후 그 소프트웨어를 고객에게 제공함.

-> 원칙적으로 plan-based를 가정함

-> 에이자일과의 상관관계도 설명을 함

-> 소프트웨어를 납품하는 과정을 배움

-> 소프트웨어공학의 주된 내용 -> 경험과 노하우에 대해서 배우는 것

-> 23,24,25장은 소프트웨어를 돈을 받고 판매하려고 할 때 중요한 부분을 차지함

-> man-month가 나온 것처럼 기존의 제조업에서 발전한 소프트웨어 개발이 상당수 실패를 겪으면서 돈을 받고 제품을 만드는 것(시간, 성능을 주로 추구함)을 해온 사람들과의 거래에서 고려해 봐야하는 부분이기 때문에 충분히 고려해봐야 할 부분이다.

-> 얼마를 받고 받을 건지, 고객에게 돈을 받고 개발하는 소프트웨어가 잘 만들어지고 있음을 알려주기도 함 -> 에이자일과 같은 기법을 사용하는 회사에서는 답답하다고 생각할 수 있음

-> 고민하는 방식에 대해 알아둘 필요가 있음

 

주요 주제

• Software pricing – 소프트웨어에 가격을 제시하는 것
• Plan-driven development – 계획을 어떻게 세울지
• Project scheduling – 계획을 좀 더 디테일하게 어떻게 수립해 나갈 것인지
• Agile planning – 이번 장부터의 내용이 plan-based 기반이기 때문에 에이자일 측면에서는 어떤 식으로 바라보아야 하는지
• Estimation techniques – 여러 가지 상황들에 대한 대처 같은 부분을 평가를 해야 함
• COCOMO cost modeling – 위와 같은 상황들에 대해 수식을 이용한 접근

 

Project planning -> 사람, 시간, 돈에 대한 계획을 세움

계획

->소프트웨어를 개발하기 위해서는 어떠한 일들이 이루어져야하는지 잘게 쪼게는 작업을 함

->잘게 쪼게진 일들을 어떻게 사람에게 할당할지를 정함, 더불어 그 사람이 얼마만큼을 해야 할지 정해져야 한다. 지금 당장 사람이 없다면 어떤 사람들이 얼마만큼의 기간 동안 필요한지 예측을 해야 함 -> 계획 중에 우리가 고려해야 될 위험 요소들(사람의 문제, 환경의 문제)을 미리 예측을 해야 함/ 그러한 문제들을 중요도 별로 카테고리화하는 작업이 필요함 -> 이러한 문제들을 미리 예측해서 대응방법들을 고려를 해야 함.

>>문제가 없다면 최소의 인력으로 최적의 방법을 진행하기 때문에 비용이 절약될 것이고 문제가 많다면 사람과 시간과 돈이 많이 늘어날 수밖에 없다. -> 따라서 미리 이러한 부분들에 대해서 염두를 해두어야 함.

사용

-> 위와 같은 과정들을 거쳐 세워진 계획들을 통해 고객에게 돈을 얼마만큼 요구하게 되는 커뮤니케이션의 수단이 될 것이다. -> 팀 내에서도 현재 진행되어야할 프로젝트 규모나 과정에 대해서 설명할 수 있는 자료가 될 수 있다.

>>따라서 대내외적인 사람들과 대화의 자료로 사용될 수 있다.

-> 이를 통해서 프로젝트가 진행되고 이에 의거하여 프로젝트가 제대로 이루어지고 있는지에 대한 관리를 하는 것을 도와줍니다.(PL부서 – 프로젝트를 계획하고 관리하는 부서)

->에이자일에서는 개발자 각각이 위와 같은 역할을 진행함

 

Planning stages

-> 계획은 한번 세우고 끝나지 않는다. - 이유는 가지고 있는 정보의 양과 질, 더불어 프로젝트의 대상이 단계별로 다르기 때문에 계획은 단계별로 상황에 따라 여러 번이루어진다.

>proposal stage – 고객이 요구하는 소프트웨어를 만들기 위해 고객에게 그러한 소프트웨어를 만들기 위해서는 얼마만큼의 돈과 시간, 인력이 들것 같다는 것을 알려주기 위한 것

-> 이후에 고객이 돈을 주고 소프트웨어 개발 프로젝트가 시작됨

>project startup phase – 프로젝트의 세부 내용을 만드는 것 -> 우리가 해야 될 일을 정의, 그렇게 해야 될 일들이 단계별로 이루어지는데 plan-based 기법에서처럼 나선형 모델에서 릴리즈1,2,3,..를 만드는 것처럼 일을 어떤 우선순위에 맞춰서 일들에 대한 선후 순서를 정합니다. -> 일들이 정의되었으면 확보한 자원에 따라 얼마만의 기간 동안 누가 진행을 할 것인지 단계별로 어떤 식으로 개발 될 것인지 계획한 후 사람과 장비를 투입하고 구체적으로 고객에게 최종전달할 날짜를 맞춥니다.

-> 하지만 정해진 대로만 프로젝트가 진행된다고 볼 수 없음

>Periodically throughout the project -> 계획에 맞춰 프로젝트가 진행될 수 있도록 계속해서 프로젝트를 모니터링 해야 함. (피드백, 컨트롤, 관리)

 

Proposal planning -> 여기서 제일 중요한 것은 비용이다.

>보통은 한곳에 맡기지 않고 어느 정도의 돈으로 얼마동안의 기간 동안 어떠한 소프트웨어가 필요한지 공표를 함 -> 그러면 대부분의 개발업체에서 자신들이 가지고 있는 것들을 공표된 범주 안에 맞추려고 노력을 함 -> 경쟁관계가 생김

누군가에게 돈을 받고 공급하는 경우에는 평균적으로 위와 같이 진행되지만 에이자일 같은 경우에는 주변의 사람들을 중심으로 우리가 필요한 것을 개발함 -> 사람에 대한 의존도가 높아짐, 돈을 받고 경쟁하는 경우가 적음

>>접근 방식에 따라 상세 개념이 달라질 수 있음

 

>>요구를 해서 소프트웨어를 만드는 경우 고객이 직접 요구사항을 씀 -> 고객이 공표를 띄우면 그 안에 요구사항 문서가 존재함 -> 따라서 고객이 요청하는 기간, 비용, 요구에 따라서 계획을 세우게 되고 가격을 책정하게 됨

>가격을 정한다는 것 – 소프트웨어 개발비용이 들어가고 소프트웨어 운영비용이 들어감, 더불어 필요한 하드웨어나 소프트웨어, 라이센스에 대한 것들도 포함을 하여 고객이 요청한 사항들 안에서 세워진 계획들을 통해 가격을 정하는 것

 

Proposal planning이후에 고객으로부터 선정이 되어 고객을 만나서 더 디테일한 요구사항을 들을 수 있다. -> 고객과 조율이 끝나면 밑에 과정을 시작한다.

 

 

Project startup planning

>가지고 있는 인적 물적 자원을 어떤 식으로 투입할지 정하는 단계

>지속적으로 프로젝트를 하면서 제대로 진행되고 있는지 모니터하는 목적이 됨.

>이 부분에선 에이자일 역시 비슷하게 적용됨.(회사 내에 인력과 자원을 사용하는 것이기 때문에 비슷한 작업이 있음)

SI업체 -> 고객에게 돈을 직접 받아옴.

>plan-based에 매우 중요함 -> 이미 돈은 정해진 것이 때문에 이걸 가지고 얼마나 효율적으로 해낼지 생각해야하기 때문에 중요함

>에이자일에 경우에는 처음에 요구사항이 불분명할 수 있지만 스프린트를 뛰면서 명확해짐 -> 돈에 그렇게 민감하지는 않음 -> 스프린트별 계획을 세울 필요는 있음

 

Development planning

>plan-based의 경우는 정해진 기간에 정해진 소프트웨어가 나와야하기 때문에 주기적으로 각 과정들마다 결과가 잘나왔는지 문서를 통해 확인하는 작업이 필요함(돈과 위험요소들을 지속적으로 계산하므로써 고객이 정한 규격에 맞춰서 결과를 만들어내야 함)

>에이자일의 경우에는 스프린트를 하면서 인원과 자원을 수정해가기 때문에 과정 안에 포함되어 있음

 

 

Software pricing -> 소프트웨어 가격을 책정할 때 고려해야할 사항들

중요한 부분 -> 소프트웨어의 가격이 왜 이렇게 다를 수 있을까 생각해보기(정치적 측면)

요구사항이 큰 레벨에서 필요함

>소프트웨어의 가격을 정할 때 사람에 대한 비용이 외부적으로는 40~60%정도 차지함

내부로 보면 더 많은 부분을 차지함, 필요한 하드웨어, 소프트웨어 비용, 회의비 개발과정에 필요한 다양한 것들이 포함됨.

>고객이 이 소프트웨어를 무슨 목적에서 돈을 지불하고 개발하려는 목적에 따라서도 달라질 수 있다.

>더불어 조직적, 정치적, 경제적, 비즈니스적인 이유에서 가격이 변화할 수 있음

(물음표는 교수님께서 전적으로 동의하는 부분은 아니라는 의미임)

 

Factors affecting software pricing(소프트웨어 가격에 영향을 미치는 5가지 요소)

>Contractual terms(계약 조건) - 금액을 굉장히 낮게 책정한 것 -> 단서 조항이 붙게 한다. -> 더 저렴한 가격으로 소프트웨어를 만들어주는 대신 소프트웨어에 대한 저작권을 제작자에게 주고 유지보수 역시 제작자가 할 수 있게 해주는 조건을 추가함.(소유권을 제작자에게 있게 함)

>Cost estimate uncertainty - 요구사항이 모호한 상태, 회사가 처음 이 소프트웨어에 대한 금액산정에 서툴 수 가 있음, 금액이 낮게 나와도 좋은 것이 아님 추가적인 문제가 발생했을 때 비용이 더 많이 발생할 수 있음.(비즈니스적 문제로 연결될 수도 있음) -> 적정선을 잘 잡아야함. 우리나라에는 최저가격 입찰제가 존재함, 가격이 낮게 산정된 경우에는 왜 낮게 산정되었는지 알아봐야한다.

>Financial health – 누가 봐도 회사가 경제적으로 어려운 경우 가격을 낮춘 경우는 사생결단으로 꼭 이 일을 수행해서 돈을 받아야하기 때문이다. 가격을 높이는 경우에는 그 일을 수행할 회사가 해당 회사밖에 없다면 가능한 돈을 많이 받아내려고 노력할 것이다.

>>각각의 요인들이 반드시 가격이 내려가고 올라간다는 한쪽 방향으로만 생각하지 말고 유연하게 생각해야한다.

>Market opportunity – 처음 해당분야에 진입하는 회사에 경우 초도계약이 매우 중요하기 때문에 처음 계약을 어떻게든 수행하려고 하기 때문에 가격을 낮게 산정할 수 있다.

-> 해석 믿을 수 있는 회사가 수익을 많이 원하지 않고 진입을 위해 진입하는 경우에는 상관없을 수 있지만 적자를 감수하면서 까지 들어오는 경우에는 위험할 수 있다. -> 회사는 믿을 수 있다고 하나 그 회사가 그러한 위험이 있는 부분에 중요한 개발자들을 투입할지에 대해서는 알 수 없기 때문이다.(제대로 된 사람들이 제대로 투입되었는지 제대로 따져볼 필요가 있다.)

>Requirements volatility(요구사항의 불안정성) - 기본적으로 요구사항이 변할 수 있음 소프트웨어는 요구사항이 변함 -> 소프트웨어를 수주하는 개발자 입장에서 최초 요구사항 기준으로는 일정 낮은 금액의 산정을 진행하고 앞으로 변한 요구사항들에 대한 적용에 대해서는 많은 금액들이 추가로 산정된다는 조항이 들어갈 수 있다. -> 요구사항이 절대 바뀌지 않은 경우에는 좋은 조건이나 요구사항이 많이 바뀌는 소프트웨어의 경우에는 더 많은 비용이 들어갈 수 있다.

>>그러나 통계적으로 소프트웨어 개발에 정확한 비용을 산정하는 경우는 거의 없다.

-> 대부분은 몇 배를 더 받기도 하고 예외상황들 인적자원에 대한 고려를 제대로 하지 못해 더 낮은 가격이 산정되기도 한다.

-> 따라서 이러한 부분들은 총체적으로 고려할 필요가 있다.

>>최종적으로 소프트웨어 비용이 산정되었다고 하더라도 위에 5가지 요인에 의해 비용은 변할 수 있다.

 

Pricing strategies

>Under pricing -> 잘 못 산출하지 않았는지, 새로운 분야로 진입하는 회사인 경우, 남은 인적자원을 활용하려는 회사인 경우 – 회사가 건실한 회사인지 판단 후 괜찮다면 진행을 해도 좋을 것이다./ 그렇지 않다면 위와 같은 부분들에 대해서 세세하게 따져봐야 할 필요가 있다.

>Increased pricing

-> 가격이 책정된다면 그 가격은 반드시 낮게 또는 높게 책정될 수밖에 없다.

-> 위와 같은 금액 산정의 차이를 최대한 맞춰가려는 노력이 필요하다.

 

Pricing to win

>고객들이 믿고 맡길 수 있게 소프트웨어가격을 정해야한다.

>개발에 대한 고려가 적어지면 가격은 낮아질 수 있다. / 악의적, 실수로 인해 가격이 낮아질 수도 있다.

>추후로 요구사항이 변경했을 때 추가 비용이 발생하는 것에 대해서도 충분히 생각을 해봐야한다.(PL그룹 – 기술력이 떨어지는 사람들이 가거나 관리에 있어 산전수전을 겪은 사람들이 들어가기도 함)

Plan-driven development

기본적으로 plan-based 기법을 많이 사용하는데 이러한 방법은 제조업 서비스에서 많이 사용하는 기법이다. 혹은 순수하게 소프트웨어를 개발하는 경우에도 규모가 되게 커서 관련된 조직이 많은 경우에도 사용함.

 

프로젝트 계획의 레코드를 만들 때 어떤 일을 해야 하고 누가 그 일을 해야 하는지 스케줄은 어떻게 잡아야하는지 결과물은 어떤 것을 만들어야하는지 고려해야한다.

-> 앞서 배운 개발과정을 단계별로 거치면서 문서화작업이 지속적으로 이루어지기 때문에 문서들이 많이 나온다. 또한 실질적인 개발과정은 스프린트를 통한 에이자일이라면 스프린트별로 나타나는 소프트웨어들이 결과물로 나올 수 있다.

-> 그 뒤로는 매니저가 일정에 따라 과정들이 잘 이루어지고 있는지 확인하기 위해 활용된다.

(PL팀이 있다면 그 팀에서 관리를 하고 에이자일이라면 그 팀에 소속되어있는 팀장과 같은 사람들이 확인문서로 사용을 한다.)

 

Plan-driven development – pros and cons(장단점)

>plan-driven approach를 지지하는 경우에는 조직적으로 사람이 투입되고 돈도 투입되는 경우에 여러 가지들이 연결되어 있는 경우가 많아 자원들을 끌어오는 것이 쉽지 않아 그러한 것들을 확인하는 경우에 사용될 수 있음, 여러 문제점과 앞으로 예상되는 것들을 미리 예상함으로써 대안을 찾는 방향에서 긍정적임.

>지지하지 않는 경우는 현시점에 계속해서 요구사항이 변화하고 그에 맞춰 소프트웨어를 개발해야하는 상황에 놓여있는 것이라면 사용에 어려움이 있음

>>소프트웨어 사용이 처해있는 상황에 따라 잘 판단하여 사용해야한다. 그리고 계획을 세운다는 것에 극단적인 생각을 가지고 접근하지 말고 두루 수용할 수 있는 방향으로 개발을 하는 것이 좋을 수도 있다.

>>시대적으로 본인이 맡은 프로젝트의 특성에 맞춰서 적용을 해야 하는 것이 중요하다.

 

Project plans -> 프로젝트를 계획할 때 고려하는 단계별 요소들

>Introduction – 해야 할 프로젝트에 대한 설명

>Project organization – 프로젝트를 수해할 조직 구성

>Risk analysis – 프로젝트 중에 발생할 위험요소를 분석하고 어떻게 대응할 것인지

>Hardware and software resource requirements – 필요한 하드웨어나 소프트웨어 리소스가 존재한다면 그런 것들을 나타냄

>Work breakdown – 따라서 어떤 일들을 할 것인지 부분 별로 나눔(액션아이템을 만듦)

>Project schedule – 액션아이템과 사람 간의 관계를 결정하고 액션아이템 간의 의존관계를 고려하여 스케줄링을 해야 함

>Monitoring and reporting mechanisms – 끝까지 프로젝트를 모니터링하고 외부에서 받은 프로젝트라면 지속적으로 보고를 해야 함, 아니면 내부적으로 각각의 부분들을 진행하면서 업무사항을 레포트하는 과정이 진행된다.

 

 

Project plan supplements – 부수적으로 들어가면 좋은 것

>Configuration management plan – 소프트웨어의 버전관리, 개발도구의 툴을 통일화하여 관리하는 것

>Deployment plan(언제에 어떠한 결과물을 제시할 것인지) - 누군가에게 돈을 받고 있다면 고객에게 어떤 릴리즈가 이루어졌는지 보고하는 과정, 반드시 있어야할 부분임

>Maintenance plan – 유지보수를 어떻게 할 것인지

>Quality plan – 프로그램이 제대로 만들어지고 있는지

>Validation plan – 프로젝트에 적절한 접근방식 인적자원, 하드웨어 자원들이 투입되어 제대로 이루어지고 있는지

>>정답이 명확히 정해져 있는 것이 아니다. -> 프로젝트를 진행하면서 핵심적인 부분들을 고려하면서 해야 한다.(결과물이 무엇인지 명확하게 하는 것이 중요하다.)

 

planning process -> 한 번 정해지고 끝나는 것이 아닌 나선모형 식으로 지속 계획을 세워야함 -> 에이자일 역시 스프린트, 릴리즈마다 계획을 어느 정도 수정하는 것이 필요하다.

>>소프트웨어 개발에 변경이 일어나는 것은 당연한 것임 자연스럽게 받아드리는 자세가 필요하다. -> 변경이 발생할 때 또는 주기적으로 계획을 수정하며 그에 따라 발생할 수 있는 위험 역시 예측을 해서 대응하는 자세가 필요함.

>>더불어 본인이 개발하는 소프트웨어가 어떤 곳에서 어떤 역할을 하는지 고민을 해서 본인 스스로가 왜 소프트웨어를 짜야할지 회사적인 입장에서 생각을 하고 비즈니스 환경이나 트렌드를 미리 고민하고 그런 것들을 조기에 제안하고 반영할 수 있는 자세가 필요하다.

 

project planning process

-> 우리가 만들 일들이 주어짐 -> 위험한 것들 제한 요건들을 반드시 준수해야한다./돌발 상황들을 미리 예측을 해서 대응을 준비해야한다.(개발이 중단되지 않도록)/ 개발과제가 정상적으로 되었을 때 어느 시점에서 어떤 것들을 나와야하는지 (마일드스톤) 계획해야한다.

-> 이러한 것들이 정해지면 세부적인 프로젝트 계획들을 세운다./ 조직 외부에서도 올 수 있다.(계획을 세움 -> 누가 무엇을 언제까지 어떤 결과물을 내놓을 것인지) -> 작업을 시작하고 지속적으로 제대로 진행되고 있는지 모니터링을 함 -> 문제가 없다면 마무리한다./ 그렇지 않다면 다시 일을 진행한다.(작은 경우에는 어느 정도 스케줄을 조정하여 대응하지만 규모가 큰 경우에는 문제를 해결을 하고 다시 가장 앞으로 처음 골격을 바꾸는 일이 진행될 수 있다.)

 

Planning assumptions(계획을 세울 때 조언)

>realistic rather than optimistic – 가장 최적의 경우를 생각해서 일정을 만듦(초보자들이 주로하는 실수) -> 계획이 이쁜 것보단 결과가 이쁘게 잘나오는 것이 좋은 것임.(실제적인 경우를 반영해야함)

>take unexpected problems into account – 문제는 발생할 수밖에 없기 때문에 미리 예측을 해서 대응을 준비하는 것이 필요하다.(대안을 미리 찾아둘 것)

>delivery schedule is not seriously disrupted – 문제가 발생하면 스케줄이 변할 수밖에 없다/ 문제를 숨기지 말고 그것을 논의하는 것이 필요하다.(투명하게 같이 고민을 함)

 

Risk mitigation

>risk mitigation actions – 미리 예측을 해서 최대한 방지를 한다.

>re-plan the project – 다시 계획할 일이 있으면 프로젝트 계획을 다시 한다.

>agreed with the customer – 고객과의 계획이 필요하다면 계획을 한다.

 

 

Project scheduling -> 운영체제에서 많이 나옴

-> 잘게 쪼겐 일을 누가할지, 얼마나 시간이 걸릴지를 각각의 별로 정의하는 것

>organized as separate tasks – 해야 할 일을 명확하게 정의함

>calendar time – 사용될 시간을 계획

>who will work – 누가 일을 할지

>HW and SW resources – 필요한 하드웨어, 소프트웨어 자원들을 도출해냄

 

Project scheduling activities

-정해진 일과 시간 그리고 자원이 있는데 이러한 것들을 하나의 항목으로 가질 수 있다.

-프로젝트를 작업으로 나누고 각 작업을 완료하는 데 필요한 시간과 리소스를 예측함.

-연관성에 의해서 일들의 선후관계가 정의함.

-프로젝트 관리자의 직관과 경험에 따라 다름

 

The project scheduling process

-> 소프트웨어의 요구사항을 가지고 액션아이템들을 도출함 -> 그러한 액션아이템들의 상호관계를 판단함 -> 더불어 이와 관계된 인적 물적 자원들을 평가함 -> 사람에게 일과 자원을 할당함 -> 결과적으로 이것을 보기 편한 그림을 그림(간트차트로 만듦)

 

Scheduling problems(스케줄링의 문제점)

>평가하는 것 자체가 어려움.(기술적인, 조직적인, 인적인 것들)

>생산성은 어떤 일을 하는 사람의 수에 비례하지 않는다. -> 어떤 일을 몇 명의 사람이 해야 할지 명확하지 않음.

>늦은 프로젝트에 사람을 추가하는 것은 통신 간접비 때문에 나중으로 만듭니다.(man-month 신화에서 굉장히 강조됨) -> 사람이 로봇처럼 행동하지 않기 때문에 사람 수가 늘어나는 것에 비례해서 일률이 늘어나지 않는다.

>예상치 못한 언제나 일어난다. -> 마음 편하게 생각하고 침착하게 해결책을 찾아감.

 

Schedule presentation

>누가 무엇을 언제까지 그래서 결과물이 무엇인지 보여줘야 할 때 간트차트(시각적인 자료, 엑셀)같은 것을 이용한다.

에이자일에서 기간을 정하고 스크럼(2-4주)을 진행하는데 하나의 스프린트가 다양한 액션아이템으로 이루어져 있는데 액션아이템에 따라서 스프린트보다 크면 안 됨.

-> plan-based로 하더라도 우리가 구상하는 테스크(액션아이템)는 2-4주정도 하는 것이 맞음.

-> 앞서 간트차트에서 보여준 것처럼 Calendar-based로 보여주기 때문에 y축을 시간으로 계산하는 것이 좋음

-> 그래픽하게 구현하는 이유 특정일과의 상관관계를 표현하기 위해서이다.(일들의 전후 상호작용을 보여주기 위함임)

 

프로젝트 활동의 기본적인 요소들

-소요되는 기간

-필요한 사람의 수

-언제까지 나와야하는지

-무엇이 결과로 나와야하는지

>>위와 같은 것들이 파악이 되어야함

 

Milestones and deliverables

Milestones – 우리가 특정한 날짜에는 어떤 결과(deliverables)가 나왔는지를 점검하는 날짜

 

>>이러한 것들을 통해 표가 도출됨.

>>또한 표를 통해 bar chart를 만들 수 있음.(33page) -> 큰 점 = 마일즈스톤

MS project 소프트웨어를 사용하면 아이템 간의 상관관계와 자원량을 자동으로 계산할 수 있다. but 엑셀을 사용한다면 사람이 일일이 작업을 해야 한다.

>>최종 결과물을 스케줄 표가 나오는 것이다.

 

 

Agile planning -> 프로젝트를 계획하는 부분을 에이자일 측면에서 생각해봄

>스프린트를 끊임없이 뛰어서 결과물을 만들어내는 연속적인 기법임 -> 설계와 개발이 계속 반복되는 구조임

>한번 스프린트를 뛰고 해당 스프린트에 개발해야할 것들은 당시에 개발을 함

>스크럼을 한다면 하루하루 누가 무엇을 할지 결정함

>에이자일에 경우 하루하루 해야 할 것을 정하거나 3,4주 단위의 스프린트에서 해야할 일을 정하므로 굉장히 유연한 측면이 있음.

 

Agile planning stages

>Release planning – 출시할(릴리즈) 소프트웨어에 대한 계획을 함. -> 여러 번의 스프린트를 진행하고 마지막 스프린트 결과로 내놓을 결과물에 대한 요구사항를 미리 정했음.(각각의 기능들을 나열해봄)

>Iteration planning – 스크럼으로 릴리즈에 대한 것을 쪼게어 스프린트로 작업을 하고 매일 데일리 스크럼을 진행하면 계획을 세운다. -> 한 번의 스프린트가 2-4주정도 걸린다고 생각함.(우선순위가 높은 것들을 먼저 개발함)

 

 

Approaches to agile planning

>스크럼을 언급함

>우리가 개발해야할 backlog들을 각각의 스프린트로 쪼게어 개발함, 가장 작게는 데일리 스크럼을 통해서 진행이 되었는지 지연되었는지 판단을 함 더불어 다음에 무엇을 해야 할지도 계획을 함

>The planning game - Extreme Programming (XP) -> 스크럼하고 비슷한 방식임 -> 전통적인 에이자일 기법으로 쓰임 -> user stories(유스케이스 같은 것들)같은 말을 사용

 

Story-based(기능들이 들어 가있는 하나의 이야기) planning

>스토리가 완성이 되면 사용자등록, 정보에 대한 업데이트와 같은 하나의 시나리오가 펼쳐진다로 이해

>>이 스토리가 완성이 되면 우리의 시스템이 완성이 된다고 볼 수 있음.

>XP의 경우 스토리를 구현한다는 것은 어떤 일을 하는데 시간이 얼마나 걸리고 스토리 중에서 어떤 스토리를 우선 개발할 것인지를 계획하는 것(앞에서와 비슷함)

-> Story-based로 시간이 얼마나 걸릴지 예측을 했다면 그것에 effort points를 줌(얼마나 많은 노력을 기울여야 되는지 점수를 매기는 것 – 시간으로 환산하기 위함, 이것에는 스토리를 구현하는데 얼마만큼의 복잡도/어려움 크기 등이 어떠한지 고려하게 됨)

velocity – 팀이 주어진 시간 안에 할 수 있는 일의 양을 수적으로 표현한 것

>>velocity(능력) 안에서 주어진 일들을 처리해 나가는 과정을 진행함.

 

The planning game

-> 스토리를 정리하면서 개발할 결과물들의 set을 구하게 됨. -> 어느 스토리가 얼마만큼의 노력이 들어가야 할지 포인트를 매기는 평가가 이루어짐 / 더불어 우리에게 주어진 능력이 있으니 그 능력 안에서 얼마만큼의 스토리를 구현할 수 있는지 얼마나 걸리는지를 환산함 -> 가장 많은 노력이 들어간 것들을 추출해서 구현하는 과정 -> 설계와 개발을 반복하는 작업을 거침

 

Release and iteration planning

>XP에서의 Release planning 어떠한 features가 시스템 안에서 구현되어야 할지를 정함

그 스토리들을 얼마만큼의 effort가 들어가야 할지 우선도를 따져서 순위를 매기는 작업

>스토리는 2-3주 정도 구현할 수 있는 것을 계획함

>팀의 velocity는 story의 선택을 안내하는 데 사용되어 반복 내에서 story가 구현될 수 있는지 예측가능하다.

 

Task allocation

>3-4주라는 시간은 너무 길기 때문에 스토리를 구성하는 task들을 잘게 나누어 주는 작업을 함.(각각이 4-16시간이 걸림)

>하나의 스토리 안에 있는 task들이 연속적으로 반복 진행되어 완성됨.

>그런 다음 개별 개발자가 구현할 특정 작업에 등록함.

>이점

- 팀원들의 전체적인 공감대가 형성됨.

- 각자가 책임감을 가지고 진행을 함

 

Software delivery

>iteration이 돌면서 하나가 끝나면 결과물(소프트웨어)이 도출됨.

>>XP에서 강조하는 것 -> 일정을 연장하지 않음(그 시점에서 소프트웨어를 출시한다.)

 

Agile planning difficulties -> 전통적인 개발자들 기준 어려운 점

>고객의 변화하는 요구사항도 계획에 반영이 되어야한다.

>추가적인 변화가 일정을 바꿀 수 있음

>고객들이 에이자일에 익숙하지 않음 -> but 에이자일에서도 마일드스톤이 있기 때문에 그렇게 많이 영향이 있지는 않음

 

Agile planning applicability -> 적용가능성

>소규모 팀인 경우, 개발자들이 서로 잘 알고 self motivation한 자들이라면 가능하다.

>엄청 큰 규모의 프로젝트라면 전반적인 것은 plan-based로 진행되고 각각의 부분이 에이자일로 진행됨.(따라서top-down 기법에 대한 이해도 필요함)

 

Estimation techniques -> 돈에 대한 이야기, 본질적인 것

어떠한 기준으로 돈이 얼마라고 말할 수 있을까?

>Experience-based techniques(경험을 바탕으로, 실제론 이 부분이 많이 활용됨)

>Algorithmic cost modeling(어려움, 이 부분을 지향함)

>>최종적으로 정확한 평가/측정은 마지막으로 갈수록 정확히 측정된다.

 

Experience-based approaches

>이전의 수많은 과제에 대한 수행을 기반으로 가격을 책정함

>비슷하지만 똑같지 않은 소프트웨어를 만듦 -> 변하는 요소를 기반으로 토의를 함

>초반의 측정은 웬만하면 실패를 함 -> 지속적인 측정/평가 노력이 필요함

 

Algorithmic cost modelling

>mathematical function – 수학적인 함수 -> 코드사이즈와 같은 것들이 파라미터로 들어감

 

Estimation accuracy

>소프트웨어 시스템의 크기는 소프트웨어 시스템이 완료되어야만 정확하게 알 수 있음.

>최종 사이즈에 영향을 주는 요소

∙ 재사용되는 시스템 및 부품의 사용

∙ 프로그래밍 언어

∙ 계통분포

>>웬만하면 어려움

>>이러한 복잡성은 알고리듬 비용 모델링의 실질적인 적용이 주로 국방 및 항공우주 시스템 엔지니어링 분야에서 일하는 비교적 적은 수의 대기업으로 제한되었다는 것을 의미한다.

 

COCOMO cost modeling

>>이러한 것을 세세하게 알 필요는 이번 수업에서는 필요가 없음

-> 여기서 고려되는 것이 man-month(사람 머리수)

-> 라인수

>>얼마나 많은 사람이 얼마나 많은 라인을 가지고 일을 하는지

>KOSA에 가면 SW사업 대가산정 가이드를 볼 수 있음.

>>돈 계산하는 것이 쉽지 않음.(따져야할 것이 많음)

 

SI(system integration, 시스템 통합)알아두기

용역 받는 회사들의 임금이 높을 수가 없음...

-> 개발에서나 많이 받음

 

Key points

>개발 회사 조직적 요인은 위험 증가를 보상하기 위해 가격을 올리거나 경쟁 우위를 확보하기 위해 가격을 낮춘다는 것을 의미할 수 있다.

 

>소프트웨어는 종종 계약을 성사시키기 위해 가격이 책정되며 시스템의 기능은 예상 가격에 맞게 조정된다.

 

>계획 주도 개발은 프로젝트 활동, 계획된 노력, 활동 일정 및 각 활동에 대한 책임자를 정의하는 전체 프로젝트 계획을 중심으로 구성됩니다.

 

>프로젝트 스케줄링에는 프로젝트 계획의 일부에 대한 다양한 그래픽 표현이 포함됩니다. 활동 기간 및 직원 채용 일정을 보여주는 막대 차트는 가장 일반적으로 사용되는 일정표입니다.

 

>프로젝트 마일스톤은 활동 또는 활동의 예측 가능한 결과입니다. 각 이정표마다 경영진에 대한 공식적인 경과보고서가 제시되어야 한다. 납품 가능 품목은 프로젝트 고객에게 납품되는 작업 제품입니다.

 

>민첩한 계획 게임은 프로젝트 계획에 팀 전체를 참여시킵니다. 계획은 점진적으로 개발되며 문제가 발생할 경우 증가분 전달을 지연시키는 대신 소프트웨어 기능이 감소하도록 조정된다.

>소프트웨어에 대한 추정 기법은 관리자가 필요한 노력을 판단하는 경험 기반일 수도 있고, 필요한 노력이 다른 추정 프로젝트 매개 변수에서 계산되는 알고리듬일 수도 있다.

 

>COCOMO II 비용 모델은 비용 추정치를 작성할 때 프로젝트, 제품, 하드웨어 및 직원 속성을 고려하는 성숙한 알고리듬 비용 모델이다.