UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE … · desenvolvimento de um Sistema Integrado de...

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

UNIDADE ACADÊMICA ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS

LARYSSE SAVANNA IZIDIO DA SILVA

SISTEMA INTEGRADO DE GESTÃO DE UNIDADES DE ALIMENTAÇÃO E

NUTRIÇÃO

Módulo de Criação e Prescrição de Cardápios

Macaíba, RN

2018

Larysse Savanna Izidio da Silva


NUTRIÇÃO


Trabalho de conclusão de curso de graduação

apresentado à Unidade Especializada em Ciências

Agrárias – Escola Agrícola de Jundiaí da

Universidade Federal do Rio Grande do Norte como

requisito parcial para a obtenção do título de

Tecnóloga em Análise e Desenvolvimento de

Sistemas.

Orientador: Prof. Dr. Taniro Chacon Rodrigues

Coorientadora: Ma. Taiana Brito Menêzes Flor

Macaíba, RN

2018

Universidade Federal do Rio Grande do Norte - UFRN

Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede – Escola Agrícola de Jundiaí - EAJ

Silva, Larysse Savanna Izidio da.

Sistema integrado de gestão de unidades de alimentação e

nutrição / Larysse Savanna Izidio da Silva. - 2018.

80 f.: il.

Monografia (graduação) - Universidade Federal do Rio Grande do

Norte, Unidade Especializada em Ciências Agrárias, Curso de

Tecnologia em Análise e Desenvolvimento de Sistemas. Macaíba, RN,

2018.

Orientador: Prof. Dr. Taniro Chacon Rodrigues.

Coorientadora: Profª. Ma. Taiana Brito Menêzes Flor.

1. Sistema de informação gerencial (SIG) - Monografia. 2.

Nutrição - Monografia. 3. Unidade de alimentação e nutrição (UAN)

- Monografia. 4. Alimentação coletiva - Monografia. I. Rodrigues,

Taniro Chacon. II. Flor, Taiana Brito Menêzes. III. Título.

RN/UF/BCZM CDU 681.5:612.39

Larysse Savanna Izidio da Silva


NUTRIÇÃO


Trabalho de conclusão de curso de graduação apresentado à Unidade Especializada em Ciências

Agrárias – Escola Agrícola de Jundiaí da Universidade Federal do Rio Grande do Norte como

requisito parcial para a obtenção do título de Tecnóloga em Análise e Desenvolvimento de

Sistemas.

Aprovado em: ____ de _______ de _____.

BANCA EXAMINADORA

__________________________________________

Prof. Dr. Taniro Chacon Rodrigues – EAJ/UFRN - Orientador

__________________________________________

Ma. Taiana Brito Menêzes Flor - EAJ/UFRN - Coorientadora

__________________________________________

Profª. Drª Laura Emmanuella Alves dos Santos Santana de Oliveira – EAJ/UFRN

__________________________________________

Prof. Dr. Eiji Adachi Medeiros Barbosa- IMD/UFRN

DEDICATÓRIA

Dedico este trabalho primeiramente à Deus, por estar sempre presente em minha vida, aos

meus pais, meus irmãos, amigos e professores que me deram todo o apoio nessa jornada de

desafios e aprendizado.

AGRADECIMENTOS

Agradeço primeiramente à Deus por estar sempre me guiando, dando força e coragem

para seguir em frente e dar sempre o meu melhor.

Agradeço à minha família por acreditar em mim e investir no meu futuro. Aos meus

pais, Cícero Vicente e Edineuza Izidio, por serem pais amorosos e dedicados. Aos meus

irmãos, Luiz Gustavo e Luzyana Izidio, agradeço por me proporcionarem tantos momentos de

alegria e por entenderem nas vezes em que não pude estar presente.

Agradeço a todos os meus amigos que me acompanharam na minha trajetória, em

especial: Íris, Iaslan, Arthur, Joffrey, Washi, Eric, Babi, Joel e Rayane que também se

tornaram família e trouxeram tantos momentos bons que tornaram a minha vida acadêmica

mais leve. Agradeço também a todos os amigos do Laboratório UBICOMP e dos demais

laboratórios do TAPIOCA, em especial aos meus irmãos acadêmicos: Fábio Henrique por

todas as brincadeiras e disputas sobre quem era o filho preferido e Assis Lucas por dividir

comigo os momentos de preocupação com a Monografia. Agradeço também a aos amigos

Tuany Mariah e Lucas Andrade por todo apoio e incentivo.

Agradeço a todos os meus professores e orientadores por todo o conhecimento que

adquiri tanto em sala de aula, quanto fora dela nos diversos projetos que tive o prazer de

participar. Um agradecimento especial ao meu orientador, professor e amigo Taniro

Rodrigues por todos os ensinamentos e diversos conselhos que, sem dúvidas, foram essenciais

para que eu chegasse onde cheguei. Agradeço por toda a compreensão, puxões de orelha e por

me ensinar que “é preciso dividir para conquistar” sempre que teimei em querer carregar o

mundo nas costas (risos). Obrigada por me servir de exemplo e por contribuir tanto para o

meu crescimento acadêmico e profissional. Agradeço a minha coorientadora Taiana Menezes

que me acompanhou desde o início da graduação até o final, com quem aprendi bastante sobre

a área de Nutrição. Agradeço também ao Prof. Márcio Dias, que me orientou no meu primeiro

projeto da graduação e foi o primeiro a acreditar no meu potencial, que também teve grande

contribuição para a minha vida acadêmica e por quem tenho um carinho enorme. Agradeço

também a Profª Laura Emmanuella e ao Prof. Helder Pacheco por todo o carinho.

Agradeço a EAJ e UFRN por todo apoio dado ao desenvolvimento deste trabalho.

We are only as strong as we are united, as weak as we are divided.

- Albus Dumbledore

RESUMO

O desenvolvimento da tecnologia da informação tem proporcionado a criação de novas

soluções para auxiliar na gestão de organizações públicas e privadas. As Unidades de

Alimentação e Nutrição (UAN) são responsáveis pela produção e distribuição de refeições a

grupos de pessoas em diferentes tipos de estabelecimentos. A UAN possui um processo de

operacionalização complexo e o nutricionista deve gerenciar desde a estrutura física,

equipamentos e funcionários até o planejamento, execução e avaliação de cardápios entre

diversas outras atividades. Esses fatores dificultam o gerenciamento das UANs, tornando seu

funcionamento mais complexo, dependendo da quantidade e tipo de refeições produzidas.

Tendo em vista essa problemática, o objetivo dessa Monografia é apresentar o

desenvolvimento de um Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição

(SIGUAN) que visa auxiliar o nutricionista na elaboração e prescrição de cardápios e nas

atividades de gestão da UAN. O SIGUAN teve sua arquitetura planejada com base no modelo

4+1 e foi desenvolvido com base no estilo arquitetural REST. Suas funcionalidades vão desde

a criação e prescrição de cardápios até o gerenciamento de insumos, preparações, estoque e

salas de preparação, que são partes comumente presentes nas UANs. A avaliação deste

trabalho foi realizada através da execução de um experimento controlado elaborado com base

em métodos propostos por diferentes autores, um deles foi o método GQM. Nesse

experimento o SIGUAN foi avaliado em termos de usabilidade, utilidade e produtividade em

comparação com a abordagem tradicional de criação e prescrição de cardápios utilizando o

Excel. Os resultados da avaliação mostraram que o SIGUAN atingiu os objetivos almejados.

Palavras-chave: SIG, Sistema de Informação, UAN, Alimentação Coletiva.

ABSTRACT

The information technology development has provided the creation of new solutions to assist

in the management of public and private organizations. The Food and Nutrition Units (UAN)

are responsible for the production and distribution of food to groups of people in different

types of establishments. The UAN has a complex operation process and the nutritionist must

manage everything from the physical structure, equipment and employees to the planning,

execution and evaluation of menus in addition to several other activities. These factors make

the UANs management difficult, making their operation more complex, depending on the

quantity and type of meals produced. In view of this problem, the purpose of this Monograph

is to present the development of an Integrated Management System for Food and Nutrition

Units (SIGUAN), which aims to assist the nutritionist in menus elaboration and prescribing

and in the UAN’s activities management. SIGUAN architecture was planned based on the 4 +

1 model and it was developed based on the REST architectural style. Its functionalities range

from the menus creation and prescription to the ingredients, preparations, stock and

preparation rooms management, which are common parts of UANs. The evaluation of this

work was performed through the execution of a controlled experiment elaborated based on

methods proposed by different authors, one of them was the GQM method. In this

experiment, SIGUAN was evaluated in terms of usability, utility and productivity compared

to the traditional approach to creating and prescribing menus using Excel. The results of the

evaluation showed that SIGUAN achieved the objectives.

Keywords: SIG, Information System, UAN, Collective Feeding.

LISTA DE FIGURAS

Figura 1. Estrutura de um cardápio semanal. ........................................................................................ 16

Figura 2. Desenvolvimento iterativo e incremental. ............................................................................. 18

Figura 3. Diagrama de Sequência da comunicação entre Cliente e Servidor Web. .............................. 20

Figura 4. Exemplo de componente Vue. ............................................................................................... 22

Figura 5. Reutilização de componentes Vue. ........................................................................................ 22

Figura 6. Ciclo de vida do OpenUP. ..................................................................................................... 23

Figura 7. Modelo arquitetural de visões 4+1. ........................................................................................ 26

Figura 8. Diagrama de Casos de Uso. ................................................................................................... 27

Figura 9. Versão simplificada do Diagrama de Classes do SIGUAN. .................................................. 28

Figura 10. Arquitetura do sistema. ........................................................................................................ 31

Figura 11. Diagrama de implantação. ................................................................................................... 32

Figura 12. Diagrama de atividades da criação de cardápio. .................................................................. 33

Figura 13. Diagrama de atividades da criação de prescrição. ............................................................... 34

Figura 14. Exemplo de requisição de login. .......................................................................................... 35

Figura 15. Exemplo de envio do token. ................................................................................................. 35

Figura 16. Exemplo de solicitação de um insumo utilizando o método HTTP GET. ........................... 36

Figura 17. Exemplo de cadastro de insumo utilizando o método HTTP POST. ................................... 37

Figura 18. Exemplo de alteração dos dados de um insumo utilizando o método HTTP PUT. ............. 37

Figura 19. Exemplo se remoção de insumo utilizando o método HTTP DELETE............................... 38

Figura 20. Exemplo de prescrição de um cardápio. .............................................................................. 39

Figura 21. Template da tela de login do SIGUAN. ............................................................................... 39

Figura 22. Tela de login do SIGUAN. .................................................................................................. 40

Figura 23. Painel de controle do SIGUAN............................................................................................ 41

Figura 24. Tela de cadastro de insumo per capita. ................................................................................ 42

Figura 25. Tela de cadastro de preparação. ........................................................................................... 42

Figura 26. Tela de criação de cardápio.................................................................................................. 43

Figura 27. Tela de prescrição de cardápio. ............................................................................................ 44

Figura 28. Relatório da Cozinha. .......................................................................................................... 44

Figura 29. Nível de conhecimento em Nutrição.................................................................................... 50

Figura 30. Nível de conhecimento em Excel. ....................................................................................... 51

Figura 31. Diagrama de Classes completo. ........................................................................................... 77

LISTA DE TABELAS

Tabela 1. Exemplos de requisições utilizando os métodos HTTP. ....................................................... 21

Tabela 2. Requisitos funcionais. ........................................................................................................... 24

Tabela 3. Requisitos não-funcionais. .................................................................................................... 25

Tabela 4. Descrição do Diagrama de Classes. ....................................................................................... 29

Tabela 5. Tarefas executadas pelos participantes. ................................................................................. 51

Tabela 6. Questionário para a variável de Facilidade de Uso Percebida. .............................................. 54

Tabela 7. Resultados do questionário sobre facilidade de uso percebida. ............................................. 55

Tabela 9. Questionário para a variável de Utilidade Percebida. ............................................................ 55

Tabela 10. Resultados do questionário sobre utilidade percebida. ........................................................ 56

Tabela 12. Duração da execução das tarefas pelos participantes. ......................................................... 56

Tabela 13. Tempo médio de realização das tarefas. .............................................................................. 57

Tabela 14. Dados estatísticos do tempo de duração. ............................................................................. 58

LISTA DE SIGLAS

API - Application Programming Interface

EAJ – Escola Agrícola de Jundiaí

REST - Representational State Transfer

SIG – Sistema Integrado de Gestão

SIGUAN - Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição

UAN – Unidades de Alimentação e Nutrição

UFRN – Universidade Federal do Rio Grande do Norte

SUMÁRIO

1. INTRODUÇÃO .................................................................................................................... 9

1.1 JUSTIFICATIVA ............................................................................................................... 10

1.1.1 ABORDAGEM TRADICIONAL ................................................................................... 12

1.2 VISÃO GERAL DO TRABALHO .................................................................................... 12

1.3 OBJETIVOS ....................................................................................................................... 13

1.3.1 OBJETIVO GERAL ........................................................................................................ 13

1.3.2 OBJETIVOS ESPECÍFICOS .......................................................................................... 13

1.4 ORGANIZAÇÃO DO TRABALHO ................................................................................. 13

2. CONCEITOS BÁSICOS .................................................................................................... 15

2.1 PLANEJAMENTO E PRESCRIÇÃO DE CARDÁPIOS NA UAN ................................. 15

2.2 SISTEMAS DE INFORMAÇÃO ....................................................................................... 17

2.3 PROCESSO UNIFICADO ................................................................................................. 17

2.4 ARQUITETURA ORIENTADA A SERVIÇOS (SOA) ................................................... 19

2.5 SERVIÇO WEB ................................................................................................................. 19

2.6 REST .................................................................................................................................. 20

2.7 VUE.JS ............................................................................................................................... 21

3. DESENVOLVIMENTO ..................................................................................................... 23

3.1 INICIAÇÃO ....................................................................................................................... 23

3.2 ELABORAÇÃO ................................................................................................................. 25

3.2.1 VISÕES 4+1 .................................................................................................................... 26

3.2.2 VISÃO DE CASOS DE USO ......................................................................................... 26

3.2.3 VISÃO LÓGICA ............................................................................................................. 28

3.2.4 VISÃO DE IMPLEMENTAÇÃO ................................................................................... 30

3.2.5 VISÃO DE IMPLANTAÇÃO ........................................................................................ 32

3.2.6 VISÃO DE PROCESSOS ............................................................................................... 33

3.3 CONSTRUÇÃO ................................................................................................................. 34

3.4 TRANSIÇÃO ..................................................................................................................... 45

4. AVALIAÇÃO ..................................................................................................................... 46

4.1 OBJETIVOS DA AVALIAÇÃO ....................................................................................... 46

4.2 QUESTÕES ........................................................................................................................ 46

