WBMA2013 - Método Ágil para desenvolvimento de software confiável

Método Ágil para desenvolvimento de
software confiável
Alan Braz, Cec´ılia M. F. Rubira, Marco Vieira
<alanbraz@br.ibm.com>,
<cmrubira@ic.unicamp.br>, <mvieira@dei.uc.pt>
MSc - Instituto de Computa¸cão - UNICAMP
Pesquisador em Engenharia de Software - IBM Research
WBMA 2013
28 de junho de 2013

Método Ágil para desenvolvimento de software confiável
Agenda
1 Introdu¸cão e Motiva¸cão
2 Desenvolvimento Ágil de Software
3 Scrum+CE
4 Experimento controlado
5 Conclusões
2 / 50

Introdu¸cão e Motiva¸cão
Agenda
3 Scrum+CE
5 Conclusões
3 / 50

Introdu¸cão
Confiabilidade não é mais um simples requisito
não funcional inerente apenas a sistemas
cr´ıticos mas sim a todos os sistemas de software
que necessitam de certa robustez
Solu¸cões:
Desenvolvimento Baseado em Componentes (DBC)
Desenvolvimento Centrado na Arquitetura
O termo confiabilidade será utilizado no sentido de reliability que
é a capacidade do sistema oferecer seus servi¸cos e funcionalidades
conforme suas especifica¸cões, ou seja, de forma correta.
4 / 50

Histórico
Histórico
Tratamento de Exce¸cões no Desenvolvimento de Software
Confiável Baseado em Componentes [Ferreira 2001]
Cria¸cão da Metodologia para Defini¸cão do
Comportamento Excepcional (MDCE)
Adi¸cão de novos estereótipos da UML.
Aplica¸cão ao processo de desenvolvimento Catalysis
Um Método para Modelagem de Exce¸cões em
Desenvolvimento Baseado em Componentes [Brito 2005]
Evolu¸cão do MDCE para o MDCE+ enfatizando a
modelagem do comportamento excepcional centrado na
arquitetura
Adapta¸cão ao processo UML Components
5 / 50

MDCE+
Metodologia para Defini¸cão do Comportamento
Excepcional (MDCE+)
Sistematiza a modelagem e a implementa¸cão do
comportamento excepcional no desenvolvimento de
sistemas baseados em componentes
Focado nas fases de projeto arquitetural e implementa¸cão
A ênfase na arquitetura de software possibilita uma
melhor análise dos fluxos de exce¸cões entre os
componentes arquiteturais
Constru¸cão de tratadores mais eficientes antecipa a
corre¸cão de poss´ıveis falhas de especifica¸cão.
6 / 50

Motiva¸cão
Motiva¸cão
Trabalho futuro sugerido por Patrick Brito:
Agilidade
Uma possibilidade para agilizar o desenvolvimento dos
sistemas seria estudar alguns processos ágeis e tentar
introduzir algumas de suas caracter´ısticas no MDCE+.
Porém, deve-se ter sempre em mente que não se pode
comprometer a confiabilidade do produto final produzido, uma
vez que esse é o objetivo principal do método MDCE+.
Por outro lado, não deve comprometer a agilidade!
8 / 50

Proposta
Proposta
Combina¸cão entre o método MDCE+
e a metodologia ágil Scrum
Scrum+CE
(Scrum com Comportamento Excepcional)
9 / 50

Proposta
MDCE
MDCE+
Catalysis
UML
Components
Scrum
Scrum+CE
Desenvolvimento
Baseado em
Components
(DBC)
Desenvolvimento
Centrado na
Arquitetura
1
2
2
3
3
1. 2001 Gisele
Ferreira
2. 2005 Patrick
Brito
3. Este trabalho
– – – Etapas
auxiliares
10 / 50

