信息系统的开发模型

二、信息系统的开发模型

开发信息系统最常使用的模型是传统的软件生命周期瀑布模型（Waterfall Model），以及在计算机辅助软件工程支持的基础上发展起来的快速原型模型（Prototyping）。

1．生命周期瀑布模型

生命周期瀑布模型是软件工程中基于软件生命周期建立起来的传统开发模型（如图3-1所示）。它规定了软件生命周期上各阶段的软件工程活动：系统分析、系统设计、系统实施及系统运行与维护。各阶段严格按顺序进行，前一阶段的任务没有完成，不能进入下一阶段工作；每一阶段的工作成果需经过评审，评审确认无误，才能作为下一阶段的输入和依据；若经过评审认为有问题而且问题源于前面的阶段，则要返回到前一阶段甚至更前的阶段重新进行。

图3-1　生命周期瀑布模型

在每个阶段结束时要求交出规定的软件文档资料，作为评审的依据和下一阶段工作的依据，如系统分析阶段的可行性分析报告、软件开发计划和系统需求分析说明书，系统设计阶段的系统软件设计说明书，系统实施阶段的源程序清单和系统测试报告，系统运行与维护阶段的软件维护报告等。

软件生命周期法应遵循以下的软件设计准则：

（1）认识抽象

软件开发的过程就是从现实世界的问题论域向软件系统的映射，其中抽象是认识复杂现象的强有力的思维方法。在建立软件的设计模型时常采用分层抽象的办法。在最高的抽象层次上，可以采用问题的环境语言概括地描述问题的解法；在较低层次上，则采用过程化的方法描述问题的解法。

抽象的内容包括过程抽象、数据抽象、控制抽象等。抽象与模块化相结合，使软件生命周期的每一个步骤都是对软件问题解法的抽象层次的一次精化。当软件的源代码编写完成时，即完成了最低层次的抽象，完成了软件系统的开发。

（2）模块化

软件模块（Module）是由数据说明、可执行语句等构成的一段程序，它可以实现某个功能。软件模块有唯一的名称，可以通过模块名标识和调用。例如，程序中的procedure（过程）、function（函数）、subroutine（子程序）、macro（宏）、block（块）等都可以是模块。模块化就是把一个程序划分成许多模块，每个模块实现一个子功能，模块与模块之间有机地关联且相互调用。模块的集合就是程序的整体。

模块化把一个复杂的软件系统的设计问题转化为若干个较小的、容易处理的模块的设计问题，便于分别解决。而且，模块化设计要求模块的独立性强，模块之间的耦合强度弱，能够有效地缩小程序中出现的错误的影响范围，极大地增加了软件的可靠性和软件开发效率。

（3）信息隐蔽和局部化

信息隐蔽是指每个模块的实现细节（过程和数据）对于其他模块是隐蔽的和不能访问的。通过抽象，可以确定构成软件的过程（或信息）实体；通过信息隐蔽，可以定义和实施对模块的过程细节和局部数据结构的存取限制。

信息局部化是指把一些关系密切的软件元素物理地就近安置，例如模块中使用的局部数据结构。局部化有助于实现信息隐蔽。

信息隐蔽和局部化可以使得在测试和维护期间修改软件所发生的错误被局限在一个或少数模块内，不致波及其他部分。

（4）结构化程序设计

结构化程序设计采用自顶向下逐步求精的方法，而且只使用以下3种实现单入口和单出口的基本控制结构：顺序、选择和循环。

在系统的总体设计阶段采用自顶向下逐步求精的方法，可以把一个复杂问题的解法分解成一个由模块组成的多层次结构的软件；在系统的详细设计阶段采用自顶向下逐步求精的方法，可以把一个模块的功能逐步分解成一系列的具体处理步骤。

（5）软件规范

严格遵守软件规范是软件开发成功的重要保证。当今国际和国内都制订了一系列的软件规范，对软件开发的目标、开发方法、开发过程、软件文档、质量标准等都给出了明确的规定。软件规范是软件生产工业化的标志之一。

生命周期瀑布模型是软件开发的完整的管理方法，它使早期的手工作坊式的软件开发转变为软件工程，在消除非结构化软件、降低软件的复杂度方面起到了显著的作用，使软件的开发有一套严格的计划、步骤、规格、方法，保证软件产品达到预期的质量要求，按时交付。因此，软件生命周期的瀑布模型自20世纪70年代以来得到了广泛的传播，而且编入了许多软件工程规范中。

