东南大学计算机科学与工程学院软件工程期末重点总结

合集下载

2021最新版《软件工程》期末考试重点背诵内容

2021最新版《软件工程》期末考试重点背诵内容

1.什么是软件危机及其表现?答:软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件危机包含下述两方面的问题:如何开发软件,以满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。

表现:(1)对软件开发成本和进度的估计常常很不准确。

(2)用户对“已完成的”软件系统不满意的现象经常发生。

(3)软件产品的质量往往靠不住。

(4)软件常常是不可维护的。

(5)软件通常没有适当的文档资料。

(6)软件成本在计算机系统总成本中所占的比例逐年上升。

(7)软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。

2.什么是软件工程?答:软件工程是指导计算机软件开发和维护的一门工程学科,由需求分析、总体设计、详细设计、编码、测试、维护和演化等一系列分工明确的活动组成。

采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。

3.什么是瀑布模型方法?(有利于大型软件开发过程中人员的组织及管理)答:按照时间顺序依次进行可行性分析、项目计划、需求分析、概要设计、详细设计、编码与单元测试、集成测试、确认验证、运行与维护等几个阶段进行软件开发。

图1 瀑布模型(软件生命周期模型)4.瀑布模型方法的优缺点:其优点体现在:(1)促进软件开发的工程化。

(2)提高了软件的成功率和质量。

(3)加强了软件开发的管理过程。

(4)强调了文档的作用,保护了软件开发商的利益。

其缺点体现在:(1)瀑布模型僵化的划分阶段、缺乏灵活性,对于软件需求不明确或不准确的问题,由于其开发模型是线性的,所以瀑布模型的风险控制能力较弱。

一方面用户只有等到整个过程的后期才能见到开发成果,中间提出的变更要求很难响应。

另一方面体现在早期的错误可能要等到开发后期的测试阶段才能发现,这样会带来严重的后果。

(2)增加了软件开发的工作量,由于开发过程各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。

软件工程期末复习重点

软件工程期末复习重点

1、什么是软件工程在《计算机科学技术百科全书》中软件工程是应用计算机科学、数学及管理科学等原理,开发软件的工程。

2、软件生存周期分哪几个阶段分别简述各个阶段的任务。

答:软件生存周期有计算机系统工程、需求分析、设计、编码、测试、运行和维护6个阶段。

A 计算机系统工程的任务是确定待开发软件的总体要求和范围,以及该软件与其他计算机系统元素之间的关系,进行成本估算,做出进度安排,并进行可行性分析,即从经济、技术、法律等方面分析待开发的软件是否有可行的解决方案,并在若干个可行的解决方案中做出选择。

B 需求分析主要解决待开发软件要“做什么”的问题,确定软件的功能、性能、数据、界面等要求,生成软件需求规约。

C 软件设计只要解决待开发软件“怎么做”的问题。

软件设计通常可分为系统设计和详细设计。

系统设计的任务是设计软件系统的体系结构,包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通信,同时设计全局数据结构。

详细设计的任务是设计各个组成成分的实现细节,包括局部数据结构和算法等。

D 编码阶段的任务是用某种程序设计语言,将设计的结果转换为可执行的程序代码。

E测试阶段的任务是发现并纠正软件中的错误和缺陷。

测试主要包括单元测试、集成测试、确认测试和系统测试。

F软件完成各种测试后就可交付使用,在软件运行期间,需对投入运行的软件进行维护,即可发现了软件中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时,对软件进行修改。

3、简述各类软件过程模型的特点。

答:典型的软件过程模型有:瀑布模型、演化模型(增量模型、原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式方法模型等。

A瀑布模型中,上一阶段的活动完成并经过评审后才能开始下一阶段的活动,其特征是:接受上一阶段活动的结果作为本阶段活动的输入;依据上一阶段活动的结果实施本阶段应完成的活动;对本阶段的活动进行评审;将本阶段活动的结果作为输出。

B 增量模型将软件的开发过程分成若干个日程时间交错的线性序列,每个线性序列产生软件的一个可发布的增量版本,后一个版本是对前一个版本的修改和补充,重复增量发布的过程,直至产生最终的完善产品。

软件工程重点总结(5篇)

软件工程重点总结(5篇)

软件工程重点总结(5篇)第一篇:软件工程重点总结软件的定义:软件是计算机系统中与硬件相互依存的另一部分,软件包括程序、数据及其相关文档的完整集合。

在结构化程序设计时代,程序的最小单位是向对象程序设计时代,程序的最小单位是类,在类中封装了相关的数据及指令代码。

软件的特性:形态特性、智能特性、开发特特性、维护特性、废弃特性、应用特性。

软件的分类:系统软件、应用软件、支撑软软件危机的表现:软件开发周期长、成本高、软件危机发生的原因:(1)缺乏软件开发的工作的计划很难制定。

(2)软件人员与用户的交流存在障碍。

(3)软件开发过程不规范,缺少方法论和规范的指导,开发人员各自为战,缺少整体的规划和配合,不重视文字资料工作,软件难以维护。

(4)随着软件规模的增大,其复杂性往往会呈指数级升高。

(5)缺少有效的软件测评手段,提高用户的软件质量差,在运行中暴露出大量的问题,轻者影响系统的正常使用,重者发生事故,甚至造成生命财产的重大损失。

首次提出“软件工程”的概念的时间是1968年。

按工程化的原则和方法组织软件开发工作是软件工程的定义:软件工程是指导软件开发和维护的工程性学科,它以计算机科学理论和其他相关学科的理论为指导,采用工程化的概念、原理、技术和方法进行软件的开发和维护,把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来,以较少的代价获得高质量的软件并维护它。

软件工程的目标是运用先进的软件开发技术衡量软件的质量的六个特性:功能性、可靠软件生存期的三个时期:软件定义、软件开定义时期的主要任务是解决“做什么”的问地满足用户的需要。

开发过程中的典型文档包括:软件需求规格计说明书、用户手册。

各个阶段所要完成的基本任务:问题定义与可行性研究、需求分析、软件设计、程序编码和单元测试、集成测试和系统测试、软件运行和维护。

典型的软件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等(喷泉模型)。

瀑布模型的特点:1)阶段间具有顺序性和依赖性。

(完整版)软件工程期末考试复习总结知识点+必考题型,推荐文档

(完整版)软件工程期末考试复习总结知识点+必考题型,推荐文档

软件工程复习资料1.软件危机产生的原因(1)软件不同于硬件,它是计算机系统的逻辑部件而不是物理部件。

在写出程序代码并在计算机上试运行之前软件开发过程的进展情况较难衡量。

很难检验开发的正确性且软件开发的质量也较难评价。

因此控制软件开发过程相当困难。

此外在软件运行过程中发现错误很可能是遇到了一个在开发期间引入的但在测试阶段没有能够检测出来的错误,所以软件维护常常意味着修改原来的设计。

这样维护的费用十分惊人,客观上使得软件较难维护。

(2)软件开发的过程是多人分工合作分阶段完成的过程,参与人员之间的沟通和配合十分重要。

但是,相当多的软件开发人员对软件的开发和维护存在不少错误的观念。

在实践的过程中没有采用工程化的方法,或多或少采用了一些错误的方法和技术。

这是造成软件危机的主要原因。

(3)开发和管理人员只重视开发而轻视问题的定义,使软件产品无法满足用户的要求。

对用户的要求没有完整准确的认识就急于编写程序。

这是许多软件开发失败的另一主要原因。

事实上,许多用户在开始时并不能准确具体地叙述他们的需要。

软件人员需要做大量深入细致的调查研究工作,反复多次与用户交流信息,才能真正全面、准确、具体地了解用户的要求。

(4)软件管理技术不能满足现代软件开发的需要,没有统一的软件质量管理规范。

首先是文档缺乏一致性和完整性,从而失去管理的依据。

因为程序只是完整软件产品的一个组成部分。

一个软件产品必须由一组的配置组成,不能只重视程序而应当特别重视软件配置。

其次,由于成本估计不准确,资金分配混乱,人员组织不合理,进度安排无序,导致软件技术无法实施。

(5)在软件的开发和维护关系问题上存在错误的观念。

软件维护工作通常是在软件完成之后进行的,因此是极端艰巨复杂的工作,需要花费很大的代价。

