Course Project
The course project is the central activity of CMSE 802.
Throughout the semester, you will apply the ideas, tools, and software engineering practices discussed in class to a project that is relevant to your own interests, research area, or professional goals. The project is intended to be flexible enough to support a wide range of topics while still providing a shared structure for learning and evaluation. Here are the project Milestones:
Milestone Timeline
- Sun 09/13 - Milestone 1: Project Proposal and Initial Git Repository
- Sun 09/27 - Milestone 2: Initial Prototype and Working Workflow
- Sun 10/11 - Milestone 3: Testing and Validation Baseline
- Sun 10/25 - Milestone 4: Documentation and Reproducibility Pass
- Sun 11/08 - Milestone 5: Project Systems and Automation
- Sun 11/22 - Milestone 5: Release Candidate and Handoff Package
- Sun 12/06 - Milestone 6: Final Project Submission and Presentation Materials
The goal is not simply to produce software that works. The goal is to produce software that another person can understand, use, evaluate, and extend.
Project Philosophy
Research software comes in many forms.
Some projects may focus on:
- analytical models
- simulations
- machine learning
- data analysis
- visualization
- scientific computing
- educational tools
Some students may begin with an existing repository. Others may start with a completely new project.
Both approaches are acceptable.
What matters is that you demonstrate meaningful progress throughout the semester and apply software engineering practices that improve the quality, usability, and sustainability of your work.
Scientific Software Engineering
Throughout the course we will revisit five core principles:
- Safe
- Portable
- Reproducible
- Robust
- Literate
Your project should gradually incorporate these ideas as the semester progresses.
For example:
- Can another person run your software?
- Can they reproduce your results?
- Can they understand how the project works?
- Can they verify that the software behaves correctly?
- Can the project continue after you are finished with it?
These questions are often just as important as the scientific results themselves.
Software Engineering Tools
One goal of the course is to provide hands-on experience with tools commonly used in software development and computational research.
Examples include:
- Git and GitHub
- environments
- linting and formatting tools
- testing frameworks
- documentation systems
- automation tools
As new tools are introduced in class, you will be expected to explore and apply them within your project when appropriate.
The purpose is not to use tools simply because they exist. The purpose is to learn how software tools can improve the quality, maintainability, and reliability of a project.
Flexibility and Alternative Workflows
Many course examples will use Python and the software tools included in the course repository template.
However, not every project will use the same technologies.
For example:
- Some projects may use R instead of Python.
- Some projects may build on existing software.
- Some projects may use domain-specific frameworks or tools.
Alternative approaches are welcome.
If you choose to use different tools, you are responsible for documenting those choices and explaining how another person can evaluate your project.
For example, if the course introduces a Python linting tool and your project uses R, you should identify a comparable R tool and provide instructions describing:
- how it is installed
- how it is run
- what output should be expected
In general, flexibility is encouraged, but clarity and documentation are required.
Repository Expectations
Every project should be managed using a version-controlled repository.
Your repository should evolve throughout the semester and serve as the primary record of your work.
Submission Model
Each milestone is submitted by updating your project repository and making the current state of your work visible there. You should commit your changes in a way that reflects the progress of that milestone and leave the repository in a reviewable state.
Instructors will review your work by pulling the latest repository changes and examining the project in its current form. This means that milestones are not submitted as separate email attachments or standalone files outside the repository.
Your project should also be prepared with the eventual final manuscript in mind. Early milestones should help build the content, evidence, and structure that will later support a JOSS-style paper. Students should consult the JOSS paper guidelines at https://joss.readthedocs.io/en/latest/paper.html as they develop their project and manuscript.