Chapter 18. Creating Your Advanced Use Case Modeling Process

Consider all the activities and artifacts described in the previous chapters. Do you see how each one could be applied to your project? Are you mentally fitting them together into a process? Or perhaps you see the applicability of many of them but do not need all of them in your project. You might even be looking for the smallest subset of these artifacts because your project runs lean and mean. This has certainly been the desire in the modern trend toward lightweight software development processes. Or, you may feel that you do not know which of them would be applicable to your project.

This entire spectrum of feelings is determined by something called ceremony—“the practices and rituals that a project uses to develop systems” [Booch 1996]. Ceremony is the greatest influence on our ability to determine which artifacts we will use and which artifacts we should use in our project. Ceremony is the level of specificity required by the organization sponsoring the project (not necessarily your organization) and is determined by numerous characteristics of the project team and the project itself.

Ceremony is a continuum. At one end of the continuum is high ceremony. In high-ceremony projects, the number of artifacts is high. Changing an artifact is often very expensive relative to what is being delivered because of the redundancy (all of which is traced) between the artifacts. Changing one artifact usually requires changing others and may be more expensive than changing the product itself. The changes nearly always require review. The redundancy is built in for a reason: to reduce risk.

At the other end of the continuum is zero ceremony. Zero-ceremony projects have no artifacts. There is simply the deliverable and some independent, heroic workers who make the deliverable possible. All the knowledge associated with the production of the deliverables is in their heads, and the workers are essentially subject matter experts. The zero-ceremony project has one goal: creativity.

In the center of the continuum is medium ceremony. The medium-ceremony project balances risk and creativity. The medium-ceremony project may be the fastest approach for the large projects of today. Obviously, it is more efficient than the high-ceremony project. Less obvious are the advantages this project has over its low-ceremony brethren. Good communication is one of the most important dynamics in the development of today’s complex systems. The low-ceremony project communicates informally. This informal technique suffers from economies of scale, becoming less efficient as the project gets larger.

Optimum productivity comes from having the “right” level of ceremony for a project. Finding this level of ceremony can be as much of a learning process as the project itself should be. To find the optimum, start in the ballpark defined by the project and project team and increase or decrease the ceremony as necessary to increase creativity or decrease risk. Different parts of the project may have different levels of ceremony. For example, the process of prototyping requires maximum creativity. Keeping ceremony low for this deliverable is critical.

Effect of the Project and Project Team on Ceremony

The keys to determining the right level of ceremony for your project are its customers, the project itself, and the project team (both engineering and management). This is by no means an exact science. However, the following characteristics of your project can guide you in making this choice.

Project influences

• Criticality. Is it “life or death”? How bad is a failure? The worse the result of a failure, the higher you want your ceremony to be. To determine such an impact, look at your industry, government regulations (if any), and competition.

• Economics. As you approach the higher end of the continuum, things get more expensive and team members get less productive. Do not assume the contrary. Zero-ceremony projects are not necessarily cheaper, because they may have long-term or intangible costs, such as the costs of rearchitecting, reengineering, or customer dissatisfaction.

• Culture. Does your culture favor heroics by individual team members and few rules? Or is there a formal process for each task? Are you ISO-9000 compliant? Attempting a high-ceremony project with a culture that favors low-ceremony can be disastrous. The converse, attempting a low-ceremony project in a high-ceremony culture, causes confusion and team stress.

Project team influences

• Size. How many workers are involved in the project? As the size of the project increases, so must its ceremony. The zero-ceremony project cannot be scaled beyond a single team or perhaps as many as 10 workers. On the other hand, high-ceremony projects naturally require larger teams (or huge amounts of time) because of the overhead involved.

• Locality of developers. Collocation of workers is necessary for the communication required for lower levels of ceremony. As the team becomes dispersed or if the project spans multiple sites, the level of ceremony must be increased.

• Experience. A developer’s experience level is determined by how many projects the developer has worked on that have successfully employed use cases to deliver a useful business process, successful software system, or well-designed component system. The lower the experience level of the workers, the closer to the middle of the continuum the project should be. High ceremony and low experience is a recipe for project paralysis. Low ceremony and low experience can lead to a wild ride.

Effects of Artifacts on Ceremony

