19
Presentation for the INCOSE Symposium 2011 Denver, CO USA 1 Validation: Losing its Differentiation Jim Armstrong

Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Embed Size (px)

Citation preview

Page 1: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Presentation for the INCOSE Symposium 2011 Denver, CO USA 1

Validation: Losing its Differentiation

Jim Armstrong

Page 2: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

© 2011 Stevens Institute of Technology 2

Verification and Validation

Verification – Did you test what you were supposed to test?– To establish the truth of correspondence between a product/system and

its specification

– Based on Requirements Database, Traceability

– Are We Building the Product/System/Service Right?

– The comparison of a module's code against its technical design specifications document is one example

Validation – Did you test the right things?– The act of ensuring compliance against an original requirement. An

example is the comparison of the actual system response of an on-line transaction to what was originally expected, requested, and finally approved

– Based on Operational or Field Testing

– Are We Building the Right Product/System/Service?

Page 3: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

ISO Definitions

Verification: Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

– Note 1: In design and development, verification concerns the process of examining the result of a given activity to determine conformity with the stated requirement for that activity.

Validation: Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled.

– Note 1: In design and development, validation concerns the process of examining a product to determine conformity with users’ needs.

– Note 2: Validation is normally performed on the final product under defined operating conditions. It may be necessary in earlier stages.

© 2011 Stevens Institute of Technology 3

- ISO 8402

Page 4: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

4-4

Government vs Commercial

Source: EIA 632

Customer, Useror Operator

AcquirerRequirements

Product

System TechnicalRequirements

AssignedRequirements

Physical SolutionRepresentation

DesignSolution

Develop

Validate

Verify

DerivedRequirements

Logical SolutionRepresentation

SpecifiedRequirements

Other StakeholderRequirements

OtherStakeholders

SystemValidation

SystemValidation

Note 4:“In addition, there can be cases where it is appropriate to validate against actual needs and expectations of end users in their environment under real-world conditions. This is called by various names: market trial, field testing, beta testing, or operational test and evaluation.”

Note 4:“In addition, there can be cases where it is appropriate to validate against actual needs and expectations of end users in their environment under real-world conditions. This is called by various names: market trial, field testing, beta testing, or operational test and evaluation.”

© 2011 Stevens Institute of Technology 2-4

Page 5: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Related Software Term

Independent Verification and Validation (IV&V)– Verification is confirmation that an individual step in the

development process meets its requirements– Validation is confirmation that the software product meets its

requirements– Independent means V&V not performed by those who developed

the software Originally not the same company

– Originated in DOD-STD-2167

© 2011 Stevens Institute of Technology 5

Page 6: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Early Software Definition

© 2011 Stevens Institute of Technology 6

SoftwareRequirements

SystemRequirements

System ValidationTesting

Hardware andSoftware Integration

SoftwareDesign and TestPlanning Coding and

DevelopmentTesting Software

Integrationand Test Software

ValidationTesting

REQUIREMENTSDEFINITION

System ValidationWhat the System is supposed to do

What the System is supposed to do

Software Validation

Software VerificationIs the software doing whatit is supposed to do?

Is the system doing whatit is supposed to do?

SOFTWARE DEVELOPMENT

Independent Verification & Validation (IV&V)When performed by people outside the program doing the development

Independent Verification & Validation (IV&V)When performed by people outside the program doing the development

Page 7: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Text References

Blanchard and Fabrycky: “the steps and the process needed to ensure that the system configuration, as designed, meets all requirements initially specified by the customer.”

Kassiakoff and Sweet: “involves evaluation of the capability of the delivered system to meet the customer’s operational need in the most realistic environment achievable.”

Stevens, Brook, Jackson & Arnold: “Actions to confirm that the behavior of a developed system meets user needs.” (end of program)

Buede: A more expanded view

Presentation for the INCOSE Symposium 2011 Denver, CO USA 7

Page 8: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Buede

2-8

DesignEngineering

Systems Engineering

SE VeeTime

Operational Concept

Originating Requirements

System Requirements

Element Specs

