1.1 WHAT IS A METHODOLOGY?

Dictionaries often provide two basic meanings for the word “methodology”. On the one hand, a methodology is an approach to doing something; on the other hand, methodology is the study of methods. According to WordNet [17], a methodology is “the system of methods followed in a particular discipline”, a method being “a way of doing something, esp. a systematic one”. Also according to WordNet, methodology means “the branch of philosophy that analyzes the principles and procedures of inquiry in a particular discipline”. Therefore, the two possible meanings of “methodology” are:

• The collection of methods followed in a particular discipline.
• The study of methods followed in a particular discipline.

These two accepted meanings are closely related but are clearly different. The first one refers to a piece of information that describes how things are done within a given discipline. The second one refers to the activity of studying how things are done within a given discipline. The first usage is common and widely accepted, although the second one is closer to the etymological origin of the word “methodology” since the -ology suffix means “study of”, in Greek.

It is also worth emphasizing that the first accepted meaning, denoting a thing (a piece of information), corresponds to a countable noun: it is possible to speak about one methodology or multiple methodologies, and the article is always used in the singular (e.g. “this methodology is flawed”). The second accepted meaning, in contrast, corresponds to an uncountable noun, very much like “biology” or “archaeology”: we usually omit the definite article (“biology is exciting” rather than “the biology is exciting”). Most uses of the word “methodology” in the realm of engineering pertain to the first meaning; it is very common to hear people speaking about this or that methodology, but extremely uncommon to hear people saying things like “methodology is an exciting area to work in” (this would sound much better with any other “-ology” noun). This is a grammatical reason that supports the first meaning of “methodology” better than the second.

Also, the first meaning relates the terms “methodology” and “method” by a whole–part relationship (i.e. a methodology is a system or collection of methods), whereas the relationship implicit in the second meaning is much more complex (methods are studied by methodology). Interestingly, most uses of “method” and “methodology” in engineering tend to blur the semantic differences between them: a method is a systematic way of doing something and a methodology is a collection of methods, which, appealing to common sense, also defines a way of doing something. This fits well with the first meaning of “methodology” and is a semantic reason that supports the first meaning of “methodology” better than the second.

Finally, the second meaning of “methodology” pertains to philosophy and is rarely used without a connection to this field. Although modelling and metamodelling have strong connections to cognitive science and psychology, we believe that the three reasons here outlined are important enough as to encourage the adoption of the first meaning of “methodology” as far as engineering disciplines are concerned. Therefore, we can say that:

This definition places the concept of “methodology” very close to that of “method”; as we said above, a collection of ways to do things (“methods”, according to the dictionary) is also, using common sense, a way to do things. This means that, for practical purposes, and as far as this book is concerned:

1.1.1 Further Characterization

Let us dig deeper into the definition of what a methodology is. We will do this by analyzing the phrase “a systematic way of doing things in a particular discipline”.

To start with, and central to the definition, a methodology is a way. In other words, it is a manner, a means, a course of conduct. This means that no methodology is an end in itself but is a means to an end. It also means that, being a manner, it is arguable that other alternative manners also exist.

In addition, a methodology is systematic, i.e. orderly, planned and, at least to a certain extent, predictable. If we assume that methodologies are often shared by multiple individuals, this means that subjectivity must be reduced to a minimum in methodologies; otherwise, they wouldn't be systematic in an objective way.

Furthermore, a methodology is a way of doing things. This means that methodologies can be applied to change the state of the world that surrounds us (i.e. to do things), becoming the cause of effects that should be observable. If this were not so, the methodology wouldn't be doing things. Also, the things done by use of a methodology are the persistent outcomes of its application; the methodology is applied in order to obtain these outcomes. In other words, the things done by a methodology encompass the purpose of the methodology as a whole. The methodology is used because some community pursues that purpose.

Finally, any given methodology pertains to a particular discipline. In other words, it is focussed on a particular domain of knowledge and, consequently, works within a particular conceptual environment. In this book, our focus is the discipline of software engineering i.e. building a software application that meets the user's stated requirements.

