You are only in a hurry till you get to the front of the queue

Thursday, 4 October 2012

Project Management goodies

Chuck Morrison, MBA, PMP, CPIM | Project Management and Business Architecture Professional:

'via Blog this'

Original page copied without editing for my sanity. Sites seem to disappear without notice and that annoys me when I need to find something urgently. Go to the link above for the original.






Out of Chaos … Order: Use Cases


9 Votes

The hardest single part of building a software system is deciding precisely what to build (… and, exactly where to begin).
– Frederick Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering.”
Those who cannot remember ( … learn from) the past are condemned to repeat it.
– George Santyana, “The Life of Reason: Volume 1, Reason in Common Sense.”
There is one timeless way of building. It is a thousand years old, and the same today as it has always been …
– Christopher Alexander, “The Timeless Way of Building.”
Imagine …
  • You were just assigned to a major, important project.
  • You’re to be part of a team that must deliver a training curriculum for several critical DMDC/DEERS applications which you and your team have never seen nor heard of before.
  • More precisely, you must deliver a set of courses without a page written to people you’ve never met, about topics you haven’t a clue, within a timeframe not yet decided.
  • What do you want to do, where do you begin …
Why Use Cases? … to learn from the past and the unknown.
  • Analyze What (Requirements – Scope, Context, Scenarios)
  • Decompose Functional System Behavior – Value
  • Divide Roles, Data, and Rules from System Behaviors
  • Measure/Validate Goals and Tasks in Context
  • Estimate Project Build and Release Schedule and Resources
  • Separate Function from User Interface and Technology
Use Case Models describe proposed functionality of a system. A Use Case represents a coherent, discrete unit of interaction between users (human or machine) and the system. This interaction is a single, coherent unit of meaningful work, such as Create Account or View Account Details.
Each Use Case describes the functionality needed to build in the proposed system, which can include another Use Case’s functionality or extend another Use Case with its own behavior. A collection of Use Cases may be loosely coupled within a coherent component (container) of related services to facilitate effective, efficient release and delivery of functionality for achieving user goals and business value.
When do we start use case analysis?
  • During requirements elicitation (e.g., JAD, Brainstorming, …)
    • Obtain agreement on major concepts – Actors, system boundaries, business use cases, Business Rules
    • Make a sketch … transfer to tool later
  • During requirements analysis
    • Insure the right questions are asked and answered
    • Supplement complex text with pictures (… worth a thousand words)
    • Disambiguate text with precise models
When do we stop doing use case analysis?
  • When the use cases meet communication/expectation needs
    • Stakeholders reach consensus
    • Less is more
Use Case descriptions include:
  • General comments and notes describing the use case.
  • Requirements – formal functionality a Use Case must provide for users to achieve goals e.g., ability to add, review, update, or delete (CRUD) an order. Requirements correspond to functional specifications found in structured methodologies i.e., “Waterfall”, and form a “contract” that the Use Case must perform specified action of value to the system (goals).
  • Constraints- formal rules and limitations a Use Case operates under, defining what can and cannot be done including:
    • Pre-conditions – must have already occurred or be in place before the use case runs; e.g., <create order> must precede <modify order>
    • Post-conditions – must be true once the Use Case is complete; for example, <order is modified and consistent>
    • Invariants – must evaluate as true throughout the Use Case scenario; for example, an order must always have a customer number.
  • Scenario – formal, sequential description of the steps taken to carry out the use case flow of events that occur during a Use Case instance. Includes multiple scenarios needed to control exceptional circumstances and alternative processing paths resulting from decisions; i.e., textual representation of the Sequence Diagram.
  • Activity diagrams – activity diagrams depict workflow; similar to Scenarios but graphically portrayed.
  • Additional attributes – e.g., implementation phase, version number, complexity rating, stereotype (<<Include>> or <<extend>>) and status.
Use Case Analysis Effectively Supports –
  • Iterative, Incremental Process (RUP, Agile) – Time-Boxed, Cross-Functional (SCRUM)
  • Use Case Driven Requirements (Scope) – Discovery, Planning, Analysis, Design, Monitoring, Control: UML
  • Architecture, Infrastructure Centric Development
  • Flexible Guideline/Framework Adaptable to Project Needs
Use Case Basics (toward Collaborative Conversation & Consensus) 
  • Use case (UC) – visual and narrative description of a sequence of actions (story – scenario) providing measurable value to an actor – “What NOT How” – drawn as horizontal ellipse in “Verb/Object” form.
  • Actor – person, places, thing, time, or external system that plays a role in one or more interactions (associations) with your system; drawn as stick figure.
  • Association – An association exists whenever an actor interacts with a use case; indicated in use case diagrams by solid lines. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. An arrowhead indicates directionality of initial relationship invocation or indicates a use case ‘s primary actors; arrowheads are often confused with data flow.
  • System Bounds (Domain, Context, Scope) – dashed rectangle surrounding the use cases; called the system bounds box. The box represents functionality within scope or context; anything outside the box is out of scope (context). System bound boxes identify which use cases will be delivered as component packaged services in each major release of a system.
  • Packages (optional) – UML constructs (containers) enabling modeling of elements (such as use cases) into deliverable groups. Packages are depicted as file folders used in any UML diagrams, including use case, activity, sequence, class, or other diagrams. Use packages to organize large diagrams into smaller ones.
