【文档说明】软件过程管理(5)课件.ppt，共(123)页，3.574 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50513.html

以下为本文档部分文字说明：

chapter__４0承上启下项目合同管理生存期模型chapter__４1RoadMap合同管理生存期需求管理任务分解项目进度规模估算质量计划配置计划风险计划团队管理项目度量集成项目跟踪控制项目结束chapter__４2软件开发项目管理第四章软件项目需求管理chapter__４3

需求管理中的问题举例需求的隐含错误需求不明确、含糊用户不断增加需求、变更需求用户刁难开发人员的镀金chapter__４4镀金（goldplating）的定义给予用户的东西要多于他们所要求的。事实上，额外的特性、扩展的功能

、更好的组件以及其他等等，通常都不会为项目增加什么价值。实际上，镀金常常会增加项目的开支，因为这需要更多的资源、更长的开发周期，还会增加重新设计的风险、耽误项目的交付使用。chapter__４5镀金案例n在检视项目要求的时候，你发

现了一个需要创建软件模块的要求。这个模块允许用户在浏览应用程序的时候，在屏幕上维持其所喜好的颜色和字体样式。在更进一步检视的时候，你意识到这个模块的加入虽然很好，但是不会为整个项目增添什么价值。chapter__４6如何确定项目

里是否包含有镀金的内容要验证开发要求或者任务里是否包含有镀金内容的一种方法是：思考一下如果项目没有包含这个模块的话，其影响会是什么。问问你自己：如果这个项目没有包含这个模块，这个应用程序的可靠性、效率是否会更低，或者根本就不会有任何降低。ch

apter__４7本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析软件需求定义chapter__４9软件需求需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么

样的功能，达到什么性能。chapter__４10软件需求的层次业务需求用户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求chapter__４111．业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明

2．用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functionalrequirement)定义了开发人

员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求

也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。chapter__４12作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体

细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。chapter__４13以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能

有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许

多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。chapter__４14功能需求功能需求：列举出被开发软件在职能上应做什么。这是最主要的需求，规定开发人员必须在产品中实现的软件功能，用户利

用这些功能来完成任务，满足业务需求。通常功能性需求是：产品功能的规格说明；产品必须执行的动作；源自于产品的基本目标例如：银行ATM系统功能性需求：取、存、查、密码检验chapter__４15非功能需求n许多非功能需求关心的是系统整体特性，而不是个

别的系统特性。因此非功能需求比功能需求对系统更关键。一个功能需求没有满足可能降低系统的能力，而一个非功能系统需求没有满足则可能使整个系统无法使用。n例如：一个飞机系统不符合可靠性需求，它将不会被批准飞行。若一个实时控制系统无法满足其性能需求，控制功能可能根本无法使用。例如：银行AT

M系统非功能需求：响应时间，安全保密等chapter__４16需求管理的重要性chapter__４17项目失败的原因分析No.Top10Factors平均值1Inadequaterequirementsspecification不充分的需求规

范4.52Changesinrequirements需求的改变4.33Shortageofsystemsengineers缺乏系统工程师4.24Shortageofsoftwaremanagers缺乏了解软件特

性的经理人4.15Shortageofqualifiedprojectmanagers缺乏合格的项目经理4.16Shortageofsoftwareengineers缺乏软件工程师3.97Fixed-pricecontract固定价合同3.8

8Inadequatecommunicationsforsystemintegration系统集成阶段,交流与沟通不充分3.89Insufficientexperienceasteam团队缺乏经验3.610Shortageofapplicationdomainexper

ts缺乏应用领域专家3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitutechapter__４18本章要点一、

软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析软件需求管理过程chapter__４20软件需求管理的过程需求分析编写需求规格需求验证需求获取需求变更需求确认需求变更chapt

er__４21需求开发(确认)和管理基本任务需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理版本控制风险分析chapter__４22本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分

析chapter__４23需求获取图示chapter__４24需求获取用户要求扩展需求基线需求软件需求chapter__４25程、硬件环境、软件环境、现有的运行系统等具体情况和客观的信息，建立起良好的沟通渠道和方式chapter__４26

