跳转到主要内容
skip to main content

developerWorks 中国  >  Rational  >

使用模型驱动系统开发(MDSD)方法进行软硬件协作开发

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 初级

Murray Cantor, 杰出工程师, IBM
Gene Roose, 系统工程顾问, IBM

2006 年 3 月 15 日

本文来自 Rational Edge ∶本文介绍了模型驱动系统开发或MDSD的基本原理和原则,模型驱动开发是一种新的说明和创建复杂系统的硬件和软件的方法。

illustration产品开发的方式已经在最后的四分之一世纪略微发生了变化,这多半是由于技术的改进,尤其是由于在微电子电路和软件方面的发展。这些发展已经导致了在系统开发方面的更大的灵活性,这对系统构架师、设计师和开发者既带来了机遇,也带来了挑战。

在过去,当分布式网络、软件工程和嵌入式系统的性能不成熟时,传统的产品开发集中在主要通过硬件来交付服务。今天的更丰富的性能使服务和功能能够在硬件、固件、软件或者这三者的一些组合中被实现。但是这种自由性得到了一种代价:大大地增加了复杂性。尽管有可能将功能分配到组件,与实现那些功能的选择范围相结合,但是传统的管理方法不再能够胜任。

面临着与功能、成本、以及时间表相关的规划和项目管理约束,系统开发队团队需要一种健壮的方法论,可以减少这种增长的复杂性。

这个由多部分组成的系列从一种系统的观点探究了联合软硬件产品开发,并提供了一种模型驱动系统开发(MDSD)的方法,用来优化功能分配。 它应用了合并到RUP-SE最新版本的技术和框架元素, 这是一种经过证实的MDSD框架,该框架是IBM Rational Unified Process®或RUP®的一个扩展, 其特别强调系统工程的挑战。 在本文中所涉及到的工件都包含在IBM Rational Method Composer的新的发布版本中(2005年12月可用), 其为剪裁过程提供了一个灵活的框架,以及为致力于MDSD的产品开发团队提供了最佳实践和在线指南。

此系列的这第一篇文章将软硬件协作开发的独特挑战与传统的系统工程方法联系在一起。在引入MDSD并介绍了一种基于对RUP-SE扩展的MDSD方法之后,本文讨论了与MDSD有关的IBM Rational的六个系统工程基本原则。

随后的文章将集中在跨软硬件边界和多视点的需求的联合实现上。这种方法提供了一个有效的软硬件协作开发过程,促进了多学科团队内部和之间的协作,并指导项目和规划管理,以优化在整个产品生命周期中的涉众价值。

更多的嵌入式软件,更高的复杂性

嵌入式软件构建的产品的数量正在快速地增长,并且嵌入式软件的功能性能逐渐丰富起来,满足了不断增长的复杂需求。这些嵌入式软件对于象航空和国防这样的行业是可预知的开发,我们通常将这些行业与高度复杂的要求系统工程技术来创建的产品关联起来。然而,今天他们同样也应用到消费产品和用具--从高清晰度电视(HDTV)到媒体播放器,到洗衣机和烘干机,到手机和PDA。

这些新的嵌入式软件不断地在替换原先在硬件中实现的功能;例如,数字线路飞行控制系统已经取代了飞机上的机械控制系统。软件也日益增加新的功能,例如智能巡航系统,驾驶员辅助设备,以及在有识别力汽车中的碰撞检测系统。事实上,一般的汽车现在包含大约七十个计算机芯片和500,000行代码--阿波罗11号往返地球需要更多的软件。在高价位汽车中,迁入式软件要交付许多创造性的和有差异的特性,代码量要远远大得多。

然而,大量的代码本身也是一个问题。引起实现头痛的是组件和子系统之上的越来越多的复杂迭代。只是在模型进入生产之后才产生的Bug已经导致了授权和质量保证成本的增加和对品牌形象的破坏。如图1所示,在汽车行业,电子组件中的故障很容易就与将所有其它汽车系统放在一起所产生的故障一样多。

Figure 1: Percent of malfunctions caused by various automotive systems

图1:由不同汽车系统所引起故障的百分比

更多的功能,更少的组件

