Unified Process

UNIFIED PROCESS (UP)

• 
• The Unifiecl Process (UP), or Unified Software Development Process, is an iterative and incremental software 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 Unifled
• Process (OpenUPL The framework has several key characteristics which seem to carry across all varlations (as far as l can tell)

The Key Characteristic

• It is an iterative and incremental development framework
• It is architecture-centríc with major work being done to define and Validate an architectural design for most codlng is done
• -It is rlsk-focused and emphaslzes that highest-risk actors be addressed in the earliest deliverables possible
• -lt is use-case and UML model driven with nearly aII requirements being documented in one of those forms
• ln general, the Unified Process is built around the idea of incorporating six specific "best practiceí‘
• into a configurable process Framework Those best practices are:
• Develop Software Iteratlveiy
• Manage Requirements
• Use Component-based Architectures
• Visually Model Software
• Verifv Software Quality
• Control Changes to Software

The disciplines for Business Modelling

• The Disclplines
• 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
• 

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).
• 

Analysis and Design

• 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 and Testing

• Implementation
• The Implementation discipline consists of coding, unit testing, and integration of the software.
• Testing
• The Testing discipline is focused on quality assurance of the software being released in that cycle or
• iteration. It includes such activities as:
• Plannlng test efforts
• Creating test cases
• Runnlng tests
• Reporting defects
• 

Deployment

• 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
• 

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
•