目录html
组长博客前端
前端
mysql
后端
android
(由于整个团队项目的ddl与完成时间未定,因此此处只是本次“需求分析报告”的燃尽图)sql
直观充分地展现了借呗的两个核心业务:
活动室的申请和管理、我的仓库里物品的租借和管理。
数据库
“个人”页面主要分为:我租借的、我管理的、信用度三大部分。
我租借的:包含用户所租借活动室或物品的详细信息、到期时间,同时也包含归还与评价
我管理的:相似于“我租借的”,包含所借物品的信息和被租用次数
信用度:此功能主要用于对用户的诚信程度进行量化评估
后端
为用户提供租用申请的消息、学校或学院的重要通知。
而且为每位用户提供不一样的数据分析,让用户能充分了解本身的物品使用状况。
安全
“社区”功能是咱们为用户提供的一个社交平台,
让用户在租借/使用物品的同时能参与到不一样的社交活动,
同时也能让不一样用户的各类闲置物品充分流通。
app
类图
1.描述的是app的功能方面内容
2.仍需改进:项目模块定义的不够清晰 各个类之间的联系较为繁琐
3.统一了参数,整体设计,提升先后端开发的效率
工具
用例图
1.描述了借呗app的各部分功能以及对各部份内容的具体化。
2.若是按照用户习惯来进行排版,提升使用的友好性
3.让各个用户使用的功能更加直观,防止了用户权限混杂的问题
状态图
1.描述的是物品的各个状态
2.仍需改进:每一个部分的具体转化还不够彻底,须要细致优化。
3.直观的体现了物品的状态,让后面的设计思路更加清晰
活动图
1.描述了用户借入和租出的后续操做和结果。
2.仍需改进:更多的功能和操做难以在图中表示出来
3.直观的表示出物品租借的步骤
实体关系图
1主要描述的是系统的概念结构设计的部分。
2实体的决定、实体属性的决定、实体之间的关系(包括了一对一,一对多,多对一,多对多)
3各实体属性的决定和实体间的关系和关联
亿图软件
这个软件的能够做不少的图,并且将各类图分类,有不少东西能够直接用,不过因为没有下载破解版因此导出的图片不清晰且有水印,能够去百度使用破解版。
51.72分
1.便利性仍是挺不错的,但愿重点考虑下安全性和互动性,能够往社交方面走一走(第二组)
安全性的问题咱们考虑用设置押金来解决;借呗有设置“社区”这个功能,用以知足不一样用户的社交需求。
2.各个部门管理的不止有活动室,还有一些属于他们的物资,好比体育部就有记分牌之类的,能够考虑让部门挂出空闲的物资来出借(第三组)
对于部门来讲的闲置物资,可让管理人员以部门的名义创建我的帐号来进行出借。
3.未提问(第四组)
...
4.是否能够对不想要出借的部门进行奖励或者合做来增长本身APP的可借数量,不止活动室,不少部门有他们独有的物资。(第五组)
咱们对于活动室的管理首先要跟学院那边商定好,对于愿意出借活动室的部门会以奖励部员信用度和可借数量增长的方式进行合做(信用度越高,可借物品数量越多)
5.大家如何作到获取各个部门活动室以及其余场地的租借权利?(第六组)
在借呗上线之前,会先与学院和相关老师进行沟通来进行活动室的协调
6.大家数据库到底是mysql仍是sql server(第七组)
mysql
7.如何确保借用出去的物品或者是活动室的完整度,以及软件是如何进行盈利的?(第八组)
用户在出借和归还的时候都须要对活动室或者物品上传照片来确保完整度;至于盈利问题,平台会在须要租金的物品的出借成功时,收取小部分佣金。
8.对于某些已经被主席团分配给学院各个部门的活动室,如何跟相关的部门负责人协调,以确保有多方同时使用同一个活动室而形成的不便?(第九组)
咱们会协调各个部门,经过奖励的方式让部门出借活动室;同时在发布出借活动室消息的时候,租借者能够选择本身独用或者在“社区”中发布消息招揽你们共同使用。
9.与学院、老师的合做有具体可行的方案吗?(第十组)
在借呗上线之前,会先与学院和相关老师进行协商来进行活动室的协调,具体方案还正在考虑中。
10.活动室的管理是否要和学院先作好沟通(第十一组)
在借呗上线之前,会先与学院和相关老师进行沟通来进行活动室的协调
11.如何避免具备活动室钥匙的人出租活动室谋取私利?以及活动室原有物资的安全问题(第十二组)
对于出租活动室,平台是不设置租金选项的,即租借活动室只须要申请不须要租金;对于安全问题,则经过在租借和归还时上传照片来解决。
①调整了表格框线的问题
②修改了环境要求和软件接口
③删除了一些没必要要的内容
《需求规格说明书》
(提取码:ny78)
困难描述: 没有android开发经验,得边学边写。由于没有实际项目经验,分工不是太明确
作过哪些尝试: 阅读开发文档和书籍;询问有经验的人
是否解决: 是
有何收获: 有了必定的android开发能力
困难描述:需求报告工做量大,需求复杂繁多,难以完成;需求报告排版格式要求细致繁复,修改复杂
作过哪些尝试:百度搜索相关博客和文档阅读了解
是否解决:是
有何收获:经过博客和文档的阅读,训练了阅读博客和文档的能力;学会合理分配文档工做,实现了最后版本的需求报告
PSP2.1 | Personal Software Process Stages | 预估耗时 (小时) |
实际耗时 (小时) |
---|---|---|---|
Planning | 计划 | 12 | 15 |
· Estimate | · 估计这个任务须要多少时间 | 12 | 15 |
Development | 开发 | 2 | 2 |
· Analysis | · 需求分析 (包括学习新技术) | 5 | 5 |
· Design | · 生成设计文档 | 5 | 5 |
· Design Review | · 设计复审 | 0.2 | 0.3 |
· Coding Standard | · 代码规范 (为目前的开发制定或选择合适的规范) | 0 | 0 |
· Design | · 具体设计 | 2 | 3 |
· Coding | · 具体编码 | 0 | 0 |
· Code Review | · 代码复审 | 0 | 0 |
· Test | · 测试(自我测试,修改代码,提交修改) | 0 | 0 |
Reporting | 报告 | 0 | 0 |
· Test Report | · 测试报告 | 0 | 0 |
· Size Measurement | · 计算工做量 | 0.1 | 0.1 |
· Postmortem & Process Improvement Plan | · 过后总结, 并提出改进计划 | 0.5 | 0.5 |
· 合计 | 14.8 | 15.9 |
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
1 | 0 | 0 | 15 | 15 | 完善了项目的需求,对本次团队项目有了更深的理解 |