软件工程的方法论
作者：陈苏闽
2000年10月
工作单位：江苏移动镇江分公司（邮编：212000）
论文摘要
计算机软件在人类社会中发挥着越来越重要的作用。但是软件技术的发展始终没有摆脱“软件危机”的阴影。本文着重从科学技术的方法论的角度讨论了软件工程的方法论特性：软件工程的思想方法和设计原则；软件工程作为技术技术方法所具有的实践性、社会性和复杂性及其对策；软件过程及其相关模型。
关键词
方法论 软件危机 软件工程 软件过程
正文
一、软件技术方法论的重要性
近年来，计算机科学在硬件研制，软件开发，网络通信等分支学科和应用领域中迅速发展，计算机的应用已经渗透到人类社会的各个行业、领域、甚至千家万户的生活之中。随着计算机技术的发展和计算机应用的普及，信息社会、网络时代离我们越来越近，计算机技术在人类社会中发挥着越来越重要的作用。美国未来学家尼葛洛庞帝在其《数字化生存》一书中曾经预言，“计算不再只和计算机有关，它决定我们的生存”[1]
由于以计算机为基础的系统在数量、复杂程度、应用方面的增长，对无处不在的计算机软件提出了更高的要求：更广，以解决层出不穷的应用问题；更精，以安全可靠地完成各项任务；更简便，以适应千家万户的使用普及。要达到这一目标，仅依靠的现有的思想方法是不够的。
当前，国际几大软件公司已经垄断了软件技术的重要领域。我国软件业要走自主创新之路，就必须掌握软件开发的核心技术，即软件开发的思路和方法，从而根据我国的发展需要开发有自主知识产权的创新软件。软件工程的研究是当前计算机科学的热点领域，新的理论与实践的成果不断涌现。利用这些知识，学习应用、加以创新，是中国软件产业赶超世界水平的机遇和途径。
在软件技术的发展道路中，方法论起着决定性的作用。正如毛泽东曾经说过的：“我们的任务是过河，但是没有桥或没有船就不能过。不解决桥和船的问题，过河就是一句空话。不解决方法问题，任务也只是瞎说一顿。”[2] 软件技术人员有必要站在哲学的高度、从方法论的角度，重新审视软件开发过程中各个环节，深刻体会软件工程和方法论的联系，从而改进和发展的现有的软件工程技术，消化吸收先进的思想、方法和技术，提高软件的质量和生产率，以适应现实世界对软件产业新的要求。本文着重从科学技术的方法论的角度，讨论了软件工程的问题、思想、方法和新技术。
二、“软件危机”和软件工程
虽然未来学家们向我们展示了信息时代的一幅美好的前景，但理想与现实之间毕竟存在着巨大的差距。计算机硬件技术遵循着“莫尔定律”加速地发展，然而软件技术的进步一直相对缓慢，差距的增大、问题的积累形成了日益尖锐的矛盾，这就导致了“软件危机”。
“软件危机”的问题归结起来有以下几个方面：
软件项目的规模和复杂性越来越大，由于缺乏系统有效的方法，现有的开发知识、经验和相关数据难以积累、复用，软件系统开发的重复过程浪费了大量的人力、物力、财力和时间。
软件开发工作缺乏有效的分析手段和设计方法，计划难以制定，经费预算常常超出，进度计划无法遵循，开发完工的期限一再拖延。
由于通常软件需求在开发的初期阶段不够明确、或是不能得到确切的表达，开发工作开始后，软件人员和用户又未能及时有效沟通，造成开发中后期需求与现实间的矛盾的集中暴露。
开发过程没有统一的、公认的方法和技术规范，设计和实现过程的资料很不完整，使得软件很难维护。
缺乏有效的评估标准，未能在测试阶段充分做好检测工作，提交的软件质量差，在运行中暴露出大量的问题。
“软件危机”最突出的例子就是美国IBM公司在1963年到1966年开发的IBM360的操作系统。这一项目花了大量的人力物力，得到的软件质量却是非常糟糕的。根据统计，它的每个新的版本都是从前一版本找出1000多个程序错误而修正的结果。 “正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难，……，程序设计工作正像这样一个泥潭，……，一批批程序员被迫在泥潭中拼命挣扎，……，谁也没有料到问题竟会陷入这样的困境……”[3] 历史的教训告诉我们，没有正确的方法，优秀的团队和先进的技术并不能保证项目的成功。
为了解决“软件危机”，许多计算机和软件科学家参照技术过程的一般模式提出了软件生存期概念（Life cycle）及其瀑布模型（Waterfall Model）。计算机软件的生存周期描述了软件孕育、诞生、成长、成熟、衰亡的生存过程：
制定计划：确定要开发软件系统的总目标，给出它的功能、性能、可靠性以及接口等方面的要求；研究完成该项软件任务的可行性，探讨解决问题的可能方案；制定完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。
需求分析：对待开发软件提出的需求进行分析并给出详细的定义。编写出软件需求说明书及初步的用户手册，提交管理机构评审。
软件设计：把已确定了的各项需求转换成一个相应的体系结构。进而对每个模块要完成的工作进行具体的描述。编写设计说明书，提交评审。
程序编制：把软件设计转换成计算机可以接受的程序代码。
软件测试：在设计测试用例的基础上检验软件的各个组成部分。
运行维护：已交付的软件投入正式使用，并在运行过程中进行适当的维护。
由于引入了软件工程的思想，把其它工程技术研究和开发领域中行之有效的知识和方法运用到软件开发工作中来，提出了按工程化的原则和方法组织软件开发工作的解决思路和具体方法。软件工程在一定程度上缓解了“软件危机” 。但美国软件学家F.Brooks在其论文中指出，人们至今尚未找到象神话中能够制服“狼人”（软件危机的本质问题）的银弹[4]，虽然问题得到缓解，但危机并没有消除。
三、软件工程的方法论
在近年的研究中，软件工程进一步发展出软件过程的概念，软件工程需要研究“如何做”的软件方法，也要研究支撑的软件工具和软件环境，软件过程则是研究如何综合软件方法和软件工具。为了更好地发展和改进软件工程技术，我们有必要从方法论的各个角度分析软件工程的方法、工具和过程，从而有的放矢地改进软件工程中各个过程的思想、方法、模式和规则。
1、软件工程的发展性
和其他技术方法一样，软件技术经历了由简单到复杂，由低级到高级，由以经验为基础到以科学为基础的历史过程。工程技术人员自觉或不自觉地实践着这一转化。回顾这段发展历史，能给予对软件技术的本质特性的把握一些有益的启示，有助于推动软件技术的发展和进步。
软件技术的发展阶段可以分为以下三个阶段：程序设计阶段，约为50至60年代；程序系统阶段，约为60至70年代；软件工程阶段，约为70年代以后。几十年来最根本的变化体现在观念转变中：程序从按个人意图创造的“艺术品”转变为能被广大用户接受的工程化产品；软件从满足自己的需要的自给自足的生产方式转变到要在市场中流通以满足广大用户的需要；软件工作的范围从只考虑程序的编写扩展到涉及整个软件生存周期。
随着软件技术，尤其是面向对象技术（OO）的发展，软件工程提出了以下新的思想方法和设计原则：
抽象：抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象，自顶向下、逐层细化的办法控制软件开发过程的复杂性。
信息隐蔽：将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问，使用与实现分离的原则。
模块化：通过对象、类等模块化手段实现信息隐蔽和抽象，有助于表示复杂的系统。
局部化：在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于控制解的复杂性。
确定性：软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。
一致性：整个软件系统（包括程序、文档和数据）的各个模块应使用一致的概念、符号和术语。
完备性：软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件过程中需要严格的技术评审。
可验证性：开发大型的软件系统需要对系统自顶向下、逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。
软件技术的实践经验告诉我们，分解是解决复杂问题的有效途径。软件问题的分解一般都体现出整体和部分的加性和方式 “一个复合体能够通过把原来分离的要素集合拢来的方法一步一步的建立起来；反之，复合体的特征能够完全分解为各个分离要素的特征”[5]。所以在遵循上述设计原则下的问题分解能达到较好的效果。
软件技术的发展历史还启示我们，没有一成不变的方法，没有绝对适用的开发模式，随着软件技术的研究和发展，必然存在着新的、更实用的分析模型、设计思想和开发技术。
2、软件工程的技术性
目前对软件这一名词公认的看法是：“软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发，维护和使用有关的图文材料。”[6] 。软件的定义包含了目前对软件技术外延的理解：所有的技术手段、途径和行为方式都是在程序、数据和文档的集合上的可操作的规则或模式。从方法论的角度分析软件问题，就必须考虑软件各要素作为技术方法所具有的特性。
实践性：软件工程的方法必须包含严格意义上的实践操作规则或模式，而不是限于理论和空谈。“符号是深入到现实背后的自然实在里去的方法的一个必不可少的部分”[7]。软件工程必须采用合适的符号体系，八十年代末以来，随着面向对象技术成为研究的热点，出现了几十种支持软件开发的面向对象方法。统一建模语言UML（Unified Modeling Language）结合了Booch, OMT 和Jacobson等方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术，成为对象管理集团（OMG）面向对象方法的标准。
社会性：软件工程的方法要关注社会因素，考虑机构、体制及管理方式等问题，甚至涉及到人的观念和人们的心理。针对这一领域，美国卡耐基-梅隆大学软件工程研究所（SEI）提出了软件机构的能力成熟度模型CMM，CMM共分五级：初始级、可重复级、以定义级、已管理级、优化级。CMM从人员、机构、体制及管理等众多角度为软件机构定义了可操作的分级实施和评估标准。
复杂性：软件本身是复杂的，软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。软件工程的方法要考虑到如何综合应用领域的知识，如何实现领域工程。
3、软件工程的系统性
由于现在使用的计算机的理论基础是图灵于1937年提出的图灵机模型和相应的冯-诺依曼体系结构。图灵机的想法是把问题转化为一步一步按规则执行的机械求解过程，各种计算机语言也不过都是这种思想下的某种形式语言。因此软件开发的过程实质上就是程序员们对客观世界问题域的形式化的过程。程序员们先建立问题的计算机语言表达，最后进行计算获得结果。由于对冯-诺依曼计算机的实现过程（顺序执行）和人们认识表达过程（不断反复，逐步深化）间存在巨大鸿沟，加上程序员把目光都集中在如何实现、如何编程上。认识的偏颇和思维的惯性导致导致对软件工程过程支持不足。例如，传统的瀑布模型以项目的阶段评审和文档控制为手段对整个开发过程进行指导，但缺乏灵活性，没有考虑到项目的评估和演进。
作为一种工程设计，必须对整个软件工程过程（Software Engineering Process）采用系统方法考虑其全过程。借鉴系统论“戴明循环法”的思路，软件工程过程包含四种基本的过程活动以及软件生存期模型：
P (Plan)：软件规格说明。规定软件的功能及其运行的限制；
D (Do)：软件开发。产生满足规格说明的软件；
C (Check)：软件确认。确认软件能够完成客户提出的要求；
A (Action)：软件演进。为满足客户的变更要求，软件必须在使用的过程中演进。
演化模型：考虑到项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难以一次成功，出现返工再开发在所难免。因此，可以先做试验开发，探索可行性，弄清软件需求；然后在此基础上获得较为满意的软件产品。通常把第一次得到的试验性产品称为“原型”。
螺旋模型：对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型沿着“戴明循环法”的循环螺线旋转，沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。
喷泉模型：喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。在开发活动，即分析、设计和编码之间不存在明显的边界。
智能模型：基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在一起。该模型应用基于规则的系统，采用归约和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。
演化模型，螺旋模型、喷泉模型、智能模型的进步之处在于都考虑了人们认识表达过程的反复特性，借鉴了系统论的系统方法，较好地支持了项目的评估和演进，并针对应用的特点组织了软件生存期的各个环节。
