CURSO DE PS-GRADUAO LATO SENSU EM GERENCIAMENTO DE PROJETOS

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MTODOS GEIS

CAMPOS DOS GOYTACAZES/RJ 2011

JORGE DA SILVA SANTOS

GERENCIAMENTO DE PROJETOS DE SOFTWARE E MTODOS GEIS

Monografia apresentada a FIJ Faculdades Integradas Jacarepagu, como requisito para concluso do Curso de Ps-Graduao 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 MTODOS GEIS

Monografia apresentada a FIJ Faculdades Integradas Jacarepagu, como requisito para concluso do Curso de Ps-Graduao 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 agradeo a Deus, Doutor e Mestre por essncia e excelncia. Aos parentes e amigos que estiveram sempre presentes a apoiar-me em minhas dificuldades, bem como fornecer o devido auxlio, seja ele moral ou material. Enfim, a todos que colaboraram de alguma forma para que este trabalho fosse concludo com xito.

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

RESUMO

Este trabalho destina-se a fazer uma abordagem sistemtica dos mtodos de gerenciamento de projetos, voltados especificamente para a rea de

desenvolvimento de software. Descreveremos os mtodos mais importantes e suas respectivas vantagens e desvantagens, visando atender as necessidades dos clientes.

ABSTRACT

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

LISTA DE ABREVIATURAS

LISTA DE FIGURAS

SUMRIO

1. INTRODUO

A era de Globalizao trouxe consigo mudanas que tm afetado sobremaneira os diversos processos de Gerenciamento de Projetos, dessa forma tornando o mercado mais competitivo e, com isso, criando expectativas maiores no que se refere agilidade e qualidade. Estamos diante de pessoas mais exigentes e criteriosas com relao a produtos e servios. Diante disso, forosamente, temos que nos atualizar e nos adaptar aos novos rumos prescritos pela Era Moderna. A competitividade nos mercados internacionais fator preponderante dessa nova realidade, onde aqueles que ficaram estagnados no tempo perderam seus lugares para outros que procuraram acompanhar tamanha evoluo, que em certas reas to rpida que se no estivermos atentos nos distanciaremos dela. Para que possamos atender as expectativas inseridas no contexto da demanda atual, faz-se necessrio que nos detenhamos na utilizao de recursos que nos levaro realizao efetiva daquilo para o qual fomos designados ou contratados. Assim sendo, tornamo-nos parte de um sistema onde gerenciamos ou somos gerenciados. Em toda organizao so desenvolvidos algum tipo de trabalho e esses so executados por pessoas em maior ou menor nmero, dependendo deles -, envolvendo planejamento, recursos e controle, eles so divididos em projetos e tarefas. Aquele, segundo define o PMBOK (2004), um empreendimento temporrio com o objetivo de criar um produto ou servio nico. Dessa forma, a temporalidade aqui, significa que ele depois de concludo , em sua essncia, diferente dos outros.

A alocao de recursos e o tempo de execuo de um projeto so fatores determinantes para avaliar sua complexidade e nos levar a agir para que efetivamente levemos a cabo sua concluso. Ainda no tocante definio de projeto, podemos citar, por exemplo, KERZNER (2005), que define projeto como um empreendimento com objetivos bem definidos, consumindo recursos e operando sob presses de prazo, custo e qualidade. A ABNT (NBR 10006) define que projeto um processo nico, consistindo de um grupo de atividades coordenadas e controladas com datas para incio e trmino, empreendido para alcance de um objetivo, conforme requisitos especficos, incluindo limitaes de tempo, custos e recursos. A Gerncia de Projetos definida, segundo o Project Management Body of Knowledge (PMBOK, 2004) a aplicao de conhecimentos, habilidades, ferramentas e tcnicas em atividades do projeto, com o intuito de satisfazer ou exceder as necessidades e as expectativas dos stakeholders1 Como este trabalho est voltado para a rea de software, podemos acrescentar a definio de Gerncia de Projetos dada por Pressman (1995) que diz que ela uma tarefa de vital importncia no processo de desenvolvimento de um produto, sendo definida como a primeira camada deste processo e no visto como uma etapa clssica do desenvolvimento, desde que ela acompanha todas as etapas do desenvolvimento, ou seja, da concepo obteno do produto. Pressman tambm diz que para que um projeto de software seja bem sucedido, necessrio

