P. 1
Monografia Gerenciamento de Projetos

Monografia Gerenciamento de Projetos

|Views: 2.427|Likes:
Publicado porfilii

More info:

Published by: filii on Jun 19, 2011
Direitos Autorais:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

07/02/2013

pdf

text

original

Sections

  • 1.1.1Partes envolvidas no Projeto de Software
  • 1.1.2O Processo do Gerenciamento do Projeto de Software
  • 1.1.3.1Gerenciamento de Integração
  • 1.1.3.2Gerenciamento de Requisitos
  • 1.1.3.3Gerenciamento de Escopo
  • 1.1.3.4Gerenciamento de Tempo
  • 1.1.3.5Gerenciamento de Custos
  • 1.1.3.6Gerenciamento de Qualidade
  • 1.1.3.7Gerenciamento de Recursos Humanos
  • 1.1.3.8Gerenciamento de Comunicações
  • 1.1.3.9Gerenciamento de Aquisições
  • 1.2.JUSTIFICATIVA
  • 1.3.1Objetivo Geral
  • 1.3.2Objetivos Específicos
  • 1.4.METODOLOGIA DE PESQUISA
  • 1.5.INTRODUÇÃO
  • 1.6.HISTÓRICO
  • 1.7.CONSIDERAÇÕES SOBRE METODOLOGIA E MÉTODO
  • 1.8.METODOLOGIAS DE GERENCIAMENTO DE PROJETOS
  • 1.9.1.1Papéis do SCRUM
  • 1.9.1.2Etapas de um Projeto com SCRUM
  • 1.9.2Extreme Programming (XP)
  • 1.9.3FDD
  • 1.9.4TDD

CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM GERENCIAMENTO DE PROJETOS

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS

CAMPOS DOS GOYTACAZES/RJ 2011

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS

Monografia apresentada a FIJ – Faculdades Integradas Jacarepaguá, como requisito para conclusão do Curso de Pós-Graduação lato sensu em Gerenciamento de Projetos.

Orientador: Jorge Washington S. dos Santos

CAMPOS DOS GOYTACAZES/RJ 2011

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MÉTODOS ÁGEIS

Monografia apresentada a FIJ – Faculdades Integradas Jacarepaguá, como requisito para conclusão do Curso de Pós-Graduação lato sensu em Gerenciamento de Projetos.

Aprovada em xx de xxxxxxxx de 2011. Banca Avaliadora:

....................................................................................................................................... Prof. Jorge Washington S. dos Santos

....................................................................................................................................... Prof.

....................................................................................................................................... Prof.

CAMPOS DOS GOYTACAZES/RJ 2011

AGRADECIMENTOS

Primeiramente agradeço a Deus, Doutor e Mestre por essência e excelência. Aos parentes e amigos que estiveram sempre presentes a apoiar-me em minhas dificuldades, bem como fornecer o devido auxílio, seja ele moral ou material. Enfim, a todos que colaboraram de alguma forma para que este trabalho fosse concluído com êxito.

Johann Wolfgang Von Goethe .As dificuldades crescem à medida que nos aproximamos do nosso objetivo.

RESUMO Este trabalho destina-se a fazer uma abordagem sistemática dos métodos de gerenciamento de projetos. . voltados especificamente para a área de desenvolvimento de software. visando atender as necessidades dos clientes. Descreveremos os métodos mais importantes e suas respectivas vantagens e desvantagens.

. We describe the most important methods and their advantages and disadvantages. to meet customer needs.ABSTRACT This work is intended to make a systematic approach to project management methods. specifically tailored to the area of software development.

LISTA DE ABREVIATURAS .

LISTA DE FIGURAS .

SUMÁRIO .

é um empreendimento temporário com o objetivo de criar um produto ou serviço único. tornamo-nos parte de um sistema onde gerenciamos ou somos gerenciados. Estamos diante de pessoas mais exigentes e criteriosas com relação a produtos e serviços. eles são divididos em projetos e tarefas. . com isso. Dessa forma. Aquele. dessa forma tornando o mercado mais competitivo e. onde aqueles que ficaram estagnados no tempo perderam seus lugares para outros que procuraram acompanhar tamanha evolução. envolvendo planejamento. em sua essência. diferente dos outros. Assim sendo. faz-se necessário que nos detenhamos na utilização de recursos que nos levarão à realização efetiva daquilo para o qual fomos designados ou contratados. A competitividade nos mercados internacionais é fator preponderante dessa nova realidade. Para que possamos atender as expectativas inseridas no contexto da demanda atual. segundo define o PMBOK (2004). INTRODUÇÃO A era de Globalização trouxe consigo mudanças que têm afetado sobremaneira os diversos processos de Gerenciamento de Projetos. Em toda organização são desenvolvidos algum tipo de trabalho e esses são executados por pessoas – em maior ou menor número. criando expectativas maiores no que se refere à agilidade e qualidade. dependendo deles -. a temporalidade aqui. temos que nos atualizar e nos adaptar aos novos rumos prescritos pela Era Moderna.1. Diante disso. forçosamente. significa que ele depois de concluído é. que em certas áreas é tão rápida que se não estivermos atentos nos distanciaremos dela. recursos e controle.

