第五次作业--原型设计

成员:陈非易 031502504 张峻雄 031502539
——————————————————————————
PDF附件https://pan.baidu.com/s/1qYRuCva

---

关于题目的初步想法：
-这个应用设计的目的是让部门更够更有效率的筛选符合条件的部员，同时让学生和部门能够得到对等而充分的信息

---

NABCD模型：

Need

• 部门需要更有效率的筛选部员同时学生需要了解部门信息的有效渠道
• 就比如最近我们学校的社团正在纳新，那么大多数部门是如何宣传自己部门的呢？是的，扫楼，而事实上这是个效率极低的方式，因为部门正处于青黄不接的阶段，可用人手少，新生又多，推广起来费时费力。一个部门的扫楼一般来说要耗费两三个晚上的时间。
  -与此同时，是学生对部门的不了解，各个部门接踵而至，光开门就能让新生开到烦，更不用说他们初至大学，一切都要适应，扫楼的行为实际上一定程度打扰到了新生。这种情况下指望部门成员三言两语就将部门直观地剖析开来是不现实的，新生能了解到的部门信息有限。
  -话分两头，部门对于新生信息的收集不够充足也是一大问题，大多数部门因为扫楼匆忙，在让新生填表的时候一般都只是姓名手机和所在系。收集到的信息少，以至于很多可以在纸面上体现出来的信息都需要在面试时再进行提问。

Approach

• 将应用分成部门端和学生端，双方的信息能够实现交互更新。
• 学生端新生在使用时要先把自己的信息填写完毕才能进行下一步操作，这样子确保每一个新生的信息都能够得到准确的收集，方便筛选。
• 学生端集成了所有部门的信息，方便学生查看。
• 部门端能够查看到报名的新生信息，同时有自己的部员表，部员表有淘汰功能，方便部门对表现不合格的部员予以淘汰，比如缺席会议5次以上。

Benefit

• 这个软件并不需要四路泰坦来带动它。
• 我们本身就是这款软件的使用者，可以根据实际情况实时调整软件的功能。
• 这个软件虽然简陋，但是完全免费，也不会出现商城之类的东西。

Competitors

• 相似的软件很容易就能制作，缺乏难以复制的核心技术
• 没有足够吸引人的“杀手功能”，一旦有其它方面更好的相似软件，用户很容易流失。

Delivery

• 试点。目前正值学校学生社团迎新的时间，可以通过在部门任职的同学进行小范围试验，在证明这款软件能力的同时可以依靠这些初期反馈迅速调整软件的一些瑕疵。
• 通过小范围的试点进一步辐射扩散用户范围。层层推广。

---

原型模型

模型采用Axure Rp制成，选用Axure Rp的原因因为这是博文里推荐的第一款软件，同时使用也比较简单，也有汉化。

• 选择登录界面
  

• 学生端界面
  
  

• 学生个人信息
  

• 学生查询部门信息,同时可以报名
  
  

• 学生可于学生端向部门请假
  
  

• 部门端界面
  

• 部门信息，用于向学生端推送本部门信息
  

• 部员信息（可以在此淘汰部员）
  

• 新生报名信息
  
  
  

• 对部员请假申请进行操作
  

---

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	25
Estimate	估计任务时间	30	30
Development	开发	240	260
Analysis	需求分析	120	150
Design	生成设计文档	30	60
Design Review	设计复审	20	25
Coding Standard	代码规范	0	0
Design	具体设计	60	80
Coding	具体编码	0	0
Code Review	代码复审	0	0
Test	测试	0	0
Reporting	报告	120	120
Test Repor	测试报告	30	30
Size Measurement	计算工作量	20	30
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	40	40
合计		740	850

---

与队友

• 作业一发布我就联系了同班同学，很快地组成了一组来完成此次作业
• 大佬很快地来到本鶸的宿舍进行了这次作业的讨论
  

---

关于本次作业
-这次作业，有点像是在做一个界面，事实上又不是，要把每个页面内部相连起来，即把这个程序的原型和构架展现出来，总体来说比较简单
-需要注意的是即使新生通过筛选变成部员，部员仍是有淘汰机制的，像比如缺席6次会议就要给予淘汰。所以在部门端需要有相应的功能，不能忽略
-虽说大致做出了个原型，但是如果要真正的实现原型中所体现的功能，对于目前的我们来说还是有难度的，需要继续学习