软件项目验收.ppt

第第10章章 软件项目验收软件项目验收 软件项目验收是指软件项目成果试运行后，正式软件项目验收是指软件项目成果试运行后，正式交付给用户之前，用户方同承担方对软件项目成果进交付给用户之前，用户方同承担方对软件项目成果进行审查，核查双方约定的项目计划中所规定范围内的行审查，核查双方约定的项目计划中所规定范围内的各项工作或活动是否均已完成，应当交付的软件成果各项工作或活动是否均已完成，应当交付的软件成果是否满足范围、功能和性能要求。是否满足范围、功能和性能要求。软件项目无论是否按计划正常结束，验收都是非软件项目无论是否按计划正常结束，验收都是非常必要的。对于非正常结束的软件项目，通过验收可常必要的。对于非正常结束的软件项目，通过验收可以查明项目的哪些工作已经完成，完成到什么程度，以查明项目的哪些工作已经完成，完成到什么程度，分析不能正常结束的原因。分析不能正常结束的原因。10.1 验收标志着软件项目即将结束验收标志着软件项目即将结束 (1)项目验收标志着软件项目的结束或阶段性结项目验收标志着软件项目的结束或阶段性结束，是软件项成果交付给用户，并开始正式使用的标束，是软件项成果交付给用户，并开始正式使用的标志。志。(2)软件项目顺利通过验收，标志着项目的用户软件项目顺利通过验收，标志着项目的用户方与承担方之间的义务和责任基本结束方与承担方之间的义务和责任基本结束(除项目运行除项目运行阶段的维护问题之外阶段的维护问题之外)。(3)项目按计划验收，是保证按合同完成软件成项目按计划验收，是保证按合同完成软件成果研制、保证软件项目成果质量的关键步骤。果研制、保证软件项目成果质量的关键步骤。(4)项目验收结束并不等于双方签订的协议的终项目验收结束并不等于双方签订的协议的终止，这是因为软件项目往往还存在后续的维护等问题。止，这是因为软件项目往往还存在后续的维护等问题。10.2 项目验收前的准备工作项目验收前的准备工作 项目验收前，项目承担方和用户方都需要做很多项目验收前，项目承担方和用户方都需要做很多准备工作。准备工作。10.2.1 项目承担方的准备工作项目承担方的准备工作 (1)做好项目的收尾工作做好项目的收尾工作 收尾是项目临近完工的一段时间内的重要活动，收尾是项目临近完工的一段时间内的重要活动，此时剩下的只是一些开发量不大但头绪很多、需要细此时剩下的只是一些开发量不大但头绪很多、需要细致耐心处理的工作。收尾工作做不好将影响验收的进致耐心处理的工作。收尾工作做不好将影响验收的进行。所以，要正确处理好项目收尾工作，做到有头有行。所以，要正确处理好项目收尾工作，做到有头有尾。尾。(2)项目组自检工作项目组自检工作 项目验收准备阶段，应对照以上验收的标准和要项目验收准备阶段，应对照以上验收的标准和要求，进行必要的自检自查工作，尽最大可能地找到软求，进行必要的自检自查工作，尽最大可能地找到软件系统中存在的问题、漏洞和不足，并尽快予以解决件系统中存在的问题、漏洞和不足，并尽快予以解决和完善。和完善。自检工作主要包括以下三项内容：自检工作主要包括以下三项内容：1)确定参加自检的人员确定参加自检的人员 2)制定自检的计划制定自检的计划 按照软件系统的功能层次和性能要求划分并确定按照软件系统的功能层次和性能要求划分并确定自检的顺序，确定自检的方法，编制自检计划。自检的顺序，确定自检的方法，编制自检计划。3)执行自检执行自检 参加自检的人员要对软件的每一个功能逐个进行参加自检的人员要对软件的每一个功能逐个进行检查，检查功能的合理性与完整性。检查，检查功能的合理性与完整性。(3)源程序整理与系统归档源程序整理与系统归档 整理源程序代码，包括清理废弃的程序代码、功整理源程序代码，包括清理废弃的程序代码、功能构件等。能构件等。对已经全部完成的软件系统或子系统，按照软件对已经全部完成的软件系统或子系统，按照软件配置管理的要求，将源程序、可执行程序及其构件进配置管理的要求，将源程序、可执行程序及其构件进行归类、存储、备份、登记，防止软件丢失、损坏，行归类、存储、备份、登记，防止软件丢失、损坏，或者泄露而造成损失。或者泄露而造成损失。(4)准备项目验收文档准备项目验收文档 软件项目验收除了验收开发的软件系统外，另一软件项目验收除了验收开发的软件系统外，另一个重要的验收内容就是审核验收合同规定的需要提交个重要的验收内容就是审核验收合同规定的需要提交给用户的全部文档资料。给用户的全部文档资料。(5)提出验收申请提出验收申请 向用户方和监理方提交申请验收的请求报告，并向用户方和监理方提交申请验收的请求报告，并同时附送项目验收的相关材料，以备项目接收方组织同时附送项目验收的相关材料，以备项目接收方组织人员进行验收。人员进行验收。10.2.2 用户方的准备工作用户方的准备工作 (1)成立项目验收委员会成立项目验收委员会 项目验收委员会一般由用户方、承担方、监理方项目验收委员会一般由用户方、承担方、监理方及行业专家组成。及行业专家组成。项目验收委员会的主要工作职责：项目验收委员会的主要工作职责：1)审查系统试运行情况报告；审查系统试运行情况报告；2)审查各种技术资料；审查各种技术资料；3)对系统运行情况进行复验和技术鉴定，评定系对系统运行情况进行复验和技术鉴定，评定系统质量；统质量；4)审核移交系统及文档清单；审核移交系统及文档清单；5)提交项目验收工作的总结报告和验收鉴定书。提交项目验收工作的总结报告和验收鉴定书。(2)现场准备与软件系统的初步验收现场准备与软件系统的初步验收 1)根据项目承担方送交的验收申请报告根据项目承担方送交的验收申请报告，组织，组织人员到现场检查运行环境的准备工作人员到现场检查运行环境的准备工作;2)按照开发人员提出的数据准备要求，收集整按照开发人员提出的数据准备要求，收集整理相关功能的验收数据，以备系统验收使用理相关功能的验收数据，以备系统验收使用;3)对软件系统运行情况进行初步的检查和验收。对软件系统运行情况进行初步的检查和验收。如果检查结果不符合项目目标的要求，应通知如果检查结果不符合项目目标的要求，应通知承担方尽快进行系统的改进和完善工作。承担方尽快进行系统的改进和完善工作。10.3 软件项目验收软件项目验收 软件项目竣工验收的组织要根据项目的重要软件项目竣工验收的组织要根据项目的重要性、规模大小和隶属关系而定。性、规模大小和隶属关系而定。一般由项目主管部门组织验收，由项目承担一般由项目主管部门组织验收，由项目承担方参与，并聘请一些熟悉软件所涉及业务的人员和方参与，并聘请一些熟悉软件所涉及业务的人员和软件项目管理方面的专家参加。软件项目管理方面的专家参加。10.3.1 项目验收标准项目验收标准 (1)全部程序已经在实际运行的硬件环境、操作全部程序已经在实际运行的硬件环境、操作系统及相关的软硬件支撑环境下进行了试运行，并且系统及相关的软硬件支撑环境下进行了试运行，并且运行稳定。运行稳定。(2)程序总体功能完整，能满足业务要求和软件程序总体功能完整，能满足业务要求和软件系统管理要求。系统管理要求。(3)文档完整，与程序一致，能满足软件正式运文档完整，与程序一致，能满足软件正式运行的要求。行的要求。验收标准的细节部分应当是量化的、可测量的条验收标准的细节部分应当是量化的、可测量的条件。件。验收标准条款的不适当举例：验收标准条款的不适当举例：1)为了保证系统功能的正确性，必须对软件系统为了保证系统功能的正确性，必须对软件系统进行彻底测试，测试要包括适当数量的数据信息和执进行彻底测试，测试要包括适当数量的数据信息和执行流程。行流程。“适当数量适当数量”不明确。不明确。“彻底地彻底地”含义也不明确。含义也不明确。2)在软件用户的协助下，承担方应该准备测试结在软件用户的协助下，承担方应该准备测试结果信息以检验在测试范围内列出的所有条目。果信息以检验在测试范围内列出的所有条目。客户协助程度没有加以限制。客户协助程度没有加以限制。谁对信息进行实际的分类。谁对信息进行实际的分类。没有时间限制。没有时间限制。验收标准不仅要明确地涵盖系统性能，还要包含验收标准不仅要明确地涵盖系统性能，还要包含系统交付情况。系统交付情况。例如，在何时、何地交付系统的拷贝或安装版本；例如，在何时、何地交付系统的拷贝或安装版本；交付多少个拷贝或安装版本；以什么形式交付，资料交付多少个拷贝或安装版本；以什么形式交付，资料如何打包等，都要在标准中加以详细叙述。如何打包等，都要在标准中加以详细叙述。10.3.2 软件系统验收软件系统验收 由监理方从用户的角度对软件系统进行细致的由监理方从用户的角度对软件系统进行细致的调查、了解和分析。对系统的功能、性能进行全方调查、了解和分析。对系统的功能、性能进行全方位的测试，并完成监理报告。位的测试，并完成监理报告。它是决定软件系统能否正常运行，能否被用户它是决定软件系统能否正常运行，能否被用户认可，是软件项目的初步验收。认可，是软件项目的初步验收。它主要考察系统的功能是否符合项目需求说明它主要考察系统的功能是否符合项目需求说明书的要求，是否具有双方所约定的软件系统的特性。书的要求，是否具有双方所约定的软件系统的特性。它与软件项目最终验收不同，最终验收是系统它与软件项目最终验收不同，最终验收是系统使用验收，是指承担方在软件项目按软件需求说明使用验收，是指承担方在软件项目按软件需求说明书和其他设计文件所规定的内容全部开发完成后向书和其他设计文件所规定的内容全部开发完成后向用户交工的过程。用户交工的过程。(1)软件验收的方法软件验收的方法 一般来讲软件验收有两种方法：一般来讲软件验收有两种方法：1)大型、复杂，各子系统之间的关联性又不是很大型、复杂，各子系统之间的关联性又不是很强，可将软件系统划分为不同的子系统，根据强，可将软件系统划分为不同的子系统，根据“总体总体规划、分步实施规划、分步实施”的策略，划分阶段、逐步完成各个的策略，划分阶段、逐步完成各个子系统的开发工作。可在某个子系统完成后，分阶段子系统的开发工作。可在某个子系统完成后，分阶段完成软件系统的验收工作，并通过对项目各个阶段验完成软件系统的验收工作，并通过对项目各个阶段验收结果的汇总、统计，得出软件系统最终的、整体性收结果的汇总、统计，得出软件系统最终的、整体性的质量验收结果。的质量验收结果。2)软件系统规模较小、较简单，或者软件系统各软件系统规模较小、较简单，或者软件系统各个功能之间关联性很强时，应在全部系统开发完成后，个功能之间关联性很强时，应在全部系统开发完成后，统一组织系统验收。统一组织系统验收。(2)软件系统质量验收软件系统质量验收 主要是对软件系统的功能、性能、流程、接口、主要是对软件系统的功能、性能、流程、接口、用户界面友好性等方面进行验收。用户界面友好性等方面进行验收。验收的内容包括：验收的内容包括：1)功能验收功能验收 软件系统实现功能是否满足用户的实际需求。软件系统实现功能是否满足用户的实际需求。2)性能验收性能验收 系统性能是否达到合同或者需求说明书中的要求。系统性能是否达到合同或者需求说明书中的要求。对于系统性能的验收，除了检查正常情况下的性对于系统性能的验收，除了检查正常情况下的性能指标外，更主要的是要检查业务峰值情况下系统的能指标外，更主要的是要检查业务峰值情况下系统的性能指标状况。性能指标状况。3)流程验收流程验收 系统流程是否达到合同或需求说明书中的要求。系统流程是否达到合同或需求说明书中的要求。4)接口验收接口验收 当软件系统与其它软件系统存在接口时，应对相当软件系统与其它软件系统存在接口时，应对相应的接口关联情况进行验收。检验接口是否满足合同应的接口关联情况进行验收。检验接口是否满足合同或者需求说明书中的要求。或者需求说明书中的要求。5)用户界面验收用户界面验收 主要对用户界面的布局、结构、一致性、美观程主要对用户界面的布局、结构、一致性、美观程度进行验收。度进行验收。6)系统开发是否按照标准进行系统开发是否按照标准进行 检验在软件系统的开发中，项目组使用的技术与检验在软件系统的开发中，项目组使用的技术与规范是否采用国际标准、国家标准及行业标准。规范是否采用国际标准、国家标准及行业标准。(3)软件系统文档验收软件系统文档验收 项目文档既是项目评价和验收的标准，也是项项目文档既是项目评价和验收的标准，也是项目交接、维护和后期评价、使用的重要原始凭证。目交接、维护和后期评价、使用的重要原始凭证。项目开发方必须将整理好的、真实的项目文项目开发方必须将整理好的、真实的项目文 档档资料交给项目验收方，项目验收方只有在对文档资资料交给项目验收方，项目验收方只有在对文档资料验收合格后才能开始项目验收工作。料验收合格后才能开始项目验收工作。项目文档验收的主要依据是项目的合同条款。项目文档验收的主要依据是项目的合同条款。由于软件系统自身的特殊性由于软件系统自身的特殊性涉及到项目的涉及到项目的知识产权界定和技术保密问题，所以在文档验收时，知识产权界定和技术保密问题，所以在文档验收时，一般除了合同条款以外，双方应签署补充协议，做一般除了合同条款以外，双方应签署补充协议，做好系统的知识产权界定及落实开发方的技术保密问好系统的知识产权界定及落实开发方的技术保密问题。题。项目文档验收的主要方面：项目文档验收的主要方面：1)完整性完整性 按照合同条款规定的文档资料验收的范围和清单，按照合同条款规定的文档资料验收的范围和清单，通过对项目文件的验收、清点，检查项目文档资料的通过对项目文件的验收、清点，检查项目文档资料的完整性。完整性。2)规范性规范性 根据国家标准或行业标准，检查文档资料书写是根据国家标准或行业标准，检查文档资料书写是否规范。否规范。3)有效性有效性 通过与实际系统的比较，检查文档内容与实际系通过与实际系统的比较，检查文档内容与实际系统是否一致。统是否一致。项目文件全部验收合格时，项目开发方与接收方项目文件全部验收合格时，项目开发方与接收方对项目文件验收报告进行确认和签字，形成项目文件对项目文件验收报告进行确认和签字，形成项目文件验收结果。验收结果。项目文件验收结果一般包括项目文件档案和项目项目文件验收结果一般包括项目文件档案和项目文件验收报告。文件验收报告。项目文件档案主要是记录整个软件项目开展过程项目文件档案主要是记录整个软件项目开展过程中各阶段的文档以及最终的用户使用手册等内容。中各阶段的文档以及最终的用户使用手册等内容。项目文件验收报告是监理方根据项目承担方提供项目文件验收报告是监理方根据项目承担方提供的各项文档资料审核完成后，对项目文档提出的验收的各项文档资料审核完成后，对项目文档提出的验收意见，指出其中根本性的内容是合格还是不合格。如意见，指出其中根本性的内容是合格还是不合格。如果不合格应指出需要修改的内容。果不合格应指出需要修改的内容。10.3.3 项目验收的工作流程项目验收的工作流程 承担方用户方监理方自测试准备文档资料准备项目报告提交申请验收报告成立验收委员会系统测试准备用户报告制定验收计划了解用户意见测试系统系统验收意见编写建立报告工作报告技术报告财务报告现场系统操作用户报告领导意见监理报告现场意见系统验收意见听取现场报告 审核验收资料 考察监理意见观看现场演示 提出专家意见 起草验收报告验收专家表决 公布验收结果签署验收合格文件准备执行项目成果移交工作10.3.4 软件项目最终验收软件项目最终验收 主要是对整个项目的执行情况，如资金使用状况、主要是对整个项目的执行情况，如资金使用状况、进度控制情况、任务完成情况以及与项目相关的各种进度控制情况、任务完成情况以及与项目相关的各种因素控制的得当与否等总体内容的验收和评价。因素控制的得当与否等总体内容的验收和评价。项目最终验收由项目验收委员会主持会议，参加项目最终验收由项目验收委员会主持会议，参加的人包括所有的软件项目的利益相关者，如用户方、的人包括所有的软件项目的利益相关者，如用户方、承担方、监理方以及行业内的相关专家等，采取的主承担方、监理方以及行业内的相关专家等，采取的主要方式是举行项目验收报告会。要方式是举行项目验收报告会。主要事项包括：主要事项包括：(1)对现场报告会准备的各类资料进行验收，主对现场报告会准备的各类资料进行验收，主要包括工作报告、技术报告、财务报告、监理报告、要包括工作报告、技术报告、财务报告、监理报告、用户报告等的格式、内容、质量和真实性做全面的分用户报告等的格式、内容、质量和真实性做全面的分析和验收。析和验收。(2)项目开发方作项目报告项目开发方作项目报告(一般包括工作报告、一般包括工作报告、技术报告、财务报告技术报告、财务报告)，介绍项目开发过程全貌和相，介绍项目开发过程全貌和相关内容。关内容。(3)监理方作监理报告，包括对软件项目交付成监理方作监理报告，包括对软件项目交付成果的测试报告，以及文档验收报告等。果的测试报告，以及文档验收报告等。(4)用户代表做用户报告（对项目的综合评价及对用户代表做用户报告（对项目的综合评价及对软件系统的最终使用评价）。软件系统的最终使用评价）。(5)审查验收软件项目各种文档的完整性。审查验收软件项目各种文档的完整性。(6)审查软件接收方所提出的软件功能、性能要审查软件接收方所提出的软件功能、性能要求是否已经在前期得到了验证和认可。求是否已经在前期得到了验证和认可。(7)审查软件项目采用的代码和基础数据是否符审查软件项目采用的代码和基础数据是否符合规范化要求。合规范化要求。(8)审查软件可执行程序是否与所提供的文档资审查软件可执行程序是否与所提供的文档资料相一致。料相一致。(9)审查用户方提供的审查用户方提供的“系统正式验收证明系统正式验收证明”。(10)根据所了解的内容和信息，决定系统是否通根据所了解的内容和信息，决定系统是否通过验收。过验收。10.4 软件系统的客户化切换软件系统的客户化切换 所谓软件系统的客户化切换，就是指软件项目验所谓软件系统的客户化切换，就是指软件项目验收合格以后，应当进行软件成果的全面移交，将系统收合格以后，应当进行软件成果的全面移交，将系统转入正式运行状态，并执行正式运行的规范化使用和转入正式运行状态，并执行正式运行的规范化使用和管理。管理。客户化切换的主要工作包括：客户化切换的主要工作包括：1）软件系统的用户交接）软件系统的用户交接 2）文档资料的用户交接）文档资料的用户交接 3）新系统的正式上线运行）新系统的正式上线运行10.4.1 软件系统的用户交接软件系统的用户交接 软件系统的用户交接主要包含以下工作：软件系统的用户交接主要包含以下工作：(1)整理试运行阶段的测试数据整理试运行阶段的测试数据 试运行阶段，软件运行所积累的数据一部分将作试运行阶段，软件运行所积累的数据一部分将作为系统今后运行必不可少的数据，这些数据将保留在为系统今后运行必不可少的数据，这些数据将保留在正式运行的系统中；另一部分数据只是为了验证系统正式运行的系统中；另一部分数据只是为了验证系统的功能、性能、流程等，当系统试运行结束后，这部的功能、性能、流程等，当系统试运行结束后，这部分数据已完成其历史使命，应从系统中清除。分数据已完成其历史使命，应从系统中清除。(2)与相关软件进行数据衔接与相关软件进行数据衔接 新的软件系统可能与其他软件或文件存在数据关新的软件系统可能与其他软件或文件存在数据关联。例如，可能是对原有软件系统的重新开发，那就联。例如，可能是对原有软件系统的重新开发，那就必须继承原系统的数据；或者是新系统，但其他系统必须继承原系统的数据；或者是新系统，但其他系统需要利用其中的部分数据，必须进行数据转换以完成需要利用其中的部分数据，必须进行数据转换以完成新旧系统的切换工作。新旧系统的切换工作。(3)进行用户操作和系统管理培训进行用户操作和系统管理培训 培训一般由软件项目接收方负责组织实施。培训一般由软件项目接收方负责组织实施。培训前必须预先编写培训大纲，培训大纲要根据培训前必须预先编写培训大纲，培训大纲要根据业务和管理的需要展开，以便达到软件操作与管理的业务和管理的需要展开，以便达到软件操作与管理的需求。培训大纲由软件项目承担方负责。需求。培训大纲由软件项目承担方负责。培训大纲的要素包括：培训大纲的要素包括：1)培训计划培训计划 确定培训目的、培训时间及课程。确定培训目的、培训时间及课程。2)培训对象培训对象 通常接受培训的人员应当是本软件运行所受影响通常接受培训的人员应当是本软件运行所受影响的部门和个人，包括接收方高级管理者、软件的用户、的部门和个人，包括接收方高级管理者、软件的用户、潜在的用户及其部门管理人员、软件的综合管理部门潜在的用户及其部门管理人员、软件的综合管理部门及其人员。及其人员。3)培训内容和资料培训内容和资料 包括与软件项目相关的操作系统、数据库管理系包括与软件项目相关的操作系统、数据库管理系统、软件项目交付成果的使用说明等相关的课程内容统、软件项目交付成果的使用说明等相关的课程内容和资料。和资料。4)培训的方式和方法培训的方式和方法 可以根据条件尽量采用可重复的、便捷的方式进可以根据条件尽量采用可重复的、便捷的方式进行，通常有课堂讲解、计算机辅助教学、在培训者指行，通常有课堂讲解、计算机辅助教学、在培训者指导下的自学、正式的跟班学习、观看录像以及网上培导下的自学、正式的跟班学习、观看录像以及网上培训等方式。训等方式。5)培训设施培训设施 如果条件允许，应在非常类似于实际性能条件的如果条件允许，应在非常类似于实际性能条件的环境中进行。环境中进行。6)培训效果的评价培训效果的评价 确定受训人员满意地完成学业的准则，收集、评确定受训人员满意地完成学业的准则，收集、评审培训的反馈信息，对培训的效果进行评价，以便考审培训的反馈信息，对培训的效果进行评价，以便考虑培训过程的改进，重新按排后续培训的机会。虑培训过程的改进，重新按排后续培训的机会。7)培训记录培训记录 保存培训的全过程记录，包括所有人员完成每个保存培训的全过程记录，包括所有人员完成每个培训课程或其他培训活动的记录，以便在考虑相关软培训课程或其他培训活动的记录，以便在考虑相关软件岗位时作为参考。件岗位时作为参考。(4)开始执行正式运行的管理规范开始执行正式运行的管理规范 正式运行阶段必须对软件运行情况加以规范化管正式运行阶段必须对软件运行情况加以规范化管理。理。(5)启动软件维护机制启动软件维护机制 维护阶段的关键任务是，通过各种必要的活动维护阶段的关键任务是，通过各种必要的活动使软件系统持久地满足用户的需要。使软件系统持久地满足用户的需要。维护阶段虽没有被进一步划分成更小的阶段，维护阶段虽没有被进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过但是实际上每一项维护活动都应该经过“提出维护提出维护要求要求(或报告问题或报告问题)，分析维护要求，提出维护方案，分析维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等改程序，测试程序，复查验收等”一系列步骤，实一系列步骤，实质上是经历了一次压缩和简化了的软件定义、开发、质上是经历了一次压缩和简化了的软件定义、开发、验收的全过程。验收的全过程。10.4.2 文档资料的用户交接文档资料的用户交接 文档资料移交时需要根据合同要求编制文档资料移交时需要根据合同要求编制项目项目文档资料移交清单文档资料移交清单。开发方和用户方按照清单查阅。开发方和用户方按照清单查阅清楚并认可后，双方在移交清单上签字盖章。移交清清楚并认可后，双方在移交清单上签字盖章。移交清单一式两份，双方各自保存一份。单一式两份，双方各自保存一份。10.4.3 系统的正式上线运行系统的正式上线运行 软件系统的移交工作并不是简单地将项目实体软件系统的移交工作并不是简单地将项目实体所有权移交给用户就完成了。移交阶段，开发方要所有权移交给用户就完成了。移交阶段，开发方要使用户方接收人员具有独立使用和对系统进行日常使用户方接收人员具有独立使用和对系统进行日常管理维护的能力。管理维护的能力。软件系统的正式上线运行前后，一定要做好以软件系统的正式上线运行前后，一定要做好以下工作：下工作：(1)用户方成立项目接收组用户方成立项目接收组 接收前，用户方要组建自己的软件系统接收组。接收前，用户方要组建自己的软件系统接收组。对于大型的软件系统，软件系统接收组在完成接收对于大型的软件系统，软件系统接收组在完成接收工作后，应当从职能上转换为软件的运行管理部门，工作后，应当从职能上转换为软件的运行管理部门，明确系统负责人、技术维护人员、系统使用人员等，明确系统负责人、技术维护人员、系统使用人员等，从开发方接过系统日常使用及维护工作。从开发方接过系统日常使用及维护工作。(2)人员培训人员培训 人员培训的目的是使用户方接收组人员完成对系人员培训的目的是使用户方接收组人员完成对系统的全面接管工作（日常使用和维护）。这部分工作统的全面接管工作（日常使用和维护）。这部分工作做得越仔细，整个软件系统的收尾工作就越迅速，将做得越仔细，整个软件系统的收尾工作就越迅速，将来项目维护的代价就会越小。来项目维护的代价就会越小。(3)系统正式上线的基础准备工作系统正式上线的基础准备工作 用户方需要组织人员，协助开发方完成系统运行用户方需要组织人员，协助开发方完成系统运行环境的准备，包括计算机硬件、网络和工作站操作系环境的准备，包括计算机硬件、网络和工作站操作系统、外购的辅助软件的准备、数据导入等系统上线的统、外购的辅助软件的准备、数据导入等系统上线的必要准备工作。协助开发方快速、安全地完成新旧系必要准备工作。协助开发方快速、安全地完成新旧系统的切换工作。统的切换工作。(4)系统正式上线运行的技术保障工作系统正式上线运行的技术保障工作 系统正式上线后，开发方在约定的一段时间内系统正式上线后，开发方在约定的一段时间内为用户方提供技术保障，从技术、操作使用、日常为用户方提供技术保障，从技术、操作使用、日常管理上及时解决用户方出现的问题。管理上及时解决用户方出现的问题。(5)软件系统正式运行过程记录软件系统正式运行过程记录 正式运行记录主要关注以下几个方面：正式运行记录主要关注以下几个方面：1)软件使用时间记录软件使用时间记录 包括开始使用时间、结束时间，累计使用时间包括开始使用时间、结束时间，累计使用时间长度等。长度等。2)软件使用情况记录软件使用情况记录 记录数据录入、查询、处理、传递、输出效率记录数据录入、查询、处理、传递、输出效率等软件功能操作情况。等软件功能操作情况。3)环境变化情况记录环境变化情况记录 记录硬件环境变化、软件操作系统环境变化、设记录硬件环境变化、软件操作系统环境变化、设置参数变化、版本变化置参数变化、版本变化(维护与升级维护与升级)、操作人员的变、操作人员的变更。更。4)软件异常情况软件异常情况 包括错误和异常中断等信息。包括错误和异常中断等信息。5)软件使用情况分析软件使用情况分析 包括使用情况统计分析，定期或不定期的使用意包括使用情况统计分析，定期或不定期的使用意见征求会议，收集软件用户对软件功能的意见和看法。见征求会议，收集软件用户对软件功能的意见和看法。10.5 软件系统的维护软件系统的维护 软件维护是在软件运行过程中出现了问题后需要软件维护是在软件运行过程中出现了问题后需要开展的工作。开展的工作。10.5.1 软件维护的方法软件维护的方法 软件系统的维护活动通常分为四类：软件系统的维护活动通常分为四类：(1)改正性维护改正性维护 修改软件系统在使用过程中发现的软件错误。修改软件系统在使用过程中发现的软件错误。要求软件测试会找出一个大型软件系统的全部潜要求软件测试会找出一个大型软件系统的全部潜在错误是不合理的，任何大型程序在运行过程中，都在错误是不合理的，任何大型程序在运行过程中，都会出现错误。改正一个或多个错误的过程就是改正性会出现错误。改正一个或多个错误的过程就是改正性维护的工作内容。维护的工作内容。(2)适应性维护适应性维护 即修改软件以适应环境的变化。即修改软件以适应环境的变化。计算机领域各个方面的发展变化十分迅速，硬件、计算机领域各个方面的发展变化十分迅速，硬件、操作系统等更新速度非常快。因此，改造软件使之能操作系统等更新速度非常快。因此，改造软件使之能与改变了的环境相适应是必需的也是常见的事。与改变了的环境相适应是必需的也是常见的事。(3)完善性维护完善性维护 即根据用户的要求改进或扩充软件使它更完善。即根据用户的要求改进或扩充软件使它更完善。当一个软件包交付使用后运行很成功的时候，软当一个软件包交付使用后运行很成功的时候，软件用户会根据实际业务的需要不断提出增加新的功能，件用户会根据实际业务的需要不断提出增加新的功能，修改现有的功能和提高总体的性能等各种建议。为了修改现有的功能和提高总体的性能等各种建议。为了满足这一类要求，就要进行完善性维护。这项维护活满足这一类要求，就要进行完善性维护。这项维护活动要占全部软件维护工作量的很大一部分。动要占全部软件维护工作量的很大一部分。(4)预防性维护预防性维护 即修改软件为将来的活动预先做准备。即修改软件为将来的活动预先做准备。为了进一步改进软件的可维护性和可靠性，或者为了进一步改进软件的可维护性和可靠性，或者为进一步提供一种更好的发展基础而对软件进行更改为进一步提供一种更好的发展基础而对软件进行更改时，这种活动通常叫做预防性维护。目前这一类维护时，这种活动通常叫做预防性维护。目前这一类维护是比较少的。是比较少的。预防性维护5%改正性维护20%适 应 性 维护25%10.5.2 软件的可维护性软件的可维护性 软件的可维护性可以简单定义为：软件能够被理软件的可维护性可以简单定义为：软件能够被理解、被校正、被修改或被改善的难易程度。解、被校正、被修改或被改善的难易程度。影响软件可维护性最主要的因素有：影响软件可维护性最主要的因素有：对整个系统的总体建构和分析；对整个系统的总体建构和分析；所采用的分析、设计方法；所采用的分析、设计方法；所采用的编程方法；所采用的编程方法；开发人员的技术熟练程度；开发人员的技术熟练程度；软件项目的管理技术。软件项目的管理技术。另外，以下因素也会对可维护性有重要影响：另外，以下因素也会对可维护性有重要影响：1)软件设计人员是否受到严格的规范化工作培软件设计人员是否受到严格的规范化工作培训；训；2)是否采用主流的编程语言；是否采用主流的编程语言；3)是否采用主流的操作系统；是否采用主流的操作系统；4)是否采用标准化的文档资料结构和文档形成是否采用标准化的文档资料结构和文档形成机制；机制；5)是否保存规范化的测试资料。是否保存规范化的测试资料。吉尔吉尔(Gilb)提出了与维护工作量有关的可维护性提出了与维护工作量有关的可维护性度量：度量：1)了解问题的时间；了解问题的时间；2)行政管理拖延的时间；行政管理拖延的时间；3)收集维护工具的时间；收集维护工具的时间；4)分析问题的时间；分析问题的时间；5)改变规格说明的时间；改变规格说明的时间；6)具体的改错或修改的时间；具体的改错或修改的时间；7)局部测试时间；局部测试时间；8)整体测试时间；整体测试时间；9)维护重审时间；维护重审时间；10)总体恢复时间。总体恢复时间。申请维护何种维护？确定优先顺序排到日程？排到日程？指定人员开始分析问题设计、编程、测试复审合格？交付程序、文档变更审批通过？结束适应性维护完善性维护改正性维护NN等待NN问题严重？确定优先顺序NYYYYY等待10.5.3 软件维护的工作流程软件维护的工作流程 规范化的软件项目管理必须在软件维护阶段收集、规范化的软件项目管理必须在软件维护阶段收集、记录维护信息，否则不能够估计维护技术的有效程度，记录维护信息，否则不能够估计维护技术的有效程度，不能确定程序的优劣程度，也不能确定维护的实际费不能确定程序的优劣程度，也不能确定维护的实际费用。用。应当收集的维护信息有：应当收集的维护信息有：1)MRF（维护申请表单）名称或编号（维护申请表单）名称或编号 2)维护类型维护类型 3)程序名称程序名称 4)程序投入使用的日期程序投入使用的日期 5)从投入使用以来，程序运行过程从投入使用以来，程序运行过程 6)与程序相关的以前故障处理情况与程序相关的以前故障处理情况 7)所用的编程语言所用的编程语言 8)程序修改的位置程序修改的位置 9)原程序的源语句原程序的源语句 10)修改后程序的语句修改后程序的语句 11)修改前后程序功能的变化修改前后程序功能的变化 12)维护开始和结束的日期维护开始和结束的日期 13)修改所付出的工时修改所付出的工时 14)累计花费在维护上的工时数累计花费在维护上的工时数 15)维护工作的净收益维护工作的净收益 16)软件工程师的姓名软件工程师的姓名 可采用这些信息内容作为维护数据库的基础，维可采用这些信息内容作为维护数据库的基础，维护工作进行评价。护工作进行评价。软件维护任务完成后，应进行简单的情况复审。软件维护任务完成后，应进行简单的情况复审。情况复审一般要回答下列问题：情况复审一般要回答下列问题：1)目前状况下，设计、编写程序、测试，哪一方目前状况下，设计、编写程序、测试，哪一方面可以改进面可以改进?2)哪些维护资源应该有，但实际却没有哪些维护资源应该有，但实际却没有?3)本次维护工作中造成困难的主要问题是什么本次维护工作中造成困难的主要问题是什么?4)根据维护申请的种类是否可以看出需要预防性根据维护申请的种类是否可以看出需要预防性维护维护?情况复审对将来的维护工作思路会有重要的影响，情况复审对将来的维护工作思路会有重要的影响，并为提高软件组织的管理效能提供重要的参考信息。并为提高软件组织的管理效能提供重要的参考信息。软件维护可能产生副作用。软件维护可能产生副作用。副作用是指由于修改软件而造成的错误或发生其副作用是指由于修改软件而造成的错误或发生其他不希望发生的情况。他不希望发生的情况。修改的内容不同，副作用也不修改的内容不同，副作用也不 一样。最危险的副一样。最危险的副作用是修改软件源程序而产生的。作用是修改软件源程序而产生的。下列对源程序的修改更易产生错误：下列对源程序的修改更易产生错误：1)改变一个子程序、函数、变量定义改变一个子程序、函数、变量定义 2)为改进运行性能所作的修改为改进运行性能所作的修改 3)改变了逻辑运算过程改变了逻辑运算过程 4)设计的变动造成了较大的程序变动设计的变动造成了较大的程序变动 5)改变了边界测试条件改变了边界测试条件 详细文档资料可帮助维护人员尽量避免产生因程详细文档资料可帮助维护人员尽量避免产生因程序修改产生的致命错误，仔细的回归测试可以帮助消序修改产生的致命错误，仔细的回归测试可以帮助消除部分错误。除部分错误。修改数据也可产生副作用，这是由于修改软件修改数据也可产生副作用，这是由于修改软件特定的信息结构所引起的。特定的信息结构所引起的。下述数据改变往往产生副作用：下述数据改变往往产生副作用：1)更新定义局部的及全程的常数更新定义局部的及全程的常数 2)重新定义记录和文件的格式重新定义记录和文件的格式 3)改变一个数组的大小或改变高层数据结构的大改变一个数组的大小或改变高层数据结构的大小小 4)对控制标志或指针的重新初始化对控制标志或指针的重新初始化 5)重新安排输入输出参量重新安排输入输出参量 修改数据的副作用可以通过完善的设计文档资料修改数据的副作用可以通过完善的设计文档资料加以限制。加以限制。修改文档资料也可产生副作用。修改文档资料也可产生副作用。用户认为软件与其文档资料所描述的一致，如用户认为软件与其文档资料所描述的一致，如果文档资料不能明确地反映软件的实际状况，可能果文档资料不能明确地反映软件的实际状况，可能比完全没有文档资料还要糟糕，因为细致地阅读文比完全没有文档资料还要糟糕，因为细致地阅读文档资料将得到对软件特性的错误认识。档资料将得到对软件特性的错误认识。为了解决某些维护申请，有时并不需要改变软为了解决某些维护申请，有时并不需要改变软件设计