作业链接
成员：
031502512 黄世辉
031502541 张昭锡
一、方案介绍
使用NABCD模型分析：
Need
客户的痛点在于：手工发放与收集表格，流程过于繁琐；各部门缺乏沟通，活动时间有所冲突；部门与学生之间在初期了解不够，导致选错部门招错人的后果。从应用场景和这些痛点中，我们可以归纳出一些客户的需求：
-
学生：
- 介绍自我
- 了解部门
- 知道部门纳新人数以及面试时间、地点等相关信息
-
部门：
- 介绍部门
- 了解学生
- 信息化报名流程以及审核流程
- 避开与其他部门相冲突的时间段开展活动
- 统计部员面试信息与请假次数等信息
Approach
- 学生和部门之间使用手机客户端软件将纳新、活动一系列流程信息化起来
- 学生通过软件完善个人信息，展示个人风采
- 部门通过软件完善部门资料，展示部门风采
- 部门通过软件发布纳新等相关信息
- 手机客户端依据各部门活动时间段生成一个时间长条，便于其他部门发布活动时选择时间
- 学生通过软件查看各部门风采，根据自己兴趣填报相应部门的纳新表格
- 部门根据收集到的纳新表以及学生个人信息进行审核
- 软件记录学生面试情况以及部员在部表现（请假次数）
Benefit
- 学生通过客户端可查询到任意部门（有使用此方案客户端）的纳新情况，而不仅仅依赖于部门传单与同学口传等传统方式，扩大了获取信息的途径
- 学生和部门之间能对彼此有大致了解，降低相互不了解的盲选概率
- 无需手工发放表格、收集表格，减轻人力成本，节约时间和精力
- 减少部门活动时间安排上的冲突，避免学生加入部门后因此而被淘汰
- 信息化管理学生面试情况、部员在部表现，而不依赖于传统纸质记录方式，减少资料繁多而造成的凌乱感
- 迁移成本几近于零（除了手机上多了一个app）
Competitors
- 优势
- 使用简单
- 无迁移成本
- 功能简洁
- 劣势
- 存在其他大量同类产品亦即其他结对队伍的解决方案
- 可能UI没有那么美观（= =嗨吖，我们也想弄得漂亮一点，为我们的设计、审美感到抱歉）
Delivery
前期与社团沟通，让各社团慢慢使用起来，带动这个软件移动端的使用；另外，在新生版块（每个学校都会有类似新生交流的版块：贴吧，论坛，各种相关QQ群）推广，让新生一入学马上就知道使用此软件。
二、原型模型
使用工具：墨刀
-
登陆界面
注：部门号学生号那些为提示信息，点击相应框则消失
-
学生界面
-
部门列表
注：支持搜索部门，可对心仪部门进行收藏
-
填报纳新表
注：学生只需填写申请理由，其他个人公开信息，部门在审核纳新表时，可点击查看学生公开信息
-
我的活动
-
个人信息
-
我的部门
-
退会申报
-
部门界面
-
发布纳新
-
纳新审核
-
成员情况
-
部门介绍
-
发布活动
注：这个界面有点奇葩，时间底下那个长条是个类似条形图的东西，其他部门如果已经申报占用了该时段的时间，则显示为灰色，那么要发布活动的部门则可以点击那里查看不会与其他部门冲突的时间，其实本来想用饼状图去表示的，然后上面依然用灰色代表已被占用的时间，然后附加这段时间发布活动的社团信息，两种方法都觉得好突兀= =，本来还想直接用系统根据你设置的时间返回时间段是否可用，但考虑到这样使用者可能需要多次尝试，用户体验太不好了）
-
设置（学生和部门设置界面一致
三、PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 150 | 240 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 90 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 90 | 150 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 60 | 90 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 20 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 40 | 60 |
| 合计 | 240 | 360 |
四、结对讨论
下图为根据纸质图在墨刀上进行原型设计
图片已删
下图根据墨刀提供的组件与纸质有些许出入，商量的过程
感谢整个过程帮忙拍照的立强同学
五、心得体会
-
昭锡
说来也很巧了，从大一一路过来，实验上基本都是跟世辉一起组队。因此这次结对的过程，沟通交流还是比较流畅的。尽管之前一直都是实验的队友，但是这次结对感觉跟以往又有些许差异。之前的实验，总是按照教科书上的实验步骤一路完成下去就行，但是这次，确确实实是完成一个从无到有的原型模型。在这个过程，少不了思维的碰撞，各自不同的想法，也是这种碰撞让我们彼此拓展了思路的火花。单人的话，也不是无法完成本次作业，但若如此，也只是沿照着自我原有的思维模式，将其展现出来，很难吸取借鉴到队友亦或者他人的知识。我们总是容易得知他人对同个问题的结果，但是很难去发现对于同一个问题，他人的思维过程是怎么样的，促使这样的一个不同的结果产生。
通过本次结对合作，大致懂得软件开发流程中需求分析的大致流程，接触了之前从未使用过的原型模型工具。应该说，每次作业都让自己接触到了一些新东西。阅读书籍的过程，如果少了这么一个实践的过程，可能确实觉得书上说得很有道理，但是具体道理在哪，很难去描述清楚。就像一开始看到NABCD模型，觉得这个厉害，但是怎么个厉害法，我们基本不会自主去尝试将其用在某一个用户场景去分析一个实体需求。当然，光是这两章东西， 还是需要多去实践才能明白它要表达的点。 -
世辉
刚开始看到这次作业是不太清楚是要做些什么的，幸亏老师在作业中提供了构建之法里的参考资料。通过翻阅构建之法里的第4，第8章才对本次作业有了初步的了解。
在构建模型的之前，我与队友先进行了一番讨论，在讨论的过程中发表自己的观点，也对对方的观点提出了自己的理解。在这次讨论中，我也收获了该如何去和队友协商沟通。在没有这次作业之前，我对原型模型是没有任何了解，也不清楚这一环节在软工时间中的重要性。到通过这次作业，让我明白了模型的重要之处。这让我们对软件有了一个初步的轮廓。再者就是构建之法中提到的NABCD模型，这是对自己设计的软件的一种分析吧，这让我们清楚了自己开发的软件有什么优点，缺点，让我们有了改进的方向。总之，这次的列队作业让我加深了对软件开发的过程的了解