프로젝트 관리 및 개발 방법론

프로젝트 관리및 개발 방법론 2009. 09. 18 박성우 (swoopark@microsoft.com)

목차 • 프로젝트 개요 • 프로젝트 개념 및 설명 • 프로젝트 담당 역할 • 전사적 프로젝트 관리 (EPM) • EPM 개요 및 배경 • EPM 관리 체계 • EPM Best Practice • 포토폴리오 관리 및 프로젝트 관리 • EPM 효과 • 프로젝트 개발 개요 • 프로젝트 개발 Life Cycle • 프로젝트 개발 단계별 주요내용 • 개발 전 – 계획과 준비 • 플랫폼 선정 단계 • 아키텍처 디자인 단계 • 팀 개발환경 구축 단계 • 개발 중 – 설계와 구현 • 분석/설계 단계 • 구현 단계 • 테스트 단계 • 개발 후 – 배포와 관리 • 배포 단계 • 관리/모니터링 단계

프로젝트 개요 • 프로젝트의 개념과 성격 • 프로젝트 정의 • 전체적인 목적을 향한 일련의 활동들. 또한 그 목적의 달성과 관련한 정보의 수집 • 유일한 제품 또는 용역을 창출하기 위해 투입되는 일시적인 노력 • 프로젝트의 특징 • 명확한 목적과 목표 : 목적을 위해 일시적으로 모인 조직이 프로젝트 목표를 달성하기 위해 일한다. • 한시적(temporary) : 명확한 시작과 종료일을 가진다. • 독특함(unique) : 기존에 없는 유일한 제품이나 서비스를 제공한다. • 점진적으로 상세화됨(progressive elaboration) : 초기의 개략적인 범위정의에서 시작해 점차 구체화하여 구현된다. • 프로젝트의 사례 • 다양한 산업분야 적용 • 조직 혁신 프로젝트 • 이벤트 프로젝트 • 건설 프로젝트

프로젝트 개요 • 프로젝트의 담당 역할

기업 내에서 지속적으로 발생하는 다양한 프로젝트들을 조직의 목표에 부합하도록 체계적으로 엮고 관리하고자 하는 Systematic Approach EPM의 대상은 일반적인 개발 및 개선 프로젝트 뿐만 아니라 전략적 추진과제 경영혁신 활동 운영 개선 전통적인 개발 프로젝트 등을 모두 포함 EPM은 전체 조직의 경쟁력을 향상시키기 위해 필요한 변화의 요소, 즉 People, Process, Technology의 원활한 활용을 가능케 함. 전사적 프로젝트 관리 (EPM) EPM을 통해 전사적인 프로젝트 관리의 효율성과 효과의 향상이 가능함 EPM이란? EPM의 목적 Visibility :조직 내의 모든 프로젝트의 진행상황과 자원 별 수행정도를 시각적으로 확인 Insight :진행상황중의 작업 별 또는 자원 별 변동 사항이 전체 프로젝트에 미치는 영향을 실시간으로 자동분석 Control :Project가 제공한 상황예측정보와 분석 정보를 기준으로 프로젝트를 입체적으로 통제

프로그램 개발 하드웨어 도입 및 설치 소프트웨어 개발 및 설치 기업 내의 IT Training 내부 직원 지원 인사 채용 관리계획 기업의 전략프로젝트 년간 예산계획 시장 조사 프로젝트 신제품 출시 영업전략계획 영업 및 마케팅에 관련된 교육프로젝트 영업수주관리 제조 프로젝트 각 제품에 따른 연구개발 프로젝트 테스트 계획 고객사 방문 지원 및 커스터마이징 프로젝트 컨설팅 서비스 프로젝트 서비스 지원 교육 조직 내 부서단위가 아닌, 전사차원의 자원 및 프로젝트의 Visibility(가시성), Insight(통찰력), Control(통제)이 필요 전사적 프로젝트 관리 배경 기업의 규모에 따라 다양한 수의 프로젝트들을 진행 중이거나 진행할 계획을가지고 있고, 전략적 목표 달성하기 위해선 이를 효과적이고 효율적으로 관리해야 함 CEO, CIO… 마케팅 및 영업부서 서비스 및 지원부서 정책부서 연구 개발 부서 IT부서

