规范只是提供一个好的例子，以描述一种思想，具体到每一个环节怎样实现，对于不同的公司或团体则是各有千秋，因为根本就不可能存在一套放之天下皆可行的标准。就像C++，也只是提供了一套标准，不同的编译器都有各自的实现，对标准的支持程度也互不相同。所以，在不同的公司或团体中，尽管核心思想都是大同小异，但具体到每一个步骤，往往都是不相同的。我手上就有一份GB8567-88的文档模板，对于那些顶多只有几千行的小程序来说，假如真按上面的要求全写上了，简直就是一种折磨！据说，当前业界最权威的标准是CMM。



软件开发过程的组织



如何组织软件开发过程中的每一个步骤，就是软件开发周期模型要解决的问题。

其实开发软件，就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法，即我写的这个程序是要干什么的；然后就是对要实现的核心功能大概构思一种或多种实现方法，并从中选出一种自认为是较好的；接下来就是将涉及的各种主要或次要功能分成各个模块；最后就是分模块来编码和DEBUG。在我看来，除了第一步外，其余的步骤应该是一个循环的过程。在编码的过程中，你总是需要不断地回过头来修改原先的模块设计，甚至最初选定的实现算法。例如，最简单的情况是，你通常都会突然发现在两个成员函数中有相同的代码，这时，程序员的直觉告诉你，你应该为你的类再添加一个private成员函数并将公共的代码放于其中；又或者是，你突然发现一个模块中的某个功能具有很高的通用性，完全可以提取出来作为一个独立的功能组件，而你也确实应该这样做；要是倒霉一点的话，你很有可能会在最后调试的时候突然发现，你的程序跑得太慢了，连你自己都无法忍受。于是你找呀找，终于找到了80/20中的那段可恶的20，原来是用了一个O（N）的算法，这时你就得老老实实地换一个更好的算法。

总之，除非你是先知，否则，对于一个具有一定规模和复杂度的软件来说，在“设计—编码”这个过程中，实在有太多的不可预知性和变化性，你根本不可能全盘地把握住每一个细节。当然，这是建立在我现时的水平之上的观点。我不知道是否成为高手以后会有所不同，因为我身边没有那样的人。

既然软件开发是一个具有不可预知性和变化性的动态的过程，那么，对其每一个步骤的组织，即周期模型，就必须包容它的这种性质。

现在来看一下最古老，最经典，同时也是最倍受批评的瀑布模型。

瀑布模型是一种线性模型，其最大的特点就是简单直观。它将软件开发过程规划为“分析—设计—编码—测试—维护”的线性过程，也就是说，你必须首先把你的软件要干的每一件工作都分析得彻彻底底，再对每一个模块，每一个接口，事无巨细，都设计得非常完美，然后才开始编码的工作，并且在编码的时候就像在对着图纸砌模型，根本不用再回头作任何修改，当然，是在把所有的代码都写完以后才开始测试的。

整个过程，光想一下就觉得冒冷汗！

[ft=,,]瀑布模型完全忽视

如果本文没有解决您的问题，请进老妖怪开发者社区提问