Conduzindo de forma ágil uma metodologia empírica para análise de Tecnologias de Software

Transcrição

1 27TH BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, Conduzindo de forma ágil uma metodologia empírica para análise de Tecnologias de Software Daniella Rodrigues Bezerra, Arilo Cláudio Dias Neto, Raimundo da Silva Barreto Computing Institute Federal University of Amazonas (UFAM), Manaus - AM, Brazil drodrigues@ufam.edu.br, {rbarreto, arilo}@icomp.ufam.edu.br Resumo Contexto: a escolha de uma tecnologia de software envolve muitas variáveis e exige uma profunda análise de cada uma delas. Estudos que resultam em metodologias empíricas para a análise do nível de maturidade das tecnologias se mostram potencialmente eficientes e auxiliam engenheiros de software a tomar uma decisão pela tecnologia mais adequada, sempre levando em consideração o cenário de aplicação da mesma. Objetivo: investigar se uma metodologia empírica pode ser conduzida por meio de métodos ágeis com o intuito de avaliar experimentalmente possíveis ganhos de desempenho na realização das atividades previstas. Método: nós selecionamos uma metodologia empírica para análise de tecnologias de software e a conduzimos com base no método ágil Scrum. Aplicamos a fusão dessas duas abordagens em um estudo prático projetado para avaliar a viabilidade, benefícios, desvantagens e o custo de adaptação por meio de uma análise qualitativa. Resultados: o método Scrum foi utilizado na íntegra nas fases de concepção, construção e avaliação de tecnologias de software, indicando desta forma, a viabilidade de utilização dos métodos ágeis para este contexto. A principal contribuição deste trabalho está relacionada a uma abordagem de como conduzir as fases de concepção, desenvolvimento e avaliação, auxiliando equipes de projetos de pesquisa ou desenvolvimento a identificarem de forma ágil que tecnologias utilizar. Conclusão: a abordagem é promissora e agrega valores de planejamento, estruturação, adaptação e previsibilidade a análise de tecnologias de software. Palavras-chave - Tecnologias de Software, Engenharia de Software Experimental, Métodos Ágeis, SCRUM. I. Introdução A análise de tecnologias de software envolve uma série de variáveis internas e externas ao projeto e demanda um tempo significativo. Aliado a isso, ainda existe uma complexidade inerente as características tecnológicas que se generalizam, e por outro lado, apresentam aspectos peculiares a um determinado domínio. Toda essa diversidade de fatores relacionados a análise de tecnologias de software fazem desta, uma atividade complexa e que envolve um certo risco caso não seja conduzida da forma sistemática, podendo resultar em um conjunto de escolhas errôneas e comprometer o sucesso do projeto. Em função disso, os engenheiros de software se deparam diante dos seguintes problemas: (i) como administrar as variáveis que influenciam na análise de uma tecnologia de software de forma a reduzir os riscos de escolhas inadequadas? (ii) como obter o custo de desenvolvimento ou adaptação de uma tecnologia? (iii) como identificar se a tecnologia selecionada ou implementada realmente agregou valor ao negócio? Existem várias metodologias que sugerem um ponto de partida à obtenção de soluções para tais problemas. Uma delas é a metodologia experimental proposta por Shull et al. [16], baseada em experiências adquiridas ao longo de duas décadas de observação unindo interesses de pesquisa e a necessidade das indústrias, essa metodologia auxilia na identificação do nível de maturidade de uma dada tecnologia. A metodologia de Shull et al. tem sido gradativamente estendida e vem demonstrando a sua flexibilidade e validade por meio de novos experimentos. Shull et al. [16] comenta superficialmente que a formalização de tecnologias para cenários variados de desenvolvimento de software não é uma tarefa trivial. As vezes a tecnologia é correta, no entanto foi aplicada de forma incorreta ou a tecnologia é nova e não demonstra de forma clara as reais melhorias que devem ser adquiridas com a adoção da mesma. Já uma tecnologia concebida de forma iterativa, oferece a possibilidade de isolar tais incertezas e a cada utilização da mesma, determinadas variáveis podem ser testadas com maior chance de se compreender os resultados obtidos para cada cenário. Shull et al. não detalha em sua metodologia como este processo iterativo pode ser conduzido e até o momento, nenhum outro trabalho o fez. Este fator nos motivou a investigar se a própria metodologia de Shull et al. poderia ser conduzida de forma iterativa e incremental, se os métodos ágeis agregariam algum valor a metodologia e quais seriam as vantagens, desvantagens e o custo dessa adaptação. Para realizar esta investigação nós conduzimos com base no método Scrum a metodologia empírica de Shull et al. [16] e observamos a fusão desses dois métodos através de um estudo prático projetado para avaliar a viabilidade, benefícios, desvantagens e o custo de adaptação por meio de uma análise qualitativa. Os resultados obtidos indicam que a abordagem é promissora e agrega valores de planejamento, estruturação, adaptação e previsibilidade a análise de tecnologias de software. Este artigo está organizado da seguinte forma: a Seção II apresenta a metodologia de Shull et al. e as duas extensões que contribuíram para a evolução da mesma. Na Seção III, os métodos ágeis são discutidos no contexto deste trabalho, suas características, vantagens e desvantagens são apontadas com base em estudos prévios. A nossa abordagem é detalhada na Seção IV e a aplicação da mesma é discutida

