新書推薦：
《
恶的哲学研究（社会思想丛书）
》
售價：NT$
500.0
《
不止江湖
》
售價：NT$
449.0
《
天才留步！——从文艺复兴到新艺术运动（一本关于艺术天才的鲜活故事集，聚焦艺术史的高光时刻！）
》
售價：NT$
704.0
《
双城史
》
售價：NT$
505.0
《
冯友兰和青年谈心系列：不是问题的问题（哲学大师冯友兰和年轻人谈心，命运解读）
》
售價：NT$
254.0
《
月与蟹（青鲤文库）荣获第144届直木奖，天才推理作家经典作品全新译本。一部青春狂想曲，带你登上心理悬疑之巅。
》
售價：NT$
230.0
《
索恩丛书·盛清统治下的太监与皇帝
》
售價：NT$
403.0
《
透过器物看历史（全6册）
》
售價：NT$
2234.0
|
| 編輯推薦： |
|
本书主要面向的读者是航天型号软件的设计人员、开发人员、测试人员以及管理人员，也可以作为相关专业人员了解和掌握航天型号软件工程的参考书。
|
| 內容簡介： |
|
本书在分析国内外航天软件工程实施情况的基础上，全面介绍了航天型号软件研制过程和管理内容，并深入阐述了软件研制各阶段、软件项目管理与计划、软件配置管理和软件质量保证等涉及的理论、方法和相关技术，详细分析了模型驱动软件开发方法和形式化开发方法在我国航天软件工程中的应用前景，不仅能够系统、全面地指导航天型号软件工程的实施，还对航天型号软件工程的发展进行了探讨。
|
| 關於作者： |
王忠贵，1961年出生，博士；现任中国载人航天工程副总设计师，探月工程（二期）副总设计师，长期从事航天系统工程总体设计、研究和软件工程化工作；参与主持神舟一号至十号、嫦娥二号和嫦娥三号任务的总体设计、研制和飞行试验，指导完成了神舟七号出舱活动及空间交会对接历次飞行任务软件研制工作，提出了全面建立航天型号软件工程化技术标准的思想，指导编制并建立了载人航天工程软件技术标准体系。
刘姝，1982年1月出生，博士，高级工程师。从事航天软件相关技术研究，主要负责核高基重大专项、载人航天工程软件工程化等相关项目研究，研究方向包括操作系统、存储系统、SoC、网络、软件工程等
|
| 目錄：
|
第1章 概 述 1
1.1 软件工程的概念 1
1.1.1 软件工程定义 1
1.1.2 软件工程的基本约束 2
1.1.3 软件工程的研究内容 5
1.2 航天实施软件工程的必要性 9
1.2.1 软件质量问题影响型号任务成败 9
1.2.2 航天型号软件研制面临挑战 14
第2章 航天型号软件工程化的要素和方法 16
2.1 航天型号软件的分类 16
2.2 航天型号软件工程的核心要素 17
2.2.1 软件开发过程 18
2.2.2 软件开发方法 26
2.2.3 软件工程工具 29
2.3 航天型号软件工程的管理内容 33
2.3.1 策划管理 33
2.3.2 需求管理 33
2.3.3 过程追踪与监控 33
2.3.4 配置管理 33
2.3.5 过程与产品质量保证 33
2.3.6 外协管理 34
2.3.7 评审管理 34
2.3.8 文档管理 34
2.3.9 开发工具的使用管理 34
第3章 国外航天型号的软件工程化情况 35
3.1 软件过程改进标准和方法 35
3.1.1 ISO 9000 35
3.1.2 CMM和CMMI 35
3.2 NASA软件工程化实践 39
3.2.1 NASA软件研制的管理体系 40
3.2.2 NASA标准规范与流程 40
3.3 ESA软件工程化实践 48
3.3.1 ESA软件研制的管理体系 49
3.3.2 ESA标准规范与流程 51
第4章 国内航天型号软件工程化情况 57
4.1 航天型号软件工程化概述 57
4.2 载人航天工程软件工程化发展历程 58
4.2.1 启动探索期 58
4.2.2 全面实施期 59
4.2.3 巩固发展期 59
4.2.4 软件工程化成绩 60
4.3 载人航天工程软件工程化标准体系 61
4.3.1 管理规定 62
4.3.2 技术标准 63
第5章 航天型号软件研制过程 66
5.1 技术流程分类 66
5.1.1 新研软件技术流程 67
5.1.2 沿用软件技术流程 67
5.1.3 参数修改软件技术流程 68
5.1.4 适应性修改软件技术流程 69
5.2 系统级分析与设计 70
5.2.1 系统分析与设计 71
5.2.2 分系统分析与设计 74
5.3 软件需求分析 77
5.3.1 输入与输出 77
5.3.2 工作内容 78
5.3.3 出口准则 79
5.4 软件设计 80
5.4.1 概要设计 80
5.4.2 详细设计 82
5.5 软件实现 84
5.5.1 输入与输出 84
5.5.2 工作内容 85
5.5.3 出口准则 86
5.6 软件测试 86
5.6.1 软件集成测试 86
5.6.2 软件配置项测试 88
5.7 系统测试 89
5.7.1 软件系统测试 89
5.7.2 系统试验验证 91
5.8 验收交付 93
5.9 运行维护 93
5.9.1 输入与输出 93
5.9.2 工作内容 93
5.9.3 出口准则 94
第6章 系统级分析与设计 95
6.1 概述 95
6.2 系统分解方法 96
6.2.1 产品分解结构 96
6.2.2 功能流框图 97
6.2.3 软件结构HIPO图 98
6.3 软硬件协同设计 99
6.3.1 软硬件协同设计定义 100
6.3.2 软硬件协同设计与仿真验证 101
6.3.3 软硬件协同设计平台 102
6.4 软件复用与外购 104
6.4.1 已有软件复用过程 104
6.4.2 软件复用技术 105
第7章 软件需求分析 110
7.1 概述 110
7.1.1 需求的定义 110
7.1.2 需求的类型 112
7.1.3 需求分析原则 113
7.2 结构化需求分析方法 114
7.2.1 数据流图 115
7.2.2 数据字典 117
7.2.3 加工规格说明 118
7.2.4 实体-关系图 118
7.2.5 数据对象描述 119
7.2.6 状态迁移图 119
7.3 面向对象的需求分析方法 119
7.3.1 面向对象分析方法概述 120
7.3.2 识别分析类和对象 122
7.3.3 定义类之间的关系 123
7.3.4 标识类的属性和服务 124
7.4 软件需求管理 126
7.4.1 内容与要求 126
7.4.2 需求追踪方法 127
7.4.3 需求管理工具 128
第8章 软件设计 131
8.1 概述 131
8.2 软件设计的原则 132
8.2.1 模块化 132
8.2.2 抽象 135
8.2.3 逐步求精 135
8.2.4 信息隐藏 135
8.3 结构化软件设计方法 135
8.3.1 面向数据流的设计方法 135
8.3.2 面向数据结构的设计方法 140
8.3.3 结构化程序设计图形工具 143
8.4 面向对象软件设计方法 147
8.4.1 系统设计与对象设计 148
8.4.2 面向对象程序设计 148
8.4.3 面向对象设计工具 150
8.5 数据库结构设计 151
第9章 软件实现 153
9.1 概述 153
9.1.1 编程语言分类 153
9.1.2 编程语言的选择 155
9.2 编程风格与编码规范 156
9.2.1 程序设计风格 156
9.2.2 C语言编码规范 161
9.3 高安全可靠的软件编码环境 167
9.3.1 编译器对软件安全可靠性的影响 167
9.3.2 安全可信编译器 167
第10章 软件测试 170
10.1 概述 170
10.1.1 测试策划 170
10.1.2 测试设计与实现 170
10.1.3 测试执行 171
10.1.4 测试总结 171
10.2 测试方法 172
10.2.1 静态测试 172
10.2.2 动态测试 172
10.3 软件单元测试 179
10.3.1 单元测试的内容 180
10.3.2 单元测试的方法 182
10.4 软件集成测试 187
10.4.1 集成测试的内容 188
10.4.2 集成测试的方法 188
10.5 软件配置项测试 190
10.5.1 功能测试 190
10.5.2 性能测试 190
10.5.3 接口测试 191
10.5.4 人机交互界面测试 191
10.5.5 强度测试 191
10.5.6 余量测试 192
10.5.7 恢复性测试 192
10.5.8 安装性测试 193
10.5.9 边界测试 193
10.5.10 安全性测试 193
10.5.11 互操作性测试 194
10.5.12 敏感性测试 194
10.5.13 数据处理测试 194
10.5.14 容量测试 195
10.6 系统测试 195
10.6.1 软件系统测试 195
10.6.2 系统试验验证 195
10.7 回归测试 196
10.8 第三方测评 196
10.9 软件测试工具 197
10.9.1 静态分析工具 197
10.9.2 单元测试工具 199
10.9.3 嵌入式软件白盒测试工具 200
10.9.4 测试管理工具 201
第11章 软件运行维护 202
11.1 概述 202
11.1.1 软件维护的定义 202
11.1.2 影响维护工作量的因素 203
11.1.3 软件可维护性 204
11.2 软件维护的实施 207
11.2.1 维护机构 207
11.2.2 维护的流程 207
11.3 遗留系统的再工程 209
11.3.1 遗留系统的演化 209
11.3.2 软件再工程和逆向工程 210
第12章 软件安全可靠性 214
12.1 概述 214
12.1.1 安全关键软件定义 215
12.1.2 安全关键软件开发难点和挑战 216
12.2 安全关键软件开发过程 217
12.2.1 软件安全计划 219
12.2.2 系统分系统设计与分析 220
12.2.3 软件安全性需求开发 232
12.2.4 软件安全性设计 246
12.2.5 软件安全性实现 250
12.2.6 软件安全性测试 250
12.2.7 软件运行维护 250
12.2.8 软件安全性追踪分析及软件变更安全性分析 251
12.3 软件可靠性设计和测试验证 252
12.3.1 软件可靠性分配与预计 252
12.3.2 软件可靠性设计 255
12.3.3 软件可靠性分析 256
12.3.4 软件可靠性测试 258
12.3.5 软件可靠性评估 259
第13章 软件项目管理与计划 262
13.1 概述 262
13.2 软件项目管理过程 262
13.2.1 启动软件项目 263
13.2.2 成本估算 263
13.2.3 风险分析 263
13.2.4 进度安排 264
13.2.5 追踪和控制 264
13.3 软件开发计划的实现过程 264
13.3.1 计划初始阶段 264
13.3.2 制订软件开发计划 265
13.3.3 对软件开发计划进行审查和批准 265
13.3.4 实施软件开发计划 265
13.3.5 软件开发过程的度量和评价 265
13.3.6 修改软件开发计划 265
13.4 软件开发成本估算 266
13.4.1 基于参数化模型的软件成本估算 266
13.4.2 非参数化的软件成本估算 271
（13-6） 272
13.5 进度安排 272
13.5.1 制订开发进度计划 273
13.5.2 进度安排的图形方法 273
13.5.3 追踪与控制 274
13.6 风险管理 274
13.6.1 风险识别 274
13.6.2 风险估算 275
13.6.3 风险评价 275
13.6.4 风险监控与应对 275
第14章 配置管理 277
14.1 概述 277
14.1.1 术语和定义 278
14.1.2 配置管理库 280
14.1.3 配置管理的组织和职责 281
14.2 配置管理流程 282
14.2.1 制订配置管理计划 283
14.2.2 建立配置管理系统 286
14.2.3 创建和发布基线 287
14.2.4 跟踪与控制变更 288
14.2.5 配置记录和报告 291
14.2.6 配置审核 292
14.3 技术状态控制 293
14.3.1 系统级分析与设计 293
14.3.2 软件需求分析 293
14.3.3 软件设计 294
14.3.4 软件实现 294
14.3.5 软件测试 294
14.3.6 验收交付 295
14.3.7 运行维护 295
14.4 配置管理工具 296
14.4.1 常用配置管理工具 296
14.4.2 选型与使用注意事项 297
第15章 软件质量保证 299
15.1 概述 299
15.2 质量保障组织机构 299
15.3 质量保证流程 300
15.3.1 制订软件质量保证计划 302
15.3.2 实施软件质量保证活动 303
15.3.3 不符合项处理 306
15.3.4 质量保证维护 307
15.4 软件评审 307
15.4.1 评审的分类 307
15.4.2 评审原则 309
15.4.3 评审计划 309
15.4.4 评审流程 309
第16章 模型驱动软件开发方法 311
16.1 概述 311
16.2 模型驱动架构 315
16.3 体系结构描述语言 318
16.3.1 UML 318
16.3.2 SysML 319
16.3.3 AADL 320
16.3.4 MARTE 323
16.3.5 比较分析 324
16.4 模型驱动开发方法的关键技术 325
16.4.1 需求分析 325
16.4.2 面向领域的建模语言语义扩展 326
16.4.3 模型转换 329
16.4.4 代码生成 329
16.4.5 基于模型的验证技术 330
16.4.6 部署与重构 330
16.5 工具支持 331
16.5.1 商业工具 331
16.5.2 开源工具 332
16.5.3 领域模型驱动开发环境研制 336
16.6 小结 337
第17章 形式化软件开发方法 339
17.1 概述 339
17.2 形式化方法的选用原则 341
17.2.1 形式化程度 341
17.2.2 形式化方法的使用范围 342
17.2.3 合理的预期 343
17.3 形式化软件开发过程 343
17.3.1 软件系统刻画阶段 343
17.3.2 建模阶段 344
17.3.3 规约阶段 344
17.3.4 分析阶段 345
17.3.5 归档阶段 345
17.3.6 维护阶段 345
17.4 需求描述及形式化 346
17.4.1 需求捕捉的层次 346
17.4.2 需求陈述的明确性 346
17.4.3 需求追踪性 347
17.4.4 底层原理和直观描述的可用性 347
17.5 形式化建模 347
17.5.1 数学模型 348
17.5.2 离散和连续域的数学模型 349
17.6 形式化规格说明 353
17.6.1 形式化规范语言 353
17.6.2 形式化规范语言风格 355
17.6.3 形式化规范和生命周期的关系 355
17.6.4 检测形式化规格说明中的错误 356
17.6.5 形式化规格说明的效用 358
17.7 形式化分析 360
17.7.1 自动演绎 360
17.7.2 有限状态方法 363
17.8 工具支持 364
17.8.1 模型验证工具 364
17.8.2 定理证明工具 365
17.9 小结 365
17.9.1 应用类型 366
17.9.2 规模和结构 366
17.9.3 类型选择 366
17.9.4 形式化级别 366
17.9.5 使用范围 366
17.9.6 工具支持 366
参考文献
|
| 內容試閱：
|
第1章 概 述
20世纪60年代末，随着计算机硬件技术的进步和元器件质量的逐步提高，整机的容量、运行速度和可靠性有了明显的提高，计算机得到广泛应用。但软件开发仍处于“手工作坊”的阶段，引发了所谓的“软件危机”。软件危机是指落后的软件生产方式无法满足快速增长的计算机软件需求，从而导致软件开发和维护过程出现一系列问题的现象。随着软件规模的扩大、复杂性的增强以及功能的增加，高质量软件开发越来越困难，常会出现不能按时完成任务、产品质量得不到保证、工作效率低下和开发经费严重超支等情况。为了解决软件危机，人们逐渐开始认识软件的特性以及软件产品开发的内在规律，尝试用工程化的思想指导软件开发，于是软件工程诞生了，软件开发和生产的过程开始逐步改善。
1.1 软件工程的概念
1968年，在北大西洋公约组织举行的一次学术会议上，Friedrich Bauer提出了软件工程的概念，并将其定义为“为了经济地获得可靠的、能在实际机器上高效运行的软件而建立和使用的健全的工程规则”。这个定义肯定了工程化的思想在软件工程中的重要性，但是没有考虑软件产品的特殊性。经过40多年的发展，软件工程已经成为一门独立的学科，人们对软件工程也逐渐有了更全面、更科学的认识。
1.1.1 软件工程定义
从理论上看，软件工程的本质特征、理论和方法学都是由软件工程所研究的对象——“软件”确定的。为了理解软件工程，先要明确“软件”的基本特点。
在软件工业或者信息社会中，软件和程序是经常被提及的概念，但是软件并不仅仅等同于计算机程序。计算机程序是以某种编程语言编写的代码，或者是算法加上数据。而软件是代码、设计文档、支持文档以及中间工作产出的一个综合体，包括需求分析、系统设计、代码配置、测试用例和测试结果、用户手册等。
1990年，IEEE-610.12标准对软件工程的定义为：“将系统的、严格约束的、可量化的方法应用到软件的开发、运营和维护中，即将工程学应用到软件中，并对上述方法进行研究”。
软件工程采用工程化的方法来开发大规模的软件，以获得较高的生产率、低成本、可控的质量、可度量的开发进度。这里工程化的方法包括确定的方法学、过程、措施、工具、标准、组织方法、管理方法、质量保障系统等。软件工程的提出是为了解决软件危机带来的各种弊端，具体地讲，其目标包括：
1）使软件开发的成本能够控制在预计的合理范围内；
2）使软件产品的各项功能和性能能够满足用户需求；
3）提高软件产品的质量；
4）提高软件产品的可靠性；
5）使生产出来的软件产品易于移植、维护、升级和使用；
6）使软件产品的开发周期能够控制在预计的合理时间范围内。
实现上述目标既需要严格的理论方法支持，又需要在实践中总结经验，形成各领域特定的**实践原则。因此，软件工程应当是理论和经验的有机整合，这就形成了软件工程**定律：“软件工程的问题必须通过理论软件工程和经验软件工程方法学共同解决”。理论软件工程由抽象、归纳的方式刻画，是以形式化推导为中心的研究；经验软件工程采用具体的、演绎的、以数据为基础的方式刻画，是以试验、确认为中心的研究。
1.1.2 软件工程的基本约束
软件工程是一个特殊的工程学科，也是迄今为止人类面临的*为复杂的工程学科之一。由于软件工程内在的不可触摸性、复杂性、多样性以及对人的依赖，存在许多先天的约束。根据Dijkstra等的研究，软件工程的约束体现在认知约束、组织约束和资源约束3个方面：
1）认知约束来自于软件工程对象——“软件”的特性，主要体现在不可触摸性、复杂性、不确定性、多样性、多态性、难于表达、难于具体化、无法量化的质量指标等方面；
2）组织约束主要来自劳动力使用充分性，例如时间约束、生产率限制等；
3）资源约束主要体现在人员、成本和硬件等方面。
1.1.2.1 软件工程的认知约束
约束1（不可触摸性）
软件的不可触摸性是软件工程的基本约束之一。软件是一种抽象结构，无法利用物理对象构造，并且软件的所有开发过程都是不可触摸的，包括问题表示、需求描述、设计和实现等。因此，难以对软件进行定义和表达。
约束2（复杂性）
软件的复杂性主要体现在错综复杂的内部连接和外部耦合，包括软件架构、行为和环境的复杂性。架构复杂性主要涉及数据对象、外部内部表示之间的复杂性；行为复杂性是指处理过程、输入输出方式复杂带来的问题；环境复杂性是指软件运行所处的硬件平台、用户的操作行为等多种多样。由于软件的部件、功能、操作、数据对象之间存在着复杂的互联关系，任何一个地方发生变动都可能导致多个不可预知的后果。因此，大型软件系统开发中，任何人都无法真正理解整个系统。项目领导和系统架构师缺乏对系统实现细节的充分把握；而程序员则可能缺乏系统的全局视图，无法理解系统与其他分系统、部件之间的交互。
约束3（不确定性）
软件的不确定性是指即使给定一个算法，在设计阶段也无法完全确定软件系统中的所有事件、行为以及它们的发生顺序。软件的许多行为只能在运行时才能确定。
约束4（多样性）
多样性是指软件有多种属性，并且每个属性包括多个方面，包括软件的类型、风格、架构、行为、平台、应用领域、实现技术、可用性、可靠性和质量等。仅仅从软件的类型上看，至少可以被分为系统软件、工具软件和应用软件。工具类软件又可以细分为编译器、代码生成器、通信网络软件、数据库管理系统和测试软件。
约束5（多态性）
多态性表示软件设计和实现的途径和风格具有多种方式，可能的解空间非常大。根据认知信息学的问题求解理论，软件设计和开发是一个开放问题，同时是一个创造性的过程。因此，无论是可能解空间，还是产生一个具体的解的路径都是不确定的。相似地，软件实现也具有多态性，任何一个设计的实现不是**的，会受多种因素影响，这些因素包括编程语言、目标计算机、编码风格、数据模型、内存分配方式等。
约束6（难于表达）
软件系统通常从3个侧面来表达，即软件架构、静态行为、动态行为。软件系统无论从结构上还是行为上进行表达、建模、表示和量化都非常困难，尤其是形式化或者严格的表达更为困难。
约束7（难于具体化）
由于软件系统的特征难以表达，在描述软件系统的架构和行为时，单一的表示形式难以满足描述需求，只有通过复合的表示方法才能够更为准确地描述。例如，图形化技术对于表示软件系统的概念模型非常有用，但却无法直接支持后续的自动代码生成。
约束8（无法量化的质量指标）
软件质量包含许多错综复杂的方面，难以量化建模和度量。例如，软件的设计质量、软件可用性、软件实现有效性、软件可靠性等至今仍然无法度量。针对大规模软件系统，如果不能度量其所有质量属性，那么就不能够完全控制该系统的开发。在软件工程中，使用定性的或者非正式的确认和评估技术（如评审）代替了量化技术。
1.1.2.2 软件工程的组织约束
软件工程的组织约束是从协作和管理的需求出发，使得具有不同角色的软件工程师之间协同、高效地完成任务。软件工程可能面临许多不同的组织约束，但是*为根本的约束有时间依赖、生产力限制、劳动时间不可转换。
约束1（时间依赖）
软件工程中几乎所有的组织问题都依赖于时间，例如软件开发进度安排、劳动力分配等。
约束2（生产力限制）
软件开发是一项智力型、具有创造性的活动，几乎所有过程都依赖于人的认知能力，包括抽象、创造、问题求解、学习和理解等。软件生产率与开发人员的能力有关。
约束3（劳动时间不可转换）
软件开发是一项群体性活动，需要在开发人员之间维持极高的协作和沟通。传统的工程学科中，劳动和时间是可以互换的，但是软件工程实践表明，难以简单地将劳动力和时间进行互换，需要考虑协作与沟通的代价。
1.1.2.3 软件工程的资源约束
软件开发过程会使用到大量的资源，核心的资源约束包括成本约束、人的约束和硬件约束。
约束1（成本约束）
软件研制需要成本，不仅包括开发成本，还包括运行和维护成本。成本必须处于受控状态，不恰当的软件工程组织方式可能会导致无用成本的增加。
约束2（人的约束）
所有的软件工程活动和过程都是由人进行的，受人的特征、认知和创造能力的约束，同时还受激励和态度的影响。
约束3（硬件约束）
软件是一个抽象的结构，其行为和能力只能通过硬件平台体现，包括硬件计算机系统、与计算机平台连接的外部IO设备等。在一些软件工程活动中，软件系统和硬件平台是同步开发的，硬件平台的可用性制约了软件工程的进展。
1.1.3 软件工程的研究内容
在软件工程发展过程中，研究者采用了各种途径来处理所面临的问题和约束，归纳起来可以分为编程方法学、软件开发模型、软件工程过程、自动化软件工程环境和软件工程理论。
这些方法对于软件工程所面临的基本问题的有效性各不相同。编程方法学和软件开发模型等传统的方法通常对于技术类问题解决较好，但是并没有涉及底层的理论问题、组织问题和管理问题。软件工程过程对于组织、管理问题提供了全面的解决方案，但是仍然缺乏理论支持。自动化软件工程集成了系统和计算机辅助软件工程工具，使软件开发人员能够在一定程度上从一些软件开发任务中解脱出来，但是仍然存在不少关键问题没有解决。软件工程理论则是一种理想化的软件工程方法，它能够全面覆盖软件工程的所有问题，但是目前仍然处于探索阶段。
1.1.3.1 编程方法学
编程方法学是软件工程的雏形，提出了许多有用的原则，包括抽象、信息隐藏、功能分解、模块化和可重用性等。它对程序设计提出了一些要求，并且给出一定的技术支持。
从20世纪50年代到现在，已经发展出了多种软件编程方法学。50年代开始，软件编程中引入了功能分解；70年代，结构化编程方法和抽象数据类型极大地促进了软件编程方法学的发展，使得软件编程方法学为广大软件工程人员所熟悉。进入80年代，面向对象的编程方法出现，它具备结构化编程和抽象数据类型的优点，同时还增加了其他具有良好组织的机制，包括封装、继承、可重用性、多态等，很快被广泛接受。面向对象的编程方法学*为显著的特征就是利用代码和系统层的继承支持软件重用。进入90年代，在面向对象的编程方法学的基础上，发展出了基于构件的编程方法学，更好地支持了软件分解、组合，以及商业软件的快速重用。
1.1.3.2 软件开发模型
软件编程方法学主要提出了程序设计的一些概念原则，侧重于软件设计和实现层的技术性要求。为了弥补软件工程在组织、管理和高层技术上的指导，研究者们提出了软件开发模型的概念。软件开发模型侧重于对软件工程的阶段、阶段之间的关系进行更为宏观的约束。
具体来讲，软件开发模型是指软件开发全部过程、活动和任务的结构框架。软件开发通常分为需求、设计、编码、测试等阶段。软件开发模型明确定义不同阶段的主要活动和任务，确定每个阶段之间的关系。典型的软件开发模型包括瀑布模型、原型化开发模型、螺旋模型、增量式开发模型等。
软件开发模型除了提供一个宏观的结构框架之外，还提供每个阶段的详细方法。例如，软件设计阶段可能选择结构化方法和面向对象方法，可以使用流程图、数据流图、实体关系图等。
软件开发模型虽然为软件设计和实现提供了一组指南，但它主要集中在软件开发生存周期的技术层面，组织和管理的方法学和过程仍然没有涉及。
1.1.3.3 软件工程过程
软件工程过程也被称为软件过程，是指在软件生存周期内，为实现特定目标而进行的一系列相关活动。每个活动都有特定的步骤，对软件工程的组织、开发和管理提供功能上连贯、可重复、可重用的框架。软件工程过程关注软件工程的系统、组织和管理的基础设施，对软件工程的范围进行了延伸，从而满足软件产品在复杂性和规模方面的快速增长需要。
到目前为止，已经出现了多个软件工程过程模型。典型的过程模型是能力成熟度模型集成（Capability Maturity Model Integration，CMMI），它不关注软件流程细节，仅仅关注制定、管理、控制软件流程所需的管理要点，以软件开发流程作为全面质量管理的架构，提升组织管理软件开发的能力。
1.1.3.4 自动化软件工程环境
为了支持编程方法学和软件开发模型，提高软件开发效率和质量，需要使一些软件开发工作自动化，产生了自动化软件工程。自动化软件工程集成了系统和计算机辅助软件工程工具，使软件开发人员能够在一定程度上从一些软件开发任务中解脱出来。自动化软件工程涉及人工智能、认知信息学、知识工程等方面知识，例如统一建模语言（Unified Modeling Language，UML）和相关的工具（Rational Rose）。
在自动化软件开发中，主要的技术难点是需求获取和规格说明、系统架构的行为建模、应用领域的知识表示、实现的正确性证明等。目前，自动化软件工程相关技术已经取得了较大的进步，但是仍然存在不少关键问题没有解决。
1.1.3.5 软件工程理论
软件工程理论是软件工程学科发展过程遵循的基本原理和普遍规律。实际的软件开发项目只有在一定的软件工程理论约束下才能贯彻软件工程思想。著名软件工程专家B.W.Boehm提出了以下软件工程的基本原理：
1）将软件的生存周期划分为多个阶段，对每个阶段实行严格的管理。软件开发是一个漫长的过程，人们可以根据工作的特点和目标，把整个软件的开发周期分为多个阶段，并且为每个阶段制定分阶段的计划和验收标准，这样有利于整个软件开发过程的管理。
2）坚持阶段评审制度，确保软件产品的质量。严格贯彻与实施阶段评审制度可以帮助软件开发人员及时发现并改正错误。在软件开发的过程中，错误发现的越晚，修正错误所需要付出的代价就会越大。只有在本阶段的工作通过评审后，才能进入下一阶段的工作。
3）实施严格的产品控制，适应软件规格的变更。在软件开发的过程中，用户需求可能不断发生变化。有些时候，即使用户的需求没有改变，软件开发人员也会受经验的限制或与用户交流不充分的影响，难以做到一次获得所有正确的需求。因此，需求工作贯穿整个软件开发的生命周期，需求的变更是不可避免的，要严格实施版本控制和变更管理。
4）采用先进的程序设计技术，提高软件开发和维护效率。先进的程序设计技术，例如面向对象软件开发方法、模型驱动软件开发方法，可以使开发的软件产品更易于维护和修改，还可以提高开发效率。
5）软件产品易于审查和度量。虽然软件产品的可见性比较差，但是它的功能和质量应当能够被准确地审查和度量，从而有利于进行有效的项目管理。
6）合理安排软件开发小组的人员，进行高效的团队管理。
7）不断改进软件工程实践。随着计算机科学的发展，软件从业人员应当不断总结经验并主动学习新技术。
1.2 航天实施软件工程的必要性
随着航天型号产品和计算机技术的飞速发展，以硬件为基础、软件为核心的特征日益明显，软件的质量和可靠性成为影响航天型号产品质量和可靠性的关键因素之一。
1.2.1 软件质量问题影响型号任务成败
随着软件在型号中的应用越来越多，软件产品的问题占总质量问题的比例有上升趋势。国内外的型号产品在装配、测试和发射场，以及在轨飞行过程中，由于软件问题影响任务成功的案例并不罕见。以下是国际上发生的重大航天事故中与软件相关的案例，都是由于软件工程实施不到位造成的。
1.2.1.1 金星探测器水手1号
1962年7 月22 日，携带着飞向金星的无人飞船水手1号的宇宙神火箭从美国卡纳维拉尔角空军基地发射升空。起飞后5 min，控制飞行姿态的计算机程序发生故障，导致火箭偏离了预定轨道，发射人员在离星箭分离只有6 s时发出了自毁指令，在大西洋上空将整个火箭摧毁。这次事故使美国损失了1850万美元，使美国太空探险史上的首次太阳系飞行计划化为泡影。
事故原因定位在软件中，是由于说明书中的一个描述错误而导致的程序错误。数学中，在变量符号上面加个水平的“ˉ”符号表示求平均，在提供给程序员的手写制导方程中，这个“ˉ”号不小心被漏掉了。程序原本应该操作平均速度，结果程序员按照算法编写的程序使用了从雷达得到的原始速度。程序运行时觉察到了火箭速度的微小波动，在经典的负反馈循环中，试图调整火箭的速度，出现了不稳定行为。
这个有缺陷的程序曾用于以前的几次飞行任务，但出问题的语句是**次执行。以前的几次飞行中，火箭的飞行是由地面控制的，没有触发出问题的代码执行。这次由于天线故障，火箭无法接收到无线电指令，所以使用了飞船上的控制软件，执行了这段以前没有使用过的代码。
1.2.1.2 阿里安5号
1996年6月4日，欧洲太空局（European Space Agency，ESA）耗资67亿美元，历时10多年研制的阿里安5号火箭带着4颗卫星在法属圭亚那库鲁航天中心第三发射场首次升空，这4颗卫星用于研究地球和太阳之间的相互影响。当地时间上午9时33分59秒（H0），芯级发动机点火。H0+7.5 s，助推器点火，起飞正常。但在H0+37 s至H0+39 s，两个助推器喷管突然摆到极限位置，火箭很快倾斜，大幅度偏离轨道，在强烈气动力的作用下引起箭体结构的断裂，随后火箭安全系统自动将火箭和助推器炸毁。ESA宣布飞行试验失败。
事故的调查结果显示，虽然阿里安5号重用了阿里安4号的代码，但触发了程序的一个错误。程序中没有对64位浮点数转换为16位带符号整数可能引发的异常进行特殊处理，而是采用了缺省的处理办法——停机。阿里安5号的惯性参考系统软件计算机程序运行中，水平偏差值（BH）超出计算机软件的限值。当对BH进行浮点数转换整数操作时，发现BH超出限值，就触发了停机处理。首先是备份计算机崩溃，0.05 s之后，主计算机也崩溃了。这些计算机的崩溃直接导致了火箭的主要处理器失效，使火箭的引擎过载，同时导致火箭在发射40 s后解体破碎。
1.2.1.3 火星气候轨道器MCO
1998年12月11日，美国国家航空航天局（National Aeronautics and Space Administration，NASA）在卡纳维拉尔角发射了火星气候轨道器MCO，计划使其进入火星轨道绕行并探测火星气候，为未来实施火星登陆计划选择合适的地点。MCO经过6.65亿 km的飞行，终于飞到了火星。但是它在准备进入绕火星运行的轨道时飞行高度太低（仅57 km），大大低于技术人员提出的约85~100km的*小安全距离，与预定的140~150 km高度更相差甚远。高度态度，探测器可能在火星的大气中因气动热而被“火葬”，甚至可能坠毁在火星表面上。该项目连同运载火箭在内，共损失1.25亿美元。
事故发生后，主管该项目的NASA喷气推进实验室等部门迅速开始了调查工作。初步分析时认定，问题可能出在卫星软件上，也可能是地面系统的问题，同时，人员操作失误的可能性也不完全排除。但*后查出的结果却让人难以置信：造成MCO飞行高度太低的原因竟然是公制和英制的转换问题。研制MCO的洛克希德?马丁公司对探测器的一项关键操作提供的是英制单位的数据，而NASA喷气推进实验室的导航人员想当然地以为是公制，未加转换便直接将英制数据输入了采用公制数据的计算机系统内，从而造成了严重的导航错误。
1.2.1.4 火星极地着陆器
NASA于1999年1月发射了由其喷气推进实验室研制的火星极地着陆器，该飞行器计划在火星南极登陆后工作9个月，进行火星气候等3项科学研究。但它在12月3日到达火星执行着陆过程后，没有按原计划向地球发回任何信息。地面工作人员尽力联系，终告失败。
NASA不清楚通讯失败的原因，然而失败审查委员会认为“在火星极地着陆器着陆前，软件提前（在40 m的高度上）向反推火箭发动机发出了关机指令”是导致该事故发生的*有可能的原因。火星极地着陆器正常的触地速度是2.4 ms，但由于反推火箭发动机提前关机，可能致使着陆器以22 ms的速度冲向火星地面。
分析表明，导致软件提前发出关机指令的原因，是因为当着陆器的腿在1500 m高度展开时引起触地传感器发出了虚假触地信号。这个虚假触地信号在40 m的高度被“使能”，导致反推火箭发动机立即关机。通过几次地面试验验证了该错误的触地信号问题确实会发生。究其原因，触地传感器（霍尔效应磁传感器）的特点是“当着陆器的3条腿展开时发生的震动可能导致霍尔传感器错误地发出触地信号”。为了避免这种信号的影响，在软件的系统需求中特意给出了“在12 m高度以上，不得使用霍尔传感器的信号”的需求。但是该软件的需求规格说明中漏掉了此项需求（见图 1 1）。调查组在对着陆器的腿展开进行测试时，确实发现了霍尔传感器发出了错误的触地信号，而软件没有将此信号的状态清除。如果在实际飞行中，当着陆器达到40 m高度时，此状态由于“使能”打开而发生作用，可导致反推火箭发动机提前关机。
图 1 1 火星极地着陆器的系统需求与飞行软件需求的映射
1.2.1.5 大力神4B半人马座军事星II
1999年4月30日，大力神-4B运载火箭带着军事星II有效载荷顺利离开卡纳维拉尔角空军基地40号发射台，这次发射采用的是液体的半人马座上面级。火箭发射9 min12 s后，遥控数据表明，大力神-4B的固体助推器、芯级和推进系统工作正常。发射后9 min36 s，上面级的发动机点火工作，2 min后，进入174 km×187 km的轨道，倾角为28 ?，此时尚无任何异常。大约发射后30 min，控制人员发现发动机**次点火工作不稳定，发生异常，地面发出遥控指令后，火箭仍然执行错误指令。
根据飞行程序，在发射后1 h15 min，上面级开始进行第二次点火工作，这次点火工作主要是将卫星送入地球同步轨道高度。发射后6 h22 min，在这个高度将进行第三次点火工作，将卫星推入同步轨道，然后卫星漂移到南美附近的西太平洋上空，之后几分钟卫星与上面级分离。而实际情况是，半人马座上面级的第二次、第三次点火均提前进行，并导致星箭过早分离，大约发射3 h后，火箭将卫星送入了740 km×5000 km的无用轨道，而不是预定的地球同步轨道。地面人员试图挽救卫星，曾成功地稳定了卫星姿态，并展开了35.4 m的太阳能电池翼。尽管卫星的电力供应正常，但从军用通信的观点来说，这次任务是失败的。加上火箭成本，这次发射失败共造成12.3亿美元的损失。
事故调查委员会的结论是，发射失败是由洛克希德?马丁公司研制和验证的软件问题引起的。洛克希德?马丁公司的一个软件工程师将惯性导航单元的软件文件中一个旋转速度过滤常量的值使用错了。洛克希德?马丁公司为了保持军事星的一致性，保留了军事星I的过滤器常量值。
1.2.1.6 事故原因分析
在软件开发过程中，软件工程在防止软件错误的产生、及时发现并排除软件的错误方面已经形成了一系列的措施。但由于软件工程的工作没有做到位，才导致以上事故发生。
（1）软件开发方面
火星极地着陆器、阿里安5号、火星气候轨道器MCO事件都是典型的软件开发问题。火星极地着陆器的失败是因为遗失需求导致的；阿里安5号的失败是软件设计缺陷导致的；火星气候轨道器MCO的失败是模块间传递的参数使用错误导致的。在这些案例中没有很好地定义软件开发过程，参与人员在文档的编写和对开发过程的完全理解上执行得不够好。尤其对于已经执行过飞行任务的软件，由于程序成熟，开发人员没有很好地理解整个软件开发过程。
（2）软件测试、验证和确认方面
软件测试、验证和确认是保障软件质量的重要手段，但在实践中可能没有严格执行，有时也会因为经验不足，测试难以发现问题或对发现的问题不敏感。火星极地着陆器需求丢失的问题出现在软件开发过程的早期，但在后续的软件走查、系统测试等多个测试阶段都没有发现。大力神4B事故同样如此。虽然NASA开发了一个独立的验证和确认程序，但是没有验证和确认速度过滤常量。在飞行程序装入惯性导航单元之后发射之前，并没有正式地检查过滤常量的合法性或者监测火箭的姿态速度。美国第45航空联队的第三航天发射中队和数百名承包商人员，在发射之前的测试中发现了问题，但由于他们之间缺少直接的交流而没有对错误进行改正。
（3）质量保证方面
航天型号系统极其复杂，对质量保证提出了很高的要求。在上述事故中，虽然洛克希德?马丁公司、NASA、ESA等单位作为承制方有丰富的研制经验，也有软件质量保证的职能，但是对整体流程和软件仍然缺乏深入理解，在质量保证方面也会有不到位之处。
1.2.2 航天型号软件研制面临挑战
航天型号研制是一项复杂的系统工程，安全可靠性要求高并且参研单位众多，如何按照进度、经费计划，完成高质量的软件研制面临一系列挑战，结合航天软件研制特点，研究并实施航天型号软件工程的理论、方法和技术，是保障航天任务的重要措施。
1.2.2.1 软件在航天型号中的数量、规模快速增长，需提高软件研制水平
软件为航天型号提供的功能比重呈明显增长趋势。1960年到2000年40年间，美国军用飞行器中，软件提供给飞行员的功能从8%增长到80%。我国航天型号也是如此，以载人航天工程为例，交会对接任务中箭载、船载、器载软件配置项比神舟七号飞行任务的软件翻了1倍。同时，随着空间科学试验种类不断增加，将更多地引进和使用“商用货架”应用软件、数据库与操作系统。从规模上看，传统的卫星等航天器的软件规模以中小规模为主，而空间站工程的软件规模以中大规模为主。面对软件数量和规模大大增加的趋势，软件的研发、测试、试验任务大量增多，资源矛盾更加突出，需要加强软件工程化的技术和管理措施保证软件质量。
1.2.2.2 安全关键软件的数量激增，需对安全可靠性进行有效保证
软件的安全可靠性问题是航天型号中非常关键的问题。航天型号中安全关键软件的比重较大，尤其是载人航天工程，软件配置项（含可编程逻辑类软件）中安全关键软件的比例高达50%。在软件研制过程中，安全相关软件必须经过严格的测试验证和安全分析，确保其潜在的缺陷*小。因此，航天型号软件工程化需要对安全关键软件提出特殊的研制流程和保障措施。
1.2.2.3 软件参研单位众多，需有效控制研制进度和质量
航天型号研制从系统到分系统，到硬件配置项和软件配置项，参研单位众多。以载人航天工程为例，工程采用矩阵式的管理体系，在平时和飞行任务期间分别实行两种管理模式，由总指挥和总设计师分别负责行政、技术两条线。全国直接承担载人航天核心研制建设任务的单位达100多家，有3000多家协作配套和保障单位，各系统、分系统、子系统的协作或配套单位更多。为了保证如此庞大的系统按照预期的进度、经费规划完成研制，需要进行严格的阶段划分和质量控制。
1.2.2.4 软件运行环境多样化，需要软件工具提升软件工程化水平
首先，软件运行环境多样化，需要开发环境类工具提升软件研制能力。航天型号采用的处理器与商用领域相比有一定特殊性，并可能广泛采用新型处理器、国产处理器。有些软件研制工具与运行环境密切相关，航天型号软件运行环境的特殊性，使编译器、测试工具、测试平台的需求发生了变化，需要投入更多的人力、物力和时间。尤其是编译器等基础软件，与生成的目标代码、系统的安全性直接相关，需要进行安全可靠性验证。
其次，需要过程管理工具和辅助工具提升管理水平。航天型号软件工程化涉及项目管理、需求管理、配置管理、质量保证等管理过程，涉及系统、分系统、软件配置项研制方的多方参与，以及分析、设计、开发、测试等多种人员角色，并且航天软件工程化过程有很多严格的要求，需要工具支持提升软件工程化的自动化水平和工作效率。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
