软件工程期末复习知识点

测试分类，过程模型，UML图，软件各个阶段的主要做什么。面向对象。结构化分析方法

一、软件及软件工程（定义 / 概念）

1. 软件的本质

计算机软件：软件是计算机系统中与硬件相互依存的另一部分，包括指计算机系统中的程序、数据及其相关文档的完整集合。

三要素：

程序：按照特定顺序组织的计算机数据和指令的集合。

数据：使程序能正常执行的数据结构

文档：为了便于理解程序所需的与开发、维护和使用有关的资料

软件 = 程序 + 文档 + 数据

软件的特点

1）软件是设计开发的，而不是传统意义上生产制造的。

2）软件不会“磨损”，但会退化。

3）大多数软件还是用户定制的。

软件的特点：

（1）一种逻辑实体，不是物理实体，具有抽象性

（2）软件的生产与硬件不同，它没有明显的制作过程

（3）软件在运行、使用期间不存在磨损、老化问题

（4）软件的开发、运行对计算机系统具有依赖性，受计算机系统的限制，导致软件移植问题

（5）软件复杂性高，成本昂贵

（6）软件开发涉及诸多社会因素

计算机软件可分为七个大类：

1）系统软件

2）应用软件

3）工程/科学软件

4）嵌入式软件

5）人工智能软件

6）产品线软件

7）WebApp

8）移动App

另一种分类

1）系统软件：

位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。

2）支持软件：

支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。

3）应用软件：

特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。

软件危机

软件危机(Software Crisis)（https://zhuanlan.zhihu.com/p/344772007）：计算机软件的开发和维护过程所遇到的一系列严重问题。

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列重问题。这些问题绝不仅仅是不能正常运行的软件才具有的,实际上，乎所有软件都不同程度地存在这些问题。

概括地说,软件危机包含下述两方面的问题:

(1)如何开发软件,以满足对软件日益增长的需求;

(2)如何维护数量不断膨胀的已有软件。

鉴于软件危机的长期性和症状不明显的特征,近年来有人建议把软件危机更名为“软件萧条( depression)”或“软件困扰(affliction)”。不过“软件危机”这个词强调了问题的严重性,而且也已为绝大多数软件工作者所熟悉,所以本书仍将沿用它。

软件危机的表现：

（1）对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算；

（2）无法满足用户需求，导致用户很不满意；

（3）质量很不可靠，经常失效；

（4）难以更改、调试和增强；

（5）没有适当的文档资料；

（6）软件成本比重上升；

（7）软件开发生产率跟不上计算机应用迅速深入的趋势。

软件为什么要更新和迭代？

1）软件必须适应新的计算环境或技术的需要。

2）必须增强软件来实现新的业务需求。

3）软件必须扩展到与其他更现代的系统或数据库进行互操作。

4）必须重新构建软件，使其在网络环境中可行。

为什么会产生软件危机？

（1）与软件本身特点有关

1. 软件不同于硬件，管理和控制软件开发过程相当困难

2. 软件在运行过程中不会因为使用时间过长而被”用坏“如果运行中发现了错误，很可能是遇到了一个在开发时期引入的在测试阶段没能检测出来的错误

3. 软件不同于一般程序，他的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升

（2）软件开发于维护的方法不正确有关

1.只重视程序而忽视软件配置其余成分的糊涂观念。

2.软件开发人员在定义时期没有正确全面地理解用户需求，知道测试阶段或软件交付使用后才发现”已完成的“软件不完全符合用户的需要

3.严重的问题在软件开发的不同阶段进行修改需要付出的代价是很不相同的!

消除软件危机？

1.首先应该对计算机软件有一个正确的认识

2.充分认识到软件开发应该是各类人员协同配合，共同完成的工程项目

3.推广使用在实践中总结出来的开发软件的成功技术和方法，并且研究探索更好的技术和方法。

4.应该开发和使用更好的软件工具

软件工程定义？

软件工程是开发、运行、维护和修复软件的系统方法。也可以说应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、发布和维护的工程或者进行研究的学科。

软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等。

软件工程的内容？

（1）软件工程是一种层次化的技术。任何工程方法必须构建在质量承诺的基础上。

（2）软件工程的基础是过程。软件过程将各个技术层次结合在一起，使得合理及时地开发计算机软件成为可能。

