UNIVERSIDADE PAULISTA RAPHAEL TREVIZAM FERMINO DE OLIVEIRA

TECNOLOGIA DA INFORMAO: Gesto de projetos para garantir a qualidade do produto, atingir a maturidade do processo de desenvolvimento e adquirir a certificao CMMI

SO PAULO 2010

RAPHAEL TREVIZAM FERMINO DE OLIVEIRA

TECNOLOGIA DA INFORMAO: Gesto de projetos para garantir a qualidade do produto, atingir a maturidade do processo de desenvolvimento e adquirir a certificao CMMI

Trabalho de desenvolvimento e aplicao dos conhecimentos adquiridos atravs das disciplinas de Gerenciamento de Projetos de TI, Empreendedorismo e Qualidade de Software, embasado numa solicitao de consultoria de uma empresa fictcia denominada de Software Developer; apresentado Universidade Paulista (UNIP) com a finalidade de Projeto Integrado Multidisciplinar (PIM VIII). Orientadora: Prof. Adriane Colossetti

SO PAULO 2010

Oliveira, Raphael Trevizam Fermino de, 1983 Tecnologia da Informao: Gesto de projetos para garantir a qualidade do produto, atingir a maturidade do processo de desenvolvimento e adquirir a certificao CMMI / Raphael Trevizam Fermino de Oliveira. - 2010. 35 f. ; 29,7 cm Orientadora: Adriane Colossetti. Projeto Integrado Multidisciplinar VIII Universidade Paulista, Gesto da Tecnologia da Informao, 2009. 1. Empreendedorismo. 2. Qualidade de Software. 3. Gerenciamento de Projetos de TI. I. Colossetti, Adriane. II. Universidade Paulista. Gesto da Tecnologia da Informao. III. Tecnologia da Informao.

RESUMO

Talvez por subestimarem a relevncia do business plan ou plano de negcio, setenta por cento dos novos empreendedores vem seus negcios desaparecerem todos os anos. Esta informao evidencia a importncia da adoo de um modelo de gesto eficiente e eficaz para projetos, processos e qualidade. Contudo, mesmo abarcando estudos em demasia, muitos profissionais de TI tm dificuldade em aplicar na prtica a teoria da gerncia de desgnio aprendida. O gerente do empreendimento precisa saber integrar e alocar adequadamente os venbulos, a fim de asseverar a obteno de xito. Pois os tcnicos especialistas apenas executam as tarefas operacionais. Como bssola para o alinhamento das fases s estimativas primordiais, preconiza-se a utilizao de um trinmio sagrado incluindo oramento, escopo e tempo. A qualidade do produto final deriva de uma anlise de risco minuciosa a partir da definio acurada dos requisitos ao planejamento, desenvolvimento e testes. Para a estipulao dos riscos e seus impactos, o compartilhamento de conhecimento emprico e terico ou experincia profissional precpuo. No compensa combater alguns riscos, quando eles forem nfimos. Porque isto elevar o custo total frivolamente. Partindo para outro passo, a fase de planejamento de projeto tambm espectvel. Nela acontece a visualizao panormica do ciclo de vida completo do prospecto, desde a concepo at o encerramento. Nenhuma ideia pode ser descartada, porm precisam passar pela viabilizao tcnica e comercial, antes de se transformarem em projeto. O mercado oferece uma gama imensa de ferramentas voltadas ao planejamento e gesto de projetos. Porm a transformao da ideia em algo slido e utilizvel e comercializvel sucede durante o processo de desenvolvimento. Assim sendo, esta a etapa mais crtica de um desgnio. A consumao de um solecismo ameaar todo o esforo incipiente e comprometer a qualidade final. Podendo, inclusive, paralisar as operaes do cliente e engendrar muitos prejuzos. Narrados concisamente alguns conceitos, este trabalho teve como objetivo a implantao de um modelo de Gesto de Projetos orientado para a aquisio da certificao oficial em CMMI, mediante solicitao da fabricante de sistemas fictcia Software Developer, situada em So Paulo - Capital, argumentando e explicitando as melhores solues e frameworks. Embasado nas teorias introduzidas, ao final o leitor consegue compreender a magnitude da necessidade da madureza dos processos. Palavras-chave: Anlise de risco; planejamento e gesto de projetos; processo de desenvolvimento; certificao oficial em CMMI; modelo de gesto; ciclo de vida; qualidade

ABSTRACT

Seventy percent of new entrepreneurs see their business disappear every year because they probably underestimate the relevance of the business plan. This information shows the importance of implementing a model of efficient and effective management for projects, processes and quality. Despite much study IT professionals find it difficult to apply in practice the theory of project management. The project manager needs to know how to use the resources to succeed. The technical experts performing only operations. Using the triangle project for the alignment of projects. The quality of the final product is the result of a careful risk analysis. Sharing empirical and theoretical knowledge is important to define the risks and impacts. Small risks are not corrected. Because this will increase the total cost unnecessarily. The planning phase of the project is also important. Her is the full view of the life cycle. No idea can be discarded. All ideas need to be approved for the training project. The market offers several tools aimed at planning and project management. The transformation of idea into something solid and usable happens during the development process. The development phase is the most critical of a project. The event of a mistake will threaten all the initial effort and compromise the final quality. Many losses can be generated. This work aimed at the implementation of the Project Management oriented to the acquisition of official certification in CMMI, upon request by the system manufacturer fictitious Software Developer, located in So Paulo - Capital, arguing and explaining the best solutions and frameworks. From the theories discussed the reader can understand the importance of the need for maturity of processes. Keywords: Risk analysis; planning and project management; development process; official CMMI certification; management model; life cycle; quality

SUMRIO

1. INTRODUO.......................................................................................................6 2. 2.1. 2.2.

2.2.1. 2.2.2. 2.2.3. 2.2.4.

DESENVOLVIMENTO .........................................................................................8 Anlise de Impacto .......................................................................................13 Planejamento de Projeto..............................................................................17

Work Breakdown Structure (WBS)...................................................................................20 Grfico Gantt ......................................................................................................................20 Project Evaluation and Review Technique ......................................................................21 Microsoft Project ................................................................................................................23

2.3. 2.4. 3.

Desenvolvimento de Projeto .......................................................................25 Como obter a certificao CMMI .................................................................29 CONCLUSO ....................................................................................................34

REFERNCIAS BIBLIOGRFICAS .........................................................................35

1. INTRODUO

