Introduction and Planning

This page will describe our planning process, how we organized our work, the requirements we defined for this project, and the methodology we use for development.

Development Methodology

For the development of PlanTask, a SCRUM methodology was used. SCRUM is a software development methodology (although it can be used for other purposes) that consists of sprint sessions, which are sessions with a fixed time in which every member works on a certain part of the project, and aims to have a shippable product by the end of each sprint. Even though SCRUM is mainly intended to be a framework for software development, we also utilized it to organize the planning stages of the project, by using a tool called Trello.

We selected the SCRUM methodology since it allows us to divide the work into smaller tasks, and work on each task until we can have a finished product.

Trello is a project managing software which can work with multiple methodologies, including SCRUM. In Trello, we created multiple lists divided into Backlog, Sprint Backlog, In progress, Review, and done. In the backlog, we insert every part of the project that we need to do, ordered by priority. Each task from the backlog will pass through every one of the lists until it reaches the done state.

Futher ahead, the whole backlog will be posted in this documentation.

We have included a section in this documentation that documents both our sprints and daily scrums (or daily stand-ups)

Project "Roles"

The team developing this project is composed of 3 people, which the tutor randomly selected. We selected Andres as the SCRUM master, the Mozcalti team and Koch rep as product owner and Angel, Itzel and Andres as the development teams.

---

Backlog

Backlog

Product backlog:

(A list of everything that needs to be done for the project organized by priority)

-Define idea for project

-Define functional / non-functional requirements for the project

-Complete backlog

-Database diagram and initial planning for data models

-Wireframes for the app’s design

-Create database in postgreSQL and convert to SQLAlchemy

-Get project in shared GitHub

-Create pyramid project from cookiecutter template

-Implement database through SQLAlchemy into pyramid project

-Create user types (admin, PM, member, observer)

-Implement authentication with JWT and store user info with argon2 hashing

-Implement RESTful API

-Implement CRUD for team projects

-Implement CRUD for users into projects

-Implement CRUD for tasks and micro-tasks

-Implement user permissions and limit access to areas of the app depending on user type

-Get notifications and async tasks done

-Messaging system

-HTML and CSS implementation following wireframes and layouts using BootStrap

-Making forms and data inputs work with pyramid project

-Implement JavaScript for the frontEnd

-Test that all templates work properly with the backend

-Connect forms with

-Unit testing with pyTest

-Test reports with Allure

-Integral Testing

-Security in BackEnd and DB through hashing, encryption, etc.

-Check for data integrity

-Using docker for deployment

-Monitor workload on server side and test for loading times on user side

-Cloud hosting

-Creation of app logs and monitoring

---

Requirements

Functional Requirements

Project Manager:

FRQ: The user (Project Manager) should be able to create a new team and add members that belong to the organization. They can also give each user labels depending on their specialty (e.g. backend, frontend, devops, planner, etc.)

FRQ: the Project Manager should be able to see all the teams that he has created in a welcome page

FRQ: The user (Project Manager) should be able to create new tasks for the team and add a description, divide the task into smaller micro-tasks and upload files if needed

FRQ: The user (Project Manager) should be able to add comments or see the team’s comments

FRQ: The Project Manager should be able to define tasks for the team

FRQ: The project manager should be able to divide the tasks into micro-tasks and either assign them manually to each user, let them be assigned automatically by their labels or let each user select their mini-task to do.

FRQ: The project manager should be able to assign a due date for each task and micro-task

FRQ: The project manager should get a dashboard where they can check progress, see how many tasks are left to do, how many are being worked on, which users are free, which tasks are up for review, etc.

FRQ: The PM should verify completion of each task before marking them as completed

FRQ: The PM should be able to access and filtrate an activity log for their projects to lookup each member’s actions

Project Member:

FRQ: The Member should be able to see the team projects that they have been

assigned to

FRQ:The member should be able to see which micro-task was assigned to them, or

select a micro-task if they’re free to choose

FRQ: The member should be able to download files if any were uploaded to the task

FRQ: The member should be able to add comments to the task or the micro-task,

depending on their needs. Said comments can contain files and links

FRQ: The member should be able to select/update an approximate amount of progress in their micro-task, which other members and the PM will be able to see to keep track of each micro-task’s progress.

FRQ: The member should be able to see and update the state of the micro-task (Undone, working on it, up for review)

FRQ: The member should be able to see a dashboard with their pending micro-tasks, which teams they belong to, their overall progress, etc.

FRQ: The member should be able to see and use a Pomodoro style timer to help them keep track of time and optimize workflow.

FRQ: The member should receive alerts to their email whenever the due date for a micro-task is coming up

FRQ: The member should be able to start a real-time chat with any of the members of their team

FRQ: The member should be able to leave comments when submitting a task that specify any things left to do, any problems still present or information that might be useful

FRQ: The member should be able to access to his history of the movements he have made

Admin:

FRQ: The admin should be able to access the activity log of the entire system and

filter by either user, project or time

FRQ: The admin should be able to assign roles to each user, either PM,

member or observer

Non User specific

FRQ: The system should validate user’s credentials and device signature to prevent external users or devices from accessing

FRQ: The system should validate the user’s role, redirecting them to different screens depending on if they’re admin, PM, member, or observer

FRQ: The system should have a built-in integrated ‘pomodoro’ function to help users to manage their own taks, this won’t be traced down or saved as this is personal for each user

FRQ: The system should log every action that users do, like uploading files, changing the status of a task, being added / removed from a project, etc. storing the time the change was made, which user made it, and which project it relates to.

FRQ: The system should verify that the files uploaded by PMs or members do not contain potentially harmful extensions like .bat

FRQ: The system should not allow observers to make any changes to the teams or tasks

FRQ: The system should have a session time limit of 30 mins and kick users out if they exceed this time

FRQ:The system should implement tests for each module, including database connections and backend

Non-Functional Requirements

NFRQ: The system should use the company’s colorway and maintain a professional picture

NFRQ: The system should be intuitive enough for users to be able to use it efficiently with minimal or no training

NFRQ: The chat system should be able to hold up to 100 concurrent users chatting

NFRQ: All passwords or user-sensitive information should be encrypted or hashed in the database

NFRQ: The system should keep a consistent appearance throughout, to maintain a professional image

NFRQ: The system should have attractive design that keeps it simple, so that users always know where to look for what they need

NFRQ: The system should not have over-bloated screens or views, to prevent users from feeling lost