软件项目管理课程清华.pptx

《软件项目管理课程清华.pptx》由会员分享，可在线阅读，更多相关《软件项目管理课程清华.pptx（452页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第第 1 1 章章 导导 论论第1页/共452页1.1软件工程软件工程一、软件工程定义一、软件工程定义软件：是与一个系统，特别是一个计算机系统有关的程序、过程和有关文档的完整集合。工程：是科学和数学的应用，通过这一应用，使得自然界的物质和能源的特性通过各种结构、机器、产品、系统和过程成为对人类有用的东西。第2页/共452页软件工程的定义有多种说法:Fritz BauerNAV69在NATO会议上给出的定义:软件工程是建立和使用一套合理的工程原则，从而经济地获得可靠的和能在实际机器上高效运行的软件。第3页/共452页IEEEIEEE93给出了一个更加综合的定义：（）将系统化的、规范的、可度量的方

2、法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。（）（）中所述方法的研究。第4页/共452页本书给出的定义:软件工程是一类求解软件的工程。它应用计算机科学、数学以及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高软件质量、降低成本、按时按量交付的目的。第5页/共452页计算机科学、数学用于构造模型和算法。工程科学用于制定规范、设计模式、评估成本及确定权衡。管理科学用于计划、资源、质量、成本等管理。第6页/共452页二软件工程框架二软件工程框架软件工程目标软件工程活动软件工程原则第7页/共452页软件工程框架软件工程框架第8页/共452页软件工程目标正确性软件产品达到预

3、期功能的程 度。可用性软件基本结构、实现、文档为用户可用的程度。合算性具有经济效益，即开发、运行的开销满足用户要求的程度。第9页/共452页软件工程活动-生产软件步骤问题定义明确要解决的问题可行性分析即定义的问题是否有解决的办法需求分析为解决问题，目标系统必须具备哪些功能设计总体设计，详细设计实现编写程序代码确认测试支持软件维护第10页/共452页软件工程原则选取适宜的开发模型采用合适的设计方法提供高质量的工程支持重视开发过程的管理第11页/共452页三软件工程模型所有软件工程的活动都必须进行管理。软件项目管理贯穿于软件工程的演化过程。软件工程的演化过程：第12页/共452页三软件工程模型软件

4、工程模型:组织软件工程活动的方法，称为软件工程模型。软件工程模型是用一定的流程将各个活动连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见模型有线性、快速原型、螺旋、渐增式等模型。第13页/共452页常见的软件工程模型线性模型（也称，瀑布模型，顺序模型）第14页/共452页常用的软件工程模型螺旋模型可看成是连接的线性模型第15页/共452页常用的软件工程模型渐增式模型（增量模型）第16页/共452页常用的软件工程模型渐增式模型首先构建系统的基本轮询回路：第17页/共452页1.2项目管理一项目与项目管理项目与项目管理项目的概念及特点项目：是指在一定约束条件下具有特定目标的一项一次性任

5、务共同特点：一次性，又称为单件性目标的明确性：成果性目标（功能性要求），约束性目标作为管理对象的整体性第18页/共452页2、项目的生命周期第19页/共452页项目的生命周期 项目启动阶段进行可行性分析，若接受项目进行需求确认，项目立项项目计划阶段建立解决问题方案，向客户提交各种计划书项目实施阶段执行解决方案，实现项目的目标工作结束阶段正式验收项目第20页/共452页另一书中对项目周期阶段的划分生命周期阶段 工程阶段 初始阶段 细化阶段 生产阶段 构造阶段 移交阶段第21页/共452页各阶段特点工程阶段：使计划、需求和构架同时进化，并解决开发风险，这个阶段以一个可执行构架基线结束，即工程阶段进

