Waterfall Development

Characteristics
Introduction to the Waterfall Process
Feasibility Study
Characteristics
Delays confirmation of critical
Unified Process
‹ ‹

‹ Requirements risk resolution

Analysis ‹ Measures progress by assessing
‹ Design work-products that are poor
Acknowledgement ‹ Programming predictors of time-to-completion
Some of the slides are adapted from the course “Object-Oriented ‹ Unit test ‹ Delays and aggregates
Analysis and Design Using UML” by Rational Software integration and testing
‹ Integration test
‹ User training ‹ Precludes early deployment
‹ Changeover ‹ Frequently results in major
‹ Maintenance unplanned iterations. 2

Iterative Development Risk Profiles

Requirements
Analysis & Design
Planning
Initial
Planning Implementation
Management
Environment

Evaluation
Deployment
Test
Each iteration
results in an
executable release
3 4
Resilient, Component-Based Purpose of a Component-Based
Architectures Architecture
‹ Resilient ‹ Basis for reuse
Component-based Component reuse
„ Meets current and future requirements „
architecture with „ Architecture reuse
„ Improves extensibility layers
‹ Basis for project management
„ Enables reuse
„ Planning
„ Encapsulates system dependencies Application- „ Staffing
‹ Component-based specific
„ Delivery
Business-
„ Reuse or customize components specific
‹ Intellectual control
„ Select from commercially-available components Middleware „ Manage complexity
„ Evolve existing software incrementally. System- „ Maintain integrity.
5 software 6

Continously Verify Your Software’s

Visual Modelling with UML Quality
Use case
Diagram
Class Diagram Statechart ‹ Earlier detection and repair
Diagram
Problems found earlier are less costly to repair
add file

„
DocumentList
Use Case 1 FileMgr Document

add( )
Actor A Actor B fetchDoc( ) delete( )
name : int
docid : int
sortByName( ) numField : int
add file [ numberOffile==MAX ] / Writing
flag OFF
get( )
open( ) read() fill the
Use Case 2 close( ) code..

Problems found and fixed earlier lead to higher quality

FileList read( ) Openning
sortFileList( )
fList create( )

„
fillDocument( ) close file
add( )
delete( )
1

Use Case 3 close file

Closing
Reading

software
rep

File

Deployment
Repository

(from Persistence) GrpFile

read( )
name : char * = 0

read( )
readDoc( )

Collaboration
open( )
readFile( )
create( )

Diagram
fillFile( )

Diagram mainWnd : MainWnd

9: sortByName ( )

FileManager
Repository DocumentList

Window9 5
Windows9 5

Windows9 5
„ Identifying and resolving problems earlier result in
more realistic and reliable development schedules
1: Doc view request ( )

2: fetchDoc( ) ¹®¼-°ü¸®
Ŭ¶óÀ̾ ðÆ ®.EXE

4: create ( )
gFile : GrpFile Document ¹®¼-°ü¸® ¾ÖÇà ¸ ´

8: fillFile ( ) Windows
NT

user : »ç¿ëÀÚ Solaris

fileMgr : FileMgr ¹®¼-°ü¸® ¿£Áø.E XE

3: create ( ) GraphicFile Alpha

UNIX
ÀÀ ¿ë¼-¹ö .EXE
6: fillDocument ( )
File FileList
Windows
NT

IBM

7: readFile ( ) Mainframe

5: readDoc ( )
document : Document
repository : Repository
µ¥ÀÌŸº£ À̽º¼- ¹ö

user
mainWnd fileMgr :
FileMgr
document :
Document
gFile repository
Component
ƯÁ¤¹® ¼-¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äÃ»Ç Ñ´Ù.
1: Doc vie w requ est ( )

Diagram
Target
2: fetchDo c( )

3: create ( )

Forward and
4: create ( )

5: readDo c ( )

System
È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( )
¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹® ¼-
°´Ã¼¿¡ ¼ ³Á¤À» ¿äÃ»Ç Ñ´Ù.

Reverse
7: readFile ( )

8: fillFile ( )

È-¸é °´Ã¼ ´Â ÀÐ ¾îµéÀÎ 9: sortBy Name ( )

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ ÃÄÑ È- ¸é¿¡
º¸¿©ÁØ´ Ù.

Engineering
Sequence 7 8
Diagram
Test Each Iteration What Do You Want to Control?
Parallel
‹ UML Workspace
Management Development

model and
implemen- CM is more than ALERT

tation just check-in and Process

REPORT
Build
check-out Integration Management

‹ Control, track, and monitor changes to enable iterative

‹ Tests development
‹ Establish secure workspaces for each developer
‹ Automate integration and build management
9 ‹ Control parallel development. 10

Rational Unified Process Achieving Best Practices through ...

‹ An iterative approach
‹ Guidance for activities and work products
(artifacts)
‹ Process focus on architecture
‹ Use cases (collection of scenarios) which drive
design and implementation
‹ Models which abstract the system.

