1ª Entrega

Está disponível o enunciado da primeira entrega de ES/SD. Recomenda-se a leitura das regras de utilização do CVS disponíveis aqui.

Sendo o FeaRS uma aplicação web, é necessário um servidor aplicacional onde o executar. Está disponível aqui uma versão pré-configurada do Tomcat que deve ser utilizada para realizar o projecto.

Artefactos relevantes:

Podem consultar-se as perguntas mais frequentes sobre esta entrega aqui. actualizado a 29/Março

Uma vez os ficheiros acima descompactados para os sítios correctos, e o servidor aplicacional correctamente instalado devem começar por eliminar o Apache Tomcat 6.0 do Build Path do projecto. Posteriormente devem executar os seguintes passos para que o projecto esteja pronto a ser utilizado no Eclipse:

  1. menu Project, opção Properties
  2. item Java Build Path
  3. separador Libraries
  4. botão Add Library...
  5. seleccionar User Library
  6. botão User Libraries...
  7. botão Import...
  8. seleccionar o ficheiro %STEP_HOME%\eclipse\stepdeps.userlibraries

Para evitar a intervenção do Eclipse no processo de construção (devido à instrumentação de classes Java que é necessária), o ficheiro de construção está a executar todo o processo de construção no directório build. Para que o resultado final fique disponível ao Eclipse (as configurações do projecto FeaRS fornecido definem o directório war\WEB-INF\classes) devem invocar o alvo eclipse-compile, que copia o resultado do processo de construção para o directório que está configurado no projecto como alvo da compilação.

Estão neste momento aptos a executar o projecto em modo desenvolvimento de forma integrada com o Eclipse, podendo inclusive executá-lo em modo depuração.

Notas sobre Gestão de Projecto

A gestão de projecto deve seguir a metodologia SCRUM.

O desenvolvimento de features usando a framework inclui tipicamente tarefas de:

- Descrição de caso de uso (CU)
- Modelação do Domínio (MD)
- Implementação do Domínio (ID)
- Desenho de Interface Utilizador (DI)
- Implementação de Interface Utilizador (II)
- Implementação de Serviço (IS)
- Teste de Aceitação (TA)

Todas as tarefas de descrição de caso de uso devem ter como resultado um documento PDF com a seguinte estrutura:

  • Nome
  • Objectivo
  • Actores
  • Pré-condição
  • Cenários de Sucesso
  • Cenários de Insucesso
  • Pós-Condição

As tarefas de modelação de domínio devem ter como resultado um documento PDF ou uma imagem JPG com um diagrama de classes UML que descreva as classes do domínio do problema. Estas classes e as suas operações devem ser inferidas a partir dos casos de uso. Caso se justifique o ciclo de vida de alguns objectos deve ser representado através de um diagrama de transição de estados.

Adicionalmente devem ser definidas tarefas de teste de aceitação para as features. Estas tarefas têm como resultado a descrição dos casos de teste de aceitação a realizar para cada feature e para composições de features.

As tarefas de implementação de domínio, incluem testes de unidade. Devem ser testados todos os métodos com lógica relevante.

O esforço das tarefas implementação de interface utilizador incluem a execução manual dos testes de aceitação definidos.

Para distinguir facilmente os tipos de actividades a sigla deve ser usada no nome da tarefa. Por exemplo IIU - Reserva de Vôo corresponde à tarefa de implementar a interface utilizador da feature Reserva de Vôo.

Uma sprint retrospective deve responder a duas questões fundamentais:

  • O que correu bem no sprint?
  • O que pode ser melhorado no próximo sprint?

Alguns dos tópicos que poderá ser interessante abordar na análise póstuma de uma release são:

  • problemas na aprendizagem/aplicação da tecnologia
  • dificuldades/problemas no trabalho em grupo e/ou divisão de trabalho
  • dificuldades no teste e/ou debugging
  • expectativas da dificuldade/complexidade do trabalho vs "realidade"
  • dificuldade em perceber "o que fazer"
  • dificuldade em perceber "como fazer"
  • modo como foi gerido o tempo para trabalhar para o projecto

2ª Entrega

Artefactos relevantes:

Podem consultar-se as perguntas mais frequentes sobre esta entrega aqui actualizado a 28/Abril.

Semanalmente terá lugar, no horário da aula laboratorial em que cada grupo está inscrito, uma reunião de gestão, cuja duração não excederá 20min.  Nesta reunião deverá ser demonstrada a funcionalidade concluida no sprint anterior e será analisado o planeamento e execução até esse momento (através de uma versão em papel e actualizada da folha de gestão).

Deliverables a entregar via Fénix (por data ):

  • 16 de Abril: folha de gestão com o planeamento para o 1º sprint.
  • 22 de Abril: sprint retrospective do 1º sprint; folha de gestão actualizada com a execução do 1º sprint e com o planeamento para o 2º sprint;
  • 29 de Abril: sprint retrospective do 2º sprint; folha de gestão actualizada com a execução do 2º sprint e com o planeamento para o 3º sprint;
  • 5 de Maio, às 20:00: etiqueta RELEASE_2 no módulo fearse.
  • 6 de Maio: Análise póstuma da 2ª entrega; folha de gestão actualizada com a execução do 3º sprint.

3ª Entrega

Artefactos relevantes:

Podem consultar-se as perguntas mais frequentes sobre esta entrega aqui.

Semanalmente terá lugar, no horário da aula laboratorial em que cada grupo está inscrito, uma reunião de gestão, cuja duração não excederá 20min.  Nesta reunião será analisado o planeamento e execução até esse momento (através de uma versão em papel e actualizada da folha de gestão). Na reunião após o final do 1º sprint deverá ser demonstrada a funcionalidade concluida no sprint anterior.

Deliverables a entregar via Fénix (por data ):

  • 7 de Maio: folha de gestão com o planeamento para o 1º sprint.
  • 20 de Maio: sprint retrospective do 1º sprint; folha de gestão actualizada com a execução do 1º sprint e com o planeamento para o 2º sprint;
  • 2 de Junho às 20:00: etiqueta RELEASE_3 no módulo fearse.
  • 3 de Junho: Análise póstuma da 3ª entrega; folha de gestão actualizada com a execução do 2º sprint.

Nota: O resultado de qualquer tarefa é um artefacto, seja ele código do projecto, protótipos funcionais, diagramas, documentos de requisitos ou outros. Todos os artefactos produzidos deverão ser colocado no CVS. Artefactos não-código devem ser colocados no directório /docs.