队员:
031402612李坤隆
031402629张建华
需求分析
1.需求
- 每个学生最终必须被分配到有且仅有一个导师
- 每个老师最多带不超过8个学生
- 考虑学生绩点优先
- 每个老师分配的学生数尽可能平均
- 最好不分配给不在志愿内的老师
- 老师可以要求带的学生人数在0-8的某个数或区间
2.做法
原始做法
系负责人下发导师候选名单-->学生报五个志愿上交系负责人-->年级负责人收集上交系负责人
由于上述流程过于繁琐且不透明,现在需要设计一个导师学生双向选择的系统。
新的做法
因为本系统使用频率不高,所以采用web的形式实现整体流程
整体流程可根据设定控制在3-6天内,流程图:
3.好处
-
操作流程信息化
-
过程公开透明,实现导师学生双向互选
-
只需登入网页即可操作
-
通过邮件通知最终结果
4.竞争
由于尚不知道其他产品的具体功能,所以无法进行比较,但是我们至少要做到以下两点:
-
网页要美观、简洁、易用(假设大部分人都会选择使用web端而不是移动端)
-
整体业务逻辑清晰,符合客户需求
5.推广
如果到时候学校采用了该系统的话,应该不用推广,只要通知大家登入网站使用
原型设计
采用Axure RP8进行原型设计
- 登入界面,账号密码无需注册,每个人分配一个账号
- 学生编辑资料页面,姓名、学号、专业名称、方向、绩点由系统设置,用户无法修改
- 选择导师界面,不同方向显示的可选导师不同,可填报志愿数也不同,点击导师名字可跳转到查看导师详细资料页面
- 导师编辑资料页面
- 查看申请学生列表,学生按绩点进行排序,点击学生名字可跳转到学生详情,到截止时间未审核的学生当拒绝处理
- 查看最终结果
学生申请结果
导师最终的学生
PSP
PSP | 具体做法 | 时间占比 |
---|---|---|
计划 | ||
*估计这个任务需要多少时间 | 学习相关知识加上文档和代码编写预计需要两个月 | |
开发 | ||
*分析需求 | 从客户描述中提炼出需求,优化需求 | 5% |
*生成设计文档 | 用AxureRP8进行原型设计 | 8% |
*设计复审 | 结对编程的时候边设计边复审 | |
*代码规范 | 约定统一命名规范,统一注释规范 | 5% |
*具体设计 | 以高内聚,低耦合为原则,设计代码整体结构,各部分功能如何封装,增加代码复用率 | 15% |
*具体编码 | 前端采用响应式布局,方便移动设备访问 | 50% |
*代码复审 | 5% | |
*测试 | 多浏览器兼容性测试 | 10% |
测试报告 | 2% |
总结
和他人一起编程,可以感受到对同一个软件,每个人都有自己的习惯,我们可以学习到他人优秀的习惯和一些使用技巧。当然2个人一起也会有分歧,我们这时候需要去换位思考,做出正确的判断。都说旁观者清,结对编程有时不仅不会浪费时间,还能极大地提高效率,更快地找到错误。通过这次合作,让我从队友身上学到了很多东西,队友显然比我更了解如何去开发一个软件,他纠正了我很多错误的想法,这次合作很愉快。