프로젝트 계획과 관리 1

프로젝트 계획 수립 문제 정의 및 선택 시스템 계획의 작성 프로젝트 관리 개념 프로젝트 성공/실패 조직구성계획 프로젝트 관리를 위한 모형화 도구 개발비용 산정

프로젝트 계획 수립 의미 프로젝트 계획 항목 프로젝트에 이용할 자원 설정, 업무분담, 일의 수행 등을 위한 계획을 설정하는 것 개요 프로젝트 조직 위험분석 S/W, H/W 자원요구사항 업무 분할 프로젝트 일정계획 감시와 보고

바 차트의 예

PERT 차트의 예

문제 정의 및 선택 문제를 정의하려면 문제의 범위와 배경 및 관련된 환경들을 잘 이해해야 한다. 사용자로부터 직접 정보를 수집하는 면접조사방법 각종 문서나 자료들을 이용하여 조사하는 방법 현장을 직접 관찰하거나 실제로 업무를 수행하여 보는 방법 등

시스템 계획의 작성 프로젝트 전체의 총책임자인 관리자의 책임 하에 작성 작업의 중요사항과 그 완료 또는 종료기일에 대하여 작성 추가, 변경 등은 「시스템 계획」 미팅(뒤에 기술)에서 실시 시스템 계획의 관리자는 어디까지나 프로젝트 전체의 총책임자 프로젝트 전체의 마스터플랜을 바-차트로 작성 키가 되는 개발 작업의 관련, 전후관계를 분명히 하고, 그 다음은 프로젝트 관리에 중점을 둔 시스템 계획과 그 프로젝트의 관리방법을 실시

「시스템 계획」미팅 시스템 계획을 기초로 프로젝트의 상황을 파악하기 위하여 프로젝트 계획의 리뷰-미팅(review-meeting)을 개최한다 미팅 프로젝트의 총책임자가 주최 프로젝트에 관계하는 부서장 또는 과장인 관리직이 출석 책임자 또는 그 부서의 대표자가 출석하지 않은 경우는 그 시스템 계획의 미팅은 성립하지 않는다 미팅의 목적은 상황파악

문제의 해결과 트래킹 문제란? 진짜의 문제인가를 판단하는 것이 중요 문제 작업의 책임자가 실행해야 될 일이라면 그들은 시스템 계획에서의 문제가 아니라 그것은 본래의 작업에 정표 가운데에 추가되어야 할 작업항목 프로젝트 진척에 영향을 미치는 사건

프로젝트 관리 개념 프로젝트관리 기술은 정보기술 커뮤니티(community)가 필요하다. 프로젝트 관리 개념을 이해하기 위해서는 다음의 내용을 이해하고 있어야 한다. 프로젝트와 프로젝트 관리의 차이점을 정의할 수 있어야 한다. 실패한 정보시스템 또는 기술 프로젝트의 원인을 설명할 수 있어야 한다. 프로젝트 관리자의 기본 능력을 설명할 수 있어야 한다. 프로젝트 관리도구로서 PERT나 Gantt 사이의 차이점을 인식할 수 있어야 한다. 프로젝트 관리 도구와 관련 있는 프로젝트 관리 소프트웨어의 역할을 설명할 수 있어야 한다. 프로젝트 관리에 대한 8가지 활동(activities)을 설명할 수 있어야 한다. 프로젝트 관리에서 프로젝트 계획 조합과 그의 역할을 정의할 수 있어야 한다

범위를 정의하고 그 범위를 구체적으로 문서화한다. 프로젝트를 소단위 작업(task)으로 분업화 시킬 수 있어야 한다. 작업기간을 측정하고 PERT 차트에 소단위 작업을 지정할 수 있어야 한다. 프로젝트에 필요한 자원을 할당하고, Gantt 차트를 이용하여 프로젝트 스케줄을 만들어야 한다. 업무(task)에 인력을 배정하고 팀의 성과를 감독해야 한다. 스케줄과 추가 예산 비용에 대한 스케줄과 자원할당에 대하여 임계경로분석(critical path analysis)을 사용해야 한다. 프로젝트에 대한 사용자 관점을 관리하여 프로젝트의 범위를 조절해야 한다.