Em prosseguimento ao servio de consultoria contratado anteriormente, a fabricante Software Developer uma desenvolvedora de sistemas bancrios para os segmentos de consrcio, financeiro e emprstimo; localizada na Capital de So Paulo pretende acrisolar ainda mais seus processos para elevar o grau de amadurecimento e asseverar a qualidade do produto final. E desta forma obter a certificao oficial em CMMI (Capability Maturity Model Integration), tornando-se mais competitiva tanto no mercado nacional quanto internacional. Boa parte dos solecismos detectados a princpio foi resolvida, com a implantao das melhores prticas reunidas na ITIL (Information Technology Infrastructure Library). Procedimentos foram criados e difundidos entre todos os funcionrios da organizao; para os gerenciamentos de configurao, incidentes, problemas, mudanas, liberao, nvel de servio, capacidade, disponibilidade, continuidade dos servios de TI (Tecnologia da Informao) e financeiro. Portanto, fazendo uso da ITIL, a companhia j galgou o segundo nvel do modelo CMMI de maturidade. Pois os processos no so mais improvisados e j podem ser replicados. Tambm as estimativas so baseadas em planejamentos ou vice-versa, os prazos so cumpridos e monitorados atravs de SLAs (Service Level Agreement) e as experincias so transformadas em documentos os quais ficam armazenados em servidores e disponveis para uma consulta do tipo clienteservidor. Embora os procedimentos estejam sendo praticados, controlados e monitorados; a evoluo paulatina e h muito a ser corrigido. Mediante o supracitado, a Consulting, uma empresa tambm situada em So Paulo Capital, foi recontratada para prestar nova consultoria. Desta vez voltada a auxiliar na identificao e correo das ineficincias impregnadas aos processos de anlise de impacto, planejamento e desenvolvimento de projeto. Sempre objetivando a obteno da certificao oficial da madureza de processos. Obedecendo esta lgica, desenvolver um estudo para fundamentar e consolidar alguns conceitos intrnsecos das disciplinas de Empreendedorismo, Qualidade de Software e Gesto de Projetos de TI. Sempre demonstrando como

eles podem ser empregados para a correo das deficincias vividas pela rea de TI, escolha do modelo de gesto dos projetos, definio do grau dos riscos, criao do plano de combate de eventualidades. Finalmente, contando com a experincia dos integrantes de sua equipe, ensinar o caminho a ser trilhado para a conquista da certificao oficial em CMMI, de modo a assegurar a aprovao pelo Software Engineering Institute (SEI).

2. DESENVOLVIMENTO

No Brasil e no mundo, setenta por cento das empresas deixam de existir no primeiro ano de vida.1 Este ndice reflete o despreparo dos novos empreendedores, pois, normalmente, eles no conseguem formular e formalizar o business plan ou plano de negcio. Talvez por subestimarem a sua relevncia. Desta forma, apostam na sorte e confiam em suas intuies, sempre desenvolvendo e abarcando o conhecimento emprico e, provavelmente, desprezando as teorias consolidadas por cientistas ou pesquisadores renomados.

30% Mortalidade no 1 ano de vida Sobrevivncia no 1 ano de vida 70%

Figura 1 ndice de mortalidade e sobrevivncia de empresas

Neste sentido, dentre os trinta por cento das empresas remanescentes da largada inicial, uma pequena parcela opera sem compreender a sua real capacidade, sem conseguir mensurar a ufania dos seus clientes, sem detectar suas deficincias e sem deter um mtodo voltado a combater as contingncias, devido ausncia de metodologias. A qual acaba trabalhando de maneira aleatria e sem rumo certo. Esta conduta uma armadilha, pois sua sobrevivncia em um mercado com constantes mutaes, onde novos concorrentes surgem numa velocidade extraordinria, depende de um excelente planejamento e de informao bem acurada que s pode ser conseguida com um bom gerenciamento de projetos e contnua anlise e melhoria de processos. Inclusive, salientemente, a gesto de algo depende de medies. Os ndices so essenciais s tomadas de decises e para a manuteno da tica empresarial.
1

MALAGUETA, Lrida. Apostila de Empreendedorismo. So Paulo: [s.n.], 2010. 28 p. il.

Antagonicamente ao exposto no pargrafo antecessor, elas correm um grande e srio risco de se desequilibrarem diante de uma turbulncia, podendo apresentar morte sbita. Afinal, sem dado preciso e consistente para a gerao de informao referencial, concreta e fundamental, fica impossvel prever os prximos passos e calcular os riscos inerentes ao segmento de atuao. Ademais, empresrios com esta peculiaridade de conduta fogem do perfil do empreendedor, pois empreender sinnimo de risco calculado.

GRUPO A Empresas planejadas

GRUPO B Empresas no planejadas

50% 70% 30% Linha do Risco de Fracassar (LRF) 50%

Considerando que as empresas de ambos os grupos venceram a fase inicial e sabendo que 30% dos novos empreendimentos adentram o mercado com sucesso todos os anos, as empresas planejadas tm 70% de chance de continuarem ativas, enquanto as no planejadas tm 50% de risco de fracassarem. Embora o grupo B venceu a largada inicial, est operando de forma aleatria. Contudo tem 20% a mais de vulnerabilidade, se comparado ao grupo A. Risco de fracassar Chance de sucesso

Figura 2 Linha de risco de fracassar (LRF) aps a largada inicial

Portanto,

para

corrigir

as

ineficincias

lacunas

(operacionais

administrativas) destas empresas, um modelo de gesto para projetos, processos, qualidade, entre outros precisa ser adotado impreterivelmente. Atravs do gerenciamento, ser possvel compreender e administrar os recursos atuais, alm de assegurar o correto planejamento s novas conquistas ou projees. Porm, antes de discutir o tema gesto de projetos e demais atrelados a ele e suas consequncias (anlise de impacto, planejamento, desenvolvimento ou certificaes de reconhecimento de excelncia num segmento), faz-se necessrio explicitar o significado de projeto. Todo produto ou servio ou a prpria fundao de uma companhia fruto de um projeto. Consentneo com o Dicionrio Michaelis da Lngua Portuguesa, projeto

10

