• 联系文档编写
  • 选择一个你喜欢的移动APP或其中某业务
  • 参考Asg_RH文档格式编写软件描述
  • 文档要包含一个业务的完整过程
• 建模要求包括(用例图、XX业务或用例的活动图、XX领域模型、XX对象的状态图、XX场景的系统顺序图与操作协议)
• 建模这答案：
  • 收集及按摩着答案URL
  • 建模者不能是本团队成员(至少有一个答案)
  • 给建模者给出评价与建议

建模案例：Keep训练指导功能业务文档

1. 用例图
   
2. XX业务或用例的活动图
   
3. 领域模型
   
4. 订单对象的状态图
   
5. XX场景的系统顺序图与操作协议
   

• a. 阅读Asg_RH文档，按用例构建lingua模型。
  • 按Task2要求，请使用工具UMLet，截图格式务必是png并控制尺寸
  • 说明：请不要受PCMEF层次结构影响。你需要识别实体（E）和中介实体（M，也称为状态实体）
    • 再单页面应用（如vue）中，E一般与数据库构建有关，M一般与store模式有关
    • 再java web应用中，E一般与数据库构建有关，M一般与session有关
  • 
• b. 数据库建模（E-R模型）
  • 按Task3要求，给出系统的E-R模型（数据逻辑模型）
  • 建模工具PowerDesigner（简称PD）或开源工具OpenSystemArchitect
    
  • 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html
  • 导出Mysql物理数据库的脚本

drop table if exists Cunstomer;
drop table if exists CreditCard;
drop table if exists Hotel;
drop table if exists Room;

create table CreditCard
(
   cardID                longtext not null,
   password              char(20),
   constraint PK_CREDITCARD primary key (cardID)
);

create table Cunstomer
(
   account                longtext,
   fullname               longtext,
   email                  longtext,
   hotelID                longtext,
   constraint PK_CUNSTOMER primary key (account)
);

create table Hotel
(
   hotelID                int               not null
   name                   longtext          not null,
   location               int               not null
   star                   int               not null
   constraint PK_HOTEL primary key (room)
);

create table Room
(
    roomID                int               not null
    type                  longtext          not null
    price                 float             not null
    isAvailable           boolean           not null
    constraint PK_ROOM primary key(roomID)
);

alter table Customer add constraint FK_REFERENCE1 foreign key (hotelID)
      references hotel (hotelID) on delete restrict on update restrict;

alter table creditCard add constraint FK_REFERENCE2 foreign key (account)
      references Customer (account) on delete restrict on update restrict;

alter table room add constraint FK_REFERENCE3 foreign key (hotelID)
      references hotel (hotelID) on delete restrict on update restrict;

alter table room add constraint FK_REFERENCE4 foreign key (account)
      references Customer (account) on delete restrict on delete restrict;

- 简单叙说数据库逻辑模型与领域模型的异同:
    - 相同点：抽象概念，将需求抽象为可视化的概念关系
    - 不同点：领域模型是对领域内概念类或现实世界对象的一种抽象的可视化表示，主要关注现实世界行为、对象和各种概念，挖掘问题域中核心的概念，并建立领域概念之间的关系；而逻辑模型则是领域模型的进一步细化，需要摒弃与具体实现无关的概念以及将需要的概念进一步细化成数据库、类对象等细节

• a.阅读Asg_RH文档，绘制用例图。按照Task1要求，请使用工具UMLet，截图格式务必是png并控制尺寸
  
• b.选择你熟悉的定旅馆在线服务系统（或移动App），如如绘制用例图。并满足以下要求：
  • 对比Asg_RH用例图，请用色彩标注出创新用例或子用例
    
  • 尽可能识别外部系统，并用色彩标注新的外部系统和服务 携程网站上的酒店预订流程如下
    
    
    
    
    

• c.对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法 在项目早期的创新往往需要参考以往已经存在的类似产品，了解这些产品的功能，画出它们的用例图，确定基本实现思路，要实现创新还需要通过调查了解各种顾客对产品的需求，考虑不同人群对产品的需求，来添加一些其他产品没有考虑的功能和用例

