技术解决方案word参考模板.docx
《技术解决方案word参考模板.docx》由会员分享，可在线阅读，更多相关《技术解决方案word参考模板.docx（22页珍藏版）》请在冰豆网上搜索。
技术解决方案word参考模板
技术解决方案（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设计产品或产品组件
开发产品或产品组件的设计。
产品设计包含两阶段，在执行上可能相互重叠：
初步设计与细部设计。
初步设计建立产品功能与架构，包含产品组成区块、产品组件界定、系统状态与模式、主要的内部接口，以及外部产品接口。
细部设计完整的定义产品组件的结构与功能。
有关开发架构需求，请参考需求开发过程域，以获得更多信息。
架构定义由需求开发过程的开发架构需求而来。
这些需求代表产品成功的关键质量与效能。
当建立细部产品设计时，架构定义结构化元素与协调的机制，使其直接满足需求或支持需求的达成。
架构包含标准与设计规则，用来管理产品组件的开发与介面，就像能帮助产品开发者的指引一样。
“选择产品组件解决方案”特定目标的特定实践中，包含更多关于使用产品架构作为备选解决方案基础的信息。
架构师设定并开发产品的模式，对产品组件所包含的软硬件做需求配置的判断。
多个支持备选解决方案的架构，经开发与分析以找出针对架构需求的优缺点。
操作概念与场景用来产生作为细化架构的使用案例与质量场景。
它们也用来评估架构的合适性，以满足架构评估期间的期望目标，并在产品设计过程中定期地执行。
有关开发用来作为架构评估的操作概念与场景，请参考需求开发过程域之“建立操作概念及场景”特定实践，以获得更多信息。
定义架构的工作，举例如下：
建立功能区块的结构化关联，与功能区块内的元件以及功能区块间的接口规则
建立软件主要的内部接口与外部接口
界定产品组件及其之间的接口
定义协调机制（例：
针对软件及硬件）
建立基础建设的能力与服务
开发产品组件样板或类别与框架
建立设计规则与授权，以制定决策
定义过程/执行绪的模式
定义软件到硬件的实际部署
界定主要再用的方法与资源
在细部设计期间，完成产品架构的细节、完整定义产品组件，以及完整描述接口。
产品组件的设计可能针对某些质量或效能特性而进行优化。
设计者可评估既有产品或现成品，以作为产品组件。
当设计成熟时，追踪需求（该需求已指定给较低阶的产品组件），以确保这些需求已满足。
有关追踪产品组件需求，请参考需求管理过程域，以获得更多信息。
软件工程适用
细部设计专注于软件产品组件的开发。
定义产品组件的内部结构、产生数据纲要、开发算法及建立启发法，使得产品组件功能满足所配置的需求。
硬件工程适用
细部设计专注于电子、机械、光电，及其它硬件产品及其组件的产品开发。
开发电子概图及电路图、产生机械及光学封装模式，并开发制造及封装过程。
典型的工作产品
1.产品架构
2.产品组件设计
子实践
1.建立并维护准则，以评估设计。
除预期的效能外，用以建立设计准则的属性，举例如下：
模块化
清晰
简单
可维护
可验证
可移植性
可靠性
准确性
安全
可扩充
可使用
2.界定、开发或取得适合于产品的设计方法。
有效的设计方法能具体表现大范围的活动、工具及描述的技术。
方法是否有效，视情况而定。
两家公司在他们所专长的产品上，或许都有非常有效的设计方法，但是这些方法在合作上也许就不那么有效。
复杂度高的方法，对未经培训的设计者而言，就未必是有效的方法。
方法是否有效，也要看它能提供设计者多少的协助，以及其成本效益。
例如：
一个需要多年时间的模型设计，可能不适用于简单的产品组件，但在开发无前例可循、昂贵及复杂的产品时，却可能会是最佳选择。
使用工具的方法是非常有效的，因工具可确保设计将包括所有必要实现产品组件设计的属性。
例如：
设计工具“知道”制造过程的能力，在设计的容忍误差中说明制造过程的差异。
增进有效设计的技术与方法，举例如下：
模型法
结构化模式
对象导向设计
精实系统分析
实体关联模式（E-Rmodels）
设计再用
设计样式
3.确保设计遵循所应用的设计标准与准则。
设计标准的范例，举例如下（部分或全部的“标准”可能是设计准则，特别是标准尚未建立时）：
操作人员接口标准
测试脚本
安全标准
设计限制（例：
电磁兼容性、讯号完整性及环境面）
生产限制
设计的容忍范围
零件标准（如生产的废弃物与废品）
4.确保设计遵循已配置的需求。
必须考虑已界定的现成品组件。
例如：
将现有产品组件放入产品架构可能会修改需求与需求的配置。
5.记录设计。
SP2.2建立技术相关数据
建立并维护技术相关数据。
技术相关数据提供开发者在开发产品或产品组件时，周详的描述。
该数据在各种情况下，也提供采购的弹性。
例如以绩效为主的合约或依设计图建造。
设计结果记录于技术相关数据中。
在初步设计期间产生技术相关数据，以记录架构定义。
在整个产品生命周期中必须维护技术相关数据，以记录必要的产品设计细节。
技术相关数据提供产品或产品组件的说明（包含未视为个别产品组件之产品相关生命周期过程），以支持产品取得策略，或产品生命周期的实现、生产、工程及后勤支持阶段。
这些说明包含必要的设计配置定义与程序，以确保产品或产品组件应有的效能。
它包含所有可用的技术数据，例如：
绘图、相关清单、规格、设计描述、设计数据库、标准、效能需求、提供的质量保证及组装细节。
技术相关数据包含用来
实现之已选定的备选解决方案。
若该信息适合产品或产品组件的型态（例如：
原料与制造需求，对软件服务或过程相关的产品组件可能没有帮助），技术相关数据应包含下列信息：
∙产品架构描述
∙已配置的需求
∙产品组件描述
∙产品相关生命周期过程描述，如未描述于个别产品组件
∙关键产品特性
∙必要的实体特性与限制
∙接口需求
∙原料需求（原料清单与原料特性）
∙建造及制造需求（针对原先的设备制造商与现场支援）
∙用来确保达成需求的验证准则
∙整个产品生命周期中的使用条件（环境）和操作/使用场景、操作的方式与状态、支持、培训、制造、废弃及验证
∙决定的理由与特性（需求、需求配置及设计选择）
由于设计说明包含大量数据，且这些数据对产品组件成功的开发可能是关键，因此建议要建立组织资料与选择数据内容的准则。
使用产品架构来组织资料与抽象化观点，使得感兴趣的议题或特性能以清晰与切题的方式呈现，是一个特别有用的方法。
这些观点包含：
∙客户
∙需求
∙环境
∙功能
∙逻辑
∙安全性
∙资料
∙状态/模式
∙结构
∙管理
这些观点都记录在技术相关数据中。
典型的工作产品
1.技术相关资料
子实践
1.决定设计阶层数目及每一设计阶层文件的适当阶层。
决定需要以文件记录与执行需求追溯之产品组件阶层的数目（例如：
子系统、硬件配置、电路板、计算机软件配置、计算机软件产品组件、计算机软件单元），对管理文件成本与支持整合及验证计划都非常重要。
2.已配置的产品组件需求、架构及较高阶的设计为基础，执行细部设计。
3.记录设计数据于技术相关数据中。
4.记录关键（例如：
对成本、进度或技术绩效有重要影响）决策或定义的理由。
5.必要时修改技术相关资料。
SP2.3使用准则设计接口
使用已建立的准则来设计产品组件接口。
接口设计包含下列：
∙起源
∙终点
∙软件的影响事件与数据特性
∙硬件的电子、机械与功能特性
∙沟通的服务管道
接口准则经常反映出周详的重要参数清单。
必须定义这些参数，或最起码要进行调查，以确保其适用性。
这些参数通常是某特定产品的特性（如软件、机械的、电子的、服务），并常与安全、保密、耐久性及任务的关键特性有关。
有关界定产品及产品组件接口需求，请参考需求开发过程域中，界定接口需求的特定实践，以获得更多信息。
典型的工作产品
1.接口设计规格
2.接口控制文件
3.接口规格准则
4.所选之接口设计的理由
子实践
1.定义接口准则。
这些准则可以是组织过程资产的一部分。
有关建立并维护组织过程资产，请参考组织过程定义过程域，以获得更多信息。
2.界定与其它产品组件相关的接口。
3.界定与外部相关的接口。
4.界定介于产品组件与产品相关生命周期过程的介面。
举例来说，这接口可包括所制造的产品组件与制造过程中用于组装的配件间的接口。
5.应用准则于接口设计的备选方案。
有关界定准则与依据准则来选择备选方案，请参考决策分析与解决方案过程域，以获得更多资讯。
6.记录已选取的接口设计与理由。
SP2.4执行自制、购买或再用之分析
根据已建立的准则，评估产品组件是要开发、购买或再用。
决定要取得哪些产品或产品组件，通常称为“自制或采购分析”，通常是以需求的分析为基础。
自制或采购分析从早期的设计开始，在设计过程阶段持续进行，完成时，决定产品要自行开发、由外部取得或再用。
有关决定产品或产品组件的需求，请参考需求开发过程域，以获得更多信息。
有关管理需求，请参考需求管理过程域，以获得更多信息。
影响自制或购买决策的因素包含如下：
∙产品所提供的功能以及这些功能如何符合的需要
∙可用的资源与技术
∙内部自行开发与外购的成本比较
∙关键的交付日期与整合日期
∙策略联盟，包含高阶的经营需求
∙可用产品的市场分析，包含现成品
∙可用产品的功能与质量
∙潜在供货商的技能与能力
∙对核心竞争力的影响
∙有关外购产品的授权、保证书、权责及界限
∙产品可用性
∙所有权议题
∙风险降低
可使用正式评估方法以进行自制或购买的决策。
有关定义准则及备选方案，以及执行正式评估，请参考决策分析与解决方案过程域，以获得更多资讯。
一如技术的渐进开发，选择开发或采购产品组件的理由也是一样。
虽然复杂的开发工作量会使大家倾向于购买现成品，但生产力与工具的进步，却又会使大家抱持相反的看法。
现成品的文件可能不够完整或正确，而且在将来未必会提供支持。
一旦决定购买现成的产品组件，其需求就用以建立供货商协议。
有时，所谓“现成品”在目前的市场也可能缺货。
例如：
某种型号的飞机或引擎等，它们并非真正的现成品，但随时可以制造。
在某些情况，这类非开发的使用，是因为绩效上的特殊理由，还有其它产品特性上的限制。
在这种情况下，需求与验收准则就必须包含在供货商协议中，并加以管理。
在其它的
状态下，现成品就如它们字面上的意思一样（如字处理软件），供货商并没有需要被管理的协议。
有关如何说明产品组件的取得，以便执行采购，请参考供货商协议管理过程域，以获得更多信息。
典型的工作产品
1.设计与产品组件再用的准则
2.自制或采购分析
3.选择现成品组件的指引
子实践
1.开发产品组件设计再用的准则。
2.分析设计以决定产品组件要自行开发、再用或采购。
3.当采购或选择非开发的（现成品、政府的成品及再用）时，分析维护所隐藏的代价。
维护的涵义，举例如下：
与未来现成品的发行有兼容性
供货商变更的配置管理
非开发性的缺失与其解决方案
非计划性的废置
SG3实现产品设计
依照设计，实现产品组件及相关的支持文件。
从“开发设计”特定目标的特定实践所建立的设计，实现产品组件。
实现工作通常包括产品整合及终端使用者文件制作前，所需的产品组件单元测试。
SP3.1实现设计
实现产品组件设计。
一旦完成产品设计，接着就是将之实现为产品组件。
实现的特性与产品组件的种类有关。
产品阶层最高阶设计的实现，包含下一阶每个产品组件的规格。
此活动包含配置、细化及验证每一产品组件。
同时也涉及多样的产品组件开发工作间的协调。
有关需求的配置与细化，请参考需求管理过程域，以获得更多信息。
有关接口管理与产品及产品组件的整合，请参考产品整合过程域，以获得更多信息。
实现的特性，举例如下：
已撰写程序代码。
数据已文件化。
服务已文件化。
电子及机械零件已制造。
产品独特的制造过程已放入实际作业中。
过程已文件化。
设施已建造。
原料已生产（例如：
一项产品特有的原料可能是一种石油、燃料油、润滑油，或是一种新的合金）。
典型的工作产品
1.已实现的设计
子实践
1.使用有效的方法实现产品组件。
软件工程适用
软件程序制作的方法，举例如下：
结构化程序设计
对象导向程序设计
自动化产生程序代码
软件程序代码再用
使用合适的设计模式
硬件工程适用
硬件制造方法，举例如下：
闸门层级组合
电路版设计（位置及路线）
计算机辅助设计图
事后设计模拟
制造方法
2.遵循适当的标准与准则。
实现制作的标准，举例如下：
程序语言标准（例：
软件程序语言标准及硬件描述语言）
绘图需求
标准零件清单
制造零件
软件组件的结构及阶层
过程及质量标准
制作的准则，举例如下：
模块化
明确
简单
可靠性
安全性
可维护性
3.对选定的产品组件，执行同行审查。
有关执行同行审查，请参考验证过程域，以获得更多信息。
4.适当时对产品组件执行单元测试。
请注意，单元测试不限于软件。
单元测试涵盖个别硬件或软件单元或先前已整合的相关群组。
有关验证方法与程序，以及关于验证工作产品是否依据所指定的要求，请参考验证过程域，以获得更多信息。
软件工程适用
单元测试的方法，举例如下：
升级会员 