随着软件容量在规模和复杂性上的增长,一个人逻辑上可能会认为电子组件的数量是随之一起增长的。事实上,情况恰恰相反。工程师们用强调成本、可靠性和打包方式来实现组件之间更紧密的集成,这样他们经常地进行工作以减少软件组件的数量,但是交付了不断扩展的能力。(参见图2)。

Figure 2: Number of functions compared with number of components

图2:功能数量与组件数量对比

系统硬件和软件组件之间不断增加的集成趋势所带来的关注远超过那些传统在系统开发上的。特别是:

  • 开发团队为了响应一个易变的环境必须越来越敏捷,在这种环境中,在一个满足涉众需求的系统能够被部署之前,需求可能经常发生变化。在底层系统技术以快速的步伐发生变化时,需求变动性就会大量地滋生;这会导致设计和组件的提早退化,否则它们是可重用的。
  • 紧密的沟通和协作是必需的,既要在团队和工程学科内,也要跨团队和工程学科。这样的跨边界协作在传统的“竖井式”集中领域开发组织中正在引起挑战。

这些挑战由于相互冲突的要求进一步增加。当组件必须有效地被集成为功能时,有关产品可维护性和可扩展性的业务需求无疑会导致松耦和的组件,这些组件可以更容易地被替换和/或被重用。满足这些相互冲突的要求,需要组织和过程共同改进,以交付一个增加最大价值和巩固竞争优势的解决方案。我们会看到,在本文中所描述的模型驱动系统开发方法可以帮助促进过程改进。

功能分配的传统方法

对越来越少的组件增加越来越多的功能的压力极大地增加了在组件之间分配功能的挑战。传统上,我们将使用一个两部分的需求驱动方法来完成此项分配:

  • 我们将在功能上分解系统,分解成需求层级中的功能(需求分解)。
  • 同时,我们将系统分解成物理组件,这些组件将被集成起来(集成分解)

我们将使用需求驱动系统开发方法在生命周期的早期定义需求,然后使用功能分配技术来派生其它需求,并将它们分配到子系统组件。在此层级的每一级上,我们将使用功能分析来派生需求,并用工程方法来得出有效性度量。一旦需求被分配到一个足够深的级别,将会开始进行详细设计活动。

这些被设计的方法用来创建一个单点解决方案--也就是,一个用于特定需求集的解决方案。因而,这种方法的一个必要假定是需求必须在开发能够进行之前被充分地理解。然而,在今天的软硬件协作开发场景中,却经常不是这种情况。

需求映射问题

考虑一下将需求层级的底层需求映射到物理系统组件的难度。

任何系统开发方法的最终结果都是一个产品,1 通常被由许多原子级子元素(组件)组成,可以被部件号码和替换字段标识为一个单元。随着功能数量的增加,开发组织面临着一种挑战,特别是在由数以百计的原子级组件组成的产品中。需求驱动系统开发方法关注于功能分解,并且经常与集成分解是分开的,集成分解一般发生在开发生命周期的晚些时候。

一个需求驱动的方法也要求较早的技术决策和将功能分配到硬件、固件和软件实体。产品(“硬件”)团队一般情况下做出这些决策,并将详细需求传递给软件和固件开发人员,由他们分别开发他们的组件。工程级产品的组装和集成系统测试发生在大多数产品开发都已经完成之后;这是生产可以开始之前的最后一个关口。

这个过程的问题是什么呢?随着开发不断进行,功能必须被分配到原子级产品组件(参见图3)。单个功能可能被分配到几个物理组件中。例如,一个汽车的防碰撞功能会影响到刹车系统、安全系统(又包括安全气袋、安全带、头靠,等等)、悬架,以及更多。同样地,大多数物理组件将包含许多功能。例如,一个汽车的引擎/动力传动系统,包括加速或减速、引擎制动、巡航控制、启动或停止、变速,以及更多。

Figure 3: The allocation of functions to atomic product components

图3:将功能分配到原子级产品组件

当涉及到复杂的、嵌入式软件时,就会导致一个上千--或许上百万种可能分配的多对多决策树。既有的需求驱动系统开发方法不提供指南如何简化这种分配,或者如何优化平衡分析和将最终的功能分配到硬件、固件和软件实体以及他们的物理组件分配上。

