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

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

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

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

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

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

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

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

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

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)

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

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

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

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

Use Case Diagram

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.

Detailed Use Case

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

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

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

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

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

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.