信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践

上传人:木92****502 文档编号:126500752 上传时间:2020-03-25 格式:DOCX 页数:40 大小:64.59KB
返回 下载 相关 举报
信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践_第1页
第1页 / 共40页
信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践_第2页
第2页 / 共40页
信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践_第3页
第3页 / 共40页
信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践_第4页
第4页 / 共40页
信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践_第5页
第5页 / 共40页
点击查看更多>>
资源描述

《信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践》由会员分享,可在线阅读,更多相关《信息技术 系统安全工程 能力成熟度模型 项目与组织基本实践(40页珍藏版)》请在金锄头文库上搜索。

1、附录A (规范性附录)项目与组织基本实践A.1 综述SSE-CMM包含项目类和组织类过程域。这些过程域源自SSE-CMM,并成为SSE-CMM的重要组成部分,并用于解释通用实践。每个过程域包括 “安全注意事项”,指出在安全工程的情况下使用该过程域的注意事项,并且还参考了相关的SSE-CMM过程域。A.2 一般安全注意事项除了作为每个过程域的特殊注意事项的解释清单外,以下各小节包括安全工程的一般注意事项适用于所有项目类和组织类过程域。A.2.1 项目风险与安全风险项目类和组织类过程域使用术语“风险”。在这些情况下,提及“项目风险”时,是指有关成功完成某个项目的风险,涉及成本和进度问题。系统安全工

2、程过程域中, “安全风险”被看作是一种是否影响运行的活动,这取决于残留安全风险是否可以被接受。虽然项目类和组织类过程域并没有提出工程类过程域涉及的安全风险管理,但安全风险评估的结果可以提供输入并且影响项目风险管理活动。A.2.2 运行阶段适用性尽管项目类和组织类过程域的措辞似乎意味着只适用于开发阶段,但这些过程域同样适用于生存周期的运行和维护阶段。在针对适用于某个组织的过程域进行评估或改进时,需要解释这些过程域。在安全注意事项中很少做例外说明。A.2.3 安全工程与系统工程在所有项目类和组织类过程域(例如,“改进组织系统工程过程”)中都使用术语“系统工程”。不过这些过程域适用面很广。因此,当这

3、些过程域应用于安全工程的情况时,术语“系统工程”应该用术语“安全工程”取代。这些过程域也需要通过确保安全工程与其他工程学科的融合来完善和提升。A.2.4 工程关系在每个过程域中,都会指出系统工程和安全工程的关系。需要注意的是:在各种不同的过程域之间有许多关系(在这些章节中只标识出他们的主要关系)。A.3 PA12确保质量A.3.1 过程域A.3.1.1 安全注意事项PA06“建立保障论据”与确保质量有关。保障可以看成是特殊类型的安全相关质量。A.3.1.2 概要描述“确保质量”的目的不仅涉及系统质量,而且还涉及到用于创建系统的过程的质量以及项目遵循已定义过程的程度。这个过程域潜在的观念是:只有

4、过程处于持续测量和改进质量的状态下,才可能始终如一地产生高质量系统。此外,必须在整个系统生存周期里遵循这个过程。开发高质量系统的过程的关键内容就是测量、分析和纠正措施。A.3.1.3 目标l 定义和测量过程质量;l 实现预期工作产品质量。A.3.1.4 基本实践列表下表包括的基本实践是优秀系统工程的基本元素:BP.12.01识别每个工作产品的质量要求;BP.12.02确保已定义的系统工程过程在系统生存周期中得到遵循;BP.12.03对照工作产品质量要求评价工作产品测量项;BP.12.04对项目使用的系统工程过程的质量进行测量;BP.12.05分析质量测量结果,以便提出关于质量改进或纠正措施的合

5、理建议;BP.12.06使员工参与识别并报告质量问题;BP.12.07启动处理已发现的问题或质量改进机会的活动;BP.12.08建立一种或一系列收集关于对过程或产品采取纠正措施的需要的机制。A.3.1.5 过程域注释一个成功的质量程序要求质量工作始终与项目组以及各个支持元素相结合。有效的过程提供一种提高质量的机制,并且减少对最终产品检查的依赖并降低返工率。这并不意味着单独由那些管理和(或)保障工作产品及过程质量的人负责工作产品输出的质量。相反,“提高”质量的主要责任落在创建者身上。质量管理过程有助于确保质量管理的所有各个方面在整个组织内得到认真考虑和执行,并且反映在产品中。其结果将增加开发者、

