Process on
必做图
该部分描述了用户通过小程序点菜拍照能够进行的操作，以及拍照识别后的支付和数据的处理
解决了用户的可使用范围，通过我们的系统可以进行自助结账，点餐，数据周报，菜品调整等功能
类图描述了系统每个部分之间的关系、连接情况。
面临模块太多，比较复杂
解决了利用类体关系图解决了开发者对各个类体之间关系的宏观认识
这里描述的是系统的学生/教师和商家所在界面下的主要行为对应的结果。
面临学生/教师端的分支结构多，在页面设计和返回的逻辑上有一定的复杂性等问题。
解决了页面之间跳转的选择问题，以及标明学生/教师界端与商家端的联系，使设计界面的时候更为便捷。
状态图（statechart diagram）是描述一个实体基于事件反应的动态行为，
显示了该实体如何根据当前所处的状态对不同的事件做出反应，以及由于各种事件的发生而引起的状态之间的转移。
该部分主要介绍了项目的所拥有的模块，以及每个模块所附有的属性。
主要解决了功能模块的划分，以及属性之间的关系，展示了项目所需要的数据
其他图
时序图是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。
面临着需要先与类图，活动图同一等问题
解决了展示对象之间交互的顺序。将交互行为建模为消息传递，通过描述消息是如何在对象间发送和接收的来动态展示对象之间的交互；
该部分描述了各部门的职能和他们之间的联系还有整个项目的不同阶段。
方便的描述了各职位的职能流程，直观描述了各职位的逻辑关系，便于理解项目流程。
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 90 | 120 |
| ?Estimate | ?估计这个任务需要多少时间 | 500 | 730 |
| Development | 开发 | 40 | 30 |
| ?Analysis | ?需求分析 (包括学习新技术) | 150 | 200 |
| ?Design Spec | ?生成设计文档 | 30 | 20 |
| ?Design Review | ?设计复审 | 20 | 15 |
| ?Coding Standard | ?代码规范(为目前的开发制定合适的规范) | 10 | 20 |
| ?Design | ?具体设计 | 10 | 20 |
| ?Coding | ?具体编码 | 150 | 300 |
| ?Code Review | ?代码复审 | 30 | 30 |
| ?Test | ?测试（自我测试，修改代码，提交修改） | 20 | 20 |
| Reporting | 报告 | 30 | 20 |
| ?Test Repor | ?测试报告 | 20 | 15 |
| ?Size Measurement | ?计算工作量 | 40 | 20 |
| ?Postmortem & Process Improvement Plan | ?事后总结, 并提出过程改进计划 | 30 | 20 |
| 合计 | 580 | 730 |
| 成员 | 参与 | 贡献比例 |
|---|---|---|
| 后敬甲 | 燃尽图+博客补充 | |
| 卢泽明 | 用例图设计 | 13% |
| 张扬 | 状态图设计 | 15% |
| 刘浩 | 类图设计 | 15% |
| 葛亮 | 活动图设计 | 14% |
| 蔡文斌 | 实体关系图设计+WBS图设计+博客整理 | 16% |
| 黄婧茹 | 泳道图 | 14% |
| 黄泽 | 时序图 | 13 % |
原文：https://www.cnblogs.com/hjjLcherry/p/9821523.html