As a summary, we can say that methodologies are used by communities that work in well-defined fields in order to produce persistent outcomes in their environment in an orderly and predictable fashion. For example, a team of software developers (the community) may use Extreme Programming [2] (a methodology) in the field of information systems development in order to produce a working system (the persistent outcome) by following some techniques, such as “pair programming” and “test first”, that are known to render good results (orderliness and predictability).

Since this book is about software development methodologies, we assume throughout that the well-defined field where methodologies will work is software engineering. It can be argued that most of the methodological knowledge in this area is also valid in related areas, such as systems engineering or even business-process engineering; we believe so but, in this book, we assume from now on that the methodologies we are discussing occur in the realm of software engineering. As a consequence, the community that uses a methodology is always assumed to be a team of software engineers or developers, and the persistent outcome that is pursued by the application of a methodology is assumed to be a software system, either a new one or a modification of a pre-existing one. Again, it can be argued that most of the knowledge related to the development of software systems can also be applied to the development and delivery of related services and even hardware.

There is one last issue to be considered before we can claim to have a complete characterization of software development methodologies. We have agreed that methodologies are used by software engineers in order to produce working systems; this means that methodologies must be usable by software engineers, with regard to both their content and form. This is the topic of the next section.

1.1.2 One Size Does Not Fit All

We believe that software development methodologies must be useful. If they are not, they will not be used and we will be wasting our time. Too often methodology books spend most of their life gathering dust on a shelf rather than being read, studied and annotated. For methodologies to be useful, we need to determine who their users are and focus on their needs. As we explained in the previous section, software engineers use methodologies in order to obtain software systems; these systems, however, can be of many kinds: embedded systems, database-oriented information systems, web applications, thick-client desktop applications, etc. Also, the teams and their context may be of very different sizes, hierarchical organizations, geographical distributions, skill sets and cultures. Other project parameters, such as calendar or budget latitude, requirements volatility and customer availability must also be considered. Given the large number of variables, it is clear that no well-defined set of needs can be clearly defined, at a useful level of detail, for the whole of the user community. The three major aspects (organization, project and product) can vary so much that the well-known adage “one size fits all” has often been reversed to convey that no single methodology can be devised so that it provides a useful systematic way of doing things in all software engineering endeavours [5].

Therefore, methodologies must be purpose-fit, i.e. adapted to the particular characteristics of the anticipated scenarios of usage. Of course, some compromises can be made; for example, it is easier to devise a methodology for the development of dynamic websites by co-located teams, regardless of the team size, than a methodology for the development of web sites, regardless of team distribution and size. As usual in engineering, the more specific the tool is, the more effective it can be – at the expense of constraining the range of its applicability.

There are two major ways of obtaining purpose-fit methodologies. The first is usually called tailoring, and is based on the adaptation of a pre-existing generic methodology to the particular needs of a user. “Tailoring” means adaptation or customization; this implies that some generic, template-like product must exist a priori, from which the final, purpose-fit product is obtained, e.g. [1]. Tailoring assumes that the fixed parts of a methodology can be clearly separated from the variable parts, because the template methodology that serves as input to the tailoring process must be defined without any specific knowledge of the properties of its future users. Often, this means abstracting out template elements and compromising on solutions that are either too abstract or, if concrete, out of scope. If a template element is very abstract, the tailoring process will have to make it more concrete by taking into account the needs of the user; if, on the contrary, a template element is not abstract but directly usable, it may well fall out of scope, since it will certainly respond to the needs of some users but not of others. As a result, the final methodology will, in both cases, be less than optimal. Also, there is a tension between the need to maximize tailorability, which pushes in the direction of abstracting out and making most aspects variable rather than fixed, and the need to provide a readily usable product, which pushes in the direction of making it concrete enough to be useful without modification and making most aspects fixed rather than variable. Tailoring is considered a viable approach to methodology development by many authors, being used by well-known approaches such as RUP [10]. However, each approach that uses tailoring as a purpose-fit mechanism must commit to a fixed compromise between abstraction and utility, which, once again, defines a supposedly universally applicable solution that should fit all.

