Differences

This shows you the differences between two versions of the page.

--- 78:process_architecture [2022/01/31 12:38] – sph
+++ 78:process_architecture [2024/02/15 00:00] (current) – external edit 127.0.0.1
@@ Line 7: / Line 7: @@
 {{  https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/75/processarchitecture4.png?nolink&1000x239  }}
-Above is an example of process architecture. Since common elements like phases & milestones, common roles (e.g. stakeholders) are defined at the corporate level, they have been defined in a workspace called ‘Lifecycle Management’. The other process areas directly interface with process elements in this workspace.
+Above is an example of process architecture. Elements like phases & milestones or value streams have cross-process validity. They are defined in a workspace called ‘Lifecycle Management’. The other process areas directly interface with  elements in this workspace, e.g. associating work products with milestones.
 Furthermore, all the process areas (including Lifecycle Management) are integrated into a single Standard Process workspace called ‘Software Engineering’ which contains all their process elements (workflows, activities, roles, phases & milestones, work products, and guidance).
@@ Line 73: / Line 73: @@
 In the image below, “Program A” needs to have interfaces with “Component A1 Hardware” and “Component A2 Software”, but not “Component B1 Hardware”, “Component B2 Software”, or “Component B3 Software”, even if the same process modules are integrated there.
-[[https://doc.stagesasaservice.com/lib/exe/fetch.php?tok=7dd61d&media=https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/78/multilevelprogram.png|{{https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/78/multilevelprogram.png?direct&800x381}}]]The above structure can be correctly instantiated **by using workspaces collections** to control the creation of interfaces. By creating workspace collections depicted by the colored dots in the image above, the interfaces will be correctly created, because **all workspaces within all collections of the current workspace** are being searched for interface candidates. The interface search uses internal identifiers instead of just names, which makes it very robust and allows the workspaces to have arbitrary names.
+[[https://doc.stagesasaservice.com/lib/exe/fetch.php?tok=7dd61d&media=https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/78/multilevelprogram.png|{{https://doc.stagesasaservice.com/lib/plugins/ckgedit/fckeditor/userfiles/image/78/multilevelprogram.png?direct&800x381}}]]
+The above structure can be correctly instantiated **by using workspaces collections** to control the creation of interfaces. By creating workspace collections depicted by the colored dots in the image above, the interfaces will be correctly created, because **all workspaces within all collections of the current workspace** are being searched for interface candidates. The interface search uses internal identifiers instead of just names, which makes it very robust and allows the workspaces to have arbitrary names.
 In addition, this allows the same process module to be integrated into different workspaces with different tailorings. For example, the “Component B2 Software” and “Component B3 Software” workspaces can have the same software development process module integrated but might have different tailorings or even different versions of the same module, and it will correctly interface with its parent “Program B” workspace.