Você está na página 1de 71

SENAI - SERVIO NACIONAL DE APRENDIZAGEM INDUSTRIAL

JEFERSON ANDR FARIAS

GERENCIAMENTO DE PROJETOS DE SOFTWARE UM ESTUDO DE CASO

Florianpolis SC

2008

JEFERSON ANDR FARIAS

GERENCIAMENTO DE PROJETOS DE SOFTWARE UM ESTUDO DE CASO

Trabalho de Concluso de Curso de PsGraduao Lato Sensu em Gerenciamento de Projetos apresentado como requisito parcial para obteno do grau de Especialista em Gerenciamento de Projetos da Faculdade de Tecnologia SENAI Florianpolis em parceria com EUAX Gesto de Projetos.

Orientador: Prof. Antonio Joaquim da Silva

Florianpolis SC 2008

JEFERSON ANDR FARIAS

GERENCIAMENTO DE PROJETOS DE SOFTWARE UM ESTUDO DE CASO

Trabalho de Concluso de Curso apresentado Banca Examinadora do Curso de Ps Graduao Lato Sensu em Gerenciamento de Projetos da Faculdade de Tecnologia SENAI Florianpolis em cumprimento a requisito parcial para obteno do ttulo de especialista em Gerenciamento de Projetos.

APROVADO PELA BANCA EXAMINADORA EM FLORIANPOLIS, 15 DE SETEMBRO DE 2008.

____________________________________________________ Prof. Antonio Joaquim da Silva, Esp. SENAI / Florianpolis Coordenador do Curso

BANCA EXAMINADORA

__________________________________________________ Prof. Antonio Joaquim da Silva, Esp. SENAI Florianpolis Orientador

__________________________________________________ Prof. Francisca Rasche, Me. SENAI - Florianpolis Examinadora

Florianpolis SC 2008

Dedico este trabalho aos meus falecidos pais, pelo Amor que nos envolve em laos de afinidade eterna. Pelos exemplos de que a vida um processo constante de busca e

aperfeioamento, mesmo que por vezes, estejamos dispersos a este propsito.

AGRADECIMENTOS

Agradeo inicialmente a DEUS, por mais esta oportunidade, pela inspirao, pela fora sempre presente. A minha esposa, Priscila Sobierajski Barreto, pelas palavras de incentivo, pelos gestos de carinho, pela pacincia, sem esquecer claro, do AMOR que nos une. Ao meu orientador, Antonio Joaquim da Silva, pelo auxlio sempre presente, pela extrema pacincia, pelos exemplos de profissionalismo. A professora Francisca Rasche, pelo auxlio na organizao metodolgica. Ao professor Carlos Fernando Martins, pelas orientaes e pelo bom humor. Aos demais professores pelos ensinamentos. Aos meus colegas de trabalho, pelo aprendizado dirio e pela oportunidade de colocar em prtica todo o conhecimento adquirido durante o curso. Aos integrantes da turma, pessoas com quem a oportunidade de trocar experincias, ampliar contatos, aprender, e principalmente fazer grandes amizades.

RESUMO

Com os crescentes avanos tecnolgicos e econmicos, o gerenciamento de projetos tornou-se uma ferramenta poderosa para o desenvolvimento das empresas, nos seus mais diversos segmentos. Buscar uma forma organizada e padronizada de gerenciar projetos denota forma eficiente de competitividade. Com o intuito de buscar uma forma de adaptao a estes constantes avanos, este trabalho pesquisa e apresenta uma metodologia de gerenciamento de projetos para ser inserido em ambiente especfico. A metodologia aplicada neste trabalho baseou-se no levantamento bibliogrfico em livros especializados, pesquisas na Internet, trabalhos acadmicos, alm de padres criados por rgos nacionais e internacionais, propiciando embasamento mnimo necessrio sobre metodologias de gerenciamento de projetos, visando a busca de prticas a serem inseridas no ambiente de pesquisa. Objetiva-se neste trabalho uma anlise, por intermdio de um estudo de caso frente a um referencial bibliogrfico, a indicao e adaptao de prticas de gerenciamento de projetos que possam auxiliar a conduo de projetos na empresa alvo de estudo, levando-se em considerao seu momento atual e seu planejamento estratgico. Os resultados obtidos neste trabalho atingiram os objetivos propostos, uma vez que foram identificadas prticas de gerenciamento de projetos mais viveis, podendo as mesmas ser inseridas no ambiente de estudo de maneira gradativa.

Palavras chave: Gerenciamento de Projetos, Desenvolvimento de Software.

ABSTRACT

Project Management has shown to be a powerful tool helping companies on their growth when adding constant technological and economical improvements to the equation. A company who is looking for organized and standardized ways of managing a project keeps competitive efficiency on their side. Willing to adapt to these constant improvements, project management methodologies were researched and are shown here to be used in a specific environment. Specialized books, Internet, academic papers, or even more, national and international standardization organizations, were basic bibliographic sources of information about project management methodologies applied to a research environment. The target of this study is to use the bibliographic study compared to a real case scenario to analyze what project management practices can be indicated and adapted to the company who is presented on this study. Nonetheless, this analyze, has been based considering the present moment and this company strategic planning. The results of this study has matched its objective, since more interesting project management practice were identified and may be implanted on the studied company in a gradual way.

Keywords: Project Management, Software Development.

II

LISTA DE FIGURAS Figura 1 Exemplo de rguas de sucesso ................................................................................12 Figura 2 O Ciclo do Scrum ....................................................................................................21 Figura 3 Interao entre grupos de processos em um projeto................................................24 Figura 4 Viso geral das reas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos ...................................................................................26 Figura 5 Componentes do MPS.BR.......................................................................................28 Figura 6 Estrutura organizacional da empresa alvo de estudo...............................................39 Figura 7 Estrutura organizacional do setor de desenvolvimento da empresa alvo de estudo 40 Figura 8 Novo processo de desenvolvimento proposto. ........................................................52

LISTA DE TABELAS

Tabela 1 - Nveis de maturidade do MR-MPS..........................................................................31

III

LISTA DE SIGLAS

ACATE ANSI ANVISA APM BID CNPq DSDM FINEP MCT MA-MPS MN-MPS MR-MPS MPS.BR PACS PMBOK PMI RAP RC SOFTEX XP XPM

Associao Catarinense de Tecnologia American National Standarts Institute Agncia Nacional de Vigilncia Sanitria Agile Project Management Banco Interamericano de Desenvolvimento Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico Dynamic System Development Method Financiadora de Estudos e Projetos Ministrio da Cincia e Tecnologia Mtodo de Avaliao para Melhoria de Processo de Software. Modelo de Negcio para Melhoria de Processo de Software. Modelo de Referncia para Melhoria de Processo de Software. Melhoria do Processo de Software Brasileiro Picture Archiving and Communication Systems Project Management Body of Knowledge Project Management Institute Rapid Plainning Release Candidate Associao para Promoo da Excelncia do Software Brasileiro Extreme Programming Extreme Project Management

IV

SUMRIO 1. INTRODUO.................................................................................................................1 1.1. Tema da pesquisa........................................................................................................2 1.2. Questes de pesquisa ..................................................................................................2 1.3. Objetivos .....................................................................................................................3 1.3.1. Objetivo Geral...........................................................................................................3 1.3.2. Objetivos Especficos................................................................................................3 1.4. Justificativa .................................................................................................................4 1.5. Estrutura do Trabalho .................................................................................................4 2. REVISO BIBLIOGRFICA ........................................................................................6 2.1. Gerenciamento de Projetos .........................................................................................6 2.2. Gerenciamento de Projetos gil .................................................................................7 2.2.1. XPM (Extreme Project Management) ......................................................................9 2.2.1.1. Valores ............................................................................................................9 2.2.1.2. Regras ...........................................................................................................10 2.2.1.3. Tcnicas e Ferramentas.................................................................................12 2.2.2. APM (Agile Project Management) .........................................................................13 2.2.2.1. Princpios ......................................................................................................14 2.2.2.2. Prticas..........................................................................................................14 2.2.3. Scrum ......................................................................................................................17 2.2.3.1. Papis e responsabilidades............................................................................18 2.2.3.2. Fundamentos .................................................................................................19 2.2.3.3. O ciclo do Scrum ..........................................................................................20 2.3. PMBOK - Project Management Body of Knowledge ..............................................21 2.3.1. O ciclo de vida do projeto:......................................................................................22 2.3.2. Grupos de Processos ...............................................................................................22 2.3.3. reas de Conhecimento ..........................................................................................24 2.4. MPS/BR ....................................................................................................................27 2.4.1. Guias .......................................................................................................................28 2.4.2. Nveis de Maturidade..............................................................................................29 2.4.3. Processo ..................................................................................................................30 2.4.4. Capacidade de Processo..........................................................................................30 3. METODOLOGIA ...............................................................................................................32 3.1. 3.2. Classificao da Pesquisa .........................................................................................32 Procedimentos Tcnicos ...........................................................................................32

4. ESTUDO DE CASO............................................................................................................35 4.1. Apresentao da Empresa .........................................................................................35 4.2. Planejamento estratgico da empresa .......................................................................36 4.2.1. Negcio ...................................................................................................................37 4.2.2. Misso .....................................................................................................................37 4.2.3. Viso .......................................................................................................................37 4.2.4. Objetivo...................................................................................................................37 4.2.5. Iniciativas................................................................................................................38 4.3. Estrutura organizacional ...........................................................................................38 4.4. Diagnstico do ambiente interno ..............................................................................41 4.4.1. Contextualizao dos projetos da empresa .............................................................41

4.4.2. Contextualizao das estruturas da empresa e seus papis.....................................41 4.4.3. Processo de desenvolvimento de software..............................................................41 4.4.4. Levantamento de requisitos ....................................................................................42 4.4.4.1. Identificao de erros e no-conformidades .................................................42 4.4.4.2. Anlise de requisitos, erros e no-conformidades ........................................42 4.4.4.3. Definio de verses .....................................................................................43 4.4.4.4. Implementao ..............................................................................................43 4.4.4.5. Controle de Qualidade ..................................................................................44 4.4.4.6. Liberao de verses.....................................................................................44 4.4.4.7. Pesquisa e Desenvolvimento.........................................................................44 4.4.4.8. Prticas de Gerenciamento de Projetos.........................................................44 4.4.5. Dificuldades encontradas ........................................................................................45 5. PROPOSTA DE METOLOGIA ........................................................................................47 5.1. Novo processo de desenvolvimento de software ......................................................47 5.1.1. Primeira Etapa.........................................................................................................48 5.1.1.1. Iniciao de Novo Ciclo de Desenvolvimento..............................................48 5.1.1.2. Testes Finais do Ciclo de Desenvolvimento anterior ...................................50 5.1.2. Segunda Etapa.........................................................................................................50 5.1.3. Terceira Etapa .........................................................................................................51 5.2. Apresentao do novo processo de desenvolvimento...............................................52 5.3. Alinhamento de Processos ........................................................................................54 5.4. Formalizao de Processos .......................................................................................54 5.5. Prticas de Sugeridas ................................................................................................55 6. CONCLUSES ...................................................................................................................57 6.1. Sugestes para trabalhos futuros...............................................................................58 REFERNCIAS......................................................................................................................59

1.

INTRODUO comum verificarmos atualmente, empresas de desenvolvimento de software de

