软件工程重点归纳Word格式.docx

软件工程重点归纳Word格式.docx

《软件工程重点归纳Word格式.docx》由会员分享，可在线阅读，更多相关《软件工程重点归纳Word格式.docx（13页珍藏版）》请在冰豆网上搜索。

（9）使用和维护

（10）退役

需求分析的定义:

需求分析用于确定用户对待开发软件系统的需求，包括：

软件的功能、软件的性能和软件的运行环境约束。

典型的软件开发过程模型的特点（优缺点）及要求：

1、★瀑布模型：

（P35）

特点：

一个开发阶段必须在另一个开发阶段开始之前完成，它从一种非常高层的角度描述了开发过程中进行的活动，并且提出了要求开发人员经过的事件序列。

优点：

有助于帮助开发人员布置他们需要做的工作，它的简单性使得开发人员很容易向不熟悉软件开发的客户做出解释。

它明确说明，为了开始下一阶段的开发，哪些中间产品是必需的。

缺点：

1、最大的问题是不能反映实际的代码开发方式。

2、在系统开发之上强加了一种项目管理结构。

3、对于处理开发过程中可能出现的产品和活动变化，没有提供相关指导。

4、没有把软件开发看作一个问题求解的过程。

5、没有说明创建最终产品过程中所需的往返活动的任何特有信息。

2、V模型

特点：

V模型是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。

编码在顶点，分析和设计在左边，测试和维护在右边。

V模型关注的是活动和正确性。

使得隐藏在瀑布模型中的迭代和重做活动更加明确。

3、★原型化模型（P37）

特点：

原型化模型允许开发人员快速构造整个系统或系统的一

部分以理解和澄清问题。

它需要对需求或设计进行反复调查以确保开发人员、用户和客户对需要什么和提交什么有一个共同理解。

优点：

1、有助于开发人员评价可选的设计策略以及决定对于特定项目哪一种策略是最好的；

2、对于验证和确认很有用。

3、减少开发中的风险和不确定性；

缺点：

1、为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。

2、为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。

3、开发过程不便于管理。

分类：

探索型原型、实验型原型和演化型。

4、★增量和迭代（P39）

增量开发：

需求文档中指定的系统按功能划分为子系统，每次新的发布增加新功能。

迭代开发：

一开始提交完整系统，提供基本功能，每次新的发布对功能进行完善。

增量和迭代：

2种结合起来。

系统其余部分还在开发的同时，用户已经获得了一部分功能，产品系统和开发系统并行运行。

1、缩短循环周期，使系统可以一部分一部分交付；

2、开发人员能够通过观察某些功能如何执行，从而很好对用户的反馈做出反应；

3、可以及早为那些以前从未提供的功能开拓市场；

4、经常性发布能够全面快速修复运行系统出现的问题；

5、针对不同版本，开发团队可以将重点放在不同的专业领域技术上。

极限编程的特点：

交流:

保持客户和开发者的交换看法

简单性:

选择简单设计和实现

勇气:

尽早并经常性交付功能（敢于承诺并信守诺言）

反馈:

开发过程中各种活动循环

第三章

了解项目计划和管理的主要内容和常用的方法。

主要内容：

1、跟踪项目进展：

A工作分解和活动图说明要干什么

B估算完成时间（用到了CPM即关键路径法、CPM条状图）

C跟踪进展的工具：

对项目进展进行跟踪（甘特图）

2、项目人员：

需要多少人、执行什么任务、需要什么能力经验

A人员角色和特性

B工作风格

C项目组织（主程序员负责制组、忘我方法）

3、工作量估算：

尽早了解项目可能成本

A专家判断：

依赖个人经验和能力，比如比较2个系统

B算法方法：

表示工作量和影响工作量因素之间的计算模型

C机器学习

D选择合适的模型

方法：

a）代码行技术：

每行代码成本x总代码行

b）任务分解技术：

每项任务成本之和

c）自动估算成本技术：

软件计算

4、风险管理：

对于开发维护过程中可能出现的不受欢迎的事，制定计划尽量避免，如果不可避免，则将负面后果减小到最小。

5、项目计划：

包含客户的需要和我们希望做什么来满足需要。

6、过程模型和项目管理：

对管理技术进行剪裁，使技术能适应所需要的资源、选取的过程和分配人员的特性。

软件可行性研究的内容：

技术可行性、经济可行性、操作可行性、社会可行性

第四章

需求的重要性：

1、引起项目失败的首要原因中几乎所有都涉及需求过程的某些部分。

2、如果开发过程的早期没有检测并修复需求错误，那么会造成很高的代价

需求的类型：

1、功能需求:

根据要求的活动来描述需要的行为。

2、非功能需求或质量需求：

描述一些软件解决方案必须拥有的质量特性

3、设计约束：

