CMM过程规范培训-启动计划阶段课件

2004/03/23CMM过程规范培训实践培训-启动计划阶段活动作者：高勇版本：1.12004/03/23CMM过程规范培训实践培训-启动计划阶段1流程图软件过程定义项目经理系统分析员WBS分解项目估算项目启动计划项目经理系统分析员设计人员QAP生命周期模型定义的软件过程软件估计书工作任务拆分表立项项目经理项目计划项目经理批准CMPSDPSMPICP各组组长STP流程图软件过程项目经理WBS分解项目估算项目启动计划项目经理2PM：过程定义，组织WBS、EST，完成CR、PPSystemAnalyst：整理CR，进行WBS、ESTQAManager：QAP、提供规范支持、审计CMManager：CMP、建立配置控制库TSManager：TSPSEPG：评审过程定义结果SeniorManager：批准PD、PP角色及职责PM：过程定义，组织WBS、EST，完成CR、PP角色及职责3制定启动计划需求活动选择生命周期模型和过程定义项目WBS风险识别、项目估算完成计划项目计划评审其它工作目录制定启动计划目录4制定启动计划入口：项目已立项输入：立项建议书活动：识别本阶段活动的内容确定活动顺序、工作量、安排资源文档化、审批输出：项目启动计划出口：启动计划通过高层经理批准制定启动计划入口：项目已立项5制定启动计划启动计划应涵盖启动准备、计划两方面工作客户需求调研、文档化软件需求分配、制定需求验收准则生命周期选用、项目过程定义WBS活动和估计活动开发和其他支持计划的制定评审活动风险管理、工具引入活动技术和管理的培训活动制定启动计划启动计划应涵盖启动准备、计划两方面工作6客户、系统需求活动入口：启动计划通过输入：启动计划、来自客户和市场的资料、上一版本产品的资料和市场反馈活动：需求获取需求分配需求评审输出：CR、SR、需求验收准则表出口：工作产品获得批准客户、系统需求活动入口：启动计划通过7客户、系统需求活动客户需求、软件系统需求作为整个项目工作的基础，对其的归纳和整理应注意满足：文档结构清晰，内容无冗余，可读性好对需求的描述易于理解，不存在二义性术语一致，需求项间没有冲突描述的结果能准确反映客户的真实需求需求是完整的，没有遗漏也没有增加含有性能需求需求是可追溯和可验证的需求验收准则是具体的可度量的、完整的客户、系统需求活动客户需求、软件系统需求作为整个项目工作的基8客户、系统需求活动剪裁准则：活动可剪裁属性选择剪裁指导方针系统需求分配形成《软件系统需求》执行执行需要在《客户需求》的基础上进一步给软件开发项目组分配客户需求。不执行《客户需求》可直接分配给软件开发项目组。客户、系统需求活动剪裁准则：活动可剪裁属性选择剪裁指导方针系9生命周期和过程定义入口：软件系统需求通过评审输入：软件系统需求，组织软件生命周期、标准软件过程描述文件，剪裁准则活动：选用生命周期模型根据组织标准软件过程剪裁定义项目过程形成文件，报SEPG评审，并得到高层批准输出：项目定义软件过程出口：过程定义获得批准生命周期和过程定义入口：软件系统需求通过评审10生命周期和过程定义选择项目生命周期瀑布式增量式原型式可剪裁的过程系统需求分配（客户需求可直接分配给项目组）概要设计（系统规模较小，层次少，结构简单，文件可与详细设计合并编写）系统测试（集成测试包含对系统功能的测试）生命周期和过程定义选择项目生命周期11项目WBS入口：过程定义完成输入：过程定义文件、系统需求活动：识别工作产品用WBS定义技术活动用WBS定义管理支持活动输出：工作任务拆分表出口：WBS结果文档化项目WBS入口：过程定义完成12项目WBSWBS活动要点识别工作产品，任务大多是根据所要产生的工作产品定义的是一个迭代过程在项目早期定义WBS的高层元素详细任务的定义可以分阶段完成一般不会超过5层在定义最低层元素时，考虑“80小时原则”注意对管理支持活动的拆分：项目管理（如：例会、批准产品活动等）、QA、CM等。项目WBSWBS活动要点13项目WBS建议的WBS第一级分类需求管理项目计划项目跟踪系统设计系统编码系统测试质量保证配置管理项目立项项目培训管理评审技术评审组间协调项目内其他活动项目外其他活动项目WBS建议的WBS第一级分类项目立项14项目WBS举例说明WBS某一项分类的分解：一级分解二级分解三级分解需求管理需求获取需求调研分配系统需求形成需求验收准则需求分析定义词汇表定义系统接口标准需求定义需求管理需求状态跟踪需求追溯需求变更项目WBS举例说明WBS某一项分类的分解：一级分解二级分解三15风险识别与管理入口：WBS完成输入：立项建议书、CR、工作任务拆分表活动：识别风险分析风险制定风险管理计划输出：风险减缓活动日志出口：批准风险减缓活动日志风险识别与管理入口：WBS完成16风险识别与管理风险识别、管理活动要点是一个迭代过程，贯穿项目过程始终风险管理不是项目经理一个人的事，建立一种有助于对潜在风险及其发生的可能性和影响进行交流的环境对项目经理来说是重要的在项目估算前进行潜在风险不等于风险类型：规模、结构、技术风险分析：可能性、影响、风险值、风险等级处理途径：避免、转移、接受、减缓风险识别与管理风险识别、管理活动要点17项目估算入口：风险已识别输入：工作任务拆分表、风险日志、CR活动：估计规模、工作量（技术、管理、支持）估计外部成本、关键计算机资源（包括培训）制定进度表（关键路径、里程碑）建立项目基准（计算BCWS）输出：软件估计书、项目进度表出口：估计结果得到批准项目估算入口：风险已识别18项目估算估计过程步骤相关过程步骤项目计划过程项目跟踪过程1建立估计：项目经理收集输入数据并计算估计2评审估计：项目经理和项目组成员评审和修订估计数据3更新历史项目数据库：从完成的项目中收集数据加入到估计基础库中识别约束：给人员、进度和功能提供约束输入用评审和批准的估计更新项目计划承诺批准：接受批准或者重新确定约束或重新计划项目在开发阶段收集跟踪数据结项变更项目估算估计过程步骤相关过程步骤项目计划过程项目跟踪过程1建19项目估算估计策略内容确定估计内容确定估计时间确定估计技术确定估计粒度估计原则两周原则项目估算估计策略内容20项目估算估计策略检查表#内容1项目是什么类型（新开发、移植、升级、改善）2客户需求已经确定了吗3软件需求已经定义了吗4我们对需求的了解程度如何5需求的稳定性如何6我们是否有可靠的和可用的历史数据7项目将采用什么样的处理模型（瀑布、增量）8项目的结构是什么9主要的风险是什么项目估算估计策略检查表#内容1项目是什么类型（新开发、移植、21项目估算估计策略方案1：情况：客户需求很好的定义，不会有很多变化；开发人员有足够业务经验；工程处理和以前项目相近；企业有可靠的历史数据。策略：项目定义时为整个项目作高级别的估计每个阶段开始前进行详细的阶段估计详细阶段估计时更新高级别估计项目估算估计策略方案1：22项目估算估计策略方案2：情况：客户需求未很好的定义或未被开发人员阅；企业缺乏该应用领域和所使用技术的经验；策略：开始时只估计需求定义阶段；完成需求定义阶段后，准备设计阶段的详细估计和其余阶段的粗略估计；每个阶段开始时进行详细阶段估计，如有必要，对余下阶段修改高级别估计项目估算估计策略方案2：23项目估算规模估计方法WidebandDelphiTechniquePertSizingTechniqueSizingByAnalogyReusedCode建议用两种以上的方法进行估计，不要单独依靠任何一个方法。项目估算规模估计方法24项目估算Delphi方法下发软件系统需求和估计用表格召集会议，讨论有关软件规模的问题每人匿名填写估计表格收集估计表格，形成反馈给参加估计的人召集会议，讨论估计上的差异每人根据讨论结果，提交另一个匿名的估计重复4-6直到达到关于软件规模的最大程度的一致项目估算Delphi方法25项目估算Pert方法最小值a，一般值b，最大值c预期规模E=(a+4b+c)/6标准偏差SD=(c-a)/6有68%的可能规模会在E-SD和E+SD之间本方法的前提是对规模的估计没有偏见经验表明，估计偏低的倾向大于偏高的倾向，使用时应加以考虑项目估算Pert方法26项目估算Analogy方法当待估计项目与已完成项目在应用、环境和复杂度方面相类似时，可以使用本估计方法依赖于已完成项目的完成程度和数据准确度，要求有一个内容丰富、准确、可靠的数据库从软件过程数据库中找到类似项目的相关数据列出已完成项目中可类比的功能点和这些功能点的代码行数标识待估项目和类比项目功能点间差异根据对比进行估计，形成估计结果项目估算Analogy方法27项目估算ReusedCode方法仅适用于对可重用模块的规模估计涉及三个参数：%Redesign、%Recode、%Retest((%Redesign+%Recode+%Retest)/3)*Code项目估算ReusedCode方法28项目估算工作量估计方法Delphi法运算法工作量=p*s*l*ep=软件产品的规模(SLOC)s=生产力系数(1/每人月的代码行)l=开发工具系数e=规模系数专家判断法结合规模估计结果和WBS综合分析项目估算工作量估计方法29项目估算开发工具系数开发工具系数标准C1.2标准C++1.1VB0.8PB0.7VC1.4JAVA1.0嵌入式C1.5项目估算开发工具系数开发工具系数标准C1.2标准C++1.130项目估算规模系数规模(KSLOC)系数501.091001.083001.055001.0410001.03项目估算规模系数规模(KSLOC)系数501.091001.31项目估算生产力系数生产力系数是用平均每人月的代码行来计算的不仅仅编码阶段，包括从分析、设计、编码、测试的整个过程的平均项目类型介入阶段生产力系数新开发项目需求基本设计500详细设计600编码850测试项目估算生产力系数项目类型介入阶段生产力系数新开发项目需求基32项目估算成本系数：由工作量计算成本配置管理系数：由开发工作量估计CM工作量质量保证系数：由开发工作量估计QA工作量改善项目规模系数：改善前到改善后的规模成本系数（元/人月）18000配置管理系数0.05质量保证系数0.05改善项目规模系数0.4项目估算成本系数：由工作量计算成本成本系数（元/人月）18033项目估算估计活动要点在项目的早期阶段，采用从上到下的估计方法，整个项目的估计粗略的分配给各个阶段项目进展过程中，从下到上的方法被用于详细阶段计划来为子阶段进行更详细的计划和估计，并更新总的项目估算项目管理活动约为开发工作量的15-20%为项目建立必须的管理储备(<=20%)：目的是适应不可避免的变更；不能由项目经理单独批准使用，只能用于那些由客户和高层经理都同意的变更项目估算估计活动要点34项目估算估计结果举例开发工作量1000小时配置管理50小时质量保证50小时其他（培训）50小时项目管理（20%）220小时总的已批准的预算1350小时管理储备270小时总的项目资金1620小时项目估算估计结果举例开发工作量1000小时配置管理50小时质35完成计划入口：估计完成输入：WBS、EST活动：合理安排管理支持活动的时间排定整体时间进度表完整计划文档化输出：项目计划出口：文档化的项目计划完成计划入口：估计完成36完成计划要点开发计划包含：培训计划、工具设备的识别和采购计划、同行评审计划CMPQAPSTP度量计划：组织、项目、质量三个层面组间协调计划验收交付计划完成计划要点37项目计划评审入口：计划已文档化输入：项目计划活动：评审计划高层批准计划建立项目配置控制库输出：项目计划出口：项目计划通过高层经理批准项目计划评审入口：计划已文档化38其他工作工具引入（TSP、VSS、RMT）培训（技术、管理）评审活动质量保证活动配置管理活动项目跟踪监控活动（任务管理、度量）问题管理（识别、分析、处理）其他工作工具引入（TSP、VSS、RMT）39培训总结基础：后续活动的准则重要：使项目过程有序可控系统：对项目全过程各方面的系统计划科学：采用科学的方式方法承诺：遵守计划的约定培训总结基础：后续活动的准则40谢谢谢谢412004/03/23CMM过程规范培训实践培训-启动计划阶段活动作者：高勇版本：1.12004/03/23CMM过程规范培训实践培训-启动计划阶段42流程图软件过程定义项目经理系统分析员WBS分解项目估算项目启动计划项目经理系统分析员设计人员QAP生命周期模型定义的软件过程软件估计书工作任务拆分表立项项目经理项目计划项目经理批准CMPSDPSMPICP各组组长STP流程图软件过程项目经理WBS分解项目估算项目启动计划项目经理43PM：过程定义，组织WBS、EST，完成CR、PPSystemAnalyst：整理CR，进行WBS、ESTQAManager：QAP、提供规范支持、审计CMManager：CMP、建立配置控制库TSManager：TSPSEPG：评审过程定义结果SeniorManager：批准PD、PP角色及职责PM：过程定义，组织WBS、EST，完成CR、PP角色及职责44制定启动计划需求活动选择生命周期模型和过程定义项目WBS风险识别、项目估算完成计划项目计划评审其它工作目录制定启动计划目录45制定启动计划入口：项目已立项输入：立项建议书活动：识别本阶段活动的内容确定活动顺序、工作量、安排资源文档化、审批输出：项目启动计划出口：启动计划通过高层经理批准制定启动计划入口：项目已立项46制定启动计划启动计划应涵盖启动准备、计划两方面工作客户需求调研、文档化软件需求分配、制定需求验收准则生命周期选用、项目过程定义WBS活动和估计活动开发和其他支持计划的制定评审活动风险管理、工具引入活动技术和管理的培训活动制定启动计划启动计划应涵盖启动准备、计划两方面工作47客户、系统需求活动入口：启动计划通过输入：启动计划、来自客户和市场的资料、上一版本产品的资料和市场反馈活动：需求获取需求分配需求评审输出：CR、SR、需求验收准则表出口：工作产品获得批准客户、系统需求活动入口：启动计划通过48客户、系统需求活动客户需求、软件系统需求作为整个项目工作的基础，对其的归纳和整理应注意满足：文档结构清晰，内容无冗余，可读性好对需求的描述易于理解，不存在二义性术语一致，需求项间没有冲突描述的结果能准确反映客户的真实需求需求是完整的，没有遗漏也没有增加含有性能需求需求是可追溯和可验证的需求验收准则是具体的可度量的、完整的客户、系统需求活动客户需求、软件系统需求作为整个项目工作的基49客户、系统需求活动剪裁准则：活动可剪裁属性选择剪裁指导方针系统需求分配形成《软件系统需求》执行执行需要在《客户需求》的基础上进一步给软件开发项目组分配客户需求。不执行《客户需求》可直接分配给软件开发项目组。客户、系统需求活动剪裁准则：活动可剪裁属性选择剪裁指导方针系50生命周期和过程定义入口：软件系统需求通过评审输入：软件系统需求，组织软件生命周期、标准软件过程描述文件，剪裁准则活动：选用生命周期模型根据组织标准软件过程剪裁定义项目过程形成文件，报SEPG评审，并得到高层批准输出：项目定义软件过程出口：过程定义获得批准生命周期和过程定义入口：软件系统需求通过评审51生命周期和过程定义选择项目生命周期瀑布式增量式原型式可剪裁的过程系统需求分配（客户需求可直接分配给项目组）概要设计（系统规模较小，层次少，结构简单，文件可与详细设计合并编写）系统测试（集成测试包含对系统功能的测试）生命周期和过程定义选择项目生命周期52项目WBS入口：过程定义完成输入：过程定义文件、系统需求活动：识别工作产品用WBS定义技术活动用WBS定义管理支持活动输出：工作任务拆分表出口：WBS结果文档化项目WBS入口：过程定义完成53项目WBSWBS活动要点识别工作产品，任务大多是根据所要产生的工作产品定义的是一个迭代过程在项目早期定义WBS的高层元素详细任务的定义可以分阶段完成一般不会超过5层在定义最低层元素时，考虑“80小时原则”注意对管理支持活动的拆分：项目管理（如：例会、批准产品活动等）、QA、CM等。项目WBSWBS活动要点54项目WBS建议的WBS第一级分类需求管理项目计划项目跟踪系统设计系统编码系统测试质量保证配置管理项目立项项目培训管理评审技术评审组间协调项目内其他活动项目外其他活动项目WBS建议的WBS第一级分类项目立项55项目WBS举例说明WBS某一项分类的分解：一级分解二级分解三级分解需求管理需求获取需求调研分配系统需求形成需求验收准则需求分析定义词汇表定义系统接口标准需求定义需求管理需求状态跟踪需求追溯需求变更项目WBS举例说明WBS某一项分类的分解：一级分解二级分解三56风险识别与管理入口：WBS完成输入：立项建议书、CR、工作任务拆分表活动：识别风险分析风险制定风险管理计划输出：风险减缓活动日志出口：批准风险减缓活动日志风险识别与管理入口：WBS完成57风险识别与管理风险识别、管理活动要点是一个迭代过程，贯穿项目过程始终风险管理不是项目经理一个人的事，建立一种有助于对潜在风险及其发生的可能性和影响进行交流的环境对项目经理来说是重要的在项目估算前进行潜在风险不等于风险类型：规模、结构、技术风险分析：可能性、影响、风险值、风险等级处理途径：避免、转移、接受、减缓风险识别与管理风险识别、管理活动要点58项目估算入口：风险已识别输入：工作任务拆分表、风险日志、CR活动：估计规模、工作量（技术、管理、支持）估计外部成本、关键计算机资源（包括培训）制定进度表（关键路径、里程碑）建立项目基准（计算BCWS）输出：软件估计书、项目进度表出口：估计结果得到批准项目估算入口：风险已识别59项目估算估计过程步骤相关过程步骤项目计划过程项目跟踪过程1建立估计：项目经理收集输入数据并计算估计2评审估计：项目经理和项目组成员评审和修订估计数据3更新历史项目数据库：从完成的项目中收集数据加入到估计基础库中识别约束：给人员、进度和功能提供约束输入用评审和批准的估计更新项目计划承诺批准：接受批准或者重新确定约束或重新计划项目在开发阶段收集跟踪数据结项变更项目估算估计过程步骤相关过程步骤项目计划过程项目跟踪过程1建60项目估算估计策略内容确定估计内容确定估计时间确定估计技术确定估计粒度估计原则两周原则项目估算估计策略内容61项目估算估计策略检查表#内容1项目是什么类型（新开发、移植、升级、改善）2客户需求已经确定了吗3软件需求已经定义了吗4我们对需求的了解程度如何5需求的稳定性如何6我们是否有可靠的和可用的历史数据7项目将采用什么样的处理模型（瀑布、增量）8项目的结构是什么9主要的风险是什么项目估算估计策略检查表#内容1项目是什么类型（新开发、移植、62项目估算估计策略方案1：情况：客户需求很好的定义，不会有很多变化；开发人员有足够业务经验；工程处理和以前项目相近；企业有可靠的历史数据。策略：项目定义时为整个项目作高级别的估计每个阶段开始前进行详细的阶段估计详细阶段估计时更新高级别估计项目估算估计策略方案1：63项目估算估计策略方案2：情况：客户需求未很好的定义或未被开发人员阅；企业缺乏该应用领域和所使用技术的经验；策略：开始时只估计需求定义阶段；完成需求定义阶段后，准备设计阶段的详细估计和其余阶段的粗略估计；每个阶段开始时进行详细阶段估计，如有必要，对余下阶段修改高级别估计项目估算估计策略方案2：64项目估算规模估计方法WidebandDelphiTechniquePertSizingTechniqueSizingByAnalogyReusedCode建议用两种以上的方法进行估计，不要单独依靠任何一个方法。项目估算规模估计方法65项目估算Delphi方法下发软件系统需求和估计用表格召集会议，讨论有关软件规模的问题每人匿名填写估计表格收集估计表格，形成反馈给参加估计的人召集会议，讨论估计上的差异每人根据讨论结果，提交另一个匿名的估计重复4-6直到达到关于软件规模的最大程度的一致项目估算Delphi方法66项目估算Pert方法最小值a，一般值b，最大值c预期规模E=(a+4b+c)/6标准偏差SD=(c-a)/6有68%的可能规模会在E-SD和E+SD之间本方法的前提是对规模的估计没有偏见经验表明，估计偏低的倾向大于偏高的倾向，使用时应加以考虑项目估算Pert方法67项目估算Analogy方法当待估计项目与已完成项目在应用、环境和复杂度方面相类似时，可以使用本估计方法依赖于已完成项目的完成程度和数据准确度，要求有一个内容丰富、准确、可靠的数据库从软件过程数据库中找到类似项目的相关数据列出已完成项目中可类比的功能点和这些功能点的代码行数标识待估项目和类比项目功能点间差异根据对比进行估计，形成估计结果项目估算Analogy方法68项目估算ReusedCode方法仅适用于对可重用模块的规模估计涉及三个参数：%Redesign、%Recode、%Retest((%Redesign+%Recode+%Retest)/3)*Code项目估算ReusedCode方法69项目估算工作量估计方法Delphi法运算法工作量=p*s*l*ep=软件产品的规模(SLOC)s=生产力系数(1/每人月的代码行)l=开发工具系数e=规模系数专家判断法结合规模估计结果和WBS综合分析项目估算工作量估计方法70项目估算开发工具系数开发工具系数标准C1.2标准C++1.1VB0.8PB0.7VC1.4JAVA1.0嵌入式C1.5项目估算开发工具系数开发工具系数标准C1.2标准C++1.171项目估算规模系数规模(KSLOC)系数501.091001.083001.055001.0410001.03项目估算规模系数规模(KSLOC)系数501.091001.72项目估算生产力系数生产力系数是用平均每人月的代码行来计算的不仅仅编码阶段，包括从