实现个性化软件产品的工作流程

发表于:2007-05-26来源:作者:点击数: 标签:
实现个性化软件产品的工作流程 王辉(转载自赛迪网) 2004年02月05日 1. 前言 1.1.个性化产品情况 软件产品已经基本成型,已经有一个以上的用户在使用。 软件产品不是通用软件,用户的大体功能相同,但都有用户个性的 需求 ,并进行个性实现。 1.2.优劣分析

实现个性化软件产品的工作流程 

王辉(转载自赛迪网)   
2004年02月05日 

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.附录 

3.1.简明需求 

  * 表示必须 

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

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

  3*需求的编号(由系统负责人统一编码,编码人将本号码放在程序第一行) 

  4 *需求的具体要求 

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

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

  5需求实现验证人(本需求验证人必须明确,最好是需求提出者是验证人) 

  6*其他 

  1)实现代码时的提示(那个代码可以复用) 

  2*)时间完成要求 

  3)技术支持人 

  4)业务支持人 

  5)相关文档(具体的法规) 

3.2.测试流程 

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

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

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

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

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

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

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

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

3.3.功能列表





原文转自:http://www.ltesting.net