rational unified process software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte the rational unified process rup is an iterative software development process framework created by the rational software corporation a division of ibm since 2003 rup is not a single concrete prescriptive process but rather an adaptable process framework intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs rup is a specific implementation of the unified process history rational software originally developed the rational unified process as a software process product the product includes a hyperlinked knowledgebase with sample artifacts and detailed descriptions for many different types of activities rup is included in the ibm rational method composer rmc product which allows customization of the process philippe kruchten an experienced rational technical representative was tasked with heading up the original rup team this journey began with the creation of the rational objectory process rop in 1996 when rational acquired the objectory process that had been written by ivar jacobson and company this was renamed rational unified process rup in subsequent releases in part to align the name with that of the unified modeling language these initial versions combined the rational software organisations extensive field experience building objectoriented systems referred to by rational field staff as the rational approach with objectorys guidance on practices such as use cases and incorporated extensive content from jim rumbaughs object modeling technology omt approach to modeling grady boochs booch method and the newly released uml 08 to help make this growing knowledge base more accessible philippe kruchten was tasked with the assembly of an explicit process framework for modern software engineering this effort employed the htmlbased process delivery mechanism developed by objectory the resulting rational unified process rup completed a strategic tripod for rational a tailorable process that guided development tools that automated the application of that process services that accelerated adoption of both the process and the tools this guidance was augmented in subsequent versions with knowledge based on the experience of companies that rational had acquired in 1997 a requirements and test discipline were added to the approach much of the additional material sourced from the requirements college method developed by dean leffingwell et al at requisite inc and the sqa process method developed at sqa inc both companies having been acquired by rational software in 1998 rational software added two new disciplines business modeling much of this content had already been in the objectory process a configuration and change management discipline sourced through the acquisition of pure atria corporation these additions lead to an overarching set of principles that were defined by rational and articulated within rup as the six best practices for modern software engineering develop iteratively with risk as the primary iteration driver manage requirements employ a componentbased architecture model software visually continuously verify quality control changes these best practices were tightly aligned with rationals product line and both drove the ongoing development of rationals products as well as being used by rationals field teams to help customers improve the quality and predictability of their software development efforts additional techniques including performance testing ui design data engineering were included and an update to reflect changes in uml 11 in 1999 a project management discipline was introduced as well as techniques to support realtime software development and updates to reflect uml 13 besides the first book to describe the process the unified software development process isbn0201571692 was published in the same year between 2000 and 2003 a number of changes introduced guidance from ongoing rational field experience with iterative development in addition to tool support for enacting rup instances and for customization of the rup framework these changes included the introduction of concepts and techniques from approaches such as extreme programming xp that would later come to be known collectively as agile methods this included techniques such as pair programming testfirst design and papers that explained how rup enabled xp to scale for use on larger projects a complete overhaul of the testing discipline to better reflect how testing work was conducted in different iterative development contexts the introduction of supporting guidance known as tool mentors for enacting the rup practices in various tools these essentially provided stepbystep method support to rational tool users automating the customization of rup in a way that would allow customers to select parts from the rup process framework customize their selection with their own additions and still incorporate improvements in subsequent releases from rational ibm acquired rational software in february 2003 in 2006 ibm created a subset of rup tailored for the delivery of agile projects released as an opensource method called openup through the eclipse website rational unified process topics rup building blocks rup is based on a set of building blocks and content elements describing what is to be produced the necessary skills required and the stepbystep explanation describing how specific development goals are to be achieved the main building blocks or content elements are the following roles who a role defines a set of related skills competencies and responsibilities work products what a work product represents something resulting from a task including all the documents and models produced while working through the process tasks how a task describes a unit of work assigned to a role that provides a meaningful result within each iteration the tasks are categorized into nine disciplines six engineering disciplines business modelling requirements analysis and design implementation test deployment three supporting disciplines configuration and change management project management environment four project lifecycle phases rup phases and disciplines the rup has determined a project lifecycle consisting of four phases these phases allow the process to be presented at a high level in a similar way to how a waterfallstyled project might be presented although in essence the key to the process lies in the iterations of development that lie within all of the phases also each phase has one key objective and milestone at the end that denotes the objective being accomplished the visualization of rup phases and disciplines over time is referred to as the rup hump chart inception phase the primary objective is to scope the system adequately as a basis for validating initial costing and budgets in this phase the business case which includes business context success factors expected revenue market recognition etc and financial forecast is established to complement the business case a basic use case model project plan initial risk assessment and project description the core project requirements constraints and key features are generated after these are completed the project is checked against the following criteria stakeholder concurrence on scope definition and costschedule estimates requirements understanding as evidenced by the fidelity of the primary use cases credibility of the costschedule estimates priorities risks and development process depth and breadth of any architectural prototype that was developed establishing a baseline by which to compare actual expenditures versus planned expenditures if the project does not pass this milestone called the life cycle objective milestone it either can be cancelled or repeated after being redesigned to better meet the criteria elaboration phase ortner the primary objective is to mitigate the key risk items identified by analysis up to the end of this phase the elaboration phase is where the project starts to take shape in this phase the problem domain analysis is made and the architecture of the project gets its basic form the outcome of the elaboration phase is a usecase model in which the usecases and the actors have been identified and most of the usecase descriptions are developed the usecase model should be 80 complete a description of the software architecture in a software system development process an executable architecture that realizes architecturally significant use cases business case and risk list which are revised a development plan for the overall project prototypes that demonstrably mitigate each identified technical risk a preliminary user manual optional this phase must pass the lifecycle architecture milestone criteria answering the following questions is the vision of the product stable is the architecture stable does the executable demonstration indicate that major risk elements are addressed and resolved is the construction phase plan sufficiently detailed and accurate do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture is the actual vs planned resource expenditure acceptable if the project cannot pass this milestone there is still time for it to be canceled or redesigned however after leaving this phase the project transitions into a highrisk operation where changes are much more difficult and detrimental when made the key domain analysis for the elaboration is the system architecture construction phase the primary objective is to build the software system in this phase the main focus is on the development of components and other features of the system this is the phase when the bulk of the coding takes place in larger projects several construction iterations may be developed in an effort to divide the use cases into manageable segments produce demonstrable prototypes transition phase the primary objective is to transit the system from development into production making it available to and understood by the end user the activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users expectations the system also goes through an evaluation phase any developer which is not producing the required work is replaced or removed the product is also checked against the quality level set in the inception phase if all objectives are met the product release milestone is reached and the development cycle is finished the ibm rational method composer product the ibm rational method composer product is a tool for authoring configuring viewing and publishing processes see ibm rational method composer and an open source version eclipse process framework epf project for more details certification in january 2007 the new rup certification examination for ibm certified solution designer rational unified process 70 was released which replaces the previous version of the course called ibm rational certified specialist rational unified process to pass the new rup certification examination a person must take ibms test 839 rational unified process v70 you are given 75 minutes to take the 52 question exam the passing score is 62 six best practices six best practices as described in the rational unified process is a paradigm in software engineering that lists six ideas to follow when designing any software project to minimize faults and increase productivity these practices are develop iteratively it is best to know all requirements in advance however often this is not the case several software development processes exist that deal with providing solution on how to minimize cost in terms of development phases manage requirements always keep in mind the requirements set by users use components breaking down an advanced project is not only suggested but in fact unavoidable this promotes ability to test individual components before they are integrated into a larger system also code reuse is a big plus and can be accomplished more easily through the use of objectoriented programming model visually use diagrams to represent all major components users and their interaction uml short for unified modeling language is one tool that can be used to make this task more feasible verify quality always make testing a major part of the project at any point of time testing becomes heavier as the project progresses but should be a constant factor in any software product creation control changes many projects are created by many teams sometimes in various locations different platforms may be used etc as a result it is essential to make sure that changes made to a system are synchronized and verified constantly see continuous integration software testing portal macroscope methodology suite agile modeling am agile unified process aup disciplined agile delivery dad dynamic systems development method dsdm computer programming featuredriven development fdd project life cycle quality assurance scaled agile framework a descendent of rup that incorporates agile software development methods such as extreme programming xp software architecture software component software development process software engineering software testing testdriven development tdd ivar jacobson grady booch and james rumbaugh 1999 the unified software development process gary pollice liz augustine chris lowe and jas madhur 2003 software development for small teams a rupcentric approach per kroll philippe kruchten 2003 rational unified process made easy the a practitioners guide to the rup per kroll bruce mac isaac 2006 agility and discipline made easy practices from openup and rup philippe kruchten 1998 the rational unified process an introduction ahmad shuja jochen krebs 2007 rup reference and certification guide walker royce software project management a unified framework ibm rational unified process web site rational software at ibm global rational user group community vteunified modeling languageactors organizations object management group uml partners persons grady booch ivar jacobson james rumbaugh conceptsobject oriented objectoriented programming objectoriented analysis and design objectoriented modeling structure actor attribute artifact class component interface object package profile diagram behavior activity event message method state use case relationships association composition dependency generalization or inheritance extensibility profile stereotype other multiplicity diagramsstructure class component composite structure deployment object package behaviour activity state machine use case interaction communications sequence interaction overview timing derived languages systems modeling language sysml uml exchange format uxf xml metadata interchange xmi executable uml xuml other topics glossary of uml terms rational unified process list of unified modeling language tools object modeling in color authority control gnd 45605130 