Mk2.5系统采用的是少数点到点连接的处理器，而SS2000系列产品则采用大量的、分布 程度很高且有容错要求的处理器。实现软件生命周期的方法也由原来的基于RTL/2的结构 化分析/设计和瀑布式开发过程转变为采用更具面向对象特征的Ada83和迭代式开发过 程。对开发的支持手段也由原来自定义的本地创建和维护的开发工具转变成了大型的、业务化的环境。
15.1.6 CelsiusTech公司的组织结构
1. 1986年以前的项目组织
海军指挥控制系统（Mk2.5)的开发是由项目经理负责的。项目经理可以采用负责各 个功能领域（如武器系统或C3系统）的部门所开发的成果实现系统功能的主要部分。图 15.8表示了 Mk2.5系统开发所采用的组织结构。每个功能领域（指挥控制、跟踪等）都由 项目经理负责，这些项目经理在从开始到系统集成的整个阶段中有人力资源使用权，能够 管理和控制所有的系统开发活动。
CclsiusTech公司发现这种部门化的任务安排促进了 -•种具有如下特征的开发模式的
把系统的主要功能分配给各个功能领域部门，并且将这一工作作为系统分析的一 部分。
将所分配的系统需求和接口写入文档，以减少各功能领域部门之间的通信.使得 各部门在设计、实现和测试中对需求和接口分别做出解释。
接口的不兼容性通常要到系统集成时才能够发现.这使得在职责划分上浪费了很
多时间.集成和安装也要耗费较多的时间，且不易实现。
• 功能领域部门经理对系统其他部分的开发知之甚少，
• 缺少激励功能领域部门经理相互协作解决全局问题的机制。
2. SS2000的组织：
从1986年后期到1991年。随着在1986年后期SS2000产品线的形成，对Mk2.5系统 开发所采用的组织结构的调整也逐步完成了。图15.9给出的是CelsiusTech公司在从1986
年后期到1991年期间为适应该产品线的开发而采用的组织结构。这时要委任一位项目总 经理来领导整个规划的开发。这位总经理要负责产品线的创建，以及该产品线中各客户系 统的开发与交付。为解决以往部门化结构的问题，CelsiusTech公司建立了强有力的管理小 组.由该小组专门负责产品线的开发并以之作为公司资产，而不再采用“自行构建”的方法. 为达到这•目的，要求各功能领域部门经理直接向项目总经理汇报。各个开发人员分属于 不同的功能领域——武器系统、C3系统、人机界面（HC1)、公共服务（由各功能领域所 使用的）或者是到各种硬件和操作系统的接口（称为基本系统)》
在这一阶段，创建了小规模的、主要关注技术问题的构架小组。该小组完全拥有并控 制构架.并直接向项目总经理汇报。CelsiusTech公司认为，产品线的成功依赖于稳定而灵 活的构架.这构架应该是整个组织都可以看到的，而且该小组应由最高管理层授予某些权限。所以，CelsiusTech公司对自己的内部组织进行了调整，以充分适应.构架商业周期的 要求：构架必须是这种新方法的核心，也将对该组织的一些珉要方面产生重大影响。
多版本的定义和管理的相互协调是创建产品线的中心问题。为更好地支持对多版本的 管理，CelsiusTech公司把软件系统的集成表配置管理工作交由一个新的小组来完成，该小 组直接向项目总经现汇报。构架小组和集成配置管理小组对CelsiusTech公司来说都是新设 置的部门，在SS2000产品线的创立过程中发挥了很大的帮助作用。
构架小组负责最初的开发，且在最初的构架完成后继续拥有和控制产品线的构架。这 就保证了各功能领域设计的-致性和可解释性。具体地说，构架小组对如下各方面负有责 任并具有相应权限：
• 产品线概念和原则的创建
• 各层及其对外接口的确定
• 接口的定义、完整性和受控演变
• 系统功能在各层上的分配
• 通用机制或服务的确定
• 诸如错误处理、进程间通信协议等通用机制的定义、原型建立和实施
• 向项目幵发人员传达产品线概念和原则
最初的构架是由两位在该领域具有丰富经验的高级工程师经过两个星期的研究后提 出来的。现在，该构架仍然是现有产品线的框架，包含组织上的概念、层的定义、大约125 个系统功能（现在大约圮200个）的确定、这些功能在各层上的分配、分布和通信的主要 机制等。在最初的构架提出后，构架小组就进行了扩充，各功能领域的首席设计人员也加 入到其中。整个构架小组现在有10位高级工程师，他们对构架进行了进步的扩充和求精,这与过去的情况形成了鲜明的对比——在过去，各个功能领域部门对自己领域的设计 和接口具有完全的自治权。
所构建的集成和配置管理小组负责如下工作：
• 单元测试之上的测试策略、测试计划和测试案例的开发
• 所有测试的协调
• 增量式构建计划的幵发（与构架小组有关）
• 有效子系统的集成和发布
• 开发和版本库的配置管理
• 软件交付介质的制作
3. SS2000的组织：从1992年到1998年
从1992年到1994年，CelsiusTech公司的重点逐渐从构架和产品线元素的开发过渡为
利用产品线合成新的客户系统。这一趋势使客户项目管理组的规模和职贵都得到了增强。 CelsiusTech公司对其组织结构做了调整，将开发人员分配到如下两大部门：
• 组件项目部门：负责产品线元素的开发、集成和管理。生产分别由负责功能（武 器、C3和HCI)、通用服务、操作系统和网络元素的各个组件项目部门完成。组 件项目经理是轮流担任的，这使中层管理人员对产品线有了更为全面的理解.所 开发的元素提交给客户项目部门。
• 客户项目部门：负责客户产品在系统集成、测试与交付等阶段的所有财务、调度 与计划、滞求分析等工作。根据产品线所开发的每个客户系统都有自己的项目经 理，负责与客户的沟通与谈判。
随着CelsiusTech公司基本产品线的完成和使用产品线的经验的不断增加，该公司逐渐 认识到可以采用更有效的方式开发系统，对产品线做相应的演变，以便更好地利用新技术 和不断变化的客户任务需求。这是构架商业周期中的反馈作用，即构架使开发组织的组织 结构不断发生变化。由此得到的是图15.10所示的组织结构。
公司里对每个大的应用领域（海军和空防）都设立了相应的业务部门，并且有自己的 经理。每个业务部门都有自己的营销组、建议组、客户项目组、系统定义组。各业务部门 负责自己的软件元素，对客户项目经理负责。毎个业务部门的运作都受市场普销计划、产品计划和技术-构架计划指导。市场营销组制定营销计划.负责评估每个市场的商机和价 值。产品计划则对业务部门出售的产品进行描述，是由建议组来完成的。产品计划实现市 场背销计划。系统定义组负责完成业务部门的技术-构架计划。技术-构架计划又实现产品 计划，大致确定了业务部门构架的演变方向。新项目的建议要考虑到业务部门的产品计划 和技术-构架计划。这种方法可以使项目与产品线保持一致。
模块足由开发组提供的。任何客户的剪裁或开发都是根据业务部门的客户项目. 结合从开发组得到的开发资源进行管理的。业务部门的系统定义组负责构架的有关事宜。 系统定义组拥有构架.控制构架、主要接口和机制的演变。对海军业务部门而言，系统定 义组仪由少数几个（通常是6个）对海军产品线非常熟悉的商级工程师组成。该小组负责 对客户霈求及其对产品线的影响做出裁断。
海军业务部门促进了 SS2000产品线用户组的形成。该用户组起到了在产品线方法下 共享客户经验的论坛的作用，并为产品线的未来演变指明了方向。该用户组包括来自世界 各地的SS2000客户代表。
开发组为所存业务部门提供开发资源。集成、配置管理和质紙保证等资源也由开发组 根据用户豁耍提供给业务部门。为进一步优化根据产品线进行的新系统创建，最近又设立 了基本的SS2000配贤项3。设置这一项目的目的是创建基本的、预先集成好的、源代码 大约1<; 50万行的核心系统，该系统配备有相应的文档和测试案例，以便为新的客户系统 的构建提供个核心。
技术指导组（Technical Steering Group, TSG)负责对有益于CelsiusTech公n]业务领 域的潜在新技术进行确认、评估和引导。TSG由技术副总裁任组长，其成员则是来自海军 和空防业务部门、开发组和研究与开发组的高级技术人员。TSG也要保证各个系统定义组 完成其构架和技术规划的建立.并在此基础上做进一步的演变。
5.人员特点：从1986年后期到1991年
如图15.11所示，项目组成员人数从最初的二三十人到后来最多时的200人不等，平 均是150人。在产品线的概念和构架尚未完全形成时，CelsiusTech公司发现所用开发人员 数慑人多。由于当时新概念、新方法不断涌现，所以人数多使问题更为复杂-
构架小组负责为产品线创建框架。构架小组的成员必须对相关领域和客户相当熟悉，
而且耍把这种熟悉与工程技巧结合起来，要能够综合考虑，确定出合适的通用机制或产品 线元素。该组的成员还必须善于交流，富有协作精神。幵发人员滞要了解产品线的框架、 构建代码以及自己所开发的模块将如何加入其中。在产品线的成型时期.开发人员要具备 Ada语t使用、基于对象的设计、软件开发环境（包括目标测试床）等方面的技巧•另外， 还要有较宽的知识面：产品线的概念、SS2000构架及其机制、可重用模块的创建、增量式 集成并且至少熟悉•个功能领域。
在必须具备的多项技术尚不成熟的情况下，管理小俎（及高级技术人员）在很大程度 上是基于对实现最终共享功能的信念而操作的。他们的主要职责之-就是把业务需要和理 想的未來状态“出售”给各个相关小组。
构架小组需要非常熟悉产品线和越来越多的当前或未来的客户需求中的要素„与客户 项目经理（协商多个客户的需求）和开发人员（期望对主要接口和机制进行优化）进行交 流的能力仍然十分重要。对于构架小组的成员来说，在保持构架总体完整性的同时对各种 新需求进行平衡是一种非常艰难的工程技巧，因为他们在不断演变构架及其主要接口和机 制。构架小组要参与技术演变、新接口的原型开发（为外部用户和应用开发人员），并评 价新技术对产品线的影响。
随着产品线的日渐完备，已不再像过去那样重点强调技术的成熟与培训了。由于有了 史多的现有客户系统，在多个客户之间进行更改客户衢求的协调逐渐成为管理的重点以及 需要优先考虑的问题。这种需求的协商不仅涉及到客户，也涉及其他的客户项目经理和产 品线构架小组。客户项目经理不仅需要举握更多的谈判技巧，而且需要对现有的产品线及 其可预期的未来发展有更多的了解。
15.2需求与质量
要利用组织的存储库开发新产品，就得保证这些产品在结构上是相似的，从而能够共
亨模块。就像在第14章中所讲到的那样，这意味着必须要有一个标准的模块集合，要就 每个模块责任、行为、性能、接口、功能的位置、通信和协调机制以及其他一些特性达 成一致。产品线中各产品共有的结构、模块、各模块特性等构成了该产品线的构架。
我们己经看到，构架的主要目的是实现满足其行为和质量需求的系统。SS2000产品线 中各个产品的构架也不例外。在这些需求中，最重耍的厲性是：
•性能。指挥控制系统必须能够以实时方式对不断到达的传感器输入做出响应’ 并且能够控制武器。
•可修改性。构架需要在如下方面具有健壮性：计算平台、操作系统、添加或更換 传感器和武器系统、人机接口需求和通信协议等。
•安全性、可靠性和可用性。系统必须在需要时可用，为武器系统提供正确的数据 和命令，并且只在正确的情况下发射。
•可测试性。每个系统都必须是可集成和可测试的，以快速发现、隔离和纠正任何 错误。
除了这些单系统需求，SS2000产品线的构架还要能用于一大类系统的开发•对这种构 架的需求包括要能够在不破坏构架的其他部分的情况下将现有的模块换成针对某个特定 系统的模块。
操作环境和物理结构
现代舰战系统的需求给设计方案带来了很大影响。现在，传感器和武器系统遍布親船 的每一个角落，船员们要通过各种工作站与系统进行交互。HCI部分必须要经过精心设计’ 以便能够快速地传达信息或接收命令，而且还必须适应该舰船的实际操作任务和船员们的 文化背景。考虑到组件可能会崩溃的情况，必须采用容错性设计方案。
图15.12给出的是这种系统的典型物理结构。用一个冗余的局域网作为系统的通信主 干。该局域网上连接了 30?70台不同的处理器，它们相互合作，共同完成系统的功能。 该局域网上的结点总数可以是30个左右，这里所说的结点对应于某条通信线路的端点’，可能足某个船员工作站、武器系统平台或者传感器组，它们位于舰船上的各个不同的位置’ 彼此之间可能有很大的间距。一个结点最多可有6个处理器。目前这一局域网采用的是双 重以太网。设备接口模块负责在系统终端、主传感器、所控制的武器系统之间发送和接收 数据。
15.3构架解决方案
我们使用3个视阁来描述构架：解释如何实现分布的进程视图：讨论SS2000系统如
何实现关注点分离的基础的分层视图;展示将责任分配给系统不同规模元素的模块分解视 图（称为系统功能和系统功能组)。根据这3个视图表述了构架后，我们将讨论CelsiusTech 公司针对产品线的维护和运用所使用的一些技巧。
15.3.1进程视图：满足分布式和产品线支持的要求
每个CPU都运行一组Ada程序.每个Ada程序至多在一个处理器上运行。一个程序 可能包括几个Ada任务。SS2000产品线中的系统最多可以包括300个Ada程序。
在分布式计算平台上运行的需求对软件构架有着广泛的影响。苜先，它要求将系统构 建为一组通信进程，从而使进程视图发挥作用。从根本上说，拥有进程视图意味着应用了 性能战术“引入并发”。采用分布式系统还要处理死锁的避免、通信协议、容错性（以防 某个处理器或通信线路故障）、网络管埋与拥速的避免、各任务之间进行协调的性能等问 题。为支持分布式结构，采用了许多约定。这些约定不仅是构架的分布式要求.也是产品 线的要求。这些任务及组件间的约定如下：
• 组件间的通信是通过强类型消息的传递而实现的。抽象数据类型及实施操纵的程 序是由传递消息的组件提供的。采用强类型方式使得在系统编译时就可以排除若 干类错误。消息是组件接口的主要机制，它使得各个组件能够在不考虑其他组件 对数据表示的实现细节（这是可变的）的情况下独立编写。
• 进程间通信协议是支持本地独立性的Ada应用程序之间的数据传输协议。这-协 议允许应用程序在不考虑各自所在处理器位置的情况下进行相互通信.这种处 理器分配匿名性，使得进程可以在处理器间迁移，从而能够在不改变源代码的锖 况下实现运行时间之前的性能调整和运行时间的重新配置.并以此作为实现容结 性的一种方法。
• 采用Ada任务机制实现线程模型。
数据的生产者在不需要了解数据使用者的情况下完成自己的工作。数据的维护和更新 从概念上是与数据的使用相分离的。这是应用了战术“引入仲裁者”以实现可修改性.设 计人员使用黑板模式实现了这一点。数据的主要使用者是HC1组件。包括存储库的组件叫做通用对象管理器（Common Object Manager，COOB)。
图15.13说明了 COOB在运行时所起的作用。该图不仅给出了经过通用对象管理器的 数据流，而且给出了因为性能原因绕过COOB的数据流。轨迹信息（某个目标的位置历史 信息）是用一个大数据结构来组织的，它直接在数据的生产者和使用者之间传递由于轨迹球信息的更新频率特别快，因此它也绕过COOB。
关于数据生产的约定包括：
•仅当数据有改动时才发送数据。这样就可以避免不必要的消息进入网络 。
•数据以面向对象的抽象形式表示出来，以便将程序与改变的实现细节隔离开来。
数据的强类型可以在编译时就把各种使用错误检测出来。
•组件拥有自己所更改的数据，并提供作为监控程序的访问过稈。这就排除了争用 的情况，因为每个数据项都仅由拥有它的组件直接访问。
•系统各结点上对数据感兴趣的各方都可以访问到此数据。指派到某个结点并不影 响组件所能访问到的数据。
• 数据是分布式的，因而对访问请求的响应时间短。
• 从较长时间段来看，数据在整个系统中是一致的。允许出现短时间不一致的情况„
与网络相关的约定包括:
• 从设计上保证网络负载较小——即在设计时为管理网络上的数据流做了大量的 工作，保证在网络上传输的都是必要的数据。
• 数据通道具有一定的防错性。尽可能在应用程序内部解决出现的错误,，
• 允许应用程序偶尔错过某次数据更新。例如，舰船的位置是在不断变化的，某次 方位数据的更新可能会被错过，可根据其前后的更新情况进行添加。
其他的约定还包括：
• 大量使用Ada语言的类属，以提高可重用性。
• 使用Ada语言的标准异常协议。
这些约定（特别是关于抽象数据类型、IPC、消息传递、数据所有权的那些约定）大 多都允许模块在不考虑自己所不能控制的可变部分的情况下独立编写。也就是说，这些模 块更具通用性，可以由不同的系统直接使用。
153.2分层视图
SS2000的构架是分层的，如下所示：
• 模块的分组大致是按照所封装的信息类型划分的。在硬件平台、局域网或结点之 间的通信协议发生变化时必须改动的所有模块构成•个层，用于实现同-类产品 系列中通用功能的模块构成另外一个层。最后，针对某个特定客户产品的模块也 构成•个层。
• 这些层是按顺序排列的，依赖于硬件的层在最底端，针对应用的层在最顶端。
• 这种分层是“严格”的，即限制层之间的交互。处于一个层中的模块只能够访问 同层中的或下一层中的模块。
在SS2000系统中，最低层是基本系统2000。该层提供了操作系统、硬件、网络和应 用程序之间的接口。对应用程序编程人员来说，基本系统2000提供了一个编程接口，利 用这一接口就可以实现组件间的通信与交互，而不必考虑下层的计算平台、网络拓扑以及 各功能在处理器间的分配等内容。图15.14说明了 SS2000的构架层。
15.3.3模块分解视图：系统功能和系统功能组
我们在第2章已经提到过，对于在模块分解视图中引入的模块，组织通常都有自己的 术语。CelsiusTech的模块被称为系统功能和系统功能组。
系统功能是SS2000中模块分解的主要元素。系统功能就足用以实现逻辑上相关的某 组需求的-•组软件，它由若干个Ada代码单元构成。系统功能组是系统功能的集合，它构 成开发小组任务分配的基础。SS2000系统由大约30个系统功能组组成，其中每个功能组 包括多达20个左右的系统功能。系统功能组是围绕几个大功能领域组织起来的，这些领 域包括：
• 指挥、控制和通信
• 武器控制
• 基础部分，即实现系统内通信和与计算环境接口的机制
• 人机界面
图15.15说明了各种不同类型模块之间的关系。
系统功能组可能（而且确实）包括来自不止一个层上的系统功能。系统功能组对应于 更适合由规模更大的开发小组开发的更大的功能。例如，要为每个系统功能组编写单独的 软件需求规范。
系统功能和系统功能组（而不是Ada单元）是产品线测试和集成的基本单元。这点 很关键。它能够使产品线中的新成员被看作是少数（10多个）高质量、高可信模块的组合， 并且这些模块之间以一种可控的、可预见的方式进行通信，而不是由数千个在有新改动时 就必须进行回归测试的小单元构成。预先试验的大元素的组装对在CelsiusTech进行重用是 很关键的。
15.3.4应用SS2000构架
表15.1总结了 SS2000的构架目标，以及为实现这些目标所使用的方法和战术（第5 章)。本节通过讨论在构建和维护构架以及根据该构架构建系统家族时会出现的4个重要 问题.对构架表述进行了总结。
将构架作为基础.，虽然这•案例分析强调如果不考虑商业、组织结构等方面的问题. 仅凭技术上的解决方案并不足以形成产品线，但SS2000系统的构架提供了实现这一产品 线的手段仍是不争的事实。在实现产品线这一目的过程中.抽象和分层是非常重要的。通 过抽象可以创建出将可能改变的决策封装在接口边界之内的模块。当在多个产品中使用该 模块时，只要有可能，就用参数化的形式来实现这些可改变的决策实例。当模块随时间的 推移、为满足新的需求需要进行改变时，这些封装在模块内部的可改变决策就可以保证不 必改变整个软件资产库。
这•构架及其填充模块的规模和复杂性清楚地表明，如果要将系统划分成具有如下特 点的若干模块.就必须对应用领域有透彻的理解。这些模块的特点是：能够相互独立地开 发：适用于其产品有多种差异（如SS2000系统的产品）的产品线；能够方便地容纳未来 的演变。
在开发新系统的同时维护资产库。我们已经说过，CelsiusTech公司所开发的并不是针
对某•个具体客户的舰载系统，也不是迄今为止已部署系统的集合。我们把其中心任务看作是对产品线自身的维护。对产品线进疗维护也就意味着要维护可甫用的资产，使得该产 品线的任何已部署产品能够®新生成（毕竟它们会随着需求的变化rfii变化、演变和壮大)， 并能够构逑出厲于此产品线的新系统。从某种意义上说，产品线的维护就是能力的维护， 即对用软件资产生成产品的能力的维护。维护这种能力就意味卷要保i正可重用模块足最新 的、通用的。不允许产品线中的产品以独立于产品线的方式进行演变。这是解决第14章 中谈到的保持产品线的演变与各产品的演变同步这问题的方法之一。
并非所有的模块都应用于产品线中的每个产品。例如，不同商家对密码技术和人机界 面的需求有着很大的差别.因此构建用于少数几个系统的模块要更为合理。从某种意义上 说，这在大的产品线中乂生成了产品线：瑞典产品集、丹安产品集等。有些模块仅使用一 次，但即使这样的模块也要作为产品线资产来维护，在设计和实现时要保证是可配置的并 且具有灵活性，以适应末来可能出现的需求利用这些模块来构建某个新系统的情况。
从外部藉.CelsiusTech公司开发的是舰船系统。从内部看，该公司形成并发展着一个 能够生产出舰船系统的通用资产库。这听起来似乎并不明显，但在控制策略的配置、企业 的组织结构、新产品的销售方式等方面都有東要影响。
大型预集成组块的维护。在关于软件重用存储庳的经典文献中，里用的单元一般是细 粒度的小模块（如Ada包、子程序或对象)，或者是大规模的、能独立执行的子系统（如 工具或独立的商业产品）。在前•种情况下，必须对这些小模块进行组装、集成、配置、 检验和测试：而在后一种情况下，子系统的可配置性和灵活性•般比较差。
CelsiusTech公司采取的是一条中间路线。他们的重用单元是系统功能，即由来自构架 中不同层的模块组成的相关功能的集合。系统功能是可预集成的——就是说，组成功能的 模块Ll经经过了组装、连编、单独测试和整体测试。当在资产库之外检验某系统功能时， 该系统功能楚可用的。这样，CelsiusTech公司不仅实现了模块的重用.而且也实现了对集 成、模块测试和单元测试的重用，而这些工作原来对每个应用都是耍重复做的。
横块的参数化。在大多数情况下，模块的重用都不涉及代码的改变，但也并不总是如 此。许多元素在编写代码时采用了符号化的值，而并不是在各个客户系统中使用的绝对量 值。例如，某个模块内的运算可能是处理器个数的函数，但在编写该模块代码时并不需要 知道处玴器个数的具体数值。所以，该模块在编写代码时可以采用某个符号值（即参数） 来表示处理器的个数，这个值是在系统集成时要绑定参数的興体数值。在运行时该模块能 够IK确地运行，而FI在拥有不同处理器数量的另一版本的系统中不必修改代码即可直接使 用该模块。
参数是实现模块重用的简单、有效而又省时的手段。但在实践中，参数增加的数量是 惊人的。几乎任何-个模块都可以借助于参数化而提高其通用性。SS2000系统当前所采用 的模块共钉3000?5000个参数.必须对根据此产品线开发出来的每一个客户系统一个一 个地设置这些参数。CelsiusTech公司目前尚无统一的方法来避免各个参数的相互冲突，即没有用来确定某些参数值的组合应用于运行系统是否会导致非法操作状态的规范方法。
参数太多这一事实在一定程度上抵消了将大的系统功能和系统功能组作为测试和集 成的基本电元所带来的好处。在为新版本的系统设置参数时，实际上是生成了从未测试过 的一个系统版本。从理论上说.每一组参数的组合都可能使系统进入从未经历过的操作状 态，更不用说全面的测试了。
将会出现的仅仅是这些参数的诸多组合中的少数儿种-但是，如果不试着“尝试”新 的参数组合，可能会导致无法利用元素的内建的灵活性（可配置性)。
在具体实践中，这些参数带来的问题似乎主要是记录起来太过繁琐。到目前为止还没 有出现过某个错误操作完全是由于参数设置不正确而造成的。在植入某个大模块时，经常 是将其以前的参数设置直接拿来使用。
15.4小 结
在1986到1998年，CelsiusTech公司从最初提供针对客户具体猫求的解决方案的国防 承包商逐渐发展成为提供商业海军系统的厂商。在这一过程中，该公司发现老的组织结构 和符理模式不能支持新出现的商业模型。他们还发现高效的产品线的实现和维护不仅仅是 选择恰当的软件和系统构架的问题，也不仅仅是开发环境、硬件或网络的问题。公司的组 织结构、管理实践和人员特点等方面都受到了很大影响。
不管是从技术上看还是从企业文化上看，构架都是整个产品线方法的基础。从某个角 度看，构架变得更为具体，苒创建和实例化是开发的最终目标。因为非常重要。所以构架 也变得更为可见。精干的构架小组负责产品线构架.并在这一方面拥冇权力。结果是实现 了Brooks所称的构架的“概念完整性”，它对软件质量是非常重要的。
构架的确定仅仅是为奠定长期开发的基础而迈出的第一步。还必须通过原型和早期运 用来进行验证。如果发现缺陷，就必须在初始阶段及以后的开发过程中以种可控制的方 式、平滑地对构架进行演变。为了管理这一自然演变过程，CelsiusTech公司的集成小组和 构架小组共同努力，以防止任何设计人员或设计小组在未经构架小组正式许可的情况下修 改重要接口。
这一方法得到了项目管理层的全力支持，取得了良好的效果。这是因为赋f了构架小 组-定的权力。构架小组是整个设计中不可回避的权威中心。这样.就实现了对概念完整 性的维护。
负责创建产品线的部门与对产品线进行维护和改善的部门不同。管理层需要为人员、 管理、堵训和组织结构上的变化做出规划。了解多个领域并熟悉软件工程技巧的构架设计 师对多个产品线的创建至关重要。在新产品的开发及产品线的改进中仍霈耍领域专家的支持。
在CelsiusTech公司从单一系统开发模式到产品线开发模式的过渡中，还涉及到对管 理人员和技术人员的教育和培训。所有这些都是关于我们所称的构架商业周期的内容。
15.5可进一步参阅的文献
关于CelsiusTech公司向产品线的过渡有两份报告可供杏阅。份是来自软件工程研究 所的[Brownsword96],这份报告也是本章内容的基础；另份[Cederling92]则是来自
瑞典林雷平大学的论文。
15.6讨论题
(1) CelsiusTech公司所用的构架是否可能已经用于第6章中所讲的空中交通管制系 统？ CelsiusTech公司是否可能已经这样用了？有什么实质差别？
(2) CelsiusTech公司在开发SS2000的过程中先后对其管理结构做了几次调整。我们 在第7章中提到过，产品结构应该反映出项目的结构。这些调整带来了哪啤影响？
原文地址：https://www.cnblogs.com/mongotea/p/11986401.html