已经做出的设计决策或限制问题解决方案集的设计决策

4、过程约束：

是对用于构建系统的技术和资源的限制。

两种需求文档：

需求定义文档和需求规格说明书。

需求定义文档：

客户想要的每一件事情的完整列表。

该文档通过描述打算构建的系统将要安装的环境中的实体，以及关于这些实体的约束、监控和转换来表达需求。

需求规格说明：

将需求重新陈述为关于要构建的系统将如何运转的规格说明。

区别：

1、需求定义面向的是业务相关人员，如委托人、客户和用户；

需求规格说明面向的是技术性人员。

2、需求规格说明仅仅提及通过其接口到系统是可访问的环境实体，需求定义可以处于环境域的任何地方。

需求规格说明书的主要内容。

a）详细描述输入和输出

b）根据接口的输入输出重新陈述要求的功能

c）对用户的质量需求，设计适配标准

类图:

描述了对象类型和他们之间的静态关系。

对象图：

对象图是类图的实例，用来表示类图的类的对象在系统运行过程中某一时刻的状态。

构件图：

表示构件的组织和他们之间的关系，通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响。

包图：

展示了不同包中的类之间的依赖关系。

用例图：

根据系统和系统之间的交互，描述可观察到的、用户发起的功能。

顺序图：

展示了活动或行为发生的顺序。

通信图：

描述了对象之间的消息顺序。

状态图：

展示了对象可能具备的状态、触发状态改变的事件、以及每次状态改变导致的动作。

活动图：

为类中的过程流或活动流建模。

用例图的作用

a）描述和决定系统的功能需求，帮助客户和软件开发人员形成一致意见。

b）给出系统应该做什么且与内容一致的可视化描述，使之成为在开发全过程中研讨系统需求和进行系统设计的依据。

c）在软件测试阶段作为系统测试的基础。

建立系统实现的各个对象类和系统操作与功能需求之间的可追踪关系。

用例图的三个组成部分：

执行者、系统边界和用例。

第五章

概要设计的主要内容：

1、告诉客户系统将要做什么

A数据来自哪里

B系统中的数据会发生什么情况

C对用户来说，系统将会是什么

D向用户提供的选择是什么

E事件的计时是什么

F报表和屏幕是什么样的

2、优秀的概念设计特性

A客户语言

B不包含技术行话

C描述系统功能

D与实现无关

E与需求文档链接起来

技术设计的内容

告诉变成这系统将做什么

1、对主要硬件部分及其功能的描述

2、软件构件的层次和功能

3、数据结构

4、数据流

好的设计的衡量：

内聚和耦合。

内聚：

如果构件的所有元素都是直接面向执行同一个任务的并且

必须的，那么该构件是内聚的

内聚的类型：

巧合内聚、逻辑内聚、时态内聚、过程内聚、通信内聚、功能内聚、信息内聚。

（低到高）

耦合：

高度耦合：

当两个构件之间有大量依赖关系的时候

松散耦合：

当两个构件具有某种程度的依赖，但他们之间的相互连接比较弱

非耦合：

构件之间不存在相互连接

构件间的耦合度取决于：

构件的引用

构件间传递的数据量

构件控制其他构件的数量

构件之间接口的复杂程度

耦合的类型：

（高到低）

内容耦合

公共耦合

控制耦合

标记耦合

数据耦合

第七章

编程程序过程中应遵循一定的标准和过程：

对单个开发人员的标准：

有助于帮助自己组织自己的想法并且避免犯错误，有助于将设计转化为代码。

具体如编写文档的方法、按标准组织代码等等；

对其他开发人员的标准：

按格式编写代码以及编写代码文档，使他人易于理解它做什么以及如何工作。

设计和实现的匹配：

最关键的标准是需要在程序设计构件之间建立直接的对应关系。

保持设计和代码的一致性。

如低耦合、高内聚、定义明确的接口这样的特性，也应该是程序的特性。

了解一些编程指导原则：

控制结构：

使程序容易阅读

根据模块化的块来构建程序

不要让代码太过特殊，也不要太过普通

用参数名和注释来展现构件之间的耦合度

构件之间的关系必须是可见的

算法：

注重性能和效率，但不应该忽略代码更快运行可能伴随的一些隐藏代价，不要牺牲代码的清晰性和正确性来换取速度。

数据结构：

保持程序简单

用数据结构来决定程序结构

通用性指导原则

局部化输入和输出

包含伪代码

改正和重写，而不是打补丁

复用

生产者复用:

在设计的构件要在以后的应用中进行复用

消费者复用:

正在使用的构件是原先为其他项目开发的构件

注意实现容错技术的主要手段是：

冗余

冗余通常分为四类:

（1）结构冗余。

（2）信息冗余（3）时间冗余（4）冗余附加技术。

