UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação"

Transcrição

1 UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Ferramenta para análise de utilização de Sistemas de Gerenciamento de Bugs em projetos de software livre Ronaldo Francisco Maia São Carlos - SP

2

3 Ferramenta para análise de utilização de Sistemas de Gerenciamento de Bugs em projetos de software livre Ronaldo Francisco Maia Orientadora: Prof a Dr a Renata Pontin de Mattos Fortes Monografia final de conclusão de curso apresentada ao Instituto de Ciências Matemáticas e de Computação ICMC-USP para obtenção do título de Bacharel em Ciência da Computação. Área de Concentração: Engenharia de Software USP - São Carlos Outubro de 2009

4

5 Resumo Ferramentas de software livre estão se tornando cada vez mais presentes no dia-a-dia das pessoas. Para desmistificar o processo envolvido no desenvolvimento de tais ferramentas, o projeto QualiPSo foi criado com o objetivo de realizar uma avaliação desse processo. No estudo realizado neste trabalho, evidenciou-se a importância dos Sistemas de Gerenciamento de Bugs (SGB) para a qualidade e sucesso do desenvolvimento dos projetos; como esses SGB estão inseridos nesse processo e sua utilização pelos usuários. Foi realizado também um estudo sobre as métricas levantadas no projeto QualiPSO, além de métricas existentes na literatura, servindo como ponto de partida para a reescrita da ferramenta Bicho, buscando auxiliar a avaliação de processos de software que utilizam SGB.

6

7 Sumário Lista de Figuras III Lista de Tabelas V 1 Introdução Objetivos do Trabalho Organização da Monografia Revisão Bibliográfica Métodos Ágeis Extreme Programming (XP) SCRUM Crystal Feature Driven Development Métodos Ágeis vs. Software Livre Desenvolvimento Orientado a Bugs Anatomia de um Bug Ciclo de Vida de um Bug Atividades de Garantia de Qualidade Ferramentas SGB Avaliação de Processos de Software O Modelo de Avaliação de Qualidade proposto no Qualipso Análise das Métricas

8 2.6 Considerações Finais Estado Atual do Projeto O Projeto Bicho Mudanças Aplicadas Frontends e Backends Interação Entre as Classes Configuração da ferramenta Avaliação Preliminar Data Warehouse Backend Interface Web Resultados Obtidos Conclusões e Trabalhos Futuros 35 5 Comentários Sobre o Curso 37 Referências Bibliográficas 39

9 Lista de Figuras 2.1 Capturas de telas apresentando campos de bugs do Bugzilla e Sourceforge Workflow para os bugs no Bugzilla e Trac (traduzidos a partir da documentação dos próprios SGB) Máquina de estados de um dos parsers da ferramenta Bicho Nova arquitetura da ferramenta Bicho Objetos do domínio Interação entre as classes Bicho, Frontend e Backend Exemplo de configuração da ferramenta Bicho Evolução dos estados dos bugs, por mês Evolução da atividade dos usuários, por mês

10

11 Lista de Tabelas 2.1 Características gerais de métodos de desenvolvimento ágeis, adaptado de (ABRAHAMSSON et al., 2002) Resumo dos dados de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009) Medidas extraídas de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009) Medidas extraídas do SGB do projeto stoq

12

13 1 1 Introdução Processo de Software é um conceito que tem sido investigado há mais de duas décadas por pesquisadores e profissionais envolvidos com desenvolvimento de software. Sommerville (2003) considera processo de software como um conjunto de atividades bem definidas que devem ser realizadas no decorrer do ciclo de desenvolvimento de um software. Essas atividades incluem, por exemplo, o planejamento, o levantamento de requisitos, o desenvolvimento, os testes do software desenvolvido, entre outras. Complementarmente são disponibilizadas diversas ferramentas, que buscam atingir um mesmo objetivo: o de facilitar e/ou melhorar o processo envolvido, de maneira a estimular que os erros humanos sejam reduzidos e que a automatização de certas tarefas auxiliem a produtividade e qualidade do produto em desenvolvimento. Entre as diversas ferramentas de apoio à melhoria do processo, estão os chamados bug trackers, ou Sistemas de Gerenciamento de Bugs (SGB), que auxiliam no gerenciamento de defeitos encontrados e no acompanhamento das melhorias necessárias no software que está sendo desenvolvido (DELUGACH, 2007). Os SGB são muito utilizados em processos de software cujos responsáveis se preocupam com a qualidade do produto desenvolvido, pois oferecem meios que possibilitam a discussão, registro e rastreamento dos problemas encontrados, visando aprimoramento e produtividade na comunicação das pessoas que podem participar no desenvolvimento do projeto de software. Dessa forma, os SGB apoiam as diversas fases do processo de software. Os SGB têm um papel importante no processo de desenvolvimento de projetos de software livre pois proporcionam um canal de comunicação entre desenvolvedores que, muitas vezes, não se encontram em um mesmo local, além de oferecerem à comunidade de usuários um histórico com o progresso do desenvolvimento e de planejamentos futuros (ANVIK; HIEW; MURPHY, 2006; BLEEK; FINCK, 2004). O desenvolvimento deste trabalho está inserido no contexto de um projeto maior, o projeto QualiPSo (Quality Platform for Open Source Softwares) 1, que envolve diversas empresas e instituições espalhadas pela Europa, China e Brasil, e cuja motivação é a desmistificação de ferramentas de software livre, principalmente no que se refere à 1

14 2 confiabilidade e qualidade do processo envolvido no desenvolvimento de tais ferramentas (QUALIPSO, 2009). Assim, um modelo de processo de software livre tem sido definido: OMM - The QualiPSo Open Maturity Model, bem como um conjunto de indicativos que possam ser obtidos por meio de métricas e verificações, para avaliar a aderência de um determinado processo ao OMM. 1.1 Objetivos do Trabalho O principal objetivo deste projeto é investigar SGB de apoio a processos de software livre, visando evidenciar dados de uso dessas ferramentas que possam demonstrar informações sobre qualidade de processo por meio de métricas estudadas na literatura. Para tanto, foram estabelecidos os seguintes objetivos específicos: Analisar a ferramenta existente Bicho para acompanhamento de SGB, uma vez que ela já estava em desenvolvimento por membros do projeto Qualipso; Estudar as métricas levantadas no desenvolvimento do projeto QualiPSo e na literatura, e como as mesmas podem ser extraídas de diversos SGB; Desenvolver a nova versão da ferramenta Bicho para auxiliar na coleta dessas métricas. 1.2 Organização da Monografia Como um tema importante desta pesquisa é sobre processo de software, no Capítulo 2, são apresentados os métodos ágeis, que foram estudados, visando identificar como eles se comparam ao processo de software livre. Uma vez que SGBs são as ferramentas objeto de estudo deste trabalho, são também descritos nesse capítulo os SGBs estudados na bibliografia, a forma como eles são utilizados nos diversos projetos de software, e quais elementos eles possuem em comum. Finalmente, no Capítulo 2, são apresentadas também as métricas envolvendo SGB e os dados coletados de quatro projetos de software, os quais são discutidos de modo a demonstrar as indicações qualitativas de processo, que podem ser obtidas desses dados. No Capítulo 3, que apresenta o estado atual de desenvolvimento deste projeto, é feita também uma avaliação sobre a ferramenta de análise de SGB denominada Bicho (que foi proposta no âmbito do projeto QualiPSo) e sobre o trabalho desenvolvido neste projeto de graduação, que foi realizado visando a análise das métricas levantadas no projeto QualiPSo, e como essas podem ser coletadas.

