| DEX (D003):— task_set | Date: 2006/06/14 12:04:07 Revision: 1.25 |
An application activity model (AAM) is provided in AP239 as an aid to understanding the scope and information requirements defined in AP239. The model is presented as a set of figures that contain the activity diagrams and a set of definitions of the activities and their data.
This DEX will support a subset of the activities and data flows. These are highlighted in yellow in the subsequent figures.
Activities and data flows that are out of scope of AP239 are marked with an asterisk.
Details of Perform Task Analysis
The activity model decomposes Design Support Solution into a lower level of detail. The details for Perform Task Analysis shown in figure 2 below.
Details of Define Potential Task
The activity model decomposes Define Potential Task into a lower level of detail. This is shown in figure 3 below.
The activity model decomposes Design Support Solution into a lower level of detail. The details for Define Support Solution shown in figure 4 below.
The activity model decomposes Define Support Solution into a lower level of detail. This is shown in figure 5 below.
The activity model decomposes Develop Support Plan into a lower level of detail. This is shown in figure 6 below.
The following terms are used in the application activity model.
action to assess the viability, risks and benefits of performing each task on different product groups or product versions, and in different locations, during different types of support opportunity
An applicability of classification can be defined for viable tasks in relation to the options above. Non-viable tasks can be referred for task evolution, or identified as candidates for resolution by embedded support features within the product. Embedded support features include:
action to define the specific product elements to which each task applies
action to define the method by which a potential task shall be performed, including sequencing of steps within the task, requirements for additional or consequential tasks, warnings and cautions applicable to the task, the identification of task predecessors and successors, the task pre- and post-conditions and the support resources required to achieve the task, including necessary skills and experience
NOTE This activity can include estimating duration and level of effort of task, assessing alternative methods for performing a task, including the task risks and consequences, and an assessment of the task viability in relation to available technology, past experience, and predicted costs. Non-viable tasks can be re-worked with a different task method, or can give rise to recommendations to the product designer for a design change to remove the support driver, or for incorporation of the task into the product functionality (embedded support capability).
action to develop a support solution definition for each deployment environment, by defining the tasks that may be performed and specifying the conditions under which each task falls due
This activity includes:
action to define the logical conditions that require a task to be done within a specific support solution definition and deployment environment, including a justification for the selection of the trigger, with appropriate reference to any analysis process that established the trigger condition
action to develop a support solution definition to meet requirements for each recognized deployment environment
This activity can include:
action to develop a resource consumption model for a potential task, including expected task duration and typical resource usage
action to develop a support plan option for each support concept to permit optimization of the support solution definition and raise work requests for the evolution of tasks where this is needed to optimize support
NOTE Each support plan should identify all tasks that can be required to satisfy the support solution requirements in the specified deployment environment, the logic through which tasks are combined or otherwise related, and the conditions under which each task would fall due.
action to develop and optimize the logic of a support plan by assigning tasks to product elements, setting task trigger conditions and rationalizing the grouping and sequencing of task in time and in space
action to define a task to the level needed to establish the task method and enable quantification of related resource requirements
If the task requirement can be met by more than one method, each method should be defined as a separate task. This activity includes:
action to identify each possible task that may need to be performed on the PIF by support participants in one or more of the predicted support and operational environments
This activity includes:
action to identify all the support resources that are needed to perform a required task and to compare required resources with resource items available, including the development of requirements for new or specialized resources that are not currently available to potential support providers
name and identifier of a task that is applicable to a given support solution definition
action to identify and define one or more economically viable and feasible support tasks to respond a support driver
Activity A2.3.2 addresses individual tasks and their resources. Integration of tasks to form a support solution is performed by activity A2.3.3. Task analysis includes:
collection of valid tasks that are applicable to a product in focus
NOTE Each task may be supported by a task description or task procedure, and by a task resource model. Task may be related to relevant support drivers and assigned to relevant product groups, versions, support locations, support opportunity type or class of task. The PIF task set may include tasks that are not used by any support solution definition such as commissioning tasks and tasks that are defined, but are not selected for use when the support solution definition is approved.
name, identifier and description of a possible support task
action to rationalize the set of necessary tasks and task triggers to develop a viable support plan for each product group, and support concept within a deployment environment
NOTE A further level of rationalization may be required across support plans and resource holdings across many product groups for the PIF as a whole. This activity is not made explicit in this AAM.
classification of a task based on its relevance to a PIF, a product group, a product version, a location or support opportunity type
NOTE Task applicability criteria may be extended or changed when the task is selected for use within a specific support solution definition.
definition of a method for performing a potential support task
NOTE The task description may include definition and quantification of the resources required to perform the task.
identification and quantification of the resources that are needed to perform an individual task
NOTE This may include definition of required skills and experience of required support personnel.
relationship between a necessary task and the product element, or elements to which it applies
conditions that require a task to be done, in the context of its assignment to a specific product element within a support solution definition
This DEX enables the transmission of a task specification. The data exchanged may be used as part of a support solution, e.g. a Prime Contractor developing a set of tasks for an aircraft. This assumes the target product and its next higher assembly have been identified. Also the End Customer has specified and communicated the supportability requirements as well as the deployment environment.
The result is a requirement to create, transfer, review and approve a task specification for a contracted item from the Prime Contractor. Information will be created including;