《软件过程管理 (5)8复习课程》由会员分享，可在线阅读，更多相关《软件过程管理 (5)8复习课程（123页珍藏版）》请在金锄头文库上搜索。
1、承上启下q项目合同管理q生存期模型RoadMap合同管理 生存期 需求管理 任务分解项目进度规模估算质量计划 配置计划风险计划团队管理项目度量集成项目跟踪控制 项目结束软件开发项目管理第四章软件项目需求管理镀金（gold plating）的定义 给予用户的东西要多于他们所要求的。 事实上，额外的特性、扩展的功能、更好的组件以及其他等等，通常都不会为项目增加什么价值。实际上，镀金常常会增加项目的开支，因为这需要更多的资源、更长的开发周期，还会增加重新设计的风险、耽误项目的交付使用。镀金案例n在检视项目要求的时候，你发现了一个需要创建软件模块的要求。这个模块允许用户在浏览应用程序的时候，在屏幕上维
2、持其所喜好的颜色和字体样式。在更进一步检视的时候，你意识到这个模块的加入虽然很好，但是不会为整个项目增添什么价值。 如何确定项目里是否包含有镀金的内容要验证开发要求或者任务里是否包含有镀金内容的一种方法是：思考一下如果项目没有包含这个模块的话，其影响会是什么。问问你自己：如果这个项目没有包含这个模块，这个应用程序的可靠性、效率是否会更低，或者根本就不会有任何降低。本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q四、案例分析n软件需求定义软件需求q需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。软件需求的层次业务需求用
3、户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求1业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明 2用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本说明中予以说明。3功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 在软件需求规格说明书 （SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开
4、发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 以一个字处理程序为例来说明需求的不同种类。 业务需求可能是：“用户能有效地纠
5、正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。功能需求n功能需求：列举出被开发软件在职能上应做什么。这是最主要的需求，规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。n通常功能性需求是：u 产品功能的规格说明；u 产品必须执行的动作；u 源自于产品的基本目标n例如：银行ATM系统 功能性需求：取、存、查、密码检验 非功能需求
6、n许多非功能需求关心的是系统整体特性，而不是个别的系统特性。因此非功能需求比功能需求对系统更关键。一个功能需求没有满足可能降低系统的能力，而一个非功能系统需求没有满足则可能使整个系统无法使用。n例如：一个飞机系统不符合可靠性需求，它将不会被批准飞行。若一个实时控制系统无法满足其性能需求，控制功能可能根本无法使用。n例如：银行ATM系统 非功能需求：响应时间，安全保密等 需求管理的重要性项目失败的原因分析No. Top 10 Factors 平均值 1 Inadequate requirements specification 不充分的需求规范 4.5 2 Changes in requirem
7、ents 需求的改变 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 integration 系统集成阶段
8、, 交流与沟通不充分 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 Institute本章要点q一、软件需求定义q二、软件需求管理过程q三、需求建模的基本方法q四、案例分析n软件需求管理过程软件需求管理的过程需求分析编写需求
9、规格需求验证需求获取需求变更需求确认需求变更需求开发(确认)和管理基本任务需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理版本控制风险分析本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析需求获取图示需求获取用户要求 扩展需求基线需求软件需求程、硬件环境、软件环境、现有的运行系统等具体情况和客观的信息，建立起良好的沟通渠道和方式进行需求获取应注意的问题1.识别真正的客户2.正确理解客户的需求3.具备较强的忍耐力和清晰的思维4.说明和教育客户本章要点q一、软件需求定义q二、软件需求管理
10、过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析需求分析定义q需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 需求分析模型本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析需求规格q需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书q需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。软件需求规格说明的原则qq从现实中分离功能，即描述要从现实中分离功能
11、，即描述要“做什做什么么”而不是而不是“怎样实现怎样实现”qq要求使用面向处理的规格说明语言（要求使用面向处理的规格说明语言（或称系统定义语言）或称系统定义语言）qq如果被开发软件只是一个大系统中的如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在一个元素，那么整个大系统也包括在规格说明的描述之中规格说明的描述之中qq规格说明应该包括系统运行环境规格说明应该包括系统运行环境qq规格说明应该是一个认识模型规格说明应该是一个认识模型qq规格说明应该容许不完备性并允许扩规格说明应该容许不完备性并允许扩充充3、规格文档参考1.引言2.系统定义 3.应用环境4.功能规格 5.性能需求6.产
12、品提交7.实现约束8.质量描述9.其它10.签字认证本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析需求验证q需求是正确的吗？q需求是一致的吗？q需求是完全的吗？q需求是实际可行的吗？q需求是必要的吗？q需求是可检验的吗？q需求是可跟踪的吗？q最后的签字本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更q三、需求建模的基本方法q四、案例分析需求总在变化需求变更管理1.确定需求变更控制过程2.建立变更控制委员会(SCCB)3.进行需求变更影响分析4.
13、跟踪所有受需求变更影响的工作产品5.建立需求基准版本和需求控制版本文档6.维护需求变更的历史记录7.跟踪每项需求的状态8.衡量需求稳定性需求变更管理q管理和控制需求基线的过程q需求变更控制系统q一个正式的文档，说明如何控制需求变更q建立变更审批系统控制需求渐变的策略1. 需求一定要与投入有显然的联系，在项目的开始双方都要明确：需求变化，成本也要变化。2. 需求的变化要经过出资者的认可。3. 小的需求变更也要经过正规的需求管理过程，否则积少成多。4. 精确的需求和范围的定义并不会阻止需求的变更。这是两个层面的问题。变更控制过程需求变更处理流程n提出变更n变更评估n实施变更变更申请忽略选择变更方式
14、SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划表4-3 需求变更提交单软件基线产品修改提交单申请人韩万江申请日期2002。1011项目名称项目管理系统阶段名称系统设计文件名 称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的变更可以推迟到下一个版本实施验证人杨炎泰
15、验证日期20021011SCCB韩万江，姜岳尊，孙泉 填表人韩万江 需求变更管理原则 （1） 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 （2） 制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。 （3） 成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决
16、策人员在内。 （4） 需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。 （5） 需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。 （6） 妥善保存变更产生的相关文档。 需求变更应对之道 相互协作很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。 充分交流需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。 安排专职人员负责需求变更管理有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。 合同约束需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况
