图书详情

配套资源图书内容样章/电子教材图书评价

配套资源

图书特别说明：由于成本考虑，本书不作为参考书赠送。如果确有授课教材选用的需求，可将详细情况发送给本书专属联系人，我们将进一步沟通并酌情处理。

本书资源

本书暂无资源

会员上传本书资源

图书内容

内容简介

本书作者是DO-178系列标准的直接制定者之一。书中详细介绍了如何基于最新版本的DO-178C标准进行高安全软件开发，既包括对标准的全面介绍，又包括依据该标准进行开发和审定的实用指南；既包含多年从事高安全软件研制、管理、审定工作的经验，又包含相关最新软件技术的深入讲解。主要内容有：在系统与安全性大视野中的软件；DO-178C标准的具体解释及如何有效使用；DO-178C相关的工具鉴定、基于模型的开发、面向对象技术、形式化方法；成功开发高安全软件及审定的实用建议；以及与高安全软件开发和验证相关的深入专题。

图书详情

ISBN：9787121259920

开本：16(185*260)

页数：364

字数：561

本书目录

第一部分  引言

第1章　引言和概览	2
1.1　安全关键软件的定义	2
1.2　安全性问题的重要性	2
1.3　本书目的和重要提示	4
1.4　本书概览	5

第二部分  安全关键软件开发的语境

第2章  系统语境中的软件	8
2.1　系统开发概览	8
2.2　系统需求	10
2.2.1　系统需求的重要性	10
2.2.2　系统需求的类型	10
2.2.3　良好需求的特性	10
2.2.4　系统需求考虑	11
2.2.5　需求假设	14
2.2.6　分配到软硬件项	14
2.3　系统需求确认与验证	14
2.3.1　需求确认	14
2.3.2　实现验证	15
2.3.3　确认与验证建议	15
2.4　系统工程师最佳实践	16
2.5　软件与系统的关系	18

第3章  系统安全性评估语境中的软件	20
3.1　航空器与系统安全性评估过程概览	20
3.1.1　安全性工作计划	20
3.1.2　功能危险评估	21
3.1.3　系统功能危险评估	22
3.1.4　初步航空器安全性评估	22
3.1.5　初步系统安全性评估	22
3.1.6　共同原因分析	23
3.1.7　航空器安全性评估和系统安全性评估	23
3.2　开发保证	24
3.2.1　开发保证级别	25
3.3　软件如何置入安全性过程	25
3.3.1　软件的独特性	25
3.3.2　软件开发保证	26
3.3.3　其他视点	27
3.3.4　在系统安全性过程关注软件的建议	28

第三部分  使用DO-178C开发安全关键软件

第4章  DO-178C及支持文件概览	31
4.1　DO-178历史	31
4.2　DO-178C和DO-278A核心文件	33
4.2.1　DO-278A与DO-178C的不同	37
4.2.2　DO-178C附件A目标表概览	38
4.3　DO-330：软件工具鉴定考虑	41
4.4　DO-178C技术补充	41
4.4.1　DO-331：基于模型的开发补充	42
4.4.2　DO-332：面向对象技术补充	42
4.4.3　DO-333：形式化方法补充	42
4.5　DO-248C：支持材料	43

第5章  软件策划	44
5.1　引言	44
5.2　一般策划建议	44
5.3　5个软件计划	46
5.3.1　软件合格审定计划	46
5.3.2　软件开发计划	48
5.3.3　软件验证计划	49
5.3.4　软件配置管理计划	51
5.3.5　软件质量保证计划	53
5.4　3个开发标准	54
5.4.1　软件需求标准	55
5.4.2　软件设计标准	55
5.4.3　软件编码标准	56
5.5　工具鉴定计划	57
5.6　其他计划	57
5.6.1　项目管理计划	57
5.6.2　需求管理计划	57
5.6.3　测试计划	57

