Alguém Poderia Colocar na Norma Abnt

1 INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE MINAS GERAIS CAMPUS BAMBUÍ BACHARELADO ENGENHARIA DE COMPUTAÇÃO MARCAAI PLATAFORMA DE AGENDAMENTOS DE SERVIÇOS LOCAIS ENTREGA FINAL ARTHUR ALBINO RESENDE HÉRICA ALVES FERREIRA LUÍS ROBERTO DE OLIVEIRA SILVA THAINÁ ALEXIANY DOS SANTOS FERREIRA Disciplina Engenharia De Software Professor Felipe Lopes BAMBUÍ 2025 RESUMO 2 O presente trabalho tem como objetivo o desenvolvimento e a especificação de um sistema de serviços e agendamentos voltado para dispositivos móveis cujo propósito é facilitar a conexão entre clientes e prestadores de serviços por meio de uma plataforma digital integrada A proposta surge da necessidade de otimizar processos de agendamento que em muitos casos ainda são realizados de forma manual ou informal resultando em falhas de organização conflitos de horários e dificuldade no gerenciamento das informações O sistema permitirá que clientes realizem cadastro e autenticação visualizem prestadores de serviços com base em critérios como localização e disponibilidade consultem informações detalhadas dos profissionais e efetuem agendamentos de maneira simples e intuitiva Em contrapartida os prestadores de serviços poderão gerenciar seus perfis cadastrar serviços definir horários disponíveis e acompanhar os agendamentos realizados A plataforma contará ainda com o envio de notificações automáticas para confirmação e lembretes de compromissos contribuindo para a redução de faltas e desencontros A solução será desenvolvida seguindo o conceito mobilefirst priorizando a usabilidade em smartphones e adotando princípios modernos de design de interface e experiência do usuário UIUX O sistema fará uso de recursos nativos dos dispositivos móveis como notificações push integração com o calendário e geolocalização proporcionando maior praticidade e eficiência aos usuários A utilização da geolocalização permitirá sugerir prestadores de serviços próximos ao cliente enquanto a integração com o calendário facilitará a organização dos compromissos agendados Do ponto de vista técnico o sistema deverá atender a requisitos não funcionais relacionados à segurança da informação desempenho escalabilidade e disponibilidade garantindo a proteção dos dados pessoais dos usuários e o funcionamento adequado mesmo em cenários de conexões móveis instáveis ou alto volume de acessos simultâneos Além disso o projeto considera boas práticas de Engenharia de Software visando a construção de uma aplicação robusta confiável e preparada para evoluções futuras Dessa forma o trabalho propõe uma solução tecnológica moderna e acessível capaz de melhorar a experiência de clientes e prestadores de serviços promovendo organização eficiência e confiabilidade no processo de agendamento digital por meio de uma aplicação móvel de qualidade profissional 1 INTRODUÇÃO O avanço das tecnologias da informação e a popularização dos dispositivos móveis têm provocado mudanças significativas na forma como serviços são ofertados contratados e gerenciados A crescente demanda por soluções digitais que proporcionem praticidade agilidade e organização evidencia a necessidade de sistemas capazes de integrar clientes e 3 prestadores de serviços em um único ambiente reduzindo processos manuais e minimizando falhas decorrentes de métodos informais de agendamento Atualmente grande parte dos agendamentos de serviços ainda é realizada por meio de ligações telefônicas mensagens instantâneas ou anotações manuais o que pode resultar em conflitos de horários esquecimento de compromissos e dificuldade no controle das informações Além disso a ausência de uma plataforma centralizada dificulta a visualização de profissionais disponíveis a comparação de serviços e a gestão eficiente do tempo tanto para clientes quanto para prestadores Diante desse cenário este projeto propõe o desenvolvimento de um sistema de serviços e agendamentos voltado para dispositivos móveis com o objetivo de facilitar a interação entre clientes e prestadores de serviços por meio de uma plataforma digital integrada O sistema permitirá que clientes encontrem profissionais visualizem informações relevantes e realizem agendamentos de forma simples e intuitiva enquanto os prestadores poderão gerenciar seus perfis serviços e horários disponíveis de maneira organizada A solução será desenvolvida seguindo o conceito mobilefirst priorizando a usabilidade em smartphones e adotando princípios modernos de design de interface e experiência do usuário UIUX O sistema explorará recursos nativos dos dispositivos móveis como notificações push integração com o calendário e geolocalização visando proporcionar maior eficiência comodidade e confiabilidade no processo de agendamento Para garantir o funcionamento adequado da plataforma o sistema será definido a partir de um conjunto de regras de negócio requisitos funcionais requisitos não funcionais e requisitos de domínio os quais estabelecem as funcionalidades oferecidas as restrições técnicas os critérios de qualidade e as condições específicas do ambiente de aplicação Esses elementos são fundamentais para assegurar que o sistema atenda às necessidades dos usuários mantenha a segurança das informações e apresente desempenho e disponibilidade adequados A descrição detalhada das regras de negócio bem como dos requisitos funcionais não funcionais e de domínio encontrase apresentada na Seção 11 servindo como base para as etapas posteriores de análise modelagem e implementação do sistema Em síntese este capítulo tem como finalidade contextualizar o problema abordado apresentar a proposta do sistema e estabelecer as diretrizes iniciais do projeto fornecendo uma visão geral que orienta o desenvolvimento de uma solução tecnológica moderna acessível e alinhada às boas práticas da Engenharia de Software 11 Requisitos de Sistema Esta seção apresenta os principais requisitos do sistema MarcaAÍ contemplando regras de negócio requisitos funcionais e requisitos não funcionais Esses requisitos definem o comportamento esperado do sistema suas funcionalidades essenciais e as características de qualidade necessárias para garantir um funcionamento adequado seguro e eficiente 4 111 Regras de Negócio As regras de negócio estabelecem restrições e condições que orientam o funcionamento do sistema e garantem a integridade das informações Apenas usuários devidamente cadastrados poderão acessar as funcionalidades do sistema Um cliente só poderá realizar agendamentos em horários previamente definidos como disponíveis pelo prestador de serviços Um mesmo horário não poderá ser reservado por mais de um cliente Todo agendamento deverá ser confirmado ou recusado pelo prestador de serviços Cancelamentos e reagendamentos deverão respeitar regras de antecedência definidas pelo sistema O sistema deverá estar em conformidade com a Lei Geral de Proteção de Dados LGPD 112 Requisitos Funcionais Os requisitos funcionais descrevem as principais funcionalidades que o sistema deverá oferecer aos seus usuários Entre os requisitos funcionais considerados neste projeto destacam se O sistema deve permitir o cadastro de clientes solicitando informações como nome e mail telefone e senha O sistema deve permitir o cadastro de prestadores de serviços incluindo dados como nome especialidade endereço e horários de atendimento O sistema deve permitir que usuários autenticados realizem login por meio de email e senha O sistema deve possibilitar a atualização de dados do perfil do usuário de forma segura O sistema deve permitir que clientes busquem prestadores de serviços por nome tipo de serviço ou localização O sistema deve permitir a visualização do perfil completo do prestador incluindo serviços oferecidos avaliações e agenda disponível O sistema deve permitir que clientes realizem agendamentos informando data e horário O sistema deve enviar notificações automáticas de confirmação cancelamento ou lembrete de agendamentos O sistema deve utilizar geolocalização para exibir prestadores de serviços próximos ao cliente 5 O sistema deve permitir a visualização do histórico de agendamentos realizados pelo usuário 113 Requisitos Não Funcionais Os requisitos não funcionais definem critérios de qualidade desempenho segurança e usabilidade do sistema Para o sistema MarcaAÍ consideramse os seguintes requisitos não funcionais O sistema deve apresentar tempo de carregamento de páginas de até 3 segundos em condições normais de uso A aplicação deve possuir disponibilidade mínima de 99 do tempo mensal O sistema deve ser escalável suportando o aumento de usuários simultâneos sem degradação significativa de desempenho Todas as informações pessoais dos usuários devem ser armazenadas de forma segura e criptografada O sistema deve utilizar protocolos seguros de comunicação como HTTPS A interface deve ser intuitiva e responsiva adaptandose a diferentes tamanhos de tela celulares tablets e computadores O sistema deve permitir funcionamento adequado mesmo em conexões móveis instáveis O sistema deve manter rotinas automáticas de backup periódico dos dados O códigofonte do sistema deve ser modular e documentado facilitando a manutenção e evolução futura 2 Metodologia SCRUM Este capítulo apresenta a metodologia de desenvolvimento adotada no projeto do sistema MarcaAÍ baseada no framework ágil Scrum A utilização do Scrum justificase por sua abordagem iterativa e incremental que possibilita maior flexibilidade diante de mudanças nos requisitos além de promover entregas frequentes de funcionalidades com valor agregado ao usuário O Scrum é amplamente utilizado no desenvolvimento de software por favorecer a colaboração entre os membros da equipe a transparência do processo e a melhoria contínua No contexto do sistema MarcaAÍ essa metodologia permite o desenvolvimento gradual das funcionalidades possibilitando validações constantes e ajustes ao longo do projeto 21 Visão Geral da Metodologia Scrum A metodologia Scrum organiza o desenvolvimento em ciclos curtos denominados Sprints que possuem duração fixa e ao final de cada ciclo é entregue um incremento funcional do sistema Cada Sprint é planejada com base em prioridades definidas no Product Backlog garantindo que as funcionalidades mais relevantes sejam desenvolvidas primeiro 6 No projeto MarcaAÍ o Scrum foi aplicado para organizar o desenvolvimento das funcionalidades relacionadas ao cadastro de usuários agendamentos notificações geolocalização e gerenciamento administrativo assegurando maior controle do progresso do projeto 22 Papéis do Scrum Os papéis definidos pela metodologia Scrum e adotados neste projeto são Product Owner responsável por definir e priorizar os requisitos do sistema garantindo que o produto atenda às necessidades dos usuários Scrum Master responsável por garantir a correta aplicação da metodologia Scrum auxiliando a equipe na remoção de impedimentos Time de Desenvolvimento responsável pela implementação das funcionalidades do sistema incluindo análise desenvolvimento e testes 23 Artefatos do Scrum Os artefatos do Scrum garantem transparência e organização ao processo de desenvolvimento 231 Product Backlog O Product Backlog consiste em uma lista priorizada de funcionalidades descritas em forma de histórias de usuário Para o sistema MarcaAÍ o Product Backlog contempla funcionalidades como cadastro de clientes e prestadores login busca de serviços agendamento notificações e avaliações O Product Backlog completo do projeto encontrase apresentado no Apêndice A 232 Sprints e Sprint Backlog As Sprints correspondem aos ciclos de desenvolvimento nos quais um conjunto de itens do Product Backlog é selecionado para implementação O Sprint Backlog contém as funcionalidades escolhidas para cada Sprint bem como o status de execução O detalhamento das Sprints planejadas para o projeto está disponível no Apêndice B 233 Burn Down Chart 7 O Burn Down Chart é utilizado para acompanhar o progresso da Sprint indicando a quantidade de trabalho restante ao longo do tempo Esse gráfico auxilia a equipe no controle do prazo e no ajuste do planejamento quando necessário Os dados utilizados para a construção do Burn Down Chart estão apresentados no Apêndice C 24 Considerações sobre a Metodologia Adotada A aplicação da metodologia Scrum no projeto MarcaAÍ contribui para um desenvolvimento organizado flexível e colaborativo A divisão do trabalho em Sprints aliada ao uso de artefatos como Product Backlog e Burn Down Chart possibilita maior controle do andamento do projeto e entregas contínuas de valor ao usuário final 3 Diagrama de Casos de Uso 1 Realizar CadastroLogin Ator Usuário Comum Descrição Permite ao usuário criar uma conta ou autenticarse no sistema para acessar as funcionalidades Précondição Usuário não autenticado Póscondição Usuário autenticado no sistema Relacionamento include Buscar Serviço 2 Buscar Serviço Ator Usuário Comum Descrição Permite pesquisar serviços disponíveis por categoria prestador ou disponibilidade Précondição Usuário autenticado Póscondição Lista de serviços exibida Relacionamento include Agendar Serviço 3 Agendar Serviço Ator Usuário Comum Descrição Permite selecionar um serviço data e horário para solicitar o agendamento 8 Précondição Serviço selecionado Póscondição Agendamento registrado como pendente 4 Visualizar Atendimentos Ator Usuário Comum Descrição Exibe todos os agendamentos realizados pelo usuário Précondição Usuário autenticado Póscondição Lista de agendamentos exibida Relacionamento include Agendar Serviço 5 Cancelar Agendamento Ator Usuário Comum Descrição Permite cancelar um agendamento já solicitado Précondição Agendamento existente Póscondição Agendamento cancelado 6 Visualizar Agenda Pessoal Ator Prestador de Serviço Descrição Exibe os agendamentos do prestador organizados por data e horário Précondição Prestador autenticado Póscondição Agenda exibida Relacionamento include Gerenciar Meus Serviços 7 Confirmar Rejeitar Agendamento Ator Prestador de Serviço 9 Descrição Permite aceitar ou recusar solicitações de agendamento recebidas Précondição Agendamento pendente Póscondição Agendamento confirmado ou rejeitado Relacionamento include Gerenciar Meus Serviços 8 Gerenciar Meus Serviços Ator Prestador de Serviço Descrição Permite cadastrar editar ou remover serviços oferecidos Précondição Prestador autenticado Póscondição Serviços atualizados no sistema 9 Gerenciar Usuários Ator Administrador Descrição Permite cadastrar editar bloquear ou remover usuários do sistema Précondição Administrador autenticado Póscondição Dados dos usuários atualizados Relacionamento include Visualizar Todas as Agendas 10 Visualizar Todas as Agendas Ator Administrador Descrição Permite visualizar todos os agendamentos do sistema Précondição Administrador autenticado Póscondição Agendas exibidas para controle e auditoria Diagrama de Casos de Uso 10 31 Diagramas de Sequência 1 Diagrama 1 Agendamento e Cancelamento de Serviço 11 Participantes Usuário Sistema Banco de Dados Prestador de Serviço Fluxo principal agendar serviço 1 Usuário Sistema Realizar cadastrologin 2 Sistema Banco de Dados Validar usuário 3 Banco de Dados Sistema Usuário validado 4 Usuário Sistema Buscar serviço 5 Sistema Banco de Dados Consultar serviços 6 Banco de Dados Sistema Lista de serviços 7 Sistema Usuário Exibir serviços 8 Usuário Sistema Selecionar serviço 9 Sistema Banco de Dados Consultar horários disponíveis 10 Banco de Dados Sistema Horários disponíveis 11 Usuário Sistema Confirmar datahorário 12 Sistema Banco de Dados Registrar agendamento 13 Sistema Prestador de Serviço Notificar agendamento 14 Sistema Usuário Agendamento confirmado Fluxo alternativo cancelar agendamento 1 Usuário Sistema Cancelar agendamento 2 Sistema Banco de Dados Atualizar status do agendamento 3 Sistema Prestador de Serviço Notificar cancelamento Diagrama 2 Registro e Cancelamento de Agendamentos Participantes Usuário Sistema Banco de Dados Prestador de Serviço Fluxo Principal 1 Usuário Sistema Registrar agendamento 2 Sistema Banco de Dados Agendamento salvo 3 Sistema Prestador de Serviço Notificar agendamento 4 Sistema Usuário Agendamento confirmado Fluxo alternativo cancelar agendamento 1 Usuário Sistema Cancelar agendamento 2 Sistema Banco de Dados Alterar status 3 Sistema Prestador de Serviço Notificar cancelamento Resumo 12 Os diagramas mostram a troca de mensagens entre os atores e o sistema para agendar e cancelar serviços O primeiro é mais detalhado login busca horários O segundo é uma visão resumida focada no registro e cancelamento do agendamento 32 Diagramas de Atividades Figura 1 Figura 2 13 Figura 1 Diagramas de Atividades Agendar um novo horário Usuário 1 Início do processo 2 Selecionar serviço desejado 3 Visualizar calendário com horários disponíveis 4 Decisão horário disponível a Não retorna para visualizar o calendário b Sim prossegue 5 Escolher horário 6 Confirmar agendamento Sistema 1 Validar a disponibilidade do horário escolhido 2 Reservar o horário no sistema 3 Enviar confirmação do agendamento ao usuário Resultado horário reservado e confirmação enviada Figura 2 Diagrama de Atividades Cancelar Agendamento Usuário 14 1 Início do processo 2 Visualizar agendamentos existentes 3 Decisão confirmar cancelamento a Não processo é encerrado b Sim solicitar cancelamento do agendamento Sistema 1 Excluir o agendamento do sistema 2 Enviar notificação de cancelamento 3 Encerrar o processo Resultado agendamento cancelado e notificação enviada Resumo Os diagramas mostram o fluxo de atividades entre usuário e sistema para agendar e cancelar horários evidenciando decisões repetições e responsabilidades 33 Diagramas de Transição de Estados com os quadros de Estímulos e Estados 1 Diagramas de Transição de Estados Usuário Agendamentos de Serviços O diagrama representa os estados da aplicação do ponto de vista do usuário e como eles mudam conforme as ações realizadas Estados e Transições 1 Início Tela Inicial a Evento Selecionar Agendar Serviço b Ação Exibir tela de agendamento c Próximo estado Agendar Serviço 2 Agendar Serviço a Evento Informar data e hora válidas b Ação Registrar data e hora c Próximo estado Agendar Serviço d Evento Confirmar agendamento e Ação Validar dados f Próximo estado Escolher Serviço g Evento Selecionar Ver Histórico h Ação Consultar serviços passados i Próximo estado Histórico 15 3 Escolher Serviço a Evento Selecionar tipo de serviço b Ação Registrar tipo de serviço c Próximo estado Escolher Serviço d Evento Selecionar Ver Histórico e Ação Recuperar agendamentos f Próximo estado Histórico g Evento Selecionar Modificar ou Cancelar h Ação Abrir opções de edição i Próximo estado Editar Cancelar 4 Histórico a Evento Selecionar Voltar b Ação Retornar à seleção de serviço c Próximo estado Escolher Serviço 5 Meus Agendamentos a Evento Selecionar agendamento b Ação Exibir detalhes da agenda c Próximo estado Escolher Serviço d Evento Selecionar Editar e Ação Abrir edição do agendamento f Próximo estado Editar Cancelar g Evento Selecionar Cancelar h Ação Solicitar confirmação i Próximo estado Editar Cancelar j Evento Selecionar Logout k Ação Encerrar sessão l Próximo estado Logout 6 Editar Cancelar a Evento Confirmar edição b Ação Atualizar dados c Próximo estado Meus Agendamentos d Evento Confirmar cancelamento e Ação Remover agendamento f Próximo estado Meus Agendamentos g Evento Selecionar Logout h Ação Encerrar sessão i Próximo estado Logout 7 Logout a Estado final do fluxo do usuário 16 2 Diagrama de Transição de Estados Prestador de Serviços Cadastro de Serviços Este diagrama descreve os estados relacionados ao gerenciamento de serviços pelo prestador Estado e Transições 1 Início Tela Inicial a Evento Entrar como prestador b Ação Autenticar usuário prestador c Próximo estado Menu Principal 2 Menu Principal a Evento Selecionar Adicionar Serviço b Ação Abrir formulário de cadastro c Próximo estado Cadastrar Serviço d Evento Selecionar Meus Serviços e Ação Listar serviços cadastrados f Próximo estado Meus Serviços 3 Cadastrar Serviço a Evento Preencher dados do serviço b Ação Validar campos preenchidos c Próximo estado Dados Preenchidos d Evento Cancelar cadastro e Ação Descartar dados f Próximo estado Menu Principal 4 Dados Preenchidos a Evento Editar dados b Ação Permitir alteração dos campos c Próximo estado Dados Preenchidos d Evento Salvar serviço e Ação Registrar serviço no sistema f Próximo estado Meus Serviços 5 Meus Serviços a Evento Selecionar serviço b Ação Exibir opções do serviço c Próximo estado Editar Serviço d Evento Selecionar Excluir Serviço e Ação Solicitar confirmação 17 f Próximo estado Confirmação de Exclusão 6 Editar Serviço a Evento Editar informações b Ação Atualizar dados do serviço c Próximo estado Meus Serviços d Evento Cancelar edição e Ação Manter dados anteriores f Próximo estado Meus Serviços 7 Confirmação de Exclusão a Evento Confirmar exclusão b Ação Remover serviço do sistema c Próximo estado Serviço Excluído d Evento Cancelar exclusão e Ação Manter serviço cadastrado f Próximo estado Meus Serviços 8 Serviço Excluído a Evento Listar serviços b Ação Atualizar lista de serviços c Próximo estado Meus Serviços Resumo Os diagramas mostram todos os estados possíveis da aplicação e o quadro complementa detalhando evento ação executada e próximo estado garantindo rastreabilidade entre o modelo gráfico e o comportamento do sistema Capítulo 4 Etapa de Projeto 41 Contrato Agendamento de Serviço 18 42 Comentário sobre o contrato Agendamento de Serviço Nome da operação O nome da operação agendarServico deve ser o mesmo utilizado nos diagramas de sequência eou diagramas de classes garantindo consistência entre os artefatos de modelagem do sistema Tipo O tipo da operação foi definido como Sistema pois a operação representa uma funcionalidade oferecida diretamente pelo sistema como um todo Em outros contextos o tipo poderia ser uma Classe caso a responsabilidade estivesse claramente atribuída a um objeto específico do domínio Responsabilidades As responsabilidades descrevem em alto nível o que a operação realiza sem entrar em detalhes de implementação Elas indicam que a operação é responsável por registrar o agendamento validar a disponibilidade do prestador apresentar informações relevantes ao cliente e confirmar o agendamento Referências cruzadas As referências cruzadas indicam todos os casos de uso nos quais a operação agendarServico aparece Essa informação facilita o rastreamento entre requisitos casos de uso e operações do sistema Anotações 19 As anotações fornecem observações adicionais que podem ser úteis durante a fase de projeto como regras de negócio específicas políticas da plataforma ou possíveis algoritmos especiais a serem considerados na implementação Exceções As exceções representam situações anormais que devem ser tratadas pelo sistema geralmente quando algum dado de entrada é inválido ou quando uma condição necessária não é satisfeita como cliente não autenticado ou indisponibilidade do prestador de serviço Entrada A entrada descreve os dados que são fornecidos ao sistema para a execução da operação como identificadores data horário e endereço Esses dados normalmente correspondem aos parâmetros da operação Saída A saída indica as informações que são produzidas pelo sistema após a execução da operação como mensagens de confirmação registros de log ou outros retornos relevantes ao usuário ou ao próprio sistema Précondições As précondições descrevem as suposições sobre o estado do sistema antes da execução da operação como a existência de um cliente cadastrado ou de um serviço disponível Muitas dessas condições podem ser verificadas durante a implementação por meio de programação defensiva Póscondições As póscondições descrevem as alterações no estado do sistema após a execução da operação No contrato apresentado essas alterações podem ser classificadas nas seguintes categorias Criação de instâncias como a criação de um novo objeto do tipo Agendamento Modificação de atributos como a definição do status inicial do agendamento Formação de associações como a associação entre Agendamento Cliente Serviço e Prestador de Serviço 43 Contrato Prestador de Serviço 20 44 Comentário sobre o contrato Prestador de Serviço Nome da operação O nome da operação confirmarDisponibilidade deve ser o mesmo utilizado nos diagramas de sequência eou diagramas de classes assegurando a consistência entre os diferentes artefatos de modelagem do sistema Tipo O tipo da operação foi definido como Sistema pois a confirmação ou recusa de um agendamento é tratada como uma funcionalidade central do sistema Em uma modelagem alternativa essa operação poderia ser atribuída diretamente a uma classe como PrestadorServico dependendo das decisões de projeto Responsabilidades As responsabilidades descrevem em alto nível as ações realizadas pela operação como permitir que prestador confirme ou recuse um agendamento atualizar o estado do agendamento e notificar o cliente sobre a decisão tomada Referências cruzadas As referências cruzadas indicam os casos de uso nos quais a operação confirmarDisponibilidade é executada permitindo o rastreamento entre requisitos funcionais casos de uso e operações do sistema Anotações As anotações apresentam observações úteis para a fase de projeto como a possibilidade de o sistema sugerir automaticamente outro prestador em caso de recusa o que pode exigir algoritmos específicos de busca e priorização 21 Exceções As exceções representam situações em que a operação não pode ser executada corretamente geralmente causadas por dados inválidos ou estados inconsistentes do sistema como prestador não autenticado ou tentativa de confirmação fora do prazo permitido Entrada A entrada corresponde aos dados fornecidos ao sistema para a execução da operação incluindo o identificador do prestador o identificador do agendamento e o status da confirmação Saída A saída indica as informações que são produzidas pelo sistema após a execução da operação como a atualização do status do agendamento o envio de notificações ao cliente e o registro da ação em log Précondições As précondições descrevem as suposições sobre o estado do sistema antes da execução da operação como a existência de um agendamento válido e a autenticação do prestador Muitas dessas condições podem ser verificadas durante a implementação por meio de programação defensiva Póscondições As póscondições descrevem as alterações no estado do sistema após a conclusão da operação podendo ser classificadas nas seguintes categorias Modificação de atributos como a alteração do status do agendamento Associações formadas ou quebradas como a manutenção ou remoção da associação entre o agendamento e o prestador de serviço Criação de instâncias como a geração de uma nova notificação para o cliente As anotações apresentam observações úteis para a fase de projeto como a possibilidade de o sistema sugerir automaticamente outro prestador em caso de recusa o que pode exigir algoritmos específicos de busca e priorização Exceções 22 As exceções representam situações em que a operação não pode ser executada corretamente geralmente causadas por dados inválidos ou estados inconsistentes do sistema como prestador não autenticado ou tentativa de confirmação fora do prazo permitido Entrada A entrada corresponde aos dados fornecidos ao sistema para a execução da operação incluindo o identificador do prestador o identificador do agendamento e o status da confirmação Saída A saída indica as informações que são produzidas pelo sistema após a execução da operação como a atualização do status do agendamento o envio de notificações ao cliente e o registro da ação em log Précondições As précondições descrevem as suposições sobre o estado do sistema antes da execução da operação como a existência de um agendamento válido e a autenticação do prestador Muitas dessas condições podem ser verificadas durante a implementação por meio de programação defensiva Póscondições As póscondições descrevem as alterações no estado do sistema após a conclusão da operação podendo ser classificadas nas seguintes categorias Modificação de atributos como a alteração do status do agendamento Associações formadas ou quebradas como a manutenção ou remoção da associação entre o agendamento e o prestador de serviço Criação de instâncias como a geração de uma nova notificação para o cliente 23 Capítulo 5 Conclusão Este capítulo apresenta as considerações finais de todos os integrantes do grupo sobre o desenvolvimento do projeto destacando os aprendizados obtidos durante as etapas de análise e projeto bem como as perspectivas de continuidade evolução e possível implantação do sistema no futuro O desenvolvimento deste projeto permitiu compreender a importância das etapas de análise e projeto para a construção de um sistema bem estruturado e coerente A identificação dos requisitos e a modelagem do sistema foram fundamentais para entender o problema e planejar uma solução adequada reduzindo possíveis falhas durante o desenvolvimento Com este trabalho esperase alcançar uma base sólida para a implementação do sistema com possibilidade de melhorias e expansão no futuro Há perspectiva de continuidade do projeto podendo ser desenvolvido e implantado como uma solução real contribuindo para o aprendizado e para a aplicação prática dos conhecimentos adquiridos APÊNDICE APÊNDICE A PRODUCT BACKLOG Apêndice A Product Backlog ID Descrição Ator Prioridade Sprint PB01 Cadastro de cliente Cliente Alta Sprint 1 PB02 Cadastro de prestador Prestador Alta Sprint 1 PB03 Login de usuário Usuário Alta Sprint 1 PB04 Busca de prestadores Cliente Alta Sprint 2 PB05 Agendamentos de serviço Cliente Alta Sprint 2 APÊNDICE B SPRINT BACKLOG Apêndice B Sprint Backlog Sprint ID Funcionalidade Status 24 Sprint 1 PB01 Cadastro de cliente Concluído Sprint 1 PB02 Cadastro de prestador Concluído Sprint 1 PB03 Login de usuário Concluído Sprint 2 PB04 Busca de prestadores Em andamento Sprint 2 PB05 Agendamento Planejado APÊNDICE C BURN DOWN CHART Apêndice C Burn Down Chart Dia Horas Planejadas Horas Restantes 1 40 40 2 40 32 3 40 24 4 40 16 5 40 0 INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE MINAS GERAIS CAMPUS BAMBUÍ BACHARELADO ENGENHARIA DE COMPUTAÇÃO MARCAAI PLATAFORMA DE AGENDAMENTOS DE SERVIÇOS LOCAIS ENTREGA FINAL ARTHUR ALBINO RESENDE HÉRICA ALVES FERREIRA LUÍS ROBERTO DE OLIVEIRA SILVA THAINÁ ALEXIANY DOS SANTOS FERREIRA Disciplina Engenharia De Software Professor Felipe Lopes BAMBUÍ 2026 RESUMO O presente trabalho tem como objetivo desenvolver e especificar um sistema de serviços e agendamentos voltado para dispositivos móveis destinado a facilitar a conexão entre clientes e prestadores de serviços por meio de uma plataforma digital integrada A proposta surge da necessidade de otimizar processos de agendamento que em muitos contextos ainda são realizados de forma manual ou informal ocasionando falhas de organização conflitos de horários e dificuldades no gerenciamento das informações O sistema permitirá que os clientes realizem cadastro e autenticação visualizem prestadores de serviços com base em critérios como localização e disponibilidade consultem informações detalhadas dos profissionais e efetuem agendamentos de maneira simples e intuitiva Por sua vez os prestadores de serviços poderão gerenciar seus perfis cadastrar serviços definir horários disponíveis e acompanhar os agendamentos realizados A plataforma contará ainda com o envio de notificações automáticas para confirmação e lembretes de compromissos contribuindo para a redução de faltas e desencontros A solução será desenvolvida com base no conceito mobilefirst priorizando a usabilidade em smartphones e adotando princípios modernos de design de interface e experiência do usuário UIUX O sistema utilizará recursos nativos dos dispositivos móveis como notificações push integração com o calendário e geolocalização proporcionando maior praticidade e eficiência aos usuários A geolocalização possibilitará a sugestão de prestadores de serviços próximos ao cliente enquanto a integração com o calendário auxiliará na organização dos compromissos agendados Do ponto de vista técnico o sistema deverá atender a requisitos não funcionais relacionados à segurança da informação desempenho escalabilidade e disponibilidade assegurando a proteção dos dados pessoais dos usuários e o funcionamento adequado mesmo em cenários de conexões móveis instáveis ou com alto volume de acessos simultâneos Ademais o projeto considera a aplicação de boas práticas de Engenharia de Software visando à construção de uma aplicação robusta confiável e preparada para futuras evoluções Dessa forma o trabalho propõe uma solução tecnológica moderna e acessível capaz de aprimorar a experiência de clientes e prestadores de serviços promovendo maior organização eficiência e confiabilidade no processo de agendamento digital por meio de uma aplicação móvel de qualidade profissional Palavraschave Agendamento de serviços Aplicação móvel Mobilefirst Experiência do usuário Engenharia de Software SUMÁRIO 1 INTRODUÇÃO 5 11 Requisitos de Sistema 6 111 Regras de Negócio 6 112 Requisitos Funcionais 7 113 Requisitos Não Funcionais 7 2 METODOLOGIA SCRUM 9 21 Visão Geral da Metodologia Scrum9 22 Papéis do Scrum10 23 Artefatos do Scrum10 231 Product Backlog10 232 Sprints e Sprint Backlog11 233 Burn Down Chart11 24 Considerações sobre a Metodologia Adotada11 3 DIAGRAMA DE CASOS DE USO 12 31 Diagramas de Atividades 19 32 Diagramas de Transição de Estados com os quadros de Estímulos e Estados22 321 Diagramas de Transição de Estados Usuário Agendamentos de Serviços 22 322 Diagrama de Transição de Estados Prestador de Serviços Cadastro de Serviços 25 4 ETAPA DE PROJETO 28 41 Contrato Agendamento de Serviço 28 42 Comentário sobre o contrato Agendamento de Serviço 28 Nome da operação28 Tipo29 Responsabilidades29 Referências cruzadas29 Anotações29 Exceções29 Entrada29 Saída30 Précondições30 Póscondições30 5 CONCLUSÃO 34 REFERÊNCIAS BIBLIOGRÁFICAS35 APÊNDICE36 5 1 INTRODUÇÃO O avanço das tecnologias da informação e a popularização dos dispositivos móveis têm provocado mudanças significativas na forma como serviços são ofertados contratados e gerenciados A crescente demanda por soluções digitais que proporcionem praticidade agilidade e organização evidencia a necessidade de sistemas capazes de integrar clientes e prestadores de serviços em um único ambiente reduzindo processos manuais e minimizando falhas decorrentes de métodos informais de agendamento Atualmente grande parte dos agendamentos de serviços ainda é realizada por meio de ligações telefônicas mensagens instantâneas ou anotações manuais o que pode resultar em conflitos de horários esquecimento de compromissos e dificuldade no controle das informações Além disso a ausência de uma plataforma centralizada dificulta a visualização de profissionais disponíveis a comparação de serviços e a gestão eficiente do tempo tanto para clientes quanto para prestadores Diante desse cenário este projeto propõe o desenvolvimento de um sistema de serviços e agendamentos voltado para dispositivos móveis com o objetivo de facilitar a interação entre clientes e prestadores de serviços por meio de uma plataforma digital integrada O sistema permitirá que clientes encontrem profissionais visualizem informações relevantes e realizem agendamentos de forma simples e intuitiva enquanto os prestadores poderão gerenciar seus perfis serviços e horários disponíveis de maneira organizada A solução será desenvolvida seguindo o conceito mobilefirst priorizando a usabilidade em smartphones e adotando princípios modernos de design de interface e experiência do usuário UIUX O sistema explorará recursos nativos dos dispositivos móveis como notificações push integração com o calendário e geolocalização visando proporcionar maior eficiência comodidade e confiabilidade no processo de agendamento Para garantir o funcionamento adequado da plataforma o sistema será definido a partir de um conjunto de regras de negócio requisitos funcionais requisitos não funcionais e requisitos de domínio os quais estabelecem as funcionalidades oferecidas as restrições técnicas os critérios de qualidade e as condições específicas do ambiente de aplicação Esses elementos são fundamentais para assegurar que o sistema atenda às necessidades dos usuários mantenha a segurança das informações e apresente desempenho e disponibilidade adequados 6 A descrição detalhada das regras de negócio bem como dos requisitos funcionais não funcionais e de domínio encontrase apresentada na Seção 11 servindo como base para as etapas posteriores de análise modelagem e implementação do sistema Em síntese este capítulo tem como finalidade contextualizar o problema abordado apresentar a proposta do sistema e estabelecer as diretrizes iniciais do projeto fornecendo uma visão geral que orienta o desenvolvimento de uma solução tecnológica moderna acessível e alinhada às boas práticas da Engenharia de Software 11 Requisitos de Sistema Esta seção apresenta os principais requisitos do sistema MarcaAÍ contemplando regras de negócio requisitos funcionais e requisitos não funcionais Esses requisitos definem o comportamento esperado do sistema suas funcionalidades essenciais e as características de qualidade necessárias para garantir um funcionamento adequado seguro e eficiente 111 Regras de Negócio As regras de negócio definem as restrições e condições que orientam o funcionamento do sistema assegurando a integridade a consistência e a confiabilidade das informações gerenciadas pela plataforma Nesse sentido estabelecemse as seguintes diretrizes Apenas usuários devidamente cadastrados e autenticados poderão acessar as funcionalidades do sistema Os clientes poderão realizar agendamentos exclusivamente em horários previamente definidos como disponíveis pelos prestadores de serviços Um mesmo horário não poderá ser reservado simultaneamente por mais de um cliente evitando conflitos de agenda Todo agendamento realizado deverá ser confirmado ou recusado pelo prestador de serviços dentro do prazo estabelecido pelo sistema Cancelamentos e reagendamentos deverão respeitar regras de antecedência previamente definidas visando à organização da agenda e à redução de faltas O sistema deverá estar em conformidade com a Lei Geral de Proteção de Dados Lei nº 137092018 LGPD garantindo a segurança a privacidade e o tratamento adequado dos dados pessoais dos usuários 7 112 Requisitos Funcionais Os requisitos funcionais descrevem as funcionalidades que o sistema deverá oferecer aos seus usuários definindo o comportamento esperado da aplicação diante das interações realizadas Para este projeto foram estabelecidos os seguintes requisitos funcionais O sistema deve permitir o cadastro de clientes solicitando informações como nome email telefone e senha O sistema deve permitir o cadastro de prestadores de serviços incluindo dados como nome especialidade endereço e horários de atendimento O sistema deve permitir que usuários previamente cadastrados e autenticados realizem login por meio de email e senha O sistema deve possibilitar a atualização segura dos dados do perfil do usuário O sistema deve permitir que os clientes realizem buscas por prestadores de serviços com base em critérios como nome tipo de serviço ou localização O sistema deve permitir a visualização do perfil completo do prestador de serviços incluindo informações sobre serviços oferecidos avaliações de clientes e agenda disponível O sistema deve permitir que os clientes realizem agendamentos informando data e horário desejados conforme a disponibilidade do prestador O sistema deve enviar notificações automáticas para confirmação cancelamento e lembretes de agendamentos O sistema deve utilizar recursos de geolocalização para exibir prestadores de serviços próximos à localização do cliente O sistema deve permitir a visualização do histórico de agendamentos realizados pelos usuários 113 Requisitos Não Funcionais Os requisitos não funcionais estabelecem critérios de qualidade que orientam o desempenho a segurança a usabilidade e a manutenção do sistema Para o sistema MarcaAÍ foram definidos os seguintes requisitos não funcionais O sistema deve apresentar tempo de carregamento das páginas de até 3 segundos em condições normais de uso A aplicação deve garantir disponibilidade mínima de 99 do tempo mensal 8 O sistema deve ser escalável permitindo o aumento do número de usuários simultâneos sem degradação significativa do desempenho Todas as informações pessoais dos usuários devem ser armazenadas de forma segura utilizando mecanismos de criptografia O sistema deve utilizar protocolos seguros de comunicação como HTTPS para garantir a integridade e a confidencialidade dos dados trafegados A interface do sistema deve ser intuitiva e responsiva adaptandose a diferentes tamanhos de tela como smartphones tablets e computadores O sistema deve manter funcionamento adequado mesmo em cenários de conexões móveis instáveis O sistema deve realizar rotinas automáticas de backup periódico dos dados assegurando a recuperação das informações em caso de falhas O códigofonte do sistema deve ser modular organizado e devidamente documentado facilitando a manutenção e a evolução futura da aplicação 9 2 METODOLOGIA SCRUM Este capítulo descreve a metodologia de desenvolvimento adotada no projeto do sistema MarcaAÍ fundamentada no framework ágil Scrum A escolha dessa metodologia justificase por sua abordagem iterativa e incremental que possibilita maior flexibilidade frente a mudanças nos requisitos além de promover entregas frequentes de incrementos funcionais com valor agregado ao usuário final O Scrum é amplamente empregado no desenvolvimento de software por incentivar a colaboração entre os membros da equipe a transparência dos processos e a melhoria contínua do produto Diferentemente das metodologias tradicionais o Scrum permite adaptações constantes ao longo do ciclo de desenvolvimento o que se mostra especialmente adequado a projetos de sistemas digitais nos quais as necessidades dos usuários podem evoluir durante a execução do projeto No contexto do sistema MarcaAÍ essa metodologia possibilita o desenvolvimento progressivo das funcionalidades favorecendo validações contínuas identificação antecipada de falhas e ajustes conforme o feedback obtido 21 Visão Geral da Metodologia Scrum A metodologia Scrum organiza o desenvolvimento do software em ciclos curtos e iterativos denominados Sprints que possuem duração fixa geralmente entre duas e quatro semanas Ao final de cada Sprint é entregue um incremento funcional do sistema potencialmente utilizável o que permite a avaliação contínua do progresso do projeto Cada Sprint é planejada a partir de um conjunto de itens priorizados do Product Backlog garantindo que as funcionalidades consideradas mais relevantes ou críticas para o negócio sejam desenvolvidas primeiramente Essa priorização contribui para a entrega de valor desde as etapas iniciais do projeto reduzindo riscos e aumentando a satisfação dos usuários No projeto MarcaAÍ o Scrum foi aplicado para organizar o desenvolvimento das funcionalidades relacionadas ao cadastro e autenticação de usuários agendamentos de serviços envio de notificações utilização de geolocalização e gerenciamento administrativo da plataforma Dessa forma a metodologia proporcionou maior controle do progresso do projeto melhor distribuição das atividades e acompanhamento contínuo dos resultados alcançados 10 22 Papéis do Scrum A metodologia Scrum define papéis específicos cada um com responsabilidades bem delimitadas os quais foram adotados neste projeto com o objetivo de garantir a eficiência do processo de desenvolvimento Os papéis considerados são Product Owner responsável por representar os interesses dos usuários e das partes interessadas definindo e priorizando os requisitos do sistema no Product Backlog Esse papel assegura que o produto desenvolvido esteja alinhado às necessidades do negócio e dos usuários finais Scrum Master responsável por garantir a correta aplicação da metodologia Scrum atuando como facilitador do processo Cabe a esse papel auxiliar a equipe na remoção de impedimentos promover a melhoria contínua e assegurar o cumprimento dos princípios e práticas do framework Time de Desenvolvimento responsável pela implementação das funcionalidades do sistema O time é composto por profissionais que realizam atividades de análise desenvolvimento testes e integração sendo autoorganizado e responsável pela entrega dos incrementos ao final de cada Sprint 23 Artefatos do Scrum Os artefatos do Scrum são elementos fundamentais para garantir transparência organização e acompanhamento do progresso do projeto No desenvolvimento do sistema MarcaAÍ foram utilizados os principais artefatos definidos pelo framework 231 Product Backlog O Product Backlog consiste em uma lista priorizada de funcionalidades requisitos e melhorias a serem implementadas no sistema normalmente descritas na forma de histórias de usuário No projeto MarcaAÍ o Product Backlog contempla funcionalidades como cadastro de clientes e prestadores de serviços autenticação de usuários busca por serviços realização de agendamentos envio de notificações automáticas e sistema de avaliações Esse artefato é dinâmico e pode ser continuamente atualizado ao longo do projeto conforme surgem novas necessidades ou ajustes nos requisitos iniciais O Product Backlog completo do projeto encontrase apresentado no Apêndice A 11 232 Sprints e Sprint Backlog As Sprints correspondem aos ciclos de desenvolvimento nos quais um conjunto de itens do Product Backlog é selecionado para implementação Para cada Sprint é elaborado o Sprint Backlog que contém as funcionalidades escolhidas as tarefas associadas e o acompanhamento do status de execução No projeto MarcaAÍ as Sprints foram planejadas de forma a distribuir equilibradamente as funcionalidades do sistema permitindo entregas progressivas e testes contínuos O detalhamento das Sprints planejadas bem como os respectivos Sprint Backlogs está disponível no Apêndice B 233 Burn Down Chart O Burn Down Chart é um gráfico utilizado para monitorar o progresso de uma Sprint demonstrando a quantidade de trabalho restante ao longo do tempo Esse artefato auxilia a equipe na identificação de atrasos gargalos ou desvios no planejamento permitindo ajustes tempestivos durante a execução da Sprint No desenvolvimento do sistema MarcaAÍ o Burn Down Chart foi utilizado como ferramenta de controle e acompanhamento do andamento das atividades contribuindo para o cumprimento dos prazos estabelecidos Os dados utilizados para a construção do gráfico encontramse apresentados no Apêndice C 24 Considerações sobre a Metodologia Adotada A aplicação da metodologia Scrum no projeto MarcaAÍ contribuiu significativamente para um desenvolvimento organizado flexível e colaborativo A divisão do trabalho em Sprints aliada ao uso de artefatos como Product Backlog Sprint Backlog e Burn Down Chart possibilitou maior controle do andamento do projeto além de favorecer entregas contínuas de valor ao usuário final Dessa forma a metodologia adotada mostrouse adequada às características do projeto permitindo a adaptação a mudanças a melhoria contínua do produto e a construção de uma aplicação alinhada às necessidades dos usuários e às boas práticas da Engenharia de Software 12 3 DIAGRAMA DE CASOS DE USO O Diagrama de Casos de Uso constitui uma ferramenta fundamental da Linguagem de Modelagem Unificada UML sendo amplamente utilizado na Engenharia de Software para representar de forma gráfica e conceitual as funcionalidades do sistema sob a perspectiva dos usuários Esse tipo de diagrama permite identificar os atores envolvidos as interações estabelecidas com o sistema e os limites funcionais da aplicação contribuindo para a compreensão dos requisitos funcionais definidos no projeto No sistema MarcaAÍ os casos de uso foram modelados com o objetivo de representar as principais operações realizadas pelos diferentes tipos de usuários a saber Usuário Comum Prestador de Serviço e Administrador Cada ator possui responsabilidades específicas dentro da plataforma refletindo níveis distintos de acesso e funcionalidades Essa separação possibilita maior clareza na definição das permissões e contribui para a segurança e organização do sistema Os casos de uso associados ao Usuário Comum concentramse nas funcionalidades relacionadas ao acesso à plataforma e à contratação de serviços O processo iniciase com o caso de uso Realizar CadastroLogin que representa a porta de entrada para as demais funcionalidades do sistema A autenticação do usuário é uma précondição essencial para a execução de ações como Buscar Serviço Agendar Serviço Visualizar Atendimentos e Cancelar Agendamento Essas funcionalidades garantem que o usuário possa localizar serviços de interesse solicitar agendamentos conforme a disponibilidade do prestador e acompanhar ou cancelar compromissos previamente realizados O relacionamento do tipo include entre os casos de uso evidencia a dependência funcional existente entre determinadas ações Por exemplo a busca por serviços é um passo necessário para a realização de um agendamento assim como a visualização de atendimentos está diretamente relacionada à existência de agendamentos previamente efetuados Essa modelagem reforça a sequência lógica das interações e contribui para a consistência do comportamento do sistema No que se refere ao Prestador de Serviço os casos de uso estão voltados ao gerenciamento da oferta de serviços e ao controle da agenda As funcionalidades Visualizar Agenda Pessoal Confirmar ou Rejeitar Agendamento e Gerenciar Meus Serviços permitem que o prestador mantenha seus serviços atualizados organize seus horários de atendimento e decida sobre as solicitações recebidas Essa abordagem 13 assegura maior autonomia ao prestador e contribui para a confiabilidade do processo de agendamento uma vez que nenhuma solicitação é confirmada sem a sua validação O Administrador por sua vez possui um papel estratégico no controle e na manutenção da plataforma Os casos de uso Gerenciar Usuários e Visualizar Todas as Agendas permitem ao administrador supervisionar o funcionamento geral do sistema garantindo a integridade dos dados o cumprimento das regras de negócio e a possibilidade de auditoria dos agendamentos realizados Esse nível de acesso é fundamental para assegurar o correto funcionamento da aplicação e a resolução de eventuais inconsistências Além dos casos de uso foram descritos fluxos de interação que detalham a troca de mensagens entre os participantes do sistema O Diagrama 1 Agendamento e Cancelamento de Serviço apresenta um fluxo principal mais detalhado contemplando desde o cadastro e login do usuário até a confirmação do agendamento incluindo consultas ao banco de dados e notificações ao prestador de serviços Esse fluxo evidencia a sequência de etapas necessárias para a realização completa de um agendamento bem como o fluxo alternativo de cancelamento que garante a atualização do status e a comunicação entre as partes envolvidas Já o Diagrama 2 Registro e Cancelamento de Agendamentos apresenta uma visão mais simplificada do processo concentrandose nas etapas essenciais do registro e cancelamento de agendamentos Essa abordagem permite uma compreensão mais direta do comportamento central do sistema sendo útil para análises de alto nível e validações rápidas dos requisitos funcionais De forma geral os diagramas de casos de uso desenvolvidos para o sistema MarcaAÍ possibilitam uma visão clara e estruturada das interações entre usuários e sistema servindo como base para as etapas de implementação e testes A modelagem adotada contribui para o alinhamento entre os requisitos funcionais as regras de negócio e a arquitetura do sistema assegurando maior consistência e qualidade ao desenvolvimento da aplicação 1 Realizar CadastroLogin Ator Usuário Comum Descrição Permite ao usuário criar uma conta ou autenticarse no sistema para acessar as funcionalidades Précondição Usuário não autenticado 14 Póscondição Usuário autenticado no sistema Relacionamento include Buscar Serviço 2 Buscar Serviço Ator Usuário Comum Descrição Permite pesquisar serviços disponíveis por categoria prestador ou disponibilidade Précondição Usuário autenticado Póscondição Lista de serviços exibida Relacionamento include Agendar Serviço 3 Agendar Serviço Ator Usuário Comum Descrição Permite selecionar um serviço data e horário para solicitar o agendamento Précondição Serviço selecionado Póscondição Agendamento registrado como pendente 4 Visualizar Atendimentos Ator Usuário Comum Descrição Exibe todos os agendamentos realizados pelo usuário Précondição Usuário autenticado Póscondição Lista de agendamentos exibida Relacionamento include Agendar Serviço 5 Cancelar Agendamento Ator Usuário Comum Descrição Permite cancelar um agendamento já solicitado Précondição Agendamento existente Póscondição Agendamento cancelado 6 Visualizar Agenda Pessoal Ator Prestador de Serviço Descrição Exibe os agendamentos do prestador organizados por data e horário Précondição Prestador autenticado 15 Póscondição Agenda exibida Relacionamento include Gerenciar Meus Serviços 7 Confirmar Rejeitar Agendamento Ator Prestador de Serviço Descrição Permite aceitar ou recusar solicitações de agendamento recebidas Précondição Agendamento pendente Póscondição Agendamento confirmado ou rejeitado Relacionamento include Gerenciar Meus Serviços 8 Gerenciar Meus Serviços Ator Prestador de Serviço Descrição Permite cadastrar editar ou remover serviços oferecidos Précondição Prestador autenticado Póscondição Serviços atualizados no sistema 9 Gerenciar Usuários Ator Administrador Descrição Permite cadastrar editar bloquear ou remover usuários do sistema Précondição Administrador autenticado Póscondição Dados dos usuários atualizados Relacionamento include Visualizar Todas as Agendas 10 Visualizar Todas as Agendas Ator Administrador Descrição Permite visualizar todos os agendamentos do sistema Précondição Administrador autenticado Póscondição Agendas exibidas para controle e auditoria 16 Figura 1 Diagrama de Casos de Uso Fonte Próprio autor 2026 Diagrama 1 Agendamento e Cancelamento de Serviço Participantes Usuário Sistema Banco de Dados Prestador de Serviço Fluxo principal agendar serviço 1 Usuário Sistema Realizar cadastrologin 2 Sistema Banco de Dados Validar usuário 3 Banco de Dados Sistema Usuário validado 4 Usuário Sistema Buscar serviço 5 Sistema Banco de Dados Consultar serviços 6 Banco de Dados Sistema Lista de serviços 7 Sistema Usuário Exibir serviços 8 Usuário Sistema Selecionar serviço 9 Sistema Banco de Dados Consultar horários disponíveis 10 Banco de Dados Sistema Horários disponíveis 11 Usuário Sistema Confirmar datahorário 12 Sistema Banco de Dados Registrar agendamento 13 Sistema Prestador de Serviço Notificar agendamento 14 Sistema Usuário Agendamento confirmado Fluxo alternativo cancelar agendamento 1 Usuário Sistema Cancelar agendamento 17 2 Sistema Banco de Dados Atualizar status do agendamento 3 Sistema Prestador de Serviço Notificar cancelamento Figura 2 Fonte Próprio autor 2026 Figura 3 Transição de Estados Fonte Próprio autor 2026 O diagrama 1 Transição de Estados representado pela figura 3 exemplifica o Aplicativo de Agendamento de Serviços Cliente Representa o fluxo do usuário cliente no aplicativo O processo inicia na Tela Inicial onde o usuário pode agendar um 18 serviço Ao agendar seleciona data e hora e em seguida escolhe o tipo de serviço A partir daí o usuário pode Confirmar o agendamento Ver agendamentos atuais em Meus Agendamentos Editar ou cancelar um agendamento existente Consultar o histórico de serviços já realizados Sair do aplicativo Logout O diagrama mostra as transições entre visualizar modificar cancelar e consultar histórico cobrindo todo o ciclo de vida do agendamento do cliente Diagrama 2 Registro e Cancelamento de Agendamentos Participantes Usuário Sistema Banco de Dados Prestador de Serviço Fluxo Principal 1 Usuário Sistema Registrar agendamento 2 Sistema Banco de Dados Agendamento salvo 3 Sistema Prestador de Serviço Notificar agendamento 4 Sistema Usuário Agendamento confirmado Fluxo alternativo cancelar agendamento 1 Usuário Sistema Cancelar agendamento 2 Sistema Banco de Dados Alterar status 3 Sistema Prestador de Serviço Notificar cancelamento Figura 4 Transição de Estados diagrama 2 Fonte Próprio autor 2026 19 Diagrama 2 Transição de Estados Cadastro de Serviços Prestador apresentado pela figura 4 representa o fluxo do prestador de serviços Inicia na Tela Inicial com a opção de entrar como prestador acessando o Menu Principal A partir do menu o prestador pode Cadastrar um novo serviço preenchendo dados e salvando Editar serviços existentes Visualizar seus serviços em Meus Serviços Excluir um serviço passando por uma confirmação de exclusão Cancelar ações e retornar ao menu O diagrama detalha as transições entre cadastro edição listagem e exclusão de serviços garantindo controle completo do prestador sobre seus serviços no sistema Figura 5 Resumo dos diagramas Fonte Próprio autor 2026 31 Diagramas de Atividades Os Diagramas de Atividades são elementos da Linguagem de Modelagem Unificada UML utilizados para representar o fluxo de ações e decisões envolvidas na execução de um processo dentro de um sistema Esses diagramas permitem visualizar a sequência lógica das atividades identificar pontos de decisão paralelismo e responsabilidades entre os atores envolvidos contribuindo para a compreensão do comportamento dinâmico do sistema No contexto do sistema MarcaAÍ os Diagramas de Atividades foram elaborados com o objetivo de descrever de forma clara e estruturada os processos de agendamento e cancelamento de horários considerados funcionalidades centrais da aplicação Os diagramas destacam a interação entre o usuário e o sistema evidenciando as etapas executadas por cada parte e os resultados esperados ao final de cada fluxo 20 O Diagrama de Atividades 1 Agendar um novo horário representa o fluxo completo do processo de agendamento de um serviço O processo tem início com a seleção do serviço desejado pelo usuário seguida da visualização do calendário com os horários disponíveis Nesse ponto ocorre uma decisão fundamental a verificação da disponibilidade do horário selecionado Caso o horário não esteja disponível o fluxo retorna à etapa de visualização do calendário caracterizando um ciclo de repetição que garante a integridade da agenda e evita conflitos de horários Quando um horário disponível é selecionado o usuário confirma o agendamento acionando as ações correspondentes do sistema O sistema por sua vez valida a disponibilidade do horário escolhido realiza a reserva no banco de dados e envia a confirmação do agendamento ao usuário O fluxo é encerrado com o resultado do processo no qual o horário é efetivamente reservado e a confirmação é comunicada assegurando confiabilidade e transparência ao usuário Figura 6 Diagrama agendar um novo horário Fonte Próprio autor 2026 Diagramas de Atividades 1 Agendar um novo horário Usuário 1 Início do processo 2 Selecionar serviço desejado 3 Visualizar calendário com horários disponíveis 4 Decisão horário disponível a Não retorna para visualizar o calendário b Sim prossegue 5 Escolher horário 21 6 Confirmar agendamento Sistema 1 Validar a disponibilidade do horário escolhido 2 Reservar o horário no sistema 3 Enviar confirmação do agendamento ao usuário Resultado horário reservado e confirmação enviada O Diagrama de Atividades 2 Cancelar Agendamento descreve o fluxo relacionado à desistência de um compromisso previamente agendado O processo inicia se com a visualização dos agendamentos existentes pelo usuário seguida de um ponto de decisão que exige a confirmação da intenção de cancelamento Caso o usuário opte por não confirmar o cancelamento o processo é encerrado sem alterações no sistema preservando os dados existentes Em caso de confirmação o sistema executa as atividades necessárias para a exclusão do agendamento atualizando o banco de dados e enviando uma notificação de cancelamento às partes envolvidas Esse fluxo garante que o cancelamento seja registrado de forma adequada e que as informações estejam sempre atualizadas evitando inconsistências e desencontros entre usuários e prestadores de serviços De modo geral os Diagramas de Atividades apresentados evidenciam de forma clara o encadeamento das ações os pontos de decisão e as responsabilidades atribuídas ao usuário e ao sistema Essa modelagem contribui para a compreensão dos processos internos do sistema MarcaAÍ servindo como base para a implementação das funcionalidades e para a validação dos requisitos funcionais definidos no projeto Figura 7 Diagrama cancelar um agendamento Fonte Próprio autor 2026 22 Diagrama de Atividades 2 Cancelar Agendamento Usuário 1 Início do processo 2 Visualizar agendamentos existentes 3 Decisão confirmar cancelamento a Não processo é encerrado b Sim solicitar cancelamento do agendamento Sistema 1 Excluir o agendamento do sistema 2 Enviar notificação de cancelamento 3 Encerrar o processo Resultado agendamento cancelado e notificação enviada 32 Diagramas de Transição de Estados com os quadros de Estímulos e Estados Os Diagramas de Transição de Estados são utilizados na modelagem de sistemas para representar os diferentes estados que um objeto ou a própria aplicação pode assumir ao longo de sua execução bem como as transições entre esses estados em resposta a eventos específicos Essa abordagem permite compreender o comportamento dinâmico do sistema evidenciando como determinadas ações do usuário ou do sistema provocam mudanças de estado contribuindo para a clareza dos fluxos operacionais e para a validação dos requisitos funcionais No sistema MarcaAÍ os Diagramas de Transição de Estados foram elaborados para descrever o comportamento da aplicação sob duas perspectivas principais a do Usuário no contexto do agendamento de serviços e a do Prestador de Serviços no contexto do cadastro e gerenciamento de serviços Para cada diagrama foram definidos quadros complementares que detalham os estímulos eventos as ações executadas e os próximos estados garantindo rastreabilidade entre o modelo gráfico e o funcionamento do sistema 321 Diagramas de Transição de Estados Usuário Agendamentos de Serviços O diagrama de transição de estados do usuário representa as diferentes situações pelas quais a aplicação pode passar durante o processo de agendamento edição e cancelamento de serviços O fluxo iniciase no estado Início Tela Inicial no qual o 23 usuário tem acesso às opções principais do sistema A partir da seleção da opção Agendar Serviço o sistema responde exibindo a tela correspondente e transitando para o estado Agendar Serviço No estado Agendar Serviço o usuário informa dados como data e horário desejados que são registrados e validados pelo sistema Esse estado admite múltiplas interações permitindo ao usuário confirmar o agendamento ou acessar o histórico de serviços previamente realizados A confirmação do agendamento desencadeia a validação dos dados e a transição para o estado Escolher Serviço no qual o usuário seleciona o tipo de serviço desejado O estado Escolher Serviço permite ainda que o usuário consulte seu histórico de agendamentos ou opte por modificar ou cancelar um agendamento existente o que conduz ao estado Editar Cancelar Essa flexibilidade garante ao usuário maior controle sobre seus compromissos respeitando as regras de negócio previamente definidas O estado Histórico possibilita a visualização de serviços passados permitindo ao usuário retornar à seleção de serviços a qualquer momento Já o estado Meus Agendamentos concentra as informações detalhadas dos compromissos ativos oferecendo opções de edição cancelamento ou encerramento da sessão Por fim o estado Logout representa o término do fluxo do usuário no qual a sessão é encerrada de forma segura Estados e Transições 1 Início Tela Inicial a Evento Selecionar Agendar Serviço b Ação Exibir tela de agendamento c Próximo estado Agendar Serviço 2 Agendar Serviço a Evento Informar data e hora válidas b Ação Registrar data e hora c Próximo estado Agendar Serviço d Evento Confirmar agendamento e Ação Validar dados f Próximo estado Escolher Serviço g Evento Selecionar Ver Histórico h Ação Consultar serviços passados 24 i Próximo estado Histórico 3 Escolher Serviço a Evento Selecionar tipo de serviço b Ação Registrar tipo de serviço c Próximo estado Escolher Serviço d Evento Selecionar Ver Histórico e Ação Recuperar agendamentos f Próximo estado Histórico g Evento Selecionar Modificar ou Cancelar h Ação Abrir opções de edição i Próximo estado Editar Cancelar 4 Histórico a Evento Selecionar Voltar b Ação Retornar à seleção de serviço c Próximo estado Escolher Serviço 5 Meus Agendamentos a Evento Selecionar agendamento b Ação Exibir detalhes da agenda c Próximo estado Escolher Serviço d Evento Selecionar Editar e Ação Abrir edição do agendamento f Próximo estado Editar Cancelar g Evento Selecionar Cancelar h Ação Solicitar confirmação i Próximo estado Editar Cancelar j Evento Selecionar Logout k Ação Encerrar sessão l Próximo estado Logout 6 Editar Cancelar a Evento Confirmar edição 25 b Ação Atualizar dados c Próximo estado Meus Agendamentos d Evento Confirmar cancelamento e Ação Remover agendamento f Próximo estado Meus Agendamentos g Evento Selecionar Logout h Ação Encerrar sessão i Próximo estado Logout 7 Logout a Estado final do fluxo do usuário 322 Diagrama de Transição de Estados Prestador de Serviços Cadastro de Serviços O diagrama de transição de estados do prestador de serviços descreve o comportamento da aplicação no que se refere ao gerenciamento dos serviços ofertados O fluxo iniciase no estado Início Tela Inicial a partir do qual o prestador realiza sua autenticação sendo direcionado ao Menu Principal da aplicação No Menu Principal o prestador pode optar por adicionar um novo serviço ou visualizar os serviços já cadastrados Ao selecionar a opção Adicionar Serviço o sistema transita para o estado Cadastrar Serviço no qual o prestador preenche os dados necessários Após a validação dos campos o sistema avança para o estado Dados Preenchidos permitindo a edição ou o salvamento das informações O salvamento do serviço resulta na transição para o estado Meus Serviços onde todos os serviços cadastrados são listados Nesse estado o prestador pode selecionar um serviço específico para edição ou solicitar sua exclusão A exclusão de um serviço exige confirmação prévia representada pelo estado Confirmação de Exclusão assegurando que a remoção ocorra de forma consciente e evitando perdas acidentais de dados Após a confirmação da exclusão o sistema alcança o estado Serviço Excluído no qual a lista de serviços é atualizada retornando em seguida ao estado Meus Serviços Esse fluxo garante consistência das informações e transparência nas ações realizadas pelo prestador Estado e Transições 1 Início Tela Inicial 26 a Evento Entrar como prestador b Ação Autenticar usuário prestador c Próximo estado Menu Principal 2 Menu Principal a Evento Selecionar Adicionar Serviço b Ação Abrir formulário de cadastro c Próximo estado Cadastrar Serviço d Evento Selecionar Meus Serviços e Ação Listar serviços cadastrados f Próximo estado Meus Serviços 3 Cadastrar Serviço a Evento Preencher dados do serviço b Ação Validar campos preenchidos c Próximo estado Dados Preenchidos d Evento Cancelar cadastro e Ação Descartar dados f Próximo estado Menu Principal 4 Dados Preenchidos a Evento Editar dados b Ação Permitir alteração dos campos c Próximo estado Dados Preenchidos d Evento Salvar serviço e Ação Registrar serviço no sistema f Próximo estado Meus Serviços 5 Meus Serviços a Evento Selecionar serviço b Ação Exibir opções do serviço c Próximo estado Editar Serviço d Evento Selecionar Excluir Serviço e Ação Solicitar confirmação 27 f Próximo estado Confirmação de Exclusão 6 Editar Serviço a Evento Editar informações b Ação Atualizar dados do serviço c Próximo estado Meus Serviços d Evento Cancelar edição e Ação Manter dados anteriores f Próximo estado Meus Serviços 7 Confirmação de Exclusão a Evento Confirmar exclusão b Ação Remover serviço do sistema c Próximo estado Serviço Excluído d Evento Cancelar exclusão e Ação Manter serviço cadastrado f Próximo estado Meus Serviços 8 Serviço Excluído a Evento Listar serviços b Ação Atualizar lista de serviços c Próximo estado Meus Serviços Os Diagramas de Transição de Estados desenvolvidos para o sistema MarcaAÍ possibilitam uma visão detalhada e estruturada do comportamento dinâmico da aplicação evidenciando como os estados evoluem em resposta às ações dos usuários A utilização dos quadros de estímulos ações e próximos estados complementa a representação gráfica assegurando maior clareza rastreabilidade e alinhamento entre o modelo conceitual e a implementação do sistema Esses diagramas constituem portanto um importante instrumento de apoio às etapas de desenvolvimento testes e manutenção da aplicação contribuindo para a qualidade e confiabilidade do sistema proposto 28 4 ETAPA DE PROJETO 41 Contrato Agendamento de Serviço O contrato de Agendamento de Serviço descreve formalmente a operação responsável por registrar a solicitação de um serviço no sistema estabelecendo de maneira clara as responsabilidades entradas saídas précondições e póscondições associadas a essa funcionalidade Esse contrato tem como objetivo garantir que o processo de agendamento ocorra de forma consistente segura e alinhada aos requisitos funcionais definidos assegurando que apenas clientes autenticados possam realizar agendamentos e que a disponibilidade do prestador seja devidamente validada antes da confirmação Além disso o contrato contribui para a rastreabilidade entre os casos de uso os diagramas de sequência e as operações do sistema servindo como referência essencial para a fase de projeto e para a implementação correta das regras de negócio envolvidas no processo de agendamento Figura 8 contrato de agendamento de serviço Fonte Próprio autor 2026 42 Comentário sobre o contrato Agendamento de Serviço Nome da operação O nome da operação agendarServico foi definido de forma consistente com os nomes utilizados nos diagramas de sequência e nos diagramas de classes garantindo a coerência e o alinhamento entre os diferentes artefatos de modelagem do sistema Essa padronização facilita a compreensão do projeto e contribui para a rastreabilidade entre requisitos casos de uso e operações do sistema 29 Tipo O tipo da operação foi definido como Sistema uma vez que o agendamento de serviços representa uma funcionalidade central oferecida pelo sistema como um todo ao usuário final Em abordagens alternativas de modelagem orientada a objetos essa operação poderia ser atribuída a uma classe específica do domínio como Agendamento ou Prestador de Serviço dependendo das decisões arquiteturais adotadas Responsabilidades As responsabilidades da operação descrevem em nível conceitual as ações que devem ser executadas pelo sistema Nesse contexto a operação é responsável por registrar o agendamento solicitado pelo cliente validar a disponibilidade do prestador de serviço apresentar informações relevantes ao usuário e confirmar o agendamento sem detalhar aspectos técnicos de implementação Referências cruzadas As referências cruzadas indicam os casos de uso e demais artefatos nos quais a operação agendarServico está presente Esse mecanismo de rastreamento permite verificar a consistência entre requisitos funcionais casos de uso diagramas e contratos de operação auxiliando na manutenção e evolução do sistema Anotações As anotações fornecem observações complementares relevantes para a fase de projeto como a aplicação de regras de negócio específicas políticas da plataforma e a necessidade de considerar algoritmos especiais por exemplo para validação de horários sugestão de prestadores alternativos ou priorização de atendimentos Exceções As exceções representam situações anormais que devem ser tratadas adequadamente pelo sistema Entre essas situações destacamse a tentativa de agendamento por um cliente não autenticado a indisponibilidade do prestador de serviço no horário solicitado ou o fornecimento de dados inválidos ou incompletos Entrada A entrada da operação corresponde aos dados fornecidos pelo usuário ou por outros componentes do sistema para a execução do agendamento como identificadores do cliente do serviço e do prestador além da data horário e endereço do atendimento Esses dados geralmente são mapeados como parâmetros da operação 30 Saída A saída da operação referese às informações produzidas após a execução do processo de agendamento incluindo mensagens de confirmação ao usuário registros de log para fins de auditoria e outros retornos relevantes para o funcionamento do sistema Précondições As précondições descrevem o estado esperado do sistema antes da execução da operação como a existência de um cliente devidamente cadastrado e autenticado e a disponibilidade do serviço solicitado Muitas dessas condições podem ser verificadas durante a implementação por meio de técnicas de programação defensiva Póscondições As póscondições indicam as alterações no estado do sistema após a conclusão da operação podendo ser classificadas em Criação de instâncias como a criação de um novo objeto do tipo Agendamento Modificação de atributos como a definição do status inicial do agendamento Formação de associações como o vínculo estabelecido entre Agendamento Cliente Serviço e Prestador de Serviço 43 Contrato Prestador de Serviço O contrato do Prestador de Serviço define formalmente a operação responsável por permitir que o prestador confirme ou recuse solicitações de agendamento realizadas pelos usuários do sistema Esse contrato especifica as condições necessárias para a execução da operação como a autenticação do prestador e a existência de um agendamento válido além de descrever as responsabilidades do sistema na atualização do estado do agendamento e na comunicação da decisão ao cliente Dessa forma o contrato assegura que o fluxo de atendimento seja controlado rastreável e consistente com as regras de negócio estabelecidas contribuindo para a integridade das informações a confiabilidade do processo de agendamento e a correta integração entre os diferentes artefatos de modelagem utilizados no projeto 31 Figura 9 contrato de prestação de serviço Fonte Próprio autor 2026 44 Comentário sobre o contrato Prestador de Serviço Nome da operação O nome da operação confirmarDisponibilidade deve ser o mesmo utilizado nos diagramas de sequência eou diagramas de classes assegurando a consistência entre os diferentes artefatos de modelagem do sistema Tipo O tipo da operação foi definido como Sistema pois a confirmação ou recusa de um agendamento é tratada como uma funcionalidade central do sistema Em uma modelagem alternativa essa operação poderia ser atribuída diretamente a uma classe como PrestadorServico dependendo das decisões de projeto Responsabilidades As responsabilidades descrevem em alto nível as ações realizadas pela operação como permitir que prestador confirme ou recuse um agendamento atualizar o estado do agendamento e notificar o cliente sobre a decisão tomada Referências cruzadas As referências cruzadas indicam os casos de uso nos quais a operação confirmarDisponibilidade é executada permitindo o rastreamento entre requisitos funcionais casos de uso e operações do sistema 32 Anotações As anotações apresentam observações úteis para a fase de projeto como a possibilidade de o sistema sugerir automaticamente outro prestador em caso de recusa o que pode exigir algoritmos específicos de busca e priorização Exceções As exceções representam situações em que a operação não pode ser executada corretamente geralmente causadas por dados inválidos ou estados inconsistentes do sistema como prestador não autenticado ou tentativa de confirmação fora do prazo permitido Entrada A entrada corresponde aos dados fornecidos ao sistema para a execução da operação incluindo o identificador do prestador o identificador do agendamento e o status da confirmação Saída A saída indica as informações que são produzidas pelo sistema após a execução da operação como a atualização do status do agendamento o envio de notificações ao cliente e o registro da ação em log Précondições As précondições descrevem as suposições sobre o estado do sistema antes da execução da operação como a existência de um agendamento válido e a autenticação do prestador Muitas dessas condições podem ser verificadas durante a implementação por meio de programação defensiva Póscondições As póscondições descrevem as alterações no estado do sistema após a conclusão da operação podendo ser classificadas nas seguintes categorias Modificação de atributos como a alteração do status do agendamento Associações formadas ou quebradas como a manutenção ou remoção da associação entre o agendamento e o prestador de serviço Criação de instâncias como a geração de uma nova notificação para o cliente 33 As anotações apresentam observações úteis para a fase de projeto como a possibilidade de o sistema sugerir automaticamente outro prestador em caso de recusa o que pode exigir algoritmos específicos de busca e priorização Exceções As exceções representam situações em que a operação não pode ser executada corretamente geralmente causadas por dados inválidos ou estados inconsistentes do sistema como prestador não autenticado ou tentativa de confirmação fora do prazo permitido Entrada A entrada corresponde aos dados fornecidos ao sistema para a execução da operação incluindo o identificador do prestador o identificador do agendamento e o status da confirmação Saída A saída indica as informações que são produzidas pelo sistema após a execução da operação como a atualização do status do agendamento o envio de notificações ao cliente e o registro da ação em log Précondições As précondições descrevem as suposições sobre o estado do sistema antes da execução da operação como a existência de um agendamento válido e a autenticação do prestador Muitas dessas condições podem ser verificadas durante a implementação por meio de programação defensiva Póscondições As póscondições descrevem as alterações no estado do sistema após a conclusão da operação podendo ser classificadas nas seguintes categorias Modificação de atributos como a alteração do status do agendamento Associações formadas ou quebradas como a manutenção ou remoção da associação entre o agendamento e o prestador de serviço Criação de instâncias como a geração de uma nova notificação para o cliente 34 5 CONCLUSÃO Este capítulo apresentou as considerações finais acerca do desenvolvimento do projeto destacando os principais aprendizados obtidos ao longo das etapas de análise e projeto bem como as perspectivas de continuidade evolução e possível implantação futura do sistema O trabalho desenvolvido permitiu aos integrantes do grupo compreender de forma prática a relevância de uma modelagem bem estruturada para a construção de sistemas de informação coerentes eficientes e alinhados às necessidades dos usuários A identificação detalhada dos requisitos funcionais e não funcionais aliada à elaboração dos diagramas de casos de uso atividades transição de estados e contratos de operações mostrouse essencial para o entendimento do problema proposto e para o planejamento de uma solução adequada Essas etapas contribuíram para a redução de ambiguidades o aumento da clareza dos processos e a minimização de possíveis falhas nas fases posteriores de implementação Dessa forma o projeto resultou em uma base conceitual sólida que poderá subsidiar a futura implementação do sistema possibilitando sua ampliação aprimoramento e adaptação a novos cenários Há portanto perspectiva de continuidade do trabalho com potencial para evoluir para uma solução real promovendo a aplicação prática dos conhecimentos adquiridos e fortalecendo a formação acadêmica e profissional dos envolvidos 35 REFERÊNCIAS BIBLIOGRÁFICAS BEZERRA Eduardo Princípios de análise e projeto de sistemas com UML 2 ed Rio de Janeiro Elsevier 2015 BOOCH Grady RUMBAUGH James JACOBSON Ivar UML guia do usuário 2 ed Rio de Janeiro Elsevier 2012 FOWLER Martin UML essencial um breve guia para a linguagem padrão de modelagem de objetos 3 ed Porto Alegre Bookman 2011 IEEE COMPUTER SOCIETY Guide to the Software Engineering Body of Knowledge SWEBOK 3 ed Los Alamitos IEEE 2014 JACOBSON Ivar et al Engenharia de software orientada a objetos um processo guiado por casos de uso São Paulo AddisonWesley 1999 LARMAN Craig Utilizando UML e padrões uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo 3 ed Porto Alegre Bookman 2007 PRESSMAN Roger S MAXIM Bruce R Engenharia de software uma abordagem profissional 8 ed Porto Alegre AMGH 2016 SCHWABER Ken SUTHERLAND Jeff Guia do Scrum o guia definitivo do Scrum 2020 Disponível em httpsscrumguidesorg Acesso em 15 jan 2026 SOMMERVILLE Ian Engenharia de software 10 ed São Paulo Pearson Education do Brasil 2018 SUTHERLAND Jeff Scrum a arte de fazer o dobro do trabalho na metade do tempo São Paulo Leya 2014 36 APÊNDICE APÊNDICE A PRODUCT BACKLOG Apêndice A Product Backlog ID Descrição Ator Prioridade Sprint PB01 Cadastro de cliente Cliente Alta Sprint 1 PB02 Cadastro de prestador Prestador Alta Sprint 1 PB03 Login de usuário Usuário Alta Sprint 1 PB04 Busca de prestadores Cliente Alta Sprint 2 PB05 Agendamentos de serviço Cliente Alta Sprint 2 APÊNDICE B SPRINT BACKLOG Apêndice B Sprint Backlog Sprint ID Funcionalidade Status Sprint 1 PB01 Cadastro de cliente Concluído Sprint 1 PB02 Cadastro de prestador Concluído Sprint 1 PB03 Login de usuário Concluído Sprint 2 PB04 Busca de prestadores Em andamento Sprint 2 PB05 Agendamento Planejado APÊNDICE C BURN DOWN CHART Apêndice C Burn Down Chart Dia Horas Planejadas Horas Restantes 1 40 40 2 40 32 3 40 24 4 40 16 5 40 0