毛明志老师软件工程期末总结内容填充版over.docx
《毛明志老师软件工程期末总结内容填充版over.docx》由会员分享，可在线阅读，更多相关《毛明志老师软件工程期末总结内容填充版over.docx（92页珍藏版）》请在冰豆网上搜索。
毛明志老师软件工程期末总结内容填充版over
第一章：
1.1
补充一下1.1
计算机软件：
指计算机系统中的程序及其文档。
程序是计算任务的处理对象和处理规则的描述。
1.1.2
软件的特点：
1软件是一种逻辑实体，开发成本和进度难以准确估算；
2软件是被开发或被设计的，没有明显的制造过程，一旦开发成功，只需复制，但维护的工作量大
3软件使用没有硬件的机械磨损和老化问题，但使用过程有维护问题，维护修改程序的时候可能引入副作用，使故障率升高。
1.1.3
软件的分类
1系统软件：
操作系统、编译程序等
2支撑软件：
数据库管理系统、网络软件等
3应用软甲：
各类特定应用程序
1.2
1.2.1
软件工程定义
IEEE：
软件工程是：
①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
②在①中所述方法的研究。
1.2.2
软件工程框架：
概括为目标、过程和原则
目标：
生产具有正确性，可用性和开销合宜的产品。
过程：
生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。
原则：
①选取适宜的开发模型
②采用合适的设计方法
③提供高质量的工程支撑
④重视软件工程的管理
1.2.3
软件生存周期：
六阶段
①计算机系统工程：
确定软件开发的要求和范围，估算成本，安排进度，可行性分析。
②需求分析：
要“做什么”，确定软件功能、性能、数据、界面等要求，生成软件需求规约。
③设计：
要“怎么做”，分为系统（总体）设计和详细设计。
前者设计软件系统的体系结构，包括软件系统的组成部分，各成分的功能和接口，成分间的连接和通信，同时设计全局数据结构；
后者设计各个组成成分的实现细节，包括局部数据和算法
④编码：
用某种程序设计语言，将设计结果转换为可执行代码。
⑤测试：
任务是发现并纠正软件中的错误和缺陷。
主要包括单元测试、集成测试、确认测试和系统测试。
⑥运行和维护：
软件测试完成即可交付使用。
在软件运行期间，需对投入运行的软件进行维护，即当发现软件中潜藏错误或需要增加功能或适应新外部环境变化等，对软件进行修改。
1.3
1.3.1了解
ISO/IEC12207软件工程生存周期过程
该标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个组织过程。
每一个过程划分为一组活动，每项活动又进一步划分为一组任务。
（内容坑爹，无视，P9~P12约3页的表格，有兴趣的自己看
（话说了解比知道要轻..现在我这么觉得
1.3.2
能力成熟度模型CMM
5级：
初始级：
无秩序或混乱，成功依赖个人或小组的努力
可重复级：
建立了基本的项目管理过程来跟踪成本、进度和功能特性。
制定了必要的过程纪律，能重复早先类似应用项目的成功。
已定义级：
以将管理和工程活动两方面的软件过程文档化、标准化，并综合成该组织的标准软件过程。
所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
已管理级：
收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。
优化级：
过程的量化反馈和先进的新思想、新技术促使过程不断改进
CMM的结构P14有兴趣的..
1.3.3知道
能力成熟度模型集成CMMI
两种表示法：
①阶段式模型：
同CMM，关注组织成熟度，5级
初始的、已管理的、已定义的、定量管理的、优化的。
②连续式模型：
关注每个过程域的能力，分为6级：
CL0：
未完成的：
未执行或未达到CL1定义的所有目标
CL1：
已执行的：
共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
CL2：
已管理的：
共性目标集中于已管理的过程的制度化。
CL3：
已定义级的：
共性目标集中于以定义过程的制度化。
CL4：
定量管理的：
共性目标集中于可定量管理的过程的制度化。
CL5：
优化的使用量化（统计学）手段改变和优化过程域，以对付客户要求的该百年和持续改进计划中的过程域的功效。
1.4
常见模型的种类，特点，优缺点，不同模型间对比
瀑布模型：
一路向下，可倒流回到上一级，7级
系统工程->需求分析与规约->设计与规约->编码与单元测试->
集成测试系统测试->运行与维护
演化模型：
先做原型给用户，根据使用意见逐步改造，最终得到令客户满意的产品。
典型的模型有：
增量模型、原型模型、螺旋模型（..居然这模型和后面这三种在同一级的标题
增量模型：
将开发过程分成若干个日程时间交错的线性序列，每个线性序列都产生软件的一个可发布“增量版本”。
（越看越像流水线
原型模型：
快速计划->快速设计方式建模->构建原型->部署交付和反馈->交流->快速计划……不断循环。
根据原型目的不同可分为：
探索型、实验型、演化型。
使用策略分为废弃策略、追加策略。
螺旋模型：
制定计划->风险分析->工程实施->客户评估不断循环。
风险太大则可能终止
喷泉模型：
支持面向对象开发的过程模型，开发各个活动没有明显边界，各个活动经常重复、迭代地进行。
“喷泉”体现了面向对象方法的迭代和无间隙特性。
六个活动：
演化，集成，测试，编码，设计，分析
1.5
敏捷软件开发基本概念，XP开发特点
敏捷软件开发概念：
书上没有，自由发挥。
简单而言就是软件工程用了，质量提高了，但工作量太大以至于难以准时交付，于是快节奏开发软件的需求就来了，方法也出来了，这些方法就是敏捷软件开发。
敏捷软件开发价值观：
①个人和交互高于过程和工具
②可运行软件高于详尽的文档
③与客户协作高于合同（契约）谈判
④对变更及时作出反应高于遵循计划
敏捷软件开发原则：
12条P27有兴趣的话..
XP:
extremeprogramming极限编程。
四个价值观：
交流，简单，反馈，勇气（追加第5个谦虚）。
XP适用于软件需求模糊且挥发性（今天要求明天可能就不需要了）强，开发团队人数在10人以下，开发地点集中的场合。
（这是特点么..?
XP方法的12个核心实践P29-30怎么都是这种..
1.完整的团队
2.计划对策
3.系统比喻
4.小发布
5.测试
6.简单设计
7.结对编程
8.设计改进
9.持续集成
10.代码全体共享
11.编码标准
12.可持续步调
第二章
2.1
计算机系统的概念，内容
基于计算机的系统：
通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。
组成基于计算机系统的元素主要有：
软件、硬件、人员、数据库、文档和规程。
软件：
计算机程序、数据结构和相关的工作产品，以实现所需要的逻辑方法、规程和控制；
硬件：
指提供计算能力的电子设备、支持数据流的互连设备、提供外部世界功能的电子机械设备（传感器，马达等）。
人员：
硬件和软件的用户和操作者。
数据库：
通过软件访问并持久存储的大型的有组织的信息集合。
文档：
描绘系统使用或操作的描述性信息。
规程：
指定义每个系统元素的特定使用或系统所处的过程性语境的步骤。
一个基于计算机的系统可以是另一个更大的基于计算机的系统的一个宏元素（组成部分）。
2.3
可行性分析的概念，分类
可行性分析：
一个基于计算机的系统通常受到资源和时间上的限制，可行性分析主要从经济、技术、法律等方面分析给出的解决方案是否可行，能否在规定的资源和时间约束下完成。
可行性分析分类：
①经济可行性：
从成本、效益、货币的时间价值（通常可用年利率来表示）、投资回收期、纯收入来分析。
②技术可行性：
分为风险分析、资源分析、技术分析。
③法律可行性。
第三章
需求工程的角色及其各个阶段//好吧，其实就是全部
3.1概述
需求工程是应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题，评估可行性，协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理要求，需求工程通过合适的工具和符号系统地描述开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
分为6阶段：
①需求获取：
通过与用户交流，对已有系统的观察及对任务的分析，确定系统或产品范围等。
②需求分析与协商：
对需求进行分类组织，分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求排序。
③系统建模：
通过合适的工具和符号地描述需求。
分析和建模方法有：
面向数据流方法、面向数据结构方法和面向对象方法。
④需求规约：
需求规约是分析任务的最终产品，建立完整的信息描述、详细功能和行为描述、性能需求和设计约束说明、合适的验收标准，给出对目标软件的各种需求。
⑤需求验证：
对功能的正确性、完整性和清晰性以及其他需求给予评价。
⑥需求管理：
对需求工程所有相关活动的规划和控制。
3.2需求获取
3.2.1软件需求
①功能需求：
系统要做什么，在何时做，在何时及如何修改或升级
②性能需求：
软件开发的技术性指标
③用户或人的因素：
用户类型
④环境需求：
软件应用的环境，包括硬件和软件。
⑤界面需求：
考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。
⑥文档需求：
需要什么文档，针对哪些读者
⑦数据需求：
考虑输入、输出数据的格式，接受、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。
⑧资源使用需求：
考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发、维护所需人力、支撑软件、开发设备等。
⑨安全保密要求。
⑩可靠性需求
①①软件成本消耗与开发进度需求
①②其他非功能性要求。
3.2.2需求获取方法与策略
①建立顺畅的通信途径
②访谈与调查
③观察用户操作路程
④组成联合小组
⑤用况
3.3需求分析、协商与建模
3.3.1需求分析原则
·必须能够表示和理解问题的信息域
·必须能够定义软件将完成的功能
·必须能够表示软件的行为（作为外部事件的结果）
·必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。
·分析过程应该从要素信息移向细节信息。
3.3.2信息域
信息域包括：
信息内容：
表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。
信息流：
表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息（数据或控制），然后进一步被变换为输出。
信息结构：
表示了各种数据和控制项的内部组织形式，比如数据或控制项将被组织为n维表还是树形结构..?
等
3.3.3抽象、分解与多视点分析
问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系，首先关注一般问题的解决途径，进而指导特殊问题的解决方法。
问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。
分析人员在整理用户描述的过程中应注意用户视角上的变化，避免由于视角不全引起的需求遗缺。
3.3.4需求协商
复杂的系统又许多项目相关人员，他们之间的需求必定会出现冲突，协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案。
通常会议是解决冲突最快的方式。
冲突解决会议应当只关注与冲突相关的需求问题。
通常会议分为3个阶段：
叙述阶段、讨论阶段和决策阶段。
3.3.5需求建模
在需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做。
目标软件的需求模型不应涉及软甲你的实现细节。
常用的分析方法有以下几种：
面向数据流的结构化分析方法（SA）
面向数据结构的分析方法
面向对象的分析方法（OOA）
3.4需求规约与验证
3.4.1需求规约的原则
①从现实中分离功能
②使用面向处理的规约语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应。
③如果被开发软件知识一个基于计算机的系统中的一个元素，那么整个大系统也应包括在规格说明的描述中
④规约必须包括系统运行环境。
⑤规约必须是一个认识模型，而不是设计或实现的模型。
⑥规约必修是可操作的，利用它能够通过测试用例判断已提出的解决方案是否都能满足规约。
⑦规约必须允许不完备性并允许扩充。
⑧规约必须局部化和松散耦合。
3.4.2需求规约
软件需求规约的框架IEEE/ANSI830-1993标准：
1引言
2信息描述
3功能描述
4行为描述
5检验标准
6参考书目
7附录
3.4.3需求验证
需求验证的目的是要检验需求是否能够反映用户的意愿。
评审人员评审时往往需要检查以下内容：
①系统定义的目标是否与用户的要求一致
②系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求。
③被开发项目的数据流与数据结构是否确定且充足。
④主要功能是否已包括在规定的软件范围之内，是否都已充分说明
⑤设计的约束条件或限制条件是否符合实际。
⑥开发的技术风险是什么。
⑦是否制定了详细的检验标准，它们能否对系统定义进行确认。
3.5需求管理
需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动。
在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求和其他需求或设计文档、代码、测试用例的不同版本间的关系。
需求跟踪有两种方式：
正向跟踪以用户需求为切入点，检查《需求规约》中的每个需求是否能在后继工作中找到对应点；逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在《需求规约》中找到出处。
第四章
4.1软件设计工程概述
软件设计是把软件需求变换成软件表示的过程，主要包含两个阶段：
软件体系结构（概要）设计阶段和部件级设计阶段。
软件体系结构设计：
将软件需求转化为数据结构和软件的系统结构。
部件级设计：
将软件体系结构中的结构性元素转化为软件部件的过程性描述，得到软件详细的数据结构与算法。
4.1.1软件设计的任务
软件设计的输入的软件分析模型。
使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、部件级设计。
①数据/类设计：
将分析类模型变换成类的实现和软件实现所需要的数据结构。
②体系结构设计：
定义了软件的整体结构，由软件部件、外部可见的属性和它们之间的关系组成。
③接口设计：
描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。
主要包括3方面内容：
设计软件模块间的接口，设计模块与其他非人的信息生产者和消费者之间的外部接口以及设计人与计算机间的人机接口。
④部件级设计：
将软件体系结构的结构性元素变换为对软件部件的过程性描述。
4.1.2软件设计的目标
①设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
②设计必须是可读，可理解的，使得将来易于编程、易于测试、易于维护。
③设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
为达到目标所建立的设计的技术标准：
①设计出来的结构应是分层结构，从而建立软件成分之间的控制。
②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。
③设计应该既包含数据抽象，也包含过程抽象。
④设计应当建立具有独立功能特征的模块。
⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。
⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
4.1.3软件设计的过程
软件设计是一个把软件需求编程软件表示的过程，通常软件设计过程分为6个步骤：
①制定规范
②体系结构与接口设计
③数据/类设计
④部件级（过程）设计
⑤编写设计文档
⑥设计评审
4.2软件设计原则
在将软件的需求规约转换为软件设计的过程中，软件的设计人员通常采用抽象与逐步求精、模块化和信息隐藏等原则。
4.2.1抽象与逐步求精
①抽象：
将注意力集中在某一层次上考虑问题，忽略低层次的细节。
软件工程的每一步都是对较高一级抽象的解作一次具体化的描述。
软件设计的主要抽象手段有：
过程抽象：
任何一个完成明确定义功能的操作都可被使用者当做单个实体看待，尽管这个操作实际上是由一系列更低级的操作完成的（类似函数的概念
数据抽象：
指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据（类似类的概念。
②逐步求精：
把问题的求解过程分解成若干步骤或阶段，每一步都比上一步更精化，更接近问题的解法。
抽象和逐步求精是一对互补的该你那，抽象使设计者能够描述过程和数据而忽略底层的细节，而求精有助于设计者在设计过程中揭示底层的细节。
4.2.2模块化
模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。
模块化实际上是系统分解和抽象的过程。
在软件工程中，模块是数据说明、可执行语句等程序对象的集合，是单独命名的，并且是可以通过名字来访问的。
例如，对象类、构件、过程、函数、子程序、宏等都可以作为模块。
模块具有名字、参数、功能等外部特征以及完成模块功能的程序代码和模块内部数据等内部特征。
假设C（x）是描述问题x复杂性的函数，E（x）是解决问题x所需工作量（按时间算）的函数，则有：
①若C（p1）>C（p2）则E（p1）>E（p2）
②C（p1+p2）>C（p1）+C（p2）
由①、②可推出
③E（p1+p2）>E（p1）+E（p2）
但虽然有③式存在，模块划分并非越多越好，因为还存在着将模块联接起来的工作量。
4.2.3信息隐藏
每个模块的实现细节对于其他模块来说应该是隐蔽的，即模块中包含的信息（包括数据和过程）不允许其他不需要这些信息的模块使用。
4.2.4模块独立
所谓的模块独立指：
模块完成独立的功能并且与其他模块的接口简单，符合信息隐蔽，模块间关联和依赖程度尽可能小。
模块独立性是模块化、信息隐藏和局部化等概念的直接结果。
模块的独立性很重要，体现在：
①功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。
②由于因设计和编码修改引起的副作用受到局限，错误传播被减少，并且模块复用成为可能，所以独立的模块更易于测试和维护。
模块的独立性可以由两项指标来衡量：
内聚度和耦合度。
内聚度：
衡量同一个模块内部的各个元素彼此结合的紧密程度。
耦合度：
衡量不同模块彼此间相互依赖的紧密程度。
4.2.4.1内聚
一般模块内聚性分为7种类型，由低到高分别是：
①巧合内聚：
将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块。
②逻辑内聚：
完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能。
③时间内聚：
一个模块中的所有任务必须在同一时间段内执行，例如初始化模块和终止模块。
④过程内聚：
一个模块完成多个任务，这些任务必须按指定的过程执行。
⑤通信内聚：
一个模块内所有处理元素都集中在某个数据结构的一块区域中。
⑥顺序内聚：
一个模块完成多个功能，这些功能又必须顺序执行。
⑦功能内聚：
一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割。
4.2.4.2耦合
一般模块之间的可能的耦合方式有7种，由高到低分别是：
①内容耦合：
一个模块直接访问另一个模块的内部数据；或一个模块不通过正常入口转到另一模块内部；或两个模块有一部分代码重叠；或一个模块有多个入口。
②公共耦合：
一组模块都访问同一个公共数据环境。
公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
③外部耦合：
模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时。
④控制耦合：
一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接受模块中的执行逻辑。
⑤标记耦合：
两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构）。
⑥数据耦合：
两个模块之间仅通过参数表传递简单数据。
⑦非直接耦合：
两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能够独立工作。
强耦合->低内聚
强内聚->低耦合
耦合和内聚都是模块独立性的定性标准，都反映了模块独立性的良好程度，但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。
4.3软件体系结构设计
4.3.2软件体系结构的风格
一些软件体系结构风格：
①数据为中心的体系结构：
一些数据保存在整个结构中心，并且被其他部件频繁地使用、添加、删除、修改。
②数据流风格的体系结构：
适用于输入数据被一系列的计算或者处理部件变换成输出数据。
由管道和过滤器组成，过滤器之间由传送数据的管道联通。
③调用和返回风格的体系结构：
包含主程序/子程序风格体系结构和远程过程调用风格的体系结构。
前者把功能分解成控制层次，顶层调用下层，下层调用下下层，最下层完成最具体的功能；后者是前者的扩展，这种结构中被主程序调用的部件分布在网络上不同的计算机中。
④面向对象风格的体系结构系统部件封装数据和操作数据的方法，部件之间的交互和协调通过消息来传递。
⑤层次式风格的体系结构：
圆环套圆环，最外面层部件向用户提供接口操作，最内层部件使用系统接口，每个中间层都是对内层接口的封装。
4.4部件级设计技术
在部件设计阶段，主要完成如下工作：
①为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述。
②确定每一部件内部使用的数据结构。
③在部件级设计结束时，应该把上述结果写入部件级设计说明书，并通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。
4.4.1结构化程序设计方法
如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
结构化程序设计方法能提高程序的可读性、可维护性和可验证性，从而提高软件的生产率。
4.4.2图形表示法
4.4.2.1程序流程图
入口出口：
圆角矩形
顺序语句：
矩形
条件分支：
菱形
只允许5种基本控制结构：
顺序型，选择型、先判定型循环、后判定型循环、多情况选择型，如下所示：
4.4.2.2N-S图
懒的画了
4.4.2.3PAD
PAD=problemanalysisdiagram
4.4.3判定表
简单而言就是列出所有条件可能组合以及对应的操作。
4.4.4设计性语言PDL
某种伪代码，关键字一律大写，其他单词一律小写。
PROCEDUREspellcheckIS查找错拼的单词
BEGIN
splitdocumentintosinglewords
把整个文档分离成单词
loodupwordsindictionary
在字典中查这些单词
displaywordswhicharenotindictionary
显示字典中查不到的单词
createanewdictionary造一新字典
ENDspellcheck
P85课后题，第2,4,5,8题
以下问题答案不保证正确性
4.2软件设计和软件质量的关系是怎么样的
答：
在进行软件设计的过程中，我们要密切关注软件的质量因素。
同时软件质量也很大程度依赖于软件设计。
4.4简述模块、模块化及模块化设计的概念
答：
升级会员 