华南理工大学广州学院 软件工程 复习提纲含答案Word格式文档下载.docx

华南理工大学广州学院 软件工程 复习提纲含答案Word格式文档下载.docx

《华南理工大学广州学院 软件工程 复习提纲含答案Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《华南理工大学广州学院 软件工程 复习提纲含答案Word格式文档下载.docx（14页珍藏版）》请在冰豆网上搜索。

8）向传统的成熟工业学习

9）适合自己的，才是最好的

6.软件生存周期：

（6个阶段）计算机系统工程、需求分析、设计、编码、测试、运行和维护

7.软件过程模型：

1）

主要思想（文档驱动）

●软件开发过程与软件生命周期是一致的

●相邻二阶段之间存在因果关系

●需对阶段性产品进行评审

瀑布模型

优点

●软件生命周期模型,使软件开发过程可以在分析、设计、编码、测试和维护的框架下进行；

●软件开发过程具有系统性、可控性，克服了软件开发的随意性

缺点

●缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发

●开发早期存在的问题往往要到交付使用时才发现，维护代价大

2）演化模型

●演化模型适用于对软件需求缺乏准确认识的情况

●演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。

●在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型，然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。

●典型的演化模型有：

增量模型、原型模型、螺旋模型。

3）增量模型

增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征；

增量模型强调每一个增量都发布一个可运行的产品。

●适用于：

需求经常变化的软件开发；

市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发

●早期阶段使投资得到明显回报

●

易于维护

●要求软件具有开放式结构

4）

原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。

一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

原型模型

原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。

然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型。

被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。

在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。

●通过与用户交互而得到验证，据此产生的规格说明文档正确描述用户需求

●后续阶段发生错误的可能性也比较小

●原型的快速建立可以加速软件开发过程，节约软件开发成本

●只关注需求不注重系统内部结构

●可能导致系统设计差、效率低，难于维护

5）螺旋模型（是瀑布模型和演化模型的结合，并增加了风险分析）

●螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动

制定计划，风险分析，工程实施，客户评估

●螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，

表示开发出一个更为完善的新软件版本。

●多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。

主要适应于内部开发的大规模软件项目

●风险驱动，要求软件开发人员具有丰富的风险评估经验和专业知识

6）喷泉模型（喷泉模型适是合于面向对象开发的模型）

体现迭代和无间隙特征

迭代：

各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统

无间隙：

开发活动之间不存在明显的边界

8.能力成熟度模型CMM

1）初始级（有纪律的过程）软件过程的特点是无秩序的，甚至是混乱的。

几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力

2）可重复级（标准的、一致的过程）建立了基本的项目管理过程来跟踪成本、进度和功能特征。

制定了必要的过程纪律，能重复早先类似应用项目取得的成功

3）已定义级（可预测的过程）已将管理和工程活动两方面的软件过程文档化、标准化，并综合成该组织的标准软件过程。

所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件

4）已管理级（持续改进的过程）收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制

5）优化级过程的量化反馈和先进的新思想、新技术促使过程不断改进

9.敏捷软件开发

软件开发的新挑战

●快速的市场进入时间，要求高生产率

●快速变化的需求

●快速发展的技术

传统的软件开发方法

●强调过程

●强调文档

●开发人员负担过重

称为重载（Heavyweight）方法

10.可行性分析

●可行性研究的目的不是解决问题，而是确定问题是否值得去解决

●可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。

●可行性研究最根本的任务是对以后的行动方针提出建议

●可行性研究需要的时间长短取决于工程的规模。

一般说来，可行性研究的成本只是预期的工程总成本的5%～10%。

●可行性分析过程

✧复查系统规模和目标

✧研究目前正在使用的系统

✧导出新系统的高层逻辑模型

✧进一步定义问题

✧导出和评价供选择的解法

✧推荐行动方针

✧草拟开发计划

✧书写文档提交审查

11.经济可行性分析

●经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发。

●基于计算机的系统的成本主要包括：

1）购置硬件、软件（如数据库管理系统、第三方开发的构件等）和设备（如传感器等）的费用

2）系统的开发费用

3）系统安装、运行和维护费用

4）人员培训费用

●成本估算技术

1）代码行技术

估计出源代码行数

用每行代码的平均成本乘以行数就可以确定软件的成本

每行代码的平均成本主要取决于软件的复杂程度和工资水平。

2）任务分解技术

按开发阶段划分任务

估计每个任务的成本时，通常先估计完成该项任务需要用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本。

