第一章：

什么是软件？

计算机系统中与硬件相互依存的另一部分。软件包括程序、数据及其相关文档的完整集合。

（1）能够完成预定功能呾性能的可执行指令（program） 
（2）使得程序能够适当地操作信息的数据结构（data） 
（3）描述程序的操作呾使用的文档（document）

软件危机的定义？

软件在开发和维护过程中遇到的一系列严重问题。

软件危机包含两层含义：

（1）如何开发软件
（2）如何维护数量不断膨胀的现有软件。

软件危机的表现：

（1）软件开发的迚度难以控制，经常出现经费超预算、完成期限拖延的现象。
（2）软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发 过程带来灾难性的后果。  
（3）软件文档资料不完整、不合格。由亍缺乏完整规范的资料，加上软件测试不充分，从而造成软件质量低下。 
（4）软件的可维护性巩，程序错误难以改正，程序丌能适应硬件环境的改变。
（5）软件价格昂贵，软件成本在计算机系统总成本中所占的比例逐年上升。

什么是软件工程？

软件工程是指导计算机软件开发和维护的一门工程学科

软件的生命周期？

1、计划阶段：确定待开发的总体目标和范围，研究系统的可行性；
2、分析阶段：分析整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册；
3、设计阶段：决定软件怎么做，集中于软件体系结构数据结构、用户界面和算法
4、实现阶段 ：将所设计的各个模块编写成计算机可接受的程序代码
5、测试阶段：设计测试用例，对软件进行测试，发现错误，进行改正；
6、运行和维护阶段：应在软件的设计和实现阶段充分考虑软件的可维护性；

软件工程的三要素：

1、工具（例：EA、Axure、MoinMoin、XMind等等.....）；
2、方法(例：业务建模方法、需求方法、项目管理方法、配置管理方法)；
3、开发过程（根据客户、团队和项目特征指定框架，关键是对核心活动的选取和定义，如业务建模、需求、分析、设计、实施、发布）；

经典的软件过程：

1、瀑布模型
2、RUP统一软件过程
3、Scrum敏捷过程
4、扩展ICONIX

软件过程之-----瀑布模型：

1、特点及其缺点：

（1）特点：自上而下、相互衔接的固定次序，上一个阶段的变换结果是下一个阶段变换的输入，相邻两个阶段具有因果关系；
（2）缺点：各个阶段划分固定，阶段之间产生了大量文档，增大了工作量。开发模型是线性的，用户只有等到整个过程的末期才能见到开发结果，增加了风险；早期的错误等到后期的测试阶段才能发现，进而带来严重的后果；

2、过程：

（1）需求分析 
（2）需求定义 
（3）概要设计
（4）详细设计 
（5）实现 
（6）系统测试 
（7）验收测试 
（8）维护

软件过程之----RUP统一软件过程：

1、特点：

中心思想是用例驱动、架构为中心、迭代和增量

迭代：反复求精

增量：逐块建造

软件过程之-----扩展ICONIX

7个阶段：

1、愿景
2、业务建模
3、需求分析
4、健壮性分析
5、关键设计
6、最终设计
7、实现

获取愿景三部曲：

1、第一步：找到项目的"老大"
2、第二步：得到“老大”对项目的期望（愿景）
3、第三步：描述出愿景的度量指标；

业务建模的意义和步骤：

1、意义：

业务建模要求我们把视角从软件系统转向客户组织，站在客户的角度看问题，以达到清晰准确地“诊断”，对症“开方”。

1、明确为谁服务--找准客户及其愿景，切记不是在为自己做系统；
2、要改进的组织是什么现状---有什么痛处和不足；
3、如何改进--新系统的价值就是解决客户痛处、改良客户不足，这才是客户愿意掏腰包的动力
4、在业务建模和需求分析阶段，忘掉自己技术专家的身份；

2、步骤：

1、明确我们为谁服务（选定要改进的组织）
2、要改进的组织是什么现状（业务用例图、现状业务序列图）
3、我们如何改进（改进业务序列图）

业务建模的第二步（了解组织现状）

从外部看：组织是价值的集合，用业务用例图来建模；
从内部看：组织是系统的集合（人是一种智能系统），用业务序列图来建模；

业务用例（从外部看企业）

业务用例图帮助我们从高层次了解组织的业务构成。

业务用例图的组成：

