The Rational Unified Process (RUP

)

1

Software Process Models 

Software process models are general approaches for organizing a project into activities. 

Help the project manager and his or her team to decide: 


What work should be done; In what sequence to perform the work.  

The models should be seen as aids to thinking, not rigid prescriptions of the way to do things. Each project ends up with its own unique plan.
2

The opportunistic approach
First rotot pe o i Unti atis ie Thin o ea or pro e ent 

« is what occurs when 

an organization oes not o ow goo engineering practices.

3

What is R P?  R P was originally developed by Rational Software (now part of IBM)     It is a software engineering process It enhances team productivity It creates and maintains models It is a guide to effectively use the nified Modeling Language  Its goal is to delivery a high quality product that the customer actually wants 4 .

this is the most widely known methodology that embraces ML  Created to support the OO design and modeling.What is R P?  So.       Designed to be adaptable Suggests a process framework Adapts to the project needs se-case-driven development Architecture-centric process Iterative and incremental process 5 .

including  relatively short-term iterations  with well-defined goals  go/no-go decision points at the end of each phase. to provide management visibility into the development process 6 .R P provides  Several mechanisms.

Requirements never change All information is known upfront The customer will be satisfied with the end results Technology will not change when it comes time to integrate  Assumptions     7 .Why not use Waterfall instead?  The Waterfall method follows a sequential approach to software development.  This limits the ability to react to any change or correct problems in a timely matter.

R P Phase Model  All phases are iterative (and concurrent) in nature 8 .

Structure of R P  R P is structured in two dimensions  Phases  which represent the four major stages that a project go through over time. and which represent the logical activities that take place throughout the project  Disciplines   It has two aspects   Serial aspect is captured in its phases Iterative aspect is captured in its disciplines (?) 9 .

Iteration Iteration Iteration  An iteration is a distinct sequence of activities    with an established plan and evaluation criteria. Iteration Construction Devel.Iterations and Phases Executable Releases Inception Elaboration Devel. 10 . resulting in an executable release. Iteration Devel. Iteration Transition Transition Transition Iteration Iteration Preliminary Architect. Architect.

Iterative Lifecycle Graph C O N T E N T S T R U C T U R E In an iteration. you may walk through all disciplines TIME 11 . .

se several best practices  Iterative in the small    Delivering incremental releases over time   ollowing proven best practices  12 . release 2 and so on.R P Characteristics (Ambler. 2005)  Serial in the large   The phases are serial in nature over time Much like seasons of a project/year! R P phases are divided into one or more iterations Reflected in how you approach its Disciplines Release 1.

R P Phases  Inception   Vision. business case Not detailed requirements Specify requirements in greater detail and define the architecture for the system Not detailed design The focus here is to develop the application to the point where it is ready for deployment. (testing is done as well) We can now delivery the system into production (Stakeholder acceptance)  Elaboration    Construction   Transition  13 . high level requirements.

R P Phase 1: Inception  Inception   Customer communication Planning  Identify resources. defines schedule In the form of use cases. assess risks. A tentative outline of major sub-systems.  Business requirements   Rough architecture   Not detailed requirements 14 . functions and features that populate them.

Inception: Lifecycle Objectives (LCO) milestone  Stakeholders must agree.   On the scope of the project That the initial requirements have been identified (although without much detail) That your software development plan is realistic That the risks have been identified and are being managed appropriately That the business case for the project makes sense That the development process has been tailored appropriately     15 .

implementation model and deployment model. project delivery dates  Review plan and make modifications   NOT detailed design 16 . analysis model. design model.R P Phase 2: Elaboration  Elaboration     Customer communication Modeling activity Expands the use cases Expands the architecture to:  se case model. Evaluate scope. risks.

as well as a high-level project plan. are in place   17 .Elaboration: Lifecycle Architecture (LCA) milestone  Stakeholders must agree that the.      Project vision has stabilized and is realistic Requirements for the project: still might evolve Architecture is stable and sufficient to satisfy the requirements Risks are continuing to be managed Current expenditures are acceptable and reasonable estimates have been made for future costs and schedules Project team has a realistic chance to succeed Detailed iteration plans for the next few Construction iterations.

