FORTRAN Documentation

1. Introduction

The web application will need storage both locally and externally. Locally that would be the session storage and the latter would be server storage which will consist of a variety of the user’s uploaded files. This includes the user’s Academic Transcripts, CVs and profile photos.

A reliable database system will have to be implemented to ensure consistent data capturing and file storage.FORTRAN decided that Firebase will be the best storage solution due to its security and convenience. GraphQL will be the API used to upload the user’s files.

Additionally the storage feature will be integrated into numerous other features namely the student/company profiles and the company rep features. This in turn will allow students to upload their files on the undergraduate portal and also allow the respective companies to download these files. The UI of our storage feature as well as the backend implementation will be merged in with the above-mentioned features when fully functional.

2. Functional Requirements

• Storage - Feature must store all the files a user wants to upload on a database, namely Firebase or PostgreSQL.
• Data Retrieval - Feature shall allow respective Companies wishing to view the Undergraduate's documents to have access to the files and download them easily.
• File Deletions - Feature must allow students to delete their previously uploaded files from the database.
• Admin Privileges - Certain users who will moderate this portal must have admin privileges who can upload/delete files on behalf of students and companies. This is important as some students may upload inappropriate content on the portal for example.
• Interface:
  • Feature must contain a user-friendly interface for the user to upload their files. This includes a "file upload" button as well as a brief menu to select which files to upload.
  • Feature must contain a user-friendly interface to allow company profiles to download files from the database.
  • Feature must contain a user-friendly interface to allow administrator profiles to moderate the database. This includes letting the admin upload and delete student’s files when necessary.

3. Non-Functional Requirements

3.1.1. Quality requirements

• Security - The files uploaded must be stored securely in a database outside the reach of users who are not authorized to view such information.
• Error Handling - Feature shall provide simple and understandable feedback when a user makes an error. Such as a pop-up message when the user tries to upload an invalid file type.
• Usability - Feature must upload/download the required files within a reasonable time frame, assuming that the user has a decent internet speed.
• Reliability:

• Feature shall have near perfect reliability when performing tasks with the database, assuming the user has a stable internet connection.
• The database must be operating and available +90% of the time, a dysfunctional database will not make the student portal very usable. Team Members & Roles (Sprint 1)

4.Contracts

5.Team Members & Roles (Sprint 1)

• Project Manager - Zoe May Liebenberg
• Business Analyst - Christian Kenan Devraj
• Designer - GO Olumayowa Shoderu
• UI Engineer - GO Olumayowa Shoderu
• API Engineers - Muziwandile Ndlovu
• Backend/Service Engineers - Omolemo Mashigo
• Data Engineers - Larisa Botha
• Testers - Simphiwe Ndlovu
• Developer Operations - Lindinkosi Kunene

6. Components/Services of our Feature

Progress/Responsibilities of Team Members

Project Manager - Zoe May Liebenberg

u20444738

As a Project Manager, any type of organization responsibilities fell into my domain. I had to take control of planning and allocating jobs. In order to ensure that we completed in time and within scope, I had to:

• Organize meetings within the FORTRAN group as well as any meetings with outside teams or individuals from outside teams. This guaranteed that we could integrate with other teams flawlessly and it also confirmed that FORTRAN was not doing jobs that other teams had already completed or were planning to complete.
• Take minutes from each meeting so that we do not forget everything discussed. I followed up on all discussion points to ensure that they were carried out by the right people.
• Monitor that team members go to meetings and follow up with the team about anything important that was discussed.
• Keep the team’s playbook updated with anything happening so that everyone could stay informed. This also includes consistently updating the project board with jobs for each member and making sure that each member follows through.
• Initiating and maintaining communication on GitHub and setting reminders for everyone to upload all their documentation to the discussion area.
• Updated project board and set clear deadlines for tasks that needed completing.

Business Analyst - Christian Kenan Devraj

u20504552

My responsibilities as a Business Analyst (BA) primarily consisted of writing up documentation and planning how exactly our team would tackle the designated feature. A few of my responsibilities included:

• Providing basic Functional Requirements for potential features, this took place prior to the meeting where team features were allocated by the head PM.
• Drafting a preliminary Requirements list as our feature was assigned to FORTRAN
• Cooperating with other teams' BAs to provide clarity regarding our features. This included minimizing any overlap between the teams and confirming whose jurisdiction certain functional requirements fall under.
• Providing an extensive SRS (using the textbook as a guideline) that also includes a database schema, suggested security measures , acceptance criteria ect.
• Maintaining team FORTRAN’s portion of the GitHub Wiki, this included constant updates as our features functional requirements were clarified and adjusted over time.
• NOTE all above-mentioned documentation can be found in Team FORTRAN’s discussion page on GitHub

Designer - GO Olumayowa Shoderu

u16186258

My core responsibilities in Sprint 1 as team FORTRAN’s designer was to first conceptualize the UI for our team before implementing it. By gathering and evaluating the functional requirements given in collaboration with the PM and BA I was able to complete my responsibilities which consisted of:

• Designing the UI elements through sketches at first.
• Designing wireframes based on feedback received and presenting it as a rough draft to the team as well as the Designers across the entire Mini-project as well as the project owners.
• Designing extensive mockups and prototypes that clearly illustrate how the Storage site functions and looks.
• Collaborating with every other team’s Designer and the UI-Kit team to establish consistency between our features UI and the entire Mini-Projects UI.
• Collaborating with the mobile Development feature in order to stick to the features that are to be implemented in the mobile UI and also to maintain consistency across all other features.
• Did some layout adjustment to accommodate the mobile view and also further made additional adjustment based on feedback received.