这种指南的缺乏是一个主要的不足之处。在集成运作挑战的因素中,不断增加的需求变动性和史无前例的团队内和团队间协作的需要,就象我们已经讨论过的一样,很容易看出传统的需求驱动方法对于软硬件协作开发工作已经变得站不住脚了。

很明显,需要一种更健壮的方法论,这就是我们现在将提出了。

一种新的方法:模型驱动系统开发

在一个纯粹的面向软件的系统环境中,认识到传统的需求驱动系统开发方法的不足已经有一段时间了。几个已经提供的可替代方法论和框架都有一些共同的显著特性,例如基于模型和迭代开发。敏捷建模、极限编程(XP),以及IBM Rational Unified Process或RUP,就是这样的三个方法论。

然而,当一个系统需要一种大的、复杂的和/或多点的软硬件产品开发时,纯粹的软件方法一般扩展得不太好。这正好是IBM Rational进行RUP系统工程扩展的原因,大家更多知道的是RUP-SE。作为一个成功的MDSD框架的被证实的例子,RUP-SE已经被IBM Rational及其客户使用和改进超过八年了。

在本文中所描述的MDSD解决方案进一步扩展了RUP-SE。它提供了开发方法,用以识别关键软硬件协作和接口,将功能需求和补充规约(例如可靠性,性能,以及容量限制)分配到RUP-SE当前的多视图开发框架中所封装的模型元素中。后者定位在一个联合实现表(JRT)上,这是RUP-SE当前的服务规格说明开发工件的一个扩展。

RUP-SE的概要大纲

像其它MDSD方法论一样,RUP-SE构建在需求驱动开发方法的技术上。通常,系统开发关注于一个系统的分解,以改善我们对系统自身以及其如何满足涉众要求的理解。开发团队必须进一步理解业务的利害关系或使命,以及处理这些利害关系和实现使命目标的系统角色。要确保系统真正满足其想要达成的目的,开发团队必须确定顶级的系统需求以及从系统需求派生的需求由系统组件的协作所满足。为了进行得有效,模型驱动系统开发必须处理这些系统关注点,也必须提供给开发团队一个系统以及其目标和组件的改善理解。

RUP-SE是一个良好发展的和被证实的技术的集合,这些技术用于应对复杂开发的挑战,提高人们通过抽象来处理复杂性的能力。它使你能够在日益增多的跨多个工程视点的更详细的特异性层次上,对复杂系统进行建模。表1显示了RUP-SE的典型系统建模视点,还有特定模型级别所产生的开发工件范例。

表1:典型的RUP-SE模型视点和工件范例
模型级别模型视点
工作者逻辑信息物理过程原理
范围角色定义

活动建模
UML产品环境图,

UML 用例图规格说明
包含扩展产品数据的UML企业数据视图领域相关视图(例如,机电的S空间)领域相关(例如公路的车辆建模)
分析系统分成人和机器的UML分区

活动建模和模拟
UML产品逻辑分解产品数据概念模型(RoseRT/ReqPro中的UML)UML产品地区视图UML产品过程视图(静态图)参数化几何模型

版面设计
设计操作说明

帮助文件

工作流和事务管理
软件组件设计产品数据模型ECM设计详细过程视图,

时序图
MCAD设计
实施硬件,软件配置

在上面表格列中所列出的视点分开提供了一些工程关注项,使得一个复杂系统可以被划分成工程学科或被清晰地描绘成相关系统元素的集合。这些视点通常是针对一个联合软硬件系统的。一个只有软件的系统不会要求几何视点,并且不可能要求物理视点,但是一个像汽车这样的系统可能要求其它视点来封装其架构的特定方面,例如能量传递或碰撞响应。

在行中所列出的模型级别提出了增长的特性级别,并按照系统开发进展详细说明。范围级别提供了一个系统、外部参与者以及系统或参与者交互边界的黑盒。这些边界是架构设计的重要的早期元素,它们马上会关注在开发团队的初始系统分析上。

一旦范围级别被描述出来,开发团队将“打开”黑盒并开始识别哪些分离的元素必须被合并到系统中,以满足在范围级别上确定的服务。这个初始的白盒视图使得团队可以决定子系统(在分析级逻辑视图中)和地区(在分析级物理视图中)。