但在实践中，生命周期瀑布模型也暴露出了很多缺点，最主要的问题是它缺乏灵活性，很难面对和处理软件开发中存在的各种风险。生命周期模型按照现代工业的工程化生产模式，规定了严格的软件开发阶段和过程，忽略了软件开发本身的特殊性，过于理想化。例如，一个很突出的问题是关于系统的需求分析。瀑布模型假设对系统的功能需求可以预先严格精确定义，要求系统的需求分析在软件设计前完成，并给出明确的、所有的需求定义，这在实际上往往是做不到的。因为在系统开发之初，无论是领域专家、终端用户还是软件系统分析人员，无论他们如何努力地调查研究与分析，也不可能对未来系统的一切需求都定义得周到详尽、完整无缺。往往是在以后的设计阶段甚至编码阶段，才发现原来对系统的需求定义必须进行某些修改和补充，这样就会导致开发工作的返工，延误软件交付时间，增加资源和费用的投入，降低软件的质量。

2．快速原型模型

按照传统的生命周期模型先要进行繁琐冗长的系统分析，将系统的需求完全确定下来后再进行软件设计和编码测试，这正是造成系统开发困难的重要原因。一方面系统分析员不可能在系统分析的初期就将所有的用户需求考虑周全，另一方面用户的需求是会变化的，用户对未来系统的认识有一个逐步深化的过程，所以对系统的需求分析不可能在系统开发之前完全确定下来。为了解决这个问题，20世纪80年代随着计算机软件技术的发展，特别是在关系数据系统（RDBS）、第四代程序设计语言（4GLS）和各种系统开发生成环境产生的基础上，提出了一种从设计思想到工具、手段都不同于生命周期模型的系统开发模型——快速原型模型。

快速原型法开发模型的基本思想如下：

（1）首先取得基本的需求，迅速构造一个系统原型。

（2）运行原型系统，对原型进行评价，提出修改意见。

（3）根据新需求，再实现新一轮的系统原型。

（4）重复上述步骤，直到实现满意的最终系统。

快速原型模型与传统的生命周期模型不同的地方是在开发过程中引入了用户评价。系统开发人员首先根据系统的最基本的需求，快速构造出一个原型系统，然后在计算机上运行这个原型系统，系统开发人员与用户一道对这个原型进行评价。在快速原型法中用户成为程序开发的参与者，从而使用户提出的需求更加明确和具体，使系统的开发能够沿着正确的方向进行。快速原型法的工作流程如图3-2所示。

图3-2　快速原型模型

由于快速原型模型强调开发的速度，因此快速原型模型的使用一般需要借助计算机辅助软件工程（即CASE）工具，至少是集成式的程序开发环境，以便快速、低代价地进行。原型系统开发所使用的工具可以与最终系统的相同，也可以不同。

快速原型模型体现了快速、简化，抓住主要问题，尽早得到用户的认同的软件开发思想。通过一轮又一轮的原型开发和用户评价，“试用—反馈—修改”，逐步求精，迅速完成用户满意的最终系统。在每一轮的原型化开发循环中，一般仍采用生命周期模型的方法，即经历需求分析、软件设计、编码、测试等阶段。

快速原型模型的主要优点是，系统开发人员与用户交流直接，消除了开发人员与用户之间的通信障碍，可以尽早地获得正确而完整的需求；开发过程简单，在一定程度上能适应需求的变化，设计与编程更快速、更准确，开发效率也显著提高，而且提高了软件质量，总开发费用也会减少。

然而使用快速原型模型开发也存在一定的缺陷。如果用户不断地用新的需求否定旧的需求，则软件开发总停留在重构一个新原型的阶段。更可怕的是，如果一个经过多次修改已接近成功的系统模型突然被用户否定掉，中间修改的成果就将化为乌有。因为用户的需求常是不全面的和不明确的，在开发过程中不断引入用户变化的需求会造成开发过程的不确定性。程序总是在不断地修改，使得系统的规模难以控制，开发人员将迟迟拿不出一个完整的成品。

从以上讨论可知，生命周期瀑布模型和快速原型模型各有其优缺点。对会计信息系统而言，现在最为流行的开发模型的选择为生命周期瀑布模型和快速原型模型相结合的混合模型。也就是开发模型依然选择生命周期模型，但在某一阶段内使用快速原型模型，这样可以兼顾两者的优点而弥补其缺点。例如，在生命周期模型的系统分析阶段利用快速原型模型可以得到很好的系统逻辑模型。