4.需求分析(必考) 考点1:需求分析的概念 考点2:需求的分类 考点3:需求分析的工具 需求分析的概念 结构化分析的结果:一套分层的**数据流图，一本数据词典**，一组小说明(也称加工逻辑说明)、补充材料 需求的分类 非功能需求（性能需求）：性能，响应，并发 设计约束：法律法规，系统要求等 期望需求：用户没有要做，但是需要去做 兴奋需求：不要去做，是多余的 需求分析的工具 数据流图 数据流**必须包含一个加工** 加工，**名称一般是动词+名词，名词+动词** 数据存储：XXX文件，XXX表，XXX库 外部实体：不是系统本身，是使用系统的，或者第三方系统 数据字典 数据字典有以下4类条目:**数据流、数据项、数据存储和基本加工**。(源点和终点不再系统之内，不在字典中说明) 结构化语言：类似伪代码

3.软件开发模型(必考) 考点1:瀑布模型与V模型(考的最多) 考点2:演化模型(原型模型、螺旋模型) 考点3:增量模型 考点4:喷泉模型 考点5:统一过程UP 考点6:敏捷方法(考的较多) 考点：判断适用场景和特点 瀑布模型与V模型 结构化开发思想(适用需求明确)，文档作为驱动 V模型 需求分析阶段考虑验收和系统测试 概要设计阶段考虑集成测试 详细设计阶段考虑单元测试 强调测试贯穿始终 原型模型 正确的需求定义是系统成功的关键。但是许多用户在开始时，往往不能准确地描述他们的需要，软件开发人员需要反复地和用户交流信息，才能全面、准确地了解用户的需求。在用户实际使用了目标系统以后，通过对系统的执行、评价，使用户更加明确对系统的需求。此时用户常常会改变原来的某些想法，对系统提出新的需求，以便使系统更加符合他们的实际需要。 原型模型是在开发真实系统之前，构造一个原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求；第二步则在第一步的基础上开发客户满意的软件产品。原型模型如图 (1) 原型模型的优点。 原型方法打破了瀑布模型方法的僵化，让开发过程之间和开发过程中的主客体之间提前融合。原型模型缩短了开发周期，加快了工程进度，降低了工程成本。 (2) 原型模型的缺点。 原型模型所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续修改可能会导致产品质量低下。 (3) 适用范围。 原型模型适合于预先不能确切定义需求的软件系统的开发。 演化模型:演化模型是迭代的过程模型，使得软件开发人员能够**逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况**。 适用于系统规模不是很大 螺旋模型 提到风险一般考虑螺旋模型 瀑布模型和演化模型结合，加入了风险分析。特别适用于庞大、复杂并且具有高风险的系统。 增量模型 第1个增量往往是核心产品**。将需求分段为一系列增量产品，每一增量可以分别开发。** 缺点是难以将需求划分为每个阶段的增量 与迭代模型的区别是，迭代模型第一版是不完整产品 喷泉模型 开发活动无明显界限，**迭代无间隙** 统一过程UP 出现UP/RUP都是统一过程 用例驱动，架构为中心，有迭代和增量的思想在内 敏捷方法 总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。适用于:“**小步快跑”的思想，适合小项目小团队**。 极限编程XP 考的多的两个 极限编程XP 并列争球法(SCRUM)**强调分组并行**

5.系统设计 （必考） 考点1:系统设计概述 考点2:模块设计**(必考)** 考点3:人机界面设计 考点4:架构设计 系统设计 概要设计：划分子系统/模块，对这些子系统 分配功能/任务，（看不到模块内部，最多能看到接口关系） 详细设计：针对子系统/模块内部设计，模块内部的数据结构等 模块设计 保持模块的大小适中 尽可能减少调用的深度 多扇入，少扇出（数量适中） 单入口，单出口 模块的作用域应该在模块之内 功能应该是可预测的 内聚性 顺序内聚和过程内聚需要注意区分，过程内聚只需要按一定的次序不一定要顺序 耦合性 数据耦合和标记耦合需要区分，标记耦合一般是传递复杂数据，如结构体 人机界面设计（接口设计） 黄金三原则 置于用户控制之下 减少用户的记忆负担 保持界面的一致性 界面美观不属于黄金三原则 架构设计 需要掌握浅层次的分类和应用特点 数据流风格 数据流风格对性能没有提升 管道-过滤器可以并行 调用/返回风格(层次结构) 主程序/子程序是单线程 面向对象是**显示调用**，明确哪些对象调用了哪些函数 一个层最多与上下两层交互，可以解耦，但对性能有影像，多一个层次就性能差一点 MVC风格 独立构件风格 虚拟机风格 解释器缺点是执行效率比较低 没有确定性算法的软件

7.软件维护 软件维护 软件维护的定义和重要性 1.软件维护是软件生命周期中最长且成本最高的阶段，因为软件的使用寿命可能长达数年甚至十年。 2.软件维护涉及的工作包括技术更新、人员流失后的工作接替等。 软件维护的四大类型 1.改正性维护（错误已经出现）：针对已经出现的错误进行修改。 2.预防性维护（错误还没发生）：在错误发生之前进行修改，以避免问题的出现，如千年虫问题的修复。 3.完善性维护：为了增加新功能或改善性能而进行的维护。 4.适应性维护：为了适应环境变化，如信息技术环境、市场需求变化(政策，操作系统)等进行的修改。 软件可维护性的决定因素 1.软件应易于理解和修改，以减少维护的难度。 2.软件应具有可修改性和可测试性，以确保修改后的软件能够正常工作。

9.软件质量保证模型（频率较高） 功能性，易用性，可移植性考察较多 易用性关注用户角度，如操作的便捷性、易学性。 可移植性涉及开发角度，关注软件在不同环境下的适应性。 功能性针对需求分析，强调准确完成需求并考虑系统的互操作性和安全保密性。