6、行设计和综合活动。生产阶段：进行构造、测试和实施活动。第22页/共452页各阶段特点借助提高功能的演示使系统能力得以进化。各种活动同时进化，每个阶段都包括一次或多次迭代，一次迭代表示一个活动序列，这些活动有明确的中间事件（里程碑）。第23页/共452页各阶段特点主里程碑：使用正式版本的评价标准和发布说明书，一个阶段结束产生一个主里程碑。次里程碑：使用非正式版本，一次迭代结束产生一个次里程碑。第24页/共452页各阶段特点为实现整个项目的某个特定状态，每个阶段都要进行足够次数迭代。各阶段的工作产品（制品，文档等），同时进化产生，但每个阶段都有一个主要焦点：初始阶段需求 （生命周期目标里程碑）细化

7、阶段设计 （生命周期构架里程碑）构造阶段实现 （初始的可操作能力里程碑）移交阶段实施 （产品发布里程碑）（这里的模型是渐增式（增量式）第25页/共452页项目管理项目管理定义PMI（Project Management Institute）定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。项目管理又可定义为：在一个确定的时间范围内，为了完成一个既定的目标，通过特殊形式的临时性组织运行机制，经有效的计划、组织、领导和控制，充分利用既定有限资源的一种系统管理方法。第26页/共452页项目管理特点综合性创造性时间性第27页/共452页项目管理的要素范围、时间、

8、成本、质量、组织、客户满意度第28页/共452页二项目管理知识体系1.集成管理2.范围管理3.时间管理4.成本管理5.质量管理6.人力资源管理7.沟通管理8.采购管理9.风险管理第29页/共452页三项目管理学科的发展项目管理学科发展的特点 全球化发展、多元化发展、专业化发展项目管理学科在双向探索中前进 各学科领域的理论、方法应用于项目管理，项目管理的理论、方法应用于各学科领域项目学发展的趋势1.微观项目管理，即单一项目的管理2.PMBOK是当前项目管理学科发展的重要内容3.项目学是知识创新与市场相结合的综合化发展4.项目学是科学、技术和艺术的综合第30页/共452页软件项目管理一软件项目产品

9、的特点1.抽象性2.缺陷检测的困难性3.高度的复杂性4.缺乏统一规则第31页/共452页二软件项目失控的原因软件失控项目(p15-16)是指软件项目在进行时遇到困难，导致大大超出可控制范围的项目。软件项目失控的原因 七方面原因：需求不明确、计划不充分和过于乐观的估计、采用新技术、管理方法缺乏或不恰当、性能问题、团队组织不当、人际因素第32页/共452页三软件项目管理的内容软件项目管理的定义(p19)软件项目管理的过程(p19)软件项目管理的内容(p19-20)第33页/共452页软件项目管理的定义PMI对项目管理定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目

10、的要求。软件项目管理的定义：在软件项目活动中运用一系列的知识、技能、工具和技术，以满足软件需求方的整体要求。第34页/共452页软件项目管理的过程1.启动软件项目2.制定项目计划3.跟踪及控制项目计划4.评审项目计划5.编写管理文档第35页/共452页软件项目管理的内容1.软件项目需求管理 2.软件项目估算与进度管理 3.软件项目配置管理 4.软件项目风险管理 5.软件项目质量管理 6.软件项目资源管理 第36页/共452页第章第章软件项目需求管理软件项目需求管理第37页/共452页 软件需求一.软件需求概念1.定义简单地说，软件需求就是确定系统需要做什么严格意义上，软件需求是系统或软件必须达

11、到的目标与能力第38页/共452页定义软件需求的五项内容1.系统的输入2.系统的输出3.系统的功能4.系统的属性5.系统环境的属性第39页/共452页2.软件需求在软件项目的作用软件需求与其他软件过程的关系第40页/共452页二软件需求类别1.软件需求的抽象层次软件需求分成四个抽象层次1.原始问题描述2.用户需求3.系统需求4.软件设计描述第41页/共452页软件需求的抽象层次第42页/共452页1.原始问题描述是对要解决问题的叙述2.用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束3.系统需求用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述4

12、.软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述第43页/共452页原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现通常情况下，经常提到的是用户需求和系统需求第44页/共452页2.用户需求用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述第45页/

