用例简介

• make reservation用例图

  

顺序图

类图

逻辑设计类图到实际项目框架的映射

PSP 2.1 统计表

PSP2.1表

GIT统计

GIT统计

工作清单

• 贡献度：30%

• 编写和管理项目管理文件
• 维护Dashboard仓库
• 书写需求规格说明书
• UI原型设计
• 管理项目进程

技术博客

个人的项目管理经验博客

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

软件框架(Software Framework)

面向某领域（包括业务领域，如ERP，和计算领域）的、可复用的“半成品”软件，它实现了该领域的共性部分，并提供一系列定义良好的可变点以保证灵活性和可扩展性。可以说，软件框架是领域分析结果的软件化，是领域内最终应用系统的模板。

软件框架至少包含以下组成部分：

• 一系列完成计算的模块，在此称为构件。
• 构件之间的关系与交互机制。
• 一系列可变点（也称热点，Hot-spots，或调整点）
• 可变点的行为调整机制。

开发人员通过软件框架的行为调整机制，将领域中具体应用所特有的软件模块绑定到该软件框架的可变点，从而得到最终应用系统

框架(Framework)

某种应用的半成品，即一组组件，供你选用完成你自己的系统。框架一般是成熟的，不断升级的软件。

区别与联系

• 联系:都是为了提高开发速度，在某一领域类提取出来的公有的部分，便于后续开发
• 区别:软件架构是针对整个领域，而框架一般更细致，具体到开发的某个层次

三层架构模型图

我们项目的三层架构模型图

三层架构模型的便利

• 开发人员可以只关注整个结构中的其中某一层
• 可以很容易的用新的实现来替换原有层次的实现
• 可以降低层与层之间的依赖
• 有利于项目标准化
• 利于各层逻辑的复用
• 项目结构更清楚，分工更明确，有利于后期的维护和升级

VUE与Flux状态管理的异同

Flux状态管理

MVC 中，一个 Model 可以被多个 Views 读取或被多个 Controllers 进行更新。

在大型应用中，一个 Model 可能使多个 Views 去通知 Controllers，并可能触发更多的 Model 更新，这样结果就会变得非常复杂。

Flux 通过强制单向数据流来解决这个额问题。 Flux 使 Views 查询 Stores（而不是 Models），用户交互触发的 Actions 被提交到一个 Dispatcher 中。

当 Actions 被派发后，Stores 将会随之更新自己并且通知 Views 进行修改。这些 Store 当中的修改会进一步促使 Views 查询新的数据。

即在相对独立的组件中，action -> state -> view 的单向数据流能得到保证。

Flux 可能不适用于视图和领域模型合理映射的简单情况，而适用于需要描述多个视图并且不能直接映射到领域模型，或是视图可能需要来自于多个模型和不同种类的聚合数据的系统。

VUE状态管理

Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。 它采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。

应用级的状态由store集中管理 修改状态的唯一方式是commit同步的mutation 异步逻辑放在action里

异同

• 区别: Vuex把action细分成了action和mutation，分别应对异步场景和同步场景，由store自身充当dispatcher（负责注册/分发action/(mutation)。
• 相同： 如果把 action 和 mutation 看作一层（Flux里的action），二者结构完全一致

建模时参考的是Leader15331019-Jupiter小组提供的的鲨鱼记账APP的业务文档

建模如下

用例图

记账业务的活动图

记账用例的领域模型

账单记录对象的状态模型

记账功能的系统顺序图

Reservation/Order状态模型

参考了去哪儿网的APP的预定酒店的流程

淘宝退款的状态模型

领域模型

数据库建模

逻辑模型

物理模型

根据数据库模型导出的MySql脚本

CREATE TABLE `Customer`
(
userID INTEGER NOT NULL,
name VARCHAR(15) NOT NULL,
PRIMARY KEY (userID)
);

CREATE TABLE `Hotel`
(
hotelID INTEGER NOT NULL,
price INTEGER NOT NULL,
name VARCHAR(15),
rank INTEGER NOT NULL,
location VARCHAR(20) NOT NULL,
PRIMARY KEY (hotelID)
);

CREATE TABLE `CreditCard`
(
CardID INTEGER NOT NULL,
limit INTEGER NOT NULL,
PRIMARY KEY (CardID)
);

