Safety Analysis as a Software Tool by qjk18715

VIEWS: 24 PAGES: 5

									                                             Safety Analysis as a Software Tool
                                                                                                                                                                      Blair T. Whatcott
                                                                                                                                                  Northrop Grumman Information Technology
                    As a software development tool, an independent software safety analysis by trained analysts reduces losses of develop-
                    ment resources and schedule, improves product quality, and prevents costly mishaps that occur during the operational
                    phase of the system life cycle. The key issues of an effective and efficient software safety analysis include (1) financial
                    and managerial independence from the software development activity, (2) trained and qualified personnel to perform
                    the analysis, and (3) a disciplined process that focuses the analysis effort, by priority, on the more safety critical areas.


P    erforming an independent system and mary steps (see Figure 2):                                               implementation. The code is verified for
     software safety analysis on embedded • Step 1. Identify safety-critical areas correct implementation of the require-
software saves overall life-cycle cost and                   and system safety hazards.                           ments as well as for correct syntax and
schedule resources, and provides a better • Step 2. Trace implementation of safe- safe coding practices. This analysis also
overall product. The primary objective of                    ty-critical requirements to the design includes identifying specific safety-critical
safety analysis is to find and remove                        and its corresponding code.                          data items and processing within the
embedded safety related hazards in the • Step 3. Verify correct system use and reviewed code module for use in the next
hardware and software systems before a                       implementation of safety-critical data step. An example of a safety-critical data
mishap occurs.                                               and processing.                                      item could be a weapon release variable.
    Finding these embedded hazards early • Step 4. Track identified hazards An example of safety-critical processing
in the development cycle reduces cost,                       throughout the system life cycle .                   could be the processing required to set or
safeguards schedules, and improves prod- Each step is discussed in the following reset the release signal.
uct quality [see Figure 1]. The reduction in paragraphs.                                                                  Requirements of higher safety criti-
added costs and schedule slips due to                                                                             cality are evaluated before those of lesser
problems found late in the development Step 1                                                                     criticality. The intent of safety analysis is
cycle and the improvement in product The first step is to list all system require- to find the more critical hazards that
quality justify the cost of performing an ments, the relative level of safety criticali- would cause mishaps of higher severity.
independent software safety analysis. ty for each system requirement with As there will always be some residual
Additionally, preventing a single cata- respect to the other requirements, and the mishap risk, particularly when software is
strophic mishap by removing an embed- applicable documented hazards for safety- involved, the task of performing a com-
ded hazard could more than pay for the critical requirements. Each system/sub- plete and thorough software safety analy-
independent safety analysis effort many system requirement must be evaluated for sis would be both cost prohibitive as well
times over, depending upon the system.                  criticality with respect to potential haz- as impossible. Consequently, items of
    This article identifies key terms associ- ards. The safety criticality of a require- lesser safety criticality may not be
ated with system and software safety, pro- ment depends upon the identified hazards Figure 1: Software Safety Analysis Benefits
vides a process for performing software and other items such as remoteness, con-
safety analysis, specifies the required envi- tributory impact, redundancies, and
ronment for efficiently and effectively per-Safety Analysis Process
                                                        human intervention.
forming safety analysis, provides cost and safety hazards andhazards vary depending upon
                                                                                                                                                Software Safety
                                                             System
schedule savings rationale, and identifies the function and use of the system. These
                                            Identify                         safety-critical requirements.                                     Analysis Benefits

issues that delay or prevent effective safe- hazards must be identified and document-
ty analyses. Although this article empha- Tracethrough designimplementations
                                                        ed. Sub-hazardscode. contribute to higher-
                                                                              and that
sizes performing safety analysis on soft- level hazards need to be specified to a suf-
                                                            requirements



ware, a thorough software safety analysis ficient detail. An example of a hazard
                                                                                                                           Primary Objective                                Added Value
                                                                                                                           Prevention of Mishaps

includes a system safety analysis as many mightsystem use and implementation of of release.
                                                                                                                                                                             Cost Savings


                                                                     be erroneous activation
                                                                                                                              Injury/Loss of Life                     Schedule Safeguarding


of the embedded hazards occur at inter- Examples data and processing.
                                                                                                                             Loss of Equipment


                                                                          of corresponding contributing
                                              Verifying correct                                                                                                     Improved Product Quality
                                                                                                                           Environment Damage