所以做好软件的定义工作是降低软件成本,提高软件质量的关键。

如果软件人员在定义阶段没有正确、全面地理解用户要求,直到测试阶段才发现软件产品不完全符合用户的需要,这时再修改就为时已晚了。

软件工程期末复习重点

软件工程期末复习重点

1.软件危机的介绍在计算机软件的开发和维护过程中所遇到的一系列严重问题。

2.产生软件危机的原因与软件本身特点有关:软件开发与维护的方法不正确有关:3.消除软件危机的途径4.软件生命周期由软件定义、软件开发和运行维护3个时期组成,每个时期又进一步划分成若干个阶段。

5.软件定义时期的任务是:确定软件开发工程必须完成的总目标;确定工程的可行性;导出实现工程目标应该采用的策略及系统必须完成的功能;估计完成该项工程需要的资源和成本,并且制定工程进度表。

这个时期的工作通常又称为系统分析,由系统分析员负责完成。

软件定义时期通常进一步划分成3个阶段,即问题定义、可行性研究和需求分析。

6.开发时期具体设计和实现在前一个时期定义的软件,它通常由下述4个阶段组成:总体设计,详细设计,编码和单元测试,综合测试。

其中前两个阶段又称为系统设计,后两个阶段又称为系统实现。

7.维护时期的主要任务是使软件持久地满足用户的需要。

8.软件生命周期每个阶段的基本任务:问题定义、可行性研究,需求分析,总体设计,详细设计,编码和单元测试,综合测试。

9.常用软件模型区别原理:(1)瀑布模型:按照传统的瀑布模型开发软件,有下述的几个特点。

a)阶段间具有顺序性和依赖性:两重含义:段的输出文档正确,后一阶段的工作才能获得正确的结果。

①必须等前一阶段的工作完成之后,才能开始后一阶段的工作;②前一阶段的输出文档就是后一阶段的输入文档,因此,只有前一阶b) 推迟实现的观点瀑布模型在编码之前设置了系统分析与系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现。

c)质量保证的观点:软件工程的基本目标是优质、高产。

为了保证所开发的软件的质量,在瀑布模型的每个阶段都应坚持两个重要做法。

每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。

每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。

软件工程期末复习必备知识点

软件工程期末复习必备知识点

一、概念解释1.软件:是程序,数据结构和文档的集合,用于实现系统所需要的逻辑方法、过程和控制。

2.软件危机:是软件开发和维护过程中所遇到的一系列严重的问题。

3.软件周期:是从软件从定义,开发,运行维护到废弃时经历的一个漫长的时期。

4.需求分析:是发现,求精,建模,规格说明和复审的过程。

5,概要设计:通过仔细分析需求规格说明,确定完成系统的模块以及各模块之间的关系,设计出完成预定功能的模块(软件结构),并建立借口。

详细设计:设计完成系统的模块内的算法和数据结构。

6.模块化:将软件划分成可以独立命名的且可以独立访问的模块,每个模块完成一个子功能,把这些模块集成起来构成一个整体,可以完成指定的功能来满足用户的需求。

信息隐藏:一个模块内包含的信息对于一个不需要这些的模块来说是不可访问的。

7.耦合:是一个软件结构内的每个模块互连程度的度量。

内聚:一个模块间各个元素之间的紧密的程度。

8.类:是对有相同数据和相同操作的一组相似对象的抽象描述。

对象:是客观世界中事物的抽象表示,其属性(状态、数据)和相关操作(行为、方法或服务)的封装体;对象之间靠消息传递相互作用。

9.消息:是对象之间相互通信的机制,是某个对象执行其操作的规格说明。

消息传递:一个对象向另一个对象发送消息时,接收消息的对象经过解释、给予响应,这种对象之间进行通信的机制成为消息传递。

10.继承:继承是子类(新类)自动的共享父类(已有类)中定义的数据的操作的机制。

子类可以继承父类的属性和操作;同时子类可以定义自己独有的属性和操作。

子类复用父类的定义,而不修改父类。

继承具有传递性。

多态性:在一个类层次中,不同对象对相同消息做出不同的响应。

11.软件重用:是指同一事物不做修改或者稍加修改就可多次重复使用,软件重用是降低软件开发成本,提高软件开发生产率和质量的有效途径。

12.软件测试:根据软件开发的规格说明和程序的内部结构而设计的一个测试用例,利用这些测试用例去运行程序以发现设计和程序错误的过程。

软件工程期末总结

软件工程期末总结

软件工程期末总结软件工程期末总结今天视频看完了,可是没有总结。

还是感觉不会总结。

一想到50讲的课,怎么总结呢?开始听的时候,是真不知道从哪里下手,因为开始看的时候有种迷迷糊糊的感觉。

软件工程,我期待的一门课就这么听完了一遍。

很有些囫囵吞枣的感觉,不过收获还是很多的,至少知道了软件工程的阶段不是只有需求分析、编程和测试维护。

当然这个很早之前就知道,只是以前根本没有概念。

第一个阶段,计划阶段,要首先对用户的要求进行了解,对软件的性能等进行了解。

然后进行可行性分析研究,在各种可行性研究中,对于软件开发人员来说,技术可行性研究最重要。

之后就是需求分析阶段了,需求分析阶段也是计划阶段的最后一部分。

需求分析定义了要做什么。

把现实的需要用程序语言表达出来。

但是这一阶段并不解决怎么做。

解决怎么做的是下一个阶段——设计阶段。

设计阶段分为概要设计和详细设计。

概要设计把每个组成部分的功能都给出意义明确的模块,每个模块都和一部分需求相对应。

但是不考虑细节。

详细设计,把每个模块的功能实现详细的表示出来,为源程序的编写打下基础。

然后就是编程阶段,我们一般最初接触的就是编程,所以编程阶段比较了解,由于前期文档已经做的很详细,功能的实现数据和算法都已经清楚了,所以编程是比较简单的。

编程完了就是测试阶段了,测试阶段的费用是最多的。

测试阶段是发现错误的阶段,改错是调试阶段。

然后就是交付用户使用,及维护。

以上几点是软件工程的生命周期的六个阶段。

软件工程过程和软件工程生命周期也不能等同。

软件工程过程如下:软件规格说明:规定软件的功能及其运行的限制软件开发:产生满足规格说明的软件:软件的确认:确认软件能够完成客户提出的要求:软件演进:为满足客户的变更要求。

软件必须在使用的过程中演进。

pdca软件工程过程与软件生存期相对应。

软件规格说明对应计划阶段,软件开发对应设计、编程阶段,软件的确认对应测试调试阶段,软件演进对应运行维护阶段。

软件开发的每个过程都有相关文档,用老师们的话说叫做以文档为驱动。

软件工程期末考试重点

软件工程期末考试重点

《软件工程》期末复习重点第一章软件工程1.什么是软件工程。

A.把系统化的、规范的、可度量的途径应用于软件开发、运行和维护的过程,也就是把工程化应用于软件中;b.研究a中提到的途径。

2. 软件工程的三要素:方法、工具和过程。

第二章软件过程1.软件生命周期分为哪几个阶段?每个阶段的基本任务是什么?a.软件定义:确定软件开发工程必须完成的总目标问题定义:要解决的问题是什么可行性研究:上阶段所确定的问题是否有可行的解决办法?需求分析:目标系统必须做什么b.软件开发:具体设计和实现在前一个时期定义的软件。

概要设计:怎样宏观地解决问题详细设计:应如何具体地实现这个系统编码和单元测试:写出正确的、易理解、易维护的程序综合测试:通过各类型测试使达到预定要求。

c.运行维护:修正错误,使软件持久地满足用户需要。

改正性维护:诊断和改正使用中的错误适应性维护:修改以适应环境变化完善性维护:根据用户的要求改进和扩充以完善预防性维护:修改以为将来的维护作准备2.常用的过程模型有哪些?各自的特点及不足。

如:瀑布模型的不足是不能适应需求的动态变更。

A.瀑布模型特点:可强迫开发人员采用规范化的方法。

严格地规定了每个阶段必须提交的文档。

要求每个阶段交出的所有产品都必须是经过验证(评审)的。

缺点:太理想化,由于瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发出的软件产品不能真正满足用户的需要。

如果需求规格与用户需求之间有差异,就会发生这种情况。