4.3 MÉTRICAS ........................................................................................................................ 47

4.4 PLANEJAMENTO ............................................................................................................. 49

4.5 PARTICIPANTES ............................................................................................................. 50

4.6 TAREFAS .......................................................................................................................... 51

4.7 ROTEIRO DO EXPERIMENTO ....................................................................................... 52

4.8 HIPÓTESES ....................................................................................................................... 53

4.9 ANÁLISE DOS RESULTADOS ....................................................................................... 54

4.10 ANÁLISE DAS MÉTRICAS ........................................................................................... 58

4.11 AMEAÇAS À VALIDADE DO EXPERIMENTO ......................................................... 60

5. CONCLUSÃO ..................................................................................................................... 62

5.1 TRABALHOS FUTUROS ................................................................................................. 62

REFERÊNCIAS ..................................................................................................................... 64

APÊNDICE A – DETALHAMENTO DE CASOS DE USO .............................................. 67

APÊNDICE B – DIAGRAMA DE CLASSES COMPLETO ............................................. 77

9

1. INTRODUÇÃO

Com o desenvolvimento da Tecnologia da Informação, as empresas, instituições e

organizações públicas e privadas estão adotando cada vez mais o uso de novas tecnologias

para auxiliar na gestão devido à complexidade de suas atividades, funcionamento de

processos, envolvimento de pessoas, entidades externas e a manipulação de diversas

informações. Entre as tecnologias mais utilizadas encontram-se os Sistemas de Informação

que, no ambiente das organizações, são todos os sistemas que coletam, processam,

armazenam, analisam e distribuem informações para execução de ações e para auxiliar no

processo de tomadas de decisões, na organização e no controle de uma organização

(WAKULICZ, 2016).

A adoção dos Sistemas de Informação tem afetado significativamente o modo como

essas organizações realizam suas atividades, como as tarefas que antes eram executadas de

forma manual e atualmente são realizadas de forma automática, proporcionando mais

praticidade e rapidez. Entre os diversos tipos de Sistemas de Informação, encontram-se os

Sistemas Integrados de Gestão (SIG) que permitem a integração de várias áreas de uma

organização, aumentando a confiabilidade e a produtividade. Ao utilizar um SIG, diversos

setores como estoques, produção, logística, compras, entre outros, podem trabalhar e

desenvolver-se de forma integrada. (FERRO, 2016). Dessa forma, a organização como um

todo pode trabalhar de forma mais eficiente e obter melhores resultados. Outra vantagem dos

SIGs é a possibilidade de obter um maior controle do processo de trabalho, gerar informações

em tempo hábil, diminuir os custos e controlar os setores. Tais características impactam na

redução dos possíveis erros que podem ocorrer durante a gestão. Uma potencial aplicação

para esse tipo de sistema ocorre nas organizações que prestam serviços de saúde, como, por

exemplo, na área de Nutrição.

O campo da Nutrição possui diversas áreas de atuação, entre elas encontra-se a de

Alimentação Coletiva onde o nutricionista atua no planejamento e no controle da qualidade de

refeições, no treinamento de funcionários, na administração de custos, entre diversas outras

atividades. Além disso, o nutricionista deve supervisionar e avaliar os serviços prestados pelas

Unidades de Alimentação e Nutrição (UAN), que são responsáveis pela produção e

distribuição de refeições a grupos de pessoas em diferentes tipos de estabelecimentos

(CAMPOS et al, 2016). As UANs possuem uma estrutura organizacional linear, caracterizada

por unidade de comando, representada por um nutricionista responsável e um número

reduzido de níveis hierárquicos. Esses fatores dificultam o gerenciamento das unidades de

10

alimentação, tornando seu funcionamento mais complexo, dependendo da quantidade e tipo

de refeições produzidas (COLARES, 2007COLARES).

O nutricionista é o profissional responsável por gerenciar uma equipe de funcionários,

bem como a estrutura física, equipamentos, planejamento, execução e avaliação de cardápios,

controle de custos, gestão de suprimentos entre diversas outras atividades que são de grande

importância para o funcionamento adequado da UAN (CONSELHO FEDERAL DE

NUTRICIONISTAS, 2018). Muitas dessas atividades são executadas de forma simultânea,

tornando a rotina de trabalho nas UANs bastante intensa. Os cardápios normalmente são

planejados com antecedência e compostos das receitas, também chamadas pelos especialistas

da área, os nutricionistas, de preparações, que serão servidas. É necessário especificar quais

ingredientes, ou insumos, serão utilizados para cada preparação. Para isso, deve-se especificar

a quantidade de insumos per capita, ou seja, a quantidade necessária de insumos para apenas

uma pessoa, e então calcular a quantidade necessária de insumos para as refeições que

compõem o cardápio de um dia (café da manhã, almoço, jantar, etc.) de acordo com a

quantidade prevista de usuários que irão consumir os alimentos, ou comensais. As

informações relacionadas aos funcionários, estoque, refeições, público externo, etc., são de

grande importância para o gerenciamento de uma UAN devido à complexidade das atividades

do nutricionista. O acesso a essas informações de forma ágil e prática é fundamental para

obter mais eficiência.

Nesse contexto, a utilização de um SIG para integrar diferentes áreas de uma

instituição tem grande potencial para melhoria do uso de recursos, sejam eles físicos, como

insumos, salas etc., ou de pessoal, como o nutricionista e demais funcionários envolvidos.

Com o uso de um único sistema para integrar todos os setores de uma UAN, ou pelo menos os

setores mais importantes, a comunicação interna se torna mais fácil e prática. Por exemplo, o

setor de estoque pode identificar rapidamente a quantidade de insumos que serão levados para

as salas de preparação de acordo com as informações que o setor de nutrição disponibiliza no

sistema. O nutricionista pode identificar a quantidade necessária de cada ingrediente para as

preparações com base na média de refeições servidas diariamente.

1.1 JUSTIFICATIVA

Devido a variação frequente do número de usuários que são atendidos diariamente nas

UANs, o processo de planejamento de refeições e cardápios se torna exaustivo e demanda

bastante tempo por exigir uma manipulação de per capitas e somatório de insumos que se

repetem nas preparações para solicitação diária de retirada de itens da despensa. Diante disso,

11

o uso de ferramentas computacionais como os Sistemas de Informação pode contribuir para a

diminuição do tempo gasto em uma única tarefa, disponibilizando mais tempo para as outras

atividades de gestão das UANs e reduzindo sua complexidade.

Existem no mercado diversos softwares destinados à prescrição de cardápios

individuais para acompanhamento clínico, porém, há uma escassez de ferramentas destinadas

à gestão de restaurantes institucionais.

O SchoolMeals (desenvolvido pela Teknisa) é um sistema voltado para a gestão de

merendas escolares e é destinado a empresas do ramo de alimentação escolar e a prefeituras

que desejam administrar de forma centralizada a produção e distribuição de alimentos usados

no preparo das refeições dos estudantes. O programa auxilia na redução do desperdício de

alimentos e permite o cadastro de produtos adquiridos para as merendas e a elaboração dos

cardápios que serão servidos nas escolas abastecidas. Para o controle do estoque, é necessário

instalar um aplicativo que é integrado ao sistema da central de merendas para

compartilhamento dos dados, assim a prefeitura consegue saber os alimentos que estão em

falta, o consumo médio de cada escola e determinar qual deve ser a velocidade média da

reposição. Apesar de auxiliar na elaboração de cardápios e no gerenciamento do estoque, essa

ferramenta é voltada apenas para o ambiente escolar, portanto a sua utilização em outros tipos

de UAN (como restaurantes de hospitais) se torna inviável, além de ser uma ferramenta

comercial e não se tratar de uma ferramenta aberta, o que impossibilita a expansão de suas

funcionalidades.

O Dietpro Clínico (desenvolvido pela Dietpro) é um software desenvolvido para

auxiliar o nutricionista no atendimento clínico. A ferramenta facilita o gerenciamento dos

pacientes e a realização de atividades como avaliações nutricionais, cálculos energéticos,

prescrição do plano alimentar e elaboração de cardápios individuais e modelos de dietas. Por

se tratar de um produto, a comercialização do Dietpro Clínico é disponibilizada apenas na

forma de instalação, onde cada uma apresentará características relacionadas a sua condição de

liberação e ao perfil do cliente.

O sistema TecDiet (desenvolvido pela Teknisa) é uma ferramenta que foi

desenvolvida para auxiliar no controle da produção, distribuição e custos das refeições

hospitalares. Suas funcionalidades vão desde a elaboração de refeições e avaliação dos custos

da produção até a realização de avaliação nutricional dos pacientes. Uma característica desse

software é a possibilidade de elaborar cardápios para o paciente de acordo com seu estado

nutricional, permitindo também o acesso rápido a informações como restrições, intolerância

alimentar e interação droga-nutriente no cardápio de cada paciente. Apesar de auxiliar na

12

elaboração de cardápios e no controle do estoque, o sistema não permite gerenciar alguns dos

principais setores de uma UAN como salas de preparação, equipamentos e funcionários.

1.1.1 ABORDAGEM TRADICIONAL

A UAN utilizada como modelo para a execução deste projeto foi o Restaurante

Universitário (RU) da Escola Agrícola de Jundiaí (EAJ) da Universidade Federal do Rio

Grande do Norte (UFRN). No processo de planejamento e criação de cardápios dessa UAN,

os funcionários que executam as operações precisam saber toda a listagem de ingredientes e

informações necessárias para que o que foi planejado seja de fato executado. O número de

refeições varia de acordo com a quantidade de usuários da UAN, portanto há uma

preocupação diária com a otimização dos recursos. Dessa forma, não é possível trabalhar com

receitas padronizadas, pois diariamente é preciso fazer ajustes para o número de usuários

esperado. A atividade de determinar os ingredientes que vão em cada preparação é

denominada Prescrição.

A prescrição de um cardápio é feita no RU da EAJ por meio de planilhas de Excel,

havendo a necessidade diária de analisar o número de refeições e fazer constantes ajustes em

função do grau de maturação de frutas e hortaliças ou vencimento de produtos, o que

impossibilita o nutricionista trabalhar de maneira estática com quantidades pré-definidas.

Tendo em vista o cenário apresentado, o presente trabalho é proposto com o intuito de

oferecer uma ferramenta que permite gerenciar os principais setores da UAN (citados

anteriormente), que agilize o trabalho do nutricionista permitindo que os principais setores da

UAN trabalhem de forma integrada e eficiente. Além de ser uma ferramenta livre, o sistema

desenvolvido neste trabalho permite que todas as suas funcionalidades sejam expandidas, o

que se torna mais um diferencial em relação aos sistemas já existentes. Essa possibilidade de

expansão das funcionalidades ocorre pelo fato das funcionalidades do sistema estarem

disponíveis através de uma API (Application Programming Interface) aberta disponibilizada

de maneira pública.

1.2 VISÃO GERAL DO TRABALHO

O Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição (SIGUAN) é

composto de um conjunto de módulos, onde cada módulo é responsável por gerenciar um

determinado conjunto de tarefas da UAN. O foco deste trabalho é o Módulo de Criação e

Prescrição de Cardápios, responsável por auxiliar o nutricionista no processo de planejamento

e execução de cardápios da UAN.

13

O SIGUAN surgiu de um projeto de extensão aplicado na EAJ da UFRN. O

desenvolvimento do sistema completo contou com a participação de 6 alunos do curso de

Análise e Desenvolvimento de Sistema com a colaboração de professores do curso e

nutricionistas do Restaurante Universitário da EAJ.

A solução proposta foi desenvolvida de forma a atender às necessidades do

profissional de nutrição no gerenciamento da UAN, principalmente nas atividades de

planejamento de cardápios. As ferramentas utilizadas na implementação foram escolhidas

com o intuito de facilitar o desenvolvimento e o trabalho dos integrantes do projeto.

1.3 OBJETIVOS

Nas subseções seguintes serão apresentados o objetivo geral e os objetivos específicos.

1.3.1 OBJETIVO GERAL

O objetivo deste trabalho é propor e implementar um sistema de apoio ao nutricionista

no planejamento e prescrição de cardápios e no gerenciamento de Unidades de Alimentação e

Nutrição.

1.3.2 OBJETIVOS ESPECÍFICOS

Como objetivos específicos podem ser citados:

• Elaboração de um modelo de sistema útil e que aumente a produtividade do

profissional de nutrição no processo de planejamento e prescrição de

cardápios;

• Implementação da API e serviços para manipulação dos dados;

• Construção do Módulo de Elaboração e Prescrição de Cardápios;

• Construção do Módulo de Geração de Relatórios;

• Construção do Módulo de Interface Web de fácil utilização.

1.4 ORGANIZAÇÃO DO TRABALHO

O restante deste trabalho está organizado da seguinte forma:

• O Capítulo 2 apresenta os conceitos básicos para este trabalho;

• O Capítulo 3 descreve a arquitetura e todo o processo de desenvolvimento do

sistema;

14

• O Capítulo 4 descreve como este trabalho foi avaliado;

• O Capítulo 5 apresenta as conclusões e perspectivas de trabalhos futuros.

15

2. CONCEITOS BÁSICOS

Este Capítulo apresenta os conceitos básicos acerca das abordagens e tecnologias

utilizadas para o desenvolvimento do SIGUAN, assim como conceitos relacionados à área de

nutrição no contexto das UANs. O Capítulo 2 está organizado da seguinte forma: a Seção 2.1

que descreve os principais conceitos relacionados ao planejamento e prescrição de cardápios

em uma UAN; a seção 2.2 que apresenta o conceito de Sistemas de Informação; a seção 2.3

que descreve o Processo Unificado de desenvolvimento de software; a seção 2.4 que

apresenta o conceito da Arquitetura Orientada a Serviços; a Seção 2.5 descreve o que são e

como funcionam os serviços web; a Seção 2.6 apresenta o estilo arquitetural REST adotado

neste trabalho para a criação dos serviços web e, por fim, a Seção 2.7 descreve o framework

Vue.js utilizado para o desenvolvimento para a interface do usuário.

2.1 PLANEJAMENTO E PRESCRIÇÃO DE CARDÁPIOS NA UAN

O nutricionista é o profissional habilitado para atuar na gestão de pessoas, gestão da

estrutura física, equipamentos e utensílios, planejamento, execução e avaliação de cardápios

mudanças dos processos, nas condições e ambientes de trabalho, etc. O trabalho do

nutricionista, em uma UAN, abrange o monitoramento das boas práticas de produção,

controle higiênico-sanitário da UAN e das refeições oferecidas e o atendimento aos clientes.

Uma Unidade de Alimentação e Nutrição (UAN) envolve um complexo sistema

operacional, com procedimentos que devem ser padronizados, claros e precisos de maneira

que todos os funcionários possam executá-los com rapidez. O principal objetivo da UAN é

