看这玩意复习你还会挂科？《软件工程篇》

软件工程：是指导软件开发和维护的一门工程学科 三要素方法/工具/开发过程 价值：促进项目成功

现代产品开发三原则：功用性、可行性、称许性 软件过程是软件工程的核心组成部分。

迭代 ：反复求精  增量：逐块建造    需求调查手段:研究文档、访谈、现场观察、问卷、原型法

经典软件过程：瀑布模型、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天）、任务（小时）

文章来源: fantianzuo.blog.csdn.net，作者：兔老大RabbitMQ，版权归原作者所有，如需转载，请联系作者。

原文链接：fantianzuo.blog.csdn.net/article/details/104073829