Ir para o conteúdo principal

SUSIE - Cadastrar Programa de Autocontrole

Data: 31/01/21

Autores:

  1. João Cícero Romão Gomes de Oliveira
  2. Raaby Liandry de Souza Teixeira
  3. Henrique dos Santos Oliveira
1. Objetivo

Descrever o processo de análise e indicar a melhor alternativa para implantação da USER STORY “Eu como fiscal, preciso finalizar meu checklist de vistoria de estabelecimento construído”.

Após realização do último Grooming, o time de desenvolvimento identificou que  a complexidade dessa user story é muito alta para implantação de maneira manual, sendo necessário um estudo aprofundado para desenvolver habilidades técnicas no time, tornando-os capazes de adicionar as informações de maneira automatizada.

2. Introdução
  1. Relatório contendo a análise da viabilidade de implantação do Laudo de Vistoria de Estabelecimento Construído no sistema Susie de maneira automatizada.
  2. Simulação para um pequeno conjunto de dados (e.g. 1 sessão com suas respectivas perguntas)
  3. Ademais, espera-se a a definição de qual a estratégia será adotada para a implantação da solução além da elucidação da complexidade técnica inerente a todas as tarefas associadas ao processo de desenvolvimento da mesma.
2.1 Premissas
  1. A GIPOA disponibiliza 1 checklist para cada tipo de estabelecimento (carne, ovos, leite, mel e pescado)
  2. O Checklist de verificação para estabelecimento de OVOS E DERIVADOS (por exemplo) contém 433 questões
  3. De acordo com o objetivo proposto, esta análise se encerra quando o FISCAL submete as respostas.
3. Desenvolvimento

Após reunião de planejamento de desenvolvimento de atividades, foram identificadas quatro abordagens possíveis para a implantação de uma solução que atenda a User Story presente no objetivo deste documento.

A seguir são descritas essas quatro abordagens, sendo destacadas quais as ações associadas são necessárias para a implantação da User Story, seguidas de um estudo da complexidade envolvida com o processo de desenvolvimento de cada uma dessas ações. Os valores de complexidade foram atribuídos as ações após reunião entre os participantes do time.

3.1 Inserção Manual na Aplicação + Criação Manual do FrontEnd

  • Ações associadas
    • Inserir perguntas manualmente no backend (0,05 PPP)
    • Inserir perguntas com opções no frontend(0,05 PPP)
    • Capturar respostas do Fiscal (5 pontos)
    • Validar preenchimento de Campos obrigatórios(1 pontos)
  • Complexidade - constante para cada questão adicionada. Considerando C(n) = n*(PPP_BACK + PPP_FRONT), teríamos 43,3 pontos de complexidade para adicionar as questões ao checklist de ovos e derivados, totalizando C = 49,3 pontos para a atividade completa.

3.2 Inserção automatizada no BackEnd (JSON/SQL) + Criação Manual do FrontEnd

  • Ações associadas
    • Converter do Word p/ .CSV (1 ponto)
    • Exportar .CSV para SQL/JSON (1 ponto)
    • Carregar SQL/JSON na aplicação (2 pontos)
    • Inserir perguntas manualmente no frontend (0,05 PPP) - (22,15 pontos)
    • Capturar respostas do Fiscal (5 pontos)
    • Validar preenchimento de Campos obrigatórios (1 ponto)
  • Complexidade - considerando a complexidade a soma de todas as ações associadas, logo teríamos C=32,15.

3.3 Inserção automatizada no BackEnd (JSON/SQL) + Geração automática no FrontEnd

  • Ações associadas
    • Converter do Word p/ .CSV (1 ponto)
    • Exportar .CSV para SQL/JSON (1 ponto)
    • Carregar SQL/JSON na aplicação (2 pontos)
    • Gerar estrutura do frontend (3 pontos)
    • Capturar respostas do Fiscal (5 pontos)
    • Validar preenchimento de Campos obrigatórios (1 ponto)
  • Complexidade - considerando a complexidade a soma de todas as ações associadas, logo teríamos C = 13 pontos.

3.4 Implantação de um Sistema de Gerenciamento

  • Ações associadas
    • Permitir à GIPOA Criar Formulário (3 pontos)
    • Permitir à GIPOA Editar Formulário (2 pontos)             
    • Permitir à GIPOA Inativar Formulário (3 pontos)            
    • Permitir à GIPOA Criar Agrupamentos (2 pontos)           
    • Permitir à GIPOA Ordenar Agrupamentos (2 pontos)        
    •  Permitir à GIPOA Criar Perguntas (2 pontos)           
    • Permitir à GIPOA Editar Perguntas (2 pontos)            
    • Permitir à GIPOA Inativar Perguntas (2 pontos)          
    • Permitir à GIPOA Ordenar Perguntas (2 pontos)        
    • Permitir à GIPOA Definir tipo de Pergunta (3 pontos)       
    • Vincular formulários às Solicitações/Vistorias (terreno, estabelecimento, rótulo,...) (2 pontos)    
    • Capturar respostas do Fiscal (5 pontos)
    • Validar preenchimento de Campos obrigatórios (3 pontos)
  • Complexidade - considerando a complexidade como a somatória de todas as ações associadas, logo, teríamos C = 33 pontos de complexidade.

