· 使用ECB实现make reservation用例的详细设计(包含用例简介，顺序图，类图)。

准备

用例图

界面原型

参照文档Asg_RH说明。

领域模型

数据库设计(ER 逻辑模型)

识别类

用例简介

make reservation 用例包括的子用例有search hotels、choose hotel、choose room type和confirm reservation，其中confirm reservation中还包括了provide personal info、add reservation to basket和make payment子用例。

结合用例图、界面原型和领域模型，能够识别出以下类：

Boundary

SearchHotelsWindow ChooseHotelWidnow ChooseRoomWindow ConfirmReservationWindow MakePaymentWindow

Controller

MakeReservationController：执行make reservation用例时的一个控制类

Entity

Hotel Location Room Reservation Payment Customer CreditCard

动态图设计

顺序图

静态图设计

类图

· 将逻辑设计类图映射到实际项目框架的包图。用树形结构表述实现的包和类。

· 描述软件架构与框架之间的区别与联系

软件架构相当于一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。软件架构就是把系统分解为一些部件，描述这些部件的职责及它们之间的协作行为。

框架是特定语言和技术的架构应用解决方案。框架是具体语言和技术相关的一种或多种架构组合的实现。

两者的主要区别在于架构与语言无关，适用于特定领域的普遍系统设计；而框架是与特定语言和技术相关，适用于某些场景的具体解决方案。框架是集成了技术代码和多种第三方解决方案的工具，能够帮助开发者聚焦于业务逻辑代码而不是具体的技术实现；架构是描述软件系统如何设计的重要策略，能够指导开发者进行系统的开发。简单来说，架构属于设计，框架属于实现。

两者的联系是软件架构中的组件或子系统可以使用框架进行实现，而某些框架本身的设计也需要组合利用其他架构的设计思想。

· 以你的项目为案例

• 绘制三层架构模型图，细致到分区
• 结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

给开发者带来的便利：

• 每个层或包的职责是清晰的，模块化并可扩展的。系统分析的每个类会分明确的放置；
• 提供了隐式的程序复用准则；
• 每个层涉及的技术是明确的。这使得程序员可以通过快速培训上岗；
• 通过依赖估计项目变化产生的工作量；
• 开发次序和重要性是明确的。领域模型、基础模块（用户和基础数据的DTO和Service必须优先开发与测试），减少这些模块的错误，特别是领域模型设计失误，是项目成功的关键；
• 并行开发支持。利用前后端分离，实现并行开发。

· 研究 VUE 与 Flux 状态管理的异同

不同点：

VUE

在VUE中，有一个专门的状态管理库——Vuex，它的状态管理基本原理如下：

Vuex使用单一状态树，用一个对象就包含了全部的应用层级状态，也即每个应用将仅仅包含一个store实例(包含多个State)。这个状态变化过程大概就是用户的交互操作action经过Dispatch后，View调用store.commit提交对应的请求到store中对应的mutation函数，然后store再改变生成新的state，最后Vue组件检测到数据变化自动渲染。

Flux

Flux的状态管理也与此类似(Vuex其实有参考Flux进行设计)，不过Flux中没有对应Vuex中的Mutations状态，如下过程：

用户的操作同样会触发 Actions，然后被提交到一个集中的 Dispatcher 当中。当 Actions 被派发之后，Stores 将会随之更新自己并且通知 Views 进行修改。

相同点：

两者均是对MVC框架的一种改进，其中都有设计解决原来在表示层中可能存在的一个 Model 可以被多个 Views 读取，并且可以被多个 Controllers 进行更新的问题，避免在大型应用当中，单个 Model 会导致多个 Views 去通知 Controllers，并可能触发更多的 Model 更新的复杂结果。

建模练习

选择对Forest App进行建模练习

软件描述文档：Forest应用

用例图

种树流程活动图

Forest 领域模型

树对象的状态图

成功种树场景的系统顺序图

操作协议

1）使用 UML State Model

参考Asg_RH文档，对Reservation/Order对象建模：

其中，个人参考了去哪儿订旅馆网站中对订单处理的操作。

2) 研究淘宝退货流程活动图，对退货业务对象状态建模

以下状态图是根据淘宝退货流程活动图进行设计的：

1. 领域建模

a. 阅读Asg_RH文档，按用例构建领域模型。

根据Task2的要求，使用工具UMLet绘制“Reserve Hotel”的领域模型图如下：

b. 数据建模(E-R 模型)

- 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型）

- 导出 Mysql 物理数据库脚本

这里使用的数据库系统为MySQL 4.0：

drop index Owns_FK on CreditCard;

drop index "Paid-with_FK" on CreditCard;

drop table if exists CreditCard;

drop table if exists Customer;

drop index "Is-in_FK" on Hotel;

drop table if exists Hotel;

drop table if exists Location;

drop index "Paid-by_FK" on Payment;

drop index "Paid-with2_FK" on Payment;

drop table if exists Payment;

drop index Reserves_FK on Reservation;

drop index "Made-by_FK" on Reservation;

drop index "Paid-by2_FK" on Reservation;

drop table if exists Reservation;

drop index Has_FK on Room;

drop table if exists Room;

/*==============================================================*/
/* Table: CreditCard                                            */
/*==============================================================*/
create table CreditCard
(
   cardType                       varchar(50)                    not null,
   cardNumber                     numeric(50,0)                  not null,
   paymentID                      int,
   emailAddress                   varchar(50)                    not null,
   securityCode                   numeric(3,0)                   not null,
   expiryDate                     datetime                       not null,
   primary key (cardNumber)
)
type = InnoDB;