faces between system components.
                                                         safety-critical


                                                        sub-hazards could be (1) erroneous release Figure 2: Software Safety Analysis Process
    When developing software systems, a identified hazards throughout the system life cycle.
                                                        signal, (2) erroneous status display, and (3)
tool enables a developer to build better sys- malfunctioning safety lock. This list of
                                           Track


tems quicker. The systems are more effec- system requirements becomes the plan Early Phases of System Software Development Life Cycle
                                                                                                                                   Safety Analysis Is Not Included During
                                                                                                           Mistaken Reasons Why Software Safety Process


tive, more efficient, and safer. Involving an Analysisis used to perform software safety
                                                        that Environment for Success
                                                                                                                          Identify safety hazards and safety-critical requirements.


independent software safety analysis con- analysis.
                                       Safety                                                                                Reason                                        Actual Need


tributes to these attributes and becomes athat
                                                                                                             Conserve funds because there is no code           Early evaluation of requirements and design




tool that should be used in today’s complex Step 2
                                                                                                                               to review.                       precludes costly coding and testing errors.
                                         Disciplined                                         Financial and
                                        process                                                                                        Trace requirements implementations
                                                                                              managerial    Difficulty establishing a contract with an        Most major defense contractors have General



system development efforts.
                                                                                                                                               through design and code.

                                         priority on Using the safety criticality priority estab- Misconception that good coding processes
                                           focuses                                                           independent organization to do safety.         Services Administration-type contracts that could
                                                                                            independence                                                                   support safety efforts.
                                         analysis in                                        from software


                                        critical areas. lished by the list from Step 1, the second
                                                                                                                                                            Success orientation of development engineers
                                                                                             development
                                                                                                                preclude embedded safety hazards.                results in missed errors; development



                                                        step is to evaluate requirements. This step Failure to budget in software safety
                                        more safety-                                            activity.                                                      environment pressures prevent thorough
                                                                                                                            Verifying correct system use and implementation of
Software Safety Analysis                                                                                                                                             system and interface analysis.



                                                        correlates the functional requirements to
                                                                                                                                            safety-critical data and processing. to be budgeted
                                                                                                                                                             Software safety analysis needs

Process
An effective process for performing a (1) theTrained level and detailed level design
                                                                     top and
                                                                                                                          analysis activities.               independently of development activity budgets.

                                                                                                             Lack of mishap evidence if hazard found          The objective of software safety is to remove



software safety analysis includes four pri- descriptions toand (2) the source code
                                                                                                                            and removed.                        hazard before mishap; prevention of one
                                                                                                                                                            catastrophic mishap more than pays for safety
                                                                     qualified                                           Track identified hazards throughout the system life cycle.
                                                                                                                                                                              analysis effort.
                                                                  personnel
                                                                                                                                       Lack of software safety analysis expertise       Evaluate potential safety analysis
                                                                                 perform

November 2004
                                                                                                                                                    and processes.                  organizations on track record, processes,
                                                                                 analysis.                                                                                                          and staff.
                                                                                                                                                                                           www.stsc.hill.af.mil          17
                                                                                                                                                                  Early identification of safety problems saves
                                                                                                                                       Problems found in safety analysis cause
                                                                                                                                             Safety Analysis Environment for Success
                                                                                                                                              additional work impacts.
                                                                                                                                                                   resources by preventing redesign, recode,
                                                                                                                                                                                          retest, and prevents mishap.
Software Toolbox

reviewed so that items that are more safe-                   prohibitive to analyze every line of code     ponents.
ty critical can be more deeply and com-                      against every item in the hazard list. The        Financial and managerial indepen-
pletely reviewed.                                            implementation freedom that software          dence ensures that specific resources will
                                                             allows precludes an all-comprehensive         be used for performing the software
                                                             automated tool that checks every line of      safety analysis and that there is no con-
The third step is to evaluate the safety-
Step 3
                                                             code for every possible hazard. We have       flict of interest between the development