전사적 프로젝트 관리 Life Cycle Doing the Right Things Doing the Right Things Right • 실행 및 모니터링 • 프로젝트 스케줄링 • 자원 할당 • 팀 협업 • 결과산출물 트랙 킹 • 예산 관리 • 위험 관리 • KPIs • 투자 분석 • 잠재적 가능 포트폴리오 모델링 • 비즈니스 드라이버 수립 및 가중치 부여 • 객관적인 기준에 입각한 의사결정 Do the Right Things Do the Right Things Right Complete Maintain Review/Govern Concept Kickoff Schedule Execute Monitor / Analyze / Report Collaborate

전사적 프로젝트 관리체계 의사결정권자의 실 시간적인 의사결정 지원 Alignment with Org. Objectives 포트폴리오 관리 조직전략 투자 및 자원에 대한 우선순위 포트폴리오 엔터프라이즈 프로젝트 및 자원 관리 Integrated Delivery Framework 관리되는 프로젝트의 통합된 포트폴리오 프로그램 프로젝트 수행의 반복성과 일관성 유지 프로젝트 공동작업 프로젝트 프로젝트 관리도구, 기술, 방법론, 교육

EPM Project Management Resource Management Project Portfolio Management Budgeting & Cost Tracking Reporting & Analysis Portfolio Management Tools & Applications Resource Management Desktop Tools & Applications Project Management Desktop Tools & Applications Budget & Cost Tracking Tools & Applications Project Reporting & Analysis Tools & Applications 전사적 프로젝트 관리 주요 구성 요소 Increasing Project Management Maturity and Sophistication How your people, processes &organization work Organizational Workflow, Collaboration, Artifact Management and Communication Supporting Technology Tools and Software

전사적 프로젝트 관리 Best Practice Create Select Plan Manage Develop Major Project Business Case PortfolioPrioritization 포트폴리오 관리 Develop Lite-weight Project Business Case Portfolio Optimization 1st Review 2nd Review Approved Portfolio Selected Final Approval Baseline Completed Workflow PortfolioPlanning Capture Project Proposals Major Project Planning & Resource Assignments 프로젝트 관리 Non Project Requests Lite-weight Project Planning & Resource Assignments Non Project Work Resource Assignment Complete Non Project Work

전사적 프로젝트 관리 예시 포트폴리오 관리사이트 • 프로젝트 등록 • 포트폴리오 선정 • 포트폴리오 평가 프로젝트 별 협업사이트 프로젝트 포털사이트 프로젝트 계획 및 관리 툴 • 프로젝트별 포털 사이트 • 문서 관리 • 게시판 • 이슈, 리스크 정보 공유 • 프로젝트 센터 • 자원 센터 및 분석 • 포트폴리오 분석 • 작업/Timesheet • 프로젝트 계획 수립 • 프로젝트 변경 관리 Outlook을 통한 작업 확인 및 입력 - 개인일정, 프로젝트 일정, 부서일정 통합관리

포트폴리오 관리 vs 프로젝트 관리 포트폴리오 관리 프로젝트관리 전략 사업전략지향 일정관리 위주 목표 전사사업, 목표 혹은 목적지향 (수익창출, 비용절감) 단위 프로젝트 비용 절감 목적 성과 비즈니스 성과를 중요시 단위 프로젝트 성과를 중요시 주요이해관계자 주주만족 프로젝트 관리자 만족 대상부서 마케팅, 영업 , 생산, R&D 포함 생산 및 R&D 위주 프로젝트영역 프로젝트의 선정 및 평가(협의)에 초점 수행만 집중관리 리소스활용 전사 리소스 분배 및 활용이 주목적 단위 프로젝트의 제한적 리소스 활용 현금 현금흐름과 이익도 고려함 비용(현금) 집행

포트폴리오 관리 개요 협의의 포트폴리오 프로젝트의 선정 및 평가에 초점을 둠 광의의 포트폴리오 선정, 수행, 평가의 프로젝트 Life Cycle 전체를 포함 선정 수행 평가 새로운 IT 제안 요구사항관리 프로젝트평가 투자여력분석 및 프로젝트 계획 수립 계획관리 프로젝트 평가결과 위험, 협력,조직, 형상 관리 Feedback IT 프로젝트 분석을 통한 서열화 운영유지보수 개선 우선순위 선정

