Module Three: Project Planning

Module Three:

Project Planning

George Cao / 曹纪清

Created on Sep 29, 2010

Last revised on Mar 18, 2013

<<CMMI Based Software Process Practice for Outsourcing Project >>

Upon completing this module, you are expected to be able to:

• Have a rough understanding of general lifecycle• Understand the process of Agile and Iteration Model• The different Lifecycle definition and how to select them• Develop WBS and do general estimation method.• Understand the advantage and disadvantage of current estimation method.• How to create a project detailed schedule• Have a rough understanding of project integrated plan

Purpose

3. WBS and Estimation3. WBS and Estimation

4. Develop Project Plans4. Develop Project Plans

2. Lifecycle & PDP2. Lifecycle & PDP

1. Project Planning Process1. Project Planning Process

Overview

5. Project Plan Commitment5. Project Plan Commitment

The project planning process is mainly divided intothese phases.

1. Develop Project Defined Process(PDP)2. Work Breakdown and establish estimates3. Develop project integrated plans4. Obtain commitment to the plan

Overview of the PP Activities

Project Planning WorkflowWorkflow of the PP

Senior Manager EPG GroupProject Planning Group OutputInput

Integration plans:Project management plan;Project monitor and control plan;Resources plan;Training plan;Stakeholder management plan;Risk management plan;Review Plan;Process and product quality assurance plan;Configuration management plan;

Estimate project size, effort

,cost, budget resource etc

Develop integration

project plans

Develop project defined process

Review

Project manage based on project

plans

Project Close

Organization Asset;Lift cycle model;Organization Process;Measurement and analysis data;Tailor guideline;

Project is start-up

PDP

Yes

Approved

No

Submit experience data to organization

asset





Overview


What’s the Software Lifecycle

• The software lifecycle model describes the steps you follow to develop software from the initial concept stage to the release, maintenance, and subsequent upgrading of the software.

开发生命周期 Lifecycle Used in Novem

Suzsoft Lifecycle is defined as below:– Software Development Lifecycle

• Standard V-waterfall Lifecycle (SVW)• V-Waterfall Lifecycle for Critical Products (VC)• Four Phase V-Waterfall Lifecycle (V4)• Three Phase V-Waterfall Lifecycle (V3)• Staged Delivery Lifecycle (SD)• Unified Process(UP)• Evolutionary Prototyping Model• Iteration Development Model• Agile Method

– Software Maintenance Lifecycle– Software Migration 迁移，移民；移植 Lifecycle– Software Testing Lifecycle

Waterfall Model 瀑布模型

Lifecycle Definition – SVW ( 标准 V 模型 )

PI

ModuleModule

Unit

ST

Acceptance Test

RSO

ASO

DSOCSO

FC

SC

System TestPlan

Integration TestPlan

ModuleTestPlan

Control FlowData Flow

XXXCheckpoint that canbe signed off by the

Project Manager

SystemComplete

FunctionComplete

Code Sign OffDesign Sign

Off

ArchitectureSign Off

RequirementsSign Off

KO

ProjectKickoff

Acceptance Test Plan

System

Module Module Module

UnitUnit UnitUnitUnitUnit

Module

Unit Unit

UnitUnitUnit

Suggested forsystem shape:

LEGEND

Subsystem

Unit Unit

Subsystem Subsystem

DEL

Standard V-Waterfall Lifecycle

RA

HLD

LLD

CUT

IT

XXX

Checkpoint that isrecommended to besigned off by Senior

Management

DC

DeliveryComplete

CLS

Product Investigation Report/User Requirements/

SVW (Cont’d)

V 模型是一种面向测试的瀑布模型。单元测试 ( 对应详细设计 ) 检测代码的开发是否符合详细设计的要求。集成测试 ( 对应概要设计 ) 检测此前测试过的各组成部分是否能完好地结合到一起。系统测试 ( 对应需求分析 ) 检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试 ( 对应用户需求 ) 则检测产品是否符合最终用户的需求。

SVW (Cont’d)

• When to Use– The requirements are clear and definite relatively, and

