5.3 系统开发基础

本节的内容就是围绕“软件工程”为核心展开的，包括宏观层面的生命周期模型、主要开发方法论，以及主要的工作环节：需求分析与设计、测试与评审、项目管理、开发环境等基础知识。本节内容是新大纲加入的内容，主要要求能够从网络专业人员的角度支持系统的开发，因此主要需要对概念层面有系统的了解，分值占本章知识点所占分值的67%左右。

1．系统开发生命周期模型

知识点说明：

难度系数：★ 考查频度：★★★★ 考查权重：★★

本知识点的重点在于掌握各种常见的开发生命周期模型的概念、特点，能够正常地做出比较与选择。

知识点详解：

系统开发的生命周期是指一个系统历经计划、分析、设计、编程、测试、维护直至淘汰的整个过程。

（1）生命周期阶段划分。

●Boehm划分法：计划（问题定义、可行性研究）、开发（需求分析、总体设计、详细设计、编码、测试）、运行（维护）三大阶段。

●国标（GB 8566—1988）划分法：可行性研究与计划、需求分析、概念设计、详细设计、实现、组装测试、确认测试、使用和维护，并在《GB/T 8566—1995信息技术—软件生存期过程》中定义了获取过程、供应过程、开发过程、运行过程、维护过程、管理过程、支持过程7个部分。

●RUP划分法：分为初始、细化、构造、移交4个主要阶段。

（2）生命周期模型。

●瀑布模型：严格遵循软件生命周期各阶段的 固定顺序 ，一个阶段完成再进入另一个阶段，适于采用结构化开发方法。它的优点是，可以比较规范化过程，有利于评审；缺点在于，过于理想，缺乏灵活性，容易产生需求偏差。

●快速原型模型：对于许多 需求不够明确 的项目，比较适合采用该模型。它采用了一种 动态定义需求 的，通过快速地建立一个能够反映用户主要需求的软件原型，让用户在计算机上使用它，了解其概要，再根据反馈的结果进行修改，因此能够充分体现用户的参与和决策。原型化人员对原型的实施很重要，衡量他们的重要标准是，能否从用户的模糊描述中 快速地获取实际的需求 。

●演化模型：它也是一种原型化开发，但与快速原型不同的是，快速原型模型在获得真实需求时，就将抛弃原型。而演化模型则不然，它将从初始的模型中逐渐演化为最终软件产品，是一种“ 渐进式 ”原型法。

●增量模型：它采用的是一种“ 递增式 ”模型，它将软件产品划分为一系列的增量构件，分别进行设计、编码、集成和测试。

●螺旋模型：结合了瀑布模型和演化模型的优点，最主要的特点在于加入了 风险 分析 。它是由制订计划、分析风险、实施工程、客户评估的循环组成的，它最初是从 概念项目 开始第一个螺旋的。

●喷泉模型：主要用于描述面向对象的开发过程，最核心的特点是 迭代 。所有的开发活动没有明显的边界，允许各种开发活动交叉进行。

2．系统开发方法论

知识点说明：

难度系数：★ 考查频度：★★★ 考查权重：★★★

本知识点的重点在于了解结构化分析与设计、面向数据结构的设计、面向对象分析与设计，以及构件化方法四种开发方法的基础知识、概念、特点，以及常用的工具、方法，对其建立宏观的认识与理解。

知识点详解：

系统的开发方法主要包括结构化分析与设计（SA/SD）、面向数据结构的设计、面向对象分析与设计，以及构件化开发方法四种。

（1）结构化分析与设计。

它采用结构化技术来完成软件开发的各项任务，把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。它与瀑布模型有很好的结合度，是与其最相适应的开发方法。

●结构化分析（解决“做什么”的问题）：是一种面向数据流的需求分析方法，它的基本思想是 自顶向下 ，逐层分解。常用的工具包括数据流图和数据字典。 数 据流图 用来描述数据流从输入到输出的变换流程，由加工、数据流（包括输入数据流和输出数据流）、文件、外部实体构成。 数据字典 则是关于数据的信息集合，也是对数据流图中所包含的所有元素进行定义的集合。数据流图中加工的具体逻辑，通常使用结构化语言、判定树、判定表进行说明。

