结队项目——第一次作业

结队项目——第一次作业

1. 结对成员：

031502614 赖志平
031502627 王国华

2. NABCD

N (Need, 需求)

首先，提出的需求如下：

要解决的困扰：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
学生的筛选和淘汰规则：

• 部门纳新人数和面试时间必须事先申报确定；
• 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
• 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
• 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
• 未参加部门面试的学生不能纳入部门。

要解决的问题是：让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。

这个系统应当分成学生端和部门端来做。
首先是学生端，根据提出的需求，学生可能会碰到的问题有：部门活动时间冲突、加入部门时不了解部门、由于活动时间冲突请假次数过多被淘汰。首先，在学生报部门的时候应当集中写出部门的介绍，并且将部门的常规活动时间统一以类似课程表的形式直观地列出来，方便学生在申请部门的时候比对参考。在学生加入部门之后，可以直观地看到活动时间表，如果有重复的活动可以选择请假，在同一个部门请假第 6 次的时候系统会提示再次请假会被淘汰。
部门端则需要申请纳新、管理学生，包括学生的评分和淘汰、还有活动的申请。
部门和学生之间要双向选择，部门之间要有一些信息的交流。

A (Approach, 做法)

首先，学生端主要的就是对部门的了解以及申请部门的时候考虑到时间的因素。我们就需要把部门的信息按照统一的标准来收集并展示给学生。
部门段最主要的就是在活动上的协调。我们在部门申请活动时可以看到其他部门已经安排好的时间，并且可以看到各个活动中自己部门的成员的参与人数，可以参考参与人数来安排活动，保证最多的学生可以参加活动。这一部分真正实现的话应该会使用数据库来提供数据，不过这都是后话了。

B (Benefit, 好处)

这样的设计首先保证了学生可以根据部门活动的时间、自己的兴趣来选择参加的部门。这样基本上可以避免学生部门活动冲突的现象。只有学生在提交申请之后才有机会进入部门。在学生请假的时候加以提醒来防止学生请假次数过多而被淘汰。
对于部门，系统可以方便的管理学生，在设定活动时间的时候也可以查看其他部门的时间，保证最多的学生可以参加，保障了部门之间的信息交流。
这些设计首先满足了提出的需求，并且功能分类较为清除，方便之后添加功能，便于维护。

C (Competitions, 竞争)

我们的系统的优势之处在于部门与部门、部门与学生之间打破了信息隔绝，可以直观地进行信息交流，避免了之前的稀里糊涂的情况。并且我们的系统仿照教务处的逻辑，可以直接放入易班学工处或者教务处的系统，更加利于使用。

D (Delivery, 推广)

至于推广，由于我们的系统是仿照教务处系统的模式，可以直接加入易班。易班是每个学生都有账号的，很多学生工作、各类申请、学习、住宿等事宜都可以登陆易班系统来解决。部门属于学生工作的范畴，放入易班十分方便，并且只需要很少的推广就可以普遍使用。

3. 原型系统

在经过需求分析后，我们得出了得出了这个系统的主要的功能，并据这些功能设计出了一个基本的原型系统，原型系统采用Asure8.0RP制作，主要包括了部门端和用户端两个版本，首先每个部门都有一个管理本部门的账号，部员也有一个自己账号。部门账号登进去为部门端界面，部员登进去为学生端，下面分别结合作出的原型进行说明：

学生端

首先登录进去为欢迎界面，点击并且有三个按钮：部门简介，我的报名和部门活动。
点击部门活动界面，会出现很多个框，每个框里有各部门的简介。
如果是在纳新期，则在我的报名界面可以进行填下相应的报名信息，为了防止因时间冲突而被淘汰的情况，下面还有每个部门的活动时间作为填报的参考，如果填写的五个志愿有时间冲突的，会在有冲突的志愿后面进行提醒，保证填写的志愿的有效性；如果是在非纳新期，此界面将被锁定。无法填写。

最后一个界面是部门活动界面。活动的相关内容用表格的形式进行显示，同时标明是常规活动还是临时活动。
如果请假可以点击相应活动的请假按钮，如果要是常规活动会给出在该部门请假的次数，并给出提醒，超过6次请假会提醒已被部门淘汰，并且不再接受此部门的活动信息。

部门端

首先登录进去为欢迎界面，点击并且有四个按钮：部门管理，活动管理，成员活动和申诉情况。

部门管理界面可以看到部门的相关信息。

活动管理界面可以进行活动的申请，还可以看到其它部门的活动情况以及自己部门的部员在这些部们中的人数，方便安排，减少时间上的冲突。

在成员管理界面可以看到相应的部门成员面试，请假等的信息。可以在这个页面里看到学生的具体情况，看到学生请假次数和违纪次数，并且可以操作，移除成员或者将移除的成员恢复。

如果还未进行纳新，那还可以点击纳新申请，提出纳新的申请，包括时间地点，纳新人数等。只有在规定的时间内才会允许纳新。

4. PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟	实际耗时（分钟
Planning	计划	20	20
.Estimate ·	估计这个任务需要多少时间	20	20
Development	开发	1080	1080
.Analysis	需求分析 (包括学习新技术)	600	600
.Design Spec	生成设计文档	20	20
.Design Review	设计复审 (和同事审核设计文档)	30	30
.Coding Standard	代码规范 (为目前的开发制定合适的规范)	30	30
.Design	具体设计	20	60
.Coding	具体编码	100	120
.Code Review	代码复审	80	80
.Test	测试（自我测试，修改代码，提交修改）	80	80
Reporting	报告	80	60
.Test Report	测试报告	30	30
.Size Measurement	计算工作量	20	20
.Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	30	30
合计		1180	1240

5. 讨论照片

姿势比较怪，但是这不是重点，重点是那认真的小眼神。

6. 心得体会

志平

     软工的作业真的是名不虚传，不过大作业和小作业都是能够让人熬夜，每次都有新的东西。这次的设计部门管理系统，从需求分析阶段到实际的原型的出来，经过三四个晚上的夜战，终于大部分实现。由于我们采用的是Asure RP，这款软件的用法相对墨刀等来说上手难度我觉得是比较大的，花了大量时间在学习这款软件上，同时我们选择的是网页版的设计，这对于我们的设计更是提出了很大的挑战，现在初步原型出来，我觉得尽管还有些地方我们还是没有真正地考虑到，希望客户在看到了我们的原型后能够给我们提供提供进一步的改进意见，同时也是十分期待下一次的编码实现阶段，能够真正地把这些功能实现。

国华

    这一次的结对首先学会了设计一个项目的始末，包括需求分析，具体功能，实现方式，产品的逻辑的分析。学会了 Axure 的使用，虽然还有瑕疵但是已经基本成型，也考虑了未来会有的一些功能。这是我第一次结队作业，结队作业就要和对方沟通交流好，互相检查，互相学习。在开始的时候一起分析交流产品的细节，在实现的时候做出来一点就要和对方分享，对方有好的地方可以借鉴，有缺漏的地方也可以提醒自己。这一次只是做出来一个原型，还不是真正的编程，十分期待未来结队编程的作业，感触与收获应该会比现在更多。