Chapter9：Software Evolution：SE_Notes《软件工程》笔记

Chapter9：Software Evolution

9.1 brief

9.1.1 What is Software Evolution ?

事实：Software change is inevitable 【出现新需求、环境变更、错误修改、引进新设备、改善性能】

措施：我们需要实现和管理对现有软件系统的变更。

9.1.2 The software evolution process

1）拿到changes

2）对changes进行分析

3）版本规划：会根据change requests的类型，对系统做出维护：修复错误【改正型】、平台适应【适应型】、系统加强完善【完善型】。

4）change implementation：和版本规划是一个迭代的活动

5）进行新版本的发布

• 放大：change implementation
  

​ 关键的区别：在第一阶段，涉及到对原有程序的理解。

​ 软件的维护者：已经不是原有的开发人员了。

​ 软件的变更，必须在理解软件的结构和功能的基础上加以变更，所以我们要求可读性较好。

9.1.3 Lehman 's laws 定理

• 《Program evolution dynamics》----- by Lehman and Belady

  《Program evolution dynamics》is the study of the processes of system change.

  Lehman and Belady 根据经验提出了一些列的方法，感觉像是 “laws”，但实际上是观察出来的结果。

  适用于大型组织开发的大型系统。

• Lehman 's laws

• Applicability of Lehman’s laws

  主要适用于：大型组织、大型系统

  Lehman’s laws 对：打包软件产品、商用化组件、较小的组织、中等规模的系统，是否适用？尚未清楚。

9.2 Software maintenance

9.2.1 What is Software maintenance？

1）在它投入使用以后，进行修改

2）maintenance主要用在 custom software 定制化软件上

3）Generic software 一般不用 maintenance，而用：evolve to create new versions

4）maintenance 主要是对系统进行小的修改，不太可能动到大的架构上

5）可以 modifying existing components 或者 adding new components

9.2.2 Types of maintenance

9.2.3 Maintenance costs

• Maintenance costs

  软件开发成本：高。但维护成本：更高（2~100倍的开发成本）

  比如通用软件：因为生命周期长，所以开发成本更高。

• Maintenance costs factors 【影响cost的因素】

  1）Team stability
  2）Contractual responsibility
  3）Staff skills
  4）Program age and structure

• Complexity metrics
  

9.3 System re-engineering

9.3.1 Maintenance vs. re-engineering

• maintenance：不会对程序进行大的修改。

• re-engineering：当一个程序用了很长时间后，结构退化的很厉害，可维护性也比较差，但是功能还非常有用，某种程度上具有不可取代性，那么我们会考虑进行：System re-engineering

  在不改变程序功能的情况下，对一个legacy system老系统，重新组织系统的结构，或者重写一部分代码。

  适用时间：用于有一些子系统经常需要维护。

  目的：使得系统易于维护。【可能需要 re-structured and re-documented 】

9.3.2 new software development vs. re-engineering

re-engineering 相比于 new software development 的好处

1）Reduced risk

2）Reduced cost

9.3.3 The reengineering process

有顺序关系，但不是每一个都需要做。

1）Source code translation：源代码转换，换成新的代码环境，可能是因为原来的代码已经没有人维护了，通常由自动转换工具实现，意味着可能丢失掉一些注释。

2）Reverse engineering：逆向工程，从可执行程序推出需求，帮助重建文档

3）Program structure improvement：程序结构改善，对于由于频繁维护造成的结构退化，可以采用程序结构改善，对程序结构进行改善。

4）Program modularization：程序模块化，把程序的公用部分、相似部分、逻辑相关部分，抽象组织成可调用的模块和对象。

5）Data re-engineering：对程序中的数据组织，进行re-engineering

9.3.4 Costs

9.3.5 Preventative maintenance by refactoring

refactoring：对程序的结构进行改善，使得：软件结构退化慢一些。

refactoring 在 re-engineering 中非常重要。

9.3.6 ‘Bad smells’ 【坏味代码】 in program code

1）Duplicate code：相同or相似的代码：可以把它们封装起来，成为一个method或function，这就是 modularization 模块化

2）Long method：长方法，如果一个方法太长，可以把它截断成几个方法。因为程序的规模不宜过大。

3）Switch statements：会使得程序发散。我们可以采用多态机制来处理。

4）Data clumping：数据堆积现象，在1个程序的不同地方重复出现相同数据，可以用一个对象来封装数据。

5）Speculative generality ：预测通用性。当初开发者加入了一些以后可能用到的代码，但实际上没有用到，现在可以去掉。

9.3.7 Legacy system management

• 遗产系统的管理

  依赖遗留系统的组织必须为这些系统的演进选择一种策略

  1）彻底废弃系统，修改业务流程，使之不再需要;

  2）继续维护系统;

  3）对系统进行改造，提高系统的可维护性;

  4）用一个新系统替换这个系统。

  所选择的战略应根据系统的特性和业务价值来确定。

• Legacy system categories
  

• Business value assessment
  

• Issues in business value assessment

  1）The use of the system

  2）The business processes that are supported

  3）System dependability

  4）The system outputs

• System quality assessment

  1）Environment assessment
  How effective is the system’s environment and how expensive is it to maintain?
  2）Application assessment
  What is the quality of the application software system?

• Factors used in environment assessment
  

• System measurement 搜集软件系统的质量数据，来做出评断

  1)通过系统申请变更的次数。

  2）系统使用的不同的用户接口的数目。

  3）系统所使用的数据的volume数量。