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

1.简短的课程学习自我总结（400字以内）

• 请不用讲述与分析、设计、开发、管理无关的话题
• 可以包括对同学帮助的致谢（同学姓名请用 github 昵称表示）

• 0 ~ 400字，即没有这段也没关系

  在这门课程体验了敏捷开发的大致流程，本人在团队中的角色是产品经理，主要负责需求分析与部分设计。从用例建模到业务建模，领域建模，数据库建模，状态建模，架构建模以及最后的用例详细设计，大致明白了每个环节之间的联系，和分析设计对编程的影响。 相较之前的编程经验，算是对一个项目的开发过程有了系统化的了解。学会了画很多图，从用例图，活动图，领域模型，状态图到系统顺序图，以及细化迭代的包图，交互图，类图，真的获益匪浅。当然到最后也发现自己只是学了皮毛，画出来的东西很难经受实践的考验，还需要继续深入学习。

2.PSP 2.1 统计表

3.个人分支的 GIT 统计报告（不需要解释原因）- 仅需要提交截图

我们小组共有四个仓库：两个前端，一个后端，以及一个Dashboard，如下图：

本人角色为产品经理，只在Dashboard仓库有过提交贡献：

4.自认为最得意/或有价值/或有苦劳的工作清单，含简短说明（一句话）

完成包括用例文档和用例图的所有用例，项目愿景，领域模型，部分顺序图和类图。

5.个人的技术类、项目管理类博客清单（只需要名称与 url ）

• Git上传文件至项目的远程仓库
• 用例建模之用例图
• 状态建模

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

1. 使用 ECB 实现 make reservation 用例的详细设计（用例简介，顺序图，类图）

• 用例简介

完成酒店的搜索后开始选择酒店，可通过对酒店进行排序来挑选酒店，确定酒店后选择房间类型，选择完毕后确认预定请求信息，完成预定。

• 顺序图

• 类图

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

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

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

• 架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统所籍接口的选择。软件架构是把系统分解为一些部件，描述这些部件的职责及它们之间的协作行为。
• 框架是特定语言和技术的架构应用解决方案，例如 Java Spring web framework，它包含了 Java 开发 web 应用的各种业务场景的具体解决方案。 框架是具体语言和技术相关的，是一种或多种架构的组合的实现。框架是集成了你的代码和多种第三方解决方案的工具，让你聚焦业务逻辑代码而不是技术实现。
• 他们之间的联系可以概括为：架构是框架的设计方法，框架是架构的组合实现。

2. 以你的项目为案例

2.1 绘制三层架构模型图，细致到分区

三层模型：表示层、业务层、持久化层

• 表示层：一般按用户角色划分分区，例：用户点餐子系统、餐厅管理子系统、餐厅厨房管理子系统、运维服务子系统等
• 业务层: 一般按业务功能服务划分分区，例：用户管理模块、菜品管理模块、订单管理模块、配餐管理模块、餐厅服务行为管理、餐厅管理等
• 持久化层：按核心交易实体管理（资源管理），例：用户、菜品、订单等等的CRUD

2.2 结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

• 软件结构是业界长期最佳实践的总结,对于程序员来说，在开发时选择优于创造，三层架构是个良好的选项
• 理解结构优于硬搬框架，三层架构能帮助开发者更好地理解程序结构，理解系统 big picture
• 三层架构在一定程度上能保证模块的内聚性和耦合性，从而对产品结构的合理性有一定保障，在开发时为程序员带来了产品方面的便利

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

Flux，状态集管理框架，专门用来构建前端框架结构的框架，便于维护。它分为四层：view视图层，action层，dispatcher派发层，store仓库层。

• 同： Vuex是专门为Vue设计的状态管理框架,同样基于Flux架构,都便于维护,保证安全。

• 异：

  • Flux数据流的顺序是: view——>action——>dispatcher——>store返回——>dispatcher——>view(接收的方法：register（）)

    View发起Action->Action传递到Dispatcher->Dispatcher将通知Store->Store的状态改变通知View进行改变

  • Vuex数据流的顺序是: vueComnent——》(dispatch)Action——》（commit）——》Mutations——》（mutate）State——》（render）VueComponent

    View调用store.commit提交对应的请求到Store中对应的mutation函数->store改变生成新的state(vue检测到数据变化自动渲染)

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

• 建模文档：饿了么APP

建模要求

task1

用例建模，画出用例图。

task2

