软件开发项目管理

chapter__50软件开发项目管理北京邮电大学软件学院韩万江chapter__51RoadMap项目结束项目执行控制项目计划项目初始第二篇软件项目计划chapter__53没有计划的情况时间资源投入开发工作计划性工作协调性工作chapter__54有计划的情况时间资源投入开发工作计划性工作协调性工作chapter__55计划的重要性PMI：项目成功的三大要素（法宝）：计划、计划、计划计划是通向项目成功的路线图进度计划是最重要的计划chapter__56项目进度计划chapter__57编制进度计划的三步曲任务分解（WBS）--范围基准成本估算资源、进度安排－－成本基准，进度基准chapter__58RoadMap合同计划风险计划沟通计划人力计划质量计划成本计划时间计划集成计划范围计划项目结束项目执行控制项目计划项目初始chapter__59软件项目管理第2章软件项目范围计划chapter__510本章要点一、软件需求管理过程二、需求建模的基本方法三、任务分解过程四、任务分解方法五、任务分解检验六、案例分析chapter__511软件需求需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。chapter__512软件需求的层次业务需求用户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求chapter__513需求管理的重要性chapter__514项目失败的原因分析No.Top10Factors平均值1Inadequaterequirementsspecification不充分的需求规范4.52Changesinrequirements需求的改变4.33Shortageofsystemsengineers缺乏系统工程师4.24Shortageofsoftwaremanagers缺乏了解软件特性的经理人4.15Shortageofqualifiedprojectmanagers缺乏合格的项目经理4.16Shortageofsoftwareengineers缺乏软件工程师3.97Fixed-pricecontract固定价合同3.88Inadequatecommunicationsforsystemintegration系统集成阶段,交流与沟通不充分3.89Insufficientexperienceasteam团队缺乏经验3.610Shortageofapplicationdomainexperts缺乏应用领域专家3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitutechapter__515软件需求管理的过程需求分析编写需求规格需求验证需求获取需求变更需求确认需求变更chapter__516需求工程基本任务需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理chapter__517需求获取图示chapter__518需求获取用户要求扩展需求基线需求软件需求chapter__519需求分析定义需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。chapter__520需求分析模型chapter__521需求规格需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。chapter__522软件需求规格说明的原则从现实中分离功能，即描述要“做什么”而不是“怎样实现”采用一定的规格说明语言如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中chapter__523规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充chapter__524规格文档参考1.引言2.系统定义3.应用环境4.功能规格5.性能需求6.产品提交7.实现约束8.质量描述9.其它10.签字认证chapter__525需求验证需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字chapter__526需求总在变化chapter__527chapter__528需求变更管理1.确定需求变更控制过程2.建立变更控制委员会(SCCB)3.进行需求变更影响分析4.跟踪所有受需求变更影响的工作产品5.建立需求基准版本和需求控制版本文档6.维护需求变更的历史记录7.跟踪每项需求的状态8.衡量需求稳定性chapter__529需求变更管理管理和控制需求基线的过程需求变更控制系统一个正式的文档，说明如何控制需求变更建立变更审批系统chapter__530变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划chapter__531表4-3需求变更提交单软件基线产品修改提交单申请人韩万江申请日期2002。10．11项目名称项目管理系统阶段名称系统设计文件名称RCR-PM-01.doc,RCR-PM-02.doc,变更简述如下修改内容1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc2）增加开发人员技能信息库管理，详见RCR-PM-02.doc验证意见同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施验证人杨炎泰验证日期2002．10．11SCCB韩万江，姜岳尊，孙泉填表人韩万江chapter__532本章要点一、软件需求管理过程二、需求建模的基本方法三、任务分解过程四、任务分解方法五、任务分解检验六、案例分析chapter__533需求建模的基本方法1.原型方法2.结构化分析法3.面向对象的用例分析法4.功能列表法5.其他chapter__534本章要点一、软件需求管理过程二、需求建模的基本方法三、任务分解过程四、任务分解方法五、任务分解检验六、案例分析chapter__535任务分解过程输入分解WBSchapter__536WBS(WorkBreakdownStructure)任务分解的过程将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。任务分解的结果WBS（任务分解结构）。WBS面向可交付成果的。Workpackages（工作包）WBS的最低层次的可交付成果chapter__537WBS实例功能1软件产品功能2-子功能2功能2功能3功能2-子功能1功能2-子功能3chapter__538PMIdefinesWBS是面向可交付成果的对项目元素的分组,它组织并定义了整个项目范围.不在WBS中包括的工作就不是该项目的工作它是一个分级的树型结构，是对项目由粗到细的分解过程。工作结构每细分一个层次表示对项目元素更细致的描述chapter__539PMIdefinesWorkpackagesWBS的最低层次的可交付成果工作包应当由唯一一个部门或承包商负责这一交付成果可以分配给另外一位项目经理进行计划和执行,或者通过子项目的方式完成工作包可进一步分解为子项目的WBS或各个活动chapter__540WBS类型清单图表chapter__541图表类型“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数chapter__542清单类型1.变化计数器1.1比较两个版本的程序1.1.1预处理1.1.2文件比较1.1.3结果处理1.2找出修改后的程序中增加和删除的代码行1.2.1找出增加的代码行1.2.2找出删除的代码行1.3统计修改后的程序中增加和删除的代码行数1.3.1统计增加代码行数1.3.2统计删除代码行数1.4统计总的代码行数1.5设定标记以指示修改的次数1.6在程序的头部增加修改纪录chapter__543任务分解步骤1.确认并分解项目的组成要素2.确定分解标准3.确定分解是否详细4.确定项目交付成果5.验证分解的正确性(建立编号)chapter__544WBS编号系统功能1:11软件产品:1功能2-子功能2:122功能2:12功能3:13功能2-子功能1:121功能2-子功能3:123chapter__545标识项功能名F1.1获取网络资源数据F1.2将资源数据存入数据库F1.3获取网络资源信息F1.4观察网络资源F1.4.1依类型分类观察网络资源F1.4.2依状态分类观察网络资源F1.5观察逻辑网F1.6观察资源状态F1.7修改网络资源的状态F1.8依条件检验网络使用情况F1.9显示拓扑图F1.10建立通道chapter__546WBS与OBS（组织分解结构）chapter__547分解标准1.生存期2.功能组成3.项目的组织单位4.。。。。。chapter__548分解标准应统一学生管理按照生命期分解规划需求设计编码测试提交按照产品组成分解1.1招生管理1.2分班管理1.3学生档案管理1.4学生成绩管理chapter__549分解标准应统一（续）不能同时使用两种标准进行分解1.招生管理2.分班管理3.学生档案管理4.学生成绩管理5.规划6.需求7.设计8.编码9.测试10.提交chapter__550本章要点一、软件需求管理过程二、需求建模的基本方法三、任务分解过程四、任务分解方法五、任务分解检验六、案例分析chapter__551任务分解方法模版类比自上而下自下而上chapter__552WBS模板举例chapter__553分解方法-自上而下“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数chapter__554分解方法-自下而上“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数chapter__555本章要点一、软件需求管理过程二、需求建模的基本方法三、任务分解过程四、任务分解方法五、任务分解检验六、案例分析chapter__556检验分解结果的标准1.最底层的要素是否是实现目标的充分必要条件2.最底层要素是否有重复的3.每个要素是否清晰完整定义4.最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排chapter__557WBS的指南(1)WBS分解的规模和数量因项目而异、因项目经理而异收集与项目相关的所有信息参看一下类似的项目的WBS,与相关人员讨论可以参照模板最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层，软件项目推荐分解到40小时的任务注：80/8规则chapter__558WBS的指南（2）每个Workpackage必须有一个提交物定义任务完成的标准每个WBS必须有利于责任分配可以准备WBS的字典最后与相关人员进行评审chapter__559WBS字典内容WBS表示号名称主题目标描述完成的任务责任者完成的标识备注1.chapter__560WBS字典WBS字典实例chapter__561WBS意义提供了项目范围基线,是范围变更的重要输入为评估和分配任务提供具体的工作包进行估算和编制项目进度的基础对整个项目成功的集成和控制起到非常重要的作用chapter__562清单式任务分解实例电信运营信息查询系统分解一例chapter__563网管系统（图表）分解实例FF1配置管理F2故障管理F3安全管理F4性能管理F3.2F3.3F3.1F3.4F4.2F4.3F4.5F4.6F4