软工实践第八次作业

本次作业博客

团队信息

• 队名：起床一起肝活队

• 原组长：
  白晨曦(101)

  • 原组员：
    李麒 (123)
    陈德斌(104)
    何裕捷(214)
    黄培鑫(217)
    王焕仁(233)
    林志华(128)
    乐忠豪(121)
    蔡子阳(102)

• 临时组长：
  何裕捷（214）

  • 组员：
    李麒(123)
    陈德斌(104)
    黄培鑫(217)
    王焕仁(233)
    高裕翔(212)
    胡青元(081600410)
    蔡子阳(102)

---

alpha版本

模块序号	模块名	模块具体内容
1	登陆注册模块	用户的登陆与注册
2	个人信息模块	用户的个人信息
3	累计反馈模块	用户世界树的更新成长以及实时天气温度等信息
4	计划模块	以日历形式显示用户制定的计划，分个人和团队
5	闹钟模块	设置关联闹钟，优先级以及提醒方式

成员分工明细以及TODO-list

负责人	分工明细	TODO-list
白晨曦	1.规划项目进程；2.组织会议、分配任务；3.负责UI设计；4.参与文档拟写	完成各个界面的UI设计稿
陈德斌	辅助项目原型的逻辑功能设计	协同同何裕捷完成项目原型逻辑功能设计
林志华	1.负责前端的开发；2.辅助pm进行项目规划	个人信息模块前端开发
何裕捷	负责项目原型的逻辑功能设计	完成项目原型逻辑功能设计
黄培鑫	负责前端的设计、开发	完成登陆注册模块前端开发
蔡子阳	负责网络接口	完成网络接口的设计与开发
李麒	1.负责后台的设计、搭建；2.主要功能程序编写	完成后台构建以及累计反馈模块的实现
乐忠豪	1.辅助后台的设计、搭建；2.搭建数据库	闹钟模块的实现，搭建数据库
王焕仁	1.辅助后台的设计、搭建；2.辅助主要功能编写	计划模块的实现

燃尽图

---

UML

用例图

描述的部分：

• 这里是用户个人管理系统的用例图

面临的问题：

• 面临用户登录注册和个人信息处理等基本问题

解决的问题：

• 尽可能符合用户的使用习惯，使用户用起来方便

附图：

描述的部分：

• 这里是用户团队管理部分的用例图

面临的问题：

• 这部分面临用户管理团队的问题，包括创建团队，解散团队，加入团队，退出团队，添加成员，踢出成员

解决的问题：

• 罗列了团队管理的基本逻辑，让用户更方便地管理自己的团队

附图：

描述的部分：

• 这里是用户计划管理部分的用例图

面临的问题：

• 这部分面临用户管理计划的问题，包括删除计划，添加计划和查看计划

解决的问题：

• 罗列了计划管理的基本逻辑，让用户更方便地管理自己的计划

附图：

描述的部分：

• 这里是用户闹钟管理部分的用例图

面临的问题：

• 这部分面临用户管理闹钟的问题，包括删除闹钟，添加闹钟和查看闹钟

解决的问题：

• 罗列了闹钟管理的基本逻辑，让用户更方便地管理自己的闹钟

附图：

描述的部分：

• 这里是用户成长反馈部分的用例图

面临的问题：

• 这部分面临用户成长反馈的问题

解决的问题：

• 罗列了成长反馈的基本逻辑

附图：

类图

描述的部分：

• 用户与闹钟，团队，计划，累计反馈的关系

面临的问题：

• 各种类的关系复杂

解决的问题：

• 明确了各类的关系

附图：

活动图

描述的部分：

• 1 用户的团队管理部分。
• 2 用户闹钟制定的部分。
• 3 用户计划制定的部分。

面临的问题：

• 1 对软件不熟悉，进度缓慢，效率低。
• 2 缺少交流，没有统一好整个流程的实现。

解决的问题：

• 1 对要开发软件的整体结构更加了解。
• 2 更加清晰用户使用软件的整个流程

附图：

状态图

描述的部分：

• 用户的注册登录部分。

面临的问题：

• 账户的管理问题。

解决的问题：

• 解决用户的注册登录问题。

附图：
]
描述的部分：

• 关联计划部分。

面临的问题：

• 关联计划有什么作用。

