第20、21章 软件交付、软件维护与演化

1.软件维护的重要性

（1）由于会出现新的需求，如不维护软件将减小甚至失去服务用户的作用。
（2）随着软件产品的生命周期越来越长，在软件生存期内外界环境发生变化的可能性越来越大，因此，软件经常需要修改以适应外界环境的改变
（3）软件产品或多或少的会有缺陷，当缺陷暴露出来时，必须予以及时的解决

2.开发可维护软件的方法

（1）考虑软件的可变性：分析需求易变性、为变更进行设计
（2）为降低维护困难而开发：编写详细的技术文档并保持及时更新、保证代码可读性、维护需求跟踪链、维护回归测试基线

3.演化式生命周期模型

初步开发—演化—服务—逐步淘汰—停止

（1）初步开发

初始开发阶段按照传统的软件开发方式完成第一个版本的软件产品开发。第一版的软件产品可以实现全部需求，也可以（通常是）只包含部分需求——对用户来说非常重要和紧急的最高优先级需求。

（2）演化

可能会有预先安排的需求增量，也可能完全是对变更请求的处理，它们的共同点都是保持软件产品的持续增值，让软件产品能够满足用户越来越多的需要，实现更大的业务价值。
总的来说，该阶段可能的演化增量有：预先安排的需求增量；因为问题变化或者环境变化产生的变更请求；修正已有的缺陷；随着用户与开发者之间越来越相互熟悉对方领域而新增加的需求。
演化阶段的软件产品要具备两个特征：(1) 软件产品具有较好的可演化性。一个软件产品在演化过程中复杂性会逐渐增高，可演化性会逐渐降低直至无法继续演化。演化阶段的软件产品虽然其可演化性低于初始开发阶段的软件产品，但是还没有到达无法演化的地步，还具有较好的可演化性。(2) 软件产品能够帮助用户实现较好的业务价值。只有这样，用户才会继续需要该产品，并持续提供资金支持。
如果在演化过程中，一个软件产品开始不满足第（2）条特征，那么该产品就会提前进入停止阶段。如果软件产品满足第（2）条的同时不满足第（1）条特征，那么该产品就会进入服务阶段。如果开发团队因为竞争产品的出现或者其他市场考虑，也可以让同时满足上面两条特征的软件产品提前进入服务阶段。

（3）服务

服务阶段的软件产品不再持续的增加自己的价值，而只是周期性的修正已有的缺陷。
服务阶段的产品还仍然被用户使用，因为它仍然能够给用户提供一定的业务价值，所以开发团队仍然需要修正已有缺陷或者进行一些低程度的需求增量，保证用户的正常使用。

（4）逐步淘汰

在逐步淘汰阶段，开发者已经不再提供软件产品的任何服务，也即不再继续维护该软件。虽然在开发者看来软件的生命周期已经结束，但是用户可能会继续使用处于该阶段的软件产品，因为它们仍然能够帮助用户实现一定的业务价值。只是用户在使用软件时必须要容忍软件产品中的各种不便，包括仍然存在的缺陷和对新环境的不适应。对于该阶段的产品，开发者需要考虑该产品是否可以作为有用的遗留资源用于新软件的开发，用户需要考虑如何更换新的软件产品并转移已有的业务数据。

（5）停止

一个软件正式退出使用状态之后就进行停止状态。开发者不再进行维护，用户也不再使用。

4.用户文档、系统文档

（1）用户文档：这里的文档支持是指为用户编写参考指南或者操作教程，常见的如用户使用手册、联机帮助文档等，统称为用户文档。
文档内容的组织应当支持其使用模式，常见的是指导模式和参考模式两种。指导模式根据用户的任务组织程序规程，相关的软件任务组织在相同的章节或主题。指导模式要先描述简单的、共性的任务，然后再以其为基础组织更加复杂的任务描述。
参考模式按照方便随机访问独立信息单元的方式组织内容。例如，按字母顺序排列软件的命令或错误消息列表。如果文档需要同时包含两种模式，就需要将其清楚地区分成不同的章节或主题，或者在同一个章节或主题内区分为不同的格式。

（2）系统文档：更注重系统维护方面的内容，例如系统性能调整、访问权限控制、常见故障解决等等。因此，系统管理员文档需要详细介绍软硬件的配置方式、网络连接方式、安全验证与访问授权方法、备份与容灾方法、部件替换方法等等。

5.逆向工程、再工程

（1）逆向工程：分析目标系统，标识系统的部件及其交互关系，并且使用其它形式或者更高层的抽象创建系统表现的过程。逆向工程的基本原理是抽取软件系统的需求与设计而隐藏实现细节，然后在需求与设计的层次上描述软件系统，以建立对系统更加准确和清晰的理解。
（2）再工程：检查和改造一个目标系统，用新的模式式及其实现复原该目标系统。目的是对遗留软件系统进行分析和重新开发，以便进一步利用新技术来改善系统或促进现存系统的再利用。
主要包括：改进人们对软件的理解；改进软件自身，通常是提高其可维护性、可复用性和可演化性。
常见具体活动有：重新文档化；重组系统的结构；将系统转换为更新的编程语言；修改数据的结构组织。

