《软件项目管理2-2.ppt》由会员分享，可在线阅读，更多相关《软件项目管理2-2.ppt（52页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件项目管理软件项目管理信息管理系汪维清0 chapter_5范围计划 配置管 理计划 合同 计划 风险 计划 沟通 计划 质量计划成本 计划 时间计划集成 计划 范围计划项目结束项目执 行控制 项目 计划 项目初始 人力 计划 1 chapter_5核心三计划q范围计划q进度计划q成本计划成本基准，进度基准2 chapter_5第2章 软件项目范围计划q项目计划活动的第一项计划活动就是估算：需要多长时间、需要多少工作量，以及需要多少人员。q项目管理过程中最重要也是最困难的方面之一是确定项目的范围，项目成果要素中很多是与范围相关的。q项目范围是指开发项目产品所包括的工作及产生这些产品所用的过程
2、。这个过程规定了如何对项目范围进行定义、管理和控制。3 chapter_52.1 关于软件需求q需求是一个软件项目的开端，也是项目建设的基石。有资料表明，软件项目中40-60的问题都是在需求分析阶段埋下的隐患。q软件开发中返工开销占开发总费用的40，其中70-80的返工是由需求方面的错误所导致。q需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。4 chapter_5项目失败的原因分析No.Top 10 Factors 平均值 1 Inadequate requirements specification 不充分的需求规范 4.5 2 Chan
3、ges in requirements 需求的改变 4.3 3 Shortage of systems engineers 缺乏系统工程师 4.2 4 Shortage of software managers 缺乏了解软件特性的经理人 4.1 5 Shortage of qualified project managers 缺乏合格的 项目经理 4.1 6 Shortage of software engineers 缺乏软件工程师 3.9 7 Fixed-price contract 固定价合同 3.8 8 Inadequate communications for system inte
4、gration 系统集成阶段,交流与沟通不充分 3.8 9 Insufficient experience as team 团队缺乏经验 3.6 10 Shortage of application domain experts 缺乏应用领域专家 3.6 Scale:5=Very Serious 3=Serious 1=No Serious Source:Carnegie-Mellon University,Software Engineering Institute5 chapter_5业 务 需求用 户 需求功 能 需求软件需求规格非功能性需求质 量 特性约束和假设系 统 需求n 软件需求
5、包括三个不同的层次：业务需求、用户需求、功能需求。最后确定软件规格，它们之间的规格如下图:n 业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定，它们在项目视图与范围文档中予以说明。n 用户需求描述了用户通过使用本软件产品必须要完成的任务，一般是用户协助提供。n 功能需求定义了开发人员必须实现的软件功能，使得用户通过使用次软件能完成他们的任务，从而满足了业务需求。6 chapter_52.2 软件需求管理过程n需求管理过程是保证软件需求以一种形式描述一个产品应该具有的功能、性能等。n需求上出现问题很少是源于需求开发技术，更多的是软件人员对需求理解上的错误和忽
6、略，源于需求工作的复杂性、细腻性以及任务的繁多。n有效的需求管理能获得多方面的好处，最大的好处是在开发后期和整个维护阶段的返工的工作量可以大大减少。Boehm发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个缺陷要多付出68倍的成本。近来很多研究表明这种缺陷导致成本放大因子可以高达200倍。7 chapter_5软件需求管理的过程需求分析编写需求规格 需求验证需求获取需求变更需求确认需求变更8 chapter_5需求工程基本任务需求工程需求管理需求开发需求获取 需求分析需求规格说明 需求验证变更管理n软件需求工程的管理分为需求开发和需求管理，如下图所示n需求开发是对需求进
7、行调查、收集、分析、评价、定义等所有活动，主要包括需求获取、需求分析、需求规格编写和需求验证等过程n需求管理是对需求进行一些维护活动，保证在客户和开发方之间能够建立和保持对需求的共同理解，同时维护需求与后续工作成果的一致性，并控制需求的变更。9 chapter_52.2.1 需求获取n需求获取是通过与用户的交流，对现有系统的观测及对任务进行分析，从而开发、捕获和修订用户的需求。n需求获取的主要任务是和用户方的领导层、业务层人员的访谈式沟通，目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运作系统等等具体情况和客观的信息，建立良好的沟通渠道和方
8、式。10 chapter_5n需求获取需要执行的活动如下：n 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围n 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。n 需求分析人员对收集到的用户需求做进一步的分析和处理n 需求分析人员将调研到的用户需求以适当的方式呈交给用户和开发方的相关人员。大家共同确认所提交的结果是否真实地反映了用户的意图。11 chapter_52.2.2 需求分析n需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多的捕获现实世界的语义n从系统分析的经验来
9、看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。n 从系统开发的过程可知，系统需求分析时犯下的错误，会在接下来的阶段被成倍的放大，越是开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。12 chapter_5需求分析模型n 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型。如下图所示：13 chapter_5n需求不明确是软件开发过程中经常遇到的问题，可以从以下几个方面处理需求不明问题：n让用户参与开发n开发用户界面原型，以便用户确认需求n需求讨论会议n强
10、化需求分析与评审14 chapter_52.2.3 需求规格编写q需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书q需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。15 chapter_5软件需求规格说明的原则q q从现实中分离功能，即描述要“做什么”而不是“怎样实现”q q采用一定的规格说明语言q q如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中q q规格说明应该包括系统运行环境q q规格说明应该是一个认识模型q q规格说明应该容许不完备性并允许扩充16 chapter_
11、5q q 下面是一个可参考的软件需求规格模版：下面是一个可参考的软件需求规格模版：q q 1.1.导言 导言q q 1.1 1.1目的 目的q q 1.2 1.2背景 背景q q 1.3 1.3缩写说明 缩写说明q q 1.4 1.4术语定义 术语定义q q 1.5 1.5参考资料 参考资料q q 1.6 1.6版本更新信息 版本更新信息q q 2.2.系统概述 系统概述q q 2.1 2.1系统定义 系统定义q q 2.2 2.2应用环境 应用环境q q 2.3 2.3假定和约束 假定和约束q q 3.3.需求规定 需求规定q q 3.1 3.1对功能的规定 对功能的规定q q 3.2 3.
12、2对性能的规定 对性能的规定q q 3.3 3.3输入输出的要求 输入输出的要求q q 3.4 3.4数据管理能力要求 数据管理能力要求q q 3.5 3.5故障处理要求 故障处理要求q q 3.6 3.6其他要求 其他要求q q 4.4.运行环境规定 运行环境规定q q 4.1 4.1设备 设备q q 4.2 4.2支持软件 支持软件q q 4.3 4.3双方签字 双方签字17 chapter_52.2.4 需求验证q需求规格提交后，开发人员需要与客户对需求分析的结果进行验证，以需求规格说明为输入、通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。q验证需求包括以下几个方面：
13、q 需求的正确性q 需求的一致性：指与其他软件需求或高层（系统、业务）需求不相矛盾q 需求完整性q 需求可行性q 需求的必要性q 需求的可检验性q 需求的可跟踪性q 最后的签字18 chapter_52.2.5 需求变更q 需求变更是软件项目的一个突出的特点，也是软件项目最为普遍的一个特点。需求管理主要的工作如下：建立需求基线：需求基线是需求变更的依据确定需求变更控制过程：制定简单、有效的变更流程，并形成文档建立变更控制委员会(SCCB)：负责裁定接受哪些变更进行需求变更影响分析跟踪所有受需求变更影响的工作产品：需求变更后，受影响的软件计划、产品、活动都要进行相应的变更建立需求基准版本和需求控
14、制版本文档维护需求变更的历史记录：妥善保存变更产生的相关文档跟踪每项需求的状态衡量需求稳定性19 chapter_5变更申请需求方 开发方忽略选择变更方式SCCB评估 项目经理自行决定根据评估结果拒绝 接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划20 chapter_5表4-3 需求变更提交单软件基线产品修改提交单申请人韩万江申请日期2002。1011项目名称项目管理系统阶 段 名称系统设计文 件 名称RCR-PM-01.doc,RCR-PM-02.doc,变更简述如下修 改 内容1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-P
15、M-01.doc2）增加开发人员技能信息库管理，详见RCR-PM-02.doc验 证 意见同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施验证人 杨炎泰 验证日期2002 1011SCCB 韩万江，姜岳尊，孙泉 填表人 韩万江 21 chapter_52.3 编写需求规格的方法q需求建模的方法有很多，如：原型分析方法，结构化分析法，用例分析法，功能列表法，以及其他方法等。目前比较流行的是原型分析法和用例分析法。详见软件工程22 chapter_52.4任务分解定义q当问题过于复杂时，可以将问题进行分解，直到分解后的问题容易解决q规划项目时，也应该从任
16、务分解开始，将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。q完成项目本身是一个复杂的过程，必须采取分解的手段把主要的可交互的成果分成更容易管理的单元才能一目了然，最终得出项目的分解结构（Work Breakdown Structure，WBS）23 chapter_52.4.1WBS(Work Breakdown Structure)qWBS是面向可交付成果的对项目元素的分组,它组织并定义了整个项目范围.不在WBS中包括的工作就不是该项目的工作qWBS是一个分级的树型结构，是对项目由粗到细的分解过程。工作结构每细分一个层次表示对项目元素更细致的描述qWBS实例如
17、下：系统子系统 子系统 子系统模块 模块 模块 模块 模块 模块 模块 模块 模块24 chapter_52.4.2任务分解的类型q一般来说，进行任务分解时，可采用清单或者图表的形式表达任意分解的结果。25 chapter_51.清单类型n 清单类型：将任务分解的结果以清单的表述形式进行层层分解。n“变化计数器”项目采用清单方式进行任务分解如下：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统计增加代码行
18、数1.3.2统计删除代码行数1.4统计总的代码行数 1.5设定标记以指示修改的次数1.6在程序的头部增加修改纪录26 chapter_52.图表类型“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数n 图表类型：将任务分解的结果以图表的形式进行层层分解。n“变化计数器”项目采用图表方式进行任务分解如下：27 chapter_52.5 任务分解的方法p任务分解有很多具体方法，如：p类比p模版p自上而下p自下而上28 chapter_52.5.1 模板参照n 许多应用领域都有标准或版标准的WBS，它他们可以当作模版参考使用n
19、 下图时软件企业进行项目分解的WBS 模版，当然，本图仅仅作为参考实例。29 chapter_52.5.2 类比方法n 虽然每个项目时唯一的，但是，WBS 经常能被“重复使用”，有些项目间在某种程序上是具有相似性。很多项目管理工具也都提供了一些WBS 的例子作为参考，我们可以选择一些类似的项目作为参考进行开发WBS30 chapter_52.5.2 自顶向下方法“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数n 自顶向下方法采用的是演绎推理方法，它是沿着从一般到特殊的方向进行。实例如下：31 chapter_5“变化计
20、数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数2.5.2 自底向上方法n 自底向上是沿着从特殊到一般的方向进行。实例如下：32 chapter_52.6 任务结构分解(WBS)步骤1.确认并分解项目的组成要素2.确定分解标准3.确定分解是否详细4.确定项目交付成果5.验证分解的正确性(建立编号)33 chapter_5WBS编号系统功能1:11软件产品:1功能2-子功能2:122功能2:12 功能3:13功能2-子功能1:121 功能2-子功能3:12334 chapter_5分解标准应统一学生管理q按照生命期分解q 规划q
21、 需求q 设计q 编码q 测试q 提交q按照产品组成分解q 1.1招生管理q 1.2分班管理q 1.3学生档案管理q 1.4学生成绩管理 35 chapter_5分解标准应统一（续）q 不能同时使用两种标准进行分解1.招生管理2.分班管理3.学生档案管理4.学生成绩管理 5.规划6.需求7.设计8.编码9.测试10.提交36 chapter_5检验分解结果的标准1.最底层的要素是否是实现目标的充分必要条件2.最底层要素是否有重复的3.每个要素是否清晰完整定义4.最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排37 chapter_5WBS的指南(1)qWBS分解的规模和数量因项
22、目而异、因项目经理而异q收集与项目相关的所有信息q参看一下类似的项目的WBS,与相关人员讨论q可以参照模板q最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层，q软件项目推荐分解到40小时的任务38 chapter_5WBS的指南（2）q定义任务完成的标准q每个WBS必须有利于责任分配q可以准备WBS的字典q最后与相关人员进行评审39 chapter_5WBS字典内容WBS表示号名称主题目标描述完成的任务责任者完成的标识备注1.40 chapter_5WBS意义q提供了项目范围基线,是范围变更的重要输入q为评估和分配任务提供具体的工作包q进行估算和编制项目进度的基础q对整个项目成
23、功的集成和控制起到非常重要的作用41 chapter_5网管系统（图表）分解实例FF1配置管理F2故障管理F3安全管理F4性能管理F3.2 F3.3 F3.1 F3.4F4.2 F4.3 F4.5 F4.6 F4.7 F4.4 F4.1F4.7.1 F4.7.242 chapter_5网管系统（图表）分解实例F1F1.1F1.2F1.3F1.4F1.5F1.6F1.7F1.8F1.9F1.10F1.11F1.4.1 F1.4.243 chapter_5标识项 功能名F1.1 获取网络资源数据F1.2 将资源数据存入数据库F1.3 获取网络资源信息F1.4 观察网络资源F1.4.1 依类型分类观
24、察网络资源F1.4.2 依状态分类观察网络资源F1.5 观察逻辑网F1.6 观察资源状态F1.7 修改网络资源的状态F1.8 依条件检验网络使用情况F1.9 显示拓扑图F1.10 建立通道44 chapter_5George and Martha一次野餐会qGeorge and Martha计划与家人和朋友举行一次特殊的野餐活动,以庆祝Martha的升职和他们35周年的结婚纪念.Martha是工程师,George是会计.他们有两个非常活泼的孩子,Mary 13岁,Thomas 17岁.经过过去几年的发展,家里不断壮大,无论是时间和金钱上的需要都在增加,所以他们已经逐渐成为非常好的计划能手,最近
25、他们又通过了PMP的认证考试,所以他们非常清楚对于这样野餐活动也需要开发一个WBS.45 chapter_5野餐准备活动任务分解序号 任务 持续时间 工作人员1开始02做冰茶15 George3准备三明治10 Martha4准备水果2 Martha5准备篮子2 Martha6收拾毛毯2 George7收拾运动服3 Martha8装车4 George9加油6 George10开车去野餐营地20 Martha11结束046 chapter_52.7 案例分析q本项目需求调研阶段，发现用户缺乏相关知识，他们对需求没有很明确的说明，但随着项目的进展，用户的经验也会增加，自然会发现一些不合理或不完整或缺
26、少的需求，必然会引起变更。q为了避免不必要的需求变化，在开发校务通需求时，项目组与用户一起确定需求规格。q本项目采用原型分析法确定需求，根据用户确定的原型系统编写软件需求规格。最后，根据需求规格形成项目的范围计划，即WBS。47 chapter_52.7.1 系统原型分析q根据用户描述，本系统应该提供3个操作平台：系统管理员平台、教师平台、学生平台。他们希望提供三个平台的统一登录界面，根据不停的角色来进入不同的平台。q 根据讨论形成主登录界面，如图2-12所示q 如果用户以教师的角色登录界面，则进入教师平台，界面如图2-13所示q 如果用户以学生的角色登录界面，则进入学生平台，界面如图2-14
27、所示q 如果用户以系统管理员的角色登录界面，则进入系统管理员平台，界面如图2-15所示48 chapter_52.7.2 需求规格说明书q 1.引言4.功能需求q 1.1目的4.1教师平台q 1.2范围4.2学生平台q 1.3缩写与术语4.3系统管理员平台q 1.4参考资料5.性能需求q 1.5版本更新信息5.1扩充性q 2.系统定义5.2适应性q 2.1项目背景5.3故障处理q 2.2项目简介5.4用户界面q 3.应用环境5.5安全需求q 3.1网络环境6.签字认证q 3.2软件环境49 chapter_52.7.3 系统WBSq根据对项目的需求规格的分析，采用图表方式进行任务分解，结果如下图所示：50 chapter_5课堂练习q你是某项目的项目经理,这个项目是为用户创建一个新的邮件服务器以及在所有100个工作站上部署相应的邮件客户端（要满足用户的期望）。其中，2个服务器需要重新购置，而客户端的机器已经存在。请提交任务分解结果WBS。51 chapter_5