프로젝트 계획 (Project Planning) - COE 306: Software Engineering -

강의 개요 문제의 정의 일정 계획 노력 추정 조직 계획 위험 분석 계획서 작성

프로젝트 관리(Management) 프로젝트 관리란? 소프트웨어 프로젝트를 조직하고(organising) 계획하고(planning) 일정관리(scheduling) 하는 것이다.

프로젝트 관리가 중요한 이유 수입과 지출에 직결되는 경제 관련 작업(economic activity) 기술 외적인 부분(경영, 경제)이 많음 관리가 잘된 프로젝트도 실패하는 경우가 있음. 관리가 잘 안 되는 프로젝트는 실패로 끝날 가능성이 많음 관리 작업에 대한 방법을 일부 이론적으로 다룸 관리를 실제 배우는 일은 현장감이 중요

문제 정의 대책 수립 신규 시스템의 목표 설정 해결 방안 모색(사용자 요구, 개발 여건, 기술적 능력 고려) 소프트웨어 공학 문제 정의 대책 수립 신규 시스템의 목표 설정 기능과 우선순위(투자 효과를 분석) 해결 방안 모색(사용자 요구, 개발 여건, 기술적 능력 고려) (C) Eun Man Choi, 2002

일정 계획(Scheduling) 일정 계획 작업 순서 소프트웨어 공학 일정 계획(Scheduling) 일정 계획 개발 프로세스를 이루는 소작업(activity)를 파악하고 순서와 일정을 정하는 작업 개발 모형 결정 소작업, 산출물, 이정표 설정 작업 순서 작업분해(Work Breakdown Structure) CPM 네트워크 작성 최소 소요 기간을 구함 소요 MM, 기간 산정하여 CPM 수정 간트 차트로 그림 (C) Eun Man Choi, 2002

작업 분해(Decomposition) 작업 분해 Work Breakdown Structure 소프트웨어 공학 작업 분해(Decomposition) 작업 분해 프로젝트 완성에 필요한 activity를 찾아냄 Work Breakdown Structure 계층적 구조 (C) Eun Man Choi, 2002

작업순서 결정 및 소요시간 예측 CP/M 소 작업 리스트 소 작업 선행작업 소요기간(일) A B C D E F G H I J 소프트웨어 공학 작업순서 결정 및 소요시간 예측 CP/M 소 작업 리스트 소 작업 선행작업 소요기간(일) A B C D E F G H I J K L - B, D A, B C, F G, E 8 15 10 5 20 25 7 (C) Eun Man Choi, 2002

소프트웨어 공학 Activity 네트워크 (C) Eun Man Choi, 2002

임계 경로 가능 경로 소요 기간(일) 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

CPM 네트워크 장점 관리에 대한 작업도 포함 가능 작업 시간을 정확히 예측할 필요 소프트웨어 도구 소프트웨어 공학 CPM 네트워크 장점 관리자의 일정 계획 수립에 도움 프로젝트 안에 포함된 작업 사이의 관계 병행 작업 계획 일정 시뮬레이션 일정 점검, 관리 관리에 대한 작업도 포함 가능 작업 시간을 정확히 예측할 필요 소프트웨어 도구 MS-Works 등 (C) Eun Man Choi, 2002

프로젝트 일정표 간트 차트 소 작업별로 작업의 시작과 끝을 나타낸 그래프 예비시간을 보여줌 소프트웨어 공학 프로젝트 일정표 간트 차트 소 작업별로 작업의 시작과 끝을 나타낸 그래프 예비시간을 보여줌 (다음 작업에 영향을 주지 않고 연장 가능한 시간) 계획 대비 진척도를 표시 개인별 일정표 (C) Eun Man Choi, 2002

프로젝트 일정표