fornecer uma alimentação segura, que possa garantir os principais nutrientes necessários para

manter, ou recuperar a saúde de todos aqueles que usufruem do seu serviço (Fonseca, 2012).

No contexto das UANs, o cardápio é composto por menus diários onde em cada

menu são especificadas as refeições de cada dia como, por exemplo: café da manhã, almoço e

jantar. Em cada refeição devem ser especificadas as receitas que serão elaboradas e servidas.

Essas receitas são chamadas de preparações. Para elaborar uma preparação é necessário

definir a quantidade de ingrediente (também chamado de insumo) necessária para uma

pessoa, esse dado é chamado de per capita que equivale ao peso bruto do insumo. É a partir

do per capita que será calculada a quantidade necessária de ingredientes para servir o número

total de usuários previstos para uma determinada refeição. Essa previsão de usuários é

chamada de previsão de comensais. A Figura 1 apresenta a estrutura de um cardápio

semanal da UAN da EAJ.

16

Figura 1. Estrutura de um cardápio semanal.

FONTE: própria da autora.

O ato de determinar o que vai em cada preparação do cardápio e suas respectivas

quantidades é denominado prescrição. Essa determinação é baseada no cálculo da

quantidade necessária de insumos para uma preparação, esse cálculo é feito da seguinte

forma:

Q = PC*P

Onde:

Q = Quantidade total necessária de insumo.

PC = Valor do peso bruto per capita do insumo.

P = Previsão de comensais.

Cada colaborador da UAN tem sua rotina de trabalho determinada. Alguns são

designados para manipular os vegetais, outros as carnes, outros sobremesas e sucos, além do

cozinheiro, profissional responsável pela cocção e finalização das preparações. Os

funcionários que irão executar as operações precisam saber toda a listagem de ingredientes e

informações necessárias para que o que foi planejado seja de fato executado. Uma UAN

normalmente possui salas de manipulação conforme o tipo de alimento e atividade a ser

desenvolvida, a fim de evitar contaminação devido a “mistura” de alimentos e operações,

portanto é importante gerar relatórios para cada sala de preparação especificando a listagem

de ingredientes e instruções de trabalho, tais como as técnicas de cocção, que é o modo de

17

cozimento da preparação; tipo de corte do insumo, que especifica como aquele insumo deve

ser cortado; modo de preparo, etc. Esses relatórios são essenciais à correta execução do

cardápio, uso adequado dos insumos disponíveis e otimização da atividade de supervisão da

execução do cardápio por parte do nutricionista.

2.2 SISTEMAS DE INFORMAÇÃO

A informação tem grande importância para as organizações, inclusive para as UANS.

Por essa razão, é importante o uso de um Sistema de Informação (SI) para organizar e

controlar informações referentes ao funcionamento das organizações em geral. Segundo

Gonçalves (2012), o conceito de SI abrange qualquer sistema que manipula dados e gera

informação. Os sistemas de informação têm por objetivo gerar informações para auxiliar no

processo de tomada de decisões. Nesses sistemas os dados são coletados, processados e

transformados em informação útil.

De acordo com Gonçalves (2012), o sucesso da aplicação de um SI ligado à tecnologia

requer a compreensão do ambiente que está recebendo o apoio do sistema. Por exemplo, para

desenvolver um SI que dê apoio às transações realizadas em um supermercado, é preciso

compreender todos os processos e procedimentos relacionados como a compra e venda de

produtos nas lojas, demandas irregulares feitas ao sistema, etc. Da mesma forma acontece a

um SI aplicado a uma UAN. É preciso entender todas as atividades que ocorrem no ambiente

e seus relacionamentos.

De acordo com Davis (1989), dentre os fatores que influenciam na aceitação de um SI

pelo usuário encontram-se as características de facilidade de uso e utilidade. Dessa forma, um

bom SI deve ser desenvolvido de forma que auxilie o usuário no seu propósito de forma útil e

que não possua um nível alto de complexidade.

2.3 PROCESSO UNIFICADO

O Processo Unificado (PU) surgiu como um processo popular para o desenvolvimento

de software visando a construção de sistemas orientados a objetos. É um processo iterativo e

adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos devido a maneira

organizada e consistente que permite conduzir um projeto.

O ciclo de vida iterativo e incremental é baseado em refinamentos e incrementos

sucessivos a fim de convergir para um sistema adequado. Em cada iteração incrementa-se um

pouco mais o produto, baseando-se na experiência obtida nas iterações anteriores e no

feedback do usuário. Cada iteração pode ser considerada um miniprojeto de duração fixa,

18

sendo que cada um destes inclui suas próprias atividades de análise de requisitos, projeto,

implementação e testes (BRAZ, 2006).

Figura 2. Desenvolvimento iterativo e incremental.

FONTE: (BRAZ, 2006).

O Processo Unificado é organizado em quatro fases principais:

• Concepção: nessa fase ocorre o levantamento do escopo do projeto de uma forma

geral. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a

ideia é ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e

determinar se o projeto é viável e merece uma análise mais profunda.

• Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos) são

levantados em detalhes. Estes são implementados e servem como base de avaliação

junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Em cada

nova iteração na fase de elaboração pode haver um seminário de requisitos, onde

requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da fase,

90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi

implementado com alta qualidade, os principais riscos foram tratados e pode-se então

fazer estimativas mais realistas.

• Construção: implementação iterativa dos elementos restantes de menor risco e mais

fáceis e preparação para a implantação.

• Transição: testes finais e implantação.

19

2.4 ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

A Arquitetura Orientada a Serviços (do inglês, Service-Oriented Architecture - SOA) é

um paradigma que determina que as aplicações sejam construídas e reorganizadas através de

serviços específicos e bem definidos que são disponibilizados por um ou mais provedores de

serviço. Essa abordagem arquitetural é utilizada para lidar com a heterogeneidade sendo

conveniente quando é necessário haver a comunicação entre diversas aplicações que são

executadas em diferentes tecnologias e plataformas. A SOA promove a interoperabilidade

entre os serviços com a utilização de protocolos padronizados e tecnologias como o SOAP

(Simple Object Access Protocol) e REST (Representational State Transfer) fazendo com que

exista um fraco acoplamento entre os elementos. Dessa forma, cada elemento define sua

própria interface de acesso de modo que a interface esteja separada da implementação, o que

proporciona maior transparência para as aplicações clientes.

2.5 SERVIÇO WEB

Serviços Web (Web Services) são sistemas de software identificados por URIs

(Uniform Resource Identifier) que possibilitam a comunicação entre diferentes máquinas

através da rede, realizando a troca de mensagens através de um protocolo de comunicação

como, por exemplo, o HTTP (Hypertext Transfer Protocol) (W3C). Esses sistemas facilitam a

interoperabilidade entre clientes e servidores fornecendo uma interface por meio da qual um

programa cliente em uma organização pode interagir com um programa servidor em outra

organização sem a necessidade de supervisão humana (COULOURIS, 2013). Em outras

palavras, ao utilizar a tecnologia Web Service, uma aplicação pode invocar outra para realizar

tarefas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens

diferentes, pois a linguagem é traduzida para uma linguagem universal em um formato padrão

de transferência de dados como o XML (eXtended Markup Language) e JSON (JavaScript

Object Notation).

A comunicação entre os sistemas clientes e os serviços é baseada no paradigma

request/reply (requisição/resposta). Essa comunicação é exemplificada com um Diagrama de

Sequência ilustrado na Figura 3:

20

Figura 3. Diagrama de Sequência da comunicação entre Cliente e Servidor Web.


O cliente faz uma requisição HTTP para o servidor solicitando um determinado

recurso ou tarefa, em seguida o servidor envia uma resposta HTTP para o cliente com os

dados solicitados em um formato padrão de transferência de arquivos (XML ou JSON).

2.6 REST

O REST (REpresentational State Transfer) é um estilo de desenvolvimento de Web

Services baseado em recursos, sendo estes os conjuntos de dados que são trafegados pelo

protocolo HTTP. O REST tem sido bastante utilizado por desenvolvedores devido a suas

diversas vantagens como a garantia de que a troca de dados entre cliente e servidor seja feita

sem acoplamento entre as partes, proporcionando mais flexibilidade nas comunicações.

O Cliente interage com os recursos através dos métodos HTTP GET, POST, PUT e

DELETE, onde:

• GET: é utilizado quando existe a necessidade de se obter um recurso;

• POST: é utilizado para processamento de um recurso a partir do uso de uma

representação;

• PUT: é utilizado como forma de atualizar ou inserir um determinado recurso;

• DELETE: é utilizado para fazer a remoção de um determinado recurso.

Cada recurso é representado por uma URI (Uniform Resource Indentifier), onde toda

URI deve especificar qual o dado que será manipulado e qual método HTTP será utilizado.

Nas requisições as URIs são chamadas de substantivos enquanto os métodos HTTP são

denominados de verbos, o que significa que os métodos HTTP são os responsáveis por

21

provocar alterações nos recursos identificados pelas URIs (Saudate, 2014). A Tabela 1

mostra exemplos dessas requisições.

Tabela 1. Exemplos de requisições utilizando os métodos HTTP.

URI Verbo HTTP Corpo do JSON Descrição

/siguan/insumo GET Vazio Retorna todos os

insumos cadastrados.

/siguan/insumo POST JSON Insere um novo

insumo.

/siguan/insumo/:id PUT JSON

Atualiza um

determinado insumo

que possui o id

especificado na URI.

/siguan/insumo/:id DELETE Vazio

Remove um

determinado insumo

que possui o id

especificado na URI.

2.7 VUE.JS

O Vue.js é um framework JavaScript progressivo e de código aberto que auxilia no

desenvolvimento de interfaces de usuário. Sua diferença em relação a outros frameworks

monolíticos se dá pelo fato do Vue ter sido projetado para ser adotado de forma incremental.

A biblioteca principal concentra-se na renderização declarativa e composição de componentes

podendo ser integrada a outras bibliotecas ou projetos existentes (Vue.js, 2014). Por outro

lado, o projeto também inclui bibliotecas e ferramentas que dão suporte a criação de

aplicações maiores de página única (Single Page Application - SPA).

O Vue usa uma sintaxe de template baseada em HTML que permite vincular de forma

declarativa o DOM (Document Object Model) renderizado aos dados da instância Vue

subjacente. Todos os templates do Vue são HTMLs que podem ser interpretados pelos

navegadores. Uma outra característica do Vue é o sistema de reatividade discreta. Modelos

são objetos JavaScript simples que quando são modificados a visão é atualizada, o que torna o

gerenciamento de estado mais simples e intuitivo. O Vue fornece também uma nova

renderização otimizada sem muita complexidade. Cada componente monitora suas

22

dependências reativas durante a renderização, portanto, o sistema sabe exatamente quando

renderizar novamente e quais componentes serão renderizados.

Os componentes são importantes recursos do Vue. Quando se trata de uma aplicação

maior, é importante dividir a aplicação em componentes menores, independentes e

reutilizáveis para tornar o desenvolvimento gerenciável. Esses componentes estendem a

elementos HTML básicos para encapsular o código reutilizável. A Figura 4 mostra um

exemplo de componente Vue:

Figura 4. Exemplo de componente Vue.

FONTE: (Vue.js, 2014)

Este componente pode ser reutilizado conforme mostra a Figura 5:

Figura 5. Reutilização de componentes Vue.

FONTE: (Vue.js, 2014)

Um componente essencial de uma SPA é o Router que é responsável por

mostrar/esconder um ou mais elementos dependendo da URL que é acessada no navegador.

Bibliotecas JavaScript como o Vue fornecem uma interface fácil para alterar o que é exibido

na página com base no caminho do URL atual independentemente de como foi alterado. O

pacote vue-router fornece uma API para alterar a URL do navegador, usar botões de retorno

(histórico de hash) e passar parâmetros pela URL de uma página para outra de forma simples.

23

3. DESENVOLVIMENTO

Este Capítulo descreve a fase de desenvolvimento do sistema proposto. Visando

reduzir os riscos relacionados a possíveis imprevistos e incertezas do projeto, foi adotado o

método ágil OpenUP (Balduino, 2007) que é fundamentado no Processo Unificado (Kruchten,

2003), bastante utilizado no desenvolvimento tradicional de softwares. O OpenUP é um

método de desenvolvimento ágil e unificado que contém um conjunto mínimo de práticas que

auxiliam no processo de desenvolvimento de software. Esse modelo foi escolhido por ser

completo e propositalmente resumido, portanto não exige tecnologias específicas ou uma

equipe grande de desenvolvedores, além de ser extensível, podendo ser utilizado como base

para agregar novos processos. O OpenUP apresenta características importantes no

planejamento e implementação de sistemas orientados a objetos, uma dessas características é

a aplicação de abordagens iterativas e incrementais que seguem um ciclo de vida estruturado

baseando-se em casos de uso e cenários a fim de manter a comunicação entre os stakeholders.

Seguindo as etapas proposta pelo método OpenUP, o processo de desenvolvimento do

SIGUAN foi dividido em quatro fases que indicam os fluxos de trabalho que devem ser

enfatizados em um dado instante, dentro de todo o ciclo de vida do projeto. As fases de

desenvolvimento estão ilustradas a seguir na Figura 6:

Figura 6. Ciclo de vida do OpenUP.

FONTE: (Meira, 2010).

3.1 INICIAÇÃO

Na fase de Iniciação foi dado início ao planejamento do projeto priorizando o

processo de análise de requisitos. Como mencionado no Capítulo 1, este projeto foi planejado

com base no contexto do RU da EAJ. O levantamento de requisitos, bem como todas as

etapas que envolveram a interação com o cliente, ocorreu com a colaboração de uma

nutricionista funcionária do RU onde o sistema foi aplicado. Os requisitos são especificações

24

que definem os objetivos do sistema e como ele deve se comportar. Esta etapa é de grande

importância para obter um maior entendimento do problema e identificar a melhor forma de

solucioná-lo. Nessa fase foram executadas as principais etapas da Engenharia de Requisitos

(Nuseibeh & Easterbrook, 2000) que levaram em consideração os elementos de solução de

problemas, elaboração, negociação e especificação. Para a obtenção dos requisitos, foram

elaboradas perguntas destinadas aos usuários do sistema para que a equipe de

desenvolvimento pudesse adquirir um entendimento básico do problema. As perguntas foram

respondidas durante reuniões periódicas com a especialista em Nutrição e tinham como

objetivo esclarecer a respeito de como eram realizadas as atividades de gestão da UAN, o que

o nutricionista esperava do sistema e como o sistema seria utilizado.

Após a obtenção das informações necessárias foram definidos os requisitos funcionais,

que determinam as funcionalidades do sistema, e os requisitos não-funcionais, que podem ser

descritos como atributos de qualidade, segurança, desempenho e/ou restrições. Os principais