2 2 27TH BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, 2013 na Seção V. A Seção VI sumariza os resultados obtidos e para finalizar, a conclusão é discutida na Seção VII. II. Evolução de uma metodologia experimental para análise de tecnologias de software De acordo com Shull et al. [16], métodos empíricos aplicados ao estudo do processo de desenvolvimento de software sobre condições mais realistas possíveis podem prover validação do nível de maturidade de determinada tecnologia 1 e a identificação de problemas em tecnologias com baixo nível de maturidade. Este fator motivou Shull et al. a propor uma metodologia empírica baseada em experiências adquiridas ao longo de duas décadas de observação unindo interesses de pesquisa e a necessidade das indústrias. A metodologia de Shull et al. surgiu a partir da compilação de estudos prévios e agrupa um conjunto de artefatos capaz de reduzir o risco dos engenheiros de software ou pesquisadores escolherem tecnologias inadequadas ou incompatíveis. Tal metodologia é composta pelas quatro etapas seguintes. Estudo de Viabilidade. Tem como propósito identificar se a tecnologia oferece resultados práticos e se ela cumpre realmente com todos os objetivos para o qual foi criada. Os estudos de viabilidade contribuem para a identificação da efetividade da tecnologia, mas não estão aptos a cobrir todas as regras e hipóteses. Uma vez identificados os resultados práticos, o próximo passo é determinar se tais resultados podem ser alcançados de forma mais rentável. Essa informação pode ser obtida através de surveys ou entrevistas, muito úteis para coletar dados qualitativos e quantitativos. As surveys podem ser executadas em um tempo relativamente curto, se comparada as entrevistas, no entanto, podem coletar a informação em um nível de detalhe indesejável. Para minimizar esse risco, é fundamental um bom planejamento. Estudo de Observação. Sobre este estudo incide a necessidade de identificar se os passos adotados na tecnologia são adequados. O propósito deste estudo é coletar dados sobre como uma determinada atividade é concluída. Esses dados coletados podem ser classificados basicamente de duas formas: (i) enquanto a tecnologia está em execução ou (ii) ao final de cada etapa da tecnologia. A observação pode ser guiada por técnicas usadas para compreender práticas adotadas em novas tecnologias e para capturar informações sobre as circunstâncias em que a equipe envolvida com a tecnologia, porventura possa ter dificuldades para entendêla ou se adaptar. O observador pode também tomar nota do tempo consumido por cada etapa da tecnologia e se a etapa é eficaz para alcançar o seu objetivo ou não. Estudo de Caso. Tem como propósito identificar se a tecnologia se encaixa em um determinado ciclo de vida de um software. Esta análise pode ser feita por meio de um estudo de caso. Tal interação pode ser dispendiosa e 1 No contexto desta pesquisa, tecnologia de software é um termo genérico usado para representar, por exemplo, processo, método, modelo, ferramenta, frameworks etc., conforme nomenclatura adotada por [4, 12, 16]. levar a problemas que não surgem quando a avaliação da tecnologia ocorre de forma isolada. Estudo de Caso na Indústria. Uma vez identificado que a tecnologia tem aplicação prática em um ciclo de desenvolvimento real, o próximo passo é aplicá-la no contexto industrial. Novamente o estudo de caso pode elicitar se a tecnologia está em conformidade ou não em relação às necessidades da indústria. A metodologia de Shull et al., vem se mostrando abrangente o suficiente para avaliação de modelos computacionais, métodos, processos de desenvolvimento e ferramentas. Mafra et al. [12] aplicou a metodologia de Shull et al. e a enriqueceu a partir de uma necessidade relacionada a caracterização de evidências. Essa necessidade motivou a extensão de tal metodologia de forma a contemplar a adoção de uma abordagem baseada em evidência para a caracterização de resultados experimentais. A abordagem proposta por Mafra et al. é representada pela condução de estudos primários e/ou secundário 2 com o objetivo de auxiliar a concepção de uma nova tecnologia ou adaptação da mesma fundamentada em possíveis evidências existentes na literatura. Posteriormente, Dias-Neto et al. [4] observou, com base na proposta de Mafra et al., que a metodologia não abordava a avaliação de evidências coletadas por meio dos estudos secundários, impondo desta forma limitações para o uso da extensão de Mafra et al. caso os estudos secundários não resultassem em fortes evidências. Com base nesta oportunidade de melhoria, Dias-Neto et al. propôs uma extensão ao trabalho de Mafra et al. com o objetivo de apontar qual é a opinião dos especialistas sobre as evidências identificadas a partir de estudos secundários. Para tal, foram conduzidas várias surveys com a participação de vários engenheiros de software. Dias-Neto et al. sugere em [4] a investigação de seis características dentro do domínio da tecnologia que devem antecipar a execução de uma survey durante a fase de concepção e sugere também um possível caminho a seguir para cada uma das característica que são as seguintes: (i) Linha de Base: o domínio da tecnologia dispõe de uma linha de base? (ii) Corpo do Conhecimento: qual o nível de maturidade do domínio da tecnologia com base nos estudos primários? (iii) Especialistas: Quem são os especialistas na tecnologia em questão? (iv) Direcionamento para a realização de futuras pesquisas: a tecnologia dispõe de uma classificação dos grandes desafios? (v) Nível de Maturidade: qual o nível de maturidade da tecnologia com base nos estudos secundários? (vi) Comunidade da Tecnologia: existe uma comunidade oficialmente formada e ativa? 2 O estudo secundário identifica, avalia e interpreta todos os resultados relevantes a um determinado tópico de pesquisa, fenômeno de interesse ou questão de pesquisa [9]. Nesse sentido, resultados obtidos por diversos estudos primários correlatos atuam como fonte de informação a ser investigada por estudos secundários. Revisão e mapeamento sistemático são exemplos de estudos secundários.

