软件工程复习总结

1、1、 软件=程序+数据+文档；2、 软件工程是研究软件开发方法和软件管理方法的一门工程科学。3、 软件工程三要素是软件工程的方法、工具和过程。4、 软件工程的基本原理是：用分阶段的生存周期计划严格管理软件开发，分为计划、分析、设计、编程、测试和运行维护6个阶段。坚持进行阶段评审，上一阶段评审不通过，就不能进入下一阶段开发。实行严格的产品版本控制。采用现代程序设计技术。结果应能清楚地审查。开发小组的成员要少而精。要不断地改进软件工程实践的经验和技术，要与时俱进。二八定律。5、 软件工程中常用的开发方法主要有3种：面向过程的方法，面向对象的方法和面向数据的方法。6、 软件工程的五个面向理论:面向流

2、程分析就是面向流程进行需求分析；面向数据设计，就是面向元数据进行概要设计；面向对象实现，就是面向对象进行详细设计和编程实现；面向功能测试就是面向功能进行单元测试、集成测试、Alpha测试和Beta测试；面向过程管理就是面向过程软件生存周期各个阶段进行管理和控制。7、 瀑布模型的特点：里程碑或基线驱动，或者说文档驱动；过程逆转性很差或者说不可逆转，因为根据上流的错误会在下流进行发散性传播的原理，所以逆转将会延误工期，增加成本，造成重大失误。优点：开发阶段清晰，便于评审、审计、跟踪、管理和控制。缺点：传统的项目组织方法按顺序完成每个工作流程。8、 增量模型的优点：将一个打系统分解为多个小系统，这就

3、等于将一个大风险分解为多个小风险，从而降低了开发难度。缺点：如果软件系统的组装和拆卸性不强，或者开发人员全局把握水平不高，或者客户不同意分阶段提交产品，或者开发人员过剩，则不宜采用这种模式。9、 迭代模式的优点：在迭代之初，它不要求有一个相近的原型，而且适用范围广，几乎适用于所有的项目开发。缺点：传统的项目组织方法按顺序完成每个工作流程，即瀑布式生存周期。10、 原型模型的优点：开发速度快，用户意见反馈实时，有利于开发商在短时间内推广并实施多个用户。缺点：因为事先有一个展示型的产品原型，所以在一定程度上不利于开发人员的创新。11、 非订单软件：软件公司在人力资源、设备资源、抵抗风险、资金和时间

4、上都具备开发该产品的能力，于是决定立项，这类软件产品被称为“非订单软件”。与固定的用户签订软件开发合同，由软件公司启动该项目的开发，这类软件被称为“订单软件”。12、 需求分析的重要性：许多大型应用系统的失败，最后均归结到需求分析失败；需求分析的输出文档是用户需求报告，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据；需求分析要占用整个软件开发时间或工作量的30%左右；需求获取中的错误属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播

5、。13、 基线：基线是软件工作产品，它是经内部和外部评审过的，并且是下一阶段工作的基础。一根基线是一个里程碑或一个检查点。14、 检查点只是由时间、计划、事件驱动的检查工作进度和和质量的一个记号。一个检查点不一定是一根基线或一个里程碑。15、 里程碑是一个标记，只需要经过内部评审。一个里程碑是一个检查点，但不一定是基线。16、 评审是对软件工作产品质量的一次开会或汇签活动。17、 审计是复查评审活动程序的合法性，是否按程序与规范进行。18、 需求分析的目的是用于说明软件产品或软件项目需求满足的条件和限制。重点是通过弄清业务流程和数据流程的手段，达到与客户共同确定业务模型、功能模型、性能模型、接

6、口模型的目标。难点是在系统的功能、性能和接口方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。19、 同行评审是软件工作产品验证的活动，其目的是为了及早和高效地从软件产品中识别并消除缺陷。20、 需求分析的描述工具有数据流程图、实体联系模型、用例图、活动图21、 软件策划的步骤：估计软件工作产品德规模、工作量、费用及所需的资源（软件工作产品，包括需求规格说明书，概要设计说明书，详细设计说明书，源代码，测试计划和测试报告，质量保证计划，软件配置管理计划，里程碑及评审点计划。）指定时间表（包括开发进度时间表和管理进度时间表：软件开发计划、质量保证计划、

