学院中文系综合管理系统（四）

7.4.2系统实施过程的质量保证活动说明

基于以上的质量保证原则和质量保证体系规定，在此举例说明系统平台在实施过程中将发生的重大质量保证活动或由此将产生的质量记录和产品，项目管理与开发阶段划分密切相关，因此主要按照项目实施的具体阶段划分说明。

7.4.2.1需求分析阶段

首先需要经双方协调，形成《需求调研计划》，确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容，经双方同意后按此计划开始调研。调研正式开始前项目开发组应检查所有必要的准备工作已经圆满完成。
项目开发组根据调研中系统平台实际系统需求，编写并向工程领导小组提交《系统需求分析报告》，并由系统平台项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效。
对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接导致项目的成功与否，因此合作双方在此阶段多投入是值得的。而且一旦评审通过并生效，需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。

7.4.2.2系统设计阶段

项目开发组通过对系统的功能、运行和性能要求加以分析，产生一个高层次的系统结构、软件结构、接口和数据格式的设计，并向工程领导小组提交《系统设计报告》（其中包括数据库设计），并由系统平台组织评审并签署评审意见。对其中评审不合格的部分进一步完善和重新策划，评审通过后由双方共同签署评审意见，并正式生效，作为后续软件开发和测试的基础。
该报告内容的变更由双方的现场实施负责人、技术负责人进行交流即可确定，并需向工程领导小组汇报。

7.4.2.4系统开发阶段

根据前面的设计结果，由双方的现场实施负责人、技术负责人讨论确定详细的开发计划，并向工程领导小组提交《项目开发计划》；工程领导小组对《项目开发计划》进行审查，由双方签字后正式生效，并将作为软件开发阶段的项目管理和监控依据，项目开发小组要严格据此计划控制项目进度，按时向工程领导小组汇报工作进展。
为了使用户能够及时获知项目的进展情况，我公司开发小组需要每周向系统平台相关领导提交《项目客户周报》，系统平台用户项目组可以随时对我公司的工作情况进行检查。

7.4.2.5系统实施和试运行阶段

首先需要经双方交流协调，形成《项目实施计划》，确定现场实施的准备工作、人员和日程安排、培训计划、阶段目标等内容，经双方负责人签字后生效，按此计划开始现场实施。正式开始现场实施前项目开发组应检查所有必要的准备工作是否已经完成。
现场工作首先要进行软件在服务器端的安装和调试，包括数据库中各类对象的生成，初始化数据，原有系统的重要数据的转换导入，前后台软件的安装，配置参数调整等工作；完成后需向系统平台维护人员提交《数据库安装目录》，《软件安装方法》文件，并协助系统平台用户进行软件安装。
软件安装完成并确认可在系统平台正常运行后，开始相关业务人员的培训；在培训开始之前需要由双方协商形成《培训计划》，明确培训环境、条件及方式，参加人员，课程课时等详细内容，由双方现场实施负责人签字后生效，并分别开始着手准备，在既定时间内完成。
培训顺利完成后将开始软件在试点部门试用，我公司将向系统平台用户项目组提交编译后的前后台软件，《软件使用操作手册》，《软件功能清单》，这两种文档将详细描述软件的使用过程，软件所包含的全部系统功能模块。
软件试用期内系统平台用户项目组的主要工作是根据《软件功能清单》所列的系统功能模块，检查我公司所提交的软件是否满足《系统需求分析报告》、《系统设计报告》的规定，列出未完成及含有较严重、明显错误的模块清单形成《软件问题及修改记录》并提交给我公司继续完善；此段时间可以对软件的细节性问题进行测试、验证，但主要精力还是应放在模块级功能的检查上，如果所有模块都已开发并可以进入试运行，其设计方法、技术可行性也都能够满足最终软件的需要，则系统平台各相关业务负责人、现场实施负责人需要签署各子系统的《软件交付书》，表明软件已在现场安装、调试、培训完成，基本可以进入软件试运行；此后在软件功能模块一级上不应再发生大的变化，如需要修改功能模块设计，则需由双方项目负责人协商解决。
试运行期内系统平台负责组织针对《软件功能清单》所列的系统功能模块进行现场的系统测试，包括新旧两套系统并行工作一段时间进行验证，使每个功能模块都得到基本确认；对于其中发现的问题和软件的细节性修改意见，需以《软件问题及修改记录》的书面形式提交给我公司；我公司修改完成后立即提交到现场，系统平台负责组织立即对软件进行确认回归测试，如验证问题已修改需要在《软件问题及修改记录》中予以说明。通过试运行及修改后证明已经基本完成的模块，系统平台用户项目组应组织相关的业务负责人在《软件功能清单》中逐项确认。