pequeno porte que utilizam um reduzido conjunto de padres ou boas prticas no gerenciamento de seus projetos. Segundo Castor (2007), esta pouca afinidade entre pequenas empresas e tcnicas de gerenciamento de projetos ocorre devido ao fato de pequenas empresas serem associadas uma alta dose de improvisao, enquanto que o gerenciamento de projetos exige uma elevada dose de previsibilidade e rigor. Os fatores que motivaram a concepo de projetos de desenvolvimento de software com a utilizao reduzida de padres ou boas prticas em seus gerenciamentos, geralmente vem de encontro com o histrico da empresa. Na maioria dos casos, tratam-se de pequenas empresas, criadas para suprir demandas de desenvolvimento de softwares especficos, para desenvolverem solues mais simples ou mais acessveis financeiramente em comparao a solues j existentes, tornandoas viveis a um mercado consumidor de menor poder aquisitivo. Inicialmente estas pequenas empresas possuem um nmero reduzido de recursos. No caso de recursos humanos, estes so, em alguns casos, os prprios scios da empresa. Elas tm como um de seus atributos indissociveis a concentrao em um, ou pouqussimos administradores, das decises relativas a produtos, mercados, tecnologia, finanas e administrao, onde as responsabilidades se sobrepem de maneira informal (CASTOR, 2007). Com gradativo crescimento destas empresas, surgem novas oportunidades de negcio gerando demanda de aquisio e contratao de novos recursos. Na medida em que novos recursos so adquiridos e contratados, ocorrem melhoras no processo de desenvolvimento de software, em decorrncia da soma intelectual e 1

tecnolgica das novas aquisies e contrataes. Mesmo com este fator positivo, os novos projetos oriundos das novas oportunidades de negcio ainda no possuem um padro definido de gerenciamento em suas etapas: iniciao, controle, execuo e finalizao. A no existncia de um gerenciamento especfico dos projetos de desenvolvimento de software, aliado crescimento destas empresas, gera dificuldades durante todo o ciclo destes projetos, na definio de escopo, na anlise de riscos, na manuteno de softwares e no gerenciamento dos recursos envolvidos nos projetos, gerando custos excessivos, esforos extras, alm da possibilidade de no cumprimento de prazos. Tendo como base o contexto apresentado, este trabalho visa desenvolvimento e apresentao de uma metodologia de gerenciamento de projetos de software, baseado em padres e boas prticas de gerenciamento de projetos para que possa ser incorporado gradativamente no cotidiano de projetos uma empresa com o perfil citado acima, de modo a possibilitar um controle mais efetivo sobre os mesmos, tornando-os mais produtivos e por conseqncia com melhores resultados. A empresa selecionada para a efetuao deste estudo de caso ser descrita posteriormente neste trabalho, no captulo 4.

1.1.

Tema da pesquisa Gerenciamento de Projetos de Software.

1.2.

Questes de pesquisa Quais so as prticas de gerenciamento de projetos de software que a empresa

selecionada utiliza atualmente?

Que boas prticas de gerenciamento de projetos podem ser incorporadas na empresa de forma a melhorar seu desempenho atual e auxiliar na obteno de seus resultados conforme seu planejamento estratgico?

1.3.

Objetivos Frente ao tema proposto, apresentam-se o objetivo geral e os especficos deste

trabalho.

1.3.1. Objetivo Geral Desenvolver e apresentar uma metodologia de gerenciamento de projetos de software alinhado a necessidades atuais e ao planejamento estratgico de uma pequena empresa.

1.3.2. Objetivos Especficos Os objetivos especficos deste trabalho compreendem as seguintes atividades: a) Identificar quais so as prticas de gerenciamento de projetos de software que a empresa selecionada utiliza atualmente. b) Analisar, indicar e adaptar prticas de gerenciamento de projetos que podem ser teis empresa selecionada, levando em considerao o momento atual da empresa e seu planejamento estratgico (viso). c) Criar uma metodologia de gerenciamento de projetos de software com as prticas mais viveis empresa alvo do estudo de caso, adequando-as gradativamente ao seu contexto.

1.4.

Justificativa Partindo do princpio de que existe a possibilidade do aumento da quantidade de

projetos e o reconhecimento da importncia dos mesmos para a empresa. A apresentao de uma metodologia de gerenciamento de projetos para a empresa visa auxili-la na busca de uma forma padronizada de conduzi-los e monitor-los, para com isso possibilitar a compilao de uma viso centralizada e precisa sobre o andamento e situao de cada um dos projetos da empresa. Como justificativa, convm citar um desafio ainda maior: Como inserir a forma padronizada de maneira prtica, gradativa, estando ela alinhada aos objetivos estratgicos da empresa, sem causar prejuzo ao conjunto das atividades em andamento, levando-se em considerao a situao atual da mesma e os recursos disponveis para propiciar tal mudana?

1.5.

Estrutura do Trabalho O presente trabalho est estruturado em seis captulos. No primeiro captulo, denominado Introduo so apresentados o tema e a questo

de pesquisa, o objetivo geral e os objetivos especficos, sendo finalizado com a justificativa da pesquisa. O segundo captulo, diz respeito Reviso Bibliogrfica, onde sero apresentados conceitos e definies referentes aos temas relevantes ao estudo, baseados em literaturas com respaldo cientfico. Os temas abordados sero: metodologias, guias, processos e boas prticas de gerenciamento de projetos de software, sempre levando em considerao o contexto da empresa alvo de estudo. O terceiro captulo composto pela Metodologia utilizada na pesquisa.

O quarto captulo denominado Estudo de Caso, onde ser efetuada a descrio do ambiente alvo de estudo, alm de diagnstico das prticas de gerenciamento de software hoje efetuadas no mesmo. O quinto captulo, denominado de Proposta de Metodologia, tem como base o segundo e quarto captulos, e trata-se da descrio de boas prticas de gerenciamento de projetos de software a serem propostas a empresa alvo de estudo, alm da forma com que tais prticas podem ser inseridas em seu contexto. No sexto captulo, ser apresentada a Concluso deste trabalho, alm das perspectivas de continuidade do mesmo, na forma de melhorias na metodologia proposta. Por fim, so apresentadas as referncias utilizadas na confeco deste trabalho.

2.

REVISO BIBLIOGRFICA

2.1.

Gerenciamento de Projetos Conforme o PMBOK (2004), gerenciamento de projetos trata-se da aplicao de

conhecimentos, habilidades, ferramentas e tcnicas as atividades do projeto a fim de atender aos seus requisitos. Sua realizao se d por intermdio da aplicao e integrao de processos de iniciao, planejamento, execuo, monitoramento e controle, e por fim o encerramento. A gerncia de projetos surgiu pela demanda de novos mtodos de gerenciamento, sendo consideradas trs foras bsicas que impulsionam sua aplicao que so: o crescimento exponencial do conhecimento humano, a demanda crescente por produtos e servios mais complexos e padronizados, e a evoluo da competio global pela produo de produtos e servios (ZANONI, 2001). O termo gerncia de projetos tambm utilizado para descrever uma abordagem organizacional para gerenciamento de processos operacionais contnuos. Esta abordagem, mais conhecida como gerncia por projetos, trata aspectos de servios continuados como projetos, objetivando aplicar a eles tambm os conceitos de gerncia de projetos. Gerenciar projetos, segundo o PMBOK (2004) inclui: a) Identificao de necessidades. b) Estabelecimento de objetivos claros e alcanveis. c) Balanceamento de demandas conflitantes de qualidade, escopo, tempo e custo. d) Adaptao de especificaes, dos planos e da abordagem s diferentes preocupaes e expectativas das diversas partes interessadas. O principal objetivo gerenciamento de projetos consiste na obteno de um equilbrio entre custos, prazos e qualidade, buscando atingir metas previamente estabelecidas.

2.2.

Gerenciamento de Projetos gil Em um contexto onde avanos tecnolgicos acontecem de maneira cada vez mais

rpida, importante que as empresas estejam atentas s inovaes a fim de ampliarem sua capacidade e agilidade produtiva. Este tambm um desafio para a rea de desenvolvimento de software, que constantemente visa a melhoria em seu processo produtivo. Mesmo com a constante evoluo de mtodos, tcnicas e ferramentas nesta rea, a entrega de software em prazos e custos estabelecidos nem sempre atingida. Uma das causas deste problema o excesso de formalidade nos modelos de processo propostos nos ltimos anos (FILHO, 2005). Conforme Yoshima (2007), o desenvolvimento de software uma atividade completamente diferente de tudo o que a indstria construiu desde os tempos de revoluo industrial. Cita ainda que reconhecer que o desenvolvimento de software requer prticas especiais de gerenciamento de projetos, por terem uma natureza que denomina como diferente, o primeiro passo de uma importante caminhada que ir definir o sucesso ou o fracasso de projetos de desenvolvimento de software. Uma nova abordagem para o desenvolvimento de software tem despertado grande interesse entre as organizaes de todo mundo. Trata-se de uma tendncia para o desenvolvimento gil de aplicaes, motivado pelo ritmo acelerado de mudanas na tecnologia da informao, presses por constantes inovaes, concorrncia acirrada e grande dinamismo no ambiente de negcios (PEREIRA, 2007). Com o objetivo de oferecer ao mundo uma alternativa s metodologias pesadas, que exigem um planejamento rigoroso e detalhado de todo o processo de desenvolvimento de software, tornando-o lento e burocrtico, um grupo de 17 autores e representantes das mais variadas tcnicas e metodologias geis reuniu-se para identificar boas prticas de desenvolvimento de projetos dentre as metodologias e tcnicas existentes, padronizando-a. 7

Este grupo autodenominou-se de aliana gil (agille alliance) e defende valores e prticas de mtodos geis, apresentando valores e princpios que definem critrios para o desenvolvimento gil (MLLER, 2004). O resultado deste encontro foi a criao do

Manifesto para Desenvolvimento gil de Software (Agile Manifesto, 2001), cujos valores so descritos a seguir: a) Indivduos e interaes so mais importantes que processos e ferramentas. b) Software funcionando mais importante do que documentao detalhada. c) O relacionamento com o cliente mais importante do que a negociao de contratos. d) Adaptao s mudanas mais importante do que seguir um planejamento. Compreender os valores do Agile Manifesto traz novas sugestes para a melhoria de mtodos, processos e tcnicas de desenvolvimento e gesto de projetos (PEREIRA, 2007). Conforme Mller (2004), os mtodos de desenvolvimento geis adaptam-se s diversas situaes e necessidades de software, como mudanas constantes nos requisitos, diferente dos processos tradicionais, que buscam prever todos os requisitos e necessidades do sistema. Outro valor significativo o incentivo ao trabalho em equipe, sendo constantemente reforada a idia de time, pois as pessoas so o plano principal no desenvolvimento gil, no o processo. Este fator facilita o gerenciamento do projeto, uma vez que propicia uma maior integrao e comprometimento da equipe do projeto, que consequentemente se sente mais motivada (PEREIRA, 2007). O reforo do planejamento do projeto, minimizando riscos, considerando que o planejamento mais importante do que o plano (uma vez que o mesmo no cessado at que se tenha atingido a satisfao do cliente na entrega do produto final) outra caracterstica positiva a ser destacada. Existem vrias opes para comear a praticar a agilidade em projetos de software, das quais podem ser destacadas o XP (Extreme Programming), Scrum (PEREIRA, 2007),

alm de XPM (Extreme Project Management) e APM (Agile Project Management) (MAGALHES, 2005). Uma vez que XP (Extreme Programming) tem seu enfoque voltado para prticas de desenvolvimento de software (e no gerenciamento), no sero citadas suas caractersticas no decorrer desta reviso bibliogrfica.

2.2.1. XPM (Extreme Project Management) O XPM caracteriza-se pela facilitao de mudanas no decorrer do projeto, sendo recomendado para projetos de software para os quais o tempo e o custo para tornar o produto disponvel no mercado crtico. Segundo o paradigma gil, o XPM visa a melhoria no gerenciamento de projetos, cuja abordagem de desenvolvimento baseada em XP (Extreme Programing). Sua principal caracterstica frente s abordagens tradicionais est na sua atitude em relao s mudanas, no qual os resultados direcionam o planejamento e no o contrrio. Segundo Magalhes (2005), a meta entregar o resultado desejado e no necessariamente o resultado planejado.

