软件项目开发总结报告.docx

上传人:b****6 文档编号:13095555 上传时间:2023-06-11 格式:DOCX 页数:15 大小:107.78KB
下载 相关 举报
软件项目开发总结报告.docx_第1页
第1页 / 共15页
软件项目开发总结报告.docx_第2页
第2页 / 共15页
软件项目开发总结报告.docx_第3页
第3页 / 共15页
软件项目开发总结报告.docx_第4页
第4页 / 共15页
软件项目开发总结报告.docx_第5页
第5页 / 共15页
软件项目开发总结报告.docx_第6页
第6页 / 共15页
软件项目开发总结报告.docx_第7页
第7页 / 共15页
软件项目开发总结报告.docx_第8页
第8页 / 共15页
软件项目开发总结报告.docx_第9页
第9页 / 共15页
软件项目开发总结报告.docx_第10页
第10页 / 共15页
软件项目开发总结报告.docx_第11页
第11页 / 共15页
软件项目开发总结报告.docx_第12页
第12页 / 共15页
软件项目开发总结报告.docx_第13页
第13页 / 共15页
软件项目开发总结报告.docx_第14页
第14页 / 共15页
软件项目开发总结报告.docx_第15页
第15页 / 共15页
亲,该文档总共15页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

软件项目开发总结报告.docx

《软件项目开发总结报告.docx》由会员分享,可在线阅读,更多相关《软件项目开发总结报告.docx(15页珍藏版)》请在冰点文库上搜索。

软件项目开发总结报告.docx

软件项目开发总结报告

xxx系统

项目开发总结报告

 

任务分配:

缺陷上传,基本信息维护(,,,)

分配缺陷(,,)

解决缺陷,测试缺陷(,,)

登录,权限设置,统计图绘制(,,)

 

2.2、基本流程分析……………………………………………………………………………4

 

3.1.主要功能及性能…………………………………………………………………………3

3.2.数据库结构及设计………………………………………………………………………4

3.1、开发进度…………………………………………………………………………………4

 

5、参考文献………………………………………………………………………………………6

 

1引言

1.1开发目的

随着社会的发展与进步,计算机的应用已深入到了社会的各个领域,软件的作用和影响也越来越广泛。

同时,软件出错的范围和可能性也越来越大。

如何有效的进行软件错误的跟踪、控制和管理,已成为提高软件质量,保证系统正常运行的一个重要手段。

BUG管理系统的研发与应用,是为控制和减轻潜在的不利因素对软件项目的影响而采取的一项活动。

它用于集中管理和控制软件测试过程中发现的错误,并进行版本控制。

通过该系统,将帮助我们更好的收集、跟踪、反馈软件系统在测试、运行过程中的错误和问题。

缺陷管理系统作为项目管理的一个重要方法和手段,能有效的帮助人们建立科学的、规范化的项目管理机制。

1.2开发背景

在WINDOWS操作系统下运行。

使用MicrosoftVisualStudio2005开发环境和SQL数据库进行编译和运行。

2系统分析

BUG管理信息系统是开学初老师给我们提出的项目,由于我们对这个项目很陌生,所以分析阶段持续了长达一个多月的时间,先后改进了6个版本。

设计了系统的业务流程图,数据流程图以及数据项和数据流。

2.1需求分析

一个BUG管理系统,需要实现几部分的功能:

1、缺陷上传,当缺陷被发现后,测试人员可以通过系统进行提交、记录。

2、缺陷录入系统后,项目经理应该可以通过系统进行浏览并进行分配。

3、项目经理将缺陷问题报告通过系统转交给开发人员,开发人员可以通过系统知道自己负责的修正的缺陷问题报告。

4、缺陷问题的修正处理,当开发人员修复缺陷后,可以通过系统,通知测试人员缺陷已修复。

5、对于开发人员无法完成的修改任务,开发人员可以拒绝后并将缺陷问题返回至项目经理重新处理。

6、测试人员对开发人员修复的缺陷进行测试,对于没有修复成功的缺陷重新返回给开发人员修复,对于修复成功的缺陷则关闭存入档案。

2.2基本流程分析

通过管理信息系统的自顶向下分析和设计,自底向上逐步实施的思路,我们先将整个软件bug管理系统分为四个业务处理功能:

上传、分配、修改、测试;且四个业务处理功能涉及到了测试人员、项目经理、开发人员三个业务处理单位。

详细的业务处理过程如下:

2.2.1上传缺陷

测试人员发现bug后,先查看以前的bug信息,看有没有相同的bug。

如果有,则查看此bug的状态,如果是close状态,则将其状态改为reopen,否则将其状态改成reject并结束。