6、管理层和客户对系统质量的信心。这个过程域可能涉及到的质量变化类型既包括技术内容,例如,派生的或分配的具体要求值;还包括形式问题,例如,对于产品使用说明书,客户喜欢纸面形式的还是电子形式的。成本超支和进度拖延也可以认为是缺陷,要像对待其他缺陷一样处理。从期望值的角度来说,组织可能希望决定技术以及与组织进度承诺相符的增长过程中其他问题的变迁。例如,如果组织已承诺在指定的某周交付或首次展示某个产品,那么,明智的做法是通过测量每周的变化情况来测量或确定它的进度。在跟踪此过程域的性能时,在可能表明是否满足保证参数的不同基本实践之间查看趋势。参见过程域PA06。过程域PA12确保质量的主题和内容对应于IS

7、O/IEC 15288的6.3.2“项目评估和控制过程”。A.3.2 BP.12.01识别工作产品的质量要求识别每个工作产品的质量要求。A.3.2.1 描述不同类型的工作产品和不同的特定工作产品可能有不同的质量要求。这些质量要求应该在定义工作产品时予以识别。A.3.2.2 工作产品示例l 工作产品质量要求:l 一般的工作产品质量要求列表。A.3.2.3 注释无。A.3.3 BP.12.02监视与已定义过程的一致性确保已定义的系统工程过程在系统生存周期中得到遵循。A.3.3.1 描述确保项目的执行遵循已定义的系统工程过程。应该按适当的时间间隔核查过程的符合性。应该评估已定义过程的偏离以及这种偏离

8、的影响,并且记录在案。A.3.3.2 工作产品示例l 已定义系统工程过程的偏离记录;l 已定义系统工程过程的偏离产生的影响记录;l 质量手册(纸面或在线形式)。A.3.3.3 注释对于已定义过程可以用多种方法监视。例如,某个自愿的审核/评审人员可以参与或观察全部(或一部分)过程活动,或者某个审核/评审人员可以监督全部(或一部分)过程中的工作产品。A.3.4 BP.12.03测量工作产品的质量对照工作产品质量要求评价工作产品测量项。A.3.4.1 描述测量工作产品的特性(涉及到与需求和标准的一致性、正确性和时效性),提出系统质量的标志。应该设计一些测量项来评估工作产品是否能够满足客户和工程的要求

9、。还应该设计一些产品测量项,以帮助解决系统开发过程中的问题。A.3.4.2 工作产品示例l 产品质量评估;l 产品质量认证。A.3.4.3 注释工作产品质量测量方法,如,包括:l 在开发过程中不同点上产品测量项的统计过程控制;l 依据要求对一系列完整的过程结果的测量,例如:u 规范值,u 计划值,u 接受范围,u 证实值,u 证实的技术变化,u 当前估计,u 预测的技术变化。A.3.5 BP.12.04测量过程质量对项目使用的系统工程过程的质量进行测量。A.3.5.1 描述用来创建优质产品的过程与产品质量同样重要。有一个接受测量核查的系统开发过程是很重要,这样可以尽早识别正在恶化的状况,使得生

10、产最终工作产品时能满足要求。因此,拥有这样一个可以测量的过程将减少浪费和提高生产率。A.3.5.2 工作产品示例l 过程质量认证。A.3.5.3 注释在测量过程中使用的工具实例包括:l 过程流程图:可用于确定应该测量哪些特性和识别潜在的变化根源,除此之外还用于定义过程;l 对过程参数的统计过程控制;l 实验设计。A.3.6 BP.12.05分析质量测量结果分析质量测量结果,以便提出关于质量改进或纠正措施的合理建议。A.3.6.1 描述仔细检查产品、过程和项目执行情况的所有可用数据,可以揭示问题的根源。然后,可以利用这些信息改进过程和产品质量。A.3.6.2 工作产品示例l 偏离分析;l 失效分