(uma palavra oriunda do latim projectu) um plano para a realizao de um ato.2 Ainda, segundo Halla (2010) trata-se de um esforo temporrio para criar um produto e/ou servio. Kerzner (2006) define projeto como um empreendimento com objetivo bem definido, que consome recursos e opera sob presses de prazos, custos e qualidade. Outrossim denomina-os de atividades exclusivas em uma empresa. Os projetos renem e vendem conhecimento. No importa qual seja a estrutura formal de uma organizao.3 Muitos profissionais de TI (Tecnologia da Informao) adquirem uma boa formao superior, fazem um ou vrios MBA (Master of Business Administration) ou especializaes diversas, outros auferem o nvel de mestrado ou doutorado ou psdoutorado, participam de seminrios, contudo sempre deparam com uma incgnita: como aplicar na prtica a teoria da gerncia de projetos (ou similares) aprendida? Afinal o modelo de gesto perfilhado pelo GP (Gerente de Projetos) determinar o sucesso ou fracasso de um projeto. Para Kerzner (2006), divididos em quatro fases, os projetos apresentam alguns fatores crticos, como: fase de aceitao pela gerncia executiva; fase de aceitao pelos gerentes de rea; fase de crescimento; e fase de maturidade. A fim de asseverar a obteno de xito, conforme demonstrado na figura 4, os gestores precisam aprender a: ouvir e abarcar as preconizaes oriundas dos colaboradores ou funcionrios; ter cincia de que alteraes precisam ser realizadas; assegurar a participao do alto escalo na gerncia dos projetos, sempre explicitando suas funes; garantir a elevao dos interesses da empresa acima dos pessoais; admitir responsabilidade; contribuir com o avano de todos os envolvidos; aceitar o emprego de frameworks ou ferramentas ou metodologias para o controle e monitoramento do setor; estar sempre disposto ao planejamento; alinhar a programao s estimativas originais, obedecendo ao trinmio sagrado (escopo, tempo, oramento); e, finalmente, treinar seu efetivo. Atualmente, a parte operacional ou de execuo das tarefas destina-se aos tcnicos especialistas. O GP fica com o papel de integrador de recurso, controlando e monitorando o planejamento, a programao e o desempenhar de todas as
2 3

HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 01 p. il. Escrita de STEWART, Thomas A. (1997). Frase extrada do livro Gesto de Projetos, referenciado no final deste trabalho.

11

atividades intrnsecas ao empreendimento, sempre focado nos objetivos e com o propsito de alcanar xito.

Figura 3 Tringulo do projeto

Os trs elementos do tringulo do projeto ou trinmio sagrado so imprescindveis ao sucesso, porque todo projeto pretende gerar um resultado dentro de um tempo estipulado, com incio e fim, e conforme os venbulos disponveis. Afinal os projetos no podem ser arquitetados com evo e precisam ser compatveis com os meios existentes e tangveis. Contudo, um projeto tambm corre o risco de fracassar, caso seu gerente: deixe de aceitar ideias alheias, inibindo o talento inventivo; menospreze a necessidade de mudana, devido ao comodismo ou abnegao de viso por autoestima; confie o controle das atividades exclusivamente ao nvel executivo, rejeitando ou isentando-se de suas responsabilidades; proba o compartilhamento de informao; dificulte o progresso dos subordinados, por temer a perda do cargo; compreenda a padronizao dos processos como ameaa e no benefcio; despreze o planejamento por confiar demasiadamente no conhecimento e experincia de sua equipe; determine o estado do projeto mediante a programao; e deixe de rastrear o custo real do projeto, correndo o risco de ultrapassar o oramento previamente proposto ou determinado. Portanto explicita-se desde j que a satisfao dos clientes e o sucesso dos projetos
4

dependem

de

uma

anlise

de

risco

minuciosa,

planejamento,

HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 04 p. il.

12

desenvolvimento e de um bom framework ou metodologia para apoiar e asseverar a maturidade dos processos.

Integrar o auto escalo

Proteger os interesses da empresa

Aceitar mudanas

Ter responsabilidade

Saber ouvir Incio

CICLO PARA A OBTENO DE SUCESSO EM UM PROJETO

Contribuir com o avano da equipe

Treinar o efetivo

Adotar frameworks

Alinhar a programao com as estimativas

Planejar sempre

Figura 4 Diagrama de como obter sucesso em um projeto

Assim

sendo

descritos

alguns

pontos

prceros

atinentes

ao

empreendedorismo, qualidade e preciso de um modelo de gesto padronizado, a empresa Consulting apresentar uma proposta bem fundamentada e argumentada fabricante de sistemas Software Developer de como solucionar suas ineficincias. Embora a aludida empresa tenha angariado a resoluo parcial das suas imperfeies embasada na consultoria passada, ela continua precisando de apoio tcnico especializado e profissional para aperfeioar seus controles e adquirir um nvel de madureza satisfatrio.

13

Para tanto, partindo desta premissa, os itens a seguir inculcaro modelos aos processos de anlise de impacto, planejamento e desenvolvimento de projeto e como obter a certificao do paradigma de maturidade do processo de desenvolvimento.

2.1. Anlise de impacto

extremamente importante formular e realizar um estudo dos diversos cenrios propcios a desastres ou insucessos, os quais podem prejudicar o funcionamento da organizao (projetos, processos, entre outros), para a preveno contra os impactos negativos e descomunais, com a criao de planos de contingncia. Magalhes e Brito (2007) preceituam para esta fase a identificao dos eventos que podem causar interrupo nos processos de negcios, a avaliao de risco para a definio dos impactos inerentes e a elaborao de um plano estratgico claro para salvaguardar a continuidade do negcio. O processo de anlise de impacto precisa ser minucioso, sempre avaliando as vantagens e desvantagens e levando em considerao o custo-benefcio. Existem basicamente dois tipos de medies: quantitativas e qualitativas. Enquanto a medida qualitativa aponta os setores carentes de melhoria imediata, a mensurao quantitativa indica a grandeza do impacto para posterior estudo e resoluo.
Tabela 1 Exemplo de categorias de impacto Nvel Alto
5

Mdio Baixo

Definio Perda significativa dos principais ativos e recursos. Perda de reputao, imagem e credibilidade. Impossibilidade de continuar com as atividades de negcio. Perda dos principais ativos e recursos. Perda da reputao, imagem e credibilidade. Perda de alguns dos principais ativos e recursos. Perda da reputao da imagem e credibilidade.

MAGALHES, Ivan Luizio; BRITO, Walfrido. Gerenciamento de servios de TI na prtica. So Paulo: Novatec Editora, 2007. 421 p. il.

14

