COMP 3521 chapter 9

Software Evolution

• Software evolution encompasses the processes involved in modifying software after its initial deployment.
• Software evolution includes evolution processes, software maintenance, and legacy systems.

Inevitability of Software Change

• Software change is unavoidable due to evolving requirements during use.
• Software change is also needed because the business environment changes over time.
• Errors must be fixed.
• New tech will be added.
• System improvements and reliability updates.
• Managing change to systems presents a key problem for organizations.

Importance of Software Evolution

• Organizations possess large stakes in their software systems, making them critical assets.
• Changes and updates are essential to preserve the value of these assets.
• Most of the software budget in large companies is allocated to evolving existing software instead of creating new ones.

Development and Evolution Spiral Model

• Specification outlines what the system should do.
• Implementation creates the code for the system.
• Validation checks if the system meets the specified requirements.
• Operation is the phase where the system is used and maintained.
• Releases are the different versions of the system.

Evolution and Servicing

• Software development involves the initial creation of the software.
• Software evolution involves adaptations and modifications after deployment.
• Software servicing involves bug fixes and environmental changes.
• Software retirement is when that software is no longer supported.

Evolution

• Evolution is the stage where the system is in operational use, and new requirements are implemented.

Servicing

• Servicing is where the software remains useful with bug fixes and changes to reflect environmental updates without adding new functionality.

Phase-Out

• Phase-out: Software may still be used but receives no further modifications.

Evolution Process Dependencies

• Maintainence depends on software type, development processes, and skills/experience of involved personnel.
• Change proposals require links to affected components for cost and impact estimation.
• Throughout the system's lifetime, change identification and evolution are ongoing.

The Software Evolution Process

• Change requests represent the start of the software evolution process.
• Impact analysis assesses the effect of the requested changes.
• Release planning organizes and schedules the implementation of changes.
• Change implementation involves modifying the software, entailing either bug fixes, platform adaptation, or system enhancement.
• System release delivers the updated software version.

Change Implementation Details

• Change implementation iterates the development process with design, implementation, and testing of system revisions.
• Program understanding may be needed during the initial phase if new developers are implementing the changes.
• Program understanding involves deciphering program structure, functionality, and potential impacts of proposed changes.

Handling Urgent Change Requests

• Software engineering processes may be bypassed when implementing urgent changes.
• These changes may include fixing a serious system halt, managing impacts of upgrades to the system environment, or providing rapid reactions to business changes.

The Emergency Repair Process

• Change requests initiate the emergency repair process.
• Source code analysis identifies the location of changes.
• Changes are made to the code.
• The changed system is delivered.

Adapting Agile Methods

• Transitioning from development to evolution should be seamless because Agile methods are rooted in incremental development.
• Evolution extends the initial development with regular system releases.
• Automated regression testing proves useful when system modifications are implemented.
• Changes can be specified as additional user stories in project management.

Handover Problems: Development vs Evolution

• Agile development teams pass work to evolution teams preferring plan-based approaches, detailed documentation may be expected.
• Plan-based development teams pass work to evolution teams preferring agile, automated tests may need to be started from scratch.

Understanding Legacy Systems

• Legacy systems are older, relying on outdated languages and tech, and are no longer used for new development.
• Legacy software depends on older hardware, like mainframe computers, and has associated outdated processes.
• Legacy systems consist of hardware, software, libraries, business processes, and other software.

Elements of Legacy Systems

• Application software often at the core with business logic.
• Support software assists application software.
• System hardware that runs all software components.
• Application data processes the application.
• Business processes are workflows the system automates, constrained by the system's capabilities.
• Business policies and rules dictate how the business is run, embedding the application system.

Legacy System Components - Hardware

• System hardware may have been written for hardware that is no longer available.

Legacy System Components - Support Software

• The legacy system may rely on a range of support software that may be obsolete or unsupported.

Legacy System Components - Applications

• Application software provides the business services and comprises numerous programs.

Legacy System Components - Application Data

• Application data are processed by the application system and are inconsistent, duplicated, or held in different databases.

Legacy System Components - Business Processes

• Business processes are the processes used in the business to achieve some business objective.

Legacy System Components - Business Policies

• Business policies and rules define how the business should be carried out and constraints on the business, with the use of the legacy application system.

Legacy System Layers

• Hardware provides the physical base.
• Platform and infrastructure software such as the operating system and databases sit on top of the hardware.
• Application software runs on platform.
• Business processes which operate on that software.

Difficulties with Replacement

• Business usually continues to use legacy systems, as replacement introduces costs and risks.
• The system replacement introduces risks such as a lack of complete system specifications.
• The replacement may cause tight integration of the system and business processes.
• The replacement may cause undocumented business rules embedded in the legacy system.
• The replacement may result in new software development being late and/or over budget.

The Expense of Changing Legacy Systems

• Inconsistencies and obsolete languages exist.
• Documentation is commonly inadequate.
• Degradation of System Structure and confusing optimizations of code, errors and duplications.

Managing Legacy Systems

• Organizations must choose a strategy for evolving the systems.
• These strategies include scrapping the system, continuing the system, transforming the system, or creating a new system.
• The choice depends on system quality and business value.

Legacy System Categories

• Low quality and business value: Scrap.
• Low quality, high business value: Reengineer or replace.
• High quality, low business value: Replace with COTS or maintain.
• High quality, high business value: Maintain.

Business Value Assessment, Stakeholders, and Issues

• Assessments should take viewpoints of system end-users, customers, managers.
• Stakeholders should be interviewed and results are collated.
• Dependability and outputs affect value.
• Business processes may lower value.

