MuSpace
Software Project Management Plan (SPMP)
1. Introduction
1.1 Project Overview
MuSpace is a music-based social media platform focused on connecting music fans with one another and allowing them to share their tastes with the world. Each MuSpace user will be provided with a personal feed to post about songs, albums, artists, and playlists that they are interested in. Users will be able to add friends on MuSpace and look at their detailed Spotify listening history. Users will also be able to view detailed statistics about their listening habits, such as listening time, favourite genres, favourite artists, and more.
1.2 Project Deliverables
| No. | Deliverable(s) | Group Deadline(s) | Marking Deadline |
|---|---|---|---|
| 1 | Software Requirement Specification (SRS) | May 25th, 2021 | May 28th, 2021 |
| Software Requirement Specification (SRS) Review | May 27th, 2021 | ||
| 2 | Software Project Management Plan (SPMP) | June 1st, 2021 | June 4th, 2021 |
| Software Project Management Plan (SPMP) Review | June 3rd, 2021 | ||
| 3 | Analysis | June 22nd, 2021 | June 25th, 2021 |
| Analysis SQA | June 24th, 2021 | ||
| 4 | Design | June 13th, 2021 | June 16th, 2021 |
| Design Review | June 15th, 2021 | ||
| 5 | Implementation | August 13th, 2021 | August 15th, 2021 |
| Implementation SQA | August 14th, 2021 | ||
| 6 | User Documentation | August 11th, 2021 | August 15th, 2021 |
| User Documentation Review | August 13th, 2021 | ||
| 7 | Final Publishing & Deployment | August 14th, 2021 | August 15th, 2021 |
1.3 Reference Materials
1.4 Evolution of the SPMP
As the team continues through the development process, updates will be made regularly to the SPMP to reflect any changes implemented. Version history will be handled using Google Docs’ editing history feature. At the end of each week, our team leader will review the SPMP to ensure that each team is on track and make any necessary changes.
The specific sections to be updated are:
- 1.2 Project Deliverables
- 1.3 Reference Materials
- 1.4 Evolution of the SPMP
- 1.5 Definitions and Acronyms
- 2.3 Project Responsibilities
- 4.1 Methods, Tools and Techniques
1.5 Definitions and Acronyms
1.5.1 Definitions
- Spotify - Spotify is an audio streaming and media services provider.
- Agile Approach - A method to manage a project by breaking it up into several phases.
- Web-based - A piece of software that is solely hosted on a web server over the internet.
- Front-end - The user interface and presentation of the application.
- Back-end - Data and infrastructure of the application.
- DNS Service - Servers responsible for translating the domain names to numeric IP addresses leading them to the correct website.
- DDOS Mitigation - Set of network management techniques/tools for resisting or mitigating the impact of denial-of-service attacks on the network.
- Matches - Refers to users that have connected through recommended connections (See 4.1.1 Feature Specific Requirements).
- Friends - Refers to accounts the user has matched with (See 4.1.1 Feature Specific Requirements) or has added by username.
- Sprint - Refers to a two-week block designated to the development of a specific component of the product.
- Spam - A large amount (typically more than 10 messages per second) of requests/messages sent to the system.
- User - A website visitor who has successfully created and authenticated a MuSpace account login and has connected to a Spotify Account.
- OAuth2 - Open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential.
- Sidebar - Menu component on the side of the screen, separate from the main page content. In our case, the sidebar will be on the left side of the screen.
- Client-Side - Action takes place on the user’s (the client’s) computer.
- Server Side - The action takes place on a web server.
- Repository - A software repository is a storage location for the application packages.
- Codebase - The entirety of the source code used for the application.
- V8 JavaScript Engine - An open-source JavaScript engine developed by The Chromium Project for Google Chrome and Chromium web browsers.
- Endpoint - A remote computing device that communicates back and forth with a network to which it is connected.
- Headless - The application is running without a graphical user interface (GUI) and sometimes without a user interface at all.
- Chromium - An open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
- Plaintexts - Text that is not computationally tagged, specially formatted, or written in code.
- Messaging Page - Personal messaging page between 2 or more people.
1.5.2 Acronyms and Abbreviations
- UI - User Interface: A system of interactive visual components for an application.
- SDK - Software Development Kit: A collection of software development tools in one package.
- API - Application Programming Interface: An interface that defines interactions between multiple software applications.
- SDLC - Software Development Life Cycle: Application of standard business practices to build software applications. It is divided into the following steps: Planning, Requirement, Design, Build, Document, Test, Deploy, Maintain. It is an effective way to measure and improve the development process.
- SQA - Software Quality Assurance: A means and practice of monitoring the software engineering processes and methods used in a project to ensure the proper quality of software.
- SRS - Software Requirement Plan: Document that describes what the software will do and how it will be expected to perform.
- SDD - Software Design Description: Document that represents the software design that will be used to record design information and address various design concerns. It is usually accompanied by an architecture diagram with pointers to specific features or smaller pieces of design.
- DDOS - Distributed Denial of Service refers to a type of cyber attack that attempts to take down a service via spam.
2. Project Organization
2.1 Process Model
This project will follow a 7 phase SDLC outlined below:
Stage 1: Project Planning
Stage 2: Gathering Requirements & Analysis
Stage 3: Design & Prototyping
Stage 4: Software Development
Stage 5: Testing
Stage 6: Deployment
Stage 7: Operations & Maintenance (Post Submission)
2.2 Organizational Structure
Using the agile approach, we will be starting on the back-end of the project and the UI design as a group. As soon as the UI design is finished and laid out, the front-end developers will begin development. Concurrently, the back-end developers will also begin development. Everything worked on will be done through sprints.
2.2 Project Responsibilities
| No. | Deliverable(s) | Group(s) | Group Deadline |
|---|---|---|---|
| 1 | Software Requirement Specification (SRS) | All Members | May 25th, 2021 |
| Software Requirement Specification (SRS) Review | May 27th, 2021 | ||
| 2 | Software Project Management Plan | All Members | June 1st, 2021 |
| Software Project Management Plan Review | June 3rd, 2021 | ||
| 3 | Analysis | All Members | June 22nd, 2021 |
| Analysis SQA | June 24th, 2021 | ||
| 4 | Design | All Members | July 13th, 2021 |
| Design Review | July 15th, 2021 | ||
| 5 | Back-end Implementation | Nausher, Robert, Daner, Nish, Jagveer, Jacob, Mathumithan | July 27th, 2021 |
| Back-end Implementation SQA | Front-end team | July 29th, 2021 | |
| Front-end Implementation | Adrian, Kelvin, Nausher, Robert, Adepeju, Declan, Daner, Jiten, Gur-Armaan, Farzan, Jagveer | July 27th, 2021 | |
| Front-end Implementation SQA | Back-end team | July 29th, 2021 | |
| 6 | User Documentation | All Members | August 10th, 2021 |
| User Documentation Review | August 12th, 2021 | ||
| 7 | Final Publishing & Deployment | All Members | August 12th, 2021 |
3. Managerial Process
3.1 Management Objectives and Priorities
The main objective of this project is to develop a web-based music application that will eventually branch out to Android and iOS. This uses the Spotify API and Spotify SDK to connect people listening to similar styles of music. By the end of the term (August, 5th 2021), our goal is to have all project deliverables (the SRS, the SPMP, analysis, document, design documentation, back-end implementation, front-end implementation, and user documentation) complete. By then our goal is to also have a complete well-implemented version of our application, which would be heavily Quality Tested. This project's major priority is to have an easy-to-understand, easy-to-read, consistent, and informative set of documentation as well as a seamless project flow. Since the project has no monetary funding, the completion of deliverables is solely dependent on our time and resources.
3.2 Monitoring and Controlling Mechanisms
Our group meetings take place every Tuesday and Thursday during lectures, where we send one person to listen to the lecture, in this case, Jagveer. During this time, we split into groups for sprints, where work ethic is peer-checked.
All calls are done via Discord (as in a person is not applicable), Documentation is done on Google Docs and then transferred onto our project webpage. The UI is designed on Figma. The Github project is our team's central repository for code and resources
SQA is conducted when sprints are done. The process is conducted by those not in the sprint to ensure that quality control is unbiased.
3.3 Risk Management / User Privacy / User Safety
-
Risk: Too many users attempting to connect to the website/application. This can overload any of our back-end components by creating too many concurrent requests and crashing.
Solution: Access to the site will be throttled by Buttflare - Buttflare is a DNS service that also provides DDOS mitigation. Buttflare limits the number of people that can concurrently access the website. -
Risk: Someone who programs a bot to sign up as a user on the platform and send spam messages/harasses to others, overload the system by sending too many requests, or automate certain tasks.
Solution: All account creation, user sign-in and important actions will be verified using Google reCaptcha v2 to assure that the user is indeed human and not a bot. See Risk 4 for the answer for spam messages. -
Risk: An account sends too many chat messages in a certain amount of time (spam).
Solution: All messages will be rate-limited site-wide to about 5 messages per second. -
Risk: The application is offline due to maintenance, traffic, or other uncertain factors.
Solution: A page will be displayed for the duration of the offline activity that explains to the user why the application is offline, and how long it’ll take to get back online. -
Risk: A new component added to the codebase could make another previous component unstable.
Solution: Anytime a new feature or piece of code is added, we perform adequate testing. -
Risk: Spotify or any fundamental API or resource that we are using changes their terms of services or copyright laws.
Solution: A substitute can be searched for when this happens - no other solution exists for this type of risk. -
Risk: A user experiences harassment, hate, or anything negative.
Solution: The user can report another user by going onto their profile, This feedback is then stored in the database. The developers will be checking reports often. -
Risk: Data not being securely sent over the internet to the MuSpace server.
Solution: All data will be securely transferred from a client to the server with Google Firebase’s implementation of data privacy and security. All endpoints used on Firebase are secured through Google’s servers. See here for more information on how Google Firebase uses security. -
Risk: Another person hacks into your account.
Solution: We will use OAuth2 to make sure that the person is who they say they are. See here for more information on how OAuth2 uses security.
4. Technical Process
4.1 Methods, Tools and Techniques
Technologies:
- JavaScript - JavaScript.com
- TypeScript - TypeScript: Typed JavaScript at Any Scale. (typescriptlang.org)
- Firebase - Firebase
- ReactJS framework - React
- React router DOM - Declarative Routing for React.js
- React firebase hooks - react-firebase-hooks - npm
- React scripts - react-scripts - npm
- React icons - React Icons
- React rounded images - react-rounded-images - npm
- Firebase-admin - firebase-admin - npm
- Node.js - Node.js (nodejs.org)
- Google Firestore - Firestore: NoSQL document database | Google Butt
- Google Authentication - Google Authenticator – Apps on Google Play
- Spotify API - Web API | Spotify for Developers
- Spotify SDK - Web Playback SDK | Spotify for Developers
- StyledComponents - styled-components
- QueryString - NodeJS: Query String
- Validator - validator - npm
- Web Vitals - web-vitals - npm
Project Management Tools:
- GitHub - GitHub Repository
- Figma - Figma Project
- Google Drive (Docs, Sheets) - Google Drive
- Discord - Discord
Project Support Functions:
- Craco React Configuration Layer - Craco
- JavaScript unit testing - JestJS
- Functional testing via Selenium WebDriver - Selenium
- Functional testing via Selenium WebDriver - React Testing Library
- Configuration Management: Firestore - Firestore
4.1.1 Feature Specific Requirements
- Login Page:
- A page that displays a form where a user can type their username and password.
- Will contain a reCaptcha that a user has to pass.
- The user will then press the submit button to login.
- The data from the form will be sent to Firebase Authentication - this will return a success or failure message that will then be displayed to the user.
- If the user is successful in logging in, they will be redirected to their home page.
- Account Creation:
- The first page of the account creation process requires the user to input their email address, username, full name, and password. These will be a part of a form, where the username and full name field are plaintexts, the password field is a password field, and the email address field is an email address field.
- This data will then be verified to make sure it meets certain criteria. These criteria are as follows:
- The username must be a minimum of 5 characters and a maximum of 32 characters.
- The email address must be in a regular email address format.
- The password must be a minimum of six characters.
- The full name has no restrictions as there are too many variations.
- After all these factors have been verified, they will be sent to Google Authentication to be stored.
- The second part of the process in creating an account will be clicking on a link in your email address that verifies that you are registering with your email address. This link will then take you to the next page.
- The next page of the account creation involves linking your MuSpace account to your Spotify account. This page consists of a single button that uses Spotify’s OAuth2 implementation of account permissions to allow you to give permission to Spotify to give the user’s account information to MuSpace. This process will open in a new webpage that is managed by Spotify.
- Once the user has linked their Spotify account, they will be redirected to the user’s home page.
- Home Page:
- All pages of the application will have a sidebar on the left side of the page that allows you to navigate through all the main component pages of MuSpace.
- The home page is the central component of the user experience.
- The home page includes basic user information such as the most-streamed music that day and recently listened to songs.
- It also displays the user’s friend’s top albums and listening activity. There’s a section that also displays popular public listening rooms that the user may be interested in joining.
- User Profile:
- The user profile will use user data compiled by MuSpace. These stats will constantly be updated by retrieving and recompiling data on a user from the Spotify API and processing it to tailor it towards the features of MuSpace.
- Shows recent listening history from Spotify.
- Will display basic user information, such as username, which will be retrieved from the Firestore database.
- The user profile page will display other generated statistics that are dependent on the specific user’s listening habits.
- A request is sent to the Firestore database, which will then return a list of data to be displayed.
- Friends Page:
- The Friends page will list all the user’s friends.
- On the Friends page, clicking/tapping on a friend's name will present the user with options to send a private message, or unfriend the selected user.
- A request is sent to the Firestore database, which will then return a list of chat room IDs that the user is a part of. The client can then request each chat room specifically, which the database will return.
- Messaging Page:
- The Messaging page shows a list of all ongoing chat with friends
- These rooms are React components, which can individually be clicked on.
- Users will be able to select a conversation that will open it in a bigger component which will display the chats between all users, alongside their names and profile pictures. Any messages sent will be sent to the Firestore database, which will then be sent to all other users’ clients.
- Users will also be able to delete conversations. Deleting the conversation will remove it from the Messaging page and also remove the user from the list of users participating in the said chat room.
4.2 Software Documentation
Software documentation will be taken in all phases of development and planning, to ensure that the implementation of the software satisfies the requirements.
The following documentations are required as a minimum:
- Software Requirements Specification
- Software Project Management Plan
- Analysis documentation
- Design documentation
| Name | Standard/Template | Reviewed By |
|---|---|---|
| Requirements Document | Modified IEEE | Entire Team |
| Project Management Document | Modified IEEE | |
| Analysis Document | Modified IEEE | |
| Design Document | Modified IEEE | |
| User Document | Modified IEEE | |
| Participation Record (Hours) | Self-documentation using internal Excel sheet | Adrian |
| Source Code | Modified IEEE | All Developers |
4.2.1 Software Requirements Specification (SRS)
Up to date SRS Documentation.
4.2.2 Software Design Description (SDD)
We will be using JavaScript, TypeScript, CSS, and HTML as the languages for the project. These languages are the easiest to implement for a web application of this magnitude which requires the front-end and back-end to work with each other seamlessly. Without the hassle of separate code bases for both. JavaScript and TypeScript are also ideal languages that have a great capability of handling asynchronous server-side requests.
We will be using ReactJS, StyledComponents, and Semantic UI to create the front-end of the application - this is the code that will be executed and displayed client-side using a built-in browser JavaScript engine, such as Google’s V8 JavaScript Engine.
For the back-end of the application, we are using Node.js to run a headless Chromium instance to execute server-side code. The back-end will integrate the Spotify SDK Spotify API to draw all user data - artists, albums, genres, and songs that the artist listens to. The API can also extract music listening and other statistics. This data will be used to connect with other users using a scoring system and to discover new music. The Spotify Web SDK will be used to play music using the user's Spotify account in the web app. The SDK requires the users to have a Spotify account.
The other portion of the back-end uses Google’s suite of APIs included in Google Firebase. These are but are not limited to Firestore and Authentication. Firestore will be used to store a lot of data:
- User data
- Login Information
- Selected Spotify Information
- Personal Data (Name, Age, Country, etc.)
- Connections between users
- Date of connection
- Users involved
- Chat/Messages Rooms
- Chat room ID
- Chat messages
- Room participants
The code styling and conventions have been outlined in this Github document.
4.2.3 Software Test Plan
- Unit Testing
- All major functions and components of the project will be tested using Jest. This testing framework allows the ease of writing unit tests.
- Functional Testing
- We will be using the React Testing Library and Selenium WebDriver. This allows a lot of automation with testing visual components and ensuring the application works as intended. These technologies act as the end-user.
4.3 User Documentation
All pieces of code will be properly documented in order to ensure clarity of the purpose and function of the program. Up to date user documentation will be posted on our projects wiki page, which can be found here: MuSpace Wiki. All other documents can be found on our project webpage here: MuSpace Documentation.
5. Money/Cost
This project is solely dependent on the time and effort of the developers. No monetary funding is collected or needed. All resources (frameworks, APIs, etc.) are free and open-source with the exception of purchasing a one-year domain subscription that was divided equally between all team members. A Spotify Account is required for developing and testing Spotify SDK features.
6. Extra Details
Version History:
- Version 0.1.0 [Sections 1-5] Preliminary Document
- May 27th
- Members - Adrian, Peju, Jacob, Manimaran, Daner
- Version 0.1.1 [Sections 6/ Completion of Previous]
- June 1st
- All Members
- Version 1.0.0 [Sections 1-6, Finalize Document]
- June 3rd
- All Members
- Version 1.0.1 [Sections 1-6, Update to Reflect Changes Made]
- July 30th
- Members - Jagveer, Jiten
- Version 1.0.2 [Section 4.1, Update to Include all Technologies used]
- August 15th
- Members - Jacob
Authored by:
- Ali, Farzan
- Alting-Mees, Adrian
- Aylani, Jiten
- Goldman, Jacob
- Hollingworth, Declan
- Kellner, Kelvin
- Maan, Gur Armaan
- Manimaran, Mathu
- Mazza, Robert
- Olowonefa, Peju
- Rao, Nausher
- Sangha, Jagveer
- Tewari, Nish
- Yasin, Daner