当前位置:大文秘网>范文大全 > 公文范文 > 软件项目验收需要哪些文档5篇

软件项目验收需要哪些文档5篇

时间:2022-09-05 10:10:05 来源:网友投稿

软件项目验收需要哪些文档5篇软件项目验收需要哪些文档 软件项目验收流程各步骤内容 项目验收过程 验收作为项目执行过程中的一个重要的里程碑,对公司和客户具有重要的意义。 一、验收申请二、验收下面是小编为大家整理的软件项目验收需要哪些文档5篇,供大家参考。

软件项目验收需要哪些文档5篇

篇一:软件项目验收需要哪些文档

项目验收流程各步骤内容

 项目验收过程

  验收作为项目执行过程中的一个重要的里程碑,对公司和客户具有重要的意义。

  一、验收申请 二、验收准备 2.1 开发商资料收集

  根据软件项目的特点,在验收时应收集以下文档:

  除上述文档外,还应单独收集、保存各应用软件源程序代码及开发商所用第三方资源信息。开发商所使用的第三方控件,除已经得到审计署的许可之外,必须提供控件的源代码,并拥有授权使用的证明或保证(由开发商提供无版权争议承诺书);对于原始程序代码,要求能够在本地不经过任何特殊设置,即可编译并正常运行。源程序清单中列举的项目应该和源程序一一对应。

  2.2 最终用户资料收集

  依据软件开发需求说明书和概要设计说明书,编写相关软件的用户满意度调查表,该调查表应该涵盖软件在需求说明书中列举的所有模块,包含软件在不同操作系统下的运行情况等。最终用户或甲方项目组按照实际情况填写该调查表。

  三、验收测试 验收测试是软件开发结束后,用户对软件产品投入实际应用以前进行的最后一次质量检验活动,它要回答开发的软件产品是否符合预期的各项要求,以及用户能否接受的问题。由于它不只是检验软件某个方面的质量,而是要进行全面的质量检验,并且要决定软件是否合格,

 因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划,进行软件配置评审、功能测试、性能测试等多方面检测。

 软件验收测试分为三部分:文档代码一致性审核、软件配置审核和可执行程序测试,其顺序可分为:文档审核、源代码审核、配置脚本审核、测试程序、平台 API测试、集成测试、验收测试等。文档代码一致性审核、软件配置审核是软件部署和实施全面验收测试的基础,由各应用软件验收责任人检查它们的完整性;由于工程开发的各软件运行环境均基于审计管理系统、审计实施系统平台,最终的集成测试、验收测试由德华工贸员工、验收专家所有参与验收工作的人员一起完成。

  3.1 文档审核

  文档审核的主要要求是确定软件开发的所有过程都在提交文档的控制下,对文档的具体要求如下:

  (1)文档完备性:是否按照合同及其附件要求提交了全部文档;

  (2)内容针对性:指文档是否是甲方要求的文档;文档的内容应该按照功能模块的重要性在论)上达到不同的详细程度;

  (3)内容充分性:指该文档全面、详细的程度; (4)文档的价值:文档应该能够反映软件开发的整个过程,即需求中提到的功能在概要设计中体现,在详细设计中实现,在测试计划中检验;

  (5)图表翔实性:是否包含了足够的图形和表格;

  (6)符合甲方规范程度:是否很好地符合甲方要求的规范、标准; (7)内容一致性:是否存在前后矛盾;是否存在需求说明中提到的功能在概要设计、详细设计中没有涉及的情况; (8)文字明确性:不使用“可能”、

 “也许”、“待定”等语义含糊不清的语句; (9)易读性:能够在一篇文档中说明清楚的内容,尽量不要拆分成若干文档,不要循环引用,文档目录一目了然,结构清晰。

  3.2 源代码审核 源代码审核的主要要求是确保开发商将全部源程序交付甲方,并确保交付的代码没有版权问题(由开发商提供无版权争议承诺书)对源代码审核的具体要求如下:

  3.2.1 版权明晰

  (1)提交的代码中注释版权的地方均应去掉版权声明,或声明版权为审计署所有。

 (2)得到甲方允许,可以使用的控件,由开发商提供无版权争议承诺书。使用其他的具有源代码的控件,均需要当作提交代码的一部分,直接置于编译环境的工程文件中,在编译发布时无需额外设置。

 3.2.2 代码完整

  (1)开发商必须把所有实现用户需求的代码交付甲方。

  (2)除非已经得到甲方的允许,使用的控件也必须有源代码,并得到授权使用证明;由开发商提供无版权争议承诺书。

  (3)包含开发工具的程序文件;要求能够在甲方计算机中正常编译、运行;除非得到甲方允许,在甲方计算机中编译的时候无需额外安装开发工具的插件或控件。

  3.2.3 可读性强 注释是软件可读性的具体体现。程序注释量不少于程序编码量的 30%。程序注释不能用抽象的语言(如“处理”、“循环”等),要精确表达出程序的处理说明。为避免每行程序都使用注释,可以在一段程序的前面加一段注释,有明确的处理逻辑。

 3.3 配置文件审核

 对于 B/S 程序,部署维护是软件生存周期中最长的一个过程,配置文件的审核显得尤为重要。对配置文件的审核要求与源代码的审核要求完全一致。

  3.4 测试用例编写及测试程序、脚本审核

  这个过程是在文档审核和配置脚本审核后,为了检验通过源代码编译后的程序是否满足设计需求。检验方式主要是 API 测试、集成测试、验收测试;这一阶段应该完成设计及其有关测试所包括的特性,还需要完成测试所需的测试用例和测试规程,并规定特性的通过准则。

  (1)测试用例说明:列出用于输入的具体值以及预期的输出结果,并规定在使用具体测试用例时,对测试规程的各种限制。要求将测试用例与测试设计分开,可以使它们用于多个设计并能在其它情形下重复使用。

  (2)测试规程说明:规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。

  测试方案

  (1)针对性测试方案:从满意度调查表中筛选出可能不符合需求设计的功能模块,编写针对具体模块设计的测试方案。这种方案的实现耗时短,根据实际使用情况调查软件的具体实现,适合在软件得到较大面积试用后采取的验收测试。

  (2)抽样测试方案:在设计文档中随机选取,根据抽样的样本大小不同,最后得到的结论可能会出现差异。这种方案的实现耗时可长可短,适合软件未得到大面积适用前验收时采用。

  3.5 平台 API 测试 常见的白盒测试是单元测试。单元测试是测试中

 最小单位的测试。简而言之,就是拿一个函数出来,加上驱动模块,让它能够运行起来,然后设计一些用例测试其内部的控制点(如:条件判断点、循环点、选择分支点等)。驱动模块是模拟调用被测函数的函数。

 根据设计文档选取关键函数和所有开放的 API,设计测试用例。

  3.6 集成测试/压力测试 常见的黑盒测试包括:集成测试,系统测试。集成测试是在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。通过一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作,在协同工作时是否能够达到功能要求。

  3.7 验收测试

  目的是检验待验收软件是否对平台和其它软件保持良好的兼容性。

  四、验收结论(成绩评定标准)

  验收结束时,根据以上文档,填写验收结论,对软件的质量做出评价 1.优秀

  1)材料完整

  2)软件可正常运行

  3)实现项目软件需求说明书要求的各项功能需求

  4)软件界面友好,易于交互

  5)软件功能新颖,有较强创新

  2.合格

 1)本标准第 2.1 条要求的材料完整

  2)可正常运行实现功能达到软件需求说明书要求的三分之二以上

  3.不合格

  1)标准第 2.1 条要求的材料不完整

  2)软件不能运行

  3) 软件需求说明书要求的主要功能 。

