项目工作说明书(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详细设计