软件项目管理 (2).ppt
《软件项目管理 (2).ppt》由会员分享,可在线阅读,更多相关《软件项目管理 (2).ppt(52页珍藏版)》请在三一文库上搜索。
1、chapter_5,0,软件项目管理,信息管理系汪维清,chapter_5,1,范围计划,chapter_5,2,核心三计划,范围计划进度计划成本计划,成本基准,进度基准,chapter_5,3,第2章 软件项目范围计划,项目计划活动的第一项计划活动就是估算:需要多长时间、需要多少工作量,以及需要多少人员。项目管理过程中最重要也是最困难的方面之一是确定项目的范围,项目成果要素中很多是与范围相关的。项目范围是指开发项目产品所包括的工作及产生这些产品所用的过程。这个过程规定了如何对项目范围进行定义、管理和控制。,chapter_5,4,2.1 关于软件需求,需求是一个软件项目的开端,也是项目建设的
2、基石。有资料表明,软件项目中40-60的问题都是在需求分析阶段埋下的隐患。软件开发中返工开销占开发总费用的40,其中70-80的返工是由需求方面的错误所导致。需求是指用户对软件的功能和性能的要求,就是用户希望软件能做什么事情,完成什么样的功能,达到什么性能。,chapter_5,5,项目失败的原因分析,Source: Carnegie-Mellon University, Software Engineering Institute,chapter_5,6,软件需求包括三个不同的层次:业务需求、用户需求、功能需求。最后确定软件规格,它们之间的规格如下图:业务需求反映了组织机构或客户对系统、产品
3、高层次的目标要求,由管理人员或市场分析人员确定,它们在项目视图与范围文档中予以说明。用户需求描述了用户通过使用本软件产品必须要完成的任务,一般是用户协助提供。功能需求定义了开发人员必须实现的软件功能,使得用户通过使用次软件能完成他们的任务,从而满足了业务需求。,chapter_5,7,2.2 软件需求管理过程,需求管理过程是保证软件需求以一种形式描述一个产品应该具有的功能、性能等。需求上出现问题很少是源于需求开发技术,更多的是软件人员对需求理解上的错误和忽略,源于需求工作的复杂性、细腻性以及任务的繁多。有效的需求管理能获得多方面的好处,最大的好处是在开发后期和整个维护阶段的返工的工作量可以大大
4、减少。Boehm发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个缺陷要多付出68倍的成本。近来很多研究表明这种缺陷导致成本放大因子可以高达200倍。,chapter_5,8,软件需求管理的过程,需求分析,编写需求规格,需求验证,需求获取,需求变更,需求确认,需求变更,chapter_5,9,需求工程基本任务,软件需求工程的管理分为需求开发和需求管理,如下图所示需求开发是对需求进行调查、收集、分析、评价、定义等所有活动,主要包括需求获取、需求分析、需求规格编写和需求验证等过程需求管理是对需求进行一些维护活动,保证在客户和开发方之间能够建立和保持对需求的共同理解,同时维护需
5、求与后续工作成果的一致性,并控制需求的变更。,chapter_5,10,2.2.1 需求获取,需求获取是通过与用户的交流,对现有系统的观测及对任务进行分析,从而开发、捕获和修订用户的需求。需求获取的主要任务是和用户方的领导层、业务层人员的访谈式沟通,目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运作系统等等具体情况和客观的信息,建立良好的沟通渠道和方式。,chapter_5,11,需求获取需要执行的活动如下:了解客户方的所有用户类型以及潜在的类型。然后,根据他们的要求来确定系统的整体目标和系统的工作范围对用户进行访谈和调研。交流的方式可以是
6、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需求分析人员对收集到的用户需求做进一步的分析和处理需求分析人员将调研到的用户需求以适当的方式呈交给用户和开发方的相关人员。大家共同确认所提交的结果是否真实地反映了用户的意图。,chapter_5,12,2.2.2 需求分析,需求分析是为最终用户所看到的系统建立一个概念模型,是对需求的抽象描述,并尽可能多的捕获现实世界的语义从系统分析的经验来看,这个过程往往是个循序渐进的过程,一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认,方能逐步明了用户的需求。 从系统开发的过程可知,系统需求分析时犯下的错误,会在接下来的阶段被成倍
7、的放大,越是开发的后期,纠正分析时犯下的错误所花费的代价越是昂贵,也越发影响系统的工期和系统的质量。,chapter_5,13,需求分析模型,需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型。如下图所示:,chapter_5,14,需求不明确是软件开发过程中经常遇到的问题,可以从以下几个方面处理需求不明问题:让用户参与开发开发用户界面原型,以便用户确认需求需求讨论会议强化需求分析与评审,chapter_5,15,2.2.3 需求规格编写,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个
8、共同的理解,使之成为整个开发工作的基础。,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
9、输入输出的要求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 需求变更,需求变更是软件项目的一个突出的特点,也是软件项目最为普遍
10、的一个特点。需求管理主要的工作如下:建立需求基线:需求基线是需求变更的依据确定需求变更控制过程:制定简单、有效的变更流程,并形成文档建立变更控制委员会(SCCB):负责裁定接受哪些变更进行需求变更影响分析跟踪所有受需求变更影响的工作产品:需求变更后,受影响的软件计划、产品、活动都要进行相应的变更建立需求基准版本和需求控制版本文档维护需求变更的历史记录:妥善保存变更产生的相关文档跟踪每项需求的状态衡量需求稳定性,chapter_5,20,chapter_5,21,表4-3 需求变更提交单,chapter_5,22,2.3 编写需求规格的方法,需求建模的方法有很多,如:原型分析方法,结构化分析法,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件项目管理 2 软件 项目 管理
链接地址:https://www.31doc.com/p-13272114.html