#结对作业——原型设计
结对作业——原型设计
结对成员: 锃2226 友林2228
工具选择
我们在网上搜索了原型设计工具,了解老师推荐的工具以及其他,发现Axure RP使用的人数较多,很多人也是推荐Axure RP,网上也有提供很多教程,大致了解了下,上手难度不大,适合我们这样之前没有接触过原型设计的人。
NABCD模型
need:
从题目可以看出学生和部门间,部门和部门间的信息交流不畅,信息也没有统合。
部门对于学生的信息传递是通过海报传单的方式,对学生的宣传难免会有遗漏;对于纳新和淘汰的处理还处于人工阶段;在进入部门前,学生对于部门不够了解,没有方式提前了解到不同部门的活动安排,部门对于申请的学生也没有方式了解;部门之间也没有沟通,活动安排可能发生冲突。
approach:
针对这种情况,需要一个平台来对部门和学生的信息进行统合和发布,一个类似于公告栏的网站就可以很好的解决这个问题。我们设计网站主要可分为三个部分。
- 第一部分为首页,用来向用户提供部门的信息简介,近期活动等动态信息。
- 第二部分为学生个人界面,学生可以在登陆后进行个人信息的修改,部门申请和退出的在线申请,已加入的部门的活动的查看和申请参加,请假的在线申请。
- 第三部分为部门管理界面,部门管理者可以在登陆后进行部门信息的修改,部门活动的发布以及历史活动的查看修改,入部申请的处理和部门现有成员的管理。
benefit:
对于部门来说:
- 有了这个网站可以将部门纳新和活动信息传播到更大学生群体(只要这个网页有人上的话),而不仅限于海报传单这样的线下宣传;
- 在对入部申请的处理上可以更加简单,而不需人工统计入部申请以及专门设立线下纳新地点分发申请表,提高效率;
- 对于活动信息的发布以及参与人数的统计更加简便,而不用另外举行例会进行通知,简化活动发布流程。
对于学生来说:
- 可以通过这个网站来了解更多的部门信息和活动信息,而不止于传单和海报;
- 可以很方便的在线申请加入部门,而不需要专门到纳新地点书面提交申请;
- 可以更清楚的了解部门的活动时间安排以及对部门发布的活动在线申请参加,而不会;
- 在线请假申请,更加方便。
competitors:
在网上搜索了下,福大好像并没有专门的进行学生部门管理的网站,那么主要的竞争对象很明显就是正在做这个结对作业的其他组了,在这方面我方优势是设计简洁,劣势可能是功能较少对实际需求了解不足。
delivery:
首先在网上发布,向学生部门推荐,安利试用,在一些学生部门试用一阶段后,再根据学生部门的反馈进行修改,以适应实际情况。
原型示例
首页
学生登陆界面
申请加入部门
学生加入部门查看
学生活动查看
学生请假界面
部门登陆界面
部门成员管理
部门活动管理
结对照片
PSP:
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 10 |
· Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
Development | 开发 | 40 | 30 |
· Analysis | · 需求分析 (包括学习新技术) | 60 | 30 |
· Design Spec | · 生成设计文档 | 20 | 10 |
· Design Review | · 设计复审 (和同事审核设计文档) | 20 | 20 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
· Design | · 具体设计 | 30 | 30 |
· Coding | · 具体编码 | 0 | 0 |
· Code Review | · 代码复审 | 0 | 0 |
· Test | · 测试(自我测试,修改代码,提交修改) | 0 | 0 |
Reporting | 报告 | 60 | 30 |
· Test Report | · 测试报告 | 20 | 20 |
· Size Measurement | · 计算工作量 | 10 | 5 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 20 |
合计 | 310 | 225 |
学习进度条
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
0 | 226 | 226 | 10 | 10 | 学会了vs基本操作以及代码的测试方法 |
1 | 100 | 326 | 6 | 16 | 了解了原型设计的相关知识与设计方法 |