7.4.2.6项目验收阶段

在试运行期内系统存在一定的细节性问题是工程项目不可避免的问题，特别是随着用户应用的逐渐深入，此类需求会逐级提出，此类问题不属于系统的致命性错误；因此当试运行期内所发现的真正的“问题和错误”收敛到一定数目以下时，各业务子系统经过一段时间的并行工作新系统已基本可靠，就可以切换到正式运行阶段，开始正式运行。
正式运行后，由系统平台提出验收要求，双方共同制定《项目验收计划》，组成项目验收小组，共同进行项目验收。此时我公司将向系统平台用户提交验收的各类文档，包括对系统开发过程进行总结的《项目总结》，《项目技术报告》，最终的完整的《数据库字典》等。
验收工作将由系统平台组织的专家组对系统平台进行全面的验收和鉴定，并出具项目验收小组领导签字的《项目验收报告》，并签署验收意见，我公司在此过程中将全程参与，在现场进行验收前的维护工作。

7.4.3实施过程提交文件汇总

以下是对上面的实施过程中将产生的文件汇总说明：

阶段	名称	作用	评审级别	变更控制
需求调研	《需求调研计划》	确定需求调研的准备工作、内容、方法方式及人员和日程安排	双方现场实施负责人	双方现场实施负责人
	《系统需求分析报告》	明确用户业务需求	双方项目负责人	双方项目负责人
设计	《系统设计报告》（其中包括数据库设计）	描述整个系统软件的模块设计，详细设计，数据库设计，供开发编码使用	双方项目负责人	双方现场实施负责人
软件开发	《项目开发计划》	软件开发的日程进度，分工，检查点设置，提交成果等计划	双方现场实施负责人	双方项目负责人
软件测试	《测试计划》 《测试总结报告》	符合质量保证体系规定的功能测试、同行间测试文档
软件现场实施	《项目实施计划》	确定现场实施准备工作、人员和日程安排、培训计划、阶段目标等	双方现场实施负责人	双方项目负责人
系统培训	《培训计划》 《培训总结》	明确培训环境条件及方式，参加人员，课程课时等要求 培训记录，培训效果总结，是否达到目标	双方现场实施负责人	双方现场实施负责人
系统安装	《数据库安装目录》 《软件安装方法》 《软件使用操作手册》	现场安装、调试和提交软件的相关文档
	《软件功能清单》	所提交软件全部模块结构划分，功能描述	系统平台人员
	《软件交付书》	软件已在现场安装、调试、培训完成，基本可以进入试运行证明	系统平台负责人
	《软件问题及修改记录》	实施中发现的软件问题和用户提出的具体修改意见，以及对其所作修改和确认记录
项目验收	《验收计划》 《验收报告》 《项目总结》 《项目技术报告》 《数据库字典》	开发过程项目总结，技术总结，数据库设计字典等验收相关文档

7.5质量计划

在计划阶段需要采取步骤确保项目是完全按用户要求提供的交付物。每一个交付物的质量标准将被明确定义，用来制订质量保障计划。在质量计划中必须考虑抽查和定稿的流程，抽查的活动必须依据技术方案严格定义并记录成文档。因而进行的质量计划活动必须同技术计划集成在一起。在质量计划过程中，质量保证经理必须以独立的身份参与项目活动，以确保产品的质量。
以下为质量管理过程中的主要行为，它是具体的质量计划制定和执行的依据，在项目实施过程中根据项目情况制定详细的计划。
质量计划主要的行为包括：
项目提交物的定义和进度安排
合约条款的回顾审查
提交项和检查点的回顾审查
系统测试
错误管理和跟踪
在执行质量计划的主要任务过程中，我们有以下各项内容。
文档规范：
程序和编程规范
设计规范
技术回顾审查程序：
文档的回顾审查过程
编码和检查点的回顾审查
系统规格书的回顾审查
系统设计和详细设计的回顾审查
源代码的回顾审查
测试程序：
测试队伍
测试过程
编制测试计划
设计测试案例
执行测试
记录测试结果
检查测试完成情况
系统集成测试
用户接受测试

