wbma2013 - método Ágil para desenvolvimento de software confiável

Metodo Agil para desenvolvimento de

software confiavel

Alan Braz, Cecılia M. F. Rubira, Marco Vieira<[email protected]>,

<[email protected]>, <[email protected]>

MSc - Instituto de Computacao - UNICAMPPesquisador em Engenharia de Software - IBM Research

WBMA 2013

28 de junho de 2013

Metodo Agil para desenvolvimento de software confiavel

Agenda

1 Introducao e Motivacao

2 Desenvolvimento Agil de Software

3 Scrum+CE

4 Experimento controlado

5 Conclusoes

2 / 50


Introducao e Motivacao

Agenda



3 Scrum+CE


5 Conclusoes

3 / 50



Introducao

Confiabilidade nao e mais um simples requisitonao funcional inerente apenas a sistemascrıticos mas sim a todos os sistemas de softwareque necessitam de certa robustez

Solucoes:Desenvolvimento Baseado em Componentes (DBC)Desenvolvimento Centrado na Arquitetura

O termo confiabilidade sera utilizado no sentido de reliability quee a capacidade do sistema oferecer seus servicos e funcionalidadesconforme suas especificacoes, ou seja, de forma correta.

4 / 50



Historico

Historico

Tratamento de Excecoes no Desenvolvimento de SoftwareConfiavel Baseado em Componentes [Ferreira 2001]

Criacao da Metodologia para Definicao doComportamento Excepcional (MDCE)Adicao de novos estereotipos da UML.Aplicacao ao processo de desenvolvimento Catalysis

Um Metodo para Modelagem de Excecoes emDesenvolvimento Baseado em Componentes [Brito 2005]

Evolucao do MDCE para o MDCE+ enfatizando amodelagem do comportamento excepcional centrado naarquiteturaAdaptacao ao processo UML Components

5 / 50



MDCE+

Metodologia para Definicao do Comportamento

Excepcional (MDCE+)

Sistematiza a modelagem e a implementacao docomportamento excepcional no desenvolvimento desistemas baseados em componentes

Focado nas fases de projeto arquitetural e implementacao

A enfase na arquitetura de software possibilita umamelhor analise dos fluxos de excecoes entre oscomponentes arquiteturais

Construcao de tratadores mais eficientes antecipa acorrecao de possıveis falhas de especificacao.

6 / 50



Motivacao

Motivacao

Trabalho futuro sugerido por Patrick Brito:

Agilidade

Uma possibilidade para agilizar o desenvolvimento dossistemas seria estudar alguns processos ageis e tentarintroduzir algumas de suas caracterısticas no MDCE+.Porem, deve-se ter sempre em mente que nao se podecomprometer a confiabilidade do produto final produzido, umavez que esse e o objetivo principal do metodo MDCE+.

Por outro lado, nao deve comprometer a agilidade!

8 / 50



Proposta

Proposta

Combinacao entre o metodo MDCE+

e a metodologia agil Scrum

Scrum+CE(Scrum com Comportamento Excepcional)

9 / 50



Proposta

MDCE

MDCE+

Catalysis

UMLComponents

Scrum

Scrum+CE

DesenvolvimentoBaseado emComponents

(DBC)

DesenvolvimentoCentrado naArquitetura

1

2

2

3

3

1. 2001 GiseleFerreira

2. 2005 PatrickBrito

3. Este trabalho

– – – Etapasauxiliares

10 / 50



Trabalhos relacionados

Trabalhos relacionados I

Agile Software Development for Component Based SoftwareEngineering [Radinger and Goeschka 2003], foi proposta umaabordagem para integrar o Desenvolvimento Agil de Software(DAS) ao DBC em um Desenvolvimento Agil deComponentes para projetos de pequena e larga escalascombinando as questoes tecnicas e gerenciais de ambas asabordagens. Todas as fases do DBC foram mantidas e comfoco em um documento de arquitetura completo e detalhadodo sistema bem como na analise e projeto igualmentedetalhados. Na fase de provisionamento de componentes, sefor tomada a decisao de que um componente devera serdesenvolvido, sua construcao devera seguir uma abordagemagil como se fosse um subprojeto.