• d.请使用SCRUM方法，在(任务b)用例图基础上，编制某定旅馆开发的需求(backlog)
  1. 搜索酒店：在首页选择城市、入住和退房日期， 选填关键词、酒店等级，点击搜索按钮
  2. 预定酒店：在酒店列表点击表项进入酒店详情页面，查看酒店可订的房型、相应日期、酒店地址，点击预定按钮
  3. 确认订单：查看详细订单，修改房间数量、预计到店时间，可选择购买保险，填写手机号码选填email确认订单
  4. 付款：选择付款方式，进行付款

2. 业务建模

• a.在(任务b)的基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法
  
  用流程图发现子用例的方法：沿着流程图的开始状态，选择流程图中的任意一个分支到流程图的结束状态，就得到了一个子用例。
• b.选择你身边的银行ATM，用活动图描绘取款业务
  
• c.查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务，在淘宝网上需要实现哪些系统用例
  
  淘宝需要实现的系统用例有：生成退款单、管理退款单、同意/不同意退款处理

  3. 用例文本编写

• 在大作业基础上，分析三种用例文本的优点和缺点
  • Brief：一段简洁的摘要
    • 优点：简洁明了、易于编写
    • 缺点：不够细致，只能提供粗略的分析
  • Casual：非正式的覆盖多种场景的段落
    • 优点：较Brief用例文本详细，
    • 缺点：不够正式
  • Fully：详细地编写用例所有步骤和各种变化，同时补充前置条件和成功保证等。Fully用例文本通常用在以摘要形式编写了很多用例以后，详细地编写其中少量具有重要意义和价值的用例
    • 优点：细节充足，具有结构性
    • 缺点：编写工作比较繁琐

• UMLet是一款具有简单用户界面，免费且开源的UML建模工具，能够快速构建UML序列图、活动图等，并且可以将原型导出为eps，pdf，jpg，svg等格式。UMLet可以独立运行，也提供Eclipse插件版本。
• 用例的定义：用例是描述参与者使用系统来完成某个目标的一系列成功和失败场景的集合
• UMLet的下载和安装：
  • 下载地址： http://www.umlet.com/changes.htm
  • 使用： 下载完成后解压，双击umlet.jar文件即可使用
    1. 添加：双击右上侧区域内要添加的对象，对象即自动添加至面板中
       
    2. 修改对象属性：选中面板中的对象，在右下角的属性面板中，可以修改对象属性
       
    3. 保存UML模型图：file -> save

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

• 瀑布模型

  • 优点：
    1. 将一个项目划分为若干个阶段，便于检查，降低了软件开发的复杂度
    2. 任意时刻是需要关注当前阶段
    3. 每个阶段完成后的文档和评估保证了阶段之间的正确衔接
    4. 可在迭代模型中应用
  • 缺点：
    1. 项目的各个阶段之间反馈极少
    2. 强调过程活动的线性顺序
    3. 在项目生命周期靠前的阶段中无法看到结果，因此具有一定盲目性
    4. 由于瀑布模型是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统工作量
    5. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段
• 增量模型
  • 优点：
    1. 人员分配灵活，可以根据市场反应来调整人力投入
    2. 增强客户对系统的信心
    3. 能有计划地管理技术风险
  • 缺点：
    1. 增量的粒度难以决定
    2. 如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布
    3. 由于进度和配置的复杂性，可能会增大管理成本，超出组织的能力
• 螺旋模型
  • 优点：
    1. 设计上的灵活性，可以在项目的各个阶段进行变更
    2. 以小的分段来构建大型系统，便于计算成本
    3. 每个阶段都有客户的参与，确保产品功能复合可预期，同时也保证了项目的可控性
    4. 良好的沟通使产品的指令得到客户的认可
  • 缺点：
    1. 对风险评估经验和专业知识要求较高
    2. 开发周期长，可能导致开发出来的产品与最新技术有较大差距，不再满足市场需求

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

三大特点： 1. 样例驱动，体现了用户驱动的开发 2. 以架构为中心，提供了其他发展演变的中心点 3. 受控的迭代式增量开发，允许使用不完善的知识进行开发，这体现了风险驱动的开发

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

