1. Unified Process
Source & Courtesy: Jing Zou

2. Reasons for Unified Process
Software becomes more complex and is updated fast.
Software developers uses methods that are as old as 25 years ago.
Development process is diverse

3. Precursor of Unified Process
Set of activities to transform a user’s requirements into a software.
Software development
Process (diversity)
User’s
Requirement
Software
System
Unified Process

4. 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

5. History of Unified Process

6. History of Unified Process

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

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

9. Terminologies Users: someone or something that interact with system.
Use Case: interaction between users and system,---what is the system supposed to do for each user?
Use Case Model: collection of use cases; description of complete functionality

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

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

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

13. Use case & Architecture
drive
influence
System architecture

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

15. Benefits to controlled iteration
Reduce the cost risk to the expenditures on a single increment
Reduce the risk of delayed product delivery (find the risks earlier)
Speed up the tempo of the whole development effort
Easier to adapt to the requirement modification

16. Relationship of 3 concepts
define
USE CASE
Goals
drive
ITERATION
drive
guide
influence
ARCHITECTURE

17. Lifecycle of Unified Process
Each cycle concludes with a product release to customers.
Each cycle consists of 4 phases:
Inception
Elaboration
Construction
Transition

18. Phases within the cycle
X-abscissa
Y-ordinate

19. End of a Cycle
At the end, a software product is releasable Finished product includes
requirements
use cases
nonfunctional requirements
test cases
artifacts modeled by the UML

20. For New Cycle For every new cycle, we need Use-case model
Analysis model
Design model
Implementation Model
Deployment model
Test model
Representation of the architecture

21. Phases within the cycle
X-abscissa
Y-ordinate

22. Phase I --> Inception
Develop 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 requirement
Initiate risk management (cost, time, political environment)

23. 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

24. 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?

25. Phase IV --> Transition
Products move to beta release.
Trial
Defects and deficiencies are reported.
Corrections and improvements
Final testing( system, acceptance, beta )
Training customer personnel
Documentation, installation and consultation
Perform postmortem review

26. Modeling Disciplines of Unified Process
Business Modeling: Model the business context, the scope, of the system.
Requirement: Engineer the requirements for the project,
Analysis and Design: Evolve a robust architecture for the system
Enterprise Management: Encompasses activities that are outside of the scope of a single project,

27. RUP and UP
UP is more of a philosophy of how to run development projects
RUP is Rational commercial product

28. Rational Corporate Introduction
Background Introduction
Products Introduction:
Requirements & analysis
Rational Suite® AnalystStudio
Visual modeling & development
Rational Suite® DevelopmentStudio
Automated Testing
Rational Suite® TestStudio®
Project Management
Rational Unified Process®
Configurable Process
RUP

29. UML and RUP UML: international standard for object-oriented modeling.
RUP uses UML to prepare blueprints of the software
How to build a use case diagram?
“…We are making inroads into many corporations today, and it's our goal to get there. We don't think it would be an easy thing to make the Unified Process a standard;…And I think that everyone that looks at the Rational Unified Process will become convinced this is the way they've got to do it….”

30. RUP strengths Strength of RUP: Based on sound SwE principles
Mechanisms that provide management visibility into the development process
HTML-based description of the RUP

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

32. Conclusion 6 Best Practices Iterative Software Deployment
Manage Requirements
Component-based architecture
Visually model software
Quality Control
Configuration Management

33. RUP is component based.
RUP uses visual modeling standard UML and rely on 3 aspects
Establishes a framework that integrates all different facets such as workflows, risk mitigation, quality control and etc.
Developers can build different models

34. Thanks…