软工实践第八次作业
团队信息
-
队名：起床一起肝活队
-
原组长：
白晨曦(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图方面的想法与工具，缺点是新换队的同学对项目了解较少，制作图的时候有一点困难。
