P20-技术解决方案(共20页).doc

精选优质文档-倾情为你奉上技术解决方案(TS)成熟度3级的工程类过程域目的技术解决方案(Technical Solution, TS) 的目的，为设计、开发及实现需求的解决方案。解决方案、设计结果及实现成品包括产品、产品组件，以及与产品相关生命周期的单一过程或适当组合的过程。业界注释技术解决方案过程域适用于产品架构的任何层级，且适用于所有产品、产品组件、产品相关生命周期过程。整个过程域中，产品及产品组件的意涵也包括服务及其组件。本过程域专注于下列事项： 评估与选择解决方案(有时称为“设计方案”、“设计概念”或“初步设计”)，满足适当的配置需求。 对选定的解决方案开发细部设计(详细到包括制造、程序制作，或实现设计为产品或产品组件所需的信息)。 实现设计成产品或产品组件。基本上，这些活动相互支持。某种程度的设计，有时相当详细，可能需要选择解决方案。模型或试行可用来作为取得足够知识，以开发技术相关资料或一组完整需求的方法。技术解决方案的特定实践，不仅适用于产品及产品组件，也适用于产品相关生命周期的过程。产品相关生命周期过程的开发，与产品或产品组件的开发有关。这种开发包括选择与定义现有过程(包含标准过程)以供使用与开发新过程。技术解决方案过程域相关的过程，接受来自需求管理过程的产品与产品组件需求。需求管理源自于需求开发过程的需求，将需求纳入适当的配置管理，并维护他们对先前需求的追溯性。就维护或维运的而言，需要维护活动或重新设计的需求可能由使用者的需要或产品组件潜在的瑕疵所驱动。新需求可能来自于操作环境的变更，这些需求在产品验证的时候，透过比较实际绩效与指定绩效而界定出不被接受的绩效落差，可以被发掘出来。技术解决方案过程域相关的过程应用以执行维护或维运的设计工作。相关过程域有关需求配置、操作观念的建立及接口需求定义，请参考需求开发过程域，以获得更多信息。有关同行审查及对产品和产品组件是否满足需求之验证，请参考验证过程域，以获得更多信息。有关正式评估，请参考决策分析与解决方案过程域，以获得更多信息。有关管理需求，请参考需求管理过程域，以获得更多信息。需求管理过程域之特定实践执行时，与技术解决方案过程域的特定实践交互作用。有关改进组织的技术，请参考组织创新与推展过程域，以获得更多信息。特定目标及实践摘要SG 1 选择产品组件解决方案SP 1.1 开发备选解决方案及评选准则SP 1.2 选择产品组件解决方案SG 2 开发设计SP 2.1 设计产品或产品组件SP 2.2 建立技术相关数据SP 2.3 使用准则设计接口SP 2.4 执行自制、购买或再用之分析SG 3 实现产品设计SP 3.1 实现设计SP 3.2 建立产品支持文件各特定目标的实践SG 1选择产品组件解决方案从备选方案中，选择产品或产品组件解决方案。选择解决方案之前，应考虑备选解决方案及其相关优点。建立在分析备选解决方案时所使用的关键需求、设计问题及限制条件。架构特性提供产品改进与演进的考虑基础，并按相对成本、进度、绩效及风险，考虑是否采用现成品作为产品组件。现成品(COTS)可直接或修改后使用，有时候这种现成品须进行接口修改或对部分特性进行客制化，以符合产品需求。良好设计过程的指针之一，是在比较与评估各种备选解决方案后，才进行设计方案的选择。通常在设计选择时要处理架构、客制或采用现成品及产品组件模块化的决定。有些决策需要使用正式的评估过程。有关正式评估过程的使用，请参考决策分析与解决方案过程域，以获得更多信息。有时寻找解决方案，只需检查相同需求的备选实例，而不必涉及其下层产品组件的需求配置。在产品架构的底层(组件)即为一例。有些情况，有些方案已预先决定(例如：某特定方案已被直接指定，或是调查可供使用的产品组件，如现成品)。一般而言，解决方案是整套的。亦即，在定义产品组件的下一层时，一起建立每个组件的解决方案。备选方案不单是对同一需求的不同处理方式，也反映需求配置于组件，构成解决方案的不同思考。此处的目标是将整体的解决方案优化，而非个别设计的优劣。因此，与需求开发过程域有密切互动，以支持产品需求暂时性的配置到各产品组件，直至选定解决方案并建立“最终”配置。产品组件解决方案是由备选解决方案所选出，而产品相关的生命周期过程就在这些产品组件解决方案之中。例如：制造、交付与支持过程就是产品相关的生命周期过程。SP 1.1开发备选解决方案及评选准则开发备选解决方案及评选准则。有关取得将需求配置到产品组件的备选解决方案，请参考需求开发过程域中，配置产品组件需求指定实践，以获得更多信息。有关建立用于决策的准则，请参考决策分析与解决方案过程域，以获得更多信息。IPPD 补充选择备选解决方案的活动以及决策分析与替代方案研究的议题，都需要相关干系人的参与。这些干系人代表经营与技术功能，以及同步开发的产品与产品相关的生命周期过程 (例如：制造、支持、培训、验证及销毁)。以此方式，重要的议题在产品开发的早期就会浮现出来，并在这些议题变成高成本的错误之前就予以处理。需要界定及分析备选解决方案，以便就成本、进度及绩效，选择最均衡的解决方案。这些解决方案，是以已建议的产品架构为基础，来说明关键产品品质，以及扩展可行解决方案的设计空间。“开发与设计”特定目标的特定实践，提供更多关于开发可能的产品架构，使其能结合产品备选解决方案的信息。备选解决方案通常包含将备选需求配置到不同的产品组件。这些备选解决方案在产品架构中，也包括现成品解决方案的使用。与需求开发过程域相关的过程，也可用于提供更完整及健全的临时性需求配置到备选解决方案。备选解决方案涵盖可接受的成本、进度及绩效的范围。产品组件需求与设计问题、限制及准则一起用于开发备选解决方案。评选准则通常必须强调成本(例如：时间、人员、费用)、效益(例如：绩效、性能、有效性)及风险 (例如：技术、成本及进度)。详细的备选解决方案及评选准则的考虑因素可包括下列： 成本(开发、制造、购买、维护及支持) 绩效 产品组件及产品相关生命周期过程的复杂度 对产品操作与使用条件、操作模式、环境及产品相关生命周期过程变异的坚固程度 产品扩充性与成长性 技术界限 建造方法及材料的敏感度 风险 需求与技术的演进 废弃 最终使用者与操作者的能力与界限 现成品的特性这里所列为最基本的考虑因素。组织应开发与经营目标一致的备选方案筛选准则，以缩小备选清单。产品生命周期的成本期望能越小越好，但常非开发组织所能控制。客户可能不愿支付短期内较高成本，来换取最终会随着产品生命周期而降低成本的功能。在此情况下，至少应提醒客户，任何会降低生命周期成本的潜在机会。用来选择最终解决方案的准则须提供成本、效益及风险之间的平衡方法。典型的工作产品1.备选解决方案筛选准则2. 新技术的评估报告3. 备选解决方案4. 最终选择的评选准则5. 现成品的评估报告子实践1. 界定筛选准则，以作为选择备选解决方案的考虑因素2.界定现有技术与具竞争优势的新产品技术有关改进组织技术，请参考组织创新与推展过程域，以获得更多信息。应界定应用于现有产品及过程的技术，并在整个生命周期，监督目前使用技术的进展。应界定、选择、评估及投资新技术，以获得竞争优势。备选解决方案可包括新开发的技术，但亦可包括不同应用的成熟技术或维持现有方法。3.界定能满足需求的备选现成品有关评估供货商，请参考供货商管理过程域，以获得更多信息。这些需求包括下列： 功能性、绩效、质量及可靠性 产品保证书的条款 风险 供货商对后续的产品维护及支持的责任4. 产生备选方案5. 取得每一备选解决方案的完整需求配置。6. 开发选择最佳备选解决方案的准则。准则应包括产品生命周期设计问题的处理，例如：易于加入新技术或利用商用产品的能力等。例如：与开放式设计或开放架构概念有关的准则，都应列入评估。SP 1.2选择产品组件解决方案选择最能满足所建立准则之产品组件解决方案。有关建立产品组件的配置需求及产品组件间之接口需求，请参考需求开发过程域之“配置产品组件需求”及“界定接口需求”等特定实践，以获得更多信息。选择最能满足准则的产品组件，即建立需求配置给产品组件。低阶需求的产生来自于备选方案的选择，并用来开发产品组件的设计。主要以功能性的观点描述产品组件间的接口需求。文件中也包含产品对外活动及的实体接口描述。记录方案的描述及选择理由。在开发过程中，渐进开发技术相关资料为技术解决方案及开发详细设计，并实现设计。维护选择理由的纪录对后续的决策十分重要。这种纪录可使后续的干系人免于返工，也可在某些适用的应用环境下，提供对技术应用的深入见解。典型的工作产品1. 产品组件选择决策及理由2. 需求及产品组件间相关性的纪录3. 解决方案、评估及理由的纪录子实践1. 依据操作概念、操作方式及操作状态所建立的评选准则，评估各备选解决方案/解决方案组。针对每一个备选解决方案，开发产品操作及使用者互动的时序场景。2. 依据备选解决方案的评估，评评选准则之适用性，必要时，更新准则。3. 界定并解决与备选技术方案及需求有关的议题。4. 选择能满足已建立之评选准则的最佳解决方案。5. 建立与所选择之备选方案关联的需求，此即为该产品组件的配置需求。6. 界定将再用或取得的产品组件解决方案。有关取得产品及产品组件，请参考供货商协议管理过程域，以获得更多信息。7. 建立并维护解决方案、评估及理由的文件。SG 2 开发设计开发产品或产品组件的设计。产品或产品组件的设计，必须提出适当的内容，这不仅是为了实现，也是为了产品生命周期阶段，如修正、重新采购、维护、维持及安装。设计文件提供相关的干系人，对于设计的相互了解之参考，并在产品的开发与后续的生命周期阶段，支持未来设计上的改变。完整的设计描述，记录于技术相关数据中，该相关数据含有格式、安装、功能、介面、制造过程特性及其它参数等完整的特征与参数。已建立的组织或的设计标准(例如：检查清单、样板、对象架构)，形成达成高度定义与完整性之设计文件的基础。IPPD 补充整合团队在设计产品的同时，也设计适当的产品相关的生命周期过程。适当时，这些过程可挑选自组织标准过程且不经修改。SP 2.1设计产品或产品组件开发产品或产品组件的设计。产品设计包含两阶段，在执行上可能相互重叠：初步设计与细部设计。初步设计建立产品功能与架构，包含产品组成区块、产品组件界定、系统状态与模式、主要的内部接口，以及外部产品接口。细部设计完整的定义产品组件的结构与功能。有关开发架构需求，请参考需求开发过程域，以获得更多信息。架构定义由需求开发过程的开发架构需求而来。这些需求代表产品成功的关键质量与效能。当建立细部产品设计时，架构定义结构化元素与协调的机制，使其直接满足需求或支持需求的达成。架构包含标准与设计规则，用来管理产品组件的开发与介面，就像能帮助产品开发者的指引一样。“选择产品组件解决方案”特定目标的特定实践中，包含更多关于使用产品架构作为备选解决方案基础的信息。架构师设定并开发产品的模式，对产品组件所包含的软硬件做需求配置的判断。多个支持备选解决方案的架构，经开发与分析以找出针对架构需求的优缺点。操作概念与场景用来产生作为细化架构的使用案例与质量场景。它们也用来评估架构的合适性，以满足架构评估期间的期望目标，并在产品设计过程中定期地执行。有关开发用来作为架构评估的操作概念与场景，请参考需求开发过程域之“建立操作概念及场景”特定实践，以获得更多信息。定义架构的工作，举例如下：· 建立功能区块的结构化关联，与功能区块内的元件以及功能区块间的接口规则· 建立软件主要的内部接口与外部接口· 界定产品组件及其之间的接口· 定义协调机制(例：针对软件及硬件)· 建立基础建设的能力与服务· 开发产品组件样板或类别与框架· 建立设计规则与授权，以制定决策· 定义过程/执行绪的模式· 定义软件到硬件的实际部署· 界定主要再用的方法与资源在细部设计期间，完成产品架构的细节、完整定义产品组件，以及完整描述接口。产品组件的设计可能针对某些质量或效能特性而进行优化。设计者可评估既有产品或现成品，以作为产品组件。当设计成熟时，追踪需求(该需求已指定给较低阶的产品组件)，以确保这些需求已满足。有关追踪产品组件需求，请参考需求管理过程域，以获得更多信息。软件工程适用细部设计专注于软件产品组件的开发。定义产品组件的内部结构、产生数据纲要、开发算法及建立启发法，使得产品组件功能满足所配置的需求。硬件工程适用细部设计专注于电子、机械、光电，及其它硬件产品及其组件的产品开发。开发电子概图及电路图、产生机械及光学封装模式，并开发制造及封装过程。典型的工作产品1. 产品架构2. 产品组件设计子实践1. 建立并维护准则，以评估设计。除预期的效能外，用以建立设计准则的属性，举例如下：· 模块化· 清晰· 简单· 可维护· 可验证· 可移植性· 可靠性· 准确性· 安全· 可扩充· 可使用2. 界定、开发或取得适合于产品的设计方法。有效的设计方法能具体表现大范围的活动、工具及描述的技术。方法是否有效，视情况而定。两家公司在他们所专长的产品上，或许都有非常有效的设计方法，但是这些方法在合作上也许就不那么有效。复杂度高的方法，对未经培训的设计者而言，就未必是有效的方法。方法是否有效，也要看它能提供设计者多少的协助，以及其成本效益。例如：一个需要多年时间的模型设计，可能不适用于简单的产品组件，但在开发无前例可循、昂贵及复杂的产品时，却可能会是最佳选择。使用工具的方法是非常有效的，因工具可确保设计将包括所有必要实现产品组件设计的属性。例如：设计工具“知道”制造过程的能力，在设计的容忍误差中说明制造过程的差异。增进有效设计的技术与方法，举例如下：· 模型法· 结构化模式· 对象导向设计· 精实系统分析· 实体关联模式(E-R models)· 设计再用· 设计样式3. 确保设计遵循所应用的设计标准与准则。设计标准的范例，举例如下(部分或全部的“标准”可能是设计准则，特别是标准尚未建立时)：· 操作人员接口标准· 测试脚本· 安全标准· 设计限制(例：电磁兼容性、讯号完整性及环境面)· 生产限制· 设计的容忍范围· 零件标准(如生产的废弃物与废品)4. 确保设计遵循已配置的需求。必须考虑已界定的现成品组件。例如：将现有产品组件放入产品架构可能会修改需求与需求的配置。5. 记录设计。SP 2.2建立技术相关数据建立并维护技术相关数据。技术相关数据提供开发者在开发产品或产品组件时，周详的描述。该数据在各种情况下，也提供采购的弹性。例如以绩效为主的合约或依设计图建造。设计结果记录于技术相关数据中。在初步设计期间产生技术相关数据，以记录架构定义。在整个产品生命周期中必须维护技术相关数据，以记录必要的产品设计细节。技术相关数据提供产品或产品组件的说明(包含未视为个别产品组件之产品相关生命周期过程)，以支持产品取得策略，或产品生命周期的实现、生产、工程及后勤支持阶段。这些说明包含必要的设计配置定义与程序，以确保产品或产品组件应有的效能。它包含所有可用的技术数据，例如：绘图、相关清单、规格、设计描述、设计数据库、标准、效能需求、提供的质量保证及组装细节。技术相关数据包含用来实现之已选定的备选解决方案。若该信息适合产品或产品组件的型态(例如：原料与制造需求，对软件服务或过程相关的产品组件可能没有帮助)，技术相关数据应包含下列信息：· 产品架构描述· 已配置的需求· 产品组件描述· 产品相关生命周期过程描述，如未描述于个别产品组件· 关键产品特性· 必要的实体特性与限制· 接口需求· 原料需求(原料清单与原料特性)· 建造及制造需求(针对原先的设备制造商与现场支援)· 用来确保达成需求的验证准则· 整个产品生命周期中的使用条件(环境)和操作/使用场景、操作的方式与状态、支持、培训、制造、废弃及验证· 决定的理由与特性(需求、需求配置及设计选择)由于设计说明包含大数据，且这些数据对产品组件成功的开发可能是关键，因此建议要建立组织资料与选择数据内容的准则。使用产品架构来组织资料与抽象化观点，使得感兴趣的议题或特性能以清晰与切题的方式呈现，是一个特别有用的方法。这些观点包含：· 客户· 需求· 环境· 功能· 逻辑· 安全性· 资料· 状态/模式· 结构· 管理这些观点都记录在技术相关数据中。典型的工作产品1. 技术相关资料子实践1. 决定设计阶层数目及每一设计阶层文件的适当阶层。决定需要以文件记录与执行需求追溯之产品组件阶层的数目(例如：子系统、硬件配置、电路板、计算机软件配置、计算机软件产品组件、计算机软件单元)，对管理文件成本与支持整合及验证计划都非常重要。2. 已配置的产品组件需求、架构及较高阶的设计为基础，执行细部设计。3. 记录设计数据于技术相关数据中。4. 记录关键(例如：对成本、进度或技术绩效有重要影响)决策或定义的理由。5. 必要时修改技术相关资料。SP 2.3使用准则设计接口使用已建立的准则来设计产品组件接口。接口设计包含下列：· 起源· 终点· 软件的影响事件与数据特性· 硬件的电子、机械与功能特性· 沟通的服务管道接口准则经常反映出周详的重要参数清单。必须定义这些参数，或最起码要进行调查，以确保其适用性。这些参数通常是某特定产品的特性(如软件、机械的、电子的、服务)，并常与安全、保密、耐久性及任务的关键特性有关。有关界定产品及产品组件接口需求，请参考需求开发过程域中，界定接口需求的特定实践，以获得更多信息。典型的工作产品1. 接口设计规格2. 接口控制文件3. 接口规格准则4. 所选之接口设计的理由子实践1. 定义接口准则。这些准则可以是组织过程资产的一部分。有关建立并维护组织过程资产，请参考组织过程定义过程域，以获得更多信息。2. 界定与其它产品组件相关的接口。3. 界定与外部相关的接口。4. 界定介于产品组件与产品相关生命周期过程的介面。举例来说，这接口可包括所制造的产品组件与制造过程中用于组装的配件间的接口。5. 应用准则于接口设计的备选方案。有关界定准则与依据准则来选择备选方案，请参考决策分析与解决方案过程域，以获得更多资讯。6. 记录已选取的接口设计与理由。SP 2.4执行自制、购买或再用之分析根据已建立的准则，评估产品组件是要开发、购买或再用。决定要取得哪些产品或产品组件，通常称为“自制或采购分析”，通常是以需求的分析为基础。自制或采购分析从早期的设计开始，在设计过程阶段持续进行，完成时，决定产品要自行开发、由外部取得或再用。有关决定产品或产品组件的需求，请参考需求开发过程域，以获得更多信息。有关管理需求，请参考需求管理过程域，以获得更多信息。影响自制或购买决策的因素包含如下：· 产品所提供的功能以及这些功能如何符合的需要· 可用的资源与技术· 内部自行开发与外购的成本比较· 关键的交付日期与整合日期· 策略联盟，包含高阶的经营需求· 可用产品的市场分析，包含现成品· 可用产品的功能与质量· 潜在供货商的技能与能力· 对核心竞争力的影响· 有关外购产品的授权、保证书、权责及界限· 产品可用性· 所有权议题· 风险降低可使用正式评估方法以进行自制或购买的决策。有关定义准则及备选方案，以及执行正式评估，请参考决策分析与解决方案过程域，以获得更多资讯。一如技术的渐进开发，选择开发或采购产品组件的理由也是一样。虽然复杂的开发工作会使大家倾向于购买现成品，但生产力与工具的进步，却又会使大家抱持相反的看法。现成品的文件可能不够完整或正确，而且在将来未必会提供支持。一旦决定购买现成的产品组件，其需求就用以建立供货商协议。有时，所谓“现成品”在目前的市场也可能缺货。例如：某种型号的飞机或引擎等，它们并非真正的现成品，但随时可以制造。在某些情况，这类非开发的使用，是因为绩效上的特殊理由，还有其它产品特性上的限制。在这种情况下，需求与验收准则就必须包含在供货商协议中，并加以管理。在其它的状态下，现成品就如它们字面上的意思一样(如字处理软件)，供货商并没有需要被管理的协议。有关如何说明产品组件的取得，以便执行采购，请参考供货商协议管理过程域，以获得更多信息。典型的工作产品1. 设计与产品组件再用的准则2. 自制或采购分析3. 选择现成品组件的指引子实践1. 开发产品组件设计再用的准则。2. 分析设计以决定产品组件要自行开发、再用或采购。3. 当采购或选择非开发的(现成品、政府的成品及再用)时，分析维护所隐藏的代价。维护的涵义，举例如下：· 与未来现成品的发行有兼容性· 供货商变更的配置管理· 非开发性的缺失与其解决方案· 非计划性的废置SG 3实现产品设计依照设计，实现产品组件及相关的支持文件。从“开发设计”特定目标的特定实践所建立的设计，实现产品组件。实现工作通常包括产品整合及终端使用者文件制作前，所需的产品组件单元测试。SP 3.1实现设计实现产品组件设计。一旦完成产品设计，接着就是将之实现为产品组件。实现的特性与产品组件的种类有关。产品阶层最高阶设计的实现，包含下一阶每个产品组件的规格。此活动包含配置、细化及验证每一产品组件。同时也涉及多样的产品组件开发工作间的协调。有关需求的配置与细化，请参考需求管理过程域，以获得更多信息。有关接口管理与产品及产品组件的整合，请参考产品整合过程域，以获得更多信息。实现的特性，举例如下：· 已撰写程序代码。· 数据已文件化。· 服务已文件化。· 电子及机械零件已制造。· 产品独特的制造过程已放入实际作业中。· 过程已文件化。· 设施已建造。· 原料已生产(例如：一项产品特有的原料可能是一种石油、燃料油、润滑油，或是一种新的合金)。典型的工作产品1. 已实现的设计子实践1. 使用有效的方法实现产品组件。软件工程适用软件程序制作的方法，举例如下：· 结构化程序设计· 对象导向程序设计· 自动化产生程序代码· 软件程序代码再用· 使用合适的设计模式硬件工程适用硬件制造方法，举例如下：· 闸门层级组合· 电路版设计（位置及路线）· 计算机辅助设计图· 事后设计模拟· 制造方法2. 遵循适当的标准与准则。实现制作的标准，举例如下：· 程序语言标准(例：软件程序语言标准及硬件描述语言)· 绘图需求· 标准零件清单· 制造零件· 软件组件的结构及阶层· 过程及质量标准制作的准则，举例如下：· 模块化· 明确· 简单· 可靠性· 安全性· 可维护性3. 对选定的产品组件，执行同行审查。有关执行同行审查，请参考验证过程域，以获得更多信息。4. 适当时对产品组件执行单元测试。请注意，单元测试不限于软件。单元测试涵盖个别硬件或软件单元或先前已整合的相关群组。有关验证方法与程序，以及关于验证工作产品是否依据所指定的要求，请参考验证过程域，以获得更多信息。软件工程适用单元测试的方法，举例如下：· 叙述涵盖度测试· 分支涵盖度测试· 述词涵盖度测试· 路径涵盖度测试· 边界值测试· 特殊值测试硬件工程适用单元测试的方法，举例如下：· 功能性测试· 辐射检查测试· 环境测试5. 必要时修订产品组件。在实现阶段发生了未能于设计阶段预见的问题时，就是修订产品组件时机的范例之一。SP 3.2建立产品支持文件建立并维护产品使用文件。本特定实践开发并维护用于产品安装、操作及维护的相关文件。典型的工作产品1. 终端使用者培训教材2. 使用者手册3. 操作手册4. 维护手册5. 在线求助子实践1. 审查需求、设计、产品及测试结果，以确保影响安装、操作及维护等项文件的相关议题已被界定并解决。2. 使用有效的方法，制作安装、操作及维护的文件。3. 遵循适当的文件制作标准。文件制作的标准，举例如下：· 与指定的文字处理软件相容· 可接受的字型· 章节及分页的编码· 与指定的文体手册一致· 缩写的使用· 安全分级的标示· 国际化的需求4. 在生命周期的初期阶段就制作安装、操作及维护等文件的初始版本，以供相关的干系人审查。5. 执行安装、操作及维护等文件的同行审查。有关执行同行审查，请参考验证过程域，以取得更多信息。6. 必要时修订安装、操作及维护文件。需要修订文件的时机，举例如下：· 需求变更· 设计变更· 产品变更· 已界定的文件错误· 界定出来预见的修改各通用目标的实践仅适用于连续式表述GG 1达成特定目标本过程将界定之输入的工作产品转换为输出的工作产品，并支持与促成过程域特定目标的达成。GP 1.1实施基础实践实施技术解决方案过程的基础实践，以开发工作产品与提供服务，达成过程域的特定目标。GG 2制度化已管理过程将过程制度化为已管理过程。仅适用于阶段式表述GG 3制度化已定义过程将过程制度化为已定义过程。本一般目标反映在阶段式表述的位置。GP 2.1建立组织政策建立并维护组织政策，以策划和执行技术解决方案过程。详细说明：本政策建立组织的期望，以反复处理下列工作：选择产品组件解决方案、开发产品及产品组件之设计与实现产品组件设计。GP 2.2策划过程建立并维护执行技术解决方案过程的计划。详细说明：执行技术解决方案过程的计划可以是计划的一部分(或参考)，计划在策划过程域中说明。GP 2.3提供资源提供充足的资源，以执行技术解决方案过程、开发工作产品及提供过程服务。详细说明：需求的开发、设计及实现，可能要使用特殊设施。如有必要，应开发或购买在技术解决方案过程域各活动所需设施。提供的资源，举例如下：· 设计规格工具· 仿真器及模型工具· 模型工具· 场景定义及管理工具· 需求追踪工具· 交互式文件制作工具GP 2.4指派责任指派技术解决方案过程的责任与授权，以执行过程、开发工作产品及提供过程服务。GP 2.5培训人员依需要培训人员，以执行或支持技术解决方案过程。详细说明：培训主题，举例如下：· 产品及产品组件应用领域· 设计方法· 接口设计· 单元测试技术· 标准(例如：产品、安全、人为因素、环境)GP 2.6管理配置将指定的技术解决方案过程工作产品，纳入适当层级的控制。详细说明：纳入控制的工作产品，举例如下：· 产品、产品组件、过程、服务及接口设计· 技术相关资料· 接口设计文件· 设计与产品组件再用的准则· 已实现的设计(例如：软件程序代码、已装配的产品组件)· 使用者、安装、操作及维护文件GP 2.7界定并纳入相关的干系人依计划界定并纳入与技术解决方案过程相关的干系人。详细说明：在下列人员中考虑相关的干系人：客户、最终使用者、开发者、制造者、测试人员、供货商、市场营销人员、维护人员、报废处理人员及其它可能影响或被产品及过程所影响的人。干系人参与的活动，举例如下：· 开发备选方案及评选准则· 取得外部接口规格及设计说明之核可· 开发技术相关资料· 评产品组件自制、采购、再用的备选方案· 实现设计GP 2.8监控过程依本过程的执行计划，监控技术解决方案过程，并采取适当的纠正措施。详细说明：用于监控的度及工作产品，举例如下：· 返工所花费的成本、进度及工作· 在产品及产品组件设计所涉及的需求比率· 产品、产品组件、接口及文件的规模大小与复杂度· 技术解决方案之工作产品的缺失密度· 设计活动的进度GP 2.9客观评估遵循程度客观评估技术解决方案过程、工作产品及过程服务，对适用的过程说明、标准及程序的遵循程度，并解决不符合的情况。详细说明：审查的活动，举例如下：· 选择产品组件解决方案· 开发产品及产品组件设计· 实现产品组件设计审查的工作产品，举例如下：· 技术相关资料· 产品、产品组件及接口设计· 已实现的设计(如：软件程序代码、装配好的产品组件)· 使用者、安装、操作及维护文件GP 2.10与上层管理人员审查各状态与上层管理人员审查技术解决方案过程的活动、状态及结果，并解决问题。仅适用连续式表述GG 3制度化已定义过程将过程制度化为已定义过程。本一般目标反映在连续式表述的位置。GP 3.1建立已定义过程建立并维护已定义技术解决方案过程的说明。GP 3.2搜集改进信息搜集由策划及执行技术解决方案过程所衍生的工作产品、度、度结果及改进信息，以支持组织过程与过程资产未来的使用与改进。详细说明：工作产品、度、度结果与改进信息，举例如下：· 制造、购买或再用的分析结果· 设计缺失密度· 应用新方法及工具的结果仅适用于连续式表述GG 4制度化已化管理过程将过程制度化为已化管理过程。GP 4.1建立过程的化目标建立并维护技术解决方案过程的化目标，该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。GP 4.2稳定子过程绩效稳定一个或多个子过程的绩效，以决定技术解决方案过程的能力，是否达成已建立之化质量与过程绩效目标。GG 5制度化优化过程将过程制度化为优化过程。GP 5.1确保持续的过程改进确保技术解决方案过程的持续改进，以实现相关的组织经营目标。GP 5.2纠正问题的根本原因界定并纠正技术解决方案过程之缺失与其它问题的根本原因。专心-专注-专业