项目开发向软件开发的进化

        在国内一片高举项目开发大旗的今天，我却一直坚持高喊软件开发，尽管不合潮流。我却在不得已的项目实战中发现了软件开发的生机。这或许也是项目开发所存在的问题吧。
      这就是，软件的公用性和共用性。我们可以很无奈的看到这种场景，即一个公司有众多的员工被非常相似，却又有所不同的项目维护所套牢。更有甚者，将一些员工常驻甲方（或招募一些廉价工人），专门用于项目维护。可悲啊。我觉得软件的目的在于提供应用性，而且设计则在于抽象，不断的抽象，直到适合软件的开发进度和费用的限制。
        因此，我对于目前一些公司仍在苦闷于项目维护成本过高的问题，提出这样一个软件开发模型。主要意思就是针对一个功能相同（相似）的软件，只保留一个版本，对于不同需求的更新，在这唯一版本中保留一个程序功能的最大集合。而这些功能集合的调用符合面向对象的和功能权限的原理要求。通过与需求方这一句炳来进行比对。如果符合，即认为具有功能权限。能够执行功能。否则将无法执行该功能。
       我们可以看到，这样的唯一版本将会大大减少功能代码的重写和维护。并且可以较大程度的达到功能共享和代码复用。
      可以使用下图来演示：
       〔原先的开发方式〕
                                                               
                   需求分析  －》   软件设计  －》   测试，上线    －》   维护 [开发人员]   《－ 需求更新
                                                                  －》   测试，上线    －》   维护[开发人员]   《－ 需求更新
                                                                    。。。。。。。
      〔新的开发方式〕
                                                                                                                    | 《－       更新的需求                                 
                   需求分析  －》   软件设计  －》   测试，上线    －》   维护 [开发人员]   －》 实施 [市场人员]
                                                                                                                                               －》 实施 [市场人员]
                                                                                                                                                。。。。。
       显然我们可以看到〔新的开发方式〕将会极大的降低维护的难度，减少开发人员的开发难度，研发成本，异地维护成本等。
        针对〔新的开发方式〕有些人提出下列问题。
        a。甲方索要源码，这样就把别的公司的需求或者功能点暴露了。
          回答，这是不会的。因为这种开发方式很大程度上将应用逻辑的触发和实现通过读去配置来实现。如果不将相应的配置信息提交给第三方，则第三方同样无法获取程序的执行流程，他们最大程度的能够获取散乱的功能点。
         b。如果不同的需求方之间采用的数据库不相同呢？
           回答。呵呵，应用逻辑重来就不应该和具体的数据库技术，具体的硬件信息绑定过。因此，能够适应不同的数据库，不同的接口程序。。。这才能够程序跨平台，跨数据库的应用实现。
         当然，还会有很多的顾虑，但是，你可曾想过，软件开发的开放性，公用性往往能够反映软件开发的费用。并且，项目开发这种‘中国特色’本来就不应该绻顾在软件工程已经兴起的中国。再也没有什么比减少重复开发更有意义的事情了。