7、软件配置管理计划、测试计划、评审计划）。鉴别和评估风险（政策风险、资源风险、市场突变风险、技术风险和技能风险）。与相关的组或人协商策划中的有关约定（策划的结果要实事求，要得到各有关方面的同意和认可）。22、 软件评估是指对软件项目进行量化估计，并记录估计结果的过程。软件估计是软件策划的核心，是软件策划的重点和难点。23、 到目前为止，在IT企业常用的软件项目规模估计方法有希腊古都法(适用于没有历史数据的情况下)、类比法（适用于评估一些与历史项目在应用领域、环境和复杂度的相识项目）、功能点估计法（适用于在需求分析阶段基于系统功能的一种规模估计方法）、无礼估计法（适用于对各个项目活动时间的完成时间

8、的估计）。24、 概要设计说明书与详细设计说明书的区别：概要设计说明书一是要覆盖需求规格说明书的全部内容，二是要作为指导详细设计的依据。因此，它注重于框架上的设计，包括软件系统的总体结构设计、全局数据库（包括数据结构）设计、外部接口设计、功能部件设计、部件之间的内部接口设计，它要覆盖需求规格说明书中的功能点列表、性能点列表、接口列表。若为C/S或B/A/S结构设计，则要说明部件运行在网络中的哪一个节点上。详细设计说明书一是要覆盖概要设计说明书的全部内容，二是要作为指导程序设计的依据。因此，它注重于微观上和框架内的设计，包括各子系统的公用部件实现设计、专用部件实现设计、存储过程是实现设计、触发实

9、现设计、外部接口实现设计、部门角色授权设计、其他详细设计等。在一般情况下，概要设计说明书有系统设计师负责，详细设计说明书则由高级程序员负责。25、 耦合定义了模块之间关系的紧密程度，内聚定义了组成模块的内部元素之间关系的紧密程度。耦合成度由低到高的分级如下：数据耦合（或参数传递耦合）：属于低级耦合。例如，模块组件通过参数传递或数据结构来访问。控制耦合：属于中级耦合。例如，操作系统中的进程调度程序，通过就绪进程的优先级来调度进程进行，那么调度程序与进程之间的耦合就是控制耦合。外部耦合(或公用耦合)：属于高级耦合。例如，模块间共享全局变量或共享访问全局数据区中的数据项，就是公用耦合。内容耦合：属于

10、最高级别耦合。例如，一个模块利用分支或跳转技术转入到另一个模块中去执行，就是内容耦合。26、 软件构架应描述以下问题：软件系统中包含那些子系统和部件；每个子系统和部件都完成哪些功能；子系统和部件对外提供或使用外部的哪些接口；子系统和部件间的依赖关系，以及对实现和测试的影响；系统是如何部署的。软件构架不包括硬件、网络以及物理平台的设计。软件构架只描述创建软件所需要的各种环境，而不是详细描述整个系统。27、 面向过程详细设计的描述工具：流程图、N-S图、程序设计语言和决策表。28、 OOA模型采用分层次结构，它们分别是：对象-类层：表达待开发系统及其环境信息的基本构造单位，标出反映问题域的对象和类

11、，并用符号进行规范的描述，以信息提供者熟悉的术语为对象和类命名。属性层：定义对象和某些结构中的数据单元，继承结构中所有类的公共属性可放于通用类中。标识对象必需的属性并放在合适的继承层次上，实例连接关系和属性的特殊限制也应标识出来。服务层：表示对象的服务或行为，即定义类上的操作，列出对象需要什么（即方法），也给出对象间的消息连接（并应以箭头指示消息从发送者到接收者）。消息系列用执行线程来表达，服务用类似流程图的方式表达。结构层：识别现实世界中对象之间的关系。当一个对象是另一个对象的一部分时，用“整体-部分”关系表示；当一个类属于另一个类时，用类之间的继承关系表示。主体层：用于管理大系统的一个方法

