Contextualizando XP para Web engineering

Apresentação em tema: "Contextualizando XP para Web engineering"— Transcrição da apresentação:

1 Contextualizando XP para Web engineering
Américo Tadeu Falcone Sampaio

2 Visão geral do trabalho
Apresentar conceitos e uma visão geral sobre Extreme Programming (XP); Apresentar conceitos sobre Web Engineering; Contextualizar XP dentro da Web Engineering e verificar possibilidades de adaptação da metodologia.

3 Extreme Programming (XP)
É uma metodologia ágil de engenharia de software, ou seja, promove: Indivíduos e interações ao invés de processos e ferramentas; Software que “roda” ao invés de documentação em demasia; Colaboração do cliente ao invés de negociação de contratos; Responder a mudanças ao invés de seguir um plano rígido. O objetivo de XP é servir como um processo ágil de engenharia de software cujo principal foco é entregar funcionalidades de forma rápida e eficiente. Além disso, XP foi criado considerando que mudanças são inevitáveis e que devem ser incorporadas constantemente.

4 Conceitos básicos Valores: Comunicação, simplicidade, feedback e coragem. Estes quatro valores servem como critérios que norteiam as pessoas envolvidas no desenvolvimento de software seguindo a metodologia XP. Princípios fundamentais: feedback rápido, assumir simplicidade, mudança incremental, abraçando mudanças e trabalho de qualidade. Práticas: Jogo do planejamento (The planning game); Releases pequenas (Small releases); Metáfora (Metaphor); Projeto simples (Simple design); Testando (Testing); Refactoring; Programação em par (Pair programming); Posse coletiva do código (Collective ownership); Integração contínua (Continuous integration); 40 horas por semana (40-hour week); Cliente no local (On-site customer); Padrões de codificação (Coding standards).

5 Valores Comunicação: XP se foca em construir um entendimento pessoa-para-pessoa do problema com o uso mínimo de documentação formal e com o uso máximo de interação cara-a-cara entre as pessoas envolvidas no projeto. Simplicidade: XP sugere que cada membro da equipe adote a solução mais fácil que possa funcionar. O objetivo é fazer aquilo que é mais simples hoje e criar um ambiente em que o custo de mudanças no futuro é baixo. Feedback: O feedback é importante pois possibilita que as pessoas aprendam cada vez mais sobre o sistema e assim corrijam os erros e melhorem o sistema. Coragem: Ela é necessária para que realmente se aplique XP como deve ser aplicado. Exemplos de atitude que exigem coragem são: alterar código já escrito e que está funcionando; jogar código fora e reescrever tudo de novo; e permitir código compartilhado por todos.

6 Princípios Feedback rápido – Um dos princípios é receber o feedback, interpretá-lo e colocar o que foi aprendido de volta no sistema o mais rápido possível. Os programadores aprendem a melhor forma de projetar, implementar e testar o sistema e retornam o aprendizado. Assumir simplicidade – Todo problema deve ser tratado para ser resolvido da forma mais simples possível. XP afirma que se deve fazer um bom trabalho (testes, refactoring, comunicação) em resolver hoje os problemas de hoje e confiar na sua habilidade de adicionar complexidade no futuro quando for necessária. Mudança incremental – Quando muitas mudanças são realizadas todas de uma vez, não se obtêm um bom resultado. Em vez disso, esse princípio de XP diz que as mudanças devem ser incrementais e feitas aos poucos.

7 Princípios - Continuação
· Abraçando mudanças (Embracing Change) – XP procura facilitar o ato de incluir alterações através do uso de vários princípios e práticas. · Trabalho de qualidade – Em XP, qualidade não é um critério opcional mas sim obrigatório. Embora a definição de qualidade possa variar de pessoa para pessoa, XP trata qualidade no sentido de se ter um sistema que atenda os requisitos do cliente, que rode 100% dos casos de teste e que agregue o maior valor possível para o negócio.

8 Práticas O jogo do planejamento (The planning game) – No final de cada release é feita uma determinação rápida do escopo da próxima, através da combinação de estimativas e prioridades do negócio. Uma release consiste de várias iterações e, em cada iteração, várias estórias (use case simplificadas) são implementadas. Os programadores estimam cada estória e dizem quantas eles podem implementar no final da release. Releases pequenas (Small releases) – Beck diz: “cada release deve ser tão pequena quanto possível, contendo os requisitos mais importantes para o negócio”. Isso possibilita ter releases freqüentes o que resulta em maior feedback para clientes e programadores, facilitando o aprendizado e a correção dos defeitos do sistema. Metáfora (Metaphor) – A intenção da metáfora é oferecer uma visão geral do sistema, em um formato simples, que possa ser compartilhada por clientes e programadores. É semelhante a uma arquitetura porém feita de uma forma mais simples.