expected to be stable.– The solution, technology and architecture are clear and

definite relatively.– A higher need for maintainability.– A higher need for stability, visibility, and controllability.

• Advantage– A higher visibility to management.– Project progress can be controlled easily if the requirements

are stable.• Disadvantage

– Not suitable for unclear or unstable requirements.– It will cause management burden because it needs to

generate much more documents.– All project stakeholders need to verify and sign off the results

at the end of every phase.– It will cause a big workload if the project scope changes.

Evolutionary Prototyping model 演化的原型模型

General Lifecycle Type – Staged Delivery Model 分阶段交付模型

Iterative Delivery Model 迭代交付模型 2013-3-20S115

横轴是过程展开的生命周期特征，包括阶段 (Phase) 、迭代(Iteration) 和里程碑 (Milestone) ；纵轴体现开发过程的静态结构，包括活动 (Activity) 和工作流 .

Why Choose Iterative Delivery Model?

• 多数客户想要尽早获得项目成果 ;• 客户不确定他们的要求 ; 同时 , 在首次软件发布日期之

前，客户不会提出所有高水平的要求 ; • 客户希望牢牢控制项目的周期和预算 ; • 客户和开发者都想尽快消除项目中的风险 ( 能不能按时

做出来 ? 能不能在预算内完成 ? 有无技术和能力来完成 ?);

Iterative Delivery Model – Instruction

• 第一次的迭代目标通常是开发一个系统核心的原型 .• 迭代计划是根据风险驱动的，每一次的迭代都基于上一次

的结果分析；• 迭代模型中的每个阶段 (Phase) 可以进一步分解为迭代周

期 (Iteration) 。一个迭代周期是一个完整的开发循环 ( 瀑布模型 ) ，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。

Initial– 先启阶段

• 先启阶段也称初始阶段。初始阶段的目标是确定项目的边界 (scope 范围 ), 识别所有与系统交互的外部实体 (external interface 外部接口 ) ，在较高层次上定义交互的特性（系统逻辑架构）。

• 本阶段所关注 ( 里程碑 ) 的是整个项目进行中的业务和需求方面的主要风险 , 需求概要 , 项目成功标准。

Refine - 精化阶段

　　　本阶段具体内容 : 确定系统的体系结构(Architecture 概要设计 ), 编制项目计划 (Project Plan), 同时为项目建立支持环境 (Support Environment) ，包括开发准则并预备工具。　本阶段结束时的里程碑：建立项目总体计划和系统总体架构设计和开发环境等必要支持要素。

Construction - 构建阶段

　在构建阶段，所有剩余的需求分析、设计和应用程序功能被开发并集成为产品，所有的功能被具体测试。　　　　构建阶段结束时的里程碑：决定了产品是否可以在客户环境中进行部署。此时的产品版本也常被称为“ beta” 版。（ alpha/beta release ）

　

Product – 产品阶段

• 产品阶段的重点是确保软件对最终用户是可用的。• 产品阶段一般由几次迭代构成 : 包括为最终 ( 产品 ) 发布

(final release) 做预备的产品测试 (user acceptance test) ，基于用户反馈的少量的调整。

• 在生命周期的这个阶段，用户反馈应主要集中在产品调整 ( 不是新的需求 ) ，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。　　　　在产品阶段的产品发布 (Product Release) 里程碑要确定目标是否实现，是否应该开始另一个开发周期（项目二期、三期… …）。

Iterative Delivery Model – 计划编制

• EHSS development schedule

• 我们只需要制定当前迭代周期的计划即可，到了迭代的后期才能确定什么需要在下个周期内完成的事情。一个迭代周期一般在 2-5 周之间。

• 在交付阶段（产品阶段）中，一般会根据需要设置三到五个的业务周期测试（即产品交付迭代周期），在每一轮的业务周期测试中都会需要进行回归测试，简单地说，也就是一轮业务周期测试一个发布的 beta 版本。

• 对于没有达到本次迭代计划要求的任务，办法有两种： 1 ）将剩余的工作列入下一次迭代计划中去， 2 ）将本次迭代的结束时间向后延迟，等待任务的完成

