Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!tut.cis.ohio-state.edu!udecc.engr.udayton.edu!blackbird.afit.af.mil!jcardow
From: jcardow@afit.af.mil (James E. Cardow)
Newsgroups: comp.software-eng
Subject: Re: SE Terms Confusion
Message-ID: <1991Apr12.122408.26869@afit.af.mil>
Date: 12 Apr 91 12:24:08 GMT
References: <1991Apr11.144028.20787@murdoch.acc.Virginia.EDU>
Organization: Air Force Institute of Technology
Lines: 54

sgf0z@watt.acc.Virginia.EDU (Steven Glenn Fox) writes:

>I have been fighting with some SE terms recently and
>am looking for some help in defining them and how
>they relate to each other.  The terms I am referring to are:

>Software Quality (& Software Quality Assurance)
>Software Risk
>Software Testing
>Verification and Validation
>Software Reliability

>To get the ball rolling, here are some of my observations:
>1. Software Reliability is one component of Software Quality.

Simplistic, but okay, I'll agree.  If a definition is what your after, try
Musa's "the probability of failure-free operation of a computer program for
a specified period of time."  Whatever definition you choose, it needs to 
be tied to performing as specified (note, that says nothing about the 
reliability of the spec.)


>2..V&V is essentially synonymous to Software Testing.

Sorry, can't agree with this one.  Software Testing is a critical element of 
V&V, but then so is the review process.  V&V definition in IEEE Std are 
pretty good.

>3..Software Risk is the risk of a software project not
>    being completed, e.g. not fulfilling its specifications?  
>    Does this make it a component of Software Reliability?
 
Okay, this takes a little more thinking.  Risk, as I see it, is the risk of 
not meeting the customer's value expectations for the software (note, you
very well may be the customer)  So risk is a composite of cost, schedule, 
performance (the machine and the people), technology innovation, etc, etc.
One think I try to get across to my students is that risk is not all bad.  Risk
taking is what makes heroes, provided you can control and manage the level
of risk.

>4. Software Quality is measuring quantitatively the quality
>    of a piece of software on a number of attributes as
>    defined by the specific project.  These attributes often
>    are similar across many projects.

Well, I think the attributes are pretty well defined.  The problem is, which
are important for which project.  For instance, portability may be a critical
attribute in one project and totally trivial in another.  


Jim Cardow
Air Force Institute of Technology
Wright Patterson AFB, OH
jcardow@blackbird.afit.af.mil