| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>openup&#92;disciplinegroupings&#92;&#92;openup_disciplines.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: openup_disciplines.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,__BZycP1UEdmek8CQTQgrOQ CRC: 1360917419 -->OpenUP Disciplines<!-- END:presentationName,__BZycP1UEdmek8CQTQgrOQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,__BZycP1UEdmek8CQTQgrOQ CRC: 2304953918 -->This is the list of disciplines in OpenUP, which help organize tasks.<!-- END:briefDescription,__BZycP1UEdmek8CQTQgrOQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_AYGfoP1VEdmek8CQTQgrOQ CRC: 4042675464 --><p> |
| A <a class="elementLink" href="./../../base_concepts/guidances/termdefinitions/discipline_7667F451.html" guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a> is a collection of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> that are |
| related to a major "area of concern" within the overall project. Grouping tasks into disciplines is mainly an aid to |
| understanding the project from a traditional waterfall perspective. Although it is more common to perform tasks |
| concurrently across several disciplines (for example, certain requirements tasks are performed in close coordination |
| with analysis and design tasks), separating these tasks into distinct disciplines is simply an effective way to |
| organize content, which makes comprehension easier. |
| </p> |
| <p> |
| Another reason that several tasks are all categorized by the same discipline is that they represent a part in achieving |
| a higher goal, or performing work tasks that are all related to each other. Every discipline defines standard ways of |
| doing the work it categorizes. Such standard ways are expressed by so-called <b>reference workflows</b> described with |
| <a class="elementLink" href="./../../base_concepts/guidances/termdefinitions/capability_pattern_F5DDC5F.html" guid="_2RUJACO4EdqaNq6Ptg8uyA">capability pattern</a>s, which define how the tasks categorized by the discipline work |
| together (in the most generic way). These reference workflows are often used for educating and teaching practitioners. |
| </p> |
| <p> |
| Like other workflows, a discipline's reference workflow is a semi-ordered sequence of activities, presented as either a |
| breakdown structure or an activity diagram performed to achieve a particular result. The "semi-ordered" nature of |
| discipline workflows emphasizes that the discipline workflows cannot present the real nuances of scheduling real work, |
| for they cannot depict the optionality of activities, or the iterative nature of real projects. Yet they still have |
| value as a way for us to understand the process, by breaking it into smaller areas of concern. |
| </p><!-- END:mainDescription,_AYGfoP1VEdmek8CQTQgrOQ --> |
| </body> |
| </html> |