12、。这里所说的“主题”可以看成是子模型或子系统，可将相关类或对象分别归类到各个主题中，并给予标号和名称。29、 OOD体系结构的4个部件内容：问题论域部分：设计构造一组为底层应用建立模型的类和对象，细化分析结果。人机交互部分：设计一组有关类接口视图的用户模型的类和对象，设计用户界面。任务管理部分：确定系统资源的分配，设计用于系统中类的行为控制的对象/类。数据管理部分：确定持久对象的存储，将对象转换成数据库记录或表格。30、 业务模型的描述方法：组织结构图、岗位（或角色）职能表、业务流程图加上业务规则说明。在UML中，完整的业务模型由用例图、时序图、交互图、状态图、活动图来表述，但是时序图在表述中

13、起到核心作用。31、 功能模型在需求分析时的表示方法有：系统功能需求列表、性能需求列表、接口需求列表、界面需求列表。UML规定采用用例图来描述功能模型。32、 UML中有3中基本构造块：事物、关系和图。UML中有4种事物：结构事物（是UML模型中的静态元素，包括类、接口、协作、用况、主动类、构件和节点）、行为事物（是UML模型中的动态元素，包括交互和状态机）、分组事物（是UML模型中的组织元素，主要是包，用一个包含名称的左上角带有一个小矩形的大矩形表示）和注释事物（是UML模型中的解释元素，主要是注解，用一个包含注解内容的右上角为折角的矩形表示）。33、 构件就是被标识的且可被复用的软件制品。

14、它的三个特点是：构件要被明确标识，即有一个被调用的名字；构件应该可复用，不可复用的只能称为模块或子系统；构件是软件制品。34、 程序设计风格的内容包括：规范化的程序内部文档、数据结构的详细说明、清晰的语句层次结构、遵守某一编程规范。编程规范的内容包括：命名规范、界面规范、提示及帮助信息规范、热键定义规范等。需求分析概要设计软件实现按原则：（1）尽可能简单（在软件实现过程中，应创建简单、易读的代码。相同功能的代码只写一次。）（2）易于验证(无论是在编码、测试还是实际操作中，软件工程师应很容易地发现其中的错误。自动化的单元测试可帮助产生易于验证的代码。)(3) 适应变化。(外部环境、软件需求和软件

15、设计，在整个开发过程中可能会随时变化，因此要求软件实现时考虑适应这些变化。)（4）遵守某一编程规范。（5）选择项目组成员最熟悉的工具或语言。总之，软件实现工具或语言不是越时髦越好，而是越成熟与越熟练越好，这样可以避免技术风险和技能风险。35、 代码重构是软件进化的重要手段，Martin Fowler将重构定义为“对软件内部结构的修改，使之更易于理解和修改，但不改变软件的对外可见的行为”。36、 “不符合项”与bug的异同：（1）同:它们都说明软件有缺陷；（2）异：它们指出的缺陷范围有所区别：“不符合项”所指出的缺陷范围广一些，抽象一些，如某一项（或性能）没有达到用户需求报告中的标准；bug所指

16、出的缺陷范围小一些，准确一些，如某个程序块中有某个bug以及该bug出现的条件、形式与环境。一般而言，“不符合项”偏重于对应用软件的评测，bug偏重于对系统软件的评测，“不符合项”包括bug，bug是“不符合项”中的一种表现形式。验收测试需求分析37、 系统测试概要设计集成测试详细设计单元测试编码软件测试V模型V模型的测试思想：左侧是开发阶段，右侧是测试阶段。开发阶段先从定义软件需求开始，然后要把这些需求不断地转换到概要设计和详细设计中去，最后形成程序代码。测试阶段是在代码编写完成以后，先做单元测试开始，然后是集成测试。系统测试和验收测试。V模型的重大贡献是提高了软件测试的地位，它将软件测试工

