软件过程管理(5)课件

1、承上启下项目合同管理生存期模型0 chapter_RoadMap合同管理 生存期需求管理任务分解项目进度规模估算质量计划配置计划风险计划团队管理项目度量集成项目跟踪控制 项目结束1 chapter_软件开发项目管理第四章软件项目需求管理2 chapter_需求管理中的问题举例需求的隐含错误需求不明确、含糊用户不断增加需求、变更需求用户刁难开发人员的镀金3 chapter_镀金（gold plating）的定义 给予用户的东西要多于他们所要求的。 事实上，额外的特性、扩展的功能、更好的组件以及其他等等，通常都不会为项目增加什么价值。实际上，镀金常常会增加项目的开支，因为这需要更多的资源、更长的开

2、发周期，还会增加重新设计的风险、耽误项目的交付使用。4 chapter_镀金案例在检视项目要求的时候，你发现了一个需要创建软件模块的要求。这个模块允许用户在浏览应用程序的时候，在屏幕上维持其所喜好的颜色和字体样式。在更进一步检视的时候，你意识到这个模块的加入虽然很好，但是不会为整个项目增添什么价值。 5 chapter_如何确定项目里是否包含有镀金的内容要验证开发要求或者任务里是否包含有镀金内容的一种方法是：思考一下如果项目没有包含这个模块的话，其影响会是什么。问问你自己：如果这个项目没有包含这个模块，这个应用程序的可靠性、效率是否会更低，或者根本就不会有任何降低。6 chapter_本章要点

3、一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析7 chapter_软件需求定义软件需求需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。9 chapter_软件需求的层次业务需求用户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求10 chapter_1业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明 2用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）

4、文档或方案脚本说明中予以说明。3功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 在软件需求规格说明书 （SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。11 chapter_作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约

5、；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。12 chapter_ 以一个字处理程序为例来说明需求的不同种类。 业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的

6、替换。13 chapter_功能需求功能需求：列举出被开发软件在职能上应做什么。这是最主要的需求，规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。通常功能性需求是： 产品功能的规格说明； 产品必须执行的动作； 源自于产品的基本目标例如：银行ATM系统 功能性需求：取、存、查、密码检验 14 chapter_非功能需求许多非功能需求关心的是系统整体特性，而不是个别的系统特性。因此非功能需求比功能需求对系统更关键。一个功能需求没有满足可能降低系统的能力，而一个非功能系统需求没有满足则可能使整个系统无法使用。例如：一个飞机系统不符合可靠性需求，它将不会被批准飞行。若

7、一个实时控制系统无法满足其性能需求，控制功能可能根本无法使用。例如：银行ATM系统 非功能需求：响应时间，安全保密等 15 chapter_需求管理的重要性16 chapter_项目失败的原因分析No. Top 10 Factors 平均值 1 Inadequate requirements specification 不充分的需求规范 4.5 2 Changes in requirements 需求的改变 4.3 3 Shortage of systems engineers 缺乏系统工程师 4.2 4 Shortage of software managers 缺乏了解软件特性的经理人 4

8、.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 系统集成阶段, 交流与沟通不充分 3.8 9 Insufficient experience as team团队缺乏经验 3.6 10 Shortage of application domain experts 缺乏应用领

9、域专家 3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University, Software Engineering Institute17 chapter_本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析18 chapter_软件需求管理过程软件需求管理的过程需求分析编写需求规格需求验证需求获取需求变更需求确认需求变更20 chapter_需求开发(确认)和管理基本任务需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理版本控制风险分

10、析21 chapter_本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析22 chapter_需求获取图示23 chapter_需求获取用户要求 扩展需求基线需求软件需求24 chapter_程、硬件环境、软件环境、现有的运行系统等具体情况和客观的信息，建立起良好的沟通渠道和方式25 chapter_26 chapter_进行需求获取应注意的问题识别真正的客户正确理解客户的需求具备较强的忍耐力和清晰的思维说明和教育客户27 chapter_本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验

11、证需求变更三、需求建模的基本方法四、案例分析28 chapter_需求分析定义需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 29 chapter_需求分析模型30 chapter_本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析31 chapter_需求规格需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。32 chapter_软件需求规格说明的原则从现实中分离功

12、能，即描述要“做什么”而不是“怎样实现”要求使用面向处理的规格说明语言（或称系统定义语言）如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中33 chapter_规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充34 chapter_3、规格文档参考引言系统定义 应用环境功能规格 性能需求产品提交实现约束质量描述其它签字认证35 chapter_本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析36 chapter_需求验证需求是正确的吗？需求是一致的

13、吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字37 chapter_本章要点一、软件需求定义二、软件需求管理过程需求的获取需求分析编写需求规格需求验证需求变更三、需求建模的基本方法四、案例分析38 chapter_需求总在变化39 chapter_40 chapter_需求变更管理确定需求变更控制过程建立变更控制委员会(SCCB)进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性41 chapter_需求变更管理管理和控制需求基线的过程需求变更控制系

