1 - Visão Geral

O Agile Short Unified Process - ASUP-LabESOF é um framework hibrido para desenvolvimento de software com base no modelo Scrum e algumas caractarísticas do método Unified Process. O Processo foi adaptado do modelo original do ASUP para atender as características inerentes ao contexto de uma fabrica de software vivenciada em sala de aula.

Portanto, o Processo será adotado para conduzir todos os projetos definidos na disciplina de Laboratório de Engenharia de Software, pois auxiliará aos alunos e ao professor na organização das atividades a serem desenvolvidas.

Figura 1 - Ciclo de Vida do Processo ASUP-LabESOF

2- Composição do Time

Os alunos deverão ser reunir para definir o time que irá conduzir o projeto. Não será aceito aluno mudando de time no decorrer do projeto. Portanto esta definição deverá ser feita com cautela e de forma definitiva.

O time deverá conter até 03 (três) alunos e um 01 (um) professor com os seguintes papeis:

• 01 - Tech Lead

• 02 - Devs

• 01 - Project Management - PM (Professor)

Na apresentação do escopo do projeto todos deverão participar, sem a definição do tech lead, pois esta apresentação não representa uma entrega do projeto.

Serão 07 (sete) entregas parciais e uma final, portanto o time deverá eleger um tech lead para cada entrega parcial, sendo realizado um entre as entregas.

Para entrega final, o time deverá eleger o tech lead destaque, que irá realizar a apresentação final e também receberá um bônus na nota. Caso o time não entre em acordo em elege o tech lead destaque, ficará a cargo do PM realizar a tarefa.

3 - Software de Gerenciamento de Projetos - JIRA

O software de gerenciamento de projetos a ser utilizado será o JIRA, pois permitirá gerenciar todas as atividades desenvolvidas no projeto. O time deverá criar uma conta no JIRA com a identificação do projeto para permitir inserir todas as informações do projeto. O JIRA deverá estar integrado com o GITHUB e com o Confluence obrigatoriamente.

Toda documentação do projeto deverá estar na Seção "Página do Projeto" devidamente integrado ao Confluence.

• Documentação do Projeto
  • Na seção Página do Projeto dentro do JIRA os seguintes documentos deverão ser disponibilizados:
    • Ideação - Apresentação;
    • Plano de Projeto - PP (com todas as seções preenchidas);
    • Product Backlog;

• 0N - Sprint - Descrição sintética
  • As Sprints deverão ser criadas utilizando os épicos levantados no Product Backlog.
  • Cada Sprint deverá receber as tasks correspondentes as atividades desenvolvidas na referida sprint e será de responsabilidade do tech lead inserir as tasks e atribuir aos membros que deverão trabalhar nelas.
  • As Sprints poderão ser inseridas conforme seu progresso, ou seja, apenas quando for iniciar novas tarefas que correspondem a sprint em questão.
  • As tarefas que correspondem a atividades de ambientação e configurações, deverão ser inseridas na sprint ativa que o grupo julgar pertinente.
    • Exemplo: Criar o repositório no GitHub; criar o sprint para o banco, ou seja, tarefas que correspondem ao atendimento de todos as demais tarefas.
    • Podem ser inseridas a qualquer momento, e também deverá ser inseridas pelo tech lead da Sprint ativa.

4 - Ideação

Dentro da abordagem do Design Thinking, a ideação é a etapa dedicada à formação de novas ideias. Ou seja: após mergulhar em um problema específico, o desafio é efetivamente começar a “pensar fora da caixa” e propor formas de solucioná-lo.

Portanto, após definição do time que irá trabalhar no projeto, porém ainda sem a definição do tech lead, todos os membros do time deverão participar das discussões para entender o problema a ser resolvido.

O time deverá apresentar o escopo do projeto sem entrar nos detalhes de desenvolvimento, apenas a ideia, contextualizando o problema e a solução a ser trabalhada. Para apresentação o time poderá utilizar recursos visuais tais como uma apresentação em power point ou qualquer outro recurso que possa facilitar a transmitir a ideia a ser projetada.

