项目需求分析答辩总结

前言


本组对其他各组评审结果

  • |编号 | 团队名称 | 项目名称 |报告格式/20| 演示内容/20 |答辩内容/20 | PPT制作/20| 演讲/20 | 总分/100 |
    |-------------------|----------------------------------|----------------------------------|----------------|------------------|-----------------|-----------------|--------------|---------------|
    | 1 | 天机组 | 指尖加密 | 15.0 | 13.6 | 13.6 | 12.8 | 15.6 | 70.6 |
    | 3 | 日不落战队 | 小葵日记 | 16.7 | 17.4 | 17.0 | 16.6 | 16.2 | 83.9 |
    | 4 | 像我这么能打的还有五个 | WanderLand | 15.0 | 15.8 | 17.2 | 15.0 | 15.4 | 78.4 |
    | 5 | 洛基小队 | START | 14.3 | 12.8 | 14.6 | 15.2 | 15.0 | 71.9 |
    | 6 | Boy Next Door | WEB账簿管家应用 | 14.0 | 15.4 | 14.0 | 14.2 | 14.0 | 71.6 |
    | 7 | Massivehard | 上一次 | 12.0 | 10.2 | 8.00 | 10.4 | 12.8 | 53.4 |
  • |编号 | 团队名称 | 项目名称 | 优点 | 存在问题 | 建议 |
    |-------------------|----------------------------------|----------------------------------|-----------------|--------------|-------------|
    | 1 | 天机组 | 指尖加密 | 增加了救援代码,考虑的问题更加全面 | 指纹识别容错率问题为解决;没有打败同类竞品的优势;泄密问题没有很好的考虑 | 演讲的人声音很好听,但能不能更有激情一点,有点让人犯困 |
    | 2 | PMS | Your eyes | 产品结构完整 | 原型界面未能很好表现 | 算法设计需要注意推进 |
    | 3 | 日不落战队 | 小葵日记 | 功能齐全,考虑的问题也比较全面。 | 样本数据不够,信任度分析没有太具体;500字左右就占了1.9M的内存,是不是过于大;对未知情况无良好的预防 | 开发功能很多,但技术难度不高,希望达到项目预期目标后能够继续完善 |
    | 4 | 像我这么能打的还有五个 | WanderLand | 用户人群明确且易于交流 | 怎么解决刷榜的问题;缺乏公信力;受众面比较窄 | 希望成品不仅能够应用于本校,多校推广也有利于提高产品公信力,以便实现为影评面试提供数据支撑的设想;下次展示能不能翻出新花样,不要每次都用上次用过的东西 |
    | 5 | 洛基小队 | START | 游戏按局进行,花费玩家时间较少,利用碎片化时间 | 游戏介绍冗长、没有抓住重点;创新较差、大致以饥荒为模板;演讲中没有讲清楚自己吸引人亮点;没有原型 | 美工制作与脚本开发应有良好的权重 |
    | 6 | Boy Next Door | WEB账簿管家应用 | 相较于之前,定位更加明确 | 网页端与移动端的同步问题;接口问题还没有很好的解决,存在诸多的隐患;博客上文档链接失效,不知道具体原因;网页端用户使用不方便 | 面向客户做一个更真实的需求调查;博客的需求报告链接失效了,希望能够更新一下 |
    | 7 | Massivehard | 上一次 | 产品有创意和人情味 | 弹窗对用户不友好;演讲产品功能不清晰,胡编乱造功能;队伍内没有达成对功能的一致认知;ppt过于简单,太多的文字;如何判断上次;使用界限模糊;用户粘性低 | ppt制作技能亟需提升,演讲中的许多应用情景,ppt中都没有体现出来,口述听不详尽;到底有什么功能组内统一一下,演讲和答辩内容对不上;功能需求与实际设计要有互为考量,很多功能想象出来,但却无法实现,最终发布版本可能遭遇史上最惨烈的阉割! |

其他各组对本组的评分

  • |编号 | 团队名称 | 项目名称 | 报告格式 | 演示内容 | 答辩内容 | PPT制作 | 演讲 | 总分/100 |
    |-------------------|----------------------------------|----------------------------------|--------------|-------------|--------------|--------------|--------|--------------|
    | 1 | 天机组 | 指尖加密 | 80.0 | 80.0 | | 80.0 | 80.0 | 80.0 |
    | 2 | PMS | Your eyes | 16.0 | 16.0 | 16.6 | 16.4 | 17.0 | 82.0 |
    | 3 | 日不落战队 | 小葵日记 | 16.0 | 17.0 | 17.0 | 17.0 | 15.0 | 82.0 |
    | 4 | 像我这么能打的还有五个 | WanderLand | 8.0 | 26.0 | 25.0 | 13.0 | 12.0 | 84.0 |
    | 5 | 洛基小队 | START | 16.0 | 17.0 | 16.0 | 16.0 | 17.0| 81.0 |
    | 6 | Boy Next Door | WEB账簿管家应用 | 15.5 | 16.0 | 16.0 | 15.5 | 15.0| 78.0 |
    | 7 | Massivehard | 上一次 | 14.0 | 15.0 | 16.0 | 17.0 | 18.0| 80.0 |
    | | 去除最高总分、最低总分 | 平均分 | | | | | | 81.0 |

