Modelagem em Desenvolvimento Ágil de Software: uma revisão da literatura

Transcrição

1 Modelagem em Desenvolvimento Ágil de Software: uma revisão da literatura Fernando Mognon 1 Orientador: Paulo C. Stadzisz 1 1 Departamento Acadêmico de Informática - Programa de Pós-Graduação em Computação Aplicada Universidade Tecnológica Federal do Paraná (UTFPR) Curitiba PR Brasil fmognon@alunos.utfpr.edu.br, stadzisz@utfpr.edu.br Abstract. Agile methods have been used for over than a decade. But there are limitations as the agile methods are used in complex, large scale projects and in distributed teams. Traditional software design technics, like modeling, could help overcome these limitations. This paper aims to identify the modeling aspects of agile software development, presenting the state-of-art in this area. The results show that modeling is used in agile methods, throughout the project, especially in the first sprints. The modeling languages used are UML, informal diagrams, CRC cards and textual language. There are attempts of using agile with formal methods and also model-driven development, without consistent results of the effectiveness of these proposals. Finally, we conclude that the literature lacks experiments on modeling in projects using agile methods. Resumo. Métodos ágeis vem sendo cada vez mais utilizados em desenvolvimento de software. Porém, verificam-se limitações à medida que o uso dos métodos ágeis avançam para projetos maiores, de grande complexidade e em equipes distribuídas. As técnicas tradicionais de projeto de software, como a modelagem, poderiam ajudar a superar estas limitações. Este artigo tem como objetivo identificar os aspectos relacionados a modelagem em projetos de desenvolvimento de software que utilizam métodos ágeis, apresentando o estado da arte neste tópico. Os resultados mostram que a modelagem é utilizada nos métodos ágeis, ao longo de todo o projeto com maior intensidade nas primeiras iterações. As linguagens de modelagem utilizadas são a UML, diagramas informais, cartões CRC e linguagem textual. Há uma tentativa de aderência aos métodos formais, além do uso de desenvolvimento orientado a modelos em conjunto com os métodos ágeis, sem uma comprovação mais abrangente da efetividade destas propostas. Por fim, concluímos que faltam na literatura experimentos sobre modelagem realizados em projetos que utilizam métodos ágeis.

2 Sumário 1 Introdução Contexto Motivação Justificativa Objeto de Estudo Objetivos Geral e Específicos 4 2 Revisão Teórica Métodos ágeis Scrum XP Modelagem Ágil 10 3 Método de Pesquisa 11 4 Resultados Estudos Comparativos e Revisões Anteriores sobre Modelagem Ágil Propostas de Integração de Processos e Modelagem Aspectos Práticos sobre Modelagem Modelagem de Arquitetura e Requisitos em Métodos Ágeis Métodos formais e métodos ágeis Desenvolvimento orientado a modelos 21 5 Discussões Instrumentos de Projeto de Software em Métodos Ágeis Visões de Modelagem nos Métodos Ágeis Linguagens de Modelagem em Métodos ágeis Momentos em que a modelagem é realizada no desenvolvimento ágil de software Critérios de avaliação do uso de Modelagem em Métodos Ágeis Definição e Comunicação da Arquitetura em Métodos Ágeis 23 6 Conclusão Limitações deste estudo Trabalhos futuros 25 7 Referências 25 8 Apêndices Artigos incluídos na revisão sistemática Cronograma de elaboração do artigo para disciplina metodologia de pesquisa Cronograma de Disciplinas do Mestrado Cronograma do Projeto de Pesquisa do Mestrado 31 2

3 1 Introdução Métodos ágeis vem sendo cada vez mais utilizados em desenvolvimento de software por empresas de todos os portes (Chuang et al., 2014) (Dybå & Dingsøyr, 2008) (Misra, 2012). Algumas das principais motivações para a criação do Manifesto Ágil por (Beck et al.,2001) foi contrapor o grande foco dado aos processos nas abordagens tradicionais. Em alguns destes métodos a codificação pode ocorrer efetivamente somente após a modelagem exaustiva do sistema. A modelagem é um instrumento que auxilia o processo de concepção de um produto, permitindo materializar as ideias abstratas e conceituais durante a atividade intelectual e criativa de invenção de uma solução para um sistema. Desta maneira, a modelagem tem um papel importante para auxiliar o raciocínio de desenvolvimento do projeto. Seus artefatos auxiliam na manutenção dos sistemas e na comunicação entre os envolvidos, principalmente em projetos de grande tamanho e complexidade, ou com equipes distribuídas (Hadar et al., 2013), (Cherubini et al., 2007). 1.1 Contexto Empresas com processos bem definidas veem os métodos ágeis como limitados, por outro lado praticantes da metodologia ágil veem a modelagem como pouco valor para o cliente, e pouco útil quando feito anteriormente ao início do desenvolvimento efetivo do projeto (Abrahamsson et al., 2010). Há também a percepção que programadores não gostam de fazer modelagem e documentação (Selic, 2009). Assim, se os desenvolvedores ágeis não perceberem a importância da modelagem, eles não vão usá-la, nem seus artefatos (Abrahamsson et al., 2010). Parece consenso que o uso deste arcabouço com muita antecipação antes do início do desenvolvimento efetivo do software pode levar a decisões equivocadas. Também parece prudente avaliar que a modelagem deve ser de acordo com o contexto: projetos grandes e complexos necessitam de um esforço de modelagem maior. Apesar da arquitetura evoluir iterativamente, decisões de maior dificuldade de mudança e mais permanentes devem ser tomada nas primeiras iterações (Abrahamsson et al., 2010). 1.2 Motivação Com o amadurecimento dos métodos ágeis, foram realizados vários estudos empíricos para identificar as teorias por trás destas práticas (Dybå & Dingsøyr, 2008). O papel da arquitetura foi apontando, entre outros fatores, com uma das principais lacunas nos estudos desenvolvidos em métodos ágeis (Dingsøyr et al., 2012). Os profissionais da área também clamam por mais informações sobre como aplicar os métodos ágeis em projetos com equipes distribuídas e grandes projetos, onde o uso de instrumentos como a modelagem podem facilitar a comunicação e criação do software (Freudenberg & Sharp, 2010). Verificam-se muitas controvérsias quanto ao papel da modelagem, arquitetura e documentação em desenvolvimento de software ágil, especialmente, à medida que o uso dos métodos ágeis avançam para projetos maiores, de grande complexidade e em equipes distribuídas. 3

4 1.3 Justificativa Desta maneira, justifica-se pesquisar a utilização de instrumentos de projeto de software, em especial a modelagem e a busca pela agilidade no desenvolvimento de projetos de software que melhorariam a qualidade e robustez das soluções, facilitariam a manutenção dos sistemas, a comunicação entre os envolvidos no projeto e no raciocínio que levaram a tomar as decisões para determinado projeto. 1.4 Objeto de Estudo O objeto de estudo deste artigo é a modelagem no contexto de desenvolvimento ágil de software. 1.5 Objetivos Geral e Específicos O objetivo geral deste trabalho é identificar como a modelagem é vista e empregada nos métodos ágeis. Os objetivos específicos são: 1. Identificar os instrumentos de projeto de software que são utilizados em métodos ágeis; 2. Identificar quais as linguagens de modelagem que são utilizadas em métodos ágeis; 3. Identificar as diversas visões de modelagem utilizadas em conjunto com métodos ágeis; 4. Identificar as lacunas e possíveis trabalhos futuros; 2 Revisão Teórica Nas sessões seguintes são apresentados alguns conceitos sobre métodos ágeis, alguns dos métodos ágeis mais utilizados, segundo os estudos científicos, além de uma apresentação dos valores, princípios e técnicas da modelagem ágil. 2.1 Métodos ágeis Os métodos ágeis ganharam esta nomenclatura após a criação do manifesto para desenvolvimento ágil de software em Neste ano, vários profissionais da área de desenvolvimento de software uniram 4 valores e 11 princípios em um manifesto, propondo ser uma alternativa, para o que eles afirmavam ser, os processos de desenvolvimento guiados por documentação e pesos-pesados (Beck et al., 2001). Os quatro valores dos métodos ágeis são: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente 4

