0、欢迎食用
- 作业链接：https://edu.cnblogs.com/campus/fzu/SoftwareEngineering2015/homework/938
- 对友联盟：
031502324 林诗尧
031502411 胡冰
1、需求分析
-
Need
部门
1、需要大量人力进行申请表发放和收集的工作以及后期部门内部的工作评定。
2、和其他部门缺乏信息沟通，不能了解部员当前的工作量。
3、盲目接收部员可能影响后续部门工作的正常推进。
部员
1、对部门的职责缺乏详细的了解，进入部门后可能发现部门实际工作与自身认知有所冲突，导致对部门工作消极怠工。
2、加入过多的部门，导致自身时间安排不当，不仅影响部门工作，甚至还可能影响学习。 -
Approach
人员招收
1、部门完善自身基本信息，包括部门名称、部长信息、联系方式、部门简介、常规活动时间、特色活动等。
2、学生完善个人信息，包括学号、姓名、性别、联系方式、特长。
3、确定纳新人数和面试时间，申请面试场地。
4、学生自行浏览部门信息，根据自身意愿填报申请表。
5、部门根据报名信息安排具体面试时间，并将面试的时间地点通知到学生。
6、未参加部门面试的学生将不被纳入部门。
7、面试结束后录入面试成绩，并根据学生预报名情况，由部门自行筛选。
8、若学生被超过5个部门同时接收，将强制学生选择5个部门。
后期管理
1、部门统计并录入每次活动的出勤情况，若部员出现常规部门活动时间请假超过6次，将发出警告。
2、部门发布临时活动时间并通知部员。 -
Benefit
部门
1、可以减少大量人力的人力工作，提升部门内部的管理效率。
2、方便与和其他部门共享信息，掌握部员真正的空余时间，可尽可能避免有事情找不到人的情况。
3、有助于部门工作的正常进行和有序推进。
部员
1、对部门的职责能有一定的了解，不会出现盲报现象。
2、方便对自身时间进行良好的规划，做到学习工作两不误。 -
Competitors
优势
1、做过一些学生工作，对目前部门在人员招收、内部管理等方面存在的问题有切身体会，能够设计出符合实际的产品。
2、目前市场上暂无成型的系统可供使用，市场竞争小。
劣势
1、项目经验不足，对一些较为细节的方面可能考虑不周。 -
Delivery
1、因为自身有担任学生工作，所以可在自己部门内部试用，若对部门管理效率有显著提升可考虑向院级其他部门甚至校级部门推广。
2、原型设计
- 工具：墨刀
- 根据需求分析主要分为两个部门端和部员端。
- 部门端
顶部导航栏在点击不同子项目的时候是有透明度变换的，但由于缩小一下效果感觉有些不明显 0 0
- 活动安排
由于纳新活动的特殊性，我们将纳新看做一个特殊的活动并进行了特殊的处理。长按加号将添加纳新活动（如左图），单击加号可添加日常的临时活动（如右图）。
对于纳新安排，点击可进入查看当前纳新进度的界面（如左图），并可点击编辑按钮对录取状态进行修改，点击记录可直接查看对应学生的具体信息；对于日常发布的临时活动，点击则将展示对应活动的进展情况（如右图）。
- 活动安排
- 部员端
这里顶部导航栏效果也是因为图片缩放不太明显 0 0
- 通知界面
当部员点击我要请假时，系统会自动检测该部员当前在该部门已请假的次数，若超过6次，将弹出提示框发出警告。
- 部门界面
单击加号即可转入部门纳新界面（如左图）进行纳新申报。点击我要报名即可转到报名表（如右图）填写，基础信息将直接导入报名表，学生只须针对不同部门的职能和需求填写加入理由即可。
在纳新时期申请过程中，会在部门信息的右下角显示当前该部门的录取状态。点击部门信息即可查看该部门的纳新进度（如左图）；对于已被确认接收的部门，在点击部门信息的时候将会出现对应部门的基础信息（如右图）。
每次打开部门界面都将检测该学生当前参与的部门数量，当学生被超过5个部门录取时将强制弹窗（如左图）。学生点击前往选择进入部门选择界面（如右图）。
- 通知界面
- 部门端
3、PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 30 |
| Development | **开发 ** | 420 | 500 |
| · Analysis | · 需求分析 (包括学习新技术) | 150 | 180 |
| · Design Spec | · 生成设计文档 | - | - |
| · Design Review | · 设计复审 (和同事审核设计文档) | - | - |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | - | - |
| · Design | · 具体设计 | 240 | 300 |
| · Coding | · 具体编码 | - | - |
| · Code Review | · 代码复审 | - | - |
| · Test | · 测试（自我测试，修改代码，提交修改） | 30 | 20 |
| Reporting | 报告 | 140 | 200 |
| · Test Report | · 测试报告 | 100 | 150 |
| · Size Measurement | · 计算工作量 | 10 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 580 | 730 |
这行字不重要，纯粹为了凹格式。
4、结对展示
- 因个人原因非常迟才能开始做本次作业，感谢对友配合我的时间。
5、心得体会和项目总结
- 林诗尧
第一次体验结对编程，emmm与平时的结对实验还是很不一样的，结对实验大部分是按照指定步骤执行即可，而结对编程却是两个人思想风暴的碰撞，脑回路不同的人设计方式、方向也有所不同的，经常会有啊原来还有这种操作的感叹。对友带我飞。两个人可以相互补充，让构思相对更完整一些，但当前尚未达成 1 + 1 > 2 的高效率工作目标，结对项目需要好的配合，讨论拟定方向后便大力猛攻，而我却时而犹豫不决，想要返工，对于大方向需要更果断更坚决一些。
对于这次的题目存有稍许疑问，到底是只需要设计一个利于纳新的系统呢，还是连后期的管理与使用也纳入考虑。最终加了一点点管理的内容，保留将纳新作为一个稍微特殊活动而非唯一事件的构思。设计真是让我头秃。 - 胡冰
没有完整地走过软工的流程，发现和自己想象中的不太一样。（此处纯为巧合 0 0）两个人结对可以互相补充逻辑上的漏洞，想到对方的思维死角，在需求分析的环节能够较快的推进，较少出现停滞不前的现象。在原型设计的时候，通过两个人的讨论和交流，可以注意到一些较为细节的地方。并且两个人不同的学习经历让我们在原型设计上能够考虑到多个方面可能存在的问题，使我们设计出的产品尽可能的完备和实用。
很开心能有这样的结对经历。虽然实际完成时间非常短暂和紧张，做出的项目还是比较粗糙，但是还是学到了不少新知识。最后再次感谢对友接下我这口大锅，配合我在最后短短的三天时间内完成了这次作业。