14级软件工程基础知识点整理.docx
《14级软件工程基础知识点整理.docx》由会员分享,可在线阅读,更多相关《14级软件工程基础知识点整理.docx(21页珍藏版)》请在冰豆网上搜索。
14级软件工程基础知识点整理
Chapter01
SE的定义、目的、方法及作用(P2/P16)
答:
采用工具、技术等用来解决现实问题的综合过程软件工程是一个系统工程,既包括对技术问题的分析和综合,又包含对开发过程和参与者的管理。
SE想确保软件具有技术高质量和实际商业价值
软件质量应从哪几个方面来衡量?
论述之。
(9--12页)
(最终)产品的质量
(软件开发及维护)过程的质量
(商业应用背景下的软件质量)(商业质量)
现代软件工程大致包含的几个阶段及各个阶段文档(P23-24)
1、需求分析——SRS(软件需求规格说明书),在这一阶段主要进行问题定义,可行性研究和需求分析。
复审(所有的参与者:
开发者、客户、用户)
2、系统设计——SAD(系统结构图),主要针对于用户界面。
复审(开发者和客户)
3、程序设计——文档,主要针对模块分析和算法设计。
复审(开发者)
4、程序实现——源代码和注释。
复审(开发者和程序员)
5、单元测试——单元测试报告,主要进行模块功能和性能测试。
复审(测试团队)
6、集成测试——集成测试报告,主要针对于系统结构图进行测试。
复审(测试团队)
7、系统测试——系统测试报告,根据SRS对系统的整体功能进行测试。
复审(开发者和客户)
8、系统提交,复审(根据用户和操作手册)——验收测试报告
9、维护——维护报告。
复审(维护团队)
使现代SE实践发生变化的(七个)关键因素是什么?
(28--29页)
商业软件的投放市场时间的紧迫性
计算经济学的改变
强力的桌面计算平台的可用性
局域网和广域网的延伸
面向对象技术的出现和采用
使用窗口、图标、菜单和指针的图形用户界面
瀑布模型用于软件开发的不可预测性
什么是抽象?
(30页)
基于某种层次归纳水平的问题描述。
它使我们将注意力集中在问题的关键方面而非细节
什么是软件过程?
软件开发活动中的各种组织及规范方法
软件过程的重要性是什么?
包含几个阶段?
(32页)(45页)
软件过程的三个阶段:
单用户、桌面生产工具;
部门应用;
企业范围应用程序或区域范围用用程序;
什么是重用等软件工程主要概念?
(34页)
重用:
重复采用以前开发的软件系统中具有共性的部件,用到新的开发项目中去.
Measurement(度量)(通用的评价方法和体系)两个方面:
量化描述系统+量化审核系统。
Chaoter02
什么是软件过程?
软件过程的重要性是什么?
(P45-46)
过程:
软件开发活动中产生某种期望结果的一系列有序任务,涉及活动、约束和资源。
重要性:
1、通用性,强制活动具有一致性和一定的结构。
2、指导性,过程结构允许我们分析、检查、理解、控制和改进我们的过程,并以此指导我们的行动。
3、共享经验。
瀑布模型及各阶段文档,优缺点?
(P49)
需求分析:
《SRS》
系统设计:
系统设计文档如软件结构图
程序设计:
模块功能算法和数据描述文档
编码:
源程序和注释
单元测试和集成测试:
单元测试报告
系统测试:
系统测试报告
验收测试:
验收测试报告
运行与维护:
维护报告
a)优点
i.描述了软件开发活动,每一个过程活动都有与其相关联的里程碑和可交付产品,以便与项目经理能够用模型来判断在某一时刻项目里最后完成还有多远。
ii.简单。
开发人员很容易向不熟悉软件开发的客户作出解释。
iii.是其他复杂模型的基础。
很多其他更复杂的模型实际上是在瀑布模型基础上的润色,如加入反馈循环以及额外的活动。
b)缺点
i.面临软件变动时,该模型无法处理实际过程中的复杂开发问题。
没有把软件看做一个问题求解的过程,软件是一个创造的过程,不是一个制造的过程。
ii.文档转换有困难
原型的概念(P51)
一种部分开发的产品,用来让用户和开发者共同研究,提出意见,为最终产品定型
论述分阶段开发模型的含义,其基本分类及特点是什么?
(56页)
定义:
系统被设计成部分提交,每次用户只能得到部分功能,而其他部分正处于开发过程中。
分类:
1、增量式开发:
系统需求按照功能分成若干子系统,开始建造的版本是规模小的、部分功能的系统,后续版本添加包含新功能的子系统,最后版本是包含全部功能呢的子系统集。
2迭代式开发:
系统开始就提供了整体功能框架,后续版本陆续增强各个子系统,最后版本使各个子系统的功能达到最强。
螺旋模型四个象限的任务及四重循环的含义?
(P58)
任务:
第一象限:
确定目标、可选方案及约束
第二象限:
评估可选方案及风险
第三象限:
开发与测试
第四象限:
计划
四重循环的含义:
1、操作概念是第一次迭代的产品。
2、而需求则是第二次迭代的主要产品。
3、在第三次迭代中,系统开发产生设计。
4、第四次迭代能够进行测试。
5、螺旋模型的每一次迭代都根据需求和约束进行风险分析,以权衡不同的选择,并且在确定某一选择之前,通过原型化验证可行性或期望度。
当风险确认之后,项目经理必须决定如何消除风险或使风险降到最低。
P80--81页习题2,3。
V模型
a)优点
i.说明了测试活动是如何与分析和设计相联系的
ii.使得隐藏在瀑布模型中的迭代和重做活动更加明确
iii.关注活动和正确性
b)缺点
c)当开发活动后期需求发生变化时,执行左边的步骤以修正和改进需求、设计和编码,在执行右边的测试步骤。
原型化模型
a)优点
i.允许开发人员快速构造整个系统或系统的一部分以理解或澄清问题
ii.减少开发中的风险和不确定性
b)缺点
c)需求变化时重新退回到需求阶段,对需求进行修正,达成共识再次进行设计编码和测试
可操作规格说明
a)优点
i.功能与设计相结合,允许用户和开发人员在早期检查需求。
b)缺点
c)在开发的早期检查需求及其隐含的含义,通过演示系统行为的方式来评估或执行系统需求。
可转换模型
a)优点
i.通过去除某些主要开发步骤来设法减少出错的机会。
ii.转换方法具有很好的前景
b)缺点
i.应用转换方法的主要障碍在于需要一个精确表述形式化的规格说明
c)不知道
阶段化开发模型
a)优点
i.即使还缺少某些功能,但在早期的发布中就可以开始进行培训,培训过程可以使开发人员观察某些功能是如何执行的,并为后面的发布提供了改进的建议。
这样,开发人员能够很好地对用户的反馈做出反应。
ii.可以及早为那些以前从未提供的功能开拓市场
iii.当运行系统出现未预料到的问题是,经常性的发布可以使开发人员能全面、快速的修复这些问题。
iv.针对不同的发布版本,开发团队将重点放在不同的专业领域技术上。
什么是UP,RUP?
UP(统一过程)是用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架,它使用对象管理组织(OMG)的UML并与对象管理组织(OMG)的软件过程工程原模型(SPEM)等相兼容。
8.RUP(统一开发过程):
迭代开发是统一开发过程的关键实践;开发被组织成一系列固定的短期小项目;每次迭代都产生经过测试、集成并可执行的局部系统;每次迭代都具有各自的需求分析、设计、实现和测试;随着时间和一次次迭代,系统增量式完善。
Chapter03
什么是项目进度?
活动?
里程碑?
(83页)
1、项目进度是对特定项目的软件开发周期的刻画。
包括对项目阶段、步骤、活动的分解,对各个离散活动的交互关系的描述,以及对各个活动完成时间及整个项目完成时间的初步估算。
2、活动:
项目的一部分,一般占用项目进度计划中的一段时间。
3、里程碑:
指特定的时间点,标志着活动的结束,通常伴随着提交物。
如何计算软件项目活动图的关键路径?
(习题2,3)冗余时间?
最早和最迟开始时间(课堂习题讲解)
软件团队人员应该具备的能力是什么?
(96页)
1、完成工作的能力
2、对工作的兴趣
3、经验
4、Training
5、与他人交流的能力
6、与他人共同承担责任的能力
7、管理技能
软件项目组织的基本结构?
(101页)
a)主程序员负责制组:
由一个人主要负责系统的设计和开发,
b)忘我方法
试述COCOMO模型的三个阶段基本工作原理或含义。
(111页)
a)阶段1应用组装:
项目通常构建原型已解决包含用户界面、软件和系统交互、性能和技术成熟型等方面在内的高风险问题。
这时,人们对正在创建的最终产品的可能规模知之甚少,因此COCOMO2用应用点(其创建者对它的命名)来估算规模。
这种技术根据高层的工作量生成器来获取项目的规模。
b)阶段2早期设计:
使用功能点对规模进行测量。
功能点是在参考文献IFPUG中详细讨论的一种技术,估算在需求中获取的功能。
因此与应用点相比,他们提供了更为丰富的系统描述。
c)阶段3后体系结构阶段:
可以根据功能点或代码行来进行规模估算,而且可以较为轻松的估算很多成本因素。
什么是软件风险?
主要风险管理活动?
有几种降低风险的策略?
(119、122页)
在软件生产过程中不希望看到的、有负面结果的事件
主要风险管理活动:
风险估算(风险识别、风险分析、风险优先级分配);风险控制(风险降低、风险管理计划、风险化解)
策略:
1、通过改变性能或功能需求,避免风险
2、把风险分配到其他系统中,或者购买保险。
3、接受并用项目资源控制风险。
找出图3.23和3.24(139页)的关键路径。
Chapter04
需求的含义是什么?
(143页)
是对来自用户的对软件系统的期望行为的综合描述,设计系统的对象、状态、约束、功能等
需求作为一个工程,其确定需求的过程是什么?
(144页图4.1宿是说说)
确定需求的过程
a)原始需求获取
b)问题分析
c)规格说明草稿
d)需求审核
e)最后形成正式的需求文档SRS
举例说明获取需求时,若有冲突发生时,如何考虑根据优先级进行需求分类。
(152页)
需求的优先级划分
a)绝对要满足的需求(必须的)
b)非常值得要的但并非必须的需求(值的要的)
c)可要可不要的需求(可选的)
需求文档分为哪两类?
(153页)
a)需求定义:
需求定义是客户想要的每一件事情的完整列表。
该文档通过描述打算构建的系统将要安装的环境中的实体,以及关于这些实体的约束、监控和转换来表述需求。
需求完全根据环境来编写,表述要构建的系统是如何影响环境的。
b)需求规格说明用技术术语和符号重述需求定义使得设计者可以开始设计。
将需求重新陈述为关于要构建的系统将如何运转的规格说明。
该规格说明也是完全按照环境来编写的,唯一的区别是它仅仅提及通过其接口到系统是可访问的环境实体。
也就是说,系统边界清楚地说明了可以被系统监控和控制的那些实体。
什么是功能性需求和非功能性需求/质量需求?
设计约束?
过程约束?
(149页)
功能需求:
描述系统内部功能或系统与外部环境的交互作用,设计系统输入应对,实体状态变化,输出结果,涉及约束与过程约束等。
非功能需求/质量需求:
描述软件方案必须具备的某些质量特征
设计约束,是已经做出的设计决策或限制问题解决方案集的设计决策。
a)物理环境:
对环境或设备的限制等
b)接口:
涉及输入输出的限制或约束条件(输入格式预定等)
c)用户:
使用者的基本情况
过程约束,对于构建系统技术和资源的限制。
a)资料:
材料、人员技能或其他。
b)文档:
类型、数量或其他
c)标准:
需求的特性?
(正确性、一致性、完整性)(155页)
a)正确性
b)一致性
c)无二义性
d)完备性:
如果需求制定了所有约束下的、所有状态下的、所有可能的输入输出以及必须的行为,那么这组需求就是完备的。
如果某些需求描述了所有状态、状态变化、输入、产品和约束,那么这组需求就是外部完备的;如果需求中没有未定义的项,就说这个需求是内部完备的。
e)可行性
f)每一个需求都是相关的吗
g)可测试:
如果需求能够提供验收测试(明确证明最终系统是否满足需求),需求就是可测试的。
h)可跟踪
在需求原型化方面,什么是抛弃型原型?
什么是演化型原型?
(192--193页)
抛弃型原型:
仅用于了解问题、探索可行性,并不打算用来作为将来实际提交系统的一部分。
进化式原型:
用于了解问题,并作为将来准备提交的系统的一部分。
Chapter05
什么是软件体系结构?
设计模式?
设计公约?
设计?
概念设计?
技术设计?
(223-224页)
1.体系结构:
一种软件解决方案,用于解释如何将系统分解为单元,以及单元如何相互关联,还包括这些单元的所有外部特性。
2.设计模式:
一种针对单个软件模块或少量模块而给出的一般性解决方案,它提供较低层次的设计决策。
3.设计公约:
一系列设计决策和建议的集合,用于提高系统某方面的设计质量。
(敏捷方法中的很多原则就属于设计公约)
4.设计:
将需求中的问题描述转述编程软件解决方案的创造性过程
5.概念设计:
侧重于系统的功能,用顾客理解的语言描述系统功能,通过解释看得见的系统外部特征使顾客理解系统的功能。
(确切的告诉客户系统要做什么)
6.技术设计:
描述了系统采用的工艺,用计算机行话和技术术语描述,对技术规格说明的技术性描述。
软件设计过程模型的几个阶段?
a)初始建模:
尝试可能的分解,根据需求描述的系统的关键特性等确定软件体系结构风格,进行系统级别的决策。
b)分析:
主要关注软件系统的质量属性(性能、安全性、可靠性等)、各种约束等。
(关注系统级别决策)
c)文档化:
确定了各个不同的模型视图
d)复审:
检查文档是否满足了所有需求
e)最后输出:
正式的(软件体系结构文档)
三种设计层次极其关系?
(229页)
a)体系结构设计:
由软件需求中的系统能力与系统部件关联起来而得到软件整体结构的过程。
b)代码设计:
各个部件的算法,数据结构的设计
c)运行设计:
最底层的设计-内存分配,数据格式,位模式,显示匹配等。
d)自顶向下的设计体系结构,然后进行代码设计,最后进入执行设计。
什么是模块化?
什么是抽象?
(238页)
a)模块化:
模块有清晰的输入和输出,设计目的明确,功能独立,可以做独立检测。
b)抽象:
对细节的隐藏成为抽象
论述设计用户界面应考虑的问题。
(242页)
设计界面要注意解决的要素:
寓意/比喻、思维模型、模型的导航规则、外观、感觉
文化差异问题(问题和解决方案)
用户爱好问题
5.5节----模块独立性----耦合与内聚的概念及各个层次划分?
(248----xxx页)
耦合:
两个软件部件之间的相互关联程度
内聚:
软件部件内部各组成成分的关联程度
模块独立性由耦合与内聚决定
举例说明耦合与内聚的基本分类。
以及各个分类的含义与特征(284页习题4,5)
a)耦合:
两个部件之间的相互关联的程度
i.非直接耦合:
模块之间没有信息传递
ii.数据耦合:
模块之间传递的是数据
iii.特征耦合:
模块间传递的是数据结构
iv.控制耦合:
模块间传递的是控制量
v.公共耦合:
不同模块访问公共数据
内容耦合:
一个模块直接修改另一个模块(模块A直接调用模块B的私有数据或直接转移到B模块中去)
b)内聚:
构成构建内部的“粘合”程度
i.偶然性内聚:
不相关的功能,过程,数据等出现在同一个部件中
ii.逻辑性内聚:
逻辑上相关或相似的功能或数据放置在同一个部件中
iii.时间性内聚:
部件各个部分要求在同一时间完成
iv.过程性内聚:
各部分有特定的次序
v.通讯性内聚:
各部分访问共享数据
vi.顺序性内聚:
各部分有输入输出的关系
vii.功能性内聚:
各部分组成单一功能
Chapter06
什么是设计模式?
设计模式:
是一套被反复使用的(多数人知晓并经过分类编目的)代码设计经验的总结,使用设计模式的目的是为了可重用代码,让代码更容易被他人理解并且保证软件质量。
OO设计的基本原则?
a)单一职责原则:
一个类只负责一个功能领域中的相应职责
b)重用原则
c)开闭原则
d)替换原则
e)依赖倒置原则
f)接口隔离原则
g)迪米特法则:
一个软件实体应当尽可能少的与其他实体发生相互作用
OO开发有何优势?
(291页)
1、语言的一致性:
可以使用同样的术语描述问题及其解决方案(类,对象,方法,属性和行为)
2、过程的一致性:
所有过程使用同样的术语,便于测试需求。
使用封装的数据和行为,组成独立的单元。
OO开发过程有几个步骤?
(292页)
a)OO需求分析
b)OO设计:
1、系统设计;2、程序设计;
c)OO编码和测试
熟悉用例图的组成和画法,用例的几个要素的含义,掌握用例图的实例解析方法(294页)
用例图、类图等对面向对象的项目开发的意义是什么?
熟悉类图中各个类之间的基本关系分类(303-305)
熟悉类图等的组成和画法(300-308页)
知道UML其他图示结构的基本用途。
Chapter07
在编写程序内部文档时,除了HCB外,还应添加什么注释信息?
(352-354页)
其他注释信息:
1、阶段性的注释
2、代码更改伴随的注释更新
3、注释应该有新信息
4、在写代码过程中写注释
什么是极限编程(XP)?
以及派对编程?
(357页)
极限编程:
是一种轻量级的软件开发方法论,属于敏捷开发方法。
其主要特征是要适应环境变化和需求变化,充分发挥开发人员的主动精神。
XP承诺降低软件项目风险,改善业务变化的反应能力,提高开发期间的生产力,为软件开发过程增加乐趣等。
两类参与者:
客户:
定义将要实现的系统之特征;描述测试计划;分配系统实现和测试的优先级。
程序员:
将客户的上诉要求给予编程实现。
派对编程属于主要的敏捷开发方法,其开发方式是两个程序员共同开发程序,且角色分工明确。
一个负责编写程序,另一个负责复审与测试。
两人定期交换角色。
Chapter08
几种主要的缺陷类型?
(367-368页)
a)算法缺陷:
算法的某些处理步骤或逻辑有问题,以至于软件部件对给定的输入数据无法生成正确的输出。
b)计算和精度缺陷:
某个算法或公式编码实现时出现错误或者最终结果达不到精度要求。
c)文档缺陷:
文档与实际做的事情不符
d)过载缺陷(压力缺陷):
在运行程序时,数据结构被填充的超过了他们规定的能力。
e)能力缺陷(边界缺陷):
当系统活动达到规定的极限时系统性能变得不可接受
f)时序性缺陷(协调缺陷):
在开发实时系统时,一个关键的问题是几个同时执行的或以仔细定义的序列相继执行的过程的协调性。
当代码协调这些事件不适当时就出现时序性缺陷。
g)性能缺陷:
当系统不能以需求规定的速度执行任务时出现的缺陷。
h)恢复性缺陷:
当遇到一次失败,而系统不能像设计人员希望的那样或者顾客要求的那样运转时出现的缺陷。
i)硬件和系统软件缺陷:
当提供的硬件或软件系统实际上并没有按照文档记录的操作条件和步骤运行时出现的缺陷。
j)代码标准和规程缺陷:
代码没有按照规程标准编写。
测试的各个阶段及其任务?
(372页图8.3)
a)单元测试:
对每个程序组件独立进行测试,与系统中其他组件分离
b)集成测试:
验证系统的组件是否按照系统和程序设计说明中描述的那样一起工作
c)功能测试:
对系统进行评价以判定继承的系统是否真的执行了需求说明中描述的功能
d)性能测试:
将系统与软件和硬件需求的其它部分作比较
e)验收测试:
根据客户的需求描述对系统进行检查
f)安装测试:
想确保系统按照它应该的方式来运
测试的方法----黑盒、白盒的概念?
(374)
a)黑盒测试:
把测试对象看做一个不了解其内容的闭盒(黑盒),测试时向闭盒提供输入,记录输出测试。
(人员完全不考虑程序内部的逻辑结构和内部特征,只依据程序的需求规格说明书检查程序的功能是否符合它的功能要求。
)
另外,测试时应该考虑让被测模块完成一切应做的事情,拒绝一切不应做的事情
i.黑盒测试参考的主要是系统设计和程序设计阶段文档
b)白盒测试:
把测试对象看做一个透明的盒子,可以根据测试对象的结构不同的方式进行测试。
(它允许测试人员利用程序内部的逻辑结构及有关信息或选择测试用例,对程序所有逻辑结构进行测试。
)
什么是单元测试?
什么是走查和检查?
(376页)
a)单元测试:
通读代码对其进行检查,试着找出算法,数据和语法上的错误;编译代码,消除剩余的语法错误,实测用例来证明输入是否正确的转换为相应的输出。
(将每个程序构建与系统中其他构件隔离,对其本身进行测试,这样的测试称为单元测试)
b)代码走查:
由程序员领导组成的评审小组审查,主要检查代码和文档中的错误,属于非正式的检查。
c)代码检查:
正式的审查,评审小组对照一个事先准备好的关注点列表来检查代码和文档。
黑盒白盒方法各自的分类?
测试用例的设计和给出方法(结合补充材料)
a)黑盒测试分类
i.等价分类法
ii.边界值分析法
iii.错误猜测法
iv.因果图法
b)白盒测试分类
i.逻辑覆盖法
1.语句覆盖:
每条语句至少执行一次
2.判定覆盖:
每一分支至少执行一次
3.条件覆盖:
判定中的每个条件均按“真”、“假”两种结果至少执行一次
4.条件组合覆盖
ii.路径覆盖法
1.边覆盖
2.节点覆盖
黑盒白盒方法的分类,各种覆盖方法等。
(课件和补充课件)
如何面对一个命题,设计和给出测试用例的问题。
(课件)
------课堂练习的测试题目和讲解内容
集成测试及其主要方法的分类?
(390-392)(驱动,桩的概念)
a)集成测试又称为组装测试,将单个组件组装为系统进行测试。
b)自底向上集成:
将组件合并起来以测试这个更大的系统,首先单独的测试系统的最底层的每个组件,然后测试调用了前面测试过的组件,反复采用这种方法直到所有的测试组件加入到测试中。
i.优点:
对面向对象的程序来讲,自底向上的测试通常是最为明智的选择。
每次一个对象与前面已经测试过的对象或对象集组合起来。
消息从一个对象发送给另一个对象,测试确保对象做出正确的响应。
ii.缺点
1.顶层构建通常是最重要的,但是却是最后测试的构件,这样使主要故障的发现推迟到测试的后期。
2.又是顶层的故障反映的是设计中的故障。
自底向上集成使得这些问题未在开发中尽快改正,而是等到最后期。
3.顶层构建通常控制或影响计时。
当系统的大部分处理都依赖与计时的时候,就很难自底向上的测试系统了。
c)自顶向下集成:
顶层通常是一个控制组件,测试时对他本身进行测试即可,然后将被测组件调用的组件集合起来,对这个更大的系统进行测试。
反复采用这种方法直到包含了所有测试组件,需要编写存根程序。
i.优点
1.可以依据被检查的功能来定义测试用例
2.任何关于功能可行性的设计故障或主要问题都可以在测试的早期进行处理,而不是等到测试的后期。
3.不需要驱动程序
ii.缺点
1.编写任何桩可能会比较困难,因为他们必须允许测试所有可能的结果
2.测试中可能需要大量的桩
驱动模块:
代替上级模块传递测试用例的程序)
桩模块:
代替下级模块的仿真程序
Chapter09
系统测试的主要步骤及各自含义?
(420页,图9.2)
a)功能测试:
由于开发者根据需求规格说明书测试。
检查集成的系统是否按照需求中指定的那样执行它的功能
b)性能测试:
由开发者根据需求规格说明书测试。
将集成的构件与非功能系统需求进行比较。
c)验收测试:
由开发者和用户根据需求文档进行测试。
他向客户保证构件的系统就是客户想要的系统。
d)安装测