labesof

Medodologia de Desenvolvimento - LabESOF

1 - Visão Geral

O Agile Short Unified Process – ASUP-LabESOF é um framework híbrido para desenvolvimento de software, baseado no Scrum e em características do Unified Process, adaptado ao contexto de fábrica de software vivenciada em sala de aula.

O processo foi estruturado para equilibrar aprendizado técnico, organização metodológica e entrega incremental de valor, preparando o aluno tanto para ambientes acadêmicos quanto profissionais.

Portanto, o ASUP-LabESOF será adotado para conduzir todos os projetos da disciplina de Laboratório de Engenharia de Software, auxiliando alunos e professor na organização, acompanhamento e avaliação das atividades desenvolvidas.

Figura 1 - Ciclo de Vida do Processo ASUP-LabESOF

2- Composição do Time

Os alunos deverão se reunir para definir o time que conduzirá o projeto. Não será permitido trocar de time após esta definição, devendo a escolha ser feita de forma consciente e definitiva.

O time deverá conter até 3 (três) alunos, com os seguintes papéis:

• 01 – Tech Lead

• 02 – Desenvolvedores (Devs)

• 01 – Project Manager (PM – Professor)

Papel dos Alunos (DEV e Tech Lead):

• Os alunos representarão os papéis de Desenvolvedor (DEV) e Tech Lead, assumindo de forma ativa a responsabilidade técnica pelas decisões de projeto e implementação;

• Caberá aos alunos desbravar as soluções técnicas, investigar tecnologias, bibliotecas, frameworks e arquiteturas necessárias para atender aos requisitos do projeto;

• O processo de desenvolvimento deverá estimular autonomia, pensamento crítico e resolução de problemas, características essenciais da atuação profissional em Engenharia de Software;

• É permitido e incentivado o uso de ferramentas de Inteligência Artificial (IA) como apoio à solução de problemas, pesquisa técnica, esclarecimento de dúvidas e prototipação de soluções;

• O uso de IA não exime o aluno da compreensão do que está sendo desenvolvido, sendo de responsabilidade do time validar, adaptar e justificar tecnicamente as soluções adotadas.

Papel do Professor (PM):

• Validar tecnicamente e metodologicamente as entregas;

• Mediar conflitos e apoiar a organização do time;

• Avaliar não apenas o produto final, mas o processo de desenvolvimento adotado;

• Garantir aderência ao ASUP-LabESOF.

Na apresentação inicial do escopo, todos os membros deverão participar, ainda sem definição de Tech Lead, pois esta apresentação não caracteriza entrega do projeto.

Serão realizadas entregas parciais ao longo do semestre, sendo eleito um Tech Lead diferente a cada sprint, promovendo rodízio de liderança técnica.

Para a entrega final, o time deverá eleger o Tech Lead destaque, responsável pela apresentação final e elegível a bônus de nota. Caso não haja consenso, a decisão caberá ao PM.

3 – Comprometimento, Presença e Responsabilidade Individual

Esta subseção estabelece diretrizes formais para garantir o comprometimento contínuo dos integrantes, a participação ativa nas atividades presenciais e a responsabilidade individual dentro do trabalho em grupo, princípios essenciais para o bom funcionamento do ASUP-LabESOF.

3.1 – Presença e Participação

A presença dos alunos nas aulas correspondentes às atividades do projeto é considerada parte integrante do processo avaliativo.

• As reuniões de Review e Planning são consideradas momentos avaliativos;

• A validação da Sprint estará condicionada à presença dos membros do time ou à apresentação de justificativa formal previamente registrada;

• Ausências não justificadas impactarão a avaliação individual, conforme critérios definidos na Seção de Distribuição de Notas.

3.2 – Responsabilidade Individual por Sprint

Cada integrante do time deverá possuir, em todas as sprints:

• Pelo menos uma task atribuída e registrada no JIRA;

• Evidência objetiva de contribuição (código versionado, documentação, diagrama, configuração ou outro artefato relevante);

• Registro de horas trabalhadas na respectiva task.