在下一个详细级别,团队开始在一些软件、硬件和固件还有系统工作者实体的组合中实现分析级元素和规格说明。这一转换是从抽象到具体,并相当直接地通向最终级别,其描述了从模型到一个可交付产品或服务的实际的实施。

这种方法论带来了如下益处:

  • 工程关注项的分离和集成。设计元素的通用集被用于不同的相关工程视点。例如,分析逻辑视图中的设计元素被分割成跨分析级物理视图中的多个地区。然而单独的RUP-SE模型视点使开发团队能够将整个复杂的系统分割成更容易处理的关注项集(关注项的分离),在一个特定系统模型级的不同视图中的通用设计元素集,使考虑中的系统能够被重新构成一个整体(关注项的集成)。
  • 递归的系统分解和从抽象到具体的转换。这种方法使开发团队能够将系统分离成不断增多的较小的和唯一的结构元素。在需要分解以确定原子级系统元素时,此方法的递归性质让分解尽可能多次的发生。这种方法认识到,系统需求和功能在一个复杂系统的开发阶段早期没有被很好地理解。在环境和分析模型级别中所包含的较高抽象级别,在它们最被需要的时候--在开发周期的早期,会促进更大的开发团队的创造性、灵活性和响应能力。这种方法通过最小化由于技术变更而引起的系统组件的返工和废弃,用一种优化成本和进度的方式来处理高风险事项,例如构架的健壮性和误解或不完整的需求。
  • 不断增加范围和复杂性的系统的可扩展性:基本的RUP-SE框架和系统开发方法可以被应用于跨多个系统开发范围。与考虑中的系统相关的视点(并且只有这些视点)可以被指定,还有在每个单元或视图中被产生出的关键工件。考虑中的系统实际上可以是一个较大系统的子组件--例如一个汽车供应商的通用“即插即用”刹车系统--或一个业务组件,例如一个包含业务过程、打印或邮件发送工作流以及打印或邮件发送技术组件的企业邮件室。

正如我们刚才所看到的,RUP-SE明确地支持开发团队在为复杂的软硬件系统构建一个健全的构架中所面临的独特的问题。RUP-SE框架是一个系统开发生命周期管理基本原理、最佳实践、方法和工具的全面集合中的一个元素。整个解决方案集远超过了本文的范围。但是,在这个环境中,对Rational的六个系统工程基本原则的讨论加强了RUP-SE方法论的价值,并进一步阐明了用于成功的软硬件协作开发工作的整个MDSD方法。

系统工程的六个基本原子

IBM Rational的六个系统工程基本原则,是从过去十年间成功的复杂系统开发实践的仔细分析中产生出来的一套高级系统开发指南。尽管它们既不全面,也不互相排斥,但它们适用于强调那些对在复杂系统开发中快速地构建专门技能感兴趣的组织的关键焦点域。它们也在评估潜在的问题域和主要项目不足和故障的根本原因中用作一个“度量技巧”。

众所周知,功能、进度和成本是项目管理的三个关键和相互独立的方面--对其中一个进行变更,影响常常会波及到其它两个。

对于复杂系统开发的产品和计划管理也存在类似的关系。如图4所示,这三个关键方面是:

  1. 系统构架
  2. 组织结构,包括系统开发基本结构
  3. 过程,包括工作流程、最佳实践等等

系统工程的六个基本原则涉及到所有这三个方面。三个技术基本原则(下面所提到的)关注在系统模型的构架和来源上年,其它的基本原则提供了补充的基本结构和需要优化技术开发环境的工作流程。

Figure 4: Three interdependent aspects of managing complex systems development

图4:管理复杂系统开发的三个相互独立的方面

六个系统工程开发基本原则是:

  1. 分解系统,而不是需求(技术的)。
  2. 激活分离和集成«关键系统开发»关注项(技术的)。
  3. 规格说明流动于构架上下(技术的)。
  4. 系统和组件进行协作;因此开发团队也应该协作。
  5. 开发组织应当反映产品构架。
  6. 让«开发»生命周期基于移出风险和增加价值。

让我们检查一下每个基本原则,首先从一个通用的系统工程视图,然后专门在联合软硬件开发的环境中。

分解系统,而不是需求