第6章  软件需求	58
6.1　引言	58
6.2　定义需求	58
6.3　良好软件需求的重要性	59
6.3.1　原因1：需求是软件开发的基础	59
6.3.2　原因2：好的需求节省时间和金钱	60
6.3.3　原因3：好的需求对安全性至关重要	60
6.3.4　原因4：好的需求对满足客户需要是必需的	61
6.3.5　原因5：好的需求对测试很重要	61
6.4　软件需求工程师	61
6.5　软件需求开发概览	62
6.6　收集和分析软件需求的输入	63
6.6.1　需求收集活动	64
6.6.2　需求分析活动	64
6.7　编写软件需求	65
6.7.1　任务1：确定方法	65
6.7.2　任务2：确定软件需求文档版式	66
6.7.3　任务3：将软件需求划分为子系统和/或特征	66
6.7.4　任务4：确定需求优先级	67
6.7.5　一个简单迂回（不是一个任务）：要避免的斜坡	67
6.7.6　任务5：编档需求	68
6.7.7　任务6：提供系统需求的反馈	72
6.8　验证（评审）需求	73
6.8.1　同行评审推荐实践	74
6.9　管理需求	76
6.9.1　需求管理基础	76
6.9.2　需求管理工具	77
6.10  需求原型	78
6.11  可追踪性	79
6.11.1　可追踪性的重要性和好处	79
6.11.2　双向可追踪性	79
6.11.3　DO-178C和可追踪性	80
6.11.4　可追踪性挑战	81

第7章  软件设计	83
7.1　软件设计概览	83
7.1.1　软件体系结构	83
7.1.2　软件低层需求	83
7.1.3　设计打包	85
7.2　设计方法	85
7.2.1　基于结构的设计（传统）	85
7.2.2　面向对象的设计	86
7.3　良好设计的特性	86
7.4　设计验证	89

第8章  软件实现：编码与集成	91
8.1　引言	91
8.2　编码	91
8.2.1　DO-178C编码指南概览	91
8.2.2　安全关键软件中使用的语言	92
8.2.3　选择一种语言和编译器	94
8.2.4　编程的一般建议	95
8.2.5　代码相关的特别话题	102
8.3　验证源代码	103
8.4　开发集成	104
8.4.1　构建过程	104
8.4.2　加载过程	105
8.5　验证开发集成	105

第9章  软件验证	106
9.1　引言	106
9.2　验证的重要性	106
9.3　独立性与验证	107
9.4　评审	108
9.4.1　软件计划评审	108
9.4.2　软件需求、设计和代码评审	108
9.4.3　测试资料评审	108
9.4.4　其他资料项评审	108
9.5　分析	109
9.5.1　最坏情况执行时间分析	109
9.5.2　内存余量分析	110
9.5.3　链接和内存映像分析	110
9.5.4　加载分析	111
9.5.5　中断分析	111
9.5.6　数学分析	111
9.5.7　错误和警告分析	112
9.5.8　分区分析	112
9.6　软件测试	112
9.6.1　软件测试的目的	112
9.6.2　DO-178C软件测试指南概览	114
9.6.3　测试策略综述	115
9.6.4　测试策划	119
9.6.5　测试开发	120
9.6.6　测试执行	122
9.6.7　测试报告	124
9.6.8　测试可追踪性	124
9.6.9　回归测试	124
9.6.10易测试性	125
9.6.11验证过程中的自动化	125
9.7　验证的验证	126
9.7.1　测试规程评审	127
9.7.2　测试结果的评审	127
9.7.3　需求覆盖分析	127
9.7.4　结构覆盖分析	128
9.8　问题报告	134
9.9　验证过程建议	136

第10章  软件配置管理	140
10.1　引言	140
10.1.1　什么是软件配置管理	140
10.1.2　为何需要软件配置管理	140
10.1.3　谁负责实现软件配置管理	141
10.1.4　软件配置管理涉及什么	142
10.2　SCM活动	142
10.2.1　配置标识	142
10.2.2　基线	143
10.2.3　可追踪性	143
10.2.4　问题报告	143
10.2.5　变更控制和评审	146
10.2.6　配置状态记录	147
10.2.7　发布	147
10.2.8　归档和提取	148
10.2.9　资料控制类	148
10.2.10加载控制	149
10.2.11软件生命周期环境控制	150
10.3　特别SCM技能	150
10.4　SCM资料	151
10.4.1　SCM计划	151
10.4.2　问题报告	151
10.4.3　软件生命周期环境配置索引	151
10.4.4　软件配置索引	151
10.4.5　SCM记录	152
10.5　SCM陷阱	152
10.6　变更影响分析	154