只适用于项目开始时需求已确定的情况。

B.快速原型模型特点:快速软件产品开发基本上是线性顺序进行。

降低了规格说明文档变化的可能性。

减少了后续阶段错误的可能性。

c.增量模型优点:人员分配灵活,刚开始不用投入大量人力资源。

当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径。

增量能够有计划地管理技术风险。

缺点:要求构件具备开放式的体系结构。

易退化为边做边改模型,从而使软件过程的控制失去整体性。

软件工程期末考试主要知识点电子版

软件工程期末考试主要知识点电子版

4.七条基本原理:(1)用分阶段的生命周期计划严格管理;(2)坚持进行阶段评审;(3)实行严格的产品控制;(4)采用现代程序设计技术;(5)结果应能清楚地审查;(6)开发小组的人员应该少而精;(7)承认不断改进软件工程实践的必要性。

10、RUP是Rational软件公司进过多年的商业化经验的六条最有效的软件按开发经验:迭代式开发、管理需求、使用基本构件的体系结构、可视化建模、验证软件质量、控制软件变更11、.微软过程生命周期的阶段以及各阶段的里程碑:(1)规划阶段(项目目标得到认可);(2)设计阶段(完成产品设计);(3)开发阶段(完成开发工作);(4)稳定阶段(准备好可发布版本);(5)发布阶段(完成产品发布)13、可行性研究的目的是用最小的成本在较短的时间内确定问题是否能够解决。

14. 对问题的每一种解法一般需要进行1.技术可行性2.经济可行性3.操作可行性4.法律可行性15. 在可行性研究阶段使用的描述工具有哪些?系统流程图,数据流图,数据字典。

16. 系统流程图:是概括地描述物理系统的传统工具表达的是数据在系统各部件之间的、流动的情况。

其基本思想是用图形符号从黑盒子描绘组成系统的各个部件(程序、文档、数据库、人工过程等)数据流图:是一个图形化技术,它描述信息流和数据从输入一点到输出的过程中所经受的变换。

数据字典:关于数据的信息的集合,即对数据流图中包含的所有元素的定义的集合17. 数据流图仅反映系统必须完成的逻辑功能,所以只是描绘数据在软件中流动和被处理的逻辑过程18. 数据字典的基本元素:数据流、数据元素、数据存储、处理21. 在进行成本/效益分析时首先需要估计成本。

成本估计可以使用那些技术?代码行技术、任务分解技术、自动估计成本技术22. 需求分析阶段的具体任务是什么?确定对系统的综合要求、分析系统的数据要求;导出系统的逻辑模型;修正系统开发计划23. 需求分析最终结果是什么体现的?分析模型、软件需求规格说明书24. 需求分析阶段完成的文档有哪些?分析模型、软件需求规格说明书25. 需求分析阶段使用的图形工具有哪些?数据流图、E-R图、状态转换图、层次方框图、watnier图、IPO图26. 在大型数据处理系统的功能分析与设计中,数据库的概念设计对应于系统开发的哪个阶段?对应需求分析阶段27. 最常用的表示概念性数据模型的方法是什么?E-R图28. 一般说来,应该从哪几个方面来验证需求分析的正确性?一致性、完整性、现实行、有效性29. 什么有穷状态机?有穷状态机有何作用?有穷状态机又哪几部分组成?有穷状态机:一个5元组(JKTSF)J有穷非空状态集K有穷的非空输入集T是一个从(J-F)*K到J 的转换函数、S属于J,初始状态。

软件工程期末考试知识概括

软件工程期末考试知识概括

一、名词解释1、软件:是计算机程序及其有关的数据和文档的完整集合。

2、软件工程:软件工程采用工程的概念、原理、技术和方法来开发与维护软件。

3、软件生命周期:是从设计软件产品开始到产品不能使用为止的时间周期。

4、模块:是能够单独命名,由边界元素限定的程序元素的序列。

在软件的体系结构中,模块能独立地完成一定的功能,是可以组合、分解和更换的单元。

5、模块化:是指把系统分割成能完成独立功能的模块。

6、软件维护:就是指在软件产品交付之后对其进行修改,以排除故障,或改进性能和其他属性,或使产品适应改变了的环境。

7、软件的可维护性:是指软件功能被理解、改正、适应和增强的难易程度,可维护性时维护人员对该软件进行维护的难易程度。

可维护性是指导软件工程各阶段的一条基本原则,提高可维护性是软件工程追求的目标之一。

8、数据流图:是用来描绘软件系统逻辑模型的图形工具,是描绘信息在系统中流动和处理的情况的。

9、数据字典:是对数据流图中出现的所有数据元素、数据流、文件、处理的定义的集合。

二、1、比较瀑布模型、快速原型模型、螺旋模型的特点。

2、尽可能推迟软件的编码3、保证质量(2)快速原型模型快速原型模型:是指快速开发一个可以运行的原型系统,该原型系统所能完成的功能往往是最终产品能完成的功能的一个子集。

(3)螺旋模型每一个螺旋周期由下列六个步骤组成:1) 确定任务 2) 选择对象 3) 分析约束条件 4) 风险分析5) 制定消除风险的方法 6) 制定下一周期的工作计划确定目标、方案、约束 复审需求计划生命周期计划开发计划集成测试计划计划下一阶段工作开发验证下一级产品需求确认设计验证与确软件需求产品设计详细设计编码单元测试集成测试验收测试运行、维护2、耦合的种类:(耦合度越低模块的独立性越强、划分的质量好)数据耦合、控制耦合、特征耦合、公共环境耦合、内容耦合(耦合度最大)为了降低模块间的耦合程度,应采用以下设计原则:●在传递信息时尽量使用数据耦合,少用控制耦合和特征耦合。

软件工程期末考试复习重点

软件工程期末考试复习重点

第一章软件危机:是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题。

软件危机的主要表现:1、对软件开发成本和进度的估计常常很不准确。

2、用户对“已完成的”软件系统不满意的现象经常发生。

3、软件产品的质量往往靠不住。

4、软件常常是不可维护的5、软件通常没有适当的文档资料6、软件成本在计算机系统总成本中所占的比例逐年上升7、软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势软件工程:定义一:是为了经济地获得可靠的且能在实际机器上有效地运行的软件,而建立和使用完善的工程原理。

定义二:1.把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程,也就是把工程应用于软件;2.研究1.中提到的途径。

软件工程方法学的三个要素:方法、工具和过程。

目前使用的最广泛的软件工程方法学:传统方法学、面向对象方法学。

软件的生命周期:软件生命周期有软件定义、软件开发和运行维护3个时期组成;定义时期分为:问题定义、可行性研究和需求分析阶段;开发时期分为:总体设计、详细设计、编码和单元测试、综合测试;维护时期的任务:是软件持久的满足用户的需求;瀑布模型:最广泛的过程模型;瀑布模型的特点:1、阶段间具有顺序性和依耐性;2、推迟实现的观点;3、质量保证的观点;Rational统一过程(RUP)四个阶段的工作目标:初始阶段:建立业务模型,定义最终产品视图,并且确定项目的范围;精化阶段:设计并确定系统的体系结构,制定项目计划,确定资源需求;构建阶段:开发出所有构件和应用程序,把他们集成为客户需要的产品,并且详尽地测试所有功能;移交阶段:把开发出的产品提交给用户使用;第二章可行性研究的目的是确定问题是否值得去解决;可行性研究的方面:技术可行性、经济可行性、操作可行性;系统流程图描述物理模型;P39(要求会做)数据流图描述逻辑模型;P40(要求会做)数据流图(DFD)描绘信息流和数据从移动到输出的过程中所经受的变换;数据字典有以下4类元素的定义组成:数据流、数据流分量(数据元素)、数据存储、处理;由数据元素组成的数据的方式三种基本类型:顺序、选择、重复;“=”是等价于(或者定义为),“+”是和(用来连接分量),“[ ]”是或(从其中选一),“{ }”是重复,“()”是可选;第三章:需求分析任务:功能需求是指定系统必须提供的服务,通过该分析划出该系统必须完成的所有功能。

软件工程期末总结复习提纲完美版

软件工程期末总结复习提纲完美版

