摘要：ISO / IEC / IEEE 15288:2015 Systems and software engineering — System life cycle processes该标准建立了一个通用过程框架，用于描述采用系统工程方法构建的...
ISO / IEC / IEEE 15288:2015 Systems and software engineering — System life cycle processes
该标准建立了一个通用过程框架，用于描述采用系统工程方法构建的人造系统的生命周期。标准从工程的角度定义了一组相关的过程和术语。这些过程可以应用在系统层级结构的任何层级。所选择的这些过程可以应用于整个生命周期的管理和系统生命周期阶段的执行。这个标准通过让所有的利益相关者的参与，实现顾客满意的最终目标。
系统之系统（SoS）适用于其系统元素也是本身也是系统的所感兴趣之系统；这些系统之系统典型地带来大规模跨学科问题，涉及多重的、混合的和分布式的系统。这些部件系统的互操作集合通常产生单个系统无法单独达成的结果。
系统之系统的开发面临诸多挑战：1）系统元素独立运行；2）系统元素生命周期各有不同；3）初始需求不清楚；4）错误管理导致的复杂度过高；5）接口模糊不清；6）产品的快速、持续迭代。
在SoS环境中系统工程师的部分工作是意识到并减少这七个挑战中的每一个带来的风险。焦点应放在控制系统元素和外部系统之间的接口。当较老的部件系统被较新版本所替换时，确保接口的可持续运作是非常重要的。验证和确认（V&V）流程在这种转换中起着关键性作用。
今天，我们首先聊一聊第一个挑战：“独立”！
大型项目管理特别是诸如卫星工程、飞机等跨系统、跨单位、跨领域的多方协同工作模式，如果SoS开发过程中，系统与系统之间、系统与分系统之间、单位与单位之间、项目团队与其他团队之间过于独立运行，不能很有效地融合，势必会在项目研制过程中带来极大的风险，甚至可以定性为最大的风险。这个风险是既是一个技术风险，也是一个管理风险，将直接决定了接口界面的清晰程度，决定了项目计划的执行力度，决定了资源分配是否合理可行，也直接决定了项目目标的综合实现程度。因此，系统元素的独立运行是系统研制过程中的最大挑战，也是系统工程管理中的最大风险。
当然，我们并不是说各个系统元素要完全丧失其独立性，而是在接口清晰的情况下保持其相对独立性的融合发展团队模式。
系统元素独立运行挑战的三种形态比喻，原来如此简单：
1）战国纷争，群王争霸：从组织管理上，各组成系统的基层组织谁都不服谁，没有总体性作用来统领整个项目研发，导致系统开发各自为政，协调难度大，信息交流不畅通，产品兼容性bug比例高；
2）多握手，少冷战：系统间交互少、交互弱、接口匹配性差：系统组成间只有在充分的信息交互后，才能实现1+1》2的更优效果，才能为用户提供更加优质的产品和服务。但是信息交互的结果，势必带来信息流的增加，对系统间的接口要求非常高。这就要求各系统研制方，要形成经常性的交流机制，“多开会”、“开好会”、“会开好”！切不可高唱“独立歌”，项目过程中“老死不相往来”，仅在项目出生和交付时，兄弟俩才见上两面，产生的结果肯定是两个系统“对”不上，南辕北辙。
3）要一把尺子量到底：大系统工程开发过程不仅涉及到团队内部成员，更多地会拓展至组织内部的不同部门、合作供应商、国际合作伙伴等等。团队与团队之间的习惯有所不一样，企业与企业的质量控制基线肯定会有所区别，国家与国家之间的标准采用往往具有“国别”特色。在具体SoS开发过程中，各系统之间内部质量控制可以适当采用自己的常规标准规范，但是，在关键的生命周期模型、V&V等关键流程环节上，应经过早期的友好协商并确定符合大多数系统开发者的统一标准，采用一把尺子量到底，从系统工程角度实现管理的系统级溯源。