1、业务执行者：在业务组织之外，与其交互，享受其价值的人或组织；例如食客是餐馆的业务执行者，顾客是超市的业务执行者；
2、业务组织：超市、餐馆；
3、业务用例：业务组织为业务执行者提供的价值。例如餐馆的业务用例有吃饭、点餐；超市的业务用例有结账；

业务序列图（从内部看企业）

业务序列图帮助我们从细节上了解组织的业务流程。
序列图以面向对象的思想来看业务流程。（优势）

业务序列图的组成：

1、业务执行者
2、业务工人：位于业务组织内部，负责业务流程中某些工作的人员；（例：银行工作人员、餐厅的服务员）
3、业务实体：在业务用例的实现柳橙汁，业务工人所使用的的“系统”。（例：银行数钞机、餐馆自动点餐机）；可以和业务工人相互取代各自的职责；
4、调用消息
5、返回消息

业务序列图的作用：

1、识别业务对象:业务执行者、业务工人、业务实体；
2、确定业务对象间的职责、协助及交互顺序；
3、通过序列图来了解现状，为业务的优化提供依据；

序列图中的几种分支：

1、循环分支：loop
2、条件分支：Alt
3、可选分支：Opt

业务序列图的高级话题：

1、消息的名字：代表责任和目的
2、消息的方向：代表责任委托，不是数据流动
3、知画领域相关的系统
4、最小单位是人肉或独立智能系统；
5、把时间看做特殊的业务实体：时间也可以是执行者，用时间执行者来标识预定的事件；

改进业务序列图（开个好方子）

改进业务序列图步骤（流程）：

1、将“新系统”作为一个业务实体进行整体设计；
2、将“新系统”引入组织现有业务流程；
3、查看其可以改进的流程；
4、评估改进结果；

了解业务组织现状的目的—发现流程中的改进点：

信息自动流转（自动化）
封装复杂业务逻辑（封装业务工人的行为）
职责的转移（银行员由操作点钞机到取款机）
访问和操作业务对象（员工管理系统、客户管理系统）

业务序列图和改进业务序列图的价值：

业务序列图战线企业内现有的业务流程，暴露问题，为优化提供直观依据。
改进业务序列图，可以提前模拟出新系统的出现，将对组织现行的业务流程造成哪些影响，可以提前评估新系统的可行性或提前进行相应的准备工作，实现安全平稳的组织改进。

业务建模结果复核目的（所有参与者签字确认）：

完善业务建模成果，寻找是否有遗漏或者错误的地方进行修正，若问题明显，就需要迭代回去继续做业务建模工作
关键干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志；

需求分析：

需求分析的几种主流方法：

原型法;原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户使用。补充和修改，在进行新的版本开发，反复进行这个过程，直到得出系统的“精髓解”，即用户满意；
用例法：由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最织实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。

域建模：

域建模的意义：

为项目创建一个术语表。确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域
域建模比普通的项目术语表优良的地方体现在：以图的方式清晰地显示出不同术语间的关系（见少理解偏差）
域模型图将通过不断修正完善逐步演化为最终的静态类图。

域建模的步骤：

仔细阅读需求文档，提取出名词和名词短语
排除列表中的重复、相似的术语
排除超出系统范围的术语
画出第一版域模型图
整理第一版域模型；

域模型之间的关系：

泛化：一般元素和特殊元素的关系
关联：两个类之间存在着某种语义上的联系。

高级话题：域建模的重要原则

不要花费太多的时间纠缠在最初的域建模工作上（几小时即可）
不要把域模型错误地认为是数据模型
在用例分析千做域建模，以避免命名混淆
不要指望最终的类视图和域模型图完全匹配，但它们在很大程度上应该是类似的
不要把与界面相关的类加入域模型中

用例分析：系统功能性需求分析的好工具；

系统用例建模的步骤

绘制系统用例图
编写系统用例描述
更新域模型

系统用例建模的意义：

系统需求分析的目的是把视角从业务组织转向新系统，站在最终用户及其它干系人的角度看问题；
吸引用例是对（新）系统为系统执行者提供的价值的建模；

业务用例VS系统用例：

业务用例：

例对银行进行业务建模，研究对象是银行，用于分析现有业务的利与弊；

系统用例：

对银行的软件系统进行系统建模，研究对象是银行的软件系统，用于分析新系统所带来的价值；

