第五章节——软件工程基础知识

---

一、软件工程概述

软件工程指的是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，目的是提高软件生产率、提高软件质量、降低软件成本。

1. 计算机软件

计算机软件指的是计算机系统中的程序及其文档。按照软件应用领域，将计算机软件分为以下十类

• 系统软件
• 应用软件
• 工程/科学软件
• 嵌入式软件
• 产品线软件
• Web应用软件（WebApp）
• 人工智能软件
• 开放计算
• 网络资源
• 开源软件

---

2. 软件工程基本原理

美国著名的软件工程专家B.W.Boehm于1983年提出了软件工程的七条基本原理

• 用分阶段的生命周期计划严格管理
• 坚持进行阶段评市
• 实现严格的产品控制
• 采用现代的程序设计技术
• 结果应能清楚地审查
• 开发小组的人员应少而精
• 承认不断改进软件工程实践的必要性

---

3. 软件生命周期

同其他事物一样，一个软件产品或软件系统要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期。软件生存周期包括以下七个方面：

（1）可行性分析与项目开发计划
这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有可行性分析报告、项目开发计划。

（2）需求分析
该阶段的任务不是具体的解决问题，而是要确定软件系统要做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档主要是软件需求说明书。

（3）概要设计
该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构，明确软件由哪些模块组成 ，这些模块层次结构是怎样的，调用关系是怎样的，每个模块的功能是什么。参与该阶段的人员有系统分析师、软件设计师。产生的文档主要是概要设计说明书。

（4）详细设计
该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。参与该阶段的人员有软件设计师、程序员。产生的文档主要是详细设计文档。

（5）编码
把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。

