Wouldn’t it be nice if your systems/software-development process was so matured that you want to re-apply it to future projects? Wouldn’t it be even better if your development tooling was matured in way that supports not only the re-use, but also specific adjustments (of tool-configurations, templates for artifacts etc.) so that you can re-apply the implementation of your process easily?
In order to support re-use and adjustment of YAKINDU Traceability (now itemis ANALYZE) (YT) configurations, we developed a new feature called parameterized configuration. We are proud to say that this new feature originates from a feature request of a customer who had exactly the above spirit of re-use in mind, so we are declaring it feature of the month for July 2018.
I want to use our WiperWasher example to illustrate this new feature. The traceability configuration in this example is inspired by Automotive Spice, (but our approach is valid for any standard in the context of functional safety like ISO26262 etc.) and traces from/to stakeholder requirements, system requirements, and software requirements which are all specified in IBM DOORS (and to a lot of other tools / artifacts which are not relevant here).
Imagine we have different variants of the WiperWasher and let’s say that all our requirements – i.e. the DOORS modules – have a parameter specifying for which variant(s) the given requirement is valid.
The image below shows the related YAKINDU Traceability (now itemis ANALYZE) configuration of without the usage of parameters.
In this case, YT is configured to extract stakeholder requirements for variant V1. The configuration is similar for system requirements and software requirements. If in this case you want to switch the variant, you have to adjust the variant three times for each DOORS mapping. And you have to ensure that you do this consistently, because otherwise you would e.g. accidently trace across different variants.
To overcome this inconvenience, we want to introduce a configuration parameter. Did you notice the P+-icon on the top of the configuration?
In our example, I defined the parameter DOORS_Variant with possible values V1 and V2 and made V1 the active value.
Once the parameter is defined, I can adjust mappings of the DOORS requirements to use the new parameter.
If I now want to switch the variant, I only need to switch one parameter and this change is then consistently applied to all three mappings of DOORS requirements. And – for those companies that use e.g. the batch mode of YAKINDU Traceability (now itemis ANALYZE) to analyze their project automatically, e.g. “nightly”, it is possible to set the active parameter values via the command line. This leverages the re-use of the very same YT configuration not only between dedicated batch evaluations for different parameter sets (i.e. the DOORS_Variant in our example) but between batch- and user evaluations.
If you want to know more about the new feature, just look into the online help topic describing configuration parameters. If you want to learn how YAKINDU Traceability (now itemis ANALYZE) helps you to analyze your traceability, you may want to download our self-guided example. It’s free :)