Microsoft Project ÎÄµµ

Practice

You are required to establish a schedule with MS Project in SVW and Iteration lifecycle based on the requirements included in HRMS SOW

and hand in before next class.

Agile Method 敏捷方法

快速构建软件、提高生产率、更加快速地向市场交付、更好地响应变化的客户需求以及提供更高的软件质量是软件外包领域的一个显著特点，相对于 CMMI庞大、重型的过程方法，轻量的敏捷 (Agile) 方法在一些特定的项目类型上很好地实现了这个目标。所以目前在软件外包企业中，越来越多的项目开始采用敏捷开发来管理项目。

2001年初，基于越来越多软件公司的团队陷入了不断增长的过程泥潭，一些业界专家聚集在一起归纳提出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。他们发表了著名的敏捷宣言

敏捷宣言

1. 个人和交互胜过过程和工具 2. 可以工作的软件胜过面面俱到的文档 3. 客户合作胜过合同谈判 4. 响应变化胜过遵循计划

敏捷实践遵循的原则

• 从上述的价值观，引出了了敏捷方法的 12条原则，它们是敏捷实践区别于重型过程的特征所在：

• 1.我们最优先要帮的是通过迟早的、持续的交付有价值的软件来使客户满意。

• 2.即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

• 3.经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

• 4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

• 5. 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

敏捷实践遵循的原则 2013-3-26S115

• 6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

• 7. 工作的软件是首要的进度测试标准。• 8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户

应该能够保持一个长期的、恒定的开发速度。• 9．不断地关注优秀的技能和好的设计会增强敏捷能力。• 10.简单——使未完成的工作最大化的艺术————是根本的

。• 11. 最好的构架、需求和设计出自于自组织的团队。• 12. 每隔一定时间，团队会在如何才能理有效地工作方面进行反省，然后相应地对自己的行为进行调整。

敏捷实践——极限开发 Extreme Programming, XP

1．客户参与 (Customer Engagement)

2. 用户素材 (User Stories)

需求的细节很可能会随时间而改变，特别是当客户看到集成到一起的系统时，所以在离真正实现需求还很早时就去捕获该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注。用户素材就是正在进行的关于需求谈话的助记符，它是一个计划工具，项目团队和客户可以使用它并根据它的优先级和估算成本来安排实现该需求的时间。

3．小版本发布 (Small Release)

4．验收测试 (Acceptance Tests) ：用户素材的验收测试在实现之前或实现的同时进行编写。验收测试一般由客户指定的形式进来，用以获取有关用户素材的细节。验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为执行。


• 5. 结对编程 (Pair Programming) ：– 所有的产品代码都是有程序员使用同一台电脑共同完成的，一个人写代

码，一个人检查，互相讨论程序设计的问题，加强沟通，促进知识在团队中的传播。

– 结对的关系每天至少改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该与所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。


• 6. 测试驱动 (Test-Driven Development)– 在编码之前设计单元测试用例的好处，一是程序中每一项功能都有测试

来验证它的操作的正确性。二是迫使程序员从程序调用者的角度去观察他将要编写的程序，即关注实现程序的功能的同时，直接关注它的接口，以设计出便于调用的软件。三是迫使程序员把自己的程序设计为可测试的。

– 易于调用与可测试使得程序必须和它的周边组件解耦。另外，这个测试文档也可以帮助其他程序员了解如何使用代码。


• 7. 代码集体所有权（ Collective Code Ownership ）– XP 中的代码集体所有权是指项目团队的所有成员都对整个项目的代码具

有所有权，他们可以随时对任意的代码进行重构。 XP 实践中，只有结对编程并不断轮换才能在程序员之间彼此审查代码；只有代码集体所有权才能产生一对程序员看到其他程序员编写的代码并进行重构。


• 9. 可持续的开发速度 (Sustainable pace)– 为了快速地交付项目， XP团队必须要以一种可持续的稳定

、适中的速度前进。 XP 的规则不允许项目团队加班工作，但在每个产品版本发布前的一个短时间内，如果发布目标就在眼前并且能够通过适当的加班达到的话则可以是例外。

