Have you ever been excited to discover a new use for something familiar, like learning that lighter fluid can be used to remove ink stains from your clothes? I recently discovered a way to leverage the tie between SLIM-Estimate and SLIM-DataManager that I was previously unaware of.
My limited view of SLIM-DataManager as a tool for historical data and SLIM-Estimate as a tool for software project estimation limited my creativity in applying the rich set of capabilities in the entire SLIM tools suite. I recently observed a more experienced SLIM user use both tools to model a history project where very little data was available, using both applications. Here is a description of the situation.
Scenario:
You have gathered metrics from a completed project to serve as the basis of estimation for your next project. Software size, lifecycle effort, lifecycle duration (phases 1-3), and defects are known, but you do not have a break out of individual phase data. How can you best model this project and capture the results in SLIM-DataManager?
Solution A:
My first approach to modeling the completed project would be to enter the data into SLIM-DataManager to calculate PI. That would at least provide a PI value from my own history. The challenge is that although only four data elements are required to determine PI, these numbers have to come from Phase 3. In this case, I only have lifecycle totals. If I had a rough idea of the percent of the total duration or effort spent in Phase 3, I could use SLIM-DataManager to calculate a PI. After meeting with the project manager, I am comfortable with her estimate that Phase 3 equates to two-thirds of the project. I enter that data as shown in the figure below. The resulting PI value is 15.4, and MBI is 2.9.
Solution B:
The more experienced SLIM user took advantage of SLIM-Estimate's solution wizards and the ability to import workbook components from one tool to the other. He created a new SLIM-Estimate workbook using the total project metrics and the Solve for PI Wizard. The QSM default lifecycle was used, selecting phases 1-3 only. The resulting PI is 16, and MBI is 3.4.
Since he wants all of the historical project data in SLIM-DataManager, he imports the SLIM-Estimate project, and sets the Status field to ‘Completed.’ The Review tab provides a place to note the source of this project data, and how it was derived. Now, he has a complete project lifecycle model that can leverage all of the power of SLIM's history tuning and comparative analysis features.
The PI values from both solutions are relatively close. The added advantage of Solution B is the ability to model the individual lifecycle phases. Approaching a problem from multiple angles is a good idea, because it provides a way to sanity-check your estimate.
Take some time every now and then to review SLIM tool features, especially how they are designed to work together and share data. Find out how others are using SLIM Suite Tools. You may notice something that escaped you before that will help you find creative solutions to your software lifecycle management challenges!