项目工作说明书(SOW)

附件1
XXXX有限公司
XXXXXXXXXXXXXX项目
工作说明书
XXXXXX有限公司
目录
1前言 (4)
1.1目的 (4)
1.2术语 (4)
1.3参考 (4)
2项目概述 (4)
2.1项目背景 (4)
2.2定位和目标 (4)
2.2.1系统定位 (4)
2.2.2系统目标 (5)
2.3应用架构 (5)
3项目范围 (5)
3.1组织范围 (5)
3.2需求范围 (5)
3.3非功能性需求 (5)
3.3.1性能要求 (5)
3.3.2可用性需求 (6)
3.3.3易用性需求 (6)
3.3.4扩展性需求 (6)
3.3.5权限控制需求 (6)
3.3.6安全性需求 (6)
3.3.7可运维性需求 (7)
3.3.8知识产权 (7)
4项目交付清单 (7)
5项目管理方案 (7)
5.1项目实施工作方法 (7)
1.1.决策制度 (7)
1.2.交流制度 (8)
1.2.1.原则 (8)
1.2.2.例会制度 (8)
1.2.3.问题争议制度 (9)
1.2.4.失误管理制度 (9)
5.2项目实施管理方法 (10)
5.2.1责任分工 (10)
5.2.2实施过程 (10)
5.2.3项目验收规程 (33)
6项目实施方案 (44)
6.1项目实施计划 (44)
6.2项目组织结构 (44)
7变更管理流程 (45)
7.1变更的目标 (45)
7.2组织人员 (45)
7.2.1变更管理员 (45)
7.2.2变更委员会 (45)
7.3变更的流程 (46)
7.4变更管理活动 (46)
7.4.1变更记录 (46)
7.4.2接收/废弃 (47)
7.5分类 (47)
7.5.1优先级的确定 (47)
7.5.2类别的确定 (47)
7.5.3规划和审批 (48)
7.6协调 (48)
7.6.1构建 (49)
7.6.2测试 (49)
7.6.3实施 (49)
7.7评估 (49)
1前言
1.1目的
本工作说明书是XXXX项目技术服务合同（以下为简称主合同）的不可分割的组成部分，并经XXXX有限公司(以下简称甲方)和XXXX有限公司（以下简称乙方）协商达成以下一致意见：
（1）乙方同意向甲方提供本工作说明书所述服务。

（2）主合同的定义、解释、条款、术语和条件将作为此工作说明书未提及部分的补充。

本工作说明书与合同有冲突的，以主合同条款为准。

（3）此工作说明书描述了由乙方为甲方实施XXXX项目（以下简称本项目）的过程中提供的技术服务细则，以及甲乙双方在项目实施过程中的主要职责。

1.2术语
1.3参考
2项目概述
2.1项目背景
2.2定位和目标
2.2.1系统定位
2.2.2系统目标
2.3应用架构
3项目范围
3.1组织范围
3.2需求范围
3.3非功能性需求
3.3.1性能要求
3.3.1.1对系统功能的性能要求
3.3.1.2对系统网络带宽的评估3.3.2可用性需求
3.3.3易用性需求
3.3.4扩展性需求
3.3.5权限控制需求
3.3.6安全性需求
3.3.7可运维性需求3.3.8知识产权
4项目交付清单
5项目管理方案5.1项目实施工作方法
1.1.决策制度
1.2.交流制度
1.2.1.原则
➢问题及早提出原则
参加项目的系统工程师对自己承担责任的工作，必须及时发现不能恰当完成的因素，并及时向项目经理或有关责任人书面报告，否则不能恰当完成任务的责任在于任务承担人。

➢及时解决原则
对所承接的工作，如没有拒绝，则代表接受人已经完全了解工作环境、工作结果要求等多个要素。

如果在呈交结果时，与任务要求有出入，则不可以以任何理由解释责任，失败责任在接受人。

因此，接受人应及时与任务分派人澄清任务的全部因素。

➢提醒原则
所有项目组成员，如发现项目进展隐患，应及时向项目经理或其他人员提醒。

提醒可以以书面或口头方式。

提醒时也要注意不要追究相关人员的后续工作。

1.2.2.例会制度
➢周例会
每周五下午，由项目经理组织在现场的双方项目组成员参加周例会。

总结上周工作，形成项目周报。

项目周报的内容包括：上周工作进展报告、本周工作计划、本周任务分派报告。

➢问题的提交
参见问题争议制度一节的相关内容。

➢审批与确认
审批或确认人在收到问题后的二个工作日内向提出人给出书面回复。