All major processes actually have two components: an engineering side and a management side. These engineering and management components are subprocesses, since they both have deliverables. Of course, many of us engineers (software, business process, or otherwise) know the management process to be overhead. And many of us managers know that no engineering would get done without our work. Right?

Grady Booch [Booch 1996] called these subprocesses the macro and the micro processes (Figure 18-1). The macro process is the management side and the micro process is the engineering side. This is like the yin and the yang. There cannot be one without the other.

Figure 18-1. Micro and macro processes

Booch wrote:

Use the macro process to control the activities of the project as a whole; use the micro process to iteratively carry out these activities and to regulate the future conduct of the macro process [Booch 1996].

Is there one macro process for the advanced use case modeling process or one for each phase? As each phase has its own stakeholders, each phase should have its own macro process. The macro process should be governed by those working on (managing and developing) the particular project. One major stakeholder is often the engineering effort upstream. The business process engineers may be waiting for a system that automates an activity of their new process. The software system may, in turn, be waiting for a set of software components.

The level of ceremony and the number of artifacts used on a project are directly related. The higher the level of ceremony, the larger the number of artifacts used. The lower the level of ceremony, the smaller the number of artifacts used. However, which artifacts should be used at which level? The answer to this question depends on the project as well.

The level of ceremony may be different in each phase of the advanced use case modeling process. It may also be different in the macro process (management) and the micro process software development. For example, the management level might be high for a medium-ceremony software development project. The extent to which the ceremony of the macro process influences that of the micro process depends on the ability of the management team to isolate development. If the manager of the medium-ceremony software development project did not isolate the software developers from the macro process tasks, the productivity of the developers in creating and updating artifacts of the macro process might be decreased. A general rule of thumb is to keep the project at a single level of ceremony.

Higher levels of ceremony of the micro process require more progress management than do lower levels. Paralysis is a well-known pitfall of high-ceremony projects. Details that would be glossed over in low-ceremony projects can be the subject of fierce debates in the high-ceremony project. The project plan is ideal for ensuring that the project does not bog down in the details. Lower-ceremony projects can often take off in an unanticipated direction if not properly focused. These projects require the guidance provided by a business or development case (Table 18-1).

Table 18-1. Suggested artifacts by level of ceremony

Software systems run the gambit of the ceremony spectrum. There are high-ceremony systems (such as an automatic pilot systems) whose failure could mean life or death. There are low-ceremony projects (some small financial systems written for a very specific short-term purpose) whose longevity is measured in days. Most software systems fall in the middle, employing medium ceremony.

Development Case

The development case allows you to customize the development process and its artifacts for your project [Kruchten 1999]. The development case outlines the steps involved in each activity and the creation of artifacts as the result of performing the steps. Key to the definition of a development case is an understanding of the level of ceremony to be used to balance creativity and risk.

Once the ceremony level is determined, the next step is to choose the activities and artifacts that you feel are most important to the success of your project. Since the development case is a macro process artifact, the activities outlined in it will be those to be performed in the micro or engineering process.

What’s in the Development Case?

The development case examines each view of the process and its constituent phases. For each phase, activities are defined. If each activity can be broken down into steps, the development case may include them as well. The development case mandates, recommends, or suggests the activities of and artifacts for the engineering process. It also defines the group or the roles of individuals involved with each of the steps. If the role is plural, the step may be the responsibility of a team (Table 18-2).

Table 18-2. Steps in the activity “Find actors”

Three categories of usage may be applied to a step or artifact: mandated, recommended, or suggested. If usage of a step or artifact is mandatory, then the use of that step or the creation of that artifact is required. All designated team members must perform the activity and must deliver their contribution to the artifact.

The second category of process element usage is recommended. In this category, a process step or creation of an artifact should be completed unless there is a good reason not to do so. Such a reason might be that the step is not applicable, the information derived from the step is trivial, or the same information could be obtained from another artifact (created earlier).

The final category is suggested. These artifacts or process steps are optional but are suggested as valuable in clarifying certain project characteristics. Process elements in this category might be applied only to those areas exhibiting these characteristics (examples include artifacts to address concurrency, real-time, or performance issues). Suggested process elements are often footnoted to indicate the type of characteristic.

