Upload
shanon-tyler
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
Rational Unified Process (Part 1)
CS3300Fall 2015
The Four P’s
• People (Roles)
• Product (Artifacts)
• Process (Templates / Workflow)
• Project (bundles everything together)
9/9/14
Definition
• Use Case Driven – Successful system must build what users want.
• Architecture Centric – Capture significant static and dynamic aspects of the system.
• Iterative and Incremental – Need to divide larger projects into smaller “mini-projects”
Phases
• Inception – Understand business case, identify use cases, feasibility, cost and planning
• Elaboration – Detailing of use cases for this iteration, refinement of system architecture (the skeleton)
• Construction – build product (put meat on the skeleton)
• Transition – Customer/User tests and interaction
• See paper for more detailed information
Inception Phase Outcomes
• A vision document: a general vision of the core project's requirements, key features, and main constraints.
• A initial use-case model (10% -20%) complete).
• An initial project glossary (may optionally be partially expressed as a domain model).
• An initial business case, which includes business context, success criteria (revenue projection, market recognition, and so on), and financial forecast.
• An initial risk assessment.
• A project plan, showing phases and iterations.
• A business model, if necessary.
• One or several prototypes.
9/9/14
Elaboration Phase Outcomes• A use-case model (at least 80% complete) — all use cases and
actors have been identified, and most usecase descriptions have been developed.
• Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case.
• A Software Architecture Description.
• An executable architectural prototype.
• A revised risk list and a revised business case.
• A development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation criteria for each iteration.
• An updated development case specifying the process to be used.
• A preliminary user manual (optional).
9/9/14
Construction Phase Outcomes
• The software product integrated on the adequate platforms.
• The user manuals.
• A description of the current release.9/9/14
Transition Phase Outcomes
• Achieving user self-supportability
• Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision
• Achieving final product baseline as rapidly and cost effectively as practical
9/9/14
Final Check before next iteration:
Is the user satisfied?
Are the actual resources expenditures versus planned expenditures still acceptable?
Use Case Model
System
Withdraw Money
Deposit Money
Perform Audit
BankCustomer
Bank Manager
Additional Diagram Features
<<includes>> (like a subroutine, always executes)
<<extends>> (like an if statement, may execute)
<<precedes>> (precondition)
(generalization, specialized instance, replaces execution)
WARNING: Use this sparingly, and do not get wrapped around the axle on usage. The most important thing is the text anyway.
9/9/14
Use Case Detailed
UC1: Withdraw Money
Primary Actor: Bank Customer
Stakeholders and Interests:
-- Cashier : Wants accurate disbursement of money
-- Bank Manager : Wants audit trail of transactions
Preconditions: Customer authenticated on Bank system (UC12)
Postcondition: Customer has correct money in their possession and account is debited correct amount. Transaction entered on cashier record and on daily accounting record.
Main Success Scenario:
1. Customer requests transaction.
2. System displays transaction screen.
3. Customer selects withdrawal
4. System requests amount
5. Customer enters amount
6. System checks account for sufficient funds and daily withdraw limit
7. System opens cashier drawer
8. Cashier dispenses amount and closes drawer
9. System prints receipt
Use CaseAlternate Flows:
6A. Insufficient funds: System notifies customer and cashier of account balance and failure of transaction. Reprompts for new amount and resume 6. Customer may also cancel transaction.
6B. Daily Limit exceeded: System notifies….
Special Requirements: Cash Drawer, Customer Screen
Response within 5 seconds
Frequency of Occurrence: Could be continuous
Open Issues: Close drawer by mistake?
Your Turn
• Pick a use case appropriate to your team.
• Draw the diagram, and then detail it with name, precondition, postcondition and main success scenario
• Type the use case text into piazza
Analysis (Robustness) Diagrams
● Tie together the use case and the domain model● Graphically depict interactions between interface
elements and domain model elements● Should be able to walk through your use case
with the diagram● Use to refine use cases and domain model● Often referred to as robustness models because
they check quality of use case/domain model.
Components
● Actor – Stick figure from use cases● Boundary Elements – represent UI screens,
APIs and other interface elements● Control Elements – glue between boundary
and domain elements. Contains business logic. May or may not become classes in the design
● Domain Elements or Entities – things from the domain model that represent data in the system
Icons
● Actors – stick person
From http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/
Withdraw
Bank Customer
Transaction Select UI
Withdrawal UI
Transaction Manager
Account
Cash Drawer API Printer API
Log Files
Rules
● Actors can only talk to boundary objects.● Boundary objects can only talk to controllers
and actors.● Entity objects can only talk to controllers.● Controllers can talk to boundary objects and
entity objects, and to other controllers, but not to actors
● Show alternative actions● Don't put design into diagram
Your Turn
• Now draw an analysis model of your use case.
Next Individual Homework
• Complete and Polish the Use Case Detail
• Complete and Polish the Analysis Model