摘要：目前市场上定义了多种软件开发模型：传统的瀑布模型（包括改进后的V模型，W模型（也称双V模型）），以及迭代模型（比如：RUP以及目前比较流行的敏捷模型）。本文根据个人在实际工作中的多年感受，创建了这个开发模型。
目前市场上定义了多种开发模型：传统的瀑布模型，改进后的V模型，W模型（也称双V模型），以及迭代模型（比如RUP以及目前比较流行的敏捷模型）。我根据个人在实际工作中的多年感受认为瀑布模型（包括：V模型，W模型）优点在于条理比较清晰，分工比较明确，虽然已经落后，但它是其他模型的基础。在迭代模型内每一次迭代都可看作为一个小的瀑布模型，开发永远不可先于需求与设计，开发产品完毕肯定要对产品进行一次严格的测试。迭代模型的优点在于通过多次迭代，可早期看到产品，发现问题，通过PDCA，在每次新的迭代内不断进行改进。敏捷开发模型优点在于强调快速开发，拥抱变化，特别SCRUM框架，引入SCRUM MASTER角色，在小组内亲临指导，处理小组与小组沟通问题，可以让研发人员专注于研发本身，减少外界干挠（在这里我特别指出，许多研发人员，技术能力很强，但缺乏沟通能力，但这样的人才同样也是我们非常需要的）。
本模型特点是：
1）术业有专攻，闻道有先后，强调每个过程必须有专门专业人士承担（当初，戴明博士在日本企业推广流水线作业模式，每个流水线由专业员工操作，从而提高了产品质量，我个人认为在软件行业也是必须的）。
2）需求分析师是团队中的业务专家，系统设计师是团队中的技术专家。这两个角色非常重要。
3）开发与测试独立，或者说测试完全独立性，有助于提高产品质量。
4）引入研发小组概念，整个研发过程是个迭代过程。
5）引入研发小组长角色，类似于SCRUM框架中的SCRUM MASTER角色。
6）简化文档个数，强调文档沟通与口头沟通相结合。
1，角色
1.1 技术角色
1.1.1 系统分析工程师
解决产品做什么?是团队中的业务专家
职责：
1）了解用户需求（包括功能需求与性能需求）；
2）用户一起分析用户需求是否合理；3）与用户一起分析用户需求是否存在矛盾；
4）将确定的用户需求转换为《需求规格说明书》；
5）将《需求规格说明书》转为《用户故事》；
6）维护《需求规格说明书》和《用户故事》；
7）评审《验收测试用例》；
8）与系统设计工程师讨论迭代次数，以及每次迭代用户故事，并决定由那些研发小组进行开发与测试。同时将结果上报给开发经理与测试经理；
9）与系统设计工程师一起讨论已发现的缺陷，决定缺陷状态。若决定修改，进入缺陷修改流程；
10）与系统设计工程师一起讨论软件系统维护工程师在客户处发现的问题，是作为一个新特性在下版本中解决还是以补丁形式解决。若以补丁形式解决，进入补丁发布流程。
说明：
一到多个，必须独立。
1.1.2 系统设计工程师
解决产品如何做，是团队技术专家。
职责：
1）评审《需求规格说明书》；
2）选择开发操作系统平台；
3）选择数据库平台；
4）建立系统架构模型；
5）选择开发语言类型；
6）选择测试方法；
7）选择测试平台；
8）进行软件架构设计，书写并维护《系统架构说明书》；
9）评审《系统测试用例》;
10）与系统分析工程师讨论迭代次数，以及每次迭代内容，并决定由那些研发小组进行开发与测试。同时上报给开发经理与测试经理；
11）与系统分析工程师一起讨论已发现缺陷，决定缺陷状态。若决定修改，进入缺陷修改流程；
12）与系统分析工程师一起讨论软件系统维护工程师在客户处发现的问题，是作为一个新特性在下版本中解决还是以补丁形式解决。若以补丁形式解决，见补丁发布流程。
说明:
一到多个，可由开发经理或测试经理担当。
版权声明：51Testing软件测试网及内容提供者拥有本文全部版权，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