●结构化设计：包括体系结构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶向下、逐步求精和模块化的过程。

概要设计：主要设计软件的结构，确定系统是由哪些模块组成的，以及每个模块之间的关系。它采用结构图（包括模块、调用、数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入/处理/输出图）来描述。整个过程主要包括复查基本系统模型，复查并精化数据流图，确定数据流图的信息流类型（包括 交换流和事务流 ），根据流类型分别实施变换分析或事务分析，根据软件设计原则对得到的软件结构图进一步优化。

详细设计：确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用 自顶向下、逐步求精 的设计方式和 单入口单出口 的控制结构。经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）、PDL（伪码）。

（2）面向数据结构的设计。

数据的输入、存储都涉及不同的数据结构，面向数据结构设计方法的基本思想是 根 据数据结构导出程序结构 。典型的面向数据结构的设计方法包括Jackson方法和Warnier方法。

采用Jackson方法的基本步骤是：先建立系统的数据结构；接着以数据结构为基础，对应地建立程序结构；最后列出程序中要用到的各种基本操作，然后将操作分配到适当的模块中去。

面向数据结构的设计方法并没有明显地使用软件结构的概念，对于模块独立性原则也重视不足，因此并不适合复杂的软件系统。

（3）面向对象分析与设计。

引入了“对象”的概念，将数据和方法封装在一起，提高了模块的聚合度，降低了耦合度，在更大程序上支持软件复用。

● 对象的 基本概念：对象是系统中用来描述客观事物的一个实体，它由 对象标识 （名称）、 属性 （状态、数据、成员变量）和 服务 （操作、行为、方法）三个要素组成，它们被 封装 为一个整体，以接口的形式对外提供服务。

● 类 的基本概念：对具有相同属性和服务的一个或一组对象的抽象。

● 继承与多态性： 继承是面向对象方法中重要的概念，用来说明特殊类与父类的关系。而多态性则是指一般类（即父类）中定义的属性或服务被特殊类继承后，可以具有不同的数据类型或表现出不同的行为。

● 消息通信： 是面向对象方法学中的一个重要原则，它与对象的封装原则密不可分，为对象间提供了唯一合法的动态联系的途径。

●面向对象分析：拥有大量不同的方法，主要包括OMT，OOA，OOSE，Booch方法等，而OMT，OOSE，Booch则最后统一为UML。

OMT：包括对象模型（静态的、结构化的系统的“ 数据 ”性质，通常采用 类 图 ）、动态模型（瞬时的、行为化的系统“控制”性质，通常使用 状态图 ）和功能模型（表示变化的系统的“ 功能 ”性质，通常使用 数据流图 ）。

OOA：需经过确定类与对象、确定结构与关联（包括继承、聚合、组合、实例化等）、划分主题、定义属性、定义服务5个步骤来完成整个分析工作。

OOSE：它在OMT的基础上，对功能模型进行了补充，提出了“ 用例 ”的概念，最终取代了数据流图进行需求分析并建立功能模型。

（4）构件化开发。

为了避免陷入“重新发明轮子”的误区，进一步降低开发费用、提高生产率并在快速的技术演化面前提供受控的系统升级的开发方式，就催生了“ 基于构件的开发 （CBD）”。这种方法通过有计划地 集成现有的软件部分 进行软件开发。它可以有效地遏制复杂性，缩短发布时间，提高一致性，更有效地利用本领域的最佳方法，提高生产率，增加项目进度的可视性，支持并行和分布式的开发，减少维护费用。采用CBD后，所有的软件解决方案都将可以使用预建的构件和模板，像“ 搭积木 ”一样进行建造。

构件是一种包装对象实现的简便方法，它可以是一个部署单元，可以对一个或多个对象实现包装，也可以是一个组装单元。然后通过构件的接口，将它们互相连接起来，成为提供服务的整体。构件具有5个要素：规格说明、一个或多个实现、受约束的构件标准、包装方法和部署方法。

