Lehman's laws of software evolution

Last updated

In software engineering, the laws of software evolution refer to a series of laws that Lehman and Belady formulated starting in 1974 with respect to software evolution. [1] [2] The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand. Over the past decades the laws have been revised and extended several times. [3]

Contents

Context

Observing that most software is subject to change in the course of its existence, the authors set out to determine laws that these changes will typically obey, or must obey for the software to survive. [1]

In his 1980 article, [1] Lehman qualified the application of such laws by distinguishing between three categories of software:

The laws are said to apply only to the last category of systems.

The laws

All told, eight laws were formulated:

  1. (1974) "Continuing Change" — an E-type system must be continually adapted or it becomes progressively less satisfactory. [4]
  2. (1974) "Increasing Complexity" — as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it. [4]
  3. (1974) "Self Regulation" — E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal. [4]
  4. (1978) "Conservation of Organisational Stability (invariant work rate)" — the average effective global activity rate in an evolving E-type system is invariant over the product's lifetime. [4]
  5. (1978) "Conservation of Familiarity" — as an E-type system evolves, all associated with it, developers, sales personnel and users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves. [4]
  6. (1991) "Continuing Growth" — the functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime.
  7. (1996) "Declining Quality" — the quality of an E-type system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes. [5]
  8. (1996) "Feedback System" (first stated 1974, formalised as law 1996) — E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

Relevance of the Laws of Software Evolution in Modern Software Engineering

In the dynamic world of modern software engineering, the Laws of Software Evolution continue to hold a profound relevance. These laws, originally formulated by Lehman and Belady in the 1970s, provide enduring insights into the nature of software systems and their evolution. In today's software development landscape, where agility and adaptability are paramount, these laws serve as guiding principles.

"Continuing Change" is a foundational concept, emphasizing that software must evolve continually to remain satisfactory. [4] This aligns perfectly with agile development methodologies, where iterative updates and feature enhancements are the norm.

"Increasing Complexity" is another key law that underscores the need for active management of complexity, particularly in large and long-lived software projects. [4] As software systems grow, modern engineering practices such as modular design, microservices, and DevOps help control and reduce complexity, ensuring that software remains maintainable and scalable.

The Laws of Software Evolution also find relevance in the context of DevOps and continuous integration/continuous deployment (CI/CD). In a DevOps-driven environment, the "Continuing Growth" law [4] is exemplified as software features must be continually expanded to meet evolving user demands and maintain user satisfaction.

The "Declining Quality" law is a stark reminder that software quality can deteriorate over time without rigorous maintenance, [4] highlighting the importance of automated testing and quality assurance in modern software development. Furthermore, the "Feedback System" law [4] reinforces the idea that software evolution is a feedback-driven process, with multiple loops and agents involved.

This resonates with the emphasis on collaboration and feedback within DevOps practices, ensuring that software is developed, tested, and deployed with a focus on continuous improvement. In summary, the Laws of Software Evolution continue to guide software engineers in navigating the complexities of modern development, from agile methodologies to DevOps, helping them deliver robust, evolving software systems.


Related Research Articles

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to:

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.

In the context of software engineering, software quality refers to two related but distinct notions:

Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is intended to ultimately improve the quality and functionality of a design. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.

Software evolution is the continual development of a piece of software after its initial release to address changing stakeholder and/or market requirements. Software evolution is important because organizations invest large amounts of money in their software and are completely dependent on this software. Software evolution helps software adapt to changing businesses requirements, fix defects, and integrate with other changing systems in a software system environment.

Azure DevOps Server is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.

In software development, or any other IT field technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

<span class="mw-page-title-main">Manny Lehman (computer scientist)</span> Known for Lehmans laws of software evolution

Meir "Manny" Lehman, FREng was a professor in the School of Computing Science at Middlesex University. From 1972 to 2002 he was a Professor and Head of the Computing Department at Imperial College London. His research contributions include the early realisation of the software evolution phenomenon and the eponymous Lehman's laws of software evolution.

Business agility refers to rapid, continuous, and systematic evolutionary adaptation and entrepreneurial innovation directed at gaining and maintaining competitive advantage. Business agility can be sustained by maintaining and adapting the goods and services offered to meet with customer demands, adjusting to the marketplace changes in a business environment, and taking advantage of available human resources.

Software entropy is the idea that software eventually rots as it is changed if sufficient care is not taken to maintain coherence with product design and established design principles. The common usage is only tangentially related to entropy as defined in classical thermodynamics and statistical physics.

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer. API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, following a pipeline through a "production-like environment", without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

<span class="mw-page-title-main">Parasoft C/C++test</span> Integrated set of tools

Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.

Performance management work (PMW) describes all activities that are necessary to ensure that performance requirements of application systems (AS) can be met. Therefore, PMW integrates software performance engineering (SPE) and application performance management (APM) activities. SPE and APM are part of different lifecycle phases of an AS, namely systems development and IT operations. PMW supports a comprehensive coordination of all SPE and APM activities, which is inevitable due to an increased complexity of AS architectures.

In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is that teams can develop and deploy their services independently of others. This is achieved by the reduction of several dependencies in the code base, allowing developers to evolve their services with limited restrictions from users, and for additional complexity to be hidden from users. As a consequence, organizations are able to develop software with fast growth and size, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API. One technique that is used is having multiple interfaces on the same service, or multiple versions of the same service, so as to not disrupt existing users of the code.

<span class="mw-page-title-main">DevOps toolchain</span> DevOps toolchain release package.

A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.

TestOps refers to the discipline of managing the operational aspects of testing within the software delivery lifecycle.

References

  1. 1 2 3 Lehman, Meir M. (1980). "Programs, Life Cycles, and Laws of Software Evolution". Proc. IEEE. 68 (9): 1060–1076. doi:10.1109/proc.1980.11805.
  2. ↑ Lehman, M. M.; J. F. Ramil; P. D. Wernick; D. E. Perry; W. M. Turski (1997). "Metrics and laws of software evolution—the nineties view" (PDF). Proc. 4th International Software Metrics Symposium (METRICS '97). pp. 20–32. doi:10.1109/METRIC.1997.637156.
  3. ↑ Herraiz, Israel; Rodriguez, Daniel; Robles, Gregorio; Gonzalez-Barahona, Jesus M. (2013). "The evolution of the laws of software evolution". ACM Computing Surveys. 46 (2): 1–28. doi:10.1145/2543581.2543595. ISSN   0360-0300.
  4. 1 2 3 4 5 6 7 8 9 10 Lehman, M. M. (1980). "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". Journal of Systems and Software. 1: 213–221. doi:10.1016/0164-1212(79)90022-0.
  5. ↑ Liguo Yu and Alok Mishra (2013) An Empirical Study of Lehman’s Law on Software Quality Evolution in International Journal of Software and Informatics, 11/2013; 7(3):469-481.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.