11 / 50




Trabalhos relacionados II

Software Architecture-Centric Methods and AgileDevelopment [Nord and Tomayko 2006] explora as relacoes esinergias entre a Analise e Projeto centrado na Arquitetura eo metodo agil XP, destacando que o segundo enfatiza odesenvolvimento rapido e flexıvel enquanto o primeiro priorizao projeto e a infraestrutura.

12 / 50




Trabalhos relacionados III

Software Reliability Engineering (SRE) for Agile SoftwareDevelopment [Far 2007] foi mostrado que, apesar de teremenfoques distintos, existe compatibilidade entre odesenvolvimento de software confiavel e agil em torno dosaspectos de se medir e avaliar a confiabilidade do softwaredesenvolvido. SRE executa testes no software criado com oobjetivo de validar os parametros de confiabilidadepreviamente definidos e modelados, enquanto que o metodoagil se apoia em uma abordagem dirigida por testes, TDD, naqual os casos de testes sao escritos antes do codigo eexecutados constantemente, preferencialmente de formaautomatica, durante o processo de desenvolvimento. Foiproposto um novo processo, chamado Agile-SRE.

13 / 50


Desenvolvimento Agil de Software

Agenda



3 Scrum+CE


5 Conclusoes

14 / 50



Desenvolvimento Agil de Software (DAS)

Conjunto de metodologias de desenvolvimento de softwareguiados por quatro valores e doze princıpios definidos em2001 no Manifesto Agil. [Beck et al. 2001]

1 Indivıduos e as interacoes entre elesmais que processos e ferramentas,

2 Software em funcionamentomais que documentacao abrangente,

3 Colaboracao com o clientemais que negociacao de contratos, e

4 Responder a mudancasmais que seguir um plano.

15 / 50



Crıticas

Enfoque na organizacao das equipes e aspectosgerenciais

Impressao de que documentar os requisitos,definir um projeto arquitetural, fazer analise edesign nao sao obrigatorios ou nao precisam denenhum tipo de rigor

Porem um dos princıpios dita:“atencao contınua a excelenciatecnica e a um bom projeto (design)”

16 / 50



Desafios

Os maiores desafios sao provenientes da transformacaocultural exigida:

Custo e o Tempo sao fixos, e o Escopo variavel,Forca o cliente a pensar nos requisitos realmenteobrigatorios para atender as suas necessidades,Muda a mentalidade de gerente de projetos edesenvolvedores,Muda a forma em que requisitos sao estimados econtratos sao negociados.

Motivacao:

Simplicidade e confundida com informalidadeou falta de rigor

17 / 50



Metodo Scrum

Metodo Scrum

Desenvolvimento iterativo de incremental

Equipes pequenas e multidisciplinares

Abordagem empırica

Rapido, adaptavel e auto-organizado

Requisitos no formato de Historias de Usuarios(User Stories)*

Estimativas feitas com Pontos de Historias(Story Points)*

* Praticas ageis amplamente utilizadas mas que nao fazem parte do

Scrum oficialmente

18 / 50



Metodo Scrum

Fases do Scrum

Pré-jogo- Planejamento- Arquitetura Inicial

Pós-jogo- Testes de integração- Empacotamento- Fechamento

Jogo

Sprints

Desen

volv

imen

to* Integração

Revisã

oAjustes

* engloba Análise, Projeto e Codificação

http://www.jeffsutherland.org/oopsla/schwapub.pdf [Schwaber 1995]

19 / 50

http://www.jeffsutherland.org/oopsla/schwapub.pdf



Metodo Scrum

Papeis, eventos e artefatos

1

2

3

4

5

6

7

8

9

10

Entradas dos Executivos, Equipe, Clientes, Usuários e

outros Envolvidos

Dono do Produto1

Backlog doProduto2

Reunião de Planejamento

do Sprint3

Equipe de Desenvolvimento1

Backlog doSprint2

Scrum Master1

Retrospectiva do Sprint3

Incremento Pronto2

Revisão do Sprint3

GráficoBurndown2