5 Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano 1 Segundo os autores, seria necessário valorizar mais os itens à esquerda, por mais que os itens da direita também tivessem seu valor (Beck et al., 2001). Um processo de desenvolvimento de software pode ser caracterizado como ágil se ele é incremental, cooperativo, descomplicado e adaptativo. Incremental significa que o processo faz entregas frequentes de software. Cooperativo indica que há interação frequente com os envolvidos no projeto. Os envolvidos no projeto incluem, entre outros, clientes e desenvolvedores. Descomplicado implica em um processo fácil de aprender e de adaptar. Adaptativo indica que há a possibilidade de atender às mudanças, mesmo as de última hora (Abrahamsson et al., 2003). A Tabela 1 apresenta uma breve descrição dos principais métodos ágeis e suas referências: Tabela 1. Descrição dos métodos ágeis mais importantes e suas principais referências Método Descrição Referência Crystal Dynamic Software Development Method (DSDM) Featuredriven development (FDD) Lean Software Development Família de métodos para times instalados na mesma localidade, com diferentes tamanhos e níveis de criticidade. O método que melhor representa os conceitos de agilidade é o Crystal Clear, que foca na comunicação em times pequenos e é aplicado ao desenvolvimento de software que não é crítico. O Crystal Clear tem sete características: entregas frequentes, melhorias contínuas, fácil comunicação, segurança pessoal, foco, fácil acesso aos especialistas e um ambiente técnico que cumpra alguns requisitos: testes automatizados, integração frequente e gerenciamento de configuração. Processo que pondera que o planejamento irá mudar assim que o desenvolvimento acontecer. É baseado em 9 princípios: envolvimento do usuário, desenvolvimento iterativo e incremental, ambiente que permita reverter as mudanças, escopo limitado antes do início do projeto, testes durante todo o processo e comunicação eficiente e eficaz. É um método baseado em model-driven development. É realizado um modelo inicial do sistema e divisão do trabalho em funcionalidades. O projeto e implementação para cada funcionalidade é realizado em iterações posteriores. Uma adaptação dos princípios da produção enxuta do sistema de desenvolvimento de software da Toyota. Consiste de sete princípios: eliminar desperdício, ampliar a aprendizagem, decidir o mais tarde possível, entregar o mais rápido possível, empoderamento do time, integridade da produção e visão do todo. (Cockburn, 2004) (Stapleton, 2003) (Palmer & Felsing, 2002) (Poppendieck & Poppendieck, 2003) 1 (Beck et al 2001) 5