A fim de exemplificar um modelo de tabela utilizada para a anlise do impacto decorrente de certos riscos, a figura 5 traz um formulrio de anlise de impacto utilizado pela Agncia de Gerenciamento de Riscos do governo americano.

Tipo de emergncia

Probabilidade Baixa 1 Alta 5

Impacto Humano Baixo 1

Impacto nos Ativos

Impacto no Negcio Alto 5

Recursos Internos Pouco 1

Recursos Externos Muito 5

Total

Figura 5 Formulrio de anlise de impacto Imagem retirada do documento FEMA Federal Emergency Management Agency do governo americano

Impacto significa o efeito de um risco, tendo pesos oscilantes e proporcionais a cada evento em particular. Sua consumao pode ameaar o sucesso de um empreendimento, assim como transformar-se numa proficuidade. Em uma de suas definies, risco a probabilidade ou incerteza de algo ocorrer. Pode ser considerado desprezvel (quando oferece pouco prejuzo) ou grave (quando inclui muitas implicaes). Da a relevncia em administr-los.

Concatenao

Compartilhamento de conhecimento Gerente

Definio do grau dos riscos

Subordinados

Criao do plano de contingncia

Figura 6 - Definio do grau dos riscos para a gerao do plano de contingncia

Dificilmente um projeto alcanar xito, sem um eficiente e eficaz gerenciamento de risco. Todos os stakeholders7 ou interessados ou colaboradores convolutos em um projeto precisam ser ouvidos. A contribuio com o conhecimento emprico e terico ou experincia profissional desenvolvida ao longo da carreira
6 7

MAGALHES, Ivan Luizio; BRITO, Walfrido. Gerenciamento de servios de TI na prtica. So Paulo: Novatec Editora, 2007. 421 p. il. Stakeholder a parte interessada ou interveniente que afeta ou pode ser afetada por uma atividade.

15

precpuo para a definio do grau dos riscos, como pode ser visto nas figuras 6 e 7. O tema proposto neste captulo comea a ser estudado desde a fase de planejamento, onde tambm se encaixa o processo de anlise de riscos. H uma singular distino entre as atividades de gerenciamento e anlise de risco. Enquanto a primeira busca criar mtodos para controlar os imprevistos (previso da probabilidade de cenrios problemticos) dentro de uma faixa de variao tolervel, a segunda visa identificar e avaliar os fatores e impactos dos riscos a fim de mitigar suas ascendncias no resultado final ou esperado. A anlise de um risco deriva da compreenso do objetivo do projeto. Desta forma, descobrir quais so os fatores de risco associados e que podem atrapalhar o seu desenrolar e critrios estipulados ao xito. Detectados os fatores dos riscos imanentes; conjecturar o valor do impacto peculiar e individual. Assim fica mais fcil priorizar os pontos a serem corrigidos e desenhar o plano de tratamento s eventualidades. Com o mtodo de contingncias traado, tem como avaliar se compensa combater um risco. Afinal, se o seu impacto for nfimo ou desprezvel, no vale a pena investir recursos para a sua conteno, porque aumentar o custo do projeto frivolamente. Maiores detalhes podem ser observados na figura 7.

Fatores crticos de sucesso Processo da gerncia de risco

Monitorao FR

Executa contingncias

Processo de controle de risco

Processo de gerncia de risco

Anlise de risco

Controle de risco

Identifica objetivos do projeto Define resposta ao FR

Identifica fatores de risco (FR) Redefine plano de projeto

Estima impacto do FR

Processo de anlise de risco

Figura 7 Processo de gerenciamento de riscos

Concernente ao processo de controle de risco, o monitoramente deve ser

8

HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 43 p. il.

16

plasmado por um membro da equipe. Geralmente esta atividade pertinente ao gerente de projetos. uma tarefa voltada a apontar o momento do acontecimento dos problemas previstos para a execuo da soluo criada, programada. Este assunto passa por um processo de acrisolamento e evoluo, portanto, no existe uma receita pronta do caminho a ser trilhado. Todavia, alguns padres foram escritos pela ISO (International Organization for Standardization) no documento ISO/IEC Guide 73 Risk Management Vocabulary Guidelines for use in Standards, que um guia padro ao gerenciamento de riscos, segundo Halla (2010). Ainda dentro deste contexto, fazendo uso de dados histricos, algumas ferramentas de qualidade podem ajudar a elucidar os pontos crticos e colaborar com o gerenciamento. So elas: diagrama de Pareto, diagrama de causa e efeito ou diagrama de Ishikawa, lista de verificao, histograma, diagrama de disperso, grfico linear e grfico de controle. Objetivada em exemplificar como uma ferramenta de qualidade pode contribuir com a identificao de um risco e do panorama geral, a figura 8 traz uma lista de verificao classificada de tabela de frequncia. Onde a maior frequncia de erro ocorreu do trigsimo ao trigsimo quinto dia.
Tempo (dias) 10 a 15 15 a 20 20 a 25 25 a 30 30 a 35 35 a 40 40 a 45 45 a 50 f II III IIIIIIIIIIII IIIIIIIIIII IIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIII IIIIIII III
9

Figura 8 Exemplo de uma tabela de frequncia Fonte: Ramos (2008)

Uma concluso ou deduo possvel que aumentou a falta de ateno dos funcionrios ou colaboradores aps o pagamento. Talvez porque ficaram descontentes ou insatisfeitos com seus salrios. Portanto, antes de criar o plano de combate de casualidade para sanar o problema, uma pesquisa indicada para desvendar o motivo de tamanha incidncia. Finalmente, por abranger todos os aspectos intrnsecos, a avaliao de
9

COSTA, Ivanir. Apostila de Qualidade de Software. So Paulo: [s.n.], 2010. 21 p. il.

17

impacto imprescindvel ao gerenciamento de riscos. Inclusive, a qualidade do produto final est diretamente atrelada a este gerenciamento.

2.2. Planejamento de projeto

A fase do planejamento de um projeto a mais espectvel, pois ela contempla todo o ciclo de vida do desgnio, sendo o comenos de estudar o contexto por completo, lobrigando os diversos cenrios possveis e fomentando a criao dos planos de combate aos solecismos. Kerzner (2006) coloca o planejamento estratgico como a essncia para a sade das empresas. Em longo prazo ele pode ser a diferena entre o sucesso e o fracasso. O mesmo autor, fazendo uma anlise circunscrita, inclui o plano de carreira dos gerentes como fator decisivo para a obteno de excelncia ou mediocridade em gesto de projetos. Nesta linha de raciocnio, os prospectos precisam ser compostos das fases de concepo, definio, iniciao, execuo e fechamento de acordo com o apresentado na figura 9.

