信息系统依据其规模、 技术复杂程度、 外部环境和需要解决问题的不同而有所不同。 在信息系统建设的长期实践中，针对这些不同的系统和不同的开发背景发展了不同的系统开发方法。 应当特别指出的是，没有任何一种方法能适用于所有类型的系统，相反，有些类型的系统至今仍缺少有效的开发方法。
1. 传统的结构化方法
早期的编程并没有什么方法可言，用户的要求是通过交谈和询问收集的，事后根据谈话写成的文字也很难理出头绪。 程序代码复杂而难以理解，逻辑流程像面条一样互相缠绕在一起。 这样的程序被称作 “意大利面条” 式的程序，它们几乎无法维护。
为了解决这些问题，到20世纪70年代，产生了 “自顶向下” 和 “结构化” 的方法。所谓自顶向下，是指从抽象的高层向具体的低层逐层展开 所谓结构化，是指把复杂的事务和活动分解成一系列小的步骤，每一步都建立在上一步的基础上。 将这两种思想广泛地用于系统开发的各主要阶段，形成了结构化分析、 结构化设计和结构化编程等一系列能改善开发人员之间的沟通、 提高程序的可读性的开发方法与工具。 尽管这些方法与工具都是面向过程而不是面向数据的，它们却一直被使用了30多年。 现在所使用的大部分软件仍然是用这种传统的自顶向下的结构化方法开发出来的。
(1) 结构化分析
1) 业务流程分析
业务流程分析可以帮助分析人员了解业务的具体处理过程，发现和处理系统调查工作中的错误和疏漏，修改和删除原系统的不合理部分，对原系统的业务流程进行优化。 常用的分析工具是业务流程图 (Transaction Flow Diagram，TFD)。 TFD是一种描述系统内各单位、 人员之间业务关系、 作业顺序和管理信息流向的工具，利用它不仅可以描述 “数据” 的流程同时也可以描述 “物流” 和人的活动，比较容易为用户所理解，所以，在系统分析中常作为同用户交流的工具。
业务流程图基本符号尚无统一的标准常用的符号如图6－5所示。
图6－5 业务流程图常用符号
订单处理业务流程如图6－6所示。 顾客将订货单交给业务员检验后，不合格的订单要由顾客重新填写 合格的订单交给发货员确定发货量并产生发货单。 发货单交给仓库管理员，该仓库管理员查阅库存明细账，如果有货，则出库给发货员，发货员根据订货单发货给顾客 如果缺货，则用缺货通知单通知采购部门采购。
图6－6 订单处理业务流程图
2) 数据流程分析
面向数据流的分析方法是结构化分析方法中最为流行的一种方法，具有明显的结构化特征。 结构化分析广泛地用于自顶向下定义系统的输入、 处理过程和输出。 它用一种图示的方法建立起信息流动的逻辑模型，这种工具即数据流程图 (Data Flow Diagram，DFD)。
数据流程图是一种能全面地描述信息系统逻辑模型的主要工具，它可以用少数几种符号综合地反映出信息在系统中的流动、 处理和存储情况，是系统分析结果的表达工具。 它是系统设计的重要参考资料，也是系统设计的起点。
数据流程图用四种符号来描述数据流入、 流出和在系统内被转换的过程。 常用数据流程图的基本符号如图6－7所示。
图6－7 数据流程图的基本符号
(a) 数据流 (b) 数据存储 (c) 处理过程 (d) 外部实体
①数据流。 数据流用带箭头的线条表示数据在处理过程、 数据存储和外部实体之间的流动。 数据流代表着一种手工和计算机产生的文件、 报告或其中的部分数据，有一个与所代表的内容相适应的名字注在箭头的旁边。 在数据流程图中，数据流符号用于连接其他三种基本符号。 在连接时应当注意，数据流不能从外部实体直接连接到外部实体，不能从数据存储直接连接到数据存储，也不能从数据存储直接连接到外部实体，其中至少有一个端点必须与加工符号连接。 本质上，数据流代表一个或多个数据项。
②数据存储。 数据存储表示系统内需存储保留的数据。 它既可以表示计算机形成的数据存储，如计算机文件、 数据库，又可以表示手工形成的数据存储，如装订好的纸质账册以及报告、 缩微胶片等。 当然，数据流程图并不关心数据存储的物理特征，而只关心逻辑模型、逻辑意义上的数据存储环节，即系统信息处理功能需要的、 不考虑存储物理介质和技术手段的数据存储环节。 每个数据存储都应当有编号和名称，写在数据存储符号中。
使用数据存储时需注意: 数据存储不能直接和数据存储相连，也不能直接和外部实体相连，数据存储只能通过数据流符号和处理过程连接起来，表示存储处理过程的结果或向处理过程提供数据。
③处理过程。 处理过程用以描述对输入数据进行加工处理的逻辑功能。 每个处理过程都应该有一个由动宾词组 (例如 “打印成绩单”、 “计算工资” 等) 或动名词 (例如 “退货管理”、 “出库管理” 等) 构成的名字和一个能够与其他处理过程相互区分的编号。
处理过程接收输入数据，进行处理后产生输出结果。 一个处理过程可以有一个或多个输入的数据流、 一个或多个输出的数据流，不能只有输入数据流而没有输出数据流，也不能只有输出数据流而没有输入数据流。
④外部实体。 外部实体是系统输入数据的提供者或系统输出信息的接收者。 它可能是组织外部的顾客、 供货方、 政府机构，也可能是组织内部的雇员或组织的其他部门，还可能是一个与本系统有数据传递关系的其他系统。
图6－8给出了某企业订货管理系统的数据流程图。 该DFD中有两个外部实体，即库房管理人员及供货单位。 库房管理人员要向系统提供缺货信息，处理过程P1将根据缺货信息和订货合同信息向供货单位发催货通知。P2、P3、P4处理如图6－8所示。
数据流程图中每一个过程都可以分解成更详细的下一层的DFD，这样逐层分解下去直到最详细的底层为止。 系统分析人员可以借助数据流程图，减少与用户沟通时的困难与误解，还有助于进行子系统的划分。
图6－8 订货管理系统的数据流程图
3) 数据字典和处理过程说明
结构化系统分析还要用到的工具是数据字典和处理过程说明。
数据字典定义了数据流程图中的数据流和数据存储的内容，使系统开发者能准确地知道每个数据流和数据存储中具体包含了哪些数据。 数据字典同时也提供了每一个数据项的含义与格式。
处理过程说明描述最底层的数据流程图的每个处理过程中的处理逻辑，描述了如何将输入的数据流加工成输出的数据流，通常描述处理过程的工具有决策树、 决策表及结构表示法。
结构化系统分析的结果将提交一套结构化的说明书，其中包括描述系统功能的数据流程图，描述数据流和数据存储的数据字典，描述处理过程的说明书，输入/输出文档以及安全、控制、 运行和转换方面的其他要求。
(2) 结构化设计
结构化设计是一种自上而下逐层展开的设计方法。 它包括一整套规则和技巧，通过增加程序的清晰度和简明性来达到减少编程、 调试和维护工作量的目的。 设计时首先考虑主要的功能，然后将主要功能分解成下层的子功能，再对子功能进行分解直至最底层。 结构化的系统分析的结果是结构化说明书。
结构化设计的结果可以用结构图来表示。 结构图是一个自顶向下的图，表示出每一层次的设计如图6－9所示。
图6－9 库存管理系统结构图
(3) 结构化编程
结构化编程是结构化设计方法在编程中的延伸，同结构化设计一样，也遵循模块化和自顶向下的原则。 结构化编程还通过让控制尽量简明的方式来组织和编写程序，减少甚至消除程序中向前和向后的跳转，达到使程序更加容易理解和更加容易修改的目的。
结构化设计产生的结构图中，每个方框代表了一个复合程序模块，它可以分解成多个模块，每个模块只完成一个或很少几个功能。 最好每个模块都能相互独立。 互相连接时，尽量使每个模块只有一个入口和出口。 共享数据的模块也应该尽量减少。
模块之间不应该有隐含的关联，那样会引起 “波纹效应”，即一个模块的修改会影响到其他模块，产生意外的结果。 减少和消除这些有害的隐含关联，也就减少了错误扩散的途径。
每个模块的大小应该便于管理，以一个人能方便地读懂它的功能为原则。 模块内的指令流也应该保持自上而下的顺序，避免任意转移。 许多 “结构化语言” 就取消了GOTO之类的无条件转移语句。
(4) 结构化方法的优点及缺点
结构化方法的优点主要表现在以下几个方面:
①阶段的顺序性和依赖性
②从抽象到具体，逐步求精
③逻辑设计与物理设计分开
④质量保证措施完备
⑤适合大型信息系统的开发。
尽管结构化方法已经产生30多年了，但只有很少的组织使用过这种方法。 一项调查发现，在被调查的组织中，只有15％~20％的组织自始至终坚持结构化的分析与设计方法。 综合来看，结构化方法主要存在以下缺点:
①预先定义需求困难
②未能很好地解决系统分析到系统设计之间的过渡
③该方法文档的编写工作量极大
④开发周期长，系统难以适应环境的变化
⑤开发成本较大。
结构化方法是一种线性化的方法。 分析、 设计与编程的每一阶段都要在上一阶段完成之后才能开始。
2. 原型法
原型法是针对生命周期法的主要缺点而发展出来的一种快速、 廉价的开发方法。 它不要求用户提出完整的需求后再进行设计和编程，而是先按用户最基本的需求，迅速而廉价地开发出一个实验型的小型系统，称作 “原型”。 然后将原型交给用户使用，通过用户的使用启发出用户的进一步需求，并根据用户的意见对原型进行修改，用户再对改进后的系统提出新的需求。 这样反复不断修改，直至完成一个满足用户需求的系统。 与生命周期法相比，原型法的用户需求是动态的，系统分析、 设计与实现都是随着对一个工作模型的不断修改而同时完成的，相互之间并无明确的界限，也没有明确的人员分工。 系统开发计划就是一个反复修改的过程。
(1) 原型法的开发步骤
原型法的开发流程如图6－10所示具体可以归纳为四个步骤。
图6－10 原型法的开发流程
①初步确定用户最基本的需求
②据此快速开发一个原型系统
③将原型交付用户使用，启发用户提出新的要求
④按新的要求改进原型，然后再交付给用户试用。
反复更迭第③、 ④两个步骤，直到满足用户的所有要求。
(2) 原型法的适用场合与局限性
原型法适合于需求不确定和解决方案不明确的系统的开发 (如决策支持系统)，完整的用户需求和解决方案可以通过原型与用户反复交互来导出。 原型法还适用于开发信息系统中的最终用户界面 (用户接口)。 当用户事先说不清系统界面的具体要求，或者虽然说明了要求，开发者却把握不准时，使用原型法特别有效。 用户和开发人员喜欢用原型法的原因主要如下:
①其加强了开发人员和用户之间的沟通
②开发人员可以更好地确定用户需求
③用户在系统开发中扮演了更为积极的角色
④减少了开发人员和用户在系统开发上花费的时间和精力
⑤实施更为容易，因为用户知道会发生什么。
这些优点使原型法得以缩短开发周期，削减开发费用，提高用户的满意度，尤其是提高最终用户的满意度。
尽管原型法有上述优点，但它仍然不能代替结构化设计的方法，不能代替严谨的正规文档，也不能取代传统的生命周期法和相应的开发工具。 第四代开发工具虽然能使原型的生成与修改变得更为快捷，但是仍然克服不了原型法的一些重大的局限性。
首先，原型法不适于开发大的系统。 除非做了彻底的需求分析，否则，人们至今尚不知道应该如何生成大系统的原型。 如果能把大系统分解成一系列的小系统，就可以用原型法对每个小系统进行有效的开发，但是这种分解工作是十分困难的，一般也需要先做彻底的需求分析。
其次，开发原型法时，测试和文档工作常常容易被忽略。 开发者总是倾向于把测试工作简单地推给用户，这使测试工作进行得不彻底，将给系统留下隐患。 开发者也容易忽略正式文档的编写，他们认为编写文档太费事，系统又太容易改变，即使做了文档，也会很快地失效。 由于缺乏有效的完整的文档，系统运行后很难进行正常的维护。
最后，原型法的另一个缺点是运行的效率可能会比较低。 最原始的原型结构不一定是合理的，以此为模板多次改进后的最终系统会保留这种结构的不合理性。 用户一般都意识不到重新进行编码的必要性，而满足于系统已经具有了所需要的功能。 当系统运行于大数据量或者是在多用户环境中的时候，运行的效率往往会降低。 这种结构不合理的系统通常也是难以维护的。 正确的方法是将其重新编写，但这要付出额外的代价。
3. 快速应用开发方法
快速应用开发 (Rapid Application Development，RAD) 与原型法有同样的目标，即对用户需求做出快速反应，但它范围更广泛。 RAD被用来描述在非常短的时间内创造可运行系统的过程，包括使用可视化编程及其他工具来建立图形化用户接口、 主要系统组件的重复原型、 自动化生成程序代码及使用者与信息系统专家间的密切合作。 简单的系统一般由事先建造的组件组合而成，流程不需要顺序处理且开发的关键部分可以同时发生。 RAD的基本逻辑就是用户的参与程度越高，尤其是在早期阶段，系统开发就越快。 由于该方法强调用户参与，以及开发速度上的特点，使得它极其具有吸引力。
在RAD中，除了要明确用户需求外，还需要有CASE工具、 原型技术、 一支能突击完成任务的队伍，以及一套能快速实现用户要求的形式化软件开发技术。 RAD使用更简练的形式方法学，并通过重用软件构件更快地得到应用系统。
(1) RAD的要素
RAD有4个要素，即管理、 人员、 方法和工具。
①管理: 管理者，尤其是高层管理者，更喜欢采用新的方式做事的试验者，或者是能很快知道如何使用新方法的早期采用者。
②人员: 比起由单个小组开展所有的系统开发的生命周期活动，RAD认识到由几个专门小组完成工作会更为有效。 这些小组的成员精通完成指定任务所需的方法及工具。 因此RAD比传统生命周期要快。
③方法: 基本的RAD方法是RAD生命周期。 RAD生命周期包括需求计划、 用户设计、构建及完成四个阶段，并且除了构建阶段，用户都起了主要作用。
④工具: RAD工具主要包括第四代编程语言、 配合原型开发和代码生成的CASE工具。
由此可以看出。 RAD的主要贡献在于通过基于计算机的工具和专门项目小组，加快系统投入使用的速度。
(2) RAD成功的关键因素
RAD成功的关键因素包括以下几个方面:
①制订明确且大胆的目标。
②对每一个 “步骤/重复周期” 设置时间表和期限。 在RAD项目中，大多数过程是“有时间限制的”，应为项目完成和其中的活动步骤设置时间期限。 在这个时间期限内，任何不能交付的特征或功能都应该被删除或推迟到将来的发布中。
③RAD支持工具。 RAD工具应该为开发人员提供使用基于构件的架构来加快开发过程，支持RAD的需求获取，能使开发人员方便地在原型中添加和删除功能，相关的活动要在无须大量重新编写代码的情况下完成。 此外，RAD工具还应该支持使用第三方构件来实现用户需求。
实施RAD方法应保证多个开发人员能在同一个应用程序平台上工作，并且这些开发人员能够在他们的团队中扮演很多角色。 例如，一个开发人员为正在讨论的应用程序创建了构架，并设计了用户界面和后台代码，而同一个资源可能还在被用于开发测试计划，用于测试应用程序，书写文档，并最终培训用户。
④管理层的支持和有力的开发团队。 管理层的支持是RAD成功的保障。 另一个关键环节是在RAD流程中使用 “混合” 小组，每个小组由5~6人组成，包括系统开发人员、 用户及其他有决定权的人。
4. 面向对象方法
结构化方法是面向过程的方法，它的侧重点在于数据转换过程，而不是数据本身。 人们逐步认识到，数据的处理过程是不稳定的、 变化的，而数据本身却相对地比较稳定，也更有价值。 一个部门产生的数据可以供给许多部门共享，只是它们各自对数据的处理方式不同而已。 例如，产品质量数据可以被生产部门、 研究部门、 销售人员、 高层管理人员，甚至顾客们分别用各自的方式加以利用，就连产生数据的部门自身，也要不断地用各种经常变化的方式使用这些数据。 当业务过程发生变化时，改变的往往是对这些数据的处理方法，而不是这些数据本身。 显然，采用面向数据的开发方法，可以使系统更加精简，更加灵活，更加易于修改，更能够对企业的经常变化做出快速反应。
面向对象系统开发方法(Object－Oriented Method，OO方法) 是从20世纪80年代末各种面向对象的程序设计方法 (如Smalltalk、 C＋＋等) 逐步发展而来的，随着应用系统日趋复杂、 庞大，面向对象方法以其直观、 方便的优点获得广泛应用。
(1) 面向对象方法的基本思想
面向对象方法认为，客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态和运动规律，不同的对象之间的相互作用和联系就构成了各种不同的系统。
当设计和实现一个客观系统时，如能在满足需求的条件下，把系统设计成由一些不可变的 (相对固定) 部分组成的最小集合，这个设计就是最好的。 因为它把握了事物的本质因而不会被周围环境 (物理环境和管理模式) 的变化及用户无休止的需求变化所左右。 而这些不可变的部分就是所谓的对象。 面向对象方法具有以下四个要点。
①客观世界是由各种对象组成的，任何事物都是对象，复杂的对象可以由比较简单的对象以某种方式组合而成。
②对象是由属性和方法封装在一起构成的统一体，属性反映了对象的信息特征，如特点、 值、 状态等，而方法则是用来定义改变属性状态的各种操作。
③所有对象都可划分成各种类，按照子类与父类的关系，可把若干个对象类组成一个层次结构的系统，通常下层的子类完全具有上层父类的特性，这种现象称为继承。
④对象彼此之间仅能通过传递消息互相联系，而传递的方式是通过消息模式和方法所定义的操作过程来完成的。
(2) 面向对象方法的开发过程
面向对象的系统开发可分为三个阶段: 面向对象分析 (OOA)、 面向对象设计 (OOD)及面向对象系统实现 (OOP)。
①面向对象分析。 这一阶段主要采用面向对象技术进行需求分析，对问题领域进行分析，明确问题是什么，以及为了解决问题需要做些什么，即在繁杂的问题域中抽象地识别出对象以及其行为、 结构、 属性、 方法等。
②面向对象设计。 这一阶段要解决的问题是把分析阶段确定出来的对象和类配置起来以实现系统功能，并建立系统体系结构，即对分析的结果做进一步的抽象、 归类、 整理，并最终以规范的形式将它们确定下来。
③面向对象系统实现，即采用面向对象的程序设计语言将上一步整理的范式直接映射(即直接用程序语言来取代) 为应用程序软件。 具体操作包括: 选择程序设计语言编程、 调试、 试运行等。 前面两阶段得到的对象及其关系最终都必须由程序语言、 数据库等技术实现，但由于在设计阶段对此有所侧重考虑，故系统实现不会受具体语言的制约，因而本阶段占整个开发周期的比重较小。
(3) 面向对象方法的特点
面向对象开发方法具有以下几个特点:
①系统开发人员通过面向对象的分析、 设计及编程，将现实世界的空间模型平滑而自然地过渡到面向对象的系统模型，使系统开发过程与人们认识客观世界的过程保持最大限度的一致。
②利用面向对象开发方法得到的信息系统软件质量高、 系统适应性强，在内外环境变化的过程中，系统易于保持较长的生命周期。
③在开发过程中，分析与设计更加紧密难分，程序设计比重越来越小，系统测试简化可维护性好，易改进，易扩充，开发模型越加注重对象之间交互能力的描述。
(4) 运用面向对象技术的障碍
虽然面向对象技术及编程的需求越来越大，但面向对象的软件开发技术仍处于不成熟阶段，要让大多数公司采用，还需要做大量的验证。 尽管人们曾提出过几种面向对象方法，但目前还没有公认的标准。 许多公司在试用这种方法时犹豫不决，还因为这需要人员的广泛培训并抛弃原有的传统方法。
5. CASE工具法
计算机辅助软件工程 (Computer Aided Software Engineering，CASE)，有时也被称为计算机辅助系统工程，是一种自动化或半自动化的系统开发环境，目的是减少重复工作量。 通过将许多常规化的开发工作自动化和强化设计，可使开发者解脱出来，将精力集中到更需要创造力的工作中。 CASE工具能够方便地产生清晰的技术文档，并使团体的工作更加协调一致。 程序员通过相互审阅和修改已经完成的工作文件，使合作变得更加容易。 CASE工具及其开发出的系统已被证明更为可靠，所需的维护也更少。 多数CASE工具都是以微机为基础，并有很强的图形能力。
CASE工具提供了自动绘图功能，用以产生图表、 流程图，并支持屏幕及报表生成器、数据字典、 高效报表工具、 分析校验工具及代码和文档生成器。 多数CASE工具是以一种或多种流行的结构化设计方法为基础的。 一些CASE工具已经开始支持面向对象的开发，并且具有了支持建立客户机/服务器模式应用的能力。 CASE工具一般是通过以下几种途径来提高生产率和质量的:
①支持一种标准的开发方法和设计原则，使设计和整个开发过程更具有整体性
②改进用户和技术专家之间的交流，以使大型开发团体和软件工程能更有效地协调
③通过设计库将系统设计的各个部分联系在一起，对其进行快速处理
④自动消除分析与设计中的冗余及错误。
为了更有成效，与传统的手工开发方式相比，使用CASE工具时，开发组应更加强调组织纪律，而不能单凭个人方式行事。 工程项目的每一位成员都应遵循一套统一的通用命名规则、 标准以及开发方法。 缺少这一原则，分析员与设计者在开发过程中就会固执于原有的系统开发方法，并将旧方法与CASE工具混在一起。 这样做事实上只会降低开发效率，因为老方法与新工具之间是不兼容的。 好的CASE工具都强调通用方法及标准的作用，因此，如果缺乏开发的组织纪律，只会阻碍这些工具发挥作用。
尽管CASE工具在系统开发的一些方面提供了便利，它能够加快分析和设计的速度，利于重新设计，但它并不能做到系统设计的自动化，并且无法使业务上的需要自然而然地得到满足。 系统设计者仍需了解一个公司业务上的需要以及业务是如何运作的。 系统分析和设计工作仍然要依靠分析与设计者的分析技能。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
