[Beta阶段]展现博客

1、团队成员简介与我的博客地址

团队博客地址：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/ 

 

   

2、软件工程展现

一） 团队项目目标：
实现一个为北航社团提供社团管理服务，为学生提供社团服务的网站

      预期的典型用户：
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

 

   

3、   团队项目的进展过程

燃尽图进展趋势

   

  总结：

scrum在大体上反映了咱们的项目进度趋势：前期进展平稳顺利，后期由于其余学科的冲击进度放缓；因为迭代日期的缘由，TFS任务的更新也出现了一些问题。

   

   

4、  团队从用户那里获得了什么反馈，有什么样的bug？这是预料之中的仍是没想到的？

1.

这是一个BUG，属于服务器和前端控制的局限，是预料之中的

2.

预料之中，社团后台界面的一些用户体验的局限

3.

社团界面与用户界面是分离的，属于设计上缺陷

 

 

5、 相对于M1的改进

M2过后总结：http://www.cnblogs.com/wowotoubuaa/p/5118509.html

 

 

6、 总结，整个团队在Alpha阶段学到了什么，对软件工程的教育，对这个具体的课程有什么批评建议？

总结：

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

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