因为系统和软件工程基本原理和方法已经在无数的案例中被编写、讨论和应用过,一个人可能认为开发团队对像“系统”和“系统工程”这样的术语有一个公同的理解。不幸地是,并不是这种情况;在一个特定行业中的企业中不是这样,在单个企业的一个工程开发社区中的产品和功能领域也不是这样。

按照INCOSE(国际系统工程委员会),系统工程2

一种能够实现成功项目的跨学科的方法和手段。它关注于确定开发周期早期的顾客要求和必需的功能,文档化需求,然后继续进行设计分析和系统确认,并考虑全部的问题:
  • 操作
  • 性能
  • 测试
  • 生产
  • 成本和进度
  • 培训和支持
  • 配置

一个系统是一组相互作用、相互关连或相互依赖的元素形成一个复杂的整体,提供被一个企业用来实现一个业务目的(任务)的一组服务。系统组件由硬件、软件、数据和工作者3组成。简单说,一个系统是一个复杂实体,提供了一些价值的真实结果。系统工程一种严格遵守学科的方法,帮助我们检查想要的结果,并确定什么可以满足它们。它也帮助我们确定如何在一组重要商业约束(成本,进度,测试参数,易于生产,等等)中进行工作。“什么”是系统功能需求“如何”,“重要商业约束”是补充需求,“期望结果”是用例的产出物。

在抽象的最高级别上,我们可以将系统视作一个单个实体(复杂整体),或黑盒。然而,要构建一个系统,我们也必须能够打开这个盒子,向里面看,看一下哪些相互作用、相互关连或相互依赖的元素构成了系统。这被称为白盒视图。系统(和软件)工程的主要任务是递归地从黑盒视图移动到白盒视图,打开系统盒子,子系统盒子,子子系统盒子,一直到我们最终确定可以提供系统预期结果的相互作用和相互依赖的元素集。

INCOSE 对系统工程的定义没有展现对实现系统的开发方法论的偏好。传统的需求驱动方法,严格而精确地定义了项目任务、里程碑、资源和进度,看起来适用。但是,正如早先所表明的,这些方法设计时没有关注早期风险缓解、流动需求或构建解决方案初始不确定的系统;或者甚至受限于科学或技术知识。

正如早先所表明的,主要关注在需求及其功能分配上会导致有关技术和构架的较早(和有约束力的)决策,即使构架没有被明确提出。这些较早的决策会导致不太好的结果:

  • 交付不能满足关键涉众要求的系统。
  • 处理需求变更或误解需求的重大返工。
  • 在最后开发阶段(系统集成)中的“挽救”失控项目的昂贵的“豪言壮语”。
  • 最糟糕的是,在豪言壮语的努力失败之后,整个打碎系统。

为避免这样的问题,我们建议将关注从立即分配系统功能需求的转到预想的实施级组件上--例如,一个既有的软件模块或商用硬件组件--为了一个最终系统抽象的更全面分析。

需求分析、分配和确认是这种方法的十分重要的元素,但是它们不是系统分析和综合的焦点。目标是用一系列逻辑步骤在结构上分解系统,遵循此过程:

  1. 理解系统在其想要的环境中的工作。将系统视为一个黑盒,确定与系统(系统 参与者)交互的环境元素和实际的相互作用及结果(系统用例 及产生的 服务)。在RUP-SE建模中,这是范围级的系统分析。
  2. 决定如何开始将系统分割成元素,元素的协作将提供服务,满足范围级上系统的要求。递归地从黑盒和白盒透视图检测元素,直到关键功能和补充需求被相互依赖的系统元素的交互所满足。这是RUP-SE中的分析级的调研。
  3. 一旦系统构架通过这个结构分解过程被抽象地产生出来,下一步就是确定如何实现系统元素。这是一个从抽象到具体的转换,分别在硬件、软件、固件、数据和工作者的一些组合中实现。RUP-SE将此称为系统开发的设计级
  4. 最终,系统被构建,测试,以及准备发布。在前一个步骤详细说明的设计被实现出来(最理想的是在按照RUP和RUP-SE框架中所定义的“迅速发布”迭代阶段中)。开发的最后阶段被保存在RUP-SE的系统开发模型实施级中。

随着我们从一个级别进行到另一个级别,需求被更准确地分配到系统元素,不确定逐渐地被提出和消除,并且系统可以被迭代地展示和评价。每个分解级别都强制进行设计决策,提供正在进行的合成,连接需求和设计规格说明,并增加系统详细内容。

