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

From OpenWetWare
Jump to navigationJump to search
(New page: {{Template:20.20(S13)}} <div style="padding: 10px; width: 670px; border: 5px solid #99CC99;"> =<center>Week 8 Tuesday </center>= Welcome back from break! == <font color = blue>Test/Debug <...)
 
(New page: {{Template:20.20(S13)}} <div style="padding: 10px; width: 670px; border: 5px solid #99CC99;"> =<center>Week 8 Tuesday </center>= Welcome back from break! == <font color = blue>Test/Debug <...)
 
(No difference)

Latest revision as of 12:58, 21 January 2013

Week 8 Tuesday

Welcome back from break!

Test/Debug

“Faith is a poor substitute for reason” Thomas Jefferson

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

Project work day

Today will be a project work day with your senior mentors in advance of the Tech Spec Review, one week from today!

Week 8 Thursday

HOMEWORK

Before Friday, please add some thoughts to the class blog. This will be the fourth of 6 entries you'll make this term.