1.2.3.问题争议制度
➢问题及早报告原则
对于一个问题，问题发起人必须在问题发生的1日之内，向项目经理提交报告。

问题没有及早报告，导致的项目影响，由延误报告人承担。

➢报告方式
如报告人认为口头报告即可，可以采用口头报告，但是如果口头报告没有使问题得以解决，则视同报告人没有作报告。

➢争议管理
在项目中，任何不能达成一致的观点均为争议，争议应立即向项目的上级单位呈报，并报项目管理部。

争议应由可以协调争议各方的机构加以裁决，并对裁决承担责任。

争议裁决人由项目管理部项目经理选择。

争议的最高仲裁机构为项目领导决策组。

如项目领导决策组仍不能达成一致意见，则遵循，谁决策，谁承担决策失误给对方和项目带来的损失之原则。

1.2.4.失误管理制度
失误可能是多方面的，失误的及早发现是项目成功的基本保障。

对失误的严肃性是项目管理的基本要素。

因此，每个项目成员均要给予极大重视。

•对以下各个事件，必须做出失误分析：
•设计方案有重大改动
•技术有严重的缺陷
•进度与计划差别较大
•设计有误
•其它重大事件
项目经理应每月给出失误分析报告，并有每一失误的详细分析报告并制订弥
补措施，此报告应提交相关人员。

如果失误分析报告看不出项目有重大影响，而项目实际有重大问题，则为项目经理之职责。

5.2项目实施管理方法
5.2.1责任分工
5.2.2实施过程
根据本项目的特点，建议采用瀑布模型作为软件开发的生命周期模型进行项目的管理与控制。

瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品，它是从硬件工程学来的一种分阶段的、系统的和顺序的软件开发方法，包括需求分析、项目策划、概要设计、详细设计、编码和单元测试、集成测试、系统测试、系统实施几个阶段。

如图1：
需求分析
项目策划
概要设计
详细设计
编码和单元测
试
集成测试
系统测试
验收和发布
图1 瀑布模型
瀑布模型的每个阶段均具有以下特征：
✧从上一阶段接受本阶段工作的对象，作为输入；
✧对上述输入实施本阶段的活动；
✧给出本阶段的工作成果，作为输出传入下一阶段；
✧对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工
作，否则返回前一阶段，甚至更前阶段。

瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一管理模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量。

优点：近30年来之所以广为流行，是因为它在支持开发结构化软件、控制软件的开发复杂度、促进软件开发工程化方面起着显著作用。

✧强调开发的阶段性；
✧强调早期计划及需求调查；
✧强调产品测试。

缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。

这些问题可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。

✧依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
✧由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
✧风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。

瀑布模型适用于需求已明确、且很少发生变化的项目及软件开发过程，不适于需求不明确或是容易变化的软件项目。

如果正在进行一个陌生领域的软件项目，建议不采用瀑布模型，但如果正在开发很熟悉领域的软件项目，就可以使用瀑布模型来加快开发速度，因为需求已明确，所以不需要代码重构等方面的开销，开发效率较高。

另外，在科学数值计算、嵌入式软件和实时控制系统方面，比较适于采用瀑布模型，能够很好地控制这类项目的复杂性。

瀑布模型尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。

在计划项目时，每个阶段完成点必需设置为主里程碑节点，在主里程碑处安排里程碑评审活动；如果阶段时间比较长，则在阶段中设置次里程碑(建议时间间隔约二～三个月)，在次里程碑处进行阶段评审；
下面各章分别描述各阶段的活动，输入输出准则，以及验证的标准。

5.2.2.1需求分析
5.2.2.2项目策划
5.2.2.3概要设计
5.2.2.4详细设计
5.2.2.5编码和单元测试
5.2.2.6集成测试
5.2.2.7系统测试
5.2.2.8验收和发布
5.2.3项目验收规程
5.2.3.1名词解释
5.2.3.2验收前准备
根据需方行业的特点和惯例，系统验收在最终用户的实际系统运行环境中进行。

供方在开发环境下，完成应用系统开发工作并进行系统测试。

