Which Models Do You Need?
This question is a loaded question. It is one of the most difficult questions to answer for a software development team. In fact, I think most people don't choose consciously. This is a very hard question to respond to. Why is it so?
First of all we obviously need to understand who "you" are? You are usually many different types of stakeholders. We have the customer, its users, the vendor (selling to the customer), the project manager, and the development team. The development team may be few individuals but they work with many things: requirements, analysis, architecture, design & implementation, test, etc. I say that the developers play many distinct roles. Individual developers have different skills. We need to be sure that our people will acquire the skills they need to do the job. Even for small products, we can't expect everyone to be equally skilled. Each of us will have our special skills.
Thus first we identify who you are. We may map that to what each one of you can work with – what artifacts each individual can produce or what roles he or she can play. We may have found these roles or artifacts from a process like the Unified Process. If there is a mismatch between the skills and the requested roles, and there usually is, then we can either simplify the process or raise the skill level of your people. The latter means education. The former means making the process lighter. We should always make the process as light as possible – but not lighter. Unfortunately many teams choose a too light process. The consequences being reduced quality or increased cost. A too rich process is not good either – it will also have negative impact on quality or costs. It is about rightsizing.
Once we know who "you" are, we can identify your needs. You obviously need code, but do you need more. Today every serious project needs more. We need more to make sure that everyone of "you" will be able to participate in the product development – something that over time may go on for more than ten years if successful. Everyone needs to be able to contribute. The customer and its users have their legitimate roles; they need to decide what they want, and verify and validate that they get what they want. The project manager needs to understand what artifacts are produced and how they are related – he or she mustn't be overloaded with information. The programmer needs to get clear requirements, s/he needs to produce testable result, s/he needs to identify what is reusable, etc.
Thus "you" need more than code. This more is models for each and everyone of "you". We could of course follow this line of thought and derive what models we need dependent on who "you" are. This becomes quite academic and I won't pursue this now and here.
Which Models Should You Choose
If we ignore business modeling (which we shouldn't) and ignore user experience design (which we shouldn't) and only care about the forward engineering chain from requirements to code, then I would recommend you to always start thinking of using the following models: use case, analysis, design and implementation (code). I would make test artifacts part of each model – each model has to verified and validated. You may later come up with a different set of models, but you should start from these models to really understand your choices and your decisions.
In the Unified Process we have given meanings to these models, we have identified the relationships between them, how you move from one model to the other, what transformation rules to apply, etc. If you take away one of these models, for instance the analysis model, then you will have to move work that you did on the analysis model to either requirements or to design. To just skip it altogether is not really an alternative. It sounds agile, but it will actually increase cost and decrease quality. I owe you an explanation. See motivation for analysis model elsewhere.
How Do You Strike The Right Balance Between Models
This is very much dependent on what kinds of tools you have. State of the art tools of today allow us to work on design and implementation as if it was one model only; updates in the design "perspectives" will instantly change the code perspective and vice versa. This allows you to choose between where you want to spend your time – in design diagrams or in code. Today we don't have the corresponding relation between analysis and design. Since twenty years I have expressed my belief that we will be able to design transformers that translates analysis models into design models. One day you may not need to have developers working in the design space (the platform specific space). Instead we will build transformers that help us with the transformation in much the same way as we have compilers today. Many other people, for instance Steve Mellor, have been pushing this idea, even harder. OMG has in principle adopted this vision in its MDA initiative.
Until we have such tools we have to be cautious not to overwork the analysis model. If we do, we will have to redo much of the job in design. A similar line of thoughts is true for moving from use cases to analysis. Don't go too far in formalizing the use case model. For instance, don't use activity diagrams to describe the internals of a use case. The analysis model is much more appropriate for doing just that: use activity diagrams with swim-lanes to describe the realization of each use case.
Balance In Practice
With poor forward engineering tools, it is practical to move the focus of the development effort to the code. You should identify and specify your use cases, you may make a quick pass through each use case in analysis to identify your conceptual classes (the vocabulary), and you may do some sequence diagrams for the most important interactions between classes/components in design. You spend maybe 60% of the work on coding. So for instance you would spend your time as follows: use cases 20%, analysis -- a few % only, design – less than 20% and coding 60%. Recall that these numbers include verification and validation – what we call "Quality from the beginning".
With modern modeling tools you can spend more work in the early models and be awarded in design and code. The numbers will change substantially. Today, with modern tools, you could very well work as follows (over all iterations): use cases 20%, analysis 10%, design 50% and implementation 20%. And your total work will be substantially smaller.
And this balance will change as we get better platforms and better tools. When model-driven development has matured – in 5-10 more years or so -- we should expect that we formalize the analysis work and spend less and less time on design & implementation. At the least for most traditional business applications.
Why not hope for: use cases 30%, analysis 60% and design & implementation 10% only. Of course with substantial cost savings, quality increase and shortened time to market.
Developing Process
"What is the difference between the Unified Process and the Rational Unified Process?"
The brief answer
The Unified Process was originally described in the book The Unified Software Development Process written by me and with Grady Booch and Jim Rumbaugh as co-authors. When this book was published (1998), RUP could be described as instance of the UP, or as an implementation of the ideas presented in this book. Now RUP has evolved over five more years, so much has been added (not much of the principles have changed).
Since, The Unified Process is not proprietary, many other people have adopted the same term, made some improvements to it. Most people have been faithful to the core values of the process.
The better answer
I answered a similar question in 1992. People asked "What is the difference between the OOSE method (Object-Oriented Software Engineering -- a Use-Case Driven Approach) and the Objectory Process. See the following resource: On the development of Objectory. This chapter was put at the end of the OOSE book as an appendix (Appendix A), because I felt that the readers would not like to be distracted by meta-level issues. I encourage you to read the whole appendix, but at the least section A.1. It is still very much up-to-date. In this appendix introduced the concept of development cases. The section A.3 From Idea to Reality, is quite amazing, now more than ten years later.
Analysis
Analysis Basics
What is Analysis? Is it part of requirements, design or somewhere in between?
Analysis and agility
The Analysis Model is a Platform Independent Model
Analysis Basics
The basic principles behind analysis is outlined, its purpose, the relationship between use cases and analysis models, why analysis is not design, etc. The article presented here was written in 1997, but is still up to date.
What is Analysis? Is it part of requirements, design or somewhere in between?
Analysis is part of requirements and NOT part of design & implementation. The result of analysis is an analysis model which is part of the requirement artifacts and not of the design artifacts. With good tools (and remember tools become better and better) you should in most cases make an analysis model. The analysis model is about 20% of the design model and there are transformation rules to translate an analysis model to a design model. And more will come!
Analysis and agility
A relevant question is whether you can claim that making an analysis model is agile development. The answer is of course tool related. If you have a tool that effectively can manage multi-modeling and that can transform abstract models into more concrete models (such as the old Objectory tool could do), then there is no reason not to do analysis. All your work (or most of it) will be transformed into design and implementation. Such tools either exist today or they will exist in a relative short time frame. At the end it is about striking a balance on where you spend your work – use cases, analysis, design, implementation, and test (verify and validate) as you go.
The Analysis Model is a Platform Independent Model
Another interesting question is how Analysis is related to Platform-Independent Models (PIM) as defined by OMG. Analysis is a PIM. Actually, I like the term Platform-Independent Model better than Analysis. The same goes for Platform-Specific Model which is a much better word than Design (and Implementation). The two terms Analysis and Design have too many connotations and cause confusions. I am all for to change terminology here.