[소프트웨어공학] #3-2 Project Planning

11/7

 

3-1 Project Planning

: 일을 쪼개고(break down), 멤버 설정, 일어날 수 있는 예상 문제 선정

: 어떻게 일을 끝낼지 팀과 고객과 소통. 진행사항 확인하게.

 

Planning 단계

-Proposal stage: 계약을 위한 비드

대략적 outline을 세움. 요구사항 수집. 가격 책정을 위한 정보 공유.(가격 책정에는 staff 비용, 하드웨어 비용, 소프트웨어비용 등)

-Project startup phase: 계획을 세움-누가할 것이고, 어떻게 프로젝트를 나눌 것이고, 어떻게 자원을 할당할지 등등

설계나 구현 정보보다는 시스템 요구사항을 잘 알아야.

계획을 세움-예산과 인력에 대한 결정

모니터링 매커니즘으로 startup plan(아직 agile 개발에 사용-프로젝트 자원 할당에)

Development planning(개발단계)

계획은 정기적으로 개정되어야한다.

프로젝트 스케줄, 비용추정, 리스크의 수정

-Periodically throughout the project: 계획을 얻은 정보를 통해 수정하고 진행상황 모니터링

 

3-2 Software Pricing

: 비용을 추정하는 것.

hw, sw, travel, 학습 및 effor 비용 등등

개발 비용과 고객이 지불할 가격은 간단한 관계가 아님

광범위한 조직적, 경제적, 정치적, 그리고 사업적 고려사항들은 부과되는 가격에 영향을 미친다

 

여러 요소들

-계약조건

-비용 추정의 불확실성

-재정 건전성

-시장 기회

-요구사항 변동

 

Pricing 전략

Under pricing(개발비용보다 낮게): 직원 재교육할 미래의 기회를 얻기 위해. 새로운 시장공간을 접근하기 위해

Increased Pricing(개발비용보다 높게): 가변가격 대조를 buyer가 원할 때. 예상치 못한 리스크 

 

Pricing to win

바이어가 내고싶은 만큼의 비용을 따라감

개발 비용보다 적으면 SW 기능성이 줄어듬.

추가적 비용은 요구 변경에서 추가되고, 원래 가격에서 부족한 부분을 보충하기 위해 더 높은 가격 책정 가능

 

3-3 Plan-driven Development

: 계획 기반, Plan-based라고도 함. 상세하게 계획하는 것이 특징

공학 프로젝트의 운영 기술에 기반함.

계획은 수행해야할 작업을 기록하기 위해 생성됨.

-누가 할 것인지/개발 일정/작업 프로덕트

관리자는 진행상황을 확인하여 의사결정을 돕는 데에 계획을 사용한다

 

장점

일찍 계획하여 조직상 문제 대처에 용이

프로젝트를 시작하기 전에 잠재적 문제나 의존이 탐색됨.

 

단점

너무 빠르게 결정해버림.

 

Project Plans(프로젝트 계획)

필요한 자원 정의, 일정 쪼개기

Section

-Introduction/Project organization/Risk analysis/HW&SW resource requirements/Work breakdown/

Project Schedule/Monitoring&Reporting mechanism

 

Supplements

형상관리 계획

배치계획(특정 HW에 종속되거나, 배치하는 경우)

품질계획(어떤 표준/수준 유지)

검증계획

 

Project planning process(프로젝트 계획 수립 프로세스)

반복적 프로세스(iterative process)

계획의 변경은 불가피함.

-정기적으로 계획을 요구사항과 스케쥴, 리스크의 변화를 반영하여 수정해야한다.

-비즈니스 목표의 변경 또한 계획의 변동을 가져온다.

 

 

Planning Assumption

-긍정적인것 보단 현실적이게.

-문제는 언제나 생길 수 있다. 지연도 그렇고

-그것을 염두하고 scheduling해야한다.

-우발사태(contingency)를 계획에 두어야한다.

 

Risk Mitigation

-serious problem이면 위험 완화를 하라

-replan하는 경우도 있음

-고객에게 사실대로 고하고 협상

-새 스케쥴, 고객과 계약 등으로 타개

 

