需求分析及原型设计

作者031402209 黄伟炜031402230 张建明

需求分析

N:Need

  1. 选导师流程复杂不透明.需要班级先收集,后汇总给年级负责人,再汇总给系负责人
  2. 需要手动收集数据.调整分配.浪费时间和精力
  3. 老师和学生存在被动分配.老师无法选择学生.学生也可能选不到自己想要的老师
  4. 老师希望控制学生人数
  5. 学生希望了解老师课题和研究方向
  6. 老师和学生互相选择

A:Approach

  1. 移动端,程序设计在安卓
  2. 时间制,在规定时间内完成选择.类似教务处选课系统
  3. 多轮选择,类似教务处系统
  4. 互查信息,学生老师双向查看个人资料

B:Benefit

  1. 移动端简单便捷.现在比较适合使用的
  2. 不必争分夺秒.有充足的时间考虑
  3. 没选中下次还可以选择.实在不行也只能随机了(这也是没办法的事情咯)
  4. 知己知彼.加深老师和学生的相互了解

C:Competitors

  1. 千篇一律,都差不多
  2. 网页,安卓,ios都差不多
  3. 这个类似教务处选课.我觉得挺好的
  4. 安排多次选择.给学生更多的机会.这是不错的
  5. 现在已有的校园应用大用户量大,它们已经实现了一些学生需要的功能,如选课、查成绩等。它们的竞争力最强。

D:Delivery

这个估计没啥好推广的了,每年用一次。最好作为现在校园应用的补充功能模块

原型设计

栋哥说不能队内结对,于是就找到了班上的建明。然后,我们就开始了热烈的讨论。在几番他讨论之后,我们确定了需求。于是,开工

  • 打草图
  • 使用Axure Rp设计
  • 在原型设计方面,我们尝试了几款原型开发软件。其中,Fluid UI、和 墨刀 是网页应用,比较便捷,但是使用起来比较卡顿。最后决定采用AxureRp
  • 注册和登陆界面: 因为,本次原型设计和主要功能师实现,学生和导师之间的双向选择。这个功能考虑应用时效性,这个应用不适合作为独立应用开发。最好是,整合到现有的校园应用(福大助手福大易班以及福大教务通)中去,作为它们功能的补充。因此,注册和登录界面可以忽略。而将精力放在要实现的功能模块
  • 学生端:本着去繁从简的原则,登录之后的学生界面,有选择导师的界面.以及对每个老师的资料描述,学生只需要在规定的时间内选好自己喜欢的导师即可.
  • 老师端:本着去繁从简的原则,登录之后的老师有修改界面.选择学生界面.以及对每个学生的资料描述老师先填好想要收的学生数量,已经学生选择导师之后,选择自己喜欢的学生即可

学生端

导师端

效能分析和PSP:

效能分析:

  • 对象:移动端程序
  • 目标:去繁从简
  • 预测:可能出现的问题就是如何获取学生老师的数据。以及使用何种算法,来分配导师。同时,让导师也选中满意的学生。

PSP

计划

使用 java 语言进行服务器应用开发不熟悉,预计要四周完成开发

开发

  • 分析需求。找到学生和老师之间互相选择的痛点。
  • 生成设计文档
  • 设计复审。初次,先讨论定好要实现的功能,做出原型。再对原型进行审核,对原型进行修改完善
  • 代码规范。主要代码是在 android 端完成。而且 google android 的代码规范很优秀。因此,采用 google java 的编程规范(风格)
  • 具体设计。按照原型设计进行实际编码开发
  • 代码复审。对开发的代码进行复审,对代码进行重构。有利于代码维护和迭代
  • 测试。进行单元测试

记录用时

记录流程中每一步的具体用时

测试报告

做真实的测试,获取测试结果并分析

总结&改进

完成任务后,对整个过程的遇到的困难和出现困难的原因进行分析和总结。然后,针对每个困难提出改进的计划。

小结

  • 首次设计原型,对原型软件使用不熟悉。为了尽快实现原型,使用“暴力”`堆各种矩形和图标的方法,缺少交互效果。还需要深入学习使用
  • 最后安利一下,windows 平台下的 markdown 神器 typora
  • 作业附件:需求分析及原型设计.pdf
posted @ 2016-09-17 11:41  echo1995  阅读(687)  评论(4编辑  收藏  举报