尽管以上步骤可能是连续出现的,并且在一个较低的、更详细的模型级上的调研似乎要求在更高的级别上完成活动,在实践中经常不是这种情况,这取决于众多因素。这些因素是由下面两个系统工程的基本原则所提出的。

激活关注项的分割和集成

处理系统复杂性的一种普通的方式是聪明地将系统分割成较小的、不复杂的小段。这样做的方式是多样化的,但是对于相似的系统类型,分割倾向于遵循相同的模式。例如,你可能分割一个汽车,通过将相关的功能组件分组在一起,例如底盘、动力传动系统、内部、外部、电子装置或软件,以及操纵、刹车或悬挂。

然而,只从一个透视图来分割系统,可能将不会促进所有涉众要求的分配。系统工程并不是狭窄地关注于构建一个满足功能要求的系统;更确切地说,它必须将在其预期环境中的系统视作操作、生产、服务、系统参与者以及其他涉众组所看到的。性能、易于使用、美观、可靠性、依从性以及所有其它约束必须被提出。

在同时尝试满足许多非功能约束时,从多个透视图来检查一个系统可能看起来是一种复合开发复杂性的方式,而不是减少它。代替处理一个带有n个约束的透视图,开发团队不得不面对带有n个约束的m个透视图。这正好是第二个系统工程基本原则要处理的问题。要激活工程关注项的分离,仅仅分割系统是不够的。被选择的系统工程开发方法论也必须提供系统重新集成的方法。

正如早先所提到的,一个已有RUP-SE框架元素的组合及新的联合实现表(JRT)构建提供了关键系统开发工程关注项的分割和集成。这种框架足够灵活和健壮,以支持跨众多行业和产品的开发活动。

在实践中,框架被裁剪成一个特定产品或产品集。裁剪框架的过程通常发生在开发周期的早期。在RUP中,这会靠近先启阶段的末尾。裁剪提出了两个主要问题:

  1. 哪个工程视点必须在系统建模和开发中被处理?为了一个联合软硬件系统,这将至少包括逻辑物理 以及 信息视点。在大多数情况下,几何也将被应用到。
  2. 哪一个单个模型视图将被处理?以及每个视图将开发出哪些工件?例如,分析级逻辑视图保存了系统的逻辑分解。这时,我们开始打开黑盒子,黑盒子就是系统,并决定内部元素集,其协作满足参与者置于系统的要求,它们将在范围级逻辑视图建立起来。在我们的MDSK方法中,这种逻辑结构及其伴随的协作将通过使用系统模型工件中的统一建模语言(UML)图被保存下来。

MDSD框架裁剪的产品是开发案例工件,其将指导开发团队通向切实的结果。这些结果被表现为与贯穿系统定义、分析、设计、构建和测试的迭代开发周期的开发进展一样的单独视图中的构件。

规格说明流动于构架上下

在一个完美的系统开发环境中,以上所概述的在激活关注项的分离和集成时从结构上分解一个系统的过程,应当用一种组织管理严密的方式自然地进行。然而,完美是很少发生的。不确定、误解、缺乏沟通、变更、技术不足以及所有其它因素限制了这种从范围到分析到设计以及最终实施的组织管理严密流动,使之难以的没有缺陷地进行下去。承认这些限制并在系统开发生命周期中尽早地处理它们,基本上是成功的关键,并且是模型驱动系统开发的一个基本的原理。

实际上,规格说明流动于架构上下。事实上,规格说明流上,流下,并且从旁边流动。在一个视图中所进行的发现可能会很好地辐射开来,影响到同一模型级别的其它视图中的工件;它们也可能在相同的视点上流上和流下模型级别。这是系统架构开始变得有缺损的指示器吗?不一定。例如,在分析系统或子系统原型时,在开发周期的相对早期进行的发现,可以比较容易地要求对系统架构的重大修改。