（6）测试
测试是保证软件质量的重要手段。参加测试的人员通常是另一部门(或单位〉的软件设计师或系统分析师。产生的文档主要是软件测试计划、测试用例、测试报告。

（7）维护
软件维护是软件生存周期中时间最长的阶段。软件己交付且正式投入使用后，便进入维护阶段。
对软件进行修改的原因包括: ①运行中发现隐含的错误而需要修改②为了适应变化的(或变化后的工作环境而修改③需要对软件功能进行扩充、增强而进行的修改④为将来软件维护活动做预先准备。

文档是软件开发使用和维护中的必备资料。文档能提高软件开发的效率，保证软件的质量，而且在软件的使用过程中有指导、帮助、解惑的作用，尤其在维护工作中，文档是不可或缺的资料。

---

4. 软件过程

软件开发中遵循一系列可预测的步骤（即路线图），该路线图称为“软件过程”。过程是活动的集合，活动是任务的集合。
软件过程的能力成熟度模型:
（1）能力成熟度模型CMM
能力成熟度模型CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。将软件过程改进分为五个成熟度级别

（1）能力成熟度模型CMMI

CMMI是若干过程模型的综合和改进，是支持 多个工程学科 和领域的、系统的、一致的过程改进框架。CMMI提供了两种表示方法：阶段式模型和连续式模型。
阶段式模型。 结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版本中有五个成熟度等级。

1. 初始级: 过程不可预测且缺乏控制。
2. 已管理级: 过程为项目服务。
3. 已定义级: 过程为组织服务。
4. 定量管理级: 过程已度量和控制。
5. 优化级: 集中过程改进。

连续式模型 关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（简称CL）。CMMI中包括六个过程域能力等级。

1. CL₀ (未完成的)﹔过程域未执行。
2. CL₁ (已执行的): 其共性目标是过程将可标识的输入工作产品转换成可标识的工作产品
3. CL₂ (已管理的): 其共性目标集中于已管理的过程的制度化。
4. CL₃ (已定义级的): 其共性目标集中于已定义的过程的制度化。
5. CL₄ (定量管理的）: 其共性目标集中于可定量管理的过程的制度化。
6. CL₅ (优化的): 使用量化手段改变和优化过程域。

二、软件过程模型

软件过程模型习惯上称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型)、喷泉模型、基于构件的开发模型、形式化方法模型和统一过程模型等。

1. 瀑布模型

瀑布模型将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。如同瀑布流水逐级下落，如下图所示。瀑布模型以项目的阶段性评审和文档控制为手段有效地对整个开发过程进行指导，所以它是
以文档作为驱动、适合软件需求很明确的软件项目的开发。

• 优点: 容易理解、成本低、强调开发的阶段性早期计划及需求调查和产品测试。
• 缺点: 客户必须能完整、正确和清晰地表达需求;难以评估项目进度状态;项目快结束时，出现大量的集成与测试工作;需求或设计的错误往往只有到了项目后期才能被发现，对项目风险的控制能力较弱，通常会导致项目延期，开发费用超出预算。

---

2. 增量模型

增量模型将需求分段为一系列产品，每一个增量都可以分别开发，如下图。

• 优点： 第一个可交付的版本成本和时间很少。开发由增量表示的小系统所承担的风险不大;由于很快发布了第一个版本，因此可减少用户需求的变更。同时，它也具有瀑布模型所有的优点。
• 缺点： 若没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定;若需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发或重新发布;管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

---

3. 演化模型（原型模型、螺旋模型)

经典的演化模型有原型模型和螺旋模型。演化模型适用于软件需求不够明确的情况。

原型模型（快速原型模型）：
原型是预期系统的一个可执行版本。原型模型开始于沟通，目的是定义软件的总体日标、标识需求，然后快速构建原型并交付用户使用，收集客户反馈意见，并在下一轮中对原型进行改进。原型模型适用于用户需求不明确、需求经常变化且系统规模不太大、不太复杂的软件项目。

螺旋模型：
对于一个复杂的大项日，开发一个原型往往达不到要求。螺旋模型将瀑布模型和原型模型结合起来，加入两种模型均忽略的风险分析，弥补了这两种模型的不足。螺旋模型中的每个螺旋周期分为以下四个步骤:①制订计划:确定软件目标，选定实施方案，明确项日开发的限制条件。②风险分析:对所选方案进行分析，识别风险，消除风险。③实施工程:实施软件开发，验证阶段性产品。④用户评估:评价开发工作，提出修正建议，建立下一个周期的开发计划。螺旋模型强调风险分析，与瀑布模型相比，支持用户需求的动态变化。螺旋模型适合用于庞大、复杂且具有高风险的系统。

---

4. 喷泉模型

喷泉模型是以用户需求为动力，以对象为驱动的模型，适用于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。喷泉模型如下图所示。

• 优点： 各个阶段没有明显的界线，开发人员可以同步进行;可以提高软件项目的开发效率，节省开发时间。
• 缺点： 由于在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理;要求严格管理文档，使得审核的难度加大。

---

5. 基于构建的开发模型

基于构件的开发模型是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件,也可以是商品化成品软件构件。基于构建的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。其不同之处在于基于构件的开发模型采用预先打包的软件构建开发应用系统。

构件是面向软件体系架构的可复用软件模块。构件(Component）是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、功能模块、软件框架（Framework)、软件架构、文档、设计模式等。

---

6. 形式化方法模型

形式化方法是建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。

---

7. 统一过程（UP）模型

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并增量”的开发过程，由方法和工具支持。统一过程定义了四个技术阶段及其主要工作产品:
(1）起始阶段： 专注项目的初创活动，主要工作产品有构想文档、初始用例模型、初始项日术语表、初始业务用例、初始风险评估、项目计划、业务模型及多个原型（需要时）。
(2）精化阶段： 主要工作产品有用例模型、补充需求、分析模型、整体体系结构描述、可执行的软件休系结构原型、初步设计模型、修订的风险列表、项目计划及初始用户手册。
(3）构建阶段： 关注系统的构建，产生实现模型，主要工作产品有设计模型、软件构件、集成软件增量、测试计划及步骤、测试用例及支持文档（用户手册、安装手册等）。
(4）移交阶段： 关注软件提交方面的工作，产生软件增量，主要工作产品有提交的软件增量、测试报告和综合用户反馈。统一过程的典型代表是RUP (Rational Unified Process），RUP是UP的商业扩展，完全兼容UP，比UP更完整、更详细。

---

8. 敏捷方法

敏捷方法的总体目标是通过“尽可能早地、持续地对有价值的软件进行交付”使客户满意。敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念，即敏捷宣言。常用的敏捷方法：

1. 极限编程（XP)：四大价值观：沟通、简单性、反馈和勇气。
2. 水晶法(Crystal)：认为人对软件质量有重要的影响，随着开发人员素质的提高，项目和过程的质量〈<也随之提高。
3. 并列争球法(Scrum)：使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
4. 自适应软件开发(ASD)：是一种敏捷软件开发方法，倡导根据需求的变化及时调整开发过程，实现软件开发的自适应性能力。
5. 敏捷统一过程(AUP)：采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。

---

三、需求分析

需求分析 也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式化的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

1. 软件需求

软件需求包括以下内容：

• 功能需求： 考虑系统要做什么，什么时候做，如何修改或升级。
• 性能需求： 考虑软件开发的技术性指标，如存储容量限制，执行速度，响应时间，吞吐量等。
• 用户或人的因素： 考虑用户的类型
• 环境需求： 考虑软件应用的环境
• 界面需求： 考虑来自其他系统的输入或到其他系统的输出等
• 文档需求： 考虑需要那些文档，文档针对那些读者
• 数据需求： 考虑输入，输出格式，接收，发送数据的频率，数据的精准度，数据流量，数据保持时间。
• 资源使用需求： 考虑软件运行时所需要的资源/
• 安全保密需求： 考虑是否需要对访问系统或系统信息加以控制。
• 可靠性需求： 考虑系统的可靠性需求，系统是否必须检测和隔离错误，错误后重启系统所允许的时间等。
• 软件成本消耗或开发进度需求： 考虑开发是否有规定的时间表
• 其他非功能性需求： 如采用某种开发模式，确定质量控制标准，里程碑和评审，验收标准等。

2. 需求分析原则

需求分析过程有不同的分析方法，它们要遵循的操作原则有：

• 必须能表示和理解问题的信息域。
• 必须能定义软件将完成的任务。
• 必须能表示软件的行为。
• 必须划分描述数据、功能和行为的模型。
• 分析过程应该从要素信息移向细节信息。

3.需求工程

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程可以细分为六个阶段:

1. 需求获取。
2. 需求分析与协商。
3. 系统建模：模型以一种简洁、准确、结构清晰的方式系统地描述软件需求。常用的需求分析方法有：面向数据流的结构化分析方法SA，面向对象的分析方法OOA。
4. 需求规约;通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求，作为用户和开发者之间的一个协议。
5. 需求验证;其目的是要检验需求功能的正确性、完整性和清晰性，是否能够反映用户的意愿。
6. 需求管理。

四、系统设计

进入设计阶段，要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型。系统设计的主要内容包括新系统总体结构设计、代码设计、输入设计、输出设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。主要目的就是为系统制定蓝图。常用的设计方法有:面向数据流的结构化设计方法(SD)、面向对象的设计方法（OOD)。系统设计包括两个基本的步骤:概要设计、详细设计。

1. 概要设计

概要设计主要包括：

1. 软件系统总体结构设计：将系统按功能划分成模块;确定每个模块的功能;确定模块之间的调用关系;确定模块之间的接口，即模块之间传递的信息;评价模块结构的质量。
2. 数据结构及数据库设计，如E-R图。
3. 编写概要设计文档：概要设计说明书、数据库设计说明书、用户手册及修订测试计划。
4. 评审。

2. 详细设计

详细设计主要包括：

1. 对每个模块进行详细的算法设计
2. 对模块内部的数据结构进行设计
3. 对数据库进行物理设计，即确定数据库的物理结构
4. 其他设计（代码设计，输入/输出设计，用户界面设计）
5. 编写详细设计说明书
6. 评审

系统设计的结果是一系列的系统设计文件，这些文件是物理实现一个信息系统（包括硬件设备和编制软件程序）的重要基础。

五、系统测试

1. 系统测试与调试

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

测试的目的是以最少的人力和时间发现潜在的各种错误和缺陷。信息系统测试包括软件测试、硬件测试、网络测试。
测试应遵循的基本原则： ①应尽早并不断地进行测试;②测试工作应避免原先开发软件的人员或小组参与;③设计测试方案时要确定输入数据，还要根据系统功能确定预期的输出结果;④设计测试用例时要设计合理、有效的输入条件，还要包含不合理、失效的输入条件。人们在测试时通常忽略了对异常、不合理、意想不到的情况进行测试，这可能就是隐患;⑤在测试时要检查程序是否做了该做、不该做的事，多余的工作会影响程序的效率;⑥严格按照测试计划进行测试;⑦妥善保存测试计划、测试用例;⑧要精心设计测试用例。

测试的过程包括：①制定测试计划;②编制测试大纲;⑧根据测试大纲设计和生产测试用例;④实施测试;⑤生成测试报告。

---

2. 传统软件测试策略

软件测试分为四步：单元测试，集成测试，确认测试和系统测试

（1）单元测试
单元测试特称模块测试，在模块编写完成且编译无误后进行，侧重于模块中的内部逻辑和数据结构。单元测试环境如下图，由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发两种模块：
驱动模块：相当于一个主程序
桩模块：用来代替测试模块中所调用的子模块

---

(2) 集成测试
集成测试就是把模块按系统设计说明书的要求组合起来进行测试。
集成测试通常有以下两种方法:

1. 非增量集成： 分别测试各个模块，再将这些模块组合起来进行整休测试。
2. 增量集成： 以小增量的方式逐步进行构造和测试。

常用的增量集成策略包括:自顶向下集成测试、自底向上集成测试、回归测试、冒烟测试等。

---

（3）确认测试

确认测试始于集成测试的结束，即已测试完单个构件，软件已经组装成完整的软件包，而且接口错误已被发现和改正。确认过程的一个重要成分是配置评审，主要检查软件、文档、数据是否齐全、分类是否有序。

当为客户开发软件时，执行一系列验收测试能使客户确认所有的需求，验收测试是由用户而不是软件工程师进行的。

α测试：最终用户在开发者的场所进行测试。
β测试：在一个或多个最终用户场所执行，与α测试不同，开发者通常不在场。

---

（4）系统测试

系统测试是将已经确认的软件、硬件、外设、网络等其他因素结合在一起，进行各种集成测试和确认测试。目的是通过与系统的需求(SRS）进行比较，发现所开发的系统与用户需求不符或矛盾的地方。主要包括恢复测试、安全性测试、压力测试、性能测试、部署测试。

3. 测试方法

软件测试分为静态测试和动态测试。

• 静态测试： 被测程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行测试，包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试，包括桌前检查、代码审查、代码走查的方式。使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误。
• 动态测试： 通过运行程序发现错误，一般采用黑盒测试和白盒测试。

（1）黑盒测试

也称功能测试 ，在不考虑软件内部结构和特性的情况下，测试软件的外部特性。
常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。

• 等价类划分：将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。等价类划分有两种：有效等价类(对于需求规格来说合理的数据集合)和无效等价类(对于需求规格来说异常的数据集合)。

• 边界值分析：是对等价类划分方法的补充。边界值分析选择等价类边界的测试用例。所谓边界值，是指相对于输入等价类和输出等价类而言，稍高于其最高值或稍低于最低值的一些特殊情况。边界值分析的步骤包括确定边界，选择测试用例两个步骤。
  例如，如果程序的规格说明中规定:“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为…”。作为测试用例，我们应取10至50，还应取9.99，10.01，49.99以及50.01等

• 错误推测：基于经验和直觉推测程序中所有可能存在的各种错误。

• 因果图：从自然语言描述的程序规格说明中找出因（输入条件）和果（输出或程序状态的改变)，通过因果图转换为判定表。因果图(Cuase-effect Graph）是一种描述输入条件的组合及每种组合对应的输出的图形化工具。在因果图的基础上可以设计测试用例。

（2）白盒测试
也称结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。常用的白盒测试技术有逻辑覆盖、循环覆盖和基本路径测试。
逻辑覆盖：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

• 语句覆盖(SC)：是指选择足够多的测试用例，使被测程序的每条语句至少执行一次。语句覆盖是一种很弱的逻辑覆盖。
• 判定覆盖（DC)：又称分支覆盖，是指设计足够的测试用例，使得不仅每条语句至少执行一次，而且每个判定表达式的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强。
• 条件覆盖(CC）：是指设计一组测试用例，不仅每条语句至少执行一次，而且使判定表达式中的每个条件的所有可能的值至少满足一次。条件覆盖不一定包含判定覆盖、判定覆盖也不一定包含条件覆盖。
• 判定/条件覆盖(CDC)：是指同时满足判定覆盖和条件覆盖的逻辑覆盖。设计足够的测试用例,使得判定表达式中每个条件的所有可能的值至少满足一次，而且每个判定本身的所有可能结果也至少出现一次。
• 条件组合覆盖（MCC)：设计足够的测试用例，使得每个判定表达式中条件的所有值的组合都至少出现一次。满足条件组合覆盖的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖。
• 路径覆盖：设计足够的测试用例，覆盖被测程序中所有可能的路径（如果程序中有环路，则要求每条环路至少经过一次）。路径覆盖考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。

4. 调试

调试发生在测试之后，其任务是根据测试时所发现的错误找出原因和具体的位置，进行改正，改正后要进行回归测试。调试工作主要由程序开发人员进行，谁开发的程序就由谁来进行调试。日前常用的调试方法有以下五种：
(1）试探法： 调试人员分析错误的症状，猜测问题所在的位置，一步步试探和分析问题所在。该方法效率氐，适用于结构比较简单的程序。
(2）回溯法： 调试人员从发现错误的位置开始，人工沿着程序的控制流程往回追踪代码，直到找出问题根原为止。该方法适用于小型程序。
(3）对分查找法： 该方法主要用来缩小错误范围，直到把故障范围缩小到比较容易诊断为止。
(4)归纳法： 从测试所暴露的问题出发，收集所有正确、不正确的数据，并分析它们之间的关系，提出假识的错误原因，用这些数据证明或反驳，从而查出错误所在。
(5）演绎法： 根据测试结果，列出可能的错误原因，分析已有的数据，排除不可能和彼此矛盾的原因。若多个错误同时存在，就要重新分析，提出新的假设，直到发现错误为止。

六、运行和维护

1. 系统转化

一个系统开发完成后，让它实际运行一段时间，是对系统最好的检验和测试方法。
新旧系统之间的转换方法有直接转换、并行转换和分段转换。

• 直接转换：直接启用新系统，终止旧系统。适用于一些处理过程不太复杂、数据不太重要的场合。
• 并行转换：新旧系统并行工作一段时间，经过一段时间的考验后，新系统正式替代旧系统■适用于较复杂的大型系统。主要特点是安全、可靠，但费用和工作量都很大。
• 分段转换：直接转换和并行转换的结合。在新系统全部正式运行前，一部分一部分地替代旧系统。既保证了可靠性，又不至于费用太大。

2. 系统维护概述

系统维护是在软件已经交付使用之后为了改正错误或满足新的需求而修改软件的过程。系统可维护性的评价指标有可理解性、可测试性和可修改性。文档是软件可维护性的决定因素。

系统维护主要包括硬件维护、软件维护和数据维护。软件维护的内容：

• 正确性维护：改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。占整个维护工作量的17%~21%。修正BUG、错误。
• 适应性维护：使应用软件适应信息技术变化和管理需求变化而进行的修改。占整个维护工作量的18%~25%。应变。
• 完善性维护：为扩充功能和改善性能而进行的修改。占整个维护工作的50%~60%。新需求。
• 预防性维护：为改进应用软件的可靠性和可维护性，为适应未来的软/硬环境的变化，应主动增加预防性的新功能，以使应用系统适应各类变化而不被淘汰。占整个维护工作量的4%左右。针对未来。

七、软件项目管理

1. 软件项目管理涉及的范围

有效的软件项日管理集中在4P上：人员(Person)、产品(Product)、过程(Procedure)、项目(Project）。

1. 人员：参与项目的人员类型有项目管理人员、高级管理人员、开发人员、客户、最终用户。
2. 产品：开展项目计划之前，应先进行项目定义，即定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术、管理约束等。
3. 过程：对于软件项目来说，强调的是对其进行过程控制，通常将项目分解为任务、子任务等。
4. 项目：常见的软件项目办法有明确目标及过程、保持动力、跟踪进展、作出明智的决策、进行事后分析。

---

2. 软件项目估算

软件项目估算涉及人、技术、环境等多种因素，因此很难在项目完成前准确地估算出开发软件所需的成本、持续时间和工作量。常用的估算方法有三种：基于已经完成的类似项目进行估算、基于分解技术进行估算、基于经验估算模型的估算。

（1）成本估算方法
常见的成本估算方法有白顶向下估算方法、自底向上估算方法、差别估算方法、专家估算法、类推估算法和算式估算法等。

（2）COCOMO模型
COCOMO模型是一种精确的、易于使用的成本估算模型。其公式如下:
E=a(L)^b，D = cE^d
其中，E表示工作量，单位是人月；D表示开发时间，单位是月；L是项目的源代码行估计值，单位是千行代码；a、b、c、d都是常数。

（3）COCOMOⅡ模型
COCOMOⅡ模型也是一种基于层次结构的估算模型，分为3个阶段性模型：应用组装模型（基于对象点数量进行估算)、早期设计阶段模型（基于功能点数量进行估算）和体系结构阶段模型（基于早期架构设计，也是基于功能点数量进行估算）。

（4）Putnam估算模型
Putnam模型是一种动态多变量模型，它是假设在软件开发的整个生存周期中工作量有特定的分布。

---

3. 进度管理

进度管理的目的是确保软件项目在规定的时间内按期完成。进度安排的常用图形描述方法有甘特图(GanttChart）和项目计划评审技术图(PERT)。

（1）甘特图
Gantt图是一种简单的水平条形图，它以日历为基准描述项目任务。横坐标表示时间，纵坐标表示任务，图中的水平线段表示对一个任务的进度安排，线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间，线段的长度表示完成该任务所需的时间。

• 优点：能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。
• 缺点：不能清晰地反映出各个任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。

---

（2）项目活动图（PERT图）

下面是一个软件项目的活动图(PERT图)，顶点表示里程碑，连接顶点的边表示活动，边上的权重表示完成该活动所需要的时间(天）。

关键路径：从开始顶点到结束顶点之间距离最长的一条路径。关键路径上的长度就是完成整个工程项目的最短工期。松弛时间:最迟开始时间-最早开始时间，最迟开始时间从后往前推（关键路径长度-该活动开始顶点到项目活动图的结束顶点的最长长度)，最早开始时间从前往后推（等于项目活动图的开始顶点到该活动开始顶点的最长长度)，或者关键路径的总时间-包含该活动的最长路径的总时间。关键路径上的活动的松弛时间均为0。

---

4. 软件项目的组织

开发组织采用什么形式，不仅要考虑到项目的特点，还要考虑参与人员的素质。软件项目组织的原则有：①尽早落实责任；②减少交流接口；③责权均衡。

程序设计小组的组织方式：
(1) 主程序员制小组
由一名主程序员、若干名程序员、一名后援工程师和一名资料员组成。主程序员通常由高级工程师承担突出主程序员的领导作用，小组内的通信主要体现在主程序员与程序员之间。

(2）民主制小组
小组成员之间地位平等，工作日标和决策由全体成员决定，这种形式的组内通信路径较多。

(3）层次式小组
由一名组长领导若干名高级程序员，每名高级程序员领导若干名程序员。组长通常是项日负责人，负责全纽的技术工作，进行任务分配，组织评审。高级程序员负责项目的一个部分或一个子系统。

5. 软件项目配置

软件配置管理(SCM）用于整个软件工程，主要目标是识别变更、控制变更、确保变更正确实现、报告有关变更。

• 基线： 基线即软件生存周期中各个开发阶段的一个特定点，作用是将各阶段的工作划分更加正确。
• 软件配置项： 软件配置项(SCI）是配置管理的基本单位，对己经成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。
• 版本控制： 版本控制实际上是一个动态的概念，一方面随着软件生存周期向前推进，SCI的数量在不断增加，一些文档经过转换生成另一些文档，并产生一些信息:另一方面又随时会有新的变更出现，形成新的版木。
• 变更控制： 对软件配置的变更加以控制和管理。是一项最重要的软件配置任务。

6. 风险管理

软件风险包括两个特性:不确定性和损失。不确定性是指风险可能发生也可能不发生;损失是指风险发生后会产生的恶性后果。常见的商业风险有:市场风险、策略风险、销售风险、管理风险、预算风险。

• **风险识别：**当识别出已知风险和可预测风险后，项日管理者首先要做的是尽可能回避这些风险，在必要时控制这些风险。风险因素可以定义为:性能风险、成本风险、支持风险、进度风险。
• **风险预测：**风险预测又称为风险估计，它试图从两个方面评估一个风险:风险发生的可能性或概率;风险发生后所产生的后果。
• **风险评估：**一种对风险评估很有用的技术就是定义风险参考水准。对于大多数软件项日来说，成本、进度和性能就是3种典型的风险参考水准。
• **风险控制：**应对风险最好的办法是主动地避免风险，即在风险发生前分析引起风险的原因，然后采取措施避免风险的发生。

八、软件质量

1. 软件质量特性

软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。讨论软件质量首先要了解软件的质量特性，在ISO/IEC 9126中，软件质量模型由三个层次组成，第一层为质量特性，第二层为质量子特性，第三层为度量指标，如下图所示。

2. 软件质量保证

• 软件质量保证(Software Quality Assurance，SQA）是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。
• 在软件质量方面强调以下三个要点:
  ①软件必须满足用户规定的需求②软件应遵循规定标准所定义的一系列开发准则③软件还应满足某些隐含的需求。
• 软件质量保证包括与以下七个主要活动相关的各种任务:
  ①应用技术方法②进行正式的技术评审③测试软件④标准的实施⑤控制变更⑥度量⑦记录、保存和报告。

3. 软件评审

软件评审的内容包括以下三个方面：

• 设计质量的评审： 包括评审软件的规格说明书是否符合用户的要求;评审可靠性;评审保密措施的实施情况;评审操作特性的实施情况;评审性能;评审软件是否具有可修改性、可扩充性、可互换性和可移植性;评审软件可测试性;评审软件可复用性。
• 程序质量的评审： 从开发者的角度进行评审，与开发技术直接相关，着眼于软件本身的结构与运行环境的接口，以及变更带来的影响。
• 与运行环境的接口： 运行环境包括硬件、其他软件和用户，主要检查项目与硬件的接口，与用户的接口

4. 软件容错技术

提高软件质量和可靠性的技术大致分为两类：避开错误和容错技术。实现容错的主要手段是冗余，常见的冗余技术有:

• 结构冗余： 又分为静态冗余、动态冗余和混合冗余。
• 信息冗余： 为检测或纠正正在运算或传输中的信息错误需外加的一部分信息。
• 时间冗余： 以重复执行指令或程序来消除瞬时错误带来的影响。
• 冗余附加技术： 为实现上述冗余技术所需要的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。

九、软件度量

1. 软件度量分类

软件度量用于对产品及开发产品的过程进行度量，如成本、效益、开发人员的生产率、可靠性、可维护性等。软件度量的方法：
（1）面向规模的度量
面向规模的度量主要是通过对质量和生产率的测量进行规范化得到的，而这些量都是根据开发过的软件的规模得到的。面向规模的度量公式如下表所示

（2）面向功能的度量
面向功能的度量以功能测量数据为规范化值。应用最广泛的面向功能的度量是功能点(FP）。功能点是根据软件信息域的特性及复杂性来计算的。

2. 软件复杂性度量

软件复杂性度量是指理解和处理软件的难易程度。软件复杂性度量的参数有很多，主要包括：①规模；②难度；③结构；④智能度。软件复杂性包括程序复杂性和文档复杂性。
典型的程序复杂性度量有McCabe环路复杂性度量和Halstead复杂性度量。
McCabe度量法是一种基于程序控制流的环路复杂性度量方法，以图论为工具，先画出程序图退化的程序流程图），然后用该图的环路数作为程序复杂性的度量值。

在一个强连通的有向图G中，环路的个数V(G)山以下公式给出：
V(G) = m - n+ 2p
其中，V(G)是有向图G中的环路数，m是图G中弧的个数，n是图G中的结点数，p是G中的强连通分量个数。

McCabe环路复杂性度量定量给出了程序的逻辑复杂度，还可以用下述3种方法中的任何一种来计算环路复杂度：
（1）程序图G中的区域数等于环路复杂度（封闭区域数+1（一个非封闭区域））。
（2）程序图G的环形复杂度V(G)= E - N＋2，其中，E是程序图中边的条数，N是结点数。
（3）程序图G的环形复杂度V(G) = P+ 1，其中，P是程序图中判定结点(有2条输出弧）的数目。有n (n>2)条输出弧的判定结点对应程序中的n-1个判断。 (个人感觉方法（3）最好用，又快又简单)

十、软件工具与软件开发环境

（1）软件工具
对应于软件开发的各种活动，软件开发工具通常有需求分析工具、设计工具、编码与排错工具、测试工具等。

（2）软件开发环境
软件开发环境(Software Development Enviromment）指支持软件产品开发的软件系统，它由软件工具集和环境集成机制构成。