Trabalhos relacionados
Trabalhos relacionados I
Agile Software Development for Component Based Software
Engineering [Radinger and Goeschka 2003], foi proposta uma
abordagem para integrar o Desenvolvimento Ágil de Software
(DAS) ao DBC em um Desenvolvimento Ágil de
Componentes para projetos de pequena e larga escalas
combinando as questões técnicas e gerenciais de ambas as
abordagens. Todas as fases do DBC foram mantidas e com
foco em um documento de arquitetura completo e detalhado
do sistema bem como na análise e projeto igualmente
detalhados. Na fase de provisionamento de componentes, se
for tomada a decisão de que um componente deverá ser
desenvolvido, sua constru¸cão deverá seguir uma abordagem
ágil como se fosse um subprojeto.
11 / 50

Trabalhos relacionados II
Software Architecture-Centric Methods and Agile
Development [Nord and Tomayko 2006] explora as rela¸cões e
sinergias entre a Análise e Projeto centrado na Arquitetura e
o método ágil XP, destacando que o segundo enfatiza o
desenvolvimento rápido e flex´ıvel enquanto o primeiro prioriza
o projeto e a infraestrutura.
12 / 50

Trabalhos relacionados III
Software Reliability Engineering (SRE) for Agile Software
Development [Far 2007] foi mostrado que, apesar de terem
enfoques distintos, existe compatibilidade entre o
desenvolvimento de software confiável e ágil em torno dos
aspectos de se medir e avaliar a confiabilidade do software
desenvolvido. SRE executa testes no software criado com o
objetivo de validar os parâmetros de confiabilidade
previamente definidos e modelados, enquanto que o método
ágil se apoia em uma abordagem dirigida por testes, TDD, na
qual os casos de testes são escritos antes do código e
executados constantemente, preferencialmente de forma
automática, durante o processo de desenvolvimento. Foi
proposto um novo processo, chamado Agile-SRE.
13 / 50

Desenvolvimento ´Agil de Software
Agenda
3 Scrum+CE
5 Conclus˜oes
14 / 50

Desenvolvimento Ágil de Software (DAS)
Conjunto de metodologias de desenvolvimento de software
guiados por quatro valores e doze princ´ıpios definidos em
2001 no Manifesto Ágil. [Beck et al. 2001]
1 Indiv´ıduos e as intera¸cões entre eles
mais que processos e ferramentas,
2 Software em funcionamento
mais que documenta¸cão abrangente,
3 Colabora¸cão com o cliente
mais que negocia¸cão de contratos, e
4 Responder a mudan¸cas
mais que seguir um plano.
15 / 50

Cr´ıticas
Enfoque na organiza¸cão das equipes e aspectos
gerenciais
Impressão de que documentar os requisitos,
definir um projeto arquitetural, fazer análise e
design não são obrigatórios ou não precisam de
nenhum tipo de rigor
Porém um dos princ´ıpios dita:
“aten¸cão cont´ınua a excelência
técnica e a um bom projeto (design)”
16 / 50

Desafios
Os maiores desafios são provenientes da transforma¸cão
cultural exigida:
Custo e o Tempo são fixos, e o Escopo variável,
For¸ca o cliente a pensar nos requisitos realmente
obrigatórios para atender as suas necessidades,
Muda a mentalidade de gerente de projetos e
desenvolvedores,
Muda a forma em que requisitos são estimados e
contratos são negociados.
Motiva¸cão:
Simplicidade é confundida com informalidade
ou falta de rigor
17 / 50

Método Scrum
Método Scrum
Desenvolvimento iterativo de incremental
Equipes pequenas e multidisciplinares
Abordagem emp´ırica
Rápido, adaptável e auto-organizado
Requisitos no formato de Histórias de Usuários
(User Stories)*
Estimativas feitas com Pontos de Histórias
(Story Points)*
* Práticas ágeis amplamente utilizadas mas que não fazem parte do
Scrum oficialmente
18 / 50

M´etodo Scrum
Fases do Scrum
Pré-jogo
- Planejamento
- Arquitetura Inicial
Pós-jogo
- Testes de integração
- Empacotamento
- Fechamento
Jogo
Sprints
D
esenvolvim
ento*
Integração
Revisão
A
justes
* engloba Análise, Projeto e Codificação
http://www.jeffsutherland.org/oopsla/schwapub.pdf [Schwaber 1995]
19 / 50