第11章  软件质量保证	157
11.1　引言：软件质量和软件质量保证	157
11.1.1　定义软件质量	157
11.1.2　高质量软件的特性	157
11.1.3　软件质量保证	158
11.1.4　常见质量过程和产品问题的例子	159
11.2　有效和无效SQA的特征	159
11.2.1　有效的SQA	159
11.2.2　无效的SQA	160
11.3　SQA活动	161

第12章  合格审定联络	164
12.1　什么是合格审定联络	164
12.2　与合格审定机构的沟通	164
12.2.1　与合格审定机构协调的最佳实践	165
12.3　软件完成总结	167
12.4　介入阶段审核	168
12.4.1　SOI审核概览	168
12.4.2　软件作业辅助概览	169
12.4.3　使用软件作业辅助	171
12.4.4　对审核者的一般建议	171
12.4.5　对被审核者的一般建议	176
12.4.6　SOI评审细节	177
12.5　合格审定飞行测试之前的软件成熟度	184

第四部分  工具鉴定和DO-178C补充

第13章  DO-330和软件工具鉴定	186
13.1　引言	186
13.2　确定工具鉴定需要和级别（DO-178C的12.2节）	187
13.3　鉴定一个工具（DO-330概览）	190
13.3.1　DO-330的需要	190
13.3.2　DO-330工具鉴定过程	190
13.4　工具鉴定特别话题	197
13.4.1　FAA规定8110.49	197
13.4.2　工具确定性	197
13.4.3　额外的工具鉴定考虑	198
13.4.4　工具鉴定陷阱	199
13.4.5　DO-330和DO-178C补充	200
13.4.6　DO-330用于其他领域	200

第14章  DO-331和基于模型的开发与验证	201
14.1　引言	201
14.2　基于模型开发的潜在好处	202
14.3　基于模型开发的潜在风险	204
14.4　DO-331概览	206
14.5　合格审定机构对DO-331的认识	210

第15章  DO-332和面向对象技术及相关技术	211
15.1　面向对象技术介绍	211
15.2　OOT在航空中的使用	211
15.3　航空手册中的OOT	212
15.4　FAA资助的OOT和结构覆盖研究	212
15.5　DO-332概览	213
15.5.1　策划	213
15.5.2　开发	213
15.5.3　验证	213
15.5.4　脆弱性	214
15.5.5　类型安全	214
15.5.6　相关技术	214
15.5.7　常见问题	214
15.6　OOT建议	215
15.7　结论	215

第16章  DO-333和形式化方法	216
16.1　形式化方法介绍	216
16.2　什么是形式化方法	217
16.3　形式化方法的潜在好处	218
16.4　形式化方法的挑战	219
16.5　DO-333概览	220
16.5.1　DO-333的目的	220
16.5.2　DO-333与DO-178C的比较	220
16.6　其他资源	222

第五部分  特别专题

第17章  未覆盖代码（无关、无效和非激活代码）	224
17.1　引言	224
17.2　无关和无效代码	224
17.2.1　避免无关和无效代码的晚发现	225
17.2.2　评价无关或无效代码	225
17.3　非激活代码	227
17.3.1　策划	229
17.3.2　开发	229
17.3.3　验证	230

第18章  现场可加载软件	231
18.1　引言	231
18.2　什么是现场可加载软件	231
18.3　现场可加载软件的好处	231
18.4　现场可加载软件的挑战	232
18.5　开发和加载现场可加载软件	232
18.5.1　开发系统成为现场可加载的	232
18.5.2　开发现场可加载软件	233
18.5.3　加载现场可加载软件	233
18.5.4　修改现场可加载软件	234
18.6　总结	234

第19章  用户可修改软件	235
19.1　引言	235
19.2　什么是用户可修改软件	235
19.3　UMS例子	236
19.4　为UMS设计系统	236
19.5　修改和维护UMS	238

