软件工程复习考点小结 1（小编推荐）

第一篇：软件工程复习考点小结 1（小编推荐）

《软件工程》考点小结

1,软件工程的定义及软件工程的研究内容？

软件工程是研究软件开发和软件管理的一门工程学科。

软件工程研究的内容包括软件开发方法、软件开发模型、软件支持过程和软件管理过程。其中软件开发方法的内容又涵盖市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护、版本升级。

常用的软件开发模型有瀑布模型、迭代模型、增量模型和原型模型。

软件支持过程由所支持的CASE工具组成，常用的CASE工具有Power Designer和Rational Rose。

软件管理过程主要有CMMI、ISO9000、微软企业文化和敏捷文化现象。

2,软件工程五个面向实施理论？

“五个面向理论”是指“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”，它是在综合“四种开发方法”各自的优点之后提出的软件工程实施理论，是对前者的继承与发展。总之，上述提法既精彩又实用。

3什么是“软件生命周期模型”，常用的软件生命周期模型有哪些？ 在整个软件生命周期中，软件开发过程应该遵循的开发路线图，或者说，软件生命周期模型是软件开发全部过程，活动和任务的结构框架。

1.瀑布模型 瀑布模型是将软件生存周期各个活动规定为自上向下，按照线性顺序连接的若干阶段的模型。

2.增量模型 增量模型是一种遵循递增方式来进行软件开发的模型。

3.原型模型

4.迭代模型 所谓迭代是指活动的多次重复。5.螺旋模型 螺旋模型是一种风险驱动的模型。6.喷泉模型 喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象 的开发方法。

7.xp模型 即指极限编程模型

4,简述瀑布模型与迭代模型之间的关系？

在宏观上，迭代模型是动态模型，瀑布模型是静态模型。一方面，迭代模型需要经过多次反复迭代，才能形成最终产品。另一方面，迭代模型的每一次迭代，实质上都是执行一次瀑布模型，都要经历初始、精化、构造、移交4个阶段，走完瀑布模型的全过程。

在微观上，迭代模型与瀑布模型都是动态模型。迭代模型与瀑布模型在每一个开发阶段（初始、精化、构造、移交）的内部，都有一个小小的迭代过程，只有经历这一迭代过程，该阶段的开发工作才能做细做好。

瀑布模型与迭代模型之间的这种微妙关系，如下图所示。

图

瀑布模型与迭代模型之间的关系

由图可见，在迭代和瀑布模型中，你中有我、我中有你。

瀑布模型与迭代模型之间的关系，反映了人们对客观事物的认识论：要认识与掌握某一客观事物，必须经历由宏观到微观的多次反复的过程。只有从宏观上反复迭代几次，才能看清全貌，掌握事物的宏观发展规律。只有从微观上反复迭代几次，才能吃透每个细节，掌握事物的微观发展规律。

5,何谓软件的“多态性”？

同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。这就是多态性。6,“数据字典”的定义？

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

7,何谓软件的“耦合性”？

耦合性也叫块间联系。指软件系统结构中个模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。

8,数据库物理设计的定义？

数据库物理设计：设计数据库的物理结构，根据数据库的逻辑结构来选定RDBMS(如Oracle、Sybase等)，并设计和实施数据库的存储结构、存取方式等。

9,需求分析的目的是什么，需求分析的难点在哪里？

软件需求分析，其目的是用于说明软件产品或软件项目需要满足的条件和限制。在软件工程项目中首先要获取用户的需求，通过对软件需要的提取、分析、文档化及验证，为进一步的设计和实现提供依据。

需求分析的难点是：在系统的功能、性能和接口方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。万一需求有一点变化，双方必须履行“需求变更管理程序”，而变更管理程序在签订合同时已经做了规定。要知道，合同是具有法律效力的。

10,业务模型、功能模型、数据模型各是什么含义？

功能模型是描述系统能做什么，即对系统的功能、性能、接口和界面进行定义。

业务模型是描述系统在何时、何地、由何角色、按什么业务规则去做，以及做的步骤或流程，即对系统的操作流程进行定义。