Reunião de Scrum Diário3

Sprint2-4

semanas

Data de entrega e Backlog do Sprint não sofrem alterações

após o início do Sprint

TarefasHistórias de Usuário

1Papel, 2Artefato, 3Evento

Time seleciona as de maior prioridade que pode se comprometer a entregar

Cada24 horas

20 / 50



Metodo Scrum

Historias de Usuario

Cartao Uma breve descricao da historia usada noplanejamento

Conversacao Forca a discussao entre os envolvidos paraobter mais detalhes

Confirmacao Testes de validacao e documentacao dosdetalhes

Formato / Modelo

Como um papel/ator, eu quero objetivo,para que eu possa valor de negocio.

21 / 50



Metodo Scrum

Exemplo de Historia de Usuario

Cartao

Como um Passageiro eu quero buscar uma linha de onibus quetenha um ponto de parada proximo a um endereco desejado, paraque eu possa caminhar o mınimo possıvel para chegar ao ponto.

Confirmacao na forma de Testes de Aceitacao

Consigo escolher o turno e sentido?

O formato do endereco e composto por latitude e longitude?

A resposta e a sigla da linha encontrada?

O ponto encontrado esta a menos de 500 metros?

O ponto e de parada?

22 / 50


Scrum+CE

Agenda



3 Scrum+CE


5 Conclusoes

23 / 50


Scrum+CE

Solucao proposta: Scrum+CE

Pré-jogo- Planejamento- Arquitetura Inicial

Pós-jogo- Testes de integração- Empacotamento- Fechamento

Jogo

Sprints

Desen

volv

imen

to* Integração

Revisã

oAjustes

* engloba Análise,Projeto e Codificação

Identificação das Exceções e Definição dos cenários excepcionais na forma de

Histórias Excepcionais

Descrição das Assertivas Excepcionais

Implementação dos Componentes e Criação de “wrappers” para os components reutilizados

Separação de interesse entre os componentes

Normais e Excepcionais Análise do Fluxo Excepcional e Refinamento dos tratadores

Implementação dos conectores

24 / 50


Scrum+CE

Papeis, eventos e artefatos

1

2

3

4

5

6

7

8

9

10

Entradas dos Executivos, Equipe, Clientes, Usuários e

outros Envolvidos

Dono do Produto1

Backlog doProduto2

Reunião de Planejamento

do Sprint3

Equipe de Desenvolvimento1

Backlog doSprint2

Scrum Master1

Retrospectiva do Sprint3

Incremento Pronto2

Revisão do Sprint3

GráficoBurndown2

Reunião de Scrum Diário3

Sprint2-4

semanas

Data de entrega e Backlog do Sprint não sofrem alterações

após o início do Sprint

TarefasHistórias de Usuário e Histórias

Excepcionais

1Papel, 2Artefato, 3EventoDono da Arquitetura1

Time seleciona as de maior prioridade que pode se comprometer a entregar

Arquitetura Inicial2

Cada24 horas

25 / 50


Scrum+CE

Relacao entre as fases

Tabela: Relacao entre as fases do MDCE+ e do Scrum.

Fases do Scrum Eventos do Scrum Fases do MDCE+

Pre-jogoPlanejamento

FASE 1: Especificacao e Analise dos RequisitosFASE 2: Definicao dos Aspectos Gerenciais

Arquitetura FASE 3: Projeto Arquitetural

Jogo

Planejamento do Sprint

FASE 1: Especificacao e Analise dos RequisitosFASE 3: Projeto ArquiteturalFASE 4: Analise do SistemaFASE 5: Projeto do Sistema

SprintFASE 6: Materializacao dos ComponentesFASE 7: Integracao dos Componentes

Revisao do SprintFASE 1: Especificacao e Analise dos RequisitosFASE 8: Implantacao (demonstracao ao cliente)

Pos-jogoTestes de integracao FASE 7: Integracao dos ComponentesEmpacotamento

FASE 8: Implantacao (entrega ao cliente)Fechamento

26 / 50


Scrum+CE

Fases afetadas

Fases afetadas

Pre-jogo

