软件工程概述
1. 软件工程学科概览
软件的基本概念
程序、数据及其相关文档的完整集合。
软件危机的原因与途径
- 客户对软件需求的描述不精确，可能有遗漏、有二义性、有错误，在软件开发过程中，用户提出修改软件功能、界面、支撑环境等方面的要求。
- 软件开发人员对用户需求的理解与用户的本来愿望有差异，不能有效地、独立自主地处理大型软件的全部关系和各个分支，容易产生疏漏和错误。
- 管理人员、软件开发人员等各类人员的信息交流不及时、不准确，有时还会产生误解。
- 缺乏有力的方法和工具方面的支持，过分依赖程序人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化。
软件工程定义
软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。
软件工程学的研究目标
- 软件开发成本较低；
- 软件功能能够满足用户的需求；
- 软件性能较好；
- 软件可靠性高；
- 软件易于使用、维护和移植；
- 能按时完成开发任务，并及时交付使用。
生命周期
软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。
软件生命周期各个阶段的任务（考）
- 计划阶段: 确定总体目标和范围，研究可行性和解决方案，进行合理的估算。
- 分析阶段: 收集用户需求，建立分析模型，编写软件需求规格说明和初步的用户手册。
- 设计阶段: 进行总体设计和详细设计，包括软件体系结构、数据结构、用户界面和算法等方面的设计。
- 实现阶段: 将所设计的各个模块编写成计算机可接受的程序代码（编码）。
- 测试阶段: 设计测试用例，对软件进行测试，发现错误并进行改正。
- 运行和维护阶段: 测试是否正确地实现所要求的修改，面对的挑战和费用较高。
2. IT行业人才格局及成长路线
+++++++++++++++++++++++++++++++++++++++++++++++++ （选择，填空）
3. 软件过程—软件工程的核心组成部分
RUP（统一软件过程）的中心思想是：用例驱动、架构为中心、迭代和增量。
软件工程三要素（必考）
工具（系统）、方法（技能）、开发过程（框架）。
02 踏上ICONIX软件过程之路
企业生命线
ICONIX过程
需求工程
通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
- 需求开发（考、画图 写文档）: 通过调查与分析，获取用户需求并定义产品需求（需求调查、分析、定义）。
- 需求管理: 在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。
ICONIX和Scrum如何定义需求
（待补充）
需求实现过程
用例图、序列图、类图、健壮性图。
扩展ICONIX过程可分为：愿景、业务建模、需求分析、健壮性分析、关键设计、最终设计和实现。它又分为两个大的部分，分别是需求阶段和系统的设计与实现阶段，又可分为四个阶段：需求分析阶段、初步设计阶段、详细设计阶段和部署阶段。
愿景
获取愿景的步骤：
- 找到软件项目的“老大”；(要改善组织中最有权力的干系人)
- 得到“老大”对项目的期望（愿景）；（“老大”愿意掏钱开发这个系统的目的，但愿景不是功能，而是需求目的）
- 描述出愿景的度量指标。 （愿景描述必须指出度量指标，不是记录具体做了什么事，而是描述改善了组织的哪些指标、重要的是这个系统的好处）
03 业务建模，精准了解你的客户
业务建模的意义
站在客户角度看问题，找准客户及其愿景，明确要改进的组织现状和痛处，如何通过新系统的价值解决客户痛处、改良客户不足。在业务建模和需求分析阶段，忘掉自己技术专家的身份。
业务建模的步骤
- 从组织的角度定位系统应该提供的价值。
- 明确服务对象（选定愿景要改进的组织）。
- 分析要改进的组织现状（业务用例图和现状业务序列图建模）
- 识别如何改进（改进业务序列图）
业务用例图的组成
业务执行者：
- 在组织之外与组织交互的人群或组织
- 例如储户是银行的业务执行者，食客是餐馆的业务执行者。
业务用例
- 组织为业务执行者提供的价值
- 例如银行的业务用例有存款、取款、转账等；餐馆的业务用例有吃饭。
撰写业务用例简述
- 以简明扼要的文字对每个业务用例进行描述，通常的格式是：业务执行者通过业务组织的某些工作，达到固定目的。
- 例如取款用例的简述为：银行客户于财神银行营业时间，到财神银行的营业厅，由银行柜员协助办理取款业务。
- 注意：本过程非必须工作。适用于对陌生业务分析时，起到辅助记录和协助沟通的作用。
业务序列图的价值
业务序列图示例：
- 识别业务对象及其职责、协作和交互顺序。
- 通过序列图了解现状，为业务优化提供依据。
- 通过改进业务序列图，提前模拟新系统对现行业务流程的影响，评估新系统的可行性。
业务序列图的组成
业务工人：
位于组织内部，负责业务流程中某些工作的人员。例如银行工作人员，医院医生。
业务实体：
- 在业务用例的实现流程中，业务工人所使用的“系统”。例如银行的取款机、点钞机，学校的校园卡系统。
- 可以和业务工人相互取代各自的职责。
04 需求分析，用例分析法
域建模
解决术语不统一的问题。
域建模的步骤（考、简答）
- 仔细阅读需求文档，提取名词和名词短语。
- 排除列表中重复、相似的术语。
- 排除超出系统范围的术语和系统本身。
- 画出第一版域模型图。
- 整理第一版域模型图。
域模型之间的关系（选择，填空）
- 泛化：一般元素和特殊元素的关系。
- 关联：两个类之间存在着某种语义上的联系。
域模型的原则
系统用例图
包含系统边界、系统用例、用例关系、系统主、辅执行者。
绘制系统用例图步骤（考）
- 确定系统边界，分割出系统内和系统外。
- 识别系统执行者。 （系统执行者是处于系统之外，跨越系统边界，与系统进行有意义交互的实体，包括人、其他系统、硬件设备以及时间触发等相关因素（这里的 “时间” 可以理解为基于时间的触发机制或定时事件，它也能引发系统的交互行为，比如定时任务调度等）。）
- 确定系统用例。
- 确定用例间的关系。
系统用例建模
- 绘制系统用例图。
- 添加系统用例描述。
- 更新域模型。
系统用例之间的关系
泛化、包括、扩展
用例命名
登录处理
系统用例描述
不涉及页面细节，基本路径和扩展路径要分开，避免假想系统不能负责的事情。
功能性需求与非功能性需求
- 功能性需求: 系统可以做什么。
- 非功能性需求: 系统可以把某项功能做到什么程度。
典型四种非功能需求
- 可靠性: 系统在一定时间内、在一定条件下无故障地执行指定功能的能力。
- 可用性: 产品有效、高效并且满意地达成特定目标的程度。
- 性能: 系统实现预期功能的能力的特性。
- 可支持性: 系统在故障解决和系统升级方面的能力。
需求评审
05 需求与设计的桥梁：健壮性分析
健壮性分析的目标
需求与设计的桥梁。
健壮性分析中的三种元素
- 边界类: 与用户交互的对象，系统与外部世界的界面。
- 实体类: 现实世界存在的实体对象，域模型中的类。
- 控制器类: 边界和实体之间的“粘合剂”，包含大部分应用逻辑。
健壮性分析三种元素之间的交互规则
“名词-动词-名词”的语法格式。
健壮性分析的步骤（考、画图）
- 第一步：创建一个空的健壮性图。
- 第二步：将用例描述关联到健壮性图上（方便同步更新）。
- 第三步：从基本路径的第一句话开始画健壮性图。
- 第四步：贯串整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器，和各元素之间的连线。
- 第五步：将每一个扩展路径画在健壮性图上，并以红色标示出。
优化健壮性分析图
完善用例描述
健壮性分析的9项指导建议
更新域模型
注：健壮性分析在什么情况下可以不做？
- 有丰富的类似项目经验
- 熟悉业务细节
06 关键设计
如何降低成本、增加收入的问题。
方法
基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互.
意义
主要意义：就是要通过寻找对象之间的交互关系，进而进行方法（操作或行为）分配
关键设计的步骤
- 将现有的域模型直接作为第一版静态类模型。
- 基于用例描述和健壮性分析结果，画出每个用例的序列图。
- 健壮性图中的控制类会转化为方法；
- 如果也转化为控制类，那么就添加到类图中（一般边界类不添加到类图中）；
- 整理静态类图和序列图。
- 关键设计复核，迭代更新用例图、类图和序列图。
关键设计复核的方法
- 形式：面对面会议。（可能多次、每次会很久 ）
- 参会人：分析设计师、专家（分析、设计、开发）。
- 被审材料：用例图、用例描述、类图、序列图（为什么没有健壮性图？）；
- 过程：需求分析师主持，介绍需求分析成果，所有参与者交流讨论，达成统一理解和确认。
- 结论：所有参与者签字确认。 （也有可能是未达成共识，需要返工。）
- 注意：已不需要甲方人员参与。 这是一个技术性的复核对话， 因此，需要的是拥有技术思想的人员。
关键设计的实用价值
跨平台和外包。
07 详细设计（选择、填空）
详细设计的目标和任务
- 从软件开发的工程化观点来看，在使用程序设计语言编制程序之前，需要对所采用算法的逻辑关系进行分析，设计出全部必要的过程细节，并给予清晰的表达。
关键问题：怎样具体地实现这个系统
技术架构及相关考虑
- 选择开发语言
- 网络拓扑及安全
- 体系结构
- 硬件支持环境
- 软件支持环境
- 数据存储设计
- 交互设计
08 认识敏捷开发 = 理念 + 实践 + 应用
敏捷软件开发模式
- 敏捷开发的核心思想是以用户的需求进化为核心，采用迭代、循序渐进的方法进行的软件开发。
- 由传统迭代式软件开发模式发展而来，强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化。
- 总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成。
生命周期
敏捷宣言（必考）：
- 个体和交互胜过过程和工具。
- 可以工作的软件胜过面面俱到的文档。
- 客户合作胜过合同。
- 谈判响应变化胜过遵循计划。
核心理念（考）
- 聚焦客户价值，消除浪费；
- 激发团队潜能，加强协作；
- 不断调整以适应变化。
优秀实践
具体应用
因地制宜选择适合的敏捷开发
09 Scrum敏捷过程 （增量和迭代的过程）
迭代开发的好处
- 通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险。
- 通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要。
- 通过小批量减少排队，提供更灵活、快速的交付能力。
- 平滑人力资源的使用，避免出现瓶颈。
Scrum开发过程
- 项目整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个Sprint，每次迭代的时间建议为2-6周。
- 使用产品Backlog管理项目的需求。Product Backlog 是一个转型商业价值排序的需求列表，体现形式通常为用户故事。
- 团队（Team）从产品Backlog中挑选最有商业价值的需求，经过Sprint计划会议得到任务列表，称为Sprint Backlog。
- 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
敏捷团队的角色职责（考）
-
产品负责人(Product Owner) : 确保Team做正确的事，负责产品投资回报。
-
代表利益相关人（如用户、Marketing、管理者等），对产品投资回报负责
-
确定产品发布计划
-
定义产品需求并确定优先级
-
验收迭代结果，并根据验收结果和需求变化刷新需求清单和优先级
-
教练(Scrum Master) : 确保Team正确地做事，辅导团队应用敏捷实践。
-
辅导团队正确应用敏捷实践
-
引导团队建立并遵守规则
-
保护团队不受打扰
-
推动解决团队遇到的障碍
-
激励团队
-
开发团队(Team) : 负责产品需求实现，保证交付质量。
-
负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量
-
向PO和利益相关人演示工作成果（可运行的软件）
-
团队自我管理、持续改进
敏捷团队实践：完整团队
完整团队聚焦客户需求交付，提高协作效率
一、什么是完整团队
- 以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。
- 完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。
二、完整团队的关键要点
- 成员来自多功能领域：团队拥有完成目标所需的各职能成员；
- 坐在一起办公：团队成员无障碍地沟通；
- 团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键。
- T型人才，背靠背精神：每个成员都一专多能，工作上互助互补。
三、完整团队的好处
- 有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合；
- 通过面对面沟通提升沟通效率。
- 实现团队成员的高度协同，支撑持续地、短周期的交付。
传统与敏捷管理的区别
- 管理者的转变: 从“控制”团队转向“激发”团队。
- 团队成员的转变: 从“听从安排的独立贡献者”转向“全方位的积极参与者”。
PO的特征
SM的特征
开发团队的特征
关于团队的深度思考
1.谁来担任PO？
- 内部开发：内部业务方代表，例如为市场营销团队开发系统，那么就应该由市场营销团队中得到授权的人当PO；
- 商业开发：组织内部员工，充当实际客户的代言人，通常是产品管理或营销部门成员；
- 外包开发：甲方安排PO，乙方安排相应的人对接；
2.谁来担任SM？
- 产品经理、项目经理、开发、测试、职业经理人、人力经理……,必须具备前面的6大特征并愿意掌握敏捷教练的技能；
3.SM必须全职吗？
- 对于成熟的Scrum团队，SM可以兼任其它团队的工作；
4.Scrum团队是否需要保持稳定？
- 尽最大可能稳定，成熟的Scrum团队非常难形成，一旦形成战斗力极强。
10 Scrum敏捷过程二
敏捷工作件
- 产品Backlog
- 迭代Backlog（Sprint Backlog）
- 完成标准
- 任务看板
- 燃尽图
敏捷软件开发过程
- PO和开发团队对产品业务目标形成共识
- PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序
- PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发
- 开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成
- 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明
- PO对每轮迭代（2－4周）交付的可工作软件进行现场验收和反馈
- 团队内部进行本轮冲刺的过程回顾，发现可改进的方面，指导下一轮迭代
产品功能列表
特性、缺陷、技术工作、知识获取。
好的产品功能列表具备DEEP特征
详略得当、涌现的、做过估算、排列了优先级
- 详略得当。马上要做的在顶部，工作量小，内容非常详细，可以在最近的一个冲刺实现。近期不打算做的放在底部，工作量大，内容粗略。
- 涌现的。根据不断涌入、具有经济价值的信息持续更新，适应变化。产生涌入的原因：
- 客户的新想法
- 竞争对手的行动
- 意外的技术问题等
- 做过估算。每个条件都做过大小估算（就是完成这个条目需要的工作量，用故事点或理想天数表示）。顶部的详细精确，底部的可以用L、XL等表示
- 排列了优先级。最近几个冲刺，排好顺序，后续的先不排。如果有新条目出现，插入队列（原则上不插入当前冲刺）
迭代计划会议
迭代计划会议由团队共同确定迭代交付内容和完成标准
什么是迭代计划会议？
每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog
多团队迭代计划会议要分层召开
- 版本迭代计划会议：将产品Backlog（需求）分配给团队
- 团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务） ，分配给团队成员；
迭代计划会议内容
- 澄清需求、对“完成标准”达成一致。
- 工作量估计、根据团队能力确定本轮迭代交付内容。
- 细化、分配迭代任务和初始工作计划。
迭代计划会议的好处
- 通过充分讨论，使团队成员对任务和完成标准理解一致
- 团队共同参与，促进团队成员更认真对待自己的承诺。
迭代计划会议的关键要点
- 充分参与：Scrum Master确保PO和Team充分参与讨论，达成理解一致；
- 相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求；
- 确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序 。
迭代Backlog规划步骤
- 确定团队生产能力。
团队开展两周的迭代，全部时间都用于执行工作吗？ 1.SCRUM活动； 2.支持、维护； 3.日常事务：会议、邮件… 4.休假！！ 剩下的才是真正的生产能力
- 选择PBI。
1.有迭代目标的按目标选择； 2.无目标的按排好序的优先级选择； 3.绝不选择一个迭代做不完的PBI
- 细化冲刺目标、获得信心。
1.选取PBI的总工作量小于团队的迭代速率； 2.同时考虑当前迭代团队的生产能力
- 敲定承诺。
团队给出承诺，在本迭代周期结束时完成所选的PBI
迭代执行
迭代执行包含规划、管理、执行和沟通工作，以确保创建可工作的、经过测试的特性
每日站立会议
- 我昨天为本项目做了什么？
- 我计划今天为本项目做什么？
- 我需要什么帮助以更高效的工作？
Scrum组成
- 三个角色: PO, SM, Team
- 四个会议: 迭代计划会议、每日站会、迭代评审会议、迭代回顾会议
- 三个产物: Product Backlog、Sprint Backlog、燃尽图
Scrum特点
- 适于在不确定性高的环境中开发复杂产品。
- 简洁但有效
- 易于学习和掌握。
- 能够在开发进程中不断检查，并作出相应调整。
- 项目信息对所有干系人高度透明。
- 便于快速发现问题，促使团队和组织持续改进。
11 敏捷工程实践技术
- 用户故事
- 结对编程
- TDD（测试驱动开发）
- 持续集成
- CodeReview
- 发布规则
用户故事的编写（写用户故事）
用户故事便于团队站在用户角度分解细化需求并制定验收标准
什么是用户故事？
- 用户故事是一个用来确认用户和用户需求的简短描述。
- 典型的描述句式为：作为一个XXX客户，我需要XXX功能，能够带来XXX好处。
- 用户故事是站在用户角度描述需求的一种方式；
- 每个用户故事须有对应的验收测试用例；
- 用户故事是分层分级的，在使用过程中逐步分解细化；
用户故事的关键要点
- I – Independent，可独立交付给客户
- N – Negotiable，便于与客户交流
- V - Valuable ，对客户有价值
- E - Estimable ，能估计出工作量
- S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成
- T - Testable，可测试
用户故事的好处
- 站在用户视角便于和客户交流，准确描述客户需求；
- 用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；
- 用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。
故事样例
- 初始需求：
1.作为网络规划人员，我想要配置一个媒体网关，因为想要增加网络容量和服务
- 初次分解：
1.1作为网络规划人员，我想把媒体网关参数上传到管理系统
1.2作为网络规划人员，我想从管理系统下载媒体网关参数
- 再次分解：
- 1.2.1作为网络规划人员，我想用文件方式从管理系统下载媒体网关参数
用例：用户在管理系统上选择以文件方式下载媒体网关参数，执行成功后，检查 文件是否正确下载到本地且内容正确
1.2.2作为网络规划人员，我想用MML结构方式从管理系统下载媒体网关的参数
常见结对方法（如结对编程）
优点
- 提升代码和产品质量；
- 有效减少BUG。研究表明结对生产率比两个单人总和低 15%，但缺陷数少 15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高；
- 降低学习成本，促进团队能力提升和知识传播。
缺点
- 对于有不同习惯的编程人员，坐在一起工作可能会产生矛盾；
- 两个人一起工作可能会出现工作精力不能集中的情况。
结对编程的关键要点
- 程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象；
- 开始新Story开发的时候即可变换搭档，以增进知识传播；
- 培养团队成员积极、协作的心态能够增进结对编程效果；
- 实施初期需精心辅导，帮助成员克服个性冲突和习惯差异。
测试驱动开发
测试驱动开发的好处
- 和代码同步增长的自动化测试用例，能为代码构筑安全网，保证代码重构的质量；
- TDD有助于开发人员优化代码设计，提高代码可测试性。
测试驱动开发的关键要点
- 测试代码和源代码一样都需要简洁，可读性好；
- 测试用例的设计要保证完备，覆盖被测单元的所有功能；
- 每个测试用例尽量保持独立，减少依赖，提高用例的可维护性；
- 当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用 TDD 实现。
持续集成
什么是持续集成
持续集成，指团队成员经常集成他们的工作，通常每人每天至少集成一次每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证
持续集成的好处
- 大幅缩短反馈周期，实时反映产品真实质量状态；
- 将集成工作分散在平时；尽早发现集成错误，避免产品最终集成时爆发大量问题。
持续集成的关键要点
- 持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息；
- 自动化测试用例的完备性和有效性是持续集成质量保障；
- 修复失败的构建是团队最高优先级的任务；
- 开发人员须先在本地构建成功，才可提交代码到配置库 ；
- 持续集成的状态必须实时可视化显示给所有人；
- 大系统持续集成需分层分级，建立各层次统一的测试策略
git实践
- git branch [branchname] 创建分支
- git branch -a 列出所有本地分支和远程分支
- git checkout -b [branchname] 新建一个分支，并切换到该分支
- **git checkout [branchname] **切换到指定分支，并更新工作区
- git branch -d [branchname] 删除本地分支
- git push origin --delete [branchname] 删除远程分支
- git merge 把不同的分支合并起来
产品发布规则
Code Review (代码审查)
Code Review：代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。
为什么要Code Review：
代码风格和质量上的差异。差异越多对项目代码的可读性及维护性影响也越大。另外由于水平有限，可能引入错误，但测试很难发现。随着时间的推移，积累的问题越来越多，到一定程度后很难解决。
好处：
- 代码复查者(reviewer)能从他们的角度来发现问题并且提出更好的解决方案。
- 公开reviewer和被复查者的想法和经验能够促进团队间的知识的分享。通过给新员工看有经验的开发者的代码能够提高他们的水平。
- 能够鼓励开发者将工作进行的更彻底，因为他们知道代码将被其他的人阅读。
评审的内容：
- 编码规范问题：命名不规范
- 代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合
- 工具、框架使用不当：Spring、Hibernate、AJAX
- 实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好
- 测试问题：测试覆盖度不够、可测试性不好
自动代码复查工具、代码评审工具
12 极限编程
极限编程价值观：沟通、反馈、勇气、简单、尊重。代码集体所有，工作时间为每周40小时，XP与Scrum的区别。
13 重构
重构介绍，基本概念，目标，重构的级别。