15 3 Finalmente, no Capítulo 4 são apresentadas as considerações finais do projeto desenvolvido e no Capítulo 5 são reportados os comentários do aluno sobre o curso de graduação.

16 4

17 5 2 Revisão Bibliográfica No contexto de processo de software, a literatura apresenta diversos métodos de desenvolvimento de software, que descrevem as atividades definidas e as características de como a adoção dos métodos se distingue dos demais. Os processos de software livre têm muitas semelhanças com os métodos ágeis, assim, neste capítulo são apresentados uma breve introdução aos métodos ágeis e como o processo de software livre pode ser considerado um método ágil. A seguir é discutido o estudo realizado sobre os conceitos relacionados aos SGB, bem como a relação desses com o processo de desenvolvimento em projetos de software livre. Além disso, as características principais de SGB existentes são discutidas e ao final, é apresentado como uma avaliação de processos de software pode ser realizada utilizando dados de SGB e o modelo de avaliação proposto no projeto Qualipso. 2.1 Métodos Ágeis Os Métodos Ágeis surgiram como uma alternativa para contornar os diversos problemas existentes nos métodos tradicionais de desenvolvimento de software, nos quais o trabalho começa com a documentação completa dos requisitos, seguida do projeto, implementação e manutenção (COHEN; LINDVALL; COSTA, 2004). Entre esses problemas destaca-se, por exemplo, a possibilidade dos usuários mudarem de idéia após um longo período de levantamento de requisitos, em um momento em que a alteração implica em um custo muito alto para o projeto. O termo Métodos Ágeis surgiu no início de 2001, com a formação de uma aliança envolvendo 17 grupos de especialistas em métodos de desenvolvimento interativos e incrementais (COHEN; LINDVALL; COSTA, 2004), mas Larman e Basili (2003) mostram que a aplicação dessas técnicas data de meados dos anos 50. Dessa aliança, surgiu o Agile Manifest que diz (BECK et al., 2001): Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Por meio deste trabalho, passamos

18 6 a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação Colaboração com o cliente mais que negociação de contratos Respostas a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos elementos descritos à direita na lista acima, valorizamos mais os elementos à esquerda. Abrahamsson et al. (2002) resume os métodos ágeis como tendo as seguintes características: Incremental: os lançamentos ocorrem em ciclos rápidos de desenvolvimento. Cooperativo: o cliente e os desenvolvedores trabalhando em próximos e em conjunto, constantemente. Direto: o método é fácil de aprender e modificar, bem documentado. Adaptativo: por ser fácil de realizar mudanças de última hora. Cohen, Lindvall e Costa (2004) afirmam que enquanto as técnicas ágeis têm práticas e ênfases diferentes, elas compartilham características comuns, incluindo desenvolvimento iterativo, com foco na interação, comunicação e redução de artefatos intermediários: O desenvolvimento em iterações permite ao time de desenvolvedores se adaptar rapidamente a mudanças nos requisitos. Trabalhar em um lugar próximo, e com foco na comunicação significa que os times podem tomar decisões e agir imediatamente, não precisando esperar correspondências. A redução da produção de artefatos intermediários, que não agregam valor ao produto final, leva a possibilidade de mais recursos serem aplicados ao desenvolvimento. A seguir são apresentados brevemente alguns métodos ágeis existentes, bem como são descritas suas características Extreme Programming (XP) O XP é um dos métodos ágeis mais populares e documentados (COHEN; LINDVALL; COSTA, 2004), e é uma combinação de idéias e práticas adquiridas de métodos previamente existentes (ABRAHAMSSON et al., 2002). As 12 praticas do método XP, conforme descritas por Beck (1999) são:

19 7 I Planejamento: os clientes decidem o escopo e tempo do lançamento baseados em estimativas fornecidas pelos programadores, que desenvolvem somente as funcionalidades exigidas na iteração. II Lançamentos pequenos: o sistema entra em produção em poucos meses, antes de resolver o problema como um todo. Os novos lançamentos são feitos frequentemente, diária ou mensalmente. III Metáfora: a forma do sistema é definida por uma metáfora, ou um conjunto de metáforas, compartilhadas entre cliente e programadores. IV Projeto simples: a qualquer momento, o projeto contém todos os testes, não contém código duplicado, e possui a menor quantidade possível de classes e métodos. V Testes: os desenvolvedores escrevem testes a todo momento. Esses testes são reunidos e todos devem ser satisfeitos com sucesso. Os clientes escrevem testes funcionais para os casos de uso (stories) da iteração. VI Refatoração: o projeto do sistema evolui através de transformações no projeto atual, desde que os testes não falhem. VII Programação em pares: todo o código é escrito pelos desenvolvedores organizados em pares, compartilhando um mesmo computador. VIII Integração contínua: o código novo deve ser integrado ao sistema em poucas horas. Quando integrado, o sistema deve ser reconstruído, e os testes devem continuar a ser satisfeitos. IX Autoria coletiva: qualquer programador pode melhorar o código em qualquer parte do projeto, ao encontrar uma oportunidade. X Cliente presente: o cliente está presente junto à equipe o tempo todo. XI Semanas de 40 horas: ninguém pode realizar horas extras por duas semanas consecutivas. Quaisquer horas extras são um sinal de problemas que devem ser resolvidos. XII Área de trabalho coletiva: a equipe trabalha em uma sala ampla, com cubículos espalhados ao redor, e a programação em pares é realizada em um computador no centro SCRUM Junto com o XP, o Scrum é um dos métodos ágeis mais populares (COHEN; LIND- VALL; COSTA, 2004). Schwaber (1995) descreveu que o Scrum pressupõe que processos

