CMMI2.0：技术解决方案TS&产品集成PI

技术解决方案（TS)

技术解决方案（TS）主要目的是设计和构建满足客户需求的解决方案，可以通过以下方式来设计和构建满足客户、功能和质量需求的解决方案：制定、评估和选择高效的设计方案；构建足够详细的设计来支持选定的设计方案的实施；将设计作为产品、服务或组件来实现。其主要过程会涉及设计方案的评价和选择，编制详细的设计说明书等，最终目的是通过编码来实现整个设计方案的内容，这些工作会贯穿整个解决方案的全过程。

它的特定实践不仅适用于产品或产品部件，也适用于服务和与产品相关的生存期过程。为了确保产品相关的生存期过程与产品或产品部件协同开发，这类开发可能包括选择并采用现有的过程以及开发新的过程。

从开始的需求管理过程接收产品与产品部件的需求，然后进行具体的，多维度的技术解决方案设计。技术解决方案实践域的过程也会被用于执行维护或支持方面的设计工作，从维护或支持组织角度看，维护活动或者设计等方面的需求主要来自用户的需要或者历史产品潜在的问题。

何为解决方案？解决方案可以是一系列的交付物，也可以是一个产品、一套系统或某种服务等。我们在实现产品或服务之前，一定会经历设计这个步骤。设计包含了概要设计、详细设计等。概要设计主要侧重于各产品部件之间的关系，详细设计主要侧重于每个部件内部的实现方法。

交付给用户后，用户如何使用交付的产品，需要有安装手册、使用手册、在线帮助、培训资料等，在技术解决方案这个实践中要求编写、交付这些使用标准和指南，对设计进行评审，并修改发现的问题。设计决策的准则指的就是评价设计方案优劣的评价指标、评价方法。

我们在实际工作中经常会遇到这些问题，例如：当存在多种技术路线、技术方案时，对这些技术方案要从哪些方面进行评价？怎么评价？这个实践域就对产品构件的实现方法进行宏观诠释。再如：某些产品构件，是自己从头开发？还是直接从市场上购买成熟的产品？或者复用历史项目已经实现的成品或组件等？或者是使用开源的构件？在这里也给出了科学的指导。  

在整体设计过程中，执行思路可以参照WBS分解，把系统拆分成子系统，子系统拆分为模块后，实现每个模块所需要的设计信息并按模块进行分类存放，这样便于执行者快速检索到所需要的所有信息，也不会存在信息污染，即你能看到你想看到的，而与你无关的内容不会出现在眼前。当实现的系统比较庞大，设计文档比较多时，这个实践的价值就变得尤其突出。

如何找出最合适的设计方案？我们很多开发人员，coding之前一般都不喜欢认真研读设计方案，经常会迫于进度和时间的压力，不仔细考虑设计方案是否合适，甚至有些组织根本就没有使用设计方案，就直接开展工作，这样做的风险是非常大，后期返工的工作量也很大，最终得不偿失。

很多人可能有这样的疑问，有的项目比较简单，规模和工作量都属于小规模的，或者设计方案很明确，没有必要执行候选方案和选择标准，直接设计就可以了。这里解释一下，设计方案的要求除了针对整个项目的大的设计方案，还包括组成产品的各个组件的设计方案。绝大部分情况下，不管项目大小，或多或少一定有部分技术不太明确是需要仔细分析的。

另外，不管大小规模的项目，从标准流程上来讲都应该根据项目的实际情况，定出这个项目的设计标准，就算只有一个方案，也需要用该设计标准来检验该方案。所以大部分情况下，认为不需要考虑多个设计方案、不考虑设计标准，都是给项目后续增加风险和问题埋下伏笔。

在项目实施过程中，我们需要尽早地进行解决方案的探索和思考。通过明确地选择并进行决策的权衡，技术解决方案实践域有助于提高决策的质量，有助于项目全生命流程包括，计划，需求，设计，编码，测试等活动的顺利开展，集思广益，运筹帷幄！

