4.4 系统生命周期模型的演化

4.4.1 系统生命周期模型的进一步发展

4.3节介绍的模型主要还是针对偏硬的工程技术系统，最初是从一些军事项目开始的，后来转移到民间的工程项目，这些模型发挥过很好的效用。随着系统工程应用领域的逐步扩大到更多涉及社会经济的领域，由于问题的高度复杂性、利益主体的多元化和人的认知的多样性，这些方法就显得有些局限性。尽管这种模型比起20世纪60、70年代的模型来已经考虑了一些人的因素，但还未能解决客观与主观的许多复杂性和不确定性问题。

这类以模型为典型的方法，尽管在处理含有大量不确定因素的系统时显得有局限性，但在系统工程发展的历史上，还是给后来的进一步发展提供了下列启示。

（1）表明科学知识至少还是能对管理者在处理操作性问题时有所帮助的。

（2）系统工程方法坚持整体论，使管理者能够得到全面综合的解决方案。

（3）运用系统方法比以管理人员的经验和即兴方法为基础来处理问题更为可取。

（4）如果目标明确，而且能按照绩效指标对不同方案进行评价和选择，这样一类偏于硬系统的思考方法还是有效的。

（5）面对复杂问题不可避免地要使用模型，模型也不局限于数学类型。如果对模型的假设非常清楚的话，它们对于管理者的学习过程是有帮助的。

后来，国外在几个模型和标准的基础上，又建立了一种“元模型”，这个模型对人的因素多了一些考虑。它把系统工程的整个过程分成四类过程：协议过程、项目过程、技术过程、评价过程。

在协议过程中，需要和用户建立一个构建新系统的协议，协议要建立在下列基础之上：可行性分析得出的结论是没有其他系统可用，需要构建新系统，而且成本效益分析结果表明是可行的。这个过程有下面三个活动。

（1）定义需求。通过与用户以及其他利益相关者的交谈，明确用户的需求。

（2）陈述问题。把为什么要进行这一项目用“问题定义”叙述清楚。

（3）项目分析。进行可行性研究，确定这个项目是否应该进行。如果应该进行就转到下一过程，即项目过程。

在项目过程中，先要制订项目规划，在项目进行中每一步都要从时间、成本、质量各方面进行检查。在这一过程中，要进行下面这些活动。

（1）项目规划。在项目开始时先制订规划，在进行过程中，规划还会不断更新修改。

（2）项目评价。在项目进行中不断检查项目的进行情况，看有没有什么需要变更的。

（3）项目控制。其中包括进度的估计，方案的评价、选择与决策。

这些过程有可能不是顺序进行，而是并行或者形成反馈闭环的。其中有关风险的控制是十分重要的。

技术过程包括开发、设计和实施，在这一过程中，需要进行下面这些工作。

（1）对任务和环境进行分析。分析用户的要求，进一步明确用户需求。

（2）确定系统的功能需求。从性质、数量、范围、时间、可用性等方面落实。

（3）定义系统的效能，并对约束的要求进行设计。

（4）系统建模。以需求为基础建立系统的功能体系结构。这种体系结构有助于发现瓶颈。模型可能是图形，也可能是文本。

（5）对备选方案进行研究。

（6）将各组成部分进行集成。

（7）进行项目实施。

在评价阶段，要检查所得的结果是不是原来所要求的，是不是满足了需求，因此需要进行下列工作。

（1）系统的验证（Verification）。在系统开发出来以后，经过评价，从评价提供的证据来看，是否满足原来任务文件提出的要求。

（2）系统的确认（Validation）。这是要看系统能否满足用户要求。

（3）系统的运行和维护，直到系统报废或再造成为新的系统。

这里有必要对系统的验证和确认的区别加以讨论。验证只是看是否满足原来任务文件提出的要求，而确认是要看是否真正满足用户特定的要求或预期的用途。前者满足了规定要求，而后者满足了使用要求。

上面说的各个过程是交叠进行的，过程内的各步骤也不会是一帆风顺按顺序完成的，总是需要按照反馈的实际情况，返回到前面的环节上去。不但每一个过程有可能引起返回，而且还可能返回到前面任何一个过程中去。

这里可以用参考文献中举的一个例子（本书对它做了必要的延伸和解释）来说明上述模型的应用：某公司的总裁希望将本公司的一些有用的经验及时传递给全公司的员工，想建立一个知识传播系统。总裁先向各有关方面征求意见，了解他们的需求，然后请某一信息系统公司来筹划和开发。双方达成协议后，作为开发方的信息系统公司经过调查，了解到用户方目前还没有能够完成这一要求的现成工具或系统，开发一个新的系统是必要且可行的，于是进一步对需求进行定义，由协议过程进入项目过程。

经过研究（项目过程中已经插入技术过程了），认为有三种方案可以满足需求：一是编写成书籍文件分发，二是制作光盘分发（二者都需要人工分发配送），三是把内容用网页形式在网络上传播。在技术方案与约束的比较分析上，由于编写书籍既费时费事，又浪费纸张（消耗森林资源，不合乎环保要求），还不利于检索，因而首先把这一方案淘汰了。在后两个方案的分析过程中，考虑到随时有新的知识需要补充，而光盘难以方便地做到更新，因此最后选定网页方案。这时可以利用公司现成的内联网，但需要周密考虑接口问题。接着就可以进行系统结构设计，在经过评审通过后，开始系统的建造。最后还需要对系统进行验证和确认，才能投入运行。

对于一些涉及不确定因素和人的因素较多的任务来说，困难多半发生在系统工程过程的一开始，也就是需求定义的阶段。第3章介绍的软系统方法论，其主要针对性也在这里。由于采取了对环境和需求逐步确定的方法，特别是建立根定义的方法，使得系统所涉及的人的活动和意见得以反映，需求也就可以明确了。