（3）软件工程方法为构建软件提供技术上的解决方法。

（4）软件工程工具为过程和方法提供自动化或半自动化的支持。

软件工程的目标
软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产效率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终使心啊软件的工业化生产。在给定成本、进度的前提下、开发出具有有效性、可靠性、可维护性、可重用性、可适应性、可移植性、可追踪性和可操作性且满足用户需求的产品。

或者是：付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用；开发的软件可靠性高。

追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。

软件工程的原则

选择适宜地开发模型；采用合适的设计方法：提供高质量的工程支持；重视开发过程的管理。

1）抽象
抽取事物最基本的特征和行为，忽略非本质细节
（2）信息隐蔽
（3）模块化
（4）局部化
（5）确定化
（6）一致性
程序内外接口保持一致，系统规格说明与系统行为保持一致
（7）完备性
（8）可验证性
自顶向下，逐层分解

软件生命周期？

软件生命周期， 又称为软件生存周期，是软件从产生直到报废的整个时期。

通常把软件开发生命周期全过程使用的一整套技术的集合称为方法学，也称为范型。软件工程方法学包括三个部分：方法、工具、过程。

软件开发的主要方法？

其用到的方法依据时间的变化主要分为结构化法、面向对象法、面向服务法以及原型法。也有些人把敏捷开发和统一过程（UP/RUP）也称之为软件开发方法。

1、传统方法，又称为生命周期法，或者结构化范型：

即面向过程的开发方法。其基本思想是“自上而下，逐步求精”，把一个复杂的系统拆分，化繁为简，形成一个个的构件。其讲究的是用户至上，系统开发过程工程化、文档化、以及标准化。严格的区分来工作阶段，每个阶段都有明确的任务和应得的成果。

2、面向对象方法：

面向对象的开发方法是自底而上的，主要表现为和现实事物结合起来，把世间万物抽象出来，形成一个个的抽象对象。相比结构化法有更好的复用性，分析、设计、实现三个阶段界限不明确，其关键点在于建立一个全面的、合理的、统一的模型。面向对象方法把数据和行为看成同等重要，他是将数据和对数据的操作紧密结合起来的方法，以为是和传统方法的重要区别。

1. 形式化方法：

形式化方法是一种基于形式化数学变幻的软件开发方法，将系统的规格说明转换为可以执行的程序。特点是软件需求规格说明被细化为用数学极好表达的详细的形式化规格说明；二是设计、实现和单元测试等开发过程由一个变换开发过程替代，通过一些列变换将形式化规格说明细化成为程序。

4、原型法： 其适用于需求不明确的场景，包括抛弃型原型和演变型原型。

抛弃型原型：业务做完之后原型就已经没有用处了；

演变型模型：在原来的模型基础之上逐步修改并一直沿用；

软件工具？

1. 软件工具是指能支持软件开发过程中某一阶段（如系统定义、需求分析、设计、编码、排错和测试等）的需要而使用的软件工具。
2. 支持软件维护过程的工具。主要有版本控制工具、文档分析工具、逆向工程工具。
3. 支持软件管理过程和支持过程的工具。主要有项目管理工具，管理配置工具，软件评价工具。

简述什么是结构换分析方法？该方法使用什么工具？

结构化分析，简称为SA，面向数据流进行数据分析的方法。采用自顶向下逐层分析的分析策略。顶层抽象的描述整个系统，底层具体的画出系统工程的每个细节。中间层则是从抽象到具体的过度。使用的工具数据流图，数据字典作为描述工具，使用结构化语言，判定表，判定书描述加工逻辑。

数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述

数据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。

数据流图符号

• 软件过程及过程模型

软件过程？

一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

软件过程是用于指定、设计、实现和测试软件系统的一系列活动。软件过程模型是过程的抽象表示，它从某些特定的角度对过程进行描述。有许多不同的软件过程，但都涉及:

（1）规格（Specification ）-界定系统应做的工作;

（2）设计及实现（Design and implementation ）-界定系统的组织架构，并实现系统;

（3）验证（Validation ）——检查它是否满足了客户的需求;

（4）进化（Evolution ）-改变系统以响应不断变化的客户需求。

软件过程模型？

也称 软件开发模型 或 软件生存周期模型

是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。

对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，主要根据软件的类型、规模，开发方法、开发环境等多种因素来确定。

