This material assumes that you are already familiar with UML, and you have seen the problems that usually occur in project development.
Most of the articles that I have read , offer you techniques on how to develop and conduct a project from beginning to the end , but most of them are very abstract. Do not believe that what I am about to write here is not abstract, but what I am trying to accomplish is a small index of ideas applied in iterative , incremental project development.
Maybe in your programming life you have seen all types of project management and development, most common being the cascade model: analysis, design, implementation, test, deploy. (I am not talking about projects that have no method, only get direct into coding from the first day). Because each stage must be completed before the next one can start, this leads to some serious weaknesses such as the fact that a large system cannot be fully understood in the first stages, or maybe some requirements change during implementation, and the current design must be changed a little. I remember, that someone said: The architecture in a project is the one thing that can be the hardest to be changed later. If there is some misunderstanding (not a big one) in what the customer needs , and we are in implementation phase (or worse, testing or even deployment ) we must go back to analysis, which in this approach is extremely hard to do.
Another approach is using the spiral model. You actually make the waterfall process over and over again , in smaller parts of the project (iterations) until the project completes. This is used somehow in Extreme Programming, but the main weakness of it is that JIT Designing (Just in Time Designing) does not offer you a system design at first, you design piece by piece but not the entire system. You might end up not being able to assemble the pieces together, later without an initial architecture of the project. With no concrete overall design, things can become chaos. However, there are many things which, if planned ahead, will only be re-designed later on.
I believe that the spiral model is an evolution of the cascade model, and an evolution of the spiral model is incremental, iterative model. This method addresses the problems with the spiral model. It is composed of 4 big phases: Inception, Elaboration, Construction and Transition. The spiral model is encapsulated in the construction phase.
Now let us take each phase and detail it some more.
The various phases
The inception phase, is the step that usually gives the vision and the goal of the project. Martin Fowler says that “during the inception phase, you work out the business case for the project-roughly how much it will cost and how much it will bring in”. Even this scenario can make up an inception phase of a project: Someone has an idea , he sits with some colleagues and over lunch he exposes his idea and his vision of the project, they contribute and make thing more concrete by making a (some) document that is forwarded to management. The management makes some preliminary evaluations of costs, marketing analysis and gives the go for the project. This is of course just a simple scenario.
This phase usually ends when the team has the go-ahead for the project. Usually in this phase, the following deliverables are made (if applicable , of course):
- a vision document
- an initial exploration of customer requirements
- a business case (financial details, marketing analysis)
- initial project plan
- initial risk assessment
About how much time, should inception be given, I would say that not too much (a few days, not more than a couple of weeks). Some say that about 10% of the project. Be aware, do not get explicit and deep into the project. That is what elaboration is for.
The elaboration phase: the purpose of this part is to get deeper into the project, analyze the problem, develop a project plan and eliminate the risks early in the project. At the end of this stage, the architects must have a good understanding of the project, but not ultra detailed.
Be aware, that it is very important to have a view of the project how the customer understands it, not how you understand it. This is actually, I would say, elaboration all about, understanding what the customer wants. This is the base of all evil, if customer requirements are not understood correctly. In order to do this , using UML (or whatever method you want, but I would recommend UML) with the customer, the entire project must be exposed in high and middle level use cases and conceptual models (other might call these analysis class diagrams).
It is important to cover up the whole project in use case diagrams. Do not get very deep into those diagrams, this will be done in construction phase but make sure that you have a good understanding of them as well as the customer. At the end of elaboration you should have the complete use case model for the system with as many diagrams as you want, but it is recommended not to abuse. One of my colleagues said about 30 is the maximum. Your system might be very complex, and the approach that I take is to make more general use cases such as:
This is then divided better during construction and analyzed in detail. You should be careful on using this technique. Before doing this ask yourselves which use cases should be in elaboration use case model, and which should be sent to construction.
Also develop the conceptual model as class diagrams, but be aware that the class diagrams that you design in this stage are not how software should be implemented, rather how the customer sees the concepts. In UML Applied (see at Resources) there is the following text about conceptual class diagrams: “If the customer doesn't understand the conceptual model, it probably isn't a concept”.
Martin Fowler recommends that you should design more conceptual diagrams each separated on a particular issue, and at the end unite them in a big one (or more). One other recommendation is to name each association with a very suggestive name. Avoid using “has”, “contains” because these are very poor names. A good example is in UML Applied:
At this stage you do not see classes , you see concepts and their associations in the mind of the customer.
In this stage you must also decide the risks of this project. What could go wrong? The bigger the risk you think of now, the bigger the attention you should pay it. Martin Fowler divides risks in:
- Requirements risks – good understanding of the system so that you do not build something different from whan the customer wants
- Technological risks – what are the risks associated with the tehnologies that you will use
- Skills risks – is staff prepared? How well?
- Political risks – are there political forces that could have an negative impact on your project
- A component diagram of the system.
Prototyping might help you analyze the risks better.
This risks should be well documented. A tutorial on risk management is not in the purpose of this article , for that I could recommend you to read more : UML Distilled, Martin Fowler, chap. 2
Now it is the time for you to prepare the next stage: construction. Construction is divided into iterations. Each iteration is composed of: analysis, design, implement, test. Now you will need to identify the iterations for this project. A good method is ranking the use cases in the use case model previously built. Give each use case a rank corresponding to the iteration in which it should be built. Usually, an iteration should be from 1 week to 2 months. Each iteration can contain one or more use cases for development. If a use case is big it can be divided so that can be integrated in more iterations.
A good practice is time-boxing each iteration. This means that each iteration should have a precise development time so you should be very careful when estimating with the developers how much time each use case will take, so that you can figure out how much the iteration will last. You are not allowed to slip any dates. Maybe you could move use cases further to other iterations. If too many times you slip the date , you should redo maybe the entire plan
Now if you have a use case model, a good understanding of the system , a conceptual model, a risk evaluation and the build plan (iterations for the construction phase), you can go to the next phase.
Construction phase. Each iteration is composed of:
- Analisys –. Detailing the use cases associated. This phase is about understanding the problem , rather then the solution. For each use case we must provide a short description (from evaluation) actors (same) requirements pre and post conditions , main flow, alternate flow and exception flow. To describe some flows you may use sequence diagrams. You might even try CRC cards.
- Design - decide what objects you need , what objects are responsible for what and when objects need to interact. For interaction I use Sequence Diagrams and Collaboration Diagrams. Transform the analysis diagram to a design class diagram. Add attributes, associations, navigability, determine visibility, determine aggregations and compositions.
- Implement I am a very big follower of unit testing, but it is not in the puspose of this material.
- Test. – be sure that everything was tested until you say that this iteration is over. Do unit testing, functional testing, stress testing etc.
It is very important to deliver the code tested, on time and documented for each iteration. Usually specialists say that evaluation should be 30% of the project and construction 50%. A word of advice: consider using well OO practices, unit testing, refactoring, patterns.
Transition phase - This usually means going from beta to release. No new features are added now, just optimizations, refactorings, tests , bug fixing etc. This phase also includes testing and feedback from client, writing manuals, training marketing people etc.
At the end of this phase a full running , tested, document product should be delivered. This is my introduction to Iterative, Incremental Framework for developing software projects using UML.
- UML Distilled, Martin Fowler 1997
- UML Applied, Adrianne Training, 2001
- From Waterfall to Iterative Lifecycle, Philippe Krutchen, 2000 – Rational whitepaper