포트폴리오 관리 기능 구성도

포트폴리오 관리 예시 비즈니스 드라이버를 정의하고 우선순위를 매기기 위하여 입증된 기술을 이용 우선순위를 선정한 비즈니스 드라이버에 대하여 각 프로젝트의 영향 평가 1 2 비즈니스 드라이버 프로젝트 비즈니스 드라이버 우선순위선정 영향 평가 프로젝트의 우선순위 선정 하기위해 각 프로젝트의 요구를 평가 (전략적 가치, 재정적 가치, 위험) 투자결정을 내리기 전에 프로젝트 포트폴리오 분석 4 3 프로젝트 우선순위 선정 투자 지도

임원 (CIO/팀장) • 전체 프로젝트 현황 모니터링 • 일정현황 모니터링 • 이슈,리스크,보고서 확인 프로젝트 종합적인 상황 분석 PMO • 전체 프로젝트 변경관리 • 전체 프로젝트 진행관리 • 전제 프로젝트 상황 분석 종합적인 포트폴리오 구성 프로젝트 종합관리 • 프로젝트 등록 • 세부작업 등록 • 자원할당 • 일정관리 • 산출물 관리 • 이슈,리스크,보고서 관리 프로젝트 계획/진행 관리 PM 프로젝트 관리 이슈/리스크 관리 문서관리 자원관리 프로젝트 진행정보 이슈/리스크 정보 자원할당 정보 문서정보 팀원 (PL,팀원) 개인별 작업할당 • 할당된 작업의 작업량 등록 • 이슈 등록 • 리스크 등록 TimeSheet/ 이슈/리스크 등록 프로젝트 관리 서비스 모델

프로젝트 관리 예시 1 2 프로젝트 관리 프로젝트 계획 4 3 작업 관리 자원 분석

전사적 프로젝트 관리 효과 프로젝트계획 수립/변경, 실적 입력 및 진행현황 파악을 쉽고 빠르게 수행하여 개발 효율성을 향상시키고 경영/관리층의 신속한 의사결정 지원을 가능케 합니다. 관리층 ▶ 의사결정 지원 정보 • 프로젝트 주요 정보 , Issue 및 비용 실시간 파악 관리(Staff) ▶ 프로젝트 관리 정보 ▶ 프로젝트 조정 기능 • 전체 프로젝트 실적 및 주요 이슈 관리 • 관리지표를 통한 프로젝트 성과 측정 P/L ▶ 프로젝트 관리 정보 • 체계적인 일정 계획 수립, 변경 및 이력 관리 기능 • 프로젝트 관리 Know-How 향상 및 타 Project 정보 공유 • 프로젝트 원가 정보 연계 (계획 대비 실적) 팀원(연구원) ▶ 담당 수행 업무 정보 • 개인별 업무 할당으로 수행 업무 명확화 • 관련 프로젝트간 진행 정보 공유 • 시스템을 통한 정보 공유 및 산출물 관리

분석, 설계 배포 플랫폼 선정 아키텍처 디자인 구현 관리, 모니터링 팀 개발 환경 구축 테스트 개발 중 개발 전 개발 후 Project Manager Business Modeler Developer Tester System Admin 프로젝트 개발 개요 • 프로젝트 개발 Life Cycle

프로젝트 개발 개요 • 프로젝트 개발의 단계별 주요내용

유지보수성 스마트 클라이언트 웹 애플리케이션 Windows Form 기능, UI 개발 전 – 계획과 준비 • 플랫폼 선정 • 애플리케이션 개발 시 구현 형태 결정 • 웹 애플리케이션 (ex. ASP.NET) • Windows 애플리케이션 (Client / Server) • 스마트 클라이언트 (Smart Client) • 분산 애플리케이션 (ex. COM+, .NET Remoting, 웹서비스)

