导入标准软件开发工艺流程

入职后第四个月总部人员开始对我们进行“软件开发工艺流程”的培训。

那个时候总部的IT部门建设也一直在进行中，是请IBM的顾问做的规划。IBM顾问帮助导入了标准的软件开发流程也就是我们所熟悉的瀑布模型。

定制了一套应用系统开发规范，现在看来这套“规范”显得很笨重，但是在当时的实际开发中很是管用，尤其在和外包厂商合作开发的时候，这个“开发流程”很大程度上减少了项目失败的风险。



整个开发规范规定了每个开发阶段的人员角色和产出文档以及合作的流程：

1.系统分析阶段（需求分析）

主要执行人员：User，系统分析师（SA）

在系统分析阶段，User提供需求的原始文档。SA根据“需求访谈的记录”必须产出以下文档：应用系统需求规格书，组织架构图（当前项目所涉及的组织架构和项目管理组织架构），业务功能划分说明，业务流程图，数据字典说明和UseCase。

2.系统分析阶段

主要执行人员：系统设计师（SD）

SD会在系统分析的后期进入项目，开始工作。SD阅读SA的文档并产出应用系统设计规格书，系统架构设计说明，Table设计清单，系统衔接界面设计等。SD还需要对AP人员进行技术支持和代码测试，以及核心公用模组的开发。

3.系统撰写阶段

主要执行人员：应用程序开发人员（AP）

AP人员根据SD的产出文档，撰写并测试应用程序，产出程序源代码文件和测试用例文档。

4.系统测试阶段

执行人员：测试人员。

外包的时候会有专门的测试人员测试。在整个项目开发中一直在进行，为了保证系统的质量专门安排了以SA为主导的系统整合测试和以使用者为主导的验收测试。

5.上线部署阶段

执行人员：项目负责人，User，SA，SD 和DBA。

一般有项目负责人主导完成，在实际的开发中项目负责人由SA担任。

这个开发规范中要求产出的文档太多，在新项目开发时加长了项目开发时间。

在系统维护时期，也不是很灵活。一个简单的增加字段的修改就需要修改三份文件，UseCase需求文件，SD系统设计文档和程序源代码。

如果再加上流程中的权限管控而带来的签核，那么一个很小的改动，就会让人直接疯掉。

两年后我们开始改善这个开发流程。在改善中，AP人员提出一个很疯狂的想法，取消所有的签核流程，废掉所有的文档，只需要一份源代码就可以了。这样显然也是不可行的，没有文档说明的程序代码会很快变成烂泥潭。也不利于各个成员之间的交流学习和新人的教育训练。

最后我们决定如果是外包项目和新项目，仍然使用这个规范。待系统上线后，冻结系统设计文档，维护阶段可以不修改此文档。

在维护阶段，系统设计和撰写测试都有一个人负责，可以只改代码和需求文档。这样就减少了工作量，缩短了程序发布的时间。

为了保证系统的程序质量在系统改善会议上增加一项“检核工作”，每隔一段时间（3个月）对需求文档和程序源代码版本说明是否一致，进行检查。

对出现的问题，提出相应的改善意见。

在实际的工作中发现，当各个角色（系统分析SA，系统设计SD，AP和Tester）都有一个人员承担时，会出现“太忙了，忘记同步文档”的情况，各种检查形同虚设。

9e56

这个时候，最好独立出一个角色或者有专职人员负责这个工作。这也是为什么我们的SA一定要独立的原因。

20130619 发布

20130620 第一次修改