个性化产品工作流程
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. <!---->功能列表
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|