这是一个特殊的例子:通常的打印系统架构包括一个将数据输入到标记(成像)引擎所要求格式的子系统。这个子系统通常存在于打印系统的控制单元中(单个地区)。在一个特定的打印系统开发的早期,原型测试显示出没有充足的处理器、内存和数据带宽来满足指定的页面打印目标。基于此时可用的计算技术,满足带宽需求唯一的方式就是跨三个计算机展开数据转换,并管理与其它子系统的工作分工。在这种情况下,用一个原型所揭示的技术约束导致了三个额外的地区,在地区、新接口和对打印系统控制单元中的逻辑子系统的变更或附加之间关联新的连接。

类似的技术考虑应用到许多不同类型的产品,这些产品要求设计人员选择在何处和如何实现功能。热量约束可以很好地强制计算机、程序控制台等的设计决策。几何约束(形状和体积)无疑影响到设备的设计决策,如手机;每一代新产品都在曾经较小的表格中塞入了更多的功能。物理约束(体积和密度)可能也要求修改机器设备,如汽车和飞机。

处理这些约束以及其它在系统开发进行中所出现的是一个发现过程。随着设计决策被制定下来,记录它们的特性是重要的,包括它们对未开发完的产品及其基于模型的表现会有什么效果。

系统和组件进行协作;开发团队也应当如此

上面所概述的三个基本原则为系统开发团队提供了技术指南。它们指导我们从结构上分解系统,从代表关注项的重要区域的多个视点来进行检测。它们也提供了一种机制重新将系统集成为一个整体,同时认识到规格说明一定不只是在计划和概念阶段中被发现的,在设计和构建阶段中也是一样。这些发现将导致设计决策,设计决策可能影响的系统元素比视图中所包含的更多,在视图中规格说明首先被确定,导致上上下下发生变更,并且是跨架构级别。

随着系统在复杂性上的不断增加,组件和子组件会有更多的需求。服务逻辑上被分组以满足功能和补充需求,并且系统实体之间的交互必须被充分地描述以使系统可以满足其预期的目的。随着模型从抽象元素转移到具体元素,功能被分配到软件、硬件、固件和工作者,并且元素之间的协作被最后确定下来。

在软硬件协作开发工作中,开发团队之间的协作具有更大的重要性。许多企业通过专门技术将工程师和开发人员结合在一起;软件工程师主要关注在软件系统元素上,硬件工程师可能要和功能组件(例如,一个汽车的引擎或底盘)结合在一起,等等。这种结合会导致“火炉烟囱”;也就是,特定知识的窄带,窄带之间很少有交互。尽管这种结合自身可能是一个好的实践,但火炉烟囱却不是。因此我们的系统工程基本原则就是:系统和组件进行协作,开发团队也应当如此。这常常需要将管理关注在鼓励和促进开发团队协作上,同时也关注于确定跨领域和更高级资源的合适数量。这种额外的管理关注的一个例子可能是一个围绕产品架构的企业级系统架构。

像这样一个MDSK框架和方法论可以在促进开发团队协作方面帮助进行管理,还有自动化和加强系统开发工件收集和管理的软件工具也可以。后者是记录设计决策和和提供需求来源和分配系统元素的追踪关系的关键。

无论什么时候可能,沟通和协作都应当按照支持清晰、有效和及时的知识和工件交换的需要而被评估和重新结合。这样做的一种方式(已经在IBM开发中实施了)是构成由关键产品开发涉众组成的“集成产品团队”,并保持定期的团队会议以汇报状态,并确保关键涉众需求在整个开发生命周期中被讨论和处理。

开发组织应当反映产品架构

系统工程的前面的基本原则集中在开发团队之间的协作上,以确保系统元素之间的交互可以完全从相关的多视点来进行处理。

下一个基本原则叙述和阐明了一个优化协作和沟通的最佳实践。它表明了开发组织应当反映出产品架构。

与产品架构结合在一起的开发组织既有效率,也工作有效。这种结合自然地优化了开发团队之间的沟通路径,并且分成工程师、编程人员、测试人员以及其他开发人员组,为资源提供深入的技能和深度能力。

我们的前提是,具有成功产品的成功企业可能已经或暗或明地成功进行了这种结合。但是,随着时间的过去,市场和产品在变化。当这种变化涉及到产品内容和功能的重要转变时,企业必须作出反应,并重新结合变化的产品架构。如果不这样,必需的协作和沟通就开始受损并失去其效率。