M´etodo Scrum
Pap´eis, 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 do
Produto2
Reunião de
Planejamento
do Sprint3
Equipe de
Desenvolvimento1
Backlog do
Sprint2
Scrum Master1
Retrospectiva
do Sprint3
Incremento Pronto2
Revisão do Sprint3
Gráfico
Burndown2
Reunião de
Scrum Diário3
Sprint
2-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
1
Papel, 2
Artefato, 3
Evento
Time seleciona
as de maior
prioridade
que pode se
comprometer
a entregar
Cada
24 horas
20 / 50

Método Scrum
Histórias de Usuário
Cartão Uma breve descri¸cão da história usada no
planejamento
Conversa¸cão For¸ca a discussão entre os envolvidos para
obter mais detalhes
Confirma¸cão Testes de valida¸cão e documenta¸cão dos
detalhes
Formato / Modelo
Como um papel/ator, eu quero objetivo,
para que eu possa valor de negócio.
21 / 50

Método Scrum
Exemplo de História de Usuário
Cartão
Como um Passageiro eu quero buscar uma linha de ônibus que
tenha um ponto de parada próximo a um endere¸co desejado, para
que eu possa caminhar o m´ınimo poss´ıvel para chegar ao ponto.
Confirma¸cão na forma de Testes de Aceita¸cão
Consigo escolher o turno e sentido?
O formato do endere¸co é composto por latitude e longitude?
A resposta é a sigla da linha encontrada?
O ponto encontrado esta a menos de 500 metros?
O ponto é de parada?
22 / 50

Scrum+CE
Agenda
3 Scrum+CE
5 Conclus˜oes
23 / 50

Scrum+CE
Solu¸c˜ao proposta: Scrum+CE
Pré-jogo
- Planejamento
- Arquitetura Inicial
Pós-jogo
- Testes de integração
- Empacotamento
- Fechamento
Jogo
Sprints
D
esenvolvim
ento*
Integração
Revisão
A
justes
* 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
Pap´eis, 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 do
Produto2
Reunião de
Planejamento
do Sprint3
Equipe de
Desenvolvimento1
Backlog do
Sprint2
Scrum Master1
Retrospectiva
do Sprint3
Incremento Pronto2
Revisão do Sprint3
Gráfico
Burndown2
Reunião de
Scrum Diário3
Sprint
2-4
semanas
Data de entrega e Backlog do
Sprint não sofrem alterações
após o início do Sprint
Tarefas
Histórias de
Usuário e
Histórias
Excepcionais
1
Papel, 2
Artefato, 3
EventoDono da Arquitetura1
Time seleciona
as de maior
prioridade
que pode se
comprometer
a entregar
Arquitetura Inicial2
Cada
24 horas
25 / 50

Scrum+CE
Rela¸cão entre as fases
Tabela: Rela¸cão entre as fases do MDCE+ e do Scrum.
Fases do Scrum Eventos do Scrum Fases do MDCE+
Pré-jogo
Planejamento
FASE 1: Especifica¸cão e Análise dos Requisitos
FASE 2: Defini¸cão dos Aspectos Gerenciais
Arquitetura FASE 3: Projeto Arquitetural
Jogo
Planejamento do Sprint
FASE 3: Projeto Arquitetural
FASE 4: Análise do Sistema
FASE 5: Projeto do Sistema
Sprint
FASE 6: Materializa¸cão dos Componentes
FASE 7: Integra¸cão dos Componentes
Revisão do Sprint
FASE 8: Implanta¸cão (demonstra¸cão ao cliente)
Pós-jogo
Testes de integra¸cão FASE 7: Integra¸cão dos Componentes
Empacotamento
FASE 8: Implanta¸cão (entrega ao cliente)
Fechamento
26 / 50