11、析;l 缺陷报告;l 系统质量趋势;l 纠正措施建议;l 因果图。A.3.6.3 注释支持质量改进的测量实例包括:l 趋势分析,例如识别引起产品参数缓慢蔓延的设备校准问题;l 标准评价,例如确定在技术或过程变更的情况下某些特定标准是否依然适用。A.3.7 BP.12.06邀请参与设法使员工参与识别并报告质量问题。A.3.7.1 描述使用得到遵循的质量过程开发优质的工作产品,要求所有相关人员关注。应该鼓励改进质量的想法,需要有可供每个员工自由地提出过程质量问题的论坛。A.3.7.2 工作产品示例l 提高质量的环境;l 从工作人员那里获得的输入和解决方案。A.3.7.3 注释可通过以下措施培育质量

12、环境:l 建立过程行动组;l 建立质量保障组,这个小组的报告指挥链应该独立于项目;l 建立报告质量问题的独立通道。A.3.8 BP.12.07启动质量改进活动启动处理已发现的问题或质量改进机会的活动。A.3.8.1 描述为了不断改进质量,必须策划和执行具体的行动。具体到系统开发过程中,损坏产品或过程质量的具体内容需要进行识别和纠正。这将包括最小化繁琐的或不切实际的制度。A.3.8.2 工作产品示例l 改进系统工程过程的建议;l 质量改进计划;l 过程修订本。A.3.8.3 注释质量改进活动的有效实施要求工作产品组提供输入和接受改进。A.3.9 BP.12.08检测纠正措施的需要建立一种或一系列

13、收集关于对过程或产品采取纠正措施所需要的机制。A.3.9.1 描述这种机制必须在产品的整个生存周期中(从开发、制造到客户使用)是可用的。这些机制可能包括:在线报告系统、专题讨论会、定期评审、以客户为中心的各种小组等。对于所有受影响的组,这些机制必须是可用的,包括设计、制造、客户和客户支持等。A.3.9.2 工作产品示例l 不断更新的数据库或总库,包含已识别的各种需要、过程改进和产品改进数据;l 为了把已识别的需要存入数据库或知识库中,要清楚地描述过程、方法和途径;l 已识别的关于过程改进的需要;l 已识别的关于产品改进的需要;l 问题报告。A.3.9.3 注释这个基本实践对于在生存周期中的生产

14、、运行和维护等阶段上有效运用系统工程是至关重要的。在这个基本实践中查明针对纠正措施的需要。在“监督和控制技术工作”过程域(PA15)中引导执行各项纠正措施。问题报告也从“验证和确认安全”过程域(PA11)纳入这个基本实践。A.4 PA13管理配置A.4.1 过程域A.4.1.1 安全注意事项在BP.13.02中确定系统/项目的配置单元层次时应考虑PA06“建立保障论据”中保障目标所要求的细节层次。“管理配置”为PA06“建立保障论据”提供证据。此外,所选择的配置管理系统本身应该按照PA01“管理安全控制”进行管理。A.4.1.2 概要描述“管理配置”的目的是维护已识别的配置单元的数据和状态,并

15、且分析和控制系统及其配置单元的变更。管理系统配置涉及到向开发人员和客户提供正确的和最新的配置数据及状态。这个过程域适用于所有置于配置管理下的工作产品,例如,包括硬件和软件配置项、设计基本原理、需求、产品数据文件或趋势研究。A.4.1.3 目标维护对工作产品配置的控制。A.4.1.4 基本实践列表下表包括的基本实践是优秀系统工程的基本元素:BP.13.01确定合适的配置管理方法。BP.13.02确定不可分割的配置管理单元。BP.13.03维护工作产品基线库。BP.13.04控制对已建立的配置单元的变更。BP.13.05向受影响的组通报配置数据、变更建议以及访问信息的状态。A.4.1.5 过程域注释配置管理功能支持可跟踪性,允许在配置生存周期的任何时刻通过系统要求的层次结构追溯配置。 可追溯性是PA10实践的一部分。当此过程域的实践用于管理需求时,需要通过PA10迭代对这些需求的更改,以传达变更对客户

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 总结/报告

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号