Overview

The Carnegie Mellon University Housing Check-In System was developed to digitize the housing check-in process for over 1,000 students annually. The project addressed inefficiencies in the paper-based workflow, reducing processing time by 50% and significantly improving user satisfaction. The system was designed, developed, and deployed with validation and oversight from the Director of Student Affairs at CMU.

Project Highlights

• Impact: Reduced processing time by 50%, saving 300+ staff hours annually.

• Tech Stack: Node.js, SQL Server, Bootstrap, custom CSS.

• Accessibility: WCAG 2.1 compliance and mobile optimization.

• Security: TLS encryption, token-based authentication, and role-based access controls.

Problem Statement

The housing check-in process previously relied on paper forms, resulting in:

1. Long Wait Times: Students often queued for hours.

2. Frequent Errors: Manual data entry caused inconsistencies in records.

3. Lack of Real-Time Updates: Staff could not monitor or manage check-ins effectively.

The digitization effort aimed to address these issues, improving the overall experience for students and staff.

Solution Overview

The solution was a responsive, web-based application integrated with CMU’s student database. Key features included:

1. Real-Time Updates: Enabled instantaneous data synchronization across departments.

2. Batch Processing: Allowed staff to perform bulk updates, saving significant time.

3. Responsive Interface: Optimized for desktop and mobile platforms using Bootstrap and custom CSS.

Table of contents

System Architecture

The CMU Housing Check-In System was designed with a robust architecture to ensure efficiency, scalability, and security. Each component of the system played a critical role in streamlining the housing check-in process.

Backend

The backend was developed using Node.js, chosen for its ability to handle asynchronous operations efficiently, which was critical for managing real-time interactions and high volumes of concurrent requests.

• Core Functionality:
  • Handled API requests and responses to support real-time updates.
  • Managed communication with the SQL Server database for data retrieval, insertion, and updates.

• Database Integration:
  • Connected directly to the CMU student database, which was built on Microsoft SQL Server.
  • Used optimized SQL queries to ensure rapid data transactions, reducing latency for user operations.
  • Implemented data integrity checks to prevent errors during batch operations.

• Security Measures:
  • Enforced strict authentication and role-based access controls to ensure only authorized personnel could access or modify data.
  • All sensitive data, including login credentials, was encrypted in transit using TLS.

Frontend

The frontend was built using the Bootstrap Framework, with custom CSS to align the design with CMU’s institutional branding and ensure an intuitive user experience.

• Responsive Design:
  • Provided seamless functionality across devices, including desktops, tablets, and mobile phones.
  • Enabled staff to use the system from various locations during housing check-in events.

• Custom Features:
  • Designed a dynamic dashboard for staff to view and update student statuses in real-time.
  • Included user-friendly forms with validation for bulk operations, such as batch check-ins and housing assignment changes.

• Accessibility Enhancements:
  • Adhered to WCAG 2.1 standards, ensuring the platform was accessible to all users, including those with disabilities.
  • Used clear visual cues and error messages to guide users through the check-in process.

Deployment

The application was deployed on CMU’s private network to maintain a high level of security and compliance with university IT policies.

• Infrastructure:
  • Hosted on on-premises servers managed by CMU’s IT department.
  • Configured to integrate seamlessly with existing university systems, including authentication and student records.

• Deployment Process:
  • Used a CI/CD pipeline for efficient testing and deployment, minimizing downtime.
  • Staging and production environments were set up to thoroughly test changes before live deployment.

• Data Security:
  • All API endpoints were secured using token-based authentication.
  • Regular vulnerability assessments were conducted to identify and mitigate potential risks.
  • Backups of the SQL Server database were scheduled daily to prevent data loss.

• Monitoring and Logging:
  • Deployed monitoring tools to track server uptime, API performance, and database health.
  • Logs were stored securely and reviewed periodically for any irregularities.

API Documentation

Endpoints

1. GET /students

Fetches a list of all students along with their current check-in statuses.

• Parameters: None

• Headers:
  • Authorization: Bearer token (required)

• Sample Response:

  [
    {
      "student_id": "12345",
      "name": "John Doe",
      "status": "Checked-In"
    },
    {
      "student_id": "67890",
      "name": "Jane Smith",
      "status": "Not Checked-In"
    }
  ]

• Use Case: Enables staff to monitor the status of all students in real time.

2. POST /checkin

Updates the check-in status of a specific student.

• Parameters (Body):

  {
    "student_id": "12345",
    "status": "Checked-In"
  }

• Headers:
  • Authorization: Bearer token (required)
  • Content-Type: application/json

• Sample Response:

  {
    "message": "Student check-in updated successfully."
  }

• Use Case: Allows staff to update the check-in status of individual students during peak check-in times.

3. PUT /assignments

Modifies housing assignments for a specific student.

• Parameters (Body):

  {
    "student_id": "12345",
    "assignment": "Dorm 3, Room 202"
  }

• Headers:
  • Authorization: Bearer token (required)
  • Content-Type: application/json