3）自动估计成本技术

●效益

1）经济效益

包括使用基于计算机的系统后可增加的收入和可节省的运行费用（如操作人员数、工作时间、消耗的物资等）。

在进行成本效益分析时通常只统计五年内的经济效益。

2）社会效益

指使用基于计算机的系统后对社会产生的影响（如提高了办事效益，使用户满意等）

通常社会效益只能定性地估计。

12.技术可行性分析

●技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现。

●技术可行性分析通常包括风险分析、资源分析和技术分析。

●风险分析：

分析在给定的约束条件下设计和实现系统的风险。

1）采用不成熟的技术可能造成技术风险

2）人员流动可能给项目带来风险

3）成本和人员估算不合理造成的预算风险

4）风险分析的目的是找出风险，评价风险的大小，并有效地控制和缓解风险。

●资源分析：

论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境。

例如，有一支开发过类似项目的开发和管理的团队，或者开发人员比较熟悉系统所处的领域，并有足够的人员保证，所需的硬件和支撑软件能通过合法的手段获取，那么从技术角度看，可以认为具备设计和实现系统的条件。

●技术分析：

分析当前的科学技术是否支持系统开发的各项活动。

1）在技术分析过程中，分析员收集系统的性能、可靠性、可维护性和生产率方面的信息，分析实现系统功能、性能所需的技术、方法、算法或过程，从技术角度分析可能存在的风险，以及这些技术问题对成本的影响。

2）技术可行性分析时通常需进行系统建模，必要时可建造原型和进行系统模拟

13.

法律可行性分析（研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题）

14.需求分析

6个阶段：

需求获取、需求分析、协商、

系统建模、需求规约、需求验证、需求管理

15.需求获取

1）软件需求：

功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性要求

2）方法与策略：

、建立顺畅的通信途径、访谈与调查、观察用户操作流程、组成联合小组、用例

●访谈与调查

前提：

文档研究、面谈方式、访谈一般按照如下原则进行准备：

所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；

不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；

提问和回答在汇总后应能够反映用户需求的全貌；

问卷调查

●观察用户操作流程（到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识）

●组成联合小组

●用例

16.需求分析与协商

●需求分析原则

1）必须能够表示和理解问题的信息域

2）必须能够定义软件将完成的功能

3）必须能够表示软件的行为（作为外部事件的结果）

4）必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节

5）分析过程应该从要素信息移向细节信息

17.需求建模

常用的分析方法：

●面向数据流的结构化分析方法（SA）

●面向数据结构的分析方法

●面向对象的分析方法（OOA）

18.需求规约

19.需求验证

1）系统定义的目标是否与用户的要求一致；

2）

系统需求分析阶段提供的文档资料是否齐全；

文档中的描述是否完整、清晰、准确地反映了用户要求；

3）被开发项目的数据流与数据结构是否确定且充足；

4）主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

5）设计的约束条件或限制条件是否符合实际；

6）开发的技术风险是什么；

7）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。

20.需求管理（需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动）需求跟踪有两种方式，正向跟踪与逆向跟踪

21.面向构件思想（面向构件是一种前沿的软件设计思想，将成熟的工业化生产中标准构件、组装、自动化生产线等概念引入到软件开发过程中，并吸收了软件开发的结构化方法和面向对象方法中的一些优点而形成的）

●软件复用

软件复用就是设法使用已有的软件组成元素来构成新的系统，以减少软件开发所需的费用和时间，提高软件的可维护性和可靠性

1）基于软件函数库的软件复用

2）生成方式，即对模式的复用

3）组装方式

●中间件

1）中间件（middleware）可以看作是面向构件的开发思想的一个实例，或者说是软件复用思想的延伸

2）中间件可以为不同领域内的应用提供系统结构上的支持和标准的服务组件等

3）中间件已成为许多标准化工作的主要部分

●软件总线的中间件（Middleware）即对象请求代理（ObjectRequestBroker，简称ORB）

分布式对象结构具有很好的开放性和透明性，用户可以非常方便地在总线上添加、更新或删除组件对象。

流行的ORB技术标准有两种：

CORBA（CommonObjectRequestBrokerArchitecture）

DCOM（DistributedComponentObjectModel）

SOA架构模式（SOA模式在三个主要参与者——“服务提供者、服务消费者和服务代理”之间定义了交互模型）

SOA系统架构的层次

●云计算（CloudComputing）：

是分布式处理（DistributedComputing）、并行处理（ParallelComputing）和网格计算（GridComputing）的发展，或者说是这些计算机科学概念的商业实现。