9 Práticas - continuação
Projeto simples (Simple Design) – Pode-se explicar esta prática em duas partes: A primeira diz que devem ser projetadas as funcionalidades que já foram definidas e não as que poderão ser definidas futuramente. A segunda diz que deve ser feito o melhor projeto que possa entregar tais funcionalidades. Testando (Testing) – Os casos de testes em XP são feitos antes da programação. Existem dois tipos de teste: teste de unidade e teste funcional. Os testes de unidade são feitos para verificar tudo que possa dar errado. Os testes são automatizados, e toda vez que o programador escrever código, ele irá verificar se o sistema roda 100%. Refactoring – Essa prática pode ser definida como constantes melhorias no projeto do software para aumentar sua capacidade de se adaptar a mudanças. O refactoring consiste em aplicar uma série de passos para melhorar o projeto do código existente, tornando-o mais simples, sem alterar sua funcionalidade.

10 Práticas - continuação
Posse coletiva do código (Collective ownership) – Qualquer membro do projeto pode alterar qualquer parte do código a qualquer tempo. A programação em par encoraja duas pessoas a trabalharem juntas procurando atingir o melhor resultado possível. Enquanto isso, a posse coletiva encoraja a equipe inteira a trabalhar mais unida em busca de qualidade no código. Integração contínua (Continuous integration) – O código escrito deve ser constantemente integrado na versão atual. As alterações feitas não podem quebrar o que foi feito antes devem passar em 100% dos testes. 40 horas por semana (40-hour week) – Essa não é uma regra que obriga as equipes em projetos XP a trabalharem somente 40 horas por semana. No entanto, Beck diz que não se deve trabalhar 2 semanas seguidas além desse tempo, pois o cansaço e a insatisfação de trabalhar horas extras pode resultar numa queda de qualidade do código.

11 Práticas - continuação
Cliente no local (On-site customer) – Deve ser incluído na equipe uma pessoa da parte do cliente, que irá usar o sistema, para trabalhar junto com os outros e responder as perguntas e dúvidas. Padrões de codificação (Coding standards) – Como XP prega a posse coletiva de código, onde todos podem alterar e fazer refactoring de qualquer parte do código a qualquer momento, então é mais do que necessário que se tenha padrões de codificação. O objetivo é que todos programem da mesma forma, facilitando o entendimento do código e as alterações.

12 Web Engineering Tópico recente da área de engenharia de software;
Preocupa-se com as características inerentes aos sistemas Web. Procura abordar aspectos que diferem da ES tradicional e como adaptar metodologias e processos de software existentes para o desenvolvimento de sistemas para a Web;

13 Caraterísticas dos sistemas Web
Diversos tipos de clientes que podem acessar o sistema via browsers distintos, via dispositivos wireless (celulares, PDAs, Pocket PCs); Possui uma arquitetura hipermídia distribuída; Rodam em ambientes heterogêneos com diversos tipos de hardware e software; Estão constantemente sendo alterados e integrados com outros sistemas e dispositivos.

14 Cenário atual de projetos de software
Ciclos de desenvolvimento curtos, tipicamente 3 meses ou menos; Times de desenvolvimento pequenos (4 a 6 pessoas) e multidisciplinares; Melhor teste e avaliação dos produtos construídos; Em projetos de sistemas Web: Mais rigor na análise de requisitos, incluindo uma análise clara das necessidades de negócio e preocupação com requisitos não funcionais; Preocupação com questões de navegação e interfaces; Maior preocupação com as questões relativas a evolução e integração dos sistemas Web. Processos ágeis surgem levando em consideração as questões acima. A Web Engineering pode se beneficiar de metodologias ágeis.

15 O que existe atualmente
Existem técnicas e metodologias que podem ser incorporadas em processos de software como RUP e XP fazendo as devidas adaptações. Técnicas de modelagem baseadas na UML com extensões para aplicações WEB (WAE, W2000, etc). Metodologias de Projeto de sistemas Hipermídia (HDM, OOHDM e outras). Não são processos completos de ES.

16 Extensões de UML 3 características importantes para estender a UML para a Web que são: modelagem de elementos específicos de aplicações Web tais como página cliente, pagina servidor, links, frames, formulários entre outros; navegação; e apresentação (interface). Existem 3 abordagens feitas respectivamente por J. Conallen (WAE), N. Koch (Koch) e L. Baresi (Framework W2000).