2.2.1.1.

Valores Segundo PONS (2004), so considerados valores do XPM:

a) Participao: O gerenciamento de projetos baseado na participao de stakeholders 1do projeto. b) Pr-Atividade: Trata-se de um processo criativo e pr-ativo de soluo de problemas. c) Transparncia: Todas as informaes do projeto so compartilhadas com stakeholders.
1

Stakeholders so as partes envolvidas no projeto, englobando clientes, a organizao executora do projeto, os membros da equipe, o gerente ou equipe de gerenciamento de projetos, os patrocinadores e os influenciadores do projeto.

d) Foco externo: O foco do Gerente de Projetos est relacionado ao foco dos stakeholders. e) Confiana: A equipe do projeto tratada como um conjunto de profissionais em que se pode confiar.

2.2.1.2.

Regras Magalhes (2005) cita 11 regras que compe o XPM, descritas a seguir:

a) A gerncia de pessoas e processos criativos demanda processos de gerenciamento criativos: No existe uma maneira especfica e certa para se gerenciar projetos na dinmica atual do mercado. Todos os envolvidos no projeto precisam de criatividade para agregar valor e qualidade ao produto final. b) Quanto menos o gerente souber sobre questes tcnicas do projeto, melhor: Faz-se necessrio distinguir informao tcnica da informao gerencial em um projeto, com o intuito de viabilizar uma maior compreenso do mesmo. Uma vez que um abrange o domnio de tecnologias, o outro abrange o controle processos e a integrao das partes envolvidas visando agregao de valor ao produto. Experincias especficas devem ser usadas em reas especficas (MAGALHES, 2005). c) O que ocorre depois do projeto mais importante do que o que ocorre durante o projeto: O acompanhamento de um projeto aps sua implantao, possibilita uma anlise de cumprimento de metas de sucesso do projeto (por parte da equipe de desenvolvimento), viabilizando a ampliao da viso do cliente do valor agregado pelo produto em seu negcio. d) Um planejamento de projeto desenvolvido sem a participao completa dos stakeholders no mais que a fantasia de um planejamento efetuado por uma s pessoa: Nesta regra destacada a importncia do envolvimento dos stakeholders durante o processo de

10

planejamento, tornando-o aberto e colaborativo, o que facilita a busca de consenso na resoluo de pontos de discrdia entre eles. e) Quanto mais tempo o gerente de projeto permanecer com os stakeholders, melhor: Sugere que o gerente de projetos deve investir uma parte considervel de seu tempo na compreenso das pessoas que fazem parte da equipe do projeto, j que a abordagem do XPM relacionada informao gerencial (diferente do XP, cuja abordagem, conforme citado anteriormente, mais voltada para o desenvolvimento de software). f) Se o sucesso de projeto no foi definido no comeo, ele possivelmente no ser alcanado no final: Sugere que os critrios que determinam o sucesso de um projeto devem ser definidos no incio do projeto e acompanhados no seu decorrer, por intermdio de rguas de sucesso, que sero descritas no decorrer deste tpico. g) A importncia da apresentao do lucro: Visa a anlise do negcio, a fim de identificar o valor agregado que o produto trar. Esta regra torna possvel ainda priorizao de funcionalidades a serem desenvolvidas de modo a maximizar benefcios. h) Os stakeholders do projeto podem ser seus melhores aliados ou seus piores inimigos: A fim de evitar a perda de recursos estratgicos, o XPM sugere a utilizao de uma ferramenta cujo objetivo manter os stakeholders informados sobre a possibilidade de utilizao de um recurso (prprio, ou de outro stakeholder). A ferramenta utilizada para este fim, tambm ser descrita no decorrer deste tpico. i) Se voc no pode prever o futuro, no planeje detalhes: Trata-se de extenso de boas prticas de desenvolvimento utilizadas em XP, onde planejamento e re-planejamento so efetuados diariamente, envolvendo toda a equipe do projeto (inclusive stakeholders). j) Se o seu projeto no mudou, fique preocupado: Trata-se de uma avaliao diria do andamento do projeto, a fim de identificar quaisquer situaes que possam prejudicar o andamento do mesmo.

11

2.2.1.3.

Tcnicas e Ferramentas So tcnicas e ferramentas do XPM:

a) RAP (Rapid Plainning) (Utilizada na regra 4): Segundo Magalhes (2005), o XPM utiliza Planejamento Rpido (RAP), para criar planos de projeto, visando assegurar a fundamentao do mesmo, com a participao intensiva dos stakeholders. Conforme Pon (2004), sem a realizao de reunies de planejamento intensivo, comum a morosidade no desenvolvimento de um plano de projeto, ao custo de o mesmo sofrer muitas revises e alteraes. O mesmo autor cita ainda, como vantagem desta tcnica que a durao do projeto diminuda, aumentando o alinhamento das expectativas de todos os envolvidos e fortalecendo a comunicao. b) Rguas de Sucesso (utilizada na regra 6): Trata-se do alinhamento de expectativas do cliente, patrocinador e outros stakeholders (PON, 2004), ou seja, a representao do grau de atendimento dos critrios de sucesso do projeto definido pelos mesmos. A figura 1 ilustra um exemplo de rguas de sucesso.

Figura 1 Exemplo de rguas de sucesso Fonte: Pon (2004) 12

c) Modelo O3 (Objective, Output, Outcome) (Utilizado na regra 7): Modelo que cria uma cadeia de valores para o projeto, permitindo vislumbrar os benefcios atrelados aos objetivos, tendo como princpio que a empresa s atingir seus resultados se houverem sucessos na produo de sadas relevantes ao projeto. d) Acordo de Qualidade (Utilizado na regra 7): Trata-se do estabelecimento de critrios e processos de qualidade do produto a partir de seus objetivos. e) Acordos de Parceria (Utilizado na regra 8): Trata-se de ferramenta que documenta servios, identifica recursos capacitados, tempo estimado e custo estimado para as necessidades de stakeholders.

2.2.2. APM (Agile Project Management) O APM um conjunto de prticas e princpios cuja finalidade guiar o gerenciamento de projetos, auxiliando as equipes de projetos a entregarem produtos ou servios de valor agregado em ambientes complexos, desafiadores e instveis (DIAS, 2006). Segundo MAGALHES (2005), O APM tem seu enfoque direcionado para habilidades de liderana, destacando a combinao de caractersticas atreladas a esta habilidade como viso de negcio, comunicao, flexibilidade, compreenso de requisitos tcnicos, juntamente com habilidade de planejamento, coordenao e execuo. No APM, o cliente quem define e prioriza as funcionalidades essenciais ao seu negcio, levando em considerao o valor agregado que estas funcionalidades traro ao mesmo. As equipes de desenvolvimento so responsveis pela criao e monitoramento do seu prprio planejamento, incluindo interaes junto com o cliente para alinhamento de expectativas. Em um cenrio como este, o gerente de projetos tem pouca necessidade de atuar de forma tradicional, passando a ser mais um facilitador e orientador. 13

Os valores e os princpios do APM descrevem a motivao de sua criao, j suas prticas descrevem como pode ser aplicado. Ambos sero apresentados a seguir. O APM considerado uma das referncias bsicas para metodologias geis. Fora concebido pelo grupo denominado aliana gil (agille alliance), descrito anteriormente, e seus valores so os mesmos descritos no manifesto gil (Agile Manifesto, 2001), ou seja: a) Indivduos e interaes so mais importantes que processos e ferramentas. b) Software funcionando mais importante do que documentao detalhada. c) O relacionamento com o cliente mais importante do que a negociao de contratos. d) Adaptao s mudanas mais importante do que seguir um planejamento.

2.2.2.1.

Princpios So considerados princpios do APM:

a) Entregar valor ao cliente. b) Gerar entregas iterativas e baseadas em funcionalidades. c) Buscar a excelncia tcnica. d) Encorajar a explorao. e) Construir times adaptativos, auto-organizados e auto-disciplinados. f) Simplificao nas atividades.

2.2.2.2.

Prticas Segundo Magalhes (2005), so prticas do APM:

a) Viso Direcionada: Trata-se do estabelecimento de uma viso direcionada para o projeto, reforando-a continuamente por meio de atitudes, influenciando assim os membros da equipe do projeto. Munido da viso do cliente no que diz respeito ao atendimento de suas 14

expectativas, o gerente de projetos deve prover uma propriedade coletiva desta viso, facilitando a obteno de senso comum sobre a mesma, por intermdio de debates. Estando a viso do projeto clara a todos os membros da equipe, fica mais fcil a equipe em manter o foco do projeto. b) Trabalho e Colaborao em Equipe: Trata-se da facilitao da colaborao ativa da equipe, estabelecendo-se condies para se manterem bons relacionamentos. Sesses de planejamento so situaes propcias para auxiliarem neste processo, Elas auxiliam no desenvolvimento de uma compreenso e respeito comum entre os desenvolvedores e o cliente. Com uma liderana adequada, na medida em que o projeto progride, sesses de planejamento podem tornar-se altamente colaborativas e criativas, resultando em melhoria do clima da equipe. Uma definio de papis na equipe, o conhecimento da caracterstica de cada indivduo (como habilidades complementares e interesses), aliadas a um relacionamento prximo, cordial e respeitoso entre todos proporcionam interaes ricas e tambm aprimoram o trabalho colaborativo. Cabe ao gerente, o monitoramento da dinmica da equipe e decidir alguma interveno (como resoluo de conflitos, caso necessrio), no esquecendo de celebrar sucessos e marcos conquistados. Valorizar a autonomia da equipe fundamental para todas as outras prticas. c) Regras Simples: Objetiva o fornecimento de suporte a equipe do projeto para um comportamento complexo, permitindo que a mesma trabalhe em uma estrutura flexvel. Estas regras devem fornecer limites claros, mas no a ponto de restringir a autonomia e criatividade da equipe. Devem ser declaradas explicitamente, compreendidas e acordadas por todos os membros da equipe logo no incio do projeto, cabendo ao gerente de projetos a avaliao, junto dos mesmos, se estas regras esto sendo seguidas, procurando ajust-las continuamente.

15

d) Informao Aberta: Objetiva o fornecimento claro e aberto informao, para que a equipe possa adaptar-se continuamente, no estando alheios a situaes que, em abordagens tradicionais somente o gerente teria conhecimento. Algumas tcnicas eficazes para serem utilizadas na disseminao de informaes: Uma proximidade do gerente de projetos com a equipe, uso de quadros, reunies dirias ou com freqncia definida (incluindo a participao de stakeholders), uso de wiki2. e) Toque leve: Trata-se da aplicao de um "controle inteligente" na equipe do projeto. Levando em considerao que na gerncia tradicional h um enfoque especfico em controle, seja de mudanas, de riscos, de pessoal, diversas metodologias, ferramentas e prticas evoluram com o intuito de administrar "um mundo fora de controle", acreditando que controle resultaria em mais ordem. Algumas delas porm, no manipulam processos cclicos com facilidade, assim como situaes variveis presente em um mundo real e incerto. O gerente de projetos que utiliza uma metodologia gil, reconhece que impossvel prever tudo antecipadamente, renunciando parte do controle, controlando somente o que for suficiente para manter a ordem. Sob o ponto de vista da gerncia tradicional, esta ordem pode parecer com desordem ou caos. Mas se o gerente estiver disposto a renunciar parte deste controle, as recompensas desta prtica englobam uma equipe dinmica e comprometida, solues inovadoras e adaptao contnua. f) Vigilncia gil: Conduzir uma equipe, levando em considerao as 5 primeiras regras descritas anteriormente requer do gerente gil uma vigilncia contnua. Isto significa confiar na equipe do projeto e no processo que elas auxiliaram a desenvolver, ser observador, avaliar continuamente a equipe e os processos, monitorar sucessos e fracassos, adaptando-se conforme a necessidade. A vigilncia gil consiste em algumas atitudes, como: encorajar o desenvolvimento colaborativo e o trabalho em equipe, percebendo

