1. 软件危机产生的原因
是在软件开发和维护过程中所遭遇的一系列严重问题，导致开发延期甚至无法交付、成本激增或者软件运行质量事故、软件无法维护等。原因是软件不再只是程序，人机交互、实时系统、业务系统等软件规模越来越大，软件复杂度也越来越高，应用范围也逐渐增大。
2. 用例图，活动图，数据流程图
用例图：描述系统的功能，展现了一组用例、用户以及他们间的关系，即从用户角度描述系统功能，用于收集用户实际需求。
活动图：描述业务用例实现的工作流程。包含： 活动状态图、动作状态、动作状态约束、动作流、开始节点、终止节点、对象、数据存储对象、对象流、分支与合并、分叉与汇合、异常处理、活动中断区域、泳道。
数据流程图：数据流程图（Data Flow Diagram,DFD ），是描述系统数据流程的工具，它将数据独立抽象出来，通过图形方式描述信息的来龙去脉和实际流程。数据流程图的基本成分，系统部件包括系统的外部实体、处理过程、数据存储和系统中的数据流四个组成部分。
3. 白盒测试（2种：静态测试、动态测试）， 黑盒测试。
白盒测试方法（White-box Testing），也称结构测试或逻辑驱动测试。白盒测试方法是根据模块内部结构了解，基于内部逻辑结构，针对程序语句、路径、变量状态等来进行测试，检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确的工作。白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
静态测试就是静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行。静态测试采用人工检测和计算机辅助静态分析手段进行检测。
动态测试是通过观察代码运行时的动作，来提供执行跟踪、时间分析，以及测试覆盖度方面的信息。动态测试通过真正运行程序发现错误。通过有效的测试用例，对应的输入/输出关系来分析被测程序的运行情况。
黑盒测试方法（Blake-box Testing），是把程序看作一个不能打开的黑盒子，不考虑程序内部结构和内部特性，而是考察数据的输入、条件限制和数据输出，完成测试
4. 驱动程序和桩程序
驱动程序（driver）：对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块。
程序（stub）: 对顶出或者上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。
5. 容错测试
软件测试包括： 集成测试、功能测试、非功能测试（负载测试，容量测试，性能测试，安全性测试，容错测试，兼容性测试，可靠性测试）和验收测试。
容错测试是一种非功能测试，主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
容错性测试是检查软件在异常条件下的行为。容错性好的软件能确保系统不发生无法意料的事故。
6. 数据词典
数据字典（Data dictionary）是一种用户可以访问的记录数据库和应用程序源数据的目录。主动数据字典是指在对数据库或应用程序结构进行修改时，其内容可以由DBMS自动更新的数据字典。被动数据字典是指修改时必须手工更新其内容的数据字典。
7. 内聚
内聚有： 功能内聚性（最高）、顺序内聚性（较高）、通讯内聚性（中）、临时内聚性（低）
8. 软件工程概念的起源
软件工程是1968年北大西洋公约组织（NATO）的计算机科学家在联邦德国召开国际会议，讨论软件危机问题，正式提出了“软件工程”。
9. 管理模型： RUP全过程管理， 瀑布， scrum模型。
RUP全过程管理模型 ：Rational Unified Process 是一种软件过程，它提供了在开发组织中分配任务和职责的严格方法，综合了许多现代软件开发的最佳实践（包括迭代开发、需求管理、基于构件的体系结构、可视化建模、验证软件质量和控制软件的变更），以一种可剪裁、可操作、详尽和实用的方式为软件项目提供过程指导，以帮助开发人员在预定的进度和预算范围内开发出符合用户需求的高质量软件系统。Rup的完整框架可以用一个二维结构来表示。其中，横轴代表时间，刻画了过程的时间因素和生命周期，体现了过程的动态结构，可以用周期、阶段、迭代和里程碑等术语来表示；纵轴代表核心过程规程，体现了过程的静态结构，可以用活动、规程、角色和工作流等术语来表示。特别适用于大型软件团队开发大项目。
瀑布模型：1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的 固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如下图所示：
优点：
1）为项目提供了按阶段划分的检查点。
2） 当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
缺点：
1） 在项目各个阶段之间极少有反馈。
2） 只有在项目生命周期的后期才能看到结果。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下 落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此， 如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。
Scrum模型： 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
1、客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣。）
2、和所有其他形式的敏捷软件过程一样，Scrum有频繁的包含可以工作的功能的中间可交付成果。 这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更项目需求以适应不断变化的需求。
3、频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解，监测和管理（风险分析）。
4、计划和模块开发的透明 – 让每一个人知道谁负责什么，以及什么时候完成。
5、频繁的进行所有相关人员会议，以跟踪项目进展 – 平衡的（发布，客户，员工，过程）仪表板更新 – 所有相关人员的变更 – 你必须拥有预警机制，例如提前了解可能的延迟或偏差。
6、没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。
7、在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