A ausência de evidência individual de contribuição em uma Sprint poderá resultar em redução da nota individual, independentemente da nota atribuída ao grupo.

3.3 – Comprometimento e Conduta Profissional

Espera-se dos alunos uma postura compatível com ambientes profissionais de desenvolvimento de software, incluindo:

• Cumprimento de prazos;

• Comunicação com o time;

• Participação ativa nas decisões técnicas;

• Respeito aos ritos do processo.

3.4 – Situações de Ausência Recorrente

Em casos de ausência recorrente, baixo comprometimento ou descumprimento reiterado das responsabilidades assumidas, o PM poderá:

• Aplicar redução de nota individual;

• Redistribuir atividades dentro do time;

• Avaliar o aluno de forma individual, desvinculando sua nota do desempenho coletivo do grupo, quando necessário.

4 - Software de Gerenciamento de Projetos - JIRA

O software oficial de gerenciamento de projetos será o JIRA.

O time deverá:

• Criar um projeto no JIRA;

• Integrar obrigatoriamente o JIRA ao GitHub e ao Confluence;

• Centralizar toda a documentação na seção “Página do Projeto”.

Todas as atividades, tarefas, sprints, registros de horas e evidências de entrega deverão ser realizadas exclusivamente no JIRA, garantindo rastreabilidade completa do projeto.

Documentação do Projeto

Na seção Página do Projeto (Confluence) deverão constar, no mínimo:

• Ideação – Apresentação;

• Plano de Projeto (PP);

• Product Backlog;

• Descrição sintética de cada Sprint.

4.1 – Estratégia de Branches (GitFlow)

O time deverá adotar o GitFlow como estratégia de versionamento no GitHub, seguindo a estrutura abaixo:

• main – branch de produção. Recebe merges apenas da branch develop ao final de cada sprint, após aprovação do Tech Lead;

• develop – branch de integração contínua. Todo o desenvolvimento é integrado aqui antes de ir para main;

• feature/nome-da-feature – criada a partir de develop para desenvolvimento de cada funcionalidade. Ao concluir, deve ser aberto um Pull Request de volta para develop;

• fix/nome-do-fix – criada a partir de develop para correções pontuais durante a sprint.

Regras obrigatórias:

• Nenhum desenvolvedor poderá realizar push diretamente nas branches main ou develop;

• Todo código novo deverá passar por Pull Request e ser aprovado pelo Tech Lead da Sprint antes do merge;

• O nome das branches deverá seguir o padrão: feature/JIRA-ID-descricao (ex: feature/LAB-42-tela-login).

💡 O Tech Lead é o único responsável por aprovar e realizar o merge dos Pull Requests durante sua sprint.

5 - Ideação

A Ideação, dentro da abordagem de Design Thinking, é a etapa dedicada à compreensão do problema e geração de soluções.

Após a definição do time, todos os membros deverão participar ativamente das discussões, buscando compreender o problema a ser resolvido e propor uma solução viável.

O time deverá apresentar:

• O contexto do problema;

• A ideia central da solução;

• Os benefícios esperados.

A apresentação não deve entrar em detalhes técnicos, podendo utilizar PowerPoint, Canva ou outros recursos visuais.

6 - Plano de Projeto - PP

O Plano de Projeto (PP) é o artefato norteador de todo o desenvolvimento do projeto e corresponde à Entrega 1.

Todos os membros do time deverão estar engajados em sua elaboração, garantindo entendimento comum sobre escopo, objetivos e estratégia de desenvolvimento.

6.1 - Introdução

Apresentar uma introdução relatando o que o documento irá apresentar.

6.2 - Visão Geral do Sistema

a) Objetivo Geral – Apresentar a finalidade central do projeto.

b) Objetivos Específicos – Listar os resultados esperados, alinhados ao objetivo geral.

c) Resumo da Solução – Descrever, de forma resumida, a solução proposta (web, mobile, arquitetura geral).

6.3 - Product Backlog - Histórias de usuários - Nível de negócio

O time deverá definir Histórias de Usuário no padrão Scrum ou Requisitos Funcionais e Não Funcionais, mantendo consistência no formato adotado.

