GBT26240-2010系统工程系统工程过程的应用和管理.pdf 71页

'lCS35．080L77a园中华人民共和国国家标准GB／T26240—201O／ISO／IEC26702：2007系统工程系统工程过程的应用和管理Systemsengineering--Applicationandmanagementofthesystemsengineeringprocess2011-01·14发布(IS0／IEC26702：2007，IDT)2011—05—01实施宰瞀鹊紫瓣訾糌瞥星发布中国国家标准化管理委员会仅19 前言⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯⋯⋯··1综述⋯-⋯⋯··⋯⋯⋯-⋯⋯⋯⋯一1．1范围⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·】．2目的⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·1．3如何使用本标准⋯⋯⋯⋯⋯⋯·1．4本标准的结构⋯⋯⋯⋯⋯⋯⋯·2规范性引用文件⋯⋯-⋯⋯-⋯·3术语和定义、缩略语⋯⋯⋯⋯⋯⋯·3．1术语和定义⋯⋯⋯⋯⋯⋯⋯⋯·3．2缩略语⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·4总体要求⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·4．0总则⋯⋯⋯⋯--⋯⋯⋯⋯⋯⋯·4．1系统工程过程⋯⋯⋯⋯⋯⋯⋯·4．2系统工程的方针和规程⋯⋯·⋯··4．3规划技术工作⋯-⋯⋯⋯⋯⋯4．4开发策略⋯⋯⋯⋯⋯⋯⋯⋯·⋯4．5建模和原型化⋯⋯⋯⋯⋯⋯⋯⋯4．6集成资源库⋯⋯⋯⋯⋯⋯··⋯⋯·4．7集成数据包⋯⋯⋯⋯⋯⋯⋯⋯⋯4．8规约树⋯⋯⋯⋯··j⋯⋯⋯⋯⋯⋯4．9制图树⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯4．10系统分解结构⋯⋯⋯⋯⋯⋯⋯4．11系统工程工作的集成⋯⋯⋯⋯4．12技术评审⋯⋯⋯⋯⋯⋯⋯⋯⋯4．13质量管理⋯⋯⋯⋯⋯⋯⋯⋯⋯4．14产品和过程改进⋯⋯⋯⋯⋯⋯5贯穿系统生存周期的系统工程应用5．1系统定义阶段⋯⋯⋯⋯⋯⋯⋯⋯5．2概要设计阶段⋯⋯⋯⋯⋯⋯⋯⋯5．3详细设计阶段⋯-·-⋯⋯⋯⋯⋯⋯5．4生产、装配、集成和测试阶段⋯⋯5．5生产和支持阶段⋯⋯⋯⋯⋯⋯⋯5．6生存周期过程中的并行工程⋯⋯6系统工程过程⋯⋯⋯⋯⋯⋯⋯⋯⋯6．1需求分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯6．2需求确认⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯6．3功能分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯6．4功能验证⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯目次GB／T26240--2010／ISO／IEC26702：2007Ⅲ，●，●000加¨¨¨¨挖坞坞MMM坫¨¨¨均船驰弘盯盯勰弛弘踮● GB／T26240—2010／ISO／IEC26702：20076．5合成⋯⋯⋯⋯⋯·⋯⋯⋯⋯·⋯．⋯⋯⋯⋯⋯⋯⋯⋯⋯．．6．6设计验证⋯⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯6．7系统分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．6．8控制⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．附录A(资料性附录)系统工程在企业中的角色⋯⋯⋯．附录B(资料性附录)系统工程管理计划．⋯⋯⋯⋯⋯⋯．附录C(资料性附录)在GB／T22032语境中使用本标准参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．Ⅱ盯蚰蛇拍∞鸥∞盯 刖吾GB／T26240--2010／ISO／IEC26702：2007本标准使用翻译法等同采用IsO／IEC26702：2007(<系统工程系统工程过程的应用和管理》(英文版)，根据GB／T1．1—2000的规定作了如下编辑性修改：——由于GB／T114572006《软件工程术语》的内容涵盖并多于IEEEStd610．121990的内容，因此第2章规范化引用文件中将IEEEStd610．12—1990替换为GB／T114572006；——ISO／IEC26702：2007附录中多处以“IEEEStd1220”(ISC}／IEC26702：2007采用自IEEEStd1220)指代本标准，这些都被替换为“本标准”；——Iso／IEc26702：2007的脚注2针对规范化引用中的IEEE标准说明IEEE标准的下载网址，在本标准中被删除，后续脚注3和4分别递进为脚注2和3；一一IsO／IEC26702：2007的脚注5和6介绍ISO及ISO／IEC出版物的获取途径，在本标准中被删除；——图13中相关的制品“需求基线”缺少表示方向的文字“From：”，本标准中进行了补充；——图14中“功能验证、设计验证、控制”活动按照箭头以及相关文字解释应该是“From：”，本标准中进行了纠正。本标准的附录A、附录B和附录C是资料性附录。本标准由全国信息技术标准化技术委员会(sAc／Tc28)提出并归口。本标准起草单位：上海超算并行软件有限责任公司、复旦大学、中国电子技术标准化研究所。本标准主要起草人：袁俊、彭鑫、赵文耘、王宝艾、冯惠、何志峰、吴毅坚、钱乐秋、王秀娟。Ⅲ 1综述GB／T26240--2010／ISO／IEC26702：2007系统工程系统工程过程的应用和管理1．1范围本标准规定了一个系统整个生存周期中所涉及的各种多学科交叉任务，这些任务将利益相关方的要求、需求和约束转换为一个系统解决方案。本标准的目的是为商业、政府、军事和空间应用等系统的开发提供指导。相关信息适用于企业的内部项目，这类项目负责开发一套产品设计并且建立维持产品生存周期所需的生存周期基础设施。本标准阐明了系统工程过程(SEP：SystemsEngineeringProcess)及其在整个产品生存周期中应用的需求。本标准并未试图定义每个系统生存周期过程的实现，但涉及了与在产品开发早期以及整个过程中定义并建立支持性的生存周期过程相关的问题。此外，本标准没有涉及成功的产品开发宜加以考虑的那些大量的文化或质量要素。本标准关注于指导产品开发所必需的那些工程活动，同时保证产品被正确设计以使其能够在可承担的范围内被生产、拥有、操作、维护以及最终被处置，并不对健康和环境造成不适当的风险。本标准的要求既适用于新产品又适用于已有产品的增量式改进，既可用于单一产品，例如卫星，又可用于面向消费者市场大量生产的产品。本标准的要求宜在每个特定的系统开发项目中有选择地加以应用。附录A对系统工程在企业环境中的角色进行了描述。本标准的内容描述了一种集成的产品开发方法，该方法代表了下列技术工作的总和：a)理解产品使用可能所处的以及产品设计应该适应的环境和相关条件；b)按照功能和性能需求、质量要素、易用性、可生产性、可支持性、安全性以及环境影响定义产品需求；c)为提供产品生存周期支持所必需的生产、测试、分发、支持、培训以及处置定义生存周期过程。1．2目的本标准的目的是为系统从最初的概念到开发、运行和处置的整个管理过程提供标准。如今，大量产品中都包含计算机以及相关软件，这使得将每个产品作为一个整体系统进行工程化管理的需要更加迫切。人、物理和软件部件都应该致力于整个系统性能的优化。本标准可以与GB／T220322008[-33”一起使用。与GB／T220322008相比，本标准规定了更多的系统工程过程和管理要求的详细描述，完善或补充了GB／T22032--2008中描述的过程活动。而GB／T22032--2008则提供了额外的过程定义和指导，支持贯穿～个系统生存周期的系统工程过程的生存周期模型的定义和应用。1．3如何使用本标准1．3．1符合性本标准中的规范性条款，即使用“应⋯⋯”陈述的条款，是宣称符合本标准的必要条件。而那些使用“宜⋯⋯”陈述的条款则属于推荐性的。希望宣称符合本标准的企业应通过实现所有的规范性条款定义和相应的规程来表明其与本标准的符合性。1．3．2推荐和剪裁企业还宜将推荐选择及可选条款纳入他们的规程中，宜保证企业中的每个项目都遵照这些规程执行。1)方括号中的数字对应于参考文献中的文献序号。』 GB／T26240--2010／ISO／IEC26702：2007第4章给出了在企业内或某个项目中实现系统工程的一些规范性条款和推荐。第4章中的规范条款包括企业方针和规程的制定和维护。描述贯穿整个项目生存周期的系统工程过程(SEP)应用的企业方针和规程，为企业SEP在特定项目中的应用提供了基础。因此，企业应该建立并维护这样的方针和规程。第6章迭代地定义了SEP，从而定义系统产品和生存周期过程。因此，定义每一个子过程(如需求分析、功能分析等)的初始条款都包括一个“应⋯⋯”的陈述，从而保证企业的SEP包括每个子过程以及子过程执行所需的任务。余下的子条款，如果是在一个子过程的定义中阐述的，则被推荐用来提供必要的灵活性，使得企业可以根据自己的目标以及典型的系统工程工作对这些子过程以及SEP中的任务定义进行调整。第6章描述了所推荐的企业SEP的项目剪裁方法，该方法将如第5章所描述的那样应用于任意一个特定的SEP项目迭代。第5章开始的条款包括一个“应⋯⋯”的陈述，从而保证项目在整个系统生存周期中都致力于SEP的应用。第5章余下条款描述了项目在一个典型的系统生存周期的每个阶段中应用SEP时通常都会执行的一些推荐和可选的活动。第5章中这些推荐和可选的活动宜由项目在为系统生存周期中任意一次SEP的特定迭代进行企业SEP剪裁时加以考虑。该方法为项目提供了应对不同系统开发层次所需的灵活性，还为项目在各个系统生存周期阶段应用SEP提供了适当的严格性。1．3．3系统范型SEP的描述及其在整个生存周期中的应用要求用一种系统范型来辅助相关材料的陈述。用来支持该范型的术语在第3章中定义。随着企业和项目对该范型的熟悉，他们可以用更加熟悉的、适用于他们的产业或业务实践的术语来代替。该系统范型是本标准的基础，接下来的各子条款将对其进行描述以支持对该术语系统的不同使用。从大的范围看，存在生物学系统、生态学系统、气候系统、太阳系等。因此，一个系统可以看作另一个更大的系统中的一个元素，而面临的挑战是理解系统的边界，这也是开发工作的关注点，以及该系统与其他系统之间的关系和接口。本标准的关注点是面向产品的系统，例如汽车、飞机或信息系统。1．3．3．1系统元素的层次一个系统一般由相关的元素(子系统和部件)以及它们之间的接口组成。此外，元素还包括该元素的产品开发、生产、测试、分发、运行、支持或处置，或者培训其他人以适应在系统中的角色所需要的人。图1给出了组成一个系统的各种元素名的层次。这个通用的系统层次是本标准中的一个关键概念，因为它将系统体系结构、规约和制图树、系统分解结构(SBS)、技术评审以及配置基线联系到了一起。该系统层次中的许多元素自身根据典型定义也可以被认为是一个“系统”，但实际上代表的是系统层次中的子系统。同样，生存周期过程表示的也是整个系统层次中的子系统。I产品I子系统{组装件I部件厂————上————]子部件子配件}I零件子部件I零件系统的元素可能包括硬件、软件和人(取决于系统定义)图1系统中的元素层次 GB／T26240--2010／ISO／IEC26702：2007复杂部件表示由硬件、软件和／或人组成的系统元素，它们可以按照生存周期过程(如何设计、测试、生产、支持等都是已知的)进行识别，而特定领域的工程团队承担着复杂部件的开发职责。这是一种主观判断——复杂部件可能要求SEP的严格性或者可以很好地适应于部件开发团队。人元素对于系统层次是必需的，可以出现在任何一级上。人元素在系统层次中没有标识出来，因为这个层次结构的目的是标识系统定义所需的系统元素，而人／系统集成问题宜根据人在系统的运行、生产、支持等过程中的角色来确定。提供一个系统中的元素层次是为了说明系统可以由其他系统(子系统)组成，它们表示不存在现有设计方案或供方的复杂元素。子系统或复杂部件的层次数量取决于所开发的系统的复杂性。SEP应用于系统层次中的每一级上，系统元素对其而言是一个无法识别出可用设计方案或现有生产商的复杂项。一个系统元素一旦被标识为一种硬件、软件或人元素，相应学科特定的设计方法学将被用来设计该系统元素。1．3．3．2构造块结构一个系统的基本构造块如图2所示——系统、它的相关产品、支持这些产品所需的生存周期过程，以及构成产品的子系统。每个生存周期过程——开发、生产、测试、分发、运行、支持、培训，或处置——自身也像是一个系统，因为同样需要开发产品来满足各个生存周期过程的目标。例如要生产一个产品，生产是一个生存周期过程。与生产生存周期过程相关的产品包括特殊的装备、工具、设施，以及生产过程和规程。构成生存周期过程的产品也可能需要生存周期的支持，因为它们也需要开发、测试、生产、分发、运行、支持、培训，以及处置。囹产品层次结构中的元素口生存周期过程图2系统的基本构造块1．3．3．3产品及生存周期过程定义图3描述了生存周期过程，包括8个基本功能过程，它们对于实现消费者总体满意度以及达到公众接受可能是必需的。一旦识别出一个生存周期过程的要求，这个生存周期过程就作为一个系统对待，而SEP将用来定义、设计和建立该生存周期过程以及支持产品和过程，使得该生存周期过程可以维持运行状态。8个基本功能过程如下：a)开发策划并执行将系统从利益相关方的要求转化为产品解决方案以及它们的生存周期过程所需的系统和子系统定义任务；b)生产用于制作和装配工程化的测试模型，实验板，原型，以及产品解决方案及其生存周期过程产品的生产，所需的活动、任务和动作； GB／T26240—2010／ISO／IEC26702：2007c)测试：1)为评价进行计划，或者基于功能体系结构或需求基线对合成产品，或基于需求基线对功能性体系结构进行评价所涉及的活动、任务和动作；2)为评价产品解决方案及其生存周期过程以测量规约符合性或利益相关方满意度而进行的活动、任务和动作；d)分发为了实现向用户、操作者或消费者的适当转移而进行的最初的产品运输、交付、装配、安装、测试以及产品出库而进行的活动、任务和动作；e)运行与产品或一个生存周期过程的使用相关联的活动、任务和动作；f)支持为维持运行而提供供应、维护、支持原料以及设施管理的活动、任务和动作；g)培训获得并维持在整个系统生存周期中高效地实现系统的操作、支持以及处置而需要的知识、技能和能力所需的一系列可测量的活动、任务和动作(包括指令和所用的练习)。培训包括那些开发并被用来为所有需要的任务提供培训的工具、装置、技术、规程和材料；h)处置为了保证毁坏的或无法修复的消费者、生存周期过程及其副产品的处置或循环使用符合所适用的环境规章和指示而进行的活动、任务和动作。一个典型的系统由企业或供方／分包商开发的产品组成。每个供方／分包商都将其产品视为它的系统的一部分。购买这些产品以集成到更高一级系统的组织宜根据这些元素对于系统性能、功能和成本的影响程度，考虑将这些产品作为子部件、部件、复杂部件或子系统。圈产品屡敬结构中的元素口生存周期过程——人员一零件库存一备用零件库存一操作员——供方／卖主——人员～维护者一培训员——供方膜方一供方／卖方——质量控制图3生存周期过程定义为了理解人／系统集成的问题并且保证系统产品是可生产、可维护、可用的以及有效建立系统过程从而保证生产的质量等级并降低总体拥有成本，产品以及生存周期过程的设计宜按照操作人员、维护人员、生产人员、培训人员等将相关人员考虑为系统的一个元素。图3描述了与系统产品和过程相关的人员要素。运行过程包括产品的运行并且辅助标识操作规程以及人的认知和考虑，以保证系统的易用性。系统元素的定义通过SEP的活动产生。第6章给出了该过程的详细描述。系统的每个开发层次中都将使用SEP以构成系统工程活动的结构，这些活动标识技术需求以及期望的系统行为并合成系统设计。1．4本标准的结构本标准的结构如下：——第1章给出本标准的范围、目的以及组织；——第2章给出适用于本标准的规范性引用；——第3章定义本标准所使用的术语以及缩略语；——第4章介绍在一个企业中规划并实现有效的系统工程能力的要求；d GB／T26240--2010／ISO／IEC26702：2007——第5章给出在系统定义、子系统定义、生产和支持过程中应用SEP的一个描述；——第6章给出开发产品解决方案及其支持生存周期过程所需要进行剪裁和执行的SEP详细任务；——附录A讨论SEP作为负责在企业中建立产品设计和生存周期支持产品的总体技术工作；——一附录B给出一个帮助企业制定系统工程管理计划的模板；——附录c讨论了本标准和GB／T22032--2008[3]之间的一些关键区别；一一最后是参考文献。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。11457--一2006信息技术软件工程术语3术语和定义、缩略语3．1术语和定义114572006中界定的以及下列术语和定义适用于本标准。3．1．1需方acqnirer从供方那里获得或获取产品或服务的利益相关方。注1：针对需方的其他常用术语包括买主、顾客和买方。需方可能同时也是拥有者、用户或运行的组织。注2：顾客的含义比需方、操作者或用户更为宽泛，包括了这些角色以及其他角色。注3：根据GB／T220322008[3]改写而成。3．1．2协定agreement对于相应条款和条件的相互认可，在此基础上建立起某种工作关系。注：参见GB／T22032--2008[33。3．1．3分配allocation为硬件、软件或人指派一个功能或决定的决策。注：分配可以只针对这三种系统元素类型中的一种或者某种结合做出，这种结合将在进一步的功能分解中解决。3．1．4基线baseline已经过正式评审和同意的一个规范或产品，它将作为迸一步开发的基础，并只能通过正式的变更控制规程进行更改。注：参见GB／T220322008[3]。3．1．5约束constraint限制SEP的设计方案或实现并且是企业无法改变的一种限制或隐含的要求。注：约束通常是不可分配的。3．1．6顾客customer接收产品的组织或人，例如消费者、客户、最终用户、零售商、受益人和购买方。注1：顾客可以是组织内部或外部的。5 GB／T26240--2010／I$O／IEC26702：2007注2：参见GB／T190002000[1]0注3：顾客的含义比需方、操作者或用户更为宽泛，包括了这些角色以及其他角色。3．1．7设计体系结构designarchitecture一种设计元素的安排，为一个产品或生存周期过程提供设计方案从而满足功能体系结构和需求基线。3．1．8设计特性designcharacteristic属于一个产品或过程的某种可测量描述的设计属性或显著特征。3．1．9按成本设计designtocost使用成本目标使设计与成本目标相一致，包括产品的生产成本(按单位生产成本设计)和生存周期成本(按生存周期成本设计)。注：成本目标宜与任何其他性能参数同等对待。3．1．10有效性分析effectivenessanalysis针对一个设计方案能在多大程度上执行或操作期望运行场景的分析。3．1．11有效性评估effectivenessassessment根据生产、测试、分发、运行、支持、培训、环境影响、成本有效性和生存周期成本对设计方案的评价。3．1．12最终项enditem识别为系统分解结构元素的一种实体(硬件装备、软件装备、数据、设施、材料、服务和／或技术)。3．1．13企业enterprise执行指定任务的组织。注：当一个不相符的企业中的项目直接应用本标准时，所提到的“企业”都宜理解为该项目。3．1．14设施facility用于促进行动的执行的物理手段或装备，如建筑物、器械、工具。注：参见GB／T220322008[3]。3．1．15功能体系结构functionalarchitecture功能及其子功能和接口(内部及外部)的编排，其中定义了执行序列、控制流和数据流条件以及性能需求，以满足需求基线。3．1．16功能需求functionalrequirement标识一个产品或过程为了产生所需要的行为和／或结果所必须实现的一种陈述。3．1．17人因系统工程humansystemsengineering整个系统生存周期中所包含的与系统设计中人的因素(包括易用性、有效性测度、性能测度以及总体拥有成本)相关的活动，包括人力、人员、培训、人因工程、健康危害和安全问题的定义和综合。6 GB／T26240—2010／iso／mc26702．20073．1．18集成资源库integratedrepository一种用于存储所有与SEP有关信息的资源库，包括所有的数据、模式、模型、工具、技术管理决策、过程分析信息、需求变更、过程和产品度量以及权衡等。3．1．19接口规约interfacespecification对于两个或更多系统元素之间公共边界上基本功能、性能和设计需求及约束的描述。注：包括人与硬件或软件之间的界面，以及人与人之间的接口。3．1．20生存周期lifecycle由利益相关方意识到的某个要求开始，直到产品处置的整个系统或产品的演化。3．1．21生存周期成本lifecyclecost在产品开发、生产、测试、分发、运行、支持、培训和处置中的总投资。3．1．22生存周期模型lifecyclemodel与生存周期相关的过程和活动框架，同时也作为交流和理解的共同参考。注：参见GB／T220322008[3]。3．1．23MOE有效性测度measureofeffectiveness可以被需方用来测量对于技术工作所生产出的产品的满意度的一组度量指标。3．1．24MOP性能测度measureofperformance提供满足某种有效性测度所必需的设计要求的一种工程性能测度。注：对于每种有效性测度一般都存在多个性能测度。3．1．25操作者operator对于系统功能有贡献以及利用知识、技能和规程来发挥作用的个人或组织。注1：操作者的角色和用户的角色可以同时或先后赋予同一个人或组织。注2：与知识、技能和规程相结合的单个操作者可以视为系统的一个元素。注3：顾客的含义比需方、操作者或用户更为宽泛，包括了这些角色以及其他角色。注4：根据GB／T22032--2008[3]改写而成。31．26性能需求performancerequirement标识一个功能的某种质量属性或者功能性需求必须实现的程度的可测量准则。3．1．27需求requirement标识一个产品或过程的运行、功能或设计特性或约束的一种陈述，该陈述必须是明确的、可测试的或可测量的，而且对于产品或过程可接受性(根据消费者要求或内部质量保障方针)是必要的。3．1．28规约specification一种按照需求(功能性、性能、约束和设计特性)以及每个需求的限定条件和规程充分描述一个设计元素或其接口的文档。 GB／T26240--2010／ISO／IEC26702：20073．1．29规约树specificationtree一种由规约元素及其接口规约组成的层次结构，该结构标识出与待控制的系统配置中的设计元素相关的元素和规约。3．1．30阶段stage与系统描述或系统自身状态相关的系统生存周期中的一个期间。注1：阶段与系统生存周期中主进展和成果里程碑相关。注2：各阶段之间可能有重叠。注3：参见GB／T220322008[3]。3．1．31利益相关方stakeholder在一个系统或其拥有满足自身要求和期望的特性中具有某种权利、份额或主张的一方。注1：利益相关方的含义比顾客、需方、操作者或用户更为宽泛，包括了这些角色以及其他角色。注2：根据GB／]、220322008[3]改写而成。3．1．32状态state在某个时间点上刻画一个功能／子功能或元素的行为的状况。3．1．33供方supplier就某种产品或服务的供应与需方达成协定的组织或个人。注：参见GB／T220322008[3]。3．1．34系统system一组或一系列相关的元素[人、产品(硬件和软件)及过程(设施、装备、材料和规程)]，其行为满足运行需要并且为产品生存周期的维持提供支撑。3．1．35系统体系结构systemarchitecture产品的设计体系结构及其生存周期过程的组合。3．1．36系统分解结构systembreakdownstructureSBS一种由元素、相关的生存周期过程及人员组成的层次结构，该结构用来分派开发团队、进行技术评审以及向实现项目目标所必需的各个任务进行工作划分和相关的资源分配。注：SBS可以作为成本跟踪和控制的基础。3．1．37系统有效性systemeffectiveness根据系统在预期的环境条件下如何运行以及系统在其生存周期中生产、测试、分发、运行、支持、培训以及处置的能力，对一个系统满足其预期运行用途的能力的一种测量。3．1．38权衡分析trade-offanalysis根据性能、按成本设计目标以及生存周期质量要素对设计选项／可替换项的分析性评价。8 GB／T26240—2010／ISO／IEC26702：20073．1．39用户user在系统使用期间从中获益的个人或团体。注1：用户的角色和操作者的角色可以同时或先后赋予同一个人或组织。注2：顾客的含义比需方、操作者或用户更为宽泛，包括了这些角色以及其他角色。注3：根据GB／T220322008[3]改写而成。3．2缩略语BIT内建测试(built—intest)FAIT制作、装配、集成和测试(fabrication，assembly，integration，andtest)FIT缺陷隔离测试(fault_isoIationtest)FMEA失效模式和影响分析(failuremodesandeffectsanalysis)IPT集成的产品团队(integratedproductteam)MOE有效性测度(measureofeffectiveness)MOP性能测度(measureofperformance)SBS系统分解结构(systembreakdownstructure)SEMS系统工程主进度表(systemsengineeringmasterschedule)SEP系统工程过程(systemsengineeringprocess)TPM技术性能测度(technicalperformancemeasure)4总体要求4．0总则企业应依照本标准规划、实施和控制一个集成的技术工作，以开发一个适应市场机会、特定利益相关方需求、企业目标和外部约束的整个系统解决方案。执行以下a)到f)项列出的活动对于达到这个目标一般都是必要的。为了达到这个目标，企业宜：a)按照针对特定项目的剪裁，规划、实施以及管理一个完全集成化的技术工作，以满足本标准的总体要求；b)在系统的每一层次应用SEP；c)在下列实施过程中控制进度：1)每一层次开发之后的技术评审；2)风险管理；3)数据管理；4)接口管理；5)配置管理；6)基于绩效的进度测量；d)生成模型和原型以支持权衡；e)生成集成数据包，确保产品可以被生产、测试、分发、操作、支持和适当地处置；f)在一个集成的资源库中捕获所有技术性活动的输出。特定的要求和推荐在本标准的其他章中给出。4．1系统工程过程如第5章描述的那样，企业应应用第6章以及图4中描述的SEP规范性条款来产生规约和基线以及相关产品。SEP是一种通用的问题解决过程，提供了标识和演化系统的产品和过程定义的机制。SEP应用于整个系统生存周期中所有与产品开发、验证／测试、生产、培训、运行、支持、分发、处置和人 GB／T26240--2010／ISO／mC26702：2007因系统工程相关的活动。图4描绘了SEP的子过程并且展示它们是如何迭代以产生一组一致的需求、功能安排和设计方案。SEP的子过程、任务和活动在第6章详细描述。4．2系统工程的方针和规程企业应开发和维护方针和规程以控制SEP的实施。这些方针和规程阐明了对于产品规划、实现和控制以及过程开发和人／系统集成的要求。这些方针和规程宜建立企业的系统工程范型，培训可以基于此范型并且项目特定的活动也可以根据这个范型剪裁和完成。企业方针和规程宜关注于：a)贯穿项目生存周期的SEP应用；b)系统工程管理计划的制定和批准；c)系统工程主进度表(SEMS)和系统工程详细进度表的制定和批准；d)集成数据包的制定和批准；e)监控并报告项目的技术进展；f)准备并实施技术评审；g)集成资源库的内容和维护；h)产品和过程的持续改进。过程输出图4系统工程过程(SEP)4．3规划技术工作项目应制定并实现用来指导项目达成其目标和适当结果所必需的技术计划和进度表。拥有项目授权和目标之后，项目宜建立一个工程计划、一个主进度表和一个详细进度表。工程计划宜是所有技术工lO GBIT26240--2010／ISO／IEC2670212007作的主要计划文档，并且描述了对本标准经剪裁的应用。主进度表，一种基于事件的进度表，以及详细进度表，一种从主进度表导出的基于日程的进度表，宜覆盖产品的开发活动以及支持性的生存周期过程。主进度表和详细进度表可以合并为单个的工程进度表。项目宜建立起和下面各条相符的技术工作计划。4．3．1工程计划工程计划应制定并在整个系统生存周期中进行更新以指导和控制项目的技术工作。工程计划宜反映一种负责涉及所有与满足生存周期需求相关因素的产品开发的集成化技术工作。工程计划宜反映附录B中识别出的内容，它给出了工程计划内容的通用大纲和描述。如果采取演化或增量式的开发策略，那么工程计划宜包含初始产品开发的策略以及增量的能力和／或技术增强的插入。4．3．2主进度表主进度表宜制定并在整个系统生存周期中进行更新以建立关键事件、相关的重要任务以及确定重要任务完成的准则。一个正确设计的主进度表宜考虑到调度与任务相关的活动、资源的分配、预算编制、人员分配、任务开始和结束日期的建立以及事件完成准则。4．3．3详细进度表详细进度表宜提供一种基于日程的活动、任务以及主进度表中关键事件的进度表。详细进度表宜被用来追踪技术工作的进展。详细进度表数据宜被用来构建事件、任务和活动的网络以确定工程工作的关键路径以及分析进度表的偏差。4．3．4技术计划应制定技术计划以根据需要补充工程计划。宜按照所应用于的工程和技术专业领域制定技术计划，宜使用技术计划来按照计划测量技术进度。技术计划一般被制定用于风险管理、配置管理、技术评审、验证、计算机资源、生产、维护、培训、保密安全和人因系统工程。4．4开发策略项目宜为开发系统及其能力探索开发策略(例如瀑布、增量、演化和螺旋模型)。改变或增强产品以及生存周期过程的能力宜设计到系统体系结构中，使得系统在它整个生存周期中的维持可以有成本效益的进行。这个设计属性宜在系统开发的早期建立[标识利益相关方需求或约束时(见6．1．1和6．1．2)]，从而为规划每个增量开发工作提供基础。演化式开发策略宜明确管理新技术引入、演化需求或增强产品能力的方法。4．5建模和原型化项目宜确定并建立合适的模型、模拟和原型来支持分析和项目决策。典型的建模、模拟和原型化问题包括：需求定义、系统体系结构和设计的分析、所标识风险的缓解。这些模拟关注于确保最终产品满足市场要求、需求及约束。这个工作支持系统功能和性能特性、可生产性、可支持性、环境影响以及人因系统工程问题(例如可维护性、易用性、可操作性和安全性)的评估。4．6集成资源库企业应在资源库中捕获相关设计数据以演化集成数据包，以及为技术信息的交换和复用提供共享资源。4．6．1数据相关的数据包括：工程计划；进度表；技术计划；功能、物理以及系统体系结构；设计决策的基本原理；完成的权衡分析，包括建议以及影响；有效性评估及其结果；风险评估和处理选项；草图和制图；工程变更；规约树；规约和配置基线；运行环境；人力、人员、培训和人因工程需求和规约；归档数据；技术目标、需求、约束、接口和风险；sBs；设计模型；测试结果；度量；以及任何其他考虑到需求到功能和设计体系结构追踪性的数据。4．6．2工具项目应维护工具版本与模型、分析结果和其他工具输出之间的追踪性，以确保重新生成支持SEP11 GB／T26240--2010／ISO／IEC26702：2007的执行结果的能力。4．7集成数据包项目应生成一个记载体系结构和设计信息的集成数据包以支持生存周期过程。这个集成数据包宜根据项目需要包括表1中定义的工程数据类型。集成数据包的初始内容宜在系统生存周期的早期定义，宜由4．7．1～4．7．4中标识的信息类型组成，并且宜随着SEP的每一次应用演化，从而为每个开发层次提供更多的细节。4．7．1硬件集成数据包包括支持产品生产、装配和集成的技术设计信息。4．7．2软件集成数据包包括支持软件需求、设计、源代码、验证和确认、构建指令、操作和维护的技术设计信息。4．7．3生存周期过程集成数据包包括对于生存周期过程及特殊的装备规约和基线、软件代码清单、技术手册、技术计划、设施图以及与生产、验证、分发、运行、支持、培训I和处置相关的特殊工具的技术设计信息。4．7．4人员集成数据包包括支持支撑系统生存周期的人的角色定义的信息。实例产品包括人因系统工程计划、安全规约、人力、人员和培训文档；工作区布置图；接口设计规约和制图；操作顺序图；手工规程；以及模型、模拟或设计数据库。表1集成数据包内容一个集成数据包包括但不限于下列项：A．硬件1)安排图记载系统中主要的子系统或部件间的关系。2)装配图——记载构成装备或系统更高一个契约层次的所需的各部分及子装配的一种组合的关系。3)连接图——记载一个安装件或它的组成装置或部分的电气连接。4)构造图——记载构造或结构的设计。5)产品图——一种以一个项可以被开发或从商业市场上获得以满足规定需求的程度记载配置和配置限制、性能和测试需求、重量和空间需求、访问许可、管道和电缆连接、支持需求等的工程图。6)细节图一为图中描绘的子部件描述完整的最终项需求。7)立面图——记载构造和结构的垂直投影或者装备的剖面。8)工程图——一种通过图示或文字陈述或二者结合的方式揭示设计以及一个项的功能性终端产品需求或设计的工程文档。9)安装图～记载安装一个与所支撑的结构或关联项相关的项所必需的一般配置和完整信息。lO)逻辑图——通过图形符号或记法的方式记载逻辑电路的序列和功能，以及运行、维护、测试和修理的序列流。11)数字控制图——记载一个项完整的设计和功能性工程和产品需求，以便于通过传送带控制方式进行生产。12)管道图——记载部件间通过管道、管线或软管的相互连接，以及必要时系统中的水流和气流的顺序流程。13)接线表——记载由表格数据和用来建立项内或项问线路连接的指令组成的一种书状制图。14)示意图——通过图形符号记载电气连接和一个特定的电路安排的功能。15)电线及电缆线束图一记载在一个特定配置中一组缚在一起的电线的路径，以简化安装。16)模型、模拟或设计数据库——提供前面1)到15)项所列的任意一项一种的物理的、分析的或数据式的表示B．软件1)软件设计文档——记载软件项体系结构、设计需求、实现逻辑以及提供一种支持手段的数据结构。2)软件源代码清单——记载表示“所构建”实现的实际的源代码指令 表1(续)GB／T26240--2010／ISO／1EC26702：2007C人员——记载在整个系统生存周期中操作、维护和支持系统的人的认知、身体和感觉特性，这些特性直接作用于或限制系统性能并且影响人机界面。1)人力、人员和培训文档——记载知识、技能和能力；培训需求；以及在整个系统生存周期中操作、维护和支持系统的人的易用性。2)工作区布置图——记载支持生存周期每个阶段的人与系统的主要子系统或部件间的关系。3)界面设计规约和图——记载支持系统生存周期的人与系统的任何方面之间所有的界面，包括人人界面、人硬件界面和人软件界面。4)操作顺序图——记载在任务执行中随着时间推移，人与系统中其他子系统或部件间交互的一种图形化表示。5)规程——记载支持生存周期中每个阶段的人所执行的为了开发、生产、测试、分发、操作、支持和处置系统或其产品的动作，或者为了培训人来完成这些动作的动作。这些规程可以以操作顺序图、列表或表格的形式给出。6)安全规约——记载装备／系统的设计特征、性能规约以及在整个装备／系统生存周期操作有效性、时间和成本的约束内，减少导致伤亡的人或机器的错误或失效的可能性的培训D．生存周期过程过程产品设计体系结构——记载与开发(系统工程和集成)、生产、验证、分发、支持、培训及处置相关的生存周期过程产品的设计体系结构。产品包括装备、软件、人、设施、过程和一个特定生存周期过程所必需的服务4．8规约树项目应生成与适合于开发层次的设计体系结构相一致的规约树。规约树由规约元素和接口规约组成。接口规约记载交互元素之间的接口需求。系统接口规约定义了与外部系统、平台和产品之间的接口。子系统接口规约定义子系统间的接口，包括硬件硬件、硬件软件、软件软件、人人、人硬件和人一软件等接口。定义了一个完全开发系统元素的各种规约如图5所示。由于项目通常在更高层系统中的一个元素上工作，图5反映了在系统周境下这个工作是如何呈现的。正如第5章描述的，规约树是自顶向下开发的。规约树的层数取决于生存周期的阶段。规约树的最低层依赖于设计元素的复杂度、以及决定与规约相关的产品的生产、购买或复用决策可以针对哪个层次作出。如果是在整个系统生存周期中支持系统的人，这个决策对具有适当知识、技能和能力的人员是否可用，或者需要执行何种层次的雇用、征募或培训。这可以是在子系统层或部件层以下的任何一层上。4．9制图树项目应生成一个制图树以反映与设计体系结构中硬件元素相关的图。这个树宜与图5中的规约树相似。 GB／T26240--2010／ISO／IEC26702：2007图5规约树4．10系统分解结构项目应生成一个SBS以描述组成系统体系结构的产品和过程的层次。项目可以用SBS来制定及控制计划包并将把它们转换为工作包、确定工作包规模、配置管理、资源分配、需求变更追踪、接口控制、成本报告以及基于事件的进度表。生存周期过程被分配到产品、装配，如果需要的话还可以分配SBS的子装配以及支持生存周期的人。制定人力、人员和支持系统及其子系统和部件的人所需要的知识、技能、能力、易用性和培训的培训规约，以确保系统可以在其生存周期内被充分地操作和支持。生存周期过程可以根据需要在SBS的各个层次上定义，从而为产品元素提供生存周期支撑。组成一个典型的完全开发系统的SBS的各种系统元素和生存周期过程如图6所示。该图反映了系统开发的三个主要层次——系统定义、概要设计和详细设计——系统通过这些层次进行演化，就如第5章描述的那样。4．11系统工程工作的集成项目将工程和业务专业的各种输入集成到系统工程工作中，以满足项目目标。4．11．1并行工程企业或者项目宜集成产品及其相关的生存周期过程的并行设计。并行工程宜集成产品和过程开发以确保产品是可生产的、可用的和可支持的。宜使用计算机辅助工程工具来支持开发和生产，并且宜集成到集成资源库中。4．11．2集成团队宜将集成团队考虑作为组织功效和有效性的主要方法。使用集成团队时，项目宜为SBS的特定元素分派团队。每一个团队宜为所分派系统元素制定所需要的计划文档(31程计划、主进度表等)；宜负责开发并满足与该元素相关的规约和基线；并且宜完成与该元素相关的任务陈述中所概括的工作，包括第5章的技术评审。4．12技术评审为了评估技术进展，项目应进行评审，包括设计评审(例如系统、子系统、部件、生存周期过程、测试准备就绪、生产许可)和审核(例如功能性和设计配置)。通常，设计评审宜在SEP的每次应用结束时进行。每次评审宜完成以下部分：a)评估系统需求和分配以确保需求是无歧义的、一致的、完备的、可行的、可验证的以及到顶层系14 GB／T26240--2010／ISO／IEC26702：2007统需求是可追踪的；b)基于技术开发目标、SEMS事件、完成情况以及支持按期进展的经验分析和测试数据，评估设计成熟度；c)陈述与后续开发工作相关联的风险；d)评估在系统生存周期中维持产品所需的生存周期过程和基础设施；e)标识后续开发需要的资源；f)确定是否继续SEP的下一次应用、中断开发或者在继续开发工作之前采取纠正动作。部件、子系统和系统设计评审宜在开发的每一层上进行。较低层次上的评审可能也是需要的，这取决于系统的复杂程度(见图6)。在设计评审期间，权衡分析和验证结果宜是可用的，从而证实设计决策。评审可能导致需要在SEP中迭代，以在开发活动进一步展开之前解决所标识的不足。宜进行部件、子系统和系统的功能和设计配置审查以确保支持文档满意地完成、针对每一个规约需求的合格性测试已经完成，并且所有的需求都得到满足。系统设计子系统设计部件设计图6系统分解结构4．13质量管理企业和项目应对产品开发和生存周期过程应用质量管理规程。4．14产品和过程改进为了在系统生存周期中以与企业目标一致的方式持续地改进产品和过程，企业和项目宜建立并维15 GB／T26240--2010／ISO／IEC26702：2007护产品和过程质量要素。4．14．1再工程企业和项目宜探索改进现有产品和过程的方法。企业和项目宜捕获与每个开发工作和设计相关的设计数据、模式、工具和模型，从而为改进系统成本有效性及纠正不足而演化一个产品和过程。注：再工程是在生产之后，通过修改来纠正设计不足或进行增量改进的系统改进过程。4．14．2自评估企业宜维护一个自评估程序，从而确定它的系统工程实践的成熟度以涵盖第6章中SEP任务的应用。企业应用在自评估时获得的认识来改进产品、生存周期过程和企业系统工程实践。4．14．3汲取的教训企业宜捕获在每个项目中汲取的教训并将它们适当地加入到企业培训中，以改进SEP的应用。汲取的教训为建立将来的系统开发工作、改进度量以及避免企业以前所承担的项目中遇到的问题提供了基础。5贯穿系统生存周期的系统工程应用为了系统产品以及它们的与开发、生产、验证、分发、支持、培训和处置相关的生存周期过程的开发和支持，项目应在整个系统生存周期中应用SEP(在第6章中描述)。每一个系统开发层次(系统、子系统、部件)上应用SEP都为前面过程应用中定义的产品增加价值(附加的细节)。在制作、装配、集成和测试(FAIT)、生产和消费者支持阶段，应用SEP对于解决所报告的问题以及演化产品以提高性能或延长服务寿命同样是有用的。开发和运行中典型的系统生存周期阶段如下：开发阶段a)系统定义；b)子系统定义：1)子系统的概要设计；2)子系统部件的详细设计；3)FAIT。运行阶段a)生产；b)支持。这些阶段在图7中描绘。于系统定义≥‘系统定义概要设计详细设计制作、装配、集成和测试(FAIT)图7典型的系统生存周期项目宜满足如5．1至5．3中定义的系统生存周期的每个开发阶段的主要出口事件。这些主要的事件包括建立产品描述、完成规约、建立配置基线以及完成技术评审。项目同样宜完成5．4和5．5中描述的系统工程任务，其中包括纠正设计和过程不足／问题、演化系统以提供附加的能力、延长系统的寿命以及完成技术评审。此外，项目宜制定系统产品所需的以满足整个生存周期的需要和要求的生存周期过程。与生存周期过程制定相关的活动在5．6讨论。5．1系统定义阶段项目宜执行系统定义阶段以建立系统定义，关注于满足运行需求所需的系统产品。这个阶段的主要事件宜包括系统、产品及子系统接口规约、系统及产品规约以及子系统的概要规约的完成；系统基线的建立；以及适合于系统定义阶段的技术评审的完成。系统定义期间产生的文档需要用来指导子系统开发。技术评审宜评价系统开发的成熟度以及进一步进行子系统定义的就绪程度。16 GB／T26240--2010／ISO／IEC26702：20075．1．1系统定义为了产生系统级的已确认需求基线、已验证的功能和设计体系结构、规约和系统基线、SBS以及已更新的工程和技术计划，项目如第6章所描述的那样应用SEP。需要完成的特定的活动在表2中列举。表2系统定义建立系统定义a)选取系统概念b)建立初始的项且和技术计划c)缓解系统风险d)评估子系统风险e)标识子系统和子系统接口f)标识人／机界面问题g)定义生存周期质量要素1)可生产性2)可验证性3)易分发性4)易用性5)可支持性6)可培训性7)可处置性8)总的拥有成本h)为概要设计修订工程和技术计划完成规约a)完成系统和产品接口规约b)完成系统和产品规约c)完成子系统接口规约d)完成子系统概要规约e)完成初步的人／机界面f)完成初步的人力、人员和培训建立基线a)建立系统基线b)建立初步的子系统设计目标基线完成技术评审a)完成可替代概念评审b)完成系统定义评审5．1．1．1系统概念有先例的系统是指存在同类设计样例的系统，从而为建立设计体系结构、工程和技术计划、规约或者低风险的可选项提供指导。对伴随增量改进或演化成长产品的有先例系统的开发，项目宜精化所建立的系统定义和产品线策略来满足市场机会或订单。无先例的系统是指不存在设计样例的系统，因而设计体系结构选项不受先前系统描述的约束。对概念尚未定义的无先例系统，项目宜创建并评价可能满足市场机会或订单的候选可选概念。在这个系统开发的第一个阶段中，宜为进一步的系统定义选取一个或多个备选概念。宜对每个备选系统相关的风险进行评估，包括风险识别和量化。另外，项目宜完成每个可行的可选项的系统和产品概要规约，以及系统和产品接口规约和一个系统基线。5．1．1．2初始的工程计划项目宜为系统生存周期建立必需的工程和技术计划，包括：a)确定系统定义进度评估的活动完成准则；b)各系统工程活动之间的技术资源分配。17 GB／T26240--2010／ISO／IEC26702：2007对于有先例的系统，工程计划、主进度表和详细进度表针对完整的开发生存周期制定，带有当前阶段的大部分细节。对于无先例的系统，工程计划、主进度表和详细进度表随着系统开发制定和演化。适当时宜为生产、后勤、计算机资源、保密安全性、安全性、可靠性和可维护性以及培训制定相关的技术计划。工程和技术计划明确系统产品的开发以满足运行功能，以及需用来满足系统级开发、生产、测试、分发、支持、培训和处置功能的生存周期过程的制定。5．1．1．3子系统和子系统接口项目宜标识每个产品的子系统，并且定义子系统之间的设计和功能接口需求以及相应的性能需求和设计约束。系统产品功能性和性能需求宜在子系统间进行分配，以保证从系统产品到它们各自子系统、以及从子系统到它们的父产品的需求追踪性。5．1．1．4标识人／机界面问题项目宜标识人和产品或子系统问的界面需求。界面需求包括性能、负载、设计约束和易用性。5．1．1．5生存周期质量要素项目宜定义影响系统满足可生产性、测试、易分发性(包装、搬运、运输、存储、安装和迁移)、易用性、可支持性、易培训性和可处置性这些下游需求的能力的系统生存周期质量要素。系统生存周期质量要素宜以一种确保质量要素追踪性得到维护的方式在产品以及子系统之间进行分解和分配。5．1．1．6修订的项目和工程计划为了响应基于系统定义中实施SEP活动的变化以及反映下一阶段开发的计划，项目宜更新所必需的工程和技术计划。．5．1．2规约项目宜制定并控制下列这些指导系统定义阶段系统工程工作所需规约。5．1．2．1系统、产品和子系统接口规约在概念／系统定义阶段的初始工作中，项目宜完成系统和产品接口规约并将其置于变更控制之下。系统接口规约宜为系统和其他系统定义系统的外部功能接EI和设计接口。所选取的系统概念的独特外部接口宜在系统接口规约中以体现这些特殊接口元素的独特性质的方式进行定义和文档化。产品接口规约宜定义系统产品和生存周期支持装备之间的设计和功能性接口需求，例如特殊的测试装备和培训辅助。子系统接口规约宜为每个产品定义子系统间的设计和功能性接El需求。项目宜标识哪些接口需求包含了系统／产品／子系统的设计约束，以及哪些接口十分关键、要由接口管理工作组管理。’5．1．2．2系统和产品规约项目宜完成并控制一份系统规约以及系统中每个产品的产品规约。系统规约宜记载系统需求(功能性和性能需求、设计特征和设计约束)以及系统规约中每项需求的判定要求。产品规约宜记载每个产品的系统级需求分配以及产品规约中每项需求的判定要求。每个规约的判定部分宜标识用来确定每项系统或产品需求已经在正常和反常情况下得以满足的方法。5．1．2．3子系统概要规约项目宜为在系统设计体系结构中标识出的每一个子系统制定子系统概要规约。子系统概要规约宜标识子系统需求(功能和性能需求、设计特性和设计约束)以及规约中每项需求的判定要求。规约的判定部分宜标识用来确定每项子系统需求在正常和反常情况下得以满足的方法。5．1．2．4完整的人／机界面概要规约项目宜为人和系统设计体系结构中标识的硬件和软件元素之间的交互制定人／机界面概要规约。规约的判定部分宜标识用来确定每个人／机交互需求在正常和反常情况下得以满足的方法。此外，人／机界面规约还包括人和／或子系统或部件间的界面需求。这些界面包括人一人、人硬件和人一软件。需求可能包括功能和性能需求，以及负载和设计约束。5．1．2．5完成初步的人力、人员和培训规约项目宜为在整个系统生存周期中操作、维护和支持系统所需要的人员制定一份规约。相应的分析1R GB／T26240--2010／ISO／IEC26702：2007宜确定具备合适知识、技能和能力的人员是否在整个生存周期中预期是可用的；可用人员的认知、身体和感知特性；系统所需的安全特征；以及这样的人员所需要的培训等级。5，1．3配置基线项目宜制定下列这些需要用来指导系统定义阶段的技术工作的基线，并将其置于配置控制之下。5．1．3．1系统基线项目宜建立系统基线，并将其置于配置控制之下。这种系统级的配置基线宜包括系统接口规约、产品接口规约、系统规约、产品规约以及捕获设计、数据、模型、度量、变更、设计原理和其他与关于系统需求所作的决策或澄清相关的信息的集成资源库。5．1．3．2子系统设计目标基线项目宜为系统体系结构中标识出的每个子系统生成一个子系统设计目标基线。每个设计目标基线宜包括可应用的子系统接口规约、相关的子系统概要规约以及为定义系统产品而开发的任何子系统制图或草图。5．1．4技术评审项目宜规划并实施可应用的技术评审以评估开发工作的成熟度并建议是否应该投资以继续开发工作。这个开发阶段所完成的系统级评审可以与项目管理评审相结合。5．1．4．1选择性概念评审如果需要，选择性概念评审宜由项目选择一个或一些概念来完成，这些概念由5．1．1．2至5．1．3．2中描述的系统定义活动应用。在这个评审中，每个概念按以下要点进行评价：a)产品和子系统分配合理并且提供了健全的系统概念；b)概念满足利益相关方需求和公众期望的能力；c)系统和产品接口规约及系统概要规约的完成；d)一个系统基线的建立；e)和概念有关的已评估风险；f)为了证实在定义概念以及确定概念满足利益相关方需求和公众期望时所作的决策的系统分析数据的适当性和完整性。5．1．4．2系统定义评审项目宜在系统定义阶段结束时完成系统定义评审，以确定系统定义是否充分成熟到可以进展到子系统定义。评审系统定义是为了确保：a)它充分成熟以满足SEMS准则；b)系统级风险已经被充分地覆盖以对后续开发进行论证；c)权衡研究数据可以充分证实系统需求是能实现的；d)到达系统定义配置时所作的决策能够得到分析、测试和／或其他技术数据的良好支持。5．2概要设计阶段项目宜执行概要设计阶段以启动子系统设计并创建子系统级规约和设计目标基线，从而指导部件开发。项目应用SEP是为了与下列各条相符，将标识出的子系统功能分解为更低层的功能，并将功能需求和性能需求分配到部件层功能和物理体系结构上。每个子系统的概要规约和概要设计目标基线都宜分别演化为一个子系统规约和一个设计目标基线。宜为开发中的子系统的各个部件定义概要规约和构建目标基线。最终的子系统文档宜包括建议的部件和接rn标识；子系统层风险的解决方案；部件风险的评估；以及面向质量要素的设计，可适当地包括每个子系统的可生产性、可验证性、易分发性、易用性、可支持性、可培训性和可处置性。5．2．1子系统概要定义项目宜为了产生子系统功能和物理体系结构，对每个子系统应用第6章描述的SEP。要完成的特定活动在表3中列出。19 GB／T26240--2010／ISO／IEC26702：20075．2．1．1组装件和组装件接口项目宜标识每个子系统的组装件并定义组装件问的设计和功能接口需求以及它们相应的性能需求和设计约束。子系统性能需求在组装件间进行分配，从而保证从子系统到适当组装件、以及从组装件到父子系统的需求可追踪性。5．2．1．2部件和部件接口项目宜标识每个组装件的部件并定义部件间的设计和功能接口需求以及它们相应的性能需求和设计约束。组装件性能需求在部件间进行分配，从而保证从组装件到它们各自的部件、以及从部件到它们的上一级组装件之间的需求可追踪性。5．2．1．3子系统和部件风险项目宜缓解在系统定义中被评估为对子系统开发有关键影响的子系统级风险，而且宜评估并缓解与每个子系统相关的组装件风险。对于关键的子系统／组装件风险，宜使用模拟、比例模型测试或者原型测试来展示从成本、进度和／或性能方面考虑已缓解到一个可以接受的等级。项目宜评估部件风险，并在发生的可能性以及相关的成本、进度和／或性能影响基础上对风险进行优先级排序。表3子系统定义——概要设计建立子系统概要定义a)标识组装件和组装件接口b)标识部件和部件接口c)缓解子系统风险d)评估部件风险e)为生存周期质量要素设计f)完成每个子系统的概要制图g)标识人／机界面问题h)为详细设计修订工程和技术计划完成规约a)更新系统和产品规约b)完成子系统和组装件规约c)完成部件接口规约d)完成部件概要规约e)更新人／机界面规约f)更新人力、人员和培训规约建立基线a)更新系统基线b)建立设计目标基线c)建立初步的构建目标基线完成技术评审a)完成子系统概要设计评审b)完成系统概要设计评审5．2．1．4标识人／机界面问题项目宜标识人与组装件或部件间的界面需求。这些界面需求包括性能、负载、设计约束和易用性。5．2．1．5生存周期质量要素项目宜标识并量化子系统生存周期质量要素，这些要素影响每个子系统满足可生产性、测试、易分发性(包装、搬运、运输、存储、安装和迁移)、易用性、可支持性、易培训性和可处置性这些下游需求的能力。子系统生存周期质量要素宜以一种确保质量要素追踪性得到维护的方式在组装件然后是部件之间分解和分配。、20 GB／T26240—2010／1SO／IEC26702：20075．2．1．6工程和技术计划项目宜更新工程和技术计划以响应基于子系统定义中进行的SEP活动的变更以及反映面向下一开发阶段的计划。5．2．2子系统规约项目宜制定并控制指导子系统定义的详细设计阶段的部件设计活动所需要的规约。5．2．2．1系统和产品规约在概要设计阶段，项目宜更新并控制已建立规约的所有变化。在生存周期的这个阶段，典型的受控规约包括系统接口规约、子系统接口规约、产品规约和系统规约。5．2．2．2子系统规约项目宜为每个子系统完成一份子系统规约并将其置于配置控制下。这些规约宜记载功能和性能需求、设计需求或其他所附加的设计约束以及每个子系统的判定要求。单个子系统规约的判定部分宜标识用来确定每项子系统已经在正常和反常情况下得以满足的方法。5．2．2．3部件接口规约项目宜为设计体系结构中标识的每个产品部件制定部件接口规约并将其置于配置控制之下。部件接口规约宜记载应该在部件开发中满足的部件间的功能和设计接口。项目宜标识哪些组装件接口需求为部件设计提供约束，以及哪些需要通过接口控制工作组管理其变更。5．2．2．4部件概要规约项目宜为设计体系结构中标识出的每个产品部件制定一份部件概要规约。部件概要规约宜标识功能和性能需求、设计需求或约束以及部件概要规约中每项性能需求的判定要求。单个规约的判定部分宜标识将被用来确定每项部件需求已经在正常和反常情况下得以满足的方法。5．2．2．5更新人／机概要界面规约项目宜为人以及在设计体系结构中标识出的硬件和软件元素之间的交互更新人／机界面规约。每个规约的判定部分宜标识用来确定每项人／机交互需求已经在正常和反常情况下得以满足的方法。此外，人／机界面规约包括人、子系统或部件间的界面需求。这些界面包括人一人、人一硬件和人一软件。需求可能包括功能和性能需求，以及负载和设计约束。5．2．2．6更新人力、人员和培训概要规约项目宜为在整个系统生存周期中操作、维护和支持系统所需要的人员更新规约。分析宜确定具有合适知识、技能和能力的人员是否在整个生存周期中预期是可用的；可用人员的认知、身体和感知特性；系统所需的安全特征；以及这样的人员所需要的培训等级。5．2．3配置基线项目宜将下列需要用来指导子系统定义阶段技术工作的基线置于配置控制之下。5．2．3．1系统基线在概要设计阶段中，项目宜更新并控制对于系统基线的所有变动。5．2．3．2设计目标基线项目为每个来自于系统定义中产生的概要设计目标基线的子系统演化／精化并建立设计目标基线。这个基线包括组装件和部件接口规约、子系统规约、组装件规约以及捕获设计、数据、所使用的模型和工具、度量、变更、设计原理以及其他与关于子系统需求所作的决策或澄清相关的信息的集成资源库。5．2．3．3部件构建目标基线项目为一个子系统的每个部件演化／精化一个部件构建目标基线。这个基线包括部件接口图以及部件规约草稿。5．2．4技术评审项目宜实施可应用的技术评审以评估开发工作的成熟度并且决定是否进行投资以继续进行详细设计。系统级以下的技术评审通常并不是作为项目管理评审的一部分进行的。21 GB／T26240—2010／ISO／1EC26702：20075．2．4．1子系统评审子系统评审宜由项目在每个子系统概要设计阶段结束时完成。每个评审的目的是为了保证：a)子系统定义是足够成熟以满足SEMS准则的；b)部件分配和部件概要规约是合理的，并提供了一个完备的子系统概念；c)子系统风险已经评估并缓解到一个适合于继续开发的等级；d)权衡研究数据可以充分证实系统需求是能实现的；e)到达子系统配置定义时所作的决策得到分析和技术数据的良好支持。5．2．4．2系统评审项目宜在子系统评审结束后完成系统级评审。这个评审是为了确定详细设计的总体系统方法是否满足系统基线；不可接受的风险是否得到缓解；所有子系统、产品和生存周期过程的问题是否都得到了解决；以及目前取得的进展和计划是否能保证后续的开发工作。5．3详细设计阶段项目宜执行系统生存周期的详细设计阶段来完成子系统直到最底层部件级的设计，并且为每个部件创建部件规约和部件构建目标基线。这一阶段的输出用来指导用于开发测试的试制原型的制作。项目根据需要多次应用第6章描述的SEP将所标识的部件功能分解为更低层的功能，并且在整个所得到的更低层功能和设计体系结构上分配功能和性能需求。子系统概要设计中生成的每一个部件概要规约和构建目标基线宜分别被演化为部件规约和构建目标基线。最终的部件文档宜包括推荐的部件和接口标识；部件层风险的解决方法{以及对于每个部件直到最低层的子部件适当包括以下这些质量要素的设计：可开发性、可验证性、易分发性、易用性、可支持性、可培训性以及可处置性。5．3．1子系统详细定义项目宜对每个部件及其子部件应用SEP，从而生成部件的功能和设计体系结构。需要完成的特定活动在表4中列举。表4子系统定义——详细设计建立子系统详细定义a)完成部件定义(硬件及软件)b)解决部件风险c)生存周期质量要素设计d)识别人／机界面问题e)准备集成数据包f)修订FAIT的工程和技术计划完成规约a)更新系统、产品、子系统以及组装件规约b)完成部件规约(硬件及软件)c)更新人／机界面规约d)更新人力、人员及培训规约建立基线a)更新系统基线和设计目标基线b)创建构建目标基线完成技术评审a)完成部件详细设计评审b)完成子系统详细设计评审c)完成系统详细设计评审 GB／T26240--2010／ISO／IEC26702：20075．3．1．1部件定义项目宜为每一个组装件分解部件到足以满足设计完整性的层次，完成每个子部件及部件的定义，并且控制子部件之间的接口。部件需求宜以一种双向追踪性都能得到维护的方式在子部件之间分配。5．3．1．2部件风险项目宜缓解那些在子系统定义中评估为对于部件开发关键的部件级风险。对于关键部件风险，宜使用模拟、比例模型测试或者原型测试来展示从成本、进度和／或绩效方面考虑已缓解到一个可以接受的等级。项目宜评估并缓解子部件风险，并在发生的可能性以及相关的成本、进度和／或绩效影响基础上对风险进行优先级排序。5．3．1．3标识人／机界面问题项目宜标识识别人和部件、子组装件或子部件之间的界面需求。这些界面需求包括性能、负载、设计约束和易用性。5．3．1．4生存周期质量要素项目宜标识并量化影响每个部件满足可生产性、可验证性(测试)、易分发性(包装、搬运、运输、存储、安装和迁移)、易用性、可支持性、易培训性和可处置性这些下游需求的能力的部件生存周期质量要素。部件生存周期质量要素宜以一种确保质量要素追踪性得到维护的方式在部件的子部件然后是更低层的子部件之间分解和分配。5．3．1．5集成数据包项目宜为每个部件及其子部件完成详细文档以满足分配到部件、部件接口规约和组装件规约上的功能体系结构需求。集成数据包宜生成并保存在集成资源库中，宜包含如4．7中所定义的详细制图、代码清单、手工规程等。5．3．1．6工程和技术计划项目宜更新必要的工程和技术计划，从而在子系统定义的详细设计阶段所进行的SEP活动基础上适应变更并反映对FAIT阶段所作的计划。5．3．2规约项目宜制定并控制下列指导子系统定义的FAIT活动所需的规约。5．3．2．1系统、产品、子系统及组装件规约项目宜更新并控制对于详细设计阶段已批准规约的所有变更。在生存周期的这个阶段，典型的已批准规约可能包括系统、子系统和部件接口规约；系统规约；产品、子系统和组装件规约。5．3．2．2部件规约项目宜为设计体系结构中标识的每一个部件完成部件规约。除了设计需求或设计约束之外，部件规约标识部件的功能和性能需求，以及每个性能需求的判定要求。单个规约的判定部分宜标识将用来确定每项部件需求已经在正常和反常情况下得以满足的方法。5．3．2．3更新人／机界面规约项目宜为人以及在设计体系结构中标识出的硬件和软件元素之间的交互更新人／机界面规约。规约的判定部分宜标识用来确定每项人／机交互需求已经在正常和反常情况下得以满足的方法。此外，人／机界面规约包括人、子系统或部件问的界面需求。这些界面包括人人、人一硬件和人一软件。需求可能包括功能和性能需求，以及负载和设计约束。5．3．2．4更新人力、人员和培训概要规约项目宜为在整个系统生存周期中操作、维护和支持系统所需要的人员更新规约。分析宜确定具有合适知识、技能和能力的人员是否在整个生存周期中预期是可用的；可用人员的认知、身体和感知特性；系统所需的安全特征；以及这样的人员所需要的培训等级。5．3．3配置基线项目宜制定下列需要用来指导子系统定义阶段技术工作的基线并将其置于配置控制之下。23 GB／T26240--2010／ISO／IEC26702：20075．3．3．1系统基线以及设计目标基线项目宜更新并控制对于所建立的系统基线和设计目标基线的所有变化。5．3．3．2构建目标基线项目宜为来自于概要设计中生成的构建目标基线的每个部件建立构建目标基线。这个基线宜包括部件接口规约、部件规约以及捕获设计、数据、模型和所使用的工具、度量、变更、设计原理以及其他与关于部件需求所作的决策或澄清相关的信息的集成资源库。5．3．4技术评审项目宜实施可应用的技术评审以评估开发工作的成熟度并且推荐是否进行投资以继续进入FAIT。系统级以下的技术评审通常不宜作为项目管理评审进行，而宜作为严格的技术评审进行。5．3．4．1部件评审部件评审宜由项目在每个部件详细设计阶段结束时完成。这种评审的目的是为了保证：a)每个部件详细定义都足够成熟以满足有效性测度／性能测度(MOE／MOP)准则；b)部件规约是合理的，并提供了一个完备的部件概念；c)部件和相关的生存周期过程风险已经评估并缓解到一个适合于支持FAIT的等级；d)权衡研究数据可以充分证实部件详细需求是可实现的；e)到达部件详细定义配置时所作的决策得到分析和技术数据的良好支持。注：有效性准则是用来确定一个设计方案成败的值的测度。5．3．4．2子系统评审项目宜在与子系统相关的部件评审结束后完成每一个子系统的子系统级评审。这个评审是为了确定子系统详细设计是否满足设计目标基线；风险得到缓解并且剩下的风险是可接受的；所有部件、组装件和生存周期过程的问题是否都得到了解决；以及目前取得的进展和计划是否能保证后续的FAIT。5．3．4．3系统评审项目宜在子系统详细设计评审结束后完成一次系统级评审。这个评审是为了确定系统的详细设计是否满足系统基线；不可接受的风险是否得到缓解；所有子系统、产品和生存周期过程的问题是否都得到了解决；目前取得的进展和计划是否满足后续技术工作的准则；以及系统是否通过解决突出的产品或生存周期过程问题为继续到FAIT作好准备。5．4生产、装配、集成和测试阶段项目在这个阶段应用第6章所描述的SEP，从而达到解决那些由观察、分析、演示或测试发现的系统、产品、子系统、组装件或部件规约未得到满足情况下的产品不足。子系统定义的FAIT阶段的目标是验证所设计的产品满足规约。这个阶段的主要活动显示在表5中。5．4．1系统集成及测试项目宜执行集成活动以保证组合更低层元素可以得到一个具有机能且统一的更高层元素，并能满足逻辑和设计接口。项目执行测试活动来验证系统满足系统需求。项目首先测试部件，然后逐步在各个层次上进行测试，直到包括整个系统。项目宜逐步组装并集成子部件到完整部件、部件到组装件、组装件到子系统、子系统到产品，然后在需要时实现产品及其生存周期过程和服务到完整系统的组装。在每个组装和集成层次上，部件、组装件、子系统、产品及系统宜接受充分的测试，以保证运行有效性、易用性、可培训性、接口符合性、与指定需求相符、可生产性以及可支持性。项目要负责对测试物品以及测试所产生的或与测试一起使用的所有有害废物进行合适的搬运和处置。5．4．2分析、修正及重新测试当一个子部件、部件、组装件、子系统或产品不能满足其需求时，项目宜对不足进行分析以确定问题的起因并且应用SEP来解决问题。项目宜重新测试产品以保证运行有效性、易用性、可培训性、接口符合性、与指定需求相符、可生产性以及可支持性。24 GB／T26240—2010／ISO／IEC26702：2007表5子系统定义——FAIT进行系统集成和测试a)制作硬件部件．实现软件部件b)组装、集成并测试部件和组装件c)组装、集成并测试子系统和产品d)建立生存周期过程e)分析并修正错误／+不足并重新测试f)更新所有规约和基线g)修订生产的工程和技术计划完成技术评审a)完成部件测试就绪评审b)完成子系统测试就绪评审c)完成系统测试就绪评审d)完成部件功能配置审核e)完成子系统功能配置审核f)完成系统功能配置审核g)完成部件生产批准评审h)完成子系统生产批准评审-)完成系统生产批准评审5．4．3项目和工程计划项目宜更新必需的工程和技术计划，从而基于子系统定义的FAIT阶段中进行的SEP活动对变更进行响应并反映面向生产的计划。5．4．4规约项目宜更新并控制对已批准规约的所有变更。5．4．5配置基线项目宜更新并控制对已建立基线的所有变更。5．4．6技术评审项目宜计划并进行可应用的技术评审来评估开发工作的成熟度，从而确定合格性测试是否准备就绪以及确定是否应该进行投资以继续进入生产阶段。系统级以下的技术评审通常不宜作为项目管理评审进行，而宜作为严格的技术评审进行。5．4．6．1测试就绪评审项目宜完成测试就绪评审(根据需要对部件、组装件、子系统、产品以及系统进行)来保证：a)测试规程符合测试计划和描述，展示出完成测试要求的充分性并且满足规约判定要求；b)测试前的判断和非正式测试结果(如有)确定规约需求的满足；c)完成测试和评价所需的新的或修改过的测试支持装备、设施和规程手册宜是可用的并且宜满足它们的需求；d)所需要的规约、基线以及其他支持文档是完整且准确的。5．4．6．2功能配置审核项目宜完成功能配置审核(根据需要对部件、子系统和系统进行)来验证产品已经实现了需求；就是说它们满足规约、接口规约以及其他基线文档中指定的特性；测试计划和规程得到遵守。5．4．6．3产品批准评审项目宜在产品功能配置审核结束之后完成系统级的生产批准评审，从而展示整个系统(人、产品和过程)经过验证，在每个系统层次上都满足规约和基线需求，并且确定生产、分发、运行、支持、培训，持续改进(如果可应用)和处置都准备就绪。项目宜确定：25 GB／T26240--2010／ISO／IEC26702：2007部件、组装件、子系统、产品和生存周期过程及服务的问题都已解决；针对部件、组装件、子系统和产品的测试规程已经完成并且准确；系统和产品确定可以进行测试；测试依照已建立的规程进行；建立从详细设计之后进行的设计评审开始、包括已证实变更的审核轨迹，并且所有部件、子系统和系统产品满足规约需求；风险处理规程满足生产的需要；演化式的开发需求和计划已经精化；计划是完整的，并且规程、资源及其他所需的人、产品和过程都可用(或规划可用)以启动进行下一步的生产、分发、运行、支持、培训、处置以及演化式开发(如果有)。5．5生产和支持阶段项目依照第6章应用SEP来纠正在生产、组装、集成以及产品和／或生存周期过程产品验收测试中所发现的不足。项目同样在支持中应用SEP来演化产品以实现增量变更、解决产品或服务不足、或实现计划的演化式增长。产品生存周期中这两个阶段的主要事件显示在图8中。生产一—／／／／／支持生产系统产品提供操作员和用户服务a)完成生产盘存和控制活动a)提供服务b)生产并装配鞘费者产品”提供零配件产品c1纠正产品设计及过程设计缺陷d1处置副产品和废物完成系统演化完成技术评审a)设计演化以a)完成部件物理配置审核1)实现增t改进b)完成子系统物理配置审棱2)解决产品缺陷C)完成系统物理配置审核3)超越同类竞争产晶图8生产和支持5．5．1系统产品项目宜进行适当的生产盘存和控制活动；生产、组装、集成和验收测试活动；以及包装、搬运、存储、交付和安装活动以向消费者和支持组织提供系统产品。项目宜管理供方以保证进行生产活动所需要的产品、原料和服务的及时交付。5．5．1．1产品和过程不足项目宜应用SEP来纠正生产、验收测试或分发过程中发现的产品和／或过程缺陷。5．5．1．2副产品和废物处置项目宜保证对在生产、验收测试和分发中产生或使用的有害废物和原料进行合适的搬运和处置。在某些情况下，项目可能还要负责在完成服务寿命后对产品进行适当的处置。5．5．2技术评审项目宜完成设计配置审核(根据需要对部件、子系统和系统进行)来保证系统元素符合定义构建目标基线的技术文档。5．5．3支持产品一旦到位，项目宜继续通过所需的服务和零组装件产品对操作员和用户进行支持，以维持供方关系。D∽0DoD砂¨ GB／T26240—2010／ISO／IEC26702：20075．5．4系统演化项目在支持中应用SEP来对已到位产品和服务进行增量改进；解决消费者产品使用或服务活动中发现的产品或过程不足；改变产品和服务以与竞争对手提供的产品和服务进行竞争；确保具有支持演化中的产品所需的合适的知识、技能和能力的人员是可用的。5．5．4．1修订项目和工程计划项目宜更新必需的工程和技术计划，从而在生产和支持中进行的SEP活动基础上响应变更。5．5．4．2规约项目宜更新并控制已批准规约的所有变更。5．5．4．3配置基线项目宜更新并控制已建立基线的所有变更。5．6生存周期过程中的并行工程项目宜依照第6章完成计划活动并应用SEP，从而为系统产品开发、生产、测试、分发、支持、培tJlI和处置制定生存周期过程和服务。生存周期过程和服务包括如下这些项：生产或维护的特殊工具和装备；生产的特殊过程；支持装备或培训或测试模拟器的软件和硬件；培训或维护手册；开发、生产和测试计划；用于测试、生产或处置的设施；与每个下游活动相关的服务规程。需要生存周期过程和服务来使产品的能力在整个它们的生存周期中能够被充分实现。项目宜将生存周期过程的制定延迟到生存周期过程所支持的产品的需求已经定义之后。生存周期过程产品和服务的并行工程阶段展示在图9中。虽然制定生存周期过程定义可以不在所要支持的产品(系统产品，子系统组装件或部件子组装件)定义之前启动，但项目仍然宜规划可应用的下游生存周期过程在使该过程可支持该产品的时候是可用的。项目宜安排好合适的生存周期过程的定义时间，以便在需要该过程来支持产品开发的时候可用。由于多数生存周期过程并没有所要支持的产品那样复杂，因此开发周期宜更短并且宜在需要时可用。5．6．1生存周期过程制定项目宜为开发、生产、测试、分发、支持、培训和处置启动可应用的下游生存周期过程的制定，以为产品及其子系统以及组装件及其部件提供生存周期支持。如果系统元素正在从供方或分包商那里获取，那么宜考虑该系统元素的生存周期支持。每个生存周期过程都像5．1到5．5中所描述的对产品那样经历同样的开发事件和活动，包括技术评审。5．6．2规约项目宜为生存周期过程和服务制定并控制与55．6．3配置基线项目宜为生存周期过程和服务制定并控制与56系统工程过程1至5．5中所描述的同样类型的规约。1至5．5中所描述的同样类型的基线。本章描述SEP(见图4)的详细要求。对于SEP的每个子过程都给出了一幅图来描述该子过程总的27 GB／T26240—2010／ISO／IEC26702：2007任务流。企业方针和规程描述了整个项目生存周期中子过程任务的一般应用和执行。项目宜根据项目范围并且依照企业方针和规程，通过增加或删除活动剪裁每个任务的活动，或者通过增加或删除任务剪裁子过程任务。6．1需求分析项目应执行需求分析任务，从而确定系统能够完成什么；系统产品按照定量、可测量的术语可以执行的程度；系统产品所运行的环境；人／机界面需求；物理／审美特性；以及影响设计方案的约束。市场要求、需求以及约束来自于利益相关方期望、项目和企业约束、外部约束和更高层的系统需求。这些都记载在需求基线中。需求基线指导SEP剩下的活动，并且表示待解决问题的定义。与需求分析相关的活动标识在图10中。项目评估并分析任务6．1．1至6．1．9中所定义的输入，以标识成本、进度以及绩效风险；定义功能和性能需求；标识冲突。进行权衡分析来解决这样的冲突，从而到达一个平衡的需求基线。权衡分析和风险评估、分析和处理任务在6．7中讨论。对于SEP的每次应用，项目对前面针对系统体系结构中更高层次所定义的需求进行适当的精化，并且为开发中的系统定义需求(见1．3中的讨论)。图10需求分析 GB／T26240--2010／ISO／IEC26702：20076．1．1定义利益相关方期望项目定义并量化利益相关方对系统的期望。利益相关方期望可能来自于市场、需方的定单、所认识到的市场机会、来自于用户的直接交流、或者来自更高层系统的需求。利益相关方期望包括：a)利益相关方希望系统(产品、生存周期过程以及想要的质量要素)完成什么(功能性需求)；b)每项功能将被完成得怎么样(性能需求)；c)系统产品运行或可能被使用的自然环境和人工环境；d)约束(例如资金；成本或价格目标；进度；技术；无需开发及可重用的项；设计特性；每天运行的小时数；开关顺序；外部接口；与生存周期过程相关的制定的现有装备、规程或设施)。利益相关方期望的定义，需要通过分析对以下各项的影响进行平衡：总体系统设计和性能以及人因工程；知识、技能和能力；易用性；可靠性；安全性；以及需要来支持生存周期过程的人的培训需求。6．1．2定义项目和企业约束企业标识并定义影响设计方案的项目和企业约束。6．1．2．1项目约束项目约束可能包括：a)在前面的SEP应用中制定的已批准规约和基线；b)工程和技术计划；c)团队分派和组织结构；d)自动工具的可用性或使用许可；e)控制机制；f)测量技术进度所需的度量；g)复用以及商用现货。6．1．2．2企业约束企业约束可能包括：a)来自于此前技术评审的管理决策；b)企业通用规范、标准或指导思想；c)方针和规程；d)领域技术；e)已建立的生存周期过程能力；f)实物、财务以及人力资源向技术工作的分配。企业可能会在技术工作上施加长期规划的约束，这可能会要求一种演化式的开发战略，从而达到项目或企业的目标。6．1．3定义外部约束项目标识并定义影响设计方案或SEP活动实现的外部约束。这些约束包括：a)公共及国际性的法律和法规；b)技术基础；c)产业界、国际性的或其他通用规范、标准和指导思想；d)与人相关的规范、标准和指导思想；e)人的易用性、招募和选择；f)竞争者产品的能力。6．1．4定义运行场景项目标识并定义那些定义了系统产品预期使用范围的运行场景。对每一个运行场景，项目定义与，q GB／T26240--2010／ISO／IEC26702：2007环境和其他系统的期望交互；人的任务及任务顺序；以及与接口连接的系统、平台或产品的物理互联。6．1．5定义有效性测度项目定义反映总体利益相关方期望和满足情况的有效性测度。关键的MOE可能包括性能、安全性、可运行性、易用性、可靠性、可维护性、培训时间和成本、负载、人的绩效要求或其他要素。6．1．6定义系统边界项目定义：a)哪些系统元素处于项目设计控制之下而哪些不受其控制；b)设计控制下的系统元素之间的期望交互以及系统边界外的外部和／或更高层的交互系统。6．1．7定义接口项目以定量的术语定义与外部和／或更高层的交互系统、平台、人和／或产品的功能和设计接rn。其中包括机械、电气、热力、数据、通讯过程、人／机以及其他交互。6．1．8定义使用环境项目为每个运行场景定义使用环境。所有可能影响系统性能的环境要素，自然或人工的，都被标识并定义。标识确保系统将导致伤亡事故的人或机器的错误或失效的可能性最小化，以及确实降低支持生存周期的人的死亡、受伤或急慢性疾病、残疾和／或工作能力风险的要素。特别地，为系统可能运行的地点及条件定义天气条件(例如雨、雪、晴、风、冰、灰尘、雾)、温度范围、地形(例如海洋、山脉、沙漠、平原和植被)、生物(例如动物、昆虫、鸟类和菌类)、时间(例如白天，夜里和黄昏)、人造物(例如振动、电磁、噪音和化学物)或其他环境因素。从对系统性能和生存周期过程的影响出发，评估其对硬件、软件和人的作用。6．1．9定义生存周期过程概念项目分析任务6．1．1至6．1．8的输出来定义开发中的系统产品的开发、生产、测试、分发、运行、支持、培训和处置所需的生存周期过程需求。6．1．9．1人力项目标识并定义用来确定支持系统生存周期过程的人的数量和构成所需的工作任务及相关的工作量。6．1．9．2人员项目评价并确定完成与支持系统生存周期过程的人相关的工作任务所需的人的经验、态度、知识、技能和能力。6．1．9．3培训项目标识并制定为人员和团队提供在指定的绩效级别上支持系统生存周期所需的知识和工作技能所需要的指令、教育、在职或团队培训。包括要开发和使用的、用于为所需要的任务提供培训的工具、装置(包括嵌入式培训系统)、培训模拟、技术、规程以及训练材料和技术手册。6．1．9．4人因工程项目标识并说明支持系统生存周期的人的那些直接作用于或约束系统性能并影响人机界面的认知、身体和感觉特性。6．1．9．5安全性项目说明引发操作、维护或支持系统的人员死亡、受伤或急慢性疾病、残疾和／或降低上作能力的重大风险的系统设训特征。6．1．10定义功能性需求为了定义系统应该能够做什么(功能需求)，项目进行功能周境分析(见6．3．1)。标识出的功能在30 GB／T26240--2010／ISO／IEC26702：20076．1．11中用来定义这些功能必须执行到什么程度并建立性能需求。通过功能周境分析标识出的功能在功能分解(见6．3．2)中被进一步分解，从而为标识并评估设计可选项提供基础。典型情况下，系统的所有需求包括功能和性能两方面，正是将系统需求看作功能和性能两个方面确保了需求是完整、一致以及可验证的。6．1．11定义性能需求项目为系统的每个功能定义性能需求。性能需求描述功能性需求必须被执行到何种程度以满足MOE。这些性能需求就是那些在功能分解分析中被分配到子功能E，并且作为测量设计方案(从综合过程演化得到，见6．5)所依照的准则的MOP。典型情况下针对每个MOE都有几个MOP，它们绑定了可接受的性能封装。6．1．12定义运行模式项目定义开发中的系统产品的各种运行模式(嵌入培训的能力、完整运行等)。那些决定运行模式的条件(环境、配置、运行等)也被定义。6．1．13定义技术性能测度项目标识技术性能测度(TPM)，它们是系统性能的关键指示器。TPM的选择通常限制为关键的MOP，它们如果不能得到满足将会置项目于成本、进度或性能风险之中。特定的TPM活动集成到SEMS中，以阶段性地确定当前已完成的成果同时根据计划的值对进度进行测量。6．1．14定义设计特性项目标识并定义开发中的系统产品所需的设计特性(例如颜色、纹理、尺寸、拟人性限制、重量及浮力)。系统标识哪些设计特性是约束，以及哪些可以在权衡分析基础上进行改变。6．1．15定义人的因素项目标识并定义影响开发中系统的运行的与人有关的要素考虑(例如设计空间限制、气候限制、视力移动、可达性，人体工程学、认知限制以及易用性)。项目标识哪些人的要素是约束以及哪些可以在权衡分析基础上进行改变。6．1．16建立需求基线任务6．1．1至6．1．15的输出记录在三个视图(运行、功能及设计)中，以构成一个建立待解决的系统问题的需求基线。运行视图描述系统产品如何为它们的用户服务。它确定了由谁来操作和支持系统及其生存周期过程，系统产品将如何在何种程度上以及在何种条件下被使用。功能视图描述了系统产品做什么以产生在运行视图中描述的所要得到的行为，并且提供用来设计视图和设计原理的方法学的描述。设计视图描述系统产品开发中的设计考虑，并且建立对技术以及装备间以及人与装备间设计界面的需求。这些视图的内容可以包括：a)运行视图：1)运行要求描述；2)系统运行分析结果；3)运行序列和场景(最好用图表示)，包括应用环境、MOE以及系统产品宜如何使用；4)系统产品宜响应的条件／事件；5)运行约束，包括MOE；6)所标识的人的角色，包括工作任务和技能需求；7)培训需求，包括如何通过正式、非正式、随带、在职或其他培训形式将人培训成为系统的部分并支持系统生存周期；8)标识需要哪些操作以确保安全；31 GB／T26240--2010／ISO／IEC26702：20079)生存周期过程概念，以包括MOE、关键M()P以及已有的产品和服务；10)与其他系统、平台、人和／或产品的运行接口；11)系统边界。b)功能视图：1)描述系统产品和生存周期过程必须做的或完成的事情的功能性需求；2)包括定性(什么程度)、定量(多少、容量)以及时间线或周期性(多长时间、多久一次)需求的性能需求；3)完成系统目标的功能序列；4)TPM准则；5)与外部、更高层或交互的系统、平台、人和／或产品之间的功能接口需求；6)运行模式；7)计划中的演化成长的功能能力。c)设计视图：1)此前批准的规约和基线；2)与其他系统、平台、人和／或产品的设计接口；3)人因系统工程元素，包括安全性、培训、完成系统功能所需的知识、技能和能力，以及信息显示和操作员控制特性；4)操作员和支持人员的特性，包括特殊的设计需求以及适用的移动、视觉或负载限制；5)信息显示和操作员控制特性；6)系统特性，包括设计限制(容量、电量、尺寸、重量)；技术限制(精度、日期格式、频率、语言)；固有的人员限制(身体和认知负载、知觉能力以及触及和人体测量限制)；以及标准化的最终项，无需开发的项和可复用性需求；7)设计约束，包括限制设计方案和／或开发规程的项目、企业和外部约束；8)设计能力以及所规划的演化式成长的能力。6．2需求确认项目应执行需求确认任务。在需求确认活动中：a)评价在需求分析中建立的需求基线，以确保其表达了标识出的利益相关方期望以及项目、企业和外部的约柬；b)评估需求基线以确定其是否充分覆盖了所有可能的系统操作和系统生存周期支持概念。如果标识出要求、约束等存在空白或要求没有适当的明确时，需求分析和确认将反复进行直到生成一个适当的需求基线。已确认的需求基线记载在集成资源库中并且作为功能分析的一种输入。同需求确认相关的任务标识在图11中。32 GB／T26240—2010／ISO／IEC26702c2007图11需求确认6．2．1与利益相关方期望比较项目根据利益相关方的期望对所建立的需求基线进行分析和比较，以确保技术需求充分反映了利益相关方对系统产品及生存周期支持概念的要求、需求和约束。涉及直接的利益相关方参与(最终用户、市场等)和／或利益相关方所提供的需求文档。6．2．2与企业和项目约束比较项目根据企业和项目约束对所建立的需求基线进行分析和比较，以确保技术需求正确反映且没有超出企业和项目方针及规程、可接受的风险级别、计划、资源、技术限制、目标、决策、标准或其他文档化的约束。6．2．3与外部约束比较项目根据外部约束对所建立的需求基线进行分析和比较，以确保所描述的技术需求正确反映且没有超出所适用的国内和国际法律(包括环境保护、有害原料禁止列表、废物处理以及社会责任法律)；正确陈述了与已有的或演化中的系统、平台或产品之间的外部接口需求；包括了所适用的通用规范以及影响开发的标准条款；同时充分定义了竞争产品的能力和特性。6．2、4标识差异和冲突项目对6．2．1至6．2．3的确认任务中出现的差异和冲突进行标识和定义。每个差异或冲突通过需求分析迭代来解决，从而精化需求基线。6．2．5建立已确认的需求基线一旦所建立的需求基线中的差异和冲突都得到满意解决，需求基线就可以认为是有效的。这个已33囱 GB／T26240—2010／ISO／IEC26702：2007确认的需求基线将作为功能分析(见6．3)的输入使用并记载在集成资源库中。6．3功能分析项目应执行功能分析任务从而实现以下两个相关的目标：E1)以更清楚的细节描述需求分析定义的问题；b)将系统功能分解为应该被系统设计元素(例如子系统、部件和零件)满足的更低级别的功能。这是通过将已确认的需求基线转化为功能体系结构来完成的。功能体系结构描述了通过将一组系统功能分解为它们的子功能所得到的子功能的功能安排以及顺序排列。功能分析宜在不考虑设计方案的情况下进行。在合成(见6．5)期间产生的子功能组设置了指导产品和子系统方案定义的准则。与功能分析相关的活动标识在图12中。厂i——一、I二藿黜J’、-．．．．．．．．．．．．．．．．．．．．．．．．．．√11--------------------●-一1‘6．3．1功能周境分析l!竺竺J串甲车‘㈨．16．3．2．2、632立?自国。。。．。。。。．。l。。。l。。。．。lI辈I睦型I孥I卜到I厅与I三鍪秽J、、．．．．．．．．．．．．．．．．．．．_／图12功能分析过程6．3．1功能周境分析系统分析每个系统功能来确定实现系统目标所需要实现的系统对于激励(输入)的响应(输出)。6．3．1．1分析功能行为进行分析以理解系统在各种条件下的功能行为并评估功能体系结构的完整性。分析宜包含使用模34 GB／T26240--2010／ISO／IEC26702：2007型受到反映预期的运行使用和环境的各种受压及非受压情形的运行场景的功能模型模拟或激励。6．3．1．2定义功能接口随着系统的功能分解，交互功能之间的接口也被创建。项目标识这些接口，并定义它们的功能交互，例如初始和结束状态，或输入和输出。6．3．1．3分配性能需求性能需求被划分为可分配的集合被直接分配到功能上。非直接可分配的需求，例如行驶里程，宜通过适当的工程技术和分析转化为导出的性能需求，例如燃油容量、引擎功率以及车辆阻力。项目将系统性能需求分配到功能上并进行记载，从而提供可追踪性并为此后的变更提供便利。6．3．2功能分解项目将系统分解为子功能，从而定义：a)可替换的子功能安排和序列；b)它们的功能接口；c)它们的性能需求。功能分解的程度依赖于建立一个对系统应完成什么功能的清晰理解。进行权衡分析和风险分析(见6，7)，从而选择一种平衡的子功能集合并将性能需求分配到子功能上以保证功能体系结构满足系统需求。6．3．2．1定义子功能功能根据它们的功能行为、运行状态和模式、功能时间线、数据流控制条件、功能失效模式及后果、以及所需的潜在危险监控功能进行分解。探究可替换的子功能安排和排序以保证一组平衡的子功能。项目分析所得到的子系统安排以确定冗余程度。所标识出的那些并非安全性、可靠性或其他关键需求所特别需要的冗余功能宜被排除。项目选择出最好的功能体系结构，并记载在集成资源库中。6．3．2．2定义子功能状态和模式项目分析功能体系结构来标识和定义子功能表现出不同行为的状态和模式。分析包括一个或--N子功能的开始和结束条件之间的状态或模式迁移。6．3．2．3定义功能时间线项目分析子功能顺序以及它们的行为，从而为每一个运行场景标识并定义一个功能时间线。每一个子功能的执行时间范围以及导致正常和反常执行的条件在功能时间线的支持下被标识出来。6．3．2．4定义数据和控制流项目分析子功能顺序及其行为，从而为每一个运行场景标识并定义子功能之间的数据流。这些数据流在数据流图或相关的面向对象的记法中进行捕获。针对每一个运行场景的功能体系结构执行控制被标识和定义，并在控制流图或相关的面向对象的记法中进行捕获。6．3．2．5定义功能失效模式及后果项目分析潜在的功能失败模式并进行优先级排序以定义失效后果并标识对缺陷侦测和恢复功能的要求。建立功能可靠性模型以支持针列每个运行场景的系统有效性分析。对代表重大安全、性能或环境危害的失效进行建模以完整理解系统影响。6．3．2．6定义安全监控功能项目分析子功能和子功能聚集，从而标识那些可能导致人员受伤、财产或产品损失、或环境影响的运行危害。附加的功能需求被导出并定义来监控危险的运行状况、通知或警告操作者即将发生的危害。6．3．3建立功能体系结构项目建立同开发层次相适应的功能体系结构，以定义性能需求的分配，设计方案宜在此基础上通过合成(见6．5)确定。在合成之前，功能体系结构宜被验证以保证其满足已确认的需求基线。6．4功能验证项目应进行功能验证任务以评估功能体系结构满足已确认需求基线的完整性，并且产生经验证的35 GB／T26240--2010／ISO／IEC26702：2007功能体系结构来作为合成的输入。同功能验证相关的任务标识在图13中。6．4．1定义验证规程项目定义验证已建立的功能体系结构的规程。6．4．2进行验证评价项目实施已定义的规程来验证已建立的功能体系结构所描述的每个需求和约束向上可追踪到已确认的需求基线，并且记录在需求基线中的所有高层系统需求和约束都向下可追踪到功能体系结构。匿图13功能性验证6．4．2．1验证体系结构完整性项目验证需求基线中所包含的系统功能和运行需求都可追踪到功能体系结构。6．4．2．2验证功能和性能测度项目验证需求基线中所有的系统级功能和性能需求都可追踪到已建立的功能体系结构。36 GB／T26240—2010／ISO／IEC26702：20076．4．2．3验证约束的满足项目验证需求基线中所有的系统级方针、规程、标准、功能和设计约束都可追踪到已建立的功能体系结构。6．4．3标识差异和冲突项目标识任务6．4．2的验证评价活动所产生的差异和冲突。如果发现不完整，功能分析任务(见6．3)将反复进行以纠正空缺。如果功能体系结构需求无法向上追踪到已确认的需求基线，宜判断是因为功能分析中引入了不属于原需求的功能或性能需求，还是需求基线中本来就忽略了一些合理的功能或性能需求。前者需要反复进行功能分析(见6．3)来消除那些不属于原需求的功能或性能需求。对后者来说，宜重复进行需求分析(见61)和需求验证(见6．2)的步骤，来生成一个修订过的、有效的需求基线。6．4．4建立经验证的功雒体系结构功能体系结构以满意地解决6．4．3中识别的差异和冲突为依据进行验证。经验证的功能体系结构，连同证明结构合理性的原理、所进行的权衡分析和关键决策都记载在集成资源库中。这个经验证的功能体系结构用于合成中，从而生成满足已确认的需求基线定义的利益相关方期望以及公众接受的设计方案。6．5合成项目应执行合成任务，其目的在于定义设计方案以及标识子系统以满足经验证的功能体系结构需求。合成将功能体系结构转化为规定了系统元素的安排、它们的分解、接口(内部和外部的)和没计约束的设计体系结构。合成活动包括从一组可选项中选取首选的方案或安排，并且理解相关的成本、进度、绩效和隐含的风险。系统分析(见6．7)根据需要被使用来评价各可选项；标识、评估及量化风险，并选择适当的风险缓解方法；以及理解成本、进度和绩效影响。随着子系统需求被定义，生存周期过程的要求、需求和约束的标识也完成了。与合成相关的任务标识在图14中。6．5．1功能分组和分配项目以一种允许它们向设计元素分配的方式将经验证的功能体系结构的通用功能和子功能分组为逻辑功能元素。向设计元素的分配发生在确定了功能元素可以被已有或新开发的项实现之后。如果功能元素需要分解才能进行分配，那么执行功能分解(见6．3．2)对功能元素进行充分的划分，从而使其能在硬件、软件和人之间进行分配。建立并记录需求跟踪以保证所有功能都已分配到系统元素中；每个系统元素至少执行一种功能。6．5．2识别设计方案可选项项目为在6．5．1中标识的功能元素生成可选的设计方案。这些解决方案宜由下列一个或多个元素组成：硬件、软件、材料、数据、设施、人员和技术。任务6．5．3至6．5．14完成后，对呵选项以及可选项组合进行分析以确定哪个设计方案最能满足所分配的功能和性能需求、接口需求和设计约束，并且最能增加系统或更高层系统的有效性。当这些任务完成后，专业工程师与设计工程师一起工作，以保证需求，例如可靠性、可用性、可维护性、可支持性、易用性、安全性、健康因素、保密安全性、可生存性、电磁兼容性以及无线电频率管理，都能被适当地设计。此外，每个可选系统产品方案和方案组合的生存周期过程需求也被标识。6．5．3评估安全性和环境性危害项目分析6．5．2的可选项及可选项组合．以标识对系统、系统和支持系统生存周期过程中涉及的人，或环境的潜在危害。应该特别注意对系统的安全运行进行评估，以及对与到目前为止已开发的系统生产、测试、分发、运行、支持、培训或处置相关的污染物、有害废物或副产品进行评估。6．5．4评估生存周期质量要素项目评估6．52的可选项以确定质量要素(可生产性、可测试性、易分发性、易用性、可支持性、可培训性和可处置性)已经被包含在解决方案中的程度。此外，项目评估相关的生存周期过程要求、需求和过程约束是否得到标识和定义。 GB／T26240--2010／ISO／IEC26702：2007图14合成过程囱 GB／T26240--2010／ISO／IEC26702：20076．5．5评估技术需求项目对6．5．2的可选项进行评估以确定那些使设计方案有效所必需的技术要求。宜对与任何为了满足需求而引入的新的或高级的技术相关的风险进行标识和评估。项目评估可选项以确定那些使系统有效所必需的人的需求。宜分析并评估分配给人的任务、角色和工作以确定作为系统一部分的人是否具有所必需的知识、技能和能力。还宜对培训和人员梯队进行评价以确保他们满足指定的需求。6．5．6定义设计和性能特性项目标识并记载设计可选项的设计和性能特性。这包括对人的物理和认知负载水平的预估或测量。宜对与生存周期质量要素相关的设计特性和人因工程元素进行识别和评估。6．5．7定义物理接口项目标识并定义产品、子系统、人、生存周期过程以及与高层系统或交互系统的外部接Izl之间的物理接口。影响设计的物理接口包括通信、数据、支持、测试、控制、显示、连通性或子系统、产品、人或其他接口连接系统或更高层系统之问交互的资源补充特性。6．5．8标识标准化机会项目分析6．5．2的可选项以评估使用标准化的最终项在技术和经济上是否可行。6．5．9标识现货的可用性项目分析6．5．2的可选项以确定现货项(无需开发的硬件或软件)的可用性。可以对每个标识出的现货项进行评估以确定成本效益、数量、可用性、可支持性以及供方和／或其产品的生存能力。6．5．10标识自制或购买可选项项目对设计可选项进行经济分析以支持自制或购买决策。该分析宜明确对于该项目而言生产设计元素与转向确定的供方相比是否具有更好的成本效益。6．5．11开发模型和原型项目开发模型和／或原型以辅助完成下列任务：a)标识并减少与集成可用的和新兴技术相关的风险；b)验证设计方案(由硬件、软件、材料、人、设施、技术、数据、和／或服务构成)符合所分配的功能和性能需求、接口需求、负载限制和约束；c)验证设计方案满足功能体系结构和需求基线中的需求。宜维护模型、数据文件和支持文档，影响需求、设计或决策的每个模型和数据文件版本都宜保存在集成资源库中。模型可以是数字的、部分的或完整的，也可以是硬件、软件或二者的结合，或者可能包括用于易用性测试和负载测量的人的模型或人控制的模拟或实物模型。6．5．12评估失效模式、后果和严重程度项目评估设计可选项的失效模式、后果和严重程度。宜对设计可选项的硬件、软件和人元素进行分析，宜应用历史或测试数据，以精化对每个可选项成功执行可能性的预估。失效模式及后果分析(FMEA)宜用来标识设计方案的优缺点。对于严重的失效，项目实施危险性分析以根据危险性评级对每个可选项进行优先级排序。分析的结果用于指导进一步的设计工作以提供冗余并支持适度的系统退化。6．5．13评估可测试性要求项目评估设计可选项的可测试性以确定支持运行或维护考虑的内建测试(BIT)和／或缺陷隔离测试(FIT)需求。对于由操作员、用户或现场支持工程师维护的那些元素宜提供BITF1T机制。BIT—FIT可以用于支持较低层次维护动作的诊断操作。6．5．14评估设计的演化能力项El评估设计可选项以确定设计方案对演化或再工程、适应新技术、提高性能、增加功能，或当系统处于生产或市场中时加入其他有成本效益或竞争力的改进的能力。宜标识可能阻碍系统演化能力的限制，分析和定义解决这些限制的方法。项目宜对产品执行配置管理来保证具备演化能力的产品能以较39 GB／T26240--2010／ISO／IEC26702：2007好的成本效益进行再工程。演化系统的可支持性可能要求支持过程与产品一起演化。这种考虑可能对支持资金和培训要求具有很大影响。6．5．15设计定案项目针对所选择的可选项进行设计定案。对设计元素之间的接口(内部的和外部的)指派和描述进行定案。6．5．16启动演化式开发如有必要，项目对任何选择了次优技术方案而非更高风险的技术，并且该元素或相接口的元素包含演化能力设计的设计元素，启动一次演化式开发。6．5．17产生集成数据包项目根据需要完成制图、制表、软件文档、手工规程等，从而在集成数据包中记载所选择的设计元素。6．5．18建立设计体系结构项目建立与开发层次相适应的设计体系结构，以记载设计方案和接口。设计体系结构包括需求追踪及分配矩阵，它们捕获功能和性能需求在系统元素之间的分配情况。设计体系结构定义宜与权衡分析结果、设计原理和关键决策一起记载在集成资源库中，从而提供需求与体系结构之间向上和向下的追踪能力。宜对设计体系结构进行验证(见6．6)，从而展示体系结构同时满足已确认的需求基线和已验证的功能体系结构。6．6设计验证项目应执行设计验证任务以确保：a)设计体系结构最低层次的需求，包括衍生需求，可追踪到已验证的功能性体系结构；b)设计体系结构满足已确认的需求基线。与设计验证相关的任务标识在图15中。6．6．1选择验证方法项目选择验证设计体系结构、评估设计完整性以及确定MOE和MOP满足性的方法。6．6．1．1定义审查、分析、演示或测试需求为了评价功能和性能需求以及在设计体系结构中标识的设计特性是否得到满足，项目选择适当的验证方法[审查、分析(包括实物模型或模拟)、演示或测试]。设计一个验证矩阵来将验证方法追踪到功能性体系结构和需求基线中的需求。项目还要选择将会用到的模型或原型，它们可以是部分的或完整的。并且可以包含或不包含人员，取决于验证任务的目的和目标。6．6．1．2定义验证规程项目为所选择的每个验证方法定义规程，标识每个验证规程的目的和目标，标识测试前后的动作，并且定义确定规程在计划的和非正常条件下成功或失败的准则。6．6．1．3建立验证环境项目为所选择的方法和所定义的规程建立环境。环境考虑包括设施、装备、工具、模拟、测量装置、人员和气候条件。环境宜在验证执行之前进行检验。6．6．2执行验证评价项目执行验证评价以保证每项需求和约束都能追踪到已验证的功能体系结构，并且设计元素方案满足已确认的需求基线。验证结果被评价以保证设计元素方案所展现的行为与预期相符并满足需求。6．6．2．1验证体系结构完整性项目验证：a)设计元素描述可追踪到功能体系结构的需求(向上追踪)；b)功能体系结构的需求被分配并追踪到设计体系结构。所有内部和外部设计接口宜能向上及向下跟踪到它们的源需求。40 GB／T26240一2010／ISO／IEC26702：2007图15设计验证6．6．2．2验证功能和性能测度项目验证来自6．6．1所定义活动的评价结果满足已确认需求基线的功能和性能需求(包括人的性能需求)。 GB／T26240—2010／ISO／IEC26702：20076．6．2．3验证约束满足性项目验证：a)来自6．6．1所定义活动的评价结果满足功能体系结构的约束，包括接口；b)已建立的设计体系结构的约束可追踪到已确认的需求基线。6．6．3标识差异和冲突项目标识产生于验证活动的差异和冲突。当差异显示出不完整性，合成任务(见6．5)或功能分析任务(见6．3)要重复进行以纠正遗漏。当评价结果没有验证功能体系结构需求，或设计体系结构需求无法追踪到功能体系结构时，宜确定合成过程中是否引人了不需要的功能和／或性能需求或设计元素，或者是否引入了合理的功能和／或性能需求而且需要在功能体系结构中反映。前一种情况表明合成活动(见6．5)需要重复进行以消除不需要的功能和／或性能需求。对于后者的差异或冲突，宜重复进行需求分析直到功能验证(见6．1至6．4)，以产生一个新的已确认的需求基线和经验证的功能体系结构。当设计体系结构需求不能追踪到已确认的需求基线时，可能需要重复合成活动以消除不需要的功能和／或性能需求；或者可能要根据需要重复SEP活动，以将那些遗漏的需求包括进来。6．6．4已验证的设计体系结构根据对6．4．3中标识的差异和冲突解决的满意程度对设计体系结构进行验证。经验证的设计体系结构，连同证明体系结构合理的原理、所进行的权衡分析和关键决策，都被记载在集成资源库中。这个经验证的设计体系结构用来构成系统的规约树，当与已验证的生存周期过程设计体系结构相结合时，就构成了系统体系结构。6．6．5已验证的生存周期过程的设计体系结构系统完成需求分析、功能分析和合成任务，以标识、定义并设计用于生存周期过程的体系结构。项目执行6．1至6．4的任务来验证每个生存周期过程产品的设计体系结构。购买或生产与每个生存周期过程相关的产品，并适时与同当前过程或其他过程相关的其他产品集成，以支持关键的技术事件。6．6．6已验证的系统体系结构完整的系统体系结构由所有生存周期过程设计体系结构和产品设计体系结构组成。系统体系结构的验证是根据完成产品及其生存周期过程产品验证的满意程度进行的。6．6．7建立规约和配置基线设计体系结构验证之后，项目为设计体系结构的各个元素开发／更新与开发阶段相适应的(见第4章)产品和接口规约。此外，项目为设计体系结构的各个元素开发／更新适当的配置基线。设计体系结构规约(产品和接口)的层次结构构成了与开发阶段(见图5)相适应的规约树。规约树描绘了产品的制作、生产、购买或编码所必须遵照的规约元素。规约记载在集成资源库中，并在SEP的下一次应用中使用。针对下一层次开发的设计方案可以满足这些规约。6．6．8制定系统分解结构(SBS)项目为所设计的系统制定一个SBS，包括生存周期过程需求(见图6)。SBS记载在集成资源库中，并被用于下一开发阶段技术活动的组织和管理。6．7系统分析项目应为以下目的而执行系统分析任务：解决在需求分析中标识的冲突、在功能分析中分解功能需求并分配性能需求、评价可选设计方案的有效性并在合成中选择最佳设计方案、评估系统有效性、并在整个系统工程工作中管理风险因素。系统分析为建立一组平衡的需求并得到一个平衡的设计提供严格的量化基础。与系统分析相关的任务标识在图16中。即使没有进行权衡分析，也宜完成对系统有效性的总体评估。6．7．1评估需求冲突项目评估需求分析中标识的需求和约束之间的冲突，以在必要的地方标识出可替换的功能和性能需求。进行需求权衡分析和评估，从而根据风险、成本、进度和绩效影响标识推荐的需求和约束集。42 GB／T26240--2010／ISO／IEC26702：2007图16系统分析过程43 GB／T26240—2010／ISO／IEC26702：20076．7．2评估功能可选项项目在功能分析期间对可能的面向功能分解以及可分配性能需求向子功能的分解的可选子功能安排进行评估。进行功能权衡分析和评估，从而根据风险、成本、进度和绩效影响为每个功能和性能需求分配标识推荐的子功能集。6．7．3评估设计可选项项目在合成过程中对来自于已验证的功能体系结构以及标识出的可选设计中的功能的潜在分组和分配进行评估。进行设计权衡分析和评估，从而根据风险、成本、进度和绩效影响来标识推荐的设计权衡。6．7．4标识风险因素项目对来自于需求分析、功能分解产生的子功能安排、对功能元素的子功能分配、合成过程所作出的设计决策以及设计体系结构的设计元素中的需求和约束进行评估，以标识出影响项目成功完成的风险因素。这些评价宜从整个生存周期的观点出发进行。风险标识宜以某种方式去认识下列问题：a)可能导致风险因素出现的情况以及风险出现的可能性；b)如果风险因素出现如何发现它；c)风险因素如何影响成本、进度和绩效。标识出的风险根据其对系统的成功开发的危害程度进行排序。宜根据开发阶段标识出可接受的风险等级，从而为建立并监控风险减少活动以及缓解不可接受的风险提供基础。6．7．5定义权衡分析范围项目宜定义将要执行的权衡分析的范围。权衡分析可以是：a)简单判断基于分析师或设计师的判断做出的选择，并不需要更加正式研究的严格性并且选择的结果也并不是太重要；其中一个可选项明显优于其他的；和／或可能没有时间采用更正式的方法(完成SEP任务中进行的大部分权衡分析都是简单判断类型的)；l，)非正式的遵循与正式的权衡分析相同的方法，但不需要正规地进行记载并且对于需方而言并不是很重要；c)正式的一正式地执行而其结果将在技术评审中进行评审。需要完整地定义非正式和正式的权衡分析的目标、执行、数据收集要求、活动进度、结果分析和期望结果。每个权衡分析都是为了在相互竞争的可选项中进行选择以在可接受的风险水平内支持利益相关方需要、系统有效性、按成本设计或生存周期成本目标而进行的。6．7．5．1选择方法学和成功准则项目根据权衡研究的定义、其重要性级别以及工具、设施、特殊装备和相关资源的可用性选择进行权衡研究的总体方法、资源和规程。项目也会列举选择准则集合，其中包括那些刻画什么使得一个特定可选项可取的因素，例如成本、进度、绩效和风险；生存周期质量要素；复用；以及尺寸、重量和能耗。不利和有利性质宜被概括为准则。6．7．5．2标识可选项项目标识并列举需要评价的可行的可选方案。每个可选项宜按照完整性进行比较，并且宜进行敏感性分析以认识每个可选项如何经受环境、技术基础或演化策略范围内的变更。6．7．5．3建立权衡研究环境项目为每个准则建立刻画各可选项满足准则程度的度量。此外，项目为每个准则设定权重因子，区别对于权衡分析定义的重要程度。必要时，建立模型(表现性的或模拟性的)来支持正式或非正式的权衡研究的执行。模型的选择依赖于权衡分析的状况、开发阶段、所需要的信息种类以及可选项的利益特性。模型在权衡分析中应用前宜进行确认。6．7．6进行权衡分析项目完成任务6．7．6．1至6．7．6．4至合适的程度，从而为下列活动完成权衡分析：44 GB／T26240--2010／ISO／IEC26702：2007a)需求分析以同时解决与利益相关方／市场要求、需求和约束之间的冲突并且满足它们；b)功能分析以支持将功能分解成子功能并分配性能需求；c)合成以支持设计决策。正式和非正式的权衡分析在受控条件下进行，以产生与各个可选项相关的数据。记录并分析权衡分析的结果，以量化各可选项对系统或技术工作的影响。这些结果将与成功准则进行比较，以确定推荐哪个可选项。6．7．6．1分析生存周期成本项目针对在权衡分析或系统有效性评估中考虑的可选系统方法，进行项目和需方的成本分析。生存周期成本分析：a)提供必需的成本信息以支持权衡分析决策；b)为系统有效性评估提供必需的成本信息；c)包括开发、生产、测试、分发、运行、支持、培训和处置成本；d)包括所建立的按成本设计目标，对这些成本的当前估计以及这些成本中已知的不确定性；e)标识所提议的变更对生存周期成本的影响。6．7．6．2分析系统和成本有效性项目分析系统有效性和生存周期成本之间的关系以：a)确定绩效对成本的影响；b)将增加的价值认识为成本的函数；c)支持性能目标和需求的标识；d)支持性能向功能的分配。系统和成本有效性分析在生产、测试、分发、运行、支持、培训I和处置的生存周期过程上进行，从而支持将生存周期质量要素包含进系统产品设计中，同时支持对生存周期过程的功能和性能需求的定义。这些分析的结果用于评价权衡分析可选项以及系统的有效性评估。6．7．6．3分析安全性和环境影响项目标识与系统实现相关的安全性和环境影响。宜标识适用的环境法律和规章，并且项目宜保证任何可选方案都遵守这些法律和规章。项目完成环境影响和安全性分析，以确定对系统产品的影响以及系统产品产生的影响，以及它们的生存周期过程对于环境或人员的影响。在可能的范围内应尽量避免对环境存在已知危害的材料使用或副产品的生成。在无法避免的地方，可以为适当地处理、存储和处置有害材料或副产品制定规定。这些分析的结果影响权衡分析的推荐以及对系统有效性的评估。6．7．6．4量化风险因素项目基于对不良后果出现可能性，对已标识的风险因素对系统或考虑中的可选项的影响进行量化。对于系统有效性评估，目前为止开发的系统体系结构的每一个元素都被评估以确定什么会出错，以及如果出错会对系统造成什么影响。对于权衡分析，生存周期成本、系统和成本有效性以及环境分析活动中评估的风险级别将进行排序，并作为权衡分析推荐的一部分进行报告。6．7．7选择风险应对方案项目评估各种风险应对方案以选择那些可以以与当前开发阶段和项目设置的风险管理方针相一致的方式缓解风险的方案。对于可以通过降低可能性和／或影响得以减轻的风险，可以在给定成本、进度和绩效影响及已计划的缓解方法下被接受。宜完成风险应对方案分析，以对成本以及对风险的可能性和影响的效果进行量化。项目宜选择那些可行的并且以最佳成本／收益率将风险降低到可接受程度的风险应对方案。实施风险应对缓解工作后预期的残余风险宜进行标识和量化。在整个风险标识、量化和应对过程中，从更低的系统体系结构层次直到系统层次都需要集成，以理解原因与后果的相互作用。减轻风险的方法以及预期的残余风险都包含在风险减轻计划中，该计划包含在权衡分析推荐以及系统有效性评估报告中。完整的风险减轻工作记载在工程计划中，并被集成到主进度中以用于开发阶段，并45 GB／T26240--2010／ISO／IEC26702：2007在适当的技术评审中简要报告。6．7．8选择可替换的推荐方案项目利用权衡分析的结果和风险减轻计划信息向决策者推荐首选项。项目宜对权衡分析进行评估以确保方法学和数据收集手段足以支持公正和完整的评价。每个推荐宜根据配置和成本、进度、绩效和风险影响进行陈述。6．7．9权衡和影响项目记载所推荐的权衡可选项以及相应的影响，并将结果呈现给SEP活动中合适的决策者，他们执行或要求进行权衡分析。最终的可选项选择在已建立用来决定可取方案的准则基础上作出。关键的权衡分析活动、决策、原理和推荐都记载在集成资源库中。6．7．10设计有效性评估项目基于评估和分析的结果确定当前系统设计的有效性。这些评估和分析的结果记载在集成资源库中，并在合适的技术和项目评审中进行概述。6．8控制项目应为了管理并记载SEP活动的目的而执行控制任务。与控制相关的任务标识在图17中。输出和测试结果、SEP活动的执行计划(工程计划、主进度表和详细进度表)以及工程专家生成的技术计划都受项目控制。控制任务包括下列内容：a)一份SEP活动及结果的完整和最新的描述，用于完成其他活动；b)对于SEP未来的应用的计划和输入；c)生产、测试和支持信息；d)提供给技术和项目评审的决策者的信息。6．8．1技术管理项目管理SEP的任务和活动以控制产生的数据、设计方案的配置、接口、风险和技术进度。项目需要维护恰当的人员、设施、装备和工具；管理成本和进度；根据需要重新计划开发活动；协调与利益相关方的技术交互；确保对技术人员和团队成员的适当培训；测量技术进展；以及协调完成本标准的系统工程任务所需的技术和业务专家之间的活动。6．8．1．1数据管理项目进行数据管理以支持整个技术工作中对所需要的技术数据的开发、控制和交付。数据管理活动包括设置合适的捕捉并保存设计数据和模式、工具和模型的存储库和规程。与技术工作相关的数据应易于访问，并宜在整个系统生存周期过程中进行维护。采取安全措施以保证数据完整性和保密安全性，避免数据的无意丢失或修改。项目有责任确保对数据进行收集、存储和控制并对演化中的产品设计、规约和基线的适当的配置管理可用。宜对数据管理和设计捕获活动进行协调。6．8．1．2配置管理项目计划并实现以下功能：a)标识将受控制的最终项(通过规约、接口控制图／文档和配置基线)；b)工程变更控制；c)状态报告；d)配置审核。与配置管理相关的数据在整个系统生存周期中都是易于访问的。项目建立并维护配置控制委员会来处理、评审和批准对最终项的工程变更。6．8．1．3接口管理项目计划并实现接口定义的功能、接口控制、接口兼容性评估和接口协调。与接口管理相关的数据在整个系统生存周期中都是易于访问的。项目建立并维护接口工作组来处理、评审并推荐对接口变更的批准。46 GB／T26240—2010／ISO／1EC2670212007图17控制过程6．8．1．4风险管理项目宜进行风险管理以系统地对项目满足成本、进度和绩效目标的能力中的不确定性进行控制。项目执行直接影响技术工作的那部分风险管理，包括风险管理准备、风险评估、风险应对方案评估和风险控制。这些活动描述如下：47 GB／T26240--2010／ISO／IEC26702：2007a)风险管理准备包括为各个开发阶段标识可接受的风险等级；标识潜在的风险来源；标识并评价风险管理工具和技术；培训团队成员以完成风险管理活动；决定所发生的分析和决策应该使用什么方法记载；以及决定如何捕获、处理和发布风险管理信息；b)风险评估包括标识并描述那些可能导致不良后果的情况；量化这些情况以确定它们发生的可能性以及潜在的成本、进度和绩效影响；对风险进行排序并将这些风险进行集成，从而为SBS的每个元素产生与开发阶段相适应的风险评估；c)风险应对方案评估包括评价风险应对方案以确定那些可行并且将风险降低到可接受水平的方案。更低层次上的风险应对方案宜与可行并且为技术工作和项目提供最佳的成本、进度、绩效和风险平衡的更高层方案进行集成；d)风险控制包括为了提供当前的风险信息并保证风险处于可接受水平之内而对风险进行持续评估。6．8．1．5基于执行的进度测量项目在主进度表、TPM、成本和进度执行测量以及技术评审的帮助下，对技术工作的进度进行测量、评价和追踪。与这些测量相关的活动描述如下：a)对于那些应该被完成以通过一个定义的技术事件的SBS元素，主进度表标识它们的任务、活动以及相关的成功准则。主进度表提供最高层的过程控制和进度测量，以：1)保证所需的技术任务的完成；2)展示进展的成果和成熟度；3)保证完整的、各学科交差的信息可用于决策和事件；4)展示为了满足技术任务、需求和目标对于成本、进度和绩效风险的控制。b)如果适当选取，TPM将是逐步评估技术进展的关键。每个关键性技术参数宜相对于时间进行追踪，包括所确定的进度检查日期以及达到完全符合的日期。关键技术参数通过预估、分析或测试并且将度量值累积到系统层次关联到SBS的较低层元素进行测量。TPM还被用来：1)评估与需求的符合性；2)评估与技术风险等级的符合性；3)触发对已标识的差异的恢复计划的制定；4)检查超出需求的性能的边际成本效益。项目向项目管理者报告超出承受范围的测量，使得可以采取所需要的纠正动作。c)成本和进度执行测量根据已执行工作的实际成本、已执行工作的计划成本以及已规划工作的计划成本对进展进行评估。计算得到的成本和／或进度差异量化了所遇到问题的影响。成本和进度执行测量与TPM集成以提供当前成本、进度和绩效影响，同时为所标识的差异提供了集成的纠正动作。d)技术评审在SEP的一次应用和／或一个开发阶段结束时进行，以确保所有的主进度准则都得到满足；评估当前的开发成熟度以及产品满足需求的能力；确保需求的可跟踪性以及决策的合理性；以及评估与生存周期下一阶段开发所需要的和为其准备的投资相关的风险。第5章描述了所需要的评审和审核以及它们与生存周期活动的关系。6．8．2追踪系统分析和测试数据项目收集、分析并追踪来自系统分析的数据以记载活动、原理、推荐和影响，以及来自测试的数据以记载结果、差异和后续活动。6．8．3追踪需求和设计变更项目对数据进行收集和分类以追踪需求和设计变更，以及维护变更源、处理过程和批准之间的追踪关系。48 GB／T26240—2010／ISO／IEC26702120076．8．4追踪项目计划进度项目对反映计划活动的数据进行收集和分类，同时根据工程计划、主进度表和详细进度表对进度进行追踪。对计划的偏离及所需的变更宜预先进行申请，并且只在批准的情况下进行。6．8．5根据工程计划追踪进度项目对反映计划活动的数据进行收集和分类，同时根据工程和技术计划对进度进行追踪以确定对计划的偏离以及所需的变更，并记载变更、决策和完成情况。6．8．6追踪产品和过程度量项目收集、分析并追踪产品和过程度量以：a)确定需要项目管理关注的技术领域；b)确定利益相关方满意和公众接受程度；c)提供新产品的成本和进度预估，对利益相关方提供更快的响应。在每个开发阶段中预先确立的控制点上，收集、追踪并报告度量，从而使：1)质量系统的建立以及资源高效使用的实现；2)系统质量和生产率的总体评价；3)与所计划的目的和目标进行对比；4)问题的早期发现；5)SEP的基准检查。6．8．7更新规约和配置基线项目更新规约和配置基线以反映配置控制委员会所批准的所有变更。原始的配置基线与批准的变更一起为后续的技术工作提供了基础。6．8．8更新需求视图和体系结构项目更新需求视图和功能、设计和系统体系结构以反映由需方、系统分析、确认和验证偏离或管理决策带来的变更。更新后的需求基线或功能、物理或系统体系结构将用于后续的SEP活动。6．8．9更新工程计划项目宜更新工程计划以反映由需方、系统分析、成本或进度偏离、或管理决策带来的变更。更新宜包括SEP以及对生存周期下一阶段的进度计划活动。6．8．10更新技术计划项目宜更新技术计划以反映由需方、系统分析、计划活动偏离或管理决策带来的变更。更新宜包括对生存周期下一阶段的进度计划活动。6．8．11集成资源库项目建立并维护从任务6．8．1至6．8．10的所有相关数据和信息的资源库。该库包含所有SEP使用和生成的重要信息，并且描述了系统开发的当前状态及其评价。推荐使用电子介质。作为共享资源，该资源库需要是准确、无歧义、保密安全、可生存、授权用户容易访问以及完整的。 GB／T26240—2010／ISO／IEC26702：2007A．1系统工程过程附录A(资料性附录)系统工程在企业中的角色SEP为产品开发提供了一种聚焦的方法，试图在与产品生存周期生存能力相关的所有因素与全球市场中的竞争能力二者间取得平衡。该过程为考虑可选的设计和配置提供了一种结构化的方法。图A．1提供了SEP及其在企业中的角色以及建立与产品供应相关的系统设计的外部环境的一个视图。外部环境——法肇——标准和通用规范——a然约束——人I鳓束——技术基础——竞争产品圈A．1企业内的系统工程环境SEP每次被递归应用于一个开发层次。首先，它被应用来标识满足市场机会的最佳概念或方法。这可以是针对一个全新产品／系统的概念，或者是针对一个已建立产品的增量改进的一个概念。过程的第二次应用通过全面描述产品／系统定义并建立配置基线为这些概念增加价值。这次应用为下次应用中的完成更加详细的整个系统的子系统、部件和系统元素的工程开发或者正在进行增量改进的已建立50 产品的合适部分提供了基础。A．2企业内部的系统工程GB／T26240--2010／Iso／iEc26702：2007图A．1中描述的目的是将系统工程表示为负责建立产品设计，以及并行建立开发、测试、生产、支持、运行、培训、分发和处置过程的总的技术工作。因此，术语“系统工程”意味着总体的系统观点宜应用到系统开发中。企业宜关注于两个关键过程从而实现产品的商品化并取得利益相关方和公众的接受。SEP建立了产品的设计及其支持生存周期基础设施。生产过程对原材料、零件等进行转换，并依照集成数据包的规约和指示将它们装配为最终的产品。接下来的各条讨论图八1中涉及的一些的通用概念。A．2．1市场机会企业可能发现来源于市场研究、研发活动或技术应用的机会。在这种情况下，企业并不是对明确定义的利益相关方需求或要求进行回应，而是试图通过创新来激发产品认同。有的情况下，技术进步和利用这些技术的系统开发也提供了新的市场机会。反映市场调研的间接材料或与产品相关的材料可能可以得到，并且宜建立定义了向市场提供的品质产品的质量属性。此外，机会可能来自于企业根据合同应需方的要求生产一种产品。这种关系要求企业理解利益相关方的要求并且开发一种产品(在系统周境中)来满足顾客和公众的期望。A．2．2新的技术进步新技术对新产品的性能和能力可能产生广泛的影响。因此，作为需求过程的一个输入，宜对新技术对于提升产品的设计或能力的价值进行评估。A．2．3项目环境项目环境定义目标、成功准则、项目里程碑以及相关的管理优先级，这些将会管理集成的、支持产品开发的技术活动。在项目环境中完成项目使用的方法宜记载在系统集成管理计划中。以下这些可以提高项目集成技术活动的效率和有效性：a)集成的、多学科交叉的协同工作；b)合适的计算机辅助集成工具。A．2．4企业环境企业建立管理与产品开发相关的项目活动方针和规程。此外，企业标准和通用规约或指导方针管理开发活动和产品设计。这些指示代表了企业在竞争的市场中建立一个可生存的产品的指导方针。企业管理宜分配可用的资源从而完成项目的系统工程任务和活动以支持产品设计、生产、测试、运行、支持分发、培训和处置过程的建立。企业活动包括对项目人员的培训、建立关键应用技术以及为项目控制实现企业信息基础设施。企业的领域技术也限制了工具的可用性和使用、设计可选项以及过程方案。A．2．5外部环境外部环境提供一些影响企业进行新产品商业化努力的政治和社会的意见或约束。企业宜保证产品适应所适用的社会政治约束。这些约束构成了社会政治气候管制商业或工业行为，包括环境保护法规、安全法规、技术约束以及其他由中央和地方政府机构制定的用以保护消费者利益的法规。此外，国际、政府和工业标准以及通用规约也约束着企业和项目活动及设计选择。企业宜了解竞争者的产品从而为改进自己的产品设计设置基准或者决定不在该产品领域进行竞争。对于产品方案的另一种约束来自于产品未来运行的自然和人工环境。这些环境的影响，以及一个给定产品可能对这些环境的影响，在很大程度上确立了产品在市场上的公众接受程度。A．2．6产品企业的一个基本利益是使满足消费者期望并能获得公众认同的产品上市销售。接受包括当需要维持产品的使用时，适用的分发、培训、支持和处置服务是可用的。A．3系统工程问题和解空间在当前周境中，系统工程负责建立一个可测试、生产、支持、操作、分发和处置的产品设计所必需的51 GB／T26240--2010／ISO／IEC26702：2007全部开发工作。同时，还要考虑对操作、支持、分发(安装等)和处置的培训。工程化一个系统以满足顾客期望、企业方针和社会、法律及地理限制的综合这一挑战需要一个结构化的过程来探究系统可选项中的选择以保证所制定的设计有较好的成本效益并且是实用的。图A．2描述了为了开始产品方案开发宜进行探究和很好理解的问题空间。问题空间解空间图A．2系统工程的问题和解空间 B．1工程计划模板附录B(资料性附录)系统工程管理计划GB／T26240—2010／ISO／IEC2670212007该工程计划模板的目的是为企业提供一种用于编制系统工程管理计划的格式。典型情况下，项目对于每个开发阶段都有一个项目特定的工程计划，并且用它来指导和追踪系统工程活动。项目特定的工程计划宜适应项目管理计划；企业计划、能力和约束；以及顾客期望。由于每个项目可能有唯一的生存周期维度、风险承受能力以及数据要求，因此工程计划宜为每个应用进行剪裁。B．2工程计划结构工程计划是一个活跃的文档，需要被组织成使之容易更新以反映贯穿生存周期某个阶段中的更改和进展的结构。经常更改的数据可以收集在一张表中。需要经过高层批准才能修改的数据宜与企业可以更改的数据分开。工程计划的配置管理计划宜包含在工程计划中。信息不宜在多处重复。在合适的地方，简单的交叉引用是有帮助的。推荐的模板结构中提供了典型的章节，并以斜体字表示章节标题，作为对起草者的指南。下面给出每个章条应该包含什么的一个描述。封面页包括“系统工程管理计划”字样、项目的文档控制号、涉及的组织以及文档标题和／或适用的系统。图B．1提供了一个标题页的例子以及所标识的必要信息。图B．1封面页示例目次列出每个带标题的段落及子段落的章节标题和页码。目次表还宜以同样的顺序列出每张图、表格及附录的标题和页码(图B．2中的页码仅仅表示模板参考。并不意味着文档长度)。53 GB／T26240--2010／ISO／IEC26702：20071．0范围包括对工程计划应用所针对的系统的目的的简短描述，工程计划的内容和目的的总结以及将如何管理它的配置。2．0适用的文件列出所有适用于工程计划中任务实施的政府法规、标准、行业、企业、项目及其他指令性的文件。目次1．0范围2．0适用的文件3．0系统工程过程(SEP)的应用3．1系统工程过程计划311主要交付件及结果3．2311集成资源库312规约和基线31．2过程输入3．13技术目标31．4系统分解结构(SBS)31．5培训31．6标准和规程3．】7资源分配3．1．8约束319工作授权需求分析33需求基线确认34功能分析3．5功能验证36合成37设计验证、3．8系统分析381权衡分析382系统／成本效益分析383风险管理39控制39l设计捕获3．92接口管理3．9．3数据管理394系统工程主进度表(SEMS)395技术性能测量396技术评审39．7供方控制398需求追踪0转化关键技术0系统工程工作的集成51组织结构5．2所需的系统工程集成任务0附加的系统工程活动61提前时间最长的事项6．2工程工具63按成本设计6．4价值工程65系统集成计划66与其他生存周期支持功能的接口67安全计划68其他计划和控制O注解71通用背景知识72首字母缩写词和简写词73术语表图表附录AB页码56789101l11121314151617181919202l2122232425252526262626272727图B．2目次示例17 GB／T26240--2010／ISO／IEC26702：20073．0系统工程过程(SEP)的应用按照将被应用到项目的整个工程工作描述任务／企业的SEP活动，同时描述组织对于系统工程活动的责任和权力，包括供方工程的控制。描述包括满足主进度表中标识的每个完成准则所需的任务，以及项目的系统工程详细进度的里程碑和进度。描述包括辅以必需的图形表达的叙述性文字，对SEP应用的计划、过程和规程进行详细描述。3．1系统工程过程计划简要描述关键的项目技术目标、过程的交付件和结果、所需的过程输入以及产品工作分解结构开发的一个概览。3．1．1主要交付件及结果详细描述对于顾客和某公司内部、作为SEP活动结果的主要技术交付件和结果。3．1．1．1集成资源库描述项目信息库的实现。包括如何捕获、追踪和维护信息的描述。提供了任意设计一捕获数据供应的描述，包括领域模型(过程、技术等)；产品模型(设计原型一位置、可用性、特性等)；归档数据(汲取的教训、过去的设计、经验数据)；需求、目标和约束；项目管理模型(成本、进度和风险)；综合视图、多视图以及多学科交叉设计及其基本原理；权衡分析和系统／成本有效性分析原理及结果；验证数据；产品和过程度量。3．1．1．2规约和基线描述规约和基线的生成将如何进行记载和控制。3．1．2过程输入标识能够完成SEP的活动(与开发层次相适应)所需的信息的详细程度、所需的信息如何获取以及冲突如何解决。3．1．3技术目标描述与项目的成功、系统及系统的有效性(如顾客的MOE)相关的技术目标。技术目标可以与系统产品及其生存周期过程相关。3．1．4系统分解结构(SBS)描述SBS的元素将如何开发。宜解释规约树与带有SBS元素的制图树之间的关系以及系统产品及其生存周期过程将如何联系起来。这一部分宜为SBS的每一个元素描述开发方法和工作包的控制；计划包的开发以及它们向工作包的转换；工作包规模的确定；资源的使用，包括集成的产品组(IPT)；变更的跟踪；成本报告以及与进度安排和关键路径识别的集成；以及配置管理。3．1．5培训标识所需的内部和外部(供方／顾客)培训。包括对性能或行为上的不足和缺陷、所需的弥补培训以及达到所需要的熟练程度的进度表的分析。3．1．6标准和规程描述项目将遵循的主要标准和规程。将标准化任务的实现合并到SEP相关的部分中。3．1．7资源分配描述对技术任务的资源分配方法。包括资源一需求标识、资源控制规程和再分配规程。3．1．8约束描述项目的主要约束。包括项目不能或不会做的事。也包括资金、A员、设施、生产能力／产量、关键资源或其他约束。3．1．9工作授权描述项目中要执行的工作的授权方法。同时描述工作成果的变更的授权方法。3．2需求分析记载对以下内容进行分析的途径和方法：系统产品使用；使用环境；人的固有限毹和能力；绩效期55 GB／T26240--2010／ISO／IEC26702：2007望；以及设计约束和与生存周期过程相关的要求、需求和约束的标识。记载硬件、软件和人因系统工程(人力、人员、培训、人因工程和系统安全性)的分析途径和方法。同时记载将用于下列质量要素和工程特性领域的功能和性能需求定义的途径和方法，包括质量要素：可生产性、可测试性、综合诊断、可分发性(包括包装和搬运、可传输性及可安装性)、易用性、可支持性、可培训性和可处置性；以及工程特性领域：可靠性、可维护性、电磁的兼容性、静电放电、健康危害和环境影响、系统保密安全性、基础设施支持以及任何其他在适当开发层次对系统的功能和性能需求产生影响的工程特性。此外，还要描述演化系统产品的途径和方法。注：有些领域可能只会在合成工作标识可选方案后才会影响需求分析。有些描述性信息可能会在其他SEP活动中适当地覆盖。3．3需求基线确认包括确认通过需求分析建立的需求基线可同时向上及向下追踪到利益相关方期望、项目和企业的约束及外部约束的途径和方法。3．4功能分析包括所计划的用来确定低层功能、向低层功能分配性能和其他限制性需求、定义功能接口以及定义功能体系结构的途径和方法的一种描述。3．5功能验证包括所计划的用来验证从功能分析中建立起来的功能体系结构可以同时向上及向下追踪到已确认的需求基线的途径和方法的一种描述。3．6合成包括将功能体系结构转换为设计体系结构(硬件、软件和支持系统生存周期的人)、定义可选系统概念、定义物理接口以及选择首选的产品和过程方案的途径和方法。描述需求如何转换为硬件、软件、人因工程、人力、人员、安全性、培训和接口的详细设计规约。还要定义工程领域、质量属性以及3．2节中的工程特性的途径和方法。此外，还要包括无需开发的项以及零件控制。3．7设计验证包括所计划的用来验证合成中所建立的设计体系结构可以同时向上及向下追踪到功能体系结构、满足已确认的需求基线中的需求，并且支持配置和规约基线(包括人因工程、人力、人员、安全性及培训l规约)的途径和方法的一种描述。3．8系统分析包括所计划的用来取得一组平衡的需求及为了满足这些需求的平衡的功能和设计体系结构，以及控制依赖于开发的SEP输出的途径和方法的概览。提供所需的特定的系统分析工作(包括硬件、软件和人员分配分析)的概览。还包括一些权衡分析、系统和成本效益分析以及分析管理方法和工具。3．8．1权衡分析描述所计划的用来在所陈述的下列因素之间进行权衡分析的研究工作：需求、设计、项目进度表、功能和性能需求、功能、任务以及人、软件和硬件及生存周期／按成本设计之间的决策分配。描述面向决策和可选设计方案权衡的准则的使用。按照具体情况包括对技术目标、准则和权重因素以及效用曲线的描述。还要描述所计划的将要使用的方法和工具以及任意与集成资源库间的接口。3．8．2系统／成本效益分析描述系统的实现以及成本效益分析以支持生存周期平衡的产品和过程的开发以及支持风险管理。描述各种MOE，它们如何相互关联以及选取MOP以支持演化中的系统定义和验证的准则。包括对系统／成本效益分析以及其他分析任务的总体方法的描述：生产分析；验证分析；分发分析；运行分析；人因工程、人力、人员和培训分析；易用性分析；可支持性分析；安全性、健康危害和环境分析；以及生存周期成本分析。描述分析结果如何集成在一起。3．8．3风险管理描述技术风险计划，包括用于风险评估(标识及量化)、风险应对方案选择以及决策过程集成的方56 GB／T26240—2010／1SO／1EC2670212007法、步骤、规程和准则。同时还描述与开发和验证需求相关的风险。标识关键风险区域。描述最小化技术风险的计划(额外的原型、技术和集成验证以及演化式的系统开发)。标识风险控制和监控措施，包括特殊的验证、TPM参数和关键里程碑／事件。描述将TPM、主进度表及详细进度表关联到成本和进度执行测量以及与SBS的关系的方法。3．9控制为设计捕获、接口管理、数据管理、基于事件的进度安排、基于日程的进度安排、TPM、技术评审、供方控制和需求跟踪的计划提供一个概览。3．9．1设计捕获描述计划用来管理已标识的系统产品及相关的生产、验证、分发、支持、培训和处置的生存周期过程的系统定义(配置)的途径和方法。包括对变更管理、配置控制规程和基线管理的描述。描述可选方案、权衡分析、决策／结论以及汲取的教训的设计记录。3．9．2接口管理描述计划用来管理与开发层次相适应的内部接口以保证外部接口(项目外部或者功能体系结构或设计体系结构的更高层上)得到管理和控制的途径和方法。包括变更管理以及与配置控制规程相互关系的描述。3．9．3数据管理描述计划用来建立并维护一个数据管理系统以及与设计捕获系统和集成资源库之间相互关系的途径和方法。包括对那些技术文档以及如何进行控制、记载项目工程和技术信息的方法。还包括保密安全性计划和可交付数据的准备。3．9．4系统工程主进度表(SEMS)描述用来导出主进度表的事件变迁以及支持系统工程详细进度表和它们的结构的关键路径方法和准则。包括对计划用来更新和维护主进度表和详细进度表的途径和方法的描述。3．9．5技术性能测量描述标识、建立和控制关键技术参数(限于那些关键的和／或由利益相关方标识的)的途径和方法。描述包括阈值、测量和追踪方法、更新频率、追踪深度级别以及生成恢复计划的响应时间和所计划的修订。所描述的参数包括对相关风险的标识。描述所选择的参数与必须测量以确定关键参数达到值的低层参数之间的关系，表示为分层依赖树的形式并且反映与相关系统性能需求(关键参数)的联系。包括对依赖树中每个参数与特定SBS元素之间相互关系的定义。3．9．6技术评审描述适用于工程计划所覆盖的开发层次的技术评审和／或审核(系统、子系统、部件和生存周期过程)。描述计划用来完成所标识的评审和／或审核的方法和规程。描述与每个评审的执行相关的任务，包括所涉及人员的责任以及必要的规程(例如动作项收尾规程)。包括如何确定与任务活动工程计划／主进度表和／或该工程计划和企业主进度表相符，如何处理标识为不满足工程计划／主进度表需求的差异，以及评估为具有中等到高符合性风险的系统产品和相关的生存周期过程在进行评审之前如何应对。3．9．7供方控制描述对供方和卖方的技术控制。包括下传需求、管理接口、控制质量、构建长期关系和确保对IPT的参与的途径和方法。3．9．8需求追踪描述需求的可追踪性如何实现。包括SEP活动、SBS及与主进度表和详细进度表间的相互关系之间的追踪性。描述需求的可追踪性与数据管理和集成资源库间的相互关系。4．0转化关键技术描述标识关键技术以及相关的风险，以及来自于企业内部技术发展及示范或来自于供方或其他来源的关键技术的评估和转化的活动和准则的途径和方法。描述如何标识可选项以及所确立的用来确定57 GB／T26240—2010／ISO／IEC26702：2007当中等到高风险技术都按照需要被评估时，何时及哪个可选技术将被加入到产品中以满足功能和性能需求的选取准则。描述计划用于工程和技术过程改进的方法，包括建立演化式的系统开发以使系统产品随着技术成熟或为了系统的演化的增量改进方法成为可能的规程。5．0系统工程工作的集成描述系统工程工作的各种输入将如何集成以及集成的产品组将如何实现以将合适的学科知识集成到协调的满足成本、进度和绩效目标的系统工程工作中。提供计划用来确保工程特性的完整性以满足项目目标的途径和方法的简要描述。5．1组织结构描述组织结构将如何支持团队工作。描述组织起来支持SBS中特定元素的团队的构成。同时还通过头衔描述团队成员的主要责任和权力，并且包括当前和所计划的项目技术成员。包括所计划的根据学科和绩效水平、人力资源负载和关键人员标识描述的人员要求。5．2所需的系统工程集成任务描述系统工程集成任务，例如技术验证、过程证明、工程测试件的制作、开发测试和评价、系统产品软件设计的实现、以及顾客和供方的：[程和问题一解决支持的途径和方法。这个描述包括对所需要的支持组的表达。6．0附加的系统工程活动包括对1．o至5．0中没有明确覆盖但对规划整个系统工程工作起根本作用的其他领域的简要描述。包括对整个系统方案成功工程化起根本作用的附加的系统工程活动的简要描述。6．1提前时间最长的事项描述影响项目关键路径的提前时间最长的事项。6．2工程工具描述计划按程序实现以支持系统工程的系统工程方法和工具。标识要获取的工具和相应的培训需求。6．3按成本设计描述按成本设计计划以及成本将如何作为一个设计参数来实现和控制。6．4价值工程描述计划用在整个开发周期中实施价值工程的途径和方法。6．5系统集成计划描述系统组装和集成的途径和方法。6．6与其他生存周期支持功能的接口描述确保和其他与项目和企业计划一致的生存周期支持功能的兼容性的途径和方法，这些生存周期与项目和企业的计划相一致。6．7安全计划描述进行安全性分析及评估对于操作员、系统、环境或公众的风险的途径和方法。6．8其他计划和控制描述用于任何其他由任务分派活动制定的或者企业系统架构师、系统工程师或系统集成者将会使用的计划和控制的途径和方法。7．0注解包含任何辅助理解工程计划(例如背景信息；按字母顺序列出的所有首字母缩写词、简写词以及它们在工程计划中的含意；所用术语的术语表)的通用信息。解释这一节中哪些项是强制的或者提供为通用信息。7．1通用背景知识提供可以帮助该工程计划中活动和任务的实现者和管理者更好的理解和完成他们职责的背景知识。IR GB／T26240--2010／ISO／IEC26702：20077．2首字母缩略词和简略词提供一个按字母顺序排列的首字母缩略词和简略词以及它们的含义的列表。7．3术语表提供一个按字母顺序排列的关键术语以及它们应用在该工程计划语境中的含义的列表。附录必要时可包含附录，以提供为了文档维护的方便而独立发布的信息。所包括的有图表以及适用于工程计划所需要的系统工程工作的私有数据。附录还包括与项目相关的技术计划的总结。每个附录宜在工程计划中的某个章条中引用，这些地方一般会提供数据。 GB／T26240—2010／iso／iEc26702：2007附录C(资料性附录)在GB／T22032语境中使用本标准C．1目的本附录的目的是方便本标准与GB／T220322008E3]--起使用。GB／T220322008提供了一个系统生存周期过程框架。本标准独立于该框架，提供了一种系统定义和管理方法。本标准可以与22032--2008一起使用，也可以单独使用。本质上，本标准定义了可以在G-B／T220322008的范围内定义的许多可能的系统定义和管理框架中的一个。本附录解释了一些本标准与GB／T220322008的概念、结构和术语之间的关键差异。本附录包括一个从本标准到GB／T220322008的概要层次映射，它也可能对支持这些标准的理解和结合应用有所帮助。C．2定义以下取自GB／T22032--2008E3]的定义提供了与本标准不同的概念。GB／T220322008的章条编号完整保留在本附录中。4．2活动(activity)花费时间与资源的一组行动，它的执行对于实现一个或多个输出是必要的，或有帮助的。4．5使能系统(enablingsystem)在一个所关心的系统的生存周期各阶段中作为补充的系统，但并不必在运行时直接有助于实现所关心的系统的功能。注1：例如，当一个所关心的系统进入生产阶段时，需要一个使能生产系统。注2：每一个使能系统有它自己的生存周期。当依照其权利把使能系统本身当成所关心的系统时，该标准(GB／T220322008[37)适用于每一个使能系统。4．6企业(enterprise)一个组织中负责根据协议获取和供应产品和(或)服务的部分。注：一个组织可能涉及几个企业，同时一个企业可能涉及一个或多个组织。4．11过程(process)一组将输人转化为输出的相互关联或相互作用的活动(GB／T19000--2008[1])。4．12项目(project)具有预定的起始和结束时间、根据规定的资源和需求承诺创建产品或服务的一个行动。注t：摘自GB／T190002008[1]和PMBOKoGuide(2000)Es]。注2：一个项目可看作是由协作和受控的活动组成的独特的过程，同时可由该标准(GB／F220322008E33)中定义的项目过程和技术过程的活动组成。4．17系统(system)为达到一个或多个规定目的而组织起来的、相互作用的元素的组合体。注1：一个系统可被认为是一个产品或它提供的服务。注2：实际上，对系统含义的解释通常通过使用一个联合名词来阐明，例如飞行器系统。或者，单词“系统”可简单地由上下文相关的同义词来替代，如飞行器，虽然这可能使系统的观点不太明显。4．18系统元素(systemelement)组成系统的一组元素中的一个成员。注：一个系统元素是一个系统中离散的部分，通过实现它可以完成规定的需求。4．19所关心的系统(system-of-interest)在该标准(GB／T22032--2008E3])中其生存周期在考虑范围的系统。4．20系统生存周期(systemlifecycle)所关心的系统从概念到退役随时间的进化。注意GB／T220322008的附录D对这些术语中的几个提供了附加的解释和可能的视图，如系统、60 CB／T26240--2010／ISO／IEC26702：2007系统元素和目标系统。例如．它指出系统可能由下列的一个或多个配嚣而成：硬f，f‘、软件、人、过程、规程、设施和F1然出现的实体。这些可能被视为产66或服务。陔标准同时注解说人可能被视为外部于系统的丌J户以及系统内的系统元素。C3系统结构和术语本章使刑一系列的图来解释两个标准中所使用的对于系统定义的不同的结构化方法。本标准的系统结构的层次视图与一种定义并精化系统产品及其相关的生存周期过程的构造块方法帽结合。本标准定义了企业和项目实践及SEP的基本集合，它们可以以适当的组合跨越产品开发、问题解决和演化的系统生存周期的不同阶段进行应用。13条介绍了本标准的层次化的系统结构定义。图l描述了本标准中使用的用来描述构成一个系统的兀素的名称的层次结构。前二二层(系统、产品和子系统)为后面的结构化描述打下了基础。图2按照组成系统的构造块、它的相关产晶、支持产品的生仔周期过程以及组成产品的子系统描述了本标准中的基本系统结构。这种构造块形式方便，与广泛用于财务管理结构的工作分解结构的对应。构造块结构被用来标识需要被工程化的产品。本标准引入了术语生存周期过程来应对跨越产品生存周期的八个功能域中都可能出现的系统支持的需要。引入它们的另一个原因是将这些支持系统J_j产品内在的系统和子系统I=|(=分阡来。本标准主要关注于产品开发方面而非生存周期过程定义和实现。产品和生存周期过程宜共刚工程化，而且～旦标识丁生存周期过程要求和元素，它们就被视为整个系统层次结构中的系统。SEP也被应用于需要进行工程化的生存周期过程元素。图C．1描述r系统层次结构中的各层如何组成一个或多个同样的基本构造块结构(产品各小相同)。同样的一绀过程，实质E是本标准SEP的子过程，在自顶向下的设计巾被应用于各个构造块。图C．1本标准的构造块结构 C]VT26240—2010／ISO／IEC26702：2007莅GP,／T22932—2008[3]中，使能系统对应于奉标准生存周甥过程中的产品和服务。在GB／T220322008中，术语系统生存周期过程包括r可以用于一个已定义的生存周期模型中任意阶段的陔标准的25个过程的集合。图■2描述了GBjT220322008的系统结构并且提供r一个与本标准等价的产品层次结构”。它引人一组与本标准中所使用的小同的术语：所关心的系统是层次结构中最上层的产品。一系统元素是可以通过构建、购买、复用或使用领域标准，如用于软件的GB／T85662007L2j所定义的那样，来开发的产品分解结构巾的实体。系统用来描述层次结构中需要工程化的所有其他产品。、％一个项目被赋予工程化一个系统的责任，它就被认为是针1对(；H／_I"22032过程应tHj的项I；=I的目标系统。喧囱豳厂—厂—]厂——厂——_瞳由匣塾由豳由睦困圄囱宙囱匪蛰匡固矗面卣己图c．2GB／T22032的图D．3所关心的系统结构GB／T22032目标系统结构中的产品用本标准构造块中的产品框来表示。GB／T220322008提供_r一个与本标准中的产品树等价的描述目标系统分解的结构。目标系统被递归地定义为它的可实现的系统元素。使能系统不是该结构的一部分。GB／T220322008L3]使能系统的需求按照与本标准中对待生存崩期过程需求相同的方式处理。罔C3表明米自本标准构造块层次结构中产品方框之间的链接与GB,T220322008中f；_】标系统结构(产品树)是一样的。GB／T22082产品结构没有在每个层次上与本标准中的术语生存周期过程进行绑定。2)(；13／-I_220322008l3-将系统(见C2定义417)定义为“为达到个或多个规定日的而组织起来的、相互作用的元素的组合体”；注1表明系统几』以考虑为产品或者作为它提供的服务， GB／T26240—201O／]SO／IEC26702：2007图c．322032构造块的分解部分基丁上述GB7T22032系统结构与本标准构造块的比较，图C．4指出了本标准构造块与220322008中相当的术语。图c．422032与本标准的术语命名比较与本标准构造块没有结构上的等价，C．4过程结构和术语本章提供本标准与(；B／T220322008[3]术语的比较。本标准与GB／T22032--2008都分层化地组织它”J的过程，但是它们使』H不同的术语和描述层次，如表c1所4i。 GB／T26240--2010／ISO／IEC26702：2007表C．1本标准和GB／T22032过程术语本标准层次1个SEP8个子过程任务活动22032层次4个过程组25个系统生存周期过程过程目标、成果、活动220322008E33的25个系统生存周期过程被分为4组：协议、企业、项目和技术过程。每组包含两个或更多过程。这些过程中的每一个描述为过程目的、输出和活动。在遵循GB／T220322008标准的应用中，过程活动需要依照组织方针和规程实现。过程活动在一个相当高的层次上进行描述，一般还辅以有益的注解。该标准的读者可以使用注解来指导解释以及定义更详细的活动实现。此外，ISO／IECTR19760：2003[4]提供了理解和应用GB／T220322008的指南。220322008没有在过程层次中包括任务这一术语，但在项目周境中使用术语任务。项目计划过程引入项目任务这个术语。注意到项目包括满足业务决策准则以及成功完成项目所需要的所有相关的活动。项目任务通过工作分解结构与活动相关联。项目任务标识每个正在被开发或生产的工作项以及工作项的相关任务。本标准第6章定义了单个过程，SEP，它被分成8个子过程。每一个子过程又被分解为进行了．讨论和图表说明的任务。一般来说，任务通过附属的企业或项目活动来实现。第4章列出了一个企业和项目必须完成以生产整个系统方案的通用需求。在第5章，企业或项目通过在每个生存周期阶段适当应用第6章的SEP任务实现第4章中的需求，从而演化系统的细节并解决所报告的问题。第5章中的表格列出了每个阶段中要完成的特定活动。本标准和GB／T220322008[3]中的过程结构和术语不同。然而，本标准中的章条与22032—2008中超出本标准第6章SEP定义范围的过程之间却存在关联关系。本标准陈述和22032活动之间的联系已经标志出来了。表c．2提供了从本标准第4章总要求及第6章SEP子过程任务到GB／T22032过程活动的概要层次映射。本标准第5章在这里没有映射，因为总的来看它针对详细系统分解期间特定的活动、文档化和评审重复了第4和第6章与GB／T22032活动之间的关系。表C．2与GB／T22032活动相关的本标准需求和SEP任务22032章条本标准章条映射到包含相应的活动第4章总要求4．1系统工程过程(SEP)54，5542系统工程的方针和规程5．3．23，53434．3规划技术工作5．4．2．34．4开发策略532．3，5．343，542．345建模和原型化5．53．3，5．5．43，557．3，559346集成资源库5．48347集成数据包5483，554．34．8规约树5．54349制图树5．543410系统分解结构(SBS)54．3 表C．2(续)GB／T26240--2010／ISO／IEC26702：2007GB／T22032章条本标准章条映射到包含相应的活动411系统工程工作的集成0．3．5．3，54．23，5．4．334，12技术评审54．33，54．4．34．13质量管理53．6．34．14产品和过程改进5．343，536．3第6章系统工程过程(SEP)6l需求分析5．5．23，5533，554．36．2需求确认523，5536．3功能分析5．5．4．364功能验证543，557365合成5．54．3，55．7．36．6设计验证5．523，5543，55．7．367系统分析5．4．5．3，5．463，5．523，5．533，554．368控制5．4．33，5．4．43，5．4．6．3，5．47．3，54．8．3，55．4．3注：这个映射概括了从本标准源文件到GB／T220322008E3]且标文件中的过程活动之间的映射关系。它包括不需要的源陈述部分与目标活动之间的关系。例如，本标准第6章子过程任务(在6xY层)代表性地映射到GB／T22032的技术过程的行为下的注解信息。同时，虽然本标准的系统工程过程明显地将GB／T22032技术过程应用于处理需求和设计，但是系统工程过程的某些方面的一些技术过程行为对最终实现系统产品有很大贡献。比如，本标准的45、64、65和66支持一些GB／T22032中的验证过程行为(在55．73行为注解下)。C．5贯穿系统生存周期的过程应用GB／T220322008[3]和本标准都应用到整个系统生存周期上。两个标准都使得系统生存周期的阶段划分成为一种规范。当阶段划分成为规范，两个标准都可以让用户自由定义单个阶段。两个标准中陈述的示例阶段(或者“典型”阶段，正如本标准对它们的称呼)有些不同。本章对示例阶段进行比较。本标准的第5章(从一种系统工程观点)描述r一个系统生存周期。GB／7T220322008[3]的第6部分要求实现该标准的符合性应用的组织建立至少由一个阶段组成的生存周期模型，其中每个阶段将会包含一个定义的目的和输出。如果合适的话，GB／T22032系统生存周期过程和活动将被选取和剪裁，从而在每个阶段中使用以实现阶段目的和输出。基于本标准的目的，第5章跨越本标准典型系统生存周期的SEP应用实现了比实现GB／T22032在同一阶段的系统生存周期过程的完整集合通常所期望的一个更狭窄的详细活动集合。本标准典型系统生存周期的每一个阶段可以按照更宽泛的目的和输出进行定义，然后SEP特定的活动可以被应用于每个阶段目的和所选择输出的部分实现。本标准在一个GB／T22032生存周期模型语境中的另一个实现视图可以将基于本标准的生存周期模型的每个阶段目的和输出的定义限制为只包括与SEP相关并且可以由本标准SEP活动的应用来实现的那些。本章提供了本标准第5部分标识的生存周期阶段与GB／T22032--2008的资料性附录B中指出的示例通用生存周期阶段之间的一个比较。在图C．5中，本标准的图7对一个典型系统生存周期的描述被GB／T220322008中的示例生存周期覆盖了。65 GB／T26240—2010／ISO／IEC26702：20076622032范围使支用持概开发阶段阶退念段阶产品役阶段阶段系统定义概要设计详细设计FAIT支持本标准范围图C．5跨越典型系统生存周期阶段的范围比较 参考文献GB／T26240--2010／ISO／IEC26702：2007[1]GB／T190002008质量管理系统基础和术语和词汇(ISO9000：2005，IDT)[2]GB／T85662007信息技术软件生存周期过程(ISO／IEC12207：1995．MOD)[3]GB／T220322008系统工程系统生存周期过程(ISO／IEC15288：2002，IDT)[4]IS0／IECTR19760：2003系统工程ISO／IEC15288(系统生存周期过程)应用指南[5]项目管理协会．项目管理知识主体指南(PMBOKGuide)2000版．NewtownSquare，PAProjectManagementInstitute，Inc．'