SE-4283
Software Re-Engineering
Lecture: 01
Instructor: Mr. Mudassar Adeel Ahmed
Email : mudassar.adeel@cust.edu.pk
Class Session: Monday 02:00---03:50 pm (B-6)
Wednesday 02:00---02:50 pm (B-3)
Office Hours: After class, via email
My Introduction
Education
• M.S. Computer Software Engineering – NUST – 2016
Teaching Experience
• Lecturer Software Engineering at CUST from February, 2018 to Date
• Lecturer Computer Science at APCOMS-UET Taxila from Feb, 2017- Jan, 2018
• Taught following courses: Object-oriented Programming, Software Engineering-1,
Software Requirements Engineering, Introduction to Database Systems, Object
Oriented Analysis & Design, Software Quality Engineering, & Software Re-Engineering
My Introduction
Research Interests
• Model Driven Software Engineering
• Advance Software Engineering
• Software Quality Engineering
• Software Requirements Engineering
Specialization Area (w.r.t MS Thesis):
• Natural Language Processing (NLP)
My Introduction
• Publications
• Conference Papers: 8 [IEEE, Springer, ACM]
• Journal Publications:
1. Model Driven Architecture: Business modeling for Software standard models.
Published in “International Journal of Computer Science and Information Security ISSN
1947-5500 Vol. 14 No. 9” [Open Access Journal]
2. The Applications of Natural Language Processing (NLP) for Software Development
Phases – A Systematic Literature Review.
Journal of System & Software (Under Review) -- Elsevier [impact factor: 1.424]
3. Conceptual Class Model Generation from User Requirements using Natural Language
Processing.
Journal of Information & Software (Submitted) – Elsevier [impact factor: 1.569]
Your Background
• Name & Fathers Name
• City
• Last attended college with obtained marks/ %age
• Overall CGPA at CUST
• Area of interest w.r.t Degree
• Any Research Interest
• Optional: Any thing else
CODE OF ETHICS
• All students must come to class on time
(Attendance will be taken in first 5 to 10 mins)
• Students should remain attentive during class and
avoid use of Mobile phone, Laptops or any gadgets
• Respect faculty and staff through actions and
speech
• Class participation is encouraged
Course Introduction
• Course Objectives:
• This course helps students to understand and practice different
software reengineering techniques. The participants of this course
will learn how to apply reengineering techniques to maintain and
modify software systems.
• Prerequisites:
• Software Construction and Development (SE-3512)
• Mode
• Mix of lectures, demonstrations, discussions, exams
Text Book
• Primary
• Re-Engineering legacy software, David Lorge Parnas, Chris
Birchall, Safari Books, Shelter Island, NY, 2016.
• S. Demeyer, S. Ducasse, and O. Nierstrasz. Object-Oriented
Reengineering Patterns. Morgan Kaufmann, 2002.
• Reference
• Application Software Reengineering, Afshar alam, Tendai
Patenga, Dorling Kindersley Pvt. Ltd, Pearson Education in
South Asia, 2010.
• Software Maintenance and Evolution: a Roadmap,
K.H.Bennett and V.T Rajlich, The Future of Software
Engineering, ACM Press 2000.
Course Outline
Week # Class Topics
Week 1 Introduction to Software Re-Engineering
Week 2 Software Evolution
Week 3 Legacy Systems
RE-Engineering Techniques (reverse engineering, restructuring &
Week 4
forward propagation)
Week 5 Reverse Engineering & its techniques
Week 6 Refactoring code to analysis artifacts
Week 7 Refactoring code to architecture
Week 8 Object Oriented Re-engineering Patterns
Course Outline
Week # Class Topics
Week 9 Object Oriented Re-engineering Patterns cont.
Week 10 Object Oriented Re-engineering Patterns cont.
Week 11 Code restructuring
Week 12 Program comprehension
Week 13 Quality issues in re-engineering processes
Week 14 Tool support for Re-engineering, Challenges & Stakeholder aspiration
Week 15 Software maintenance and re-engineering economics.
Week 16 Student Presentation
Course Learning Outcome
(CLO’s)
• At the end of this course, the students should be able to:
• CLO:1. Define the concepts and techniques of software reengineering.
[C1 Remember]
• CLO:2. Demonstrate and utilize reengineering techniques to maintain
and modify software systems. [C3 Apply]
• CLO:3. Examine maintenance related problems associated with object-
oriented software systems. [C4 analyze]
• CLO:4. Investigate and design complex reengineering and reverse
engineering problems [C6 Create]
Evaluation Components
• Quizzes - 10
• Assignments - 10
• Project - 20
• Midterm - 20
• Final - 40
• Project (in group of max 4’s)
• Demonstration
Sequence [Todays Agenda]
Content of Lecture
•Introduction, Context and Strategies
•State-of-the-art definitions
•Reengineering difficulties and challenges
•Reengineering Techniques
•Why Reengineering Projects Fail
Traditional SDLC
Context: Software Life Cycle
Reengineering – Definitions -
1
Several definitions of reengineering:
•Preparation or improvement to software, usually for increased
maintainability, reusability or evolvability.
R. S. Arnold, A Roadmap Guide to Software Reengineering Technology, Software
Reengineering, 1994.
•The examination and alteration of a subject system to
reconstitute it in a new form and the subsequent
implementation of the new form
E. Chikofsky and J. Cross, Reverse Engineering and Design Recovery: A
Taxonomy, IEEE Software 7(1) Jan 1990: 13-17.
Reengineering – Definitions -
2
• Reengineering is the systematic transformation of an existing
system into a new form to realize quality improvements in
operation, system capability, functionality, performance, or
evolvability at a lower cost, schedule, or risk to the customer.
S. Tilley and D. Smith, Perspectives on Legacy System Reengineering, SEI White
Paper, 1995
What is Reengineering?
Reengineering – Related Topics
-1
Restructuring:
•Restructuring is the transformation from one representation
form to another at the same relative abstraction level, while
preserving the subject system’s external behavior
Refactoring:
•Refactoring is the process of changing a software system in
such a way that it does not alter the external behavior of the
code yet improves its internal structure.
Reengineering – Related Topics
-2
Business Process Reengineering (BPR):
•concerned with the conversion of business process and not of
computer processes
Data Reengineering:
•concerned with conversion of data format and not its content
Why Reengineer?
Why does an organization decide to reengineer one or more of
their systems:
•Software system is an integral part of the organization.
•System must be regularly maintained and maintenance is
becoming a large cost factor.
•Less risk and cost than redevelopment.
Reengineering difficulties
and challenges
Reasons why legacy systems have not been designed to
accommodate change:
•Short life expectancy – not anticipated to last decades when
first developed.
•Failure of process models and software engineering culture to
treat evolution as a first class activity – future requirements
ignored.
•Satisfying constraints that existed at the time of development –
hardware (memory and processing power).
Reengineering Strategies
Reengineering Strategies for legacy applications:
•Ignore – discard them
•Cold turkey – rewrite them from scratch
•Integrate – consolidate them into the current and future
applications by access in place
•Data Warehouse – build a “shadow”system to house the
frequently accessed data
•Gradual Migration – rearchitect and transition gradually
Factors Influencing Strategy
The following factors will influence what strategy is to be
chosen:
•Business value of the legacy systems – support current as well
as future business processes.
•Flexibility and growth requirements – if legacy system does not
need extensive changes for flexibility and growth then minimal
effort for integration may be appropriate.
•Technical status of the legacy system – represents the quality
of the system in terms of modularity, error rates, flexibility and
utilization of current technologies.
Categories of Legacy
Applications
• Completely decomposable – all components are well
structured and separable. Friendly to migration efforts
• Data decomposable – data services well structured and well-
defined interfaces. Semi-friendly to migration efforts
• Program decomposable – program modules are well
structured and have well-defined interfaces. Semifriendly to
migration efforts
Strategies – Ignore - 1
When can the existing system be discarded?
•The business has changed and new methods of doing business
have been developed, existing methods are being phased out.
•It is too costly to try to reengineer the current systems.
•Current systems are monolithic and not reusable.
•New COTS products can be bought with the same or similar
functionality for less cost that reengineering
Strategies – Ignore - 2
• In most situations it is not practical to ignore legacy systems
especially the data.
• Some organizations are ignoring legacy systems by
outsourcing them to software houses that specialize in
operating and maintaining legacy applications.
Strategies – Cold Turkey - 1
When can the existing system be ignored?
•The business has changed and new methods of doing business
have been developed – need to build systems to implement
these new methods.
•It is too costly to try and understand what you currently have.
•It is too costly to try to reengineer the current systems.
•Time and resources are available to start from scratch.
Strategies – Cold Turkey - 2
In practice this approach may not be viable because:
•Management may not allow such large investments in
development just to have a more flexible system – must have a
better system produced.
•Business does not stand still while new systems are being
developed.
•Specifications for legacy systems rarely exist and
undocumented dependencies frequently exist.
•The rewritten system themselves become legacy before
completion as development takes a long time.
Strategy – Integrate - 1
When can the existing system be integrated?
•A lot of the business knowledge and rules are built into the
current systems and these need to be preserved – high business
value.
•Costs will be reduced by reengineering the current systems
rather than developing from scratch.
•Time and resources are not available to start from scratch.
Strategy – Integrate - 2
In practice integration is carried out when:
•Access to needed data is urgent and cannot be postponed until
completion of migration.
•Needed data can be accessed by client applications by
employing COTS technologies.
Strategy – Data Warehouse -
1
When can the data warehouse option be used?:
•The data is the most important part of the existing systems.
•There is a need for new ways to access and manipulate the
data (web-based, distributed).
•These isn’t a need to reimplement existing system functionality
and time and resources are not available to do so.
Strategy – Data Warehouse -
2
Organization’s data is in two formats:
•Operational data which is used for day-to-day transaction
processing.
•Analysis (decision support) data which are used for business
analysis and report generation. This data is extracted from the
operational data periodically and downloaded, usually to a
separate system, for report generation and analysis..
Strategies - Gradual Migration -
1
When can the gradual migration option be used?:
•Integration is not economical over a long period of time or
those legacy systems are to be phased out.
•There is an immediate need to update some of the more
important components.
•Time and resources are not available to do the reengineering
all at once.
•It is unclear how the reengineering effort will proceed – need
for prototyping of different reengineering methods.
Strategies - Gradual Migration -
2
• The legacy and target systems may coexist during the
migration stage.
• Challenge will be to design gateways to isolate the migration
steps so that end users do not know if the data is coming from
old or new systems.
• The development of gateways to facilitate migration is usually
an expensive undertaking.
Reengineering Issues - 1
• Ease of change
• how difficult will it be to change the legacy system
• Comprehensibility
• how difficult is it to obtain an understanding of the systems that
will need to be reengineered
• Size
• what is the size of the systems that have to be reengineering
• Decomposability
• how easy or difficult is it to decompose the software system
Reengineering Issues - 2
• Degree of coupling
• how coupled are the existing components
• Degree of cohesion
• how cohesive are the components
• Granularity
• can the system be reused in large chunks or does it need to be
decomposed
• Complexity
• what is the level of complexity of the software
• Degree of documentation
• what documentation is available
Reengineering Issues - 3
• Degree of abstraction
• what abstractions are available
• Language type & choice
• what language(s) is the existing system written in and what will
be used in the new system
• Referential transparency
• do the components always produce the same output
Reengineering – Risks - 1
Some of the risk areas in reengineering :-
•Process
• is there a defined process to follow to successfully reengineer the
systems.
•Personnel
• are the necessary resources available.
•Skills/Education
• do the personnel have the right skills or can they be trained.
•System/Application
• difficulties with the legacy system.
Reengineering – Risks - 2
• Technology
what technology is used in the target system
• Tools
are there tools to assist in the reengineering work
• Strategy
has the right strategy been chosen
Reengineering Projects – Why
they fail?
Reengineering projects fail for many reasons:
•Most reasons are not specific to reengineering projects but also
occur in new development projects.
•Usually not just one reason why a project fails but maybe a
combination of reasons.
Bergey, John; Smith, Dennis; Tilley, Scott; Weiderman, Nelson; Woods,
Steven. Why Reengineering Projects Fail (CMU/SEI-99-TR-010).
Reengineering Projects Fail - 1
Reason #1:
•The organization inadvertently adopts a flawed or incomplete
reengineering strategy.
•This may be caused by poor assumptions or lack of attention to
detail. Maybe the wrong problem is being addressed. Possibly
not all of the components and steps are considered. If a system
is ignored or discarded a lot of corporate knowledge may be
lost/abandoned.
Reengineering Projects Fail - 2
Reason #2:
•The organization makes inappropriate use of outside
consultants and outside contractors.
•Outsiders may bring domain understanding, technical skills,
and extra resources. However they may not know the business
as well as the insiders. Their role needs to be clearly defined and
monitored. Outsiders may have conflicting interests (maximizing
cost rather than minimizing). Outsiders take control of the work
rather than it being controlled by insiders (results in lack of
insight by insiders)
Reengineering Projects Fail - 3
Reason #3:
•The work force is tied to old technologies with inadequate
training programs.
•The lack of training can cause project failure. New
programming paradigms will be adopted. No possible to
continue to do business as usual while at the same time bringing
the same workforce up to speed on new technologies. Must be
a conscientious and persistent effort to upgrade skills of the
existing workforce or there must be a replacement of existing
workforce or replacement or some combination.
Reengineering Projects Fail - 4
Reason #4:
•The organization does not have its legacy system under control.
•Before a system can be managed effectively, a system baseline
under configuration management should be in place to aid in
disciplined evolution. Legacy system needs to be well
documented, with an understanding of the priority of change
requests and their impact on the system.
Reengineering Projects Fail - 5
Reason #5:
•There is too little elicitation and validation of requirements for
the reengineering effort.
•There may be flaws in the requirements elicitation and
validation processes. Requirements include functional, non-
functional, user and customer requirements.
Reengineering Projects Fail - 6
Reason #6:
•Software architecture is not a primary reengineering
consideration.
•Failure can occur when a methodical evaluation of the software
architecture of the legacy and target systems is not the driving
factor in the development of the reengineering technical
approach. Evaluation of the legacy architecture may decide
what strategy is undertaken.
Reengineering Projects Fail - 7
Reason #7:
•There is no notion of a separate and distinct reengineering
process.
•The means by which a legacy system evolves can have a large
influence on the success of failure. The existence of a
documented life-cycle process and corresponding work
products are often wrongly viewed as being evidence of a sound
reengineering process. There needs to be a set of tasks and
guidance to perform them and an understanding of how it all
fits together.
Reengineering Projects Fail - 8
Reason #8:
•There is inadequate planning or inadequate resolve to follow
the plans.
•Projects often get out of kilter by focusing on the low-level
“software problems” and neglecting the intermediate-level
tactical management planning and systems engineering
planning aspects of the job.
•Sometimes there may be an absence of a documented project
plan that has the buy-in of the key stakeholders (line
management, project team, domain and system experts and
software engineers).
Reengineering Projects Fail - 9
Reason #9:
•Management lacks long-term commitment.
•Management support means careful monitoring and putting
things back on the track when they stray off track.
•If management gets distracted with other projects during the
course of a major reengineering effort, it will not know when
things go wrong.
Reengineering Projects Fail - 10
Reason #10:
•Management predetermines technical decisions.
•Mandates or edicts issued by the upper management that
predetermine the technical approach or schedule, cost, and
performance considerations without sufficient project team
input or concurrence are frequently seen to cause reengineering
project failure.
55