Comportamento excepcional sera documentado na formade Historias Excepcionais e de Testes de Aceitacao nasHistorias de Usuario que validem especificamente osfluxos excepcionais.Arquitetura Inicial passara a expor os componentesexcepcionais conforme o modelo de componentetolerante a falhas ideal que e categorizado em dois tipos:normal, que produz respostas corretas; e excepcional (ouanormal), que e executado quando um erro e detectado.Definicao de “Pronto”: o tratamento docomportamento excepcional tambem deve serexplicitado, adicionando o seguinte trecho:“. . . e todas as excecoes foram devidamente tratadas”.

27 / 50


Scrum+CE

Fases afetadas

Exemplo de Historia Excepcional

Cartao

Como um Usuario eu quero ver uma mensagem de erro quando obanco de dados estiver indisponıvel, para que eu possa evitar avisualizacao de mensagens tecnicas.

Confirmacao na forma de Testes de Aceitacao

Uma mensagem de erro e mostrada quando o banco de dados estafora do ar?

Uma mensagem de erro e mostrada ocorre um erro de autenticacaono banco de dados?

Uma mensagem de erro e mostrada quando um consulta malformatada e feita no banco de dados?

28 / 50


Scrum+CE

Fases afetadas

Exemplo de Testes de Aceitacao Excepcionais

Cartao

Como um Passageiro eu quero buscar uma linha de onibus que tenha umponto de parada proximo a um endereco desejado, para que eu possacaminhar o mınimo possıvel para chegar ao ponto.

Testes de Aceitacao Excepcionais

Mostrar mensagem de erro se nao houverem parametros de entrada;O parametro Turno nao pode ser nulo;O parametro Turno deve ser um numero inteiro positivo;Mostrar mensagem de erro caso nao existirem linhas para o Turnodesejado;O parametro Sentido nao pode ser nulo;O parametro Sentido deve ser um unico caractere;O valores validos de Sentido sao: T, t, C, c;Os parametros de Latitude e Longitude nao podem ser nulos;Os valores de Latitude e Longitude devem ser numericos, com casasdecimais, negativos ou positivos.

29 / 50


Scrum+CE

Fases afetadas

Fases afetadas

Jogo

As Historias Excepcionais sao priorizadas, com ajuda doDono da Arquitetura, e selecionadas do Product Backlogassim como as Historias de Usuarios

Tarefas explıcitas para o tratamento das excecoes devemser criadas no Sprint Backlog durante a Reuniao dePlanejamento do Sprint

Arquitetura deve ser revisada e atualizada caso novasexcecoes sejam descobertas

30 / 50


Scrum+CE

Fases afetadas

Fases afetadas

Reuniao de Planejamento dividida em trespartes:

1 O que vai ser entregue como resultado do Incrementodo proximo Sprint;

2 Qual o impacto de tais mudancas na arquitetura;

3 Como sera realizado o trabalho necessario para adaptara arquitetura e entregar o Incremento.

31 / 50


Experimento controlado

Agenda



3 Scrum+CE


5 Conclusoes

32 / 50



Metodologia

Metodologia

Foi realizado um experimento controladoquantitativo com o intuito de avaliar aaplicabilidade pratica do metodo Scrum+CE.

Implementacao de um sistema de software comrequisitos de confiabilidade relativos aconsistencia dos dados.

Formatado em um treinamento de“Scrum na Pratica” com duracao de 2 semanas,composto por 3 equipes de 4 participantes cada.

33 / 50



Definicao

Tabela: Visao Geral do experimento.

Objetivo Analisar a viabilidade do uso do Scrum+CE no desenvolvimento de siste-mas de informacao com requisito de confiabilidade sem perder a agilidade,atraves da comparacao com o uso do Scrum.

Foco daqualidade Melhor qualidade do codigo gerado atraves da diminuicao dos numero de

defeitos;Entrega de menor quantidade de Pontos de Historia.

Contexto Objeto: sistema de software para plataforma web em linguagem JavaSujeitos: desenvolvedores profissionais com pelo menos 3 anos de ex-periencia em Java (67% certificados)

