Progress status report (Overleaf)
In this report, you should assess the progress you are making
on your project teams and update the work plan as necessary. Include your
group's
names and email addresses on the overleaf section as well. This is not likely
to be a
long report--just a checkpoint document to make sure you're on a good
track--
towards completing the project in the available time.
A 2-3 page summary of the problem your
project team is solving, and your high-level approach.
Start with yourprevious progress report (if any) and add
the following content to your progress report .
The progress summary report should
inform about,
- Design decisions,
- The target audience for the project (who the users are), personas, user stories if any
- What is the overall design? What are the core features?
- How does the requirements/design satisfy the needs of your users?
- What tools/technologies will you use and why?
- What is the overall design? What are the core
features?
- How does the UI/UX satisfy the needs of your users?
- Screen shots of the user interface or a prototype (in
your intial progress reports).
- Data Models (ER, Use Cases, Class Diagrams, HTA, Sequence Diagrams) - optional
- System architecture and implementation details (if any) - optional
- Current Status
- What is the current status of the implementation?
- What is left to do?
- Who is doing what?
- Project Gantt Chart - optional
Final Report (Overleaf)
A
comprehensive report describing
the project. This should be a "complete" document, so it should
include front matter (title page, abstract, table of content,
chapters),
problem statement, explain your design and implementation and
evaluation. This report should stand by
itself as the
archival description of the project. It’s
likely to be reasonably large document. Written
report will be evaluated both on the quality of the project but also on
the
quality, comprehensibility and completeness of the presentation.
- Each individual teams should write their own section/chapter in
the main project report. Make sure to list the team member names, email
addresses at the start of the section/chapter.
- The
report may include portions of your earlier reports (proposal, progress
reports, prototypes, concept, design, etc.).
- The
project report should be checked for spelling and grammar.
- Your
evaluation (or evaluation strategy) - 2 separate sections for mobile and web teams
- What
are the characteristics of users that you would invite to evaluate this
system?
- What
kind of tasks will you ask them to perform?
- What
metrics will you use to evaluate the success of your system?
- Comparison
with existing applications (which)?
- Performance
measures (how will you measure them)?
- Other
criteria?
- You
should address the same questions as those you have addressed in the
previous
reports, only with more details, especially regarding some of the
challenges
that you need to solve and your experimental results if any.
- You should
also include your conclusions from the study and point out how your
work can be
further extended (i.e., future work).
- References should
list ALL sources that you used for your project. It
is
recommended that you list your references in the IEEE Square numbered style. All team members must be involved in preparing this
section, and provide a list of URL's, books, or other sources that they
used
for the project.
- Provide any specific code segments and explanations (non-trivial), this may include pseudo-code or actual code segments.
- Provide
as much graphics as
you can—not only UI components, but any kind of diagrams and
illustrations that
will make it easier for us to understand and evaluate your effort.
Graphics are
always helpful, you have probably heard the saying “a
picture is worth a thousand words!"
- Do
not just show the diagrams—for all figures, tables, and diagrams
provide some narrative
discussion! Unfortunately, diagrams, particularly technical
diagrams, are rarely if ever self-explanatory. You should document the
alternative solutions that you considered as well as the arguments for
the
final choice. Diagrams only represent your final solution, but do not
explain
why you decided on this solutions and what alternatives were
considered. Hence, all diagrams must be accompanied
with
explanation
and discussion of alternatives and tradeoffs. Anything that could lead
to
ambiguity or misunderstanding on the reviewer’s part, should be clearly
explained. Explanations should be written in prose and key arguments
highlighted in bullet points.
- There is no
limit on the number of pages
for the report. Of course,
you should avoid stuffing your report with redundant or irrelevant
material.
Final
project presentations / demos
- The project schedule and sign up available at Piazza
- Time 15 mintues per each team + 5 mintues question/answer.
- When
your 15 minutes are up, I will stop you and we will move to the Q/A
time. During those 5 minutes, the next team should begin to setup. We
will start the next presentation exactly 5 minutes later. If you have
trouble setting up, you will lose time for your presentation. As a
result, I highly recommend that all teams do a walkthrough of their
presentation before Tuesday, just to make sure that whatever
resources you need are available.
- In terms of content, you will
have to make hard decisions about what to include in your presentation
(and what to cut). Do not feel like you have to jam every technical
component into your talk; indeed, presentations that sacrifice clarity
for overstuffing inevitably fare poorly. Remember that you have the
project report as an avenue for communicating all of the details of
your approach, so you are free to use the presentation as a
higher-level opportunity to motivate your part of the project, give clear insight
into your approach, and give us a flavor of your overall development and
results. Manage your time carefully.
- Specifically, you should probably use fairly large fonts
and clear figures.
- All team members must participate!
- As we assess your presentation, here are some of the points we will consider:
- Preparation
and poise.
Did you speak to the audience rather than look at the slides? Did you
expand on what was on the slides rather than read them word-by-word?
Did you speak at a reasonable pace rather than too fast or too slow?
Did you appear to be spontaneous and fluid, avoiding the use of
distracting mannerisms and colloquialisms?
- Use of
allotted time.
Was there a good balance between inspirational material and technical
content? Did you complete your presentation in time? Did you have to
skip some important material (e.g., conclusions) in order to complete
your presentation in time?
- Use of
visual aids.
Did you use pictures/diagrams to explain your ideas? Did you have
graphs of experimental results? Did the slides contain short, clear
bullets rather than long sentences and/or cryptic equations?
- Presentation
is visually appealing and strongly effective presentation. Easy to read
slides, utllized creativity in use of graphics, headings, colors, and
white space to provide sequential information from introduction to
conclusion.
- Presenters are confident and professional
with eye contact and clearly conveyed problem, methods, techniques,
conclusions. Answer questions well.