From the literature it is very difficult for me to nail down what it is. It seems to be different things to different people and everything and the kitchen sink to some people. No two definitions seem to match. For some it is a documentation driven heavy weight way to manage a project from begining to end. For some it is a feather weight like XP, Extreeme Programming. For some it is requirements management. For some it is a web site with process documentation. For some it is UML and for some UML is optional.
Due to the wealth (or volume) of the information out there I will try to summarize and add my own confusion.
Rational after concurring/consolidating/standardizing the UML for Object Oriented systems has turned its eyes to the life cycle of a software project. The result is a book describing a process called "Unified Process" with a promise to address all good things in a project life cycle.
The primary idea is that a project will go through 4 phases: Inception, Elaboration, Construction, and Transition. Each phase will have its deliverables called artifacts, delivered by a set of individuals called workers, performing tasks called activities organized to montiorable work flows.
The phases are expected to overlap as much as possible and as early as possible.
The deliverables are also expected to evolving in nature and get refined over time.
Hence each phase is broken down into iterations. At the end of each iteration one would take a stock of how things are moving and define the next iteration. It woudl have been nice to call these "Weekly iterations" to emphasize their short duration. With out this definition it is possible that an iteration can take a number of months defeating its purpose.
UML and its notation is expected to be used in each of the phases for delivering the artifacts. Particularly the use of usecases for clarifying and consolidating the requirements. The emphasis of actors and usecases are useful and adds another dimension to the clarification process, any extra-emphasis on use cases might make it more difficult for the user to understand requirements.
This task of requirements or functional specifications used to be provided with the help of a word document that focuses on the functional decomposition of the system. In my mind this functional decomposition is very essential to the requirements process. Each of the functional modules or facilities or features can be stated for their intent and idea and then proceed to valid usecases (user interaction) for manipulating or benefiting from that facility. With out this context usecases tend to be documentation for documentation sake.
Another flaw to guard with a use case as a requirement artifact is its length. The usecase templates strive to be so detailed that they cloud to convey the idea to the users not to mention to give a direction to the developers with out gettign lost in the detail.
A product like RequisitePro is used to manage this process. The key here is to collect information and evaluate risks. This process should be easy to do. The process should encourage stakeholders to contribute their requests. Visibility and management of these requests are important. Dedicated tools can be self defeating in this process. Tools with the characteristic of weblogs could greatly enhance this process. Ease of update, and visibility and analyis needs to be the hall marks of this phase.
UML should be de-emphasized in this phase and given a very secondary status or even eliminate it from the process and push it to the elaboration phase.
This is the phase for architecture and execution of risk mitigation. Use cases make a good progress to elaborate the system and have it approved by users. Class diagram and class modelling should be discouraged in this phase.
RUP is both a process and product from IBM. In oo parlance it is an instance of the unified process with some specializations and realizations. When this product is installed apparently you get to tailor your processes and then publish the results to a web site where programmers can start using the process. This aspect of it is quite difficult to garner from the documents. One has to see an actual implemenation and see how it works. The white papers are too abstract on this aspect. What is more confusing is that this product is supposed to interact with all of other rational products that does requirements, analysis, and design. Being a product this raises the question how is one expected to use it for Non IBM technologies such as Microsoft Project, Dotnet etc.
1. Have a process 2. Start your engines on all fronts as early as possible 3. Keep your iterations short 4. Use UML generously 5. Produce executable code as often as possible 6. Manage risks through iterations 7. Website for knowledge distribution
1. Have a process 2. Daily/weekly builds 3. Story boards for requirements 4. Test driven 5. Pair programming 6. Clear definition of a project environment through Developer/Customer bill of rights.