绘制系统用例图流程：

确定系统边界（系统包含功能与不包含的功能之间的界限；通俗来讲就是分割出系统内和系统外：系统内：需要我们投入大量的精力进行建设；系统外：需要我们考虑与他们的接口）
识别系统执行者（执行者是在系统外，透过系统边界，与系统进行有意义交互的任何事物；如人，系统，硬件设备；）
识别系统用例（1、用例是系统执行的一系列动作，这些动作生成特定执行者可观测的有价值的结果；2、用例是执行者通过系统达到的某个目标 ，例如：取款）
确定用例间的关系（扩展、包含、泛化）

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让他从基用例中声明的扩展点上

包含：使用包含用例来封装一组跨越多个用例的相似动作，以便复用；

泛化：子类继承父类；

系统用例的高级话题：

用例的命名：用例名称必须是动宾短语，采用域建模中的名词术语，慎用弱动词弱名词--会掩盖真正的业务（弱动词：进行、使用、复制；弱名词：数据、报表、表格）
用例不等于功能：（描述事物的三个出发点：结构、功能、价值）
用例不等于步骤：用例是执行者对系统的一个愿望（完成这个愿望可能需要经过很多步骤，但任何步骤不能够完整的反映执行者的目标）
用例与愿景目标（所有用例应该都能追溯到远景目标；所有的愿景目标都应有对应的用例实现）
怎么处理登录
用例分包（当存在大量用例时可以对用例进行分包：按执行者分包，按主题分包、按开发团队分包、按发布情况分包）
不要滥用用例关系

编写系统用例描述：

干系人利益：用例体现干系人利益的平衡点
基本路径：客户最想看到的、最关心的路径；把基本路径单独分离，凸显用例的核心价值；与扩展路径相比，更为有序；
扩展路径：系统要处理的意外和分支；与基本路径相比，更为无序；
业务规则：注意事项-不要涉及页面细节，基本与扩展分开，不要假想系统不能负责的事情；

用例描述的作用：

系统用例图描述总体，系统用例文档描述细节
每个系统用例必须对应有系统用例描述；

完整的用例文档：（完整不等于必需）

用例编号：用例名
执行者
前置条件：开始用例前系统及其环境的状态；形式：必须是系统能检测到的；内容：不涉及到涉众的利益；
后置条件：用例成功结束后系统应该具备的状态；
干系人利益
基本路径
扩展路径
字段列表：可以用自然语言，也可以用表达式；+：数据序列；【】：可选项；{}：多个；{| | |}：可能取值；A=B：把B的结构赋给A；
业务规则
设计约束：必须来自于干系人；界面样式，报表，平台，语言，外系统接口；

非功能性需求（系统可以把某项功能做到什么程度）：

功能性需求：系统可以做什么（人无我有）；
非功能性需求：系统可以把某项功能做到什么程度（人有我优）；

软件产品的典型非功能性需求：

可靠性（Reliability）：系统在一定时间内，在一定条件下无故障地执行指定功能的能力；
可用性（Usability）：一个产品可以被特定的用户在同特定的上下文中，有效、高效并且满意得达成特定目标的程度；
性能（Performance）：系统实现预期功能的能力的特性
可支持性（Supportability）：系统在故障解决和系统升级方面的能力

SRS（软件需求规格书）：正确定、必要性、优先级、明确性、可测性、完整性、一致性、可修改性；

需求评审：

临时评审：在日常沟通中做回顾确认；
轮查：交叉交换文档产物，互相提出意见
结对编程
走查
小组评审
审查

需求审查：主要阶段

规划：谁参加？评审什么
总体会议（会前会）：召集参加评审会的所有成员开一个简短的会议，讨论、明确要评审的内容、评审的要点、评审时所需的资料、缺陷检查表
准备：评审人员提前阅读和准备，才能提出有价值的建议
审查会议：暴露问题、讨论问题，待审查文档应该符合；
返工：没有返工的评审必然沦为“形式主义”。审评中发现的错误必须得到重视和回应
跟踪：解决问题：对评审提出的问题进行解决；  避免问题再次出现：对问题进行分类，因果分析，找到问题的深层次原因；

需求评审确认需求分析结果，然后才能迚入设计阶段。

用例分析强调站在用户角度看待问题，而设计强调的是站在技术人员角度去看问题，如何衔接两种角度的转换？-------健壮性分析；