노력 추정 소프트웨어 개발 비용 예측 예산 정확한 비용 예측은 매우 어려움 과거의 데이터가 필요 단계적 비용 산정 방법도 사용 소프트웨어 공학 노력 추정 소프트웨어 개발 비용 예측 정확한 비용 예측은 매우 어려움 알려지지 않은 요소가 산재 원가의 계산이 어려움 과거의 데이터가 필요 단계적 비용 산정 방법도 사용 예산 인건비: MM(인원/월)을 기초 경비: 여비, 인쇄비, 재료비, 회의비, 공공요금 간접 경비: overhead (C) Eun Man Choi, 2002

비용에 영향을 주는 요소 제품의 크기 제품의 복잡도 프로그래머의 자질 요구되는 신뢰도 수준 소프트웨어 공학 비용에 영향을 주는 요소 제품의 크기 제품의 크기가 커짐에 따라 기하급수로 늘어남 제품의 복잡도 응용 : 개발지원 : 시스템 = 1 : 3 : 9 프로그래머의 자질 코딩, 디버깅의 능력차 프로그래밍 언어, 응용 친숙도 요구되는 신뢰도 수준 기술 수준(개발 장비, 도구, 조직능력, 관리, 방법론 숙달) 남은 시간 Putnam “프로젝트의 노력은 남은 개발 기간의 4제곱에 반비례” (C) Eun Man Choi, 2002

프로젝트 비용을 예측하는 방법 상향식 소요 기간을 구하고 여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건 비용을 계산 소 작업에 대한 노력을 일일이 예측 하향식 프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정 프로그램의 규모 LOC (Line of Code) 기능 점수

COCOMO 방법 Boehm이 개발 표준 산정 공식 예 CAD 시스템 예상 규모: 33360 LOC 소프트웨어 공학 COCOMO 방법 Boehm이 개발 TRW의 2K-32K 정도의 많은 프로젝트의 기록을 통계 분석 표준 산정 공식 노력(MM) 기간(D) Organic 유형 PM = 2.4*(KDSI)**1.05 TDEV=2.5*(PM)**0.38 Semidetached 유형 PM = 3.0*(KDSI)**1.12 TDEV=2.5*(PM)**0.35 Embedded 유형 PM = 3.6*(KDSI)**1.20 TDEV=2.5*(PM)**0.32 예 CAD 시스템 예상 규모: 33360 LOC PM = 3.0*(KDSI)**1.12 = 3.0*(3.33)**1.12 = 152MM TDEV = 2.5*(PM)**0.35 = 2.5*(152)**0.35 = 14.5 M N=E/D = 152/14.5 ~ 11 명 보정 (C) Eun Man Choi, 2002

COCOMO에 의한 비용 예측

중간 COCOMO 방법 비용 드라이버 비율 매우낮음 낮음 보통 높음 매우높음 극히매우높음 제품특성 RELY 0.75 0.88   비용 드라이버 비율 매우낮음 낮음 보통 높음 매우높음 극히매우높음 제품특성 RELY 0.75 0.88 1 1.15 1.4 DATA 0.94 1.08 1.16 CPLX 0.7 0.85 1.3 1.65 H/W TIME 1.11 1.66 STOR 1.06 1.21 1.56 VIRT 0.87 TURN 1.07 개인특성 ACAP 1.46 1.19 0.86 0.71 AEXP 1.29 1.13 0.91 0.82 PCAP 1.42 1.17 VEXP 1.1 0.9 LEXP 1.14 0.95 PROJECT 특성 MODP 1.24 TOOL 0.83 SCED 1.23 1.04   모든 노력 승수를 곱한다.

중간 COCOMO 방법 모든 노력 승수를 곱한다. 단점 소프트웨어 제품을 하나의 개체로 보고 승수들을 전체적으로 적용시킴 예: E=EAF * 2.4(32)1.05 = EAF * 91 man-months 단점 소프트웨어 제품을 하나의 개체로 보고 승수들을 전체적으로 적용시킴 실제 대부분의 대형 시스템은 서로 상이한 서브 시스템으로 구성되며 이중 일부분은 Organic Mode이고 다른 부분은 Embedded Mode인 경우도 있다.