Wiki uma coleo de muitas pginas interligadas e cada uma delas pode ser visitada e editada por qualquer pessoa.

16

sinais de tenso e intervindo quando necessrio, encorajar a auto-organizao, estar atualizado frente a tecnologia, estando situado na linguagem da equipe, motivar e recompensar iniciativas, administrando expectativas, refletir sobre o que est de acordo e o que precisa de melhoria.

2.2.3. Scrum O Scrum um mtodo gil para o gerenciamento de projetos de desenvolvimento de software, cujo objetivo a maximizao da produtividade de um grupo de trabalho. Segundo Filho (2005), o Scrum foi desenvolvido para gerenciar o processo de desenvolvimento de software em ambientes em que os requisitos esto em constante mudana. A metodologia Scrum pode ser vista como um processo incremental e iterativo, mais orientado para o gerenciamento dos projetos de software (MAGALHES, 2005), mas tambm pode ser usado para projetos sem relao com software, pois seus princpios so aplicados a qualquer projeto (MLLER, 2004). A idia principal do Scrum que o desenvolvimento de software envolve muitas variveis tcnicas e de ambiente (como requisitos, recursos e tecnologia) que podem sofrer mudanas durante o processo, tornando-o complexo e imprevisvel, requerendo flexibilidade para o acompanhamento de tais mudanas. O Scrum baseado em processos empricos, ou seja, processos que no so prdefinidos, por isso menos tempo despendido tentando planejar e definir tarefas antecipadamente, bem como para ler e criar documentao. Estes processos (empricos) divergem dos processos tradicionais (definidos), como o cascata e o espiral, quanto ao tratamento da anlise e desenvolvimento (MLLER, 2004).

17

Por se tratar de um framework3, o Scrum poder ser til como guia de boas prticas para atingir objetivos (PEREIRA, 2007). Entretanto, as decises de quando e como utiliz-lo, quais tticas e estratgias seguir para obteno de maior produtividade fica a cargo de quem as estiver aplicando. Um dos aspectos positivos do Scrum a sua adaptabilidade, pois o conhecimento das suas prticas permite sua aplicao de variadas formas. A seguir sero apresentadas algumas dos conceitos e prticas do Scrum.

2.2.3.1.

Papis e responsabilidades So consideradas prticas do Srum:

a) Product Owner - Trata-se do encarregado pela definio de requisitos do produto, sendo responsvel por decidir a data de liberao da verso e o que deve conter a mesma. responsvel tambm pelo retorno financeiro (ROI) do produto. Ele quem pode mudar requisitos e prioridades de cada Sprint, alm ainda de poder aceitar ou rejeitar o resultado de cada Sprint (PEREIRA, 2007). b) Scrum Master O Scrum Master o responsvel pela garantia dos utilizao dos valores do Scrum, respeitando e fazendo respeitar as prticas e regras do mesmo. Cabe a ele o relacionamento com o cliente e com os membros da equipe, representando-os. c) Scrum Team - Trata-se da equipe que desenvolver o produto. Ela responsvel por selecionar entre os itens priorizados, os que iro ser executados durante a Sprint, tendo liberdade de realizar o que quiser dentro da Sprint para cumprir o objetivo da iterao. Cabe aos membros da equipe uma auto-organizao de forma participativa.

Framework uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido.

18

2.2.3.2.

Fundamentos So considerados fundamentos do Scrum:

a) Product Backlog - Trata-se da lista das funcionalidades que estaro contempladas na verso do software (organizadas em ordem de prioridade). nela onde sero especificados novos requisitos, tarefas e tecnologias. b) Sprint Sprint o ciclo de desenvolvimento do Scrum. No possui especificamente um perodo de tempo pr-definido, mas sugere-se que seja curto (geralmente com durao mxima de trinta dias). Durante sua execuo so realizadas tarefas e atividades para garantir a meta de entregar um software que contemple o disposto no product backlog. c) Sprint Backlog Trata-se do backlog que ser executado durante o ciclo do Sprint, ou seja, uma lista com funcionalidades, atividades e tarefas a serem executadas e desenvolvidas durante o Sprint. d) Daily Meeting Reunio realizada diariamente, com durao mxima de 15 minutos, onde a equipe discute aspectos pertinentes ao trabalho. Nesta reunio efetuada a anlise do que fora produzido desde a ltima reunio e o que se pretende fazer at a prxima. A brevidade da reunio fica cargo do Scrum Master. e) Sprint Planning Meeting Trata-se de reunio realizada antes do Sprint, onde so definidos os itens que iro compor a lista de backlog do Sprint e sua ordem de prioridade entre os itens. Por intermdio de estimativas efetuadas pela equipe de desenvolvimento, ser definida a lista de backlog do prximo Sprint. Nesta reunio os requisitos podem ser alterados, sendo que aps o incio do Sprint s os desenvolvedores podem realizar mudanas. (MLLER, 2005).

19

2.2.3.3.

O ciclo do Scrum O ciclo do Scrum, conforme ilustrado na Figura 2, inicia-se com o product

backlog, atravs de uma reunio de planejamento, onde o usurio vai definir e classificar as funcionalidades desejadas para o software por nvel de prioridade. A cada novo ciclo podero ser alterados os itens deste backlog, podendo-se inserir, mudar ou excluir requisitos antes especificados. A mudana de requisitos aceita, no prejudicando o andamento do projeto. Backlog do Sprint - Esta etapa efetuada aps a definio do backlog de produto. nela onde so definidas (a partir do backlog do produto), quais atividades sero realizadas no Sprint. Sprint - Sprint a fase de desenvolvimento do que fora definido no backlog do Sprint. Uma vez iniciada s os desenvolvedores envolvidos podero fazer mudanas nas atividades especificadas. Estas mudanas tratam-se de alteraes e expanses nas tarefas definidas no backlog de Sprint e visam a melhor adaptao ao trabalho a ser realizado. O objetivo do Sprint completar as tarefas definidas para ele e entregar uma pequena parte funcional do software, tambm conhecida como incremento. Para tanto a equipe livre para desenvolver, desde que os objetivos sejam alcanados (MLLER, 2005). Qualquer problema ou necessidade da equipe ou com um membro em particular, reporta-se ao Scrum Master, que dever orientar a equipe para evitar problemas e atingir sua meta. Diariamente, durante o Sprint, realizam-se as reunies de Scrum (os Daily Meetings), onde a equipe se rene e discute sobre o andamento do projeto. Nela, os membros da equipe falam brevemente de como vai o seu trabalho, explicitando problemas encontrados e qual ser sua prxima atividade. Por fim, efetuada uma apresentao ao cliente o produto da iterao, ou seja, o pedao executvel de software ou incremento, para ser analisado pelo usurio final (Product 20

Owner). Este incremento dever estar testado e com as funcionalidades especificadas para ele. Nesta fase tambm analisado o progresso do projeto, onde so gerados grficos de monitoramento (MLLER, 2005).

Figura 2 O Ciclo do Scrum Fonte: Magalhes (2005)

2.3.

PMBOK - Project Management Body of Knowledge O guia PMBOK (2004) uma publicao que descreve conhecimentos e prticas

para gerncia de projetos, publicado pelo PMI (Project Management Institute), sendo mundialmente aceito e reconhecido como padro neste segmento pelo ANSI (American National Standarts Institute). Nele so tratados aspectos como ciclo de vida do projeto, processos e grupos de processos de gerenciamento, sendo abordadas reas de conhecimento da gerncia de projetos e suas interaes. Conforme Magalhes (2005) o PMBOK (2004) tambm pode ser utilizado para orientar a definio de um processo padro para o gerenciamento de projetos de software. O conjunto de conhecimentos em gerenciamento de projetos descreve o conhecimento exclusivo da rea de gerenciamento de projetos e que se sobrepe s outras disciplinas de gerenciamento PMBOK (2004). Este conjunto de conhecimentos consiste na

21

definio do ciclo de vida do projeto, em cinco grupos de processos de gerenciamento de projetos e em nove reas de conhecimento, que sero apresentados a seguir.

2.3.1. O ciclo de vida do projeto: Em se tratando de gerenciamento de projetos deve haver uma distino do ciclo de vida de projeto e do ciclo de vida do gerenciamento de projeto. Com relao ao ciclo de vida de um projeto o PMBOK (2004) descreve-o como o conjunto de fases nas quais um projeto dividido, visando a determinao de seu incio e fim. So assim divididos visando facilitar sua elaborao progressiva, seu gerenciamento e seu controle. Ainda segundo o PMBOK (2004), so as caractersticas especficas de cada projeto que determinam seu ciclo de vida. Com relao ao ciclo de vida do gerenciamento do projeto, o PMBOK (2004) descreve que o gerenciamento de projetos ocorre por intermdio de processos (que um conjunto de aes que geram um resultado). Cita ainda que os processos de gerenciamento esto distribudos em 5 fases do ciclo de vida do gerenciamento do projeto: Iniciao, Planejamento, Execuo, Controle e Encerramento.

2.3.2. Grupos de Processos Conforme o guia PMBOK (2004), o gerenciamento de projetos um empreendimento integrador, e esta integrao exige que cada processo do projeto e do produto seja adequadamente associado e conectado a outros processos, visando facilitar a sua coordenao. Esta integrao ocorre por intermdio da descrio da natureza dos processos de gerenciamento de projetos, em termos da integrao entre eles, das interaes dentro deles e dos objetivos a que atendem. 22

Esses processos so agregados em cinco grupos, definidos como os grupos de processos de gerenciamento de projetos, que so: a) Grupo de processos de iniciao: Visam definio e autorizao de um projeto ou uma fase de um projeto. b) Grupo de processos de planejamento: Visa definio e o refinamento dos objetivos do projeto (escopo), sendo posteriormente planejada a ao necessria para alcanar os objetivos definidos. c) Grupo de processos de execuo: Visa mobilizao e integrao de recursos a fim de realizar o plano de gerenciamento do projeto. d) Grupo de processos de monitoramento e controle: Visam o monitoramento e medio do progresso no desenvolvimento do projeto, para que possam ser identificadas variaes em relao ao plano de gerenciamento do projeto, tornando possvel a tomada de aes corretivas e preventivas quando necessrio. e) Grupo de processos de encerramento: Visam formalizao da aceitao do produto, servio ou resultado, conduzindo o projeto a um final ordenado.

A figura 3 ilustra a interao entre os grupos de processos:

23

Figura 3 Interao entre grupos de processos em um projeto Fonte: PMBOK (2004) 2.3.3. reas de Conhecimento Com relao s reas de conhecimento, o PMBOK (2004) identifica nove reas de concentrao do conhecimento do gerenciamento de projetos, cujos objetivos so descritos a seguir: 24

