软件开发过程的组织和实现

　　软件开发过程的组织

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

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

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

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

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

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

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

　　瀑布模型完全忽视了软件开发过程的动态变化。恐怕只有那些已经发展得非常成熟，且规模不大的系统，例如：用Access做后台，用VB画前端的数据库应用程序，才有瀑布模型一展拳脚的地方。

　　相比之下，现在常用的一些周期模型则更接近于人的自然思维，例如螺旋模型就是一种我比较喜欢的模型。

　　软件开发过程的实现

　　具体到每一步的工作要怎样完成，我前面已提到过，是非常灵活的，只要把握住大体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的就是文档的编写。文档的作用在于以下3个方面：一是可以帮助整理思路。把要完成的目标，系统的结构，每一个模块的功能等整理一下，然后分门别类地写下来，这样在开发的过程中，就有据可依，在需要回过头来修改设计的时候，也有证可考。二是便于交流。想象一下开会时的情形。一大帮子人争先恐后，激烈辩论，然后会终人散，思想灵感也就随之散了，结果是开了半天会，什么也没讨论出来。这就是后来会议记录被发明出来的原因。在脑子里的东西一多，就会散而且乱，用语言表达的时候，很容易会丢三落四，别人也很难把握住你的思想。但经过整理写在纸上以后，则会清晰得多，无论是别人还是自己，看起来都可以一目了然。三是可以作为以后维护时的参考资料。有一句名言：“笔和纸永远都比大脑可靠”，意思就是说，放在大脑里的东西说不准哪天就忘了，但写在纸上的东西，只要不发生什么意外，一般是丢不了的。当过了一段时间，你需要再回过头来修改你的程序的时候，你就会发现，你以前写下的文档实在太有价值了。别指望你的源代码，对于复杂一点的程序来说，单纯的源代码几乎会扼杀掉你所有的时间。

　　至于文档怎样写，教科书上大多都是一条一条列得满满的，就像一些地方政府的规章制度一样，其实大可不必，只要能满足需要就行。如果是在公司，则每个公司大多都有一套自己内部的文档模板，个人没有选择的余地。而对于像我这种业余的，写个程序除了练练手艺，无非就是供自己和亲朋好友玩玩，则根本没必要搞得过于复杂。以下就是我自己的一份文档模板的概要，麻雀虽小，但五脏俱全。

　　可行性分析 就是关于当前项目能不能干的分析结果。主要考虑的方面包括：是否能把这个项目开发出来；假如可以的话，预计需要多少时间，能否满足客人的时间要求；需要多少人力和资金的投入；最重要的是，这个项目能否赚钱，能赚多少。还要对可能存在的风险进行评估，例如，万一项目主管被车撞了要怎么办。当然，这对于我来说毫无意义，我在这里写上只是为了保持完整而已。

　　项目描述 这是在决定立项以后，对当前项目的一份扼要说明。必须包括以下几个方面：(1)项目的名称或编号；(2)对客户方的描述；(3)对开发人员的描述；(4)工程任务的描述；(5)工程的输入和输出；(6)开发环境；(7)其他的附加条件。在这里，对工程任务的描述是从整体的角度来说的，例如：能对当前的

    更多信息请访问：新浪自考频道 自考论坛 自考博客圈

　　特别说明：由于各方面情况的不断调整与变化，新浪网所提供的所有考试信息仅供参考，敬请考生以权威部门公布的正式信息为准。