Stakeholders so pessoas ou organizaes que so afetadas pelo sistema e que tem influncia direta ou indireta nos requisitos do sistema [PMBOK (2004)].

que alguns parmetros sejam corretamente analisados, a saber: o escopo, os riscos envolvidos, os recursos necessrios, as tarefas a serem realizadas, os indicadores a serem acompanhados, os recursos e custos aplicados e a sistemtica que dever ser seguida.

1.1.

GERENCIAMENTO DE PROJETO DE SOFTWARE

Para que possamos nos deter com maior profundidade no tema deste trabalho, torna-se necessrio falarmos um pouco sobre o gerenciamento de projetos de software, Comearemos falando sobre pesquisas realizadas na dcada de 90, onde eram demonstradas que as principais causas do fracasso falhas na execuo e atraso na entrega de um projeto de software estariam ligadas ao desempenho do gerenciamento do projeto. No ano de 1993, o Software Engineering Institute (SEI), verificou que o problema de maior relevncia que preocupa as organizaes de software aquele relacionado com o aspecto gerencial. Darci Prado (PRADO, 2008), em seu livro intitulado Maturidade em Gerenciamento de Projetos, fala sobre o Relatrio Chaos Report (2004), ao analisar os projetos de TI que falharam, afirma que isto no aconteceu, em sua maioria, por falta de recursos ou acesso tecnologia, mas antes por falta de conhecimento em gesto de projetos e que esse no aplicado somente figura do gestor, mas tambm de todos os integrantes da equipe. O Relatrio Chaos realizado pelo Standish Group (1995) identificou que as empresas americanas gastaram $ 81 milhes em projetos de software que foram

cancelados em 1995. Destes, 31% foram cancelados antes da sua concluso; 53% dos que foram concludos excederam mais de 50% em sua estimativa de custo. Somente 9%, referentes s grandes organizaes, foram entregues no tempo e oramentos previstos. No que se refere s pequenas e mdias empresas, o nmeros melhoraram em 28% e 16% respectivamente. Esse relatrio assinala o gerenciamento como principal responsvel pelo sucesso ou falha de um projeto de software.

1.1.1 Partes envolvidas no Projeto de Software

No projeto de Software h o envolvimento de vrias pessoas que exercem diversos papis, a saber: - Gerente de Projeto; - Desenvolvedor (Analistas, Projetistas, Programadores e Engenheiros de Testes); - Gerente de Qualidade; - Clientes; - Usurios. Denomina-se equipe o conjunto de pessoas que trabalham num projeto em diferentes tarefas, mas com os mesmos objetivos. Isso no se aplica somente aos projetos de software, mas a toda atividade. Os papis de cada um devem ser bem definidos, considerando-se que a boa formao de uma equipe depende disto. Tambm deve-se levar em conta alguns

elementos como relacionamento interpessoal, criatividade, tipo de projeto, entre outros. Segundo Pressman (PRESSMAN, 2005), no tocante estrutura das equipes, podemos classific-las em vrios tipos: - Democrtica Descentralizada: nesta, no h um lder permanente, mas o consenso do grupo quem determina a tomada de decises; - Controlada Descentralizada: aqui h um lder, ainda que a comunicao seja horizontal; - Controlada Centralizada: h um lder e a comunicao entre ele e a equipe vertical.

1.1.2 O Processo do Gerenciamento do Projeto de Software

A composio do processo de gerenciamento de software envolve trs etapas principais: - Planejamento: um plano bem organizado que define, no incio do projeto, como esse ser elaborado. Ele tem como funo abordar as definies do escopo do software, do processo de software do projeto, da realizao de estimativas, da elaborao de cronograma, da identificao e soluo para os riscos agregados ao projeto; - Acompanhamento: No incio do projeto existe pouca informao que possibilite evitar o comprometimento da preciso do escopo, das estimativas feitas e do cronograma desenvolvido. Pela prpria natureza dos projetos, o

conhecimento aumenta na medida em que estes avanam e, dessa forma, podemos ajustar e fazer um refinamento dos elementos supracitados. Como os projetos so dinmicos e, assim sendo, esto sempre sujeitos modificaes, torna-se fundamental acompanhar o seu progresso, fazer alteraes no processo do projeto e no cronograma, fazer refinamento no escopo e, por fim, monitorar riscos e tomar aes corretivas; - Encerramento: Aps o trmino do projeto, passa-se para a anlise do que deu certo e o que no funcionou conforme as especificaes do projeto. Aqui podemos fazer comparaes entre o estimado e o realizado, identificar os problemas e suas causas. Tudo isso deve ser feito com o envolvimento de toda a equipe, de forma a se tornar um aprendizado para futuros projetos.