a) Gerenciamento da integrao: Objetiva assegurar a coordenao dos elementos do projeto, como negociaes de conflitos visando atingir as necessidades de todas as partes interessadas no mesmo. Envolve as atividades de desenvolvimento e execuo do plano do projeto, alm do controle de mudanas. b) Gerenciamento de escopo: Objetiva a definio e controle dos trabalhos solicitados no projeto. Nele esto inseridas as atividades de iniciao, planejamento, definio, verificao e controle de mudanas do escopo. c) Gerenciamento do tempo: Objetiva a concluso do projeto no prazo previsto. Nele esto inseridos os processos de definio, ordenao, estimativa de durao das atividades, alm da elaborao e controle de cronogramas. d) Gerenciamento de custos: Objetiva a garantia da concluso da execuo do projeto dentro do oramento previsto. Fazem parte desta rea as atividades de planejamento de recursos, estimativas, oramentos e controle de custos. e) Gerenciamento da qualidade: Objetiva a certificao de que o projeto satisfar as conformidades solicitadas pelo cliente nas atividades de planejamento, garantia e controle de qualidade. f) Gerenciamento de recursos humanos: Objetiva a otimizao da utilizao de recursos humanos envolvidos no projeto. As atividades pertinentes a este gerenciamento so: o planejamento organizacional, alocao de recursos humanos e o desenvolvimento da equipe do projeto. g) Gerenciamento da comunicao: Objetiva a obteno e disseminao adequada das informaes do projeto. Ou seja, as informaes so filtradas de acordo com os papeis dos envolvidos no projeto. Consiste das atividades de planejamento da comunicao, distribuio da informao, relatrios de acompanhamento (reports) e encerramento administrativo do projeto.

25

h) Gerenciamento de riscos: Objetiva a identificao e anlise de riscos ao projeto, de modo a maximizar resultados e minimizar conseqncias. Fazem parte desta rea as atividades de identificao, quantificao, tratamento e controle de tratamento de riscos. i) Gerenciamento das aquisies: Objetiva a obteno de recursos, bens e servios externos a capacidade produtiva da equipe do projeto. Neste gerenciamento so necessrias as atividades de planejamento de aquisio, planejamento de solicitao, solicitao de propostas, seleo de fornecedores, e administrao e encerramento de contratos. A figura 4 ilustra as reas de conhecimento e os processos de gerenciamento de projetos

Figura 4 Viso geral das reas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos Fonte: PMBOK (2004) 26

2.4.

MPS/BR O MPS.BR (Softex, 2007) um programa para a Melhoria de Processo do

Software Brasileiro. Trata-se de um projeto coordenado pela SOFTEX (Associao para Promoo da Excelncia do Software Brasileiro), com apoio do MCT (Ministrio da Cincia e Tecnologia), da FINEP (Financiadora de Estudos e Projetos) e do BID (Banco Interamericano de Desenvolvimento). Este programa busca estar adequado a empresas com diferentes tamanhos e caractersticas, sendo elas pblicas ou privadas, concentrando sua ateno nas micro, pequenas e mdias empresas, estando alinhado a padres de qualidade j aceitos no contexto de projetos mundial, aproveitando toda a competncia j existente nos padres e modelos de melhoria de processo j disponveis (Softex, 2007). O MPS.BR baseado em conceitos de maturidade e capacidade de processo para a avaliao e melhoria da qualidade e produtividade de produtos de software e servios correlatos, cujo embasamento orientado por trs componentes, conforme ilustrado na figura 5: a) Modelo de Referncia (MR-MPS): O Modelo de Referncia MR-MPS contm os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o mesmo. Nele esto contidas as definies dos nveis de maturidade, processos e atributos do processo, descritos no decorrer deste tpico. Este modelo est em conformidade com os requisitos de modelos de referncia de processo da norma ISO/IEC 15504-2 (ISO/IEC 15504-2, 2003). b) Mtodo de Avaliao (MA-MPS): O mtodo de avaliao descreve o processo de avaliao, os requisitos para os avaliadores e os requisitos para atender o Modelo de Referncia (MR-MPS), em conformidade com a norma ISO/IEC 15504, sendo descrito no guia de avaliao. 27

c) Modelo de Negcio (MN-MPS): O Modelo de Negcio MN-MPS descreve regras de negcio tanto para a implementao do Modelo de Referncia (MR-MPS), seja pelas instituies que desejam implement-la, como para as instituies que almejem avali-la, como para a organizao de grupos de empresas para implementao do MR-MPS e avaliao MA-MPS para tornarem-se consultores e certificadores de aquisio e programas anuais de treinamento por meio de cursos, provas e workshops MPS.BR.

Figura 5 Componentes do MPS.BR Fonte: SOFTEX (2007)

2.4.1. Guias A descrio do MPS.BR (Softex, 2007) foi efetuada por meio de documentos em formatos de guias, descritos a seguir: a) Guia Geral: Guia que contm a descrio geral, detalhando o Modelo de Referncia (MRMPS), seus componentes e as definies necessrias para seu entendimento e aplicao. b) Guia de Aquisio: Guia que descreve um processo de aquisio de software e servios para este fim. Visa o apoio s instituies que desejam adquirir produtos de software e servios apoiando-se tambm no Modelo de referncia (MR-MPS). 28

c) Guia de Avaliao: Guia que descreve o processo e o mtodo de avaliao do Guia de Aquisio, os requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA). d) Guia de Implementao: Guia que descreve como implementar um determinado nvel do Modelo de Referncia (MR-MPS), sub-dividido em 7 partes.

2.4.2. Nveis de Maturidade Segundo a Softex(2007), os nveis de maturidade estabelecem patamares de evoluo de processos, caracterizando estgios de melhoria da implementao de processos na organizao. O nvel de maturidade em que se encontra uma organizao permite prever o seu desempenho futuro ao executar um ou mais processos. So sete os nveis de maturidade do MPS.BR: A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). O nvel G o nvel inicial, indicando que o processo mais imaturo que os demais nveis, e o nvel A indica que o processo mais maduro. Perfis de processo so atribudos a cada um dos nveis descritos. Eles indicam pontos de melhoria nos processos. O atendimento de propsitos, a obteno de resultados esperados dos processos e dos atributos de processo estabelecidos so indicadores de alcance de nveis de maturidade. Segundo Weber (2006) os sete nveis do MR-MPS possibilitam uma implementao e reconhecimento mais gradual da melhoria de processo de software, facilitando sua adequao s pequenas e mdias empresas, com visibilidade dos resultados em prazos mais curtos.

29

2.4.3. Processo Os processos no MR-MPS so descritos na forma de propsitos e resultados. Propsitos descrevem o objetivo a ser atingido durante a execuo de um processo. Resultados estabelecem os resultados a serem obtidos com a efetiva implementao do processo. Os resultados obtidos podem ser evidenciados por intermdio de um artefato produzido ou por intermdio de uma mudana significativa de estado ao ser executado o processo.

2.4.4. Capacidade de Processo Conforme Softex (2007), a capacidade do processo representada por um conjunto de atributos de processo descrito em termos de resultados esperados. Ela expressa o grau de refinamento e institucionalizao com que o processo executado. No MPS.BR, medida que a organizao evolui nos nveis de maturidade, um maior nvel de capacidade para desempenhar o processo deve ser atingido pela organizao. A capacidade do processo no MPS.BR possui nove (9) atributos de processos (AP) que so: AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2. Cada AP est detalhado em termos de resultados esperados do atributo de processo (RAP) para alcance completo do atributo de processo. A tabela 1 apresenta os nveis de maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada nvel.

30

Tabela 1 - Nveis de maturidade do MR-MPS Fonte SOFTEX(2007)

31

3.

METODOLOGIA A metodologia da pesquisa norteia o caminho a ser seguido, orienta o pesquisador

como realizar o trabalho, quais procedimentos seguir para que a pesquisa seja confivel e tenha respaldo cientfico. Para formular a metodologia utilizada nesta pesquisa, foi empregada a classificao conforme Gil (2002). Segundo o autor, toda e qualquer classificao se faz mediante algum critrio, pode-se classificar a pesquisa com base em seus objetivos gerais, e conforme os procedimentos tcnicos utilizados.

3.1.

Classificao da Pesquisa Com base nos objetivos da pesquisa, o presente estudo classificado como

exploratrio e descritivo. A pesquisa exploratria visa proporcionar maior familiaridade com o problema, tornando-o explcito. Envolve levantamento bibliogrfico, entrevistas com envolvidos em experincias prticas com o problema pesquisado, assumindo, em geral, as formas de pesquisas bibliogrficas e estudos de caso (GIL, 2002). J a pesquisa descritiva visa descrever caractersticas de determinada populao, fenmeno ou ambiente. Envolve o uso de tcnicas padronizadas de coleta de dados como questionrios e observao sistemtica, assumindo em geral a forma de levantamento (GIL, 2002).

3.2.

Procedimentos Tcnicos A classificao conforme os procedimentos tcnicos utilizados tm como objetivo

traar um modelo conceitual e operativo da pesquisa. A forma como os dados foram 32

coletados compreende os seguintes procedimentos tcnicos: pesquisa bibliogrfica, documental, levantamento e estudo de caso. Conforme Gil (2002) A pesquisa bibliogrfica desenvolvida com base em material j elaborado (...). A pesquisa bibliogrfica d sustentao terica a qualquer tipo de pesquisa. A pesquisa classificada como documental, pois fora elaborada a partir de materiais que no receberam tratamento analtico (GIL, 2002). Foram utilizados documentos internos da empresa alvo do estudo de caso, como instrues de trabalho, intranet4, informativos. Para obteno de maiores informaes referentes s prticas atuais de gerenciamento de projetos de software ser efetuado um levantamento. Levantamento um procedimento de interrogao direta de pessoas cuja atividade e comportamento deseja-se conhecer (GIL, 2002). Nesta pesquisa, o levantamento de dados foi realizado a partir da observao direta na empresa alvo de estudo, conforme ser detalhado no estudo de caso. O estudo de caso consiste em uma pesquisa profunda de uma ou poucas unidades, tem como objetivo dar um carter de profundidade e detalhamento. (VERGARA, 2004). A presente pesquisa pode ser classificada como um estudo de caso, de uma realidade especfica, pois se trata de um estudo sobre as aes de gerenciamento de projetos de software utilizadas atualmente pela empresa alvo de estudo. Portanto, com base na classificao apresentada e com o objetivo de criar uma metodologia com as prticas de gerenciamento de projetos de software mais viveis empresa alvo de estudo, foram realizadas as seguintes etapas metodolgicas:

a) Levantamento

bibliogrfico:

Levantamento

bibliogrfico

baseado

em

livros

especializados, pesquisas na Internet, artigos de revistas especializadas, trabalhos


Uma Intranet uma plataforma de rede independente, conectando os membros de uma organizao, utilizando protocolos padres de internet.
4

33

acadmicos, apresentando metodologias, modelos de maturidade, guias, processos e boas prticas de gerenciamento de projetos de software. O foco deste tpico a apresentao de conceitos bsicos, para propiciar embasamento mnimo necessrio para a criao de uma metodologia, viabilizando o entendimento de onde e como a metodologia proposta poder ser inserida. b) Levantamento do atual contexto de gerenciamento de projetos de software: Para viabilizar a criao de uma metodologia de gerenciamento de projetos de software, faz-se necessria a contextualizao das atuais prticas adotadas pela empresa alvo de estudo, para que sirva como base na elaborao da nova metodologia. Esse levantamento foi realizado por meio da observao direta, bem como a pesquisa documental. c) Proposta de metodologia: A partir do conhecimento prvio sustentado pelo levantamento bibliogrfico e pelo levantamento do contexto atual, ser elaborada e apresentada uma metodologia de gerenciamento de projetos de software para a empresa alvo de estudo de forma descritiva, com definies acerca do que a metodologia prope.

34

4.

ESTUDO DE CASO Neste captulo ser realizada a apresentao da empresa estudada, sendo

