系统的系统与风险管理
黄锡滋 陈光宇
由于科学技术飞速发展和社会需求的拉动，“系统的系统”（System of systems，SOS）已经在和军事，信息技术，经济等诸多领域崭露头角。“系统的系统”远比传统的系统更加复杂，怎样才能对“系统的系统”开发实施有效的风险管理，装备管理部门面临更加严峻的挑战。
一、 系统的系统定义
研究“系统的系统”风险管理，必须充分认识“系统的系统”的特征。
1. 美国软件工程研究所(SEI)的定义：“系统的系统”是“由许多独立的，自成体系的系统构成的一个整体系统，用来满足特殊的功能需求” 。
2. Wiped百科全书的定义：“系统的系统”是“一个由各种功能不同的系统或专用系统，构成的新系统，它综合了各个系统的功能，综合应用各个系统的资源，可以获得比单个系统简单总合所能提供的更高的功能，和更好的性能” 。
3. “系统的系统”实例：美军正在积极建设的未来战斗系统（Future Combat System，FCS）就是一个“系统的系统”的 实例。美国政府的一个官方文件，对FCS 的结构有如下几段具体描述。“军队领导决定在FCS的设计中，包含与其他系统的互操作性，将未来战斗系统中的单个系统，设计成为网络化‘系统的系统’中的一个独立工作单元”；“14个武器系统或平台需要同时设计和集成，单独的系统必须在严格的尺寸，重量，时间约束下按照典型的开发过程开发，认证和现场部署。至少有53个没有达到关键能力和性能的关键技术，需要进一步成熟并集成到未来战斗系统中。此外还有157个辅助系统需要按未来战斗系统的要求和进度，同步开发，认证和生产。”
以后，本文在涉及的“系统的系统”内部结构时，为了叙述的方便，将“系统的系统”的顶层，称为SOS层，“系统的系统”中独立的系统称为系统（或项目），独立系统的子系统称为子系统（或子项目）。
二、 风险管理过程
“系统的系统”的风险管理，更加需要遵循系统风险管理的普遍规则和过程。图1是系统风险管理过程图。详细内容，请参阅我们在2008年撰写的另外一篇文章“软件密集系统风险管理”（见国外质量与可靠性信息网，网址 ）。本文将重点放在“系统的系统”的风险管理所涉及的特殊问题。
图1 系统风险管理过程图
三、“系统的系统”风险管理的特殊挑战和对策
（一） 众多的利益相关方
1. 挑战
1） SOS的利益相关方包括主订货方，若干项目主承包商，以及下属更多层次的子承包商，构成复杂交错的承包商链。美国政府主订货方一般是DOD和NASA，项目承包商链中的利益相关方，可能同时具有买方和卖方双重身份。众多利益相关方在怎样对待项目风险方面，他们的认识、态度和习惯的处理方法存在明显差别，包含着潜在的风险。
2） 不同的利益相关方在对待项目的费用（Cost)、性能（Performance）、进度（Schedule）方面（简称CPS），基于自身利益，具有不同期望值。互相之间可能存在竞争关系，难于协调一致。
2. 对策
1） 在SOS层面和项目层面，必须设立一个稳定的机构，集中管理和实施综合风险分析。
2） 在SOS层面、项目层面和重要的子项目层面，首先需要对费用、性能、进度三个方面，分别进行系统的、全面的调查分析，然后将三方面结果进行综合权衡和优化。边际效应分析是常用的一种有价值的分析方法。
3） 促进SOS开发中存在伙伴关系的相关方，充分了解彼此在CPS期望值方面的差异，及早协调，制订对应的解决方案。
（二）不一致的风险管理过程
1. 挑战
1） 各个项目受传统习惯和技术水平的影响，往往采用个别的无序的互不兼容的风险识别方法，结果使得有的风险被遗漏，有的风险被夸大。
2） 由于各个机构采用不同的风险分析方法，对于同样的风险，可能得出差别明显的风险级别。
3） 不重视风险处理战略。风险处理战略往往仅针对特殊风险制订，没有全面考虑存在的其他风险。
2. 对策
1） 采用公认的风险识别方法，至少下列三种主流风险识别方法必须全面采用，它们是：工作分类结构法（Work Breakdown Structure，WBS），需求流向法（Requirement Flow Down，RFD）,关键过程评价法（Key Process Evaluation， KPE）。
2） SOS开发的主要负责机构，应该为其它有关机构提供确定风险级别的通用准则。
3） 风险处理战略必须包括全部识别的风险。为各种风险提供各种可能的选择，包括风险规避，风险控制，风险转移。制订执行各种选择的最适当方法。
（三）长寿命周期的影响
1. 挑战
1） SOS的寿命期可从几年到数十年，SOS中各个项目在整个寿命期中的成熟度，从开发早期到稳定运行期不断变化。项目成熟度水平参差不齐，导致SOS层的风险管理复杂化。
2） 在SOS寿命期中，不断地有新系统补充，这时已经部署的旧系统势必对新系统构成某些约束，新系统采用的新技术和新编程方法，同时也影响到原有各个系统的运行。
2. 对策
1） 险管理计划应该是可剪裁的，用来适应各个系统寿命周期的不同阶段。
2） 风险管理计划必须是动态的，随着SOS各个层次结构和性能变化，不断地进行调整和进化。
（四）公共技术风险
1. 挑战
公共技术风险通常包括设计风险，功能风险，性能风险，集成风险，资源可获得性风险和新技术采用风险。在风险管理计划中，通常包括了对一部分技术风险的管理和处理，但是没有专门作为一个特殊类别加以评估和分析。
2. 对策
将公共技术风险，作为专门类别加以管理，有助于SOS高级决策层清楚认识风险管理过程、员工能力、技术水平和资源获取的优势和缺点。公共技术风险难于用概率的方法加以评价， SOS的主要责任方，应该制定统一的评价方法。
（五）集成风险
1. 挑战
集成风险包括硬件/硬件集成，硬件/软件集成，软件/软件集成三种类型的风险。集成风险广泛的存在于SOS的各个项目，SOS和各个项目的各个层次。在SOS层面还存在网络集成问题。
对于集成风险，普遍存在不够重视和不能及时发现的问题。由于集成风险出现，经常造成项目费用超支、进度延误。
2. 对策
解决的办法是提高对集成风险重视程度，采用螺旋开发模型和早期原型样机和认识性测试的方法，及早识别可能的集成风险。
（六）功能履行风险
1. 挑战
功能履行风险是指是否具有足够的能力论证需求及功能是否能达到规定的水平。这种类型的风险过去很少列入风险预计的范围。如果需求和功能存在缺陷，再加上识别论证能力不能不断地改进，将导致需求功能的缺陷在开发的后期才能暴露。
功能履行风险等级，无法用发生概率表示 只能定性的采用诸如“很不成熟”到“很成熟”等不同的等级表示。识别功能履行风险的方法包括初始建模、模拟、模仿、原型样机和测试，
2. 对策
在开发期和集成期进行功能履行风险分析，使这种风险降低到可以接受的水平。
（七）界面复杂性
普遍的看法是界面复杂性越高，风险越大，但是实际上很难将界面复杂性与风险发生概率和后果准确的加以联系。
建议将界面复杂性风险和设计，集成，保障风险结合进行分析。
