软件工程基础知识Word格式文档下载.docx
《软件工程基础知识Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件工程基础知识Word格式文档下载.docx（38页珍藏版）》请在冰豆网上搜索。
数据库说明书
用户手册
修订的测试计划（测试的策略、方法、步骤）
4.4.4详细设计阶段
详细设计说明书
4.4.5系统测试阶段
系统测试计划文档
五．有哪些主要生存期模型？
瀑布模型、原型开发模型（快速原型模型、演化模型、增量模型）、螺旋模型、喷泉模型、
5.1瀑布模型
瀑布模型（传统的软件周期模型）严格遵循软件生命周期各阶段的固定顺序：
计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段，整个模型就像一个飞流直下的瀑布。
优点：
可强迫开发人员采用规范的方法，严格规定了各阶段必须提交的文档；
要求每一阶段结束后，都要进行严格的评审。
与它最相适应的开发方法是结构化方法。
缺点：
不适应用户需求的改动。
5.2原型模型
5.2.1快速原型模型
快速原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。
主要用于需求分析阶段。
不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法，所以不能定义完善的文档。
特征：
简化项目管理、尽快建立初步需求、加强用户参与和决策。
具有广泛技能水平的原型化人员是原型实施的重要保证。
原型化人员应该是具有经验与才干、训练有素的专业人员。
衡量原型化人员能力的重要标准是他是否能够从用户的模糊描述中快速获取需求。
5.2.2演化模型
在快速原型模型中，原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。
而演化模型应用于整个软件开发过程，是从初始模型逐步演化为最终软件产品的渐进过程。
也就是说，快速原型模型是一种“抛弃式”的原型化方法，而演化模型则是一种“渐进式”的原型化方法。
5.2.3增量模型
增量模型主要用于设计阶段，把软件产品划分为一系列的增量构件，分别进行设计、编程、集成和测试。
新的增量构件不得破坏已经开发出来的产品。
5.2.4原型模型小结
从下面的有关原型化方法的叙述中，选择出正确的叙述：
（1）快速原型方法是一种企图克服传统软件周期模型缺点的开发方法。
（2）在用户的数据资源没有得到很好地组织和管理的时候，应该使用原型化方法。
（3）在用户没有明确地肯定其需求的时候，应该使用原型化方法。
（4）在用户不希望把自己的时间花在软件开发过程中的时候，应该使用原型化方法。
（5）使用原型化方法时应该使用第三代编程语言。
（6）原型化加强了开发过程中用户的参与和决策。
（7）原型化方法大致可分为三类：
抛弃式、演化式和递增式。
（8）原型化方法大致可分为演化式和递增式。
（9）采用原型化方法时，软件的开发成本较高。
（10）采用原型化方法时，关键的因素是建立原形的速度，而不是原形运行的效率。
5.3螺旋模型
螺旋模型综合了瀑布模型和原型模型中的演化模型的优点，还增加了风险分析。
螺旋线第一圈的开始点可能是一个概念项目。
从第二圈开始，一个新产品开发项目开始了，新产品的演化沿着螺旋线进行若干次迭代，一直转到软件生命期结束。
5.4喷泉模型
喷泉模型主要用于描述面向对象的开发过程。
喷泉一词体现了面向对象开发过程的迭代和无间隙特征。
六．软件过程基础知识
6.1软件过程
软件过程是指人们用于开发和维护软件及相关产品的一系列活动，包括软件工程过程和软件管理过程。
6.2评估工具
软件过程的评估，通常采用软件能力成熟度
模型（CapabilityMaturityModel，CMM）。
CMM1.1的5个等级（由低级到高级）：
初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力，管理是反应式（消防式）的。
可重复级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。
制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准化软件过程。
所有项目均使用经标准、裁减的标准软件过程来开发和维护软件。
已管理级
收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制。
优化级
加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能持续不断地改进。
七．软件工程项目管理基本知识
软件项目管理开始于任何技术活动之前，并且贯穿于整个的软件生命周期。
软件工程项目管理一般分为时间管理、成本管理、人力资源管理、风险管理。
7.1时间管理
7.1.1Gantt图
是一种简单的水平条形图，它以水平线段表示子任务的工作阶段，线段的起点和终点分别对应着子任务的起始时间，线段长度指示完成该任务所需要的时间。
甘特图的优点：
直观简明、易学易绘、可从图上清楚地标出子任务间的时间对比，但它也有
缺点：
（a）不能显示地描绘各项彼此间的依赖关系；
（b）进度计划的关键部分不明显，难以判断哪些部分应当是主攻和主控的对象；
（c）计划中有潜力的部分以及潜力的大小不明确，往往造成潜力的浪费。
7.1.2PERT网图与关键路径
PERT网图是一个由箭头（标识任务）和结点（标识事件）组成的有向图。
将网络方法用于工作计划安排的评审和检查。
PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的依赖关系，即哪些任务完成后才能开始另一些任务，以及如期完成整个工程的“关键路径”。
关键路径（CriticalPath）是由一连串的任务所组成的链，距离最大的一条路径。
软件项目的管理人员应该密切注视关键任务的进展情况。
如果希望缩短工期，只有往关键任务中增加资源才会有效果。
八．模块化基本知识
模块是指执行某一特定任务的数据和可执行语句程序元素的集合，通常是指可通过名字来访问的过程、函数、子程序或宏调用等。
模块化就是将一个待开发的软件划分成若干个可完成某一子功能的模块，每个模块可独立地开发、测试，最后组装成完整的程序。
8.1模块特性
8.1.1可分解性
如果一种设计方法提供了将问题分解成子问题的系统化机制，它就能降低整个系统的复杂性，从而实现一种有效的模块化解决方案。
8.1.2可组装性
如果一种设计方法使现存的（可复用的）设计构件能被组装成新系统，它就能提供一种不需要一切从头开始的模块化解决方案。
8.1.3可理解性
如果一个模块可以作为一个独立的单位（不用参考其他模块）被理解，那么它就易于构造和修改。
8.1.4连续性
如果对系统需求的微小修改只导致对单个模块，而不是整个系统的修改，则修改引起副作用就会被最小化。
8.1.5保护性
如果模块内部出现异常情况，并且它的影响限制在模块内部，不会影响其他模块，则错误引起的副作用就会被最小化。
8.2模块与模块的耦合性
耦合是对一个软件结构内不同模块之间互连程序的度量。
耦合可以分成下列几种，它们之间的耦合度由高到低排列。
8.2.1内容耦合
直接操作或修改另一模块的数据，或不通过正常入口转入另一个模块。
软件设计时应坚决禁止内容耦合，应设计成单入口、单出口的模块，避免病态连接。
8.2.2公共耦合
多个模块引用同一全局数据区。
8.2.3外部耦合
模块与软件以外的环境有关联。
例如，输入输出把一个模块与特定的设备、格式、通信协议耦合在一起。
8.2.4控制耦合
一模块明显把开关量、名字等信息送入另一模块，控制另一模块的功能。
8.2.5标记耦合
两个模块之间通过传递公共指针或地址相互作用的耦合。
8.2.6数据耦合
模块间通过传递数据交换信息。
8.2.7非直接耦合（无耦合）
模块间无任何关系，独立工作
原则上讲，模块化设计总是希望模块之间的耦合表现为非直接耦合方式。
在以上耦合中，耦合度从高到低，内容耦合度最高，非直接耦合度最低。
8.3模块的内聚性
内聚是指一个模块内各个元素彼此结合的紧密程序，它是信息隐蔽和局部的概念的自然扩展。
设计时应该力求高内聚，理想内聚的模块应当恰好做一件事情。
1）.偶然内聚：
一个模块的各成分之间毫无关系。
比如：
一组语句在程序的多处出现，为了节省内存空间，这些语句放在一个模块中，该模块的内聚是偶然内聚的。
2）逻辑内聚：
把几种逻辑上相关的功能组放在同一模块中。
3）瞬时内聚（时间内聚）：
一个模块所包含的任务必须在同一时间间隔内执行，例如初始化模块。
4）过程内聚：
一个模块的处理元素是相关的，而且必须按特定的次序执行。
5）通信内聚：
一个模块的所有成分都结合再同一个数据结构上。
6）顺序内聚：
模块的成分同一个功能密切相关，且输出，作为另外一个成分的输入。
7）功能内聚：
模块内的所有成分属于一个整体，完成单一的功能。
在以上的内聚中，内聚度从低到高，偶然内聚度最低，功能内聚度最高。
模块的高内聚、低耦合的原则称为模块独立原则，也称为模块设计的原则。
8.4模块的深度、宽度、扇出与扇入
深度：
表示软件结构中控制的层数。
宽度是软件结构中同一个层次上的模块总数的最大值
一个模块的扇入是指直接调用该模块的上级模块的个数。
一个模块的扇出是指该模块直接调用的下级模块的个数。
设计原则：
低扇出、高扇入。
8.5模块作用域和控制域
软件设计时，模块的作用域应在控制域之内。
8.6模块化基础知识小结
通过模块的合并和分解，降低模块的耦合度。
模块的扇入应尽量大，扇出应尽量小。
扇入大表示模块的重用性高，利用率高。
扇出大表示模块的复杂度高。
所以要高扇入，低扇出。
要将模块的作用范围限制在模块的控制范围之内。
降低模块之间的复杂性，避免“病态连接”。
九．什么是软件开发方法？
有哪些主要方法？
软件开发方法：
使用已定义好的技术集及符号表示习惯组织软件生产的过程。
结构化方法、面向对象方法、JACKSON方法。
9.1结构化方法学
结构化方法学也称为生命周期方法学（瀑布模型方法），是一种面向数据流的需求分析方法。
它的基本思想是自顶向下逐层分解。
为了在需求改变时对软件的影响较小，结构化分析时应该使程序结构与问题结构相对应。
常用工具：
数据流图（DFD）、数据字典（DD）、实例—关系图（E—R图）及描述加工处理的结构化语言、判定表、判定树。
9.1.1数据流图（DFD图）
DFD的基本成分
数据流图主要由4种成分组成：
数据流（dataflow）：
由一组固定成分的数据组成，表示数据的流向。
它可以从源、文件流向加工，也可以从加工流向文件和宿，还可以从一个加工流向另一个加工。
通常每个数据流必须有一个合适的名字，一方面是为了区别，另一方面也给人一个直观的印象，使人容易理解这个数据流的含义。
但流向文件或从文件流出的数据流不必命名，因为这种数据流的组成部分就是相应文件的组成部分。
加工（process）：
描述了输入数据流到输出数据流之间的变换，也就是输入数据流做了什么处理后变成了输出数据流。
每个加工有一个名字和一个编号。
编号反映了该加工位于分层DFD的哪个层次和哪张图中以及它是哪个加工分解出来的子加工。
文件（file）：
可以表示数据文件，也可以表示一个数据记录。
流向文件的数据流表示写文件，流出文件的数据流表示读文件，双向箭头表示对文件既读又写。
每个文件都有一个文件名。
源/宿（source/sink）：
源是指系统所需数据的发源地，宿（也称数据池）是指系统所产生的数据的归宿地。
无论源或宿，均对应于外部实体，在框内应加注实体的名字，在一个软件各级软件系统中，有些源和宿可以是一个外部实体，外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地和系统所产生数据的归宿地。
分层数据流图
一套分层的的数据流图由顶层、底层、和中间层组成。
画分层数据流图基本原则与注意事项
a.自外向内，自顶向下，逐层细化，完善求精。
b.保持父图与子图的平衡。
也就是说，父图中某加工的输入数据流中的数据必须与它的子图的输入数据流在数量和名字上相同。
c.保持数据守恒。
也就是说，一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据。
d.加工细节隐藏。
根据抽象原则，在画父图时，只需画出加工和加工之间的关系，而不必画出各个加工内部的细节。
e.简化加工间关系。
在数据流图中，加工
间的数据流越少，各加工就越相对独立，所以应尽量减少加工间输入输出数据流的数目。
f.均匀分解。
应该使一个数据流中的各个加工分解层次大致相同。
g.适当地为数据流、加工、文件、源/宿命名，名字应反映该成分的实际意义，避免空洞的名字。
h.忽略枝节。
应集中精力于主要的数据流，
而暂不考虑一些例外情况、出错处理等枝节性问题。
i.表现的是数据流而不是控制流。
j.每个加工必须既有输入数据流，又有输
出数据流.在整套数据流图中，每个文件必须既有读文件的数据流又有写文件的数据流，但在某一张子图中可能只有读没有写或者只有写没有读。
小结：
一个软件系统，其数据流图往往有多层。
如果父图有N个加工（Process），则父图允许有0～N张子图，但是每张子图只能对应一张父图。
在一张DFD图中，任意两个加工之间可以有0条或多条名字互不相同的数据流；
在画数据流图时，应该注意父图和子图的平衡，即父图中某加工的输入输出数据流必须与其输入输出流在数量和名字上相同。
DFD信息流大致可分为两类：
交换流和事务流。
9.1.2数据字典
数据字典是关于数据的信息的集合也就是对
数据流图中包含的所有元素的定义的集合。
组成部分：
a.数据项条目
b.数据流条目
c.文件条目
d.加工条目
加工条目是对数据流图中每一个不能再分
解的基本加工的精确说明。
对于加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树和判定表。
9.1.3结构化语言
结构化语言实际上是一种半形式化语言，
它的结构通常可分为内外两层。
外层接近于形式化语言，而内层近似于自然语言的描述。
9.1.4实体——关系图（E—R图）
实体——关系图（Entity-Relabionship
Diagram），简称E-R图，包含实体、关系和属性等3种基本成分。
通常用矩形框代表实体，并用直线把实体（或关系）与其属性连接起来。
E-R图通常用于数据库应用系统。
9.2结构化设计
结构化设计通常可分为概要设计和详细设计，但是主要用于概要设计阶段。
概要设计的任务是确定软件系统的结构，进行模块划分，确定每个模块的功能、接口以及模块间的调用关系。
详细设计的任务是为每个模块设计实现的细节。
9.2.1概要设计
经过需求分析阶段的工作，系统必须“做什么”已经清楚了，概要设计的基本目的就是回答“概括地说，系统应该如实现？
”这个问题。
概要设计的重要任务：
将一个复杂的系统按功能化分为模块、确定每个模块的功能、确定模块之间的调用关系、确定模块之间的接口（模块之间传递的信息）、评价模块的结构质量。
1.软件结构图形工具
结构化设计方法（SD）方法采用结构图（StructureChart）、层次图和HIPO图描述软件结构。
结构图的主要成分有模块、调用和数据，结构图中的模块用矩形表示，在矩形框内可标上模块的名字。
模块间如有箭头或直线相连，表明它们之间有调用关系。
层次图用来描绘软件的层次结构.层次图中一个矩形框代表一个模块,方框间的连线表示模块间的调用关系.
HIPO图实际上就是层次图加输入/处理/输出图.HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”，是在层次图里出了最顶层的方框之外，每个方框都加了编号。
编号规则和数据流图的编号规则一样。
9.2.2详细设计
概要设计已经确定了每个模块的功能和接口，详细设计的任务就是为每个模块设计其实现的细节。
详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，得出对目标系统的精确描述。
1.详细设计阶段的内容
为每个模块进行详细的算法设计。
为模块内部的数据结构进行设计。
对数据库进行物理设计。
其他
详细设计工具主要包括程序流程图（系统流程图）、盒图（N-S图）、PAD图和伪码（PDL）。
2．人机界面设计
人机界面的设计质量，直接影响用户对软件产品的评价。
界面的美观、灵活和风格都很重要，但人机界面设计中最重要的也是最基本的目标是软件的易操作性。
人机界面设计主要包括系统响应时间、用户帮助设计、出错信息处理和命令交互设计等几个方面。
9.3Jackson方法
上面讲的结构化设计方法是面向数据流的，另外还有一种面向数据结构的设计方法，
Jackson方法是最著名的面向数据结构的设计方法,而不是面向数据流的设计方法。
Jackson方法的基本步骤是：
建立系统的数据结构；
以数据结构为基础，对应地建立程序结构；
列出程序中要用到的各种基本操作，再将这些操作分配到程序结构适当的模块中。
9.4面向对象分析方法（00A）
十．软件工具
软件工具是指用于辅助软件开发、运行、维护、管理、支持等过程中的活动的软件。
通常也称为CASE（ComputerAidedSoftwareEngineering,计算机辅助软件工程）工具。
按软件过程的活动分为软件开发工具、软件维护工具和软件管理工具等。
十一.软件开发环境
集成型开发环境通常可由工具集和环境集成机制两部分组成。
这种环境应具有开放性和可裁减性。
环境集成机制主要有数据集成机制、控制集成机制和界面集成机制。
十二.软件质量管理基础知识
12.1软件质量
软件质量模型可从软件功能性、可靠性、可用性、效率、可维护性、可移植性6个方面来衡量。
（1）功能性
与功能及其指定的性质的一组软件属性。
（2）可靠性
软件在规定的一段时间内和规定的条件下保持其性能水平有关的一组软件属性。
也可以称为在规定的条件下和规定的时间间隔内，软件实现其规定功能的概率。
（3）可用性
与使用的难易程序及规定或隐含用户对使用
方式所做的评价有关的软件属性。
（4）效率
与在规定条件的性能水平与所用资源量之间的关系有关的一组软件属性。
（5）可维护性
与软件维护的难易程序有关的一组软件属性。
（6）可移植性
软件可从某一环境转移到另一环境的能力有关的一组属性。
即软件从一个计算机系统转换到另一个计算机系统运行的难易程度是指软件的可移植性。
为了提高可移植性，应注意提高软件的设备独立性。
采用表格驱动程序有助于提高设备独立性。
为了提高可移植性，还应有完备的文档资料。
使用C语言开发的系统软件具有较好的可移植性。
12.2软件质量保证
软件质量保证的主要困难表现在以下几个方面：
1）软件开发的管理人员往往关心项目开发的成本与进度。
因为成本和进度是显而易见的，而软件质量则难以度量。
如果软件开发的管理人员对交付的软件含有多少隐患并不必负什么责任，他们必定没有太高的热情去控制开发的质量，更不必说保证质量并不容易且代价昂贵。
开发人员的习惯一旦形成难以改变，他们的形为也难于控制，而高质量的软件产品，又主要取决于参与开发的人员。
复杂的软件项目需要许多技术人员和管理人员参与，对问题的不同认识和误解如不能及时消除必然影响软件质量。
软件开发人员的频繁流动，特别是骨干开发人员的流失，也会使软件质量受到一定的影响。
软件质量的保证手段：
开发初期制定质量保证计划，并在开发中坚持实行。
开发前选定或制定开发标准或开发规范，并遵照实施。
从开始就选择分析设计方法和工具，形成高质量的分析模型和设计模型。
严格执行阶段评审，以便及时发现问题。
各个开发阶段的测试。
对软件的每次“变动”都要经过申请、评估、批准、实施等步骤。
软件质量特性的度量化。
软件生存期的各阶段都要完整的文档。
十三.软件测试
软件测试的费用已经超过软件开发费用的30%左右。
“高产”测试是指用少量的测试用例，发现被测试程序尽可能多的错误。
13.1软件测试经过的步骤
单元测试－>
集成测试－>
确认测试－>
系统测试
13.2测试与软件开发各阶段的关系
单元测试对程序中每一个程序单元进行测试，检查各个模块是否争取实现规定的功能，从而发现模块在编码中或算法中的错误，该阶段涉及编码和详细设计文档。
集成测试是为了检查与设计相关的软件体系结构的有关问题，也就是检查概要设计是否合理有效。
确认测试主要是检查已实现的软件是否满足需求规格说明书中已确定了的各种需求。
系统测试是把已确认的软件与其他系统元素（如硬件，其他支持软件、数据、人工等）结合在一起进行测试，以确定软件是否可以支付使用。
13.3白盒测试
白盒测试又称为结构测试。
可以把程序看成装在一个透明盒子里，测试者（一般为编程者）完全知道程序的结构和处理算法。
按照程序内部逻辑设计测试用例，检测程序中的主要执行通路是否能按预定要求正常工作。
白盒测试多用于单元测试阶段。
逻辑覆盖是主要的白盒测试技术。
白盒测试时，确定测试数据应根据程序的内部逻辑和指定的覆盖方式。
采用一下几种逻辑覆盖标准：
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
条件组合覆盖
路径覆盖
满足条件组合覆盖测试用例，也一定满足判定条件覆盖。
因此，条件组合覆盖是上述五种覆盖标准中最强的一种。
13.4黑盒测试
黑盒测试，又称为功能测试。
把软件看做是一个不透明的黑盒子，完全不考虑（或不了解）软件内部结构和处理算法，它只检测软件功能是否能按照软件需求说明书的要求正常使用，软件是否能适当的接受输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息（例如文件和数据库）的完整性等。
常用的黑盒测试技术包括等价类划分，边值分析、错误推测和因果图等。
其中等价类划分和边界值分析法方法最常用。
如果两者结合使用，更有可能发现软件中的错误。
13.4灰盒测试
灰盒测试介于白盒测试和黑盒测试之间，它把软件看做是一个半透明的灰盒子，结合考虑软件的内部结构和外部功能
升级会员 