KEMBAR78
Unified process Model | PPTX
Unified Process
DANIYAL YOUNIS
Reasons for Unified Process
1. Software becomes more complex and is updated fast
2. Software developer uses methods that are as told as 25 years ago
3. 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?
1. Provides guidance to the order of team’s activities
2. Integrates team’s work and individual’s work
3. Specifies artifacts
4. 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
1. Use-case driven
2. Architecture-centric
3. 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
1. Tool for specifying requirements
2. Driving design
3. 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
1. Rough outline (use case independent )
2. Subset of identified use cases (5-10%)
3. 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:
1. Inception
2. Elaboration
3. Construction
4. 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:
1. Only developing process, not the entire software process
2. Not supporting multi-system infrastructure development
efforts
3. Iterative nature foreign to experiences developers
4. 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

Unified process Model

  • 1.
  • 2.
    Reasons for UnifiedProcess 1. Software becomes more complex and is updated fast 2. Software developer uses methods that are as told as 25 years ago 3. Development process is diverse
  • 3.
    Precursor for UnifiedProcess Set of activities to transform a user’s requirements into a software. Software Development Process (Diversity) Unified Process User’s Requirement Software System
  • 4.
    What does UnifiedProcess do? 1. Provides guidance to the order of team’s activities 2. Integrates team’s work and individual’s work 3. Specifies artifacts 4. Offers criteria for monitoring and measuring
  • 5.
    History of UnifiedProcess • 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
  • 6.
    History of UnifiedProcess • 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
  • 7.
    Key Aspects ofUnified Process 1. Use-case driven 2. Architecture-centric 3. Iterative and incremental
  • 8.
    Use-Case Driven Use-Case Drivenmeans: Development process proceeds through a series of workflows that derive from use cases.
  • 9.
    Terminologies Users: Someone orsomething 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
  • 10.
    Initiate AND bind 1.Tool for specifying requirements 2. Driving design 3. Source for testing
  • 11.
    Architecture-Centric Architecture is theview 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)
  • 12.
    Simplified Process 1. Roughoutline (use case independent ) 2. Subset of identified use cases (5-10%) 3. More use cases specified, more architecure discovered
  • 13.
    Use Case andArchitecture System architecture Drive Influence Use Case
  • 14.
    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)
  • 15.
    Relationship of 3concepts USE CASE ARCHITECTURE ITERATION Define Goals Guide Drive Drive influence
  • 16.
    Lifecycle of UnifiedProcess • Each cycle concludes with a product release to customers • Each cycle consist of four phases: 1. Inception 2. Elaboration 3. Construction 4. Transition
  • 17.
    Phases within thecycle Iteration
  • 18.
    Phase-I Inception • Developmenta 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
  • 19.
    Phase-II Elaboration Here architectureis 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
  • 20.
    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
  • 21.
    Phase-IV Transition Prodcut moveto 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
  • 22.
    Weaknesses of RUP Weaknessesof RUP: 1. Only developing process, not the entire software process 2. Not supporting multi-system infrastructure development efforts 3. Iterative nature foreign to experiences developers 4. Tools-driven approach, not sufficient for complex system
  • 23.
    RUP and UP UPis more of a philosophy of how to run development Project RUP is Rational Commercial product
  • 24.