개발 전 – 계획과 준비 • 애플리케이션 아키텍처 디자인 • 개요 • 크게 애플리케이션 아키텍처 (Application Architecture) 와 시스템 아키텍처 (System Architecture)의 두가지 종류로 분류 • 전체적인 애플리케이션을 계층화된 구성요소의 상관관계로 이루어진 구조로 나누는 것을 의미 • 각 구성요소의 성격과 특성 및 기능을 구분하며, 물리적으로 배치함으로써 분산(Distribution)의 효과 • 애플리케이션 아키텍처 • 논리적 아키텍처 (Logical Architecture)와 물리적 아키텍처 (Physical Architecture)로 구분 • 논리적 아키텍처 : 애플리케이션을 각 계층에서 어떠한 기능과 역할을 수행하는가 에 따라 논리적으로 분리한 것을 의미 (Presentation Layer, Business Logic Layer, Data Access Layer) • 물리적 아키텍처 : 논리적 계층(Layer)들을 실제 물리적으로 각 시스템 에 어떻게 배치할 것인가를 의미

개발 전 – 계획과 준비 • 애플리케이션 아키텍처 디자인 구성 예

개발 전 – 계획과 준비 • 시스템 아키텍처 • 네트워크 아키텍처, 하드웨어 아키텍처, 시스템 소프트웨어로 구분 • 네트워크 아키텍처 : 시스템 구축 시 전형적으로 나타나는 인터넷 및 인트라넷 구성으로 분류 • 하드웨어 아키텍처 : 데이터베이스 서버, 애플리케이션 서버, 웹 서버의 형태로 분류

개발 전 – 계획과 준비 • 팀 개발 환경 • 프로젝트 작업 내용에 따라서 역할을 분담하여 팀을 구성해서 개발하는 것 • 특징 • 다수의 인원이 동시에 개발, 각 구성원은 세분화된 역할을 가짐 • 구성원 간에 소스 또는 빌드 결과물을 참조, 공유 • 소스의 백업, 버전 관리가 필요 • 여러 단계로 세분화된 개발 프로세스가 존재

개발 중 – 설계와 구현 • 분석 및 설계 • 요구사항을 분석하여 기능 사용을 정의, 구현할 컴포넌트를 설계하는 단계 • 예시 • Microsoft의 CBD 개발 방법론인 MSF/CD (Microsoft Solution Framework/Component Design) • Conceptual, Logical, Physical 의 세가지 단계로 구분

개발 중 – 설계와 구현 • MSF/CD 설계 공정표 (1)

개발 중 – 설계와 구현 • Conceptual Design • 설계하고자 하는 업무에서 현재 사용자가 하는 일이 무엇이고, 비즈니스 요구사항이 무엇인지에 대해 이해하며 업무를 정의하는데 목적 • 수행 절차 • Business Process / 사용자 그룹에 대한 조사 • 데이터 취합 • 산출물 • Business Context Diagram • Workflow Process Diagram • Task Sequence (option) • Use Case Scenario • Task Sequence Diagram (option)

개발 중 – 설계와 구현 • Business Context Diagram • 개발할 시스템에 해당하는 비즈니스 도메인을 기준으로 사용자들, 프로세스, 시스템들 과의 관계에 대한 총체적인 View를 생성 • 중앙에 개발할 시스템을 크게 하나의 박스로 두고 그 외부에 사용자들, 프로세스, 시스템 들을 위치 • 그들 사이의 상호작용 및 이벤트를 화살표로 표시

개발 중 – 설계와 구현 • Workflow Process Diagram • 앞 단계의 Context Diagram으로부터 정의된 개발 업무의 내부 프로세스를 크게는 부서별, 작게는 한번에 처리하는 업무 단위까지 각 단계를 Level Down하며 서브 프로세스들로 나누어 정의 • Context Diagram상에 나타난 사용자들, 프로세스, 시스템 들과 그들 사이의 상호작용, 이벤트를 그대로 유지 • 첫번째 Level에서는 보통 부서별로 나누어 프로세스를 정의 • 두번째 이후 Level에서는 그보다 더 작은 단위로 나누어 보통은 3단계(한번에 처리하는 업무단위)까지 프로세스를 세분화하여 정의

개발 중 – 설계와 구현 • Use Case Scenario • Workflow Process Diagram의 마지막 Level에 기술된 업무에 대해 각각 상세한 업무절차를 서술형식으로 기술 • 사전준비사항 : 현재 업무 이전의 절차가 수행됨에 따라 발생되는 현재 업무의 Input에 대하여 기술 • 업무처리절차 : 사전준비사항의 Input을 가지고 업무를 처리하는데 있어 순서에 입각하여 구체적으로 명확한 비즈니스 로직 전개 • 사후처리사항 : 연속되는 다른 Use Case가 정상적으로 수행되도록 output에 대한 전달 및 통보와 같은 행위 기술

