软件工程复习笔记

软件工程

软件工程概述

软件危机

是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象

软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件生命周期

软件的产生直到报废或停止使用的生命周期

软件开发主要分为以下几个阶段

  1. 问题定义
    确定好要解决的问题是什么（what），通过对客户的访问调查，系统分析员扼要的写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
  2. 可行性研究
    确定该问题是否存在一个可以解决的方案。这个阶段的任务不是具体解决问题，而是研究问题的范围，套索这个问题是否值得去解决，是否有可行的解决办法。可行性研究的结果是客户做出是否继续进行这项工程的决定的重要依据，一般来说，只有投资可能取得较大的效益的那些工程项目才值得继续进行下去。
  3. 需求分析
    深入具体的了解用户的需求，在所开发的系统要做什么这个问题上和用户想法完全一致。明确目标系统必须做什么，确定目标系统必须具备哪些功能。通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。用《规格说明书》记录对目标系统的需求。
  4. 概要设计（总体设计）
    概括的说，应该怎样实现目标系统，设计出实现目标系统的几种可能方案，设计程序的体系结构，也就是确定程序由哪些模块组成以及模块之间的关系。
  5. 详细设计
    实现系统的具体工作，编写详细规格说明，程序员可以根据它们写出实际的程序代码。详细设计也称模块设计，在这个阶段将详细的设计每个模块，确定实现模块功能所需的算法和数据结构。
  6. 编码和单元测试（编码占全部开发工作量的10%-20%）
  7. 综合测试（测试占全部开发工作量的40%-50%）
    分为集成测试和验收测试。
  8. 软件维护
    在这里插入图片描述

瀑布模型特点

瀑布模型有以下优点

  1. 为项目提供了按阶段划分的检查点。
  2. 当前一阶段完成后，您只需要去关注后续阶段。
  3. 可在迭代模型中应用瀑布模型。
    增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
  4. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型有以下缺点

  1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
  2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
  3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
  4. 瀑布模型的突出缺点是不适应用户需求的变化。

快速原型模型特点

原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。
快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
这种模型适合预先不能确切定义需求的软件系统的开发。

缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
　　显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
快速原型模型有点整合“边做边改”与“瀑布模型”优点的意味。

增量模型特点

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点，增量模型具有以下优点。

  1. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
  2. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
  3. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

增量模型的缺点是要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。
增量模型适用于具有以下特征的软件开发项目：

  1. 软件产品可以分批次地进行交付。
  2. 待开发的软件系统能够被模块化。
  3. 软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。
  4. 项目管理人员把握全局的水平较高。

迭代模型特点

早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型（stagewise model）”。迭代模型是RUP推荐的周期模型。被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
在现代过程方法XP（eXtreme Programming，极限编程）、RUP无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点，在发现那么多采用了瀑布模型的失败的项目之后，不但放弃了对它的要求，而且从1994年的报告开始，积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时，中国中科院也提倡选用迭代模型。
与瀑布模型不同，不再强调开发工作的序列化过程，而是将这些过程并行化，分为多个阶段，每个阶段都包含这些工作，只是不同阶段，不同的比例。
优点
与传统的瀑布模型相比较，迭代过程具有以下优点：

  1. 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
  2. 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
  3. 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
  4. 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

需求分析

数据流图

数据流图是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。在结构化开发方法中，数据流图是需求分析阶段产生的结果。

数据字典

数据流图描写叙述了系统的分解。但没有对图中各成分进行说明。数据字典是对数据流图中出现的全部被命名的图形元素在数据字典中作为一个词条加以定义，使每一个图形元素的名称都有一个确切的解释。

需求分析的重要性分析

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

总体设计

软件模块化的基本思想

在设计较复杂的程序时，一般采用自顶向下的方法，将问题划分为几个部分，各个部分再进行细化，直到分解为较好解决问题为止。模块化设计，简单地说就是程序的编写不是一开始就逐条录入计算机语句和指令，而是首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来，并定义和调试好各个框架之间的输入、输出链接关系逐步求精的结果是得到一系列以功能块为单位的算法描述。以功能块为单位进行程序设计，实现其求解算法的方法称为模块化。模块化的目的是为了降低程序复杂度，使程序设计、调试和维护等操作简单化。
利用函数，不仅可以实现程序的模块化，使得程序设计更加简单和直观，从而提高了程序的易读性和可维护性，而且还可以把程序中经常用到的一些计算或操作编写成通用函数，以供随时调用。

HIPO图

是表示软件结构的一种图形工具，以模块分解的层次性以及模块内部输入、处理、输出三大基本部分为基础建立的。
点击链接

内聚