/*==============================================================*/
/* Index: "Paid-with_FK"                                        */
/*==============================================================*/
create index "Paid-with_FK" on CreditCard
(
   paymentID
);

/*==============================================================*/
/* Index: Owns_FK                                               */
/*==============================================================*/
create index Owns_FK on CreditCard
(
   emailAddress
);

/*==============================================================*/
/* Table: Customer                                              */
/*==============================================================*/
create table Customer
(
   fullName                       varchar(50)                    not null,
   emailAddress                   varchar(50)                    not null,
   primary key (emailAddress)
)
type = InnoDB;

/*==============================================================*/
/* Table: Hotel                                                 */
/*==============================================================*/
create table Hotel
(
   hotelName                      varchar(50)                    not null,
   cityName                       varchar(50)                    not null,
   starRating                     int,
   lowestPrice                    float(50,0),
   favourites                     int,
   primary key (hotelName)
)
type = InnoDB;

/*==============================================================*/
/* Index: "Is-in_FK"                                            */
/*==============================================================*/
create index "Is-in_FK" on Hotel
(
   cityName
);

/*==============================================================*/
/* Table: Location                                              */
/*==============================================================*/
create table Location
(
   cityName                       varchar(50)                    not null,
   primary key (cityName)
)
type = InnoDB;

/*==============================================================*/
/* Table: Payment                                               */
/*==============================================================*/
create table Payment
(
   amount                         float(8,2)                     not null,
   paymentID                      int                            not null,
   cardNumber                     numeric(50,0)                  not null,
   ReservationID                  int                            not null,
   primary key (paymentID)
)
type = InnoDB;

/*==============================================================*/
/* Index: "Paid-with2_FK"                                       */
/*==============================================================*/
create index "Paid-with2_FK" on Payment
(
   cardNumber
);

/*==============================================================*/
/* Index: "Paid-by_FK"                                          */
/*==============================================================*/
create index "Paid-by_FK" on Payment
(
   ReservationID
);

/*==============================================================*/
/* Table: Reservation                                           */
/*==============================================================*/
create table Reservation
(
   ReservationID                  int                            not null,
   hotelName                      varchar(50)                    not null,
   emailAddress                   varchar(50)                    not null,
   paymentID                      int,
   checkInDate                    datetime                       not null,
   checkOutDate                   datetime                       not null,
   primary key (ReservationID)
)
type = InnoDB;

/*==============================================================*/
/* Index: "Paid-by2_FK"                                         */
/*==============================================================*/
create index "Paid-by2_FK" on Reservation
(
   paymentID
);

/*==============================================================*/
/* Index: "Made-by_FK"                                          */
/*==============================================================*/
create index "Made-by_FK" on Reservation
(
   emailAddress
);

/*==============================================================*/
/* Index: Reserves_FK                                           */
/*==============================================================*/
create index Reserves_FK on Reservation
(
   hotelName
);

/*==============================================================*/
/* Table: Room                                                  */
/*==============================================================*/
create table Room
(
   roomType                       varchar(50)                    not null,
   roomPrice                      float(50,0)                    not null,
   adultsNumber                   numeric(8,0),
   childrenNumber                 numeric(8,0),
   RoomNo                         int                            not null,
   hotelName                      varchar(50)                    not null,
   isAvailability                 bool                           not null,
   usageTime                      datetime                       not null,
   primary key (RoomNo)
)
type = InnoDB;

/*==============================================================*/
/* Index: Has_FK                                                */
/*==============================================================*/
create index Has_FK on Room
(
   hotelName
);

alter table CreditCard add constraint FK_Owns foreign key (emailAddress)
      references Customer (emailAddress) on delete restrict on update restrict;

alter table CreditCard add constraint "FK_Paid-with" foreign key (paymentID)
      references Payment (paymentID) on delete restrict on update restrict;

alter table Hotel add constraint "FK_Is-in" foreign key (cityName)
      references Location (cityName) on delete restrict on update restrict;

alter table Payment add constraint "FK_Paid-by" foreign key (ReservationID)
      references Reservation (ReservationID) on delete restrict on update restrict;

alter table Payment add constraint "FK_Paid-with2" foreign key (cardNumber)
      references CreditCard (cardNumber) on delete restrict on update restrict;

alter table Reservation add constraint "FK_Made-by" foreign key (emailAddress)
      references Customer (emailAddress) on delete restrict on update restrict;

alter table Reservation add constraint "FK_Paid-by2" foreign key (paymentID)
      references Payment (paymentID) on delete restrict on update restrict;

alter table Reservation add constraint FK_Reserves foreign key (hotelName)
      references Hotel (hotelName) on delete restrict on update restrict;

alter table Room add constraint FK_Has foreign key (hotelName)
      references Hotel (hotelName) on delete restrict on update restrict;

- 简单叙说 数据库逻辑模型 与 领域模型 的异同

相同点：

1. 领域模型的实体类、类属性以及联系依次对应数据库逻辑模型的实体、实体属性和关系，它们有相同的名字以及相同的数据类型，这些都是与数据库的构建有关。

不同点：

1. 领域模型中包含有中介实体，而与数据库相关密切的数据库逻辑模型中是不存在中介实体的。
2. 数据库逻辑模型最主要应用在数据库构建方面，而领域模型除了数据库构建，还能用于描述其他模型架构。
3. 数据库逻辑模型能够转换为物理模型，进而转换成具体的数据库对象，原来的“实体-关系”转换成“表-外键”，实体的属性转换为表的列，同时每个列的数据类型转换为对应的DBMS中支持的数据类型，因此E-R模型中会存在领域模型中没有的主键、外键等概念。

1. 用例建模

