Month: October 2020

Disco beat or syncopated rhythm: Finding the Review Cycle

Published on by Michael BurkeLeave a comment

Weekly standing meetings are the “disco beat” (1) of review cycles. For projects that march forward at a well defined interval (2) regular meetings are the correct way to go. But what about for the more common project with irregular updates?

The ideas behind Agile Development (3) seem like the perfect counterpoint to the “set” review cycle, a syncopated rhythm. The short daily stand ups and sprint wrap ups seem like the way to review when you need to review. However, in practice, people come to the stand up meetings less prepared than they should be for a formal review.

Event triggered reviews

One approach is to move to “event triggered” reviews. The event is tied to one of 3 things

  1. Completion of one or more requirements: This is a logical review point as the completion of requirements should be verified as part of the validation process.
  2. Update to requirements: When requirements change, a review of the model should be performed to determine the impact of the change. If they exist at this point in time, the associated test cases should be updated.
  3. External trigger: This is generally when a “real world” bug is discovered; you are reviewing because there is a need for a major change

Model size: absolute and % change

A change in the model size alone is not a valid trigger for a model review, if I have added in 1,000 new blocks but the functionality is the same, there is nothing new to review. At the same time, developers should use the change in model size as a caution. If you have added in 100 blocks and the functionality has not changed then most likely you are working in an unfocused fashion.(4)

Testing…

When tests fail, and if the developer cannot get to the root cause, it is a clear sign that a design review is in order. For these reviews the full test failure diagnostic logs should be part of the review, both pre-and post failures. If possible, the deltas in the model and model data should be presented as well.

Informal reviews

As a final note, not all reviews need or should be formal. Informal reviews are helpful for those “I’m just stuck here” moments in the development process that everyone faces. More often than not, the simple process of talking through what you are doing will help you resolve the issue.

Footnotes

  1. The “four to the floor” disco rhythm is easy to dance to but lacks the complexity of other drumming styles.
  2. There are projects with this sort of well defined interval; they tend to be instances of the same work being repeated.
  3. There are few animals more agile then a ring-tailed lemur.
  4. The exception would be in the case of a model architecture reorganization. In general this should reduce the number of blocks but there are instances where the model size could grow.

Model-Based Design Walk Through: Part 5: V&V

Published on by Michael BurkeLeave a comment

This post is the fifth in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole, these videos, provides the foundation stones for understanding and implementing Model-Based Design workflows. I will be using a simple Home A/C system for my example; however the principals apply to everything from Alpine ski sharpeners to Zamboni de-icing.(1)

Today we will look at three V&V activities: guideline compliance, coverage and requirements based tests.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnotes

  1. Qui transfert terminos glacies et gelu de auferentes?
  2. Additional links for how to use…
    1. Simulink Design Verifier
      1. From MathWorks
      2. From this blog
    2. Simulink Test
      1. From MathWorks
      2. From this blog

Model-Based Design Walk through: Part 4: Data

Published on by Michael BurkeLeave a comment

This post is the fourth in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole, these videos provide the foundation stones for understanding and implementing Model-Based Design workflows. I will be using a simple Home A/C system for my example; however the principals apply to everything from Active suspensions to Zonal control.(1)

With this post I cover the basics of data management, both for the model and configuration settings.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnote

  1. Stay in the zone, even when you zone out!
  2. Take it with a grain of salt but how you pronounce the word “Data” may be dependent on ST-NG