Scrum+CE
Fases afetadas
Fases afetadas
Pré-jogo
Comportamento excepcional será documentado na forma
de Histórias Excepcionais e de Testes de Aceita¸cão nas
Histórias de Usuário que validem especificamente os
fluxos excepcionais.
Arquitetura Inicial passará a expor os componentes
excepcionais conforme o modelo de componente
tolerante a falhas ideal que é categorizado em dois tipos:
normal, que produz respostas corretas; e excepcional (ou
anormal), que é executado quando um erro é detectado.
Defini¸cão de “Pronto”: o tratamento do
comportamento excepcional também deve ser
explicitado, adicionando o seguinte trecho:
“. . . e todas as exce¸cões foram devidamente tratadas”.
27 / 50

Scrum+CE
Fases afetadas
Exemplo de História Excepcional
Cartão
Como um Usuário eu quero ver uma mensagem de erro quando o
banco de dados estiver indispon´ıvel, para que eu possa evitar a
visualiza¸cão de mensagens técnicas.
Confirma¸cão na forma de Testes de Aceita¸cão
Uma mensagem de erro é mostrada quando o banco de dados está
fora do ar?
Uma mensagem de erro é mostrada ocorre um erro de autentica¸cão
no banco de dados?
Uma mensagem de erro é mostrada quando um consulta mal
formatada é feita no banco de dados?
28 / 50

Scrum+CE
Fases afetadas
Exemplo de Testes de Aceita¸cão Excepcionais
Cartão
Como um Passageiro eu quero buscar uma linha de ônibus que tenha um
ponto de parada próximo a um endere¸co desejado, para que eu possa
caminhar o m´ınimo poss´ıvel para chegar ao ponto.
Testes de Aceita¸cão Excepcionais
Mostrar mensagem de erro se não houverem parâmetros de entrada;
O parâmetro Turno não pode ser nulo;
O parâmetro Turno deve ser um número inteiro positivo;
Mostrar mensagem de erro caso não existirem linhas para o Turno
desejado;
O parâmetro Sentido não pode ser nulo;
O parâmetro Sentido deve ser um único caractere;
O valores válidos de Sentido são: T, t, C, c;
Os parâmetros de Latitude e Longitude não podem ser nulos;
Os valores de Latitude e Longitude devem ser numéricos, com casas
decimais, negativos ou positivos.
29 / 50

Scrum+CE
Fases afetadas
Fases afetadas
Jogo
As Histórias Excepcionais são priorizadas, com ajuda do
Dono da Arquitetura, e selecionadas do Product Backlog
assim como as Histórias de Usuários
Tarefas expl´ıcitas para o tratamento das exce¸cões devem
ser criadas no Sprint Backlog durante a Reunião de
Planejamento do Sprint
Arquitetura deve ser revisada e atualizada caso novas
exce¸cões sejam descobertas
30 / 50

Scrum+CE
Fases afetadas
Fases afetadas
Reunião de Planejamento dividida em três
partes:
1 O que vai ser entregue como resultado do Incremento
do próximo Sprint;
2 Qual o impacto de tais mudan¸cas na arquitetura;
3 Como será realizado o trabalho necessário para adaptar
a arquitetura e entregar o Incremento.
31 / 50

Experimento controlado
Agenda
3 Scrum+CE
5 Conclus˜oes
32 / 50

Metodologia
Metodologia
Foi realizado um experimento controlado
quantitativo com o intuito de avaliar a
aplicabilidade prática do método Scrum+CE.
Implementa¸cão de um sistema de software com
requisitos de confiabilidade relativos a
consistência dos dados.
Formatado em um treinamento de
“Scrum na Prática” com dura¸cão de 2 semanas,
composto por 3 equipes de 4 participantes cada.
33 / 50

