# [BETA] Processo: Análise de complexidade

Neste capítulo, são feitas considerações à respeito da análise para definição da complexidade de um caso.

To-do: 
Definir processo.
Concluir/Revisar considerações gerais.
Concluir revisões conjuntas.

# Considerações Gerais

### **Tópicos considerados**

Durante o processo de análise para definir a complexidade de um caso, alguns pontos devem ser levados em consideração:

##### **Tipo de alteração**

1. **Alteração apenas "adicional"**  
    A alteração feita no caso é considerada uma implementação adicional quando não é alterado nenhum processo já existente, apenas acrescentada uma nova condição para um processo que já existe ser executado.
2. **Alteração adicional com ressalvas**  
    Uma alteração é considerada adicional com ressalvas quando, é adicionada uma condição para a execução de um processo já existente, entretanto, esse processo necessita de adaptações para a condição adicionada.
3. **Implementação de um processo**  
    Uma alteração onde existe a implementação de um processo antes não existente, é uma alteração de implementação.

##### **Categorias de Complexidade:**

**Baixa (1)**

- Alteração de relatórios;
- Alterações meramente visuais;
- Categorias de erros de baixa complexidade: 
    - "Field not found";
    - "Index out of bound";
    - "Focar em campo invisível";
    - "Erros de estado da query";
- Modificações nos eventos mais comuns dos componentes: 
    - OnExit;
    - OnClick;
    - OnEnter;
    - OnDlgClick;
    - OnChange;

**Média (2)**

- Cláusulas extensas com inúmeros JOIN, funções de agregações, etc;
- Criação de campos e tabelas;
- Métodos/Funções de Rotinas Comuns;
- Criação/Implementação de relatórios;
- Modificações nos eventos dos componentes: 
    - OnKeyDown;
    - OnKeyPress;
    - OnKeyUp;

**Alta (3)**

- Eventos de componentes do tipo TFDQuery;
- Eventos de componentes não citados na complexidade anterior;
- Rotinas de transmissão (específica por módulo: SPED, eSocial, notas em geral);
- Rotinas de Integração entre sistemas;

Estabelecer prazo "máximo" antes de marcar pessoas do nível de complexidade "pedindo" revisão

# Revisões Conjuntas

### **Definição**

Para maior assertividade nas revisões feitas, as revisões feitas dessa maneira, são realizadas por dois desenvolvedores conjuntamente. Onde contará com um desenvolvedor "especialista" do sistema (**Dev 1**), ou seja, que trabalha ou trabalhou na manutenção do sistema em questão e que possui conhecimento intermediário/avançado das rotinas alteradas que serão revisadas. A revisão também será composta por outro desenvolvedor (**Dev 2**), que não conhece propriamente os processos alterados do sistema e que será auxiliado/guiado pelo Dev 1.

### **Como funciona**

A revisão conjunta visa incentivar e proporcionar o intercâmbio de conhecimento entre o Dev 1 e o Dev 2 do caso, para que isso seja efetivo, é necessário que o Dev 2 vivencie toda a rotina do processo em questão no caso e que consiga reproduzir a situação relatada no caso com o auxílio do Dev 1.