5 - Plano de Projeto - PP

O Plano de Plano - PP será o documento que irá direcionar todo o desenvolvimento do Projeto, nele deverá constar todos os elementos que envolvem o desenvolvimento pleno das atividades do projeto.

Este artefato será considerado a Entrega 1, e contará com um valor de nota a ser apresentado na seção de Distribuição de Notas - DN no final deste documento.

Para compor o PP, os itens abaixo serão considerados obrigatórios. Porém, o time poderá acrescentar algo que não conste no modelo apresentado, caso desejem enriquecer mais ainda o trabalho.

Como este documento será o artefato norteador do projeto, todos os membros do time deverão estar engajados neste, para entender todos os passos que serão desenvolvidos no projeto.

Abaixo os itens que deverão compor o PP:

5.1 - Introdução

💡

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

5.2 - Visão Geral do Sistema

a. Objetivo Geral

💡

Deve resumir e apresentar a ideia central do trabalho, descrevendo também a sua finalidade.

b. Objetivos Específicos

💡

Apresentar em forma de itens os resultados que se pretende alcançar alinhados ao objetivo geral.

c. Resumo da solução

💡

Nesta seção, apresentar um resumão da solução a ser adotada, se é web ou mobile, como será gerenciada e organizada.

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

💡

Para esta seção, o time deverá compor um grupo de histórias de usuários no formato Scrum, ou itens em forma de Requisitos Funcionais e Não Funcionais. O time poderá definir o formato a ser seguido para compor o documento.

5.4 - Diagrama de Casos de Uso

💡

Este artefato será obrigatório e deverá ser elaborado com bastante cuidado, pois é por meio deste que será representado a ideia em forma de funções que serão trabalhadas.

💡

Para facilitar a apresentação do Diagrama de Casos de Uso, o time poderá separar em várias cenas para um melhor entendimento e organização das funções.

5.5 - Diagrama de atividade ou BPMn

💡

Para esta seção, a depender do tipo de projeto a ser desenvolvido, este artefato poderá ser eliminado, caso o PM julgue que não seja necessário.

5.6 - Identidade Visual

a. Design inicial

💡

Para esta seção, será considero os elementos de design a ser utilizado no site público e telas internas, tais como cores, padrões de botões, tipografia, etc.

b. Logotipo com slogan

💡

Considerar um nome para identidade do projeto, bem como um logotipo com ou sem slogan

5.7 - Arquitetura e Tecnologia a serem utilizadas

💡

Desenhar a arquitetura para representar como será organizado e dividido o sistema, como por exemplo. Monolítico, 2 camadas, 3 camadas, N camadas, etc.

💡

Ao representar a arquitetura, informar quais serão as tecnologias a serem utilizadas em cada camada.

5.8 - Ambiente e Configurações a serem definidas

💡

Esta seção deverá ser representado todos os passos para configurar um ambiente de desenvolvimento conforme arquitetura definida.

💡

Além disso deverá apresentar a proposta de deploy a ser utilizada como todos os passos para ser realizado.

6 - Product Backlog - PB

Este artefato deverá ser entregue junto com o PP, sendo considerado um valor para nota também. Com o Projeto de Pesquisa - PP em mãos e com todos os artefatos desenvolvidos nele, o time deverá orientar e refinar o Product Backlog - PB, representando um cenário com as possíveis Sprints a serem trabalhadas, já com as divisões em épicos ou funcionalidades.

Para este artefato o time deverá apresentar em forma de planilha, pois será apenas um cronograma com o planejamento inicial e estará em seu estágio inicial, ou seja, apenas uma proposta.

7 - Ciclo das Sprints - Eventos

7.1 - A Sprint Ativa