产品集成（PI）

产品集成（PI）简单理解就是把不同部件集成在一起，形成一个更大的部件或一个完整的可交付的产品。这个实践域包含了集成策略的制定、集成准备、集成中、集成后的验证与确认、以及交付的活动。其核心内容包含了：集成的频率、集成的方法、集成的顺序等，最终就是解决如何将产品组件集成为更复杂的产品组件或者完整的产品，这个是产品集成这个实践域的精髓。

产品集成的目的是组合产品组件最终形成产品，并要确保已集成的产品是符合用户和设计需要的。CMMI对该实践提供了进一步的描述，在产品集成过程中我们需要注意的是产品集成出来的部件不一定就是最终的产品，也可能是项目过程中某一个中间的组件，重要的是集成出来的产品或组件要符合用户和相关设计文档的要求。

在产品集成活动中，我们应该在尽可能的情况下将产品集成的工作日常化、自动化，这样做的好处是可以尽早发现产品集成时由于各种接口问题所带来的风险，而且可以使项目团队成员对整体项目的进展有所了解。

在实际的工作中，很多软件技术人员并不清楚软件产品集成是做什么的，在什么时候可以进行产品的集成。产品集成对很多软件开发和测试人员来说是既熟悉又陌生的，熟悉是因为产品集成的概念经常被提及，经常也会参与相关的一些培训，陌生是因为在实际项目中产品集成的过程被分的并不显著，所以在实际工作中的感受不深。

我们虽然可以形象地把产品集成看作是电脑组装的过程，在电脑的各个模板准备就绪之后，根据先后多次的反复拼接和测试，最终变成成品的过程。但是，产品集成远远不只是在设计与开发完成时将产品组件一次性地装配起来，产品集成可以采用装配产品组件、进行测试，然后装配更多产品组件的重复过程增量式地进行，也能采用对经过完整单元测试的产品，进行高度自动化的构建与持续集成来进行。

重点在于一步一个脚印，就跟建房子一样，确保每一步都夯实，直至完成最终的成品。在每一次连续的构建中，功能和功能组件得到构筑、测试、改进以及基于测试过程反馈进行的重构。

其次，我想说的是：产品集成的活动与集成测试都是相互关联的， 产品集成的规程即产品集成与测试的具体方法与步骤，包括手工集成的步骤，自动集成的脚本，集成测试的步骤与用例。产品集成的准则包括集成准备就绪的准则、集成测试的用例与通过准则等。

在组装之前，确认每个部件都依据其需求和设计被正确地标识了并能正常运行。检查集成的准备情况：例如：待集成的部件是否经过了评审或单元测试？执行集成测试以确保集成后的产品部件或产品符合需求与设计。该活动是持续、反复执行的，每次集成后都要进行测试。最后持续集成是目前行业的最佳实践之一，强烈建议各公司搭建自己的持续集成平台，自动化集成，执行集成测试以确保集成后的产品部件或产品符合需求与设计。

下面说一下产品集成中的接口管理。产品集成的一个重要方面是管理产品与产品组件的内部与外部接口，以确保接口间的兼容性。这些接口并不局限于用户界面，也适用于产品组件之间的接口，包括内部与外部的数据源、中间件以及其它组件——它们可能受到或不受到开发组织的控制，但是产品会依赖着它们，因此我们在项目过程中应始终关注接口管理，每次集成后都要同步进行测试接口，包括外部接口，内部接口。同时，在项目的全生命周期内要进行接口的管理，有接口需求、接口设计，要评审接口需求、接口设计，发生变更时，要保持各描述的一致。

产品集成是软件开发日常性的工作，是与软件开发和测试人员息息相关的基础性工作，也是常规性工作，这就更需要相关人员在平时的工作中加强沟通和联系，真正的做到你中有我，我中有你！  

————————————————

作者：赛希咨询 

出处：https://www.bilibili.com/read/cv17189425/ 

声明：本文系转载，文章版权归原文作者所有，如有疑问，请联系删除。