Session 13 Page 11 ECE361 Engineering Practice Verification & Test Plan.

Slides:



Advertisements
Similar presentations
Process and Product Quality Assurance (PPQA)
Advertisements

MODELING THE TESTING PROCESS Formal Testing (1.0) Requirements Software Design Risk Data Approved, Debugged, Eng. Tested Code Automated Test Tools Tested.
More CMM Part Two : Details.
1 Software Engineering Lecture 11 Software Testing.
Project Bidding Procedures Enhancing Data and Presentation Skills for Engineers EDASPE Writing the RFP Training Courses – July 2004.
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
Software Testing and Quality Assurance
Projmgmt-1/33 DePaul University Project Management I - Risk Management Instructor: David A. Lash.
Greg Baker © Part One The Foundations – A Model for TQM Chapter # 3 Design for quality.
Systems Engineering Management
Session 7 Page 11 ECE361 Engineering Practice Brainstorming, Trades, Evaluation, and Conceptual Capture.
Session 6 Page 11 ECE361 Engineering Practice Brainstorming, Trades and the Design Process.
Robotic Football Group E1 Jesse Brawer Zach Eberbach Rob Mineo Laura Peveler Susan Sinclair.
Hazard Analysis and Critical Control Points
Stoimen Stoimenov QA Engineer QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
ASPEC Internal Auditor Training Version
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
QUALITY MANAGEMENT SYSTEM ACCORDING TO ISO
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
SQA Architecture Software Quality By: MSMZ.
Title page. 1. Identify the Problem Write a statement that answers the following questions. What are you trying to design? What are the requirement gaps?
Module 1 Session 1.1 Visual 1 Managing the Implementation of Development Projects Course Overview and Introduction.
CLEANROOM SOFTWARE ENGINEERING.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
IT Requirements Management Balancing Needs and Expectations.
Software Project Management Lecture # 10. Outline Quality Management (chapter 26)  What is quality?  Meaning of Quality in Various Context  Some quality.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
Company for Urban Innovative Transport (CUIT) 19/12/2007 Request for proposal.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
10 Aug 2010 ECE/BENG-493 SENIOR ADVANCED DESIGN PROJECT Meeting #2.
Joel Gerber Zachary Reaver Kurt Schilling.  Provides physical proof of development  Maintains product design knowledge base  Meets government and corporate.
Software Requirements Specification Document (SRS)
QUALITY MANAGEMENT SYSTEM
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Lectures 2 & 3: Software Process Models Neelam Gupta.
Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
What has been accomplished at the end of MSD 1 & 2?
6/6/ SOFTWARE LIFE CYCLE OVERVIEW Professor Ron Kenett Tel Aviv University School of Engineering.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
What is a software? Computer Software, or just Software, is the collection of computer programs and related data that provide the instructions telling.
University of Southern California Center for Systems and Software Engineering RDCR ARB CS 577b Software Engineering II Supannika Koolmanojwong.
Getting Ready for the NOCTI test April 30, Study checklist #1 Analyze Programming Problems and Flowchart Solutions Study Checklist.
Adaptive Software Development Process Framework. Version / 21 / 2001Page Project Initiation 2.0 Adaptive Cycle Planning 5.0 Final Q/A and.
Planning meetingCertification audit, stage 1 Pre-audit (optional) Document review Prior to every certification audit a planning meeting is conducted where.
PRODUCT VERIFICATION Adapted from the NASA Systems Engineering Handbook for CSULB EE 400D by Alia Bonetti.
Six Sigma Greenbelt Training
Product Validation Adapted from the NASA Systems Engineering Handbook for CSULB EE 400D by Alia Bonetti.
Module 7 Verify WSP Session structure Definition Actions Outputs
Software Verification and Validation
ECE361 Engineering Practice
Testing Process Roman Yagodka ISS Test Leader.
ECE361 Engineering Practice
Prepared by Rand E Winters, Jr. ASR Senior Auditor October 2014
Software Requirements
Flooding Walkdown Guidance
Level - 3 Process Areas (CMMI-DEV)
SQA Role during Software Requirements Phase
CMMI – Staged Representation
Quality Management Systems – Requirements
MRL 6 Artifacts (at End of TMRR) Page 1 of 6
Orders & Shipment Tracking
Software Quality Engineering
ECE362 Principles of Design
APQP PROCESS FLOW Prepare for APQP Plan and Define Program
RISK REDUCTION PROCESS
Adaptive Product Development Process Framework
DOD’S PHASED SYSTEM DEVELOPMENT PROCESS
Presentation transcript:

