系统工程
系统工程师简介和系统工程师能力发展框架 (2012-03-10 20:24:47) ▼
标签： 系统工程 cmmi 项目管理 架构
分类： 工程
系统工程是一门非常前沿专业，在美国系统工程师是最热门的职业，在中国虽然很多人放在嘴上，但实际上很少有人这是个什么职业？有人甚至说这是个当总统的专业，简直是在侮辱系统工程师。系统工程最初起源于航天、航空、军事部门，由于卫星、飞船、飞机、导弹这些产品的研发需要很多专业的综合，所以诞生了系统工程；后来该专业也扩展到民用部门，包括民用航空、铁路系统、通信系统、医疗设备等，甚至是一个小小的照相机也涉及系统工程。中国最初提出系统工程就我所知大概是钱学森了，但是从他的系统工程概念还不算太成熟，主要偏重于管理，而实际上系统工程跨越了技术和技术管理，它与项目管理有所交叉，也有很大的区分。
以下是一个系统工程师的在项目开发中的所做的事情：
第一步，你要去研究市场，了解用户有什么问题、想要些什么，有可能在市场上你已经有竞争对手，你还要调查对手的当前状态，最后你要为用户提出建议的解决方案，开发一个新的系统或是改造一个旧的系统。这时候你的系统可能仅仅是一个设想，你的系统可能很庞大，需要大量的资金投入，潜藏着许多技术风险，而企业的未来就依赖于你的专业决策，这时候一方面你需要尽量满足用户的欲望，又要小心地避免不可逾越的技术障碍。如果你的系统是卫星、飞机这样庞大的系统，一般的专业工程师如机械工程师、电子工程师根本无法完成这样的工作，这时候你才会闪亮登场。你要与用户签订合同，包括资金、进度、技术等方面的内容，系统的开发被划分为若干的阶段，资金分阶段的支付，每个阶段有确定的进入和完成准则，以避免潜在的风险。作为专业系统工程师，基本的能力包括技术规范编写、进度规划、分解工作是需要的，作为中国系统工程师（如果存在这个名词的话），尤为重要的是喝酒、吹牛皮、胆大妄为和玩弄词汇的能力。
一个需求分析的失败案例：曾经有一位工程师，他提出一个几乎是天才的创意，用卫星连接全世界通信，这个工程具有系统工程的特质，要发射６６颗卫星，投资ＸＸ亿美元，但不幸的是，这个项目失败了。首先手机的发展很快占据了市场，其次卫星电话面临技术障碍，无法在室内通讯，而且硬件过于庞大。可以说项目的决策者没有系统的分析用户的需求、技术风险和竞争对手，导致项目的失败。这就是摩托罗拉的铱星计划。
第二步，你要提出解决方案，或者叫设计，对系统
来说也可以叫架构开发。虽然是第二步，但并不说设计就一定在用户需求调查之后，为了占领市场，有时候它在需求调查之前就开始，有时候它随着需求分析同步进行。系统工程师在这个阶段要开发架构。什么是架构，这个词来自于最古老的工程行业—建筑业，风行于最现代的工程行业—软件业。打个比方，架构就好比人的骨架，潘长江就是吃的再多也长不成姚明，因为他们骨架不同。架构设计充满创意，系统工程师当深通于此，产品围绕架构组成系统。架构使用视图来表达，机械工程使用三个图表示三维实体，系统工程师则使用多个架构视图描述系统。好的架构就像金字塔一样悠久，坏的架构就像某些豆腐渣工程一样脆弱。作为专业的系统工程师，基本的能力包括系统建模、仿真和分析技术。
一个架构设计的失败案例：在某国一个雷电交加的夜晚，两车相撞了，在经历了５个月的调查后，事故报告公开，造成事故一条设计原因是，当一个采集设备被雷击故障后，传送给主机的状态信息一直保持为故障前采集到的信息，使人做出错误的判断。在不知道情况的时候保持最后的状态似乎是一个非常自然的选择，很多的设计师都非常习惯这样设计，但真的如此吗？这个系统的设计师是否做过“故障模式影响分析”ＦＭＥＣＡ不得而知，在项目中做ＦＭＥＣＡ是非常吃力不讨好的，因为这首先要假设所有的设备都可能出故障，然后通过设计确保故障不影响安全，一些安全关键系统中要求连续两个故障或者两个操作错误或者两个操作错误和故障的组合不会导致致命事故。
管理相关：系统工程师脚踏两只船，一只是技术，一只是管理，因此常常与项目管理者的职责分配剪不断理还乱，通常来说项目管理者侧重于进度、资金、范围等，而系统工程师侧重于技术管理，包括技术状态、接口、需求等，什么？技术还有管理？是的，技术需要管理。系统工程师要像猎狗追踪每一个要求的落实，从最初的用户要求到向部件提出的要求直至获得明确无误的证据表明需求已经落实，否则部件设计师会像系统工程师欺骗用户一样欺骗系统工程师。曾经一个火星探测器坠毁，仅仅因为计算单位不统一，如果你是一个学生，计算单位错误最糟糕的结果是考试不及格，而在大型工程中就是数亿美元的损失，为此系统工程师要紧盯每一个接口，防止彼此设计的不匹配，这是一项非常繁琐的工作，因为一个大型系统的接口从几百到几千几万。需求也罢、接口也罢，都要有秩序的管理。管理的技能是必需的。
验证：验证就是为产品满足需求提供证据的活动。如果没
有验证，系统的开发就会像中国的保健品市场一样混乱。验证包含了检查、分析、演示、测试几个类别，验证也像需求一样划分为多个层次，从底层部件到最顶层的系统需要逐步的验证，验证是一项非常消耗资源的活动，因此系统工程师当小心的选择验证的类别、层次，以平衡进度、风险和成本。验证中的某些活动甚至需要独立的专业和工程师支持，例如试验工程师，因为测试设备的准备、开发并非系统工程师能够完成的。对于验证活动而言，除了数学分析能力、发现问题的能力外，最大需要可能就是勇气和诚实，因为在验证活动中发现问题后，许多工程师由于面临各种压力或是采用鸵鸟政策视而不见或是伪造数据欺骗用户。
在中国，还没有一个完整的系统工程教育，有些学校开了系统工程课，也是偏重于数学理论，以下是本人通过自学推荐有志于做系统工程师的人应该学习的知识、工具和需要进行的实践：
·
知识：
o
UML、SYSML标准：建模标准，类似于机械工程师的机械制图标准、电子工程师的电路制图标准，语言是有效率专业沟通和知识传承的保障，没有这些，沟通会陷入咬文嚼字的困境（巴比伦塔建造的失败是沟通失败的最好例子，可见古人很早就认识到这点），设计中所包含的思想也会随着时间而退化。
o
CMMI能力成熟度模型综合：描述了系统工程所需要做的工作内容，对照这本书进行实践和改进。
o
Incose System Engeering Handbook（国际系统工程协会系统工程手册）基于ISO15288，与CMMI类似。
o
System Analysis, Design,and DevelopmentConcepts,Principles, and Practices：有大量指导系统工程的技术内容，值得一读。
o
DoDAF:美国国防部体系架构：DoD一个架构开发标准，很专业，可以参照学习系统架构。
o
其它基础专业：数学和英语要熟练，数学需要大量应用，英语是阅读系统工程书籍的必需；电子、机械、软件等要知道基础概念，对于特定行业的系统工程还更深入的了解相应的专业。
·
工具：
o
系统架构建模：Visio(用于建模表达)、Telelogic(同时用于建模表达和仿真 )
o
仿真和分析：Matlab和Simlink
o
文字和表格：Word、Excel、PPT（编写文件、报告所必需）
o
项目管理： Project
·
实践：
o
需求分析实践：实践MOE、MOS、MOP、TPM分析过程，建立一个系统从顶层直至底层的指标关联。
o
规范编写实践：至少完成不同产品、不同阶段规范编写实践各一次，阶段包括系统规范、研制规范；
o
需求管理实践：完成一次全系统的需求跟踪表，能够在任何时候跟踪需求的达到程度；
o
架
构设计的实践：完成一次基于SYSML标准对系统的完整建模过程；
o
范围管理实践：完成一次WBS，理解WBS模板中各个分解在项目中实际含义；
o
进度管理实践：实践使用Project建立IMS，达到能够自动生成网络图、进行进度分析的效果；在项目进展中记录项目进度，获取第一手数据，积累自己对时间的预测能力；
o
技术状态和信息管理实践：与规范实践结合，建立项目三条基线：功能、分配、产品，实践文件版本管理和控制。
