Desenvolvimento de Software como Serviço através do uso de Metodologias Ágeis. Regis Pires Magalhães (IFPI), Nécio de Lima Veras (IFCE)

Transcrição

1 Desenvolvimento de Software como Serviço através do uso de Metodologias Ágeis Regis Pires Magalhães (IFPI), Nécio de Lima Veras (IFCE)

2 2 Parceria

3 3 Agenda Introdução Processos de Desenvolvimento Arquitetura Orientada a Serviço (SOA) Computação em Nuvem Software como Serviço (SaaS) Arquitetura Modelo-Visão-Controlador (MVC) Testes Integração Contínua Implantação (Deploy) da Aplicação Uso de sistemas de controle de versão

4 4 Introdução

5 5 Introdução Sistemas computacionais estão em todo lugar Qualidade é um item obrigatório Conceito atual Computação em Nuvem

6 6 Introdução Engenharia de Software Meta: criar software de qualidade com melhor custo-benefício Envolve Processos de Software ( Receita de bolo para atingir a meta) Geralmente aumenta o tempo de entrega do sistema Métodos Ágeis Processos menos prescritivos Desenvolvimento incremental do sistema (pequenas entregas)

7 7 Introdução Na indústria de software moderna demanda-se o desenvolvimento de sistemas em menos tempo e com qualidade superior Alguns meios: Métodos Ágeis Testes (qualidade) Ferramentas de Suporte (ferramentas para controle de versão, IDE s e frameworks de desenvolvimento) Arquitetura MVC (Model-View-Controller) Implantação (deployment) das aplicações diretamente na nuvem

8 8 Processos de Desenvolvimento

9 9 Introdução à abordagem de Projetos

10 10 Produtos de software Surge de ideias conceituais e reajustáveis; É intangível; Possui escopo variável; É dotado de incertezas constantes; Difícil visualização do produto final. Mas como obter um produto de software com qualidade diante de todas estas peculiaridades?

11 11 Engenharia de software A ideia foi incluir a disciplina de engenharia no desenvolvimento de software; A E.S. engloba três elementos fundamentais:

12 12 Processos de desenvolvimento Processos para construção de um software são como conjuntos de passos que irão trabalhar de forma ampla definições, desenvolvimento e manutenção; São compreendidos por Paradigmas da Engenharia de Software ou Modelos de Ciclo de Vida de Software [Pressman 2005];

13 13 O modelo cascata em imagem

14 14 Evolução do modelo Notou-se que quando o cliente visualiza um protótipo ele consegue entender melhor o que quer; Isso fez com que fossem combinados: O modelo Waterfall + Protótipos; Existiria uma sequência de 4 fases até atingir um protótipo mais apurado em relação ao anterior. Eis que surge o modelo Espiral.

15 15 O modelo espiral em imagem

16 16 Interseção entre ambos os modelo? Longo período de tempo para o desenvolvimento; Volume muito grande de documentação e planejamento; Fases maiores ainda => Big Design Up Front (BDUF); E agora, para onde vamos?

17 17 Agilidade Um grupo em fevereiro de 2001, chamado de Agile Alliance, começou a descobrir maneiras melhores e mais leves de desenvolver software valorizando: pessoas e interações ao invés de processos e ferramentas; softwares funcionando no lugar de documentações abrangentes; colaborações com clientes do que negociações de contratos e respostas à mudanças por planos fechados. Esses valores originaram o Manifesto Ágil com outros DOZE princípios que regem a filosofia de criar softwares com agilidade [Beck 2001].

18 18 Agilidade O modelo é baseado em mudanças abrangentes e; melhoria contínua de um protótipo incompleto; Algumas práticas são enfatizadas tais como: Test-Driven Development (TDD); Test-Driven Behavior (BDD) User Stories; Integração Contínua; Dentre outras...

19 19 Contraste com os outros dois modelos É tão rápido que novas versões são disponibilizadas ao cliente a cada duas semanas e novos recursos são adicionados continuamente ao mesmo protótipo até que o cliente esteja satisfeito [Fox e Patterson 2012].

20 20 Arquitetura Orientada a Serviço (SOA Service Oriented Architecture)

21 21 Arquitetura Orientada a Serviço (SOA) SOA é uma arquitetura de software onde todos os componentes são projetados para virarem serviços; Os componentes de uma aplicação devem atuar como serviços interoperáveis e podem ser usados de forma independente e/ou recombinados com outras aplicações; Uma implementação contrária a essa ideia é conhecida como software silo ;

22 22 Um exemplo real de SOA Facebook Platform Google+

23 23 Arquitetura de uma livraria com software silo Perceba: Os acessos aos dados; Uma API externa única contendo todos os subsistemas.

24 24 Arquitetura de uma livraria com SOA Perceba Separação e independência de subsistemas; Bases separadas por contextos; Fatias verticais de camadas; Fatias conectadas por serviços; Reusabilidade.

25 25 Computação em Nuvem

