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 –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