(no subject)

From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Thu May 13 2004 - 09:46:48 EST



=09by marcie.it.uts.edu.au (PostfixFiltered) with ESMTP id BFA3226234 =09for <re-online@it.uts.edu.au>; Thu, 13 May 2004 01:21:18 +1000 (EST) Received: from blue.rahul.net (blue.rahul.net [66.237.72.10]) =09by filter.it.uts.edu.au (Postfix) with ESMTP id 4CC991D6297 =09for <re-online@it.uts.edu.au>; Thu, 13 May 2004 01:21:11 +1000 (EST) Received: by blue.rahul.net (Postfix, from userid 48) =09id 7A2C114B27; Wed, 12 May 2004 08:21:07 -0700 (PDT) Received: from 128.107.170.251

        (SquirrelMail authenticated user dorfman)
        by squirrelmail.rahul.net with HTTP;
        Wed, 12 May 2004 08:21:07 -0700 (PDT)
Message-ID: <4936.128.107.170.251.1084375267.squirrel@squirrelmail.rahul.ne= t>
In-Reply-To: <200405110638_MC3-1-8228-529E@compuserve.com> References: <200405110638_MC3-1-8228-529E@compuserve.com> Date: Wed, 12 May 2004 08:21:07 -0700 (PDT) Subject: Re: [re-online] validation vs. verification - any defacto/dejure

     references?
From: dorfman@rahul.net
To: re-online@it.uts.edu.au
Cc: dorfman@rahul.net
User-Agent: SquirrelMail/1.4.2-0.1.7.x
MIME-Version: 1.0
Content-Type: text/plain;charset=3Diso-8859-1 Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
X-Spam-Status: No, hits=3D1.1 tagged_above=3D0.0 required=3D6.3 tests=3DNO_= REAL_NAME,
 PRIORITY_NO_NAME
X-Spam-Level: *
Sender: owner-re-online@it.uts.edu.au
Precedence: bulk
Reply-To: re-online@it.uts.edu.au

     Over the years there has been serious controversy over the definitions of verification and validation; specifically, software and system engineers have used different definitions. IEEE standard 610.12 (1990), IEEE Standard Glossary of Software Engineering Terminology, contains:
- Validation. The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.
- Verification. The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

     Note that both these involve only the system's internal documentation rather than actual needs (which may of course differ from the documentation).

     However by 2004 I believe the System Engineering definition is winning the battle; thus Verification is closer to the 610.12 definition of validation while Validation depends on actual needs.

> -------------------- Begin Original Message --------------------
>
> Scott Finnie wrote,
>
> "In our projects we informally use the terms validation and verification
> as
> follows:
>
> * Validation is checking with stakeholders (sponsors/users) that th=
e
> requirements as specified meet their needs. It's therefore targetted at
> human acceptance
> * Verification is ensuring that an implemented system is consistent
> with the specified requirements.
>
> This is in line with use I've seen elsewhere, although I don't have any
> formal references or definitions. Would be grateful if anyone could poin=
t
> me to relevant material...
> "
> -------------------- End Original Message --------------------
>
> Hi Scott,
>
> Your usage is consistent with my understanding...
>
> ...verification is checking we built it right, validation is checking we
> built the right thing.
>
>
> The SEI's Capability Maturity Model contains a Maturity Level 3 process
> area for each of Verification and Validation.
>
> The respective purposes of these process areas are specified as...
>
> "The purpose of Verification is to ensure that selected work products mee=
t
> their specified requirements."
>
> "The purpose of Validation is to demonstrate that a product or product
> component fulfills its intended use when placed in its intended
> environment."
>
> (Ref: CMU/SEI-2002-TR-012)
>
> I trust this helps.
>
>
> Best regards,
> Grant Rule
>
> _________________________________________________________________________=
__
> News Flas=E5h: Introduction to the CMM Integration SE/SW/IPPD/SS v1.1
> [staged]
> SEI-authorised workshop plus practical measurement to drive
> implementation.
> All you need to know, from requirements management and project planning,
> to
> organizational innovation and causal analysis. SEI certificated course.
> Transition Partner: Ken Dymond (PTI). Facilitated by: Grant Rule (SMS).
> 21/24-Jun-04 at London's Gatwick airport. =A32100 GBP includes
> 4 day residential workshop plus all meals and course materials.
> The 2nd and 3rd participants from one organisation can book at a discount=
=2E
> Participants' comments: http://www.gifpa.co.uk/cst/training/cmmi_2002.htm=
l
> _________________________________________________________________________=
__
> Software Measurement Services Ltd.
> 143 High Street, Edenbridge, Kent, TN8 5AX UK
> http://www.software-measurement.com/
> T:+44(0)1732-863-760
> F:+44(0)1732-864-996
> M:+44(0)7770-503-241
> E:PG_Rule@compuserve.com or G.Rule@measuresw.com



To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.

This archive was generated by hypermail 2.1.6 : Mon May 24 2004 - 09:00:19 EST