【成电860考研】《软件工程》-anki卡片知识合集-504张卡片-28000字-上岸资料整理

软件的定义 软工 :: 概述 程序 ：为完成特定任务的指令 数据 ：由数据结构组织，是程序操作的对象 文档 ：为便于维护，编写的说明性文字
软件危机是什么 软工 :: 概述 软件在整个生命周期中遇到的严重的麻烦问题
举例软件危机有哪些 软工 :: 概述 项目超出预算 → 亏损 项目超时 → 不能交付 软件质量差 → 不合要求 → 不能交付
软件的特征 软工 :: 概述 胡磊式抱怨： 1、（各个过程都）xxx特别困难 估计开发时间 特别困难 估计工作量 特别困难 软件测试 特别困难 软件维护 特别困难 2、xxx有新问题 软件维护 产生新问题 3、软件不会磨损，但会退化和废弃
软件危机产生的原因应该从哪些角度来谈 软工 1、软件自身特点（与物相关） 2、软件开发与维护方法（与人相关） 软工 :: 概述 :: 软件危机
产生软件危机中与 软件自身特点 相关的原因 软工 1、软件是逻辑部件 => 缺乏可见性 => 进度、质量难以衡量 2、软件需要维护 => 维护需要修改 => 修改产生错误 3、规模庞大 => 需合作开发 => 需涉及很多方法 这三点是相互促进的，增加的难度都是指数级的。
软件危机产生原因中与人相关的原因 软工 1、需求分析阶段：不充分或错误 2、开发阶段：不规范 3、质量保证阶段：缺少测评手段 3、维护阶段：难以维护 <= 开发阶段不重视文档 软工 :: 概述 :: 软件危机 分阶段出现问题。需求分析有问题，开发有问题，测试/质量保证有问题，维护有问题。
简述整本书的框架逻辑 软工
软件工程的定义 软工 （1）应用 系统化、规范化、可量化的方法（采用的方法）来 开发、维护 软件（目的）， =即 把工程应用到软件（总结） （过程） （2）对（1）方法的研究 （研究） （1）顾名思义，软件工程=软件+工程。那受作用的对象就是软件，而方法就是工程化。 对其进一步解释工程是什么，答案是：工程是系统的、规范的、可度量的 对其进一步解释软件要干什么，答案是：目的是开发、维护软件 总结，这其实就是工程化的方法。 （1）有了方法论，还得上升一步，对整个方法过程进行研究提升优化，那就是对上述过程的研究。 软件需求规格说明书和需求建模的要求也是系统化、规范化
软件工程的三要素有哪些 软工 质量焦点（基础）→ 1、过程 → 2、方法 → 3、工具
软件工程三要素中 过程的含义 软工 连接软工的各个阶段，（含义）（理解，套话） 在各个环节之间建立里程碑，（关键词） 以提升软件质量、缩短开发时间。（目的） 最后一句是一句套话废话，软件工程干什么的目的最终都是提升质量和缩短时间。
软件工程三要素中方法的含义 软工 给软件开发、维护提供解决方法。（含义） 方法依赖了一组原则，这是一组包含了所有技术领域的原则（关键词） 最后可以加一句套话废话：目的是为了缩短开发时间，提升软件质量。
软件工程三要素中工具的含义 软工 为下层的过程和方法提供自动化或半自动化的支持（含义） 这样的系统被称为计算机辅助软件系统。（关键词） 软工 :: 概述 :: 软件工程
计算机辅助软件工程 英文缩写 CASE 中文名 软工 :: 概述 :: 软件工程三要素 Computer-Aided Software Engineering
软件工程的根基是什么 软工 质量关注点/质量焦点
软件工程的发展过程可以分为哪几代 第一代、传统的软件工程 第二代、对象工程 第三代、过程过程 第四代、构建工程 对象工程：c语言面向对象那种 过程工程：有了第二章软件过程那些东西，瀑布、螺旋什么的 构建工程：组件化，工程化
七大类软件的划分 软工 1、系统软件：服务其他所有程序的基础软件，如windows 2、应用软件：辅助完成特定领域 3、工程/科学软件：如MATLAB 4、嵌入式软件：如智能手表 5、产品线软件：具有工业性质的 6、移动App：如安卓app 7、人工智能软件：用特殊算法解决复杂问题 软工 :: 概述
软件工程的七个原则（西德专家） 瀑布质量保证的两点：1、计划 2、评审 项目管理方面： 3、质量保证的方法：规范化 4、明确权责 5、先进技术 6、少而精 7、不断改进 西德一个软件工程专家提出来的，很多资料都有 1、（初始）严格的计划 <= 大量失败源于计划不周 2、定期评审 <= 尽早发现错误 <= 越晚发现错误，代价越高 3、严格的产品控制 ： 给予每部分不同的权限，不能想改就改，命名什么的都要规范 4、使用先进技术 ：这技术包括编程工具、开发技术、维护技术 5、规定权责和时限 <= 更好地进行管理 6、开发人员少而精 : 避免胡磊这种垃圾 7、不断改进，不断迭代，不断提升
软件生命周期的概念 软工 软件产品 或 软件系统（主体） 从 定义，设计，投入使用到被淘汰的过程 软工 :: 过程模型
软件过程的概念 软工 软件过程是软件生产一系列活动的总和，这些活动覆盖了软件开发的整个过程 软件工程三要素中也有一个“过程”他们的答案是可以通用的。
能力成熟度模型是哪个学校提出来的 软工 卡内基梅隆大学CMU 软工 :: 软件过程
能力成熟度模型 英文缩写 CMM 中文名 软工 软工 :: 过程模型 Capability Maturity Model
能力成熟度模型的分级 软工 1、初始级：一般学生出来创业的状态 2、可重复级：希望学生们能够有些管理，能达到这个水平 3、已定义级：公司里面差不多就这样，有了标准，把标准贴到墙上 4、量化管理级：有些有历史的公司可以量化管理，采集数据然后分析帮助maneger 5、优化级：可以不断进步改进升级 软工 :: 软件过程 公司里最喜欢就是量化管理了，说什么KPI，绩效什么的。
CMM是干什么的 软工 能力成熟度模型是一个标准，这个标准对软件过程中的各个阶段的好坏进行了描述。 软工 :: 过程模型 定量描述了软件过程的好坏程度。
软件开发模型 的同义词 软工 软件过程模型 软工 :: 软件过程模型
软件生存周期模型 的同义词 软件过程模型 软工 :: 软件过程模型
软件过程模型的概念 是一种结构框架， 能直观表达整个过程，（目的） 包含了软件开发的过程、活动、任务、策略，（内容） 为了完成任务制定的一系列框架，规定了各个步骤
软件工程三要素各个要点答题的思路 软工 含义+关键词+目的 软工 :: 概述 :: 软件工程 :: 软件工程三要素 目的都是更好更快， 关键词：过程：里程碑；方法：一组原则；工具：CASE
软件生命周期各个阶段的完整顺序 软工 1、问题定义 2、可行性研究 3、需求分析 4、概要设计 5、详细设计 6、程序开发 7、测试/质量保证 8、软件维护
问题定义 阶段 此阶段产生了什么 项目计划报告 是在哪一阶段产生的 软工 软件工程 :: 过程模型
可行性研究 阶段 此阶段产生了什么 可行性研究报告 是在哪一阶段产生的 软工 软工 :: 过程模型
需求分析 阶段 此阶段产生了什么 需求分析规格说明书 是在哪一阶段产生的 软工 软件工程 :: 过程模型 还有需求建模
概要设计 阶段 此阶段产生了什么 概要设计说明书 是在哪一阶段产生的 软工 软工 :: 过程模型
详细设计 阶段 此阶段产生了什么 详细设计说明书 是在哪一阶段产生的 软工 软工 :: 过程模型
程序编写 阶段 此阶段产生了什么 源代码 是在哪一阶段产生的 软工 软工 :: 过程模型
软件测试 阶段 此阶段产生了什么 测试报告 是在哪一阶段产生的 软工 软工 :: 过程模型
软件维护 阶段 此阶段产生了什么 维护说明书 是在哪一阶段产生的 软工 软工 :: 过程模型
软件过程模型中经典模型是哪一个 瀑布模型
软件工程范型 的同义词 软件过程模型
瀑布模型是以什么为驱动的 以文档为驱动 软工 :: 过程模型
软件生命周期和哪一种软件开发模型是一致的 瀑布模型 软工 :: 软件过程模型
瀑布模型的顺序性和依赖性的含义 两重含义： 1、在时间上，只有前一阶段完成后，后一阶段才能开始。（顺序性） 2、在内容上，前一阶段的输出是后一阶段的输入。（依赖性） 过程模型 :: 瀑布
瀑布模型中推迟实现的含义 编码时间越早 → 最终开发时间反而越长 为解决这个问题， 瀑布模型中，编码阶段之前有需求分析、系统设计等阶段，对软件进行了深入分析， 通过推迟编码的时间，让软件开发效率更高。 过程模型 :: 瀑布
瀑布模型每个阶段都需要完成哪两个重要做法 1、每个阶段完成相应文档 2、每个阶段对文档进行评审 过程模型
瀑布模型的特点/优点 1、顺序性和依赖性 2、推迟实现 3、每个阶段交付文档 4、每个阶段完成文档审查 质量好、文档驱动、稳定
瀑布模型的质量保证方法是什么 1、每阶段交付文档 2、每阶段对文档进行评审 过程模型
理想中的瀑布模型与实际的瀑布模型有什么区别 理想中的瀑布模型是笔直单向前进的， 而实际的瀑布模型是带反馈的，若某一阶段出现了问题会回到相应阶段做修改。
大部分软件预算花费在{{c1::}} 软件维护 软件开发 软件测试 系统设计 需求分析
如何理解“瀑布模型是由文档驱动的”这句话的含义 瀑布模型的核心就是文档， 瀑布模型的主要优点和主要缺点都是跟文档相关的。
瀑布模型的缺点 总：太过理想化 1、阶段划分固定 → 阶段间有大量文档 → 增加工作量 2、开发模型线性 → 末期才能看到产品 → 增加风险 3、开发模型线性 → 后期才能进行测试 → 增加工作量 4、难以胜任 需求变化和需求不明确 的情况 这些优缺点并不是每个过程独有的，而是整个类型的，相关的模型都具有相同的优缺点。
瀑布模型适用于什么场合 需求明确（需求变动是瀑布模型弱点之一） 技术成熟（因错误后期才维护是瀑布模型弱点之一） 工程管理严格（瀑布模型需要每阶段写文档并评审） 过程模型 :: 瀑布模型
渐增模型是什么 增量模型 过程模型 :: 增量模型
简述增量模型的概念 软工 把软件分解成各个模块， 第一个模块完成最核心的功能， 然后逐渐添加更加次要功能的模块到软件上。 软工 :: 过程模型
RAD 中文名 快速应用开发（模型） 英文缩写 过程模型 过程模型 :: 增量过程模型 Rapid Application Development模型
增量过程模型的分类 软工 增量模型 RAD模型
增量过程模型与RAD的关系 RAD是一种增量过程模型
增量模型中所谓的 增量是什么意思 软件模块构件 过程模型
增量模型的优点 1、只要有一个增量，就能进行开发 2、初期不用太多人力资源 3、增量可以有效管理技术风险。（一个增量有问题，不会使整个软件重新调整） 4、更早进入市场 5、给予用户充足学习时间。
开放的软件体系结构的含义 软工 1、新增加的构件不会破坏原有结构 2、扩充新构件的过程简单、方便 软工 :: 过程模型 :: 增量 一方面是对原有的：不会改变破坏 另一方面是对将来的：可扩充，并且扩充方便
增量模型的缺点 软工 1、软件体系结构必须是开放的，这非常困难。 2、每个增量必须提供部分系统功能 => 增量的划分很困难 3、不断修改 => 易失去整体性 软工 :: 过程模型 :: 增量
增量模型适用于什么场合 软工 1、变化多 2、要早日进入市场 软工 :: 过程模型 :: 增量
简述RAD模型 软工 与瀑布模型类似，都是按照软件生命周期顺序来开发软件。不过比起瀑布模型，更强调速度。 与增量模型的共同点是 都是按照构件开发软件的。 RAD模型是在瀑布模型的基础上，强调快速开发，按照构件的形式划分软件，然后对软件进行整合。 软工 :: 过程模型 :: 增量过程模型 :: RAD模型
快速应用开发模型 强调什么 软工 短暂的开发周期/快速 软工 :: 过程模型 :: 增量过程模型 ::RAD
RAD的缺点 软工 1、需要大量人力（独有缺点） 2、三种系统不适用： 无法合理模块化的系统（模块化的问题，也是增量模型的问题） 需要后期调整的（瀑布模型的缺点） 技术风险高的系统（瀑布模型的缺点） 软工 :: 过程模型 :: 增量过程模型 :: RAD
原型模型 与 演化过程模型 的关系 原型模式是一种演化过程模型 过程模型
螺旋模型 与演化过程模型的关系 螺旋模型是一种演化过程模型 过程模型 :: 演化过程模型 演化过程模型：改来改去模型。
原型模型与螺旋模型的关系 两者都属于演化过程模型，是并列关系。 过程模型 :: 演化过程模型
在ppt中演化模型{{c1::}}演化过程模型 等同于 不同于
增量过程模型基本的思想是什么 通过以模块化构建，逐渐完成一个功能完整的系统。 每一个增量的开发都是一个瀑布模型。
演化模型的基本思想是什么 先实现最核心的功能 过程模型 :: 演化 改来改去，改来改去模型都是现实性最核心的。 增量模型也是
原型开发范型 的同义词 原型开发过程模型 过程模型 :: 演化 :: 原型
什么时候适用于原型开发模型 1、客户定义了一些基本任务，但没有明确具体任务 或 2、开发者对种种具体情况没有把握。 软件过程模型 :: 演化 ::原型 说白了就是其中一方没搞明白，后面需要一直改改改的情况。 什么时候适合原型开发？–答没搞懂的情况下
原型模型的优点 先开发出核心 => 减少不明确需求的风险 过程模型 :: 演化 :: 原型 可以一直改改改，改得快。 我还可以说，它有这些优点： 投入市场早，早点给用户学习，反馈及时改需求方便，有bug可以很早发现，不用到了最后项目结束测试阶段才发现问题，用户可以很快看到软件，并明确自己的需求。
简述原型模型的过程 沟通（需求获取） → 快速策划、设计 → 开发（构造原型） → 交付使用 → 获取反馈 → （重新开始） 过程模型 :: 演化 :: 原型
原型模型的缺点（独有部分） 1、客户意识不到一些质量问题 2、工程师为了快速运行程序 => 得进行折衷（关键词） => 会产生一些质量问题 3、快速建立 + 多次修改 => 质量差 演化模型：多次修改，没有用构件的方式。 增量模型：所谓增量就是构件，使用了构件的方式具有模块化。 只要是交给用户先看，用户又不懂，很多问题他都意识不到。
螺旋模型有哪四个象限 计划 风险 工程 反馈 软工 :: 过程模型 :: 演化 :: 螺旋 风险是螺旋的特点，因此专门有个象限是风险评估。 1、计划制定 2、风险评估 3、工程实施 4、客户评估
软件开发的风险有哪些，请粗略说明（非考纲） 1、用户对产品不满意 2、到了期限未能交付 3、程序员跳槽
原型的概念 原始的类型，为后期的完整开发提供基础 软件过程 :: 演化
螺旋模型强调什么 风险管理 过程模型 :: 演化过程模型 :: 螺旋模型
螺旋模型适合于{{c1::}}的开发 大型软件 小型软件 技术成熟的软件 技术不成熟的软件 过程系统
螺旋模型的优点 1、支持需求变化 2、开发了原型 => 便于用户和开发者共同理解 => 便于决策 3、可及时调整决策 => 降低风险 4、可扩充、可修改 => 提高软件适应能力 修修改改的模型：两种演化模型（原型+螺旋）都很适合需求变化。 修修改改的模型都可以及时调整决策，也可修改，可扩充。 两种增量模型也是可扩充的，但是经典的瀑布式就是难以修改和扩充的。
螺旋模型的缺点 1、对开发者要求高 2、需要风险评估（因为螺旋模型重视风险评估） 3、迭代次数多→增加时间、成本 过程模型 螺旋的特色就是风险。
螺旋模型适用场景 1、需求不明确（需求变动是螺旋模型的亮点） 2、大型软件 3、支持多种开发方法，如面向过程、面向对象（不明白） 过程模型
简述喷泉模型的过程 为保证统一性， 在整个过程中围绕“对象”展开， 因而各阶段的界限变得模糊。 过程模型 :: 喷泉 关键词：对象驱动、边界模糊、同时进行
喷泉模型中“喷泉”的含义 表明各个阶段之间界限模糊、无缝衔接、同时进行 这不是糊弄人嘛，你是从火星来的吗，喷泉长这个样子吗？
软件开发过程中迭代的含义 过程模型 这个阶段反复做，写了改，改了写
喷泉模型以什么为动力 用户需求 软件过程模型 这废话，所有的模型都是以用户需求为动力的。 瀑布模型是文档驱动的
喷泉模型是以什么为驱动的 对象驱动 软件过程模型 整个开发过程围绕对象展开，确保统一性。
喷泉模型的优点 各阶段无明显界限 => 可同时开发 => 开发效率高 => 节省时间 软件过程模型
喷泉模型的缺点 开发阶段重叠 => 需要大量人员 => 不利于项目管理（RAD模型也是） 信息随时会加入 => 文档管理困难
敏捷声明的内容 1、个体和交互 胜过 过程和工具 2、可工作的软件 胜过 全面的文档 3、客户合作 胜过 合同谈判 4、响应变化 胜过 遵循计划
极限编程 英文缩写 XP 中文名 软件过程 软件过程 :: 敏捷 eXtreme Programming
极限编程中“极限”二字的含义 把好的开发方法用到极值
举例一些敏捷开发模型 极限编程/XP SCRUM 软件过程 :: 敏捷
敏捷模型的优点 快， 不仅快，这样的快还能持久。 软件过程 :: 敏捷 对需求变更反应更快 plus.这种快速是可持续的 => 适合商业竞争下小项目
敏捷模型的缺点 1、不适用于大型软件 2、软件难以维护重构
Rational 统一过程 英文缩写 RUP “中文”名 软工 软工 :: 软件过程模型
RUP是干什么的 Rational软件公司总结的软件过程 软件过程模型
RUP最佳实践是什么 Rational公司总结的6条最有效的软件开发经验 软件过程模型
需求分析的定义（原话） 以规范化、易理解、一致性的方式（对需求规格说明书的描述） 对待开发系统中有意义部分的描述（描述对象） 需求分析 需求分析的核心是需求规格说明书，而需求规格说明书的特点就是规范化、易理解… 而描述的对象是什么，是待开发系统中有意义的部分。
需求获取的概念 1、一方面是一个动作，软件需求的来源 2、一方面是一个方法，收集需求的方法 需求分析 需求获取是需求分析过程中的第一步，所以说所有需求分析的信息都是来源于需求获取的。 与IEEE软件工程的定义一样，给出了两层含义，第一层是具体的，第二层是抽象的逻辑化的。于是这里第二层思想就是方法论。
需求抓取 的同义词 需求获取 需求分析
需求发现 的同义词 需求获取 需求分析
需求获得 的同义词 需求获取 需求发现
需求分析的过程主线 需求获取 → 需求提炼 → 需求描述 → 需求验证
需求提炼的概念 对问题进行分析，对其建立模型， 要求精确化、完全化， 最后形成 需求规格说明书。 需求分析 :: 需求分析的过程 :: 需求提炼 因为整个需求分析过程中最重要的步骤就是需求规格说明书和建模，所以有时也把需求提炼这个单独的步骤等同于整个需求分析，毕竟名字也可以叫得一样。 说白了就是建模+需求规格说明书，精确化、完全化是需求规格说明书附加的内容。
需求描述完成的基本标志是什么 形成一份 完整的、规范的 需求规格说明书 需求分析 :: 需求分析的过程 :: 需求描述
需求规格说明书 的 作用 让用户和开发者对软件的初始规定有共同理解， 使其成为开发的基础 需求分析 :: 需求分析的过程 :: 需求描述 软件过程模型 :: 需求分析 对双方都是增强理解，对开发者起指导作用，对测试人员起参考作用。
需求管理的完整过程 分为 需求确认 和 需求变更 两条线 1、需求确认部分（需求分析的步骤）： 需求获取 → 需求提炼 → 需求描述 → 需求验证 2、需求变更部分：需求变更
需求确认 与 需求验证的关系 需求确认 是 软件需求管理过程中的主要支线， 需求验证 是 需求确认这条支线中最后一个步骤 因此，需求验证 包含于 需求确认 需求分析 :: 需求分析的过程
需求分析的步骤 和 需求确认的关系 按照ppt的说法，两者所包含的内容都是相同的 都是 需求获取 → 需求提炼 → 需求描述 → 需求验证 需求分析 :: 需求分析的过程
需求分析的作用 重要性（正面）： 1、对开发者： 增强对开发的指导 增强对用户的理解 2、对用户： 增强对开发者的理解 3、对测试人员： 提供参考 必要性（反面）： 错误的需求分析导致 开发失败 需求分析 :: 需求分析的概念 搭建了桥梁，增加双方的理解。 对于主要干事情的开发者而言，更是对他们工作的指导。 对于测试人员来说能提供参考，但相对开发者来说没有这么重要。
需求分析的任务 1、建立分析模型（建模） 2、编写需求说明书 这是最主要的两点，本章这两部分所包含内容也最多。
建模的作用 需求分析 确定目标，确定该做的事
功能性需求 和 非功能性需求 的含义 功能性需求：系统应该做什么 非功能性需求：标准、细节、质量等其他内容 需求分析
需求获取技术有哪些 采访 会议 观察商业过程 注意，对应的还有质量验证的技术。
需求获取的挑战 客户说不清楚需求（老头） 需求总是变（老头） 问题复杂（问题本身） 理解问题：不全面，不一致（软件公司这边的问题） 需求分析 :: 需求分析的过程 :: 需求获取
需求诱导十原则 交流方面： 1、倾听 2、有准备的沟通 3、聚焦引导话题 4、当面沟通 5、继续前进原则 6、记录决定（存储） 7、有人推动（动力） 8、图形表示（转码） 好听的话： 9、通力合作（废话） 10、双赢原则（好听） 需求分析 :: 需求分析的过程 :: 需求获取
需求分析 的一词多义 （随时增改） 需求分析： 章节名，软件生命过程中的一部分 需求分析的过程：指的是软件需求管理的主线，共有四个步骤 步骤名，与“需求提炼”同义，是需求分析过程的二个步骤 需求分析 因为需求分析作为一个大过程，最重要的内容就是建模和需求结构分析说明书，而这两部分都是在小步骤需求提炼中完成的。所以大致上，需求提炼=需求分析。
需求提炼 的一个同义词 需求分析 （需求分析有很多个含义，这只是其中一个奇葩含义。 需求分析通常是指软件过程中的一个大的阶段） 需求分析
需求提炼的定义 对问题和环境进行分析， 为此建立相应的模型， 使得用户需求精确化、完整化， 最终的目的是 需求规格说明书 需求分析 :: 需求分析的过程 :: 需求提炼 需求提炼是需求分析最核心的部分，某种意义上可以等同于需求分析，而需求分析的核心是建模和说明书，因此需求提炼也就是建模和说明书。
需求分析的核心是什么 建立分析模型 其实还有需求分析说明书
分析建模可以按照哪些标准分类 1、数据模型、功能模型、行为模型 的划分 2、面向需求 和 面向过程 的划分 需求分析 :: 分析建模
软件需求规格说明书 的定义 是对待开发软件行为的完整描述， 包含了功能性和非功能性需求 要求：清晰化、规范化、完整化 是开发人员与用户沟通的桥梁，能够促进相互之间的理解。
需求分析完成的标志是什么 完成了一份完整而规范的需求规格说明书 需求分析
软件需求规格说明书有哪些原则（分性质和内容） 需具备的性质： 全面性 规范性 无二义性 可操作性 可扩充性 需描述的内容： 描述功能而非具体做法 描述运行环境 描述更大的整体 需求分析 需求规格说明书答题模板
需求验证的必要性 如果错误，返工代价大 需求分析 :: 需求分析的过程 :: 需求验证 原话：如果后期发现错误，会付出更大代价导致返工
对需求文档应进行哪些检查 1、有效性检查： 各种功能是否有效 2、一致性检查： 文档内部不能有冲突 3、完备性检查： 文档应包含所有用户的全部需求 4、现实性检查： 现有技术能够实现 需求分析 :: 需求分析的过程 :: 需求验证 现实性检查即检查可操作性， 一致性检查即检查自洽性，有无内部冲突， 完备性即检查完整性，是否写完了
需求验证技术有哪些 1、瀑布里有评审，这里也有评审 评审分正式和非正式两种 2、需求分析要产生用户手册，这里也要产生用户手册 3、原型模型有原型，这里也有原型 4、软件测试有用例，这里也有用例 5、软工三要素有CASE，这里也有CASE，当然要保证“一致性” 需求分析 :: 需求分析的过程 :: 需求验证 五种方法在书中都有对应的部分 1、需求评审：有正式和非正式两种，类似于瀑布中各个阶段的评审（项目管理的文科方法） 2、编写用户手册。（传统文本方法） 计算机科技方法： 3、利用原型检验系统。（先编程） 4、对每个需求编写测试用例。（再写用例） 5、检验模型的一致性。如CASE工具（完整成熟的工具）
ERD 中文名 实体-联系图 英文缩写 需求分析 :: 建模 E-R图 Entity - Relationship Diagram
数据字典 英文缩写 DD 中文名 需求分析 :: 建模 Data Dictionary
数据流图 英文缩写 DFD 中文名 软工 需求分析 :: 建模 Data Flow Diagram
状态变迁图 英文缩写 STD 中文名 软工 需求分析 :: 建模 State Transition Diagram
数据流图长什么样 需求分析 :: 建模 它表示的都是数据在各个主体之间的流动方向。
用例图长什么样 用例图的特点就是有很多小人。
时序图 同义词 顺序图 同义词 软工 需求分析 :: 建模
顺序图长什么样 需求分析 :: 建模
用例图 中文缩写 UCD 中文名 需求分析 :: 建模 Use Case Diagram
类图 英文缩写 CD 中文名 建模 需求分析 :: 建模 Class Diagram
软件设计 的同义词 系统设计 系统设计
软件设计的定义(IEEE) (IEEE给出的） 软件系统 或 其组件的架构、构件、接口 and so on 的 定义过程 及其结果 软件设计 软件设计=系统设计=架构设计+数据设计+构件设计+接口设计 按照IEEE的风格，一般有两层含义：一是定义过程，二是其结果。 软件设计/系统设计的分类是怎样的：系统架构、构件、接口设计，设计了这些东西再加上设计的过程和结果。
在面向过程设计过程，需要具体设计哪些部分？ 请把这些部分归纳为概要设计或详细设计。 概要设计部分： 接口设计 数据设计 体系结构设计 详细设计部分： 过程设计 系统设计
在面向对象设计过程，需要具体设计哪些部分？ 请把这些部分归纳为概要设计或详细设计。 概要设计： 接口设计 类/数据设计 体系结构设计 详细设计： 构件级设计 系统设计
概要设计包括哪些内容 接口设计 数据设计 组件设计（没有叫设计这个构件的内部） 体系结构设计 系统设计 :: 概要设计
概要设计中哪一个是主要内容 体系结构设计 系统设计 :: 概要设计
详细设计的概念 对概要设计设计出的具体模块或具体过程进行进一步设计， 使其能编码实现。 系统设计 :: 详细设计
顶层设计是什么（同义词） 概要设计
软件架构设计是什么（同义词） 概要设计
总体设计是什么（同义词） 概要设计
好的设计须具备的三个特点（ppt上说三个，实际上拆开不止三个） （软件需求说明书的要点+隐藏需求） 1、满足明确要求与隐藏要求 2、易读易理解 3、完整性 4、可行性/现实性/可操作性 1、实现所有模型中的 明确要求 和 隐藏要求。（对客户给出的需求方面） 2、设计对后阶段的人员（编码、测试、维护）易读易理解。（对我们的工程师而言） 3、完整性：包含整个软件 可行性：能解决数据、功能、行为各领域的问题（对软件设计本身而言）
哪些过程模型是先完成最核心的板块 增量模型、螺旋模型、原型模型
系统设计的指导原则 中 数据、体系结构、接口、组件设计的具体要求是什么 1、对于组件：功能独立 2、对于接口：能组件间或与外部相连 3、对于数据结构：能为系统所用 系统设计 :: 系统设计指导原则 后两点都是废话，就像说鞋的要求是能穿一样。 对于组件来讲，功能独立是其基本要求，ppt也花了不少篇幅来讲这个。
系统设计的指导原则有什么（5点） 1、是架构（整体而言） 2、模块化（具体往下） 3、具体到各方面 4、由需求分析中的信息驱动（信息来源） 5、正确、清楚（表示方式） 系统设计 包含了来源、表示方式、具体的，整体的 1、设计出的是架构 2、模块化 3、包含各个方面：数据、体系结构、接口、组件（可展开） 4、由软件需求分析中信息驱动 5、表示方式：正确、清楚
软件设计中有哪些质量属性 功能性：Dell可以跑MATLAB，而Surface不可以 易用性：Surface在哪儿都可以打开，很方便 可靠性：Dell电脑相对稳定，不会时不时宕机 性能：Dell电脑性能相对较强，可以满足我的正常需求 可支持性：扩展性、适应性、可维护性 系统设计
可支持性的细分分类 扩展性：我的Dell电脑可以扩展出多显示器 适应性：Dell电脑在强磁场也能工作 可维护性：电池坏了也可以换 系统设计 :: 设计质量的属性 :: 可支持性 这里和其他部分有冲突，进行模糊化处理。
书上经典图中设计模型有哪些层次 第一层：构件级设计 第二层：接口设计 第三层：体系结构设计 第四层：数据/类设计
抽象的概念 找到本质和共性，抛去细节和差异。 系统设计 :: 八大概念
体系结构的定义 1、软件的整体结构。 2、它提供了一种概念，这种概念能够完善系统中各个构件的组织方式、相互作用的方式。 系统设计 :: 八大概念 书上有完整的专业性表述
体系结构可以用那些模型表示 关于整体的： 结构模型 框架模型 有变化的： 动态模型 过程模型 做事情的： 功能模型 系统设计 :: 八大概念 对应于什么层次模型、数据流模型、对象模型、调用模型
设计模式的含义 设计模式处在一个特定的环境中，因此需要联系上下文， 在这种环境中特定的问题有特定的解决方案，这些问题和解决方案具有共同性。 系统设计 :: 八大概念 :: 设计模式
数据抽象的含义 描述对象的数据集合 门：门的类型、门的重量… 系统设计 :: 八大概念 :: 抽象 如：门xxx
过程抽象的含义 有限、明确的功能指令集合。 开门：（包含各种过程）走到门前，拉门，转把手… 系统设计 :: 八大概念 :: 抽象
模块化的概念 将软件划分为若干个相对独立的组件， 以这些组件的集成解决问题 系统设计 :: 八大概念
模块{{c1::}}组件 等于 不等于
简述模块个数与工作成本的关系 模块数量越大，集成成本越高。 模块数量越小，单个模块成本越高。 只有当模块个数适中时，工作成本才最小。 系统设计 :: 八大概念 :: 模块化
模块有哪些设计标准 1、往下：可分解性 2、往上：可以组装成新组件 3、可理解 4、遇到变化：连续性，小变化只影响本模块 5、遇到异常：模块化的保护：异常只影响本模块 系统设计 :: 八大概念 :: 模块化 1、可分解性：可分解为子问题（内部往细节看） 2、组合性：模块可以组装成新组件（外部往大了看） 3、可理解性（对程序员来讲） 4、连续性：小变化只影响单个模块 5、模块化的保护：内部异常只影响本模块 后面两条都一个意思，不过一个是正面的，另一个是负面的。
信息隐藏这个概念是关于什么问题的 信息隐藏是模块划分的原则之一。 系统设计 :: 八大概念 :: 信息隐藏
信息隐藏的含义 如果另一个模块不需要本模块的相关信息，那么这个模块不能访问本模块的信息 系统设计 :: 八大概念 :: 信息隐藏
功能独立的概念 1、每个模块只负责特定的独立功能 2、对外接口简单 系统设计 :: 八大概念 :: 功能独立
功能独立的优点 易于开发： 功能单一（对本身而言） 接口简单（对外面信息交换而言） 易于测试和维护： 错误传递少 => 错误影响小（因为功能单一） 模块重用（维护和测试量大大降低） 系统设计 :: 八大概念 :: 功能独立
功能独立有哪些标准 内聚性 耦合性 系统设计 :: 八大概念 :: 功能独立
内聚性的含义 内聚性强，说明单个功能都被放入单一模块中 内聚性若，说明单个功能被切分为多个模块 它说明了单个模块功能的强弱 系统设计 :: 八大概念 :: 功能独立
耦合性的含义 耦合性越强，单个模块对其他模块依赖度越高 耦合性越弱，单个模块对其他模块依赖度越低 耦合性体现了模块间的相互依赖程度 系统设计 :: 八大概念 :: 功能独立
耦合性与内聚性的关系是怎样的 负相关， 耦合性越高，内聚性越低。 耦合性越低，内聚性越高。 系统设计 :: 八大概念 :: 功能独立
一个功能独立的模块应该是怎样的，请用定性衡量标准说明 高内聚低耦合 系统设计 :: 八大概念 :: 功能独立
细化 同义词 精化 同义词 系统设计 :: 八大概念
精化的概念 逐渐求精的过程 系统设计 :: 八大概念 不断细化，细节分层。
精化与抽象的关系 两者是互补的。 精化是不断对细节进行分解，能揭示底层细节。 抽象是对细节进行隐藏，隐藏了底层细节。 系统设计 :: 八大概念
重构的概念 不改变组件功能的前提下，重新设计代码，使其代码简化更为高效。 系统设计 :: 八大概念 重写模块，重写代码
重构的方法 检查现有的冗余情况： 未使用的元素、无效元素、低效算法、不当的数据结构… 系统设计 :: 八大概念 :: 重构
数据设计中对什么内容进行了高层次的抽象 用户/客户的数据视图 系统设计 :: 四个方面 数据设计 设计的是数据，数据是来自于客户的，所以要抽象也是对客户的数据进行抽象，而抽象后的展示方式就是使用数据视图。
数据设计的含义 构建 高层抽象 数据模型/信息模型 的过程和方法。 系统设计 :: 四个方面
体系结构设计的含义（设计内容3点和设计方法） 设计内容： 1、各个模块干什么 2、模块间的连接 3、整体对模块的约束 设计方法： 通过已知的需求分析的建模，对系统分析，以理解系统的特性。 系统设计 :: 四个方面 通过已知的来自于需求分析建模的数据进行分析。 设计内容： 1、设计各个组件，如数据模块、计算模块（设计各个具体的组件） 2、设计各个组件之间通信、协同的连接方式（设计组件之间的关系） 3、设计各个组件构成系统的约束条件（设计组件对整体系统的关系） 设计方法： 对系统进行分析，理解系统的特性
数据中心架构是什么样的 以数据库为中心，其他的软件都以它为中心交换数据 系统设计 :: 四个方面 :: 体系结构设计 :: 体系结构设计的简要分类
数据流体系架构是怎样的 批处理系列，处理文字数据，就像电路通过各个组件一样 系统设计 :: 四个方面 :: 体系结构设计 :: 体系结构设计的简要分类 :: 数据流体系架构
调用和返回架构是怎样的 就像编程里用的嵌套模式，从上层不断地调用底层的数据或功能 系统设计 :: 四个方面 :: 体系结构设计 :: 体系结构设计的简要分类 :: 调用和返回架构
面向对象架构是怎样的 以对象为单位，说明每个对象内部的数据和功能，并描述对象之间的关系 系统设计 :: 四个方面 :: 体系结构设计 :: 体系结构设计的简要分类
层次架构是怎样的 系统设计 就像OS系统一样，有一个个层级 系统设计 :: 四个方面 :: 体系结构设计 :: 体系结构设计的简要分类
概念数据模型大概是怎样的 描述的不是具体的数据组织方式，而是抽象的相互之间的数据的关系 系统设计 :: 四个方面 :: 数据设计 :: 概念数据模型
物理数据模型大概是怎样的 用具体化的方式描述了具体定量的数量关系 系统设计 :: 四个方面 :: 数据设计 :: 物理数据模型
瀑布、螺旋、喷泉分别是什么驱动的 瀑布：文档驱动 螺旋：风险驱动 喷泉：对象驱动
主流的几种过程模型中哪些是模块化模型，哪些是改来改去模型 模块化：增量、RAD 改来改去：原型、螺旋、喷泉、敏捷
哪些模型要求的人力多，哪些模型要求的人力少 整体人力多：喷泉、RAD 初期人力少：RAD
哪个模型码农要求高 螺旋、敏捷
各个主流模型对需求变化的应付情况 难以应付：瀑布、增量、RAD、喷泉 易于应付：原型、螺旋、敏捷
哪些模型进入市场早/见客户早，哪些晚 早：增量、原型、螺旋 晚：瀑布、RAD、喷泉
哪种过程适合大型软件 螺旋
模块化过程（增量那种直接写的）的缺点 需具备开放性 划分困难
改来改去模型的优点 早点给用户看 适应需求变化
改来改去模型的缺点 只去整体性 → 质量差 难以维护 改的太多 → 时间、成本高
改来改去模型都是先完成什么部分 最核心最主要的部分
软件过程模型优缺点的答题思路是什么 1、先看是否是 模块化 或 改来改去 的过程模型 如果是搬模板 2、答驱动方式：文档、风险、对象… 3、需求变化、风险、技术成熟、管理程度…
质量保证需要做到哪几个“一致” 表明软件是否与下列一致： 1、与给定需求一致 2、与隐藏需求一致 3、与指定开发标准一致
质量保证/软件质量测量的基础是什么 软件需求
软件需求与软件功能不一致{{c1::}}软件质量问题 等同于 不等同于 缺乏一致性等同于缺乏软件质量
软件质量保证的概念 通过系统性的监测和评估工程， 以最大限度地提高实现质量的最低标准
质量保证的原则 1、达到预期 2、淘汰错误 质量保证 一次成功的意思应该是软件交付之后按理来说就没有错误了。 1、适合用途：产品应达到预期 2、一次成功：淘汰掉错误
SQA 中文 软件质量保证 英文缩写 质量保证 Software Quality Assurance
SQA的概念 通过监视、评估工程 以确保软件的质量。 质量保证 软件质量保证的概念：通过监视、评估等方法，系统性地提升软件的最低质量。
系统设计 → {{c1::}} → 软件维护 都不对 质量保证 可行性研究 需求分析 质量保证涵盖了软件生命周期中的整个过程，这里应该填“软件测试”
软件测试的定义 两个过程，由具体到抽象 过程一：（具体） 在特定条件下，对系统或组件进行操作， 观察其结果，并对其某方面进行评估。 过程二：（抽象深化） 分析现有结果与应有结果的差异，并进行评估特征。
软件缺陷的含义 对系统或组件来说输出的现有结果与应有结果有差异 质量保证 :: 软件测试 多了功能 少了功能 少了隐藏功能 错误 觉得不好用，用户会觉得不好
软件缺陷有哪些 功能与产品说明书不一致： 1、多实现了产品说明书的功能 2、少实现了产品说明书的功能 3、未实现产品说明书的隐含功能 4、软件出现了错误 5、软件难以理解、不易使用、性能差 → 测试人员觉得不好 → 用户会认为不好 跟女人一样，要按照她的想法去做，多了一点不行，少了一点也不行，还要满足她没有说的需求。 错误当然是不能容忍的，而且觉得质量不好，不能理解的东西她也觉得不好。
验证和确认的区别 验证(Verification)：过程是否正确 确认(Validation)：结果是否正确 质量保证 结果只能确认，确认结果就很顺口，而验证结果就不常用。验证的是过程。
软件测试与质量保证的区别 1、软件测试是质量保证的主要方法。 2、软件测试在程序编写完成后进行， 质量保证贯穿了产品生命周期的全过程。 3、软件测试是为了找出软件的缺陷并确保修复， 质量保证是有一套完整科学成体系的方法。 质量保证 软件测试是质量保证的主要方法，质量保证是一套完整成体系的方法论。 软件测试：找出软件缺陷，并确保修复 质量保证：执行软件开发过程，并防止软件缺陷， 需遵循一套完整的标准和方法。
软件测试的基本原则 测试不了的部分：1、无法穷尽测试（测试不完） 2、潜在缺陷无法测出 时间： 3、尽早测试 事物本身特点： 4、软件缺陷有聚集性 5、避免“杀虫剂”现象 对于人： 6、使用独立的测试团队，而不是让开发团队测试 质量保证
测试用例的概念 内容：一组数据的集合， 包含了 输入、条件、预期输出 目的：为了验证程序正确性，找出软件缺陷而开发的 质量保证
测试策略V模型的过程 左右两边一一对应，一一测试验证。
软件测试V模型把测试分为了哪些过程 单元测试 集成测试 系统测试 验收测试 质量保证
软件测试V模型的四个测试步骤分别的含义是什么 单元测试：测试模块内部，验证软件模块是否按详细设计的规格说明运行 集成测试：测试模块之间，验证软件模块间是否按概要设计说明运行 系统测试：测试整个系统，验证整个系统是否按照概要设计说明运行 验收测试：检测是否符合合同定义，满足用户功能和业务 软件质量保证 :: 软件测试
子系统测试的同义词 集成测试 质量保证 :: 软件测试
桩模块的概念 替换了被测模块原有的子模块，因为不需要使用原子模块的全部功能。 质量保证 :: 软件测试
驱动模块的概念 代替被测模块的主程序，用来输入和输出数据 质量保证
简要描述单元测试，待测模块与周围模块关系是怎样的 被测模块的子模块被替换成桩模块，用于减少原子模块中不必要的功能。 被测模块的主模块被替换成驱动模块，用于传递输入输出数据 质量保证
集成测试有哪些方法 1、自顶向下集成 2、自底向上集成 3、SMOKE方法 质量保证 :: 软件测试
自顶向下集成测试方法分为哪几种 广度优先方法、深度优先方法 质量保证 :: 软件测试
简述自顶向下和自底向上集成测试方法的过程 自顶向上：按照从上至下或从下至上的方法逐渐集成新模块到系统中进行测试
自顶向下和自底向上集成测试方法分别的缺点是什么 自顶向下：需要开发大量桩模块 自底向上：每个模块都要开发驱动模块 质量保证 :: 软件测试 :: 集成测试
实际工作中常使用{{c1::}}的集成测试方式 两种相结合 自顶向下 自底向上
简述SMOKE方法 设计一系列测试以暴露待测试构造（build）的错误，将此构造与其他构造进行集成进行测试。 质量保证 :: 软件测试 :: 集成测试
SMOCK方法的测试单位是什么 构造（Build） 质量保证 :: 软件测试 :: 集成测试
系统测试的主要内容有哪些 1、功能测试 2、性能测试 3、强度/压力测试 4、恢复测试 5、安全测试 质量保证 :: 软件测试 :: 系统测试 自顶向下 自底向上 冒烟 这些是集成测试，毕竟是一块块把它们都拼到一起的测试。而系统测试则是把它们都看做一个整体来测试系统的功能性能。 功能测试是要看软件在实际的工作环境中表现如何。这当然首先要符合需求说明书的功能，然后性能要好。还要要求在现实情况中遭遇各种问题：强度、掉电、是否安全。
软件性能体现在什么地方 性能测试 响应时间、缓存区占用量、处理精度等 质量保证 :: 软件测试 :: 系统测试 :: 性能测试
功能测试的含义 系统测试 检查软件是否符合软件需求规格说明书的功能，以验证其错误 质量保证 :: 软件测试 :: 系统测试 :: 功能测试
压力测试的概念 系统测试 测试运行环境有问题时系统的运行情况， 如调高输入数据速率，设计占用大量内存资源的测试用例 质量保证 :: 软件测试 :: 系统测试 :: 压力测试
恢复测试的含义 系统测试 测试硬件产生故障系统能否正常工作 质量保证 :: 软件测试 :: 系统测试 :: 恢复测试
如何进行恢复测试 系统测试 模拟硬件故障，如掉电测试。 质量保证 :: 软件测试 :: 系统测试 :: 恢复测试
验收测试是以什么人为主的 用户 质量保证 :: 软件测试
α测试和β测试分别是什么 α测试：用户在开发环境下进行测试 β测试：用户在实际环境下进行测试 质量保证 :: 软件测试 :: 验收测试
α测试和β测试分别在什么地方测试 α测试：在开发环境下测试，开发者场所 β测试：在用户场所进行 质量保证 :: 软件测试 :: 验收测试
α测试和β测试开发者的在场情况如何 α测试：开发者在场 β测试：开发者不在场 质量保证 :: 软件测试 :: 验收测试
α测试和β测试是否可以同时进行 不可以，只有当α测试足够可靠后才能进行β测试。 质量保证 :: 软件测试 :: 验收测试
回归测试的概念 软件部分修改后， 对整个系统或某个部分进行再测试， 这样的再测试是有选择的， 目的是验证修改后的部分不会有错误影响。 质量保证 :: 软件测试 :: 回归测试
回归测试在什么时候进行 在软件测试的各个阶段，软件产生变化的部分需要进行再测试。
回归测试的分类 缺陷再测试（因为有错而更改） 功能改变测试（因为需求→功能变更而更改） 新功能测试 完全回归测试（测试整个系统） 质量保证 :: 软件测试 :: 回归测试 错误而更改、需求→功能而更改、新增、整体
回归测试应采用{{c1::自动化测试}}（一个词）（什么方法） 质量保证 :: 软件测试 :: 回归测试
软件质量保证的主要方法是什么 软件测试 质量保证
软件测试占总成本大概多少 40%以上 每个部分都自卖自夸，搞硬件的说自己吃香，搞软件的说软件需求越来越大，软件维护的说自己占用成本最高，这里又来一个说软件测试占总成本40%以上，那你的意思是软件开发、需求分析、系统设计之类的只占总成本不到10%.吹牛吧你。
质量与可靠性有哪些衡量标准 质量保证 功能性：是否满足响应功能 可靠性：平均无故障的时间 可维护性：平均修复时间 可用性：可靠性+可维护性 效率：软件运行得快不快 可移植性：跨平台、跨硬件移植 关于正常用：功能性、效率 关于故障：可靠性、可维护性、可用性 关于换平台：可移植性
白盒测试的含义 考虑系统或组件的内部逻辑结构进行的测试
黑盒测试的含义 不考虑系统或组件内部逻辑结构进行的测试
灰盒测试的含义 介于黑盒测试与白盒测试之间的测试，既关注程序的输入输出，又关注程序的逻辑性
结构性测试的同义词 白盒测试
功能性测试的同义词 黑盒测试
灰盒测试常被用于哪个阶段 集成测试阶段
逻辑覆盖属于{{c1::}}盒测试 白 黑
逻辑覆盖有哪几种分类 语句覆盖 分支覆盖 条件覆盖 条件组合覆盖 质量保证 :: 软件测试 :: 白盒测试 :: 逻辑覆盖
语句覆盖的含义 设计若干个测试用例，使得每条语句都能至少被测试一次 质量保证 :: 软件测试 :: 白盒测试 :: 逻辑覆盖
分支覆盖的含义 设计用例，使每个判断的每个分支至少测试一次。 质量保证 :: 软件测试 :: 白盒测试 :: 逻辑覆盖
判定覆盖 的同义词 分支覆盖 质量保证 :: 软件测试 :: 白盒测试 :: 逻辑覆盖 :: 分支覆盖
条件覆盖的含义 设计测试用例，使得每个条件的取值至少被测试一次。 质量保证 :: 软件测试 :: 白盒测试 :: 逻辑覆盖
条件组合覆盖的含义 设计足够多的测试用例，使得每个判断组合都至少执行一次 质量保证 :: 软件测试 :: 白盒测试 :: 逻辑覆盖
控制流图 英文缩写 CFD 中文名 Control Flow Diagram
程序图 的同义词 控制流图
流图的同义词 控制流图
控制流图长什么样
控制流图覆盖测试属于{{c1::}}盒测试 白 黑 灰 质量保证 :: 软件测试 :: 白盒测试
控制流图覆盖测试 与 逻辑覆盖 的具体分类中的对应关系 语句覆盖-节点覆盖 分支覆盖-边覆盖 条件覆盖-路径覆盖 质量保证 :: 软件测试 :: 白盒测试 :: 控制流图覆盖测试
黑盒测试的分类 等价类划分、边界值分析、状态测试 质量保证 :: 软件测试 :: 黑盒测试
简述等价类划分的大致方法 把所有可能的输入数据划分为若干部分，从每一部分中选取少数具有代表性的数据作为测试用例 质量保证 :: 软件测试 :: 黑盒测试 :: 等价类划分
等价类的划分分哪些步骤 1、列出等价类表 2、选取测试用例 质量保证 :: 软件测试 :: 黑盒测试 :: 等价类划分
等价类是什么 是一个集合，在这个集合中各个输入对于揭示程序的错误都是等效的。 质量保证 :: 软件测试 :: 黑盒测试 :: 等价类划分
等价类有哪两种情况 有效等价类：对程序合理的输入集合 无效等价类：对程序不合理的输入集合 质量保证 :: 软件测试 :: 黑盒测试 :: 等价类划分
设计黑盒测试用例时，采用等价类划分的方法，应使用{{c1::}} 其他 有效等价类 无效等价类 设计测试用例时要同时考虑有效等价类和无效等价类
等价类划分的原则有哪些 1、给出范围 可以划分（连续型） 2、给出输入集合 可以划分（离散型） 3、输入为bool量 可以划分（布尔型） 4、每个输入处理都不同，则对于每个输入都可以划分（case1,2,3） 5、给定规则，是否合规，可以划分 质量保证 :: 软件测试 :: 黑盒测试 :: 等价类划分 1、若给出了输入的取值范围，则可以划分有效和无效等价类。（连续型） 2、规定了输入值的集合，可以划分一个有效和无效等价类。（离散型） 3、输入条件为布尔量，可以划分一个有效等价类和无效等价类。（布尔型） 4、给出输入的一组值，其中每个值都要分别处理， 则对于每个值，都可以划分有效等价类和无效等价类。（case1,2,3） 5、规定了一个条件规则，则可以划分…（是否符合规则）
静态分析方法是什么 不运行程序，检查和阅读代码、文档、手册来发现问题 软件测试 空谈误国型
静态分析的分类 1、同事审查，用于初次审查，要求最低 2、走查：开发组内部进行 3、审查：开发组、测试组合相关人员开会 软件测试
伙伴审查 的同义词 软件测试 同事审查
静态分析类型中要求最低的审查方式是哪一种 同事审查 软件测试
静态分析类型中初次审查是在什么人之间进行 同事审查，在同事之间进行 软件测试
边界值分析方法是什么 是一种黑盒测试方法，是对等价类划分测试的补充。 因为软件大量测试出现在边界上 软件测试 :: 黑盒测试
软件维护的概念（原因+动作+目的） 原因：软件出现问题需要改进 动作：对代码及文档进行修改 目的：修改软件的同时保持软件的完整性 软件维护
软件维护的基本类型有哪些 纠错性维护：为了改错 适应性维护：适应外部条件，如OS或硬件架构变化 完善性维护：增加新功能，如OneNote不断完善 预防性维护：采用先进方法重新设计、编码、测试 Adobe有PS只能在Windows上面跑，但是x86的复杂指令集架构太老旧了，时代浪潮滚滚向前，需要用ARM架构，于是我们进行适应性维护。（可以这么理解，但实际上并不是的）
软件维护的基本类型中，占比最小和最大分别是什么 占比最大：完善性维护 占比最小：预防性维护
正确性维护 的同义词 纠错性维护 软件维护
完善性维护占比大概占维护成本的多少 50% 软件维护 :: 完善性维护
软件维护的成本大概占总成本的多少 80% 这骗人
可维护性的因素主要分为哪些大的方面 主要因素（抽象） 环境因素（具体） 软件维护
可维护性的主要因素（抽象）有哪些 1、可理解性 2、可移植性 3、可重用性 4、可测试性 5、可修改性 软件维护 与软件的质量相比很多都相同，但是增加了可测试性、可修改性，没有了性能、功能性。
可维护性的环境因素（具体）有哪些 1、软件维护的文档 2、软件的运行环境 3、软件的维护组织 4、软件维护的质量（这不废话吗） 软件维护 对应了“软件维护为什么困难”这个问题。
软件维护的困难性有哪些 1、管理不到位（管理） 2、人员变动（人） 3、软件可读性差（文档） 4、时间紧（时间） 软件维护 软件功能的的困难可以用各个阶段进行论述，而软件维护的困难可以从 管理+人+文档+时间 四方面来论述。
软件维护的过程模型大概长什么样子 1、分类鉴别（寻找大方向） 2、分析（代替了需求分析） 3、设计（类似于系统设计） 4、编码实现 5、测试 6、验收 7、交付 是一个微缩版的软件过程模型
软件再工程是什么 对现有软件进行重新改造， 使之形成新的软件，新的形式 软件维护
软件逆向工程的概念 正向工程是从概念设计到代码， 而逆向工程是从代码模块分析出模块间的关系，获知抽象概念。 然后通过某种形式来展现这个系统。 软件维护
项目管理的四要素 4P： People人员 Product产品 Process过程 Project项目 项目管理
软件项目管理的定义 （IEEE） 计划、协调、度量、监控、控制等 一些列方法应用到软件开发维护中， 以保证过程具有系统性、可量化、有原则。 项目管理
PCMM 中文名 人力资源管理成熟度模型 英文缩写 项目管理 People Capability Maturity Model
软件度量的定义 一种量化衡量的方法，使得人们可以把握软件项目生产效率 项目管理
软件独立的目的是什么 描述（项目和过程） 评估（状态和质量） 预测（为计划） 改进（产品质量和产品性能） 项目管理
项目中的三驾马车是什么 项目负责人Project Manager 只能部门负责人Manager in Department 项目成员Project Members 项目管理
软件度量的分类 面向规模度量 面向功能度量 项目管理
软件的特征有哪些 胡磊式抱怨： 1、软件开发进度、时间、工作量、成本难以衡量（可延伸） 2、软件维护非常困难，维护易产生新问题 客观问题： 1、不会磨损和老化，但是会退化和废弃 2、软件是开发或者工程化的，不是制造的 概述
软件的双重作用是什么 1、一方面是一种产品 2、另一方面是开发软件的工具 概述 就像人，一方面是个人，另外一方面可以造人。
按照软件的功能来划分，软件可以分为哪几类 1、系统软件 2、支撑软件（独有，奇葩） 3、应用软件 在这本书里软件有很多种划分方法，有七大类软件，我也不知道为什么这么划分。还有操作系统的划分方法，各种计算机的书划分方法都不一样。这里就记它这种吧。
软件工程的目标 在给定时间、预算内， 按照用户的要求， 开发 易修改、高效、可靠、可维护、适应力强、可移动、可重用（常规套话） 的软件 概述
称赞软件好的词有哪些 可靠性、可维护、可用性好 功能性 可移植、移植性好 可读性好、可理解 易修改、易维护、易测试 性能好、高效
基于构件的过程模型与常规过程模型有什么不同 1、分析步骤：新增组件分析，看哪些组件可以用，哪些组件需要改 2、系统设计步骤：需要考虑组件的重用 3、代码实现：有组件的话一些代码就不用直接写了，要把组件集成进软件中 软件过程
基于构件的过程模型的缺点（4点） 1、模型复杂 2、需求的折衷，不一定完全符合要求 3、无法完全控制开发系统的演化过程 4、项目、模块划分困难 软件过程
简述基于构件的软件过程是什么玩意儿 不同于RAD和增量模型，基于构件看起来是用的别人写的模块， 而增量模型、RAD的模块是自己写的 软件过程 所以有些地方无法自己控制
用例图在ppt的哪个位置 需求分析
数据流图在PPT的哪个位置 需求分析
PPT中需求分析部分主要讲了哪些图 数据流图、用例图
分解设计是什么 把软件分解为各个组件的设计 系统设计
页面设计的重要原则 1、用户为中心 2、减少用户记忆负担 3、保持界面一致 系统设计
体系结构组织和细化的两个基本问题是什么 控制问题和数据问题 1、组织→控制结构问题 架构内如何实现控制管理 是否有多种控制架构 2、细化→数据传递问题 组件间如何进行数据传递 数据流是连续传递还是间断传递的 系统设计
内聚强弱的排序 功能内聚 > 顺序内聚 > 通信内聚 > 过程内聚 > 时间内聚 > 逻辑内聚 > 偶然内聚 系统设计 时间内聚与顺序内聚含义相似
偶然内聚的含义 没有什么关系，只为了节省内存就放进了一个模块内 系统设计 :: 八大概念 :: 内聚
逻辑内聚的概念 把任务逻辑相同相似的放在一块 系统设计 :: 八大概念 :: 内聚
时间内聚的概念 把同一个阶段的任务放在同一个模块里 系统设计 :: 八大概念 :: 内聚
低内聚的分类 时间内聚 > 逻辑内聚 > 偶然内聚 系统设计 :: 八大概念 :: 内聚
过程内聚的含义 模块内的元素按照一定的执行顺序， 使用程序流程图一般能得到过程内聚的模块 系统设计 :: 八大概念 :: 内聚
通信内聚的含义 模块内各个元素有相同输入或输出 系统设计 :: 八大概念 :: 内聚
中内聚的分类 内聚 通信内聚 > 过程内聚 系统设计 :: 八大概念 :: 内聚
顺序内聚的含义 1、模块内运输与一个功能紧密相关 2、元素处理顺序执行 系统设计 :: 八大概念 :: 内聚 这很像时间内聚啊
功能内聚的概念 1、模块处理元素属于一个整体 2、完成单一功能 系统设计 :: 八大概念 :: 内聚
高内聚的分类 功能内聚 > 顺序内聚 系统设计 :: 八大概念 :: 内聚
系统结构图长什么样 系统设计
系统结构图中的模块分为哪几种 传入模块 传出模块 变换模块 协调模块 系统设计
系统结构图中各个模块传递的数据流分别叫什么名字 传入模块：逻辑输入数据流 传出模块：逻辑输出数据流 变换模块：变换数据流 协调模块：（没说） 系统设计 :: 系统结构图
结构化的总体设计的方法步骤 1、分析数据流图，通过软件需求规格说明书弄清楚数据加工过程。（来源：需求分析的说明书） 2、确定问题类型，将其分为变换型和事务性。（分类，确定大方向） 3、推导出初始系统结构图（草图） 4、不断改进系统结构图（不断修改） 5、修改补充数据词典 系统设计 事物型和变换型结构图的画法流程都是一样的，总体而言都是这么做的。
系统结构图的分类 变换型系统结构图 事务型系统结构图 系统设计
变换型系统结构图中的过程分为哪些步骤 1、取得数据-数据输入 2、变换数据-中心变换 3、给出数据-数据输出 系统设计 :: 系统结构图 :: 变换型系统结构图
简述事务型系统结构图 根据输入的特点，选择一个处理单元进行处理， 每个事务处理单元可能会调用若干个操作模块以及下层的细节模块进行处理。 系统设计 :: 系统结构图 :: 事务型系统结构图
简述 事务型系统结构图 和 变换型系统结构图 的区别 事务型系统结构图是分类后选定某一个模块进行变换， 而变换型系统结构图是直接对输入数据进行变换。 系统设计 :: 系统结构图
对于两种系统结构图，实际操作中常使用{{c1::}} 两种混合 变换型系统结构图 变换型系统结构图 系统设计 :: 系统结构图
常使用以{{c1::变换分析}}为主，{{c1::事务分析}}为辅的方式进行软件结构设计 系统设计 :: 系统结构图
变换分析是什么 是一系列设计方法的总称， 目的是把数据流图转化为软件结构 系统设计 :: 面向数据流设计 软件结构？或者说是转化为系统结构图？ 变换分析和事务分析都是软件设计的方法，他们都是将数据流图转化为系统结构图。
变换分析是将什么图转换为什么图？ 将 数据流图（需求分析阶段） 转换为 变换型系统结构图（系统设计阶段） 系统设计 :: 面向数据流分析
变换分析分为哪些步骤 1、重新画数据流图 2、将数据流图分为输入、输出、中心变换三部分 3、进行一级分解，将数据流图分解出的三部分转换为系统结构图 4、进一步分解，细化每个板块。 系统设计 :: 面向数据流分析 :: 变换分析
变换分析的注意事项有哪些 1、完成本模块所有的下属模块后才能转向下个模块的设计（设计顺序） 2、需考虑模块的耦合与内聚（模块性质） 3、黑箱技术 4、模块划分时，模块的下属模块不宜过多（模块划分） 5、遇到某些情况需要停止模块分解（停止条件） 系统设计 :: 面向数据流分析 :: 变换分析 设计的顺序，模块的性质是怎样的，黑箱，划分的规则，停止条件
模块划分时，一个模块的下属模块一般是几个左右 变换分析 5个 系统设计 :: 面向数据流分析 :: 变换分析
什么是 “黑箱”技术 变换分析 设计当前模块时，不需要考虑其下属模块的内部结构和实现方式， 只需要定义其为“黑箱”，而在下一步继续设计加工。 系统设计 :: 面向数据流分析 :: 变换分析
什么情况下停止模块分解 变换分析 1、不能细分为明显的子任务 2、分解成了所提供的模块或程序库的子程序 3、模块过小 4、模块的输入、输出是系统输入输出的信息 系统设计 :: 面向数据流分析 :: 变换分析
正确写法：{{c1::}} 事务型系统结构图 事物型系统结构图 系统设计 :: 面向数据流分析
事务的含义 面向数据流分析 是一种数据流，这种数据流可以引发一个或多种处理模块 系统设计 :: 面向数据流分析 :: 事务分析
事务分析的大致过程 面向数据流设计 1、根据数据流图进行分解 2、建立第一级事务性系统结构图 3、不断优化形成更加细分的结构图 系统设计 :: 面向数据流分析 :: 事务分析 大致过程，模糊化处理
简述这几个数据流图的主要图形是干什么的 数据流图
数据流图有哪几种基本成分 数据流图
两个加工之间只能有一条数据流{{c1::}} 数据流图 错 对 两个加工之间可以有多个数据流
数据流命名的两个原则 数据流图 1、不用使用意义空洞的名词 2、使用现实系统中已有的名字
数据流图中需要画控制流吗{{c1::}} 不能画 必须画 可以画 控制流不能画在数据流图中
激发条件需要画在数据流图中吗{{c1::}} 不能画 必须画 可以画 不要在数据流图中标出激发条件
加工的概念 数据流图 表示对数据的操作 模糊化
加工的编号是干嘛的 数据流图 说明该加工在层次分解中的位置
加工的命名要怎么弄 数据流图 1、不要用空洞的名字 2、要选用有意义，存在已有的名字
什么数据流不必命名 数据流图 流向数据存储或从数据存储中流出的数据流不用命名
外部实体的概念 数据流图 在系统之外的东西叫外部实体
对于加工来说输入输出是不是必须的{{c1::}} 数据流图 输入输出都是必须的 输入是必须的 输出是必须的 输入输出都不是必须的 每个加工至少得有一个数据输入流和一个数据输出流
数据是否可以不经过加工而直接在数据源、数据终点、数据存储之间流动{{c1::}} 数据流图 不可以 可以，但必须经过数据存储 可以，但是必须要有控制流
DFD与程序流程图在数据和控制方面的区别 DFD不表示程序的控制结构，只描述数据的流动。
数据流图，用例图，类图，程序流程图中哪一个有父图子图，要分层来画{{c1::}} 数据流图 用例图 类图 程序流程图 DFD分层多层。
描述画DFD的过程 1、画顶层 2、画下面的层次 3、先考虑开始和结束，暂时忽略系统过程 4、抓住主干，暂时忽略细节 5、随时准备重画 DFD是先暂时忽略过程，而用例图是暂时画整体的，后期再逐步细化。
画分层DFD的指导原则是什么（四条） 1、父图-子图平衡 2、局部数据存储 3、编号 4、分解的程度
父图-子图平衡的概念 数据流图 父图输入输出数据流 = 子图输入输出数据流
局部数据储存的概念 数据流图 加工不能从某个地方来，又回那个地方去。 只有等到某个层级加工可以从一个地方来，又到另一个地方去的时候才应该画出来。
加工的编号依据什么原则 数据流图 1、顶图不编号 2、子图的图号为父图加工号（加工是一个数据流图中的专有名词） 3、同等级的子图以最后的数字序号为区别
分解一般分解为大约多少层 数据流图 4±1层
各层各张数据流图的加工数据大概是多少 数据流图 7±2
DFD的改进手段有哪三点 1、检查正确性 2、提高易理解性/可读性 3、重新分解
可以从哪三个角度检查DFD的正确性 1、数据是否守恒/一致 2、数据存储使用正确 3、父图、子图是否平衡
数据不守恒情况的分类有哪两种 数据流图 1、有相应的数据输入，但是输出没有用到 2、输出用到了某个数据，但这个数据没有输入 数据流图 :: 检查正确性
关于数据存储使用的判断 数据流图 :: 检查正确性 检查只有流入没有流出的数据存储 或只有流出没有流入只有流出的数据存储 数据流图 :: 改进措施 :: 检查正确性 :: 数据存储的使用
可以通过哪三点提高DFD的易理解性 1、简化加工之间的联系 2、均匀分解 3、正确合理地命名 数据流图 :: 改进
什么叫不均匀的分解 数据流图 一张图中某些加工已经不能再分解了， 而另一些加工还可以继续分解出好几层。 数据流图 :: 改进 :: 提高易理解性
命名不当和分解不当有什么关联{{c1::}} 数据流图 分解不当 => 命名不当 命名不当 => 分解不当
重新分解的步骤 数据流图 1、把某张图的所有子图框起来 2、把这部分的各个子图分为几个部分， 让每个部分都联系紧密，与外界联系少。 3、把各个部分建立为新的子图 4、为新的子图命名和编号 数据流图 :: 改进 :: 重新分解
UML 中文 统一建模语言 英文缩写 需求分析 Unified Modeling Language
UML是面向{{c1::}}的 对象 过程
UML的概念 是一个统一的交流标准，包含了概念、术语和图形符号
UML是用于需求分析的方法论{{c1::}} 错 对 它只是一种建模语言
举例系统边界 用例图 计算机软硬件边界 某个部门 某个组织
为什么要进行系统边界识别 用例图 通过识别系统边界，以明确什么是系统，系统的职责是什么
参与者的概念 用例图 1、在系统之外 2、需要使用系统或与系统交互 如人，设备，外部系统
参与者有哪三种表示形式 用例图 1、icon形式：画一个小人，并注明名字 2、Label形式：画个框框，并注明名字 3、Decoration形式：框框里画个小人，并标注名字
所有的数据流都需要命名{{c1::}} 数据流图 错 对 最初输入和最后输出的数据流不用命名
用例的符号是怎样的 用例图 椭圆
简述系统、参与者、用例三者的关系 用例图 用例属于系统，在系统的范围内。 参与者不属于系统，在系统的范围外。 参与者与用例通过“关联”进行联系。
用例的获取方法（通过以下问题讨论用例） 用例图 对于参与者 1、想用系统干什么 2、想访问什么信息 对于系统 1、需要什么外部信息 2、需要把什么信息告诉参与者 3、如何维护 通过以下问题讨论用例： 1、参与者希望系统干什么 2、参与者在系统中访问/增改什么信息 3、系统需要哪些外部信息 4、需要将系统的什么事情告诉参与者 5、如何维护系统
用例的定义 用例图 系统与参与者的交互的说明 ，对其进行的文字描述（与上一句同义）， 提供了外部可见功能
用例的目的是{{c1::}} 用例图 定义系统行为 解释系统结构 用例的目的是定义系统行为，而不是解释系统的内部结构。
通过用例做需求分析的特点 用例图 1、从使用的角度，分析而不考虑内部结构实现方式 2、用例描述了一些用户需求，用户目标 3、是对系统行为的动态描述
{{c1::}}属于UML动态建模部分 用例图 数据流图
用例是一个单独的步骤{{c1::}} 错 对 把用例当做一个单独的步骤、操作或事务的处理是一个常见的错误
对于饮料贩卖机来说，是把饮料贩卖机这个硬件作为系统边界还是把商店或企业组织作为边界，该根据什么情况来选择呢 用例图 开发设备的话就用软硬件作为系统边界 从事企业过程就以企业组织为边界
用例图中有哪几种关系 关联association 泛化generalization 包含include 扩展extend
关联的含义 用例图中的关系 参与者与参与执行的用例的通信路径
泛化的含义 用例图中的关系 一般和特殊的关系，类似于类的继承与派生
包含 英文 include 中文 用例图
扩展 英文 extend 中文 用例图
包含的含义 用例图 其中一个用例的范围包含另一个用例
基本用例是什么 用例图中的关系 :: 包含 能包含另一个用例的，范围更大的用例
被包含用例是什么 用例图中的关系 :: 包含 被另一个用例包含，范围更小的一个用例
箭头方向是从{{c1::基本用例（范围大的）}}指向{{c1::被包含用例（范围小的）}} 用例图中的关系 :: 包含
什么时候使用包含用例 用例图 1、多个用例有相同功能，则将这些功能分解到另一个用例中 2、某个用例功能过多时，用包含关系创建两个小用例 一个“合”，一个“分”
扩展关系是怎样的 用例图 以某个用例作为基础，只有当这个用例可以执行时，扩展用例才能够执行
基本用例和扩展用例分别是什么 用例图中的关系 :: 扩展关系 基本用例：是独立的，是扩展用例可以操作的基础 扩展用例：不能独立执行，只有满足基本用例后才能执行
箭头方向的指向是怎样的 用例图中的关系 :: 扩展 由扩展用例（非独立）指向基本用例（独立，基本点）
包含和扩展关系的区别 用例图 依赖性不同。 包含关系中两个用例是独立的，都可以独立执行。 扩展关系中如果执行了扩展用例，那一定得执行基本用例。
什么关系的表示 关联 的图像表示法是怎样的 用例图
表示什么关系 扩展 的图像表示法 用例图
表示什么关系 泛化 图像表示法 用例图
表示什么关系 包含 图像表示法 用例图
用例图的概念 显示用例、参与者，以及它们之间关系的图
UML中，一个用例模型由{{c1::}}用例图描述 若干个 一个
用例需要描述哪些内容 用例图 1、用例的目标 2、用例启动条件（触发条件） 3、用例与参与者间信息传递（传递的信息） 4、用例中主路径与其他路径（传递的路径） 5、用例结束后系统状态（结束）
用例规约是什么 对用例的描述
前置条件 的含义 用例 :: 用例描述的主要组成 用例执行前应满足的条件
后置条件 的概念 用例 :: 用例描述的主要组成 用例执行完毕后可能处于的一组状态
主事件流的概念 用例 :: 用例描述的主要组成 正常情形，最常用的路径
用例图中，如果有被可扩展、包含、泛化的用例 应该怎么做 写出它们的名称，并说明使用的情况
用例描述中 用例优先级 的概念 用例 :: 用例描述的主要组成 说明用例的优先级，这代表了用户对用例的期望值
用例的优先级可以用来干什么 用例 :: 用例描述的主要组成 为今后开发制定优先顺序
用例描述的主要组成有哪些 用例图 1、用例名称 2、用例说明 3、参与者 4、前置条件 （扩展） 5、后置条件 （扩展） 6、扩展点 （扩展） 7、优先级 （扩展） 8、主事件流 （扩展） 9、其他事件流
用例分析的步骤 用例图 1、确定 系统的边界 和 参与者（确定范围） 2、确定每个参与者的行为，将其命名为用例（确定行为与命名） 3、分解共用公共的系统行为（包含关系） 4、把可以分解为扩展用例的分解为扩展用例（扩展关系） 5、编制用例脚本（画草图） 6、画用例图 7、将特殊情况的用例画成子用例图 8、细化用例图，解决重复和冲突
用例识别有哪两种方法 1、基于参与者 2、基于事件 面向对象和面向过程
基于参与者的方法是怎样的 用例识别 1、识别出于系统有关的参与者 2、对每个参与者 识别出他们参与的过程
基于事件的方法是怎样的 用例识别 1、识别系统响应的外部事件 2、把事件参与者与用例联系起来
识别用例有哪些要点 1、是有意义的目标 2、使用业务语言，用户观点 3、用例粒度
用例粒度问题是怎样的 粒度大则用例数少，粒度小则用例数多。 用例粒度无绝对标准。
组件级设计 同义词 过程设计 同义词
组件级设计位于哪个时间段 位于数据设计、体系结构设计、接口设计之后 系统设计 :: 面向过程组件设计
结构化构成元素有哪几种 1、顺序 2、条件 3、重复、循环 系统设计 :: 面向过程组件设计
详细设计工具可以分为哪几类 图形设计符号：流程图、盒图 表格设计符号：决策表 程序设计符号：PDL 系统设计 :: 面向过程组件设计
流程图的概念 用各种方块图形、线条、箭头表达解决问题的步骤及顺序的图 系统设计 :: 面向过程组件设计
{{c1::}}是算法的一种表示方式 流程图 结构图 数据流图 用例图
SOP 中文名 标准作业流程 英文缩写 Standard operating procedure
SOP是什么 用于企业，让任何人看到流程图都一目了然
程序流程图 与 流程图的关系 程序流程图属于流程图，但是好像这门课主要讲的是程序流程图 系统设计 :: 面向过程组件设计
制作流程图的优点有哪些 1、所有流程都很清楚 2、换人时好上手 3、画流程图时容易发现错误而进行改正 系统设计 :: 面向过程组件设计
流程图的各个符号表示什么意思 {{c1::}} {{c1::}} 系统设计 :: 面向过程组件设计 :: 流程图
流程图有哪几种基本结构 顺序 选择 循环 系统设计 :: 面向过程组件设计 :: 流程图 老生常谈了
盒图有哪几种基本控制结构 顺序型 选择型 WHILE重复型 UNTIL重复型 CASE型 系统设计 :: 面向过程组件设计 :: 盒图
盒图的顺序性长什么样子
盒图的选择型长什么样子 系统设计 :: 面向过程组件设计 :: 盒图
盒图的WHILE重复型长什么样子 系统设计 :: 面向过程组件设计 :: 盒图
盒图的UNTIL重复型长什么样子 系统设计 :: 面向过程组件设计 :: 盒图
盒图的CASE型长什么样子 系统设计 :: 面向过程组件设计 :: 盒图
判定表 同义词 决策表 同义词 系统设计 :: 面向过程组件设计
判定表 与 程序流程图 在 控制结构 分支判断 部分有什么重大的区别 判定表只能有两分支的判断的列表， 而程序流程图可以有多分支判断的列表
PDL长什么样
盒图长什么样
面向对象设计活动可以有哪些 系统架构设计 用例设计 类设计 数据库设计 用户界面设计 系统设计 :: 面向对象设计
架构设计的输入和输出分别是什么 输入：用例模型、分析模型 输出：物理结构、子系统、设计类 系统设计 :: 面向对象设计
架构设计分为哪几个步骤 系统设计 Step1:构造系统物理模型 Step2:设计子系统 Step3:非功能需求设计
构造系统的物理模型的过程 系统设计 1、用UML的xx图描述其物理结构 2、把需求分析得到的功能分配到具体的物理节点上
系统的物理模型长什么样子 系统设计 :: 面向对象设计
面向对象设计活动由什么人员进行 架构师 系统设计
设计子系统的步骤 架构设计 Step1:划分各个子系统 Step2:定义子系统间的关系 Step3:定义子系统的接口 系统设计 :: 面向对象设计 :: 架构设计
通过哪些依据来划分子系统 架构设计 1、按照功能 2、按照物理布局 3、按照软件层次 系统设计 :: 面向对象设计 :: 架构设计
按照软件层次划分子系统大概是什么样子的 架构设计 系统设计 :: 面向对象设计 :: 架构设计
子系统之间可以有些什么关系 架构设计 请求-服务关系：单向调用的关系 平等关系：双向调用关系 系统设计 :: 面向对象设计 :: 架构设计
解决子系统之间关系过于密切的方法有哪些 架构设计 1、重新划分子系统 2、重新定义子系统接口，将依赖关系定义在接口上 系统设计 :: 面向对象设计 :: 架构设计
非功能需求设计是什么 架构设计 可移植性、软件通用性、安全性 这些不是用户提出来的对用户有直接用处的部分 系统设计 :: 面向对象设计 :: 架构设计
什么是类 包含信息（数据） 和信息行为（函数）
类间关系有哪些 关联关系 聚合关系 组合关系 依赖关系 泛化关系 系统设计 :: 面向对象设计
分析类图和设计类图大概长什么样 系统设计 :: 面向对象设计
类的设计讲了哪几种类，说出他们分别的含义 实体类：业务实体，用于存储信息 边界类：用例、参与者之间若有交互，应建立边界类 控制类：控制协调对象 系统设计 :: 面向对象设计
细化用例的步骤 Step1:找出所有类 Step2:添加各种类的类型 Step3:添加类的关系 系统设计 :: 面向对象设计 :: 细化用例
详细设计一个类由什么人完成 构架工程师
类设计有哪些步骤 Step1:定义类的属性 Step2:定义类的操作 Step3:定义类间关系 系统设计 :: 面向对象设计 :: 类设计

创作不易，需要完整版anki文件私我支付宝付款，请备注姓名。
博主平时比较忙，但是每周会看一次私信，到账后会把anki文件发给付款者的