apresentado seu nicho de mercado e as solues que oferece ao mesmo, seguido da contextualizao de dados de crescimento. Em seguida, sero citadas informaes de sua estrutura organizacional e seu planejamento estratgico, com o intuito de prover uma maior viso de sua estrutura. Por fim, sero apresentados o diagnstico do ambiente interno, ou seja, os processos de trabalho (com foco no desenvolvimento de software), as prticas de gerenciamento de projetos utilizadas, alm dos problemas que a empresa enfrentada atualmente na concepo de seus projetos. As informaes obtidas neste estudo de caso, serviro como base para a criao de uma metodologia mais adequada para a empresa alvo de estudo, que apresentada no captulo 5.

4.1.

Apresentao da Empresa A empresa alvo de estudo fui fundada em maio de 2002, em Florianpolis (SC) e

especializada em desenvolvimento e comrcio de sistemas para o setor de radiologia e de diagnstico por imagem. Especializada em solues PACS (Picture Archiving and Communication Systems), um avanado conjunto de softwares que permitem realizar captura, armazenamento, impresso, distribuio, visualizao e manipulao de exames de diagnstico por imagem, fornecendo solues personalizadas e adaptadas ao mercado nacional, com investimentos viveis e adequados realidade do sistema de sade brasileiro.

35

Seus produtos destinam-se a mdicos radiologistas, clnicas especializadas de diagnstico por imagem e hospitais, sejam eles pblicos ou privados. Suas solues esto presentes em vinte e oito bases espalhados por dez estados Brasileiros. Com relao a seu crescimento, comparando o exerccio do ano de 2006 para 2007, a empresa triplicou seu faturamento (de R$ 593.000,00 para R$ 1.600.000,00) Maia (2007). Neste exerccio, o nmero de hospitais e clnicas especializadas aumentou de 15 para 27, e para suprir esta nova demanda, o nmero de funcionrios passou de 17 para 23. Atualmente a empresa alvo de estudo tem como meta aumentar seu faturamento para R$ 2.500.000,00, consta atualmente com 35 clientes um quadro de 33 funcionrios. Conforme citado anteriormente, seu negcio est voltado ao fornecimento de um conjunto de softwares para a manipulao de imagens mdicas, que por conseqncia gera servios (de vendas, implantao, treinamento e suporte), indicando que sua receita esta diretamente ligada venda dos softwares produzidos e os servios que gera, denotando a importncia do gerenciamento de projetos de software para a empresa.

4.2.

Planejamento estratgico da empresa O planejamento estratgico trata-se de um plano onde formalizado o caminho

que a empresa optou com o objetivo de torn-la competitiva, garantindo sua continuidade. Neste plano, esto definidas atividades e competncias relacionadas entre si visando entrega de valor de maneira diferenciada aos interessados. O planejamento estratgico da empresa alvo de estudo, ser descrito a seguir:

36

4.2.1. Negcio A empresa especializada no desenvolvimento de solues voltadas para a gesto de imagens mdicas em hospitais e clnicas de imagem. O produto desenvolvido o sistema de PACS (Picture Archiving and Communication Systems), um avanado conjunto de softwares que permitem realizar aquisio, armazenamento, distribuio, visualizao e manipulao de exames de diagnstico por imagem.

4.2.2. Misso A misso da empresa o desenvolvimento de tecnologia e a prestao de servios para clnicas e hospitais da rea de diagnstico por imagens mdicas na Amrica do Sul, visando otimizar os recursos dos clientes por meio de uma soluo integrada de software, tendo como benefcio social a melhoria do atendimento a comunidade.

4.2.3. Viso Tornar-se referncia na rea de desenvolvimento de softwares para diagnstico por imagem nos pases em desenvolvimento.

4.2.4. Objetivo O objetivo principal da empresa o desenvolvimento de tecnologias inovadoras e diferenciadas, com alto valor agregado e facilidade de uso, a fim de disponibilizar solues capazes de garantir maior agilidade no fluxo de trabalho dos mdicos e maior preciso diagnstica.

37

4.2.5. Iniciativas A empresa est em fase de registro e certificao de marcas e produtos na ANVISA (Agncia Nacional de vigilncia Sanitria), rgo que rege o setor brasileiro de sade. Com o intuito de aumentar diretrizes e reconhecimento da qualidade dos seus produtos e processos, ela est em busca da constante melhoria de seus processos produtivos (alm da busca por certificaes), baseando-se em padres e boas prticas recomendadas pelo PMBOK, MPS.BR (Melhoria do Processo do Software Brasileiro) e Agille Aliance.

4.3.

Estrutura organizacional Encontram-se na literatura trs denominaes bsicas para os tipos de estruturas

organizacionais: Funcional, Matricial e Projetizada. Segundo Vargas (2003) estruturas funcionais so caracterizadas pela utilizao de uma mesma linha de controle para operaes regulares e projetos. O mesmo autor cita ainda que neste tipo de estrutura os projetos tem importncia reduzida frente as atividades consideradas na organizao. Conforme Valeriano (2001), estruturas projetizadas so caracterizadas por formar equipes temporrias de trabalho chefiadas por um Gerente de Projetos, exclusivamente dedicadas execuo de um projeto. Vargas (2003) cita que em organizaes estruturadas desta forma os gerentes tm autonomia total assumindo tambm o controle funcional dos envolvidos. A estrutura matricial, segundo Valeriano (2001) caracterizada pela combinao de benefcios das estruturas funcional e projetizada. O mesmo autor cita ainda que nesta estrutura existe a sobreposio de uma estrutura de projetos uma estrutura funcional.

38

Vargas (2003) subdivide as organizaes matriciais em fracas, equilibradas ou moderadas e fortes. Em uma organizao matricial fraca, cita que existe a alocao de recursos para conduo de projetos com pouco reconhecimento de autoridade formal sobre as atividades e os recursos, destacando que nestas organizaes a importncia dada aos projetos ainda limitada. Em estruturas organizacionais consideradas moderadas, h uma dedicao integral do Gerente de Projetos aos projetos, possuindo ainda uma autonomia comparvel a de um gerente funcional. Em estruturas matriciais consideradas fortes, a autonomia do Gerente de Projetos maior que a de gerentes funcionais, pois os projetos tendem a ser estratgicos para a empresa. A figura 6 ilustra o organograma da empresa alvo de estudo. Nela pode-se constatar a ligao direta das diferentes reas da empresa com a diretoria, onde a descentralizao de autoridade est dividida entre Gerncias, Coordenadorias e Lideranas de equipe, no existindo a figura do Gerente de Projetos.

Figura 6 Estrutura organizacional da empresa alvo de estudo 39

Com exceo do setor de desenvolvimento de software, os demais setores da empresa so considerados como funcionais, uma vez que so agrupadas na mesma unidade e realizam atividades dentro de uma mesma rea tcnica. O desenvolvimento caracterizado por uma estrutura por projetos, como ilustra a figura 7, onde os recursos esto agrupados de acordo com o(s) projeto(s) com o(s) qual(is) esto envolvidos. Neste caso, o projeto funciona como um departamento temporrio, cujas lideranas de equipe e desenvolvedores podem trabalhar em mais de um projeto simultaneamente.

Figura 7 Estrutura organizacional do setor de desenvolvimento da empresa alvo de estudo

As duas formas de departamentalizao da empresa caracterizam-na como uma estrutura tipicamente matricial, haja vista que existe uma combinao de dois tipos de departamentalizao, uma funcional e outra por projetos. A empresa pode ser considerada uma estrutura matricial fraca, pois no existe hoje a figura do Gerente de Projetos, sendo os projetos conduzidos pelo Diretor de Tecnologia, Gerncias, Coordenadorias e Lideranas de Equipe.

40

4.4.

Diagnstico do ambiente interno

4.4.1. Contextualizao dos projetos da empresa A empresa alvo de estudo possui um conjunto de softwares desenvolvidos em 2 linguagens de programao (Java e C++) para viabilizar sua soluo PACS. No Setor de Desenvolvimento, cada software considerado como um projeto. Atualmente so 13 os projetos ativos na empresa, que juntos ou separadamente compe 8 produtos. Existe uma forte dependncia entre os projetos, mesmo nos casos que os projetos envolvidos em um produto especfico sejam concebidos em linguagens diferentes.

4.4.2. Contextualizao das estruturas da empresa e seus papis Conforme citado anteriormente a empresa alvo de estudo tem seu foco no desenvolvimento de softwares para diagnstico de imagens mdicas. Estes softwares por sua vez geram produtos e servios que so os insumos que o setor Comercial, Marketing, Qualidade, Implantao e Suporte utilizam para o desenvolvimento de suas atividades. Estes setores sero ora denominados de stakeholders do setor de desenvolvimento de software.

4.4.3. Processo de desenvolvimento de software O processo e desenvolvimento de software da empresa alvo de estudo consiste das seguintes etapas:

41

4.4.4. Levantamento de requisitos Esta atividade efetuada pelos diversos setores da empresa como a Gerncia de Produto, o Setor Comercial, o Setor de Implantao e o Setor de Suporte. A Gerncia de Produto efetua pesquisa de mercado para avaliar diferencial entre ferramentas para o mesmo fim, solicitando funcionalidades de equiparao com produtos de empresas concorrentes. O Setor Comercial efetua consultas e solicitaes para o atendimento de exigncias contratuais de novos clientes. O Setor de Implantao aps efetuar suas atividades (implantao e treinamento), encaminha as solicitaes de melhorias (efetuadas pelos clientes durante suas atividades). O Setor de Suporte solicita melhorias na medida em que as mesmas so reportadas ao setor. Estes requisitos so reportados ao Setor de Desenvolvimento, onde so cadastrados (por projeto) em um software especfico para o cadastramento de requisitos, denominado JIRA (ATLASIAN, 2008).

4.4.4.1.

Identificao de erros e no-conformidades Esta atividade executada pelos mesmos envolvidos no levantamento de

requisitos, com a participao adicional do Setor de Controle de Qualidade. Suas ocorrncias tambm so cadastradas no software JIRA (ATLASIAN, 2008).

4.4.4.2.

Anlise de requisitos, erros e no-conformidades Uma vez registradas as ocorrncias de requisitos, erros e no-conformidades

efetuado o processo de anlise de caractersticas da ocorrncia, anlise de impactos e anlise de riscos que envolvem a mesma. 42

Ocorrncias podem ser desmembradas em mais de um outro projeto, uma vez que pode englobar uma funcionalidade especfica de um projeto. Esta anlise geralmente ocorre em breves reunies, entre o Diretor de Tecnologia e o(s) envolvido(s) no projeto que afetado pela ocorrncia. Nesta anlise tambm efetuada definio prvia de qual verso do projeto a mesma ser implementada ou solucionada.

4.4.4.3.

Definio de verses A definio de datas e de que quais itens (seja a implementao requisitos ou a

resoluo de erros) faro parte da prxima verso de cada software fica a cargo do Diretor de Tecnologia e do Lder da Equipe do projeto envolvida. A empresa atualmente adota a postura de desenvolvimento de releases curtos (de aproximadamente 30 dias), sob a justificativa de manter os clientes constantemente atualizados. Durante a pesquisa observou-se que dependendo da criticidade da solicitao, a gerao de uma verso pode ocorrer no mesmo dia da solicitao.

4.4.4.4.

Implementao Os desenvolvedores so encarregados de consultar diariamente o software JIRA

(ATLASIAN, 2008), para verificao e implementao das pendncias que esto sob sua responsabilidade.

43

4.4.4.5.

Controle de Qualidade Na medida em que so efetuadas implementaes, o Setor de Qualidade efetua