20 8 de desenvolvimento são imprevisíveis e complicados. Dessa forma o método é definido como um conjunto de atividades que incluem ferramentas e técnicas conhecidas com o melhor que uma equipe de desenvolvimento pode planejar para construir sistemas. O método Scrum inclui 3 fases (SCHWABER, 1995): Pré-jogo: esta fase inicial é composta pelas seguintes atividades: Planejamento - nessa fase é realizada a definição de um novo lançamento com base em um backlog, além da estimativa do tempo necessário e do custo. Se um novo sistema está sendo desenvolvido, essa fase consiste na conceitualização e análise. Se um sistema existente está sendo melhorado, essa fase consiste em uma análise limitada. Arquitetura - definição de como os itens do backlog serão implementados, incluindo as modificações na arquitetura e um projeto em auto nivel. Jogo: esta é a principal fase do processo Scrum. Nela são realizados os Sprints de desenvolvimento, nos quais novas funcionalidades são desenvolvidas, respeitando as variáveis tempo, requisitos, qualidade e custo. A combinação dessas variáveis define o fim desta fase. Pós-jogo: esta fase representa o final do método. Nela ocorre o fechamento, que consiste na preparação para o lançamento, incluindo documentação, testes e o lançamento propriamente dito. 1995): Além disso, o método Scrum apresenta as seguintes características (SCHWABER, Objetivos flexíveis : o conteúdo do produto final é ditado pelo ambiente. Agenda flexível : o produto final pode ser necessário antes ou depois do que planejado. Equipes pequenos : cada equipe não tem mais do que 6 membros e existem várias equipes em um mesmo projeto. Revisões frequentes : o progresso de uma equipe é revisto conforme a complexidade e risco exigirem assim o exigirem. Colaboração : a colaboração dentro e entre as equipes é esperada durante todo o projeto. Orientada a objetos : cada equipe trabalha em um conjunto de objetos relacionados, com interfaces e comportamentos claros.

21 Crystal Desenvolvido por Alistair Cockburn, no início dos anos 90, o método foi proposto como uma solução àquilo que acreditava ser um dos maiores obstáculos ao desenvolvimento de software: a comunicação (COHEN; LINDVALL; COSTA, 2004). Crystal é na verdade uma família de métodos classificados por cor, devendo ser escolhidos de acordo com o tamanho do projeto (ABRAHAMSSON et al., 2002). Todos os métodos pertencentes à família começam com um conjunto básico de papéis, técnicas e notações, e conforme a criticidade do projeto aumenta, o rigor do método acompanha. O processo usa ciclos de desenvolvimento incremental com um período máximo de quatro meses. É dada enfase a comunicação e cooperação, e leva em consideração o talento e capacidade dos desenvolvedores envolvidos. A metodologia não restringe as práticas e ferramentas que podem ser usadas, podendo também ser empregadas práticas de outros métodos ágeis como o XP ou Scrum Feature Driven Development A abordagem Feature Driven Development (FDD) não cobre todo o processo de desenvolvimento, mas da ênfase às fases de projeto e construção. Assim como o Crystal, o método foi projetado para ser empregado junto à outras atividades, mesmo que de outros métodos (ABRAHAMSSON et al., 2002). No FDD o processo começa com o desenvolvimento de um modelo, a partir do qual um conjunto de funcionalidades é identificado e depois organizado em pacotes. Esses pacotes são então distribuídos entre os desenvolvedores e as funcionalidades são planejadas com mais detalhes, implementadas, testadas e integradas Métodos Ágeis vs. Software Livre A Tabela 2.1 apresenta um resumo das principais características dos métodos ágeis apresentados. Embora possua algumas características distintas como a distribuição geográfica dos desenvolvedores e o tamanho das equipes, podemos observar que em processos de software livre, várias das idéias propostas pelos métodos ágeis são praticadas, tais como: lançamentos rápidos e frequentes, trabalho conjunto entre desenvolvedores e clientes (que muitas vezes também são desenvolvedores) e requisitos em constante elaboração, a medida que o software evolui (WARSTA; ABRAHAMSSON, 2003). Levando em consideração as características dos métodos ágeis, atribuídas por Abra-

22 10 Características Método Principais Especiais XP Desenvolvimento dirigido pelo cliente, times pequenos, builds diários. Scrum Times de desenvolvimento independentes, pequenos e autoorganizados, ciclos de lançamento de 30 dias. Crystal Família de métodos, cada um com os mesmos princípios. Técnicas, papéis, ferramentas e padrões variam. FDD Processo com cinco passos, desenvolvimento baseado em componentes (funcionalidades) orientados a objetos, iterações curtas (de horas a duas semanas) Refatoração - redesenho constante do sistema, para melhorar a performance e respostas a mudanças. Obriga uma mudança de paradigma do definido e repetível para a visão de desenvolvimento do Scrum Habilidade de selecionar o método mais apropriado baseado no tamanho do projeto e criticidade. Simplicidade do método, desenha e implementa o sistema por funcionalidades, modelagem de objetos. Tabela 2.1: Características gerais de métodos de desenvolvimento ágeis, adaptado de (ABRAHAMSSON et al., 2002). hamsson et al. (2002), podemos observar que o modelo de desenvolvimento de software livre também satisfaz as mesmas propriedades, que são (WARSTA; ABRAHAMSSON, 2003): Incremental: conforme notado por Raymond (1999), ter lançamentos rápidos e frequentes é uma das características de projetos de software livre. Cooperativo: a colaboração é a principal idéia por trás do software livre e é muito incentivada, mesmo que não seja por meio de código. Testes, documentação, traduções e divulgação também são formas de cooperação. Direto: embora não seja bem documentado, o modelo de desenvolvimento é de fácil aplicação e modificação. Adaptativo: os produtos de software livre possuem requisitos que estão em constante mudança, sempre se adaptando às necessidades dos seus usuários. Portanto o processo de software permite uma fácil adaptação a essas mudanças. Dessa forma, com base nas propriedades apresentadas, concluímos que processos de software livre pode ser considerados um tipo de método ágil. A seguir, é apresentado um modelo de processo mais detalhado de software livre, principalmente no que diz respeito ao gerenciamento de bugs ou requisitos.

23 Desenvolvimento Orientado a Bugs Reis e Fortes (2002) descrevem o processo utilizado nos projetos da Mozilla Foundation 1 como um Desenvolvimento Orientado a Bugs, no qual cada mudança realizada na base de código é feita como uma solução para um bug. Esses bugs não necessariamente representam um defeito, mas também podem ser planejamentos de melhorias no software ou pedidos de novas funcionalidades por seus usuários. Dessa forma, o ciclo de desenvolvimento de qualquer projeto de software pode ser iniciado com o controle de bugs. Já Halloran e Scherlis (2002) apresentam diversas ferramentas de software livre e evidenciam que praticamente todas usam algum tipo de SGB acessível ao público em geral. Além disso, descrevem brevemente o processo envolvido em relação aos bugs: Usuários relatam a existência de defeitos ou pedidos de melhorias, e cada um desses relatos se torna uma espécie de lista de discussões focada somente nesse ponto. Algumas dessas discussões são resolvidas rapidamente (como inválidas, por exemplo) e outras podem durar semanas ou até mais tempo, e podem envolver dezenas de mensagens. As ferramentas de gerenciamento de bugs fornecem o veículo para contribuições de código-fonte de programadores sem privilégios de alterações no repositório do projeto. Além disso, a ferramenta de gerenciamento de bugs tem um papel na gerência do projeto, permitindo, por exemplo, que problemas específicos (como desempenho, funcionalidade, reparos de problemas) sejam relacionados a um Planejamento para Lançamento Estável, oferecendo assim um ponto de partida para um lançamento futuro. Nesse contexto, este projeto, aliado às metas do Qualipso, também considera que as ferramentas SGB são essenciais para se apresentar um desenvolvimento eficiente e de software com qualidade Anatomia 2 de um Bug Cada ferramenta de SGB distinta possui uma definição diferente das informações que compõem um bug. Em geral, observa-se que essas informações podem ser pré-definidas pela própria ferramenta, ou ser atributos personalizados com valores específicos ao processo do projeto que os usa Os termos anatomia e ciclo de vida, comumente utilizados nos artigos que tratam desse assunto, tem origem provável na documentação do Bugzilla e fazem uma analogia à biologia dos insetos.

24 12 Alguns desses atributos possuem informações sobre a classificação do bug como prioridade e severidade, se é um defeito ou uma melhoria, a qual componente esse bug se aplica, entre outros. Há alguns valores que não mudam com o tempo, como o autor do relato e a data de abertura, e outros que podem ter mudanças mais freqüentes, como as pessoas envolvidas ou o estado atual do bug (ANVIK; HIEW; MURPHY, 2006). Embora muitas vezes diferentes, podemos observar que algumas dessas informações são recorrentes aos diversos SGB. A Figura 2.1 ilustra alguns desses campos nos SGB Bugzilla e Sourceforge. (a) Bugzilla (b) Sourceforge Figura 2.1: Capturas de telas apresentando campos de bugs do Bugzilla e Sourceforge A seguir, são descritas as informações básicas que os SGB apresentam em comum, mesmo que de diferentes formas (ANVIK; HIEW; MURPHY, 2006), (DELUGACH, 2007), (BUGZILLA, 2009), (TRAC, 2009): Descrição e Detalhes: os bugs sempre têm uma descrição simples e breve que ajuda a identificá-los rapidamente em uma lista, além de uma descrição mais detalhada de como reproduzir o problema, no caso de um defeito, ou melhorias desejadas, no caso de um pedido de funcionalidade nova. Estado e Resolução: o estado reflete a situação atual do bug e pode ter os seus valores resumidos em dois estados mais abrangentes: aberto ou fechado. Enquanto o bug estiver no estado aberto, ele pode ser considerado novo, ainda não ter sido confirmado como um bug de fato ou já estar atribuído para algum desenvolvedor, entre outros. Já no caso de um bug no estado fechado, ele pode ter sido

25 13 resolvido (com uma alteração efetiva no código), marcado como um bug duplicado de outro, ou sequer ser um problema de fato, o que o torna inválido. Relator: pessoa (usuário ou desenvolvedor) que reportou bug (problema ou requisição de uma melhoria). Responsável: desenvolvedor que irá trabalhar em uma solução para o bug. Anexos: arquivos anexos geralmente contêm informações não textuais como uma captura de tala de um problema ou um patch (solução) para o bug. Comentários: campos de texto livre no qual cada usuário pode expressar sua opinião em uma discussão ou adicionar informações que complementem a descrição. Revisões sobre soluções propostas geralmente acontecem na forma de comentários no próprio bug. Com base nessas informações, as ferramentas SGB se diferenciam conforme se especializam para atender diferentes necessidades de projeto. O Bugzilla, por exemplo, oferece um controle mais detalhado para o tempo gasto no desenvolvimento dos bugs, permite criar uma relação de dependência entre os bugs, e definir um lançamento alvo, para quando um bug deverá estar corrigido. (BUGZILLA, 2009) Ciclo de Vida de um Bug Desde sua criação até a resolução e fechamento, um bug passa por diversas fases, dependendo do processo adotado pelos desenvolvedores do projeto. Em geral, essas fases correspondem aos diversos conjuntos de estados pelos quais os bugs podem ser qualificados. Anvik, Hiew e Murphy (2006) relatam um exemplo desse ciclo de vida para um bug do projeto Eclipse 3 : Quando um bug é submetido ao repositório do Eclipse, o seu estado é ajustado para novo. Assim que um desenvolvedor foi designado ou assumiu a responsabilidade pelo bug o estado muda para atribuído. Quando um bug é fechado seu estado passa então para resolvido. Ele pode ainda ser marcado como verificado ou ser fechado para sempre ( fechado ). Um bug pode ser resolvido de diversas maneiras e essa informação é armazenada no campo resolução. Se a solução resultou em uma mudança na base de código o bug é resolvido como corrigido. Quando o desenvolvedor determina que já existe um relato equivalente para o bug, o mesmo é marcado como duplicado. Se 3

26 14 o desenvolvedor não conseguiu reproduzir o bug, como descrito, ele marca a resolução como funciona para mim. Se o bug descreve um problema que não será resolvido, ou sequer é um problema, a resolução será não será resolvido ou inválida, respectivamente. Um bug previamente resolvido pode ser reaberto em um outro momento, e terá o seu estado ajustado para reaberto. Assim como os campos definidos em um bug podem variar de ferramenta para ferramenta, o mesmo ocorre com as fases de sua vida. A Figura 2.2 mostra o fluxo dos estados nos SGB Bugzilla 4 e Trac 5. (a) Bugzilla (b) Trac Figura 2.2: Workflow para os bugs no Bugzilla e Trac (traduzidos a partir da documentação dos próprios SGB) É possível observar que na mudança entre os estados possíveis, certas atividades podem estar presentes, como: A confirmação de um bug ainda não confirmado, na passagem do estado Não Confirmado para o estado Novo 4 Adaptado de 5 Adaptado de

27 15 O processo de revisão ao qual os patches são submetidos antes de serem aplicados ao código, entre os estados Atribuído e Resolvido. A verificação da solução por parte da equipe de garantia de qualidade após o bug ter sido resolvido, o que pode levar ao estado Verificado se a equipe estiver satisfeita, ou ao estado Reaberto, caso algum problema ainda persita. Essas atividades de garantia de qualidade são apresentadas com mais detalhes a seguir Atividades de Garantia de Qualidade Conforme um bug avança em seu ciclo de vida, pode-se observar que atividades auxiliares estão envolvidas nesse processo. As principais atividades são a triagem pela qual os novos bugs passam, o processo de revisão e aprovação para as soluções propostas e a garantia de qualidade que é realizada após a aplicação da solução. Essas atividades são descritas a seguir. Triagem Uma das vantagens da natureza aberta de SGB em projetos de software livre é a possibilidade de que uma quantidade maior de bugs seja identificada e reportada pelos usuários. Em contrapartida, ela vem acompanhada de uma desvantagem : cada bug que é reportado deve passar por uma triagem a fim de assegurar que ele é realmente válido e atribuí-lo a um desenvolvedor apropriado (ANVIK; HIEW; MURPHY, 2006). Considerada uma atividade relacionada com a Garantia de Qualidade 6, a triagem envolve um trabalho nos bugs reportados, com tentativas de reprodução, podendo invalidálos quando as descrições fornecidas não são suficientes ou o problema é, na verdade, um comportamento esperado. Uma melhor distribuição dos novos bugs entre os desenvolvedores disponíveis também é uma das responsabilidades da triagem (REIS; FORTES, 2002). Anvik, Hiew e Murphy (2005) mostram que um dos desafios de se ter um SGB aberto é a quantidade de bugs que são reportados diariamente: o Firefox 7, por exemplo, recebe uma média diária de 8 bugs perto de um lançamento, com o máximo de 37 em um dia. Já o Eclipse tem uma média de 48 bugs por dia chegando a ter 192 perto de um lançamento. Dos bugs do Eclipse, 39% não contribuem para a melhora do produto, enquanto no Firefox esse número chega a 56%. 6 Do inglês, Quality Assurance 7

28 16 Revisão de código Em sua investigação sobre o processo envolvido na Mozilla Foundation, Reis e Fortes (2002) descrevem o processo de revisão e aprovação pelas quais as mudanças no código passam antes da integração como uma das características mais importantes: O processo de revisão funciona da seguinte maneira: o desenvolvedor trabalhando no código gera um patch, que consiste em um arquivo de texto descrevendo linha por linha as diferenças entre a versão local do desenvolvedor e a ultima versão do código do repositório. Esse patch é então anexado ao bug no Bugzilla e um pedido de revisão é feito. O revisor, que pode ser o dono do módulo ou alguém familiar com o código, irá então ler as mudanças de uma maneira crítica e aprovar ou sugerir novas alterações. Essa revisão é feita em comentários no próprio bug e podem descrever mudanças necessárias, questões sobre partes não esclarecidas ou recomendações sobre outros aspectos do patch (impactos no desempenho, dependências ou problemas relacionados). Validação das Mudanças Além da triagem já descrita, outra responsabilidade da Garantia de Qualidade é a realização de testes para assegurar que a solução aplicada realmente soluciona o problema descrito, e que novos problemas não foram introduzidos. Esses testes não são necessariamente realizados pela própria equipe de desenvolvedores, e podem ser realizados também por voluntários, smoke testers ou testes funcionais automáticos (REIS; FORTES, 2002). O termo Smoke tests descreve o processo de validação das mudanças no código antes desses serem integrados efetivamente no código do produto. Depois da revisão de código, smoke testing é o método mais rentável para identificar e corrigir defeitos no software (MICROSOFT, 2009). Conforme evidenciado na literatura, existe um consenso de que os SGB exercem um papel importante no processo de desenvolvimento de projetos de software livre, sendo muitas vezes a principal ferramenta utilizada na gerência de tais projetos. 2.3 Ferramentas SGB Para apoiar o processo de gerência de bugs, as ferramentas existentes possuem características similares. A partir de um estudo das ferramentas disponíveis, pode-se classificálas em dois tipos: as presentes em forges como o SourceForge e Google Code e as stan-

29 17 dalones, em que o usuário (ou projeto) interessado deve ter uma instalação própria para poder utilizá-lo. Como exemplos de forges temos o já citado SourceForge, além do Launchpad 8 e Google Code 9. Para os standalones, fora o popular Bugzilla, Mantis 10 e Trac 11 são outros SGB usados por projetos de software livre. Koru e Tian (2004) afirmam que em projetos de software livre de pequena escala, os desenvolvedores geralmente tomam nota dos defeitos encontrados em arquivos de histórico ou planilhas, ou os arrumam sem manter nenhum controle. Já Krishnamurthy (2002), em seu estudo sobre os 100 projetos mais maduros disponíveis no Sourceforge, chegou à conclusão de que a maioria dos programas de software livre é desenvolvida por um pequeno grupo de indivíduos. Pode-se concluir que projetos de pequeno porte geralmente utilizam algum tipo de forge pela simplicidade e facilidades oferecidas. Esses forges costumam oferecer diversas funcionalidades necessárias ou úteis ao processo de desenvolvimento, como ferramentas para controle de versões, documentação, listas de discussões, entre outras. Koru e Tian (2004) ainda descrevem que projetos de médio a grande porte, ou aqueles que envolvem mais do que apenas alguns desenvolvedores por um período curto de tempo, necessitam de um controle mais organizado sobre os defeitos, e que a maioria dos projetos de grande porte de que têm conhecimento usam ferramentas standalones, como o Bugzilla. Os SGB standalones são mais atrativos para projetos de maior porte ou mesmo empresas com desenvolvimento de software proprietário. Uma das desvantagens no uso de forges para esses projetos é a dependência de ferramentas que estão fora de seu controle e podem deixar de funcionar ou não estar disponíveis em algum momento crítico. Outro atrativo é a possibilidade de adaptar a ferramenta a necessidades específicas do projeto, como algum workflow diferenciado, ou restrições maiores a certos tipos de usuários, o que dificilmente é possível em ferramentas mais genéricas como os forges. 2.4 Avaliação de Processos de Software Com o decorrer do processo de desenvolvimento e o uso das ferramentas de apoio (entre elas os SGB), dados importantes sobre o processo são gerados e podem ser usados para realizar uma avaliação sobre o mesmo. Esses dados podem ser utilizados individualmente ou até mesmo combinados, para uma melhor aferição sobre como as ferramentas envolvidas 8 https://launchpad.net/

30 18 se relacionam. Bachmann e Bernstein (2009) afirmam, no entanto, que pouca informação sobre a qualidade desses dados está disponível, embora sejam muito utilizados em pesquisas. Essa qualidade é definida como a porcentagem dos dados disponíveis que realmente possuem informações relevantes para realizar a avaliação. A seguir são apresentadas as medidas características de processo envolvendo SGB e controle de versão, levantadas por Bachmann e Bernstein (2009): M-I Mudanças de estado por bug: as mudanças de estado em bugs são uma boa indicação para o grau de colaboração e a existência de um processo definido para a manipulação de bugs. M-II Comentários por bug: o número de comentários é um bom indicador para a atividade da comunidade, mas também pode ser um sinal de uma má descrição do bug. Bugs com vários comentários devem, portanto, ser analisados cuidadosamente. M-III Anexos por bug: os arquivos anexos podem ser muito úteis para um desenvolvedor resolver um problema, logo, anexos são um bom sinal de qualidade do relato. M-IV Média de bugs abertos por usuário: quanto maior a quantidade de bugs abertos por um usuário, melhor é a qualidade dos bugs, devido ao aprendizado que o usuário obtém a cada novo bug, como qual informação é relevante para os desenvolvedores solucionarem o problema. Melhores descrições do problema levam a uma resolução mais eficiente, logo, quanto maior esse valor, mais rápido os bugs podem ser resolvidos. M-V Relação de usuários que alteram estados de bugs por desenvolvedor: essa relação mostra o quão aberto é o acesso ao SGB. No caso ideal, o desenvolvedor que resolve um bug é o mesmo que o marca como resolvido, e mais tarde, alguém valida a solução e finalmente, alguém marca como fechado. Nesse caso, um máximo de três pessoas diferentes modificariam o estado do bug. M-VI Relação de usuários que reportam bugs por desenvolvedor: quanto maior a comunidade, maior é a quantidade de usuários que abrem bugs. Um valor mais alto não necessariamente é um mau indicador, mas quanto menor esse número, maiores as chances do desenvolvedor dar retorno para bugs descritos de uma forma incompleta. M-VII Média de bugs por desenvolvedor: Quanto mais bugs um desenvolvedor se envolver, maior sua experiência e desenvolvedores experientes são de grande valor para um projeto. Portanto esse valor também é um indicador da experiência na comunidade de desenvolvedores.

31 19 M-VIII Média de bugs resolvidos por desenvolvedor: de forma similar, quanto mais bugs um desenvolvedor já resolveu, maior é sua experiência dentro de um projeto. Em um estudo de Wang, Guo e Shi (2007) sobre a evolução de sistemas de software livre, foi definido um conjunto de métricas relacionadas a SGB muito similar às métricas citadas. A Tabela 2.2 apresenta um resumo dos dados presentes nos SGB de projetos de software livre, enquanto a Tabela 2.3 mostra os valores para algumas das métricas definidas. (BACHMANN; BERNSTEIN, 2009) Apache Eclipse Gnome OpenOffice Período considerado 18/03/ /04/ /10/ /02/ /05/ /09/ /03/ /02/2008 Total de Bugs Bugs resolvidos Bugs duplicados Relatores Alteradores de estado Comentários Desenvolvedores Tabela 2.2: Resumo dos dados de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009) Apache Eclipse Gnome OpenOffice Taxa de bugs resolvidos 28,80% 52,16% 26,40% 38,93% Taxa de bugs duplicados 12,39% 13,03% 33,56% 16,12% Taxa de bugs inválidos 34,46% 12,76% 4,32% 19,46% Mudanças de estado por bug 1,77 1,83 1,35 2,93 Comentários por bug 3,58 4,32 2,95 6,53 Alteradores de estado por desenvolvedor 12,27 27,94 7,54 29,10 Relatores por desenvolvedor 46,80 100,73 105,50 161,53 Bugs por desenvolvedor 66, ,33 285,50 728,17 Bugs resolvidos por desenvolvedor 19,19 600,58 75,38 283,49 Tabela 2.3: Medidas extraídas de SGB para projetos de software livre, adaptado de (BACHMANN; BERNSTEIN, 2009)