《软件工程》复习大纲1软件与软件工程1. 1 软件的基本看法(比方,软件的定义、文档、软件的特点等)简单地说,软件由程序和文档两部分组成,一是机器能够执行的程序及相关的数据,二是机器不能够执行的文档,软件的两种宽泛定义:①软件是与计算机系统操作相关的程序,规程、规则及任何与之相关的文档和数据。

②软件是程序以及开发,使用和保护程序所需要的文档,包括机器运行所需要的各种程序及相关资料。

程序:为认识决某一问题而按早先设计的功能和性能要求执行的指令系列,也许说,用程序设计语言描绘的适合于计算机办理的语句序列。

数据:使程序能正常控制信息的数据构造。

文档:描绘程序、数据和系统开发以及使用的各种图文资料。

它拥有永久性并能供人或机器阅读。

软件的基本特点:·①计算机软件产品是一种逻辑产品部件而不是物理产品部件。

·②软件产品的生产主若是研制,是经过人们的智力活动,把知识与技术转变为信息的一种产品。

·③软件拥有“复杂性” ,其开发和运行常碰到计算机系统的限制。

而且,软件投入使用后,仍需要进行保护,这就带来软件保护复杂性的问题。

·④软件不存在磨损,物理上不会老化,但存在软件退化问题。

·⑤软件成本昂贵,其开发方式当前还没有完满挣出手工生产方式。

1. 2 软件危机的看法软件危机是指在软件开发和保护过程中所碰到的一系列严重问题。

【由于软件的规模越来越大,复杂度不断增加,软件需求量增大。

而软件开发过程是一种高密集度的脑力劳动,软件开发的模式及技术不能够适应软件发展的需要。

致使大量质量低质的软件涌向市场,有的开销大量人力财力,而在开发过程中就夭折。

】“软件危机”主要表现在两个方面:(1)软件产质量量低质,甚至开发过程就夭折;(2)软件生产率低,不能够满足需要。

1. 3 软件工程学的看法 (定义 )、研究的内容(三要素)1993 年 IEEE定义:(1)把系统化的、规范化的、可胸襟的路子应用于软件开发、运行和保护的过程,也就是把工程化应用于软件中;(2)研究( 1)中提到的路子。

软件工程复习总结

软件工程复习总结

软件工程复习总结第一篇:软件工程复习总结第1章1什么是软件危机,产生软件危机的原因,消除软件危机的途径。

落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象。

软件维护费用的急剧上升,直接威胁计算机应用的扩大;软件生产技术进步缓慢,是加剧软件危机的重要原因。

既要有技术措施,又要有必要的组织管理措施。

2什么是软件,软件的精确定义。

软件是程序以及开发、使用和维护程序所需的所有文档.。

3软件工程的精确定义,软件工程的7个特征,7基本原理。

软件工程是指导计算机软件开发和维护的一门工程学科。

1,软件工程关注于大型程序的构造;2,软件工程的中心课题是控制复杂性;3,软件经常化;4,开发软件的效率非常重要;5,和谐地合作是开发软件的关键;6,软件必须有效地支持它的用户;7,在软件工程领域中是由一种文化背景的人替具有另一种文化背景的人创造产品。

基本原理:1,用分阶段的生命周期计划严格管理;2,坚持进行阶段评审;3,实行严格的产品控制;4,采用现代程序设计的技术;5,结果应能清楚地审查;6,开发小组的人员应该少而精;7,承认不断改进软件工程实践的必要性。

4软件工程方法学的精确定义,它的三要素。

二种方法学,面向结构,面向对象3个要素:方法工具和过程两种方法学:1传统方法学2面向对象方法学 5什么是软件生命周期,它有哪几个阶段(8个阶段),各个阶段分别做什么,这些阶段的重要性。

一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。

阶段:1问题定义2可行性研究3需求分析4总体设计5详细设计6编码和单元测试7综合测试8软件维护6软件过程的精确定义,它与软件工程的关系,它的各种模型,各种模型的优缺点,适用范围。

软件过程为一个为建造高质量软件所需完成的任务的框架,它规定了完成各项任务的工作步骤。

瀑布模型快速原型模型增量模型螺旋模型喷泉模型第2章1什么是可行性研究,它的目的,它的任务,可行性研究是在项目建议书被批准后,对项目在技术上和经济上是否可行所进行的科学分析和论证。

软件工程期末复习知识点整理

软件工程期末复习知识点整理

复习整理一、绪论1.软件的定义软件是能够完成预定功能和性能的可执行的计算机程序,包括使程序正常执行所需要的数据,以及有关描述程序操作和使用的文档。

(软件=程序+文档)2.软件工程的定义●是指导计算机软件开发和维护的一门工程学科;●采用工程化的原理与方法对软件进行计划、开发和维护;●把证明正确的管理技术和最好技术综合运用到软件开发中;●研究经济地开发出高质量的软件方法和技术;●研究有效维护软件的方法和技术。

3.软件危机的概念,及出现的原因软件开发技术的进步未能满足发展的要求。

在软件开发中遇到的问题找不到解决的办法,问题积累起来,形态尖锐的矛盾,导致了软件危机。

产生原因:⑴软件规模越来越大,结构越来越复杂⑵软件开发管理困难而复杂。

⑶软件开发费用不断增加。

⑷软件开发技术落后。

⑸生产方式落后,仍采用手工方式。

⑹开发工具落后,生产率提高缓慢。

4.三种编程范型的特点(1) 过程式编程范型:把程序理解为一组被动的数据和一组能动的过程所构成;程序=数据结构+算法;着眼于程序的过程和基本控制结构,粒度最小(2) 面向对象编程范型:数据及其操作被封装在对象中;程序=对象+消息;着眼于程序中的对象,粒度比较大(3) 基于构件技术的编程范型:构件是通用的、可复用的对象类;程序=构件+架构;眼于适合整个领域的类对象,粒度最大二、软件生存周期与软件过程1、软件生存周期的定义,把生存周期划分为若干阶段的目的是什么,有哪几个主要活动●定义:一个软件从开始立项起,到废弃不用止,统称为软件的生存周期●目的:软件生存周期划分为计划、开发和运行3个时期;把整个生存周期划分为较小的阶段,给每个阶段赋予确定而有限的任务,就能够化简每一步的工作内容,使因为软件规模而增长而大大增加了软件复杂性变得较易控制和管理。

●主要活动:需求分析、软件分析、软件设计、编码、软件测试、运行维护(P19)2、软件生命周期划分为哪几个阶段软件生命周期分为三个时期八个阶段:●软件定义:问题定义、可行性研究;●软件开发:需求分析、概要设计、详细设计、编码、测试;●软件运行:软件维护3、瀑布模型的特点和缺陷特点:线性模型,每一阶段必须完成规定的文档(阶段间的顺序性和依赖性)优点:●可强迫开发人员采用规范化的方法。

软件工程导论期末复习重点

软件工程导论期末复习重点

软件工程导论期末复习重点软件工程期末复习一、软件工程学概述1.软件危机:计算机开发和维护的过程中所遇到的一系列问题名词解释(需要加上软件危机产生的原因)对用户的要求没有完整准确的认识就匆忙着手编写程序论述题(需要加上软件危机的典型表现)01.对软件开发成本和嫉妒的估计常常不准确02.用户对已完成软件系统的不满意情况经常发生03.软件的质量靠不住2.软件工程:指导计算机开发和维护的一门工程学科?名词解释3.软件工程方法学的三要素:方法、工具、过程4.软件生命周期的三个时期:软件定义、软件开发、运行维护01.软件定义时期的三个阶段:问题定义、可行性研究、需求分析02.软件开发时期的四个阶段:总体设计、详细设计、编码、单元测试,综合测试,前两个称系统设计,后两个称系统实现03.软件维护时期:只要任务是使软件持久的满足用户的需要,具体的说,当软件在使用过程中发现错误时应该加以纠正,当环境改变时应修改软件以适应新的环境,当用户有新的需要时,应该及时改进软件以满足用户新的需求,本时期不在划分阶段,但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程5.可行性研究的结果是客户做出是否继续这项工程的决定的重要依据,只有投资取得较大收益的的那些工程项目才是值得继续进行下去的6.需求分析的目标是:确定出系统必须具备哪些功能,和用户密切配合,充分交流信息,以得出经过系统确认的系统逻辑模型7.软件维护的四类维护活动:01.改正性维护:改正和诊断在使用过程中发生的软件错误02.适应性维护:修改软件以适应新的环境变化03.完善性维护:根据用户的需求改善和扩充软件使它更完善04.预防性维护:为将来的维护活动事先做准备8.瀑布模型: ?论述题01.传统的瀑布模型开发软件的特点A.阶段间具有顺序性和依赖性B.推迟实现的观点C.质量保证的观点02.软件配置:程序、文档、数据03.注释有什么用:提高代码的可读性(有待补充)二、可行性研究1.可行性研究的目的:就是用最小的代价在尽可能短的时间内确定问题是否能够解决2.从三个方面研究每种解法的可读性;01.技术可行性:使用现在的技术能实现这个系统吗?02.经济可行性:这个系统的经济效益能超过它的开发成本吗?03.操作可行性:系统的操作方式在这个用户组织内能行得通吗?3.系统流程图:是概括的描绘物理系统的传统工具。

