Upload
philip-shields
View
215
Download
2
Embed Size (px)
Citation preview
Spring 2007
Lillevik 481s07-l1 1University of Portland School of Engineering
CS-EE 481
Senior DesignLecture 1
Fall re-cap
Spring pre-view
Debugging
Spring 2007
Lillevik 481s07-l1 2University of Portland School of Engineering
CS-EE 481
Our overall goal
University Professional
Practice,
Graduate School
Senior design facilitates the transition
Today
Spring 2007
Lillevik 481s07-l1 3University of Portland School of Engineering
CS-EE 481
Fall semester re-cap
• Formed design team and defined project
• Established a methodology
• Developed specification (FS doc)
• Created a plan (Plan doc)
• Designed the project (DR milestone)
It was a busy semester, many accomplishments
Spring 2007
Lillevik 481s07-l1 4University of Portland School of Engineering
CS-EE 481
Fall 2006 grades
• Distribution (CS/EE)
A = 6/9 A- = 0/1
B+ = 1/3 B = 0/1 B- = 0/0
C+ = 0/0 C = 0/2
• Class averagesCS = 3.5 8 students
EE = 3.5 18 students
Spring 2007
Lillevik 481s07-l1 5University of Portland School of Engineering
CS-EE 481
Evaluation messages
Design components
Technical
Process
Spring contribution may need to shift
Spring 2007
Lillevik 481s07-l1 6University of Portland School of Engineering
CS-EE 481
Spring semester pre-view
• Lots of implementation and debugging• Little formal lecture time (use class time for
team meetings)
• Two documents (TOP, Final Report)
• Selection of “Outstanding Project”• Founders Day: April 17
• Commencement: May 6
Spring 2007
Lillevik 481s07-l1 7University of Portland School of Engineering
CS-EE 481
Spring deliverablesDate Deliverable
Jan. 30, Feb. 1 January Program Review
Feb. 9 Theory of Operations 0.9
Feb. 23 Theory of Operations 1.0 and Approval Meeting
Feb. 27, Mar. 1 February Program Review
Mar. 27, 29 March Program Review
Apr. 13 Prototype Release and Approval Meeting
Apr. 17 Founders Day Celebration
Apr. 18 Final Report 0.9
Apr. 25 Post Mortem with Junior Class
Apr. 27 Final Report 1.0 and Approval Meeting
Ver
y bu
sy !
! 2 m
onth
s !!
Spring 2007
Lillevik 481s07-l1 8University of Portland School of Engineering
CS-EE 481
January2007
CS-EE 480 University of Portland
Pgm rev Pgm rev
Weekly
Weekly
Mon Tue Wed Thu Fri
4 5
8 9 10 11 12
15 16 17 18 19
22 23 24 25 26
29 30 31 1 2
1 2 3
XmasEnds
Weekly
Semester Begins
Spring 2007
Lillevik 481s07-l1 9University of Portland School of Engineering
CS-EE 481
February2007
CS-EE 481 University of Portland
Pgm rev Pgm rev
Weekly
WeeklyTOP 0.9
Weekly
WeeklyTOP 1.0
Approv mtg
Weekly
Mon Tue Wed Thu Fri
1 2
5 6 7 8 9
12 13 14 15 16
19 20 21 22 23
26 27 28 1 2
TOP 0.95to IR
Spring 2007
Lillevik 481s07-l1 10University of Portland School of Engineering
CS-EE 481
March2007
CS-EE 481 University of Portland
Pgm rev Pgm rev
Weekly
WeeklyPR info list
Weekly
Mon Tue Wed Thu Fri
5 6 7 8 9
12 13 14 15 16
19 20 21 22 23
26 27 28 29 30
Spring BreakStarts
Spring BreakEnds
Comp Exam
Spring 2007
Lillevik 481s07-l1 11University of Portland School of Engineering
CS-EE 481
April2007
CS-EE 481 University of Portland
FoundersDay
Final rpt0.9
WeeklyProto rel
Approv mtg
Weekly,optional
WeeklyFinal rpt 1.0Approv mtg
Mon Tue Wed Thu Fri
5 6
9 10 11 12 13
16 17 18 19 20
23 24 25 26 27
30 1 2 3 4
2 3 4PR info
to IR
FDRehearsal
Final rpt 0.95to IR
Peer reviews
FinalsStart
Post Mortemwith Jr’s
EasterMonday
FinalsEnd
Seniorluncheon
Weekly
Spring 2007
Lillevik 481s07-l1 12University of Portland School of Engineering
CS-EE 481
Comprehensive exam
• Purpose: curricula assessment and development
• Format: multiple choice
• Date: March 6 at 9-11 or 10-12
• Coordinators: Dr. Lillevik, Dr. Lu
• Policy: must pass (60%) or senior design grade dropped by one letter
• Senior luncheon: top 2 scores recognized
Spring 2007
Lillevik 481s07-l1 13University of Portland School of Engineering
CS-EE 481
Sr. design award
• Outstanding Senior Design Project• Purpose: recognized top two projects
• Started in 2003
• Senior class selects
• Names and title engraved on a plaque
• Teams present in afternoon session on Founders Day
Spring 2007
Lillevik 481s07-l1 14University of Portland School of Engineering
CS-EE 481
Product development cycle
Define Design Prototype Evaluation Production
Milestones/
Approvals
Product
Approval
Design
Release
Prototype
Release
Beta
Release
Product
Release
DocumentsFunctional
Specifications
Project
Plan
Debug &
Evaluation
Plan
Theory of
Operations
Qualification
Report
Not in class
Manufacturing
Report
EOL
Final ReportToday
Spring 2007
Lillevik 481s07-l1 15University of Portland School of Engineering
CS-EE 481
Two observations
• Time is of the essence !!– Don’t procrastinate– Maximize your time
• Debugging is a major challenge– All projects have anomalies (bugs)– Develop an approach, stick to it
Spring 2007
Lillevik 481s07-l1 16University of Portland School of Engineering
CS-EE 481
Fixing a leaky roof
Flashing fault
Leak in bedroom
chimney
Where you see the leak is different then the problem
Spring 2007
Lillevik 481s07-l1 17University of Portland School of Engineering
CS-EE 481
Debugging
Design Error
Cause Effect
Often, only the effect is observable !!
Usually ~6 steps to solve a problem
Spring 2007
Lillevik 481s07-l1 18University of Portland School of Engineering
CS-EE 481
Debugging Step 1
Spring 2007
Lillevik 481s07-l1 19University of Portland School of Engineering
CS-EE 481
Debugging Step 2
Spring 2007
Lillevik 481s07-l1 20University of Portland School of Engineering
CS-EE 481
Debugging Step 3
Spring 2007
Lillevik 481s07-l1 21University of Portland School of Engineering
CS-EE 481
Debugging Step 4
Spring 2007
Lillevik 481s07-l1 22University of Portland School of Engineering
CS-EE 481
Debugging Step 5
Spring 2007
Lillevik 481s07-l1 23University of Portland School of Engineering
CS-EE 481
Debugging Step 6
Spring 2007
Lillevik 481s07-l1 24University of Portland School of Engineering
CS-EE 481
Suggestions
• Keep an open mind, be objective
• Don’t confuse symptom with cause
• Avoid “trial and error” debugging
• Focus on root cause
• Make sure to test fix
Spring 2007
Lillevik 481s07-l1 25University of Portland School of Engineering
CS-EE 481
Debugging in practice
• Consumes 60% - 80% of project time line• Formal process (War Room meetings, several
hundred bugs)
• Bug tracking database (title, symptom, severity, cause, fix, state)
• Number of bugs determines product release date
Spring 2007
Lillevik 481s07-l1 26University of Portland School of Engineering
CS-EE 481
Spring 2007
Lillevik 481s07-l1 27University of Portland School of Engineering
CS-EE 481
Debugging Step 1
• Describe the symptomThe more detail the better
Spring 2007
Lillevik 481s07-l1 28University of Portland School of Engineering
CS-EE 481
Debugging Step 2
• Determine if symptom is:1. Repetitive (easy)
2. Intermittent (hard)
Spring 2007
Lillevik 481s07-l1 29University of Portland School of Engineering
CS-EE 481
Debugging Step 3
• Isolate cause (very hard)– Break the problem into smaller pieces– Check that each smaller piece works, then put
them together
Spring 2007
Lillevik 481s07-l1 30University of Portland School of Engineering
CS-EE 481
Debugging Step 4
• Propose and implement a fix– If you understand the cause, its often easy to
find a fix– Sometimes you want to propose several fixes
and later select the “best” one
Spring 2007
Lillevik 481s07-l1 31University of Portland School of Engineering
CS-EE 481
Debugging Step 5
• Test fix – Functional (does it work?)
– Regression (any not working that did before?)
Spring 2007
Lillevik 481s07-l1 32University of Portland School of Engineering
CS-EE 481
Debugging Step 6
• Document & communicate the changeWho needs to know what and when?