软件演化笔记

第一讲

识别和分类不同种的软件工程，并能识别其位于的软件周期中。

分析软件演化背后的驱动因素。

描述软件成品演变的一些模型和过程。

 

 

维护似乎更与这些独立进行，而不是像这张图上这样的。

从瀑布模型中我们可以看出，需求、设计（架构）、实施（数据、代码、文档、技术）和验证（测试和证明）都在不断发展。

演化是某种物质的或抽象的、自然的或人工的实体或系统的属性、特征和行为随时间逐步变化的阶段性过程。

软件演化则是人工的软件的属性、特征和行为随时间逐步变化的阶段性过程。

Phase-out（停止维护）

Close-down（终止使用）

软件工件的演进应保持一致。然而，这在现在实际上是一个问题。

1. 纠正性维护：针对任何类型的失效（如漏洞、系统错误）而进行的维护。

2. 适应性维护：针对数据或处理环境的变化（如需求变化）进行维护。

3. 完善性维护：为消除缺陷、优化质量属性或提高可维护性而进行的维护。

程序的稳定性是关键（稳定性：程序变化放大的阻力）。
程序是某种事物的抽象表示。程序建立在一个理论框架/模型之上（例如编程范式、数学、逻辑）。这一理论框架/模型考虑对正在解决的现实世界问题或特定环境或领域进行抽象。

S型程序：

其功能由规范正式定义并可由规范派生的程序

所解决的问题都有明确的话语定义。

 

程序的正确性是可以证明的。

例子：一些专门的数学、算法程序。

E(A)型程序（不断发展的、应用的）：在现实世界中运行的程序（或针对现实世界的程序）。它们应该不断发展，因为现实世界也在发展。

解决的问题是以不断发展的现实世界为框架的。

由此产生的程序在概念上并不是静态的。

程序的正确性无法证明，只能测试。

 E-program的八条定律：

1. 持续变化——E型系统必须不断调整，否则就会越来越不尽如人意。

2. 复杂性逐步增加——随着E型系统的发展，其复杂性也会增加，除非进行维护或降低复杂性。

3. 自我调节——E型系统的演化过程是自我调节的，其产品和过程测量值随时间的分布接近正常。

4. 组织稳定性的保持——在一个不断演化的E型系统中，总体平均有效活动率在产品的整个生命周期内保持不变。

 

5. 熟悉度的保持——在不断演化的E型系统的有效寿命期间，连续发布的平均内容是不变的，每次更改的内容大致上应该一样。

6. 功能持续增长——E型系统的功能内容必须不断增加，以保持用户在使用期内对系统的满意度（如何定义功能内容的增加？）。

7. 质量下降——除非对E型系统进行严格维护并使其适应不断变化的运行环境，否则利益相关者会认为E型系统的质量在下降（如何定义质量？）。

8. 反馈系统——E型系统中的演化过程构成了多层次、多轮次、多代理反馈系统，必须将其作为多层次、多轮次、多代理反馈系统来处理，才能在任何合理的基线上取得显著的改进。

2013年前，只有两条定律还能用（1和4）。

第二讲

software requirements定义：“描述系统应提供的服务及其运行限制。”

requirement specification：“描述系统应做什么的文件。它通常是客户与供应商之间合同的一部分。”

用户需求vs系统需求

用户：对系统功能和服务的整体要求。常常是非常口语化的。

系统：详细描述软件系统的功能、服务和操作限制。确定要实施的具体内容。常常是非常准确的。

功能性需求与非功能性需求

功能性需求：说明系统应提供的服务、系统应如何对特定输入做出反应，以及系统在特定情况下应如何运行。

非功能性需求：对系统提供的服务或功能的限制。它们包括时间限制、开发过程限制和标准限制。

影响演变的需求

当发生下列情况时，软件演化的难度会很大：

• 糟糕的需求（如模糊、主观、过于复杂等）
• 需求不稳定（系统中存在依赖关系）
• 缺失的需求
• 不一致的需求

糟糕的需求

需求应可衡量。例如，应遵循SMART标准。Specific（具体）、Measurable（可衡量）、A（Achievable, Actionable, Appropriate）、R（Realistic, Relevant）、T（Time-bound, Traceable）。