7.6项目控制

项目控制是对整个项目进行过程中的各种情况进行控制的一种手段，通过对项目进度、项目质量、项目的提交等控制和管理，以确保项目能够在不超出预算的前提下按时保质保量完成。
本节主要从管理控制、交付控制、缺陷管理、质量管理、文档管理和变更管理等方面进行描述。

7.6.1管理控制

管理控制涉及项目活动的所有方面，控制活动以项目指导委员会会议、项目保证小组会议和其他的项目会议方式来进行。会议类型包括：
项目启动会议 – 提供一个项目的良好开端，以确保如参照、目标、承诺、调整、计划和组织等词汇被清楚的定义、公布、理解并达成一致。
进度会议 – 这是一个常规会议。在会议中，项目经理将汇报项目当前状况，并提供一个契机，让项目指导委员会解决那些项目经理无法解决的项目问题。会议召开的频度由双方决定。
最后阶段的评估 – 它在每个实施阶段的收尾部分进行。
开发结案会议 – 这是项目指导委员会的最后一个会议，用来确认并接受新开发的系统，并正式宣布相关的开发阶段结束。
关键点检查 – 这是一个定时进行的会议。项目经理检查相关交付物，确认项目的技术问题，并按需要采取相应的措施。

7.6.2交付控制

质量和技术控制主要针对特定阶段提交的交付物，而不是针对整个阶段的产品结果。目的是为了在开发阶段尽可能早的确认并改正错误。它通常采用下面的控制机制：
质量抽查－每一次质量抽查，是指技术、质量保证及用户的相关人员对交付物进行检查，确定它已经完成、符合对它的描述、符合质量标准和相关的用户需求。
变更控制 – 一个变更是指与一个或多个交付物相关的并且事先未知的需求改变。它需要被记录并应采取适当措施加以控制以防变化扩大化。
软件配置管理 – 软件配置管理提供一个正式的机制用来对交付物进行标记和归档，跟踪开发状态及它们之间的关系。
缺陷管理 – 缺陷是指已被认为正式通过后的交付物发现技术上的异常问题。它需要被记录及改正以保持交付产品的完整性。
风险管理 – 这个控制机制用来识别、评估、监控项目风险，使项目风险对项目的破坏程度降到最小。

7.6.3缺陷管理(Defect)

缺陷管理是管理在系统验收测试中发现的、新系统运行过程中发现的错误的修改工作。发现的缺陷将被记录，而且修正过程需要被严格监控。缺陷是指新运行系统与开发前确定需求规格的差异（即接收到的需求与完成的产品之间的差别），包括文档，用户界面，功能，以及性能。
非偏离需求规格而引起的变动叫“变动请求”（CR）。CR将被按照变动管理的方法去报告和处理。详细描述见“变动管理”部分。
缺陷跟踪系统
为在系统开发过程中，能够即时提交缺陷，管理缺陷，分配、更新缺陷跟踪记录，必须建立缺陷跟踪系统。缺陷的管理包括：
缺陷发现
缺陷提交
缺陷分级
缺陷分配
解决缺陷
再测试
发布和完成
缺陷状态
每个缺陷将被分配一个状态。缺陷的处理过程可以通过观察每个缺陷的状态来完成缺陷监控。可能出现的状态有：

状态	说      明
活动的	缺陷已经输入，还没有实施解决措施
已解决	缺陷已经分配，问题正在解决，等待再测试。
已完成	缺陷已经测试过了，没有碰到更多问题
重复	属于重复性的缺陷
优先	缺陷比其它系统缺陷要优先处理

缺陷发现
大部分缺陷是在测试阶段发现的，如先前所讲，缺陷是文档中描述的需求与完成产品之间的差异。而系统改进方面的请求应按照“变动管理”方法处理。
 
缺陷提交
每个项目组成员都可以提交缺陷，通常，大部分缺陷都是在系统测试阶段发现的。在这种情况下，缺陷要报告给项目经理，并且登记到缺陷管理系统。所有的缺陷将进入缺陷管理系统，它们应该包含以下信息：
缺陷所在系统模块
缺陷的详细描述
如果是功能缺陷，说明是否缺陷会再产生，以及再产生的步骤。
严重度
根据发现问题的性质，缺陷的重要程度可以分为：