chapter__４27进行需求获取应注意的问题1.识别真正的客户2.正确理解客户的需求3.具备较强的忍耐力和清晰的思维4.说明和教育客户chapter__４28本章要点一、软件需求定义二、软件需求管理过

程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析chapter__４29需求分析定义需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。chapter__４30需求分析模型chapter__４31本章要点一、

软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析chapter__４32需求规格需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户

和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。chapter__４33软件需求规格说明的原则从现实中分离功能，即描述要“做什么”而不是“怎样实现”要求使用面向处理的规格说明语言（或称

系统定义语言）如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中chapter__４34规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充chapter__４353、规格文档参考1.

引言2.系统定义3.应用环境4.功能规格5.性能需求6.产品提交7.实现约束8.质量描述9.其它10.签字认证chapter__４36本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析chapter

__４37需求验证需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字chapter__４38本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、

需求建模的基本方法四、案例分析chapter__４39需求总在变化chapter__４40chapter__４41需求变更管理1.确定需求变更控制过程2.建立变更控制委员会(SCCB)3.进行需求变更影响分析4.跟

踪所有受需求变更影响的工作产品5.建立需求基准版本和需求控制版本文档6.维护需求变更的历史记录7.跟踪每项需求的状态8.衡量需求稳定性chapter__４42需求变更管理管理和控制需求基线的过程需求变更控制系统一个正式的文档，说明如何控制需求变更建立变更审批系统chapter__４43控

制需求渐变的策略1.需求一定要与投入有显然的联系，在项目的开始双方都要明确：需求变化，成本也要变化。2.需求的变化要经过出资者的认可。3.小的需求变更也要经过正规的需求管理过程，否则积少成多。4.精确的需求和范围的定义并不会阻止需求的变更。这是两个层面的问

题。chapter__４44变更控制过程chapter__４45需求变更处理流程n提出变更n变更评估n实施变更chapter__４46变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修

改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划chapter__４47表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__４48需求变更管理原则（1）建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经

过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。（2）制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性

，对以后的项目开发和其他项目都有借鉴作用。（3）成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。（4）需求变更一定要先申请然后再评估，

最后经过与变更大小相当级别的评审确认。（5）需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。（6）妥善保存变更产生的相关文档。chapter__４49需求变更应对之道•

相互协作——很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。•充分交流——需求变更管理的过程很大程度上就是用户与开发人员的交

流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。•安排专职人员负责需求变更管理——有时开发任务较重，开发人员容易陷入开发工作中

而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。•合同约束——需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分

接受，还可以规定发生需求变更时必须执行变更控制流程。•区别对待——随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、chapter__４50需求变更应对之道•对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，

项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时

，还要注意控制新需求提出的频率。•选用适当的开发模型——采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的

解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。•用户参与需求评审——作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，

在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。chapter__４51本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析chapter__

４52需求建模的基本方法1.原型方法2.结构化分析法3.面向对象的用例分析法4.功能列表法5.其他chapter__４53本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法原型方法结构化分析法面

向对象的用例分析法功能列表法其他四、案例分析chapter__４54原型方法按照用户的需要，快速形成一个操作流程界面可能只是一个框架，具体的功能没有实现，只是结果静态的操作流程，以便与用户

快速就需求达成一致主要考虑系统的功能需求，很少考虑非功能需求chapter__４55原型方法需求分析原型开发原型评价chapter__４56原型方法的类型进化型开发出来用于了解问题，并形成被交付软件的部分或全部

的基础抛弃型开发出来获以便更多地了解问题或探究可能的方案的灵活性或者合理性，是尝试性软件，不用于被交付软件的实际部分chapter__４57原型实例原型系统chapter__４58本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法

原型方法结构化分析法面向对象的用例分析法功能列表法其他四、案例分析chapter__４59结构化分析方法（SA,StructuredAnalysis）20世纪70年发展起来的面向数据流的方法是一种自顶向下逐步求精的分析方法

根据软件内部数据传递、变换的关系进行分析的chapter__４60结构化分析方法-技术数据流图(DFD)数据字典(DD)系统流程图chapter__４61描述银行取款过程的数据流图chapter__４62数