选择一项业务或用例，给出活动图。

• 下订单的活动图

task3

识别实体和中介实体，按用例构建领域模型。

task4

对在线订外卖业务对象进行状态建模。

task5

给出一个场景的系统顺序图，如下订单，取消订单等。

• 支付订单的系统顺序图

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

1）使用 UML State Model

建模对象： 参考 Asg_RH 文档， 对 Reservation/Order 对象建模。 建模要求： 参考练习不能提供足够信息帮助你对订单对象建模，请参考现在 定旅馆的旅游网站，尽可能分析围绕订单发生的各种情况，直到订单通过销售事件（柜台销售）结束订单。

旅店的订单状态建模：

• 状态集合 S= { 待填写，待提交，等待酒店确认，预定完成待支付，预定取消，等待入住，订单完成}
• 常见事件 E = { 网上预定，填写订单，提交订单，酒店确认，取消预定，支付，支付超时，取消订单，查询订单，柜台销售，入住 }

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

淘宝退货业务对象状态建模：

• 状态集合 S= { 申请待处理，申请被拒绝，待审核，退货地址待确认，待退货，待收货，待退款，退款成功}
• 常见事件 E = {买家申请退货，商家同意退货，商家不同意退货，买家举证淘宝客服介入，审核通过，审核不通过，商家确认收货地址，买家退货，商家确认收货，银行受理，买家收款 }

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

1、 领域建模

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

按 Task2 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸 说明：请不要受 PCMEF 层次结构影响。你需要识别实体（E）和 中介实体（M，也称状态实体）

• 在单页面应用（如 vue）中，E一般与数据库构建有关，M 一般与store模式有关
• 在 java web 应用中，E 一般与数据库构建有关， M 一般与 session 有关

Task2: Develop a class model for business objects and business logic in “Reserve Hotel”. The class model should show attributes in classes and relationships between classes.

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

• 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型）
• 建模工具 PowerDesigner（简称PD） 或开源工具 OpenSystemArchitect
• 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html
• 导出 Mysql 物理数据库的脚本

系统的 E-R 模型

Mysql 物理数据库的脚本

/*==============================================================*/
/* DBMS name:      Microsoft SQL Server 2012                    */
/* Created on:     2018/4/29 20:44:17                           */
/*==============================================================*/


if exists (select 1
   from sys.sysreferences r join sys.sysobjects o on (o.id = r.constid and o.type = 'F')
   where r.fkeyid = object_id('Hotel') and o.name = 'FK_HOTEL_RELATIONS_LOCATION')
alter table Hotel
   drop constraint FK_HOTEL_RELATIONS_LOCATION
go

if exists (select 1
   from sys.sysreferences r join sys.sysobjects o on (o.id = r.constid and o.type = 'F')
   where r.fkeyid = object_id('RequestSpecification') and o.name = 'FK_REQUESTS_RELATIONS_RESERVAT')
alter table RequestSpecification
   drop constraint FK_REQUESTS_RELATIONS_RESERVAT
go

if exists (select 1
   from sys.sysreferences r join sys.sysobjects o on (o.id = r.constid and o.type = 'F')
   where r.fkeyid = object_id('ReservationRequest') and o.name = 'FK_RESERVAT_HAS_HOTEL')
alter table ReservationRequest
   drop constraint FK_RESERVAT_HAS_HOTEL
go

if exists (select 1
   from sys.sysreferences r join sys.sysobjects o on (o.id = r.constid and o.type = 'F')
   where r.fkeyid = object_id('ReservationRequest') and o.name = 'FK_RESERVAT_LOGGED_CUSTOMER')
alter table ReservationRequest
   drop constraint FK_RESERVAT_LOGGED_CUSTOMER
go

if exists (select 1
   from sys.sysreferences r join sys.sysobjects o on (o.id = r.constid and o.type = 'F')
   where r.fkeyid = object_id('Room') and o.name = 'FK_ROOM_RELATIONS_HOTEL')
alter table Room
   drop constraint FK_ROOM_RELATIONS_HOTEL
go

if exists (select 1
            from  sysobjects
           where  id = object_id('Customer')
            and   type = 'U')
   drop table Customer
go

if exists (select 1
            from  sysindexes
           where  id    = object_id('Hotel')
            and   name  = 'Relationship_1_FK'
            and   indid > 0
            and   indid < 255)
   drop index Hotel.Relationship_1_FK
go

