Skip to content

Course Project

In this course you will build a project as a team, taking on different roles and working in a manner in which a professional team might.

We will work together in Week 1 to come to a consensus on the project you will build.

Common Criteria

All projects will need:

  • To have user-facing & internal documentation.
  • To have a team strategy for git usage and code review.
  • To make use of automated testing and other quality control tools.
  • To meet certain architecture requirements documented below.
  • To come to a consensus on a license for the project.
  • To meet some number of the below optional requirements.

Warning

As the course progresses, additional criteria will be introduced.

Examples

Projects will be complete public-facing applications built with users in mind.

You can see last year's projects here.

Here are some example directions to consider:

A public-benefit software tool: A tool that helps communities organize or share collective knowledge. Examples would include tools to help volunteers organize themselves, or interactive applications for participatory planning or budgeting.

A government service prototype: A tool intended to be adopted by a government, or serve as an example of how a government might better provide a service. A redesigned workflow for receiving benefits, or a way for the public to suggest urban landscape improvements.

Providing novel views & analysis of data: A data pipeline to gather & compare energy usage data from different countries, along with tools for the general public & researchers to explore the data. This might include visualizations, simulations, and other features. This is similar to an enhanced 30122 project in some ways, but should be built according to the guidelines of this class: user-first, not data-first as 30122 projects are out of necessity.

Architecture Choice

I want to give teams a lot of freedom in what they build, but will provide a few architecture suggestions.

These are intended as starting points, and you are welcome to add to these, or propose your own alternative entirely.

Standard Web Application

This is a good choice if you would like the project to serve information to a web browser. It also allows you to write the majority of your code in Python, which is a good choice since it will ensure your entire team can contribute to every area as needed.

Your architecture will consist of:

  • A database
  • A backend that primarily serves HTML.
  • A lightweight frontend that is primarily HTML, CSS, and JavaScript.

Example Technologies: - sqlite3 or PostgreSQL for the database. - Django or Flask for the backend. - Pure HTML, HTMX or similar for the frontend.

In 2024, four teams chose this architecture.

API-First Application

This is a good choice if you want to build an app that runs on the web (particularly as a single-page application) or a mobile device. This architecture will require you to write a lot of JavaScript or possibly some Swift or Kotlin. These are presumably languages that fewer team members will have experience in. Careful consideration will need to be given to how to divide team responsibilities.

Your architecture will consist of (at least):

  • A database
  • A backend API.
  • A frontend that consumes the API.

Example Technologies:

  • sqlite3 or PostgreSQL for the database.
  • Flask, FastAPI, Django for the backend.
  • React, Vue, Svelte (JavaScript) or SwiftUI (iOS) for the frontend.

In 2024, one team chose this architecture.

Microservice Architecture

This is a variant of API-first, where instead of a single API you will build multiple smaller services that communicate with each other. This allows team members to work in smaller units, or perhaps individually, but will require careful coordination to ensure that the services work together.

Your architecture will consist of (at least):

  • At least (team size - 2) distinct microservices.
  • A frontend of some kind.

Example Technologies:

Example Technologies: - sqlite3 or PostgreSQL for the databases. - FastAPI or AWS Lambda for microservices. - React, Vue, Svelte (JavaScript) or SwiftUI (iOS) for the frontend.

Large Scale ETL w/ Static Site Generation

This is provided to get you thinking outside the box.

Not all projects need to have a traditional frontend. For data that updates infrequently, a static site can be a great choice. This can also be used to publish bulk data for others to use.

If your application is primarily about processing data, you could build an architecture centered around that.

  • A coordination service to manage the pipeline.
  • A database to store the data.
  • A final step of the data pipeline to publish bulk data and/or build a static site.

Example Technologies:

  • Pure Python, Luigi, Apache Airflow for the coordination service.
  • sqlite3 or PostgreSQL for the database.
  • hugo, jekyll, or similar for the static site generation.

Additional ("Complexity") Requirements

In order to make sure that projects are at a sufficient level of complexity for everyone to have a clear contribution, each project must have two "complexity requirements" to be agreed upon during the course of the quarter.

