Guideline: Structuring a Practice |  |
This guideline provides recommendations for structuring a practice.
Main Description
### Structuring a Practice Structuring a Practice is where the elements of the practice and their relationships are defined. Specifically, structuring a practice involves: Defining the practice -- where the practice fits in the overall Practice Framework and what are its external dependencies Defining the practice elements -- what elements are contained within the practice and what are their relationships Categorizing the practice elements into standard and custom categories Each of these topics is described in the following sections. #### General practice structuring guidelines The practice structure must be developed within the guiding principles and constraints of the practice framework in which the practice resides. When structuring a practice, resist the temptation to enter detailed descriptions into the defined method elements. Instead, just name and briefly describe the elements and enter a few outline details, if they help to more clearly describe the element's basic definition. When structuring a practice, be sure to look for opportunities to leverage existing information in core elements and/or in other practices. If you find existing method elements in another practice that you would like to share, work with the method architects to get the common information moved to the core where it can be shared. Likewise, method elements should be defined to maximize reuse. If while structuring a practice you define an element that can be shared across practices, it should be defined in in the core where it can be shared, instead of in the practice. #### Defining the practice Defining the practice involves identifying, naming and briefly describing the practice, as well as defining the practice's position in the practice framework (i.e., defining the practice's external dependencies; what are the practice's relationships with other elements in the framework, including core elements as well as other practices). When defining a practice, it is important to explicitly define its inputs (Work Product Slots) and outputs (work products that fill slots), as well as any information (e.g., guidance, work product definitions, etc.) that is shared between practices. It is also a good idea to identify a candidate list of method elements the practice should contain. This provides more detail around the practice's definition. The practice contents will be further refined when the practice is designed. A practice name should be able to be used as a verb phrase – as in "we practice internal medicine", "we practice iterative development", "we practice component-based design", "we practice use-case driven requirements". Be sure to following the naming conventions for the practices. For more information, see the topic Method Element Naming Conventions in Guideline: General Naming Conventions. When defining practices, strive to minimize dependencies between practices (unless a practice is intended to enhance/refine an existing practice). To reduce the dependencies between practices, information that is shared between practices should be defined as an Work Product Slots and common guidance. Where necessary, practice elements may depend on elements in Core plug-ins (e.g., work product slots, common work products, common guidance, etc.), but ideally should not depend on elements in other practices (unless the purpose of the practice is to extend another specific practice). Remember, practices are intended to be independently adoptable and interchangeable, so limiting external dependencies is important. Any practice that is intended to be an alternative of another practice is not considered an extension/customization of the other practice. It is a practice in its own right. Practices are physically packaged in Practice plug-ins. Practice dependencies are represented as plug-in dependencies. For more information, see the topic Defining Plugins in Guideline: Creating Plug-ins, Practices and Configurations. #### Defining the practice elements Base definitions of practice elements are defined in Practice Base plug-ins. If you are customizing/extending an existing practice, then the definition of the elements that extend/customize the existing elements should be defined in Extend plug-ins. Defining the practice elements involves: Defining the practice method content elements and their relationships Defining the practice processes and what tasks they are assembled from Defining the practice guidance and associating the guidance with the appropriate method elements Each of these is described in the following sections. ##### Defining the practice method content elements A practice may contain any number of practice-specific method content elements. In most cases, however, the key elements of a practice are the work products it produces and the tasks that are performed to produce the work products. The following sections provide practice-specific recommendations for defining the method content elements for practices. If the elements to be included in the practice are extensions/customizations of existing elements (or are reusing existing elements in some way), be sure to note the use of variability and the dependence on the element being reused/extended/customized. ##### Defining practice work products Work products in practices may be defined to be used outside the practice, as an input to another practice, for example (externally-available work product), or may be defined to only be used within the practice ("local" work product). Local work products are defined within the practice and may be used as both input and output work products of practice tasks. Note: Tasks may produce the local work product, but another task must consume the local work product and produce an externally-available work product. Externally-available work products may be defined in either the practice or in a Core plug-in (of their definition is to be shared). No matter where they are defined, externally-available work products must fulfill a Work Product Slot. The fulfillment of the slot is defined within the practice (not in common). Externally-available work products may be used as inputs and/or outputs to tasks in the practice. Note: Even if they are defined in Core, these work products are still considered conceptually part of the practice. The only reason they are physically placed in a Core plug-in is so their definition can be shared. If the practice work products have significant states that must be recognized in the method (e.g., outlined, detailed, etc.), be sure to include the definition of those states in the work product description. You will also need to define a default role assignment for the work product (i.e., what role is responsible for the work product). For more information on roles, see the "Defining Practice Roles" section. ##### Defining practice roles Practices generally implement a Delayed Assignment approach for role assignments so that the practices can be reused in different contexts where the roles are different. Thus, in most cases, roles and role assignments (e.g., tasks to performing roles, roles responsible for work products) are not defined in the same method plug-in as the plug-in where the base practice elements are defined, unless a role is truly practice-specific. Role assignments for practices are usually defined in Practice Assign plug-ins. ##### Defining practice tasks All tasks are usually defined in practices. Very rarely are tasks themselves reusable enough to be in a Core plug-in. A recommended way to identify practice tasks is to identify the key states of the practice work products and then define the tasks so that each task takes a specific work product (e.g., artifact: Practice) to a specific state (e.g., designed, detailed). Tasks should also be named to reflect their purpose, so you may want to consider including the work product name and the intended state in the task name (e.g., design the practice, detail the practice). Using such a convention results in tasks with a good separation of concerns and with consistent granularity and scope across practices. Practice tasks that need information external to the practice should use Work Product Slots as input work products. They may also use practice work products as input work products. Practice tasks should only output practice tasks, not work product slots. Again, practices general implement a delayed assignment approach for roles, so the performing role for a task is generally not defined in the task definition itself. ##### Defining Practice Guidance A practice may contain any number of practice-specific guidance elements. However the following is the type of information that all practices should include: Goals of the practice Why anyone would want to adopt it (it's business value). What do you get when you adopt it? What problems does it solve? What is provided as part of the practice (i.e., the practice's bill-of-materials) What is the best way to read/navigate the practice (which elements and an what order). How to apply/adopt/implement the practice, including information on different levels of adoption, if applicable Additional information/references related to the practice (e.g., white papers, web sites, etc.) Practices tend to describe a specific technique for accomplishing a goal. Thus, guidance elements are a key part of a practice. However, some guidance can be reused across practices. Reusable guidance is packaged in Core plug-ins where it can be shared. A practice may reference such guidance (i.e., associate common guidance with the practice elements) and use it as if it was defined directly within the practice. In fact, such guidance can be considered conceptually part of the practice. Practice-specific guidance should be defined within the practice and associated with the method elements in the practice. ##### Defining practice processes Defining practice process is where you turn your attention to the process side of things. How should the tasks "flow" together? What tasks always appear together and in what order do they appear? Are there specific sets of tasks that can be reused together in more course-grained flows? It is a good idea for every practice to provide some capability patterns that describe how the practice elements can be used in a process. Practice-specific capability patterns represent the key things you can do (the capabilities you gain) when you choose the process. Defining practice processes defines an overall flow through the practice's content and validates that you have the right content with the right separation of concerns. In order to define a practice-specific process, you will need to define a process construction configuration that will serve as the default configuration for the process (all processes must have a default configuration). Name the process construction configuration to reflect its association with the practice. Practice processes should be role-agnostic, which means that the construction configuration should not include the default role assignments for the practice tasks. Specifically, the default construction configuration for practice processes should not include the Practice Assign plug-in. Assemble the practice tasks (and tasks in practices that the practice depends on, if any) into capability patterns. If appropriate, create additional capability patterns that leverage capability patterns defined in the practice and in other practices this practice depends on, if necessary. For example, an architecture practice adds a new work product and a new task to a basic development practice (thus the architecture practice depends on the basic development practice). Within the architecture practice you would define architecture-specific capability patterns using the practice tasks, but you may also define a few additional capability patterns that show how the architecture capability patterns could be combined with the basic development capability patterns. Such informational-like capability patterns have been referred to as "reference workflows" as they are not intended to be reused as-is in other processes; instead, they are to be used as an educational tool and may be mimicked in other processes. It is the practice-specific capability patterns (the practice's "key activities") that are intended to be reused in other processes. These guidelines provide practice-specific recommendations for defining processes. #### Categorizing practice elements Practice elements can be categorized into standard and/or custom categories. Each of these is described in the following sections. ##### Categorizing the practice method content into standard categories Practice method content elements should be categorized according to the standard categorization scheme defined in the practice library architecture. However, since practices usually implement a Delayed Assignment approach for standard categories, the assignment of the elements to a standard category should be done separately from the base definition of the practice element (i.e., in Practice Assign plug-ins). ##### Categorizing the practice elements into custom categories Practices may define their own custom categories (e.g., a practice-specific way to conceptually organize the practice content, etc.) or add their elements to an existing custom category (e.g., adding content to a custom category of a practice that this practice is extending, etc.)
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. EPF Copyright.