
Medodologia de Desenvolvimento - LabESOF
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 08 (oito) entregas parciais e uma final, portanto o time deverá eleger um tech lead para cada entrega parcial, sendo que o rodízio deverá obedecer ao ciclo de 3 (três) em 3 (três) entregas. Ou seja, se elegem o aluno 1 para entrega 1, este deverá estar na entrega 4 novamente, assim repete até a entrega 9.
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 criar o projeto e inserir todas as informações do projeto. O JIRA deverá estar integrado com o GITHUB e com o Confluence.
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;
- Na seção Página do Projeto dentro do JIRA os seguintes documentos deverão ser disponibilizados:
- 0N - Sprint - Descrição sintética
- As Sprints deverão ser criadas utilizando os épicos levantados.
- 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
5.2 - Visão Geral do Sistema
a. Objetivo Geral
b. Objetivos Específicos
c. Resumo da solução
5.3 - Product Backlog - Histórias de usuários - Nível de negócio
5.4 - Diagrama de Casos de Uso
5.5 - Diagrama de atividade ou BPMn
5.6 - Identidade Visual
a. Design inicial
b. Logotipo com slogan
5.7 - Arquitetura e Tecnologia a serem utilizadas
5.8 - Ambiente e Configurações a serem definidas
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 - 10/02 a 17/02
- Apresentação para todos, dia 18/02/2024
💡O artefato deverá ser apenas uma apresentação PowerPoint descrevendo o escopo do sistema proposto.
- Entrega 1 - Plano de Projeto - PP - 18/02 a 10/03
- 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 em formato PDF e deverá estar devidamente registrado no ambiente de GP. 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 14 dias (02 semanas), sendo utilizado as aulas do dia conforme cronograma a ser apresentado.💡Review - No décimo quarto 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 - 11/03 a 25/03
- 25/03/2025 - Review Sprint 01 e Planning Sprint 02
- Entrega 3 - Sprint 02 - 25/03 a 08/04
- 08/04/2025 - Review Sprint 02 e Planning Sprint 03
- Entrega 4 - Sprint 03 - 08/04 a 23/04
- 23/04/2025 - Review Sprint 03 e Planning Sprint 04
- Entrega 5 - Sprint 04 - 23/04 a 06/05
- 06/05/2025 - Review Sprint 04 e Planning Sprint 05
- Entrega 6 - Sprint 05 - 06/05 a 20/05
- 06/05/2025 - Review Sprint 05 e Planning Sprint 06
- Entrega 7 - Sprint 06 - 20/05 a 10/06
- 10/06/2025 - Review Sprint 06 e Planning Sprint 07
- Entrega 8 - Sprint 07 - 10/06 a 24/06
- 24/06/2025 - Review Sprint 07 e Planning Sprint 08
- Entrega Final - Trabalhar nos Ajustes Finais - 25/06 a 08/07
- Entrega 2 - Sprint 01 - 11/03 a 25/03
9 - Distribuição de Notas - TDN
As notas serão distribuidas 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
Descrição | Valor | Data |
---|---|---|
Entrega 1 | 10 Pontos | 18-25/02/2025 |
Entrega 2 | 5 Pontos | 25/03/2025 |
Entrega 3 | 5 Pontos | 08/04/2025 |
Entrega 4 | 5 Pontos | 23/05/2025 |
Entrega 5 | 5 Pontos | 06/05/2025 |
Entrega 6 | 5 Pontos | 20/05/2025 |
Entrega 7 | 5 Pontos | 10/06/2025 |
Entrega 8 | 5 Pontos | 24/06/2025 |
Apresentação Final | 15 Pontos | 08/07/2025 |
Total de Pontos | 60 Pontos |
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 validadas para gamefication
Item | Descrição | Valor | Data |
---|---|---|---|
1 | Sistema em funcionamento em conformidade com os itens apresentados nos artefatos do projeto | 10 Pontos | 08/07/2025 |
2 | Sistema devidamente implantado no domínio acordado junto ao PM | 10 Pontos | 08/07/2025 |
3 | Tech Lead destaque | 10 Pontos | 08/07/2025 |
4 | Bonus de Presença | 10 Pontos | 08/07/2025 |
Total de Pontos | 40 Pontos |
Observações: Para o item 1 será avaliado se o projeto foi entregue dentro do que foi planejado e modelado. Para o item 2, o time deverá propor soluções de deploy para colocar o sistema on-line e disponível de forma pública. No item 3 o time deverá eleger o tech lead destaque para receber o bonus, ou caso não entrem em acordo o PM fará a escolha. 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.