testes incrementais nas verses "parciais" de cada projeto. 4.4.4.6. Liberao de verses Finalizada a etapa de implementaes e de controle de qualidade, efetuada a gerncia de configurao das verses produzidas. Esta atividade consiste de um conjunto de atividades de apoio ao desenvolvimento no controle de mudanas efetuadas nos softwares. nela onde so gerados documentos de atualizao que sero encaminhados aos setores de Suporte e Implantao para atualizao e implantao de novas verses de softwares em clientes.

4.4.4.7.

Pesquisa e Desenvolvimento Em virtude da necessidade de estar constantemente inovando seus produtos, a

empresa alvo de estudo tem investido em pesquisa e desenvolvimento, buscando fomento junto a instituies como o FINEP (Financiadora de Estudos e Projetos) e o CNPq (Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico). Existe a perspectiva criao de novos projetos na empresa, caso estes fomentos sejam concretizados.

4.4.4.8.

Prticas de Gerenciamento de Projetos Durante o estudo de caso, pode-se observar que a empresa alvo de estudo no

aplica prticas especficas de Gerenciamento de Projetos em seu cotidiano. A prpria inexistncia do papel de Gerente de Projetos denota este fato. Existem atividades

44

organizacionais que merecem destaque, mas que no possuem vnculos ou referncias especficas com prticas de Gerenciamento de Projetos, que so: a) Definio de processos da ANVISA (Para todos os setores da organizao). b) Gerncia de Configurao. c) Anlise de Riscos simplificada (Sem formalizao, nem plano de aes corretivas).

4.4.5. Dificuldades encontradas Em decorrncia do crescimento da empresa (apresentado em item anterior neste captulo), ocorreram mudanas com relao ao nmero e ao perfil de clientes. Some-se a este fato ocorrncias como: Necessidade de criao de inovaes como diferencial competitivo, necessidade de atualizaes tecnolgicas, necessidade de estabilizao de verses dos 3 principais produtos da empresa e treinamento de novos recursos. Mesmo com o aumento do quadro de funcionrios (nos diferentes setores) o processo de desenvolvimento de software existente no est adaptado a esta nova realidade, o que ocasionou uma queda gradativa na capacidade de produo do setor de desenvolvimento. Mesmo efetuando esforos extras como tentativa de suprir a nova demanda, constatou-se uma queda na qualidade dos produtos e servios gerados. Em levantamento efetuado com os demais setores da empresa, foram constatados os seguintes problemas em relao ao processo de desenvolvimento de software atual: 1) Gerao de novas verses em perodos curtos (menores do que 30 dias): a) Dificulta a atualizao de clientes por parte do Setor de Suporte (apenas parte dos clientes recebem atualizao devido sua quantidade). b) Dificulta a atualizao e divulgao de manuais por parte do Setor de Implantao. c) Dificulta a especificao de prazos aos clientes por parte dos setores Comercial, Implantao e Suporte. 45

d) Dificulta a divulgao direcionada (a mdicos radiologistas e gerentes de TI dos clientes) de novas implementaes e ajustes. e) Dificulta o controle de qualidade, devido ao nmero de projetos a serem testados (sendo testadas apenas os incrementos / alteraes efetuadas e no todo o aplicativo novamente). 2) Gerao de verses por projeto e no do PACS como um produto: a) Dificulta o entendimento das dependncias entre projetos por parte dos Setores de Implantao e Suporte. Durante o levantamento de informaes, ficaram evidenciadas falhas de comunicao entre os setores no alinhamento de suas expectativas.

46

5.

PROPOSTA DE METOLOGIA Uma vez efetuada a reviso bibliogrfica, na qual foram apresentados conceitos de

metodologias de Gerenciamento de Projetos e efetuado o estudo de caso das atuais prticas que a empresa alvo de estudo utiliza, torna-se possvel identificar e propor uma maneira prtica de inserir prticas de Gerncia de Projetos empresa alvo de estudo. A proposta composta das seguintes fases: a) Criao de um novo processo de desenvolvimento de software. b) Apresentao do novo processo de desenvolvimento de software. c) Alinhamento de processos internos dos stakeholders com o novo processo de desenvolvimento. d) Formalizao de processos. e) Sugesto de prticas de gerenciamento de projetos.

5.1.

Novo processo de desenvolvimento de software Conforme observado no estudo de caso, o processo atual de desenvolvimento de

software da empresa alvo de estudo no suporta a nova demanda ocasionada pelo crescimento da empresa. essencial que o mesmo seja re-adequado para no apenas suportar a nova demanda, mas estar alinhado com os demais setores, que utilizam o produto dos projetos do setor de desenvolvimento como insumos para suas atividades. Mesmo no sendo este o foco deste estudo de caso (a re-adequao do processo de desenvolvimento de software), importante apresent-lo, pois a partir do mesmo que ser sugerida a incluso gradativa de prticas de Gerenciamento de Projetos na empresa alvo de estudo, servindo como meio.

47

O novo processo de software sugerido trata de uma mudana conceitual, pois como os projetos que compe o PACS esto fortemente interligados e cada vez mais com relaes de dependncias entre os mesmos, sugere-se que no mais sejam efetuadas liberaes de verses de softwares, mas sim, verses do PACS. Ao conjunto destas verses dos projetos sugere-se a definio de um nome especfico, seguido de um controle de verses numrico (Ex. PACS 1.0). O novo processo sugerido dividido em 3 etapas, descritas a seguir:

5.1.1. Primeira Etapa Sugere-se que esta etapa tenha a durao de trinta dias e seja composta de dois processos, que so: o Processo de Iniciao de Novo Ciclo de Desenvolvimento e o Processo de Testes Finais do Ciclo de Desenvolvimento Anterior. Sugere-se tambm que estes processos ocorram de forma paralela.

5.1.1.1.

Iniciao de Novo Ciclo de Desenvolvimento Neste processo, objetiva-se que o setor de desenvolvimento de software rena-se

com todos os seus stakeholders para a definio de quais funcionalidades iro compor cada software que compe o PACS. Sugerem-se duas reunies durante este processo. Sobre a primeira reunio de cada projeto, sugere-se que ocorra nos dez primeiros dias desta etapa. nela onde devero ser apresentadas as necessidades de cada stakeholder, como descrito a seguir: a) Equipe de desenvolvimento do projeto: Equipe que ser responsvel pela anlise e implementao das solicitaes.

48

b) Lderes de Equipe de projetos dependentes: Caso o projeto cujas funcionalidades a serem incorporadas no ciclo de desenvolvimento dependam de um outro projeto, sugere-se a participao das lideranas de equipe dos mesmos para alinhamento de expectativas. c) Gerente de Produto: Para solicitaes de diferenciais de produto, efetuados por intermdio de pesquisa mercadolgica. d) Coordenadoria de Implantao: Para solicitaes de clientes cuja implantao e treinamento j ocorreram. e) Gerente de Suporte: Para as solicitaes de correes de erros, reportadas por clientes. f) Gerente Comercial: Para incorporar solicitaes contratuais de clientes novos. g) Gerente Financeiro: Caso haja a necessidade de ser efetuada alguma aquisio para o processo de desenvolvimento, a presena deste gerente se faz necessria para que possa efetuar previso oramentria. h) Coordenadoria de Qualidade: Para que possa mapear todas as necessidades, solucionar dvidas sobre os objetivos das mesmas e assim traar plano global de testes. i) Gerente de Marketing: Para verificar as necessidades de insumos por parte do setor de Desenvolvimento, como por exemplo a produo de cones. Uma vez apresentadas as necessidades, sero efetuadas em conjunto anlises de viabilidade, anlise de riscos, impacto sobre outros projetos, dentre outras consideraes importantes. Objetiva-se que ao final desta reunio, tanto desenvolvedores como os stakeholders j tenham definido o escopo prvio do que ir compor a verso do projeto em anlise (com todos os requisitos, devidamente cadastrados no software JIRA (ATLASSIAN, 2008)), alinhando assim expectativas entre as partes interessadas.

49

Sobre a segunda reunio de cada projeto, sugere-se que seja efetuada nos ltimos dez dias desta etapa. nela onde a equipe tcnica de desenvolvimento ir efetuar definies de arquitetura, modelagem de objetos, modelagem de dados, definies de tarefas por recurso. 5.1.1.2. Testes Finais do Ciclo de Desenvolvimento anterior Conforme citado anteriormente, trata-se de processo paralelo ao de iniciao de ciclo de desenvolvimento. Uma vez que a equipe de desenvolvimento no estar em continuamente reunida para a definio de verses, sugere-se que em paralelo a estas atividades, sejam efetuados ajustes nas verses do ciclo de desenvolvimento anterior, ou seja, a que a equipe de desenvolvimento esteja focada na estabilizao dos aplicativos que compe a verso anterior do PACS. Para viabilizar a estabilizao de verses de software que compe o PACS, sugerese que sejam liberadas verses RC (Release Candidate5) em ambiente de produo de um nmero reduzido de clientes. Para os clientes dispostos a testarem as novidades do PACS, podem ser concedidas algumas vantagens contratuais, como atualizaes gratuitas, por exemplo.

5.1.2. Segunda Etapa Trata-se da etapa a ser considerada como o Desenvolvimento do Ciclo, onde sero implementadas as funcionalidades definidas nos escopos dos projetos durante a 1 etapa. Sugere-se que esta etapa tenha a durao de quarenta e cinco dias e que nela sejam definidos marcos dentro dos projetos, para que na medida em que forem alcanados, sejam
5 Refere-se liberao de uma verso com potencial para se tornar o produto final. Nesta fase, o produto apresenta todas as funcionalidades

concebidas sem a presena de erros impeditivos;

50

geradas verses parciais a serem encaminhadas ao Setor de Qualidade para a efetivao de testes. Sugere-se tambm que o Setor de Marketing produza e disponibilize os insumos solicitados pelo Setor de Desenvolvimento, como por exemplo, a criao de cones. Cabe nesta etapa ainda, como sugesto, a atualizao de clientes com verses fechadas de aplicativos de ciclo anterior, alm de seus manuais e materiais de divulgao, pelo Setor de Suporte.

5.1.3. Terceira Etapa Trata-se da etapa a ser considerada como Testes Iniciais do Ciclo. Sugere-se que esta etapa tenha a durao de 15 dias. Nesta etapa as verses implementadas so liberadas para testes completos para o Setor de Controle de Qualidade. Nela o Setor de Desenvolvimento deve estar focado no ajuste de erros e no conformidades encontradas durante os testes. Sugere-se tambm que na medida em que forem finalizados os ajustes citados acima, sejam efetuadas as seguintes atividades pelo Setor de Desenvolvimento, para que os demais setores possam dar seqncia suas atividades: a) Encaminhamento de informao ao setor de implantao para atualizao de manuais. b) Encaminhamento de informaes ao setor de marketing para a divulgao de material de divulgao. c) Efetuar de treinamentos de novas funcionalidades com os Setores de Suporte, Implantao e Comercial.

51

5.2.

Apresentao do novo processo de desenvolvimento A apresentao do novo processo de desenvolvimento aos demais setores da

empresa (stakeholders) tem o intuito de diminuir o impacto causado, por se tratar de uma mudana conceitual na concepo de projetos e gerao de produtos e servios. A figura 8 ilustra o novo processo de desenvolvimento proposto.

Figura 8 Novo processo de desenvolvimento proposto.

Objetiva-se tambm nesta fase obter desde o princpio a participao de todos os envolvidos, seja avaliando o processo, questionando motivaes, sugerindo mudanas, enriquecendo-o, dando incio um processo de desenvolvimento colaborativo entre setor de desenvolvimento e seus stakeholders, fazendo com que todos sintam-se parte integrante do processo.

52