프로젝트 성공/실패 프로젝트의 성공 프로젝트의 실패 최종 정보 시스템이 고객에게 만족해야 한다. 주어진 시간에 완성되어야 한다. 정해진 예산안에 이루어져야 한다. 시스템 개발과정이 현재 사업 운영에 최소의 충돌을 가져야 한다. 프로젝트의 실패 시스템 개발을 위한 기술 요원 부족 시스템 개발 방법 가로지르기 : 예산이나 시간을 맞추기 위하여 일정이나 개발 단계를 뛰어넘는 경우 프로젝트 스코프가 서투르게 정의된 경우 부정확한 예상 : 시간의 흐름에 따라 사업의 필요성이 변경되는 경우 예산과 일정이 비현실적임 : 문제 분석이나 요구사항 분석을 제대로 하지 않고 예산이나 일정을 무리하게 정하는 경우 개발기술을 잘못 선택할 경우 인력관리 실패, 불충분한 자원, 시대흐름에 역행, 계획관리 실패 등.

프로젝트 관리 기능 스코프(scoping) : 프로젝트 관리의 첫 활동은 스코프를 정하는 것이다. 스코프는 기본 데이터, 기능 및 행위들을 식별하며 이 특성들에 대한 양적 한정(boundaries)을 정하는 것이다. 즉, 양적 데이터(예, 입출력 데이터 형식, 동시 사용자 수 등)가 명시적으로 기술되어야 한다. 계획(planning) : 프로젝트를 완성시키기 위한 필요한 작업들을 정의한다. 예비요원(staffing) 조직화(organizing) 일정계획(scheduling) 감독(directing) : 일단 프로젝트가 시작하면 관리자는 팀의 활동을 감독한다. 제어(controlling) 폐기(closing)

조직구성계획 조직구성에는 프로젝트별 조직(project format), 기능별 조직(function format), 행렬식 조직(matrix format)으로 구분할 수 있다. 프로젝트별 조직(project format) 중소 규모의 프로젝트에 적합 프로젝트 관리자가 중심이 되어 강한 동료의식과 공동 책임감이 고취되며 조직상의 제도나 제약을 적게 받기 때문에 조직의 동기성 및 환경 적응성을 높일 수 있다.

기능별 조직(function format) 장점 분석, 설계, 구현, 테스트, 유지보수 각 단계별로 전문화가 필요하다. 기능별 조직은 관리자가 소속된 요원들의 일을 전문화하고 각 부분별로 관리자가 개발자들을 지휘 감독 전문가들의 지식, 기술, 경험을 보다 효과적으로 활용 전문가들은 자신의 능력을 최대한 발휘할 수 있는 환경을 제공받게 된다 대형 프로젝트에 적합 단점 의사전달 방식에서 규정된 문서화방법을 사용 의견 불일치의 경우 많은 혼란을 가져올 수 있고, 서로의 의사에 대한 중재자가 필요

행렬식 조직(matrix format) 프로젝트별 조직과 기능별 조직의 장점을 취하여 구성 각 개발자는 기능별 전문 분야 내에서만 활용하되 프로젝트팀의 구성원으로서도 활용하는 절충식 구조 개발자는 기능 조직에 소속되어 일정기간 프로젝트 조직에 파견 나가는 형태 장점 협동적으로 노력하기 때문에 각 기능별로 전문가들의 시야를 넓혀주고 혁신을 촉진하게 되며 시간, 비용, 인력 등의 프로젝트별 배정에 있어서 균형을 유지할 수 있다. 단점 관리 비용이 증가 조직 내의 긴장해소, 조직 간의 균형유지, 프로젝트 수행상의 시간과 비용의 균형을 유지하는데 노력이 필요

팀구성 매니저(manager), 테스터(tester), 설계자(designer), 프로그래머(programmer)로 구성 계층적 구성(hierarchical organization) 소프트웨어 생산을 위한 팀은 주로 계층적 팀 구성 계층적 팀 구성은 조직이나 프로젝트의 크기에 따라 여러 단계로 구분

