# Sprint 0

This initial sprint the team met the PO, taking the initial steps to understand the product, we'll explore the following topics:

**Kickoff meeting with the PO** - Here we expose what was defined in the first meeting with the PO.

**Similar projects survey / Market Research** - Products related to our topic or with similar challenges as the ones we'll face

**Domain analysis** - Here we clarify the different domains in the product

**Product vision refined** - Our vision about the products after meeting with the PO

**First architectural definition** - First decisions about the architecture we'll adopt for the product

**Main risks that may impede success** - What may hold us back from achieving the requisites

**Preliminary technical soundness assessment** - Our reasons to choose our technological stack

**Assignment of Roles** - Defining the TL (Team Leader) and the SPO (Surrogate Product Owner)

**Team collaboration tools** - The tools we'll use to communicate, store files and develop the project.

## Kickoff meeting with the PO
In this first meeting we got to know the PO and the project better. We've also defined the metrics we'll tackle:
- CO2
- Global temperature
- Water level
- Air quality
- Microplastic in water
- Ozone hole

Each member was asked to make a mockup about their idea of the project so that the PO could better define his ideia for this project.

## Similar projects survey / Market Research

The Product Owner wanted two different approaches to the visualization, which is the main component of the project:
- Clear and exact, this might be graphs, numbers or others
- Visual and intuitive way that anyone can understand

So we searched for projects that belonged to one of these two categories.

### [CO2.earth](https://www.co2.earth)
This website presents in its home page last month's CO2 concentration and average temperature levels and compares them to previous years.
Its information is followed by articles warning users to the inevitable consequences if this trend continues. This however is displayed in a not so user friendly matter which is exacly what we pretend to do in our project.


### [ShowYourStripes](https://www.showyourstripes.info)
ShowYourStripes provides a user friendly way to analyse the rising of temperatures of multiple countries.
By selecting a country it is displayed a visual representation of the change in temperature as measured over the past 100+ years. Each stripe represents the temperature in that country averaged over a year. And for virtually every country or region, the stripes turn from mainly blue to mainly red in more recent years, illustrating the rise in average temperatures in that country


### [Electricity Map](https://www.electricitymap.org/?page=country&solar=false&remote=true&wind=false&countryCode=PT)
Electricity Map provides a view of Europe with detailed information about each country's electricity consumption as well as its carbon intensity.
This is done in an extremely user friendly way allowing the user to compare different country's emissions.

### [Climate Time Machine](https://climate.nasa.gov/interactives/climate-time-machine)
This NASA's platform shows hard proof about climate change in a visual way, using colors to transmit the change in the various metrics.

### [CO2 Box](https://www.nationalgeographic.com/environment/2018/12/climate-geoengineering-series-intro/)
Although this is no project, it's the perfect example of what the PO wants us to do in the human friendly data visualization aspect of the project. Here a simple box transmits a lot of information without overwhelming the user with meaningless details to a normal human.

## Domain analysis

### Key Abstractions
**Database** - To be populated by APIs, scraping and/or spreadsheets. Contains all the data related to the existing metrics.

**Dashboard** - The visual aspect on the user's side. Presents the different metrics and their information through graphics and animations.

**Metrics** - Measures for tracking the planet's health.

**Information** - Past, present and predicted values for each metric, followed by relevant explanations.

## Product vision refined
Our product is a **call to action** on climate change. Hard proof shown both by concrete and human friendly data visualization to force a need in each individual to act on climate change.

## MVP

The MVP (minimum viable product) was defined by our PO and it goes as follows:

* Homepage with easy to use visualization of the current state of the planet.
* Individual pages for each metric in which the user can filter the data by date and other relevant parameters.
* Add to each metric's page individual information about the importance of what's being measured.
* Decent UI

### Target
We'll have two different targets:
- People worried about the climate
- They'll most likely be familiar with the problem. After following a link from the press, social media or a friend they won't comeback. Our goal for them is awareness.
- People in power
- They need the information to make decisions. Researchers, cientists, politicians, etc.

## First architectural definition


The architecture must adapt to a simple web app, meaning it will need a simple scheme where it uses these layers: frontend, backend and database.
To achieve that we will be using an Architecture with a Layered Pattern.

“This Layered Pattern can be used to structure programs that can be decomposed into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher layer.”

Our layers will be:
* Presentation layer (UI layer)(front-end)
* Application layer (service layer)(back-end)
* Business logic layer (domain layer)
* Data access layer (database layer)(database)

## Main risks that may impede success
### Lack of APIs

One of the main concerns about developing this project is the availability of APIs that can give the information we need. If there are no APIs to give this information this may force us to search the information through other means.
We would have to scrape a website that has the information or only use **past** information that is shared through spreadsheets, this would mean that the project would lose the live component that the Product Owner wanted and be static instead.

### Lackluster presentation/design

In order for this project's objective to be achieved, first time users must be captivated by the way the information is presented in the dashboard. As such, good planning and mockups are important for the project's success.

## Preliminary technical soundness assessment

The technologies used in this project are MERN based. MERN stands for mongoDB, expressJs, reactJs and nodeJs.

> Is the chosen architecture a good fit for the problem?

Yes, because it fits all the requirements for our project and and favors our development.
The reason being, because it is a webpage, there’s not need for any other component than the one shown in the schema.

> Are the chosen technologies a good fit for the architecture?

It is a good fit because it allows for rapid development as it is all javascript based, which will allow easy movement between the backend and frontend, for all the developers working in this project.

> Are the chosen technologies a good fit for the problem?

This web app will be frontend heavy, react has a lot of packages freely available which allow for good looking elements and animations to be implemented without much hassle, and making sure they are personalized to our needs. On top of that react allows for real time up dates to the webpage seamlessly.

When it comes to the backend the use of nodeJs will work perfectly because, once again, the fact that it is javascript based makes it really easy to develop on top of, not to mention the connection to a mongoDB document (making queries, setting values and updating values) is seamless with the help of a package called mongoose.
On top of this there are spidering packages that work really well and will be needed if some APIs fail to give us all the needed information.

MongoDB is perfect because the web app is not relation heavy, This means a database technology like mongoDB, that’s NoSQL JSON like database, will be easily customized to our needs. Also, the fact that most of our metrics will follow the same structure for each entry point (date, value, type), helps with the schema prototyping.

>Does the implementation evidences a good application of the chosen technologies?

It provides a good aplication becasue, once again, the webpage we're building is frontend heavy and react provides all the tools we need to make sure it will not only be informative but also intuitive and easy to look at.

## Effort measure
>is the expected effort appropriate for the curricular unit (120h/student)?

We believe it will be enough time to not only finish the project, but to make a polished ready for release product. Of course this will all heavily depend on how the APIs are made and if we are able to find the relevant information.

we are confident it will be possible to make a project the PO is happy with and that we are proud of.

## Assignment of Roles

TL (Team Leader) will be Duarte Frazão and the SPO (Surrogate Product Owner) will be Manuel Monteiro.

## Team collaboration tools

- *Google drive* - Files that are not supposed to be on the repository
- *Gitlab* - Code repository and scrum board
- *Trello* Team to-do list
- *Slack* - One channel for team communication and another for team communication with the PO