Hipotese nulaIgual ou maior numero de defeitos.Igual ou maior numero de Pontos de Historia entregues.

Fator principal Praticas propostas pelo Scrum+CE em relacao ao ScrumOutros fatores Experiencia dos desenvolvedores na plataforma Java e no processo Scrum.Variaveisdependentes

(i) Corretude do codigo entregue avaliada pela execucao de um conjunto detestes funcionais manuais;(ii) Quantidade de Pontos de Historia entregues;(iii) Metricas de tamanho e complexidade do codigo gerado.

34 / 50



Preparacao

Reducao

Adaptacao da duracao dos eventos para viabilizar oexperimento.

Tabela: Fatores de reducao para viabilizar simulacao.

Fator Sugerido Utilizado

Tamanho da Equipe de Desenvolvimento entre 5 e 9 4Quantidade de Sprints na Release 1 ou mais 2Duracao total do Sprint entre 2 e 4 semanas 1 semanaDuracao da Reuniao de Planejamento do Sprint entre 4 e 8 horas 2 horasDuracao do Scrum Diario 15 minutos 3 minutosDuracao do dia de trabalho 8 horas 2 horasDuracao da Revisao do Sprint entre 2 e 4 horas 1 horaDuracao da Retrospectiva do Sprint entre 2 e 4 horas 1 hora

35 / 50



O Problema

Sistema implementado

Tabela: Visao do sistema.

Para usuarios do servico de fretados e funcionarios do departamentode transportes.

Que precisam saber qual linha de onibus passa por determinado pontoem um determinado horario.

O BusMaps e uma plataforma movel.Que controla os itinerarios das linhas de fretados atraves do cadastro

e manutencao dos pontos de parada dos onibus.Ao contrario do sistema atual que apenas lista as avenidas e ruas principais

de cada linha e seu horario de partida no sentido de ida para aempresa.

Nosso produto possibilitara a visualizacao dos itinerarios em ambos os sentidos,bem como o horario previsto de parada em cada ponto, facili-tando assim a busca das linhas pelos usuarios e a manutencao eplanejamento dos itinerarios pelo setor de transportes.

36 / 50



O Problema

Arquitetura

DB2OpenJPARestlet

Navegador

Celular

Entidades

ApresentaçãoExcepcional

PersistênciaExcepcional

Interface deUsuário

Sessão do Usuário / Serviços de Sistema

Serviços de NegócioBanco de

Dados

JSON

HTTP

37 / 50



O Problema

Modelo de Dados

38 / 50



Execucao

Atividades

39 / 50



Execucao

Agenda

40 / 50



Execucao

Grupos e Papeis

253, 36%

225, 32%

233, 33%

G1 - Controle - Scrum

G2 - Experimental - Scrum+CE

G3 - Experimental - Scrum+CE

Figura: Indice total dos grupos.

Tabela: Mapeamento dos papeis do Scrum aos participantes doexperimento.

Papel Representante

Dono do Produto pesquisadorDono da Arquitetura pesquisadorScrum Master pesquisadorEquipe de Desenvolvimento participantes do experimento

41 / 50



Resultados

Historias entregues

Disponíveis no Backlog do Produto

G1 G2 G30

10

20

30

40

50

60

70

61

4945 47

139 7 8

Pontos de Estória

Estórias de Usuário

Grupos

Qu

an

tida

de

Figura: Total de Historias e Pontos entregues.

Tabela: Historiasentregues por grupodo experimento.

Historia Pontos G1 G2 G3

1 20 • • •2 5 • • •3 8 • • •4 3 • • •5 3 • • •6 2 • •7 1 • • •8 3

9 5 • • •10 2 •11 2

12 5

13 2

42 / 50



Resultados

Historias entregues

G2 entregou 22% menos historias que G1.G3 entregou 11% menos historias que G1.

Estórias entregues Pontos entregues-25%

-20%

-15%

-10%

-5%

0%

-22%

-8%

-11%

-4%

G2/G1

G3/G1

Figura: Comparacao das entregas entre G1 e G2, e entre G1 e G3.

43 / 50



Resultados