32 20 Esses dados nos permitem entender melhor o processo que há por trás de cada projeto de software livre, no entanto, deve-se sempre levar em consideração as características individuais de cada projeto como a quantidade de desenvolvedores, o público alvo e a quantidade de usuários, idade do projeto, tamanho da base de código, entre outras. Nos dados apresentados, podemos destacar, por exemplo, os valores altos para a relação de bugs por desenvolvedor (M-VII) e de usuários que reportam bugs por desenvolvedor (M-VI). Além de evidenciarem o elevado número de usuários, esses valores altos são indícios de que o processo está sendo prejudicado, seja pela baixa qualidade dos bugs reportados e o tempo gasto pelos desenvolvedores para tentar identificar esses problemas mal descritos, ou pela dificuldade em identificar bugs duplicados, entre outros. Outro dado interessante é o número de mudanças de estado (M-I). Em um processo bem definido, espera-se que um bug passe por várias fases desde sua criação até a finalização, conforme descrito na Seção 2.2. Esse valor não necessariamente deve ser grande, mas deve estar próximo do número de mudanças de estado pelo qual se espera que um bug passe. Por exemplo, no caso de um processo onde um bug, após aberto, deve ser designado a um desenvolvedor e após a resolução ele deve ser verificado, espera-se que o valor de M-I esteja próximo de 3. Conclui-se assim que os SGB são uma boa fonte de informação acerca do processo de desenvolvimento empregado em sistemas de software livre, porém, por cada projeto ter características singulares, deve-se levar em consideração as propriedades de cada um, tanto do processo utilizado quanto do produto sendo desenvolvido. 2.5 O Modelo de Avaliação de Qualidade proposto no Qualipso Conforme o movimento Open Source evolui e produtos de software livre ganham popularidade, espera-se que os requisitos de qualidade sobre esses produtos aumentem, e isso traz a necessidade de se estabelecer o que é qualidade em processos de desenvolvimento de software livre. Produtos comerciais geralmente exibem certificados de qualidade ou alegam aderência à padrões bem estabelecidos, como o ISO9001. No entanto, para projetos de software livre, pode não ser fácil de se obter tal certificação, pois elas exigem documentação detalhada, organização de responsabilidades claramente definidas, entre outros requisitos. A satisfação desses requisitos se torna difícil uma vez que projetos de software livre são desenvolvidos por pessoas espalhadas geograficamente e sem uma infra-estrutura ou ambiente formal definido.