critical data and processing identified in                   found that a trained analyst who is cur-      activity and the software safety analysis
Step 2 in the context of the system.                         rent with the list of software hazards is     activity. An example of a conflict of
Particular attention is given to the inter-                  more efficient and effective in perform-      interest could be the program office or
faces between subsystems, sequencing of                      ing the safety analysis. Software utilities   development organization controlling
state changes, and timing windows of                         and tools can and are often used to help      the work of the safety analysis by direc-
vulnerability. This type of analysis is                      the analyst more quickly locate similar       tion toward or away from specific haz-
oftentimes not given sufficient attention                    patterns, occurrences, and uses.              ards or risks. The criticality list from Step
during software development and testing                                                                    1 is the road map that identifies the pri-
as well as peer reviews because of the                                                                     ority of safety-critical areas to be
added complexity and time required to be                                                                   reviewed. The resources are used in
                                                             Software Safety Analysis
thorough.                                                    Environment                                   accordance with this priority, which
                                                  To perform effective and efficient soft-
                                                                                                           means that safety-critical areas of lower
                                                  ware safety analysis, an environment of
                                                                                                           priority may not be reviewed or analyzed
In the fourth step, identified hazards are three components is required: (1) finan-
Step 4
                                                                                                           because of the need to use resources to
documented and communicated to the cial and managerial independence from
                      Safety Analysis Process                                                                                                        Softwar
                                                                                                           analyze safety-critical areas of higher pri-
development organization. hazards and the software development activity, (2)
               Identify safety The safety safety-critical requirements.                                    ority.                                   Analysis
analysis effort tracks the identified haz- trained and qualified personnel to per-                             An example of implementing an
ard until it is removed from the software. form the analysis, and (3) a disciplined                        independent safety analysis effort would
As software hazards tend to be repeated process that focuses the analysis effort,                          be for the program office to contract
in other areas and applications, the haz- by priority, on the more safety-critical                         separate activities to the development
ard is added to the lessons learned software areas [see Figure 3].                                         organization and the software safety
safety analysis database. The hazards                 Each of these components is neces-                   analysis organization. As such, reports to
                        Trace requirements implementations

from this database, as well as hazards            sary for a successful software safety                                            from the Objective
                                                                                                           the program office Primary software
                               through design and code.
identified on industry generic safety lists, analysis. The absence of any undermines                       safety analysis organization are indepen-
are used for training of safety analysis the effort and the strength of the other                          dent of the software development activi-
                                                                                                                                  Prevention of Mishaps
engineers and for performing evaluation components. For example, without the                               ty. Another example would be to have
                                                                                                                                     Injury/Loss of Life
                 Verifying correct system financial and managerial of
checklists when future modifications are use and implementation independence                               the safety office independently contract
                                                                                                                                     Loss of Equipment
                           safety-critical from the development
made to the software being analyzed ordata and processing. activity, the ana-                              to the software safety analysis organiza-
                                                                                                                                  Environment Damage
other software in other systems.                  lyst may be directed in a way that inhibits              tion for work being developed by the
    An example of a generic safety list fully performing the analysis, or the dis-                         program office that is contracted to the
can be found in Appendix E of the Joint cipline process is circumvented because                            software development organization.
Software System Safety Committee’s of management direction caused by a                                         Performing a successful software
“Software System Safety Handbook” [1]. need to use resources in areas other than                           safety analysis requires a technical staff
This combined list of software-specific safety analysis. Similar examples can be                           that is qualified to perform safety analy-
              Track identified hazards throughout the system life cycle.
hazards is very large. It would be cost drawn for the absence of the other com-                                      enjoys doing this type Why Software
                                                                                                           ses and Mistaken Reasons of work.