最常见的构件化开发方法有：RUP（Rational Unified Process），The Select Perspective Method和Sterling Software的Enterprise-CBD方法。这些方法虽然在细节上存在许多不同，但所主张的基于构件设计的抽象方法都是相同的：存储在构件库中的多种多样的构件，一种关注于接口的设计方法，以及基于构件架构的应用程序组装。面向构件的软件过程的要素如图5-3所示。

3．需求分析与设计

知识点说明：

难度系数：★★ 考查频度：★ 考查权重：★★

本知识点的重点在于掌握需求分析的任务、过程、方法、原则，以及需求的详细分类与概念；掌握系统设计的任务、过程、方法、原则，能够正确区分高层设计与详细设计的区别与联系。

知识点详解：

需求分析与设计是软件生存期中最重要的两个步骤， 需求分析 解决的是 “做什么” 的问题， 系统设计 解决的则是 “怎么做” 的问题。

（1）需求分析的任务与过程。

需求分析所要做的工作是深入地描述软件的 功能 和 性能 ，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的 数据 域。需求分析的实现步骤通常包括：获取当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统的逻辑模型三部分。具体来说，需求分析阶段的工作可以分成4个方面。

●问题识别：用于发现需求、描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，以及预先估计以后系统可能达到的目标。

●分析与综合：也就是对问题进行分析，然后在此基础上整合出解决方案。这个步骤经常是反复进行的，常用的方法有面向 数据流 的 结构化分析方法 （SA）、面向 数据结构 的Jackson方法、面向 对象 的分析方法（OOA），以及用于建立 动态 模型 的 状态迁移图 和Petri 网 。

●编制需求分析的文档：也就是对已经确定的需求进行文档化描述，该文档通常称为“需求规格说明书”。

●需求分析与评审：它是需求分析工作的最后一步，主要对功能的 正确性 、 完整 性 和 清晰性 ，以及其他需求给予评价。

（2）需求分析的原则。

●必须能够表达和理解问题的数据域和功能域。

●必须按 自顶向下 、 逐层分解 的方式对问题进行分解和不断细化。

●要给出系统的逻辑视图和物理视图。

（3）需求的分类。

什么是软件的需求呢？软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束三方面内容，如图5-4所示。

●功能需求：是指系统必须完成的事情，即为了向它的用户提供有用的功能，产品必须执行的动作。

●非功能需求：是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。

●设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如，必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统下等。

除了这三种需求之外，还有业务需求、用户需求、系统需求这三个处于不同层面下的概念，充分理解这些模型才能够使你更加清晰地理清需求的脉络。

●业务需求（Business requirement）：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。

●用户需求（User requirement）：是指描述用户使用产品必须完成什么任务，以及怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发的需求。

●系统需求（System requirement）：是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束。

我们经常围绕着“功能需求”来展开工作，而功能需求大都是从“系统需求”的角度来分析与理解的，也就是用“开发人员”的视角来理解需求。但要想真正地得到完整的需求，仅戴上“开发人员”的眼镜是不够的，我们还需要戴上“领域专家”的眼镜，从更高的角度来理解需求，这就是“业务需求”；同时我们还应该更好地深入用户，了解他们的使用场景，了解他们的所思所想，这就是“用户需求”。这是一个理解层次的问题，而不仅仅是简单的概念。

（4）需求工程。

需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，也就是指 需 求开发 和 需求管理 两大工作。

●需求开发：包括需求捕获、需求分析、编写规格说明书和需求验证4个阶段。在这个阶段需要确定产品所期望的用户类型，获取每种用户类型的需求，了解实际用户任务和目标及这些任务所支持的业务需求，分析源于用户的信息，对需求进行优先级分类，将所收集的需求编写成为软件规格说明书和需求分析模型，对需求进行评审等工作。

●需求管理：通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。

这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话说，需求开发是努力更清晰、明确地掌握客户对系统的需求，而需求管理则是对需求的变化进行管理的过程。

（5）软件设计的任务。

软件设计是把软件需求变换为软件表示的过程。最初这种表示只是描绘出软件的总体框架，然后进一步细化，在此框架中填入细节。从工程管理的角度，可将软件设计分为两步：

● 概要设计 。也称为 高层设计 ，将软件需求转化为数据结构和软件的系统结构。