数据模型是描述系统工作前的数据来自何处，工作中的数据存到什么地方，工作后的数据放到何处，以及这些数据之间的关联，即对系统的数据结构进行定义。

11,为什么说需求分析是面向流程的？

系统的功能、性能、接口、界面都是在流程中动态实时的反映出来。在所有的流程（物流、人流、资金流、信息流、单据流、报表流、数据流）中，数据流最重要，也最具有代表性。因为在计算机网络系统内，一切流程都表现为数据流，或者说是数据流在不同方向的投影。而流程是动态的、实时的。所以说，需求分析是面向流程的。

12,简述实用软件测试的流程？ 实用软件测试流程可以分5步展开：

（1）理解、验证和分解需求。

（2）编写测试计划（包括测试设计）。（3）测试执行。（4）专项测试。（5）编写测试报告。

13,软件测试的目的和目标是什么？

简单明了地说，软件测试的目的就是发现软件缺陷。但同时还要时刻牢记在心的是：软件测试的目标是尽可能早地发现软件缺陷，并确保其得以修复。这里的缺陷，包括Bug和不符合项。

14,软件需求分析过程中，需求分析的输入是《合同》、《立项建议书》，以及对用户现场的调研，分析和确认，输出是《用户需求报告》或《需求规格说明书》。

15,软件产品的来源是立项和签合同。

16,信息标准化，就是信息的代码化和规范化。

17,面向数据设计以E-R图为基础，按照一定的规则将CDM转换成能被某种

数据库管理系统接受的PDM。

18,按照“五个面向”的实施理论，软件设计的主要方法是面向数据设计，软件实现的主要方法面向对象实现。

19, 软件评估既是软件策划的核心，又是软件策划的重点和难点。20,软件设计包括软件架构设计和软件详细设计，其中三种常用的详细设计方法

21, 软件设计包括软件架构设计和软件详细设计，其中三种常用的详细设计方法是是面向过程、面向数据、面向对象。

22,SW-CMM的5个成熟度等级分别为初始级、可重复级、已定义级、已管理级、优化级。

23,UML规定采用类图和对象图来表述数据模型。24,软件设计可以分为概要设计和详细设计。25,UML规定采用用例图来描述功能模型。

26,软件一般存在5种风险，分别为：政策风险、技术风险、技能风险、资源风险和其他风险。

27,UML中有3种基本构造块：事务、关系和图，它们是UML建模中的积木元素或积木合体。

28, 数据库设计包括数据库需求分析、数据库概念设计、数据库物理设计三个阶段。

第二篇：软件工程考点总结

第一章

1.软件是程序和所使程序正确运行所需的相关文档和配置信息.软件工程是一门工程学科，涉及软件生产的各个方面.软件过程是指制作软件产品的一组活动及其结果。

2.软件过程的4项基本活动有:软件描述：客户和工程师定义所要生产的软件以及对其操作的一些约束软件开发软件得以设计和编程实现软件有效性验证软件经过检查以保证它就是客户所需要的软件进化软件随不同的客户和变化的市场需求而修改.3.软件工程人员的工作不仅仅是技术的应用，还要承担很多责任.保密：工程人员必须严格保守雇主或客户的机密，而不管是否签署了保密协议.工作能力 工程人员应实事求是地表述自己的工作能力，不应有意接受超出了自己能力的工作.知识产权工程人员应当知晓控制专利权、著作权等知识产权使用的地方法律，必须谨慎行事，确保雇主和客户的知识产权受到保护.计算机滥用 软件工程人员不应该用自己的技能滥用他人的计算机，滥用计算机有时对他人影响不大（如在雇主的计算机上玩游戏），但有时后果非常严重（传播病毒）.第二章

