Meetings and classes
- On Tuesdays, your team will meet with your assigned mentor.
We will assign your team to one of the Tuesday sections. Show up at
the assigned time and await your mentor meeting.
- Wednesdays will be used for a variety of purposes. Most
Wednesdays will feature lectures or your team presentations.
When teams present, we will use two rooms; otherwise, we will
use one room for all.
- In addition to the official Tuesday/Wednesday times, you
should meet with your team at least once during the week.
Teams
- You must meet with your team at least once a week, and everyone
in a team must commit to that common time.
- Group dynamics in a team can sometimes turn sour, in which case
you first try and resolve the issue within the team, and then
approach your mentor. You need to approach your mentor soon
after the problem occurs. We will not save doomed teams late in
the game.
Trello and Git
(Fall and Spring)
We will use Trello
and Github throughout this course
in both semesters.
- Trello is a time-and-task management tool that helps coordinate
within a team, and also allows continual updating and editing of
tasks.
- Github is a code repo system that makes it convenient for teams
to share code and keep code up to date.
- Please view tutorials on both and learn how to use these tools
yourself. Each team will have a single trello account, and a single
Github repo. We will expect you to have this set up by the end
of the second week.
- Your Trello screen should have three columns:
- The first column (initially empty) will have "Completed
tasks". This will contain all the cards for tasks that have
been completed.
- The second column will feature "Currently working on"
tasks, typically for the current month.
- The third column will feature "Future tasks". Ideas for the
future will come up in discussions and during mentor meetings.
These should first go into "Future tasks". Then, once you
deliberately pick on a task for the current month, move that
card to the "Currently working on" column.
- Every task should have a start-date, projected end-date,
and a clear description of what the outcome will be.
- Tasks can be quite small, as in: "install and test OpenCV".
Generally, it's preferable to break tasks into small ones.
Writing assignments
(Fall)
Our alumni are always telling us "require more writing and oral
presentations" and "clear writing is essential to success in the
workplace".
Accordingly, this course will feature several writing assignments
in which the content is rather straightforward but where you will
have an opportunity to practice writing clearly. All writing
assignments will be due in the Fall.
See the writing assignments
for more details.
Presentations
(both Fall and Spring)
One way by which you can have striking impact and work your
way towards leadership is to give effective presentations.
Many of our alumni have rated the presentation training
in senior design as one of its most important non-negotiable features.
We often hear of alumni stories where, in a workplace
room full of ivy-leaguer, our alumni stand out because they
are able to give an excellent presentation.
Accordingly, in this course, we will show you how to
blow an audience away with a strong, forceful presentation.
See the presentation requirements
for more details.
Design and design homeworks
(Fall)
Chris Toombs will be teaching you about software engineering and
design. How exactly do you go about building a large project?
What is a systematic way to plan ahead, think through pieces of the
project so that the process is manageable? What are best practices
in design? These questions and others will be the focus on his
lectures.
Your goal is to apply design principles to your project. First,
you will use your project as the basis for completing homeworks
assigned by Chris. Second, you will apply sound design principles
as you proceed with your project, with the understanding that you will
have to explain how these design principles were applied.
HCI and HCI homeworks
(Fall)
Elyse Nicholas will be teaching you about HCI and front-end design.
What makes an interface easy-to-use and intuitive?
What principles can one distill from years of HCI experience with
actual users? How do you apply these to your project?
These questions and others will be the focus of her lectures.
The application of these principles to your project greatly
depends on the project. Some projects have a rich user interface.
Others (like a systems project) might have less of an interface.
In any case, you will complete homeworks, applying as much to your
project as possible.
Demos
(Spring)
To demonstrate progress on your project throughout the year,
we will schedule demos that indicate the expected level of progress:
- Bootcamp. The "bootcamp" phase of your project
is the beginning phase where you are exploring various tools
and APIs. You need to show that you've installed the tools,
are able to get the "helloworld" in each tools/API working,
and are able to integrate these in your project.
At this stage, your project remains "undesigned" and somewhat
haphazard. That's OK, because you are exploring the underlying
technologies or solving small issues, such as getting some hardware
to work, or getting a phone to talk to a server, and so on.
- 30% demo.
Discuss with your mentor what aspects, if completed, will constitute
30% progress towards completion.
Important: By this time, you will have attended lectures
on design and thus, your 30% needs to start incorporating elements
of design.
- 40% demo.
A few more things demonstrably working beyond 30%. Also, at this
stage, your project should feature considerably more design. You
should be able to explain how components integrate and how
you can test both individual components and the whole.
There should be no "totally empty" component. Even if you haven't
gone far with a component, you should at least have a "shell" of a
component that does something as a placeholder.
- 70% demo.
You will be at the 70% stage when your design is refined, and most
components are at least partially working. It's quite possible
that the algorithmic challenge remains or that you have yet to
successfully train a machine-learning algorithm. We're looking
for software completion as opposed to project success at
this stage.
- 90% demo.
At this stage, nearly everything is working and you only have
finishing touches or a little more functionality to add.
- 100% demo. As the name implies.
- Final demo.
The final demo is where we "kick the tires" and grade the project.
You will bring
everything you need to demo, demonstrate compilation, execution,
and answer detailed questions about your implementation.
Winter break
(Spring)
Examine the due dates closely and you'll see the 40% demo
scheduled for December and the 70% for mid-January.
This is not a mistake: you should expect to develop a good deal
of your project over the winter break. Clearly, you'll want to also
rest and recover, but please plan on blocking off enough
time during the winter break to work on your project.
Why do we do this? We have scheduled your final presentations
in mid-April rather than May (during finals) to avoid panic over
whether project completion will hold up graduation. We would rather
you spend your last few weeks as a senior in a celebratory mood,
basking in nostalgia and excitement about graduation, rather than
nervously scrambling to pass the course.
Note that you always have the option of being ahead of schedule,
which will free up more of the winter break.
Project webpage
(Spring)
Create a single webpage (hosted anywhere, as long as it's
publicly accessible) for the project with the following elements:
- A clear picture of every team member.
- For every team member: a short (one paragraph) biosketch that says a
little about you, your interests, dreams etc.
- Screencast.
Create an 10-minute screencast using the slides in your final presentation where you talk as you go from slide to slide. Think of this as a record of your final presentation that anyone can view.
- Links to the following:
- All writing assignments (even though they are cumulative).
- The Final-Report (that's in the final package below).
Note: do not link to the source code from the website. The source is
in the final package.
Final package
(Spring)
The final package must be submitted by noon, Tuesday May 5
in your group's google drive folder (a replica of the code
should be in your team's github account) with the following items:
- Code.
- The most recent working version of all your project’s code
in a single zip file.
- A README file that explains how to install all libraries needed, what paths need to be set up etc to get your project running.
- A simple test program that can be run at the command-line that will run only if everything is correctly installed.
- Submitted homeworks:
All submitted homeworks (design, HCI) for each team member for
both Fall and Spring. Make
one folder for each team member inside of which should go that
team member's submissions.
- A document called "Final Report" that includes the following sections:
- Section 1: Team member names, and a description (a list) of
who-did-what in the project.
- Section 2: A brief non-technical
overview of your project (2 paragraphs).
- Section 3: The link to your project website, with a list of
items on the website. See the description above on this page
about
what the project webpage needs to have.
- Section 4: A complete list of libraries, packages and APIs
that you used for the project. This is not inclusive of your
own code.
- Section 5: A brief technical overview of your
project (2 paragraphs).
- Section 6: One "if I had to do this again" paragraph
from each team member that contains technical
lessons learned, and what
would you have done differently if you know what you know now
(but with exactly the same project). Examples could include
using a different API, some other type of restructuring etc.
- Section 7: Instructions for follow-on projects.
Write a detailed set of instructions for the next group of
SD students who choose to build on your project:
- How to download and get the project working. If there's
equipment, a description of where to purchase (what model # etc).
- What works, what doesn’t, what to be aware of (pitfalls, issues).
- Ideas for next steps.
- Any other relevant documents such as licenses.
Important:
- If your project involved equipment bought by the Department, please return the equipment before noon on Tuesday, May 5.
- The final website and package will be graded on completeness
and ease of use. Please take the time to make them understandable.
Late policy
- Writing Assignment Late policy:
Late writing assignments will lose 20% per 24-hour period (not pro-rated).
- Submission of all writing assignments must follow the submission
rules above. All reports, presentations and such will be submitted
via your project website AND via google drive. You must submit
both a document and a PDF (which we will use for grading).
- Presentations and demos cannot be submitted late for credit as
they are required in-class.
- The submission time will be determined by the upload time of the pdf on google drive.
-
If you’re seeking an extension because you’ve been ill and have a letter from a doctor, please see us about it. Please remember that many deadlines for this class are known far in advance, so being sick for (for example) 5 days might not be reasonable justification for an extension.
Grade breakdown
Fall:
- 20% writing assignments
- 20% presentations
- 20% design homeworks
- 10% HCI homeworks
- 20% timely and continued progress towards project
- 10% high enthusiasm, motivation, team cheerleadership
Spring:
- 10% HCI homeworks
- 10% practice presentations
- 15% final presentation
- 20% timely and continued progress towards project
- 30% final demo
- 10% final package, website
- 5% attendance, enthusiastic participation