Presentation
Download
Report
Transcript Presentation
PhD Seminar 23 November
2004
Per Trygve Myhrer
Overview
Methods that can be used to
identify hazards early in the
development process
Methods to achieve traceability and
Intent Specification
2
Finding hazards early
It is important to:
Identify hazards
Be able to insert barriers or
preventive action early
We do not want a lot of analysis that
are useless after changes and gives
a false sense of security
3
Finding hazards early II
In the BUCS project we have tried out
several methods for identifying
hazards
PHA on System concept
PHA on High level requirements
PHA to find deviations from the
happy scenarios
Use of the KJ process with focus on
hazards
4
Preliminary Hazard Analysis
Brainstorming, structured by PHA
table and system concept
What can go wrong
The results depend on the
participants’ experience and
knowledge
PHA will work best if the members of
the analysis have experience with
the system that is going to be made
5
PHA on system concept
Subject: Connection to the central database
Dangers
Causes
Effects
Barriers / actions
No connection / No data
received
The central database is
down
Then we will have trouble
with:
-No registered users
-No user updates
-The users cannot log in
We shall regularly /
continuous poll the central
database. If fail, one of our
alarms shall be activated,
and the administrators will
get an SMS or an e-mail.
Wrong data received
- Our SQL query is wrong
- Database central error
- The central database
interface have changed,
and we have not updated
our query
- Wrong user updates
- Wrong registered users
- We have to notify the
central database
administrators that we are
depending on their
database.
- We have to change our
query
It is hard to define a
barrier here, we have to
depend on feedback from
our users
6
PHA on High level requirements
Requirements
Incident
Consequence
User registration
Not registered
Can not use the system
Registered multiple
times
Several Ids can result in
missing exercise
deliveries
Forget
password
user ID
Can not access the
system
User disappears in the
system
Can not use the system
Information get lost
Wrong info
Can not access the
system Wrong
information
Missing feedback
Registered multiple
times
7
Happy Scenarios
Scenario ID: “User logon”
Scenario pre condition:
The student chooses the course he or she wants to take from a list at the universities web pages. The student will log in as
a student, and writes in (when prompted) username and password.
Function
Incident
Consequence
Severity
Wrong UID / password
No access
L
UID/password not recognised
No access
Annoyance
Re-registration of user
M
Inconsistency between web and
“student system”
Rejected
M
Course full
Rejected
L
Login as wrong person
Destroy information
Security problem
H
Not yet opened course (no
available information)
Can miss out on taking course if user waits too long to
register (this may be an organisational issue)
L
Scenario post condition:
When the student successfully has logged in, he or she can read the latest news, will be able to download the files that
have been published by the teacher, and can join and participate in the discussion group at the course news group.
8
Notis board innhold
The KJ process
Vedlegg
The new item is
not in the notice board
Info kommer ikke
på websiden
Får ikke lest vedlegg
Info er feil eller uleselig
Får ikke lagt ved vedlegg
Element is not added
to the notice board
News item attachemnts
are missing (links missing
or dead links)
Vedlegg med virus
News item is dated
incorrectly (not part
of scenario)
Teacher is not able to
select ”add element to
notice board” from the menue
Students are able to add
items to the notice board
without having the proper
access privilegies
Ytelse
Systemet henger
Siden blir forsinket oppdatert
og studenten sender samme
info en gang til => dobbeltpost
Menyvalg
The text is not the same
as the teracher wrote in
Students can not see
the new news item on
the notice board
Får ikke oppdatert
notice board
Får ikke endra / fjerna
notis
The menue choice leads
to wrong address
Kommer ikke tilbake
til start etterpå
Noting happens when
the menue item is chosen
9
Safety when using Agile methods
Agile methods uses
stories for
requirements
We add the hazard
stories
Hazard
Story
Stories
Development
Refractoring
10
The methods
None of the methods will find hazards
that none of the members have
experienced or thought might
happen
We need more experiences and this
can be done by building and using a
experience database
11
Traceability
Traceability is important because it:
Makes it possible to get an overview of
the system and help people easy find
reasons for decisions when developing
software
Link hazards to proposed barriers and
actions identified
Will help us to document our decisions
12
Why Intent Specification ?
Intent Specification will allow us to:
Explain reason for decisions
Show consequences of decisions
In order to justify our decisions we can use
Expert judgment
Experiences
”What if?” – analysis
13
Intent Specification
Intent Specification has hyperlinks that
links parts of documentation and code
that influence each other
Links from requirements through the
documentation and down to the code
Decisions on how to comply with a safety
requirements and links to the code where
it’s done
14
Example of Intent Specification
Before start of
development
History of
previous systems
High level
requirements
PHA
Requirements
Architectur
e
Hazop
CCA
Requirements
for components
Code
System is finished
User guides
15
SpecTRM
SpecTRM is a tool that can be used to
realize Intent Specification. The tool
is:
Made to be used to develop safety
critical software systems and
supports the use of Intent
Specification
Adaptable and can also be used for
a system that is not safety critical
16
Discussion
Challenges with traceability
Traceability both ways will add more work to
maintain
Is it enough to have traceability only bottom –
up?
PHA – Happy scenarios is probably the
best method
Are Agile Methods are useful for business
critical systems?
17