3 BEZERRA AND DIAS-NETO AND BARRETO: MÉTODOS ÁGEIS E TECNOLOGIAS DE SOFTWARE 3 A Figura?? compila o processo evolutivo da metodologia de Shull et al., destacando o pronto exato das contribuições obtidas por meio das duas extensões propostas no campo da concepção da tecnologia. O eixo y (questões de pesquisa) da Figura??, está enumerado com base nas seguintes questões de pesquisa: 1. Existe evidência na literatura? 2. Qual é a opinião dos especialistas sobre as evidências identificadas a partir dos estudos secundários? 3. O tecnologia oferece resultados práticos e o tempo foi gasto adequadamente? 4. Os passos da tecnologia são adequados? 5. A tecnologia é adequada ao contexto de um ciclo de vida? 6. A tecnologia é adequada ao contexto de um ciclo de vida na indústria? De forma análoga, o eixo x destaca as etapas da metodologia para tal modelo em função do tempo. Figura 1. Metodologia sugerida por Shull et al. [16] e na sequência, estendida por Mafra et al. [12] e Dias-Neto et al. [4]. Os processos de desenvolvimento de tecnologias podem ser usados para capturar as melhores práticas de lidar com um determinado problema e viabilizam a popularização de boas práticas de trabalho, auxiliando a equipe executora a ter mais senso crítico e condições de prever tempo, esforço, entre outra variáveis, elevando o trabalho de uma escala artesanal para industrial. Sendo assim, uma tecnologia bem formalizada permite observar e mensurar o desempenho da mesma. Entretanto, o processo envolve uma série de desafios inerentes a formalização e iteração. Shull et al. [16] comenta superficialmente que a formalização de tecnologias para cenários variados de desenvolvimento de software não é uma tarefa trivial. As vezes a tecnologia é correta, no entanto foi aplicada de forma incorreta ou a tecnologia é nova e não demonstra de forma clara as reais melhorias que devem ser adquiridas com a adoção da mesma. Já uma tecnologia concebida de forma iterativa, oferece a possibilidade de isolar tais incertezas e a cada utilização da mesma, determinadas variáveis podem ser testadas com maior chance de se compreender os resultados obtidos para cada cenário. Shull et al. não detalha em sua metodologia como este processo iterativo pode ser conduzido e até o momento, nenhum outro trabalho o fez. Isso nos despertou o interesse de investigar as seguintes questões de pesquisa: 1. Poderia a própria metodologia de Shull et al. ser conduzida de forma iterativa e incremental? Os métodos ágeis agregariam algum valor a metodologia? 2. Comumente os métodos iterativos e incrementais são aplicados na fase de construção das tecnologias e não na fase de concepção e avaliação como discutido por Shull et al. Quais seriam as vantagens, desvantagens e o custo dessa adaptação? Com o intuito de fundamentar os métodos ágeis, a próxima seção aborda características e fatores motivantes para a integração dos mesmos na análise de novas tecnologias de software. III. Métodos Ágeis Um dos grandes desafios que a Engenharia de Software enfrenta é como otimizar o desenvolvimento de software de forma que resulte em entregas rápidas, baixo custo, que atendam as necessidades dos clientes e agreguem valor ao negócio com o menor esforço possível. Diversas sugestões para superar tais desafios estão surgindo a partir de experiências práticas com métodos de desenvolvimento ágil. Existem vários métodos ágeis e segundo a revisão sistemática realizada por Dybå e Dingsøyr [6], os seis principais métodos são: Crystal, Dynamic software development method (DSDM), Feature-driven development, Lean, Scrum e Extreme Programming (XP e XP2). Independente do método, todos eles compartilham da mesma filosofia, com foco na comunicação fácil entre as pessoas que participam do projeto (clientes, equipe técnica, etc.), entregas frequentes, melhoramento contínuo das estimativas e consequentemente do processo, desenvolvimento iterativo e incremental, aprendizado contínuo, compartilhamento do conhecimento, equipe capaz de se autogerenciar, flexibilidade e resposta rápida à mudanças de requisitos, administração de incertezas e complexidade, transparência no processo de desenvolvimento e melhor administração dos riscos. Laanti et al. [11] comenta vários benefícios e desvantagens mapeados a partir de uma survey abrangente realizada com mais de 1000 participantes envolvidos com métodos ágeis, distribuídos em sete países. Os nove benefícios mais relevantes são: efetividade do processo de desenvolvimento, aumento na qualidade do produto, transparência dos resultados obtidos, aumento na colaboração, o trabalho torna-se mais empolgante, aumento do senso de ética, o projeto fica mais organizado e melhor planejado, a equipe ganha mais autonomia e a detecção antecipada de erros. Um outro dado que chama atenção é que 60% dos participantes não tem nenhum interesse em voltar a traba-