第20章  实时操作系统	240
20.1　引言	240
20.2　什么是RTOS	240
20.3　为什么使用RTOS	241
20.4　RTOS内核及其支持软件	241
20.4.1　RTOS内核	242
20.4.2　应用编程接口	242
20.4.3　主板支持包	243
20.4.4　设备驱动	243
20.4.5　支持库	244
20.5　安全关键系统中使用的RTOS的特性	244
20.5.1　确定性	244
20.5.2　可靠的性能	244
20.5.3　硬件兼容	244
20.5.4　环境兼容	244
20.5.5　容错	244
20.5.6　健康监控	245
20.5.7　可审定	245
20.5.8　可维护	245
20.5.9　可复用	246
20.6　安全关键系统中使用的RTOS的特征	246
20.6.1　多任务	246
20.6.2　有保证和确定性的可调度性	246
20.6.3　确定性的任务间通信	248
20.6.4　可靠的内存管理	248
20.6.5　中断处理	248
20.6.6　钩子函数	249
20.6.7　健壮性检查	249
20.6.8　文件系统	249
20.6.9　健壮分区	249
20.7　需考虑的RTOS问题	250
20.7.1　要考虑的技术问题	250
20.7.2　要考虑的合格审定问题	252
20.8　其他的RTOS相关话题	254
20.8.1　ARINC 653概览	254
20.8.2　工具支持	256
20.8.3　开源RTOS	256
20.8.4　多核处理器、虚拟化和虚拟机管理器	257
20.8.5　保密性	257
20.8.6　RTOS选择问题	257

第21章  软件分区	258
21.1　引言	258
21.1.1　分区：保护的一个子集	258
21.1.2　DO-178C和分区	258
21.1.3　健壮分区	259
21.2　共享内存（空间分区）	260
21.3　共享中央处理器（时间分区）	261
21.4　共享输入/输出	262
21.5　一些与分区相关的挑战	262
21.5.1　直接内存访问	262
21.5.2　高速缓存	263
21.5.3　中断	263
21.5.4　分区之间通信	263
21.6　分区的建议	264

第22章  配置数据	268
22.1　引言	268
22.2　术语和例子	268
22.3　DO-178C关于参数数据的指南总结	269
22.4　建议	270

第23章  航空数据	274
23.1　引言	274
23.2　DO-200A：航空数据处理标准	274
23.3　FAA咨询通告AC 20-153A	277
23.4　用于处理航空数据的工具	278
23.5　与航空数据相关的其他工业文件	278
23.5.1　DO-201A：航空信息标准	279
23.5.2　DO-236B：航空系统性能最低标准：区域导航要求的导航性能	279
23.5.3　DO-272C：机场地图信息的用户需求	279
23.5.4　DO-276A：地形和障碍数据的用户需求	279
23.5.5　DO-291B：地形、障碍和机场地图数据互换标准	279
23.5.6　ARINC 424：导航系统数据库标准	279
23.5.7　ARINC 816-1：机场地图数据库的嵌入式互换格式	280

第24章  软件复用	281
24.1　引言	281
24.2　设计可复用构件	282
24.3　复用先前开发的软件	285
24.3.1　为在民用航空产品中使用而评价PDS	285
24.3.2　复用未使用DO-178[  ]开发的PDS	289
24.3.3　COTS软件的额外考虑	290
24.4　产品服役历史	292
24.4.1　产品服役历史的定义	292
24.4.2　使用产品服役历史寻求置信度的困难	292
24.4.3　使用产品服役历史声明置信度时考虑的因素	292

第25章  逆向工程	294
25.1　引言	294
25.2　什么是逆向工程	294
25.3　逆向工程的例子	295
25.4　逆向工程时要考虑的问题	295
25.5　逆向工程的建议	296

第26章  外包和离岸外包软件生命周期活动	301
26.1　引言	301
26.2　外包的原因	302
26.3　外包的挑战和风险	302
26.4　克服挑战和风险的建议	305
26.5　总结	311

附录A  转换准则举例	312
附录B  实时操作系统关注点	318
附录C  为安全关键系统选择实时操作系统时考虑的问题	321
附录D  软件服役历史问题	324
缩略语	327
参考文献	332

展开

前言

推荐语
“Rierson女士从自己的经验和大量项目中提炼出一本简明易懂的书……该书的出众之处在于诚挚、现实的建议，以及对各个DO-178C目标的透视。如果项目认真借鉴她的指南，并从起点开始实现，我相信项目将以比“打勾式项目”更小的成本，产出更加安全的软件。”
——Wendy Ljungren，通用电气航空

“……任何从事开发、验证或审定机载系统的人的必读书……本书对于在RTCA DO-178C及其相关文件的指导下开发软件密集的航空系统的过程，给出了非常清晰又相对简明的解释。本书是一份出色的作品，用非常实际的“要怎样做”和“不要怎样做”提供了必要的基础。”
——Andrew J. Kornecki，安柏瑞德航空大学教授