● 详细设计 。也称为 低层设计 ，对结构表示进行细化，得到详细的数据结构与算法。

在整个软件设计过程中，需完成以下工作任务：制定规范（设计的共同标准）、完成软件系统结构的总体设计（将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系——模块间的组成关系）、设计处理方式（算法、性能——周转时间、响应时间、吞吐量、精度）、设计数据结构、可靠性设计、编写设计文档（概要设计说明书、数据库设计说明书、用户手册、初步的测试计划）、概要设计评审（可追溯性、接口、风险、实用性、技术清晰度、可维护性、质量、限制等）。

4．系统测试与评审

知识点说明：

难度系数：★ 考查频度：★★★ 考查权重：★

本知识点的重点在于了解软件质量的基本概念，掌握ISO/IEC 9126软件质量模型和Mc Call软件质量模型中定义的质量特性的含义，了解主要的软件质量保证措施；掌握测试的4个阶段及其任务，了解各种常见的测试种类，以及它们分别应该在什么阶段进行，掌握黑盒、白盒两种主要的测试方法论，对常见的黑盒测试技术与白盒测试技术有宏观的认识与了解。

知识点详解：

软件质量就是软件与显性与隐性需求相一致的程度。具体地说，就是软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

影响软件质量的因素主要包括人、软件需求、开发过程的各个环节、测试的局限性、质量管理的困难性、是否对质量管理予以重视、软件人员的传统习惯、开发规范和支持性的开发工具等方面。

（1）软件质量特性标准。

为了能够统一地描述软件质量特性，形成了许多质量特性标准，其中最常用的有国际通用的ISO/IEC 9126软件质量模型和McCall软件质量模型。

●ISO/IEC 9126模型。

该标准已于1996年被采纳为我国的国家标准《GB/T 16120—1996 软件产品评价、质量特性及其使用指南》，其包括以下六类21个质量特性（如表5-2所示）。

●McCall质量模型体系如图5-5所示。

McCall质量模型质量特性如表5-3所示。

（2）软件质量保证。

软件质量保证就是保证软件产品充分满足消费者要求的质量而进行的有计划、有组织的活动。它主要包括质量方针的制定和展开、质量保证方针和质量保证标准的制定、质量保证体系的建立和管理、明确各阶段的质量保证工作、各阶段的质量评审、确保设计质量、重要质量问题的提出与分析、总结实现阶段的质量保证活动、整理面向用户的文档和说明书、产品质量和质量保证系统的鉴定、质量信息的收集分析及使用。

（3）测试的阶段与任务。

为了保证系统的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格的技术评审。而软件测试是为了发现错误而执行程序的过程。

根据测试的目的、阶段的不同，可以分成许多不同的测试种类。其中最核心的是如图5-6所示的3种（如果非纯软件，则还有“系统测试”）。

●单元测试：根据详细设计说明书进行模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试，通常由开发人员自己负责。由于通常程序模块不是单独存在的，因此常常要借助 驱动模块 （相当于用于所测试模块的主程序）和 桩模块 （子模块）完成。

●集成测试：也称为组装测试、联合测试（对于子系统而言，则称为部件测试）。它主要是指将已通过单元测试的模块集成在一起，即测试模块之间的协作性。从组装策略角度而言，可以分为 一次性组装 和 增量式组装 （包括自顶向下、自底向上、混合式三种）两种。

●确认测试：也称为有效性测试，主要是指验证软件的功能、性能及其他特性是否与用户要求（需求）一致。根据用户的参与程度，通常分为4种类型。

内部确认测试：主要由软件开发组织内部按软件需求说明书进行测试，通常也称为验证测试；

α测试：由用户在开发环境下进行测试；

β测试：由用户在实际使用环境下进行测试；

验收测试：针对需求规格说明书，在交付前进行的以用户为主的测试。

●系统测试：将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行的一系列集成与确认测试。

（4）测试的种类与目的。

根据测试的目的、采用的技术、满足的需求等不同，可以将测试分成多种类型，这些概念之间相互也有一些交叠：