5.2.3.2.1系统验收前需方进行的工作
需方在系统验收前应完成的工作是：
1)计算机机房的场地准备
2)计算机机房必须满足项目的系统以及工作人员对温度、湿度、洁净度、
风速度、电磁场强度、电源质量、噪音、照明、振动、防火、屏蔽和接
地等要求(本项目机房内装修建设由供方完成)
3)网络资源申请
4)申请网络地址，租用网络带宽等
5.2.3.2.2系统验收前供方进行的工作
供方在系统验收前应完成的工作是：
1)供方应对完整产品的运行进行确认
2)供方在完成确认测试后，证实系统已满足合同规定的条件及需求说明书中
对系统功能和性能的要求
3)供方应准备好提交验收的各种文档、系统软硬件配置清单，并作好产品的
交付准备
4)供方应准备好《系统测试分析报告》和《技术总结报告》3份以上，1份
上报需方上级管理部门(按需方要求)，2份作为系统验收的必备文件提交给测试验收小组
5)供方提供人员培训和技术支持的方案
6)供方向需方提出书面验收申请
5.2.3.3验收的过程
项目的系统验收包括系统工程验收、系统上线验收和试运行、系统最终验收（终验）三个个阶段（这三个阶段根据合同可以简化为工程验收、系统终验两个阶段）。

系统验收应履行正式手续，成立专门的测试验收小组，负责组织、监督和裁决整个系统的验收过程。

5.2.3.4组成验收小组
5.2.3.4.1人员组成
需方负责成立专门的验收小组，作为系统验收的组织机构。

从成立之日到终验结束，验收小组行使验收职责。

验收小组设组长一人，组员若干人，验收小组下设系统验收测试组、技术组和文档审查组，配备若干测试员和记录员。

验收小组由上级部门负责人、需方代表、特邀专家和最终用户代表组成，必要时，也可吸收供方代表参加。

特邀专家必须是国内通信、计算机领域、需方行业的权威，熟悉国内外项目直接涉及的技术发展状况。

5.2.3.4.2验收小组的任务
验收小组主持系统验收工作，要完成的任务包括：
•审定系统上线测试及割接计划、系统终验计划；
•听取供方的《技术总结报告》和《测试分析报告》，听取需方的《系统运行报告》；
•判定所验收的系统是否符合合同及系统说明书的要求；
•审定验收测试计划、测试方案和割接上线方案；
•组织终验测试，对系统进行终验评审，形成系统终验报告；
•监督系统验收后的产品移交；
5.2.3.4.3验收小组的权限
•有权要求供方和需方对系统开发过程中的有关问题进行说明，提出质疑并要求做出解释；
•协调供方和需方之间可能发生的纠纷；
•决定系统是否通过验收；
5.2.3.4.4验收记录
验收工作的全过程必须详细记录，记录验收过程中验收小组提出的所有问题与建议，验收小组对被验收系统的评价，并形成文件供评审时查阅及存档。

5.2.3.5系统上线验收
工程上线验收过程包括（项目组可根据项目具体情况简化）：
1) 系统工程上线验收申请
2) 系统工程验收计划
3) 系统设备验收
4) 文档审查、上线测试环境检查
5) 系统演示
6) 系统上线测试计划和测试方案
7) 系统上线测试
8) 系统上线或割接
5.2.3.5.1系统工程上线验收申请
供方完成“系统验收前供方进行的工作”的各项准备工作以后，应适时向需方正式提出工程验收申请报告，扼要说明申请系统验收的准备情况和系统所具备的验收条件。

供方在提交工程验收申请报告时，必须交付有关的产品资料，其中包括系统设备及系统软件配置清单、应用软件文档(根据合同版权要求决定)、应用软件源程序(根据合同版权要求决定)、技术总结报告和测试分析报告等。

验收申请报告应有供方的技术负责人签字。

需方对供方提交的系统验收申请报告和文档进行审查，提出处理意见。

需方主要检查要验收的系统的功能、性能、系统配置和文档是否满足要求。

需方技术负责人在申请报告上签字。

5.2.3.5.2系统工程上线验收计划
在系统工程验收活动进行之前，要制定系统工程验收计划。

系统工程验收计划由系统的供方和需方共同制定。

该计划应包括：工程验收工作的活动程序、验收测试要求、技术条件、设备资源、验收准则、人员组成以及日程安排等内容。

该计划由需方提交验收小组审定后执行。

5.2.3.5.3系统设备验收
验收小组的技术组根据供方提供的系统设备、网络设备、通信设备、系统软件、数据库和工具软件等的配置清单，并对照合同或项目可研的有关规定，检查这些设备及其各项性能指标是否符合要求。

并将审查结果形成《系统设备验收报告》。

验收小组的技术小组还要监督供方向需方提供各种设备文档，包括：
•随机资料（产品介绍、技术原理手册、使用说明书、操作手册、培训资料等）、
•设备安装记录
•机房平面图
•机房设备布置图
•线缆走线图
•系统结构图
•机架配置图
•控制关系图
•电源系统图
•动力电缆走线图
•接地系统图
•网络拓扑结构图
•软件设置参数
•系统调测记录等
5.2.3.5.4文档审查、上线测试环境检查
在上线测试开始之前，需方必须提前将《上线测试计划书》、《测试大纲》和《测试用例》分发给验收小组的成员。

