Engenharia de Software 2º Semestre de 2006/2007

Transcrição

1 Engenharia de Software 2º Semestre de 2006/2007 Segundo enunciado detalhado do projecto: Portal OurDocs

2 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 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 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. Pag. 2 de 5

3 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) e definição de um conjunto de Testes de aceitação. Prefixo D-PL+T; Pag. 3 de 5

4 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 entrega 1. 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: ; Data de disponibilização do código base: ; Data Entrega: ; Pag. 4 de 5

5 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 ( :59:59). Pag. 5 de 5