Tag Archive for: v-model

ASPICE

If you haven’t already, check out Part I of our ASPICE 101 blog series to learn about what the standard is and why it’s important to automotive development, and Part II, where we examine the similarities and differences between ISO 26262 and ASPICE. In this post, we take a look at the goals of ASPICE and the different compliance levels.

Fundamentally, the goal of ASPICE is to define best practices for development of embedded software for vehicles.

Given that a modern vehicle can involve hundreds of millions of lines of code, creating some objective “best practices” can only benefit the teams working on this code. And it’s not just how much code is required that adds complexity — it’s also the fact that companies increasingly work across geographic and industry boundaries. When looking for suppliers, having some objective standards of assessment can be useful.

ASPICE is based on the V-Model — a model that requires logical decomposition of requirements and rigorous evaluation through testing at each stage of development. This model benefits both suppliers and system integrators by giving opportunity to eliminate problems in early development stages and providing a framework for ideation and development.

ASPICE V-ModelIt also ensures continuous innovation and product development. On the left side of the V-Model are initial phases of product development.

  • Requirement Analysis: Discovering, listing, and prioritizing client requirements
  • System Design: Mapping client needs and putting them into a viable work model
  • Architecture Design: Organizing requirements into logical operations
  • Module Design: Creating software requirements that match system requirements and developing service units
  • Coding: Designing and implementing units; this is the point of the V

On the right side of the V-Model are the secondary phases of product development:

  • Unit Testing: Determining if code and design match and standards and requirements are met
  • Integration Testing: Evaluating software architecture and service units
  • System Testing: Integrating everything into the full system and testing
  • Acceptance Testing: Performing final tests

The advantage of the V-model is that it promotes testing and improvement throughout the development cycle. For each point along the V, there is a corresponding testing phase and additional traceability and management processes. Suppliers who follow this ASPICE model can earn certifications according to standardized achievement phases; the ASPICE standard is scored in levels from zero to five, which clients can use to evaluate the proficiency of the development team.

ASPICE levels are as follows:

LEVEL 0 | Basic

Teams at Level 0 are still developing processes or systems. They can, at most, “partially” achieve ASPICE requirements. These teams should focus most of their efforts on managing basic tasks.

LEVEL 1 | Performed

Teams achieving Level 1 either nearly or completely deliver standard ASPICE requirements, but likely have gaps in their processes.

LEVEL 2 | Managed

Level 2 teams can reliably deliver work products and almost or completely achieve ASPICE standards.

LEVEL 3 | Established

At Level 3, teams have established and set performance standards and are engaged in continuous improvement to constantly evaluate and learn.

LEVEL 4 | Predictable

Level 4 teams measure, record, and analyze outcomes; evaluate outcomes and processes objectively; and consistently meet performance standards.

LEVEL 5 | Innovating

Level 5 teams have reached a stage where they are not only consistently delivering high performance and quality products, but also engaging and investing in continuous improvement. These teams also analyze performance standards for quantitative feedback and causal analysis resolution.

ASPICE does not prescribe tools or techniques for teams, but rather gives a framework for examining the approach to internal development methods. The ASPICE standard is mostly generic and largely tool and process “agnostic” — that is, it gives a framework for evaluating the process and outcomes, but does not dictate the best processes or methods for every team. Because every team is different, this generic approach can help bring order and improvement to any team operating in any automotive system or space.

ASPICE levels look daunting, and for a start-up or young team, the idea of achieving Level 5 might seem out of the question. However, it’s important to note that Levels 4 and 5 are aspirational; most teams that achieve these levels are part of very large corporations. Level 2 is a more realistic initial target, and by the time teams are at Level 3, they are functioning at a standard broadly considered “excellent.”

How ASPICE Affects Automotive Development

The world of automotive development is only becoming more complex.

Some factors that are increasing complexity:

Consumer demand: A connected world means that consumers want seamless connectivity across their entire lives. The lines between work, home, and leisure are increasingly blurry, and consumers who still need vehicles to get from point A to point B will want all of those pieces of their lives to be integrated — even behind the wheel.

