Final Deliverable

In a traditional laboratory course, the final deliverable is often a term paper that the instructor reads once and then files away forever. In BIOSC 1640, your goal is not just to finish the assignment, but to create an artifact: a computational tool or pipeline that is robust, documented, and usable enough that a future student or researcher could pick it up and continue your work without needing to email you for help.

This “Release Package” replaces the traditional final research paper. It represents the culmination of your semester’s work, shifting the focus from simply getting a result to building a maintainable product. In professional software engineering and high-impact computational biology, code that works only on your laptop is indistinguishable from code that doesn’t work at all. Therefore, your final grade depends heavily on the reproducibility and usability of your software.

We grade this deliverable against the Operational Continuity principle. If your entire team were suddenly unavailable to continue the work, could a new researcher download your repository and reproduce your science solely by reading your documentation? If the answer is no, the project is not release-ready.

Component 1: The Codebase

We expect production-grade code, not “scripting scratchpads.” By the end of the semester, your repository should be scrubbed of dead code, commented-out blocks, and untitled “test” files (e.g., analysis_FINAL_v2_REAL.py).

Your repository must follow a logical directory structure (e.g., /src for source code, /data for inputs, /docs for images). Files should be named descriptively. Code should be modular. Giant, monolithic scripts are unacceptable; logic should be broken into functions or classes imported from modules. Code must be commented for context, not just syntax. Don’t tell us what a line does (e.g., x = x + 1 # adds 1 to x); tell us why it exists (e.g., # Increment counter to skip the header row). Variable names should be meaningful.

Component 2: The Documentation

In this course, your README.md is your final paper. It serves the dual purpose of a user manual and a scientific manuscript. It must be written in professional, scientific English and formatted with Markdown headers, bold text, and code blocks for readability. It must include:

  • Scientific Introduction. This replaces the “Introduction” of a paper. Provide the biological and computational context. What is the target? Why does it matter? What was the specific gap in knowledge or tooling you aimed to fill? A reader with no prior knowledge of your specific target should understand why this tool exists.
  • Installation & Usage. This is the most critical technical section. You must provide exact, step-by-step commands to set up the environment. Provide a “Quick Start” example: a single command to run your tool on a provided test dataset. If the instructor follows these steps literally and an error occurs, points will be deducted significantly.
  • Methodology & Algorithms. This replaces the “Methods” section. Detail how. Did you use AutoDock Vina or Smina? What specific parameters did you change? What architecture did your Neural Network use? How did you filter the data? You must cite the external libraries and tools you used. Transparency is key to scientific integrity.

Component 3: Reproducibility

The ultimate test of a computational scientist is reproducibility. We will not grade your project based on screenshots or claims in a report. We will clone your repository to a fresh machine and run it.

  • Your repo must include a small demo dataset and a command to run the full pipeline.
  • The pipeline must run without crashing and produce the expected outputs.
  • If your code fails because you forgot to list a library, it is considered broken.

You will submit this by creating a GitHub Release tag using calendar versioning (e.g., v26.4.18). This “freezes” the code at that moment in time, simulating the versioning process used in industry and academia.

Last updated on