1. Software Aging By David Lorge Parnas Source: “Software Findamentals Collected papers by David L. Parnas.” Edited by Daniel M. Hoffman and Davic M. Weiss

2. Do software systems age analogously to human? What Nonsense! Software is a mathematical product; mathematics doesn’t decay with time If a program is correct today, it will be correct 100 years from now If it is wrong 100 years from now, it must have been wrong when it was written It make no sense to talk about software aging TRUE, BUT NOT REALY RELEVANT Software does get old and it costs more in old age than it did at birth.

3. Software products do exhibit a phenomenon that closely resemble human aging. Many products are now viewed as a burdensome legacy from the past. A steadily increasing amount of effort is going into the support of these older products. Like human aging, software aging is inevitable, but like human aging, there are things that we can do to slow down the process and sometimes even reverse its effects. The fact that software is now becoming a major “capital” of many high- tech firms. The aging of these products is impeding the further development of the systems that include them.

4. What causes software aging? Two basic types of software aging: Failure to keep up with changing environment Unless software is frequently updated, its users will become dissatisfied and they will change to a new product as soon as the benefits outweigh the costs of retaining and converting Tissue damage resulting from maintenance It is essential to upgrade software to prevent aging, changing software can cause a different form of aging. But changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade. Both lead to a decline in the value of a software product

5. Causes of software aging: Our expectations have changed We are no longer willing to use the clumsy software interfaces of yesterday We demand interactive access Old software would still do its job if used, but nobody would use it Old software must compete with new products When changes are not made, it seems as if the software has aged!

6. More causes of software aging: Designers of software had simple concept in mind when writing the program Changes made without understanding design concept Changed code is inconsistent with original concept After changes, one must know both the original design concept, and the exceptions After more changes – NOBODY understands the modified product When nobody understands the product Changes take longer Changes are more likely to introduce “bugs” The problem is exacerbated when maintainers do not have time to update the documentation

7. More causes Many companies allow the product line to split, with the second line inheriting the properties of the first. This policy leads to difficult to constrain, growth. Changes must be made to many versions instead of just one The cost of maintenance gets very high, it is no longer possible to keep up with the market on all the versions. Plus Developers move on to other projects Developers forget what they did and why they did it

8. More Causes: Bad documentation Information not available Information not correct Information hard to find Information must be verified Information is not precise, easily misinterpreted Documentation are not kept “alive”

9. The costs of software aging Rising Maintenance Costs It harder to know where to make changes Changes are harder to make There are more errors Testing becomes more of a burden Documentation takes longer to update

10. Inability to keep up with others Newer products have desired features Newer products can be adapted more quickly Newer products win more market share Program size increased order of magnitude makes changes more difficult

11. Reduced performance The size of the program grows; more demands on the computer resource More demands on the computer memory, more delays caused by swapping Performance decreases because of poor (or poorly understood) design Customers must upgrade their hardware to get acceptable response -- leads to switch to newer products to obtain better performance

12. Decreasing reliability Errors are introduced; each error corrected may introduce more than one error Improvements can make things worse -- often the only choice was to abandon the product or at least to stop repairing bugs Large groups of people are devoted to customer requested repairs

13. Reducing the costs of software aging Experience showed that any serious product requires extensive testing, review and revision after the first successful run. The work that is invested by a development organization after the first successful run and before the first release is usually much greater than that required to get the first successful run. Most organization only focus on that first release Experience with software aging tells us that we should be looking far beyond the first release to the time when product is old.

14. What can we do to delay the decay and limit software aging’s effects Design for success The only software that does not change is software that is not used. Designing for change is designing for success Apply: Information hiding Abstraction Separation of concerns Data hiding Object orientation By characterizing the likely classes changes; estimate the probabilities of each type of change Organize the software to confine likely changes to a small amount of code Implement objects that hide changeable data structures Provide an abstract interface that abstracts from the changes

15. Why the industry failed to apply these ideas? Programmers are impatient with such considerations; they are eager to meet deadline, there is no time to design for change Designs that result from a careful application of information hiding are not “natural” for many software designers Designers mimic older designs Many confuse design principles with choice of language Many developers do not have the education appropriate to the job

16. There is no miracle drugs or quick fix to this problem Good design is HARD, it requires: Careful consideration of possible changes Careful examination of constraints Careful design of interface Careful review Qualified people Do not depend on languages, we must recognize that software problems never went away in spite of the introduction of FORTRAN, PL/I. ADA

