看这玩意复习你还会挂科？《软件工程篇》
软件工程：是指导软件开发和维护的一门工程学科 三要素方法/工具/开发过程 价值：促进项目成功
现代产品开发三原则：功用性、可行性、称许性 软件过程是软件工程的核心组成部分。
迭代 ：反复求精 增量：逐块建造 需求调查手段:研究文档、访谈、现场观察、问卷、原型法
经典软件过程：瀑布模型、RUP统一软件过程、Scrum敏捷过程、扩展ICONIX过程
瀑布模型：需求分析、需求定义、概要设计、详细设计、实现、系统测试、验收测试、维护
UML承载面对象思想。静态图：对象图/类图/组件图/部署图；动态图：用例图/序列图/活动图/状态图/协作图
需求是软件成功的基础，需求工程是解决需求噩梦手段：需求开发/调查/分析/定义/管理/确认/跟踪/变更控制
需求开发（获取用户需求/定义产品需求，找到痛点提出办法）需求调查需求分析（定义愿景、业务建模、用例分析）需求定义：规格说明书（（非）功能需求）需求管理（客户与开发方需求共同理解，维护与其他成果一致，控制变更）
三类人需求：老板战略/开源节流/定愿景；经理:简化管理优化流程 业务建模；业务建模;员工：工作简单用例分析
ICONIX过程：(开源节流用例驱动)愿景、业务建模(用例/现状序列图/改进)需求分析（系统/域）健壮性分析(健壮性图更新域模型)关键设计最终设计（详细设计）实现（域模型->更新->静态类图）
特点:早编码，缩短设计周期。简化RUP过程。基于敏捷思想。
与RUP比是轻量级过程。与敏捷比提供充足的需求设计文档，但不过度分析设计。
获取愿景：找项目老大（最有权力的干系人）得到期望（掏钱的目的）描述度量指标
业务建模步骤明确为谁服务（改进组织）什么现状从外部看：组织是价值的集合；从内部看是系统的集合。改进
业务建模意义把视角转向客户，清晰准确诊断。明确为谁服务，不为自己做；组织现状/痛处不足；如何改进/解决.
业务用例图：帮助从高层次了解组织的业务构成。业务执行者：享受价值；业务组织：提供的价值。
业务序列图（帮助从细节上了解组织的业务流程）用例对应一段流程优势：以面向对象的思想来看业务流程
作用：识别业务对象：确定业务对象间职责、协作和交互顺序；通过业务序列图了解现状，为业务的优化提供依据
组成：业务执行者；业务工人；业务实体；调用消息；返回消息 常用分支：循环loop、分支alt、可选opt
改进1新系统作为实体引入现有流程、查看可改进流程、评估改进结果
2了解目的，发现改进点：信息自动流转、封装复杂逻辑、职责转移、操作业务对象（管理系统）
结果复核（所有参与者签字确认或未达成共识需要返工）目的：完善建模成果，寻找遗漏错误的地方，修正，可以迭代回去继续做业务建模。关键干系人在信息和意见上达成一致，签字确认，下一阶段启动标志。
域建模步骤提取名词短语、排除重复相似、排除系统本身及范围外、第一版、整理第一版域模型
意义术语表确保清晰一致术语交流。比普通术语：图示化方式，清晰显示术语关系3修正完善演化为最终静态类图
域模型数据模型关系
域模型：分析模型、认识实体间关系的工具；数据模型：系统设计实现的一部分，描述用户需求在数据结构的实现
组成系统：主执行者：发起者,为其实现辅执行者：支持者；提供支持（后台）3系统边界、系统用例、用例关系
系统用例建模意义把视角转向新系统，站在最终用户角度看问题，是对新系统为系统执行者提供的价值的建模
绘制系统用例步骤：1确定系统边界 2识别系统执行者3识别系统用例，执行动作，生成执行者可观测价值结果
用例关系包含：封装一组相似动作以便复用。泛化：继承。扩展：一段相对独立且可选的动作
用例≠功能/步骤（用例是执行者愿望，很多步骤）大量用例分包：按执行者、按主题、按开发团队、按发布情况
系统用例描述干系人利益（客户：简单。银行：安全。法律：保护）基本路径（客户最想看到 “名动名” 主语是执行者或系统）扩展路径（意外分支）业务规则（限额）非功能性需求：做到的程度、功能性需求：做什么
软件需求规格书：正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性
需求评审：
1临时评审（回顾与用户日常沟通）2轮查（交叉产物互相提意见）3结对编程/走查/评审/审查4规划：谁参加/评审什么5总体会议6准备7审查会议：暴露讨论问题8返工：防形式主义9跟踪：解决问题避免再次出现
健壮性分析三种元素：边界类实体类控制器类
规则1执行者只和边界通话2边界和控制器3控制器和控制器4控制器和实体
健壮性步骤：创建图、用例文本、基本路径，执行者、边界对象和实体对象、控制器，元素之间的连线、扩展路径。
健壮性优点：1.用例的对象化图示，用例和对象链接起来2.指出了对象互相如何交互3.确保用例文本正确，提供了健壮性检查4.帮助确保用例考虑所有必要扩展路径，提供完整正确检查5.能够发现对象6.缩小分析和设计鸿沟
价值：帮助完善用例分析结果。完善域模型，做为需求分析走向系统设计的过度技术
关键设计意义：寻找对象间交互关系，进行方法分配。包括用例图、用例描述、健壮性分析图。
非功能性需求：可靠性、可用性、性能、可支持性
高内聚：一个软件模块由相关性强的代码组成，只负责一项任务，一个好内聚模块恰好做一件事，单一责任原则
低耦合：度量模块间直接依赖关系，模块与模块间接口应少而简单，如关系较复杂，模块划分，有利于修改与组合
详细设计（编码测试部署维护升级）技术架构：开发语言、网络拓扑安全、体系结构、硬件环境、软件环境
敏捷宣言敏捷=理念+优秀实践+具体应用（是敏捷起源基础，揭示更好开发方式，重新思考开发中的价值和如何更好工作，是以人为核心/迭代/循序渐进的开发方法）
1)个体与交互>过程和工具2）可以工作的软件>面面俱到的文档3)客户协作>合同谈判4）响应变化>遵循计划
（软件：复杂性/一致性/可变性/不可见性）敏捷有改变:管理者的转变\团队成员的转变
好功能列表有DEEP特征：详略得当、涌现的、做过估算、排列优先级。
Scrum产品负责人、scrum教练、开发团队
1)产品负责人和开发对产品业务目标形成共识2)产品负责人建立维护需求列表（不断新增改变），优先级排序3)产品负责人每轮迭代前，筛选高优先级需求本轮开发4)开发团队细化迭代需求，按照优先级依次迭代完成5)开发团队每日立会/特性开发/持续集成，使开发进度真正透明（每日立会）6)产品负责人对每轮迭代交付的可工作软件现场验收反馈（迭代评审会议）7)团队内部进行本轮回顾，发现可改进方面指导下一轮迭代（迭代回顾会议）
敏捷管理实践迭代计划会议（达成一致确定任务）、迭代执行、每日立会、迭代评审会议、迭代回顾会议（总结改进）
敏捷工程实践结对编程、测试驱动开发、持续集成、Code Review、产品发布规则、用户故事
用户故事三要素：客户价值、用户 级别：史诗故事（1月）、特性故事（1周）、冲刺故事（1天）、任务（小时）