1. Module 8: Software Evolution CSEB233 Fundamentals of Software Engineering Badariah Solemon 2010

2. Objectives: To explain about maintenance and supports required of an application, which is already in operation. To present Lehman’s laws of software evolution. To explain the concept of reengineering. To describe different activities of software reengineering.

3. Software Maintenance Software is released to end-users, and – within days, bug reports filter back to the software engineering organization. – within weeks, one class of users indicates that the software must be changed so that it can accommodate the special needs of their environment. – within months, another corporate group who wanted nothing to do with the software when it was released, now recognizes that it may provide them with unexpected benefit. They’ll need a few enhancements to make it work in their world. All of this work is software maintenance. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

4. Legacy Application Software In IT, legacy applications and data are those that have been inherited from languages, platforms, and techniques earlier than current technology. Most organizations who use computers have legacy applications and databases that serve critical business needs. Typically, the challenge is to keep the legacy application running while converting it to newer, more efficient code that makes use of new technology and programmer skills. Many organizations are migrating their legacy applications to new programming languages and operating systems that follow open or standard programming interfaces. http://searchdatacenter.techtarget.com/definition/legacy-application

5. Software Maintenance and Support Ongoing activities to change and support the software after it is in operation. – Software does not degrade or require periodic maintenance – However, software is continually evolving. Include: 1.Correcting defects 2.Adapting application to a changing business environment

6. Software Maintenance and Support (cnt’d) 3.Implementing enhancement at the request of stakeholders. 4.Supporting users as they integrate an application into their personal and business workflow.

7. Maintainable Software Maintainable software exhibits effective modularity It makes use of design patterns that allow ease of understanding. It has been constructed using well-defined coding standards and conventions, leading to source code that is self-documenting and understandable. It has undergone a variety of quality assurance techniques that have uncovered potential maintenance problems before the software is released. It has been created by software engineers who recognize that they may not be around when changes must be made. – Therefore, the design and implementation of the software must “assist” the person who is making the change These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

8. Supportability Software “the capability of supporting a software system over its whole product life. – This implies satisfying any necessary needs or requirements, but also the provision of equipment, support infrastructure, additional software, facilities, manpower, or any other resource required to maintain the software operational and capable of satisfying its function.” [SSO08] The software should contain facilities to assist support personnel when a defect is encountered in the operational environment (and make no mistake, defects will be encountered). Support personnel should have access to a database that contains records of all defects that have already been encountered—their characteristics, cause, and cure. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

9. Lehman’s Law of Software Evolution Year and Brief NameLaw 1.(1974) Continuing ChangeE-type systems must be continually adapted or they become progressively less satisfactory 2.(1974) Increasing ComplexityAs an E-type system evolves its complexity increases unless work is done to maintain or reduce it 3.(1974) Self RegulationE-type system evolution process is self regulating with distribution of product and process measures close to normal 4.(1978) Conservation of Organizational Stability The average effective global activity rate in an evolving E-type system is invariant over product lifetime 5.(1978) Conservation of Familiarity As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves[ 6.(1991) Continuing GrowthThe functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime 7.(1996) Declining QualityThe quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes 8.(1996) Feedback SystemE-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. Lehman, M. M.; J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski (1997). "Metrics and laws of software evolution—the nineties view". Proc. 4th International Software Metrics Symposium (METRICS '97). pp. 20-32. doi:10.1109/METRIC.1997.637156. http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf. A series of laws that Lehman and Belady formulated starting in 1974 with respect to software evolution.

10. Who Performs Maintenance? Separate maintenance team – May be more objective – May find it easier to distinguish how a software should work from how it does work Part of development team – Will build the software in a way that makes maintenance easier – May feel over-confident, and ignore the documentation to help maintenance effort

11. Reengineering To support ‘new business rules’, existing software may be modified or rebuilt (reengineered). Reengineering may begin with a Business Process Reengineering (BPR) before move on to software reengineering.

12. Reengineering To support ‘new business rules’, existing software may be modified or rebuilt (reengineered). Reengineering may begin with a Business Process Reengineering (BPR) before move on to software reengineering. Business Processes ITsystemsITsystems SoftwareApplicationsSoftwareApplications Reengineering

13. Business Process Reengineering (BPR) "... the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed.“ [Hammer and Champy, 1993] Business process – “a set of logically related tasks performed to achieve a defined business outcome” [Davenport and Young, 1990] – The business  business systems/functions  business processes  business subprocesses BPR is usually iterative.

14. A Model for BPR With six activities: pg. 766-767 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

15. Software Reengineering An activity that will absorb IT resources for many years – require systematic strategy. General reengineering principles: 1.Inspect the product 2.Inspect the structure of the product, rebuild if it is weak, remodel if it is structurally sound 3.Understand how well the original was built before you rebuild 4.If you begin rebuild, use only the best methods, tools, resources etc 5.Be disciplined about it – use practices that will result in high quality

16. Software Reengineering Process Model These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Forward engineering Data restructuring Code restructuring Reverse engineering Document restructuring Inventory analysis

17. Inventory Analysis build a table that contains all applications establish a list of criteria, e.g., – name of the application – year it was originally created – number of substantive changes made to it – total effort applied to make these changes – date of last substantive change – effort applied to make the last change – system(s) in which it resides – applications to which it interfaces,... analyze and prioritize to select candidates for reengineering These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

18. Document Restructuring Weak documentation is the trademark of many legacy systems. But what do we do about it? What are our options? 1.Creating documentation is far too time consuming. If the system works, we’ll live with what we have. In some cases, this is the correct approach. 2.Documentation must be updated, but we have limited resources. We’ll use a “document when touched” approach. It may not be necessary to fully redocument an application. 3.The system is business critical and must be fully redocumented. Even in this case, an intelligent approach is to reduce documentation to an essential minimum. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

19. Reverse Engineering Recreate design and specification information from the source code. The process: Pfleeger and Atlee (2006)

20. Code Structuring Source code is analyzed using a restructuring tool. Poorly design code segments are redesigned Violations of structured programming constructs are noted and code is then restructured (this can be done automatically) The resultant restructured code is reviewed and tested to ensure that no anomalies have been introduced Internal code documentation is updated. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

21. Code Restructuring Activities: 1.Interpreting the source code and representing it internally 2.Simplifying the internal representation 3.Regenerating structured code Pfleeger and Atlee (2006)

22. Data Structuring Is a full-scale reengineering activity In most cases, it begins with a reverse engineering activity. – Current data architecture is dissected and necessary data models are defined (Chapter 9). – Data objects and attributes are identified, and existing data structures are reviewed for quality. – When data structure is weak, the data are reengineered. Because data architecture has a strong influence on program architecture and the algorithms that populate it, changes to the data will invariably result in either architectural or code-level changes. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

23. Forward Engineering Forward engineering process applies software engineering principles, concepts, and methods to re-create an existing application. In most cases, forward engineering does not simply create a modern equivalent of an older program. Rather, new user and technology requirements are integrated into the reengineering effort. Capabilities of the older program may be extended too

24. The Economic of Reengineering Reengineering require a lot of resources. So, before an organization attempts to reengineer an existing application, it should perform a cost-benefit analysis. An example of cost-benefit analysis model is as proposed by Sneed (1995). (pg. 781)