软件过程模型有：瀑布模型、原型开发模型（快速原型）、增量模型、螺旋模型、专用过程模型、形式化方法模型

软件过程模型

瀑布模型：瀑布模型也称之为生命周期法，是结构方法中最常用的开发模型，其讲究的是从需求获取到开发到测试到维护像瀑布样顺流而下。

特点是：

1、各个阶段之间具有顺序性和依赖性。必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。

2、推迟实现的观点：瀑布模型在编码之前设置来系统分析和系统设计的各个阶段。分析与设计阶段的任务故一定，在这两个阶段主要考虑目标系统的模型，不涉及软件的物理实现；清楚的区分逻辑设计和物理设计，尽可能的推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。

3、质量保证的特点。每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；每个阶段结束前都要对完成的文档进行评审，以便于及时发现问题，改正错误。

优缺点：

优点是可以强迫开发人员采用规范化的方法；严格的福鼎来每个阶段必须提交的文档；要求每个阶段交出的所有产品必须是经过验证的。

缺点是由于瀑布模型完全依赖于书面的规格说明，很可能导致最终开发出来的软件产品不能真正的满足用户的需要。如果需求规格说明书与用户的需求之间有差异就会出现这种情况。瀑布模型只适用于项目开始时需求已确定的情况。

瀑布模型的变体–V模型：

V模型是以测试驱动的模型，测试贯穿的整个始终。

快速原型模型：快速原型模型是快速建立起来的可以在计算机上运行的程序，他能完成的程序往往是最中产品功能的一个子集。

优缺点：

优点是：原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确的描述用户的需求，从而有助于满足于用户真实的需求，同时在开发过程的后续阶段不会因为需求规格说明文档的错误而进行大的反工；软件产品的开发基本上是按照线性顺序进行的；开发人员通过建立原型系统已经学到很多东西，因此，在设计和编码阶段发生错误的可能性比较小，减少来在后续阶段需要改正前面阶段锁放错误的可能性；原型的用途是获知用户的真实需求，一旦需求确定了，原型可以被抛弃，或者继续在原型的基础上进行开发。

缺点见下表。

增量模型也称为渐增模型 使用增量模型进行开发软件时，把软件产品作为一些勒的增量构件来设计、编码、结成、测试。每个构件由于多个相互作用的模块构成，并且能够完成特定的功能。第一个增量构件往往实现软件的基本需求，提供最核心的功能。第二个增量构件提供更加完善的编辑和文档生成功能；第三个构件实现拼写和语法检查功能，第四个构件完成高级的页面编排功能。将软件产品分解为一些列的增量构件，在增量开发迭代中逐步加入。

优缺点：

优点是可以在较短的时间内向用户提交一些有用的工作产品，从第一个交付日开始，用户就能做一些有用的工作；逐步增加产品的功能可以是用户有比较充裕的时间学习和适应新产品，减少新产品可能给用户、组织带来的冲击；项目失败的风险较低，虽然在某些增量构件种可能遇到一些问题，但其他增量构建爱你能够成功的交付给用户；优先级最高的服务首先交付，然后在将其他增量构件主次继承进来。一个必然的事实是，最重要的系统服务将接受最多的测试。意味着系统最重要的一部分不会遭遇失败。

缺点是见下表

    螺旋模型 该模型将瀑布模型和快速原型模型结合起来，并且加入风险分析。分为四个阶段即：制定计划、风险分析、实施工程以及客户评估。每个阶段的任务是确定该阶段的目标，为了完成这些目标选择方案以及设定这些方案的约束条件。介些来的任务是，从风险角度分析上一部的工作结果，努力排除各种潜在的风险，通常用建造原型的方法来排除风险，如果成功的排除了所有风险，则启动下一开发步骤。以原型为基础，加上瀑布模型重复沿着以上几个步骤进行开发。

优缺点：

优点是对可选方案和约束条件的强调有助于已有软件的崇勇，也有助于把软件质量作为软件开发的一个目标，减少了过多测试或者测试不足带来的风险，在螺旋模型中，维护只是模型的另外一个周期，在这个模型中，开发和维护并没有本质的区别。

缺点是螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风心----当项目实际上走向灾难时，开发人员可能还以为一切正常。

