河北师大软件工程复习PPT2
**************************
1.Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。
2.ICONIX软件开发过程：愿景、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现。
3.Scrum中涉及的角色：PO、Master、Team。
第二章
1.敏捷开发是一种 以人为核心、迭代、循序渐进的开发方法。
2.Scrum开发模型：提出问题、产品功能列表、迭代计划会、迭代、评审。
3.Scrum的适用场景：人数较少、最好能坐在一起、客户参与度高、快速移动互联网项目、自助性研发的产品。
4.敏捷是一种思想，Scrum是一个框架。
5.项目的背景：找到项目的主要服务对象、找到项目的目标（愿景）、项目的商业价值、项目的服务对象细分（用户建模）。
6.客户（系统的购买者）、用户（系统的使用者）。
第三章
1.解决别人愿意花钱解决的问题，就是商业价值。
2.用户建模四部曲：
·列出尽可能多的用户
·识别关键用户（购买决策者、主要使用者）
·分类、合并次要用户
·添加虚拟和极端用户
第四章
1.产品功能列表从客户而来。
2.用户故事三要素：角色、功能、客户价值。
3.在书写用户功能的时候应该是 主谓原则、动宾原则。
4.好故事的准则：
·独立的
·可讨论的
·对用户或客户有价值的
·可估计的
·小的
·可测试的
第五章 规划
1.Scrum发布周期：两种常见方法：每次迭代发布、多次迭代发布。
2.每次迭代发布适合：移动互联网项目、自主性研发产品。
3.一次迭代发布适合：传统项目、大型项目。
4.如何为backlog条目重要性评分？1-1000原则
5.用户故事的三个变量：范围、重要性、估算。
6.外部质量、内部质量
7.确定Sprint目标及长度、讲解Story、估算时间、任务分解、决定sprint要包含的故事、一些其他问题。
8.Sprint长度：3个星期是个不错的长度。
9.故事估算的单位：故事点。
10.“任务”和“故事”的区别是：
·故事是可以交付的东西
·任务是不可以交付的东西
11.团队怎样决定把哪些故事放到sprint里面：本能反应（凭着经验去计算）、昨日天气（查看团队历史）、生产率计算。
12.如果没有历史数据，默认的投入程度是70%
13.调整优先级、缩小范围、拆分故事
第五章 计划
1.燃尽图是在项目完成之前，对需要完成的工作的一种可视化标示（Sprint燃尽图、迭代燃尽图）
2.任务板的错误使用：第六章（13页）错在哪了？
3.迭代燃尽图展示了以故事点表示的在每轮迭代末剩余的工作量。
4.每日燃尽图显示了团队在某轮迭代中的进度，
第一章 ICONIX
1.ICONIX适用场景
·团队规模相对较大
·项目规模相对较大
·客户参与度不高
2.ICONIX过程：愿景、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现
3.ICONIX的核心思想：开源（尽量增多软件的功能点）、节流（降低开发中的成本）
4.增加收入：愿景、业务建模、需求分析（站在客户的角度来思考问题）
降低成本：健壮性分析、关键设计、最终设计、实现
。（站在开发人员的角度来思考问题）
5.愿景往往设计公司战略。
6.获取软件项目愿景的三步曲：
·找到软件项目的“老大”
·得到“老大”对项目的期望（愿景）
·描述出愿景的度量指标
7.老大是买方，老大就是要改善的组织中最有权力的干系人
8.愿景必须指出度量指标：不是做具体的事，是改善组织的指标 减少。。 提供。。 缩短。。
9.ICONIX软件过程是 用例驱动 的软件过程。
10.Scrum是测试驱动的
11.业务用例建模：了解客户的现在的情况，根据每个用例描述用例描述来画健壮性分析图。
12.域模型驱动转化为 类图
用例模型转化为 动态模型
域模型转化为 静态模型
13.ICONIX过程中的第一步：明确愿景
·愿景是确保项目成功的第一步
·愿景必须来自老大
·愿景必须是可度量的
第二章
1.业务建模的目的：从组织的角度来定位系统的价值。
2.系统仅仅是组织中的一个零件。
3.业务建模要求我们把视角从系统转向组织，站在客户角度看问题，以达到清晰准确地“知彼”。
4.组织：为了实现既定的目标
业务：
业务建模：
5.选定业务组织要结合系统愿景
6.在EA中完成业务建模第一步：业务用例建模。（找到要改善的组织、找到组织的业务执行者、找到组织的价值（业务用例））。
7.业务建模的步骤：
·明确我们为谁服务（选定愿景要改进的组织）
·要改进的组织是什么状况（业务用例图、现在业务序列图）。
·我们如何改进（改进业务序列图）
8.第一步（业务用例建模）、第二步（了解组织现在）
9.业务用例图帮助我们从高层次了解组织的业务构成。组成元素：业务组织、业务执行者、业务用例。
10.业务用例：业务组织为业务执行者提供的价值。
11.业务用例的意义：业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。
12.业务用例只针对业务执行者，内部活动不是业务用例。
13.识别业务用例：两条路线：从业务执行者开始，观察组织的内部
活动。
14.每个业务用例都代表一条业务流程，一般用文字、活动图或序列图来描述这个流程。
15.序列图是以面向对象的思想来看业务流程的。
16.业务序列图的组成：业务执行者、业务工人、业务实体。
17.业务工人：位于业务组织内部，负责业务流程中的
某些工作的人员。
18.业务实体：在业务用例的实现流程中，业务工人所使用的“系统”。
19.箭头代表责任。
21.改进业务组织的业务流程中的改进点：
·信息自动流转
·封装复杂业务逻辑
·职责转移
·访问和操作业务对象
·……
22.业务建模三步曲：
·who？（选定愿景要改进的组织）
·what？（要改进的组织是什么现状，采用业务用例图、现状业务序列图表示）。
·how？（如何改进，采用改进业务序列图表示）。
第三章 需求分析
1.术语表定义：域建模
2.功能性需求：系统用例建模
3.非功能性需求：RUPS
4.域建模为项目创建一个术语表。
5.域模型最终演化为静态类图。
6.域建模的步骤：（最先确定域模型之间的关系：泛化和关联）
·仔细阅读需求文档，提取出名词和名词短语。
·排除列表中重复、相似的术语。
·排除超出系统范围的术语。
·画出第一版域模型图
·整理第一版域模型
7.域模型之间的关系：泛化（一般元素和特殊元素的关系）和关联（两个类之间存在着某种语义上的联系）
8.系统用例建模的意义：
·系统需求分析的目的是把视角转向新系统，站在最终用户的角度看问题
·系统用例是对新系统为系统执行者提供的价值的建模。
9.系统用例图的组成：系统主执行者、系统边界、系统用例、辅助执行者、用例关系。
10.系统用例建模步骤：
·绘制系统用例图
·编写系统用例描述
·更新域模型
11.绘制系统用例图的步骤：
·确定系统边界
·识别系统执行者
·识别系统用例
·确定用例间的关系
12.主执行者：用例发起者；用例为其实现有价值的目标
辅执行者：用例支持者；用例的完整需要与其交互，得到其支持。
13.用例之间的关系：泛化、包含、扩展。
14.包含关系：使用包含用例来组装一组跨越多个用例的相似动作，以便多个基用例复用。
15.执行者必须与系统直接交互。
16.用例的命名：
·用例名称必须是动宾短语
·采用域模型的名称术语
·慎用弱动词、弱名词
17.描述一个事物的三个出发点：
·这个事物是什么？---结构
·这个事物能做什么？---功能
·人们能够用这个事物做什么？ ---价值
18.所有用例应该都能追溯到愿景目标。
所有的愿景目标都应该对应的用例实现。
19.用例描述的作用：
·用例图描述总体，用例文档描述细节。
·每个用例必须对应有用例描述
20.用例描述的基本组成：
·干系人利益
·基本路径
·扩展路径
·业务规则
21.用例是干系人的平衡点。
22.基本路径的书写要求：以主动语态、“名词-动词-名词”格式来书写。主语只能是执行者或系统。
23.扩展路径：系统要处
理的意外和分支。
24.常见的扩展点：
·系统验证
·步骤失败
·执行者的选择
25.基本路径不要涉及页面细节
26.基本与扩展分开
27.功能性需求，通俗讲就是系统可以做什么
28.非功能性需求，通俗讲就是系统可以把某项功能做到什么程度。
29.人无我有（功能性需求），人有我优（非功能性需求）。
30.软件产品的典型非功能性需求：
·可靠性
·可用性
·性能
·可支持性
31.需求获取的方法：
·研究文档
·问卷调查
·访谈
·观察
·研究竞争对手
32.需求分析就是确定新系统的目的、范围、定义和功能
33.域建模用例生成统一的关键术语表
34.用例建模用来定义系统的功能性需求
第四章 健壮性分析
1.用例分析强调站在用户角度看问题，而设计强调的是站在技术人员角度看问题。
2.健壮性分析的价值 -桥。
3.分析（what）、设计（how）
4.后序的设计实现都是基于如下前提：
·用例及用例描述正确；
·域模型正确
5.健壮性分析帮助完善和确认需求分析的成果。
6.健壮性分析的优点：
·用例的对象化图示，将用例和对象链接起来
·指出了参与用例场景的对象互相之间如何交互
·确保用例文本的正确性，从而提供了健壮性的检查
·帮助确保用例考虑了所有必需的扩展路径，从而提供了完整性和正确性检查
·让你能够发现对象
·缩小分析和设计的鸿沟，从而最终完成初步设计
7.健壮性分析中的三种要素：边界类、实体类、控制器类
8.经典的三层架构：表示层（编辑类）、业务逻辑层（控制器类）、数据访问层（实体类）
9.基于健壮性分析更新域模型
10.箭头代表责任、虚线代表返回值
11.健壮性分析是在用例描述上画出来的
第五章 关键设计
1.关键设计开始考虑如何制造的问题，关键设计解决的是功能性需求如何实现（实体驱动、责任驱动）
2.基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互。
3.序列图的要素：执行者、边界类、实体类、控制器类
4.序列图和类图里面的方法是一一对应的。
5.边界类不添加到类图中。
6.画序列图的时候不能加返回箭头
7.类之间的关系：泛化（实现了代码复用、实现了多态）、实现（接口和抽象类）
8.类之间的动态关系：依赖
9.类之间的等静态关系：关联、聚合、组合。
第六章 详细设计
1.招聘网站的背景描述
·环境现状
·可靠性
·可用性
·性能
·可支持性
38.详细设计的工作
39.时间架构及相关考虑
40.数据存储设计
41.交换设计
42.详细设计：（画部署图，部署到服务器上去）
·直接拷贝关键类图、
·客户端的类以C_开头，服务器端
的类以S_开头
·添加日志存储类
·银行的接口转换为服务器端
43.详细设计的步骤
填空10个
选择题10个
判断10个
简单2个
项目20、30（大题一般是作业）