Activities usually start with some information to be used as a basis or starting point. This information may have been created through another activity or it may be available from other sources in the organization. This information is captured as an input to the activity. Inputs may be mandatory, in which case the information is necessary for the activity to proceed. Recommended inputs should be used whenever possible, and suggested inputs are usually useful.

Each activity in the development case should culminate in the delivery of artifacts of measurable value. The role of each minor step is to add more information to the final delivery. If a step does not increase understanding of the system, the step is misplaced or should be omitted.

The usage of the artifact should correspond to the highest usage of any process step. Thus, a set of mandatory steps should not culminate in a suggested artifact, nor should a set of suggested steps culminate in a mandatory artifact.

The development case need not be elaborate. Each activity should be decomposed only to the level where a single group or individual is responsible for its completion and the same usage level is maintained throughout. Suppose that all three steps under “Find actors” were mandatory and performed by the use case brainstorming team. We could simply note in the development case that “Find actors” was a mandatory step to be completed by the use case brainstorming team.

Don’t be afraid to reference process descriptions that are available to the development teams involved (Table 18-3). The intent of the development case is not to write a process book. However, make sure any reference included in the development case is available to all process participants. There is nothing more frustrating than having to track down an obscure reference to understand how to do your job!

Table 18-3. Abbreviated version of an activity using a reference

Who Should Develop the Development Case?

The development case sets the tone for the project. The development case also enforces the ceremony. The more activities and mandatory artifacts, the higher the level of ceremony. The fewer activities and suggested artifacts, the lower the level of ceremony. The development case is one of the key inputs into the project plan. As you can imagine, a poorly thought-out development case can easily sabotage a project.

Experience is the key to creating a good development case. Experienced developers and managers know when to take risks and when to unleash creativity. They also know when to mitigate risk and when curtail creativity. Key to the development plan is an understanding of the ceremony levels corresponding to the customer and development team. Is it a brand new product unlike any ever delivered before? Is time to market the key requirement? Or is this a mission-critical system whose failure could lead to loss of lives?

Creating a development case should involve the most experienced people on the development and management teams. Achieving consensus is important, and the finished product should reflect the level of ceremony desired on the project, not a set of compromises. No matter how you approach the creation of the development case, members deciding which artifacts should be used should be the people who are actively working on the creation of that project’s deliverable. Having “skin in the game” is extremely important as characteristics of the project may be discovered that may lead to the need to revise the development case.

Iterative Development and the Development Case

The engineering process defined in the development case should not be performed in a waterfall fashion [Royce 1970]. At least some part of the project should be the subject of an iteration of the process. Iterative development is especially important if the process is new to the organization. Problems with the development process can be detected more readily if it is performed in increments.

The development case is a living document, as are the artifacts it contains. As the project proceeds, changes to the development case may be necessary to reflect increased experience with the subject matter being developed, increased experience with the development process, or the need to increase creativity or decrease risk.

A word of caution before proceeding to change the development case: Ensure that you are changing the development case for good reason. Many developers have changed a development case because they perceived lower ceremony to equal productivity increase. What they got from lower ceremony was lots of rework that actually cost them more in the long run.

One of the biggest reasons to change the development case is changes in the experience level. An inexperienced development team might have started with medium ceremony and learned the value of certain activities and artifacts that they had not expected. They might also downgrade the usage of activities they did not find especially useful. As teams become more comfortable with a development process, they tend to want to change it to reflect what they really do.

The best time to change the development case is between iterations in the engineering process. At this time, the entire process will have been tested for problems. Problems found in the development case can be corrected and these corrections can take effect in the next iteration.

Finally, those of you feeling overburdened by ceremony, take heart. For each of you there is someone who feels that there is not enough and that their project is flying by the seat of its pants. Achieving the right level of ceremony is a difficult undertaking and personal preferences vary.

Conclusion

One size does not fit all when it comes to a development process. This is because each organization and each domain is different. Therefore, each process must be customized. Creating a good development case with the right activities to model your domain and the right level of ceremony to satisfy your customers and development team is challenging. However, getting it right the first time is not necessary. Iterating over the development case as you would iterate any other aspect of the development project will help you zero in on the activities that are right for you.

To help you out in this regard, “typical” development cases for each of the phases of advanced use case modeling are given in Appendix B. To reflect the most common setting, the business process definition development case is high ceremony. The software system development case is medium ceremony, and the component development case is low ceremony.