软件规划项目开发情况总结报告Word文档格式.docx
《软件规划项目开发情况总结报告Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件规划项目开发情况总结报告Word文档格式.docx（15页珍藏版）》请在冰点文库上搜索。
在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
否
项目组组长
项目表（project）：
pro_num
项目编号
pro_name
char（30）
项目名称
3
description
4
5
remarks
char（50）,
备注
权限表（authority）：
authority_num
int
权限编号
authority_name
char（20）
权限名
角色表（roles）：
role_num
角色编号
role_name
char（10）
角色名
authority
角色所拥有的权限,如00011110
测试环境表（environment）：
en_num
system
equip
char（50）
设备配置信息
严重级别表（severity_level）：
severity_num
严重级别编号
severity_name
char（15）
严重级别名称
优先级别表（priority_level）：
priority_num
优先级别编号
priority_name
优先级别名称
分配表（share）：
bug_num
缺陷编号
unum
人员编号
share_time
datetime
分配时间（默认当前时间）
modify
修改时间
缺陷信息表（bugs）：
缺陷序号，唯一标识
缺陷环境编号
status
缺陷状态
varchar（100）
所属项目编号
6
char（4）,
严重级别
7
up_time
上传时间（默认当前时间）
8
close_time
关闭时间
9
优先级别
10
version
版本所属的版本信息
11
modular
模块所属的模块
12
solution
char（200）
解决方案
13
remark1
用户表（users）：
用户编号
uname
用户名
所属项目组编号
tel
char（11）
电话号码
address
nvarchar（50）
地址
char（20）,
password
char（6）
密码
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管理系统的开发对我们来说是比较陌生的，但是由于一学期的分析设计，我们掌握了业务流程，数据流程，以及模块划分的思路，所以大家在开发过程中整体流程和目的都比较明确。
不过有一点，由于在专周之前是考试周，所以大家都没有对专周进行提前研究，项目计划没有很详细的安排出来。
在第一天专周的时候还是比较乱的，后面及时的设计了项目计划，表结构，分配了各个成员的任务。
后期因为命名的规范不是很严格，导致后来代码拼接以及结尾工作时遇到了一些问题，消耗了部分时间。
不过大家一起交流讨论，问题也很顺利的得到了解决。
以后在进行系统开发的时候会更加的注意前期项目开发计划的制定，以及制定并严格的执行代码规范。
这是第一次以小组的形式进行的专周，在开发过程中不仅加深了我们对上学期管理信息系统这门课所学知识的理解和认识，同时也加强了我们的团队协同合作能力，通过大家的一起交流也开拓了思路。
希望以后可以有更多这种小组合作的机会，
升级会员 