CREATE TABLE `Order`
(
orderID INTEGER NOT NULL,
hotelID INTEGER NOT NULL,
userID SMALLINT NOT NULL,
startTime DATE NOT NULL,
dueTime TIME NOT NULL,
PRIMARY KEY (orderID)
);

数据库模型和领域模型的异同

• 相同点:都关注用例和用户的参与
• 不同点：领域模型更关注功能，数据库模型更关注数据

项目启动阶段的任务

在项目启动的阶段，需要建立一些文档，包括

• 项目管理文档

  • 项目规划：包含项目的产品说明，以及迭代周期和迭代任务
  • 团队组建：包含团队组员的职务，任务分工以及开发宣言
  • 项目前期调研：包含产品的市场调查，竞争优势分析，以及对同类产品的分析
  • 项目愿景：包含产品的功能消息说明，以及开发产品的方向
  • 产品特性：包含产品的各个方面的特性说明，以及功能的详细说明

    项目管理的方法

    对项目的管理主要通过两个工具实现，包括

• Teambition团队协作管理

  Teambition上包含三个开发计划

  • 总计划：总体的开发流程，由项目经理和产品经理发布和分配任务，对项目的整个流程和进度进行把控。包含有技术准备，需求分析，系统设计，前端开发，后端开发，集成，测试，需求迭代
  • 前端计划：前端分组的开发流程，由前端组组长发布任务，在总计划更新时，及时更新自己组内的任务和分配
  • 后端计划：后端分组的开发流程，由后端组组长发布任务，在总计划更新时，及时更新自己组内的任务和分配

• Github团队文件管理

  在Github上建立了organization，并建立了三个仓库

  • Dashboard:展示项目的开发文档和管理文档，只能由产品经理和项目经理进行更新，其他组员查看文档，获取需要的信息
  • FrontEnd:存放前端的代码和文档
  • BackEnd:存放后端的代码和文档

用例建模

1. 按照Asg_RH文档绘制用例图
2. 选择去哪儿网，再次绘制用例图，其中红色用例为创新用例，橙色为外部系统
3. 创新思路
   • 尽可能的让用户定制自己的商品，比如在搜索和排序时提供更多的类型，让用户根据自己的需求去定制
   • 简化操作，拒绝复杂的流程，比如在订单确认时，可以之间添加和修改订单的信息，而不是返回上一页面去修改
4. 开发需求backlog

   业务建模

5. 绘制找酒店的流程图
6. 绘制ATM取款的流程图
7. 淘宝退款流程

用例书写

• Full

  • 优点：有严格的书写格式规范，考虑全面
  • 缺点：费时，书写起来很复杂

• Causal

  • 优点：说明比brief丰富，容易完成
  • 缺点：需要详细说明时无法使用

• Brief

  • 优点：描述直观，可以直接的理解用例
  • 缺点：缺乏细节，只适合早期开发

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

• 瀑布模型

  • 优点：可以保证整个软件产品较高的质量,保证缺陷能够提前被发现和解决,具备良好的扩展性和可维护性.

• 缺点：发现问题来自上一阶段时难以回溯

• 增量模型

  • 优点：(1)增强客户对系统的信心；(2)降低系统失败风险；(3)提高系统可靠性；(4)提高系统的稳定性和可维护性

• 缺点：(1)增量粒度难以选择；(2)确定所有的基本业务服务比较困难；(3)并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构

• 螺旋模型

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

• 缺点：（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识（2）过多的迭代次数会增加开发成本，延迟提交时间。

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

三大特点

• 迭代式增量开发，体现风险驱动的开发。为了有效地控制风险，统一过程以渐进的方式进行演进，软件生命周期的每个阶段可以划分为多个迭代，每个迭代确定一个内部里程碑
• 用例驱动,体现了用户驱动的开发。用开发过程中的用例和场景来驱动设计、实现和软件的测试，使最终系统更能满足最终用户的需要。
• 以系统架构为中心

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

划分准则：开发生命周期的关键里程碑

• 先启阶段：为系统建立业务案例 (Business Case) 并确定项目的边界。里程碑为生命周期目标
• 精化阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。里程碑为生命周期架构
• 构建阶段：完成所有剩余的技术构件和稳定业务需求功能的开发，并集成为产品，详细测试所有功能。里程碑为初始运作能力
• 移交阶段：确保软件对最终用户是可用的。产品化阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量 调整。里程碑为产品发布

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

