项目管理和质量控制之开发过程控制
项目需求稳定性与开发模型选择
项目来源通常可区分客户合同项目、内部产品更新换代。客户合同项目由于受到客户直接约束，有固定的工期，而且需求往往很不稳定，很多时候客户只指定一个大概的需求范围，由开发商在应标的时候列出能实现的功能需求、环境支持和开发费用，在多家开发商应标的情况下，客户有可能综合多家厂家的功能，要求开发商实现，还有一些项目客户只提出研究方向，根本没有具体的需求细节；内部产品更新换代需求相对稳定一些，而且工期也相对宽松，比较容易把握，但产品的需求是连续的，产品需要不停的升级增加新功能才有生命力；由于需求的稳定性不同，往往需要比较好的开发模型来支持，否则很容易发生到了项目后期才发现实现的功能与实际应用需求不符，达不到使用效果，导致项目失败；开发模型的不同，需要管理的力度也不同，管理花费的时间也不同；下图是笔者多年总结的开发模型选择经验：



瀑布模型因为需求稳定，实现细节明确，只要需求理解正确，设计没有出现大的错误，基本上按照需求分析》设计》编码》单元测试》集成》集成测试》验收》发布走下来，过程任务明确，很少出现文档代码重复评审的情况，开发人员可以专心地按阶段进行开发工作，管理也非常简单，只要把握好每个项目成员的进度，基本上可以确保完成任务了。原型演化模型因为需求不稳定，实现细节不明确，很多东西需求摸索之后才能明白怎么做、能否实现，这个时候需要快速地做出原型，在做原型的时候确定技术要点，分辨这些要点以现有项目组的水平是否能够按时完成，如果无法完成，需要向客户解释为什么，对有可能出现技术延误的功能需要提前取得客户的谅解，以便以后追加费用或者放到二期完成，因为在项目开发过程中需要不停地与用户交流，修改需求、设计、代码，工作量比较难估计，项目追踪难度高，这个时候项目经理需要建立需求矩阵、风险列表，一项一项的解决问题，协调项目成员，不停调整项目计划保证后面的工作评估尽量贴近实际，以免失控，管理工作将占项目经理大部分时间，可以说在这三个模型中项目进度是最难把握的。喷泉模型适应于产品升级开发，产品不停地更新换代，不断的增加功能，通常不会一下子全部实现所有功能，最好是分期实现，降低风险，早日回收开发成本，这种开发》测试》发布》开发》测试》发布的螺旋回溯
f式开发继保证了产品的延续性也保证了产品的稳定性，管理灵活r