The second possible approach to obtaining a purpose-fit methodology is called method engineering¹ [3; 11; 18; 19] and is based on the idea that methodologies can be dynamically assembled from pre-existing components according to the user's needs. With this approach, no templates exist; the only universals that are considered are fine-grained, self-contained method components that have been demonstrated to work well in different situations. A method component, therefore, is a small, reusable piece of information about a very specific aspect of a methodology (such as a particular task to be performed or a particular product to be used) that can be stored in a database to be selected and incorporated into a methodology as necessary. This approach benefits from a large degree of reuse, since method components are reused each time they are selected for a particular methodology and are evaluated when the methodology is used, thus establishing a feedback loop that can be used to alter the specification of a method component from the data obtained during its real-world usage (Figure 1.1). At the same time, this approach benefits from the fact that no pre-existing overall fixed parts exist, and therefore the assumptions that need to be made about the users of the methodologies are minimal.

An architectural simile is useful to understand the differences between these two approaches. The tailoring approach is akin to buying a house and refurbishing it by knocking down some walls and building a few extensions; the resulting house will be better suited to its owners than the original one but will always be constrained by the original assumptions and overall design. The method engineering approach, on the other hand, is analogous to defining what kind of house you would like to have, drafting some blueprints, obtaining the components (such as doors, windows, bricks and tiles) and building the house yourself. Although this is likely to be a more time-consuming task, the outcome will be optimally adjusted to your needs.

In this book, we adopt a method engineering approach because of its evident advantages. This approach, however, emphasizes an additional aspect of methodologies that must be considered carefully: if methodologies are to be created as complex assemblies of components, how is this done? Who should do it? What tools and techniques are available to do it? Following our previous example, an average citizen would not build a house herself, but would hire an architect; similarly, the role of method engineers, as the community that creates and maintain methodologies as first-order artefacts, must be introduced and its relation with the community of methodology users must be described.

Figure 1.1: Method engineering at work: the dashed line separates the domains of method engineers and software engineers; processes (such as “enactment” or “monitoring”) are indicated by arrows and labelled in italics; entities (such as “repository” or “endeavour”) are depicted as shapes and labelled in roman typeface

1.1.3 Communities and Uses

There are two contrasting communities of people that interact with and utilize software development methodologies. Firstly, and most obviously, software engineers use methodologies in order to create software systems. Secondly, method engineers create and maintain methodologies according to the needs of software engineers. Notice that the concept of a method engineer, i.e. a person who designs and build methodologies according to some well-known needs, is not peculiar to the software engineering discipline; any other discipline that uses methodologies may utilize this concept as well.

Some vocabulary must be introduced. Method engineers are said to construct methodologies from method components. Software engineers are said to enact methodologies on endeavours. Enacting a methodology means, basically, applying it to solve a problem of the kind that it has been designed to solve. An endeavour is the organizational and psychological scenario where the methodology is applied. Typically, endeavours are visible as projects, where a project has as its purpose the development of a software system. However, non-project endeavours, such as infrastructure management or organizational support activities, are also common. These are endeavours but not, strictly speaking, projects, so we will use the broader term “endeavour” rather than “project”.

An idealized method engineering scenario would appear as in Figure 1.1. The raw material that method engineers use is method components, usually stored in a specialized database often called a repository (some authors call this a methodbase). This repository contains tools that allow method engineers to browse and query the repository in order to locate the optimal components for a specific need. Tools are used to create new components, modify or delete existing components, transfer components between repositories and, in general, maintain repositories and components in good working order.

When a team of software developers needs a methodology, the method engineer negotiates with them a set of requirements for the methodology itself, requirements that are analogous to the requirements that a software engineer would gather and document from his customers and other stakeholders prior to constructing a software application. Thus, the method engineer gathers, analyzes, documents and validates a set of methodological requirements with the future users of the methodology and other stakeholders. These requirements are formalized and fed into some tool that assists the method engineer in the process of selecting the optimal components from the repository so that the best possible methodology is created. Not all the requested method components are necessarily available in the repository; sometimes, methodological requirements are so special or deal with such unexpected situations that some custom-made method components must be created by the method engineer for a specific endeavour. In this case, she may choose to incorporate them into the repository, so that future developments can benefit from them, or keep them “private” to the current effort. This has obvious parallels to the challenges of maintaining class libraries in object-oriented programming.