26 26 Computação em Nuvem SOA está nos fundamentos de Computação em Nuvem. Provê infra-estrutura composta de: (i) Comunicação realizada através da Internet; (ii) Escalabilidade para lidar com flutuações na demanda, atendendo rapidamente ao crescimento do número de usuários; (iii) Confiabilidade para que o serviço e a comunicação estejam continuamente disponíveis.

27 27 Clusters Antes: servidores de custo elevado mais confiáveis. É mais fácil lidar com poucos servidores do que com muitos computadores com menos recursos. Clusters Permitiram a interligação de computadores de baixo custo. Vantagens: mais escaláveis; distribuição de software facilitada (uso de máquinas virtuais); mais confiáveis devido ao uso de redundância; baixo custo do hardware; distribuição geográfica dificulta indisponibilidade do serviço.

28 28 Economia de escala Custos menores por máquina e de pessoal; Melhor aproveitamento do poder computacional de cada máquina.

29 29 Utility Computing Serviço de nuvem pública capaz de oferecer poder de processamento, armazenamento e comunicação a centavos por hora [Armbrust et al. 2010]. Recursos pagos pelo uso (pay-as-you-go). semelhante a serviços de distribuição de água, luz e telefonia. Objetivo: Fornecer armazenamento, CPUs e largura de banda como mercadoria, através de provedores especializados com um baixo custo por unidade utilizada [Sousa et al. 2010].

30 30 Utility Computing Usuários não se preocupam com: Escalabilidade; Backups. Exemplos: Amazon Elastic Compute Cloud (EC2), Google App Engine e Microsoft Azure.

31 31 Utility Computing Farmville Serviço Amazon Elastic Compute Cloud (EC2). 4 dias - 1 milhão de jogadores 9 meses - 75 milhões de jogadores

32 32 Modelos de Serviço

33 33 Software como Serviço (SaaS)

34 34 Software como Serviço (SaaS) Fornece softwares e dados com propósitos específicos. Softwares ficam acessíveis a partir de vários dispositivos. Não exige instalação e execução de código binário na máquina cliente. Desenvolvedores focam em inovação e não na infraestrutura [Sousa et. al. 2009].

35 35 Software como Serviço (SaaS) Disponibilidade em qualquer lugar e momento. Atualizações transparentes para os usuários. Exemplos: Aplicações Web relacionadas a busca, redes sociais e vídeos.

36 36 Vantagens [Fox e Patterson 2012] Não é preciso instalar a aplicação, nem se preocupar com hardware ou sistema operacional; Dados armazenados e gerenciados pelo próprio serviço. Ambiente propício ao compartilhamento, edição e manipulação coletiva dos dados. Software servidor em ambiente controlado pelo desenvolvedor. Possibilidade de lançar versões de testes para parte dos usuários. Atualizações mais fáceis e freqüentes de hardware e software. Evita a pirataria. Cobrança periódica e/ou pelo uso.

37 37 Crescimento de SaaS As vantagens impulsionam o rápido crescimento de SaaS. Versões SaaS para softwares tradicionais: Microsoft Office 365

38 38 Desvantagens Necessidade de boa conexão com a Internet Trabalho online Versão offline que sincroniza com versão online, acrescenta complexidade ao software.

39 39 Frameworks para desenvolvimento de SaaS Alguns frameworks foram especificamente concebidos para facilitar o desenvolvimento através de metodologias Ágeis. Alinham-se ao ciclo de vida ágil. Aplicações podem ser facilmente disponibilizadas em modelos de PaaS ou mesmo IaaS. Exemplos: Play Framework VRaptor Grails Django Ruby on Rails etc.

40 40 Arquitetura MVC

41 41 Testes

42 42 Testes A grande maioria das pessoas já teve alguma experiência com um software que não funcionou como esperado. Softwares que não funcionam corretamente podem levar a muitos problemas, incluindo financeiro, tempo e reputação das empresas. Podendo, inclusive, chegar a influenciar na integridade das pessoas [ISTQB 2011].

43 43 Testes Podemos associar a qualidade de um software à quantidade de falhas percebidas no mesmo O teste de software ajuda a medir e/ou garantir essa qualidade Níveis de Teste Unidade (componente) Integração (interface entre componentes) Sistema (comportamento) Aceitação (apropriado para uso)

44 44 Testes Métodos de Testes; No contexto de testes automáticos se sobressaem duas abordagens: TDD (Testing-Driven Development) ou Desenvolvimento dirigido por testes BDD (Behavior-Driven Design) ou Projeto guiado por comportamento

45 45 Testes

46 Test Driven Development