1软件工程模型瀑布模型软件描述和开发，分成独立和不同的阶段.增量式开发描述、开发和有效性验证交错进行.面向复用的软件工程基于已存在的很多可复用的组件.2.瀑布模型：1需求分析和定义，通过咨询系统用户建立系统的服务、约束和目标。2系统和软件设计系统设计过程通过建立系统的总体体系结构将需求分为硬件需求和软件需求。3实现和单元测试将软件设计实现为一组程序或程序单元，单元测试是检验每个单元是否符合其描述。4集成和系统测试集成单个的程序单元或一组程序，并对系统整体进行测试以确保其满足了软件需求。5运行和维护

3瀑布模型的问题1将项目分成不同阶段，难以应付不断变化的客户需求.2当需求十分明确，软件开发中只做有限修改时才适合使用该模型.3很少有业务系统有稳定的需求。瀑布模型主要是用于大型系统工程项目，且软件项目是大型工程项目的一部分时尤为适用.4增量式开发优点：

1、降低了适应用户需求变更的成本

2、容易得到用户及时的反馈

3、为及时交付用于的系统提供了可能问题1过程不可见;2系统结构通常较差;3需要专业技能(如快速原型语言等).5过程活动包括：软件描述、软件设计和实现、软件有效性验证及软件进化.6软件描述（需求工程）软件描述或需求工程主要是理解并定义系统需要哪些服务以及找出开发和运行期间受到哪些约束.可行性研究：指明现有的软件硬件及能否实现用户对新系统的要求需求导出和分析：通过对现有系统分析、与潜在用户和购买者讨论、进行任务分析等导出系统需求的过程需求描述：把在分析活动中收集的信息以文档的形式确定下来。需求有效性验证：检查需求的现实性、一致性和完备性。

7软件设计和实现把系统描述转化为一个可运行的系统的过程。软件设计，实现软件的结构、系统的数据等描述。实现，把软件结构转化为可执行的程序。体系结构设计识别系统总体结构、基本组件、它们之间的关系以及它们是怎样分布。接口设计定义系统结构的借口组件设计针对每个系统组件设计它的运行方式数据库设计设计系统数据结构，以及如何在数据库中表示这些数据结构

8软件有效性验证也称检查和有效性验证，是为了表明系统符合其描述，满足了客户的需求.包括检查和审查过程，还有系统测试.组件或单元测试由开发系统的人员对组成系统的组件进行测试系统测试集成组件形成完整的系统。并测试是否满足需求。接收测试系统在接受并运行之前的最后阶段测试

9软件进化软件本质是灵活的，可以改变的.由于业务环境的不断变化，客户需求也随之发生变化，该软件支持的业务也必须不断更新和修改.10.Rational统一过程来自于UML上的工作和相关的软件开发过程.开端建立一个业务案例细化增进对问题域的理解，建立系统的体系框架，给出项目计划、风险构造系统设计、编程和测试转换在其操作环境部署这一系统.过程工作流：业务建模；需求；分析和设计；实现；测试；部署；支持工作流：配置和变更管理；项目管理；环境RUP 好的实践：反复地开发软件；对管理需求；使用基于组件的体系结构；可视化模型软件；验证软件质量；控制对软件的变更

第三章

1.XP和敏捷方法的原则1增量式开发是通过系统的小的频繁开发的版本来支持的；2客户的参与是通过全时雇佣到开发团队的方式；3人（而不是过程）是通过结对编程、集体对系统代码的所有权、可以忍受的开发过程而无需超额的工作小时来运作的；4变更是通过经常性的系统版本来支持的；5通过持续的再分解来维护系统的简洁性。

2问题：1很难将兴趣保持在参与到开发的客户身上。2团队成员个人可能从性格上不太适应激烈的投入，这是敏捷方法的典型特征。3对变更做出优先级排序可能是极困难的，尤其是对那些有很多参与者的系统。4维护简洁性需要额外的工作。5许多机构很难向另一种工作模型转换。6随着其他迭代方法的发展，合同可能也是极限方法的一个问题。优点1极限编程将增量式开发推向极致。2极限编程将软件进行再分解（refactoring），使得当新情节实现的时候软件总是容易理解和改变的。3.在创建程序特征之前开发自动测试。

3结对编程优点：1它支持共同拥有软件和共同对系统负责2它担当了非正式的复查过程3有助于支持重构

