I am not going to elaborate further on how to select and define the business objectives. I also will not spend much time on the “How,” assuming that as experts in our field we know how to create a to-do list for achieving our objectives. I do want to acknowledge that there are also “First Times,” such as, a new application, a new graphical library, or a new programming environment. In these cases, the to-do list may not be right at our fingertips. In these situations, answering the following questions will help us to produce the desired list.
  • Which work products do you share with the rest of the team?
  • What are the steps for finding answers to what is unknown?
  • Which deliverables give you feedback on your progress?
  • What is the level of detail that helps you to provide better estimates?
I do want to cover the “What” in more detail. The “What” defines the strategy for building the software system. The strategy is the bridge between the “Why” and the “How.” Moreover, this “bridge” has a name. We refer to it as the software development process or software development lifecycle. A software development process defines What to do When and for How Long.
Applying the first tip, “Isolate Issues” gives structure to the work that needs to be accomplished. The Rational Unified Process shows the issues we need to isolate when building software systems. It depicts the areas of activities we spend our efforts on, and it helps us divide our concerns as they evolve over time. 

Figure 2: Overview of the Rational Unified Process (RUP)
The point of this diagram is not to advocate the incremental and iterative development process versus the spiral or waterfall model. 
These are archetypal models that do not exist in their pure form?they are thinking models. Questions (e.g. How well do we understand the problem?), and project characteristics (e.g. project size and complexity) determine whether your product development strategy follows the waterfall, spiral or iterative/incremental process. 
The first proposed software development process was the waterfall model. Its major contribution was to call out the different engineering activities, such as requirements, analysis, design, implementation and test, and the sequence in which they occur. The spiral model identifies risk and its reduction as a major driver of the software development process. It also acknowledges the shortcomings of the waterfall model by proposing that the sequence of engineering activities will be executed repeatedly. 		 The iterative life cycle groups deliverables into iterations for early and continuous feedback on the product as it evolves and the process.
Following are short descriptions of the type of work that needs to be accomplished in each of the four phases of the RUP: 
  • The focus of the inception phase is to prepare the business case. This includes the product requirements, an estimate for the budget and schedule and projected costs and revenues. 
  • During the elaboration phase, software requirements are written, and a detailed project plan is prepared. The component architecture of the software system and interfaces are defined. Investigative prototyping may occur. Hardware and software are acquired, installed and configured. 
  • The construction phase is devoted to producing the software system. Module design, source code implementation and testing are implemented. 
  • During the transition phase, the emphasis is on crossing the T’s and dotting the I’s. Beta test feedback from customers is incorporated into the product, and system tests are conducted. Product stability is the target. Release management moves into the center.
The titles for the four phases serve as the first decomposition for the WBS. The process components are placeholders or checklist items for the next level of the WBS. The target is a detailed WBS similar to the one in Figure 3. 

Figure 3: WBS for the Implementation Component
  • To get from the phase-based skeleton to a detailed WBS, we need to apply the second tip, which is “divide and conquer.” Specifically, we need to divide and conquer the technical content of the product we are building. There are two ways we can divide the technical content:
  • Based on the functional requirements
  • Based on the software components of the product

Copyright © 1999  P2E. All rights reserved.