If you have a fairly typical MDSW app that takes in some data, does a calculation and displays an answer or report (i.e. structurally it's very simple) but it includes dozens, maybe hundreds of small "SOUP" items like standard windows components, dlls etc.
It doesn't seem reasonable/possible to get that into the architecture, one by one in a diagram, and does it make sense to include as a list (client is exporting a document with a list of all SOUP items, with version numbers and website etc).
does it make sense to lump together these small components into a single "SOUP" item, lets say you have a DATABASE item in your architecture, group the relevant standard plugins or components into a DATABASE_SOUP ITEM instead?
is it OK to then describe this at a higher overall level (required performance, function etc) and let the exported SOUP list just tag which components are in DATABASE_SOUP so there's traceability there (I am not sure why having this repeated in the architecture document would make sense).
Secondly, how do you go about managing evaluating published anomaly lists and maintenance updates for so many individual components? The app is simple so most ITEMS will just be the same as the overall system safety class, so its not like I can argue theres lots of low/no risk ITEMS we can do less for.
But can you for example use your risk analysis and risk controls to identify specific SOUP components worthy of detailed followup and analysis (and drawing separately in the architecture)
I am guessing this is not a new problem!
It doesn't seem reasonable/possible to get that into the architecture, one by one in a diagram, and does it make sense to include as a list (client is exporting a document with a list of all SOUP items, with version numbers and website etc).
does it make sense to lump together these small components into a single "SOUP" item, lets say you have a DATABASE item in your architecture, group the relevant standard plugins or components into a DATABASE_SOUP ITEM instead?
is it OK to then describe this at a higher overall level (required performance, function etc) and let the exported SOUP list just tag which components are in DATABASE_SOUP so there's traceability there (I am not sure why having this repeated in the architecture document would make sense).
Secondly, how do you go about managing evaluating published anomaly lists and maintenance updates for so many individual components? The app is simple so most ITEMS will just be the same as the overall system safety class, so its not like I can argue theres lots of low/no risk ITEMS we can do less for.
But can you for example use your risk analysis and risk controls to identify specific SOUP components worthy of detailed followup and analysis (and drawing separately in the architecture)
I am guessing this is not a new problem!