• 项目需求分析与原型模型设计


    项目需求分析与原型模型设计#


    0313026 阙长林
    031302606 陈少扬


    1.需求分析

    从用户类型来看,该项目的用户可分为负责人、教师两种。经过分析,用户的“痛点”在于使用功能分散的途径来实现开课报课需求。
    负责人与教师之间通过邮箱发送开课计划书,过程繁琐,文件冗余,并且过于分散;没有进行功能的集成,容易出错,不易整合。从负责人的角度来看,该类用户将大量时间花费在了对每个教师的邮箱发送一份含开课计划书的Excel文件,而且无法设定期限,如果想对开课内容修改,则需要重新发送计划书。以及在收到回复后,又从每个老师的回复邮件中手动提取文件,更费时的时,将如此众多的Excel进行汇总,其工作量将非常大,而且意义不大。从教师的角度出发,那么每次开课都需要在表格上填完在通过邮箱回复给负责人,假如需要修改,又得重新填写表格,再重新发送,用户体验非常差。
    如果我是负责人,我希望我不必用邮件一个个发送邮件,最好是一键发送简要的消息通知,然后教师在特定统一的地方填写;如果我是教师,我希望无需下载文件然后打开,而是在线直接完成。
    用户的需求归根到底就是希望将中间这些步骤集成封装起来,重点优化:

    1. 群发邮件
    2. 汇总课表
    3. 用户体验
      由此,我们将整个过程分为以下几个功能模块:

    负责人:
    -群发通知教师
    -增删改开课计划
    -生成开课汇总表
    教师:
    -开课课程增删改

    2.方案设计与原型模型

    原型开发工具采用Axure RP 7.0
    整体方案前期采用网页形式实现,并收集用户建议,试点运行,为版本改进与功能拓展做准备,首先基本满足客户目前需求。考虑到移动终端的快速发展,应积极筹备此项目的移动App开发。网页版方案具体如下
    4. 登录界面
    首先,用户在登录之后,系统自动区分用户类型,账号以“T”开头为教师,以“M”开头为管理员,即负责人。以此来区分不同角色的权限,初步设计界面如下

    1. 负责人界面
      负责人主界面中左侧有一个侧边栏,为该角色的权限,有排课通知、排课计划以及课程汇总。
      其中,点击进入“排课通知”界面,有收件人、正文两个输入框。收件人邮箱地址可从右侧通讯录中单选或者全选。收件人的邮箱地址可由教师个人信息表中提取出来,界面如下

    排课计划界面只有在每学期排课计划时间内开放,否则提示“当前不是排课时间”,主要内容为一个基本表,负责人可以手动添加单元行,并且在每个单元格都有下拉框,或者手动输入进行匹配,快捷、准确,如图:

    通过数据库操作,可免去负责人手动汇总课表信息,节省大量时间。此界面为一个基本表,合并教师回复内容。

    1. 教师界面
      在规定时间内,教师可进入选课界面,只要点击前面单选按钮就可输入起止周、备注,并且可以修改、查看,并用红字在表格上方提醒截止时间

    3.预期规划

    功能界面采用web形式,搭建Tomcat以及MySql数据库,使用HTML+JSP+Java Web语言实现。团队将分成前端与后台两部分进行开发,并与客户保持经常性交流。考虑用户人数比较多,会在正式发布之前进行模拟使用来,beat版面向部分人群开放进行测试,收取数据与建议。整体方案由于采用网页形式,用户无需下载本地客户端,不仅有利于开发版本改进,而且网页界面操作对于大多数用户来说简便易懂,我们也会在上面作进一步的功能引导。在初步做完该项目的移动端调查并获取市场需求后,会进一步开发移动App,初步决定主要面向教师用户。

    4.小结

    以上开发过程参照《构建之法》第八章NABCD模型,初次接触,尚没有实践来深入了解,写的内容也不清晰,还是得再多去理解。

    另附PDF链接:PDF

  • 相关阅读:
    菜鸟系列docker——docker镜像下(5)
    菜鸟系列docker——docker镜像中(4)
    菜鸟系列docker——docker镜像上(3)
    菜鸟系列docker——docker仓库(2)
    菜鸟系列docker——docker基本概念(1)
    Postman工具内容梳理
    Fiddler抓包手机APP失败的处理
    微信
    微信文本的爬取
    如何写活类的装饰器
  • 原文地址:https://www.cnblogs.com/YohKin/p/4830091.html
Copyright © 2020-2023  润新知