33 21 Com base nisso, o projeto Qualipso desenvolveu, baseado no modelo CMMI 12, um modelo de avaliação denominado Qualipso OpenSource Maturity Model (OMM). Esse modelo é o resultado da comparação dos elementos de confiança (TrustWorthy Elements - TWE) de processos de desenvolvimento de software livre e dos TWE encontrados no CMMI, e da seleção dos elementos que são necessários ou que estão faltando nos dois modelos. Utilizando o método Goal, Question, Metric (GQM) (BASILI; CALDIERA; ROM- BACH, 1994), foram definidas métricas para avaliar os diversos elementos de confiança definidos no OMM. A seguir são apresentadas as métricas relacionadas aos sistemas de apoio utilizados em processos de software, e que de certa forma permitem uma coleta automática por meio de ferramentas especializadas. Essas métricas podem ser indicadores importantes da qualidade em processos de software livre, porém é necessário um estudo mais profundo para avaliar a viabilidade de coleta dessas informações Análise das Métricas Em (WITTMANN et al., 2008) foi feito um levantamento de várias métricas de processo de software baseado nos elementos de confiança definidos no OMM. A seguir, essas métricas são classificadas pela área de aplicação e, ao mesmo tempo, são propostas algumas medidas equivalentes (ou complementares) que podem ser extraídas de SGB. Código Fonte Essas são medidas que podem ser obtidas realizando uma análise do código fonte ou do histórico de mudanças do repositório. M1 Número de autores de mudanças distintos. Da mesma forma que temos os autores em sistemas de controle de versões, temos os bug reporters em SGB. Poderiamos ainda fazer essa medida usando os criadores de patches, o que pode ser uma informação mais valiosa que os próprios commiters, uma vez que em projetos de maior porte, são poucos os usuários que têm permissão para aplicar as modificações. M2 Percentual de atividade (número de alterações em um certo período). Podemos medir o percentual de atividade em SGB também, analisando a quantidade de bugs abertos, comentários inseridos ou patches anexados aos bugs. 12 Capability Maturity Model Integration