Conceber (ideia)

Definir (plano)

Iniciar (time)

Executar (trabalho)

Fechar (encerrar)

Figura 9 Ciclo de vida de um projeto

10

Assim sendo, tudo comea com o brainstorming ou criatividade ou sbito de ideia, onde um ator sugere a inveno de algo (produto, servio, entre outros) para ser verificado e tornado comercializvel. A fim de calcular a viabilidade tcnica do projeto, a direo da companhia
10

HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 09 p. il.

18

necessita averiguar o potencial mercadolgico da proposta primordial. Tambm carece desvelar quais benefcios podem ser auferidos versus o valor investido, alm de checar se os venbulos disponveis so suficientes para a execuo do pretendido e estimar o custo total aproximado. Aps o consentimento ou aprovao da direo, obrigatoriamente, formular de maneira explcita e disponibilizar aos envolvidos um plano contendo as metas e o escopo a ser atingido. Sempre certificando a compreenso de todos a respeito da razo do empreendimento, dos detalhes dos resultados aguardados, das atividades a serem praticadas, das funes e responsabilidades particulares, do tempo ou cronograma estipulado e do oramento destinado aos recursos. Estando garantido o entendimento geral, d-se o start ou incio do desgnio, alocando os venbulos em suas respectivas posies. O GP (gerente de projeto), por sua vez, comea a mapear as tarefas para alinh-las s estimativas ou propsitos. A figura 10 traz maiores detalhes do supracitado.

INCIO DO PROJETO
PLANEJAMENTO Criao dos planos com as metas e escopo Divulgao dos planos da etapa anterior Certificao de que os planos foram entendidos

VALIDAO TCNICA Verificao do potencial mercadolgico da ideia Gerao da estimativa dos custos totais Estudo dos benefcios versus o valor investido

Averiguao dos recursos necessrios

Obteno de aprovao da diretoria

Figura 10 Diagrama da viabilidade tcnica e de comercializao da ideia at o incio do projeto

Durante a execuo, fazer um policiamento das atividades, com o intuito de verificar suas consonncias em relao ao previamente planejado. Como solecismos podem suceder (cenrios problemticos percebidos na fase de planejamento para o

19

desenvolvimento do plano de conteno de eventualidades), aps a correo das falhas consumadas toda a equipe deve tomar conhecimento. Deste modo assegurase o emprego de revises impreterveis, consentneo com a figura 11. Finalmente, havendo a aprovao do cliente final, o projeto encerrado. Como nota especial e sobressalente, todos os erros sobrevindos precisam ser documentados para posterior consulta. Afinal, uma alterao possibilita a engendrao de outra a qual pode passar por despercebida, mesmo com todos os testes efetuados ao longo do desenvolvimento.

Planejamento

Desenvolvimento

Teste

Dados referenciais disponveis aos novos planejamentos

Solecismo

Aprovado? S

Registro da falha

Aceitao S Registro da soluo

Encerramento

Base de dados dos solecismos consumados e resolvidos

Figura 11 Diagrama da documentao dos problemas

O mercado disponibiliza algumas ferramentas bastante interessantes para a gesto de projetos, dentre elas destacam-se: Work Breakdown Structure (WBS), Grfico Gantt, Critical Path Method (CPM), Project Evaluation and Review Technique (PERT) e Microsoft Project. Com elas fica mais fcil vislumbrar o contexto ou o cenrio total ou conjunto ou sequncia de tarefas.

20

2.2.1. Work Breakdown Structure (WBS)

Sendo fcil de utilizar, a WBS orientada ao planejamento e controle de projeto, possibilitando a estimativa e administrao dos custos e contribuindo com a definio, organizao e classificao do escopo proposto pelo cliente atravs do ajuntamento das tarefas, onde se cria uma lista estruturada ou sumarizada e com numerao encadeada das atividades e suas dependentes, como o apresentado na tabela 2.
Tabela 2 Exemplo de WBS WBS 5151.1 5151.1.1 5151.1.2 5151.1.3 5151.1.4 5151.1.5 5151.1.6 5151.1.6.1 5151.2
11

Atividade Fase piloto obter software instalar software configurar software criar pacote para instalao silenciosa Instalar pacote em uma estao de fase Efetuar testes de software Testar interface/enviar arquivo Fase implantao

Assunte que todos os itens da WBS afigurada na tabela 2 fazem parte da atividade 5151, a qual fui subdividida em dois grupos (grupo um e grupo dois). Inclusive, o sexto componente do grupo um foi desdobrado em dois. Halla (2010) determina que a WBS inclua 100% (cem por cento) do trabalho definido pelo escopo do projeto, no gere a sobreposio de escopo entre elementos e trate o resultado planejado como uma tarefa.

2.2.2. Grfico Gantt

J o grfico Gantt12 ou grfico de Gantt ilustra o cronograma atravs de barras horizontais e permite a sobreposio de tarefas, afinal algumas atividades podem
11

HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 20 p. il. 12 Criado por Henry Gantt entre 1910 e 1915.

21

acontecer concomitantemente, como o caso do departamento de compras e engenharia de software, pois os programas podem ser desenvolvidos simultaneamente com a fase de aquisio de bens ou servios.

Figura 12 Modelo de grfico Gantt

13

Na figura 12, a atividade C est sendo realizada ao mesmo tempo em que a atividade B est acontecendo.

2.2.3. Project Evaluation and Review Technique (PERT)

O mtodo PERT especifica as atividades interdependentes, objetivado em elucidar a ordem impretervel de desenvolvimento. Tambm tem a finalidade de identificar o tempo mnimo requerido ao trmino do projeto. Veja maiores detalhes na figura 13.

Atividade A B C D E F G H I
O N P

Predecessor A A B C F D E

Tempo Estimado Otimista Normal Pessimista (h) (h) (h) 2 4 6 3 4 5 2 5 8 4 5 6 7 8 10 1 4 8 1 2 3 4 7 8 1 5 6

Mdia 4,00 4,00 5,00 5,00 8,17 4,17 2,00 6,67 4,50

Tempo otimista Tempo normal Tempo pessimista

O + (4 N ) + P mdia = 6

Figura 13 Exemplo de tabela PERT

13 14

14

Fonte: <http://www.newtonwagner.net> HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 22 p. il.