1.1.3 reas de Conhecimento em Gerenciamento de Projetos

Conforme cita o PMBOK (2004), existem nove reas de conhecimento em gerenciamento de projetos, a saber: gerenciamento de integrao, do escopo, de tempo, de custos, da qualidade, dos recursos humanos, das comunicaes, de riscos e de aquisies. Abaixo faremos uma breve descrio de cada uma das referidas reas.

1.1.3.1 Gerenciamento de Integrao

Segundo Vieira, o Gerenciamento de Integrao a rea responsvel pela identificao e gerenciamento dos pontos de interao entre os elementos do projeto e o estabelecimento e manuteno da boa comunicao entre esses pontos.

1.1.3.2 Gerenciamento de Requisitos

A definio para requisitos, segundo SAYO 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, padro, especificao ou outra formalidade imposta.

1.1.3.3 Gerenciamento de Escopo

De acordo com Vieira, escopo todo trabalho envolvido na criao dos resultados do projeto (VIEIRA, 2003). O Gerenciamento de Escopo faz a descrio dos processos envolvidos na verificao de que o projeto inclui, to e somente, o trabalho necessrio para que seja concludo com sucesso.

1.1.3.4 Gerenciamento de Tempo

Envolve o controle das atividades para o cumprimento do cronograma e a confirmao dos marcos do projeto dentro das estimativas de prazo (VIEIRA, 2003). a rea que descreve os processos relacionados ao trmino do projeto dentro do prazo estimado.

1.1.3.5 Gerenciamento de Custos

Descreve os processos envolvidos no planejamento, na estimativa, no oramento e controle de custos, visando o trmino do projeto dentro do oramento aprovado. De acordo com VIEIRA (2003), o importante no determinar custos antes da definio do requisito e do escopo, alm de estuda bem a tecnologia a ser utilizada.

1.1.3.6 Gerenciamento de Qualidade

Este tem por base a descrio dos processos envolvidos na garantia de que o projeto ir satisfazer as metas definidas a serem alcanadas por ele, no que est implcita a satisfao dos clientes e usurios finais. Vieira (2003) diz que a qualidade est ligada ao atendimento das necessidades do usurio final e, em alguns casos, ao desempenho do sistema.

1.1.3.7 Gerenciamento de Recursos Humanos

Como uma das principais fontes da produtividade no desenvolvimento de sistemas, o gerenciamento e o planejamento das pessoas envolvidas no projeto so de fundamental importncia, especialmente para que os prazos sejam cumpridos.

1.1.3.8 Gerenciamento de Comunicaes

O gerenciamento de comunicaes descreve os processos relacionados gerao, coleta, armazenamento e destinao final das informaes do projeto, de forma oportuna e adequada (VIEIRA, 2003).

1.1.3.9 Gerenciamento de Aquisies

Aqui so descritos os processos de compra ou aquisio de produtos, servios ou resultados, alm dos processos de gerenciamento de contratos (VIEIRA, 2003). Depois de darmos algumas definies relacionadas ao Gerenciamento de Projetos e, em especial, ao de software, avanamos neste trabalho, cuja temtica envolve gerenciamento de projetos de software, lidando com os mtodos geis, mas sem deixar de falar sobre os mtodos tradicionais. No Captulo 3 faremos uma abordagem sobre os mtodos tradicionais e geis. Descrevendo de maneira sucinta suas vantagens e desvantagens e quando mais vivel utiliz-los. O Captulo 4 ser destinado a uma pequena comparao entre os dois mtodos.

1.2. JUSTIFICATIVA

