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

1、软件项目管理软件项目管理软件项目管理软件项目管理软件：是与一个系统，特别是一个计算机系统有关的程序、过程和有关文档的完整集合。工程：是科学和数学的应用，通过这一应用，使得自然界的物质和能源的特性通过各种结构、机器、产品、系统和过程成为对人类有用的东西。lFritz BauerNAV69在NATO会议上给出的定义: l 软件工程是建立和使用一套合理的工程原则，从而经济地获得可靠的和能在实际机器上高效运行的软件。lIEEEIEEE93给出了一个更加综合的定义：（） 将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。（） （）中所述方法的研究。l本书给出的定

2、义:软件工程是一类求解软件的工程。它应用计算机科学、数学以及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高软件质量、降低成本、按时按量交付的目的。l计算机科学、数学用于构造模型和算法。l工程科学用于制定规范、设计模式、评估成本及确定权衡。l管理科学用于计划、资源、质量、成本等管理。l软件工程目标l软件工程活动l软件工程原则l正确性软件产品达到预期功能的程 度。l可用性软件基本结构、实现、文档为用户可用的程度。l合算性具有经济效益，即开发、运行的开销满足用户要求的程度。l问题定义明确要解决的问题l可行性分析即定义的问题是否有解决的办法l需求分析为解决问题，目标系统必须具备哪些功能l

3、设计总体设计，详细设计l实现编写程序代码l确认测试l支持软件维护l选取适宜的开发模型l采用合适的设计方法l提供高质量的工程支持l重视开发过程的管理l所有软件工程的活动都必须进行管理。l软件项目管理贯穿于软件工程的演化过程。l软件工程的演化过程：l软件工程模型: 组织软件工程活动的方法，称为软件工程模型。l软件工程模型是用一定的流程将各个活动连接起来，并可用规范的方式操作全过程，如同工厂的生产线。l常见模型有线性、快速原型、螺旋、渐增式等模型。l线性模型（也称，瀑布模型，顺序模型）l螺旋模型可看成是连接的线性模型l渐增式模型（增量模型）l渐增式模型首先构建系统的基本轮询回路：项目的概念及特点项目

4、：是指在一定约束条件下具有特定目标的一项一次性任务共同特点：l一次性，又称为单件性l目标的明确性：成果性目标（功能性要求），约束性目标作为管理对象的整体性项目的生命周期 l项目启动阶段进行可行性分析，若接受项目进行需求确认，项目立项l项目计划阶段建立解决问题方案，向客户提交各种计划书l项目实施阶段执行解决方案，实现项目的目标l工作结束阶段正式验收项目生命周期阶段 工程阶段 初始阶段 细化阶段 生产阶段 构造阶段 移交阶段l工程阶段： 使计划、需求和构架同时进化，并解决开发风险，这个阶段以一个可执行构架基线结束，即工程阶段进行设计和综合活动。l生产阶段： 进行构造、测试和实施活动。l借助提高功能

5、的演示使系统能力得以进化。l各种活动同时进化，每个阶段都包括一次或多次迭代，一次迭代表示一个活动序列，这些活动有明确的中间事件（里程碑）。l主里程碑： 使用正式版本的评价标准和发布说明书，一个阶段结束产生一个主里程碑。l次里程碑： 使用非正式版本，一次迭代结束产生一个次里程碑。l为实现整个项目的某个特定状态，每个阶段都要进行足够次数迭代。l各阶段的工作产品（制品，文档等），同时进化产生，但每个阶段都有一个主要焦点：初始阶段需求 （生命周期目标里程碑）细化阶段设计 （生命周期构架里程碑）构造阶段实现 （初始的可操作能力里程碑）移交阶段实施 （产品发布里程碑）（这里的模型是渐增式（增量式）l项目管