34 22 M3 Número de alterações normalizado (usando o número de contribuições dos maiores contribuidores). Da mesma forma que em M2, podemos usar as atividades dos usuários nos SGB. M4 Autoria dos módulos (Número de módulos escrito por cada usuário) M5 Liderança de código (Percentagem do número de módulos escrito por autor) M6 Número de desenvolvedores ativos que se tornam Core developers (Taxa de evolução, medida como o número de contribuições) M7 Taxa de usuários e desenvolvedores (evolução ao longo do tempo) Novamente, podemos evidenciar esses dados em SGB. Usuários são aqueles que somente reportam bugs ou inserem comentários, já os desenvolvedores costumam mais marcar os bugs como resolvidos e anexar patches M8 Taxa de linhas órfãs, que são as linhas de código que não foi possível definir a autoria. (evolução ao longo do tempo) M9 Freqüência de lançamentos (evolução ao longo do tempo). Dependendo das características, esta é uma informação que pode estar presente em SGB. M10 Número de mudanças introduzidas a cada lançamento (evolução ao longo do tempo). Caso o SGB ofereça um controle de lançamentos, como marcos alvos, podemos considerar o número de mudanças introduzidas como o número de bugs resolvidos. Mesmo que a ferramenta não ofereça esse controle, podemos obter essa informação levando em consideração o período de desenvolvimento de cada lançamento. M18 Número de licenças distintas incorporadas (evolução) M19 Número de arquivos e módulos sem licença (evolução) M20 Número de idiomas suportados (evolução) Documentação A documentação pode estar presente em várias formas, como arquivos de texto no próprio repositório de código fonte ou ferramentas de edição colaborativa (wikis), que estão de tornando cada vez mais comuns em projetos de software livre. M11 Número de documentos guia.