Defini¸cão
Tabela: Visão Geral do experimento.
Objetivo Analisar a viabilidade do uso do Scrum+CE no desenvolvimento de siste-
mas de informa¸cão com requisito de confiabilidade sem perder a agilidade,
através da compara¸cão com o uso do Scrum.
Foco da
qualidade
Melhor qualidade do código gerado através da diminui¸cão dos número de
defeitos;
Entrega de menor quantidade de Pontos de História.
Contexto Objeto: sistema de software para plataforma web em linguagem Java
Sujeitos: desenvolvedores profissionais com pelo menos 3 anos de ex-
periência em Java (67% certificados)
Hipótese nula
Igual ou maior número de defeitos.
Igual ou maior número de Pontos de História entregues.
Fator principal Práticas propostas pelo Scrum+CE em rela¸cão ao Scrum
Outros fatores Experiência dos desenvolvedores na plataforma Java e no processo Scrum.
Variáveis
dependentes
(i) Corretude do código entregue avaliada pela execu¸cão de um conjunto de
testes funcionais manuais;
(ii) Quantidade de Pontos de História entregues;
(iii) Métricas de tamanho e complexidade do código gerado.
34 / 50

Prepara¸cão
Redu¸cão
Adapta¸cão da dura¸cão dos eventos para viabilizar o
experimento.
Tabela: Fatores de redu¸cão para viabilizar simula¸cão.
Fator Sugerido Utilizado
Tamanho da Equipe de Desenvolvimento entre 5 e 9 4
Quantidade de Sprints na Release 1 ou mais 2
Dura¸cão total do Sprint entre 2 e 4 semanas 1 semana
Dura¸cão da Reunião de Planejamento do Sprint entre 4 e 8 horas 2 horas
Dura¸cão do Scrum Diário 15 minutos 3 minutos
Dura¸cão do dia de trabalho 8 horas 2 horas
Dura¸cão da Revisão do Sprint entre 2 e 4 horas 1 hora
Dura¸cão da Retrospectiva do Sprint entre 2 e 4 horas 1 hora
35 / 50

O Problema
Sistema implementado
Tabela: Visão do sistema.
Para usuários do servi¸co de fretados e funcionários do departamento
de transportes.
Que precisam saber qual linha de ônibus passa por determinado ponto
em um determinado horário.
O BusMaps é uma plataforma móvel.
Que controla os itinerários das linhas de fretados através do cadastro
e manuten¸cão dos pontos de parada dos ônibus.
Ao contrário do sistema atual que apenas lista as avenidas e ruas principais
de cada linha e seu horário de partida no sentido de ida para a
empresa.
Nosso produto possibilitará a visualiza¸cão dos itinerários em ambos os sentidos,
bem como o horário previsto de parada em cada ponto, facili-
tando assim a busca das linhas pelos usuários e a manuten¸cão e
planejamento dos itinerários pelo setor de transportes.
36 / 50

O Problema
Arquitetura
DB2
OpenJPARestlet
Navegador
Celular
Entidades
Apresentação
Excepcional
Persistência
Excepcional
Interface de
Usuário
Sessão do Usuário /
Serviços de Sistema
Serviços de Negócio
Banco de
Dados
JSON
HTTP
37 / 50

O Problema
Modelo de Dados
38 / 50

Execu¸c˜ao
Atividades
39 / 50

Execu¸c˜ao
Agenda
40 / 50

Execu¸cão
Grupos e Papéis
253, 36%
225, 32%
233, 33%
G1 - Controle - Scrum
G2 - Experimental - Scrum+CE
G3 - Experimental - Scrum+CE
Figura: Índice total dos grupos.
Tabela: Mapeamento dos papéis do Scrum aos participantes do
experimento.
Papel Representante
Dono do Produto pesquisador
Dono da Arquitetura pesquisador
Scrum Master pesquisador
Equipe de Desenvolvimento participantes do experimento
41 / 50

Resultados
Histórias entregues
Disponíveis no
Backlog do
Produto
G1 G2 G3
0
10
20
30
40
50
60
70
61
49
45
47
13
9
7 8
Pontos de
Estória
Estórias de
Usuário
Grupos
Quantidade
Figura: Total de Histórias e Pontos entregues.
Tabela: Histórias
entregues por grupo
do experimento.
História 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
Histórias entregues
G2 entregou 22% menos histórias que G1.
G3 entregou 11% menos histórias que G1.
Estórias entregues Pontos entregues
-25%
-20%
-15%
-10%
-5%
0%
-22%
-8%
-11%
-4%
G2/G1
G3/G1
Figura: Compara¸cão das entregas entre G1 e G2, e entre G1 e G3.
43 / 50