6、理定义PMI（Project Management Institute）定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。项目管理又可定义为：在一个确定的时间范围内，为了完成一个既定的目标，通过特殊形式的临时性组织运行机制，经有效的计划、组织、领导和控制，充分利用既定有限资源的一种系统管理方法。l项目管理特点l综合性l创造性时间性l范围 、 时间 、成本、 质量、 组织 、客户满意度l集成管理l范围管理l时间管理l成本管理l质量管理l人力资源管理l沟通管理l采购管理l风险管理l项目管理学科发展的特点 全球化发展、多元化发展、专业化发展l项目管理学科在双向

7、探索中前进 各学科领域的理论、方法应用于项目管理，项目管理的理论、方法应用于各学科领域l项目学发展的趋势l微观项目管理，即单一项目的管理lPMBOK是当前项目管理学科发展的重要内容l项目学是知识创新与市场相结合的综合化发展l项目学是科学、技术和艺术的综合l抽象性l缺陷检测的困难性l高度的复杂性l缺乏统一规则l软件失控项目(p15-16) 是指软件项目在进行时遇到困难，导致大大超出可控制范围的项目。l软件项目失控的原因 七方面原因：需求不明确、计划不充分和过于乐观的估计、采用新技术、管理方法缺乏或不恰当、性能问题、团队组织不当、人际因素l软件项目管理的定义(p19)l软件项目管理的过程(p19)

8、l软件项目管理的内容(p19-20)lPMI对项目管理定义：在项目活动中运用一系列的知识、技能、工具和技术，以满足或超过相关利益者对项目的要求。l软件项目管理的定义：在软件项目活动中运用一系列的知识、技能、工具和技术，以满足软件需求方的整体要求。l启动软件项目l制定项目计划l跟踪及控制项目计划l评审项目计划l编写管理文档l软件项目需求管理 l软件项目估算与进度管理 l软件项目配置管理 l软件项目风险管理 l软件项目质量管理 l软件项目资源管理 l简单地说，软件需求就是确定系统需要做什么l严格意义上，软件需求是系统或软件必须达到的目标与能力l系统的输入l系统的输出l系统的功能l系统的属性l系统环

9、境的属性l软件需求与其他软件过程的关系软件需求分成四个抽象层次l原始问题描述l用户需求l系统需求1.软件设计描述l原始问题描述是对要解决问题的叙述l用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束l系统需求用详细的术语给出系统要提供的服务及受到的约束，因而系统需求文档也称为功能描述l软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述l原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通l系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现l

10、通常情况下，经常提到的是用户需求和系统需求l用户需求从用户的角度描述系统的需求，以便没有专业技术背景的用户能看懂它只描述系统的外部行为，尽量避免涉及系统内部的设计特性，因而用户需求就不可能使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述l描述困难l需求混乱因此写需求文档应遵守一些简单原则：l标准的格式l使用一致的语言l使用特殊文本l尽量避免专业术语l系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点l系统需求描述通常采用结构化语言和过程设计语言PDL.名称 说明 优点 缺点 结构化语言是对自然语言格式化，依赖于定义标准格式

11、或模板来表达需求描述表现能力强、易于理解 、一致性约束 、控制结构 、图形化显示仍然有一定程度的二义性；细致程度欠缺PDL 源于像Java或Ada这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力 可通过软件工具进行语法和语义检查表达系统功能的能力不足、使用的符号只有具有程序设计背景的人才能理解l分为三类 ： 功能需求 非功能需求 领域需求 (1) 功能需求功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述系统的功能需求应该具备全面性和一致性要做到全面和一致几乎是不可能的原因有二，其一是系统本身固有的复杂性；其二是用户和开发人员站在

12、不同的立场上，导致他们对需求的理解有偏颇，甚至出现矛盾为保证软件项目的成功，无论在哪个阶段，只要发现问题，都必须修正需求文档(2) 非功能需求非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性，响应时间，存储空间等非功能需求定义了对系统提供的服务或功能的约束，包括时间约束，空间约束，开发过程约束及应遵循的标准等l按照非功能需求的起源，可将其分为三大类：产品需求，机构需求，外部需求；l产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程非功能需求 产品需求 可用性需求 效率需求