据流图的层次结构为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统chapter__４63chapter__４64数据字典描述系统中涉及的

每个数据,是数据描述的集合,通常配合数据流图使用,用来描述数据流图中出现的各种数据和加工.chapter__４65数据字典-组成数据项:数据元素数据流:由数据项组成的数据流数据文件:表示对数据文件的存储chapter__４66数据流图需求分

析实例建立学生管理系统学管科体检科学籍科学生处chapter__４67数据流图-顶层学管科体检科学籍科学生管理信息系统学生处领导学生基本信息学生健康信息学生成绩学生健康情况表学生成绩单查询要求不及格人数人数统计表chapter__４68数据流图-0层chapter__４69

数据流图-1层chapter__４70数据流图-1层chapter__４71数据字典-数据流学生基本信息：学号十姓名学生健康信息：学号十健康情况学生成绩：学号十{课程名+成绩}查询要求：[健康查询单|平均成绩查询单l不及格人数查询]学生健康情况表：优％十良％十一般％十差％学生成绩单：学号

十姓名十{课程名+成绩}+总成绩不及格人数统计表：学号十成绩十不及格总人数chapter__４72数据字典-数据文件文件名：基本信息组成：｛学号十姓名十入学成绩十生源｝组织：按学号递增顺序排列文件名：健康文件组成：{学号+

姓名+健康情况}组织：按照健康情况为优、良、一般、差顺序排列文件名：成绩文件组成：{学号+姓名+平均成绩}组织：按照评剧成绩递增顺序排列chapter__４73系统流程图系统包含的部分以及各个部分之间的

关系是描述物理系统的工具用图形符号表示系统中的元素表达了系统中各个元素之间的信息流动情况chapter__４74系统流程图符号chapter__４75制定出访计划开始出访组团登记出访计划表?出访团组基本情况登记表是否需要办理护照护照管理护照

登记表?护照卡?申请护照签证管理结束是否临时出访计划表?申请出国护照事项表申请出国签证事项表?高检院外事局出访业务流程图计划是否落实是否是否本单位人员是否结束chapter__４76本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法原型方法结构化分析

法面向对象的用例分析法功能列表法其他四、案例分析chapter__４77面向对象的需求分析OOSEOOAOODOOPOOT…….chapter__４78OOA是OO软件工程的第一项技术活动将现实世界的“视图”转化为用对象来描述的模型描

述对象之间的各种关系，以满足软件系统的要求。chapter__４79用例需求（Usecase）分析用例需求分析方法采用一种面向对象的情景分析方法用例是系统向用户提供一个有价值的结果的某项功能从用户角度出发考虑的功能需求所有的用例结合起来就构成了用例

模型chapter__４80UML需求视图用例视图（UsecaseDiagram）顺序图（SequenceDiagram）状态图（StateDiagram）活动图（ActivityDiagram）chapter__４81

chapter__４82chapter__４83chapter__４84chapter__４85用例视图用例视图主要是展示了外部行为者所观察到的系统将提交的功能.即:各类外部行为者与系统所提供的用例的连接chapte

r__４86用例视图用例（Usecase）：系统所提供的功能描述角色（Actor）：可能使用用例的人或者外部系统chapter__４87UML图符chapter__４88n通信关系：执行者与用例之间的连线来表示n泛化关系：用例间

的泛化关系意味着一个用例是另一个用例的特殊版本，特殊用例可在一般用例的执行序列的任意位置插入额外的动作序列，也可修改某些继承来的操作和顺序。在UML中用带连线的三角形表示。n包含关系：描述用例间的共同行为，当两个或多个用例有共同的执行序列片断时，可将这

些序列片断抽取，形成被包含用例。UML中用标有《include》的虚箭头线来表示。有点类似于程序间的调用关系。n扩展关系：当对一个已存在的用例增加新的功能时，可使用扩展关系，扩展关系一般用于有条件地扩展已有用例的行为，是一种不改变原始用例的情况下增加用例行为的一种方法。c

hapter__４89存款验证密码支取管理取款维护通知透支转帐《include》《include》《extend》顾客银行系统管理员chapter__４90用例实例chapter__４91用例实例chapter_