Once the methodology has been assembled, it is delivered to its users, in an appropriate form. By “appropriate” we mean a form that allows users to apply the methodology to solve problems (e.g. to develop software systems). A methodology that is delivered, for example, as a hard-copy document, can be used by software engineers only at a high cost, since they would have to read the document, make the correct interpretations and carry out the gathered instructions manually. A better delivery form would be an electronic specification of the instructions, which can be fed into an appropriate tool in order to be enacted in an endeavour. During the lifetime of the endeavour, the actual use of the methodology can be monitored by the same tools and the collected data sent back to the method engineers so that they can gain further understanding of how the selected method components operate in real-world conditions. From these data, they will be able to make the necessary adjustments to the method components, thus closing a loop. Thus, the quality both of the components and of the constructed methodology can increase in time. This means that this approach can provide an underpinning to the area of software engineering known as software process improvement (SPI).

From our discussion here and from Figure 1.1, it seems clear that the two communities involved in method engineering must be able to communicate fluently and as unequivocally as possible. Misunderstandings often arise when two different communities try to communicate, either because one community does not understand the meaning of some terms used by the other or because the first community uses the same term as the second one, but with a different meaning. An obvious way to combat this problem is to establish a shared, agreed-upon set of concepts and terms – often called an ontology – and use it systematically for every communication. It is worth emphasizing that not only must terms and concepts be standardized across communities, but also the mappings between them. This means that there is little value in agreeing upon the terms to be used and the major concepts in play if the relationships between the terms and the concepts they denote are not equally well defined.

An excellent example of terminology clashes is that of the ever-present term “task”. For a software developer or a software project manager (both belonging to the software engineering community), a task is something like a period of time, with well-defined start and end times and a duration in which a certain kind of work is done. Roughly speaking, a task is a bar in a Gantt chart. However, when a method engineer is using, for example, OMG's SPEM 2.0 [16], a task (interchangeably referred to as a “task definition”; see [16, p. 87]) is something along the lines of a description of the work being performed by a role. Notice the word “description”: for a software engineer, the task is the work actually being undertaken, while for a SPEM-oriented method engineer, the task is the description of what work must be done. These are different concepts, although the same term is being used.

A good test that can be used to verify whether two possibly different meanings of the same term are, in fact, different is to try to characterize each of the concepts using properties. For example, it is obvious that, for a software engineer, tasks have a duration. However, a SPEM-oriented method engineer would disagree; for her, tasks have a description. It is the instances of the task that have a duration. Relationships to other concepts are also useful in performing the test. For the SPEM method engineer, each task has a list of mandatory inputs and a list of optional inputs. The concept of “optional” is revealing, because it indicates that something is still to be decided at the endeavour level. In fact, for the software engineer, a task has a list of effective inputs, some of which would be considered mandatory by SPEM and others optional.

At the same time that we stress the differences between the two communities, we must also acknowledge the strong relationships that unite them. After all, a software engineering task is an instance of a SPEM method engineering task (task definition). As we saw with the mandatory versus optional inputs above, the meaning of “task” for the method engineer influences the meaning of “task” for the software engineer. In fact, it should be the other way around, since the software engineer is the user of the methodology and, as in any other engineering discipline, the user should be the one who determines the requirements of the product and therefore its overall semantics. In other words, the concepts used by method engineers to describe the methodologies that they will construct for software engineers must be chosen, shaped and adjusted according to the needs of the latter.

Both communities need to be able to describe the particular aspects of a software development methodology that they require. The software engineer needs to be able to access advice on what to do, how to do it, when to do it and who to do it. This advice may be available electronically or on paper. In both cases, the advice is in the form of a written description of the methodological element. For instance, it may be a description of the task of constructing a class model or how to use a technique such as robustness analysis; it may be a description of the role of a producer such as a business analyst or a description of an interim work product such as an agent class diagram. In contrast, the method engineer needs to be able to describe in a formal manner the concepts underlying the notion of task, technique, producer and work product.

Both communities fulfil their needs by the use of models. However, since the models used by the method engineer are at a higher level of conceptualization (often called, somewhat inaccurately, a higher level of abstraction), we will denote this specific kind of model by the name “metamodel” (where meta-indicates something “further” or “beyond”).

In the next section of this chapter, we will introduce metamodelling and its characterization and needs in a summary fashion before giving an in-depth presentation of modelling and metamodelling basics in Chapter 2.