Rational Unified Process Mr Hisham Al Khawar Iterative

  • Slides: 14
Download presentation
Rational Unified Process Mr Hisham Al. Khawar

Rational Unified Process Mr Hisham Al. Khawar

Iterative versus Waterfall We need to use a life cycle model in order to

Iterative versus Waterfall We need to use a life cycle model in order to approach developing a system easily, and be able to track progress ¡ The waterfall life cycle is supposed to be very linear ¡ Complete each task before starting the next – requirements, design, code, test

Iterative versus Waterfall ¡ The iterative life cycle breaks down the requirements into stages

Iterative versus Waterfall ¡ The iterative life cycle breaks down the requirements into stages or subsets ¡ Then development focuses on completely developing one stage, releasing it, then adding the next stage Also called evolutionary or incremental development

Iterative Development This helps get critical functionality to the customer much faster ¡ Iterative

Iterative Development This helps get critical functionality to the customer much faster ¡ Iterative development also makes it clear sooner if something’s wrong ¡ Note: the spiral life cycle is a different animal; it’s used for resolution of critical risks and combines the features of the prototyping model and the waterfall model. ¡

Time Boxing A technique to help stay focused during development is to schedule using

Time Boxing A technique to help stay focused during development is to schedule using time boxing ¡ Short periods of time (e. g. 1 -4 weeks) are allocated for each iteration; this makes it clearer if your development time expectations are unrealistic ¡

Time Boxing ¡ To help keep on schedule, some techniques might help Automated regression

Time Boxing ¡ To help keep on schedule, some techniques might help Automated regression tests, such as using JUnit or Win. Runner Continuous integration, using an automated build process with automated testing to do daily (or more frequent) testing These are also advocated by Extreme Programming (XP)

Predictive vs. Adaptive Planning Predictive planning for a project develops a plan, and measures

Predictive vs. Adaptive Planning Predictive planning for a project develops a plan, and measures progress against meeting that plan ¡ Adaptive planning creates a plan, but uses it mostly to assess the impact of changes on the overall schedule ¡

Agile Processes ¡ Agile processes, such as Extreme Programming, generally: ¡ Are very adaptive

Agile Processes ¡ Agile processes, such as Extreme Programming, generally: ¡ Are very adaptive in nature Use time boxing Use UML as a sketching tool Agile processes are ‘lightweight’ – they have little documentation and few control points

Rational Unified Process (RUP) n Developed by “three amigos” at Rational Software (IBM) q

Rational Unified Process (RUP) n Developed by “three amigos” at Rational Software (IBM) q q q n Grady Booch, Ivar Jacobson, and Jim Rumbaugh Unified Modeling Language (UML) is a set of graphical and linguistic notations for modeling systems, not a process or method The three amigos also developed Rational Unified Process (RUP) You don’t have to use RUP to use UML Interestingly different from the traditional waterfall model Highly iterative and incremental process q q Software product is not released in one big bang at end of project Instead, developed and released in pieces (prototypes, partial releases, beta, etc. )

Rational Unified Process (RUP) ¡ System is defined by use cases ¡ A “use

Rational Unified Process (RUP) ¡ System is defined by use cases ¡ A “use case” is a major way of using the system, or a major type of functionality High level planning needs to Define what are the major use cases and in what order they will be done Estimate development time for each use case (as in “time boxing”)

RUP Iterative Development ¡ Each iteration implements one or more use cases Includes the

RUP Iterative Development ¡ Each iteration implements one or more use cases Includes the entire life cycle (requirements analysis, design, implementation, and testing) Results in some clearly defined end product Is planned with a fixed time to completion

Lifecycle Phases Inception – “Daydream” Elaboration – “Design/Details” Construction – “Do it” Transition –

Lifecycle Phases Inception – “Daydream” Elaboration – “Design/Details” Construction – “Do it” Transition – “Deploy it” Phases are not the classical requirements/ design/coding/implementation processes Phases iterate over many cycles

Inception Elaboration … ¡ ¡ During inception, establish business rationale and scope for project

Inception Elaboration … ¡ ¡ During inception, establish business rationale and scope for project Business case: how much it will cost and how much it will bring in? Scope: try to get sense of size of the project and whether it’s doable Creates a vision and scope document at a high level of abstraction In elaboration, collect more detailed requirements and do high-level analysis and design Inception gives you the go-ahead to start a project, elaboration determines the risks ¡ ¡ Requirement risks: big danger is that you may build the wrong system Technological risks: can the technology actually do the job? will the pieces fit together? Skills risks: can you get the staff and expertise you need? Political risks: can political forces get in the way? Develop use cases, non-functional requirements & domain model

… Construction Transition ¡ Construction builds production-quality software in many increments, tested and integrated,

… Construction Transition ¡ Construction builds production-quality software in many increments, tested and integrated, each satisfying a subset of the requirements of the project ¡ Delivery may be to external, early users, or purely internal Planning is crucial: use cases and other UML documents Transition activities include beta testing, performance tuning (optimization) and user training No new functionality unless it’s small and essential Bug fixes are OK