2. Building Software
Software Development Life Cycle
Iterative Software Development
The Unified Process
Prithwis
Mukerjee 2
3. What is a process ?
A series of steps that specify the way
Clients
Analysts
Designers
Programmers
Would work together to create a new system
A process defines Who is doing What, When and How to reach a
certain goal.
In software engineering the goal is to build a software product or
to enhance an existing one
Various Processes exist
SDLC Process / Waterfall Method
Unified Process / Unified Modeling Language
Prithwis
Mukerjee 3
4. System Development Life Cycle
Methodology
Component
Functional Technical
Estimate Develop Deliver Test Support
Design Design
Communication & Coordination
(all teams)
Functional
Functional
Support
USER Driven
Specification
Specification Test
Client Sign Off
Client Client
Review Review Code
Code
Bundle //
Bundle
Demo
Demo
Technical Code Review
Review Complexity
Complexity Unit Test
Unit Test Unit Test
Unit Test Program
Program Pre-
Pre- Support
Programmer Driven
Determination
Determination Plan
Plan Results
Results Review
Review Production
Production (optional)
// Estimate
Estimate Checklist
Checklist Support
Support
Technical Program
Legend
Technical Program
Specification
Specification Source Code
Source Code Task With Deliverable
Technical Task Without Deliverable
Design Optional Service Area
Walkthrough
Prithwis
Process Checkpoint
Mukerjee 4
5. The WaterFall Method – A simplified view
Analysis Users define what they want
from the system
Programmers re-define what they
Design believe the users want in a more
structured manner
Actual program is built using
an appropriate computer Coding
language like C, Java, VisualBasic
Application is tested and then Test / Deploy
deployed in the end users machine
Prithwis
Mukerjee 5
6. The WaterFall Method – Deliverables
Analysis Requirements Analysis Document
written in simple English language
Systems Specifications written in
Design
terms of e.g. TABLES, COLUMNS,
METHODS, FUNCTIONS
Programs written in an appropriate
language and tested individually. Coding
Unit Test Report for each program
All programs tested together to
ensure compatibility and consistency Test / Deploy
Integration Test Report
Prithwis
Mukerjee 6
7. Waterfall Process Assumptions
Requirements are known up front before design
In reality, users do not know what they want
They certainly cannot visualise what the final thing will look
like
Requirements rarely change
They always will, however much you hate it
Design can be conducted in a purely abstract space, or
trial rarely leads to error
The technology will all fit nicely into place when the
time comes (the apocalypse)
Prithwis
Mukerjee 7
8. Waterfall Process Limitations
Big Bang Delivery Theory
The proof of the concept is relegated to the very end of
a long singular cycle. Before final integration, only
documents have been produced.
Late deployment hides many lurking risks:
technological (well, I thought they would work together...)
conceptual (well, I thought that's what they wanted...)
personnel (took so long, half the team left)
User doesn't get to see anything real until the very end, and
they always hate it.
System Testing doesn't get involved until later in the process.
Prithwis
Mukerjee 8
9. What did the customer really want ?
Prithwis
Mukerjee 9
10. An Iterative Development Process...
Recognizes the reality of changing requirements
Caspers Jones’s research on 8000 projects
40% of final requirements arrived after the analysis phase,
after development had already begun
Promotes early risk mitigation, by breaking down the
system into mini-projects and focusing on the riskier
elements first
Allows you to “plan a little, design a little, and code a little”
Encourages all participants, including testers, integrators
to be involved earlier on
Allows the process itself to modulate with each iteration, allowing
you to correct errors sooner and put into practice lessons
learned in the prior iteration
Focuses on component architectures, not final big bang 10
Prithwis
Mukerjee
11. An Incremental Development Process...
Allows for software to evolve, not be produced in one
huge effort
Allows software to improve, by giving enough time to the
evolutionary process itself
Forces attention on stability, for only a stable
foundation can support multiple additions
Allows the system (a small subset of it) to actually run much
sooner than with other processes
Allows interim progress to continue through the
stubbing of functionality
Allows for the management of risk, by exposing
problems earlier on in the development process
Prithwis
Mukerjee 11
12. Goals and Features of Each Iteration
The primary goal of each iteration is to slowly chip
away at the risk facing the project, namely:
performance risks
integration risks (different vendors, tools, etc.)
conceptual risks (ferret out analysis and design flaws)
Perform a “mini-waterfall” project that ends with a
delivery of something tangible in code, available for
scrutiny by the interested parties, which produces
validation or correctives
The result of a single iteration is an increment--an
incremental improvement of the system, yielding an
evolutionary approach
Prithwis
Mukerjee 12
13. Incremental Model
Release 1
Design Coding Test Deployment
Requirements
Release 2
Design Coding Test Deployment
Release 3
Design Coding Test Deployment
Non-incremental, e.g. Waterfall, rapid prototyping models
Operational quality complete product at end
Incremental model
Operational quality portion of product within weeks
Each release adds more functionality, i.e., a new increment
Prithwis
Mukerjee 13
14. Evolutionary Model
Version 1
Requirements Design Coding Test Deployment
Version 1
Requirements Design Coding Test Deployment
Version 1 Feedback
Requirements Design Coding Test Deployment
Advantages
Constant customer involvement and validation
Allows for good risk management
Disadvantages
Build-and-fix danger
Contradiction in terms
New Mukerjee
versions implement new and evolving requirements14
Prithwis
15. Spiral model
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW anal sis Proto-
y
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirem ent design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integration
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
Radial dimension: cumulative cost to date
Angular dimension: progress through the spiral
If all risks cannot be resolved, the project is immediately terminated
Prithwis
Mukerjee 15
16. The “Unified Process”
Unified Process (UP) is a methodology proposed by
three amigos: Booch, Jacobson, Rumbaugh
They are also the co-developers of the Unified Modeling
Language (UML). They formed a company called Rational which
was bought over by IBM
Non Commercial and Free piece of knowledge
Rational Unified Process
The proprietory process, based on the Unified Process, along
with a suite of tools that allow one to use the process effectively
Commercial Product
Prithwis
Mukerjee 16
17. What is UML
Is a language.
It is not simply a notation for drawing diagrams, but a complete
language for capturing knowledge(semantics) about a subject
and expressing knowledge(syntax) regarding the subject for the
purpose of communication.
Applies to modeling and systems.
Modeling involves a focus on understanding a subject (system)
and capturing and being able to communicated in this
knowledge.
It is the result of unifying the information systems and
technology industry’s best engineering practices
(principals, techniques, methods and tools).
Prithwis
Mukerjee 17
18. UML – Consists of a set of Artefacts
S St a at e e
tt tte
DDi ai agSgSCraaalaamse s
r t mt s
UUs se e CCa as se e DDi ai ag gr ral amm s s
C as
DDi ai ag gr ra amm s s
DDUaiUUgsgsreraeCmC assassese e
i a e aCm
s a S St a at e e
t t e
UU s se e CC a as se e DD i aiUagsgrera ammas ss e
C DDi ai agSgOtraabatjmee cs t
S t mt s
r
DDUaiUagsgrec Ctmimassissteye
i s Ae ra aCav DD i ai ag gr ra amm s s DDi ai agO rab ame c st
ggrar jamm ss
DDi ai aA grc rataimvmistsy
g DDi ai a g r a m s
DDi ai ag gr ra amm s s
S Sc ce en na ar ri o o S St a at e e
SaSc cer ea nm arisri o o
DDi i Sg g qnauame nsi c e S tStaatat e e
DDi ai ag gr Sr tatmam tse
t
DDaSi eagrgq rauamem n sc e
ia e r s r m ts s
DDi ai ag gS rataa m e s
DD i ai ag gr ra amm s s M odel DDi ai ag gr ra amm s s
S Sc ce en na ar ri o oi
C Co ommp po on ne en nt t
DDiSaioaclcleraerabnmoar sri so ot i o n
S g g na am r a DCiCaoi aomgmar am mnsne en nt t
po
CD ioa lgl ar b m risa t i o n DDe ep pl o oy ymm e en nt t CC ogi ommrppaopm sosn ne en nt t
D D ar g o
CD i a g ra ao m s l D ia g r a m s
DDi ai ag gr ra amm s s DDi ai ag gr ra amm DDi ai ag gr ra amm s s
Prithwis
Mukerjee 18
19. Unified Process : 4 Phases
Inception Construction
Business case Iterative implementation of
Scope lower risk elements
Vague estimates Preparation for deployment
Continue or stop? Transition
Elaboration Beta tests
Identification of most Deployment
requirements
Iterative implementation of
the core architecture
resolution of high risks
Inception Elaboration Construction Transition
time Prithwis
Mukerjee 19
20. Iterative and Incremental Development
development is organized into a series of iterations
short fixed-length mini-projects (2 to 6 weeks)
timeboxed (i.e. fixed length iterations)
shift tasks to future iterations if necessary ...
an iteration represents a complete development cycle
incl. requirements,
the outcome of each iteration:
a tested, integrated and executable system
Inception Elaboration Construction Transition
Preliminary Iter. #1 Iter. #2
Iteration
Milestone Release Final production
Prithwis
release
Mukerjee 20
21. 1. Inception Phase
Obtain buy-in from all interested parties
Capture initial requirements
Analyse Cost and Benefits
Analyse Initial Risks
Define Scope of Project
Define candidate architecture
Language ? RDBMS ? Tiers ?
Develop a disposable prototype
Look and Feel of the application
Prithwis
Mukerjee 21
22. 2. Elaboration Phase
Define System Requirements
Develop USE CASE MODELS
Actors
USE CASE
Scenarios
Use Case Diagrams
Use Case Descriptions
Develop Class diagrams
Define Glossary of terms
Refine Risk Assesment
Revised Architecture Document
Prithwis
Mukerjee 22
23. 3. Construction Phase
From paper documents to computer programs
Cumulative increase in functionality
Increasing depth of implementation
Stubs fleshed out
Implementation of “bells and whistles”
Increasing severity of testing
More and more complex test cases
implement all details, not only those of central architectural
value
Analysis continues, but design and coding
predominate
Prithwis
Mukerjee 23
24. 4. Transition Phase
Transfer of the system to the user community
Includes manufacturing, shipping, installation,
training, technical support and maintenance
Development team begins to shrink
Control is moved to maintenance team
Alpha, Beta, and final releases
Software updates
Integration with existing systems (legacy, existing
versions, etc.)
Prithwis
Mukerjee 24
25. Unified Process Disciplines
Phases
Process Disciplines Inception Elaboration Construction Transition
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Supporting Disciplines
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations
Prithwis
Mukerjee 25
26. Use Case Model : Actors
Actors will interact with the
system
Product
Input Information Manager
Request Information
Who could be
Distinct individuals
Same individual with Salesman
multiple roles
Other computer systems
Production
Planning
System
Financial
Prithwis System
Mukerjee 26
27. Use Case Models
Define the tasks that the
Actors will pursue Define Product
Product
for example Manager
Define a Product
Define a new Customer
Define Customer
Create an Order
List of all Outstanding Orders Salesman
List of all fulfilled Orders Create Order
Create USE CASE diagram
UML syntax
Stick figures - actors Update Order
Ovals – use cases
System boundary
No control on anything Display
Prithwis
outside the system Outstanding
Mukerjee Orders 27
28. Use Case Diagrams
Use Case Diagrams describe the functionality of a
system and users of the system. These diagrams contain
the following elements:
Actors, which represent users of a system, including human
users and other systems.
Use Cases, which represent functionality or services provided
by a system to users.
Prithwis
Mukerjee 28
29. Scenarios
A USE CASE could consist of a number of scenarios
A USE CASE specifies a goal
Create ORDER, Create Customer
A SCENARIO represents a particular outcome when attempting
to reach the goal.
Create Order
Old customer, good credit rating
New customer, no credit rating
Old customer, bad credit rating
The action to be followed in each case will be different
In a formal development process, each scenario would
have its own documentation describing in detail all the
events in the scenario
Prithwis
Mukerjee 29
30. Use Case Descriptions
Detailed Description of what the USE CASE means
The USE CASE diagram gives the big picture but does not
provide detailed description of what is happening
Various formats are possible
Paragraph of text
Two Column approach
First column : Actor action
Second column : System action
More complexity
Pre-condition
Post-condition
Sequence of steps
Activity Diagram or Flowchart
Sequence Diagram
Prithwis
Mukerjee 30
31. Activity Diagram
Display
Order Entry
Screen
Does NO
Customer
exist ?
Define Customer
Order value NO Display
within
Error Message
credit ?
Add Order
Prithwis Record
Mukerjee 31
32. From Use Cases to Classes
“Nouns” in the Use Cases Class Diagram is the
are candidates for connection between
Classes Object Oriented
Order, Customer Programming techniques of
Attributes the Unified Process and
Order number, customer id Data Modelling techniques
that result in Entities and
“Verbs” in the Use Cases
Attributes in Third Normal
are candidates for form
Methods
Identification of Classes,
Attributes, Methods is an
iterative process
Prithwis
Mukerjee 32
33. Class Diagrams
ORDER CUSTOMER
Order ID N 1 Customer ID
Order Date Customer Name
Customer ID Customer Address
Order Value Customer Credit Limit
Receive, Update, Bill 1 Create, Update,
CreditCheck, ...
ORDER ITEM N PRODUCT
Order ID Product ID
Item ID Product Desc
Product ID N 1 Product unit price
Item quantity Create, SetPrice
Item Deliver Date
Create, Deliver Optional, May Have
Prithwis Mandatory, Must Have
Mukerjee 33
34. Class Diagrams
Class Diagrams describe the static structure of a system,
or how it is structured rather than how it behaves. These
diagrams contain the following elements.
Classes, which represent entities with common characteristics
or features. These features include attributes, operations and
associations.
Associations, which represent relationships that relate two or
more other classes where the relationships have common
characteristics or features. These attributes and operations.
Prithwis
Mukerjee 34
35. Sequence Diagram
:Main
Salesman Screen
Start
Challenge : Order
Entry Screen
ID/PW
New
Order Order-Item
New
: Order
Item Screen
New Get Data
New
: Order
Item Screen
New Get Data
New
X
Prithwis
X
Mukerjee 35
36. Sequence Diagrams
Sequence Diagrams describe interactions among
classes. These diagrams focus on classes and the
messages they exchange to accomplish some desired
behavior. Sequence diagrams contain the following
elements:
Class roles, which represent roles that objects may play within
the interaction.
Lifelines, which represent the existence of an object over a
period of time.
Activations, which represent the time during which an object is
performing an operation.
Messages, which represent communication between objects.
Prithwis
Mukerjee 36
38. Benefits of a Use-Case Driven Process
Use cases are concise, simple, and understandable by a
wide range of stakeholders
End users, developers and acquirers understand functional
requirements of the system
Use cases drive numerous activities in the process:
Creation and validation of the design model
Definition of test cases and procedures of the test model
Planning of iterations
Creation of user documentation
System deployment
Use cases help synchronize the content of different
models
38
39. Summary: Unified Process
The Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting
the artifacts of a software-intensive system
A software development process defines Who is doing
What, When and How in building a software product
The Rational Unified Process has four phases: Inception,
Elaboration, Construction and Transition
Each phase ends at a major milestone and contains one
or more iterations
An iteration is a distinct sequence of activities with an
established plan and evaluation criteria, resulting in an
executable release
Rational Unified Process is a commercial version of 39
Editor's Notes
The UML provides a single, common modeling language that is useable across many methods, across the entire lifecycle, and across many different implementation technologies. It maps the artifacts between business engineering, requirements capture and analysis, design, implementation, and test. It defines an expressive and consistent notation that can point out omissions and inconsistencies. It scales to support very small to very large systems development. If facilitates effective communications with all members of the development team. We are beginning the transition from the UML to the RUP. The students are not expected to be able to read this slide. The point is just to summarize all of the UML diagrams used for visual modeling. You might point out that learning the UML and all of its diagrams is not enough for a developer to be successful. It is similar to learning a natural language like English by reading the dictionary. You might know all the words and even the syntax, but you wouldn’t be able to effectively communicate. So the UML is a crucial first step as it gives us a common language with which to communicate. But a process is needed to understand how to apply the UML to ensure successful development efforts. That’s why we developed the RUP. Activity diagrams are not shown on the slide. Activity diagrams can be used to model workflows in business process engineering.
The important point to get across is that use cases permeate all parts of RUP and are a key mechanism in accomplishing the Managing Requirements best practice.