47 47 Testes Passo 1: Cria-se o teste! Mesmo SEM a classe principal. public class TestaSorteio { private Sorteio public void setup() throws Exception { sorteio = new Sorteio(); } public void testtotalparticipantes() { sorteio.settotal(200); assertequals(200, sorteio.gettotalparticipantes() ); }

48 48 Testes Passo 2: Tenta-se executar o teste, mas o mesmo não funcionará porque o código está incompleto.

49 49 Testes Passo 3: Cria os códigos de maneira que ele faça o teste funcionar. public class Sorteio { int total; public void settotal(int total){ } public int gettotal(){ return 200; } } Perceba que o código funcionará apenas para esse teste

50 50 Testes Passo 4: Roda-se o Teste e verifica-se que o mesmo será VERDE.

51 51 Testes Passo 5: Refatora-se o código implementado de maneira que ele funcione agora para outros testes. public class Sorteio { int total; public void settotal(int total){ this.total = total; } public int gettotal(){ return total; } }

52 52 Testes Passo 6: Repete-e novamente os testes que DEVEM continuar verdes.

53 53 Testes de comportamento Sobre BDD podemos fazer as seguintes considerações [Fox e Patterson 2012]: BDD faz perguntas sobre comportamentos antes e durante o desenvolvimento; Requisitos são escritos como estórias BDD se concentra no comportamento da aplicação versus a implementação da aplicação e os testes são conduzidos utilizando TDD. de usuários.

54 54 Fluxo padrão do BDD

55 55 Fluxo padrão do BDD

56 56 Fluxo padrão do BDD

57 57 Fluxo padrão do BDD

58 58 BDD Estória 1 Uma narrativa simples: uma confirmação de inscrição para o ENUCOMP faz o participante concorrer a um sorteio.

59 59 BDD Classe que mapeia a Estória 1

60 60 BDD Classe que testa tudo

61 61 Resultado da execução

62 Integração Contínua

63 63 Integração contínua Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente. Martin Fowler

64 64 Integração contínua Cada commit no servidor de integração contínua realiza um build da aplicação e executa todos os testes. Vantagem: Feedback instantâneo. Após o processo bem sucedido de integração contínua a aplicação está pronta para implantação no servidor de produção. Ferramentas: CruiseControl, Hudson, Jenkins, Bamboo, BuildMaster, AnthillPro e Teamcity.

65 65 Implantação (Deploy) da Aplicação

66 66 Implantação (deploy) O processo de implantação é todo o conjunto de atividades necessárias para que o software esteja disponível para o cliente. O momento para a realização desse processo vai depender dos acordos feitos entre o desenvolvedor e o cliente.

67 67 Implantação (deploy) Basicamente três ambientes são bastante utilizados pela comunidade: Desenvolvimento: Desenvolvida Homologação: Testada Produção : Podemos visualizar funcionando

68 68 Heroku PaaS que permite fazer deploy automático da aplicação Utiliza GIT para enviar a aplicação para a nuvem. É gratuito com um determinado limite (vamos utilizar esse limite) Bem simples para fazer deploy de aplicações com Play, Rails e outros frameworks

69 69 Heroku É necessário instalar GIT em sua máquina

70 70 GIT: Comandos Adicionando arquivos (que foram modificados ou arquivos novos) git add. Comitando as suas modificações git commit -m Minha Mensagem do Commit Recebendo as atualizações git pull Enviando as suas alterações para o origin (remoto) git push origin master

71 71 Conclusão

72 72 Conclusão Engenharia de software cada vez mais focada na qualidade e eficiência do software. Buscamos também rapidez na entrega. Metodologias Ágeis aliam esses fatores. A Internet revoluciona o modo como o software é feito e distribuído.

73 73 Conclusão O modelo de SaaS e a arquitetura MVC viabilizam o desenvolvimento de software mais dinâmico, colaborativo, eficiente e com feedback do usuário. Os testes de software e ambientes de integração contínua asseguram a qualidade do software de forma automatizada. Sistemas de controle de versão e modelos de fluxos de trabalho facilitam o desenvolvimento em equipe e possibilitam um gerenciamento mais efetivo sobre as modificações ocorridas no software.

74 74 Referências Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., and Zaharia, M. (2010). A view of cloud computing. Commun. ACM, 53(4): Beck, K., et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Acessado em 18 de agosto de Fox, A., Patterson, D. (2012). Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Alpha Edition. Strawberry Canyon LLC, Hoelzle, U. and Barroso, L. A. (2009). The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines. Morgan and Claypool Publishers, 1st edition. ISTQB. (2011). Certified Tester Foundation Level Syllabus, version Pressman, R. S. (2005). Software engineering: a practitioner s approach, 6 ed. New York: MacGraw-Hill, Serman, D. V. (2010). Orientação a projetos: uma proposta de desenvolvimento de uma arquitetura orientada a serviços. JISTEM: Journal of Information Systems and Technology Management, Sin mes, Sousa, F. R. C., Moreira, L. O. e Machado, J. C. (2009). Computação em Nuvem: Conceitos, Tecnologias, Aplicações e Desafios. In: Santos Neto, P. (Org.). III Escola Regional de Computação Ceará - Maranhão - Piauí, ERCEMAPI 2009, 1 ed. SBC, Piauí. Sousa, F. R. C., Moreira, L. O., Macedo, J. A. F. e Machado, J. C. (2010). Gerenciamento de Dados em Nuvem: Conceitos, Sistemas e Desafios. In: XXV Simpósio Brasileiro de Banco de Dados, 2010, Belo Horizonte. SBBD 2010.

75 Obrigado! Dúvidas, sugestões, comentários?