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:

  1. O objetivo primário de um projeto de software é o próprio software, e não um grande conjunto de documentação sobre ele;
  2. 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

    1. AGILE ALLIANCE. Disponível em:
      <http://www.agilealiance.org/home>. Acesso em: 04 abr. 2003.

    2. AGILE ALLIANCE. Disponível em:
      <http://www.controlchaos.com>. Acesso em: 04 abr. 2003.

    3. AMBLER, S. W. Agile modeling (AM) site. Disponível em:
      <http://www.agilemodeling.com>. Acesso em: 04 abr. 2003.

    4. AMBLER, S. W.; JEFFRIES, R. Agile modeling: effective practices for extreme programming and the unified process. [S.l.]: John Wiley & Sons, 2002.

    5. AMBLER, S. W. The practices of agile modeling (AM). Disponível
      em: <http://www.agilemodeling.com/
      practices.htm
      >. Acesso em: 04 abr. 2003.

    6. BECK. K. et al. Manifesto for agile software development.
      Disponível em:
      <http://www.agilemanifesto.org> . Acesso em: 04 abr. 2003.

    7. HIGHSMITH, J. Disponível em:
      <http://www.adaptivesd.com>. Acesso em: 04 abr. 2003.

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

    9. RONIN INTERNATIONAL. Disponível em:
      <http://www.ambysoft.com/
      agilemodeling.html
      >. Acesso em: 04 abr. 2003.

    10. XPROGRAMMING.COM an extreme programming resource. Disponível em:
      <http://www.xprogramming.com>. Acesso em: 04 abr. 2003.