是指基于互联网的超级计算模式--即把存储于个人电脑、移动电话和其他设备上的大量信息和处理器资源集中在一起，协同工作。

在极大规模上可扩展的信息技术能力向外部客户作为服务来提供的一种计算方式。

●SaaS

22.软件测试

●Davis提出了一组指导软件测试的基本原则：

1）所有的测试都应可追溯到客户需求

2）应该在测试工作真正开始前的较长时间就进行测试计划

3）Pareto原则：

测试中发现的80%的错误可能来自于20%的程序代码

4）测试应从“小规模”开始，逐步转向“大规模”

5）穷举测试是不可能的

6）为了达到最有效的测试，应由独立的第三方来承担测试

●其他的测试原则：

1）在设计测试用例时，应包括合理的输入条件和不合理的输入条件

2）严格执行测试计划，排除测试的随意性

3）应当对每一个测试结果做全面检查

4）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便

5）检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事

6）在规划测试时不要设想程序中不会查出错误

23.白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作[PPT]

●主要用于对模块的测试

●常用的测试方法

1）基本路径覆盖测试根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径，最后为每一条基本路径设计一个测试用例

2）逻辑覆盖测试考察使用测试数据运行被测程序时对程序逻辑的覆盖程度

3）数据流测试根据程序中变量的定义（赋值）和引用位置来选择测试用例

4）循环测试简单循环、嵌套循环、串接循环和非结构循环

24.黑盒测试（依据软件的需求规约，检查程序的功能是否符合需求规约的要求）[PPT]

●主要测试方法

1）等价类划分将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例

2）边界值分析挑选那些位于边界附近的值作为测试用例

3）比较测试分别开发二个软件版本，用相同的测试用例对二个版本的软件分别进行测试，比较其测试结果

4）错误猜测凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例

5）因果图既考虑输入条件的组合关系，又考虑输出条件对输入条件的依赖关

25.

软件测试策略

26.V模型

1）V模型：

描述软件开发各阶段与测试策略之间的对应关系

2）单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。

3）集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。

4）确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。

5）对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误。

27.软件维护（指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程）

●软件维护的类型

完善性维护：

扩充原有系统的功能，提高原有系统的性能，满足用户的实际需要。

纠错性维护：

对在测试阶段未能发现的，在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错以及验证、修改的回归测试过程。

适应性维护：

要使运行的软件能适应运行环境的变动而修改软件的过程。

预防性维护：

为了进一步改善软件的可靠性和易维护性，或者为将来的维护奠定更好的基础而对软件进行修改。

●软件维护的特性

1）结构化维护：

指软件开发过程是按照软件工程方法，软件的维护过程，有一整套完整的方案、技术、审定过程。

2）非结构化维护：

缺乏必要的文档说明，难于确定数据结构、系统接口等特性。

维护工作令人生畏，事倍功半。

●软件维护的技术面向维护的技术、软件支援技术、软件维护中应注意的问题

28.软件项目管理

●软件项目管理，是对整个软件生存期的所有活动进行管理。

主要过程包括：

1）项目启动确定系统范围、组建项目团队、建立项目环境。

2）项目规划确定项目活动、项目成本估算、制定进度计划

3）项目实施监控项目执行、管理项目风险、控制项目变更

4）项目收尾项目验收、软件安装培训、项目总结

●项目管理的主要活动

1）软件项目的规划（可行性分析、软件成本估算、软件计划）

2）人员的组织管理（人员配备原则、人员配备模式、软件团队建设、软件项目沟通活动）

3）软件风险管理（风险识别、风险分析、风险规划、风险监控）

4）软件配置管理（是为了有效地控制和管理软件开发过程中的变化，进行标识、组织和控制修改的技术；

配置管理活动：

配置项的标识、版本管理、系统构建、变更控制）

29.风险管理（项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程，包括风险识别、风险量化、风险对策和风险监控，从而将积极因素所产生的影响最大化和使消极因素产生的影响最小化，或者说达到消除风险、回避风险和缓解风险的目的）

●应对风险的基本措施

1）规避。

通过变更项目计划消除风险或风险的触发条件，使目标免受影响。

2）转移。

不能消除风险，而是将项目风险的结果连同应对的权利转移给第三方。

3）弱化。

将风险时间的概率或结果降低到一个可以接受的程度，其中降低发生的概率更为有效。

4）接受。

不改变项目计划，而考虑发生后如何应对