1. 初始：
   • 获得项目的基础，为系统建立业务案例并确定项目的边界
   • 里程碑：生命周期目标，包括像Vision这样一些重要的文档
2. 细化：
   • 对问题进行分析，建立迭代化系统构架
   • 里程碑：生命周期构架，包括风险分析文档、项目计划等
3. 构造：
   • 完成产品的功能开发以及测试
   • 里程碑：初始运作功能的实现
4. 移交：
   • 把软件部署到用户环境
   • 里程碑：产品发布

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

因为工期由合同确定，每个阶段的完成时间都是定好了的，开发团队不能随意更改。质量也由合同中的验收条件确定，团队也不能轻易更改。只有范围/内容是由团队控制的，因为只有由团队来控制，项目才能够顺利完成。

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

- 固定生产节奏：UP的软件生命周期从时间上分为四个阶段，每个阶段都包括一个主要的里程碑，在每个阶段结束时根据阶段目标评估以决定是否进入下一个阶段
- 固定周期发布产品：UP通过迭代来控制风险，软件生命周期的每个阶段都可以划分为多个迭代，每次迭代会有一次发布
因此UP为企业按照固定节奏生产、固定周期发布软件产品提供了依据

项目管理使用

- 使用截图工具（png格式输出），展现你团队的任务Kanban，请注意以下要求
    - 每个人的任务是明确的。即一周后可以看到具体成果
    - 每个人的任务是1-2项
    - 至少包含一个团队活动任务
![](https://github.com/zhongrliu/zhongrliu.github.io/blob/master/Assets/assignments.png)

1.1 软件工程的定义:

1. 将系统化的、规范化的、可度量的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件；
2. 在1）中所述方法的研究

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

1. software crisis:软件危机，泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要表现为：
   • 软件开发进度难以预测
   • 软件开发成本难以控制
   • 用户对产品功能难以满足
   • 软件产品质量无法保证
   • 软件产品更难以维护
   • 软件缺少适当的文档资料
2. COCOMO模型：是由TRW公司开发，Boehm提出的结构化成本估算模型。是一种精确的、易于使用的成本估算方法。该模型按照详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型以及详细COCOMO模型。

1.3 软件生命周期：

1. 软件分析时期：问题定义、可行性研究、需求分析
2. 软件设计时期：总体设计、详细设计
3. 编码月测试时期：编码、测试
4. 运行与维护时期 软件生命周期存在多重模型，如瀑布模型、快速原型模型、螺旋模型等

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

1. 软件需求
2. 软件设计
3. 软件构建
4. 软件工程

1.5 解释CMMI的五个级别。例如：Level 1 – initial：无序，自发生产

1. 初始级Level 1-Inintial：软件过程无序，几乎没有定义，成功取决于个人努力
2. 可管理级Level 2-Managed：有了必要的过程纪律，能重复早先类似应用的成功经验
3. Level 3-Defined：实现软件的管理和工程两方面的文档化、标准化，所有项目都使用标准软件过程来开发和维护软件，软件的生产在整个软件过程中是可见的
4. Level 4-Quantitatively Managed：量化管理，分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制，管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能
5. Level 5-Optimizing：优化管理，过程量化反馈和先进的新思想、新技术促使过程持续不断改进

1.6 用自己的语言简述SWEBok或CMMI

SWEBok是Software Engineering Body Of Knowledge的简写，意为软件工程知识体系，是IEEE计算机协会、职业事件委员会主持的一个项目，旨在说明软件工程知识体系指南。软件工程知识体系从建立开始经过了数次版本迭代，其知识体系领域也在不算细化与拓展。知识体系在软件工程领域内定义了许多知识领域，到目前为止一共定义了15个KAs，包括软件需求、软件设计、软件构建、软件测试、软件维护等软件工程体系下的细分领域。

2. 按照PSP各项指标及技能要求

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

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

一个软件工程师在接到任务之后要做的事情有：

统计方法：将需求设计为日程安排，细化每天的任务量，这样就能够统计出每一项工作所花费的时间。

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