[Beta阶段]展示博客
一、团队成员简介与个人博客地址
团队博客地址:http://www.cnblogs.com/wowotoubuaa/
江昊,项目经理
http://www.cnblogs.com/haoj/
王开,后端开发
http://www.cnblogs.com/wk1216123/
王春阳,后端开发
http://www.cnblogs.com/wcysoftware/
杨墨犁,前端开发(UI)
http://www.cnblogs.com/pikali/
徐丞,后端开发
http://www.cnblogs.com/ericxuc/
付帅,前端开发
http://www.cnblogs.com/fusluv/
王若愚,前端开发
http://www.cnblogs.com/ruoyuwang/
二、软件工程展示
一) 团队项目目标:
实现一个为北航社团提供社团管理服务,为学生提供社团服务的网站
预期的典型用户:
1.社团管理者小A:通过"北航Clubs"社团后台,创建与发布活动资讯,在收集活动报名同学信息后,进行群发Email及短信操作;管理社员名单;查看活动回复。
2.学生小C:通过"北航Clubs"网站,参加社团或者浏览近期社团活动并报名,报名后收到社团管理者小A发来的活动信息;对活动进行评论,查看站内信。
预期场景描述:
场景一 |
烤漆终于结束了,如释重负的小江想报名参加凌峰社周末的外出活动,但该活动外场报名已经结束,负责人的联系方式也不得而知。就在这时,小江通过朋友的介绍,打开BuaaClubs网站,经过实名注册后,进入到了活动首页。小江迅速找到了凌峰社的外出活动,点击该活动右下角的"我要报名"按钮,弹出提示"报名成功",并在随后受到了凌峰社发送的与该活动相关的短信和email通知。终于,周末又可以出去浪了! |
场景二 |
凌峰社的负责人昊昊,由于凌峰社作为北航最大也最为著名的社团之一,经常举办许多活动,但是由于宣传渠道有限,及时动用了大量的人力物力去做宣传,依旧效果不是很理想。后来,昊昊得知北航社团平台的发布后,他主动联系网站的负责人,为凌峰社建立了后台账号。他登陆进去后,跳转到活动编辑页面,编辑页面简单且易上手,他很快就变写好了一个新的活动事宜,点击"我要发布",这篇活动信息,就出现在了网站展示页面的首页了。 |
场景三 |
作为大一新生的小芳,想要使自己的大学新生活更加丰富多彩,考虑加入几个社团体验一下。但她在百团大战中并没有找到自己心仪的社团。于是,她打开了北航社团平台的网站,进入"社团荟萃"的页面,数十个社团按照不同的分类排列展示出来,小芳兴奋的查看着这些社团发布的一些讯息,很快凌峰社就吸引了她的注意,她迫切的按下了"加入"的按钮,申请加入凌峰社。后来的几天,她收到了凌峰社的面试短信,最终如愿进入了凌峰社的大家庭中。 |
预期用户(实名制)数量:
初期达到50
二) 实际数据
访问量:截至今日 6000+,访客数 658
用户: 已达到初步要求的50个
社团:3个
三)团队合作
分工协作:
前端驱动开发,API处于交互核心位置。
前后端通过后端制定的API文档进行统一交互;前后端内部则继续细分任务,其中前端的动态展示以及后端的Model层实现均采取了结对编程的方式,来保证项目的完成效率与正确性。
成员分工及贡献比
Member |
角色 |
分工 |
具体量化 |
贡献分数 |
江昊 |
PM&DEV |
完成学生界面前端重构,实现较好的用户体验辅助测试若干API |
4000行html 、css代码 |
53 |
杨墨犁 |
DEV |
社团界面的静态实现,通知,历史消息,评论,社员管理 |
47 |
|
付帅 |
DEV |
增加新的社团后台功能,包括社员名单管理、社员申请加入社团审核、发送站内信、导出EXCEL社员名单、查看历史站内信 |
1900行代码(js、界面) |
51 |
王若愚 |
DEV |
增加新的社团后台功能,包括社员名单管理、社员申请加入社团审核、发送站内信、导出EXCEL社员名单、查看历史站内信 |
1500行代码(js、界面) |
48 |
王开 |
DEV&TEST |
二轮API设计文档,二轮数据库设计文档 评论部分,登陆,身份验证,实名验证部分API |
700行rails代码 API文档、数据库设计文档 |
52 |
王春阳 |
DEV&TEST |
实现或修改了通知、站内信、文章以及评论等部分的API,负责Scrum meeting的发布和管理,修改完善二轮API文档 |
700行rails代码 Scrum meeting文档 |
50 |
徐丞 |
DEV&TEST |
实现社团管理部分的API,负责一部分Scrum meeting的发布和管理,测试编写的API |
400行rails代码 Scrum meeting文档 |
49 |
Github管理统计
后端
前端
经验教训:
经验之谈
1.软件架构设计提高开发效率
在进行开发前,我们制定了API文档,规定了API各项参数与细节,使得前端后端可以完全独立开发,互相不受干扰与影响,专注于自己的技术领域,学习成本降低,开发效率提升。
2.任务的细化可以让每个队员都贡献力量
通过API文档,将项目任务细化为前端与后端。
后端采用rails框架,自带MVC结构,后端三人分别去做Model层、Controller以及Router
前端采用界面与JS代码分离开发的方式,将任务分为UI设计与界面实现、界面动态化展示。
于是任务以比较平均的方式细化到每个人身上,为每个人设计了自己的关注焦点,调动起团队的力量。
3.每周例会,不是形式
每周的例会推动项目不断进展。每次到周会前,项目都会"进展神速",实现本周要求的任务。
每周例会主要议题有两个,第一个是该周目标与任务安排,第二个是介绍采用的新的技术方案or开发工具、开发方式。第一个议题,使每个队员明确自己的任务,任务明确,是一个开发人员进行开发的最大动力。第二个议题,使队员知道接下来将如何和队友合作,如何什么样的技术实现将要开发的功能。
比如,我们在讨论用户状态控制时,涉及到后端的Token存储、API调用、前端sessionStorage存储以及header传递身份信息的验证方式,将整个技术流程介绍完毕,前后端队员就理解如何更好的和对方配合了。
教训之谈:
API文档要保证最新且真实可用
作为最重要的团队文档,API文档应该被精心维护,有动态更新应及时告知队友。
团队开发中,比较浪费效率的一次就是后端更改了API的一个参数,没有及时更新API文档,导致前端开发队员苦调半天而无果。
五) 团队如何平衡 时间/质量/资源 争取如期完成任务的
团队整体:PM发挥PM的作用,面对每天的时间,找到优先级,作出判断与分工。团队通过每天的scrum meeting进行总结,对项目安排进行相应调整
前后端开发各自内部:通过个人能力与时间等依据,每天制定计划分工与目标任务。
六) 代码工程质量及数据证明
团队代码的软件工程质量:
- 最终代码地址:https://github.com/buaaclubs-team
关于测试:
在Beta阶段,我们主要进行了如下几种测试:
- 单元测试
- 黑盒测试
- 兼容性测试
- 压力测试
单元测试主要通过rails自带的单元测试框架以及测试人员利用fiddler对请求返回的response进行检查两种方式进行。
Rails自带的单元测试框架,通过编写测试用例,然后执行测试用例并通过。由于Beta阶段实现的API有一些比较复杂,如发送短信,短信等功能。所以,简单的API是通过rails自带的单元测试框架测试的,其余大部分API都是通过fiddler4手动测试。
Fiddler4对API进行测试,测试流程是测试人员在Fiddler4中构造API请求,之后对获得的response body体中的各个参数进行检查,并对测试结果截图记录。以下是测试记录的相关截图:
测试用例1:
Request:
Response:
测试用例2:
Request:
Response:
黑盒测试,主要发现了以下bug:
- 社团成员信息无法自动更新
- 活动成员名单没有对齐
- 历史消息页面中,按钮排版存在问题
- 用户界面中站内信未读问题
兼容性测试,主要针对用户和社团的各个页面进行了浏览器的兼容性测试,测试的浏览器包括:火狐浏览器,IE浏览器,谷歌浏览器,搜狗浏览器
具体可见测试报告 http://www.cnblogs.com/wowotoubuaa/p/5117708.html
压力测试,由于Alpha阶段没有进行对软件的压力测试,所以在Beta阶段我们着重测试了这一方面。压力测试的流程,通过编写的python 脚本程序,同时发送上百条请求,记录请求相应的时间,请求平均响应时间等相关参数。测试对象为功能上比较重要的API。测试的结果显示,对于不同API的500条请求,基本都可以在10s内响应完成,服务器未出现异常情况
具体 http://www.cnblogs.com/wowotoubuaa/p/5117708.html
代码规范:
由于rails本身对代码的规范有许多默认的约定,比如变量,常量的命名,路由,控制器,模型的命名等都有一套默认的规范,我们在进行后端的编写时遵从了rails本身默认的这些约定。并且,对api格式的规范还有注释的要求进行了统一规定。
关于文档:
保存于 https://github.com/buaaclubs-team/share-and-notify
三、 团队项目的进展过程
燃尽图进展趋势
总结:
scrum在大致上反映了我们的项目进度趋势:前期进展平稳顺利,后期因为其他学科的冲击进度放缓;由于迭代日期的原因,TFS任务的更新也出现了一些问题。
四、 团队从用户那里得到了什么反馈,有什么样的bug?这是预料之中的还是没想到的?
1.
这是一个BUG,属于服务器和前端控制的局限,是预料之中的
2.
预料之中,社团后台界面的一些用户体验的局限
3.
社团界面与用户界面是分离的,属于设计上缺陷
五、 相对于M1的改进
M2事后总结:http://www.cnblogs.com/wowotoubuaa/p/5118509.html
六、 总结,整个团队在Alpha阶段学到了什么,对软件工程的教育,对这个具体的课程有什么批评建议?
总结:
- 前后端技术
- 团队协作、沟通交流
- 软工开发模式的理解
批评建议:时间安排不妥当,导致时间资源不充足