consistindo de um grupo de atividades coordenadas e controladas com datas para início e término. custo e qualidade. é necessário 1 Stakeholders são pessoas ou organizações que são afetadas pelo sistema e que tem influência direta ou indireta nos requisitos do sistema [PMBOK (2004)]. conforme requisitos específicos. consumindo recursos e operando sob pressões de prazo. KERZNER (2005). Ainda no tocante à definição de projeto. empreendido para alcance de um objetivo. com o intuito de satisfazer ou exceder as necessidades e as expectativas dos stakeholders1 Como este trabalho está voltado para a área de software. custos e recursos. A ABNT (NBR 10006) define que projeto é um processo único. Pressman também diz que para que um projeto de software seja bem sucedido. podemos citar. . que define projeto como um empreendimento com objetivos bem definidos. da concepção à obtenção do produto. segundo o Project Management Body of Knowledge (PMBOK.A alocação de recursos e o tempo de execução de um projeto são fatores determinantes para avaliar sua complexidade e nos levar a agir para que efetivamente levemos a cabo sua conclusão. 2004) é a aplicação de conhecimentos. A Gerência de Projetos é definida. podemos acrescentar a definição de Gerência de Projetos dada por Pressman (1995) que diz que ela é uma tarefa de vital importância no processo de desenvolvimento de um produto. desde que ela acompanha todas as etapas do desenvolvimento. incluindo limitações de tempo. ou seja. sendo definida como a primeira camada deste processo e não é visto como uma etapa clássica do desenvolvimento. por exemplo. ferramentas e técnicas em atividades do projeto. habilidades.

o Software Engineering Institute (SEI). O Relatório Chaos realizado pelo Standish Group (1995) identificou que as empresas americanas gastaram $ 81 milhões em projetos de software que foram . os indicadores a serem acompanhados. por falta de recursos ou acesso à tecnologia. os riscos envolvidos. Começaremos falando sobre pesquisas realizadas na década de 90. as tarefas a serem realizadas. Darci Prado (PRADO. onde eram demonstradas que as principais causas do fracasso – falhas na execução e atraso na entrega – de um projeto de software estariam ligadas ao desempenho do gerenciamento do projeto. ao analisar os projetos de TI que falharam. mas também de todos os integrantes da equipe.que alguns parâmetros sejam corretamente analisados. mas antes por falta de conhecimento em gestão de projetos e que esse não é aplicado somente à figura do gestor. fala sobre o Relatório Chaos Report (2004). 1. afirma que isto não aconteceu. em sua maioria. No ano de 1993.1. em seu livro intitulado ‘Maturidade em Gerenciamento de Projetos’. 2008). torna-se necessário falarmos um pouco sobre o gerenciamento de projetos de software. GERENCIAMENTO DE PROJETO DE SOFTWARE Para que possamos nos deter com maior profundidade no tema deste trabalho. verificou que o problema de maior relevância que preocupa as organizações de software é aquele relacionado com o aspecto gerencial. os recursos necessários. a saber: o escopo. os recursos e custos aplicados e a sistemática que deverá ser seguida.

Clientes.Usuários. considerando-se que a boa formação de uma equipe depende disto. Os papéis de cada um devem ser bem definidos.cancelados em 1995. a saber: . No que se refere às pequenas e médias empresas.Gerente de Projeto. Também deve-se levar em conta alguns . mas com os mesmos objetivos. . Projetistas. 1.Desenvolvedor (Analistas.Gerente de Qualidade. referentes às grandes organizações. Denomina-se equipe o conjunto de pessoas que trabalham num projeto em diferentes tarefas. Destes. . mas a toda atividade. 53% dos que foram concluídos excederam mais de 50% em sua estimativa de custo. Isso não se aplica somente aos projetos de software. . Somente 9%. o números melhoraram em 28% e 16% respectivamente. Programadores e Engenheiros de Testes). .1. foram entregues no tempo e orçamentos previstos. Esse relatório assinala o gerenciamento como principal responsável pelo sucesso ou falha de um projeto de software. 31% foram cancelados antes da sua conclusão.1 Partes envolvidas no Projeto de Software No projeto de Software há o envolvimento de várias pessoas que exercem diversos papéis.