Figure 3: Safety Analysis Environment for Success                                                                       Early Phases of new sys-
                                                                                                           Most engineers prefer building System Softwa
                                                                                                           tems and being part of the development
                                                                                                           process of major systems. Many engi-
                                                                                                           neers find no interest in digging through
         Safety Analysis Environment for Success                                                                                       Reason
                                                                                                                         find embedded hazards no
                                                                                                           systems toConserve funds because there isthatcode
                                                                                                                                         find and
                                                                                                           are not only difficult toto review. under-
                                                                                                           stand, but also have not evidenced them-
           Disciplined                                                        Financial and
                                                                                                                                  the proverbial looking
                                                                                                           selves. It becomesestablishing a contract with an
          process that                                                         managerial                              Difficulty

                                                                                                           for a needle in the haystack, except there
             focuses                                                                                                    independent organization to do safety.  S
                                                                             independence
           analysis in                                                       from software                 is really no clue that the needle is even in
           priority on                                                                                     the haystack preclude embedded number of
                                                                                                                             or even in a safety hazards.
                                                                                                                       Misconception that good coding processes S

                                                                                                           haystacks. Finding engineers who can do
                                                                              development

                                                                                                           this type of work and want to do it for
          more safety-                                                           activity.

                                                                                                           many years is difficult. Some can do
          critical areas.

                                                                                                                                    or so; however,
                                                                                                           analysis for a year analysis activities. the
                                                                                                                          Failure to budget in software safety

                                                                                                           strength of a software safety analysis
                                                                                                           organization comes from analysts who
                                                                                                           have done analysis for many years on
                                                                                                                       Lack of mishap evidence if hazard found

                                                                                                           many systems.
                                              Trained and                                                                             and removed.

                                                                                                               Two pitfalls are seen when companies
                                                qualified

                                                                                                                       Lack of safety organizations.
                                                                                                           set up softwaresoftware safety analysis expertise
                                              personnel to
                                                perform
                                                                                                           First, individuals who are used to per-
                                                                                                           forming software safety analysis activities
                                                                                                                                     and processes.
                                                analysis.

18 CROSSTALK The Journal of   Defense Software Engineering                                                                   additional work November 2004
                                                                                                                      Problems found in safety analysis cause
                                                                                                                                             impacts.
                                                                                                              Safety Analysis as a Software Tool

are not correctly screened with respect to
ability and desire. Oftentimes, they are                                      Safety Terminology
selected from those who have not been
successful doing other code development
activities because of work habit issues or
                                                 For the purposes of this article, the following safety-related terms are provided from

lack of ability. The fallacy of doing this is
                                                 [2].

that performing successful analysis on
                                                 • A mishap is an unplanned event that results in death, injury, occupational illness,

code that is generated by the develop-
                                                      equipment or property damage or the loss of, or environmental damage.

ment activity requires individuals that are
                                                 • Hazards are conditions that cause a mishap.

better trained and more capable than
                                                 • The ultimate goal of a system safety program is to design systems that contain

those who have developed the code.
                                                      no hazards. However, since the nature of most complex systems makes it impos-

They must be able to find embedded
                                                      sible or impractical to design them completely hazard-free, a successful system

hazards missed by other development
                                                      safety program often provides a system design where there exist no hazards

reviews and testing that could result in a
                                                      resulting in an unacceptable level of mishap risk.

mishap during the operational phase of
                                                 • Mishap risk is an expression of the possibility/impact of a mishap in terms of haz-

the system life cycle.
                                                      ard severity and hazard probability.
                                                 • Residual mishap risk is the remaining mishap risk after all mitigation techniques
    The second pitfall of setting up soft-            (techniques used to remove or lessen the hazard) have been implemented or
ware safety organizations is that the                 exhausted.
development activity expects that the            • Safety is the freedom from hazards, which cause death, injury, occupational ill-
code developer should be able to gener-               ness, equipment or property damage or loss, or environmental damage.
ate good code that contains no safety            • The objective of a safety analysis is to achieve acceptable mishap risk through
hazards. Consequently, the development
                                                      a documented systematic approach to hazard analysis, risks assessment, and risk
activity either sees no value in perform-
                                                      management.
ing an independent safety analysis or lim-
                                                 • System safety is the application of engineering and management principles, cri-
its safety analysis resources to the point
                                                      teria, and techniques to achieve acceptable mishap risk, within the constraints of

that little can be done to effectively
                                                      operational effectiveness and suitability, time, and cost, throughout all phases of

accomplish a thorough safety analysis.
                                                      the system life cycle.

