1 / 77

Module Three: Project Planning

<<CMMI Based Software Process Practice for Outsourcing Project >>. Module Three: Project Planning. George Cao / 曹纪清 Created on Sep 29, 2010 Last revised on Mar 18, 2013. Purpose. Upon completing this module, you are expected to be able to:

kelsie-kidd
Télécharger la présentation

Module Three: Project Planning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. <<CMMI Based Software Process Practice for Outsourcing Project >> Module Three: Project Planning George Cao /曹纪清 Created on Sep 29, 2010 Last revised on Mar 18, 2013

  2. Purpose • 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

  3. Overview 1. Project Planning Process 2. Lifecycle & PDP 3. WBS and Estimation 4. Develop Project Plans 5. Project Plan Commitment

  4. Overview of the PP Activities The project planning process is mainly divided into these phases. 1. Develop Project Defined Process(PDP) 2. Work Breakdown and establish estimates 3. Develop project integrated plans 4. Obtain commitment to the plan

  5. Workflow of the PP Project Planning Workflow

  6. Overview 1. Project Planning Process 2. Lifecycle & PDP 3. WBS and Estimation 4. Develop Project Plans 5. Project Plan Commitment

  7. 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.

  8. 开发生命周期 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

  9. Waterfall Model瀑布模型

  10. Lifecycle Definition – SVW (标准V模型)

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

  12. 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.

  13. Evolutionary Prototyping model演化的原型模型

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

  15. Iterative Delivery Model迭代交付模型2013-3-20S115 横轴是过程展开的生命周期特征，包括阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴体现开发过程的静态结构，包括活动(Activity)和工作流.

  16. Why Choose Iterative Delivery Model? 多数客户想要尽早获得项目成果; 客户不确定他们的要求;同时,在首次软件发布日期之前，客户不会提出所有高水平的要求; 客户希望牢牢控制项目的周期和预算; 客户和开发者都想尽快消除项目中的风险(能不能按时做出来?能不能在预算内完成?有无技术和能力来完成?);

  17. Iterative Delivery Model – Instruction 第一次的迭代目标通常是开发一个系统核心的原型. 迭代计划是根据风险驱动的，每一次的迭代都基于上一次的结果分析； 迭代模型中的每个阶段(Phase)可以进一步分解为迭代周期(Iteration)。一个迭代周期是一个完整的开发循环(瀑布模型)，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。

  18. Initial– 先启阶段 先启阶段也称初始阶段。初始阶段的目标是确定项目的边界(scope范围),识别所有与系统交互的外部实体(external interface外部接口)，在较高层次上定义交互的特性（系统逻辑架构）。 本阶段所关注(里程碑)的是整个项目进行中的业务和需求方面的主要风险,需求概要,项目成功标准。

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

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

  21. Product –产品阶段 产品阶段的重点是确保软件对最终用户是可用的。 产品阶段一般由几次迭代构成:包括为最终(产品)发布(final release)做预备的产品测试(user acceptance test)，基于用户反馈的少量的调整。 在生命周期的这个阶段，用户反馈应主要集中在产品调整(不是新的需求)，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。　　在产品阶段的产品发布(Product Release)里程碑要确定目标是否实现，是否应该开始另一个开发周期（项目二期、三期… …）。

  22. Iterative Delivery Model – 计划编制 EHSS development schedule 我们只需要制定当前迭代周期的计划即可，到了迭代的后期才能确定什么需要在下个周期内完成的事情。一个迭代周期一般在2-5周之间。 在交付阶段（产品阶段）中，一般会根据需要设置三到五个的业务周期测试（即产品交付迭代周期），在每一轮的业务周期测试中都会需要进行回归测试，简单地说，也就是一轮业务周期测试一个发布的beta版本。 对于没有达到本次迭代计划要求的任务，办法有两种： 1）将剩余的工作列入下一次迭代计划中去， 2）将本次迭代的结束时间向后延迟，等待任务的完成

  23. 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.

  24. Agile Method敏捷方法 快速构建软件、提高生产率、更加快速地向市场交付、更好地响应变化的客户需求以及提供更高的软件质量是软件外包领域的一个显著特点，相对于CMMI庞大、重型的过程方法，轻量的敏捷(Agile)方法在一些特定的项目类型上很好地实现了这个目标。所以目前在软件外包企业中，越来越多的项目开始采用敏捷开发来管理项目。 2001年初，基于越来越多软件公司的团队陷入了不断增长的过程泥潭，一些业界专家聚集在一起归纳提出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。他们发表了著名的敏捷宣言

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

  26. 敏捷实践遵循的原则 从上述的价值观，引出了了敏捷方法的12条原则，它们是敏捷实践区别于重型过程的特征所在： 1.我们最优先要帮的是通过迟早的、持续的交付有价值的软件来使客户满意。 2.即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3.经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5.围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

  27. 敏捷实践遵循的原则2013-3-26S115 6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7.工作的软件是首要的进度测试标准。 8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9．不断地关注优秀的技能和好的设计会增强敏捷能力。 10.简单——使未完成的工作最大化的艺术————是根本的。 11.最好的构架、需求和设计出自于自组织的团队。 12.每隔一定时间，团队会在如何才能理有效地工作方面进行反省，然后相应地对自己的行为进行调整。

  28. 敏捷实践——极限开发Extreme Programming, XP 1． 客户参与 (Customer Engagement) 2. 用户素材(User Stories) 需求的细节很可能会随时间而改变，特别是当客户看到集成到一起的系统时，所以在离真正实现需求还很早时就去捕获该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注。用户素材就是正在进行的关于需求谈话的助记符，它是一个计划工具，项目团队和客户可以使用它并根据它的优先级和估算成本来安排实现该需求的时间。 3．小版本发布(Small Release) 4．验收测试(Acceptance Tests)： 用户素材的验收测试在实现之前或实现的同时进行编写。验收测试一般由客户指定的形式进来，用以获取有关用户素材的细节。验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为执行。

  29. 敏捷实践——极限开发Extreme Programming, XP 5. 结对编程(Pair Programming)： 所有的产品代码都是有程序员使用同一台电脑共同完成的，一个人写代码，一个人检查，互相讨论程序设计的问题，加强沟通，促进知识在团队中的传播。 结对的关系每天至少改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该与所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。

  30. 敏捷实践——极限开发Extreme Programming, XP 6. 测试驱动(Test-Driven Development) 在编码之前设计单元测试用例的好处，一是程序中每一项功能都有测试来验证它的操作的正确性。二是迫使程序员从程序调用者的角度去观察他将要编写的程序，即关注实现程序的功能的同时，直接关注它的接口，以设计出便于调用的软件。三是迫使程序员把自己的程序设计为可测试的。 易于调用与可测试使得程序必须和它的周边组件解耦。另外，这个测试文档也可以帮助其他程序员了解如何使用代码。

  31. 敏捷实践——极限开发Extreme Programming, XP 7. 代码集体所有权（Collective Code Ownership） XP中的代码集体所有权是指项目团队的所有成员都对整个项目的代码具有所有权，他们可以随时对任意的代码进行重构。XP实践中，只有结对编程并不断轮换才能在程序员之间彼此审查代码；只有代码集体所有权才能产生一对程序员看到其他程序员编写的代码并进行重构。

  32. 敏捷实践——极限开发Extreme Programming, XP 9. 可持续的开发速度(Sustainable pace) 为了快速地交付项目，XP团队必须要以一种可持续的稳定、适中的速度前进。XP的规则不允许项目团队加班工作，但在每个产品版本发布前的一个短时间内，如果发布目标就在眼前并且能够通过适当的加班达到的话则可以是例外。 10. 开放的工作空间(Open Workspace) 团队在一个开放的房间中一起工作。房间中有一些桌子。每张桌子上摆放了两到三台电脑，每台电脑前一般有两把椅子。墙壁上挂满了状态图表、任务明细表、UML图，等等。大家随时可以热烈讨论，团队的生产率成倍地提高。

  33. 敏捷实践——极限开发Extreme Programming, XP 11. 计划游戏(Planning Game) XP将整个项目规划为一个个小的迭代周期或交付周期，与客户一起确定每个用户素材的重要程度和优先顺序。计划游戏（planning game）的本质是划分业务和开发之间的职责。业务人员（也就是客户）决定功能的重要性，开发人员决定实现一个功能所花费的工作量。 在每次发布和迭代的开始，开发人员向客户提供一个估算，客户选择那些所需的工作量合计起来小于等于该估算的用户素材。开发者所提供的估算是基于他们在上一次迭代或者发布周期所完成的工作量的。客户基于对开发人员的开发速度的了解，能够确定项目会持续多长时间，以及会花费多少成本。

  34. 敏捷实践——极限开发Extreme Programming, XP 12.简单的设计(Simple Design) XP团队使他们的设计尽可能的简单、有表达力，他们仅仅关注于计划在本次迭代中要完成的用户素材，而不会考虑那些未来的用户素材。团队更愿意在一次次的迭代中不断地重构系统的设计，使之对正在实现的用户素材而言始终保持在最优的系统设计状态。 也就是说， XP团队的工作可能不会从系统基础架构开始，如选择数据库或者中间件等，而是先以最简单的可能方式实现第一批用户素材。只有当出现一个用户素材迫切需要基础架构时，他们才会引入该架构。

  35. 敏捷实践——极限开发Extreme Programming, XP 13．重构(Refactoring)： 在开发过程中，随着一个又一个的功能的增加、处理一个又一个的缺陷，代码的结构会逐渐退化，最终使得代码混乱而难于维护。XP团队通过经常性的代码重构来扭转这种退化。 重构就是在不改变代码行为的前提下，对其进行一系列持续的、小的改造，旨在改进系统结构的实践活动。每个改造都是微不足道的，几乎不值得去做。但是所有的这些改造叠加在一起，就形成了对系统设计和构架显著的改进。

  36. Overview 1. Project Planning Process 2. Lifecycle & PDP 3. WBS and Estimation 4. Develop Project Plans 5. Project Plan Commitment

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

  38. Procedures for PDP Develop Project Defined Process

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

  40. Overview 1. Project Planning Process 2. Lifecycle & PDP 3. WBS and Estimation 4. Develop Project Plans 5. Project Plan Commitment

  41. 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.

  42. Work Breakdown Structure(WBS) • 1．WBS的分解方式 • WBS可以由树形的层次结构图或者行首缩进的表格表示。在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。 • WBS的分解可以采用多种方式进行，包括： • 按产品的物理结构分解。 • 按产品或项目的功能分解。 • 按照实施过程分解。 • 按照项目的地域分布分解。 • 按照项目的各个目标分解。

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

  44. WBS template and samples 树型WBS 表格型WBS

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

  46. Practice 2013-4-9S115 Please update your HRMS schedule (2 versions) with the WBS technology(as detailed as you can).

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

  48. 估算的内容 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

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

  50. 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

More Related