Session 13 Page 11 ECE361 Engineering Practice Verification & Test Plan

Session 13 Page Days til the Competition The Fans Await…

Session 13 Page 33

Session 13 Page 44 Design Process Assures Design will meet Requirements Requirements Specification BrainstormingTrades Preliminary Design Requirements vs. Capabilities Detailed Design Review ImplementationTestingReporting Stage 1 Stage 1 – Problem Definition & Potential Solutions Stage 2 Stage 2 – Design Stage 3 Stage 3 – Verification Deliver = $$$ This process is part of what we call Systems Engineering

Session 13 Page 55 Verification Plan Prepares Your Design for Customer “Sell-Off” The PDS describes the requirements for your design The Design Review presents your design to the customer The next step is providing proof to the customer that your design meets requirements –This is provided in the form of results from the various types of verification exercises you undertake –These exercises are described in a verification plan, which includes the test plan

Session 13 Page 66 What is the Verification Plan? Each PDS requirement must be verified to the customer –Prove that the system meets the requirements, to customer’s satisfaction –Can mean renegotiation of requirements or contract… –All of this is presented in a Verification Plan for customer approval Document presented to customer outlining plans for verification of design’s performance against requirements –Includes verification matrix and test plan –Eventually includes test results

Session 13 Page 77 Verification Includes Testing Each requirement is verified using one of several methods, as approved by the customer –Inspection – e.g., the box shall be blue –Analysis – e.g. the lifetime shall be 5 years –Demonstration – e.g. the device shall make three shots within 5 seconds –Test – e.g. the signal level at the output of the filter shall be greater than 1 mV For those items which are to be verified by test –Each test and its success criteria are to be documented in a test plan –Results must be documented to verify performance against requirements

Session 13 Page 88 Verification Matrix is Implemented as a Table Each requirement (“shall”) is entered as a line in the table, with a number/letter ID designator –Every requirement should be included –These requirement IDs can be used in the test plan to better organize the information Columns identify requirement ID, requirement, verification method, and comments –Verification methods are analysis (A), demonstration (D), inspection (I), and test (T) This should be a single page table presented early in the verification plan

Session 13 Page 99 Test Plan Purpose: To define the tests, their order and importance, and evaluation criteria –A complete list of all requirements to be tested –Establish a sequential order for testing –Assign priority to each test –Define the criteria for successful test results –Provides data for design refinement Results: Detailed records of all test setups and test results –Record ALL the conditions and results of testing –Test results available to client/customer –Redesign of system to overcome failure

Session 13 Page 1010 Test Plan Details Detailed testing specifications –The robot will be placed at the far right corner of the starting area and read the first data card in no more than 5 seconds. –The robot will read every data or operator card correctly 99 out of 100 times. Lack of detail in results shows lack of planning –The robot will complete the course quickly (how quickly?) –The robot will read the data and operator cards correctly (every time?)

Session 13 Page 1111 Amateurs test until it works. Pros test until it no longer fails. - Unknown

Session 13 Page 1212 Team Assignment Continue prototype construction Prepare verification plan including –Design Update –Verification Matrix –Test Plan Complete list of tests to be performed Details of test conditions/apparatus Criteria for successful test results Schedule of testing Use report format, with cover memo initialed by team members

Session 13 Page 1313 ECE 361 Assignments TEAM ACTIVITY – Continue Construction and Test Work! TEAM ASSIGNMENT - Prepare verification plan using report format Due 24,25 October in class, one per team, hard copy