P20技术解决方案教学提纲.docx

P20技术解决方案教学提纲.docx

《P20技术解决方案教学提纲.docx》由会员分享，可在线阅读，更多相关《P20技术解决方案教学提纲.docx（21页珍藏版）》请在冰豆网上搜索。

P20技术解决方案教学提纲

技术解决方案（TS）

成熟度3级的工程类过程域

目的

技术解决方案（TechnicalSolution,TS）的目的，为设计、开发及实现需求的解决方案。

解决方案、设计结果及实现成品包括产品、产品组件，以及与产品相关生命周期的单一过程或适当组合的过程。

业界注释

技术解决方案过程域适用于产品架构的任何层级，且适用于所有产品、产品组件、产品相关生命周期过程。

整个过程域中，产品及产品组件的意涵也包括服务及其组件。

本过程域专注于下列事项：

•评估与选择解决方案（有时称为“设计方案”、“设计概念”或“初步设计”），满足适当的配置需求。

•对选定的解决方案开发细部设计（详细到包括制造、程序制作，或实现设计为产品或产品组件所需的信息）。

•实现设计成产品或产品组件。

基本上，这些活动相互支持。

某种程度的设计，有时相当详细，可能需要选择解决方案。

模型或试行可用来作为取得足够知识，以开发技术相关资料或一组完整需求的方法。

技术解决方案的特定实践，不仅适用于产品及产品组件，也适用于产品相关生命周期的过程。

产品相关生命周期过程的开发，与产品或产品组件的开发有关。

这种开发包括选择与定义现有过程（包含标准过程）以供使用与开发新过程。

技术解决方案过程域相关的过程，接受来自需求管理过程的产品与产品组件需求。

需求管理源自于需求开发过程的需求，将需求纳入适当的配置管理，并维护他们对先前需求的追溯性。

就维护或维运的而言，需要维护活动或重新设计的需求可能由使用者的需要或产品组件潜在的瑕疵所驱动。

新需求可能来自于操作环境的变更，这些需求在产品验证的时候，透过比较实际绩效与指定绩效而界定出不被接受的绩效落差，可以被发掘出来。

技术解决方案过程域相关的过程应用以执行维护或维运的设计工作。

相关过程域

有关需求配置、操作观念的建立及接口需求定义，请参考需求开发过程域，以获得更多信息。

有关同行审查及对产品和产品组件是否满足需求之验证，请参考验证过程域，以获得更多信息。

有关正式评估，请参考决策分析与解决方案过程域，以获得更多信息。

有关管理需求，请参考需求管理过程域，以获得更多信息。

需求管理过程域之特定实践执行时，与技术解决方案过程域的特定实践交互作用。

有关改进组织的技术，请参考组织创新与推展过程域，以获得更多信息。

特定目标及实践摘要

SG1选择产品组件解决方案

SP1.1开发备选解决方案及评选准则

SP1.2选择产品组件解决方案

SG2开发设计

SP2.1设计产品或产品组件

SP2.2建立技术相关数据

SP2.3使用准则设计接口

SP2.4执行自制、购买或再用之分析

SG3实现产品设计

SP3.1实现设计

SP3.2建立产品支持文件

各特定目标的实践

SG1选择产品组件解决方案

从备选方案中，选择产品或产品组件解决方案。

选择解决方案之前，应考虑备选解决方案及其相关优点。

建立在分析备选解决方案时所使用的关键需求、设计问题及限制条件。

架构特性提供产品改进与演进的考虑基础，并按相对成本、进度、绩效及风险，考虑是否采用现成品作为产品组件。

现成品（COTS）可直接或修改后使用，有时候这种现成品须进行接口修改或对部分特性进行客制化，以符合产品需求。

良好设计过程的指针之一，是在比较与评估各种备选解决方案后，才进行设计方案的选择。

通常在设计选择时要处理架构、客制或采用现成品及产品组件模块化的决定。

有些决策需要使用正式的评估过程。

有关正式评估过程的使用，请参考决策分析与解决方案过程域，以获得更多信息。

有时寻找解决方案，只需检查相同需求的备选实例，而不必涉及其下层产品组件的需求配置。

在产品架构的底层（组件）即为一例。

有些情况，有些方案已预先决定（例如：