篇二:软件项目验收需要哪些文档

信息化I

 T Applicati on 拿到新房钥匙的业主们兴奋之余,一般都会冷静地查清楚房间的面积是否够数,卫生间 是否漏水⋯⋯当企业拿到新信息系统的时候 ,一定要冷静验货,如果等将来再发现问 题 ,可就来不及了! 软件验收全攻略 在 莫名其妙的问题:软件突然 停止运行,一直输入的密码 这次怎么也进不去⋯⋯。为 什么会这样呢?其实,这种 情况极有可能是软件自身程 序缺陷造成的,这些小BUG (缺陷)在大部分软件中都存 在。由于软件问题导致个人 电脑出现故障造成的损失可 能不大,但如果企业的系统 由于软件缺陷无法运行,就 96 NEWWAVE 会给企业带来巨大的损失。

 企业信息化有两个方面是必须的 顶级的硬件设备和个性化的软件系统。

 如果软件不能很好地跟硬件配合,那么 就会导致硬件功能得不到充分地发挥。

 也就是说劣质的软件会拖硬件的后腿,

 同时造成资源与资金的潜在性浪费。无 形中就增加了企业本来就不低的信息化 成本,尤其是对软件项目外包的中小企 业来说,这是非常重要的。

 那么,在外包的软件项目完成之 后,企业首先应该做些什么呢? 毫无疑问,就是严格的软件验收。

 ● 文 /司马蕾 软件测试——重点在 “负面” 企业对开发商交付的软件系统产 品进行测试是软件验收的必须环节,就 像我们在超市买了个热水壶回家之后要 先用它烧两壶开水试试一样。质量是目 的,测试是手段,任何一个软件系统的 生命周期都要经过:需求分析、系统设 计、编码、测试验收、投产和维护几个 阶段。生命周期的每一个周期都有确定 的任务,并且必须产生一定规格的文档 (资料),提交给下一个周期作为继续工 作的依据。

 企业对软件系统进行测试,其目的 在于检验它是否满足规定的需求或是弄 清预期结果与实际结果之间的差别。可 以分为以下几种 单元测试、整体测试、 有效性测试、系统测试、验收测试等。

 其中单元测试、整体测试、有效性测试 是在研制单位内部进行的,而系统测试 和验收测试是在编码结束后,对软件项 目的综合测试。

 在信息化项目完成之后,企业不要 忙着使用,必须经过一个严格的测试环 节,才能验货付款。通常验收测试内容 包括:功能度、安全可靠性、易用性、 可扩充性、兼容性、效率、资源占用率、 用户文档等方面。

 在测试过程,专家认为:重点要进 行周全的 “负面”测试。昆山泓森信息 维普资讯 http://www.cqvip.com

 科技管理顾问有限公司执行总裁黄绍良 认为:只有进行了有效的负面测试,才 是全面的测试。业界关于大型软件系统 存在漏洞而使得黑客入侵的新闻时有耳 闻,究其原因,主要的一点就是没有进 行有效的负面测试。例如,对于某个输 入栏,系统设计者、测试者都按照系统 规划说明中指出的那样,输入ABC这 样的三个字母,系统运行正常。那么, 如果有人故意弄错了,输入 123呢?一 个设计缜密的系统,会有效防止这种错 误。但是,不幸的是这样的“简单错误” 软件系统验收指南 虚幻的字眼。什么才是高质量的软件,

 如何衡量这质量呢?每一个人都有自己 的解释,没有一个标准。

 所以,即使在软件项 目结束后,企 业往往会产生疑问,这套系统能不能满 足实际的需要呢?验收就是在软件项 目 结束后,企业对软件项目投入运行前进 行的最后一次质量检验活动。通过验 收,验证软件项目是否符合设计需求, 功能实现的正确性及运行安全可靠性。

 企业希望通过最后的严格的验收测试, 可发现软件存在的、潜在的重大问题, 了解项目背景与验收要求 建立模拟网络环境并模 定义测试 目标 (3)

 拟测试 f

 )分析项目需求 确定测试策略 建立项 目小组 建立测试环境 现场配备测试环境 编写应用的测试脚本 确定项 目时间表 执行现场验收测试项 目 设计测试系统结构 (4) 分析从测试中收集的数据 (2)设计测试环境 设计测试用例 进行测试 研究问题类型推荐改进意见 运行验收测试报告 并不鲜见,有时候还会造成重大损失。

 所以在测试环节,一个合格的软件项目 管理人员必须跳出惯性思维,进行有效 的负面测试。

 软件验收——手段最重要 企业把信息化的项目交给开发商 去研发、实施,在某种意义上与我们找 建筑公司盖房子一样。我们可以告诉建 筑公司需要什么效果,哪种户型,需要 哪些材料、何时交工等等,然后让建筑 公司提供有关工程的设计图、效果图和 施工计划。如果自己有能力的话,我们 可以自己弄好设计图、效果图,只是让 建筑公司施工。不过,软件开发毕竟跟 盖房子不一样,前者更难以把握。在计 算机行业,业内人士也常谈到质量问 题,但 “软件质量”给人的感觉往往是 最大限度保证软件项目的质量。

 验收文档资料一一要全面 企业应该知道,软件开发过程缺 乏很强的透明度,只有在信息化项目 完成之后,才可以看到项 目所包含 的 软件载体和文档资料。所以在进行软 件系统的测试前有必要检查软件需求 与任务目标是否一致,检查所交付的 程序和数据以及相应的软件支持环境 是否符合要求,检查文档与程序的一 致性,检查软件研制过程中形成的文 档是否齐全、文档的准确性和完整性 以及是否通过了有关评审。

 验收项目系统一一要仿真 在进行项目系统验收的时候,企业 应该从真正应用此系统的部门挑选足够 的人力来参与系统验收的过程,同时也 可以借助辅助工具。验收者的依据将主 要存在于实用的要求及被验收产品的技 术合同约定,同时遵从产品的行业规范 与标准。可以运用安装/卸载测试、功 能测试、性能测试、安全测试等多种验 收测试手段。

 在软件全面验收阶段是多种测试 手段并用的时期,在运用这些手段的 是,除了必要的技巧之外,专家提醒企 业,测试手段的仿真性非常重要。比如 在进行安全测试时测试人员应该假扮非 法入侵者,采用各种办法试图突破防 线。例如,想方设法截取或破译口令; 专门使用软件破坏系统冲击软件的保护 机制;故意导致系统失败,企图趁恢复 之机非法进人 试图通过浏览非保密数 据,推导所需信息等等。理论上讲,只 要有足够的时间和资源,没有不可进入 的系统。因此系统安全设计的准则是, 使非法侵入的代价超过被保护信息的价 值。此时非法侵入者已无利可图。

 通常情况下,如模仿成百上千个用 户大量访问,重复执行和运行测试看系 统是否稳定,监测系统抗疲劳程度,对 安全系统进行各种各样的破坏等方面的 测试是由研制单位来进行的,因为测试 过程中会涉及到一些专业自动化辅助工 具,手工操作是不可能完成的。

 事实上,最后的验收测试阶段固然 重要,其实在软件项目的初始阶段,企 业更应该首先认识到开发软件的需要, 然后通过可行性研究,明确目标,确定 需求,确定软件获得的策略,并定义软 件验收的标准。这样,最后的验收测试 才会顺利的进行。

 俗话说 “编筐编篓,全在收口”,外 包的软件系统能否投入正式使用,项目 的验收、测试至关重要。相比房地产项 目来说,看得见摸不着的软件开发项目 显得更加“虚幻”一些。因此,在软件系 统项目 “收口”企业千万要擦亮眼。口皿 NEWWAVE 97 维普资讯 http://www.cqvip.com

