结对成员： 031502641-郑珍发 031502513-黄逸飞
1.整体框架与NABCD构架
当看到第一次结对作业时，经过讨论和实践，最终决定采用墨刀进行原型设计，因为墨刀下载渠道多，工具简单易行容易上手和掌握，所以采用墨刀。原型分为面向部门，面向学生两个端口。
1）N——need需求
- 部门的需求：在每学期开学初，纳新人数总是逐年递增。学生会各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选。以往学生会各个部门只能手动通过一一比对的方式查看某个学生申请的部门是否超过五个或者加入的部门的常规活动时间是否冲突等，这增加很多麻烦和不必要的工作量，所以急需一款能够让部门选择的过程能够信息化起来的app。
- 学生的需求：每学期想加入学生会的学生只能扛着烈日在青春广场穿梭却所得不多，对部门也不甚了解，而且有些人并不会去考虑是否有冲突问题等。甚至会忘了面试时间，加入后也不一定会去考虑请假情况等等。所以急需一款能够方面学生选择部门的app。
2）A——approach做法
- 经过我们的研究，首先原型设计要在解决客户需求的情况下进行有限的功能扩充，分为学生端和客户端。其次，我们的app主要是针对学生的，因为有权使用部门端的人较少。学生端主要实现对部门的详情查看、加入申请和请假申请。部门端主要实现对学生的申请和情况进行管理。
3）B—Benefit
- 可以减少部门间的人工交互，节省时间和精力，通过app自动筛选和管理的信息化大大方面了部门人员。对于学生，大热天在室内通过手机就能进行部门选择，并且可以随时了解部门动向，大大方面了学生。
4）C——competitors
- 由于大家作业一样，看了同学的界面设计感觉压力山大，相比他们优美的界面和较为完善的功能，我感觉我的原型设计一般，优点应是界面精简却不失优美，功能随拓展有限却实现了基本的功能。
5）D——delivery
我们可以在qq或微信方面做小小的宣传和推广。同时可以邀请身边的人进行简单试用根据反馈作出相应的优化，而后向本学校甚至其他学校的学生会进行推荐和使用。还可以将其发布在网上和安卓市场推广。
2.原型设计：
- 使用墨刀开发工具
学生端（031502641-郑珍发）：
学生用学号和密码登录到首页；首页可以搜索部门，通过轮播图可以查看热门活动
也可以在下列部门标签中选择部门，点进去有部门信息和纳新信息，可以点击右下角的申请加入，填申请表
在填完申请表后，提交有两种情况：a.提交成功，会通知具体面试时间，面试时间由系统随申请人数而变，减少学生等待时间，提交成功后会跳至已申请界面b.若申请加入部门超过5或常规活动时间冲突，会提示失败原因
底栏首页旁边是活动，包括常规活动和临时活动的通知。
底栏最右边是我的，包括个人信息（以下）、设置（未做）、通知（以下）、已申请、已加入、请假和退出登录（到登录界面）。
已加入中可以查看你已加入的部门，已申请中可以查看已申请的部门，点开可以查看面试信息等。
请假详情中可以请假、查看请假信息等。
部门端（031502513-黄逸飞）
部门管理员用部门帐号和密码登入，首页就是部门事务管理界面
部门纳新界面是对面试时间地点人数进行申请 申请后跳转至学期申请界面对申请的进度进行查看和修改
新生申请界面就是查看新生提交的申请情况，星号代表是否有有来参加面试，手势代表查看新生申请表，面试情况界面就是归纳新加入部门成员名单
临时活动发布就是发布临时活动信息，通知成员。
部门考核中部门人员界面中可以查看搜索成员，点击成员能查看成员在部的表现情况，在部表现情况界面中能查看请假次数和请假超6次强制成员退
人员流动界面可以查看主动退部和被强制退部信息。我的界面就是改密码和退出登录等常规操作
3.PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 9.5*60 | 12.5*60 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 2*60 | 2.5*60 |
| · Design Spec | · 生成设计文档 | 1*60 | 1*60 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 3*60 | 5*60 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 1*60 | 70 |
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | 1.5*60 | 100 |
| · Size Measurement | · 计算工作量 | 10 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 |
4.描述结对过程
- 虽是跨班结对，却是早已相识。
- 照片
5.心得体会：
- 031502641-郑珍发：
经过这次之后，我深深地体会到了对项目做好规划的重要性。由于是第一次结对合作开发软件，经验不足，一开始讨论界面、细节、功能等后。我做学生端，队友做部门端。因为跨斑结对，缺少交流还有个人习惯的不同，导致做出后风格和界面不太一致。而且功能方面也有相对的缺少。配合的不顺畅需要一定的时间来磨合和适应，意见的沟通也需要时间，由于时间太短，尚不完善。当然，在构想细节和界面时还是发挥了结对的优势，各抒己见，集思广益，在讨论时还是会针对自己的分析提出不足和建议，相互学习和传递经验。这是我第一次涉及原型设计开发，从构想到一步步实现，掌握了对墨刀开发工具的使用和交互界面的设计思路，交互界面是用户使用软件的第一印象，因此原型设计极其重要。通过此次的原型设计，我收获良多，受益匪浅。 - **031502513 -黄逸飞
之前做结队作业的时候，我们只碰面讨论了下关于结队作业中的客户需求以及大致的内容模块，并没有深入讨论模型的设计，也没有及时的讨论，导致了模型的画风差异大，这次经历让我体会到了，在做结队还是团队的合作时，一定要及时进行沟通，提出自己想法和接收别人的想法才能把自己的项目弄的越来越好。还有一点就是，在做项目的时候，一定要明确好各自的分工，根据自己的特点特长，分配任务，这就是我做这次结队作业的心得体会。
948
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