3-4 Project Scheduling

결정 프로세스.

-어떻게 개별 task로 작업을 조직할지

-언제/어떻게 task들을 실행할지

calendar time의 추정(어떤 일을 언제까지, 필요한 노력, 누가 할지)

필요한 자원의 추정(서버의 디스크 공간, 필요한 시간, 예산)

 

Project Scheduling Activities

-일을 쪼개기, 일을 끝내기위한 시간/자원소모 추정

-어떻게 효율적으로 일을 배치할지

-연관관계가 복잡해지지 않게

-직관과 경험이 관리자에겐 중요함.

 

Problems

비용 예측이 어려움.

생산성은 인력을 많이 넣는다고 좋아지지 않음

사람을 나중에/뒤늦게 투입하면 오히려 늦어질 수 있음.(communication overhead)

예상 외의 일은 언제나 발생한다.

 

Schedule Presentation(일정 표현)

그래픽으로 나타내기도 함.

일은 너무 작아서도 안되고 1~2주 걸리는 정도.

Calendar-based: Bar chart가 가장 일반적임.

Activity network: 일의 의존성을 보여줌.

 

Project Activities

-쪼갤 수 없는 기본요소

-기간/노력 추정치/끝내야하는 시점/정의된 종료 시점

Milestones(이정표): 스케쥴의 포인트

Deliverables(산출물): 고객에게 전달될 work product

 

3-5 Agile Planning

애자일은 반복적인 방법(iterative approaches)

- 주기적으로 요구사항을 받아서 개발 및 증분

- Plan-driven에 비해 계획이 덜 상세하다.

- 고객이 우선순위를 정하고 요구를 변경하여 '유연함'

 

Stages

Release planning(릴리즈 계획 수립): 몇달치의 계획(릴리즈) 수립

Iteration planning(반복 계획 수립): 중간 중간 short-term(2~4주 간격)에서 어떤 증분을 수립할지.

 

프로젝트 백로그와 데일리 리뷰.

game(주고받는것): 사용자와 개발자의 '주고받음' : 우선순위, 개발 사항 등

 

Story-based planning

-스토리를 모아서 우선순위를 정함(rank)

-필요한 노력의 양을 분석(effort points)-크기와 어려움이 반영됨.

-팀의 속도(velocity)를 감안하여 스토리를 선정.

 

Release planning involves

-스토리의 선택(selection)과 정재(refining)- 어느 릴리즈에 이 부분을 구현할지.

-당연히 그 릴리즈까지 기능을 구현해야함.

-스토리는 각 반복마다 선택된다.(반복은 2~3,4주정도 길이): 어떤 부분을 구현할지 정함

-팀의 속도는 선택에 도움.

 

task allocation(테스크 할당)--task가 구현의 최소단위

-스토리를 쪼갬.

-테스크는 4-16시간정도면 가능할 크기

(장점)

-팀에서의 overview:종료나 개발을 확인 가능

-개발자 자체의 ownership

 

Software delivery

-증분은 언제나 전달되어야한다.

-시간내에 개발되어야한다.

 

(단점)

-고객 참여를 유도하기 어려움.

-고객이 우선순위 결정에 대표성을 가지는지/고객이 참여하기 어렵다는 사실.

 

작고 안정적인 개발팀에서 잘 돌아가고

큰 팀/물리적 거리가 크고/멤버교체가 잦으면 힘듬.

 

3-6 Estimation Techniques

Experience-based techniques

- 관리자의 경험에 기반

- 기존 프로젝트에 대한 경험에 기반한다.

-그러나 SW가 동일하지 않으니 달라질 수 있다.(추정 오류)

-기술이 발전하여 도움이 크게 안될수도 있다.

-직관이 개입하니 사견도 있음.

Algorithmic cost modeling

- 알고리즘. 산술식을 이용하여 구하는 방식

 

추정의 불확실성

-개발 과정이 갈수록 불확실성이 줄어들고, 처음에는 불확실성이 크다.

-수치가 다 지정되어있다.

-Effot = A * Size^B * M

-SW 산업 대가 산정 가이드(한국)