10 Aug 2010

1. ECE/BENG-492 SENIOR ADVANCED DESIGN PROJECT Meeting #7 10 Aug 2010

2. ECE-492 Meeting#7 Q1: Teams – let’s discuss your Design Reviews Q2: Any questions about Design Document format and preparation?

3. Testing • Systems must be tested to ensure that they meet the engineering requirements • Testing is used to understand system’s reliability and uncover design flows • Frequently systems are tested for a variety of conditions and many combinations of conditions – 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 – such testing can save your project !

4. Testing Principles • Testing begins at a design process • Write test cases to check requirements spec • Write test plan while designing modules • Write test plan for module integration • Perform testing/debugging while implementing modules • The Test-Vee illustrates this process Test plan; Test cases

5. Every level of design has a corresponding level of testing • Notice added arrows – they emphasize that the left side develops a plan at a given level, while 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 • General benefits: • Test cases define exactly what the system/module must do • Testing prevents “feature creep” • The cases motivate developers by providing immediate feedback • The cases force designers to think about extreme situations • Test cases are a form of documentation • Test cases force the designer to re-consider the design of the module before building it

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

7. Types of Test • Black box tests • No knowledge of internal organization • These tests can be more challenging • Only access to inputs and outputs • Change inputs and observe outputs • White box tests • Knowledge of internal organization • Tests target specific internal nodes of the system to check that they are operating as expected • Might have expectation of fault module • Create test instance which reveals physical or logical errors

8. Constructing Tests • Four different types of tests shown in the Test-Vee figure • Debugging • Unit testing • Integration testing • Acceptance testing • Additional motivation • Testing reduces the number of bugs in existing and new features • 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

9. Experimentation Plan • You need to include a short experimentation plan in your Design Document – it’s required • In the discussion focus on • Which functionalities you want to test • Method of testing leading to an answer “we succeeded”, “we are close”, or “not so” • Designing experiments which will give you quantitative data; so you can process and derive conclusions • Type of graphs demonstrating your test/processed data • Do not write to ambitious plan (with many tests). Instead focus on few tests but explain them in greater detail. (Sometimes, less is more.)

10. CASE STUDY#1< Testing >

11. Project Management • Motivation • Engineers are regularly engaged in projects in their careers • Middle management continues to shrink • Industry now organizes more around projects than functions • Engineers have led the way on project management, it is now “hot and trendy” • According to a survey: #1 required skill for new engineers = Project Management Skills • Project Management  To complete the project: • On-time • Within budget • So that it meets the requirements

12. 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 • An ACTIVITY must have (see Table 10.1): • Definition of the work to be done • Timeframe for completion of the activity • Resources needed • Person(s) responsible for the activity • Predecessors – other activities to be completed before • Checkpoints for monitoring the progress

13. Graphical Visualization of the Project • Gantt chart • Preferred method for project visualization • See Figure 10.3 • Developed by Henry Gantt (1861-1919) – 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

15. Please use the following simplified version of Gantt charts

16. Guidance for creating WBS • Build the plan after your design is almost complete • Take the initial time estimates for activities and extend them almost by ~50% • 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 • Track the progress versus the plan • Don’t become a slave to the plan • Experience counts • Next semester – you need to resubmit your revised WBS

17. CASE STUDY#1< Work Breakdown Structure>