| Agile Modeling - Overview
Autores: Alexandre Denes dos Santos, Jefferson
Carlos Martins e Manoel Flávio Leal
Resumo
Este artigo apresenta o processo
de modelagem de software conhecido como Agile Modeling (AM), mostrando
suas características e seus princípios. Os prós e os contras desta metodologia
são abordados, auxiliando a identificação do tipo de projeto no qual este
processo poderá ser mais eficiente que os processos prescritivos tradicionais.
1.
Introdução
O processo atual de desenvolvimento de software
em vários lugares está em um nível de qualidade muito abaixo do que seria
considerado ideal, pois normalmente os sistemas são entregues aos clientes
fora do prazo estipulado no projeto preliminar e com um custo maior do que
o previsto; além disso, esses sistemas freqüentemente não alcançam a qualidade
desejada pelo cliente e, em muitos casos, não satisfazem as reais necessidades
dos mesmos, necessitando ser desenvolvidos de novo, e de novo, e de novo,
num processo conhecido por muitos profissionais como “isso terá de ficar
para uma próxima versão”. Uma das
propostas para minimizar esse problema é o Agile Modeling (AM), um processo
de desenvolvimento de software baseado em práticas que visa aumentar a
eficiência da equipe dentro de um projeto de desenvolvimento de software.
Ao contrário dos processos “tradicionais” como o sugerido pelo Unified
Process, por exemplo, que requer basicamente os mesmos artefatos para
todos os tipos de projetos, AM busca a construção e manutenção eficiente
de artefatos, criando-os apenas quando agregarem valor real ao projeto,
e focando principalmente os esforços no desenvolvimento do software que,
em última análise, é o objetivo principal do processo.
Deve-se notar, entretanto, que AM não é
uma metodologia de desenvolvimento ágil como eXtreme Programming (XP),
SCRUM, DSDM, etc., mas uma metodologia de modelagem ágil, isto é, AM visa
construir e manter modelos de sistemas de maneira eficaz e eficiente e,
portanto, pode ser utilizada dentro de metodologias ágeis como as citadas
há pouco, como também em metodologias prescritivas como o Unified Process.
2. Agile Modeling
Segundo
Scott W. Ambler, Agile Modeling (AM) é uma metodologia baseada na prática
para modelagem eficaz de software. AM é uma coleção de práticas, guiadas
por princípios e valores que podem ser aplicados por profissionais de
software no dia a dia. Não sendo um processo prescritivo, não define procedimentos
detalhados de como criar um dado tipo de modelo, em vez disso, provê conselhos
de como ser efetivo como modelador. Em resumo, AM busca o ponto de melhor
custo/benefício entre os artefatos que devem ser criados para o sistema
e o custo de manutenção e atualização desses artefatos.
Pode-se citar duas motivações principais para a criação desta metodologia:
- O objetivo primário de um projeto de software é o próprio software,
e não um grande conjunto de documentação sobre ele;
- Um artefato é criado primordialmente para permitir a comunicação e
a troca de informações entre a equipe (um modelo de classes é criado
para passar para a equipe a hierarquia imaginada pelo projetista, assim
como um diagrama de casos de uso é criado para a equipe ter uma visão
do mecanismo da funcionalidade envolvida) e permitir a discussão e refinamento
do modelo do sistema. Assim, se um artefato não está passando informação
relevante ao projeto, ele não cumpre seu objetivo básico.
Baseado
nessas constatações um grupo de pesquisadores (entre eles Grady Booch,
Martin Fowler e Alistair Cockburn) com suporte de algumas empresas (entre
elas Rational, TogetherSoft e Object Mentor), criaram a Agile Software
Development Alliance, onde foi definido um manifesto para o incentivo
às melhores maneiras de produção de software, definindo valores que devem
ser praticados para a obtenção de um processo mais interativo e menos
burocrático do que os atuais. Tais valores são:
Indivíduos
e interação em vez de processos e ferramentas: Infelizmente em muitas
empresas de desenvolvimento de software os analistas e gerentes de projeto
acabam se limitando em documentações e ferramentas de integração de seus
modelos e, com isso, acabam deixando de lado algo que é muito importante
em uma equipe, que é a cooperação de todos e os feedback dos colaboradores
envolvidos com o projeto.
Software
funcional em vez de extensa documentação: Em várias ocasiões é mais
útil um protótipo simples que mostre o funcionamento de uma arquitetura
do que um grande e complexo diagrama de classes; também é mais simples
para o cliente analisar o funcionamento do sistema através de um protótipo,
mesmo que não seja real, do que através de um conjunto de diagramas de
casos de usos e projetos de interface. Não se trata de abandonar o processo
de documentação, mas apenas de utilizar a ferramenta certa para transmitir
a informação desejada no momento.
Colaboração
com o cliente em vez de renegociação de contrato: Quem deve definir
o que o sistema deve ou não fazer é o cliente. Pode-se dizer que o cliente
não tem conhecimento suficiente para especificar o sistema, que o cliente
vive mudando de idéia sobre o que o sistema deve fazer, que o cliente
vive adicionando requisitos, etc., porém essa é
a
realidade do processo de desenvolvimento; em vez de tratar o cliente como
“aquele pessoal que só atrapalha”, deve-se realizar um trabalho de descoberta
das necessidades do cliente e educação do mesmo para o processo durante
a duração do projeto. É um caminho bastante árduo, porém tem se mostrado
muito gratificante para aqueles que o trilham.
Aceitação
das mudanças em vez de obediência cega a um plano: Mudanças fazem
parte da vida, especialmente na área de desenvolvimento de software; é
simplesmente contraproducente reclamar desse fato... Em vez disso, acostume-se
às mudanças; não estamos dizendo que não se deve ter um plano de projeto,
pelo contrário: o plano deve ser flexível o bastante para aceitar as mudanças
do ambiente aonde esse software deverá ser utilizado. De fato, um sistema
que atendia aos requisitos do usuário na fase de análise, porém não atende
mais esses requisitos quando posto em produção não configura exatamente
um sistema útil, não é mesmo?
3.
Definição de modelos ágeis
Um
modelo utilizando AM é simplesmente um modelo eficiente, o qual apresenta
as seguintes características:
Atende
o seu propósito: Um modelo tem por propósito comunicar alguma coisa
para a equipe. Se o modelo não traz informação adicional sobre o projeto,
então ele não está cumprindo o seu papel e não vale a pena pagar o custo
necessário para mantê-lo;
É
inteligível: Um modelo deve ser
inteligível, e não bonito. Isto significa que um modelo desenhado à mão
em uma folha de papel ou uma foto digital de um modelo desenhado em um
quadro branco pode comunicar a informação pretendida tão bem como o mesmo
modelo desenhado em uma ferramenta CASE da moda, com a vantagem de ser
muito mais fácil de ser construído;
É
suficientemente detalhado: Todo
modelo deve ser atualizado de acordo com a evolução do sistema. Se o modelo
for exageradamente detalhado, o custo de manter esse modelo atualizado
é maior devido à sua maior complexidade. O modelo deve ser suficientemente
detalhado para conseguir transmitir a informação desejada e manter o custo
de manutenção em um nível mínimo. Mais detalhe que esse ponto pode inserir
informação demais no modelo, o que gera uma complexidade desnecessária.
Esse detalhamento adicional normalmente pode ser colocado em um outro
modelo ou, preferencialmente, definido pelo próprio código do sistema.
4.
Definição de modelagem ágil
Deve-se
diferenciar o que são os modelos ágeis, descritos na seção anterior, do
processo de modelagem ágil. Também é importante estabelecer o escopo do
AM para esclarecer o que pode e o que não pode ser atendido por este processo:
AM
é um complemento aos processos existentes; não é uma metodologia completa:
AM foca em modelagem e, em segundo plano, documentação. AM pode ser utilizado
para aumentar a eficiência da modelagem e documentação, tanto em processos
prescritivos como o Unified Process quanto processos ágeis como o SCRUM;
AM
é não é uma bala de prata: AM
é uma técnica eficiente para a melhoria dos esforços de desenvolvimento
de software de muitos profissionais da área. AM não é uma espécie de óleo
mágico que resolverá todos os problemas, tampouco uma técnica que garantirá
melhores resultados. A idéia por trás de AM é a de que se você utilizar
seus esforços de modelagem de maneira mais racional e permanecer focado
no projeto, então provavelmente sua eficiência no desenvolvimento do projeto
irá aumentar;
AM
não visa a eliminação da documentação:
AM simplesmente diz que a documentação deve ser feita de modo mais racional,
maximizando o investimento do cliente no processo de desenvolvimento.
AM
não visa a eliminação de ferramentas CASE:
Pelo contrário: AM diz que a melhor ferramenta para criar um modelo é
a mais simples. Se um modelo for mais fácil de ser desenhado em uma ferramenta
CASE do que em um papel, então a ferramenta CASE deve ser utilizada para
a criação desse modelo.
5. AM na prática
A
implantação de AM dentro da cultura de desenvolvimento de software é uma
experiência tanto interessante quanto traumática, devido à grande mudança
de pensamento acarretada pelo método e também devido à inércia natural
das pessoas frente a mudanças.
Para
direcionar os esforços em torno de AM, existem alguns princípios que devem
ser observados para que o processo adotado seja realmente ágil. Dentre
esses princípios, os mais importantes são:
5.1
Princípios fundamentais ou centrais
Software
é seu principal objetivo: software que funcione.
Habilitar
seu próximo esforço é um objetivo secundário: pensar sempre nas
próximas funcionalidades.
Viaje
com pouca bagagem: menos documentos durante o projeto - escolher
documentos a serem mantidos durante o processo de desenvolvimento.
Assuma
Simplicidade.
Aceite
a Mudança.
Aplique
Mudanças Incrementais.
Modele
com um propósito: para atender a realidade, para melhorar a comunicação.
Construa
Múltiplos Modelos.
Trabalhe
com Qualidade.
Obtenha rápido
Feedback.
Maximize o investimento
do Stakeholder (pessoa chave que representa a empresa).
5.2 Princípios suplementares
Conteúdo
é mais importante que representação.
Cada
um tem algo a aprender com o outro.
Conheça
seus modelos.
Conheça
suas ferramentas.
Adapte
o modelo à organização.
Comunicação
aberta e honesta.
Atente
para os instintos da equipe: ouça as sugestões/reclamações de
sua equipe, pois talvez o problema que a equipe encontrou poderá dificultar
o restante da implementação.
6.
Práticas da AM
O
AM também possui dois tipos de práticas, as práticas centrais e as práticas
suplementares.
6.1 Práticas fundamentais ou centrais
Modelagem Iterativa e Incremental:
- Aplique o artefato correto;
- Crie vários modelos em paralelo;
- Itere entre diferentes artefatos;
- Modele em pequenos incrementos.
Trabalho
em Equipe:
- Modelar com outras pessoas;
- Participação ativa do Stakeholder;
-
Conhecimento coletivo (nunca deixe
somente uma pessoa dominar todo o
processo,
pois se a mesma morrer, acabou o projeto);
- Exiba modelos
publicamente (colocar em painéis, parede, etc.).
Simplicidade:
-
Crie conteúdo simples;
- Descreva modelos simples;
-
Use a ferramenta mais simples.
Validação:
Considere
a testabilidade;
Prove com código.
6.2
Práticas suplementares
Produtividade:
-
Utilize padrões e normas de
modelagem;
-
Aplique padrões (design patterns)
com sabedoria;
-
Reutilize recursos existentes.
Documentação:
-
Descarte Modelos temporários;
-
Formalize
os modelos de contrato “Contract Models”;
-
Atualize apenas quando dói (para que o modelo não fique
inconsistente).
Propósito:
-
Modele para entender;
-
Modele para comunicar.
Boas
Idéias:
-
Conheça bem suas ferramentas;
-
Refactoring;
-
Test-First
Design.
7.
Conclusão
O
AM é uma metodologia que tem o objetivo de facilitar e ao mesmo tempo
fazer com que o analista ganhe tempo no desenvolvimento. Para que não
existam confusões sobre o que é AM, tenha em mente os “statements” descritos
abaixo. Eles irão ajudá-lo na hora de identificar se o AM é a melhor solução
para o seu projeto ou não.
AM
é uma atitude, não um processo prescritivo;
AM é um
suplemento aos métodos existentes, ele não é uma metodologia completa;
AM é uma
forma efetiva de se trabalhar em conjunto para atingir as necessidades
dos patrocinadores no projeto;
AM é efetivo
e é sobre ser efetivo;
AM é uma
coisa que funciona na prática, não é teoria acadêmica.
AM não
é uma solução “salvadora”;
AM é para
o desenvolvedor médio, mas não é um substituto de pessoas competentes;
AM não
é um ataque à documentação, pelo contrário, AM aconselha a criação
de documentos que têm valor;
AM não
é um ataque às ferramentas CASE;
AM não
é para todos.
8. Referências
-
AGILE
ALLIANCE. Disponível em:
<http://www.agilealiance.org/home>.
Acesso em: 04 abr. 2003.
-
AGILE
ALLIANCE. Disponível em:
<http://www.controlchaos.com>.
Acesso em: 04 abr. 2003.
-
AMBLER,
S. W. Agile modeling (AM) site. Disponível em:
<http://www.agilemodeling.com>.
Acesso em: 04 abr. 2003.
-
AMBLER,
S. W.; JEFFRIES, R. Agile modeling: effective practices for
extreme programming and the unified process. [S.l.]: John Wiley &
Sons, 2002.
-
AMBLER,
S. W. The practices of agile modeling (AM). Disponível
em: <http://www.agilemodeling.com/
practices.htm>. Acesso em: 04 abr. 2003.
-
BECK.
K. et al. Manifesto for agile software development.
Disponível em:
<http://www.agilemanifesto.org>
. Acesso em: 04 abr. 2003.
-
HIGHSMITH,
J. Disponível em:
<http://www.adaptivesd.com>.
Acesso em: 04 abr. 2003.
-
POLETTO JR., J. Agile modeling - a terceira via do desenvolvimento de software. In: OD´2002, CONGRESSO E EXPOSIÇÃO INTERNACIONAL DE OBJETOS
DISTRIBUÍDOS, 7., 2002, São Paulo.Anais... São Paulo, 2002.
-
RONIN
INTERNATIONAL. Disponível em:
<http://www.ambysoft.com/
agilemodeling.html>. Acesso em: 04 abr. 2003.
-
XPROGRAMMING.COM
an extreme programming resource. Disponível
em:
<http://www.xprogramming.com>.
Acesso em: 04 abr. 2003.
denes@ppgia.pucpr.br
jeffcm@celepar.gov.br
mfleal@celepar.gov.br
|
maio
2003 # 131
