1. INTRODUÇÃO
Um modelo é uma abstração que descreve um ou mais aspectos de um problema, ou uma solução potencial para esse problema [2].
A modelagem ágil é uma metodologia baseada em práticas para a modelagem e documentação de sistemas de software. É composta por um conjunto de valores, princípios e práticas para a modelagem de software que pode ser aplicado num projeto de desenvolvimento de software de um modo mais flexível em relação aos métodos tradicionais de modelagem. O desenvolvimento ágil de software usa desenvolvimento iterativo como base, mas defende um ponto de vista mais centrado nas pessoas do que nas abordagens tradicionais. Ao invés de planejamento, utiliza processos de feedback como mecanismo de controle primário. Este feedback é guiado por testes regulares de versões do software que está sendo desenvolvido.
Agile Model Driven Development (AMDD), conforme está implícito no próprio nome, é a versão ágil do Model Driven Development (MDD). MDD é uma abordagem de desenvolvimento de software onde modelos abrangentes são criados antes que o código fonte seja escrito. Um exemplo de MDD é o padrão OMG MDA (Object Management Group’s Model Driven Architecture. Com o MDD uma abordagem serial normalmente é utilizada, sendo que ele é bastante popular. A diferença para o AMDD é que, ao invés de criar modelos abrangentes antes da escrita do código fonte, se criam modelos ágeis que são suficientemente bons para guiarem os esforços de desenvolvimento [1].
A figura 1 ilustra o ciclo de vida do AMDD.
Para a primeira versão de um sistema, é necessário levar vários dias para identificar alguns requisitos de alto nível, bem como o escopo da versão (o que se acha que o sistema deve fazer). Para o modelo de requisitos iniciais é necessário algum tipo de modelo de uso para explorar como os usuários irão utilizar o seu sistema, um modelo de domínio inicial que identifica os tipos entidade de negócio e as relações entre o modelo inicial de interface de usuário que explora UI e problemas de usabilidade. O objetivo é construir um entendimento compartilhado, então não é necessário escrever documentação detalhada. Um fator crítico de sucesso é a utilização de técnicas de modelagem que permitam a participação dos interessados.
O objetivo do modelo arquitetural é tentar identificar uma arquitetura que tenha uma boa chance de funcionar corretamente. Nas próximas versões é possível definir iterações 0 menores, para alguns dias, horas, ou mesmo removê-la completamente. O segredo é manter as coisas simples. Não é necessário um modelo com muitos detalhes, é necessário somente que o modelo seja suficiente. O desenvolvimento de software ágil não é serial, é iterativo e incremental, evolucionário. Com uma abordagem evolucionária, a modelagem do modelo é feita no momento em que é necessária (just in time), durante as iterações de desenvolvimento e sessões de discussão do modelo.
No que diz respeito às iterações do modelo, no início de cada iteração de construção, a equipe deve planejar o trabalho que será feito naquela iteração. Times ágeis implementam requisitos por ordem de prioridade. Para isso poder ser feito com sucesso, a equipe deve ser capaz de estimar exatamente o trabalho necessário para cada requisito, e então com base em seu conhecimento das iterações anteriores, estimar o esforço que será necessário para a iteração corrente, conforme ilustra a figura 2 [1].
Figura 2. Processo de gerenciamento de mudança de requisitos ágeis.
O AMDD funciona por diversas razões:
- Atende as necessidades de planejamento de projeto, pois através da identificação dos requisitos (em alto nível), e através da identificação de uma arquitetura na primeira fase, se tem informações suficientes para uma estimativa inicial de custo e de tempo.
- Riscos técnicos são gerenciáveis, pois os esforços iniciais de modelagem arquiteturais permitem que sejam identificadas áreas de maior risco técnico.
- Minimização de perdas, pois uma abordagem just in time permite focar somente em aspectos do sistema que irão ser construídos (e não em aspectos do modelo que não tem muita importância para o usuário).
- Melhores questões são levantadas, pois quanto mais se discute o requisito de um modelo, mais conhecimento do domínio se adquire.
- Usuários dão melhores respostas, pois estes também têm um melhor conhecimento do sistema que está sendo construído, porque lhes é entregue regularmente pacotes de software, e dessa forma ele está habilitado a fornecer feedbacks concretos.
2. TRABALHOS RELACIONADOS
2.1. Trabalho 1
O objetivo do trabalho [3] é investigar se, e como, alguns princípios e práticas ágeis podem ser aplicadas no desenvolvimento de jogos. Esta pesquisa pode ajudar a desmistificar a impressão de que a adoção de práticas ágeis para o desenvolvimento de jogos é um processo difícil.
Foi possível identificar um ciclo comum de desenvolvimento em diferentes times: o modelo em cascata, que foi adaptado para a produção de jogos. Dois estágios deste modelo podem ser salientados: a definição das regras do jogo e a produção da documentação do projeto [3].
As regras do jogo determinam o comportamento e interação entre os personagens e o ambiente, e podem ser vistos como requisitos. O projeto de um jogo envolve nada mais do que a criação de um conjunto de regras, geralmente através de um processo informal, que envolve a equipe de desenvolvimento.
A documentação do projeto é a principal (e única) documentação do jogo. Seu objetivo é descrever e detalhar os mecanismos do jogo (o que cada jogador é capaz de fazer dentro do ambiente do jogo, e como isso pode levá-lo a uma experiência satisfatória). Também contêm os componentes principais da história e a descrição dos cenários do jogo e das ações dos jogadores. Muitos desenvolvedores a utilizam como especificação funcional, servindo como base para o design arquitetural [3].
Uma evidência de boa prática adotada por times de desenvolvimento de jogos é a análise de post-mortem, que visa coletar dados relevantes para generalizar os resultados, e aprender com os erros e casos de sucesso, permitindo um reuso futuro deste conhecimento. Outras boas práticas já adotadas pelos times de desenvolvimento de jogos puderam ser identificas, e estas já estão em conformidade com práticas ágeis pertencentes ao Scrum, XP e Modelagem Ágil. Estas práticas tem sido adotadas pelas equipes de maneira instintiva.
2.2. Trabalho 2
O trabalho [4] apresenta um mecanismo de extensão de um modelo de dados, onde um modelo de dados básico é estendido, ao se adicionar atributos e classes que satisfaçam os requisitos específicos de cada camada do sistema.
Grandes sistemas de dados são caracterizados por manipular e exibir grandes quantidades de dados estruturados. Esses dados são salvos em algum sistema de armazenamento persistente, como um banco de dados ou um arquivo. Tais sistemas de dados são geralmente projetados em três camadas: camada de apresentação, domínio (ou função de negócio) e camada de origem de dados [4]. A informação contida na origem de dados é acessada através da camada de origem de dados. Essa camada transfere os dados contidos em estruturas de dados persistentes, tais como as tabelas de um banco de dados, em estruturas de dados dinâmicas, tais como arrays ou objetos. As funções de transferência podem ser codificadas manualmente ou serem geradas através de um modelo de dados dos dados persistentes [4].
Os problemas a serem resolvidos para estes sistemas de dados são complexos, por isso funções de transferência codificadas manualmente podem levar facilmente a erros lógicos. Para se reduzir a complexidade deste problema, deve-se olhar através de um ponto de vista abstrato, ignorando-se os detalhes da linguagem de programação. Essa abstração pode ser disponibilizada por um modelo independente de plataforma, que é criado durante o processo de MDD (Model Driven Development). Enquanto o MDD tenta capturar todos os aspectos de um programa utilizando diferentes variantes de modelagem (como diagramas de atividades, ou de classe), AMDD (Agile Model Driven Development) tem seu foco no aspecto do modelo necessário atualmente. No desenvolvimento deste tipo de sistema, um dos primeiros aspectos a serem modelados para cada camada é a estrutura de dados.
MDD é uma abordagem para implementar um sistema de software descrevendo-o num Modelo Independente de Plataforma (PIM). Esse modelo define associações entre os dados e o comportamento do software, e é usado como entrada para os geradores produzirem um Modelo Específico de Plataforma (PSM). Para suportar o MDD, o OGM liberou a MDA, que contêm padrões que permitem a especificação e transformação dos modelos [4]. Outra abordagem dominante ao MDD é o Software Factories, que é proposto pela Microsoft e pode ser visto como um novo paradigma de desenvolvimento de software.
Os modelos de projeto de software são geralmente especificados utilizando a Linguagem de Modelagem Unificada (UML), que é um outro padrão do OMG. A modelagem de dados ágil conta com a construção iterativa de modelos de dados, onde cada modelo satisfaz os requisitos necessários para a iteração corrente. É melhor adequado para aplicações, que contam com banco de dados relacionais para armazenamento de dados persistentes. AMDD também usa uma abordagem iterativa, ao invés de modelos extensivos gerados no processo MDD normal [4].
Este trabalho introduziu um novo método para facilitar a construção dirigida à modelos de software com camadas de dados intensivos. Aplicar os conceitos de modelagem de dados usando conceitos tradicionais resulta em um modelo para cada camada de software, o que leva à definição de classes redundantes em diferentes modelos com relação à origem de dados. Alterar o modelo de dados implica em alterar todas as classes em outros modelos de dados, sendo que cada modelo é guiado por vários requisitos, que levam à um número diferente de atributos nas classes equivalentes dependentes do modelo de dados. O trabalho apresentou o mecanismo para aplicação das mudanças do modelo, que é chamado de Transient Model Extension (TME), e também os casos de uso deste modelo, que incluem a extensão de classes, seus atributos e associações. Essas extensões transitórias são guiadas pelos requisitos específicos da camada. Ao final os autores fizeram uma comparação da abordagem utilizando tecnologias relacionadas para lidar com estruturas de dados persistentes.
2.3. Trabalho 3
O trabalho [5] relata o uso de AMDD para o desenvolvimento de aplicações de workflow baseadas na web. O AMDD permite que os desenvolvedores possam gerar e liberar as aplicações esperadas dentro de um curto espaço de tempo, enquanto os usuários finais possam gerenciar a evolução de suas aplicações de workflow em um ambiente controlado através de ferramentas também baseadas na web.
O desenvolvimento de aplicações web é feito sob pressão dos negócios que se desenvolvem, em curtos períodos de tempo e com recursos limitados. Essa dinâmica exige uma abordagem diferente e radical para que requisitos de negócio sejam transformados em artefatos de software. Na prática, é difícil de se capturar com precisão todos os processos de negócio necessários, os objetos de negócio, bem como a especificação da interface do usuário durante a fase de coleta e análise de requisitos de um projeto. Também pode ser comum a mudança dos requisitos antes deles terem sido implementados ou re-implementados. Um fator responsável por isso é a incerteza dos usuários, ou falta de entendimento daquilo que eles necessitam enquanto não puderem visualizar uma representação de software concreta, já implementada. Daí a importância em reduzir o tempo necessário para transformar requisitos de negócio em artefatos de software, ao se desenvolver aplicações web. AMDD tira vantagem tanto dos princípios de MDD (acelerar o processo de transformação de requisitos, na forma de modelos conceituais em implementações de software), quanto de técnicas ágeis (que permitem a criação somente das partes necessárias do modelo, deixando assim que mudem ao longo do projeto).
A proposta dos autores se baseia na combinação do AMDD com o desenvolvimento para o usuário final, que permite a criação de aplicações baseadas na web. Foi demonstrado a arquitetura da aplicação web, que suporta tal abordagem combinada, através do uso de SBO e LBPF. A modelagem com SOB é leve e altamente customizável, permitindo assim a rápida construção dos objetos de negócio. Ao mesmo tempo, os usuários podem usar ferramentas com as quais já estão habituados, tais como planilhas e diagramas gráficos baseados na web, para a definição dos processos de negócio, revisão e remoção. Os autores puderam desenvolver com sucesso uma aplicação web para a Universidade de Western Sydney, que faz uso de pesados workflows que executam em paralelo e fazem sincronização em diversos pontos. As interfaces web foram geradas com SOB e todo o modelo de dados foi modelado usando SBOML [5].
2.4. Trabalho 4
O trabalho [6] descreve uma maneira de formalizar informações clínicas de pacientes em sistemas informatizados. Na abordagem utilizada, os requisitos e as interações de vários atores são consideradas para se formalizar tais informações de modo que estas sejam interpretáveis por uma representação computacional, usando-se uma maneira semi-automatizada baseada em técnicas de processamento da linguagem natural. Os papéis dos usuários foram analisados para a construção do modelo, que foi implementado através de protótipos para mostrar sua utilidade aos diversos usuários [6].
Devido à natureza dos dados, o processo de formalização requer colaboração intensiva e contínua entre os engenheiros e a equipe médica. Também se precisa de um sistema que possa facilmente integrar a percepção vinda de qualquer envolvido no processo e permitir que se avalie cada passo. Para o desenvolvimento de um sistema, os autores tiraram a inspiração nos conceitos envolvidos com AMDD.
Os autores estudaram o ciclo de vida do processo, para identificar o que são fases, quais são os atores e as conseqüentes interações, e quais delas se sobrepõem. As fases do ciclo de vida consideradas são [6]:
- Desenvolvimento: neste estágio os conhecimentos médicos são construídos.
- Publicação e Disseminação: o conhecimento médico tem de ser publicado, iniciando o difícil caminho de disseminação.
- Formalização: os engenheiros transformam o texto em narrativa do conhecimento médico numa versão interpretável pelo computador.
- Implementação e Aplicação: o conhecimento é introduzido no ambiente e implementado com base na versão formalizada durante a atividade diária.
Já os atores envolvidos são:
- Desenvolvedores do conhecimento médico: responsáveis pelo conteúdo do conhecimento médico (na fase de desenvolvimento), assim como pela sua publicação e disseminação.
- Pessoal da área da saúde: profissionais com diferentes perfis que se enquadram nessa categoria. Devido à complexidade, os autores decidiram considerar principalmente os médicos (sem sub-estimar os outros grupos).
- Engenheiros do conhecimento: cientistas da computação que formalizam o conhecimento.
Outros refinamentos no modelo desenvolvido pelos autores foram feitos, permitindo que um editor de informações fosse gerado. Este permite também a exportação dos dados para posterior disseminação no meio onde é usado.
2.5. Trabalho 5
O trabalho [7] propõe um framework para arquiteturas ágeis, onde os requisitos empresariais possam ser planejados através do uso de métodos ágeis e suas práticas, para proporcionar um retorno o mais breve possível. Através do uso deste framework, o risco do projeto pode ser reduzido, e também a cooperação entre a equipe de arquitetura e do desenvolvimento do projeto ser garantida. Reuniões entre os envolvidos, em conjunto com a definição das últimas aceitações guiam ao sucesso do framework. Um dos outros benefícios do framework é o uso de um repositório para manter informações, pesquisas, ajuste de modelos e uso de métodos ágeis durante todos as fases do framework, para que este seja melhor, mais rápido e mais barato do que a prática clássica [7].
A arquitetura empresarial consiste em várias estruturas e processos de uma organização. Para completar essa definição, um modelo arquitetural é uma representação destas estruturas e processos. Um bom modelo arquitetural retrata a organização como ela é hoje e prevê seu futuro. Muitas vezes os modelos arquiteturais da organização são uma ponte de comunicação entre os detentores de negócio e os profissionais de TI. Entretanto, na indústria de TI, esta terminologia não é usada assim. O termo arquitetura empresarial se refere ao grupo de pessoas responsáveis por modelar e documentar a arquitetura. O framework da arquitetura empresarial é como um padrão que é útil para se pensar e se explorar vários aspectos de uma empresa, que normalmente consiste de modelos, diagramas e produtos definidos para um projeto [7].
Este framework pode resolver a deficiência e problemas da prática clássica, e também ajudar a empresa a atingir suas metas mais rapidamente porque possui padrões técnicos combinados, portanto, é basicamente ágil. Ele consiste em 7 modelos e 11 interações entre eles. Estes modelos e interações são feitos de princípios e valores ágeis, e ele cobre diferentes pontos de vista e aspectos do projeto e da empresa. Os pontos de vista são: planejador, proprietário, designer, construtor, e programador. Os aspectos do projeto são: dados, funções, rede, pessoas, tempo, e motivação [7].
O framework é executado de modo que possa mudar a supervisão dos detentores de negócio para um modo cooperativo. O projeto é visto de maneira mais entusiástica por toda a equipe, fazendo com que o mesmo seja suportado como um todo, reduzindo o risco do seu planejamento, sem contar com as interações simultâneas que facilitam seu desenvolvimento, e que guiam sua execução e conclusão com sucesso.
3. CONCLUSÕES
Métodos ágeis podem ser aplicados ao desenvolvimento de praticamente qualquer sistema de software atualmente. Suas principais vantagens são o uso de ciclos de desenvolvimento menores, onde a equipe mantém uma constante comunicação, que acaba facilitando um melhor entendimento dos requisitos. Além disso, os requisitos podem mudar com maior freqüência, sem que a equipe perca isso de vista. Com esta dinâmica, só é feito o que realmente importa, para cada entrega ao final de cada ciclo, permitindo que a equipe foque esforços somente naquilo que é necessário. O usuário acaba recebendo um produto palpável, que ele pode utilizar e verificar se realmente está atendendo às suas necessidades, além de poder dar feedbacks à equipe enquanto esta está desenvolvendo o produto.
REFERÊNCIAS
[1] D. Leflingwell. "Agile Software Requirements".
[2] S. W. Ambler. "Agile Model Driven Development (AMDD)". XOOTIC Magazine, February, 2007.
[3] F. Petrillo and M. Pimenta. "Is Agility out there? Agile Practices in Game Development". SIGDOC 2010, S. Carlos, SP,
[4] M. Thonhauser; G. Schmoelzer; C. Kreiner. "Model-based Data Processing with Transient Model Extensions". 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS), 2007.
[5] X. Liang;
[6] P. Martini; K. Kaiser; S. Miksch. "Easing the Formalization of Clinical Guidelines with a User-tailored, Extensible Agile Model Driven Development (AMDD)". 21st IEEE International Symposium on Computer-Based Medical Systems, 2008.
[7] B. D. Rouhani; H. Shirazi; A. F. Nezhad; S. Kharazmi. "Presenting a Framework for Agile Enterprise Architecture". Proceedings of the 2008 1st International Conference on Information Technology, 2008.
Nenhum comentário:
Postar um comentário