Television has done a fine job of glamorizing the job of an investigator. Whether you fancy the classic Sherlock Holmes, the affable Colombo, or even perhaps enjoy the suspense associated with cracking the case on television shows like “The First 48,” Hollywood has tried to make us believe the search for clues is always exciting. However, those who have searched thousand row spreadsheets for software data collection efforts, may beg to differ with that sentiment. The needle in a haystack analogy may seem more fitting, if only the haystack was bigger!
Although most folks will never get the chance to track down a villain like Sherlock’s nemesis, Professor Moriarty, there still is a need in many professions to find “clues.” In software estimation, those clues can be thought of as software project data. What information do I need to solve this software project estimation case and how do I obtain it? In that search for information, perhaps we can utilize some basic investigation steps to find the software data needed to produce good software project estimates. Honestly, why would one embark on the often daunting quest of collecting project data for future estimation without at least a basic approach? Well, there are many reasons. However, let’s focus on a way to proactively look at an approach using the analogy of an investigation.
For this example, let us consider the first step (Collect) in a very simple investigative process of Collect-Examine-Analyze-Report. Although the step may seem too simple at first, there undoubtedly exist several activities that an investigator has to undertake in order to successfully collect data.
So let’s expand the step in the chart below. The chart depicts basic investigation activities in the “Collect” step, with crime investigation and software data collection as loosely compared categories:
|Collect Activity||Crime Investigation||Software Data Collection|
|1. Identify Possible Data Sources||Crime scenes, suspects, experts||Metrics spreadsheets, reports, databases, experts|
|2. Collect Data||Obtain the information needed to solve the case||Obtain the information needed for software project estimation|
|a. Develop a storage plan (where, who)||Evidence lockup, chain of custody (access) process||Measurement database, identify user access protocols|
|b. Actual Collection||Search crime scene||Search databases, spreadsheets, interviews|
|c. Validate Data||Crime labs, experts, witnesses||Independent review, experts and data entry personnel, developers|
Considering the chart takes some liberties as a truly appropriate comparison, it can at least be argued the process steps are relevant for each activity. Thus, if you are indeed faced with the daunting task of data collection for software estimation, remember the basics of using simple investigative process to organize your work.
You can gain insight into the additional investigative steps of Examine-Analyze-Report, and how they can be applied to your software estimation needs by learning about QSM's Software Lifecycle Management (SLIM) tools and consulting services.
In future posts, I will continue to examine the relationships between processes related to software project success and security.
For this blog series, Victor tapped into his security experience as a former Criminal Investigator and Antiterrorism Specialist to draw some interesting analogies for approaching software estimation. He also considered products he previously authored concerning critical security focus areas for organizations such as the Missile Defense Agency (MDA), United States Marine Corps (USMC) and Target Corp.