개발 중 – 설계와 구현 • Logical Design • 프로젝트 팀 구성원의 관점에서 개념 설계에서 요구하는 서비스를 만족시킬 수 있는 솔루션을 제시하는 것 • 수행 절차 • Service 항목에 대한 정의 • Object 항목에 대한 정의 • Attribute 항목에 대한 정의 • Relationship 항목에 대한 정의 • 산출물 • Object List • Object Interaction Diagram • Service Generalization • Pseudo Code (option) • Class Diagram • UI Sketch • Logical ERD

개발 중 – 설계와 구현 • Object List • 개념 설계의 Use Case Scenario에서 사용된 모든 명사들로부터 Object와 Attribute를 추출하며 일정한 분류기준에 의해 명사들을 Class로 묶는다. • 문서번호 : Use Case별 부여된 번호 • Use Case명 : Use Case의 Scenario명 • 명사 : Use Case에서 추출한 명사 • Class명 : 추출된 명사들을 분류하여 각 그룹을 대표할 만한 명사 • Attribute명 : 추출된 명사가 속한 Class에서의 역할에 맞게 부여되는 속성 이름

개발 중 – 설계와 구현 • Object Interaction Diagram • 각 시나리오의 업무 절차가 제대로 수행되는지 검증하고, Class의 서비스를 도출하기 위한 방법으로 사용, Use Case Scenario별로 작성 • 좌측 Use Case에는 Use Case Scenario롤, 우측 상단에 Object List에서 나타난 Class들을 가로로 배열 • Use Case에 나타난 각 처리 절차를 대상으로 Class간의 상호작용을 화살표와 함께 적절한 서비스명을 적고, Input/Output 파라미터를 기술 • 시스템으로 구현되지 않을 처리 절차는 제외하고 반영 • 사후처리사항도 하나의 트랜잭션 내에서 이루어져야 할 행위라고 판단되면 업무처리절차란에 기술하고 화살표로 표시

개발 중 – 설계와 구현 • Service Generalization • Object Interaction Diagram내에서 각 Class간에 화살표로 표기되었던 서비스명을 모두 모아서 각 Class별 Public 서비스들을 도출 • OID에 나타난 모든 서비스들을 모든 후에 같은 유형의 서비스들이 있는지 확인 • 해당 Class명, 서비스명, Input/Output 파라미터를 아래 예시와 같게 기술 • Use Case와 서비스들을 다시 검토하여 서로 빠진 것이 없는지 확인하고 추가 및 수정

개발 중 – 설계와 구현 • Class Diagram • Object List, Service Generalization 후 정의된 각 Class들을 기준으로 그들간의 상호관계를 찾아내고, 그 관계로부터 설계작업의 합리성을 점검 • Object List에 나타난 각 Class들을 정의 , 각각 Class에 속한 중요한 Attribute을 몇 개 (5개이내)와 Service Generalization의 모든 서비스들을 옮겨적는다. • 상호 작용이 있는 Class들을 찾아내어 서로 연결하는 화살표와 이름을 부여한다. • 업무의 흐름 및 상호관계로부터 그 합리성을 점검하고 조정

개발 중 – 설계와 구현 • UI Sketch • 고객의 입장에서 고객이 원하는 방식으로 화면을 편리하게 스크래치 하거나 디자이너에게 미리 주어 작성 • 사용자가 사용할 화면을 정의하고 이 때 발생하는 모든 Event를 표현 • 각 화면별 Navigation을 정의

개발 중 – 설계와 구현 • Logical ER Diagram • Object List 와 Service Generalization 이후에 그 산출물로부터 Entity와 Relation을 가진 논리적 ERD를 작성

개발 중 – 설계와 구현 • Physical Design • 개발자의 관점에서 구현하려고 하는 솔루션의 제약사항을 파악하여 실제 구현 가능한 솔루션을 제시하는 것 • 수행 절차 • 물리적 요구사항 파악 • Performance • Supportability • Technology • Availability 등 • 예비적인 배포 모델 안 수립 및 예비 구현 기술 선택 • 패키지와 배포 전략 수립 및 프로그래밍 모델 수립 • 컴포넌트 상세 명세 정의 • 산출물 • Component Interact Diagram • Application Structure • Component Specification • UI Specification • Physical ERD

