ENGENHARIA DE SOFTWARE ExtremePlanner

Transcrição

1 ENGENHARIA DE SOFTWARE ExtremePlanner Acesso ao sistema: Procedimento de Login: O login e password é definido pelos caracteres iniciais do endereço de do aluno, ou seja, se o endereço de for: gabriel.pestana@tagus.ist.utl.pt ou gcfp@mega.ist.utl.pt então o login e password é: A ferramenta ExtremePlanner requer um minimo de 5 caracteres para a password. Aos s com apenas 4 caracteres foi adicionado o digito 1 ao login e password. A password deverá ser alterada após o primeiro acesso. Clicar no link Options para activar a interface Edit User Options onde poderá alterar a password. Na no sistema online foram criados vários projectos com o mesmo nome dos grupos. O acesso a cada projecto é restrito à respectiva equipa de projecto (ou seja, elementos do grupo). Assim sendo após efectuado o login os elementos da equipa devem seleccionar o projecto com o qual irão trabalhar.

2 Nesta fase todos os elementos da equipa de projecto têm um perfil de acesso de Project Manager. A ferramenta ExtremePlanning implementa a metodologia Extreme Programming 1 de desenvolvimento de software, pelo que a gestão de um projecto segue a sequência de passos da metodologia, ou seja: 1. Registo e descrição dos requisitos dos utilizadores (User Stories); 2. Identificação e calendarização dos entregáveis do projecto (Release planning); 3. Registo e descrição das tarefas a executar para a implementação de cada um dos requisitos (Tasks); 4. Identificação dos testes de aceitação dos requisitos (Test Cases) 5. Estruturar o plano de projecto num conjunto de iterações de curta duração (Iteration planning); 6. Rever calendarização dos entregáveis do projecto (Release planning); User Stories Segue os mesmos propósitos dos casos de uso do UML; Relevantes para estimar o tempo de execução dos requisitos e por conseguinte apoiar a calendarização dos entregáveis do projecto. Os requisitos devem ser descritos na linguagem do cliente, ou seja, evitar termos técnicos que dificultem o entendimento do que se pretende. Razão pela qual o âmbito do requisito tem de ser muito focado e descrito em detalhe. 1 Para mais informação ver o site Gestão de Projectos 2/5

3 O nível de detalhe na descrição do requisito deve ser apenas o suficiente para permitir uma avaliação do esforço (medido em homens/hora) para a sua implementação; Foco é nas necessidade de informação dos utilizadores e não nos requisitos técnicos para a implementação do especificado (esse nível de detalhe poderá ser efectuado aquando da criação das Tasks). Evitar descrições da interface (i.e., GUI); usar uma abordagem centrada nos benefícios e implicações do requisito. O cronograma de implementação de um conjunto de requisitos designa-se de Release Pan, por norma associado a uma entrega. Tarefas & Testes de Aceitação Os requisitos devem ser mapeados num conjunto de tarefas e testes de aceitação. A descrição técnica de uma Story é feita ao nível das tarefas, onde a equipa de programação deverá decompor o requisito no conjunto de tarefas de desenvolvimento de software necessárias para a implementação do requisito. Cada tarefa deverá ter um custo associado (i.e., esforço e tempo); Release Plan Especifica quais os requisitos a implementar em cada entrega Os requisitos a implementar em cada entrega devem ser descritos via tarefas cuja implementação deve ser monitorizada através do Iteration Plan. Uma entrega só pode ser efectuada quando as tarefas do Iteration Plan estiverem todas implementadas. Caso não seja possível implementar todas as tarefas então recomenda-se a criação de uma nova iteração com redistribuição de recursos e reavaliação do esforço. Um Release Plan bem elaborado é quando o custo estimado não diverge muito do custo real. Este conceito efectua um balanceamento de três métricas: Custo, Tempo, Âmbito O nível de prioridade dos requisitos pode ser usado para estruturação de quais os requisitos a implementar primeiro. Iteration Plan Na fase de implementação os requisitos podem ser agrupados dando origem a uma iteração (Iteration Plan); Uma iteração corresponde a um período curto (no caso do projecto de ES medido em horas) e que foca a implementação/desenvolvimento de uma parte do código (e.g., classes de domínio, serviços, ou funcionalidades da camada de apresentação) Classificação dos Requisites e Tarefas Os requisitos e respectivas tarefas devem ser classificadas de forma a estarem em conformidade com as recomendações da metodologia RAPPeL. Gestão de Projectos 3/5

4 Story/Topic Presentation-Behaviour Presentation-Information Needs Presentation-User Interface Requirements Domain-Business Rules Domain-Object Scenarios Descrição Funcionalidades a disponibilizar (botões, links, parâmetros, etc.) Condições que têm de ser satisfeitas para que as funcionalidades possam ser executadas (e.g., user domain = xxx.xxx) Tipo de dados a listar/mostrar no ecrã Condições que têm de ser satisfeitas para a disponibilização da informação no ecrã Definição da semântica Identifica as fontes de informação e como os dados são transformados. Tipo de interface Tratamento das mensagens de erro/excepções Forma como os dados devem ser apresentados Tipos e sequências da interface Identifica requisitos ao nível da camada de domínio relacionados com: Define o comportamento esperado do funcionamento do sistema relativamente a um requisito do negócio Relacionamentos entre requisitos de informação definidos pelos utilizadores (e.g., listar documento identificar o User e a Team) Descrição técnica do mapeamento das regras de negócio pelos objectos de domínio: Response Rules conjunto de condições a verificar de modo a executar determinada acção/operação Pre-condition Rules conjunto de pré-requisitos para executar determinada acção/operação Post-condition Rules conjunto de condições que têm de ser satisfeitas para a prossecução de uma determinada acção/operação Inference Rules regras que originam novos objectos Computation Rule regras que derivam de uma equação ou algoritmo. Obs.: Na análise de requisitos as regras de negócio determinam o comportamento e objectos do domínio pelo que devem ser definidas com recurso a verbos e substantivos. Identifica requisitos ao nível da camada de domínio relacionados com: Descrição dos cenários operacionais/validação de parâmetros Tratamento de erros/excepções Persistência e acessos à base de dados Gestão de Projectos 4/5

5 Story-Tasks Após classificar as Stroies proceder à inserção das tarefas (Tasks). Por uma questão de simplicidade as tarefas deverão especificar também os serviços da Thin Layer que devem ser implementados de forma a que o sistema disponibilize os requisitos identificados Usar os Object Stereotypes para a classificação das tasks. Esta classificação deve ser feita no campo Description seguida de uma descrição dos objectivos da Task: 1. Information holders. 2. Structurers 3. Controllers. 4. Coordinators 5. Service providers 6. Interface objects Exemplo sobre o requisito da interface para a funcionalidade Create User. Caso de uso (requisito do cliente): o Story Name: Create User o Story Description = Um utilizador para poder aceder ao portal Ourdocs tem de estar registado no portal, para tal o utilizador deverá registar o seu login e domínio o Story Topic = Presentation-User Interface Requirements o o Regras de negócio (Tasks da Story Create User): Um domínio é uma string de caracteres com um ponto entre duas strings, ou seja apresenta uma sintaxe definida por «caracteres».«caracteres»; A sequência login e domínio identifica univocamente o utilizador Sequência de Interface (Task da Story Create User): O botão Submit da janela de login requer que os atributos de interface User name e Domin estejam correctamente preenchidos. Gestão de Projectos 5/5