Software Evolution - csactor

Breaking

csactor

computer science , software engineering ,information system and information technology lesson series like data structure and algorithm , computer networking , programming , database , web development , operating system , information system , digital marketing and business study.

Saturday, August 18, 2018

Software Evolution



Software Evolution

Importance of 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 and servicing

 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