For the past 15 years, many proposed OO methodologies have sought to deliver full life-cycle support for systems development using OO tools. Many are highly prescriptive, that is, the methodology elements are highly interconnected. This inherent complexity makes it difficult for a methodology to be adapted to project-specific circumstances, especially (and usually) when project managers and developers are advised by the methodology’s creator that they must use all or none of the components of the methodology. Indeed, even with the advent of agile methodologies, frequently touted by their developers as offering more people-focus and flexibility, proponents often say an agile methodology like extreme programming (XP) must be followed in its entirety and that XP without, say, pair programming is not XP.
A less popular alternative is provided by way of the theory of method engineering, which subsumes process engineering and product engineering. While discussed in the academic literature and implicit in ISO standards like 12207, it does not seem to be widely acknowledged or practiced by software engineers. Method engineering offers flexibility but is often viewed (unfairly) as also having a costly overhead (in terms of time, money, and people). Method engineering contrasts with the use of out-of-the-box methodologies presented as ready for immediate use. The cost and effort to the organization are often totally ignored when such a prepackaged methodology is used and found to be an inappropriate description of the system-user company’s business processes.
Here, I explore (both theoretically and practically) the rationale behind a method-engineering approach, as well as its potential adoption by systems development teams.
Method Engineering
A methodology (or method) includes both process aspects and work-product descriptions. Considering not only the methodology per se but the components that go together to form it, we can use the ideas of method engineering to construct a full methodology from the elements, also known as method fragments. Typically, method fragments are stored in a repository underpinned by a metamodel. Situational (or situated) method engineering is defined as the creation of a method(ology) specifically attuned to the project at hand [1, 2, 11]. I refer to both kinds of method engineering—situational and nonsituational—under the generic label of method engineering.
Methodological approaches compatible with the theory of method engineering include Process Instance Evolution (PIE) [3], the ISO/IEC 12207 standard [10], and, in the OO arena, the Object-oriented Process, Environment, and Notation (OPEN) framework and the OPEN Process Framework (OPF) [4]. However, these approaches tend to focus on the process-engineering elements of method engineering and assume that the product side is addressed through modeling languages like UML. While ISO 12207 and OPF have many similarities in scope and granularity, the ISO model lacks a metamodel and adequate construction guidelines—both found in OPF.
OPEN Process Framework
As noted earlier, I bias my discussion of how to apply method engineering toward the more novel and interesting aspects of process engineering. The definition of “process” should include not only descriptions of phases, activities, tasks, and techniques but issues associated with human resources, technology, and the life-cycle model to be used. In contrast, the capability assessment and standards communities tend to use the term “process” at a smaller scale, more like “activity” in OPF and “discipline” in the Object Management Group’s Software Process Engineering Metamodel (SPEM). Defining process as the transformation of input to output (as in ISO/IEC12207 [10]), the notions of process and process improvement in many ISO standards and Software Process Improvement (SPI) contexts underline the granularity of interest often referred to as method fragment, method chunk (such as [11]), or process component (such as [4]). Here, I investigate how process engineering can be accomplished in the context of OPF.
The process is created by members of the organization itself, thus giving them ownership of the resulting OPEN process.
An important part of OPF is its comprehensive library of process components used in a variety of software projects and that cover changes in technology. OPF includes five major classes of these components (see Figure 1), all defined in the metamodel:
- Work Product. “A Work Product is anything of value produced during the development process” [4]. Work Products are the result of Producers (people) executing Work Units and are used either as input to other Work Units or delivered to clients. They also include externally supplied (such as by users) preexisting artifacts used as inputs to Work Units.
- Producer. “A Producer is responsible for creating, evaluating, iterating, and maintaining Work Products” [4].
- Work Unit. A Work Unit is a functionally cohesive operation performed by a Producer. The three major classes of Work Unit are Activity, Task, and Technique.
- Language. A Language is used to document a Work Product.
- Stage. A Stage is an identified and managed duration within the process or a point in time at which some achievement is recognized.
The OPF repository (see Figure 2) contains a range of predefined instances for each class and subclass in the metamodel; for example, there are about 30 predefined instances of Activity, 160 instances of Task, 200 instances of Techniques, and 76 instances of Role. In addition, users can add extra components from their own best practice.
Typically, someone in the development organization, in the role of process engineer or method engineer, selects appropriate process/methodology components from the repository and combines them to form an actual process within the methodology (see Figure 3). This procedure is often called process construction and may (in one step) create a project-specific process directly or a two-step process to construct first an organizational standard process and then a project-specific process. Construction decisions need to account for myriad variables pertinent to the development organization. Variables include, but are not restricted to, Capability Maturity Model level of maturity, available skills, available tools, quality desired, time scales, degree of ceremony, and number of people on the development team. While most process construction today is carried out by a specialist (the process/method engineer), emerging embryonic software tools assist this engineer in doing it effectively and efficiently.
Other ideas proposed in the academic literature not yet fully utilized include the Method Engineering Process Model of [11] and the method assembly rule set (specified using a formal language) of [1].
Each process component should be optimal, say, the best set of Work Units, Activities, Tasks, and Techniques. OPEN recommends construction of a number of matrices linking, for example, Activities with Tasks and Tasks with Techniques. The possibility values in these matrices indicate the likelihood of the effectiveness of each individual pair [8]. These values should be tailored to a specific organization or a specific project. While five levels—mandatory, recommended, optional, discouraged, forbidden—are recommended in published texts, I personally encourage individual organizations to use the matrices for process construction at the project level, perhaps using only two (use/do not use) or three (use/do not use/optional) values.
Table 1 outlines typical Task/Activity pairs for a hypothetical process to build a small piece of software when the requirements are fixed. I have identified eight appropriate Tasks for the six selected Activities. To fulfill these Tasks, a number of Techniques must be identified by the process engineer. In all, 25 are selected (in this example), as shown in Table 2. Finally, some time sequencing is added by using the Stage class of the metamodel, as in Figure 1.
The synergy between the stage view and the process elements results in an overall OPEN process that may be oriented toward a particular organization or project or, more broadly, a specific domain (such as Web applications, business reengineering, or real-time software) (see the sidebar “Examples of Method/Process Engineering” for application domains). Once developers determine which process they’ll use, this process is enacted on a real project (including a method/process instance, as shown in Figure 3) through the allocation of resources, including roles played by personnel and time scheduling, as well as money and hardware.
The method/process engineering approach has many advantages over an out-of-the-box approach. The process is created by members of the organization itself, thus giving them ownership of the resulting OPEN process; everyone has bought into it because they have had the opportunity to contribute to its formation. Along with local ownership, there is also global support because the framework and the repository from which the process was constructed are identical to the ones used by many other organizations worldwide. One can thus readily participate in user group meetings and forums. In addition, there’s a good chance that new hires will have the necessary skills gained from a worldwide community standard rather than from some idiosyncratic in-house approach.
There’s a good chance that new hires will have the necessary skills gained from a worldwide community standard rather than from some idiosyncratic in-house approach.
Finally, since many such process instances can be created from a common framework, process engineers can create a family of processes for various industrial demands, including, for example, safety-critical software, background financial processing, and real-time stock market modeling.
Figures
Figure 1. The five major metaclasses in OPF [
Figure 2. Creating an instance of a process from its metamodel [
Figure 3. Creating a project-specific process/method from the OPEN Process Framework.
Tables
Table 1. Task/Activity matrix example appropriate for a small process in which the requirements are set [
Table. New Work Units useful in Web development projects [7].
Join the Discussion (0)
Become a Member or Sign In to Post a Comment