6.4 - Diagrama de Casos de Uso

Artefato obrigatório, representando as funcionalidades do sistema.

O diagrama poderá ser dividido em múltiplas visões, visando melhor clareza e organização.

6.5 - Diagrama de Entidade Relacionamento (DER)

Artefato obrigatório para projetos que utilizam banco de dados relacional, representando as entidades do sistema, seus atributos e os relacionamentos entre elas.

O DER deverá refletir o modelo de dados real do sistema, sendo atualizado sempre que houver mudanças significativas na estrutura do banco ao longo das sprints.

💡 Para projetos que não utilizam banco relacional (ex.: bancos NoSQL), este artefato poderá ser substituído por um diagrama equivalente de modelagem de dados, a critério do PM.

6.6 - Diagrama de atividade ou BPMn

Este artefato será opcional, podendo ser dispensado a critério do PM, conforme a natureza do projeto.

6.7 – Identidade Visual

• Design inicial (cores, tipografia, padrões visuais);

• Logotipo e nome do projeto, com ou sem slogan

6.8 – Prototipação

O time deverá elaborar um protótipo navegável da interface do sistema, simulando os principais fluxos de interação do usuário antes do início do desenvolvimento.

A prototipação é uma prática consolidada na indústria e tem como objetivo validar a experiência do usuário, alinhar expectativas entre o time e o PM e reduzir retrabalho durante as sprints.

Ferramentas recomendadas: Figma ou Lovable (ou equivalente aprovado pelo PM).

O protótipo deverá contemplar, no mínimo:

• As telas principais do sistema (fluxo de login, dashboard, funcionalidades centrais);

• Navegação entre telas, demonstrando o fluxo do usuário;

• Aplicação da identidade visual definida na seção anterior (cores, tipografia, logotipo).

Entrega: o protótipo deverá ser entregue juntamente com o Plano de Projeto (Entrega 1) e o link de acesso registrado no Confluence. O protótipo poderá ser refinado ao longo das sprints conforme o sistema evolui.

💡 Um bom protótipo não precisa ser perfeito — precisa ser suficiente para guiar o desenvolvimento e ser apresentado ao PM no Review da Sprint 0.

6.9 - Arquitetura e Tecnologia

Descrever e representar a arquitetura do sistema (monolítica, camadas, microserviços etc.), indicando as tecnologias utilizadas em cada camada.

6.10 - Ambiente, Configurações, CI/CD e Deploy

O time deverá descrever e configurar, ao longo do projeto, a infraestrutura de desenvolvimento e entrega do sistema.

a) Ambiente de Desenvolvimento

Descrever as ferramentas, versões de linguagem/framework e passos necessários para configurar o ambiente localmente.

b) Pipeline de CI/CD

O time deverá configurar obrigatoriamente um pipeline de Integração e Entrega Contínua utilizando GitHub Actions (ou ferramenta equivalente aprovada pelo PM). O pipeline deverá contemplar, no mínimo:

• Execução automática dos testes a cada Pull Request aberto para develop;

• Build da aplicação validando ausência de erros de compilação;

• Deploy automático para o ambiente de produção a partir de merge na branch main.

💡 O pipeline é parte obrigatória da entrega final. A ausência de CI/CD configurado impactará a avaliação do item de deploy.

c) Estratégia de Deploy

O time deverá propor e implementar uma solução de deploy que torne o sistema disponível publicamente, conforme acordado com o PM. São esperados:

• A aplicação deverá ser containerizada obrigatoriamente com Docker, com Dockerfile e, quando aplicável, docker-compose.yml para orquestração dos serviços (aplicação, banco de dados, etc.);

• Ambiente de produção acessível via domínio público (registro.br ou equivalente), executando os containers do projeto;

• Documentação das rotas da API via Swagger, implantado no mesmo servidor;

• Procedimento documentado para atualização e rollback em caso de falha.

6.11 - Estratégia de Testes Automatizados

O time deverá definir, ainda no Plano de Projeto, a estratégia de testes que será adotada ao longo das sprints.

