Software Engineering and Business Process

Extensive research across software engineering and business process management emphasizes that production systems must evolve in tandem with changing processes. Meir Lehman’s seminal Laws of Software Evolution assert that software becomes progressively less satisfactory unless continually adapted (the “Continuing Change” law) ¹. Business Process Management (BPM) scholarship further explores frameworks and tools for handling dynamic processes in information systems, highlighting the need for versioning, process mining, and continuous improvement cycles ². In parallel, agile and lean methodologies (e.g., the Agile Manifesto, Lean principles) prescribe iterative, rapid delivery to reduce the time between requirement identification and live deployment, thereby mitigating misalignment with emergent business needs ^3,4. Empirical studies on requirements volatility and deployment lag demonstrate that the longer the interval from elicitation to go-live, the higher the risk of software misfit, leading to cost overruns, delays, and defects⁵ NASA Technical Reports Server.

1. Software Evolution: Supporting Dynamic Processes

1.1 Lehman’s Laws of Software Evolution

Continuing Change: E-type systems (software embedded in real-world processes) must continually adapt or become obsolete Wikipedia ⁵. Increasing Complexity: Without active maintenance, evolving systems accrue complexity, hindering future adaptation⁵.

Feedback Systems: Evolution is governed by multi-level feedback loops, reinforcing the need for processes (and by extension software) that can respond rapidly to stakeholder input ⁶.

1.2 Implications for Process-Oriented Systems

Lehman’s observations imply that process-supporting software must be architected for constant evolution, with mechanisms for modular updates, plug-in business rules, and live analytics to detect process drift.

2. Business Process Management (BPM) and Dynamic Processes

2.1 Managing Dynamics in BPM

Contemporary BPM research defines dynamics along dimensions of determinateness (predictable vs. ad hoc changes) and context scope (process-internal vs. environmental) ⁷. A four-quadrant matrix guides organizations in selecting control strategies—from rigid, model-driven enactment to adaptive, real-time monitoring.

2.2 Process-Aware Information Systems

Process-aware information systems (PAIS) implement these strategies by integrating:

Versioning and Governance: Ensuring multiple process versions coexist during transitions.

Process Mining & Monitoring: Capturing execution logs to recommend timely software updates.

Simulation & Continuous Improvement: Embedding simulation engines (e.g., BPMN-based) to prototype process changes before deployment

ScienceDirect.

3. Agile and Lean: Reducing the Deployment Lag

3.1 Agile Manifesto Principles

The Agile Manifesto’s tenet “Responding to change over following a plan” directly addresses process volatility by favoring incremental delivery and continuous stakeholder collaboration⁸.

3.2 Lean Software Development

Lean principles—Deliver as fast as possible, Amplify learning, Optimize the whole—aim to eliminate waste such as waiting for long release cycles, thereby shortening the feedback loop between evolving process needs and software updates⁹.

4. Requirements Volatility and Risk of Deployment Lag

4.1 Nature of Requirements Volatility

Requirements volatility refers to the degree and frequency of changes to software requirements during development. Empirical evidence shows high volatility correlates with increased defect rates, cost overruns, and schedule slips¹⁰ .

4.2 High-Risk Interval: Elicitation to Go-Live

Time Lag Risk: Quantitative models demonstrate that the longer requirements sit unimplemented, the more they diverge from actual process needs¹⁰.

Bayesian Risk Assessment: Russell et al. employ Bayesian networks to predict volatility sources and inform risk mitigation, underscoring the value of early, iterative releases to capture evolving requirements ¹⁰.

System Dynamics Case Study: Dasgupta et al. simulate waterfall projects under various volatility patterns, finding that longer lead times amplify deviations from planned outcomes ¹⁰.

Architectural Impact: Even software architecture suffers: unanticipated requirement churn forces expensive refactoring if the deployment lag is too long ¹⁰.

5. Practical Recommendations

Adopt Continuous Delivery Pipelines: Automate build‐test‐deploy to shorten intervals between requirement sign‐off and production deployment ¹⁰.

Embed Feedback Loops: Use feature flags, canary releases, and real-time monitoring to adjust production software rapidly as processes change.

Govern Volatility with Metrics: Track requirements churn metrics (e.g., change frequency, impact) to set iteration cadences that balance stability with responsiveness¹⁰.

Align Software and Process Roadmaps: Synchronize business process improvement initiatives with software release planning to prevent misalignment.

Conclusion

A rich body of literature—from Lehman’s foundational laws to BPM frameworks, agile/lean practices, and empirical volatility studies—converges on the imperative that software must be treated as a living system, continuously evolving to reflect dynamic processes. Critically, minimizing the time from requirements identification to go-live reduces the risk of software obsolescence and ensures closer alignment with current business workflows.

References

1. Lehman, M. M. Programs, Life Cycles, and Laws of Software Evolution. Proc. IEEE.
2. Wikipedia: Lehman’s Laws of Software Evolution
3. Vom Brocke, J. & Rosemann, M. Managing Dynamics in and Around Business Processes. BIS Engineering.
4. Dasgupta, S. et al. Impact of Software Requirement Volatility Pattern on Project Dynamics. arXiv (2011).
5. Russell, M. S. Assessing Requirements Volatility and Risk using Bayesian Networks. NASA (2010).
6. Abrahamsson, P. et al. Agile Software Development Methods: Review and Analysis. arXiv (2017)
7. Beck, K. & Fowler, M. Manifesto for Agile Software Development. Agile Alliance (2001)
8. Poppendieck, M. & Poppendieck, T. Lean Software Development: An Agile Toolkit. Addison-Wesley (2003).
9. Russell, M. S. et al. Quantifying Requirements Volatility Effects. VU University (2007). Vrije Universiteit Amsterdam
10. Dasanayake, S. et al. Impact of Requirements Volatility on Software Architecture. arXiv (2019)