原型设计(结对第一次)
结对成员
林翔170327041
李明皇170327037
NABCD模型
Need
针对本次作业这个案例来说,用户最基础的需求为:提供一个学生部门纳新时能够让学生和学生会双向互选的平台。确定了最基础的需求后,我们分析了学生会部门纳新的整体流程:
- 学生会各部门向所有学生发布纳新通知和常规活动时间和面试时间;
- 学生填写表格后提交学生会;
- 学生通过面试,部门将学生纳入部门;
- 学生按照部门规定的常规活动时间参加活动,若未能参加需提交请假申请,当同一部门请假时间超过6次后部门管理人员将其淘汰;
根据以上流程,我们认为这个平台的需求有:
- 部门
- 部门纳新信息公开;
- 部门发布常规活动时间时,警告与其他部门常规活动时间冲突;
- 部门管理人员可在系统上发布纳新通知等相关内容,临时活动,部门人员管理;
- 部门纳新信息公开;
- 学生
- 申请前了解所有部门情况;
- 简化学生申请流程,学生若想申请多个部门无需重复填写申请表;
- 学生报名时,不同部门常规活动时间重叠警告;
Approach
- 部门管理人员发布纳新信息,其中包括面试时间地点和常规活动时间。若和其他部门常规活动时间冲突(+-2小时)将收到警告;
- 学生凭学号和密码登录该管理系统后,在个人信息界面填入个人资料。该资料作为申请部门的简历,可重复使用。在个人资料填写内容我们参考了福州大学研究生会的纳新表格。这一部分需要设计一个数据库来实现;
- 学生在部门信息处可以看到系统管理员发布的纳新通知,可在该处进行职位的选择和申请。若存在部门常规活动或面试时间冲突将受到警告;
Benefit
- 简化了申请流程,公开了部门情况;
- 面试时间、常规活动时间、请假次数一目了然;
- 部门信息沟通更流畅,提升工作效率;
Competitors
- 操作简单,功能齐全;
- 作为大学生我们更能了解部门纳新时的流程和过程的繁琐,能更好的简化流程;
Delivery
参考教务管理系统的模式,系统以web的方式实现。经过内部的测试后向同学推荐,经过改进后联系学校的部门进行推广。
原型模型
原型工具
学生界面原型
- 首页界面
- 登录界面
- 个人中心
部门申请,学生可以在这里申请加入发布了纳新通知的部门,若已申请部门的常规活动时间或者面试时间冲突,将收到警告
- 活动安排,学生可以在这里看到自己已加入部门的活动安排,当有部门活动冲突时将用红色标注。学生可以在这进行请假操作并能看到当前请假次数
我的消息,学生能在这里收到管理人员发送的通知
系统管理员界面原型
- 通知管理,管理员可以在这里发布新的通知和修改旧的通知
- 活动管理,管理员可以在这里发布新的临时活动和修改旧的常规活动
纳新管理,管理员在这发布新的纳新通知,若检测到常规活动时间或面试时间和其他部门冲突将收到警告
成员管理,管理员在这里看到申请成员的信息和请假次数,可以对人员进行加入和删除的操作
结对过程
这次合作过程比较愉快。第一天,我们先是看了发布的需求和构建之法的第三章,第四章和第八章之后大致了解了结对是怎样一种状态。第二,三天我们先是一起分析了需求,然后一起设计原型。在设计原型的过程中,确定了大概的网页框架后李明皇负责设计学生部分的页面,林翔负责设计管理员部分的页面。第四天,林翔开始设计需求分析报告的大致架构。最后我们互相检查对方的工作作出补充和修改。最后李明皇补充了PSP表格。
PSP
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 15 |
· Estimate | · 估计这个任务需要多少时间 | 10 | 15 |
Development | 开发 | 295 | 505 |
· Analysis | · 需求分析 (包括学习新技术) | 30 | 60 |
· Design Spec | · 生成设计文档 | 60 | 100 |
· Design Review | · 设计复审 (和同事审核设计文档) | 10 | 15 |
· Design | · 具体设计 | 180 | 300 |
· Test | · 测试(自我测试,修改代码,提交修改) | 15 | 30 |
Reporting | 报告 | 60 | 90 |
· Test Report | · 测试报告 | 20 | 20 |
· Size Measurement | · 计算工作量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 60 |
合计 | 365 | 610 |