if exists (select 1
            from  sysobjects
           where  id = object_id('Hotel')
            and   type = 'U')
   drop table Hotel
go

if exists (select 1
            from  sysobjects
           where  id = object_id('Location')
            and   type = 'U')
   drop table Location
go

if exists (select 1
            from  sysindexes
           where  id    = object_id('RequestSpecification')
            and   name  = 'Relationship_4_FK'
            and   indid > 0
            and   indid < 255)
   drop index RequestSpecification.Relationship_4_FK
go

if exists (select 1
            from  sysobjects
           where  id = object_id('RequestSpecification')
            and   type = 'U')
   drop table RequestSpecification
go

if exists (select 1
            from  sysindexes
           where  id    = object_id('ReservationRequest')
            and   name  = 'logged_FK'
            and   indid > 0
            and   indid < 255)
   drop index ReservationRequest.logged_FK
go

if exists (select 1
            from  sysindexes
           where  id    = object_id('ReservationRequest')
            and   name  = 'has_FK'
            and   indid > 0
            and   indid < 255)
   drop index ReservationRequest.has_FK
go

if exists (select 1
            from  sysobjects
           where  id = object_id('ReservationRequest')
            and   type = 'U')
   drop table ReservationRequest
go

if exists (select 1
            from  sysindexes
           where  id    = object_id('Room')
            and   name  = 'Relationship_5_FK'
            and   indid > 0
            and   indid < 255)
   drop index Room.Relationship_5_FK
go

if exists (select 1
            from  sysobjects
           where  id = object_id('Room')
            and   type = 'U')
   drop table Room
go

/*==============================================================*/
/* Table: Customer                                              */
/*==============================================================*/
create table Customer (
   Customer_Name        char(256)            null,
   Email                char(256)            not null,
   constraint PK_CUSTOMER primary key nonclustered (Email)
)
go

/*==============================================================*/
/* Table: Hotel                                                 */
/*==============================================================*/
create table Hotel (
   Hotel_ID             int                  not null,
   Location_Code        int                  null,
   Hotel_Name           char(256)            null,
   star                 int                  null,
   Hotel_Address        char(256)            null,
   constraint PK_HOTEL primary key nonclustered (Hotel_ID)
)
go

/*==============================================================*/
/* Index: Relationship_1_FK                                     */
/*==============================================================*/
create index Relationship_1_FK on Hotel (
Location_Code ASC
)
go

/*==============================================================*/
/* Table: Location                                              */
/*==============================================================*/
create table Location (
   Location_Code        int                  not null,
   Location_Name        char(256)            null,
   Hot                  float                null,
   constraint PK_LOCATION primary key nonclustered (Location_Code)
)
go

/*==============================================================*/
/* Table: RequestSpecification                                  */
/*==============================================================*/
create table RequestSpecification (
   Request_ID           int                  null,
   NumOfAdult           int                  null,
   NumOfChildren        int                  null,
   Room_Number          int                  null
)
go

/*==============================================================*/
/* Index: Relationship_4_FK                                     */
/*==============================================================*/
create index Relationship_4_FK on RequestSpecification (
Request_ID ASC
)
go

/*==============================================================*/
/* Table: ReservationRequest                                    */
/*==============================================================*/
create table ReservationRequest (
   Request_ID           int                  not null,
   Hotel_ID             int                  null,
   Email                char(256)            null,
   CheckInDate          datetime             null,
   CheckOutDate         datetime             null,
   constraint PK_RESERVATIONREQUEST primary key nonclustered (Request_ID)
)
go

/*==============================================================*/
/* Index: has_FK                                                */
/*==============================================================*/
create index has_FK on ReservationRequest (
Hotel_ID ASC
)
go

/*==============================================================*/
/* Index: logged_FK                                             */
/*==============================================================*/
create index logged_FK on ReservationRequest (
Email ASC
)
go

/*==============================================================*/
/* Table: Room                                                  */
/*==============================================================*/
create table Room (
   Date                 datetime             null,
   IsAvailable          bit                  null,
   Room_Type            char(256)            null,
   Room_Price           float                null,
   Room_ID              int                  not null,
   Hotel_ID             int                  null,
   constraint PK_ROOM primary key nonclustered (Room_ID)
)
go

/*==============================================================*/
/* Index: Relationship_5_FK                                     */
/*==============================================================*/
create index Relationship_5_FK on Room (
Hotel_ID ASC
)
go