篇三:软件项目验收需要哪些文档

软件项目文档要求(全过程)阶段123456项目开工文档7 实施进度计划交付件(每一项均为独立文本)招/投标文件中标通知书合同项目经理任命书实施方案实施方案报审表共包含但不仅限于合同文档结构中以下5项内容:1、项目计划(该系统是如何被开发与实施的);2、实施计划(包括实施、培训和维护计划);3、软件开发迭代计划(每一个迭代的详细开发活动);4、维护计划;5、系统验收计划包含内容(项目施工合同内容)共包含但不仅限于合同文档结构中以下1项内容:1、员工质量手册(对员工管理和持续性质控制方案)进度计划报审表开工申请开工令10(监理方签署发布)11 调研计划12 调研报告89系统需求调研,一定要有相关的业务单位人员参与,这一不工作至关重要,调研记录中需要有用户单位签字共包含但不仅限于合同文档结构中以下5项内容:1、前景文档(项目开发的目标);2、用例模型(定义系统的功能性需求);3、定义系统的功能性规格和非功能性规格4、UML需求设计文档;5、词汇表(定义项目开发中所用到的专业词汇)13 软件规格需求说明书14 需求分析规格说明书审批表15 概要设计说明书程文档共包含但不仅限于合同文档结构中以下20项内容:1、系统编码设计(系统中信息所使用的编码方案,编码应该易于计算机和人的设计处理);2、设计模型(对系统设计结果的记录);3、数据库数据模型设计文档;4、标准化设计文档;5、静态类设计及类关系文档;6、动态类交互设计文档;7、功能设计文档;8、非功能设计文档;9、界面设计文档;10、部署模型设计文档;11、数据模型(包括概念模型和物理模型;采用ER图)12、质量风险管理计划(在开发过程中是如何保证质量和管理风险的);13、程序语言和编辑手册;14、作业控制参考手册;15、数据通讯手册;16、软件参考手册;17、安全指南(系统保护机制、使用方法和相互作用);18、安全设计手册(安全保护原理、功能界面、安全策略、系统结构和安全功能);

 阶段项目过程文档4、标准化设计文档;5、静态类设计及类关系文档;6、动态类交互设计文档;应用软件项目文档要求(全过程)7、功能设计文档;8、非功能设计文档;交付件 包含内容9、界面设计文档;(每一项均为独立文本)

 (项目施工合同内容)10、部署模型设计文档;11、数据模型(包括概念模型和物理模型;采用ER图)12、质量风险管理计划(在开发过程中是如何保证质量和管理风险的);13、程序语言和编辑手册;14、作业控制参考手册;15、数据通讯手册;16、软件参考手册; 16 详细设计说明书17、安全指南(系统保护机制、使用方法和相互作用);18、安全设计手册(安全保护原理、功能界面、安全策略、系统结构和安全功能);19、流程图(业务模型;数据流程图;系统流程图;系统资源图);20、系统架构设计说明书(采用UML余元记录的系统架构模型,对非功能性需求的解决方案,以及界17 数据库数据设计说明书共包含但不仅限于合同文档结构中以下2项内容:1、数据库结构设计文件和数据管理系统手册(详细说明数据库结构设计和数据库管理操作);2、备份操作过程手册(详细数据备份操作);共包含于合同文档结构中以下2项内容::1、评审意见;2、评审结论采用MUL语言记录的系统设计结果18 概要设计说明书审批表19 详细设计说明书审批表20 测试用例21 灾备方案22 源代码说明系统运行过程中出现突发事件、网络、软硬件故障的解决方案所有的源代码文件、所有的单元测试源代码文件、所有与源程序相关的控件共包含但不仅限于合同文档结构中以下7项内容:1、项目阶段性总结报告;2、项目进度报告;3、工作月报(合同中要求有);4、周工作进度报告(可用项目周报代替);5、单元测试报告(所有模块的单元测试报告,包括测试用例报告、代码覆盖率报告等);6、问题报告和软件变更方案;7、程序说明文件;23 阶段性项目进度总结报告242526272829303132333435测试方案测试计划测试计划/方案审批表功能测试报告性能测试报告集成测试报告数据迁移计划书用户使用报告初验方案初验方案报审表初验申请表项目初验报告该系统如何被测试的系统测试的结果,包括通过的测试用例数、未通过的测试用例数及相关分析对历史数据的顺利迁移的具体实施计划包括:1、初验总结;

 应用软件项目文档要求(全过程)阶段交付件(每一项均为独立文本)36 项目完成分析报告包括:1、初验总结;包含内容(项目施工合同内容)项目初验文档37 用户操作手册共包含但不仅限于合同文档结构中以下4项内容:1、用户手册(用户使用手册);2、操作手册(软件操作详细说明手册);3、维护手册;4、安全操作手册(安全操作和管理,警告功能,参数设置和权限管理);共包含但不仅限于合同文档结构中以下3项内容:1、系统软件光盘(安装光盘);2、控件光盘;3、发布说明(该发布版本主要增加了哪些功能、改正了哪些错误等);共包含但不仅限于合同文档结构中以下2项内容:1、部署计划(如何将系统部署到生产环境中去);2、安装及配置手册(软件产品、数据库及应用服务器配置安装步骤);包括:1、培训方案;2、培训计划;3、培训手册(针对最终用户的培训教材);共包含但不仅限于合同文档结构中以下3项内容::1、部署报告;2、问题处理报告;3、试运行总结;38 光盘39 部署手册40 培训教材41 系统上线方案42 系统试运行报告项目终验文档4344454647484950515253用户使用报告终验方案终验方案报审表项目终验报告终验证书问题处理报告程序修改报告功能变更报告及变更文档项目开发总结项目文档移交清单

 备注监理签发文档监理签发文档监理签发文档监理签发文档

 备注监理签发文档监理签发文档如有监理签发文档如有用户签发监理审核监理审核

 备注

篇四:软件项目验收需要哪些文档

交付文档 交付(归档)时间 命名规则 形式 纸质规划立项 基本构想PID 基本构想DR通过项目或系统名_基本 构 想PID_yyyymmdd_v1.EXCELPPT√合同会签表 合同会签结束 同上 WORD √项目合同 合同会签结束 同上 WORD √项目价格清单 合同会签结束 同上 EXCEL √合同技术协议 合同会签结束 同上 WORD √项目主计划 启动会结束后项目或系统名_项目 主 计 划_yyyymmdd_v1.0EXCEL √项目启动会PPT 启动会结束后 同上 PPT √项目组管理规定启动会结束后 同上WORDEXCEL√需求调研计划 需求调研前项目或系统名_需求 调 研 计 划_yyyymmdd_v1.0EXCEL √需求调研总结 需求调研后 同上 PPT √需求调研记录 需求调研后 同上 WORD业务蓝图 需求调研后 同上 Visio单据清单 需求调研后 同上 EXCEL基础数据清单 需求调研后 同上 EXCEL功能清单 需求调研后 同上 EXCEL接口清单 需求调研后 同上 EXCEL报表清单 需求调研后 同上 EXCEL功能设计书 系统设计评审后项目或系统名_功能 设 计 书_yyyymmdd_v1.0WORDEXCEL数据库设计书 系统设计评审后 同上WORDEXCEL接口设计书 系统设计评审后 同上 EXCEL关键程序流程图系统设计评审后 同上 Visio程序设计说明 系统设计评审后 同上WORDEXCEL基础数据说明书系统设计评审后 同上 EXCEL选型招标项目启动需求调研系统设计

 DEMO 系统设计评审后 同上程序开发计划 开发前项目或系统名_功能 开 发 计 划_yyyymmdd_v1.0EXCEL程序源码 开发后 同上通用模块调用手册开发后 同上 EXCEL编码规范说明 开发后 同上WORDEXCEL单元测试报告 开发后 同上WORDEXCEL综合测试报告 开发后 同上WORDEXCEL业务测试计划 测试前领域_项目或系统名_业务测试计划_yyyymmdd_v1.0EXCEL业务测试操作手册测试前 EXCEL用户手册 测试后 同上 WORD培训计划及培训报告测试后 同上 EXCEL系统运行维护手册测试后 同上WORDEXCEL业务测试报告 测试后 同上WORDEXCEL技术验收 技术验收报告 技术验收 同上 PPT正式上线计划 上线前领域_项目或系统名_业务测试计划_yyyymmdd_v1.0EXCEL正式上线报告 上线后 同上 EXCEL文档资料交接单上线后 同上 EXCEL √运行监控报告 项目验收前领域_项目或系统名_运行监控报告_yyyymmdd_v1.0PPTKPI&ROI实绩 上线后 同上 PPT业务功能性能情况上线后 同上PPTEXCEL业务验收 业务验收报告 项目验收后 同上 EXCEL √业务测试实施上线应用监控编码开发

 电子 提交者√ IS窗口√ IS窗口√IS窗口商务经理√ 商务经理√IS窗口商务经理√ 项目经理√ 项目经理√ 项目经理√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组

 √ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组

 阶段 交付文档 交付(归档)时间 命名规则 形式 纸质基本构想PID 基本构想DR通过领域_项目或系统名 _ 基 本 构 想PID_yyyymmdd_v1.EXCELPPT√立项审批表 立项结束领域_项目或系统名 _ 立 项 审 批_yyyymmdd_v1.0EXCEL √项目资源清单 立项结束 同上 EXCEL √招标申请表 招标开始 同上 WORD √项目招标书 招标开始 同上 WORD √项目应标书 招标开始 同上 WORD √开标结果会签 招标结束 同上 WORD √合同会签表 合同会签结束 同上 WORD √项目合同 合同会签结束 同上 WORD √项目价格清单 合同会签结束 同上 EXCEL √合同技术协议 合同会签结束 同上 WORD √项目主计划 启动会结束后领域_项目或系统名 _ 项 目 主 计 划_yyyymmdd_v1.0EXCEL √项 目 启 动 会PPT启动会结束后 同上 PPT √项目组管理规定启动会结束后 同上WORDEXCEL√项目VSS配置 启动会结束后 同上WORDEXCEL√需求调研计划 需求调研前领域_项目或系统名_需求调研计划_yyyymmdd_v1.0EXCEL √需求调研总结 需求调研后 同上 PPT √需求调研记录 需求调研后 同上 WORD业务蓝图 需求调研后 同上 Visio单据清单 需求调研后 同上 EXCEL基础数据清单 需求调研后 同上 EXCEL功能清单 需求调研后 同上 EXCEL接口清单 需求调研后 同上 EXCEL规划立项选型招标项目启动需求调研

 报表清单 需求调研后 同上 EXCEL功能设计书 系统设计评审后领域_项目或系统名 _ 功 能 设 计 书_yyyymmdd_v1.0WORDEXCEL数据库设计书 系统设计评审后 同上WORDEXCEL接口设计书 系统设计评审后 同上 EXCEL关键程序流程图系统设计评审后 同上 Visio程序设计说明 系统设计评审后 同上WORDEXCEL基础数据说明书系统设计评审后 同上 EXCELDEMO 系统设计评审后 同上程序开发计划 开发前领域_项目或系统名_功能开发计划_yyyymmdd_v1.0EXCEL程序源码 开发后 同上通用模块调用手册开发后 同上 EXCEL编码规范说明 开发后 同上WORDEXCEL单元测试报告 开发后 同上WORDEXCEL综合测试报告 开发后 同上WORDEXCEL业务测试计划 测试前领域_项目或系统名_业务测试计划_yyyymmdd_v1.0EXCEL业务测试操作手册测试前 EXCEL用户手册 测试后 同上 WORD培训计划及培训报告测试后 同上 EXCEL系统运行维护手册测试后 同上WORDEXCEL业务测试报告 测试后 同上WORDEXCEL技术验收技术验收报告 技术验收 同上 PPT正式上线计划 上线前领域_项目或系统名_业务测试计划_yyyymmdd_v1.0EXCEL正式上线报告 上线后 同上 EXCEL文档资料交接单上线后 同上 EXCEL √编码开发业务测试实施上线系统设计

 运行监控报告 项目验收前领域_项目或系统名_运行监控报告_yyyymmdd_v1.0PPTKPI&ROI实绩 上线后 同上 PPT业务功能性能情况上线后 同上PPTEXCEL业务验收业务验收报告 项目验收后 同上 EXCEL √应用监控

 电子 提交者√ IS窗口√ IS窗口√ IS窗口√ IS窗口√ IS窗口√ 商务经理√ IS窗口√ IS窗口√IS窗口商务经理√ 商务经理√IS窗口商务经理√ 项目经理√ 项目经理√ 项目经理√ 项目经理√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组

 √ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组√ 项目组

 √ 项目组√ 项目组√ 项目组√ 项目组

篇五:软件项目验收需要哪些文档

XXXXXX 系统项目验收报告

 目 录 一、项目基本信息............................................................................ 二、验收目的................................................................................... 三、验收范围................................................................................... 四、项目验收表...............................................................................

 一、项目基本信息 项目名称

 项目合同甲方

 项目合同乙方

 合同类型 技术开发合同 合同签订时间 2009 年 11 月 17 日

  二、验收目的 目的在于对项目进行全方位的检验与测评,检验乙方提供的软件系统是否遵循软件开发标准的要求,检验各项指标与功能是否与合同要求相吻合。

 三、验收范围

  验收范围以双方签订的技术开发合同所描述的内容为准。具体如下:

 1、项目技术目标

  XXXXXXXX 系统可支持 4 个人工座席客户端,实现 XXXXX 功能。

 2、项目技术内容 (1)、研究设计 XXXXXXX 系统,系统可支持 4 个人工座席客户端;实现。。。。。。。。。。。。。。。。。。。。。。。。。。。; (2)、硬件平台建设:包括研华工控机 1 套;客户端主机 DELL 台式机 10 套,DELL 笔记本 3 套;三汇语音卡 1 套;SONY DSLR-A230L 数码相机 1 套;D-Link 24口 网络交换机 1 套。

 项目于 2010 年 11 月开始组织建设,在甲乙双方密切配合下,项目进展顺利,乙方按合同完成了 XXX 硬件平台建设、软件系统平台开发、数据库建设、系统培训、技术支持等工作,系统于 2010 年 12 月正式投入使用,系统正常运行。

 四、项目验收表 项目名称

 验收单位

 开发单位

 验收时间 2011-5-16 项目负责人

 验收情况 序号 验收内容 应达到要求 验收结论 存在问题 备注 1 可支持4个人工座席客户端 正确运行通过 不通过

  2

 3

 4

 5

 6

 7

 验收结论:

 项目达成合同约定的建设目标和内容,通过验收。

 验 收 人

  验收单位(签章):

推荐访问:软件项目验收需要哪些文档 验收 文档 项目

声明:本网站尊重并保护知识产权,根据《信息网络传播权保护条例》,如果我们转载的作品侵犯了您的权利,请在一个月内通知我们,我们会及时删除。

Copyright©2024 大文秘网 版权所有 备案号:桂ICP备15001782号-