Course Map
Overview. Introduction. History
Content. Rational Unified Process. Extreme Programming
Implementation. Tools, Training, Roles. CMM, Metrics. Selection & Evaluation
Briefings (Term Papers)
1 2 3 4 6 7 8 9 10 115
Assignments
Quizzes
Week
Mem
ori
al D
ay
• Understand the basics of the Rational Unified Process (RUP)– Structure
– Content
– Best practices
• In particular, understand how RUP enables iterative development
Today’s Objectives
Topic Duration
• Quiz #1 40 minutes
• RUP Overview 30 minutes
• *** Break 10 minutes
• RUP Overview (cont.) 45 minutes
• RUP and Iterative Development 60 minutes
Today’s agenda
Topic Duration
• Quiz #1 40 minutes
• RUP Overview 30 minutes
• *** Break 10 minutes
• RUP Overview (cont.) 45 minutes
• RUP and Iterative Development 60 minutes
Today’s agenda
Topic Duration
• Quiz #1 40 minutes
• RUP Overview 35 minutes
• *** Break 10 minutes
• RUP Overview (cont.) 30 minutes
• RUP and Iterative Development 75 minutes
Today’s agenda
Think to yourself how many of the projects you have worked were:
On Time? On Budget?
High Quality?
The Bottom Line: Our Customers are upset with us.The Bottom Line: Our Customers are upset with us.
The Result is Often Referred to as the Software Crisis
• Schedule Overruns• Cost Estimate Overruns• Software Quality Problems• Software does not meet User Expectations• Productivity of Software Developers has not
been keeping up with demand
Why is This?
• Software is dynamic versus static• Software is complex• Software is difficult to conceptualize • Software is difficult to represent • Software is difficult to communicate• Software is difficult to evaluate and measure• Software developers have trouble learning what users
want:– Users do not know what they want – Software developers misunderstand the problem
• There is a tremendous demand for software
Symptoms and Root Causes
Some Symptoms:• Requirements in flux • Users needs not met• Poor quality• Schedule slips• Projects cancelled• Cost over runs• Difficulty in maintaining
software• Software that work in pilot
does not work in production• Business changes faster
than systems can keep up• Staff turnover
Some Root Causes:• Insufficient and misunderstood
requirement• Ambiguous communication• Lack of good software
architectures• Undetected inconsistencies• Poor testing• Overwhelming complexity• Uncontrolled changes• Manual practices• Exponentially increasing cost of
change
Best Practices
“An organized and documented set of principles, methods and processes that increase quality and productivity of software development.”
“An organized and documented set of principles, methods and processes that increase quality and productivity of software development.”
Source: Rational - “Principles of Managing Iterative Development v2.0”
The Rational Unified Process
• Developed through the combined efforts of:– Grady Booch– Ivar Jacobson– James Rumbaugh
• Features– Based on the Unified Modeling Language– Iterative– Architecture-centric– Use-case driven– Risk driven
Rational Objectory Process 4.1
Rational Approach
Rational Unified Process 5.5
Rational Unified Process 5.0
Rational Objectory Process 4.1
Rational Unified Process 2000
Objectory Process 3.8
The History of the Rational Unified Process
2000
1999
1998
1997
1996
1995
UML v1.0
UML v1.1
UML v1.3
RUP Model Notation
A role played by an individual or a
team.
A unit of work that a worker may
perform.
A piece of information that
is produced, modified or used
by a process.
Workers
• A Worker is a role played by an individual or a team.
• Example:– Stakeholder– Systems Analyst– Designer– Test Designer– Project Manager
A piece of information that is produced, modified or used by a process.
Artifacts are the intangible products of the project
Examples: A use-case model A document such as a
business case Source Code Executable code
Artifacts
Activities
• An Activity is a unit of work that a worker may perform.
• Examples:– Plan an interaction
performed by Project Manager
– Find use cases and actors– Review the design– Execute a performance
test
Additional Process Elements
• Guidelines - are rules, recommendations, or heuristics that support activities and steps.
• Templates - are models or prototypes of artifacts– Ex. Word template for Vision Document
• Tool mentors - are a means of providing guidance by showing you how to use a specific software tool (Similar to wizards)
• Concepts - Separate material that describe some of the reasons and background on a specific topic
Software Product
Rational’s Nomenclature of the Software Engineering Process
Requirements
User Team (Suppliers)Expectations• Features• Cost• Benefit• Delivery Dates• Quality
Users Team(Customer)Perceptions• Features• Cost• Benefit• Delivery Dates• Quality
SoftwareEngineering
Process(Workflows)
Software Development Team
Processes, Techniques & Tools
PerformanceMeasures(Activities)
Software is developed in Teams:
Workers
Workers
Workers
ArtifactsArtifacts
Artifacts
Activities
Rational’s View of Best Practices
• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change
Iterative Advantages/Disadvantages
Advantages• Resolves risks before
making large investments• Enables early user feedback• Makes testing and
integration continuous• Focuses project on short-
term objectives• Makes partial deployments
possible
Disadvantages• Waterfall life cycle is more
familiar since it is similar to hardware life cycle
• Iterative Life Cycles difficult to estimate and manage.
• Only recently used on real projects - therefore little track record
Iterative life cycle best used for problems that are not well understood. Iterative life cycle best used for problems that are not well understood.
Rational’s View of Best Practices
• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change
Manage Requirements
A systematic approach to– eliciting
– organizing
– documenting
– and managing
the changing requirements of the software application
What’s the Difference?
• Requirements Analysis• Requirements Definition• Requirements Specification• Requirements Management
Managing Changing Requirements
• Establish a Baseline• Evaluate changes and determine their impact• Track and document tradeoffs and decisions
Rational’s View of Best Practices
• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change
Software Components
Definition:
A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.
Definition:
A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.
Components
Airplane
Private Data
Object Operations
Airplane
Private Data
Object Operations
Engines
Private Data
Object Operations
Engines
Private Data
Object Operations
Wings
Private Data
Object Operations
Wings
Private Data
Object Operations
Fuselage
Private Data
Object Operations
Fuselage
Private Data
Object Operations
Tail
Private Data
Object Operations
Tail
Private Data
Object Operations
COMPONENTS - Are objects that are combined into new objects without the use of inheritance
Benefits of Component Architectures
• Resilient– Meets current and future requirements– Improves extensibility– Enables reuse– Encapsulates system dependencies
• Reuse proven solution elements– Reuse or customize components– Select from Commercially-available
components– Evolve existing software incrementally
Benefits of Architecture
• Intellectual control– Manage complexity– Maintain integrity
• Basis for reuse– Component reuse– Architecture reuse (patterns)
• Basis for project management– Focus on early iterations– Planning– Staffing
Rational’s View of Best Practices
• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change
Model Visually - Use the UML
• Capture the structure and behavior of architectures and components
• Show how the elements of the system fit together
• Maintain consistency between a design and its implementation
• Promote unambiguous communication
The Unified Modeling Language
• Developed through the combined efforts of:– Grady Booch– Ivar Jacobson– James Rumbaugh
• Is a language for:– Visualizing– Specifying– Constructing– Documenting
the artifacts of a software-intensive system.
UML Components
• Multiple Views• Precise Syntax and semantics• Include
– Use-Case Diagrams– Class Diagrams– Object Diagrams– Component Diagrams– Deployment Diagrams– Activity Diagrams– State Chart Diagrams– Collaboration Diagrams– Sequence Diagrams
Rational’s View of Best Practices
• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change
Continuously Verify Quality
• In the Rational Unified Process, quality is defined as:"The characteristic identified by the following:
– satisfies or exceeds an agreed upon set of requirements, and – assessed using agreed upon measures and criteria, and – produced using an agreed upon process."
• Therefore, achieving quality is not simply "meeting requirements" or producing a product that meets user needs, or expectations, etc.
• Quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process, has achieved the desired degree of quality (and can be repeated and managed).
Test Each Iteration
• Start testing early• Continuously test• Test each iteration for functionality and
performance• Iterative development makes regression
testing necessary• Use automated tests whenever possible
Rational’s View of Best Practices
• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change
Control Changes
• You must control, track and monitor changes to enable iterative development
• Control changes for all software artifacts:– Models
– Documents
– Source code
– Project plans
• Establish secure workspaces fore each developer• Automated integration and build management
Controlling Parallel Development
• Multiple developers• Multiple teams• Multiple sites• Multiple iterations• Multiple releases• Multiple projects• Multiple platforms
Configuration Management
Configuration Management is the process which controls the changes made to a software system and manages the different versions and releases of the evolving software products– Librarian like function– Manages the version number for each software product– Changes made are controlled by a Change Control Process– Can be managed manually or through the use of a
configuration management tool (Difficult to do manually, but it can be done.)
• Check In• Check Out• Read only for others
Change Control Process
Create InitialSections
Create/ModifyDraft
Review Draft(V&V)
Create Changes to Incorporate
Changes Needed In Document
DocumentApproved
Create Review Revise ReviewReview Approved
Time
...
Document in Production and Under Formal Change Control
Document in Production and Under Formal Change Control
Document Under Development and User Change Control
Document Under Development and User Change Control
Topic Duration
• Quiz #1 40 minutes
• RUP Overview 30 minutes
• *** Break 10 minutes
• RUP Overview (cont.) 45 minutes
• RUP and Iterative Development 60 minutes
Today’s agenda
Core Concepts
Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases
A D IVersion 1
A D IVersion 2
A D IVersion 3
Core Concepts
Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases
Version 1
Development CycleVersion 2
Development CycleVersion 3
Development Cycle
Initial
Evolution
Evolution
Product delivered to users
Core Concepts
Milestones
• Exit criteria• Decide to proceed, abort, or change course• Measure progress, e.g.,
– use cases completed– features completed– performance requirements satisfied– risks eliminated– test cases passed
Guidelines
Key Question: Deliverables/Outcomes
Activities Exit Criteria
Look at the objectives and distill into one key question that needs to be answered by this phase
What are the major artifacts produced? Outcomes achieved?
What are the essential activities?
Predefined standards that must be met before exiting one development phase and entering another. A team handing work off to another part of the project must fully satisfy their exit criteria, while the receiving team verifies that the work meets their standard entry criteria.
Summary Timeline
1960 1970 1980 1990 2000
Tech eraMainframe
Decentralized
Distributed Internet
Life cyclemodel
Stage wise
Waterfall
Iterative/Incremental
Methapproach
Structured Analysis/Design
Information Engineering
Object-Oriented A/DAgile
ContentUpdates
• Data mgmt • UI design• Bus process reengineering • Data/process distribution • CASE tools
• JAD• Prototyping • Multimedia content mgmt
• Network design/mgmt • Quality• Security
• OLTP
Protracted integration and late breakage
Conventional application of the waterfall model typically results in late integration and performance showstoppers
Dev
elop
men
t p
rogr
ess
(% c
oded
)
100%Late designbreakage
Original target date
Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).
Integrationbegins