13、共452页使用自然语言可能出现如下问题描述困难需求混乱因此写需求文档应遵守一些简单原则：标准的格式使用一致的语言使用特殊文本尽量避免专业术语第46页/共452页3.系统需求系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点系统需求描述通常采用结构化语言和过程设计语言PDL.第47页/共452页 系统需求的描述语言名称 说明 优点 缺点 结构化语言是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述表现能力强、易于理解、一致性约束、控制结构、图形化显示仍然有一定程度的二义性；细致程度欠缺PDL 源于像Java或Ada这样的程序设计语

14、言，包含附加的、更抽象的构造来提高其表达能力 可通过软件工具进行语法和语义检查表达系统功能的能力不足、使用的符号只有具有程序设计背景的人才能理解第48页/共452页4系统需求的分类分为三类：功能需求 非功能需求 领域需求第49页/共452页(1)功能需求功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述系统的功能需求应该具备全面性和一致性要做到全面和一致几乎是不可能的原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正

15、需求文档第50页/共452页(2)非功能需求非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等第51页/共452页按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程第52页/共452页表2.2 非功能需求的类别非功能需求 产品需求 可用性需求 效率需求 性能需求 空间需求 可靠性需求 可

16、移植性需求 机构需求 交付需求 实现需求 标准需求 外部需求 互操作需求 道德需求 立法需求 隐私需求安全性需求第53页/共452页(3)领域需求领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识第54页/共452页三软件需求文档软件需求文档是对软件系统要求的陈述 包括：用户需求 系统需求第55页/共452页三软件需求文档1.需求文档的编制与作用需求文档的编制与作用编写需求文档时，以下几点是应该注意的：语句和段落尽量简短表达时采用主动语态语句要完整，且语法，标点等正确无误使用的术语要与词汇表中的定义保持一致陈述时要采

17、用一致的样式避免模糊的，主观的术语，如性能优越避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证第56页/共452页需求文档的作用 使用对象 需求文档的作用 软件项目客户 了解软件项目能够提供的软件产品，检查 软件需求是否满足需要项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员 理解要开发的产品及具体要开发的内容软件测试人员 验证软件系统是否满足了预期的要求软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员 在需求文档的基础上编写用户文档，如用户手册软件培训人员 在需求文档的基础上编写培训材料第57页/共452页

18、软件需求规格说明(1)基本含义规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档第58页/共452页软件项目管理者用SRS来对项目进行计划和管理。除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。SRS的基本内容包括功能需求和非功能需求。功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功

19、能,是整个软件需求的核心。非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。第59页/共452页(2)IEEE标准830-1998 见:P27P28第60页/共452页(3)SRS 大纲 见:P28-P29第61页/共452页四.软件需求度量一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节.软件需求质量度量的九个元素,即正确,无歧义,完备,一致,分级,可验证,可修改,可跟踪及可理解第62页/共452页22 需求工程第63页/共452页一、产生与发展1、产生人们逐渐认识到需求分析活动不再仅限

20、于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。需求规格说明又是软件设计、实现、测试直至维护的主要基础。第64页/共452页2.发展需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合发展。（）对象化需求工程的对象化主要是指需求模型及其构造方法的对象化，面向对象需求模型及需求定义语言是其研究的关键。第65页/共452页（）形式化 需求规格描述方法有三种:形式化方法、非形式化方法和半形式化方法。形式化方法是具有严格数学基础的描述系统特征的方法，具有准确

21、、无二义性的特点，有助于验证有效性和完整性。非形式化方法使用未作任何限制的自然语言，易于理解和使用，但它固有二义性，且难以保证正确性、可维护性，难以用计算机系统提供自动化的支持。半形式化方法介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些局部方面则允许使用非形式化的自然语言。第66页/共452页(3)自动化在自动化的层次方面，已从实现级、设计级发展到功能级，并逐渐渗透到需求级。第67页/共452页二.研究内容、需求工程的目标 需求工程有两个主要任务：其一是通过对问题及其环境的理解、分析和综合，建立分析模型;其二是在完全弄清用户对软件系统的确切要求的基础上，用SRS把用户的需求表达

