在软件开发中，可以用一个金字塔来形容从需求分析到编码这整个过程。从中来分析整个开发过程以及开发过程中是否规范的利与弊。
金字塔从下到上依次是由需求分析、概要设计、详细设计、编码组成，这里把需求分析又分成了需求和软件需求规格说明书，如图1所示：
图1 规范的软件开发金字塔
下面从下到上开始来分析规范的软件开发金字塔。
在软件开发中，无论你的软件或大或小，需求分析是最重要且必不可少的，也是整个软件开发的基础。图1中浅绿色部分即为需求分析，这里把需求分析分为需求和软件需求规格说明书。在实际的项目开发中，很多的项目是没有需求规格说明书的，一方面可能项目太小，一方面对文档的要求不够。
需求分析是为了明确用户和客户的需要是什么，需要我们的软件做什么，解决什么问题，软件作成什么样子，最终达到什么效果。这差不多也就是项目所要达到的目标。有了目标之后，我们才开始对需要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，得到什么结果，最后应输出什么，处理过程中需要遵循什么准则等等，最后整理出软件需求规格说明书。软件项目属于工程项目，而软件需求规格说明书就相当于工程的设计效果图，我们是通过这个设计效果图来与客户达成一致，也便于开发人员有一个明确的开发目标。如果缺少了这张效果图，我们辛辛苦苦开发出来的软件有可能最终不是客户所需要的效果，而导致反工。
有了设计效果图，现在就该来搭建软件的架构、表述各模块功能、模块接口连接和数据传递的实现等各项事务了，这个阶段就是概要设计，即图1中棕色部分。在概要设计阶段我们需要把系统从整体的角度按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等去进行软件结构设计。我们还需要对数据特征进行描述、确定数据的结构特性、以及数据库的设计来完成数据结构的设计。通过软件结构设计和数据结构设计完成目标系统的逻辑模型。
目标系统的逻辑模型设计好了，接下来我们就应该开始设计每个模块的实现算法、所需的局部数据结构，对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，把程序的具体实现的功能、现象等描述出来。这就是详细设计所需要我们做的事情了，图1中的黄色部分即为详细设计。
有了需求、设计效果图、逻辑模型、具体实现的描述，我们就可以根据系统的特点以及公司的人员情况来确定最后采用什么开发语言，由哪个项目组去编码实现。到这里，我们的软件开发金字塔也就基本开发完成。
图2 不规范的软件开发金字塔
在实际的开发过程中，无论我们是否明显的划分这些阶段去做，我们都是潜在的按照着这样的流程去开发的，只是一些阶段，我们草草的走过了，或者是没有留下该阶段的文档记录，过程如同图2。通过这些金字塔，我们还可以形象的来表现出我们需要在这些阶段大概花费的时间，以及后期维护过程中可能存在的风险。
图3 金字塔中各层级的功能
从图3中，我们可以看到各个阶段的责职，需求是客户提出的问题，需要我们的软件去解决的问题，解决这些问题的时候有什么准则等等，一切都是围绕着问题。软件需求规格说明书是为了解决这些问题设计出来的设计效果图,我们用它来与客户达成一致，客户满意了我们便可以进行下一步的工作。这个设计效果图也将是指导我们的开发人员进行开发的标准，因为它的最终效果是与客户达成一致的，使客户最终所想要的，我们只有按照这个标准开发出来的软件最后才能顺利的通过客户的验收。有了设计效果图我们是不是就可以直接上手开始编码了呢？我认为还欠点火候。虽然说我们已经有了设计效果图，但是我们对整个系统的认识还是没有很清楚，我们还有很多模糊的地方。所以我们需要根据设计效果图来建立一个目标系统的逻辑模型，通过这个逻辑模型来分析系统的整体架构，数据结构的设计，各个模块的划分，以及未来新的问题出现时对系统可能带来的风险等等。我们只有从整体去审视这个系统，才能更好的去搭建系统的架构，使系统更稳健，代码结构设计更合理，才能经得起那些未知的问题出现时的考验。那么怎么样才能更好的去编码呢，我们就来对这个目标系统的逻辑模型进行详细的设计描述。
按照整个规范的过程下来，真正编码前所花费的时间，要比编码的时间多得多。然而我们的工期却是有限的，因此很多公司都把其中的很多过程都草草而过，采用的是图2不规范的软件开发金字塔，前期的工作花费的时间很少，大部分的时间都放在了编码中。其实这种不规范的金字塔中的编码过程也包含了概要设计和详细设计，只是他们是同步进行的。
不规范的金字塔漏洞百出，存在的问题也很多，看似能很快的把系统做出来了，虽然存在很多问题，以后也可以慢慢的去修改，总之能在工期结束时能给客户交个系统，大体的功能实现就行。然而，我们对一个软件，所花费最多的时间在哪呢？是开发吗？很显然不是。我们开发出一个系统不是给了客户就完事了，以后不用再管了，我们还要对它进行维护，对它出现的问题进行解决，我们所花费在对系统后期维护上的时间要远远大于开发的时间。
很明显，我们做好了前期的工作，也与客户达成了一致，也对系统的各个方面做好了分析，能通过整体全面的去分析系统。那么，无论后期维护中，有什么新需求的增加，也不会对整个系统的结构造成多大的影响。后期维护人员即使是一点都不了解系统的，前人也都留下了“设计效果图”，目标系统的逻辑模型，以及系统实现的描述，很快他就能了解整个系统，也能给好的参与到系统的维护中去。即使有新的需求，他也能根据系统的整体架构去重新设计和开发，保证系统的整体架构，性能以及代码结构的质量。这样就能很大程度的降低了维护成本。
而不规范的金字塔，则把大部分的时间花在了编码上，前期工作也就匆匆的做了一下，也没留下多少有用的设计文档。对系统的很多地方都是模糊的，也有可能因为这些模糊而在编码过程中遇到很多问题，而没有很好的解决方案，或者解决方案只考虑了当前模块的，忽略了系统的整体，从而又产生了别的问题，如此恶性循环下去。最终做出来的系统，很有可能还不是客户所期望的效果，还存在很多问题和漏洞，从而产生了很多的bug。后期维护时，什么有用的文档也没有留下。这样一来，开发成本很有可能没有降低下来，维护成本却很大程度上增加了。
即使后期维护时才来编写设计文档，虽然很大程度上利于后期开发维护，但是编写出来的文档或多或少都会受到已成型的系统的干扰，比如理解不够准确，缺少一些重要的分析等等都会对后期的维护造成影响，导致编写出来的文档可能存在设计上的问题，导致不了解系统的后期维护人员在后期开发维护中造成很多不良的影响。比如华北票据系统的分公司机打票管理模块和分公司定额票管理模块的功能基本都是一样的，从浏览器的地址栏来看，路径是不一样的，这两个模块应该是分开了单独写的，从实现的角度来说，这两个模块是可以放在一起来处理和显示的，然而后期编写的文档只能按照分开的来写，那么如果后面再有别的类型的票据增加，增加新的模块，功能也是差不多的，那么按照文档来开发，已经实现的模块代码只因票据类型不同而又得再写一遍，无疑是增加了维护成本。类似于这样的问题，其他的老系统也存在。
综上，我们的开发过程和文档的编写越规范，从长远的角度来说更利于我们的软件产品的开发和维护，也能保障我们软件产品的质量，从而降低开发成本和维护成本。