1322005 MAPLDDesign Integrity Concepts What Do You Mean It Doesn’t Do What We Thought? Validating a Design.

Slides:



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

Configuration management
Testing Medical Devices A Brief Overview © 2005 Max Cortner. Copying and distribution of this document is permitted in any medium, provided this notice.
Testing Workflow Purpose
Donald T. Simeon Caribbean Health Research Council
Chapter 12 Prototyping and Testing Design of Biomedical Devices and Systems By Paul H. King Richard C. Fries.
EECE499 Computers and Nuclear Energy Electrical and Computer Eng Howard University Dr. Charles Kim Fall 2013 Webpage:
Software Quality Assurance Plan
Chapter 2 – Software Processes
Alternate Software Development Methodologies
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 6/e (McGraw-Hill 2005). Slides copyright 2005 by Roger Pressman.1.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Lecture 7 Model Development and Model Verification.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
1 Testing. 2 About Testing  The reason the program is in testing is that it probably doesn’t work!  We test to find bugs before our users and hope that.
SE 555 Software Requirements & Specification Requirements Validation.
Validating and Improving Test-Case Effectiveness Author: Yuri Chernak Presenter: Lam, Man Tat.
Simulation Exercises Overview Activities designed to assess, enhance and evaluate preparedness.
Introduction to Software Testing
Software Testing & Strategies
Release & Deployment ITIL Version 3
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Understanding (and Untangling) Verification and Validation Requirements ISO 9001 vs. CMMI-Dev 1.2.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Introduction to ISO New and modified requirements.
Dillon: CSE470: QUALITY ASSURANCE1 Software Qualities Maintainer User Customer Good Documentation Readable Code Good Design Low Cost Portability Increased.
1 Software Testing (Part-II) Lecture Software Testing Software Testing is the process of finding the bugs in a software. It helps in Verifying and.
TESTING.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
MAPLDDesign Integrity Concepts You Mean We’re Still Working On It? Sustaining a Design.
TASK PACKAGING Module 1 UNIT IV ADDITIONAL TOPICS " Copyright 2002, Information Spectrum, Inc. All Rights Reserved."
Testing Workflow In the Unified Process and Agile/Scrum processes.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Approaching a Problem Where do we start? How do we proceed?
Lecture 7: Requirements Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
| 1 › Matthias Galster, University of Groningen, NL › Armin Eberlein, American University of Sharjah, UAE Facilitating Software Architecting by.
Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 MIS 161 Systems Development Life Cycle II Lecture 5: Testing User Documentation.
TESTING LEVELS Unit Testing Integration Testing System Testing Acceptance Testing.
Process System Capability An introduction to 9103 ‘VARIATION MANAGEMENT OF KEY CHARACTERISTICS’ Bernard LAURAS AIRBUS.
Safety-Critical Systems 7 Summary T V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis.
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
Chapter 10 Verification and Validation of Simulation Models
Building Simulation Model In this lecture, we are interested in whether a simulation model is accurate representation of the real system. We are interested.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Software Engineering 2004 Jyrki Nummenmaa 1 BACKGROUND There is no way to generally test programs exhaustively (that is, going through all execution.
Network design Topic 6 Testing and documentation.
Software Requirements Specification Document (SRS)
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
GLAST LAT ProjectFace to Face, 14 April 2004 LAT System Engineering 1 GLAST Large Area Telescope: EGSE and Interface Verification Pat Hascall SLAC System.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
Testing Integral part of the software development process.
 System Requirement Specification and System Planning.
This has been created by QA InfoTech. Choose QA InfoTech as your Automated testing partner. Visit for more information.
Chapter 8 – Software Testing
Software Requirements
Definitions.
Chapter 10 Verification and Validation of Simulation Models
Introduction to Software Testing
Lecture 09:Software Testing
Progression of Test Categories
Measurements Makes Walls White! Acceptance Criterion Fit Criterion
System Testing.
Presentation transcript:

MAPLDDesign Integrity Concepts What Do You Mean It Doesn’t Do What We Thought? Validating a Design

MAPLDDesign Integrity Concepts Agenda – Design Validation Concepts and implications Specification mitigations Design mitigations Test set mitigation Summary

MAPLDDesign Integrity Concepts Concepts Validation – Confirmation, through the provision of objective evidence, that the requirements for a specified intended use or application have been fulfilled

MAPLDDesign Integrity Concepts Implications The issues relating to validation encompass those of verification Additional concerns with validation –Caused by the need to match the application to the product –Application has been translated to specification through the requirements process –Requirements process is by nature imperfect –Sometimes the specification does not satisfy the needs of the application Result – a verified product might be invalid –May require significant rework to the product –May require accepting reduced functionality (waiver) A goal of the development process is to minimize validation failures –Begins in review of the requirements process (hopefully primary point) –Mitigate by design activities –Reduce by robust test set design

MAPLDDesign Integrity Concepts The Implication Illustrated Alice electronics (detector component and C&DH component) Joint requirement: process > 10 k sustained events per second Individual requirements defined for detector and C&DH processing –Both met individual requirements for processing –When combined only 6-7 k sustained events per second Verification of individual units led to invalid system What went wrong? –The overall requirements were not broken down correctly –The C&DH and DE test sets were not high fidelity Verified functionality, not performance We got lucky that a waiver was acceptable

MAPLDDesign Integrity Concepts Specification Mitigation Only list requirements, not desirements State unambiguous performance requirements Build in adequate margin –Not open-ended enhancement, but –Enough to accommodate performance shortfalls Ruthlessly remove TBDs Insist on definite test methods for mitigation Remember – Unless application needs can be unambiguously specified, they won’t be met!

MAPLDDesign Integrity Concepts Design Mitigation Implement specification exactly Isolate various sub-sections –Minimizes “corner cases” and negative interactions –Allows correction with minimal impact when things don’t work right Verify complex functions early, thoroughly, and completely –Allows early look at potential problems –Analysis / simulation / what ifs should be as realistic as possible Insist on end-user review of implementation –Allows user community to comment –Minimizes misunderstandings upon delivery Develop test plans that have high fidelity to the end application

MAPLDDesign Integrity Concepts Test Set Mitigation Ensure interfaces are maximally flight-like –Precludes misunderstandings of characteristics –Provides early indication of problems –Don’t emulate only one characteristic of interface Make test set reasonably sophisticated –Sufficient complexity to reproduce operational timing –Adequate functionality for stress testing Run all interfaces at maximum speed with margin Don’t let the same group build the tested unit (design) and the unit tester (test bench) –Identical assumptions might go into both ends of an interface –Faithful reproduction is dependent on familiarity (if possible, test bench should be provided by end user)

MAPLDDesign Integrity Concepts Test Set Mitigation (cont.) Make the control interface as application like as possible –Forces correct command structures / types –Allows all test scripts to be reproduced at higher levels If at all possible, incorporate early interface tests of real engineering hardware Keep the test (or simulation) environment unless the flight system changes –Don’t change test equipment hardware configurations –Apples to apples comparisons during tests vital –Ensure that flight changes are reflected in test set design

MAPLDDesign Integrity Concepts Test Set Mitigation (cont.) Use the same controls for test set development as for flight unit development –Configuration management –Software development –Peer reviews Build in diagnostics so that anomalies can be traced to test equipment or unit under test Ensure that test results mean something –Pass / fail criteria clear –Allowable flight parameter variations included –Reasonable displays (with significant information clearly shown) –Ensure that test set accommodates calibration

MAPLDDesign Integrity Concepts Summary Successful verification does not always guarantee successful validation Techniques can be incorporated that improve the likelihood that validation will succeed –Careful specification development –Thorough and cautious design techniques –Extensive test set fidelity to flight requirements Effective techniques for validation are extra effort –More time consuming –More expensive –But, definitely worth it.