requisitos funcionais e não-funcionais estão apresentados na Tabela 2 e Tabela 3

respectivamente.

Tabela 2. Requisitos funcionais.

Código Descrição

RF001 Fazer login e autenticar usuário.

RF002 Cadastro, exclusão, atualização e consulta de

usuários.


insumos.


insumo per capita.

RF005 Cadastro, exclusão, atualização e consulta da

Análise Química de um insumo.


cortes.


salas de preparação


preparações.


cardápios.

25


embalagens.


itens no estoque.

RF012 Realizar seleção do cardápio que será aplicado a

uma semana.


prescrição.

RF014 Emitir relatórios de prescrição (Despensa e

preparações por sala).

Tabela 3. Requisitos não-funcionais.

Código Descrição

RNF001

Segurança. O sistema deverá ser usado apenas

por usuários cadastrados e autorizados por

processo de login. Todas as operações do sistema

deverão validar se o usuário possui credenciais

válidas para a operação requisitada.

RNF002 Segurança. O sistema deve guardar as senhas dos

usuários de forma criptografada.

RNF003 Portabilidade. O sistema deve ser acessado em

qualquer dispositivo conectado à internet.

RNF004 Usabilidade. O sistema deve oferecer uma

interface fácil de ser usada.

RNF005 Compatibilidade. O sistema deve ser compatível

com qualquer browser (Mozila, Chrome, Edge)

Após a definição dos requisitos, os mesmos foram validados pela nutricionista para

garantir que estavam de acordo com esperado. Após a validação foi dado início à análise

arquitetural do sistema (fase apresentada na Seção 3.2 ).

3.2 ELABORAÇÃO

Na fase de Elaboração foi enfatizado o processo de desenvolvimento da análise

arquitetural do sistema, onde foi estabelecida uma arquitetura estável a partir da qual o

sistema pôde evoluir. Por se tratar de um sistema de software complexo e com uma série de

requisitos de qualidade, a arquitetura do sistema foi planejada com o intuito de detalhar os

26

componentes de software, suas propriedades e seus relacionamentos de modo a atender os

requisitos dos usuários e facilitar o seu desenvolvimento e manutenção, bem como

proporcionar um alto nível dos atributos de qualidade como confiabilidade, usabilidade,

disponibilidade e segurança. Para realizar as especificações da arquitetura de software foi

adotado o modelo arquitetural de Visões 4+1, apresentado na Seção 3.2.1 .

3.2.1 VISÕES 4+1

O modelo arquitetural de Visões 4+1 foi criado por Kruntchen (1995) e propõe

organizar a especificação da arquitetura de software em torno de quatro visões concorrentes e

fazer uma ilustração a partir de alguns casos de uso selecionados ou cenários que se tornam

uma quinta visão (Figura 7).

Figura 7. Modelo arquitetural de visões 4+1.


3.2.2 VISÃO DE CASOS DE USO

Esta visão ilustra as funcionalidades do sistema a partir de um conjunto de casos de

uso especificados conforme a necessidade dos stakeholders do projeto. Os cenários são uma

abstração dos requisitos mais importantes. Nessa visão, esses cenários são usados para

identificar elementos arquitetônicos e ilustrar e validar o projeto de arquitetura. Esta visão é

chamada de ‘+1’, pois ela serve para descobrir os elementos arquitetônicos durante o projeto

da arquitetura e como uma função de validação e ilustração após a conclusão do projeto. A

Figura 8 apresenta o diagrama de casos de uso que ilustra as principais funcionalidades

oferecidas pelo sistema e o modo como os atores interagem com as mesmas.

27

Figura 8. Diagrama de Casos de Uso.

FONTE: adaptada do projeto SIGRU.

O sistema desenvolvido contempla quatro atores, que são:

1. Nutricionista: usuário que possui o maior nível de permissão no sistema. É

responsável por realizar as principais funcionalidades, como o gerenciamento

de todos os registros cadastrados, elaboração de cardápios e preparações,

emissão de relatórios e controle dos demais usuários;

2. Estagiário de Nutrição: possui autorização para realizar parte das

funcionalidades do sistema, como o gerenciamento de parte dos registros

cadastrados e emissão de relatórios. O ator Estagiário de Nutrição não possui

autorização para gerenciar os demais usuários do sistema.

3. Almoxarife: responsável por realizar o controle de entrada e saída de itens do

estoque;

4. Usuário Externo: utiliza o sistema para visualizar os cardápios semanais.

O detalhamento dos casos de uso está disponível na seção de Apêndice A.

28

3.2.3 VISÃO LÓGICA

A Visão Lógica abrange principalmente os requisitos funcionais, os quais serão

disponibilizados ao usuário final em termos de serviços. Esta visão foi representada neste

projeto através do diagrama de classes, responsável por descrever o conjunto de classes e seus

relacionamentos lógicos, especificando suas associações, composições, heranças e assim por

diante. A Figura 9 mostra o diagrama de classes simplificado com a representação das

principais classes do sistema e seus respectivos atributos e relacionamentos. A versão

completa do diagrama pode ser encontrada no Apêndice B.

Figura 9. Versão simplificada do Diagrama de Classes do SIGUAN.

FONTE: adaptação do projeto SIGRU

A Tabela 4 apresenta as descrições das classes especificando o que cada uma

representa.

29

Tabela 4. Descrição do Diagrama de Classes.

Classe Descrição

Usuario

Classe que representa o usuário que irá utilizar o

sistema. Possui atributos que indicam os dados do

usuário como nome e tipo.

Login Classe que representa o login e possui atributos que

indicam os dados para a autenticação do usuário.

Insumo

Classe que representa o item do ingrediente. Possui

atributos que indicam informações como nome, tipo

e unidade base.

InsumoPerCapita

Classe que representa o ingrediente necessário para

apenas uma pessoa. Possui atributos que indicam o

nome, peso bruto, peso limpo e tipo de corte

aplicado.

TipoCorte

Classe que representa o tipo de corte que deve ser

aplicado ao insumo per capita. Possui atributos que

indicam o nome e a descrição do corte.

ItemEstoque

Classe que representa o insumo disponível no

estoque. Possui atributos que indicam o nome do

item, quantidade, unidade, entrada (operação de

entrada ou saída), responsável e data da operação.

Unidade

Classe que representa a embalagem do insumo.

Possui atributos que indicam o nome (Ex.: caixa,

pacote, etc.), a unidade base (Ex.: grama, litro, etc.)

e o multiplicador.

Preparacao

Classe que representa a receita que será preparada

em cada refeição. Possui atributos que indicam

nome, ingredientes, modo de preparo, local de

preparo, técnica de cocção, etc.

SalaDePreparo

Classe que representa o local onde as preparações

são produzidas. Possui atributos que indicam o

nome, descrição e número de funcionários.

MenuAplicado

Classe que representa um menu aplicado a um dia

da semana. Possui atributos que indicam a data, as

refeições e a previsão de comensais (usuários da

UAN).

CardapioAplicado Classe que representa um cardápio semanal

contendo um conjunto de menus diários. Possui

atributos que indicam o nome, os menus e o usuário

30

responsável.

Prescricao

Classe que representa uma prescrição, onde é

especificado a quantidade necessária dos insumos

para preparar as refeições de um dia específico.

Possui atributos que indicam o cardápio aplicado, a

data, o responsável e a lista de itens que serão

retirados do estoque especificando suas respectivas

quantidades.

3.2.4 VISÃO DE IMPLEMENTAÇÃO

A visão de implementação ilustra o sistema do ponto de vista do desenvolvedor a

respeito de como o sistema será implementado. Visando atingir os objetivos do trabalho, a

arquitetura da aplicação desenvolvida foi planejada com base no estilo arquitetural em

camadas. A arquitetura em camadas proporciona maior facilidade de compreensão, pois

utiliza níveis crescentes de abstração particionando problemas complexos em passos

sequenciais e incrementais, além de tornar o sistema mais flexível, o que facilita a

manutenção (LARMAN, 2004). As camadas foram organizadas de forma hierárquica de

modo que cada camada oferece o serviço para a camada superior e faz uso do serviço

oferecido pela camada inferior. A arquitetura proposta para o desenvolvimento do SIGUAN

está representada na Figura 10.

31

Figura 10. Arquitetura do sistema.


A arquitetura está representada em cinco camadas. A camada de Mapeamento

Objeto-Relacional é responsável pela Persistência dos dados no Banco de Dados MySQL.

O modelo dos dados que serão persistidos é determinado pela camada Modelo, que representa

a especificação das regras de negócios e as estruturas dos dados que serão armazenados na

base de dados.

A camada de Serviços RESTful compreende os Serviços Web baseados em REST

que serão utilizados pelo frontend para se comunicar com o backend e realizar a troca de

recursos utilizando os métodos HTTP. O frontend faz uma requisição e o backend retorna a

resposta com o recurso solicitado. Os recursos trafegam em um formato de transferência de

dados específico, no caso do SIGUAN, o formato adotado foi o JSON, pois é um formato leve

e de fácil interpretação.

A camada do Frontend Vue.js é uma aplicação web que serve de interface para que o

usuário possa interagir com as funcionalidades do sistema.

32

3.2.5 VISÃO DE IMPLANTAÇÃO

Esta visão demonstra o ambiente de execução do sistema e foca nos aspectos da

topologia e organização de componentes de software na camada física, além das conexões

físicas entre esses componentes. Nesta fase foram levados em consideração principalmente os

requisitos não funcionais do sistema, como disponibilidade, escalabilidade, confiabilidade e

desempenho a fim de identificar a melhor forma possível para mapear os artefatos de software

ao hardware responsável por hospedar esses artefatos. A arquitetura de implantação deste

projeto foi representada pelo diagrama de implantação representado na Figura 11.

Figura 11. Diagrama de implantação.


Como é possível observar na Figura 11, os componentes desse sistema foram

organizados da seguinte forma: O Cliente representa a interface gráfica do sistema (frontend)

que faz referência ao browser que se encarrega de fazer a comunicação com o servidor através

do protocolo HTTP e utiliza os métodos que permitem o acesso às funcionalidades do

sistema. O Servidor armazena as regras de negócio que definem como os dados serão

acessados e processados. Este componente é responsável por fazer a comunicação entre o

banco de dados e o cliente. Por fim, o Banco de Dados que faz referência a todos os registros

existentes. A comunicação do servidor com o banco de dados é realizada através do JDBC

(Java Database Connectivity) que se trata de uma API que possui um conjunto de rotinas e

padrões em Java que fazem o envio de instruções SQL para o banco de dados relacional.

33

3.2.6 VISÃO DE PROCESSOS

A visão de processos aborda os aspectos dinâmicos do sistema e demonstra toda a

comunicação entre seus processos. Nesta etapa foram descritos como as principais abstrações

da visão lógica se enquadram na visão de processos. Alguns requisitos não-funcionais foram

levados em consideração para o planejamento desta visão, como desempenho,

disponibilidade, integridade e tolerância a erros. Para representar a arquitetura de processos

do sistema desenvolvido, foram elaborados diagramas de atividades responsáveis por

descrever o fluxo de atividades dos processos. A Figura 12 apresenta o diagrama de

atividades que descreve as etapas para a criação de um cardápio no sistema. Primeiramente o

usuário deve inserir um nome para o cardápio, em seguida criar os menus e fazer uma busca

nas preparações cadastradas e selecionar as que deseja incluir em cada menu.

Figura 12. Diagrama de atividades da criação de cardápio.


A Figura 13 apresenta o diagrama de atividades da criação de uma prescrição.

Primeiramente o usuário deve inserir a data da prescrição, em seguida fazer uma busca pelos

34

cardápios aplicados cadastrados no sistema e selecionar o cardápio desejado. Após

selecionado o cardápio aplicado, o usuário deve escolher os menus que deseja prescrever. Ao

salvar a prescrição, o sistema realiza o cálculo da quantidade dos insumos que serão

necessários para as preparações dos menus selecionados na prescrição e faz a retirada dos

itens do estoque de forma automática.

Figura 13. Diagrama de atividades da criação de prescrição.


3.3 CONSTRUÇÃO

Na fase de Construção foi dado início ao processo de implementação do sistema com

base na arquitetura apresentada na seção anterior. A equipe de desenvolvimento é composta

por 6 programadores e 1 gerente de projeto responsável por coordenar a equipe, mas tendo em

vista o foco desta Monografia, nesta seção serão apresentadas com mais ênfase as

implementações realizadas pela autora do trabalho.

O processo de construção foi realizado de forma iterativa e incremental, os requisitos

foram transformados em componentes executáveis para que, ao final de cada iteração,

houvesse um produto executável que pudesse ser testado pelo usuário e assim obter um

feedback contínuo e achar possíveis erros ou má interpretação dos requisitos.

A camada de Mapeamento Objeto-Relacional foi implementada utilizando o

framework Hibernate para mapear as classes Java em tabelas do banco de dados relacional.

Além de realizar o mapeamento objeto relacional, a ferramenta também disponibiliza

35

mecanismos de consulta de dados, o que permite uma redução considerável no tempo de

desenvolvimento da aplicação. Para realizar a persistência dos dados, o Hibernate faz uso da

API JDBC para fazer o envio de instruções SQL para o banco de dados.

Para ter acesso a maioria das funcionalidades do SIGUAN é necessário realizar a

autenticação no sistema para garantir a segurança dos dados. O único recurso que não

necessita de autenticação para ser acessado é o do cardápio semanal, pois este recurso foi

disponibilizado para que o público externo pudesse visualizar o cardápio da semana. Os

demais recursos só podem ser acessados por usuários autenticados. Além das funcionalidades

de gerenciamento de recursos, o SIGUAN também dispõe de um serviço responsável por

realizar essa autenticação de forma segura. Para isso, o cliente (frontend) envia um JSON

contendo os dados de autenticação do usuário (login e senha) através de uma requisição

HTTP POST. A Figura 14 apresenta um exemplo de solicitação de login.

Figura 14. Exemplo de requisição de login.


O backend verifica se os dados de login estão corretos e manda uma resposta HTTP

passando no corpo do JSON os dados do usuário autenticado e um token no cabeçalho. O

token é uma chave única utilizada como um identificador do usuário que está autenticado.

Esta chave é verificada sempre que o cliente faz uma solicitação a um serviço. O token deve

ser passado no cabeçalho do JSON seguindo o padrão “Authorization: bearer token” como

mostra a Figura 15.

Figura 15. Exemplo de envio do token.

36


A Figura 16 apresenta um exemplo de solicitação do recurso insumo de id=1

utilizando o método HTTP GET. A resposta enviada pelo servidor é um objeto JSON

contendo os dados do insumo solicitado.

Figura 16. Exemplo de solicitação de um insumo utilizando o método HTTP GET.