They fail to understand that there is a
basic difference between engineers who          schedule, over-budget, and anxious to get     misleading as amount and quality of
develop code and engineers who analyze          their own work done. These distractions       product does not necessarily prove that
code for embedded hazards. Engineers            lessen the effectiveness of the peer          the right analysis was performed. On the
who develop code are success oriented.          review. Additionally, peer reviews tend to    other hand, the tangible products of a
They move from the implementation of            focus on the module level and place less      development effort do prove the efforts
one requirement to the next. They are           emphasis at the system level where many       of the development engineer.
driven by a typically over-budget sched-        of the embedded safety hazards reside.            From the development activity per-
ule and are always anxious to catch up.             Software developers must be safety        spective, if the code successfully per-
Conversely, safety engineers analyze code       conscious as they develop code.               forms its intended function and matches
in the context of finding failures. They        However, in light of the above and their      documented code standards, then return
move from analyzing one module to the           success orientation, developers continue      on investment is evident. Failure to iden-
next only when they are convinced that          to introduce embedded hazards in the          tify embedded hazards does not confirm
there are no embedded safety concerns.          software development process; it is very      that quality analysis has not been per-
                                                difficult for them to see their own errors.   formed any more than the identification
                                                E-mails are a vivid example. E-mail           of some embedded hazards ensures that
                                                authors re-read their own e-mails over        all hazards have been found. The analyst
Complexity Warrants Additional

With our mentality of getting the most          and over to verify correctness. They send     decides the correct amount of effort
Safety Analysis

out of software development budgets             them out only to later find a glaring error   spent in the analysis of a safety-critical
combined with the mindset that develop-         in the most awkward place that they           area for hazards without evidence of
ers can generate hazard-free code, man-         missed during multiple reviews. Some          their existence based on his or her expe-
agers pressure software developers to           well-known examples of software fail-         rience and understanding.
generate code faster and more efficiently.      ures resulting in mishaps are described in        In summary, development engineers
They insist that better processes, pride of     Appendix F of the Joint Software System       are good at building new systems in the
workmanship, better compilers and               Safety Committee’s “Software System           context of a driving schedule. Software
development environment tools, code             Safety Handbook” [1].                         safety engineers are good at evaluating
walk-throughs, and peer reviews should              Engineers who effectively analyze         code for embedded hazards. Requiring
sufficiently guarantee safe code. It is true    code for embedded hazards are con-            development engineers to constantly
that compilers and development environ-         vinced that all software contains embed-      evaluate their code with the understand-
ment tools are becoming more powerful,          ded hazards and that it is only a matter of   ing that something is wrong and there are
but at the same time they are becoming          time and circumstance before the haz-         embedded hazards seriously takes away
more complex. This additional complex-          ard(s) causes a mishap. The quality and       from the success orientation that enables
ity warrants additional safety analysis. It     quantity of analysis is a function of the     forward progress. Software safety analy-
is true that code walk-throughs, peer           analyst’s safety experience and under-        sis engineers are attuned to the identifi-
reviews, and other process improve-             standing of the code under inspection         cation of embedded hazards and the
ments result in better code; however,           within the context of the system.             amount of resources required to fully
they rely upon peers who are also behind        Tangible products of the analysis may be      analyze a safety-critical area of code. Just

November 2004                                                                                                             www.stsc.hill.af.mil   19
Software Toolbox

as letting off an automobile’s gas pedal the examined software will not be the                                        of the necessary review and rework.
does perform some slowing, and letting source of a system mishap.                                                     This is further impacted by the soft-
off the brake pedal allows continued                                                                                  ware safety analyst’s need for time to
movement, both the gas pedal and the Issues That Hinder Software                                                      become familiar with the function,
brake pedal are required for efficient                                                                                requirements, design, and code of the
handling. A combination of develop- Safety Efforts                                                                    software under analysis. If this need
ment engineers and software safety engi- There are many reasons why organiza-                                         is put off until code is released, then
neers in an independent environment tions mistakenly choose not to include a                                          safety concerns are, consequently,
provides a product that is synergistically software safety analysis activity early in                                 identified later in the implementation
more than if either were to do both the code development cycle (see Table 1).                                         phase, resulting in additional wasted
tasks.                                     These include the following:                                               resources because testing must also
    The software safety analysis process 1. Organizations erroneously believe                                         be repeated due to reworked require-
combines the people and the resources         that performing software safety                                         ments, design, and code.
to produce the most effective and effi-       analysis only needs to be done when                                2.   Government organizations find it dif-
cient product possible. The process           code has been generated. They                                           ficult and time consuming to estab-
ensures that priorities are followed,         believe that they can conserve                                          lish a contract with an independent
                                 Software resources during the requirements
