Module 8: Software Evolution

CSEB233 Fundamentals of Software Engineering

Badariah Solemon 2010

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.

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.

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

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 defects2.Adapting application to a changing business

environment

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.

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 changeThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

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.

Lehman’s Law of Software Evolution

Year and Brief Name Law

1. (1974) Continuing Change E-type systems must be continually adapted or they become progressively less satisfactory

2. (1974) Increasing Complexity As an E-type system evolves its complexity increases unless work is done to maintain or reduce it

3. (1974) Self Regulation E-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 Growth The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime

7. (1996) Declining Quality The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes

8. (1996) Feedback System E-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.

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

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.

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 ProcessesBusiness ProcessesBusiness ProcessesBusiness Processes

ITITsystemssystems

ITITsystemssystems Software Software

ApplicationsApplicationsSoftware Software

ApplicationsApplicationsReengineeringReengineering

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.

A Model for BPR

• With six activities:Businessdefinition

Processidentification

ProcessEvaluation

ProcessSpecificationand Design

Prototyping

Refinement&

Instantiation

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.

Software Reengineering

• An activity that will absorb IT resources for many years – require systematic strategy.

• General reengineering principles:1. Inspect the product2. Inspect the structure of the product, rebuild if it is weak,

remodel if it is structurally sound3. Understand how well the original was built before you rebuild4. 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

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.

Forwardengineering

Datarestructuring

Coderestructuring

Reverseengineering

Documentrestructuring

Inventoryanalysis

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.

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.

Reverse Engineering• Recreate design and specification information from the

source code.• The process:

Pfleeger and Atlee (2006)

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.

Code Restructuring• Activities:

1. Interpreting the source code and representing it internally2. Simplifying the internal representation3. Regenerating structured code

Pfleeger and Atlee (2006)

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.

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

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)