在软件开发中，能够用一个金字塔来形容从需求分析到编码这整个过程。从中来分析整个开发过程以及开发过程中是否规范的利与弊。

金字塔从下到上依次是由需求分析、概要设计、具体设计、编码组成，这里把需求分析又分成了需求和软件需求规格说明书，如图1所看到的：

图1 规范的软件开发金字塔

以下从下到上開始来分析规范的软件开发金字塔。

在软件开发中，不管你的软件或大或小，需求分析是最重要且不可缺少的，也是整个软件开发的基础。图1中浅绿色部分即为需求分析，这里把需求分析分为需求和软件需求规格说明书。在实际的项目开发中，非常多的项目是没有需求规格说明书的，一方面可能项目太小，一方面对文档的要求不够。

需求分析是为了明白用户和客户的须要是什么，须要我们的软件做什么，解决什么问题，软件作成什么样子，终于达到什么效果。这差点儿相同也就是项目所要达到的目标。有了目标之后，我们才開始对须要解决的问题进行具体的分析，弄清楚问题的要求，包含须要输入什么数据，得到什么结果，最后应输出什么，处理过程中须要遵循什么准则等等，最后整理出软件需求规格说明书。软件项目属于project项目，而软件需求规格说明书就相当于project的设计效果图，我们是通过这个设计效果图来与客户达成一致，也便于开发者有一个明白的开发目标。假设缺少了这张效果图，我们辛辛苦苦开发出来的软件有可能终于不是客户所须要的效果，而导致反工。

有了设计效果图，如今就该来搭建软件的架构、表述各模块功能、模块接口连接和数据传递的实现等各项事务了，这个阶段就是概要设计，即图1中棕色部分。在概要设计阶段我们须要把系统从总体的角度按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等去进行软件结构设计。我们还须要对数据特征进行描写叙述、确定数据的结构特性、以及数据库的设计来完毕数据结构的设计。通过软件结构设计和数据结构设计完毕目标系统的逻辑模型。

目标系统的逻辑模型设计好了，接下来我们就应该開始设计每一个模块的实现算法、所需的局部数据结构，对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，把程序的具体实现的功能、现象等描写叙述出来。这就是具体设计所须要我们做的事情了，图1中的黄色部分即为具体设计。

有了需求、设计效果图、逻辑模型、详细实现的描写叙述，我们就能够依据系统的特点以及公司的人员情况来确定最后採用什么开发语言，由哪个项目组去编码实现。到这里，我们的软件开发金字塔也就基本开发完毕。

图2 不规范的软件开发金字塔

在实际的开发过程中，不管我们是否明显的划分这些阶段去做，我们都是潜在的依照着这种流程去开发的，仅仅是一些阶段，我们草草的走过了，或者是没有留下该阶段的文档记录，过程如同图2。通过这些金字塔，我们还能够形象的来表现出我们须要在这些阶段大概花费的时间，以及后期维护过程中可能存在的风险。

图3 金字塔中各层级的功能

从图3中，我们能够看到各个阶段的责职，需求是客户提出的问题，须要我们的软件去解决的问题，解决这些问题的时候有什么准则等等，一切都是环绕着问题。软件需求规格说明书是为了解决这些问题设计出来的设计效果图,我们用它来与客户达成一致，客户惬意了我们便能够进行下一步的工作。这个设计效果图也将是指导我们的开发者进行开发的标准，由于它的终于效果是与客户达成一致的，使客户终于所想要的，我们仅仅有依照这个标准开发出来的软件最后才干顺利的通过客户的验收。有了设计效果图我们是不是就能够直接上手開始编码了呢？我觉得还欠点火候。尽管说我们已经有了设计效果图，可是我们对整个系统的认识还是没有非常清楚，我们还有非常多模糊的地方。所以我们须要依据设计效果图来建立一个目标系统的逻辑模型，通过这个逻辑模型来分析系统的总体架构，数据结构的设计，各个模块的划分，以及未来新的问题出现时对系统可能带来的风险等等。我们仅仅有从总体去审视这个系统，才干更好的去搭建系统的架构，使系统更稳健，代码结构设计更合理，才干经得起那些未知的问题出现时的考验。那么怎么样才干更好的去编码呢，我们就来对这个目标系统的逻辑模型进行具体的设计描写叙述。

依照整个规范的过程下来，真正编码前所花费的时间，要比编码的时间多得多。然而我们的工期却是有限的，因此非常多公司都把当中的非常多过程都草草而过，採用的是图2不规范的软件开发金字塔，前期的工作花费的时间非常少，大部分的时间都放在了编码中。事实上这样的不规范的金字塔中的编码过程也包括了概要设计和具体设计，仅仅是他们是同步进行的。

不规范的金字塔漏洞百出，存在的问题也非常多，看似能非常快的把系统做出来了，尽管存在非常多问题，以后也能够慢慢的去改动，总之能在工期结束时能给客户交个系统，大体的功能实现即可。然而，我们对一个软件，所花费最多的时间在哪呢？是开发吗？非常显然不是。我们开发出一个系统不是给了客户就完事了，以后不用再管了，我们还要对它进行维护，对它出现的问题进行解决，我们所花费在对系统后期维护上的时间要远远大于开发的时间。

非常明显，我们做好了前期的工作，也与客户达成了一致，也对系统的各个方面做好了分析，能通过总体全面的去分析系统。那么，不管后期维护中，有什么新需求的添加，也不会对整个系统的结构造成多大的影响。后期维护人员即使是一点都不了解系统的，前人也都留下了“设计效果图”，目标系统的逻辑模型，以及系统实现的描写叙述，非常快他就能了解整个系统，也能给好的參与到系统的维护中去。即使有新的需求，他也能依据系统的总体架构去又一次设计和开发，保证系统的总体架构，性能以及代码结构的质量。这样就能非常大程度的减少了维护成本。

而不规范的金字塔，则把大部分的时间花在了编码上，前期工作也就匆匆的做了一下，也没留下多少实用的设计文档。对系统的非常多地方都是模糊的，也有可能由于这些模糊而在编码过程中遇到非常多问题，而没有非常好的解决方式，或者解决方式仅仅考虑了当前模块的，忽略了系统的总体，从而又产生了别的问题，如此恶性循环下去。终于做出来的系统，非常有可能还不是客户所期望的效果，还存在非常多问题和漏洞，从而产生了非常多的bug。后期维护时，什么实用的文档也没有留下。这样一来，开发成本非常有可能没有减少下来，维护成本却非常大程度上添加了。

即使后期维护时才来编写设计文档，尽管非常大程度上利于后期开发维护，可是编写出来的文档或多或少都会受到已成型的系统的干扰，比方理解不够准确，缺少一些重要的分析等等都会对后期的维护造成影响，导致编写出来的文档可能存在设计上的问题，导致不了解系统的后期维护人员在后期开发维护中造成非常多不良的影响。比方华北票据系统的分公司机打票管理模块和分公司定额票管理模块的功能基本都是一样的，从浏览器的地址栏来看，路径是不一样的，这两个模块应该是分开了单独写的，从实现的角度来说，这两个模块是能够放在一起来处理和显示的，然而后期编写的文档仅仅能依照分开的来写，那么假设后面再有别的类型的票据添加，添加新的模块，功能也是差点儿相同的，那么依照文档来开发，已经实现的模块代码仅仅因票据类型不同而又得再写一遍，无疑是添加了维护成本。类似于这种问题，其它的老系统也存在。

综上，我们的开发过程和文档的编写越规范，从长远的角度来说更利于我们的软件产品的开发和维护，也能保障我们软件产品的质量，从而减少开发成本和维护成本。