Some examples of roughly equivalent complexity are given below, you may decide to meet these, or propose other requirements that you feel are of similar complexity.

GIS Component

Your project makes meaningful use of the GIS libraries and tools.

To fulfill this criteria, the usage must be non-trivial, that is, more than just putting points on a map or a simple distance search.

Examples would be allowing users to plot their own routes on a map, or perform sophisticated area searches.

User Logins / Secure Information Handling

Your application requires users to authenticate. Users might log in because there is some sensitive behavior or information associated with their use of the application. (A log in without any purpose behind it would not count.)

Building on the data privacy & security module, your application will also be required to have a data privacy and retention policy if you choose this option.

Continuous Data Pipeline

Your application requires the continuous ingestion of data on a regular basis, preferably daily or hourly.

This requirement will mean that you will need to have a functional data pipeline early enough in the quarter to deploy it for a few weeks.

Accessibility

Your application is designed to work well for users with a particular disability, such as vision impairment.

Internationalization

Your application presents its interface natively in at least two languages using internationalization tools.

Team Roles

Team Size: 6+

Teams will need to define their roles and responsibilities. This is primarily to help you all plan out how you will work together and ensure that all the necessary work gets done.

Everybody should have two roles, and at least one of their roles should involve substantial coding. Some reasonable pairings are included, but almost any pairing can work as long as one is sufficiently technical.

Some suggested roles to consider:

Project Manager

  • Schedule Meetings
  • Keep Project on Track
  • Communicate with Course Staff
  • General Documentation

Pairs well with: Specialist, Support Engineer Roles, QA Engineer

Chief Architect

  • Lead Architecture Discussions
  • API Documentation
  • Final Decider on Tech Choices

Pairs well with: Lead Engineer Roles, Specialist

Lead Frontend Engineer

  • Primary Frontend Developer
  • Decider on Frontend Tech

Pairs well with: UI/UX Designer

Lead Backend Engineer

  • Primary Backend Developer
  • Decider on Backend Tech

Pairs well with: Chief Architect, Support Engineer Roles

QA Engineer

  • Testing Infrastructure Maintenance
  • Quality Control Tools
  • Git Repository Maintenance

Pairs well with: Frontend/Backend Engineer, Project Manager

UI/UX Designer

  • Lead User Research & Evaluation
  • Advocate for User Needs

Specialist/____ Support Engineer

Frontend/Backend/QA; or you might consider adding "specialist" roles for specific needs of your team such as GIS, Security, or Data Engineering.

Milestones

M1 - Design Milestone

This milestone will have you considering the users of your application before any design decisions are made.

See https://github.com/uchicago-capp-30320/sect-2025/blob/main/milestones/m1.md for instructions.

M2 - Work Plan

This milestone will continue building out design decision & placing the team in their roles.

See https://github.com/uchicago-capp-30320/sect-2025/blob/main/milestones/m2.md for instructions.

M3 - Git Repository & Data Model Exercise

This milestone will lay a solid foundation for your project to build upon and have you considering your data model.

See https://github.com/uchicago-capp-30320/sect-2025/blob/main/milestones/m3.md for instructions.

M4 - Preliminary Documentation

This milestone will have you document your architecture & API(s) to ensure the team gets on the same page on these ideas.

M5 - Prototype Check-In

This milestone will need a working prototype of some key functionality that can be reviewed with time for feedback to be incorporated.

M6 - Retrospective

The team, as a whole, will conduct a retrospective on how the team performed, and the effect it had on the final outcome.

Team Criteria

T1 - General Documentation

  • A clear & easy to follow README on how to get the project running.
  • Public-facing documentation on how to interact with the project. (Can be integrated into the site, a separate document, or a recorded video.)
  • A LICENSE file agreed upon by the team.

T2 - Internal Documentation

  • Docstrings on public interfaces.
  • A clear architecture diagram.
  • Documentation for API methods.

T3 - Code Quality

  • Is the code well-organized?
  • Are there tests in place?
  • Are there quality control tools in place?
  • Is the code readable and maintainable?

