软件项目管理课程精-清华PPT课件

.,教材：软件项目管理覃征等编著,.,第1章导论,.,1.1软件工程一、软件工程定义,软件：是与一个系统，特别是一个计算机系统有关的程序、过程和有关文档的完整集合。工程：是科学和数学的应用，通过这一应用，使得自然界的物质和能源的特性通过各种结构、机器、产品、系统和过程成为对人类有用的东西。,.,软件工程的定义有多种说法:,FritzBauerNAV69在NATO会议上给出的定义:软件工程是建立和使用一套合理的工程原则，从而经济地获得可靠的和能在实际机器上高效运行的软件。,.,IEEEIEEE93给出了一个更加综合的定义：（）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。（）（）中所述方法的研究。,.,本书给出的定义:软件工程是一类求解软件的工程。它应用计算机科学、数学以及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高软件质量、降低成本、按时按量交付的目的。,.,计算机科学、数学用于构造模型和算法。工程科学用于制定规范、设计模式、评估成本及确定权衡。管理科学用于计划、资源、质量、成本等管理。,.,二软件工程框架,软件工程目标软件工程活动软件工程原则,.,软件工程框架,.,软件工程目标,正确性软件产品达到预期功能的程度。可用性软件基本结构、实现、文档为用户可用的程度。合算性具有经济效益，即开发、运行的开销满足用户要求的程度。,.,软件工程活动-生产软件步骤,问题定义明确要解决的问题可行性分析即定义的问题是否有解决的办法需求分析为解决问题，目标系统必须具备哪些功能设计总体设计，详细设计实现编写程序代码确认测试支持软件维护,.,软件工程原则,选取适宜的开发模型采用合适的设计方法提供高质量的工程支持重视开发过程的管理,.,三软件工程模型,所有软件工程的活动都必须进行管理。软件项目管理贯穿于软件工程的演化过程。软件工程的演化过程：,.,三软件工程模型,软件工程模型:组织软件工程活动的方法，称为软件工程模型。软件工程模型是用一定的流程将各个活动连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见模型有线性、快速原型、螺旋、渐增式等模型。,.,常见的软件工程模型,线性模型（也称，瀑布模型，顺序模型）,.,常用的软件工程模型,螺旋模型可看成是连接的线性模型,.,常用的软件工程模型,渐增式模型（增量模型）,.,常用的软件工程模型,渐增式模型首先构建系统的基本轮询回路：,.,1.2项目管理一项目与项目管理,项目的概念及特点项目：是指在一定约束条件下具有特定目标的一项一次性任务共同特点：一次性，又称为单件性目标的明确性：成果性目标（功能性要求），约束性目标作为管理对象的整体性,.,2、项目的生命周期,.,项目的生命周期项目启动阶段进行可行性分析，若接受项目进行需求确认，项目立项项目计划阶段建立解决问题方案，向客户提交各种计划书项目实施阶段执行解决方案，实现项目的目标工作结束阶段正式验收项目,.,另一书中对项目周期阶段的划分,生命周期阶段工程阶段初始阶段细化阶段生产阶段构造阶段移交阶段,.,各阶段特点,工程阶段：使计划、需求和构架同时进化，并解决开发风险，这个阶段以一个可执行构架基线结束，即工程阶段进行设计和综合活动。生产阶段：进行构造、测试和实施活动。,.,各阶段特点,借助提高功能的演示使系统能力得以进化。各种活动同时进化，每个阶段都包括一次或多次迭代，一次迭代表示一个活动序列，这些活动有明确的中间事件（里程碑）。,.,各阶段特点,主里程碑：使用正式版本的评价标准和发布说明书，一个阶段结束产生一个主里程碑。次里程碑：使用非正式版本，一次迭代结束产生一个次里程碑。,.,各阶段特点,为实现整个项目的某个特定状态，每个阶段都要进行足够次数迭代。各阶段的工作产品（制品，文档等），同时进化产生，但每个阶段都有一个主要焦点：初始阶段需求（生命周期目标里程碑）细化阶段设计（生命周期构架里程碑）构造阶段实现（初始的可操作能力里程碑）移交阶段实施（产品发布里程碑）（这里的模型是渐增式（增量式）,.,项目管理,项目管理定义PMI（ProjectManagementInstitute）定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。项目管理又可定义为：在一个确定的时间范围内，为了完成一个既定的目标，通过特殊形式的临时性组织运行机制，经有效的计划、组织、领导和控制，充分利用既定有限资源的一种系统管理方法。,.,项目管理特点综合性创造性时间性,.,项目管理的要素,范围、时间、成本、质量、组织、客户满意度,.,二项目管理知识体系,集成管理范围管理时间管理成本管理质量管理人力资源管理沟通管理采购管理风险管理,.,三项目管理学科的发展,项目管理学科发展的特点全球化发展、多元化发展、专业化发展项目管理学科在双向探索中前进各学科领域的理论、方法应用于项目管理，项目管理的理论、方法应用于各学科领域项目学发展的趋势微观项目管理，即单一项目的管理PMBOK是当前项目管理学科发展的重要内容项目学是知识创新与市场相结合的综合化发展项目学是科学、技术和艺术的综合,.,软件项目管理一软件项目产品的特点,抽象性缺陷检测的困难性高度的复杂性缺乏统一规则,.,二软件项目失控的原因,软件失控项目(p15-16)是指软件项目在进行时遇到困难，导致大大超出可控制范围的项目。软件项目失控的原因七方面原因：需求不明确、计划不充分和过于乐观的估计、采用新技术、管理方法缺乏或不恰当、性能问题、团队组织不当、人际因素,.,三软件项目管理的内容,软件项目管理的定义(p19)软件项目管理的过程(p19)软件项目管理的内容(p19-20),.,软件项目管理的定义,PMI对项目管理定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。软件项目管理的定义：在软件项目活动中运用一系列的知识、技能、工具和技术，以满足软件需求方的整体要求。,.,软件项目管理的过程,启动软件项目制定项目计划跟踪及控制项目计划评审项目计划编写管理文档,.,软件项目管理的内容,软件项目需求管理软件项目估算与进度管理软件项目配置管理软件项目风险管理软件项目质量管理软件项目资源管理,.,第章软件项目需求管理,.,软件需求一.软件需求概念1.定义,简单地说，软件需求就是确定系统需要做什么严格意义上，软件需求是系统或软件必须达到的目标与能力,.,定义软件需求的五项内容,系统的输入系统的输出系统的功能系统的属性系统环境的属性,.,2.软件需求在软件项目的作用,软件需求与其他软件过程的关系,.,软件需求类别1.软件需求的抽象层次,软件需求分成四个抽象层次原始问题描述用户需求系统需求软件设计描述,.,软件需求的抽象层次,.,原始问题描述是对要解决问题的叙述用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束系统需求用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述,.,原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现通常情况下，经常提到的是用户需求和系统需求,.,2.用户需求,用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述,.,使用自然语言可能出现如下问题,描述困难需求混乱因此写需求文档应遵守一些简单原则：标准的格式使用一致的语言使用特殊文本尽量避免专业术语,.,3.系统需求,系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点系统需求描述通常采用结构化语言和过程设计语言PDL.,.,系统需求的描述语言,.,4系统需求的分类,分为三类：功能需求非功能需求领域需求,.,(1)功能需求功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述系统的功能需求应该具备全面性和一致性要做到全面和一致几乎是不可能的原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档,.,(2)非功能需求非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等,.,按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程,.,表2.2非功能需求的类别,.,(3)领域需求领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识,.,三软件需求文档,软件需求文档是对软件系统要求的陈述包括：用户需求系统需求,.,三软件需求文档1.需求文档的编制与作用,编写需求文档时，以下几点是应该注意的：语句和段落尽量简短表达时采用主动语态语句要完整，且语法，标点等正确无误使用的术语要与词汇表中的定义保持一致陈述时要采用一致的样式避免模糊的，主观的术语，如性能优越避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证,.,需求文档的作用,使用对象需求文档的作用软件项目客户了解软件项目能够提供的软件产品，检查软件需求是否满足需要项目管理人员根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员理解要开发的产品及具体要开发的内容软件测试人员验证软件系统是否满足了预期的要求软件维护人员使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员在需求文档的基础上编写用户文档，如用户手册软件培训人员在需求文档的基础上编写培训材料,.,软件需求规格说明,(1)基本含义规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档,.,软件项目管理者用SRS来对项目进行计划和管理。除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。SRS的基本内容包括功能需求和非功能需求。功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。,.,(2)IEEE标准830-1998见:P27P28,.,(3)SRS大纲见:P28-P29,.,四.软件需求度量,一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节.软件需求质量度量的九个元素,即正确,无歧义,完备,一致,分级,可验证,可修改,可跟踪及可理解,.,22需求工程,.,一、产生与发展1、产生人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。需求规格说明又是软件设计、实现、测试直至维护的主要基础。,.,2.发展需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合发展。（）对象化需求工程的对象化主要是指需求模型及其构造方法的对象化，面向对象需求模型及需求定义语言是其研究的关键。,.,（）形式化需求规格描述方法有三种:形式化方法、非形式化方法和半形式化方法。形式化方法是具有严格数学基础的描述系统特征的方法，具有准确、无二义性的特点，有助于验证有效性和完整性。非形式化方法使用未作任何限制的自然语言，易于理解和使用，但它固有二义性，且难以保证正确性、可维护性，难以用计算机系统提供自动化的支持。半形式化方法介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些局部方面则允许使用非形式化的自然语言。,.,(3)自动化在自动化的层次方面，已从实现级、设计级发展到功能级，并逐渐渗透到需求级。,.,二.研究内容,、需求工程的目标需求工程有两个主要任务：其一是通过对问题及其环境的理解、分析和综合，建立分析模型;其二是在完全弄清用户对软件系统的确切要求的基础上，用SRS把用户的需求表达出来。,.,（）建立需求分析模型分析模型是描述软件需求的一组模型。需求分析模型包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，是形成需求说明、进行软件设计及实现的基础。（）编写SRSSRS的编写要以需求分析模型为基础、按照软件组织定义的SRS大纲、采用某种需求描述语言来进行。,.,、需求工程的层次分解,需求工程可分为需求开发和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。,.,需求开发和需求管理是有界限的：,.,需求管理,.,一.需求管理的必要性,、需求供求双方固有的矛盾需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。、需求具有易变性和难以表述性软件项目中的问题都是在需求分析阶段埋下的祸根。软件需求还很难以表述。正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。,.,、需求错误出现的高频性和修复的高昂成本需求错误是软件项目开发中最常见的。,表2.4软件缺陷总结缺陷来源潜在缺陷剩余缺陷排除效率（%）需求0.20.04677设计0.250.037585编码0.350.017595建档0.120.02480修复0.080.02470合计10.14985.1,.,一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的倍。对于软件缺陷，修复的发现和修复的越早，则成本越低。做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。,.,软件缺陷修复的成本,.,二.目标和原则,、目标(p35-36)需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。具体来说,需求管理的目标有二个:(1)使软件需求受控,并建立供软件工程和管理使用的需求基线。(2)使软件计划、产品和活动与软件需求保持一致。,.,、原则为进行有效的需求管理，通常要遵循如下五条原则：（）需求一定要分类管理（）需求必须分优先级（）需求必须文档化（）需求一旦变化，就必须对需求变更的影响进行评估（）需求管理必须与需求工程的其他活动紧密整合,.,三.需求管理活动,需求管理规划内容包括：需求识别变更管理过程需求跟踪自动化工具,.,需求管理是一个对系统需求变更了解和控制的过程。需求管理的过程是与其他需求工程过程相互关联的。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。,.,需求管理活动的具体内容如表所示,.,2.3.4需求变更管理,1、需求变更的原因软件项目的需求总是在变化着,一般原因有二:(1)在项目的早期所有的问题不可能被完全定义,软件需求是不完全的,注定了需求需要变更。(2)随着软件项目的进行,软件开发人员对问题的理解会发生变化,这些变化也要反馈到需求中去。,.,大型软件系统还可能存在如下导致需求变更的原因:(1)不同类型的用户的需求可能是冲突的或是矛盾的,最后的系统需求是它们之间的一个妥协.这种妥协的程度在项目进行过程中有可能发生改变,从而导致系统需求的改变。(2)系统购买者或系统最终用户很少是同一人,有的系统客户对系统提出的一些需求可能和最终用户需求不一致。,.,2、变更管理过程变更管理过程分为变更描述、变更分析和变更实现三个阶段。,.,(1)变更描述变更描述阶段要对需求问题或变更提议进行分析以检查它的有效性，进而产生一个更明确的需求变更提议。(2)变更分析变更分析阶段对被提议的变更产生的影响进行评估。一旦分析完成，就有了对此变更是否执行的决策意见。,.,(3)变更实现实现变更时，需求文档及系统设计和实现都要做修改。一个容易出现的错误，一定要注意：先对系统做变更然后再回头修改需求文档的想法，这几乎不可避免地导致需求描述和系统实现不同步。需求文档应该有一个很好的形式，使得变更不会带来大量文字的修改。对于程序文档的可变性则通过最小化外部引用和尽量使之模块化来实现。,.,3、变更影响分析进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其他需求的影响,同时明确与变更相关的任务并评估完成这些任务需要的工作量。变更影响分析有助于做出信息量充分的变更决策,确定对变更是修改还是抛弃,或者创建新系统以及评估每个任务的工作量.,.,如果一个处于关键路径的任务因变更而延期,则项目肯定赶不上预定进度,但如果能避免变更影响关键任务,则变更不会影响项目的进度表影响分析报告的模板,用来报告进行需求变更的影响分析,变更控制委员会仅需要影响分析的总结.,.,需求变更影响分析模板,.,4、变更控制流程需求变更控制的流程如图所示,.,2.3.5需求文档版本,如果没有很好的需求文档版本管理,就容易造成资源浪费.需求文档版本控制是需求管理的一个必要方面.,.,做好需求文档版本控制,必须保证如下几点:统一确定需求文档的每一个版本,保证每个成员都能得到当前的需求版本;清楚地将变更写成文档,并及时通知项目开发所涉及的人员;为尽量减少困惑、冲突、误传，应只允许指定的人来更新需求文档。,.,版本控制的最简单方法是在每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已作变更的内容、变更日期、变更人的姓名以及变更的原因，并根据标准约定手工标记软件需求规格说明的每一次修改。,.,2.3.6需求状态,1、需求的属性需求还有一些相关的属性,这些属性的定义及更新是需求管理的重要内容.需求的属性为需求提供了背景资料和上下文关系。,.,需求要考虑的属性如下,(1)需求的创建时间(2)需求的版本(3)需求的创建者(4)需求的批准者(5)需求的状态(6)需求的原因或根据(7)需求涉及的子系统(8)需求涉及的产品版本(9)需求的验证方法或测试标准(10)需求的优先级(11)需求的稳定性,.,需求的优先级,即从实现需求所涉及的代价、收益、成本、风险四个方面考察需求的优先级需求的稳定性，表示将来需求可能变更的程度，稳定性越差，意味着需求越容易发生变更，因而应给予较多的关注。,.,2、需求状态需求状态是需求的一项重要属性,跟踪需求的状态是需求管理的一个重要方面。何谓需求状态?状态是一种事物或实体在某一个时间点或某一阶段的情况的反映。需求状态是指某时间点需求的一种情况反映。,.,客户的需求可分为四种情况:客户可以明确且清楚地提出的需求.客户知道需要做些什么,但却不能确定的需求.需求可以由客户得出,但需求的业务不明确,还需要等待外部信息.客户本身也说不清楚的需求.,.,需要与客户沟通或确认的需求有两种情况:其一是确认双方达成共识其二是还需要再进一步的沟通可把需求状态分为如下8种已建议已批准已拒绝已设计已实现已验证已交付已删除,.,2.3.7需求跟踪,1、需求跟踪的必要性进行需求跟踪的目的是建立和维护从用户需求开始到测试之间的一致性与完整性,确保所有的实现都以用户需求为基础,而实现的需求也全部覆盖了预期的需求,同时确保所有的输出与用户需求的符合性.跟踪能力信息使得变更影响分析十分便利,有利于确认和评估实现某个建议的需求变更所必须的工作.,.,2、可追溯性信息进行需求跟踪,就要对需求和需求之间以及需求和系统设计之间的许多关系进行追溯。当需求变更发生的时候,必须追踪这些变题对其他需求和系统设计的影响。可追溯性是需求描述的一个总体特性,反映了反映相关需求的能力。,.,需要维护的可追溯性信息有三类:(1)源可追溯性信息,指连接需求到提出需求的项目相关人员和产生需求的原因.(2)需求可追溯性信息,指连接需求文档中彼此依赖的需求.(3)设计可追溯性信息,指连接需求到其实现的设计模块.,.,3、需求跟踪的实现需求跟踪有两种方式,正向跟踪和逆向跟踪：(1)正向跟踪以用户需求为切入点,检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。(2)逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。,.,需求跟踪的双向模式可以通过需求链来表示,.,过程元素之间的关系有如下三种一对一，如一个代码模块应用一个设计元素。一对多，如多个测试实例验证一个功能需求。多对多，如一个测试实例导致多个功能性需求，而其中一些功能性需求又拥有多个使用实例。,.,需求跟踪矩阵,.,4、需求跟踪的作用,在需求验证中的作用有助于需求变更影响分析便于需求的维护便于测试时找出问题所在便于项目跟踪减小项目的风险简化了系统的再设计易于软件重用,.,2.4需求管理质量保证,.,2.4.1需求验证,1.需求验证过程审查需求文档依据需求编写测试用例编写用户手册确定合格的标准,.,2.验证的内容在需求验证过程中,要对需求文档中定义的需求执行多种类型的检查：有效性检查一致性检查完备性检查现实性检查可检验性检查可跟踪性检查可调节性检查可读性检查,.,2.4.2需求评审,1.方式评审有两类方式:一类是正式技术评审,另一类是非正式技术评审。2.注意事项严格控制每一次评审的文档规模及持续时间评审工作要分段进行对讨论的问题进行控制避免无谓的争吵,.,第3章软件项目估算与进度管理,主要内容：3.1软件项目估算3.2软件规模3.3软件项目成本估算3.4软件项目进度管理,.,3.1软件项目估算,1.项目估算的意义：包括工作量估算和成本估算两个方面。估算是指通过预测构造软件项目所需要的工作量的过程，初步的估算用于确定软件项目的可行性，详细的估算用于指导项目计划的制定。进度计划是从时间的角度对项目进行规划，而成本估算则是从费用的角度对项目进行规划。,.,2.项目估算的问题：,1.项目人员对软件开发盲目乐观，对费用估计过低；2.系统分析员对软硬件权衡不准确，造成软件成本增幅过大；3.项目经理对各个阶段的工作进度没有可靠的依据，难以控制开发过程。,.,3.估算的时机,软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。对任何一种估算方法来说，估算的时机和精度都是一种矛盾。选择合适的时间点进行估算是估算中必须考虑的一个问题。,.,软件产品生命周期及需要进行估算的五个时间点：E1,E2,E3,E4,E5,.,估算的时机,客户需求：E1客户需求阶段列出客户需要的基本软件功能。时间点E1的估算可以为软件组织提供初步信息，否则需要重新考虑项目的可行性。产品定义：E2产品定义阶段完成对项目的规格说明，进一步细化系统功能。系统设计：E3系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明；,.,系统实现：E4设计通过审查之后，系统的实现工作就开始了。该阶段结束时，前面各项活动中消耗的资源（时间及人力等）和软件工作量均可获得，从而可对原有的估算进行调整，后期需要的工作则按此估算进行计划。系统运行：E5当所有的工作都已完成并得到了验证后，系统就可以投入运行了。估算工作实际上是对估算过程的评价，即用实际的消耗与各个阶段估算值进行比较，为下一项目积累宝贵的经验。,.,3.2软件规模,1.工作分解结构传统的WBS结构,.,软件规模的估计步骤：,1.在技术允许的条件下，应从最详细的WBS开始；2.精确定义度量的标准；3.估计底层每一模块的规模，汇总以得到总体估计；4.适当考虑偶然因素的影响。,.,常用的软件规模度量标准：代码行DOC:功能点FP:,.,代码行：代码行LOC是常用的源代码程序长度的度量标准。代码行可分为：无注释的代码行（NCLOC）和注释的源代码行（CLOC）实际工作中，也常常使用KLOC（千代码行）来表示程序长度。一代码行（1LOC）价值和人月均代码行数可以体现一个软件生产组织的生产能力。,.,功能点：功能点度量是在需求分析阶段基于系统功能的一种规模估计方法，常应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点数量。,.,计算功能点数的步骤：（1）计算所需要的输入、输出、查询、外部文件、内部文件的数量。,.,计算功能点数的步骤：,（2）有了以上五个功能项的数量后，再由估计人员对项目的复杂性作出判断，大致分成简单、一般、复杂三种情况。然后根据下表求出功能项的加权和。,.,功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF）相成得到。,.,从上表计算出：TCF=0.65+0.01*(SUM(Aj)TCF的取值范围为0.651.35，分别对应着组成部分Aj都取值0和5，得到功能点FP的计算公式：FP=UFC*TCF,.,功能点度量在以下情况下特别有用：（1）估计新的软件开发项目；（2）应用软件包括很多输入输出或文件活动；（3）拥有经验丰富的功能点估计专家；（4）拥有充分的数据资料，可以相当准确地将功能点转化为LOC。,.,3.3软件项目成本估算,.,3.3.1成本估算方法,.,一.算法模型,.,二.专家判定,对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有：（1）求中值或平均值（2）召开小组会议,.,（3）Delphi技术（4）WidebandDelphi技术,.,三.类比,.,四.自顶向下,推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。其缺点是难以识别较低级别上的技术性困难。,.,五.自底向上,自底向上估算是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，就得到了软件开发的总工作量。易于忽略许多与软件开发有关的系统级成本。,.,六计划指南,.,默认工作量和进度在各阶段的分布,.,七.成本和进度估计过程,自项向下的方法计划序列软件项目经理(和其他人)开发出项目所需的规模、过程、环境、人员和质量的全局描述。使用软件成本估计模型，在宏观级别上估计整体工作量和制定进度。软件项目经理使用如表1中的指南，将估计的工作量分配到第一级工作分解结构中。软件项目经理又使用表2中的指南，将进度分成主里程碑日期、并将工作量分配给各级人员。此刻，子项目经理负责将每一个工作分解结构元素划分到更低的级别，而使其满足顶层分配、人员结构和主里程碑日期的限制。,.,由底向上的方法计划序列最低级别的工作分解结构元素被细化成细节任务，相关的工作分解结构元素的管理人员根据这些任务估计预算和进度。在较高级别预算和里程碑中结合并集成了估计。与自顶向下的预算和进度里程碑进行比较。评估总的区别并进行校正，以取得自顶向下和自底向上估计的协调。,.,3.4软件项目进度管理,.,3.4.1制定项目计划一.制定项目计划的原则,项目计划在项目开始的时候制定，并随着项目的进展不断发展。考虑的重点要放在需要更多知识的地方及如何去获取这些知识。,.,二.软件项目计划的要素,软件项目计划的要素包括目标、合理的概念设计、工作分解结构、规模估计、工作量估计和项目进度安排。,.,三.软件项目计划的逻辑要点,需求分析：项目计划的第一步就是把模糊的需求准确化。项目的概念设计：一般要定义工作分解结构。资源配置和进度安排,.,需求足够清晰时，应进行详细设计，制定实现策略并纳入计划之中。充分理解项目各部分后，确定实施细节并在下次计划更新时形成文档。在整个项目周期中，项目计划为各种资源的配置提供框架。,.,四.软件项目计划周期,.,五.项目计划的内容,项目的目标工作分解结构WBS资源配置进度安排,.,一.必要性,制定项目计划时，项目的交付最好采用按阶段交付的形式。软件组织最好的做法是在早期只对基本功能进行约定，其余问题的约定则推迟。软件功能按照其重要程度的顺序进行交付，最重要的功能最先交付。,.,二.分阶段交付的过程,.,三.如何分阶段,定义每一个阶段的主题，然后就主题和用户进行商榷，再根据主题把软件特征分配到各阶段。,.,3.4.3进度安排,.,一.进度安排的整体过程,.,项目整体进度安排的过程如下：（1）根据项目总体进度目标，编制人员计划（2）将各阶段所需要的资源和可以取得的资源进行比较，确定各阶段的初步进度，然后确定整个项目的初步进度。,.,（3）对初步进度计划进行评审，确保该计划满足要求，否则就要重复上面的步骤。一般都需要多次调整。,.,二.进度中的并行性,.,软件开发过程中设置了若干里程碑。当一个软件任务成功地通过了评审并产生了相应文档之后，就完成了一个里程碑。软件项目的并行性提出了一系列进度要求。,.,三.进度安排的方法,采用图示方法。常用的有甘特图和网络图,.,（1）甘特图甘特图（GanttChart），又称横道图，是各种任务活动与日历表的对照图。,.,.,每一个任务的完成不以能否继续下一阶段的任务为标准，其标准是是否交付相应的文档和通过评审。,.,（2）网络图用网络分析的方法编制的进度计划成为网络图。,.,.,.,第4章软件项目配置管理,4.1配置管理概念,.,4.1.1基本概念软件项目配置管理就是作为变更控制机制而引入到软件项目中的,相关概念（1）软件配置管理中的软件是指由逻辑和功能特性构建的信息。（2）配置配置由部件表和部件分解图组成。部件分解图定义了基线中包含的所有要素以及如何将它们安装在一起。,.,（3）标识识别产品的结构、产品的构件及其类型，为其分配惟一的标识符，并以某种形式提供对它们的存取。（4）软件配置项软件配置项SCI是为了配置管理的目的而作为一个单位来看待的软件要素的集合。,.,软件部件表1,.,软件部件表2,.,软件部件分解图,.,软件配置项,.,.,（5）版本版本是一个基线或一个软件配置项的特例。（6）基线基线是开发过程的里程碑，以一个或多个软件配置项的交付为标准；基线由通过正式评审的软件配置项组成，是进一步开发的基础；基线只有通过正式的变更控制过程才能改变。,.,（7）控制通过建立产品基线，控制软件产品的发布和整个软件生命周期中对软件产品的修改。（8）状态统计记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。,.,（9）审核确认产品的完整性并维护构件间的一致性，即确保是一个严格定义的构件集合。（10）生产对产品的生产进行优化管理。（11）过程管理确保软件组织的规程、方针和软件周期得以正确贯彻执行。,.,（12）小组协作控制开发统一产品的多个开发人员之间的协作。（13）配置控制委员会配置控制委员会CCB负责评审和批准对基线的变更，通常由项目选出的代表组成。,.,4.1.2软件配置管理,1.定义软件配置管理是软件项目运作的一个支撑平台。这种支撑是贯穿项目的整个生命周期的。,.,SCM作为支撑平台,.,配置管理CM是在系统生命周期中对系统中的配置项进行标识和定义的过程。该过程是通过控制配置项的发布及后续变更、记录并报告配置项的状态及变更请求、确保配置项的完整性和正确性来实现的。,.,软件配置管理SCM是应用于由软件组成的系统的配置管理，通过一套工程规范，在整个软件生命周期中跟踪、记录软件，保证全部变更都记录在案，并保证软件的当前状态是已知的和可重复的。,.,2.软件配置管理过程根据IEEE定义,软件配置管理过程分为四步。（1）计划配置管理确定SCM组织和责任，明确CM的过程、工具、技术及方法论，知道何时及如何进行。,.,（2）开发CM方案定义了一个配置标识方案CIS对软件产品进行跟踪，包括建立各个阶段的CM基线、进行配置标识。CIS贯穿于整个软件生存周期中。（3）配置控制建立软件配置控制委员会，对基线的变更只有得到CCB的同意才能进行；对变更进行跟踪，确保任何时候软件配置都是已知的；在软件生存周期的整个过程中都要清楚基线状态的变更历史，以便于下一步的状态审计。,.,（4）状态审计对状态进行报告，明确到目前为止改变的次数及最新版本等。,.,软件配置管理过程,.,4.2配置管理组织和职责4.2.1CMM二级体系,软件能力成熟度模型SCMM分为5个级别:初始级、可重复级、已定义级、已管理级和优化级。每个成熟度级别都包含若干个关键过程域KPA。,.,可重复级（二级）CMM包含6个：软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪和监督、软件项目策划及需求管理。软件配置管理作为二级CMM的一个KPA，是保证软件项目生成的产品在软件生存周期中完整性的重要手段。,.,实施CMM二级体系的组织结构图,.,从组织结构图中可以看出，SCM在整个体系中的位置及其与其他部分的关系。图中各组成部分的说明见P96。,.,4.2.2SCM的职责,软件配置管理的基本职责有配置经理、模块主管、变更控制委员会。1、配置经理配置经理的基本职责是对代码开发和测试进行支持和保护，是变更管理的控制中心。,.,配置经理具有如下职能：制定SCM规程，形成文档并分发给有关人员建立系统基线，包括备份规定确保对基线的变更都经过授权人员的批准确保对基线的所有变更都进行充分细致的记录，以便可以重新生成或回退确保所有基线变更都经过回归测试规定解决异常问题的关注焦点,.,2、模块主管每一个模块配备一个主管的开发人员作为模块主管，其主要职责是：把握模块的设计为参与模块及其接口工作的人员提供建议控制模块的所有更改评审模块的变更和定期进行回归测试，确保模块的完整性,.,3、变更控制委员会CCB软件变更控制委员会SCCB是大中型软件项目中协调变更的集中控制机制，是对每个变更进行评审，做出相关决策的实体。SCCB是一个常设组织，项目经理指定SCCB的主席，SCM经理一般担任SCCB的秘书，SCCB成员般由各个功能组的技术或管理代表组成，包括从事开发、文档编写、测试、维护、发布等方面的人员。,.,4.2.3SCM文件体系与过程活动,1、SCM文件体系文件体系是实施SCM的依据，它将标准的SCM要求映射为项目实施SCM所需的方针、程序和作业规范等文件,.,文件体系的构架,.,（1）方针在金字塔顶层的方针文件中，描述了SCM的目标、方法、途径和方针的责任人。本文件一般由SCM经理编制、项目经理审核、规划经理批准。（2）过程定义过程定义是图中第二层次的文件，支撑了顶层方针，是整个文件体系的核心，它将SCM所有共同特性的关键实践予以文件化和制度化。过程定义文件一般包括：范围、目的、引用标准、术语和定义、过程活动描述等几个方面，可以按照下面的八项指标描述过程活动。,.,目的：SCM过程活动的目的。角色及职责：完成一个过程活动的个人或小组的职责。入口准则：触发一个过程活动的必要的条件。控制：约束或调节一个过程活动。输入：一个过程活动执行的数据。过程活动：采取行动把输入转变成预定的输出。输出：一个过程活动产生或导出的数据。出口准则：结束一个过程活动的必要条件。,.,一般由SCM经理组织人员编制过程定义文件，然后由项目经理审核、规划经理批准。,.,（3）规程或模板规程或模板是第三层次的文件，支撑了上两个层次的文件，为具体执行活动提供作业规范或模板。规程或模板一般包含记录格式的表单，记录是开展SCM活动的有效工具。规程或模板文件一般由从事这项具体工作的工作人员编制，由SCM经理审核，由项目经理批准。编制SCM文件体系，需要将开展过程活动的各种SCM要素包含进去，包含组织结构、资源、工具等。,.,2、SCM过程活动SCM过程包括管理SCM和执行SCM两项活动。SCM过程活动如图所示：,.,.,4.3配置管理功能,软件配置管理是涉及组织和管理各种软件产品及文档、控制其变化的一系列活动，贯穿整个软件生命周期。软件配置管理有四个主要功能：配置标识、配置控制、配置状态报告及配置审核。,.,4.3.1配置标识,配置标识惟一的标识软件配置项1、要注意的问题配置标识功能论述了与基线中包含的软件配置项的标识以及基线本身的标识有关的问题。“标识”用来确定如何识别产品的所有部件和由部件建造的产品基线。要考虑的关键点见P100,.,2、配置标识框架配置标识的框架如下所示：ITEMISBELONGTOPROVIDESROPERTIESREQUIRESVERSION_LINKCONTENTPONITER指向初版内容END,.,(1)配置项名称配置项名称是一字符串,为该配置项命名。（2）文档类别名文档类别名指配置项属于哪一工程、哪类文档。,.,（3）资源资源指配置项向外供应什么、向外要求什么，实际上就是表达与其他配置项的关系、变化/版本信息。（4）供应资源特性供应资源特性采用非过程化的、独立于完成语言的方式说明数据的类型、功能、接口形式及其他一些限定特征。,.,（5）版本链版本链指版本的演化过程。（6）指针指针是一个指示符，用于版本溯源。根据指针，可以找到当前版本的初始源头。,.,4.2.3配置控制,配置控制是在软件生存周期中控制软件产品的变更和发布,其目标是建立有助于确保软件质量的机制。,.,1、版本控制在软件产品中开发中以及产品发布以后可靠地建立和重新创建版本是软件配置管理的一个必备功能。当软件项目的参加人员多于是2个人时，他们的工作就存在潜在的冲突，表现见P101P102为了支持并行开发，软件配置管理必须具有支持分支、文件比较和合并的功能，版本控制提供了这种功能机制。,.,分支是使软件配置项同时沿着两个或多个分支展开，新版本独立地添加到各自的分支中。文件比较用来比较两个或多个分支（或基线）中具有相同名字的文件，并识别不同的文件。合并是有选择地将分支中对源文件所做的修改与主分支中相应的源文件对应起来或者同一分支的两次修改对应起来的过程，分为水平合并和垂直合并两种形式。,.,分支、文件比较与合并,.,2、变更管理（1）模块变更管理对于同一软件模块，有时候有不同功能需求问题。此时模块大部分代码相同，只是为实现不同功能，代码有局部差异。通常的做法是作为模块的变更管理。模块变更管理分为差异代码管理和条件代码管理。,.,（1）差异代码管理差异代码管理把基本的代码部分和差异代码分开。对基本代码进行维护时，只要不涉及与差异代码的接口，补充简要的防止误用说明后就可以直接进行变更。同样，也可以单独对差异代码进行维护，但不能涉及到基本代码部分。,.,差异代码管理的缺点是：为使差异代码能方便的产生，基本代码部分可能很复杂；基本代码与差异代码组成的变更链中，一旦某个元素丢失或损坏，则重建整个链条将非常困难；由于部分模块的生命周期很长，相关的差异代码要维持很长时间，因而差异代码可能会逐渐变大。,.,实用的解决方案是，是对临时性变更采用差异代码管理，而对于与大量代码无关的永久变更，可以通过将模块分成两个或多个部分来代理，公共元素作为一个支持所有使用的相同模块，每个变更都通过增加独立模块来实现,.,条件代码管理条件代码管理面对的问题是从几种可供选择的模块中选择一种，以实现特定功能。此时所有情况下的模块都在模块库中，但每次只使用一个。使用条件代码时，只有一个模块，差异表现在条件代码中。,.,（2）基线管理基线是软件开发过程中的特定点，其作用是使软件项目各个阶段的划分更加明确，使本来连续的工作在这些点上断开，以便于检查和肯定阶段成果。基线由软件配置项组成，是软件配置管理的基础。随着软件配置项的建立，产生了一系列基线。对这些基线必须进行管理和控制。,.,.,在初始基线建立、下一个基线产生之前，所有变更都必须记录下来并文档化。基线建立的时间要视具体情况而定，只要各个开发模块相对独立，相互关联不多，就不需要基线。但一旦项目各模块联系较多，开始集成，就必须建立基线，进行正式的控制。,.,基线管理应具有两个基本功能。对基线进行适当控制，禁止任何未经批准的变更。确定新基线前，必须用新基线的试行版本对每个建议的变更进行测试，通常还需要一个综合的回归测试规程。基线管理的第二个功能是为程序员提供灵活的服务，确保他们能够比较容易地对自己的代码进行修改和测试。准备将工作结果并入基线并形成新的基线时，必须确保新的变更和其他部分兼容，确保新代码不会导致回归现象，即没有丢失以前的功能。,.,基线管理过程,.,概括起来，对基线变更控制机制的需求如下：对基线提出的变更必须经过一定层次的评审。必须确定和理解提出的变更对经费、进度、软件开发和生产造成的影响。变更必须获得相关组织的批准。必须正确实施被批准的变更。一旦变更被批准，必须通知所有受影响的部门。,.,4.3.3配置状态报告,配置状态报告的目的是提供软件开发过程的历史记录。内容包括软件配置项当前的状态及何时因何故发生了变更，使相关人员了解配置状态报告。配置状态报告主要描配置项的状态、变更的执行者、变更时间和对其他工作有何影响。,.,配置状态报告的结果存入数据库中，可以查询变更信息并对为更进行评估。在配置状态报告中，必要的文档记录是不可缺少的。其中配置项状态报告、变更请求、变更日志、变更测试是重要的几种记录文档。表4.3、表4.4、表4.5、表4.6分别给出了这些文档的样例。见P105106,.,4.3.4配置审核,1、配置审核概念配置审核根据需求标准或合同协议检验软件产品配置，验证每个软件配置项的正确性、一致性、完备性、有效性、可追踪性，以判定系统是否满足需求。,.,确定变更是否正确有正式技术审核和软件配置审核两种措施。正式技术审核在软件交付用户前实施。正式技术审核关注已变更的配置对象的技术正确性、审核者评估软件配置项的一致性、遗漏及潜在的副作用。软件配置审核关注的是正式技术审核中未考虑的因素，作为技术审核的补充措施，确保软件变更被正确地实施。软件配置审核关注的因素见P106,.,2、配置审核内容配置审核包括两方面的内容，即配置管理活动审核与基线审核。配置管理活动审核用于确保项目组成员的所有配置管理活动都遵循已批准的软件配置管理方针和规程。实施基线审核，则要保证基线化软件工作产品的完整性和一致性，且满足其功能要求。,.,基线的完整性可从以下几方面考虑：基线库是否包括所有计划纳入的配置项？基线库中配置项自身的内容是否完整？如文档中所提到的参考或引用是否存在？对于代码，要根据代码清单检查是否所有源文件都已存在于基线库，还要编译所有的源文件，检查是否可产生最终产品。一致性主要考察需求与设计以及设计与代码的一致关系，尤其在有变更发生时，要检查所有受影响的部分是否都做了相应的变