软件工程基础概念

软件的概念

• 软件是独立于硬件的。在早期，软件是作为计算机的零件来开发的，这时的软件是为了最大化发挥硬件作用而编写的，没有独立存在的需求。到了上世纪 $50-60$ 年代，随着计算机硬件开始进入商业应用，软件也得到了自身的发展，开始独立地被开发和使用。

• 软件是一种工具。其核心逻辑是将显示世界的复杂信息建模成计算模型，然后再利用计算机的强大计算能力和信息处理能力解决问题。即建立起问题域与解系统的桥梁。

• 软件的核心是程序。软件 = 程序 + 文档 + 数据 + 共识（知识）

• 软件的开发远比编程复杂。随着软件规模的增长，编程所占的工作比例会逐步下降，随之而来的是文档编写与缺陷清除的耗费增加。

• 应用软件源于现实高于现实。现实世界是问题的发生地，也是最终的问题解决地。

软件工程的概念

软件工程定义 必考

[$\mathrm{IEEE}610.12-1990$] 给出了软件工程的一般定义：

1. 应用系统的、规范的、可量化的方法来开发、运行和维护软件，即将工程应用到软件；
2. 对 1 中各种方法的研究。

软件工程的特点

• 软件工程是一种工程活动。它具备了所有工程学科的共同特性。

• 软件工程解决的实际问题范围广泛。相比之下，其他工程领域的问题相对受限。而软件工程解决的实际问题通常是模糊的，需要软件工程师在构造软件前花时间去澄清。

• 软件工程是科学性、实践性与工艺性并重的。它经历了从工艺到商业化再到职业化工程的演变。工程 = 科学 + 实践的原则 + 工艺（艺术）

• 软件工程追求足够好，而不是最好。软件工程都要以成本效益比有效作为生产成功的基本条件。

软件开发的活动阶段

1. 分析和设计：分析活动确定软件要做什么，即确定软件的现实世界知识和问题。设计活动利用抽象软件实体组建复杂概念结构，使之既能与现实世界形成良好互动，又能解决问题。

2. 编码、调试和编译：在特定的约束下，使用编程语言，将复杂概念结构映射和安装到通用计算机上，即进行编码、调试、编译等活动。

$\mathrm{Brooks}$ 在《人月神话》中指出，第1阶段的活动更加重要——分析和设计是软件开发的根本 $(\mathrm{essential})$ 任务，编码等活动是软件开发的次要 $(\mathrm{accidental})$​ 任务。

软件工程知识域

$\mathrm{SWEBOK}\mathrm{V}3$ 指出了软件工程的技术知识域。

软件开发活动的流程

一般的软件开发包括如下的流程

$$\begin{array}{c}\mathrm{问}\mathrm{题}\mathrm{域}\\ \stackrel{\mathrm{需}\mathrm{求}\mathrm{开}\mathrm{发}}{\to }& \mathrm{软}\mathrm{件}\mathrm{需}\mathrm{求}\mathrm{规}\mathrm{格}\mathrm{说}\mathrm{明}\\ \stackrel{\mathrm{软}\mathrm{件}\mathrm{设}\mathrm{计}}{\to }& \mathrm{软}\mathrm{件}\mathrm{构}\mathrm{件}\mathrm{方}\mathrm{案}\\ \stackrel{\mathrm{软}\mathrm{件}\mathrm{构}\mathrm{造}}{\to }& \mathrm{软}\mathrm{件}\mathrm{产}\mathrm{品}\\ \stackrel{\mathrm{软}\mathrm{件}\mathrm{测}\mathrm{试}}{\to }& \mathrm{合}\mathrm{格}\mathrm{软}\mathrm{件}\mathrm{产}\mathrm{品}\\ \stackrel{\mathrm{软}\mathrm{件}\mathrm{交}\mathrm{付}\mathrm{与}\mathrm{持}\mathrm{续}\mathrm{维}\mathrm{护}}{\to }& \mathrm{改}\mathrm{进}\mathrm{的}\mathrm{现}\mathrm{实}\mathrm{世}\mathrm{界}\end{array}$$

如何学好软件工程

67语：

外因：问题背景（职业决定、学习特殊领域的特点:嵌入式、信息系统、网络）、工具（掌握常用工具、实践）、技术和方法（课堂学习+实践巩固）。

内因：哲学与解决问题的能力、知识背景（课堂学习基础+课外大量阅读）、实践经验（多动手实践、多参与交流、多浏览专业论坛）、灵感（智力与天赋）。

软件工程的发展

时间	特点
1950s	科学计算，以机器为中心进行编程；像生产硬件一样生产软件。
1960s	业务应用；软件不同于硬件；用软件工艺的方式来生产软件。
1970s	结构化方法；瀑布模型；强调规则和纪律。
1980s	追求生产力最大化；现代化结构化方法和 OOP；重视过程的作用；《人月神话》。
1990s	以企业为中心的大规模软件系统的开发；追求快速开发、可变更性和用户价值；Web 应用开始出现。
2000 -至今	大量的 Web 应用和产品出现；持续追求快速开发、可变更性和用户价值，敏捷开发成为主流

