软件项目管理课程完整-清华ppt课件.ppt

单击此处编辑母版标题样式,.,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,.,*,教材：,软件项目管理,覃征 等 编著,软件项目管理,软件项目管理,.,第,1,章 导 论,.,1.1,软件工程一、软件工程定义,软件：是与一个系统，特别是一个计算机系统有关的程序、过程和有关文档的完整集合。,工程：是科学和数学的应用，通过这一应用，使得自然界的物质和能源的特性通过各种结构、机器、产品、系统和过程成为对人类有用的东西。,.,软件工程的定义有多种说法,:,Fritz BauerNAV69,在,NATO,会议上给出的定义,:,软件工程是建立和使用一套合理的工程原则，从而经济地获得可靠的和能在实际机器上高效运行的软件。,.,IEEEIEEE93,给出了一个更加综合的定义：,（）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。,（）（）中所述方法的研究。,.,本书给出的定义,:,软件工程是一类求解软件的工程。它应用计算机科学、数学以及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高软件质量、降低成本、按时按量交付的目的。,.,计算机科学、数学用于构造模型和算法。,工程科学用于制定规范、设计模式、评估成本及确定权衡。,管理科学用于计划、资源质量、成本等管理。,.,二软件工程框架,软件工程目标,软件工程活动,软件工程原则,.,软件工程框架,.,软件工程目标,正确性软件产品达到预期功能的程 度。,可用性软件基本结构、实现、文档为用户可用的程度。,合算性具有经济效益，即开发、运行的开销满足用户要求的程度。,.,软件工程活动,-,生产软件步骤,问题定义明确要解决的问题,可行性分析即定义的问题是否有解决的办法,需求分析为解决问题，目标系统必须具备哪些功能,设计总体设计，详细设计,实现编写程序代码,确认测试,支持软件维护,.,软件工程原则,选取适宜的开发模型,采用合适的设计方法,提供高质量的工程支持,重视开发过程的管理,.,三软件工程模型所有软件工程的活动都必须进行管理。,软件项目管理贯穿于软件工程的演化过程。,软件工程的演化过程：,.,三软件工程模型,软件工程模型,:,组织软件工程活动的方法，称为软件工程模型。,软件工程模型是用一定的流程将各个活动连接起来，并可用规范的方式操作全过程，如同工厂的生产线。,常见模型有线性、快速原型、螺旋、渐增式等模型。,.,常见的软件工程模型,线性模型（也称，瀑布模型，顺序模型）,.,常用的软件工程模型,螺旋模型可看成是连接的线性模型,.,常用的软件工程模型,渐增式模型（增量模型）,.,常用的软件工程模型,渐增式模型首先构建系统的基本轮询回路：,.,1.2,项目管理,一项目与项目管理,项目的概念及特点,项目：是指在,一定约束条件,下具有,特定目标,的一项,一次性,任务,共同特点：,一次性，又称为单件性,目标的明确性：成果性目标（功能性要求），约束性目标,作为管理对象的整体性,.,2,、项目的生命周期,.,项目的生命周期,项目启动阶段进行可行性分析，若接受项目进行需求确认，项目立项,项目计划阶段建立解决问题方案，向客户提交各种计划书,项目实施阶段执行解决方案，实现项目的目标,工作结束阶段正式验收项目,.,另一书中对项目周期阶段的划分,生命周期阶段,工程阶段,初始阶段,细化阶段,生产阶段,构造阶段,移交阶段,.,各阶段特点,工程阶段：,使计划、需求和构架同时进化，并解决开发风险，这个阶段以一个可执行构架基线结束，即工程阶段进行设计和综合活动。,生产阶段：,进行构造、测试和实施活动。,.,各阶段特点,借助提高功能的演示使系统能力得以进化。,各种活动同时进化，每个阶段都包括一次或多次迭代，一次迭代表示一个活动序列，这些活动有明确的中间事件（里程碑）。,.,各阶段特点,主里程碑：,使用正式版本的评价标准和发布说明书，一个阶段结束产生一个主里程碑。,次里程碑：,使用非正式版本，一次迭代结束产生一个次里程碑。,.,各阶段特点,为实现整个项目的某个特定状态，每个阶段都要进行足够次数迭代。,各阶段的工作产品（制品，文档等），同时进化产生，但每个阶段都有一个主要焦点：,初始阶段需求 （生命周期目标里程碑）,细化阶段设计 （生命周期构架里程碑）,构造阶段实现 （初始的可操作能力里程碑）,移交阶段实施 （产品发布里程碑）,（这里的模型是渐增式（增量式）,.,项目管理,项目管理定义,PMI,（,Project Management Institute,）定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。,项目管理又可定义为：在一个确定的时间范围内，为了完成一个既定的目标，通过特殊形式的临时性组织运行机制，经有效的计划、组织、领导和控制，充分利用既定有限资源的一种系统管理方法。,.,项目管理特点,综合性,创造性,时间性,.,项目管理的要素,范围时间、成本、质量、组织、客户满意度,.,二项目管理知识体系,集成管理,范围管理,时间管理,成本管理,质量管理,人力资源管理,沟通管理,采购管理,风险管理,.,三项目管理学科的发展,项目管理学科发展的特点,全球化发展、多元化发展、专业化发展,项目管理学科在双向探索中前进,各学科领域的理论,、,方法应用于项目管理，项目管理的理论,、,方法应用于各学科领域,项目学发展的趋势,微观项目管理，即单一项目的管理,PMBOK,是当前项目管理学科发展的重要内容,项目学是知识创新与市场相结合的综合化发展,项目学是科学、技术和艺术的综合,.,软件项目管理,一软件项目产品的特点,抽象性,缺陷检测的困难性,高度的复杂性,缺乏统一规则,.,二软件项目失控的原因,软件失控项目,(p15-16),是指软件项目在进行时遇到困难，导致大大超出可控制范围的项目,。,软件项目失控的原因,七方面原因：需求不明确、计划不充分和过于乐观的估计、采用新技术、管理方法缺乏或不恰当、性能问题、团队组织不当、人际因素,.,三软件项目管理的内容,软件项目管理的定义,(p19),软件项目管理的过程,(p19),软件项目管理的内容,(p19-20),.,软件项目管理的定义,PMI,对项目管理定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。,软件项目管理的定义：在软件项目活动中运用一系列的知识、技能、工具和技术，以满足软件需求方的整体要求。,.,软件项目管理的过程,启动软件项目,制定项目计划,跟踪及控制项目计划,评审项目计划,编写管理文档,.,软件项目管理的内容,软件项目需求管理,软件项目估算与进度管理,软件项目配置管理,软件项目风险管理,软件项目质量管理,软件项目资源管理,.,第章软件项目需求管理,.,软件需求一,.,软件需求概念,1.,定义,简单地说，软件需求就是确定系统需要做什么,严格意义上，软件需求是系统或软件必须达到的目标与能力,.,定义软件需求的五项内容,系统的输入,系统的输出,系统的功能,系统的属性,系统环境的属性,.,2.,软件需求在软件项目的作用,软件需求与其他软件过程的关系,.,软件需求类别,1.,软件需求的抽象层次,软件需求分成四个抽象层次,原始问题描述,用户需求,系统需求,软件设计描述,.,软件需求的抽象层次,.,原始问题描述是对要解决问题的叙述,用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束,系统需求用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述,软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述,.,原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通,系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现,通常情况下，经常提到的是用户需求和系统需求,.,2.,用户需求,用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述,.,使用自然语言可能出现如下问题,描述困难,需求混乱,因此写需求文档应遵守一些简单原则,：,标准的格式,使用一致的语言,使用特殊文本,尽量避免专业术语,.,3.,系统需求,系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点,系统需求描述通常采用结构化语言和过程设计语言,PDL.,.,系统需求的描述语言,名称,说明,优点,缺点,结构化语言,是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述,表现能力强、易于理解、一致性约束、控制结构、图形化显示,仍然有一定程度的二义性；细致程度欠缺,PDL,源于像,Java,或,Ada,这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力,可通过软件工具进行语法和语义检查,表达系统功能的能力不足、使用的符号只有具有程序设计背景的人才能理解,.,4,系统需求的分类,分为三类：,功能需求,非功能需求,领域需求,.,(1),功能需求,功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述,系统的功能需求应该具备全面性和一致性要做到全面和一致几乎是不可能的原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾,为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档,.,(2),非功能需求,非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等,非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等,.,按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；,产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程,.,表,2.2,非功能需求的类别,非,功,能,需,求,产品需求,可用性需求,效率需求,性能需求,空间需求,可靠性需求,可移植性需求,机构需求,交付需求,实现需求,标准需求,外部需求,互操作需求,道德需求,立法需求,隐私需求安全性需求,.,(3),领域需求,领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点,领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识,.,三软件需求文档,软件需求文档是对软件系统要求的陈述,包括：用户需求 系统需求,.,三软件需求文档,1.,需求文档的编制与作用,编写需求文档时，以下几点是应该注意的：,语句和段落尽量简短,表达时采用主动语态,语句要完整，且语法，标点等正确无误,使用的术语要与词汇表中的定义保持一致,陈述时要采用一致的样式,避免模糊的，主观的术语，如性能优越,避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证,.,需求文档的作用,使用对象 需求文档的作用,软件项目客户 了解软件项目能够提供的软件产品，检查 软件需求是否满足需要,项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用,软件开发人员 理解要开发的产品及具体要开发的内容,软件测试人员 验证软件系统是否满足了预期的要求,软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系,软件发布人员 在需求文档的基础上编写用户文档，如用户手册,软件培训人员 在需求文档的基础上编写培训材料,.,软件需求规格说明,(1),基本含义,规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统,软件需求规格,SRS,也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档,.,软件项目管理者用,SRS,来对项目进行计划和管理。,除设计和实现上的限制外，,SRS,一般不包括设计、构建、测试或工程管理的细节。,SRS,的基本内容包括功能需求和非功能需求。,功能需求定义系统需要,“,做什么,”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。,非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。,.,(2)IEEE,标准,830-1998,见,:P27P28,.,(3)SRS,大纲,见,:P28-P29,.,四,.,软件需求度量,一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节,.,软件需求质量度量的九个元素,即正确,无歧义,完备,一致,分级,可验证,可修改,可跟踪及可理解,.,2,2,需求工程,.,一,、,产生与发展,1,、产生,人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。,需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。,需求规格说明又是软件设计、实现、测试直至维护的主要基础。,.,2.,发展,需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合发展。,（）对象化,需求工程的对象化主要是指需求模型及其构造方法的对象化，面向对象需求模型及需求定义语言是其研究的关键。,.,（）,形式化,需求规格描述方法有三种,:,形式化方法、非形式化方法和半形式化方法。,形式化方法是具有严格数学基础的描述系统特征的方法，具有准确、无二义性的特点，有助于验证有效性和完整性。,非形式化方法使用未作任何限制的自然语言，易于理解和使用，但它固有二义性，且难以保证正确性、可维护性，难以用计算机系统提供自动化的支持。,半形式化方法介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些局部方面则允许使用非形式化的自然语言。,.,(3),自动化,在自动化的层次方面，已从实现级、设计级发展到功能级，并逐渐渗透到需求级二,.,研究内容,、需求工程的目标,需求工程有两个主要任务：,其一是通过对问题及其环境的理解、分析和综合，建立分析模型,;,其二是在完全弄清用户对软件系统的确切要求的基础上，用,SRS,把用户的需求表达出来。,.,（）,建立需求分析模型,分析模型是描述软件需求的一组模型。,需求分析模型包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，是形成需求说明、进行软件设计及实现的基础。,（）编写,SRS,SRS,的编写要以需求分析模型为基础、按照软件组织定义的,SRS,大纲、采用某种需求描述语言来进行。,.,、需求工程的层次分解,需求工程可分为需求开发和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。,.,需求开发和需求管理是有界限的：,.,需求管理,.,一,.,需求管理的必要性,、需求供求双方固有的矛盾,需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。,、需求具有易变性和难以表述性,软件项目中的问题都是在需求分析阶段埋下的祸根。,软件需求还很难以表述。,正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。,.,、需求错误出现的高频性和修复的高昂成本需求错误是软件项目开发中最常见的。,表,2.4,软件缺陷总结,缺陷来源 潜在缺陷 剩余缺陷 排除效率（,%,）需求,0.2 0.046 77,设计,0.25 0.0375 85,编码,0.35 0.0175 95,建档,0.12 0.024 80,修复,0.08 0.024 70,合计,1 0.149 85.1,.,一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的倍。,对于软件缺陷，修复的发现和修复的越早，则成本越低。,做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。,.,软件缺陷修复的成本,.,二,.,目标和原则,、目标,(p35-36),需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。具体来说,需求管理的目标有二个,:,(1),使软件需求受控,并建立供软件工程和管理使用的需求基线。,(2),使软件计划、产品和活动与软件需求保持一致。,.,、原则,为进行有效的需求管理，通常要遵循如下五条原则：,（）需求一定要分类管理,（）需求必须分优先级,（）需求必须文档化,（）需求一旦变化，就必须对需求变更的影响进行评估,（）需求管理必须与需求工程的其他活动紧密整合,.,三,.,需求管理活动,需求管理规划内容包括：,需求识别,变更管理过程,需求跟踪,自动化工具,.,需求管理是一个对系统需求变更了解和控制的过程。需求管理的过程是与其他需求工程过程相互关联的。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。,.,需求管理活动的具体内容如表所示,需求管理活动,活动的任务,变更控制,建议需求变更并分析其影响，做出是否变更的决策,版本控制,确定单个需求和,SRS,的版本,需求跟踪,定义对于其他需求及系统元素的联系链,需求状态,定义并跟踪需求的状态,.,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),逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。,.,需求跟踪的双向模式可以通过需求链来表示,.,过程元素之间的关系有如下三种,一对一，如一个代码模块应用一个设计元素。,一对多，如多个测试实例验证一个功能需求。,多对多，如一个测试实例导致多个功能性需求，而其中一些功能性需求又拥有多个使用实例。,.,需求跟踪矩阵,需求代号,规格说明,需求实例,设计实例,编码实例,测试实例,测试记录,R001,标题或,标识符,标题或,标识符,标题或,标识符,标题或,标识符,标题或,标识符,标题或,标识符,R002,.,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,）有了以上五个功能项的数量后，再由估计人员对项目的复杂性作出判断，大致分成简单、一般、复杂三种情况。然后根据下表求出功能项的加权和。,功能项,权,重,简单,一般,复杂,输入,3,4,6,输出,4,5,7,查询,3,4,6,外部文件,7,10,15,内部文件,5,7,10,.,功能点,FP,是由未调整的功能点数,UFC,与技术复杂度因子（TCF,）相成得到。,.,从上表计算出：,TCF=0.65+0.01*(SUM(Aj),TCF,的取值范围为,0.65,1.35,，,分别对应着组成部分,Aj,都取值,0,和,5,，,得到功能点,FP,的计算公式：,FP=UFC*TCF,.,功能点度量在以下情况下特别有用：,（,1,）估计新的软件开发项目；,（,2,）应用软件包括很多输入输出或文件活动；,（,3,）拥有经验丰富的功能点估计专家；,（,4,）拥有充分的数据资料，可以相当准确地将功能点转化为,LOC,。,.,3.3,软件项目成本估算,.,3.3.1,成本估算方法,.,一,.,算法模型,.,二,.,专家判定,对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有：,（,1,）求中值或平均值,（,2,）召开小组会议,.,（,3,）,Delphi,技术,（,4,）,Wideband Delphi,技术,.,三,.,类比,.,四,.,自顶向下,推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。,其缺点是难以识别较低级别上的技术性困难。,.,五,.,自底向上,自底向上估算是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，就得到了软件开发的总工作量。,易于忽略许多与软件开发有关的系统级成本。,.,六 计划指南,第一级工作分解结构元素,默认预算,管理,10环境,10%,需求,10%,设计,15%,实现,25%,评估,25%,实施,5%,合计,100%,.,默认工作量和进度在各阶段的分布,项目,初始,细化,构造,移交,工作量,5%,20%,65%,10%,进度,10%,30%,50%,10%,.,七,.,成本和进度估计过程,自项向下的方法计划序列,软件项目经理,(,和其他人,),开发出项目所需的规模、过程、环境、人员和质量的全局描述。,使用软件成本估计模型，在宏观级别上估计整体工作量和制定进度。,软件项目经理使用如表,1,中的指南，将估计的工作量分配到第一级工作分解结构中。软件项目经理又使用表,2,中的指南，将进度分成主里程碑日期、并将工作量分配给各级人员。,此刻，子项目经理负责将每一个工作分解结构元素划分到更低的级别，而使其满足顶层分配、人员结构和主里程碑日期的限制。,.,由底向上的方法计划序列,最低级别的工作分解结构元素被细化成细节任务，相关的工作分解结构元素的管理人员根据这些任务估计预算和进度。,在较高级别预算和里程碑中结合并集成了估计。,与自顶向下的预算和进度里程碑进行比较。评估总的区别并进行校正，以取得自顶向下和自底向上估计的协调。,.,3.4,软件项目进度管理,.,3.4.1,制定项目计划一,.,制定项目计划的原则,项目计划在项目开始的时候制定，并随着项目的进展不断发展。,考虑的重点要放在需要更多知识的地方及如何去获取这些知识。,.,二,.,软件项目计划的要素,软件项目计划的要素包括目标、合理的概念设计、工作分解结构、规模估计、工作量估计和项目进度安排。,.,三,.,软件项目计划的逻辑要点,需求分析：项目计划的第一步就是把模糊的需求准确化。,项目的概念设计：一般要定义工作分解结构。,资源配置和进度安排,.,需求足够清晰时，应进行详细设计，制定实现策略并纳入计划之中。,充分理解项目各部分后，确定实施细节并在下次计划更新时形成文档。,在整个项目周期中，项目计划为各种资源的配置提供框架。,.,四,.,软件项目计划周期,.,五,.,项目计划的内容,项目的目标,工作分解结构,WBS,资源配置,进度安排,.,一,.,必要性,制定项目计划时，项目的交付最好采用按阶段交付的形式。,软件组织最好的做法是在早期只对基本功能进行约定，其余问题的约定则推迟。,软件功能按照其重要程度的顺序进行交付，最重要的功能最先交付。,.,二,.,分阶段交付的过程,.,三,.,如何分阶段,定义每一个阶段的主题，然后就主题和用户进行商榷，再根据主题把软件特征分配到各阶段。,.,3.4.3,进度安排,.,一,.,进度安排的整体过程,.,项目整体进度安排的过程如下：,（,1,）根据项目总体进度目标，编制人员计划,（,2,）将各阶段所需要的资源和可以取得的资源进行比较，确定各阶段的初步进度，然后确定整个项目的初步进度。,.,（,3,）对初步进度计划进行评审，确保该计划满足要求，否则就要重复上面的步骤。一般都需要多次调整。,.,二,.,进度中的并行性,.,软件开发过程中设置了若干里程碑。,当一个软件任务成功地通过了评审并产生了相应文档之后，就完成了一个里程碑。,软件项目的并行性提出了一系列进度要求。,.,三,.,进度安排的方法,采用图示方法。常用的有甘特图和网络图,.,（,1,）甘特图,甘特图（,Gantt Chart,），又称横道图，是各种任务活动与日历表的对照图。,.,.,每一个任务的完成不以能否继续下一阶段的任务为标准，其标准是是否交付相应的文档和通过评审。,.,（,2,）网络图,用网络分析的方法编制的进度计划成为网络图。,.第,4,章 软件项目配置管理,4.1,配置管理概念,.,4.1.1,基本概念,软件项目配置管理就是作为变更控制机制而引入到软件项目中的,相关概念,（,1,）软件,配置管理中的软件是指由逻辑和功能特性构建的信息。,（,2,）配置,配置由部件表和部件分解图组成。部件分解图定义了基线中包含的所有要素以及如何将它们安装在一起。,.,（,3,）标识,识别产品的结构、产品的构件及其类型，为其分配惟一的标识符，并以某种形式提供对它们的存取。,（,4,）软件配置项,软件配置项,SCI,是为了配置管理的目的而作为一个单位来看待的软件要素的集合。,.,部件号,部件描述,1,软件项目计划,2,需求规格说明3,设计说明,4,质量保证计划,5,测试计划,6,源程序代码,7,例行程序库,8,可执行代码,软件部件表,1,.,软件部件表,2,部件号,部件描述,9,脚本文件,10,测试程序,11,测试报告,12,建造程序,.,软件部件分解图,.,软件配置项,项目,相关信息,产品概念说明,软件项目计划,软件开发计划,软件质量保证计划,软件配置管理计划,软件验证和确认计划,软件需求规格说明,软件设计说明,源代码,源代码列表,可执行文件,Make,文件,库,.,项目,相关信息,数据库描述,图表和文件描述,初始内容,软件配置管理程序,源代码树结构,日常建造程序,备份程序,软件问题报告,软件发布过程,内部发布过程外部发布过程,发布文档,软件测试文档,测试计划,测试程序,测试脚本,测试数据,测试报告,用户文档,用户手册,联机帮助,系统管理员文档,服务文档,维护文档,软件维护计划,软件问题报告,变更请求,.,（,5,）版本,版本是一个基线或一个软件配置项的特例。,（,6,）基线,基线是开发过程的里程碑，以一个或多个软件配置项的交付为标准；基线由通过正式评审的软件配置项组成，是进一步开发的基础；基线只有通过正式的变更控制过程才能改变。,.,（,7,）控制,通过建立产品基线，控制软件产品的发布和整个软件生命周期中对软件产品的修改。,（,8,）状态统计,记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。,.,（,9,）审核,确认产品的完整性并维护构件间的一致性，即确保是一个严格定义的构件集合。,（,10,）生产,对产品的生产进行优化管理。,（,11,）过程管理,确保软件组织的规程、方针和软件周期得以正确贯彻执行。,.,（,12,）小组协作,控制开发统一产品的多个开发人员之间的协作。,（,13,）配置控制委员会,配置控制委员会,CCB,负责评审和批准对基线的变更，通常由项目选出的代表组成。,.,4.1.2,软件配置管理,1.,定义,软件配置管理是软件项目运作的一个支撑平台。这种支撑是贯穿项目的整个生命周期的。,.,SCM,作为支撑平台,.,配置管理,CM,是在系统生命周期中对系统中的