- 如何理解软件维护的重要性？
- 开发可维护软件的⽅法
- 演化式⽣命周期模型
- ⽤户⽂档、系统⽂档
- 逆向⼯程、再⼯程
用户文档, 系统文档
文档是软件交付的重要部分, 不仅培训师可以作为参考材料, 而且能够在完成交付之后继续帮助用户使用系统.
绝大多数系统都有用户文档和系统管理员文档, 除了较为简单的系统只有用户文档.
用户文档: 为用户编写参考指南或操作教程, 常见的有用户使用手册, 联机帮助文档等.
⽂档内容的组织应当⽀持其使⽤模式, 常见的是指导模式和参考模式两种.
- 指导模式 → 根据⽤户的任务组织程序规程, 相关的软件任务组织在相同的章节或主题. 指导模式要先描述简单的、共性的任务, 然后再以其为基础组织更加复杂的任务描述.
- 参考模式 → 按照⽅便随机访问独⽴信息单元的⽅式组织内容. 例如, 按字母顺序排列软件的命令或错误消息列表.
如果⽂档需要同时包含两种模式, 就需要将其清楚地区分成不同的章节或主题, 或者在同⼀个章节或主题内区分为不同的格式.
系统文档: 更注重系统维护⽅⾯的内容, 例如系统性能调整、访问权限控制、常见故障解决等等. 因此, 系统管理员⽂档需要详细介绍软硬件的配置⽅式、⽹络连接⽅式、安全验证与访问授权⽅法、备份与容灾⽅法、部件替换⽅法等等.
软件维护的重要性
软件维护的定义: 在交付之后修改软件系统或其部件的活动过程, 以修正缺陷, 提高性能或其他属性, 适应变化的环境.
原因(重要性):
- 问题发生改变: 随着时间的发展, 形势可能会发生变化, 导致用户的问题发生变化. 这些使得软件的需求发生变化, 出现新的需求, 否则软件将减小甚至失去服务用户的作用.
- 环境发生改变: 随着软件产品的生命周期越来越长, 在软件生存期内外界环境发生变化的可能性越来越大, 因此, 软件经常需要修改以适应外界环境的改变.
- 软件产品中存在缺陷: 软件开发的理想结果当然是建立一个完全无缺陷的软件产品, 但这是不可能达到的目标. 最终的软件产品总是或多或少的会遗留下一些缺陷. 当这些缺陷在使用中暴露出来时, 必须予以及时的解决.
类型:
- 完善性维护: 满足新需求, 增加软件功能
- 适应性维护: 为了适应新的环境
- 修正性维护: 排除遗留缺陷
- 预防性维护: 让产品在将来可维护, 提升可维护性
开发可维护软件的方法
- 考虑软件的可变更性
- 分析需求的易变性, 尽可能发现和预测可能的变更
- 为变更进行设计, 进行关注点的分离, 使用信息隐藏和OCP等设计思想将可能的变更封装起来
- 为降低维护困难而开发
- 在软件开发阶段多做一些工作, 降低维护工作的困难
- 编写详细的技术文档并保持及时更新
- 保证代码的可读性
- 维护需求跟踪链
- 维护回归测试基线(系统修改之前的有效测试用例集合)
演化式生命周期模型
演化: 一开始与维护(交付之后的修改过程)是等价的词汇, 但随着人们开始使用分阶段交付的方法尽快完成产品开发与交付, 软件往往一边开发一边维护, 交付的准确时间点变得模糊, 很难确定软件开发和软件维护的时间线. 这种软件产品一直被持续地开发和维护的情况更多地被称为演化(evolution).
演化式生命周期模型:
初步开发
按照传统的软件开发⽅式完成第⼀个版本的软件产品开发. 第⼀版的软件产品可以实现全部需求, 也可以（通常是）只包含部分需求——对⽤户来说⾮常重要和紧急的最⾼优先级需求.
初始阶段的软件体系结构是必须进行仔细设计, 要求具有良好的可扩展性, 可修改性, 且比较坚实可靠. 如果大幅修改第一个版本的软件体系结构(软件设计中最重要的决策), 则软件的复杂性就会急剧增加以至于很快就无法继续演化下去.
演化
该阶段可能会有预先安排的需求增量, 也可能完全是对变更请求的处理. 它们的共同点都是保持软件产品的持续增值, 让软件产品能够满⾜⽤户越来越多的需要, 实现更⼤的业务价值.
总的来说, 该阶段可能的演化增量有:
- 预先安排的需求增量;
- 因为问题变化或者环境变化产⽣的变更请求;
- 修正已有的缺陷;
- 随着⽤户与开发者之间越来越相互熟悉对⽅领域⽽新增加的需求.
演化阶段的软件产品要具备两个特征:
- 软件产品具有较好的可演化性.
- ⼀个软件产品在演化过程中复杂性会逐渐增⾼, 可演化性会逐渐降低直⾄⽆法继续演化.
- 演化阶段的软件产品虽然其可演化性低于初始开发阶段的软件产品, 但是还没有到达⽆法演化的地步, 还具有较好的可演化性.
- 软件产品能够帮助⽤户实现较好的业务价值.
- 只有这样, ⽤户才会继续需要该产品, 并持续提供资⾦⽀持.
如果在演化过程中, ⼀个软件产品开始不满⾜第2条特征, 那么该产品就会提前进⼊停⽌阶段.
如果软件产品满⾜第2条的同时不满⾜第1条特征, 那么该产品就会进⼊服务阶段.
如果开发团队因为竞争产品的出现或者其他市场考虑, 也可以让同时满⾜上⾯两条特征的软件产品提前进⼊服务阶段.
服务
服务阶段的软件产品不再持续的增加⾃⼰的价值, ⽽只是周期性的修正已有的缺陷.
服务阶段的产品还仍然被⽤户使⽤, 因为它仍然能够给⽤户提供⼀定的业务价值, 所以开发团队仍然需要修正已有缺陷或者进⾏⼀些低程度的需求增量, 保证⽤户的正常使⽤.
逐步淘汰
在逐步淘汰阶段, 开发者已经不再提供软件产品的任何服务, 也即不再继续维护该软件.
虽然在开发者看来软件的⽣命周期已经结束, 但是⽤户可能会继续使⽤处于该阶段的软件产品, 因为它们仍然能够帮助⽤户实现⼀定的业务价值. 只是⽤户在使⽤软件时必须要容忍软件产品中的各种不便, 包括仍然存在的缺陷和对新环境的不适应.
对于该阶段的产品, 开发者需要考虑该产品是否可以作为有⽤的遗留资源⽤于新软件的开发, ⽤户需要考虑如何更换新的软件产品并转移已有的业务数据.
停⽌
⼀个软件正式退出使⽤状态之后就进⾏停⽌状态. 开发者不再进⾏维护, ⽤户也不再使⽤.
软件维护与演化的常见技术
常见的维护与开发的情况: 依赖于开发文档, 程序源代码和程序员理解能力进行程序理解与修改实现
特殊情况:
- 没有开发文档和程序源代码
- 修改实现不再基于现有的软件结构, 整体建立全新的软件结构
此时就需要与软件开发阶段完全不同的技术来辅助.
遗留软件
维护预留软件很困难, 可以考虑使用的方法:
- 没有使用价值 → 丢弃
- 还有使用价值, 但是维护它的成本效益比低于新开发一个软件系统的成本效益比 → 冻结遗留软件, 将其作为一个新的更大的系统的组分进行使用
- 遗留软件的成本效益比高于新开发一个软件系统的成本效益比, 且该遗留软件仍然具备较好的可维护性 → 逆向工程该遗留软件, 继续维护一段时间
- 遗留软件的成本效益比高于新开发一个软件系统的成本效益比, 且该遗留软件已经不具备可维护性 → 修改系统(进行再工程)使其获得新生, 然后继续维护改造后的系统
逆向工程
处理没有任何文档且没有源代码的维护任务
理解而不修改
逆向⼯程: 分析⽬标系统, 标识系统的部件及其交互关系, 并且使⽤其它形式或者更⾼层的抽象创建系统表现的过程.
基本原理:
- 抽取软件系统的需求与设计⽽隐藏实现细节
- 然后在需求与设计的层次上描述软件系统, 以建⽴对系统更加准确和清晰的理解.
再工程
不会画大力气理解软件, 而是主要关注如何修改软件.
处理遗留软件时, 再工程之前往往需要一个前导的逆向工程.
再⼯程: 检查和改造⼀个⽬标系统, ⽤新的模式及其实现复原该⽬标系统.
⽬的是对遗留软件系统进⾏分析和重新开发, 以便进⼀步利⽤新技术来改善系统或促进现存系统的再利⽤.
主要活动:
- 改进⼈们对软件的理解;
- 改进软件⾃⾝, 通常是提⾼其可维护性、可复⽤性和可演化性.
常见具体活动:
- 重新⽂档化;
- 重组系统的结构;
- 将系统转换为更新的编程语⾔;
- 修改数据的结构组织.