_４92顺序图示顺序图展示了几个对象之间的动态协作关系，主要用来显示对象之间发送消息的顺序，还显示对象之间的交互，即系统执行某一特定时间点所发生的事。chapter__４93顺序图示chapter__４94状态视图状态图是对类描述的补充，它说明该类的对象所有可能的状态以及那些事件将导致状态的改

变。它是一个类对象所可能经历的所有历程的模型图chapter__４95活动视图活动图用来描述执行工作流程中涉及的活动，展示了连续的活动流chapter__４96活动图例chapter__４97UseCase需求分析方法综述识别出系统

的Actor描述主要的Usecase实现用例视图实现顺序视图，活动视图,状态视图等chapter__４98实例用Rationalrose工具实现的需求规格文档贸易链需求的需求实例chapter__４99chapter__４100cha

pter__４101chapter__４102chapter__４103chapter__４104chapter__４105chapter__４106chapter__４107chapter__４108chapter__４109本章要点一、软件需求定义二、软件需求管理过程三、需求建

模的基本方法原型方法结构化分析法面向对象的用例分析法功能列表法其他四、案例分析chapter__４110功能列表需求类别（功能/性能）名称/标识描述特性（Feature）AA.1……A.n特性FeatureBB.1……B.n特性FeatureCC.1……C.n

chapter__４111功能列表实例（某网站功能列表)chapter__４112本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析chapter__４113案例分析―School‖项目的需求管理过程：需求确认：原型法需求变

更：变更控制系统变更过程chapter__４114Infosys公司常用的变更管理过程（1）记录变更。（2）分析变更对工作产品的影响。（3）估计变更申请所需的工作量。（4）重新估计交付时间表。（5）执行累积的成本影响分析。（6）如果影响超出一定限度，则与高

级主管一起评审影响。（7）客户不再提出变更申请。（8）修改工作产品。chapter__４115变更申请日记n护一个变更申请日记，以跟踪变更申请。n日志中的每条记录包含一个变更申请号、关于变更的简单描述、变更的影响、变更申请的状态以及关键日期。n在评估变

更申请的影响时，必须执行影响分析。n影响分析涉及标识出需要进行变更的工作产品，并估算对每种产品的变更量；通过重新查看风险管理计划，重新评估项目风险；评估需求变更蕴涵的总的工作量和进度估计的变化。n客户对分析结果进行评审，并做

出答复。n变更申请一般作为需求规格说明文档的附件。有时还要修改文档的有关部分以反映所做的变更。n监督已认可的变更申请并保证它们正确实现，这部分由配置管理过程处理。chapter__４116变更的累积影响需求变

更的一种危险是：尽管每种变更本身并不大，但是生命期中所有变更的累积影响却是很大的。因此，除了研究每个变更的影响并对它们进行跟踪外，还必须监督变更的累积影响。chapter__４117Infosys公司的项目经理有时为处理变更申请预留一定

的余地。–只要所有变更累积的工作量不超过这一预留的工作量，就不需要做任何特殊的处理。–然而，如果所有变更的累积工作量超过了这一预留的工作量，则再进行变更可能会对总成本和进度安排产生负面影响。在这种情况中，项目经理必须修改估计并使它们得

到承认。chapter__４118课堂讨论面对客户的需求变更，接受还是拒绝？在某公司的项目管理课堂上，小李，小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近遇到的两个颇为有趣的项目。据小王介绍，这两个

项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬

，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。chapter__４119话刚一说完，小李就抢着说：“A比较像我，一般在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家

二话没说就同意改了。你说如果是B的话可能吗？”小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”小林接着小王的话说：“

当前，国内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。”chapter__４120小赵反驳道：“不管怎

样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。”问题：1、如果你的项目遇

到需求变更问题，你会采用哪种方式去应对？2、分析这两种应对需求变更方式的优缺点。分析结果chapter__４121chapter__４122小结软件需求开发过程需求的获取需求分析编写需求规格需求验证

需求变更需求建模的基本方法原型方法结构化分析法面向对象的用例分析法关键功能列表法