软件工程第三次作业

1. 本周的作业请参照此文：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html 制定本组项目的GitHub版本更新流程。

2. 制定本组的代码规范、GitHub提交源码的标准。

3. 组长组织每周例会（可以使用群微信群试验一下每天沟通项目开发进度的方法）需要有证据能够在博客上公布
4. 根据邹欣老师的教材相关内容，确定小组成员的角色，细化项目需求、时间计划、列出产品积压工作项和预计开发时间

 第一题：制定本组项目的GitHub版本更新流程

　　通过学习链接中的内容，发现总共有三种管理方案：git flow， github flow和gitlab flow。

　　对于git flow，这种管理方案采用了develop 和 master分支作为长期分支。另外有功能开发，补丁和预期发布的短期分支。这种管理方法的问题在于master分支和develop两个长期分支实际差别不大，造成了功能冗余，提高了维护代价。

　　Github flow采用master作为主分支，并将其作为保护分支。意味着如果需要将其他分支merge到master分支上，需要提交pull request，得到批准之后，才可以完成merge操作。这样的管理方案，可以有效地保护master分支上的代码质量。

　　最后提到了Gitlab flow。这种管理方案采用上游优先的原则，所有的分支的上游master分支。只要master分支采用的变化，才可以应用到其他分支。该方法建议针对不同的环境建立不同的分支，例如pre-production分支。

　　我们小组打算使用java构建web框架，实现一个网站。在网页上实现四则运算。所以我们打算采用github 和gitlab flow结合的方法。我们采用master作为项目主分支，并将其作为保护分支，向master提交代码需要提交pull request。另外建立development分支，作为开发分支。另外根据开发用途，创立frontDev 和 backDev两个分支，分别用于前端代码开发和后端代码开发。两个将测试成功的代码并入development分支中。另外，所有分支开发都以master分支作为基准，其他分支的开发环境根据master代码变化而变化。最后创建debug分支，用于消除issue中提到的bug。当debug分支上有bug修缮，需要及时和master分支同步（此时需要提交pull request）。

　　对于成员本地git库，需要根据自己的开发需求创立本地分支，这里不做硬性要求。例如debug， master和test分支。小组分支使用状况如下。FrontDev和 backDev分支部分功能开发完成并通过测试后，提交pull request将DEV和这两个分支merge起来，进行进一步测试。

第二题：代码规范

编码规范　　

　　1、去除没有用到的类引用
　　2、格式化代码,使之符合一般代码标准
　　3、删掉无用的老代码，不保留编写过得废弃模块，减少空间占用
　　4、适量使用空行，使代码格式变得清晰
　　5、提高代码的重用率
　　6、对于变量的命名，尽量使用大家都能看懂的全称
　　7、尽量把所有的定义都放在一起，方便查找
　　8、拆分大类，使类功能尽可能的精简
　　9、规范的注释类信息，使用同一的模板规则
　　10、为不容易理解类变量注释
　　11、注释代码段，注释逻辑选择
源码标准：
　　1、编写的代码使之符合代码规范
　　2、提交的代码应已实现该模块功能并且已完成相应测试，避免上传无用代码

第三题：组长组织每周例会（可以使用群微信群试验一下每天沟通项目开发进度的方法）需要有证据能够在博客上公布

    

    

    

    

 第四题：根据邹欣老师的教材相关内容，确定小组成员的角色，细化项目需求、时间计划、列出产品积压工作项和预计开发时间

小组成员角色安排

在此次软件工程项目中，我们小组成员对于角色的分配，是由自己选取自己感兴趣的职位，在此次项目中，大家也在不停地尝试互换职位，试着在不同的职位上体验不同的感受，因此在小组模式上来讲，我们小组更像是业余剧团模式。下表记录这小组目前成员职位分配：

成员	邓杰	陈宗雷	李艳薇	范世良	王博
角色	项目管理者 、模块设计	需求分析和管理、文档编写	界面设计、测试、程序员	架构设计、程序员、测试	集成测试人员

 

 

 

 

细化项目需求

1) 功能需求

1. 用户的注册和登录功能。
2. 用户输入四则运算，并存储在数据库中。
3. 实现四则运算计算功能，并能够进行真分数运算。
4. 程序自动生成四则运算式子，满足无负数，无假分数或者小数。
5. 输出四则运算式子，并读入用户输入答案，判断正确题数及错误题号。

2) 可用性需求

1. 系统可直接在浏览器中中访问，不需要其他软件的支持。
2. 当用户进行了错误的操作之后，系统会制动提示用户进行正确的操作。
3. 系统开发遵循简洁的理念，所有界面简单明了，无歧义，方便用户可以快速正确的使用被系统。

3) 性能需求

1. 程序是在Web平台上开发，最大并发人数2000人，当人数在此范围内时，系统可以很好的运行。
2. 当最大访问人数不超过最大并发人数时，并且在网络状况良好的情况下，系统最大响应时间不应超过100ms。
3. 小学生四则运算测试系统的后台用户事务的最大处理时间应该是10ms。当超过这个值之后，可能会对用户的体验造成不好的影响。

4) 可靠性需求

1. 系统每周运行时间应该达到7*24小时。
2. 系统发生严重错误的平均时间间隔应该大于24*7小时。

5) 保障性需求

1. 在系统出现漏洞之后，应该在不超过2天的期限内得到解决。
2. 本系统完全上线后的一年内，提供的技术支持时间应该是每周8小时*5天。

6) 设计限制需求

系统只能在浏览器中进行访问，每次访问时的所有数据都要重新在服务器中获取。

时间计划

整个系统的完成时间，我们预设在8到9周完成，具体安排如下表所示：

  

项目的需求还需要不断的完善；项目的编码还属于初期阶段，只实现了部分功能；Git的使用还需要不断深入的学习。