a. 阅读Asg_RH文档，绘制用例图。按Task1要求，请使用工具UMLet，截图格式务必是png并控制尺寸

　　如下UML图：

b. 选择你熟悉的订旅馆在线服务系统（或移动APP），如绘制用例图。并满足以下要求：
- 对比Asg_RH用例图，请用色彩标注出创新用例或子用例
- 尽可能识别外部系统，并用色彩标注新的外部系统和服务

　　本次个人选择的是去哪儿网站中的订旅馆在线服务系统进行用例分析。

去哪儿网站订旅馆基本流程：

　　下面提供了个人在未登录状态下使用去哪儿网站订旅馆过程的截图，其中将与Asg_RH中例子区别的主要创新用例或子用例用红框框出。

搜索旅馆：

　　这部分的创新用例包括了选择境内外酒店、高级搜索酒店、地图搜索以及根据每日酒店推荐搜索。

选择旅馆：

　　这里额外提供了按条件筛选酒店的功能。

选择房间：

　　增加了用户点评、酒店设施概况、酒店位置交通、多个预订网站选择等等功能。

确认订单：

　　下面是预定完成后的预定信息，可以进一步选择取消订单或打印：

支付：

　　支付方式有多种类型。

用例图

　　其中红色用例表示创新用例或子用例，绿色外部Actors表示新的外部系统或服务，黄色注释也是与Asg_RH中网站所包括的不同点。另外，需要强调的是，去哪儿网站已经发展非常成熟，因而与文档中的旧网站相比，有更多的功能和服务，也就有更多的用例，用例图更加复杂。下列用例图也只是选择了主要的用例，尽可能地详细绘制，但实际上也有相当多的用例被选择忽略，因而请阅者体谅。

c. 对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法

　　通过比较两个产品的用例图，可以发现出两个产品之间的异同点，首先是相同点：

1. 两个产品用例图的主要用例是一致的，比如两者均包含预订酒店用例，同时该用例的子用例也是相同，有搜索酒店、选择酒店、选择房间和确认订单，还有支付用例等等，因为这些均是在线预订酒店平台所必须具备的基本功能。
2. 上述提到的基本用例的扩展点是类似的，比如两者的选择酒店用例的扩展点都有搜索酒店，就是允许客户在选择酒店时重新搜索酒店；选择酒店时也同样可以选择进行酒店排序。
3. 主要的外部系统是相同的，比如都有基本的网上信用卡支付系统的支持。

　　两者的不同点在于：

1. 新时代的去哪儿预订酒店产品的基本用例更加简单，比如搜索酒店用例，只需要选择目的地、入住和退房时间，并不需要亲自输入目的地或者选择输入留宿天数；在提供预订房间数量的时候，也不需要过多地说明旅客人数和是否是成人或者小孩；同时，在未登录状态下，支付阶段也不需要额外进行添加购物车流程。
2. 两者的某些用例的具体场景并不完全相同，即相同业务的流程不一样，比如旧系统的在选择房间类型时就需确定房间数量，而新系统将这一步骤设置成确定订单的一步；取消订单的流程也从在购物车中取消改成在确认订单过程中就可取消，对用户更加友好。另外，同样用例的注释内容也不完全相同。
3. 新系统的在每个基本用例上都添加了创新用例，比如搜索酒店中新增了境内境外酒店选择、地图搜索、高级搜索、酒店推荐等等，选择酒店新增了筛选条件选择，选择房间类型新增了用户评论、酒店交通和设施介绍，确定订单中新增了打印订单，支付的方式也明显增加。
4. 新系统的外部系统支持更多，同时还有和同类竞争者合作。

　　分析上面两个产品的异同点，可以总结出项目早期，发现创新的思路与方法：

1. 在模仿前辈产品的基本业务的前提上，调整某个业务的操作流程，使得用户使用更加方便，比如把取消订单改为在确定订单的流程中。
2. 对前辈产品的基本业务进行简化，将额外冗余的功能进行筛选删除，使得新产品使用更加简单快捷，比如删除冗余的购物车流程。
3. 扩大或者缩小产品的目标市场范围，比如上述旧系统只是针对国内市场，而新系统则面向国内和国外市场。
4. 在单个业务或者多个业务流程中，考虑添加新的功能或者对相同的扩展点进行修改，比如在相同的对酒店排序扩展点上，旧系统是根据星级、价格、喜好以及字典顺序排列，而新系统则选择是根据星级、价格以及用户评分来排序；又例如在搜索酒店时添加高级搜索或者酒店推荐功能。
5. 考虑寻找更多的外部系统支持，并在这基础上进行扩展。比如在支付上，除了信用卡支付，考虑还有各个支付平台的存在，可以向这些平台寻求合作，为用户提供更多便利。
6. 与竞争对手合作，可以考虑和竞争对手共享数据资源（这里主要指是酒店信息等大数据，并不是指用户私人信息）或者利用前辈产品的渠道进行扩展合作。比如在线预订酒店平台项目早期，可以寻求前辈产品（或者国外同类平台）的合作来利用它的数据库资源，同时自身为前辈产品提供一个推广渠道，这其实是一个互惠共利的思路方法。

d. 请使用Scrum方法，在（任务b）用例图基础上，编制某订旅馆开发的需求（backlog）

　　绘制backlog的方法可见Learning-Scrum-and-XP，下列backlog使用的排序方法是按需求组织的形式进行排序，并非按照重要性排序，同时，下列故事条目只是选取了主要故事以及每个主要故事的一个扩展点作为例子。另外，初始估算是假设开发团队为6人时进行的人-天估算（每个故事安排2人），并且一个迭代周期假设为三个星期工作日（15天）。最后，下列backlog并没有How to demo条目，主要是因为篇幅太大，所以被省去，请阅者体谅。