软件中的注释主要分为：

序言性注释和功能性注释两种。

第八九章

测试的目标：

通过测试发现故障和错误

测试的衡量标准：

只有当发现了错误时，测试才被认为是成功的

测试的分类（或组织）：

1、单元测试：

将每个程序构件与系统中其他构件隔离，对其本身进行测试。

他们验证，针对设计预期的输入类型，构件能否适当地运行。

2、集成测试：

确保构件之间的接口的正确定义和处理。

验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：

确保具有期望的功能。

对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能。

（将正在构建的系统与开发人员的需求规格说明进行比较）

4、性能测试：

将系统与这些软件和硬件需求的剩余部分进行比较，确定系统是按照对系统描述的理解运行的。

5、验收测试：

确定系统是按照客户期望运转的，根据用户的需求描述对系统进行检查。

6、安装测试：

验收的系统安装在将要使用的环境中，安装测试确保系统将按照他应该的方式进行。

黑盒测试：

将测试对象看作一个不了解其内容的黑盒，通过向黑盒提供输入数据，得到输出，并且观察输出和预期输出是否匹配。

黑盒测试免于受强加给测试对象内部结构和逻辑的约束。

不可能总是进行完备的测试

白盒测试：

将测试对象看成一个透明的盒子，根据测试对象的结构用不同的方法进行测试。

有时候有太多的路径，测试显得不切实际。

可以通过只检查少量的相关情况来表达整个的可能性。

单元测试的主要内容：

检查代码

证明代码正确性

测试程序构件

集成测试的类型及主要的测试策略

自底向上集成：

通过合并构建来测试较大型系统的流行方法称为自底向上测试。

每一个处于系统层次中最底层的构件先被单独测试，然后测试调用了最底层构件的构件，以此类推。

（优点：

面向对象很有用

但顶层最重要却最迟测试，容易引起让故障发现推迟等问题。

）

自顶向下集成：

顶层构件先进行独立测试，然后与他调用的构件组合起来测试，以此类推。

正在测试的构件可能会调用还没有经过测试的其他构件，因此我们需要编写一个桩来辅助。

可以依据被检查的功能来定义测试用例、主要问题可以

被尽早发现和处理。

可能需要大量的桩而桩的编写有可能会比较困难）

改进后的自顶向下集成：

在合并测试构件以前，先单独测试低一层的每个构件。

（避免了大量桩的问题，但对每个构件，既需要桩，又需要驱动程序，从而导致更多编码和潜在问题）

一次性集成：

所有构件分别测试，再将它们合在一起作为最终系统进行测试，看能否一次运行成功。

适用于小型系统。

但实际上都不推荐使用。

需要驱动程序和桩、很难发现失效原因、很难把接口故障与其他类型的故障区分开来。

三明治集成：

将自顶向下和自底向上结合起来。

将系统看成三层，目标层在中间，目标层上一层使用自顶向下，目标层下一层使用自底向上，测试集中在目标层。

集合了自底向上和自顶向下的优点。

没有单独完全的测试构件。

改进后的三明治集成：

先单独测构件。

确认测试（系统测试）的主要内容：

分为4个步骤：

功能测试：

对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能。

从现在起进行闭盒测试。

性能测试：

将系统与这些软件和硬件需求的剩余部分进行比较，确定系统是按照对系统描述的理解运行的。

可靠性、可用性、可维护性。

验收测试：

确定系统是按照客户期望运转的，根据用户的需求描述对系统进行检查。

基准测试、试验性测试、并行测试。

安装测试：

验收的系统安装在将要使用的环境中，安装测试确保系统将按照他应该的方式进行。

了解测试计划的主要内容。

测试计划描述我们将以何种方式向用户证明软件运转正确。

a）构建测试目标

b）设计测试用例：

成功测试的关键

c）编写测试用例

d）测试测试用例

e）执行测试

f）评估测试结果。

第十一章

维护活动的类型：

改正性维护：

维护对日常的系统功能的控制，对故障立即作出反应

适应性维护：

维护对系统修改的控制。

系统的一部分改变时，实现对系统其他部分所要求的改变

完善性维护：

完善现有系统。

对系统某些方面进行改进而做出的改变。

预防性维护：

防止系统性能下降到不可接受的程度。

改变系统某些方面，以预防失效发生。

软件再生：

文档重构：

对源代码进行静态分析以产生系统文档，它不对代码作出改变，只是导出信息。

帮助维护人员理解和引用代码。

重组：

将结构不好的代码转换为结构良好的代码，使它变得易于理解和改变。

逆向工程:

从源代码返回到它之前的产品，根据代码重新创建设计和规格说明信息。

再工程：

它是逆向工程的扩展。

再工程在不改变整个系统功能的前提下，生产新的软件源代码。