第五次作业--原型设计

第五次作业--原型设计

成员: 张峻雄 031502539 陈非易 031502504
——————————————————————————
PDF附件https://pan.baidu.com/s/1qYRuCva


关于题目的初步想法:
-这个应用设计的目的是让部门更够更有效率的筛选符合条件的部员,同时让学生和部门能够得到对等而充分的信息


NABCD模型:

Need

  • 部门需要更有效率的筛选部员同时学生需要了解部门信息的有效渠道
  • 就比如最近我们学校的社团正在纳新,那么大多数部门是如何宣传自己部门的呢?是的,扫楼,而事实上这是个效率极低的方式,因为部门正处于青黄不接的阶段,可用人手少,新生又多,推广起来费时费力。一个部门的扫楼一般来说要耗费两三个晚上的时间。
    -与此同时,是学生对部门的不了解,各个部门接踵而至,光开门就能让新生开到烦,更不用说他们初至大学,一切都要适应,扫楼的行为实际上一定程度打扰到了新生。这种情况下指望部门成员三言两语就将部门直观地剖析开来是不现实的,新生能了解到的部门信息有限。
    -话分两头,部门对于新生信息的收集不够充足也是一大问题,大多数部门因为扫楼匆忙,在让新生填表的时候一般都只是姓名手机和所在系。收集到的信息少,以至于很多可以在纸面上体现出来的信息都需要在面试时再进行提问。

Approach

  • 将应用分成部门端和学生端,双方的信息能够实现交互更新。
  • 学生端新生在使用时要先把自己的信息填写完毕才能进行下一步操作,这样子确保每一个新生的信息都能够得到准确的收集,方便筛选。
  • 学生端集成了所有部门的信息,方便学生查看。
  • 部门端能够查看到报名的新生信息,同时有自己的部员表,部员表有淘汰功能,方便部门对表现不合格的部员予以淘汰,比如缺席会议5次以上。

Benefit

  • 这个软件并不需要四路泰坦来带动它。
  • 我们本身就是这款软件的使用者,可以根据实际情况实时调整软件的功能。
  • 这个软件虽然简陋,但是完全免费,也不会出现商城之类的东西。

Competitors

  • 相似的软件很容易就能制作,缺乏难以复制的核心技术
  • 没有足够吸引人的“杀手功能”,一旦有其它方面更好的相似软件,用户很容易流失。

Delivery

  • 试点。目前正值学校学生社团迎新的时间,可以通过在部门任职的同学进行小范围试验,在证明这款软件能力的同时可以依靠这些初期反馈迅速调整软件的一些瑕疵。
  • 通过小范围的试点进一步辐射扩散用户范围。层层推广。

原型模型

模型采用Axure Rp制成,选用Axure Rp的原因因为这是博文里推荐的第一款软件,同时使用也比较简单,也有汉化。
  • 选择登录界面
    1220247-20170921190557243-661736980.png
  • 学生端界面
    1220247-20170921190643712-1311726498.jpg
    1220247-20170921191003321-607868720.jpg
  • 学生个人信息
    1220247-20170921191128275-543664810.jpg
  • 学生查询部门信息,同时可以报名
    1220247-20170921191217478-2050123314.jpg
    1220247-20170921191341400-53023116.jpg
  • 学生可于学生端向部门请假
    1220247-20170921191656775-1443197790.jpg
    1220247-20170921191813181-2112296469.jpg
  • 部门端界面
    1220247-20170921191902259-398562418.jpg
  • 部门信息,用于向学生端推送本部门信息
    1220247-20170921191951400-1205459266.jpg
  • 部员信息(可以在此淘汰部员)
    1220247-20170921192458384-375172674.jpg
  • 新生报名信息
    1220247-20170921192751071-594818194.jpg
    1220247-20170921193255196-1877927778.jpg
    1220247-20170921193327228-1739883437.jpg
  • 对部员请假申请进行操作
    1220247-20170921194554993-297562795.jpg

PSP2.1Personal Software Process Stages预估耗时(分钟)实际耗时(分钟)
Planning计划3025
Estimate估计任务时间3030
Development开发240260
Analysis需求分析120150
Design生成设计文档3060
Design Review设计复审2025
Coding Standard代码规范00
Design具体设计6080
Coding具体编码00
Code Review代码复审00
Test测试00
Reporting报告120120
Test Repor测试报告3030
Size Measurement计算工作量2030
Postmortem & Process Improvement Plan事后总结, 并提出过程改进计划4040
合计740850

与队友

  • 因为是结对作业,所以很快选择了志趣相投的同班同学作为本次作业的搭档
  • 很快地在大佬宿舍进行了本次作业的讨论
    1220247-20170921200550243-364337097.jpg
    -------------
    关于本次作业
    -总的来说,这次作业的思路还是比较清晰的,大体上就是一个部门-学生的框架,要做的就是依照要求把各个功能填进去。
    -需要注意的是即使新生通过筛选变成部员,部员仍是有淘汰机制的,像比如缺席6次会议就要给予淘汰。所以在部门端需要有相应的功能,不能忽略
    -第一次接触这种项目,即使能够把原型模型做出来,如何用代码来实现这个小项目,还需要更多的努力。

转载于:https://www.cnblogs.com/Typhon/p/7543900.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值