4 4 27TH BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, 2013 lhar da forma anterior, ou seja, além do benefício material do ponto de vista do produto e da qualidade no relacionamento cliente-fornecedor, existe também o benefício social onde os funcionários também ganham em satisfação e qualidade de trabalho. Já as desvantagens são: gerenciamento dos requisitos no contexto de um planejamento iterativo, gerenciamento de dependências e estimativas incorretas. Com base nas características e benefícios dos métodos ágeis, nos vários casos de sucesso práticos e científicos envolvendo projetos dos mais variados níveis de complexidade, nós decidimos propor uma abordagem ágil para análise de tecnologias que será discutida na próxima seção. IV. Abordagem Proposta A nossa abordagem é executar de forma ágil as etapas de concepção, construção e avaliação. Na metodologia original, Shull et al. [16] detalha apenas a fase de avaliação. Posteriormente Mafra et al. [12] detalhou a fase de concepção. Neste artigo estamos detalhando a fase intermediária que é a de construção e como esta se integra com a fase de embasamento (conceituação) e a fase de mais alto nível (avaliação). Sendo assim, a evolução da metodologia de Shull et al., ilustrada na Figura 1, agora pode ser vista com base na nossa abordagem de acordo com a Figura 2. Damos destaque no eixo y para a questão de pesquisa que adicionamos, pertinente ao desenvolvimento de nova tecnologias. Todas as outras questões de pesquisa enumeradas de 1 a 6 seguem a mesma descrição detalhada na Seção II, identico a Figura 1. Figura 2. Fluxo proposto para análise de Tecnologias de Software. É importante ressaltar que a existência da fase de construção vai depender se a fase de conceituação revelar a necessidade de novas tecnologias. No entanto, a fase de conceituação e avaliação sempre estarão presentes no processo de análise de tecnologia de software existentes. Nas próximas seções detalharemos cada uma dessas fases. A. Fase de Concepção A fase de concepção inicia com a definição prévia de uma lista de requisitos fundamentada nas necessidades do projeto, seja de pesquisa ou desenvolvimento, com demanda para análise de tecnologia de software. Esta lista pode ser fundamentada em requisitos funcionais, não funcionais, user stories, lista de bugs, atividades técnicas, questões de pesquisa, objetivos (geral e específicos), mapeamento de necessidades da indústria, etc. De posse desta lista, popularmente chamada de product backlog 3 segundo a metodologia Scrum, cada requisito deve ser priorizado pelos interessados na execução da análise das tecnologias de software, para o domínio em questão. Após esta fase, inicia-se o planejamento do Sprint que na verdade representa um ciclo de execução com duração entre duas e quatro semanas, conforme sugestão da metodologia Scrum, definido com base na necessidade de cada projeto. Para cada item especificado no product backlog, a equipe executora 4 e responsável pela identificação das tecnologias de software, deve detalhar as atividades que serão desenvolvidas no decorrer do sprint, estimá-las e em seguida executá-las. Por exemplo, tanto para uma revisão de literatura ad-hoc ou a identificação de estudos primários e secundários, por meio de revisão ou mapeamento sistemático, devem seguir atividades como: planejamento, execução, coleta de dados e análise. O que varia é exatamente o método de execução de cada abordagem. No caso da revisão e mapeamento sistemático, cada uma dessas atividades deve seguir um rigor científico capaz de garantir a repetição e auditoria do processo. Já na revisão ad-hoc não existe este compromisso. De posse desta lista de atividades que devem ser realizadas ao longo do sprint, popularmente chamada de sprint backlog, a equipe executará vários ciclos de concepção sempre com o objetivo de responder se existem evidências na literatura. Uma reunião diária muito rápida deve ser feita onde cada membro da equipe fala o que foi e o que será feito com o intuito de deixar o processo mais transparente a todos os envolvidos e para uma rápida intervenção em caso de impedimentos por parte do scrum master. Ao final de cada sprint, a equipe deve realizar uma reunião de revisão com demonstrações dos objetivos alcançados e retrospectiva com discussões de lições aprendidas, sugestões de melhorias do processo, etc. e onde será efetivamente coletada a informação de interesse desta pesquisa sobre as vantagens e desvantagens de se conceber uma tecnologia de forma iterativa e incremental. O objetivo é que a cada sprint, a concepção da(s) tecnologia(s) seja obtida gradativamente. A Figura 4 ilustra a fase de concepção realizada de forma ágil. B. Fase de Construção A fase de concepção que antecede a construção pode resultar simplesmente em uma lista de sugestão para o reuso de tecnologias com base nas evidências encontradas ou pode resultar também em uma lista com a demanda 3 Para maiores detalhes sobre a nomenclatura utilizada pela metodologia Scrum, consultar Martin Blom [2]. 4 Recomendamos que os ciclos de concepção sejam feitos no mínimo por duas pessoas, sendo um o executor e o outro o revisor com possíveis trocas e revesamento de funções entre a dupla. Quando for o caso de equipes maiores, é só seguir as recomendações da metodologia Scrum.

5 BEZERRA AND DIAS-NETO AND BARRETO: MÉTODOS ÁGEIS E TECNOLOGIAS DE SOFTWARE 5 Figura 3. Fase de Concepção realizada de forma ágil. para o desenvolvimento de novas tecnologias. Neste segundo caso, cabe a execução de uma fase de construção que pode ser fundamentada no reuso de outras. Da mesma forma que a fase de concepção, um product backlog é especificado, cada item é priorizado, em seguida a equipe responsável pela construção da(s) tecnologia(s) detalha o sprint backlog e estima cada atividade. Vários ciclos de construção podem ser executados sempre com o intuito de produzir nova(s) tecnologia(s) a cada incremento. Existem vários trabalhos que relatam o processo de construção por meio de métodos ágeis [5,15]. No entanto, essa abordagem de trazer da fase de concepção evidências que ajudem a justificar e fortalecer a necessidade de novas tecnologias é inovadora. Um outro benefício é que a fase de concepção também resulta na indicação de que tecnologias são candidatas ao reuso para a construção de novas. A Figura 4 ilustra a fase de construção realizada de forma ágil. onde podem ser consideradas características da tecnologia que se pretende avaliar bem como objetivos que devem ser atingidos com a realização da avaliação. De posse desses requisitos devidamente priorizados, a equipe executora pode planejar o sprint backlog com as atividades que devem ser realizadas para se atingir os objetivos definidos. Todos os estudos definidos na metodologia de Shull et al. [16] para a fase de avaliação podem ser conduzidos de forma experimental. O benefício de se adotar uma submetodologia experimental para realizar cada um dos estudos previstos é que ao final, a condução individual de cada estudo pode ser reproduzida e auditada. Observe que neste caso, temos uma possível concatenação de dois métodos científicos e um tecnológico que podem ser combinados: (i) metodologia de Shull - fase de avaliação (estudos de viabilidade, observação, ciclo de vida e ciclo de vida na indústria), (ii) frameworks de experimentação para conduzir cada um desses estudos que tradicionalmente sugerem as fases de: (i) planejamento dos experimentos, (ii) projeto, (iii) coleta de dados, mensuração e (iv) análise. Por último, um método ágil para conduzir metodologia e sub-metodologia. Após o planejamento adequado da avaliação e execução da mesma, vários ciclo iterativos são realizados sempre com o intuito de identificar se: a tecnologia é viável, se os passos da tecnologia são adequados, se a tecnologia é adequada ao contexto de um ciclo de vida e ao contexto industrial. Ao final dos vários ciclos, incrementalmente teremos a tecnologia avaliada. A Figura 5 ilustra todos esse processo. Figura 5. Fase de Avaliação realizada de forma ágil. Figura 4. Fase de Construção realizada de forma ágil. Ao longo dos vários ciclos, avaliamos se o processo de construção contribuiu para a formalização da nova tecnologia. Caso a tecnologia tenha sido concebida de forma iterativa e incremental, seguindo um rigoroso processo, é possível validá-la e comparar características deste processo de desenvolvimento em relação a outros, bem como desempenho, usabilidade, corretude, etc. C. Fase de Avaliação A fase de avaliação consiste em identificar se a tecnologia é adequada ao propósito de aplicação seja ela nova ou não. Esta fase inicia com a definição do product backlog Por meio de um fluxograma, é possível visualizar em alto nível a abordagem propostas. A Figura 6 ilustra a execução dos vários ciclos de concepção. Ao final desta primeira fase, é possível analisar se o resultado obtido aponta para a demanda de novas tecnologias. Em caso positivo, ciclos de construção serão realizados e ao final, as novas tecnologias devem ser avaliadas. Em caso negativo, serão avaliadas as tecnologias candidatas ao reuso. Se ao final dos ciclos de avaliação a mesma foi positiva, teremos um conjunto de tecnologias adequadas. Caso o resultado não seja positivo, é necessário retornar ao ciclo de concepção e realizar novas iterações até que um conjunto satisfatório de tecnologias adequadas seja obtido. Na próxima Seção apresentaremos uma aplicação prática da abordagem proposta nesta seção com destaque para os

