Capstone Rubric: Detailed Assessment Criteria

This rubric applies to all three capstone projects: the Personal Finance Tracker, the Trivia Game Engine, and the Data Dashboard. Each project is assessed across six criteria weighted to reflect the priorities of this course. The total is 100 points.

Criterion 1: Functionality (40 points)

This is the largest portion of the grade because a program that doesn't work isn't a program — it's an aspiration. Functionality measures whether your application meets the required features specified in the project description.

Exceeds Expectations (36-40 points)

• All required features are implemented and work correctly
• At least two stretch goals are implemented and functional
• The application handles all edge cases identified in the project spec (empty datasets, tied scores, first-run scenario, etc.)
• The user interface is intuitive — a new user can navigate the application without reading the source code
• The application performs well with realistic data volumes (100+ transactions, 50+ questions, 1000+ data rows)

Meets Expectations (28-35 points)

• All required features are implemented and work correctly
• Edge cases are handled for the most common scenarios
• The user interface is functional — all features are accessible, even if the flow isn't perfectly smooth
• Minor bugs may exist in uncommon scenarios but do not affect core functionality

Approaching (16-27 points)

• Most required features are implemented (at least 75%)
• Some features have bugs that affect usability but don't crash the application
• Some edge cases are unhandled
• The user interface works but requires the user to know the "right" inputs

Needs Improvement (0-15 points)

• Fewer than 75% of required features are implemented
• Core features have bugs that prevent normal use
• The application crashes during common workflows
• Missing critical features (e.g., no file persistence, no reports, no scoring)

Criterion 2: Code Quality (20 points)

Code quality measures whether your code is readable, maintainable, and follows the conventions taught throughout this course. A working program written in spaghetti code is better than a broken program with perfect style — but a working program with clean code is what we're aiming for.

Exceeds Expectations (18-20 points)

• Functions are short (under 25 lines each), focused, and well-named with verb phrases (e.g., calculate_monthly_total(), not data() or do_stuff()) (Chapter 6)
• Variable names are descriptive and follow Python naming conventions (snake_case for variables and functions, PascalCase for classes) (Chapter 3)
• No code duplication — repeated logic is extracted into functions or methods (Chapter 6)
• Appropriate use of Python idioms: list comprehensions, f-strings, context managers, unpacking, enumerate (Chapters 7, 8, 10)
• Code is organized into modules with clear, logical groupings (Chapter 12)
• Comments explain why, not what — the code itself is clear enough to explain what (Chapter 6)
• No dead code (commented-out blocks, unused imports, unreachable branches)
• Constants are defined at the top of modules, not hardcoded in function bodies

Meets Expectations (14-17 points)

• Functions are reasonably sized and named
• Variable names are mostly descriptive (a few unclear names are acceptable)
• Minimal code duplication (one or two repeated blocks)
• Python conventions are followed with minor inconsistencies
• Code is split into multiple modules
• Some comments present where logic is non-obvious

Approaching (8-13 points)

• Some functions are too long (40+ lines) or do too many things
• Variable names are inconsistent or occasionally cryptic (e.g., x, temp, data2)
• Noticeable code duplication across the project
• Some Python conventions violated (e.g., mixing naming styles)
• Code is in too few modules (everything in one or two files)

Needs Improvement (0-7 points)

• Functions are absent or extremely long (100+ lines)
• Variable names are largely single letters or meaningless
• Extensive code duplication
• Python conventions are not followed
• All code is in a single file with no modular organization

Criterion 3: OOP Design (15 points)

OOP design measures how well you've applied the object-oriented principles from Chapters 14, 15, and 16. This isn't about using classes for the sake of using classes — it's about using them to manage complexity effectively.

Exceeds Expectations (14-15 points)

• Classes have clear, single responsibilities (Single Responsibility Principle) (Chapter 16)
• Each class encapsulates its own state — other classes don't reach into its internals (Chapter 14)
• @property is used for computed attributes where appropriate (Chapter 14)
• Special methods (__str__, __repr__, __eq__, __lt__) are implemented where they add value (Chapter 14)
• Inheritance is used appropriately (not forced) — subclasses genuinely extend or specialize the parent (Chapter 15)
• Composition is used where it makes more sense than inheritance ("has-a" vs. "is-a") (Chapter 16)
• The class hierarchy matches the problem domain — someone reading the class names can understand the application's structure
• No "god classes" that do everything, and no "anemic classes" that are just dictionaries with extra steps

Meets Expectations (10-13 points)

• At least 3-4 well-designed classes with clear responsibilities
• Encapsulation is mostly respected — occasional direct attribute access where a property would be better
• Special methods are implemented for the most important classes
• Inheritance or composition is used in at least one place where it genuinely simplifies the design
• Class design is reasonable even if not optimal

Approaching (5-9 points)

• Classes exist but responsibilities are unclear or overlapping
• Some classes are too large (doing multiple unrelated jobs)
• Limited use of special methods or properties
• Inheritance is either absent or forced into a situation where it doesn't fit
• Some OOP principles are applied but not consistently

Needs Improvement (0-4 points)

• Minimal or no use of classes (procedural code only)
• Classes are used but don't encapsulate state effectively (public attributes everywhere, no methods of substance)
• No special methods, properties, or inheritance
• The class structure doesn't reflect the problem domain

Criterion 4: Error Handling (10 points)

Error handling measures whether your application is robust — whether it can survive unexpected input, missing files, and user mistakes without crashing or producing wrong results. This criterion reflects the EAFP philosophy and exception handling practices from Chapter 11.

Exceeds Expectations (9-10 points)