Segment Specs

Component Specs

CI Specs

System Delivered

Elements Delivered

Segments Delivered

Components Delivered

CIs Delivered

OperationalValidity

Stakeholders’Needs

Acceptability

DevelopmentalVerification

ConceptualValidity

DesignValidity

RequirementsValidity

Page 9: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Larsen & Buede

© 2008 Stevens Institute of Technology 2-9

Page 10: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Requirements Validation

Is the requirement real?

Confusion with requirements verification– Quality checks for requirements

Consise Consistent Traceable Verifiable Formal Etc.

Example: validation of message maximum delivery time requirement– Discussion of potential conflict with data reliability requirement

Some percentage of data can be lost – infinite delivery time

– No consideration of whether or not the time specified has an impact on operations

Presentation for the INCOSE Symposium 2011 Denver, CO USA 10

Page 11: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Scukanec and van Gaasbeek

2-11

 Requirements Product

 Verification Are the requirements right? Do they meet the basic quality criteria (e.g., correct, complete)

Is there objective evidence that the product satisfies the requirements?

 Validation Are the requirements the right requirements, i.e., do they properly represent the customer need?

Does the product, when operated by representative operators, in the

representative operational environment, satisfy the customer

needs?

Page 12: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Manuals and Guidebooks

NASA’s Systems Engineering Guidebook – Meeting specifications - verification – Assuring that the system “accomplishes its purpose” – validation

FAA’s NAS Systems Engineering Manual (2006)– Limits the definition of validation to assuring that the

requirements are correct and complete– Activities that are included in other definitions of validation are

addressed elsewhere and with different vocabulary in this document

Department of Health and Human Services Practices Guide for Independent Verification and Validation– An activity that “validates that the product conforms with client

requirements”

Presentation for the INCOSE Symposium 2011 Denver, CO USA 12

Page 13: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

RFP for IV&V Services

RFP from the North Dakota Department of Human Services– “The validation services will ensure that the new Medicaid

system will meet the current and planned business needs of Medical Services, and that all necessary training, policy, process and procedural changes have been defined and implemented within Medical Services.”

Presentation for the INCOSE Symposium 2011 Denver, CO USA 13

Page 14: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

INCOSE SE Handbook

ISO definitions used Improved in consistency from earlier versions Some variation in detail sections

Also includes validation of models and simulations. – Confirmation that the model or simulation correctly reflects the

situation it is intended to model or simulate.

Presentation for the INCOSE Symposium 2011 Denver, CO USA 14

Page 15: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Observed Effects?

In appraisals– We don’t do validation, the customer does

In class– Difficulty identifying validation risks– Difficulty defining validation mitigations

Class discussion question– Confusion with verification at work

Natural forces at work?– Prevalence of convergent thinkers– Tendency to focus on target (spec)

Presentation for the INCOSE Symposium 2011 Denver, CO USA 15

Page 16: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Presentation for the INCOSE Symposium 2011 Denver, CO USA 16

Student Responses

Question: Identify validation risks and early mitigations

Responses:Mostly technical spec risksFew operational area concerns

– Different environment– People issues, customs

Mitigations are more verification– Extra testing to assure meeting spec– Design margin to reduce risk

Few “go find out” options– Site visits– Prototypes to user/maintainer

Page 17: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Presentation for the INCOSE Symposium 2011 Denver, CO USA 17

Student Discussion

Question: What do people at work define as validation?

Responses: Some good

– Field testing– CONOPS as reference

Some confusion– Subset of verification– “intended environment” gets lost

Page 18: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Net Effect

Loss of real world customer focus during development Products that don’t work in the real world Unhappy customers

Presentation for the INCOSE Symposium 2011 Denver, CO USA 18

Page 19: Presentation for the INCOSE Symposium 2011 Denver, CO USA1 Validation: Losing its Differentiation Jim Armstrong

Recommendation

Ensure real world focus and checks at all points

Don’t forget site visits Use of models and prototypes with operators

Presentation for the INCOSE Symposium 2011 Denver, CO USA 19