Reasoning About Precisely Defined
Processes
Leon J. Osterweil ([email protected])
Lab. For Advanced SE Research (LASER)
http://laser.cs.umass.edu
University of Massachusetts
Amherst, MA 01003
Institute for Software Research
University of California Irvine
25 April 2014
Thanks to Collaborators
Faculty and Staff
• Lori A. Clarke
• George Avrunin
• Barbara Lerner
• Sandy Wise
Students
• Bobby Simidchieva
• M.S. Raunak
• Stefan Christov
• Huong Phan
• Heather Conboy
• Xiang Zhou
• Seung Yeob Shin
• Huong Phan
– And others….
A Focus on Human-Intensive Systems
• Integrate contributions of
– Software systems
– Hardware devices
– Human participants
• They control much of the world’s work
– So it is important that they be defect-free, secure
• They are increasingly complex
– Concurrent, distributed, complex, exception rich
– Making it hard to be sure of them
Some Examples
• Elections
• Medical Procedures
– Blood transfusion
– Chemotherapy administration
•
•
•
•
Software Development
Management processes
Manufacturing Processes
Emergency planning and support
Some Examples
• Elections
• Medical Procedures
– Blood transfusion
– Chemotherapy administration
•
•
•
•
Software Development
Management processes
Manufacturing Processes
Emergency planning and support
Our Approach
• Human-intensive systems are collections of
processes
• Model them
• Analyze them
• Continuously improve them
An Example: Health Care Process Engineering
• ~100,000 people die in US hospitals each year due to
preventable medical errors
– 1999 IOM report estimate
– Doesn’t count serious injury, pain-and-suffering, needless
cost
• Errors like:
–
–
–
–
Transfusing the wrong type of blood
Delivering incorrect medication
Amputating the wrong leg
Removing the healthy lung (leaving the cancerous one in)
• Recent NY Times article estimates it is probably more
like 440,000 deaths per year
– Third leading cause of death in the US
Copyright L.J.Osterweil All
Rights reserved
~100,000 people each year in US
hospitals due to preventable errors
One fully loaded 747 per day
Another Example: Elections in the U.S.
• Elections entail far more than casting and tabulating votes
• Need to consider the entire process
– Voting machines play a part
– Humans are also key participants
– Databases too
• The election process is large and complex and, in the U.S.,
varies from jurisdiction to another
• Election processes vary over time as well
Goal
• To identify potential defects, threats to security, in election
processes and evaluate approaches to correcting them
Our Approach:
Continuous Process Improvement
• Create a precise, accurate model of a real-world
process
• Use formal analysis methods to automatically
identify potential problems in the model
– E.g. single points of failure (SPFs)
• Modify process model to address the problems
– Verify that the modification makes things better
• Deploy improvements in real-world process
Approach: Consider a process to be a kind of software:
Apply software engineering technologies
Programming Human-Intensive Processes
• Process programming language requirements:
– Capture complexity of systems clearly, cleanly, in detail
– Rich semantics
(e.g. functionality, concurrency, resource utilization,
exceptions, human participation)
– Precisely defined semantics to support static analysis,
simulations, and executions
– Understandable to the domain experts (facilitate
validation that the definition models actual process)
Process Improvement Environment Architecture
Device model
Requirements
Derivation
Derived
Requirements
Property elicitor
(PROPEL)
Properties
Process editor
(Little-JIL editor)
Process
definition
Little-JIL
narrator
Textual
representation of
process definition
Hazards
Fault tree
generator
Fault trees, minimal
cut sets
Failure
modes
Failure mode
and effects
analyzer
Effects of failure
modes
Scenario
specifications
Discrete event
simulator
Discrete event
simulation runs
Process definition +
requirements
Model Checker
(FLAVERS)
Analysis
Improvements, new family members
Satisfied properties,
violated properties +
counterexamples
Analysis Feedback
The Little-JIL Process Definition Language
•
•
•
•
•
•
•
•
•
•
•
•
•
Blends proactive and reactive control
Coordinates human and automated agents
Emphasizes exception specification, management
Facilities for abstraction, scoping, hierarchy
Supports artifact flow
Concurrency, synchronization with message-passing
Articulate specification of resources
Steps have agents that can be humans, software, hardware
Semantics for aborting steps
Pre/post condition constructs
Facilities for human choice
Rigorously defined using finite state machine semantics
Visual language
“Step” is the central Little-JIL abstraction
Interface Badge
(parameters, resources, agent)
Prerequisite Badge
Postrequisite Badge
TheStepName
X
Handlers
Substep sequencing
Exception type
Artifact
flows
continuation
Define an election process
• Use the Little-JIL process definition language
– Consists of coordination diagram, and other
specifications (e.g. agents, artifacts, resources)
– Especially appropriate for modeling concurrency
and complex exception handling that arise in
elections
– Visual representation facilitates communication
and validation
Top-Level, simplified election process
pass authentication and vote
present ID
Perform pre-vote
authentication
Check off
voter as voted
Issue ballot
Record voter preference
Hierarchy, Scoping, and Abstraction
in Little-JIL
• Definition is a hierarchical decomposition
• Think of steps as procedure invocations
– They define scopes
– Copy and restore argument semantics
• Encourages use of abstraction
– Eg. system fragment reuse
Adding some elaborations
pass authentication and vote
present ID
Perform pre-vote
authentication
=
Confirm voter ID
matches voter
Confirm voter ID
matches voting roll
Check off
voter as voted
Confirm voter
has not voted
Issue ballot
Record voter preference
Exception Handling: A Special Focus of
Little-JIL
• Steps may have one or more exception handlers
• Handlers are steps themselves
– With parameter flow
• React to exceptions thrown in descendent steps
– By Pre- or Post-requisites
– Or by Agents
• Four different continuations
And some exception management
pass authentication and vote
Missing ID Exception
Inadmissible ID Exception
ID Mismatch Exception
present ID
Exceptions:
Missing ID
Inadmissable ID
Perform pre-vote
authentication
=
Voter Already Checked Off
Exception
Check off
voter as voted
Issue ballot
Record voter preference
Let voter voter with
provisional ballot
Fill out provisional
ballot
Confirm voter ID
matches voter
Confirm voter ID
exceptions: matches voting roll
ID Mismatch
Confirm voter
has not voted
exceptions:
ID Mismatch
exceptions:
Voter Already
Checked Off
Submit
provisional
ballot
Properties needed to support Finite-State
Verification (Model-Checking)
• Refine the requirements for an election process
– High-level requirements
– Low-level requirements
– Precise properties, or event sequences
• Identify event alphabet
• Annotate graph with events used to define
properties
• Verify the process adheres to the properties
– Run formal analysis using finite-state verification
Decompose high-level requirements
• Example refinement of high-level requirement
into a collection of low-level requirements
each unique voter is allowed at most one vote
 voter must be authenticated
