### Histórico de Versão

| **Data** | **Versão** | **Descrição** | **Autor(es)** |
| --- | --- | --- | --- |
| 14/02/2021 | 1.0 | Criação do documento. | José Aquiles |
| 16/02/2021 | 1.1 | atualizando o documento | José Aquiles , João Victor, Pedro Bayma, Luciano Santos|
| 18/02/2021 | 1.2 | Correções apontadas pelos professores | José Aquiles, João Vitor, Pedro Bayma, Cícero.

# 1.Introdução

## 1.1 Declaração do problema

| --- | --- |
| --- | --- |
|Problema| O conceito de marca mutante não possui um software para implementa-lo|
|Afeta | Software para o bem(SpB) |
|Cujo impacto é| Fragilização da imagem do projetos desenvolvidos pelo SpB
|Uma solução de sucesso seria| Criar um software que modifique a marca SpB de acordo com a necessidade dos seus projetos, respeitando o design já desenvolvido
## 1.2 Objetivos do Projeto

Criar uma aplicação que possibilite a implementação de uma marca que se adapte ao publico.

## 1.3 Definições, acrônimos e abreviações

- SpB - Software para o bem
- PO - Product Owner: é a pessoa responsável por maximizar o valor resultante do produto desenvolvido. Sua principal responsabilidade é gerenciar o Product Backlog.
- Marca mutante - Marca que varia conforme a necessidade

# 2 Stakeholders

| Nome | Descrição | Responsabilidades |
| --- | --- | --- |
| Luciano Mendes | Idealizador do conceito da marca mutante do **software para o bem** | Estabelecer os requisitos, verificá-los e certificar se o software está de acordo com a ideia inicial |
| Coordenação e equipe de publicidade do **SpB** | Quem está por trás da divulgação e manutenção da indetidate do **software para o bem** | Utilizar o software para adaptar a marca ao tema em que estão trabalhando|

# 3 Visão Geral do Produto
## 3.1 Declaração de posição do produto

| -- | -- |
| -- | -- |
|**Para** | O SpB |
|**Quem** | Trabalha com vários projetos|
|**A**| Marca SpB |
| **Que** | Deseja adaptar a marca ao público alvo de seus projetos|
| **Ao contrário** | Usar uma marca estática para todos seus projetos |
| **Nosso Produto**| Viabiliza uma marca que se adapta de acordo as propostas apresentadas |

## 3.2 Minimo Produto Víavel (MVP)

- Permitir mudanças nas cores da marca aleatoriamente de acordo com a as cores definidas na paleta de cores da marca SpB.
- Movimentação das formas nos eixo x e y.

# 4 Visão geral do produto
## 4.1 Organização do projeto

| Papel | Atribuições | Responsável | Participantes |
| -------- | -------- | -------- | ------- |
| Desenvolvedor | Desenvolver o software e seus artefatos | José Aquiles |José Aquiles, Pedro Bayma, Cícero Filho, João Victor, Luciano Santos
|Profesores orientadores| Orientar o desenvolvimento do projeto e fazer as validações necessárias | | George Marsicano, Fabiana Mendes, Rafel Fazzolino
|Product Owner(PO)|Elaborar os requisitos e verificar se foram aplicados corretamente|Luciano Mendes| Luciano Mendes

# 5 Ferramentas, Ambiente e infra-estrutura
## 5.1 Hardware

| Perfil | Tipo de Hardware | Configurações | Qtd. planejada |Prazo estimado| Observação|
| -------- | -------- | -------- |--- | --| ---|
| Desenvolvedor | Desktop, Laptop| | 5| -|-|
Teste| Smartphone| Android e iOS || -|-|

## 5.2 Software

| Perfil | Tipo de Software | Nome da ferramenta | Versão |Qtd licenças planejadas| Prazo estimado| Observação|
| -------- | -------- | -------- |--- | --| ---| --|
Todos os perfis | Gerenciador de controle de versão| Git| | -| - |-|
Desenvolvedor | IDE | VS Code| | |-|-|
|Teste| Emulador | Android Studio | | | -|-|
|Desenvolvedor| Framework de desenvolvimento | Flutter| 1.22.6 | |- |-|
|Desenvolvedor| Gerenciador de containers| Docker| | |- |-|
| Desenvolvedor | plugin de navegador | zenhub| | | |quadro kanban, gráficos de velocity e burndown |

# 6 Processo de gerência de software
## 6.1 Planejamento das fases e interações do projeto

As etapas de desenvolvimento obedecerão ao Scrum com sprints de 3 semanas com reuniôes no começo de cada para a retrospectiva da sprint anterior e planejamento da próxima sprint.
Será criado um quadro kanban com a extensão zenhub

## 6.2 Processo de desenvolvimento e mensuração.

Vai ser aplicado, não exclusivamente, desenvolvimento em pares para nivelar o conhecimento da equipe.
Para medir o desempenho da equipe nas sprints será utilizado o gráfico de burndown e velocity gerados pela extensão zenhub.

## 6.3 Matriz de Comunicação.
| Descrição | Área/Envolvidos | Periodicidade | Produtos Gerados |
| -------- | -------- | -------- | ------- |
|Comunicar situação do projeto|Equipe, professores | Semanal |
Reunião de sprint | Equipe do projeto| A cada 3 semanas|
| | | | |

## 6.4 Escalabilidade do projeto.

Conflitos internos serão tratados primeiro entre a equipe e depois repassados aos professores.

## 6.5 Gerenciamento de riscos.

- Lista de riscos
- Alguém precisar se ausentar do projeto
- Nâo cumprir com os prazos estabelecidos
- Defeitos e falhas que se propaguem no projeto ("Bugs")
- Solução: Testar e verificar o projeto periodicamente
- Qualidade de Código
- Software não estar adequado com as métricas de qualidade de software definidas
- Soluções:
- Uso de corretores de folha de estilo(linter)
- Pipeline de automatização
- Equipe de desenvolvimento com ambientes muito distinto.
- Solução: Uso de um gerenciador de containers(docker) para que todos trabalhem no mesmo ambiente

## 6.6 Critérios de replanejamento.

- Saída de um membro da equipe
- Dificuldade de criação ou implementação

# 7 Lições aprendidas

- Criação da visão do produto
- Edição de texto em Markdown
- Conceito de marca mutante

# 8 Referências