35 23 M12 Número de documentos com recomendações de desenvolvimento M13 Presença de documentação de planejamento M14 Presença de árvore de autoria. M15 Presença de FAQ e guia de usuários M16 Presença de diretrizes sobre o workflow do projeto Gerenciamento de Bugs Essas são as métricas que podem ser obtidas diretamente de SGB. Elas serão o alvo da ferramenta desenvolvida neste projeto de graduação. M23 Número de pedidos de modificações submetidos pelos testes automáticos (evolução). M24 Número de pedidos de melhorias submetidos por usuários/desenvolvedores (evolução). M25 Número de bugs enviados ao projeto (evolução). M26 Número de bugs abertos. M27 Número de bugs sem um target. M28 Número de bugs não atribuídos. M29 Percentagem de bugs resolvidos (por período de tempo). M30 Número de bugs enviados. M31 Percentagem de bugs de regressão (sobre o total de bugs). M32 Percentagem de bugs de erros (sobre o total de bugs). Listas de Discussão As listas de discussões oferecem para os usuário um meio de comunicação para que dúvidas sejam tiradas e problemas discutidos. Conforme descrito por Halloran e Scherlis (2002) os bugs se tornam uma espécie de mini-lista, onde somente as questões relativas ao bug são consideradas. M33 Número de cadastros nas listas. Da mesma forma que temos os cadastros nas listas, temos os usuários cadastrados no SGB.

36 24 M34 Número de escritores para as listas. Enquanto os bugs são mini listas, podemos medir o número de usuários que comentam em bugs. M35 Número de cadastrados que se tornaram desenvolvedores. Essa é outro valor que pode ser aferido com mais precisão usando os dados presentes em SGB: é possível determinar o momento em que um usuário deixou de contribuir apenas com comentários e novos bugs, e passou a propor soluções na forma de patches. M36 Contribuidores mais ativos nas listas. Novamente, podemos verificar quais são os usuários mais ativos nos SGB. 2.6 Considerações Finais Neste capítulo vimos como processos de software livre se comparam com os métodos ágeis, e podem inclusive ser considerados como tal. Vimos também a importância dos SGB para os projetos de software livre, a forma como essas ferramentas estão inseridas no processo envolvido nos projetos e quais são as informações gerenciadas pelos SGB. Além disso, foram apresentadas métricas existentes na literatura e levantadas no projeto Qualipso, que evidenciam a qualidade do processo de software, ao mesmo tempo que foram comentadas maneiras de se extrair valores equivalentes (ou complementares) para tais métricas. No capítulo a seguir, será descrita a ferramenta desenvolvida neste projeto para auxiliar na coleta das métricas estudadas e que foram consideradas como requisitos para a avaliação da qualidade do processo de software, coletados de SGB.

37 25 3 Estado Atual do Projeto Neste capítulo é descrita a ferramenta denominada Bicho, o seu estado no início do projeto, as alterações que foram implementadas e uma interface web criada para visualização dos dados coletados. Entre os motivos que levaram à escolha dessa ferramenta para o desenvolvimento desse projeto de graduação estão: A sua inclusão no planejamento do projeto Qualipso como resultado de uma de suas fases (PETRINJA et al., 2008). A linguagem de programação do projeto ser Python e a familiaridade deste autor com a mesma. Após o desenvolvimento das alterações, foi possível coletar dados reais de projetos de software livre atuais. Uma interface web foi implementada para exemplificar uma possível aplicação de visualização desses dados. 3.1 O Projeto Bicho Desenvolvido pelo GSyC/LibreSoft, um grupo de pesquisa da Universidad Rey Juan Carlos, Espanha, o projeto Bicho é uma ferramenta de linha de comando usada para analisar SGB. Em sua execução, a ferramenta cria um banco de dados contendo três tabelas com cópias das informações presentes no SGB sob análise (GSYC/LIBRESOFT, 2009): Bugs, com detalhes sobre cada bug; Comments, com informações sobre cada comentário nos bugs; Attachments, com informações sobre cada arquivo anexo aos bugs.

38 26 Com o inicio do desenvolvimento em agosto de 2007, tendo última atividade registrada em fevereiro de 2009 e com três versões lançadas nesse período, a ferramenta possuía quase 3000 linhas de código Python e apresentava as seguintes funcionalidades: Possibilidade de configuração via parâmetros na linha de comando ou arquivo de configuração; Parser para os bug trackers Bugzilla e Sourceforge; Armazenamento em banco de dados com o esquema dos dados descrito acima. O parser para os bugs do Sourceforge, por exemplo, foi implementado usando uma máquina de estados finitos de difícil leitura e interpretação, o que tornava a manutenção do código uma tarefa árdua. Após uma re-estruturação ocorrida recentemente nas páginas do Sourceforge, esse parser deixou de funcionar corretamente e uma tentativa de corrigir o código levaria muito tempo. A Figura 3.1, presente na documentação da ferramenta, mostra o diagrama de estados implementado nesse parser. É possível observar que os estados enumerados consistem nas 19 possíveis condições dos estados que o programa deve prever e todas as respectivas transições, rotuladas com os tokens html que permitem a transição. Assim, fica evidenciada a complexidade do código implementado nesse parser. O projeto apresentava também uma ligação muito forte entre o frontend (parte responsável pela busca dos dados nos SGB) e o backend (parte responsável pelo armazenamento da saída no banco de dados), o que também dificultava a adição de novas funcionalidades como outros SGB ou um esquema diferente de banco de dados. 3.2 Mudanças Aplicadas O trabalho inicial deste projeto de graduação na ferramenta Bicho foi o de tentar minimizar os problemas citados na seção anterior, começando por uma refatoração do código com o objetivo de satisfazer o máximo possível as indicações do PEP-8 2. O PEP- 8 (Python Enhancement Proposals ou Propostas de Melhoras para o Python) contém uma série de convenções sobre o estilo de código para os programas e bibliotecas escritas em Python, como: identação, uso dos espaços em branco, tamanho máximo das linhas e linhas em branco, além de algumas recomendações sobre a forma de programar. Ao mesmo tempo em que a refatoração do estilo era feita, o projeto foi sendo re-escrito, removendo partes de código desnecessários ou melhorando a forma como algumas soluções 2

39 27 Figura 3.1: Máquina de estados de um dos parsers da ferramenta Bicho. 1 foram implementadas. Ao final de todas as alterações, o projeto passou a apresentar pouco mais de 1600 linhas de código Python. Nas subseções a seguir são descritos os principais componentes da nova arquitetura da ferramenta, a interação entre esses componentes e a configuração da ferramenta. A nova arquitetura é ilustrada pela Figura 3.2. Figura 3.2: Nova arquitetura da ferramenta Bicho

2 Medição e Acompanhamento

2 Medição e Acompanhamento 2 Medição e Acompanhamento Para verificar a eficácia da aplicação da técnica de desenvolvimento dirigido por testes, foram usadas algumas métricas para determinar se houve melhoria ou degradação no processo

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

6 Infraestrutura de Trabalho

6 Infraestrutura de Trabalho 6 Infraestrutura de Trabalho Este capítulo tem como objetivo fornecer uma visão geral do ambiente de trabalho encontrado na organização estudada, bem como confrontá-lo com a organização ideal tal como

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Principais Vantagens do Microsoft Visual Studio Team System

Principais Vantagens do Microsoft Visual Studio Team System Principais Vantagens do Microsoft Visual Studio Team System White Paper Novembro de 2008 Para obter as últimas informações, visite o site www.msdnbrasil.com.br/vstudio As informações contidas neste documento

Leia mais

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas Gerenciamento de Gerenciamento de Configuração Novas versões de sistemas de software são criadas quando eles: Mudam para máquinas/os diferentes; Oferecem funcionalidade diferente; São configurados para

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Maior Previsibilidade com o Visual Studio Team System 2008