개발 중 – 설계와 구현 • Component Interact Diagram • 논리설계에서 작성된 UI Sketch상의 조회,신규,삭제,저장 등의 이벤트들이 발생되었을 때 이 서비스를 제공하기 위하여 User Service / Business Service / Database Service의 3계층에서 존재하는 컴포넌트들이 각각 어떻게 상호작용 하는지를 도식화 • 1차와 2차 두 단계에 걸쳐 CID를 작성하며 1차에는 시스템 제한 사항을 고려하지 않고 단순히 각 이벤트에 대해 서비스를 제공하기 위한 컴포넌트들 간의 상호작용만을 기술, 2차에는 Network Topology, Data Topology, Component Topology 측면의 문제점들을 고려하여 재구성 • Client와 Server간의 Round Trip을 최소화, 관리용 또는 공통 Component를 생성, 활용 • Database에 관련된 작업만 처리하는 Data Service Component를 생성, 활용

개발 중 – 설계와 구현 • Application Structure • 실제 COM+에 등록할 Application의 모습, 각 Application에 어떤 Component DLL들이, 각각의 Component DLL에는 어떤 Class들이 포함될 것인지 결정 • 하나의 Application의 컴포넌트 개수는 20개 미만으로 권장 • Application Packaging은 Out-of-Process Communication이 최소화 되도록 한다. • 업무상 자주 Interaction이 일어나는 컴포넌트들을 모아서 Application으로 Packaging한다

개발 중 – 설계와 구현 • Component Specification • 확정된 Component DLL을 기준으로 하여 확정된 물리적인 사항에 대하여 Spec을 작성, 개발자가 이 문서만 보고도 컴포넌트를 생성시킬 수 있도록 구체화 • CID 작성시 도출된 관리 Component들을 포함하여 작성, 논리파일과 물리적인 테이블의 매핑 정보를 함께 기술 • Public 부분에는 컴포넌트에서 외부에 노출시킬 부분을 명시, Private 부분에는 내부적으로 처리할 부분을 명시

개발 중 – 설계와 구현 • UI Specification • 실제 사용할 UI를 작성, 화면별 특이사항을 기술하며 Workshop이나 프로젝트 관련 전체회의를 통해 최종적으로 화면에 대한 확인을 받는다 • UI Event별 사용할 Component 및 호출방식을 기술

개발 중 – 설계와 구현 • Physical ER Diagram • 확정된 ERD를 기준하여 이름, 크기 등 물리적인 테이블들의 구성 요소를 완성

개발 중 – 설계와 구현 • 구현 지침 • 공통적인 개발 환경 설정 및 프로젝트 구조 생성 • 개발 PC 환경 설정 • 운영 체제별 환경 설정 • 개발 환경 설정 • 코딩 시에 준수해야 할 명명 규칙 (Naming rule)과 주석 사용 지침

개발 중 – 설계와 구현 • 프로젝트 생성 및 구조 수립 • 프로젝트 구조 : 개발 도구 상에서의 프로젝트 파일 구조 및 환경 설정 • 폴더 및 파일 구조 : 디스크에 저장되는 물리적인 파일 시스템 • 네임스페이스 구조 : 소스 코드와 클래스들을 구분하기 위한 논리적인 단위 => 이 3가지 요소들이 모두 동일한 계층 구조를 가지는 것이 가장 바람직함

개발 중 – 설계와 구현 • 소스 프로젝트 구조 계획 • 솔루션 내에 1개의 마스터 프로젝트 템플릿과 n개의 업무별 프로젝트 템플릿을 만들도록 구성

개발 중 – 설계와 구현 • 명명 규칙 (Naming rule) • 구현 단계에서 코드 작성 시에 적용할 명명 규칙을 준수하여 작성함으로써 프로젝트 참가자 사이에 원활한 의사소통이 가능 • 각 단계별 산출물 사이에 일관성 유지 가능 • 일반사항 • 대소문자 혼용 • 약어 사용 자제 • 단어의 선정 • 네임스페이스 명명 규칙

프로젝트 관리 및 개발 방법론