第四章

1需求工程过程包括可行性研究、需求导出和分析、需求描述、需求有效性验证及需求管理。2功能需求对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。非功能需求对系统提供的服务或功能给出的约束。时间约束、开发过程的约束、标准等。3功能需求描述系统所预期提供的功能或服务。取决于开发的软件类型、软件未来的用户以及开发的系统类型。理论上，系统的功能需求应该既全面又具有一致性。全面用户所需的所有服务都应该给出描述；一致性在对系统功能需求进行描述时，不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。

4非功能需求它们定义系统的属性和约束。非功能性需求比功能性需求更关键。产品需求这些需求定义或约束软件的行为。机构需求很广泛的系统需求，起源于客户所在的机构和开发者所在的机构中的政策和规定。外部需求包括所有来自于系统外部因素和开发过程的需求。非功能性需求可能是很难精确描述的，并且不精确的需求可能也难以得到检验。系统目标用户的一般的要求，比如系统的易用性。可检验的非功能需求应用某些度量进行描述，它们可以客观的得到验证。

5需求导出和分析（4个活动）：1需求发现这是一个与系统的信息持有者交流从而收集他们的需求的过程。来自信息持有者和文档的领域需求是在这个活动中得以发现的。2需求分类与组织所收集的需求是无序的，需要对其重新组织和整理，将其分为相关的几个组。3需求优先排序和协商对需求进行优先权排序，并通过协商发现且解决这些冲突。4需求描述记录需求并将它作为螺旋下一个循环的输入，产生形式化和非形式化的需求文档。系统需求导出和分析是困难的：1信息持有者表述泛泛2需求工程师没有领域知识3不同的信息持有者需求不同4政治上的因素影响系统需求5经济和业务环境是动态的6需求发现是一个收集准备建立的系统和正在使用的系统的信息，并从这些信息当中提取用户和系统需求的过程。信息源包括已有文件、系统信息持有者以及类似系统的相关内容。7脚本（场景）是对交互实例片段的描述。一个场景可能包扩以下内容：1在场景的开始部分有一个系统状态描述；2一个关于标准事件流的描述；3一个关于哪儿会出错以及如何处

理错误的描述；4有关其他可能在同一时间进行的活动的信息；5在场景完成后系统状态的描述。

第五章

活动图，表示一个过程或数据处理中所涉及的活动用例图，表示一个系统和它所处的环境之间的交互。时序图，表示参与者系统之间以及系统各部分之间的交互类图，表示系统中对象类以及这些类之间的联系状态图，表示系统是如何响应内外部事件的。

第六章

1明确设计和文档化软件体系结构好处：1信息持有者之间的沟通体系结构可以作为不同的项目相关人员之间讨论的焦点2系统分析系统分析对体系结构的设计决策，对系统能否满足非功能需求具有很大的影响3大规模复用体系结构能在相似需求的系统之间互用，以支持大规模的软件复用。

2分层体系结构分层模型用来把系统组织成一系列的层次，每一层提供一组服务。

3容器体系结构系统所有数据在一个中央容器中管理，该容器可被所有系统组件访问组件通过容器交互。优点它是共享大量数据的一个高效方法；子系统不必关心数据是如何集中进行的这些活动；共享模型能通过容器模式而看得见。缺点子系统一定要与容器数据模型一致，不可避免地，每个专用的工具之间要做出妥协；数据进化变得很困难和昂贵；容器模型迫使所有的子系统使用相同的策略；很难将容器有效的分配到多台机器上。4客户机/服务器体系结:优点数据的分布式最直接的;可以更有效地使用网络系统，从而降低了对硬件的要求；很容易就添加一台新的服务器或更新现有的服务器。缺点没有共享数据模型，子系统以不同的方式组织它们的数据。数据交换效率就可能很低；每个服务器上出现冗余数据管理；没有中央寄存器的名字和服务，这可能很难找出哪个服务器和哪些服务可用。5管道和过滤体系结优点：易于理解并支持变换的复用。缺点：通信变换间所传输的数据格式必须协商好。

