SYIV System Integration and Verification

Linked Knowledge Nuggets:
arrow_forward "Systems Engineering - Why the heck do we need this?"

person Author: Alexander Feulner
The increasing complexity, shortened development times, distributed development, heightened cost pressures, technological change, and organizational transformations are just a few of the challenges facing the current development. If these statements seem unfamiliar to you, we congratulate you warmly. For all those who are confronted with these challenges on a daily basis, we present the methodology of ‘Systems Engineering’ in our webinar and answer the question: "Why the heck do we need this?". This webinar is tailored not only for system developers but also for professionals in various domains including software development, hardware development, testing, project management and more.

• school Webinar recording and slides
  

arrow_forward "Testmanagement"

person Author: Process Fellows
Test Management ensures that testing activities are strategically planned, monitored, and evaluated across all development phases. From unit tests to system-level integration, this cross-cutting discipline defines methods, tools, documents, and roles to ensure traceable and efficient verification and validation.

• school PF_Testmanagement_Extract.pdf
  Short Overview of Test Management (related to all Automotive SPICE® verification processes)

arrow_forward "Verification level vs. Verification timepoint"

person Author: Process Fellows
The execution of a verification measure is not necessarily linked to the verification time point. It is possible that a verification measure from SWE.6 is carried out as part of the verification of the SW component and integration verrifcation if the setup or the environment is better suited to this. However, it remains a verification of the SW requirements. The decisive factor is what a verification measure is derived from. However, it is important to ensure that this verification measure is included in and part of the report and in the summary of the SW verification. Pay attention to the sequences and dependencies to be followed.

• O1 Verification measures (Verification measure = Verification measure can be:
  • Test cases
  • Measurements
  • Calculations
  • Simulations
  • Reviews
  • Analyses
  Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) for system integration and for system verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) are specified
• O2 System elements (System Element = System elements can be:
  • Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
  • Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.
  ) are integrated up to a complete integrated system, the integration is verified with specified verification measures (Verification measure = Verification measure can be:
  • Test cases
  • Measurements
  • Calculations
  • Simulations
  • Reviews
  • Analyses
  Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), and the verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) results are recorded
• O3 The integrated system is verified with specified verification measures (Verification measure = Verification measure can be:
  • Test cases
  • Measurements
  • Calculations
  • Simulations
  • Reviews
  • Analyses
  Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) and the results of system verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) are recorded
• O4 Horizontal traceability is established on all levels

BP1 Specify and perform verification measures for integration. ( O1, O2 )

Specify and perform verification measures (Verification measure = Verification measure can be:

• Test cases
• Measurements
• Calculations
• Simulations
• Reviews
• Analyses

Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) for the integration and record the verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) results including pass/fail status. Perform integration of the system elements (System Element = System elements can be:

• Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
• Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.

) until the system is fully integrated.
Note 1: Examples for preconditions for starting integration can be successful system element (System Element = System elements can be:

• Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
• Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.

) verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) or qualification of pre-existing system elements (System Element = System elements can be:

• Logical and structural objects at the architectural and design level. System elements can be further decomposed into more fine-grained system elements of the architecture or design across appropriate hierarchical levels.
• Physical representations of these objects, or a combination, e.g., peripherals, sensors, actuators, mechanical parts, software executables.

)

Linked Knowledge Nuggets:
arrow_forward "Archiving test results"

person Author: Process Fellows
Don’t lose your evidence. With perspective to testing, SUP.8.BP1 in combination with SUP.8.BP8 expects structured storage of test logs, verdicts, anomalies, and configuration info. This is not only a formality: It enables you to later on reproduce details about a certain system version.

BP2 Specify and perform system verification measures for system. ( O1, O3 )

Specify and perform the verification measures (Verification measure = Verification measure can be:

• Test cases
• Measurements
• Calculations
• Simulations
• Reviews
• Analyses

Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) suitable to provide evidence of compliance of the integrated system with the system requirements. Record the verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) results including pass/fail status.

Linked Knowledge Nuggets:
arrow_forward "Archiving test results"

person Author: Process Fellows
Don’t lose your evidence. With perspective to testing, SUP.8.BP1 in combination with SUP.8.BP8 expects structured storage of test logs, verdicts, anomalies, and configuration info. This is not only a formality: It enables you to later on reproduce details about a certain system version.

BP3 Establish horizontal traceability. ( O4 )

Ensure horizontal traceability from system requirements and system architecture to the corresponding verification measures (Verification measure = Verification measure can be:

• Test cases
• Measurements
• Calculations
• Simulations
• Reviews
• Analyses

Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) and results.
Note 2: Horizontal traceability supports consistency, impact analysis and verification (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) coverage demonstration for a respective V-model level.

Linked Knowledge Nuggets:
arrow_forward "Consistency vs. Traceability – What’s the Difference?"

person Author: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.

arrow_forward "The true benefit of traceability "

person Author: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized. Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments. In the aftermath, the effort increases noticeably and the risk of gaps is high. If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure. It also enables proof of complete coverage of the derived elements and allows the complete consistency check.