软件项目管理 (2).ppt
chapter_5,0,软件项目管理,信息管理系汪维清,chapter_5,1,范围计划,chapter_5,2,核心三计划,范围计划进度计划成本计划,成本基准，进度基准,chapter_5,3,第2章 软件项目范围计划,项目计划活动的第一项计划活动就是估算：需要多长时间、需要多少工作量，以及需要多少人员。项目管理过程中最重要也是最困难的方面之一是确定项目的范围，项目成果要素中很多是与范围相关的。项目范围是指开发项目产品所包括的工作及产生这些产品所用的过程。这个过程规定了如何对项目范围进行定义、管理和控制。,chapter_5,4,2.1 关于软件需求,需求是一个软件项目的开端，也是项目建设的基石。有资料表明，软件项目中40-60的问题都是在需求分析阶段埋下的隐患。软件开发中返工开销占开发总费用的40，其中70-80的返工是由需求方面的错误所导致。需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。,chapter_5,5,项目失败的原因分析,Source: Carnegie-Mellon University, Software Engineering Institute,chapter_5,6,软件需求包括三个不同的层次：业务需求、用户需求、功能需求。最后确定软件规格，它们之间的规格如下图:业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定，它们在项目视图与范围文档中予以说明。用户需求描述了用户通过使用本软件产品必须要完成的任务，一般是用户协助提供。功能需求定义了开发人员必须实现的软件功能，使得用户通过使用次软件能完成他们的任务，从而满足了业务需求。,chapter_5,7,2.2 软件需求管理过程,需求管理过程是保证软件需求以一种形式描述一个产品应该具有的功能、性能等。需求上出现问题很少是源于需求开发技术，更多的是软件人员对需求理解上的错误和忽略，源于需求工作的复杂性、细腻性以及任务的繁多。有效的需求管理能获得多方面的好处，最大的好处是在开发后期和整个维护阶段的返工的工作量可以大大减少。Boehm发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个缺陷要多付出68倍的成本。近来很多研究表明这种缺陷导致成本放大因子可以高达200倍。,chapter_5,8,软件需求管理的过程,需求分析,编写需求规格,需求验证,需求获取,需求变更,需求确认,需求变更,chapter_5,9,需求工程基本任务,软件需求工程的管理分为需求开发和需求管理，如下图所示需求开发是对需求进行调查、收集、分析、评价、定义等所有活动，主要包括需求获取、需求分析、需求规格编写和需求验证等过程需求管理是对需求进行一些维护活动，保证在客户和开发方之间能够建立和保持对需求的共同理解，同时维护需求与后续工作成果的一致性，并控制需求的变更。,chapter_5,10,2.2.1 需求获取,需求获取是通过与用户的交流，对现有系统的观测及对任务进行分析，从而开发、捕获和修订用户的需求。需求获取的主要任务是和用户方的领导层、业务层人员的访谈式沟通，目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运作系统等等具体情况和客观的信息，建立良好的沟通渠道和方式。,chapter_5,11,需求获取需要执行的活动如下：了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需求分析人员对收集到的用户需求做进一步的分析和处理需求分析人员将调研到的用户需求以适当的方式呈交给用户和开发方的相关人员。大家共同确认所提交的结果是否真实地反映了用户的意图。,chapter_5,12,2.2.2 需求分析,需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多的捕获现实世界的语义从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。 从系统开发的过程可知，系统需求分析时犯下的错误，会在接下来的阶段被成倍的放大，越是开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。,chapter_5,13,需求分析模型,需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型。如下图所示：,chapter_5,14,需求不明确是软件开发过程中经常遇到的问题，可以从以下几个方面处理需求不明问题：让用户参与开发开发用户界面原型，以便用户确认需求需求讨论会议强化需求分析与评审,chapter_5,15,2.2.3 需求规格编写,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。,chapter_5,16,软件需求规格说明的原则,从现实中分离功能，即描述要“做什么”而不是“怎样实现”采用一定的规格说明语言如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充,chapter_5,17,下面是一个可参考的软件需求规格模版：1.导言1.1目的1.2背景1.3缩写说明1.4术语定义1.5参考资料1.6版本更新信息2.系统概述2.1系统定义2.2应用环境2.3假定和约束3.需求规定3.1对功能的规定3.2对性能的规定3.3输入输出的要求3.4数据管理能力要求3.5故障处理要求3.6其他要求4. 运行环境规定4.1设备4.2支持软件4.3双方签字,chapter_5,18,2.2.4 需求验证,需求规格提交后，开发人员需要与客户对需求分析的结果进行验证，以需求规格说明为输入、通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。验证需求包括以下几个方面：需求的正确性需求的一致性：指与其他软件需求或高层 （系统、业务）需求不相矛盾需求完整性需求可行性需求的必要性需求的可检验性需求的可跟踪性最后的签字,chapter_5,19,2.2.5 需求变更,需求变更是软件项目的一个突出的特点，也是软件项目最为普遍的一个特点。需求管理主要的工作如下：建立需求基线：需求基线是需求变更的依据确定需求变更控制过程：制定简单、有效的变更流程，并形成文档建立变更控制委员会(SCCB)：负责裁定接受哪些变更进行需求变更影响分析跟踪所有受需求变更影响的工作产品：需求变更后，受影响的软件计划、产品、活动都要进行相应的变更建立需求基准版本和需求控制版本文档维护需求变更的历史记录：妥善保存变更产生的相关文档跟踪每项需求的状态衡量需求稳定性,chapter_5,20,chapter_5,21,表4-3 需求变更提交单,chapter_5,22,2.3 编写需求规格的方法,需求建模的方法有很多，如：原型分析方法，结构化分析法，用例分析法，功能列表法，以及其他方法等。目前比较流行的是原型分析法和用例分析法。详见软件工程,chapter_5,23,2.4任务分解定义,当问题过于复杂时，可以将问题进行分解，直到分解后的问题容易解决规划项目时，也应该从任务分解开始，将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。完成项目本身是一个复杂的过程，必须采取分解的手段把主要的可交互的成果分成更容易管理的单元才能一目了然，最终得出项目的分解结构（ Work Breakdown Structure，WBS ）,chapter_5,24,2.4.1WBS (Work Breakdown Structure),WBS是面向可交付成果的对项目元素的分组,它组织并定义了整个项目范围.不在WBS中包括的工作就不是该项目的工作WBS是一个分级的树型结构，是对项目由粗到细的分解过程。工作结构每细分一个层次表示对项目元素更细致的描述WBS实例如下：,chapter_5,25,2.4.2任务分解的类型,一般来说，进行任务分解时，可采用清单或者图表的形式表达任意分解的结果。,chapter_5,26,1. 清单类型,清单类型：将任务分解的结果以清单的表述形式进行层层分解。“变化计数器”项目采用清单方式进行任务分解如下：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_5,27,2. 图表类型,图表类型：将任务分解的结果以图表的形式进行层层分解。“变化计数器”项目采用图表方式进行任务分解如下：,chapter_5,28,2.5 任务分解的方法,任务分解有很多具体方法，如：类比模版自上而下自下而上,chapter_5,29,2.5.1 模板参照,许多应用领域都有标准或版标准的WBS，它他们可以当作模版参考使用下图时软件企业进行项目分解的WBS模版，当然，本图仅仅作为参考实例。,chapter_5,30,2.5.2 类比方法,虽然每个项目时唯一的，但是，WBS经常能被“重复使用”，有些项目间在某种程序上是具有相似性。很多项目管理工具也都提供了一些WBS的例子作为参考，我们可以选择一些类似的项目作为参考进行开发WBS,chapter_5,31,2.5.2 自顶向下方法,自顶向下方法采用的是演绎推理方法，它是沿着从一般到特殊的方向进行。实例如下：,chapter_5,32,2.5.2 自底向上方法,自底向上是沿着从特殊到一般的方向进行。实例如下：,chapter_5,33,2.6 任务结构分解(WBS)步骤,确认并分解项目的组成要素确定分解标准确定分解是否详细确定项目交付成果验证分解的正确性(建立编号),chapter_5,34,WBS编号系统,chapter_5,35,分解标准应统一,学生管理按照生命期分解规划需求设计编码测试提交按照产品组成分解1.1招生管理1.2分班管理1.3学生档案管理1.4学生成绩管理,chapter_5,36,分解标准应统一（续）,不能同时使用两种标准进行分解招生管理分班管理学生档案管理学生成绩管理 规划需求设计编码测试提交,chapter_5,37,检验分解结果的标准,最底层的要素是否是实现目标的充分必要条件最底层要素是否有重复的每个要素是否清晰完整定义最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排,chapter_5,38,WBS的指南(1),WBS分解的规模和数量因项目而异、因项目经理而异收集与项目相关的所有信息参看一下类似的项目的WBS,与相关人员讨论可以参照模板最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层，软件项目推荐分解到40小时的任务,chapter_5,39,WBS的指南（2）,定义任务完成的标准每个WBS必须有利于责任分配可以准备WBS的字典最后与相关人员进行评审,chapter_5,40,WBS字典内容,chapter_5,41,WBS意义,提供了项目范围基线,是范围变更的重要输入为评估和分配任务提供具体的工作包进行估算和编制项目进度的基础对整个项目成功的集成和控制起到非常重要的作用,chapter_5,42,网管系统（图表）分解实例,chapter_5,43,网管系统（图表）分解实例,chapter_5,44,chapter_5,45,George and Martha一次野餐会,George and Martha计划与家人和朋友举行一次特殊的野餐活动,以庆祝Martha的升职和他们35周年的结婚纪念. Martha是工程师, George是会计.他们有两个非常活泼的孩子,Mary 13岁,Thomas 17岁.经过过去几年的发展,家里不断壮大,无论是时间和金钱上的需要都在增加,所以他们已经逐渐成为非常好的计划能手,最近他们又通过了PMP的认证考试,所以他们非常清楚对于这样野餐活动也需要开发一个WBS.,chapter_5,46,野餐准备活动任务分解,chapter_5,47,2.7 案例分析,本项目需求调研阶段，发现用户缺乏相关知识，他们对需求没有很明确的说明，但随着项目的进展，用户的经验也会增加，自然会发现一些不合理或不完整或缺少的需求，必然会引起变更。为了避免不必要的需求变化，在开发校务通需求时，项目组与用户一起确定需求规格。本项目采用原型分析法确定需求，根据用户确定的原型系统编写软件需求规格。最后，根据需求规格形成项目的范围计划，即WBS。,chapter_5,48,2.7.1 系统原型分析,根据用户描述，本系统应该提供3个操作平台：系统管理员平台、教师平台、学生平台。他们希望提供三个平台的统一登录界面，根据不停的角色来进入不同的平台。根据讨论形成主登录界面，如图2-12所示如果用户以教师的角色登录界面，则进入教师平台，界面如图2-13所示如果用户以学生的角色登录界面，则进入学生平台，界面如图2-14所示如果用户以系统管理员的角色登录界面，则进入系统管理员平台，界面如图2-15所示,chapter_5,49,2.7.2 需求规格说明书,1. 引言 4. 功能需求 1.1 目的 4.1 教师平台 1.2 范围 4.2 学生平台 1.3 缩写与术语 4.3 系统管理员平台 1.4 参考资料 5. 性能需求 1.5 版本更新信息 5.1 扩充性2. 系统定义 5.2 适应性 2.1 项目背景 5.3 故障处理 2.2 项目简介 5.4 用户界面3. 应用环境 5.5 安全需求 3.1 网络环境 6. 签字认证 3.2 软件环境,chapter_5,50,2.7.3 系统WBS,根据对项目的需求规格的分析，采用图表方式进行任务分解，结果如下图所示：,chapter_5,51,课堂练习,你是某项目的项目经理,这个项目是为用户创建一个新的邮件服务器以及在所有100个工作站上部署相应的邮件客户端（要满足用户的期望）。其中，2个服务器需要重新购置，而客户端的机器已经存在。请提交任务分解结果WBS。,
