Continuous simulation and the software development life cycle

“One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today’s civil engineers, while our craftsmanship will still be honored.”

—Andy Hunt (computer programmer, writer, one of the 17 original authors of Agile Manifesto, one of the founders of Agile Alliance, and co-author of “The Pragmatic Programmer: From Journeyman to Master” with Dave Thomas)

Software Development Life Cycle (SDLC) vs. Systems Development Life Cycle

The distinction between the Software Development Life Cycle (SDLC) and the System Development Life Cycle (also ambiguously referred to as SDLC) is often unclear. To clarify, we can trace the definitions of these terms back through time.

The standard ISO/IEC/IEEE 12207:2017 Systems and software engineering – Software life cycle processes was first introduced in 1995. This international standard defined the range of processes necessary for software systems development and maintenance, along with anticipated deliverables and subprocess activities. Even though agile workflows are predominant in the IT industry today, businesses still need some of these processes and planning to keep operations organized and to maintain/track their issues and goals.

The standard IEEE/ISO/IEC 24748-3-2020 - ISO/IEC/IEEE International Standard - Systems and software engineering–Life cycle management–Part 3: Guidelines for the application of ISO/IEC/IEEE 12207 is an international application development life cycle standard usually consisting of between six and ten stages:

• 6-stage life cycle (traditional): requirement analysis, design, development and testing, implementation, documentation, and evaluation.
• 10-stage life cycle (expanded): initiation, systems concept development, planning, requirements analysis, design, development, integration and test, implementation, operations and maintenance, and disposition. [Chapter 1 of US Department of Justice (2003). Information Resources Management Guide].

ISO/IEC 24748 is a guideline for applying ISO/IEC/IEEE 12207:2017 and established the well-defined terminology and implementation guidance for a common framework for software life cycle processes.

We see across these specifications that the System Development Life Cycle is not actually a methodology. On the contrary, it describes the phases in the life cycle of information or cyber-physical systems applications used by systems engineers, information engineers, and software engineers. The Software Development Life Cycle (SDLC) is typically considered a subset of the Systems Development Life Cycle.

We will use SDLC to refer to Software Development Life Cycle throughout this blog. Dissecting the software development life cycle (SDLC) into distinct stages can help teams compose a roadmap for their software delivery efforts. Within that decomposition, we can leverage software simulations.

In this post, we’ll demonstrate how software delivery simulation can fit into software delivery life cycles and how it can help businesses reach their goals.

Simulation and the seven stages of the SDLC

No correct or wrong way of breaking down software delivery exists, though more granular partitioning may allow businesses to develop more detailed software delivery plans. The 7-phase breakdowns appear to be more common, though splits with other numbers of stages (e.g., 5) exist as well.

At a high level, here’s what an SDLC might look like, and here’s how simulation can integrate into it:

Table 1: Integration of Simulation into Software Development Life Cycle

Table 1 demonstrates how simulation can be integrated into the software development life cycle. Within the context of the listed seven stages, simulation can be considered from these two viewpoints:

• Simulation as part of planning. Software delivery simulation can be used from phases one to three to facilitate software delivery planning and the assessment of the plan’s feasibility. Ideally, simulation should be utilized when an SDLC plan and requirements are already in place.
• Simulation as a tool for benchmarking. Software delivery simulation can simulate phases from four to seven to help teams assess the efficiency of their SDLC. Simulation can be applied to either an entire SDLC or its phases individually.

Several case studies serve to highlight how simulations can be integrated with the SDLC:

1. A simulation model that focuses on the error rates associated with waterfall methodologies and determining Average Defects per Phase, Average Defects per Day, and Average Repairs per Day (Kramer, Sahinoglu, & Ang, 2015).
2. A simulation of the Waterfall SDLC using the Simphony.NET simulator tool to assist project managers in determining the optimal number of resources required to produce a particular project within the allotted schedule and budget (Bassil, 2012).
3. A simulation model developed by Siemens Corporate Technology to demonstrate the impact of unstable software requirements on project duration and effort. This model analyzed the investment necessary to stabilize software requirements to achieve optimal cost-effectiveness (Pfahl & Lebsanft, 2000).

Nevertheless, businesses should decide when and how to use simulation-based on their software delivery life cycle structure and what makes sense for their needs.

How simulation can enhance software delivery