●设计评审：对设计方案进行正式审查，以确认其是否能够满足需求。

●代码审查：对源程序进行正式审查，以确认其是否满足设计的需要，以及能否达到预定的规范要求。

●功能测试：是指在规定的一段时间内运行软件系统的所有功能，以验证软件系统有无严重错误。

●结构测试：也称为路径测试，对软件系统内部进行逻辑测试，常使用白盒测试法。

●回归测试：用于验证软件修改后是否引出新的错误。

●可靠性测试：验证软件是否满足需求说明书中的可靠性要求，通常使用MTBF（平均无故障时间）、MTTR（平均修复时间）来衡量。

●强度测试：是指检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度。

●性能测试：是指检查系统是否满足需求规格说明书中规定的性能。

●恢复测试：是指证实在克服硬件故障后，系统能否继续正常工作。

●启动/停止测试：验证在机器启动及关机阶段，软件系统正确处理的能力。

●配置测试：检查计算机系统内各个设备或各种资源之间的相互连接和功能分配中的错误。

●安全性测试：检验系统中已有的系统安全性、保密性措施是否发挥作用，有无漏洞。

●可使用性测试：主要是从使用的合理性、方便性等角度对软件系统进行检查，以发现人为因素或使用方面的问题。

●可支持性测试：主要验证系统的支持策略对于公司与用户是否切实可行。

●安装测试：目的在于查找安装过程中的错误。

●互联测试：验证两个或多个不同的系统之间的互联性。

●兼容性测试：验证软件产品在不同版本之间的兼容性。

●容量测试：也称为压力测试，验证系统的承受能力最高能达到什么程度。

●文档测试：检查用户文档的清晰性和精确性。

（5）黑盒测试与白盒测试。

根据所采用的测试策略不同，可以将测试分为黑盒测试与白盒测试两种。

●白盒测试：又称为结构测试或逻辑驱动测试，在已知产品的内部工作过程的基础上，通过测试证明每种内部操作是否符合设计规格要求。最常见的方法是 逻 辑覆盖法 。所有可用的方法按从弱到强排序为： 语句覆盖 、 判定覆盖 、 条件覆 盖 、 判定—条件覆盖 、 条件组合覆盖 、 路径覆盖 。

●黑盒测试：在已知产品功能设计规格的基础上，通过测试证明每个实现了的功能是否符合要求。常用方法如下。

等价类划分 ：将所有可能的输入数据划分为等价的部分，然后从每个部分中选取少数有代表性的数据作为测试用例。等价类可以分为 有效等价类 （即合理的、有意义的数据集合）、 无效等价类 （即不合理的、无意义的数据集合）两种。而在选取测试用例时，应遵从“设计一个新的测试用例时，应 尽可能 多 地覆盖尚未覆盖的 有效等价类 ，但每次应 仅覆盖一个 尚未覆盖的 无效等价 类 ”的原则。

边界值分析 ：它是对等价类划分法的一个补充，即选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

错误推测法 ：列举出程序中所有可能有的错误和容易发生的错误的特殊情况，根据它们选择测试用例。

因果图 ：等价类划分、边界值分析都只考虑了输入条件，未考虑输入条件间的联系，而因果图则用来描述多种条件组合的测试用例，其最终生成的结果是 判定表 。它首先基于规格说明书分析 原因 （等价类）和 结果 （输出条件）；然后找出原因与结果之间的关系，画出因果图；再在因果图上加上约束或限制条件；将其转换为判定表；根据判定表得出测试用例。

功能图 ：它是由状态迁移图和逻辑功能模型构建的。状态迁移图用于表示输入数据序列及相应的输出数据；逻辑功能模型用于表示在状态中输入条件与输出条件之间的对应关系。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成的。

5．项目管理基础

知识点说明：

难度系数：★ 考查频度：★★★ 考查权重：★★

本知识点的重点在于了解项目管理的目标、项目计划的内容，了解各种软件估算的策略与方法，了解软件规模、工作量、成本估算的常用模型，了解项目进度计划与监控技术，掌握甘特图、PERT技术、CPM方法的关键特征，了解项目人员组织的常见方法与适用点，了解配置管理、风险管理的基本知识。