17. Keeping records – Documentation Design concepts and decisions are not recorded Documentation is neglected by researchers and practitioners Documentation is usually poorly organized, incomplete and imprecise Often the coverage is random, written when time and interest are there Where documentation is a contractual requirement, it’s often done by a technical writer who does not understand the system Documentation that seems clear today, may be difficult to understand tomorrow Documentation is not an “attractive” topic. But it is your responsibility as a software engineer to produce accurate design document and to keep them up-to-date

18. Second Opinions – reviews Reviews are not standard practice among developers, why? Many developers have no professional training in software and the concept of preparing and holding a design review is non-existent Lack of documentation is review against Software is often produced under time pressure, leads to “short-cut” Reviewer must represent long-term interests of the manufacturer or client Review for ease of change must become standard

19. Software aging is inevitable Our ability to design for change depends on our ability to predict the future We will make changes that violate our original assumptions Documentation, even if formal and precise, will never be perfect Reviews will overlook some issues Preventive measures are worthwhile, but we cannot eliminate aging We have to think about how to care for aging software!

20. How to care for aging software: Stopping the deterioration This is done by introducing, or recreating structure whenever changes are made. Applying the same design principles, if a design decision about the system is changed, the new data structure or algorithm can be hidden(encapsulated) in a way that make any future changes of that aspect of the system easier. Careful reviews must ensure that each changes is consistent with the intent of the original designers. New documents must be created and reviewed The code must be checked to make sure that it has been made consistent with these new documents

21. Retroactive documentation To slow the aging upgrade the documentation! Correcting the documentation can be a major project, but worth undertaking Redoing the documentation often leads to improvements in the software Writing the documentation is a way to study and understand the software It makes the next person’s job easier

22. Amputation Some code has been modified so often and so thoughtlessly, it is not worth saving. Often it should never have been written at all Sections of code should be discarded and replaced by new code which perform the function in some other way.

23. Restructuring When a large family of products gets out of control, a major effort to restructure it is appropriate. First step – reduce the size of the program Examine the various versions to determine why they are different Replace many versions with one by introducing “switches” that are checked at run-time to determine which version of behavior is wanted. It often pays to ship the same code to everyone – even those who have not paid for all the features.. The features can be “turned off”

24. Planning ahead If we want to prevent or at least slow down software aging, we must recognize it as a problem and plan for it. We must imposing standards on structure and documentation Design have to be documented, reviewed before coding begins Changes have to be documented and reviewed A thorough analysis of future changes must be a part of every product design and maintenance action

25. Using Mathematics to Estimate Software

26. In order to model software developments, we must take into account the different development life cycle models that are in use today. The lowest cost software development process is the waterfall Requirements Preliminary Design Detailed Design Code and Unit test Integration & System Test Acceptance Test, Implementation Verification Flow From “Rapid Testing” by Culbersion, Brown and Cobb Information flows from top to bottom. The arrows that are pointing backwards are all verification flows

27. Preliminary Design Modified Design Test Another popular software development life cycle model is called the spiral process. This process was first used to accommodate a prototype development to increase confidence in a set of requirements and allow experimentation with the human computer interface, database structure, usability, performance etc. System Design Prototyping Beta Prototyping Incremental Delivery Alpha Prototyping Customer Requirements Customer Demonstration/ Testing Reusable Components

28. The best software development life cycle model for software products that must get to market with limited functionality in order for a business venture to success is the spiral model. The spiral model provides a planned set of releases so that redoing some of the user interfaces, database design or improving the performance can be accomplished in a later release of the product. It is also the best process to use when the requirements are fuzzy and there is no precedent product. The spiral model best accommodates projects that have a high volatility of requirements, since adding, deleting, or changing requirements can easily be worked into the upcoming builds by a parallel effort of maintenance and new development folding into a future build of the product.

29. If “do it right the first time” applies to the type of software project you are working on, then the low-cost approach would be the waterfall model. If the user don’t know what they need as a total solution, or if releasing the entire software product some time in the distance future will cause it to fail customer expectations, then the low-risk approach would be the spiral model.

30. It is clear that the requirements of a software cost-estimating model must be modularized. It must be flexible enough to divide out the test effort from the program management or coding estimates. Barry Boehm (1981) identified three clusters in his database of successful software projects: Organic cluster – projects that had small teams performing work that they were very familiar with, such that a report being added to a existing program. Semidetached cluster – projects that fell somewhere in between the embedded and organic clusters. Embedded cluster – projects that had a large development team that assumed risks, such as lack of knowledge of programming or test environments, requirements volatility, shortened schedule, tight performance constraints on execution speed, etc.

31. Boehm developed three software cost estimation models – basic, intermediate, and detailed. Those three clusters are called modes, which provides a summary of Barry Boehm’s Constructive Cost Model (COCOMO) equations Basic COCOMO Model MM = 2.4 (KLOC) 1.05 TDEV = 2.5 (MM) 0.38 MM = Staff-Months TDEV = Time to Develop

