Transcript CSEB233 Fundamentals of Software Engineering Module 8: Software Evolution Badariah Solemon 2010 Objectives: • To explain about maintenance and supports required of an application, which is.

CSEB233 Fundamentals of Software
Engineering
Module 8: Software Evolution
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.
Badariah Solemon 2010
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.
Badariah Solemon 2010
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
Badariah Solemon 2010
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
Badariah Solemon 2010
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.
• Not unusual for a software organization to
expend as much as 60 to 70 percent of all
resources on software maintenance.
Badariah Solemon 2010
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
Badariah Solemon 2010
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.
Badariah Solemon 2010
Lehman’s Law of Software Evolution
A series of laws that Lehman and Belady formulated starting in 1974 with
respect to 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.
Badariah Solemon 2010
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
Badariah Solemon 2010
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.
Badariah Solemon 2010
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
IT
systems
Reengineering
Software
Applications
Badariah Solemon 2010
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.
Badariah Solemon 2010
A Model for BPR
• With six activities:
pg. 766-767
Badariah Solemon 2010
Software Reengineering
• An activity that will absorb IT resources for many
years – require systematic strategy.
• General reengineering principles:
1.
2.
3.
4.
5.
Inspect the product
Inspect the structure of the product, rebuild if it is weak,
remodel if it is structurally sound
Understand how well the original was built before you rebuild
If you begin rebuild, use only the best methods, tools,
resources etc
Be disciplined about it – use practices that will result in high
quality
Badariah Solemon 2010
Software Reengineering Process
Model
Forward
engineering
Data
restructuring
Code
restructuring
Inventory
analysis
Document
restructuring
Reverse
engineering
Badariah Solemon 2010
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
Badariah Solemon 2010
Document Restructuring
• Weak documentation is the trademark of many
legacy systems.
• But what do we do about it? What are our
options?
1.
2.
3.
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.
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.
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.
Badariah Solemon 2010
Reverse Engineering
• Recreate design and specification information
from the source code.
• The process:
Pfleeger and Atlee (2006)
Badariah Solemon 2010
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.
Badariah Solemon 2010
Code Restructuring
• Activities:
1.
2.
3.
Interpreting the source code and representing it internally
Simplifying the internal representation
Regenerating structured code
Pfleeger and Atlee (2006)
Badariah Solemon 2010
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.
Badariah Solemon 2010
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
Badariah Solemon 2010
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)
Badariah Solemon 2010
Summary:
Students should have learned about:
• The maintenance and supports
required of an application, which is
already in operation.
• TheLehman’s laws of software
evolution.
• The concept of software reengineering.
• The different activities of software
reengineering.
Badariah Solemon 2010
References
• Contents in the slides are adapted from the book and the slides that
accompanied the book by R.S. Pressman, Software Engineering: A
Practitioner’s Approach, 7th. Edition, McGraw Hill, 2009.
• 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.
• http://searchdatacenter.techtarget.com/definition/legacyapplication
Badariah Solemon 2010