2. 业务建模

a. 在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。

　　如下所示，即是去哪儿网站中预订酒店平台的找酒店用例的活动图建模。需要注意的是，该活动图只是选取了主要的业务流程。可以知道的是，通过分析流程图中的重要操作能够获取子用例，尤其是需要实现额外功能的操作。比如，该找酒店用例，就有选择酒店范围以及以某种搜索方式搜索酒店这两个操作需要再进行扩展设计的，对比用例图，能够发现这些操作就是找酒店用例的子用例，而且是创新用例。

b. 选择你身边的银行ATM，用活动图描绘取款业务流程。

　　选择建设银行的ATM进行分析，取款业务流程的活动图如下所示：

c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例

　　通过浏览淘宝开放平台提供的API文档，可以发现退款退货业务的多泳道活动图（忽略API接口信息），如下所示：

　　可以发现，客户要完成退货业务，淘宝网需要实现的系统用例（考虑成功退货的主要用例）包括有：生成退款单、同意退货处理、变更退款单状态以及同意退款处理。

3. 用例文本编写

· 在大作业基础上，分析三种用例文本的优点和缺点

Brief（high level）

　　用例描述是一段简洁的概括性文字，通常描述用例主要的参与者以及主要的成功场景。

优点：

　　在早期的需求分析阶段，可以帮助团队成员快速理解用例主题和范围。同时设计方便，编写只需要几分钟时间。

缺点：

　　因为描述比较概括，所以不太利于开发时的功能细节设计与实现。

Casual

　　用例描述使用非正式的段落格式。使用多个段落来较为详细地描述各种场景。

优点：

　　比brief格式更加详细地描述用例场景，同时还提供了更多的场景描述，对开发时的功能实现过程有所帮助。同时这部分的设计对与客户需求交流也有所帮助。

缺点：

　　因为使用非正式的段落格式，所以往往会对功能细节的描述仍有所遗漏，并不能帮助达成开发目标。

Fully

　　详细描述用例的所有场景、场景步骤以及其他相关信息，包括前置条件和成功保证支持。通常在团队识别大多数用例并完成brief用例设计后，在第一次需求分析会议中，选择最重要的、最有价值的那几个用例进行详细编写。

优点：

　　用例描述详尽，很好地帮助开发过程的功能设计与实现，能够引导开发人员解决开发时遇到的功能细节问题，同时也能够帮助达成开发目标。

缺点：

　　描述用例的所有信息所需的编写时间花费很大，对于敏捷开发团队来说，不太适合投入太多的时间。实际上，项目团队也不可能完全描述出用例的所有相关信息。所以，存在的矛盾也非常明显。

前言

　　这部分内容是个人在阅读《硝烟中的Scrum和XP》时的理解和记录，用于帮助个人更好地在学习团队中应用Scrum和XP。

什么是Scrum？

　　Scrum是敏捷开发模式的一种方法论，是一种框架，用于指导帮助需要的团队进行敏捷开发实践。Scrum的实施过程符合敏捷开发的原则和标准，同时还结合了UP（Unified Process，统一开发）过程的特点。因此，良好的Scrum有以下基本要求：

1. 每个迭代要有固定时长（也就是“时间盒”或“timebox”），迭代时长在2~6个星期，不能超过六个星期，也不要少于两个星期。
2. 在每一次迭代的结尾，代码都必须经过QA的测试，能够正常工作。
3. Scrum团队必须要有产品负责人，而且团队都清楚这个人是谁。
4. 产品负责人必须要有产品Backlog，其中包括团队对它进行的估算。
5. 团队必须要有燃尽图，而且要了解他们自己的生产率。
6. 在一个Sprint中，外人不能干涉团队的工作。

　　根据上述基本要求，在Scrum实践过程应该会有如下产物：产品Backlog、Sprint Backlog、对于两个Backlog分别的估算和燃尽图。而这些关于Scrum的术语是本文将主要介绍的内容。

什么是XP？

　　XP（Extreme Programming，缩写为XP）是极限编程的英文简称，也是属于敏捷开发的一种方法论。XP和Scrum均关注“尽可能早地、持续地对有价值软件的交付”，具体来讲，即是在每次迭代结束均有一个可发布的软件版本，每个版本不一定是最完善的，但它是有改进的（系统改进或功能增加），对于客户来说均是有使用价值的。

　　同时，二者也有不同的关注点，XP关注的是实际的编程实践，而Scrum注重的是管理和组织实践。但是，这并不影响两者的组合使用，组合使用Scrum和XP能够为敏捷团队带来累累硕果。而两者的组合会使用到以下方法：结对编程、测试驱动开发（TDD）、增量设计和持续集成等等。这些内容将会在后续再次提到。

Scrum术语

什么是Backlog?

用例、故事

　　在开始具体介绍Backlog的含义之前，必须先要了解下UP过程中的两个关键术语——用例和故事。如果读者已经熟悉这部分的内容，可以直接跳过，也可以选择阅读回顾。

　　用例，即Use case的定义如下：

“Use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.”

　　翻译过来，即用例是参与者使用系统达成目标的一系列成功和失败场景的集合。理解这个概念，需要关注到以下三点：

