【项目流程规范体系】

项目流程

项目流程规范体系

中信软件教育中心就业部制定

1. 前言

1.1. 流程规范构想

提供一份尽量完善的流程规范体系给软件产品生命周期的全部相关人员，包括项目经理，软件开发工程师，软件测试工程师，软件质量工程师等，真正做到研发项目的端到端管理，保证软件产品质量，提高客户满意度。

1.2. 当前的工作

现实总是残酷的，基于周边环境等条件的限制，参考《软件开发规范国家标准》先给出一个针对当前现实最合理，最有效的项目流程规范，保证项目的顺利开展。

2. 软件开发基础

为了更好的理解我们的项目流程规范体系，先将流程规范中涉及的技术基础知识列出来。

项目流程

2.1. 软件生存周期

根据GB/T 8567-2006《计算机软件文档编制规范》国标，软件从出现一个构思之日起，经过软件开发成功投入使用，直到最后决定停止使用并被另一项软件代替之时止，被认为是该软件的一个生存周期，一般地说这个软件生存周期可以分成以下6个阶段。

2.2. 软件开发模型

软件开发模型是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

项目流程

本文列出和我们项目流程规范体系相关的软件开发模型：瀑布模型和迭代模型。

2.2.1. 瀑布模型

1970年Winston Royce提出了著名的“瀑布模型”，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型的致命问题是由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险，并且早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

2.2.2. 迭代模型

迭代模型是RUP（Rational Unified Process，统一软件开发过程，统一软件过程）推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程，实质上，每一次迭代类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

迭代和瀑布的最大的差别就在于风险的暴露时间上。任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。

2.3. 软件测试模型

该流程规范中软件测试模型将使用V模型。

项目流程

V&V：验证与确认（Verification & Validation）

2.4. 软件测试理论

将软件测试理论总结如下：

项目流程

AlphaBeta

1. Alpha测试是用户在模拟真实环境下进行测试，有测试人员参与。

2. Beta测试是发布一个版本后，用户在真实使用环境下进行测试，无测试人员参与。在客

户场地，由客户进行的对产品预发布版本的测试。

2.5. 快速原型设计

当我们需要进行思想交流、概念探索、业务需求表现、交互行为模拟时，快速原型设计无疑是最好的方法。在产品设计中，快速原型法（Rapid Prototyping）是一种有效的、高效的、以用户为中心的技术，可以帮助用户体验专家、设计师、工程师创造更加有用、可用的产品。

通常，快速原型设计指在尽可能短的时间内制作能够表现产品基本特征的原型，包括整体的信息架构、基础的交互功能以及基本的页面元素等，必要时还需要添加色彩因素。快速原型设计的结果我们通常称之为低保真原型，其目的并不是为了交付，而是为了沟通、测试、修改等，解决产品中主要的不确定问题，所以快速原型设计需要具有快速构建、轻松修改、容易操作、关注流程、抛弃成本低的特点。

推荐使用Axure RP（Rapid Prototyping）做原型设计。

项目流程

3. 项目管理流程规范

项目经理需要从整体去把握项目，非常熟悉项目流程，各个项目角色的职责定义，各个阶段的输出文档。

3.1. 整体流程规范

项目经理负责将下面表格中的开发流程，以及每一个项目流程的项目工期，开始时间，结束时间体现在《项目开发计划》中。

6阶段；设计阶段；实现阶段；测试阶段；运行与维护阶段）很好对应起来。

3.2. 项目角色职责

为了实施规范化的过程管理，对软件项目小组的角色必须进行分工。在项目小组人数较少的情况下，往往一人身兼数职，但是这些角色是绝对不能忽略的。

项目流程

3.3. 项目相关文档

备注：很多文档名称不同，但是内容是一致的，比如可行性分析与市场调研报告，还有很多就不一一举例。该流程规范不会刻意去统一文档名称，主要是让学生对文档有更多的认识。

项目流程

项目流程规范体系

14.

RP 原型(Rapid Prototyping)

产品原型简单的说就是产品设计成形之前的 一个简单框架，对网站来讲，就是将页面模 块、元素进行粗放式的排版和布局，深入一 些，还会加入一些交互性的元素，使其更加 具体、形象和生动。 备注：这里设计出来的页面是粗糙的。 对于基于 Web 的企业应用，则要做一个漂亮 的页面原型。这个页面原型不需要有任何后 台程序支持，业务逻辑可以用页面间的跳转、 假设的数据简单表示。 备注：这里设计出来的页面是经过美工的。

15.

页面原型

16. 17. 18. 19. 20.