软工重要知识点总结

软工重要知识点总结

软工重要知识点总结软件工程(Software Engineering)是一门研究如何应用科学和工程原则,以及管理方法,对软件的开发、运行和维护过程加以系统化的学科。

在软件工程领域,有一些重要的知识点需要掌握。

本文将对这些知识点进行总结。

1. 软件开发过程软件开发过程是指从需求分析到软件交付的整个过程。

常见的软件开发过程模型有瀑布模型、迭代模型和敏捷模型。

其中,瀑布模型适用于需求比较稳定的项目,迭代模型适用于需求变化较快的项目,而敏捷模型则更加注重快速交付和用户反馈。

2. 需求工程需求工程是软件工程的核心环节,它负责收集、分析、规范和管理用户需求。

需求工程师需要与用户充分沟通,确保准确理解用户需求,并将其转化为可执行的软件需求规格。

需求工程包括需求获取、需求分析、需求规格和需求验证等步骤。

3. 软件设计原则软件设计原则是指在软件设计阶段应该遵循的基本原则,以确保软件的可维护性、可扩展性和可重用性。

常见的软件设计原则包括单一责任原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则和迪米特法则等。

遵循这些原则可以提高软件系统的质量和可维护性。

4. 软件测试与调试软件测试是验证软件系统是否满足需求的过程。

常见的软件测试方法包括单元测试、集成测试、系统测试和验收测试等。

软件调试是解决软件中的错误(bug)的过程,常用的调试工具有断点调试和日志输出。

软件测试和调试是确保软件质量的重要手段。

5. 软件项目管理软件项目管理是指对软件开发项目进行组织、计划、协调和控制的过程。

项目管理包括项目计划、需求管理、进度管理、质量管理和风险管理等方面。

良好的软件项目管理可以提高项目成功的几率,降低风险。

6. 软件质量保证软件质量保证是指在软件开发过程中对软件质量进行监控和管理的活动。

常见的软件质量保证方法有代码评审、性能测试、安全测试和用户体验测试等。

软件质量保证旨在提高软件质量,确保软件系统的可靠性和稳定性。

7. 软件配置管理软件配置管理是对软件开发过程中的软件配置项进行管理和控制,以保证软件配置的正确性和一致性。

软件工程期末复习要点归纳总结

软件工程期末复习要点归纳总结

