《软件项目验收》PPT课件.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)预防性维护 即修改软件为将来的活动预先做准备。为了进一步改进软件的可维护性和可靠性，或者为进一步提供一种更好的发展基础而对软件进行更改时，这种活动通常叫做预防性维护。目前这一类维护是比较少的。,10.5.2 软件的可维护性 软件的可维护性可以简单定义为：软件能够被理解、被校正、被修改或被改善的难易程度。影响软件可维护性最主要的因素有：对整个系统的总体建构和分析；所采用的分析、设计方法；所采用的编程方法；开发人员的技术熟练程度；软件项目的管理技术。,另外，以下因素也会对可维护性有重要影响：1)软件设计人员是否受到严格的规范化工作培训；2)是否采用主流的编程语言；3)是否采用主流的操作系统；4)是否采用标准化的文档资料结构和文档形成机制；5)是否保存规范化的测试资料。,吉尔(Gilb)提出了与维护工作量有关的可维护性度量：1)了解问题的时间；2)行政管理拖延的时间；3)收集维护工具的时间；4)分析问题的时间；5)改变规格说明的时间；6)具体的改错或修改的时间；7)局部测试时间；8)整体测试时间；9)维护重审时间；10)总体恢复时间。,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)重新安排输入输出参量 修改数据的副作用可以通过完善的设计文档资料加以限制。,修改文档资料也可产生副作用。用户认为软件与其文档资料所描述的一致，如果文档资料不能明确地反映软件的实际状况，可能比完全没有文档资料还要糟糕，因为细致地阅读文档资料将得到对软件特性的错误认识。为了解决某些维护申请，有时并不需要改变软件设计或源程序，而只需指出在用户文档资料中的某些不清楚的地方就行了，对于这类问题，维护工作的重点就是修改文档资料。,10.6 软件系统的评价 如何评价软件系统，美国的和R.Bmwn先后提出了三个层次的评价度量模型：软件质量要素 评价准则 度量(1)软件质量要素 软件质量可分解成六个要素，这六个要素是软件的基本特征。,1)功能性 软件所实现的功能满足用户需求的程度。功能性反映了所开发的软件是否全部实现了用户要求的功能。2)可靠性 在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，也反映了在故障发生时能继续运行的程度。,3)易使用性 对于一个软件系统而言，易使用性是指用户学习、操作、准备输入和理解输出时所做的努力程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。4)效率 在指定的条件下，效率即用软件实现某种功能所需的计算机资源(包括时间)的有效程度。效率反映了在完成功能要求 时，有没有浪费资源。,5)可维护性 其含义是软件能够被理解、校正、被修改或被改善的难易程度。可维护性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的难易程度。6)可移植性 从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。,(2)评价准则 可分成22点，包括精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。(3)度量 对于不同规模、不同类型的软件，如系统软件、控制软件、管理软件，在质量要求、评价准则、度量问题等方面的侧重点会有所不同，应加以区别。,用户在选择软件项目承担方时，需要考察其是否建立起丁目己的软件质量度量和评价数据，数据库中是否存有与本企业所在行业相关的软件，是否具有相关的开发经验，这些都是软件系统优良性能的基本保证。,应用环境生存期长适时系统要在不同环境中使用银行系统中使用,重点考虑的因素可移植性、可维护性可靠性、效率可移植性可靠性、功能完整性,作业：1.项目验收时，项目承担方需要做哪些准备工作？2.项目验收时，用户方需要做哪些准备工作？3.软件系统交接需要做哪些工作？,