喷泉模型：喷泉模型主要支持面向对象的开发方法，系统某部分常常重复工作多次，相关功能在每次迭代中完善，其主要体现了迭代和无间隙性特征。所谓无间隙指的是在开发活动中，分析、设计、和编码活动之间有所重叠，没有明确的界限。

V模型

瀑布模型图示

快速应用开发RAD是一个增量型的软件开发模型，其强调的是极短的开发周期。是瀑布模型的一个高速变种，通过使用大量的可复用的构件，采用基于构件的方法赢得快速开发。

RAD的流程可分为：

①、业务建模：以什么信息驱动业务过程运作？要生成什么信息？想达到什么效果？可以使用数据流程图来回答上述问题（相当于需求分析，理解需求）；

②、数据建模：为支持业务的数据流找到数据对象集合，定义数据对象属性，并与其他数据对象关系构成数据模型，可以辅以E-R图（相当于创建业务对象，找出对象之间的关系）。

③、过程建模：使数据对象在信息流中完成各业务功能，即细化数据流图中的处理窗（相当于功能模块的实现，比如CRUD等业务）。

④、应用生成：打通各个功能模块的关系，构造出整个应用系统。

⑤、测试与交互。

构件组装模型 构件是系统中模块画的、可不熟的和可替换的构件，该部分封装来实现并暴露系列列接口，构件可以是组织内部开发的，也可以使心啊城的商业成品构件。指的是在整个应用开发的过程中，把各个功能模块抽取出来组成一个个可复用的构件，以便于重复使用，可以极大限度的减少重复劳动、缩短开发周期、降低开发成本、从而是软件开发效率得到提高。类似于积木一样，把整个构件整合起来，形成一个个的应用系统。

形式化方法模型

从广义上讲，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。

狭义的讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。

形式化方法原则上就是用数学与逻辑的方法描述和验证软件。

可以实现从描述到实现的自动转换。

优点：能够开发出无缺陷的软件

缺点：成本高、耗时、对开发人员的技术水平要求高。

统一过程又称为UP、或RUP，是基于构件的。统一过程是一个通用的过程框架，可以用于各种各样的软件项目。

特点：用例驱动、以基本架构为中心、迭代和增量。

基于UP的软件过程是一个迭代的过程，他有四个阶段，分别是：

a、初始阶段：为系统建立业务模型并确定项目的边界；

b、细化阶段：分析问题领域，建立健全的架构基础 。主要是要完成系统的架构。

c、构件阶段：开发剩余的构件和应用程序功能，形成产品并且进行详细的测试

d、交互阶段：主要任务是进行β测试(用户环境，用户做的测试)

过程模型（瀑布模型）和敏捷开发方法的比较？

在互联网企业中往往会有三大技术职位：开发工程师、测试工程师和运维工程师。这三个职位的成员分别负责着一套软件产品从零开始到最终交付的几个阶段工作。围绕着这些工作，也发展出了对应的软件开发模式，从最早的瀑布开发，到后来的敏捷开发，再到当前的DevOps。这些模式分别具有什么样的特点与区别，本文将用最简单易懂的文字为你讲述。

一. 瀑布开发

在软件开发的早期阶段，行业内普遍采用“瀑布模型”的方式进行工作。整个软件开发流程严格遵循需求、设计、开发、测试和部署几个阶段。在这个流程中，需要等上 一个阶段工作完成后，才会进行下个阶段的工作。例如：开发工程师会把需求的代码全部开发好，才给到测试人员进行验证，最后交给运维工程师部署上线。在这种模式下，项目开发的进程由是从一个阶段“流动”到下一个阶段，如同瀑布流水一般，因此被称为瀑布模型（Waterfall Model）。

瀑布模型基于工程学的理念将整个过程分成不同的阶段，提供了软件开发的基本框架，便于人员间的分工协作。同时，也可以对不同阶段的质量和成本进行严格把控。但在这种模式下也存在着一些缺陷，产品迭代的频率经常是以月为单位来进行，更甚者可达半年到一年时间，这导致的风险就是需求无法得到快速验证。

随着互联网行业的快速爆发，软件开发在企业中的地位变得越加重要，软件不再仅仅是为业务提供支持，而是成为业务本身不可或缺的组成部分。与此同时，针对市场的快速变化和响应成了新的目标。

