In a nutshell
A work process describes the steps that need to be performed in order to reach a given goal. The steps are usually described as if they were performed sequentially, while in reality they are performed in an opportunistic sequence and often in parallel. Documentation and other deliverables are the concrete results of the work process. It is often useful to pretend that the deliverables are the results of a rational work process because this makes them easier to read and understand.
There are work processes on many different time scales. We have found it convenient to distinguish between three: creating a model, creating an application, and creating a reusable component.
A work process is a sequence of steps that need to be performed to reach a specified goal. The process itself is almost invisible to all but the people who actually perform it. The process steps should therefore be intimately associated with the deliverables that constitute their concrete results. The deliverables can be computer programs, formal models, or informal descriptions.
A work process describes the steps needed to reach a goal
Processes on different time scales
Processes can be on different time scales, ranging from short processes for the solution of specific details to very long term processes covering the evolution of reusable assets. We find it convenient to distinguish between the following processes:
The model creation process focuses on how to create a model or some other manifestation of thoughts for a certain phenomenon. Examples are processes for creating a role model, for performing role model synthesis, and for creating object specifications. 1.
The system development process covers the typical software life cycle. It consists of the steps from specifying users needs to the installation and maintenance of the system that meets these needs. 2.
3. The reusable assets building process is the least mature software engineering process, but we expect it will be an essential
contributor to future productivity and quality. Our focus is on the continuous production of several, closely related systems; where we build on a continuously evolving set of reusable components. Creating a system will mainly be a case of configuring and reusing robust and proven components; possibly adding a few new components to complete the system.
29 March 1995 23:05 1.3 Process with Deliverables
The processes are opportunistic and iterative
The work processes on all three levels are iterative and the deliverables evolutionary. The goal is to minimize the risk by focusing the most critical parts in the early iterations.
Many managers dream of the ultimate work process that will ensure satisfactory solutions from every project. We believe that this dream is not only futile; it can even be harmful.
Documentation is by its nature linear and must be strictly structured. Software development processes are by their nature creative and exploratory, and cannot be forced into the straightjacket of a fixed sequence of steps. In an insightful article, [Parnas 86] states that many have sought a software process that allows a program to be derived systematically from a precise statement of requirements. Their paper proposes that although we will not succeed in designing a real product that way, we can produce documentation that makes it appear as if the software was designed by such a process.
The documentation is sequential
The sequences of steps we suggest in the following and in the rest of the book are therefore to be construed as default work processes and suggested documentation structures. We also believe that you will have to develop your own preferred sequence of steps, but you may want to take the steps proposed here as a starting point.
1.3.1 Introduction to the model-creation process
How should you go about describing a phenomenon in a role model? In the general case, we suggest the following eight steps for creating a role model. Each step results in a deliverable, which is a view on the role model. The relative importance of these views depend on the purpose of the model.
Eight steps for developing a role model
The steps are performed iteratively until the role model is adequately defined. Steps (4) and (5) are performed in parallel. It is often easier to see what needs to be done than to identify the actors, but both need to be specified in an object-oriented model.
Determine the Area of Concern
(1)
Understand the problem and identify the nature of the objects
(2)
Determine Environment roles and Stimulus/Response
(3)
(4) Identify and understand the roles
29 March 1995 23:05 1.3 Process with Deliverables
(5) Determine the message sequences
Determine the collaboration structure
(6)
Determine Interfaces
(7)
(8) Determine the role behavior
With the OOram method, you can describe your analysis and design in a single role model or in a number of related models. There are general process guidelines for creating the individual models, and for breaking complex situations into smaller models that "are so simple that there are obviously no deficiencies".