Iterative Rework: the Good, the Bad, and the Ugly

COVER FEATURE Iterative Rework: The Good, the Bad, and the Ugly In software development, some rework is both inevitable and beneficial. But how much is too much and how little is too little? Understanding the nature of rework and why it occurs can help answer these questions. Richard E. ecause the creative processes in developing port the next version (bad that can turn ugly). Fairley and modifying software are subject to Understanding and correcting the root causes of Oregon Health and myriad external and changeable forces, it problems that result from too much or too little Science University is impossible to get all but the simplest rework can significantly increase productivity, B products right in one pass. Long experi- quality, developer morale, and customer satisfac- Mary Jane ence has shown the advantages of iterative devel- tion. Willshire opment, in which each iteration subsumes the pre- Colorado Technical vious iteration’s software and adds capabilities to ITERATIVE DEVELOPMENT MODELS University the evolving product to produce a next version. As All forms of iterative development provide a way developers build and validate the next version’s to capabilities, they rework the previous version to enhance its capabilities and fix defects discovered • continuously integrate and validate the evolving while integrating the new and old versions. product, Iterative development can take many forms, • frequently demonstrate progress, depending on the project’s goals: Iterative proto- • alert developers early on about problems, typing can help evolve a user interface. Agile devel- • deliver subset capabilities early on, and opment is a way to closely involve a prototypical • systematically incorporate the inevitable rework customer in a process that might repeat daily. that occurs in software development. Incremental build lets developers produce weekly builds of an evolving product. A spiral model can Agile and incremental-build are two commonly help the team confront and mitigate risk in an evolv- used iterative development models. In both mod- ing product. els, significant changes to requirements, design con- Each iteration involves a certain amount of straints, or environmental factors such as changes rework to enhance and fix existing capabilities (the to middleware application programming interfaces good). However, excessive rework could indicate (APIs) or hardware features can require significant problems in the requirements, the developers’ skills rework of the design and existing code. and motivation, the development processes or tech- nology used, or all of the above (the bad). Exorbitant Agile development levels of rework result in truly untenable situations Although the agile theme has several variations, (the ugly). most agile process models adhere to five principles On the other hand, too little rework could indi- (http://agilemanifesto.org/principles.html): cate insufficient review and testing or too little anticipation of the product features needed to sup- • Continuously involve a prototypical customer. 34 Computer P u b l i s h e d by th e IE E E Co m p u t e r So c i e t y 0018-9162/05/$20.00 © 2005 IEEE Hear Specify Start customer requirement(s) here story Deliver here • Develop test cases and test scenarios before Write test scenario(s) implementing the next version. Customer • Implement and test the next version. Demonstrate • Demonstrate each version to the customer and capabilities Add new features; elicit the next requirements. review, test, and • Periodically deliver evolving subsets of the rework product into the operational environment. The customer’s role is to review progress and pro- Figure 1. Steps in the agile development process. The process from customer vide the story line that determines the requirements story to demonstrated capabilities is iterative in nature, with Iterations typically for new capabilities and revisions to demonstrated occurring in cycles of one day or less. Developers may periodically deliver capabilities (www.martinfowler.com/articles/new versions to users. Methodology.html). Figure 1 depicts an iterative model for agile development. Some agile process models require developers to produce a next version of a running system within one workday. Some use pair programming, in which pairs of developers share a computer terminal to develop their software. Customer Experience with agile models indicates that the Requirements resulting products rate high in customer satisfac- specification tion and have low defect levels. Customer satisfac- tion, however, depends critically on involving a Architectural knowledgeable prototypical customer. Some crit- design Incremental ics maintain that products from an agile process validation may have functional structures, which are hard to Design and rework modify, and no design documentation. Others note partitioning the approach’s lack of scalability. Incremental Incremental Incremental build verification (a) and rework builds In contrast to agile models, in which requirements and architecture evolve, the incremental- build model is based on stable requirements and an architectural design. As Figure 2a shows, the model Incremental Design validation partitions requirements and architecture into a pri- partitioning Demonstrate oritized sequence of builds. Each build adds capa- feature set 1 Validate bilities to the incrementally growing product. Build feature set 1 feature set 1 Incremental Developers typically produce a next version of a validation demonstrable system each week. Each version inte- Demonstrate grates, tests, and demonstrates the progress that all Build Validate FS 1 + FS 2 developers have made. feature set 2 feature sets 1+2 Incremental The incremental-build process works well when validation each team consists of two to six developers plus a • • • Validate Demo team leader. Team members can work as individu- • • • • • • • • • • • • . als or perhaps in pairs using an agile process. Each Incremental rework individual or pair will typically produce several Build Validate unofficial builds during each development cycle feature set N FS1 … FSN using a copy of the current official version as a test- Demo and deliver bed. FS1 … FSN The incremental-build model scales well to large projects. Developers partition the architecture into (b) Time well-defined subsystems and allocate requirements and interfaces to each. The team can independently Figure 2. An incremental-build model: (a) partitioning of the design into test and demonstrate subsystems, perhaps using prioritized build sequences and (b) build-validate-demonstrate iterations. September 2005 35 Environmental context Functionality systems. System integration can proceed incre- Structure mentally as intermediate versions of the various Behavior subsystems become operational. Quality attributes As Figure 2b shows, successive incremental builds can overlap. Developers could, for example, start the next version’s detailed design while vali- dating the present version. In contrast to the agile Figure 3. Four dimensions of software: functionality, structure, behavior, and quality approach, the customer is not in the loop, except attributes. All four dimensions exist within the software’s environmental context. perhaps to observe some of the weekly demon- strations. What Is Refactoring? TYPES OF REWORK Both software development and maintenance Refactoring improves the structure of software so that developers can involve new work and rework. New work is con- more easily understand, modify, evolve, document, and test it. It can cerned with adding capabilities to the previous ver- also improve the quality attributes of software components and sub- sion, while rework involves modifying a previous systems or enhance their potential for reuse. version. The goal is to make it easier to incorporate reusable elements, add The basic premise of iterative development is that new elements, or accommodate future changes. Developers perform rework is inevitable because events that occur dur- refactoring in small steps. At each step, they perform tests to ensure that ing software development make once-through structural transformations do not alter functionality or behavior or development impossible in all but the simplest degrade necessary quality attributes. cases. Acknowledging and accommodating this Figure A illustrates refactoring in object-oriented development, which premise avoids the well-known pitfalls of massive can involve integration, testing, and rework that proponents • moving an attribute or a method from one class to another; of the waterfall model—a once-through, sequen- • consolidating common attributes or methods in two different classes tial process—encounter. Iterative processes, such into a parent class; as agile development and incremental build, pro- • splitting a class into two classes; vide the ability to gracefully modify the current ver- • adding an adapter to allow two components with incompatible sion of an evolving product while adding interfaces to work together; or capabilities to produce the next version. • modifying the relationships among classifiers (for example, chang- As Figure 3 shows, four dimensions character- ing an inheritance relationship into a composition relationship). ize software: functionality, structure, behavior, and quality attributes. Software exists in an environmental context from which it receives stimuli and to which it delivers responses. Class A Class AB The software’s computational features provide Attrs A1 Attrs A1 functionality.

Load more