SENG 540 Software Evolution - PowerPoint PPT Presentation

1 / 67
About This Presentation
Title:

SENG 540 Software Evolution

Description:

Recode. Redesign. Respecify. Restructure. Retarget. SENG 540 Lecture 5. 29. Redocument ... Reimplement (or recode) Changes the characteristics of the source code. ... – PowerPoint PPT presentation

Number of Views:134
Avg rating:3.0/5.0
Slides: 68
Provided by: elearnC
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com