验收小组必须进行以下检查，以确定是否可以进行上线测试。

5.2.3.5.5测试环境与条件检查
验收小组要检查测试环境是否符合要求，检查全部测试项目的测试用例是否
准备好，有关测试人员是否全部到位。

5.2.3.5.6文档检查
供方向验收小组提供全部应用软件的源程序清单(根据合同版权要求决定)，验收小组应参照《GB/T8566-1995》有关程序编制的标准和约定，检查程序和数据以及软件环境是否符合要求。

验收小组的文档审查组要检查供方交付的文档是否与合同书中规定的要求一致，在编写内容、格式上是否符合软件设计与开发规范。

特别要检查文档与程序的一致性、文档的准确性和完整性，并形成文档检查报告。

软件开发过程中通常产生如下九种文档：
1) 项目开发计划（★）
2) 需求规格说明书（★）
3) 概要设计说明书（★）
4) 详细设计说明书（☆）
5) 用户操作手册（★）
6) 测试计划（★）
7) 测试分析报告（★）
8) 项目开发总结报告（★）
9) 程序维护手册（★）
备注：★为项目必须文档，☆为项目可选文档
5.2.3.5.7系统演示
供方向验收小组演示被验收系统的全部用户界面、系统的主要功能和性能，以证明系统满足合同书或需求说明书的要求。

通过演示活动让验收小组对系统有一个直观和概括的了解。

验收小组可现场选用实例对被验收系统进行演示考核，以证实与系统需求的一致性、程序与文档的一致性。

5.2.3.5.8系统上线测试计划和测试方案
系统的上线前测试是系统验收活动的最关键的步骤，被验收的系统必须满足合同条款与系统需求说明书中规定的要求。

软件上线前测试是在系统投入试运行之前，对需求分析、设计和编码的最终复审，是软件质量保证的最后把关。

测试计划通过对人员、设备、进度等资源进行合理地分配，来有效地组织和规划整个测试过程。

测试计划从人员分配（角色定义）、测试环境的选择和搭建、测试进度的制定、风险评估等方面来进行。

在制定测试计划同时，还要制定测试方案。

测试方案应明确测试内容及重点，根据需求规格说明书中对系统的功能、性能、压力承载、可靠性、安全和标准化接口等的规定和要求，精心设计一批测试用例。

测试用例的设计要恰到好处，以达到软件确认的目的。

5.2.3.5.9系统上线前测试
验收小组的测试组应按系统上线测试计划和测试方案对系统进行各项测试。

系统测试的目的不是为了证明软件没有错误，相反是证明错误的存在。

当错误发生以后，应该对这些错误进行有效地跟踪和记录。

测试人员按分工对被验收系统进行逐项测试，并详细记录每一项测试结果，将这些结果分别与预期的结果对照分析，然后写出《系统上线测试报告》，该报告将作为验收小组评价系统的主要依据，也是需方确定是否接收该系统的主要依据。

系统上线测试通过后，系统具备上线条件。

需方和供方要配合制定上线或割接计划、方案以及回退方案，要确定系统进入试运行的时间和结束时间，并向需方或需方上级管理部门提交上线或割接申请，同时提交上线测试报告、割接计划、割接方案以及回退方案。

需方或需方上级管理部门接到申请后，三天内给出批复意见。

5.2.3.5.10系统上线或割接
需方接到同意上线或割接批复后，组织各方人员和资源，按照上线或割接方
案实施上线或割接过程。

密切观察和记录上线或割接过程中的各种情况，出现重大故障，立即实施回退方案，不能影响业务开展。

5.2.3.6系统试运行
系统割接上线后，根据具体情况至少需要一周的试运行阶段。

5.2.3.
6.1解决问题
在试运行阶段，供方要解决试运行过程中检测出的系统缺陷和处理遗留问题，要按用户要求对系统进行相应的修改，完善系统的功能和性能。

试运行也是对系统的稳定性和可靠性的继续考核。

5.2.3.
6.2试运行报告
在试运行阶段，需方的系统维护人员和操作人员将接受供方组织的现场培训和实习，尽快掌握系统原理和操作，为系统正式移交后的独立运行维护奠定基础。

在系统试运行阶段，需方的运行维护人员和供方的开发技术人员要密切合作，对系统运行情况进行严密的监视和记录。