考虑一下汽车行业。直到最近,汽车在很大程度上由软件构成。引擎和动力传动系统、刹车系统、底盘、外型、内部以及诸如灯、挡风玻璃雨刷和紧急刹车装置都是关键的组件和子组件。这导致了在这些领域的具有专门技术的开发组织。当考虑一个新产品时,通过从每一个特长域中挑选资源来形成产品团队。然而,目前软件在汽车和对新产品内容有重大贡献者上正在呈现更大的重要性。随着更多的功能在软件中实现,需要增加产品团队、硬件领域和软件工程师之间的协作和沟通。这种在内容上的变更有希望将通过开发组织结构上的改进来完成,以正确地反映软件的增长的影响。

使生命周期基于消除风险和增加价值

以上所有这些基本原则涉及到系统工程的三个关键方面:系统架构,组织结构和过程。这三个方面由适当的管理保持在一起:计划和项目管理,执行操作,变更和配置管理,承包商和业务伙伴管理,等等。管理团队负责确保首先消除最高的风险,以及产品或计划价值能够按照开发进展情况来定期度量。这导致了最后的系统工程基本原则:使生命周期基于消除风险和增加价值。

对于复杂的系统,不确定通常是一个程序在开发的早期阶段面临的最大的风险。第二大的风险区域就是在开发过程中的早期不去确定假定条件(这可能在系统进行集成测试时被证明是无效的,导致重大的返工)。第三大风险区域是对硬件、软件和固件的特定实施承诺过早,最后导致短暂的系统,不能被容易的扩展。

如何度量价值呢?在确定方法之前,首先需要进行一个评估,以确定一个给定的程序或产品想要什么“价值”。如果价值度量正在提供给一个满足涉众需求的系统,一种方法就是定期去证明开发系统是针对关键的涉众。这种方法既包含在RUP中,也包含在RUP-SE中。系统被迭代地进行开发,有规律地增加性能。开发团队不断请求涉众对每一次迭代进行评审和反馈,并对适当的系统调整进行响应。

这六个基本原则及它们所包含的方法确定要消除风险,并为复杂的软硬件系统的协作开发提供了一种框架。在以后的一篇文章中,我们将通过概览一个打印系统范例的结构分解并结合实现来阐明MDSK技术。

注释

1 本文关注在物理产品上--也就是,可能也包含固件和软件的硬件产品--相对于商用构件(COTS)软件,例如,对此唯一的物理具体化是一个诸如CD-ROM的发行媒体。

2 Blanchard 和 Fabrycky,系统工程和分析,第三版。Prentice Hall 1998。

3 如上。





回页首


参考资料

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文




回页首


作者简介

Murray Cantor's photo

作为一个IBM Rational领域服务组的一名领导者,Murray Cantor促进和扩展了Rational的最佳实践,并与顾客一起使用创新的方法更有效地构建和交付系统。现在,他在领导一个用于软件开发组织变革的新模型的开发,以及用于系统工程的Rational Unified Process®(RUP-SE®)。后者方法论对于那些从事于前沿的大规模的硬件和软件系统开发的组织是关健的。他也关注于如何将IBM Rational领域能力与其他的IBM品牌集成在一起。

由于他对RUP-SE的贡献,以及他在与客户进行企业变革方面的成就,他已经被授予IBM杰出工程师称号。 作为一个有名的思想领导者,他是一名在业界广受欢迎的基调发言人,已经发表了二本书和众多的论文,并且在与UML和RUP有关的标准委员会中扮演关键角色。

Murray Cantor在1973获得了伯克利加州大学的数学哲学博士。


Gene Roose是一名IBM Rational的高级系统工程咨询顾问。 他帮助客户进行解决方案分析和设计,架构的推导和确认,以及全面的项目管理。 他与Murray Cantor 在研究专业传动系统的一个重要的系统工程过程方面的协作为本文提供了基础的资料。

以前,他在80年代早期以开发印刷(AFP)软件和硬件开始,开发、部署和支持了IBM 印刷系统和文档出版产品。

他持有亚利桑那州大学的数学学士学位和统计学硕士学位,以及乔治华盛顿大学的项目管理专家证书。






回页首


对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?




回页首


其他公司、产品或服务的名称可能是其他公司的商标或服务标志。


    关于 IBM隐私条约联系 IBM