团队项目之UML图设计---WeEdit

团队信息：

 

学号：	姓名：	本次博客连接：
041602209	黄毓明（临时队长）	https://www.cnblogs.com/mingsonic/p/9820702.html
061600236	杨礼亮	http://www.cnblogs.com/YangLiLiang/p/9821082.html
031601124	蒋熊	https://www.cnblogs.com/jxdbky/p/9822930.html
031601123	黄志铭	http://www.cnblogs.com/zhimingfzu/p/9823028.html
181600215	林翔宇	https://www.cnblogs.com/Stella12/p/9823123.html
031602219	柯奇豪（原队长）	http://www.javashuo.com/article/p-mezkqnqe-dv.html
031602603	陈超星	https://www.cnblogs.com/ccxccx/p/9822698.html
041602204	丁水源	http://www.javashuo.com/article/p-wbsgrcgy-me.html

团队分工：

 分工图及todolist：

燃尽图：

 

 

UML  Design：

Part1：（部署图）

 

 • 这里描述的是系统哪部分？

      这里主要说明的是部署问题

• 这部分要面临什么样的问题？
　　服务器及数据库的搭建，先后端交互等。
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　前端客户操做返回给后台服务器，后端服务器依照前端操做给出相应返回值，从数据库中调用相应的数据。

 

 

 

 

 

 

Part2：（类图）

 

 • 这里描述的是系统哪部分？

      使用WeEdit小程序的功能方面内容。

• 这部分要面临什么样的问题？
　　1）项目模块定义不够清晰；
       2）代码未有统一格式；
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　 经过统一参数，方便后续先后端工做的配合。

 

 

 

 

 

 Part 3：（状态图）

 

• 这里描述的是系统哪部分？

      这部分UML描述了发布签到、发布共享文档、发布投票功能可能的状态以及其中状态的具体活动

• 这部分要面临什么样的问题？
　　每一个具体状态转化细化得不够彻底、在实现中还需更近一步改进
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　 体现了软件须要的功能以及解决了软件内部各功能实现的逻辑问题

 

 

 

 

 

 

 

 Part 4：（用例图）

 

• 这里描述的是系统哪部分？

       这里是用户在**WeEdit**系统上可以进行各项操做的部分，以及对操做内容的具体化。

• 这部分要面临什么样的问题？
　　须要面临功能如何按照用户习惯排布的问题
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　 各个功能模块之间直观的逻辑联系

 

 

 

 

 

Part 5：（活动图）

 

• 这里描述的是系统哪部分？

       描述了用户具体选择发布通知，现场签到，投票，想法收集和文章分享这几大模块。以及每一个模块相对应的后续操做和结果。如进入现场签到模块后，能够选择签到会议。

• 这部分要面临什么样的问题？
　　不能防止同窗带翘课的同窗的手机来签到。
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　 解决了用户权限的问题。不一样权限的用户进入不一样的界面，进行不一样的操做，不会发生权限混乱形成文件出现错误。

 

 

 

 

 

 

Part 6：（时序图）

 

• 这里描述的是系统哪部分？

       展现对象之间交互的顺序。它经过描述对象之间发送消息的时间顺序显示多个对象之间的动态协做。

• 这部分要面临什么样的问题？
　　须要理清项目各模块内的逻辑，按时间顺序显示各模块内的动态协做。
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　更加清晰地展现了各模块内的交互逻辑、交互顺序。

 

 

 

 

 

Part 7：（实体关系图 ）

 

• 这里描述的是系统哪部分？
 　　主要描述的是系统的概念结构设计的部分。
• 这部分要面临什么样的问题？
　　实体的决定、实体属性的决定、实体之间的关系（包括了一对一，一对多，多对一，多对多）
• 如下设计解决了哪些问题？
　　解决的问题：
　　　　1） 分配了七个实体：参与者、发起者、投票、现场签到、文章分享、想法收集、发布通知
　　　　2） 各实体属性的决定。具体属性可参照“实体关系图”。
　　　　3） 各实体之间的关系。具体实体之间的关系可参照“实体关系图”

　　参与者

　（E-R图——参与者）　

 

 （E-R图——发起者）

 

工具选择：

　　 Process ON 

　　主要是基于方面才选择这个工具的，之前的老师也有推荐过。

 

使用感觉:

　  简单便携，支持的UML也比较多，主要是网页版，随时随地均可以使用，也比较容易上手，适合小团队使用。

 

PSP表格

 

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

 

Individual Score

具体评分细则：

 

姓名	贡献分+基础分=总得分（%）
黄毓明	15+2=17
丁水源	14+2=16
杨礼亮	11+2=13
蒋熊	6+2=8
黄志铭	6+2=8
苏路明	13+2=15
陈瀚霖	7+2=9
胡展瑞	12+2=14

 

• 本队“原队长”给出的“课后”贡献分评估

学号	名	“课后”贡献分	评价
031602219	奇豪(队长)	12.5%	分配到的任务不难，算是正常操做，做为标准拿个基础分
041602209	毓明	14.5%	做为临时队长分配管理很好，各项任务也能尽职尽责
041602204	水源	13.5%	任务完成基本符合预期，可是用词上还须要改进，例如ER图中实体、属性应该是名词，“核实”以及某些实体的叫法都偏动做了些
061600236	礼亮	13.5%	任务完成基本符合预期，可是菱形分支上缺少条件说明，部分箭头指示缺失，还望及时修改
031602603	超星	6.5%	参照交换组的评定，彷佛贡献度不够，需注意
181600215	翔宇	12.5%	参照交换组的评定，任务完成基本符合预期
031601123	志铭	10.5%	两人作的话彷佛分摊的工做量略小，同时类图的规范标准彷佛没有明确，"+"(public)、"-"(private)和"#"(protected)的区别
031601124	熊	10.5%	两人作的话彷佛分摊的工做量略小，同时类图的规范标准彷佛没有明确，"+"(public)、"-"(private)和"#"(protected)的区别

 

本次团队项目感觉：

做为本次UML图设计的临时队长（自荐的），其实感受本身仍是有点不够尽职，对于任务分配和贡献分分配仍是有些不太熟练，但好在队员们都很配合，无论是转过来队员，仍是本组的原有队员，都积极配合完成工做，最后完成的结果也还能够，但感受氛围仍是有点生疏，没有在原队伍的那种感受，多是由于我没有协调好，互动好吧，这里我反省一下本身。优势方面：新换来的队友都很积极，完成的效率质量都也还不错。 缺点：协同性较差，交流较少，做为临时队长自我反省。