기능 점수 방법 기능 점수(function points) 복합 가중 값을 이용한 기능점수 산출(표 2.7) 소프트웨어 공학 기능 점수 방법 기능 점수(function points) 정확한 라인 수는 예측 불가능 입력, 출력, 질의, 파일, 인터페이스의 개수로 소프트웨어의 규모를 나타냄 각 기능에 가중 값(표 2.6) 기능 점수 1을 구현하기 위한 LOC 어셈블리 언어(324), C언어(150), Pascal(91), Ada(71), APL(32) 복합 가중 값을 이용한 기능점수 산출(표 2.7) 총 라인 수 = FP * 원하는 언어의 1점 당 LOC 개발 노력 = 총 라인수 / 생산성(LOC/MM) (C) Eun Man Choi, 2002

기능 점수 추정 사례 사원 업무 관리 시스템 사원과 할당된 업무를 추적하는 기능이 필요하다. 사원과 할당된 업무의 추가, 변경, 삭제, 조회, 보고 등. 사원은 정규직과 비 정규직이 있다. 사원은 하나 이상의 업무를 할당 받을 수 있다. 표준 업무에 대한 설명은 다른 시스템이 제공한다. 사원은 한 부서 이상에서 일할 수 있고 하나의 부서에는 여러 명의 사원이 일한다.    

기능 점수 추정 사례 Step 1: 내부 논리파일(Internal Logical File)과 외부 인터페이스 파일(External Interface File) 등 모든 데이터 관련 기능을 찾아내고 복잡도를 구한다. 자료 이름 항 목 엔티티/서브 타입 종류(내부/외부) 사원 (이름, 주민번호, 부양자수, 근무형태(정규직/비정규직), 근무부서(외부 키)) 엔티티타입 내부 정규직 (직급) 서브타입 RET 비정규직 (시간당 임금, 소개소) 업무 (작업명, 작업번호, 임금단가) 업무할당 (발령일, 급여, 근무평가, 업무번호(외부키), 사원주민번호) 업무기술 (업무번호(외부키), 기술서 줄 번호, 기술서) 외부 자료 - 부서 (부서이름, 주소, 사원주민번호(외부키)) 외부 데이터 외부

기능 점수 추정 사례 표 2.9에 대입 복잡도를 구하면 내부 파일 외부 파일 사원: 8개의 DET(이름, 주민번호, 부양자수, 근무형태, 근무부서, 직급, 시간당 임금, 소개소) -> 단순등급 2개의 RET(정규직, 비 정규직) -> 단순등급 업무: 4개의 DET(작업명, 작업번호, 임금단가, 업무번호) -> 단순등급 1개의 RET -> 단순등급 외부 파일 3개의 DET

기능 점수 추정 사례 Step 2: 처리관련 기능(transactional function)인 외부 입력(External Input)과 외부 출력(External Output) 및 사용자 질의(External Query)를 파악하고 복잡도를 구한다. 외부 입력  외부 출력 질의 사원 사원 추가, 변경, 삭제 사원질의: 6-9 DET 사원질의 업무 작업 추가, 변경, 삭제 작업질의: 5 DET 작업질의 업무할당 작업할당 부서변경 사원평가 업무해임 적업할당 질의:      작업할당 보고서 업무할당 질의 부서 보고 부서질의

기능 점수 추정 사례 표 2.11에 대입 복잡도를 구하면 사원 업무할당 외부 출력 작업 보고 업무할당 보고 추가: 10개 DET, 2개 FTR(업무, 부서) 삭제: 3 DET, 1FTR -> 단순등급 업무할당 6개의 DET, 3개의 FTR(사원, 업무, 업무할당) -> 복잡 등급 외부 출력 6-19개의 DET, 2개의 FTR(사원, 부서) 작업 보고 5개의 DET, 1개의 FTR -> 단순등급 업무할당 보고 6~18개의 DET, 3개의 FTR(사원, 작업, 작업 할당) -> 중간급

