1. Waterfall Development Process
analysis
design
implementation
testing
maintenance
Linear
one phase is completed before the next begins
in practice, must revise earlier decisions based on experience in project - I.e. there is feedback

2. Waterfall Development Process
analysis
design
implementation
testing
maintenance
Not iterative
errors in earlier phases are really expensive to fix
doesn’t allow for prototyping which is a strong aid for confirming requirements

3. A Generic Spiral Process for Development
evaluate
Engineer
(design, implement, test)
Analyze requirements
for this iteration
Analyze risks / plan
Studies show more successes with an iterative approach
4 phases comprise one iteration
arbitrary number of iterations
user involvement
early feedback

4. Unified Process (UP)
Defined by Rational Corporation
Booch, Rumbaugh, Jacobson
An iterative development process
an iteration yields a working system
iterations last anywhere from 2 weeks to 6 months
many iterations make a project
risk-driven
early iterations prove out the major risks or show-stoppers

5. Unified Process (UP)
several activities
deliverables are referred to as artifacts - works produced (use cases, code, database designs, …)
4 phases
inception, elaboration, construction, transition
Inception
Use case model is started

6. Figure 2.4 Illustrates the activities in UP used to develop a system
Iterative development is central to the UP

7. Figure 2.3 illustrates the 4 phases comprising the UP
More requirements gathering
More programming

8. Unified Modeling Language (UML)
Booch, Rumbaugh, Jacobson (the 3 Amigos) joined forces (all work for Rational) to create a unified development method/process, from which came the Unified Modeling Language (UML)
Not a methodology
Methodologies can use UML
examples: Rational’s Unified Process; Catalysis
value of UML is in the common language IT professionals have for expressing the nature of a system

9. Use Cases
Use Cases help with:
requirements capture
scope definition
iteration management
test planning

10. Use Cases
a Use Case is initiated by an Actor
Describes functional requirements from the user’s perspective
illustrate actors & tasks
forms:
pictorial (defined in UML)
textual
not defined in UML
recommended to leave UI details out and focus on the purpose of the use case
focus on what the system does, not how it does it (black box)

11. Use Cases
Use cases can be used to identify/specify iterations
what is done first
second, third, etc.
What do you choose to do when? Use Case with
highest risk
greatest complexity
no risks nor complexity

12. Use Cases
Risks/dangers when using use cases:
too much focus on functionality may lead to non-OO system
need time to allow time to refactor

13. Use Cases
numerous forms
brief, casual, fully dressed
single- vs two-column form
common format at

14. Suppose our system interacts with a billing system:
Actors
An actor is anyone or thing that interacts with the system. These people or things are at the boundaries of the system.
Suppose our system interacts with a billing system:
Chair
Assign duties
Billing
Browse enrollments
Instructor
Assign grades
Its common to place non-human roles on the RHS
Register for courses
Student

15. Use Case Diagram

16. System Responsibilities
Summary Use Case
simplifies steps and details, an incomplete first draft.
Useful during early requirements and scope analysis
Actor Intentions
1. Customer presents items to rent.
2. Clerk records items.
5. Customer pays.
System Responsibilities
3. Remember rented items.
4. Calculate and present price.
6. Authorize and record payment.

17. Detailed Use Case

18. An Order-Processing System
Place order
Get Order status
Customer Rep
Send catalog
Customer
Cancel order
Shipping company
Return product
Deliver product
Supplier
Send us product
Calculate postage
Clerk

19. casual
Cancel Order Use Case
When the customer rep receives a request to cancel an order, the customer rep finds the order in the system and marks it canceled. Then a request is sent to the accounting system to credit the customer’s account

20. More formally
Cancel Order Use Case
1. The use case begins when the customer rep receives a request to cancel an order
2. The customer rep enters an order ID
3. The customer rep presses Find
4. The system will display that order
5. The system marks the order canceled
6. The accounting system is notified to credit the customer’s account and the use case ends

21. Jacobson: estimates a 10-person-year project has 20 use cases
How many Use Cases?
Jacobson: estimates a 10-person-year project has 20 use cases
Fowler: based on a recent project … about 100 use cases
Use cases vary in granularity - Fowler prefers smaller-grained use cases
Why was this important?
It clarified our vocabulary and
It included all the parts we needed to function
Discuss other ways to write use cases
narrative
formal scripts

22. Scenarios
A scenario refers to a single path through a use case, one that shows a particular combination of conditions within that use case.
Consider a Use Case for ordering goods:
Several associated scenarios:
one in which all goes well
one in which there are not enough goods
one in which our credit is refused
etc
Why was this important?
It clarified our vocabulary and
It included all the parts we needed to function
Discuss other ways to write use cases
narrative
formal scripts

23. Scenarios A Scenario is an instance of a Use Case.
Hence, each Use Case usually has many possible Scenarios
For example, two scenarios for Assign grades:
Instructor Jim Jones assigns the grade of A+ to student Eddy Match in the course Intro to Warehousing.
Instructor Jim Jones tries to assign the grade of B to student Edward Watson in the course Intro to Warehousing, but cannot because there is no record of Edward’s registration in the course.