• 什么是场景？”Scenario is a specific sequence of actions and interactions between actors and the system, it is also called a use case instance.”（场景是参与者与系统进行的一个特定的交互行为序列，也被称为是一个用例实例。）
• 这些场景是描述一个参与者使用系统达成目标的过程。既有成功的场景，也有失败的场景。比如，一个顾客想使用美团外卖APP进行订餐，他先打开美团外卖APP，然后点击“美食”栏目进入外卖商家列表，再选中要订的美食分类，选择其中一个商家进入该商家的菜单列表，选择要叫的美食，加入购物车，接着进入购物车并确认结算，进入结算列表，填写收货地址，使用红包，确认信息后，提交订单，接着选择支付方式，跳转完成支付后，返回商家，等待商家确认订单，商家确认后即完成了订餐过程。这样的一个具体的使用美团外卖APP订餐的过程就是一个成功的订餐场景，它包括了一系列参与者与系统的交互行为。其中参与者是顾客，系统是美团外卖APP，达成的目标是订餐。如果在打开美团外卖APP过程中，手机没有连接网络，APP提示无法连接网络，无法继续进行后续步骤。这个就是一个失败的订餐场景，因为最终无法达到订餐的目标。
• 用例是一系列成功和失败场景的集合。用例是集合，这说明用例其实是一个抽象出来的描述，它概括了这个集合内的成功和失败场景。通常，用例名称就是这个抽象的描述，并清楚说明了用例的目标，比如上述的两个场景（一个成功，一个失败）就是属于订餐这个用例。“订餐”是用例名称，也是用户使用美团外卖APP的一个目标。从另一个角度来讲，用例也可以理解成是系统提供的一种服务或功能，订餐是美团外卖APP提供的一种服务，属于它其中的一个功能。

　　额外地，需要提醒的是，用例中有主场景（也叫基本流）和可选场景（备选流）。主场景即是成功使用系统达成目标的场景，比如上述的第一个场景；而可选场景则是除了主场景外的其他成功或失败场景，比如上述的第二场景就属于可选场景，同时，对于成功订餐场景，如果直接选择历史订单，然后再次订餐的具体过程也是一个可选场景。

　　另外，用例可以分成多个子用例，比如可以将订餐这个用例分成选择商家、选择美食、提交订单、支付这几个子用例，每个子用例也是一个场景集合，包含了各种场景，比如支付就又包含了微信支付和银行卡支付等等过程场景。

　　最后，强调一下，用例是以客户角度使用客户术语描述的，与技术无关，并不关注系统内部怎么实现；用例以及其中的场景描述并不是太具体，比如具体到要按下左下角的购物车按钮进入购物车这样的一个步骤，可以说用例描述是一种UI-Free Style，不用去想界面，只关注用户意图来进行简洁描述。

　　说完用例，接下来就是故事了。简单来讲，故事其实是对用户使用系统来达成目标或期望的需求描述，比如，顾客想使用美团外卖APP来在线订餐，其中“在线订餐”就是顾客使用美团外卖APP的目标需求，“顾客”也当然就是用户。可以发现，故事其实和用例很像。故事中的用户相当于用例中的参与者，故事中用户的目标或期望则相当于用例的名称，比如“订餐”。事实上，两者在理解上可以看成一种偏等价关系。

　　但是，需要了解的是，两者仍有所不同。用例是多个成功和失败场景的集合，而故事则只是用户对使用系统的目标需求的描述。用例更注重参与者使用系统的交互过程，故事则更关注用户想要系统能提供的有价值的功能（目标需求）。相比之下，用例比故事更加详细，用例中主场景、可选场景都可能转换为故事。

　　方便于理解Scrum中的Backlog，其实只需要记住，故事的目标或期望可以理解成用例的名称，故事的描述可以理解成用例主场景的更概括性描述；用例可以分成多个子用例，故事也可以分成多个小故事，子用例和小故事互相对应。

Backlog

backlog从根本上说，就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。　　

　　可以知道，backlog条目罗列了系统产品的故事、需求、特性或者功能，同时它还对这些用户的需求进行了重要性排序。从另一面讲，backlog也表示了系统各用例的重要性程度。

　　以下是截取书中的示例，是一个产品Backlog的示例：

　　一个backlog一般包括有以下一些字段（当然也有其他字段）：

• ID——统一标识符，是一个递增的数字，用于区分各个故事。
• Name——名称，简短的、描述性的故事名，这里也可以使用用例名称来代替。
• Importance——重要性，用来说明这个故事有多重要。它也是使用数字来表述的，但对连续性和大小范围没有要求，数值越大，说明该故事越重要。这些数字可以是0（不重要）、5（不太重要）、10、30、40、100（重要）、150（很重要）等等。通常，将各个故事之间的重要性数值间隔设置得比较大，方便在增加新故事时，能够有合适的重要性数值。比如添加一个重要性在100和150两个故事之间的新故事项，可以设置重要性为120，但不要设置成101，因为100和101两个故事之间可能会再添加新故事，此时只能选择重要性为100.1或者100.5，这样非常不清晰和美观。
• Initial Estimate——初始估算，表示完成该故事所需的工作量，也即是实现该系统功能所需要的时间。这个可以使用故事点/用例点来衡量，即人-天。比如预估2个人完成某项故事所需的时间是4天，那么故事点就是两个数的乘积8。因为是预估，所以故事点的计算依赖经验，常用的估算依据有API接口数、页面数（部件数）和报表数。
• How to demo——如何演示，描述了在sprint结束前的演示过程。这里可以根据对应用例的主场景描述来进行更具体地描述。
• Notes——注释，相关信息、解释说明和对其它资料的引用等等，比如一些分析工具或技术设计上的注释。一般都非常简短。

产品Backlog

　　产品backlog是一个Scrum的核心，因为它描述了这个产品“所有”的故事（或功能、或特性）。但是实际在开发过程中，是不可能完全列出所有故事的。通常情况下，产品backlog会尽可能多地罗列系统产品的故事，并在开发过程中，随着迭代进行，不断地进行调整。比如在Inception阶段（UP过程的第一个阶段），只能够列出一些主要的故事，并进行排序；而在Elaboration阶段（UP过程的第二个阶段），则可以对产品backlog进行补充，使其更加完善。

