一、结对成员
| 姓名 | 学号 | 班级 |
|---|---|---|
| 程一飞 | 031502608 | K班 |
| 周元 | 051503223 | K班 |
二、原型设计工具的选择
1、原因与过程
因为对原型设计并不熟悉，最初我们按照作业上所写的几个设计工具一个个几乎全都下载过，想选择一个操作比较简单的工具，但是具体的感觉都差不多。后来经人推荐，我们发现原来还有很多网页版的设计工具。在ProcessOn和"墨刀"之间，我们选择了墨刀，因为他的使用更为简单，而且更为专业。
2、原型图片
首页
学生登录界面
完善资料
申请部门（点击【部门×】出现部门简介）
部门简介
部门登录界面
发布活动
发布纳新
查看申请
3、照片
三、NABCD模型分析
1、N（Need，需求）：
本次结对作业对现状描述如下：
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
- 部门纳新人数和面试时间必须事先申报确定；
- 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
- 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
- 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
- 未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
-----引自第五次作业---原型设计(结对)
从描述中可以看出，现状中最突出的矛盾就在于各个部门之间以及部门与学生之间的信息沟通不畅，由此而导致了活动时间冲突、学生和部门之间互相的不了解这样较为严重的问题。
此外，筛选和淘汰的机制十分繁杂，靠人工来每次确定的话，对于部门的管理也是一个比较大的难题。部门手工发放和收集汇总申请表，也会浪费很多的人力物力。
2、A(Approach，做法)
我们打算采用B/S模式，通过一个部门和学生都可以登录和操作的网站，将学生和部门的信息透明化，以此来解决二者之间信息沟通不畅的主要问题，同时加强互相之间的了解。
网站中分别以部门和学生的身份登录，将会有不同的功能供他们选择。部门的主要功能有发放和回收汇总申请表、筛选和淘汰部员、公布活动时间并提醒部员等等。学生的主要功能有申请部门面试、查看通知、申请请假。
3、B(Benefit，好处)
首先，我们采取的B/S模式能够实现不同的人员，从不同的地点，以不同的接入方式访问和操作共同的数据。不论用户使用的是何种设备和操作系统，均可通过操作系统方便和快速的进行所需要的操作。
通过B/S的操作方式，将人工发放申请表、请假等需求搬到网络上，也能减少部门的人力物力消耗，使同学们不会浪费太多的时间和精力。
4、C(Competitors，竞争)
我们的优点主要在于以浏览器为基础的跨平台性，系统界面尽力保持简单易用。
劣势主要在于相对与一些移动端app，我们的用户界面不够华丽，缺少一些赏心悦目的动画效果；在一些网络不好的地方，通过网页不能获得任何内容，而移动端app却可以依旧显示一些常用的功能。
5、D(Delivery，推广)
- 我们的首要推广目标应该是学校里大量的社团，可以采用上门推广的方式，教他们了解并学会使用该产品，让他们了解该产品将会在"百团大战"中带来的遍历，吸引他们在接下来的纳新中使用该产品。
- 在开学的时候，我门也可以制作海报，张贴在各大校园里，或者制作二位码，在一些餐厅上进行印刷粘贴，以方便用户的了解和使用。当我们吸引足够的学生用户将信息注册到网站的时候，也将会吸引更多社团的使用，以此来达到良性循环。
4、PSP
| PSP | 结对作业 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 5 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 5 |
| Development | 开发 | 250 | 330 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 60 |
| · Design Spec | · 生成设计文档 | 30 | 10 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 120 | 240 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 10 | 20 |
| Reporting | 报告 | 75 | 90 |
| · Test Report | · 测试报告 | 30 | 20 |
| · Size Measurement | · 计算工作量 | 15 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 60 |
| 合计 | 335 | 555 |
学习进度条
| 第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
|---|---|---|---|---|---|
| 0 | 150 | 150 | 48 | 48 | 了解了软件工程的一般方法，学会用工程的视角看待项目 |
| 1 | 120 | 150 | 7 | 55 | 原型设计、合作探讨、复习课程 |
附：PDF:PDF