在这种场景下，有可能团队花费数月开发的东西早已经不符合市场的需要，这不仅仅是对人力资源的浪费，也会严重影响企业的发展进程。渐渐地，大家开始发现这种笨重的模式难以适应业务的需要，我们得有一种新的模式来满足需求。

于是，敏捷开发（Agile）开始登上舞台。

二. 敏捷开发（敏捷原则和适合用敏捷开发的软件项目的特征P30）

“敏捷”一词来源于2001年在美国犹他州举行的雪鸟会议，在这次会议上，Martin Fowler，Jim Highsmith等17位著名的软件开发专家提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。敏捷宣言的主要价值观如下：

1、个体和互动高于流程和工具。

2、工作的软件高于详尽的文档。

3、客户合作高于合同谈判。

4、响应变化高于遵循计划。

敏捷意味着效率的提升，相比于传统的瀑布开发，敏捷开发实行的是一种更加快捷的做法。当收集到足够一次迭代开发的需求时，即可以向下一个步骤前进，尽量缩短在每个阶段的停留时间。敏捷的目标在于快速地将需求上线，使其呈现到用户面前，并获取到来自用户的反馈进行功能的迭代。如何理解“敏捷开发”？简单地说，“敏捷开发”是把原有模式下的大需求拆分成多个小需求，并采用小步快跑的方式进行开发与迭代，原来的一个大环改为一个个小的闭环。在新迭代开始前，产品经理会将需求拆分成具体的开发任务，研发人员进行任务认领，每日站会进行任务的review，直到开发完成，发布新的可用版本。

敏捷开发带来的最大效益在于能够更好地贴近市场环境，产品的功能得以根据市场变化快速反应。同时，在敏捷宣言的指引下，强调充分发挥每个人的主动性和创造力，追求有价值的产品结果，这也有利于提升团队的创造力。目前，已有多种基于敏捷开发的方法论，如Scrum、XP（极限编程 extreme programming）等。虽然敏捷开发提升了开发的效率，但它的范围仅限于开发和测试阶段，并没有覆盖到部署端。很显然，运维部门并没有在这其中得到受益，甚至可以说“敏捷”加重了运维的负担。因为运维追求的目标是稳定，而频繁的变更往往就是出现问题的根源，这与敏捷的理念产生了冲突。于是乎，矛盾就在两个团队之间集中爆发了。

当出现问题时，往往会出现运维与开发互相指责的情况，运维认为是开发的代码问题导致，而开发则认为是运维的部署有问题。随着问题的累加，最终的结果是两个部门之间的信任缺失，甚至到了相互防范的地步。很显然，这样的结果并不是我们希望看到的。

那么，要如何才能化解这个矛盾呢？现在，该到了我们Devops上场的时间了。

三. DevOps

一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例， 通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。可以说，DevOps的出现正是为了打破开发和运维人员之间的壁垒，让两者得以更加通畅的沟通，以清除部门间存在的对立。

首先是推行协作的文化，两者之间不再是对立的关系，而应该是互相协作、深度交流并且彼此体谅的状态。而在流程方面，以往开发和运维各搞各的模式也需要进行改变。运维会在项目开发阶段就介入，了解开发所使用的系统架构和技术路线，并制定好相关的运维方案。而开发人员也会参与到后期的系统部署和日常发布中，并提供优化建议，而不再是把代码甩给运维了事。

在这个过程中，不止是基层人员，管理层也需要具备清晰的目标，并且有足够的思想准备及认知。因为这个过程并不轻松，在整个落地过程中往往会面临重重阻力，这种变革需要自上而下的力量进行推动，否则到最后可能不了了之。

另外，DevOps的成功实现也离不开工具的支持。这其中就包括最重要的自动化CI/CD流水线，通过自动化的方式打通软件从构建、测试到部署发布的整个流程，还有包括实时监控、事件管理、配置管理、协作平台等一系统工具的的配合。

近些年的微服务架构理念、容器技术、云计算等使得DevOps的实施变得更加容易，快速开发的产品可以立刻获得更广泛的使用。这也是为什么DevOps早在十几年前就有人提出来,但是，直到这些年才开始受到越来越多的企业重视和实践的原因。

敏捷过程模型

1、极限编程

2、Scrum

3、自适应软件开发（ASD）

4、动态系统开发方法（DSDM）

5、特征驱动开发（FDD）

6、精益软件开发（LSD）

7、敏捷建模AM

8、敏捷统一过程AUP

