交付和维护
交 付
项目交付工作
项目验收交付时，还有三项工作在等着：实施、培训、验收
验收后的项目才正式进入“维护”阶段
项目实施
项目实施是将软件系统部署到客户方的计算机系统上，协助客户准备基础数据，使软件系统顺利上线运行。
• 保证软件符合需求，质量过关
全面做好测试工作（集成测试、功能测试、性能测试）
• 制定实施计划
要发布的代码版本、数据库创建方式、基础数据准备方式
• 准备好程序代码和相关文档
用户手册以及其他系统文档（如需求说明书、设计文档等）
客户培训
在系统部署完成、基础数据准备齐全之后，应该组织客户培训，使其掌握对软件系统的使用和操作。
• 选择合适的培训人员
经验丰富、了解业务和系统
• 准备好培训内容
不要临时抱佛脚
• 制定培训计划
与客户沟通协调，安排时间
项目验收
客户对系统进行验收测试，包括范围核实（用户需求是否全部实现）和质量核实（质量属性是否满足要求）。
软件部署定义
软件部署是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。
部署技术影响着整个软件过程的运行效率和投入成本，软件系统部署的管理代价占到整个软件管理开销的绝大部分。
软件配置过程极大地影响着软件部署结果的正确性，应用系统的配置是整个部署过程中的主要错误来源。
软件部署作用
基本目的：支持软件运行，满足用户需求，使得软件系统能够被直接使用。
• 保障软件系统的正常运行和功能实现
• 简化部署的操作过程，提高执行效率
• 同时还必须满足软件用户在功能和非功能属性方面的个性化需求
软件部署模式
面向单机软件的部署模式
面向单机软件的部署模式：包括安装、配置和卸载，该部署模式主要适用于运行在操作系统之上的单机类型的软件。
部署操作的执行功能主要通过脚本编程的方式来实现，以脚本语言编写的操作序列来支持诸如软件的安装和注册。
集中式服务器应用部署
集中式服务器应用部署：适用于用户访问量小（500人以下）、硬件环境要求不高的情况，诸如中小企业、高校在线学习、实训平台等。
集群式服务器应用部署
集群式服务器应用部署：适用于并发用户访问量大（10000以上）、对系统稳定性和性能要求高的分布式平台部署。
持续集成与交付
持续集成是一项软件开发实践，团队成员经常集成自己的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。
• 所有开发人员需要在本地机器上进行本地构建，然后再提交到版本控制库中，以免影响持续集成。
• 开发人员每天至少向版本控制库中提交一次代码，至少从版本控制库中更新一次代码到本地机器。
• 需要有专门的集成服务器来执行集成构建，并通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。
当有了持续集成需要的构建服务器和脚本之后，下一个问题是：
持续交付：以自动化或半自动化方式，将构建版本从一个环境提送到更接近实际使用的交付准备环境中。
• 一周内平均部署几十次，几乎每个开发人员的每次修改就会导致 一次部署。
• 这不仅仅意味着可以更快地从用户那里得到使用反馈，更可以迅速对产品进行改进， 更好地适应用户的需求和市场的变化。
常见的软件交付过程
对於单个项目来说，整个过程大体上是一个典型的瀑布开发过程。
该产品线有很多并行项目，为了避免互相干扰可能带来的冲突，每个项目启动后都会重新在主干上拉出分支，在上线前才进行合并。
持续集成的交付过程
调 试
**调试（也称为纠错）**作为成功测试的后果出现，也就是说，调试是在测试发现错误之后排除错误的过程。
虽然调试应该而且可以是一个有序过程，但是，目前它在很大程度上仍然是一项技巧。
软件工程师在评估测试结果时，往往仅面对着软件错误的症状，也就是说，软件错误的外部表现和它的内在原因之间可能并没有明显的联系。调试就是把症状和原因联系起来的尚未被人深入认识的智力过程。
调试过程
调试是软件开发过程中最艰巨的脑力劳动。调试工作如此困难，可能心理方面的原因多于技术方面的原因。
调试途径
无论采用什么方法，调试的目标都是寻找软件错误的原因并改正错误。通常需要把系统地分析、直觉和运气组合起来，才能实现上述目标。
一般说来，有下列3种调试途径可以采用：
1、蛮干法 — 逐点（单步）跟踪
2、回溯法 — 从出错处向上追朔
3、原因排除法 — 对分查找法、归纳法和演绎法
维 护
软件维护的定义
软件维护 ---- 就是在软件已经交付使用之后，为保证软件在相当长的时期能够正常运作所进行的软件活动。
维护的类型有四种：
改正性维护
适应性维护
扩充与完善性维护
预防性维护
改正性维护
在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。
这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。
为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程就叫做改正性维护。
适应性维护
在使用过程中，下面情况可能发生变化。
外部环境（新的硬、软件配置）
数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）
为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。
扩充与完善性维护
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。
为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
这种情况下进行的维护活动叫做扩充与完善性维护。
预防性维护
预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。
预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
各种维护所占比例:
影响软件维护的因素
维护的费用和代价
维护费用仅仅是软件维护的明显代价。还有许多不明显的代价。
维护的问题
理解别人写的程序通常非常困难
需要维护的软件往往没有合格的文档
当要求对软件进行维护时，不能指望由开发人员仔细说明软件
绝大多数软件在设计时没有考虑将来的修改软件维护不是一项吸引人的工作
文 档
文档是影响软件可维护性的决定因素。往往文档比程序代码更重要。
软件系统的文档可以分为用户文档和系统文档两类。
---- 用户文档主要描述系统功能和使用 方法，并不关心这些功能是怎样实现的；
---- 系统文档描述系统设计、实现和测试等各方面的内容。
软件文档应该满足下述要求：
(1) 必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用；
(2) 必须描述怎样安装和管理这个系统；
(3) 必须描述系统需求和设计；
(4) 必须描述系统的实现和测试，以便使系统成为可维护的。
用户文档
用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。
用户文档至少应该包括下述5方面的内容：
(1) 功能描述； (2) 安装文档；
(3) 使用手册； (4) 参考手册；
(5) 操作员指南(如需要有系统操作员的话) 。
上述内容可以分别作为独立的文档，
也可以作为一个文档的不同分册，
具体做法应该由系统规模决定。
系统文档
---- 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。
---- 描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。
---- 和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。
提高可维护性的方法
建立明确的软件质量目标和优先级
使用提高软件质量的技术和工具
进行明确的质量保证审查
选择可维护的程序设计语言
改进程序的文档
软件维护的标准化
IEEE 1219《软件维护标准》
修改请求
分类与鉴别
分析
设计
实现
系统测试
验收试验
交付
结构化维护与非结构化维护
软件维护过程
维护组织
维护报告
工作流程
维护记录的保存
对维护的评价
软件维护策略
维护准备
软件维护的范围
过程的剪裁
指定由谁维护
维护成本的估计
维护策划
维护计划、维护计划指南
资源分析
人力资源、环境资源、财政资源
小 结:
软件维护的4类活动
（改正性、适应性、完善性、预防性）
决定软件可维护性的基本要素
（可理解、可测试、可修改、可移植和可重用性）
文档是影响软件可维护性的决定因素