解决的问题：

• 用户可以创建计划、查看计划、修改计划。

附图：

描述的部分：

• 用户关联闹钟管理的部分。

面临的问题：

• 关联闹钟的管理问题。

解决的问题：

• 用户可以对关联闹钟创建、删除、修改。

附图：

描述的部分：

• 关联闹钟的叫醒部分。

面临的问题：

• 关联闹钟如何叫醒用户。

解决的问题：

• 用户通过完成任务、成员一键呼叫来起床，用户起床后或无法被联系才解除闹钟。

附图：

描述的部分：

• 累积反馈部分。

面临的问题：

• 累积反馈的过程如何。

解决的问题：

• 完成任务后成果增加，超过时间未完成任务则成果减少，可以查看自己的成果。

附图：

实体关系图

描述的部分：
这里是软件所拥有的实体以及它们之间的关系

面临的问题：
如何清晰地展示我们软件的一个实体属性以及之间的关系。

解决的问题：
能让用户和程序员更清晰地了解到软件的构成。

附图：

---

构件图

描述的部分：

• 1 用户界面
• 2 计划管理
• 3 成长反馈
• 4 团队关联

面临的问题：
如何描述接口和系统功能

解决的问题：
在有交互的界面标注接口，系统功能分为直接调度和程序调用

附图：

对象图

描述的部分：

• 描述对象与类之间的关系

面临的问题：

• 对软件不熟悉以及需要等待类图

解决的问题：

• 明确了对象与类的关系

附图：

序列图

描述的部分：

• 1 总体而言，是对象之间的沟通方法，描述运行时的交互关系。
• 2 流程而言，创建一个群组，并进行发布（关联闹钟|关联计划）的过程。
• 3 具体而言，是在一次正常工作情况中，进行的用户，系统，数据库之间的数据交路的过程与方法。

面临的问题：

• 1 如何建立正确的模块调用关系。
• 2 如何处理好大量用户情况下的调用。

解决的问题：

• 1 让模块调用顺序化，具体化。
• 2 让系统能成功调用模块和功能。

附图：

部署图

描述的部分：

• 描述用户，客户端，数据库的关系

面临的问题：

• 系统如何部署

解决的问题：

• 更好的体现了各个硬件的宏观关系

附图：

---

工具选择

• 工具：StarUML
• 评价：
  1.优点：针对性强，容易上手，使用便利，转出方便。
  2.缺点：相比其他在线工具需下载安装才能使用，功能的友好度方面缺少团队协作功能和自动保存功能。

---

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	180	190
· Estimate	· 估计这个任务需要多少时间	5	5
Development	开发	90	120
· Analysis	· 需求分析 (包括学习新技术)	60	60
· Design Spec	· 生成设计文档	30	60
· Design Review	· 设计复审 (和同事审核设计文档)	0	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	0	0
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	80	80
· Test Report	· 测试报告	0	0
· Size Measurement	· 计算工作量	20	20
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	60	60
合计		350	390

---

个人贡献

• 课上贡献分评估

短学号	姓名	此次作业任务	贡献分配	备注
214	何裕捷	用例图	13.5%	临时队长
123	李麒	对象图；写博客	13%
104	陈德斌	实体关系图	12.5%
217	黄培鑫	状态图	12.5%
233	王焕仁	活动图	12%
212	高裕翔	构件图	11%
081600410	胡青元	顺序图	12.5 %
102	蔡子阳	类图；部署图	13%

• 课后贡献分评估

短学号	姓名	此次作业任务	贡献分配	备注
101	白晨曦	组织	5%	原组长
214	何裕捷	用例图	15%	临时队长
123	李麒	对象图；写博客	16%
104	陈德斌	实体关系图	13%
217	黄培鑫	状态图	13%
233	王焕仁	活动图	12%
102	蔡子阳	类图；部署图；alpha版本分工；燃尽图	22%
128	林志华	完善构图	2 %
121	乐忠豪	完善构图	2%

---

换队环节感受

这次换队考验了我们的临时应变能力，一开始大家对于换队比较的紧张，不知道如何是好，不过很快我们就开始正常进行团队作业了。这次换队的优点在于换队的同学为我们提供了很多制作UML图方面的想法与工具，缺点是新换队的同学对项目了解较少，制作图的时候有一点困难。