因为合同固定后，工期和质量都在合同中有了明确的规定，不能随意更改，软件开发过程中遇到问题时，项目团队可以和与客户商议稍微调整项目的范围/内容。

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

• 固定节奏：UP的软件生命周期从时间上分为四个阶段，每个阶段包括一个主要的里程碑。在各个阶段结束时，执行评估阶段目标是否满足以决定是否进入下一个阶段。
• 固定周期发布软件产品：UP是风险驱动的，为了有效地控制风险，UP以渐进的方式进行演进，首先解决高风险的问题，这主要是通过迭代来实现。在软件生命周期中，每个阶段可以划分为多个迭代，每个迭代确定一个里程碑

项目任务

• 团队成员

• 总体计划
• 前端开发计划
• 后端开发计划
• 团队活动

1.软件工程的定义

在软件的开发和维护中，对系统的，有组织的，可度量的方法的研究

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

软件危机是指，在早期的软件开发中出现的一系列问题，包括

• 软件开发成本和进度不受控制
• 难以维护，调试和更改
• 用户需求满足不全

---

COCOMO模型，即Constructive Cost Model，结构式成本模型 COCOMO模型分为基本、中间、详细三个层次 分别用于软件开发的三个不同阶段。

• 基本COCOMO模型 用于系统开发的初期，估算整个系统的工作量(包括软件维护)和软件开发所需要的时间。
• 中间COCOMO模型 用于估算各个子系统的工作量和开发时间。
• 详细COCOMO模型 用于估算独立的软部件，如子系统内部的各个模块。

3.软件生命周期。

软件生命周期(Systems Development Life Cycle，SDLC)是软件的产生直到报废的生命周期，是一种按时间分程的思想方法周期包括有

• 问题定义
• 可行性分析
• 需求分析
• 总体设计
• 详细设计
• 编码，调试和测试
• 验收与运行、维护

每个阶段从时间上是相对独立的

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

SWEBOK,即Software Engineering Body of Knowledge，软件工程知识体系 是通用的软件工程指导的国际化标准 本课程主要关注的知识领域包括

• Software requirements 软件需求
• Software design 软件设计
• Software construction 软件架构
• Software quality 软件质量

5.解释 CMMI 的五个级别。

• Level 1 - Initial：无序级，自发生产模式。
• Level 2 - Managed：已管理级，项目过程制度化。
• Level 3 - Defined：已定义级，组织过程制度化。
• Level 4 - Quantitatively Managed：量化管理级，度量并基于统计去控制过程。
• Level 5 - Optimizing：优化级，过程持续改进。

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

软件工程知识体系（swebok）是国际标准iso 的，详细说明了普遍接受的软件工程知识体系的技术指南。涉及到软件工程的各个方面，包括有

• 软件需求
• 软件设计
• 软件构造
• 软件测试
• 软件维护
• 软件配置管理
• 软件工程过程
• 软件过程工具与方法
• 软件质量
• 相关科学知识

SWEBOK的作用是指导在软件工程方面遇到的问题，可以根据问题快速定位到相关知识领域，然后查找各种方法、标准。

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

PSP指标要求

• 项目/任务大小：项目的大小, 一般用代码行数 (Line Of Code, LOC) 来表示；也可以用功能点 (function point)
• 花费时间：完成项目用时
• 代码质量：使用代码中缺陷的数量来除以项目的大小来衡量
• 按时交付：稳定，一致的交付时间

8.按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？

接到任务后： 计划

• 估计这个任务需要多少时间

开发

• 分析需求
• 生成设计文档
• 设计复审 (和同事审核设计文档)
• 代码规范 (为目前的开发制定合适的规范)
• 具体设计
• 具体编码
• 代码复审
• 测试（包括自我测试，修改代码，提交修改）

记录时间花费 测试报告 计算工作量 事后总结 提出过程改进计划

所需技能：

• 规划能力
• 理解能力
• 书面表达能力
• 编码测试能力
• 总结能力
• 执行力

统计方法：

• 将项目明确划分阶段，确定每个阶段的工作任务和结束指标
• 每次完成阶段的工作任务后，利用代码统计工具对完成的代码进行统计
• 项目完成后，对记录的结果进行分析。