严重度	适  用  于
S1	防碍系统能力的发挥
S2	防碍运行和重要任务的完成，但是其他功能仍然可以用
S3	影响运行和重要任务完成，而且没有解决措施
S4	影响运行和重要任务完成，已经发现解决办法
S5	使操作员使用不方便和烦恼，但是不影响运行和关键任务处理 使操作员使用不方便和烦恼，但不妨碍任务的完成
S6	其他影响

缺陷一旦被接收，分配一个唯一编码，其状态为“活动”
缺陷优先级
缺陷管理长官要每天监控缺陷提交。根据缺陷的严重度和性质对缺陷分配一个优先级：
高-  缺陷必须尽快改正
中- 应该尽快修正。 但是，可以在所有高优先级别的缺陷修正之后做。
低- 缺陷可以以后再改，不会影响系统运行。
缺陷分配
缺陷将按以下顺序分配给开发者去改正：高，中，低。在软件开发和内部测试阶段，分配和解决缺陷可能不必获得项目经理的批准。软件开发者可以分配和解决所有必要的缺陷。
然而，一旦一个版本已经选为基本版本，项目经理要进行影响分析，确定是否要解决该缺陷。在版本选择阶段，任何缺陷的修改必须获得配置管理员和项目经理的批准。
解决缺陷
当开发者收到缺陷时，要分析缺陷的成因，并分析原因和提出解决方案。其直接领导要立刻批准对应的分析和解决方法。批准之后，项目经理要分配时间去解决问题。为修改程序，需要从版本控制系统中借出源文件。对缺陷要做单元测试，以免影响系统其他部分。当缺陷改正后，有关文件要还回版本控制系统。在还回时，记录缺陷的编号和简要描述。
在缺陷管理系统里面，要更新缺陷的信息，加入缺陷分析和解决措施，以及修改过的文件。缺陷的状态应标为“正在解决中”，并分配给测试组进行重新测试。所有会影响文档的修补，如用户文档，要通知项目经理，以便采取响应行动。
测试，布置和结束
缺陷处于“正在解决中”状态，而且被发回测试组时，将进行再测试。测试组根据标准测试方法测试。如果再测试成功，将修改部分布置到生产系统中，要求用户再进行测试。如果没有问题，缺陷的状态就可以标志为“已完成”。如果缺陷仍然存在，或碰到新问题，缺陷要被发回负责处理的人。返回的缺陷要包含返回的原因和碰到的问题。返回的缺陷要被再评估，这个过程要不断重复直到缺陷解决为止。
缺陷管理包括：
发现缺陷
报告缺陷
缺陷分级
缺陷分配
解决缺陷
重新测试和结束
缺陷跟踪和监控
为确保一系列行动被执行，并且在要求时间内完成，缺陷应该由项目经理亲自进行跟踪和监控。

7.7变更管理

产品的完整性需要通过变动管理来维持。用户需求的变化、系统需求的变化、和系统设计的变化都被监控和跟踪，从而了解被批准变动的实施状态。控制变动的目的是为了确保只有经过批准的变动才能实施，确保变动情况传达到了相应的有关方面，提供它们考虑和获得它们批准。
用户需求、系统需求和系统设计文档在通过评审并批准后将作为基准。当一个文档变为基准以后，就自动进入变动控制范围。任何变动都需要提交变动请求。变动管理由以下四部分组成：
变动请求
变动评估
变动批准
变动实施和跟踪
任何变动都要通过变动请求（CR）提出并提交到项目指导委员会进行批准。CR并不意味现存产品有任何错误。提出CR可能的理由有：
用户希望修改系统某一特性
发现了新的需求
项目组成员针对系统某一特性提出了一个改良的建议
（1） 变动请求
当有变动需要时，请求者将填表格，表格要包含以下信息：
变动所影响的模块和系统
变动的描述
变动的理由
变动细节
预计的影响
收到CR后，项目经理将其编号，召开会议讨论。
 （2）变动评估和批准
当项目指导委员会收到CR后，要决定是批准还是否决。任何变动都要在会议之前做好研究。 项目服务控制人员将考虑请求的重要性，并进行影响分析。调查者要写影响分析报告，并发给项目指导委员一份。
 变动的种类
