Unifed Process (UP)

Unifed Process Variations

Slide 2

• The Unified Process (UP), is an iterative and incremental software developmentframework from which a customized process can be defined. The framework contains many components and has been modified a number of times to create several variations

KEY CHARACTERISTICS:

• It is an iterative and incremental development framework
• It is a architecture-centric with major work being donde to define and validate an architectural desing for most coding is done.
• It is ise-case and UML model driven with nearly all requirements being documented in one of those forms.
• It is risk-focused and emphasizes that highest-risk factors be addressed in the earliest deliverables possible.

Slide 4

• The unifed process is built around the idea of incorporating six specific "best practices" into a configurable process framework. those best practices are:
• Develop Software Iteratively
• Manage Requirements
• Use Component-based Architectures
• Visually Model Software
• Verify Software Quality
• Control Changes to Software

History

• Much of the concepts in the Unified process began with work Ivar Jacobson did at Ericsson in the 1960's
• Jacobson went out on his own in 1978, codified his earlier work into what become the Objectory Procees, and started the Objectory AB company to sell the process. After a number of years further developing the Objectory process, Jacobson relased the book Object-Oriented Software Engineering in 1995 which described the Objectory Process in detail.
• In 1996 Rational Software adquired the Objectory Process and company, Jacobson worked at Rational and teamed up with Grady Booch and Jim Rumbaugh and together they spent the next several years further developing the Objectory Process. In 1998, Rational changed the name from the Rational Objectory Process to the Rational Unified Process. However, because RUP was the trademarked property of Rational, further work by the software and academic community.
• IBM acquired Rational Software in 2003, and in 2005 donated the core of the Rational Process to the Eclipse Foundation open-source community.

Slide 6

• The unified process framework is made up of the following components.
• Cycles
• Phases
• Iterations
• DisciplinesActivitiesArtifactsWorkers

Slide 7

• The disciplines are:
• Business Modeling
• Requirements
• Analysis and Design
• Implementation
• Testing
• Deployment
• Confifiguration and Change Management
• Project Management
• Environment

Slide 8

• The four phases are:
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

Slide 9

• Business Modeling
• One of the major problems with most business engineering efforts, is that the software engineering and the business engineering community do not communicate properly with each other. This leads to the output from business engineering is not being used properly as input to the software development effort, and vice-versa. The Rational Unified Process addresses this by providing a common language and process for both communities, as well as showing how to create and maintain direct traceability between business and software models.

Slide 10

• Requirements
• The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, we elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions. A Vision document is created, and stakeholder needs are elicited. Actors are identified, representing the users, and any other system that may interact with the system being developed. Use cases are identified, representing the behavior of the system. Because use cases are developed according to the actor's needs, the system is more likely to be relevant to the users. The following figure shows an example of a use-case model for a recycling-machine system.

Slide 11

• Analysis & Design
• The goal of the Analysis & Design workflow is to show how the system will be realized in the implementation phase. You want 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 structured to be robust (easy to change if and when its functional requirements change).
• Analysis & Design results in a design model and optionally 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 design packages and design subsystems with welldefined 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.

Slide 12

• Implementation
• The purpose of implementation is:
• • To define the organization of the code, in terms of implementation subsystems 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.

Slide 13

• Test The purposes of testing are:
• • To verify the interaction between objects.
• • To verify the proper integration of all components of the software.
• • To verify that all requirements have been correctly implemented.
• • To identify and ensure defects are addressed prior to the deployment of the software.

Slide 14

• Deployment
• The purpose of the deployment workflow is to successfully produce product releases, and deliver the software to its end users. It covers a wide range of activities including:
• • Producing external releases of the software.
• • Packaging the software.
• • Distributing the software.
• • Installing the software.
• • Providing help and assistance to users.
• • In many cases, this also includes activities such as:
• • Planning and conduct of beta tests.
• • Migration of existing software or data.
• • Formal acceptance.

Slide 15

• Project Management
• Software Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to deliver, successfully, a product in which meets the needs of both customers (the payers of bills) and the users. The fact that so few projects are unarguably successful is comment enough on the difficulty of the task.
• This workflow focuses mainly on the specific aspect of an iterative development process. Our goal with this section is to make the task easier by providing:
• • A framework for managing software-intensive projects.
• • Practical guidelines for planning, staffing, executing, and monitoring projects.
• • A framework for managing risk.

Slide 16

• Configuration & Change Management
• • Simultaneous Update:
• • Limited Notification
• • Multiple Versions