13、 性能需求 空间需求 可靠性需求 可移植性需求 机构需求 交付需求 实现需求 标准需求 外部需求 互操作需求 道德需求 立法需求 隐私需求安全性需求(3) 领域需求领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点领域需求可能是功能需求，也可能是非功能需，其确定需要领域知识软件需求文档是对软件系统要求的陈述 包括： 用户需求 系统需求编写需求文档时，以下几点是应该注意的：l语句和段落尽量简短l表达时采用主动语态l语句要完整，且语法，标点等正确无误l使用的术语要与词汇表中的定义保持一致l陈述时要采用一致的样式l避免模糊的，主观的术语，如性能优越l避免使用比较性的词汇，尽量给出定

14、量的说明， 含糊的语句表达将引起需求的不可验证 使用对象 需求文档的作用 l软件项目客户 了解软件项目能够提供的软件产品，检查 软件需求是否满足需要l项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用l软件开发人员 理解要开发的产品及具体要开发的内容l软件测试人员 验证软件系统是否满足了预期的要求l软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系l软件发布人员 在需求文档的基础上编写用户文档，如用户手册l软件培训人员 在需求文档的基础上编写培训材料(1)基本含义l规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统l

15、软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档l软件项目管理者用SRS来对项目进行计划和管理。l除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。lSRS的基本内容包括功能需求和非功能需求。l功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。l非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性

16、等。(2) IEEE标准830-1998 见: P27P28(3) SRS 大纲 见: P28-P29l一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽量避免软件设计与软件实现的细节.l软件需求质量度量的九个元素,即正确,无歧义,完备,一致,分级,可验证,可修改,可跟踪及可理解22 需求工程一 、 产生与发展1、 产生人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。需求工程是一个包括创建和维护需求文档所必需的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。需求规格说明又是软件设计、实现、测试直至维护的主要基础。

17、2. 发展需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合发展。（）对象化需求工程的对象化主要是指需求模型及其构造方法的对象化，面向对象需求模型及需求定义语言是其研究的关键。（ ）形式化 需求规格描述方法有三种: 形式化方法、非形式化方法和半形式化方法。形式化方法是具有严格数学基础的描述系统特征的方法，具有准确、无二义性的特点，有助于验证有效性和完整性。非形式化方法使用未作任何限制的自然语言，易于理解和使用，但它固有二义性，且难以保证正确性、可维护性，难以用计算机系统提供自动化的支持。半形式化方法介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些局部方面则允许使用

18、非形式化的自然语言。(3) 自动化在自动化的层次方面，已从实现级、设计级发展到功能级，并逐渐渗透到需求级。、需求工程的目标 需求工程有两个主要任务：其一是通过对问题及其环境的理解、分析和综合，建立分析模型;其二是在完全弄清用户对软件系统的确切要求的基础上，用SRS把用户的需求表达出来。（）建立需求分析模型分析模型是描述软件需求的一组模型。需求分析模型包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，是形成需求说明、进行软件设计及实现的基础。（）编写SRSSRS的编写要以需求分析模型为基础、按照软件组织定义的SRS大纲、采用某种需求描述语言来进行。 需求工程可分为需求开发

19、和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。l需求开发和需求管理是有界限的： 需求管理、需求供求双方固有的矛盾需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。、需求具有易变性和难以表述性软件项目中的问题都是在需求分析阶段埋下的祸根。软件需求还很难以表述。正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。 表2.4 软件缺陷总结l缺陷来源 潜在缺陷 剩余缺陷 排除效率（% %）需求 0.2 0.046 77 设计 0.25 0.0375 85 编码 0.35 0.0175 95 建档 0.12 0.024

20、 80 修复 0.08 0.024 70 合计 1 0.149 85.1 l 一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的倍。对于软件缺陷，修复的发现和修复的越早，则成本越低。做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。、目标(p35-36) 需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。具体来说,需求管理的目标有二个: (1)使软件需求受控,并建立供软件工程和管理使用的需求基线。 (2)使软件计划、产品和活动与软件需求保持一致。、原则为进行有效的需求管理，通常要遵循如下五条原则：（）需求一定要分类管理（）需求必须