Resultados
Métricas de qualidade dos requisitos
Tabela: Testes realizados e
defeitos encontrados por
grupo experimento.
Métrica G1 G2 G3
Testes realizados 189 149 161
Testes falhos 66 44 21
Taxa 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: Compara¸cão dos defeitos entre
G1 e G2, e entre G1 e G3.
G2 falhou 5% menos que G1.
G3 falhou 22% menos que G1.
44 / 50

Resultados
Métricas de qualidade de código
Tabela: Métricas de qualidade de código.
Métrica G1 G2 G3
Linhas de código 2232 1984 1950
Número de Classes 27 47 38
Número de Exce¸cões 1 21 2
Blocos catch de exce¸cões nativas 53 18 33
Blocos catch de exce¸cões criadas 9 12 6
Complexidade Ciclomática total 446 305 288
Complexidade Ciclomática por classe 15.9 4.5 7.2
Complexidade Ciclomática por método 5.0 2.4 2.5
G2 e G3 entregaram 12% menos linhas de código que G1.
G2 e G3 tiveram complexidade 33% menor que G1.
45 / 50

Conclus˜oes
Agenda
3 Scrum+CE
5 Conclus˜oes
46 / 50

Conclusões
Conclusões
Aplicar o Scrum+CE resultou em:
Melhor qualidade do código gerado através da diminui¸cão
dos número de defeitos. Validado!
13.5% menos defeitos em média!
Complexidade 33% menor implica melhor design!
Entrega de menor quantidade de Pontos de História.
Validado!
Apenas 6% menos devido ao tamanho do experimento.
Cr´ıtica: Experimento não escala!
É poss´ıvel desenvolver software confiável com
método ágil!
Adicionar o Comportamento Excepcional não interfere
na agilidade.
47 / 50

Agradecimentos
Agradecimentos
Orientadora:
Profa. Dra. Cec´ılia M. F. Rubira - IC - UNICAMP
Co-orientador:
Prof. Marco Vieira
DEI - Universidade de Coimbra(UC)
Banca da qualifica¸cão:
Profa. Dra. Eliane Martins - IC - UNICAMP
Prof. Dr. Hans Kurt Edmund Liesenberg - IC -
UNICAMP
Banca da defesa:
Profa. Dra. Regina Lúcia de Oliveira Moraes - FT -
UNICAMP
Profa. Dra. Eliane Martins - IC - UNICAMP
48 / 50

Bibliografia
Bibliografia I
Beck, K. et al. (2001).
Manifesto para Desenvolvimento Ágil de Software.
http://agilemanifesto.org/iso/ptbr/.
Acessado em 18 de setembro de 2011.
Brito, P. H. S. (2005).
Um Método para Modelagem de Exce¸cões em Desenvolvimento Baseado em
Componentes.
Master’s thesis, IC, Unicamp.
Far, B. (2007).
Software Reliability Engineering for Agile Software Development.
20th IEEE Canadian Conference on Electrical and Computer Engineering
CCECE, pages 694–697.
Ferreira, G. R. M. (2001).
Tratamento de exce¸cões no desenvolvimento de sistemas confiáveis baseados em
componentes.
Master’s thesis, IC, Unicamp.
49 / 50

Bibliograﬁa
Bibliograﬁa 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-oriented
programming, systems, languages, and applications.
Schwaber, K. (1995).
SCRUM Development Process.
In Proceedings of the 10th Annual ACM Conference on Object Oriented
Programming Systems, Languages, and Applications (OOPSLA), pages 117–134.
50 / 50

WBMA2013 - Método Ágil para desenvolvimento de software confiável

Mais conteúdo relacionado

Mais procurados

Semelhante a WBMA2013 - Método Ágil para desenvolvimento de software confiável

Mais de Alan Braz

WBMA2013 - Método Ágil para desenvolvimento de software confiável