项目UML设计（团队）
前言
团队
| 组长 | 成员 | 参与 | 贡献比例 |
|---|---|---|---|
| ★ | 530 雨勤 | 用例图设计 | 18% |
| 311 旭 | 状态图设计 | 17% | |
| 403 俊 | 类图设计 | 21% | |
| 223 元 | 活动图设计 | 20% | |
| 437 海辉 | 博客随笔+WBS分工设计+燃尽图 | 24% |
分工
-
WBS
粒度较粗，主要描述每个模块下的分工，由于未讨论出真正适合且效率较高的代码，无法给出更加细的粒度工作。
确定 alpha 版本需要做哪些事情
这个需要时间，挤出来的时间。。。
-
分工明细
| 成员 | 负责模块 | 具体任务 |
|---|---|---|
| 530 雨勤 | 车辆检测与跟踪 | |
| 311 旭 | 行人检测与跟踪 | |
| 403 俊 | 界面 | |
| 223 元 | 测试+热力图 | |
| 437 海辉 | 视频摘要 |
-
leangoo
小组内近期任务分布
任务完成情况（惊了。。。某人竟然）
-
燃尽图
按工作方式
按照卡片数
UML
工具：Process on
- 优点：支持流程图、思维导图、原型图、UML、网络拓扑图等；支持图形界面操作，容易上手，方便实用；随时将作品分享给队友，达成团队之间的共享，能够更好的协同合作，互相促进；资源丰富，图库资源强大；
- 缺点：模板商务化，没有酷炫的年轻化形式；需在线操作，网络因素可能造成不便；
用例图
这里描述的是系统哪部分？
- 描述了用户通过摄像头能够进行的操作，以及完成操作后的行为和调取需求视频的方法。
以下设计解决了哪些问题？
-
解决了用户的可使用范围，通过我们的系统能够完成以视频摘要、行人检测、车辆检测为主的三大模块下的10个具体功能。
-
类图
这里描述的是系统哪部分？
描述了系统每个部分之间的关系、连接情况。
以下设计解决了哪些问题？
解决了开发者对于各个类体之间关系的宏观认识。
-
活动图
这里描述的是系统哪部分？
描述用户具体选择视频实时监控与视频分析两大模块，每个行为对应的结果，例如流量分析、视频摘要。
- 这部分要面临什么样的问题？
视频摘要部分的结果页的存储可能会面临困难。
- 以下设计解决了哪些问题？
解决了对于每一个功能页中可操作的行为的范围，以及一些超出允许操作的警告，如反馈页面的部分限制。在主体范围内，无论是视频监控还是视频分析，均可进行行人检测、车辆检测、流量统计、视频摘要等四大功能，并输出保存。
状态图
- 这里描述的是系统哪部分？
信息摘要和输出摘要中的热力显示模块
- 以下设计解决了哪些问题？
解决了对视频进行行人、车辆检测后，对视频图像的显示问题，更加直观地展示出来。
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 100 | 60 |
| · Estimate | · 估计这个任务需要多少时间 | 100 | 60 |
| Development | 开发 | 0 | 0 |
| · Analysis | · 需求分析 (包括学习新技术) | 0 | 0 |
| · Design Spec | · 生成设计文档 | 30 | 20 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 30 | 40 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 30 |
| Reporting | 报告 | 120 | 60 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 80 | 30 |
| 合计 | 470 | 310 |
