SENG 540 Software Evolution

1
SENG 540 Software Evolution

• Lecture 5
• 19 June 2007

2
Dates

• Class Schedule
• 6/26 - Midterm
• 7/1 Second assignment due
• 7/31 Third assignment due
• 8/7 Final exam

3
Midterm Information

• Take home test
• Test will be delivered on 26 June 2007
• You will have until midnight on 27 June 2007 to
  email back your answers
• The content of the test is focused on the
  lectures up to and including tonight (19 June
  2007)
• Questions are short-answer, short-definition, or
  small essay type questions

4
Assignment 2

• Similar to the first assignment
• Definitions
• Analysis of evolution
• Part I Write definitions for
• The process of program understanding
• Program comprehension
• System-of-systems
• Reengineering
• Software pattern
• Static program analysis
• Bottom-up program understanding

5
Assignment 2

• Examine the Firefox browser
• Answer the following questions
• Briefly describe the extension architecture of
  the Firefox browser
• Briefly describe the Firefox plug-in
  architecture.
• Briefly describe how an application developer can
  integrate his or her application into the Firefox
  browser
• What are the benefits for an application
  developer to use Firefox?
• What are the mechanisms to use and rules to
  follow to develop applications for Firefox?
• Resources available in assignment located in docs
  section of website

6
Evolutionary software

• Shift to develop software which continually
  evolves
• Develop software which is maintainable and can
  accommodate change
• Looking for a single incremental approach to
  evolving a system
• Rather there are families of solutions

7
Best Candidate for Reengineering?

• Legacy Software
• Characteristics
• Resistant to change
• Characteristics
• Old 10-25 years
• Large 100K - 1M LOC
• Poorly structured traumatic maintenance
• Poorly understood personnel turn-over
• Represent substantial corporate knowledge
• Pervasive (and growing in number)

8
Reengineering

• Offers an approach to migrating a legacy system
  to an evolvable system in a disciplined manner
  through systematic transformations
• Broader scope than just software
• Just one mechanism for evolution

9
Reengineering -- Definition

• SEI
• 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.

10
Reengineering - Definitions (2)

• Other definitions
• This is the examination and alteration of an item
  or a system under consideration to reconstitute
  it in some new form and for the subsequent
  implementation of that form
• Any activity that improves ones understanding of
  software and/or improves the software itself,
  usually for increased maintainability,
  reusability, or evolvability

11
Reengineering Other Definitions (3)

• Software reengineering. This is the examination
  and alteration of an existing item or system to
  reconstitute it in a new form and encompasses a
  combination of subprocesses such as
  re-documentation, reverse engineering,
  restructuring, retargeting, and forward
  engineering.
• Re-documentation. This is the process of
  analyzing the system or item to develop and
  produce support documentation in forms such as
  user manuals and reformatting the source code
  listing of the systems.
• Restructuring. This is the process of
  transforming the item or system from one form to
  another at the similar relative abstraction level
  and at the same time keeping the subject system's
  external functional behavior intact.
• Forward engineering. This is a set of engineering
  activities that makes use of products or
  artifacts derived from legacy software and new
  needs to manufacture or produce a brand-new
  target system or item.
• Business process reengineering. This is the
  fundamental rethinking and radical redesign of
  business processes to achieve tangible or
  dramatic improvements in vital and contemporary
  measures of performance, such as service, speed,
  quality, and cost.
• Data reengineering. This refers to the tools that
  conduct all of the associated reengineering
  functions with source code (forward engineering,
  re-documentation, translation, retargeting,
  restructuring, and reverse engineering) but act
  specifically upon data files.

12
Goals of Reengineering

• Lower maintenance costs and/or cycle time
• Reduce maintenance backlog
• Improve quality of maintenance fixes
• Achieve greater reliability
• Compensate for loss of staff or loss of skills
• Increase raw product performance
• Remove obsolete functions

13
Goals of Reengineering (2)

• Increase capacity to accommodate more processing
  demand
• Replace obsolete hardware platforms
• Replace custom software components with more
  standard parts
• Add new functionality
• Change basic system architecture

14
Goals of Reengineering (3)

• Integrate disconnected but functionally related
  applications into a suite
• Convert source code programming languages
• Reuse legacy components on another specific
  project
• Populate a generic reuse library with legacy
  components
• Restructure and rationalize data files

15
Reengineering and Legacy Software

• Goal is to evolve the legacy software from
  current state to evolutionary software
• Evolvability
• A measure of the ease with which a system can
  evolve from its current (legacy) state to its
  future (desired) state

16
Evolvability Attributes

• Technical efficiency
• What is the quality of the current system?
• Functional effectiveness
• How well does the current system satisfy business
  requirements?
