Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Public Council Teleconference: Application Rationalization — Hidden Costs and Smart Decisions
November 17 at 11:00 am US/Eastern (GMT-5)
Join Honorio Padrón, of The Hackett Group, who will share the drivers for companies to tackle application rationalization and the results of research that define the hidden cost of complexity. Additionally, we will discuss key decision milestones—to start or not, holding the course steady and fulfilling expectations.
Virtual Desktop Cost-Benefit Analysis — Michael Jacobs, Catlin Group
The analysis contained in this presentation measures the cost of everything from the machines and licenses to the infrastructure for virtual vs. traditional desktop environments.
Honor your best senior team members - Apply for the CIO Ones to Watch Award
Get well-earned public recognition for your top up-and-coming team members, your IT organization and your enterprise. Award winners will be announced, publicized and feted in May 2010, great timing to help attract new IT recruits to your company.
Learn more about the CIO Executive Council »June 24, 2008 — CIO —
"The process of scientific discovery is, in effect, a continual flight from wonder." —Albert Einstein
Chapter Contents
The previous chapter discussed the methods and techniques that form the foundations of Brownfield. We investigated each of these and compared the differences and similarities. Brownfield was shown to have evolved from these methods.
This chapter shows how the Brownfield method is used within the project lifecycle. As in the previous chapter, the lifecycle approach has again evolved as a composite of a number of existing lifecycle approaches.
Large-scale development has traditionally been based around well-organized phases. Each phase is completed before moving on to the next phase and is defined through work breakdown structures, work product definitions, and quality criteria. When viewed on a plan, these phases form steps down the page; this picture has led to the term "waterfall development." The water moves in only one direction, filling each phase before moving on to the next phase.
The more complex projects get, the more rigorous the methods become—up to and including extensive use of static testing and formal systems engineering techniques. These techniques are used to form quality assurance checkpoints at key points along the waterfall.
Static testing consists of techniques such as inspections and design walkthroughs to test the system's requirements, design, and implementation before the system can be executed.
The checkpoints check progress and create rigorous, strong baselines. The baselines are made up of a single set of unambiguous, formally signed-off documents. Figure 8.1 shows these project phases together with the quality assurance checkpoints used to enforce the rigor. The example shown uses the baselines defined in Carnegie Mellon's Software Engineering Institute's Capability Maturity Model Integration (CMMI).
On very large projects, many people have tried to shortcut this process (deliberately or through ineptitude, or both), and many have come unstuck.
As Barry Boehm and Richard Turner point out in their book, Balancing Agility and Discipline: A Guide for the Perplexed, five factors determine whether waterfall or agile methods will prevail on any particular project. For the purposes of this book, we have rephrased them, but we have stayed true to the spirit of their findings (see Table 8.1).
Table 8.1 Comparison of Agile and Waterfall Methods
|
Factor |
Agile Characteristics |
Waterfall Characteristics |
|
Size |
Optimal for small projects and teams; reliance on tacit knowledge |
Tailored for large projects and teams |
|
Mission-critical projects |
Untested; general lack of documentation |
Long history of use in such implementations |
|
Stability and complexity of existing |
Continuous refactoring used; suitable for dynamic and simple environments (typically Greenfield) |
Structured baselines used; suitable for more static and complex environments environment (typically Brownfield) |
|
Skills |
Continuous involvement of highly skilled individuals; difficult to cope with many lower skilled resources |
Highly skilled individuals needed in early phases; designed to cope with many lower-skilled resources in later phases |
|
Suitable organization culture |
Chaotic; dynamic; empowered |
Roles well defined; procedures in place |
As you can see, agile and waterfall development each have their strengths and drawbacks. To recast the comparison, it is both possible and safe to build a paper airplane without a detailed plan. It would be foolish to spend 20 minutes writing the instructions and then spend 20 seconds building the plane. However, building a passenger airliner without detailed, upfront design would be a long and expensive process involving a lot of rework that you would otherwise have avoided. (You'd also probably face a shortage of test pilots to take the airliner on its maiden flight.) Figure 8.2 summarizes the different development techniques used in building a paper airplane and building an airliner.
In formal waterfall methods, defects are detected as early as possible through static and then executable testing. If defects are found, changes are made to the requirements, specifications, or solution design documents. Changes can ripple forward from the first work product affected to the last. This approach reduces the overall number of defects and is far more cost-effective than not following these best practices because it reduces the number of surprises and the amount of rework.