Além da solicitação de recursos, o SIGUAN também oferece serviços contendo

métodos para inserir registros no banco de dados. Nesse caso, o cliente (frontend) faz uma

requisição HTTP POST enviando um objeto JSON que contém os dados do recurso que

deseja inserir. A resposta enviada pelo servidor é um objeto JSON contendo o id do insumo

cadastrado. A Figura 17 mostra um exemplo de cadastro de um insumo.

37

Figura 17. Exemplo de cadastro de insumo utilizando o método HTTP POST.


Outra funcionalidade oferecida é a opção de edição de registros. Para isso, o cliente

faz uma requisição HTTP PUT enviando um objeto JSON que contém os dados do recurso

que deseja alterar. Também é necessário especificar o id do recurso na URI. O servidor envia

uma resposta contendo o objeto JSON com os dados do recurso que foi alterado. A Figura 18

mostra um exemplo de edição de cadastro de insumo que possui id=234.

Figura 18. Exemplo de alteração dos dados de um insumo utilizando o método HTTP PUT.


38

O SIGUAN também oferece serviços com métodos para remover registros do banco

de dados. Para isso, o cliente faz uma requisição HTTP DELETE especificando na URI o id

do recurso que deseja remover, por exemplo, na Figura 19 o id é 234. O servidor apresenta

como resposta o conteúdo vazio e o status 204 No Content.

Figura 19. Exemplo se remoção de insumo utilizando o método HTTP DELETE.


Uma das principais funcionalidades implementadas foi o serviço de prescrição de

cardápios. Este serviço é responsável por calcular a quantidade de insumos necessária para as

preparações de um cardápio levando em consideração a lista de ingredientes de cada

preparação e o número de comensais previsto para cada refeição. Para prescrever um cardápio

é necessário que o cliente envie um objeto JSON contendo as informações das previsões de

comensais e o cardápio que deseja prescrever composto das preparações que contém as listas

de ingredientes. Ao receber o objeto de Prescrição, o serviço se encarrega de realizar o cálculo

dos insumos necessários e preenche as listas de itens para cada refeição informando suas

respectivas quantidades. A Figura 20 mostra um exemplo da criação de uma prescrição

utilizando o método HTTP POST.

39

Figura 20. Exemplo de prescrição de um cardápio.


A camada Frontend Vue JS representa uma aplicação web desenvolvida com o

framework Vue JS que serve como uma interface para o usuário. Essa aplicação representa o

cliente que irá consumir os serviços e manipular os recursos. A interface foi construída com

base em componentes independentes e reutilizáveis a fim de simplificar o desenvolvimento e

torna-lo gerenciável. Também foi utilizado o template AdminLTE1 do Boostrap. O Vue JS

usa uma sintaxe de templates baseada em HTML que são interpretados pelo navegador e os

componentes da aplicação são exibidos para o usuário. A Figura 21 mostra o trecho de

código do template da tela de login do SIGUAN utilizando o framework Vue JS.

Figura 21. Template da tela de login do SIGUAN.

1 https://adminlte.io/

https://adminlte.io/

40


A Figura 22 apresenta os componentes da tela de login que são apresentados para o

usuário.

Figura 22. Tela de login do SIGUAN.

FONTE: Própria da autora.

O painel de controle, apresentado na Figura 23, possui uma área de trabalho onde é

exibido o conteúdo do sistema e uma barra lateral com o menu de opções de trabalho

disponíveis que são as seguintes:

1. Insumos: Usada sempre que há a necessidade de cadastrar, alterar ou excluir insumos,

insumos per capita ou um tipo de corte no sistema. Para cadastrar um per capita é

necessário o cadastro do insumo associado ao per capita. Uma vez definido, um per

capita pode ser usado sempre que necessário.

2. Preparação: Usada quando há a necessidade de cadastrar, alterar ou excluir uma

preparação ou uma sala de preparação. Para o cadastro de uma preparação é necessário

definir os per capitas que serão usados.

3. Cardápios: Usada quando há a necessidade de cadastrar, alterar ou excluir um

cardápio. Para o cadastro de um cardápio é necessário cadastrar previamente as

preparações que serão utilizadas.

4. Estoque: Usada quando há a necessidade de cadastrar, alterar ou excluir itens no

estoque ou embalagens nas quais um insumo pode vir a dar entrada no estoque.

41

5. Prescrições: Usada quando há necessidade de prescrever menus.

6. Usuários: Usada quando há a necessidade de cadastrar, alterar ou excluir usuários do

sistema.

7. Exibição de cardápios: No centro da tela é exibido o cardápio da semana contendo os

menus diários e suas respectivas preparações.

Figura 23. Painel de controle do SIGUAN.


A tela de cadastro de insumo per capita, apresentada na Figura 24, possui um

formulário onde o usuário deve inserir os seguintes dados: 1- ingrediente (que é o insumo

que já deve ter sido cadastrado anteriormente); 2- observações; 3- especificar se o per capita é

condimento ou não; 4- selecionar o tipo de corte (que já deve ter sido cadastrado

anteriormente); 5- informar o peso limpo, peso bruto e o fator de correção do insumo per

capita.

42

Figura 24. Tela de cadastro de insumo per capita.


Na tela de cadastro de preparação (Figura 25) o usuário insere as informações das

receitas que serão servidas na UAN. Uma vez cadastrada, a preparação pode ser reutilizada

posteriormente sempre que for necessário, sem a necessidade de inserir as mesmas

informações novamente, o mesmo serve para os insumos e cardápios. Os dados requeridos

para o cadastro das preparações são: 1- nome, 2- ingredientes (que são os insumos per

capitas que já devem ter sido cadastrados anteriormente), 3- cor predominante da

preparação, 4- textura, 5- grupo de alimentos ao qual a preparação pertence, 6- aspecto

gorduroso, 7- técnica de cocção, 8- nível de enxofre, 9- sala de preparo onde a preparação

deve ser produzida, 10- nível de sódio da preparação, 11- informar se a preparação é

vegetariana e, por fim, 12- informar como a preparação deve ser preparada.

Figura 25. Tela de cadastro de preparação.

43


Na tela de planejamento e criação de cardápios (Figura 26) os dados requeridos para o

cadastro do cardápio são: 1- nome e 2- dados dos menus diários. Cada menu diário deve

possuir um nome e as preparações para cada refeição. Não é obrigatório o preenchimento de

todas as refeições.

Figura 26. Tela de criação de cardápio.

FONTE: própria autora.

Os dados requeridos para o cadastro de prescrição são: 1- data, 2- cardápio aplicado

(que é o cardápio semanal com menus aplicados a uma data específica), 3- seleção dos menus

que deseja prescrever e informação a respeito da previsão de comensais para cada refeição. A

Figura 27 apresenta a tela de cadastro da prescrição de um cardápio.

44

Figura 27. Tela de prescrição de cardápio.


A partir da prescrição o usuário poderá gerar os relatórios de cada sala de preparação,

que são: 1- Sala de Vegetais: que contém todos os insumos que são vegetais, 2- Sala de

Carnes: composto pelos insumos que são carnes e 3- Cozinha: que contém os demais

insumos. Além de gerar o relatório de Requisição Diária que contém todos os insumos que

serão retirados da despensa pelo almoxarife. A Figura 28 apresenta um exemplo de relatório

da cozinha.

Figura 28. Relatório da Cozinha.

45


3.4 TRANSIÇÃO

A fase de Transição enfatizou o processo de implantação do sistema com foco na

realização de testes para verificar se o sistema consegue suprir as necessidades dos usuários.

Esta etapa compreendeu a configuração do ambiente de produção e o treinamento dos

usuários do sistema. A princípio o sistema foi disponibilizado online para que a nutricionista

integrante do projeto pudesse utiliza-lo e retornar informações sobre erros, ajustes e

sugestões. O próximo passo do projeto nesta fase é disponibilizar o SIGUAN para ser

utilizado no ambiente do RU pelos demais funcionários e continuar a fase de testes nesse

ambiente.

46

4. AVALIAÇÃO

Este Capítulo descreve o processo de avaliação do SIGUAN realizado através da

execução de um experimento controlado baseado no método proposto por Jedlitschka at al.

(2008). O experimento teve como objetivo investigar se as funcionalidades do sistema

desenvolvido atingem os objetivos deste trabalho (especificados no Capítulo 1) e avaliar o

nível de complexidade, utilidade e produtividade do sistema em comparação com um método

tradicional de planejamento e prescrição de cardápios em UANs.

4.1 OBJETIVOS DA AVALIAÇÃO

Os objetivos da avaliação partiram dos objetivos estabelecidos para esta Monografia e

foram definidos com base na metodologia Goal, Question, Metric (GQM) proposta por Basili

at al. (1992). O paradigma GQM é uma abordagem orientada a objetivos bastante utilizada em

engenharia de software para a avaliar produtos e processos de software. Essa abordagem parte

do princípio de que toda a coleta dos dados deve ser baseada num fundamento lógico, em um

objetivo que é documentado de forma explícita (FONTOURA et al., 2004). O primeiro passo

seguindo o método GQM é definir os objetivos que serão alcançados no processo de

avaliação.

Como especificado no Capítulo 1, os objetivos deste trabalho são: (i) Elaboração de

um modelo de sistema útil e que aumente a produtividade do profissional de nutrição no

processo de planejamento e prescrição de cardápios; (ii) Implementação de serviços para

manipulação dos dados; (iii) Construção do Módulo de Elaboração e Prescrição de

Cardápios; (iv) Construção do Módulo de Geração de Relatórios; (v) Construção do Módulo

de Interface Web de fácil utilização. Estes objetivos foram aperfeiçoados para dar origem ao

objetivo (Goals) do experimento controlado:

Objetivo 1 (G1): Analisar o SIGUAN no processo de planejamento e prescrição de

cardápios com o propósito de avaliar sua eficácia com relação à usabilidade percebida,

utilidade percebida e produtividade no contexto da UAN.

A partir do objetivo da avaliação foram elaboradas questões (Questions) que refinam o

objetivo de forma quantitativa. As questões estão especificadas a seguir na Seção 4.2 .

4.2 QUESTÕES

Um conjunto de questões foi elaborado a partir do objetivo a fim de especificar as

métricas adequadas para a avaliação. As questões identificam a informação necessária para

atingir o objetivo e as métricas irão definir os dados a serem coletados para responder as

47

perguntas. Foram elaboradas três questões (Q1 a Q3), onde todas refinam o Objetivo 1 (G1).

A questão Q1 está relacionada à característica de usabilidade, a questão Q2 possui foco na

característica de utilidade e a questão Q3 tem como alvo a característica de produtividade.

• Q1: O SIGUAN é fácil de usar?

• Q2: O SIGUAN ajuda no planejamento e prescrição de cardápios?

• Q3: O SIGUAN é eficiente no processo de planejamento e prescrição de cardápios em

termos de tempo quando comparado com o método tradicional?

4.3 MÉTRICAS

As métricas (Metrics) foram definidas com base nas questões quantitativas

especificadas na Seção 4.2 a fim de obter respostas para essas questões. Essas métricas

avaliam quantitativamente a abordagem automatizada proporcionada pelo SIGUAN para o

planejamento de cardápios no contexto das UANs. Esta avaliação foi feita com base nas

variáveis: (i) facilidade de uso percebida, (ii) utilidade percebida e (iii) esforço de trabalho.

Avaliar o nível de aceitação do usuário de Sistema de Informação é de grande

importância para determinar a eficácia do sistema. Diante disso, a métrica M1 foi definida

com base na variável de facilidade de uso percebida que se refere à “o grau em que uma

pessoa acredita que usar um determinado sistema estaria livre de esforço” (DAVIS, 1989).

Para a obtenção de M1 foi elaborado um questionário, baseado na teoria de Davis (1989), que

avalia o nível de concordância do usuário com algumas afirmações sobre a facilidade de uso

percebida. As respostas do questionário baseiam-se na escala de Likert (LIKERT, 1932)

podendo variar de 1 a 5, onde:

• 1 = Discordo totalmente;

• 2 = Discordo;

• 3 = Indiferente;

• 4 = Concordo;

• 5 = Concordo totalmente.

A métrica M1 é obtida através da média ponderada dos resultados do questionário,

como mostra a expressão:

48

Onde:

Q = Número da questão sobre Facilidade de Uso Percebida;

P = Número de participantes.

A partir dos valores de M1 é possível identificar a opinião dos participantes em

relação a facilidade de uso do SIGUAN. Caso os valores obtidos para M1 sejam elevados,

isso aponta que os candidatos consideram fácil de ser utilizada a abordagem automatizada de

criação de cardápios e prescrições com o SIGUAN. Caso os valores sejam baixos, isso

significa que os candidatos consideraram difícil a utilização do SIGUAN para a criação de

cardápios e prescrições.

A métrica M2 foi definida com base na variável de utilidade percebida que é definida

como “o grau em que uma pessoa acredita que usar um determinado sistema aumentaria seu

desempenho no trabalho” (DAVIS, 1989). A métrica M2 foi obtida através de um

questionário, baseado na teoria de Davis (1989), que avalia o nível de concordância do

usuário com algumas afirmações sobre a utilidade percebida. As respostas do questionário

também se baseiam na escala de Likert (LIKERT, 1932).

A métrica M2 é obtida através da média ponderada dos resultados do questionário,

como mostra a expressão:

Onde:

Q = Número da questão sobre Utilidade Percebida;

P = Número de participantes.

A partir dos valores de M2 é possível identificar a opinião dos participantes em

relação a utilidade do SIGUAN. Caso os valores obtidos para M2 sejam elevados, isso aponta

que os candidatos consideram útil a abordagem automatizada de criação e prescrição de

cardápios com o SIGUAN. Caso os valores sejam baixos, isso significa que os candidatos não

consideraram útil a utilização do SIGUAN para a criação e prescrição de cardápios.

A métrica M3 foi definida com base na variável de esforço de trabalho que se refere

ao tempo total gasto por cada grupo na execução das tarefas do experimento controlado

levando em consideração as abordagens tradicional e automatizada com o SIGUAN. A

métrica M3 foi obtida através do somatório do tempo gasto pelos candidatos integrantes dos

grupos.

A métrica M3 é obtida através da expressão:

M3 ∑ Tempo de Duração da Tarefa {A; G}

49

Onde:

A = Abordagem utilizada pelo participante na execução da tarefa;

G = Grupo ao qual o participante pertence.

A partir dos valores de M3 é possível identificar o tempo necessário para executar as

tarefas em cada abordagem. Caso os valores obtidos para M3 sejam elevados, isso significa

que a abordagem utilizada exige um esforço maior para a execução das tarefas de elaboração

de cardápios e prescrições. Caso os valores sejam baixos, isso significa que abordagem

utilizada exige um esforço menor para a execução das tarefas de elaboração de cardápios e

prescrições.