“本书出自一位博学的管理者和实践者的出色研究和经验……它使用易于理解的术语，精炼而准确地解释了规章中给出的指南……其结果是一本难以释卷的吸引人的著作。”
——George Romanski，Verocel公司总裁


随着软件复杂性和关键性的增长，以及项目被迫以更快速度和更低成本开发软件，保证软件密集系统的可靠和安全尤为重要。本书可为你配备有效和高效开发安全关键航空软件所需的信息。这些原则也适用于其他安全关键领域。

本书作者是一位安全关键软件的国际权威，以20多年的经验为背景，总结出了丰富的最佳实践和具体建议。本书是软件和系统经理、开发者和质量保证人员的宝贵参考，帮助你更自信地开发、管理和审批安全关键软件。

作者简介
利安娜 瑞尔森（Leanna Rierson）
安全关键软件和复杂电子系统领域的资深专家，多年担任美国联邦航空局（FAA）的软件和航空电子专家、航空计算机软件首席顾问，是在软件和复杂硬件技术领域具有A级授权的FAA委任工程代表（DER）。发表了大量关于安全关键软件、综合模块化航空电子（IMA）等方面的论文，领导了许多国际工程团队和工作会议，并为FAA编制了一系列课程、政策、手册以及指南材料。
她是DO-178C标准的重要参与者之一，在负责制定该标准的美国航空无线电技术委员会（RTCA）中担任一个工作组的副主席和编写组负责人。她还从事大量的相关培训和审定活动，合作过的众多航空器和航空电子公司包括波音（Boeing）、罗克韦尔-柯林斯（Rockwell Collins）、通用电气航空（GE Aviation）、霍尼韦尔（Honeywell）等。
译者简介
崔晓峰
研究员，北京大学计算机软件与理论专业博士，英国约克大学访问学者。现为研究员，长期从事大型关键软件系统研发与工程化管理工作。主要研究方向包括软件体系结构、软件需求工程、软件过程改进等。 