Conduct unit testing for the components Integrate components. 18 . Implement all functions and features for that increment.R P Phase 3: Construction  Construction      Develop software components (that make the use cases operational). Complete the analysis and design models.

Construction: Initial Operational Capability (IOC) Review  Stakeholders must agree that. as well as a high-level project plan. are in place     19 .  Software and supporting documentation are acceptable to deploy Stakeholders (and the business) are ready for the system to be deployed Risks are continuing to be managed effectively Current expenditures are acceptable and reasonable estimates have been made for future costs and schedules Detailed iteration plans for the next few Transition iterations.

R P Phase 4: Transition  Transition     Create user manuals. 20 . Software is given to users for beta testing. installation procedures. Get user feedback The increment is now a useable software release. guidelines.

including supporting documentation and training. is ready for deployment Current expenditures are acceptable and reasonable estimates have been made for future costs System can be operated once it is in production System can be supported appropriately once it is in production 21 .Transition: Product Release (PR) Milestone  Stakeholders must agree that.     System.

R P disciplines (activities in phases)  Business Modeling  Goal is to understand the business of the organization Goal is to define Scope: What is and is not to be built Goal is to analyze the requirements and design the solution Goal is to execute the code based on the design  Requirements   Analysis and Design   Implementation  22 .

R P disciplines (activities in phases)  Test  The goal is to verify all aspects of the system to ensure quality The goal is plan and deliver a working system to the customer The goal is to manage access to the project¶s work products Not only tracking versions over time but also controlling and managing changes to them  Deployment   Configuration and change management   23 .

software) are available to the team as needed. tools (hardware. directing people and coordinating with people The goal is to support the rest of the efforts in terms in ensuring that the proper process.R P disciplines (activities in phases)  Project Management   The goal is to direct the activities that take place on the project Includes managing risks. guidance (standards and guidelines).  Environment  24 .

Best Practices of the R P  Adapt the process  Adapt R P appropriately based on the development needs Balance their priorities when they often change Take an evolutionary approach by keeping stakeholders as active participants Keep an open communication process Provide effective tools and working environment 25  Balance competing stakeholders    Collaborating Across Teams   .

Best Practices of the R P  Demonstrate Value Iteratively   Organize your project into iterations Deliver working software early and regularly Adapt modeling tools. and focus on architecture This is done by testing at every major part of the project  Elevate the level of Abstraction     ocus continuously on Quality  26 . reuse existing code.

Disadvantages of R P  The process may be  too complex to implement out of control heavyweight process an expert to fully adopt this process  Development can get   It is a   You need  27 .

Advantages of R P  Improved governance   True earned value. delivery of high quality software One can easily determine whether R P team is on track or not Can see portions of the system sooner and receive assurance that they will receive what they want Working incrementally allows higher risks to be addressed early You can react to any changes as you are developing in small iterations 28  Regular feedback from and to stakeholders   Improved risk management   You implement the actual requirements  .

writing documentation. waiting for acceptance. reworking things and developing detailed plans  Developers focus on what matters   29 .Advantages of R P  You discover what works early   Elaboration phase ensures that your architecture works early in your project Developing the skeleton for your system you mitigate much of the technical risk Developers can find out important issues to work on depending on the circumstances With traditional approaches a team will often spend months modeling. reviewing their work.

ibm.pdf  A Manager¶s Introduction to the Rational nified Process (R P) http://www.pdf  The Rational nified Process http://www.pdf 30 .References  Rational nified Process: Best Practices for Software Development Teams http://www.com/developerworks/rational/library/conte nt/03July/1000/1251/1251_bestpractices_TP026B.menloinnovations.com/downloads/managersIntroToR P.com/freestuff/whitepapers/R ational%20Unified%20Process.ambysoft.