Software Evolution
Organizations have huge investments in their software systems - they are critical business assets.
To maintain the value of these assets to the business, they must be changed and updated.
The majority of the software budget in large companies is devoted to changing and evolving existing software rather than developing new software.
Evolution
The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.
Servicing
At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added.
Phase-out
The software may still be used but no further changes are made to it.
Evolution processes
Software evolution processes depend on
The type of software being maintained;
The development processes used;
The skills and experience of the people involved.
Proposals for change are the driver for system evolution.
Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated.
Change identification and evolution continues throughout the system lifetime.
Change identification and evolution processes
The software evolution process
Change implementation
Iteration of the development process where the revisions to the system are designed, implemented and tested.
A critical difference is that the first stage of change implementation may involve program understanding, especially if the original system developers are not responsible for the change implementation.
The emergency repair process
Agile methods and evolution
Agile methods are based on incremental development so the transition from development to evolution is a seamless one.
Evolution is simply a continuation of the development process based on frequent system releases.
Automated regression testing is particularly valuable when changes are made to a system.
Changes may be expressed as additional user stories.
Legacy systems
Legacy systems are older systems that rely on languages and technology that are no longer used for new systems development.
Legacy software may be dependent on older hardware, such as mainframe computers and may have associated legacy processes and procedures.
The elements of a legacy system
Legacy system components
System hardware Legacy systems may have been written for hardware that is no longer available.
Support software The legacy system may rely on a range of support software, which may be obsolete or unsupported.
Application software The application system that provides the business services is usually made up of a number of application programs.
Application data These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases.
Business processes These are processes that are used in the business to achieve some business objective.
Business processes may be designed around a legacy system and constrained by the functionality that it provides.
Business policies and rules These are definitions of how the business should be carried out and constraints on the business. Use of the legacy application system may be embedded in these policies and rules.
An example of a legacy system assessment
Legacy system categories
Low quality, low business value
These systems should be scrapped.
Low-quality, high-business value
These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available.
High-quality, low-business value
Replace with COTS, scrap completely or maintain.
High-quality, high business value
Continue in operation using normal system maintenance.
Business value assessment
Assessment should take different viewpoints into account
System end-users;
Business customers;
Line managers;
IT managers;
Senior managers.
Interview different stakeholders and collate results.
Issues in business value assessment
The use of the system
If systems are only used occasionally or by a small number of people, they may have a low business value.
The business processes that are supported
A system may have a low business value if it forces the use of inefficient business processes.
System dependability
If a system is not dependable and the problems directly affect business customers, the system has a low business value.
The system outputs
If the business depends on system outputs, then the system has a high business value.
No comments:
Post a Comment