Followers——需求分析

[Followers_]

这个作业属于哪个课程	福大软工实践W班
这个作业要求在哪里	作业要求的链接
团队名称	Followers
这个作业的目标	项目需求分析
其他参考文献	Axure教程、《需求规格说明书》参考、csdn等

目录

• 一、团队项目计划
• 整体计划安排
• 里程碑
• 二、项目分工与贡献度
• 项目分工
• 贡献度
• 三、界面原型设计
• 四、界面原型设计答辩PPT
• 五、软件需求规格说明书
• 六、需求分析报告PPT
• 七、评审表
• 八、本博客的全部附件
• 九、反思总结
• 个人总结
• 关键点，难点分析

一、团队项目计划

整体计划安排

主要任务	计划时间	内容
团队展示	3.13-3.19	组建团队并确定项目选题；进行选题汇报
个人学习	3.20-3.26	个人选择开发方向进行相关知识学习
项目需求分析	3.27-4.2	撰写项目软件需求规格说明书；进行界面原型设计；需求分析答辩；原型设计答辩
个人学习	4.3-4.16	组员确定开发方向；个人选择开发方向进行相关知识学习；制定代码规范
概要设计和数据库设计	4.17-4.23	进行概要设计和数据库设计；项目开发前期准备；环境配置；确定负责模块
团队GitCode实训	4.24-4.26	完成项目实训
Alpha冲刺	4.24-5.7	完成α版本开发；完成项目结构搭建，实现基础功能；站立式会议
Beta冲刺;进行优化	6.1-6.18	完成β版本开发；实现未完成功能；拓展功能；对项目进行优化
总结	6.19	个人技术总结；项目总结

里程碑

二、项目分工与贡献度

项目分工

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

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

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

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

贡献度

学号	工作内容	贡献度
221900331	团队项目管理；工作安排对接；审查修改；博客撰写（50%）；答辩（100%）	13%
051904112	需求小组组长；需求规格说明书部分（26%）：类图、引言、总体描述、输入输出格式、个人与后台模块	10.8%
221900223	需求分析ppt制作（90%）、原型设计ppt制作（90%）	7.2%
221900225	原型设计部分（20%）：“我的”页面、细节优化 ；博客撰写（50%）；原型设计ppt制作（10%）	10.4%
221900305	需求分析评审表（100%）；原型设计评审表（100%）；需求规格说明书部分（15%）：娱乐天地的功能编写，模块后续的修改	8.5%
221900309	需求规格说明书部分（21%）：类图，校园地图模块原型及验收标准编写；原型设计部分（35%）：校园地图、细节优化、主要功能添加；	16.8%
221900325	后勤；相关资料搜寻	5%
221900334	需求规格说明书部分（21%）：用况图、类图、生活须知模块编写；原型设计部分（20%）：需知、后台管理系统贴图	12.3%
221900413	需求规格说明书部分（17%）：“我的”页面、细节优化 ；原型设计部分（15%）：学习社区；需求分析ppt制作（10%）	10%
221900424	原型小组组长；原型设计部分（20%）：文娱、后台管理系统模型	9%

贡献度（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. 如何使团队和个人获得预想的收获和成长。

[Followers_]

@助教_李耕 助教的建议十分中肯实用，感谢！这次文档类的开发过程中虽然强调了进行沟通一致，但没有一个具体的参考大家的成果风格上多少出现了一些不一致，浪费了些许人力和时间在于统合文档，是值得思考改进的地方，注重每处细节才能获得成功。

[助教_李耕]

建议：一定要注意各文档间风格的一致性，不然到最后统合文档时难免遇到麻烦，建议大家（不同文档负责人）都参考、学习毕业论文撰写规范的部分内容，保证格式的规范、一致、美观性，养成好习惯，这对以后是有帮助的。

[Followers_]

@助教_李耕 这次作业只使用在线表格了，在作业过程中确实遇到了只使用在线表格不方便的地方，这也是前期准备工作做得不到位的结果，可能没有接触到一些专业的项目管理工具。只注重的开发过程轻视了整个工程项目的管理过程，导致项目管理起来出现了一些困难，接下去会多进行成熟的企业开发流程的调查学习，使用助教提到的teambition等其他工具来协助管理。

[助教_李耕]

总体来说完成得很棒！文档内容很完整，还给出了本次作业的部分过程、困难与感想描述，很真实，总结的很好。答辩加油~
还有个问题就是你们是否采用了专业的、带看板、时间轴等功能的项目管理工具？是只使用在线表格吗？可以试一下teambition。

[Followers_]

@助教_吕庆炜 是的，由于每个人的长处和兴趣不一样，而且我们这是一个长期多次的团队项目，可能说在这一次任务中配比比较少的，出于各种考量，在后续任务中要承担更多的工作，做出更大的贡献。这是一个我们团队10人共同的项目，每个人都不应该游离在外，而应该是每个人添砖加瓦，共同呵护。例如我们的小组长，一是采取自愿报名的方式，但组长也会考虑到能力和经历，尽量能让每个人都在任务周期中担任过小团队的组织者，进行一个锻炼，虽然这样每个人的身份不断切换会导致工作中遇到一定的困难，需要去克服，但总的来说有利于每个人的成长！

[助教_吕庆炜]

博客写的很丰富！对任务分配方式做了思考和改进，很棒。
对于贡献度比较低的同学，在之后的任务分配时是否会有一定侧重或分配要求呢？

[Followers_]

@助教_陈雨虹 助教一语中的，点出了任务过程中的重难点。与以往专注于代码编写不同的是，此门课程团队协作、团队管理、软件开发过程更是重中之重，由于是第一次进行这类实践，难免会遇到很多问题，比如助教提到的问题，这个过程没有捷径，我们需要不断进行探索改进，反思总结，最终得出适合我们团队的各项方法标准等。

[助教_陈雨虹]

如何整合采用统一标准去进行人员、任务等等的评估是需要进行考量的。合理的交流与沟通也是我们这门课的必修部分。
前期工作可能确实需要有经验的同学引导其他同学展开，后续的代码工作亦是如此，如何将学习成本等等融入工作量也需要新的考量。

[Followers_]

@Jingbin-Wang 谢谢老师的肯定和点评！用例图两个Actor分开画图确实会更清晰明了；原设计的person类和role类的关系确实有模糊、令人疑惑的问题，不太妥当，我们将重点针对这些问题以及其他人提出的建议进行改进！

[Jingbin-Wang]

界面原型设计清新简约，整体舒适，赞！
完全民主的分工不一定合理。用例图不建议采用将两个Actor的用例图合在一起；person类和role类的关系是否合理？