alter table Hotel
   add constraint FK_HOTEL_RELATIONS_LOCATION foreign key (Location_Code)
      references Location (Location_Code)
go

alter table RequestSpecification
   add constraint FK_REQUESTS_RELATIONS_RESERVAT foreign key (Request_ID)
      references ReservationRequest (Request_ID)
go

alter table ReservationRequest
   add constraint FK_RESERVAT_HAS_HOTEL foreign key (Hotel_ID)
      references Hotel (Hotel_ID)
go

alter table ReservationRequest
   add constraint FK_RESERVAT_LOGGED_CUSTOMER foreign key (Email)
      references Customer (Email)
go

alter table Room
   add constraint FK_ROOM_RELATIONS_HOTEL foreign key (Hotel_ID)
      references Hotel (Hotel_ID)
go

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

  领域模型是对领域内的概念类或现实世界的对象的一种抽象的可视化表示。又称为概念模型，它主要关注问题域本身，挖掘问题域中核心的领域概念，并建立领域概念之间的关系。

  • 领域模型是在了解了用户的需求，用户的业务领域工作情况以后，分析和总结出来的用以描述用户业务需求的一些概念的东西，和软件开发没有任何关系。
  • 逻辑模型是将领域模型具体化。要实现概念模型所描述的东西，需要哪些具体的功能和处理哪些具体的信息，属于需求分析的细化阶段。系统需要建立几个数据表，系统要包括几个功能，均属于建立逻辑模型。
  • 这两个过程，就是实现一个软件系统的两个关键的步骤，是一个从抽象到具体的一个不断细化完善的分析，设计和开发的过程。

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

1.用例建模

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

b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：

• 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例
• 尽可能识别外部系统，并用色彩标注新的外部系统和服务

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

原则为一切以用户为中心，明确用户群体，从用户需求的出发考虑问题，把困难留给自己，把简单留给用户。项目早期首先要根据“二八定律”抓住功能重点，然后达成快速上线的目标，再根据用户反馈来顺应需求的动态变化。本人总结的具体思路和方法大致如下：

1. 考虑新技术，能否应用新型技术来提高用户使用产品的效率，从而为用户带来更好的操作体验？如新增基于地理信息服务的地图搜索功能。
2. 考虑业务逻辑，现有的流程和方法是否能够进一步改善？例如：之前提供了搜寻结果排序的功能，但是如果增加筛选的功能，可以使用户更快地获得自己想要的信息。
3. 考虑拓展模块，用户是否有进一步的需求？是否应该为用户提供更多的信息，帮助用户更好的达成自己的目标？如添加评论区，不但让用户更多地获取了他们想了解的信息，也增强了用户的参与度。

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

• 去哪儿预定酒店模块的BACKLOG

2、业务建模

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

利用流程图发现子用例的方法： 因为子用例与父用例的关系一般用include和extend来描述，所以我们可以通过寻找父用例之间的共同包含动作来发现子用例，也可以通过寻找父用例的扩展点来发现子用例。利用流程图对业务活动的流程进行建模，可以帮助我们清晰快速地发现基用例的共同点和扩展点，从而发现子用例。

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

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

客户要完成退货业务，在淘宝网上需要实现的系统用例：

• 处理退货申请
• 审核凭证
• 处理退款

3、用例文本编写

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

1. 摘要 优点：编写所需时间很短，在项目的早期需求分析过程中，可快速帮助了解主题和范围。 缺点：只包含主成功场景，无法说明用例的详细业务过程，不利于深入分析需求。

2. 非正式 优点：在摘要的基础上添加了交替场景，编写所需时间短，在早期需求分析过程中，可快速帮助了解主题和范围。 缺点：不够详细全面，缺少足够的用例细节。

3. 详述 优点：结构化，展示了更多细节，更为深入，用于详细编写具有重要架构意义和高价值的用例，有利于进行详细的需求分析。 缺点：编写所需时间很长，需要考虑各种繁琐的细节。

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

1

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

• 瀑布模型 优点：定义了软件开发基本流程与活动，降低软件开发的复杂程度。 缺点：1. 依赖问题。前面需求模糊，后面工作容易产生问题；2. 容错问题。缺乏灵活性，风险控制能力较弱，在后期发现需求问题，回溯工作量令人难以接受；3.资源调配问题。知识技能需求不同，人员数量要求不同。项目可控性低，可能导致项目延期。

