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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

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

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

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

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

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

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 28 Revisão para a Prova 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 28-28/07/2006 1 Matéria para a Prova 2 Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap.

Leia mais

Prof. Me. Marcos Echevarria

Prof. Me. Marcos Echevarria Prof. Me. Marcos Echevarria Nas décadas de 80 e 90 a visão geral sobre a melhor maneira de desenvolver software era seguir um cuidadoso planejamento para garantir uma boa qualidade; Esse cenário era aplicável

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

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

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

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

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

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

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

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

Desenvolvimento Ágil de Software em Larga Escala

Desenvolvimento Ágil de Software em Larga Escala Desenvolvimento Ágil de Software em Larga Escala Jutta Eckstein Encontro Ágil 2009 1 Agilidade é Quente Gerenciamento Ágil de Projetos Testes Ágeis Arquitetura Ágeis Offshore Ágil Investimento Ágil PLM

Leia mais

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental Ajuda ao SciEn-Produção 1 Este texto de ajuda contém três partes: a parte 1 indica em linhas gerais o que deve ser esclarecido em cada uma das seções da estrutura de um artigo cientifico relatando uma

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

Instituto de Ciências Matemáticas e de Computação. MANUAL DE USO Sistema de Reserva de Salas INTRANET - ICMC-USP

Instituto de Ciências Matemáticas e de Computação. MANUAL DE USO Sistema de Reserva de Salas INTRANET - ICMC-USP Instituto de Ciências Matemáticas e de Computação ISSN - 0103-2569 MANUAL DE USO Sistema de Reserva de Salas INTRANET - ICMC-USP André Pimenta Freire Renata Pontin de M. Fortes N 0 213 RELATÓRIOS TÉCNICOS

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

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

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

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

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

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

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

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português 1 de 7 28/10/2012 16:47 SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português RESULTADO DO SIMULADO Total de questões: 40 Pontos: 0 Score: 0 % Tempo restante: 55:07 min Resultado: Você precisa

Leia mais

1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007. projeto

1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007. projeto Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007 1 Inicie um novo Antes de começar um novo, uma organização deve determinar se ele se enquadra em suas metas estratégicas. Os executivos

Leia mais

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES Trabalho de Graduação Orientando: Vinicius Stein Dani vsdani@inf.ufsm.br Orientadora: Giliane

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

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

ERP: Pacote Pronto versus Solução in house

ERP: Pacote Pronto versus Solução in house ERP: Pacote Pronto versus Solução in house Introdução Com a disseminação da utilidade e dos ganhos em se informatizar e integrar os diversos departamentos de uma empresa com o uso de um ERP, algumas empresas

Leia mais

Engenharia da WEB 16/08/2011. Vida moderna. Sistemas WEB

Engenharia da WEB 16/08/2011. Vida moderna. Sistemas WEB Engenharia da WEB Fernando Schütz Especialização 2010 UTFPR Vida moderna Sistemas WEB Início Arquivos hipertexto Hoje Bancos! Powell Sistemas WEB envolvem uma mistura de publicação impressa e desenvolvimento

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

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

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

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

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

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

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

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

EVOLUÇÃO DE SOFTWARE

EVOLUÇÃO DE SOFTWARE EVOLUÇÃO DE SOFTWARE Dinâmica da evolução de programas Manutenção de software Processo de evolução Evolução de sistemas legados 1 Mudança de Software 2 Manutenção de software Mudança de software é inevitável

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

Desenvolvendo Software Livre com Programação extrema

Desenvolvendo Software Livre com Programação extrema Desenvolvendo Software Livre com Programação extrema Dairton Bassi FISL 7.0 abril/2006 Panorama sobre o Desenvolvimento de Software A sociedade demanda: Grande quantidade de sistemas/aplicações Sistemas

Leia mais

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Ponta Grossa 2012 ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Trabalho elaborado pelo

Leia mais

UMA ABORDAGEM SOBRE OS PADRÕES DE QUALIDADE DE SOFTWARE COM ÊNFASE EM SISTEMAS PARA WEB

UMA ABORDAGEM SOBRE OS PADRÕES DE QUALIDADE DE SOFTWARE COM ÊNFASE EM SISTEMAS PARA WEB UMA ABORDAGEM SOBRE OS PADRÕES DE QUALIDADE DE SOFTWARE COM ÊNFASE EM SISTEMAS PARA WEB Alan Francisco de Souza¹, Claudete Werner¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil alanfsouza.afs@gmail.com,

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

Como conduzir com sucesso um projeto de melhoria da qualidade

Como conduzir com sucesso um projeto de melhoria da qualidade Como conduzir com sucesso um projeto de melhoria da qualidade Maria Luiza Guerra de Toledo Coordenar e conduzir um projeto de melhoria da qualidade, seja ele baseado no Seis Sigma, Lean, ou outra metodologia

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

Leia mais

CMM - Capability Maturity Model

CMM - Capability Maturity Model Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon

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

Estratégias de Pesquisa

Estratégias de Pesquisa Estratégias de Pesquisa Ricardo de Almeida Falbo Metodologia de Pesquisa Departamento de Informática Universidade Federal do Espírito Santo Agenda Survey Design e Criação Estudo de Caso Pesquisa Ação Experimento

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

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

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

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de SCE186-ENGENHARIA DE SOFTWARE Módulo 1 Atividades da Engenharia de GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br 2003 DEFINIÇÃO CONSTRUÇÃO SOFTWARE PRODUTO MANUTENÇÃO

Leia mais

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo

Leia mais

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO

REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO Capítulo 12 REPROJETO DA ORGANIZAÇÃO COM SISTEMAS DE INFORMAÇÃO 12.1 2003 by Prentice Hall OBJETIVOS De que forma o desenvolvimento de um novo sistema poderia mudar a maneira de uma organização trabalhar?

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

Modelagem de Casos de Uso (Parte 2)

Modelagem de Casos de Uso (Parte 2) Modelagem de Casos de Uso (Parte 2) Roteiro (1) Método para Modelagem de Casos De Uso Estudo de Caso: Sistema de Controle para Videolocadora Levantamento Inicial dos Casos de Uso Identificação dos Casos

Leia mais

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE Modelo de Otimização de SAM Controle, otimize, cresça Em um mercado internacional em constante mudança, as empresas buscam oportunidades de ganhar vantagem competitiva

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

Leia mais

Estudo de Viabilidade

Estudo de Viabilidade Estudo de Viabilidade PGE: Plastic Gestor Empresarial Especificação de Requisitos e Validação de Sistemas Recife, janeiro de 2013 Sumário 1. Motivação... 1 2. Introdução: O Problema Indentificado... 2

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

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44 Armazenando Dados em Aplicações Java Parte 2 de 3: Apresentando as opções Hua Lin Chang Costa, hualin@cos.ufrj.br, COPPE/UFRJ. Leonardo Gresta Paulino Murta, leomurta@ic.uff.br, IC/UFF. Vanessa Braganholo,

Leia mais