软件工程复习1.docx
《软件工程复习1.docx》由会员分享，可在线阅读，更多相关《软件工程复习1.docx（26页珍藏版）》请在冰豆网上搜索。
软件工程复习1
软件工程
单选2*15判断1*10过程设计2*10简答6*4综合16
第一章
软件==程序+数据+文档。
数据==初始化数据+测试数据
文档==开发文档+管理文档。
1．什么叫程序、软件、软件产品？
什么是软件工程？
程序：
由个人开发，供个人使用。
规模小，功能有限，缺乏良好的用户界面和适当的文档资料
软件：
是一系列按照特定顺序组织的计算机数据和指令的集合
软件产品：
有多个用户，有良好的用户界面、合适的使用手册和良好的文档支持。
经过系统化设计、精心实现和彻底测试过的。
不仅包含程序代码，还有所有相关的文件。
一组工程师团队开发
2．编程结构：
顺序、选择、循环
3．软件设计技术的发展
第二章
1．生命周期阶段及描述
软件的生命周期是指软件产品会在其一生中所经历的一系列可识别的阶段。
第一阶段：
可行性研究阶段随后是：
需求分析和说明、设计、编码、测试及维护
2．为什么使用生命周期？
生命周期鼓励以系统化和规范的方式开发软件。
当程序由团队开发时，避免导致混乱和项目失败。
3．瀑布模型（其他的生命周期模型基本上都来自于经典瀑布模型）
●不同的阶段分别是：
可行性研究、需求分析和说明、设计、编码和单元测试、集成和系统测试（开发阶段）以及维护（开发阶段完成后开始，工作量大，时间较长）
●特点：
⏹将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
⏹项目管理跨越整个项目期限。
●生命周期中可行性研究和产品测试和交付之间的部分被称为开发部分
●优势：
¡有利于大型软件开发过程中人员的组织及管理
¡有利于软件开发方法和工具的研究与使用
¡提高了大型软件项目开发的质量和效率。
●劣势：
¡由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
¡早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
¡各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
¡开发时间（周期）十分长
¡成本高；
4．其他模型
迭代瀑布模型：
●避免了经典瀑布模型不支持处理在任何阶段发生的错误机制的缺点
●不适用于很大型的项目和风险很多的项目
原型模型：
特点：
1）在执行实际软件开发前，建立系统的一个工作原型。
原型是系统的一个模拟执行，功能有限、可靠性较低及性能不充分。
2）原型用处：
说明输入数据格式、消息、报告以及和客户的交互对话；帮助工程师仔细的检查和产品开发相关的技术问题；第一次就“完全弄好”是不可能的，因此需计划放弃第一个产品，这样后面就能开发出一个好产品。
3）适用于开发团队不清除解决方案时
4）首个阶段是初次需求收集阶段
进化模型：
（增量模型）
螺旋模型：
（元模型）
5．模型的比较（参考以上）
6．如何理解“软件开发的生命周期模型”？
为什么在开发一个大型软件产品时遵循一个生命周期模型很重要？
（见点1，点2）
第三章
1．项目经理职责
写项目建议书、项目造价估算、时间安排、项目人员、软件过程修改、项目检测和控制、软件组态管理、风险管理、与客户交谈以及经理报告和演讲等。
2．项目规划包含活动：
1）估计项目的一些基本属性：
成本；期限；工作量
规划活动的效率是基于如下估计的准确度的：
2）人力和其他资源的调度
3）人员组织和人员配置计划
4）风险识别、风险分析以及风险减少规划
5）杂项计划，如质量保证计划、组态管理计划等
3．项目规模估算的度量：
●两种度量被广泛用来估计规模：
代码行和功能点
1）代码行（LOC）：
通过计算已开发程序中源指令的数量估算项目规模，用来注释代码和头部的行都被忽略了。
优点：
最简单易用的
缺点：
A.对问题的规模给出了一个数值，会因为个人编码风格不同而有很大变化
B.好的问题规模策略应考虑到问题的总体复杂性，以及解决这一问题所需的工作量。
C.与代码质量和效率没有太大关系
D.阻碍使用更高级别的编程语言、代码重用等
E.会测量程序的词汇复杂程度，但并不处理更重要的而又微妙的逻辑上或结构上的复杂性问题
F.很难根据问题描述准确估算，只有代码被完整开发后才能被准确计算出来
2）功能点（FP）：
软件产品的规模直接取决于它支持的多种不同的功能或特性。
优点：
它可以很容易地直接根据问题说明来估算软件产品的规模
4.常见的项目估算方法
●经验估算法：
专家判断法、Delphi成本估算
●启发式方法
●分析估算法
5.调度
●为了调度项目活动，软件项目经理需要完成：
1）确定完成项目所需的各项任务
2）把大型任务划分为小型活动
3）确定不通活动之间的依存关系
4）建立完成活动所需时间的最有可能估算
5）分配资源到活动
6）规划不同活动的起止日期
7）确定路径。
关键路径是决定项目持续时间的活动链
●工作分解结构（WBS）：
用于把一个给定的任务集递归分解成小活动
●活动网络和关键路径方法
MIS问题的活动网络示意图：
关键路径方法（CPD）：
1）完成项目的最小时间（MT）是从开始到结束所有路径的最大值。
2）一个任务最早的开始（ES）时间是从开始到这个任务所有路径的最大值。
3）最晚的开始（LS）时间是MT与从该任务到结束所有路径最大值的差值。
4）一个任务的最早结束时间（EF）是任务的最早开始时间和任务持续时间之和
5）一个任务的最晚结束（LF）时间可以通过MT减去从该任务到结束所有路径的最大值得到
6）松弛时间（ST）是LS-EF，也可以写成LF-EF。
松弛时间（浮动时间）是在一个任务能够影响项目的结束时间之前被推迟的总时间。
松弛时间指明了开始和结束任务的灵活性。
注意：
在关键路径中一般是没有浮动时间的。
7）关键任务是松弛时间为0的任务
8）从开始节点到结束节点且仅包含关键任务的路径被称为关键路径。
●Gantt图（图P56）
1）主要用于把资源分配到活动
2）是一种特殊类型的条形图，其中每个横条都代表一个活动
●PERT图
1）方块表示活动，箭头表示关系
2）表示了项目估算中的统计变量，假设一个正态分布
3）每个任务都标记有消极、相识、乐观的估算
6.风险管理
风险是可能在项目进行过程中发生的任何可预知的不利事件或情况。
项目风险：
涉及各种形式的预算、进度、人员、资源以及和客户相关的问题
风险识别技术风险：
涉及潜在的设计、实现、对接、测试及维护问题，包括需求说明歧义、需求
说明不全、需求说明改变、技术的不确定性及技术落后
业务风险：
建立一个无人想要的优秀产品的风险、失去预算或人员承诺的风险等
风险成真的可能性（r）
风险管理风险评估
和该风险相关的问题的后果（s）：
p（风险优先级）=r*s
规避风险：
与客户讨论以减少工作范围，奖励工程师以避免人员变更的风险等
风险控制转移风险：
涉及获得一个第三方开发的有风险的组件，或购买保险保障等
减少风险：
涉及规划遏制风险所造成的损害的方法，如存在一些关键人员可能离开的风险
第四章
1．需求收集和分析
需求收集：
涉及到采访最终用户和客户，以及研究现有的文档，从而收集到与系统相关的所有可能的信息
对已收集需求的分析：
主要目的在于清楚的了解客户的确切需求。
需识别并解决最重要的需求问题是异常（需求中的歧义）、不一致（需求中任意两条相互抵触）和不完整（需求中有些部分被忽视）的问题。
2．软件需求规约（SRS）
SRS通常以非正式的形式包含了所有的用户需求，开发团队和顾客意见的一个合约的记录
SRS文档用户的重要类别及其需要如下：
用户、顾客和销售人员，软件开发人员，测试工程师，用户手册作者，项目经理，维护工程师
SRS文档记录系统的功能需求、非功能需求、实施目的
3．功能需求
每个高级需求涉及到从用户那里接受一些数据，然后将其转换为所需的回应，再把回应输出给用户。
第五章
1．SRS文档的完成标志设计开始
设计阶段的目标就是将SRS文档当作一种输入，并在设计阶段完成完成之前生成的文件
2．优秀的软件设计特点：
1）正确性：
能够正确执行系统的所有功能
2）可理解性：
易于理解
3）效率：
有效率的
4）可维护性：
易于更改
易于理解具备的特征：
1）对于不同的设计组件，应该使用一致的且有意义的名字
2）设计应该是模块化的（模块化）
3）准确的把模块安排在一个层次中（清楚分解、模块整齐排列）
整齐排列的特征：
1）分层次的解决方法
2）低扇出
3）抽象化
3．内聚和耦合
模块分解首要特点：
高内聚、低耦合
功能独立重要，原因如下：
1）错误隔离：
减少错误传递
2）重新使用的范围
3）可理解性：
复杂度降低
内聚力分类：
巧合、逻辑、临时、程序、沟通、顺序、功能
耦合的分类：
数据、标记、控制、公共、内容
4．设计方法
●面向功能的设计
特点：
1）一个系统被视为能够执行一系列的函数
2）系统状态是集中的，并在不同的函数之间共享
●面向对象的设计
特点：
1）系统被视为是一个对象的集合（即实体）。
2）系统的状态在对象中是分散的，并且每个对象可以控制自己的状态信息
面向功能的设计和面向对象的设计的区别：
1）不同于面向功能的设计方法，在OOD中基本抽象物并不是sort、display、track之类的功能，而是employee、picture、machine、radarsystem等真正存在的实体
2）在OOD中，状态信息是在系统对象之间分发的集中共享存储器中及时呈现的
3）如果作为一组他们形成了更高级别的功能，则SA/SD之类的面向功能的技术会把功能组织在一起。
面向实体的技术会以在其上操作的数据为基础，把所有的功能组织在一起
第六章
1．结构分析
结构分析技术是基于以下基本原则：
1）自上而下的分解方法
2）分治原则—每个功能都被独立分解
3）使用数据流程图来图形化表示分析结果
2．数据流图（P117图）
3．DFD缺点
1）DFD中有相当多的部分是不精确的。
在DFD模型中，通过其标记来判断一个气泡执行的功能，然而一个较短的标记可能无法体现出一个气泡的所有功能
2）DFD并未定义控制方面
3）执行分解到连续级别的方法和分解回到最终级别是高度主观的，取决于分析师的选择和判断。
同一问题可能出现多个DFD，且不好取舍
4）对于如何准确的分解一个给定的功能到其子功能，数据流程图技术并未提供任何明确的指导，需主观判断来执行分解
4．设计审查
审查小组由参与设计、执行、测试及维护的成员组成
审查设计文档由以下几方面：
1）可追溯性2）正确性3）可维护性4）执行
5．在面向功能的设计的语境下，你认为“自上而下的分解”这个短语的意思是什么？
（主要强调传统的设计方法的基本思想，自上而下，逐步求精，模块分解是其核心）
第七章
1．基本机制：
对象、类与实例、继承、消息和方法
2．OOD的优势：
1）代码和设计复用
2）提高的生产率
3）简便的测试和维护
4）代码与设计更好的可理解性
最主要的是提高的生产率，例如：
1）使用预定义类库进行的代码复用
2）继承导致的代码复用
3）更简单的和更直观的抽象，即对于固有复杂性的更优组织
4）
更好的问题分解
3．五种类型，九种图
结构视图：
类图、对象图
行为视图：
序列图、协作图、状态图、活动图
实施视图：
构件图
环境视图：
部署图
用户视图：
用例图
第八章
1．面向对象基本思想
使用对象、类、继承、封装、消息等基本概念来进行程序设计。
从现实世界中客观存在的事物（即对象）出发来构造软件系统，并且在系统构造中尽可能运用人类的自然思维方式。
2．什么叫模式
模式是在很多应用中重复发生的问题的可复用的解决问题的方案
一个模式有四个重要组成部分：
1）问题
2）问题发生的环境
3）解决方案
4）解决方案生效的环境
3．用例模型
序列图
4．面向对象的分析（OOA）和面向对象的设计（OOD）之间有什么不同？
OOA与OOD是软件工程/过程的两个不同阶段；从技术上说是两个不同层次的技术，前者要求更抽象，能够把问题描述清楚，针对的是需求、问题等，后者在前者的成果基础上要求更具体的设计，强调怎么实现，非常精确
第九章
1.一个良好用户界面的特征
●学习速度
●使用比喻和直观的命名名称
●一致性
●基于组件的界面
●使用速度
●重新调用的速度
●错误预防
●吸引力
●一致性
●反馈
●对于多个技术级别的支持
●错误回复（撤销命令）
●用户指南和在线帮助
2．用户指南和在线帮助
在线帮助系统、指导消息、错误信息
3．基于模式的界面与无模式的界面
一个基于模式的界面不同集合的命令可以根据系统所处的模式进行调用
一个无模式的界面只有一个单一模式，所有的命令在软件操作的整个过程中都可用
4．图形用户界面（GUI）与基于文本的用户界面
1）在一个GUI中，拥有不同信息的多个窗口可以同时显示在用户屏幕上
2）GUI中也可能有图标化的信息表示以及象征性的信息操作
3）一个GUI通常支持使用一个有吸引力的和用户友好的菜单选择系统进行命令选择
4）在一个GUI中，一个指向设备，可以用来发布命令，提高命令发布程序的效率
5）在图形显示方面，一个GUI需要有图形运算能力的特殊终端，同时也需要特殊的输入设备
5．用户界面的种类
基于命令语言的界面、基于菜单的界面（活动菜单、弹出菜单、层级菜单）、直接操作界面
第十章
1.编码
编码标准：
●限制使用全局变量的规则。
●不通模块的文件头应先行体现代码内容
●全局变量、局部变量和常量标识符的命名规则
全局变量：
以大些字母开头
局部变量：
全部由小写字母构成
常量：
全部由大写字母构成
●错误返回规范和异常处理机制
编码指南：
●不要使用太艰深或太困难以至于难以理解的编码风格
●避免模糊的副作用
●不要将一个标识符用于多种用途
●代码应有良好的记录
●任何函数的长度都不应超过10行源代码
●不要使用goto语句
2.代码复审分为：
代码走查和代码检查
代码走查：
是一种非正式的代码分析技术
代码检查：
与代码走查相反，其目的在于要发现由于忽略和不正确的编程所导致的一般类型的错误。
3.测试目的：
识别存在于一个软件产品中所有缺陷，即发现错误。
而不是证明没有错误。
4.一个软件产品要经历4个级别的测试：
单元测试、集成测试、系统测试、验收测试
5.黑盒测试
特点：
在黑盒测试中，测试用例是根据输入/输出值的检验所设计出来的，并不会根据所需设计或代码的知识。
用来确认软件功能的正确性和可操作性。
主要方法：
等价类划分、边界值分析、错误推测法、因果图法、场景法
6、白盒测试
特点：
根据所需设计或代码的知识设计出来的。
主要方法：
逻辑覆盖法（语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖）、基本路径测试法（路径覆盖）、划分法
7.程序分析工具：
静态分析工具、动态分析工具
8.黑盒测试和白盒测试之间的区别？
黑盒测试：
目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性.
白盒测试：
了解程序结构和处理过程，检查是否所有的结构和路径都是正确的，检查程序的内部动作是否按照设计说明的规定正常进行。
9．通常大型软件产品在三个不同测试级别进行测试，即单元测试、集成测试和系统测试。
为什么不在系统开发完成后再对其进行一个单独彻底的测试，例如，在系统测试中检测该产品的所有缺陷呢？
第十一章
1.软件的可靠性概念
本质上，软件产品的可靠性代表了其可信赖或可依赖程度，也可被定义为在一段给定时间中该产品能够正确运行的概率；
2.硬件与软件的可靠性（图P237）
硬件：
故障时由于组件损耗造成，修正错误可以更换或修理出现故障的零件，修复好可靠性保持之前水平。
关注稳定性。
软件：
只有在找到了错误并改变设计或代码后，才会停止出现故障，修复好可靠性会增高或降低。
关注提升可靠性。
3.软件质量（优质软件的几个质量因素）
可移动性、可用性、可复用性、正确性、可维护性
4.SEI能力成熟度模型（CMM）把软件开发企业分为5个成熟度级别：
CMM级别
重点
关键过程域
基本级
能胜任的人
——
重复级（可重复级）
项目管理
软件项目规划、软件配置管理
确定级（已定义级）
过程的定义
过程定义、培训项目、同行评议
管理级
产品和过程质量
定量的过程度量、软件质量管理
优化级
过程连续改进
缺陷预防、过程变更管理和技术变更管理
5.ISO和SEI/CMM的比较
1）ISO9000是一个由国际标准组织颁布的，SEICMM供内部使用
2）SEICMM专为软件产业特别开发出来的，可以处理很多仅和软件产业相关的问题
3）SEICMM超出了质量保障的范围，会为组织做好准备以最终达成TQM，ISO9001目标是第三级别的SEICMM模型
4）SEICMM模型提供了一个关键过程域（KPA）的列表，提供了逐渐取得质量提升的方式
6.指出使测量软件可靠性比测量硬件可靠性更加困难的因素
大多数硬件故障是由于组件损耗造成的，要修正硬件错误我们可以更换或修理出现故障的零件。
就软件而言，只有在找到错误并改变设计或代码后它才会停止出现故障。
鉴于此当硬件修复好之后，它的可靠性还是在故障发生之前的水平；而软件故障修复好之后，它的可靠性则会增加或降低。
从另一个角度来看硬件可靠性研究所关注的是稳定性，而软件可靠性研究的目的在于提高可靠性。
第十二章
理解CASE工具和CASE环境？
1．计算机辅助软件工程（CASE）的概念、范围、环境
概念：
CASE工具是一个通用术语，指的是对软件工程的任意形式的自动支持。
更狭义的说，CASE工具表示的是使有关软件开发的一些活动自动化进行的任何工具。
范围：
规约、结构分析、设计、编码、测试等
环境：
CASE好处：
1）减少所以开发阶段的成本，工作量可以减少30%-40%
2）使质量有相当的改进
3）有助于产出优质且一致的文档
4）减少了软件工程师的繁重工作
5）极大的降低软件维护工作中的成本
6）会影响一家公司的工作方式，并使其认识到结构化和有序的方法
2．你所理解的CASE工具和CASE环境是什么？
为什么整合工具会加强这些工具的作用?
请举例说明。
（同上）
例如：
TurboC和VisualC++之类的标准编程环境都装配有程序编辑器、编译器、调试器、连接器等，所有这些工具都被整合在一起。
如果点击编译器，编译器报告一个错误，那么不仅您会被转向到编辑器中，光标也会指到造成错误的特定行或语句。
第十三章
维护有哪些？
为什么需要这些维护？
1．软件维护的特征
时间最长，成本最高，达到60%以上
2．软件维护的需求日渐增长的主要原因：
纠正性：
纠正在系统使用中所发现的漏洞
适应性：
用户需要产品在新平台、新操作中运行或需要产品和新的硬件或软件接口时，需要维护。
完善性：
根据客户要求改变系统的不同功能或强化系统的性能。
3．软件维护过程模型
模型1
模型2
4．一个软件产品可能需要的不同类型的维护有哪些？
为什么需要这些维护?
纠正性：
纠正在系统使用中所发现的漏洞
适应性：
用户需要产品在新平台、新操作中运行或需要产品和新的硬件或软件接口时，需要维护。
完善性：
根据客户要求改变系统的不同功能或强化系统的性能。
第十四章
1．能够有效复用的主要项目有：
需求规约、设计、代码、测试用例、知识
升级会员 