21、分优先级（）需求必须文档化（）需求一旦变化，就必须对需求变更的影响进行评估（）需求管理必须与需求工程的其他活动紧密整合l需求管理规划内容包括： 需求识别 变更管理过程 需求跟踪 自动化工具l需求管理是一个对系统需求变更了解和控制的过程。需求管理的过程是与其他需求工程过程相互关联的。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。l需求管理活动的具体内容如表所示需求管理活动 活动的任务变更控制 建议需求变更并分析其影响，做出是否变更的决策版本控制 确定单个需求和SRS的版本需求跟踪 定义对于其他需求及系统元素的联系链需求状态 定义并跟踪需求的状态1、需

22、求变更的原因 软件项目的需求总是在变化着,一般原因有二: (1)在项目的早期所有的问题不可能被完全定义,软件需求是不完全的,注定了需求需要变更。 (2)随着软件项目的进行,软件开发人员对问题的理解会发生变化,这些变化也要反馈到需求中去。大型软件系统还可能存在如下导致需求变更的原因: (1)不同类型的用户的需求可能是冲突的或是矛盾的,最后的系统需求是它们之间的一个妥协.这种妥协的程度在项目进行过程中有可能发生改变,从而导致系统需求的改变。 (2)系统购买者或系统最终用户很少是同一人,有的系统客户对系统提出的一些需求可能和最终用户需求不一致。2、变更管理过程 变更管理过程分为变更描述、变更分析和变

23、更实现三个阶段。(1)变更描述 变更描述阶段要对需求问题或变更提议进行分析以检查它的有效性，进而产生一个更明确的需求变更提议。(2)变更分析 变更分析阶段对被提议的变更产生的影响进行评估。一旦分析完成，就有了对此变更是否执行的决策意见。(3)变更实现 实现变更时，需求文档及系统设计和实现都要做修改。一个容易出现的错误，一定要注意：先对系统做变更然后再回头修改需求文档的想法，这几乎不可避免地导致需求描述和系统实现不同步。需求文档应该有一个很好的形式，使得变更不会带来大量文字的修改。对于程序文档的可变性则通过最小化外部引用和尽量使之模块化来实现。3、变更影响分析l进行需求变更影响分析,应评估每项选

24、择的需求变更,以确定它对项目计划安排和其他需求的影响,同时明确与变更相关的任务并评估完成这些任务需要的工作量。变更影响分析有助于做出信息量充分的变更决策,确定对变更是修改还是抛弃,或者创建新系统以及评估每个任务的工作量.l如果一个处于关键路径的任务因变更而延期,则项目肯定赶不上预定进度,但如果能避免变更影响关键任务,则变更不会影响项目的进度表l影响分析报告的模板,用来报告进行需求变更的影响分析,变更控制委员会仅需要影响分析的总结.l如果没有很好的需求文档版本管理,就容易造成资源浪费.l需求文档版本控制是需求管理的一个必要方面.l做好需求文档版本控制,必须保证如下几点:l统一确定需求文档的每一个

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

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

27、可以由客户得出,但需求的业务不明确,还需要等待外部信息.客户本身也说不清楚的需求.l需要与客户沟通或确认的需求有两种情况: 其一是确认双方达成共识 其二是还需要再进一步的沟通l可把需求状态分为如下8种 已建议 已批准 已拒绝 已设计 已实现 已验证 已交付 已删除1、需求跟踪的必要性 进行需求跟踪的目的是建立和维护从用户需求开始到测试之间的一致性与完整性,确保所有的实现都以用户需求为基础,而实现的需求也全部覆盖了预期的需求,同时确保所有的输出与用户需求的符合性. 跟踪能力信息使得变更影响分析十分便利,有利于确认和评估实现某个建议的需求变更所必须的工作.2、可追溯性信息 进行需求跟踪,就要对需求