Escopo mínimo obrigatório:

• Testes unitários das principais regras de negócio do back-end (funções, serviços, validações);

• Os testes deverão ser executados automaticamente pelo pipeline de CI a cada Pull Request.

Boas práticas esperadas:

• Organizar os testes em diretório dedicado (/tests ou equivalente conforme convenção do framework);

• Nomear os testes de forma descritiva, indicando o comportamento esperado;

• Garantir que nenhum Pull Request seja mergeado com testes quebrados.

💡 A cobertura de testes não precisa ser exaustiva, mas deve contemplar os fluxos críticos do sistema. O PM poderá verificar a existência e execução dos testes durante o Review.

7 - Product Backlog - PB

O Product Backlog deverá ser entregue juntamente com o PP.

Ele deverá ser registrado no Confluence (na seção Página do Projeto) e lançado no JIRA com a estrutura de épicos, funcionalidades e a previsão de sprints devidamente criadas, contendo:

• Épicos;

• Funcionalidades;

• Proposta inicial de 8 sprints ao longo do semestre, já criadas no JIRA com seus respectivos itens de backlog.

O JIRA deverá estar operacional — com sprints criadas e backlog distribuído — antes do Planning da Sprint 01. O PB representa um planejamento inicial, sujeito a ajustes conforme evolução do projeto.

8 - Ciclo das Sprints - Eventos

Cada sprint terá duração de 15 dias (2 semanas).

8.1 – Sprint Ativa

A Sprint Ativa corresponde à sprint em execução, sendo considerada:

• Início no Planning;

• Encerramento no Review.

8.2 – Planning

Reunião conduzida com o PM, onde são definidas:

• Tasks da Sprint Ativa;

• Responsáveis;

• Tech Lead da Sprint.

Nenhum membro poderá ficar sem task atribuída durante uma Sprint Ativa.

8.3 – Distribuição das Tasks

A criação e atribuição das tasks será responsabilidade do Tech Lead da Sprint, utilizando exclusivamente o JIRA.

• Registro de horas é obrigatório;

• Uma task pode ter mais de um colaborador;

• Tasks técnicas transversais (configuração, CI/CD, testes, refatoração) podem ser incluídas em qualquer sprint.

8.4 – Daily Check

Durante a Sprint Ativa, o PM realizará verificações periódicas rápidas com o time para garantir foco e identificar impedimentos antes que se tornem problemas.

• O Daily Check não é uma reunião formal — pode ocorrer presencialmente no início da aula ou de forma assíncrona via comentário no JIRA;

• Cada membro deverá ser capaz de responder em poucas palavras: o que está fazendo e se há algum impedimento;

• Impedimentos identificados devem ser registrados imediatamente como observação na task correspondente no JIRA;

• O Tech Lead é o responsável por garantir que o time responda ao PM dentro do prazo estipulado.

8.5 – Code Review e Pull Request

Todo código desenvolvido durante a Sprint Ativa deverá passar por revisão antes de ser integrado à branch develop.

Fluxo obrigatório:

1. O desenvolvedor conclui a implementação em sua branch feature/ e abre um Pull Request para develop no GitHub;

2. O Tech Lead da Sprint é o responsável por revisar o código, aprovando ou solicitando ajustes;

3. Somente após aprovação do Tech Lead o merge poderá ser realizado — e é o próprio Tech Lead quem executa o merge;

4. O desenvolvedor nunca realiza o merge de seu próprio código.

O Tech Lead deverá verificar, no mínimo:

• Se o código está funcionando conforme o esperado;

• Se os testes automatizados estão passando;

• Se o código está legível e sem duplicações evidentes;

• Se a task correspondente está devidamente atualizada no JIRA.

💡 Pull Requests sem aprovação do Tech Lead não serão considerados como evidência de entrega na avaliação da Sprint.

8.6 – Definition of Done (DoD)

Uma task ou funcionalidade é considerada concluída somente quando atender a todos os critérios abaixo:

• Implementação finalizada na branch feature/ correspondente;