UI Engineer - GO Olumayowa Shoderu

u16186258

My responsibilities as a UI Engineer in the first sprint was to start with the implementation of the Designs as well as plan the layout of the webpage. So far I have looked into the Angular framework, material, NGXs and so on. Based on my research on angular, I decided that I’m gonna make certain parts of the page components. The black bordered parts of the page in the picture will be developed by the UI Kits team as general components that can be reused by every other feature. The blue and purple bordered parts will be developed by me. I decided to make these components because of the responsiveness of the page, when the page shrinks into a mobile view, the purple components disappear as shown to the left.

API Engineer - Muziwandile Ndlovu

u20469366

My responsibilities as API Engineer in the first sprint was to build a schema and create a mock API which had the core functionality of being able to be called for an outside source when running. Furthermore I had to get the understanding of what the Lead Front-end Developer would need in terms of data to be requested and also consult with the service engineers on what services would be needed. Items Completed:

• Created the mock API that is callable
• Collaborated with other API engineers to get our schemas established
• Short draft of how General Storage works (On Fortran Discussion board)
• Ehlpin

Backend/Service Engineer - Omolemo Mashigo

u19044233

As the Backend/Service Engineer, my responsibilities in the first sprint were to create the service layer. I had to create command and query files using the NestJS framework. These commands will ensure that our feature will enable users to add and delete specific files such as their academic records, CVs and other necessary files. Other commands will enable users to delete the files. The query commands I created are to actually get the user’s academic records and files and store them on the database, together with their credentials such as IDs, email addresses, username and passwords.

Data Engineer - Larisa Botha

u20522623

As the data engineer of the storage team I am responsible for accessing and managing any data from external sources which in our case included the PostgreSQL database as well as a third party storage tool. During this first sprint I accomplished the following:

• Designed a file upload relation that will simplify the database query process while increasing the adaptability thereof. (ie one can easily alter the files allowed for upload without changing the structure of the relation).
• Established connections with both external data sources situated under the repository folder.
• Experimented with a mock PostgreSQL database and a Firebase bucket in order to write template/example functions on how to use the above mentioned connections thus maximizing productivity in the next sprint.
• Developed a manner in which other features will interact with the temporary Firebase storage solution for various external storage purposes such as student story videos and database dumps.

Tester - Simphiwe Ndlovu

u19027372

As a Tester for the storage feature I am responsible for helping developers with their testing and ensure that everything is tested (correctly), comprehensively and is logged before any mergers to the upstream. Ensure that everything that gets incorporated upstream is tested and passed. During this first sprint managed to document a testing plan and testing cases for the storage feature. For the second sprint I will be dealing with different types of testing which are Unit testing, Integration testing, End-to-end testing and Usability testing.

Developer Operation - Lindinkosi Kunene

u17102210

My responsibilities as the person in charge of the developer operations for the first sprint was to oversee anything github related which included :

• Providing help with some aspects of github.
• Enforcing on the team standards for how PRs and merges should function( originally there was some confusion amongst the dev ops about the standards that were later cleared by the CI/CD feature team after a meeting on the 23rd of March)
• Reviewing all PRs done by my team and re-running the CI tests again to verify results (if and where needed).
• Fixing any issues caused by a PR made by a team member and helping the other dev ops with pipeline breaks for their teams. We were also tasked with consulting the CI/CD team before making any reverts in the develop branch.
• As a dev op most of our work (pertaining to maintaining the pipeline) started this week and will continue into the second sprint. And as such I will be continuing with this role into the second sprint to ensure smooth operations from our side.

7. Meetings

Date	Meeting Duration	General Meeting Agenda
27/02/2022	20 minutes	Introductions and allocating project manager
28/02/2022	55 minutes	Assigning roles
02/03/2022	54 minutes	Project manager update and discussion of possible features
08/03/2022	23 minutes	Choosing Top 4 features
09/03/2022	29 minutes	Allocated feature discussion
11/03/2022	10 minutes	Designing of the feature
12/03/2022	25 minutes	Business analyst update and database discussion
15/03/2022	20 minutes	Meeting with team Ruby
15/03/2022	40 minutes	Project boards
22/03/2022	27 minutes	Preparation for end of Sprint 1
30/03/2022	17 minutes	Planning for the start of Sprint 2
11/04/2022	24 minutes	General team update
18/04/2022	29 minutes	Deadline of Major Feature commits
21/04/2022	17 minutes	Demo 2 Preparations

8. Acceptance Criteria

The storage feature provides a backbone for the entire Mini-Project as a core functional requirement is data upload/retrieval by the respective users. With this fact in mind, we have set mandatory acceptance criteria before the release of this feature:

• File upload must have a near perfect success rate, when users use our feature there must be minimal errors when interacting with the database. Any errors while uploading must be caught and the user must be notified. [Signed by Christian Devraj - Business Analyst of Team FORTRAN]

• File download must be quite reliable as well. When a user attempts to download the file it must be:

  • The correct file selected by the user. [Signed by Christian Devraj - Business Analyst of Team FORTRAN]
  • The same file format that was uploaded. [Signed by Christian Devraj - Business Analyst of Team FORTRAN]
  • Not corruptible in any way. [Signed by Christian Devraj - Business Analyst of Team FORTRAN]

• The UI must be aesthetically pleasing and completely functional, a UI with even a few faults will make the user-experience inadequate. This in turn will damage our entire system's reputation among other repercussions. [Signed by Christian Devraj - Business Analyst of Team FORTRAN]

• Feature should be able to integrate the other features and the mini-project as a whole. [Signed by Christian Devraj - Business Analyst of Team FORTRAN]