Universidade Federal de Santa Catarina Centro Tecnológico Disciplina: Projetos I Aluno: Diogo Ludvig 0313812-7 Resumo artigo Agile Modeling- Overview Este trabalho se refere ao resumo do artigo Agile Modeling, de Alexandre Denes dos Santos, Jefferson Carlos Martins e Manoel Flávio Leal. O artigo encontrasse na edição 131 de maio de 2003 da revista BateByte. 1. Introdução O processo atual de desenvolvimento de software se encontra muito precário, pois normalmente os sistemas são entregues aos clientes fora do prazo e com um custo maior do que o previsto. E, além disso, mesmo tendo custos mais altos e prazos prolongados estes sistemas não conseguem atingir um nível de qualidade que o cliente deseja. Por estes motivos os sistemas têm que ser desenvolvidos de novo, e de novo, caindo no processo conhecido como isso terá que ficar para uma próxima versão. E uma das propostas para solucionar este problema é o AM - Agile Modeling, que visa aumentar a eficácia da equipe de um projeto de desenvolvimento de software. Diferentemente de metodologias como a sugerida pelo Unified Process que requer basicamente todos os artefatos para qualquer tipo de projeto de desenvolvimento, o AM busca uma construção flexível buscando utilizar artefatos somente quando se faz realmente preciso. Devemos nos atentar que a AM não é uma metodologia de desenvolvimento ágil como XP - extreme Programming ou SCRUM, mas sim uma metodologia de modelagem ágil, ou seja, pode ser utilizada dentro de metodologias ágeis mas também em metodologias prescritivas como o Unified Process. 2. Agile Modeling AM é uma coleção de práticas com princípios e valores que podem ser aplicados por profissionais de software no dia a dia, segundo Scott W. Ambler. AM não define procedimentos detalhados de como criar um modelo e sim dá orientações de como o modelador poderá ser mais efetivo. Podemos citar duas motivações principais para a criação desta metodologia:
1. O objeto principal de um projeto de software é o próprio software e não um grande conjunto de documentação sobre ele; 2. Um artefato é feito para permitir a comunicação e a troca de informações entre a equipe e permitir a discussão e refinamento do modelo. Então, se um artefato não esta passando informação útil ao projeto, ele não cumpre seu objetivo. Em cima destas constatações um grupo de pesquisadores com suporte de algumas empresas criaram a Agile Software Development Alliance, onde foi definido um manifesto para o incentivo ás melhores práticas de produção de software, definindo alguns valores: - Indivíduos e interação em vez de processos e ferramentas; - Software funcional em vez de extensa documentação; - Colaboração com o cliente em vez de renegociação de contrato; - Aceitação das mudanças em vez de obediência cega a um plano; 3. Definição de modelos ágeis Um modelo que utiliza AM é simplesmente um modelo eficiente, e podemos apresentar algumas características relevantes: - Atende o seu propósito; - É inteligível; - É suficientemente detalhado. 4. Definição de modelagem ágil AM é um complemento aos processos existentes, não é uma metodologia completa. AM foca em modelagem e em segundo plano documentação. Em resumo, a modelagem ágil é flexível o suficiente para deixar aberto, por exemplo, a necessidade da utilização de ferramentas cases ou não, se a ferramenta case por deixar o processo mais simples e eficiente então que seja usada. 5. AM na prática Os capítulos a seguir foram retirados do artigo original, visto que se trata de partes já bem resumidas e com várias citações e tópicos.
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.