第七章

1复用 1抽象层:不直接复用，运用软件设计中的成功抽象。2对象层：直接复用库中对象，代替自己编写代码3组件层：通常需要添加自己的代码对组件进行调成和扩展 4系统层：复用整个系统

2配置管理管理变更中软件系统的一般过程1版本管理对软件不同版本的追踪提供支持2系统集成提供支持帮助开发人员定义在创建每个系统版本时所用的组件版本 3问题追踪提供支持允许用户报告缺陷及其他问题，并允许开发人员谁在修复这些问题，以及何时完成修复。

第八章

1检验: “我们是否在正确地构造一个产品”。软件应该符合设计规格。有效性验证: "我们是否在构造一个正确的产品”。软件应该满足用户所需要的。

2商业软件测试3阶段：1开发测试2发布测试3用户测试

3开发测试：1.单元测试，对单独的程序单元活对象类进行测试（功能）。2组件测试，多个程序单元整合创建一个合成的组件（接口）3系统测试，一些或所有组件作为整体（交互）。4选择单元测试案例：1划分测试，识别具有共同特征和以同样方法处理的一组数据。2基于准则测试，使用测试准则来选择测试案例。

5准则：用一个只有单个值的序列来测试软件；在不同的测试中使用不同规模的多个序列；导出一个测试，让序列的第一个、中间一个和最后一个元素得到测试；测试序列的长度为零。原则：选择能强制系统生成的所有错误信息输入；设计能够使系统的输入缓冲溢出的输入；重复相同的输入或一系列输入很多次；使产生无效的输出；迫使输出结果太大或者太小。6组件测试：1参数接口数据从一个过程传到另外一个过程2共享内存接口内存块为过程或函数所共享3程序接口子系统封装一组程序，这些程序为其他子系统调用4消息传递接口子

系统通过传递消息请求其他子系统上的服务。接口错误3类：接口误用调用者组件在调用其他组件时因接口使用不当而发生接口错误。接口误解调用者组件误解了被调用组件的接口描述而产生错误，对呗调用组件进行了错误的假设。时序错误调用和被调用组件以不同的速度运行，中间过时的数据无法得到正确的处理.7用户测试：α测试：软件用户和开发小组一起在开发小组一起在开发者的地点测试这个软件。β测试：该软件的版本是提供给用户让他们进行测验，并向开发者提供发现的文题。接受测试：客户测试系统决定他们是否愿意从系统开发者哪里接收系统并在客户环境中部署。接收测试六个阶段：1.定义接受准则（合同）2.计划接受测试 3导出接收测试 4.运行接受、测试 5协商测试结果 6 拒绝/接收系统

第九章

1软件进化：变更请示、影响分析、版本规划（缺陷修补、平台适应、系统增强）、变更实现、系统发布。变更实现：提议的变更、需求分析、需求更新、软件开发紧急修补过程：变更请求、分析源代码、修改源代码、移交修改的系统。

2软件维护：

1、修补软件缺陷（纠正性）

2、是软件适应不同操作系统（适应性）

3、增加或修改系统功能（完善性）

3投入后代价增加原因：1团队稳定性2糟糕的开发实践3人员技术水平4程序年龄和结构。

第25章

1配置管理包括：变更管理：包括跟踪来自客户和开发者的软件变更请求，计算做出这些变更的花费并估计其影响，决定是否变更，何时完成变更。版本管理：包括跟踪系统组件的多个版本，确保由不同开发者对组件做出的变更不会彼此干涉。系统构建：是一个组装程序组件，数据和库的过程，然后把这些组件编译连接成一个可以执行的系统。发布管理：包括准备对完发布的软件，持续跟踪已经发布以供客户使用的系统版本。

2配置项（软件配置项）：与配置管理控制下的软件项目有关的任何事物。配置项会存在多个不同的版本，每个配置项都有一个唯一的名字。

