软件工程第三次作业
Posted yigebokeyuan
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件工程第三次作业相关的知识,希望对你有一定的参考价值。
-
本周的作业请参照此文:http://www.ruanyifeng.com/blog/2015/12/git-workflow.html 制定本组项目的GitHub版本更新流程。
-
制定本组的代码规范、GitHub提交源码的标准。
- 组长组织每周例会(可以使用群微信群试验一下每天沟通项目开发进度的方法)需要有证据能够在博客上公布
- 根据邹欣老师的教材相关内容,确定小组成员的角色,细化项目需求、时间计划、列出产品积压工作项和预计开发时间
第一题:制定本组项目的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) 功能需求
- 用户的注册和登录功能。
- 用户输入四则运算,并存储在数据库中。
- 实现四则运算计算功能,并能够进行真分数运算。
- 程序自动生成四则运算式子,满足无负数,无假分数或者小数。
- 输出四则运算式子,并读入用户输入答案,判断正确题数及错误题号。
2) 可用性需求
- 系统可直接在浏览器中中访问,不需要其他软件的支持。
- 当用户进行了错误的操作之后,系统会制动提示用户进行正确的操作。
- 系统开发遵循简洁的理念,所有界面简单明了,无歧义,方便用户可以快速正确的使用被系统。
3) 性能需求
- 程序是在Web平台上开发,最大并发人数2000人,当人数在此范围内时,系统可以很好的运行。
- 当最大访问人数不超过最大并发人数时,并且在网络状况良好的情况下,系统最大响应时间不应超过100ms。
- 小学生四则运算测试系统的后台用户事务的最大处理时间应该是10ms。当超过这个值之后,可能会对用户的体验造成不好的影响。
4) 可靠性需求
- 系统每周运行时间应该达到7*24小时。
- 系统发生严重错误的平均时间间隔应该大于24*7小时。
5) 保障性需求
- 在系统出现漏洞之后,应该在不超过2天的期限内得到解决。
- 本系统完全上线后的一年内,提供的技术支持时间应该是每周8小时*5天。
6) 设计限制需求
系统只能在浏览器中进行访问,每次访问时的所有数据都要重新在服务器中获取。
时间计划
整个系统的完成时间,我们预设在8到9周完成,具体安排如下表所示:
项目的需求还需要不断的完善;项目的编码还属于初期阶段,只实现了部分功能;Git的使用还需要不断深入的学习。
以上是关于软件工程第三次作业的主要内容,如果未能解决你的问题,请参考以下文章