17、作作为软件工程中一个与开发过程同样重要的过程（V字母的两侧是平等的）。但是V模型没有体现出定义和设计阶段与尽早发现软件缺陷。我们需要对V模型进行改进，一是加入软件测试的定义和设计阶段，二是体现“尽早”的思想，改进后的V模型就形成了一个没有软件开发过程的。左边是软件测试的需求定义和设计阶段，右边是软件测试的执行阶段，测试执行阶段要在软件编码阶段之后，但是测试需求定义和设计阶段可以提前，提前到与开发阶段并行开展。按照改进后的V模型开展测试工作，才能实现软件测试的目标，真正发挥软件测试的作用。验收测试测试需求分析 系统测试系统测试设计集成测试集成测试设计详细设计单元测试编写测试用例编码改进后的软件测

18、试V模型38、 黑盒测试：又叫功能测试。盒子指的是被测试的软件，“黑盒”就是只知道被测软件的外部情况，主要是界面和接口，被测软件的内部逻辑结构和数据结构，对测试人员是不可见的。黑盒测试主要检查以下错误：功能不正确或者被遗漏;界面错误;数据结构或者外部数据库访问错误;性能错误;初始化或者终止错误.黑盒测试技术： 等价分类法；边界值分析法；错误推测法。39、 白盒测试：测试人员进行白盒测试之前，必须清楚软件的内部逻辑结构和执行路径，然后根据它们展开测试的。 原则：保证模块中每一个独立的路径至少执行一次。保证所有判断的每一个分支至少执行一次。保证每一个循环都在边界条件和一般条件下至少执行一次。验证所

19、有内部数据结构的有效性。白盒测试方法：逻辑覆盖测试（它以程序的内部逻辑结构为基础, 设计测试用例。语句覆盖；判定覆盖；条件覆盖；判定-条件覆盖；条件组合覆盖等）；循环测试；基本路径测试。40、 回归测试：在软件发生修改之后，重新执行原有已经执行过的测试用例，以保证修改的正确性，为此目的开展的测试工作称为回归测试。41、 Alpha测试：有开发人员或者测试人员在场，客户在开发环境下使用软件，也称为受控测试。42、 Beta测试：所谓Beta测试，就是将软件的Beta版本交给大量典型客户（通常是让客户通过网络自由下载），由他们从客户的角度出发，在实际环境中使用软件（没有开发人员和测试人员做指导）。

20、43、 软件产品：不局限于特定业务领域，能被广大用户直接使用的软件系统。如：操作系统，编译系统、工具系统，通用财务系统等。软件项目：对特定业务领域、需要提供业务流程重组与优化的软件系统。如：MIS、ERP、电子商务、自动跟踪控制系统等。软件项目的专用性强，通用性差，业务领域知识所占比重大，工程性强。44、 “客户化”与“”初始化“的区别：客户化是指按照客户的实际需求，对软件产品的功能、性能、接口做适当的改动。初始化是指按照客户的实际情况，对软件产品的代码表(又称数据字典)进行初始化，即：将客户的各种信息编码录入到相应的代码表中，如单位代码、部门代码、物资代码、设备代码、商品代码、科目代码等。

21、初始化工作简单，客户化工作复杂。客户化包括初始化工作。初始化工作只是客户化工作中的一小部分。45、 软件维护：指软件项目或产品在安装、运行并交付给用户使用后，在新版升级之前的这段时间里，软件厂商向客户提供的服务工作。46、 软件维护的分类：纠错性维护（产品或项目中存在缺陷或错误，在测试和验收时未发现，到了使用过程中逐渐暴露出来，需要改正）；适用性维护（这类维护是为了产品或项目适应变化了的硬件、系统软件的运行环境，如系统升级）；完善性维护（为了给软件系统增加一些新的功能，是产品或项目的功能更加完善与合理，又不至于对系统进行伤筋动骨的改造，这类维护占维护活动的大部分。）；预防性维护（为了提高产品或项目的可靠性和可维护性，有利于系统的进一步改造或升级换代）。47、 软件生存周期是从某软件产品开始研发到软件不再使用为止的时间间隔。软件生存周期一般包括：需求阶段、概念阶段、设计阶段、实现阶段、测试阶段、安装和调整阶段、运行和维护阶段，有时还包括退役阶段。48、 CMM的初