[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进行总结,对项目安排进行相应调整

前后端开发各自内部:通过个人能力与时间等依据,每天制定计划分工与目标任务。

   

六) 代码工程质量及数据证明

团队代码的软件工程质量:

  1. 最终代码地址: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:

  1. 社团成员信息无法自动更新
  2. 活动成员名单没有对齐
  3. 历史消息页面中,按钮排版存在问题
  4. 用户界面中站内信未读问题

 

兼容性测试,主要针对用户和社团的各个页面进行了浏览器的兼容性测试,测试的浏览器包括:火狐浏览器,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阶段学到了什么,对软件工程的教育,对这个具体的课程有什么批评建议?

总结:

  1. 前后端技术
  2. 团队协作、沟通交流
  3. 软工开发模式的理解

批评建议:时间安排不妥当,导致时间资源不充足

原文地址:https://www.cnblogs.com/wowotoubuaa/p/5118380.html