软件开发的金字塔



 

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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