• Testes automatizados escritos e passando no pipeline de CI;

• Pull Request aprovado e mergeado pelo Tech Lead na branch develop;

• Task atualizada para Done no JIRA, com horas registradas;

• Funcionalidade demonstrável no ambiente de desenvolvimento.

Tarefas que não atenderem a esses critérios não serão contabilizadas como entregues no Review, devendo ser incorporadas à sprint seguinte.

8.7 – Review

Evento de entrega da Sprint Ativa, conduzido pelo Tech Lead, com participação obrigatória de todo o time.

• Cada membro deverá relatar sua contribuição na sprint;

• As funcionalidades entregues deverão ser demonstradas em funcionamento;

• Caso tasks não sejam concluídas, deverão ser registradas e incorporadas à sprint seguinte.

Presença obrigatória: o aluno que não estiver presente no Review perderá automaticamente os pontos integrais da sprint, independentemente de sua contribuição técnica. Ausências somente serão consideradas mediante justificativa formal previamente apresentada ao PM.

Ainda nesse mesmo dia, após o Review, o Tech Lead apresentará o que será realizado na próxima sprint (Planning da Sprint seguinte) e será definido o próximo Tech Lead.

8.8 – Retrospectiva

Ao final de cada Review, o time realizará uma Retrospectiva com o objetivo de inspecionar o processo e identificar oportunidades de melhoria para a próxima sprint.

O time deverá responder três perguntas:

• O que funcionou bem nesta sprint e deve ser mantido?

• O que não funcionou e deve ser melhorado?

• O que faremos diferente na próxima sprint?

As conclusões da Retrospectiva deverão ser registradas sinteticamente no Confluence (na descrição da sprint encerrada) e consideradas na condução da sprint seguinte.

💡 A Retrospectiva não é avaliativa, mas é parte do processo. O PM poderá verificar se o registro foi feito durante o Review da sprint subsequente.

9 - Resumo do Cronograma das Entregas - Time Box

O cronograma seguirá o calendário acadêmico, com entregas distribuídas entre julho e dezembro.

As aulas ocorrem às segundas-feiras (4 aulas) e terças-feiras (2 aulas). Os eventos de Review e Planning serão realizados preferencialmente às segundas-feiras. Quando o dia previsto coincidir com feriado, o evento será realizado na próxima aula disponível conforme indicado abaixo.

A Sprint 0 corresponde à documentação inicial e planejamento do projeto.

Figura 2 - Cronograma das entregas 2-2026

• Definição dos times e dos escopos dos projetos - 28/07 a 10/08

  • Apresentação do Pitch para todos: 10/08/2026 (seg)

  💡 O artefato deverá ser apenas uma apresentação PowerPoint/Canva descrevendo o escopo do sistema proposto, o problema resolvido e os benefícios esperados.

• Entrega 1 (Sprint 0) - Plano de Projeto 10/08 a 24/08 - Planning da Sprint 01

  • Neste momento o JIRA já deverá estar devidamente alimentado, com as sprints criadas e o backlog distribuído, bem como a integração com o Confluence e com o GitHub. Portanto, todos estes artefatos deverão compor a seção Página do Projeto.

  💡 Os artefatos deverão ser entregues devidamente registrados no ambiente Confluence. O Product Backlog deverá conter a previsão das 8 sprints já criadas no JIRA com seus respectivos itens de backlog.

• Duração das Sprints e os eventos de Review e Planning

  💡Duração - Cada sprint terá uma duração de 15 dias (02 semanas), exceto sprints que confrontarem com feriados, sendo utilizado as aulas do dia conforme cronograma apresentado.

  💡 Review - No décimo quinto dia da Sprint, deverá ser apresentado o que foi realizado durante as duas semanas, sendo que cada membro do time deverá relatar no que contribuiu para vencer a Sprint Ativa. O responsável pela entrega sempre será o Tech Lead, porém todos deverão participar. A ausência no Review implica perda automática dos pontos da sprint.

  💡 Planning - Ainda nesse mesmo dia, após todos relatarem suas contribuições da Sprint Ativa, o Tech Lead deverá apresentar o que será realizado na próxima sprint que será considerada a Sprint Ativa e será definido o próximo Tech Lead.

  💡 Retrospectiva - Logo após o Review, o time realizará uma retrospectiva cujas conclusões deverão ser registradas no Confluence.

  💡 Caso tenha ocorrido alguma intercorrência e a Sprint planejada não foi entregue, estas intercorrências deverão ser relatadas e registradas e estas deverão compor a próxima sprint.

