软件工程复习（一）

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主管角色负责维护过程和任务，产品负责人表明利益全部者，开发团队包括了全部开发人员。

      一、客户成为开发团队中的一部分。（例如客户确定对开发的结果然正感兴趣。）

      二、和全部其余形式的敏捷软件过程同样，Scrum有频繁的包含能够工做的功能的中间可交付成果。 这使得客户能够更早的获得能够工做的软件，同时使得项目能够变动项目需求以适应不断变化的需求。

      三、频繁的风险和缓解计划是由开发团队本身制定。– 在每个阶段根据承诺进行风险缓解，监测和管理（风险分析）。

      四、计划和模块开发的透明 – 让每个人知道谁负责什么，以及何时完成。

      五、频繁的进行全部相关人员会议，以跟踪项目进展 – 平衡的（发布，客户，员工，过程）仪表板更新 – 全部相关人员的变动 – 你必须拥有预警机制，例如提早了解可能的延迟或误差。

      六、没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。

      七、在工做场所和工做时间内必须全身心投入。– 完成更多的工做并不意味着须要工做更长时间。