Year by year, the use of technology is coming into all aspects of our lives, whether we like it or not, we are transitioning into a digital age. With the largely available information on social medias, we are often times, bombared with content from various different social media platforms.
An important aspect of university is to have a well-balanced routine, allowing for you to work hard and play hard. As it is hard to keep up with who, what and where things are happening, it would be useful for a platform that notifies you of upcoming social events at university.
TicketTailor is a social media application, event organiser and notifier that allows you to do just that. You can connect with other members of participating clubs while being notified of future events planned. The application also acts as an social media platform, allowing you to follow clubs and societies to keep in touch with their events. Other features may include sharing posts, instant messaging and/or collecting payments for ticketed events.
Name: Jia-Jie (Jackie) Dinh Chang
Student number: 47498312
The complete system will provide the following features:
The Minimum Viable Product (MVP), of this system will include the following features:
After extensive consideration, I have concluded that the following three attributes were chosen as the most crucial to the project.
The software application should be always accessable by users at any time and on any platform. Any changes to the data should be syncronised and accessible via different platforms such as mobile and computer. The system should be implemented to provide fault tolerance such that after any sort of failure, it should immediately spin up another service or switch to an available service such that the downtime is minimal.
This refers to the architecture of the system that encourages for extra features to be added. It is less about users being able to provide extensions but allowing developers to add additional features without major refactoring of the system. This allows for a quicker and easier prototyping and deployment of features. The components should be independent of each other, with minimal coupling
The system is deemed reliable if the database is replicated more than once, data is sync between tables and users will be able to access the most up-to-date data. If the database was to go corrupt, a backup should be ensured either through replicas or instance snapshots. To evaluate the reliability of this system, consistency will be ensured and evaluated by metric provided by error rates and corect behaviour in stress test.
Availability: For the MVP, we are only concerned with the system being accessible by the broser. Users should be able to view the application through it at all times. The system will be provided with basic tests that should be created to monitor and ensure that system performs uner different environments under different amounts of load and stress.
Extensibility: The extensibility attribute of the overall system should be evaluated based on how well defined the inrefaces are. The architecture of the system should be a basic as possible where the features included in the scope utilise these interfaces. As mentioned previously, components should be independent of each other and implemented in isolation.
Reliability: The system is considered reliable if the database is replicated more than once as data will be synced between the replicas where users are enabled to view the most up-to-date data. If the database was to fail or be corrupted, there should be a backup. As mentioned previous, these will be through replicas or instance snapshots. However, if the data is to go out of sync, there should be a way to determine which database is the most accurate.