22

Com o mtodo PERT fica fcil reconhecer as atividades e suas dependentes ou predecessores. Conforme o exemplificado na figura 13, as atividades C e D necessitam da concluso da atividade A para serem instauradas. E assim sucessivamente. Outra vantagem do aludido mtodo que ele empadroa trs tipos de tempos estimados para cada uma das atividades. Portanto, uma mdia pode ser calculada, a fim de encontrar o tempo aproximado entre o incio e o fim do projeto. Depois do planejamento formalizado com uma das ferramentas citadas anteriormente, possvel desenhar os caminhos a serem percorridos ou trilhados, a fim de excogitar o caminho crtico (maior caminho ou aquele que pode comprometer o cronograma caso sofra alguma alterao significativa de tempo, devido ao impacto de algum risco consumado). A figura 14 delineia o Critical Path Method (CPM) da tabela PERT da figura 13.

30 C 5h 10 A 4h Incio B 4h 20 E 8,17h D 5h

F 4,17h

40

50 H 6,67h

G 2h

60

I 4,50h

Fim

Figura 14 Exemplo de grfico PERT para calcular o caminho crtico

Com o grfico acima possvel calcular o tempo mnimo necessrio para cada um dos caminhos, de acordo com a tabela 3.
Tabela 3 Tempo dos caminhos do projeto Caminho A-C-F-G A-D-H B-E-I Tempo 4 + 5 + 4,17 + 2 4 + 5 + 6,67 4 + 8,17 + 4,50 Total 15,17h 15,67h 16,67h

Ou seja, o caminho crtico do grafo acima B-E-I, com quase dezessete

23

horas. Caso uma das atividades deste caminho sofra alargamento de tempo, todo o projeto ser prejudicado. Contudo, esta uma ferramenta de suma importncia aos gerentes de projetos.

2.2.4. Microsoft Project

O programa proprietrio Microsoft Project designado ao gerenciamento de projetos, e engloba as demais ferramentas citadas. Halla (2010) aponta algumas de suas funcionalidades, como: durao de tarefas (datas, calendrios); grfico de Gantt; modelo probabilstico; diagrama de rede; custos (fixos e no fixos ou outros); relatrios; etc.

Figura 15 Tela principal do Microsoft Project

Enfim preconiza-se a adoo do Microsoft Project para um eficiente e eficaz planejamento, controle e monitoramente de todas as fases dos projetos desenvolvidos pela fabricante Software Developer. Porque o mencionado programa, antagonicamente a uma soluo hermtica, ergonmico e favorece a

24

administrao desde a concepo da ideia at a consumao e finalizao do desgnio. Concisamente, por suportar e incluir os dados bsicos requeridos s mensuraes indispensveis aos processos de governana e por engendrar relatrios de equiparao, ele ajuda os gestores de projeto a manterem o alinhamento do executado com as estimativas primordiais e de interesse da organizao e do cliente, positivando uma ufania global e garantindo um resultado auspicioso, consonante com a figura 16.

Execuo

Alinhamento

Estimativa de tempo e custos; definio do escopo; entre outros.

Fase de planejamento

Relatrios Definio dos requisitos

Programa Microsoft Project

Servidores operando em sincronismo SGBD

Sistema gerenciador de banco de dados (SGBD) Figura 16 Como empregar o programa Microsoft Project para o gerenciamento de projetos

Ao constatar desvios atravs dos relatrios sumariados e dependendo da magnitude da anomalia, o plano de contingncia pode ser aplicado para a normalizao e realinhamento do foco.

25

2.3. Desenvolvimento de projeto

Pertencente ao departamento de engenharia, nesta fase a qualidade do produto precisa ser garantida, pois qualquer falha culminar com o insucesso do projeto. Nela sucede a transformao da ideia principal em algo slido e utilizvel ou comercializvel. Um dos maiores problemas enfrentados pela empresa Software Developer pode estar residindo no desenvolvimento. Quando as atividades dos clientes ficam paralisadas por horas, sinal de que ocorreram falhas durante a confeco do sistema ou mdulo. Provavelmente os testes so insuficientes ou nem esto sendo ministrados. Assim sendo, como sanar os problemas apresentados para assegurar a qualidade do produto final? Em resposta, consoante com os conceitos anteriormente defendidos e propostos, todo desgnio precisa compreender as fases de estipulao dos requisitos, planejamento e construo de um arqutipo. Para executar vrios testes em busca de erros, aps a concluso do prottipo. Solecismos vo aparecer sempre, caso contrrio os experimentos so ineficientes. Veja a figura 17.

S Treinamento Satisfao N Qualidade

Instalao

Implantao

Produo

Testes

Definio dos requisitos

Planejamento

Construo de um prottipo

Figura 17 Modelo de gesto satisfatria para a fase de desenvolvimento

26

De acordo com a figura 17, o produto s pode ser enviado para produo depois da etapa de testes. Seno os custos estimados se elevam, comprometendo a qualidade aguardada e colocando o empreendimento em risco, devido aos retrabalhos. Contudo, atualmente isto fato consumado. Consequentemente, a conta est sendo paga pelos clientes os quais s no procuraram a concorrncia visto que o software exclusivo, em virtude da patente auferida. Em continuao da produo vem o estgio de instalao e capacitao do usurio final. Dentre os diversos frameworks disponveis ao desenvolvimento de software, interativo e gil so dois modelos bastante chamativos e atraentes. Com o tipo interativo verifica-se constantemente o progresso das atividades executadas, garantindo desta forma o alinhamento contnuo do realizado com o requisitado pelo cliente. At porque o pessoal do desenvolvimento pode ter entendido o solicitado de maneira distorcida ou o cliente decide sugerir uma alterao inesperada. Observe o delineado na figura 18.

Verificao ou alinhamento

Validao

Encerramento

Definio dos requisitos

Planejamento

Verificao ou alinhamento Figura 18 Modelo de desenvolvimento interativo

Porm, ao estgio de desenvolvimento de software da fabricante Software Developer, sugere-se a ferramenta SCRUM. Alm de empregar um desenvolvimento gil, com a resoluo rpida de problemas e ciclos curtos s atividades, ela propicia o gerenciamento de projetos, conforme pode ser constatado na figura 19. Todavia, com a formao de uma equipe enxuta e multidisciplinar, preconiza-

Verificao ou alinhamento

Desenvolvimento

27