4.4 PLANEJAMENTO

O experimento controlado foi dividido em duas etapas. Na primeira etapa, ocorreu o

processo de treinamento dos participantes para a utilização do modo tradicional de criação e

prescrição de cardápios. Esse treinamento se fez necessário tendo em vista que os

participantes não possuíam conhecimento nem experiência com atividades relacionadas ao

planejamento de cardápios. No treinamento foram apresentados os conceitos e estrutura da

UAN, em seguida os participantes receberam orientações a respeito das etapas de

planejamento e prescrição de cardápios e por último foram apresentadas as principais

funcionalidades do SIGUAN. Em seguida, ainda na primeira etapa, os participantes

responderam a um questionário de avaliação acadêmica, pessoal e profissional a fim de

coletar informações relacionadas a suas experiências e habilidades com ferramentas

computacionais e com atividades de planejamento e prescrição de cardápios. Com base nas

respostas do questionário, foi identificado que os participantes se encontravam dentro do

padrão esperado e, portanto, nenhum participante foi excluído do experimento. Também

foram disponibilizados slides com as orientações dadas no treinamento e o manual do

SIGUAN como materiais de apoio para a realização das tarefas.

A segunda etapa compreendeu a execução de atividades de criação e prescrição de

cardápios utilizando uma abordagem tradicional fazendo uso da ferramenta Excel e, em

seguida, utilizando a abordagem automatizada com o SIGUAN para executar as tarefas do

experimento (especificadas na Seção 4.6 ). Primeiramente foi realizado um sorteio para

dividir os participantes em dois grupos (Grupo 1 e Grupo 2). Em seguida, um segundo sorteio

foi realizado para determinar qual abordagem seria utilizada primeiro por cada grupo. Com

base no resultado do sorteio, foi determinado que o Grupo 1 utilizaria primeiro a abordagem

50

automatizada com o SIGUAN e a abordagem tradicional com o Excel depois, enquanto o

Grupo 2 realizaria a abordagem tradicional com o Excel primeiro e, em seguida, a abordagem

automatizada com o SIGUAN.

4.5 PARTICIPANTES

O perfil dos participantes esperado para a participação no experimento abrange: (i)

nível educacional, (ii) nível de experiência com ferramentas computacionais, (iii) nível de

conhecimento no campo de alimentação coletiva. O experimento contou com a participação

de 8 alunos de Graduação da Escola Agrícola de Jundiaí (EAJ) da Universidade Federal do

Rio Grande do Norte (UFRN). Os participantes foram convidados a participar do experimento

de forma voluntária. Nenhum dos participantes teve envolvimento com o planejamento do

experimento de avaliação e todos assinaram um formulário de consentimento contendo a

descrição do procedimento, termos de confidencialidade e esclarecimento dos benefícios que

o experimento proporcionaria e da liberdade de desistência. O formulário de caracterização

mostrou que 100% dos participantes possuem conhecimento avançado em informática. Em

relação ao conhecimento na área de nutrição (Figura 29), apenas dois participantes

declararam ter conhecimento básico, enquanto 6 participantes declararam não possuir

conhecimento na área.

Figura 29. Nível de conhecimento em Nutrição.


Em relação ao nível de conhecimento em Excel (Figura 30), as respostas do

formulário de caracterização mostraram que metade dos participantes possui nível básico de

conhecimento, enquanto 37,5% possui nível médio e 12,5% possui nível avançado de

conhecimento na ferramenta.

51

Figura 30. Nível de conhecimento em Excel.


4.6 TAREFAS

Um conjunto de tarefas foi elaborado para serem executadas pelos participantes de

forma a possibilitar a coleta das métricas para a avaliação. As tarefas elaboradas estão

dispostas na Tabela 5.

Tabela 5. Tarefas executadas pelos participantes.

Tarefa Descrição

T1 Criar uma lista de 11 insumos especificando informações como o nome, embalagem e

o valor do peso bruto per capita de cada insumo.

T2

Criar uma lista de 5 preparações especificando informações como o nome, modo de

preparo, insumos que serão utilizados com seus respectivos valores de peso bruto per

capita e a sala onde a refeição será preparada. A preparação será composta pelos

insumos cadastrados na Tarefa 1.

T3

Criar um cardápio com apenas um menu referente ao dia de Segunda-feira. O menu

deve possuir três refeições (desjejum, almoço e jantar) e as refeições devem ser

compostas pelas preparações criadas na Tarefa 2. Atribuir uma data ao cardápio

criado e determinar a quantidade de comensais (usuários) prevista para cada refeição.

T4

Realizar a prescrição do cardápio criado na Tarefa 3. A prescrição deve ser gerada

através do cálculo da quantidade necessária de cada insumo para o preparo das

receitas, levando em consideração a previsão de comensais para cada refeição. Para

obter a quantidade necessária de insumos, deve-se fazer a multiplicação do peso bruto

52

per capita do insumo pela previsão de comensais da refeição.

T5

Gerar um relatório para cada sala de preparação determinando os insumos que serão

utilizados, as quantidades de cada insumo e as instruções de trabalho para os

funcionários. Os insumos determinados na prescrição do cardápio devem ser

separados nos relatórios de acordo com seu tipo, os que forem vegetais entram no

relatório da Sala de Vegetais, os que forem carnes entram para o relatório da Sala de

Carnes e os demais insumos vão para o relatório da Sala de Cocção (Cozinha).

Todos os participantes executaram as mesmas tarefas de maneira sequencial e na

mesma ordem tendo em vista que, com exceção da T1, cada tarefa depende dos resultados da

tarefa anterior para serem executadas.

4.7 ROTEIRO DO EXPERIMENTO

Esta seção descreve o roteiro de atividades para o procedimento aplicado. O

experimento controlado foi executado em um laboratório de informática onde haviam

computadores disponíveis para todos os participantes. As etapas do procedimento estão

definidas a seguir:

1. Ao chegar no laboratório o participante recebe o formulário de consentimento

contendo os termos de participação do experimento e realiza o preenchimento;

2. É realizado o processo de treinamento dos participantes para o procedimento

tradicional de criação e prescrição de cardápios e para o procedimento automatizado

com o SIGUAN;

3. Os participantes recebem o formulário de qualificação e realizam o preenchimento;

4. O material de apoio é distribuído entre os participantes;

5. É realizado o sorteio para definir os participantes do Grupo 1 e do Grupo 2 e um

segundo sorteio para definir qual grupo começa com a abordagem tradicional e qual

grupo começa com a abordagem automatizada com o SIGUAN.

6. É dado início à execução das tarefas pelos participantes.

6.1 Na primeira etapa os participantes do Grupo 1 executam as tarefas utilizando a

abordagem automatizada com o SIGUAN, enquanto os participantes do Grupo 2

executam as tarefas utilizando a abordagem tradicional com o Excel.

53

6.1.1 Ao final de cada tarefa o avaliador analisa se a mesma foi completada

corretamente;

6.1.2 O avaliador verifica o tempo gasto na execução de cada tarefa;

6.1.3 Após a execução de todas as tarefas, os participantes preenchem os

questionários de avaliação;

6.2 Na segunda etapa os participantes do Grupo 1 executam as tarefas utilizando a

abordagem tradicional com o Excel, enquanto os participantes do Grupo 2

executam as tarefas utilizando a abordagem automatizada com o SIGUAN.

6.2.1 Ao final de cada tarefa o avaliador analisa se a mesma foi completada

corretamente;

6.2.2 O avaliador verifica o tempo gasto na execução de cada tarefa;

6.2.3 Após executar todas as tarefas, os participantes preenchem o questionário

de pós-execução do experimento;

6.2.4 Os participantes preenchem o questionário final sobre as duas abordagens

utilizadas.

7. O experimento é encerrado.

4.8 HIPÓTESES

Para o objetivo deste experimento foram definidas as hipóteses nulas (H₀i) e hipóteses

alternativas (H₁i) como suas correspondentes, onde i é o contador da hipótese. As hipóteses

nulas definidas para este experimento são:

• H₀₁: O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi considerado tão fácil quanto o processo utilizando

a abordagem com o Excel.

• H₀₂: O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi considerado tão útil quanto o processo utilizando a

abordagem com o Excel.

• H₀₃: O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi equivalente ao processo utilizando a abordagem

com o Excel em termos de tempo.

54

As hipóteses alternativas definidas para este experimento são:

• H₁₁: O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi considerado mais fácil do que o processo

utilizando a abordagem com o Excel.

• H₁₂: O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi considerado mais útil do que o processo utilizando

a abordagem com o Excel.

• H₁₃: O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi mais eficiente do que o processo utilizando a

abordagem com o Excel em termos de tempo.

4.9 ANÁLISE DOS RESULTADOS

Esta seção apresenta os resultados obtidos no experimento controlado realizado para

obter os dados das métricas definidas na Seção 4.3 . As métricas M1 e M2 foram obtidas

através dos questionários respondidos pelos participantes avaliando o SIGUAN com base nas

variáveis em que cada métrica está relacionada. A métrica M3 foi obtida através da análise do

tempo que cada participante levou para executar cada uma das tarefas.

A métrica M1, que leva em consideração as características de facilidade de uso

percebida, foi obtida através de um questionário respondido pelos participantes composto por

questões que avaliam o quão fácil é a utilizar o SIGUAN no planejamento e prescrição de

cardápios. A Tabela 6 apresenta as questões respondidas pelos participantes com relação a

facilidade de uso do SIGUAN.

Tabela 6. Questionário para a variável de Facilidade de Uso Percebida.

Índice Questão

Q1 Usar o SIGUAN facilitaria o planejamento e prescrição de cardápios.

Q2 Minha interação com o SIGUAN seria clara e compreensível.

Q3 Eu não precisaria consultar o manual do usuário muitas vezes ao usar o SIGUAN.

Q4 Usar o SIGUAN daria maior controle sobre o planejamento e prescrição de cardápios.

Q5 O SIGUAN me permitiria realizar tarefas mais rapidamente.

Q6 Eu acho o SIGUAN fácil de usar.

55

A Tabela 7 mostra os resultados obtidos através do questionário de avaliação da

facilidade de uso e os dados estatísticos de variância e desvio padrão. Os resultados mostram

que 50% dos participantes concordam e outros 50% concordam totalmente que o SIGUAN é

fácil de usar. Também é possível observar que 75% dos participantes concordam totalmente

que o SIGUAN facilita o processo de planejamento e prescrição de cardápios. 87,5% dos

participantes concordam que o SIGUAN permite realizar as tarefas de forma mais rápida em

comparação ao método tradicional utilizando o Excel.

Tabela 7. Resultados do questionário sobre facilidade de uso percebida.

Questão Concordo

totalmente

Concordo Indiferente Discordo Discordo

totalmente

Variância Desvio

Padrão

Q1 6 2 0 0 0 5,44 2,332

Q2 3 5 0 0 0 4,24 2,059

Q3 3 4 1 0 0 2,64 1,624

Q4 6 2 0 0 0 5,44 2,332

Q5 7 1 0 0 0 7,44 2,727

Q6 4 4 0 0 0 3,84 1,959

A métrica M2, definida com base na característica de utilidade percebida, também foi

obtida a partir dos resultados de um questionário respondido pelos participantes com questões

que avaliam o quanto o SIGUAN é útil no processo de planejamento e prescrição de

cardápios. As perguntas do questionário sobre utilidade percebida estão apresentadas na

Tabela 8.

Tabela 8. Questionário para a variável de Utilidade Percebida.

Índice Questão

Q1 O SIGUAN seria útil para o planejamento e prescrição de cardápios.

Q2 Acho fácil fazer com que o SIGUAN faça o que eu quero.

Q3 O SIGUAN atenderia às minhas necessidades relacionadas ao planejamento e

prescrição de cardápios.

Q4 Usar o SIGUAN para o planejamento e prescrição de cardápios aumentaria minha

produtividade.

Q5 O SIGUAN fornece orientação útil na realização de tarefas.

56

Q6 Usar o SIGUAN para o planejamento e prescrição de cardápios melhoraria meu

desempenho.

Os resultados do questionário bem como os dados estatísticos de variância e desvio

padrão estão apresentados na Tabela 9 e mostram que 85,5% dos participantes concordam

totalmente que o SIGUAN é útil no planejamento e prescrição de cardápios. 75% dos

participantes também concordam totalmente que o SIGUAN aumenta a produtividade na

realização das tarefas de criação e prescrição de cardápios. Além disso, 75% dos participantes

concordam totalmente que o SIGUAN atende às necessidades de relacionadas ao

planejamento e prescrição de cardápios.

Tabela 9. Resultados do questionário sobre utilidade percebida.

Questão Concordo

totalmente Concordo Indiferente Discordo

Discordo

totalmente

Variância Desvio

Padrão

Q1 7 1 0 0 0 7,44 2,727

Q2 4 4 0 0 0 3,84 1,959

Q3 6 2 0 0 0 5,44 2,332

Q4 6 2 0 0 0 5,44 2,332

Q5 3 4 1 0 0 2,64 1,624

Q6 5 3 0 0 0 4,24 2,059

A métrica M3, baseada na característica de esforço de trabalho, foi obtida através da

medição do tempo gasto por cada participante na realização de cada tarefa do experimento. A

Tabela 10 apresenta o tempo que cada participante levou para realização de das tarefas em

nas duas abordagens.

Tabela 10. Duração da execução das tarefas pelos participantes.

SIGUAN Excel SIGUAN Excel

Tempo de Duração Duração total por participante Grupo

P1 00:23:57 - - 00:38:27 01:02:24 1

P2 00:27:34 - - 00:49:51 01:17:25 1

P3 00:20:54 - - 00:26:57 00:47:51 1

P4 00:18:34 - - 00:21:22 00:39:56 1

P5 - 00:30:26 00:28:03 - 00:58:29 2

P6 - 00:34:28 00:28:04 - 01:02:32 2

57

P7 - 00:29:05 00:24:19 - 00:53:24 2

P8 - 00:33:51 00:22:41 - 00:56:32 2

Total 01:30:59 02:07:50 01:43:07 02:16:37 07:38:33 Ambos

A Tabela 11 mostra o tempo médio gasto pelos participantes na realização de cada

tarefa nas duas abordagens. Os resultados mostram que a abordagem automatizada utilizando

o SIGUAN proporcionou uma redução do tempo médio em 27% na realização de todas as

tarefas em comparação com a abordagem tradicional utilizando o Excel. Com base nesse

resultado, é possível afirmar que utilizar o SIGUAN causa uma redução do tempo gasto no

processo de criação e prescrição de cardápios. As tarefas 4 e 5, que compreendem a realização

do cálculo da prescrição e criação dos relatórios para as salas de preparação respectivamente,

apresentaram uma redução média de 85% do tempo gasto. Esse dado significa que o SIGUAN

