This page contains advice from students to students for
Senior Project.
In Fall 2009 the following question was asked on the mini-exam:
I need to refresh (or, at least, add on) to the advice for future students.
Please offer your best advice to future students in this class. I will likely
share this advice (but without your name) with future students. For full credit
your advice must be well thought-out and explained.
The answers follow.
I suggest that people get over their differences and work as a team sooner
rather than later. This will only increase productivity and not stop it.
Show up in class, if not sure on what to do ask the professor, start early,
break the workload early.
Take good notes from Dr. Christensen as mini exam will cover these
materials. Keep all handouts provided in this class for purpose of mini exam.
Keep in frequent communication with team members - you should always be
available by either email of phone, choose one. Respond promptly to team members
as you man miss out on meetings.
Starting early is great, but keep your momentum. It's not smooth sailing
till you're done. In 1-2 weeks or less research and decide what you can or
cannot do. The faster you do this the sooner you can begin. Pick a project you
enjoy. Because the time will fly and you may have a job from it! Expect to spend
money if you have any hardware you need to make.
My advice is to really spend the first week or so researching the
feasibility of the requirements you are given by your company before you commit
to them in the initial presentation. Just because a customer asks for something
does not necessarily mean that it is possible to do within the customer's other
requirements (so they conflict). It is important to really hammer out the
requirements with the customer very early on.
Don't wait until the last minute to start the project (we basically started
midway through the semester in early October). Go to the Guest Lectures: you
learn so much from them. As a side consequence obviously to attend the guest
lectures, go to class. Devote a lot of time to the class. Meet with your company
and stay in contact with them. There might be lack of communication on how the
project is progressing if you don't do this. Don't get distracted, and stick to
your timeline and plan.
The class take up a lot of time out side of class to be done correctly. USF
call the class 2 hours but it feel like it a 4 hour class with a lab, with all
of the time you spend outside of class. Every know this class meets once a week
(off for some weeks) you need to plan this are due for that week every if you
have no class.
I see now why people have said come to class. I am glad I did. Not only are
the lectures useful in general but they are also useful for this mini-exam! For
a small recommendation, I would extend the most common recommendation by saying
take detailed notes. Pertaining to the project, start early on the coding as it
will help on the design. Also, make sure everybody knows their roles at every
step. At times, people just floundered about not knowing what to do. Take the
lead if necessary. Practically, make sure to verify your requirements in the
presentations, visually if possible. Also, remember your audiences in the
presentations.
1) Do not drop the class after project assignments; this impacts others as
well as yourself. 2) Always be doing something, whether it is status reports,
documentation, paperwork, coding whatever this is always something to be done so
put the time in day by day, don't wait till the end. 3) Show up to guest
lectures their there for your benefit not Dr. Christensen's, and some of them
may be hiring.
I think the worst part of the project for us was to find out that some of
the things that the customer stated can be done were actually not feasible
because of the Google framework security blocks which made us look bad on your
eyes. We worked really hard to be able to make it possible which turned out to
be waste of time. So one of my suggestions to future students to go out and make
research to make sure the things that will except as requirements is actually
possible to implement. Another suggestion, I think I did not see in the
suggestion list is to elect a team leader and very well divide the work load
into pieces making sure everyone has enough work on the project for 7-8 hours.
Create a second traceability matrix that shows the status of each
specification item (fully covered, partially covered and not covered). Use this
traceability matrix when demoing to your client and update it when the client
agrees a specification item is covered.
The company we partnered with gave us the advice to build slack time only
into the end of the project. This way, you are forced to try to meet certain
goals early and if you run into troubles and need more time, it is when you are
well along in development.
In Spring 2007 the following question was asked on the mini-exam:
What advice you would give to students in this class in the next
semester? Make a list of things the students 1) should do and 2)
should not do. I will create an actual list to give to the students
next semester from the answers you give here.
The answers follow.
"Should do" items:
Come to class
Choose a project you are interested in
Meet with your team and your company EARLY
Be on time when meeting company
Ask Dr. Christensen questions if you do not understand something about the
design process or even your project (he has much knowledge about many things).
Do your best to stay on track of your plan.
If you don't know something do not just read about it, play with it and
figure it out as you go.
UPDATE DOCUMENTATION
Always have a working project
Ask questions and try to network, but don't be weird about it.
Broaden your knowledge on your subject, even if you don't think it will help
in your specific project, it will.
Buy a laptop
Always go to class when is needed. Even though this class does not require
much of class attending, lectures and speaker are very useful.
Keep in touch with Dr. Christensen via email or visiting his office hours.
Personally I found this to be very helpful because he is always trying to help
in any way he can. When developing a "oyr" specification, design, or anything
he a very useful tool.
Work ahead on your project.
Go to every meeting there is with the company that you are developing the
project with. You always learn something new from every visit.
The student should start the project early in order to avoid rushing at the
end of the semester.
Meet with the company as soon as possible.
Have good communications with your team members and be all in the same page.
Do lots of research in your area of the project.
Split the project into parts so it can be done faster.
Good project management.
Meet once a week.
See Dr. Christensen when help is needed.
Create a timeline for the project.
Meet the intermediate the little goals along the way to meet the final goal
in the end
Stay on top of everything from day one, don't let yourself get behind.
Clearly have the company define what will be included in the scope of the
project and if there are more things that can be added at the end as a bonus
then do so, but meet initial requirements first.
Start early!! This was the advice given to us at the beginning of the
semester but so few groups payed attention. We were one of the lucky that did
in fact start early and were much better off for it. I watched other groups
floundering because they waited too long to start.
Work as a team. We suffered from the "division of labor" problem a bit,
where we were each working on our own individual part without seeing the big
picture. It ended up working o.k. for us because we had a clear plan but I can
certainly see how we could have improved (especially in terms of design and
debugging) had there been more collaboration.
Test, test, test! We had a clear testing plan and that is the only thing
that saved us from a couple nasty bugs. From my talks with other groups,
testing does not seem to be a priority but if you get in your demo and your
program crashes you are toast.
Start early and clearly realize what you have to do
Meet with professor about what he clearly wants for deliverables
Ask a lot of question even
Go to class listen to speakers
Start coding early
Schedule much more time than you think you will need for this class. There
is no way that you will be able to get your project done if you expect to only
spend two hours a week on it.
Think of this class as a second job.
Meet with your tam members regularly.
Keep all paperwork up to date. It takes a lot longer than you think it
will.
Listen to clients
Ask questions
Start on projects early
Take notes and follow guidelines
Start coding right away
Conceptualize the project before starting coding.
Get started early
Work together, communicate well
Follow requirements and specifications, but don't be afraid to change if
necessary
Be prepared for prototype demo and final presentation/demo
Be active in keeping checkpoints with each other
Give yourselves your own deadlines
Present drafts to Christensen before assignment is due
Be diligent in keeping paperwork up to date
Start early
Dress respectably
Communicate well with your project company
Start as early as possible (same advise we got)
"baby steps" try to partition your project as much as possible into
functional and non-functional components that have been tested and verified
Create a lot of tests to verify the functionality of each component. Called
scaffolding in the book.
Start early - while this may seem obvious, no matter how "easy" a project
may seem, something will always come up to "throw a wrench in the gears"
Keep an open mind - while some people may say offensive things, look past
their personal comments and focus on the objective things.
Have specific times to meet every week about project
Spend time doing solid design that allows for individuals to work on their
own time
Communicate
Have regular group meetings to discuss status
Have checklists set in beginning so everyone knows what they are responsible
for
Immediately in beginning of semester start researching how your group will
accomplish the goal
Ask as many questions as possible to people who will know the answers:
faculty, project company
Have professor Christensen check your work before the due date
To prepare ahead
Before signing up, the students should discuss with the advisors the
academic load they will carry along with Senior Project. Not doing so may
result in a hands-on experience on how does it feel to see the project falling
behind and rescheduling (like chapter 2 of the book suggests) is not an option.
I believe that with a balanced academic load, the final project would be
properly tested and overall better.
Listen to the advice from Dr. Christensen on the very first day of classes
and get your project group and meet with him to discuss what are the pit-falls
to avoid. More important apply the advice.
Find out or decide what language, technology, or environment will be used
for the project and learn as soon as possible. There are plenty of tutorials
online. It is extremely helpful that at least one team member has experience
with it.
On the first couple of weeks, designate somebody in the group to be the
"manager" and that individual should keep an eye on upcoming deadlines and
demand completed work from team members on a timely fashion.
Meet with Dr. Christensen before turning in due documents. He will point
out things to be changed and it is better to fix them before.
Keep your company's contact informed of the status of the project at least
weekly.
Do your best to have things ready at least a week before due.
When having a demo, set it u p and try it before and at the same location
where the demo is schedule. What worked at home the night before will probably
not work in front of Dr. Christensen and it feels bad. (Really bad.)
Show up on time for guest speaker's presentation.
An advice I would give to the next semester students is they should
understand that they are not far from the real professional job, and they are
almost no students no more. The grade doesn't mean much; meaning there are
more important things than the grade. They should learn to work in teams, be
more flexible about their schedules, and understand that they are important no
matter how much contribution they give, every opinion could be a key to solve a
problem. They should learn how to design good algorithms, have a conceptual
contract, manage intellectual team work. The project may seem quite complex at
the beginning, but after understanding it, it will fell apart. The most
important thing to remember is to understand the problem. At last, students
must reserve enough time for the testing part, many surprises may happen.
Another thing I want to mention is the choice of the project. The students
should not jump into a project that requires some kind of skills which they do
not have and choose the project based on the name of the company. Do not let
driving distances become an issue; make sure to choose a good schedule that you
would stick with. Do not over or under estimate the driving time to meet with
your teammates.
"Should not do" items:
Skip class
Not meet with company
Do not have open line of communication with company
Have the same documentation as when you started (it should always be
improved up until the last day.
Don't ask questions when you have guest lectures (you are only hurting
yourself)
Not always have a working project
Do not dress like you are going to gym class
Ask Christensen for help unless you've done your research first.
Bicker or argue with those about you, it does not impress or help.
Be afraid to call and communicate with your company.
Wait until the end of semester to start working on the project.
Not keeping contact with the company they are working for.
Not keeping contact with Dr. Christensen
Giving all the work to the other students in the group.
Don't start the project at the last minute and start coding early.
Do not get angry with your partners.
Do not wait till the date before to turn things in
Do no wait to start your project half way through the semester.
Don't get overwhelmed, have the mentality that you can finish on time.
Do not fall out of communication with your company. Without mentioning
names, I know one group that was essentially lost because they had very little
communication with their company.
Skip class
Fall asleep during speakers
Get fussy with Dr. Christensen or your company: BE NICE
Don't wait. Do as much as you can as soon as you can.
Don't waste time thinking about what you are going to do. Just start something and get it working.
Don't be late for a guest lecture.
Don't dress inappropriately for your speeches or for a guest lecture.
Wait a month before starting
Not come to class
Ask the client TOO many questions
Not contact the clients early
Procrastinate. Anything.
Not follow up with team members
Not set deadlines
Think "oh, you'll get it done." Get it done, period.
Not keep in touch with your company
Skip class
Wait until end of semester
Start late
Overestimate the functionality of several different components when joined
together.
Forget about assignment dates. (They come fast at the end of the semester.)
Work by yourself (yourself meaning the team working by itself) - part of the
development process is design - you will not have a very good design unless you
are in constant communication with your company.
Wait until late to do everything
Try to force meetings in two days from now as it often conflicts
And I stress "Wait until the last minute!"
Assume that group members will get their parts done
Develop unrealistic time frames for due dates
Change requirements at the last minute
Ignore all the above
Think that because all parts of the project are finished. The job is done.
Integration of components is when all bugs come out.