根据影响分析报告，变动将被分为以下几类：
类别1，变动影响到基准文档或者引起成本和进度变动。
类别2，变动不影响基准文档，并且对于成本和进度影响可以忽略。
如果委员会认为变动属于类别2，变动自动获批准，不要进一步行动。如果变动属于类别1，必须给出如何处理的建议。有两种可能性：-
接受变动并建议变动何时实施
拒绝请求
 影响分级
根据“影响分析报告”，变动的影响可以分为以下级别：
 

状态	说      明
高	变动的实施非常重要，比如为符合合同的要求
中	很有必要实施，比如影响到运行效率
低	没有大的好处和影响，比如文档的修改
装饰性	改动很小，对系统的作用不可测量，例如修改操作手册的样式。

根据CR的优先级和其他项目因素（比如，可用时间和资源），委员会可以决定是否建议实施变动。
 影响分析
影响分析是要确定对产品进行变动所需要的资源，时间，成本，以及风险。研究者应该准备“影响分析报告”。报告中应包含以下项目：
提出者和其单位
所建议的达到变化的简要方法
技术优点评估
潜在副作用评价
总结对其他配置项目和系统功能的总体影响
必须考虑的限制
预计对于项目成本和时间的变动
评审和监督的标准
建议可以采取的方法和不能采取的方法
 （3）变动的批准
变动请求应该有以下六状态：

未处理	未有决定
否决	已决定不变动
延后	决定不在此项目中修改，留待以后去做
同意	批准实施
进展中	正在实施变动
完成	已经完成变动并经过审核

 
 
在会议结束，CR应该处于以下状态之一：未处理，否决，延后，或批准。获得批准并且开始了实施工作，状态应为：进展中。所有工作完成，CR将处于“完成”状态。
会议中请求的列表应记录在文档中，并且标明审批的状态，最后要委员会签署。在项目结束时，所有的CR应处于“否决”，“延后”，“完成”三种状态之一。
（4） 变动实施和跟踪
根据委员会对变动的建议，有两种的行动可能发生。如果委员会建议是否决，将请求的状态记录为“完成”，如果委员会建议接受并批准了书面的对计划和成本的影响，本公司要实施变动的处理。

7.8系统测试

7.8.1测试任务与步骤

系统测试是衡量产品质量的重要过程。建立详细的测试计划是测试工作保质保量完成的前提。而一个详细的测试计划需要依据项目的实际实施中发生的活动和系统需求来编制，我们将在项目实施过程中根据需要而制订详细、切实可行的测试计划。
本项目进行测试的主要任务有：
制订测试计划、测试标准及测试风险评估和避免措施
设计测试过程、用例和数据
测试执行
评价商业情况的准确性
利用测试结果，监控和改进测试过程
分析测试结果，给出测试报告，确定系统的可用性
验收测试过程包含以下步骤：
制定测试策略和过程
设计测试用例和数据
准备测试环境
测试执行
测试总结

7.8.3设计测试用例和数据

测试用例和数据准备的目的是帮助用户在不熟悉实际环境的时候，能正常的测试系统并对系统做出正确的评价。
测试用例和数据的准备是一项枯燥和费时间的工作。为了提高工作效率可以从以下几方面着手：
将信息放在一个指定的位置，便于反复利用，降低变化产生的影响；
一次完成一个步骤，避免冗余和额外的工作；
尽早尽可能完成多个步骤。
为了保证每一个业务流程准备测试用例和数据的正确性，在测试计划中应遵循下列过程，并完成以下步骤：
确定要测试的业务情况类型
确定每个要求的测试用例
合并所有的测试用例，生成测试大纲
编制测试脚本，包括必要的系统输入信息和期望的输出结果
检查信息保证每一步的准确性和完整性（即，确定业务情况类型、确定测试用例、生成测试大纲和编制测试脚本）。
（1）确定业务情况类型
确定实际商业环境中出现的业务情况类型是非常重要的。每一种业务情况类型都对应一个实际商业业务。业务情况类型可以被表达成多种状况（例如，简单情况、或需要进行复杂处理的例外情况）。
（2）确定测试用例
对每一条规定验收要求，确定测试用例。每个测试用例包括测试条件（包括生成测试条件需要的测试数据类型）和期望的结果。每个测试用例都应该是唯一确定的（例如，赋一个数值）。
（3）生成测试大纲
对每一种业务情况类型，生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例，将测试用例的条件映射为测试大纲是非常必要的。
测试大纲中测试用例的顺序安排是非常重要的，它应考虑多种方面的因素，主要考虑的因素：
按照系统产生的数据，在测试大纲中安排测试用例的顺序，使得一个测试的结果作为另一个测试前提。
按以下顺序编制测试大纲：
       确定唯一的标识（例如，测试大纲编号）
       确定业务情况类型
       对每种业务情况类型进行测试之前，列出成功完成测试必需的测试用例数目
       对每个测试用例按照测试进行的顺序给出测试用例编号
