RUP - IBM Rational Unified Process/Disciplines or Workflows
Workflows or disciplines (it depends on RUP version) are distributed along phases and iterations. They are separated in six engineering disciplines and three support disciplines.
Engineering disciplines
[edit | edit source]Engineering disciplines are business modeling, requirements, analysis & design, implementation, tests and deployment.
Business Modeling
[edit | edit source]Business modeling explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.
Organizations are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organization. Businesses invest in IT when they understand the competitive advantage and value added by the technology. The aim of business modeling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization (the client), the current problems in the organization, and possible improvements. They must also ensure a common understanding of the target organization between customers, end users and developers.
Requirements
[edit | edit source]Requirements explain how to elicit stakeholder requests and transform them into a set of requirements work products that scope the system to be built and provide detailed requirements for what the system must do.
Analysis and Design
[edit | edit source]The goal of analysis and design is to show how the system will be realized. The aim is to build a system that:
- Performs — in a specific implementation environment — the tasks and functions specified in the use-case descriptions.
- Fulfills all its requirements.
- Is easy to change when functional requirements change.
Designs results in a design model and analysis optionally into an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. The design model consists of design classes structured into packages and subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases.
Implementation
[edit | edit source]The purposes of implementation are:
- To define the organization of the code in terms of implementation subsystems that are organized in layers.
- To implement classes and objects in terms of components (source files, binaries, executables, and others).
- To test the developed components as units.
- To integrate the results produced by individual implementers (or teams) into an executable system.
Systems are realized through the implementation of components. The process describes how to reuse existing components, or implement new components with well-defined responsibility, making the system easier to maintain and increasing the possibilities to reuse.
Test
[edit | edit source]Test workflow: The purpose of testing is to assess product quality. This not only involves the final product, but also begins early in the project with the assessment of the architecture and continues through the assessment of the final product delivered to customers. The test workflow involves the following:
- Verifying the interactions of components
- Verifying the proper integration of components
- Verifying that all requirements have been implemented correctly
- Identifying and ensuring that all discovered defects are addressed before the software is deployed
Deployment
[edit | edit source]The purpose of deployment is to successfully produce product releases, and to deliver the software to its end users. It covers a wide range of activities including producing external releases of the software, packaging the software and business application, distributing the software, installing the software, and providing help and assistance to users. Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase. The Deployment and Environment workflows of the Rational Unified Process contain less detail than other workflows.
Support disciplines
[edit | edit source]Support disciplines are configuration and change management, project management and environment.
Configuration and Change Management
[edit | edit source]Configuration and Change Management discipline is not only for tracking versions but for controlling changes. Critical activities are managing change requests, managing configuration and baselines.
Project Management
[edit | edit source]The Project management discipline and project planning in the RUP occur at two levels. There is a coarse-grained or Phase plan which describes the entire project, and a series of fine-grained or Iteration plans which describe the iterations.
It focuses mainly on the important aspects of an iterative development process: Risk management, Planning an iterative project, through the lifecycle and for a particular iteration, and Monitoring progress of an iterative project through metrics. However, this discipline of the RUP does not attempt to cover all aspects of project management.
Environment
[edit | edit source]This discipline focuses on the activities required to provide software development environment, including processes and tools. Considering it may be a weight and expensive discipline its possible to use IBM Rational Method Composer to help make it simpler, so process engineers and project managers could more easily customize the RUP for their project needs.