• 10. 开放的工作空间 (Open Workspace)– 团队在一个开放的房间中一起工作。房间中有一些桌子。每张桌子上摆放了两到三台电脑，每台电脑前一般有两把椅子。墙壁上挂满了状态图表、任务明细表、 UML图，等等。大家随时可以热烈讨论，团队的生产率成倍地提高。


• 11. 计划游戏 (Planning Game)– XP将整个项目规划为一个个小的迭代周期或交付周期，与客户一起确定

每个用户素材的重要程度和优先顺序。计划游戏（ planning game ）的本质是划分业务和开发之间的职责。业务人员（也就是客户）决定功能的重要性，开发人员决定实现一个功能所花费的工作量。

– 在每次发布和迭代的开始，开发人员向客户提供一个估算，客户选择那些所需的工作量合计起来小于等于该估算的用户素材。开发者所提供的估算是基于他们在上一次迭代或者发布周期所完成的工作量的。客户基于对开发人员的开发速度的了解，能够确定项目会持续多长时间，以及会花费多少成本。


• 12.简单的设计 (Simple Design)– XP团队使他们的设计尽可能的简单、有表达力，他们仅仅

关注于计划在本次迭代中要完成的用户素材，而不会考虑那些未来的用户素材。团队更愿意在一次次的迭代中不断地重构系统的设计，使之对正在实现的用户素材而言始终保持在最优的系统设计状态。

– 也就是说， XP团队的工作可能不会从系统基础架构开始，如选择数据库或者中间件等，而是先以最简单的可能方式实现第一批用户素材。只有当出现一个用户素材迫切需要基础架构时，他们才会引入该架构。


• 13．重构 (Refactoring) ：– 在开发过程中，随着一个又一个的功能的增加、处理一个又一个的缺陷

，代码的结构会逐渐退化，最终使得代码混乱而难于维护。 XP团队通过经常性的代码重构来扭转这种退化。

– 重构就是在不改变代码行为的前提下，对其进行一系列持续的、小的改造，旨在改进系统结构的实践活动。每个改造都是微不足道的，几乎不值得去做。但是所有的这些改造叠加在一起，就形成了对系统设计和构架显著的改进。





Overview


Develop Project Defined Process

通过 CMMI3 以上认证的公司在本组织内建立了一套组织标准过程库（ Organizational Standard Process, OSP ）。但是这并不是说这些过程、知识和技能可以在任何时候一成不变地应用于所有的项目。在 CMMI 中明确提出了在项目的计划阶段，项目经理必须根据项目的实际情况，在组织级过程规范的基础上确定适合于本项目的过程，这个过程叫“裁剪 (tailoring)” ，最终结果是定义了某一具体项目的过程规范。

Project Defined Process, PDP建立《项目已定义过程》

Develop Project Defined ProcessProcedures for PDP

Inputs Tailoring guidelineOrganization Standard Process

Steps Analyze project characteristic and project typeAnalyze customer requirements , defined project type.Define project lifecycleSelect and refine a software model for the project to address interdependencies and appropriate sequencing of software project activities.Ref :Life Cycle MethodDevelop PDPPM, DM, TL and other stakeholders develop PDP

based on tailoring guideline and project type and characteristic.

Major activity or process tailor need to approved by EPG team.

Outputs Approved PDP

Develop PDP

下面是 EHSS项目定义过程文档（ EHSS Project Defined Process）的样例，分别包括对工程类、管理类和支持类三大类过程的活动及输出物的裁剪：

Microsoft Office Excel 97-2003 ¹¤×÷±í





Overview


Work Breakdown Structure(WBS)2013-4-2S115

　　 WBS (Work Breakdown Structure 工作分解结构 ) is also known as work breakdown system. It is a map of the project that identifies the products and work elements involved in a project. WBS is an outline of the project with different levels of details, it defines the relationship of the final deliverable to its sub-deliverables, and in return, their work packages. 　　 WBS helps to assume project managers that all the work are identified and established.

