3 Background
3.8 Statistics
A product’s development cycle is measured in various ways, all of which determine how much progress has been made. Project Managers (PMs) use progress reports to view the progress made in a project, usually through visual displays, such as charts and graphs. PMs are able to share this
information with other PMs, employees on their teams, and upper management, to help convey the status of a project.
3.8.1 ChromeOS Statistics
The Project Managers (PMs) of the ChromeOS team use bug trends to track the progress of the team. The fewer open bugs the team has, the closer the product is to being ready. PMs compare the rate at which new bugs are found against the rate at which the bugs are fixed to determine the stability of the product.
Before our project, the PMs viewed bugs in the NVBugs database using the web server API. The PMs would manually look through the modules and projects to find information on relevant bugs, and would then translate the information into statistics that could be shared. The three most common charts the PMs used are:
Project Bug Velocity
Project Bug Trend by Modules
Project Bug Trend by Engineers
The charts can be observed in the figures on the following pages. Figure 2, Figure 3, and Figure 4 are charts that were used in a presentation by a PM of the ChromeOS project. Figure 2 and Figure 3 use the ChromeOS project ‘Acer Kitty’ as the target project, and Figure 4 uses the ChromeOS project ‘HP/Bailey’.
33 Figure 2 shows the Project Bug Velocity chart. The chart’s columns display the number of open bugs, the number of new bugs, and the number of fixed bugs for a single project over multiple weeks. The chart shows the open/new/fixed levels for up to fifteen weeks in the past. This chart is used to show the velocity of the bugs for a single project: how many bugs are being created against how many are being fixed. This information allows PMs to make a rough prediction about when the number of bugs in the project will approach zero.
Figure 2: Project Bug Velocity Chart
Figure 3 shows the Project Bug Trend by Modules chart. The chart displays the number of open bugs per module for a single project over time. The numbers of open bugs for each module are stacked on one another, summing to the total number of open bugs. Each different module relating to the project is assigned a color, which is used to show the different amounts of open bugs. The graph shows the stacked modules for up to fifteen weeks in the past, allowing the viewer to see the differing number of open bugs for each module. This chart is used to compare the number of open bugs per module against other modules. This allows PMs to gain insight into how the different modules are tracking against each other with respect to reaching a state where the code can be released.
34 Figure 3: Project Bug Trend by Modules
Figure 4 shows the Project Bug Trend by Engineers. The chart shows the number of open bugs per engineer for a single project. The columns represent the number of bugs that are currently open and assigned to a specific engineer. This chart allows the viewer to see which engineers have the most number of bugs to fix for a particular project. This allows the PMs to make decisions about reassigning bugs to different engineers to ensure that workloads per engineer are roughly balanced.
35 The PMs need to generate the above three charts for every project they are working with. Generating each chart takes a long time, as searching the bugs and recording the data is time intensive. A PM must search every module that they are interested in, and manually record each bug’s info, such as request date, fixed date, days open, etc. The PM then uses this manually recorded data and generates a chart with the data using Microsoft Excel. This approach takes an enormous amount of time.
The web client of NVBugs does have several embedded charts. The embedded charts are limited in what they can display. The web client can also only display a single chart at a time. An example can be found in Appendix B.
3.8.2 Generating Dynamic Charts with Microsoft Excel
The PMs currently generate the required charts by manually entering data into tables within Excel. This process is quite time-intensive and not the best use of managerial time.
Converting this process to be automatic would drastically reduce the time involved in generating the charts. This would have multiple benefits:
PMs could better allocate their time.
Charts could be generated at the click of a button, allowing PMs to access the latest statistics quickly and frequently.
Excel provides different methods of automating chart creation, one of which is Visual Basic for Applications.
3.8.2.1 Visual Basic for Applications
Microsoft Excel allows code to be run from a programming language called Visual Basic for Applications (VBA). VBA enables many Excel processes to be automated [50]. A user can use VBA to create a small series of instructions that Excel runs, called a macroinstruction (macro). These macros are able to be integrated into the Excel spreadsheets, and can be triggered through a user’s input. Macros are able to automate table generation, mathematical formulas, and even document saving.
3.8.2.2 Gremlins
The Gremlins database is a backup database for NVBugs. The name “Gremlins” comes from an NVIDIA joke: “It is not in the best interests of a company to hire developers to create bugs. Because everything we do at NVIDIA is for the best interests of the company, the only logical explanation for why there are bugs is gremlins.” [63].
36 Gremlins is a database that takes a snapshot of the NVBugs database every 15 minutes, and backs the data up. The difference between Gremlins and NVBugs is the API associated with these two services. NVBugs provides SOAP APIs that can modify bugs, as well as providing a web-client front end. Gremlins is used solely for information gathering, allowing SQL connections and queries. Gremlins allows users to programmatically pull specific information from NVBugs that the user would otherwise have to manually pull from the NVBugs web client.
37