是一个模块内部各成分之间相关联程度的度量

  1. 功能内聚 模块的所有成分对于完成单一的功能都是必须的，则称为功能内聚
  2. 通信内聚 如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚。
  3. 逻辑内聚 几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。
  4. 偶然内聚 如果一个模块的各成分之间毫无关系，则称为偶然内聚，也就是说模块完成一组任务，这些任务之间的关系松散，实际上没有什么联系。

耦合

软件工程中对象之间的耦合度就是对象之间的依赖性

  1. 数据耦合 模块之间通过参数来传递数据，那么被称为数据耦合。数据耦合是最低的一种耦合形式，系统中一般都存在这种类型的耦合，因为为了完成一些有意义的功能，往往需要将某些模块的输出数据作为另一些模块的输入数据。
  2. 特征耦合 两个都与同一个数据结构有关的模块发生的耦合。由于同时使用同一个数据结构，当数据结构变动时,必然影响这两个模块,从而增加模块间的依赖性，降低模块独立性。在设计模块结构时,应当尽量将数据结构传递修改为数据传递,从而将特征耦合变为数据耦合,降低耦合度。
  3. 控制耦合 一个模块通过接口向另一个模块传递一个控制信号，接受信号的模块根据信号值而进行适当的动作，这种耦合被称为控制耦合。
  4. 公共耦合 两个或两个以上的模块共同引用一个全局数据项，这种耦合被称为公共耦合。在具有大量公共耦合的结构中，确定究竟是哪个模块给全局变量赋了一个特定的值是十分困难的。
  5. 内容耦合 当一个模块直接修改或操作另一个模块的数据时，或一个模块不通过正常入口而转入另一个模块时，这样的耦合被称为内容耦合。内容耦合是最高程度的耦合，应该避免使用之。

详细设计

https://blog.csdn.net/chs007chs/article/details/78366663

程序流程图

是用统一规定的标准符号描述程序运行具体步骤的图形表示。程序框图的设计是在处理流程图的基础上，通过对输入输出数据和处理过程的详细分析，将计算机的主要运行步骤和内容标识出来。程序框图是进行程序设计的最基本依据，因此它的质量直接关系到程序设计的质量。

PAD图

它是日本日立公司提出，由程序流程图演化来的，用结构化程序设计思想表现程序逻辑结构的图形工具。

面向对象软件工程

面向对象的优点

  1. 易维护
    采用面向对象思想设计的结构，可读性高，由于继承的存在，即使改变需求，那么维护也只是在局部模块，所以维护起来是非常方便和较低成本的。
  2. 质量高
    在设计时，可重用现有的，在以前的项目的领域中已被测试过的类使系统满足业务需求并具有较高的质量。
  3. 效率高
    在软件开发时，根据设计的需要对现实世界的事物进行抽象，产生类。使用这样的方法解决问题，接近于日常生活和自然的思考方式，势必提高软件开发的效率和质量。
  4. 易扩展
    由于继承、封装、多态的特性，自然设计出高内聚、低耦合的系统结构，使得系统更灵活、更容易扩展，而且成本较低。

面向过程的区别

面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。
面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。

用例模型

用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

类图绘制

https://blog.csdn.net/u013870094/article/details/78826614

类间的各种关系及UML表示

https://blog.csdn.net/qq_28379809/article/details/79499577

活动图绘制

https://blog.csdn.net/anyue0205/article/details/72604790

软件测试

黑盒测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。

语句覆盖

就是针对代码语句的嘛。它的含义是我们设计出来的测试用例要保证程序中的每一个语句至少被执行一次。通常语句覆盖被认为是“最弱的覆盖”，原因是它仅仅考虑对代码中的执行语句进行覆盖而没有考虑各种条件和分支，因此在实际运用中语句覆盖很难发现代码中的问题。

判定覆盖

判定覆盖也被成为分支覆盖(Branch Coverage)，也就是说设计的测试用例要保证让被测试程序中的每一个分支都至少执行一次。

条件覆盖

条件覆盖于分支覆盖不同，条件覆盖要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值、有一次假值。

判定条件覆盖

判定条件覆盖，说白了就是我们设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次（条件覆盖），同时每个判断本身所有的结果也要至少执行一次（判定覆盖）。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖，弥补了两者各自的不足，但是判定条件覆盖并未考虑条件的组合情况。

条件组合覆盖

意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。

Alpha测试

一般来说 alphatest 测试是在公司内部组织进行的面向于部分职工的，自愿参与的产品试用。其主要目的就是以最终用户的视角去发现产品的设计缺陷和功能的不足，发现问题后，测试者可以提交BUG（硬件，软件，结构，外观方面） 给开发部门和质量部门以确保产品在最终上市前达到比较理想的状态。此测试在正规的手机研发公司和游戏开发公司中有着较为广泛的开展，也是新产品引入流程中重要的一环。

posted @ 2019-03-21 14:59  赫凯  阅读(84)  评论(0)    收藏  举报