新过程改进方法与实践案例 978 7 302 23431 9 第三部分 实践案例 Ch10 载人航天.ppt

主题 10.1 面临的挑战 10.2 初 始 阶 段 10.3 统一过程阶段 10.4 解决的问题 10.5 项目过程的定义 10.6 贯彻与执行阶段 10.7 直接目标和实施效果分析 10.8 战略目标和过程改进的路线图 面临的挑战 从计算机和软件工程的角度来看，整个载人航天工程，到处充满了计算机单元和设备，以及与硬件相互嵌入的软件单元、软件部件和软件配置项。 计算机系统与软件的安全可靠成为影响载人航天工程的重要因素之一。 由于软件开发过程的可见性比计算机硬件制造的可见性还差，所以软件产品的可靠性比硬件产品的可靠性更难以掌控。 因此，软件的进度和质量成为影响整个载人航天可靠与安全的关键问题之一。 主题 10.2 初 始 阶 段 10.2.1 旧白皮书的推动作用 10.2.2 蓝皮书的推动作用 旧白皮书的作用 在首次“白皮书”制定的时间段，我国的主要军用标准是1988年颁布的GJB 437-88、GJB 438-88和GJB 439-88三个标准。 这三个标准主要强调以结构化的编程为主要技术，以及以瀑布模型为开发过程的管理 蓝皮书的推动作用 与旧白皮书相对应，航天工业部门在参考美国NASA相关标准、我国的GJB 437-88、GJB 438-88、GJB 439-88以及航天部门的行业标准的基础上，编写了航天载人工程的软件技术规范“蓝皮书”。 在蓝皮书中，特别强调了嵌入式软件的开发过程与质量问题，强调了安全可靠软件中的数据(信息)保护、异常处理等关键技术，同时讨论了航天领域传统的“问题清零”制度和技术在软件中如何落实的问题。这项制度与CMM等级5的“缺陷预防”关键域所提出的目标具有相似之处。 主题 10.3 统一过程阶段 10.3.1 白皮书的制定过程 10.3.2 白皮书的宣讲和培训 统一过程阶段 建立新的“白皮书”的基础 以GJB 2786、GJB 438A为基础， 吸收原先的“白皮书”和“蓝皮书”的内容， 尽可能采纳美国军方“MIL-STD-498”中所提出的增量式和渐进式模型， 参考美国NASA在安全软件设计和编程方面的经验， 并总结我国航天工业在软件方面的相关技术经验。 白皮书的制定过程 新白皮书的主要内容 软件研制任务书目录和编写要求 软件研制工作管理要求 软件测试细则 软件评审细则 软件验收、移交和保障细则 软件配置管理细则 软件开发和文档编制 软件设计和编程指南 宣讲和培训 专家组组织了相关的专家，到主要的参研单位进行了宣讲和培训。单位涵盖： 航天系统 军队的研发系统 电子工业系统 科学院系统 执行任务的基地等。 通过宣讲和培训，使得各参研单位的主要软件技术人员和管理层对工程中采用的名词、属性、软件质量的定义、评审方法和过程、配置管理方法和过程等有了共同理解(common understanding)。 宣讲与培训为后来的工程进展过程中的各种评审(例如同行评审)奠定了基础，极大地提升了工作效率。 10.4 解决的问题 10.4.1 名词的统一 10.4.2 对瀑布模型之外的开发过程的支持 10.4.3 软件安全等级、规模划分与管理实施 10.4.4 软件开发文档的可剪裁性 10.4.5 配置管理与完整性 10.4.6 评审的定量化 10.4.7 软件测试过程和准则 10.4.8 软件设计和编程的规范化 10.4.9 软件的验收、移交和保障 10.4.10 研发团队管理和技术团队的体制建设和管理 解决的问题 名词的统一 ，例如： 英文的Specification，在系统中解释为“规范”，而在软件中定义为“规格说明”。 英文的Configuration，在大系统中解释为“技术状态”，而在软件系统中定义为“配置”。 英文的Integration，统一称为“集成”，取消了在航天系统已用很久的“组装”的概念。 统一了评审与测试覆盖率的计算方法，等等。 解决的问题 对瀑布模型之外的开发过程的支持 新的白皮书中包含了： 瀑布模型、 增量模型、 渐进模型 目标机更换 更换编程语言，以及， 逆向工程等过程和方法， 扩充了原先仅强调瀑布式开发模型的限制。 软件安全等级、规模划分与管理实施 软件开发文档的可剪裁性 软件开发文档的可剪裁性 软件开发文档的可剪裁性 配置管理与完整性 无论是CSU、CSC还是CSCI均要求具有唯一的编号。编号的唯一性提升了软件开发和维护过程的完整性，目的是避免遗漏和版本的篡改。 《软件配置管理细则》规定了各研制单位要成立配置控制委员会和小组，承担对修改、控制、评审及记录的职责。 评审的定量化 软件需求分析评审细则 软件概要设计评审细则 软件详细设计评审细则 软件单元测试阶段评审细则 软件部件测试阶段评审细则 软件配置项测试阶段评审细则 系统测试