软件工程121.docx
- 文档编号:17387593
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:24
- 大小:1.05MB
软件工程121.docx
《软件工程121.docx》由会员分享,可在线阅读,更多相关《软件工程121.docx(24页珍藏版)》请在冰点文库上搜索。
软件工程121
◆计算机软件定义:
计算机运行所需要的各种程序和数据的总称,包括操作系统、汇编程序、编译程序、数据库、文字编辑及维护使用手册等。
◆软件的特点:
(1)软件产品的生产主要是脑力劳动,还未完全摆脱手工开发方式,大部分产品是“定做”的。
(2)软件是一种逻辑产品,它与物质产品有很大的区别,它是脑力劳动的结晶。
(3)软件产品不会用坏,不存在磨损、消耗问题。
(4)软件产品的生产主要是研制。
。
(5)软件费用不断增加,软件成本相当昂贵
◆软件危机的定义:
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
包括:
1)软件“不能正常运行”。
2)主要是指如何开发软件?
3)怎样满足对软件日益增长的需求?
4)如何维护数量不断膨胀的现有软件?
◆软件危机的原因
在软件的开发和维护过程中存在着这么多的问题,一方面与软件本身的特点有关,另一方面也与软件的开发和维护的方法有关。
造成上述软件危机的原因概括起来有以下几方面:
(1)软件的规模愈发庞大。
(2)软件开发的管理困难。
(3)软件本身的独有特点确实给开发和维护造成一些客观困难,但是人们在长期的实践中也积累了不少成功的经验。
(4)软件开发和维护中许多错误认识和方法的形成可以归结与计算机发展早期软件开发的个体化特点。
(5)软件开发技术落后。
(6)生产方式落后。
(7)开发工具落后,生产率提高缓慢。
◆软件工程的定义
将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。
基本原理
1.用分阶段的生命周期计划严格管理
2.坚持进行阶段评审
3.实行严格的产品控制
4.采纳现代程序设计技术
5.结果应能清楚地审查
6.开发小组的人员应少而精
7.承认不断改进软件工程实践的必要性
◆软件工程原则:
为了达到软件系统开发目标,在软件开发过程中必须遵循下列软件工程原则:
抽象、信息隐藏、模块化、局部化、一致性、完整性和可验证性。
第二章
◆软件生命周期的定义:
任何一个软件都是从它的提出开始到最终被淘汰为止,有一个存在期。
软件生命周期一种典型的阶段划分为:
问题定义、可行性研究、需求分析、概要设计(总体设计)、详细设计、编码、测试和维护等八个阶段。
也有提出软件生命周期内划分成四个活动时期:
软件分析时期、软件设计时期、编码与测试时期以及软件运行与维护时期。
软件生命周期模型:
如瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型、基于知识的模型和变换模型。
瀑布模型是将软件生命周期各活动规定为依线性顺序联接的若干阶段的模型。
软件生命周期划分成七个阶段,包括:
可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。
每个阶段的工作完成都需要评审等技术确认。
瀑布模型为软件开发提供了一种有效的管理模型。
根据这一模式制定开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导。
因此它是以文档作为驱动、适合于需求很明确的软件项目开发的模型。
.瀑布模型的特点
瀑布模型是一种整体开发模型,在开发过程中,用户看不见系统是什么样,只有开发完成向用户提交整个系统时,用户就能看到一个完整的系统。
瀑布模型是以文档形式驱动的,为合同双方最终确认产品规定了蓝本,为管理者进行项目开发管理提供了基础,为开发过程施加了“政策”或纪律限制,约束开发过程中的活动。
)阶段间的顺序性和依赖性
顺序性:
依赖性:
2)推迟实现的观点
——逻辑设计和物理实现清楚区分
3)保证质量的观点
——文档和复审
它是一种理想的线性开发模式,缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题。
这些缺点最终可能导致开发出的软件并不是用户真正需要的软件,并且问题往往是在开发过程完成后才能发现,已为时太晚。
为此必须要进行返工,或者在运行中进行大量修改。
这种返工或修改付出的代价巨大。
同时,随着软件开发项目的规模日益扩大,瀑布模型缺乏灵活性的缺点引发的问题更为严重。
原型模型(PrototypingModel)则是借助一些软件开发工具或环境尽可能快地构造一个实际系统的简化模型。
原型模型的最大特点是:
利用原型法技术能够快速实现系统的初步模型,供开发人员和用户进行交流,以便较准确获得用户的需求;采用逐步求精方法使原型逐步完善,这是一种在新的高层次上不断反复推进的过程,它可以大大避免在瀑布模型冗长的开发过程中看不见产品雏形的现象。
适合采用原型模型的条件:
(1)首先得有快速建立系统原型模型的软件工具与环境。
(2)原型模型适合于那些不能预先确切定义需求的软件开发。
(3)原型模型适合于那些项目组成员(包括分析员、设计员、程序员和用户等)不能很好协同配合、交流或通信上存在困难的情况。
增量模型是快速分析并构造一个小的原型系统,满足用户的某些要求后,使用户在使用过程中受其启发,逐步确定各种需求。
1.增量构造模型
需求分析阶段和设计阶段按瀑布模型的整体方式开发。
但是编码阶段和测试阶段按增量方式开发。
这种模型的优点是开发中用户可以及早看到部分软件功能,发现问题,以便在开发其他软件功能时及时解决问题。
2.演化提交模型
先对某部分功能进行需求分析,然后按顺序进行设计、编码和测试,把该功能进行开发,提交用户直至所有功能全部增量开发完毕为止。
该模型是增量开发的极端形式,它不仅是增量开发也是增量提交,用户将最早收到部分软件,能及早发现问题,使修改扩充更容易。
3.快速原型模型
软件开发的早期阶段应该是一个学习与实践的过程,其活动包括开发人员和用户两个方面。
不仅要求他们合作,而且要有一个实际的工作系统。
用户开始虽然说不出未来系统的样子,但对现行系统可以非常熟练的使用。
基于这种思想的技术就是快速原型开发
旋模型综合了传统的软件生命周期模型和原型模型的优点。
将瀑布模型与增量模型结合起来,加入了两种模型均忽略了的风险分析,弥补了这两种模型的不足。
螺旋模型是一种风险驱动的模型。
在软件开发中,有各种各样的风险。
每个螺旋周期可分为四个工作步骤。
1.计划
确定软件产品各部分的目标,如性能、功能和适应变化的能力等;确定软件产品各部分实现的各种方案;确定不同方案的限制条件。
2.风险分析
对各个不同实现方案进行评估,对出现的不确定因素进行风险分析,提出解决风险的策略,建立相应的原型。
若原型是可运行的则可作为下一步产品演化的基础。
3.工程
若以前的原型已解决了所有性能和用户接口风险,而且占主要位置的是程序开发和接口控制风险,那么接下来的应是采用瀑布模型的方法,进行用户需求、软件需求、软件设计和软件实现等。
同时要对其作适当修改,以适应增量开发。
也可选择原型、模拟原型,导致了步骤的不同子集的使用。
4.用户评价
通过对产品的评价,提出修改意见。
对下一周期的软件需求、设计和实现进行计划。
软件生命周期模型可以按瀑布模型,先进行分析,后进行设计;也可以按螺旋模型或增量模型,交替地进行分析和设计。
不过更能体现两者之间关系特点的是近几年提出的喷泉模型。
喷泉模型以面向对象的软件开发方法为基础,以用户需求为动力,以对象作为驱动的模型。
它适合于面向对象的开发方法。
喷泉模型的特点:
(1)模型规定软件开发过程有5个阶段,即分析、设计、实现、测试与集成。
(2)模型从高层返回低层无资源消耗,反映了软件过程迭代的自然特性。
(3)以分析为基础,资源消耗呈塔型,在分析阶段消耗的资源最多。
(4)各阶段相互重叠反映了软件过程并行性。
(5)模型强调增量开发,它依据分析一点,设计一点的原则,并不要求一个阶段的彻底完成,整个过程是一个迭代的逐步提炼的过程。
(6)模型是对象驱动的过程,对象是所有活动作用的主体和项目管理的基本内容。
(7)模型在实现时,由于活动不同,可分为系统实现和对象实现,这既反映了全系统的开发过程,也反映了对象的开发和重用过程。
基于知识的模型是把瀑布模型和专家系统结合在一起。
在开发的各个阶段上都利用了相应的专家系统来帮助软件人员完成开发工作,使维护在系统需求说明一级上进行。
基于知识的模型是基于瀑布模型,在各阶段都有相应的专家系统支持。
其中支持需求活动的专家系统用来帮助减少需求活动中的二义性、不精确性和冲突易变的需求,这种专家系统要使用应用领域的知识,要用到应用系统中的规则,建立应用领域的专家系统来支持需求活动。
变换模型主要用于软件的形式化开发方法,从软件需求形式化说明开始,经过一系列变换,最终得到系统的目标程序。
可行性研究与其他的研究不同,这个阶段不是去开发一个软件项目,也不是解决问题。
而是研究这个软件项目是否值得去开发,其中的关键和技术难点是什么,问题能否得到解决,怎样达到目的等。
可行性研究的主要内容是对问题的定义,要初步确定问题的规模和目标,问题定义后,要导出系统的逻辑模型。
然后从系统的逻辑模型出发,选择若干供选择的主要系统方案。
可行性研究任务与步骤
(1)技术可行性研究。
根据客户提出的系统功能、性能及实现系统的各项约束条件,从技术的角度研究实现系统的可行性。
(2)经济可行性研究。
进行成本效益分析,评估项目的开发成本,估算开发成本是否会超过项目预期的全部利润。
分析系统开发对其他产品或利润的影响。
3)法律可行性研究。
研究在系统开发过程中可能涉及的各种合同、侵权、责任以及各种与法律相抵触的问题。
(4)开发方案的选择性研究。
提出并评价实现系统的各种开发方案,从中选出一种用于软件项目开发。
第三章
需求分析是软件定义时期的最后一个阶段,其基本任务是回答“系统必须做什么”这个问题。
——对目标系统提出完整、准确的具体要求。
需求分析的基本任务是要准确地理解旧系统,定义新系统的目标。
需求分析的任务还不是确定系统怎样完成它的工作,仅仅是确定系统要完成哪些工作,也就是对系统提出完整、准确、清晰、具体的要求。
这个时期的工作可以从可行性阶段的数据流图等文档出发,划分出系统必须完成的许多基本功能,研究这些功能并进一步具体化。
1.问题明确定义
(1)功能需求:
指所开发的软件必须具备什么样的功能。
(2)性能需求:
要开发软件的技术性能指标,如访问时延、存储容量、运行时间等限制。
(3)环境需求:
软件运行时所需要的硬件的机型、外设;软件的操作系统、开发与维护工具和数据库管理系统等要求。
(4)用户界面需求:
用户操纵界面的形式、输入/输出数据格式、数据传递的载体等。
(5)系统的可靠性、安全性、可移植性和可维护性等方面的需求。
2.导出软件的逻辑模型
分析人员根据前面获取的需求资料,要进行一致性的分析检查,在分析、综合中逐步细化软件功能,划分成各个子功能。
同时对数据域进行分解,并分配到各个子功能上,以确定系统的构成及主要成分。
最后要用图文结合的形式,建立起新系统的逻辑模型。
3.编写文档
通过分析确定了系统必须具有的功能和性能,定义了系统中的数据,描述了数据处理的主要算法。
应该把分析的结果用正式的文件记录下来,作为最终软件的部分材料。
编写文档的步骤如下:
(1)编写“需求说明书”,把双方共同的理解与分析结果用规范的方式描述出来,作为今后各项工作的基础。
2)编写初步用户使用手册,要从用户使用系统的角度来描述系统的用户要求。
(3)编写确认测试计划,作为今后确认和验收的依据。
(4)修改完善项目开发计划。
。
软件分析方法比较多,其中最有影响的是功能分解法、数据流法、信息建模法和面向对象的分析。
结构化分析步骤
1.建立现行系统的物理模型
通过了解现行系统的工作过程,对现行系统进行详细调查,收集资料,将看到的、听到的、收集到的信息和情况用图形或文字描述出来。
也就是用一个模型来反映自己对现行系统的理解,如画系统流程图(后面介绍)。
2.抽象出现行系统的逻辑模型
要构造新的逻辑模型就要去掉物理模型中非本质的因素(如物理因素),抽取出本质的因素。
这种逻辑模型反映了现行系统“做什么”的功能。
3.建立目标系统的逻辑模型
有了现行系统的逻辑模型后,就将目标系统与现行系统逻辑进行分析,比较其差别,即在现行系统的基础上决定变化的范围,把那些要改变的部分找出来,将变化的部分抽象为一个加工,这个加工的外部环境及输入输出就确定了。
4.进一步补充和优化
1)它所处的应用环境及它与外界环境的相互联系;
2)说明目标系统的人机界面;
3)说明至今尚未详细考虑的环节。
如出错处理、输入/输出格式、存储容量和响应时间等性能要求与限制。
数据流图要应用一些符号,有些表示的意义相同但是符号不一样。
归纳起来数据流图只有四种基本符号元素:
数据流(DataFlow)、数据处理(Process)、数据存储(DataStore)和外部实体(ExternalEntity)。
→:
箭头,表示数据流。
○:
圆或椭圆,表示加工。
=:
双杠,表示数据存储。
□:
方框,表示数据的源点或终点。
——总体设计:
把需求转换为数据结构和软件体系结构
——详细设计:
主要集中在体系结构表达式的细化,从而产生详细的数据结构和软件的算法表达式。
1.软件系统结构设计
(1)采用某种设计方法,将一个复杂的系统按功能划分成模块。
(2)确定每个模块的功能。
(3)确定模块之间的调用关系。
(4)确定模块之间的接口,即模块之间传递的信息。
(5)评价模块结构的质量。
2.数据结构及数据库设计
1)数据结构的设计
根据需求分析阶段对系统数据的组成、操作约束和数据之间的关系的描述,确定数据结构特性。
2)数据库的设计
一般的软件系统都有数据的存储,存储要借助数据库技术。
数据库的设计是指数据存储文件的设计。
设计包括以下三个方面:
(1)概念设计。
(2)逻辑设计。
(3)物理设计。
3.网络系统设计
如果采用的是网络环境,则要进行网络系统的设计。
要分析网络负荷与容量,遵照网络系统设计原则,确定网络系统的需求。
要进行网络结构设计,选择好网络操作系统,确定网络系统配置,制定网络拓扑结构。
4.软件总体设计文档
总体设计说明书是总体设计阶段结束时提交的技术文档。
按国标GB8576–88的《计算机软件产品开发文件编制指南》规定,软件设计文档可分为“总体设计说明书”、“详细设计说明书”和“数据库设计说明书”。
这些文档的内容与格式请参考有关资料。
5.评审
在该阶段,对设计部分是否完整地实现了需求中规定的功能、性能等要求,设计方案的可行性、关键的处理及内外部接口定义正确性、有效性以及各部分之间的一致性等,都一一进行评审。
耦合(Coupling)表示软件结构内不同模块彼此之间相互依赖(连接)的紧密程度,是衡量软件模块结构质量好坏的度量,是对模块独立性的直接衡量指标。
耦合强弱取决于模块间接口的复杂程度,进入或访问一个模块的点,以及通过接口的数据。
内聚标志一个模块内各个元素彼此结合的紧密程度,它是信息隐蔽和局部化概念的自然扩展。
简单地说,理想内聚的模块只做一件事情。
1.功能内聚
如果模块内所有处理元素属于一个整体,完成一个单一的功能,则称为功能内聚。
功能内聚是最高程度的内聚。
5.6.1数据流的类型
1.变换型数据流图
根据信息系统的模型,信息一般是以外部形式进入系统,通过系统处理后,然后离开系统。
从其过程可以得出,变换流的数据流图是一个线性结构。
变换型的数据流是由输入、变换(或称处理)和输出三部分组成。
.事务型数据流图
基本系统模型意味着变换流。
因此,原则上可以讲所有的信息流都可以归结为这一类。
图中的处理T称为事务中心,它完成下述任务:
(1)接收输入数据。
(2)分析每个事务,确定其类型。
(3)根据事务选择一条活动通路。
结构化设计方法转换的步骤:
(1)数据流图:
把数据流图转换成软件结构图前,设计人员要参照规范说明书,仔细地研究分析数据流图并参照数据字典,认真理解其中的有关元素,检查有无遗漏或不合理之处,进行必要的修改。
(2)确定数据流图类型:
通常将系统的数据流图视为变换流。
(3)找出变换中心:
输入流是一条路径,经过这条路径数据从外部形式转换为内部形式。
输出流则相反,从内部形式转换为外部形式。
(4)第一层分解:
如果是变换流,要把数据流图映射为一种输入、变换、输出的特殊结构。
(5)第二层分解:
这一步的任务是把数据流图中的各个变换映射成为相应的模块。
6)根据优化准则对软件结构求精。
(7)描述模块功能、接口及全局数据结构。
(8)复查,如果有错,转步骤
(2)修改完善,否则进入详细设计。
变换流的设计是将数据流图到程序结构图的转换。
当数据流图具有较明显的变换特征时,则按照下列步骤设计。
1.确定数据流图中的变换中心、逻辑输入和逻辑输出。
2.设计软件结构的顶层和第一层。
3.设计中、下层模块。
1)输入模块的下属模块的设计
2)输出模块的下属模块的设计
3)变换模块的下属模块的设计
4.设计的优化
(1)输入部分的求精
(2)输出部分的求精
(3)变换部分的求精
事务流的设计是从事务数据流图到程序结构的变换。
对于具有事务型特征的数据流图,则采用事务分析的设计方法。
(1)确定数据流图中的事务中心和加工路径。
当数据流图中的某个加工具有明显地将一个输入数据流分解成多个发散的输出数据流时,该加工就是事务中心。
从事务中心辐射出去的数据流为各个加工路径。
(2)设计软件结构的顶层和第一层。
事务处理中心和事务处理路径确定后,就可以确定它们的软件结构。
(3)进行事务结构中、下层模块的设计、优化等工作。
第四章
UML具备以下三种结构:
(1)静态对象结构(StaticObjectStructure)。
看到同一时刻、同时发生的同步操作。
(2)动态行为(DynamicBehavior)。
(3)系统部署(SystemDeployment)
第五章
需求来源
一、需求获取技术:
1)用户面谈;
2)需求讨论会;
3)问卷调查;
4)现场考察;
5)原型化方法;
6)基于用例的方法。
第六章
第八章
第九章
属于软件维护工作的活动不只是对软件中的错误进行修改,只要是因为以下的原因之一产生的活动都属于软件维护:
(1)对软件中的错误进行修改。
(2)因软件在使用过程中的软硬件环境发生变化,需要修改软件以适应这种变化。
(3)用户要求增加新的功能,提高软件的性能等。
(4)为适应新的工作要求而对软件部分或整体进行再工程(reengineering)。
维护的副作用:
维护的目的是为了延长软件的寿命并让其创造更多的价值,经过一段时间的维护,软件的错误被修正了,功能增强了。
但同时,因为修改而引入的潜伏的错误也增加了。
这种因修改软件而造成的错误或其他不希望出现的情况称为维护的副作用。
维护的副作用有编码副作用、数据副作用和文档副作用三种。
逆向工程:
是从源代码中抽取出来的设计信息。
作为逆向工程的评价,要求抽取出来的信息的抽象程度越高越好。
下面是逆向工程中得到的信息抽象层次(从低到高):
软件过程的设计表示、程序和数据结构信息、数据和控制流模型和实体-关系模型。
软件公司做逆向工程一般是自己的程序,有些是在多年以前开发出来的。
这些程序没有规格说明,对它们的了解很模糊。
因此,软件的逆向工程是分析程序,力图在比源代码更高抽象层次上建立程序表示的过程。
再工程(reengineering),它不仅能从已存在的程序中重新获得设计信息,而且还能使用这些信息来改建或重构现有的系统,以改进它的综合质量。
一般软件人员利用再工程重新实现已存在的程序,同时加进新的功能或改善它的性能。
第十一章
软件项目管理的对象是软件工程项目。
它所涉及的范围覆盖了整个软件工程过程。
1.启动一个软件项目
2.成本估算
3.风险分析
4.进度安排
5.追踪和控制
第十二章
12.1.1软件质量的定义
[定义12-1]
(1)软件产品具备满足给定需求的特性及特征的总体的能力。
(2)软件拥有所期望的各种属性组合的程度。
(3)用户认为软件满足他们综合期望的程度。
(4)软件组合特性可以满足用户预期需求的程度。
16.3.1软件质量保证的概述
1.软件质量保证(SQA)
采用一定的技术、方法和工具,来处理和调整软件产品满足需求时的相互关系,以确保软件产品满足或超过在该产品的开发过程中所规定的标准。
2.质量保证系统(QAS)
提供质量保证措施和策略的总框架,包括机构的建立和发行过程,职责的分配及选择执行质量保证的工具。
3.质量保证计划
软件质量度量是对软件所具有的影响其属性所进行的定量测量
软件质量度量时必须满足的质量标准
客观性:
如果不存在来自测试者对度量的主观影响,则度量是客观的。
可靠性:
如果在重复度量中,在同样条件下达到相同的效果,则认为度量是可靠的。
适用性:
如果度量结果能够明确地说明质量特性时,则可以说度量是适用的。
标准化:
标准化是指必须有一个可以明确表示度量结果的标度,当这个可比较的标度存在时,度量被认为是达到标准化的。
可比较性:
当某项度量与其他度量相关时,则度量具有可比较性。
经济性:
当度量是在低成本下进行时,它是经济的。
度量的经济与否取决于度量过程的自动化程度和度量的数据量,使用工具可以大大改善软件度量的自动化水平。
有效性:
有效形式是最难证明的。
但是不说明度量标准是有效时,就不能客观的评价软件质量。
软件质量度量可以划分为过程度量和产品度量。
1.过程度量,是度量开发过程和维护过程或开发环境的定量属性。
例如,说明开发人员具有多少年的编程经验和开发过程的成本等。
2.产品度量,是度量产品的定量属性。
产品度量不涉及有关产品生产的任何方面或形成产品当前实际状况的原因。
产品度量包括度量产品的大小,如程序行数或程序中的符号数;结构的复杂性,如控制流程、嵌套深度和递归深度等;数据结构的复杂性,包括使用的变量数和数据文件等产品的应用领域,如工资清单。
也可能是以上各项的组合。
软件质量评价采用软件复杂性度量。
复杂性度量包括静态度量和开发度量。
静态度量是在给定时间内测量软件产品的质量,它可以分为:
(1)软件产品的规模。
(2)软件产品程序控制结构的度量。
(3)数据结构的度量。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 121
![提示](https://static.bingdoc.com/images/bang_tan.gif)