A acirrada competio no mercado de software tem como exigncia principal a melhoria nos processos de desenvolvimento. Melhoria essa, que tm sua fundamental ateno voltada para a qualidade dos processos e da produtividade, assim como para a reduo de riscos. O desenvolvimento de software requer muita habilidade, visto que na prtica , em grande parte, uma atividade normalmente muito confusa, comumente marcada pelos verbos: codificar e consertar. Quando o sistema pequeno, as indefinies do plano inicial do projeto, com as mltiplas decises a serem tomadas em curto prazo, no interferem, sobremaneira, no andamento do sistema. Entretanto, se o projeto de maior vulto, torna-se mais difcil implantar-lhe novos recursos e os defeitos que se subseguem, tornam-se cada vez mais arraigados e, consequentemente, difceis de serem suprimidos. O sistema acima citado carrega consigo, como caracterstica, uma longa fase de testes que confronta diretamente com o cronograma estabelecido, visto que as atividades de testes no deixam margem para uma previso exata de tempo para a execuo delas. Segundo FOWLER (2000), metodologias impem um processo disciplinado no desenvolvimento de software com a finalidade de torn-lo mais eficiente e previsvel. Elas fazem isso desenvolvendo um processo detalhado com uma forte nfase em planejamento e inspiradas em outras disciplinas de engenharia, motivo pelo qual Fowler se refere a elas como Metodologias de Engenharia.

Sendo as metodologias supracitadas consideradas como burocrticas, surge um novo grupo que reage a elas. A princpio eram chamadas de metodologias leves, mas hoje o termo mais aplicado metodologia gil. Essas metodologias tentam criar um meio termo entre a escassez e o excesso de processos, de forma a prover o suficiente deles, para ter uma resposta plausvel. Conforme FOWLER (2000), o resultado disso que os mtodos geis tm algumas mudanas de nfase significativas em relao aos mtodos burocrticos ou tradicionais. E continua, dizendo que os mtodos geis so menos centrados em documentao e de vrias formas so mais voltados ao cdigo-fonte do programa. Ainda que os mtodos geis ainda sejam vistos com desconfiana pelo gerenciamento tradicional, a cada dia surgem novos adeptos daqueles. Pela utilizao de uma abordagem simplificada, os mtodos geis vm se popularizando no Brasil nos ltimos anos. De acordo com HIGHSMITH (2004), Agilidade a habilidade de criar e responder a mudanas com respeito ao resultado financeiro do projeto em um turbulento ambiente de negcios. Agilidade a habilidade de balancear flexibilidade com estabilidade. Ele ainda enfatiza que a ausncia de estrutura ou estabilidade pode levar ao caos, ainda que acrescente que a estrutura em demasia gera a rigidez. No se trata aqui de colocar os mtodos geis como a nica alternativa para o desenvolvimento de software, pois existem casos em que mais aconselhvel adotar a metodologia tradicional.

Nossa proposta analisar os mtodos geis na sua funo de alcanar a melhoria no desenvolvimento de software, atingindo, assim, o objetivo de atender os requisitos propostos e a qualidade esperada pelos envolvidos no projeto.

1.3. OBJETIVOS
A seguir, apresentaremos o objetivo geral e os especficos que sero desenvolvidos no decorrer deste trabalho.

1.3.1 Objetivo Geral

O Objetivo principal deste trabalho fazer uma anlise das metodologias geis no gerenciamento de projetos de software em contraste com as metodologias tradicionais, levantando seus pontos comuns e divergentes.

1.3.2 Objetivos Especficos

Os objetivos especficos, que aqui sero tratados, so baseados nos seguintes itens: Citar as metodologias geis mais relevantes no mercado; Demonstrar, atravs de pesquisas, a aceitao da metodologia gil no mercado; Fazer uma breve comparao entre os mtodos geis e os tradicionais;

1.4. METODOLOGIA DE PESQUISA

A metodologia de pesquisa utilizada neste trabalho foi, em sua grande parte, marcada pela pesquisa bibliogrfica e tambm a eletrnica. Essas duas modalidades de pesquisa foram a base dos estudos necessrios para que fosse possvel adquirir conhecimentos que levasse a concretizao do referido trabalho. Tambm foram coletadas informaes com professores do IFF Campos dos Goytacazes, bem como a utilizao de aulas da disciplina de Gerenciamento de Projetos do curso de Anlise e Desenvolvimento de sistemas da referida Instituio. Buscou-se tambm subsdios nos relatrios do Ministrio da Cincia e Tecnologia, sobre desenvolvimento de software.