• Cronograma das Sprints

  • Entrega 2 - Sprint 01 - 24/08 a 07/09 ⚠️ (feriado – sem aula)

    • 08/09/2026 (ter) - Review Sprint 01 e Planning Sprint 02

  • Entrega 3 - Sprint 02 - 08/09 a 21/09

    • 21/09/2026 (seg) - Review Sprint 02 e Planning Sprint 03

  • Entrega 4 - Sprint 03 - 21/09 a 05/10

    • 05/10/2026 (seg) - Review Sprint 03 e Planning Sprint 04

    💡 12/10 é feriado (seg); a aula será cumprida na terça 13/10 com horário de segunda.

  • Entrega 5 - Sprint 04 - 05/10 a 19/10

    • 19/10/2026 (seg) - Review Sprint 04 e Planning Sprint 05

  • Entrega 6 - Sprint 05 - 19/10 a 02/11 ⚠️ (feriado – sem aula)

    • 03/11/2026 (ter) - Review Sprint 05 e Planning Sprint 06

    💡 02/11 é feriado (seg); a aula será cumprida na quinta 05/11 com horário de segunda.

  • Entrega 7 - Sprint 06 - 03/11 a 16/11

    • 16/11/2026 (seg) - Review Sprint 06 e Planning Sprint 07

  • Entrega 8 - Sprint 07 - 16/11 a 30/11

    • 30/11/2026 (seg) - Review Sprint 07 e Planning Sprint 08 (final)

  • Entrega 9 - Sprint 08 - 30/11 a 14/12 (Ajustes Finais)

    • 14/12/2026 (seg) - Entrega Final do Produto

10 - Distribuição de Notas - TDN

As notas serão distribuídas em dois segmentos, sendo o primeiro para compor os valores a serem validados nas entregas conforme cronograma acima. Para o segundo segmento será adotado o esquema de gamefication conforme será demonstrado abaixo.

10.1 - Notas validadas nas Entregas

Observações: Será considerado o valor máximo caso o time realize a Review e Planning conforme acordado, e será avaliado a Sprint Ativa de Entrega. Caso o PM verifique que não houve comprometimento no processo de desenvolvimento da Sprint Ativa o PM poderá atribuir a nota que corresponde a nível de entrega e comprometimento do time.

10.2 - Notas finais de projeto

Observação 1: Para o item 1 será avaliado se o projeto foi entregue dentro do que foi planejado e modelado e será considerado os ajustes durante o desenvolvimento do projeto. Para o item 2 o time deverá providenciar a implantação do swagger e dos testes automatizados no servidor vinculado ao item 3. Para o item 3, o time deverá propor soluções de deploy para colocar o sistema on-line e disponível de forma pública, com pipeline de CI/CD ativo e documentado. Para o item 4, o aluno receberá o valor total caso tenha assiduidade plena, ou seja, sem nenhuma falta, caso o aluno tenha falta, será descontado 1 (um) ponto para cada falta nas aulas que correspondem a 4 (quatro) horários e 0,5 (meio) ponto para cada falta em aulas de 2 horários, até seu saldo esgotar. Quanto o aluno sair mais cedo e chegar mais tarde do acordado, será descontado 0,5 por infração. Além disso será considerado o comprometimento do aluno no projeto. Para o item 5 será considero a apresentação e o respeito em assistir as apresentações dos demais grupos.

Observação 2: No que corresponde ao Tech Lead destaque o time deverá eleger o um dos integrantes do grupo que obteve destaque, para receber o bonus, ou caso não entrem em acordo o PM fará a escolha