Engenharia de Software
2º Semestre de 2006/2007Segundo enunciado detalhado do projecto:
Portal OurDocs
1. Introdução
Neste segundo enunciado do projecto do Portal OurDocs pretende-se que seja elaborado um plano de desenvolvimento do projecto, bem como a execução desse mesmo plano. O plano deve detalhar os requisitos funcionais descritos no enunciado. A execução do plano deve resultar numa actualização ao código e configurações do Portal OurDocs que satisfaça os novos requisitos.
Os requisitos deverão ser descritos usando a nomenclatura do Extreme Programming e o plano de projecto deverá ser gerido através da ferramenta ExtremePlanner, disponível online no endereço https://es.extremeplannerlive.com.
Para o efeito foi criado um projecto para cada grupo e é dentro desse projecto que deverá ser criado o plano de projecto com a descrição das Stories, Tasks e Test Cases que considerarem relevantes para a completa descrição dos novos requisitos e respectivas alterações ao nível do que foi definido e implementado aquando do primeiro enunciado do projecto.
Com o objectivo de ajudar na estruturação do plano de projecto foi criado um projecto tipo (ver projecto ES-2 no site https://es.extremeplannerlive.com) onde se apresenta um exemplo da descrição da Story: Criar Documento com uma descrição de duas Tasks. Tal como no exemplo apresentado, o projecto deverá ter apenas uma Release e uma Iteration, onde serão descritas todas as Stories. A secção 3 completa a descrição da estrutura a adoptar no plano de projecto.
2. Contexto
Estender a solução actual de forma a que um documento tenha 4 partes, Título, Resumo, Corpo, e Conclusões. Para cada uma destas partes é guardada a versão, à qual é associado um número de versão. O documento, num dado momento, é igual à junção da versão mais recente de cada uma das partes. Altera-se a forma como se identifica um documento, deixa de ser pelo título e passa a ser por um número único de documento.
O Título apenas pode ser alterado pelo criador nos estados DRAFT, e EDITABLE e pelo editor no estado SUBMITTED. O comportamento para as restantes partes é igual ao definido anteriormente.
No âmbito deste segundo projecto inclui-se a descrição e implementação das alterações que são necessárias ao nível das camadas arquitecturais do actual projecto OurDocs de forma a viabilizar a criação de um documento constituído pela agregação de 4 partes distintas e com uma gestão de versões autónoma.
3. Desenvolvimento
Com o objectivo de uniformização da estrutura do plano de projecto apresentamos em seguida os componente obrigatórios para cada um dos elementos do plano:
Release – este segundo projecto deverá ser descrito usando apenas uma Release;
Iteration – todas as Stories descritas são agrupadas numa única Iteration;
Story – a descrição de uma Story deverá incluir os seguintes tópicos
Descrição – breve resumo do requisito na óptica do cliente Actores – intervenientes
Pré-condições – conjunto de condições que se devem satisfazer para que a
execução da Story leve à verificação das pós-condições;
Pós-condições – conjunto de condições que são satisfeitas quando se executam os
cenários primários;
Cenários Primários – descrevem as interacções entre o sistema e os actores
quando as pré-condições se verificam;
Cenários Secundários – descrevem as interacções entre o sistema e os actores
quando as pré-condições não se verificam (cada cenário secundário deve indicar quais as suas pós-condições);
Task – a descrição de uma Task deverá ser feita numa linguagem mais técnica. O nome
da Tasks deverá ter um prefixo definido por: Design (D) ou Implementation (I) dependendo da Task referenciar um tarefa de desenho ou de
implementação. Cada um destes dois itens deverá ser classificado em função da camada arquitectural usando a seguinte nomenclatura como sufixo: Data Layer (DL), Domain Model Layer (DML), Thin Layer (TL) e Presentation Layer (PL).
Nos casos em que uma Task inclui a definição de Testes deverá ser adicionado o prefixo (T). Os tipos de Tasks que devem existir são:
• Domain Model Design – Task ao nível do desenho do modelo de domínio e regras de negócio associadas à história. Prefixo D-DML;
• Domain Model Implementation and Testing – Task ao nível da implementação do modelo de domínio e respectivos testes de regressão (unidade). Prefixo I-DML+T;
• Presentation Design and Testing – Task ao nível do desenho da interface da camada de apresentação (esboços da interface e fluxo entre interfaces)
• Presentation Implementation – Task ao nível do implementação da camada de apresentação. Prefixo I-PL;
• Thin and Data Implementation and Testing – Task ao nível do implementação dos serviços da camada fina, persistência dos dados e testes de regressão (unidade). Prefixo I-TL+DL+T.
Associados a cada Story apenas pode haver Tasks destes tipos. Note-se que uma Story pode ter várias Tasks do mesmo tipo desde que seja possível haver trabalho em paralelo, por exemplo, a implementação de 2 JSPs de um caso de uso. Neste exemplo, deverá depois haver uma Task de integração dos JSPs.
O desenvolvimento desta fase do projecto Portal OurDocs deve partir do código base a disponibilizar na Segunda-feira na secção Projecto do site da cadeira (até lá deverão ser levantados os requisitos e definido o plano do projecto). Este código deverá ser alterado de modo a responder aos requisitos especificados na secção 2, todavia as alterações devem respeitar a arquitectura definida para o projecto e que foi apresentada nas aulas de laboratório.
4. Avaliação
A avaliação desta segunda fase do projecto é composta por duas partes: • Visualização do projecto e avaliação dos elementos do grupo; • Avaliação posterior do plano de projecto e do código desenvolvido.
A primeira parte é realizada nas aulas de laboratório na semana seguinte à entrega do projecto. Durante esta primeira avaliação considera-se requisito mínimo o seguinte:
O aluno deve ser capaz de, num PC do laboratório, obter o projecto a partir do repositório CVS, efectuar o deploy e apresentar a página inicial do portal num navegador web. Os alunos que não conseguirem
cumprir este requisito em 15 minutos têm 0 (zero) nesta entrega1.
_____________________________________________________
1
A utilização do Eclipse na avaliação é completamente facultativa, pelo que fica ao critério de cada aluno decidir sobre a sua utilização ou não.
A segunda parte da avaliação é realizada posteriormente pelo corpo docente e consiste na avaliação do projecto do ponto de vista da correcção da solução e do cumprimento das normas de utilização da arquitectura, bem como do plano de projecto definido e sua execução.
Período de realização do Projecto:
• Data de Inicio: 11-05-2007;
• Data de disponibilização do código base: 14-05-2007; • Data Entrega: 18-05-2007;
Submissão do projecto:
• Documentação do ExtremePlanner – exportar para formato RTF todas as Stories, Tasks e Test Cases. A documentação deverá ser colocada num único ficheiro comprimido com o nome do grupo (e.g., T0000.zip) que deverá ser entregue via Fénix;
• O código do projecto OurDocs deverá ser desenvolvido com recurso ao CVS, sendo a versão avaliada a etiquetada com ES-2 ou, caso não exista, a versão à data limite de entrega (2007-05-18 23:59:59).
