团队项目-需求分析报告

组长博客连接

一、总体计划安排

阶段序列	阶段时间	主要阶段任务	完成状况
第一阶段	9.18	团队成立	已完成
第二阶段	9.18-9.25	肯定选题及协商分工	已完成
第三阶段	9.25-10.14	前期学习及准备	已完成
第四阶段	10.14-10.20	选题报告	已完成
第五阶段	10.20-10.27	需求分析报告	已完成
第六阶段	10.27-11.9	完成用户登陆模块	待完成
第七阶段	11.9-11.23	完成用户车辆登记板块	待完成
第八阶段	11.23-11.30	完成用户留言板块	待完成
第九阶段	12.1-12.10	完成动态板块	待完成
第十阶段	12.10-12.18	完成灰度测试	待完成
第十一阶段	12.19-12.27	团队工做量整理，公测	待完成
第十二阶段	12.28	团建	待完成

二、团队分工

肯定 alpha 版本须要作哪些事情

状态	分工内容	截止时间	负责人
进行中	注册界面	11月09日	石晓楠
进行中	登陆界面	11月09日	陈启昌
未开始	车辆登记模块	11月23日	刘晓翔
未开始	用户留言模块	11月30日	王焱
未开始	动态板块	12月10日	杨晋南
未开始	其余界面设计	12月10日	宋奕

各成员分工明细及 TODO list

成员姓名	分工	to do list
宋奕	项目经理、后端工程师	1.负责成员分工及组织会议，推进项目进程 。2.负责后端接口及逻辑功能的实现，服务器的部署及数据库的构造
林少惠	UI设计师、团队资源管理师	1.负责项目原型的逻辑功能设计，app的UI设计。2.负责设计及撰写文档，拍摄记录团队进程，沟通先后端
杨蓝婷	UI设计师、团队资源管理师	1.负责项目原型的逻辑功能设计，app的UI设计,2.负责设计及撰写文档，拍摄记录团队进程，沟通先后端
张雨	UI设计师、团队资源管理师	1.负责项目原型的逻辑功能设计，app的UI设计,2.负责设计及撰写文档，拍摄记录团队进程，沟通先后端
陈启昌	前端工程师	负责web端界面的功能实现，及先后端交互
石晓楠	前端工程师	负责web端界面的功能实现，及先后端交互
陈靖雯	前端工程师	负责web端界面的功能实现，及先后端交互
杨晋南	移动端工程师	负责安卓端及iOS端的接口交互，和页面的实现
刘晓翔	移动端工程师	负责安卓端及iOS端的接口交互，和页面的实现
王焱	移动端工程师	负责安卓端及iOS端的接口交互，和页面的实现
刘华一	算法工程师	负责算法学习、设计及开发

燃尽图

三、思惟导图

四、评估贡献比例

撰写需求规格说明书的工做流程

• 项目经理肯定需求规格说明书的内容
  
• 小组开会肯定app界面的各个模块和功能。
• 一部分人先完成说明书的文字部分和原型、UML图等。

• 另外一部分人最后完成PPT制做、PPT演讲准备、整合需求说明书内容。

  组员分工

  任务内容	分工状况及分数
  需求报告文字描述部分	晓楠六、张雨2
  思惟导图	晓楠2
  类图	宋奕2
  ER图	晋南2
  数据字典	晋南4
  外部需求	宋奕4
  状态图、活动图	张雨4
  验收验证标准	张雨2
  整合报告内容、排版	晓楠二、靖雯4
  原型设计	少惠1五、靖雯五、晓楠3
  PPT制做	蓝婷15
  PPT演讲	启昌6
  评审表设计	靖雯1
  评审表汇总、录入	张雨2
  填写评审表和提问	宋奕二、启昌二、晋南二、晓翔二、王焱二、华一二、蓝婷二、少惠二、张雨二、晓楠二、靖雯2
  博客撰写	张雨4
  开会	宋奕二、启昌二、晋南二、晓翔二、王焱二、蓝婷二、少惠二、张雨二、晓楠二、靖雯2
  分工、计算贡献率、提交材料	靖雯3

  组员工做量比例

  姓名	贡献率
  宋奕	10/130=8%
  启昌	10/130=8%
  晋南	10/130=8%
  晓翔	4/130=3%
  王焱	4/130=3%
  华一	2/130=2%
  蓝婷	19/130=15%
  少惠	19/130=15%
  张雨	18/130=14%
  晓楠	16/130=12%
  靖雯	16/130=12%

  五、评审表格设计

  六、UML

  必作图

  用例图

  描述的部分：
  （1）描述了咱们软件必须完成的任务，定义了必须完成的软件功能；
  （2）基本呈现用户与用例之间的具体关系；
  （3）基本表达系统的基本功能；
  （4）基本表达系统的具体行为。
  面临的问题：
  （1）如何具体对用例进行分类，使得用例更加具体；
  （2）如何对用户与不一样用例之间的关系详细分析。
  解决的问题：
  （1）初步获取用户的需求；
  （2）指导测试；
  （3）在整个过程当中对其余工做流起到指导做用。
  

  类图

  活动图

  描述的部分：
  (1)动态生成过程。
  (2)联系车主过程。
  面临的问题：
  （1）面临帐户管理问题。
  （2）面临联系车主问题。如何使用户较为快速的联系到对应的车主。
  解决的问题：
  使用户能够查询到车主，方便快捷的解决难题。
  

  状态图

  【part1】

  描述的部分：描述了用户登陆及未登陆使用的状态。
  面临的问题：面临用户帐号管理的问题。
  解决的问题：
  （1）解决了用户注册登陆流程的问题。
  （2）解决了用户找回密码的问题。
  

  【part2】

  描述的部分：描述了用户寻找车主的状态。
  面临的问题：面临扫描识别及车牌识别的问题。
  解决的问题：
  （1）解决了用户经过扫描车身进行识别的问题。
  （2）解决了用户经过输入车牌号进行识别的问题。
  （3）解决了用户经过本平台寻找车主的问题。
  

  【part3】

  描述的部分：描述了用户动态编辑、展现及评论的状态。
  面临的问题：面临用户添加自定义动态及其显示、评论的问题。
  解决的问题：
  （1）解决了用户自定义建立动态、显示动态的问题。
  （2）解决了用户评论他人动态的问题。
  

  实体关系图

  其余图

  成员成果聚集