（4）编制测试脚本
在了解系统构造的情况下，将测试大纲概要作为编制测试脚本的指导。
根据系统输入指导测试人员如何进行测试。例如，编写详细的测试步骤或给出如何进行数据输入的说明（如已经填好数据的屏幕实例）。即使没有相应的测试，也要包括每一个必要的测试步骤以便确定测试条件。确定进行测试的时间（例如，进行输入的模拟日期和期望观察输出结果的模拟日期，或对循环测试，对测试大纲进行测试的逻辑上的天数、周数、月数和年数要相当于两个月的实际时间）
（5）检查测试
每步测试完成后，需要利用测试计划中确定的处理步骤对测试过程进行检查（例如，检查业务情况类型、测试用例、业务情况和测试脚本）
 

7.9系统验收

7.9.1递交成果的签署

签署的目的：签署指的是评审人在验收文档上签字，表明评审人已对递交的成果进行了评阅，并认为递交的成果满足要求，同时成果递交者已解决评审人对递交成果提出的意见。
评审和签署程序：本公司提出了以下评审和签署程序
在评审过程中，评审人将完成以下各项程序:

1. 检查递交的成果是否满足要求
2. 在意见表中填写评审意见

在评审之后，评审人将意见表交给我公司项目经理。如果评审人对递交的成果提出重要意见或需求，需要对递交的成果进行修改。递交的成果修改之后，评审人将重新进行评审。对于每个评审循环，评审人将完成上述的步骤 1 到 2。 评审人将对递交的成果进行完整的评审，并在两个评审循环中完成评审。如果安排的评审周期结束，将不再重复这个过程。
在评审周期内任何时间，如果评审人认为递交的成果已经满足所有需求，并提出了评审意见，评审人将通知用户方项目协调人。在这种情况下，用户方项目协调人将签署递交的成果。
如果在评审周期结束后，递交的成果仍然不能满足规定的需求或不能解决评审人提出的意见，评审人将把这种情况记录在意见表中，并将意见表交给项目协调人。评审人将认为递交的成果不可接受。接收/拒绝表将由项目协调人递交给我公司项目经理。

7.9.2递交成果的拒绝

如果评审人没有依据评审准则，对递交的成果进行评审或没有给出任何特殊的或客观的理由，评审人就不能拒绝递交的成果。
如果递交的成果已经签署，就不能做任何修改，项目协调人则将接受/拒绝表归档。如果有任何问题，则由系统平台项目协调人与我公司项目经理协商解决。
如果发现由于递交的成果没有满足质量标准要求，或在评审周期结束之日所有作者没有解决评审人提出的意见而被拒绝，拒绝的递交成果必须退回给成果递交者进行修改。如果用户方项目协调人与我公司项目经理无法协商解决问题，将上报到相关部门解决。

7.9.3软件系统的验收

验收方法：开发的软件通过用户验收测试进行验证。软件验收根据软件满足规定的验收合格标准进行判断。
验收标准：验收标准是在用户正式接收开发的软件并认为软件满足合同要求之前必须满足的条件。本文档中定义的所有验收标准是基于定量的和可度量/可观察的条件。
 验收合格标准
测试准备:
用户验收测试文件包括对项目确定的所有软件功能的测试程序。
进行测试之前，用户方和我公司必须认可用户验收测试文件。
用户方已经认可测试数据
用户方已经指定和批准用户验收测试文件的测试人员。
测试执行
测试由指定的测试人员来进行
所有的情况都必须得到测试
在测试过程中，测试人员必须记录所有测试结果
测试结果由指定的测试人员签字
用户方和我公司必须接受用户验收测试报告
测试结果
测试结果说明软件满足下列要求：
在认可的外部设计文档中表述的功能要求
在认可的系统描述文档中表述的非功能要求
质量要求：
测试过程中发现的所有错误都必须记录下来
对错误进行分类和确定级别
报告的错误得到修改/处理，或修改错误的计划得到同意。
 验收标准
