| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmi:id="_zag6Q9nmEdmO6L4XMImrsA" name="discipline,3.409251897849429E-305" guid="_zag6Q9nmEdmO6L4XMImrsA" changeDate="2005-10-28T23:12:26.440-0700"> |
| <mainDescription><a id="XE_DISCIPLINE__KEY_CONCEPTS" name="XE_discipline__key_concepts"></a> |
| <p> |
| A Discipline is a collection of Tasks that are related to a major "area of concern" within the overall project. The |
| grouping of 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 all represent a part in |
| achieving a higher goal or performing work that is all related to each other.&nbsp; Every Discipline defines standard |
| ways of doing the work it categorizes.&nbsp; Such standard ways are expressed by so-called reference workflows |
| described with <a class="elementLink" |
| href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html" |
| guid="1.7072348895114264E-305">Capability Pattern</a>s defining how the Tasks categorized by the Discipline 'work |
| together' in the most generic way.&nbsp; 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 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> |
| <h4> |
| Example: The role of Disciplines in Software Engineering |
| </h4> |
| <p> |
| In Software Development, each Discipline has associated with it one or more 'models', which are in turn composed of |
| associated Work Products. Some fundamental disciplines identified in Software are: |
| </p> |
| <ul> |
| <li> |
| Business Modeling |
| </li> |
| <li> |
| Requirements |
| </li> |
| <li> |
| Analysis and Design |
| </li> |
| <li> |
| Implementation |
| </li> |
| <li> |
| Test |
| </li> |
| <li> |
| Deployment |
| </li> |
| <li> |
| Configuration and Change Management |
| </li> |
| <li> |
| Project Management |
| </li> |
| <li> |
| Environment |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |