4.1. Configuration of a Process

The process-components in the previous chapter provided the process building blocks. While these building blocks provide the necessary theoretical background for a process, they cannot be used directly in practice. The process-components must be combined or configured into a real Software Engineering Process before they can be used by a project manager. Configuring the process achieves the job of creating an executable process from the given process-components. This work is done by the process engineer together with the project manager and the quality manager. The activities and tasks related to this configuration of a process are also process based, and are described in the previous chapter under the process configuration process-component. Activities of process deployment and process enactment are also described in Chapter 3 as part of the dual responsibilities of a process engineer and the project managers.

Figure 4.2 [Henderson-Sellers and Unhelkar 2000] shows how a SEP is created from the process architecture. On the left side of the figure are the four major process elements (activities, tasks, roles, and deliverables). These process elements are described as cohesive components of a process in the previous chapters. These process elements, based on their process-components, are brought together in a complete process, or SEP.

Occasionally, techniques for performing tasks (or the guidelines that might be provided with a task) are shown separately. This is because in a high-ceremony process, external guidelines and techniques may deserve a separate discussion. Alternatively, the techniques are part of the tasks to be performed.

The right side of Figure 4.2 shows the fountain model that represents the iterative and incremental nature of the process (discussed later in this chapter). The job of a process engineer, together with the project and quality manager, is to bring the process elements and the iterative and incremental lifecycle together to configure a practical process. Such practical processes may be preconfigured for direct usage, or they may be created on a project-by-project basis. Examples of creating SEPs are shown in Figure 4.2 (for a problem statement on the Lucky Insurance case study, please see the accompanying CD). A LUCKY_SEP is created for Lucky Insurance's CRMS implementation. Other examples shown are the creation of a SEP for data warehouse implementation and one for an outsourced project.

The sample SEPs shown in Figure 4.2 are also made readily available by process tool vendors. In that case, they are called “off-the-shelf” processes. The architecture of these processes is prefabricated, making them available for use in practical projects. The current IT scene has a few off-the-shelf Software Engineering Processes that claim to provide the necessary support for object-oriented development that is iterative and incremental. They also claim to facilitate UML-based development. They include Rational's Unified Process (RUP), which is based on Jacobson et al.'s work [1999], also succinctly described by Kruchten [1999]. The OPEN Consortium has also put together a rigorous process [Graham et al. 1997] whose practical application is shown by Henderson-Sellers and Unhelkar [2000]. Other commercial processes include ICONIX and MeNtOR.^[1] The lightweight programmer-centric process called eXtreme Programming [Beck 2000] also deserves attention in any process talk, as it tries to kowtow to programming as the core activity of a project team.

^[1] MeNtOR is available on www.processmentor.com as well as on the owner company's home site on www.oopl.com.au. Currently, MeNtOR remains a pure practical process (as opposed to theoretical research and/or support of a published book).

In fact, numerous methodological approaches centered on programming and considered “light” by the methodology purists are now under the umbrella of “Agile” methodologies [Fowler and Highsmith 2002]. Despite differing weightings accorded by processes to programming and modeling, they all recognize the need to create some form of models before coding. Processes recognize what Barry Boehm [1981] noted two decades ago:

Only about five percent of the difficulty in software development lies in the code itself, with much more of the difficulty in specification and design.

These ready-made processes have their own strengths and weaknesses, which should be carefully considered by the process engineer, together with the project manager and the quality manager, before a process is procured and adopted. For example, some processes, like MeNtOR, are strong in the areas of requirements modeling, providing benefits in package-implementation projects that have relatively limited lower-level design activities. Rational's RUP, on the other hand, is tightly integrated with its UML CASE tool ROSE, providing the advantage of seamlessness between the deliverables produced by a process and the UML diagrams.

The type of project plays an important role when deciding which commercial off-the-shelf process should be procured. For example, a data warehousing project requires a process that focuses on multidimensional drilling of data and data conversion; not all ready-made SEPs can satisfy these special requirements.

