SUSIE - Cadastrar Programa de Autocontrole

 implantação

2.1. 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.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.2. 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.2.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.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.2.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.2.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.2.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

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.

Figura 1. Exemplo de dados inseridos no banco de dados

3.2.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.

4.3. 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