22、出来。第68页/共452页（）建立需求分析模型分析模型是描述软件需求的一组模型。需求分析模型包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，是形成需求说明、进行软件设计及实现的基础。（）编写SRSSRS的编写要以需求分析模型为基础、按照软件组织定义的SRS大纲、采用某种需求描述语言来进行。第69页/共452页、需求工程的层次分解 需求工程可分为需求开发和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。第70页/共452页需求开发和需求管理是有界限的：第71页/共452页 需求管理第72页/共452页一.需求管理的必要性、需求供求双方固有的矛盾需求过程中，需

23、求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。、需求具有易变性和难以表述性软件项目中的问题都是在需求分析阶段埋下的祸根。软件需求还很难以表述。正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。第73页/共452页、需求错误出现的高频性和修复的高昂成本需求错误出现的高频性和修复的高昂成本需求错误是软件项目开发中最常见的。需求错误是软件项目开发中最常见的。表2.4 软件缺陷总结缺陷来源 潜在缺陷 剩余缺陷 排除效率（%）需求 0.2 0.046 77 设计 0.25 0.0375 85 编码 0.35 0.0175 95 建档 0.12

24、 0.024 80 修复 0.08 0.024 70 合计 1 0.149 85.1 第74页/共452页一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的倍。对于软件缺陷，修复的发现和修复的越早，则成本越低。做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。第75页/共452页软件缺陷修复的成本软件缺陷修复的成本第76页/共452页二.目标和原则、目标(p35-36)需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。具体来说,需求管理的目标有二个:(1)使软件需求受控,并建立供软件工程和管理使用的需求基线。(2)使软件计划、产品

25、和活动与软件需求保持一致。第77页/共452页、原则为进行有效的需求管理，通常要遵循如下五条原则：（）需求一定要分类管理（）需求必须分优先级（）需求必须文档化（）需求一旦变化，就必须对需求变更的影响进行评估（）需求管理必须与需求工程的其他活动紧密整合第78页/共452页三.需求管理活动需求管理规划内容包括：需求识别 变更管理过程 需求跟踪 自动化工具第79页/共452页需求管理是一个对系统需求变更了解和控制的过程。需求管理的过程是与其他需求工程过程相互关联的。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。第80页/共452页需求管理活动的具体内容如

26、表所示需求管理活动 活动的任务变更控制 建议需求变更并分析其影响，做出是否变更的决策版本控制 确定单个需求和SRS的版本需求跟踪 定义对于其他需求及系统元素的联系链需求状态 定义并跟踪需求的状态第81页/共452页2.3.4 需求变更管理1、需求变更的原因 软件项目的需求总是在变化着,一般原因有二:(1)在项目的早期所有的问题不可能被完全定义,软件需求是不完全的,注定了需求需要变更。(2)随着软件项目的进行,软件开发人员对问题的理解会发生变化,这些变化也要反馈到需求中去。第82页/共452页大型软件系统还可能存在如下导致需求变更的原因:(1)不同类型的用户的需求可能是冲突的或是矛盾的,最后的系

27、统需求是它们之间的一个妥协.这种妥协的程度在项目进行过程中有可能发生改变,从而导致系统需求的改变。(2)系统购买者或系统最终用户很少是同一人,有的系统客户对系统提出的一些需求可能和最终用户需求不一致。第83页/共452页2、变更管理过程 变更管理过程分为变更描述、变更分析和变更实现三个阶段。第84页/共452页(1)变更描述 变更描述阶段要对需求问题或变更提议进行分析以检查它的有效性，进而产生一个更明确的需求变更提议。(2)变更分析 变更分析阶段对被提议的变更产生的影响进行评估。一旦分析完成，就有了对此变更是否执行的决策意见。第85页/共452页(3)变更实现 实现变更时，需求文档及系统设计和

