Unified process Model

DaniyalYounis 23,368 views 24 slides Jun 03, 2017
Slide 1
Slide 1 of 24
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24

About This Presentation

Here simple and easy understandable slides for good presentation.


Slide Content

Unified Process Daniyal Younis

Reasons for Unified Process Software becomes more complex and is updated fast Software developer uses methods that are as told as 25 years ago Development process is diverse

Precursor for Unified Process Set of activities to transform a user’s requirements into a software. Software Development Process (Diversity) Unified Process User’s Requirement Software System

What does Unified Process do? Provides guidance to the order of team’s activities Integrates team’s work and individual’s work Specifies artifacts Offers criteria for monitoring and measuring

History of Unified Process 1967: Ericsson software engineering process - Component-based - Divide and Conquer - “traffic cases.” 1987: Ivar Jacobson, Objectory - Workflaws: Requirements, analysis. Design, code and test - Document driven: customized templates

History of Unified Process Rational - Iterative development process - Acquired Objectory in 1995 and formed Rational Objectory Process (ROP) Complementary approach: Evolved into Rational Unified Process in 1998 - Process model - Templates -1999: Jacobson published Unified Software Development Process

Key Aspects of Unified Process Use-case driven Architecture-centric Iterative and incremental

Use-Case Driven Use-Case Driven means: Development process proceeds through a series of workflows that derive from use cases.

Terminologies Users: Someone or something that interact with systems Use Case: interaction between users and system, what the system supposed to do for each user? Use Case Model: collection of users; decription of complete functionality

Initiate AND bind Tool for specifying requirements Driving design Source for testing

Architecture-Centric Architecture is the view of the whole design with key Characteristics and without too many details Only 5-10% use cases Growth with use case in parallel (structure and function )

Simplified Process Rough outline (use case independent ) Subset of identified use cases (5-10%) More use cases specified, more architecure discovered

Use Case and Architecture System architecture Drive Influence Use Case

Iterative and Incremental ?? Iteration: Steps in the workflow (mini-project) Create a design for relevant use cases Implement with components Required iteration in loigcal order for economy Incremental: Growth in the product (might not be additive)

Relationship of 3 concepts USE CASE ARCHITECTURE ITERATION Define Goals Guide Drive Drive influence

Lifecycle of Unified Process Each cycle concludes with a product release to customers Each cycle consist of four phases: Inception Elaboration Construction Transition

Phases within the cycle Iteration

Phase-I Inception Development a good idea into a vision of the end product Business case for the product is presented Establish goals Build business case Identify essential system requiremnet

Phase-II Elaboration Here architecture is expressed as a view of different models Develop architecture Capture functional requirements as use cases Identify non functional requirements Plan the construction Continue risk management

Phase-III Construction Muscle built: software added to the architecture Build the system Maintain architectural integrity (Architecture is stable but might has minor changes) Iterative, incremental However, is it sufficient to take early delivery

Phase-IV Transition Prodcut move to beta release Trail Defects and deficiencies are reported. Correctness and improvement Final testing (system, acceotance, beta) Training customer personal Documentation, installation and consultation Perform postmortem review

Weaknesses of RUP Weaknesses of RUP: Only developing process, not the entire software process Not supporting multi-system infrastructure development efforts Iterative nature foreign to experiences developers Tools-driven approach, not sufficient for complex system

RUP and UP UP is more of a philosophy of how to run development Project RUP is Rational Commercial product

Rational Unified Process Question & Queries
Tags