Desenvolvimento de Software como Serviço através do uso de Metodologias Ágeis

Regis Pires Magalhães (IFPI), Nécio de Lima Veras (IFCE)

Parceria

2

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

3

Introdução

4

Introdução Sistemas computacionais estão em todo lugar

Qualidade é um item obrigatório Conceito atual

Computação em Nuvem

5

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)

6

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

7

Processos de Desenvolvimento

8

Introdução à abordagem de Projetos

9

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?

10

Engenharia de software

A ideia foi incluir a disciplina de engenharia no desenvolvimento de software;

A E.S. engloba três elementos fundamentais:

11

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];

12

O modelo cascata em imagem

13

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.

14

O modelo espiral em imagem

15

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?

16

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].

17

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...

18

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].

19

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

20

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”;

21

Um exemplo real de SOA

Facebook Platform

Google+

22

Arquitetura de uma livraria com software silo

Perceba:Os acessos aos

dados;Uma API externa

única contendo todos os subsistemas.

23

Arquitetura de uma livraria com SOA

PercebaSeparação e

independência de subsistemas;

Bases separadas por contextos;

Fatias verticais de camadas;

Fatias conectadas por serviços;

Reusabilidade.

24

Computação em Nuvem

25

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.

26

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.

27

Economia de escala

•Custos menores por máquina e de pessoal;

•Melhor aproveitamento do poder computacional de cada máquina.

28

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].

29

Utility Computing

• Usuários não se preocupam com:▫ Escalabilidade;▫ Backups.

• Exemplos: Amazon Elastic Compute Cloud (EC2), Google App Engine e Microsoft Azure.

30

Utility Computing – Farmville

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

31

Modelos de Serviço

32

Software como Serviço (SaaS)

33

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 infra-estrutura [Sousa et. al. 2009].

34

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.

35

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.

36

Crescimento de SaaS

• As vantagens impulsionam o rápido crescimento de SaaS.

• Versões SaaS para softwares tradicionais:▫ Microsoft Office 365

37

Desvantagens

• Necessidade de boa conexão com a Internet▫ Trabalho online

• Versão offline que sincroniza com versão online, acrescenta complexidade ao software.

38

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.

39

Arquitetura MVC

40

Testes

41

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].

42

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)

43

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

44

Testes

45

Test Driven Development

Testes Passo 1: Cria-se o teste! Mesmo SEM a classe principal.

47

public class TestaSorteio {

private Sorteio sorteio;

@Beforepublic void setUp() throws Exception {

sorteio = new Sorteio();}

@Testpublic void testTotalParticipantes() {

sorteio.setTotal(200);assertEquals(200, sorteio.getTotalParticipantes() );

}}

Testes Passo 2: Tenta-se executar o teste, mas o mesmo não funcionará porque o

código está incompleto.

48

Testes Passo 3: Cria os códigos de maneira que ele faça o teste funcionar.

49

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

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

50

Testes Passo 5: Refatora-se o código implementado de maneira que ele funcione

agora para outros testes.

51

public class Sorteio {

int total;

public void setTotal(int total){this.total = total;

}

public int getTotal(){return total;

}

}

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

52

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 de usuários.

BDD se concentra no comportamento da aplicação versus a implementação da aplicação e os testes são conduzidos utilizando TDD.

53

Fluxo padrão do BDD

54

Fluxo padrão do BDD

55

Fluxo padrão do BDD

56

Fluxo padrão do BDD

57

BDD – Estória 1 Uma narrativa simples: uma confirmação de inscrição para o ENUCOMP

faz o participante concorrer a um sorteio.

58

BDD – Classe que mapeia a Estória 1

59

BDD – Classe que testa tudo

60

Resultado da execução

61

Integração Contínua

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

63

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.

64

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

65

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.

66

Implantação (deploy)

● Basicamente três ambientes são bastante utilizados pela comunidade:● Desenvolvimento: Desenvolvida● Homologação: Testada● Produção : Podemos visualizar funcionando

67

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…

68

Heroku

É necessário instalar GIT em sua máquina

69

GIT: Comandos

git add .

git commit -m “Minha Mensagem do Commit”

git pull

git push origin master

Adicionando arquivos (que foram modificados ou arquivos novos)

Comitando as suas modificações

Recebendo as atualizações

Enviando as suas alterações para o origin (remoto)

70

Conclusão

71

Conclusão72

● 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.

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.

73

Referências74

● 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):50–58.

● Beck, K., et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. http://agilemanifesto.org/. Acessado em 18 de agosto de 2012.

● Fox, A., Patterson, D. (2012). “Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing”, Alpha Edition. Strawberry Canyon LLC, 2012.

● 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 2011.

● Pressman, R. S. (2005). “Software engineering: a practitioner’s approach”, 6 ed. New York: MacGraw-Hill, 2005.

● 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, 619-638.

● 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.

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