• Sample Response:

  {
    "message": "Housing assignment updated successfully."
  }

• Use Case: Provides flexibility to reassign housing accommodations dynamically.

4. POST /batchcheckin

Processes check-ins for multiple students in bulk.

• Parameters (Body):

  {
    "students": [
      { "student_id": "12345", "status": "Checked-In" },
      { "student_id": "67890", "status": "Checked-In" }
    ]
  }

• Headers:
  • Authorization: Bearer token (required)
  • Content-Type: application/json

• Sample Response:

  {
    "message": "Batch check-in completed successfully."
  }

• Use Case: Reduces processing time during peak hours by enabling staff to update multiple records simultaneously.

Authentication

All API endpoints require token-based authentication. Tokens must be included in the Authorization header as a Bearer token.

• Login Process:Use the /login endpoint to obtain a token. The token is valid for 24 hours.

Error Responses

Each API returns standardized error messages. Here are common scenarios:

• 401 Unauthorized:

  {
    "error": "Unauthorized access. Please provide a valid token."
  }

  Reason: Token is missing or invalid.

• 400 Bad Request:

  {
    "error": "Invalid input. Please check the request parameters."
  }

  Reason: Request body or parameters do not meet validation rules.

• 500 Internal Server Error:

  {
    "error": "An unexpected error occurred. Please try again later."
  }

  Reason: Server-side issues.

User Documentation

Staff Dashboard

The dashboard is the primary interface for staff to manage the check-in process.

• Login:
  • Navigate to the secure portal at [internal URL].
  • Use CMU credentials for authentication.
  • Multi-factor authentication (MFA) is enabled for added security.

• View Check-In Status:
  • The main dashboard displays all students with their current check-in statuses.
  • Use the search bar to filter by student name or ID.
  • Real-time updates ensure that the dashboard reflects the latest status.

• Batch Processing:
  • Upload a CSV file containing student IDs and statuses to perform bulk updates.
  • The system validates the file format and highlights any errors for correction before processing.

Troubleshooting

Common issues and their resolutions:

• Issue: Students are missing from the dashboard.
  • Cause: The student database sync may have failed.
  • Resolution: Verify the scheduled database sync logs and run the sync script manually if necessary.

• Issue: Unable to update a student’s check-in status.
  • Cause: API connection or database errors.
  • Resolution: Check API health using the /health endpoint. Review server logs for error details.

• Issue: Housing assignment changes are not saving.
  • Cause: Input validation errors.
  • Resolution: Ensure the room number follows the correct format (e.g., Dorm X, Room XXX).

Maintenance Guide

Database Integration

• Scheduled Syncs:
  • A cron job runs daily at midnight to sync the student database with the system.
  • The sync script is located at /scripts/db_sync.sh and can be triggered manually.

• Error Handling:
  • Sync errors are logged in /logs/db_sync_errors.log.
  • Use the -dry-run flag during testing to avoid overwriting live data.

Logging

• API Logs:
  • All API interactions are logged in /logs/api_access.log for auditing purposes.
  • Errors are logged in /logs/api_errors.log with timestamps and request details.

• System Logs:
  • General system activity is logged in /logs/system.log.
  • Logs are rotated weekly to manage disk space.

Version Control

• Semantic Versioning:
  • The system follows semantic versioning (e.g., 1.2.3 where 1 is the major version, 2 is minor, and 3 is a patch).
  • Each release is tagged in the Git repository for easy rollback if necessary.

• Deployment:
  • Deployment is managed via a CI/CD pipeline using GitHub Actions.
  • Deployment scripts are located in /deployment/ and include staging and production configurations.

Routine Maintenance Tasks

• Database Backup:
  • Weekly backups are scheduled every Sunday at 3 AM.
  • Backup files are stored in /backups/db/ with a 30-day retention policy.

• API Health Checks:
  • A /health endpoint is available to monitor API status. Schedule a cron job to ping this endpoint every 10 minutes.
  • Example health check response:

    {
      "status": "healthy",
      "uptime": "102 days",
      "last_checked": "2024-11-28T10:00:00Z"
    }

• System Updates:
  • Review system dependencies monthly and apply patches or updates as needed.
  • Use the script /scripts/update_dependencies.sh to check for outdated packages.

Future Enhancements

• Real-Time Notifications:
  • Implement push notifications for staff to receive updates on system errors or sync failures.

• Mobile App Development:
  • A mobile app for the system could further enhance accessibility for staff during check-in events.

Lessons Learned

• Process Improvement: Streamlined workflows saved significant staff time.

• Stakeholder Collaboration: Regular feedback from staff and oversight by the Director of Student Affairs ensured a user-centric solution.

Impact

• Efficiency Gains: Estimated 300+ staff hours saved annually.

• Error Reduction: Manual data entry errors reduced by 40%.

• User Satisfaction: Positive feedback indicated high adoption and ease of use.

Conclusion

The CMU Housing Check-In System is a testament to the power of thoughtful design and collaborative problem-solving. Its successful deployment has set a benchmark for streamlined administrative processes.