• 软件需求与结构化分析方法

软件需求：软件需求的基本任务是准确的回答“系统要做什么的问题”深入描述系统的功能需求和性能需求，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。获取用户对软件系统在功能、行为、设计约束等方面的期望。

定义

1、用户解决问题或达到目标所需的条件或权能

2、系统或系统部件要满足合同、标准、规范或其他正式规定文档中所需具有的条件或权能

3、一种反映以上任意一中所描述的条件或权能的文档说明

4、该定义从外部行为、内部特性 阐明需求的定义

需求分析阶段的任务

1. 需求获取：通过启发、引导，从用户那里得到原始需求是他们的业务要求
2. 需求分析：分析上一部获取需求的完整性、正确性、合理性、可行性、充分性
3. 需求定义：将经过需求分析的需求清晰、全面、系统的描述成正式的文档，便携软件需求规格说明书
4. 需求验证：为了确保软件需求规格说明书的准确无误，能为客户理解和接受，需要对其进行严格的评审，需要用户参加，并充分听取用户的意见。

常见的需求分析方法有：

目的：帮助弄清用户对软件的需求

1、结构化分析方法
a.面向数据流的结构化分析方法
b.面向数据结构的结构化数据系统开发方法
c.面向数据结构的Jackson方法

2、面向对象的分析方法
a. 静态分析方法
b.动态分析方法

结构化分析方法

结构化分析方法是结构化程序设计理论在软件需求分析阶段的运用。是使用数据流图（DFD）、数据字典（DD）、结构化英语、判定表和判定树等工具，来简历一种新的、成为结构化规格说明目标的文档。

数据字典？以此条方式定义数据模型，佛你功能模型，行为模型中出现的对象以及控制信息的特性，给出他们的准确定义，包括数据流、加工、数据文件、数据元素以及数据源点和数据汇点。包括在目标系统中使用和生成的所有数据对象。

围绕这个核心有三种图？

数据流图（DFD）？描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能），用于功能建模。

实体关系图（E-R图）？描述数据对象几数据对象之间的关系，用于数据建模。

状态迁移图（STD）？描述系统对于外部事件如何响应，如何动作，用于行为建模。

软件需求规格说明书（需求定义）

系统规格说明书为一个系统或子系统制定需求和制定保证每个需求得到满足所使用的方法，描述一个基于计算机系统的功能和性能，以及哪些将左右系统开发的约束，此文档的编织是为了用户和软件开发者对该软件的出事规定有一个共同的理解，使成为整个开发工作的基础。

软件设计？

软件设计的重要性 ：

（1）软件开发阶段占据软件项目开发总成本的绝大部分，是软件开发中形成质量的关键环节

（2）软件设计是开发阶段的最重要的步骤，是将需求转化成完整的软件产品或系统的唯一途径

（3）软件设计做出的决策，最终影响软件实现的成败

（4）设计是软件工程和软件维护的基础

技术观点看，~包括：

（1）软件结构设计：定义软件系统与各主要部件的关系

（2）数据设计：将分析时创建的模型转化为数据结构的定义

（3）接口设计：描述软件内部、软件和协作系统之间以及软件与人之间如何通信

（4）过程设计：系统结构部件转换成软件的过程性描述

工程管理角度看，~包括

概要设计：

将软件需求转化为软件体系结构、确定系统级接口、全局数据结构或数据库模式

详细设计：

确立每个模块的实现算法和局部数据结构，用适当方法表示算法和数据结构的细节

软件设计的基本原理？

（1）抽象

（2）逐步求精和模块化

（3）信息隐蔽和局部化

（4）信息独立性

软件设计的原则？

（1）分为治之。将大型复杂的问题分解为许多容易解决的小问题。

（2）模块独立性，模块是构成软件的基本构件。

（3）提高抽象层次。忽视一恶搞主题中与当前目标无关的方面，以便更能充分注意与当前目标有关的方面。

（4）复用性设计。复用是指同一事物不做修改或者稍加修改就可以多次重复利用。将复用的思想用于软件开发称软件复用。将软件重用部分称为软构件。

（5）灵活性设计。保证软件灵活性设计的关键是抽象。

结构化设计？

