1、软件项目开发总结材料报告材料xxx系统项目开发总结报告任务分配: 缺陷上传,基本信息维护(,) 分配缺陷(,) 解决缺陷,测试缺陷(,)登录,权限设置,统计图绘制(,)2.2、基本流程分析43.1. 主要功能及性能33.2. 数据库结构及设计43.1、开发进度45、参考文献61引言1.1开发目的随着社会的发展与进步,计算机的应用已深入到了社会的各个领域,软件的作用和影响也越来越广泛。同时,软件出错的范围和可能性也越来越大。如何有效的进行软件错误的跟踪、控制和管理,已成为提高软件质量,保证系统正常运行的一个重要手段。BUG管理系统的研发与应用,是为控制和减轻潜在的不利因素对软件项目的影响而采取的
2、一项活动。它用于集中管理和控制软件测试过程中发现的错误,并进行版本控制。通过该系统,将帮助我们更好的收集、跟踪、反馈软件系统在测试、运行过程中的错误和问题。缺陷管理系统作为项目管理的一个重要方法和手段,能有效的帮助人们建立科学的、规范化的项目管理机制。1.2开发背景在WINDOWS操作系统下运行。使用Microsoft Visual Studio 2005开发环境和SQL数据库进行编译和运行。2系统分析BUG管理信息系统是开学初老师给我们提出的项目,由于我们对这个项目很陌生,所以分析阶段持续了长达一个多月的时间,先后改进了6个版本。设计了系统的业务流程图,数据流程图以及数据项和数据流。2.1需
3、求分析 一个BUG管理系统,需要实现几部分的功能:1、缺陷上传,当缺陷被发现后,测试人员可以通过系统进行提交、记录。2、缺陷录入系统后,项目经理应该可以通过系统进行浏览并进行分配。3、项目经理将缺陷问题报告通过系统转交给开发人员,开发人员可以通过系统知道自己负责的修正的缺陷问题报告。 4、缺陷问题的修正处理,当开发人员修复缺陷后,可以通过系统,通知测试人员缺陷已修复。5、对于开发人员无法完成的修改任务,开发人员可以拒绝后并将缺陷问题返回至项目经理重新处理。 6、测试人员对开发人员修复的缺陷进行测试,对于没有修复成功的缺陷重新返回给开发人员修复,对于修复成功的缺陷则关闭存入档案。2.2基本流程分
4、析 通过管理信息系统的自顶向下分析和设计,自底向上逐步实施的思路,我们先将整个软件bug管理系统分为四个业务处理功能:上传、分配、修改、测试;且四个业务处理功能涉及到了测试人员、项目经理、开发人员三个业务处理单位。详细的业务处理过程如下:2.2.1上传缺陷测试人员发现bug后,先查看以前的bug信息,看有没有相同的bug。如果有,则查看此bug的状态,如果是close状态,则将其状态改为reopen,否则将其状态改成reject并结束。如果没有相同的bug,则给出严重级别,并查看所属项目组,根据这些内容填写bug信息表,然后上传bug信息并结束。2.2.2分配缺陷项目经理先查看待分配的缺陷,根
5、据待分配的bug分配任务,分配时需先看是否是开发人员退回:若是则另选开发人员;否则判断是否需要解决:若否则给出解决方案并修改缺陷状态为reject;否则修改缺陷状态为open,再判定是否有相似问题:如果有,则指定给相似问题的开发人员修改;否则判定优先级并分配任务。最后安排修改。2.2.3解决缺陷 开发人员先查看所分配的bug信息 ,然后判断是否要退回bug:如果要退回,则拒绝任务。否则接受任务并给出解决方案、修改bug状态为fixed.最后提交测试。2.2.4缺陷测试 测试人员接收修改结果,给出测试结果,然后判断是否修改通过:如果是,则修改bug信息状态为closed并关闭bug;否则判断是否
6、为新的bug:如果是,则标记此bug,进行上传处理;否则退回给开发人员继续修改。3系统设计设计阶段是在分析阶段成熟之后进行的,真正进入设计阶段画数据流程图的过程中遇到了很多问题,同时也发现了之前分析阶段考虑的很多不足之处。先后改进了3个版本。绘制了SC图,设计了数据库表结构。3.1基本功能3.1.1登录功能实现与服务器的链接配置,在用户的服务器信息发生变动时可以进入配置,配置一次即可,以后可以直接登录使用。根据用户输入的用户名密码,判断是否有权进入,若无权,判断是因为用户名不存在,还是因为密码输错。登录成功后,获取用户的权限,进入主菜单后显示相应权限的菜单项。不拥有权限的菜单项不显示。3.1.
7、2基本信息维护功能 对基本信息如环境配置,人员信息,优先级别,严重级别,模块,角色信息进行管理。3.1.3权限管理功能当模块、权限或者角色发生变动时,可以根据不同的角色进行相关模块的授权与释权。权限设置模块的操作权归管理员所有。3.1.4报表统计功能根据不同的项目绘制某个项目在某个时间段发现的BUG数量的柱状图。3.2数据库结构及设计项目组表(pro_group):序号字段名数据类型是否主键描述1group_numchar(4)是项目组编号2leaderchar(4)否项目组组长项目表(project):序号字段名数据类型是否主键描述1pro_numchar(4)是项目编号2pro_namec
8、har(30)否项目名称3descriptionchar(30)否描述4group_numchar(4)否项目组编号5remarkschar(50),否备注权限表(authority):序号字段名数据类型是否主键描述1authority_numint是权限编号2authority_namechar(20)否权限名角色表(roles):序号字段名数据类型是否主键描述1role_numchar(4)是角色编号2role_namechar(10)否角色名3authoritychar(20)否角色所拥有的权限,如00011110测试环境表(environment):序号字段名数据类型是否主键描述1en
9、_numchar(4)是项目组编号2systemchar(20)否项目组组长3equipchar(50)否设备配置信息严重级别表(severity_level):序号字段名数据类型是否主键描述1severity_numchar(4)是严重级别编号2severity_namechar(15)否严重级别名称优先级别表(priority_level):序号字段名数据类型是否主键描述1priority_numchar(4)是优先级别编号2priority_namechar(15)否优先级别名称分配表(share):序号字段名数据类型是否主键描述1bug_numchar(4)是缺陷编号2unumchar
10、(4)否人员编号3share_timedatetime是分配时间(默认当前时间)4modifydatetime否修改时间缺陷信息表(bugs):序号字段名数据类型是否主键描述1bug_numchar(4)是缺陷序号,唯一标识2en_numchar(4)否缺陷环境编号3statuschar(20)否缺陷状态4descriptionvarchar(100)否描述5pro_numchar(4)否所属项目编号6severity_numchar(4),否严重级别7up_timedatetime否上传时间(默认当前时间)8close_timedatetime否关闭时间9priority_numchar(4
11、)否优先级别10versionchar(10)否版本 所属的版本信息11modularchar(20)否模块 所属的模块12solutionchar(200)否解决方案13remark1char(50)否备注用户表(users):序号字段名数据类型是否主键描述1unumchar(4)是用户编号2unamechar(10)否用户名3group_numchar(4)否所属项目组编号4telchar(11)否电话号码5addressnvarchar(50)否地址6remarkschar(20),否备注7passwordchar(6)否密码8role_numchar(4)否角色编号4系统实现4.1开发
12、进度 时间阶段任务完成度2011.12.31项目起动,分配任务,设计表结构,设计界面进度完成2012.1.3各成员单独进行模块实现进度完成2012.1.4模块整合及测试进度完成2012.1.5小组进行讨论,功能完善进度完成2012.1.6测试程序并答辩进度完成2012.1.7完成项目开发总结报告进度完成4.2实现过程的错误分析1、开始上传界面环境、项目、严重级别等选择时显示的是编号,后来发现,编号对于用户来说并不懂其中的含义,需转换成具体的名称。所以将其关联到对应的环境表,项目表,严重级别表等,让用户可读取到其名称。2、由于编号都是“0001”,“0002”这样以“0”开头的字符串,而不是数字
13、,不能直接自增。通过网上查了相关资料,参考了其他人的代码,发现可以用right函数,选择右面的非空位,然后再加上“1”,编写这样的存储过程,完成编号的自增。还有老师要求数据库中的表得是英文,而前台的表得是中文,最开始我们不懂在C#环境下如何把列名从英文转换成中文,后来发现拉数据源后,可在其SQL的“select”语句中,添加“as”字段,将其列名转化成汉语,显示在dbgrild中。3、在任务分配界面上忽略了一些细节,查询缺陷时,没有显示项目经理要分配的所有项目,当项目经理分配完一个项目后,表中则删除掉一条,这样看起来更加直观。而在这次专周所做的实验,刚开始并没有考虑到这些,仅以个人的观点去看待
14、,没有以项目经理的角度去,所以整个界面还不够完善。由于运用到临时表,刚开始分配的缺陷保存在临时表中时,如果再次选择跟临时表中一样的缺陷时,依然可以实行,为了解决这个问题,在分配的存储过程中又加以修改,将查询选中的缺陷是否存在在临时表中,如果存在则出现提示框,保证缺陷分配给指定的人员。4、解决缺陷和缺陷测试的实现过程中时间数据考虑的不周,忽略了时间的设定,应该限制修改时间迟于分配时间;bug描述、解决方案不应该用textbox控件,信息查看不方便;用于选择查询的类型太少。5、绘制统计图模块因为以前都没有接触过,所以这方面的知识完全是全新的,通过学习后知道ZedGraphClass控件在绘制二位柱
15、状图时需要获得两列多行的数据,理清思路后使用临时表暂时储存查询统计的数值,在对临时表进行查询,将结果返回给控件进行显示。在操作过程中在时间的换算上不知道该如何更进,通过XX,知道时间更进只需进行简单的加减运算就可以达到效果了。6、在授权模块中,由于读取角色的字符串后使用str.length获得字符串的长度,通过长度进行循环访问authority表,但是循环结果与预期的并不一样,后来通过查找才发现原来str.length获得的字符串长度是整个字段长度,而不是实际存放的字符串长度,于是通过增加if语句进行控制循环。4.3后期完善1、在答辩前,密码是通过自定义的函数实现加密,经过分析发现这种加密方式
16、并不安全,改换成使用SQL自带的加密函数pwdencrypt()进行加密,在进行登录的密码匹配时使用pwdcompare()函数。在操作上更加简便,而且加密效果更加安全。2、在对表进行增删改查时,很多字段用户是不能更改的。例如编号等主码,这时应该将其用来显示的text的属性改成只读,而不能是可读可写。还有,在上传时,没添加一个bug,其text和combobox等填写框都应该清空,这样可以尽可能的减少误操作。否则用户可能添加只有编号不同,内容却相同的bug。5参考文献6小组总结为期一周的专周结束了,在答辩过后,我们小组开了小会,讨论了这次专周的收获和不足。总的来说这次的专周完成得还是比较顺利的
17、,虽然BUG管理系统的开发对我们来说是比较陌生的,但是由于一学期的分析设计,我们掌握了业务流程,数据流程,以及模块划分的思路,所以大家在开发过程中整体流程和目的都比较明确。不过有一点,由于在专周之前是考试周,所以大家都没有对专周进行提前研究,项目计划没有很详细的安排出来。在第一天专周的时候还是比较乱的,后面及时的设计了项目计划,表结构,分配了各个成员的任务。后期因为命名的规范不是很严格,导致后来代码拼接以及结尾工作时遇到了一些问题,消耗了部分时间。不过大家一起交流讨论,问题也很顺利的得到了解决。以后在进行系统开发的时候会更加的注意前期项目开发计划的制定,以及制定并严格的执行代码规范。这是第一次以小组的形式进行的专周,在开发过程中不仅加深了我们对上学期管理信息系统这门课所学知识的理解和认识,同时也加强了我们的团队协同合作能力,通过大家的一起交流也开拓了思路。希望以后可以有更多这种小组合作的机会,
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1