Work Breakdown Structure(WBS)

1 ． WBS 的分解方式　　 WBS 可以由树形的层次结构图或者行首缩进的表格表示。在实际应用中，表格形式的 WBS 应用比较普遍，特别是在项目管理软件中。

WBS 的分解可以采用多种方式进行，包括：•按产品的物理结构分解。•按产品或项目的功能分解。•按照实施过程分解。•按照项目的地域分布分解。•按照项目的各个目标分解。

Work Breakdown Structure(WBS)

　　 2．创建 WBS 的过程　　　　 a. 得到项目工作说明书 (Statement of Work ， SOW) 。　　 b. 建立项目策划组，集体讨论所有主要项目工作，确定项目工作分解的方式 ( 生命周期 ) 。　　 c. 分解项目工作。如果有现成的模板，应该尽量利用。　　 d. 画出 WBS 的层次结构图。 ( 子项目 , 生命周期 , 阶段 ) e. 将主要任务 / 活动细分为更小的、易于管理的组分或工作包 ( 必须详细到可以对该工作包进行准确估算 ) f .随着其他计划活动的进行，不断地对 WBS更新或修正，直到覆盖所有工作。

　　

WBS template and samples

Microsoft Office Visio Ä£°å

Microsoft Project ÎÄµµ

树型 WBS

表格型 WBS

Exercises

　　 Please develop a WBS with MS Project for HRMS based on the SOW.

Practice 2013-4-9S115

　　 Please update your HRMS schedule (2 versions) with the WBS technology(as detailed as you can).

Review

　　 1. What are the steps to do WBS? 2. What is the criteria to judge if the WBS is finished?

估算的内容

• Estimate Contents– Scale/Size 规模

• KLOC :line of code, Use case, Function Point, etc

– Effort, Cost • Man Day, man hour; RMB,US$, etc

– Schedule • Duration 工期 , Start date, End date

– Resource• Number of each roles

估算的影响因素

• Estimate Factors影响估算的因素– Project Type– Development Technology– Productivity– Lifecycle Model– Project Complexity ,etc

General Estimation Method 常用的估算方法

• Line of Code• Delphi (Expert Judgment)• Top-down• Bottom-up• FPA (Function Points Analysis)• Use Case points• Pert (Program Evaluation and Review Techniques)

* 主观估算法 Subjective 、客观估算法 Objective

Line of Code 代码行法 ( 估算工作量 , 生产率 )

• Procedure– WBS (functions)– Estimate the scale (K LOC).– Calculate the effort according to the productivity.

* productivity= total effort/KLOC• Advantage

– Easy to understand.• Disadvantage

– Difficult to get the data at the beginning of project.– Normally used combined with other methods.

Delphi 专家判断法（任何估算项）（ Expert Judgment ）

• Procedure– Selection of one or more panels （专家）小组 to participate in

the exercise. Customarily, the panelists小组成员 are experts in the area to be investigated.

– Development of the first round Delphi questionnaire 问卷– Analysis of the first round responses – Preparation of the second round questionnaires– Analysis of the second round responses

(Former steps are re-iterated 迭代，重复 as long as desired or necessary to achieve stability in the results.)

– Preparation of a report by the analysis team to present the conclusions of the exercise

• Advantage– Need not the historical data, suit for new project

• Disadvantage– Too Subjective– Base on the level of experts, sometimes the estimation result is

not correct.

Delphi Personal Estimation Form 个人估算表

Delphi Final Estimation Form 最终估算表

Practice

Try to discuss and estimate the efforts (man hour) for the HRMS WBS with Delphi(at leaset 2 rounds) in groups.

Top-down ( 自上而下法，经常与 bottom-up 结合使用 )

• Procedure– Estimate the total effort– Divide the effort to each stage(phase 项目的阶段 ) or

each activities– Continue divide the effort for each stage or activities.

• Advantage– The effort for estimation is small– The time used for estimation is small

• Disadvantage– The consideration is not sufficient and sometimes it

may miss 遗漏 some parts of project.

Bottom-up 自下而上法，一般结合其他方法，常用

