Technical depth / education

DCU web platform (Agile delivery lead)

I led a seven-person DCU build for a oneM2M IoT dashboard: backlog, sprints, code reviews, release checks, and a working Node/Express platform that turned live sensor containers into Highcharts views.

Employer / client: Dublin City University
Duration: 2024
Project type: IoT web platform delivery

GitHub dcu-onem2m-iot-dashboard

Architecture and delivery maps

How the platform worked and shipped

Runtime architecture: browser dashboard calls a frontend Express server and backend Express API. The API requests application entities, containers, content-instance history, and latest readings from the oneM2M CSE, then the browser renders Highcharts time-series views. — How the browser dashboard, frontend server, backend API, oneM2M CSE, and Highcharts view fit together at runtime.
Runtime architecture from the supplied code

Agile delivery and release-gate flow: stakeholder brief becomes backlog stories, sprint build, review decision, install gate, smoke gate, release handoff, and AWS EC2 release, with review feedback looping back into the backlog. — How Agile delivery and release gates kept the seven-person build moving under deadline pressure.
Agile and release-flow map

Delivery pipeline: a review-group brief becomes a backlog with testable acceptance criteria and named owners, moves through a sprint build and code review with seven contributors, then ships to AWS EC2 with in-product KPI tracking. Review feedback loops back into the backlog each sprint. — How the brief moved from backlog and acceptance criteria, through a seven-person sprint build, to a live EC2 release with usage tracked inside the product.
My delivery pipeline

Process flow

How I work the steps

01
before Brief to backlog
Review-group asks became small stories with acceptance checks.
Me / stakeholders
02
handoff Sprint build
Seven contributors split frontend, backend, charting, config, and deployment tasks.
Team
03
control Review gate
Route, config, and dashboard checks before a feature was treated as done.
Me / reviewers
04
risk Release path
Local install/start checks, handoff notes, then EC2 release.
Me / deployment owner
05
after Dashboard visibility
Sensor readings visible as Highcharts views for review.
Users / reviewers

How I built it

Led backlog shaping and sprint cadence for a seven-person DCU team, turning the review brief into small, testable build slices.
Mapped the oneM2M data path: application entities, containers, content instances, latest readings, and the dashboard views each route had to support.
Coordinated code review and release checks so frontend, backend, config, and deployment tasks didn't drift apart like shopping carts with bad wheels.
Framed the delivery pipeline for reviewers: requirements → backlog → sprint build → local checks → EC2 release → KPI/dashboard visibility.
Documented the trade-offs clearly: quick course deadline, shared build ownership, legacy Node dependencies, and config-driven CSE endpoints.

Measured results

What I measured

7 volume

Delivery team led

Seven contributors coordinated across frontend, backend, charting, config, review, and release work.

4 volume

Core API routes

Routes for all AEs, containers, content-instance history, and latest readings.

5 comparison

Runtime layers

Browser dashboard, frontend Express server, backend API, oneM2M CSE, and charting layer.

Findings

Led the seven-person build from review-group asks to a working dashboard with a frontend server, backend API, oneM2M CSE integration, and Highcharts time-series views.
Kept delivery moving through short Agile loops: backlog grooming, sprint reviews, code review, release checks, and visible ownership when the deadline got tight.
Used release-gate discipline: install dependencies, run local start checks, verify routes and config, then promote the build toward the AWS EC2 deployment.
Made the architecture explainable for non-engineers: browser dashboard, Node/Express frontend, Node/Express API, oneM2M CSE, and KPI-style charts in one line of sight.