[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. 软工开发模式的理解

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