Como toda mudana tende a gerar certa resistncia inicial, cabe apresentar aos envolvidos as vantagens do novo processo, no que diz respeito produtividade. Basicamente elas esto relacionadas ao ganho de tempo na execuo de atividades, descritas por setor a seguir: 1) Setor de Controle de Qualidade: a) Intervalo de tempo maior para efetuao de testes na empresa. b) Possibilidade de execuo de testes em ambiente de produo na 1 Etapa. 2) Setor de Suporte: a) Intervalo de 90 dias para a atualizao de clientes. b) Intervalo de tempo maior para treinamento interno de novas funcionalidades. c) Informar melhorias e correes aos clientes com base em prazos mais seguros. 3) Setor de Marketing: a) Intervalo de tempo maior para a gerao e divulgao de material de apresentao de melhorias e novas funcionalidades (o popular o que h de novo?). 4) Setor de Implantao: a) Intervalo de tempo maior para incremento e atualizao de manuais. b) Intervalo de tempo maior para preparao de treinamentos. c) Intervalo de tempo maior para agendar implantaes em novos clientes. d) Informar melhorias e correes aos clientes com base em prazos mais seguros. 5) Setor Comercial: a) Possibilidade de prospeco antecipada (e com prazo de entrega seguro) de novas funcionalidades. b) Informar melhorias e correes aos clientes com base em prazos mais plausveis. 6) Setor de Desenvolvimento: a) Maior controle em seu processo produtivo.

53

b) Alinhamento de expectativas com os demais setores da empresa.

5.3.

Alinhamento de Processos Uma vez apresentado, debatido, melhorado e aceito o novo processo de

desenvolvimento de software, sugere-se que seja efetuado um alinhamento do mesmo com os processos internos dos stakeholders. Este alinhamento auxiliar na obteno de respostas a perguntas como: a) Em que etapa o desenvolvimento de software poder solicitar insumos ao setor de Marketing (por exemplo, a confeco de cones)? b) Caso hajam ocorrncias emergenciais de suporte durante a 2 etapa, como inseri-las no ciclo em andamento? c) Cabe na segunda reunio da 1 etapa, alguma nova solicitao de algum stakeholder que tenha surgido desde a primeira reunio? A identificao de informaes teis entre os processos, como necessidades, excees, dados de entradas e sadas, viabiliza no somente a integrao entre ambos, mas a possibilidade de serem monitorados e melhorados continuamente.

5.4.

Formalizao de Processos Com os processos (o de desenvolvimento de software e os dos stakeholders)

alinhados, sugere-se a formalizao dos mesmos. Como a empresa alvo de estudo j est em processo de registro com a ANVISA, importante que os novos processos sejam formalizados perante o rgo conforme suas diretrizes.

54

Convm citar que a formalizao de processos auxilia a divulgao e o conhecimento de todos para toda a organizao.

5.5.

Prticas de Sugeridas Visando a criao da cultura de Gerenciamento de Projetos na empresa alvo de

estudo, levando-se em considerao sua situao atual e seu planejamento estratgico, sugerem-se as seguintes prticas a serem inseridas de forma gradativa em seu contexto: a) Criao do papel de Gerente de Projetos: Conforme pode ser observado na estrutura organizacional da empresa estudada, no existe o papel do Gerente de Projetos. Sugere-se a criao deste papel, para que possa desempenhar atividades necessrias, com foco inicial na concepo, anlise e melhoria de processos, servindo de elo entre o Setor de Desenvolvimento e os stakeholders, agindo como facilitador. b) Passar mais tempo com os stakeholders: Citado como regra do XPM, tende a viabilizar uma viso direcionada (APM), sobre as reais expectativas e necessidades dos mesmos. c) Participao ativa de stakeholders na concepo de projetos e produtos: Citado na reviso bibliogrfica como prtica do XPM, esta sugesto visa tornar o processo de desenvolvimento de software aberto e colaborativo, propiciando transparncia, alinhando a produo de software aos seus objetivos reais. d) Encerramento de ciclos: Sugere-se que ao final de cada ciclo de desenvolvimento de software (apresentado no captulo Proposta de Metodologia) sejam efetuadas reunies do Setor de Desenvolvimento com seus stakeholders para que possa ser efetuado o encerramento do ciclo de desenvolvimento, onde sugere-se que sejam expostos e formalizados os erros e acertos do mesmo (popular lies aprendidas conforme PMBOK).

55

e) Melhoria contnua nos processos: Citada em praticamente todas as referncias da reviso bibliogrfica, a criao de prticas para inspeo e adaptao de processos, propiciando uma reflexo regular sobre seus sucessos e falhas auxilia na obteno da maturidade organizacional. f) Desenvolver e implantar o Gerenciamento da Comunicao: Conforme observado no estudo de caso, existem falhas de comunicao entre o Setor de Desenvolvimento e seus stakeholders. Visando sanar este problema, sugere-se a definio de processos que viabilizem a disseminao adequada das informaes entre ambos, assegurando a gerao, coleta, distribuio, armazenamento e apresentao das informaes s partes interessadas. g) Desenvolver e implantar o Gerenciamento da Qualidade: Uma vez que o novo processo de desenvolvimento sugerido tem duas de suas etapas voltadas para testes, sejam eles executados na prpria empresa, ou em ambiente de produo de um nmero reduzido de clientes, sugere-se a criao de processos para a certificao de que os softwares estaro sendo disponibilizados em conformidade com as expectativas iniciais dos clientes finais. h) Criao de metodologia de medio do novo processo de desenvolvimento de software: Visa obteno de informaes acerca da capacidade produtiva do Setor de Desenvolvimento, com o intuito de disponibilizar informaes para a tomada de decises da diretoria quanto incorporao de novos projetos ao portiflio da empresa. i) Criar processos de gesto de Conhecimento e Inovao: Com o intuito de formalizar o conhecimento tcito adquirido pelos recursos da empresa, visando facilitar a disseminao de conhecimento entre as diferentes reas da empresa alm da rpida adaptao de novos recursos.

56

6.

CONCLUSES No decorrer deste estudo foram sugeridas boas prticas de gerenciamento de

projetos com o intuito de introduzir de maneira gradativa o gerenciamento de projetos na empresa alvo de estudo. A reviso bibliogrfica propiciou o embasamento das metodologias de gerenciamento de projetos mais difundidas, de forma sucinta, uma vez que no era seu objetivo o aprofundamento nas mesmas, para que a partir deste embasamento fosse possvel a seleo ou adaptao das prticas que compe a metodologia proposta. A partir das prticas inseridas na metodologia, desde que seguidas, tem-se condies gradativamente conduzir projetos de uma maneira mais padronizada e organizada e ainda de efetuar um processo de melhoria contnua, sempre alinhado realidade e ao planejamento estratgico da empresa, viabilizando uma fcil adequao metodologias mais robustas, caso haja necessidade e interesse. Como resultado a metodologia proposta cumpre seus objetivos especficos, ou seja, efetua um estudo da empresa alvo, tomando conhecimento de sua estrutura, seus objetivos, seus processos e suas dificuldades. Com base nestas informaes, efetua a anlise no intuito de indicar e adaptar prticas baseadas na reviso bibliogrfica, levando em considerao o momento atual da empresa, como seu planejamento estratgico. Por fim, espera-se que este trabalho possa agregar valor empresa alvo de estudo, servindo como base na incluso da cultura de gerenciamento de projetos na mesma, melhorando o ndice de sucesso em seus projetos, aumentando a satisfao dos stakeholders internos e clientes por meio da melhora na qualidade dos servios entregues, alm de servir como base a outros trabalhos acadmicos.

57

6.1.

Sugestes para trabalhos futuros Por se tratar de um estudo de caso, que prope uma metodologia, este trabalho

apresenta uma sugesto para trabalhos futuros, descrito a seguir:

a) Aumento da maturidade de Gerenciamento de Projetos: Uma vez adotada e sendo seguida a metodologia de gerenciamento de projetos proposta neste trabalho, sugere-se que seja aumentado o nvel de maturidade do mesmo, sendo adicionados novos processos, tornando-a mais robusta, e que estejam coerentes com os objetivos e planejamento estratgico da empresa.

58

REFERNCIAS ATLASSIAN [On-line]. JIRA Bug and Issue Tracker. Disponvel em <http://www.atlassian.com/software/jira/ >. Acessado em: 07/2008. CASTOR, Belmiro Valverde Jobin. Gesto de Projetos nas pequenas Empresas: A busca da compatibilidade. Revista Mundo PM, n. 18, p. 07, 2007. DIAS, Marisa V. B. et al. Titulo do artigo. AGILE PROJECT MANAGEMENT: Um Novo Enfoque para o Gerenciamento de Projetos de Desenvolvimento de Sistemas de Tecnologia de Informao. So Paulo: Universidade de So Paulo USP. 6f, 2006. FILHO, Edes G. C. et al. Padres e Mtodos geis: Agilidade no processo de desenvolvimento de software. So Carlos: Universidade Federal de So Carlos Departamento de Computao, 2005. GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. So Paulo: Atlas, 2002. MAGALHES, Ana L. et al. Titulo do artigo. Revista ProQualiti: Qualidade na Produo de Software.Ncleo de Estudos Avanados em Engenharia e Qualidade de Software. Lavras: Universidade Federal de Lavras - UFLA. n. 1, p. 34, 2005. MAIA, Viviane. Crnios e ossos via internet. Revista Pequenas Empresas e Grandes Negcios, n. 227, p.50, 2007. SOFTEX. Associao para Promoo da Excelncia do Software Brasileiro. MPS.BR: Guia de Aquisio, verso 1.2,jun. 2007. Disponvel em: <www.softex.br>. Acesso em: 06/2008 MLLER, Elias. Mtodos geis: Uma Aplicao do Scrum no Simuplan. Passo Fundo, 2004, 92 f. Trabalho de Concluso de Curso (Bacharelado em Cincia da Computao) Universidade de Passo Fundo, Passo Fundo, 2004. NASCIMENTO, Gustavo V. et al. ProAgil: Um modelo para a implantao de processo de desenvolvimento gil. So Paulo: Universidade de So Paulo (USP) - Departamento de Cincias da Computao, 2007. PEREIRA, Paulo. et al. Entendendo Scrum para Gerenciar Projetos de Forma gil. Revista mundo PM, Curitiba, n. 14, p. 60, 2007. PMBOK - A guide to the project management body of knowledge. Project Management Istitute, 2004. PONS, Roberto H. N. et al. Gerenciamento de Mltiplos Projetos. Rio de Janeiro, 2004, 91 f. Trabalho de Concluso de Curso (MBA em Gerncia de Projetos) Fundao Getlio Vargas, Rio de Janeiro, 2004. VERGARA, Sylvia Constant. Projetos e relatrios de pesquisa em administrao. 5. ed. So Paulo: Atlas, 2004.

59

VALERIANO, Dalton L. Gerenciamento Estratgico e Administrao por Projetos. So Paulo: Makron Books, 2001. VARGAS, Ricardo V. Gerenciamento de Projetos: Estabelecendo diferenciais competitivos. 5 ed. Rio de Janeiro: Brasport, 2003. YOSHIMA, Rodrigo. Entregue Software Funcionando: Gerenciamento de Projetos gil. Revista Mundo Java, Curitiba, n. 26, p. 10, 2007. ZANONI, Roberto. Proposta de um Modelo de Gerncia de Projeto de Software. Porto Alegre, 2001, 47 p. Trabalho Individual - Programa de Ps-Graduao em Cincia da Computao Curso de Mestrado, Pontifcia Universidade Catlica do Rio Grande do Sul. Faculdade de Informtica. WEBER, Kival. et al. Titulo do artigo. Melhoria de Processo do Software Brasileiro (MPS.BR): Um Programa Mobilizador. SOFTEX Associao para Promoo da Excelncia do Software Brasileiro. 10f, 2006

60