products are produced, and schedules           Safety                                                                 organization to do software safety
are met. The four primary steps of a          definition and design disclosure phas-                                  analysis. It is important to start the
                                              es by waiting
                               Analysis Benefits until code is released to                                            process early to take into account the
software safety analysis process have
been described. Necessary products of         involve the software safety analysis                                    lead times as well as the need for
the safety analysis include a criticality     effort. They fail to understand the                                     either contracting directly with the
analysis report from Step 1, problem          importance of evaluating system and                                     software safety analysis company or
reports from all steps, and a software        functional requirements with respect                                    using a contract vehicle already in
safety analysis report – including testing    to safety prior to design, and of eval-                                 place by the contractor.
and analysis summaries – from Step 2          uating the design disclosure with                                  3.   The organization erroneously be-
                  of the process. When
through Step 4Primary Objective a                      to safety prior
                                              respectAdded Value to coding.                                           lieves that a good code development
                  conscientious software
thorough and Prevention of Mishaps            Safety concerns found during the                                        process will preclude all embedded
                    complete, and safety
safety analysis isInjury/Loss of Life         implementation phase after the code                                     safety hazards. Mishaps caused by
                                                       Cost Savings

hazards have Loss ofidentified and
                   been Equipment             has been generated require re-evalua-                                   software occur in fielded systems that
                                                 Schedule Safeguarding
removed, the resulting summary report         tion of the requirements, redesign,                                     were developed under good process-
                                                Improved Product Quality
becomes a tangible product that indi-         and recoding. This results in wasted                                    es. As described earlier, an indepen-
                Environment Damage

cates with a high level of confidence that    resources and schedule slips because                                    dent software safety analysis can find
                                                                                                                      embedded hazards and prevent
Table 1: Mistaken Reasons Why Software Safety Is Not Included During Early Phases of the                              mishaps when trained and experi-
System Development Life Cycle                                                                                         enced analysts are used and the soft-
                                                                                                                      ware safety analysis process is fol-
                                                                                                                      lowed.
                                                                                                                 4.   Organizations fail to factor into their
  Mistaken Reasons Why Software Safety Is Not Included During
                                                                                                                      budget the software safety analysis
    Early Phases of System Software Development Life Cycle
                                                                                                                      activity when cost projections are
                    Reason                                                Actual Need                                 supplied to planning activities. Upon
                                                                                                                      program execution, they severely limit
                                                                                                                      or do not fund software safety activi-
     Conserve funds because there is no code                   Early evaluation of requirements and design

                                                                                                                      ties because of the difficulty of find-
                    to review.                                  precludes costly coding and testing errors.

                                                                                                                      ing unbudgeted resources to cover
                                                                                                                      safety. Including software safety
     Difficulty establishing a contract with an               Most major defense contractors have General
                                                             Services Administration-type contracts that could

                                                                                                                      analysis activities in the master budget
      independent organization to do safety.
                                                                         support safety efforts.

                                                                                                                      plan is critical to software safety.
                                                                                                                 5.   The lack of mishap evidence gives
     Misconception that good coding processes                Success orientation of development engineers

                                                                                                                      the program manager a false impres-
        preclude embedded safety hazards.                       results in missed errors; development
                                                               environment pressures prevent thorough
                                                                                                                      sion of the safety state of the soft-
                                                                     system and interface analysis.

                                                                                                                      ware being developed. If an embed-
                                                                                                                      ded hazard is found and removed,
        Failure to budget in software safety                 Software safety analysis needs to be budgeted


                                                                                                                      there is no evidence that the mishap
                  analysis activities.                       independently of development activity budgets.

      Lack of mishap evidence if hazard found                 The objective of software safety is to remove
                                                                                                                      would have ever occurred. Embedded
                                                                                                                      hazards cause catastrophic mishaps
                   and removed.                                 hazard before mishap; prevention of one

                                                                                                                      only when a set of combining cir-
                                                             catastrophic mishap more than pays for safety

                                                                                                                      cumstances simultaneously occurs. A
                                                                             analysis effort.

                                                                                                                      thorough analysis covers areas and
     Lack of software safety analysis expertise                     Evaluate potential safety analysis

                                                                                                                      combinations of events that are
                  and processes.                                organizations on track record, processes,

                                                                                                                      either difficult to test or are not test-
                                                                                and staff.

      Problems found in safety analysis cause                  Early identification of safety problems saves
                                                                                                                      ed because of limitations due to test
                                                                                                                      time and tester expertise.
             additional work impacts.                           resources by preventing redesign, recode,

                                                                                                                 6.   Organizations have difficulty finding
                                                                       retest, and prevents mishap.


