At the start of every semester, students are confronted with a major problem: the scheduling of their timetable. They have to try and juggle their own responsibilities with their friends’ availabilities. The more friends they have, the harder their job becomes. Timetablr simplifies this with a one stop solution. Whether you’re out of the country, on your phone, or even without no internet, you can coordinate your time with your friends’.
Name: Zhengde Fang
Student number: 47450383
The core of the software is a timetable. Basic functionality would allow the user to schedule, modify and remove events across a typical 7-day week. This would be achievable both using manual input and through imports from existing software, such as Microsoft Outlook, as well as online calendars. The software’s timetable would continue to automatically sync with these external systems.
The user would then be able to connect to other users through a friend system, similar to current social media implementations like Instagram. Accounts are manually created, but existing account systems like Google would be integrated to further simplify and familiarize the process for the end user. Users would be able to see the timetables of friends, with options to distinguish friends through specific groups designated by the user, or even on an individual basis.
It would also be possible to send invitations/requests to friends and friend groups for meetings, based on availabilities within the shared schedule. Given the invitation functionality, a notification system would also be implemented, notifying the user with options to control the frequency, type of notifications etc.
The software would be accessible from both PC and mobile devices and synced between devices, enhancing accessibility for the end user. While the software does require a network connectivity for cross-platform and sharing functionality, it will also be available without an internet connection using locally stored data.
The minimum viable product would consist of only basic timetabling and sharing functionality. Key functionality would be the ability to add, remove and edit events across the day, and the timetable syncing to correctly to a global internet calendar.
Sharing functionality would be limited to a single general pool, with all users having the ability to see all other users’ timetables. Syncing of amendments to timetables between users would occur based on user input, and not automatically. The use of a general pool also necessitates the use of a backend database, where all user data is stored, edited and removed.
Development would be for a web-based application catered to PC access.
The key quality attributes for Timetablr are Scalability and Availability.
Interoperability is important for the system. Both the social media aspect and the notification system are independent of the timetable and its sharing functionality but are dependent on information derived from the timetable. Thus, regardless of whether the final software is distributed or not, there will be significant communication between different parts of the system. Furthermore, integrations with external accounts (Google) and external timetables (Outlook) will require a clear and simple API from the system to the outside world.
Scalability is key for the software. Users share schedules with each other, necessitating data transfer either between users or to a database. Ongoing use throughout most of the year would is consistent, with users checking shared schedules and updating their own. However, usage would spike at certain times in the year, such as the start of school and university semesters. Minimising resource consumption during low usage periods throughout the majority of the year before scaling to meet required demand at peak times would net significant efficiency benefits for the system. Effective scalability can be measured simply by monitoring usage statistics throughout low and high usage times of the product.
Another key attribute is availability. A wide variety of users from different time zones means that the software will be accessed throughout the entire day. Furthermore, users need to timetable, regardless of time or place. Therefore, to meet required demand, the software must be available all the time, and available from and through a wide range of devices and mediums. Users will also continue to timetable regardless of network connectivity, meaning that the software must be operable internet-free to accommodate user requirements.
Availability is the most important of the given attributes. System functionality will remain effective, even if scalability and interoperability are sacrificed. However, the expected user demand for timetabling software at all times necessitates that the product is highly available. Other attributes were also considered, but deemed to be less significant, or assumed to be foundational to the architecture. For example, secure storage of user data is a core aspect of most modern systems, regardless of their specific functionality.
Unit testing will be used to find and remove bugs as part of internal testing by the development team. More advanced testing will also be conducted by an independent quality assurance team with no system knowledge.
This will follow standard QA protocols, with testers conducting two different types of tests. Firstly, they will freely explore the prototype, conducting their own random testing. Following this, they follow a set list of instructions testing all features of the MVP including creating, modifying and deleting meetings, as well as syncing their timetables between users. Feedback will be gathered from these testers to find bugs and errors and but also potential points of improvement in the user experience. During these tests, hardware performance metrics, such as CPU and storage usage, will also be monitored for unexpected behaviour. These beta tests would also help test scalability and availability. Beta testing would inform developers of peaks, troughs and steady state use times, allowing them to prepare by allocating additional resources beforehand, or informing the use of scalable software that can handle the estimated load. During these tests, scalability is easily measurable by comparing usage metrics to resource consumption. Beta testing would also simulate actual user access times, checking system availability for the average user.
Scalability will be further tested through a different approach. Assuming that the software will use a cloud computing service, like AWS or Azure, limit testing is available to developers. The software will be tested with a large number of simulated users using cloud computing tools. User counts would be derived from predicted peak numbers given by previously mentioned beta tests. Statistics such as the uptime to downtime ratio would be monitored throughout testing to confirm uptime and stability even at peak usage. This simulation would cover all functionality provided by the MVP, to more accurately replicate actual user behaviour.
Availability can similarly be developer tested. Usage will be consistently simulated for 24 hours a day, 7 days a week, to check availability through the day and week, beyond expected user behaviour. Access would also be simulated from a variety of different locations, to confirm access times and application responsiveness are within desired parameters.
Interoperability is harder to measure and test, with a lack of quantitative data. However, it can be empirically evaluated by developers through methods like paired programming. Further testing would involve monitoring response times between internal and external components, using programming language and cloud computing tools respectively.