OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/base_concepts/guidances/concepts/task.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?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>\base_concepts\guidances\concepts\task.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: task.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,7.624729048911575E-305 CRC: 4065096731 -->Task<!-- END:presentationName,7.624729048911575E-305 -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,7.624729048911575E-305 CRC: 4175284857 -->A Task describes a unit of work assigned to a Role that provides a meaningful result.<!-- END:briefDescription,7.624729048911575E-305 -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_zaqENNnmEdmO6L4XMImrsA CRC: 891996363 --><a id="XE_ACTIVITY__KEY_CONCEPTS" name="XE_activity__key_concepts"></a>
 <h3>
     Definition
 </h3>
 <p>
     A Task describes a unit of work. Every Task is performed by specific Roles. The granularity of a Task is generally a
     few hours to a few days. It usually affects one or only a small number of Work Products. Tasks are not necessarily used
     as&nbsp;a basis for planning and tracking progress - they are often too fine-grained for that purpose; Activity
     groupings of Tasks are often the better units for planning and tracking.
 </p>
 <p>
     A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models,
     classes, or&nbsp;plans. Within a Task, each performing Role achieves a well defined goal. A Task provides complete
     step-by-step explanations of doing all the work required to achieve this goal. This description is complete,
     independent of when in a process lifecycle the work would actually be done. Therefore, it does not describe when you do
     what work at what point of time, but describes all the work that gets done throughout the development lifecycle that
     contributes to the achievement of the Tasks' goal.
 </p>
 <p>
     When a Task is being applied in a Process, a reference object defined as Task Descriptor provides information, which
     includes what elements of the Task will actually be performed at that point in time. This assumes that a Task will
     usually be performed in the Process over and over again, but each time with a slightly different emphasis on different
     steps or aspects of the Task description&nbsp;as well as perhaps different or additional performing roles or different
     input/output (also refer to <a class="elementLink"
     href="./../../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html"
     guid="_94_eoO8LEdmKSqa_gSYthg">Key Capabilities of the Unified Method Architecture (UMA)</a> for the difference between
     Method Content and Process).
 </p>
 <h3>
     Steps
 </h3>
 <p>
     Tasks can be broken down into sections of Steps. A Step describes a meaningful and consistent part of the overall work
     described for a Task. Steps fall into three main categories:
 </p>
 <ul>
     <li>
         <b>Thinking</b> Steps: where the individual performing the Role understands the nature of the Task, gathers and
         examines the input Work Products, and formulates the result.
     </li>
     <li>
         <b>Performing</b> Steps: where the individual performing the Role creates or updates some Work Products.
     </li>
     <li>
         <b>Reviewing</b> Steps: where the individual performing the Role inspects the results against some criteria.
     </li>
 </ul>
 <p>
     Not all Steps are necessarily performed each time a Task is invoked, so they can be expressed in the form of alternate
     flows (similar to Use Cases).
 </p>
 <h3>
     Examples
 </h3>
 <h4>
     A Typical Task
 </h4>
 <p>
     A typical Task&nbsp;to "Develop Use-Case Model" would describe all the work that needs to be done to develop a complete
     use-case model. This would consist of the following:
 </p>
 <ul>
     <li>
         The identification and naming of use cases and actors
     </li>
     <li>
         The writing of a brief description
     </li>
     <li>
         The modeling of use cases and their relationships in diagrams
     </li>
     <li>
         The detailed description of a basic flow
     </li>
     <li>
         The detailed description of alternative flows
     </li>
     <li>
         Performing of walkthroughs, workshops and reviews, etc.
     </li>
 </ul>
 <p>
     All of these parts contribute to the development goal of developing the use case model, but the parts will be performed
     at different points in time in a Process. Identification, naming, and brief descriptions would be performed
     <strong>early</strong> in a typical development process versus the writing of detailed alternative flows which would be
     performed much <strong>later</strong>. All these parts or Steps within the same Task define the "method" of developing
     a use-case model. Applying such a method in a lifecycle is defining which Steps are done when going from one iteration
     to the next.
 </p>
 <h4>
     A Task and its Steps
 </h4>
 <p class="example">
     A&nbsp;typical Task to "Find Use Cases and Actors"&nbsp;would be decomposed into the following Steps:
 </p>
 <blockquote>
     <blockquote>
         <ol>
             <li>
                 Find actors
             </li>
             <li>
                 Find use cases
             </li>
             <li>
                 Describe how actors interact with use cases
             </li>
             <li>
                 Package use cases and actors
             </li>
             <li>
                 Present the use-case model in use-case diagrams
             </li>
             <li>
                 Develop a survey of the use-case model
             </li>
             <li>
                 Evaluate your results
             </li>
         </ol>
     </blockquote>
 </blockquote>
 <p class="example">
     The finding part [Steps 1 to 3] requires some thinking; the performing part [Steps 4 to 6] involves capturing the
     result in the use-case model; the reviewing part [Step 7] is where the individual performing the Role evaluates the
     result to assess completeness, robustness, intelligibility, or other qualities.
 </p><!-- END:mainDescription,_zaqENNnmEdmO6L4XMImrsA -->
 </body>
 </html>
	<?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>\base_concepts\guidances\concepts\task.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: task.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,7.624729048911575E-305 CRC: 4065096731 -->Task<!-- END:presentationName,7.624729048911575E-305 -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,7.624729048911575E-305 CRC: 4175284857 -->A Task describes a unit of work assigned to a Role that provides a meaningful result.<!-- END:briefDescription,7.624729048911575E-305 -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_zaqENNnmEdmO6L4XMImrsA CRC: 891996363 --><a id="XE_ACTIVITY__KEY_CONCEPTS" name="XE_activity__key_concepts"></a>
	<h3>
	Definition
	</h3>
	<p>
	A Task describes a unit of work. Every Task is performed by specific Roles. The granularity of a Task is generally a
	few hours to a few days. It usually affects one or only a small number of Work Products. Tasks are not necessarily used
	as a basis for planning and tracking progress - they are often too fine-grained for that purpose; Activity
	groupings of Tasks are often the better units for planning and tracking.
	</p>
	<p>
	A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models,
	classes, or plans. Within a Task, each performing Role achieves a well defined goal. A Task provides complete
	step-by-step explanations of doing all the work required to achieve this goal. This description is complete,
	independent of when in a process lifecycle the work would actually be done. Therefore, it does not describe when you do
	what work at what point of time, but describes all the work that gets done throughout the development lifecycle that
	contributes to the achievement of the Tasks' goal.
	</p>
	<p>
	When a Task is being applied in a Process, a reference object defined as Task Descriptor provides information, which
	includes what elements of the Task will actually be performed at that point in time. This assumes that a Task will
	usually be performed in the Process over and over again, but each time with a slightly different emphasis on different
	steps or aspects of the Task description as well as perhaps different or additional performing roles or different
	input/output (also refer to <a class="elementLink"
	href="./../../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html"
	guid="_94_eoO8LEdmKSqa_gSYthg">Key Capabilities of the Unified Method Architecture (UMA)</a> for the difference between
	Method Content and Process).
	</p>
	<h3>
	Steps
	</h3>
	<p>
	Tasks can be broken down into sections of Steps. A Step describes a meaningful and consistent part of the overall work
	described for a Task. Steps fall into three main categories:
	</p>
	<ul>
	<li>
	<b>Thinking</b> Steps: where the individual performing the Role understands the nature of the Task, gathers and
	examines the input Work Products, and formulates the result.
	</li>
	<li>
	<b>Performing</b> Steps: where the individual performing the Role creates or updates some Work Products.
	</li>
	<li>
	<b>Reviewing</b> Steps: where the individual performing the Role inspects the results against some criteria.
	</li>
	</ul>
	<p>
	Not all Steps are necessarily performed each time a Task is invoked, so they can be expressed in the form of alternate
	flows (similar to Use Cases).
	</p>
	<h3>
	Examples
	</h3>
	<h4>
	A Typical Task
	</h4>
	<p>
	A typical Task to "Develop Use-Case Model" would describe all the work that needs to be done to develop a complete
	use-case model. This would consist of the following:
	</p>
	<ul>
	<li>
	The identification and naming of use cases and actors
	</li>
	<li>
	The writing of a brief description
	</li>
	<li>
	The modeling of use cases and their relationships in diagrams
	</li>
	<li>
	The detailed description of a basic flow
	</li>
	<li>
	The detailed description of alternative flows
	</li>
	<li>
	Performing of walkthroughs, workshops and reviews, etc.
	</li>
	</ul>
	<p>
	All of these parts contribute to the development goal of developing the use case model, but the parts will be performed
	at different points in time in a Process. Identification, naming, and brief descriptions would be performed
	<strong>early</strong> in a typical development process versus the writing of detailed alternative flows which would be
	performed much <strong>later</strong>. All these parts or Steps within the same Task define the "method" of developing
	a use-case model. Applying such a method in a lifecycle is defining which Steps are done when going from one iteration
	to the next.
	</p>
	<h4>
	A Task and its Steps
	</h4>
	<p class="example">
	A typical Task to "Find Use Cases and Actors" would be decomposed into the following Steps:
	</p>
	<blockquote>
	<blockquote>
	<ol>
	<li>
	Find actors
	</li>
	<li>
	Find use cases
	</li>
	<li>
	Describe how actors interact with use cases
	</li>
	<li>
	Package use cases and actors
	</li>
	<li>
	Present the use-case model in use-case diagrams
	</li>
	<li>
	Develop a survey of the use-case model
	</li>
	<li>
	Evaluate your results
	</li>
	</ol>
	</blockquote>
	</blockquote>
	<p class="example">
	The finding part [Steps 1 to 3] requires some thinking; the performing part [Steps 4 to 6] involves capturing the
	result in the use-case model; the reviewing part [Step 7] is where the individual performing the Role evaluates the
	result to assess completeness, robustness, intelligibility, or other qualities.
	</p><!-- END:mainDescription,_zaqENNnmEdmO6L4XMImrsA -->
	</body>
	</html>