第12组 团队项目-需求分析报告

写在前面

组长博客

另外图看不清可以点开看大图

组队后的团队项目的整体计划安排

时间 计划
9.26-10.19 选题报告及答辩
10.20-10.26 需求分析报告及答辩
10.28-10.29 接口设计
10.30-11.3 总体框架搭建
11.4-11.22 Alpha
11.23-12.13 Beta
12.14-？ 完善

详见下节的Todo List

团队分工

Alpha Goal

后端

  1. 用户认证模块完整
  2. 点记录和分享模块实现
  3. 轨迹记录和分享模块实现
  4. 社交模块完整实现
  5. 平台集成和社会化分享能做多少算多少

App端

  1. 用户认证模块完整
  2. 点记录和分享模块实现
  3. 轨迹记录和分享模块实现
  4. 社交模块基本实现
  5. 平台集成和社会化分享能做多少算多少

成员分工明细

成员 分工
王永福 派任务、催进度、后端、App
孙承恺 算法设计和实现、App实现
邱畅杰 社会化分享模块
丁枢桐 社会化分享模块、算法设计和实现
张凌昕 App、公共事务
余琳玲 App、文案
林青霞 App
林星培 App
徐祖豪 App

其中App部分的细分见Todo，采用动态分配的认领制度

Todo

燃尽图

思维导图

本次团队分工

流程

工作量评估

成员 工作量
张凌昕 5%
孙承恺 12%
邱畅杰 8%
林星培 10%
余琳玲 14%
林青霞 10%
王永福 23%
徐祖豪 5%
丁枢桐 13%

具体理由可见前节的流程图

评审表

别看了

UML

成员成果汇集

Part 1 类图

  • 这里描述的是系统哪部分？
    • 描述了系统各部分数据的关系
  • 这部分要面临什么样的问题 ？
  • 各部分关联和划分
  • 以下设计解决了哪些问题
  • 解决了开发者对于各个类体之间关系的宏观认识

Part 2 用例图

  • 这里描述的是系统哪部分？
    • 用户与系统的交互用例
  • 这部分要面临什么样的问题 ？
  • 哪些用户能干什么
  • 以下设计解决了哪些问题
  • 明晰了用户类型及操作

Part 3 认证状态图

  • 这里描述的是系统哪部分？
    • 用户与系统认证的状态
  • 这部分要面临什么样的问题 ？
  • 面临账号的登入注册的设计逻辑的问题
  • 以下设计解决了哪些问题
  • 解决了在设计登入注册找回密码这几个方面的逻辑顺序

Part 4 点分享状态图

  • 这里描述的是系统哪部分？
    • 点分享的状态
  • 这部分要面临什么样的问题 ？
  • 面临发布和浏览点分享的设计逻辑的问题
  • 以下设计解决了哪些问题
  • 解决了发布和浏览点分享的状态转换问题

Part 5 轨迹状态图

  • 这里描述的是系统哪部分？
    • 轨迹的状态
  • 这部分要面临什么样的问题 ？
  • 面临记录编辑轨迹的设计逻辑的问题
  • 以下设计解决了哪些问题
  • 解决了记录编辑轨迹的状态转换问题

Part 6 活动图

  • 这里描述的是系统哪部分？
    • 用户使用系统的流程
  • 这部分要面临什么样的问题 ？
  • 用户可能不清楚系统的操作逻辑
  • 以下设计解决了哪些问题
  • 明晰了用户的操作顺序和操作预期结果

Part 7 实体关系图

  • 这里描述的是系统哪部分？
    • 系统间各实体的关系
  • 这部分要面临什么样的问题 ？
  • 各实体间如何组织
  • 以下设计解决了哪些问题
  • 明确了各个实体的属性及其间的关系

Part 8 部署图

  • 这里描述的是系统哪部分？
    • 系统部署架构
  • 这部分要面临什么样的问题 ？
  • 系统如何部署
  • 以下设计解决了哪些问题
  • 明确了系统部署是各个组件的节点分配

关于工具

主要使用了几个工具：Visio、Process On、Visual Paradigm、StarUML

  • Visio: 强大，不管对于初学者还是有高级要求的人员都适用
  • Process On: 简单易上手，对初学者友好，但高级功能欠缺，且不能导出到能在其他软件编辑的通用格式，偶有小Bug
  • Visual Paradigm: 非常高级的工具，学习曲线陡峭，难以掌握
  • StarUML: 专门画UML的，易用，强大，但比较卡，且难以破解

答辩总结

得分

组号 分数
1
2 54.6
3 51.3
4
5
6
7
8 47.4
9 50.4
10
11
12 49.2
平均分 50.3
截至本博客撰写时(2019-10-27T17:30)，空白为未评分的小组

Q&A

1

  • Q: 请问你们对帖子的内容有限制或审核吗？如何规避大家都不分享轨迹而发布一些与软件无关的内容？
  • A: 后期上线时我们可以引入简单的关键词审查机制或引入第三方内容过滤服务提供商缓解这个问题

2

  • Q: 创意还是很不错的，希望将重点放在吸引用户量上，或者将分享内容与其他社交平台联动获取更大的关注度
  • A: 谢谢您的建议，我们会认证考虑的

3

  • Q: 对那些积极分享或是分享内容优秀的用户会不会有适当的奖励机制？
  • A: 我们在上线后可以考虑赠送增值服务等方式来奖励，或推出原创激励计划

4

截至本博客撰写时(2019-10-27T17:30)，尚未提问

5

截至本博客撰写时(2019-10-27T17:30)，尚未提问

6

  • Q: 记录轨迹的时候是否可以停止一段时间后，再继续上一次的记录？
  • A: 我们会考虑加入此功能，如果时间允许

7

  • Q: 为什么在这次作业中把使用cordova改成了Android
  • A: 我们在前期调研趟坑中发现了Cordova的地图存在较为严重的性能问题

8

  • Q: 对用户的需求场景还可以进行多一些的调查，请问如何去审核一些不文明的分享动态？
  • A: 谢谢您的建议。后期上线时我们可以引入简单的关键词审查机制或引入第三方内容过滤服务提供商缓解这个问题

9

  • Q: 创意挺好的，想请问该软件的可移植性考虑是？
  • A: 目前计划使用原生Android开发，暂无其他平台计划

10

  • Q: 请问你们靠什么吸引用户在一众同类app中选择使用你们的app呢？
  • A: 我们的App目前来说更轻量，不过于商业化，且有在轨迹上进行标记的功能和基于位置的社交功能，相信可以吸引用户

11

  • Q: 没有安卓基础或许用小程序上手快一点？
  • A: 确实如此。但是小程序对设备能力的调用限制较多，且网页应用有性能问题

需求分析报告

其中有修订记录
另外根据柯老板的建议修改了字体大小
别看了

最终版本，散了吧

遇到的困难及解决方法

困难描述

本次作业要求完成一份需求分析报告，组内同学都没有相关经验

做过哪些尝试

根据作业要求和Checklist, 网上找了几份模板，嫖了一下往届学长学姐的报告，最后形成了一份框架，然后根据框架分配任务，完成报告。

是否解决

是

有何收获

了解了一份完整的需求分析报告应该包括哪些内容。以及需求分析报告的目标人群是谁，文字应该如何组织才能够达到写这份报告的目的。对于规范文本的格式也有了更多了解。

PSP表格

PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟）
Planning 计划 20 20
Estimate 估计这个任务需要多少时间 20 20
Development 开发 1055 1720
Analysis 需求分析 (包括学习新技术) 100 250
Design Spec 生成设计文档 60 100
Design Review 设计复审 20 20
Coding Standard 代码规范 (为目前的开发制定合适的规范) 125 150
Design 具体设计 240 360
Coding 具体编码 240 360
Code Review 代码复审 120 180
Test 测试（自我测试，修改代码，提交修改） 150 300
Reporting 报告 60 90
Test Repor 测试报告 20 30
Size Measurement 计算工作量 15 20
Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 25 40
合计 1135 1830

学习进度条

第N周 新增代码（行） 累计代码（行） 本周学习耗时(小时) 累积学习耗时(小时) 重要成长
1 0 0 5 5 熟悉Axure RP用法
2 0 0 5 10 了解原型设计方法
3 0 0 5 15 原型设计实战
4 0 0 12 27 团队项目原型设计
5 0 0 15 42 学习kotlin
posted @ 2019-10-27 21:05  雨霖铃0000  阅读(91)  评论(0)  编辑  收藏  举报