• All user input is validated before processing (Chapter 11)
• try/except blocks use specific exception types — never bare except: or except Exception: without good reason (Chapter 11)
• The application never crashes from user input, missing files, or malformed data
• Error messages are helpful: they tell the user what went wrong and how to fix it (e.g., "Invalid amount: 'abc'. Please enter a positive number like 42.50.")
• The EAFP principle is applied where appropriate (try the operation first, handle the exception) rather than always checking before acting (Chapter 11)
• File operations use context managers (with statements) consistently (Chapter 10)
• Edge cases are handled: empty collections, division by zero, first-run with no data file, extremely large inputs

Meets Expectations (7-8 points)

• Most user input is validated
• try/except blocks use mostly specific exception types
• The application rarely crashes — common error scenarios are handled
• Error messages are present, even if not always perfectly helpful
• File operations mostly use context managers

Approaching (4-6 points)

• Some input validation is present but gaps exist (certain inputs can cause crashes)
• Some bare except: blocks or overly broad exception handling
• The application crashes on uncommon but predictable scenarios (e.g., empty file, missing column)
• Error messages are generic ("An error occurred") rather than specific

Needs Improvement (0-3 points)

• Little or no input validation
• The application crashes on common user mistakes (wrong menu choice, non-numeric input)
• No try/except blocks, or exclusively bare except: with pass
• File operations don't use context managers (resource leaks)

Criterion 5: Testing (10 points)

Testing measures whether you've written an automated test suite that verifies your code works correctly. This criterion reflects the testing practices from Chapter 13 — not just that tests exist, but that they test the right things.

Exceeds Expectations (9-10 points)

• At least 15 unit tests using pytest (Chapter 13)
• Tests cover the core logic: calculations, data transformations, filtering, sorting, scoring — the parts where a bug produces wrong results (Chapter 13)
• Tests cover edge cases: empty inputs, single items, boundary values, invalid data (Chapter 13)
• Tests use fixtures for shared setup data (Chapter 13)
• Tests are independent — each test can run in any order without affecting others
• Test file organization mirrors source file organization (test_models.py tests models.py, etc.) (Chapter 12)
• All tests pass on submission
• Test names are descriptive: test_median_even_length_list, not test_1 or test_stuff

Meets Expectations (7-8 points)

• At least 10 unit tests using pytest
• Tests cover the most important logic paths
• Some edge cases are tested
• Tests are mostly independent
• Most tests pass on submission

Approaching (4-6 points)

• At least 5 tests using pytest
• Tests cover basic functionality but miss edge cases
• Some tests may depend on each other or on external state (file system, specific data)
• Some tests may be failing

Needs Improvement (0-3 points)

• Fewer than 5 tests, or tests are not automated (manual "run and check" testing only)
• Tests don't verify meaningful behavior (e.g., only testing that objects can be created, not that they behave correctly)
• Tests are disorganized or mostly failing
• No use of pytest conventions or fixtures

Criterion 6: Documentation (5 points)

Documentation measures whether someone other than you can understand your project. This is the smallest criterion because the code itself should be the primary documentation (well-named functions and classes communicate intent), but external documentation matters for real-world projects.

Exceeds Expectations (5 points)

• A README file explains: what the project does, how to install/run it, usage examples with expected output, and project architecture
• All classes and public methods have docstrings that describe purpose, parameters, and return values (Chapter 6)
• Inline comments explain non-obvious logic (but don't narrate obvious code)
• The project structure is clear and follows the suggested module organization

Meets Expectations (3-4 points)

• A README exists with basic instructions (how to run the project)
• Most classes and important functions have docstrings
• Some inline comments present
• Project structure is reasonable

Approaching (2 points)

• A README exists but is minimal (just the project title)
• Some docstrings present but incomplete
• Few or no inline comments
• Project structure is not clearly organized

Needs Improvement (0-1 points)

• No README
• No docstrings
• No inline comments
• Project structure is unclear (everything in one directory, unclear file names)

Grade Calculation

Sum the scores across all six criteria:

Submission Checklist

Before submitting, verify each item:

• [ ] All source code files are included and organized into modules
• [ ] The application runs without errors from a fresh start (no pre-existing data files required)
• [ ] All required features are implemented (review the project spec)
• [ ] The full test suite runs with pytest and all tests pass
• [ ] A README file exists with installation and usage instructions
• [ ] No sensitive data, API keys, or personal information is included in the submission
• [ ] No unnecessary files (.pyc, __pycache__, IDE configuration files) are included
• [ ] You've had at least one other person try to use your application and incorporated their feedback

A Note on Academic Integrity

You built TaskFlow across 27 chapters. You debugged Elena's pipeline, explored the Crypts of Pythonia, and analyzed Dr. Patel's DNA sequences. The capstone is your chance to prove that you can do this independently.

Using AI coding assistants, copying from online sources, or submitting another student's work defeats the purpose. The capstone isn't just an assignment — it's evidence that you can build software. If you submit work you don't understand, you'll know. And the first technical interview will reveal it.

That said, these resources are fair game:

• This textbook — every chapter, every example, every exercise
• Python's official documentation — docs.python.org is a professional resource, not a cheat sheet
• Your own previous code — including TaskFlow and chapter exercises
• Stack Overflow and similar sites — for specific syntax questions ("how do I format a date in Python"), not for architectural solutions to the capstone itself
• Classmates — discussing approaches, debugging together, and reviewing each other's code is encouraged. Submitting identical code is not.

The line is simple: if you can explain every line of your submission and could rewrite any function from memory, it's your work.

Final Thought

The rubric quantifies your work, but it doesn't capture everything. The most important outcome of the capstone isn't the grade — it's the experience of building a complete application from an empty directory to a working product. You've designed an architecture, made trade-offs, fixed bugs at midnight, and shipped something that works. That's what it means to be a programmer.

Every professional developer remembers their first real project. This is yours.