Managing iteration in OO projects

  • Published on

  • View

  • Download


  • John D. Williams Knowledge Systems Corporation

    = Object technology

    challenges project managers

    as well as developers.

    The author supplies guidelines

    and tools to help

    new managers accurately

    track project progress.

    0018-9162/96/$5 00 D 1996 IEEE

    Iteration in 00 Projects

    hy do some companies succeed in managing object-oriented projects and others fail? I have reviewed numerous failed object technology projects, and it is clear to me that the sin-

    gle largest failure is technology management, not the technology itself. When they move to object technology, most companies prepare their technical staffs by sending them to language and object-oriented analy- sis and design classes. Unfortunately, these same companies often ignore the training needs of the managers wholl be directing those technical staffs. Managers are left to fend for themselves, armed with yesterdays tools and with little insight into the potential of todays technology.

    Moving to object technology does not mean project managers must dis- card everything they know. Managers still need to know if their projects are meeting goals, on schedule, or suffering from feature creep. They must still understand overall project goals and keep the project team focused on meeting them. They still must manage customer expectations when it comes to features and delivery schedules. Switching technologies does not make these problems disappear. If you have problems with these issues now, youll still have problems when you switch to object technology.

    The difference in managing object technology is knowing what ques- tions to ask and understanding the answers. You still need to know the status of your project, but if you cling to a waterfall view of the world while your technical staff adopts an iterative, incremental method, you wont understand the status of a project or be able to predict where its going.

    Also, 00 development affords managers new opportunities and choices that are not available in traditional approaches. These opportunities pro- vide managers with newfound flexibility and capability. Consequently, new insights and techniques are necessary to let managers capitalize on these new capabilities and integrate them with ongoing project manage- ment requirements.

    In this article, 1 describe several project management issues facing com- panies switching to object technology and offer ways for managers to cope. I write from first-hand experience as the lead software systems engineer and team manager for StarView (the user interface to the Hubble Telescopes data archive) at the Space Telescope Science Institute and as a long-time consultant.

    UNDERSTANDING AND MANAGING ITERATION The problems with the waterfall approach are well known (see the 00

    life cycle sidebar), yet an iterative approach can be problematic as well for new managers. In an iterative process, how do you know where you are in the development cycle? How do you know if youre making progress? This question reveals why many managers feel uncomfortable with the iterative process: They see no way to answer these questions.

    Other managers take a dim view of the iterative process. Instead of whirlpool, they might use black hole to describe a process that they

    September 1996

  • I----

    --- - 1 '* '* ' '

    Figure 1.3db diagram, which charts the shifting focus of where a software development project is over time. The 3db point indicates the project's tran- sition from mostly analysis to mostly design. When design is mostly complete, the curve levels off, which indicates the focus is on implementation.

    think will suck up resources at a prodigious rate. They see no clear way to end iteration and achieve a finished product.

    Managers are justified in feeling such disquiet, yet most

    00 methodologists assume that managers automatically understand the implications of the whirlpool approach and understand how to make it work, which generally is not true.

    While I was tracking the StarView project's progress, I developed a technique I call 3db software engineering. Figure 1 diagrams it. I developed this technique to answer my project manager when he asked how I knew where I was in the project. (The project manager, an electrical engineer, decided the curve I'd drawn resembled a 3 deci- bel point, and the name stuck.)

    The diagram in Figure 1 linearly charts the results of the iterative analysis and design process, thereby showing how, over time, you can tell how close the project's design is to completion, at which time implementation can begin.

    The straight line in Figure 1 represents development in the traditional waterfall process. The actual shape should be a stair step, but the line is a reasonable approximation. Essentially, as you move from one step to the next, you move in a straight line from beginning to end.

    In the waterfall, steps are recognized as complete when specific deliverables for each step are complete. These may be a requirements document or analysis and design dia- grams. Integrated code is the final deliverable. The problem is knowing if you have all the requirements so that you can complete the analysis, design, and coding. Missing pieces up front lead to problems further down the waterfall. With

    of code to measure progress, since little else is known. It also requires usually unfounded assumptions about what is known, such as requirements, and when things are com- pletely known. Typically, the waterfall approach assumes that everything is known up front so that well-defined tasks

    rstanding and addressing the issues of rnanqing object technology pro- jects. Traditional development still uses the classic waterfall method, shown in Figure A. Although people try to mod-


  • the whirlpool, however, you see a shift of emphasis. Percent complete is a guesstimate based on how things are shift- ing and what percent of time is being spent where.

    The curved line in Figure 1 represents the progress of iterative development. Note that the line is almost flat in the beginning, reflecting how things truly are at the start of a project when things change as days drag on and little appears to be accomplished. For example, at project start, developers try to come up with an initial list of classes and define some of their relationships. That list of classes changes everyday and so, of course, do the interrelation- ships, but the value in this approach is that the best design often emerges from the consideration of many possibili- ties.

    As the process continues, the design will start to solid- ify. The list of classes changes less frequently, which means that the class relationships do likewise. The system archi- tecture begins to take on a stable shape and form. Before long, youll notice that your team is spending more time on the details of how a class works and the exact nature of relationships between classes than on discovering classes or relationships themselves.

    The knee in the graph, the 3db point, shows where pro- ject emphasis shifts from a focus on analysis to one on design. The key for managers is to be attuned to how much of the teams time is occupied with analysis issues versus design or coding issues. Milestones, such as less frequently

    changing classes, are guidelines in determining where the team is in the development process.

    The 3db point is an excellent time for an informal design review, which serves as a sanity check to ensure that the architecture is sound. Now progress toward design com- pletion accelerates rapidly, and the curve in the graph heads almost straight up. The 3db curve shows how your project teams focus shifts from analysis to design. But how do you know when design is complete enough? By testing your design against the scenarios or use cases that your devel- opers or analysts have constructed for the application. This implies that the use cases are fairly comprehensive and cover all appropriate requirements. When the design sup- ports all scenarios, the design is complete enough.

    Design implementation, indicated on the graph by the curved line leveling off toward the right, will inevitably bring additional changes, which may mean revisiting some design or analysis steps. Youll find, however, that itera- tion at this stage is more a matter of refinement than of major redesign.

    PROJECe MANAGEMENT TOOLS Managers can determine how far projects have pro-

    gressed through the use of milestones, a class-and-method count, an earned-value count, and defect categorization. (For information on a less tangible but equally valuable tool for managers, see the Mentoring sidebar.)

    ment is particularly suited to the whirlpool approach. Some methodologists have different vari- ations with different names, such as Brian Henderson-Sellers fountain model or Peter Coads baseball model, but they, too, reflect the underlying whirlpool approach. Most methodologists would agree that 00 development is best suited to an iter- ative whirlpool approach, in which the basic goal is delivering useful systems in shorter cycles, even with fewer clearly defined requirements.

    Figure B shows one variation on the iterative, incremental whirlpool model. The same basic steps shown in the waterfall model appear here as tasks to be accomplished. Whats different is how the steps interrelate and how each is accomplished. The basic process lets you run through a projects entire life cycle in small increments.

    September 1996

  • ~ I

    Figure 2. Tracking software functionality through classes and methods.

    Figure 3. Tracking software functionality through earned value.

    Milestones Preferably, milestones are based on a few formal and infor-

    mal design reviews during analysis and design, then on prototypes that progressively demonstrate increasing func- tionality as the software evolves. The milestones demon- strate the actual state of the software at any given point.

    One key milestone is when the project moves from analy- sis to design (at what we earlier called the 3db point). Another milestone is when you can trace your requirements to classes. Yet a third milestone is when you can validate

    your design with use cases, with Booch object and interaction diagrams1 This key milestone shows how the design meets its goals and also, at its completion, shows that you are ready for a formal design review. Once youve reached this point, youre also ready to create a more detailed implemen- tation schedule that will contain additional milestones.

    One important goal of the implementa- tion milestones is to demonstrate the soft- wares increasing functionality through incremental integration and a steady stream of prototypes. Even though the soft- ware is incomplete, others evaluating your project have a high level of confidence that progress is occurring because they can see the software grow and evolve. This is far preferable to counting lines of code and waiting for the big bang of integration at the end of implementation.

    To create these milestones, you do need to understand class interrelationships. Let the integration milestones help determine the order of development. Start with the core classes, your key abstractions, and move on to those classes that use them. You can also create milestones for subsys- tems and incremental milestones that reflect the completion of key aspects of the software such as the ability to generate a query against a database. With these mile-

    stones, you can show a more linear view of progress toward your goals, which will be meaningful to managers who are interested only in results.

    Along with milestones, you need information to track development so you can identify existing or potential prob- lems. For example, was a milestone missed because the software was growing out of its original boundaries? Was new functionality added thatwasnt in the initial schedule or requirements? This happens when requirements change in the middle of development. The flip side of this is to find

    functionality that may have been lost, which means someone forgot to do part of the work. The conventional approach to finding these problems is to count lines of code, but there are better ways to track development.

    Counting classes and methods The key component in 00 development

    is the class, not the line of code. By tracking the number of classes and methods devel- oped, you can better understand the state of development. An increase in classes and methods, for example, can show that soft- ware is growing out of bounds. Areduction in expected number may show missing func- tionality. An increase in classes, but a reduc- tion in methods, may indicate that developers are taking more advantage of code reuse. If you count fewer classes, but


  • more methods, this may indicate that a consolidation of classes is occurring.

    You can make analysis easier by grouping classes and counts by subsystem. For example, on the StarView project at the Space Telescope Science Institute, the actual counts were 1 for each method and 1 for the class itself. To mon- itor progress, we tracked the growth of classes by com- paring them to estimates made at the beginning of implementation.

    Figure 2 shows a sample of this metric. Planned classes are those originally projected; forecasted classes are those caused by new functionality. Added to the planned line, they indicate what count should be seen each month. Actual classes are those that are actually done for the month. This diagram reflects the fact that, as a result of iteration, new functionality was accepted into the soft- ware later in the life cycle.

    Earned value Another way to track software functionality is the

    earned-value approach, in which you assign value to each functionality increment and track the value growth. Functionality is not equivalent to a low-level function; instead, its a higher level of functionality such as display- ing the results of a query.

    The totalvalue for incremental functionality is counted when all work for that increment is complete. As this hap- pens, the software grows in value. Counting earned value is not synonymous with counting classes, because a func- tionality increment may require several classes to be com- plete.

    In Starview, we assigned a value of 10 to each func- tionality increment. Figure 3 illustrates this data in graph form and, like Figure 2, shows that new functionalitywas accepted during implementation.

    Defect categorization Defect categorization is useful for managing bugs and

    improving software quality. While not strictly an object technology management tool, this technique, when com- bined with others, such as Pareto charts for statistical process control, give managers considerable insight into the quality of their particular development process.

    The StarView project applied a set of categories,2 includ- ing enhancement, specification defect, design defect, code defect, documentation defect, environment support defect, and others. These categories, when supplemented with SPC tools, can be part of an overall iterative quality improvement process.

    SOFTWARE PROJECT MANAGEMENT IS FRAUGHT with difficul- ties and problems. An iterative, incremental approach to software development like the whirlpool method can over- come some of the difficulties managers face. The iterative approach lets you understand how a software system is evolving while development is ongoing so you can handle changing requirements yet still deliver usable software. Techniques to help manage iterative and incremental development include a combination of milestones, the 3db curve, counting classes and methods, and counting earned value.

    With new techniques and the courage to use them, man- agers are much more likely to lead successful object-ori- ented projects. I

    References 1. G. Booch, Object-Oriented AnaZysysis and Design with Applica-

    tions, second edition, Addison-Wesley, Reading, Mass., 1994. 2. R.B. Grady, Practical Software Metria Forproject Management

    and Process Improvement, Prentice-Hall, Englewood Cliffs, N.J., 1992.

    John D. Williams is the director ofITarchitecture at Car- olina Power and Light. Previously he directed development services for Knowledge Systems Corporation. Williams has more than 17yearscomputer and management experience and has held senior management and technical positions with Space Telescope Science Institute, Imperial Chemical Industries, and Diversified Systems.

    Williams received a BAfrom Milligan College in Tennessee and has done graduate work in computer science and busi- ness administration. He hasfrequently taught, lectured, and published on 00 software development. He holds apatent for electrical circuit design.

    Readers can contact Williams at Carolina Power and Light, CPB 17A5,410 S. Wilmington St., Raleigh, NC27601; johnd.


    The IEEE Computer Societys newest magazine seeks volunteers with expertise in Internet applications and systems to review manuscript submissions. For more information on reviewing, send your curriculum vitae and e-mail address to Linda World at For more information on IEEE Internet Computing, visit the magazine home page: .org/pubs/internet

    C ~ ~ ~ P U T E R SOCIETY 5 0 Y E A R S OF SERVICE * 1946-1 9 9 6