From the course: Migrating COBOL Apps

Lehman's laws of software evolution - COBOL Tutorial

From the course: Migrating COBOL Apps

Start my 1-month free trial

Lehman's laws of software evolution

“

- [Instructor] The Waterfall Model of software engineering was one of the earliest formal approaches to the software lifecycle and was introduced in 1970. The basic concept with this model is that there is a fixed business requirement, which can be specified and coded. And this will then operate with the maintenance phase being limited to correcting mistakes made in the original design or implementation. As software became a key part of business processes, it became apparent that software applications needed to evolve to meet changing business requirements. In 1980, Meir Lehman published his paper on the Laws of Software Evolution, which set five laws. Continuing change, the idea that an application must be continually updated or it becomes progressively less fit for purpose. Increasingly complexity. As an application evolves, its complexity increases and less effort is invested to maintain or reduce it. Fundamental law. This law states that from observations, the evolution of software has statistically determinable trends. Organizational stability. The activity rate in an evolving application is constant over the application's lifetime. And conservation of familiarity. As an application evolves, all associated with it, developers, sales personnel and users must maintain mastery of its content and behavior if it's to continue to be fit for purpose. What we can take out of this is that legacy applications will typically continue to evolve over time. And in doing so, become more and more complex. If there hasn't been investment, not just in achieving the baseline changes but also in redesign and recoding to manage complexity, then the legacy application will become highly complex to understand and to migrate. Associated with this is the concept of application aging. In this context, a legacy system is said to have aged when its quality has decayed. The decay is exhibited with the following symptoms. Pollution of the business need. Where the system includes many components, which don't exist to achieve current business functions. Embedded knowledge, where knowledge of the application domain and its evolution is not in the documentation and must be gleaned by analyzing the program code. Poor lexicon, where variable function and module names have little meaning or are inconsistent with their functionality. Coupling, where the program components are linked by extensive data or control flows. And merged architectures, where the architectural integrity of the application as a whole has been lost when several different solutions have been merged or superimposed across each other during many maintenance activities. These issues can be measured and the combined measurements provide guidance to the effort involved in migration and the priority for migration.

Contents