1. CAPTULO I
1.5. INTRODUO
Neste captulo abordaremos a metodologia gil nos seus diversos aspectos, a partir de um enfoque do Manifesto gil, o qual prega que a prioridade satisfazer o cliente atravs de entregas antecipadas e contnuas de software de valor. De acordo com FOWLER (2000), metodologias geis buscam criar um equilbrio entre nenhum processo e muito processo, fornecendo o suficiente de processo para a obteno de um retorno aceitvel. Ele acrescenta que a maior diferena mais clara entre essa modalidade e a tradicional que as metodologias geis so menos centradas em documentao, ainda que menos documentao seja apenas um sintoma de duas diferenas mais profundas:
Metodologias

geis uma

so

adaptativas parte do

ao

invs

de de

predeterminantes. Metodologias de engenharia tendem a tentar planejar grande processo desenvolvimento detalhadamente por um longo perodo de tempo. Isso funciona bem at as coisas mudarem. Ento a natureza de tais mtodos a de resistir mudana. Para os mtodos geis, entretanto, mudanas so bem-vindas. Eles tentam ser processos que se adaptam e se fortalecem com as mudanas, at mesmo ao ponto de se auto-modificarem.
Mtodos geis so orientados a pessoas ao invs de serem

orientados a processos. O objetivo dos mtodos de engenharia de definir um processo que ir funcionar bem, independentemente de quem os estiverem utilizando. Mtodos geis afirmam que nenhum processo jamais ser equivalente habilidade da equipe de desenvolvimento.

Portanto, o papel do processo dar suporte equipe de desenvolvimento e seu trabalho. Para SOMMERVILLE (2003), em geral, as metodologias geis dispem de uma abordagem iterativa para especificao, desenvolvimento e entrega de software. Nossa abordagem no far meno s controvrsias em torno do assunto, mas somente expor, de maneira sucinta e clara, a metodologia gil com suas caractersticas de usabilidade das principais metodologias utilizadas.

1.6. HISTRICO
Entre os dias 13 e 13 de fevereiro 2001, um grupo de dezessete especialistas (gestores e desenvolvedores) em desenvolvimento de software se reuniu em Utah, nos Estados Unidos da Amrica, para discutir que prticas poderiam ser usadas para melhorar o desempenho de seus projetos. Nesse encontro foi assinado um documento chamado de Manifesto para desenvolvimento gil de software, cujo intuito era determinar qual a viso de uma equipe de desenvolvimento de software. O Manifesto gil e formado por princpios e valores que devem servir de base para as equipes. Nele so valorizados: Indivduos e interaes mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano.

No so descartados os valores direita, mas se d preferncia queles que esto colocados esquerda. Os princpios que norteiam o Manifesto so 12, a saber: 1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado; 2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente; 3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo; 4. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; 5. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho; 6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face; 7. Software funcionando a medida primria de progresso; 8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente; 9. Contnua ateno a excelncia tcnica e bom design aumenta a agilidade; 10. Simplicidade - a arte de maximizar a quantidade de trabalho no realizado- essencial; 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis; 12. Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva, e ento, ajustar-se de acordo com seu comportamento; No significa, contudo, que ser gil radicalizar ou defender que exista apenas uma soluo para os projetos de desenvolvimento de software, mas antes,

que ser gil identificar e focar em objetivos bem definidos, procurar para que haja conscientizao da equipe, assim como a sua unio.

1.7. CONSIDERAES SOBRE METODOLOGIA E MTODO

Existem diversas definies ou interpretaes para metodologia e mtodo. No entendimento de YOURDON (1995), metodologia incorpora todo o processo de desenvolvimento de software e mtodo aplicado em uma ou mais fases desse desenvolvimento. Yourdon d a seguinte definio para metodologia e mtodo:

Plano de batalha ou livro de receitas passo a passo para se chegar a um resultado desejado. Uma metodologia de software comumente identifica as principais atividades (anlise, projeto, codificao, testes) a serem executadas e indica quais pessoas (usurios, gerentes, tcnicos) devem estar envolvidas em cada atividade e que papis devero desempenhar. As metodologias frequentemente descrevem os critrios de entrada (essas condies devem ser satisfeitas antes de iniciar a fase de projeto), os critrios de sada e os pontos de conferncia para decises de prosseguir/no prosseguir (os usurios devem decidir ao final da anlise se desejam continuar a financiar o projeto) (YOURDON, 1995).

Mtodo: abordagem tcnica passo a passo para se realizar uma ou mais das principais tarefas indicadas numa metodologia global. Dessa forma, a anlise estruturada um mtodo para se realizar a fase de anlise de um projeto, enquanto o projeto orientado a objetos um mtodo orientado para se executar a fase do projeto (YOURDON, 1995).

