第二次作业——结对项目之需求分析与原型模型设计
031302223 031302331
汇总课表的困扰
针对汇总课表巨大的工作量,我们首先构建了NABCD模型:
一.下面是我们对汇总Excell项目的NABCD模型的理解
1.N(Need,需求)
对象:A.教务处:每个学期中间,第6周,教务处都要发布下学期的开课计划,而如果教务处群发邮件,显得有些麻烦,可以设计一个网站,教务处可以不用群发邮件给老师,减轻工作量。
B.老师:开课计划书以群发邮件的形式发给所有老师后,而老师要在规定的时间内,将自己的名字填入自己希望报的课程的那一行 “任课教师”列,而老师如果不必收邮件,填好再发邮件,只需登陆网站后在线填好开课计划表,想必老师会轻松不少吧。
C.负责人:老师以邮件形式发回给负责人,负责人查阅每封邮件,打开每个excel,查看每个老师的填报,最后手动汇总成一个excel,但是负责人群发邮件、群收邮件、催收邮件、汇总每个老师的excel,工作量巨大。所以,如果能自动汇总老师的开课计划,负责人则省去了繁杂的工作,减轻负责人的压力。
2.A(Approach,方法)
我们小组设计了如下方案:
可以设计一个网站,上面有现成的开课计划表,老师只需要登陆网站填写好自己的开课计划表并提交,负责人只需要一键汇总就可以自动汇总好所有老师提交的开课计划表,考虑到安全性,可以设置账号密码登陆。
考虑到项目前期老师不习惯用网站,那负责人可以用qq邮箱等客户端群发邮件,并提示老师可到网站上提交表格或在线填写。当然,有些老师更倾向于直接填写然后回复邮件,那么我们可以下载下来放到指定的文件夹,最后网站上选择一键汇总即可。
关于服务器方面,倘若负责人不能接触到服务器后台(即不能将文件放到指定文件夹,即只有服务器上该网站的权限),那负责人可以选择重新提交非在线填写表格和上传表格的老师的报名表,在这边我们应做一个可多选多文件的上传窗口,方便负责人操作。
3.B(Benefit,优势)
1.首先这个基本考虑了所有情况并给出了对应的方案,同时在细节处理上给了使用者很大的方便, 方案免去老师收发邮件给负责人繁琐的步骤,只需要填写好自己的开课计划表, 一键提交就行;教务处也不需要群发邮件给各个老师。
2.其次,更减轻了负责人的工作,群收邮件,再一个个汇总工作量太大,而我们设计的方案可以一键完成汇总步骤,难道不是最大的方便吗?
3.再者,负责人在汇总老师的开课计划表时难免会出错,而我们的方案却避免了这样的失误的发生。不仅速度提高了,工作量减轻了,效率也得到了保障。
4.我们团队拥有非常丰富的项目开发经验和比赛参赛经验,在网站和Android客户端的开发上颇有造诣,在项目在技术上完全可行,这也是相对其他小组我们的一个优势。于此同 时,团队成员为同班同学,并多次在一些项目中进行合作,配合默契,能够更合理的安排项目进度和项目分配。
5.团队成员曾参与众多项目的开发,并且研究学习了《构建之法》,能够更准确的把握用户的需求,产品上力争给用户最好的体验。
4.C(Competition,竞争)
我们的竞争对手很明确,其他小组也有他们的好的想法和方案,
主要的竞争对手就是其他优秀的小组。
5.D(Delivery,推广)
完成了NABCD的前四项后,我们就要考虑该如何将我们的成果交付到我们的客户手中,刚开始的时候,可以先小规模的给老师和负责人使用,让用户体会到快速和便捷,同时收集用户的建议和评价实时的改进,力争给用户最好的体验。等到有好的反响时,可以借助学院和老师的力量,宣传和推广到全校使用,因为我们这个是教师应用,我们目前只考虑网上宣传,并且针对人群为各学院教师。当然一个好的产品的推广归根揭底最重要的还是迎合用户的需求和体验,所以我们也会不断地改进,推出我们的V1.1,V1.2,只给用户最好的体验。
二.我们设计的原型模型(Axure Rp)
1.登陆界面,老师可以通过登录界面填写自己的开课计划表
2.登录后,老师可以通过勾选选择自己要开设的课程,然后进行提交
3.老师提交完自己的开课计划后,如果有所变化,可以通过查看课表界面进行修改
4.在个人信息版面,可以修改自己登录的密码
5.以管理员的身份(负责人)登录,可以查看已经提交课表的老师和未提交课表的老师,在截止日期的时候,可以通过一键汇总自动生成课表
三.预期的规划:
1.在前1到2周的时间里,完成初步的设计,实现最基本的功能和界面。
2.接下来,根据客户的反应,不断进行修改,不断完善功能,根据实际情况进行适当的修改。
我们结对时的照片:
四.附件:生成PDF
http://i.cnblogs.com/Files.aspx