4.4.2 综合集成方法在系统工程过程中的应用

对于一些涉及社会、经济、环境的开放式巨系统，需要使用第3章介绍的综合集成方法论和综合集成研讨厅的方法来实现系统工程过程。它们的实质乃是把专家群体、统计数据与信息资料、计算机和信息网络技术结合起来，构成一个智能化程度很高的人机结合而以人为主的系统，来处理系统工程问题。

对开放式复杂巨系统问题，需要把各种分析方法与工具、模型、知识和经验加以综合集成，构造出适合于解决问题的环境，这个环境就是综合集成研讨厅。研讨过程就是人的知识与智慧与工具的不断交互作用的过程。

综合集成方法的具体实施过程大致有下列一些步骤：

（1）通过与任务委托者的沟通和有关信息的收集，明确系统的任务和目的。

（2）尽可能请有关专家对人物、目标、可行性等提出意见，这些意见显然是定性的，而且是各式各样的。同时还要收集大量的有关文献资料，并认真调查了解情况。

（3）在有了上述定性的意见和定性、定量的信息之后，可以构建一个初步的模型。在这个过程中，要注意不断和实际的信息相对照，使模型细化。

（4）在这个模型的基础上进行分析，将分析结果请专家进行评价和检验，这样反复进行，直到结果令专家满意为止。

在这个过程中，如何让群体成员发表意见，可以按照下面的步骤进行。

（1）召集专家进行讨论。首先请专家研究有关材料。会上先说明会议目的。对讨论不做任何限制，让专家畅所欲言，然后由会议主持者综合各方面的意见，无论是正面意见还是反面意见，都要加以综合。

（2）针对需要系统研究的问题（包括专家提出的问题）请专业咨询机构或有关专家进行专题研究，最好是采取多种多样的研究方法和途径。研究结果要形成报告。

（3）对研究报告和方案进行专家论证和评审，希望专家不要受部门、专业、当时形势的影响和束缚，从整体和长远利益出发，做出公正的评价。

（4）进行比较研究，与同样性质的项目进行对比，从而发现问题。

（5）横向征求意见，必要时还可以会商协调。

这些步骤只是指明了一个思路，具体各步骤还可以用后面几章讲的方法来实施。如果只是需要一个规划或者概念设计，上述步骤完成也就得到了结果。如果后面还要有具体的工程建设，就又可以用前面介绍的几种模型了。

从上面的讨论可以看出，无论是怎样的一个系统工程项目，一些重要的过程，例如需求的确定，可行性分析，系统的架构和功能设计、方案的设计、分析、比较和选择，系统的实施与评估等都是必不可少的，只是对一些需求明确、环境条件简单、有先例可循的任务，可以循着各类模型所提出的步骤依次实施。对一些具有高度不确定性和人的因素的系统，需求常常不是一下子就很清楚，各利益主体之间的冲突又难以协调，所以不能完全按照模型中的步骤依次进行，总要有一些难以预见到的反复。

我们可以从软件工程（其实软件工程就是软件系统工程）和信息化系统开发的方法中得到一些启示。软件或信息系统的开发一般包括四个阶段：需求定义（R）、系统设计（D）、系统实施（I）、系统运行维护（M），这和我们前面介绍的步骤是一致的。最早的开发方式是循着R、D、I、M顺序进行的，从一个转到下一个，在软件工程和信息系统开发中称之为瀑布模型。这种模型如果用参考文献中对过程的表述方法，就是像图4-2中的（a）那样，图中的横轴表示的是时间的推移。

后来发现有时候前一阶段还没有完全结束，就有条件进行下一阶段的工作了，也就是有可能并行工作一段，这时就出现了所谓生鱼片（Sashimi）模型，如图4-2（b）所示。

后来发现在一开始的需求阶段，用户还说不完全或者说不清楚真正的需求，而且对于软件或信息系统究竟能够干什么、不能干什么也还不清楚。为了解决这一问题，就出现了所谓“快速原型法”，也就是在收集了用户需求和初步确定目标之后，先快速设计一个满足用户要求的系统原型，与用户反复讨论。一方面，用户可以在对系统有一个轮廓性的了解之后提出比较明确的要求，而开发者也容易阐述自己的看法。原型系统设计可以不停留在纸面上，对软件和信息系统来说，可以开发一个演示或初步（局部）可运行的系统。而对一些战略研究、规划任务来说，可以尽量用一些可视化的手段（图标、视频乃至于虚拟现实）或仿真来展示。这样不断地谈论和改进，就会形成完善的系统方案。然后转入下面的步骤。用图4-2（c）的表示方法，可以看出一开始就有设计（D）、实施（I）、运行维护（M）的介入，然后逐步扩展。

从软件工程中还可以移植螺旋模型，这种模型是把瀑布模型和快速原型法结合起来，再把风险分析考虑在内，形成一种渐进式的方法。它是把制订计划、风险分析、工程实施、客户评估四个部分组成一个迭代模型，沿着螺旋线依次旋转进行。每一个循环都要进行风险分析，如果需求明确，风险较小，一个循环就可以完成，这对应于瀑布模型。一般来说，总是要经过几个循环的。风险分析首先要对风险进行识别，然后研究如何减少和规避风险。

对于复杂的系统来说，由于不确定因素较多，上面的几种方法都很难简单地直接应用，因为在需求、设计、实施、运行各阶段之间的反复不但很多，而且随时会发生，难以预见。所以系统的生命周期是参考文献所提到的一种“混沌生命周期”，如图4-2（d）所示。从图中可以看出，随着时间的推移，随时都有返回前面阶段的可能。这意味着复杂系统工程的过程总是有反复的，而反复出现带有许多偶然因素。