健壮性分析的优点：

用例的对象化图示，将用例和对象衔接起来。
指出了参与用例场景的对象相互之间如何交互
确保用力文本的正确性，从而提供了健康性检查
帮助确保用例考虑了所有必需的扩展路径，从而提供了完整性和正确性检查；
让你能够持续发现对象；

健壮性分析技术两个主要的价值：

帮助完善用例分析结果
完善域模型，做为需求分析走向系统设计的过度技术；

健壮性分析中的三种元素：

边界类：与用户交互的对象，系统和外部世界的界面；
实体类：现实世界存在的实体对象，域模型中的类，它常对应于数据库表和文件。
控制器类：边界和实体间的“粘合剂”，将边界对象和实体对象关联起来，它包含了大部分应用逻辑，他们在用户和对象之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略。

健壮性分析中的三种元素的交互规则：

执行者只可以和边界对象通话；
边界对象和控制器可以通话；
控制器可以和另一个控制器通话
控制器可以和实体通话

健壮性分析的步骤：

创建一个空的健壮性图
直接将用例文本粘贴到图上（基本路径和扩展路径）
从基本路径的第一句话画健壮性图
贯穿整个用例基本路径，一次一个句子，画执行者、适当地边界对象和实体对象以及控制器，和各元素之间的连线
将每一个扩展路径画在健壮性图上，并以红色标示出；

健壮性分析的高级话题：

优化健壮性分析图
完善用例描述
健壮性分析的9项指导建议：
1、将用例文本直接粘贴到健壮性图上
2、从域模型中提取实体对象，如果发现之前有缺漏，则补充上
3、在画健壮性图时修正之前用例中模糊的地方
4、将每一个屏幕对象定义为边界对象，并进行清晰的命名
5、切记控制器对象大部分时候对应的是逻辑操作方法，偶尔也会对应真实的控制器类对象
6、再画健壮性图时，如果调用另一个用例，就直接在图上画出调用此用例即可；
7、切记健壮性分析描绘的是概要设计而不是详细设计；
8、健壮性图上的边界对象和实体对象会转化为时序图中的对象实例，而控制器对象会转化为消息或控制器实例。
9、切记健壮性图是用例的“对象化图示”，它的目的是优化和完善用例文本和域模型。

更新域模型：

基于健壮性分析更新域模型；

关键设计：

• 意义：通过寻找对象之间的交互关系，进而进行方法分配

• 方法：基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互；

• 步骤

 将现有的域模型直接作为第一版静态类模型
 基于用例描述和健壮性分析结果，画出每个用例的序列图；
 1、健壮性图中的控制类会转化为方法
 2、如果也转化为控制类，那么就添加到类图中
 整理静态类图和序列图
 关键设计复核，迭代更新用例图、类图和序列图；

• 如何决定控制器类分配给哪个类

高内聚、低耦合，是判断设计好坏的标准。

目的：使得模块的“可重用性、移植性大大增强；”

 高内聚：指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则；
 低耦合：指一个软件模块与模块之间的接口，尽量少而简单。如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分，降低相互的依赖。这样有利于修改和组合；

• 关键设计复核方法：

形式：面对面

参会人：分析设计师、专家

被申材料：用例图、用例描述、类图、序列图（为什么没有健壮分析图）

结果：参会人员都必须要签字

详细设计：

（编码->测试->部署->维护->升级）

技术架构及相关考虑：

选择开发语言
网络拓扑及安全（各种设备如何连）
体系结构（三层：用户界面、业务逻辑、数据访问）
硬件支持环境
软件支持环境（数据库、交互设计）

详细设计范例：

• 序列图

• 组件图

• 部署图

软件过程之----Scrum敏捷开发

敏捷宣言：是敏捷起源的基础，由4个简单的价值挂组成，敏捷宣言的签署推动了敏捷运动，敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作;敏捷是一种以人为核心、迭代、循序渐进的开发方法；

个体和交互            胜过       过程和工具
可以工作的软件         胜过       面面俱到的文档
客户合作              胜过       合同谈判
响应变化              胜过       遵循计划

虽然右项也具有价值，但我们认为左项具有更大的价值

对敏捷常见的误解：