第一章软件工程学概论1、软件危机产生的原因软件本身的特点:难于维护、逻辑复杂软件开发与维护的方法不正确:忽略需求分析重要性、轻视软件维护课本表述:1、软件不同于硬件,它是计算机中的逻辑部件而不是物理部件2、软件不同于一般程序,它的一个显著特点是规模庞大,而且程序的复杂性将规模的增加而呈现指数上升;3、软件本身特有的特点确实给开发和维护带了一些客观困难4、软件开发与维护有关的许多错误认识与做法有关忽略需求分析,轻视软件维护5、对用户要求没有完整准确的认识就匆忙开始着手编写程序6、在软件不同阶段进行修改需要付出的代价是很不相同的2、软件危机的表现什么是软件危机1、成本高:2、软件质量得不到保证:软件质量问题导致失败的软件项目非常多3、进度难以控制:●项目延期比比皆是●由于进度问题而取消的软件项目较常见●只有一小部分的项目能够按期完成4、维护十分困难:▼软件维护的多样性▼软件维护的复杂性▼软件维护的副作用3、克服软件危机1、管理的角度:软件开发过程的研究、文档的标准化以及人员的交流方式等2、软件开发方法的研究结构化软件开发方法, 面向对象的开发4、软件工程的定义概括的说,软件工程师指导计算机软件开发和维护的一门工程学科;采用工程的概念、原理、技术和方法来开发和维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程;1、软件工程就是建立和使用一套合理的工程原理,从而经济地获得可靠的、可以在实际机器上高效运行的软件;2、①把系统的、规范的、可度量的方法应用于软件开发、运行和维护的过程,也就是把工程应用于软件.②研究①中提到的途径总之:软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程;他借鉴传统工程的原理、方法,以提高质量,降低成本为目的;5、软件工程的本质特性1、关注与大型程序的构造2、中心课题是控制复杂度3、软件经常变化4、开发软件的效率非常重要5、和谐的合作是开发软件的关键6、软件必须有效地支持它的用户7、在软件工程领域中通常由具有一个文化背景的人替另外一种文化背景的人创造产品6、软件工程的基本原理1、用分阶段的生命周期计划严格管理2、坚持进行阶段评审3、实行严格的产品控制4、采用现代程序设计技术5、结果应能清楚地审查6、开发小组应该少而精7、承认不断改进软件工程实践的必要性软件工程学包含3个要素:方法、工具和过程7、软件生命周期1、概念:软件生命周期由软件定义、软件开发和运行维护也成软件维护3个时期组成;2、内容:1、问题定义回答“要解决的问题是什么“,写出关于问题性质、工程目标和工程规模的书面报告2、可行性分析回答”对于问题是否有行得通的解决办法“,即探索问题是否值得去解,是否有可行的办法3、需求分析确定”为了解决这个问题,目标系统必须做什么“,确定目标系统必须具备哪些功能,得到需求规格说明书;4、总体设计回答”概括地说,应该怎样实现目标系统“,确定程序由哪些模块组成以及模间的关系5、详细设计回答”应该怎样具体地实现这个系统呢”,确定实现模块功能所需要的算法与数据结构6、编码和单元测试写出正确的容易理解、容易维护的程序模块,然后仔细测试每个模块7、综合测试通过各种类型的测试及相应的调试是软件达到预定要求8、软件维护通过各种必要活动是系统持久地满足用户需求8、生命周期模型1、瀑布模型传统瀑布模型特点:1、阶段间具有顺序性与依赖性2、推迟实现的观点3、质量保证的观点瀑布模型优点:1、可强迫开发人员使用规范的方法例如:结构化技术;2、严格规定每个阶段必须提交的文档;3、要求每个阶段交出的所有产品都必须通过验证;缺点:1、“瀑布模型是由文档驱动的”成为主要缺点适用范围:适合于用户需求明确、完整、无重大变化的软件项目开发;2、快速原型模型适用范围:用户不能给出完整、准确的需求说明,或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等情况;3、增量模型特点:1、反复的应用瀑布模型的基本成分和原型模型的迭代特征,每一个线型过程产生一个“增量”的发布或提交,该增量均是一个可运行的产品;2、早期的版本实现用户的基本需求,并提供给用户评估的平台;优点:1、在较短时间内向用户提交可完成部分工作的产品;2、逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品,从而减少一个全新的软件可能给客户组织带来的冲击;缺点:1、软件体系结构必须是开放的;2、开发人员既要把软件系统看作整体;又要看成可独立的构件,相互矛盾;3、多个构件并行开发,具有无法集成的风险;4、螺旋模型基本思想:使用原型或其他方法来降低风险;适用范围:适用于内部开发大规模软件项目;优点:1、对可选方案和约束条件的强调有利于已有软件的重用,也有助于把软件质量作为软件发的一个重要目标2、减少了过多测试或测试不足3、维护和开发之间并没有本质区别缺点:1、风险驱动,需要相当丰富的风险评估经验和专门知识,否则风险更大2、随着迭代次数的增加,工作量加大,软件开发成本增加5、喷泉模型特点:喷泉模型是一种以用户需求为动力,以对象为驱动的模型,主要用于采用对象技术的软件开发项目;该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性;6、Rational统一过程RUP重复一系列周期,每个周期由一个交付给用户的产品结束;每个周期划分为初始、细化、构造和移交四个阶段,每个阶段围绕着五个核心工作流需求、分析、设计、实现、测试分别迭代;第二章可行性研究1、概念目的用最小的代价在尽可能短的时间内确定问题是否能够解决,不是解决问题,而是确定问题是否值得去解决;2、可行性研究任务了解客户的要求及现实环境,从技术、经济和社会因素等三方面研究并论证本软件项目的可行性,编写可行性研究报告,制定初步项目开发计划;即对软件开发以后的行动方针提出建议;3、研究内容(1)技术可行性使用现有的技术能实现这个系统吗(2)经济可行性这个系统的经济效益能超过它的开发成本吗(3)操作可行性系统的操作方式在这个用户组织内行得通吗(4)法律可行性新系统开发是否会侵犯法藤、集体或国家利益4、数据字典1、内容1、数据流2、数据流分量即数据元素3、数据存储4、处理2、作用对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义,使得每一个图形元素都有一个确切的定义;第三章需求分析1、需求分析的任务(1)确定对系统的综合要求(2)分析系统的数据要求(3)导出系统的逻辑模型(4)修正系统的开发步骤2、获取需求的方法(1)访谈(2)面向数据流自顶向下(3)简易的应用规模说明技术(4)快速建立软件模型3、实体-关系图P63、层次方框图P68和IPO图P694、结构化分析模型●数据流图:描绘当数据在软件系统中移动时被变换的逻辑过程,指明系统具有的变换数据的功能,是建立功能模型的基础●实体-联系图:描绘数据对象及数据对象之间的关系,用于建立数据模型;●状态转换图:指明了作为外部事件结果的系统行为;描绘了系统的各种行为模式称为“状态”和在不同状态间转换的方式;是行为建模的基础第四章总体设计1、模块独立性与耦合性P97(1)模块化把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求模块化的优点:1.使软件结构清晰,容易设计也容易阅读与理解2.容易测试与调试,提高可靠性3.提高软件的可修改性4.有助于软件开发工程的组织管理(2)模块独立的重要性○有效的模块化即具有独立的模块的软件比较容易开发出来○独立的模块比较容易测试和维护(3)耦合衡量不同模块彼此间互相依赖连接的紧密程度,耦合要低,即每个模块和其他模块之间的关系要简单1、数据耦合:两个模块之间通过参数交换信息,而且交换的信息仅仅是数据2、控制耦合:传递的信息中有控制信息3、特征耦合:当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素4、公共环境耦合:两个或多个模块通过一个公共环境相互作用5、内容耦合:出现一下情况之一,则为内容耦合:1、一个模块访问另一个模块的内部数据2、一个模块不通过正常入口而转到另一个模块的内部3、两个模块有一部分代码重叠4、一个模块有多个入口数据耦合<控制耦合<特征耦合<公共环境耦合<内容耦合(4)内聚P99衡量一个模块内部各个元素彼此结合的紧密程度;内聚要高,每个模块完成一个相对独立的特定子功能信息隐藏P96应该这样设计和确定模块,使得一个模块内包含的信息过程和数据对于不需要这些信息的模块来说,是不能访问的2、启发规则1、改进软件结构提高模块独立性2、模块规模应该适中3、深度、宽度、扇入、扇出都应适中4、模块的作用域应该在控制域之内5、力争降低模块接口的复杂度6、设计单入口、单出口模块7、模块功能应该可以预测3、层次图和HIPO图P1024、面向数据流的设计方法P104(1)概念面向数据流设计就是把信息流映射成软件结构,信息流的类型决定了映射的方法;信息流包括变换流、事物流;(2)变换分析与事务分析P1055、小结i.进行软件结构设计遵循的最主要的原理是模块独立原理ii.抽象和求精是一对互补概念iii.软件工程师在实践中总结经验得出一些很有参考价值的启发式规则iv.自顶向下逐步求精是进行软件结构设计的常用途径v.用形式化的方法由数据流图映射出软件结构第五章实现1、选择程序设计语言为了使程序容易测试和维护以减少软件的总成本,所选用的高级语言程序应该有理想的模块化机制,以及可读性好的控制结构和数据结构:为了便于调试和提高软件可靠性,语言特点应该是编译程序能够尽可能多地发现程序中的错误;为了降低软件开发和维护的成本,选用的高级语言应该有良好的独立编译机制;第六章软件测试2、测试的概念(1)测试是为了发现程序中的错误而执行程序的过程(2)好的测试方案是极可能发现了至今为止尚未发现的错误的测试方案;(3)成功的测试是发现了至今为止尚未发现的错误的测试;3、测试的过程与步骤P153大型软件的测试过程基本由下述几个步骤组成(1)模块测试单元测试发现编码和详细设计的错误(2)子系统测试(3)系统测试集成测试(4)验收测试确认测试(5)平行运行4、单元测试P153着重从下述5个模块进行测试主要使用白盒测试技术(1)模块接口(2)局部数据结构(3)重要的执行通路(4)出错处理通路(5)边界条件5、集成测试P156集成测试就是测试和组装软件的系统化技术,主要目标是发现与接口有关的问题;有两种集成策咯(1)自顶向下集成(2)自底向上集成6、确认测试P160也称验收测试,它的目标是验证软件的有效性;通常使用黑盒测试法;7、白盒测试技术P162白盒方法测试软件时设计测试数据的典型技术(1)逻辑覆盖1、语句覆盖2、判定覆盖3、条件覆盖4、判定/条件覆盖5、条件组合覆盖6、点覆盖7、边覆盖8、路径覆盖(2)控制结构测试1、基本路径测试2、条件测试3、循环测试8、黑盒测试技术P171黑盒测试力图发现下述类型的错误:(1)功能不正确或遗漏了功能;(2)界面错误;(3)数据结构错误或外部访问数据库错误(4)性能错误(5)初始化和终止错误黑盒测试用到的技术(1)等价划分(2)边界值分析(3)错误推测第七章维护1、维护的定义P189所谓软件维护就是在软件已经交付使用周,为了改正错误或满足新的需要而修改软件的过程;根据交付使用之后可能进行的4项活动具体定义软件维护(1)改正性维护纠正在使用过程中暴露出来的错误;诊断和改正错误的过程,(2)适应性维护为了和变化了的环境适当地配合而进行的修改软件活动(3)完善性维护在使用软件的过程中增加新的功能或修改已有功能,还可能提出一般性的改进意见的过程(4)预防性维护为了改进未来的可维护性与可靠性,或为了给未来的改进奠定更好的基础而修改软件的过程;2、维护的过程P192(1)维护组织(2)维护报告(3)维护的事件流(4)保存维护记录(5)评价维护活动3、小结1、软件生命周期每个阶段的工作都和软件可维护性有密切关系;2、再工程过程可以在完成任意一个活动之后中止第八章面向对象技术1、面向对象方法学要点(P203面向对象方法学的出发点和基本原则,是尽可能模拟人类思维方法,是开发软件尽可能接近人类认识世界解决问题的方法与过程;2、面向对象方法学优点1、与人类习惯的思维方法一致2、稳定性好3、可重用性好4、较易开发大型软件产品5、可维护性好3、对象模型(P216对象模型表示静态的,结构化的系统的“数据”性质;它是对模拟客观世界实体的对象以及对象彼此之间的关系的映射,描述了系统的静态结构;4、动态模型(P223动态模型表示瞬时的、行为化的系统的”控制“性质,它规定了对象模型中的对象的合法序列;5、功能模型(P224功能模型表示变化的系统的”功能“性质,他指明了系统应该”做什么”,因此更直接反映了用户对目标系统的需求;6、 三种模型之间的关系(P 228功能模型指明了系统应该“做什么”;动态模型明确规定了什么时候即在何种状况下接受什么时间的触发做;对象模型则定义了做事情的实体;在面向对象方法学中,对象模型是最基本的,它为其他两种模型奠定了基础,人们依靠对象模型完成了3中模型的集成;下面扼要地叙述3种模型之间的关系; 三种模型描述了系统的不同方面: 对象模型 动态模型 功能模型 对象的静态结构及相互关系与时间和顺序有关的系统性质 与值的变化有关的系统性质 描述系统的数据结构控制结构 系统的功能 “干事的主体”“什么时候干” “干什么”7、 其他复杂问题大型系统的对象模型通常由下述5个层次组成:主题层、类与对象层、结构层、属性层、服务层主题层类与对象层结构层属性层服务层功能模型与对象模型的关系--对象模型描述了功能模型中的动作对象,数据存储以及数据流结构 --功能模型中的处理对应于对象模型中的操作 动态模型与对象模型的关系 --状态转换驱使行为发生,这些行为在DFD 中被映射成处理,它们同时与对象模型的操作相对应 --针对每个建立的动态模型描述了类实例的生命周期或运行周期动态模型与功能模型的关系--功能模型中的处理可能产生动态模型中的事件;面向对象开发方法包括OOA面向对象分析、OOD面向对象设计、OOP面向对象实现三个部分第九章软件项目管理1、估算软件规模P305(1)代码行技术每个人了估计程序的最小规模a,最大规模b和最可能规模m,分别算出这3中规模的平均值a̅、b̅和m̅之后,用下面公式计算程序规模:L=a̅+4m̅+b̅6(2)功能点技术2、项目进度Gantt图3、质量保证概括得说,软件质量就是“软件与明确地和隐含地定义的需要相一致的程度”;更具体地说,软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度;4、软件配置管理软件配置管理事是在软件的整个生命周期内管理变化的一组活动;具体地说,这组活动用来:(1)标识变化(2)控制变化(3)确保适当地实现了变化(4)向需要知道这类信息的人报告变化5、基线基线是一个软件配置管理概念,它有助于人们在不严重合理变化的前提下来控制变化,简而言之,基线就是通过了正式复审的软件配置项;;在软件配置项变成基线之前,可以迅速而非正式地修改它;其他复习简答题1、简述文档在软件工程中的作用;1 提高软件开发过程的能见度2 提高开发效率3 作为开发人员阶段工作成果和结束标志4 记录开发过程的有关信息便于使用与维护;5 提供软件运行、维护和培训有关资料;6 便于用户了解软件功能、性能;。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

—————————————————————————东南大学计算机科学与工程学院《软件工程》复习总结(根据张敏灵老师的英文PPT)—————————————————————————第一章软件系统的特点:1.复杂的创造很多功能实现许多不同的(往往又是矛盾的)目标包含许多组成部分不同的参与者开发流程和软件生命周期经常持续很多年2.容易发生变化客户或终端用户需求变化发现错误开发者有了很好的理解新技术出现,员工变迁软件工程的定义:1.建模软件工程师通过建模解决复杂性问题模型:系统的抽象体现,使我们可以回答系统的问题并直观理解系统2.问题求解在有限的预算和时间下,模型寻求合理的解决方案OOSE:object-oriented software engineering需求获取需求分析系统设计对象设计实现测试3.知识获取软件工程师收集数据,组织成信息,形成知识非线性过程4.原理驱动软件工程师需要了解作出决定的环境条件和做出这些决定的基本原理用来应对变化SE概念:技术、方法和工具的集合,可以在有限的时间、预算以及变化出现的情况下实现高质量的软件系统参与者和身份系统和模型生产产品(内部产品+交付产品)功能需求和非功能需求符号,方法,方法论方法论:方法的集合,解决一类问题或说明如何以及何时每个方法需要被用到本书用到的方法论:1.需求获取和分析2.系统设计和对象设计3.变化相关的活动4.配置管理SE不仅是有关开发,也关于管理开发活动:需求获取,需求分析,系统设计,对象设计,实现测试管理活动:交流,原理管理,软件配置管理,项目管理,软件生命周期第二章UML:Unified Modeling Language面向对象软件建模中出现的标准创始人:OMT (James Rumbaugh)OOSE (Ivar Jacobson)Booch (Grady Booch)用途广泛:功能模型:用例图(用户角度)对象模型:类图(对象、属性、联系、操作角度)需求分析—>分析对象模型—>应用概念系统设计—>系统设计模型—>系统接口描述对象设计—>对象设计模型—>解决方案对象的详细描述动态模型:交互图—>在一系列对象之间进行一系列消息交换来描述行为状态机图—>针对某一个对象的状态转换活动图—>针对控制和数据流描述行为用例图:描述系统功能,在需求获取和分析时使用,从外部角度来关注系统行为用例:描述系统提供的功能,产生用户可见的结果参与者:任何与系统交互的人(用户,另一个系统,系统的物理环境)参与者在系统边界外,用例在系统边界内(乃们一定要记住用例名是写在这个椭圆下面的啊T T 学长考试的时候全写在里面了!)类图:描述系统的结构类:描述具有相同结构和行为的对象集的抽象对象:在系统执行过程中被创建、修改和销毁的类的实体有状态(包括属性值和与其他对象的联系)类图的成分:类,对象,属性,操作,联系交互图:在用例中涉及的对象(参与对象),表现的就是这些对象之间发生的交互状态机图:转换包括对象未来可以转向的状态和转变条件活动图:活动:代表一系列操作执行的建模元素针对活动来描述系统行为其他活动的结束、对象的可用和外部的活动都可以出发活动的执行与流程图相似:控制流(操作发生的顺序),数据流(操作中对象的交互)用例图:《extend》代表异常或很少调用的用例,箭头指向被扩展的用例《include》代表被分离出来的用例,箭头指向使用的用例《inheritance》代表一个用例可以通过添加细节特化另一个更一般的用例,箭头指向那个一般的用例用例描述:1.用例名称2.参与者3.事件流4.进入条件5.退出条件6.特殊需求类图:表现系统的结构需求获取分析中对应用域概念建模在系统设计中对子系统建模在对象设计中说明类的详细行为和属性类:代表一种概念,封装属性和操作,每个属性有一个类型,每个操作有一个签名,只有类名是强制的信息实例/对象:实例代表一种现象,实例名有下划线,名字可以只包括类名关系也可以通过属性来刻画关系类可以用自己的操作和属性,用虚线连在关系线上聚集:共享聚集:表示一种“属于”继承,空心菱形组合聚集:更强形式的聚集,生命周期必须一致,实心菱形限制(qualification):减少关系的复杂性继承:“是一种”的继承,通过分类简化分析模型,子类继承父类的操作和属性包:可以用UML包机制来组织子系统对象模型建立步骤:1.找到新的类2.定义名字、属性、方法3.找到类之间的关系4.标注一般的关系(has\owns,etc.)5.决定关系之间的多重性6.重审关系7.找到分类(使用继承)8.简化、重组顺序图:在分析中,优化用例描述,找到更多的对象(参与对象)在系统设计中,优化系统接口消息—>参与对象,消息是参与对象中的方法水平虚线箭头代表数据流在消息前有个*代表迭代重复发送消息,在消息前有个[布尔表达式]代表一种发送消息的条件消息指向一个对象的激活(就是对象下面的长方形)则代表创建(creation),在最后的激活上有个代表销毁,销毁可以代表一个对象有用的生命的结束状态机图:状态:满足一个对象(或系统)某种属性的一种情形转换:被事件、条件或时间触发的状态转变Action动作:不可被打断的,有转换action,内部转换action,entry/action,exit/actionActivity活动:在状态内部的可能是长时间的活动,当退出转换被调用的时候activity会被打断,用do做标签嵌套状态机:内部转换来减少复杂度活动图:是状态图的特殊形式活动图中的状态是活动(“功能”)活动结束自动跳转,不需要驱动活动图对于描述系统的工作流程非常有用活动允许对“决定”(一个菱形)和“并发性”(竖线,包括把控制流分成几个线程和同步多个活动)进行建模活动还可以被分成若干个泳道,代表这些活动是被哪个对象或子系统实现的第三章角色:定义了责任(要去做什么)责任被指定到角色身上,角色被指定到人身上任务:描述了被管理人员追踪的最小数量级的工作,包括:1.角色2.工作产品3.开始时间4.计划工期5.需要资源工作产品:可见的任务产出,交付到用户手中的叫作交付产品活动:一系列相关的任务可能会以不同的名字再次被包含到更高级的活动当中允许关注分离在活动中存在优先关系计划内沟通:问题陈述,客户评审,项目浏览,同行评审,现状浏览,集思广益,发布,事后浏览……计划外沟通:需求的澄清,需求的变化,问题求解同步沟通机制:面对面交谈,问题和正式会面,会议,同步群件异步沟通机制:电子邮件,新闻组,万维网,Lotus公司的Notes(其他重点可以看书,还是多看看中文比较好,毕竟试卷是中文....)第四章软件生命周期:需求获取,需求分析,系统设计,系统细节设计,实现,测试需求说明用自然语言,分析模型用UML功能需求:描述系统和环境之间的交互,与实现无关非功能需求:不与功能行为直接相关的方面1.可用性:必须是可测量的(网购需要的步数)2.鲁棒性(健壮性):错误的输入,外界环境的改变…3.有效性:系统正常运行时间的比例(不要总是down机)4.性能5.可支持性限制(伪需求Pseudo requirements):由客户或环境提出需求确认:1.正确性:是否代表了客户的本意2.完整性:系统能应用的场景是否全面3.相容性:没有相互矛盾的需求4.明确性:需求只能有一种解释方式5.可实现性:需求能够被实现和交付6.可追踪性:每个系统行为都可以追踪到一系列的功能需求需求获取的不同方式:1.绿地工程:需求从用户和客户处抽取2.再工程:新需求从现存系统中抽取3.界面工程:需求从技术使能者或新的市场需求抽取场景:一种陈述性描述,所描述的是,在人们使用计算机系统和应用的时候他们所做的和所经历的。

(这是根据老师PPT上的原句翻译的,个人认为书上99面的翻译是错的。

原句是:”A narrative description of what people do and experience as they try to make use of computer systems and applications.”)As-is 场景:描述了当前情况,常用于再工程项目,通过观察用户并将他们的活动描述成场景,一次来理解当前系统Visionary空场景:描述了未来的系统,常用于绿地工程和再工程项目。

开发者和用户两个方面。

关于用例的在前面已经有了,再稍作补充:用例是场景的抽象提取用例可以被多个对象使用分析的关键:从用例出发,找到参与对象第五章对象建模的步骤:1.类定义2.寻找属性3.寻找方法4.寻找类之间的关系实体对象:代表被系统追踪的持久性信息(应用域对象,也被称作“业务对象”)边界对象:代表用户和系统之间的交互控制对象:代表系统所执行的控制任务不同的对象类型让我们更好的应对变化对象类型起源于Smalltalk(Alan Kay):Model, View, Controller (MVC)Model <-> Entity ObjectView <-> Boundary ObjectController <-> Control Object版型机制,模板机制(stereotype mechanism):在UML中可以引入新的建模元素类型《String》Name还可以用图标(icons)和图形符号来定义模板在用例中寻找参与对象:1.选中一个用例,观察事件流2.做语法分析(Abbott’s Technique),名词就是对象或类的候选项,动词就是操作的候选项3.定义不同对象的类型注意:这只是在用例中寻找对象,如果是整个对象定义过程,则是如下:1.从用户和应用域专家处获得一系列场景2.从场景中抽取出用例3.再进行上面“用例中寻找参与对象”的过程,同时还要进行的是组建UML类图组建类图的过程:1.类定义(语法分析,领域专家)2.属性和操作的定义(有时在类之前就被发现)3.类关系的定义4.多重性的定义5.任务的定义6.继承的定义动态图为对象模型发现和补充操作顺序图:布局:第一列——初始化用例的参与者第二列——边界对象第三列:管理剩余用例的操作对象创建:边界对象在用力初始化的时候被创建,控制对象由边界对象创建访问:实体对象被控制对象和边界对象访问,实体对象决不能调用边界对象和控制对象构建顺序图中,可能会有新出现的事件,这些事件可以被认为是接受这个事件的类的一个public权限的操作集中控制式结构,操作可以交换顺序,有新需求时可以插入新操作非集中式控制结构,操作之间有很强的联系和顺序性UML状态图符号(Notation)事件是斜体,条件用[]括起,动作和活动之前都要加/Notation是根据Harel的工作基础上建立起来的超状态:其中有很多嵌套子状态从其他状态进入超状态是进入的第一个子状态从超状态的任意一个子状态都可以离开两种类型的并发性:系统并发性:对象并发性:导航路线:状态图可以被用作用户接口的设计状态:界面名称活动/动作:在界面名下面,前面有个“·”,一般只有退出动作会写出来状态转换:退出动作的结果(点击按钮、选择菜单、光标移动)Model verification检验模型之间转换model validation把模型结合实际进行比较(更高一层),正确性、完整性、一致性、无歧义性、可实现性对象模型占主要:系统有很多类,这些类的状态无关紧要,但是类之间的关系很复杂动态模型占主要:模型有很多事件:输入、输出、异常、错误等功能模型占主要:模型执行复杂的转换(计算包含许多步)RAD (Requirement Analysis Document)第六章“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. Hoare设计目标是对不同利益关注者的权衡子系统:在UML中以包的形式出现对象模型中的对象和类是子系统的“种子”服务:功能模型中的用例是服务的“种子”服务在系统设计中被定义子系统接口:是服务的优化,需要被很好的设计并很小子系统接口在对象设计中被定义Application programmer’s interface (API) :APIs 在实现中定义层次:一个子系统向另一个子系统提供服务某个层次只依赖于它下层的服务,并且对它的上层一无所知UML中,Depend on 用实线,calls用虚线划分:一个层次可以水平的被分为独立的子系统,即划分同一层的划分之间可以互相提供服务划分是低耦合的子系统P2P关系虚拟机:上下层之间是一种“提供服务”的关系(关于子系统)封闭架构(模糊):上层只能向其下一层调用操作可维护性,灵活性开放结构(透明):每个虚拟机可以向任何一个下层的虚拟机调用操作运行效率一致性:测量一个子系统中各个类之间的依赖程度(高)耦合性:测量各个子系统之间的依赖程度(低)体系结构风格:子系统分解的模式客户端/服务器:一个或多个服务器向称谓客户端的子系统实例提供服务客户端知道服务器端的接口服务器端不知道客户端的接口常用于数据库缺点:不能满足P2P的要求P2P:ISO = International Standard OrganizationOSI = Open System Interconnection仓库(repository):子系统访问和修改单一的数据结构子系统之间相互独立,子系统之间交互需要通过仓库完成MVC第七章UML构件图:编译时间下子系统之间的设计依赖关系UML部署图:描述系统的执行时间配置文件系统:数据只由一个人写由很多人读数据库:数据被并发的人读和写访问矩阵:每一行代表系统的参与者,每一列代表希望控制的类访问表:参与者,类,操作访问控制表:参与者,操作(针对于某个类)能力:类,操作(针对于某个参与者)第八章对象设计:对需求分析进行补充并作出实现决定应用对象:与系统相关的对象(应用域专家和终端用户定义)求解对象:与应用域没有对应(开发人员定义)继承:用新的操作或重新操作来扩展基类1.描述分类:需求分析中使用2.接口定义:对象设计中使用,定义所有对象的签名实现继承(类继承):父类的操作已经被实现定义继承(子类型化):只是继承被声明的操作,并不实现类库:被动的,不影响控制流框架:主动的,影响控制流授权:抓取一个操作发送到另一个对象上组合模式:模型动态聚集适配器模式:与已经存在的系统关联桥模式:与已经存在的和未来的系统关联,用于多重实现facade模式:与子系统关联英文全称:UML:unified modeling language(考到)OMT:object modeling technologyOCL(Object Constraint Language)(考到)OOAD(Object Oriented Analysis And Design)(考到)FRIEND: First Responder Interactive EmergencyNavigational DatabaseODD:The Object Design DocumentCMM:Capability Maturity Model for SoftwareLOC:length of code (代码行)COCOMO:constructive cost modelApplication programmer’s interface (API)ISO : International Standard OrganizationOSI : Open System Interconnection (当时写下来觉得没什么用,没想到居然真的考到这个了!)OOSE:object-oriented software engineeringRAD :Requirement Analysis Document“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. HoareOMT (James Rumbaugh)OOSE (Ivar Jacobson)Booch (Grady Booch)—————————————————————————复(yu)习到后面几章的时候离考试已经没几个消失了,所以写下来的东西就很少了。

相关文档
最新文档