3变更管理确保系统的进展是一个可管理的过程。主要关心的是对提建议的变更的成本收益分析，保证变更值得做，并记录系统的哪些组件已经改变。变更请求考虑的因素：不做变更会引起的后果，变更的益处，变更影响的用户数，变更所需花费，产品发布循环。

4版本管理是跟踪软件组件或配置信息以及使用这些组件系统的不同版本的过程。版本管理系统通常提供一系列特征：版本和发布版本识别被管理版本提交给系统时给他们分配标识符存储管理为了减少存储空间，版本管理系统会提供存储管理工具变更历史记录记录并列出所有对系统或组件作出的变更独立开发确保由不同的开发者对组件做出的变更互不影响项目支持一个版本管理系统可能支持共享组件的几个项目的开发。

第三篇：软件工程考点总结

关类组成一个层次结构的系统；

4、对象彼此间只能通过发送消息相互联系。

面向对象另一个优点是软件可重用。（6）：软件生命周期？

1、问题定义

2、可行性研究

3、需求分析

4、总体设计

5、详细设计

6、编码和单元测试

7、综合测试

8、软件维护

（7）：几个模型优缺点

1、瀑布模型

优点：可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

缺点：瀑布模型是由文档驱动的这个事实也是它的一个主要缺点。由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需求。

2、快速原型模型

优点：是不带反馈环的，软件产品开发基本上是线性顺序进行的。缺点：快速原型的本质是“快速”，开发人员应尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本，原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。

3、增量模型

优点：能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点，另一个优点是逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

缺点：把每个新的增量构件集成到现有的软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计的便于按这种方式进行扩充，软件体系结构必须是开放的。

4、螺旋模型

优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

缺点：是风险驱动的。软件开发人员具有丰富的风险评估经验和这方面专门的知识，否则项目实际上正在走向灾难时，开发人员可能还认为一切正常。

5、喷泉模型

优点：体现了面向对象软件开发过程迭代和无缝的特征。缺点：开发软件是会产生无序现象。

目的：就是用最小的代价在尽可能短的时间内确定问题是否能够解决。任务：在较高层次上以较抽象的方式进行的系统分析和设计的过程。以便于对以后的行动方针提出建议。

过程：

1、复查系统规模和目标

2、研究目前正在使用的系统

3、到处新系统的高层次逻辑模型

4、进一步定义问题

5、导出和评价供选择的解法

6、推荐行动方针

7、草拟开发计划

8、书写文档提交审查

（2）：数据字典4类元素

1、数据流

2、数据流分量

3、数据存储

4、、处理

（3）：成本估计技术

1、代码行技术

2、任务分解技术

3、自动估计成本技术

（4）：成本效益分析方法，考虑方面？

1、货币的时间价值

2、投资回收期

3、纯收入

4、投资回收率

（1）：设计过程的9个步骤

1、设想供选择的方案

2、选取合理的方案

3、推荐最佳的方案

4、功能分解

5、设计软件结构

6、设计数据库

7、制定测试计划

8、书写文档

9、审查和复审（2）：软件设计的原理

1、模块化

2、抽象

3、逐步求精

4、信息隐藏和局部化

5、模块独立（3）：启发规则

1、改进软件结构提高模块独立性

2、模块规模应该适中

3、深度、宽度、扇出和扇入都应适当

4、模块的作用域应该在控制域之内

5、力争降低模块接口的复杂程度

6、设计单入口单出口的模块

7、模块功能应该可以预测

（4）：面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法，信息流有变换流和事务流两种类型。

（1）：程序设计语言的标准

1、系统用户的要求

2、可以使用的编译程序

3、可以得到的软件工具

4、工程规模

5、程序员的知识

6、软件可移植性要求

7、软件的应用领域（2）：编码遵循的规则

1、程序内部的文档

2、数据说明

3、语句构造

4、输入输出

5、效率

（3）：软件测试的准则

1、所有测试都应该能追溯到用户需求。

2、应该远在测试开始之前就制定出测试计划。

3、把Pareto原理应用到软件测试中。

4、应该从”小规模“测试开始，并逐步进行”大规模“测试。

5、穷举测试是不可能的。

