ProjectCodeMeter
Monitoring an Ongoing project development team productivity
This
process enables actively monitoring the progress of software
development, by adding up multiple analysis measurement results (called
milestones). It is done by comparing the previous version of the
project to the current
one, accumulating the time and cost delta (difference)
between the two versions.
Only when the software is in this mode, each analysis will be added to the History Report, and an auto-backup of the source files will be saved into the ".Previous" sub-folder of your project folder.
The process is a variant of Cumulative Differential Analysis which allows to more accurately measure software projects, including those developed using Agile lifecycle methodologies.
It is suitable for measuring productivity of both single programmers and development teams.
Step by step instructions:
1. Make
sure you don't have any open ProjectCodeMeter report files in your
spreadsheet or browser, as these files will be updated. If you
want to start a new history tracking, simply rename or delete the old History Report file.
2. Put on your local disk a folder with the most current project source version (excluding any auto generated files, files created by 3rd party, files
taken from previous projects) if you already have such folder from
former analysis milestone, then use it instead and copy the latest
version of the source files over it.
3. Select this folder into the Project Folder textbox
4. Click the Differential Comparison checkbox to enable checking only revision differences
5. Clear the Old Version Folder
textbox, so that the analysis will be made against the auto-backup
version, and an auto-backup will be created after the first milestone
(ProjectCodeMeter will automatically fill in this textbox later with
the auto-backup folder)
6. Optionally, set the "When analysis ends:" option to "Open Differential History Report" as the History Report is the most relevant in this process
7. Select the Settings describing the current version of the project (you should usually ask your developer for the Quality Guarantee setting, and).
8. Click "Analyze", when the analysis process finishes the results for this milestone will be shown at the bottom right summary screen, While results for the overall project history will be written to the History Report file, which should now open automatically.
9.
On the first analysis, Change the date of the first milestone in the
table (the one with all 0 values) to the date the development started,
so that Project Span will be correctly measured (in
the History Report file).
10. If the source code analyzed is a skeleton taken from previous projects
or a third party, and should not be included in the effort history, simply
delete the current milestone row (last row on the table).
11.
Fill in the number of developers who worked simultaneously on this milestone. For example, if the previous milestone was checked last
week and was made by 1 developer, and at the beginning of this week you
hired another developer, and both of them worked at developing the
source code for the this weeks milestone, then enter 2 in this milestones
"Developers" column (the previous milestone will still have 1 in its
"Developers" column)
12.
Optionally, if you know the actual time it took to develop this project
revision from the previous version milestone, you can input the number
(in hours) in the Actual Time column at the end of the milestone row, this will allow you to see the Average Actual Productivity of your development team (indicated in that report) which can give you a more accurate and customizable productivity rating than Average Span Productivity.
The best practice is to analyze the projects source code weekly.
Each milestone has its own Span Productivity (and if available, also Actual Productivity), these show how well your development team performs comparing to the APPW
statistical model of an average development team. As your team is
probably faster or slower than average, it is recommended you gather at
least 4 weekly milestones before deriving any conclusions. For
monitoring and detecting productivity drops (or increases), look at the
Span Prod. Delta (and if available, also Actual Prod. Delta) to see changes (delta) in productivity for this milestone. A
positive value means increase in productivity, while negative values
indicate a drop. It is recommended to look into the reasons behind
significant increases (above 5) or drops (below -5), which development productivity improvement steps to take.
Look at the Average Span Productivity (or if available the Average Actual Productivity) percentage of the History Report
to see how well your development team performs comparing to the APPW
statistical model of an average development team. A value of 100
indicated that the development team productivity is exactly as expected
(according to the source code produced during the project duration), As
higher values indicate higher productivity than average. In case the value drops significantly and steadily below 100, the development process is less efficient
than the average, so it is recommended to see Productivity improvement tips.