In summary, the conventional software process was characterized by the following:
• Sequentially transitioning from requirements to design to code to test
• Achieving 100% completeness of each artifact at each life-cycle stage
• Treating all requirements, artifacts, components, and so forth, as equals
• Achieving high-fidelity traceability among all artifacts at each stage in the life cycle
A modern iterative development process framework is characterized by the following:
• Continuous round-trip engineering from requirements to test at evolving levels of abstraction
• Achieving high-fidelity understanding of the drivers (the 20%) as early as practical
• Evolving the artifacts in breadth and depth based on risk management priorities
• Postponing completeness and consistency analyses until later in the life cycle
A modern process framework attacks the primary sources of the diseconomy of scale inherent in the conventional software process. Figure 17-1 illustrates the next generation of software project performance by depicting the development progress versus time, where progress is defined as percent coded (demonstrable in its target form). (The figure follows the same presentation format as Figures 1-2 and 15-1.)
My goal in this book has been to explain how to move onto the upper, shaded region, with a modern process supported by an advanced, fully integrated environment and a component-based architecture. Organizations that succeed should be capable of deploying software products that are constructed largely from existing components in 50% less time, with 50% fewer development resources, and maintained by teams 50% the size of those required by today's systems.
As an organization transitions to new techniques and technologies, there is always apprehension and concern about failing. Maintaining the status quo and relying on existing methods is usually considered the safest path. In the software industry, where most organizations succeed on only a small percentage of their projects, maintaining the status quo is not always safe. When an organization decides to make a transition, these two pieces of conventional wisdom are usually offered by internal champions as well as external change agents: (1) Pioneer any new techniques on a small pilot program. (2) Be prepared to spend more resources—money and time—on your first project that makes the transition. I see both recommendations as counterproductive.
Small pilot programs outside the mainstream have their place, but they rarely achieve any paradigm shift of consequence. Trying a new little technique, tool, or method on a very rapid, small-scale effort—less than 3 months, say, and only a few people—can frequently show good results, initial momentum, or proof of concept. The problem with pilot programs is that they are almost never on the critical path of the organization. Consequently, they do not merit "A" players, adequate resources, or management attention.
The most successful organizational paradigm shifts I have seen resulted from sets of circumstances similar to these: The organizations took their most critical project and highest caliber personnel, gave them adequate resources, and demanded better results. If, on the. other hand, an organization expects a new method, tool, or technology to have an adverse impact on the results of the trailblazing project, that expectation is almost certain to come true. Why? Because no organization manager would knowingly cause an adverse impact on the most important projects in the organization, and that is where the organization's best people will be assigned. Therefore, the trailblazing project will be a noncritical project staffed with noncritical personnel of whom less is expected. This low expectation is often a self-fulfilling prophecy.
A better way to transition to a more mature iterative development process that supports automation technologies and modern architectures is to take the following shot:
• Ready. Do your homework. Analyze modern approaches and technologies. Define (or improve, or optimize) your process. Support it with mature environments, tools, and components. Plan thoroughly.
• Aim. Select a critical project. Staff it with the right team of complementary resources and demand improved results.
• Fire. Execute the organizational and project-level plans with vigor and follow-through.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.