• Infrastructure maturity
• Are the processes and tools in place to evolve
  the current system?

17
Techniques for Assessment

• Metrics-based
• Qualitative analysis of some aspect of system and
  its operation
• Scenario-based
• Quantitative and qualitative data on the
  operation of the system in typical use
• Expert-opinion based
• Informal guidelines and heuristics based on
  experiences of experts in using and evolving
  similar systems

18
Families of Systems

• If several legacy systems are to be reengineered
• Capture their similarities in a common reusable
  architecture
• Treating them as a family of systems rather than
  independent points

19
Characteristics of Code Calling for Reengineering

• Frequent failures
• Code gt 7 years old
• Overly complex program structure logic flow
• Very large modules

20
Characteristics of Code Calling for Reengineering
(2)

• Code written for previous generation of hardware
• Running in emulation mode
• Excessive resource requirements
• Difficulty in keeping maintainers
• Seriously deficient documentation

21
Process

• Identify candidates
• Reengineering plan
• System understanding
• Elicitation
• Capture
• Analysis
• System evolution
• To desired state

22
Existing system

• Significant scrutiny by users
• Long history of maintenance
• Stress-hardened code
• Wealth of test and validation capabilities
• Performance and accuracy have been fine-tuned

23
Desired System

• Portability
• Modularity
• Structure
• Readability
• Testability
• Data independence
• Documented system understanding

24
Evolution -- Plan

• New -- Big Bang
• Separate re-development
• Incremental -- phase out pieces
• Re-develop in parts and phase in
• Evolutionary -- phase in new features over time
• Reengineer legacy system in pieces, phase in over
  time

25
Risk Analysis

• Cost, time, and effort
• Maturity level of technology inserted into the
  system
• Ability to reduce or eliminate undesirable
  properties
• Impact of changes on performance and robustness
• Impact of deployment of the reengineered system

26
Reengineering Problem Solving
System Understanding
Plan
Current System
Desired System
Feasibility Study
Implement/Monitor
Analyze
Design
27
Software Reengineering
Image from Software Engineering for Evolution,
Yang and Ward
28
Software Reengineering

• Re-document
• Reverse engineer
• Translate source code
• Data reengineer
• Recode
• Redesign
• Respecify
• Restructure
• Retarget

29
Redocument

• The process of analyzing the system to produce
  support documentation in various forms including
  users manuals and reformatting the system's
  source code listings

30
Reverse Engineer

• The engineering process of understanding,
  analyzing, and abstracting the system to a new
  form at a higher abstraction level

31
Translate Source Code

• Transformation of source code from one language
  to another or from one version of a language to
  another version of the same language (e.g., going
  from COBOL-74 to COBOL-85 or from CMS-2 to Ada)

32
Data Reengineering

• Transformation of data from one format to another
  format (e.g., going from flat-file to relational
  database format)

33
Reimplement (or recode)

• Changes the characteristics of the source code.
  May involving translation from one language to
  another or changes in control or data flow.
  Quality changes may also occur such as enhancing
  readability, meeting code standards, etc.

34
Redesign

• Changing the characteristics of the design.
  Possible changes include restructuring a design
  architecture, altering a system's data model as
  incorporated in data structures or in a database,
  and improving an algorithm.

35
Respecify

• Changing the characteristics of the requirements.
  Ranges from changing the form of the requirements
  to adding, deleting or altering requirements.

36
Restructuring

• The engineering process of transforming the
  existing system from one representation form to
  another at the same relative abstraction level,
  while preserving the subject system's external
  functional behavior

Requirements
Design
Source Code
Behavior
37
Retargeting

• The engineering process of transforming,
  rehosting, or porting the existing system in a
  new configuration

38
Approaches
Abstract System
Components
Middleware
Semi-automatic
Automatic
39
Reengineering Approaches (1)

• Automatic restructuring
• Automatic transformation
• Semi-automatic transformation
• Design recover and reimplementation
• Code reverse engineering and forward engineering
• Data reverse engineering and schema migration
• Migration of legacy systems to modern platforms

40
Reengineering Approaches (2)

• Automatic restructuring
• Done to generate more readable source code
• Apply code standards after the fact
• Automatic transformation
• Generate better source code
• Clarify control flow, simplify
• Refactor and remodularize
• Others

41
Reengineering Approaches (3)

• Semi-automatic transformation
• Re-architect code and data
• Built from abstract system (models)
• Semi-automatic generation of new structural,
  functional and behavioral abstraction
• Then create new system from these abstractions

42
Reengineering Process Framework

• Issue assessment
• Decision analysis
• Solution development
• System transition
• Effort evaluation

43
Issue Assessment

