"当Bug跟踪系统上所有的bug都被打上Closed后，你是否感到如释重负。当项目成功交付后你是否感到大脑进入了“冬眠”期，上网，聊天，写自己感兴趣的小程序，但是对于上个项目你已不愿去想它。既然项目间隙还有点时间，就干点轻松的活吧，免的老板给你找些更受罪的事来作。
“温故而知新”，这句古训可以帮你给老板交差，对项目的进行过程作个分析，总结，最好再交个分析数据，老板绝对不会觉得你拿了钱不干活，而且自己也能有些收获。
开发阶段最好找的就是Bug记录，Bug管理系统已经记录下了所有的Bug的现象，分类，所处模块，发生原因。虽然几乎所有的Bug管理系统都提供报表，分类汇总功能。但是真正对这些信息作认真分析的项目恐怕不很多"
一个哥们的blog上写的.正是感同身受.于是也回顾一下这个项目的一些东西,看看我们系统的bug分析.
需要考虑的因素太多,麻烦
姑且
将###线定义为会议和日报上面提出的bug.
将###线定义为用户需求调整.
将###线定义为流程.
将###线定义为预算编制.
将###线定义为标杆.
将###线定义为项目化和一些系统功能.
发现人.gif
期中###的739 主要是一些会议和日报上面提出的bug.
###和###348+147=495 主要是客户或者根据客户的需求提出的.
###,### 74+14=88 比较麻烦的bug.
bug一共1670左右,有三分之一强是我们的需求和客户的需求的差别.
麻烦的bug 5% 左右.
发现人时间线.GIF
可以看出###线基本是一个放缓趋势.自身发现的bug在不断减少.
可以看出###线有明显的梯度.而且梯度均匀.说明客户的需求一直是存在的,
而且没有尽头,没次都有差不多数量的需求.
指定对象.gif
###预算,bug 507 ###332除去一些系统需求,剩下
300左右项目化 流程 311 标准化 272
其他模块的bug差不多,预算这块变动多,bug多了80%.
指定对象和测试版本.GIF
比较显著的是 060109上线前版本
bug基本集中在预算编制一块.
指定对象和发现人.GIF
###块,预算,标准化,项目化,bug差不多.用户对流程的需求相对较多.
实际测试中预算编制的bug较多.
状态时间线2.gif
1月突击了一把.
4月继续,5月更甚,6月刚过一半,估计比四月多,比5月少.
状态时间线
一月和四月,五月坡度相近(5月那节水平线是劳动节),6月时间才过一半,估计坡度差不多.
说明开发速率一直保持在同一个状态.
指定对象时间线.GIF
几条主要的线的曲折时间折线基本同起同落.