The purpose of the RUP phases, therefore, is not to partition the activities by type: analysis, coding, and so on (this is what you achieve with the concept of disciplines). Rather, the purpose of a phase is to do just enough of any activity required to meet the objectives of this phase by the time you meet the milestone that concludes it. And what you need to achieve in each phase is mostly driven by risk. In other words, the phases define project states, whereas the states are in turn defined by the particular risks you are mitigating, or the questions you are answering.
These major milestones are key business-level decision points for the project, where major decisions must be made about the continuation of the project and its scope, funding, strategy, delivery, or schedule. Also, since the phases are not associated with one kind of role, a RUP project is not executed in a pipeline fashion by having a crew of analysts throw requirements over the wall to a team of designers, who throw a design to a bunch of developers, who pass it to the poor testers to take all the blame. A RUP project is a collaboration among all these people, from business analysts to testers. All the RUP roles are involved throughout most of the cycle (except maybe the very early startup of a brand-new project). |