2020(S11) Lecture:week 8: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
No edit summary
No edit summary
Line 2: Line 2:
<div style="padding: 10px; width: 670px; border: 5px solid #CC9999;">
<div style="padding: 10px; width: 670px; border: 5px solid #CC9999;">
=<center>Week 8 Tuesday </center>=
=<center>Week 8 Tuesday </center>=
==<font color = blue> </font color>==
Welcome back from break!
==<font color = blue>Why are we doing this?</font color>==
==<font color = blue> Test/Debug</font color>==
<center>''“Faith is a poor substitute for reason”'' Thomas Jefferson</center>
==Part 1: <font color = blue> Eau d'coli test/debug</font color>==
<center>
[[Image:Overall MIT2006 Fullsystem.jpg]]
</center>
Aye yay yay!  Won't we ever get away from this Eau d'E coli project?  Not yet!  Take a close look at the device-level system diagram.  You can't see all the underlying BioBrick parts (there are ~24 parts in total).  If you were the designer of this system, do you think that the system would work if you just synthesized all the DNA as a single contiguous strand, transformed this new DNA into a cell, and let your genetic program rip!?  Or, stated differently, what would be your next step if you tried to get everything working at once, and NOTHING HAPPENED, or, even worse, your engineered DNA killed the cell? <br>
<br>
Having a plan for testing and debugging your projects is critical.  To help you think about how to develop the best testing and debug plan for your 20.020 projects, spend the next 10' working with your team to outline a testing and debug plan for the Eau d'coli system.  Before you get started, designate one person on your team to act as spokesperson. Once the 10' are up, we'll ask each spokesperson for an accurate description of your testing and debug plan. If you're having trouble knowing where to start, you might consider:
*First, use the device level system diagram to sketch out a timing diagram (use a white board).
*Second, think about what this iGEM team could have done if they just added all this DNA to the cell, and then nothing happened (no smell, or worse, all the cells died). How would they go about figuring out what aspects of the project might be working, and what other components need to be revised or fixed?
*Finally, look again at the device-level system diagram.  Is there anything about the system's design that makes testing and debugging easier or harder than it might be otherwise?  Would you like to change any aspects of the system design to make testing and debug easier?
 
==Mapping these challenges to your project==
There is no such thing as either complete knowledge or flawless design. And if you believe, as Henry Petroski does, that "...the central goal of engineering is still to obviate failure, and thus it is critical to identify exactly how a structure may fail." (pg 195 in [http://www.amazon.com/Engineer-Human-Failure-Successful-Design/dp/0679734163 To Engineer is Human]), then you and your team will dedicate effort
*to collecting relevant data that validates or disproves the ideas in your own project and
*to anticipating failure modes so debugging your design is trivial rather than backbreaking. <br>These ideas of validation and debugging should be included in your Tech Spec Review, at least a first go at them.
 
=<center>Week 8 Studio</center>=
=<center>Week 8 Studio</center>=
{| cellspacing="2"  
{| cellspacing="2"  

Revision as of 11:23, 17 March 2011

Week 8 Tuesday

Welcome back from break!

Test/Debug

“Faith is a poor substitute for reason” Thomas Jefferson

Part 1: Eau d'coli test/debug

Aye yay yay! Won't we ever get away from this Eau d'E coli project? Not yet! Take a close look at the device-level system diagram. You can't see all the underlying BioBrick parts (there are ~24 parts in total). If you were the designer of this system, do you think that the system would work if you just synthesized all the DNA as a single contiguous strand, transformed this new DNA into a cell, and let your genetic program rip!? Or, stated differently, what would be your next step if you tried to get everything working at once, and NOTHING HAPPENED, or, even worse, your engineered DNA killed the cell?

Having a plan for testing and debugging your projects is critical. To help you think about how to develop the best testing and debug plan for your 20.020 projects, spend the next 10' working with your team to outline a testing and debug plan for the Eau d'coli system. Before you get started, designate one person on your team to act as spokesperson. Once the 10' are up, we'll ask each spokesperson for an accurate description of your testing and debug plan. If you're having trouble knowing where to start, you might consider:

  • First, use the device level system diagram to sketch out a timing diagram (use a white board).
  • Second, think about what this iGEM team could have done if they just added all this DNA to the cell, and then nothing happened (no smell, or worse, all the cells died). How would they go about figuring out what aspects of the project might be working, and what other components need to be revised or fixed?
  • Finally, look again at the device-level system diagram. Is there anything about the system's design that makes testing and debugging easier or harder than it might be otherwise? Would you like to change any aspects of the system design to make testing and debug easier?

Mapping these challenges to your project

There is no such thing as either complete knowledge or flawless design. And if you believe, as Henry Petroski does, that "...the central goal of engineering is still to obviate failure, and thus it is critical to identify exactly how a structure may fail." (pg 195 in To Engineer is Human), then you and your team will dedicate effort

  • to collecting relevant data that validates or disproves the ideas in your own project and
  • to anticipating failure modes so debugging your design is trivial rather than backbreaking.
    These ideas of validation and debugging should be included in your Tech Spec Review, at least a first go at them.

Week 8 Studio

HOMEWORK

We've rescheduled our talk with a premier genome engineer, Pete Carr, who will come speak with us tomorrow. Pete has done remarkable work in the MIT Media lab as part of the Center for Bits and Atoms, and has collaborated with George Church at Harvard Medical School on an ambitious genome rewriting project called "Re.coli." In advance of his talk tomorrow, please spend one hour looking at the following review article.
Also, before Friday, please add some thoughts to the class blog. This will be the fourth of 6 entries you'll make this term.

Week 8 Thursday

Dr. Peter Carr
Take 2: Thanks for coming to talk to our class today...we're glad you're feeling better!