Manag ing software change
Download
1 / 28

Manag ing Software Change - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on
  • Presentation posted in: General

Manag ing Software Change. CIS 376 Bruce R. Maxim UM-Dearborn. Software Change. Software change is inevitable New requirements emerge as software is used Business environment may change Errors need to be repaired New equipment needs to be accommodated

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

Manag ing Software Change

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Managing Software Change

CIS 376

Bruce R. Maxim

UM-Dearborn


Software Change

  • Software change is inevitable

    • New requirements emerge as software is used

    • Business environment may change

    • Errors need to be repaired

    • New equipment needs to be accommodated

    • May need to improve performance or reliability

  • A key problem for companies is implementing and managing change to their legacy systems


Software Change Strategies

  • Software Maintenance

    • Changes are made in response to changed requirements but the functional software structure is sound

  • Architectural Transformation

    • System may be modified from mainframe to distributed architecture

  • Software Re-engineering

    • Software restructured to facilitate future changes, no new functionality is added


Program Evolution Dynamics – part 1

  • The study of the processes of system change

  • Lehman and Bundy proposed several observations after studying changes made to large systems

  • Continuing Change

    • A program used in the real-world must change or become progressively less useful in that environment.

  • Increasing Complexity

    • As an evolving program changes, its structure becomes more complex and extra resources must be devoted to preserving and simplifying the structure.


Program Evolution Dynamics – part 2

  • Large Program Evolution

    • Program evolution is a self-regulating process. Some attributes (e.g. size, time between releases, # reported errors) are invariant for each system release.

  • Organizational Stability

    • Over a program’s lifetime its rate of development is approximately constant and independent of the resources devoted to system development.

  • Conservation of Familiarity

    • Over the lifetime of a system, the incremental change in each release is approximately constant.


Applicability of Lehman’s Laws

  • They seem to apply to large custom made systems developed by large organizations

  • It is not clear how they need to be modified for

    • Shrink-wrapped software products

    • Systems containing several COTS components

    • Small organizations

    • Medium sized systems


Maintenance is Inevitable

  • System requirements are likely to change while the system is being developed because their environment is changing

  • Systems are tightly coupled to their environment

  • When a system is installed it changes the environment and that can change the system requirements

  • The delivered system may not meet its requirements

  • Systems must be maintained to remain useful in their environment


Types of Maintenance

  • Corrective Maintenance (21%)

    • making changes to repair defects

  • Adaptive Maintenance (25%)

    • making changes to adapt software to a different environment (hardware, business rules, OS, etc.)

  • Perfective Maintenance (50%)

    • modifying system to meet new client requirements

  • Preventative Maintenance (4%)

    • eliminating potential problems before they appear


Spiral Maintenance Model


Maintenance Costs

  • Usually greater than the development costs (2 to 10 times as much in some cases)

  • Affected by both technical and non-technical factors

  • Increase as software is maintained and system corruption is introduced

  • Aging software can have high support costs (e.g. old languages, compilers, etc.)


Maintenance Cost Factors

  • Staff turnover

    • no turnover usually means lower maintenance costs

  • Contractual responsibility

    • developers may have no contractual obligation to maintain the delivered system and no incentive to design for future change

  • Staff skills

    • maintenance staff are often inexperienced and have limited domain knowledge

  • Program age and structure

    • as programs age their structure deteriorates, they become harder to understand and change


Maintenance Process


Change Requests

  • Requests can come from users, customers, or management

  • Change requests should be carefully analyzed as part of the maintenance process before they are implemented

  • Some changes requests must be implemented urgently due to their nature

    • fault repair

    • system environment changes

    • urgently required business changes


Maintenance Prediction

  • Concerned with determining which parts of the system may cause problems and have high maintenance costs

  • Change acceptance depends on the maintainability of the components affected by the change

  • Implementing changes degrade system and reduces its maintainability

  • Maintenance costs depends on number of changes

  • Costs of change depend on maintainability


Maintenance Prediction


Change Prediction

  • Predicting the number of changes requires understanding the relationships between a system and its environment

  • Tightly coupled systems require changes whenever the environment changes

  • Factors influencing the system/environment relationship

    • number and complexity of system interfaces

    • number and volatility of system requirements

    • business processes where the system is used


Maintenance Complexity Metrics

  • Predictions of maintainability can be made by assessing component complexities

  • Most maintenance efforts only affect a small number of system components

  • Maintenance complexity depends on

    • complexity of control structures

    • complexity of data structures

    • module size


Maintenance Process Metrics

  • Maintainability measurements

    • number of requests for corrective maintenance

    • average time required for impact analysis

    • average time to implement a change request

    • number of outstanding change requests

  • If any if these increases it may signal a decline in maintainability


Architectural Evolution

  • Concerned with the need to covert legacy mainframe systems to client-server architectures

  • Change drivers

    • hardware costs (servers are cheaper than main frames)

    • user interface expectations (users expect GUI’s)

    • distributed system access (users want to use the system from geographically separated computers)


Factors Influencing System Distribution Decisions

  • Business importance

    • if distribution provides more efficient support for stable business processes then it is more likely to be cost-effective

  • System age

    • the older the system the harder it will be to modify its architecture due to degradation introduced by previous changes

  • System structure

    • the more modular the system the easier it will be to change the architecture

  • Hardware procurement policies

    • distribution may be necessary if mainframes are not replaced


Layered Distribution Model

  • Presentation Layer

    • concerned with display and organization of end-user screens

  • Data Validation Layer

    • concerned with validity of data input by user and output to user

  • Interaction Layer

    • concerned with managing sequence of end-user operations and sequence of screens presented to end-user

  • Application Services Layer

    • concerned with basic computations provide by the aplication

  • Database layer


Legacy System Distribution


Distribution Options

  • The more that is distributed from server to the client the higher the cost of evolution

  • The simplest distribution model is UI distribution where only the user interface is implemented on the client machine

  • The most complex distribution option is where the server simply provides data management and application services are implemented on the client


Distribution Option Spectrum


UI Distribution

  • Takes advantage of the local processing power found on the user’s workstation

  • The legacy system can be modified to distribute the user interface only when there is a clear separation between the user interface and application

  • If the separation is not clear, then screen management middleware can be used to translate text interfaces to GUI’s


User Interface Distribution


UI Migration Strategies - part 1

  • Implementation using the workstation window management system

    • advantage

      • have unrestricted access to all UI functions

    • disadvantage

      • platform dependent

      • may be harder to achieve interface consistency


UI Migration Strategies - part 2

  • Implementation using a web browser

    • advantage

      • platform independent

      • lower training costs

      • easier to achieve interface consistency

    • disadvantage

      • potentially poorer UI performance

      • interface design is constrained by browser capabilities


ad
  • Login