reduz consideravelmente o tempo gasto na realização do cálculo da prescrição e geração de

relatórios, que são as tarefas que mais demandam tempo e esforço dos Nutricionistas de uma

UAN. Entretanto, as tarefas 1 e 2 apresentaram um aumento médio de 151,5% do tempo gasto

no cadastro dos insumos per capta e das preparações. Isso ocorre devido ao fato de que para

cadastrar um insumo per capita ou uma preparação no SIGUAN é necessário inserir uma

quantidade maior de informações a fim de armazenar mais detalhes dos registros, o que

proporciona um controle maior dos itens que são utilizados nas preparações e dos tipos de

preparações que são servidas para os usuários da UAN, além de proporcionar uma visão mais

abrangente e detalhada dos serviços oferecidos. Apesar de o processo de cadastro exigir um

tempo maior, esse é um procedimento que será realizado apenas uma vez no SIGUAN, pois

uma vez que os insumos e preparações estiverem cadastrados, o usuário poderá usá-los nos

cardápios sempre que quiser, sem a necessidade de inserir as mesmas informações sempre que

for criar um cardápio.

Tabela 11. Tempo médio de realização das tarefas.

SIGUAN Excel Redução (%) Aumento (%)

Tarefa 1 00:07:27 00:03:45 - 99%

Tarefa 2 00:09:34 00:03:09 - 204%

Tarefa 3 00:03:40 00:03:06 - 18%

Tarefa 4 00:02:30 00:13:42 82% -

Tarefa 5 00:01:06 00:09:21 88% -

58

A Tabela 12 apresenta os dados estatísticos de variância e desvio padrão do tempo de

duração de cada tarefa para as abordagens do SIGUAN e Excel. Os dados mostram que tanto

o desvio padrão quanto a variação foram relativamente baixos, o que significa que os valores

do tempo de duração obtidos estão próximos da média.

Tabela 12. Dados estatísticos do tempo de duração.

Abordagem Tarefas Variância Desvio Padrão

SIGUAN Tarefa 1 0,000000443 00:00:58

Tarefa 2 0,000001525 00:01:47

Tarefa 3 0,000000763 00:01:16

Tarefa 4 0,000003370 00:02:39

Tarefa 5 0,000000111 00:00:29

Excel Tarefa 1 0,000000520 00:01:02

Tarefa 2 0,000000481 00:01:00

Tarefa 3 0,000000832 00:01:19

Tarefa 4 0,000009143 00:04:21

Tarefa 5 0,000004339 00:03:00

4.10 ANÁLISE DAS MÉTRICAS

Esta seção tem como objetivo analisar os dados obtidos na execução do experimento e

responder as questões (definidas na Seção 4.2 ) a partir do resultado do cálculo de cada

métrica.

Q1: O SIGUAN é fácil de usar?

A métrica M1 foi obtida através da média ponderada dos resultados do questionário

sobre facilidade do uso percebida respondido pelos participantes do experimento. O resultado

obtido para M1 foi o seguinte:

• ∑Facilidade de uso percebida{Q1}/8 ≈ 4.75;





• ∑Facilidade de uso percebida{Q6}/8 = 4.5.

59

A partir dos valores obtidos é possível concluir que o SIGUAN foi considerado pelos

participantes como de fácil utilização. Dessa forma, a hipótese nula H₀₁ é rejeitada e a

hipótese alternativa H₁₁: “O processo de planejamento e prescrição de cardápios utilizando a

abordagem do SIGUAN foi considerado mais fácil do que o processo utilizando a abordagem

com o Excel” é aceita.

Q2: O SIGUAN ajuda no planejamento e prescrição de cardápios?

A métrica M2 foi obtida através dos resultados do questionário respondido pelos

participantes em relação a utilidade percebida. O resultado obtido para M2 foi o seguinte:

• ∑Utilidade percebida{Q1}/8 ≈ 4.9;

• ∑Utilidade percebida{Q2}/8 = 4.5;



• ∑Utilidade percebida{Q5}/8 ≈ 4.25;

• ∑Utilidade percebida{Q6}/8 ≈ 4.62.

Com base nos resultados obtidos, é possível afirmar que o SIGUAN foi considerado

útil pelos participantes do experimento controlado. Dessa forma a hipótese nula H₀₂ é

rejeitada e a hipótese alternativa H₁₂: “O processo de planejamento e prescrição de cardápios

utilizando a abordagem do SIGUAN foi considerado mais útil do que o processo utilizando a

abordagem com o Excel.” é aceita.

Q3: O SIGUAN é eficiente no processo de planejamento e prescrição de cardápios em

termos de tempo quando comparado com o método tradicional?

A métrica M3 foi obtida através da medição do tempo gasto por cada grupo na

execução das tarefas em cada abordagem. O resultado de M3 para o Grupo 1, que utilizou

primeiro a abordagem com o SIGUAN, foi o seguinte: ∑Tempo de duração da

tarefa{SIGUAN, Grupo 1} = 01:30:59, o tempo gasto pelo mesmo grupo na realização de

todas as tarefas utilizando o método tradicional com o Excel foi calculado por M3 como:

∑Tempo de duração da tarefa{Excel, Grupo 1} = 02:07:50.

O resultado de M3 para o Grupo 2, que utilizou primeiro a abordagem tradicional com

o Excel, foi o seguinte: ∑Tempo de duração da tarefa{Excel, Grupo 2} = 02:16:37, o tempo

gasto pelo mesmo grupo na realização de todas as tarefas utilizando o método automatizado

com o SIGUAN foi calculado por M3 como: ∑Tempo de duração da tarefa{SIGUAN, Grupo

2} = 01:43:07. Com base nesses resultados é possível afirmar que as o planejamento e

prescrição de cardápios foi realizado de forma mais rápida quando os grupos utilizaram o

60

SIGUAN. Dessa forma a hipótese nula H₀₃ é rejeitada e a hipótese alternativa H₁₃: “O

processo de planejamento e prescrição de cardápios utilizando a abordagem do SIGUAN foi

mais eficiente do que o processo utilizando a abordagem com o Excel em termos de tempo.” é

aceita.

4.11 AMEAÇAS À VALIDADE DO EXPERIMENTO

A validade de um experimento está relacionada ao nível de confiança do experimento

como um todo. Ou seja, o quão confiáveis são os elementos envolvidos nesse processo desde

a base teórica adotada até os resultados obtidos, bem como a forma como esses resultados são

apresentados (Lima et al., 2012). É possível identificar dois fatores que ameaçam a validade

do experimento realizado: (i) validade interna, (ii) validade externa e (iii) validade de

construção.

A validade interna define se o relacionamento observado entre o tratamento e o

resultado não foi influenciado por outro fator não controlado ou medido (Travassos, Gurov, &

Amaral, 2002). Em relação ao experimento executado, as seguintes ameaças a validade foram

identificadas:

1) Limitação de conhecimento dos participantes: a limitação de conhecimento e

experiência dos participantes em atividades de planejamento e prescrição de cardápios

pode afetar os resultados do experimento. Essa ameaça foi reduzida com a realização

do treinamento com os participantes antes da realização das tarefas.

2) Dificuldade em lembrar das fórmulas e conceitos: os participantes poderiam sentir

dificuldade em lembrar de conceitos importantes da UAN, de como realizar os

cálculos da prescrição ou de como realizar alguma operação no SIGUAN. Essa

ameaça foi tratada com a disponibilização de materiais de apoio como slides e o

manual do SIGUAN.

3) Desmotivação e cansaço: devido a longa duração do experimento, os participantes

poderiam se sentir fadigados ou perder a motivação ao longo do tempo. O

experimentador observou os participantes durante todo o experimento e sinais de

cansaço ou desmotivação não foram identificados. Este efeito pode ser justificado

devido ao fato dos participantes terem consciência da liberdade de abandonar o

experimento a qualquer momento.

4) Expectativa do experimentador ou dos participantes: a opinião do experimentador ou

a expectativa de um resultado positivo ou negativo de ambas as partes poderia gerar

resultados tendenciosos. Essa ameaça foi tratada ao manter os participantes apenas no

61

nível de execução do experimento. Os participantes não foram informados das etapas

do procedimento nem de como seriam realizadas as tarefas antes do experimento ser

executado. Além disso, o experimentador procurou não interferir ou dar opiniões nem

sugestões que pudessem influenciar os participantes durante a realização das tarefas.

5) Aprendizado: a maneira como o experimento foi planejado poderia proporcionar com

que os participantes aprendessem conforme fossem executando as tarefas em cada

abordagem, o que afetaria a opinião dos participantes. Para tratar essa ameaça os

participantes foram organizados de forma aleatória com relação a abordagem utilizada

e estação de trabalho. De acordo com (PFLEEGER, 1995), atribuir os tratamentos às

unidades experimentais de forma aleatória evita as fontes de viés das quais o

experimentador não possui controle.

A validade externa define as condições que limitam a habilidade de generalizar os

resultados de um experimento fora do ambiente planejado inicialmente (Travassos et al.,

2002). O experimento apresenta informações suficientes para ser reproduzido em outros

ambientes, porém, ainda é necessário executar o experimento mais vezes com tarefas

diferentes e um número maior de participantes para validar os resultados.

A validade de constructo define se um conjunto de variáveis reflete bem o constructo

a ser medido (Travassos et al., 2002). Essa ameaça foi tratada ao: (i) usar o método GQM para

organizar os passos necessários para determinar as ligações entre os objetivos do experimento

e os testes de hipóteses; (ii) usar questões (DAVIS, 1989) e escalas (LIKERT, 1932)

padronizadas para medir a opinião dos participantes.

62

5. CONCLUSÃO

Nesta Monografia foi apresentado o SIGUAN, um Sistema Integrado de Gestão de

Unidades de Alimentação e Nutrição que auxilia o nutricionista na criação e prescrição de

cardápios e no gerenciamento dos principais setores da UAN. Como contribuição para o

profissional de nutrição, o sistema desenvolvido proporciona mais agilidade na realização das

atividades do nutricionista e permite que os principais setores da UAN trabalhem de forma

integrada e eficiente proporcionando a centralização das informações e aumentando a

confiabilidade e a produtividade.

Um grande diferencial do trabalho apresentado nesta Monografia em relação aos

trabalhos já existentes é o fato do sistema ter sido planejado para ser utilizado por qualquer

tipo de UAN, seja ela institucional, situada dentro de uma empresa, escola ou universidade;

comercial, como restaurantes abertos ao público; ou presente em estabelecimentos de saúde

como hospitais. Outro diferencial é fato do SIGUAN ter sido desenvolvido com base no estilo

arquitetural REST, portanto oferece uma API RESTful que permite que suas funcionalidades

sejam expandidas ou integradas a sistemas já existentes.

Os resultados do experimento de avaliação do SIGUAN mostraram que: (i) os

participantes consideram o SIGUAN fácil de usar; (ii) os participantes consideram que o

SIGUAN é útil na realização de atividades de planejamento e prescrição de cardápios e (iii)

que o planejamento e prescrição de cardápios se torna mais eficiente com a abordagem

utilizando o SIGUAN do que com a abordagem tradicional com o Excel em termos de tempo.

A partir dos resultados obtidos pode-se concluir que o SIGUAN conseguiu oferecer

aos usuários participantes uma ferramenta útil na realização de atividades de planejamento e

prescrição de cardápios, de fácil utilização e que aumenta a produtividade exigindo menos

esforço de trabalho. Portanto, é possível concluir que o SIGUAN atingiu os objetivos

esperados.

5.1 TRABALHOS FUTUROS

Este trabalho surgiu de um projeto de extensão e foi desenvolvido sob orientação de

uma especialista da área de nutrição e professores do curso de Análise e Desenvolvimento de

Sistemas da Escola Agrícola de Jundiaí (EAJ) da Universidade Federal do Rio Grande do

Norte (UFRN). Os próximos passos são implantar o sistema inicialmente no Restaurante

Universitário da EAJ e futuramente permitir que o mesmo seja utilizado por outras UANs.

Como trabalhos futuros pretende-se desenvolver um módulo para a realização da

Avaliação Qualitativa das Preparações do Cardápio (AQPC) que será responsável por auxiliar

63

o nutricionista no planejamento e avaliação de um cardápio adequado do ponto de vista

nutricional analisando as preparações com respeito a variedade de nutrientes e em relação a

variedade de cores, textura, sabores, etc. das preparações servidas na UAN. Esse tipo de

serviço pode servir como ferramenta de educação alimentar e nutricional o que proporcionaria

mais qualidade de vida para os usuários da UAN.

64

REFERÊNCIAS

BALDUINO, R. (2007). Introduction to OpenUP (Open Unified Process). Organization,

1–9. Retrieved from https://eclipse.org/epf/general/OpenUP.pdf

BASILI, V. R. (1992). Software modeling and measurement: the Goal/Question/Metric

paradigm. Quality. https://doi.org/10.1016/S0164-1212(99)00035-7

BRAZ, C. C. M. Introdução ao Processo Unificado. DEVMEDIA. 2006.

CAMPOS, F. M., Prado, S. D., Ferreira, F. R., & Kraemer, F. B. (2016). Food service in the

scientific field of Food and Nutrition: Reflections about scientific conceptions and

research. Revista de Nutricao, 29(3), 425–433. https://doi.org/10.1590/1678-

98652016000300012

COLARES, L., & FREITAS, C. de. (2007). Processo de trabalho e saúde de trabalhadores

de uma unidade de alimentação e nutrição: entre a prescrição eo real do trabalho

Work process and workers’. Cad. Saúde Pública, 23(12), 3011–3020. Retrieved from

http://www.scielosp.org/pdf/csp/v23n12/21.pdf

CONSELHO FEDERAL DE NUTRICIONISTAS. Resolução CFN 600/2018. Dispõe sobre

a definição das áreas de atuação do nutricionista e suas atribuições, indica parâmetros

numéricos de referência por área de atuação e dá outras providências. 2018.

DAVIS, F. D. (1989). Perceived Usefulness, Perceived Ease of Use, and User Acceptance

of Information Technology. MIS Quarterly, 13(3), 319. https://doi.org/10.2307/249008

FERRO, Derival Alves; NETO, Mário Ferreira. A Importância do Sistema Integrado de

Gestão Empresarial Para as Instituições Privadas ou Públicas. 2016.

FONTOURA, L. M., PRICE, R. T. (2004). Usando GQM para Gerenciar Riscos em

Projetos de Software. 18. Simpósio Brasileiro de Engenharia de Software, 39–54.

Retrieved from http://www.lbd.dcc.ufmg.br/colecoes/sbes/2004/004.pdf

JEDLITSCHKA, A., CIOLKOWSKI, M., & PFAHL, D. (2008). Reporting experiments in

software engineering. In Guide to Advanced Empirical Software Engineering (pp. 201–

228). https://doi.org/10.1007/978-1-84800-044-5_8

