整体概况
- 1、整体框架与NABCD构架
- 2、面向部门
- 3、面向同学
- 4、MockPlus框架图一览 可实现版 [脑洞版]（由于没管住自己的手，结果把项目升级成了团队项目，没有会员的我只能默默地看不能另存了，如果需要运行，我提供账号密码，在云上运行一下吧。）
- 5、图表项
- 6、心得体会，以及我和我的队友 > _ > 031502106_陈涵 031502634_杨光海天
1、整体框架与NABCD构架
- 具体内容我们通过MockPlus（在搜索Balsamiq Mockups的额外产物，同时也有知乎和CSDN推荐， 一下子被MockPlus简洁的界面吸引了）进行了原型设计，分为面向部门，面向同学，针对管理员部分，我们在现阶段还没有具体设计，但是有了一些打算。
1>Need篇
痛点的概述
1）部门的痛点
- 身处学校的广播台，今年已经是第三年了，对于纳新已经再熟悉不过了，眼下又是一轮新的纳新周期，我也由此对我周围的部长进行了一些调研，不难看出和我的想法是基本一致的，那就是我们不了解新生的作息，包括课程的安排和一些其他部门的安排，痛点很简单也很一致，那就是我们不知道这个同学进入了几个部门，他们部门是什么，最关键的就是不知道他们部门的工作量是多少。
关键痛点1：多部门已纳，而面试者未知
- 部门的工作量其实最直观的反应就是他们的部门名称，如果知道了名称，那么我们是很容易了解到他现在所需要的工作性质。 打个比方，比如一位同学，加入了校主持队，加入了校社联，加入了校记者团……如果一个学生的能力还不错的话，他们如果已经加了上述三个部门或以上，我想我们是不会选择纳入这名学生的。因为他的工作量实在是太大了，同时，例会的冲突可能也在所难免，我把它归结为一个痛点，同时这也就是本次最关键的痛点。
关键痛点2：专业因素冲突，影响部门工作
- 但是即便是他没有上述的一些部门，但是如果他的专业是建筑类的话，可能我们也要再三考虑，因为这个专业的课程可能不只是BT这么简单了。他有没有能力胜任这份工作，这是我们需要考虑的，但是如果我们不知道他的专业，这个问题可能直到他来面试，才会了解，这将会使他和我们无故的增加一些工作量。此为痛点二。
2）学生的痛点
级别不清，部门、社团、学生会，工作性质不明
- 周围的一些同学，恰恰是一些班导，而自己的新生群中，也有很多的新生，因此我了解过他们的难处，那就是"这个部门，那个社团，或者这个社联究竟是什么？"校级，院级？究竟有什么区别，我要做什么？"，总结了一下他们的痛点，那就是了解部门，社团，社联的概念，并且分类依据需要不同的级别！但是题目所给的是部门的概况，因此我只是单单以部门模型为例，区分校级、院级的不同。以此作为问题的痛点。
2>Approach篇
依托数据库的解决之道
-
首先想澄清一点，我们的想法很多，但考虑到后期实现的困难程度，因此我们对自己的高要求进行了"落地"操作，取消了一些我们看上去能够实现，但是能力和时间所限无法实现的问题。并且对一些研究过于详细，实现难度大的问题进行了模型的简化。
-
其次，介绍一下部门的管理，此为重中之重，我们的功能也主要是面向部门。我们提供了部门成员的整体管理，新生的纳入，请假情况的详查，以及新生被占时间为例会的查询，目的很简单，解决痛点，提供给部门一个明明白白的新生框架。由此我们建立三张表来处理这个需求。在面向部门之处会详细介绍。
-
之后，对于学生，我们想通过支持学生注册的方式，对学生进行管理，学生不想参加的话，没有必要透露个人信息。而学生的痛点，在于不了解部门，因此目前任何人都可以查询部门的状况。由于部门是公开的，所以也没有必要对其进行细化，以后可以单独给学生创立一个界面，完成学生自己的申请操作。
-
整体的实现框架
3>Benefit篇
一线需求者，同时也是一线的制作者
- 和一般软件一样，数据库不需要什么硬件消费，同时做自己最了解的事情，当然自己也应该擅长这一方面的策划。解决问题的软件，才是好软件。深受问题影响的人，也是最可能解决问题的人。可能自己的能力有限，没有好看的UI，可能距离移动到移动平台还有些时日，但是模型，关键需求的满足是每一个软件设计者必须的东西。可能，我们只是展现一下这方面的造诣。
4>Competitors篇
Sum = (选修软工实践人数) / 2;
- 开一个玩笑。由于没有正式的类似软件上线管理，因此我们都算是一个竞争者，而目前为止，我们的对手就是所有班需要做这道题的同学。我方优势：原版的方式较为简化，上手方便。 我方劣势：没有开发经历，掌握的开发工具比较薄弱。没有优质的算法实现。
5>Delivery篇
强大的自媒体社交与传统的推广
- 自己的纳新环节必定可以作为一个参考，来审核一下自己到底哪些地方不好，哪些地方做的还可以。自己这个试验场还可以推广到自己的部长，甚至是以后作为部长的部员，下一步推广到认识的朋友，在别的部门工作的人，甚至是以前的同学，不同学校，我想，这一定不是我们一个学校的问题，也是众多学校共有的问题。
2、面向部门
- 讲了那么多介绍，下面来一些干货，首先是面向部门的规划和提供的功能。
3、面向学生
- 提供基础查询，简化模型，无需登录
4、MockPlus框架图
- 首先安利一波MockPlus的学习教程，很好很强大 ->点击这里
可实现版
- 登录及注册界面
- 部门登录
- 部门和学生注册
- 部门管理
- 学生查询部门
脑洞版
- 整体构架
- 登录界面
- 部门注册界面
- 学生注册界面
- 学生登录个人管理界面
- 部门首页功能介绍
- 部门模块功能介绍
- 页面流程图
- 新脑洞版，在ios上运行，并且增加了一些额外，如学生和部门的互选功能，学生可以查询到自己的面试得分和面试每轮的在线题目（如需要）。更加明晰要纳入学生的具体状态，以及对于时间冲突学生的判定。
- 该版本主体由杨光海天具体制作，我来负责前期一些规划和后期的一些修改。
5、图表项
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 330 | 330 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 100 |
| · Design Spec | · 生成设计文档 | 60 | 120 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 30 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 120 | 80 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 90 | 70 |
| · Test Report | · 测试报告 | 30 | 20 |
| · Size Measurement | · 计算工作量 | 30 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 450 | 430 |
6、心得体会，以及我和我的队友
1>心得体会及项目总结
陈涵
-
第一次不是一个人上路了，第一次想法可以有一个共享的平台，我喜欢这种感觉，第一次尝试了一下组织，安排工作，我喜欢这样一个轻松的氛围，说实话，不知道自己的想法会不会被采纳，的确有很多的想法和希望，但是由于各种各样自身的原因，难以实现，这也反映了自己的能力还远远不够，自己会的工具还是太少，当然，就像我第一次作业说的，我会按照自己的计划，按部就班地做下去，而不是希望那种竞争气太重，或者抱着一个大腿，成为一个“优质“的附庸者，我觉得既然报了软工实践，就要给自己一点空间去真正的实践，既然选择了栋哥，就要把自己的极限往上升一个档次。我希望的结对和团队都是希望每一个人能够亲身经历这个过程，每个人或多或少都可以参加一部分的工作，可以说不论是结对还是组队，我们都不强，都没有一个真正的靠山，但是我觉得这种危机意识，以及无法依靠大腿的意识，会敦促我们按时按质的完成自己的任务，同时，我更倾向一个和谐的团队氛围，我们可以有争论，我们可以有不同想法，但是都不要过分地夹杂情绪的影响，而使自己过于强势，我们可以问，可以想，也可以提，可以看。团队是你的家，而不会漠视任何一个人的存在。我理想的Team就是以上这样子。
-
同时附上理想（qiang po zheng）的自己：对于自己感兴趣的事，要么不做，要么做，做就做好。
杨光海天
- 刚听到本门课程的作业需要结对完成的时候，不免有些茫然失措。平时并不十分努力的我，该如何结对呢？更何况不能和组队的人员冲突。
- 在这危难关头，他向我抛出了橄榄枝，说实话有种受宠若惊的感觉。同样是来自北京的同学，能力上的差距已然显而易见。我想，自己的步伐既然已经慢了很多，有一位优秀的同学愿意带带我，必然是我受益匪浅，所以欣然接受了他的邀请。
- 毕竟开学第一周，需要忙碌的事着实不少，终于在9月16日周六晚上，在活动室针对本次作业进行了研究讨论。虽然是研究讨论，不过大佬就是大佬，已经准备了很多内容，并且分享了他对于本次作业的大致想法，而我只不过在此基础上，提供了一些建议。当我第一次看到作业内容的时候，不知道具体应该运用什么知识来解决，而队友提出了运用数据库的方式来达到实践目的。的确是比较合适的解决方案，同时也比较简洁，相对应该会比较容易实现。
- 第一次作业，仅仅是个开始，我相信以后我一定可以在队友的引导下，不断提升。
2>我和我的队友
-
讲什么呢…………讲得太多怕坑了他，讲的太少怕他不满意，图太正面感觉毁三观……
-
所以就送一张图吧（正在MockPlus上作讨论）
9.22 更新脑洞设计界面