기술적인 관리조직 전체 프러덕트 구현은 프로젝트 리더의 지시에 따라 진행 프로그래머들은 팀 리더에게 보고하고 팀 리더들은 프로젝트 리더에게 보고 수한 프로그래머의 승진은 동시에 유능한 프로그래머를 잃게 되고 잘못하면 무능한 관리자를 생산하게 된다

매트릭스 구성(matrix organization) 여러 프로젝트를 분야별 소프트웨어 개발 팀 즉, 전문화된 소프트웨어개발 팀으로 나누어 개발하는 팀 서로 다른 분야의 사람들이 소프트웨어 개발 프로젝트를 수행하는 것 매트릭스 팀 구조는 작으면서 특정 분야의 전문 팀 그래픽 프로그래밍 팀, 데이터베이스 팀, GUI 팀, 품질 평가 팀 등 각 개인은 전문분야와 프로젝트 종류인 x, y 두 축에 따라 조직화

SWAT 팀 RAD(Rapid Application Development)와 같이 점진적 소프트웨어 개발 방식을 갖는 프로젝트에서 이용 SWAT는 Skilled With Advanced Tools를 의미 주로 4, 5명으로 구성되는 소규모의 팀 대화채널은 매우 단순하며 형식적 절차적인 회의 보다는 서로 일상생활에서처럼 한 사무실에서 대화 브레인 스토밍(brain storming)과 같은 형식으로 대화 SWAT 리더는 관리자이며 개발자

팀 구성을 위한 기본 원칙 기본원칙 가능하면 능력을 가진 소수의 인력을 사용하라. 사람들의 능력과 작업을 잘 끼워 맞추어라. 장기간의 프로젝트에서 능력 이외의 일을 위해서는 팀을 구성하라. 팀의 중요성 역 Peter 원칙 Paul 원칙 잘 균형이 있고 조화의 팀 구성이 현명하다. 팀에 맞지 않은 사람은 제거하라.

프로젝트 관리를 위한 모형화 도구 프로젝트 일정 계획은 소프트웨어 관리자가 필요로 하는 일 관리자가 계획된 노력으로 이용 가능한 작업들을 조정 소 작업 중에서 병행처리가 가능할 수 있도록 작업과 일정계획들 사이의 상호 종속 관계를 고려 CPM(Critical Path Method) 기법을 사용하여 소작업 사이의 상관관계를 고려하여 프로젝트의 총 소요 시간을 계산 일정 계획에 필요한 작업 소프트웨어 개발모형 결정, 각 단계에 필요한 작업 분해, 작업후의 결과 정의. CPM 네트워크로 각 작업 상호의존 관계 표시. CPM의 각 작업 소요 기간 설정, 프로젝트 완료에 필요한 최소 기간을 산출. 프로젝트 규모 산출 방법을 사용하여 소요되는 Man-Month(MM)를 구하고, 이것을 기초로 기간을 산출하여 CPM 네트워크와 비교한 후 수정한다. 확정된 결과를 간트 차트(Gannt chart)로 그린다.

작업 분류 구조(WBS) 의미 목표를 단계(phases), 활동(activities), 작업(tasks) 등 계층적으로 분류하는 것을 작업 분류 구조(Work Breakdown Structure) WBS는 그림 3.8과 같이 탑-다운 계층 구조로 나타낼 수 있다 순서적 그리고 계층적으로도 표현할 수 있다 WBS는 간단한 전체적인 프로젝트의 윤곽을 보여주며 간트 차트에서 활동(activity)이나 작업의 기준이 된다. WBS 에서 프로젝트 관리자는 소단위 작업에 대한 작업 소요 일을 측정 작업기간을 측정할 때 소비시간(elapsed time) 개념을 이해하는 것이 중요 소비 시간은 두 가지 중요한 인간적인 요소(people factor)를 고려 효율성(efficiency) interruptions

작업을 수행하는데 필요한 예측치(expected duration ED)는 다음과 같다 1, 4, 1은 가중치의 기본 값이고, OD, PD, ED를 측정하는데는 가장 많이 사용하는 세가지 방법 Decomposition, COCOMO, Function point가 있다. decomposition은 프로젝트를 가장 작은 소단위 작업으로 나누어서 과거의 경험을 바탕으로 측정하는 방법 COCOMO는 하나의 모델을 기준으로 측정하는 것으로써 이전의 프로젝트 기간을 중심으로 새로운 프로젝트의 기간을 정하는 방법 기능점수 계산(function point count) 방법은 Albert[ALB79]에 의해 제안되었고, Albert와 Gaffbey(1983)에 의해 정제 입력 수, 출력 수, 파일 수, 질의 수, 외부인터페이스 수를 이용하여 FP(function point)를 다음과 같이 계산 FP= 합계*[0.65+0.01 (Fi)]

