 Hello! In this video, I will present the notorious Rational Unified Process method. It is abbreviated as RUP. First, let me present some history. Much of the concepts in the unified process began with work either Jacobson did at Ericsson in 1960s. Jacobson went out on his own in 1987 and started the objectory company to sell the process. In 1996, Rational Software acquired the objectory process. Jacobson worked at Rational and teamed up with Grady Butch and Jim Rambo. And together, they further developed the objectory process known as the Rational Objectory Process and the unified method which later became known as UML. In 1998, Rational changed the name from the Rational Objectory Process to the Rational Unified Process. However, because RUP was trademarked property of Rational, further work by the software and academic community usually referred to just the unified process in order to avoid trademark issues. IBM acquired Rational Software in 2003 and in 2005 donated the core of the Rational Process to the open source community. So, it is an iterative and incremental approach and is built around the idea of incorporating 6 specific best practices. The word best practices are in quotes because it is how these specific practices are called. RUP is an architecture-centric method. It means we spend a significant amount of time developing and validating system architecture models. This is risk-focused method and emphasizes that the highest risk factors be addressed in the earliest deliverables possible. Also, it is a configurable process. It means a team can choose the proportions of activities and it can choose to be more agile or plan-driven. Now, let's talk about the building blocks of RUP model. Let's talk about the 6 best practices. The first is develop software iteratively. We already discussed the good things iterative development brings to the table. Authors strongly believe that iterative development accelerates risk reduction in comparison to the waterfall model. The second is manage requirements. Authors believe that requirements are dynamic. Expect them to change during software development. There should be no chaos in changing requirements. Requirements should be managed by maintaining forward and backward compatibility. Also, changing requirements should be negotiated and agreed upon with a client taking into consideration a budget and development time. The third is use component-based architectures. It permits reuse, allows choosing from thousands of commercially available components, improves maintainability and extensibility. Also, it promotes a clean division of work among teams of developers. The fourth is visually model software. Visual modeling improves our ability to manage software complexity, allows us to capture the structure and behavior of components, promotes an amigos communication. The fifth is verify software quality. It means extensive testing, developing test suites for each iteration and testing for functionality, reliability, performance and other criteria. The last practice is control changes to software. Authors believe that without explicit control, parallel development degrades to chaos. Control means decomposing the architecture into subsystems, establishing secure work spaces for each team and establishing an enforceable change control mechanism. The RUP has determined a project lifecycle consisting of four phases. Each phase has one Q-objective and the milestone at the end that denotes the objective being accomplished. Let's investigate these phases. The first phase is an inception phase. The primary objective is to scope the system adequately as a basis for validating initial costing and budget. In this phase, the business case which includes context, success factors and the financial forecast is established. To complement a business case, a basic use case model, project plan, initial risk assessment and project description are generated. The second phase is the elaboration phase. The primary objective is to mitigate the key risk items identified by analysis. 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 third phase is the 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 where the bulk of the coding takes place. The last phase is the transition phase. The primary objective is to transfer the system from the development into production, making it available to and understood by the end user. The activities of this phase include training and better testing of the system. The system also goes through an evaluation phase. The product is checked against the quality level set in the inception phase. Now let's see at the proportions of each phase. So around 10% of project time is dedicated to the inception phase. Around 25% of the project time is dedicated to the elaboration phase. The biggest construction phase takes around 55% of the project time. And finally, the transition phase takes around 10% of the project time. With each iteration, the tasks are categorized into 9 disciplines. The first 6 are engineering disciplines. Business modeling allows describing a vision of the organization in which the system will be deployed. Requirements include eliciting stakeholder requests and transforming them into a set of requirement work products that scope the system. Analysis and design show how the system will be realized. Implementation means activities that are required to construct or realize the software system. Testing includes test workflows. The aim is to assess product quality. Deployment is related to successfully producing product releases and to delivering the software to its end users. The last 3 are the support disciplines. Configuration and change management discipline is not only for tracking versions, but for controlling changes as well. The project management discipline focuses mainly on the important aspects of an iterative development process. Risk management, planning an iterative project and monitoring the progress of an iterative project. The environment discipline focuses on the activities required to provide a software development environment, including processes and tools. Now let's combine everything into a single model. The visualization of RUP phases and disciplines over time is referred as to the RUP hump chart. You see that chart on the screen. As you can see, the software development lifecycle is divided into 4 phases. The sequential order of the phases looks similar to the waterfall model, but there is a huge difference. It's an iterative model. The iterations are shown at the bottom of the picture. The 9 disciplines we discussed recently are listed on the left side. Finally, everything is connected using the humps that are available for every phase iteration and discipline. These humps indicate the intensity of specific activities during each phase. One can see that during the inception phase, the business modeling and requirement related activities are the most intense. During the elaboration phase, the analysis and design basically software modeling activities are the most important. The implementation is tightly related to the construction phase. Deployment and configuration management activities take place mostly during a transition phase. Some activities like testing are performed on a similar intensity level throughout the project. Testing intensity slightly increases towards the finish. Now let's see when do we use this model. First, when you deal with changing requirements, tightly managing them. Second, when there is a need for accurate documentation and its implementation. Third, when there is a need for integration to happen throughout the software development. Finally, when there is a need for a configurable risk-focused model. Now let's see the challenges. The process heavily relies on proficient and expert team members since the assignment of the activities to individual workers should produce tangible, preplanned results in the form of artifacts. The unified process does not capture the sociological aspects of the software development. It is very important in agile approaches. And it is rather a complex method that makes its implementation challenging, particularly for smaller businesses, teams or projects. The key points of this lecture are. RUP is an iterative and incremental approach that is built around the idea of incorporating six best practices. It is architecture-centric process with major work being done to define and validate an architectural design. It is risk-focused and emphasizes that high-risk factors be addressed in the earliest deliverables possible. It is a configurable process. One can choose to make it more agile or plan-driven. The team chooses the configuration. Thank you for your attention and see you next time.