UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO
|
|
- Walter Casado Bennert
- 8 Há anos
- Visualizações:
Transcrição
1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA ÁGIL SCRUM Área de Engenharia de Software por Monike Roberta Kluge Adriana Gomes Alves, M. Eng Orientadora Itajaí (SC), julho de 2009
2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA ÁGIL SCRUM Área de Engenharia de Software por Monike Roberta Kluge Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Adriana Gomes Alves, M. Eng. Itajaí (SC), julho de 2009
3 SUMÁRIO LISTA DE ABREVIATURAS...iv LISTA DE FIGURAS...v LISTA DE TABELAS...vi RESUMO...vii ABSTRACT...viii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA PROCESSOS DE SOFTWARE METODOLOGIAS TRADICIONAIS METODOLOGIAS ÁGEIS SCRUM Papéis no Scrum Estrutura do Processo Scrum Ciclo de Vida do Scrum Ferramentas PROJETO ANÁLISE DE REQUISITOS Requisitos Funcionais Requisitos Não Funcionais Regras de Negócio DIAGRAMA DE CASOS DE USO Módulo Projeto Módulo Product Backlog Módulo Controle de Sprint DIAGRAMA DE CLASSES DIAGRAMA ENTIDADE-RELACIONAMENTO DESENVOLVIMENTO IMPLEMENTAÇÃO DA FERRAMENTA Framework ScriptCase ii
4 4.2 A FERRAMENTA SCRUM PROJECT Acesso ao Sistema Módulo de Cadastros Módulo Projeto Módulo Product Backlog Módulo Sprint Backlog Módulo Reunião de Planejamento Módulo Reunião Diária Reunião de Revisão Reunião de Retrospectiva Relatórios CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS...54 GLOSSÁRIO...56 A DESCRIÇÃO DOS CASOS DE USO...58 A.1 MÓDULO PROJETO A.2 MÓDULO PRODUCT BACKLOG A.3 MÓDULO DE CONTROLE DE SPRINT iii
5 LISTA DE ABREVIATURAS ASD CASE DSDM FDD MOSCOW ROI RUP TCC UML UNIVALI XP Adaptative Software Development Computer Aided Software Engineering Dynamic System Development Method Feature Driven Development Must, Should, Could, Want Return on Investment Rational Unified Process Trabalho de Conclusão de Curso Unified Modeling Language Universidade do Vale do Itajaí Extreme Programming iv
6 LISTA DE FIGURAS Figura 1. Camadas da Engenharia de Software...5 Figura 2. Modelo em Cascata...8 Figura 3. Fases do RUP...10 Figura 4. Adoção do Scrum...12 Figura 5. Framework do Scrum...14 Figura 6. Fluxo do Scrum...16 Figura 7. Product Backlog...18 Figura 8. Priorização do Product Backlog...18 Figura 9. Importância do Product Backlog...19 Figura 10. Estimando o Product Backlog através do Planning Poker...20 Figura 11. Estrutura de uma Sprint...21 Figura 12. Planejamento da Sprint...22 Figura 13. Controle da Sprint Backlog...23 Figura 14. Burndown Charts dias/horas...24 Figura 15. Burndown Charts Sprint /estimativa...24 Figura 16. Diagrama de casos de uso do módulo Projeto...32 Figura 17. Diagrama de casos de uso do módulo Product Backlog...33 Figura 18. Diagrama de casos de uso do módulo controle de Sprint...34 Figura 19. Diagrama de classes de domínio...35 Figura 20 - Diagrama de entidade-relacionamento do banco de dados...37 Figura 21 - Framework ScriptCase...38 Figura 22. Tela inicial ScriptCase...39 Figura 23. Tela autenticação dos usuários na ferramenta...40 Figura 24. Menu da ferramenta Scrum Project para o perfil Scrum Master Figura 25. Menu da ferramenta Scrum Project para o perfil Scrum Time Figura 26. Menu da ferramenta Scrum Project para o perfil Product Owner...42 Figura 27. Cadastro de usuários...43 Figura 28 - Cadastro de times...44 Figura 29 - Cadastro de projetos...45 Figura 30 - Cadastro de Product Backlog...46 Figura 31 - Cadastro de Sprint Backlog...47 Figura 32 - Cadastro da Reunião de Planejamento...48 Figura 33 - Informar reunião diária...49 Figura 34 - Informar reunião de revisão...50 Figura 35 - Informar reunião de retrospectiva...51 Figura 36 - Consulta Sprint Backlog...52 v
7 LISTA DE TABELAS Tabela 1. Funcionalidades dos Softwares Avaliados e da Ferramenta Proposta...27 Tabela 2. Características Gerais dos Softwares Avaliados e da Ferramenta Proposta...28 vi
8 RESUMO Kluge, Monike Roberta. Scrum Project: ferramenta de apoio ao gerenciamento de projetos de software baseados nos princípios da metodologia ágil Scrum. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, A área de Gerenciamento de Projetos há muito tempo, vem enfrentando problemas relativos a atrasos na entrega de projetos, orçamento extrapolado e insatisfação de clientes e usuários. Visando a atingir melhores resultados, as empresas estão adotando metodologias de desenvolvimento de software flexíveis a mudanças e que propiciem maior interação entre cliente e desenvolvedor. Essas metodologias, chamadas de ágeis, surgiram em oposição às metodologias tradicionais, orientadas para a produção de documentação. Entre as metodologias ágeis, destaca-se o Scrum, uma metodologia que tem, por objetivo, definir um processo de desenvolvimento de software de forma iterativa incremental e que pode ser aplicado no gerenciamento de atividades e desenvolvimento de novos produtos. Este Trabalho de Conclusão de Curso (TCC) apresenta o desenvolvimento de uma ferramenta de gerenciamento de projetos, denominada Scrum Project, que implementa os artefatos do Scrum e propicia o gerenciamento de projetos de forma ágil e flexível. Palavras-chave: Gerenciamento de Projetos. Metodologias Ágeis. Scrum. vii
9 ABSTRACT Since a long time, area of Project Management has been facing problems related to delays in delivering projects, exceeded budget, and dissatisfaction of customers and users. Seeking for achieving the best results, the companies are adopting methodologies of software development, which are flexible to changes and that may provide a greater interaction between the customer and the developer. These methodologies, called "agile", emerged opposing to traditional methodologies, which are geared towards the production of documentation. Among agile methodologies, one highlight is the Scrum, a methodology which aims at defining a process for software development in an iterative, incremental way that may be applied to the activities management and the development of new products. This Final Work presents the development of a tool for the projects management, called the Scrum Project, which implements the Scrum's artifacts and makes the projects management more agile and flexible. Keywords: Project Management. Agile Methodologies. Scrum. viii
10 1 INTRODUÇÃO O desafio constante da área de Engenharia de Software é melhorar o processo de desenvolvimento de software. Apesar da crescente evolução das técnicas, métodos e ferramentas, a entrega de softwares no prazo e custo pré-estabelecidos nem sempre é possível. Vários são os fatores que podem influenciar esse atraso, tais como: mudanças de escopo, saída de pessoas importantes, excesso de formalização da documentação, programadores inexperientes, alta taxa de erros, falhas de critérios de qualidade entre outros (COSTA FILHO et al, 2005). O sucesso na entrega de softwares é algo difícil de ser realizado. Desde 1994, o Standish Group International publica a cada dois anos um estudo nomeado de Chaos Research que consolida as informações de uma pesquisa sobre sucessos e fracassos dos projetos de software desenvolvidos com as mais diversas metodologias. Na última pesquisa divulgada (STANDISH, 2008) foram apontadas as seguintes conclusões: Em 1998, o número de projetos que terminaram no prazo, dentro do orçamento e atendendo aos requisitos do cliente era de 26%. Em 2006, o número de projetos aumentou para 35%; Em 1998 e 2008, o número de projetos finalizados e com software operacional entregue foi mensurado em 46%, porém nesses projetos, o orçamento e o prazo ultrapassam os limites estipulados; e Em 1998, o número de projetos cancelados era de 28%. Em 2008, esse número reduziu para 19%. Apesar do aumento significativo no número de projetos bem sucedidos, as somas da porcentagem dos projetos fracassados e comprometidos equivalem a 65% do total de projetos. Um aspecto que contribui para esse número é o fato de que a maior parte dos projetos desenvolvidos é baseada em metodologias tradicionais (FOWLER, 2003; LARMAN, 2004, apud COSTA FILHO et al, 2005). Segundo Soares (2004) os processos tradicionais, muito orientados para a produção de documentação, podem tornar-se fatores limitadores de desenvolvimento, dado que muitas organizações não possuem recursos e conhecimento para adotar processos complexos de produção de software. As metodologias tradicionais são aplicadas em situações em que os requisitos do sistema são estáveis com evoluções futuras previsíveis. Entretanto, muitos projetos caracterizam-se por
11 requisitos dinâmicos, estando sujeitos a freqüentes mudanças resultantes da dinâmica da organização (SOUZA NETO, 2004). Em oposição às metodologias tradicionais surgiram as Metodologias Ágeis, que proporcionam um desenvolvimento de software mais rápido, atendendo os requisitos do cliente, no prazo e custo e ainda permitem modificações à medida que novas necessidades surgem (COSTA FILHO et al, 2005). Segundo Soares (2004), ao contrário das metodologias tradicionais, as metodologias ágeis surgiram com a proposta de aumentar o foco nas pessoas e não no processo de desenvolvimento, além disso, existe a preocupação de gastar menos tempo com documentação e mais na resolução de problemas de forma iterativa. Entre as metodologias ágeis destaca-se o Scrum. Segundo Schwaber e Beedle (2002, apud PEREIRA, 2005), o Scrum é um processo iterativo e incremental de desenvolvimento de software. Utiliza técnicas simples unidas ao senso comum e baseadas em experiências passadas, já testadas e aprovadas. O uso do Scrum vai de encontro com a necessidade de pequenas empresas de desenvolvimento de software, pelo fato de ser simples, ágil e com o mínimo de burocracia. O uso da metodologia Scrum deve ser facilitado através da utilização de uma ferramenta que forneça o apoio necessário no desenvolvimento das atividades envolvidas nesse processo. Pelo fato do uso de metodologias ágeis serem um assunto relativamente novo, existem poucas ferramentas disponíveis que suportam o processo ágil de desenvolvimento utilizando Scrum. As ferramentas existentes no mercado são desenvolvidas em inglês e algumas não contemplam todas as funcionalidades definidas pelo Scrum. Diante desse cenário, esse trabalho propõe o desenvolvimento de uma ferramenta de apoio ao gerenciamento de projetos de software baseados nos princípios da metodologia ágil Scrum. Essa ferramenta deverá auxiliar os analistas e desenvolvedores de sistemas na implantação do Scrum de forma ágil e rápida, possibilitando ao gerente do projeto obter maior controle, integração entre cliente e desenvolvedor, acompanhar cada fase do projeto e possibilidade de alterar o escopo no momento em que necessite. 1.1 PROBLEMATIZAÇÃO Formulação do Problema As empresas de software estão utilizando o Scrum como metodologia para gerenciamento de projetos, porém a inexistência de uma ferramenta que contemple os artefatos do Scrum obriga as empresas a gerenciarem seus projetos de forma manual, através de quadros informativos 2
12 preenchidos com post-its. As ferramentas existentes no mercado são desenvolvidas em inglês e algumas não contemplam todas as funcionalidades do Scrum. Já as ferramentas mais completas são pagas Solução Proposta A solução proposta nesse projeto é o desenvolvimento de uma ferramenta que apóie o desenvolvimento de projetos utilizando a metodologia Scrum. Essa ferramenta foi desenvolvida em português, baseada em software livre e de código fonte aberto para que outros desenvolvedores possam adaptá-la e atender as necessidades de sua empresa. 1.2 OBJETIVOS Objetivo Geral Desenvolver uma ferramenta para gerenciamento de projetos baseada na metodologia ágil Scrum Objetivos Específicos Os objetivos específicos desse TCC são: Pesquisar e compreender detalhadamente a metodologia ágil Scrum; Pesquisar e analisar soluções de softwares similares; Estudar e aprender as ferramentas computacionais necessárias à implementação do sistema; Realizar a modelagem conceitual da ferramenta; Implementar a ferramenta; Testar e validar a implementação da ferramenta; e Documentar o desenvolvimento. 1.3 Metodologia Para o desenvolvimento da Fundamentação Teórica foram realizadas pesquisas buscando compreender os principais conceitos referentes às Metodologias Tradicionais, Ágeis e Scrum. Essas 3
13 pesquisas foram mais intensas na Metodologia Scrum, visando entender sua estrutura e fluxo de funcionamento. Foram estudadas algumas ferramentas existentes no mercado analisando suas características e quais artefatos do Scrum as mesmas possuem implementados. Essas pesquisas foram realizadas através de livros, artigos científicos, sites de busca e trabalhos acadêmicos. O desenvolvimento do Projeto foi iniciado com uma análise de todos os requisitos que a ferramenta deveria atender. Os requisitos foram identificados com base nas informações levantadas sobre o Scrum e no levantamento de carências das ferramentas existente. Após a identificação dos requisitos, foi realizada a modelagem do banco de dados, representada através de um diagrama Entidade-Relacionamento. Por último, foi descrito a implementação da ferramenta. As telas que a mesma apresenta suas funcionalidades e como é possível o gerenciamento de projetos através dessa ferramenta. 1.4 Estrutura do trabalho Este projeto esta estruturado em cinco capítulos: (i) Introdução; (ii) Fundamentação Teórica; (iii) Projeto; (iv) Desenvolvimento; e (v) Conclusões. O Capítulo 1 (Introdução) apresentou uma visão geral sobre o projeto desenvolvido, o problema encontrado e qual a solução proposta, os objetivos do TCC e sua metodologia de desenvolvimento. O Capítulo 2 (Fundamentação Teórica) apresenta conceitos dos temas necessários para o desenvolvimento do projeto: Processos de Software, Metodologias Tradicionais, Metodologias Ágeis, Scrum e estudo sobre as Ferramentas similares disponíveis. O Capítulo 3 (Projeto) especifica o projeto detalhado da ferramenta desenvolvida, incluindo requisitos elicitados, casos de uso, diagrama de classes e modelagem do banco de dados. O Capítulo 4 (Desenvolvimento) descreve como a ferramenta foi implementa, ilustrando suas telas e funcionalidades. O Capítulo 5 (Conclusões) apresenta as considerações finais do trabalho desenvolvido, dificuldades encontradas e sugestões de melhorias a serem realizadas na ferramenta com de intuito de dar continuidade ao trabalho. 4
14 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo é apresentada a revisão bibliográfica sobre o tema base desse presente projeto: a metodologia ágil Scrum. A seção 2.1 apresenta uma visão sobre processo de software expondo seu conceito e a diferença entre processo e método. Na seção 2.2 é apresentada uma breve discussão sobre metodologias tradicionais, expondo suas características, vantagens e desvantagens do seu uso. A seção 2.3 apresenta informações sobre as metodologias ágeis, expondo suas vantagens de utilização, crescimento de uso e principais características. Por fim, a seção 2.4 apresenta a metodologia ágil Scrum, suas características, sua relação com o Manifesto Ágil, seu funcionamento e as ferramentas utilizadas. 2.1 Processos de Software A engenharia de software é uma disciplina relacionada com os aspectos de produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção (HELDMAN, 2005). Segundo Pressman (2006), a engenharia de software é dividida em camadas e tem como principal foco a qualidade do produto final gerado. A Figura 1 ilustra a divisão da engenharia de software. Figura 1. Camadas da Engenharia de Software Fonte: Adaptado de Pressman (2006). A primeira camada da engenharia de software se refere às ferramentas que fornecem apoio automatizado ou semi-automatizado para os processos e métodos. Segundo Pressman (1995, p. 32) quando as ferramentas são integradas de forma que a informação criada por uma ferramenta possa
15 ser usada por outra, é estabelecido um suporte ao desenvolvimento de software chamado engenharia de software auxiliada por computador - CASE. As ferramentas CASE auxiliam as atividades de engenharia de processos, desde análise de requisitos e modelagem até programação e testes. A camada de métodos de engenharia de software é uma representação abstrata das atividades, modelos e artefatos, fornecem a técnica de como fazer para construir software (PRESSMAN, 2006, p. 18), englobando um conjunto de tarefas que inclui análise de requisitos, projeto, construção de programas, teste e manutenção. Os métodos orientam os processos recomendando práticas mais adequadas e atividades a serem seguidas. O alicerce da engenharia de software é a camada de processo. O processo de engenharia de software é um conjunto de atividades realizadas por pessoas, cujo objetivo é o desenvolvimento ou aperfeiçoamento de um software e sua documentação (LEITE, 2008). Segundo Jacobson (apud PRESSMAN, 2006, p.19), um processo define quem está fazendo o quê, quando e como alcançar um certo objetivo. De acordo com Sommerville (2007), existem quatro atividades fundamentais que são comuns a todos os processos de software: 1. Especificação de software: clientes e engenheiros definem o software a ser produzido e suas restrições; 2. Desenvolvimento de software: o software é projetado e programado; 3. Validação de software: o software é verificado para garantir que atende o que o cliente deseja; e 4. Manutenção de software: o software é adaptado para atender as modificações do cliente e do mercado. Por fim, a base para todas as camadas da Engenharia de Software é o foco na qualidade do produto final gerado. A engenharia fornece métodos, processos e ferramentas de forma que o gerente de projeto possa garantir que o software será gerado com a qualidade desejada. Os processos de software são complexos e dependem da visão do gerente do projeto e do tipo de software que se deseja construir. Cada software, dependendo de sua finalidade, exige um processo de desenvolvimento diferente e, apesar da diversidade de modelos de processos de 6
16 software, não existe um processo ideal, forçando as empresas a realizarem adaptações para atender suas demandas de desenvolvimento. Alguns sistemas críticos necessitam de um processo de desenvolvimento estruturado, ou ditos burocráticos, outros sistemas de negócio possuem requisitos que mudam rapidamente exigindo um processo flexível e ágil (SOMMERVILLE, 2007). Dentre os processos de softwares existentes, podem ser citadas as metodologias tradicionais, que são orientadas a documentação, e as metodologias ágeis, que procuram desenvolver software com o mínimo de documentação (SOARES, 2004). 2.2 Metodologias Tradicionais As metodologias tradicionais surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros 1. Na época o custo para realizar alterações e correções em programas era muito elevado, uma vez que o acesso aos computadores era limitado e não existiam ferramentas como depuradores e analisadores de código. Por isso o software era planejado por inteiro, documentado e por último programado (ROYCE, 1970, apud SOARES, 2004). A maior parte dos projetos, que utilizam metodologia tradicional, baseiam-se no modelo em cascata. A principal característica desse modelo é a separação das fases do projeto, que consistem em: levantamento de requisitos, modelagem, implementação, testes e implantação. Nesse modelo uma fase só inicia quando a anterior estiver pronta (RIBEIRO, 2008). A Figura 2 ilustra as fases do modelo em cascata e a dependência entre elas. 1 O termo terminal burro refere-se a terminais formados apenas por vídeo e teclado, que não possuem unidade de armazenamento e nem poder de processamento, ficando interconectados a um computador central, chamado de mainframe. Disponível em < > Acesso em 10 jan
17 Figura 2. Modelo em Cascata Fonte: Adaptado de Sommerville (2007). O modelo em cascata gera questionamentos com relação a sua eficácia, pois dificulta o controle do projeto. Entre os problemas encontrados no modelo em cascata estão (PRESSMAN, 2006): Projetos reais dificilmente seguem o fluxo seqüencial que o modelo propõe. A natureza linear do modelo em cascata leva a estados de bloqueio, nos quais alguns membros da equipe do projeto precisam esperar que outros membros terminem as atividades pendentes; Em geral, é difícil para o cliente definir todo o escopo do projeto na fase de levantamento de requisitos. O modelo em cascata exige isso e tem dificuldade para reagir com mudanças no escopo, pois a cada alteração é necessário retornar ao início do projeto para modificar a documentação; e A versão executável do projeto somente fica disponível no final do projeto. A vantagem do modelo em cascata é a documentação produzida em cada fase, porém esse modelo deve ser usado em projetos onde os requisitos são bem compreendidos e haja pouca probabilidade de mudanças durante o desenvolvimento do sistema (SOMMERVILLE, 2007). Como proposta para solucionar os problemas do modelo em cascata surgiu o Processo Unificado. Ivar Jacobson, Grady Booch e James Rumbaugh (apud PRESSMAN, 2006, p. 51) 8
18 discutem a necessidade de um processo de software guiado por casos de uso, centrado na arquitetura, iterativo e incremental quando afirmam: Hoje, a tendência em software é em direção a sistemas maiores, mais complexos. Isso se deve, em parte, ao fato de que computadores têm se tornado mais potentes a cada ano, levando os usuários a esperar mais deles. Essa tendência tem também sido influenciada pelo uso da internet, que está se expandindo, para trocar toda espécie de informação... Nosso apetite por softwares cada vez mais sofisticados cresce à medida que aprendemos de uma versão de um produto para a seguinte como o produto poderia ser aperfeiçoado. Desejamos softwares que sejam melhor adaptados às nossas necessidades, mas que, por sua vez, não torne o software somente mais complexo. Em resumo, desejamos mais. Um produto comercial baseado no processo unificado é o RUP (Rational Unified Process). O RUP, desenvolvido pela empresa Rational Software Corporation, é considerado um framework genérico que engloba as melhores práticas de mercado. Segundo Sommerville (2007), o RUP é um exemplo de modelo de processo moderno que foi derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento associado. O objetivo do RUP é descrever um software usando técnicas comerciais visando aumentar a qualidade dos softwares gerados. Está fundamentado em três princípios básicos: Iterativo e Incremental; Guiado por casos de uso; e Baseado na arquitetura do sistema. O RUP é um modelo constituído por quatro fases que compõem o processo de desenvolvimento (FERREIRA, 2007): 1. Iniciação: nessa fase é estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a precisão necessária para se proceder estimativas de prazos e custos. 2. Elaboração: o propósito nessa fase é analisar mais detalhadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos que oferecem maior risco. Os elementos de risco a serem analisados, nesta fase, são os riscos de requisitos, tecnológicos, de recursos e políticos. Essa fase é a mais crítica de todas, pois ao final dessa fase a engenharia é considerada completa e os custos para modificação do sistema aumentam à medida que o projeto avança. 9
19 3. Construção: essa fase compreende a modelagem e desenvolvimento do sistema, tendo como base a arquitetura entregue na fase anterior. Essa fase geralmente é composta por diversas iterações, onde ao final de cada iteração tem uma parte executável do produto. 4. Transição: o objetivo dessa fase é assegurar que o software esteja disponível para a comunidade de usuários. Os usuários testam o software e geram relatórios contendo defeitos e modificações necessárias. Além disso, a equipe cria informações de apoio necessárias aos usuários (manual do usuário e procedimento de instalação). A Figura 3 ilustra as fases do desenvolvimento do RUP e as atividades desenvolvidas em cada fase. Figura 3. Fases do RUP Fonte: Ferreira (2007). No RUP as fases de desenvolvimento não ocorrem em seqüência, mas em paralelo. Isso significa que ao mesmo tempo em que as fases de elaboração, construção e transição estão sendo realizadas, uma nova fase de incremento de software já foi iniciada. (PRESSMAN, 2006). Embora o RUP represente uma nova geração de processos genéricos, ele não é um processo adequado a todos os tipos de desenvolvimento. Para projetos de software pequenos o RUP é um processo complexo e trabalhoso devido à quantidade de documentação gerada (SOMMERVILLE, 2007). 10
20 2.3 Metodologias Ágeis Atualmente os negócios operam em um ambiente global sujeito a rápidas mudanças. Eles têm de responder rapidamente às mudanças econômicas, oportunidades de mercado e ao surgimento de novos produtos e serviços. O software é parte integrante das operações de negócio, sendo assim, é essencial que o software seja desenvolvido ou modificado de forma rápida e eficiente para suprir as novas necessidades impostas pelos avanços do mercado (SOMMERVILLE, 2007). Segundo Sommerville (2007, p.260): Os processos de desenvolvimento de software baseados em especificações completas de requisitos, projeto, construção e teste não estão voltados para o desenvolvimento rápido de software. Quando os requisitos são alterados ou quando problemas com requisitos são descobertos, o projeto ou implementação precisa ser refeito e testado novamente. Como conseqüência, um processo em cascata ou baseado em especificações é geralmente prolongado e a versão final do software é entregue para o cliente muito tempo depois dos requisitos serem definidos, o que poderá tornar o software inútil. Para enfrentar esses desafios encontrados pelos desenvolvedores de software, um grupo de 17 metodologistas formou a Agile Software Development Alliance, freqüentemente citada apenas como Agile Alliance, em fevereiro de Esse grupo de pessoas definiu um manifesto com as melhoras práticas de desenvolvimento de software e, com base nesse manifesto formulou um conjunto de princípios que definem critérios para o desenvolvimento ágil de software, a partir dessas definições surgiu o termo Metodologia Ágil (AGILE MANIFESTO, 2008). Os conceitos do Manifesto Ágil são (AMBLER, 2004): Indivíduos e interações ao invés de processos e ferramentas; Software executável ao invés de documentação; Colaboração do cliente ao invés de negociação de contratos; e Respostas rápidas a mudanças ao invés de seguir planos. O Manifesto Ágil não rejeita processos, ferramentas, documentação e planejamento, mas mostra que eles têm importância secundária quando comparado com indivíduos e interações, com o software estar executando corretamente, com a colaboração do cliente e as respostas rápidas a mudanças e alterações (SOUZA NETO, 2004). O conceito de metodologia ágil é mais adequado para a execução de projetos de curta duração em pequenas e médias empresas. Entre os métodos ágeis existentes podem-se citar: Extreme Programming (XP), Scrum, Dynamic System Development Method (DSDM), Adaptive Software Development (ASD), Crystal, 11
21 Feature Driven Development (FDD) e Lean Development. Uma pesquisa realizada sobre o estado do desenvolvimento ágil indica que 40% dos entrevistados utilizam Scrum como metodologia base (VERSIONONE, 2007 apud TAVARES, 2008). A Figura 4 mostra o percentual de adoção do Scrum quando comparado com outras metodologias ágeis. Figura 4. Adoção do Scrum Fonte: Yoshima (2007). Métodos, práticas e técnicas para o desenvolvimento ágil de projetos prometem aumentar a satisfação do cliente (BOEHM, 2003) para produzir alta qualidade de software e para acelerar os prazos de desenvolvimento de projetos. Empresas como a Rede Globo de televisão, Microsoft, Google, Yahoo, Nokia, BBC, CESAR, Philips, adotaram o Scrum para desenvolvimento de software e o resultado obtido foi vantajoso (BERNABO, 2007). O Scrum é um método ágil que vem ganhando grande visibilidade nos últimos cinco anos, em projetos de desenvolvimento de software, ressaltando benefícios como comprometimento da equipe, motivação, colaboração, integração e compartilhamento de conhecimento, o que facilita em muito o gerenciamento e sucesso dos projetos (SCHWABER, 2004, apud MARÇAL et al., 2007). Por esses motivos, este método foi escolhido como objeto de estudo deste trabalho de conclusão de curso e é melhor detalhado nos itens a seguir. 2.4 Scrum O Scrum é uma metodologia ágil utilizada para gerenciar e controlar o desenvolvimento de software utilizando práticas iterativas e incrementais. Baseado nas práticas de gerenciamento do 12
22 Extreme Programming e no RUP, o Scrum produz os benefícios do desenvolvimento ágil com a vantagem de ser uma implementação simples (YOSHIMA, 2007). Inicialmente o Scrum foi concebido como um estilo de gerenciamento de projetos, em empresas de fabricação de automóveis e produtos de consumo, por Hirotaka Takeuchi e Ikujiro Nonaka no livro The New Product Development Game (Harvard Business Review, 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares produziam os melhores resultados, e associaram estas equipes altamente eficazes à formação do Scrum no Rugby 2. A primeira experiência reconhecida do Scrum foi realizada em 1993 por Jeff Shuterland que implementou em sua organização, a Easel Corporation, um processo baseado na formação do Rugby e nos estudos de Nanaka e Takeuchi. Em 1995, Ken Schwaber formalizou a definição do Scrum e ajudou a implantá-lo em desenvolvimento de software (MACEDO e DESCHAMPS, 2008). Scrum é uma metodologia objetiva, com papéis bem definidos e de fácil adaptação. Segundo o seu autor Schwaber (2004, apud MARÇAL et al., 2007) o Scrum não é um processo previsível, ele não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os problemas serão mais facilmente identificados através do framework e do conjunto de práticas oferecidos. O framework do Scrum é composto em papéis, cerimônias e artefatos. A Figura 5 ilustra as atividades que compõe cada item do framework. 2 Rugby é um jogo praticado na Inglaterra, composto por oito jogadores em cada time. O Scrum é um termo utilizado no Rugby e consiste em colocar a bola em jogo novamente através do trabalho em equipe. 13
23 Figura 5. Framework do Scrum Fonte: Bernabo (2007) Papéis no Scrum O Scrum, como qualquer outra metodologia, é baseado em papéis e responsabilidades, sendo, estas mais abrangentes e direcionadas para atingir o sucesso do projeto (YOSHIMA, 2007). A metodologia Scrum define basicamente três papéis: Product Owner, Scrum Master e Scrum Team, apresentados a seguir (MARÇAL et al., 2007) Product Owner Product Owner significa dono do produto. É o cliente ou um importante interessado do projeto, que representa os interesses de todos os envolvidos com o software. Suas principais responsabilidades são (MARÇAL et al., 2007): Definir as características e funcionalidades do produto; Concentrar as informações vindas das pessoas envolvidas no projeto ou do mercado, de maneira que se obtenha uma visão única dos requisitos do sistema; A maior responsabilidade é o ROI (Return on Investment) do projeto; Priorizar as funcionalidades do projeto de acordo com as necessidades dos usuários; Solicitar alterações a serem implementadas nas próximas iterações; e Aceitar ou rejeitar os resultados de cada iteração. 14
24 Scrum Master O Scrum Master desempenha um papel de liderança, gerenciando os interesses do Product Owner mediante o time. Comparando com uma abordagem tradicional de gerenciamento de projetos, o Scrum Master seria um gerente de projetos. O Scrum Master possui como responsabilidades (YOSHIMA, 2007): Promover a criatividade e conhecimento do time visando aumento de produtividade; Estimular uma comunicação cooperação entre as pessoas do time; Garantir o desenvolvimento do projeto no prazo e custo; Realizar reuniões de acompanhamento (Daily Scrum, Sprint, Review e Sprint Retrospective); Auxiliar o Product Owner a maximizar a produtividade atingindo os seus objetivos com o Scrum; Facilitar a colaboração entre as funções e áreas e eliminar os impedimentos do time; Proteger o time de interferências externas; Controlar as tarefas realizadas, em andamento, concluídas e o surgimento de novas tarefas; e Atualizar o Burndown Chart Scrum Team O Scrum Team é um grupo de pessoas responsável em desenvolver as funcionalidades do projeto. Suas características são (MARÇAL et al., 2007): Multi-funcional e auto-organizável. O time deve ter capacidade e o conhecimento técnico sobre todo o processo de desenvolvimento do produto; Entre 7 a 9 pessoas; Seleciona, entre os itens priorizados, os que serão executados durante cada iteração; e Demonstra as funcionalidades do produto e os resultados obtidos ao Product Ower. 15
25 2.4.2 Estrutura do Processo Scrum O Scrum define conceitos importantes referentes à aplicação da metodologia no desenvolvimento do projeto. Esses conceitos fundamentam práticas para definir a estratégia de desenvolvimento do projeto e fornecem visibilidade do andamento dos trabalhos e previsibilidade do que acontecerá. A Figura 6 ilustra o fluxo de desenvolvimento no Scrum (YOSHIMA, 2007). O fluxo no Scrum inicia com a definição da lista de funcionalidades que deverão ser implementadas, essa lista é chamada de Product Backlog. Para cada iteração ou Sprint, é realizada uma reunião inicial de planejamento chamada de Sprint Planning Meeting, onde os itens desta lista são priorizados pelo cliente, no Scrum chamado de Product Owner. A equipe define quais funcionalidades poderão ser atendidas dentro da iteração de acordo com a capacidade da mesma. Essa lista planejada para a iteração é chamada de Sprint Backlog (TAVARES, 2008). Diariamente, durante a Sprint, a equipe faz uma reunião chamada Daily Meeting que ajuda a manter a comunicação do time sobre o andamento do projeto, disseminar conhecimento e identificar impedimentos. No final de cada Sprint, na reunião chamada Sprint Review, a equipe apresenta as funcionalidades que foram desenvolvidas durante a Sprint. Esse ciclo se repete várias vezes até que o Product Backlog seja atendido (TAVARES, 2008). Esses conceitos são melhor apresentados na seções a seguir. Figura 6. Fluxo do Scrum Fonte: Pereira (2008). 16
26 Sprint O Scrum é baseado em iterações chamadas de Sprints. As Sprints podem ter de duas a quatro semanas de duração e, ao final desse período uma parte do projeto é demonstrada ao Scrum Owner. Essa demonstração é importante para avaliar o andamento do projeto, verificar se os requisitos exigidos estão sendo desenvolvidos e avaliar a produtividade da equipe (MARÇAL et al., 2007) Time Boxing O Time Boxing é todo um espaço de tempo definido e cronometrado que faz com que a equipe se concentre nas atividades importantes, sem gastar tempo com tarefas desnecessárias para o objetivo. Por exemplo, um Sprint com período de 30 dias ou reuniões diárias de 15 minutos representam um Time Box, ou seja, o tempo definido para execução de cada tarefa no Scrum (YOSHIMA, 2007) Product Backlog O conceito mais importante no Scrum é o Backlog do produto (Product Backlog). O Product Backlog contém uma lista de itens definidos e priorizados pelo Product Owner, que incluem os requisitos funcionais e não funcionais de um sistema. Os itens do Product Backlog são chamados de histórias e todos os envolvidos no projeto podem inclui-lás, porém somente o Product Owner pode priorizá-las. Essa lista não precisa ser definida por completa no início do projeto, podendo ser complementada com novas funcionalidades à medida que aumenta o conhecimento no produto. Normalmente, no início do projeto, essa lista contém somente os itens necessários para o desenvolvimento do primeiro Sprint. A ordenação da lista Product Backlog é por ordem de prioridade, ou seja, no topo da lista estão os itens mais prioritários (TAVARES, 2008). Outro item importante do Scrum é o Backlog de Impedimentos (Impediment Backlog), uma lista que contém todos os itens que impedem o progresso do projeto e geralmente estão associados a riscos. Estes itens não possuem uma priorização, mas estão associados a algum item de Backlog do produto ou a tarefas do item. O Scrum Master deve ter controle sobre esses itens, possibilitando ao time desenvolver o Backlog do produto sem impedimentos (MARÇAL et al., 2007). A Figura 7 exemplifica itens do Product Backlog que deverão ser priorizados e estimados pelo Product Owner e pela equipe do projeto respectivamente. 17
27 Figura 7. Product Backlog Fonte: Albuquerque (2007) Priorização do Product Backlog pelo Product Owner Após o desenvolvimento do Backlog do Produto os itens devem ser priorizados. A Figura 8 ilustra um exemplo de priorização baseado na importância dos itens do Backlog para o Product Owner. Esse método de priorização é nomeado por alguns autores como método MoSCoW Must, Should, Could, Want, e consiste em numerar os requisitos de acordo com sua importância (ALBUQUERQUE, 2007). Figura 8. Priorização do Product Backlog Fonte: Albuquerque (2007). 18
28 Outra forma de priorizar os requisitos consiste em numerar os itens de acordo com a sua importância. A Figura 9 ilustra a importância dos requisitos usados como exemplo na Figura 8 (os itens de menor valor são os mais importantes). Figura 9. Importância do Product Backlog Fonte: Albuquerque (2007) Estimativa do Product Backlog Antes de iniciar a reunião do planejamento é preciso ter o Backlog priorizado e estimado. Uma técnica objetiva é o Planning Poker que pode ser usada onde a estimativa pode ser feita em horas/tamanho (MARÇAL et al., 2007). O Planning Poker é uma forma de estimativa em conjunto, podendo ser feita como um jogo. Todos os membros do time, inclusive o Product Owner, participam de forma democrática para chegar a um consenso de estimativa, para cada item do Backlog. O primeiro passo do jogo é fornecer para cada membro da equipe um conjunto de cartas baseado na seqüência numérica de Fibonacci (1,2,3,5,8,13,..). A escolha dessa seqüência esta ligada aos gaps que são maiores à medida que os números aumentam, ou seja, os números maiores têm menos granularidade, deixando visível a diferença entre os itens à medida que eles se distanciam (ALBUQUERQUE, 2007). O jogo é iniciado selecionando o item do Backlog que o Product Owner e o time acreditam que seja o mais fácil de implementar, e a ele é associado o menor número da seqüência. Depois o próximo item é selecionado, e é comparando o seu grau de dificuldade com os dos itens já estimados. Nesse momento cada membro da equipe seleciona uma carta que represente o grau de dificuldade associado ao item e espera até que os outros participantes terminem suas seleções. 19
29 Quando todos terminaram as cartas são exibidas e se houver um consenso geral nas seleções feitas, o número da carta que corresponde ao tamanho é associado ao item. Em caso de divergência, é necessário que os participantes expliquem o motivo de sua escolha, para que todos possam repensar e validar a sua escolha. Após a finalização dessa discussão, uma nova rodada é realizada para que todos tenham oportunidade de reavaliar seus julgamentos. Esse processo continua até que os membros participantes seguem em um consenso. O Scrum Master é responsável em organizar as discussões para que sejam produtivas e organizadas. Esse ciclo é seguido até que todos os itens do Backlog sejam estimados (MARÇAL et al., 2007). A Figura 10 ilustra uma equipe estimando, através do Planning Poker, valores para cada história do Product Backlog. Figura 10. Estimando o Product Backlog através do Planning Poker Fonte: Pereira (2008) Sprint Backlog É uma lista que contém as tarefas que o Scrum Team irá trabalhar durante a Sprint. Os itens do Product Backlog, priorizados pelo Product Owner, são quebrados em tarefas que formam o Sprint Backlog. Cada tarefa deve ser estimada pela equipe quanto ao número de horas necessário para completá-la, normalmente as tarefas são completadas em até 16 horas. É responsabilidade da equipe manter a lista atualizada diariamente com as tarefas concluídas, e a estimativa de tempo necessário para a conclusão das tarefas em andamento (TAVARES, 2008). 20
30 Execução da Sprint Uma Sprint inicia com um dia de planejamento que ocorre em duas partes. Nesse dia todos os envolvidos no projeto planejam quais serão os objetivos a serem realizados nos próximos 28 dias (caso a Sprint tenha 30 dias). Após o planejamento a equipe trabalha no desenvolvimento do projeto. No último dia da Sprint, o produto desenvolvido pelo time é avaliado juntamente com o Product Owner e uma reunião de Retrospectiva é realizada, com o intuito de discutir as lições apreendidas e definir ajustes necessários ao processo. A Figura 11 ilustra a estrutura de execução de uma Sprint e seus conceitos são discutidos a seguir (YOSHIMA, 2007). Figura 11. Estrutura de uma Sprint Fonte: Yoshima (2007) Planejamento da Sprint (Sprint Planning Meeting) A reunião de planejamento da Sprint é a primeira reunião que ocorre e acontece em duas partes, cada uma dela com Time-Box de quatro horas. Na primeira parte da reunião de planejamento o Scrum Master reúne-se com o Product Owner para verificar qual é o Product Backlog, focando no ROI (Retorno sobre Investimento) do projeto. Na segunda parte do planejamento o Scrum Master se reúne com o time e com o Product Owner para planejar o Sprint Backlog. Para escolher os itens que irão compor o Sprint Backlog a equipe estima o Product Backlog, definindo complexidade e prazo das tarefas (YOSHIMA, 2007). A Figura 12 ilustra a Reunião de Planejamento da Sprint e as atividades desenvolvidas em cada parte. 21
31 Figura 12. Planejamento da Sprint Fonte: Pereira (2008) Gerenciamento da Sprint Backlog Durante a execução da Sprint, a alocação de recursos para cada tarefa é dirigida pelo próprio time, cada membro da equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e dependência entre elas. Um fator importante de sucesso para o time com o uso do Scrum é o controle da disciplina. O time é considerado auto-gerenciável, e deve responder como tal. Para isto todos os membros do time devem reportar as horas utilizadas em tarefas para que o valor de horas restantes seja calculado corretamente e o time possa verificar o seu progresso. Para esse acompanhamento o time usa um gráfico chamado de Sprint Burndown. O Sprint Burndown exibe o progresso diário do time em função do total de horas estabelecido e é explicado a seguir (YOSHIMA, 2007). A Figura 13 mostra uma maneira de controlar a execução dos itens da Sprint Backlog através do uso de um quadro de trabalho. O objetivo é organizar as atividades dos itens do Sprint Backlog em quatro estados: para fazer, em andamento, para verificar e concluído (MARÇAL et al., 2007). 22
32 Figura 13. Controle da Sprint Backlog Fonte: Pereira (2008) Burndown Chart O gráfico de Burndown é o principal artefato para acompanhamento do andamento da Sprint. Ele é gerado com base nas atualizações diárias da equipe com o status das tarefas, e no número de horas restantes para a conclusão de cada tarefa. A soma de horas das tarefas determina a quantidade de horas necessárias para finalizar a Sprint, e conforme as tarefas são concluídas, o gráfico vai decrescendo até atingir o número de horas zero. O eixo Y representa o número total de horas estimado para a Sprint e o eixo X os dias da Sprint, de acordo com o seu tamanho. As Figura 14 e 15 representam exemplos de Burndown Charts (TAVARES, 2008). 23
33 Figura 14. Burndown Charts dias/horas Fonte: Pereira (2008). Figura 15. Burndown Charts Sprint /estimativa Fonte: Albuquerque (2007) Reunião Diária (Daily Meeting) Durante a Sprint o time controla o progresso de execução das tarefas através de reuniões diárias. Essa reunião é rápida, não mais do que 15 minutos, e o objetivo é fazer com que cada membro do time responda as seguintes perguntas feitas pelo Scrum Master (ALBUQUERQUE, 2007): O que foi feito desde ontem?; O que você planeja fazer para amanhã?; e 24
34 Você tem algum impedimento?. A reunião tem por objetivo auxiliar o Scrum Master na verificação do andamento do trabalho, manter a comunicação e sincronização do status do projeto entre os membros da equipe (YOSHIMA, 2007) Reunião de Revisão (Sprint Review) A Sprint Review é um importante ponto de inspeção da metodologia Scrum. Essa reunião de fechamento ocorre no último dia da Sprint e representa o momento em que a equipe e o Scrum Master demonstram as funcionalidades implantadas ao Product Owner. Essa reunião é importante, pois auxilia na correção de erros do projeto antes do início da nova Sprint (YOSHIMA, 2007) Reunião de Retrospectiva (Sprint Retrospective) Ao final de cada Sprint acontece a reunião de revisão. O objetivo dessa reunião é entregar o produto e realizar uma demonstração para que o Product Owner possa verificar se o produto produzido está de acordo com suas expectativas. Nessa reunião se discute como foi o desenvolvimento da Sprint e o que precisa ser melhorado (ALBUQUERQUE, 2007) Ciclo de Vida do Scrum O ciclo de vida do Scrum é baseado em três fases (SOUZA NETO, 2004): 1. Pré-Planejamento (pre-game phase): nessa fase os requisitos são descritos e priorizados no Product Backlog, a estimativa de esforço para cada requisito é realizada, definição da equipe, definição das ferramentas de desenvolvimento e estimativa de riscos do projeto; 2. Desenvolvimento (game phase): nessa fase ocorre o desenvolvimento iterativo e incremental das funcionalidades do produto através de múltiplas Sprints, reuniões diárias e de revisão; e 3. Pós- Planejamento (post-game phase): após a fase de desenvolvimento são realizadas reuniões para analisar o progresso do projeto e demonstrar o software atual para o 25
35 Product Owner. Nessa fase são realizadas as etapas de integração, testes e documentação Ferramentas O uso do Scrum é recente, por isso o mercado dispõe de poucas ferramentas. Dentre as ferramentas encontradas destacam-se: 1. Mingle; 2. Scrinch; 3. Scrum Works; e 4. ProjectKoach. A Mingle é uma ferramenta desenvolvida pelo grupo ThoughtWorks 3, uma empresa líder em desenvolvimento ágil. Entre suas funcionalidades pode-se destacar: planejamento do projeto, desenvolvimento do Product Backlog e Sprint Backlog, reuniões diárias e revisões, métricas de acompanhamento utilizando Burndown Chart, controle de velocidade de desenvolvimento, estimativas, entre outras. O Mingle é uma ótima ferramenta para gerenciamento de projetos com Scrum, porém é desenvolvida em inglês e o valor de sua licença varia de acordo com o tempo de uso e o número de usuários. O Scrinch é uma ferramenta desenvolvida em Java e distribuída pela SourceFourge 4. A ferramenta é gratuita, porém desenvolvida em inglês e com interface de difícil utilização. Suas funcionalidades contemplam: desenvolvimento do Product Backlog e Sprint Backlog, definição do time de desenvolvedores, definição do Time Boxing da Sprint, controle de velocidade, priorização e estimativa do Product Backlog, entre outras. O ScrumWorks é uma ferramenta desenvolvida pela empresa Danube 5. Existem duas versões dessa ferramenta disponíveis: ScrumWorks Pro (versão paga) e Scrum Works Basic (versão grátis). A ferramenta paga possui as funcionalidades básicas do Scrum, porém é desenvolvida em inglês. 3 Mingle. Disponível em < Acesso em 24 out Sprinch. Disponível em < >. Acesso em 24 out Scrum Works. Disponível em < Acesso em 24 out
36 A ferramenta ProjectKoach é desenvolvida pela Good Software Inc 6, é gratuita e de fácil utilização, porém seu idioma é o inglês. Entre suas funcionalidades destacam-se: planejamento de Sprints, inclusão de tarefas, estimativa de tempo de duração de cada tarefa e definição do time. Essa ferramenta não contempla todas as funcionalidades do Scrum, como por exemplo, Burndown Chart, reuniões diárias, revisão e planejamento da Sprint. Essa ferramenta evidencia o controle do escopo do projeto. Os softwares testados foram o Scrinch, o ProjectKoach e a versão grátis do Mingle. O ScrumWorks Basic foi instalado, mas exige certificado de licença para o funcionamento pleno. Esse certificado foi solicitado, porém a Danube não enviou a resposta com a autorização para utilização do aplicativo. As Tabela 1 e 2 demonstram a análise realizada com as principais funcionalidades avaliadas e também requisitos não funcionais. Além dos softwares avaliados, a tabelas contêm a solução proposta pelo presente TCC. O softwares ScrumWorks está sendo avaliado de acordo com as informações fornecidas no site do aplicativo. Tabela 1. Funcionalidades dos Softwares Avaliados e da Ferramenta Proposta Ferramenta Criação de Sprints Criação Product Backlog Criação Sprint Backlog Prioriza estima Tarefas Criação de Time Burndown Chart Mingle Sim Sim Sim Sim Não Sim Scrinch Sim Não Sim Sim Sim Sim Scrum Works Sim Sim Sim Sim Sim Não Identificado ProjectKoach Sim Não Sim Não Sim Não Ferramenta Proposta Sim Sim Sim Sim Sim Não 6 ProjectKoach. Disponível em < Acesso em 24 out
37 Tabela 2. Características Gerais dos Softwares Avaliados e da Ferramenta Proposta Ferramenta Software Gratuito Plataforma Web Língua Portuguesa Mingle Não Sim Não Scrinch Sim Não Não Scrum Works Sim Sim Não ProjectKoach Sim Não Não Ferramenta Proposta Sim Sim Sim Através do estudo das ferramentas, foi possível identificar que as ferramentas disponíveis no mercado não contemplam todas as atividades necessárias para gerenciamento de projetos utilizando a metodologia Scrum. A ferramenta proposta, além de conter todos os artefatos do Scrum, tem como diferencial as seguintes características: será um software gratuito, código fonte aberto, voltado para a web e na língua portuguesa. 28
38 3 PROJETO A primeira atividade realizada durante a fase de Projeto foi a análise dos requisitos funcionais, não funcionais e regras de negócio que devem ser atendidos pela ferramenta. Os requisitos foram levantados com base na fundamentação teórica e no estudo das ferramentas similares, realizada no Capítulo 2. Em seguida, os casos de uso foram definidos com base nas principais operações desenvolvidas pelo usuário. Por últimos os diagramas de classes e entidade-relacionamento foram construídos. 3.1 Análise de Requisitos Durante a etapa de modelagem, realizada no TCCI, a análise dos requisitos teve o objetivo de identificar o escopo do projeto e definir as funcionalidades que o sistema deveria atender. Nessa análise, os requisitos funcionais, os não funcionais e as regras de negócio foram elicitados, documentados e analisados. Para o desenvolvimento do TCCII esses requisitos foram refinados e implementados na ferramenta, originando operações que podem ser realizadas pelo usuário. As seções seguintes apresentam o resultado desse trabalho Requisitos Funcionais Os requisitos funcionais descrevem o funcionamento do sistema e abrangem as tarefas que ele disponibilizará aos usuários. Para maior entendimento e dimensão da ferramenta, os requisitos funcionais foram divididos em três módulos: Projeto e Time, Product Backlog e Sprint. Na etapa de análise os seguintes requisitos funcionais foram identificados: Projeto e Time RF01: O sistema deverá permitir cadastrar, alterar e excluir um projeto; RF02: O sistema deverá permitir cadastrar, alterar e excluir usuários; e RF03: O sistema deverá permitir cadastrar, alterar e excluir um time. 29
39 Product Backlog RF01: O sistema deverá permitir cadastrar, alterar e excluir itens em um Product Backlog; RF02: O sistema deverá permitir priorizar os itens de um Product Backlog; RF03: O sistema deverá permitir estimar os itens de um Product Backlog; e RF04: O sistema deverá permitir cadastrar, alterar e excluir um Impediment Backlog para um item do Product Backlog. Sprint RF01: O sistema deverá permitir cadastrar e excluir uma Sprint para um projeto; RF02: O sistema deverá permitir informar a data de início e fim de uma Sprint; RF03: O sistema deverá permitir selecionar os itens do Product Backlog que irão compor a Sprint Backlog; RF04: O sistema deverá permitir cadastrar, alterar e excluir tarefas em uma Sprint Backlog; RF05: O sistema deverá permitir alocação de uma tarefa a um membro do time; RF06: O sistema deverá permitir informar a data de início e fim de cada tarefa; RF07: O sistema deverá permitir informar o tempo de duração de cada tarefa; RF08: O sistema deverá permitir informar horas trabalhadas e o status do andamento em cada tarefa; RF09: O sistema deverá permitir inserir informações sobre a reunião diária; RF10: O sistema deverá permitir inserir informações sobre a reunião de planejamento; RF11: O sistema deverá permitir inserir informações sobre a reunião de revisão; e RF12: O sistema deverá permitir inserir informações sobre a reunião de retrospectiva Requisitos Não Funcionais Os requisitos não funcionais especificam as características do software, neste caso, a linguagem de programação, o banco de dados e a plataforma utilizados. 30
40 RNF01: O sistema deve ser voltado para WEB; RNF02: O sistema deve ser desenvolvido na linguagem de programação PHP; RNF03: O sistema utilizará o Banco de Dados PostgreSQL; e RNF04: O sistema deverá solicitar ao usuário login e senha de acesso Regras de Negócio As regras de negócio definem as particularidades do funcionamento da ferramenta: RN01: O Scrum é composto por três papéis: Product Owner, Scrum Master e Scrum Team; RN02: As Sprints devem ter de 2 a 4 semanas de duração; RN03: Ao final de cada Sprint uma parte do produto deverá ser entregue; e RN04: A estimativa do Product Backlog será realizada baseando na seqüência numérica de Fibonacci. 3.2 Diagrama de Casos de Uso Os casos de uso melhoram a compreensão da análise dos requisitos, são documentos narrativos que descrevem a seqüência de eventos de um ator que usa um sistema para completar um processo (JACOBSON et al, 1992, apud LARMAN, 2000). Os casos de uso do sistema desenvolvido foram organizados em três módulos, a fim de facilitar o entendimento da modelagem. A seguir são apresentados os módulos que compõem o sistema, sendo a descrição de cada caso de uso apresentada no Apêndice A Módulo Projeto Esse módulo permite ao usuário gerenciar os cadastros básicos para iniciar as atividades na ferramenta e cadastrar, alterar ou excluir um projeto. A Figura 16 mostra a interação entre o usuário (ator) e os casos de uso que constituem esse módulo. Antes de iniciar um projeto é necessário que os usuários, cargos dos usuários e o time do projeto estejam cadastrados. 31
41 uc Pacote 1 - Módulo Proj... UC Manter Usuário UC Manter Projeto UC Manter Time Scrum Master Figura 16. Diagrama de casos de uso do módulo Projeto Módulo Product Backlog Esse módulo permite ao usuário o gerenciamento do Product Backlog do projeto. O Product Owner e o Scrum Master possuem como tarefas o gerenciamento e priorização do Product Backlog e Impediment Backlog. A estimativa do Product Backlog é realizada por todos os elementos do grupo. A Figura 17 ilustra esse módulo e as principais atividades desenvolvidas. 32
42 uc Pacote 2 - Product Backlog UC Gerenciar Product Backlog UC Gerenciar Impediment Backlog Product Ow ner Scrum Master UC Estimar Product Backlog Scrum Team Figura 17. Diagrama de casos de uso do módulo Product Backlog Módulo Controle de Sprint A Figura 18 mostra as atividades desenvolvidas no módulo Controle de Sprint. Os responsáveis por esse módulo são o Scrum Master e o Scrum Team. É função do Scrum Master gerenciar a Sprint, selecionar os itens do Product Backlog que irão compor o Sprint Backlog, acompanhar o andamento do projeto através da visualização do gráfico Burndown e auxiliar o Scrum Time a cadastrar as tarefas para cada item do Product Backlog. A função do Scrum Team é gerenciar cada tarefa, ou seja, alocar a tarefa a um membro do grupo, estimar sua duração, informar horas trabalhadas por semana e a situação da tarefa (não iniciada, em desenvolvimento, finalizada, em testes ou pendente) e gerenciar as reuniões diárias. 33
43 uc Controle de Sprint UC UC Gerenciar Reunião de Rev isão UC Gerenciar Reunião de Planejamento UC Cadastrar Sprint UC Gerenciar Reunião de Retrospectiv a Scrum Master UC Selecionar Itens do Product Backlog UC Cadastrar tarefas UC Gerenciar Reunião Diária UC AlocarTarefa Scrum Team UC Informar Status da Tarefa UC Informar Duração de Cada Tarefa UC Informar Horas Trabalhadas em Cada Tarefa Figura 18. Diagrama de casos de uso do módulo controle de Sprint 34
44 3.3 Diagrama de Classes Segundo Furlan (1998), o diagrama de classes trata-se de uma estrutura lógica estática em uma superfície de duas dimensões mostrando uma coleção de elementos declarativos de modelo, como classes, tipos e seus respectivos conteúdos e relações. A Figura 19 mostra o diagrama de classes da ferramenta proposta. class Scrum Project Projeto - Nome_Projeto: varchar - Objetivo_Projeto: varchar - Data_Inicio: date - Data_Fim: date - Valor_Projeto: decimal + Incluir_Projeto() : void + Atualizar_Projeto() : void + Deletar_Projeto() : void * 1 Time - Descrição: varchar - Código_Usuário: int - Nome_Usuário: varchar - Nome_Cargo: varchar + Incluir_Time() : void + Atualizar_Time() : void + Deletar_Time() : void + Incluir_Usuario_Time() : void 0..* 1 0..* 1..* Usuários - Nome: varchar - Data_Nasc.: date - RG: varchar - CPF: varchar - Endereço: varchar - Bairro: varchar - Cidade: varchar - CEP: integer - Estado: varchar - Telefone: varchar - Celular: varchar - varchar - Login: varchar - Senha: varchar + Incluir_Usuário() : void + Atualizar_Usuário() : void + Deletar_Usuário() : void Product Backlog - Projeto: varchar - Item_Product_Backlog: varchar - Prioridade: int - Estimativa: int - Fator_Impedimento: varchar + Incluir_Product() : void + Alterar_Product() : void + Deletar_Product() : void 1..* 1 0..* Sprint Backlog - Item_Product: varchar - Tarefa: varchar - Responsavel: varchar - Data_Inicio: date - Data_Fim: date - Horas_Estimadas: int - Semana_1: int - Semana_2: int - Semana_3: int - Semana_4: int - Status: varchar + Cadastrar_Sprint_Back() : void + Gerenciar_Tarefas() : void 0..* 0..* 1 1 Sprint - Projeto: varchar - Data_Inicio: date - Data_Fim: date + Incluir_Sprint() : void + Atualizar_Sprint() : void + Deletar_Sprint() : void * 1 Reunião Planejamento - Projeto: varchar - Apresen_Sprint: varchar 1 - Local_Reuniao: varchar - Duracao: int - Program_Prevista: varchar - Objetivo: vachar - Como_Atingir: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void Reunião Diária - Projeto: varchar - Sprint: int - Usuario: varchar - Desenvolvimento_Ontem: varchar - Desenvolvimento_Amanhã: varchar - Impedimentos: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void Reunião Retrospectiva - Projeto: varchar - Desenvolvimento: varchar - Pontos_Melhorar: varchar - Sugestões: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void 1 Reunião Revisão - Projeto: varchar - Erro_Encontrado: varchar - Status: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void Figura 19. Diagrama de classes de domínio A seguir é apresentada uma breve descrição das classes do diagrama (Figura 19): Usuário: classe que contém os dados referentes aos usuários da ferramenta; Time: essa classe contém os usuários que pertencem a um time do projeto, divididos em cargos; Projeto: é a principal classe da ferramenta, contém informações gerais referentes ao projeto; 35
45 Product_Backlog: essa classe contém a descrição dos itens que deverão ser desenvolvidos no projeto; Impediment_Backlog: contém os itens considerados fatores de impedimento para o desenvolvimento do projeto; Sprint_Backlog: essa classe contém os itens do Product Backlog quebrados em tarefas, com prazo estimado de desenvolvimento, data de início e fim e horas informadas semanalmente pelo desenvolvedor da tarefa; Sprint: guarda informações referentes às Sprints (iterações) do projeto; Reunião_Planejamento: armazena informações referentes a reunião de planejamento de cada Sprint do projeto, tais como objetivo e duração da Sprint e desenvolvedores; Reunião_Diária: classe que armazena os dados de todas as reuniões diárias que ocorreram durante o desenvolvimento da Sprint; Reunião_Retrospectiva: classe que contém informações referente a reunião de demonstração do produto realizada no final do Sprint para o cliente; Reunião_Revisão: classe que armazena as informações da reunião de revisão realizada no final do desenvolvimento de uma Sprint. 3.4 Diagrama Entidade-Relacionamento Após a definição das classes de domínio utilizadas pela ferramenta Scrum Project, foi construído o diagrama de Entidade-Relacionamento apresentando a estrutura do banco de dados. A Figura 20 apresenta esse diagrama. 36
46 dm Scrum CARGO «column» *PK CD_CARGO: integer NM_CARGO: varchar(30) DS_CARGO: varchar(100) «PK» + PK_CARGO(integer) USUARIO «column» USUARIO_TIME *PK CD_USUARIO: integer NM_USUARIO: varchar(50) «column» NR_RG: varchar(12) TIME «column» *PK CD_TIME: integer DS_TIME: varchar(100) «PK» + PK_TIME(integer) *pfk CD_TIME: integer *pfk CD_USUARIO: integer *pfk CD_CARGO: integer «FK» + FK_USUARIO_TIME_CARGO(integer) + FK_USUARIO_TIME_TIME(integer) + FK_USUARIO_TIME_USUARIO(integer) «PK» + PK_USUARIO_TIME(integer, integer, integer) NR_CPF: varchar(15) DT_NASCIMENTO: date DS_LOGRADOURO: varchar(100) NR_LOGRADOURO: integer NM_BAIRRO: varchar(30) NM_CIDADE: varchar(30) NR_CEP: integer DS_ESTADO: varchar(30) NR_TELEFONE: varchar(20) NR_CELULAR: varchar(20) DS_MAIL: varchar(50) LOGIN: varchar(20) SENHA: varchar(20) REUNIAO_REVISAO «column» *PK CD_REUNIAO_REV: integer FK CD_SPRINT: integer «FK» ITEM_REUNIAO_REVISAO «column» *PK CD_SEQ: integer FK CD_REUNIAO_REV: integer DS_ERRO: varchar(100) DS_STATUS: varchar(30) PROJETO «PK» + PK_USUARIO(integer) + FK_REUNIAO_REVISAO_SPRINT(integer) «PK» + PK_REUNIAO_REVISAO(integer) «FK» + FK_ITEM_REUNIAO_REVISAO_REUNIAO_REVISAO(integer) «PK» «column» + PK_ITEM_REUNIAO_REVISAO(integer) *PK CD_PROJETO: integer FK CD_TIME: integer NM_PROJETO: varchar(50) DS_PROJETO: varchar(200) REUNIAO_RETROSPECTIVA FK CD_USUARIO: integer DT_INICIO: date DT_FIM: date VL_PROJETO: decimal(10,2) DT_CRIACAO: date DT_ATUALIZACAO: date «column» SPRINT «column» *PK CD_REUNIAO_RETRO: integer FK CD_SPRINT: integer DS_DESENVOLVIMENTO: varchar(300) DS_SER_MELHORADO: varchar(300) DS_SUGESTAO: varchar(300) *PK CD_SPRINT: integer «FK» + FK_PROJETO_TIME(integer) + FK_PROJETO_USUARIO(integer) «PK» + PK_PROJETO(integer) * CD_PROJETO: integer DT_INICIO: date DT_FIM: date «PK» «FK» + FK_REUNIAO_RETROSPECTIVA_SPRINT(integer) «PK» + PK_REUNIAO_RETROSPECTIVA(integer) + PK_SPRINT(integer) REUNIAO_PLANEJAMENTO «column» *PK CD_REUNIAO: integer *FK CD_SPRINT: integer DS_OBJETIVO_SPRINT: varchar(200) DS_ATINGE_OBJETIVOS: varchar(300) DT_APRESENTACAO_SPRINT: date PRODUCT_BACKLOG «column» *PK CD_PRODUCT: integer *FK CD_PROJETO: integer DESCRICAO_ITEM: varchar(100) NR_PRIORIDADE: integer NR_ESTIMATIVA: integer DS_IMPEDIMENTO: varchar(100) DS_STATUS: varchar(30) SPRINT_BACKLOG «column» *FK CD_SPRINT: integer FK CD_PRODUCT: integer *PK CD_ITEM_SPRINT: integer REUNIAO_DIARIA «column» *PK CD_SEQ_REUNIAO: integer FK CD_SPRINT: integer FK CD_USUARIO: integer DT_REUNIAO: date DS_ATIVIDADE_ONTEM: varchar(200) DS_ATIVIDADE_AMANHA: varchar(200) DS_IMPEDIMENTO: varchar(300) DS_LOCAL_REUNIAO_DIARIA: varchar(50) DS_HORARIO: varchar(50) DS_AGENDA_REUNIAO: varchar(300) «FK» + FK_REUNIAO_PLANEJAMENTO_SPRINT(integer) «PK» + PK_REUNIAO_PLANEJAMENTO(integer) «FK» + FK_ITEM_PRODUCT_BACKLOG_PROJETO(integer) «PK» + PK_ITEM_PRODUCT_BACKLOG(integer) DS_TAREFA: varchar(50) NR_HORAS_EST: integer NR_HORAS_SEM_1: integer NR_HORAS_SEM_2: integer NR_HORAS_SEM_3: integer NR_HORAS_SEM_4: integer DS_STATUS: varchar(20) FK CD_USUARIO: integer DT_INICIO: date DT_FIM: date «FK» + FK_REUNIAO_DIARIA_SPRINT(integer) + FK_REUNIAO_DIARIA_USUARIO(integer) «PK» + PK_REUNIAO_DIARIA(integer) CD = CÓDIGO DS = DESCRIÇÃO DT = DATA NM = NOME NR = NÚMERO VL = VALOR «FK» + FK_ITEM_SPRINT_PRODUCT_BACKLOG(integer) SEM = SEMANA EST = ESTIMADA + FK_ITEM_SPRINT_SPRINT(integer) + FK_SPRINT_BACKLOG_USUARIO(integer) «PK» + PK_ITEM_SPRINT(integer) Figura 20 - Diagrama de entidade-relacionamento do banco de dados 4 DESENVOLVIMENTO Este capítulo descreve o desenvolvimento da ferramenta Scrum Project, apresentando o framework utilizado para seu desenvolvimento e a apresentação das telas e funcionalidades disponíveis. 4.1 Implementação da Ferramenta O desenvolvimento da ferramenta foi realizado focando sua utilização em ambiente web, objetivando independência de plataforma e maior disponibilidade aos usuários. Para isso, utilizouse o framework de desenvolvimento ScriptCase e o banco de dados PostgreSQL. Optou-se por esse framework por ser uma ferramenta nacional, com documentação e suporte em português, pela 37
47 agilidade e redução no tempo de desenvolvimento oferecido e compatibilidade com o banco de dados utilizado e por desenvolver os sistemas em PHP (Hypertext Preprocessor) Framework ScriptCase O ScriptCase é um ambiente de desenvolvimento de aplicações web de forma rápida e eficiente, reduz tempo para desenvolvimento e manutenção e permite a criação de novos sistemas utilizando formulários, consultas, relatórios e menus. O ScriptCase suporta os bancos de dados mais usados no mercado como Oracle, DB2, SQLServer, MySQL, PostgreSQL e Sybase. O código-fonte da aplicação é em PHP com JavaScript e fazem uso da tecnologia Ajax para permitir a transferência de dados sem a necessidade de recarga da interface, tornando menor o tempo de resposta das operações realizadas. As aplicações rodam independente da ferramenta sendo compatíveis com Windows, Unix, AS/400, entre outros (NETMAKE, 2009). A Figura 21 representa uma visão do funcionamento desse framework. Figura 21 - Framework ScriptCase Fonte: Netmake (2009). O ScriptCase pode ser obtido através da internet, sob licença acadêmica ou download da versão trial com licença para 30 dias de uso. A Figura 22 mostra a tela inicial do ScriptCase. 38
48 Figura 22. Tela inicial ScriptCase Fonte: Netmake (2009). 4.2 A Ferramenta Scrum Project A ferramenta Scrum Project foi desenvolvida de acordo com a modelagem entidaderelacionamento apresentada na seção 3.4, tendo em vista o cumprimento dos requisitos e regras de negócio definidos. Nas próximas seções é apresentado o resultado desse trabalho Acesso ao Sistema O acesso dos usuários ao sistema é controlado através de autenticação de login e senha previamente cadastrados. A Figura 23 apresenta a tela inicial do ambiente, na qual o usuário informa seu login e senha e é feita a validação dos dados informados. 39
Géssica Talita. Márcia Verônica. Prof.: Edmilson
Géssica Talita Márcia Verônica Prof.: Edmilson DESENVOLVIMENTO ÁGIL Técnicas foram criadas com o foco de terminar os projetos de software rapidamente e de forma eficaz. Este tipo de técnica foi categorizada
Leia maisDesenvolvimento Á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 maisUma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br
Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish
Leia maisScrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE
Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.
Leia maisAlexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes
Instituto Federal do Rio Grande do Norte IFRN Graduação Tecnologia em Analise e Desenvolvimento de Sistema Disciplina: Processo de Desenvolvimento de Software Scrum Alexandre Lima Guilherme Melo Joeldson
Leia maisApós completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades
Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do
Leia maisSCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br
SCRUM Otimizando projetos Adilson Taub Júnior tecproit.com.br Sobre mim Adilson Taub Júnior Gerente de Processos Certified ScrumMaster; ITIL Certified; Cobit Certified; 8+ anos experiência com TI Especialista
Leia maisManifesto Á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 maisPONTIFÍ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 maisAluna: Vanessa de Mello Orientador: Everaldo Artur Grahl
Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação
Leia maisSCRUM Discussão e reflexão sobre Agilidade. Fernando Wanderley
SCRUM Discussão e reflexão sobre Agilidade Fernando Wanderley Apresentação Líder Técnico em Projetos Java (~ 9 anos) (CESAR, Imagem, CSI, Qualiti Software Process) Consultor de Processos de Desenvolvimento
Leia maisMetodologias Á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 maisSCRUM 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 maisManifesto Á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 maisWesley Torres Galindo. wesleygalindo@gmail.com
Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman
Leia maisScrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.
Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização
Leia maisGerenciamento de Equipes com Scrum
Gerenciamento de Equipes com Scrum Curso de Verão 2009 IME/USP www.agilcoop.org.br Dairton Bassi 28/Jan/2009 O que é Scrum? Processo de controle e gerenciamento Processo iterativo de inspeção e adaptação
Leia maisWesley Torres Galindo
Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar
Leia maisMANIFESTO Á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 maisEngenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org
Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming
Leia maisENGENHARIA 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 maisO 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 maisSCRUM. 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 maisMETODOLOGIA 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 maisCom 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 maisExpresso Livre Módulo de Projetos Ágeis
Expresso Livre Módulo de Projetos Ágeis Desenvolvedor / Orientador Rafael Raymundo da Silva Guilherme Lacerda Out / 2010 1 Sumário 1.Conhecendo a ferramenta...3 2.Gerência de projetos ágeis...3 2.1Product
Leia maisScrum. Gestão ágil de projetos
Scrum Gestão ágil de projetos Apresentação feita por : Igor Macaúbas e Marcos Pereira Modificada por: Francisco Alecrim (22/01/2012) Metas para o o Metas para treinamento seminário Explicar o que é Scrum
Leia maisTópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619
Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o
Leia maisAnálise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software
Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Carolina Luiza Chamas Faculdade de Tecnologia da Zona Leste SP Brasil carolchamas@hotmail.com Leandro Colevati dos
Leia maisEXIN Agile Scrum Fundamentos
Exame Simulado EXIN Agile Scrum Fundamentos Edição Fevereiro 2015 Copyright 2015 EXIN Todos os direitos reservados. Nenhuma parte desta publicação pode ser publicado, reproduzido, copiado ou armazenada
Leia maisA Disciplina Gerência de Projetos
A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos
Leia maisDISCIPLINA 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 maisAUTOR: 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 maisProfessor: Curso: Disciplina:
Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos
Leia maisGestão de Projetos com Scrum
Gestão de Projetos com Scrum Curso de Verão - Jan / 2010 IME/USP - São Paulo Dairton Bassi dbassi@gmail.com Processo de gerenciamento de projetos. Processo iterativo de inspeção e adaptação. Usado para
Leia maisProposta. Treinamento Scrum Master Gerenciamento Ágil de Projetos. Apresentação Executiva
Treinamento Scrum Master Gerenciamento Ágil de Projetos Apresentação Executiva 1 O treinamento Scrum Master Gerenciamento Ágil de Projetos tem como premissa preparar profissionais para darem início às
Leia maisMódulo de projetos ágeis Scrum Módulo de Projetos Ágeis Scrum
Módulo de Projetos Ágeis Fevereiro 2015 Versão Módulo de Projetos Ágeis O nome vem de uma jogada ou formação do Rugby, onde 8 jogadores de cada time devem se encaixar para formar uma muralha. É muito importante
Leia maisProcesso 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 maisPROCESSO 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 maisEngenharia 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 maisDesenvolvimento Ágil sob a Perspectiva de um ScrumMaster
Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster Danilo Sato e Dairton Bassi 21-05-07 IME-USP O que é Scrum? Processo empírico de controle e gerenciamento Processo iterativo de inspeção e adaptação
Leia maisAPLICACAÇÃ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 maisARCO - 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 maisProjeto de Sistemas I
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o
Leia maisANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM
ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM Peterson Vieira Salme 1, Claudete Werner 1 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil petersonsalme@gmail.com, claudete@unipar.br
Leia maisO Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto
O Guia Passo-a-Passo para IMPLANTAR Em seu próprio Projeto Aprenda como Agilizar seu Projeto! A grande parte dos profissionais que tomam a decisão de implantar o Scrum em seus projetos normalmente tem
Leia maisO modelo unificado de processo. O Rational Unified Process, RUP.
Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,
Leia maisUTILIZAÇÃ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 maisFerramenta 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 maisMETODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI
METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI HISTÓRICO DE REVISÕES Data Versão Descrição Autor 02/04/2014 1.0 Versão Inicial Ewertton Bravo 27/08/2014 1.1 Alteração da Imagem
Leia maisGARANTIA 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 maisGovernança de TI. ITIL v.2&3. parte 1
Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços
Leia maisSCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.
SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que
Leia maisMetodologias 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 maisSCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)
SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features
Leia maisMetodologia de Gerenciamento de Projetos da Justiça Federal
Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...
Leia maisScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação
ScRUM na prática Scrum no dia-a-dia V Semana de Tecnologia da Informação Agenda Manifesto Ágil; O Scrum; Os papéis do Scrum; Quem usa Scrum; O Scrum na Tray; Cerimônias; Artefatos. Qualidade. era uma vez
Leia maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
Leia maisIdeal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?
Significado de XP? Extreme Programming (Programação Extrema). Ideal para que tipo de empresa (equipe): pequena, média, grande? Pequenas e Médias. Em software onde os requisitos não são conhecidos é recomendado
Leia maisEngenharia 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 maisPLANEJAMENTO E PROJETOS. Lílian Simão Oliveira
PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos
Leia mais! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado
Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo
Leia maisMÓ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 maisObjetivos do Módulo 3
Objetivos do Módulo 3 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Conceitos do Scrum O que é um Sprint Decifrando um Product backlog Daily Scrum, Sprint Review, Retrospectiva
Leia maisSistemas 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 maisINTRODUÇÃO AOS MÉTODOS ÁGEIS
WESLLEYMOURA@GMAIL.COM INTRODUÇÃO AOS MÉTODOS ÁGEIS ANÁLISE DE SISTEMAS Introdução aos métodos ágeis Metodologias tradicionais Estes tipos de metodologias dominaram a forma de desenvolvimento de software
Leia maisFeature-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 maisFaculdade Pitágoras. Engenharia de Software. Prof.: Julio Cesar da Silva. juliocesar@tecnocracia.eti.br. Http://e-academy.com.br
Faculdade Pitágoras Engenharia de Software Prof.: Julio Cesar da Silva juliocesar@tecnocracia.eti.br Http://e-academy.com.br Evolução do Software (1950 1965) - O hardware sofreu contínuas mudanças - O
Leia maisProf. 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 maisMetodologia SCRUM. Moyses Santana Jacob RM 63484. Stelvio Mazza RM 63117. Tiago Pereira RM 63115. Hugo Cisneiros RM 60900
Metodologia SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484 Stelvio Mazza RM 63117 Tiago Pereira RM 63115 SCRUM? O que é isso? SCRUM é um modelo de desenvolvimento ágil de software que fornece
Leia maisPó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 maisCaso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho
Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho UOL Produtos Rádio UOL Julho 2008 André Piza Certified Scrum Master Agenda Scrum como método
Leia maisJonas de Souza H2W SYSTEMS
Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição
Leia maisCapítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1
Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de
Leia maisDesenvolvimento Á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 maisScrum How it works. Há quatro grupos com papéis bem definidos:
Scrum É um processo de desenvolvimento iterativo e incremental. É utilizado quando não se consegue predizer tudo o que irá ocorrer. Em geral, utiliza-se em projetos complexos, de difícil abordagem pela
Leia maisCampus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /
Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e
Leia maisRESUMO 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 maisUML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2
UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem
Leia maisGestão Ágil de Requisitos e Scrum
Gestão Ágil de Requisitos e Scrum Agilidade na gestão de requisitos e desenvolvimento de softwares... Trabalho apresentado na disciplina Introdução à Computação, curso de Tecnologia em Análise e Desenvolvimento
Leia maisTó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 maisEngenharia 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 maisPRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17
PRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17 Índice 1. Conceitos de Ciclo de Desenvolvimento de Sistemas...3 1.1. Principais Fases... 3 1.2. Técnicas... 4 1.3. Papéis de Responsabilidades... 4 1.3.1.
Leia maisUNIDADE 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 maisRequisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis
Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade
Leia maisMDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI
MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo
Leia maisAgenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria
Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos
Leia maisProcesso de Desenvolvimento Unificado
Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas
Leia maisA PRIMMER possui casos importantes nesta área. Venha compartilhar conosco desta experiência magnífica no mundo das metodologias ágeis.
METODOLOGIAS ÁGEIS Boas Práticas para o Gerenciamento de Projetos de TI utilizando métodos ágeis baseados em SCRUM e XP etc. DIFERENCIAIS Avaliação prévia das necessidades de cada participante para customização
Leia maisNome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO A4 DATA 23/04/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA
Leia maisUniversidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias
Leia maisPROJETO DE FÁBRICA DE SOFTWARE
FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...
Leia maisDISCIPLINA 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 maisMétodo Aldeia de Projetos
MAP Método Aldeia de Projetos Como surgiu o MAP? Em mais de 15 anos de atuação experimentamos distintas linhas de pensamento para inspirar nosso processo e diversas metodologias para organizar nossa forma
Leia maisIntrodução à Engenharia de Software
Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia
Leia maisdevelopment 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 maisComo 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 maisReferências internas são os artefatos usados para ajudar na elaboração do PT tais como:
Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código
Leia maisCiclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental
CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti
Leia mais