before entering voting booth
 voter must be checked off before
 voter must enter voting
booth before choosing to vote
 voter must receive ballot
 voter must leave
entering voting booth
before choosing to vote
voting booth after choosing to vote
Formally define the properties
Use the PROPEL property elicitation tool to
formally define a property corresponding to
the low-level requirement “voter must be
authenticated before entering voting booth”
Example property
Voter must be authenticated before entering voting booth:
•
Disciplined English view:
– VoterEntersVotingBooth cannot occur until after VoterIsAuthenticated has
occurred. VoterIsAuthenticated is not required to occur, however.
– VoterIsAuthenticated can occur multiple times before the first subsequent
VoterEntersVotingBooth occurs.
– After VoterIsAuthenticated occurs other events can occur before the first
subsequent VoterEntersVotingBooth occurs
– After VoterEntersVotingBooth occurs neither VoterIsAuthenticated nor
VoterEntersVotingBooth can occur again.
•
FSA view:
Binding property events to process steps
Property FSA specified in PROPEL
Yes, the process satisfies
the property
Little-JIL process definition
Bindings between property events
and process steps
FLAVERS finite-state verifier
OR
No, the property could be violated Here is
a counter-example
Finite-state verification with FLAVERS
• The FLAVERS FSV verifier has been extended to automatically
construct finite models of the Little-JIL process definitions
• Finite model represents all possible event sequences, for the events
in a property, that could occur for all the possible traces through the
process definition
• Apply dataflow analysis algorithm to determine if the model is
consistent with the property
• If the process is inconsistent with the property, a counter-example
trace is produced
• FLAVERS determines whether the election process, as defined in
Little-JIL, adheres to the property “voter must be authenticated
before entering voting booth”
Violation detected
•
An unauthenticated voter can vote with provisional ballot
– Counter-example produced by FLAVERS to demonstrate how the property “voter
must be authenticated before entering voting booth” could be violated
[pass authentication and vote]
[present ID]
[perform pre-vote authentication] (Voter Already Checked Off Exception)
[let voter vote with provisional ballot] (Voter Enters Voting Booth Event)
[fill out provisional ballot] (Voter Votes Or Does Not Vote Event)
[submit provisional ballot] (Voter Leaves Voting Booth Event)
Violation detected
•
An unauthenticated voter can vote with provisional ballot
– Counter-example produced by FLAVERS to demonstrate how the property “voter
must be authenticated before entering voting booth” could be violated
Violation explanation
• The parallel step creates a race condition
– The pre-vote authentication step is executed in parallel with
two others
– Exceptions can occur in any order
– Exceptions may appear to be independent, but they are not
– If confirm voter has not voted wins, that creates problems
• Forcing sequential execution can correct this situation
• After correcting the process definition, the FLAVERS
verifier can verify that the new process definition
satisfies the “voter must be authenticated before
entering voting booth” property, as well as the other
properties
Is this a “real” problem?
• Humans would probably never let this happen
– They will be watching and using their judgment
• But suppose this process were automated?
– Steps executed by hardware/software wherever
possible
– This scenario could actually happen
– Would manifest itself as a “bug”
• Prior diagnostic analysis prevents this
In Medical Domain
• Have found race conditions, deadlocks
• Unsafe sequences
– Administering medication with checking, dosage,
permission, etc.
– Not being sure to weight patients upon arrival
– Letting patients into emergency department
without wristbands
Other kinds of problems
• Finite state verification/model checking looks
for event sequence defects
• But assumes that all steps are performed
correctly
• Humans may make errors
– Software too
• Looking for consequences of incorrect
performance done using Fault Tree Analysis
Fault Tree Analysis (FTA)
• A well accepted and widely practiced safety
analysis technique that identifies all possible
combinations of events that could lead to a
given hazard
– Hazard: A condition in which loss of life or
serious loss of property becomes possible
• Approach
– Specify a hazard that is of concern
– Create a fault tree for that hazard
– Derive Minimal Cut Sets (MCSs)--minimal event
combinations that can cause the hazard
Process Improvement Environment
Device model
Requirements
Derivation
Derived
Requirements
Property elicitor
(PROPEL)
Properties
Process editor
(Little-JIL editor)
Process
definition
Little-JIL
narrator
Textual
representation of
process definition
Hazards
Fault tree
generator
Fault trees, minimal
cut sets
Failure
modes
Failure mode
and effects
analyzer
Effects of failure
modes
Scenario
specifications
Discrete event
simulator
Discrete event
simulation runs
Process definition +
requirements
Model Checker
(FLAVERS)
Analysis
Improvements, new family members
Satisfied properties,
violated properties +
counterexamples
Analysis Feedback
BACKGROUND
Fault Tree Analysis (FTA)
• FTA is a deductive, top-down analysis to find out which
events in a system could lead to a given hazard
• A fault tree is a graphical model of various combinations
of events that could produce the hazard
hazard
gate
primary event
35
BACKGROUND
Minimal Cut Set (MCS)
• A minimal cut set (MCS) is a minimal set of
primary events all of whose occurrence
ensures that the hazard event occurs
• MCS can be computed automatically from a
Fault Tree using Boolean Algebra
• A MCS indicates a system vulnerability that
an adversary may be able to exploit to create
the hazard
– E.g. A singleton MCS, called a single point of
failure (SPF) is a particularly worrisome
vulnerability
36
Our Approach: Generate the Fault Tree
from the Process Definition
• Specify a hazard
– Consider hazards created by the delivery of an
incorrect artifact to a process step
– Generation based on templates for the semantics of
the language
• Use Fault Tree Analysis to develop all
Minimal Cut Sets
– Automatically calculated from the fault tree using
Boolean algebra
Small example part of a real generated fault tree
Details of our Approach
• Use our rigorously defined model of the process
– Derived from and validated by domain experts
• Obtain election hazards from domain experts
• Apply fault tree analysis
– To detect vulnerabilities
• Using hazard analysis
– To define attacks that can exploit the vulnerabilities
• In ongoing work we are also
– Composing attacking and defending processes
– Evaluating the defender’s resistance to such attacks
• Using model checking
39
FTA for Medical Processes
• Use to identify critical steps that should be
double-checked
Finding Vulnerabilities in
The Simple Blood Transfusion Process
Artifact Flow
t ID
Pa ti en
Bl ood T ype
D
tI
d
lo o
B
pe
Ty
e
Typ
od
B lo
ID
nt
t ie
Pa
Pa
n
tie
Handle Exception :
Patient’s Blood Type Unavailable
Blood Unit
A Derived Fault Tree
Blood Unit to “Perform Transfusion” is wrong
E1
1
E2
Blood Unit from “Pick up Blood from Blood Bank” is wrong
2
E3
Blood Type to “Pick up Blood from Blood Bank” is wrong
E4
3
E5
Blood Type from “Contact Lab for Patient 's Blood Type” is wrong
E6
Blood Type from “Test Patient 's Blood Type ” is wrong
Blood Unit
4
E7
“Contact Lab for Patient 's Blood Type”
produces wrong Blood Type
6
5
E9
E8
Exception is
not thrown by “Contact
Lab for Patient 's Blood
“Test Patient 's Blood Type ”
produces wrong Blood Type
E13
Exception is
thrown by “Contact
Lab for Patient 's
7
Blood Type”
Type”
E11
Patient
ID to “ Blood
Transfusion Process”
Is wrong
Input Blood
Type is correct , but
“Pick up Blood from Blood
Bank” produces wrong
E12
E11
E10
Input patient
ID is correct, but “Contact
Lab for Patient 's Blood
Type” produces wrong
Patient
ID to “ Blood
Transfusion Process”
Blood Type
Input patient
ID is correct , but “Test
Patient 's Blood Type”
produces wrong
is wrong
Blood Type
Calculating Minimal Cut Sets
Blood Unit to “Perform Transfusion” is wrong
E1
1
E2
Blood Unit from “Pick up Blood from Blood Bank” is wrong
2
E3
Blood Type to “Pick up Blood from Blood Bank” is wrong
E4
3
E5
Blood Type from “Contact Lab for Patient 's Blood Type” is wrong
E6
Blood Type from “Test Patient 's Blood Type ” is wrong
Blood Unit
4
E7
“Contact Lab for Patient 's Blood Type”
produces wrong Blood Type
6
5
E9
E8
Exception is
not thrown by “Contact
Lab for Patient 's Blood
“Test Patient 's Blood Type ”
produces wrong Blood Type
E13
Exception is
thrown by “Contact
Lab for Patient 's
7
Blood Type”
Type”
E11
E12
Patient
ID to “ Blood
Transfusion Process”
Is wrong
Input Blood
Type is correct , but
“Pick up Blood from Blood
Bank” produces wrong
E10
E11
Input patient
ID is correct, but “Contact
Lab for Patient 's Blood
Type” produces wrong
Patient
ID to “ Blood
Transfusion Process”
Blood Type
Input patient
ID is correct , but “Test
Patient 's Blood Type”
produces wrong
is wrong
Blood Type
Each gate corresponds to an equation
1: E1 = E2
5: E6 = E9
2: E2 = E3 + E4 3: E3 = E5 + E6 4: E5 = E7
E13 6: E7 = E11 + E12 7: E9 = E11 + E10
=> E1 = ( E4 ) + ( E11 ) + ( E12
E8 ) + ( E10
E13 )
E8
Calculating Minimal Cut Sets
Blood Unit to “Perform Transfusion” is wrong
E1
Single points of failure
1
E2
Blood Unit from “Pick up Blood from Blood Bank” is wrong
2
E3
Blood Type to “Pick up Blood from Blood Bank” is wrong
E4
3
E5
Blood Type from “Contact Lab for Patient 's Blood Type” is wrong
E6
Blood Type from “Test Patient 's Blood Type ” is wrong
Blood Unit
4
E7
“Contact Lab for Patient 's Blood Type”
produces wrong Blood Type
6
5
E9
E8
Exception is
not thrown by “Contact
Lab for Patient 's Blood
“Test Patient 's Blood Type ”
produces wrong Blood Type
E13
Exception is
thrown by “Contact
Lab for Patient 's
7
Blood Type”
Type”
E11
E12
Patient
ID to “ Blood
Transfusion Process”
Is wrong
Input Blood
Type is correct , but
“Pick up Blood from Blood
Bank” produces wrong
E10
E11
Input patient
ID is correct, but “Contact
Lab for Patient 's Blood
Type” produces wrong
Patient
ID to “ Blood
Transfusion Process”
Blood Type
Input patient
ID is correct , but “Test
Patient 's Blood Type”
produces wrong
is wrong
Blood Type
Each gate corresponds to an equation
1: E1 = E2
5: E6 = E9
2: E2 = E3 + E4 3: E3 = E5 + E6 4: E5 = E7
E13 6: E7 = E11 + E12 7: E9 = E11 + E10
=> E1 = ( E4 ) + ( E11 ) + ( E12
E8 ) + ( E10
E13 )
E8
An Actual Generated Fault Tree
Dynamic Analysis too by generating
discrete event simulations
Device model
Requirements
Derivation
Derived
Requirements
Property elicitor
(PROPEL)
Properties
Process editor
(Little-JIL editor)
Process
definition
Little-JIL
narrator
Textual
representation of
process definition
Hazards
Fault tree
generator
Fault trees, minimal
cut sets
Failure
modes
Failure mode
and effects
analyzer
Effects of failure
modes
Scenario
specifications
Discrete event
simulator
Discrete event
simulation runs
Process definition +
requirements
Model Checker
(FLAVERS)
Analysis
Improvements, new family members
Satisfied properties,
violated properties +
counterexamples
Analysis Feedback
Driving Simulations to Optimize
Resource Allocations
•
•
•
•
•
Define processes in Little-JIL
Hypothesize resource behaviors
Define resource allocation strategies
Run simulations
Tabulate
An Example part of an ED process
An Example Resource Type specification
<resource type="medical doctor">
<attribute name="location" value="" />
<attribute name="shift" value="" />
<capacity assignment_available="1"
reservation_available="1"/>
<capability name="MD">
<reservation
guard="location==artifact(patient.location)
&& time>=start(shift) && time<end(shift)"
contention_policy="SickestFirst : ProblemSpecific"
selection_policy="LeastUtilizedFirst :
ProblemSpecific"
effort_needed="0" />
<assignment
guard="location==artifact(patient.location)
&& time>=start(shift) && time<end(shift)"
contention_policy="SickestFirst : ProblemSpecific"
selection_policy="LeastUtilizedFirst :
ProblemSpecific"
effort_needed="1" />
Some Resource Instance Specifications
<instantiate type="medical doctor"
number="10" />
<instance type="medical doctor" id="1"
set_attribute="location" value="main􀀀track"
/>
<instance type="medical doctor" id="1"
set_attribute="shift" value="7AM􀀀􀀀3PM" />
<instance type="medical doctor" id="2"
set_attribute="location" value="main􀀀track"
/>
<instance type="medical doctor" id="2"
set_attribute="shift" value="3PM􀀀􀀀11PM" />
<instance type="medical doctor" id="3"
set_attribute="location" value="main􀀀track"
/>
<instance type="medical doctor" id="3"
set_attribute="shift" value="11PM􀀀􀀀7AM" />
Priority-based scheduling policy greatly reduces Length
of Stay for patients across all acuity levels.
Waiting times by acuity level using:
Sickest-first scheduling policy
Priority-based scheduling policy greatly reduces Length
of Stay for patients across all acuity levels.
Waiting times by acuity level using:
Priority-Based scheduling policy
The number of handoffs decreases when doctors
and nurses stop accepting new patients 1 hour
before their shifts end.
Triage Nurse can/cannot place patient in bed
Elapsed time (in simulation time units)
Summary of Results
• Found some defects in some healthcare processes
• Effected a 70% reduction in the number of “errors
reaching the patient” at Baystate Oncology Division
• Identified defects and vulnerabilities in election
processes
• Automating some code refactoring processes
• While also—
– Improving our process language
– Creating automated Fault Tree generation/analysis toolset
Another Example Domain
• Elections
• Medical Procedures
– Blood transfusion
– Chemotherapy administration
•
•
•
•
Software Development
Management processes
Manufacturing Processes
Emergency planning and support
Software Engineering
• Analysis of Scrum processes
– Precise definition(s)
– Simulations of task assignment strategies
• Understanding Rework in software development
– What is rework?
– Application to refactoring
Scrum:
Activity Skeleton
Development Iteration
X
Sprint Planning Meeting
Sprint
Sprint Review
Sprint Retrospective
Scrum
product: Product
sprint backlog channel: Backlog Channel
Development Iteration
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
agent: team
agent: ScrumMaster
product
product
product
owner: ProductOwner
product
deadline: Hours = 4
product: Product
Sprint Planning Meeting
Sprint
Sprint Review
Sprint Retrospective
Now Elaborate on the Sprint Step
product: Product
sprint backlog channel: Backlog Channel
Development Iteration
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
agent: team
agent: ScrumMaster
product
product
product
owner: ProductOwner
product
deadline: Hours = 4
product: Product
Sprint Planning Meeting
Sprint
Sprint Review
Sprint Retrospective
Sprint:
Sprint
Activity Skeleton
X
30
Daily Sprint
=
X
+
*
Checked Work
Daily Scrum
Revise Sprint Backlog
Sprint Step Details
product: Product
Sprint
X
product: Product
deadline: Days = 1
30
product
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
product
Daily Sprint
=
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
agent: Team
agent: ScrumMaster
editor: BacklogTool
team: Team
sprint backlog: Backlog
sprint burndown: BurndownTool
editor: BacklogTool
deadline: Minutes = 15
+
sprint backlog: Backlog
product
product
*
Checked Work
agent: Team
Daily Scrum
product: Product
Revise Sprint Backlog
Now elaborate on
“Checked Work”
Checked Work
Elaboration
product: Product
Sprint
X
product: Product
deadline: Days = 1
30
product
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
product
Daily Sprint
=
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
agent: Team
agent: ScrumMaster
editor: BacklogTool
team: Team
sprint backlog: Backlog
sprint burndown: BurndownTool
editor: BacklogTool
deadline: Minutes = 15
+
sprint backlog: Backlog
product
product
*
Checked Work
agent: Team
Daily Scrum
product: Product
Revise Sprint Backlog
Now elaborate on
“Checked Work”
Checked Work Subprocess
Checked Work
X
Rework
Work
Integrate
Checked Work Subprocess
Report: Build Failed
product: Product
Checked Work