se a otimizao de recursos para assegurar melhores resultados. O SCRUM composto basicamente pelos elementos de product backlog, product owner, scrum master, developers, testers, customers, subject matter especialist, sprints, bugs e daily scrum, segundo Halla (2010).

Gerente

Cliente externo

Desenvolvedor

Especialista

Reunio diria, teste e correo de erro Incorporao ao produto final

De 3 a 30 dias de durao

Execuo dos sprints

Requerimento das funcionalidades

Reviso dos requerimentos

Definio dos sprints

Figura 19 Ferramenta SCRUM

Sucintamente, tem como vantagem e simplicidade a identificao e reviso das funcionalidades inevitveis do produto; apurao do tempo irremissvel a cada atividade imanente; monitorao, teste e validao das atividades; e identificao dos atrasos do desgnio.

3500 3000 Hora / Esforo 2500 2000 1500 1000 500 0 1 2 3 4 5 6 7 8 Dias 9 10 11 12 13 14 15

Figura 20 Grfico Burndown (esforo versus dia)

28

Consentneo com Halla (2010) e conforme o demonstrado na figura 20; a monitorao do incremento de cada sprint ou marco pode ser feita atravs de um grfico burndown, o qual mostra o trabalho efetuado versus o tempo transcorrido. Entretanto, para assegurar realmente o controle das tarefas e a fim de averiguar o andar do trabalho, o GP precisa organizar reunies dirias de curta durao ou daily scrum, com tempo estimado em 15 minutos. A daily scrum busca reconhecer a labuta realizada no dia antecessor e a ser desempenhada no dia vigente; os problemas decorridos; as ferramentas faltantes; e os empecilhos expostos.

Qualidade de processos Compreenso dos requisitos funcionais tanto do cliente quanto da empresa

Adoo de metodologia ao desenvolvimento e gerenciamento

Estrutura do sistema da qualidade Estabelecimento e delegao de responsabilidades Criao e documentao do sistema de qualidade Definio dos procedimentos das atividades corretivas

Tarefas do ciclo de vida do software Definio do escopo Elaborao das funcionalidades Projeo do layout Programao Implantao Manuteno

Atividades para suportar

Gesto da

configurao documentos qualidade

Controle de

Registros inerentes Parmetros de

mensurao prticas e convenes

Criao de regras, Escolha das Gesto de

ferramentas e tcnicas de operao aquisies integrao

Mdulos para Capacitao

Figura 21 Estrutura bsica da ISO 9000-3

Ainda dentro do contexto da garantia da qualidade de software, a Internation Organization for Standardization (ISO) criou a ISO 9000-3. Esta norma foi

29

incorporada pela ABNT (Associao Brasileira de Normas Tcnicas), recebendo o nome de NBR ISO 9000-3. E tem por objetivo o mesmo sistema da qualidade da ISO 9001. Contudo, destina-se exclusivamente s indstrias de software ou fbricas digitais, abrangendo as fases de projeto, desenvolvimento, fornecimento, instalao e manuteno. H tambm para o processo de desenvolvimento a ISO 12.207, a qual aborda os processos do ciclo de vida de software. Aps arrumar a casa e objetivando em tornar-se cada vez mais competitiva a nvel nacional e internacional, a companhia Software Developer poder aderi-las. Afinal o mercado est demasiadamente acirrado, onde apenas o melhor vencer e sobreviver. O prprio mercado nacional est bastante exigente, com a entrada dos concorrentes externos. Pois qualidade sinnimo de preo baixo e elevao de lucratividade, porque os venbulos sero mais bem aproveitados. Deste modo complica a vida das empresas desorganizadas. Sucintamente, a ISO 9000-3 incorpora todos os fundamentos j explanados, onde se pede o entendimento geral dos requisitos funcionais tanto da contratante quanto da contratada, adoo de metodologia ao desenvolvimento de software abarcando todas as fases e framework para o gerenciamento do empreendimento, de acordo com a figura 21. Finalmente, como este tipo de certificao ser protelada ao futuro, este trabalho limitar-se- ao j mencionado.

2.4. Como obter a certificao CMMI

Baseada numa primeira consultoria, a fabricante Software Developer se organizou implantando as boas prticas da ITIL (Information Technology Infrastructure Library). Embora a ITIL no seja uma metodologia, ela serviu de estrutura para a empresa corrigir seus solecismos, propiciando uma melhoria contnua e subsidiando a implantao da governana de TI para o alinhamento do setor s estratgias organizacionais. A perfilhao da ITIL levou em considerao a no obrigatoriedade de uma nova forma de agir e pensar, devido cultura e filosofia de trabalho j difundida ou propalada e aceita pelos colaboradores.

30

Portanto, boa parte dos problemas foi corrigida. Agora falta garantir a maturidade dos processos de desenvolvimento de software. E isto ser alcanado atravs do gerenciamento e da melhoria contnua da qualidade, com a implantao do framework CMMI (Capability Maturity Model Integration). Para Halla (2010), conforme a figura 22, o modelo CMMI representa a maturidade do desenvolvimento de software em cinco nveis: inicial, repetvel, definido, gerenciado e otimizado.

5 Otimizao Processo aperfeioado continuamente 4 Gerenciando Processo previsvel e controlado 3 Definido Processo consistente e padronizado 2 Repetvel Processo disciplinado 1 Inicial Processo imprevisvel e sem controle Figura 22 Nveis de maturidade CMMI
15

A fase inicial j foi superada, porque os processos no so mais improvisados e j podem ser seguidos. A priori o departamento de TI estava totalmente descontrolado. A classificao dos problemas era feita consonante com a viso de mundo peculiar de cada atendente e num bloco de papel, sem nenhum critrio aparente. Sendo desprezada, a causa raiz nunca era reconhecida e documentada. Porm, acatando os conselhos da consultoria anterior, foram criados procedimentos para os gerenciamentos de configurao, incidentes, problemas, mudana, liberao, nvel de servio, capacidade, disponibilidade, continuidade dos servios de TI e financeiro. Os quais ficam armazenados no aplicativo Lotus Notes
15

HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. So Paulo: [s.n.], 2010. 66 p. il.

31

da IBM (International Business Machines), com acesso liberado a todos os envolvidos a partir de terminais conectados ao servidor central. Contudo, a evoluo paulatina. Embora os procedimentos tenham sido divulgados e estejam sendo praticados, controlados e monitorados, h muito a ser acrisolado ainda.

Otimizado