Use Case Relationships (Extend, Include, Generalization) …
  • Include – one use case includes another; “… a Directed Relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case“ [OMG 2008] i.e., the outcome of a given use case depends on the outcome of the included use case; useful for containing common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label “«include»”.
  • Extend – one use case (the extension) extends another. The behavior of the extension use case is inserted into the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label “«extend»”. Notes or constraints are associated with this relationship to illustrate conditions when this behavior is executed. Modelers use the «extend» relationship to indicate use cases that are “optional” to the base use case.
  • Generalization – A given use case may have common behaviors, requirements, constraints, and assumptions with a more general use case.
Activity Diagram Basics (Use Case Scenario – Diagram, Narrative) …
  • Initial node – solid circle indicates starting point of the diagram.
  • Activity – represented by a rounded rectangle. Activities are physical, such as “Audit Record”, or electronic, such as “Display Policy Coverage”.
  • Flow/edge – arrows on the diagram.
  • Fork – black bar with one flow going into it and several leaving it. Denotes the beginning of parallel activity.
  • Join – black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue; denotes the end of parallel processing (concurrency).
  • Condition – text such as [Invalid Record] on a flow, defining a guard (pre-condition) which must evaluate to true in order to traverse a node.
  • Decision (Business Rule) – a diamond with one flow entering and several leaving . The exiting flows include post-conditions although not indicated if obvious.
  • Merge (Business Rule) – a diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards (post-conditions) on the outgoing flow.
  • Swimlane (Domain, Context) – optional vertical or horizontal partitions, also called swimlanes, indicating who/what (Actor – Role) is performing the activities and decisions (either the Actor or System) in the Use Case scenario.
  • Flow final – a solid circle within a circle indicates the scenario stops at this point.
  • Business Rule – statement defining or constraining some aspect of a business; intended to assert business structure or to control or influence the behavior and of the business. Business rules describe the operations, definitions, persistence (data, structures), and constraints associated with Actors in achieving goals.
Use Case Narrative – Use cases identify usage or functional goals of a system; automated or manual. When an actor attempts to accomplish a system goal, there are decisions and associated business rules that change the use case outcome depending on what decision is made. Exception conditions may also be triggered that affect the accomplishment of a goal using alternative action flows depending on the decision made by an actor. Although a use case diagram provides a convenient view of the main features of a system, it is too concise to describe what users are expecting. So, as with most diagrams, use cases are optionally supported with narrative.
  • Use Case Name – Action Verb/Object pair – Use Cases are triggered by events that occur NOW!!! … not the past nor future tense.
  • Use Case Name – Unique Use Case identifier
  • Author – Who wrote the Use Case
  • Last Update – date the use case was last updated
  • Use Case Description – Describing a use case requires that we both frame the context of the use case and describe the dialog between an actor or another use case and the general sequence within the scope of a given Use Case.
  • Assumptions (Constraints) – Conditions that must evaluate as true to use a specific use case action flow. Validating these conditions (business rules) is outside the scope of a use case (contrast this with the pre-conditions and post-conditions … or guard conditions) e.g., consider authentication or authorization– these functions are typically handled by a standard security feature e.g., the user has provided a valid card and password.
  • Pre-Conditions – Conditions that must evaluate as true to initialize a use case. Unlike assumptions, these conditions are validated by this use case before entry into an action sequence. If the conditions are not true, the actor or other use case is refused entry.
  • Post-Conditions – Conditions that must evaluate as true when the use case ends. You may never know what comes after the use case ends, so you must guarantee that the system is in a stable state when the use case ends e.g., upon successful completion of an ATM withdrawal.
  • Use Case Dialog – A step-by-step description of the dialog between a use case (the system) and the user (actor or other use case). Very often it is helpful to model this sequence of events using a flowchart or activity diagram just as you might model a communication protocol between two business units e.g., the system asks for the withdrawal amount.
  • Use Case Termination – Occurs when the Use Case ends Successfully.
Narrative Example
  • Name: Withdraw Cash from ATM
  • Assumption: User provided valid ATM card and password.
  • Pre-Condition: The User has an Account with this Bank
  • Main Dialog:
    • The user selects an amount for withdrawal.
    • The ATM verifies that amount entered is within the predefined policy limits and is an amount divisible by the defined denomination, for example, multiples of $20.00.
    • If the funds are available, the ATM gives the user their money and prints a receipt.
  • Alternative Dialogs:
    • If the amount fails at main step 2, an error message is displayed
    • If funds not available, the user gets an error message.
    • System displays a message that it cannot connect to the bank.
    • User cancels the transaction.
  • Termination:
    • The system dispenses the specified cash and prints a receipt.
    • The system displays a message that the entered amount is invalid.
    • The system displays a message that it could not connect with the bank.
    • The user cancels the transaction.
  • Post-Conditions:
    • System prints the final outcome on the receipt.
    • User account is updated.
    • Transaction logged
    • Upon error condition, ATM returns to initial state.
    • Upon receiving Cancel, ATM returns to initial state .
©2003-2012 Chuck Morrison, Hollister, CA, All rights reserved

0 comments :

Post a Comment

Thank you for taking the time to comment. Your opinion is important and of value and we appreciate the positive feedback! If you are "Negative Nancy" then please do us, and humanity, a favor and piss off.

Total Pageviews

Google+ Followers

Interesting pages

Blog Archive

Popular Posts

Recent Comments

Rays Twitter feed

Ads

Web sites come and go and information is lost and therefore some pages are archived. @rayd123 . Powered by Blogger.