28、实现都要做修改。一个容易出现的错误，一定要注意：先对系统做变更然后再回头修改需求文档的想法，这几乎不可避免地导致需求描述和系统实现不同步。需求文档应该有一个很好的形式，使得变更不会带来大量文字的修改。对于程序文档的可变性则通过最小化外部引用和尽量使之模块化来实现。第86页/共452页3、变更影响分析进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其他需求的影响,同时明确与变更相关的任务并评估完成这些任务需要的工作量。变更影响分析有助于做出信息量充分的变更决策,确定对变更是修改还是抛弃,或者创建新系统以及评估每个任务的工作量.第87页/共452页如果一个处于关键路径的任务

29、因变更而延期,则项目肯定赶不上预定进度,但如果能避免变更影响关键任务,则变更不会影响项目的进度表影响分析报告的模板,用来报告进行需求变更的影响分析,变更控制委员会仅需要影响分析的总结.第88页/共452页需求变更影响分析模板需求变更影响分析模板第89页/共452页4、变更控制流程需求变更控制的流程如图所示第90页/共452页2.3.5需求文档版本如果没有很好的需求文档版本管理,就容易造成资源浪费.需求文档版本控制是需求管理的一个必要方面.第91页/共452页做好需求文档版本控制,必须保证如下几点:统一确定需求文档的每一个版本,保证每个成员都能得到当前的需求版本;清楚地将变更写成文档,并及时通知

30、项目开发所涉及的人员;为尽量减少困惑、冲突、误传，应只允许指定的人来更新需求文档。第92页/共452页版本控制的最简单方法是在每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已作变更的内容、变更日期、变更人的姓名以及变更的原因，并根据标准约定手工标记软件需求规格说明的每一次修改。第93页/共452页2.3.6需求状态1、需求的属性 需求还有一些相关的属性,这些属性的定义及更新是需求管理的重要内容.需求的属性为需求提供了背景资料和上下文关系。第94页/共452页需求要考虑的属性如下(1)需求的创建时间(2)需求的版本(3)需求的创建者(4)需求的批准者(5)需求的状态(6)需求的原因

31、或根据(7)需求涉及的子系统(8)需求涉及的产品版本(9)需求的验证方法或测试标准(10)需求的优先级(11)需求的稳定性第95页/共452页需求的优先级,即从实现需求所涉及的代价、收益、成本、风险四个方面考察需求的优先级需求的稳定性，表示将来需求可能变更的程度，稳定性越差，意味着需求越容易发生变更，因而应给予较多的关注。第96页/共452页2、需求状态 需求状态是需求的一项重要属性,跟踪需求的状态是需求管理的一个重要方面。何谓需求状态?状态是一种事物或实体在某一个时间点或某一阶段的情况的反映。需求状态是指某时间点需求的一种情况反映。第97页/共452页客户的需求可分为四种情况:客户可以明确且

32、清楚地提出的需求.客户知道需要做些什么,但却不能确定的需求.需求可以由客户得出,但需求的业务不明确,还需要等待外部信息.客户本身也说不清楚的需求.第98页/共452页需要与客户沟通或确认的需求有两种情况:其一是确认双方达成共识 其二是还需要再进一步的沟通可把需求状态分为如下8种 已建议 已批准 已拒绝 已设计 已实现 已验证 已交付 已删除第99页/共452页2.3.7需求跟踪1、需求跟踪的必要性 进行需求跟踪的目的是建立和维护从用户需求开始到测试之间的一致性与完整性,确保所有的实现都以用户需求为基础,而实现的需求也全部覆盖了预期的需求,同时确保所有的输出与用户需求的符合性.跟踪能力信息使得变

33、更影响分析十分便利,有利于确认和评估实现某个建议的需求变更所必须的工作.第100页/共452页2、可追溯性信息 进行需求跟踪,就要对需求和需求之间以及需求和系统设计之间的许多关系进行追溯。当需求变更发生的时候,必须追踪这些变题对其他需求和系统设计的影响。可追溯性是需求描述的一个总体特性,反映了反映相关需求的能力。第101页/共452页需要维护的可追溯性信息有三类:(1)源可追溯性信息,指连接需求到提出需求 的项目相关人员和产生需求的原因.(2)需求可追溯性信息,指连接需求文档中彼此依赖的需求.(3)设计可追溯性信息,指连接需求到其实现的设计模块.第102页/共452页3、需求跟踪的实现需求跟踪