28、和需求之间以及需求和系统设计之间的许多关系进行追溯。当需求变更发生的时候,必须追踪这些变题对其他需求和系统设计的影响。可追溯性是需求描述的一个总体特性,反映了反映相关需求的能力。l需要维护的可追溯性信息有三类: (1) 源可追溯性信息,指连接需求到提出需求 的项目相关人员和产生需求的原因. (2) 需求可追溯性信息,指连接需求文档中彼此依赖的需求. (3) 设计可追溯性信息,指连接需求到其实现的设计模块.3、需求跟踪的实现需求跟踪有两种方式,正向跟踪和逆向跟踪：(1) 正向跟踪以用户需求为切入点,检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。(2) 逆向跟踪检

29、查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。l过程元素之间的关系有如下三种l一对一，如一个代码模块应用一个设计元素。l一对多，如多个测试实例验证一个功能需求。多对多，如一个测试实例导致多个功能性需求，而其中一些功能性需求又拥有多个使用实例。需求代号规格说明需求实例设计实例编码实例测试实例测试记录R001标题或标识符标题或标识符标题或标识符标题或标识符标题或标识符标题或标识符R002l在需求验证中的作用l有助于需求变更影响分析l便于需求的维护l便于测试时找出问题所在l便于项目跟踪l减小项目的风险l简化了系统的再设计易于软件重用2.4 需求管理质量保证1.需求验证过程l审

30、查需求文档l依据需求编写测试用例l编写用户手册确定合格的标准2.验证的内容 在需求验证过程中,要对需求文档中定义的需求执行多种类型的检查： 有效性检查 一致性检查 完备性检查 现实性检查 可检验性检查 可跟踪性检查 可调节性检查 可读性检查1.方式 评审有两类方式:一类是正式技术评审,另一类是非正式技术评审。2.注意事项l 严格控制每一次评审的文档规模及持续时间l评审工作要分段进行l对讨论的问题进行控制l避免无谓的争吵主要内容：l3.1 软件项目估算l3.2 软件规模l3.3 软件项目成本估算l3.4 软件项目进度管理l1. 项目估算的意义：包括工作量估算和成本估算两个方面。估算是指通过预测构

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

32、点E1的估算可以为软件组织提供初步信息，否则需要重新考虑项目的可行性。l产品定义：E2 产品定义阶段完成对项目的规格说明，进一步细化系统功能。l系统设计：E3 系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明；l系统实现：E4设计通过审查之后，系统的实现工作就开始了。该阶段结束时，前面各项活动中消耗的资源（时间及人力等）和软件工作量均可获得，从而可对原有的估算进行调整，后期需要的工作则按此估算进行计划。l系统运行：E5当所有的工作都已完成并得到了验证后，系统就可以投入运行了。估算工作实际上是对估算过程的评价，即用实际的消耗与各个阶段估算值进行比较，为下一项目积累宝贵的经验。l1.

33、工作分解结构传统的WBS结构1.在技术允许的条件下，应从最详细的WBS开始；2.精确定义度量的标准；3.估计底层每一模块的规模，汇总以得到总体估计；4.适当考虑偶然因素的影响。l常用的软件规模度量标准：代码行 DOC:功能点 FP:l代码行：代码行LOC是常用的源代码程序长度的度量标准。代码行可分为：无注释的代码行（NCLOC）和注释的源代码行（CLOC）实际工作中，也常常使用KLOC（千代码行）来表示程序长度。一代码行（1LOC）价值和人月均代码行数可以体现一个软件生产组织的生产能力。l功能点：功能点度量是在需求分析阶段基于系统功能的一种规模估计方法，常应用需求来确定各种输入、输出、查询、外

