# Plano de Gerência e Configuração de Software

**Histórico de Revisão**

| **Data** | **Versão** | **Descrição**                                    | **Autor**    |
| -------- | ---------- | ------------------------------------------------ | ------------ |
| 11/06/18 | 1.0        | Adicionando Introdução, Ferramentas e Políticas. | Igor Gabriel |

## 1. Introdução

&#x20;Neste documento, será descrito o planejamento dos principais itens relevantes em relação a Gerência de Configuração de *Software*, com o objetivo de apresentar as ferramentas utilizadas na configuração do projeto além dos padrões de organização e nomenclatura a serem utilizados.

## 2. Item de Configuração

&#x20;Um item de configuração é um artefato produzido no projeto que necessite de gerenciamento (itSMF, 2002). Portanto, para determinar quais ferramentas serão utilizadas e métodos de versionamento, determina-se quais serão os artefatos que se tornarão itens de configuração. Para o contexto deste projeto, serão considerados dois principais itens de configuração a serem mantidos:

* **Documentos:** Arquivos em texto contendo planejamentos, descrição do produto e projeto e outros semelhantes.
* **Código:** É um dos artefatos resultantes da execução do projeto, sendo composto por um conjunto de arquivos texto, que conterá o código de uma ou mais linguagens de programação, por exemplo Python.

## 3. Ferramentas

| **Ferramenta**     | **Descrição**                                                                                                                                     |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Git/Github         | Sistema de versionamento em nuvem.                                                                                                                |
| Python             | Linguagem de programação utilizada para o desenvolvimento do projeto.                                                                             |
| Gitbook            | O *gitbook* é um gerador de sites com base em arquivos *markdown.*                                                                                |
| Zenhub             | Ferramenta para controle e distribuição de *issues*/histórias.                                                                                    |
| Atom               | Editor de Texto.                                                                                                                                  |
| Pip                | *Pip* é um sistema de gerenciamento de pacotes usado para instalar e gerenciar pacotes de software escritos na linguagem de programação *Python*. |
| SQLite3/Python     | Biblioteca para gerenciamento de banco de dados SQLite.                                                                                           |
| SQLAlchemy Migrate | fornece uma maneira de lidar com mudanças no esquema do banco de dados em projetos SQLAlchemy.                                                    |

## 4. Políticas

### 4.1 Política de Contribuição na Documentação(GitBook)

&#x20;Com o intuito de manter a rastreabilidade e controle das alterações feitas no *gitbook* ( gerador de sites com base em arquivos *markdown*) do projeto, o *gitbook* já fornece essa funcionalidade de rastreabilidade através de uma integração com o *github*, onde para cada modificação realizada em certo documento é gerado um *commit* em nosso repositório, dedicado a armazenar esses documentos gerados no *gitbook.*&#x20;

### 4.2 Política de Commits

Os *commits* devem ser atômicos, representando uma funcionalidade ou parte dela. A mensagem deve descrever o que foi produzido, de forma sucinta. Além disso, o *commit* deverá ser em inglês.

### 4.3 Política de *Branches*

Haverá apenas um repositório com uma branch principal (master) e uma branch auxiliar de desenvolvimento (devel). Será necessária a criação de branches auxiliares para o desenvolvimento de cada história de usuário ou história técnica, essas serão ramificações da devel. Após o término da funcionalidade, os desenvolvedores responsáveis deverão mesclar o conteúdo da *branch* auxiliar na qual a funcionalidade foi desenvolvida com a branch auxiliar de desenvolvimento (devel). Essa tarefa deve ser realizada com o comando merge. A funcionalidade deverá ser integrada a master através do pull request, onde o qualidade do código será analisada.

### 4.4 Política de Aprovação do Código

&#x20;O código será aprovado caso seja funcional e siga todas as especificações da folha de estilo com a aplicação das técnicas de programação, tais como: identação, presença de loggings, comentários, ou seja, o uso de programação defensiva. Além disso o código deverá conter uma cobertura de testes mínima determinada pelo time, assim como, satisfazer todos os requisitos das ferramentas de análise de código. O Scrum Master da sprint em questão deverá revisar o código presente em cada pull request. Caso não obedeça às regras e não seja explicado o não uso de uma das especificações estabelecidas acima o **Scrum Master deverá recusar o pull request** a branch mastere voltar a branch devel para a última versão estável.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://lorembot.gitbook.io/docs/planos-do-projeto/plano-de-gerencia-e-configuracao-de-software.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
