Final Project Presentation

Showcasing Your Complete Application

ImportantFinal Presentation Information

Presentation: Final class session Weight: 25% of total project grade (15% of course grade)

Overview

The final presentation is your opportunity to showcase the culmination of a semester’s work. You’ll present a complete, deployed application while reflecting on your architectural decisions, team dynamics, and learning journey. This is both a technical demonstration and a professional presentation of your work.

Final Project Expectations

By the final presentation, your project should demonstrate:

  • Feature complete: All planned MVP features implemented
  • Production ready: Error handling, security considerations, documentation
  • Well documented: README, API docs, architecture decision records
  • Professionally managed: Complete project history visible in GitHub

Deliverables

1. Final Technical Report (5-7 pages)

Executive Summary (0.5 page)

  • What you built and why
  • Key accomplishments
  • Live application URL

Architecture Deep-Dive (1.5-2 pages)

  • Final system architecture diagram
  • Technology stack with retrospective on choices
  • Complete ADR summary (what decisions were made and why)
  • Security measures implemented
  • Scalability considerations

Feature Documentation (1-1.5 pages)

  • Complete feature list with descriptions
  • User flows with screenshots
  • API documentation summary (link to full docs)
  • Known limitations and future enhancements

Development Journey (1-1.5 pages)

  • Evolution from proposal to final
  • Major pivots and their rationale
  • Technical challenges and solutions
  • What you would do differently

Project Management Retrospective (1 page)

  • Final project metrics (issues, PRs, commits by member)
  • Sprint velocity analysis
  • Team dynamics and collaboration assessment
  • Process improvements discovered

Individual Contributions (0.5 page per member)

  • Each team member writes a brief summary of their contributions
  • Key learnings and growth areas

3. Complete GitHub Repository

Your repository should be a portfolio piece:

project-name/
├── README.md                       # Comprehensive project documentation
│   ├── Project overview and demo link
│   ├── Features list
│   ├── Technology stack
│   ├── Local development setup
│   ├── Deployment instructions
│   └── Contributing guidelines
├── docs/
│   ├── proposal.md
│   ├── midterm-report.md
│   ├── final-report.md
│   ├── api/                        # API documentation
│   │   └── openapi.yaml           # Or equivalent
│   └── architecture/
│       └── decisions/             # Complete ADR history
├── frontend/
│   ├── Dockerfile
│   ├── README.md                  # Frontend-specific docs
│   ├── src/
│   └── tests/
├── api/
│   ├── Dockerfile
│   ├── README.md                  # API-specific docs
│   ├── src/
│   └── tests/
├── docker-compose.yml
├── docker-compose.prod.yml
├── .github/
│   └── workflows/
│       ├── ci.yml                 # Continuous integration
│       └── deploy.yml             # Deployment automation (if applicable)
└── LICENSE

4. Peer Evaluations

Each team member submits a confidential peer evaluation:

  • Rate each team member’s contribution (1-5 scale)
  • Provide specific examples of contributions
  • Identify team strengths and areas for improvement
  • Self-assessment of your own contribution
WarningPeer Evaluation Impact

Significant discrepancies in peer evaluations may result in individual grade adjustments. Be honest and fair in your assessments.

5. Final Presentation (12-15 minutes)

Present your completed project to the class:

  1. The Pitch (2 min): Problem, solution, and value proposition recap
  2. Live Demo (5-6 min): Complete walkthrough of key features
  3. Architecture Tour (3 min): Technical decisions, trade-offs, and learnings
  4. Team Retrospective (2-3 min): What worked, what didn’t, what you learned
  5. Q&A (2 min): Field questions from class and instructors

Rubric

Technical Report (25 points)

Criterion Excellent (5) Good (4) Satisfactory (3) Needs Work (2) Missing (0)
Architecture Analysis Insightful analysis; clear evolution story Good analysis Basic analysis Weak analysis No analysis
Decision Documentation Complete ADRs; clear rationale Good ADRs Some ADRs Few/poor ADRs No ADRs
Retrospective Quality Honest reflection; meaningful insights Good reflection Basic reflection Superficial No reflection
Individual Contributions Clear, specific contributions documented Good summaries Basic summaries Vague summaries Missing
Writing Quality Professional; well-organized; publication-ready Good writing Adequate Poor quality Unacceptable

Repository Quality (15 points)

Criterion Excellent (5) Good (4) Satisfactory (3) Needs Work (2) Missing (0)
Code Quality Clean, consistent; good test coverage Good quality Acceptable quality Poor quality Very poor
Commit History Clean history; meaningful messages Good history Acceptable Poor history Single commits
Project Management Complete issue history; closed milestones Good tracking Some tracking Minimal None

Presentation (15 points)

Criterion Excellent (5) Good (4) Satisfactory (3) Needs Work (2) Missing (0)
Demo Quality Smooth, professional; handles edge cases Good demo Demo works Demo issues Failed demo
Technical Communication Clear architecture explanation; insightful Good explanation Basic Unclear No explanation
Team Presentation All members contribute; cohesive story Good teamwork Some imbalance Very uneven Solo presentation

Peer Evaluation Modifier (10 points)

Criterion Full Credit (10) Partial (5-9) Significant Concerns (0-4)
Contribution Contributions match or exceed peer expectations Minor discrepancies with peers Major discrepancies or concerns raised

Final Checklist

Before your final presentation, verify:

Technical Requirements

Documentation Requirements

Presentation Requirements

Administrative Requirements

Grading Philosophy for Final

The final grade weighs both product and process:

Product (60%): - Does the application work? - Is it deployed and accessible? - Does it solve the stated problem?

Process (40%): - Was the project well-managed? - Did the team collaborate effectively? - Are decisions documented? - Is the codebase maintainable?

TipWhat Makes an “A” Project?

An “A” project demonstrates mastery of course concepts through thoughtful architectural decisions, clean implementation, effective teamwork, and honest reflection on the development journey. It’s not about feature count—it’s about doing things well.

Post-Course Opportunities

Exceptional projects may be considered for:

  • Showcase presentation to department or industry partners
  • Continued development as independent study
  • Publication in student portfolios or case studies
  • Reference for future course materials

Submission Instructions

  1. Final Report: Submit PDF to LMS by 11:59 PM on April 28
  2. Deployed Application: URL must be working by presentation time
  3. Repository: Ensure all code is pushed and README is complete
  4. Peer Evaluations: Submit via LMS within 48 hours of presentation
  5. Presentation: Be prepared to present during final class session

Questions?

  • Office Hours: Tuesday 9-11 AM, Pitt 2206
  • Webex: Use the project-final tag
  • Email: kuruzj@rpi.edu

Good luck with your final presentations! This is your moment to shine.