Case study · MSU Mankato · Spring 2026

Disney SICO: Smart Itinerary & Capacity Orchestrator

A full systems analysis and design for a system that detects a ride disruption, finds every affected guest, rebooks them onto a suitable alternative, and tells them, with no manual staff work in the loop.

Course: CIS 380, Systems Analysis & Design
Role: Project lead and main contributor
Deliverables: DFDs, use cases, data dictionary, ERD, Access prototype, WBS, risk plan
Tools: Microsoft Access, diagramming tools

The problem

When a ride goes down at a Disney park, nothing connects the disruption to the guests it affects. Responses are manual, slow, and inconsistent.

No central system. Disruptions are handled by hand.
Guests left uninformed. There is no direct channel telling them what happened or what to do.
Lost reservations. Affected bookings cannot be moved or rescheduled automatically.
Staff overload. Manual intervention raises workload and response time.

The business impact runs from guest satisfaction and missed rebooking revenue to operational cost and, downstream of those, brand risk.

The solution

SICO automates disruption recovery end-to-end through five processes.

Disruption Detection. Receives real-time ride status, validates it, classifies the disruption, and logs it.
Guest Impact Analysis. Queries the reservation system for every affected guest, assesses severity, and produces an affected-guests list.
Alternative Evaluation. Checks attraction capacity, filters by availability then guest suitability, and ranks options by wait time.
Reservation Management. Cancels the original booking, assigns the top-ranked alternative, and updates the reservation system.
Guest Notification. Sends a personalized message by app with an email/SMS fallback, logs the response, and sends decision support to park operations.

Scope

In: real-time disruption detection, alternative evaluation, reservation reassignment, guest notification. Out: staffing and HR, ride maintenance, and ticket pricing systems.

System diagrams

I produced the full set of process models: a functional decomposition, a context diagram, a Level 0 data flow diagram, a Level 1 DFD for each of the five processes, and a use case model across four actors. Click any diagram to enlarge.

Design decisions in the flows

Validate before logging. Invalid ride status updates are discarded at step 1.2, and updates with no disruption skip the log entirely.
Availability first, then suitability. The alternative-evaluation step filters by capacity before guest constraints such as height restrictions, then ranks by shortest wait.
Notification fallback. If the app does not deliver, the message goes by email or SMS, and every response is logged.
No alternative available. The guest is notified and routed to guest services instead of being left with nothing.

Data design

Five entities support the system. Attraction Capacity is foundational, with no foreign keys, and everything else traces back to it. Each rebooking keeps the original and new reservation ids side by side, so any change traces to the disruption that caused it.

Entity	Primary key	Foreign keys	Fields
Attraction Capacity	`attraction_id`	none	7
Disruption Log	`disruption_id`	`attraction_id`	7
Reservation Data	`reservation_id`	`attraction_id`	10
Updated Bookings	`new_res_id`	`guest_id`, `original_res_id`, `new_attraction_id`, `disruption_id`	8
Notification Log	`notification_id`	`reservation_id`, `disruption_id`, `guest_id`	8

I built a working Microsoft Access prototype of all five tables with sample rides, disruptions, reservations, reassigned bookings, and notification responses (accepted, declined, or no response) to validate the relationships.

Project management

The plan spans five phases over 20 weeks.

Phase	Weeks	Focus
Requirements & design	1–3	Finalize requirements, integration points, diagrams
System development	4–11	Build the five processes, unit test each
Integration	12–15	Connect status feed, reservation system, mobile app
Testing	16–18	Component, integration, and peak-load testing
Deployment & training	19–20	Go live, train park operations, monitor

Top risks and responses

Risk	Likelihood	Impact	Response
Legacy system API integration	High	High	Extra dev time in the integration phase
Guest app notification fails	Medium	High	Email and SMS fallback
Inaccurate ride status feed	Medium	High	Validation discards bad updates (step 1.2)
Peak-hour performance	Medium	High	Scalable cloud infrastructure
Guest data breach	Low	High	Encryption and privacy compliance

How success would be measured

Park operations. Manual interventions per disruption, before versus after.
Guests. Time from disruption_timestamp to sent_timestamp.
Mobile app. Delivery and response rates from the Notification Log.

Systems Analysis Data Flow Diagrams ERD Microsoft Access Use Case Modeling Project Management

← All projects Get in touch →