SDSM:Index: Difference between revisions
(Add RETURN links to each section to go back to the TOC.) |
(Write first version of Introduction: System Overview section.) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 20: | Line 20: | ||
== Introduction == | == Introduction == | ||
'' | === System Overview === | ||
'''School Data System (SDS)''' is an electronic records management system | |||
that empowers a school's fundamental operations by managing the school's | |||
records of its students and related data and business processes. | |||
This includes tracking students' identities, enrolment, classes, and marks. | |||
'''SDS''' is used directly by students, their parents, their teachers, and | |||
other staff of a school having various roles. | |||
'''SDS''' is meant in principle to be usable by any school, but first | |||
and foremost to meet the specific needs of | |||
'''St. Michaels University School (SMUS)'''. | |||
'''SMUS''' is the only school actually using it as of | |||
2024, but '''SDS''' may be made available to other schools later. | |||
Historically, '''SDS''' was also used by '''Brentwood College School'''. | |||
'''SDS''' has a client-server architecture, hosted on a network as a web | |||
server, and used by way of a web client. '''SDS''' should be compatible | |||
with all modern web clients, including Mozilla FireFox, Google Chrome, | |||
Microsoft Edge, and Apple Safari; it should be usable with all modern | |||
client devices and operating systems. | |||
'''SMUS''' hosts all of its '''SDS''' instances, production and testing, | |||
on premises on network servers located at its Richmond Road campus. | |||
They are not hosted by a third party, whether "cloud" or otherwise. | |||
See https://sds.smus.ca for the production instance. | |||
'''SDS''' has 2 main versions in April of 2024, older and newer. | |||
The older '''SDS''' version (''SDS Gavintech''), is actively in use in | |||
production, and its development is mostly frozen, with minimal updates only. | |||
The newer '''SDS''' version (''SDS Laravel'' or ''SDS API''), is not currently | |||
used in production, and is incomplete; nearly all current development work | |||
is on this version, and it is intended to replace the older version in | |||
production once it is sufficiently complete. | |||
The newer '''SDS''' version is meant to have essentially the same | |||
outward-facing or user-visible feature set, behavior, and appearance as | |||
the older version. The newer version also uses essentially the same SQL | |||
database schema as the older version, and they actively share a database, | |||
which makes for a more seamless migration as the database doesn't have to | |||
be "converted". Within these constraints of looking the same to users and | |||
having the same database, the new version is almost completely different | |||
internally, with a new internal code structure that is a lot more modern. | |||
'' | Each '''SDS''' version is written in the '''PHP''' programming language | ||
and uses a '''MySQL''' database. The newer version uses the | |||
'''Laravel''' PHP application framework, while the older version uses | |||
the '''Gavintech''' PHP framework. Both versions' production instances | |||
are on servers running the '''Ubuntu''' operating system and are behind | |||
an '''Apache''' web server. While '''Gavintech''' is essentially | |||
abandoned, very non-modern, and bespoke, all of the other named | |||
dependencies are actively maintained, modern, and very popular. | |||
[[#top|RETURN]] | [[#top|RETURN]] | ||
Revision as of 16:06, 30 April 2024
This document consists of multiple parts; for a directory to all of the
parts, see SDSM:Index.
Name
SDS Modernization (SDSM) - Modernization of SMUS School Data System
Description
This document describes an active effort running through 2024 to modernize the School Data System (SDS) of St. Michaels University School (SMUS).
Introduction
System Overview
School Data System (SDS) is an electronic records management system that empowers a school's fundamental operations by managing the school's records of its students and related data and business processes. This includes tracking students' identities, enrolment, classes, and marks. SDS is used directly by students, their parents, their teachers, and other staff of a school having various roles.
SDS is meant in principle to be usable by any school, but first and foremost to meet the specific needs of St. Michaels University School (SMUS). SMUS is the only school actually using it as of 2024, but SDS may be made available to other schools later. Historically, SDS was also used by Brentwood College School.
SDS has a client-server architecture, hosted on a network as a web server, and used by way of a web client. SDS should be compatible with all modern web clients, including Mozilla FireFox, Google Chrome, Microsoft Edge, and Apple Safari; it should be usable with all modern client devices and operating systems.
SMUS hosts all of its SDS instances, production and testing, on premises on network servers located at its Richmond Road campus. They are not hosted by a third party, whether "cloud" or otherwise.
See https://sds.smus.ca for the production instance.
SDS has 2 main versions in April of 2024, older and newer.
The older SDS version (SDS Gavintech), is actively in use in production, and its development is mostly frozen, with minimal updates only.
The newer SDS version (SDS Laravel or SDS API), is not currently used in production, and is incomplete; nearly all current development work is on this version, and it is intended to replace the older version in production once it is sufficiently complete.
The newer SDS version is meant to have essentially the same outward-facing or user-visible feature set, behavior, and appearance as the older version. The newer version also uses essentially the same SQL database schema as the older version, and they actively share a database, which makes for a more seamless migration as the database doesn't have to be "converted". Within these constraints of looking the same to users and having the same database, the new version is almost completely different internally, with a new internal code structure that is a lot more modern.
Each SDS version is written in the PHP programming language and uses a MySQL database. The newer version uses the Laravel PHP application framework, while the older version uses the Gavintech PHP framework. Both versions' production instances are on servers running the Ubuntu operating system and are behind an Apache web server. While Gavintech is essentially abandoned, very non-modern, and bespoke, all of the other named dependencies are actively maintained, modern, and very popular.
Purpose and Scope
Clarify the intended use of the documentation and its intended audience.
TODO.
Audience of the Documentation
Specify who the documentation is written for (e.g., developers, system administrators, end-users).
TODO.
System Architecture
TODO.
High-Level Architecture
Overview of the system's architecture, including major components and how they interact.
TODO.
System Components and Interactions
Detailed description of each system component and its role.
TODO.
Network Diagrams
Visual representations of network and system architecture, if applicable.
TODO.
Environment Setup
TODO.
Hardware Requirements
Specifications for necessary hardware.
TODO.
Software Requirements
Required software and versions.
TODO.
Environment Configuration
Instructions for setting up development, testing, and production environments.
TODO.
Client Requirements
Required software and versions.
TODO.
Database Documentation
TODO.
Database Schema
Detailed diagrams and descriptions of database tables, fields, data types, and relations.
TODO.
Data Dictionary
Detailed definitions of all database elements.
TODO.
Entity-Relationship Diagrams
Visual representation of data entities and relationships.
TODO.
Database Performance Metrics
Information on database performance and optimization.
TODO.
Codebase Overview
TODO.
Languages and Frameworks
Information about programming languages and frameworks used.
TODO.
Repository Structure
Description of the code repository structure.
TODO.
Coding Standards and Conventions
Guidelines followed in the codebase.
TODO.
Repository Access
Instructions to access code repository.
TODO.
API Documentation
TODO.
List of Endpoints
Detailed list of API endpoints and their functions.
TODO.
Request/Response Formats
Specifications of request and response formats.
TODO.
Authentication and Authorization
Methods used for API security.
TODO.
User Interface Documentation
TODO.
Screenshots and Descriptions
Visuals and descriptions of key interfaces.
TODO.
User Flow Diagrams
Diagrams showing user navigation through the system.
TODO.
Security Protocols
TODO.
Data Security Measures
Techniques used for securing data.
TODO.
Network Security Configurations
Network security tools and configurations.
TODO.
Installation and Deployment
TODO.
Installation Guide
Step-by-step installation instructions.
TODO.
Deployment Procedures
Process for deploying updates or new releases.
TODO.
CI/CD Practices
Continuous integration and deployment methodologies used.
TODO.
Testing and Quality Assurance
TODO.
Testing Procedures
Overview of testing strategies and methodologies.
TODO.
Test Case Descriptions
Examples of key test cases.
TODO.
Automated Testing Frameworks
Description of automated testing setup.
TODO.
Performance and Optimization
TODO.
System Performance Benchmarks
Key performance indicators and benchmarks.
TODO.
Optimization Strategies
Techniques and practices for optimizing system performance.
TODO.
Backup and Recovery
TODO.
Backup Procedures and Schedules
How and when backups are conducted.
TODO.
Disaster Recovery Plan
Steps and procedures for system recovery in case of a disaster.
TODO.
Access Control
TODO.
User Roles and Permissions
Description of different user roles and their access levels.
TODO.
Access Management Procedures
How user access is managed and controlled.
TODO.
System Integration
TODO.
External System Integration
Details of integration with external systems or services.
TODO.
Data Exchange Protocols
Protocols used for data exchange with external systems.
TODO.
Localization and Internationalization (if applicable)
TODO.
Supported Languages
List of languages the system supports.
TODO.
Cultural Adaptations
Adjustments made for different cultural or regional needs.
TODO.
Scalability and Future Development
TODO.
Scalability Strategies
Plans and techniques for scaling the system.
TODO.
Expansion Plans and Roadmap
Future development plans and system evolution roadmap.
TODO.
Customization and Extensibility
TODO.
Customization Options
Options available for system customization.
TODO.
API Documentation for Extensibility
Documentation for APIs available for extending the system.
TODO.
Operational Best Practices
TODO.
System Maintenance Guidelines
Best practices for maintaining the system.
TODO.
Security Best Practices
Guidelines for maintaining security.
TODO.
Audit Trails and Logging
Information on system logging and audit trails.
TODO.
Feedback and Continuous Improvement
TODO.
Feedback Mechanisms
How users can provide feedback.
TODO.
Improvement Processes
How feedback is incorporated into system improvements.
TODO.
Appendices
TODO.
Glossary of Terms
Definitions of technical terms used.
TODO.
Authors
Primarily written by Darren Duncan.
Includes portions written by or derived from sources written by:
- Chetan Sondagar
License and Copyright
Copyright © 2024, St. Michaels University School.