Simulation tools (such as Software Delivery Simulator) allow businesses to perform a test deployment of their software delivery pipelines. The simulation will enable teams to partially or entirely model software delivery workflows.

Code quality checks, artifact building, pushing new commits, team meetings, deployment in the cloud – pretty much all the steps of software delivery can be simulated in a virtual environment. The Software Delivery Simulator even allows team members to consider components like software development/deployment solutions (like Jenkins, Eclipse, or Kubernetes or collaboration environments (like Microsoft Teams, Eclipse, or GitHub) to help them obtain a more granular understanding of their systems.

All this can be visualized via informative and easy-to-read flowcharts to help team members and stakeholders keep track of tasks and activities and ascertain that the SDLC was built correctly.

But how exactly can software delivery simulation benefit businesses? Here are three SDLC examples where simulation can support the team!

Simulation may be used for SDLC benchmarking

The ultimate goal of building a software delivery simulation is assessing if the team’s plan can meet the enterprise’s business goals in terms of time and costs. This goal is achieved by laying out the steps of software delivery (e.g., code production, quality assurance, and deployment) and providing estimates of their completion time.

At the end of a simulation run, businesses receive an estimate on the duration of project (or a component) execution. Based on this estimate, companies can decide on a further course of action – they can continue the project, reevaluate their software design choices, or scrap the project altogether.

A few case studies of using simulations to benchmark within the SDLC are:

1. A simulation study developed using four benchmark software development projects that suggested that greater performance towards zero defects can be achieved through testing after each phase (concurrently) in the development life-cycle of software as opposed to testing after the system’s coding has been completed (Huq, 2000).
2. A simulation model that supports a decision-maker involved in performance analysis for a given distributed application by analyzing the execution environment through various configurations of hardware resources based on dynamic workload over a specific time period (Geetha, et al., 2012).

Note that simulation can’t provide the actual completion times or costs of a project – only estimates. Furthermore, the validity and reliability of simulation results depend on how well simulation engineers understand the simulated process and how accurately they’ve estimated its statistical properties (such as code quality check failure rate, mean completion time, etc.).

Simulation may be used to identify SDLC bottlenecks

Not only can software delivery simulation help businesses estimate the duration and costs of their projects, but it can also help them identify and eliminate bottlenecks in their SDLC.

Consider a situation where a carefully crafted SDLC doesn’t meet specified time requirements. To rectify the issue, the simulation team would need to identify time-consuming activities in the system and tweak them to achieve satisfactory performance.

Two other case studies are:

1. The simulation modeling of UML software architectures (Balsamo & Marzolla, 2003, June).
2. A simulation that identified and introduced cost-saving measures for increasing the return on investment (ROI) during the Software Development Lifecycle through selected quantitative analyses employing both the Monte Carlo and discrete event simulation approaches (Sahinoglu, et al., 2014).

Figuring out what needs to be optimized can be challenging. Still, simulation eases the burden by allowing simulation engineers to fine-tune SDLC steps in a safe environment with minimal time investment. Engineers can quickly and easily identify bottlenecks by playing around with model parameters.

Essentially, simulation can point out what can and needs to be improved in a system. Businesses could take these insights and institute optimization activities, and these optimizations could later be tested with simulation once again.

Simulation may help businesses test their SDLC understanding

Finally, the simulation could help businesses check if their software delivery workflows are well understood. Suppose a company can’t visualize in detail how ideas and specifications proceed from point A to point B on their way to becoming software. In that case, gaps may become apparent in the software delivery plan and perhaps even the business’s understanding of how software delivery should be carried out.

Figure 1 illustrates a causal model coded into a software process simulator. It became the basis for project managers and researchers to perform ‘‘what if” analyses and enabled users to examine the risk of various levels of requirements volatility and determine project outcomes.

Though this form of a “sanity check” isn’t the primary reason for using simulation, it can still have a critical impact. It can help teams identify inconsistencies or omissions early on from software delivery plans.

Next steps

Simulation most certainly has immense utility, but it should be used sparingly. Yes, it can dramatically enhance software delivery workflows. Still, it is most useful when no better alternatives exist, and a sufficiently accurate statistical description of the target system can be provided.

With that, recognizing when software delivery simulation should and should not be used is essential. And when the simulation is indeed the best tool in a given situation, it should be carefully planned and executed.