X
product
report
Build Fail Report
product
product
product
Report: Build Failed
product: Product
agent: Team
product
agent: Builder
product
Check Build
product: Product
Work
X Build Failed
Checked Work
Integrate
agent: Team
product: Product
report: Build Failed
:= report U Build Fail Report
Development Iteration
product: Product
sprint backlog channel: Backlog Channel
Development Iteration
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
agent: team
agent: ScrumMaster
product
product
product
owner: ProductOwner
product
deadline: Hours = 4
Product: Product
Sprint Planning Meeting
1
Sprint
Sprint Review
Sprint Retrospective
2
“Begin Sprint” event
“End Sprint” event
Sprint
product: Product
Sprint
X
product: Product
deadline: Days = 1
30
product
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
product
Daily Sprint
=
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
3
agent: Team
agent: ScrumMaster
editor: BacklogTool
team: Team
sprint backlog: Backlog
sprint burndown: BurndownTool
editor: BacklogTool
deadline: Minutes = 15
+
product
sprint backlog: Backlog
product
*
Work
agent: Team
Daily Scrum
product: Product
Revise Sprint Backlog
4
Sprint
product: Product
Sprint
X
product: Product
deadline: Days = 1
30
product
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
product
Daily Sprint
=
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
3
agent: Team
agent: ScrumMaster
editor: BacklogTool
team: Team
sprint backlog: Backlog
sprint burndown: BurndownTool
editor: BacklogTool
deadline: Minutes = 15
+
product
sprint backlog: Backlog
product
*
Work
agent: Team
Daily Scrum
product: Product
Revise Sprint Backlog
sprint
backlog
change
4
Sprint
product: Product
Sprint
X
product: Product
deadline: Days = 1
30
product
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
product
Daily Sprint
=
X
sprint backlog
sprint backlog channel
sprint backlog
sprint backlog channel
3
agent: Team
agent: ScrumMaster
editor: BacklogTool
team: Team
sprint backlog: Backlog
sprint burndown: BurndownTool
editor: BacklogTool
deadline: Minutes = 15
+
product
sprint backlog: Backlog
product
*
Work
agent: Team
Daily Scrum
product: Product
Revise Sprint Backlog
sprint
backlog
change
4
This is benign because the step is performed by Team
Simulation of Different Task
Assignment Strategies
• Hypothesized
– Distribution of task sizes and difficulties
– Distribution of worker coding and testing skill levels
– Different team makeups
– Different strategies for task assignment
• Fault injection to simulate coding bugs and
inadequate testing
• Iterate until no more bugs found
Different strategies for task assignment
• Strategies
– Random assignment of tasks to workers
– Greedy: Hardest tasks to strongest workers
– Prev: Tasks not completed reassigned to previously
assigned workers
– Greedy Prev: Combination of Greedy and Prev
• Different task assignment strategies produced
sharp differences in
– Lines of code produced
– Number of residual bugs
What is “rework”?
in software development?
In other intellectual work?
Traditional Software
Development Process
Traditional Software
Development Process
Rework in a
Requirements
Requirements =
Specification
+
Sub-Process
Inter-requirement
Consistency Check
Develop Rqmt Element
X
~ Rqmt OK
Declare and Define Rqmt
Rqmt OK
Declare Rqmt Element
Develop Rqmt Element
Define Rqmt Element
Rework in a Design Sub-Process
Copyright L.J.Osterweil All Rights reserved
Requirements Rework May Be Triggered
During Design
Copyright L.J.Osterweil All Rights reserved
Requirements Rework Process
Copyright L.J.Osterweil All Rights reserved
Contains a Previously Executed Step
Copyright L.J.Osterweil All Rights reserved
That We Saw Previously Here
Copyright L.J.Osterweil All Rights reserved
Requirements Rework
Invocation of step originally defined
as substep of Requirements
Copyright L.J.Osterweil All Rights reserved
Requirements Rework
Same exception
thrown
Invocation of step originally defined
as substep of Requirements
Copyright L.J.Osterweil All Rights reserved
Requirements Rework
Invocation of step originally defined
as substep of Requirements
Same exception
thrown
Different invocation
context -> different
response
Copyright L.J.Osterweil All Rights reserved
Another 10 High-Level Design
Rework-centered
X
Design Process
9
~ Rqmts OK
8
6 Declare and Define HLDesign Elements
Requirements
~ A Rqmt OK
HLDesign
OK
Develop Rqmt Element
4
7
~ HLD OK
Declare HLDesign Elements
High-Level Design
2
+
1
Declare HLDesign Element
5
3 Define HLDesign Elements
Copyright L.J.Osterweil All Rights reserved
Coding
Coding
Develop Code Modules
X
~Rqmts OK
~HLD OK
Requirements
~LLD OK
High-Level Design
Define Module Interfaces
=
+
Low-Level
Design
~Code
OK
Interface
OK
Coding
…
~ A Rqmt OK
Define A Module Interface
Develop Rqmt
Element
Code All ModulesCode
OK
…
Copyright L.J.Osterweil All Rights reserved
Final Observations
• Many kinds of analysis applicable to processes
– FSV/Model Checking
– Fault Tree Analysis
– Reachability Analysis
– Discrete Event Simulation
• Requires rigorous definitions of processes and
properties/hazards
• Broadly applicable to many diverse domains
What we have learned about system and
process software could show us how to
do better application software
• Resource management
– Which supports integration of humans “inside the
box”
• Rework
– Which entails effective use of retrospection,
inspection
Resource Management
• A resource is an entity that is characterized by
– Ability to provide one or more “capabilities”
• Capability: The ability to support doing some task/activity/work
– A set of descriptive attributes
• Attribute: a (name, value) pair
• Capability set changes with context, circumstances
– Attribute values do too
• A resource is a set of
– Guarded capabilities
– Guarded attributes
Resource Management
• Seems overlooked in application software
– Old view: Software = algorithms + data ???
– New view ?: Software = activities +artifacts+resources
• Resources rediscovered in Service-orientated
software development?
• A big issue, with lots of hard questions
Rework
• Pervasive in virtually all creative activities
• The essence is in the data (and resources),
rather than the activities
• Rework is a kind of recursion
• State reification and inspection helps
• So does historical retrospection
We should focus more on similarities
than differences
• Strong Temptations to do the opposite
– And good rewards too
• Everything is different from everything else
• But there are often important similarities too
– And we should try to learn from similarities
– And we should find strong rewards in doing so
What we do is more fundamental than
we may think
• Can we carry to other domains our clear insights
into:
–
–
–
–
Abstraction
Concurrency
Analysis/Reasoning
Phased development and evolution
• And learn from related disciplines about
– Rework
– “humans in the box”
– Agents/resources
• And fashion an understanding of something still
far deeper and more fundamental
Thank you
and
Questions?
Recall the previous process
pass authentication and vote
Missing ID Exception
Inadmissible ID Exception
ID Mismatch Exception
present ID
Voter Already Checked Off
Exception
Perform pre-vote
authentication
=
Check off
voter as voted
Issue ballot
Record voter preference
Let voter voter with
provisional ballot
Fill out provisional
ballot
Confirm voter ID
matches voter
Confirm voter ID
exceptions: matches voting roll
ID Mismatch
Confirm voter
has not voted
exceptions:
ID Mismatch
exceptions:
Voter Already
Checked Off
Submit
provisional
ballot
Now elaborate the issue ballot step
Issue regular
ballot
Issue provisional
ballot
Now elaborate the issue ballot step
pass authentication and vote
Missing ID Exception
Inadmissible ID Exception
ID Mismatch Exception
present ID
Voter Already Checked Off
Exception
Perform pre-vote
authentication
=
Check off
voter as voted
Issue regular
ballot
Confirm voter ID
matches voter
Confirm voter ID
exceptions: matches voting roll
ID Mismatch
Confirm voter
has not voted
exceptions:
ID Mismatch
exceptions:
Voter Already
Checked Off
Issue ballot
X
Record voter preference
Issue provisional
ballot
Let voter voter with
provisional ballot
Fill out provisional
ballot
Submit
provisional
ballot
Detecting Vulnerabilities in This Process
• Process has numerous checks and doublechecks, but are they enough?
• What combinations of incorrect performances
could cause a hazard?
• Can the wrong artifact reach
– The wrong step
– The wrong agent
• How to find these situations?
98
An Example Election Process Hazard:
An unqualified voter gets to vote with
a regular ballot
Is modeled, based upon our Little-JIL
process definition, as:
The “record voter preference” step
receives an incorrect “ballot” artifact.
99
Artifact flow
• Primarily along parent-child edges
– As procedure invocation parameters
– Passed to exception handlers too
– Often omitted from coordination diagrams to reduce
visual clutter
• Parent-child data flow is inadequate
– Artifacts also need to flow laterally
– And subtasks need to communicate with each other
• Little-JIL also incorporates channels
– For concurrency synchronization, preemption
– And for passing data laterally
Add artifact flow (and adjust exception management)
Missing ID Exception
pass authentication and vote
Inadmissible ID Exception
ID Mismatch Exception
present ID
voterQualified >>
Perform pre-vote
authentication
>> voterQualified
Check off
voter as voted
=
Issue ballot
X
voterQualified==true
ballot >>
>> voterQualified
Issue regular
ballot
voterName >>
>> voterName
voterRegistered >>
Confirm voter ID
matches voter
Confirm voter ID
matches voting roll
voterQualified==true
Voter Already Checked Off
Exception
ballot >>
>> voterQualified
>> ballot
Record voter preference
ballot >>
>> voterQualified
Issue provisional
ballot
voterQualified==false
voterQualified >>
Confirm voter
has not voted
voterRegistered==true
Let voter voter with
provisional ballot
Fill out provisional
ballot
Submit
provisional
ballot
PRELIMINEARY RESULTS
The Fault Tree automatically derived from the Little-JIL
this process definition
Hazard: an unqualified voter gets to vote with a
regular ballot
Hazard specification using the FTA tool
artifact “ballot” input into the step “record
voter preference” is wrong
102
PRELIMINEARY RESULTS
The Resulting MCSs
• There are 11 MCSs in the fault tree
• Example:
1. Step get voter name produces wrong voterName
2. Step verify voter has not voted does not throw VoterUnregistered
exception (while checking prerequisite)
3. Step check off voter as voted does not throw VoterUnqualified
exception (while checking prerequisite)
4. Step issue regular ballot does not throw VoterUnqualified
exception (while checking prerequisite)
One informal interpretation: An imposter provides an incorrect
name, but three different checks fail to pick this up.
There are other interpretations, too.
103
One Interpretation: Imposter provides
name of qualified voter who has not yet
voted
1. Step get voter name produces wrong voterName
2. Step verify voter has not voted does not throw
VoterUnregistered exception (while checking prerequisite)
3. Step check off voter as voted does not throw
VoterUnqualified exception (while checking prerequisite)
4. Step issue regular ballot does not throw VoterUnqualified
exception (while checking prerequisite)
There is really only one incorrectly performed step, namely the first one.
The others are “incorrect”, only because they get incorrect input—but they
104
are correct given their inputs
An impostor has the name of a registered voter who
Missing ID Exception
has not voted
pass authentication and vote
Inadmissible ID Exception
ID Mismatch Exception
present ID
voterQualified >>
Perform pre-vote
authentication
>> voterQualified
Check off
voter as voted
3
=
Issue ballot
X
voterQualified==true
ballot >>
>> voterQualified
>> voterName
voterRegistered >>
Confirm voter ID
matches voter
1
Issue regular
ballot
4
voterName >>
Confirm voter ID
matches voting roll
voterQualified==true
>> ballot
Record voter preference
voterQualified==false
Confirm voter
has not voted
voterRegistered==true
Let voter voter with
provisional ballot
ballot >>
>> voterQualified
Issue provisional
ballot
voterQualified >>
2
Voter Already Checked Off
Exception
ballot >>
>> voterQualified
Fill out provisional
ballot
Submit
provisional
ballot
Alternative Interpretation: Imposter
provides name of qualified voter who
has voted, but official does not notice
1. Step get voter name produces wrong voterName
2. Step verify voter has not voted does not throw
VoterUnregistered exception (while checking prerequisite)
3. Step check off voter as voted does not throw
VoterUnqualified exception (while checking prerequisite)
4. Step issue regular ballot does not throw VoterUnqualified
exception (while checking prerequisite)
106
Alternative interpretation: An impostor has the name of a
registered voter who has
voted, but the election official
does
Missing ID Exception
pass authentication and vote
Inadmissible ID Exception
not notice
ID Mismatch Exception
present ID
voterQualified >>
Perform pre-vote
authentication
>> voterQualified
Check off
voter as voted
3
=
Issue ballot
X
voterQualified==true
ballot >>
>> voterQualified
>> voterName
voterRegistered >>
Confirm voter ID
matches voter
1
Issue regular
ballot
4
voterName >>
Confirm voter ID
matches voting roll
voterQualified==true
>> ballot
Record voter preference
voterQualified==false
Confirm voter
has not voted
voterRegistered==true
Let voter voter with
provisional ballot
ballot >>
>> voterQualified
Issue provisional
ballot
voterQualified >>
2
Voter Already Checked Off
Exception
ballot >>
>> voterQualified
Fill out provisional
ballot
Submit
provisional
ballot