Do you really still think that for professional software development, what is necessary is only a method? In other words, have you ever tried to work in an environment with more than three persons?
Well, if you have, you perfectly well know that a lot of the project time is spent discussing topics not directly relevant to the project itself, fighting to convince others of your idea of the “right way” and waiting for “Executive Decisions”. And worse, any time a new project starts, the same topics are discussed over and over again.
Even with the introduction of a method most of the problems remain. A method doesn’t contain the necessary information to manage complex projects. It describes a notation (syntactically and semantically) and how to use it in a meaningful way during the typical development phases. But it doesn’t speak about teamwork, software reuse and software maintenance. The logical consequence: confusion, loss of time, and different not homogeneous or integrated solutions, working in parallel for every different problem.
Moreover, a method is not flexible enough. Because it has been defined by a method specialist working somewhere else, who simply cannot know or foresee the requirements of every development environment.
It is really time to get rid of the weak method and think about something that completely covers the needs of professional software development. Actually, there is only one possible alternative: before starting anything, we have to define a development process.
A development process is the only correct approach to software development. A development process is a way to organise people, information and tools. Activities are distributed to people, information is organised and tools are used to support the work. But most importantly: the process describes the way to reach the global goal.
Great! Does it mean that now we have a solution to all our problems? Wrong. The real problems have still to be solved.
The concept “development process” is still something generic and subjective. A development process can be interpreted in many ways by different people and can have different results when used in different environments.
But all these problems are also well known as method problems. So, what is the big deal? We try to get rid of something, but we find something different with the same problems? Of course not.
Of course, as already said, the advantage to have a process is the opportunity to organise and manage a multitude of activities in a seamless way. But the even more evident difference, compared with a method, is that a development process now can and has to be determined by the people that are going to use it. So, after we have defined a development process, the next action to take is to describe the development process, known also as “Development Case”. In the description, we are giving precise indications about the way how to organise the work, how to organise and transform the available information and what kind of tools are necessary and how to use them for the development of the system.
The advantage to have a “Development Case” is that the process description is something in our hand and it is alive: it grows and changes to adapt to new situations and demands.
Moreover, a process description is something concrete that has to be used as a reference and not as a starting point for new discussions. At least not while a project is running. Process modification and/or enhancement is of course necessary, but it is an error to change the process while a project is in progress. Changes have to be defined, described, discussed, implemented and tested. This is a full time activity that runs in parallel with normal projects. The process development gets input from the running projects and prepares a new process release to be used when a new project starts.
That is fine, but I can already hear your next question: “Can anybody define a process? Does a good template we can use already exist? Do right processes and wrong processes exist?”
Defining a good process is not a trivial activity, because of its intrinsic complexity. That’s the reason that so called “process templates” are available, to be used as starting points. One of these process templates is also the subject of this paper.
But for the moment, let us take a step back.
We have reached a point in the software development history where too many discussions and fights have been going on, to find out if it is better to represent a class using a cloud or a rectangle. Another favourite argument of discussion has became if a rich or a less rich notation is better. Moreover, I think everybody has realised that even the best notation is not perfect and that it would be nice to be able to adapt it to the needs of the particular project or development environment.
The history is going to change. Not only has the focus changed from method to process but also from notation to a much more powerful Modelling Language to support a flexible and extendible OOAD Meta-Model.
That’s the reason why the Unified Method has become the Unified Modelling Language (UML). UML is the first step in a new way to think about software development. The software designer has now in his hand a way to define the best modelling environment and notation to support its requirements.
Of course this is only the first step, and even though very important, it is still the development process that is the engine for our software development.
The logical consequence is that after the definition of the UML the effort now is concentrated on the definition of a process template, supported by the modelling language, that guarantees the same flexibility and extendibility.
From the description point of view, the difference between the modelling language and the process is that the language is more formal. A process cannot be simply formally described because of the infinite number of variables in play.
Different processes have been defined and used more or less successfully. Any process anyway contains a well defined structure based on its three fundamental components:
The algorithm also produces intermediate results that document the process internal steps.
The Process, Input, Output and Result will be documented using the modelling language. It is of course up to the process to decide if the modelling language has to be extended to meet the requirements of the process itself.
We must not forget that a process can also be split into multiple sub-processes so that the complete process is simply more manageable, and information modelled during the process doesn’t get lost. Any sub-process is anyway defined and organised like the main process. The only particularity is that the output of one sub-process is defined to be ideal for the following sub process. Again it is up to the process to decide if it is necessary that the modelling language should provide different notations and semantics for the different sub- processes.
The process I am going to introduce in this paper is a process based on the Objectory Process developed on the original idea of Ivar Jacobson. I will not discuss the whole process, but I will concentrate on the part that I consider the most important and innovative.
We are going to speak about Use Cases and their influence in the development process.
But before we start, let me introduce to you the CRUNCHER.
A CRUNCHER is a major component in a process: it receives information in input, starts to crunch it and produces the expected result. What is contained in this result? New information? No, the result contains nothing else than the same information, only in a new elaborated form. We should never forget that it doesn’t matter in which part of the process we are, the information flowing through the CRUNCHERS is always describing the same system. Their form and representation is different, but the system described is always the same.
So the CRUNCHER is responsible to modify information, but it is still a “Mechanical” component. The good use of the information produced is again the responsibility of the process: it collects this information, certifies it, extends it if necessary and organises it to be ready for the next CRUNCHER.
Now back to our process template based on Use Cases. Use Cases play a big role in the over all development process, as we will see, but the place where they are defined and described is the Requirement Analysis sub-process.
One of the main problems in Software development has always been to understand the real user’s requirements and to reach an agreement on what the software system has to provide.
For this reason the Requirements Analysis sub-process uses a CRUNCHER specialised in Use Cases production. In input the CRUNCHER gets information from different sources:
We know that this is a huge amount of information often redundant, often incomplete, often generic. We also have the problem that hidden between system architecture, design, implementation information, are the real specifications of the system.
The Use Case modelling CRUNCHER is able to identify this information, to help the process user to complete it and to sort it in the correct category. Some of the information sorted by the CRUNCHER is not interesting for the software system, like business information. Other information is interesting later in the development, like system architecture and graphic interface specifications.
Of course, all this information is important and useful but the output we are looking for from the CRUNCHER are Actors and Use Cases. An Actor is defined as in [Jacobson]: ”A system’s user type or category. The Actor models anything that needs to exchange information with the system.”. A Use Case is defined as: “A specific way to use the system by performing some part of the functionality. Each Use Case constitutes a complete course of events initiated by an actor and the system. A Use Case is thus a special sequence of related transactions performed by an actor and the system in a dialogue. The collected Use Case specifies all the existing ways of using the system.”. At the end, the sequence of transactions produces a valuable result for the Actor which started the Use Case.
Concretelay, a Use Case will be described by way of a document. The document describes exactly the interactions between the Actor and the system and what happens in the system between the interactions.
The CRUNCHER will produce a document for every Use Case found. The process then will use these documents as a concrete representation of the system functionality, to be presented to the system’s contractor. The Use Case description is used as a means to check the completeness and the correctness of the user system functionality requirements. The process is of course iterative.
In other words, from the contractor’s point of view, the documents are a way to reach an agreement between contractor and system development, on the functionality that is going to be implemented.
But this is one side of the story. As soon as a set of Use Case’s descriptions have been accepted, the class modelling can start. The modelling will use the Use Case’s description as a functional specification and start to model the system one functionality a time. Also for this activity that actually belongs already to the next sub-process, a CRUNCHER is defined to help in the transformation of a text document into a class model. The process is then responsible to manage the multiple class models produced by the CRUNCHERS in a well structured global class model.
Does the Requirement Analysis sub-process finish, as soon the Use Case has been completely described? Of course not.
Changes in the requirements as well as new requirements are always possible in every software system. New requirements, as you can imagine, are very good candidates for new Use Cases. Anyway, more interesting is what happens when a requirement changes.
With a software development process based on Use Cases the way from the requirement to the class model is no longer hidden in the brain of some smart class specialist - who could not be available - but is well documented and traceable through the Use Case Model.
What we have to do is to put the changed requirements into the CRUNCHER and get the reference to the Use Case(s) where the requirement has been used. The next step is to put the new modified Use Case into the next CRUNCHER and find out the set of classes responsible for the modelling. The right classes will be modified according to the new Use Case’s description and the system will be newly generated. At the end, the process will test whether the new release of the system works exactly as specified in the Use Case description.
Use Cases are active through the all software development process. They work as an information source and they trace the right information in the right output or result of the process: from the functionality definition, through the class modelling (both static and dynamic-behavioural), the system functionality test and as a model for the User Reference Manual, until the maintenance and the extension of the system.
We have seen that Process and not Method is the decisive means to manage a software project. To represent the information the process produces, we have also seen that a flexible and extendible modelling language is necessary and that the final result of the process we are going to produce depends on the CRUNCHER we will use. In other words, define our goal, with the same information we can get different views of the system. We have also seen how Use Cases play an important role as a traceability link through the whole process.