Increasing regulation: With the increasing complexity of auto systems and a focus on reducing climate impact, auto manufacturers will have to comply with new and possibly shifting regulations across different entities.

Rapid innovation: Technology continues to change and innovate at a breakneck pace. With systems increasingly integrated into automobiles, manufacturers will have no choice but to keep up with innovation. In fact, as of 2019, 80% of product innovation in automotive comes through software development

Fortunately, ASPICE can help auto suppliers and original equipment manufacturers (OEMs) respond to this increasing complexity in multiple ways:

Control the process: ASPICE gives teams clear guidance for evaluating and controlling their development processes, which can help ensure product quality, shorten time to market, and reduce costs.

Streamline supplier selection: By clearly defining levels of achievement, ASPICE can help OEMs assess and evaluate suppliers. If suppliers achieve Level 2 or 3 in ASPICE, OEMs can be fairly certain they are getting quality products.

Reduce costs and improve time to market: Because ASPICE is more concerned with process than with specific regulations or safety guidelines, using the standard can help teams reduce costs and improve efficiency, thereby improving overall market competitiveness.

How to Ensure Compliance with ASPICE

Most automotive developers are rigorously working towards ASPICE compliance and there are many advantages to aiming for it.

1.) It’s possible that compliance will be required some time in the future, so working toward it now is a positive step in preparation.

2.) Automotive development is only getting more complicated, not less, and development will continue to require teamwork across industries, companies, and geographies. Working within the ASPICE standard will help ensure consistency.

3.) Working within ASPICE will give teams a competitive edge over other suppliers and OEMs who are not yet using the standard.

But knowing that compliance is desired and actually achieving it are two different things. How can teams ensure compliance with the ASPICE standard?

Start with an honest assessment.

Teams can’t know where to go until they know where they are. A good place to start is to draft current processes and compare them to the ASPICE V-model. This effort can provide good insights into current levels compliance and where improvements can be made.

Confront the gaps and missing pieces.

Most teams will have some gaps in their processes or procedures. Likewise, some teams will have unclear separation between steps in the V-Model. Look at the gaps and assess how to close them, and identify where additional steps should be introduced.

Include stakeholders.

Be sure that all stakeholders have complete visibility into the ASPICE compliance efforts, and clearly define the resources those stakeholders can provide where necessary.

Test every phase.

Testing is vital to ASPICE compliance. Be sure to include rigorous testing at every phase in the process.

Operate under the new guidelines.

Once the plan is in place, implement it immediately.

Reassess and improve.

After completing a new product under the new ASPICE compliant processes, reassess, evaluate, and look for ways to improve. This constant focus on improvement is what allows teams to achieve higher levels of ASPICE compliance.


The Myth of the V-Model

If you are building complex systems, then you have probably heard of the V-Model. Before we explain it, a word of caution: There are different, partially contradicting definitions of the V-Model. Further, it’s easily misunderstood, which can be more harmful than helpful. This is also the source of the myths of the V-Model. Understanding the Myth of the V-Model helps you apply it correctly, thereby making you more effective.

The V-Model in Brief

Above is one visualization of the V-Model: To understand it, we start in the top left. Here you find the high-level requirements (“Concept of Operations”). Following the left arm of the V, the product definition is refined until we reach the implementation. The right arm of the V contains the corresponding items for validation and verification, like tests, analysis or inspection.

What’s unclear about the model (and frequently a source of confusion) are the relationships between the elements, visualized through arrows. Note that the various arrows have different meanings:

  • The solid lines connecting the boxes represent dependencies. For instance, there is a relationship between “Requirements” and “Detailed Design” (the Detailed Design is a possible solution). If the requirement changes, then usually the design needs to change as well. For instance, changing the battery life from 24 to 48 hours (requirement) will probably require a larger battery (design).
  • The dashed “Verification & Validation” lines also represent a dependency, but this time for test coverage. Note that the arrows in the figure represent a “tests” relationship (“System Verification & Validation tests Requirements & Architecture”). The direction of the dependency is in the other direction (e.g., changing the battery life from 24 to 48 hours will trigger an update to the corresponding Systems Test).
  • The outer dashed lines denote activities, and broadly represent time. But here we have to be very careful because they do not represent a strict time sequence. This is a huge source of confusion.

