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.

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 atividade ou BPMn

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

6.6 – Identidade Visual

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

• Logotipo e nome do projeto, com ou sem slogan

6.7 - Arquitetura e Tecnologia

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

6.8 - Ambiente e Configurações

Descrever:

• Ambiente de desenvolvimento;

• Passos de configuração;

• Estratégia de deploy e publicação.

7 - Product Backlog - PB

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

Ele deverá ser apresentado em formato de planilha, contendo:

• Épicos;

• Funcionalidades;

• Proposta inicial de 8 sprints ao longo do semestre.

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, refatoração) podem ser incluídas em qualquer sprint.

8.4 – Review

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

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

9 - Resumo do Cronograma das Entregas - Time Box

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

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

Figura 2 - Cronograma das entregas 1-2026

• Definição dos times e dos escopos dos projetos - 09/02 a 23/02
  • Apresentação para todos, dia 23/02/2026

  💡 O artefato deverá ser apenas uma apresentação PowerPoint/Canva descrevendo o escopo do sistema proposto.

• Entrega 1 (Sprint 0) - Plano de Projeto 23/02 a 09/03 - Planning da Sprint 01
  • Neste momento o JIRA já deverá estar devidamente alimentado, 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. Para o Product Backlog deverá conter uma previsão de cronograma com 8 sprints que serão trabalhadas durante todo o semestre.

• 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 sprint 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.

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

  💡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 - 09/03 a 22/03
    • 23/03/2026 - Review Sprint 01 e Planning Sprint 02
  • Entrega 3 - Sprint 02 - 23/03 a 05/04
    • 06/04/2026 - Review Sprint 02 e Planning Sprint 03
  • Entrega 4 - Sprint 03 - 06/04 a 26/04
    • 27/04/2026 - Review Sprint 03 e Planning Sprint 04
  • Entrega 5 - Sprint 04 - 27/04 a 10/05
    • 11/05/2026 - Review Sprint 04 e Planning Sprint 05
  • Entrega 6 - Sprint 05 - 11/05 a 24/05
    • 25/05/2026- Review Sprint 05 e Planning Sprint 06
  • Entrega 7 - Sprint 06 - 25/05 a 07/06
    • 08/06/2026 - Review Sprint 06 e Planning Sprint 07
  • Entrega 8 - Sprint 07 - 08/06 a 21/06
    • 22/06/2026 - Review Sprint 07 e Planning Sprint 08 (final)
  • Entrega 9 - Sprint 08 - 22/06 a 06/07 (Ajustes Finais)
    • 06/07/2026 - 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 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. 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. 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