14、统一个正式的文档，说明如何控制需求变更建立变更审批系统42 chapter_控制需求渐变的策略需求一定要与投入有显然的联系，在项目的开始双方都要明确：需求变化，成本也要变化。需求的变化要经过出资者的认可。小的需求变更也要经过正规的需求管理过程，否则积少成多。精确的需求和范围的定义并不会阻止需求的变更。这是两个层面的问题。43 chapter_变更控制过程44 chapter_需求变更处理流程提出变更变更评估实施变更45 chapter_变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划46 c

15、hapter_表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的变更可以推迟到下一个版本实施验证人杨炎泰验证日期20021011SCCB韩万江，姜岳尊，孙泉 填表人韩万江47 chapter_ 需求变更管理

16、原则 （1） 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 （2） 制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。 （3） 成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。 （4） 需求变更一定要先申请然后再评估，最后经过与变更大小相当级别

17、的评审确认。 （5） 需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。 （6） 妥善保存变更产生的相关文档。 48 chapter_需求变更应对之道 相互协作很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。 充分交流需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出

18、需求变更会给整个开发工作带来什么样的冲击和不良后果。 安排专职人员负责需求变更管理有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。 合同约束需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。 区别对待随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、49 chapter_需求变更应对之道对项目进度有重大影响的需求。遇到这种情况，开发人员可

19、以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变

20、更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。 用户参与需求评审作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。 50 chapter_本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法四、案例分析51 chapter_需求建模的基本方法原型方法结构化分析法面向对象的用例分析法功能列表法其他52 chapter_本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法原型方法结构化分析法面向对象的用

21、例分析法功能列表法其他四、案例分析53 chapter_原型方法按照用户的需要，快速形成一个操作流程界面可能只是一个框架，具体的功能没有实现，只是结果静态的操作流程，以便与用户快速就需求达成一致主要考虑系统的功能需求，很少考虑非功能需求54 chapter_原型方法需求分析原型开发原型评价55 chapter_原型方法的类型进化型开发出来用于了解问题，并形成被交付软件的部分或全部的基础抛弃型开发出来获以便更多地了解问题或探究可能的方案的灵活性或者合理性，是尝试性软件，不用于被交付软件的实际部分56 chapter_原型实例原型系统57 chapter_本章要点一、软件需求定义二、软件需求管理过

22、程三、需求建模的基本方法原型方法结构化分析法面向对象的用例分析法功能列表法其他四、案例分析58 chapter_结构化分析方法（SA,Structured Analysis）20世纪70年发展起来的面向数据流的方法是一种自顶向下逐步求精的分析方法根据软件内部数据传递、变换的关系进行分析的59 chapter_结构化分析方法-技术数据流图(DFD)数据字典(DD)系统流程图60 chapter_描述银行取款过程的数据流图61 chapter_数据流图的层次结构为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚

23、地表达和容易理解整个系统62 chapter_分层数据流图63 chapter_数据字典描述系统中涉及的每个数据,是数据描述的集合,通常配合数据流图使用,用来描述数据流图中出现的各种数据和加工.64 chapter_数据字典-组成数据项:数据元素数据流:由数据项组成的数据流数据文件:表示对数据文件的存储65 chapter_数据流图需求分析实例建立学生管理系统学管科体检科学籍科学生处66 chapter_数据流图-顶层学管科体检科学籍科学生管理信息系统学生处领导学生基本信息学生健康信息学生成绩学生健康情况表学生成绩单查询要求不及格人数人数统计表67 chapter_数据流图-0层68 chap

24、ter_数据流图-1层69 chapter_数据流图-1层70 chapter_数据字典-数据流 学生基本信息：学号十姓名 学生健康信息：学号十健康情况 学生成绩：学号十课程名+成绩 查询要求：健康查询单 |平均成绩查询单 l不及格人数查询 学生健康情况表：优十良十一般十差 学生成绩单：学号十姓名十课程名+成绩+总成绩 不及格人数统计表：学号十成绩十不及格总人数71 chapter_数据字典-数据文件文件名：基本信息组成：学号十姓名十入学成绩十生源组织：按学号递增顺序排列文件名：健康文件组成：学号+姓名+健康情况组织：按照健康情况为优、良、一般、差顺序排列文件名：成绩文件组成：学号+姓名+平均

25、成绩组织：按照评剧成绩递增顺序排列72 chapter_系统流程图系统包含的部分以及各个部分之间的关系是描述物理系统的工具用图形符号表示系统中的元素表达了系统中各个元素之间的信息流动情况73 chapter_系统流程图符号74 chapter_75 chapter_本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法原型方法结构化分析法面向对象的用例分析法功能列表法其他四、案例分析76 chapter_面向对象的需求分析OOSEOOAOODOOPOOT.77 chapter_OOA是OO软件工程的第一项技术活动将现实世界的“视图”转化为用对象来描述的模型描述对象之间的各种关系，以