32. The Intermediate/Detailed COCOMO Model They have a coefficient, called effort adjustment factor (EAF) Organic Mode MM adj = (EAF) 3.2 (KELOC) 1.05 TDEV = 2.5 (MM adj ) 0.38 Semidetached Mode MM adj = (EAF) 3.0 (KELOC) 1.12 TDEV = 2.5 (MM adj ) 0.35 Embedded Mode MM adj = (EAF) 2.8 (KELOC) 1.20 TDEV = 2.5 (MM adj ) 0.32 ELOC = Equivalent LOC EAF = Effort adjustment factor MM adj = Adjusted MM http://sunset.usc.edu/research/COCOMOII/index.htmlhttp://sunset.usc.edu/research/COCOMOII/index.html download a free version of COCOMO software cost estimation model

33. Cost Driver Values that are multiplied together to yield the Effort Adjustment Factor (EAF)

34. The difference between the Intermediate and Detailed COCOMO is that one EAF factor is applied to all phases in the Intermediate COCOMO, where in Detailed COCOMO, a different set of cost drivers are multiplied together to arrive at a phase-dependent EAF, which is applied to the appropriate phase in the calculation.

35. Although the COCOMO model was not intended for estimating maintenance effort for legacy systems, based on an annual change traffic (ACT) factor, is a pretty accurate method. The maintenance effort, MM maint, for the first three years after the a system is released can be estimated, based on ACT, which has a rule of thumb, average 15%, 10%, and 5% of the effort expended to produce the system MM maint = ACT x MM adj e.g. MM adj = 362 staff-months ACT = 15%, makes MM maint = 4.525 staff-months (first year) for a 50,000 LOC embedded development

36. Function Point Technology (software sizing) In Albercht (1979), a methodology of sizing software is presented that is built upon the premise that software development productivity is related to functionality. The areas of functionality that are to be counted, called the information domain values, are: Number of user inputs – Each user input that provides distinct application-oriented information to the user is counted. Inputs should be distinguished from inquiries. Number of user outputs – Each user output that provides application-oriented information to the user is counted. Output refers to reports, screens, error messages, etc. Number of user inquiries – an inquiry is defined as an online input that results in the generation of some immediate software response in the form of an online output

37. Number of files – each logical file (i.e. a logical grouping of data that may be one part of a large database of separate files) is counted Number of external interfaces – all machine-readable interfaces (e.g. data files on some media that are used to transmit to another system) are counted

38. 2-Steps of Function Point Technology Step 1 Once the data has been collected, a complexity adjustment scale Fi, i= 1, 2, … 14, is associated with each count. Rate each factor on a scale of 0 to 5: (0 = no influence; 1= incidental; 2= moderate; 3= average; 4= significant; 5= essential) 1.Does the system require reliable backup and recovery 2.Are data communication required 3.Are there distributed processing functions 4.Is performance critical 5.Will the system run in existing, heavily utilized operational environment 6.Does the system require online data entry 7.Does the online data entry require the input transaction to be built over multiple operational screens 8.Are the master files updated online 9.Are the inputs, outputs, files or inquiries complex 10.Is the internal process complex 11.Is the code designed to be reusable 12.Are conversion and installation included in the design 13.Is the system designed for multiple installations in different organizations 14.Is the application designed to facilitate change and ease of use by the user After answering all 14 questions, add up the numbers you have chosen for your answers and carry this sum forward to the next step.

39. Step 2 Measurement Parameter Count Simple Average Complex Weighting factors Number of user inputs x 3 4 6 = Number of user outputs x 4 5 7 = Number of user inquiries x 3 4 6 = Number of files x 7 10 15 = Number of external interfaces x 5 7 10 = Total Count FP = total-count x [.65 +.01 x SUM (Fi)]

40. A function point is a weighted index-type of metric for measuring the quantity of functionality of a software package as seen by an end-user. Allan Albercht invented the concept of function point while working at IBM in the early 1970s. He felt that the functionality of a software application is more significant determinant of application size than LOC. Function points align with the information processing functions delivered to the user. Function points provide a size measurement that is independent of development technique, technology, or programming language. As a size metric, function point counts are more reliable and can be determined earlier in the life cycle of the development. Today, there is an International Function Point Users Group (IFPUG) that was formed over a decade ago to standardize the definitions and usage of the technology

41. Homework 04/08/04 1.Read Chapters 11, 12 2.Research and understand the differences between the two software development life cycle models – waterfall and spiral. Discuss the advantages and disadvantages of each model.