6、为了达到最佳的测试效果，应该由独立的

第四篇：软件工程小结

今天视频看完了，可是没有总结。还是感觉不会总结。一想到50讲的课，怎么总结呢？开始听的时候，是真不知道从哪里下手，因为开始看的时候有种迷迷糊糊的感觉。软件工程，我期待的一门课就这么听完了一遍。很有些囫囵吞枣的感觉，不过收获还是很多的，至少知道了软件工程的阶段不是只有需求分析、编程和测试维护。当然这个很早之前就知道，只是以前根本没有什么概念。

第一个阶段，计划阶段，要首先对用户的要求进行了解，对软件的性能等进行了解。然后进行可行性分析研究，在各种可行性研究中，对于软件开发人员来说，技术可行性研究最重要。之后就是需求分析阶段了，需求分析阶段也是计划阶段的最后一部分。需求分析定义了要做什么。把现实的需要用程序语言表达出来。但是这一阶段并不解决怎么做。

解决怎么做的是下一个阶段——设计阶段。设计阶段分为概要设计和详细设计。概要设计把每个组成部分的功能都给出意义明确的模块，每个模块都和一部分需求相对应。但是不考虑细节。详细设计，把每个模块的功能实现详细的表示出来，为源程序的编写打下基础。然后就是编程阶段，我们一般最初接触的就是编程，所以编程阶段比较了解，由于前期文档已经做的很详细，功能的实现数据和算法都已经清楚了，所以编程是比较简单的。

编程完了就是测试阶段了，测试阶段的费用是最多的。测试阶段是发现错误的阶段，改错是调试阶段。然后就是交付用户使用，及维护。

以上几点是软件工程的生命周期的六个阶段。软件工程过程和软件工程生命周期也不能等同。

软件工程过程如下：

软件规格说明：规定软件的功能及其运行的限制

软件开发：产生满足规格说明的软件：

软件的确认：确认软件能够完成客户提出的要求：

软件演进：为满足客户的变更要求。软件必须在使用的过程中演进。

pdca

软件工程过程与软件生存期相对应。软件规格说明对应计划阶段，软件开发对应设计、编程阶段，软件的确认对应测试调试阶段，软件演进对应运行维护阶段。

软件开发的每个过程都有相关文档，用老师们的话说叫做以文档为驱动。文档的好坏直接影响到软件开发的进度和软件的质量。而文档中最多的是使用图表，dfd图，sc图。数据流程图、过程流程图、系统流程图等各种图表。还是那句话，一张好的图表胜过一千句话。

在软件生存周期的各个部分都有各自要注意的地方，过着说是各自的重点（或者是知识点）。

今天已经是22号了，文档还没写。先写文档了。唉，又落后了。

第五篇：软件工程复习材料

1.软件的概念

一般可以将软件划分为系统软件、应用软件和介于这两者之间的中间件。计算机软件的传统定义为：软件是计算机系统中与硬件相依存的另一部分，软件包括程序、数据及其相关文档的完整集合。

程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。

2.软件的特性

1)形态特性。软件是无形的、不可见的逻辑实体。2)智能特性。3)开发特性。4)质量特性。5)生产特性。6)管理特性。7)环境特性。8)维护特性。9)废弃特性。10)应用特性。

软件危机：软件开发周期长、成本高、质量差、维护困难 原因

1)缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作的计划很难制订；

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

3)软件开发过程不规范，缺少方法论和规范的指导；

4)随着软件规模的增大，其复杂性往往会呈指数型增长； 5)缺少有效的软件评测手段，提交用户的质量差。

1.1.1 软件工程的概念

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

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

1.1.2 软件工程的目标

软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。

衡量软件质量的6个特性：功能性、可靠性、可使用性、效率、可维护性和可移植性。1.1.3 软件工程的基本原理 按软件生存周期分阶段制订计划并认真实施； 3 坚持进行阶段评审； 4 坚持严格的产品控制； 5 使用现代程序设计技术； 6 明确责任； 7 用人少而精； 不断改进开发过程