项目管理基础

项目与项目管理

项目是具有下列特征的一系列活动和任务：具有一个明确的目标、有限定的开始和结束日期、有成本限制、消耗人力和非人力资源和多工种合作。

项目管理的目标是做到以下方面：在限定时间、一定的成本内，在要求的质量水平上高效使用资源并获得客户认可。

项目的整个过程包括项目启动、项目计划、项目执行、项目跟踪与控制和项目收尾

团队组织与管理 重点

团队的组织结构

• 主程序员团队：由主程序员来完成总体的构思和设计，然后分配给其他团队成员。但很大程度上是“个人英雄主义”，项目的工作效率比较依赖主程序员的能力。如果团队对完成项目的把握比较大，且时间要求比较紧迫，那么可以考虑主程序员团队。

• 民主团队：民主团队没有集中的交流点，所以每个成员都能发挥自己的能动性，取得更高的士气。但过多的交流可能会拖慢工作进度，在统一思想和解决冲突上也会浪费时间。敏捷过程采取民主团队。

• 开放团队：开放团队是为了创新而存在的，团队内部的交流途径是不可见或难以规范化的。团队可以按照自己认为合适的方式进行自我管理。这种团队常见于开源社区。

团队管理与建设的方法

• 建立团队章程
• 持续成功（可以是无关于项目的成功，如户外团建）
• 和谐沟通
• 避免团队杀手

软件质量保障 重点

在软件的开发过程中，要监控和执行质量保障计划；当开发活动达到一个里程碑时，要进行质量验证。主要的质量保障活动包括评审和度量。具体的质量保障活动如下表：

里程碑	质量保障活动
需求开发	需求评审、需求度量
体系结构	体系结构评审、集成测试
详细设计	详细设计评审、设计度量、集成测试
实现	代码评审、代码度量、测试
测试	测试、测试度量

评审

评审时现在公认的质量保障最佳实践方法。评审由作者之外的其他人来检查产品问题，是静态分析手段。

评审主要分为以下六个阶段。

质量度量

用数字量化的方式来描述软件产品。测度就是为了描述软件产品而提供的定量指标。进行测度的活动就称为测量。

软件配置管理

$\mathrm{IEEE}$ 将配置管理定义为 [$\mathrm{IEEE}610.12-1990$​​]：“用技术的和管理的指导和监督方法，来标识和说明配置项的功能和物理特征，控制对这些特征的变更，记录和报告变更处理及其实现状态，并验证与规格需求的一致性”。

$\mathrm{IEEE}$ 将配置项定义为 [$\mathrm{IEEE}610.12-1990$]：“置于软件配置管理之下的软件配 置的各种有关项目，包括各类管理文档、评审记录与文档、软件文档、源码及其可执行码、运行所需的系统软件和支持软件以及有关数据等”。

软件配置的动机

在软件开发活动中，除了最终产品之外，还会产生很多中间制品，例如需求规格说明、需求分析模型、软件体系结构设计模型、详细设计模型等。这些制品是不同阶段、不同⻆色、不同软件开发活动进行协同的基础。

在复杂软件系统开发中，产生的制品数量众多，以至于开发者需要维护一个清单才能清楚项目所处的状态，理解已经完成的工作和将要进行的工作。某个制品发生变化带来的最大挑战是如何确保其使用者能够得到最新的制品，避免开发协同出现问题。

基线

指已经经过正式评审的规格说明或产品，可以作为进一步开发的基础， 并且只有通过正式的变更控制过程才能变更。

配置管理活动 重点

• 标识配置项
• 版本管理（可以使用 $\mathrm{Git}$ 等工具）
• 变更控制
• 配置审计
• 状态报告
• 软件发布管理

变更控制

当软件开发到一定程度时，就需要将最新开发的内容加入基线当中，或者对基线里的内容进行更改。这时就需要进行变更控制。变更控制是版本管理中不可避免的部分，相当于项目的检查点。不仅是代码，需求、设计、测试和用户手册等绝大多数开发产物都需要进行变更控制——即所有配置项都要进行变更控制。

正式的变更控制由六个角色按严格的步骤进行。即

$$\mathrm{提}\mathrm{请}\mathrm{者}\to \mathrm{接}\mathrm{收}\mathrm{者}\to \mathrm{评}\mathrm{估}\mathrm{者}\to \mathrm{变}\mathrm{更}\mathrm{控}\mathrm{制}\mathrm{委}\mathrm{员}\mathrm{会}(\mathrm{CCB})\to \mathrm{修}\mathrm{改}\mathrm{者}\to \mathrm{验}\mathrm{证}\mathrm{者}$$

这是变更控制的流程图