个性化产品工作流程

1.    前言

1.1.   个性化产品情况

软件产品已经基本成型，已经有一个以上的用户在使用。

软件产品不是通用软件，用户的大体功能相同，但都有用户个性的需求，并进行个性实现。

1.2.   优劣分析

优势：

1.        不是通用软件，而是对不同用户进行个性实现，使系统盗版的可能性降低。

2.        由多个用户提出需求，以业务驱动技术进行实现，良好的需求用户共享，可以保持系统的先进性。

3.        核心部分已经完成，从用户提出需求到系统上线，实施时间短。

劣势：

1.        很容易对于用户需求使有快速开发方式，头痛医头，脚痛医脚，测试由于时间紧急、测试数据不完整等原因测试达不到质量要求，使系统稳定性不足。

2.        统一版本管理困难，一线人员最怕升级，不知升级后会有什么问题。

3.        由于用户的增多工作战线会拉的长，易形成救火队组织。分工不明确，到最后可能开发团体每个人是工程人员，也是开发人员还是测试人员，事情混杂，不能专心一个时间内做一件事情 。

1.3.   目的

根据以上情况及个人经验制订出以下工作流程。

 

2.    工作流程

2.1.   名词定义

个性化需求：单独为某一个用户个性所做并不涉及系统核心（委托，转换，清算，初始化）的需求，需求的失败编程影响只提实现需求实现代码内，不应有连锁影响。

系统需求：涉及系统核心（委托，转换，清算，初始化）的需求（含由于单一用户提出的涉及核心的需求，因他个性的需求修改核心，会影响其他用户）。

2.2.   个性化需求流程

1.      用户工程人员提出需求文档及要求

2.      系统开发负责人了解情况后进行分析，如果决定开发进行下一步，否则告诉需求提出人需求被拒绝。

3.      对需求进行统一编码

4.      安排相关人员开发，测试人员为用户工程人员。

5.      在紧急或外部开发方式情况可以由工程人员开发，用户直接测试。

6.      测试流程按部门〈测试流程〉进行。

7.      测试通过，需求放在〈功能列表〉

8.      安排人员更新〈用户手册〉

2.3.   系统需求流程

1.      用户工程人员或相关人员提出需求文档及要求

2.      系统开发负责人进行内部讨论相关性后，如果决定开发进行下一步，否则告诉需求提出人需求被拒绝。

3.      对需求进行统一编码，对需求编写测试案例

4.      安排相关人员开发，安排测试人员

5.      测试流程按部门〈测试流程〉进行

6.      测试通过，需求放在〈功能列表〉

7.      安排人员更新〈用户手册〉

2.4.   系统升级及新增功能发布流程

1.      对于个性化升级在测试完毕后对个性用户进行升级

2.      系统统一升级在每月的月中进行

3.      新增功能信息在每月的月中同系统统一升级一起发布

4.      紧急 BUG 问题系统升级可以随时

5.      用户负责人对用户进行的程序升级必须记录在〈用户维护记录〉中

6.      〈用户维护记录〉系统负责人每月必须进行一次审核

 

3.    关于作者

王辉　从 1994 年开始工作，曾担任教师、数据库管理员、主程序员、项目经理，现在深圳一家公司工作。可以通过 ddxxkk@21cn.com 联系。

4.    附录

4.1.   简明需求

* 表示必须

1 *需求提出人（公司、个人）及联系方式（电话、MSN等）

2 需求提出的假设（为什么提出本需求，用于解决什么问题，由此可以更深入明确及理解需求）

3*需求的编号（由系统负责人统一编码，编码人将本号码放在程序第一行）

4 *需求的具体要求

1）输入内容（界面的位置在是业务管理还是系统管理，是新加FORM还是在某上FORM上修改）

2）输出内容（通过什么查询到结果，是如果是表要说明表记录和字段变化，如果是界面说明输出项）

5需求实现验证人（本需求验证人必须明确，最好是需求提出者是验证人）

6*其他

1）实现代码时的提示（那个代码可以复用）

2*）时间完成要求

3）技术支持人

4）业务支持人

5）相关文档（具体的法规）

 

4.2.   测试流程

1.        程序员完成自测试，对测试人员进行需求和功能讲解 （可选：提交相关《需求说明书》），测试人人员进行桌前程序运行检查，如果检查成功下入一下步，否则修改程序。

2.        程序员提交程序（相关安装及使用说明）、功能列表 （推荐提供《测试案例》））给测试人员进行确认测试。

3.        测试人员在相应的测试时间内完成《测试 BUG 报告 》，中间如果有重大不可测试问题，程序员提供紧急技术支持，在 2 小时内解决问题，否则结束测试进入第一步。

4.        程度员在相应的时间内根据《测试 BUG 报告 》修改程序，添加修改人及时间。

5.        提交修订后《测试 BUG 报告 》和新程序给测试人员时行回归测试，测试完毕后进入回归测试，添写确认人及时间。

6.        如果 BUG 数多于五个，循环进入第一步，否则进行下一步。

7.       测试人员添加《功能列表》的测试确认人与时间。

8.       发布新版本给用户进行验收测试 ，测试后由安装或技术支持人员添加用户确认人及时间（推荐用户签字完成《功能确认书》。

4.3.   功能列表

4.3.   功能列表 业务编号 业务名称 业务描绘需求 分析人及 完成时间 相关功能（模块） 功能描绘 代码实现人及时间 自测时间 测试人及 测试完成时间 用户确认人 及时间