Metricas de qualidade dos requisitos

Tabela: Testes realizados edefeitos encontrados porgrupo experimento.

Metrica G1 G2 G3

Testes realizados 189 149 161Testes falhos 66 44 21Taxa de insucesso 35% 30% 13%

Testes realizados Testes falhos Taxa de insucesso-80%

-70%

-60%

-50%

-40%

-30%

-20%

-10%

0%

-21%

-33%

-5%

-15%

-68%

-22%

G2/G1

G3/G1

Figura: Comparacao dos defeitos entreG1 e G2, e entre G1 e G3.

G2 falhou 5% menos que G1.

G3 falhou 22% menos que G1.

44 / 50



Resultados

Metricas de qualidade de codigo

Tabela: Metricas de qualidade de codigo.

Metrica G1 G2 G3

Linhas de codigo 2232 1984 1950Numero de Classes 27 47 38Numero de Excecoes 1 21 2Blocos catch de excecoes nativas 53 18 33Blocos catch de excecoes criadas 9 12 6Complexidade Ciclomatica total 446 305 288Complexidade Ciclomatica por classe 15.9 4.5 7.2Complexidade Ciclomatica por metodo 5.0 2.4 2.5

G2 e G3 entregaram 12% menos linhas de codigo que G1.G2 e G3 tiveram complexidade 33% menor que G1.

45 / 50


Conclusoes

Agenda



3 Scrum+CE


5 Conclusoes

46 / 50


Conclusoes

Conclusoes

Aplicar o Scrum+CE resultou em:

Melhor qualidade do codigo gerado atraves da diminuicaodos numero de defeitos. Validado!

13.5% menos defeitos em media!Complexidade 33% menor implica melhor design!

Entrega de menor quantidade de Pontos de Historia.Validado!

Apenas 6% menos devido ao tamanho do experimento.Crıtica: Experimento nao escala!

E possıvel desenvolver software confiavel commetodo agil!

Adicionar o Comportamento Excepcional nao interferena agilidade.

47 / 50


Agradecimentos

Agradecimentos

Orientadora:Profa. Dra. Cecılia M. F. Rubira - IC - UNICAMP

Co-orientador:Prof. Marco VieiraDEI - Universidade de Coimbra(UC)

Banca da qualificacao:

Profa. Dra. Eliane Martins - IC - UNICAMPProf. Dr. Hans Kurt Edmund Liesenberg - IC -UNICAMP

Banca da defesa:

Profa. Dra. Regina Lucia de Oliveira Moraes - FT -UNICAMPProfa. Dra. Eliane Martins - IC - UNICAMP

48 / 50


Bibliografia

Bibliografia I

Beck, K. et al. (2001).

Manifesto para Desenvolvimento Agil de Software.http://agilemanifesto.org/iso/ptbr/.Acessado em 18 de setembro de 2011.

Brito, P. H. S. (2005).Um Metodo para Modelagem de Excecoes em Desenvolvimento Baseado emComponentes.Master’s thesis, IC, Unicamp.

Far, B. (2007).Software Reliability Engineering for Agile Software Development.20th IEEE Canadian Conference on Electrical and Computer EngineeringCCECE, pages 694–697.

Ferreira, G. R. M. (2001).Tratamento de excecoes no desenvolvimento de sistemas confiaveis baseados emcomponentes.Master’s thesis, IC, Unicamp.

49 / 50

http://agilemanifesto.org/iso/ptbr/


Bibliografia

Bibliografia II

Nord, R. L. and Tomayko, J. E. (2006).Software Architecture-Centric Methods and Agile Development.IEEE Software, 23(2):47–53.

Radinger, W. and Goeschka, K. M. (2003).Agile software development for component based software engineering.Companion of the 18th annual ACM SIGPLAN conference on Object-orientedprogramming, systems, languages, and applications.

Schwaber, K. (1995).SCRUM Development Process.In Proceedings of the 10th Annual ACM Conference on Object OrientedProgramming Systems, Languages, and Applications (OOPSLA), pages 117–134.

50 / 50

wbma2013 - método Ágil para desenvolvimento de software confiável

Technology