34、部文件和内部文件的数目，从而确定功能点数量。l计算功能点数的步骤：（1）计算所需要的输入、输出、查询、外部文件、内部文件的数量。（2）有了以上五个功能项的数量后，再由估计人员对项目的复杂性作出判断，大致分成简单、一般、复杂三种情况。然后根据下表求出功能项的加权和。功能项权 重简单一般复杂输入346输出457查询346外部文件71015内部文件5710l功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF）相成得到。l从上表计算出： TCF=0.65+0.01*(SUM(Aj)TCF的取值范围为0.651.35，分别对应着组成部分Aj都取值0和5，得到功能点FP的计算公式：FP=UFC*

35、TCFl功能点度量在以下情况下特别有用：（1）估计新的软件开发项目；（2）应用软件包括很多输入输出或文件活动；（3）拥有经验丰富的功能点估计专家；（4）拥有充分的数据资料，可以相当准确地将功能点转化为LOC。l对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有： （1）求中值或平均值 （2）召开小组会议l（3）Delphi技术l（4）Wideband Delphi 技术l推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。l其缺点是难以识别较低级别上的技术性困难。l自底向上估算是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有

36、部分相加，就得到了软件开发的总工作量。l易于忽略许多与软件开发有关的系统级成本。第一级工作分解结构元素第一级工作分解结构元素默认预算默认预算管理10%环境10%需求10%设计15%实现25%评估25%实施5%合计100%l默认工作量和进度在各阶段的分布项目项目初始初始细化细化构造构造移交移交工作量5%20%65%10%进度10%30%50%10% 自项向下的方法计划序列 软件项目经理(和其他人)开发出项目所需的规模、过程、环境、人员和质量的全局描述。 使用软件成本估计模型，在宏观级别上估计整体工作量和制定进度。 软件项目经理使用如表1中的指南，将估计的工作量分配到第一级工作分解结构中。软件项目

37、经理又使用表2中的指南，将进度分成主里程碑日期、并将工作量分配给各级人员。 此刻，子项目经理负责将每一个工作分解结构元素划分到更低的级别，而使其满足顶层分配、人员结构和主里程碑日期的限制。l由底向上的方法计划序列l最低级别的工作分解结构元素被细化成细节任务，相关的工作分解结构元素的管理人员根据这些任务估计预算和进度。l在较高级别预算和里程碑中结合并集成了估计。与自顶向下的预算和进度里程碑进行比较。评估总的区别并进行校正，以取得自顶向下和自底向上估计的协调。 项目计划在项目开始的时候制定，并随着项目的进展不断发展。 考虑的重点要放在需要更多知识的地方及如何去获取这些知识。l软件项目计划的要素包括

38、目标、合理的软件项目计划的要素包括目标、合理的概念设计、工作分解结构、规模估计、概念设计、工作分解结构、规模估计、工作量估计和项目进度安排。工作量估计和项目进度安排。l需求分析： 项目计划的第一步就是把模糊的需求准确化。l项目的概念设计：一般要定义工作分解结构。l资源配置和进度安排l需求足够清晰时，应进行详细设计，制定实现策略并纳入计划之中。l充分理解项目各部分后，确定实施细节并在下次计划更新时形成文档。l在整个项目周期中，项目计划为各种资源的配置提供框架。l项目的目标l工作分解结构WBSl资源配置l进度安排l制定项目计划时，项目的交付最好采用按阶段交付的形式。l软件组织最好的做法是在早期只对

39、基本功能进行约定，其余问题的约定则推迟。l软件功能按照其重要程度的顺序进行交付，最重要的功能最先交付。l定义每一个阶段的主题，然后就主题和用户进行商榷，再根据主题把软件特征分配到各阶段。l项目整体进度安排的过程如下： （1） 根据项目总体进度目标，编制人员计划 （2） 将各阶段所需要的资源和可以取得的资源进行比较，确定各阶段的初步进度，然后确定整个项目的初步进度。l（3） 对初步进度计划进行评审，确保该计划满足要求，否则就要重复上面的步骤。一般都需要多次调整。l软件开发过程中设置了若干里程碑。l当一个软件任务成功地通过了评审并产生了相应文档之后，就完成了一个里程碑。l软件项目的并行性提出了一系

40、列进度要求。l采用图示方法。常用的有甘特图和网络图l（1） 甘特图 甘特图（Gantt Chart），又称横道图，是各种任务活动与日历表的对照图。 l每一个任务的完成不以能否继续下一阶段的任务为标准，其标准是是否交付相应的文档和通过评审。l（2）网络图 用网络分析的方法编制的进度计划成为网络图。4.1 配置管理概念l相关概念（1）软件 配置管理中的软件是指由逻辑和功能特性构建的信息。（2）配置 配置由部件表和部件分解图组成。部件分解图定义了基线中包含的所有要素以及如何将它们安装在一起。（3）标识 识别产品的结构、产品的构件及其类型，为其分配惟一的标识符，并以某种形式提供对它们的存取。（4）软件

41、配置项 软件配置项SCI是为了配置管理的目的而作为一个单位来看待的软件要素的集合。部件号部件描述1软件项目计划2需求规格说明3设计说明4质量保证计划5测试计划6源程序代码7例行程序库8可执行代码部件号部件描述9脚本文件10测试程序11测试报告12建造程序项目相关信息产品概念说明软件项目计划软件开发计划软件质量保证计划软件配置管理计划软件验证和确认计划软件需求规格说明软件设计说明源代码源代码列表可执行文件Make文件库项目相关信息数据库描述图表和文件描述初始内容软件配置管理程序源代码树结构日常建造程序备份程序软件问题报告软件发布过程内部发布过程外部发布过程发布文档软件测试文档测试计划测试程序测试

42、脚本测试数据测试报告用户文档用户手册联机帮助系统管理员文档服务文档维护文档软件维护计划软件问题报告变更请求（5）版本 版本是一个基线或一个软件配置项的特例。（6）基线 基线是开发过程的里程碑，以一个或多个软件配置项的交付为标准；基线由通过正式评审的软件配置项组成，是进一步开发的基础；基线只有通过正式的变更控制过程才能改变。（7）控制 通过建立产品基线，控制软件产品的发布和整个软件生命周期中对软件产品的修改。（8）状态统计 记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。（9）审核 确认产品的完整性并维护构件间的一致性，即确保是一个严格定义的构件集合。（10）生产 对产品的生产

43、进行优化管理。（11）过程管理 确保软件组织的规程、方针和软件周期得以正确贯彻执行。（12）小组协作 控制开发统一产品的多个开发人员之间的协作。（13）配置控制委员会 配置控制委员会CCB负责评审和批准对基线的变更，通常由项目选出的代表组成。1.定义 软件配置管理是软件项目运作的一个支撑平台。这种支撑是贯穿项目的整个生命周期的。 配置管理CM是在系统生命周期中对系统中的配置项进行标识和定义的过程。该过程是通过控制配置项的发布及后续变更、记录并报告配置项的状态及变更请求、确保配置项的完整性和正确性来实现的。l软件配置管理SCM是应用于由软件组成的系统的配置管理，通过一套工程规范，在整个软件生命周

44、期中跟踪、记录软件，保证全部变更都记录在案，并保证软件的当前状态是已知的和可重复的。2.软件配置管理过程 根据IEEE定义,软件配置管理过程分为四步。（1）计划配置管理 确定SCM组织和责任，明确CM的过程、工具、技术及方法论，知道何时及如何进行。（2）开发CM方案 定义了一个配置标识方案CIS对软件产品进行跟踪，包括建立各个阶段的CM基线、进行配置标识。CIS贯穿于整个软件生存周期中。（3）配置控制 建立软件配置控制委员会，对基线的变更只有得到CCB的同意才能进行；对变更进行跟踪，确保任何时候软件配置都是已知的；在软件生存周期的整个过程中都要清楚基线状态的变更历史，以便于下一步的状态审计。（

45、4）状态审计 对状态进行报告，明确到目前为止改变的次数及最新版本等。 软件能力成熟度模型SCMM分为5个级别:初始级、可重复级、已定义级、已管理级和优化级。每个成熟度级别都包含若干个关键过程域KPA。l可重复级（二级）CMM包含6个：软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪和监督、软件项目策划及需求管理。软件配置管理作为二级CMM的一个KPA，是保证软件项目生成的产品在软件生存周期中完整性的重要手段。l从组织结构图中可以看出，SCM在整个体系中的位置及其与其他部分的关系。图中各组成部分的说明见P96。l软件配置管理的基本职责有配置经理、模块主管、变更控制委员会。l1、配置经理

46、配置经理的基本职责是对代码开发和测试进行支持和保护，是变更管理的控制中心。配置经理具有如下职能：l制定SCM规程，形成文档并分发给有关人员l建立系统基线，包括备份规定l确保对基线的变更都经过授权人员的批准l确保对基线的所有变更都进行充分细致的记录，以便可以重新生成或回退l确保所有基线变更都经过回归测试l规定解决异常问题的关注焦点2、模块主管 每一个模块配备一个主管的开发人员作为模块主管，其主要职责是：l把握模块的设计l为参与模块及其接口工作的人员提供建议l控制模块的所有更改l评审模块的变更和定期进行回归测试，确保模块的完整性3、变更控制委员会CCB 软件变更控制委员会SCCB是大中型软件项目中

47、协调变更的集中控制机制，是对每个变更进行评审，做出相关决策的实体。 SCCB是一个常设组织，项目经理指定SCCB的主席，SCM经理一般担任SCCB的秘书，SCCB成员般由各个功能组的技术或管理代表组成，包括从事开发、文档编写、测试、维护、发布等方面的人员。 1、SCM文件体系 文件体系是实施SCM的依据，它将标准的SCM要求映射为项目实施SCM所需的方针、程序和作业规范等文件（1）方针 在金字塔顶层的方针文件中，描述了SCM的目标、方法、途径和方针的责任人。本文件一般由SCM经理编制、项目经理审核、规划经理批准。（2）过程定义 过程定义是图中第二层次的文件，支撑了顶层方针，是整个文件体系的核心

48、，它将SCM所有共同特性的关键实践予以文件化和制度化。过程定义文件一般包括：范围、目的、引用标准、术语和定义、过程活动描述等几个方面，可以按照下面的八项指标描述过程活动。l目的： SCM过程活动的目的。l角色及职责： 完成一个过程活动的个人或小组的职责。l入口准则： 触发一个过程活动的必要的条件。l控制： 约束或调节一个过程活动。l输入： 一个过程活动执行的数据。l过程活动： 采取行动把输入转变成预定的输出。l输出： 一个过程活动产生或导出的数据。l出口准则： 结束一个过程活动的必要条件。l一般由SCM经理组织人员编制过程定义文件，然后由项目经理审核、规划经理批准。（3）规程或模板 规程或模板

49、是第三层次的文件，支撑了上两个层次的文件，为具体执行活动提供作业规范或模板。 规程或模板一般包含记录格式的表单，记录是开展SCM活动的有效工具。 规程或模板文件一般由从事这项具体工作的工作人员编制，由SCM经理审核，由项目经理批准。 编制SCM文件体系，需要将开展过程活动的各种SCM要素包含进去，包含组织结构、资源、工具等。2、SCM过程活动 SCM过程包括管理SCM和执行SCM两项活动。 SCM过程活动如图所示：l软件配置管理是涉及组织和管理各种软件产品及文档、控制其变化的一系列活动，贯穿整个软件生命周期。软件配置管理有四个主要功能：配置标识、配置控制、配置状态报告及配置审核。l配置标识惟一

50、的标识软件配置项1、要注意的问题 配置标识功能论述了与基线中包含的软件配置项的标识以及基线本身的标识有关的问题。“标识”用来确定如何识别产品的所有部件和由部件建造的产品基线。要考虑的关键点见P1002、配置标识框架配置标识的框架如下所示：ITEM IS BELONGTO PROVIDES ROPERTIES REQUIRES VERSION_LINK CONTENTPONITER指向初版内容END (1)配置项名称 配置项名称是一字符串,为该配置项命名。（2）文档类别名 文档类别名指配置项属于哪一工程、哪类文档。（3）资源 资源指配置项向外供应什么、向外要求什么，实际上就是表达与其他配置项的关