• 增量模型 优点：1. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展; 2.以组件为单位进行开发降低了软件开发的风险，一个开发周期内的错误不会影响到整个软件系统; 3.开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。 缺点：要求待开发的软件系统可以被模块化。没有完整的技术框架，预先设计好接口，粒度难以选择，各部分存在融合问题。

• 螺旋模型（含原型方法） 优点：发现问题早，成本低。设计上具有灵活性,可以在项目的各个阶段进行变更。以小的分段来构建大型系统,成本计算简单。客户始终参与每个阶段的开发,保证了项目不偏离正确方向。随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。 缺点：不适合大团队，具体迭代次数难以确定，无法确定发布日期。很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

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

UP 的三大特点： 1）迭代和增量的（Iterative and incremental）：迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，系统增量式地发展完善，使之最终成为适当的系统。 2）以架构为中心的（Architecture-centric）：统一过程强调架构是项目团队努力塑造系统的核心所在。由于没有单个模型足以覆盖系统的所有方面，统一过程支持多种架构模型和视图。 3）风险集中的（Risk-focused）：统一过程要求项目团队专注于解决项目生命周期早期最关键的风险。每个迭代的可交付成果，特别是在精化阶段，必须选择，以确保最大的风险首先得到解决。 风险集中的和以架构为中心迭代开发的实践体现了风险驱动的开发，意味着早期迭代要致力于核心架构的构造，测试和稳定，没有稳固的架构会带来高风险。而根据用户需求和反馈进行迭代和增量式的系统完善则体现了用户驱动的开发。

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

UP项目将其工作和迭代组织为四个主要阶段： 1）初始（Inception）：大体上的构想，业务案例，范围和模糊评估。 2）细化（Elaboration）：已精化的构想，核心架构的迭代实现，高风险的解决，确定大多数需求和范围以及进行更为实际的评估。 3）构造（Construction）：对遗留下来的风险较低的和比较简单的元素进行迭代实现，准备部署。 4）移交（Transition）：进行beta测试和部署。 关键的里程碑在“细化”阶段之后，“构造”阶段之前，是迭代的结束点，此时有重要决策或评估产生，应提交一个包括成本和进度估算的准确计划。

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

虽然项目的工期、质量、范围/内容，都会在合同中明确给出，但是“工期”可能会受到各种原因以及突发情况的影响，如：前期分析和设计出现重大失误，负责开发的队员辞职罢工等，这些因素都是难以人为控制的。而“质量”本身就是一个难以捉摸的东西，它涉及考查很多方面，并且在项目完成之前是难以预测的，也无法进行实际评估，因此也是团队难以掌控的。相对来说，“范围/内容”一旦在合同上确切给出，那么控制权就完全移交给了项目团队，从设计到实现的过程中，根据明确的项目内容要求，控制项目范围是件很轻松的事。

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

UP是一种构造面向对象系统的迭代软件开发过程，其时间定量迭代和进化式开发的特点，为企业按固定节奏生产、固定周期发布软件产品提供了依据。迭代开发是UP的关键实践，迭代生命周期中开发被组织成一系列固定的短期小项目，在多次迭代中系统增量式发展和完善。因为每次迭代都产生可执行的但不完整的系统，输出最终系统的产品子集，所以UP为企业按固定节奏生产提供了依据。而多次迭代之后的系统能合格地用于产品部署，则为固定周期发布软件产品提供了依据。

2、项目管理使用

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

• 每个人的任务是明确的。即一周后可以看到具体成果。
• 每个人的任务是1-2项。
• 至少包含一个团队活动任务。 本小组第一次迭代的任务Kanban如下：

Some Suggestions for Beginners

1.Read Github Guides

Github Guides is the official Hello World of Github, it contains some very basic knowledge and operations of Github and is easy understanding. By reading Github Guides you can learn how to:

• Create and use a repository
• Start and manage a new branch
• Make changes to a file and push them to GitHub as commits
• Open and merge a pull request

2.Using Github Desktop

In the past, it’s easy to download source code from Github while submitting code to Github can be troublesome. Fortunately，Since the advent of GitHub Desktop, everything becomes easy and convenient. By using Github Desktop, you can submit your own project without gitShell. After all, GIT instructions is not that friendly for rookies. The page of Github Desktop is simple and easy to handle.

3.Introductory learning material

• GotGithub It’s comprehensive and detailed.

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

1

1.1软件工程的定义。