概要设计说明书 详细设计说明书 数据库设计说明书 开发周报 测试计划 测试组长根据 SOW 编写《测试计划》 ,其中 包括人员，软件硬件资源，测试点，集成顺 序，进度安排和风险识别等内容。 测试组长组织测试成员编写《测试方案》 ,测 试方案要求根据 《SRS》 上的每个需求点设计 出包括需求点简介，测试思路和详细测试方 法三部分的方案。测试方案覆盖了测试需求 点 测试用例根据《测试方案》编写的，保证用 例的可执行和对需求的覆盖。测试用例需要 包括测试项，用例级别，预置条件，操作步 骤和预期结果。测试用例应该覆盖测试方案 根据《测试计划》进度安排，测试组长进行 多轮次的测试，每轮测试完成后测试组长需 要编写测试报告，其中包括用例执行通过情 况，缺陷分布情况，缺陷产生原因，测试中 的风险等等，这时测试人员就修改增加测试 用例。待到开发修改完 bug 并转来新的测试 版本，测试部开始进行第二轮的系统测试， 首先回归完问题单，再继续进行测试，编写 第二轮的测试报告，如此循环下去，直到系 统测试结束。 在系统测试期间，测试人员还需要编写验收 手册，验收用例和资料测试用例等。 要求提供 ER 图

21.

测试方案

22.

测试用例

23.

系统测试

24. 25. 26. 27. 28. 29.2011-1-13

测试分析报告 验收测试

验收测试报告 用户手册 项目结束报告 产品运行报告中信软件教育中心就业部 Page 8 of 17

项目流程

3.4. 文档裁剪规则

尽管在文件编制中存在着很多灵活性，然而，文件的编制确实是非常必要的，其意义如前所述。为了控制这种灵活性，保证文件编制能达到应该达到的目的，对于具体的软件开发任务，应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力，制定一个文件编制实施规定，说明在什么情况下应该编制哪些文件。

为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来，这就是本例的出发点。软件的规模不妨分为四级：

件，其文件编制要求介于两级之间，可根据一个软件产品的具体情况，由项目负责人参照《产品文件体系》表的规定，确定需要编制的文件种类。

项目流程

4. 软件开发流程规范

项目启动阶段对应需求分析与规划阶段，项目实施阶段对应软件开发阶段。

4.1. 项目启动阶段

在进入具体项目实施之前为获得明确需求或进行完备可行性调研及整体策划所花费的时

4.2. 项目实施阶段

在获得明确需求或通过可行性评估后为实现项目所做的设计和实现。

项目流程

4.3. 总结阶段

项目流程

5. 软件测试流程规范

软件测试流程分3个阶段:计划与设计阶段，实施测试阶段，总结阶段。核心原则：测试从需求开始。

5.1. 计划与设计阶段

项目流程

5.2. 实施测试阶段

5.3. 总结阶段

测试工作结束或即将结束时，测试组就要开始着手准备进行总结的工作。

项目流程

项目流程规范体系

5.

编写测试报告： 在测试结束之 后，测试经理编写测试报告， 对测试进行总结， 并且提交给 项目经理， 为产品的后续工作 提供重要的信息支持。

输入条件：测试组完成了所有的测试工作 工作内容：测试经理根据测试的结果及测试工程师 提交的测试报告编写测试报告，测试报告必须包含 以下重要内容：

测试资源概述 —— 多少人、多长时间 测试结果摘要 —— 分别描述各个测试需求的 测试结果，产品实现了哪些功能点，哪些还没有实 现 缺陷分析 —— 按照缺陷的属性分类进行分析 测试需求覆盖率 —— 原先列举的测试需求的 测试覆盖率，可能一部分测试需求因为资源和优先 级的因素没有进行测试，那么在这里要进行说明 测试评估 —— 从总体对项目质量进行评估 测试组建议 —— 从测试组的角度为项目组提 出工作建议退出标准退出标准：测试经理完成了符合标准的测试报告， 发送给项目

经理。 责任人：测试经理

6.

测试验收： 测试验收工作是在 以上工作全部结束后， 对测试 的过程，效果进行验收，宣布 测试结束。

输入条件：测试组完成了所有的测试实施工作，编 写了符合标准的测试文档 工作内容：由测试经理进行测试验收，验收内容包 括：

测试效果验收 —— 测试是否达到预期目的 测试文档验收 —— 测试过程文档是否齐全， 符合标准 测试评估 —— 从总体对测试的质量进行评估 测试建议 —— 对本次测试工作指出不足，需 要在以后工作中改进的地方 宣布测试结束 —— 测试组成员签字宣布本次 测试结束退出标准：签发测试验收报告 责任人：测试经理 7. 测试归档： 测试归档是在测试 验收结束宣布测试有效， 结束 测试后， 对测试过程中涉及到 各种标准文档进行归档。 输入条件：测试验收通过 工作内容：归档测试过程所有文档，主要包括以下 文档(必须)

测试计划 测试用例 测试报告 验收报告

退出标准：全部文档归档完毕 责任人：测试经理

2011-1-13

中信软件教育中心就业部

Page 14 of 17

项目流程

6. 结束语

最后，首先恭喜你终于看完了项目流程规范体系文档，其次就是有没有问题？ 问题1：请问你真正看懂了项目流程规范体系没有。 问题2：该流程规范文档中的疏忽，你的修改意见。

问题3：最后就是问问自己哪些流程规范可以优化一下，或者至少在自己的特定项目中。

7. 附录

7.1. 流程规范文件

7.2. 版本信息

需要将日期，版本，修改描述，作者记录下来。

项目流程

7.3. 参考材料

项目流程规范体系参考国家标准制作完成。

项目流程

查阅资料：

本文来源：https://www.bwwdw.com/article/z0wi.html