This web page is a model of ISO 15288:2015 together with ISO 15289:2017.
We started from the pdf document of the ISO and imported them in arKItect using a python API for reading pdf documents and importing them into an arKItect database.
Here is a data visualization of the arKItect database provided for free by arKItect platform from which we made an HTML export.
Conventions are as follows:
- cyan blue boxes are processes according to ISO 15288
- leaf blue boxes are activities which means parts of processes.
- flows between boxes are items according to ISO 15289, e.g. documents delivrables resulting from ISO 15288 processes execution.
For obvious IP reasons, we did not display definitions and descriptions from the norms.
- when double clicking on a box, you go into that box and see corresponding sub-processes.
- by convention, flows names with same producer and same destination are grouped together.
- small white boxes correspond to input ports of flows that are not coming from an actor of the same layer.
- small black boxes correspond to output ports of flows that are not going to an actor of the same layer.
- question mark on ports ("?") means that corresponding flows are not produced or consumed.
- if mark "!!" is present on a port, it means it is a double production of flow. This is possible if in the norm, same deliverable is produced by different processes. This is possible e.g. "problem report" is produced and consumed by many processes, however they do not correspond to the same kind of problems and could be named differently accordingly.
- Especially in this model flow "problem report" and only this one has been hidden because it is produced and consumed by many processes and degraded the readability of the model.
As you will see, there are many inconsistencies in the model, mainly because the syntax is the norm is much more flexible than the one you need in a model. For instance, let's search all occurrences of "requirements specification" in the model, we get this list:
As you can see, we have six flows containing requirements specification, in each case they are either produced or consummed or both by some activities. Looking at them, you will see that some of them certainly match together, however they will be considered inconsistent in the model.
The point is this modeling is suggesting taking care about this in the norm itself. It's not that difficult to clean the outcomes and incomes of each activity in such a way that we know immediately for any deliverable item which process should produce and which process should consume, however at the moment, this is subject to interpretation.