34、有两种方式,正向跟踪和逆向跟踪：(1)正向跟踪以用户需求为切入点,检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。(2)逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。第103页/共452页需求跟踪的双向模式可以通过需求链来表示第104页/共452页过程元素之间的关系有如下三种一对一，如一个代码模块应用一个设计元素。一对多，如多个测试实例验证一个功能需求。多对多，如一个测试实例导致多个功能性需求，而其中一些功能性需求又拥有多个使用实例。第105页/共452页需求跟踪矩阵需求代号规格说明需求实例设计实例编码实例测试实例测试记录R00

35、1标题或标识符标题或标识符标题或标识符标题或标识符标题或标识符标题或标识符R002第106页/共452页4 4、需求跟踪的作用、需求跟踪的作用在需求验证中的作用有助于需求变更影响分析便于需求的维护便于测试时找出问题所在便于项目跟踪减小项目的风险简化了系统的再设计易于软件重用第107页/共452页2.4 需求管理质量保证第108页/共452页2.4.1 需求验证1.需求验证过程审查需求文档依据需求编写测试用例编写用户手册确定合格的标准第109页/共452页2.验证的内容 在需求验证过程中,要对需求文档中定义的需求执行多种类型的检查：有效性检查 一致性检查 完备性检查 现实性检查 可检验性检查 可

36、跟踪性检查 可调节性检查 可读性检查第110页/共452页2.4.2 需求评审1.方式 评审有两类方式:一类是正式技术评审,另一类是非正式技术评审。2.注意事项 严格控制每一次评审的文档规模及持续时间评审工作要分段进行对讨论的问题进行控制避免无谓的争吵第111页/共452页第第3章章 软件项目估算与进度管理软件项目估算与进度管理主要内容：3.1 软件项目估算3.2 软件规模3.3 软件项目成本估算3.4 软件项目进度管理第112页/共452页3.1 软件项目估算1.项目估算的意义：包括工作量估算和成本估算两个方面。估算是指通过预测构造软件项目所需要的工作量的过程，初步的估算用于确定软件项目的可

37、行性，详细的估算用于指导项目计划的制定。进度计划是从时间的角度对项目进行规划，而成本估算则是从费用的角度对项目进行规划。第113页/共452页2.项目估算的问题：1.项目人员对软件开发盲目乐观，对费用估计过低；2.系统分析员对软硬件权衡不准确，造成软件成本增幅过大；3.项目经理对各个阶段的工作进度没有可靠的依据，难以控制开发过程。第114页/共452页3.估算的时机软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。对任何一种估算方法来说，估算的时机和精度都是一种矛盾。选择合适的时间点进行估算是估算中必须考虑的一个问题。第115页/共452页软件产品生命周期及需要进行估

38、算的五个时间点：软件产品生命周期及需要进行估算的五个时间点：E1,E2,E3,E4,E5E1,E2,E3,E4,E5第116页/共452页估算的时机客户需求：E1客户需求阶段列出客户需要的基本软件功能。时间点E1的估算可以为软件组织提供初步信息，否则需要重新考虑项目的可行性。产品定义：E2 产品定义阶段完成对项目的规格说明，进一步细化系统功能。系统设计：E3 系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明；第117页/共452页系统实现：E4设计通过审查之后，系统的实现工作就开始了。该阶段结束时，前面各项活动中消耗的资源（时间及人力等）和软件工作量均可获得，从而可对原有的估算进