기능 점수 추정 사례 Step 3: 전체 기능 점수를 구한다. 미조정 기능점수 = 96 미조정 기능점수 = 96 단순 중간 복잡 외부입력  6 × 3  2 × 4  2 × 6 외부출력  1 × 4  3 × 5    × 7 내부화일  3 × 7    × 10  6 × 15 외부화일  1 × 5  6 × 10 외부질의  3 × 3  0 × 6 미조정 기능점수 = 96 Step 4: 14가지 시스템 특성을 고려하여 조정. 총영향도(Total Degree of Influence): 25 Step 5: 최종 기능 점수 Function Points = UFP X (0.65 + 0.01 X TDI) = 96 X ( 0.65 + 0.01 X 25) = 86.4

조직 계획 조직의 구성 프로젝트의 구조 소프트웨어 개발 생산성에 큰 영향 작업의 특성과 팀 구성원 사이의 의사교류 소프트웨어 공학 조직 계획 조직의 구성 소프트웨어 개발 생산성에 큰 영향 작업의 특성과 팀 구성원 사이의 의사교류 프로젝트의 구조 프로젝트별 조직 프로젝트 시작에서 개발 완료까지 전담 팀 기능별 조직 계획수립 분석 팀, 설계 구현 팀, 테스트 및 유지보수 팀 Pipeline 식 공정 매트릭스 조직 요원들은 고유 관리 팀과 기능 조직에 동시에 관련 필요에 따라 요원을 차출 팀을 구성하고 끝나면 원래의 소속으로 복귀 (C) Eun Man Choi, 2002

중앙 집중식 조직 의사 결정권이 리더에게 집중 계층적 팀 구조 책임 프로그래머 팀(chief programmer team) 소프트웨어 공학 중앙 집중식 조직 의사 결정권이 리더에게 집중 계층적 팀 구조 책임 프로그래머 팀(chief programmer team) 외과 수술 팀 구성에서 따옴 책임 프로그래머: 제품설계, 주요부분 코딩, 중요한 기술적 결정, 작업의 지시 프로그램 사서: 프로그램 리스트 관리, 설계 문서 및 테스트 계획 관리 보조 프로그래머: 기술적 문제에 대하여 상의, 고객/출판/품질 보증 그룹과 접촉, 부분적 분석/설계/구현을 담당 프로그래머: 각 모듈의 프로그래밍 (C) Eun Man Choi, 2002

중앙 집중식 조직 특징 단점 의사 결정이 빠름 소규모 프로젝트에 적합 초보 프로그래머를 훈련시키는 기회로 적합 소프트웨어 공학 중앙 집중식 조직 책임프로그래머 프로그램 사서 프로그래머 보조 프로그래머 백업 특징 의사 결정이 빠름 소규모 프로젝트에 적합 초보 프로그래머를 훈련시키는 기회로 적합 단점 한 사람의 능력과 경험이 프로젝트의 성패 좌우 보조 프로그래머의 역할이 모호 (C) Eun Man Choi, 2002

분산형 팀 조직 민주주의식 의사결정 의사 교환 경로 특징 단점 서로 협동하여 수행하는 비이기적인 팀(Ego-less) 소프트웨어 공학 분산형 팀 조직 민주주의식 의사결정 서로 협동하여 수행하는 비이기적인 팀(Ego-less) 자신이 있는 일을 알아서 수행 구성원이 동등한 책임과 권한 의사 교환 경로 특징 작업 만족도 높음 의사 교류 활성화 장기 프로젝트에 적합 단점 책임이 명확하지 않은 일이 발생 대규모에 적합하지 않음(의사 결정 지연 가능) (C) Eun Man Choi, 2002

혼합형 팀 조직 집중형, 분산형의 단점을 보완 특징 소프트웨어 기능에 따라 계층적으로 분산 단점 초보자와 경험자를 분리 소프트웨어 공학 혼합형 팀 조직 집중형, 분산형의 단점을 보완 특징 초보자와 경험자를 분리 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐 의사교환은 초보 엔지니어나 중간 관리층으로 분산 소프트웨어 기능에 따라 계층적으로 분산 단점 기술인력이 관리를 담당 의사 전달 경로가 김 (C) Eun Man Choi, 2002