PERT와 Gannt Chart PERT 차트는 프로젝트의 작업들과 작업들 사이의 관계를 그래프로 표현한 네트워크 모델

개발비용 산정 개발비용을 산정하기 위해서 고려해야 할 사항 Boehm(1981)에 의해 제시된 소프트웨어 비용 산정방법 프로젝트 처음부터 끝까지 비용 산정 예산을 초과하지 않은 범위 내에서 산정 조직적, 경제적, 정치적인 고려사항과 사업적인 요소들을 고려하여 산정 Boehm(1981)에 의해 제시된 소프트웨어 비용 산정방법 알고리즘 모델(algorithmic cost modeling) : 특정한 소프트웨어 척도와 프로젝트 비용과 과거의 정보를 바탕으로 개발된 모델 전문가의 판단(expert judgement) : 전문가의 판단에 의한 소프트웨어 비용 산정 유추에 의한 산정(estimation by analogy) : 기존에 작업했던 프로젝트를 유추해서 프로젝트 비용 산정 파킨스의 법칙(Parkinson's law) : 작업은 가능한 시간 내에서는 계속되고 비용이 있으면 다 쓰게 된다는 의미. 능력별 지급(pricing to win) : 프로젝트에 대해 지불할 수 있는 비용 그 자체로 산정, 실제 상황에 가장 공통적인 비용 산정 법 하향식 산정(top-down estimation) : 제품의 전체적인 특성을 고려하여 결정되고 이 비용은 각 구성 부분에 할당 상향식 산정 (bottom-up estimation) : 각 구성의 비용이 산정되고, 이 비용이 전부 더해져 최종적인 비용이 산출

소프트웨어 비용 산출 방법 (1) 하향식 산정 방법 전문가의 판단(expert judgment) 일반적으로 가장 많이 사용되는 방법이며, 경험과 전문지식이 많은 개발자들이 참여한 회의에서 토론을 통하여 산정 전문가의 판단(expert judgment) 소프트웨어 개발 기술에 관한 경험이 많은 전문가의 판단에 따라 비용을 산출하는 방법 2명 이상의 전문가에게 의뢰 사소한 문제로 인한 결정이나 그룹 내의 한사람에 의한 독단으로 가면 문제가 발생

델파이(Delphi)식 산정방법 델파이식 비용 산정 방법의 진행과정 회의의 부작용을 방지하면서 전문가의 의견일치를 얻기 위하여 1948년 랜드사(Rand Co.)에서 개발 전문가의 판단 방법의 단점을 보완한 방법 전문가들이 편견이나 분위기에 지배받지 않도록 조정자(coordinator)를 필요 델파이식 비용 산정 방법의 진행과정 조정자가 시스템 정의서와 비용 산출 양식을 전문가들에게 제공. 조정자는 전문가들이 비용 산출에 관한 토의를 위한 회의를 소집. 전문가들은 익명으로 각자의 산정 작업을 완료. 조정자는 그룹 산정과 개인 산정에 관한 내용을 요약하여 제시. 조정자는 산정내용의 차이가 많을 때, 그 문제에 초점을 맞추어 회의를 소집. 전문가들은 다시 익명으로 산정 작업을 실시. 이 과정은 의견의 일치를 이룰 때까지 반복

WBS상에서 분해된 시스템의 기능들을 각각 필요한 원시코드 라인수로 산정함 (2) 상향식 산정방법 하향식 방법의 비과학성을 보안하기 위하여 개발할 시스템을 작업분류구조(WBS:work breakdown structure)로 정의하고, 각 구성요소에 대한 산정을 독립적으로 실시한 후 이를 합산하는 방식이 상향식(bottom-up) 산정방법 ① 원시코드 라인수(line of code) 기법 WBS상에서 분해된 시스템의 기능들을 각각 필요한 원시코드 라인수로 산정함 가장 효율적인 방안은 프로젝트 관리 목적으로 대두된 PERT(project evaluation and review technique)의 예측공식을 이용하는 것 확률론에서 배타분포도에 근거하여 낙관치(optimistic estimate), 기대치(most likely estimate) 및 비관치(pessimistic estimate)의 확률적 집합으로 예측치(expected value)와 이의 편방편차(variance)를 산출

② 개발단계별 노력산정 기법 시스템의 각 기능의 구현에 필요한 노력을 각 생명주기의 단계별로 산정하여 원시코드 라인 수 기법보다 더 정확성을 기하자는 것 개발비 산정에 반영시키는 목적도 있다. (3)COCOMO 방법 미국 TRW사의 B. Boehm은 1981년 저술한 소프트웨어공학 경제학[BOE 81]에서 원시 프로그램의 규모에 의한 비용산출 방법인 COCOMO(Constructive COst MOdel) 방법을 소개 실제 소프트웨어 개발 프로젝트들의 기록을 통계 분석한 결과로 산출 진행 예정인 프로젝트의 여러 특성들을 고려할 수 있도록 개발자에게 융통성 부여

기본모드(organic mode) : 일반응용 프로그램 과학기술 계산용, 일반 업무용으로 크기는 5만 라인 이하 난이도 수준을 측정하는 프로덕트의 개발 모델 의 세 가지 유형 기본모드(organic mode) : 일반응용 프로그램 과학기술 계산용, 일반 업무용으로 크기는 5만 라인 이하 중간 모드(semi-detached mode) : 개발지원도구 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 프로그램 등과 같은 크기나 복잡도가 중간급 정도이며 규모는 30만 라인 이하 내장형 모드(embedded mode) : 시스템 소프트웨어, 하드웨어, 소프트웨어 그리고 운영제약이 하나의 시스템으로 형성되는 항공기 운항제어 시스템과 같은 초대형 규모의 시스템 PM(Person/Months)은 프로젝트를 개발하는데 필요한 프로그래머 인원/월의 관계이고 KDSI(thousands of delivered source instruction)는 제품의 최종 원시코드의 명령어 수

Putnam 추정모델 (4) Putnam 추정모델 소프트웨어 개발프로젝트의 생명주기 전과정 동안에 노력의 특수한 분포를 가정해주는 동적 다변수 모델 LOC의 개수(원시문장)를 노력과 개발시간에 관련시켜서 다음과 같은 소프트웨어 식을 유도하는데 사용 Ck는 기술의 상태상수 이고 이것은 프로그래머의 진행을 방해하는 처리율 제약을 반영 Ck는 과거의 개발노력들로부터 수집된 자료를 통한 구역간의 자료를 이용하여 구역간의 조건을 유도해낼 수 있다.

개발노력 K에 대한 식으로 유도하면 다음과 같다. td는 단위의 개발시간 적용된 노력과 전달에 관한 시간과의 관계식은 비선형적

(5) 기능점수(Function Point) 모델 IBM의 A.J. Albert가 1979년 소프트웨어 생산성을 측정하기 위하여 개발 모델 구성을 위한 방법은 시스템에서 발생하는 5가지 항목을 조사하여 작성 입력 유형의 수(I) - 형식이 서로 다른 입력의 수 출력 유형의 수(O) - 화면 출력 및 출력 양식 사용자 명령어의 수(E) - 내부 데이터 구조를 변경시키지 않으며 프로그램 실행을 제어하는 명령어, 예를 들면 메뉴선택, 질의 선택 등 데이터 파일의 수(L) - 시스템에 의해 생성되는 내부 파일의 수 인터페이스의 수(F) - 외부루틴과의 인터페이스의 수

연습문제 프로젝트 관리란 무엇을 의미하는가? 프로젝트 관리를 위한 전문적 지식 영역에는 어떠한 것이 있는가? 프로젝트 일정 계획에서 이루어지는 작업을 설명하시오. 프로젝트 수행을 위한 조직 구성에 대하여 설명하시오. PMI 프로젝트 관리 모델 프로세스에 대하여 조사해 보자.