Exercise 10: Demo Management Flashcards
Murphy’s Law
“Anything that can go wrong, will go wrong”
Alternative phrasings:
When things are going well, something will go wrong.
When things just can’t get worse, they will.
When things appear to be going better, you have overlooked something
Risk has materialized: No Backend Available
- The outsourcing company was not able to deliver a working backend
- How can we manage this problem?
- Tornado Model (scenario-based design)
- Mock Objects allow us to deal with non-existing components
Tornado Model:
From Visionary Scenario to Demo Scenario
Scenario-based Design: Starting with the Problem Statement
The Problem Statement was given by the customer.
Section 2 of the Problem Statement describes the Visionary Scenarios by the Customer
- Developers transform the Visionary Scenarios into Formalized Scenarios
- A Formalized Scenario consists of 6 components:
- Scenario Name
- Participating Actors
- Flow of Events
- Entry Conditions
- Exit Conditions
- Quality Requirements
Formalized Scenario - compoments
- ScenarioName
- The Scenario Name should contain at least a
noun and a verb
- Participating Actors
- The participating actor should be a concrete
user of the system. Also include the role.
- Flow of Events
- Describes the interaction between the Actors and the System. Indentation helps to distinguish between user input and system response.
- Entry Conditions
- Defines conditions that have to be met before the Flow of Events can start.
- Exit Conditions
- Defines conditions that have to be true at the end of the Flow of Events.
- Quality Requirements
- These are the non-functional Requirements for the Scenario.
Writing the Screenplay
- A Screenplay consists of
- Scenes describing the event flow and participating actors of the Formalized
Scenario which are needed for the Demo Scenario
- Scenes describing the event flow and participating actors of the Formalized
- Additional information such as props and stage directions
Identification of Participating Methods and Objects
- Inspect the flow of events in your Screenplay
- Do a textual analysis (noun-verb analysis)
- Nouns are candidates for classes (Participating Objects)
- Verbs are candidates for operations (Participating Methods)
- ➡ This analysis is also called Abbott’s Technique
- Create a Class Diagram from these Participating Objects and Methods
Demo Backlog: A collection of action items for the Demo
- Action Items are added to the Demo Backlog
- They describe Implementation tasks and other tasks such as the acquisition of props
- The Manager owns this backlog and is responsible for its realization
Can we still do the demo without the backend?
Yes, we can! We use Model-based demonstration
1) We start with the System Model
2) We identify the System Under Demo, SUD
3) The SUD does not exist in isolation, it interacts with other objects that are not yet implemented: Collaborators
4) To be able to interact with Collaborators, we create Mocks
5) Mocks mimic the behavior of the Collaborators
Model-based Demonstration in General
- We start with the System Model
- The system contains the objects we need for the demonstration (System Under Demo, SUD)
- The SUD does not exist in isolation, it interacts with other participating objects in the system model that are not yet implemented: Collaborators
- To be able to interact with Collaborators, we add objects to the Demo Model
- These objects mimic the behavior of the Collaborators and are called Mocks
Mock-Object Pattern
- The Mock Collaborator replaces the behavior of the Collaborator (the real object)
- A mock object can be created at startup-time with a factory pattern
- Mock objects can be used for testing state of individual objects as well as the interaction between objects.
Last Step: Demo Feedback
- The developers deliver the Demo Application to the customer
- They present the Demo Application and request feedback from the customer
- The feedback is then used to refine the Visionary Scenario