6 6 27TH BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, 2013 TABLE I Características do Projeto Mogno. Figura 6. Fluxo proposto para análise de Tecnologias de Software. artefatos obtidos em cada fase. V. Aplicando a Abordagem Proposta Nós aplicamos a abordagem proposta em um projeto de médio porte chamado Mogno, que teve a primeira iteração de análise de tecnologias de software formada pelas fases de concepção, construção e avaliação de tecnologias candidatas ao reuso executadas ao longo de 20 sprints (cada um com duração de duas semanas) no decorrer do ano de Já a fase de avaliação das novas tecnologias desenvolvidas, foi planejada para 19 sprints (cada um com duração de duas semanas) que ainda será executada no decorrer do ano de O projeto vem sendo conduzido em ambiente físico descentralizado sob acompanhamento do Grupo de Interesse em Sistemas Embarcados e Engenharia de Software - GISE/UFAM. A equipe técnica é composta ao total por quatro membros onde três são pesquisadores seniores e uma estudante. A experiência da equipe em métodos ágeis no inicio do projeto, variou entre o nível avançado, consolidado por desenvolvimento profissional de aproximadamente cinco anos usando o método Scrum até o nível básico, formado por experiências acadêmicas resultantes de discussões em fóruns, conferências e disciplinas. Quanto a análise de tecnologias de software, a equipe possuía experiência mista no início do projeto, variando entre um nível avançado e intermediário em relação a concepção, construção e avaliação. No decorrer do projeto essa diferença foi se nivelando já que o grupo GISE/UFAM tem internamente uma cultura colaborativa, o que facilita a comunicação e o compartilhamento de conhecimento. O projeto Mogno tem como objetivo gerar um modelo computacional que atenda as necessidades dos engenheiros florestais de análise da dinâmica florestal e estimativa de Carbono. Em linhas gerais, essa análise ocorre por meio da linguagem de consulta CarbonQL e da ontologia Carbontology especialmente desenvolvidas para este domínio. Esses dois componentes integrados formam o modelo computacional Mogno que usa a Engenharia Guiada por Modelos [7,8] como método para a integração e modularização dos mesmos. A partir da linguagem de consulta CarbonQL conectada a um banco de dados, os engenheiros florestais podem obter respostas aos seus questionamentos por meio da especificação de consultas usando a terminologia do domínio, formalizada por meio da Carbontology. Trata-se de um projeto que une uma necessidade prática da engenharia florestal com interesse de pesquisa da computação e com a necessidade da análise de tecnologias em Características Valores Tempo de duração do projeto 11 meses Porte do Projeto Médio Total de Sprints 20 Total de membros da equipe 4 (3 pesquisadores com dedicação parcial, 1 estudante com dedicação integral) Scrum Master Um dos pesquisadores Experiência prévia ou conhecimento básico sobre métodos ágeis Aplicável a todos da equipe Experiência prévia ou conhecimento básico sobre análise de tecnologias Aplicável a todos da equipe de software Product owner 2 engenheiros florestais Adoção da abordagem proposta por este artigo No início do projeto Tamanho do Sprint Software de gerenciamento do processo 2 semanas PangoScrum vários pontos da pesquisa. Sendo assim, a equipe adotou a abordagem proposta por este artigo para conduzir as etapas de concepção, construção e avaliação. A Tabela I sumariza as características mais relevantes do projeto Mogno para a discussão que segue nas próximas seções. A. Fase de Concepção: gerando um Mapeamento Sistemático como artefato de saída A fase de concepção para o Projeto Mogno teve como objetivo criar o alicerce da pesquisa. Esta fase iniciou com um conjunto primário de questões de pesquisa e objetivos, com escopo abrangente. Foram realizadas entrevistas com engenheiros florestais e estudos de observação in loco em reservas florestais para compreender a análise da dinâmica florestal e questões relacionadas. Deste levantamento inicial foram extraídas oportunidades de pesquisa, necessidades da indústria madeireira, bem como user stories. Uma revisão exploratória ou ad-hoc da literatura foi realizada com o intuito de se obter uma visão geral do problema de pesquisa, da problemática relacionada a área da dinâmica florestal, mapeamento prévio de modelos computacionais existentes, desafios associados a modelagem computacional, bem como a extração de termos técnicos e sinônimos, que posteriormente foram usados na formulação da string de busca do mapeamento sistemático da literatura [10, 14]. É importante enfatizar a análise prévia da real necessidade de se realizar mapeamentos e/ou revisões sistemáticas da literatura. O pesquisador deve caracterizar, com base nos objetivos definidos, que tipo de pesquisa

