BUGLIST管理追踪系统1.0

BUGLIST管理追踪系统1.0
BUG跟踪管理系统1.0需求分析
版本记录
1 设计背景:
为了开发项目的需要,便于项目开发中的协作和相互测试,并能有效追踪BUG,特在比较外面成熟系统的基础上,自己设计和开发一套适合内部小规模使用的BUG追踪系统------Bug 跟踪管理系统1.0.
2 设计目标:
1)1.0版本由于设计时间短,主要是配合论坛该版项目的开展.只要实现对一个5~10的项目开发小组的管理.
2)技术上采用,应用开发组都比较熟悉的ASP来做开发语言,数据库将有SQL SERVER和ACCESS 两个版本,以便于管理和移植.
3)该版本要为以后的升级和扩展提供支持.所以管理页面是采用简洁实用的方案,数据库表设计将严格遵循关系模型.
3 相关概念:
3.1 项目(Project):指有多人配合完成的开发和设计任务.
3.2 模块(Model): 为实现项目功能而细化的,可以为小组成员接受的,定量的开发任务.(一般以一人一天来定义模块的大小).
3.3 项目组(project group):开发同一个项目而在一起分工协作的所有成员的集合.(1.0版本不支持多个项目组).
3.4 系统管理员(Administrator):对系统拥有最高管理的人,他可以批准成立新的项目组,任命新的项目组长,发起新的项目.原则上一个项目组在一次开发生命周期中,只能针对一个项目.(1.0版本不支持改功能).
3.5 项目组长(team leader):对一个项目进行监控的领导,她可以添加新的项目组成员,可以对所有提交测试的模块进行测试.可以分配测试任务.
3.6 开发人员(developer):负责具体模块开发的人,他必须在每天工作结束后,在系统中提交开发的模块,并对需要测试的模块,提交项目组其他人员测试,他可以提交测试备案.对测试人员,返回的BUG报告,进行处理,完成后需要说明处理过程,向测试人员申请BUG关闭
3.7 测试人员(testing):被要求测试某个同一项目组其他成员的开发模块的人.他可以按照约定的测试方法和要求,或按照需求设计要求,进行测试.如果没有问题,他必须记录测试过程和具体结果,或上传自己的该次测试文档,并提交项目组长复核.如果发现BUG,可以提交BUG情况说明,必要时候上传BUG情况截图,返回开发人员修改.对开发人员申请的BUG关闭请求进行复核后,关闭该BUG.
3.8 BUG (bug):一切不符合项目开发需求和设计的错误.
4 功能描述:
4.1 登入功能:系统管理员和项目成员均从这儿登入.
4.1.1 登入权限分配:所有登入者,将按照用户名和密码,验证身份合法性,并分配相应权限后进入自己的管理页面.
4.1.2 登入所属的项目组:成员从正在进行工作的项目组中,挑选可以进入的项目进入,项目成员必须先输入,该项目组约定的验证码后,才能进入.
4.2 系统管理员的操作
4.2.1项目列表:
图4.2.1项目列表
系统管理员的项目列表页面如图4.2.1,点预览可以看项目的详细内容.修改可以进入修改页面,点删除可以逻辑删除该项目.模个项目如果结束,项目组长可以向系统管理员申请关闭,系统管理员点了关闭,则项目将对系统成员关闭,成员将不能登入项目,提交BUG.只有系统管理员点激活,才能重新打开.
4.2.2添加项目
图4.2.2添加项目
每个项目都有唯一的系统生成的序列号,项目名称必须填写.并要设置项目组长.每个项目都有一个该项目成员进入的验证码,默认是1111.其他项目都是选添项目.
4.2.3 用户管理
图4.2.3
系统管理员可以添加系统成员,系统成员有系统管理员,项目组长和成员三类型.登入的系统管理员不可以删除自己本人.这儿可以修改和删除会员.
4.2.3 用户添加
图4.2.3
系统管理员在这儿添加用户,用户的权限有成员,项目组长和系统管理员三类,部门是可选的,可以在部门列表中添加,实现比较简单,就不说明了.emial是必须填写的,系统将对email的合法性进行校验,因为系统中的许多通知功能需要邮件支持,所以信箱合法很重要.
4.3项目组长的管理页面:
4.3.1项目组长登入项目
图4.3.1第一步选择所进入项目,按登入连接
图4.3.2输入该项目的验证码,确认身份
图4.3.3进入该项目的具体管理页面,上面是成员提交的模块列表项目组长的登入具体项目分两步,先登入系统,然后选择所领导项目,这儿要输入验证码确认身份.上面三张图说明了这个过程.
项目组长可以是项目中的开发人员,除拥有成员的所有功能. 还可以添加和删除项目组成员,项目的设置,对申请通过的模块进行复核,并可以在项目结束后,申请关闭该项目.
4.3.4模块详细图
模块详细描写,下面是BUG列表,√表示BUG已经复核通过,被关闭.〤表示BUG待修改.☆表示BUG已经由开发者修正,申请测试人复核.选复核就讲提交项目组长二次复核,决定是否关闭该BUG.点详细将看到BUG的详细信息.具体如下图4.3.4:
图4.3.4模块详细显示
如图描写,有两个说明提交区域,依据进入人员角色来决定开发提交功能.系统建议无论开发,还是测试人员尽量上传BUG修改和测试说明文档.以便于今后详细复核,比较简单的处理过程,可直接填写说明.下面有该模块的BUG列表.模块提交人和项目组长有修改和逻辑删除的权限.模块提交人可以向项目组长申请通过该模块,系统会自动检测该模快是否还有没有关闭的BUG,只有所有BUG都已经处理,并关闭后,该操作才允许.
4.3.5成员添加和管理
图4.3.5.1选择项目成员,是系统成员中权限为成员的都在下拉表中显示.
图4.3.5.2删除和查看项目成员
4.3.6 BUG的提交和管理
BUG是模块中的,不符合项目要求的错误,所以必须先选对应的模块,然后才能进入提交BUG页面.
见图4.3.4,选上面的[提交BUG]连接,可以进入BUG提交页面.
图4.3.6 BUG的提交,这儿填写BUG名称和简要说明,还允许上传6张BUG的说明截图在提交BUG的同时,系统将自动email到模块设计人信箱,提醒他及时处理.
图4.3.6.2所有BUG列表,点BUG号可以进入BUG详细页面
图4.3.6.3BUG详细页面
该页面显示了BUG的详细情况,无论更正人或测试人,都会显示对应的提交说明和文件上传区,以记录和追踪BUG的处理过程,下面有BUG更正和复核的过程列表.该BUG产生的摸块编写人可以在处理BUG后,点[申请关闭BUG],以要求发现该BUG的测试员在复核后关闭该BUG.
4.4项目成员的管理页面:
4.4.1项目成员的项目管理页面
项目成员点模块列表,可以看到自己的模块提价状态,申请测试中有自己提交的要求测试模块的列表,待改BUG中,有要求自己修改的BUG 列表.BUG列表则列出自己提交的所有BUG目前的处理情况,待复核BUG是开发人员已经修改好,等待自己复核确认,申请关闭的BUG.已复核BUG是自己修改好的BUG已经被确认关闭的BUG列表.操作和前面的项目组长没有区别.所有提交的BUG在所在模块的设计人未浏览前均可以允许修改和删除.。