不是按书本顺序来的，所以读起来可能会有点吃力
软件定义：软件=“完成特定功能的程序+数据结构+文档”。
软件工程定义： IEEE给出的定义：将系统化的，规范的，可度量的方法用于软件开发，运行和维护的过程，即将工程化应用于软件开发中。
软件危机的定义：在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机的表征：
(1) 对软件开发成本和进度的估计常常很不准确。[造成预算错误，甚至亏本]
(2) 用户对“已完成的”软件系统不满意的现象经常发生。[例：路口人流开发为车流]
(3) 软件产品的质量往往靠不住。
(4) 软件常常是不可维护的。[结构设计问题，很难扩充]
(5) 软件通常没有适当的文档资料。[造成无法理解]
(6) 软件成本在计算机系统总成本中所占的比例逐年上升。[很难控制其在某个范围内]
(7) 软件产品“供不应求”。[无法满足各行各业的需求]
可行性分析需要考虑的内容（选择题）：技术可行性，经济可行性，操作可行性
需求分析的任务：确定软件系统的功能。
需求分析的主要内容：问题分析，需求描述和需求评审。
需求分析的目的：用于说明软件产品或软件项目需要满足的条件和限制。在软件工程项目中首先要获取用户的需求，通过对软件需要的提取、分析、文档化及验证，为进一步的设计和实现提供依据。
需求分析需要考虑的内容（选择题）：功能需求，性能需求，可靠性和可用性需求，出错处理需求，接口需求，约束，逆向需求，将来可能提出的需求
需求分析建立的三个模型（填空题）：数据模型、功能模型、行为模型
软件工程的主要目的和次要目的：
主要目的：提高软件质量；实现预期的软件功能，达到较好的软件性能，满足用户的需求。
次要目的：增强软件的可见性和可控性，保证软件的质量；提供所开发软件的可维护性，降低维护费用；提高软件开发成本，即使交付使用；合理预算开发成本，付出较低的开发费用。
软件生命周期组成：
软件定义时期：问题定义，可行性研究，需求分析
开发时期：总体设计，详细设计，编码和单元测试，综合测试
维护时期：软件维护
软件测试(Verification) Vs. 软件验证(Validation) 解释区别
测试：客观的！重要的是满足最开始的预期的需求
验证： 客观+主观的。包括测试，重要的是做客户需要的
结构化程序设计语言 定义：少用GO TO语句的高级语言，最好仅在检测出错误时才使用GO TO 语句，而且总是使用向前的GO TO语句.
结构化程序设计的基本思想（必背）：自顶向下，逐步求精，模块化的结构化分析方法。
结构化程序设计的定义：以模块化设计为中心，将待开发的软件系统划分为若干个相互独立的模块，各模块通过“顺序，选择，循环”的控制结构进行连接，并且只有一个入口，一个出口
软件总体设计的主要任务 （选择题）：概括地说，系统应该如何实现预定的任务
软件详细设计的主要方法 OOAD也属于结构化程序设计
要维护阶段的文档所包括的类型：用户文档和系统文档
用户文档：描述功能，不关心功能怎么实现的。
系统文档：从问题定义、需求说明到验收测试计划等一系列和系统有关的文档。
提高程序可读性的方法 ：代码规范! 使用三种标准控制结构；采用有实际意义的变量名；给程序加注释。
可维护性的决定因素，并且该如何提高可维护性：
- 可理解性，提高可理解性：模块化，详细的设计文档，结构话设计，程序内部文档，良好的高级程序设计语言。
- 可测试性，提高可测试性：软件结构，可用的测试工具和调试工具、设计好的测试过程。
- 可修改性，提高可修改性：耦合，聚合，信息隐藏，局部化，控制域与作用域的关系。
- 可移植性，提高可移植性：高级程序设计语言
- 可重用性，提高可重用性：经过严格测试的可重用软件构件，软件中使用较多的可重用软件构件。
控制域：这个模块本身和所有直接或间接从属它的模块的集合
作用域：受该模块内一个判定影响的所有模块的集合
A的控制域是B C D E F，如果A中修改了某一个static变量，而G又使用了这个static变量，那A的作用域就是G B C D E F，所以控制域属于作用域，作用域不一定属于控制域。但是在设计的时候，尽量让作用域在控制域之内
软件维护定义：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程、
软件维护地四种类目 列举/定义
改正性维护：诊断和改正错误的过程。Example：球买来踢不了，比如说软件下载下来登录没办法成功，APP用着突然出错
适应性维护：为了和变化了的环境适当地配合而进行的修改软件的活动。Example:比如玩游戏的时候用PSN，PS升级操作系统以后，有些游戏就玩不了了，必须要下载最新的游戏才能玩。Windows在线从8升级到10，有些软件就用不了了。手机系统更新以后必须要去商店下载最新的APP才能玩游戏。
完善性维护（占比最高）：用户增加新功能或修改已有功能的建议,example：微信新增拍一拍功能。王者荣耀对英雄的输出的修改。原来一个软件最多一次有100人使用，用的人越来越多，就修改软件，让每次能同时有更多人使用。
原来要求软件点菜，现在要求软件点外卖
预防性维护：改进未来的可维护性或可靠性，给未来的改进奠定更好的基础而修改软件。Example：比如系统原来只会显示1900-1999年，进入21世纪以后需要让时间能显示2000+
软件过程定义：为了获得高质量软件所需要完成的一系列任务的框架。概括地说，软件过程描述为了开发出客户需要的软件，who,when,where,what,how做这些事以实现某一个特定的具体目标
软件过程的主要模型（选择+解答）：瀑布/(后面全是叠加)快速原型/增量/螺旋/敏捷方法 特点/区别
- 瀑布模型******
主要特点：[方括号里是便于理解记下来的，不用背方括号里的内容]
- 阶段间具有有顺序性和依赖性 [每步依赖于前步结果]
- 推迟实现的观点 [尽可能推迟物理设计，做好逻辑设计可以事半功倍]——典型特点
- 质量保证的观点 [每个阶段都要有文档，评审之后再进行下一项工作，防止错误的放大]
瀑布模型的问题： - 实际的项目很少顺序严格 混乱；
- 用户往往难以给出具体、正确、完整的要求，很可能导致用户的需求不能被真正满足；
- 用户必须有耐心 产品出现晚+大错误灾难；
- 发开人员“阻塞状态”严重，效率低。
- 快速原型模型：[获取正确的模型再设计实现]
优点：
- 有助于保证用户的需求得到真正的满足；
- 不带反馈；
- 最能适应快速变化的需求。
- 增量模型：[将软件分为多个部件组件实现]
特点：
- 结合了线性模型和原型模型的特点；
- 每个增量可以结合原型法 [该增量交付后就修改系统，降低了修改全部系统的成本]；
- 系统的问世提前 用户尽早看到产品。
问题：开放的软件体系结构 [需要将模块合理的组织起来]。
- 螺旋模型：[可以看作在每个阶段之前都增加了风险分析过程的快速原型模型]
优点：
适合规模庞大，复杂且高风险的项目。 - 喷泉模型：[体现了面对对象软件开发过程迭代和无缝的特性]
敏捷过程的四个价值观：
- 个体和交互胜过过程和工具；
- 可以工作的软件胜过面面俱到的文档；
- 客户合作胜过合同谈判；
- 响应变化胜过遵循计划。
功能性属性定义：系统所应提供的服务。
非功能性属性(软件质量) 定义:如何执行，执行得好不好。
主要的非功能性属性列举/定义/解释：
- 可靠性：产生一个错误的平均时长。一个月出一个错的系统和一天出一个错误的系统，明显前者的可靠性更高。
- 响应时间：对给定输入做出反应的时间。我的软件跟你软件功能一样，但是我的用户跟多，是因为我软件不卡顿，不用等待太长时间。
关注 定义：制作程序的时候集中解决特定概念的目标。将整体看成为部分的组合，一个部分就是一个关注点。
关注分离 定义/解释：只标识，封装和操纵关注点的能力。解释：将整体看成为部分的组合并对各个部分分别加以处理，最后综合各部分的结果，合成整体的解决方案。
聚合(内聚) 定义/解释：一个模块内部元素之间彼此结合的紧密程度。
聚合(内聚)的7种类目 定义/区别/解释
偶然—逻辑—时间——过程—通信——顺序—功能
低——————— 中 —————— 高
偶然内聚：如果一个模块完成一组任务，这些模块之间即使有联系，关系也是松散的。
逻辑内聚：将若干具有逻辑相似性的功能段放在一个模块内。
时间内聚：把在系统运行的同一时间处理的元素组合成一个模块（比如系统的初始化）。
过程内聚：模块内的处理元素是相关，且须以特定次序执行。（根据程序流图确定模块划分时，通过得到过程内聚的模块）。
通信内聚：如果模块中所有元素都使用同一输入数据和产生同一输出数据，称为通信内聚。
顺序聚合：如果一个模块内的处理元素和同一功能密切相关，而且处理必须按照顺序执行。
功能聚合：如果模块内的所有的处理元素属于一个整体，完成一个单一的功能。（是最高成的内聚）
耦合 定义/解释：对一个软件内不同模块之间互联程度的度量。
高内聚，低耦合是最好的！！！！！！
耦合的5种类目 定义/区别/解释
数据耦合—控制耦合—特征耦合—公共环境耦合—内容耦合
低 ————————————————————— 高
内容耦合：一个模块修改另一个模块的内容。
公共耦合：若干模块通过一个公共数据环境相互作用。
特征耦合：当把整个数据结构作为参数传递而被调用模块只需要使用其中一部分数据元素时，就出现了特征耦合。
控制耦合：一个模块通过传递开关、标志、名字等控制信息，明显地控制选择另一个模块的功能。
数据耦合：如果两个模块彼此间通过参数交换信息，而交换的信息仅仅时数据，叫数据耦合。
软件工程中的错误放大性效应 解释（考释义）：错误发现、改正得越晚，需付出的代价越高。
软件需求的变化性 解释：因为用户的意愿或者时间的变化，需求极易发生改变。
软件体系架构 定义：将系统中的各个模块组成良好的层次关系。
模块/模块化/信息隐藏/局部化/模块独立 定义/解释：
模块：由边界元素限定的相邻程序元素的序列，而且由一个总体标识符代表它。
模块化：把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，模块集成起来构成一个整体，可以完成用户指定的功能。
信息隐藏：应这样设计和确定模块，使得一个模块内包含的信息对于不需要这些信息的模块来说，是不能访问的。
局部化：把一些关系密切的软件元素物理地放得彼此靠近。
模块独立：希望设计这样的软件结构，使得每个模块完成一个相对独立的子功能，并且和其他模块之间的关系很简单。模块独立是模块化，抽象，信息隐藏和局部化概念的直接结果。
对象/对象三要素/类/面向对象 定义/解释（必须会）：
对象：一个包含数据结构和施加其上的操作的封装体。
对象三要素：封装，继承，多态。
类：对具有相同属性和行为的一个或多个对象的描述。
面对对象：软件开发过程中，抽取和整理用户需求并建立问题域精确模型的过程叫面对对象分析。
抽象数据类型 Vs. 类 区别/解释：抽象数据权限是public ,类有信息隐藏
白盒测试（最重要）/黑盒测试/灰盒测试（介于白跟黑） 区别
白盒测试：通过分析程序的内部逻辑结构来设计测试用例，检测程序中的主要执行通道是否都按照预定要求正确执行。
黑盒测试：如果已经知道了产品应该具有的功能，可以通过黑盒测试来检验是否每个功能都能正常使用。
黑跟白的区别：黑盒测试又称功能测试。在这里，盒子指的是被测试的软件，“黑盒”就是只知道被测试软件的外部情况，主要是界面和接口，被测试软件的内部逻辑结构和数据结构，对测试人员来说是不可见的，主要关注被测试软件的功能实现。 白盒测试就是对程序执行路径的测试。 黑盒测试和白盒测试的联系是：一般宏观上用黑盒测试，微观上用白盒测试，系统集成人员用黑盒测试方法对系统进行测试，构件开发人员用白盒测试方法对构件进行测试，这是常用的测试方法。
黑盒 等价类划分 边界值分析(不是重点)：
等价划分：把输入数据的的可能值划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，这样就可以少量的代表性测试数据，来取得较好的测试结果。
边界值分析：取输入输出等价类的边界值作为测试用例。
V模型 每一种测试和对应的软件开发阶段和文档：
单元测试：源程序文档
集成测试: 设计说明书
系统测试： 开发计划
确认(验收）测试：需求文档
软件总体设计中的启发规则中的宽度和深度扇入/扇出等的定义（有一道题）： 总得来说就是跨度和层级数，具体解释如下：
深度：软件结构中控制的层数。
宽度：软件结构中同一层次上模块总数的最大值。
扇出：该模块直接控制/调用的模块数（3-4）。
扇入：直接调用该模块的上级模块个数。
扁平化处理不太行
需求分析与设计的区别 问题域建模/建模基础上设计答案：俺没有找到答案
数据流图用图形符号表示：数据存储、处理、数据流、外部实体
制作变换型的数据流图的前提，确定三要素（很重要）：变换中心、逻辑输入、逻辑输出。
总体设计中设计软件的结构 = 设计功能和模块结构。（记住
面向对象分析的基本过程所包含的3个子模型为（记住）：动态模型、功能模型和对象模型。
Alpha测试（开发者+用户）
由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。Alpha测试是在受控的环境中进行的。
Beta测试（用户+开发者）
由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场。Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在Beta测试过程中遇到的一切问题，并把这些问题报告给开发者
来源：姓伍不姓六
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！