ECE-492 SENIOR ADVANCED DESIGN PROJECT

Transcription

1 ECE-492 SENIOR ADVANCED DESIGN PROJECT Meeting #7

2 ECE-492 Meeting#7 Q1: Let s discuss your Design Reviews Q2: Any question about Design Document format and preparation? HW5: Teams show your background phenomenology as a foundation of your approach

3 STEP 10: TESTING PLAN Systems must be tested to ensure that they meet the engineering requirements Testing is used to: o Verify system functions and performance against requirements o Uncover design flows o Find implementation errors (and bugs) o Understand system s reliability Testing frequently requires building a separate system dedicated to the execution of tests and collection of test data

4 Systems are tested for a variety of conditions and many combinations of conditions o But, for complex systems, it s almost impossible to test against all combinations of conditions Testing can be time consuming and costly, but at the end, testing saves money (e.g., Hubble Telescope) The costs of corrections is lower before systems are deployed Testing must be considered throughout system implementation and integration such testing can save your project!

5 Test plan and Test cases Testing Principles Testing begins at a design process o Write test cases to check requirements spec o Write test plan while designing modules o Write test plan for module integration o Perform testing/debugging while implementing modules Development Requirements Specification System Design Construct Integration Test Unit Test Testing Acceptance Test The Test-Vee illustrates this process Debugging

6 Every level of design has a corresponding level of testing Notice added arrows they emphasize that o The left side develops a plan at a given level, while o The right side executes the test plan accordingly An acceptance test must be written to test against requirements specification You will need to develop test cases early next semester

7 Influence of Test Planning on System Design Test cases define exactly what the system/module must do Testing prevents feature creep Test cases motivate developers by providing immediate feedback Test cases force designers to think about extreme situations Test cases force the designer to re-consider the design of the module before building it Test cases are a form of documentation and an integral part of contract obligations (!)

8 Dos and Don ts for ECE-492/3 Too many ECE-492/3 projects are finished with o Very limited testing (NOT GOOD) o A demo of See, it works attitude THIS IS NOT ACCEPTABLE! o Ad hoc testing plan implemented at the end (NOT GOOD) o No data diagrams, statistical analysis, etc. (NOT GOOD) Advice o Spend a lot of time on testing to develop a powerful statement We succeeded rather than It works o Collect data. Process data using statistical analysis. Show diagrams. Derive conclusions and discuss performance and problems. o Answer to: Tell me when your system fails - but use quantitative data, diagram of process test data, or similar. Don t use intuitive explanations.

9 Types of Test Black box tests o No knowledge of internal organization o These tests can be more challenging o Only access to inputs and outputs o Change inputs and observe outputs White box tests o Knowledge of internal organization o Tests target specific internal nodes of the system to check that they are operating as expected o Create test instances which reveal physical or logical errors

10 Constructing Tests Four different types of tests shown in the Test-Vee figure o Debugging o Unit testing o Integration testing o Acceptance testing Additional motivation Testing reduces the number of bugs Tests reduce the cost of change Tests improve design Tests allow you to change and optimize components Testing forces you to slow down and think more (!) Testing makes development faster Tests reduce fear

11 Experimentation Plan You need to include a short experimentation plan in your Design Document it s required (!!!) In the discussion, focus on: o Which top-level functionalities you want to test o Method of testing leading to an answer we succeeded, we are close, or not so o Designing experiments which will give you quantitative data; so you can process and derive conclusions o Type of graphs demonstrating your test/processed data

12 CASE STUDY Clock Timer < Step 9: Testing >

13 Summary: Testing Plan in ECE492 Start with the development of an acceptance test o A test which will verify two or three system requirements o Focus on performance requirements (easiest to demonstrate; will give you the most powerful justification of a success) Define a simple test case; next move on to a more challenging test case Think immediately what data you need to collect and how to collect them Do not write too ambitious plan (too many tests) Instead focus on few tests but explain them in greater detail (sometimes, less is more) Keep data from debugging and integration (just in case)

14 STEP 11: PROJECT MANAGEMENT Motivation o Engineers are regularly engaged in projects in their careers o Middle management continues to shrink o Industry now organizes more around projects than functions o Engineers have led the way on project management, it is now hot and trendy o According to a survey: #1 required skill for new engineers = Project Management Skills o This has more to do with all team members understanding project management aspects rather than being a manager (!)

15 Project Management Objectives (!) To complete the project: On-time Within budget So that it meets the requirements

16 Work Breakdown Structure WBS is a hierarchical breakdown of the tasks and deliverables that need to be completed in order to accomplish the project objectives ACTIVITY a combination of a task and its associated deliverables TASK/CHECKPOINT an action that accomplishes a job DELIVERABLE an entity that is delivered to the project

17 ACTIVITY An ACTIVITY must have: Definition of the work to be done Timeframe for completion of the activity Resources needed Person responsible for the activity Predecessors other activities to be completed before Checkpoints for monitoring the progress

18 Graphical Visualization of the Project Gantt chart Preferred method for project visualization Developed by Henry Gantt ( ) a bar graph representation of activities on a timeline Frequently, each activity must be complemented by a numeric Task Completion Rate (in percentages) Include Milestones major in-progress demos given to your FS See Figure 10.3

19 I D Task Name Start Finish Duration Jan 2005 Feb /16 1/23 1/30 2/6 2/13 2/20 2/27 11: Interface Circuitry 1/10/2005 2/22/ d 2 1.1: Design Circuitry 1/10/2005 1/27/ d 3 1.2: Purchase Components 1/28/2005 2/10/ d 4 1.3: Construct & Test Circuits 2/11/2005 2/22/2005 8d : Current Driver Circuitry 2/11/2005 2/14/2005 2d : Level Offset & Gain Circuitry 2/11/2005 2/15/2005 3d : Integrate Components 2/16/2005 2/22/2005 5d 82: LED & Driver Circuitry 1/10/2005 2/9/ d Research A/D Converters 1/10/2005 1/10/2005 1d Complete Hardware Design 1/11/2005 1/19/2005 7d Purchase LED & Driver Components 1/20/2005 2/2/ d : Construct & Test 2/3/2005 2/9/2005 5d 1 3: System Integration & Test 3 2/23/2005 3/3/2005 7d

20 You can use the following simplified version of Gantt charts Project Planning Chart Reporting Period Task Name Completion Rate 1 Weeks Robot hardware development 1.1 Platform construction 100% 1.2 Motion system development 100% 1.3 Short-range sensor system development 100% 2. Motion control system development 2.1 Micro-processor system integration 100% 2.2 Motion control software programming 100% 2.3 Motion control system integration 100% 3. Experimentation and testing 3.1 Testing robotic platform 65% 3.2 Experiment #1 100% 3.3 Experiment #2 0% 4. Uprade #1 implementation 4.1 Long-range sensor system development 75% 4.2 Long-range sensor integration 4.3 Testing and Experiment #3 0% 0% 5. Commercial applications analysis 0% 6. Demonstration (milestones) 7. Reporting

21 CASE STUDY: Clock Timer < Step 10: Work Breakdown Structure>

22 Summary: Project Management in ECE492 Build the plan after your design is almost complete Take the initial time estimates for activities and extend them almost by ~30% Assign a lot of time for testing and integration Factor in lead times for part ordering Do not assign all team members to all tasks Experience counts Next semester you need to resubmit your revised WBS