17 Extensões de UML - Comparação
A WAE (Web Application Extension), proposta por J. Conallen, define um conjunto de estereótipos para modelagem dos elementos específicos descritos anteriormente, porém não atende a um aspecto muito importante que é o da navegação.  A extensão proposta por N. Koch , que é baseada na OOHDM (Object Oriented Hipermedia Design Method) , trata dos aspectos de navegação e apresentação, porém não define estereótipos para modelar os elementos básicos.  O framework W2000, proposto por L. Baresi, é uma caracterização do HDM (Hipermedia Design Method) usando o meta modelo da UML. Ele trata apenas dos aspectos de navegação.

18 Extensões UML – Quadro Resumo

19 Técnicas de Projeto de sistemas Hipermídia
Sistemas Web podem ser considerados sistemas Hipermídia. Essas técnicas podem ser incorporadas dentro de um processo de engenharia de software. As principais são HDM (Hipermidia Design Method) e OOHDM (Object Oriented Hipermedia Design Method)

20 OOHDM Em OOHDM, uma aplicação hipermídia é construída em um processo de cinco passos em um estilo iterativo e incremental. Cada passo mantém seu foco em um interesse particular de projeto e um modelo orientado a objetos é construído. Classificação, agregação e generalização/especialização são usadas durante o processo para melhorar o poder de abstração e as oportunidades de reuso. Possui cinco atividades: captura de requisitos, modelagem de domínio ou conceitual, projeto navegacional, projeto da interface abstrata e implementação

21 Resumo dos passos de OOHDM
O primeiro passo é capturar os requisitos do sistema. Os cenários são então coletados para formar uma Use Case que é representada usando Diagramas de Interação do Usuário (UID). Em seguida, um conjunto de guidelines é aplicado aos UIDs para extrair o modelo conceitual. O próximo passo é construir o modelo conceitual do domínio da aplicação usando técnicas conhecidas de modelagem orientada a objetos, além de algumas primitivas para perspectivas de atributos (atributos multivalorados) similares às perspectivas HDM. Na atividade de projeto da interface abstrata o modelo é construído pela definição de objetos perceptíveis (ex. figura, mapa, etc.) em termos de classes de interface Na implementação ocorre o mapeamento dos objetos de interface em objetos implementacionais

22 XP e Web Engineering Web Engineering possui características como: equipes multidisciplinares (XP); ciclos curtos de desenvolvimento (XP); grande quantidade de requisitos não funcionais; preocupação com questões de navegação e interfaces; preocupação com as questões relativas a evolução e integração dos sistemas Web; e mudanças constantes nos requisitos (XP). XP atende a algumas dessas características e falha em outras. Atende: ver acima (XP) Não atende  a metodologia precisa ser adaptada XP pode ser adaptado para a Web Engineering

23 Falha de XP: Navegação e Interface
Uma das questões fundamentais no desenvolvimento de sistemas para a Web é a do projeto da navegação e das páginas do Website. Os sistemas Web são concebidos para serem usados por diversos tipos de usuário, com perfis e funções diferentes, que podem navegar de diversas maneiras para obter informações de seu interesse. Então, qualquer metodologia que trate da construção de sistemas Web deve levar isso em consideração.  Ao analisar a metodologia XP nota-se a omissão em relação a esse assunto. Para solucionar o problema pode-se pensar em importar para XP, práticas de projeto de navegação e interface adotadas por outras metodologias como extensões de UML (seção 2.3) e OOHDM (seção 2.4). É importante mencionar que a incorporação de tais práticas deve ser feita respeitando os valores e princípios de XP, caso contrário ela pode perder a sua característica de metodologia ágil.

24 Outras falhas A questão de modelagem em XP não é muito levada em consideração visto que seu foco é maior em implementação e testes. Possibilidades de solução: Utilização de modelagem baseada em técnicas ágeis (Agile Modeling) e utilização de Design Patterns As questões arquiteturais em XP são descritas de forma superficial através da metáfora. O problema da metáfora é que ela é relativamente estática e estável o que não se alinha ao desenvolvimento Web que deve possuir um alto grau de dinamismo para incorporar as mudanças de infraestrutura e permitir a evolução dos sistemas Web. Considerar uso de padrões arquiteturais

25 Conclusão Extreme Programming pode ser adaptado para a Web Engineering; A adaptação deve ser feita de forma a preservar as caraterísticas ágeis de XP e responder às peculiaridades dos sitemas Web; Já existem iniciativas semelhantes de criação de processos ágeis para Web Engineering (AWE process).