• part1

  （1）这里描述的是系统的登陆部分
  （2）这里面临的是实名认证的问题
  （3）咱们经过添加数据库的学生表来解决了这个问题
  
  这个表记录了从1998-2019的学生身份数据。

• part2

  （1）这里描述的是系统的车牌绑定部分
  （2）这里面临的是套牌车的问题
  （3）咱们经过多拍几张照片或者选取特色来解决了这个问题这边增长了两个表
  

  七、工具选择

  ProcessOn在线做图工具

  八、对工具的评价

  ProcessOn是一个在线做图工具的聚合平台，它能够在线画流程图、思惟导图、UI原型图、UML、网络拓扑图、组织结构图等等，高效易用，并且支持团队协做，可多人同时制做。

  九、答辩总结

  本组的现场答辩得分 去除最高总分，最低总分，求平均分（保留2位小数）

  团队组别	第01组	第02组	第03组	第04组	第05组	第06组	第07组	第08组	第09组	第10组	第11组	第12组	本组最终得分
  他组队本组的评分	89	87	79.9	88	86	90	86	85	84	85	81	77	85.09

回答其余小组对本小组的提问

团队组别	提出的问题	回答
第01组	车牌识别提取号码的功能打算怎么实现？本身写算法仍是直接用别人的轮子？	用别人的轮子
第02组	Q1：如何说服用户将本身的车牌信息录入？Q2：以及别人随意查看车主信息彷佛有些不合理？Q3：且替人挪车的收益感受不是那么大，时效性也不高，受众和使用频率也不会很高	A1：这就靠咱们的前期宣传，若是可能的话，咱们会尝试与学校合做，加大用户量；A2：车主的信息是能够自行选择是否进行彻底公开的，相似电话号码，若是车主不想透露，能够经过平台进行联系；A3:咱们会设立奖励机制，若是你正好在求助的用户附近，经过帮他挪车是乐于助人的同时又能够赚的积分，和乐而不为呢
第03组	产品如何盈利，如何鼓励不是车主的其余用户帮忙挪车？	经过发放优惠券和别的商家或者小组合做
第04组	如何可以很及时的通知车主挪车？由于不是每一个人都随时看手机。	因为是推送因此咱们也没办法强制完成
第05组	初期用户量不足的状况下，大家的项目等于没有挪车功能，一个没有功能的应用就算客户使用了，怎么保证它在大家功能成熟前不删了它呢？	咱们的app主要功能是挪车，可是不止这一个功能哦，还能够在平台上发布你的买卖车信息以及若是您不当心将别人车的某些部分弄坏掉能够进行留言之类的哦
第07组	屡次发出挪车消息无人应答，致使用户体验感不好，如何避免？	这个在项目初期是不可能避免的，可是中后期用户总量增长，应该能够缓解
第08组	建议是若是挪的不是本身的车而使用这个软件来帮别人挪车或者经过其它方式，能够收取适当的费用，来增长产品的盈利性	这个建议咱们会归入考虑的，谢谢
第09组	能查看他人那么多信息，信息安全如何保障？	咱们严格控制每条信息得保密，只要设置是保密，他人就看不见的
第10组	未提问...
第11组	获取用户手机号和车牌如何实现，真的会愿意本身填上这些私密信息吗，若是从其余渠道获取，是否是有侵犯我的隐私的问题？	手机号是能够有隐藏的选项的，若是您不肯意将本身的手机号公布出来，能够隐藏起来
第12组	Q1:电话加密如何实现？Q2:基于网络电话仍是传统电路域电话？Q3:电路域电话存在一段传输没法加密，网络电话如何保证用户能接到	A1: 电话加密是基于阿里云的功能；A2:基于网络电话；A3:阿里云对用户功能应该是有所保障

根据答辩中其余组提出的意见和建议修改完善本组需求分析报告，并标明修改之处

针对永福所说的缩进问题，有作修改


对于token类型的改进

十、需求说明书

十一、遇到的困难及解决方法

困难描述

对《软件需求规格说明书》较为陌生，不知从何入手

作过哪些尝试

咱们认真阅读了做业中给出的 checklist，而后请教了以前的学长学姐。并阅读了一些前辈的报告，最终肯定出框架，而后开始分工撰写。

是否解决

是

有何收获

了解了《软件需求规格说明书》的框架和内容，明白了团队协做的重要性，并体会到其中的乐趣。

十二、psp

---

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

1三、学习进度条

---

第N周	新增代码（行）	累积代码（行）	本周学习耗时（小时）	累积学习耗时（小时）	重要成长
1	0	0	10	10	作前期准备工做
2	0	0	12	22	撰写选题报告
3	0	0	13	35	撰写需求报告