In the case of aviation or the surgical checklists these do not signify whether it is "safe" to take-off or start whatever procedure but as a reminder to the practitioner and supporting team that they have reached a place where they need to check on their status and progress. The decision to go or no-go is not the remit of the checklist. For example, once a checklist is complete a pilot is free to choose whether to take-off or not irrespective of the answers given to the items on the checklist (cf: [2]).
This got me thinking in that there are some similarities to design-by-contract and this could be used to explain checklists better possibly. For example consider the function to take-off (written in pseudo Eiffel fragments [3]):
take-off
-- get the throttle position, brake status etc and spool-up engines
do
....
end
...
can be called whenever, there is no restriction and this is how it was, until an aircraft crash in the 1930's triggered the development of checklists in aviation. So now we have:
take-off
-- get the throttle position, brake status etc and spool-up engines
require
checklist_complete = True
do
....
end
...
and in more modern aircraft this is supplemented by features to specifically check on the aircraft status
take-off
-- get the throttle position, brake status etc and spool-up engines
require
checklist_complete = True
do
if flaps < 10 then
soundAlarm
end
....
end
...
or even:
take-off
-- get the throttle position, brake status etc and spool-up engines
require
checklist_complete = True
flaps > 10
mode = GroundMode
do
....
ensure
mode = FlightMode
end
...
What you actually see are specific checks from the checklists being incorporated into the basic protection mechanisms of the aircraft functionality. This is analogous to what we might see in a process, for example below we can see the implementation of functionality to encode a project approval checklist into some approval function:
approveProject
require
securityReview.status = Completed
privacyReview.statuse= Completed
continuityReview.status = Completed
performanceReview.status = Completed
architecturalReview.status = Completed
do
...
Now we have said nothing about how the particular reviews were actually made or whether the quality of their results were sufficient. This brings us to the next question of the qualitative part of a checklist and deciding what to expose. Here we have three options:
- completion
- warnings
- show stopping preconditions
The first is as explained above, the second and third offer us a choice about how we expose and act upon the information gained through the checklist. Consider a privacy or information content review of system, we would hope that specific aspects are specifically required, while others are just warnings:
approveProject
require
...
privacyReviewStatus = Completed
privacyReview.pciData = False
privacyReview.healthData = False
...
do
if privacyReview.dataFlowModelComplete = False then warn("Incomplete DFDs!") end
...
And we can get even more complex and expose more of the checklist contents as necessary.
The main point here is that if we draw an analogy with programming, some aspects of checklists can be more easily explained. Firstly the basic checklist maxim is:
All the items on a checklist MUST be checked.
then we should be in a place to make a decision based on the following "procedure"
- Are all individual items in their respective parameter boundaries?
- Are all the parameters taken as a whole indicating that we are in a state that is considered to be within our definition of "safe" to proceed to the next state?
- Final question: Go or No-Go based on what we know from the two questions above?
Of course, we have glossed over some of the practical implementations and cultural aspects such as team work, decision making and cross-referencing, but what we have described is some of the philosophy and implementation of checklists in a more familiar to some programming context.
References
[1] Great Ormond Street Hospital did this according to one BBC (I think) documentary.
[2] Spanair Flight 5022
No comments:
Post a Comment