误解一： 敏捷开发意味着可以不需要文档、设计和计划
误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合
误解三： 敏捷只适用于小项目开发
误解四： 敏捷只会对研发产生改变
误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了
误解六： 引入敏捷只需要按照既定的步骤去做就可以了
误解七： 敏捷是CMM 的替代品，是另一种流程
误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了

敏捷=理念+优秀实践+具体应用

• 理念

 聚焦客户价值，消除浪费
 激发团队潜能，加强协作
 不断调整以适应变化

• 优秀实践：业界敏捷优秀实践概览；

• 具体应用：因地制宜选择适合的敏捷实践

SCRUM是当前最流行的敏捷过程；

敏捷团队的角色职责：敏捷团队包括三个核心角色

PO特性：领域能力、人际交往能力、决策力、责任心
SM特性：见多识广、善于提问、有耐心、有协作精神、保护团队、公开透明
开发团队的特性：自组织、跨职能的多样化和全面化、T型技能、透明沟通、团队规模适中、专注、有责任感、团队成员稳定

敏捷软件开发过程:

PO和开发团队对产品业务目标形成共识
PO建立和维护产品需求列表（需求会不断新增和改变），并进行优先级排序
PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发
开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成
开发团队每日站立会议，特性开发、持续集成，使开发进度真正透明
PO对每轮迭代（2--4周）交付的可工作软件进行现场验收和反馈
团队内部进行本轮冲刺的过程回顾，发现可改进的方面；

敏捷工作件

• 产品backlog（经过优先级排序的动态刷新的产品需求清单，用来指定发布计划和迭代计划）

好处：

 通过需求的动态管理应对变化，避免浪费；
 易于优先交付对用户价值高的需求；

关键要点：

 清楚表述列表中每个需求任务对用户带来的价值：作为优先级排序的重要参考；
 动态的需求管理而非“冻结”方式：PO持续性地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代。
 迭代的需求分析过程，而非一次性分析清楚所有需求：只对近期迭代要做的需求进行详细分析，其他需求停留在粗粒度；

好的产品功能列表具有DEEP特性：

 详略得当
 涌现的：目的是适应变化，产生涌现的原因有客户的新想法，竞争对手的行动，意外的技术问题等
 做过估算
 排列优先级

• 迭代backlog（迭代backlog是团队在一轮迭代中的“任务”清单，是团队的详细迭代开发计划）

好处：

将需求分解成更细小的任务，利于对迭代内进度进行精确控制；剩余工作量可用来实时跟踪团队当前进展；

关键要点：

 “任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；
 任务要落实到具体的负责人；
 任务粒度要小，工作量大于两天的任务要进一步分解；
 用小时作为任务剩余工作量的估计单位，并每日重估计和刷新；

• 完成标准（衡量团队工作的完成标准）

• 任务看板

• 燃尽图（Y轴工作，X轴时间，理想情况下，改图是一个向下的曲线）

敏捷管理实践：

迭代计划会议：充分参与、相互承诺、确定内部任务；
迭代执行：规划、管理、执行、沟通工作，以确保创建可工作的、经过测试的特性；
每日立会：昨天做了啥，今天计划干啥，需要啥帮助更加高效的工作；
迭代评审会议：每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户需求；由SM组织，PO和用户代表负责验收、Team负责演示可工作的软件；
迭代回顾会议：哪些做得好，哪些工作还可以做得更好，在下次迭代在哪些方面进行改进；

迭代周期通常为2–4周，对应的规划时间为4–8小时；

敏捷工程实践技术：

用户故事
结对编程
TDD（测试驱动开发）：在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构华优化，TDD要求测试可以完全自动化运行；
持续集成：
CodeReview：
发布规则

用户故事：

体现客户（用户）价值，轻量级的点位符
3C特质
1.卡片（Card），作为XX，我希望XXX，这样可以XXX；
2.对话（Conversation）:不描述到细节，由团队通过持续性对话细化，激发大家的深度理解；
3.确认（confirmation）：有明确的验收标准
用户故事级别
史诗故事（1--2月）
特性故事（1--2周）
冲刺故事（1--2天）
任务（几个小时）：可分工执行

用户故事的标准：

独立
可协商
有价值
可估算
大小合适
可测试

敏捷有哪些改变：

• 管理者的改变（学会放松“控制”）

• 团队成员的转变（从被动到主动）

作者：可乐加冰灬

原文链接：https://blog.csdn.net/qq_42936836/article/details/103666276