知识点详解：

项目管理是基于被接受的管理原则的一套技术或方法。这些技术或方法用于计划、评估、控制工作活动，以按时、按预算、依照规范达到理想的最终结果。项目管理的主要活动包括“POIM”4个方面：Plan（计划）、Organize（组织）、Implement（实现）、Measurement（度量）。通俗地说，在项目实施过程中的主要工作是：制订计划 （计划） ，按计划布置任务 （组织、实现） ，并在过程中不断地对进度进行监控 （度量） ，根据实际进度情况调整计划，并处理需求变更引起的项目计划变更。

（1）制订项目计划。

通俗地说，制订项目计划即回答以下问题：“需要完成什么工作？”、“哪些条件决定这些工作将按协议完成？”、“工作按什么顺序完成？”、“完成每项工作需要什么样的资源？”、“怎么安排工作进度以满足期限的要求？”。其目标是提供一个使项目管理人员 对资源、成本和进度做出合理估算 的框架。

●确定项目范围：通常包括问题/机会、项目目标、项目目的、成功标准、假设/风险/障碍5个方面的内容。

●识别项目活动：通常使用 工作分解结构 （WBS）对工作进行分级描述。它包括两种分解方式，一是纵向分解，即按时间轴分解，按工作阶段分解；二是横向分解，即按功能轴分解，按工作产品分解。在分解的过程中，可以采用自上而下（从项目目标起步逐级分解）和自下而上（先进行头脑风暴，然后进行归并整理）两种方法。

●工作量的估算：有6项技术适用于初步计划，与其他活动的相似性、历史数据、专家建议、Delphi技术（见后描述）、三点技术（估算值=[乐观估计+4×最可能估计+悲观估计]/6）、扩展Delphi技术（Delphi技术加上三点技术）。

●资源计划：资源通常包括人员、设施、设备、资金、材料等多方面，根据工作任务进行详细的计划资源投入。

●进度计划：结合工作任务、工作量、资源投入来制订项目进度计划。

（2）软件项目估算——度量。

估算的内容包括软件规模估算、软件工作量估算与成本估算三个方面。

●估算策略：包括“ 自顶向下 ”和“ 自底向上 ”两种。

自顶向下：以项目经理为核心，先根据用户、决策者的要求确定一个时间期限，然后根据该期限进行分解，将开发工作对号入座，以获得一个可以满足这个期限的估算。

自底向上：由核心小组进行头脑风暴，完成工作任务分解，然后由开发人员进行合理估算，累计得到总的估算。

●软件规模估算：即估算要完成的工作范围，常用的方法有LOC和FP估算法。

LOC估算法：代码行估算法，将项目切分为一个个小模块，通过历史项目经验、开发人员经验，估算每个模块的代码行。它操作简单、容易计算，但根据不同的编程语言没有直接的可比性。

FP估算法：FP是指功能点，是一种衡量工作量大小的单位。它的计算方法是： 功能点 = 信息处理规模 × 技术复杂度 。其中， 技术复杂度 =0.65+ 调节因子 。它首先通过外部输入数、外部输出数、外部查询数、内部逻辑文件数、外部接口文件数5个方面来衡量整个系统的 信息处理规模 ，然后根据数据通信、分布式处理、性能、配置项、事务率、在线数据、用户使用效率、在线更新、复杂处理、重用性、安装容易程度、操作容易程度、多个地点、修改容易程度等14个方面的复杂度进行微调，每个方面都在0~0.05之间取值，最后累加出 调节因子 ，再加上0.65得出 技术复杂度 。

●软件工作量估算：工作量的单位通常是人/月，计算方法为 规模 / 产能 = 工作量 。

IBM模型：是在60多个项目的基础上进行统计的静态模型。

普特南模型：它是一种动态多变量模型，通过建立一个“资源需求曲线模型”来导出一系列等式，模型化资源特性。

COCOMO模型：它是最有代表性的方法。在该模型中使用了源指令条数（DSI）、开发工作量（MM）、开发进度（TDEV）三个基本量，它将项目分为组织型（相对较小、较简单的项目）、嵌入式（软硬件限制较多的项目）、半独立型（介于两者之间，规模和复杂性中等以上）。它包括基本（静态模型）、中间、详细三种不同的模型。