Once the SEPs are created, they are able to outline the path to be followed during the enactment of the process. With UML-based projects in particular, the SEP, based on the activities and tasks belonging to the process-components, can guide the sequence of creating the UML-based diagrams. Creation of UML diagrams needs to follow certain steps. The UML standard itself, and eventually the quality checks of these diagrams and their models (available in the accompanying CD), do not discuss the sequence of creating these diagrams. A SEP provides that missing guidance in practice.

The project team has a number of choices when deciding the sequence of creating UML diagrams. For example, it is possible to start the process of software development with use case diagrams, which are then followed by the sequence and class diagrams, usually resulting in a GUI. This is shown as option (a) on Figure 4.3. Options (b) and (c) show different combinations and sequences of UML-based diagrams. On their own, these options are not good or bad—it all depends on which type of project will apply these SEPs.

In addition to putting together a full process based on the process-components, a SEP must consider the important aspect of the software development lifecycle (SDLC) on which it is based. We discuss these SDLCs briefly, before proceeding with configuring the process.

4.1.1. The Waterfall-Based SDLC

A waterfall lifecycle represents a linear phased approach to software development [Sommerville 1989]. A process based on this approach produces deliverables such as the analysis model, designs, code, and tests, which are sequentially dependent on the previous deliverable. For example, design, in such an approach, does not proceed until the analysis model is signed off, and coding proceeds only after the design is signed off. And just as a waterfall travels in one direction only (from top to bottom), similarly, software development proceeds in one direction with no opportunity of going back to correct or improve on the work done in the earlier phase.

Although the waterfall lifecycle itself does not prescribe ordering of the UML diagrams, any software-development process based on the waterfall approach can still be used in UML-based projects. For example, a process based on such a sequential approach and using the UML would perhaps recommend the creation of all use cases up front, followed by all the activity diagrams, and then the class diagrams and so on. Drawing of the class diagrams, in a waterfall lifecycle, does not proceed until all the use cases have been signed off. Such a process supports the production of one deliverable at a time, and is not able to facilitate user feedback and changes to the completed deliverables.

The quality-assurance activities in a waterfall lifecycle follow the production of the deliverables, and therefore focus heavily on quality control. The risks to quality are not so much the correctness of the deliverables produced at the end of each phase, but the appropriateness to the purpose for which the users want the system.

4.1.2. The Spiral-Based SDLC

Barry Boehm's view of software development was that it proceeds in ever-expanding spirals [1986]. He divided the software scene into four quadrants, namely:

• Determine objectives, alternatives, and constraints

• Evaluate alternatives; identify and resolve risks

• Develop and verify

• Plan next phase

Software development starts with activities in one quadrant, and follows in a spiral fashion, passing through other quadrants in expanding spirals. UML-based projects that follow this model produce deliverables at the end of each quadrant of activities. These quadrants within the spiral model provide the basis for repetition. However, the approach focuses more on how systems are implemented rather than providing a full iterative support in dealing with the needs of the users. Therefore, the quality risks, although mitigated compared with the waterfall approach, still exist.

4.1.3. The Fountain-Based SDLC

If water-based models are indeed considered appropriate to depict the software development lifecycle, then none come closer to showing it more faithfully than the fountain model [Henderson-Sellers and Edwards 1993]. Just as a water fountain rises to a height and then comes down again, similarly software development proceeds in an iterative fashion—reaching a certain height in terms of requirements, design, implementation, and testing, and then falling back into the development pool.

A software process based on the fountain model provides feedback to the users and, in fact, to all other players in the project throughout the development and across all deliverables. Such a software process incorporates the concepts of iterations and increments. Development in such an iterative and incremental process, even if following the phases, does not aim to produce a complete deliverable in one hit. Project managers accustomed to sign-offs at the end of each software phase have to readjust their views on sign-offs when they start following the iterative and incremental approach to software development.

Processes based on the fountain model mitigate the risks by ensuring that the development in the solution space is in accordance with the needs expressed in the problem space. Furthermore, the initial work in the solution space is used to influence the thinking in the problem space. This is made possible by demonstrating a small part of the solution to the modelers and the users in the problem space (by either actually developing that small solution, or by creating a prototype, or both) and receiving their feedback.