1. Rational Unified Process (RUP)By Patel RonakNiraj PunjabiGaurav DadhichSabhariswaran PSharad SrivastavaNimesh Kumar RathodShailendra Shankar Gautam

2. Rational Unified Process (RUP) Introduction Phases Core Workflows Best Practices Tools 3. 68% of all Software Projects fail - ZDNET McKinsey 17% of large IT Projects fail miserably Geneca - Large IT Projects run 45% over budget, 7% over time, delivering 56% less value 75% Project participants lack confidence in their project 4. Software Projects fail from around 5 to 47 factors Alexandria University Organizational Structure Badly Defined Requirements Unrealistic or Unarticulated goals Inability to handle project complexity Sloppy development practices Inaccurate estimates 5. Project failures can be controlled Delivery dates impact project delivery Projects estimations can be made as close as possible Risks can be re-assessed, controlled and managed Staff can be awarded for long work hours 6. Unified Software Development Process Agile Unified Process Basic Unified Process Enterprise Unified Process Essential Unified Process Open Unified Process Rational Unified Process Oracle Unified Method RUP-Systems Engineering 7. What is RUP ? A software engineering process based on best practices in modern software development A disciplined approach to assigning and managing tasks and responsibilities in a development organization Focus on high quality software that meets the needs of its end users within a predictable schedule and budget A process framework that can be tailored to specific organization or project needs RUP is a methodology for delivering projects in a maximum performance manner 8. RUP uses an integration of approaches & initiatives Team-Unifying Approach The RUP unifies a software team by providing a common view of the development process and a shared vision of a common goalIncreased Team Productivity Toolknowledge base of all processes view of how to develop software modeling language Rational provides many tools ArchitectSpecialistRelease EngineerProject ManagementAnalystDesigner / DeveloperTester 9. Key Aspects of RUP Risk-driven process Risk management integrated into the development process Iterations are planned based on high priority risks Use-Case driven development Use cases express requirements on the systems functionality and model the business as context for the system Use cases are defined for the intended system and are used as the basis of the entire development process Architecture-centric design Architecture is the primary artefact to conceptualize, construct, manage, and evolve the system Consists of multiple, coordinated views (or models) of the architecture 10. Rational Unified Process (RUP) - Snapshot time Phases Process WorkflowsInception ElaborationConstructionTransitioncontentBusiness Modeling Requirements Analysis & Design Implementation Test DeploymentSupporting Workflows Configuration & Change Mgmt Project Management Environment Preliminary Iteration(s)Iter. #1Iter. #2Iter. #nIter. Iter. #n+1 #n+2IterationsIter. #mIter. #m+1 11. Rational Unified Process (RUP) Introduction Architecture of RUP Phases Core Workflows Best Practices Tools 12. Architecture of RUP RUP produces a software generation A generation extends from idea to retirement of a single version of the systemDynamic Structure Describes the process in terms of how the process rolls out over time Expressed in terms of iterations, phases, and milestonesStatic Structure How RUP elements are co-works together Expressed in terms of core disciplines 13. Dynamic Aspect The dynamic structure deals with the lifecycle or time dimension of a project Shows cycles which contains 4 phases Inception closed with Milestone: lifecycle objective Elaboration closed with Milestone: Lifecycle Architecture Construction closed with Milestone: Initial Operational Capability Transition closed with Milestone: product Release InceptionElaborationConstructionTransitionTime10%30%50%10%Effort5%20%65%30% 14. Rational Unified Process (RUP) Introduction Architecture of RUP Phases Core Workflows Best Practices Tools 15. Inception Phase Objective: Understand what to build. Inception is the first of four RUP phase its all about getting familiar with Project goal and Scope .this phase Identify key system functionality. help you determine the A initial use-case model (10% -20%) complete. project feasibility , what customer want and how will Determine at least one possible solution. One or several prototypes. you get into more resource consumable phase. Understand the costs, schedule, and risks associated with the project. A vision document: Optional business model An initial project glossaryAn initial risk assessment. Business caseDecide what process to follow and what tools to use. A project plan 16. Lifecycle Objective Milestone Its first project Milestone which help to abort project or reconsider it early And let us not to focus on a doomed to fail project.Milestone: cost/schedule estimates. Requirements understanding. Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype . Actual expenditures versus planned expenditures. First Major MilestoneInceptionElaborationConstructiontimeTransition 17. Elaboration phase Objectives: Elaboration is the second of the four phases in the RUP approach. Deeper Requirement understanding At least 80% complete use-case model The goal of the Elaboration phase Supplementary requirements capturing is to define and baseline the non functional requirements architecture of the system in order None Use case requirement to provide a stable basis for the Architect consideration. A Software Architecture Description. bulk of the design and An executable architectural prototype. implementation effort in the Construction phase. The Risk mitigation and Accurate Cost/Scapulae architecture evolves out of a A revised risk list and a revised business case. consideration of the most significant requirements (those Development Case refinement that have a great impact on the A development plan for the overall project coarse-grained project plan architecture of the system) and an showing iterations assessment of risks. evaluation criteria for each iteration. 18. Milestone : Lifecycle Architecture This milestone tell help to determine if project plane, vision , architecture Are enough good to achieve project goals? If not Abort the project or reconsider it very seriously Is vision Stable? Is architecture stable? Does executable show true risk management? Is next phase (Construction) plane is accurate? Does current vision could be achieved? Is the actual resource expenditure versus planned expenditure acceptable?Major Milestones InceptionElaborationConstructiontimeTransition 19. Construction Phase Construction is really about cost-efficient development of a complete productan operational version of your systemthat can be deployed in the user communityObjectives: Minimize development costs and achieve some degree of parallelism Iteratively develop a complete product that is ready to transition to its user community The software product integrated on the adequate platforms. The user manuals. A description of the current release. 20. Milestone : Initial Operational Capability The Construction phase ends with an important project milestone, the Initial Operational Capability Milestone, which is used to determine whether the product is ready to be deployed into a beta test environment by answering (among others) the following questions Is this product release stable and mature enough to be deployed in the user community? Are all the stakeholders ready for the transition into the user community? Are actual resource expenditures versus planned expenditures still acceptable? Major MilestonesInceptionElaborationConstructiontimeTransition 21. Transition Phase The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed.Objectives: beta testing to validate the new system against user expectations parallel operation with a legacy system that it is replacing conversion of operational databases training of users and maintainers roll-out the product to the marketing, distribution, and sales teams Improve future project performance through lessons learned 22. Milestone: Product Release Transition ends with the fourth major project milestone, the Product Release Milestone, to determine whether the objectives were met and if you should start another development cycle. (Several development cycles may have been already planned during Inception.) In some cases this milestone may coincide with the end of the Inception phase for the next cycle Is the user satisfied? Are the actual resources expenditures versus planned expenditures still acceptable? Major MilestonesInceptionElaborationConstructiontimeTransition 23. Dynamic Elements Phases and Milestones Major MilestonesLifecycle ArchitectureLifecycle ObjectivesInitial Operational CapabilityProduct Release timeInception Define scope of projectElaboration Plan project, specify features, baseline architectureConstructionTransitionBuild productTransition product to end user community 24. Rational Unified Process (RUP) Introduction Architecture of RUP Phases Core Workflows Best Practices Tools 25. Static Aspect of RUP Static dimension of RUP consist of Some Roles ,Activities , Artefacts and workflows. Workflow is a way to describe meaningful sequences of Project Management activities that produce some Business Modeling valuable result and to show Requirements interactions between roles. Analysis and Design Roles in RUP are assigned to Implementation Workers , and preparing an Test artifact assign to Roles . Configuration and Change Management Activities shows how a Role Environment will do an assignment. DeploymentStatic Elements Worker (Who) Activity (How) Artifact (What) Workflows (when) 26. Static Process Elements Roles (who) A role that defines the individuals or a team that should carry out the workActivity (how) Describes a piece of work a worker performsArtifact (what) A piece of information that is produced, modified, or used by an activity Workflow (when) Specifies when a set of related activities is performed, by which workers, producing some artifact, which provides some observable value to the project 27. Roles Any Worker Any of the workers identified in the Rational Unified Process Architect The architect leads and coordinates technical activities and artifacts throughout the project. Architecture Reviewer The architecture reviewer plans and conducts the formal reviews of the software architecture in general. Business Designer The business designer defines the responsibilities, operations, attributes, and relationships of one or several business workers and business entities. Business-Model Reviewer The business-model reviewer participates in formal reviews of the business use-case model and business object model. 28. Roles-Cont. Business-Process Analyst The business-process analyst leads and coordinates business use-case modeling.Capsule Designer The capsule designer focuses on ensuring that the system is able to respond to events in a timely manner, in accord with the concurrency requirements.Change Control Manager The change control manager (worker) oversees the change control process. In a small project, a single person, such as the project manager or software architect, may play this role.Code Reviewer responsible for ensuring the quality of the source codeConfiguration Manager The configuration manager ensures that the CM environment facilitates product review, change, and defect tracking activities. The configuration manager is also responsible for writing the CM plan and reporting changerequest-based progress statistics. 29. Roles-Cont. Course Developer The course developer develops training material to teach users how to use the product.Database Designer The database designer defines the tables, indexes, views, constraints, triggers, stored procedures, table spaces or storage parameters, and other database specific constructs needed to store, retrieve, and delete persistent objects.Deployment Manager The deployment manager is responsible for plans to transition the product to the user community.Design Reviewer The design reviewer plans and conducts the formal reviews of the design model.Designer The designer defines the responsibilities, operations, attributes, and relationships of one or several classes and determines how they should be adjusted to the implementation environment. 30. Roles-Cont. Implementer An implementer is responsible for developing and testing components in accordance with the project's adopted standards so that they can be integrated into larger subsystems.Process Engineer The process engineer is responsible for the software development process itself.Project Manager The project manager allocates resources, shapes priorities, coordinates interactions with the customers and users, and generally tries to keep the project team focused on the right goal.Project Reviewer The project reviewer is responsible for evaluating project planning artifacts and project assessment artifacts, at major review points in the project lifecycle.Requirements Reviewer The requirements reviewer plans and conducts the formal review of the use-case model. 31. Roles-Cont. Stakeholder Is anyone who is materially affected by the outcome of the project. System Administrator Maintains the development environmentboth hardware and software and is responsible for system administration, backup, and so on. System Analyst Leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system. System Integrator System integrators combine components to produce an internally released build. Also responsible for planning the integration of the system. Technical Writer The technical writer produces end-user support material, such as user guides, help texts, release notes, and so on. 32. Roles-Cont. Test Designer The test designer is responsible for the planning, design, implementation, and evaluationm of testing and evaluation of test coverage, test results, and effectiveness.Tester The tester is responsible for executing testing, including test setup and execution; evaluating test execution and recovering from errors; and assessing the results of test and logging identified defects.Tool Specialist The tool specialist is responsible for the supporting tools in the project. This includes assessing the need for tool support and selecting and acquiring tools.Use-Case Specifier The use-case specifier details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases.User-Interface Designer Capturing usability requirements; building user-interface prototypes; involving other stakeholders of the use and reviewing and providing the appropriate feedback on the final implementation of the user interface. 33. RUP Disciplines In RUP, the process is described at two levels: the discipline level and the workflow detail level. A Workflow is a grouping of activities that are often performed "together" to produce a specific result. In particular, workflow details describe groups of activities performed together in a discipline.The workflows for the RUP disciplines and workflow details are described using Unified Modeling Language (UML) activity diagrams. Discipline diagrams contain the workflow details of the discipline. 34. RUP Disciplines- Business Modeling ArtifactBusiness Modeling Understand the organization structure and dynamics in which a system is to be deployed Drive system requirements and achieving common understanding of system.Target-Organization Assessment Business Vision Business Glossary Business Rules Supplementary Business Specification Business Use-Case Model Business Use Case Business Actor Business Use-Case Business Object Model Organization Unit Business Worker Business Entity Business Architecture DocumentRoleBusiness-Process Analyst Business-Process Analyst Business-Process Analyst Business-Process Analyst Business-Process Analyst Business-Process Analyst Business Designer Business Designer Business-Process Analyst Business Designer Business Designer Business Designer Business-Process Analyst 35. RUP Disciplines: Requirements Management Requirements Management ArtifactRequirements Management Plan Stakeholder Requests Glossary Vision Requirements AttributesCapture and manage requirements Design a user interface focused on users needs Supplementary specification Software Requirements and goals Specification To define the boundaries Use-Case Model of (delimit) the system Use-Case Package Use Case To provide a basis for Actor (system) estimating cost and time Actor (human) to develop the system Boundary Class Use-Case Storyboard User-Interface PrototypeRoleSystem Analyst System Analyst System Analyst System Analyst System Analyst System Analyst Use-Case Specifier System Analyst Use-Case Specifier Use-Case Specifier System Analyst User-Interface Designer User-Interface Designer User-Interface Designer User-Interface Designer 36. RUP Disciplines: Analysis and Design ArtifactAnalysis and Design Translate requirements into a specification that describes how to implement the system Fulfills all its requirements. Is structured to be robust?Reference Architecture Reference Architecture Fit/Gap Analysis Software Architecture Doc Use-Case Realization Analysis Model Analysis Class Design Model Design Subsystem Design Package Design Class Interface Capsule Protocol Signal Event Data ModelRole Architect Architect Architect Designer Designer Architect Architect Designer Designer Designer Designer Capsule Designer Designer Designer Designer Database Designer 37. RUP Disciplines Implementation Implementation Create, assemble, and integrate components and subsystem into an executable systemArtifactRoleImplementation ModelArchitectImplementation ModelImplementer Implementer System IntegratorImplementation Subsystem Component Integration Build PlanSystem Integrator 38. RUP Disciplines Test Test test the developedcomponents as units. integrate the results produced by individual implementers into executable verify the interaction between objects. verify that all requirements have been correctly implementedArtifactTest PlanTest Model Test Procedure Test CaseRole Test Designer Test Designer Test Designer Test DesignerTest ScriptTest DesignerWorkload ModelTest DesignerTest Package Test Class Test Subsystem Test Component Test Results Test Evaluation SummaryDesigner Designer Implementer Implementer Tester Test Designer 39. RUP Disciplines: Deployment Deployment Turn the finished software product over to its users Producing external releases of the software. In some case includes: Planning and conduct of beta tests. Migration of existing software or data. Formal acceptance.Deployment PlanDeployment ManagerBill of MaterialsDeployment ManagerRelease NotesDeployment ManagerInstallation Component Support Material Training Material Product ArtworkImplementerTechnical Writer Course Developer Graphic Artist 40. RUP Disciplines: Configuration and Change Management Configuration and Change Management Assess product quality Simultaneous Update Multiple VersionsArtifact Configuration Management Plan Project Repository Configuration Audit Findings Change RequestRole Configuration Manager Configuration Manager Configuration Manager Change Control Manager 41. RUP Disciplines: Project Management Project Management Plan an iterative process Decide duration and content of an iteration provide practical guidelines for planning, staffing, executing, and monitoring projects provide a framework for managing riskArtifactRoleBusiness CaseProject ManagerSoftware Development Plan Iteration Plan Problem Resolution Plan Risk Management Plan Product Acceptance Plan Measurement Plan Iteration AssessmentProject Manager Project Manager Project Manager Project Manager Project Manager Project ManagerStatus AssessmentProject ManagerWork OrderProject ManagerProject MeasurementsProject ManagerReview RecordProject ReviewerProject Manager 42. RUP Disciplines: Environment Environment Track and maintain the integrity of evolving project assets Support the development organization with processes and tools Turn the finished software product over to its users Process improvementArtifactRoleQuality Assurance PlanProcess EngineerDevelopment Organization AssessProject-Specific Templates ment Development CaseProcess EngineerSupporting EnvironmentSystem AdministratorTool Support Assessment ToolsTool SpecialistGuidelines (Design, Test, etc.)Process Engineer Process Engineer Many WorkersTool Specialist 43. Additional Static Elements Guidelines Rules, recommendations, techniques, or heuristics to support activities and artifactsTemplates Models of artifacts that can be used to create the artifact Usually associated with a toolConcepts Discussions on particular concepts (e.g., iteration, risk) associated with the processTool mentors Show how to perform a set of process steps using a specific tool 44. Models and Workflows Business ModelingBuild upon Business ModelRequirements Workflow Use-Case ModelAnalysis Design WorkflowEach major workflow describes how to create and maintain a particular model.realized byDesign ModelImplementation Workflowverified byimplemented byImplementation ModelTest Workflow Used byDeployment WorkflowsTest Model Deployment model 45. Workflow Detail: Prepare Environment for Project 46. Bringing It All Together... Phases Process WorkflowsInception ElaborationIn an iteration, you walk through all workflowsConstructionTransitionBusiness Modeling Requirements Analysis & Design Implementation Test DeploymentSupporting Workflows Configuration & Change Mgmt Project Management Environment Preliminary Iteration(s)Iter. #1Iter. #2Iter. #nIter. Iter. #n+1 #n+2IterationsIter. #mIter. #m+1 47. Rational Unified Process (RUP) Introduction Phases Core Workflows Best Practices Tools 48. Rational Unified Process Describes the effective implementation of key Best Practices Manage RequirementsDevelop IterativelyModel VisuallyVerify QualityControl ChangesUse Component Architectures 49. 1. Manage Your Requirements Elicit, organize, and document required functionality and constraints Track and document tradeoffs and decisions Business requirements are easily captured and communicated through use cases Use cases are important planning instruments Use-Case Modelrealizationinfluenced byverifiesDesign ModelImplementation ModelTest Model 50. 2. Develop Software Iteratively Aninitial design will likely be flawed with respect to its key requirements Late-phase discovery of design defects results in costly over-runs and/or project cancellation Requirements Analysis & Design Planning ImplementationInitial PlanningManagement Environment Deployment Evaluation Test 51. Waterfall Development Requirements Analysis Design Code & Unit Testing Subsystem Testing System TestingT I M E 52. Waterfall Development: Risk vs. TimeR I S KRequirements Analysis Design Code & Unit Testing Subsystem Testing System TestingT I M E 53. Risk Profile of an Iterative Development Waterfall InceptionElaborationRisk Construction TransitionPreliminary IterationArchitect. IterationArchitect. IterationDevel. IterationDevel. IterationTimeDevel. IterationTransition IterationTransition PostIteration deployment 54. Iterative Development Characteristics Critical risks are resolved before making large investments Initial iterations enable early user feedback Testing and integration are continuous Objective milestones provide short-term focus Progress is measured by assessing implementations Partial implementations can be deployed 55. 3. Employ Component-based Architecture Design, implement and test your architecture up-front!A systematic approach to define a good architecture Resilient to change by using well-defined interfacesBy using and reverse engineering componentsDerived from top rank use cases Applicationspecific BusinessspecificComponent-based Architecture with layersMiddleware Systemsoftware 56. 4. Model Software Visually Aiding understanding of complex systems Exploring and comparing design alternatives at a low cost Forming a foundation for implementation Capturing requirements precisely Communicating decisions unambiguouslySub Systems Visual Modeling raises the level of abstractionClasses Code 57. 5. Verify Software Quality Create tests for each key scenario to ensure that all requirements are properly implemented Unacceptable application performance hurts as much as unacceptable reliability Verify software reliability - memory leaks, bottle necks Test every iteration - automate test!CostSoftware problems are 100 to 1000 times more costly to find and repair after deploymentDevelopmentDeployment 58. 6. Control Changes to Software Control, track and monitor changes to enable iterative development Establish secure workspaces for each developer Provide isolation from changes made in other workspaces Control all software artifacts - models, code, docs, etc. Automate integration and build managementParallel DevelopmentWorkspace ManagementCM is more than just check-in and check-outREPORTALERTProcess IntegrationBuild Management 59. Summary: Best Practices of Software Engineering The result is software that is On Time On Budget Meets Users NeedsAnalystPerformance EngineerDevelop Iteratively Manage RequirementsBest PracticesUse Component ArchitecturesTesterModel Visually Verify Quality Control ChangeRelease EngineerDeveloper Project Manager 60. Tools The success of process adoption is significantly improved by the use of appropriate supporting tools.Tool Mentors provide detailed descriptions of how to perform specific process activities or steps, or produce a particular artifact or report, using one or more tools. 61. Tools Rational Unified Process RUP Builder Rational Process Workbench Rational Administrator Rational Suite AnalystStudio Rational ClearCase Rational ClearQuest Rational ProjectConsole Rational PurifyPlus Rational QualityArchitect 62. Q&A 63. Assessment and Remarks Group NumberTiming - 2 marksPaticipation by Content in Slides Delivery & Clarity Total Group Members -3 3 Marks -212 completed in time2.5 requires improvement2 No formal attire2 good8.522 completed in time1.5 missed some IEEE standards2 less explanation2 good7.532 completed in time2.5 requires improvement2 was reading the slides1.5 ok8.041.5 exceeded time limit2.5 good3 good delivery2 good9.052 completed in time2 repetition in content3 good preparation1.5 may be improved8.5 64. Thank You