3.5 Exemplo

Para exemplificar a inserção automatizada no banco de dados, é simulada a geração do primeiro conjunto de questões do RELATÓRIO DE VISTORIA EM ESTABELECIMENTO DE OVOS E DERIVADOS.

Tabela 1. Trecho do relatório utilizado para simulação

image.png

Identificada a necessidade de portar esses dados para um formato aberto e de fácil manipulação, optou-se pela utilização do formato .csv (comman separeted values). Após converter o arquivo para o formato em questão, utilizou-se uma ferramenta para preparar os dados para a inserção em um banco de dados, convertendo-os para SQL, conforme Tabela 2.

Tabela 2. Código em SQL gerado, dados preparados para serem inseridos no banco de dados

CREATE TABLE laudo_demo( questao VARCHAR(265) NOT NULL PRIMARY KEY );
INSERT INTO laudo_demo(questao) VALUES ('1. ÁREA EXTERNA');
INSERT INTO laudo_demo(questao) VALUES ('1.1 Delimitação do estabelecimento impede entrada de pessoas estranhas/animais (cercas, portões)?');
INSERT INTO laudo_demo(questao) VALUES ('1.2 Ausência de lixo, objetos em desuso, animais, insetos e roedores?'); INSERT INTO laudo_demo(questao) VALUES ('1.3 Perímetro industrial adequadamente pavimentado, limpo e com escoamento de águas adequado e/ou com áreas de paisagismo para evitar formação de poeira no trânsito de veículos transportadores de produtos?');
INSERT INTO laudo_demo(questao) VALUES ('1.4 Ausência de residências/moradias no perímetro industrial?'); INSERT INTO laudo_demo(questao) VALUES ('1.5 Há depósito de lixo adequado?');
INSERT INTO laudo_demo(questao) VALUES ('1.6 Ausência de fontes produtoras de mau cheiro?');
INSERT INTO laudo_demo(questao) VALUES ('1.7 Ausência de trânsito interno de veículos, com exceção dos veículos transportadores de produtos?');

Os dados foram preparados para a inserção utilizando uma ferramenta online e gratuita de conversão de dados separados por virgula em SQL, a ferramenta CONVERTCSV https://www.convertcsv.com/csv-to-sql.htm . Na Figura 1, podemos confirmar a inserção dos dados no banco.

image.png

Figura 1. Exemplo de dados inseridos no banco de dados

3.6 Resultados

Na Tabela 3 é apresentado um comparativo entre as alternativas propostas para a implantação da User Story descrita no objetivo deste documento. Entende-se que quanto mais alta a complexidade ( C(n) ) , maior o tempo necessário para o desenvolvimento das tarefas associadas.

Com relação aos pontos fortes e fracos, uma maior complexidade técnica e de tempo devem ser evitadas, sendo considerados pontos fracos, quando demasiadas. Busca-se um código com alta sustentabilidade, baixa complexidade técnica e de tempo.

Tabela 3. Comparativo de complexidade (C(n)), pontos fortes e fracos das opções analisadas.

OPÇÃO

C(n)

PONTOS FORTES

PONTOS FRACOS

1

51,3

  • complexidade técnica (-)

  • complexidade de tempo (+)

  • sustentabilidade (-)

2

32,15

  • complexidade técnica (-)

  • complexidade de tempo (+)

3

13

  • complexidade de tempo (-)

  • sustentabilidade (+)

  • complexidade técnica (+)

4

33

  • complexidade técnica (-)

  • sustentabilidade (+)

  • complexidade de tempo (+)

  • fora do escopo da aplicação

  • grande trabalho ao cliente

  • cenários desconhecidos
4. Conclusão

Após análise da complexidade técnica, complexidade de tempo, sustentabilidade do código-fonte das alternativas propostas para a implantação da User Story “Eu como fiscal, preciso finalizar meu checklist de vistoria de estabelecimento construído”, fica definido entre as partes envolvidas que a implantação desta história será feita a partir da proposta número 3, tendo sua complexidade atribuída de 13 pontos, podendo este ser posteriormente alterado em acordo entre as partes.

Para baixar o relatório técnico, acesse o Link: SPIKE - Sprint 51.pdf

Voltar ao topo