　　另外，产品backlog通常会有一个额外的字段——Iteration，用于表示估算该故事在哪个迭代内实现完成。

　　比如，下面是个人学习小组在Inception阶段设计的在线短租平台的产品backlog：

　　可以看到，最初的产品backlog的故事并不完善，只是列出了主要的故事，同时重要性级别设计不太合理，也没有进行重要性从大到小的排序。另外，对于初始估算以及迭代安排也不确定，只是简单使用随机数字来代替。而实际上，个人的学习小组项目经验也不足，因此该产品backlog出现许多问题。例如：

1. 用户登录以及注册分别是两个故事，不应该设计在一起，同时，重要性安排也不应该这么高，可以设计更低的重要性。
2. 重要性数值设计间隔太窄，不方便添加新故事。
3. 多个相同重要性的故事，实际上重要性并不应该相同，比如“发布房源信息”应该重要于“修改房源信息”和“查看房源信息”，因为前者的优先级更高，对于这个在线短租平台更重要；同时“支付”故事的重要性则应该稍低些。

Sprint Backlog

　　Sprint backlog是用于一次迭代过程的backlog，在每次Sprint（迭代）开始前进行设计。Sprint backlog是属于产品backlog的一部分，它是从产品backlog中选择故事用于安排在该迭代内完成。通常，一个迭代的Sprint backlog会先选择重要性较高的故事来作为本次迭代的内容（先实现更重要的功能），同时还会根据预估生产率来进行修改。

　　比如，下面就是书中关于从产品backlog中选择设计出Sprint backlog示例：

　　一个迭代的预估生产效率等于在该迭代内可以用的故事点（人-天）乘以投入程度。一个迭代周期以三个星期为例，可用的故事点表示在这三个星期内所有团队成员可以为项目投入的人-天之和，假设团队有两个人（实际最好是4~6个），A能抽出一个星期的时间，那么他的人-天为7，B能抽出50%的时间，那么他的人-天为21/2=10.5，所以可用故事点为7+10.5=17.5。而投入程度则等于上一个迭代中实际完成的故事点之和除以上一个迭代实际工作的故事点。比如，上一个迭代实际工作的故事点为20，而在迭代中完成的故事点之和是10，那么投入程度是10/20=50%。所以这个迭代的预估生产率为17.5 * 50%=8.75。同时，这个投入程度可以再进行修改，例如这个迭代时间内，组员有其他重要的任务课题，能投入的时间和精力也会减小，那么可以适当下降投入程度，成40%，那么预估生产率就变成17.5 * 40% =7。

　　那么在设计Sprint backlog时，选择的故事点之和应该是小于预估生产率的，比如预估生产率（另一个团队）是50，选择的前5个重要性最高的故事的故事点之和为49，而前6个为60，那么这个迭代只安排前5个故事。

　　实际在设计Sprint backlog过程中，可能会出现前几个故事的故事点之和会远小于预估生成率，而多加一个故事点却又会过大，这往往是因为重要性高的故事往往也是较为复杂的故事。此时，为了充分利用迭代时间，可以选择重新设计故事的优先级别，又可以将故事缩小或拆分成小故事（比如将用例分成多个子用例）。在这个迭代中先实现这个故事的一部分，后下一个迭代再实现这个故事的其他部分。

　　另外，在开发初期，尤其是第一个迭代中，往往是不能预估出生产率的，这时就可以先预估个大概数值，然后第一次迭代后，就能进行较准确的估计了。

另外一种排序方式

　　backlog除了按重要性进行排序外，还能够按照需求组织的方式来进行安排，通常就是将一个大故事拆分后的小故事按顺序进行排序，比如下面的例子，将find hotel故事中的子故事find city和find on map等排序到一起，先在开始的迭代中一起实现，有些子故事的重要性并不是最高的：

Sprint

　　Sprint本意是冲刺，在这里，一个Sprint相当于一个迭代。在每次迭代（Sprint）开始前，需要进行一次计划会议，设计Sprint backlog，而在每次结束前，则会进行回顾，关注这次迭代中有什么可以改进的点。在Sprint过程中，需要了解的是燃尽图，根据燃尽图的反馈，在Sprint过程中对Sprint backlog进行修改以使得Sprint最终能够成功且合理的达成目标。　　

燃尽图

　　燃尽图，burn-down chart，用于记录一个Sprint过程的完成情况。燃尽图的横坐标是迭代时间，即一个迭代时间盒是三个星期，那么横坐标则是从三个星期中的第一天日期到最后一天的日期；纵坐标则是剩下的Sprint backlog中记录的需要完成的故事的故事点，最高点即是Sprint backlog中所有故事的故事点之和，比如下图。

　　团队每经过一天，就会在燃尽图的对应日期上画出当前的进度点（今天过后还剩下需要完成的故事点），并和之前的进度点连线。那么在经过一段时间后，燃尽图就会出现上述的示例情况，蓝色表示实际的进度的连线，虚线表示如果进度速率平均时的的进度线。

　　分析燃尽图中进度线的表现可以反映出当前团队的进度情况，并适当地对Sprint backlog进行调整：

1. 团队进度缓慢，需要适当删除backlog的故事项，否则团队不可能在迭代中达成目标：

1. 团队进度太快，为了避免团队后期没有活干，可以适当添加backlog故事条目：

看板