软件生存期: 软件定义：问题定义、可行性研究和需求分析

软件开发：概要设计、详细设计、编码和测试

运行维护：改正性维护、适应性维护、完善性维护和预防性维护

软件工程方法学包含3个要素：方法、工具和过程。

3.1 软件需求分析阶段的任务：获取需求、分析需求、定义需求和验证需求

3.4 数据建模三要素：数据对象，属性，关系 3.5 行为建模三要素：状态，状态转换，事件

1.1.1 软件设计的阶段与任务：两个阶段：概要设计阶段和详细设计阶段

1.1.2 模块独立性

1)松散耦合：非直接耦合，数据耦合，标记耦合，控制耦合，外部耦合，公共耦合，内容耦合。

高度内聚：巧合内聚，逻辑内聚，时间内聚，过程内聚，通信内聚，信息内聚，功能内聚

1.1.3 设计过程

(1)复查并精化数据流图；

(2)确定数据流图中数据流的类型，典型的数据流类型有变换型数据流和事务型数据流；

(3)导出初始的软件结构图；(4)逐级分解；

(5)精化软件结构；

(6)导出接口描述和全局数据结构

1.1.4 软件模块结构的改进方法 1)模块功能的完善化；

2)消除重复功能，改善软件结构；

3)模块的作用范围应在控制范围之内；

4)尽可能减少高扇出结构，随着深度增大扇入； 5)避免或减少使用病态连接； 6)模块的大小要适中

5.1.2 自顶向下、逐步细化的设计过程

一是将复杂问题的解法分解和细化成由若干个模块组成的层次结构； 二是将每个模块的功能逐步分解细化为一系列的处理。

7.1面向对象的主要概念(1)对象(2)类(3)继承

(4)消息：把向对象发出的操作请求称为消息；(5)关联：是两个或多个类之间的一个静态关系；

(6)聚合：一个对象由其它若干个对象作为其构成部分。

7.2基本原则主要有：抽象、分类、封装、消息通信、多态性、复杂性控制

8.1面向对象分析（OOA）是软件生命周期的一个阶段，具有一般分析方法所共有的内容、目标及策略。

(1)OOA模型分为3个层次：对象层、特征层和关系层。

12.1.1 软件维护的定义

称在软件运行/维护阶段对软件产品所进行的修改就是所谓的维护。1.改正性维护：诊断和改正错误的过程；

2.适应性维护：为了使软件适应外部环境或数据环境可能发生的变化，而修改软件的过程称为适应性维护； 3.完善性维护：

修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性，这种情况下进行的维护活动称为完善性维护。4..预防性维护

12.2 软件维护活动 1 软件维护申请报告 2 软件维护工作流程 3 维护档案记录 4 维护评价

12.3.3 修改程序的副作用以及其控制

所谓副作用是指因修改软件而造成的错误及其它不希望发生的情况 1.修改代码的副作用 2.修改数据的副作用 3.修改文档的副作用

12.4.1软件可维护性的定义

所谓软件可维护性，是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。

12.4.2 可维护性的度量 1.可理解性 2.可靠性 3.可测试性 4.可修改性 5.可移植性 6.效率

7.可使用性

10.2 传统软件过程模型 10.2.1 瀑布模型： 优点：（1）可强迫开发人员采用规范化的方法

（2）严格的规定了每个阶段必须提交的文档

（3）要求每个阶段交出的所有产品必须是经过验证的 缺点：（1）几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需求

（2）瀑布模型只适用于项目开始时需求已确定的情况

10.2.2 快速原型模型

优点：(1)有助于满足用户的真实需求。

(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。

(3)软件产品的开发基本上是按线性顺序进行。

(4)因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。

(5)开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。(6)快速原型的突出特点是“快速”。10.2.3 增量模型

优点;(1)能在较短时间内向用户提交可完成一些有用的工作产品

(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。(3)项目失败的风险较低

(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。10.2.4 螺旋模型 • 优点

 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。

 减少了过多测试或测试不足所带来的风险。

 在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。• 缺点

 螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。

10.2.5 喷泉模型