Software Development Models Compared

Overview of Development Models: Organizing 5 Types on a Single Axis

A development model is an approach that defines the order and repetition of processes such as requirements definition, design, implementation, and testing (see “Development Overview and Rework-Free Design”). There are five typical development models: waterfall, agile, spiral, prototyping, and incremental. The iterative model, which is often confused with these, will be discussed later not as an independent sixth type, but in the context of clarifying the differences between spiral and incremental models.

The five models are broadly divided into those that proceed through the processes sequentially only once and those that repeat them. Even when repeating, the unit of repetition differs for each model. Whether to repeat by feature, according to the level of risk, or centered around a prototype determines how to choose a model. This article compares these five types across the board and covers how to use them in embedded development.

Waterfall Model and Agile Model: Reviewing the Two Basic Choices

The waterfall model is a development model in which processes such as requirements definition, design, implementation, and testing proceed sequentially without going backward. It is easy to manage progress, and because the deliverables of each process are documented, it is also easy to keep quality assurance records. On the other hand, it has the weakness that the cost of rework increases as the project progresses to later stages. From a quality assurance perspective, the waterfall model is commonly operated in combination with the V-model.

The agile model is a development model that repeats processes such as planning, design, implementation, and testing in short-term iterations. A single iteration is typically limited to a few weeks. Its strength lies in the ability to deliver working software incrementally while reflecting user feedback in the next iteration. On the other hand, the overall plan and completion timeline are harder to estimate compared to the waterfall model.

These two models and their application scenarios are explained in more detail in another article (see “Waterfall vs. Agile Development”). This article also focuses on the remaining three models.

• View PDF for details

What Is the Spiral Model? Development That Expands While Repeating Risk Analysis

The spiral model is a development model proposed by Barry Boehm in 1986. It divides a system into parts and gradually expands the scope while repeating four processes: planning, risk analysis, development and testing, and evaluation. A key feature is that a series of processes from requirements definition to design, implementation, and testing is executed within a single cycle.

The most significant feature is the explicit incorporation of risk analysis into each cycle. Risks such as technical difficulty and schedule delays are identified early in the cycle, and countermeasures are taken before proceeding to development and testing. This procedure makes it easier to handle uncertainty, even in large-scale projects where requirements are not yet finalized. This development model is particularly suited for large, complex projects with high technical uncertainty.

Disadvantages include the need for experienced engineers who can properly evaluate risks. In addition, requirements tend to expand with each cycle, which can lead to budget and schedule overruns. Because the final product is difficult to see at an early stage, this model is not well-suited for fixed-price contracts.

What Is the Prototyping Model? Development That Aligns Requirements Through Prototyping

The prototyping model is a development model in which a working prototype is created at an early stage of development. This prototype is used to elicit specific requirements while allowing users to operate it, aligning the understanding between developers and users at an early stage.

There are two main ways to handle prototypes. One is to discard the prototype once requirements are finalized and build a production system from scratch. The other is to modify the prototype and develop it directly into the production system.

The advantage is that differences in expectations for the final product can be resolved early. It also allows for flexible responses to specification changes and feature additions. The disadvantage is that creating the prototype itself takes time and cost. As the product scale becomes larger and more complex, the burden of modifying the prototype also increases.

In embedded development, this model is suitable for areas where you want to finalize specifications while checking the user’s operational feel, such as the screen design of an operation panel. Even without using a prototype of the actual machine, alignment can sometimes be achieved using a prototype that only reproduces screen transitions.

• View PDF for details

What Is the Incremental Model? Development That Adds Features Incrementally

The incremental model is a development model in which requirements definition is performed only once at the beginning, and features or scopes are divided into several parts to be designed, implemented, and delivered incrementally. First, a version with core features is developed and released. Then, features are added in order of priority.

The advantage is that a usable version can be provided to users at an early stage. Since work can start with high-priority functions, important functions can be reliably delivered even with a limited budget or timeframe. The disadvantage is that functions added later may cause rework in the design finalized in the previous stage. Designing to maintain the independence of each part also requires a corresponding amount of man-hours.