7 BEZERRA AND DIAS-NETO AND BARRETO: MÉTODOS ÁGEIS E TECNOLOGIAS DE SOFTWARE 7 pretende realizar e em seguida investigar se não existe até o presente momento algum mapeamento e/ou revisão que possa ser reusado no contexto da pesquisa. De posse desses requisitos iniciais (questões de pesquisa, objetivos, necessidades da indústria madeireira e user stories), o Product Backlog foi especificado e incrementalmente refinado, o Sprint Backlog incial foi planejado e em seguida executado em ciclos curtos de duas semanas, extamente para avaliar e obter feedback rápido do desenvolvimento da pesquisa. Ao final da execução de um ciclo, o Sprint Backlog e o Product Backlog eram revisados, toda a equipe discutia, em uma reunião de retrospectiva, sobre as entregas parciais e o andamento do sprint passado, em seguida, o novo sprint era planejado. O planning poker [13] foi usado como técnica para estimar o custo de excução e o valor agregado de cada user story em caso de conclusão. A Figura 7 mostra o total de pontos planejados versus pontos entregues para cada Sprint executado no Mogno. A soma dos pontos atribuídos pela equipe para cada atividade do Sprint, com base na complexidade e esforço resulta no total de pontos planejados. Já a soma dos pontos das atividades concluídas resulta no total de pontos entregues. Através do cruzamento dessas duas informações, e análise individual de cada sprint, é possível extrair variáveis como desempenho, total de impedimentos, como os impedimentos foram solucionados, ação e reação da equipe diante de impedimentos, etc. A revisão ad-hoc se repetiu o longo dos 3 primeiros sprints e gerou como resultado a demanda por estudos secundários, no entanto, como as questões de pesquisa ainda estavam em um nível abrangente, a equipe optou pela realização de um mapeamento sistemático com base nas seguintes etapas: 1. Planejamento: definição do protocolo; 2. Execução: as fontes para o mapeamento foram selecionadas, os estudos primários foram identificados, selecionados e avaliados de acordo com os critérios de inclusão, exclusão e de qualidade estabelecidos durante o protocolo do mapeamento; 3. Análise dos Resultados: os dados do estudo foram extraídos e sintetizados mostrando lacunas de pesquisa e oportunidade para realização de revisões sistemáticas. Por meio do mapeamento sistemático foi possível responder com mais propriedade se existem evidências na literatura, confrontar necessidades regionais, por exemplo, relacionadas ao cenário amazônico e necessidades mais abrangentes de pesquisa. Essa fundamentação foi o primeiro ponto de partida para identificar questões válidas ou não do ponto de vista científico, foco, fatores motivacionais, refinamento dos objetivos, etc. Como fruto dos estudos primários e secundários a Tabela II sintetiza os resultados obtidos para as tecnologias candidatas ao reuso e a demanda para o desenvolvimento de novas tecnologias. Observe que nem sempre a identificação do reuso implica que não será necessário desenvolver uma nova tecnologia. No entanto, ter uma demanda para o desenvolvimento de uma nova tecnologia tende a ser condição necessária e suficiente para o reuso de alguma TABLE II Análise do reuso e demanda para o desenvolvimento de novas tecnologias. Síntese obtida a partir da fase de concepção. Reuso de Tecnologias Demanda para o desenvolvimento de novas Tecnologias Engenharia Guiada por O modelo computacional Modelos Mogno Linguagem OWL Carbontology Linguagem de Domínio CarbonQL Específico + ANTLR Framework Hibernate e a Parser de tradução de linguagem HQL CarbonQL para HQL Padrão de Projeto MVC Arquitetura do compilador CarbonQL JEE + GWT (Google Front-end para a linguagem Web Toolkit) CarbonQL JBoss + Hibernate + Back-end para o Mogno MySQL Guia para inventário de gases de efeito estufa PangoScrum Mendeley Framework de Experimentação proposto por Basili [1] Start Mapeamento Sistemático tecnologia existente, pois é assim que o conhecimento científico avança. A terceira e última situação da Tabela II é quando existe a simples necessidade do reuso sem gerar demanda para o desenvolvimento de novas tecnologias. É o caso PangoScrum, ferramenta selecionada para administração de todas as atividades e artefatos produzidos pelo projeto Mogno. Durante os vários ciclos da fase concepção, foi possível investigar quais as vantagens de se conceber uma tecnologia de forma iterativa e incremental. No estudo de caso observado, a tecnologia de mais alto nível concebida foi o modelo computacional Mogno, composto por subtecnologias como a linguagem CarbonQL, a Carbontology, etc. Todas as vantagens e desvantagens tradicionalmente relatadas na adoção de métodos ágeis e discutidas na Seção III foram observadas na fase de concepção com exceção de uma: elimina a tendenciosidade de relatar os resultados pois os mesmos são obtidos a partir de um método formal que faz com que a escolha das tecnologias mais adequadas sejam um resultado lógico entre a análise das possibilidades e o contexto onde serão aplicadas. B. Fase de Construção: gerando um Projeto Piloto como artefato de saída Após a fase de concepção indicar a demanda para a construção de novas tecnologias, a equipe do projeto planejou a construção de um projeto piloto para validação da ideia.