Maior Previsibilidade com o Visual Studio Team System 2008 Maior Previsibilidade com o Visual Studio Team System 2008 White Paper Maio de 2008 Para obter as últimas informações, visite o site www.microsoft.com/teamsystem As informações contidas neste documento

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2 ENGENHARIA DE SOFTWARE II Modelos de Ciclo de Vida e Processos de Software AULA 2 Sumário Motivação Conceitos de Processo de Desenvolvimento de Software Atividades que compõem os processos de desenvolvimento

Leia mais

Introdução a Métodos Ágeis de Desenvolvimento de Software

Introdução a Métodos Ágeis de Desenvolvimento de Software Introdução a Métodos Ágeis de Desenvolvimento de Software Curso de Verão Centro de Competência em Software Livre Departamento de Ciência da Computação - IME / USP Realização: AgilCoop Verão Ágil 2010 Copyleft

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

Leia mais

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Micaelly P. Soares e Silva, Carla I. M. Bezerra, Camilo C. Almendra, Enyo José T. Gonçalves Universidade

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo DOCUMENTAÇÃO TÉCNICA Melhores práticas de gerenciamento de ativos de software JUNHO DE 2013 Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo John Fulton CA IT Business Management

Leia mais

Guia de Introdução ao Windows SharePoint Services

Guia de Introdução ao Windows SharePoint Services Guia de Introdução ao Windows SharePoint Services - Windows SharePoint Services... Page 1 of 11 Windows SharePoint Services Guia de Introdução ao Windows SharePoint Services Ocultar tudo O Microsoft Windows

Leia mais

Ferramenta para gestão ágil

Ferramenta para gestão ágil Ferramenta para gestão ágil de projetos de software Robson Ricardo Giacomozzi Orientador: Everaldo Artur Grahl Agenda Introdução Objetivos Fundamentação teórica Desenvolvimento Resultados e discussões

Leia mais

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2 APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2 Renan J. Borges 1, Késsia R. C. Marchi 1 1 Universidade Paranaense (UNIPAR) Paranavaí, PR Brasil renanjborges@gmail.com, kessia@unipar.br

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br Comparativo entre Processos Ágeis Daniel Ferreira dfs3@cin.ufpe.br O que discutiremos: Histórico Os Princípios Ágeis Comparação Do ponto de vista incremental Do ponto de vista funcional Vantagens e Desvantagens

Leia mais

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP extreme Programming extreme Programming (XP) Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitos vagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

Evolução de Software e Refatoração

Evolução de Software e Refatoração Evolução de Software e Refatoração Mudança de software Mudança de software é inevitável Novos requisitos surgem quando o software é usado; O ambiente de negócio muda; Erros devem ser reparados; Novos computadores

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

Documento de Requisitos

Documento de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Documento de Requisitos Sistema Gerenciador de Atendimento de Chamados Técnicos Grupo: Luiz Augusto Zelaquett

Leia mais

O uso do gestor de conteúdos plone no suporte a processos de software

O uso do gestor de conteúdos plone no suporte a processos de software O uso do gestor de conteúdos plone no suporte a processos de software Fernando Silva Parreiras Objetivo Demonstrar a aplicação de ferramentas de gestão de conteúdo, especificamente o plone, no apoio a

Leia mais

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof.

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Sumário. Prefácio...14. Capítulo 1 O que é qualidade?...17. Capítulo 2 Normas e organismos normativos...43. Capítulo 3 Métricas: visão geral...

Sumário. Prefácio...14. Capítulo 1 O que é qualidade?...17. Capítulo 2 Normas e organismos normativos...43. Capítulo 3 Métricas: visão geral... Prefácio...14 Capítulo 1 O que é qualidade?...17 1.1 História... 17 1.2 Uma crise de mais de trinta anos...20 1.3 Qualidade e requisitos...25 1.4 Papel da subjetividade...27 1.5 Qualidade e bugs I: insetos

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software CCE 876 - Engenharia de Software Introdução à Engenharia de Software Objetivos Introduzir a Engenharia de Software e explicar sua importância. Introduzir os conceitos principais relacionados à Engenharia

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

Leia mais

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL Guilherme Vota Pereira guivotap@hotmail.com Prof. Pablo Schoeffel, Engenharia de Software Aplicada RESUMO: Este artigo irá efetuar uma abordagem

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

Engenharia de Software

Engenharia de Software Faculdade de Informática e Administração Paulista Curso de Sistemas de Informação 2º SI-T Engenharia de Software Modelo de Desenvolvimento Ágil SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

Leia mais

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS TM RELATÓRIO EXECUTIVO DE NEGÓCIOS A visão da computação em nuvem por Aad van Schetsen, vicepresidente da Compuware Uniface, que mostra por que

Leia mais

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III FERRAMENTAS DE GERENCIAMENTO DE PROJETOS TRAC E DOTPROJECT ORIETADOS AO RUP ACADÊMICOS: GUSTAVO

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D.

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D. Capítulo 25 Gerenciamento de Configuração slide 624 2011 Pearson Prentice Hall. Todos os direitos reservados. Tópicos abordados Gerenciamento de mudanças Gerenciamento de versões Construção de sistemas

Leia mais

Usando ferramentas já conhecidas integradas ao Visual Studio Team System 2008

Usando ferramentas já conhecidas integradas ao Visual Studio Team System 2008 Usando ferramentas já conhecidas integradas ao Visual Studio Team System 2008 White Paper Maio de 2008 Para obter as últimas informações, visite o site www.microsoft.com/teamsystem As informações contidas

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

A Evolução de XP segundo Kent Beck Parte 2

A Evolução de XP segundo Kent Beck Parte 2 A Evolução de XP segundo Kent Beck Parte 2 O que mudou nesses 5 anos? Danilo Toshiaki Sato dtsato@ime.usp.br Agenda PARTE 1 1. Introdução 2. O que é XP? 3. O que mudou em XP? Valores, Princípios e Práticas

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

Daniel Wildt -dwildt@gmail.com

Daniel Wildt -dwildt@gmail.com Metodologias Ágeis e Software Livre Daniel Wildt -dwildt@gmail.com Bacharel em Informática (PUCRS) Professor Universitário (FACENSA) Mais de 10 anos de experiência em Desenvolvimento de Software, hoje

Leia mais

FACULDADE LOURENÇO FILHO ENADE 2011 Prof. Jackson Santiago Engenharia de Software DATA: 29/10/2011

FACULDADE LOURENÇO FILHO ENADE 2011 Prof. Jackson Santiago Engenharia de Software DATA: 29/10/2011 Assunto : Ciclo de vida de software 1. O modelo de ciclo de vida em cascata: a) enfatiza a realização sequencial das atividades do desenvolvimento de um produto de software. b) enfatiza a comunicação estreita

Leia mais

development Teresa Maciel DEINFO/UFRPE

development Teresa Maciel DEINFO/UFRPE development Teresa Maciel DEINFO/UFRPE Prazos curtos Baixo custo Agregação ao negócio Fidelidade do cliente Competitividade Sobrevivência Cenário 2000 35% dos projetos apresentam sucesso 31% dos projetos

Leia mais

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

Leia mais

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados Tribunal de Justiça de Pernambuco Diretoria de Informática Guia de Utilização do Mantis Máquina de Estados Guia de Utilização Mantis Histórico de Alterações Data Versão Descrição Autor Aprovado Por 02/09/2008

Leia mais