A Sprint Ativa é considerada a sprint que corresponde ao planejamento de entrega conforme cronograma que será apresentado abaixo. Como o evento de Planning e Review acontecem juntos, para o evento Planning a Sprint Ativa será a sprint que se iniciará, e para o Review a Sprint Ativa é considera o encerramento do ciclo da sprint.

7.2 - Planning

O Planning é um evento que ocorre por meio de uma reunião junto ao PM, definindo as tasks que correspondem ao atendimento da Sprint Ativa que se inicia. O time esclarece junto ao PM quem será o tech lead da Sprint Ativa e define as tasks que cada membro irá trabalhar durante o time-box de 02 (duas) semanas. O tech lead deverá renomear a Sprint ativa para uma descrição sintética e que correponde a entrega e criará as tarefas definindo quem serão os responsáveis pelas atividades. Não poderão tem membros sem tasks dentro de uma Sprint Ativa. Caso isso aconteça o tech lead em comum acordo com o time poderá criar tasks em outra sprint ou criar atividades de ambientações e configurçaões.

Poderão ter tasks da sprint anterior que irão compor a sprint ativa, conforme definido na Review da Sprint entregue.

7.3 - Distribuição das tasks

Como já mencionado o tech lead da sprint ativas será o responsável por criar as tasks dentro do ambiente Redmine. A distribuição das taks é de reponsabiliade do tech lead, porém é de suma importância a participação de todos e a concordância de todos os membros do time.

Poderão ter tasks atribuidas a um membro do time, porém, outro membro poderá trabalhar na mesma tarefa também.

Será facultativo a definição de tempo estimado para as tasks, porém o registro de horas trabalhadas pelo membro do time em cada task será obrigatório, pois irá representar quanto cada membro debruçou para vencer a task, além de representar o relatório no final do projeto.

O Autor da tarefa a ser criada deverá ser sempre o tech lead, para representar no relatório de sprint definido no redmine.

7.4 - Review

O evento de Review acontece por meio de uma reunião antes na reunião de Planning, pois o Review representa a Entrega da Sprint ativa que se encerra. A entrega deverá ser conduzida pelo tech lead da Sprint Ativa e será computado um valor de nota para ela.

Na entrega o tech lead deverá reportar se todas as tasks definidas na Planning foi realmente realizadas. Caso alguma task não tenha sido vencida, esta poderá compo a próxima Sprint que será a sprint ativa e deverá ser considera na reunião de planning.

8 - Resumo do Cronograma das Entregas - Time Box

Figura 2 - Cronograma das entregas 1-2025

• Definição dos times e dos escopos dos projetos - 29/07 a 11/08
  • Apresentação para todos, dia 11/08/2025

  💡

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

• Entrega 1 (Sprint 0) - Plano de Projeto 29/07 a 18/08 - Planning da Sprint 01
  • Neste momento o JIRA já deve estar devidamente alimentado, bem como a integração com o Confluence. 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 7 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), 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.

  💡

  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.💡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 - 18/08 a 01/09
    • 01/09/2025 - Review Sprint 01 e Planning Sprint 02
  • Entrega 3 - Sprint 02 - 01/09 a 15/09
    • 15/09/2025 - Review Sprint 02 e Planning Sprint 03
  • Entrega 4 - Sprint 03 - 15/09 a 29/09
    • 29/09/2025 - Review Sprint 03 e Planning Sprint 04
  • Entrega 5 - Sprint 04 - 29/09 a 13/10
    • 13/10/2025 - Review Sprint 04 e Planning Sprint 05
  • Entrega 6 - Sprint 05 - 13/10 a 10/11
    • 10/11/2025 - Review Sprint 05 e Planning Sprint 06
  • Entrega 7 - Sprint 06 - 10/11 a 24/11
    • 24/11/2025 - Review Sprint 06 e Planning Sprint 07
  • Entrega 8 - Sprint 07 - 24/11 a 15/12
    • 15/12/2025 - Review Sprint 07 (Trabalho Final)

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

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

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