软件开发过程理论的天堂和实际应用(1)

对于软件开发过程的接触从开始的WaterFall，Spiral到UP到现在的Agile的XP，Scrum也有快8年了吧。今天翻看了程序员，突然有了想要写些什么的想法，就算是Blog中的一个切入点吧。

毕业后直接进入了华为做软件开发，从一两个人的小项目到几百人开发的大产品都有参与过。自己的角色也经过从一个普通的初级程序员到TeamLeader以及维护经理这样的不同岗位。当时对公司产品的开发过程好像没有太多的想法，反而在离开了华为两年多后在异国他乡的一个IT公司做了程序员，回头看过来才有了比较。既然已经离开了华为两年多，以一个程序员的身份总结一些自己参与过的产品开发过程应该也不能够算是什么要紧的吧，不过如果有任何人有异议，请留言并告知我，谢谢。

进入华为就有机会接受了为期1个多月的CMM的培训，公司从印度请来专门的讲师。开始的一周没有配翻译，结果大家都被印度英语弄到晕倒，反馈上去以后由几个公司内的专家进行现场翻译，效果好了很多。从那个时候才开始对软件开发过程有了概念。也最初的接触到了一些工业上的产品开发概念。培训的时候，好像没有多少问题，对于印度老师讲的也都照作经典通盘接收。记得刚刚结束培训回到部门以后，现在回想来颇有点当初那些留俄回来的理想主义者的意思。对照着学来的V模型(1)，看着部门里面的开发过程处处存在问题：
没有正式的需求文档（软件需求说明书）

没有正式的设计文档（软件概要设计说明书，软件详细设计说明书）

没有单元测试（单元测试设计说明书）

没有系统测试设计文档

不过很快一场革命的雄心就在产品进度的压力下几乎烟飞灰灭了，也就继承着前辈们的行为，继续着。至此看来，那个产品没有遵循任何开发过程，似乎是无法支撑一个大型的团队。然而也许会令你吃惊的是，那是华为公司的拳头当家产品（省去这个产品的名字），版本巨多，开局数目巨大。那么是什么原因可以让它在那个特定时刻，成为成功的产品呢？忽略各种非软件因素，我个人看到的地方，也是有着普遍参考意义的一些点是：
缺陷跟踪电子流

补丁控制流程

版本控制流程

系统测试

网上问题跟踪电子流

今天先来具体说明一下缺陷跟踪电子流。通过这些年的软件开发，我越发的感觉这个是软件开发过程实施中的王牌武器之一。所谓缺陷跟踪电子流，在应用中通常有着扩展，不仅仅是对软件缺陷的跟踪，还可以提供对诸如新特性，文档设计，文档变更等等凡是需要归档的元素都进行管理。一个流程主要包括问题的提交，实施，审核，验证这样的过程。以一个普通的缺陷为例子，一个可能的流程是：
测试人员提交问题给测试经理，提供问题的具体描述和定位相关的信息

测试经理分析问题后提交给相关的软件项目经理（或者认为是无效问题退回给测试人员）， 设置正确的模块，版本等等

软件项目经理根据问题大概确定子模块，并且分发给开发人员定位。

开发人员定位后填入问题原因和大概的解决方案提交给项目经理

项目经理授权实施，并指定代码审核人

开发人员实施后验证并提交审核

审核通过后，将实施Check in，问题单提交项目经理等待新版本并自验

新的内部版本完成后，项目经理将所有问题打印并要求开发人员自验

自验通过，项目经理将问题转回测试经理

测试经理等待新版本发布，将问题转给提交人回归验证

测试人员回归验证通过后，问题关闭，归档

上面这个过程还只是一个简单的流程描述，在实际操作中，你可以预期到还会有很多的分支情况，也许应该绘制一个比较完整的流程图。

(To be continue)

(1)V模型其实并不是CMM中的内容。在CMM中只描述了需要做什么，并没有提到如何做。V模型则是一个很实际的开发过程。简单的说一下
系统需求说明书和系统测试说明书同一阶段完成

软件概要设计说明书和集成测试说明书同一阶段完成

软件详细设计说明书和单元测试说明书同一阶段完成

软件编码和单元测试同一阶段完成