供方的开发技术人员要切实为用户着想，不断改进和优化系统。

在系统试运行结束后，需方在供方配合下，要如实编写《系统试运行报告》，作为系统终验的依据文件。

5.2.3.7系统终验
系统终验过程包括：
1) 系统稳定验证
2) 系统终验评审
3) 系统终验报告
4) 系统终验表决
5) 系统移交
5.2.3.7.1系统稳定验证
系统上线后，需方在供方的配合下，要对系统的各种功能、性能进行验证，即线上验证，并与上线前测试报告汇总，形成系统终验测试报告。

如果系统出现任何问题，需方要立即与供方协调解决。

供方对上线系统进行的任何改动，都需要与需方确认，并通过线下测试确认后，才能上线。

待系统稳定，达到需求，可开始进行终验评审。

系统稳定验证一般至少需要一周，如果系统问题比较多，可适当延长。

该阶段根据项目情况决定是否需要。

5.2.3.7.2系统终验评审
待系统稳定后，需方可向上级管理部门提出终验申请报告和终验测试报告，同时提交供方提供的各种文档、文档检查报告和设备验收报告。

需方或需方上级管理部门接到申请后，三天内给出批复意见。

为进行终验，验收小组应及时主持评审会，听取有关报告和审议验收结果，并对系统做出综合评价。

评审会的议程如下：
1) 听取供方开发部门的《测试分析报告》和《技术总结报告》；
2) 听取验收技术组的《系统设备验收报告》、文档组的《文档审查报告》和测试组的《系统验收测试报告》。

3) 按以下验收准则对系统进行评价：
•系统是否满足需方系统要实现的目标；
•系统采用的技术和实现方案是否可靠、先进、灵活、实用并具有扩展性；
•设备选型是否合理；
•应用软件是否具有较好的灵活性、可操作性、扩展性和稳定性；
•运行系统是否可靠安全，是否具有较强的容错能力，使系统不容易瘫痪；
•关键设备与数据备份的设施是否达到安全可靠；
•用户界面是否风格规范、统一；
•操作权限的管理是否健全，系统安全设施是否合理有效；
•联机帮助功能是否方便实用；
验收小组应认真评审被验收系统，对被验收的系统给出实事求是的评价。

评价内容包括系统的先进性、功能性、可靠性和安全保密性；设计与需求的一致性、程序代码与软件设计的一致性；文档描述与程序的一致性；以及文档的完整性、准确性和标准化程度。

最后由验收小组进行表决，决定系统是否通过终验。

5.2.3.7.3系统终验报告
终验评审后，验收小组应写出《系统终验报告》，详尽记录验收中对系统的评价及验收意见。

尤其要明确系统在验收过程中发现的问题和缺陷，以及需要改进的意见和供方对此所做的承诺。

验收小组全体成员应在终验报告上签字。

根据验收小组表决情况，由验收小组组长在终验报告上签署验收意见。

供方、需方向验收小组提交的各种终验文档一式三份，一份提交给需方上级管理部门备案，两份需方保留。

5.2.3.7.4系统终验表决
终验是否通过要通过验收小组全体成员表决决定，验收结论分为以下两种：
1) 通过。

同意的组员超过三分之二；
2) 不通过。

同意的组员不超过三分之二。

如果系统终验不能通过，验收小组将根据合同书的规定与供需双方协商处理意见，要求供方限期完成开发任务，重新提出验收申请或终止合同。

系统终验通过后，系统进入正式运行，明确供方在运行期间要解决的遗留问题以及改进系统的意见，对此供方的代表要作出承诺。

终验过程中形成的所有文档要提交给需方备案。

5.2.3.7.5系统移交
系统通过终验后，验收小组的技术组和文档审查组应分别对供方提供的系统设备清单和文档资料清单进行验收，逐项核实以后，移交给需方。

移交结束后形成系统移交文件，移交文件包括以下内容：
1) 移交清单。

移交清单包括硬件部分和软件部分。

硬件部分包括计算机、存储设备、外设、网络设备、通信设备以及其他合同规定的设备；软件部分包括系统软件、网络软件、通信软件、工具软件和应用软件等。

移交清单中应包括设备（软件）名称、单价、数量、供货厂商、保修期限和随机资料。

应用软件中包括源程序和文档（根据合同版权约定），并对软件的运行环境做详细说明。

2) 移交的时间、地点和收授人签字。

至此系统完全移交给需方，系统验收工作全部完成。

6项目实施方案
6.1项目实施计划
6.2项目组织结构。