• Procedure– Develop WBS– Estimate the scale or effort of each activities– Summarize them to the total value.

• Advantage– The estimation of each part is accurate .

• Disadvantage– It may miss遗漏 some parts , sometimes the

estimation value is less than actual.

Use Case Points（用例点法） 2013-4-10S111

• Procedure– Generate the Use case– Assign the Actor weight and Use case Weight to each Use case.– Calculate the UUCP (Unadjusted Use Case Points)

• UUCP＝∑ Actor Weight +∑UseCase Weight – Considering the environment factor and technical factor and get

the AUCP (Adjusted Use Case Points) • AUCP=UUCP×TCF×EF

– Base on AUCP & Factor (Scale<->Effort) to get the Effort.

• Advantage– Suit for the Object-orientation Project

• Disadvantage– The adjust fact must be base on the experience.

– 详见打印材料

Use Case Points（练习） 2013-4-11

– 要求按照论文的方法，估算 HRMS 项目的工作量（先按照顶层用例 high level use case 的方式来估算）

Use Case Points

1. 识别用例（角色，高层、底层用例；步骤数；：管理员、人事经理、人事专员、职员）；

2. 确定角色的权重 -- 所操作用例的业务复杂性；

3. 确定用例的权重 -- 基本流的步骤数；4. UUCP ，基于角色权重及用例权重的累加值5. 评估本系统包括的影响因子：技术、环境的6. 计算技术因子和环境因子的累加值；7. 计算 ACUP-- 基于影响因子的“调整的用例点”；

8. 计算项目的工作量 ( 生产率 )

Steps to Create the Project Schedulein MS Project

• Create WBS in MS project• List the lifecycle with phases• List the milestone and deliverables• Further divide and makeup the tasks for each phase• Analyze the dependence of each tasks• Assign resources and start/end date for each task• *Confirm the Critical Path for the project schedule• *Check if there are the issues like overloaded and adjust

Practice

• To revise the HRMS schedule based on the project planning methods.

—Delivery date: April 23, next Tuesday

知识拓展：关键路径 (Critical Path)

• 在项目管理中，关键路径 (Critical Path) 是指项目活动序列网络（箭线）图中终端元素的序列，关键路径的工期决定了整个项目的工期。任何关键路径上的终端元素的延迟将直接影响项目的预期完成时间。一个项目可以有多个，并行的关键路径。

• 关键路径法 (Critical Path Method ， CPM) 是一种项目计划管理方法。它是通过分析项目过程中哪个活动序列进度安排的总时差最少来预测项目工期的网络分析方法。它用网络图表示各项工作之间的相互关系，找出控制工期的关键路线，在一定工期、成本、资源条件下获得最佳的计划安排，以达到缩短工期、提高工效、降低成本的目的。

Project Crashing 项目赶工S115 2013-4-16

缩短关键路径 (Critical Path) 上任务的工期或工时。更改任务限制，以增加日程排定的灵活性。更改任务相关性，以增加日程排定的灵活性。在适用的相关任务间设置前置重叠时间。将关键任务（指 CP 上的任务）分解成多个由不同资源同时进行的小任务。排定加班工时。为关键路径上的任务分配额外资源。采用迭代及敏捷方法的开发模型理念





Overview


Develop Project Plans

A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.

When making the project plan, we should consider all the phases of the project life cycle. Project planning should ensure that all plans affecting the project are consistent with the overall project plan.


Entry Criteria

WBS is establishedEstimates containing cost, effort, and size have been establishedProject life-cycle is defined

Steps

1

Identify and analyze project risksReferring to the Organizational Risk Database, to develop a risk management plan, which include risk management mechanism, risk list, impact, possible ， risk tracking frequency , risk tracking tools ,preventive action and priority

2 Plan for data managementData management include paper documents (hard copy)management and electronic documents(soft copy) management

3 Define Project Control StrategiesDefine project monitor and control mechanism , frequency and responsible party

4 Resources planResources list include employee, software, hardware etc.

Project Plans Development Procedures

Step

5