第22、23章 软件开发过程模型

1.软件生命周期模型

需求工程—软件设计—软件实现—软件测试—软件交付—软件维护

2.解释与比较不同的软件过程模型

【题型】对给定场景，判断适用的开发过程模型（要求、特征描述、优点、缺点）

（1）构建-修复模型

特征：a.没有对开发过程进行规范和组织，因此一旦开发过程超出个人控制能力，就会导致开发过程无法有效进行而失败。
b.对需求的真实性没有进行分析
c.没有考虑软件结构的质量，导致结构在修改中越来越糟，直至无法修改
d.没有考虑测试和程序的可维护性，也没有任何文档，导致难以维护
适用场景：软件规模很小，只需要几百行程序，其开发复杂度是个人能力能够胜任的；软件对质量的要求不高，即使出错也无所谓；只关注开发活动，对后期维护的要求不高，甚至不需要进行维护。

（2）瀑布模型（文档驱动）

特征：a.对于软件开发活动有明确阶段划分
b.每个阶段的结果都必须验证，使得该模型是“文档驱动”
优点：清晰的阶段划分有利于开发者以关注点分离的方式更好的进行复杂软件项目的开发。
缺点：a.对文档期望过高；
b.对开发活动的线性顺序假设（线性顺序与迭代相反）；
c.客户、用户参与度不够（需求被限制在一个时间段）
d.里程碑粒度过粗（软件复杂使得每个阶段时间长，无法尽早发现缺陷）
适用：需求非常成熟、稳定，没有不确定的内容，也不会发生变化；所需的技术成熟、可靠，没有不确定的技术难点，也没有开发人员不熟悉的技术问题；复杂度适中，不至于产生太大的文档负担和过粗的里程碑。

（3）增量迭代模型（需求驱动）与演化模型互为补充

特征：项目开始时，通过系统需求开发和核心体系结构设计活动完成项目的前景范围的界定，然后将后续开发活动组织为多个迭代、并行的瀑布式开发活动。第一个迭代完成的往往是核心工作，满足基本需求，后续迭代完成附带特性。
优点：a.更符合软件开发实践
b.并行开发可以缩短产品开发时间
c.渐进交付可以加强用户反馈，降低开发风险。
缺点：a.要求高：软件需要有开放式的体系结构
b.不确定性太多，导致难以在项目开始就确定前景和范围
适用：比较成熟和稳定的领域

（4）演化模型（需求驱动）

特点：更好地应对需求变更，更适用于需求变更比较频繁或不确定性较多的领域。将软件开发组织为多个迭代、并行的瀑布式开发活动。是迭代＋并行＋渐进
优点：a.适用于需求变更频繁或者不确定性多的系统的开发
b.并行开发可以缩短开发时间
c.加强用户反馈，降低开发风险
缺点：a.无法在项目早起确定项目范围
b.后续迭代活动以前导迭代为基础，容易使后续迭代忽略分析与设计。退化为构建－修复方式。
适用：不稳定领域的大规模软件系统

（5）原型模型（需求驱动）

特点：大量使用抛弃式原型（抛弃式原型：通过模拟“未来”的产品，将“未来”的知识置于“现在”进行推敲，解决不确定性）。
优点：a.加强与客户、用户的交流，更好的产品满意度
b.适用于不确定性大的新颖领域
缺点：a.成本较高，有耗尽时间和费用的风险
b.有人不舍得抛弃“抛弃式原型”，使得较差代码进入产品，降低质量
适用：有着大量不确定性的新颖领域

（6）螺旋模型（风险驱动）

特点：基本思想是尽早解决比较高的风险，如果有些问题实在无法解决，那么早发现比项目结束时再发现要好，至少损失要小得多。风险是指因为不确定性（对未来知识了解有限）而可能给项目带来损失的情况，原型能够澄清不确定性，所以原型能够解决风险。
迭代与瀑布的结合：开发阶段是瀑布式的，风险分析是迭代的
优点：降低风险，减少因风险造成的损失
缺点：a.使用原型方法，为自身带来风险
b.模型过于复杂，不利于管理者依据其组织软件开发活动。
适用性：高风险的大规模软件系统开发

3.软件工程知识体系的知识域

需求、设计、构造、测试、维护、配置管理、工程管理、工程过程、工程工具和方法、质量

链接

👉软件工程与计算II重点整理(第1-5章)
👉软件工程与计算II重点整理(第6-7章)
👉软件工程与计算II重点整理(第8-11章)
👉软件工程与计算II重点整理(第12-15章)
👉软件工程与计算II重点整理(第16-19章)