如何定义软件工程
软件工程，是软件开发领域里对工程方法的系统应用。
1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。此后，IEEE多次给出软件工程的定义。
解释导致software crisis本质原因、表现，述说克服软件危机的方法
软件危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个方面：
- 项目运行超出预算。
- 项目运行超过时间。
- 软件质量低落。
- 软件通常不匹配需求。
- 项目无法管理，且代码难以维护
原因：
- 用户需求不明确
- 缺乏正确的理论指导
- 软件开发规模越来越大
- 软件开发复杂度越来越高
克服危机的方法：
- 软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展了许多软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取得良好的效果。
- 在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环境，以求从管理和技术两方面解决软件危机问题。
- 人工智能与软件工程的结合成为80年代末期活跃的研究领域。基于程序变换、自动生成和可重用软件等软件新技术研究也已取得一定的进展，把程序设计自动化的进程向前推进一步。
- 在软件工程理论的指导下，发达国家已经建立起较为完备的软件工业化生产体系，形成了强大的软件生产能力 。软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动，缓解软件危机方面起到了重要作用。
软件生命周期
软件生存周期(SDLC，软件生命周期)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
可行性分析和计划阶段
确定软件开发的总体目标，给出功能、性能、可靠性以及接口等方面的要求，进行可行性分析。
估计可利用的开发资源 (硬件、软件、人力等)、成本、效益、开发进度，进行投资-收益分析，制订开发计划。
提交可行性分析报告、开发计划等文档
需求分析阶段
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
设计阶段
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
- 概要设计/逻辑设计：把各项软件需求转换成软件的体系结构。结构中的每一个组成部分意义明确，并和某些需求相对应。
- 详细设计/物理设计：对按照概要设计分解的每个模块所要完成的工作进行具体的描述，提供源程序代码编写的直接依据。
- 提交概要结构设计说明书、详细设计说明书和测试计划初稿等文档
实现阶段
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
- 完成源程序的编码、编译 (或汇编) 和运行调试，得到没有语法错误的程序清单。程序结构良好、清晰易读，且与设计相一致。
- 编写进度日报、周报和月报 (取决于项目的重要性和规模)。
- 编制测试计划。
- 提交用户手册、操作手册等面向用户的文档。
测试阶段
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
全面测试目标软件系统，并检查审阅已编制的文档，提交测试分析报告。逐项评价所实现的程序、文档以及开发工作本身，提交项目开发总结报告。
运行和维护阶段
软件提交给用户后，在运行使用中得到持续维护，根据用户新提出的需求进行必要而且可能的扩充、删改、更新和升级。
软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行环境变化) 和完善性维护 (增强功能)。
SWEBoK 的 15 个知识域（An Overview of the SWEBOK Guide 请中文翻译其名称与简短说明）
Software Requirements 软件需求
软件需求关注软件需求的启发，协商，分析，规范和验证。 在软件行业中，人们普遍认为，当这些活动表现不佳时，软件工程项目非常容易受到攻击。 软件需求表达了对软件产品的需求和限制，这些需求和约束有助于解决一些现实问题。
Software Design 软件设计
软件设计涵盖了设计过程和最终产品。 软件设计过程是软件工程生命周期活动，其中分析软件需求以产生软件内部结构及其行为的描述，其将作为其构造的基础。 软件设计（结果）必须描述软件体系结构 - 即软件如何分解和组织成组件以及这些组件之间的接口。 它还必须描述能够构建它们的详细程度的组件。
Software Construction 软件构造
软件构建是指通过结合详细设计，编码，单元测试，集成测试，调试和验证来详细创建工作软件。 软件构建包括与满足其要求和设计约束的软件程序开发相关的主题。
Software Testing 软件测试
测试是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动。 软件测试涉及在有限的测试用例集上针对预期行为动态验证程序的行为。
Software Maintenance 软件维护
软件维护包括增强现有功能，调整软件以在新的和修改的操作环境中运行，以及纠正缺陷。 这些类别称为完善，自适应和纠正性软件维护。
Software Configuration Management 软件配置管理
系统的配置是硬件，固件，软件或这些的组合的功能和/或物理特征。 它还可以被视为根据特定构建过程组合的特定版本的硬件，固件或软件项的集合，以满足特定目的。
Software Engineering Management 软件工程管理
软件工程管理涉及规划，协调，测量，报告和控制项目或程序，以确保软件的开发和维护是系统化的，规范化的和量化的。
Software Engineering Process 软件工程过程
软件工程过程关注软件生命周期过程的定义，实施，评估，测量，管理和改进。 涵盖的主题包括流程实施和变更（流程基础架构，流程实施和变更模型以及软件流程管理）; 流程定义（软件生命周期模型和流程，流程定义，流程适应和流程自动化的符号）; 过程评估模型和方法; 测量（过程测量，产品测量，测量技术和测量结果的质量）; 和软件处理工具。
Software Engineering Models and Methods 软件工程模型和方法
软件工程模型和方法解决了涵盖多个生命周期阶段的方法; 其他涵盖特定生命周期阶段的特定方法。 涵盖的主题包括建模（软件工程模型的原理和属性;语法与语义与不变量;前置条件，后置条件和不变量）; 模型类型（信息，结构和行为模型）; 分析（分析正确性，完整性，一致性，质量和相互作用;可追溯性;以及权衡分析）; 和软件开发方法（启发式方法，形式方法，原型方法和敏捷方法）。
Software Quality 软件质量
软件质量是许多SWEBOK V3 KAs中普遍存在的软件生命周期问题。 此外，软件质量KA还包括软件质量的基础知识（软件工程文化，软件质量特性，软件质量的价值和成本以及软件质量改进）; 软件质量管理流程（软件质量保证，验证和确认，审核和审核）; 和实际考虑（缺陷表征，软件质量测量和软件质量工具）。
Software Engineering Professional Practice 软件工程专业实践
软件工程专业实践关注软件工程师必须具备的专业，负责和道德的软件工程知识，技能和态度。
Software Engineering Economics 软件工程经济学
软件工程经济学KA关注的是在业务环境中做出决策，以使技术决策与组织的业务目标保持一致。
Computing Foundations 计算基础
计算基础涵盖了提供软件工程实践所需的计算背景的基础主题。 涵盖的主题包括问题解决技术，抽象，算法和复杂性，编程基础，并行和分布式计算的基础知识，计算机组织，操作系统和网络通信。
Mathematical Foundations 数学基础
数学基础涵盖了提供软件工程实践所必需的数学背景的基础主题。 涵盖的主题包括集合，关系和功能; 基本命题和谓词逻辑; 证明技术; 图形和树木; 离散概率; 语法和有限状态机; 和数论。
Engineering Foundations 工程基础
工程基础涵盖了提供软件工程实践所必需的工程背景的基础主题。 涵盖的主题包括经验方法和实验技术; 统计分析; 测量和指标; 工程设计; 仿真与建模; 和根本原因分析。
简单解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式
- Maturity Level 1 - Initial:无序，自发产生模式
- Maturity Level 2 - Managed:建立基本管理过程，能借鉴已有项目的成功经验。缺点是只能借鉴已有的项目，不够系统，比较被动。
- Maturity Level 3 - Defined:管理过程组织化，项目根据组织的标准进行，主动性增强
- Maturity Level 4 - Quantitatively Managed:量化管理，过程可控，管理操作有理论依据，结果性能可预测
- Maturity Level 5 - Optimizing: 过程的量化反馈和先进的新思想、新技术促使管理过程不断改进。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。
用自己语言简述 SWEBok 或 CMMI （约200字）
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成。SWEBok全名软件工程知识体系，它IEEE计算机协会发布的一个国际标准，它描述普遍接受的知识体系部分，一共提出了15个知识域，对这15个知识域进行了描述与说明。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
