目录

一、团队项目计划

整体计划安排

里程碑

二、项目分工与贡献度

项目分工

改进前：开始时采用的方式为组员自己选取分工，并自发去完成，经过两天时间的检验后发现这种方式并不合理，于是及时更改策略。

改进后：采用了指定人数且半自愿半强制的工作分配方式，由组长根据每个人的能力、兴趣和其他因素，决定出小组长和各项分工人员。

改进后的分工相对合理可执行，从最终的完成情况也证明了这一点。简单说一下如此分配的考量：需求规格说明书和原型设计是此次作业的工作量较大部分，于是需要的人数较多，且其负责的小组长应该专职专责，负责其该小组内的会议召开、组织调配、商讨决策、成果整合、与组长交流汇报等等。因为需求规格说明书和原型设计内容互有交叉，无法完全割裂，于是在两个小组中同时出现了相同的人员，也是为了方便两个小组间进行交流协作。同理，需求分析与原型设计ppt制作与具体实现内容也密切相关，于是在ppt制作中安排了上述两组的成员充当参谋的效果。另外还有一些工作无法量化，如组长的团队项目管理，工作的组织安排，成果的审查修改、后勤等工作，因此不予罗列，但会因实际情况考虑其贡献度。

• 组织模式：团队组长统筹管理，进行整个团队的考虑；下设各分工小组长，统领安排小组分工作业，进行组与组间的交流，向组长反馈问题和汇报工作；小组员在各自分工小组中充分发挥作用，进行基础作业。
• 协作形式：线下会议、腾讯会议、讨论组讨论、私下讨论、文件交流、在线文档、在线表格、Axure共同开发、ProcessOn在线共享开发。

贡献度

贡献度（100%）=需求规格说明书（30%）+ 原型设计（30%）+ 博客（8%）+ PPT（4%*2）+ 评审表（2%*2）+ 答辩（6%）+ 其他 （14%）[组长/小组长（3%*3）+ 后勤（5%）]

三、界面原型设计

Android原型：<点击进入>
Web后台原型：<点击进入>

四、界面原型设计答辩PPT

界面原型设计答辩PPT：<界面原型设计答辩PPT>

五、软件需求规格说明书

需求规格说明书下载：<需求规格说明书>

实现过程的设计思路、遇到的问题以及解决的方式：

• 051904112：原型设计和需求文档交叉依赖，原本的设想是齐头并进，但实际执行起来却变成了各说各话，原型界面每多一个组建就意味着文档中的类图、界面功能描述与验收标准的大范围更改。二者配合难度大，导致后需不断更改。
• 221900334：需求规格说明书的编写采用了腾讯文档，能看到其他人的描述，使文档整体风格类似，并且在较为关键的类图设计时也采用了在线协作网页process on，配合语音通话，实现了较好的沟通交流。

六、需求分析报告PPT

需求分析报告PPT下载：<需求分析报告PPT>

七、评审表

界面原型设计评审表：<点击跳转>
需求分析评审表：<点击跳转>

八、本博客的全部附件

本博客的全部附件：<点击跳转>

九、反思总结

个人总结

• 221900309：遇到最大的困难应该是在团队协作方面，在一个10人的大团队中，每个人的意见难免有一些出入，在对项目的方案以及实现上讨论的十分激烈；原型设计和规格说明书的撰写上，大家的风格都不太一致，也经历了一个漫长的协调统一过程。在校园地图的设计中，通过查阅资料得知，可以通过地图开放平台设计自定义地图并获取html代码，将html代码转为js后。导入到Axure的内联框架中，即可将地图展现在原型上。
• 221900334：感觉这次作业的难点就是在于团队如何进行高效的协作，原型设计的时候一人设计一个模块，每个人设计风格不同，导致整合后要多费力气修改细节。

关键点，难点分析

• 221900331:

1. 十人团队的管理，如何保证保质保量的完成每一次任务，如何进行合理的分工，如何调动团队成员积极性。
2. 原型设计的功能是否要全部实现，或者能否进行改善，用户的需求是否真正得到满足。
3. 信息数据的采集和更新该如何开展。
4. 数据库的设计。
5. 前后端的交接如何做好。
6. 难点功能如校园地图板块该如何实现。
7. Alpha冲刺结束后的1.0版本成功的标准如何制定。
8. Beta冲刺要完成哪些工作，是否真正达到产品的要求。
9. 如何使团队和个人获得预想的收获和成长。