Projeto de Software

Projeto de Software Roteiro Aula Prática 2 ROTEIRO DE AULA PRÁTICA NOME DA DISCIPLINA Projeto de Software OBJETIVOS Definição dos objetivos da aula prática Desenvolver práticas de um projeto conforme os princípios da metodologia ágil Scrum INFRAESTRUTURA Instalações Computador com internet Materiais de consumo Descrição Quantidade de materiais por procedimentoatividade Computador 1 por aluno Software Sim X Não Em caso afirmativo qual IceScrum Trello e Asana Pago Não Pago X Tipo de Licença Gratuita Descrição do software As plataformas utilizadas são online e auxiliam as equipes a organizar acompanhar e gerenciar seu trabalho Equipamento de Proteção Individual EPI NSA PROCEDIMENTOS PRÁTICOS Desenvolvimento de etapas de um projeto ágil Atividade proposta Desenvolvimento de etapas de um projeto ágil Procedimentos para a realização da atividade 3 Problema Proposto Primeira etapa Nesta primeira etapa você é o cliente pense em um aplicativo que você deseja construir levante as funcionalidades e característica que você almeja no seu aplicativo Seja criativo e detalhista Segunda etapa Nesta etapa você não é mais o cliente e sim o Product Owner da empresa que vai elaborar o aplicativo proposto Suas responsabilidades são a Definir as funcionalidades do produto ou seja desenvolver o product backlog b Priorizar as funcionalidades de acordo com o valor de negócio c Montar um quadro do Scrum Kanban com as divisões de etapas tarefas data de entrega e responsáveis por atividade Para este item imagine que o desenvolvimento do seu aplicativo está em um estágio mais avançado por este motivo deve haver tarefas em todas as etapas Utilize uma das ferramentas propostas para montar o seu quadro Para a realização do problema proposto você deve utilizar pelo menos uma das ferramentas listadas a seguir o IceScrum httpswwwicescrumcom o Trello httpswwwtrellocom o Asana httpsasanacompt Checklist Criar a ideia de um aplicativo Desenvolver a solução de acordo com os princípios da metodologia ágil Scrum RESULTADOS Resultados da aula prática Elaborar um relatório que deverá conter introdução métodos resultados e conclusão sobre o assunto desenvolvido em aula prática UNIVERSIDADE CURSO ALUNO A RELATÓRIO AULA PRÁTICA PROJETO DE SOFTWARE CIDADE UF 2025 ALUNO A RELATÓRIO AULA PRÁTICA PROJETO DE SOFTWARE Relatório técnico apresentado à disciplina Projeto de Software como parte da avaliação da unidade curricular CIDADE UF 2025 SUMÁRIO 1 INTRODUÇÃO5 2 DESENVOLVIMENTO6 3 RESULTADOS8 4 CONCLUSÃO9 REFERÊNCIAS11 1 INTRODUÇÃO Esta aula prática da disciplina Projeto de Software teve como objetivo exercitar de forma aplicada os princípios do desenvolvimento ágil com Scrum desde a concepção do produto até a modelagem do fluxo de trabalho e do plano de sprints Para isso foi proposto o desenvolvimento do BusFácil um aplicativo móvel orientado à mobilidade urbana que apresenta previsão de chegada de ônibus por ponto estimativa de lotação dos veículos e um canal simples de relatos dos usuários A escolha desse domínio se justifica pela relevância social do transporte público pela disponibilidade de dados em tempo real em diversas cidades e pela aderência do problema a cenários típicos de produtos digitais com atualização contínua No contexto didático a prática foi estruturada em duas etapas complementares Na primeira o estudante atuou como cliente descrevendo as funcionalidades desejadas valores e restrições de uso do aplicativo o que permitiu explicitar necessidades reais dos usuários redução de incerteza no tempo de espera acessibilidade e comunicação com a gestão do serviço Na segunda etapa o estudante assumiu o papel de Product Owner transformando essas necessidades em histórias de usuário critérios de aceite priorização e planejamento de sprints além de definir Definition of Ready DoR e Definition of Done DoD elementos fundamentais para garantir qualidade e previsibilidade Para materializar o processo e dar visibilidade ao fluxo utilizouse o Trello como ferramenta de gestão visual O quadro foi organizado nas listas Backlog Icebox Planejado Sprint atual Em Progresso WIP 3 Em RevisãoTestes Pronto para Release e Concluído com data refletindo um estado avançado do projeto com cartões distribuídos em todas as etapas As histórias US01US06 e US12 foram planejadas para o MVP da Sprint 1 incluindo tarefas técnicas já em progresso por exemplo implementação de GPS e API de previsão e atividades em verificação de qualidade enquanto itens de evolução como favoritosalertas moderação de relatos e painel de qualidade permaneceram priorizados no backlog para sprints seguintes A visão do produto define o BusFácil como uma solução que empodera o cidadão com informação confiável e em tempo real sobre ônibus urbanos favorecendo decisões de deslocamento mais eficientes Como referências de valor e acompanhamento foram descritas métricas de sucesso como tempo médio para localizar uma linha no app acurácia da previsão de chegada erro absoluto médio engajamento com favoritos e volume de relatos moderados Além dos requisitos funcionais foram destacados requisitos não funcionais de desempenho e disponibilidade bem como conformidade com a LGPD por meio de consentimento explícito e telemetria controlada US12 A aplicação de Scrum nesta prática priorizou a entrega iterativa e incremental de valor com sprints de duas semanas reuniões de acompanhamento Daily e momentos de inspeção e adaptação Review e Retrospectiva O uso de histórias INVEST e critérios de aceite verificáveis buscou reduzir ambiguidades e facilitar a validação pela perspectiva do usuário final A limitação de WIP trabalho em progresso na lista Em Progresso foi empregada para melhorar foco e fluxo ao mesmo tempo em que as regras de passagem para Em RevisãoTestes e Pronto para Release alinharam o time à DoD acordada Do ponto de vista pedagógico a atividade promoveu o desenvolvimento de competências alinhadas às diretrizes da disciplina comunicação clara de requisitos priorização por valor de negócio planejamento realista de capacidade rastreabilidade entre histórias tarefas e releases e gestão visual do trabalho O recorte do MVP favoreceu a construção de um caminho feliz GPS previsão busca relatos consentimento de dados permitindo validar hipóteses centrais do produto antes de investir em funcionalidades periféricas Este relatório está organizado da seguinte forma na seção de Métodos descrevem se o processo ágil adotado as convenções do quadro o esquema de priorização e a cadência de sprints Em Resultados apresentamse o backlog inicial a distribuição dos cartões por lista o estado da Sprint 1 e as entregas concluídas Por fim a Conclusão discute os aprendizados limitações e próximos passos recomendados incluindo a avaliação com usuários e o ajuste do backlog à luz das métricas levantadas 2 DESENVOLVIMENTO O desenvolvimento do BusFácil foi organizado em sprints de duas semanas e conduzido integralmente com Scrum usando o Trello para dar transparência ao fluxo Logo no início foram definidas as convenções de trabalho histórias no formato INVEST critérios de aceite verificáveis Definition of Ready e Definition of Done e criado o quadro com as listas Backlog Icebox Planejado Sprint atual Em Progresso WIP 3 Em RevisãoTestes Pronto para Release e Concluído com data Essa estrutura permitiu visualizar em tempo real o estado do projeto ideias e evoluções permaneceram no Backlog o MVP da Sprint 1 foi destacado em Planejado as tarefas ativas ficaram limitadas pelo WIP em Em Progresso e o avanço para RevisãoTestes e Release seguiu a DoD acordada A Sprint 1 foi planejada para entregar um MVP navegável que cobrisse o caminho feliz do usuário localizar um ponto consultar previsão de chegada decidir com base na lotaçãoacessibilidade buscar linhas pelo nomecódigo relatar problemas e em paralelo assegurar conformidade de dados Por isso foram priorizadas as histórias US01 GPS e pontos US02 previsão por pontoETA US03 lotação e acessibilidade US05 busca US06 relatos com foto e US12 consentimento LGPD e telemetria Cada card recebeu critérios de aceite claros por exemplo atualização do ETA a cada 30 segundos ícones padronizados de lotação e acessibilidade confirmação do relato e status de acompanhamento além de estimativas em Story Points para apoiar a capacidade da sprint Na execução o time manteve o foco com limite de WIP em Em Progresso evitando dispersão e trocas constantes de contexto Iniciouse pela base técnica a tarefa US01 Implementação GPS tratou permissões de localização exibição de pinos no mapa e atualização ao panzoom em seguida a US02 API Previsão v1 expôs um endpoint de ETA por ponto com cache leve e renovação periódica e a US06 Tela de Relato upload estruturou o formulário com validações e registro do envio À medida que as tarefas cumpriam os critérios técnicos os cards migravam para Em RevisãoTestes onde foram verificados comportamento desempenho e aderência aos critérios ex US05 Busca QA checou autocomplete e histórico US01 GPS Code Review avaliou precisão e padrões US02 API Previsão Testes funcionais mediu latência e renderização correta do ETA A qualidade foi tratada como parte do fluxo não como etapa final O Pipeline CI registrado em Concluído garantiu build e testes automatizados a cada alteração enquanto a telemetria com consentimento US12 viabilizou medir indicadores essenciais do produto desde o MVP como tempo para localizar uma linha e taxa de uso de favoritos Também foram consideradas metas de desempenho tempo de resposta 800 ms para a consulta de ETA e boas práticas de acessibilidade desde a base ainda que o modo específico de alto contraste e TTS US09 esteja planejado para sprints seguintes O gerenciamento de riscos esteve presente durante toda a sprint Três pontos receberam atenção a disponibilidade de dados em tempo real a acurácia da previsão em horários de pico e a adesão do usuário ao consentimento de dados Para mitigar o time definiu fallback com horários programados quando o feed estiver indisponível sinalização de confiabilidade do ETA na interface e monitoramento contínuo do erro absoluto médio MAE por linha e por ponto Esses mecanismos foram registrados nos cards e vinculados ao Release R1 Sprint 1 que consolida o escopo pronto para entrega Por fim o Backlog Icebox permaneceu alimentado com evoluções que ampliam valor e retenção como US04 favoritos e alertas US07 moderação de relatos e US08 painel de qualidade além de US10 notificações configuráveis e US11 i18n Essa organização deixou claro para a turma o que compõe o MVP e o que fica para as próximas iterações mantendo a rastreabilidade entre histórias tarefas testes e releases Com isso o quadro do Trello espelha um projeto em estado avançado há trabalho planejado com critérios objetivos execução limitada por WIP verificação sistemática em testesrevisão e um pacote de release pronto alinhado à DoD e às metas de aprendizado da disciplina 3 RESULTADOS Como resultado da aula prática o projeto BusFácil alcançou um estado visível de maturidade no quadro do Trello com cartões distribuídos em todas as listas e evidências de fluxo contínuo O Backlog Icebox permaneceu como espaço de evolução do produto contendo itens de retenção e transparência como favoritos e alertas moderação de relatos e painel de qualidade devidamente priorizados como ShouldCould A lista Planejado Sprint atual concentrou o escopo do MVP da Sprint 1 reunindo as histórias essenciais para permitir o caminho completo do usuário localizar o ponto consultar a previsão decidir com base em lotação e acessibilidade buscar linhas e relatar problemas além da conformidade com a LGPD por meio do consentimento e telemetria básica A execução prática ficou evidente na lista Em Progresso WIP 3 onde as primeiras tarefas técnicas foram abertas e limitadas por WIP para manter foco implementação do GPS permissões pinos e atualização com o movimento do mapa exposição da API de previsão com atualização periódica e cache leve e a construção da tela de relatos com validações e upload de imagem Concluídas as etapas técnicas de cada item os cartões avançaram para Em RevisãoTestes onde foram verificados critérios de aceite desempenho e aderência ao padrão de código em especial a busca passou por QA funcional a tarefa de GPS por code review com foco em precisão e a API de previsão por testes de latência e renderização correta do ETA No tocante a prontidão de entrega foi preparado o Release R1 Sprint 1 consolidando as histórias do MVP que satisfizeram a Definition of Done Em Concluído com data registraramse entregas que sustentam a qualidade do processo e a medição do produto o pipeline de CI com build e testes automatizados as definições de DoRDoD formalizadas e a base de consentimento LGPD com telemetria optinoptout Esses resultados reforçam que a equipe conseguiu sair do planejamento para um pacote funcional validável assegurando rastreabilidade entre história tarefa teste e release além de condições para aprender com dados reais na iteração seguinte Figura 1 Quadro Trello do projeto BusFácil em estado avançado com histórias do MVP planejadas tarefas em progresso itens em revisãotestes release preparado e entregas concluídas CI DoRDoD e LGPD 4 CONCLUSÃO A aula prática permitiu aplicar Scrum de ponta a ponta em um contexto realista de mobilidade urbana transformando necessidades de usuários em histórias priorizadas com critérios de aceite e um fluxo de trabalho visível no Trello O MVP da Sprint 1 foi estruturado para validar o caminho feliz do BusFácil localizar pontos consultar previsão de chegada considerar lotaçãoacessibilidade buscar linhas e relatar problemas enquanto requisitos transversais de qualidade de processo DoRDoD CI e governança de dados consentimento LGPD e telemetria foram incorporados desde o início O uso disciplinado de limite de WIP e checklists reduziu retrabalho facilitou inspeçãoadaptação nas cerimônias e preparou um Release R1 com rastreabilidade clara entre história tarefa teste e entrega Os principais aprendizados incluem i a importância de critérios de aceite objetivos para orientar implementação e testes ii o valor de métricas de produto desde o MVP tempo para encontrar linha acurácia de ETA apoiando decisões baseadas em dados iii o papel de riscos mapeados e planos de mitigação indisponibilidade do feed em tempo real variação de acurácia em pico adesão ao consentimento para manter previsibilidade e iv a necessidade de tratar acessibilidade e desempenho como requisitos de produto não apenas técnicos Como limitações o escopo do MVP não cobre ainda recursos de retenção favoritosalertas e transparência ampliada painel de qualidade que permanecem priorizados para as próximas sprints Como próximos passos recomendase executar testes de usabilidade com usuários reais medir sistematicamente o MAE do ETA por linhaponto evoluir alertas e favoritos para aumentar engajamento implementar moderação de relatos para qualidade informacional e concluir o modo acessível alto contrasteTTS Em paralelo é desejável ampliar automações ButlerTrello e pipeline e adotar revisões técnicas regulares para manter a Definition of Done efetiva Esses desdobramentos consolidam o ciclo ágil de entrega de valor aprendizagem e replanejamento fortalecendo a maturidade do time e do produto REFERÊNCIAS ATLASSIAN Trello 2025 Disponível em httpstrellocom Acesso em 23 out 2025 BRASIL Lei nº 13709 de 14 de agosto de 2018 Lei Geral de Proteção de Dados Pessoais LGPD Diário Oficial da União Brasília DF 15 ago 2018 Disponível em httpswwwplanaltogovbrccivil03ato201520182018leiL13709htm Acesso em 23 out 2025 HUMBLE Jez FARLEY David Continuous Delivery Reliable Software Releases through Build Test and Deployment Automation Boston AddisonWesley 2010 PRESSMAN Roger S MAXIM Bruce R Engenharia de Software uma abordagem profissional 9 ed Porto Alegre AMGH 2016 SCHWABER Ken SUTHERLAND Jeff The Scrum Guide The Definitive Guide to Scrum 2020 atualizado Disponível em httpsscrumguidesorg Acesso em 23 out 2025 1 Establish a clear objective for the lesson Define what you want your students to learn and be able to do by the end of the lesson 2 Begin with a motivational introduction to capture students interest and curiosity Use a relevant story question or activity 3 Present new information clearly and concisely Use visuals examples and demonstrations to enhance understanding 4 Engage students in guided practice activities where they can apply what they have learned with your support 5 Provide opportunities for independent practice to reinforce the lessons objectives 6 Summarize the key points of the lesson to consolidate learning 7 Assess student understanding through quizzes discussions or practical activities 8 Provide constructive feedback to help students improve 9 Reflect on the lessons effectiveness and plan adjustments for future lessons based on student responses and outcomes 10 Incorporate a closing activity that reinforces the lessons objectives and leaves students with a positive impression