In embedded software, a typical example of the incremental model is to first implement the essential control functions and then gradually add logging and communication functions.

Differences Between Spiral, Incremental, and Iterative: Clarifying Three Often-Confused Models

These three development models are easily confused because they all involve repeating processes. The key to clarifying them is to understand for what purpose and in what units the repetition occurs.

The incremental model focuses on dividing functions or scope and adding them step-by-step. Requirements definition is done only once at the beginning. The iterative model focuses on repeating the same scope in short cycles to gradually increase completeness. This approach involves reviewing the deliverables of the previous cycle and making continuous improvements. The spiral model is a development model that explicitly incorporates risk analysis into each cycle, expanding the scope of development while evaluating risks. The duration of a single cycle is also relatively long, on the order of several months.

For example, consider a project to add support for a new communication standard to an existing measuring instrument. The approach of separating the communication function as a unit and adding it to existing functions is the incremental model. The approach of completing the separated communication function through repeated operation checks and modifications is the iterative model. If there is high uncertainty regarding the feasibility of the communication standard to be adopted, the spiral model concept of repeating prototyping and evaluation to assess risks is added.

This classification may vary depending on the source. Some literature explains the spiral model as a higher-level framework that includes two approaches: incremental and iterative. Since this is an area where definitions of terms are not standardized, it is necessary to be aware of which perspective the explanation is based on when reviewing materials.

In practice, it is common to combine these concepts. It is not unusual to gradually add functions while iterating each stage in short cycles, focusing evaluation on high-risk areas.

• View PDF for details

Model Selection in Embedded Development: Application Scenarios, Decision Criteria, and a Hybrid Approach

In embedded software development, the suitable model varies depending on the nature of the project. For products that require compliance with safety standards or are intended for mass production, the waterfall model or V-model is the standard. Even in IEC 61508, a cross-industry functional safety standard, and IEC 62304, which targets medical device software, the development process is generally explained using the V-model. This is because standard compliance emphasizes the ability to keep records of the correspondence from requirements to design, implementation, and verification.

Since design changes after mass production affect even the procurement of molds and parts, an approach that avoids rework in later processes is required.

On the other hand, for parts where improvements are made based on user feedback, such as the UI of operation panels or the application layer, iteration using the agile model or iterative model is suitable. For highly novel products where requirements themselves are not yet finalized, an approach that aligns understanding at an early stage using the prototyping model is effective. How much the software depends on hardware specifications and timing also influences model selection (see “Embedded vs. General-Purpose Software”).

• Degree of requirement finalization: How well requirements are defined at the start of development
• Degree of hardware dependency: How much the software depends on hardware specifications and timing (see “Constraints in Embedded Development”)
• Presence of standard requirements: Whether records or evidence of the development process, such as functional safety standards, are required
• Susceptibility to change: How frequently requirements or specifications change during development or after market launch
• Team size: The number of people on the development team and whether the structure spans multiple locations

In actual embedded development sites, it is rare for a project to proceed using only a single model. A combination is also seen where design and testing proceed with a highly planned waterfall model, while the implementation process proceeds with agile model iterations. Differentiating development by using the waterfall model for safety-critical core functions and the agile model for user-oriented functions is also adopted in actual product development.

In model selection, in addition to the five decision criteria mentioned so far, whether there is an environment where tests can be repeatedly executed is the sixth perspective. No matter which model is selected, this perspective influences the feasibility of development (see “Types of Software Testing”). In embedded development, there tends to be a period during which tests cannot be executed until actual prototypes or mass-produced parts are available. By using a verification environment that simulates connected devices and I/O signals, verification can be started even before actual machines are available.

Summary

There are five types of development models: waterfall, agile, spiral, prototyping, and incremental. In embedded development, it is rare for a project to proceed using only a single model, and hybrid operation according to the characteristics of the project is realistic. In addition to model selection, preparing an environment where tests can be repeatedly executed is essential for proceeding with development as planned.

• View PDF for details