20 CROSSTALK The Journal of   Defense Software Engineering                                                                                         November 2004
                                                                                                         Safety Analysis as a Software Tool

    software safety analysis expertise and    resources and schedule.
    processes. As described earlier, effec-       Software development teams want to
                                                                                                 About the Author
    tive analysis is a function of the        generate a quality product, but are hesi-
    expertise and experience of the ana-                                                                   Blair T. Whatcott is the
                                              tant to have independent activities per-
    lyst. Qualified sources for software                                                                   lead engineer and pro-
                                              form analysis on their product. A change
    safety expertise will probably be more    of mindset will result in a synergistic                      gram manager of the
    costly because of the need to employ      team that produces a superior product.                       Software and System
    this level of expertise and experience.   Development engineers will be able to                        Safety Analysis Program
7. Organizations are concerned that           do what they do best in a success-orient-                    Office in the Infor-
    problems found by software safety         ed environment within their resources        mation Solutions Department of
    analysis will cause additional work       and schedules. Software safety analysis      Northrop Grumman Information
    that impacts schedule and resource        engineers will provide the necessary         Technology. He has managed and been
    needs. Reputable organizations do         checks and balances that result in a supe-   lead engineer on independent verifica-
    not generate unsafe software.             rior product, free of embedded hazards.      tion and validation and software safety
    However, because of the nature of         When these work as a team, software          analysis projects for more than 18 years.
    embedded hazards that result in           development will cost less and be pro-
    mishaps, there is always the concern                                                   These projects have focused on detailed
                                              vided on schedule in our world of con-       analysis and testing of embedded soft-
    that large amounts of resources are
                                              tinuous change and improvement.N             ware in military aircraft and weapon
    spent to prevent mishaps that have a
    very low probability of occurring.                                                     systems. He has a bachelor’s degree in
    These organizations fail to under-
                                              References                                   electrical engineering from Brigham
    stand that providing a small level of     1. Joint Software System Safety
                                                                                           Young University, Provo, Utah.
    software safety analysis can greatly         Committee. Software System Safety
    lower the probability of a mishap            Handbook.     Washington,    D.C.:
    occurring.                                   Department of Defense, Dec. 1999              Northrop Grumman

    Each of these mistaken reasons is            <www.egginc.com/dahlgren/files/               Information Technology

real. Together they may discourage using         ssshandbook.pdf>.                             1530 N Layton Hills PKWY

software safety analysis as a tool to gen-    2. Department of Defense. “Standard              STE 200

erate a better product for less cost.            Practice for System Safety.” MIL-             Layton, UT 84041-5683
Finding these embedded hazards early in          STD 882D. Washington, D.C.: DoD,              Phone: (801) 773-5274 ext. 13
the development cycle reduces cost, safe-        10 Feb. 2000 <www.safetycenter.               Fax: (801) 773-5262
guards schedules, and improves product           navy.mil/instructions/osh/milstd              E-mail: blair.whatcott@ngc.com
quality. Our experience shows that a             882d.pdf>.
requirements problem that is not found
until the test phase of the software
development cycle results in the loss of
70 percent of the time used to design,
code, and test the implementation of
that requirement.

Summary
We live in a world that is averse to unsafe
conditions. We also live in a world that
applies heavy pressure to building the bet-
ter and faster more efficiently. The con-
flicts between these two mindsets are
profit and risk. The courts of the land
insist daily upon the responsibility of the
product provider. Flashy packaging and
brand-name recognition oftentimes erro-
neously instill within us a false sense of
trust. And if we are harmed, our loss of
productivity and capability demands
compensation in order to survive.
    Software safety analysis as a tool
results in a safer and better product at a
cost and schedule savings. Early involve-
ment is critical to an efficient and effec-
tive analysis effort. Software require-
ments hazards will be found and
removed during the requirements phase.
Hazards found during the other software
development phases will be found during
the correct phase, preventing loss of

November 2004                                                                                                         ww.stsc.hill.af.mil   21

								
To top