COVER FEATURE Iterative Rework: The Good, the Bad, and the Ugly

In 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 . Incremental build lets developers produce weekly builds of an evolving product. A 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 (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 devel- opment. Some agile process models require devel- opers 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 require- ments 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. 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 —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 environ- mental 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. Structure is both static—programs Attrs A2 = > Ops A1( ) and data as designed and coded—and dynamic— Ops A1( ) the interconnections among software entities that Ops A2( ) come and go at runtime. The behavioral dimension reflects how a system’s state changes over time in Class B Class A Class B response to computations and external events. Attrs B Attrs A2 Attrs B Quality attributes include performance, reliability, Ops B( ) Ops A2( ) Ops B( ) safety, security, dependability, ease of modification, and reusability. Rework results in changes to one or more of Figure A. Refactoring to avoid inheritance of unneeded attributes and these four dimensions. A well-known form of operations in Class B (Attrs2 and Ops2( )). By placing shared capabilities rework is refactoring, in which developers perform (Attrs1 and Ops1()) in an abstract parent class, developers can avoid semantics-preserving structural transformations, inheriting unneeded attributes and operations in subclasses. usually in small steps.1 The “What Is Refactoring?” sidebar gives an example of this practice. Software developers must take care to ensure that structural stubs and drivers as interfaces, or perhaps using transformations do not alter functionality or early, incremental versions of other evolving sub- behavior or degrade necessary quality attributes.

36 Computer Table 1. An iterative rework taxonomy.

Type of rework Characteristics Good, bad, or ugly?

Evolutionary Work performed on a previous version of an Good—if it adds value without violating a cost or evolving software product or system to enhance schedule constraint and add value to it Bad—if it violates a cost or schedule constraint Ugly—if it smacks of “gold plating” Avoidable Work performed on a previous version of an Good—small amounts are inevitable; better now Retrospective evolving software product or system that than later developers should have performed previously Bad—if it occurs routinely Ugly—if excessive, it indicates a need to revise work processes Avoidable Work performed to fix defects in the current Good—if total rework is within control limits Corrective and previous versions of an evolving software Bad—if it results in patterns of special-cause effects product or system Ugly—if it results in an out-of-control development process

As Table 1 shows, rework can be either evolu- during development indicate the likelihood of high tionary or avoidable,2 and avoidable rework can levels of customer-discovered defects (one of soft- be retrospective or corrective. ware engineering’s many counterintuitive results). Retrospective rework. In retrospective rework, Evolutionary rework developers modify the previous version’s function- Evolutionary rework adds value to an evolving ality, structure, behavior, or quality attributes, or product by modifying one or more of the current some combination of these because the developers version’s four dimensions (structure, functionality, of that version (likely themselves) failed to imple- behavior, and quality) to provide new capabilities ment it in a manner that provided foreseeable capa- in the next version. Evolutionary rework typically bilities needed in the next version. In contrast to occurs in response to changes in user requirements, evolutionary rework, retrospective rework occurs design constraints, environmental factors, or other because developers knew about the needs but conditions that the developers were not aware of didn’t accommodate them for whatever reason or could not have foreseen when developing the (perhaps because of excessive schedule pressure). software’s previous version. Evolutionary rework is Suppose, for example, that rework involved unavoidable because the developers could not have adding an interface to the next version. The rework known about or foreseen the changes that necessi- would be evolutionary if the customers added the tate it. requirement for such an interface after the devel- opers had finished the previous version. The Avoidable rework rework would be retrospective (and thus avoidable) In principle, avoidable rework is work that no if the developers knew the capabilities the new ver- one would have to do had the previous work been sion would require and did not add the interface in correct, complete, and consistent. That means the anticipation of needing it later on. previous work satisfies its requirements, is fit for Corrective rework. Corrective rework occurs its intended use, and does not contain defects when developers correct defects that result from (unlike hardware, software does not break from mistakes previous developers (most likely them- repetitive use; all defects in software are traceable selves) made. Defects can be due to mistakes of to human error). commission—doing something incorrectly—or In practice, some amount of avoidable rework is mistakes of omission—not doing something they inevitable—even desirable—because insufficient or others should have done. Defects encountered rework could mean that the software developers are at runtime can result in failures, which could cause not doing enough refactoring, reviewing, or testing. system crashes or produce incorrect results or An excessive amount of avoidable rework, however, unexpected behavior. reduces productivity, increases costs, delays sched- Corrective rework fixes defects detected in the ules, and demoralizes the development team. It also new capabilities or defects in a previous version erodes customer satisfaction because customers tend that the new capabilities expose. In iterative devel- to doubt the quality of software that has high lev- opment, mistakes count as defects if developers find els of rework, thinking it might mean the delivered them software will have too many defects. Because a certain percentage of defects will • while integrating the new capabilities of the escape the development process, high defect levels next version with the current version or

September 2005 37 • while verifying and validating the next Collecting and analyzing rework data The line version. The development team and organization must between understand the kinds of rework that occur and why, Verification is the process of determining which requires collecting and analyzing rework evolutionary and that a work product is complete, consistent, data. This activity is possible even in ambiguous retrospective and correct with respect to its requirements. situations. Because the goal is to identify major rework can be Validation determines if a work product trends and to determine the rework’s root causes, fuzzy. is suitable for its intended use. In iterative the rework data does not have to be highly accu- development, common verification tech- rate to indicate problem areas. niques include traceability, peer reviews, and Collected rework data fits the three categories in testing, while testing and demonstrations are Table 1: common validation techniques. Mistakes that developers make and correct while • Evolutionary. Rework caused by external fac- developing the next versions of their work prod- tors, such as changed requirements, design ucts do not count as defects. Defects count only in constraints, environmental factors, or other work products that have satisfied their acceptance unforeseeable external events. criteria and are then checked into the official build • Retrospective. Rework to improve structure, directory. functionality, behavior, or quality attributes of a previous version to accommodate the needs IS IT GOOD OR BAD? of the current version while building the cur- In many cases, rework is obviously done in rent version. response to changes in user requirements, design • Corrective. Rework to fix defects discovered in constraints, or the operational environment (evo- the current version and previous versions during lutionary rework). In other cases, rework addresses reviews, tests, and demonstrations of the cur- the failure of the previous version to provide the rent version. capabilities needed in the next version (retrospec- tive rework). In still others, it is in response to Four common techniques—informal anecdotes, detected defects (corrective rework). observation, record keeping, and automated ver- sion control—are suitable for collecting rework Fuzzy lines data. The line between evolutionary and retrospective Informal anecdotes and observation are useful rework—and even whether one is good and the indicators for small agile development teams and other bad—can be fuzzy. incremental-build subsystem teams. Record keep- Suppose, for example, that unforeseeable refac- ing is essential, although software developers tend toring is required to modify the previous version’s to avoid it because they feel it takes time that structure to make it a suitable basis for the capa- detracts from their productivity and because they bilities of the next version; the rework effort is fear that the organization will tie rework to per- evolutionary and thus unavoidable (good). If devel- formance reviews. opers had foreseen future needs but chose not to Publishing sanitized rework data in summary include them in the previous version, the rework form and basing process improvements on the data effort is retrospective and thus avoidable (bad). will show developers that the time spent in record The fuzzy part is in the interpretation. Customers keeping results in more efficient and effective work might say that they are only clarifying requirements processes, thus increasing productivity. Organiza- the developers should have understood (retrospec- tions can ameliorate the fear of tying rework to per- tive rework), while the developers might maintain formance by having a nonthreatening person such that the customer changed the requirements (evo- as a clerical worker ask each developer what per- lutionary rework). centage of the previous day was spent on new work In other cases, retrospective rework might be the and evolutionary, retrospective, and corrective better choice. Suppose reworking version 5 would rework. That person then records the composite take less effort than attempting to accommodate data for the team or project, thus preserving indi- version 5’s needs while building version 4. In this vidual anonymity. case, rework to version 4 while developing version Most iterative development projects require some 5 is arguably delayed evolution, not retrospective kind of automated version-control system because rework. of the many interrelated, ongoing work activities

38 Computer How Control Charts Work

A control chart is a plot of a variable of interest versus time in which the variable has specified control limits. In the 1920s, Walter Shewart developed control charts as a statistical method for analyzing manu- and work products. With automated version con- facturing defects in the mechanical switching relays used in telephone trol, an organization can easily collect data on the switching centers. Shewart made the distinction between common- and effort spent (new work and each kind of rework) special-cause effects. for each product version by adding electronic forms When plotted against time, common-cause effects exhibit random that developers complete when they check in the fluctuations around a mean value. In software development, common- next version’s components. The collected data is cause effects of rework are the noise in the development process that not associated with the person who enters it, thus results from factors such as variations in developers’ skill levels and moti- ensuring anonymity. vations, fluctuations in requirements, lack of familiarity with the appli- Developers should be willing to participate in cation domain, and product complexity. One of the goals of quality collecting rework data once they receive compos- improvement is to reduce the mean and deviation of common-cause vari- ite, sanitized feedback, see improvements based on ations. that feedback, and learn through experience that Special-cause effects are the result of exceptional situations that pro- managers will not use rework data in performance duce spikes and troughs in a variable of interest that cause the value to evaluations (which is impossible if the data is lie outside the band defined by an upper control limit (UCL) and a lower anonymous). Training classes, mentoring, and dis- control limit (LCL). A process that is in control exhibits random fluc- cussion groups can help developers learn to cate- tuations about a mean value, and all variations are within the UCL and gorize rework data consistently. LCL. An out-of-control process exhibits patterns that violate the UCLs and LCLs for variables of interest. HOW MUCH IS ACCEPTABLE? For manufacturing processes, Shewart used three standard deviations µ 3σ For several years, our rule of thumb has been that from the mean as the UCL and LCL ( ± ) and two criteria to indi- total rework (evolutionary plus both types of avoid- cate patterns of special-cause effects worth investigating: able) is acceptable at 10 to 20 percent of the total • effort for each reporting period in an iterative devel- two of three successive measurements on the same side of the mean σ opment process. The reporting period typically and more than 3 beyond it, or • varies from a week to a month. Weekly analysis of four of five successive measurements on the same side of the mean σ rework data is desirable in a project’s early stages. and more than 2 beyond it Less frequent reporting and analysis is appropriate once rework stabilizes and remains within the Determining the UCL and LCL of a control chart for a particular vari- desired range. able of interest is based on pragmatic considerations. We have found In agile development, 10 to 20 percent of the effort that, for most organizations, a UCL of 20 percent and an LCL of 10 is about one to two hours per workday for each percent are both desirable and achievable for software rework. developer (or developer pair in paired program- ming). Rework of 10 to 20 percent in a weekly incre- mental-build process is roughly a half to a full day picious if developers refactor less than 10 percent of effort per developer during integration, review, of the code during each iteration.3 testing, and demonstration of the weekly builds. The purpose of reviewing and testing is to find Spending more than 20 percent of total effort on defects. Software developers are only human; rework (evolutionary and avoidable) indicates humans make mistakes that result in defects that problems in the work processes, work products, or must be corrected. As a result, the best organiza- both. Excessive evolutionary rework typically indi- tions rarely achieve less than 5 percent corrective cates problems in requirements, design, or envi- rework, so it is reasonable to be suspicious if evo- ronmental factors, such as an unstable operating lutionary, retrospective, and corrective rework total system or changing hardware specifications. less than 10 percent of the overall effort. Excessive avoidable rework indicates problems in the development process, the tools, the methods, DEALING WITH THE UGLY the design strategy, or the developers’ skills or moti- The “How Control Charts Work” sidebar vation. It could also be the result of excessive sched- describes the control-chart methodology that qual- ule pressure. ity initiatives such as total quality management and Less than 10 percent rework, on the other hand, six sigma use. The methodology suggests conduct- could indicate insufficient reviewing, revising, and ing a root-cause analysis and initiating corrective testing. Robert Cringely addresses the possibility action when software rework in two of three or of too much refactoring (www.pbs.org/cringely/ three of five successive reporting periods exceeds pulpit/pulpit20030508.html), but Martin Fowler 20 percent of total effort or is less than 10 percent and Kendall Scott advise organizations to be sus- of total effort.4,5

September 2005 39 Rework per reporting period 20%

on clean-room projects at the NASA Goddard 10% Space Flight Center was avoidable rework.6 Other reports indicate that rework can amount to as much as 80 percent of total work.7-9 An analysis of (a) Reporting Cocomo II data indicates that most of the savings periods Rework per in effort from improved software process matu- reporting period rity, software architectures, and software risk 20% management came from reducing avoidable rework.2 Clearly, identifying and remedying the causes of avoidable rework offers outstanding opportunities 10% for higher quality, improved productivity, increased worker morale, and increased customer satisfac- tion. Figure 5 illustrates the effort saved by reduc- (b) Reporting periods ing defects (mistakes made), which reduces avoidable rework and thus reduces total effort. A well-known example is Raytheon’s reduction of Figure 4. Rework control charts Illustrating (a) excessive rework and (b) rework from 41 to 11 percent over four years, for insufficient rework. a net savings of $16 million.10 Figure 5 also illustrates the additional effort that organizations must expend on quality enhancement Quality Defect reduction to meet the stringent requirements of safety-critical enhancement reduces rework and mission-critical systems, which demand the low- increases total and total effort est possible defect levels. Process improvements that effort reduce defects can help offset that additional effort. The fundamental tenet of process improvement is that superior products result from superior processes. From Walter Shewart’s seminal work on Total effort Total effort includes quality improvement to process improvements 10% to 20% rework based on the current SEI Capability Maturity Model Integration and ISO Software Process Improvement and Capability Determination process maturity models, investments in process Defect density improvement have repeatedly yielded significant returns.11-13 Process improvement involves changing Figure 5. Effort saved by reducing defects, thus reducing avoidable rework. work activities, organizational structures, roles, relationships, methods, tools, and techniques to Figure 4 shows situations in which rework is improve quality, productivity, morale, profits, and excessive and insufficient. In Figure 4a, rework is customer satisfaction. excessive in three of five successive reporting peri- Identifying the root causes of avoidable rework ods, indicating that corrective action is warranted, can provide key indicators of the processes most in while Figure 4b shows insufficient rework in two of need of improvement. Improvements in require- three reporting periods. The anomaly in Figure 4b ments-based testing and increased attention to inter- might be the result of insufficient review and test- face design (two of the most common causes of ing, which warrants corrective action. It might also avoidable rework) might, for example, cut avoidable be the result of exceptional quality in those ver- rework in half. If avoidable rework were 40 percent sions, which warrants determining root causes so of total work (not untypical), this reduction would that the organization can emulate causative factors boost organizational performance by 20 percent. in other projects.

PROCESS IMPROVEMENT voidable rework is unnecessarily high in most Avoidable rework is the bane of software devel- software organizations. Identifying and cor- opment and modification. Vic Basili and Scott A recting its root causes is a high-leverage mech- Green reported that 40 to 50 percent of the work anism for improving quality, productivity, morale,

40 Computer profits, and customer satisfaction. Organizations misc/annual-report/2002.pdf. seeking to improve these factors should try to 10. R. Dion, “Process Improvement and the Corporate answer questions in six areas: Balance Sheet,” IEEE Software, July/Aug. 1993, pp. 28-35. • How can we collect rework data without 11. P. Crosby, Quality Is Free, Penguin Books, 1980. intruding into and disrupting the developers’ 12. P. Crosby, Quality Is Still Free, McGraw-Hill, 1996. creative efforts more than is necessary? 13. Carnegie Mellon Software Eng. Inst., “Demonstrat- • What percentage of avoidable rework is ret- ing the Impact and Benefits of CMMI: An Update rospective, and for which product attributes and Preliminary Report,” Oct. 2003;www.sei.cmu. does it occur? edu/publications/documents/03.reports/03sr009. • How can we better anticipate the capabilities html. we will need in the next version so that we can reduce retrospective rework? Richard E. (Dick) Fairley is a professor of com- • What kinds of mistakes do we make and when puter science and director of the software engi- do we make them? Could we detect them neering program in the OGI School of Science and sooner? How could we prevent them? Engineering of the Oregon Health and Science Uni- • How much corrective rework does it take to versity. His research interests include software sys- fix our mistakes? tems engineering, analysis and design, project • How can we improve our processes to reduce management, and practical software process or eliminate these kinds of mistakes? improvement. Fairley received a PhD in from the University of California, Los The answers to some of the questions about Angeles. He is a member of the IEEE Computer avoidable rework may be idiosyncratic to particu- Society. Contact him at [email protected]. lar projects and organizations, but most are com- mon to all types of organizations and software- Mary Jane Willshire is dean of computer science intensive systems and products. Whether avoidable for the Colorado Technical University system. Her rework comes from local circumstances or the fail- research interests include , ure to apply well-known practices, understanding human-computer interaction, and database man- and correcting its root causes is the key to cost- agement systems. Willshire received a PhD in effective process improvement. I computer science from Georgia Tech. She is a member of the IEEE, IEEE Computer Society, SWE, and the ACM. Contact her at mjwillshire@ References coloradotech.edu. 1. M. Fowler et al., Refactoring: Improving the Design of Existing Code, Addison Wesley, 1999. 2. B. Boehm and V. Basili, “Software Defect Reduction Help shape Top 10 List,” Computer, Jan. 2001, pp. 135-137. 3. M. Fowler and K. Scott, UML Distilled, 2nd ed., the IEEE Computer Addison Wesley, 1999, p. 28. 4. W. Shewart, Statistical Methods from the Viewpoint Society of tomorrow. of Quality Control, Dover, 1956. 5. S. Sytsma and K. Manley, “Common Control Chart Cookbook;” www.sytsma.com/tqmtools/charts.html. Vote for 2006 IEEE 6. V. Basili and S. Green, “Software Process Evolution Computer Society officers. at the SEL,” IEEE Software, July 1994, pp. 58-66. 7. C. Jones, Applied , McGraw- Polls open 8 August – 4 October Hill, 1996. 8. NSF Center for Empirically Based - ing (CeBase), “Summary of the First CeBase e-Work- shop,” Mar. 2001; www.cebase.org/www/research Activities/defectReduction/eworkshop1/. 9. S.E. Cross, “Message from the Director,” 2002 Annual Report, Carnegie Mellon Univ., Software www.computer.org/election/ Eng. Inst., p. 3; www.sei.cmu.edu/pub/documents/

September 2005 41