no tocante à estrutura das equipes. 2005).elementos como relacionamento interpessoal. ainda que a comunicação seja horizontal. no início do projeto. entre outros. tipo de projeto. criatividade. não há um líder permanente. da realização de estimativas. Ele tem como função abordar as definições do escopo do software.Controlada Descentralizada: aqui há um líder. podemos classificá-las em vários tipos: . mas o consenso do grupo é quem determina a tomada de decisões. como esse será elaborado. o . .Controlada Centralizada: há um líder e a comunicação entre ele e a equipe é vertical. Pela própria natureza dos projetos.2 O Processo do Gerenciamento do Projeto de Software A composição do processo de gerenciamento de software envolve três etapas principais: .1.Acompanhamento: No início do projeto existe pouca informação que possibilite evitar o comprometimento da precisão do escopo. 1. do processo de software do projeto. . da identificação e solução para os riscos agregados ao projeto. . das estimativas feitas e do cronograma desenvolvido. Segundo Pressman (PRESSMAN.Democrática Descentralizada: nesta.Planejamento: é um plano bem organizado que define. da elaboração de cronograma.

. existem nove áreas de conhecimento em gerenciamento de projetos. . de riscos e de aquisições. das comunicações. Aqui podemos fazer comparações entre o estimado e o realizado. do escopo. podemos ajustar e fazer um refinamento dos elementos supracitados. da qualidade.conhecimento aumenta na medida em que estes avançam e.Encerramento: Após o término do projeto.3 Áreas de Conhecimento em Gerenciamento de Projetos Conforme cita o PMBOK (2004). torna-se fundamental acompanhar o seu progresso. dessa forma. de forma a se tornar um aprendizado para futuros projetos. por fim. passa-se para a análise do que deu certo e o que não funcionou conforme as especificações do projeto. de tempo. fazer refinamento no escopo e. identificar os problemas e suas causas. de custos. monitorar riscos e tomar ações corretivas. fazer alterações no processo do projeto e no cronograma. 1. a saber: gerenciamento de integração. Tudo isso deve ser feito com o envolvimento de toda a equipe.1. dos recursos humanos. Abaixo faremos uma breve descrição de cada uma das referidas áreas. assim sendo. Como os projetos são dinâmicos e. estão sempre sujeitos à modificações.

2003).4 Gerenciamento de Tempo Envolve o controle das atividades para o cumprimento do cronograma e a confirmação dos marcos do projeto dentro das estimativas de prazo (VIEIRA. segundo SAYÃO E BREITMAN (2005) é: “uma capacidade de software que deve ser disponibilizada por um sistema ou componente de um sistema de modo a satisfazer um contrato. o trabalho necessário para que seja concluído com sucesso. 1.1. É a área que descreve os processos relacionados ao término do projeto dentro do prazo estimado. o Gerenciamento de Integração é a área responsável pela identificação e gerenciamento dos pontos de interação entre os elementos do projeto e o estabelecimento e manutenção da boa comunicação entre esses pontos.1. 1. escopo é todo trabalho envolvido na criação dos resultados do projeto (VIEIRA.3. tão e somente. padrão.3.3 Gerenciamento de Escopo De acordo com Vieira.1. . especificação ou outra formalidade imposta”.1.2 Gerenciamento de Requisitos A definição para requisitos.3. O Gerenciamento de Escopo faz a descrição dos processos envolvidos na verificação de que o projeto inclui.3.1 Gerenciamento de Integração Segundo Vieira. 2003). 1.1.

3. 1. o importante é não determinar custos antes da definição do requisito e do escopo.3.6 Gerenciamento de Qualidade Este tem por base a descrição dos processos envolvidos na garantia de que o projeto irá satisfazer as metas definidas a serem alcançadas por ele. . no que está implícita a satisfação dos clientes e usuários finais.1.1. no orçamento e controle de custos.3.7 Gerenciamento de Recursos Humanos Como é uma das principais fontes da produtividade no desenvolvimento de sistemas. na estimativa. visando o término do projeto dentro do orçamento aprovado. De acordo com VIEIRA (2003).1. Vieira (2003) diz que a qualidade está ligada ao atendimento das necessidades do usuário final e.1. 1. além de estuda bem a tecnologia a ser utilizada. o gerenciamento e o planejamento das pessoas envolvidas no projeto são de fundamental importância. em alguns casos. especialmente para que os prazos sejam cumpridos.5 Gerenciamento de Custos Descreve os processos envolvidos no planejamento. ao desempenho do sistema.

lidando com os métodos ágeis. cuja temática envolve gerenciamento de projetos de software. 1. Descrevendo de maneira sucinta suas vantagens e desvantagens e quando é mais viável utilizá-los.1. armazenamento e destinação final das informações do projeto. 2003). ao de software. Depois de darmos algumas definições relacionadas ao Gerenciamento de Projetos e. serviços ou resultados.3. 2003). O Capítulo 4 será destinado a uma pequena comparação entre os dois métodos. em especial. coleta. de forma oportuna e adequada (VIEIRA. .8 Gerenciamento de Comunicações O gerenciamento de comunicações descreve os processos relacionados à geração.3.9 Gerenciamento de Aquisições Aqui são descritos os processos de compra ou aquisição de produtos. avançamos neste trabalho. além dos processos de gerenciamento de contratos (VIEIRA.1.1. No Capítulo 3 faremos uma abordagem sobre os métodos tradicionais e ágeis. mas sem deixar de falar sobre os métodos tradicionais.

O desenvolvimento de software requer muita habilidade. Melhoria essa. assim como para a redução de riscos. uma atividade normalmente muito confusa. Segundo FOWLER (2000). as indefinições do plano inicial do projeto. como característica. Entretanto. que têm sua fundamental atenção voltada para a qualidade dos processos e da produtividade. visto que na prática é. uma longa fase de testes que confronta diretamente com o cronograma estabelecido. não interferem. com as múltiplas decisões a serem tomadas em curto prazo. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase em planejamento e inspiradas em outras disciplinas de engenharia. torna-se mais difícil implantar-lhe novos recursos e os defeitos que se subseguem.1. motivo pelo qual Fowler se refere a elas como “Metodologias de Engenharia”. sobremaneira. Quando o sistema é pequeno.2. . se o projeto é de maior vulto. em grande parte. no andamento do sistema. metodologias impõem um processo disciplinado no desenvolvimento de software com a finalidade de torná-lo mais eficiente e previsível. difíceis de serem suprimidos. JUSTIFICATIVA A acirrada competição no mercado de software tem como exigência principal a melhoria nos processos de desenvolvimento. O sistema acima citado carrega consigo. consequentemente. tornam-se cada vez mais arraigados e. comumente marcada pelos verbos: codificar e consertar. visto que as atividades de testes não deixam margem para uma previsão exata de tempo para a execução delas.

os métodos ágeis vêm se popularizando no Brasil nos últimos anos. de forma a prover o suficiente deles. para ter uma resposta plausível. surge um novo grupo que reage a elas. ainda que acrescente que a estrutura em demasia gera a rigidez. Ainda que os métodos ágeis ainda sejam vistos com desconfiança pelo gerenciamento tradicional. a cada dia surgem novos adeptos daqueles. Essas metodologias tentam criar um meio termo entre a escassez e o excesso de processos. Não se trata aqui de colocar os métodos ágeis como a única alternativa para o desenvolvimento de software. E continua. A princípio eram chamadas de metodologias “leves”. pois existem casos em que é mais aconselhável adotar a metodologia tradicional.Sendo as metodologias supracitadas consideradas como burocráticas. dizendo que os métodos ágeis são menos centrados em documentação e de várias formas são mais voltados ao código-fonte do programa. Pela utilização de uma abordagem simplificada. Agilidade é a habilidade de balancear flexibilidade com estabilidade. Ele ainda enfatiza que a ausência de estrutura ou estabilidade pode levar ao caos. mas hoje o termo mais aplicado é metodologia ágil. o resultado disso é que os métodos ágeis têm algumas mudanças de ênfase significativas em relação aos métodos burocráticos ou tradicionais. Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. Conforme FOWLER (2000). De acordo com HIGHSMITH (2004). .

1.Nossa proposta é analisar os métodos ágeis na sua função de alcançar a melhoria no desenvolvimento de software. .2 Objetivos Específicos Os objetivos específicos. atingindo.1 Objetivo Geral O Objetivo principal deste trabalho é fazer uma análise das metodologias ágeis no gerenciamento de projetos de software em contraste com as metodologias tradicionais.3. que aqui serão tratados. o objetivo de atender os requisitos propostos e a qualidade esperada pelos envolvidos no projeto. através de pesquisas. 1. • Fazer uma breve comparação entre os métodos ágeis e os tradicionais.3. são baseados nos seguintes itens: • • Citar as metodologias ágeis mais relevantes no mercado. Demonstrar. OBJETIVOS A seguir. apresentaremos o objetivo geral e os específicos que serão desenvolvidos no decorrer deste trabalho.3. 1. assim. levantando seus pontos comuns e divergentes. a aceitação da metodologia ágil no mercado.

Essas duas modalidades de pesquisa foram a base dos estudos necessários para que fosse possível adquirir conhecimentos que levasse a concretização do referido trabalho. Também foram coletadas informações com professores do IFF – Campos dos Goytacazes. em sua grande parte. Buscou-se também subsídios nos relatórios do Ministério da Ciência e Tecnologia.1. bem como a utilização de aulas da disciplina de Gerenciamento de Projetos do curso de Análise e Desenvolvimento de sistemas da referida Instituição. METODOLOGIA DE PESQUISA A metodologia de pesquisa utilizada neste trabalho foi. .4. marcada pela pesquisa bibliográfica e também a eletrônica. sobre desenvolvimento de software.

mudanças são bem-vindas. Métodos ágeis afirmam que nenhum processo jamais será equivalente à habilidade da equipe de desenvolvimento. entretanto.5. o qual prega que a “prioridade é satisfazer o cliente através de entregas antecipadas e contínuas de software de valor”. Então a natureza de tais métodos é a de resistir à mudança. até mesmo ao ponto de se auto-modificarem. Ele acrescenta que a maior diferença mais clara entre essa modalidade e a tradicional é que as metodologias ágeis são menos centradas em documentação. a partir de um enfoque do Manifesto Ágil. O objetivo dos métodos de engenharia é de definir um processo que irá funcionar bem.1. INTRODUÇÃO Neste capítulo abordaremos a metodologia ágil nos seus diversos aspectos. Isso funciona bem até as coisas mudarem. CAPÍTULO I 1. • Métodos ágeis são orientados a pessoas ao invés de serem orientados a processos. independentemente de quem os estiverem utilizando. ainda que menos documentação seja apenas um sintoma de duas diferenças mais profundas: • Metodologias ágeis uma são adaptativas parte do ao invés de de predeterminantes. Metodologias de engenharia tendem a tentar planejar grande processo desenvolvimento detalhadamente por um longo período de tempo. fornecendo o suficiente de processo para a obtenção de um retorno aceitável. metodologias ágeis buscam criar um equilíbrio entre nenhum processo e muito processo. . De acordo com FOWLER (2000). Para os métodos ágeis. Eles tentam ser processos que se adaptam e se fortalecem com as mudanças.

Software em funcionamento mais que documentação abrangente. Colaboração com o cliente mais que negociação de contratos. para discutir que práticas poderiam ser usadas para melhorar o desempenho de seus projetos. um grupo de dezessete especialistas (gestores e desenvolvedores) em desenvolvimento de software se reuniu em Utah. Nesse encontro foi assinado um documento chamado de “Manifesto para desenvolvimento ágil de software”. Para SOMMERVILLE (2003). Nele são valorizados: • • • • Indivíduos e interações mais que processos e ferramentas. Responder a mudanças mais que seguir um plano. cujo intuito era determinar qual a visão de uma equipe de desenvolvimento de software. desenvolvimento e entrega de software. 1. mas somente expor. O Manifesto Ágil e formado por princípios e valores que devem servir de base para as equipes. . as metodologias ágeis dispõem de uma abordagem iterativa para especificação. em geral. nos Estados Unidos da América. Nossa abordagem não fará menção às controvérsias em torno do assunto. o papel do processo é dar suporte à equipe de desenvolvimento e seu trabalho.Portanto.6. HISTÓRICO Entre os dias 13 e 13 de fevereiro 2001. de maneira sucinta e clara. a metodologia ágil com suas características de usabilidade das principais metodologias utilizadas.

Os patrocinadores.a arte de maximizar a quantidade de trabalho não realizado-é essencial. Os processos ágeis promovem desenvolvimento sustentável.Não são descartados os valores à direita. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. e então. requisitos e designs emergem de equipes auto-organizáveis. Em intervalos regulares. Software funcionando é a medida primária de progresso. Os princípios que norteiam o Manifesto são 12. a equipe deve refletir sobre como tornar-se mais efetiva. 11. Contínua atenção a excelência técnica e bom design aumenta a agilidade. 9. 3. a saber: 1. 2. As melhores arquiteturas. de poucas semanas a poucos meses. 7. que ser ágil é radicalizar ou defender que exista apenas uma solução para os projetos de desenvolvimento de software. mas antes. mas se dá preferência àqueles que estão colocados à esquerda. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. . Simplicidade . 12. 10. contudo. 8. 5. Entregar frequentemente software funcionando. com preferência à menor escala de tempo. Mudanças nos requisitos são bem-vindas. 6. Não significa. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. ajustar-se de acordo com seu comportamento. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 4. Construa projetos em torno de indivíduos motivados. mesmo tardiamente no desenvolvimento.

7. enquanto o projeto orientado a objetos é um método orientado para se executar a fase do projeto (YOURDON. Método: abordagem técnica passo a passo para se realizar uma ou mais das principais tarefas indicadas numa metodologia global. Dessa forma.que ser Ágil é identificar e focar em objetivos bem definidos. gerentes. 1. a análise estruturada é um método para se realizar a fase de análise de um projeto. No entendimento de YOURDON (1995). testes) a serem executadas e indica quais pessoas (usuários. assim como a sua união. os critérios de saída e os pontos de conferência para decisões de prosseguir/não prosseguir (os usuários devem decidir ao final da análise se desejam continuar a financiar o projeto) (YOURDON. Yourdon dá a seguinte definição para metodologia e método: “Plano de batalha” ou livro de receitas passo a passo para se chegar a um resultado desejado. procurar para que haja conscientização da equipe. . projeto. técnicos) devem estar envolvidas em cada atividade e que papéis deverão desempenhar. metodologia incorpora todo o processo de desenvolvimento de software e método é aplicado em uma ou mais fases desse desenvolvimento. As metodologias frequentemente descrevem os critérios de entrada (essas condições devem ser satisfeitas antes de iniciar a fase de projeto). CONSIDERAÇÕES SOBRE METODOLOGIA E MÉTODO Existem diversas definições ou interpretações para metodologia e método. 1995). codificação. 1995). Uma metodologia de software comumente identifica as principais atividades (análise.

. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada à linguagem especial e introduzem um conjunto de critérios para a qualidade do software (PRESSMAN.Engenharia concorrente. É uma mistura de processos que nos dizem “o que deve ser feito”. codificação. arquitetura de programa e algoritmo de processamento. 1995). . análise de requisitos de software e de sistemas. projeto da estrutura de dados. . Ele acrescenta que boas metodologias integram outros processos na gerência de projetos e. KERNER (2001) diz que não é possível atingir a maturidade da gerência de projetos sem um processo repetitivo que possa ser usado em todos os projetos. teste e manutenção. definindo-o assim: Os métodos de engenharia de software proporcionam os detalhes de “como fazer” para construir o software. os seguintes processos: . em nível estratégico.Gerência da Qualidade total. uma metodologia fornece um plano. várias organizações dos mais diversos ramos de atuação.controle de Mudança de Escopo. o qual se refere como metodologia do gerenciamento de projetos.Já PRESSMAN entende que método incorpora todo o processo de desenvolvimento de software. integraram numa única metodologia de gerência de projetos. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto. . durante a década de 90. 1. para planejar e controlar os processos de software.Gerência de Projetos. METODOLOGIAS DE GERENCIAMENTO DE PROJETOS De acordo com REHMAN (2007).8. mas não “como deve ser feito”.

baseada processos integrados. • Formato de relatórios padronizado. conforme necessário. • Utilização de modelos. • Uso de fases do ciclo de vida padronizado. • Baseado em orientações e não em políticas e procedimentos. • Prontamente aceito e utilizado em toda organização. programação e controle dos custos padronizado. KERNER (2001) também enumera as características de uma boa metodologia. tanto os internos quanto para os clientes. • Flexibilidade para uma rápida introdução de melhorias.. a saber: • Um recomendado nível de detalhe. • Fácil para que o cliente possa entender e seguir. . • Com base em um bom trabalho ético. • Técnicas de planejamento.Gerência de Risco. • Flexibilidade para a aplicação em todos os projetos.

METODOLOGIAS ÁGEIS De acordo com FOWLER (2003). assim como outras metodologias de desenvolvimento. no artigo “The New Project Development Game”.1 SCRUM O SCRUM foi concebido por Takeuchi e Nonaka. Ele aumenta significativamente a produtividade e reduz o tempo e reduz o tempo para obter . existem algumas diferenças significativas entre elas. A função primária do SCRUM é ser usado para o gerenciamento de projetos de desenvolvimento de software. como um estilo em gerenciamento de projetos em indústrias de automóvel e materiais de consumo. ainda que também possa ser utilizado em qualquer contexto. 1.1. Ele tem sido usado com êxito para esse fim. onde um grupo de pessoas precise trabalhar junto para alcançar um objetivo comum. Ainda que todas compartilhem algumas características.9. Takeuchi e Nonaka perceberam que projetos que se utilizavam de equipes pequenas e multidisciplinares produziam os melhores resultados.9. SCRUM é um processo ágil e leve que utiliza práticas iterativas e incrementais para gerenciar e controlar o desenvolvimento de software. Abaixo faremos a descrição de algumas dessas metodologias para um maior entendimento de seus processos. várias são as metodologias que estão dentro da categoria de ágeis.

além de atender aos padrões CMMI e PMBOK. tendo em vista que facilita a adaptação a processos empíricos de desenvolvimento de sistemas. Aceitar ou rejeitar os resultados do trabalho.1 Papéis do SCRUM Como qualquer metodologia. de forma que se obtenha uma visão única dos requisitos do sistema. O SCRUM foi adotado como ferramenta padrão de gerenciamento de projetos nas metodologias MSF for Agile e Open Up.9. como indicado abaixo: . Suas responsabilidades são: • • Definir as funcionalidades do produto. que garantirá que o projeto seja entregue com todas as funcionalidades necessárias. stakeholders ou do mercado.1. antes que um papel. 1. Poder alterar as prioridades fora do Sprint.resultados.Team Members: pode ser considerado como um grupo de pessoas.Product Owner: Pode se tratar do financiador ou de alguém importante. • • • Priorizar o Product Backlog. Concentrar as informações vindas dos usuários. o SCRUM é baseado em papéis e responsabilidades. interessado no projeto. . As características do Team são: . O Team Members é o grupo de pessoas ligadas diretamente ao trabalho a ser feito.

Formado por até 7 pessoas. o SCRUM Master deve atender os seguintes requisitos: • Melhorar a vida e a produtividade do time de desenvolvimento promovendo o conhecimento e a criatividade. • • Garantir que o processo está sendo respeitado. • • Remover impedimentos. a fim de garantir que o cliente é quem realmente está direcionando as funcionalidades desenvolvidas. Gerencia os interesses do Product Owner através do Time. Define o objetivo do Sprint e especifica o resultado do trabalho. Promover práticas de engenharia para que cada parte de funcionalidade seja potencialmente implantável.SCRUM Master: Sua função está relacionada ao papel de líder. . Demonstra o resultado do Sprint para o Product Owner e outros Stakeholders. Remover barreiras entre o desenvolvimento e o cliente. para alcançar o objetivo do Sprint. . Estimular uma cooperação muito próxima entre todas as pessoas do time. • Faz o que é necessário dentro das diretrizes do projeto. • • Auto-organizável.• • • Multifuncional. Para ser eficiente. • • Proteger o time das interferências externas.

. . 2004): • • Preparação: onde é definido o business-case. Dentro de cada Sprint são realizadas algumas atividades. game concept. . um Product Increment a ser entregue ao cliente ao final do Sprint. . . uma após outra.Sprint Restrospective: tem como objetivo identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os erros encontrados. onde os membros discutem aquilo em que trabalharam. no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o o progresso do trabalho. Este encontro é uma maneira eficiente de manter os membros cientes dos objetivos e evitar que o projeto se desvie do seu objetivo. Sprints: são iterações realizadas. onde o Product Owner tem a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe. as seguintes etapas (TEAM SYSTEM.9. Product Baccklog inicial e outras premissas ligadas ao projeto.SCRUM Planning Meeting: é o início de um Sprint. tais como: . para entregar gradativamente as estórias que compõem o jogo.Criação do Product Increment: A finalização das estórias definidas para um determinado Sprint marca a realização do Product Increment.Daily SCRUM Meeting: É um encontro diário realizado pela equipe.2 Etapas de um Projeto com SCRUM Num projeto SCRUM existem. que é responsável por validar e/ou solicitar ajustes para que o jogo se torne adequado aos anseios do cliente.1. basicamente.Sprint Review: é o momento em que a equipe exibe o Product Increment construído ao Project Owner.1.

info/wp-content/uploads/2009/10 . é a última etapa de um projeto utilizando o SCRUM. motivado pelos itens mais prioritários.. Fonte: http://mundoti. Ele ocorre.Encerramento: Como sugere o próprio nome. após a finalização de todos os Sprints e é marcada pela entrega do produto final que foi a causa da criação do projeto.Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado. . Figura 1 – Ciclo do SCRUM.

Esses valores devem ser observados para que se tenha um melhor resultado da metodologia em questão. no intuito de dar continuidade ao . . A Equipe da Extreme. que definem como será o procedimento da equipe durante o processo de desenvolvimento. mas funcional. digitar menos código. onde o cliente define o que será feito em seguida. mas antes ir de encontro à funcionalidade desejada pelo cliente. Os outros o complementam e lhe dão suporte. Existem alguns valores na Extreme Programming. esse é o primeiro e talvez o mais importante dos valores do XP. simplicidade significa que o código deve ser simples. ela é uma metodologia ágil.2 Extreme Programming (XP) De acordo com BECK (2004). São Eles: . É o Feedback que garante um sistema ágil e consistente. o idealizador da Extreme Programming.9. com a ajuda de formulários simples. onde os requisitos para o desenvolvimento de software são vagos e estão em constante mudança. Não deve ser confundido com se fazer de qualquer maneira e. para que ocorra o Feedback.Comunicação: A equipe de desenvolvimento deve. durante toda fase de desenvolvimento. se reúne diariamente com o cliente e.Simplicidade: No XP.1. trocar informações com o cliente. para pequenas e médias equipes. tampouco. é possível ajustar suas necessidades a uma situação próxima do ideal. .Feedback: segundo TELES (2004).

br/imagens/javamagazine/Figura_01CicloVidaXP. Ele foi criado em 1997 por Jeff De Lucca.3 FDD FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é um método iterativo e incremental que tem um bom funcionamento com iterações curtas de até duas semanas. Figura 2 – Ciclo de Vida do XP. . Essa comunicação poderá ser feita de várias maneiras.devmedia.9. ainda que a mais utilizada seja a escrita em forma de documentação.com.projeto. Fonte: http://www.JPG 1.

Green. dessa forma.9. deve-se primeiro escrever um pequeno pedaço de código para testar o resultado. Fazemos o Teste passar (Green). Adicionamos uma nova funcionalidade do sistema.4 TDD O Test Driven Design (TDD) é a combinação de duas técnicas de programação: Test-First Development (TFD) e Refactoring (Refatoração).4.1 Fases O FDD possui duas fases: • Concepção e Planejamento: nessa fase acontece a triagem de requisitos. Onde: • • • Escrevemos um Teste que inicialmente não passa (Red). . Refactor. 1. • Construção: Aqui temos um detalhamento por funcionalidade.Red. Antes de se escrever um código funcional. em qualquer linguagem de programação. .9.O FDD prega a visibilidade do estado do projeto e.9.3. 1. 1. é possível saber quantas funcionalidades já foram desenvolvidas e quantas ainda restam para se desenvolver.1 Ciclo de Desenvolvimento do TDD O ciclo de desenvolvimento do TDD pode ser elaborado conforme discriminado abaixo. É Especificado mais o que deve ser feito.

Escrevemos o próximo Teste.• • Refatoramos o código da nova funcionalidade (Refactoring).com/2010/11/tdd3. Figura 3 – Ciclo de Desenvolvimento do TDD.files.wordpress. Fonte: http://alexandregama.png .

2006. PMBOK . GERENCIA de PROJETOS. PMI . The New Methodology. UFES. Acesso em 10/09/2010. Acessado em 12/09/2010. FOWLER. EUA. Rio de Janeiro: Campus.pmtech. em http://www.br/~falbo/files/GerenciaProjetosSoftware. KERZNER.Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK®) Terceira edição 2004 Project Management Institute. Disponível em: <http://martinfowler. Engenharia de Software. PRESSMAN. Marconi Fábio. Disponível em http://gerpro2008. 3a. Four Campus Boulevard. PRADO. São Paulo: Makron. Engenharia de Software. Bookman. 2005. PA 19073-3299 EUA. Editora INDG-Tecs. PMTECH. Artigo publicado em julho de 2003. edição. 2005.2.com. Acesso 20/09/2010. em PMTECH. Gerenciamento de Projetos de Software.pdf>.REFERÊNCIAS BREITMAN.inf. S. Karin Koogam. 2003. São Paulo: Makron. Gerência de Requisitos.pdf. J. Projetos de Software. Maturidade em Gerenciamento de Projetos. H. Outubro. Miriam. Creating innovative products. Disponível <http://www. Martin. HIGHSMITH.br/artigos/CMM&PMBOK. Addison Wesley. Disponível acesso em 14/092010. em em VIEIRA.pmtech. Acesso em 24 de outubro de 2010.com/articles/newMethodologyOriginal.ufes. v. Gerenciamento de Projetos de Tecnologia da Informação. Mini-Cursos do 20º SBBD e 19º SBES. 1995.html>.com/files/Apostila_GERENCIA_DE_PROJETOS_DE_ SOFTWARE. Disponível <http://www. 2004. Sayão.Project Management Institute (PMI) (2004) “A Guide to the Project Management Body of Knowledge”.googlecode. S. PRESSMAN.pdf.pdf>. . Newtown Square. Darci.br/artigos/Gerenciamento_Projetos_Software. Gestão de Projetos: As Melhores Práticas. Porto Alegre. Agile Project Management. R.. 2008. R.com.

H. REHMAN. São Paulo. em YOURDON. 7ª. 6. KERZNER. 1 . Edição. Declínio e Queda dos Analistas e dos Programadores. Acesso em 10 de novembro de 2010.org/iso/ptbr/>. (2001). (2007). Engenharia de Software. ed. Disponível <http://agilemanifesto. 2003 Manifesto para Desenvolvimento Ágil de Software. Project Management. Software Project Management Methodologies/Frameworks Dynamics “A Comparative Approach”. 1995. São Paulo: Addison Wesley. In Proceedings of the IEEE International Conference on Information and Emerging Technologies (ICIET). pp. E. Ian.SOMMERVILLE.5. A. John Wiley & Sons. .

You're Reading a Free Preview

Descarregar
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->