KRUCHTEN, P. (2003). The Rational Unified Process: An Introduction. Science.

65

https://doi.org/10.1109/ICSE.2002.146346

KRUNTCHEN, P. (1995). Architectural blueprints–the” 4+ 1” view model of software

architecture. IEEE Software, 12(November), 42–50.

https://doi.org/10.1145/216591.216611

LARMAN, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development. Analysis.

https://doi.org/10.1016/j.nec.2006.05.008

LIKERT, R. (1932). A technique for the measurement of attitudes. Archives of

Psychology. https://doi.org/2731047

LIMA, V. C. M., SECA NETO, A. G. S., & Emer, M. C. F. P. (2012). Investigação

experimental e Práticas ágeis: ameaças à validade de experimentos envolvendo a

prática ágil Programação em Par. 3o Workshop Brasileiro de Métodos Ágeis, 12.

NUSEIBEH, B., & EASTERBROOK, S. (2000). Requirements engineering. Proceedings of

the Conference on The Future of Software Engineering - ICSE ’00, 35–46.

TRAVASSOS, G., GUROV, D., & AMARAL, E. (2002). Introdução à Engenharia de

Software Experimental. Programa de Engenharia de Sistemas e Computação

COPPE/UFRJ. https://doi.org/RT-ES 590/02, COPPE/UFRJ, 2002.

WAKULICZ, G. J. Sistemas de informações gerenciais. Universidade Federal de Santa

Maria, Colégio Politécnico, Rede e-Tec Brasil, 2016.

67

APÊNDICE A – DETALHAMENTO DE CASOS DE USO

UC 1. Gerenciar Usuários

Este caso de uso apresenta as ações do ator Nutricionista para realizar funcionalidades

básicas como cadastrar, buscar, atualizar e remover os usuários do sistema (RF002). Além do

Nutricionista, somente o usuário cadastrado pode atualizar seus próprios dados no sistema. Os

casos de uso secundários que fazem parte do gerenciamento de Usuários estão descritos na

Tabela 1.

Caso de Uso Objetivo

UC 1.1: Cadastrar Usuário O ator Nutricionista cadastra um novo usuário no

sistema.

UC 1.2: Buscar Usuário O ator Nutricionista buscar um usuário no sistema

UC 1.3: Atualizar Usuário O ator Nutricionista atualizar as informações de

um usuário no sistema;

UC 1.4: Atualizar Usuário O próprio usuário pode atualizar os seus dados no

sistema;

UC 1.5: Remover Usuário O ator Nutricionista desativa o usuário no sistema

Tabela 1. UC 1. Gerenciar Usuários.

UC 2. Gerenciar Insumos

Os insumos são os ingredientes que poderão ser utilizados em preparações, por

exemplo, arroz, feijão, café, entre outros. Devido ao requisito de gerenciar insumos (RF003),

este caso de uso foi criado para que os atores Nutricionista e Estagiário de Nutrição possam

gerenciar as funcionalidades de cadastrar, buscar, atualizar e remover os insumos do sistema.

68

Os casos de uso secundários que fazem parte de Gerenciar Estoque estão descritos na Tabela

2.


UC2.1: Cadastrar

Insumos

Os atores Nutricionista e Estagiário de Nutrição

realizam o cadastro de insumos no sistema

UC2.2: Buscar Insumos Os atores Nutricionista e Estagiário de Nutrição

realizam a busca de insumos cadastrados no

sistema

UC2.3: Atualizar Insumos Os atores Nutricionista e Estagiário de Nutrição

realizam a atualização dos insumos cadastrados

no sistema

UC2.4: Remover Insumos Os atores Nutricionista e Estagiário de Nutrição

realizam a remoção dos insumos no sistema

Tabela 2. UC 2 Gerenciar Insumos.

UC 3. Gerenciar Cortes

Os cortes no sistema são definidos como o tipo de técnica de corte (em cubos, fatias,

tirinhas, etc.) que poderá ser aplicada ao insumo durante a sua preparação. Por exemplo, o

tipo de corte “fatiado” poderia ser usado para especificar que o insumo batata deveria ser

cortado em fatias durante uma preparação. Devido ao requisito de gerenciar cortes (RF004),

este caso de uso foi criado para que os atores Nutricionista e Estagiário de Nutrição possam

gerenciar a funcionalidade de cadastrar, buscar, atualizar e remover os cortes do sistema. Os

casos de uso secundários que fazem parte de Gerenciar Cortes estão descritos na Tabela 3.


69

UC3.1: Cadastrar Cortes Os atores Nutricionista e Estagiário de Nutrição

realizam o cadastro de um corte no sistema

UC3.2: Buscar Cortes Os atores Nutricionista e Estagiário de Nutrição

realizam a busca de um corte cadastrados no

sistema

UC3.3: Atualizar Cortes Os atores Nutricionista e Estagiário de Nutrição

realizam a atualização dos cortes cadastrados no

sistema

UC3.4: Remover Cortes Os atores Nutricionista e Estagiário de Nutrição

realizam a remoção do corte no sistema

Tabela 3. UC 3. Gerenciar Cortes.

UC 4. Gerenciar Salas

As salas de preparação são os locais onde os alimentos são manuseados e preparados,

por exemplo, a Sala de Carnes onde os funcionários fazem os cortes das carnes, a Sala de

Vegetais onde os vegetais são cortados e as saladas são preparadas, a Sala de Lanches onde os

lanches são preparados, entre outros. Devido ao requisito de gerenciar salas (RF005), este

caso de uso foi criado para que os atores Nutricionista e Estagiário de Nutrição possam

gerenciar a funcionalidade de cadastrar, buscar, atualizar e remover as salas de preparação no

sistema. Os casos de uso secundários que fazem parte de Gerenciar Salas estão descritos na

Tabela 4.


UC4.1: Cadastrar Salas Os atores Nutricionista e Estagiário de Nutrição

realizam o cadastro de uma sala no sistema

70

UC4.2: Buscar Salas Os atores Nutricionista e Estagiário de Nutrição

realizam a busca de uma sala cadastrada no

sistema

UC4.3: Atualizar Salas Os atores Nutricionista e Estagiário de Nutrição

realizam a atualização de uma sala cadastrada no

sistema

UC4.4: Remover Salas Os atores Nutricionista e Estagiário de Nutrição

realizam a remoção de salas cadastradas no

sistema

Tabela 4. UC 4. Gerenciar Salas.

UC 5. Gerenciar Preparação

A preparação, popularmente conhecida como receita, determina como um conjunto de

insumos serão preparados, por exemplo, o tipo de corte, o local de preparo, a textura, etc.

Devido ao requisito RF007 de gerenciar preparações, foi criado este caso de uso para que os

atores Nutricionista e Estagiário de Nutrição possam gerenciar as funcionalidades de

cadastrar, buscar, atualizar e remover preparações do sistema. Os casos de uso secundários

que fazem parte de Gerenciar Preparação estão descritos na Tabela 5.


UC 5.1: Cadastrar

Preparação


realizam o cadastro da preparação no sistema

UC 5.2: Buscar

Preparação


realizam a busca da preparação cadastrados no

sistema

UC 5.3: Atualizar

Preparação


realizam a atualização das preparações

cadastrados no sistema

71

UC 5.4: Remover

Preparação


realizam a remoção das preparações no sistema

Tabela 5. UC 5 Gerenciar Preparação.

UC 6. Gerenciar Cardápios

Os cardápios são definidos no sistema como um conjunto de menus. Já os menus são

conjuntos de preparações para um dia organizadas em uma lista. Por exemplo, desjejum,

lanche da manhã, almoço, lanche da tarde, jantar e ceia. Devido ao requisito (RF006) de

gerenciar o cardápio, este caso de uso é especificado para que os atores Nutricionista e

Estagiário de Nutrição possam gerenciar a funcionalidade de cadastrar, buscar, atualizar e

remover os cardápios do sistema. Um Estagiário de Nutrição pode cadastrar cardápios, mas

antes de qualquer uso, estes deverão ser autorizados pelo Nutricionista responsável. Os casos

de uso secundários que fazem parte de Gerenciar Cardápio estão descritos na Tabela 6.


UC6.1: Cadastrar

Cardápio


realizam o cadastro de um cardápio no sistema

UC6.2: Buscar Cardápio Os atores Nutricionista e Estagiário de Nutrição

realizam a busca de cardápios cadastrados no

sistema

UC6.3: Atualizar

Cardápio


realizam a atualização dos cardápios cadastrados

no sistema

UC6.4: Remover

Cardápio


realizam a remoção dos cardápios no sistema

Tabela 6. UC 6. Gerenciar Cardápios.

UC 7. Gerenciar Unidades

72

As unidades são definidas nesse sistema como as embalagens de cada insumo, por

exemplo, um pacote de 1 quilo (kg) de arroz ou pacote de 500 gramas (g) de café. Devido ao

requisito (RF009) de gerenciar unidades este caso de uso foi criado para que os atores

Nutricionista, Estagiário de Nutrição e Almoxarife possam gerenciar as funcionalidades de

cadastrar, buscar, atualizar e remover as unidades do sistema. Os casos de uso secundários

que fazem parte de Gerenciar Unidades estão descritos na Tabela 7.


UC7.1: Cadastrar

Unidades

Os atores Nutricionista, Estagiário de Nutrição e

Almoxarife realizam o cadastro de unidades no

sistema

UC7.2: Buscar Unidades Os atores Nutricionista, Estagiário de Nutrição e

Almoxarife realizam a busca de unidades no

sistema

UC7.3: Atualizar

Unidades


Almoxarife realizam a atualização de unidades

cadastradas no sistema

UC7.4: Remover

Unidades


Almoxarife realizam a remoção de unidades no

sistema

Tabela 7. UC7 Gerenciar Unidades.

UC 8. Gerenciar Estoque

O estoque é definido no sistema como a quantidade de unidades de cada insumo

existente, por exemplo, existem 300 pacotes de 1 quilo (kg) de macarrão. Devido ao requisito

(RF008) de gerenciar estoque, este caso de uso foi criado para que os atores Nutricionista,

Estagiário de Nutrição e Almoxarife possam gerenciar as funcionalidades de cadastrar,

buscar, atualizar e remover os itens do estoque do sistema. Os casos de uso secundários que

fazem parte de Gerenciar Estoque estão descritos na Tabela 8.

73


UC 8.1: Cadastrar Item

no Estoque


Almoxarife realizam o cadastro de itens no

estoque no sistema.

UC 8.2: Buscar Item no

Estoque


Almoxarife realizam a busca de itens no estoque

cadastrados no sistema.

UC 8.3: Atualizar Item do

Estoque


Almoxarife realizam a atualização dos itens do

estoque cadastrados no sistema.

UC 8.4: Remover Item do

Estoque


Almoxarife realizam a remoção dos itens do

estoque cadastrados no sistema.

Tabela 8. UC 8 Gerenciar Estoque.

UC 9. Autenticação

A autenticação permite o acesso do usuário ao sistema. Esta ação pode ser realizada

pelos atores Nutricionista, Estagiário de Nutrição e Almoxarife ao inserir os dados de usuário

e senha cadastrados no sistema. Devido ao requisito (RF007) de realizar autenticação no

sistema, este caso de uso foi criado para que apenas os usuários autorizados possam ter acesso

às funcionalidades oferecidas pelo sistema. A descrição deste caso de uso é exibida na Tabela

9.


UC14.1: Realizar

Autenticação


Almoxarife realizam autenticação no sistema.

Tabela 9. UC 9 Autenticação.

74

UC 10. Emitir relatório

A emissão de relatórios está definida no sistema como a obtenção de variados

relatórios que podem ser obtidos a partir e uma prescrição, por exemplo a requisição diária de

insumos que contém a lista de todos os insumos que serão utilizados nas refeições de um dia.

Devido ao requisito (RF013) para emitir relatórios, foi criado esse caso de uso para que os

atores Nutricionista e Estagiário de Nutrição possam emitir relatórios a partir de uma

prescrição realizada. O caso de uso emitir relatório está descrito na Tabela 10.


UC10: Emitir Relatório Os atores Nutricionista e Estagiário de Nutrição

emitem relatórios no sistema.

Tabela 10. UC 10. Emitir Relatório.

UC 11. Gerenciar Prescrição

A prescrição do sistema é definida a partir da previsão do número de comensais para

cada refeição, por exemplo, há uma previsão de 200 comensais para o almoço e 150

comensais para o jantar. O nutricionista especifica o menu que deseja prescrever e as

previsões de comensais para cada refeição, a partir daí o sistema calcula a quantidade

necessária de insumos para cada preparação. Devido ao requisito (RF012) de gerenciar

prescrições foi criado este caso de uso para que o ator Nutricionista possa gerenciar as

funcionalidades de cadastrar, buscar, atualizar e remover as prescrições do sistema. Os casos

de uso secundários que fazem parte de Gerenciar Prescrição estão descritos na Tabela 11.


UC11.1: Cadastrar

prescrição

O ator Nutricionista realiza o cadastro de

prescrições no sistema

UC11.2: Buscar

prescrição

O ator Nutricionista realiza a busca de prescrições

cadastradas no sistema

75

UC11.3: Atualizar

prescrição

O ator Nutricionista realiza a atualização das

prescrições cadastradas no sistema

UC11.4: Remover

prescrição

O ator Nutricionista realiza a remoção das

prescrições cadastradas no sistema

Tabela 11. UC 11. Realizar Prescrição.

UC 12. Aplicar cardápio

O aplicar cardápio significa escolher um cardápio pré-cadastrado no sistema para

aplica-lo a semana atual do calendário. Para o requisito RF011 foi criado este caso de uso para

que os atores Nutricionista e Estagiário de Nutrição possam aplicar o cardápio e utilizá-lo

para criar uma prescrição. Os casos de uso secundários que fazem parte de Aplicar Cardápio

estão descritos na Tabela 12.


UC12.1: Aplicar

Cardápio

Os atores Nutricionista ou Estagiário realizam

uma aplicação de um cardápio à uma semana.

Tabela 12. UC 12. Aplicar Cardápio.

UC 13. Visualizar cardápio semanal

O cardápio da semana exibe o que será servido no Restaurante Universitário (RU)

durante a semana atual. O caso de uso Visualizar Cardápio Semanal está descrito na Tabela

13.


76

UC13.1: Visualizar

cardápio semanal

O usuário externo visualiza o cardápio com as

preparações da semana

Tabela 13. UC 13. Visualizar cardápio semanal.

77

APÊNDICE B – DIAGRAMA DE CLASSES COMPLETO

Figura 31. Diagrama de Classes completo.

FONTE: projeto SIGRU.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE … · desenvolvimento de um Sistema Integrado de...

Documents

Transcript of UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE … · desenvolvimento de um Sistema Integrado de...