Research Hub

TESTING AND QA STRATEGY (RORY) Topic: Midterm deck Our testing strategy focuses on data accuracy, usability, and reliability. After each CSV import, we compare a sample of dashboard records with the original file to confirm that the measurements, dates, units, locations, and quality-control flags match. We also test blank measurements, duplicate rows, invalid coordinates, and flagged values. The dashboard should identify these problems without crashing, hiding valid information, or displaying misleading results. The main dashboard features are tested manually, including location selection, date filters, charts, tables, login access, and data-quality indicators. We also review the dashboard at phone, tablet, and desktop widths to make sure charts resize correctly, text remains readable, controls are usable, and nothing extends off the screen. Before each demonstration, another team member reviews the completed work using a shared checklist. Any problems are recorded, corrected, and tested again before the feature is considered complete. ALGORITHMIC DESIGN - INGESTION SCRIPT (RORY) Topic: Midterm deck The ingestion script first confirms that the CSV file contains the required columns. It then reads each row, converts dates and measurements into consistent formats, and connects the data to the correct plot or tower location. Duplicate location-and-date records are removed, while measurement columns are converted into standardized database readings. Blank measurements are skipped, invalid coordinates are flagged, and the import results are recorded. Clean data is uploaded to Supabase in batches so one bad row does not stop the entire file. For n CSV rows, the ingestion process takes O(n) time because each row is examined once. With an index on location and timestamp, a typical dashboard query takes O(log n + k) time. The index quickly finds the requested range, and k represents the number of readings returned.

Everyone on the visit reads this first. It covers what to bring, what to look for at each tower and plot, what to photograph, safety, and the questions to ask on site.

Everyone reads this before the Thursday, Oct 8, 2:30-3:00 PM connect with Prof. Ray and Dr. Kay. Dr. Kay asked us to come prepared to share what we understand so far and our next steps. This entry has all three.

Dr. Kay answered our plot-label question. Towers do not map one-to-one to plots, so each tower is linked to the agroecosystem around it. Use this table for chart labels and treat it as context until PVAMU confirms it.

Your current FluxView build works, but it shows sample numbers. This guide walks you through swapping in the real Shell data, what to fix, the prompt to use, and exactly where to upload your result in ProjectPulse.

Follow these steps for your tasks this week. You should not need to ask anyone how to start. Each task on the Tasks board has the same name as its step here.

This is our #1 priority now: the dashboard Shell told us to build first. Before we hand anything to an AI coding tool, here's what FluxView v1 actually is, why it's built in this order, and the exact prompts to paste in for each piece - so we understand what we're shipping, not just what the AI wrote.

Follow-up call after the Sep 21 kickoff. The real dataset has now arrived (8 towers, 30-min + daily files, May 2023 through Sep 2026) and Shell confirmed exactly what to build first and how they want forecasting validated later.

Plain-language definition of every column in the 8 tower CSVs Shell sent us, pulled from Shell's own student data guide (full file is in Resources). Read this before writing any ingestion or chart code - it tells you what each field means, its unit, and what it's actually good for.

10% of grade, only the team leader (Raylen) submits, due Sep 23 11:59pm. Full text below — the real file is Week3_Progress_Report.docx, which Raylen has and submits as a PDF. A NOTE ON WEEKS 1-2: Our team was originally placed on a different capstone project at the start of the semester and was reassigned to the Shell NET-PVAMU Data Visualization project partway through. Because we were not working on this project during Weeks 1-2, we have no progress to report for those weeks and this is our first entry in this running doc. Raylen also emailed Dr. Shuvo with this same context so it doesn't read as a missing submission.