39、行调整，后期需要的工作则按此估算进行计划。系统运行：E5当所有的工作都已完成并得到了验证后，系统就可以投入运行了。估算工作实际上是对估算过程的评价，即用实际的消耗与各个阶段估算值进行比较，为下一项目积累宝贵的经验。第118页/共452页3.2 软件规模1.工作分解结构传统的WBS结构第119页/共452页软件规模的估计步骤：1.在技术允许的条件下，应从最详细的WBS开始；2.精确定义度量的标准；3.估计底层每一模块的规模，汇总以得到总体估计；4.适当考虑偶然因素的影响。第120页/共452页常用的软件规模度量标准：代码行 DOC:功能点 FP:第121页/共452页代码行：代码行LOC是常用的

40、源代码程序长度的度量标准。代码行可分为：无注释的代码行（NCLOC）和注释的源代码行（CLOC）实际工作中，也常常使用KLOC（千代码行）来表示程序长度。一代码行（1LOC）价值和人月均代码行数可以体现一个软件生产组织的生产能力。第122页/共452页功能点：功能点度量是在需求分析阶段基于系统功能的一种规模估计方法，常应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点数量。第123页/共452页计算功能点数的步骤：（1）计算所需要的输入、输出、查询、外部文件、内部文件的数量。第124页/共452页计算功能点数的步骤：（2）有了以上五个功能项的数量后，再由估计人员对项目