　　看板，相当于任务板，用于记录一个Sprint中需要完成的所有任务以及完成每个任务对应的小组成员。通常可以将Sprint backlog中的故事拆分成任务，并设计在看板上。其中，需要注意任务与子故事的区别在于故事是可以交付的功能，而任务则是不可交付的，但却是完成一个故事所需要的步骤，比如一个扫码订餐APP的一个故事是订餐，它拆分成子故事是扫码、选择美食、提交订单、支付，而拆分成任务是设计UI、前端编程、后端编程、测试用例设计等等。

1. 简单题

· 简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

瀑布模型

优点：

1. 降低软件开发的复杂程度，提高软件开发过程的透明性，提高软件开发过程的可管理性。
2. 推迟软件实现，强调在软件实现前必须进行分析和设计工作。
3. 以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，是产品达到预期的质量要求。

缺点：

1. 强调过程活动的线性顺序。
2. 缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
3. 风险控制能力较弱，失败风险较高。
4. 软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量。
5. 管理人员如果仅仅以文档的完成情况来评估项目完成进度，往往会产生错误的结论。
6. 不适应用户需求的变化。

增量模型

优点：

1. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
2. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
3. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
4. 提高系统的稳定性和可维护性。

缺点：

1. 增量粒度难以选择。
2. 确定所有的基本业务服务比较困难。
3. 缺少一定的需求分析。
4. 模块间的设计不当，后期修改代价会很高。

螺旋模型（含原型方法）

优点：

1. 引入了明确的风险管理。
2. 设计上的灵活性,可以在项目的各个阶段进行变更。
3. 以小的分段来构建大型系统,使成本计算变得简单容易。
4. 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
5. 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

缺点：

1. 风险分析需要相当的成本耗费。
2. 失败的风险分析可能带来更大的风险。
3. 迭代次数不确定，也无法确定产品发布的日期。
4. 不适合大团队合作。
5. 有时客户会对风险分析不买账。

· 简述UP的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？

三大特点

用例/客户驱动 Use Case Driven

用例

• 用例是一系列行为的散文表述。
• 行为是由一个或多个行动者（人或非人）和系统本身执行的。
• 这些行为对一个或更多的行动者来说是有价值的，可以帮助他们达成他们的目标。

用例是站在用户的角度上使用自然语言来表述的，它必须可以被所有利益相关者所理解。

用例驱动意味着开发团队要依据客户需求进行开发，并且在编码和测试阶段也要不断收集和明确客户的需求。

架构为中心 Architecture Centric

软件架构是关于：

• 软件系统的整体结构
• 系统的结构元素（模块）和它们之间的接口
• 这些结构元素之间的合作和它们的预期行为

架构为中心：软件架构提供了其他所有发展演变的中心观点

• 为系统提供了一个蓝图
• 为开发过程提供一个组织框架，注重改善系统的质量来发展完善系统
• 鼓励重复利用有效的结构模块

迭代和增量 Iterative and Evolutionary

迭代和增量式开发允许开发初期的知识准备不完善。

迭代和增量式开发有以下特点：

• 系统架构逐步趋向稳定
• 有效管理需求变化
• 持续集成
• 尽早接触整个系统
• 在线的风险评估

迭代和增量式开发是在固定的迭代周期前提下，每次迭代周期内，依据需求提供系统原型或是对原型进行修改和完善，并在此过程继续明确需求，最终需求趋于稳定，系统呈增量式增长。

在三大特点中，用例驱动体现了用户驱动的开发（依据需求开发），以架构为中心体现了风险驱动的开发（设计一个架构，开发有中心点），迭代和增量式开发则包括了用户驱动和风险驱动的开发（管理需求变化、在线的风险评估）。

· UP四个阶段的划分准则是什么？关键的里程碑是什么？

UP四个阶段

• 初始阶段 Inception：大体上的构想、业务案例、范围和模糊评估。
• 细化阶段 Elaboration：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。
• 构造阶段 Construction：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
• 移交阶段 Transition：进行beta测试和部署。

划分准则

依据UP的软件生命周期时间和每个阶段的关键里程碑来划分。每个阶段结束于一个关键的里程碑，并在每个阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意，可以允许项目进入下一个阶段。

关键的里程碑

初始阶段里程碑：

生命周期里程碑，包括一些重要的文档，如：项目愿景（Vision）、原型用例模型、原始业务风险评估、一个或者多个原型、原始业务案列等。需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。

细化阶段里程碑：

生命周期体系结构里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

构造阶段里程碑：

初始运行能力里程碑（发布）。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运行。

移交阶段里程碑：

产品发布里程碑（最终产品发布）。确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段相重合。

· IT项目管理中，“工期、质量、范围/内容”三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队易于控制的。

　　工期是指完成项目的时间，这在项目计划阶段，签署合同前，项目团队和客户会协商达成一致；质量包括了在项目开始前客户提出的对项目的预期需求以及在项目结束后的验收满意程度；范围/内容则是包括项目开发团队对项目系统所设计使用的框架模块和功能代码等等。

　　前两个元素在合同固定条件下，因有客户的参与，所以项目团队不容易控制；而“范围/内容”则可以根据项目团队本身自己的资金状况、人力资源情况和时间安排，对项目系统进行相应的设计和编码，比如在资金或时间资源不足情况下，项目团队可以通过使用减少或修改项目系统的功能模块但又能满足客户基本需求的方法，在达成项目目标的同时，渡过危机。所以，”范围/内容”是项目团队易于控制的。

· 为什么说，UP为企业按固定节奏生产、固定周期发布软件产品提供了依据？

UP理论依据

在UP中，有以下关于工作流（Workflows） 的理论依据，企业可以按固定节奏生产、固定周期发布软件产品。

UP使用迭代和增量开发