在软件生存周期中，软件设计处于需求分析阶段及软件构造（编码）阶段的中间位置。这一阶段的任务是明确做什么，软件设计将用户需求准确的准确的转换成最终的软件产品的唯一途径，在需求到构造之间起到桥梁作用。结构化设计方法是在模块化、自顶向下逐步细化及结构化程序设计技术基础上发展起来的。可以分为两类：一类是根据系统的数据流进行设计，称为面向数据流的设计，或称为过程驱动的设计；另一类是根据系统的数据结构进行设计，称为面向数据结构设计，或者称为数据驱动的设计。面向数据流的设计工作可以和软件需求分析阶段的结构化分析方法相连接（因为用到数据字典），可以很方便的将用数据流图表示的信息转换成程序结构的设计描述，同时，这一方法还能和编码阶段的“结构化程序设计方法”相适应，称为常用的结构化设计方法。

耦合？

程序结构中各个模块之间相互关联的度量，它取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型。

内聚？

内聚是一个模块内部各个元素之间彼此结合的紧密程度的度量。

概要设计

1.概要设计的任务

（1）设计软件系统结构

（2）数据结构及数据库设计

（3）编写概要设计文档

（4）概要设计文档评审

常用的软件结构设计工具：结构图（structure chart），也称程序结构图

图形说明：

矩形：一般模块

带圈箭头：数据信息

实圈箭头：控制信息

用于描述软件系统的层次和分块结构关系

模块类型：

传入模块

传出模块

变换模块

协调模块

深度：表示控制的层数

上级模块、从属模块

宽度：整体控制跨度

扇入：调用一个给定模块的模块个数

扇出：一个模块直接调用其他模块数

原子模块：树中位于叶子结点的模块

面向数据流的结构化设计方法

（1）数据流类型

变换型

信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心没精加工处理以后再沿输出桐庐变换成外部形式离开软件系统。

工作过程：取得数据、变换数据、输出数据

事务型

存在某种作业数据流，可以引发一个或多个处理，这些处理可以完成该作业要求的功能的数据流称为事务

工作过程：事务中心接收数据，分析每个事务一确定它的类型，根据事务类型选择一条活动通路。

（2）面向数据流设计方法的实施要点

步骤:

分析类型

说明数据流的边界

把数据流图映射成结构图

根据设计准则产生的结构进行细化和求精

设计的准则

（1）提高模块独立性

（2）模块规模适中

（3）深度、宽度、扇出、扇入适当

（4）使模块的作用域在模块的控制域内

（5）应减少模块的接口和界面的复杂性

（6）设计成单入口、单出口的模块

（7）设计功能可预测的模块

详细设计

详细设计的任务是：为软件结构图的每一个模块确定实现算法和局部数据结构，用某种选定的表达工具表示算法和数据结构的细节

常见的过程设计工具有：

图形工具：程序流程图，N-S图。PAD图，HIPO图

表格工具：判定表

语言工具：PDL（伪码）

1.流程图

箭头：控制流

矩形：加工步骤

菱形：逻辑条件

2. N-S图

方框图

3. PAD图

问题分析图（problem analysis diagram）

五种基本控制结构：

顺序型

选择型

WHILE重复型

UNTIL重复型

多分支选择型

4.PDL（procedure decision language）

过程设计语言 也称 结构化英语和伪码

常用词汇：

顺序

条件 IF/THEN/ELSE/ENDIF

循环 DO WHILE/ENDDO

重复 REPEAT UNTIL / ENDREPEAT

分支 CASE_OF/WHEN/SELECT/ENDCASE

面向对象方法与UM图

面向对象=对象+类+继承+消息通信。如果一个系统是使用上述4个概念设计和实现的，则可以认为这个系统是面向对象的，面向对象程序的基本组成单位是类。程序在运行过程时由类生成对象，对象之间通过发送消息进行通信，互相协作完成响应的功能。对象是面向对象程序的核心。

面向对象的四个基本特性是，抽象、封装、继承以及多态。

抽象

    抽象就是忽略关注主题与当前目标无关的信息，以便更关注于与当前目标有关的信息。抽象并不打算了解全部问题，而只关注于主题相关性较大的部分，且暂时不用关注部分细节。 抽象包括两个方面，一是过程抽象，二是数据抽象。过程抽象，关注于目标的功能是什么，而不是功能是怎么实现的。数据抽象，关注于提取目标的特性信息。

 封装