如果软件系统满足所有验收合格标准，而且没有出现S3以上级别的错误，用户将正式接收该软件系统。

第八章 系统用户培训计划

8.1 培训承诺

在项目实施过程中，我们充分考虑用户的需求，为用户做好技术培训工作，为项目的顺利实施打下了坚实的基础，同时也保证了信息系统的稳定运行。为了更好地作好项目建设的技术培训工作，我们将选派具有丰富技术培训和实施经验的技术人员组成培训小组，编写详尽、实用的培训教材，并且制定切实有效的培训方案。
技术培训的工作分为应用软件系统管理和使用培训两个部分进行。
在应用软件系统管理和使用培训中，我们会组织项目开发小组的主要人员针对管理和使用人员的不同需求，提供不同层次的培训课程。

8.2 培训遵循的原则

在此次项目的培训工作中，我们将遵循以下原则：
集中授课、结业考核
本次培训采用面对面集中授课的方式进行，以保证培训取得良好效果。对于强制学习课程进行结业考核。
规范与知识并重
在针对网站管理人员的培训中，除了对知识的教授以外，应特别强调对规范的介绍，以使项目建设队伍在相同的概念范畴之内协同工作，保证项目进行过程中的良好交流与沟通，这样不仅可以减少项目进程中的内耗，更是为系统的后期维护打好了必要的基础。
强制与自愿培训相结合
在全部培训体系中，那些对项目成败有关键影响的培训内容必须强制培训对象参加、应用系统的最终用户、应用系统的维护人员）；而某些培训内容可以由培训对象根据自身的需要灵活选择（主要针对第一线的技术人员，因为他们使用的技术非常广泛，而这些技术人员的技术背景相差较大）。
层次分明、针对性强
在培训体系中，涉及了多个不同层次的项目参与人员，对他们的培训不能千篇一律，而是具体问题具体分析，采取“缺什么，补什么”的办法，为不同的培训对象设计不同的培训大纲，选择有针对性的教材，采用有针对性的教学方法，使每次培训达到最好的效果。

8.3 面授培训

如果用户需要进行面授培训我们将安排经验丰富的讲解人员配合用户做好面授的培训工作。

8.4 应用软件系统培训

8.4.1 培训目标

通过对管理人员和使用人员进行应用系统全面的培训，达到管理人员具备以下能力：
能够对系统进行安装和调试
能够对系统进行日常的管理和维护
能够对系统进行诊断和问题排除
能够对系统进行修改调试
对于使用人员来说，目的只有一个，能够达到熟练对系统进行管理和维护，更好的进行日常业务工作。

8.4.2 培训对象

系统管理人员，日常使用人员。

8.4.3 培训方式

应用系统管理培训采用现场和集中培训的方式，参加培训的技术人员集中参加培训。在培训过程中，培训教员使用投影仪，进行技术理论的讲解，同时，针对应用系统，进行现场的安装配置以及使用演示。

第九章 系统运行维护承诺

9.1服务品质承诺（SLA）

为了更好的完成项目，我公司在投标文件其他部分（包括：技术承诺、集成方案的培训、服务，本部分的人力资源等）承诺以外做出下列特别承诺：
* 我公司对项目相关单位提供免费电话支持服务。热线电话。
* 对工程项目中我公司承担之项目出现异常时，我公司承诺在接到通知后，根据问题发生的严重程度、服务网点距问题发生地距离、服务难度等，将在2小时内作出实质性响应，需要现场服务的，将在24小时内到达现场。
* 负起系统集成商的责任，协助用户维护本文集成方案提到的数据中心和项目管理中心。
* 按招标书要求提供集成服务、开发服务、培训服务和维护服务、。并承诺提供用户要求的其他相关的技术咨询和支持服务，服务价格、质量令用户满意。
* 严格按本投标书人员计划投入相应的资源。
* 对于服务人员质量水平的承诺。我公司承诺安排的项目组成员具有完成任务的能力。
* 派遣合格的项目协调人员在现场协调项目（根据项目具体情况在项目组内选定），保持和客户的同步交流，并以最快的速度进行反馈。
* 我公司承诺以我公司能够承担的最低价完成其他项目的任务。

9.2应用软件系统服务与支持