如果没有相同的bug,则给出严重级别,并查看所属项目组,根据这些内容填写bug信息表,然后上传bug信息并结束。

2.2.2分配缺陷

项目经理先查看待分配的缺陷,根据待分配的bug分配任务,分配时需先看是否是开发人员退回:

若是则另选开发人员;否则判断是否需要解决:

若否则给出解决方案并修改缺陷状态为reject;否则修改缺陷状态为open,再判定是否有相似问题:

如果有,则指定给相似问题的开发人员修改;否则判定优先级并分配任务。

最后安排修改。

2.2.3解决缺陷

开发人员先查看所分配的bug信息,然后判断是否要退回bug:

如果要退回,则拒绝任务。

否则接受任务并给出解决方案、修改bug状态为fixed.最后提交测试。

2.2.4缺陷测试

测试人员接收修改结果,给出测试结果,然后判断是否修改通过:

如果是,则修改bug信息状态为closed并关闭bug;否则判断是否为新的bug:

如果是,则标记此bug,进行上传处理;否则退回给开发人员继续修改。

3系统设计

设计阶段是在分析阶段成熟之后进行的,真正进入设计阶段画数据流程图的过程中遇到了很多问题,同时也发现了之前分析阶段考虑的很多不足之处。

先后改进了3个版本。

绘制了SC图,设计了数据库表结构。

3.1基本功能

3.1.1登录功能

实现与服务器的链接配置,在用户的服务器信息发生变动时可以进入配置,配置一次即可,以后可以直接登录使用。

根据用户输入的用户名密码,判断是否有权进入,若无权,判断是因为用户名不存在,还是因为密码输错。

登录成功后,获取用户的权限,进入主菜单后显示相应权限的菜单项。

不拥有权限的菜单项不显示。

3.1.2基本信息维护功能

对基本信息如环境配置,人员信息,优先级别,严重级别,模块,角色信息进行管理。

3.1.3权限管理功能

当模块、权限或者角色发生变动时,可以根据不同的角色进行相关模块的授权与释权。

权限设置模块的操作权归管理员所有。

3.1.4报表统计功能

根据不同的项目绘制某个项目在某个时间段发现的BUG数量的柱状图。

3.2数据库结构及设计

项目组表(pro_group):

序号

字段名

数据类型

是否主键

描述

1

group_num

char(4)

项目组编号

2

leader

char(4)

项目组组长

项目表(project):

序号

字段名

数据类型

是否主键

描述

1

pro_num

char(4)

项目编号

2

pro_name

char(30)

项目名称

3

description

char(30)

描述

4

group_num

char(4)

项目组编号

5

remarks

char(50),

备注

权限表(authority):

序号

字段名

数据类型

是否主键

描述

1

authority_num

int

权限编号

2

authority_name

char(20)

权限名

角色表(roles):

序号

字段名

数据类型

是否主键

描述

1

role_num

char(4)

角色编号

2

role_name

char(10)

角色名

3

authority

char(20)

角色所拥有的权限,如00011110

测试环境表(environment):

序号

字段名

数据类型

是否主键

描述

1

en_num

char(4)

项目组编号

2

system

char(20)

项目组组长

3

equip

char(50)

设备配置信息

严重级别表(severity_level):

序号

字段名

数据类型

是否主键

描述

1

severity_num

char(4)

严重级别编号

2

severity_name

char(15)

严重级别名称

优先级别表(priority_level):

序号

字段名

数据类型

是否主键

描述

1

priority_num

char(4)

优先级别编号

2

priority_name

char(15)

优先级别名称

分配表(share):

序号

字段名

数据类型

是否主键

描述

1

bug_num

char(4)

缺陷编号

2

unum

char(4)

人员编号

3

share_time

datetime

分配时间(默认当前时间)

4

modify

datetime

修改时间

缺陷信息表(bugs):

序号

字段名

数据类型

是否主键

描述

1

bug_num

char(4)

缺陷序号,唯一标识

2

en_num

char(4)

缺陷环境编号

3

status

char(20)

缺陷状态

4

description

varchar(100)

描述

5

pro_num

char(4)

所属项目编号

6

severity_num

char(4),

严重级别

7

up_time

datetime

上传时间(默认当前时间)

8

close_time

datetime

关闭时间

9

priority_num

char(4)

优先级别

10

version

char(10)

版本所属的版本信息

11

modular

char(20)

模块所属的模块

12

solution

char(200)

解决方案

13

remark1

char(50)

备注

用户表(users):

序号

字段名

数据类型

是否主键

描述

1

unum

char(4)

用户编号