（1）将系统化的，规范化的，可度量的方法应用于软件的开发，运行和维护的过程，也就是将工程化应用于软件中。（2）对（1）所述方法的研究。软件工程是指导计算机软件开发和维护的工程学科。

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

Software Crisis 六十年代以来，随着计算机应用需求的驱动，系统软件和应用软件发展迅速，如操作系统，编译系统和大型应用软件等。由于软件生产的复杂性和高成本，大型软件的生产出现了很大的困难，即出现软件危机。主要表现为：软件开发进度难以预测，软件开发成本难以控制，用户对产品功能难以满足，软件产品质量无法保证，软件产品难以维护，软件缺少适当的文件资料。

COCOMO 模型 Constructive Cost Model构造性成本模型，一种精确的，易于使用的，基于模型的成本估算方法，从本质上说是一种参数化的软件规模估算方法。 在该模型中使用的基本量有以下几个： （1）DSI（ 源指令条数 ） ，定义为代码行数，包括除注释行以外的全部代码。 （2）MM（ 度量单位为人月 ） 表示开发工作量。 （3）TDEV（ 度量单位为月 ） 表示开发进度，由工作量决定。 （4）COCOMO 模型重点考虑 15 种影响软件工作量的因素，并通过定义乘法因子，从而准确、合理地估算软件的工作量。
COCOMO用3个不同层次的模型来反映不同程度的复杂性，他们分别为： 基本模型 （Basic Model）。是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的函数来计算软件开发工作量。 中间模型 （Intermediate Model）。则在用 LOC 为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。 详细模型 （Detailed Model）包括中间 COCOMO 模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。 通过基础COCOMO的计算可以得出每个开发者需要投入的时间，整个项目的开发时间以及需要的人数,所需要的输入是软件的大小（以代码的行数（千行）为单位，记做SLOC）。

1.3软件生命周期。

软件生命周期是软件的产生直到报废或停止使用的生命周期，从时间角度，把整个周期划分为若干个阶段。划分的原则：各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。受软件规模，性质，种类，开发方法等因素的影响。软件生命周期典型划分：GB8567，4个时期7个阶段。 （1）软件分析时期：问题定义，可行性研究，需求分析； （2）软件设计时期：总体设计，详细设计； （3）编码与测试时期：编码，测试； （4）运行与维护时期。

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

根据已发布的SWEBOK版本3所定义的KA划分，由于本课程培养具有客户思维的软件工程设计师，因此本课程关注以下KA：软件需求，软件设计，软件构建，软件工程管理，软件工程过程，软件工程模型和方法。

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

• Level 1 - Initial：过程无序，自发生产模式;
• Level 2 - Managed：响应式的，具有项目特征的软件开发过程；
• Level 3 - Defined：具有组织特色的，积极主动的软件开发过程；
• Level 4 - Quantitatively Managed：定量的，可控的开发过程；
• Level 5 - Optimizing：注重开发过程的优化和创新；

1.6用自己语言简述 SWEBOK 或 CMMI（约200字）。

CMMI（能力成熟度模型集成）描述了各个进程的一些关键元素，描述了那些成功实施了过程改进的组织的特性，提供了一个可供公众使用的准则。CMMI具有五个等级：初始级，管理级，定义级，量化管理级，以及优化级，可以说是一个从无序的，不成熟的活动向成熟的，规范的过程进化的指南。 CMMI的每个等级都由相应的过程域PA组成，这些过程域共同形成一种软件过程能力。CMMI是一个评估当前实践的标准，不局限于单一学科，用于组织的评估而不是认证，一个组织能通过CMMI来进行评估，从而有针对性地完善自己的开发过程。

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

• 阅读《现代软件工程》的 PSP: Personal Software Process 章节。
• 按表格 PSP 2.1，了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ （期末考核，每人按开发阶段提交这个表）

  1.大块估算：先针对该任务的大过程大方向先进行一个占比的大致估算，如PSP中的计划，开发，报告这三大块； 2.过程细分：列出该过程的具体任务，根据每个细分任务的大致时间 来估计该过程所需时间； 3.类比法：如做过类似的项目，类比以前的经验估计此次任务的时间； 4.考虑风险：考虑这个项目的风险，列出可能会遇到的问题，在某些过程增加缓冲时间和缓冲任务； 5.平均法：通过最佳和最差方案来估计时间； 6.其他因素：对这个任务的了解程度，开发人员的技术水平和严谨程度，对这个程序的擅长程度，这段时间的个人状态。