Agir de maneira preventiva, sempre identificando os pontos crticos melhoria contnua

Gerenciado

Estipular metas quantitativas

Medir os processos e produtos para a gesto

Definido

Padronizar os processos utilizados e estabelecidos em toda a organizao

Assegurar o alinhamento dos processos tcnicos aos gerenciais

Aplicao obediente das polticas e procedimentos para o gerenciamento do desenvolvimento de software

Criar o planejamento com base em experincias de projetos anteriores

Repetvel

Garantir a utilizao de processos definidos, usados, propalados, documentados, mensurados e monitorados para a melhoria contnua

Abolir a improvisao e criar processos replicveis

Realizar estimativas baseadas em planejamentos

Garantir o cumprimento de prazos e custos

Inicial

Asseverar o compartilhamento dos procedimentos e conhecimentos, desvinculando-os das pessoas e associando-os aos projetos

Figura 23 Diagrama fundamental de como implantar o modelo CMMI

Conforme o cenrio supracitado, a companhia atingiu o segundo nvel do CMMI. A fim de ser certificada neste modelo, ela precisa estabelecer e estender a padronizao dos seus processos para a organizao toda, sempre alinhando os processos tcnicos aos gerenciais; estipular metas quantitativas e assegurar a

32

mensurao dos processos e produtos para a gesto; e melhorar continuamente os processos, sempre agindo de forma preventiva e identificando os pontos crticos, falhos e pechosos. Em conformidade com o assuntado na figura 23. Aps atender plenamente os requisitos de uma das fases do CMMI, a empresa pode ser avaliada e certificada oficialmente pelo Software Engineering Institute (SEI), mesmo no tendo galgado todos os nveis de amadurecimento. Entretanto, antes de ser avaliada, preciso compor uma equipe interna de acompanhamento e contratar uma empresa especializada a qual enviar um Lead Appraiser ou High Maturity Lead Appraiser para a avaliao oficial, que um profissional outorgado pelo SEI, de acordo com a ISD BRASIL (2010). Veja a figura 24.

Acrisolar o gerenciamento dos processos

Aprovado?

Obtm certificao pelo perodo de trs anos

Reportar os resultados apurados ao SEI

Definir o nvel de maturidade atual

Avaliar o cenrio com o mtodo SCAMPI Lead Appraiser Formar uma equipe interna de acompanhamento Contratar uma empresa autorizada pelo SEI

Figura 24 Procedimento para a obteno da certificao CMMI

O processo de certificao subdividido nas fases de planejamento, preparao, conduo e reporte. E faz uso do mtodo de avaliao SCAMPI (Standard CMMI Appraisal Method for Process Improvement) para compreender o atual cenrio dos processos da organizao. Depois da apurao do nvel de maturidade o Lead Appraiser faz a recomendao da certificao, reportando os resultados apurados ao SEI. Obtendo a aprovao da aludida instituio, a empresa passa a ser certificada por um perodo de trs anos. Vencendo o prazo, a companhia precisa ser reavaliada. Se comprovar a evoluo dos seus processos,

33

ela pode auferir um nvel superior. Antagonicamente a isto, ela continuar com o nvel vigente. Porm necessita atestar a sua manuteno, caso contrrio perder o reconhecimento oficial da maturidade dos seus processos. Finalmente, a Consulting limita-se a oferecer uma consultoria essencial para a arrumao da casa e ministra auditorias peridicas para o alinhamento indispensvel.

34

3. CONCLUSO

Conclui-se com este estudo e trabalho que o gerente de projetos precisa integrar os recursos eficientemente, para asseverar o sucesso de um projeto ou da prpria organizao; obedecendo as fases de concepo, definio, iniciao, execuo e fechamento. Sempre focado no objetivo central do desgnio e controlando e monitorando sistematicamente o planejamento, a programao e o desempenhar das atividades imanentes. Tambm efetuando os alinhamentos ou ajustes do realizado com as estimativas determinadas primordialmente. Pois a ausncia de planejamento pe em risco no apenas o produto ou servio, mas tambm a vida da companhia. O framework adotado para a gesto do empreendimento ser o grande responsvel pela garantia da qualidade pretendida e pelo amadurecimento dos processos. E, obrigatoriamente, precisa abarcar as etapas de anlise de impacto, planejamento e desenvolvimento. Sua excelncia depende de informao ltica e acurada. Portanto torna-se imprescindvel estipular metas quantitativas e assegurar a medio dos processos e produtos. Ademais s possvel gerir algo mensurvel. Inclusive, para a elevao do nvel de maturidade, os solecismos devem ser documentados, armazenados e disponibilizados aos funcionrios. Desta forma fica descartada a necessidade de repensar uma soluo e engendrar retrabalhos. Para a definio do grau dos riscos e estipulao dos planos de contingncia, os colaboradores devem ser ouvidos plena e impreterivelmente, contribuindo com as experincias profissionais ou conhecimentos empricos e tericos. Nem todo risco combatido, porque se ele for desprezvel aumentar o custo frivolamente. Enfim, embasada na consultoria anterior e com a adoo da ITIL implantao da Governana de TI, a empresa Software Developer alcanou o segundo nvel de maturidade do modelo CMMI. Finalmente, foi possvel vislumbrar ao longo da pesquisa que a aquisio da certificao oficial em CMMI far toda a diferena s fabricantes de software, tanto no mercado nacional quanto internacional, tornando-as bem mais competitivas e lucrativas.

35

REFERNCIAS BIBLIOGRFICAS

COSTA, Ivanir. Apostila de Qualidade de Software. UNIP. So Paulo: [s.n.], 2010. HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. UNIP. So Paulo: [s.n.], 2010. ISD BRASIL. Site de apresentao da empresa. So Paulo, 2010. Disponvel em: <http://www.isdbrasil.com.br>. Acesso em: 03/12/2010. KERZNER, Harold. Gesto de Projetos: as melhores prticas. Porto Alegre: Bookman, 2006. MAGALHES, Ivan Luizio; BRITO, Walfrido. Gerenciamento de servios de TI na prtica: uma abordagem com base na ITIL. So Paulo: Novatec Editora, 2007. MALAGUETA, Lrida. Apostila de Empreendedorismo. UNIP. So Paulo: [s.n.], 2010. WAGNER, Newton. Utilizando linha de base (baseline) no MS Project. [S.I.], 2010. Disponvel em: <http://www.newtonwagner.net>. Acesso em: 29/11/2010.