J PRESSMAN entende que mtodo incorpora todo o processo de desenvolvimento de software, definindo-o assim:
Os mtodos de engenharia de software proporcionam os detalhes de como fazer para construir o software. Os mtodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, anlise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificao, teste e manuteno. Os mtodos da engenharia de software muitas vezes introduzem uma notao grfica ou orientada linguagem especial e introduzem um conjunto de critrios para a qualidade do software (PRESSMAN, 1995).

1.8. METODOLOGIAS DE GERENCIAMENTO DE PROJETOS

De acordo com REHMAN (2007), uma metodologia fornece um plano, em nvel estratgico, para planejar e controlar os processos de software. uma mistura de processos que nos dizem o que deve ser feito, mas no como deve ser feito. KERNER (2001) diz que no possvel atingir a maturidade da gerncia de projetos sem um processo repetitivo que possa ser usado em todos os projetos, o qual se refere como metodologia do gerenciamento de projetos. Ele acrescenta que boas metodologias integram outros processos na gerncia de projetos e, durante a dcada de 90, vrias organizaes dos mais diversos ramos de atuao, integraram numa nica metodologia de gerncia de projetos, os seguintes processos: - Gerncia de Projetos; - Gerncia da Qualidade total; - Engenharia concorrente; - controle de Mudana de Escopo;

- Gerncia de Risco. KERNER (2001) tambm enumera as caractersticas de uma boa metodologia, baseada processos integrados, a saber: Um recomendado nvel de detalhe; Utilizao de modelos; Tcnicas de planejamento, programao e controle dos custos

padronizado; Formato de relatrios padronizado, tanto os internos quanto para os clientes; Flexibilidade para a aplicao em todos os projetos; Flexibilidade para uma rpida introduo de melhorias, conforme necessrio; Fcil para que o cliente possa entender e seguir; Prontamente aceito e utilizado em toda organizao; Uso de fases do ciclo de vida padronizado; Baseado em orientaes e no em polticas e procedimentos; Com base em um bom trabalho tico.

1.9. METODOLOGIAS GEIS

De acordo com FOWLER (2003), vrias so as metodologias que esto dentro da categoria de geis. Ainda que todas compartilhem algumas

caractersticas, existem algumas diferenas significativas entre elas. Abaixo faremos a descrio de algumas dessas metodologias para um maior entendimento de seus processos.

1.9.1 SCRUM

O SCRUM foi concebido por Takeuchi e Nonaka, no artigo The New Project Development Game, como um estilo em gerenciamento de projetos em indstrias de automvel e materiais de consumo. Takeuchi e Nonaka perceberam que projetos que se utilizavam de equipes pequenas e multidisciplinares produziam os melhores resultados. A funo primria do SCRUM ser usado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com xito para esse fim, assim como outras metodologias de desenvolvimento, ainda que tambm possa ser utilizado em qualquer contexto, onde um grupo de pessoas precise trabalhar junto para alcanar um objetivo comum. SCRUM um processo gil e leve que utiliza prticas iterativas e incrementais para gerenciar e controlar o desenvolvimento de software. Ele aumenta significativamente a produtividade e reduz o tempo e reduz o tempo para obter

resultados, tendo em vista que facilita a adaptao a processos empricos de desenvolvimento de sistemas. O SCRUM foi adotado como ferramenta padro de gerenciamento de projetos nas metodologias MSF for Agile e Open Up, alm de atender aos padres CMMI e PMBOK.

1.9.1.1 Papis do SCRUM

Como qualquer metodologia, o SCRUM baseado em papis e responsabilidades, como indicado abaixo: - Product Owner: Pode se tratar do financiador ou de algum importante, interessado no projeto. Suas responsabilidades so: Definir as funcionalidades do produto; Concentrar as informaes vindas dos usurios, stakeholders ou do mercado, de forma que se obtenha uma viso nica dos requisitos do sistema; Priorizar o Product Backlog; Poder alterar as prioridades fora do Sprint; Aceitar ou rejeitar os resultados do trabalho.

- Team Members: pode ser considerado como um grupo de pessoas, antes que um papel. O Team Members o grupo de pessoas ligadas diretamente ao trabalho a ser feito, que garantir que o projeto seja entregue com todas as funcionalidades necessrias. As caractersticas do Team so:

Multifuncional; Formado por at 7 pessoas; Define o objetivo do Sprint e especifica o resultado do trabalho;

Faz o que necessrio dentro das diretrizes do projeto, para alcanar o objetivo do Sprint;

Auto-organizvel; Demonstra o resultado do Sprint para o Product Owner e outros Stakeholders.

- SCRUM Master: Sua funo est relacionada ao papel de lder. Gerencia os interesses do Product Owner atravs do Time. Para ser eficiente, o SCRUM Master deve atender os seguintes requisitos: Melhorar a vida e a produtividade do time de desenvolvimento promovendo o conhecimento e a criatividade; Proteger o time das interferncias externas; Estimular uma cooperao muito prxima entre todas as pessoas do time; Remover impedimentos; Remover barreiras entre o desenvolvimento e o cliente, a fim de garantir que o cliente quem realmente est direcionando as funcionalidades desenvolvidas;

Garantir que o processo est sendo respeitado; Promover prticas de engenharia para que cada parte de funcionalidade seja potencialmente implantvel;

1.9.1.2 Etapas de um Projeto com SCRUM

Num projeto SCRUM existem, basicamente, as seguintes etapas (TEAM SYSTEM, 2004):

Preparao: onde definido o business-case, game concept, Product Baccklog inicial e outras premissas ligadas ao projeto; Sprints: so iteraes realizadas, uma aps outra, para entregar gradativamente as estrias que compem o jogo. Dentro de cada Sprint so realizadas algumas atividades, tais como: - SCRUM Planning Meeting: o incio de um Sprint, onde o Product Owner tem a oportunidade de atualizar a priorizao dos itens do Product Backlog e definir juntamente com a equipe, um Product Increment a ser entregue ao cliente ao final do Sprint. - Daily SCRUM Meeting: um encontro dirio realizado pela equipe, onde os membros discutem aquilo em que trabalharam, no que iro trabalhar e possveis 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. - Criao do Product Increment: A finalizao das estrias definidas para um determinado Sprint marca a realizao do Product Increment. - Sprint Review: o momento em que a equipe exibe o Product Increment construdo ao Project Owner, que responsvel por validar e/ou solicitar ajustes para que o jogo se torne adequado aos anseios do cliente. - 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.

- Atualizao do Product Backlog: O Product Owner responsvel por re-priorizar toda lista de itens do Product Backlog para que um prximo Sprint possa ser iniciado, motivado pelos itens mais prioritrios. - Encerramento: Como sugere o prprio nome, a ltima etapa de um projeto utilizando o SCRUM. Ele ocorre, aps a finalizao de todos os Sprints e marcada pela entrega do produto final que foi a causa da criao do projeto.

Figura 1 Ciclo do SCRUM. Fonte: http://mundoti.info/wp-content/uploads/2009/10

1.9.2 Extreme Programming (XP)

De acordo com BECK (2004), o idealizador da Extreme Programming, ela uma metodologia gil, para pequenas e mdias equipes, onde os requisitos para o desenvolvimento de software so vagos e esto em constante mudana. A Equipe da Extreme, se rene diariamente com o cliente e, com a ajuda de formulrios simples, onde o cliente define o que ser feito em seguida, possvel ajustar suas necessidades a uma situao prxima do ideal. Existem alguns valores na Extreme Programming, que definem como ser o procedimento da equipe durante o processo de desenvolvimento. Esses valores devem ser observados para que se tenha um melhor resultado da metodologia em questo. So Eles: - Feedback: segundo TELES (2004), esse o primeiro e talvez o mais importante dos valores do XP. Os outros o complementam e lhe do suporte. o Feedback que garante um sistema gil e consistente. - Simplicidade: No XP, simplicidade significa que o cdigo deve ser simples, mas funcional. No deve ser confundido com se fazer de qualquer maneira e, tampouco, digitar menos cdigo, mas antes ir de encontro funcionalidade desejada pelo cliente, para que ocorra o Feedback. - Comunicao: A equipe de desenvolvimento deve, durante toda fase de desenvolvimento, trocar informaes com o cliente, no intuito de dar continuidade ao

projeto. Essa comunicao poder ser feita de vrias maneiras, ainda que a mais utilizada seja a escrita em forma de documentao.

