Part 0. 开篇
WeEdit需求规格说明书
第三次软工实践答辩材料
一分钟演示视频
组长博客链接
Part 1. 计划安排
- 团队所有成员共同讨论各部分实现功能,共有5个功能,分别由5名成员负责各自的后端接口,2名同学负责前端界面,1名同学负责美工;
- 在11月8日前,美工组同学先完成界面主体设计,然后交由各参数于前端小组;
- 在11月8日——11月15日期间,前端小组根据美工小组同学的设计,完成前端的编程,与此同时,后端组自发讨论学习各自功能的实现算法;
- 在11月15日——11月20日期间,后端组完成各自的后端功能实现,并与前端接口相连接;
- 在11月20日——11月25日期间,团队成员组织探讨合并该项目,对于有缺陷或者未能实现的功能集中讨论,改善项目。
- 线上推广
- 在本院、校学生会以及各个班级组织推广免费使用
- 线下推广
- 与福建省其他高校一起推广使用,体验高效便捷的微信办公软件服务
- 另外,在办公区域,通过添加小程序等服务,赠送相关办公用品
Part 2. 项目logo
因为我们的项目名称是WeEdit,所以我们的LOGO象形E,即办公的意思,同时主体部分为共享的标志,符合我们项目的立意。另外,用交流符号“...”以及铅笔形象地结合,展现出我们的主推功能———“共享编辑”。底色设定为绿色,主要是为了契合微信的图标底色,我们竭尽全力地使这个小程序与微信进一步的贴切,减少用户的使用难度,方便使用。
Part 3. 思维导图
Part 4. 团队中个人的贡献比例
图中已经细分了各个成员在本次的团队实践任务中的具体工作分工,并以工作量的比例进行分数的评定,详细见图。本次的需求规格说明书具体参照了“GB-T 9385-2008,《计算机软件需求规格说明规范》”,以大纲为框架逐渐完善内部内容,后续经审核补充完成最终的文档。
姓名 | 得分(百分制比例%) |
---|---|
柯奇豪 | 18.575 |
蒋雄 | 8.675 |
黄志铭 | 7.775 |
黄毓明 | 14.975 |
林翔宇 | 16.775 |
丁水源 | 14.975 |
杨礼亮 | 16.775 |
陈超 | 1.475 |
Part 5. 评审表格设计
Part 6. 答辩总结
Q&A
- 第一组的问题
Q1:在宣传中讲到应用的文档编辑倾向于“轻量化的编辑”,这与现有的移动端文档编辑应用相比有独到的竞争力吗?
A1: 我们主推微信群聊群体(尤其针对经常使用微信群聊进行办公的上班族、社团部门等),简单编辑易上手和链式体验就是我们的竞争力。
Q2:产品比起之前的需求分析又增添了新功能,能否阐述一下产品的核心功能是?
A2: 我们的核心功能还是共享编辑。
Q3:是否对文档协同编辑时可能出现的问题制定相应的验收标准(比如文档在多端编辑时没有同步更新)
A3: 后期会制定一个标准,及时更新,谢谢。
- 第二组的问题
Q1:市面上有很多做的很成熟且使用很方便的竞品,其功能也很丰富,为什么客户要选择你们的?
A1: 首先,微信小程序便于使用和分享,其次捕获定位信息的功能能够方便用户们的使用而不同于其他软件的选取地点。
Q2:你们产品为小程序且介绍的功能较多,加上小程序本身有局限,能够真正实现你们所介绍的功能吗?
A2: 小程序开发内部提供有丰富的接口,就目前了解而言是可以实现的。
Q3:是否有考虑增加更佳新颖功能或界面设计更加突出来吸引用户使用?
A3:暂时没有,我们认为能使用户更加便捷快速的去熟悉使用就是我们产品推出的初衷。
- 第四组的问题
Q1:请问你们开发的产品相比于如腾讯文档这类多人实时在线编辑的软件,存在有哪些附加功能呢,还是仅是以微信小程序形式来实现?
A1:我们还有现场签到、发布通知等一系列功能,可以形成一个链式的关联整体使用。
Q2:微信小程序能实现的功能存在局限性,是否能有效完成该项目呢?
A2: 就目前而言是可以完成的。
Q3: 仅依赖于微信小程序是否显得拓展性不够,扩展成APP的形式是否会效果更好呢?
A3: 我们认为微信小程序本身以其简单便捷的优点会给产品带来更大的吸引力,拓展性方面会在可行的范围内,再进一步的去深入,尽可能的在完成既定规划的情形下去丰富拓展。
- 第五组的问题
Q1:既然是链式功能服务,有没有考虑做成app,可供多种社交账号进行登录使用?并且不同账号之间的文件可以共享编辑?
A1: 我们暂时主要是为了微信用户来考虑,因为从目前来看,微信这边市场需求比较大,办公人群居多。
Q2:文档编辑授权问题,发起人能否进行批量授权?
A2: 文档本身是以一种交互反馈的形式来共享编辑,因此批量授权的实现是在我们考虑范围中的。
Q3:现场签到的防止虚拟定位是否繁琐了点,能否有更加高效的签到方式?
A3: 目前为止这是我们想到的一个解决虚拟定位的方式之一,后续会再进一步去深入了解与学习,寻找更便捷一点的防范措施,感谢你们的建议。
- 第六组的问题
Q1:你好,请问1分钟的视频用来展示原型的操作时间过短,且没有声音,观看者很难看清楚具体功能,是否可以考虑采用截图置于PPT中由演讲者大致讲解功能模块?
A1: 视频的展示主要是为了引导用户的使用,达到一个过程式的介绍,关于时间过短(题目规定)以及无声(视频制作的不足)的问题我们是可以后续修改的,你们提出的建议可以接收,谢谢指出不足。
Q2:你好,请问签到功能是否能够解决代签问题?
A2: 我们在介绍中有提到,目前给出的一个解决方案是配合网络接入地址进行防止虚拟定位的问题,后续会进一步去了解使用其他更便捷的方法。
Q3:你好,请问PPT内容相对比较少,是否可以考虑丰富PPT内容? 如增加原型的界面截图。
A3: 本次的ppt主要介绍的主题均已经点出,已经满足基础性的要求,关于内容较少的问题,我们后续会注意的。
- 第七组的问题
Q1:你们提到签到的时候会限制IP或者WIFI,不知道这个方法的可行性有多高呢?是否可以给出一些例证来说明?
A1: 举例你到一定的地点使用上此IP,然后我对此进行判断后抉择签到授权问题,当你在其他的IP地址上签到时因为不满足要求则视为无效签到地址。可行性目前的了解是可以做到的。
Q2:”收集想法“这个功能和在朋友圈发一条消息或者在QQ空间发说说有什么差别?
A2: 不太能够理解你们提问的目的,但是作为本产品的一个辅助性功能,收集想法本身对使用群体没有多大的约束,它本身作为一种放松心态、随时发送随机回答的方式,满足工作闲暇之余的放松。
Q3:”共享编辑“这个功能是否有历史修改记录,能实现版本回退?如果回退到较早的一个版本,这个版本之后的改动是否会一直保存着,还说是在这次操作里还能保留,但退出本次操作后,那些版本就会被清空?
A3: 会考虑增设记录的保存,即可以退回使用,如果是愿意回退到上一个版本的话,自然该版本后的操作将视为失效不予记录。
- 第八组的问题
Q1:产品与其他同类型产品拉开距离的核心竞争力是什么?
A1: 我们使用微信小程序,依托微信潜在的巨大办公市场,能够给用户更便捷的办公体验。
Q2:对于协同编辑功能有没有考虑到在线用户数量会暴增,那会不会造成编辑的不稳定,有什么对策解决?
A2: 目前我们考虑的是小群体用户,即一个部门或者一个小团队的内部使用,针对于这个,我们后续也会考虑解决的,谢谢。
Q3:对于签到,为防止代签之类的问题,是不是会用gps定位功能,但若是组员没有开启这个功能,那这样不就有漏网之鱼了吗?
A3: 本身该功能就是为了精准签到设定的,所以对于使用者是有要求的,你所提到的问题不属于我们产品本身该考虑的问题。
- 第九组的问题
Q1:既然是多人编辑文档,以微信小程序实现的话,在手机端会不会不方便编辑文档?
A1: 我们会考虑尽可能的去使得用户满意并愿意使用我们的小程序,关于不方便操作的问题我们正在设法简约操作,谢谢你们给予的意见。
Q2:如果在电脑端实现,那么该产品跟目前以有的产品相比较,你觉得你们的优势在哪里?
A2: 可以进行配套使用,因为主打的群体面向微信用户,目前市面上的公司等等大型组织一般都更经常的使用微信,因此其存在的意义就是以其方便快捷来拉拢这些潜在的既有用户,拓展更多的新用户涌入。
Q3:微信小程序的编辑文档界面是否真的能方便用户的使用,有没有考虑调查一下用户的使用感受?
A3: 可以在后续进行若干次产品调研,提升使用质量。
Final Score:
小组 | 评分 |
---|---|
第一组 | 82 |
第二组 | 77 |
第三组 | 77 |
第四组 | 87 |
第五组 | 63 |
第六组 | 82 |
第七组 | 79 |
第八组 | 76 |
第九组 | 90 |
最低分 | 63(第五组) |
最高分 | 90(第九组) |
有效分数 | 82,77,77,87,82,79,76 |
最终平均得分 | 80 |
Part 7. 软件需求规格说明书(有大幅度的丰富改动)
WeEdit需求规格说明书
之前提到过的关于格式上的问题已经全部进行了修改,包括页码、部分未处理好的文字阴影等。同时在内容上进行了大幅度的增加,包括重新绘制实体关系图,增加数据流图以及数据字典等
Part 8.
PSP表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 0 | 0 |
· Estimate | · 估计这个任务需要多少时间 | 80 | 75 |
Development | 开发 | 0 | 0 |
· Analysis | · 需求分析 (包括学习新技术) | 10 | 10 |
· Design Spec | · 生成设计文档 | 0 | 0 |
· Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
· Design | · 具体设计 | 60 | 60 |
· Coding | · 具体编码 | 0 | 0 |
· Code Review | · 代码复审 | 0 | 0 |
· Test | · 测试(自我测试,修改代码,提交修改) | 0 | 0 |
Reporting | 报告 | ||
· Test Report | · 测试报告 | 0 | 0 |
· Size Measurement | · 计算工作量 | 5 | 5 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 0 | 0 |
合计 | 75 | 75 |
学习进度条
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
1 | 0 | 0 | 1 | 1 | |
2 | 100 | 100 | 7 | 8 | 学会了HashMap的排序 |
3 | 0 | 100 | 7 | 15 | 学了NABCD模型 |
4 | 0 | 0 | 2 | 17 | 第1次与别人合作 |
5 | 100 | 200 | 10 | 27 | 学会了简单地爬取网页信息 |
6 | 0 | 200 | 2 | 29 | 第1次团队合作 |
7 | 0 | 200 | 2 | 31 | 学了UML设计,画了一点活动图和泳道图 |
8 | 0 | 200 | 2 | 33 | 学会了简单地分析需求 |