Define communication mechanism with stakeholdersDevelop a stakeholders management plan, List stakeholders name, impact ,communication mechanism, communication frequency, expected result, dependency risk and issue then monitor and control stakeholders follow by stakeholders management plan.

6 Define a measurement and analysis planIdentify the measurement item according to organization object and project information.Determine the measurement time, responsibility, tools and measurement period.

Project Plans Development Procedures


Steps 7

Develop quality control planQuality plan includes: technical review and milestone

8 PPQA Action PlanPPQA develop a PPQA plan, define PPQA activities and work product

9 Management for integration planIncorporate 合并，混合，一体化 all project plans(Training Plan, CM Plan, PPQA Plan, Project Management Plan, Risk Management Plan, Stakeholder Management Plan and Measurement Analysis Plan) into the detailed development plan ,PM coordinate 整合，调整 each plans to ensure the effective use of resources

Project Plans Development Procedures20111020S2

Develop Project Plans–

Project Management Plan 20111026S1 PPQA Plan (later) Configuration Management Plan (later) Measurement and Analysis Plan (later) Risk Management Plan 20111024S2 Training Pan (later) Stakeholder Management Plan Project schedule





Overview


Project Plans Commitment

To be effective, plans require commitment from those who are responsible for implementing and supporting the plans.

Project Plans Commitment

Steps

1

Review plans that affect the projectPM,DM,QA Leader and other stakeholders review all project plans include CM plan, PPQA plan, measurement plan ,risk management plan, training plan and project management plan then document the review result in Project Plan Review Record.——20111031S3

2 Reconcile 使一致 work and resource levelsReconcile any differences between the estimate and

the available resources. Revise all plans that affect the project or schedule.

3 Obtain plan commitmentObtain all relevant stakeholders’ commitment to the project, and document the review result.

Outputs Records of the review of plans that affect the projectBaseline is establishedApproved project plans

Project Plans Commitment Procedures

Project Plan Review Record/Report20111031S1

Microsoft Office Excel 97-2003 ¹¤×÷±í

Project Plan Review Checklist

项目计划评审报告比较简单，除了要求记录发现的问题记录，结论只有两种情况：

[ ] 同意通过。有关问题在会后修改。 [ ] 不同意，需要进一步修改。

对于第二种情况，修改后需要重新提出评审申请

最后这个结果需要 PMO经理的签字确认。

ITO Terms for PP-20111103S3

Project Defined Process (PDP), Iteration Delivery Model, V-waterfall Lifecycle, Agile Method , Waterfall, Staged Delivery Lifecycle, Evolutionary Prototyping Model, Unified Process, Milestone, Business Modeling, Activity, Organizational Standard Software Process (OSSP), OPAL, Inspection, Four Eyes, Walkthrough, Verification(VER), formal review, Pert, Possible Value, Pessimism[‘pesimizəm] , Optimism , Delphi, Questionnaire (survey) , Bottom-up , Top-down, Work Breakdown Structure(WBS), roll-out[rəul’aut] 推进，实施 (implematation), Man Head, Schedule, System Nursing (maintenance), Estimation , Critical Path(CP), Development Model ,Construction(coding), Transition 过度、转移 , Project Management Plan (PMP), Configuration Management Plan(CMP), SVN(VSS), CCB (change control board), Backup, Recovery, Commitment, Checklist, RA, HLD, LLD, CUT, IT, ST, Extreme Programming(XP) , Pair Programming , Stand up Meeting , Statement of Work , Scale(size-FP,UCP,LOC,PAGE), Effort, Resource, Line of Code (LOC), Productivity(=total effort/total scale), Duration, Baseline, Configuration Item, Stakeholder , Mitigation action, Threshold, Use Case Point(UCP), Function Point(FP)

Review

1. If a project size is big ,duration is long and the requirements are easy to change, which kind of lifecycle will you want to select?

2. What’s the advantage of Iteration compared to Waterfall?

3. Please list some principals of Agile Method.

4. Please introduce at least one estimation method you learnt.

6. What factors will affect the result of estimation?

7. How to reduce the duration of a project?

Documents

Module Three: Project Planning