8 8 27TH BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, 2013 Este processo, compreende a implementação de artefatos de pesquisa com base na engenharia guiada por modelos que sugere a construção simplificada do domínio em duas camadas: (i) modelos independentes de plataforma e (ii) modelos de plataforma específica. Com o objetivo de atender a camada (i), o projeto piloto gerou a linguagem de consulta CarbonQL e a Carbontology como artefatos. Entre a camada (i) e (ii) existe um tradutor de modelos chamado CarbonQLWalker e na camada (ii) tem o CarbonQL2HQL, um gerador de código para o framework de mapeamento objeto-relacional Hibernate que é responsável em gerenciar o mapeamento entre a CarbonQL (nível de especificação) e SQL (nível de execução). Os artefatos de pesquisa gerados na camada (i) e (ii) foram construídos com base nas seguintes etapas: 1. Análise: os requisitos previamente identificados foram refinados e as características, estruturas e comportamentos do projeto piloto foram descritos em nível conceitual; 2. Projeto: definição concreta do projeto piloto. 3. Implementação: os artefatos do projeto piloto foram efetivamente implementados na forma de componentes com base nas decisões de projeto. 4. Teste: os artefatos foram testados. Os que apresentarem algum tipo de falha ou restrição retornam ao fluxo de implementação para correção ou reimplementação. Todas as vantagens e desvantagens tradicionalmente relatadas na adoção de métodos ágeis, discutidas na Seção III foram observadas na fase de construção. O grande valor agregado nesta fase, na verdade está no fato da fase de concepção ter sido realizada de forma iterativa e incremental, produzindo rapidamente uma lista de novas teconologias que puderam ser implementadas no mesmo ritmo de agilidade. Isso garante que o processo de construção da tecnologia contribuiu para a formalização da mesma. C. Avaliando o reuso de tecnologias e planejando experimentos para as novas tecnologias desenvolvidas A fase de avaliação tem como objetivo identificar se a lista de tecnologias candidatas ao reuso realmente são adequadas e o quão bom é o modelo Mogno para o propósito estabelecido. Segundo as boas práticas científicas, novos métodos, modelos, técnicas, linguagens e ferramentas não devem ser apenas sugeridos, publicados ou apresentados sem a devida experimentação e validação. Uma das melhores formas de garantir um modo sistemático e controlado para tal validação é por meio de um método experimental. As duas seções seguintes abordam como o Framework de Experimentação proposto por Basili [1] foi utilizado nos subciclos de avaliação. Este framework possui as seguintes etapas: 1. Planejamento do Experimento: descrever os objetivos, o objeto do estudo, o foco da qualidade, o ponto de vista e contexto. Como resultado, a fase de planejamento fornece a direção geral do experimento, o seu escopo, a base para a formulação das hipóteses e as notações preliminares para a avaliação da validade. TABLE III Resultado de avaliação das tecnologias candidatas ao reuso. Tecnologias ao Reuso Cadidatas Viabilidade Observação Estudos Ciclo de Vida Indústria Engenharia Guiada por Modelos Linguagem OWL Linguagem de Domínio Específico + ANTLR Framework Hiberanate e a linguagem HQL Padrão de Projeto MVC JEE + GWT JBoss + Hibernate MySQL Guia para inventário de gases de efeito estufa PangoScrum Mendeley Framework de Experimentação proposto por Basili StArt Projeto: Nesta fase são selecionados: o contexto, as hipóteses, as variáveis e os participantes. Ocorre a preparação da instrumentação e a consideração da validade do experimento. O resultado dessa fase apresenta o experimento totalmente elaborado e pronto para execução. 3. Coleta de Dados e Mensuração: Ocorre sobre a execução do experimento. Nesta fase é importante atentar ao fator humano. Os participantes devem ser preparados para a experimentação do ponto de vista metodológico para evitar resultados errôneos devido ao mal-entendido ou falta de interesse. A coleta de dados deve ser realizada de maneira que não cause efeito significativo ao estudo em andamento. 4. Análise e interpretação: oferecem as conclusões sobre a possibilidade da rejeição da hipótese nula, a redução do conjunto de dados, e a verificação das hipóteses. Nessa fase, os aspectos mais importantes são: escolher o teste estatístico apropriado, explicar os resultados considerando os aspectos da validade, realizar a análise custo-benefício, e interpretar corretamente os resultados negativos.

9 BEZERRA AND DIAS-NETO AND BARRETO: MÉTODOS ÁGEIS E TECNOLOGIAS DE SOFTWARE 9 C.1 Tecnologias candidatas ao reuso C.2 Novas tecnologias desenvolvidas No contexto do Mogno, a fase de avaliação das novas tecnologias desenvolvidas ainda não foi executada no entanto foi planejada e também será conduzida de forma iterativa e incremental baseada no método Scrum, seguindo o Framework de Experimentação proposto por Basili [1] A repetição é um princípio muito importante que deve ser considerado em um experimento pois está diretamente relacionado com a reprodução dos resultados por outros investigadores. Tal repetição é importante porque implica que as variáveis imprevistas não estão afetando os resultados. Os resultados dos experimentos não podem ser amplamente aceitos sem que a repetição interna ou externa seja aplicada. Após a execução dos experimentos, será possível comprovar se: (i) a tecnologia é viável, (ii) se os passos da tecnologia são adequados, (iii) se a tecnologia é adequada ao contexto de um ciclo de vida e (iv) se a tecnologia é adequada ao contexto industrial. A. Avaliação Qualitativa VI. Resultados B. Lições Aprendidas com o uso da Abordagem Proposta planejamento, estruturação, adaptação e previsibilidade C. Impacto do ponto de vista prático e científico VII. Conclusão Este artigo apresentou uma proposta de execução ágil e um exemplo prático da mesma sobre uma metodologia empírica para análise de tecnologias de software. Os resultados apresentados aqui foram obtidos a partir da observação do Projeto Mogno executado em um ambiente acadêmico voltado para necessidades práticas da indústria madeireira e engenharia florestal unindo interesses de pesquisa na área da computação. As maior contribuição deste artigo foi integrar a abordagem ágil ao processo de concepção de tecnologias de software. Caso a tecnologia não exista e a demanda pela construção seja confirmada, tal processo de desenvolvimento seguindo métodos ágeis é uma prática comum sem nenhuma contribuição inovadora. Já a ideia de conduzir a avaliação de forma ágil é inovadora, no entanto ainda não foi investigada, tornando-se um trabalho futuro desta pesquisa. A. Limitações Várias limitações foram observadas neste estudo. Primeiro, a busca pelo desempenho de uma abordagem ágil aplicada a uma metodologia empírica para tecnologias de software está associada a um alto nível de abstração e o domínio no qual a metodologia foi aplicada exerce muitas influência nos resultados. Isso significa que é muito difícil isolar o método sem levar em consideração a análise do domínio de aplicação. Três tipos de limitações recorrentes são mencionadas na literatura quanto a estudos que abordam avaliações qualitativas: estudos de casos que são facilmente observados, já que é muito raro observar todas as TABLE IV Práticas Scrum adotadas ao longo das fases de concepção e construção e *avaliação de tecnologias candidatas ao reuso. Práticas Scrum Concepção Construção Fases Avaliação* Código & Testes Parcial Total Total Integração contínua Total Total Total Geração diária de uma Parcial Parcial Parcial versão do produto Reunião diária Total Total Total Ritmo de trabalho estimulado Total Total Total Projeto Incremental Total Total Total Programação ou análise Não foi Parcial Total em pares usado Real envolvimento dos Total Total Parcial stakeholders Código compartilhado Total Total Total Base unificada de código Total Total Total Equipe no mesmo Parcial Parcial Parcial espaço físico Planning Poker Total Total Total Reunião de retrospectiva Total Total Total do sprint Reunião de planejamento Total Total Total do sprint User stories Total Total Total Burndown Chart Total Total Total Papeis claros (Product Total Total Total owner, scrum master e scrum team) Product Backlog Total Total Total Sprint Backlog Total Total Total possíveis situações gerando fortes questionamentos quanto a validade espacial; as observações tomam tempo e este período é fortemente questionado quanto a validade temporal; e por último a seletividade das pessoas que fazem parte do processo. No caso desta pesquisa, ao selecionarmos o Mogno como projeto de observação, restringimos as pessoas aos participantes da equipe. Por mais que outros projetos fossem selecionados para o estudo de caso, não seriam pessoas aleatórias e sim o grupo previamente formado para o projeto. Já a seleção de projetos aleatórios é mais complicado ainda pois nem todas as instituições permitem investigações detalhadas de seus processos e métodos de seleção de tecnologias. B. Direções para futuras pesquisas Um outro tópico interessante é a integração coerente de métodos. Cañete-Valdeón, [3] comenta que essa área

