第五次作业——原型设计(结对)

结对成员

031502516 李佳莹
031502528 苏媛

PDF

PDF文件地址

原型设计工具

最先我们是先尝试了GUI Design Studio,究其原因是我看一些人的评价说是它较为简单一点。就下载的角度来说它倒是确实不难,但在我们开始在网上寻找它的使用教程和自主钻研的时候,我才真正地意识到了小马过河故事的意义所在。小马在自己下河走之前不会知道河水到底有多深,而我们在亲自使用之前也永远不会明白一个软件到底适不适合自己。
总之在下完它之后我们一筹莫展了良久,主要问题在于我们的英文水平不够,无法很好的理解每一个功能和按键,而网上又很难找到比较有亲和力的教程视频,所以最后我们选择换一个工具使用。
这次选用的是Mockplus,是在好友的倾情推荐下开始接触的。不得不说语言真的是一个巨大的鸿沟,跨越了之后的使用感觉较之前真的是轻松了不少。这款原型设计工具使用前需要先注册账号,并不是冗杂的举动,在注册后会收到官方发来的邮件,里面有着该工具的使用教程链接,可以说是非常贴心了。将它与先前下的GUI Design Studio做对比的话,个人感觉优势最大之处是在页面链接时,Mockplus可以直接用鼠标连过去,相较起来真的是显得格外便利。

NABCD模型

  • N(Need,需求)

从本次题目中可以看出,我们总共有两种客户,一个是普通的,需要加入部门的学生,另一个则是部门里负责招生的那一部分管理员。
从困扰的现状中,我们可以看出,学生最大的难题是无法集中地获得各部门的活动时间,从而导致了个人的时间安排不畅,平白浪费了时间与精力。所以对于一个刚步入校园,想要加入部门的新生来说,他的需求就主要表现在对各部门信息的获取上。
而对于各纳新部门的负责人来说,他们手工发放申请表,手工汇总,再人工通知时间信息,太过混乱,所以需要一种更简便,更省时省力的信息处理手段。

  • A(Approach,做法)

我们可以建立一个网站,提供一个平台为客户获取信息。

  • B(Benefit,好处)

学生可以在上面获取自己想要的部门信息,如果有了想要加入的部门,也可以直接点击申请。他们还可以在上面看到自己所面临的面试和部门活动的时间地点,一目了然,不会出现因为遗忘或者疏忽而导致时间相碰无法处理的情况。
而负责纳新的部门管理员则可以在上面发布自己部门的简介,在未来的部门活动中,也可以发布临时通知,从而能够统一告知部员临时活动等事情的具体信息。学生可以在上面直接报名,因此负责人也不再需要手工发放宣传单和报名表。非常直接地在物力人力方面免去了他们很大一部分负担。

  • C(Competitors,竞争)

呃,现在的竞争对手基本上应该是班里其他的结对CP 了。要论我方小组的优势的话,可能就是我们特别情比金坚了,我们将报名的手续最大的简化。只需让学生一次性在个人信息页面将基础信息填好,报名时就只要在报名页面点击报名按钮即可,无需重复填写报名表单。
会有这样的想法,主要是当一个人报名多个部门时,报名表上的很大一部分基础信息都是重复的,反复填写这些信息很容易令人产生厌倦情绪,这极有可能会提前结束了部分学生探寻适合自己部门的步伐,在纳新期过去之后才觉得自己错过良多,这就很可惜了。嗯,当然,更主要的是,我们设计这个原型系统,最大的目标本就是能够将这段流程进行简化,能够让用户少动一点手,总归是没有坏处的。
这个做法也可能会出现一点弊端,比如每个部门获取到的信息相同,没有差异性。但这个问题可以很轻易的在面试环节中更一步了解到,所以我们认为,瑕不掩瑜。

  • D(Delivery,推广)

理论上来说,推广一个用于学生与部门之间的产品,首先要从部门开始入手,部门接受了这个产品,就有了稳定的信息来源,自然就能吸引新生使用。

结对&照片

我们相性比较好,生肖比较配。

遇到的困难和解决方法

最大的困难就是最开头不得不更换原型模型工具,前面提过了,这里就暂不赘述了。
还有就是我们两人对于题目的理解在初级阶段发生了冲突,提出的想法也很有多相异之处。但万事胜在沟通,我们互相列举了自己思路的历程和提出这个想法的理由,在一条条慢慢梳理下达成了共通,也就形成了目前的这个设计。

设计说明

本次设计的项目树如下图:

登录界面

  • 学生
  • 管理员

学生登录

  • 首页
  • 部门列表
  • 某部门界面
  • 学生日程
  • 个人信息
  • 我的申请
  • 我的社团

管理员登录

  • 部门详情
  • 部门纳新
  • 部门成员
  • 临时通知

PSP表格

PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
Planning 计划 20 15
· Estimate · 估计这个任务需要多少时间 20 15
Development 开发 360 645
· Analysis · 需求分析 (包括学习新技术) 120 260
· Design Spec · 生成设计文档 0 0
· Design Review · 设计复审 (和同事审核设计文档) 0 0
· Coding Standard · 代码规范 (为目前的开发制定合适的规范) 0 0
· Design · 具体设计 30 30
· Coding · 具体编码 180 300
· Code Review · 代码复审 0 0
· Test · 测试(自我测试,修改代码,提交修改) 30 55
Reporting 报告 85 138
· Test Report · 测试报告 60 120
· Size Measurement · 计算工作量 5 3
· Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 20 15
合计 465 798
posted on 2017-09-22 20:14  inblue  阅读(194)  评论(1编辑  收藏  举报