即隐藏对象的属性和实现细节，仅对外公开接口，控制在程序中属性的读和修改的访问级别。封装的优点，良好的封装能够减少耦合；类内部的结构可以自由修改；可以对成员变量进行更精确的控制；隐藏信息，实现细节。

继承

即子类继承父类的特征和行为，使得子类对象（实例）具有父类的实例域和方法，或子类从父类继承方法，使得子类具有父类相同的行为。

多态

即同一个行为具有多个不同表现形式或形态的能力。表现形式为，子类重写父类方法，实现类实现接口方法，子类重写抽象类方法。

UML类图的几种关系。继承、实现、关联、聚合、组合、泛化

软件测试？

软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发个阶段的规格说明和程序的内部结构而精心设计的一批测试用例（及输入数据及其预期的输出结果）并且利用这些测试用例去运行程序，以发现程序错误的过程。

软件测试的目的？

基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，一般希望通过软件测试检验软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试称为表明产品中不存在错误的过程，验证该软件已正确的实现来用户的要求，确立人们对软件质量的信心。

1. 测试是程序的执行过程，目的在于发现错误；
2. 一个好的测试用例在于能发现至今未发现的错误；
3. 一个成功的测试是发现了至今未发现的错误的测试。

总之，设计测试的目标是向以最少的时间和人力系统的找出软件中潜在的各种错误和缺陷。

软件测试与质量保证的区别

质量保证： 质量保证的工作是通过预防、检查和改进来保证软件质量。QA使用“全面质量管理”和“过程改进”的原理开展质量保证工作。所关注的是软件质量的管理与测量。虽然QA活动也有些测试活动，但所关注的主要是软件质量的检查与测量。

软件测试： 测试和质量保证同样都是与软件的开发过程紧密相关，但不同的是其并不关心软件开发过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试活动必须假设软件中存在潜在问题，测试中所有的操作都是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题的分析、追踪与回归测试也是软件测试中的重要工作，所以说软件测试是保证其质量的重要一环。

软件测试的原则

1. 应当把“尽早的和不断的进行软件测试”作为软件开发者的座右铭
2. 测试用例婴幼测试输入数据和与之对应的预期输出结果这两部分组成
3. 尽量避免让程序员测试自己的程序；
4. 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；
5. 充分注意测试中的群集现象；
6. 严格执行测试用例，排除测试的随意性
7. 对每一个测试结果做全面检查
8. 妥善保存测试计划、测试用例、出错统计和最终分析报告，为未来实施的维护提供方便

测试的分类？

白盒测试：已经知道产品内部的工作过程，可以通过测试证明每种内部操作是否是符合设计规格要求，所有内部成份是否已经过检查。

黑盒测试：已经知道产品的功能设计规格，通过测试证明每个实现来的功能是否符合要求。把测试对象看城市一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只一句程序的需求规格说明书，检查程序的功能是否符合他的功能说明。

灰盒测试：是介于白盒测试和黑盒测试之间的一种，灰盒测试多用于集成测试阶段，不仅关注输入、输出的正确性，同时也关注程序内部的情况。

常见的白盒测试：逻辑覆盖、语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖、基本路径覆盖

常见的黑盒测试：等价类划分、边界值分析、阿尔法测试、贝塔测试、发型测试、回归测试

按照开发阶段划分

1、单元测试（Unit Testing）

又称模块测试。对软件的组成单位进行测试，其目的是检验软件基本组成单位的正确性。测试的对象是软件测试的最小单位：模块。【例如：登录测试】

2、集成测试（Integration Testing）

集成测试也称联合测试（联调）、组装测试：将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。【例如：京东购物用微信支付】

3、系统测试（System Testing）

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。

【例如：房子能不能住人（功能） 房子抗不抗台风（性能）；QQ能不能注册，能不能登录，能不能聊天发消息（功能） 人数太多会不会卡顿（性能）】

系统测试如何开展？

需求评审（功能需求、性能需求、接口需求） - 测试计划 - 测试用例 - 用例评审 - 测试环境搭建（平台、架构、web服务器、数据库） - 执行用例 - 提交问题 - 缺陷的跟踪和回归测试 - 测试报告

4、验收测试（Acceptance Testing）

是部署软件前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。向软件购买者展示该软件系统满足原始需求。

实施验收测试的策略有三种：

正式验收测试

非正式验收测试或α测试

β测试