某特定方案已被直接指定，或是调查可供使用的产品组件，如现成品）。

一般而言，解决方案是整套的。

亦即，在定义产品组件的下一层时，一起建立每个组件的解决方案。

备选方案不单是对同一需求的不同处理方式，也反映需求配置于组件，构成解决方案的不同思考。

此处的目标是将整体的解决方案优化，而非个别设计的优劣。

因此，与需求开发过程域有密切互动，以支持产品需求暂时性的配置到各产品组件，直至选定解决方案并建立“最终”配置。

产品组件解决方案是由备选解决方案所选出，而产品相关的生命周期过程就在这些产品组件解决方案之中。

例如：

制造、交付与支持过程就是产品相关的生命周期过程。

SP1.1开发备选解决方案及评选准则

开发备选解决方案及评选准则。

有关取得将需求配置到产品组件的备选解决方案，请参考需求开发过程域中，配置产品组件需求指定实践，以获得更多信息。

有关建立用于决策的准则，请参考决策分析与解决方案过程域，以获得更多信息。

IPPD补充

选择备选解决方案的活动以及决策分析与替代方案研究的议题，都需要相关干系人的参与。

这些干系人代表经营与技术功能，以及同步开发的产品与产品相关的生命周期过程（例如：

制造、支持、培训、验证及销毁）。

以此方式，重要的议题在产品开发的早期就会浮现出来，并在这些议题变成高成本的错误之前就予以处理。

需要界定及分析备选解决方案，以便就成本、进度及绩效，选择最均衡的解决方案。

这些解决方案，是以已建议的产品架构为基础，来说明关键产品品质，以及扩展可行解决方案的设计空间。

“开发与设计”特定目标的特定实践，提供更多关于开发可能的产品架构，使其能结合产品备选解决方案的信息。

备选解决方案通常包含将备选需求配置到不同的产品组件。

这些备选解决方案在产品架构中，也包括现成品解决方案的使用。

与需求开发过程域相关的过程，也可用于提供更完整及健全的临时性需求配置到备选解决方案。

备选解决方案涵盖可接受的成本、进度及绩效的范围。

产品组件需求与设计问题、限制及准则一起用于开发备选解决方案。

评选准则通常必须强调成本（例如：

时间、人员、费用）、效益（例如：

绩效、性能、有效性）及风险（例如：

技术、成本及进度）。

详细的备选解决方案及评选准则的考虑因素可包括下列：

•成本（开发、制造、购买、维护及支持）

•绩效

•产品组件及产品相关生命周期过程的复杂度

•对产品操作与使用条件、操作模式、环境及产品相关生命周期过程变异的坚固程度

•产品扩充性与成长性

•技术界限

•建造方法及材料的敏感度

•风险

•需求与技术的演进

•废弃

•最终使用者与操作者的能力与界限

•现成品的特性

这里所列为最基本的考虑因素。

组织应开发与经营目标一致的备选方案筛选准则，以缩小备选清单。

产品生命周期的成本期望能越小越好，但常非开发组织所能控制。

客户可能不愿支付短期内较高成本，来换取最终会随着产品生命周期而降低成本的功能。

在此情况下，至少应提醒客户，任何会降低生命周期成本的潜在机会。

用来选择最终解决方案的准则须提供成本、效益及风险之间的平衡方法。

典型的工作产品

1.备选解决方案筛选准则

2.新技术的评估报告

3.备选解决方案

4.最终选择的评选准则

5.现成品的评估报告

子实践

1.界定筛选准则，以作为选择备选解决方案的考虑因素

2.界定现有技术与具竞争优势的新产品技术

有关改进组织技术，请参考组织创新与推展过程域，以获得更多信息。

应界定应用于现有产品及过程的技术，并在整个生命周期，监督目前使用技术的进展。

应界定、选择、评估及投资新技术，以获得竞争优势。

备选解决方案可包括新开发的技术，但亦可包括不同应用的成熟技术或维持现有方法。

3.界定能满足需求的备选现成品

有关评估供货商，请参考供货商管理过程域，以获得更多信息。

这些需求包括下列：

•功能性、绩效、质量及可靠性

•产品保证书的条款

•风险

•供货商对后续的产品维护及支持的责任

