Module 8

Module 8: Software Evolution

           SOFTWARE MAINTENANCE

•Software is released to end-users, and

–within days, bug reports filter back to the software engineering organization.

–within weeks, one class of users indicates that the software must be changed so that it 

   can accommodate the special needs of their environment.

–within months, another corporate group who wanted nothing to do with the software 

   when it was released, now recognizes that it may provide them with unexpected 

   benefit. They’ll need a few enhancements to make it work in their world.

LEGACY APPLICATION SOFTWARE

- In IT, legacy applications and data are those that have been inherited from 

                      languages, platforms, and techniques earlier than current technology. 

- Typically, the challenge is to keep the legacy application running while converting it to 

  

   newer, more efficient code that makes use of new technology and programmer skills   

                  - Many organizations are migrating their legacy applications to new

                    programming languages  and operating systems that follow open or standard 

                    programming interfaces.

            SOFTWARE MAINTENANCE AND SUPPORT

1. Correcting defects

                                     2. Adapting application to a changing business environment

                3. Implementing enhancement at the request of stakeholders.

                      4. Supporting users as they integrate an application into their personal and business workflow

             MAINTENABLE SOFTWARE

•Maintainable software exhibits effective modularity

•It makes use of design patterns that allow ease of understanding. 

             SUPPORTABILITY SOFTWARE

•The software should contain facilities to assist support personnel when a defect is 

  encountered in the operational environment (and make no mistake, defects will be 

  encountered). 

LEHMAN'S LAW OF SOFTWARE EVOLUTION

A series of laws that Lehman and Belady formulated starting in 1974 with respect to

software evolution.

Lehman, M. M.; J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski (1997). "Metrics and laws of software evolution—the nineties view". Proc. 4th International Software Metrics Symposium (METRICS '97). pp. 20-32. doi:10.1109/METRIC.1997.637156. http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf.

WHO PERFORM MAINTENANCE?????

•Separate maintenance team

–May find it easier to distinguish how a software should work from how 

   it does work

•Part of development team

–May feel over-confident, and ignore the documentation to help 

   maintenance effort

           REENGINEERING

•To support ‘new business rules’, existing software may be modified or rebuilt 

  (reengineered).

•Reengineering may begin with a Business Process Reengineering (BPR) before move on 

  to software reengineering.

A MODEL FOR BPR

-with 6 activities :

         SOFTWARE REENGINEERING PROCESS MODEL

NURUL AIN BINTI MD HASHIM (IS086681)