Now that we have a rough understanding of the V-Model, let’s look at four of its common myths:

Myth: The V-Model is Only an Extended Waterfall

If we take the time axis too literally, then the V-Model appears to be the Waterfall Model (the left side of the V), with the verification “folded” up. Just as a reminder, the Waterfall model is a linear development approach. It consists of different phases (requirements, design, implementation, etc.), where each one is completed before the next starts. The main difference between the V-Model and Waterfall is the fact that the V-Model iteratively increases the maturity of the development, affecting all items of the product description.

Myth: The V-Model is Simply a Process

This statement is correct, but not complete. Yes, the V-Model is a process. In fact, it is widely used, cited and standardized in various ways: There is the German “Das V-Modell,” a government standard and PRINCE2 method, which is used in the UK and US. Many standards reference it, including ISO/IEC/IEEE 15288.

But this view focuses on the process and ignores the fact that the V-Model also represents the artifacts of product development and their relationships. This second view can generate additional insights, especially if the artifacts are fine-grained: For instance, traditionally the box “requirements” in the figure above would represent a requirements process, with a process flow to the design process.

But if these represent individual requirements, with a precise traceability to design elements, this relationship can suddenly be used for coverage analysis (“ensure all requirements are covered”), change management (“after this requirement change, which design elements are affected?”) and much more.

Looking at both — the process and data model — significantly increases the value of the V-Model.

Myth: The V-Model Cannot be Applied in an Agile Environment

This myth is related to the previous one: The existing methods based on the V-Model were created in the ‘90s, before the Agile Manifesto was created.

But the V-Model itself is not just compatible with Agile methods. It’s (almost) a prerequisite! To be more precise, a robust relationship model, like the V-Model, is the foundation for making changes with confidence. And frequent changes are one of the aspects of Agile development. A robust relationship model reflects the triangular relationship between requirement, test and implementation.

Myth: During Development, We Move from Left to Right

As already indicated in the two myth we busted, the V-Model requires jumping back and forth during development. Nevertheless, the assumption is that we need requirements before we can create the corresponding tests.

But the V-Model is well-suited to also support behavior-driven development (BDD). In BDD, the expected behavior is defined in a testable manner. Design only starts after the behavior is defined.

This corresponds to test-driven software development, where an automated test is written before the software implementation is created. For BDD to work, the relationships between the items concerned must be clearly defined and available for analysis and change management.

The V-Model provides the necessary structures for this process. In fact, this triangular relationship is visible in the V-Model’s triangular form, except that BDD uses a slightly different terminology.

The V-Model and Product Development Platforms

The V-Model can be confusing, as it relates to both process and data models. Product development platforms like Jama Software distinguish between these two aspects and address them separately:

  • Works with a flexible data model consisting of item types and relationships. These can be tailored to existing artifacts and workflows. This allows the product description to evolve naturally, while managing the relationships automatically. The results are a clearer understanding of coverage without the fear of changes.
  • Allows workflows to guide the maturity of the product description, aligned with existing processes. This creates the confidence in the quality of the product, makes it easy to work in a compliant environment and takes the anxiety out of audits.

Conclusion

The V-Model is a powerful concept. But it has been around for a long time: It was created in a time where document-based work was the norm, and where Agile was not yet an established approach. Applied in a modern context, the V-Model is the enabler for the faster development of better products. But in order to take advantage of this, it must be understood.

Learn how to overcome tight timelines, increasing product complexity and risk and regulation adversity with our webinar, “Do More with Less: How Effective Requirements Management Increases Productivity.”