Software Development Life Cycle phases

Software Development Life Cycle The UML is largely process-independent, meaning that it is not tied to any particular software development life cycle. However, to get the most benefit from the UML, you should consider a process that is Use case driven Architecture-centric Iterative and incremental The Rational Unified Process is summarized in Appendix B; a more complete treatment of this process is discussed in The Unified Software Development Process and The Rational Unified Process. Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating the system's architecture, for testing, and for communicating among the stakeholders of the project. Architecture-centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. An iterative process is one that involves managing a stream of executable releases. An incremental process is one that involves the continuous integration of the system's architecture to produce these releases, with each new release embodying incremental improvements over the other. Together, an iterative and incremental process is risk-driven, meaning that each new release is focused on attacking and reducing the most significant risks to the success of the project. This use case driven, architecture-centric, and iterative/incremental process can be broken into phases. A phase is the span of time between two major milestones of the process, when a well-defined set of objectives are met, artifacts are completed, and decisions are made whether to move into the next phase. As Figure 2-24 shows, there are four phases in the software development life cycle: inception, elaboration, construction, and transition. In the diagram, workflows are plotted against these phases, showing their varying degrees of focus over time. Figure 2-24. Software Development Life Cycle FIGURE Inception is the first phase of the process, when the seed idea for the development is brought up to the point of beingat least internallysufficiently well-founded to warrant entering into the elaboration phase. Elaboration is the second phase of the process, when the product requirements and architecture are defined. In this phase, the requirements are articulated, prioritized, and baselined. A system's requirements may range from general vision statements to precise evaluation criteria, each specifying particular functional or nonfunctional behavior and each providing a basis for testing. Construction is the third phase of the process, when the software is brought from an executable architectural baseline to being ready to be transitioned to the user community. Here also, the system's requirements and especially its evaluation criteria are constantly reexamined against the business needs of the project, and resources are allocated as appropriate to actively attack risks to the project. Transition is the fourth phase of the process, when the software is delivered to the user community. Rarely does the software development process end here, for even during this phase, the system is continuously improved, bugs are eradicated, and features that didn't make an earlier release are added. One element that distinguishes this process and that cuts across all four phases is an iteration. An iteration is a distinct set of work tasks, with a baselined plan and evaluation criteria that results in an executable system that can be run, tested, and evaluated. The executable system need not be released externally. Because the iteration yields an executable product, progress can be judged and risks can be reevaluated after each iteration. This means that the software development life cycle can be characterized as involving a continuous stream of executable releases of the system's architecture with a midcourse correction after each iteration to mitigate potential risk. It is this emphasis on architecture as an important artifact that drives the UML to focus on modeling the different views of a system's architecture.