译者序
安全关键软件（safety-critical software）是指应用于航空、航天、交通、能源、医疗、军事等领域，其运行情况会影响到人身和设施安危的软件系统。该类软件无疑应当被投以格外的关注、施以有效的方法，为追求“万无一失”而极尽所能。
在这一目标下，基于“高质量的过程产生高质量的产品”这一理念，出现了一系列“以过程为中心”的软件工程方法、标准和实践，广为人知的“能力成熟度模型集成（CMMI）”和本书将要介绍的“民航机载软件适航标准（DO-178）”均属此列。CMMI影响之大不必多说，而DO-178的成熟和成功同样卓著。实际上可以说在近30年间，每个有过飞行经历的人都已在不知不觉中，获得过包含DO-178一份贡献的安全保障。
DO-178是民航领域用于保证机载软件符合飞行安全要求（即“适航性”）的规范性文件，它由美、欧航空组织建立，已成为在全球航空领域（包括中国）得到广泛认可和使用的事实标准。该系列标准起始于20世纪80年代初，最新版本（DO-178C）于2011年12月发布。DO-178C继承了上一版本（DO-178B）的主体，这本身就是对上一版本1992年以来近20年成功运用的最好肯定。新版在概念和结构的清晰性、与系统过程以及新技术发展的协调性方面进行了积极有益的改进，将会进一步提升其实践的效能。
DO-178C在作用和思想上与CMMI（及其衍生的一些类似标准）有一定的可比性，但是也存在很大的实质不同。CMMI最终评判的是一个组织（企业）的“能力”；DO-178C最终评判的是一个产品是否合格。CMMI涵盖工程活动和辅助活动、项目管理、过程管理；DO-178C聚焦于工程及其直接相关的管理活动。此外，即使在二者的交集上，DO-178C的特色也十分突出。CMMI是一个“模型”、“框架”，以抽象原则为主（除了明确的“目标”和“实践”），没有强制特定做法，更不提供系统化的实施途径。这种方式为实践者针对具体情况创造具体方法保留了灵活性，但是也时常令一些实施者和评价者无所适从。与之不同的是，DO-178C从头到脚都极具实践性、操作性，它所规定的每一件事、每一个要求都更直截了当、更清晰明确，此外还尽可能地针对各种可能用到的新技术和特殊技术，给出专门的使用指导和要求。这种方式体现了一个高安全领域对产品近似“刻板”的限定，而事实也雄辩地证明了它的卓越成效。使用DO-178C无论开展研制还是检查，可能会牺牲一些“发挥”的空间，但是更强的可依据性、易判定性也将避免不少疑问与纠结的可能。对于许多正为难以驾驭CMMI而困扰的实践者，DO-178C恰似一份难得的“消化药”和“实战图”，在过程改进的道路上正好可以与CMMI相辅相成，相得益彰。
作为一个行业标准，DO-178C对于航空软件工作者自然是必修与必从的“法典”。但实际上对于其他领域软件而言，DO-178C同样具有宝贵的指导作用。软件工程难题的根源是软件状态空间超大、需求抽象漂移、人为因素交织等内在特征，而与软件应用的领域并无太大关联。DO-178C所针对和解决的各种问题，其实就是软件工程的基本和普遍问题。因此，对外界而言“深山人未知”的DO-178C，作为一套成熟的工程准则和指南，完全可以在更广阔的空间发挥积极作用，尤其是那些具有高安全性要求的领域，无论天上还是地面，无论民用还是军事，无论是否以通过审定为目的。事实上，他山之石，可以攻玉，有机会深入了解一下不同领域的成功经验和不同背景的专家思维，往往可以获得超出预想的裨益。当然这种学习应当是启发式的而不是拘泥不化的，软件工程这门特殊的学科应当格外崇尚向实践学习、向成功学习，同时也应当格外谨记不存在“一只鞋子适合所有的脚”。
本书是在最新版的DO-178C推出之际，给出的一份对该系列规范的全面、深入的解读。本书作者是直接参与DO-178C文件修订的资深专家，以其对标准的把握，来传递标准原本的思想、方法、制定者的观点甚至争议。同时，本书还是作者作为航空软件审定的官方代表和权威专家，以其20年的研发、审定、授课经历，对其积累的宝贵经验的汇聚。这些经验和建议来自实践、用于实践，对于让规范真正发挥实效可谓一语千金。
国际上，软件过程和质量方面的标准早已在关键应用领域中发挥出重要作用。在国内，相关概念、模型、标准的重视和推行也已有相当时日。但是抽象的标准并不能完全传授如何在实际中实施和见效，包括如何有效地进行审查和评价，这也许是过程改进道路上常常遇到的最大困难。从这个意义上，本书将成熟领域中的成熟经验和盘托出，不拒其繁、不舍其微，没有玄奥的理论和华丽的铺陈，却也许正是尤为难得的良师益教。
由于译者的知识不足和时间仓促，翻译中难免有不当或谬误之处，敬请读者原谅和指正。任何意见、建议和探讨都欢迎致信：qualitysoftware@yeah.net。

崔晓峰
2014年5月

前言
我深感重任又忐忑不安地将这本书呈现给您。经过两年的研究和写作，我感到完成的还只是浮光掠影。我希望自己的经验和分享会对您的职业生涯带来帮助。
我很早就热衷于关注安全性及其现实的实现。在高中时代，我为一家本地报纸撰写一个关于安全性小建议的专栏，深入地研究了（作为互联网时代之前的美国乡镇所能做到的极致）：浴盆安全、拖拉机安全、电力安全，以及其他许多方面。在高中最后一年，我参加了州举办的说服性演讲比赛，主题是座椅安全带的安全性。对提高安全性的愿望引领我进入了美国联邦航空局（FAA），这个愿望也是撰写这本书的主要动因。
软件只是整个安全性链条中的一环，然而，它却是一个重要的环节，并且变得越来越关键。随着软件变得更加普及并且以更加关键的方式得到使用，它的风险和对安全性的作用日益增长。与软件相关的安全性增长的同时，许多公司的业务模型似乎也在变化——以少搏多、进度为王，软件工程师被看成如同棋盘上的棋子一样可以摆来摆去。
本书的意图是成为那些在业界奋斗的人们的有益工具。可能您是一位系统工程师或经理、软件经理、软件工程师、质量保证工程师，或者一位努力从他人那里汲取经验的学生。您想要做出色的工作，却被进度和预算的压力拖累。我希望这本书，基于我过去20年在航空工业中的经验，可以在您追求质量和卓越的时候助上一臂之力。

展开

作者简介

本书暂无作者简介

样章试读

查看样章
图书评价我要评论

本书资源

会员上传本书资源

内容简介

图书详情

本书目录

前 言

作者简介

前言