Figura 2 Ciclo de Vida do XP. Fonte: http://www.devmedia.com.br/imagens/javamagazine/Figura_01CicloVidaXP.JPG

1.9.3 FDD

FDD

Feature

Driven

Development

(Desenvolvimento

Guiado

por

Funcionalidades) um mtodo iterativo e incremental que tem um bom funcionamento com iteraes curtas de at duas semanas. Ele foi criado em 1997 por Jeff De Lucca.

O FDD prega a visibilidade do estado do projeto e, dessa forma, possvel saber quantas funcionalidades j foram desenvolvidas e quantas ainda restam para se desenvolver. 1.9.3.1 Fases

O FDD possui duas fases: Concepo e Planejamento: nessa fase acontece a triagem de requisitos. Construo: Aqui temos um detalhamento por funcionalidade. Especificado mais o que deve ser feito.

1.9.4 TDD
O Test Driven Design (TDD) a combinao de duas tcnicas de programao: Test-First Development (TFD) e Refactoring (Refatorao). Antes de se escrever um cdigo funcional, em qualquer linguagem de programao, deve-se primeiro escrever um pequeno pedao de cdigo para testar o resultado.

1.9.4.1 Ciclo de Desenvolvimento do TDD

O ciclo de desenvolvimento do TDD pode ser elaborado conforme discriminado abaixo; - Red, Green, Refactor. Onde:

Escrevemos um Teste que inicialmente no passa (Red); Adicionamos uma nova funcionalidade do sistema; Fazemos o Teste passar (Green);

Refatoramos o cdigo da nova funcionalidade (Refactoring); Escrevemos o prximo Teste;

Figura 3 Ciclo de Desenvolvimento do TDD. Fonte: http://alexandregama.files.wordpress.com/2010/11/tdd3.png

REFERNCIAS
BREITMAN, Karin Koogam; Sayo, Miriam. Gerncia de Requisitos. Mini-Cursos do 20 SBBD e 19 SBES. Outubro, 2005. FOWLER, Martin. The New Methodology. Artigo publicado em julho de 2003. Disponvel em: <http://martinfowler.com/articles/newMethodologyOriginal.html>. Acesso em 24 de outubro de 2010. GERENCIA de PROJETOS. Disponvel em http://gerpro2008.googlecode.com/files/Apostila_GERENCIA_DE_PROJETOS_DE_ SOFTWARE.pdf. Acesso em 10/09/2010. HIGHSMITH, J., Agile Project Management, Creating innovative products, Addison Wesley, 2004. KERZNER, H. Gesto de Projetos: As Melhores Prticas. Porto Alegre, Bookman, v.2. 2005. PMBOK - Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK) Terceira edio 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 EUA. PMI - Project Management Institute (PMI) (2004) A Guide to the Project Management Body of Knowledge, 3a. edio, EUA. PMTECH. Disponvel acesso em 14/092010. em http://www.pmtech.com.br/artigos/CMM&PMBOK.pdf. em

PMTECH. Gerenciamento de Projetos de Software. Disponvel <http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acessado em 12/09/2010.

PRADO, Darci. Maturidade em Gerenciamento de Projetos. Editora INDG-Tecs, 2008. PRESSMAN, R. S. Engenharia de Software. So Paulo: Makron, 1995. PRESSMAN, R. S. Engenharia de Software. So Paulo: Makron, 2006. UFES. Projetos de Software. Disponvel <http://www.inf.ufes.br/~falbo/files/GerenciaProjetosSoftware.pdf>. Acesso 20/09/2010. em em

VIEIRA, Marconi Fbio. Gerenciamento de Projetos de Tecnologia da Informao. Rio de Janeiro: Campus, 2003.

SOMMERVILLE, Ian. Engenharia de Software. 6. ed. So Paulo: Addison Wesley, 2003 Manifesto para Desenvolvimento gil de Software. Disponvel <http://agilemanifesto.org/iso/ptbr/>. Acesso em 10 de novembro de 2010. em

YOURDON, E. Declnio e Queda dos Analistas e dos Programadores. So Paulo. 1995. KERZNER, H. (2001). Project Management. 7. Edio. John Wiley & Sons. REHMAN, A. (2007). Software Project Management Methodologies/Frameworks Dynamics A Comparative Approach. In Proceedings of the IEEE International Conference on Information and Emerging Technologies (ICIET), pp. 1 - 5.