第五次作业——原型设计(结对)
结对成员
031502516 李佳莹
031502528 苏媛
原型设计工具
最先我们是先尝试了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 |