The Reverse Detective is an easy-to-read, breakthrough book that shows you how to prevent software failure by using the same disciplined, step-by-step process used by professional detectives to solve crimes.
There's just one difference: You put the traditional Sherlock Holmes approach in reverse.
The result? Instead of solving the crime of software failure, you prevent it by precisely determining and modeling the right requirements before you begin writing code.
Getting software development right from the start ... when you put the Reverse Detective process to work, you'll minimize the chance of blown budgets, missed timelines, endless revision rounds, and other career-busting problems.
Now you know why this practical, enjoyable guide is destined to become a must-read for everyone with a major stake in software development, including: executives, business managers and process owners, and hands-on software engineers.
Review By: Harry L. Kirkpatrick 02/25/2008The authors take an interesting approach in this book. They illustrate how the techniques of a criminal detective, in this case Monsieur C. Auguste Dupin, can help us with software engineering. Specifically the authors point out how the detective goes about solving a crime, and how these methods can be applied to gathering and modeling requirements for a software application.
The role of the detective and the role of the software engineer appear to have no relationship whatsoever. However, the authors suggest that the relationship between the detective and the software engineer is based not in what each does, but rather in their methodology: how they go about doing their work. A comparison of the two methodologies reveals significant overlap. To illustrate the behaviors of the software engineer, the authors introduce a fictional software engineer called Alex.
Alex’s role doubles as the "detective", particularly in the early stages of product development. The fundamental difference between the activities of M. Dupin and Alex is that Dupin is investigating a crime that has already been committed. The detective has the luxury of dealing with evidence, witnesses, and suspects after the commission of the crime. The software engineer, on the other hand, can be considered to be investigating the crime before its commission.
Stated simply, the software engineer gathers information as to what the "crime" should be, then creates the "crime" to fit the evidence and testimony.
The book is packed with figures, examples, and a case study. After introducing the detective and the software engineer, the remainder of the discussion follows two threads of interest. The first thread tracks the activities of M. Dupin investigating a case. The second thread examines the activities of Alex working within the context of a traditional software development methodology: the Rational Unified Process. To better illustrate Dupin's activities and place them into the appropriate context, a case study of a detective at work is presented. A later chapter details Alex's process and applies it to an example application whose purpose is to support the work of the detective as he investigates the crime.
Each chapter concludes with a synopsis of the chapter’s objective and the recipe for accomplishing the stated objective. The example application model and the entire case study are provided on the accompanying CD-ROM. Two appendices are provided with additional information. The second appendix introduces the Software Engineering Effectiveness Model (SEEM). SEEM provides the methodological underpinnings of the presented material. A complete overview of SEEM will help the reader understand how the presented material fits into the entire development process for a software application.
This book should be added to your library as soon as possible. The book is concise and well organized. It's a must read for everyone with a major stake in software development.