• Establish the scope and direction of effort
• Develop a preliminary plan
• Determine desired quality improvements
• Perform risk assessment

44
Issue Assessment (2)

• Perform inventory and analysis of legacy system
• Gain a level of understanding of systems
• Architecture, design, operational characteristics
  and functionality
• Formulate candidate strategies
• Determine reengineering is most viable and
  effective option

45
The Reengineering Decision
Risk
Time
To reengineer or not?
Cost
Benefits
46
Decision Analysis

• Outcome-- decision whether to
• Reengineer
• Initiate new development
• Continue maintenance
• Account for all technical, economic,
  programmatic, and political issues

47
Decision Analysis (2)

• Prepare plan
• Tasks to be performed
• Schedule
• Risk assessment
• Resources required
• Milestones and funding
• Itemization of products

48
Decision Analysis (3)

• Choose a strategy
• Least risk
• Shortest implementation schedule
• Minimal transition problems
• Greatest upward compatibility
• Maximum usage of existing resources
• Increased customer acceptance

49
Solution Development

• Formally elicit and validate the detailed
  requirements for the reengineered system
• Reverse engineering
• Obtaining an in-depth understanding of the system
• Recovery of artifacts
• Adapt and use in the reengineered system
• Forward engineering

50
System Transition

• Focuses on deployment into operational
  environment
• Include trial deployment
• Site preparation
• System installation and checkout
• Training

51
Effort Evaluation

• Process improvement
• Meet schedule?
• Collect and evaluate metrics

52
Reengineering Technical Assessment (RTA)

• SOFTWARE REENGINEERING
• ASSESSMENT HANDBOOK
• Version 3.0
• Available on website

53
RTA

• Match existing software with appropriate
  reengineering strategy or maintenance strategy
• Technical aspects of software
• Aid in management's reengineering decisions

54
RTA -- Steps

• Assess organizations level of preparation
• Minimum criteria an organization should meet
• Identify and list those software components
  perceived as a problem or having significant
  improvement potential
• Age, complexity, language, reliability, expense
  of maintenance, documentation, importance to user

55
RTA -- Steps (2)

• Reduce list -- remove if
• Remaining life is lt 3 years
• Not important
• Developed less 5 years ago
• Business process it supports is being
  reengineered
• Complete RTA questions regarding
• Redocument, translate, data reengineer, retarget,
  restructure

56
RTA -- Steps (3)

• Consider other strategies
• Reverse engineering
• Use resulting design information for long term
  maintenance
• Redevelopment
• Candidate not worth salvaging
• 3 or more reengineering strategies are indicated
  and life span is gt 5 years
• Status quo

57
RTA -- Steps (4)

• Compare reengineering needs across different
  components
• Management decision aid
• Combine technical assessment with cost data
• Maintenance environment
• Assess current maintenance environment

58
A Reengineering Project

• Utility Company
• Solve Y2K bought new computer systems
• Integrates billing and meter readings
• Must use existing data
• Original data within COBOL file system
• Extraction must be done in COBOL

59
A Reengineering Project (2)

• Process
• Reverse engineer
• Design information
• Data dictionary, data structure diagrams
• Data flow diagram
• System understanding of new product
• Design information
• Data dictionary
• Data usage
• Design and implement extraction reformating
  programs

60
Portability

• WVU Software Portability Group
• A software unit is portable (exhibits
  portability) across a class of environments to
  the degree that the cost to transport and adapt
  it to a new environment in the class is less than
  the cost of redevelopment

61
Portability (2)

• Extends software value
• Extends its useful life
• Expands the range of installations which can be
  used
• Most software packages will at some point need to
  be ported in order to maintain and expand their
  usefulness

62
What can be Ported?

• Software Units
• Data
• Libraries
• Tools
• Documentation

63
Phases of Porting

• Transportation
• Physically move software to new environment
• Adaptation
• Modify source to suit the requirements of new
  environment
• Translate modified source to executable
• Test and debug the ported software
• Once installed enters a normal lifecycle

64
Porting Existing Software

• Should it be ported or redeveloped?
• Reverse engineering
• Improving portability

65
Costs/Benefits of Porting

• Source code must be available
• Testing and debugging will be lessened
• Only a small segment of code will be modified
• Documentation should be similar so cost should be
  lessened
• Maintenance easier -- shared modules
• Can not improve portability or optimize structure
  for target environment

66
Maintenance of Ported Implementations

• Fewer elements differ -- easier
• Single versions of common parts
• Common changes must be easily propagated to
  appropriate implementations
• All documentation must be updated

67
Standards and Portability

• Following standards should increase portability
• COBOL standards
• Do not promote portability
• 5 year life span
• Successive versions are not necessarily supersets