10 10 27TH BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING, 2013 Figura 7. Total de pontos estimados para as user stories e efetivamente entregues por Sprint ao longo da fase de concepção e contrução do Projeto Mogno de pesquisa surgiu a partir da necessidade de se integrar métodos de forma segura. Como garantir então que dois ou mais métodos podem resultar em uma integração de sucesso? As abordagens formais adotadas por esta área de pesquisa podem ajudar a fortalecer evidências coerentes em relação a condução ágil da análise de tecnologias de software C. Trabalho Futuro A nossa agenda de pesquisa para este tópico envolve Agradecimentos À CAPES pelo apoio financeiro e aos pesquisadores Niro Higuchi e Adriano Nogueira, ambos do Instituto Nacional de Pesquisa da Amazônia (INPA) por compartilharem conhecimento a respeito de manejo e dinâmica florestal, por fornecerem dados para os experimentos e apoiarem a realização deste trabalho. Referências [1] V. Basili and R. Selbv. Paradigms for experimentation and empirical studies in software engineering. Reliability Engineering and System Safety, 32(1-2): , [2] Martin Blom. Is scrum and xp suitable for cse development? Procedia CS, 1(1): , [3] José Miguel Cañete Valdeón. How influential has academic and industrial research been in current software life cycles? a retrospective analysis of four mainstream activities. Inf. Softw. Technol., 55(2): , February [4] Arilo. C. Dias-Neto, Rodrigo O. Spínola, and Guilherme H. Travassos. Developing software technologies through experimentation: Experiences from the battlefield. In XIII Congresso Iberoamericano de Engenharia de Software (CIBSE), Cuenca, Equador, [5] Torgeir Dingsøyr, Sridhar Nerur, VenuGopal Balijepally, and Nils Brede Moe. A decade of agile methodologies: Towards explaining agile software development. J. Syst. Softw., 85(6): , June [6] Tore Dybå and Torgeir Dingsøyr. Empirical studies of agile software development: A systematic review. Inf. Softw. Technol., 50(9-10): , August [7] R. France and B. Rumpe. Model-driven development of complex software: A research roadmap. In 2007 Future of Software Engineering, FOSE 07, pages 37 54, Washington, DC, USA, IEEE Computer Society. [8] J. Hutchinson, M. Rouncefield, and J. Whittle. Model-driven engineering practices in industry. In Proceedings of the 33rd International Conference on Software Engineering, ICSE 11, pages , New York, NY, USA, ACM. [9] B. Kitchenham and S. Charters. Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE , Keele University and Durham University Joint Report, [10] B. A. Kitchenham, D. Budgen, and Pearl B. O. Using mapping studies as the basis for further research - a participant-observer case study. Inf. Softw. Technol., 53(6): , June [11] Maarit Laanti, Outi Salo, and Pekka Abrahamsson. Agile methods rapidly replacing traditional methods at nokia: A survey of opinions on agile transformation. Inf. Softw. Technol., 53(3): , March [12] Sômulo N. Mafra, Rafael F. Barcelos, and Guilherme H. Travassos. Aplicando uma metodologia baseada em evidência na definição de novas tecnologias de software. In XX Simpósio Brasileiro de Engenharia de Software, pages , Florianópolis, SC, October [13] Viljan Mahnič and Toma Hovelja. On using planning poker for estimating user stories. J. Syst. Softw., 85(9): , September [14] K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson. Systematic mapping studies in software engineering. In Proceedings of the 12th international conference on Evaluation and Assessment in Software Engineering, EASE 08, pages 68 77, Swinton, UK, UK, British Computer Society. [15] Mali Senapathi and Ananth Srinivasan. Understanding postadoptive agile usage an exploratory cross-case analysis. In Proceedings of the 2011 Agile Conference, AGILE 11, pages , Washington, DC, USA, IEEE Computer Society. [16] Forrest Shull, Jeffrey Carver, and Guilherme H. Travassos. An empirical methodology for introducing software processes. SIG- SOFT Softw. Eng. Notes, 26(5): , September 2001.