What's the best way to implement a configuration of a product that has over 2000 attributes, so that we can also print a table of the config using RPE?
Product config has over 2000 attributes. Our initial thought was to create a DNG module with all the attributes, but creating all of those attributes sounds painful, unless there's an easier way? Another thought was to use a Rhapsody Table. |
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 02 '21, 12:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER If this is just to compare the design with the actual system config, I'd just create a textual requirement in DNG with those attributes listed. To simplify the "compare" operation, I'd make the format of that text match as closely as possible the way those attributes are defined in the actual system config. Comments We have a product that will have a "recommended configuration" and "current actual configuration". There are over 2000 different settings that can be changed on these configs. Are there any other jazz tools that would accomplish modeling this and also interfaceable with RPE to print a comparison report of the two configurations? Thanks!
Geoffrey Clemm
commented Aug 03 '21, 2:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
What constraints are there on how the "current actual configuration" is specified? For example, can it just be a text-valued requirement with one line per configuration setting? Or is it required to be in some particular format? We'd rather each setting have it's own 'attribute', as some may require us to have some enumerations and such.
Geoffrey Clemm
commented Aug 03 '21, 7:21 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The approach I would recommend for something like this would be to use a variant management system such as pure::variants ( https://www.pure-systems.com ). That would allow you to both model your system, as well as add constraints. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Can you provide more insight into how those 2000 attributes are used (possibly, some examples)? For instance, do you have a product family with 2000 variation points, where a particular product selects a value for each of those variation points? And if so, how are those values used ... just for reporting, or for configuring the product at design, build, or run time? The best way to implement those 2000 attributes will be determined by how you then plan on using those attributes.
Those 2000 attributes are basically different options for that specific config of the system. We will be using these attributes to compare the config in the model/dng to how the actual system config is setup.