T4 - Performance

  • Does the application perform as intended?
  • Are there any serious efficiency issues in the code?

T5 - User Experience

How well does your project incorporate the needs of the user as stated in your initial exploration and further research?

T6 - User Interface

Is the user interface easy to use? Are there design flaws that are unaddressed?

T7 - Project Management

Did the team use version control & issue management well/according to plan?

T8 - Additional Complexity

This will be used to evaluate the team's implementation of an additional complexity as noted above.

T9 - Additional Complexity 2

This will be used to evaluate the team's implementation of an additional complexity as noted above.

T10 - TBA

An additional requirement will be announced during the quarter.

Individual Criteria

I1 - Team Evaluation

Each team will evaluate the contributions of their teammates throughout the quarter.

Consistent and significant issues will result in a penalty here.

I2 - Professionalism

This is an evaluation of how well you worked with your team and course staff.

Missing a scheduled meeting without appropriate notice would be the kind of thing that could qualify for a deduction.

I3 - Individual Code Contribution

The quality of one's personal code contributions to the team.

I4 - Individual Auxiliary Role(s)

You will be evaluated on how you performed in other roles such as project manager, QA engineer, etc.

Grading

Each of the milestones and criteria will receive a S, N, or U grade.

  • S - Satisfactory - The milestone was completed on time and met the requirements with only minor issues.
  • N - Needs Improvement - The milestone was completed, but had notable issues.
  • U - Unsatisfactory - The milestone was not completed.

For team criteria (including milestones), team members will receive the same grade barring extraordinary circumstances.

Exceptional Work

In some circumstances, where a team or team member has gone above & beyond, I may award an "E" for either a team or individual criteria grade.

For instance, if a team delivered a particularly strong implementation of an advanced architecture (that fit their project's needs!) they may get an E for the System Design component.

Or, if a team evaluation made it clear that a team member stepped up in a big way, they may get an E for their Individual Contribution.

These will be rare and at my discretion. Please do not ask "will XYZ earn an E?" I can only award them after I see the work.

Late Policy

A milestone will receive a penalty (S->N, N->U) if turned in 0-48 hours late.

After 48 hours, the milestone will receive a U. It will still be necessary to complete as part of the final project.

Participation Points

There will also be opportunities throughout the quarter for participation points. Examples include:

  • attendance & engagement in lecture
  • optional practice exercises
  • additional readings/Ed Discussion

There will be at least five of these opportunities, announced on a rolling basis. You may earn up to three of these, additional participation is appreciated but will not result in more points.

Final Grade

The final grade will consist of 20 ESNU grades combined with participation points.

To determine your final grade each "E" will be worth 3 points, "S" worth 2, "N" worth 1 point, and "U" 0 points.

These will be combined with up to three participation points.

Grade Minimum Points
A 40
A- 38
B+ 36
B 34
B- 32
C+ 30

I reserve the right to move these boundaries, but will only do so in your favor. (That is, I may decide the boundary for a B- is a 30, but I will not raise to 32.)

Example 1 - Room for Error

The grading system is meant to have some leeway for an N here or there, as sometimes things don't go as planned or you need to prioritize other things.

People on a team with 3N can still receive an A if they earn all three participation points. (Or 2 participation points, and an E somewhere along the way.)

Example 2 - Individual Criteria

Remember that four of the twenty criteria are assessed on you as an individual.

A team that does very well might earn 30 of the 32 possible points from the 16 joint criteria.

If a member misses meetings, fails to turn in work on time, etc. they may see themselves with U grades on their individual criteria, earning a C+ or B- while other team members end with an A- or A.

Example 3 - Process

A team that stays on track with milestones, documentation, and other process items will have already earned 24 of the 32 possible group points.

This means that a technical issue or omitted complexity criteria will be far less severe than ignoring the process requirements in this course.

In practice, it is likely that the teams with strong processes will be able to avoid these outcomes, but there are a lot of unknowns in building a piece of software in 9 weeks. Nobody is going to do poorly because they didn't deliver what they intended, so long as the reason for that was not in process shortcomings.