26、满足软件系统的要求。78 chapter_用例需求（Use case）分析用例需求分析方法采用一种面向对象的情景分析方法用例是系统向用户提供一个有价值的结果的某项功能从用户角度出发考虑的功能需求所有的用例结合起来就构成了用例模型79 chapter_UML需求视图用例视图（Use case Diagram）顺序图（Sequence Diagram）状态图（State Diagram）活动图（Activity Diagram）80 chapter_81 chapter_82 chapter_83 chapter_84 chapter_用例视图用例视图主要是展示了外部行为者所观察到的系统将提交的功

27、能.即:各类外部行为者与系统所提供的用例的连接85 chapter_用例视图用例（Use case）：系统所提供的功能描述角色（Actor）：可能使用用例的人或者外部系统86 chapter_UML图符87 chapter_通信关系：执行者 与用例之间的连线来表示泛化关系：用例间的泛化关系意味着一个用例是另一个用例的特殊版本，特殊用例可在一般用例的执行序列的任意位置插入额外的动作序列，也可修改某些继承来的操作和顺序。在UML中用带连线的三角形表示。包含关系：描述用例间的共同行为，当两个或多个用例有共同的执行序列片断时，可将这些序列片断抽取，形成被包含用例。UML中用标有 include的虚箭头

28、线来表示。有点类似于程序间的调用关系。扩展关系：当对一个已存在的用例增加新的功能时，可使用扩展关系，扩展关系一般用于有条件地扩展已有用例的行为，是一种不改变原始用例的情况下增加用例行为的一种方法。88 chapter_存款验证密码支取管理取款维护通知透支转帐includeincludeextend顾客银行系统管理员89 chapter_用例实例90 chapter_用例实例91 chapter_顺序图示顺序图展示了几个对象之间的动态协作关系，主要用来显示对象之间发送消息的顺序，还显示对象之间的交互，即系统执行某一特定时间点所发生的事。 92 chapter_顺序图示93 chapter_状态视

29、图状态图是对类描述的补充，它说明该类的对象所有可能的状态以及那些事件将导致状态的改变。它是一个类对象所可能经历的所有历程的模型图94 chapter_活动视图活动图用来描述执行工作流程中涉及的活动，展示了连续的活动流95 chapter_活动图例96 chapter_Use Case需求分析方法综述识别出系统的Actor描述主要的Use case实现用例视图实现顺序视图，活动视图,状态视图等97 chapter_实例用Rational rose工具实现的需求规格文档贸易链需求的需求实例98 chapter_99 chapter_100 chapter_101 chapter_102 chapt

30、er_103 chapter_104 chapter_105 chapter_106 chapter_107 chapter_108 chapter_本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法原型方法结构化分析法面向对象的用例分析法功能列表法其他四、案例分析109 chapter_功能列表需求类别（功能/性能）名称/标识描述特性（Feature） AA.1A.n特性Feature BB.1B.n特性Feature CC.1C.n110 chapter_功能列表实例（某网站功能列表)111 chapter_本章要点一、软件需求定义二、软件需求管理过程三、需求建模的基本方法

31、四、案例分析112 chapter_案例分析“School”项目的需求管理过程：需求确认：原型法需求变更：变更控制系统变更过程113 chapter_Infosys公司常用的变更管理过程（1）记录变更。（2）分析变更对工作产品的影响。（3）估计变更申请所需的工作量。（4）重新估计交付时间表。（5）执行累积的成本影响分析。（6）如果影响超出一定限度，则与高级主管一起评审影响。（7）客户不再提出变更申请。（8）修改工作产品。114 chapter_变更申请日记护一个变更申请日记，以跟踪变更申请。日志中的每条记录包含一个变更申请号、关于变更的简单描述、变更的影响、变更申请的状态以及关键日期。在评估变

32、更申请的影响时，必须执行影响分析。影响分析涉及标识出需要进行变更的工作产品，并估算对每种产品的变更量；通过重新查看风险管理计划，重新评估项目风险；评估需求变更蕴涵的总的工作量和进度估计的变化。 客户对分析结果进行评审，并做出答复。变更申请一般作为需求规格说明文档的附件。有时还要修改文档的有关部分以反映所做的变更。监督已认可的变更申请并保证它们正确实现，这部分由配置管理过程处理。115 chapter_变更的累积影响 需求变更的一种危险是：尽管每种变更本身并不大，但是生命期中所有变更的累积影响却是很大的。因此，除了研究每个变更的影响并对它们进行跟踪外，还必须监督变更的累积影响。116 chapter_Infosys公司的项目经理有时为处理变更申请预留一定的余地