6 Scrum Extreme programming (XP) Foco em gerenciamento de projetos em situações onde é difícil fazer um planejamento completo com antecedência. Iterações frequentes com ações de reação de acordo com os resultados obtidos constituem o elemento núcleo deste processo. O software é desenvolvido por times auto-gerenciados em ciclos chamados sprints, iniciando com um planejamento e terminando com uma revisão. As funcionalidades a serem implementadas no sistema são registradas em um estoque de atividades, chamado de backlog. Um representante do cliente, o chamado Product Owner decide quais funcionalidades devem entrar em cada sprint. O time coordena o trabalho em reuniões diárias, que devem ser curtas. Para ajudar neste propósito, são realizadas com os participantes em pé, a chamada stand-up meeting. Um dos membros do time, chamado de scrum master é o responsável por remover os impedimentos do time. Consiste em boas práticas para o desenvolvimento de software. São elas: jogo de planejamento, pequenas entregas, metáforas, projeto simples, testes constantes, refatoração, programação pareada, propriedade coletiva, integração contínua, semana de 40 horas de trabalho, clientes dentro da empresa e padrões de codificação. Fonte: adaptado de Dybå & Dingsøyr, 2008 (Schwaber & Beedle, 2001) (Beck, 2004) A Figura 1 apresenta a relação e evolução dos métodos de desenvolvimento ágil de software até As linhas pontilhadas indicam os principais métodos e seus criadores que contribuíram com a publicação do manifesto ágil. A origem principal dos métodos ágeis são os métodos de prototipação, o modelo em espiral e o evolucionário (Abrahamsson et al., 2003) Abordagens Orientada a objetos UML Ciclo de Vida Evolucionário (Gilb, 1988) RADical (Bayer & Highsmith, 1994 Crystal (Cockburn, 1998) Método por Prototipação (e.g., Lantz, 1986) Desenvolvimento Rápido de Aplicação (RAD) (e.g.,martin, 1991) DSDM (DSDM, 1995) Modelo Espiral (Boehm, 1986) Jogo de Desenvolvimento de Novos Produtos (Takeuchi & Nonaka, 1986) XP (Beck, 1999) Scrum (Schwaber, 1995), (Schwaber & Beedle, Processo Unificado Rational (RUP) (Kruchten, 2000) FDD (Palmer & Felsing, 2002) Desenvolvimento de Software Adaptativo (Highsmith, 2000) Modelagem Ágil (Ambler, 2002) Figura 1. Evolução dos métodos ágeis até 2002 Manifesto Ágil (Beck et al, 2001) Fonte: Adaptado de Abrahamsson et al.,

7 A Figura 1 apresenta o paradigma orientado a objetos e a linguagem unificada de modelagem (UML Unified Modeling Language). Influenciados por estas tecnologias foram criados os processos Crystal e o desenvolvimento orientado a funcionalidades (FDD Feature Driven Development). Paralelamente o processo unificado Rational (RUP Rational Unified Process) foi desenvolvido (Abrahamsson et al., 2003). Após a divulgação do manifesto ágil, foi publicado um conjunto de valores, princípios e práticas de modelagem de software adaptadas a nova proposta de desenvolvimento ágil, que foi chamado de modelagem ágil (AM Agile Modeling). Influenciado diretamente pela UML, RUP e XP (Ambler, 2002). Percebe-se a grande diversidade de métodos, porém, além dos métodos ágeis em geral, Scrum e XP são os métodos ágeis que mais apresentam estudos de caso (Chuang et al., 2014), (Melo et al., 2013), (Chow & Cao 2008) e (Dybå & Dingsøyr, 2008). Estudos recentes incluem também Lean entre os mais utilizados (Kupiainen et al., 2014). Além disso, uma pesquisa de opinião patrocinada pela VersionOne, uma empresa fornecedora de ferramentas para gerenciamento de projetos ágeis, que anualmente realiza um questionário sobre uso e impressões relacionados a métodos ágeis, aponta como métodos mais utilizados o Scrum, um híbrido de Scrum e XP, além de processos customizados (híbrido de práticas ágeis) como os mais utilizados pelas empresas que utilizam métodos ágeis (VersionOne, 2015). Nas seções seguintes serão detalhados o Scrum, o XP, além de uma breve descrição sobre modelagem ágil. 2.2 Scrum O Scrum é um processo de gerenciamento de projetos de software iterativo e incremental com foco em entender as necessidades e prioridades dos clientes e entregar software de qualidade em funcionamento. O Scrum é um processo empírico, ou seja, o conhecimento é baseado na experiência e as decisões são tomadas baseado no que é conhecido. Ele não fornece as técnicas para o projeto ou desenvolvimento de software (Schwaber & Sutherland, 2011). O Scrum tem sua fundamentação em três pilares: transparência, inspeção e adaptação. Todos os envolvidos devem ter uma visão e entendimento do que está sendo produzido. Os participantes devem constantemente inspecionar os artefatos e resultados para averiguar se o objetivo será cumprido. Caso haja algum desvio detectado durante a inspeção o processo ou os artefatos devem ser corrigidos (Schwaber & Sutherland, 2011). A Figura 2 apresenta um modelo geral do Scrum (Scrum Alliance ). Os requisitos do produto (product backlog) são definidos junto com o cliente ou seu representante dentro da empresa (product owner), através de linguagem textual que explica quais as funcionalidades ou casos de uso devem ser implementadas no software, as chamadas estórias. É também função do product owner estabelecer as prioridades para as estórias (Ken Schwaber & Beedle, 2001). Com base nas prioridades dos requisitos do produto é feito o planejamento do ciclo de desenvolvimento, chamado sprint. A partir dos requisitos que são incluídos no sprint o time de desenvolvimento planeja as atividades que serão realizadas. O time 7

8 também projeta qual será o produto acabado ao final do período, dividindo tecnicamente as estórias, que irão gerar um backlog de atividades do sprint (Schwaber & Sutherland, 2011). Durante o ciclo, que pode durar entre duas a quatro semanas são realizadas reuniões diárias de acompanhamento. Estas reuniões devem ser realizadas em pé e não devem durar mais que quinze minutos. Seu propósito é compartilhar o que foi realizado no dia anterior, qual o planejamento para o dia atual e se existe algum impedimento (Schwaber & Sutherland, 2011). As atividades de desenvolvimento incluem o projeto, desenvolvimento e teste do código em funcionamento. Ao final do sprint é realizado uma revisão, onde se faz uma demonstração do software produzido durante o ciclo. Assim como uma retrospectiva, onde são avaliados quais foram as boas práticas e o que deve ser melhorado (Schwaber & Sutherland, 2011). O time de desenvolvimento no processo Scrum deve ser multifuncional e auto gerenciável. Apesar das especialidades, o indivíduo deve ser chamado desenvolvedor. Podendo realizar diversas atividades, como projeto, desenvolvimento ou teste. (Schwaber & Sutherland, 2011). Um dos papéis descritos no Scrum é o do scrum master, ele é o responsável por orientar o time, remover os impedimentos, além de ser a interface com pessoas externas ao processo de desenvolvimento. Figura 2. Processo de gerenciamento de projetos software Scrum Fonte: adaptado de Scrum Alliance 2.3 XP A programação extrema foca em técnicas de programação, comunicação e trabalho em equipe. Suas principais características são ciclos de desenvolvimento curtos, mudanças incrementais, adaptação às mudanças, testes automáticos, comunicação oral, em código e testes, projeto evolutivo e colaboração entre os programadores (Beck, 2004). 8

9 As principais práticas do XP são (Beck, 2004): Jogo de planejamento: planejamento e definição dos requisitos técnicos e de negócio (função para o qual o software se propõe a resolver). O planejamento é realizado por iteração, e controlado diariamente. Nesta fase as estórias de usuários são descritas, para que possa se planejar quais entrarão na liberação a cada iteração. As estórias correspondem aos casos de uso. Cada estória possui uma estimativa de tempo para implementação, com base nesta informação é decidido quais as estórias serão implementadas a cada iteração de acordo com sua prioridade, definida pelo cliente, ou seu representante. Pequenas entregas: as entregas devem ser frequentes e a cada iteração. Elas devem incluir os testes unitários e os critérios de aceitação. Metáforas: tem a intenção de formar um vocabulário acessível para todos os envolvidos no projeto, de usuários a desenvolvedores, descrevendo uma visão geral do sistema. Projeto simples: determina que o projeto de software deve ser realizado somente para as tarefas determinadas, não tentando prever usos futuros. O projeto deve ser tão simples quanto possível, para resolver os requisitos atuais. O projeto deve comunicar a visão que o programador teve e devem atender aos requisitos, ou seja, os testes devem ser verificados. O projeto não deve ter lógica duplicada e possuir o menor número de classes e objetos possíveis. Testes constantes: os testes devem ser divididos em testes unitários e testes de aceitação. Os testes unitários são criados junto com o desenvolvimento do software e devem ser rodados sempre que houver modificação no código. Os testes de aceitação verificam se as funcionalidades exigidas pelo cliente funcionam de maneira satisfatória. Refatoração: melhorias contínuas no código e em seu projeto, otimizando-os sem alterar a sua funcionalidade. Programação pareada: todo código é produzido por duas pessoas no mesmo computador. Enquanto uma pessoa projeta e codifica a outra pensa em formas mais eficientes de cumprir o mesmo objetivo, além de revisar o código e apontar as falhas. Os pares são trocados frequentemente, assim como os papéis. Propriedade coletiva: encoraja a equipe a trabalhar em todas as partes do sistema, sem responsáveis por módulos específicos. Integração contínua: o código privado desenvolvido é integrado ao sistema, sendo efetivamente incluído somente após passarem todos os testes, sem falhas. Semana de 40 horas de trabalho: evitando horas extras, que podem diminuir a qualidade do código. Clientes dentro da empresa: os clientes são responsáveis por definir as funcionalidades e as prioridades, é necessário que ele esteja em contato 9

10 constante com a equipe. Caso isso não seja possível, é necessário alguém que o represente e seja conhecedor das suas necessidades; Padrões de codificação: para que todos codifiquem com o mesmo estilo, facilitando o entendimento do código e encorajando a propriedade coletiva. O ciclo de vida de um processo XP inclui a fase de exploração, onde são investigadas os requisitos gerais e planejado uma visão completa do sistema, incluindo sua arquitetura prévia. Após esta fase inicia-se a fase de planejamento. Nesta fase as estórias são estimadas e o cliente decide as prioridades, sendo definidas quais estórias serão incluídas em cada iteração (de 1 a 3 semanas) e consequentemente, a cada liberação (de 2 a 4 meses). A fase das iterações dentro de uma liberação, inclui a escrita dos casos de teste, o projeto de software, codificação, realização dos testes e integração. Após o final da primeira liberação o software já encontra na fase de produção, onde é simulado um ambiente real de uso, para avaliar o desempenho do sistema. Simultaneamente, a fase de manutenção, inerente ao processo XP, inclui a refatoração, melhorias, correção de defeitos, integração de novos membros ao time, novas tecnologias ou melhorias na arquitetura. Por fim a fase de morte, que pode ser devido ao fato de não se vislumbrar mais funcionalidades ou por verificar uma inviabilidade do projeto (Beck, 2004). 2.4 Modelagem Ágil Modelagem ágil é uma metodologia baseada na prática para modelagem e documentação de sistemas de software. É uma coleção de valores, princípios e práticas que podem ser aplicados a qualquer projeto de desenvolvimento de software. Para o criador da modelagem ágil, os modelos são utilizados para entender o que se deseja construir e para ajudar na comunicação. A questão fundamental que a modelagem ágil pretende direcionar é como criar modelos de maneira efetiva e de uma maneira ágil (Ambler, 2002). A modelagem ágil adota e estende os valores do XP. Comunicação facilitada por modelos que podem promover o entendimento entre times, envolvidos no projeto e desenvolvedores no mesmo time. Simplicidade nos modelos. Retorno (feedback) mais rápido sobre a ideia de implementação, apresentando diagramas, podem rapidamente receber opiniões sobre sua ideia. Coragem para tomar decisões e mudar de direção sempre que necessário, descartando ou refatorando o trabalho quando ele não estiver adequado. Humildade para reconhecer que não sabe tudo e que colegas, clientes e outros envolvidos podem ter opiniões válidas (Ambler, 2002). A modelagem ágil apresenta princípios equivalentes ou relacionados aos do XP. O software em funcionamento sendo o principal objetivo de um projeto de software, eliminar todo esforço desnecessário, acolher as mudanças, modelar com um propósito e conteúdo é mais importante que a representação (Ambler, 2002). 10

11 Um conjunto de práticas são derivadas dos princípios e valores da modelagem ágil. São elas (Ambler, 2002): Modelagem iterativa e incremental (aplicar os artefatos corretos, criar múltiplos modelos em paralelo, alternar para outro modelo, modelos incrementais); Trabalho em equipe (modelagem com outros, participação ativa dos envolvidos, propriedade coletiva, apresentar modelos publicamente); Simplicidade (criar conteúdo simples, representar modelos de maneira simples, usar as ferramentas mais simples); Validação (considerar a testabilidade, prová-la com código); Produtividade (aplicar padrões (standards) de modelos, aplicar matrizes (patterns) gentilmente, reutilizar recursos existentes); Documentação (descartar modelos temporários, formalizar modelos de contrato, atualizar somente se estritamente necessário); Motivação (modelar para entender, modelar para comunicar); Os principais modelos sugeridos para uso com a modelagem ágil são os diagramas da UML, principalmente os diagramas de sequência, de classe, casos de uso além de diagramas que representem uma visão geral da arquitetura, telas de interface com o usuário, modelos de dados, conceitos e processos de negócios e CRC (classeresponsabilidade-colaboração) (Ambler, 2002). 3 Método de Pesquisa A Figura 3 apresenta o método de pesquisa utilizado neste trabalho. Primeiramente foi realizado uma busca na literatura e o tema de pesquisa foi definido. Para identificar o estado da arte para o tema escolhido foi feita uma revisão sistemática da literatura de acordo com as diretrizes propostas por Kitchenham & Charters, As perguntas de pesquisa que se pretendem responder com esta revisão sistemática da literatura são: ágeis? ágeis? QP1. Quais são os instrumentos de projeto de software utilizados em métodos QP2. Quais são as visões de modelagem descritos nos métodos ágeis? QP3. Quais são as linguagens de modelagem que são utilizadas em métodos QP4. Em que momentos a modelagem é realizada no desenvolvimento ágil de software? QP5. Quais critérios avaliam o uso de modelagem em métodos ágeis? QP6. Como a definição e comunicação da arquitetura é realizada em métodos ágeis? 11

12 As fontes de informação utilizadas para pesquisa foram: IEEE Xplore 2 ACM Digital Library 3 ISI Web of Science 4 Nas orientações propostas por Kitchenham & Charters, 2007 são apresentados como critérios determinantes para a pesquisa: contexto, população, comparação, intervenções e resultados. Para este estudo foram definidos: Contexto: software População: agile Intervenção: modeling Comparação e resultados não foram incluídos na pesquisa para não restringir os trabalhos encontrados. A frase de busca utilizada foi a combinação lógica de todos os elementos do contexto, população e intervenção. Assim a frase de busca ficou definida como: (Software AND Agile AND modeling). A busca foi realizada no título, resumo e palavras chaves. A frase de busca, que possibilitou uma amplitude maior de resultados, gerou um número maior de artigos encontrados, que foram então selecionados a partir dos critérios de inclusão e exclusão dos mesmos. Foram considerados somente trabalhos originais e não duplicados, relativos à engenharia de software. A qualidade e adequação ao tema de pesquisa foram verificadas de acordo com as questões de verificação definidas abaixo. QV1: O trabalho é uma pesquisa científica (possui método claro e resultados confiáveis)? QV2: O foco do estudo é processo de desenvolvimento de software ágil? QV3: O trabalho apresenta resultados relacionados ao processo de modelagem ou projeto de software? QV4: O escopo do trabalho e suas limitações são bem definidos? Todas as questões de verificação de qualidade devem ser afirmativas para que o estudo seja incluído na revisão sistemática

13 Figura 3. Método de Pesquisa 4 Resultados A pesquisa resultou num total de 3939 artigos. Após uma primeira triagem por título e resumo foram selecionados 73 artigos. Posteriormente, foi realizada uma seleção baseada no conteúdo, método e resultados dos artigos, resultando num total de 20 estudos relevantes quanto a modelagem em métodos ágeis. A Tabela 2 apresenta os dados completos das pesquisas por buscadores. Tabela 2. Resultados das buscas Buscador Data da Busca Resultados Título/ Resumo IEEE Xplore 26/07/ ACM Digital Library 29/07/ ISI Web of Science 30/07/ Método/ Resultados A relação dos artigos selecionados e incluídos na revisão sistemática após a verificação das questões de verificação são apresentados no apêndice 8.1 em ordem cronológica de publicação. 13

14 Após uma análise do conteúdo dos artigos eles foram divididos em 6 categorias: estudos comparativos e revisões anteriores sobre modelagem ágil, propostas de integração de processos e modelagem ágil, aspectos práticos sobre modelagem, modelagem de arquitetura e requisitos em métodos ágeis, métodos formais e métodos ágeis, desenvolvimento orientado a modelagem (MDD do inglês, model-driven development). 4.1 Estudos Comparativos e Revisões Anteriores sobre Modelagem Ágil Em seu estudo Stojanovic et al., 2003 apresentam os resultados de sua pesquisa sobre modelagem em métodos ágeis. Eles argumentam que XP, FDD, modelagem ágil e modelagem extrema (XM, do termo em inglês Extreme Modeling) apresentam descrição de técnicas que são relacionadas com modelagem e projeto de software. A Tabela 3 apresenta uma comparação entre este subconjunto de métodos ágeis. XP, FDD e modelagem ágil já foram brevemente descritos neste documento, quanto ao XM trata-se do uso de desenvolvimento de software dirigido por modelos, para transformação de modelos diretamente para código, baseado no XP. De acordo com os autores, a quantidade de modelagem é baixa ou média para os métodos analisados. Não há auxílio de ferramentas para o XP e FDD, sendo que para a modelagem ágil o uso é o mais simples possível, por exemplo o uso de quadro branco. O uso é extensivo em XM, pois a transferência de modelos para código é feita por software. As notações mais utilizadas são estórias de usuário, cartões de CRC, esboços de classes, funcionalidades (features), diagramas de sequência, telas de interface com usuário, modelagem de dados, UML e redes de Petri. O projeto de arquitetura é baseado em orientação a objetos, domínios, metáforas e protótipos. A elicitação dos requisitos é realizada com o auxílio de estórias de usuários, casos de uso e funcionalidades. Modelagem ágil acrescenta modelagem de negócios e uso de componentes. XM, por sua vez, faz uso de repositórios de modelos e propõe a reutilização dos mesmos. Todos os processos são incrementais (Stojanovic et al., 2003). Tabela 3. Projeto e modelagem em um subconjunto de métodos ágeis Escopo Processo de Desenvolvimento XP FDD Modelagem Ágil Modelagem Extrema (XM) Processo de Desenvolvimento Modelagem Projeto Modelagem Baixa Baixa Média Média Ferramenta apoio Notação de Não Estórias de usuários, CRC, esboços de classes Não especificado (possível suporte de UML) Funcionalidades, objetos/classes, diagramas de sequência e O mais simples possível (quadrobranco) UML + estórias de usuários, telas de interface com usuário, modelagem de dados, etc Processo de Desenvolvimento Suporte extensivo (transferência de modelos para código UML padrão + redes de Petri 14

15 Projeto arquitetura Elicitação requisitos Uso componentes Modelagem negócios Repositórios modelos de dos de de de Projetando sistemas grandes Metáforas, Architecture Spike (protótipos), primeira liberação Baseado em modelo de objetos Pacotes domínio Estórias de usuário Funcionalidades Casos de uso + estórias de usuário Não Não Até certo ponto Não Não Não Sim Não Não N/A Não Sim Não Até certo ponto Sim Sim Incremental Sim Sim Sim Sim Iterativo Sim (pequenos incrementos) Fonte: adaptado de Stojanovic et al., 2003 Sim, somente duas fases de Sim, sequencial e iterativo Baseado orientação objetos Casos de uso em a Modelo e código constantemente sincronizados Os autores sugerem que o uso de orientação a objeto, e a modelagem utilizando ferramental orientado para esse fim, como CRC e diagramas UML podem não ser a melhor alternativa para aderir aos princípios dos métodos ágeis. Eles sugerem o uso de componentes para trazer melhores resultados (Stojanovic et al., 2003). Componentes possuem um nível de abstração mais alto que objetos e classes. Sua descrição é focada nos serviços que determinado componente oferece mais que em como este serviço foi desenvolvido. Desta maneira componentes auxiliaram a atingir uma melhor comunicação entre os envolvidos da área de negócios e técnica. O uso de componentes traria mais simplicidade ao criar modelos mais abstratos de arquitetura, além de contribuir para criar projetos escalonáveis. A estratégia de divisão do projeto em componentes facilitaria o entendimento do problema e sua solução. Por outro lado o uso de componentes requer interfaces bem definidas, o que pode adicionar complexidade no projeto de software de cada componente individualmente (Stojanovic et al., 2003). Já Erickson et al., 2005 apresentam uma crítica aos estudos sobre métodos ágeis, incluindo a modelagem ágil, argumentando que os estudos são em sua maioria casos de sucesso. Ele revisa os conceitos de Abrahamsson et al., 2003 que afirmam que os métodos ágeis são basicamente ciclos de desenvolvimento de análise, projeto, construção e teste (ADCT, do inglês analysis, design, code and test), assim a modelagem faria parte de cada ciclo, auxiliada pelas técnicas propostas por Ambler, 2002 e avalia a modelagem ágil mais como um conjunto de práticas que uma nova metodologia. Para os autores, assimilar os conceitos de modelagem, especialmente a UML e outros diagramas não seguem o conceito de foco em código dos métodos ágeis. Para cumprir tal propósito, a modelagem deveria ser executável e facilmente convertida em código, além de todos os modelos poderem ser testados (Erickson et al., 2005). Além disso o autor afirma que não haviam estudos relevantes sobre modelagem ágil. 15

16 Sua conclusão sobre o tema foi que existiam poucos trabalhos nesta área e citou a dificuldade de avaliar o tema por considerar subjetivo a avaliação de boa ou má modelagem (Erickson et al., 2005). 4.2 Propostas de Integração de Processos e Modelagem Em seus estudos ShuiYuan et al., 2009 e Wang et al., 2010 fazem uma análise do uso de modelagem ágil em combinação com o processo unificado Rational (RUP, do inglês Rational Unified Process). Clientes e usuários fornecem os detalhes e prioridades dos processos do sistema, que para facilitar o projeto e entendimento é dividido em módulos. São utilizados diagramas de fluxo de operações, modelos de casos de uso e modelagem de objetos do negócio utilizando o CRC. Como sugerido pela modelagem ágil a definição da interface de usuário é definida como parte do processo de análise do projeto do sistema. Adicionalmente um diagrama de robustez é utilizado, este diagrama descreve objetos de interfaces, objetos de entidade e objetos de controle e procedimento. Ele é mais simples que o diagrama de sequência do UML, porém não é aplicável para lógicas complexas. O processo unificado também é apresentado em combinação com o Scrum e XP por Bruegge et al., Neste trabalho os autores apresentam um processo de desenvolvimento, ao qual, chamam de Tornado, onde modelos formais são utilizados em conjunto com modelos mais informais para comunicação entre os envolvidos. Cenários visionários são apresentados para entendimento da solução, porém a implementação é mais específica e focada em partes da solução, priorizadas pelo cliente. A Figura 4 apresenta o modelo que foi apresentado pelos autores, como uma adaptação do processo unificado proposto por Kruchten, Durante a fase de prédesenvolvimento o problema é definido, os requisitos funcionais e não funcionais são elucidados, é identificado uma prévia de projeto de alto nível e um cronograma inicial é proposto. No primeiro sprint é feito o lançamento do projeto e os times são alocados. Este sprint é mais longo que os subsequentes e deve fornecer uma visão clara do problema do cliente e uma primeira liberação de software. O projeto de software é baseado em cenários. Para a modelagem dos requisitos são usadas estórias de usuário dividas em pequenas tarefas. O foco principal deste processo é na usabilidade e um protótipo deve ser construído para receber uma primeira avaliação do cliente. Ao final do projeto o cliente realiza testes de aceitação para validar o software. Este é um modelo instrucional e foi utilizado com foco em ensino para o curso de engenharia de software (Bruegge et al. 2012). Os autores propõem o uso de um processo de modelagem criativo e informal, pois acreditam que os modelos ajudam a nivelar a compreensão dos conceitos a todos os envolvidos. Os modelos propostos são preferencialmente os da UML, feitos em quadro branco ou esboços em papel, prévias de interfaces de usuários, storyboards, textos narrativos e estórias de usuários (Bruegge et al., 2012). Como este é um processo acadêmico utilizado em cursos de engenharia de software os estudantes devem realizar a transição dos modelos informais em modelagem com rigor de especificação, para aprendizagem dos modelos mais formais. 16

17 Figura 4. Modelo do ciclo de vida de desenvolvimento de software Tornado Fonte: adaptado de Bruegge et al., 2012 O uso de modelagem UML combinado com Scrum é apresentado por Wei et al., O autor afirma que Scrum é o método ágil mais popular atualmente e propõe utilizar a estrutura de organização do Scrum com os métodos detalhados de implementação da modelagem UML. A abordagem faz um mapeamento das tecnologias de modelagem UML nas práticas do Scrum. A fase de elicitação dos requisitos é realizada utilizando casos de uso e estórias de usuários. O processo de desenvolvimento é iterativo e incremental utilizando a modelagem UML. Diagramas de classes seriam utilizados para descrever estruturas estáticas do sistema e diagramas de sequência, colaboração, atividades, de estado são usados para descrever as características dinâmicas. Os autores afirmam que não há necessidade de realizar esta modelagem utilizando ferramentas, mas utilizar quadros ou papel, ao final é decidido se o diagrama deve ser publicado. O uso do modelo foi aplicado em um estudo de caso e foi considerado de fácil entendimento e mantendo a agilidade do processo Scrum (Wei et al., 2014). 4.3 Aspectos Práticos sobre Modelagem O uso de esboços e diagramas foi apresentado no estudo de Baltes & Diehl, Os autores concluíram que o uso de esboços é frequente em desenvolvimento de software, estes são criados em pouco tempo e em sua maioria são revisados e pode haver uma transição de mídia, ou seja, do quadro branco ou folha de papel para ferramentas de suporte ou fotografias. Um terço dos esboços não tem vida útil de mais de um dia, outro um terço de até um mês e o restante tem vida mais longa que um mês. O arquivamento normalmente é feito com os esboços digitalizados, e a motivação para serem mantidos é para poder visualizar a implementação ou porque ajudam no seu entendimento. A maioria destes esboços contém elementos da UML, com uma parte contendo estritamente estes elementos. Além disso outros diagramas são informais. A 17

18 maioria dos esboços são criadas em quadros brancos ou papel. Sendo criados por uma ou mais pessoas. Os principais propósitos para a criação destes esboços estão relacionados com a criação, explicação ou entendimento do projeto. Além disso a compreensão e esclarecimento dos requisitos também foram citados como importante motivação (Baltes & Diehl 2014). Este estudo corrobora com a pesquisa de Cherubini et al., Estes autores também atribuem o uso de diagramas para compartilhar, esclarecer, racionalizar e para criação, durante o projeto de software. Além disso os autores apresentam que os desenvolvedores usam uma variedade informal de convenções visuais, frequentemente utilizando mais de uma notação no mesmo diagrama. Caixas e setas são os diagramas mais utilizados além do uso de figuras especiais para entidades específicas como base de dados e pessoas. Diagramas com ideias amadurecidas e já estabelecidos podem ser expostos publicamente, como por exemplo em paredes ou wikis, podendo ser transcritos para meios digitais. Esta publicação serve para entendimento do código existente ou para comunicação do sistema com todos os envolvidos, técnicos ou não (Cherubini et al., 2007). 4.4 Modelagem de Arquitetura e Requisitos em Métodos Ágeis O uso de redes de objetivos de forma mais leve em desenvolvimento ágil é apresentado por Lin et al., 2014 como forma de modelar requisitos e tornar o entendimento mais fácil entre todos os envolvidos, ao contrário do uso de diagramas UML, que segundo os autores são técnicos demais. O método consiste em definir os objetivos de alto nível, identificar os objetivos secundários escondidos nas estórias dos usuários e modelar hierarquicamente a estrutura de objetivos. Segundo os autores esse modelo mais estruturado facilita o entendimento da hierarquia dos requisitos, além de ser menos ambíguo do que a linguagem natural, o que é mais importante quando os requisitos não estão claros para o próprio cliente. Um modelo gráfico pode ser mais intuitivo e efetivo para o time entender os requisitos do projeto (Lin et al., 2014). A falta de suporte para atender aos requisitos não funcionais é apresentada por Farid & Mitropoulos, Segundo os autores há um foco no tratamento dos requisitos funcionais nos métodos ágeis, deixando os requisitos não funcionais como um processo posterior. Além disso preocupações com segurança, desempenho e escalabilidade são negligenciadas (Paetsch et al. 2003). Eles propõem o uso de uma ferramenta para dar suporte a metodologia para modelar requisitos não-funcionais para métodos ágeis (NORMAP non-funciontal requirements modeling for agile processes). A ferramenta NORMATIC é utilizada como auxílio para identificar, referenciar e modelar requisitos não-funcionais com requisitos funcionais numa tentativa de aprimorar a qualidade de software sem comprometer a agilidade. A ferramenta possibilita a geração automatizada dos requisitos não funcionais e inclui uma visualização de cores para diferenciar os requisitos não funcionais baseados no código e soluções, em restrições da arquitetura e políticas que não tem aspecto técnicos (Farid & Mitropoulos, 2012). A definição de uma modelagem estruturada para a arquitetura é apresenta no estudo de (Durdik, 2011). O autor sugere que a arquitetura sem um processo de definição bem definido traz um mau reuso entre projetos e propõe um novo processo 18

19 que direcione a elicitação dos requisitos através do uso de padrões e componentes. O processo é incremental e iterativo. Os artefatos são criados sob demanda. Segundo o autor o método inova ao trazer a reutilização de componentes como parte do processo de elicitação de requisitos (Durdik, 2011). Ainda relacionado a arquitetura, Hadar & Silberman, 2008 propõem uma metodologia para suprir a lacuna entre um planejamento mais estratégico da arquitetura e o foco em codificação dos métodos ágeis. A metodologia proposta é baseada na arquitetura de referência e arquitetura implementada, facilitando um posicionamento de todos os envolvidos quanto a distância entre os objetivos e o realizado, fomentando discussões de mudança de planejamento e mitigando riscos. Os autores afirmam que um nível de abstração deve ser imposto, para que a modelagem não seja muito detalhada. A arquitetura é dividida em níveis de abstração, desde um nível mais elevado que inclui módulos com responsabilidades funcionais distintas (representadas por símbolos de pacotes da UML). Um segundo nível de abstração é representado por componentes e suas interfaces. A partir deste nível são detalhadas as interfaces dos componentes e o que é necessário para cumprir suas funcionalidades (Hadar & Silberman, 2008). Em um viés de pesquisa mais voltado para a documentação e explicitação do conhecimento Christensen & Hansen, 2011 estudam como a arquitetura pode ser extraída a partir de anotações incorporadas ao código, o principal foco dos métodos ágeis. Apesar de não ser uma ideia nova e haver outros estudos relacionados, a maior contribuição do estudo é uma abordagem prática de evoluir a representação da arquitetura continuamente com o código (Christensen & Hansen, 2011). O uso de linha de produtos de software (SPL, do inglês software product line) que define sistemas por um conjunto de funcionalidades que podem ser compartilhadas em conjunto com métodos ágeis é abordado por Pohjalainen, Em seu estudo ele apresenta um estudo de caso onde 3 sistemas de software para telecomunicações foram realizados a partir de uma modelagem de baixo para cima, utilizando SPL e o seu modelo de funcionalidades. A Figura 5 mostra a sintaxe da modelagem por funcionalidades. O autor relata a dificuldade de utilizar uma abordagem MDA (com transformação de código) devido à dificuldade em encontrar ferramentas adequadas para tal. O uso de diagramas UML foi percebido como uma tarefa que consumiria muito tempo. Assim foi utilizada uma configuração textual, a análise de domínio orientada a funcionalidades. O autor conclui que o uso desta linguagem é simples, pois utiliza expressões regulares (Pohjalainen, 2011). 19

20 Fonte: adaptado de Hofman et al., 2012 Figura 5. Sintaxe modelagem por funcionalidades O uso de SPL com métodos ágeis também é abordado no estudo de Hofman et al., O estudo apresentado por estes autores relata a experiência de introduzir a modelagem por funcionalidades em uma linha de produtos e como este processo pode expandir o desenvolvimento de software entre unidades de negócio. Foi desenvolvido um método para determinar o modelo de funcionalidades a partir do conhecimento do domínio. Segundo os autores, este modelo melhora o entendimento dos requisitos por todos os envolvidos, facilitando a delimitação do escopo, testes, eficiência e transparência nas atividades de planejamento. Segundo os autores utilizando o método é possível criar um conjunto de atividades iniciais mais estruturado, essencial para o início do desenvolvimento em um processo ágil, a partir do qual o software irá evoluir, além de fornecer melhor visualização para reuso das funcionalidades (Hofman et al., 2012). 4.5 Métodos formais e métodos ágeis Alguns estudos resultantes desta pesquisa indicam uma tentativa de conciliar o uso de métodos formais com o desenvolvimento ágil. Métodos formais são uma coleção de técnicas baseadas em formalismos matemáticos usadas para descrever precisamente um sistema com relação à sua funcionalidade, concorrência, completude, corretude, ou seja, as propriedades de um sistema podem ser analisadas através dos modelos. Black et al., 2009 citam uma tentativa de integrar métodos formais em métodos ágeis, avaliando que esta integração pode abrir possibilidades de uso de métodos ágeis em instalações com criticidade de segurança. Segundo os autores os métodos formais trazem a vantagem de segurança ao lidar com aplicações críticas enquanto a agilidade traz os benefícios da flexibilidade (Black et al., 2009). Wolff, 2012 propõe a integração de especificações formais no Scrum. A modelagem de propriedades de alto risco do sistema é especificada somente para funcionalidades que exigem investigação. As tarefas convencionais com pouca ou nenhuma incerteza podem ser implementadas sem investigação. O seu uso com modelos executáveis exige o uso de ferramentas apropriadas (Wolff, 2012). 20

21 4.6 Desenvolvimento orientado a modelos Uma abordagem pragmática e ágil de desenvolvimento de software baseado em modelos é proposta por Rumpe, O autor propõe o uso de modelos como um artefato para documentar os requisitos e o projeto, geração de código e desenvolvimento de casos de teste. Uma abordagem de transformação permite uma evolução eficiente para mudanças nos requisitos, otimizando a arquitetura e gerando casos de teste para garantir a qualidade do sistema. A mesma linguagem (UML) é utilizada para a modelar o sistema e os testes (Rumpe, 2004). Esta primeira abordagem ainda necessitava de ferramentas mais eficientes para a transformação dos modelos, capazes de gerar eficientemente o código e testes executáveis. A adoção de desenvolvimento dirigido a modelos em conjunto com práticas ágeis também é abordado por Zhang & Patel, A modelagem é realizada em UML e há transformação dos modelos em código. Cada fase do projeto inclui análise de requisitos, projeto de alto nível, projeto detalhado, geração de código e testes unitários e de integração. As práticas de MDD adotadas incluem a modelagem como código, onde a modelagem pareada é utilizada para criar os modelos em UML. O código é então gerado a partir dos modelos com auxílio de ferramentas. Assim como no XP há uma abordagem de modelagem dirigida por testes, modelagem iterativa e incremental, modelagem contínua, gerando código frequentemente e testando em ambientes de testes automáticos (Zhang & Patel, 2011). O uso de modelagem ágil com MDD é um dos objetivos do estudo de Buchmann, Ele apresenta uma ferramenta chamada Valkyrie que permite o esboço de diagramas a mão livre usando-se da tecnologia de tela sensível ao toque, desta maneira ao invés de manualmente converter diagramas esboçados em quadro branco durante uma reunião de modelagem, o resultado é o diagrama realizado durante a reunião. O uso de ferramentas possibilitaria também a transformação de modelos para código e de texto para modelos. Além de uma proposta de criação de casos de teste a partir de modelos de caso de uso e diagramas de atividades automaticamente. As ferramentas utilizadas utilizam a notação UML (Buchmann, 2012). 5 Discussões A revisão sistemática da literatura realizada provê indícios baseados nos estudos indexados pelas bases de pesquisa escolhidas para responder às questões de pesquisa deste estudo. Nesta seção serão respondidas estas questões. 5.1 Instrumentos de Projeto de Software em Métodos Ágeis O projeto da arquitetura é baseado em orientação a objetos, domínios, metáforas e protótipos. O uso de prova de conceito, através de protótipos que comprovem o funcionamento de determinado modelo proposto, é incentivado quando a modelagem é utilizada. O uso de componentes é citado como aderente aos princípios dos métodos ágeis, pois agilizam o processo de ter o software em funcionamento, quando já existem componentes criados e com interfaces bem definidas. A definição da interface com o 21

22 usuário, quando aplicável, auxilia em um retorno mais rápido da expectativa do cliente em relação ao software, e pode ser considerada um instrumento para ajudar na definição do software. Alguns estudos apresentam ferramentas para auxiliar no processo de modelagem, sejam elas para a geração do código através dos modelos, ou mesmo para tornar as tarefas de modelagem mais práticas, como o uso de dispositivos que tem tela sensível ao toque. Porém, não há resultados abrangentes que atestem a efetividades destas ferramentas. Há também estudos que propõe o uso de métodos formais com princípios ágeis, avaliando que somente funcionalidades com criticidade de segurança devessem ser analisada por estes modelos. Esta abordagem também exige o uso de linguagens de modelagem bem definidas e o auxílio de ferramentas. Os estudos que avaliam o uso de MDD com métodos ágeis propõem que a partir dos modelos pudessem ser gerados além do código, os casos de teste, um dos princípios dos métodos ágeis. Porém, esta abordagem é criticada pois exige uma modelagem muito detalhada, uso intensivo de ferramentas, que muitas vezes podem não ser eficientes, gerando partes do código que devem ser retrabalhadas pelos desenvolvedores. Esta tarefa pode dificultar o trabalho, pois exigem grande esforço para descobrir onde estão os erros e uma posterior correção. 5.2 Visões de Modelagem nos Métodos Ágeis A modelagem está presente nos métodos ágeis, muitas vezes o uso de esboços e diagramas mais informais, com elementos como caixas e setas, ajudam na criação explicação ou entendimento do projeto. A compreensão e esclarecimento dos requisitos também são auxiliados com o uso de modelos. Este uso mais abrangente, utilizando elementos mais abstratos facilitam a comunicação entre os envolvidos, como clientes, que podem não conhecer as linguagens técnicas. Percebeu-se uma tentativa de adequar nos princípios ágeis, técnicas de modelagem, visto que ela é intrínseca do processo de desenvolvimento. Desta forma, o uso da modelagem de forma incremental, com foco no desenvolvimento de software rodando, funcional e verificado por testes foi evidenciada nos estudos. O foco em testes também é percebido, utilizando os modelos gerados também para a definição dos testes. Os artefatos produzidos, muitas vezes de maneira mais informal, em reuniões de criação, podem ser transferidas de mídia, para publicação e facilitar a comunicação, com auxílio de ferramentas, ou mesmo de maneiras mais diretas, como a utilização de fotografias. Um conceito presente nos estudos é a utilização de níveis de abstração, indo desde o nível mais abstrato, para facilitar a compreensão entre todos os envolvidos, que nos métodos ágeis, incluem desde desenvolvedores até representantes do cliente, durante o processo de desenvolvimento do projeto. De acordo com a necessidade os modelos são detalhados, porém é considerado o foco em código efetivamente rodando, sendo estabelecido que o nível de detalhamento não deve ser incentivado, mantendo o nível de abstração dos modelos. 22

23 5.3 Linguagens de Modelagem em Métodos ágeis Nos estudos encontrados nesta pesquisa a principal linguagem de modelagem utilizada é a UML. Há ainda indícios de uso de diagramas que não seguem uma linguagem específica. Estes diagramas informais utilizam elementos como caixas e setas, as vezes utilizando figuras específicas, como bases de dados ou representação de pessoas e podem conter ainda elementos da UML. Alguns estudos citam o uso de redes de Petri ou modelagem por funcionalidades. Em estudos que tratam do MDD a linguagem utilizada é sempre a UML complementadas pelo uso de perfis. Há também o uso de linguagem textual para representar as estórias de usuários e o uso do CRC, semelhante ao diagrama de classes da UML. É citado também o uso de diagramas de robustez, que relacionam as classes de acordo com a sua função. 5.4 Momentos em que a modelagem é realizada no desenvolvimento ágil de software De acordo com os estudos, a modelagem é realizada ao longo das iterações. Cada iteração consiste de análise, projeto, desenvolvimento e testes. Porém, entendeu-se que nos primeiros sprints há um uso mais intenso de modelagem, pois os esforços para elicitação dos requisitos, análise e projeto são maiores nestes ciclos. A definição da arquitetura é realizada em conjunto, em processos de criação colaborativos. Alguns modelos são desenvolvidos nestas reuniões. 5.5 Critérios de avaliação do uso de Modelagem em Métodos Ágeis Não houveram indícios de critérios de avaliação nem qualitativos nem quantitativos quanto às métricas, benefícios ou limitações do uso da modelagem em métodos ágeis. 5.6 Definição e Comunicação da Arquitetura em Métodos Ágeis Reuniões de definição da arquitetura normalmente são realizadas de forma colaborativa, criando-se esboços em quadros branco ou em papel. Estes artefatos, quando mais estabelecidos através da prova de conceito por código, são digitalizados, se isso for julgado importante, e publicados em wikis ou em algum lugar visível fisicamente, como em paredes, onde possam ficar visíveis para todos os envolvidos. Há também propostas de marcações no código, o objetivo principal nos métodos ágeis, para gerar documentação da arquitetura. A Figura 6 apresenta uma síntese sobre o uso de modelagem em métodos ágeis de acordo com os indícios coletados da literatura. A modelagem é mais intensa nos ciclos iniciais, porém é realizada ao longo de todo o projeto. A criação é colaborativa e é realizada para elicitação dos requisitos, compreensão e comunicação entre os envolvidos. Há uma tentativa de uso conjunto de métodos formais e MDD, bem como a utilização de componentes e modelagem por funcionalidades com os métodos ágeis. As principais linguagens utilizadas são UML, diagramas informais, cartões CRC e linguagem textual. Os estudos apresentaram um uso restrito de ferramentas para modelagem e uso extensivo de esboços em quadro branco e papel. 23

24 Definição Colaborativa Protótipos - Componentes - Funcionalidades - Diagramas UML - Diagramas Informais - cartões CRC - Linguagem textual Ciclo 1 Ciclo 2 Ciclo 3 Ciclo n Elicitação dos Requisitos Compreensão Comunicação Interface com Usuário Legenda - MDD - Métodos Formais - Uso restrito de ferramentas - Uso extensivo de esboços em quadro branco e papel Modelagem Propostas de Integração Ciclos de Iterações Artefatos Figura 6. Modelagem em Métodos Ágeis 6 Conclusão Neste trabalho verificamos evidências do uso de modelagem em métodos ágeis. Utiliza-se principalmente a linguagem UML, diagramas informais, cartões CRC e linguagem textual. Há uma tentativa de aderência aos métodos formais, além do uso de MDD em conjunto com os métodos ágeis. A modelagem é realizado ao longo do projeto, durante cada iteração, com uma intensidade maior durante os primeiros ciclos. Porém, faltam experimentos realizados em ambientes reais mais abrangentes. As pesquisas normalmente são feitas através do uso de entrevistas semiestruturadas ou questionários, que apenas apresentam percepções dos envolvidos com o processo de desenvolvimento de software e não os efeitos reais do uso de modelagem em métodos ágeis. Além disso muitos dos estudo encontrados nas buscas, são propostas de usos diferenciados da modelagem em conjunto com os princípios dos métodos ágeis, onde apenas um estudo de caso é apresentado para validar a proposta, sem uma validação mais abrangente do novo modelo. 6.1 Limitações deste estudo Devido a escolha das bases de pesquisa e frases de busca, estudos relevantes podem ter sido omitidos. A realização da inclusão e exclusão dos artigos por apenas uma pessoa também pode levado a erros na verificação, visto que a análise dos critérios são subjetivos, e poderiam ter resultados distintos caso a mesma fosse feita por outra pessoa. 24

25 6.2 Trabalhos futuros Como propostas de trabalhos futuros poderiam ser estudados linguagens de modelagem mais acessíveis e de fácil compreensão, completa e que tenha aderência ao estilo ágil, de ser desenvolvimento em profundidade, em contrapartida ao uso da UML, que apesar de bem difundida é complexa e apresenta muitos diagramas distintos. Estabelecer critérios de avaliação para identificar as vantagens e desvantagens do uso da modelagem, para que seja possível avaliar o impacto de utilização de modelagem. Por fim, sugerimos uma pesquisa estruturada para avaliar o uso na prática de modelos em métodos ágeis. Coletando, através de questionários, como os desenvolvedores utilizam os instrumentos de modelagem e a percepção dos mesmos do seu uso. 7 Referências Abrahamsson, P. et al., New directions on agile methods: a comparative analysis. 25th International Conference on Software Engineering, Proceedings., 6. Abrahamsson, P., Ali-Babar, M. & Kruchten, Agility and Architecture: can they coexist? IEEE Computer Society, (April), pp Alliance, S., What is Scrum? An Agile Framework for Completing Complex Projects - Scrum Alliance. Available at: [Accessed August 9, 2015]. Ambler, S., Agile Modeling: Effective Practices for extreme Programming and the Unified Process. Baltes, S. & Diehl, S., Sketches and Diagrams in Practice Categories and Subject Descriptors. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. pp Beck, K., Extreme Programming Explained: Embrace Change 2nd ed., Addison- Wesley. Beck, K. et al., Manifesto for Agile Software Development Disponível em: [Acessado em 02/08/2015]. Black, S. et al., Formal versus agile: Survival of the fittest. IEEE Computer Society, 42(9), pp Bruegge, B., Krusche, S. & Wagner, M., Teaching Tornado Categories and Subject Descriptors. EduSymp12, pp Buchmann, T., Towards tool support for agile modeling: sketching equals modeling. Proceedings of the 2012 Extreme Modeling Workshop, pp

26 Cherubini, M. et al., Let s Go to the Whiteboard: How and Why Software Developers Use Drawings. CHI 2007 Proceedings, pp Chow, T. & Cao, D.-B., A survey study of critical success factors in agile software projects. Journal of Systems and Software, 81(6), pp Christensen, H.B. & Hansen, K.M., Towards architectural information in implementation: NIER track rd International Conference on Software Engineering (ICSE), pp Chuang, S.W., Luor, T. & Lu, H.P., Assessment of institutions, scholars, and contributions on agile software development ( ). Journal of Systems and Software, 93, pp Cockburn, A., Crystal clear: A Human-Powered Methodology For Small Teams, including The Seven Properties of Effective Software Projects, Addison-Wesley. Dingsøyr, T. et al., A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85(6), pp Durdik, Z., Towards a process for architectural modelling in agile software development. Proceedings of the joint ACM SIGSOFT conference -- QoSA and ACM SIGSOFT symposium -- ISARCS on Quality of software architectures -- QoSA and architecting critical systems -- ISARCS - QoSA-ISARCS 11, p.183. Dybå, T. & Dingsøyr, T., Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), pp Erickson, J., Lyytinen, K. & Siau, K., Agile modeling, agile software development, and extreme programming: the state of research. Journal of Database Management, pp Farid, W.M. & Mitropoulos, F.J., NORMATIC: A visual tool for modeling nonfunctional requirements in agile processes. Conference Proceedings - IEEE SOUTHEASTCON, (978). Freudenberg, S. & Sharp, H., The top 10 burning research questions from practitioners. IEEE Software, 27(5), pp.8 9. Hadar, E. & Silberman, G.M., Agile architecture methodology: long term strategy interleaved with short term tactics. Proceedings of the Conference on ObjectOriented Programming Systems Languages and Applications OOPSLA, 44(3), pp Hadar, I. et al., Less is more: Architecture documentation for agile development th International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE Proceedings, pp

27 Hofman, P. et al., Domain specific feature modeling for software product lines. Proceedings of the 16th International Software Product Line Conference on - SPLC 12 -volume 1, p.229. Kitchenham, B. & Charters, S., Guidelines for performing Systematic Literature Reviews in Software Engineering. Engineering, 2, p Kruchten, P., The Rational Unified Process: An Introduction, Addison-Wesley Professional. Kupiainen, E., Mäntylä, M. V. & Itkonen, J., Why are industrial agile teams using metrics and how do they use them? Proceedings of the 5th International Workshop on Emerging Trends in Software Metrics - WETSoM 2014, pp Lin, J. et al., Using Goal Net to Model User Stories in Agile Software Development. In International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD), th IEEE/ACIS. Misra, S., Agile software development practices: evolution, principles, and criticisms. International Journal of Quality & Reliability Management, 29(9), pp De O. Melo, C. et al., The evolution of agile software development in Brazil. Journal of the Brazilian Computer Society, 19(4), pp Paetsch, F., Eberlein, A. & Maurer, F., Requirements engineering and agile software development. WET ICE Proceedings. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003., pp Palmer, S.R. & Felsing, J.M., A Practical Guide to Feature-Driven Development, Prentice-Hall. Pohjalainen, P., Bottom-up modeling for a software product line: An experience report on agile modeling of governmental mobile networks. Proceedings - 15th International Software Product Line Conference, SPLC 2011, pp Poppendieck, B.M. & Poppendieck, T., Lean software development: an agile toolkit Software Development Managers, Addison-Wesley. Rumpe, B., Agile Modeling with the UML 1 Portfolio of Software Engineering Techniques. Radical Innovations of Software and Systems Engineering in the Future. 9th International Workshop, (October 2002), pp Schwaber, K. & Beedle, M., Agile Project Management with Scrum, Prentice- Hall. 27

28 Schwaber, K. & Beedle, M., Agile Software Development with Scrum, Prentice- Hall. Schwaber, K. & Sutherland, J., The scrum guide. Scrum. org, October, 2(July), p.17. Selic, B., Agile documentation, anyone? IEEE Software, 26(6), pp ShuiYuan, H. et al., A research and practice of agile unified requirement modeling International Symposium on Intelligent Ubiquitous Computing and Education, IUCE 2009, pp Stapleton, J., DSDM: Business Focused Development 2nd ed., Pearson Education. Stojanovic, Z., Dahanayake, A. & Sol, H., Modeling and Architectural Design in Agile Development Methodologies. In Exploring Modelling Methods for Systems Analysis and Design. Exploring Modelling Methods for System Analysis and Design, pp VersionOne, Th Annual State of Agile Survey., pp Available at: Wang, F., Gan, S. & Huang, L., The research and application of the requirement modeling method on AM-RUP requirement process. Proceedings - 3rd International Conference on Information Management, Innovation Management and Industrial Engineering, ICIII 2010, 2, pp Wei, Q. et al., Research on Software Development Process Conjunction of Scrum and UML Modeling Fourth International Conference on Instrumentation and Measurement, Computer, Communication and Control, pp Wolff, S., Scrum goes formal: Agile methods for safety-critical systems st International Workshop on Formal Methods in Software Engineering: Rigorous and Agile Approaches, FormSERA Proceedings, pp Zhang, Y. & Patel, S., Agile model-driven development in practice. IEEE Software, 28(2), pp

29 8 Apêndices 8.1 Artigos incluídos na revisão sistemática Os artigos que foram selecionados e incluídos na revisão sistemática após a verificação das questões de verificação são apresentados na Tabela 4 em ordem cronológica de publicação: Tabela 4. Artigos incluídos na revisão sistemática Autores Título Publicação Ano Stojanovic, Z. Dahanayake, A., Sol, H. Modeling and architectural design in agile development methodologies Conferência 2003 Rumpe, B. Agile modeling with UML Workshop 2004 Erickson, J., Lyytinen, K., Siau, K. Cherubini, M., Venolia, G., DeLine, R., Ko, A.J. Hadar, E., Silberman, G.M. ShuiYuan, H. et al. Agile modeling, agile software development, and extreme programing: the state of research Let's go to the whiteboard: how and why software developers use drawings Agile architecture methodology: long term strategy interleaved with short term tactics A research and practice of agile unified requirement modeling Revista 2005 Conferência 2007 Conferência 2008 Simpósio 2009 Black, S. et al. Formal versus agile: suvival of the fittest? Revista 2009 Wang, F., Shengke, G., Longjun, H. The research and application of the requirement modeling method on AM-RUP requirement process Conferência 2010 Pohjalainen, P. Bottom-up modeling for a software product line Conferência 2011 Chirstensen, H. B., Hansen, K. M. Durdik, Z. Zhang, Y., Patel, S. Bruegge, B., Krusche, S., Wagner, M. Buchman, T. Hofman, P., et al Towards architectural information in implementation Conferência 2011 Towards a process for architectural modelling in agile software development Conferência 2011 Agile model-driven development in practice Revista 2011 Teaching Tornado: from communication models to releases Towards tool support for agile modeling: sketching equals modeling Domain specific feature modeling for software product lines Simpósio 2012 Workshop 2012 Conferência

30 Wolff, 2012 Farid, W. M., Mitropoulos, F. J. Lin, J. et al. Wei, Q. et al. Baltes, S. Diehl, S. Scrum goes formal: agile methods for safety-critical systems NORMATIC: a visual tool for modeling non-functional requirements in agile processes Using goal net to model user stories in agile software development Research on software development process conjunction of Scrum and UML modeling Sketches and diagrams in practice: categories and subject descriptors Workshop 2012 Conferência 2012 Conferência 2014 Conferência 2014 Conferência Cronograma de elaboração do artigo para disciplina metodologia de pesquisa A Figura 7 apresenta o cronograma de atividades para elaboração do artigo para disciplina metodologia de pesquisa. O cronograma abrange a definição do tema de pesquisa, revisão sistemática, discussões e conclusões e a elaboração da apresentação. Estas tarefas são detalhadas, omitindo as reuniões de orientação que ocorreram ao longo de todo o trabalho. Figura 7 Cronograma elaboração artigo disciplina metodologia de pesquisa 8.3 Cronograma de Disciplinas do Mestrado A Figura 8 apresenta as disciplinas que foram cursadas, bem como a disciplina de metodologias ágeis para o desenvolvimento de software que será cursada posteriormente. 30

31 Figura 8. Cronograma de disciplinas cursadas no mestrado 8.4 Cronograma do Projeto de Pesquisa do Mestrado A Figura 9, apresenta o planejamento para a definição e planejamento do projeto de pesquisa, elaboração do artigo científico para submissão, escrita da dissertação e preparação para a apresentação da defesa da dissertação. Figura 9 Cronograma do projeto de pesquisa do mestrado 31