2

uname

char(10)

用户名

3

group_num

char(4)

所属项目组编号

4

tel

char(11)

电话号码

5

address

nvarchar(50)

地址

6

remarks

char(20),

备注

7

password

char(6)

密码

8

role_num

char(4)

角色编号

4系统实现

4.1开发进度

时间

阶段任务

完成度

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”开头的字符串,而不是数字,不能直接自增。

通过网上查了相关资料,参考了其他人的代码,发现可以用right函数,选择右面的非空位,然后再加上“1”,编写这样的存储过程,完成编号的自增。

还有老师要求数据库中的表得是英文,而前台的表得是中文,最开始我们不懂在C#环境下如何把列名从英文转换成中文,后来发现拉数据源后,可在其SQL的“select”语句中,添加“as”字段,将其列名转化成汉语,显示在dbgrild中。

3、在任务分配界面上忽略了一些细节,查询缺陷时,没有显示项目经理要分配的所有项目,当项目经理分配完一个项目后,表中则删除掉一条,这样看起来更加直观。

而在这次专周所做的实验,刚开始并没有考虑到这些,仅以个人的观点去看待,没有以项目经理的角度去,所以整个界面还不够完善。

由于运用到临时表,刚开始分配的缺陷保存在临时表中时,如果再次选择跟临时表中一样的缺陷时,依然可以实行,为了解决这个问题,在分配的存储过程中又加以修改,将查询选中的缺陷是否存在在临时表中,如果存在则出现提示框,保证缺陷分配给指定的人员。

4、解决缺陷和缺陷测试的实现过程中时间数据考虑的不周,忽略了时间的设定,应该限制修改时间迟于分配时间;bug描述、解决方案不应该用textbox控件,信息查看不方便;用于选择查询的类型太少。

5、绘制统计图模块因为以前都没有接触过,所以这方面的知识完全是全新的,通过学习后知道ZedGraphClass控件在绘制二位柱状图时需要获得两列多行的数据,理清思路后使用临时表暂时储存查询统计的数值,在对临时表进行查询,将结果返回给控件进行显示。

在操作过程中在时间的换算上不知道该如何更进,通过XX,知道时间更进只需进行简单的加减运算就可以达到效果了。

6、在授权模块中,由于读取角色的字符串后使用str.length获得字符串的长度,通过长度进行循环访问authority表,但是循环结果与预期的并不一样,后来通过查找才发现原来str.length获得的字符串长度是整个字段长度,而不是实际存放的字符串长度,于是通过增加if语句进行控制循环。

4.3后期完善

1、在答辩前,密码是通过自定义的函数实现加密,经过分析发现这种加密方式并不安全,改换成使用SQL自带的加密函数pwdencrypt()进行加密,在进行登录的密码匹配时使用pwdcompare()函数。

在操作上更加简便,而且加密效果更加安全。

2、在对表进行增删改查时,很多字段用户是不能更改的。

例如编号等主码,这时应该将其用来显示的text的属性改成只读,而不能是可读可写。

还有,在上传时,没添加一个bug,其text和combobox等填写框都应该清空,这样可以尽可能的减少误操作。

否则用户可能添加只有编号不同,内容却相同的bug。

5参考文献

 

6小组总结

为期一周的专周结束了,在答辩过后,我们小组开了小会,讨论了这次专周的收获和不足。

总的来说这次的专周完成得还是比较顺利的,虽然BUG管理系统的开发对我们来说是比较陌生的,但是由于一学期的分析设计,我们掌握了业务流程,数据流程,以及模块划分的思路,所以大家在开发过程中整体流程和目的都比较明确。

不过有一点,由于在专周之前是考试周,所以大家都没有对专周进行提前研究,项目计划没有很详细的安排出来。

在第一天专周的时候还是比较乱的,后面及时的设计了项目计划,表结构,分配了各个成员的任务。

后期因为命名的规范不是很严格,导致后来代码拼接以及结尾工作时遇到了一些问题,消耗了部分时间。

不过大家一起交流讨论,问题也很顺利的得到了解决。

以后在进行系统开发的时候会更加的注意前期项目开发计划的制定,以及制定并严格的执行代码规范。

这是第一次以小组的形式进行的专周,在开发过程中不仅加深了我们对上学期管理信息系统这门课所学知识的理解和认识,同时也加强了我们的团队协同合作能力,通过大家的一起交流也开拓了思路。

希望以后可以有更多这种小组合作的机会,

 

欢迎您的下载,

资料仅供参考!

 

致力为企业和个人提供合同协议,策划案计划书,学习资料等等

打造全网一站式需求

 

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2