Full text of our "Existing Work, Problem Identification, Gap Analysis, Requirements, and System Specification Report" (25% of grade, due Sep 23). This entry has all the WRITING — the 8 required diagrams (flowchart, context model, use-case, sequence, UML class, ER diagram, Gantt timeline, UI wireframe) only exist as images inside the actual Word file, which Raylen has and can share directly (ProjectPulse doesn't support file uploads, only text and links). Ask Raylen for FluxView_Report_DRAFT.docx if you need the real file with diagrams. ABSTRACT Environmental data collected at the Prairie View A&M University (PVAMU) research farm — including rainfall, humidity, soil moisture, and eddy-covariance flux tower measurements of greenhouse gas exchange — is currently gathered by scientists and by Shell's Nature and Environmental Technology (NET) program, but it is not easily accessible to the students, farm staff, and community members who could benefit from it. Anyone who wants to know what conditions looked like on the farm last week, rather than just today, currently has to request that data directly from the research team or log into a specialized platform not built for casual use. This project, developed as the Data Visualization workstream of the Shell NET–PVAMU capstone portfolio, addresses that gap by building a mobile-friendly dashboard (FluxView) that ingests timestamped environmental readings through a documented API, stores them with quality-assurance flags, and presents both real-time conditions and historical trends through simple charts, a farm map, and threshold-based alerts. 1. INTRODUCTION 1.1 Problem Statement Environmental data collected at the PVAMU research farm — rainfall, humidity, soil moisture, and eddy-covariance flux tower measurements of greenhouse gas exchange — is currently collected and stored by scientists and by Shell's Nature and Environmental Technology (NET) program, but it is not accessible to non-expert users in a simple, self-service way. Farmers, students, and the broader Prairie View community have no way to check current or historical environmental conditions for the farm the way they might check a weather app: anyone who wants that information today has to log into a specialized research platform or request it directly from the team. This creates a gap between the value of the data being collected and the number of people who can actually use it to understand what is happening on the farm over time. 1.2 Background or Related Work Several categories of existing systems are related to this project, and each falls short of what the Shell NET–PVAMU community needs: - General consumer weather apps (e.g., Apple Weather, Weather.com) provide current conditions and short-term forecasts, but almost never expose historical trend data beyond the past day or two, and have no concept of a specific research farm or of flux-tower-derived metrics such as net ecosystem exchange. - FLUXNET's public data portal is a legitimate existing system for sharing flux tower data across research sites worldwide, but it is oriented toward researchers downloading raw CSV files for offline analysis, not toward a mobile-friendly, at-a-glance dashboard for non-expert users. - Shell's own internal visualization tools (referenced by the sponsor team during our requirements call) let Shell scientists visualize their data, but these tools are not built for public, student, or community access, and are not integrated with the specific PVAMU farm dataset. - Manual, ad hoc logging — the current de facto approach described by the sponsor — requires anyone who wants historical context to separately request it or dig through internal systems, rather than simply opening an app. Taken together, the gap this project addresses is not a lack of data — PVAMU and Shell already collect rich environmental data through eight eddy-covariance flux towers (operating since May 2023) as part of Prof. Ram Ray's "Enhancing Soil Carbon Sequestration by Implementing Innovative Tools and Interventions under Different Ecosystems" project — but a lack of an accessible, historically-aware, mobile-friendly way to view it. [Team note: add 2-3 real citations here via Zotero before final submission — search "environmental monitoring dashboard," "precision agriculture data visualization," "eddy covariance data portal usability." We deliberately did not invent citations.] 1.3 Objectives - Define and implement a data schema and ingestion path that can accept Shell/PVAMU flux tower and weather data, with timestamps, units, and QA/QC flags. - Build a mobile-friendly web dashboard exposing current conditions, historical trend charts, and simple map context for the PVAMU farm site. - Add threshold-based alerting so out-of-range or anomalous conditions are surfaced automatically. - Provide simple CSV export so researchers and community users can pull data out for their own analysis. - Establish a documented API and common data schema so the Predictive Analytics workstream (Project 3 of the Shell NET portfolio) can plug forecast overlays into this dashboard later. 1.4 Our Approach Build a thin vertical slice end-to-end first — ingest one variable, store it, and chart it — rather than fully building each architectural layer in isolation. Validate the whole pipeline early using sample or historical data while the live Shell data-transfer process is finalized. Prioritize "must-have" dashboard views (current conditions and historical trend charts) ahead of polish features (maps, CSV export). Avoid overpromising on data completeness or accuracy — aim for a credible prototype, not a production-certified monitoring system.

PASTE THIS WHOLE BLOCK INTO YOUR AI SLIDE TOOL (Gamma, etc.) TO GENERATE THE ROUND 2 DECK: Create a 10-minute, 10-slide presentation titled "FluxView: Shell NET–PVAMU Data Visualization — Contribution & Requirement Analysis (Round 2)". Make this feel like a polished product pitch a well-funded startup or a company's innovation team would give investors or executives — NOT a plain academic bullet-point deck. The audience knows nothing about flux towers, agriculture, or environmental science going in. By the final slide they should feel genuinely excited about this project, not just informed that it exists. Audience: our senior design faculty coordinator (Dr. Md Hossain Shuvo) and our Shell industry sponsors (Dr. Kuloyo and Hemshikha), for a Computer Science capstone course. Tone: confident, energetic, non-expert-friendly. VISUAL AND PRODUCTION QUALITY REQUIREMENTS (critical — do not generate a plain bulleted-text deck): - Every slide needs a strong visual: a relevant photo or illustration, an icon set, a map, a diagram, or a chart. Never a slide of plain bullet text with nothing else. - Use consistent icons throughout (rain, thermometer, soil/leaf, trend-line, bell/alert, phone/mobile) instead of repeating words. - Color palette: clean, professional blue/green earth-and-data tones. - Include at least 2 illustrative example charts showing what the dashboard's real-time and historical trend views will look like once built. Label these clearly on the slide as "Illustrative concept — not real Shell data" in a visible caption, since we don't have real measurements plotted yet. Never present mockup numbers as if they are real results. - Include a simple map or diagram showing the PVAMU research farm with its flux towers feeding data into the dashboard. - On the problem slide, use a strong visual "before vs. after" or side-by-side contrast (e.g., a phone showing a normal weather app next to a "???" for farm history) so the gap is obvious at a glance, not just stated in words. - Close on a visually strong, memorable "vision" slide — not a plain "Thank You" text slide. Generate speaker notes under every slide that a nervous first-time presenter could read almost verbatim, matching the timing below, written in plain conversational English (not bullet fragments). Structure exactly as follows: SLIDE 1 — Title slide - Title: "FluxView: A Mobile-Friendly Dashboard for Real-Time and Historical Environmental Monitoring" - Subtitle: "Shell NET–PVAMU Data Visualization Team — Contribution & Requirement Analysis, Round 2" - Team: Raylen Williams (Team Lead), Rory Samuels, Alex Curtis - Course: COMP-4207 Senior Design, Prairie View A&M University - Visual: a strong hero image or illustration evoking farmland + data (e.g., a stylized farm landscape with a subtle data-overlay/grid effect) SLIDE 2 — Project Overview (this slide covers ~2 minutes of talk time) - Team name, leader, and members (restate briefly) - Project title - One-sentence problem statement for a non-expert audience: "PVAMU and Shell collect rich environmental data from 8 flux towers on the research farm — but right now, nobody outside the research team can easily see it, especially not historical trends, on a phone." - Project goal: build a mobile-friendly dashboard showing real-time and historical environmental conditions - Intended users: PVAMU researchers, students, farm staff, and the broader community - Visual: a simple map/diagram of the PVAMU research farm showing flux tower locations SLIDE 3 — The Problem, in Plain Terms - Visual metaphor, shown not just described: side-by-side contrast of "checking today's weather" (a normal, easy phone weather app screen) vs. "checking last week's soil moisture on the farm" (a big question mark / dead end) — make the gap visually obvious in one glance - 3 bullet gaps beneath it: (1) no accessible historical view, (2) flux tower / greenhouse gas data locked in research-only tools, (3) nothing mobile-first or purpose-built for this farm SLIDE 4 — Major Project Contribution (~2 minutes of talk time) - Headline: "We are not inventing new sensors or new science — we are making Shell and PVAMU's existing environmental data usable by non-experts for the first time." - 3 contribution bullets, each with its own icon: 1. Accessible historical trends (not just "today"), on mobile, for this specific farm 2. Threshold-based alerts so out-of-range conditions surface automatically instead of requiring someone to notice 3. A documented, common data API so the Predictive Analytics team (Project 3 in the Shell portfolio) can later plug in forecasts without this team's work blocking on that - Visual comparison table: "Existing tools" (consumer weather apps, FLUXNET portal, Shell's internal tools) vs. "What's missing" vs. "What we're building" — styled like a clean product-comparison table, not a plain grid SLIDE 5 — Requirement Analysis: Must-Have (~1 min of the 3-minute requirements section) - A. Must-have requirements, each with a small icon: - Ingest environmental readings via a documented API, tagged with QA/QC flags - Display current conditions on a dashboard home view - Display historical trend charts over a selectable date range - Fully mobile-responsive layout (this is the core value proposition) SLIDE 6 — Requirement Analysis: Should-Have and Future (~2 min of the 3-minute requirements section) - B. Should-have requirements: - CSV export of displayed data - Configurable alert thresholds with notifications - C. Future/scalable requirements: - Forecast/prediction overlays (integration point with Project 3) - Multi-site comparison as more towers/sensors come online - Automated anomaly detection beyond simple thresholds - Visual: a simple layered/roadmap graphic showing Must-Have -> Should-Have -> Future as building blocks SLIDE 7 — Updated Project Milestones (~1.5 minutes of talk time) - Completed: kickoff and sponsor requirements call (mid-September); existing-work review and gap analysis - Current: this requirements and system specification report + this presentation (due this week) - Remaining: wireframes and data schema design -> ingestion API + database prototype -> dashboard front-end (charts, maps) -> alerting logic + accessibility pass -> integration testing and usability review -> Semester 1 demo and progress report (target: December 2026) - Task assignment (draft — team to confirm): Raylen — architecture, ingestion API, Shell coordination; Rory — database design, data validation/QA logic; Alex — dashboard front-end and visualization - One honest note: team started roughly a week to a week and a half behind the ideal timeline while finalizing the Shell data-transfer process, which the sponsor explicitly said is a normal and acceptable delay - Visual: a horizontal timeline/roadmap graphic, not a text list SLIDE 8 — Expected Final Outcome (~1.5 minutes of talk time) - What the completed system will accomplish: any PVAMU/Shell stakeholder can open the dashboard on a phone or desktop and see current conditions plus at least 12 months of historical trend data for the research farm within seconds, with automatic alerts for threshold exceedances - How success will be demonstrated: a live or recorded demo showing real (or representative) data flowing end-to-end from ingestion into charts, meeting all must-have requirements - What counts as a successful outcome: a credible, working prototype — not production-certified software — that a non-technical user can operate without help, per the capstone program's own scope guidance - Visual: an illustrative mockup of the finished dashboard on a phone screen (current conditions + a trend chart + an alert banner), clearly captioned "Illustrative concept — not real Shell data" SLIDE 9 — References - List: PVAMU-Shell Capstone Project Description (sponsor brief); FLUXNET public data portal; NIST Cybersecurity Framework; NIST AI Risk Management Framework - Note: full citations also included in the team's written report SLIDE 10 — Vision / Thank You / Q&A - Not a plain text slide: a strong closing visual (e.g., the illustrative dashboard mockup again, or a "from data to decisions" graphic) paired with a short, energetic closing line and "Questions?" - Team contact: Raylen Williams (team lead)

What our kickoff calls with Shell (Dr. Kuloyo + Hemshikha) are for, and questions each of us can bring so we're not walking in blind.

The simple, no-jargon explanation of this project - for Rory, Alex, or anyone new joining the team so nobody walks into a Shell meeting blind.

From Dr. Shuvo's COMP 4207 (Senior Design Project I, Fall 2026) lecture 1 slides - the actual grading breakdown and process for this class. Also confirms our Shell mentor's name: Dr. Kuloyo.

Core variables and measurement concepts explained by the Shell mentor on our call - needed to build the dashboard's variable set and the plot-comparison feature correctly.

PVAMU Senior Design capstone sponsored by Shell's Nature and Environmental Technology (NET) team. Our team is on the Data Visualization track. The sponsor wants visualization built first (fast to demo), with predictive forecasting layered on later using the same data - not two separate efforts.