Analysis of System Quality

• Business process assessment determines support for current business goals.
• Environment assessment measures environment effectiveness and cost of maintenance.
• Application Assessment gauges application software system quality.

Business Assessment Elements and Example

• Stakeholder viewpoints should be used to define process models.
• Different organizational parts may user different processes to perform the same function.
• Business processes could be adapted, or is effectively supported by legacy applications.
• A travel ordering system may have a low business value because of the widespread use of web-based ordering.

Considerations for Environmental Factors

• Consider supplier stability (is it still in business).
• Consider failure rate, age, and performance.

Support Requirements: Questions on Support

• Support requirements questions for hardware and software (consider system replacement based on support costs)?

Maintenance Costs: Questions on Support Contracts and Licences

• What are the costs of hardware maintenance and support software licences?

Interoperability: Question on Compilers

• Is hardware emulation required and are there problems connecting the system to the others?

Measuring Attributes and Performance

• Consider source code understandability and complexity.
• Evaluation include system documentation, data attributes, data, and data consistency.
• Appraise overall system performance.

Programming language and test and configurations considerations

• What are modern languages used to develop this system and is it still in use.
• Check for all versions of system parts are managed.
• Test data should exist for systems: Regression tests performed on features added.

Personnel: Considerations

• Personnel available who have skills to maintain/ use the software.

Quantifying System Quality

• Accumulate Data on System Change and the number of user interfaces.
• The volume of data is the key to making assessments of the data-processing.
• Cleaning is costly.

Defining Software Maintenance

• Maintenance modifies a program after use, focused on custom software; it rarely introduces architecture changes.
• System modifications and integration can be implemented in phases.

Categories of Maintenance

• Fault repairs are used to fix defects and bugs.
• Software is updated to different operating environments, is referred to environmental adaptation, and may operate in different environments from the initial implementation.
• Changes to a system can include additions and modifications.

Effort Distribution of Maintenance

• Functionality addition or modification (58%).
• Fixing faults(24%).
• Adjusting to new environments (19%).

Defining factors of Maintenance Costs

• Costs are higher for maintenance, and maintenance can be higher depending on the application.
• Factors also technical ones and non technical.
• Expenses rise and corrupt the software, and maintainence makes it difficult.
• Support costs are high (compilers, languages,etc).

Expense: Development vs Modifications

• It's normally more expensive to add to maintenance rather than in a system under development.
• New Teams and developers are needed to work on maintainable software.
• Maintenance staff who are often inexperienced, and their structures often age.

Defining Maintenance Prediction

• Prediction looks at which systems may have problems and high costs.
• Implementation changes degrade systems and maintenance depends on maintaining the maintainability.

Prediction Elements

• Maintainability is predicted by system changes, maintenance costs, and the parts affected by change.

Change Prediction

• Understanding changes requires a system, its environment.
• System coupled with changes whenever environment ones are adapted.
• Changing can depend on volatility (requirements), complexity (interfaces), and processes.

Defining Complexity metrics

• Predictions focus on complexity of control and data, and the sizes of object, procedure, and module.

Process indicators

• Can measure to maintain the number of requests, average time, and requests outstanding.
• Maintainability decreases if indicators increase.

Software Re-engineering

• Code is rewritten or restructured in legacy systems without functionality changes.
• This is mainly used when frequent maintenance is needed.
• Re-engineering includes adding effort.

Reduced Risk

• There is risk with software development because there may be problems, specifications and staffing.

Reduced Cost

• Re-engineering is less expensive than software development.

Process of Re-engineering

• Original Program: Initial code slated for re-engineering.
• Reverse Engineering: Analyze code to understand structure and logic.
• Program Documentation: Create documentation to aid understanding and future maintenance.
• Source Code Translation: Convert code to a new language for modern development.
• Program Modularization: Divide program into manageable modules.
• Program Structure Improvement: Restructure Code for understandability.
• Restructure Program: Improve internal code organization with changes.
• Result: Re-engineered program + re-engineered data.

The Activities of Re-engineering

• Convert Code to a specific Language (Source language translation), Reverse it to read the original components
• Restructure to enhance understandability and reorganize code.
• Clean and organize the structural system.

Approaches to Re-engineering

• Automated code restructuring can be automated.
• Code Conversion should be automated but manual too.
• Code enhancements will be integrated to reduce costs.

Factors for cost

• The tool support available, data conversion, and expert staff are important for reducing the costs.

Refactoring

• Improvement is to reduce degradation with change, and reduced problems will result.
• Altering improves maintainance, and complexity improvements.
• Concentrate on functionality not enhancement.

Re-engineering and Refactoring Summary

• Automation can be used, but it involves legacy software to create maintainable ones.
• Refactoring is improving and code degradation can prevent the maintaininability.

Bad Code Examples

• Similar code is placed in different programs to be implemented as a function.
• If a function is to long, re design into methods.

Polymorphism for code statements

• Those that depend of value switch should be polymorphic to reduce duplication.

“Bad Smells” Cont. - Clumps & Neglect

• Similar items in classes can be encapsulated, and generalization might not be used and should be removed.

Key Points on Evolution:

• Evolution and development are integrated iterations, and maintenance out costs development.
• Change-driven software evolution involves change impact analysis, release planning, and implementation, with old software remaining in use due to its business benefits.

Key Points on Evolution and Legacies:

• Legacy application assessments, transformations and maintainability are cheaper than completely starting again.
• Software maintenance can be a mix of fixing bugs, adapting it, and implementing them.

Improving software:

• Softwares need to be re-organized to be modified and improved.
• Changing codes that maintains performance is a important maintainance role.