V Diagram For Systems Engineering

The Challenge of the Systems Engineering V

Systems engineers have long viewed the V as a fundamental part of good engineering. Lately though, the systems engineering V has gotten a bad rap. The new generation of engineers view it as a symbol of slow, waterfall engineering practices. They consider these practices irrelevant to the speed required for software development.

Traditional engineering proponents prefer the V to "agile" methods. This is especially true when it comes to critical systems.

Who should we believe?

Well, if we're honest, when the V exists as one glorious pass for an entire system, the new generation makes a great point. The V really can slow good software development down.

What is the Systems Engineering V?

At its core, the Systems Engineering V is a logical construct. It describes the discovery of system requirements by breaking a system down into smaller parts and then assembling and validating those parts.

Systems engineers apply the V in various contexts. Most often, the V appears in large organizations, such as the US Department of Defense. It's also prominent in academic institutions.

These large programs or organizations use the V as part of their top-level execution process. The general workflow has seven phases:

The process starts on the left side of the V where (1) concepts are generated. Next, (2) requirements for the entire system are defined, decomposed, and allocated. Then, (3) system components are designed in detail.

Implementation occurs at the bottom of the V (4). This is where the designed components are created according to the requirements from earlier in the process.

Moving up the right side of the V, those components are (5) integrated together into the final system. The integrated system is then verified to ensure it meets the original requirements and validated to ensure it meets user needs (6). Finally, (7) the system is delivered and maintained.

Challenges of the V

Executing the V process proves troublesome for many large projects-especially those that include software.

Integration
One major problem is that integration occurs too late in the development process. Programs relying on the V wait until software components are complete to reduce costly integration re-work.

Manual integration of software components takes a tremendous amount of time. The reality we all know to be true is that software is never done. Integration activities left to the end are rushed to meet the program schedule.

In the V, integrated components usually meet functional requirements, but often fail to be safe, secure, or correct.

Verification & Validation
Waiting until the system has been completely integrated to conduct verification and validation (V&V) compounds this problem. Implementing fixes causes ripples throughout the entire system, making it challenging and costly to address issues that arise during V&V.

Programs often put in place 'system-level' fixes instead of solving the root of the problem — a band-aid approach. Software risk is often mitigated by practices such as system level firewalls and anti-virus software rather than addressing it in code.

Band-aids decrease the chance that users encounter the flaw, but the flaw itself is not fixed and continues to lurk in the system.

Meeting the challenge

The concepts in the Systems Engineering V are not the problem — it is the structure of the V that does not apply to software

Modern techniques can enable continuous integration of software, even on large programs. Using tools and processes that embrace early integration and verification do not negate the core concepts of the V — they enhance the V so that it works for software development.

The end result is software that is correct at creation, and a system that is cheaper, safer, and faster to deliver.

Posted by: kerakeramcmahille0272367.blogspot.com

Source: https://medium.com/the-framework-by-tangram-flex/the-challenge-of-the-systems-engineering-v-8a2631c1a43a