11 12
A Team-Based Definition of Process Phases in the Process
‹ A process defines who is doing what, when and UP has four phases:
how to reach a certain goal. ‹ Inception: Define the scope of project
‹ Elaboration: Plan project, specify features, baseline architecture
‹ Construction: Build the product
Software
Software new or changed Transition: Transition the product into end user community
new or changed ‹
Engineering
requirements Engineering system time
Process
Process
Inception Elaboration Construction Transition

Major
13 Milestones 14

Inception Phase Elaboration Phase

‹ Purpose ‹ Purpose
„ To establish the business case for a new system or for a major „ To analyze the problem domain
update of an existing system „ To establish a sound architectural foundation
„ To specify the project scope „ To address the highest risk elements of the project
‹ Outcome „ To develop a comprehensive plan showing how the project will
„ A general vision of the project’s requirements, i.e., the core be completed
requirements ‹ Outcome
Initial use-case model and domain model (10-20% complete)
„
„ Use-case and domain model 80% complete
„ An initial business case, including: „ An executable architecture and accompanying documentation
„ Success criteria (e.g., revenue projection)
„ An initial risk assessment
„ A revised business case, including revised risk assessment
„ An estimate of resources required „ A development plan for the overall project
‹ Milestone: Lifecycle objectives. ‹ Milestone: Lifecycle architecture.
Construction Phase Transition Phase
‹ Purpose ‹ Purpose
„ To incrementally develop a complete software product which is „ To transition the software product into the user community
ready to transition into the user community ‹ Products
‹ Products „ Executable releases
„ A complete use-case and design model „ Updated system models
„ Executable releases of increasing functionality „ Evaluation criteria for each iteration
„ User documentation „ Release descriptions, including quality assurance results
„ Deployment documentation „ Updated user manuals
„ Evaluation criteria for each iteration „ Updated deployment documentation
„ Release descriptions, including quality assurance results „ “Post-mortem” analysis of project performance
„ Updated development plan ‹ Milestone: Product release.
‹ Milestone: Initial operational capability.

Iterations and Phases Workflow Notation

‹ An iteration is a distinct sequence of activities with an Role
A unit of work
that a role may be
established plan and evaluation criteria, resulting in an asked to perform
executable release (internal or external).
A role may be
Inception Elaboration Construction Transition played by an Describe a Activity
individual or a Requirements
Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition team in the Use Case
Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration development
Specifier
organization A piece of information
that is produced, modified,
responsible for or used by a process

Use Case Use-Case Artifact

Releases
19
Package 20
Roles Are Used for Resource
Planning Example of a Workflow
‹ Each individual in the project is assigned to one or
several roles
Human
Role Activities
Resource
Paul Designer Define Operations …

Mary Use-Case Specifier Describe a Use Case …

Joe Use-Case Designer Distribute Behavior …

Sylvia Design Reviewer Review Use-Case Model …

Define Use-Case View
Stefan Architect
Define Logical View … 21 22

Bringing it All Together:

Models and Workflows The Iterative Approach Workflows group
activities logically
Business Each major workflow
Modeling Business
describes how to create and
Business Model
Object Model maintain a particular model In an iteration,
Requirements you walk through
Workflow Use-Case Model
realized by all workflows

Analysis Design implemented by

Workflow Each interation
Analysis Model Design Model
verified by results in an
executable release
Implementation
Workflow Implementation Model

Test Workflow 23 24
Test Model
Workflows Guide Iterative Workflows Guide Iterative
Development Development
Business Modeling: Analysis and Design:
Workflow Details Workflow Details

Requirements: Implementation:
Workflow Details Workflow Details
25 26

Warning For More Reading

This is not a workflow: Develop Iteratively
‹ Most software teams still use a waterfall process for
development projects, completing in strict sequence the

⊗
phases of requirement analysis, design, implementation,
integration and test.
‹ UP represents an iterative approach:
„ It lets you take into account changing requirements.
„ Integration is not one “big bang” at the end; instead, elements are
integrated progressively. With UP, what used to be a lengthy
time of uncertainty and pain -- taking up to 40% of the total effort
at the end of a project -- is broken down into six to nine smaller
integrations involving fewer elements.
27 28
For More Reading For More Reading
Develop Iteratively Develop Iteratively
„ Risks are usually discovered or addressed during integration. ‹ Project managers often resist the iterative approach,
With the iterative approach, you can mitigate risks earlier.
seeing it as a kind of endless and uncontrolled
„ Iterative development provides management with a means of
making tactical changes to the product -- to compete with hacking. In UP, the iterative approach is very
existing products, for example. It allows you to release a product controlled; the number, duration, and objectives of
early with reduced functionality to counter a move by a iterations are carefully planned, and the tasks and
competitor, or to adopt another vendor for a given technology.
„ Iteration facilitates reuse; it is easier to identify reusable
responsibilities of participants are well defined.
components as they are partially designed or implemented than to
recognize them during planning.
„ When you can correct errors over several iterations, the result is a
more robust architecture.
29 30