4.产生备选方案

5.取得每一备选解决方案的完整需求配置。

6.开发选择最佳备选解决方案的准则。

准则应包括产品生命周期设计问题的处理，例如：

易于加入新技术或利用商用产品的能力等。

例如：

与开放式设计或开放架构概念有关的准则，都应列入评估。

SP1.2选择产品组件解决方案

选择最能满足所建立准则之产品组件解决方案。

有关建立产品组件的配置需求及产品组件间之接口需求，请参考需求开发过程域之“配置产品组件需求”及“界定接口需求”等特定实践，以获得更多信息。

选择最能满足准则的产品组件，即建立需求配置给产品组件。

低阶需求的产生来自于备选方案的选择，并用来开发产品组件的设计。

主要以功能性的观点描述产品组件间的接口需求。

文件中也包含产品对外活动及的实体接口描述。

记录方案的描述及选择理由。

在开发过程中，渐进开发技术相关资料为技术解决方案及开发详细设计，并实现设计。

维护选择理由的纪录对后续的决策十分重要。

这种纪录可使后续的干系人免于返工，也可在某些适用的应用环境下，提供对技术应用的深入见解。

典型的工作产品

1.产品组件选择决策及理由

2.需求及产品组件间相关性的纪录

3.解决方案、评估及理由的纪录

子实践

1.依据操作概念、操作方式及操作状态所建立的评选准则，评估各备选解决方案/解决方案组。

针对每一个备选解决方案，开发产品操作及使用者互动的时序场景。

2.依据备选解决方案的评估，评量评选准则之适用性，必要时，更新准则。

3.界定并解决与备选技术方案及需求有关的议题。

4.选择能满足已建立之评选准则的最佳解决方案。

5.建立与所选择之备选方案关联的需求，此即为该产品组件的配置需求。

6.界定将再用或取得的产品组件解决方案。

有关取得产品及产品组件，请参考供货商协议管理过程域，以获得更多信息。

7.建立并维护解决方案、评估及理由的文件。

SG2开发设计

开发产品或产品组件的设计。

产品或产品组件的设计，必须提出适当的内容，这不仅是为了实现，也是为了产品生命周期阶段，如修正、重新采购、维护、维持及安装。

设计文件提供相关的干系人，对于设计的相互了解之参考，并在产品的开发与后续的生命周期阶段，支持未来设计上的改变。

完整的设计描述，记录于技术相关数据中，该相关数据含有格式、安装、功能、介面、制造过程特性及其它参数等完整的特征与参数。

已建立的组织或的设计标准（例如：

检查清单、样板、对象架构），形成达成高度定义与完整性之设计文件的基础。

IPPD补充

整合团队在设计产品的同时，也设计适当的产品相关的生命周期过程。

适当时，这些过程可挑选自组织标准过程且不经修改。

SP2.1设计产品或产品组件

开发产品或产品组件的设计。

产品设计包含两阶段，在执行上可能相互重叠：

初步设计与细部设计。

初步设计建立产品功能与架构，包含产品组成区块、产品组件界定、系统状态与模式、主要的内部接口，以及外部产品接口。

细部设计完整的定义产品组件的结构与功能。

有关开发架构需求，请参考需求开发过程域，以获得更多信息。

架构定义由需求开发过程的开发架构需求而来。

这些需求代表产品成功的关键质量与效能。

当建立细部产品设计时，架构定义结构化元素与协调的机制，使其直接满足需求或支持需求的达成。

架构包含标准与设计规则，用来管理产品组件的开发与介面，就像能帮助产品开发者的指引一样。

“选择产品组件解决方案”特定目标的特定实践中，包含更多关于使用产品架构作为备选解决方案基础的信息。

架构师设定并开发产品的模式，对产品组件所包含的软硬件做需求配置的判断。

多个支持备选解决方案的架构，经开发与分析以找出针对架构需求的优缺点。

操作概念与场景用来产生作为细化架构的使用案例与质量场景。

它们也用来评估架构的合适性，以满足架构评估期间的期望目标，并在产品设计过程中定期地执行。

有关开发用来作为架构评估的操作概念与场景，请参考需求开发过程域之“建立操作概念及场景”特定实践，以获得更多信息。