위험 분석 위험 요소를 인식하고 그 영향을 분석하여 관리 실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립 소프트웨어 공학 위험 분석 위험 요소를 인식하고 그 영향을 분석하여 관리 실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립 인력의 부족 -> 인력의 적극적 유치; 팀 구성; 교차교육 등 일관성 있는 해결 방안 비용에 많은 영향을 미치는 요소 -> 리스크 요구분석의 변경 프로토타이핑, 설문지, 리뷰 일정 지연의 위험 작업 의존도를 낮춤 CPM 네트워크에서 outgoing arcs가 많은 노드 (C) Eun Man Choi, 2002

일반적인 위험 요소 1.인력 부족 - 유능한 인력모집, 팀 구성, 요원 배치, 교차-교육, 유능 인력 사전 확보 소프트웨어 공학 일반적인 위험 요소 위험 요소 위험 관리 기법 1.인력 부족 - 유능한 인력모집, 팀 구성, 요원 배치, 교차-교육, 유능 인력 사전 확보 2.비현실적 일정 - 더 자세한 비용, 일정 예측, 원가 분석, 및 예산 점증적 개발, 소프트웨어 재사용 요구를 줄임 3.잘못된 기능의 - 사용자 회람, 프로토타이핑, 사용자 지침 소프트웨어 개발 서를 조기에 작성, 조직 분석, 직능 분석 4. 잘못된 인터페 - 프로토타이핑, 시나리오, 태스크 분석, 이스의 개발 사용자 분류(기능, 스타일, 업무) 5. 과포장 - 요구 삭감, 프로토타이핑, 비용-수익 분석, 원가 분석 (C) Eun Man Choi, 2002

일반적인 위험 요소 위험 요소 위험 관리 기법 6. 계속적인 - 최대 변경 상한선, 정보 은닉, 점증적 소프트웨어 공학 일반적인 위험 요소 위험 요소 위험 관리 기법 6. 계속적인 - 최대 변경 상한선, 정보 은닉, 점증적 요구 변경 개발(다음 버젼까지 변경을 연기) 7. 외부 모양의 - 벤치마킹; 검사; 대조 확인; 성숙도 분석 빈약 8. 외부 기능의 - 대조 확인; 사전 검증; 설계 경연; 팀 작업 9. 실시간 성능 - 시뮬레이션, 벤치마킹, 모델링, 의 빈약 프로토타이핑, 튜닝 10. 기술적 취약 - 기술 분석, 비용-수익 분석, 프로토타이핑; 점검 (C) Eun Man Choi, 2002

계획서 작성 1 개 요 1.1 프로젝트 개요 1.2 프로젝트의 산출물 1.3 정의, 약어 2 자원 및 일정 예측 2.1 자원 소프트웨어 공학 계획서 작성 1 개 요 1.1 프로젝트 개요 1.2 프로젝트의 산출물 1.3 정의, 약어 2 자원 및 일정 예측 2.1 자원 가. 인력 나. 비용 2.2 일정 3 조직 구성 및 인력 배치 3.1 조직 구성 3.2 직무 기술 (C) Eun Man Choi, 2002

계획서 작성 4 WBS 5 기술관리 방법 5.1 변경 관리 5.2 위험 관리 5.3 비용 및 진도 관리 소프트웨어 공학 계획서 작성 4 WBS 5 기술관리 방법 5.1 변경 관리 5.2 위험 관리 5.3 비용 및 진도 관리 5.4 문제점 해결 방안 6 표준 및 개발 절차 6.1 개발 방법론 7 검토 회의 7.1 검토회 일정 7.2 검토회 진행 방법 7.3 검토회 후속 조치 (C) Eun Man Choi, 2002

계획서 작성 8 개발 환경 9 성능 시험 방법 10 문서화 11 유지보수 12 설치, 인수 13 참고문헌 및 부록 소프트웨어 공학 계획서 작성 8 개발 환경 9 성능 시험 방법 10 문서화 11 유지보수 12 설치, 인수 13 참고문헌 및 부록 (C) Eun Man Choi, 2002