Activity

Definition

Activity

the highest-level work unit that models a cohesive collection of one or more tasks that are performed by one or more collaborating producers when producing a set of one or more related work products or providing one or more related services related to a single management or engineering discipline

Also known as a ‘discipline’

An activity is cohesive in the following senses:

• An activity models a single, functionally-cohesive discipline that covers a single subject matter area.
• An activity is well known and widely-recognized with an industry-standard name, defininition, and scope.
• As a discipline, an activity typically has its own books, journals, conferences, and certifications.
• Traditionally (and prior to the recognition of the value of cross functional teams), the tasks of an activity have often been largely performed by a single role or job title.
• Major individual activities (i.e., direct subclasses of the activity class) may themselves be abstract superclasses that forms the roots of inheritance subtrees of related subactivities. For example, there are numerous kinds of architecting and testing.

Classification

As illustrated in the preceding figure, activity is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Work Unit
• Subclasses:
  • Management Activities:
    • Configuration Management
    • Digital Asset Management:
      • Content Management
    • Disaster Recovery
    • Management
    • Risk Management
    • Training
  • Engineering Activities:
    • Architecture_Engineering
    • Component Product Acquisition
    • Deployment
    • Design
    • Digital Branding
    • Environments Engineering
    • Implementation
    • Integration
    • Manufacturing
    • Metrics Engineering
    • Process Engineering
    • Quality Engineering
    • Requirements Engineering
    • Reuse Engineering
    • Safety Engineering
    • Security Engineering
    • Testing
  • Post-Development Activities:
    • Maintenance
    • Operations
    • Retirement
    • User Support

Activity by Phase

The following three tables document activity performance by phase.

Management Activities

The following table illustrates that management activities are typically ongoing during all phases:

Engineering Activities

The following table illustrates that some engineering activities are ongoing during all phases, whereas other engineering activities are typically performed during a small number of phases although even they typically overlap multiple phases:

Post-Development Activities

The following table illustrates the activities that occur primarily after development:

Responsibilities

The typical responsibilities of Activity are to:

• Enable process engineers to compose a process out of related activities.
• Organize related tasks into larger abstractions that provide a high-level viewpoint that is often easier to understand and manage than individual tasks.
• Enable a top-down process construction approach.

Guidelines

• Every endeavor typically involves the performance of multiple activities.
• These activities are typically performed in an incremental, iterative, concurrent, and timeboxed manner.
• Activities should not be confused with:
  • Phases, as was the case under the classic waterfall cycle. Activities refer to cohesive collections of tasks that are performed, whereas phases refer to a specific time frames and imply sequencing. Although the above activities are listed in roughly their chronological under the classic waterfall cycle, they actually tend to both overlap greatly in time and to cut across phase boundries because of the iterative, incremental, and parallel nature of most modern development cycles.
  • Tasks, which are components of activities. Sometimes, some tasks are so important and well known that individuals misuse the task name when they really mean the entire activity. Thus, you may hear someone say ‘requirements analysis’ when they really mean ‘requirements engineering.’
  • Processes, which are larger than activities and contain all kinds of process components such as work products, work units, producers, stages, endeavors, and languages. For every activity, a corresponding process [framework] can be created consisting of all process components highly related to the activity (e.g., work products produced by the activity, tasks and techniques performed during the activity, producers who perform these tasks and use these techniques, the stages during which the activity occurs, etc.).
• Dependency relationships between activities can be constrained by use of assertions (preconditions, postconditions) that result in a contractual delivery cycle.
• Activities typically consist of multiple tasks that are typically performed by multiple producers, although a single producer may take the lead and perform most of the work.
• On small, short, and simple endeavors, an activity might be composed of only a single scaled down task performed by only a single person (perhaps playing multiple roles on multiple teams).
• To provide process engineers with maximum flexibility during the instantiation of the OPEN Process Framework (OPF), any activity can theoretically be composed out of any set of tasks. However, activities should be cohesive, and the relationships between activities and their component tasks are therefore typically much more constrained. For example, requirements engineering is usually composed of requirements tasks such as requirements elicitation, requirements analysis, and requirements specification.