迭代是固定的或时间定量的，系统是增量式增长的。

需求变化趋于稳定

迭代反馈和进化向预期系统的方向发展。需求和设计的不稳定性随着时间逐步下降。

早期迭代

UP进度表

UP科目与阶段

UP描述了科目（discipline） 中的工作活动，例如编写用例。科目是在一个主题域中的一组活动（及相关制品），例如需求分析中的活动。在UP中，制品（artifact） 是对所有工作产品的统称，如代码、Web图形、数据库模式、文本文档、图、模型等。

2. 项目管理使用

· 使用截图工具（png格式输出），展现你团队的任务Kanban，请注意以下要求

• 每个人的任务是明确的。即一周后可以看到具体成果
• 每个人的任务是1-2项
• 至少包含一个团队活动任务

1. 简单题

· 软件工程的定义

Software engineering is “(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software,” and “(2) the study of approaches as in (1).” – IEEE Standard 610.12

　　软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，这就是软件工程。

· 阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。

　　软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

　　构造性成本模型（COCOMO，英文全称为Constructive Cost Model）是由巴里·勃姆（Barry Boehm）提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式，使用从项目历史和现状中的某些特征作为参数来进行计算。

　　COCOMO用3个不同层次的模型来反映不同程度的复杂性，他们分别为：

• 基本模型 （Basic Model）。 是一个静态单变量模型，它用一个以已估算出来的源代码行数 （LOC） 为自变量的函数来计算软件开发工作量。
• 中间模型 （Intermediate Model）。 则在用 LOC 为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
• 详细模型 （Detailed Model）。 包括中间 COCOMO 模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。

　　COCOMO 模型具有估算精确、易于使用的特点。在该模型中使用的基本量有以下几个：

1. DSI（ 源指令条数 ），定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。
2. MM（ 度量单位为人月 ），表示开发工作量。
3. TDEV（ 度量单位为月 ） ，表示开发进度，由工作量决定。

　　COCOMO 模型重点考虑 15 种影响软件工作量的因素，并通过定义乘法因子，从而准确、合理地估算软件的工作量。

　　但是COCOMO也存在一些很严重的缺陷，例如分析时的输入时优先的，不能处理意外的环境变换，得到的数据往往不能直接使用，需要校准，只能得到过去的情况总结，对于将来的情况无法进行校准等。

· 软件生命周期。

　　从时间角度，把整个软件开发周期划分为若干个阶段。

　　划分的原则：各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。受软件规模、性质、种类、开发方法等因素的影响。

　　典型划分GB8567（4个时期7个阶段）：

1. 软件分析时期：问题定义、可行性研究、需求分析
2. 软件设计时期：总体设计、详细设计
3. 编码与测试时期：编码、测试
4. 运行与维护时期

· 按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？

　　按照SWEBOK（Software Engineering Body of Knowledge，软件工程知识体系）的KA（Knowledge Area）划分，本课程关注的知识领域有：

• Software requirements 软件需求分析
• Software design 软件设计
• Software construction 软件构造
• Software engineering management 软件工程管理
• Software engineering process 软件工程过程
• Software engineering models and methods 软件工程模型和方法
• Software quality 软件质量

· 解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。

1. Level 1 - Initial 初始级：无序，过程不可预测，自发生产模式，成功取决于个人努力。管理是反应式的，可控程度低。
2. Level 2 - Managed 可管理级：根据项目来建立特定的过程管理，跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
3. Level 3 - Defined 已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
4. Level 4 - Quantitatively Managed 量化管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
5. Level 5 - Optimizing 优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。关注于软件过程的改进和提升。

· 用自己语言简述 SWEBok 或 CMMI （约200字）

　　CMMI（Capability Maturity Model Integration，能力成熟度模型集成，又称软件能力成熟度集成模型），是一个用于描述企业组织中不同的软件项目开发过程的模型框架，也是一个评价企业软件开发能力的规范标准。利用这个模型框架，软件开发企业可以对自己的软件开发过程进行改进以达成高质量、高效率且成本效益高的软件项目开发。CMMI模型包括有五个级别，分别为初始级、可管理级、已定义级、量化管理级和优化级，从左到右级别依次提高，且软件开发的过程域更加详细和完善。企业组织可以向评估组织申请软件能力成熟度认证和评级。

2. 解释 PSP 各项指标及技能要求

· 阅读《现代软件工程》的 PSP: Personal Software Process 章节。

http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html

· 按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ （期末考核，每人按开发阶段提交这个表）

　　一个软件工程师在接到一个任务之后，首先需要进行计划，估计这个任务需要多少时间；然后是进行开发，按软件开发周期，依次进行需求分析（包括学习新技术）、生成设计文档、进行设计复审（和同事审核设计文档）、为目前的开发制定合适的规范、进行具体设计和具体编码、进行代码复审以及测试（包括自我测试、修改代码和提交修改）；接着是对任务进行报告，记录时间花费和完成测试报告，计算工作量并进行事后总结，最后提出过程改进计划。

　　需要的技能有时间管理的能力（自我管理能力）、软件工程开发过程的模型思想、软件需求分析能力、软件设计思想、软件测试思想、团队沟通合作的能力（表达和交流的能力、与人合作的能力）、把任务按质按量完成的执行力、对具体技术的掌握和动手能力（编码能力）以及学习能力等等。

　　就个人而言，可以通过使用看板软件，比如Tower，先大概估计完成每一步所需天数，制定计划和目标（最好预估更多的时间），然后完成任务就在Tower上记录（包括提前完成和延误），最后在项目完成后，在Tower的个人动态记录上计算每步完成的时间，并进行总结统计。

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。