9.2.1 技术支持办法

1. 开发过程中，如果用户提出需求更改且用户提出的要求在开发合同限定的范围内，经双方确认以后，我公司根据要求进行修改。
2. 系统交付用户试运行以后，我公司根据用户测试的结果进行程序正确性维护。
3. 系统经验收正式提交用户使用以后，我公司提供1年免费的系统正确性维护和技术支持，技术支持办法参见下文说明。

技术支持办法：
系统提交用户使用以后，如用户请求技术支持，如果通过电话支持可以解决的问题通过电话进行指导解决；重大技术问题及时现场技术支持，技术支持项目师将在最短时间内赶到现场用户现场；
1）灾难性事件：由于经过大量的测试，系统本身应不含有可引起灾难事件的隐患，如果确因系统开发问题造成灾难事件发生，我公司立即组织开发队伍进行修改（必要的话会到现场对事件进行调研），并尽快到现场升级原有系统，同时，通过软件分发渠道对所有使用该软件的操作者进行升级，需要现场升级的我公司提供上门服务。如果系统由于病毒或其他非应用系统原因造成的灾难性事件（包括系统不能启动等），需要恢复到可运行状态，我公司酌情收取差旅费、服务费进行现场恢复操作。
2）严重程序错误：如果确因系统开发问题而可能造成数据错误（必要的话会到现场对事件进行调研），我公司立即通知用户暂停使用本系统，并立即组织开发队伍进行修改，并尽快到现场升级原有系统，同时，通过软件分发渠道对所有使用该软件的操作者进行升级，需要现场升级的我公司提供上门服务。
3）一般程序错误：如果程序出现开发上的“笔误”，不会造成严重的数据损失，我公司立即组织开发队伍进行修改，并通过软件分发渠道对所有使用该软件的操作者进行升级。
4）属于用户使用不当问题的，我公司将通过电话进行指导。

9.2.2 服务承诺

我公司在项目中本着“质量第一、用户至上、长期合作”的原则，为我公司提出以下服务承诺:
1．项目中，我公司以交钥匙项目方式，最终将在合同规定期限内向用户交付符合合同技术要求的、实用的信息系统；
2．在项目建设中，我公司将严格质量管理，项目进程控制，与使用项目人员密切配合，虚心听取意见，弥补工作中的不足；
3．我公司负责与本项目中所涉及的各类产品的各生产厂商联络，并与各生产厂商密切合作，共同保证项目产品按时到货，确保产品质量；
4．我公司对本项目中所涉及的各类产品按照生产厂商提供的免费保修期限，向用户提供及时的免费保修，并在设备保修期间与生产厂商共同保证系统的正常运行。在保修期外的产品，我公司将提供产品的维护，及时对产品提供升级，维修等服务，并为客户提供最优的升级、维修价格；
5．我公司为项目设立系统维护支持小组，并指定专人与用户项目人员保持定期联络。在系统安装调试阶段以及系统试运行阶段的三个月中，我公司保证每天都有技术人员提供8小时电话服务。在系统验收后半年内，我公司技术人员每周通过电话访问用户一次，了解用户系统运行情况，解决运行中遇到的问题，并填写系统维护日志。在系统验收半年以后，我公司技术人员每月通过电话访问用户一次，了解系统运行情况，并提供测试报告及解决方案。
6．我公司为项目设立热线支持电话，提供7 X 12小时有人接听支持。同时提供我公司项目负责人热线电话，提供7 X 24小时电话联系。
7．我公司对项目提供5 X 8小时现场支持。严重系统问题24小时内解决。
8．我公司为管理人员、系统使用人员的多层次、多种类的培训。

• 学生WEB端操作手册 顶岗实习管理软件
• 教师WEB端操作手册 顶岗学习管理软件
• 顶岗实习学院用户客户端操作手册
• 职业技术学院顶岗实习管理软件
• 顶岗实习信息管理APP学生版操作手册（六
• 顶岗实习信息管理APP学生版操作手册（五
• 顶岗实习信息管理APP学生版操作手册（四
• 顶岗实习信息管理APP学生版操作手册（三
• 顶岗实习信息管理APP学生版操作手册（二
• 顶岗实习信息管理APP学生版操作手册（一
• 顶岗学生实习信息化管理平台（实习成绩
• 顶岗实习信息化管理平台学生版（管理制