41、的复杂性作出判断，大致分成简单、一般、复杂三种情况。然后根据下表求出功能项的加权和。功能项权 重简单一般复杂输入346输出457查询346外部文件71015内部文件5710第125页/共452页功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF）相成得到。第126页/共452页从上表计算出：TCF=0.65+0.01*(SUM(Aj)TCF的取值范围为0.651.35，分别对应着组成部分Aj都取值0和5，得到功能点FP的计算公式：FP=UFC*TCF第127页/共452页功能点度量在以下情况下特别有用：（1）估计新的软件开发项目；（2）应用软件包括很多输入输出或文件活动；（3）拥有经

42、验丰富的功能点估计专家；（4）拥有充分的数据资料，可以相当准确地将功能点转化为LOC。第128页/共452页3.3 软件项目成本估算第129页/共452页3.3.1 成本估算方法第130页/共452页一.算法模型第131页/共452页二.专家判定对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有：（1）求中值或平均值 （2）召开小组会议第132页/共452页（3）Delphi技术（4）Wideband Delphi 技术第133页/共452页三.类比第134页/共452页四.自顶向下推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。其缺点是难以识别较低级别上的技术

43、性困难。第135页/共452页五.自底向上自底向上估算是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，就得到了软件开发的总工作量。易于忽略许多与软件开发有关的系统级成本。第136页/共452页六 计划指南第一级工作分解结构元素第一级工作分解结构元素默认预算默认预算管理10%环境10%需求10%设计15%实现25%评估25%实施5%合计100%第137页/共452页默认工作量和进度在各阶段的分布项目项目初始初始细化细化构造构造移交移交工作量5%20%65%10%进度10%30%50%10%第138页/共452页七.成本和进度估计过程 自项向下的

44、方法计划序列 软件项目经理(和其他人)开发出项目所需的规模、过程、环境、人员和质量的全局描述。使用软件成本估计模型，在宏观级别上估计整体工作量和制定进度。软件项目经理使用如表1中的指南，将估计的工作量分配到第一级工作分解结构中。软件项目经理又使用表2中的指南，将进度分成主里程碑日期、并将工作量分配给各级人员。此刻，子项目经理负责将每一个工作分解结构元素划分到更低的级别，而使其满足顶层分配、人员结构和主里程碑日期的限制。第139页/共452页由底向上的方法计划序列最低级别的工作分解结构元素被细化成细节任务，相关的工作分解结构元素的管理人员根据这些任务估计预算和进度。在较高级别预算和里程碑中结合并

45、集成了估计。与自顶向下的预算和进度里程碑进行比较。评估总的区别并进行校正，以取得自顶向下和自底向上估计的协调。第140页/共452页3.4 软件项目进度管理第141页/共452页3.4.1制定项目计划一.制定项目计划的原则 项目计划在项目开始的时候制定，并随着项目的进展不断发展。考虑的重点要放在需要更多知识的地方及如何去获取这些知识。第142页/共452页二.软件项目计划的要素软件项目计划的要素包括目标、合理的概念设计、工作分解结构、规模估计、工作量估计和项目进度安排。第143页/共452页三.软件项目计划的逻辑要点需求分析：项目计划的第一步就是把模糊的需求准确化。项目的概念设计：一般要定义工

46、作分解结构。资源配置和进度安排第144页/共452页需求足够清晰时，应进行详细设计，制定实现策略并纳入计划之中。充分理解项目各部分后，确定实施细节并在下次计划更新时形成文档。在整个项目周期中，项目计划为各种资源的配置提供框架。第145页/共452页四.软件项目计划周期第146页/共452页五.项目计划的内容项目的目标工作分解结构WBS资源配置进度安排第147页/共452页一.必要性制定项目计划时，项目的交付最好采用按阶段交付的形式。软件组织最好的做法是在早期只对基本功能进行约定，其余问题的约定则推迟。软件功能按照其重要程度的顺序进行交付，最重要的功能最先交付。第148页/共452页二.分阶段交

47、付的过程第149页/共452页三.如何分阶段定义每一个阶段的主题，然后就主题和用户进行商榷，再根据主题把软件特征分配到各阶段。第150页/共452页3.4.3 进度安排第151页/共452页一.进度安排的整体过程第152页/共452页项目整体进度安排的过程如下：（1）根据项目总体进度目标，编制人员计划 （2）将各阶段所需要的资源和可以取得的资源进行比较，确定各阶段的初步进度，然后确定整个项目的初步进度。第153页/共452页（3）对初步进度计划进行评审，确保该计划满足要求，否则就要重复上面的步骤。一般都需要多次调整。第154页/共452页二.进度中的并行性第155页/共452页软件开发过程中设

48、置了若干里程碑。当一个软件任务成功地通过了评审并产生了相应文档之后，就完成了一个里程碑。软件项目的并行性提出了一系列进度要求。第156页/共452页三.进度安排的方法采用图示方法。常用的有甘特图和网络图第157页/共452页（1）甘特图 甘特图（Gantt Chart），又称横道图，是各种任务活动与日历表的对照图。第158页/共452页第159页/共452页 每一个任务的完成不以能否继续下一阶段的任务为标准，其标准是是否交付相应的文档和通过评审。第160页/共452页（2）网络图 用网络分析的方法编制的进度计划成为网络图。第161页/共452页第162页/共452页第163页/共452页第第4

49、 4章章 软件项目配置管理软件项目配置管理4.1 配置管理概念第164页/共452页4.1.1 4.1.1 基本概念基本概念软件项目配置管理就是作为变更控制机制而引入到软件项目中的相关概念（1）软件 配置管理中的软件是指由逻辑和功能特性构建的信息。（2）配置 配置由部件表和部件分解图组成。部件分解图定义了基线中包含的所有要素以及如何将它们安装在一起。第165页/共452页（3）标识 识别产品的结构、产品的构件及其类型，为其分配惟一的标识符，并以某种形式提供对它们的存取。（4）软件配置项 软件配置项SCI是为了配置管理的目的而作为一个单位来看待的软件要素的集合。第166页/共452页部件号部件描

50、述1软件项目计划2需求规格说明3设计说明4质量保证计划5测试计划6源程序代码7例行程序库8可执行代码软件部件表软件部件表1 1第167页/共452页软件部件表软件部件表2 2部件号部件描述9脚本文件10测试程序11测试报告12建造程序第168页/共452页软件部件分解图软件部件分解图第169页/共452页软件配置项软件配置项项目相关信息产品概念说明软件项目计划软件开发计划软件质量保证计划软件配置管理计划软件验证和确认计划软件需求规格说明软件设计说明源代码源代码列表可执行文件Make文件库第170页/共452页项目相关信息数据库描述图表和文件描述初始内容软件配置管理程序源代码树结构日常建造程序备