Hints for achieving parsimony of analysis:
My safety podcast: disastercast.co.uk
My mobile (from October 6th): 0450 161 361
On 20 January 2016 at 22:41, Matthew Squair <mattsquair_at_xxxxxx
> Hi Drew I'm not sure I get why more effort in modeling would cause the
> model to drift away from the real world? Do you mean that there's a focus
> on 'truth in the model' vs a description of the real world?
>
> As a side note, one of the things I am not looking forward to is the death
> of a thousand FHA tables. Does anyone have any thoughts on how to achieve
> parsimony of analysis?
>
> Matthew Squair
>
> MIEAust, CPEng
> Mob: +61 488770655
> Email; Mattsquair_at_xxxxxx
> Web: http://criticaluncertainties.com
>
> On 20 Jan 2016, at 9:28 PM, Martyn Thomas <martyn_at_xxxxxx
> wrote:
>
> On 20/01/2016 07:06, DREW Rae wrote:
>
> The more effort you put into creating an analysable model of the real
> world, the less that model looks like the real world and the greater the
> chance that the safety problems will exist outside the analysis altogether.
>
> Drew
>
> Somehow, you have to be satisfied that you understand well enough what you
> are trying to do. When you believe you have achieved this, wouldn't you
> agree that expressing your results formally can only be beneficial? Why
> would you choose to write things down informally if you had a way to do so
> formally and there were tools that would then tell you about errors and
> inconsistencies?
>
> Trivially, we can partition our task into two objectives.
>
> The first is to establish the functionality, interfaces to other systems
> and the safety and security properties that we need. The second is to
> implement these in a system and generate adequate evidence that we have
> done so successfully.
>
> The first is hard and inherently contains some steps that cannot be fully
> formalised. (I'll assume we agree about that and leave any discussion
> about it to a separate thread). But once we have completed this objective
> to the extent that we consider to be sufficient to enable the second
> objective to proceed to a successful conclusion, it is possible to attempt
> a formal model of the functionality and properties that we have
> established.
>
> I don't see how doing so could possibly weaken the work we have already
> completed - indeed, it will probably reveal some oversights and
> contradictions that will help us to improve it.
>
> It is likely also to reveal some functionality or properties or interfaces
> that we cannot formalise. That's a useful warning sign, because it
> indicates areas where our knowledge is incomplete (perhaps inevitably so)
> and where we shall need to direct our best efforts to mitigate the risks
> that result from this incomplete knowledge.
>
> It will also give you a firm starting point for the second objective and,
> in my experience, reduce the cost of this second stage whilst improving the
> quality ( assessed on whatever measures you would like to choose).
>
> Martyn
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx
> <systemsafety_at_xxxxxx
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx
>
>
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Wed Jan 20 2016 - 14:07:25 CET
This archive was generated by hypermail 2.3.0 : Sat Feb 16 2019 - 09:17:07 CET