来自各组对本组的提问

  • 天机组

    • Q:请问视频是要传输到服务器进行处理还是就在本地处理?
    • A:本学期目标完成本地处理。
    • Q:是一个类似web界面的软件还是说一个web端的产品?
    • A:产品本身为基于pc端的软件,但我们计划以web的方式作为展示给客户的前端。
    • Q:能否直接与实时监控连接使用,而不是人工导入视频?
    • A:可以。我们的界面原型在首页就体现出两个入口——实时检测和历史回溯,对于实时检测,我们能够直接调取监控摄像头,获取当前视频画面。
  • 日不落战队

    • Q:答辩时说到90%的识别成功率很好实现,那是否意味着可复制性较强?
    • A:90%的检测准确率是基于非密集无遮蔽的场景,这种场景识别难度低是可预见的,但并不意味着可复制性就强。检测技术的难度在于其在密集的、目标物互相遮蔽的情形下,如何对二值掩模图像的连通区域进行目标分割与检测。
    • Q:与市面上现有的类似产品相比,请问有什么优势?
    • A:据调查,市面上已有的,如成都臻识等,动辄几万的摄像头、地感线圈、服务器和其他硬件费用,花费巨大,而我们的产品的是轻资产的产品,用户只需要拥有摄像头,就能用我们的设备,比较高性价比。
    • Q:请问将如何击败未来潜在的竞争对手?
    • A:所有的产品、项目都是在竞争中求生存,在荒漠中开拓。我们会以实验室产品为基调,努力去提升我们产品的性能、知名度,以求得生存,进而去与其他产品争夺(虽然很难,但梦想总得有不是吗)。
  • 像我这么能打的还有五个

    • Q:有没有考虑过产品的实用性,和其他很强大的团队相比,该产品的优点在哪,如何去与其他产品竞争?
    • A:监控市场的蛋糕很大,而没有那个团队能一口吃成胖子。我们当前的垂直市场是针对用户对流量统计与路况分析方面的需求,利用本产品轻资产的特性,完成对已有硬件的服务升级,这是我们的优势所在。
    • Q:Web端不能离线操作吧,有没有想过做pc端?
    • A:产品本身为基于pc端的软件,直接对本地文件进行操作,无需联网,应当为表述问题,我们只是以web的方式作为展示给客户的前端。
    • Q:该产品的内测用户是哪些,有没有考虑如果没有用户愿意接收这个产品该怎么办?
    • A:首先,这不是一个没有市场的产品;其次,我们的项目作为实验室前置项目的补充,主要的目的是将功能增加到已有的项目中,而我们的前置项目已有了测试用户。
  • 洛基小队

    • Q:是否已经已经就软件试运行阶段的目标用户达成了合作?
    • A:我们的项目作为实验室前置项目的补充,主要的目的是将功能增加到已有的项目中。
    • Q:能否体现出足够的让自己能在同类软件中脱颖而出的优势?
    • A:我们的产品具有轻资产的特性,无需配套硬件或服务器,只需在用户已有的监控摄像头基础上进行服务升级。
    • Q:除了主要功能,有没有考虑过添加一些提高用户体验的小功能?
    • A:有的,我们在原有输出流量信息摘要的基础上,增加了热力图显示,帮助用户更直观地感受哪里的流量大、哪里的流量小、人车的流动趋势等。
  • Boy Next Door

    • Q:识别的准确率是如何确定的?
    • A:我们主要参考了国内高校论文,论文测试大多基于白天光线充足的场景下,通过人流车流在70%的时间内为非密集的情形,在人流车流密度小的情况下,平均可以达到95%的准确率,在密度较大的情况下有85%左右的准确率,考虑到本学期的时间因素,可能没有充足时间完善算法中关于遮蔽情况图像分割效果的部分,故将团队目标下调至70%,但这只是最低目标,我们有可能做得更好。
    • Q:项目正式版的第一批交付用户是谁?
    • A:我们的项目作为实验室前置项目的补充,主要的目的是将功能增加到已有的项目中。
    • Q:使用现实中的世界摄像头做过多少次实地测试?
    • A:小组算法仍在完善中,尚未形成可应用程序,暂时无法使用摄像头进行测试。
  • Massivehard

    • Q:原型界面未能很好展示
    • A:我们将原型界面放在了宣传视频中,没想到宣传视频并不在演讲时播放,于是演讲的同学只好打开我们的项目需求报告进行讲解,确实缺乏一定条理性。如果感兴趣的话可以看看我们组的需求报告、宣传视频或是博客UML设计
    • Q:软件是web端还是os端?
    • A:在课堂展示中,我们说明产品最终将以web形式面向用户,但产品本身为基于pc端的软件,我们只是以web的方式作为展示给客户的前端。关于界面问题,团队对此做出了一些变更,可以下拉滑块到达博客底部查看。
    • Q:软件后期是如何将功能整合到一起的?
    • A:WBS可以使你了解我们的算法组成,欢迎移步博客UML设计查看。

课后讨论对小组计划做出如下修改

  • 问题:我们最终要使用web实现界面吗?
    • 某A:web操纵本地文件……我觉得有点画蛇添足……

    • 某B:web界面实现交互性会比桌面版好吧,而且现在响应式蛮火的,不过事件反馈会很多吧。

    • 某C:本来我想要速成QT的……pc程序软件比较容易实现嘛

    • 某D:web的客户体验差些吧,页面切换什么的响应速度慢一些

    • 某E:啊……那承认一波错误吧。

      综上,虽然不知道当初究竟是怎么敲定的web方式界面,但出于对实现便易性与开发周期的考虑,本组决定用桌面版的pc应用,代替原计划的web方式。
      PS:不影响原型。

原文地址:https://www.cnblogs.com/SoShun/p/7750925.html