소프트웨어 공학 (software engineering ) 계획 (planning) 문양세 강원대학교 it...
DESCRIPTION
소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공. In this chapter … (1/2). 계획 (Planning). 소프트웨어 공학의 계획을 논하기에 앞서서 … 만사에 있어서 계획이 없으면 이룰 것이 없다 . 많은 계획들 중에 있어서도 가장 중요한 계획은 자기 자신 인생의 장중단기 계획이다. 사랑하는 학생 여러분 가슴에 손을 올리고 생각해 보세요 . 나는 10 년 후에 무엇이 되고 싶은가 ? 장기 계획 - PowerPoint PPT PresentationTRANSCRIPT
소프트웨어 공학 (Software Engineer-ing)
계획 (Planning)
문양세강원대학교 IT 대학 컴퓨터과학전공
Software Engineeringby Yang-Sae MoonPage 2
소프트웨어 공학의 계획을 논하기에 앞서서…• 만사에 있어서 계획이 없으면 이룰 것이 없다 .
• 많은 계획들 중에 있어서도 가장 중요한 계획은 자기 자신 인생의 장중단기 계획이다 .
계획 (Planning)In this chapter … (1/2)
사랑하는 학생 여러분 가슴에 손을 올리고 생각해 보세요 .• 나는 10 년 후에 무엇이 되고 싶은가 ? 장기 계획• 10 년 후를 위해서 , 올 한해 나는 무엇을 추구하고 달성할 것인가 ? 중기 계획• 올 한해 목표를 달성하기 위해서 , 나는 이달에 , 오늘 무엇을 해야 하나 ? 단기 계획
그래 고민되니까 오늘까정만 술 한잔 ?
Software Engineeringby Yang-Sae MoonPage 3
계획 (Planning)In this chapter … (2/2)
소프트웨어 공학에서의 계획이란 ,• 개발하고자 하는 문제에 대한 정확한 이해 및 정의를 하고 ,
• 여러 가지 필요한 작업들을 도출하고 , 그 작업들의 순서를 결정하며 ,
• 어떻게 개발해 나갈 것인지 일정을 계획하며 , 이에 따른 비용을 추정하는 것이다 .
• 그리고 , 궁극적인 결과 (output) 로는 계획서를 작성하는 것이다 .
We will cover …• 프로젝트 관리• 문제의 정의• 노력 추정• 일정 계획• 위험 분석• 계획서 작성
Software Engineeringby Yang-Sae MoonPage 4
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 5
프로젝트 관리란 ?
소프트웨어 프로젝트를
1) 조직하고 (organizing) – 어떠한 일이 있는지 파악하여 , 관련 사람들을 어떻게 끌어 모으고 ,
2) 계획하고 (planning) – 어떠한 일정으로 얼마의 비용으로 어떻게 사람을 넣어서 진행하며 ,
3) 일정관리 (scheduling) 하는 것이다 . – 잘 진행되는지 항시 점검하고 피드백하는 것이다 .
프로젝트 관리 (Project Management)계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 6
수입과 지출에 직결되는 경제 관련 작업 (economic activity)• 기술 외적인 부분 ( 경영 , 경제 ) 이 많음• 기술력 최고 ? 이것보다는 적기에 , 쓸만한 것을 , …
온라인 게임 열풍 , 앵그리버드 , 애니팡
관리가 잘된 프로젝트도 실패하는 경우가 있음관리가 잘 안 되는 프로젝트는 실패로 끝날 가능성이 많음• 결과적으로 , 프로젝트에 있어서 관리는 필수적 개념임• 그래서 , 아무리 잘난 사람이 많아도 조직에는 과장 , 팀장 , 부장이 존재하는 것임
관리 작업에 대한 방법을 일부 이론적으로 다룸• 관리를 실제 배우는 일은 현장감이 중요• 관리에 , 특히 인간 관리에 정도는 없음 경험을 바탕으로 융화할 수 있어야
프로젝트 관리의 중요성계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 7
계획 (1/2)
계획의 부재• 불확실성 중간에 무엇을 하고 있는지 , 어디까지 되어가는지 파악할 길이 없음
• 일정의 차질 , 경비의 초과 , 저품질 , 높은 유지보수 비용
• 위험 (risk)
• 결과적으로는… 프로젝트의 실패
소프트웨어 프로젝트 계획 수립
“소프트웨어 개발 과정과 일정 , 비용 , 조직 , 생산 제품에 대하여 사전에 계획”
• 문제를 이해하고 정의
• 필요한 소작업 (activity) 을 정의하고 순서를 결정
• 일정 예측
• 비용 예측
• 위험 분석
계획 (Planning)
계획서 작성
Software Engineeringby Yang-Sae MoonPage 8
계획 (2/2)
계획 수립의 결과
소프트웨어 개발 계획서• 사업관리자 , 개발자 , 사용자들에게 사업의 범위 , 필요 비용 , 필요 자원 , 개발 일정 ,
위험 요소 등에 대한 정보를 제공하는 산출문서 (deliverable)
주의할 점• ( 계획자는 ) 시스템에 대한 충분한 이해가 있어야 함 , 그러나 변경의 여지도 있음
• 현실적 , 구체적 계획 보여주기 위한 계획이 아닌 실질적인 계획
• 득실 관계 저울질 기간 vs. 비용
• 기술적인 측면 고려 제품의 난이도 , 투입 엔지니어의 능력
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 9
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 10
문제 정의 (1/2)
문제의 이해 :대상 업무나 문제를 사용자가 이해하는 용어로 정확히 기술한 것( 개발자가 아닌 고객의 관점에서 정확히 기술해야 함 )
계획 (Planning)
문제의 인식
기본 요건 분석
시스템 조사 및 정보 수립
현 시스템의 이해
신규 시스템의 정의
문제 범위와 원인 파악
문제를 둘러싼 조직 , 제도 , 시설 , 인원 , 기술에 관한 현황 파악
현재의 시스템 조사 , 업무 흐름 정책 등을 파악
면담과 서류로 심층 분석 ( 고객 상담 , 현업의 분석 , 작업의 체험 )
목표 시스템의 정의
Software Engineeringby Yang-Sae MoonPage 11
문제 정의 (2/2)계획 (Planning)
문제를 정의한 후에는 해결 방법에 대한 대책을 수립함• 신규 시스템의 목표 설정 기능과 우선순위 ( 투자 효과를 분석 )
• 해결 방안 모색 ( 사용자 요구 , 개발 여건 , 기술적 능력 고려 )
문제 ( 개발 시스템 ) 의 정의 요소• 문제의 기술 ( 교수용 온라인 게임을 만든다 .)
• 시스템의 필요성 ( 교수들도 가끔 즐길 권리가 있다 .)
• 시스템의 목표 ( 전국 교수들을 모두 매혹시킨다 .)
• 제약 사항 (근데 , 컴퓨터를 다룰 줄 모르는 분은 불행히 제외한다 .)
• 시스템의 제공 기능 (3D 와 FullHD 는 기본이고 , 사운드는 5.1 채널 지원이다 .)
• 사용자의 특징 ( 애덜이 아니라 대부분 중년이다 .)
• 개발 , 운용 , 유지보수 환경 ( 전화 Claim 이 비교적 많을 것이니 , ARS 응대가
필요하다 .)
Software Engineeringby Yang-Sae MoonPage 12
타당성 분석 (Feasibility Analysis)계획 (Planning)
경제적 타당성• 투자 효율성 ( 본전은 뽑을 수 있어야 … , 본전은 뽑지 못해도 , 고객은 확보해야 … )
• 시장성 ( 판매가 가능하고 , 시장이 열려 있어야… )
• 비용과 수익의 비교
기술적 타당성 ( 사용자 요구 기능 및 성능 vs. 제공 가능성 )• 사례 연구 (case study)
• 실패 사례 연구
실패는 성공의 어머니 , 他山之石 (타산의 아무 쓸모 없는 돌도 다듬으면 옥… )
• 모의 실험 (simulation)
• 프로토타이핑
법적 타당성• 사용 도구들의 법적 권한 1000억짜리 ( 불법 ) 툴을 사용하여 하루에 끝내자 . Oh! No.
• 시장 , 관행들에 대한 조사 아무 메일이나 잡아내는 소프트웨어를 개발하자 . Oh! No.
Software Engineeringby Yang-Sae MoonPage 13
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 14
노력 추정이란 ?계획 (Planning)
얼마나 노력이 들어가느냐 , 결국 개발 비용을 추정하는 것이다 .
소프트웨어 개발 비용 예측• 정확한 비용 예측은 매우 어려움
알려지지 않은 요소가 산재 에러 발생 , 성능 저하 , 엔지니어의 이직 , …
원가의 계산이 어려움 ( 결국 , 인건비인데 , 이것 자체의 추정이 어려움 )
• 과거의 ( 경험적 ) 데이타가 필요
• 단계적 비용 산정 방법도 사용 ( 초기 10억원 , 프로토타입 이후 11.5억원 등 )
예산• 인건비 : MM( 인원 /월 ) 를 기초 관리자를 포함한 엔지니어의 인건비를 의미함
• 경비 : 여비 , 인쇄비 , 재료비 , 회의비 , 공공요금
• 간접 경비 : 오버헤드 (overhead) 회사에는 회계 , 기획 , 경영 등 많은 파트가 있음
Software Engineeringby Yang-Sae MoonPage 15
비용에 영향을 주는 요소계획 (Planning)
제품의 크기• 제품의 크기가 커짐에 따라 비용은 기하급수로 늘어남 분산 , 병렬 시스템의 예
제품의 복잡도• 응용 : 개발지원 : 시스템 = 1 : 3 : 9
프로그래머의 자질• 코딩 , 디버깅의 능력차
• 프로그래밍 언어 , 응용 친숙도
요구되는 신뢰도 수준 MTBF(mean time between failure)
기술 수준 ( 개발 장비 , 도구 , 조직능력 , 관리 , 방법론 숙달 )
남은 시간• Putnam “ 프로젝트의 노력은 남은 개발 기간의 4 제곱에 반비례”
2 달 남았으면 1/24 = 1/16, 1 달 남았으면 1 이 필요…
Software Engineeringby Yang-Sae MoonPage 16
MTBF 제안 예제계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 17
프로젝트 비용을 예측하는 방법계획 (Planning)
상향식 (Bottom-up)• 소작업에 소요되는 기간을 구하고 , 여기에 투입되어야 할 인력과 투입 인력의 참여도를
곱하여 최종 인건 비용을 계산
• 장점 : 소작업에 드는 노력을 일일이 계획할 수 있음
• 단점 : 개인의 주관에 의한 추정이 될 가능성이 많음
하향식 (Top-down)• 프로그램의 규모를 예측하고 과거 경험을 바탕으로
예측한 규모에 대한 소요 인력과 기간을 추정
• 프로그램의 규모
• LOC (Lines of code)
• 기능 점수 (Function Point)
총 몇 라인이니까 , 혹은 어떤 기능이 있으니까 얼마 정도가 들 것이다라고 예측함
Software Engineeringby Yang-Sae MoonPage 18
COCOMO 방법 (1/4)계획 (Planning)
개요 ( 위키)
• B. Boehm 이 1981 년에 제안한 Constructive Cost Model 이다 .
• 주로 2K-32K 라인 규모의 많은 프로젝트의 기록을 통계 분석하여 얻은 결과로서 ,
중소규모 프로젝트의 추정에 적합하다 .
• 완성될 규모의 LOC(lines of code) 를 추정하고 , 이를 준비된 식에 대입하여 소요 MM
을 예측한다 .
• 소프트웨어 공학 기술의 발전과 더불어 초기 COCOMO 모델은 1995 년에 COCOMO
II 로 확장되었다 .
Software Engineeringby Yang-Sae MoonPage 19
COCOMO 방법 (2/4)계획 (Planning)
표준 산정 공식
프로젝트 유형 노력 (MM) 개발 기간 (Day)
단순형 (Organic) PM = 2.4 x (KDSI)1.05 TDEV = 2.5 x (PM)0.38
중간형 (Semi-detached) PM = 3.0 x (KDSI)1.12 TDEV = 2.5 x (PM)0.35
임베디드형 (Embedded) PM = 3.6 x (KDSI)1.20 TDEV = 2.5 x (PM)0.32
용어• KDSI: Kilo Delivered Source Instruction 입력 값으로 추정치에 해당함
(LOC: Lines of code 1 KDSI = 1,000 LOC)
• PM: Programmer-Month
• TDEV: Total development time 궁극적으로 파악해야 하는 값
Software Engineeringby Yang-Sae MoonPage 20
COCOMO 방법 (3/4)계획 (Planning)
유형 설명• 단순형 : 소규모 팀이 개발하는 잘 알려진 응용 시스템으로 , 일괄 자료 처리 , 과학 기술
계산 , 비즈니스 자료 처리 등 5 만 라인 이하 규모
• 중간형 : 중규모 팀이 개발하는 소프트웨어 시스템으로 , 트랜잭션 처리 , 운영체제 ,
DBMS 등 30 만 라인 이하 규모
• 임베디드형 : 하드웨어가 포함된 실시간 시스템 , 미사일 유도 , 신호기 제어 시스템
예제 : CAD 시스템• 예상 규모 : 33,360 LOC 중간형
• PM = 3.0 x (KDSI)1.12 = 3.0 x (33.36)1.12 = 152MM
• TDEV = 2.5 x (152)0.35 = 14.5 M
• N = PM/TDEV = 152/14.5 ≒ 11명
Software Engineeringby Yang-Sae MoonPage 21
COCOMO 방법 (4/4)계획 (Planning)
비용 예측 그래프
• 단순히 # of lines 에 비례하는 것이 아니라 ,
• 복잡할수록 ( 시스템이 커질수록 ) 비례하는 정도가 달라진다 . 빨리 증가한다 .
Software Engineeringby Yang-Sae MoonPage 22
COCOMO 방법의 보정 (Scaling) (1/2)계획 (Planning)
기본 방법에 제품의 성격 , 목표 시스템의 특성 , 개발 구성원의 특성 ,
프로젝트 자체의 성격 등에 따라 보정한다 .• 예를 들어 , 프로그램의 경험이 많다면 노력 예측 값은 더 작아져야 하며 ,
• 실시간 처리 요구가 있다면 예측 값은 더 커져야 한다 .
노력 승수 : 여러 조건을 고려하여 기본 방법에 곱하는 상수 값
노력 승수에 영향을 미치는 요소• 제품의 특성 : 신뢰성에 대한 요구나 문제의 복잡도 , 데이터베이스의 크기 등
• 컴퓨터 실행 : 수행 시간의 제약 , 주기억 장치의 제약 , H/W 및 S/W 의 안전성 등
• 개발자의 특성 : 개발자의 응용 분야 경험 유무 , 프로그래밍 언어에 대한 익숙도 등
• 프로젝트 : 복잡한 소프트웨어 도구 사용이 필요한가 ?
Software Engineeringby Yang-Sae MoonPage 23
COCOMO 방법의 보정 (Scaling) (2/2)계획 (Planning)
노력 승수 테이블 다음 페이지 참조
노력 승수 (ki, 1 i n) 를 사용하여 보정한 PM 계산
노력 승수를 기본 PM 값에 곱하여 보정된 PM 값을 구한다 .
1 1 n n k
scale i ii iPM k PM k c KDSI
Software Engineeringby Yang-Sae MoonPage 24
노력 승수 테이블 예제계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 25
COCOMO 방법의 사용 예제 (1/2)계획 (Planning)
128,000 LOC 크기인 임베디드형 (Embedded) 의 예측
기본 방법• PM = 3.6 x (128)1.20 = 1,216 MM(man-months)
• TDEV = 2.5 x (1,216)0.32 = 24 개월
• N = 1,216 / 24 = 50.66 ≒ 51명
• 생산성 : 128,000/1,216 = 105 LOC/MM 한 달에 105 라인 작성
Software Engineeringby Yang-Sae MoonPage 26
COCOMO 방법의 사용 예제 (2/2)계획 (Planning)
128,000 LOC 크기인 임베디드형 (Embedded) 의 예측 ( 계속 )
보정된 방법 (1.15, 1.56, 0.82 적용 시 예제 )
• PMscale = 1.15 x 1.56 x 0.82 x PM = 1,789 MM(man-months)
• TDEV = 2.5 x (1,789)0.32 = 28 개월
• N = 1,789 / 28 = 50.66 ≒ 63명
• 128,000/1,789 = 72 LOC/MM 한 달에 72 라인 작성
Software Engineeringby Yang-Sae MoonPage 27
COCOMO 방법의 특징계획 (Planning)
COCOMO 모델을 보면 , “ 소요 기간과 소요 인원의 관계는 서로 바꿀 수
있는 관계가 아니다”라는 말을 실증하고 있다 .
기간이 먼저 계산되고 , 이에 따라서 필요 인원을 파악
“기간이 많이 걸리니 인원을 늘리자”는 잘못된 생각
프로젝트의 규모만 예측될 경우 , 인원 , 개발 기간 등의 비용을 비교적
정확하게 예측할 수 있다 .
반면에 ,
1) 소프트웨어 제품을 하나의 개체로 보고 전체적인 수식을 계산한다 .
실제로는 제품이 훨씬 복잡한 구조를 가지고 있다 .
2) 계획 단계에 프로젝트의 규모를 정확히 예측하기는 거의 불가능하다 .
Software Engineeringby Yang-Sae MoonPage 28
COCOMO II계획 (Planning)
1995 년에 발표
소프트웨어 개발 프로젝트가 진행된 정도에 따라 세 가지의 다른 모델을
제시 각 단계에 따라 다른 계산법을 적용
제 1 단계 : 프로토타입을 만드는 단계• 화면이나 출력 등 사용자 인터페이스 , 3 세대 언어 컴포넌트 개수를 세어 응용 점수
(application points) 를 계산
• 이를 바탕으로 노력을 추정
제 2 단계 : 초기 설계 단계• 자세한 구조와 기능을 탐구
제 3 단계 : 구조 설계 이후 단계• 시스템에 대한 자세한 이해
Software Engineeringby Yang-Sae MoonPage 29
기능 점수 방법계획 (Planning)
기능 점수 (function points)• 정확한 라인수는 예측 불가능 COCOMO 적용이 어려움
• 입력 , 출력 , 질의 , 화일 , 인터페이스의 개수로 소프트웨어의 규모를 나타냄
• 각 기능에 가중값 ( 표 3.4(p. 120)) 이 기본이고 ,
표 3.5(p. 121) 은 복잡도에 따라 세분화함 ) 부여
• 기능 점수 1 을 구현하기 위한 LOC
어셈블리 언어 : 324
C언어 : 150
Pascal: 91
Ada: 71
Smalltalk: 21
총 라인수 = FP x 원하는 언어의 1 점 당 LOC
개발 노력 = 총 라인수 / 생산성 (LOC/MM)
일단 총 라인 수를 구하고 , COCOMO 등을 사용해 예측할 수도 있다 .
이들 고급 언어는 어디로 갔지 ?
Software Engineeringby Yang-Sae MoonPage 30
가중값 설명 (1/2)계획 (Planning)
입력 개수 : 사용자가 시스템에 제공하는 입력 자료의 개수
예 : 웹 페이지 작성에 있어서 입력 화면의 개수
출력 개수 : 시스템이 사용자에게 제공하는 출력 자료의 개수
예 : 웹 페이지 작성에 있어서 출력 화면의 개수
질의 개수 : 사용자가 제공하는 대화형 질의의 개수
예 : 검색 화면에서 검색 조건을 주는 방법의 수
Software Engineeringby Yang-Sae MoonPage 31
가중값 설명 (2/2)계획 (Planning)
파일 개수 : 시스템이 저장 및 관리하는 파일의 개수
예 : 봉급 파일 , 주소 파일
인터페이스 개수 : 다른 시스템과의 인터페이스 개수
예 : 은행 봉급 서버는 주소 서버 , 고과 서버와 인터페이스 함
Software Engineeringby Yang-Sae MoonPage 32
복합 가중값 설명계획 (Planning)
기본 가중값을 바탕으로 복잡도를 고려하여 , 단순 , 보통 , 복잡의 세 가지 단계로 구분함
아래 예를 보면 , “ 개수 x 복합 가중값”을 더하여 최종 점수 148 을 구한다 . 25 LOC/FP 인 4 세대 언어로 구현하면 , 148 x 25 = 3775 LOC 가 된다 .
프로젝트 팀의 생산성이 2000 LOC/MM 이며 ,
즉 한 달에 한 사람이 2000 라인 작성한다면 , 3775/2000 = 1.9MM 가 된다 .
Software Engineeringby Yang-Sae MoonPage 33
기능 점수 추정 사례계획 (Planning)
내용을 Skip 함 ( 교재 사례 예제가 너무 복잡하여 강의에서 제외함 )
Software Engineeringby Yang-Sae MoonPage 34
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 35
일정 계획 (Scheduling)계획 (Planning)
일정 계획 :
개발 프로세스를 이루는 소작업 (activity) 를 파악하고 , 그 순서와
일정을 정하는 작업• 개발 모형 결정 (폭포수 , 프로토타이핑 , …)
• 소작업 , 산출물 , 이정표 설정
작업 순서• 작업 분해 : WBS(Work Breakdown Structure) 작성
• CPM(Critical Path Method) 네트워크 작성
• 최소 소요 기간 (best case) 을 구함 ( 위험 분석을 위해 , worst case 도 작성해 본다 .)
• 소요 MM, 기간 산정하여 CPM 수정
• 간트 차트로 그려 , 일정을 구체화 함
Software Engineeringby Yang-Sae MoonPage 36
작업 분해 (Decomposition)계획 (Planning)
작업 분해 :
프로젝트 완성에 필요한 소작업 (activity) 를 찾아냄
WBS(Work Breakdown Structure)• 계층적 구조를 가짐
• Activity 의 규모를 판별할 수 있음
• 각 노드에 작업 소요일 , 책임자 등을
표시할 수 있음
작업 분해는 일정 계획에
앞서서 필요 작업을 찾는데
주된 목적이 있음
Software Engineeringby Yang-Sae MoonPage 37
작업순서 결정 및 소요시간 예측계획 (Planning)
CPM 네트워크 작성을 위해 , 우선 각 소작업에 대한 소요 기일을
예측하고 , 각 소작업 간의 선후관계를 파악한다 .
CPM 소작업 리스트 예제
소작업 선행작업 소요기간 ( 일 )
ABCDEFGHIJKL
--A-
B, DA, B
AD
C, FG, E
IK
815151010520251515710
Software Engineeringby Yang-Sae MoonPage 38
CPM 네트워크 (1/2)계획 (Planning)
CPM 네트워크는 방향성 그래프 (directed graph) 이다 . 그리는 예는 ,• 노드 (node) 는 소작업을 표시한다 .
원형 노드 : 소작업의 이름과 소요 기간을 기재한다 .
박스 노드 : 프로젝트 중간 점검 (milestone) 을 의미하며 , 예상 종료일을 기재한
다 .
• 에지 (edge) 는 작업 사이의 선후 관계를 표시한다 .
CPM 네트워크를 사용하여 , 프로젝트 완성에 필요한 작업을 나열하고
작업에 필요한 소요기간을 예측하는데 사용된다 .
Software Engineeringby Yang-Sae MoonPage 39
CPM 네트워크 (2/2)계획 (Planning)
CPM 네트워크 예제
Software Engineeringby Yang-Sae MoonPage 40
CPM 네트워크에 의한 임계 경로 (1/2)계획 (Planning)
CPM 네트워크를 사용하여 파악할 수 있는 정보• 각 작업이 가장 빠르게 시작할 수 있는 시각 (earliest start time)
• 각 작업이 최대한 빠르게 끝날 수 있는 시각 (earliest finish time)
• 각 작업을 최대로 늦추어 시작할 수 있는 시각 (latest start time)
• 각 작업을 최대로 늦추어 끝낼 수 있는 시각 (latest finish time)
작업의 순서는 물론 엔지니어의 적기 투입에 중요한 역할을 한다 .
임계 경로 (critical path)• 프로젝트를 마치는데 있어서 가장 기간을 많이 차지하는 경로
• 임계 경로 내의 작업이 늦어지면 프로젝트 전체 일정이 늦어진다 .
• 관리자는 임계 경로의 작업에 많은 신경을 써야 한다 .
Software Engineeringby Yang-Sae MoonPage 41
CPM 네트워크에 의한 임계 경로 (2/2)계획 (Planning)
임계 경로 예제
가능 경로 소요 기간 ( 일 )
S-A-M1-C-M4-I-M6-K-M8-L-X
S-A-M3-F-M4-I-M6-K-M8-L-X
S-A-M1-G-M7-J-X
S-B-M3-F-M4-I-M6-K-M8-L-X
S-B-M2-E-M7-J-X
S-D-M2-E-M7-J-X
S-D-M5-H-X
55*
45
43
52
40
35
35
Software Engineeringby Yang-Sae Moon
CPM 네트워크 특징계획 (Planning)
장점• 관리자의 일정 계획 수립에 도움
• 프로젝트 안에 포함된 작업 사이의 관계를 파악할 수 있음
• 병행 작업 계획 Parallel Processing 가능
• 일정 시뮬레이션
• 일정 점검 , 관리
관리에 대한 작업도
포함 가능
작업 시간의 정확한
예측 필요
소프트웨어 도구• MS Project 등
Page 42
Page 42
Software Engineeringby Yang-Sae MoonPage 43
MS Project 의 CPM 네트워크 예제계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 44
프로젝트 일정표 ( 간트 차트 , Gannt Chart)계획 (Planning)
소작업별로 작업의 시작과 끝을 나타낸 그래프
예비시간 (slack time) 을 보여줌예비시간 : 다음 작업에 영향을 주지 않고 연장 가능한 시간
계획 대비 진척도를 표시할 수 있음 프로젝트 일정 관리에 활용
개인별 일정표 작성 가능 언제 투입하고 , 언제 휴가가고…
일반적인 간트 차트의 구성• 세로를 일정축으로 하여 작업을 가로의 막대로서 표시함
• 막대의 흰 부분 : 예상 소요 기간
• 막대의 회색 부분 : 예비시간
Software Engineeringby Yang-Sae MoonPage 45
간트 차트 예제계획 (Planning)
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5T8
M3
M2T6
T5M4
T9
M7T10
M6
T11M8
T12
Start
Finish
Software Engineeringby Yang-Sae MoonPage 46
MS Project 의 간트 차트 예제계획 (Planning)
관심있는 학생은 MS Project 를 배워보시기 바랍니다 . ( 무료교육 많
음 )
SI 업체 등에 취업할 경우 큰 도움이 될 것입니다 .
Software Engineeringby Yang-Sae MoonPage 47
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 48
조직 계획계획 (Planning)
조직의 구성• 소프트웨어 개발 생산성에 큰 영향
• 작업의 특성과 팀 구성원 사이의 의사 교류
프로젝트의 구조• 프로젝트별 조직 : 프로젝트 시작에서 개발 완료까지 전담 팀 구성
• 기능별 조직
계획수립 분석팀 , 설계 구현 팀 , 테스트 및 유지보수 팀
파이프라인 (pipeline) 식 공정
• 매트릭스 조직 ( 인력 풀 제도 )
요원들은 고유 관리 팀과 기능 조직에 동시에 관련
필요에 따라 요원을 차출 팀을 구성하고 끝나면 원래의 소속으로 복귀
Software Engineeringby Yang-Sae MoonPage 49
조직 구성의 노하우 ?계획 (Planning)
경험이 많은 사람과 적은 사람을 적당히 혼합한다 .• 경험 많은 사람만 모아놓으면 배가 산으로 갈 것이다 .
• 경험 적은 사람만 모아놓으면 아예 배를 만들지 못할 것이다 .
• 적당히 섞어 놓으면 , 경험과 노하우가 자연스럽게 전수되는 이점이 있다 .
이직의 최소화가 대규모 프로젝트의 성패를 좌우한다 .• 프로젝트 후반에 새로운 인원이 투입되면 그만큼 일정이 지연된다 .
기간 단축을 위해서 인원을 추가 투입하는 것은 의미가 없다 .
프로젝트를 너무 잘게 나누면 , 팀 ( 모듈 ) 간 의사 교환 문제가 발생한다 .
대개 3명~8명 정도가 적당하다 . 8명이 넘으면 중간 관리자를 둔다 .
Software Engineeringby Yang-Sae MoonPage 50
중앙 집중식 조직 (1/2)계획 (Planning)
의사 결정권이 리더에게 집중
계층적 팀 구조
책임 프로그래머 팀 (Chief Programmer Team)• 외과 수술 팀 구성에서 따옴
• 책임 프로그래머 : 제품설계 , 주요부분 코딩 , 중요한 기술적 결정 , 작업의 지시
• 프로그램 사서 : 프로그램 리스트 관리 , 설계 문서 및 테스트 계획 관리
• 보조 프로그래머 : 기술적 문제에 대하여 논의 , 고객 / 출판 / 품질 보증 그룹과 접촉 ,
부분적 분석 / 설계 / 구현을 담당
• 프로그래머 : ( 책임 프로그래머의 지시에 따라 ) 각 모듈을 프로그래밍
Software Engineeringby Yang-Sae MoonPage 51
중앙 집중식 조직 (2/2)계획 (Planning)
특징• 의사 결정이 빠름
• 소규모 프로젝트에 적합
• 초보 프로그래머를 훈련시키는 기회로 적합
단점• 한 사람의 능력과 경험이 프로젝트의 성패 좌우 책임 프로그래머의 선정 문제
• 책임 프로그래머에게 오버로드가 걸릴 수 있음
• 보조 프로그래머의 역할이 모호
책임프로그래머
프로그램 사서 프로그래머 보조 프로그래머
백업
Software Engineeringby Yang-Sae MoonPage 52
분산형 팀 조직계획 (Planning)
민주주의식 의사 결정• 서로 협동하여 수행하는 비이기적인 팀
• 자신이 있는 일을 알아서 수행
• 구성원이 동등한 책임과 권한
다각도의 의사 교환 경로 제공
특징• 작업 만족도 높음 ( 이직률이 낮음 )
• 의사 교류 활성화
• 장기 프로젝트에 적합
단점• 책임이 명확하지 않은 일이 발생
• 대규모에 적합하지 않음 ( 의사 결정 지연 가능 )
Software Engineeringby Yang-Sae MoonPage 53
혼합형 팀 조직계획 (Planning)
집중형 , 분산형의 단점을 보완
특징• 초보자와 경험자를 분리
• 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐
• 의사교환은 초보 엔지니어나 중간 관리층으로 분산
소프트웨어 에 따라 계층적으로 분산됨
단점• 기술인력이 관리를 담당
• 의사 전달 경로가 김
Software Engineeringby Yang-Sae MoonPage 54
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 55
위험 분석 (Risk Analysis)계획 (Planning)
(내재된 ) 위험 요소를 인식하고 그 영향을 분석하여 관리
실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립• 인력의 부족 인력의 적극적 유치 , 팀 구성 시 고려 , 교차교육 등
• 일관성 있는 해결 방안 (누가 못하면 , 조금 여유 있는 옆 사람이 한다 ?)
체계적이고 조직적인 해결 방안 ( 조수 / 사수 개념 , 중복 배치 등 )
비용에 많은 영향을 미치는 요소 리스크• 요구분석의 변경
위험 감소 방안 프로토타이핑 , 설문지 , 리뷰
• 일정 지연의 위험
작업 의존도를 낮춤 ( 한 가지 작업에 병목이 발생하는 것을 최소화한다 .)
CPM 네트워크에서 outgoing edge 가 많은 노드
Software Engineeringby Yang-Sae MoonPage 56
위험 요소 위험 관리 기법
1. 인력 부족 유능한 인력모집 , 팀 구성 , 요원 배치
교차 - 교육 , 유능 인력 사전 확보
2. 비현실적 일정 및 예산 더 자세한 비용 , 일정 예측 , 원가 분석
점증적 개발 , 소프트웨어 재사용 요구를 줄임
3. 잘못된 기능의 소프트웨어 개발
사용자 회람 , 프로토타이핑
사용자 지침서 조기 작성 , 조직 분석 , 직능
분석
4. 잘못된 인터페이스의 개발 프로토타이핑 , 시나리오 , 태스크 분석
사용자 분류 ( 기능 , 스타일 , 업무 )
5. 과포장 요구 삭감 , 프로토타이핑
비용 - 수익 분석 , 원가 분석
일반적인 위험 요소 (1/2)계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 57
위험 요소 위험 관리 기법
6. 계속적인 요구 변경 최대 변경 상한선 , 정보 은닉
점증적 개발 ( 다음 버젼까지 변경을 연기 )
7. 외부 모양의 빈약 벤치마킹 , 검사 , 대조 확인 , 성숙도 분석
8. 외부 기능의 빈약 대조 확인 , 사전 검증 , 설계 경연 , 팀 작업
9. 실시간 성능의 빈약 시뮬레이션 , 벤치마킹 , 모델링 , 프로토타이핑 , 튜닝
10. 기술적 취약 기술 분석 , 비용 - 수익 분석 , 프로토타이핑 , 점검
일반적인 위험 요소 (2/2)계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 58
In this chapter …
프로젝트 관리
3.1 문제의 정의
3.2 노력 추정
3.3 일정 계획
3.4 조직 계획
3.5 위험 분석
3.6 계획서 작성
계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 59
계획서 작성 (1/3)계획 (Planning)
1. 개 요
1.1 프로젝트 개요
1.2 프로젝트의 산출물
1.3 정의 , 약어
2. 자원 및 일정 예측
2.1 자원
가 . 인력
나 . 비용
2.2 일정
3. 조직 구성 및 인력 배치
3.1 조직 구성
3.2 직무 기술
Software Engineeringby Yang-Sae MoonPage 60
계획서 작성 (2/3)계획 (Planning)
4. WBS
5. 기술관리 방법
5.1 변경 관리
5.2 위험 관리
5.3 비용 및 진도 관리
5.4 문제점 해결 방안
6. 표준 및 개발 절차
6.1 개발 방법론
7. 검토 회의
7.1 검토회 일정
7.2 검토회 진행 방법
7.3 검토회 후속 조치
Software Engineeringby Yang-Sae MoonPage 61
계획서 작성 (3/3)계획 (Planning)
8. 개발 환경
9. 성능 시험 방법
10. 문서화
11. 유지보수
12. 설치 , 인수
13. 참고문헌 및 부록
Software Engineeringby Yang-Sae MoonPage 62
개발 계획서 예제 (1/2)계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 63
개발 계획서 예제 (2/2)계획 (Planning)
Software Engineeringby Yang-Sae MoonPage 64
Homework #2계획 (Planning)