●成本估算：得到工作量、人员需求、项目持续时间后，就可以进一步估算成本了，通常包括人员成本、资源成本、其他开支等。

●常用的估算辅助方法：包括Delphi法和三点法，如图5-7所示。

（3）进度计划与监控。

项目的进度安排与任何一个多重任务工作的进度安排差不多。项目的进度计划和工作的实际进展情况通常表现为各项任务之间的进度依赖关系，因而通常使用图表（甘特图、PERT技术）的方式来说明。

●甘特图：它使用水平 线段 表示任务的 工作 阶段，线段的 起点 和 终点 分别对应任务的 开工时间 和 完成时间 ，线段的 长度 表示完成任务 所需的时间 。而跟踪甘特图则是在甘特图的基础上，加上一个表示现在时间的纵线，可以直观地看出进度是否延误。甘特图的优点在于标明了各任务的 计划进度 和 当前进度 ，能动态地反映项目进展；其缺点在于难以反映多个 任务之间 存在的复杂 逻辑关系 。

●PERT技术和CPM方法：PERT叫做 计划评审技术 ，CPM方法则是 关键路径法 。它们都采用 网络图 来描述一个项目的任务网络，通常使用两张图来定义网络图。一张图给出某一特定项目的所有任务，另一张图给出应按照什么次序来完成这些任务，给出各个任务之间的衔接。PERT技术和CPM方法都为项目计划人员提供了一些定量的工具。

确定关键路径：即决定项目开发时间的任务链，即寻找到最长时间的路径；

应用统计模型：对每个单独的任务确定最可能的持续时间的估算值；

计算边界时间：为具体的任务定义时间窗口。

●评估项目进度：最常见的方法是EVA（净增值分析），它是通过计算实际已花费在项目上的工作量来预计该项目所需的成本和完成时间的一种方法。

（4）开发组织和作用。

在建立开发组织的组织结构时，可以采用三种不同的组织结构：按课题划分（即按项目划分，每个小组负责本项目的所有任务），按职能划分（根据工作阶段划分为不同的专业小组，它的缺点是各个小组间联系接口多，优点在于易于培养专才）、矩阵式（复合型，优点是有利于发挥专长，而且各个项目小组都有专人负责，有利于项目的完成，但不适合于小型开发组织）。

具体的程序设计小组的组织形式也有三种常见的结构，如表5-5所示。

（5）配置管理。

在软件项目中，存在着大量的文件与数据，而且还伴随着不可避免的变更过程，因此为了能够有效地进行控制，就需要进行“配置管理”。配置管理的对象称为 配置项 ，它是软件工程过程中所产生的所有信息项，通常包括：与合同、过程、计划和产品有关的文档和数据；源代码、目标代码和可执行代码；相关产品包括工具、可复用软件、外购软件等。

软件配置管理的任务包括：制订配置管理计划、实施变更管理、实施版本管理和发行管理。要实现变更管理需要借助 配置数据库 和 基线 ，配置数据库可以分为 开发库 （专供开发人员使用，可以频繁修改）、 受控库 （某一阶段工作结束时发布的阶段产品）、 产 品库 （完成系统测试后的软件产品）三类；而 基线 是指软件生命周期各开发阶段末尾的特定点，也称为里程碑。 版本管理 是指对系统不同版本进行标识和跟踪的过程。

（6）风险管理。

项目风险管理通常包括 风险识别 、 风险估计 和 风险驾驭 三个主要活动。风险识别的主要工作是找到潜在风险并将其文档化，它包括 项目风险 、 技术风险 和 商业风险 三种。风险估计则是通过对各种风险发生的 可能性 及 破坏性 两个方面进行评估，并按优先级进行排列。风险驾驭则是指利用某种技术，如原型化、软件自动化、软件心理学、可靠性工程学等方法，设法避开风险。 UXgOnaJ+cz+qg5Aev7OOMjA5PNwCetPoO2DO0ZL4Qejia376W/VkpdmrJkScAVyk