Untitled

The Unified Process (UP)

• What is it?
• The Unified Process (UP) , or Unified Sotfware Development Process, is a iteractive and incremental sofftware development framework 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.
• The most popular variations include the Rational Unified Process (RUP) and the Open Unified Process (OpenUP).

key characteristics "Unified Process"

• -It is an iterative and incremental development framework.
• -It is architecture centric with major work beign done to define and validate an architectural desing for most coding is done.
• -It is use-case and UML model driven with nearly all requirements being documentation in one of those forms.

The best practices

• 1. Develop Software Iteratively
• 2. Manage Requiremets
• 3. Use Component-based Architectures
• 4. Visual Model Software
• 5. Verify software Quality
• 6. Control Changes to Softwre

HISTORY

• Much of the concepts in the Unified Process began with work Ivar Jacabson did at Ericsson in the 1960's, Jacabson went out on his own in 1987, codified his earlier work into what became the Objectory Process, and started the Objectory AB company to sell the process.

Components:

• -Cycles
• -Phases
• -Iterations
• -Disciplines (also known as Workflows)
• -Activities
• -Artifacts
• -Workers

The Disciplines are:

• -Business Modeling
• -Requirements
• -Analysis and Desing
• -Implementation
• -Testing
• -Deployment
• -Configuration and change Management
• -Project Management
• -Enviroment

The four phases are:

• -Inception phase
• -Elaboration phase
• -Construction phase
• -Transition phase

The Disciplines

• Business Modeling
• The Business Modelllng dlsclpllne focuses on efforts to understand the organlzatlon, Its processes.
• and the problem domain. The dlsclpllne focuses on understandlng the followlng factors and how
• they may impact or relate to the software being considered:
• -Enterprlse buslness rules
• -Enterprise business process model
• -Enterprise domain model
• -Enterprise mission statement
• -Enterprise vision
• -Organization model

Slide 9

• Requirements
• The requirements discipline in RUP Is like the requirements discipline in pretty much every other
• software process The main difference is that RUP requirements are highly focused in the form of
• UML models and Use Cases (both diagrams and descriptions).

Slide 10

• Analysis and Design
• The Analysis and Design dlsclpline would be better named the Solution Analysis and Design
• discipline In my opinion. This Is because the requirements are analyzed from a solution design
• perspective, rather than a requirements analysis perspective. Specific activities that are part of this
• discipline include:
• -Understanding and analyzing the requirements for the system
• -Defining a candidate architecture for a system
• -Constructlng a proof—of-concept or prototype to validate a candidate architecture
• -Design of components, services, and/or modules
• -Design of interfaces (network, user, and databases)
• Implementation
• -The Implementation discipline consists of coding, unit testing, and integration of the software.

Slide 11

• Testing
• The Testing discipline is focused on quality assurance of the software being released in that cycle or
• iteration. It includes such activities as:
• oPlannlng test efforts
• oCreating test cases
• tRunnlng tests
• oReporting defects

Slide 12

• Deployment
• The Deployment discipline is focused on planning the deployment of, and actually deploying, the
• software that is being completed that cycle, phase or iteration. It includes such activities as:
• -Planning the deployment
• -Developing support and operations materials
• -Planning alpha, beta, and pilot testing efforts
• -Deploylng the software
• -Tralning end users
• -Managing acceptance testing efforts

Slide 13

• Managing acceptance testing efforts
• Configuration and Change Management
• The Configuration and Change Management discipline is focused on managing change to the
• project’s work products. This Includes such activities as:
• -Managing change requests
• -Setting up the Change Management process and environment
• -Plannlng configuration control
• -Monitoring and reporting the configuration status
• -Managing baselines and releases

Slide 14

• Project Management
• The Project Management discipline is focused on standard project management activities such as:
• -Managing project staff
• -Stakeholder coordination and management
• -Managing project risks
• -Project estimating, planning, and scheduling
• -lteration planning
• -Project initiation and close-out

Slide 15

• Environmerlt
• The Environment discipline is focused on supporting the overall project and development efforts
• through managing environmental factors such as:
• -Processes
• -Standards
• -Tools (hardware, software, etc.)

Slide 16

• The Phases inception Phase
• The Inception Phase Is the part of the framework when the "why" of the development effort ls
• deflned. Thls includes such actlvltles as:
• -Definlng the buslness case
• -Creatlng a vlsion document with core requirements, features, and constraints
• -Creating an initial risk assessment
• -Creating early use cases (10-20% complete, mostly use-case models)
• -Creating a inltlal project plan
• -And the creation of one or more prototypes (especlally archltectural prototypes)
• -The milestones (that together comprise the Lifecycle Objectives Milestone) that show completion
• of the Inception phase are:
• -Stakeholder agreement on buslness case, scope, and project cost and schedule estimates
• -Agreement that the content of the primary use cases is an accurate representation of what the
• software will deliver (at a high level)
• -That the final prototypes are sufflclent indications of the correct future development goals

Slide 17

• Elaboration Phase
• The Elaboratlon Phase Is the part of the framework when more detailed analysls and plannlng are
• undertaken to better understand the problem domain, develop a more concrete project plan,
• identify and eliminate the high-risk elements of the effort, and to establish a solid architectural
• foundation for the software to be developed. The goal is to develop a "mile wide and inch deep"
• View of the system to be developed‘

Unified Process Variations

• In addition to the general Unified Process described above (which also covers the Rational Unified
• Process), the following are other UP variants I have come across. The main difference seems to be
• In the number of Disclplines each defines (some add, some subtract) and In the number and type of
• Activities and Artifacts.
• Agile Unified Process (AUP)
• The Agile Unified Process is a simplified version of RUP developed by Scott Ambler. It makes a
• number of changes to RUP.
• -It adds agile techniques such as test driven development (TDD), Agile Model Driven Development
• (AMDD), agile change management, and database refactoring
• -It combines the Business Modeling, Requirements, and Analysis & Design disciplines from UP into
• a single Modeling discipline