Qualidade do software

UNIVERSIDADE PAULISTA RAPHAEL TREVIZAM FERMINO DE OLIVEIRA

TECNOLOGIA DA INFORMAÇÃO:

Gestão de projetos para garantir a qualidade do produto, atingir a maturidade do processo de desenvolvimento e adquirir a certificação CMMI

SÃO PAULO

2010

RAPHAEL TREVIZAM FERMINO DE OLIVEIRA

TECNOLOGIA DA INFORMAÇÃO:

Gestão de projetos para garantir a qualidade do produto, atingir a maturidade do processo de desenvolvimento e adquirir a certificação CMMI

Trabalho de desenvolvimento e aplicação dos conhecimentos adquiridos através das disciplinas de Gerenciamento de Projetos de TI, Empreendedorismo e Qualidade de Software, embasado numa solicitação de consultoria de uma empresa fictícia denominada de Software Developer; apresentado à Universidade Paulista (UNIP) com a finalidade de Projeto Integrado Multidisciplinar (PIM VIII).

Orientadora: Profª. Adriane Colossetti

SÃO PAULO

2010

Oliveira, Raphael Trevizam Fermino de, 1983

Tecnologia da Informação: Gestão de projetos para garantir a qualidade do produto, atingir a maturidade do processo de desenvolvimento e adquirir a certificação CMMI / Raphael Trevizam Fermino de Oliveira. - 2010.

35 f. ; 29,7 cm

Orientadora: Adriane Colossetti.

Projeto Integrado Multidisciplinar VIII – Universidade Paulista, Gestão da Tecnologia da Informação, 2009.

1. Empreendedorismo. 2. Qualidade de Software. 3. Gerenciamento de Projetos de TI. I. Colossetti, Adriane. II. Universidade Paulista. Gestão da Tecnologia da Informação. III. Tecnologia da Informação.

RESUMO

Talvez por subestimarem a relevância do business plan ou plano de negócio, setenta por cento dos novos empreendedores vêem seus negócios desaparecerem todos os anos. Esta informação evidencia a importância da adoção de um modelo de gestão eficiente e eficaz para projetos, processos e qualidade. Contudo, mesmo abarcando estudos em demasia, muitos profissionais de TI têm dificuldade em aplicar na prática a teoria da gerência de desígnio aprendida. O gerente do empreendimento precisa saber integrar e alocar adequadamente os venábulos, a fim de asseverar a obtenção de êxito. Pois os técnicos especialistas apenas executam as tarefas operacionais. Como bússola para o alinhamento das fases às estimativas primordiais, preconiza-se a utilização de um trinômio sagrado incluindo orçamento, escopo e tempo. A qualidade do produto final deriva de uma análise de risco minuciosa a partir da definição acurada dos requisitos ao planejamento, desenvolvimento e testes. Para a estipulação dos riscos e seus impactos, o compartilhamento de conhecimento empírico e teórico ou experiência profissional é precípuo. Não 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 também é espectável. Nela acontece a visualização panorâmica do ciclo de vida completo do prospecto, desde a concepção até o encerramento. Nenhuma ideia pode ser descartada, porém precisam passar pela viabilização técnica e comercial, antes de se transformarem em projeto. O mercado oferece uma gama imensa de ferramentas voltadas ao planejamento e gestão de projetos. Porém a transformação da ideia em algo sólido e utilizável e comercializável sucede durante o processo de desenvolvimento. Assim sendo, esta é a etapa mais crítica de um desígnio. A consumação de um solecismo ameaçará todo o esforço incipiente e comprometerá a qualidade final. Podendo, inclusive, paralisar as operações do cliente e engendrar muitos prejuízos. Narrados concisamente alguns conceitos, este trabalho teve como objetivo a implantação de um modelo de Gestão de Projetos orientado para a aquisição da certificação oficial em CMMI, mediante solicitação da fabricante de sistemas fictícia Software Developer, situada em São Paulo - Capital, argumentando e explicitando as melhores soluções e frameworks. Embasado nas teorias introduzidas, ao final o leitor consegue compreender a magnitude da necessidade da madureza dos processos.

Palavras-chave: Análise de risco; planejamento e gestão de projetos; processo de desenvolvimento; certificação oficial em CMMI; modelo de gestão; ciclo de vida; qualidade

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 São 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

1. INTRODUÇÃO.......................................................................................................6

2. DESENVOLVIMENTO .........................................................................................8

2.1. Análise de Impacto .......................................................................................13

2.2. Planejamento de Projeto ..............................................................................17

2.2.1. Work Breakdown Structure (WBS)...................................................................................20

2.2.2. Gráfico Gantt ......................................................................................................................20

2.2.3. Project Evaluation and Review Technique......................................................................21

2.2.4. Microsoft Project................................................................................................................23

2.3. Desenvolvimento de Projeto .......................................................................25

2.4. Como obter a certificação CMMI .................................................................29

3. CONCLUSÃO ....................................................................................................34

REFERÊNCIAS BIBLIOGRÁFICAS .........................................................................35

1. INTRODUÇÃO

Em prosseguimento ao serviço de consultoria contratado anteriormente, a fabricante Software Developer – uma desenvolvedora de sistemas bancários para os segmentos de consórcio, financeiro e empréstimo; localizada na Capital de São 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 certificação oficial em CMMI (Capability Maturity Model Integration), tornando-se mais competitiva tanto no mercado nacional quanto internacional.

Boa parte dos solecismos detectados a princípio foi resolvida, com a implantação das melhores práticas reunidas na ITIL (Information Technology Infrastructure Library).

Procedimentos foram criados e difundidos entre todos os funcionários da organização; para os gerenciamentos de configuração, incidentes, problemas, mudanças, liberação, nível de serviço, capacidade, disponibilidade, continuidade dos serviços de TI (Tecnologia da Informação) e financeiro.

Portanto, fazendo uso da ITIL, a companhia já galgou o segundo nível do modelo CMMI de maturidade. Pois os processos não são mais improvisados e já podem ser replicados. Também as estimativas são baseadas em planejamentos ou vice-versa, os prazos são cumpridos e monitorados através de SLAs (Service Level Agreement) e as experiências são transformadas em documentos – os quais ficam armazenados em servidores e disponíveis para uma consulta do tipo cliente- servidor.

Embora os procedimentos estejam sendo praticados, controlados e monitorados; a evolução é paulatina e há muito a ser corrigido.

Mediante o supracitado, a Consulting, uma empresa também situada em São Paulo – Capital, foi recontratada para prestar nova consultoria. Desta vez voltada a auxiliar na identificação e correção das ineficiências impregnadas aos processos de análise de impacto, planejamento e desenvolvimento de projeto. Sempre objetivando a obtenção da certificação oficial da madureza de processos.

Obedecendo esta lógica, desenvolver um estudo para fundamentar e consolidar alguns conceitos intrínsecos das disciplinas de Empreendedorismo, Qualidade de Software e Gestão de Projetos de TI. Sempre demonstrando como

eles podem ser empregados para a correção das deficiências vividas pela área de TI, escolha do modelo de gestão dos projetos, definição do grau dos riscos, criação do plano de combate de eventualidades.

Finalmente, contando com a experiência dos integrantes de sua equipe, ensinar o caminho a ser trilhado para a conquista da certificação oficial em CMMI, de modo a assegurar a aprovação 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 não conseguem formular e formalizar o business plan ou plano de negócio. Talvez por subestimarem a sua relevância.

Desta forma, apostam na sorte e confiam em suas intuições, sempre desenvolvendo e abarcando o conhecimento empírico e, provavelmente,

desprezando as teorias consolidadas por cientistas ou pesquisadores renomados.

30%

Mortalidade no 1º ano de vida

Sobrevivência no 1º ano de vida

70%

Figura 1 – Índice de mortalidade e sobrevivência 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 deficiências e sem deter um método voltado a combater as contingências, devido à ausência de metodologias. A qual acaba trabalhando de maneira aleatória e sem rumo certo.

Esta conduta é uma armadilha, pois sua sobrevivência em um mercado com constantes mutações, onde novos concorrentes surgem numa velocidade extraordinária, depende de um excelente planejamento e de informação bem acurada que só pode ser conseguida com um bom gerenciamento de projetos e contínua análise e melhoria de processos. Inclusive, salientemente, a gestão de algo depende de medições. Os índices são essenciais às tomadas de decisões e para a

manutenção da ética empresarial.

1 MALAGUETA, Lérida. Apostila de Empreendedorismo. São Paulo: [s.n.], 2010. 28 p. il.

Antagonicamente ao exposto no parágrafo antecessor, elas correm um grande e sério risco de se desequilibrarem diante de uma turbulência, podendo apresentar morte súbita. Afinal, sem dado preciso e consistente para a geração de informação referencial, concreta e fundamental, fica impossível prever os próximos passos e calcular os riscos inerentes ao segmento de atuação. Ademais, empresários com esta peculiaridade de conduta fogem do perfil do empreendedor,

pois empreender é sinônimo de risco calculado.

GRUPO A

Empresas planejadas

GRUPO B

Empresas não planejadas

70%

30%

Linha do Risco de Fracassar (LRF)

50%

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 têm 70% de chance de continuarem ativas, enquanto as não planejadas têm 50% de risco de fracassarem. Embora o grupo B venceu a largada inicial, está operando de forma aleatória. 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) após a largada inicial

Portanto, para corrigir as ineficiências e lacunas (operacionais e administrativas) destas empresas, um modelo de gestão para projetos, processos, qualidade, entre outros precisa ser adotado impreterivelmente.

Através do gerenciamento, será possível compreender e administrar os recursos atuais, além de assegurar o correto planejamento às novas conquistas ou projeções.

Porém, antes de discutir o tema gestão de projetos e demais atrelados a ele e suas consequências (análise de impacto, planejamento, desenvolvimento ou certificações de reconhecimento de excelência num segmento), faz-se necessário explicitar o significado de projeto.

Todo produto ou serviço ou a própria fundação de uma companhia é fruto de um projeto. Consentâneo com o Dicionário Michaelis da Língua Portuguesa, projeto

(uma palavra oriunda do latim projectu) é um plano para a realização de um ato.2

Ainda, segundo Halla (2010) trata-se de um esforço temporário para criar um produto e/ou serviço.

Kerzner (2006) define projeto como um empreendimento com objetivo bem definido, que consome recursos e opera sob pressões de prazos, custos e qualidade. Outrossim denomina-os de atividades exclusivas em uma empresa.

Os projetos reúnem e vendem conhecimento. Não importa qual seja a estrutura formal de uma organização.3

Muitos profissionais de TI (Tecnologia da Informação) adquirem uma boa formação superior, fazem um ou vários MBA (Master of Business Administration) ou especializações diversas, outros auferem o nível de mestrado ou doutorado ou pós- doutorado, participam de seminários, contudo sempre deparam com uma incógnita: como aplicar na prática a teoria da gerência de projetos (ou similares) aprendida?

Afinal o modelo de gestão 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 críticos, como: fase de aceitação pela gerência executiva; fase de aceitação pelos gerentes de área; fase de crescimento; e fase de maturidade.

A fim de asseverar a obtenção de êxito, conforme demonstrado na figura 4, os gestores precisam aprender a: ouvir e abarcar as preconizações oriundas dos colaboradores ou funcionários; ter ciência de que alterações precisam ser realizadas; assegurar a participação do alto escalão na gerência dos projetos, sempre explicitando suas funções; garantir a elevação dos interesses da empresa acima dos pessoais; admitir responsabilidade; contribuir com o avanço 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 programação às estimativas originais, obedecendo ao trinômio sagrado (escopo, tempo, orçamento); e, finalmente, treinar seu efetivo.

Atualmente, a parte operacional ou de execução das tarefas destina-se aos técnicos especialistas. O GP fica com o papel de integrador de recurso, controlando

e monitorando o planejamento, a programação e o desempenhar de todas as

2 HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. São Paulo: [s.n.], 2010. 01 p. il.

3 Escrita de STEWART, Thomas A. (1997). Frase extraída do livro Gestão de Projetos, referenciado

no final deste trabalho.

atividades intrínsecas ao empreendimento, sempre focado nos objetivos e com o propósito de alcançar êxito.

Figura 3 – Triângulo do projeto4

Os três elementos do triângulo do projeto ou trinômio sagrado são imprescindíveis ao sucesso, porque todo projeto pretende gerar um resultado dentro de um tempo estipulado, com início e fim, e conforme os venábulos disponíveis. Afinal os projetos não podem ser arquitetados com evo e precisam ser compatíveis com os meios existentes e tangíveis.

Contudo, um projeto também corre o risco de fracassar, caso seu gerente: deixe de aceitar ideias alheias, inibindo o talento inventivo; menospreze a necessidade de mudança, devido ao comodismo ou abnegação de visão por auto- estima; confie o controle das atividades exclusivamente ao nível executivo, rejeitando ou isentando-se de suas responsabilidades; proíba o compartilhamento de informação; dificulte o progresso dos subordinados, por temer a perda do cargo; compreenda a padronização dos processos como ameaça e não benefício; despreze o planejamento por confiar demasiadamente no conhecimento e experiência de sua equipe; determine o estado do projeto mediante a programação; e deixe de rastrear o custo real do projeto, correndo o risco de ultrapassar o orçamento previamente proposto ou determinado.

Portanto explicita-se desde já que a satisfação dos clientes e o sucesso dos

projetos dependem de uma análise de risco minuciosa, planejamento,

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

desenvolvimento e de um bom framework ou metodologia para apoiar e asseverar a

maturidade dos processos.

Integrar o auto escalão

Proteger os interesses da empresa

Aceitar mudanças

Ter responsabilidade

Saber ouvir

Treinar o efetivo

Início

CICLO PARA A OBTENÇÃO DE SUCESSO EM UM PROJETO

Contribuir com o avanço da equipe

Adotar

frameworks

Alinhar a programação com as estimativas

Planejar sempre

Figura 4 – Diagrama de como obter sucesso em um projeto

Assim sendo e descritos alguns pontos próceros atinentes ao empreendedorismo, qualidade e precisão de um modelo de gestão padronizado, a empresa Consulting apresentará uma proposta bem fundamentada e argumentada à fabricante de sistemas Software Developer de como solucionar suas ineficiências.

Embora a aludida empresa tenha angariado a resolução parcial das suas imperfeições embasada na consultoria passada, ela continua precisando de apoio técnico especializado e profissional para aperfeiçoar seus controles e adquirir um nível de madureza satisfatório.

Para tanto, partindo desta premissa, os itens a seguir inculcarão modelos aos processos de análise de impacto, planejamento e desenvolvimento de projeto e como obter a certificação do paradigma de maturidade do processo de desenvolvimento.

2.1. Análise de impacto

É extremamente importante formular e realizar um estudo dos diversos cenários propícios a desastres ou insucessos, os quais podem prejudicar o funcionamento da organização (projetos, processos, entre outros), para a prevenção contra os impactos negativos e descomunais, com a criação de planos de contingência.

Magalhães e Brito (2007) preceituam para esta fase a identificação dos eventos que podem causar interrupção nos processos de negócios, a avaliação de risco para a definição dos impactos inerentes e a elaboração de um plano estratégico claro para salvaguardar a continuidade do negócio.

O processo de análise de impacto precisa ser minucioso, sempre avaliando as vantagens e desvantagens e levando em consideração o custo-benefício. Existem basicamente dois tipos de medições: quantitativas e qualitativas. Enquanto a medida qualitativa aponta os setores carentes de melhoria imediata, a mensuração quantitativa indica a grandeza do impacto para posterior estudo e resolução.

Tabela 1 – Exemplo de categorias de impacto5

Nível Definição

Alto Perda significativa dos principais ativos e recursos.

Perda de reputação, imagem e credibilidade.

Impossibilidade de continuar com as atividades de negócio.

Médio Perda dos principais ativos e recursos.

Perda da reputação, imagem e credibilidade.

Baixo Perda de alguns dos principais ativos e recursos.

Perda da reputação da imagem e credibilidade.

5 MAGALHÃES, Ivan Luizio; BRITO, Walfrido. Gerenciamento de serviços de TI na prática. São

Paulo: Novatec Editora, 2007. 421 p. il.

A fim de exemplificar um modelo de tabela utilizada para a análise do impacto decorrente de certos riscos, a figura 5 traz um formulário de análise de impacto

utilizado pela Agência de Gerenciamento de Riscos do governo americano.

Figura 5 – Formulário de análise de impacto6

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 consumação pode ameaçar o sucesso de um empreendimento, assim como transformar-se numa proficuidade.

Em uma de suas definições, risco é a probabilidade ou incerteza de algo ocorrer. Pode ser considerado desprezível (quando oferece pouco prejuízo) ou grave

(quando inclui muitas implicações). Daí a relevância em administrá-los.

Concatenação

Compartilhamento de conhecimento

Definição do grau dos riscos

Subordinados Gerente

Criação do plano de contingência

Figura 6 - Definição do grau dos riscos para a geração do plano de contingência

Dificilmente um projeto alcançará êxito, sem um eficiente e eficaz gerenciamento de risco. Todos os stakeholders7 ou interessados ou colaboradores convolutos em um projeto precisam ser ouvidos. A contribuição com o conhecimento

empírico e teórico ou experiência profissional desenvolvida ao longo da carreira é

6 MAGALHÃES, Ivan Luizio; BRITO, Walfrido. Gerenciamento de serviços de TI na prática. São

Paulo: Novatec Editora, 2007. 421 p. il.

7 Stakeholder é a parte interessada ou interveniente que afeta ou pode ser afetada por uma atividade.

precípuo para a definição do grau dos riscos, como pode ser visto nas figuras 6 e 7.

O tema proposto neste capítulo começa a ser estudado desde a fase de planejamento, onde também se encaixa o processo de análise de riscos. Há uma singular distinção entre as atividades de gerenciamento e análise de risco. Enquanto a primeira busca criar métodos para controlar os imprevistos (previsão da probabilidade de cenários problemáticos) dentro de uma faixa de variação tolerável, a segunda visa identificar e avaliar os fatores e impactos dos riscos a fim de mitigar suas ascendências no resultado final ou esperado.

A análise de um risco deriva da compreensão do objetivo do projeto. Desta forma, descobrir quais são os fatores de risco associados e que podem atrapalhar o seu desenrolar e critérios estipulados ao êxito. Detectados os fatores dos riscos imanentes; conjecturar o valor do impacto peculiar e individual. Assim fica mais fácil priorizar os pontos a serem corrigidos e desenhar o plano de tratamento às eventualidades. Com o método de contingências traçado, tem como avaliar se compensa combater um risco. Afinal, se o seu impacto for ínfimo ou desprezível, não vale a pena investir recursos para a sua contenção, porque aumentará o custo do

projeto frivolamente. Maiores detalhes podem ser observados na figura 7.

Fatores críticos de sucesso

Monitoração FR Executa contingências

Processo de controle de risco

Processo da gerência de risco

Análise de risco Controle de risco

Identifica objetivos do projeto

Identifica fatores de risco (FR)

Estima impacto do

FR

Define resposta ao

FR

Redefine plano de projeto

Figura 7 – Processo de gerenciamento de riscos8

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

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

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 execução da solução criada, programada.

Este assunto passa por um processo de acrisolamento e evolução, portanto, não existe uma receita pronta do caminho a ser trilhado. Todavia, alguns padrões 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 padrão ao gerenciamento de riscos, segundo Halla (2010).

Ainda dentro deste contexto, fazendo uso de dados históricos, algumas ferramentas de qualidade podem ajudar a elucidar os pontos críticos e colaborar com o gerenciamento. São elas: diagrama de Pareto, diagrama de causa e efeito ou diagrama de Ishikawa, lista de verificação, histograma, diagrama de dispersão, gráfico linear e gráfico de controle.

Objetivada em exemplificar como uma ferramenta de qualidade pode contribuir com a identificação de um risco e do panorama geral, a figura 8 traz uma lista de verificação classificada de tabela de frequência. Onde a maior frequência de

erro ocorreu do trigésimo ao trigésimo quinto dia.

Tempo (dias) f

10 a 15 II

15 a 20 III

20 a 25 IIIIIIIIIIII

25 a 30 IIIIIIIIIII

30 a 35 IIIIIIIIIIIIIIIIIIIIII

35 a 40 IIIIIIIIIIIIII

40 a 45 IIIIIII

45 a 50 III

Figura 8 – Exemplo de uma tabela de frequência9

Fonte: Ramos (2008)

Uma conclusão ou dedução possível é que aumentou a falta de atenção dos funcionários ou colaboradores após o pagamento. Talvez porque ficaram descontentes ou insatisfeitos com seus salários. Portanto, antes de criar o plano de combate de casualidade para sanar o problema, uma pesquisa é indicada para desvendar o motivo de tamanha incidência.

Finalmente, por abranger todos os aspectos intrínsecos, a avaliação de

9 COSTA, Ivanir. Apostila de Qualidade de Software. São Paulo: [s.n.], 2010. 21 p. il.

impacto é imprescindível 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 espectável, pois ela contempla todo o ciclo de vida do desígnio, sendo o comenos de estudar o contexto por completo, lobrigando os diversos cenários possíveis e fomentando a criação dos planos de combate aos solecismos.

Kerzner (2006) coloca o planejamento estratégico como a essência para a saúde das empresas. Em longo prazo ele pode ser a diferença entre o sucesso e o fracasso.

O mesmo autor, fazendo uma análise circunscrita, inclui o plano de carreira dos gerentes como fator decisivo para a obtenção de excelência ou mediocridade em gestão de projetos.

Nesta linha de raciocínio, os prospectos precisam ser compostos das fases de concepção, definição, iniciação, execução 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 projeto10

Assim sendo, tudo começa com o brainstorming ou criatividade ou súbito de ideia, onde um ator sugere a invenção de algo (produto, serviço, entre outros) para ser verificado e tornado comercializável.

A fim de calcular a viabilidade técnica do projeto, a direção da companhia

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

necessita averiguar o potencial mercadológico da proposta primordial.

Também carece desvelar quais benefícios podem ser auferidos versus o valor investido, além de checar se os venábulos disponíveis são suficientes para a execução do pretendido e estimar o custo total aproximado.

Após o consentimento ou aprovação da direção, obrigatoriamente, formular de maneira explícita e disponibilizar aos envolvidos um plano contendo as metas e o escopo a ser atingido. Sempre certificando a compreensão de todos a respeito da razão do empreendimento, dos detalhes dos resultados aguardados, das atividades a serem praticadas, das funções e responsabilidades particulares, do tempo ou cronograma estipulado e do orçamento destinado aos recursos.

Estando garantido o entendimento geral, dá-se o start ou início do desígnio, alocando os venábulos em suas respectivas posições.

O GP (gerente de projeto), por sua vez, começa a mapear as tarefas para alinhá-las às estimativas ou propósitos.

A figura 10 traz maiores detalhes do supracitado.

INÍCIO DO PROJETO

PLANEJAMENTO

VALIDAÇÃO TÉCNICA

Verificação do potencial mercadológico da ideia

Geração da estimativa dos custos totais

Estudo dos benefícios

versus o valor investido

Averiguação dos recursos necessários

Obtenção de aprovação da diretoria

Figura 10 – Diagrama da viabilidade técnica e de comercialização da ideia até o início do projeto

Durante a execução, fazer um policiamento das atividades, com o intuito de verificar suas consonâncias em relação ao previamente planejado. Como solecismos podem suceder (cenários problemáticos percebidos na fase de planejamento para o

desenvolvimento do plano de contenção de eventualidades), após a correção das falhas consumadas toda a equipe deve tomar conhecimento. Deste modo assegura- se o emprego de revisões impreteríveis, consentâneo com a figura 11.

Finalmente, havendo a aprovação do cliente final, o projeto é encerrado.

Como nota especial e sobressalente, todos os erros sobrevindos precisam ser documentados para posterior consulta. Afinal, uma alteração possibilita a engendração de outra – a qual pode passar por despercebida, mesmo com todos os

testes efetuados ao longo do desenvolvimento.

Planejamento

Desenvolvimento

Teste

Solecismo N

Aprovado? S

S

N Aceitação

S

Encerramento

Base de dados dos solecismos consumados e resolvidos

Figura 11 – Diagrama da documentação dos problemas

O mercado disponibiliza algumas ferramentas bastante interessantes para a gestão de projetos, dentre elas destacam-se: Work Breakdown Structure (WBS), Gráfico Gantt, Critical Path Method (CPM), Project Evaluation and Review Technique (PERT) e Microsoft Project.

Com elas fica mais fácil vislumbrar o contexto ou o cenário total ou conjunto ou sequência de tarefas.

2.2.1. Work Breakdown Structure (WBS)

Sendo fácil de utilizar, a WBS é orientada ao planejamento e controle de projeto, possibilitando a estimativa e administração dos custos e contribuindo com a definição, organização e classificação do escopo proposto pelo cliente – através do ajuntamento das tarefas, onde se cria uma lista estruturada ou sumarizada e com numeração encadeada das atividades e suas dependentes, como o apresentado na tabela 2.

Tabela 2 – Exemplo de WBS11

WBS Atividade

5151.1 Fase piloto

5151.1.1 obter software

5151.1.2 instalar software

5151.1.3 configurar software

5151.1.4 criar pacote para instalação silenciosa

5151.1.5 Instalar pacote em uma estação de fase

5151.1.6 Efetuar testes de software

5151.1.6.1 Testar interface/enviar arquivo

5151.2 Fase implantação

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, não gere a sobreposição de escopo entre elementos e trate o resultado planejado como uma tarefa.

2.2.2. Gráfico Gantt

Já o gráfico Gantt12 ou gráfico de Gantt ilustra o cronograma através de barras horizontais e permite a sobreposição de tarefas, afinal algumas atividades podem

11 HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. São Paulo: [s.n.], 2010. 20 p. il.

12 Criado por Henry Gantt entre 1910 e 1915.

acontecer concomitantemente, como é o caso do departamento de compras e engenharia de software, pois os programas podem ser desenvolvidos simultaneamente com a fase de aquisição de bens ou serviços.

Figura 12 – Modelo de gráfico Gantt13

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 método PERT especifica as atividades interdependentes, objetivado em elucidar a ordem impreterível de desenvolvimento. Também tem a finalidade de identificar o tempo mínimo requerido ao término do projeto. Veja maiores detalhes

na figura 13.

=  6 

Figura 13 – Exemplo de tabela PERT14

13 Fonte: <http://www.newtonwagner.net>

14 HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. São Paulo: [s.n.], 2010. 22 p. il.

Com o método PERT fica fácil reconhecer as atividades e suas dependentes ou predecessores.

Conforme o exemplificado na figura 13, as atividades C e D necessitam da conclusão da atividade A para serem instauradas. E assim sucessivamente.

Outra vantagem do aludido método é que ele empadroa três tipos de tempos estimados para cada uma das atividades. Portanto, uma média pode ser calculada, a fim de encontrar o tempo aproximado entre o início e o fim do projeto.

Depois do planejamento formalizado com uma das ferramentas citadas anteriormente, é possível desenhar os caminhos a serem percorridos ou trilhados, a fim de excogitar o caminho crítico (maior caminho ou aquele que pode comprometer o cronograma caso sofra alguma alteração 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.

Início

30

C

5h

10 D

5h

A

4h

F 40

4,17h

50

G

2h

H

6,67h

I

Fim

60

B

4h E

8,17h

20

4,50h

Figura 14 – Exemplo de gráfico PERT para calcular o caminho crítico

Com o gráfico acima é possível calcular o tempo mínimo necessário para cada um dos caminhos, de acordo com a tabela 3.

Tabela 3 – Tempo dos caminhos do projeto

Caminho Tempo Total

A-C-F-G 4 + 5 + 4,17 + 2 15,17h

A-D-H 4 + 5 + 6,67 15,67h

B-E-I 4 + 8,17 + 4,50 16,67h

Ou seja, o caminho crítico do grafo acima é B-E-I, com quase dezessete

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

2.2.4. Microsoft Project

O programa proprietário Microsoft Project é designado ao gerenciamento de projetos, e engloba as demais ferramentas citadas. Halla (2010) aponta algumas de suas funcionalidades, como: duração de tarefas (datas, calendários); gráfico de Gantt; modelo probabilístico; diagrama de rede; custos (fixos e não fixos ou outros);

relatórios; etc.

Figura 15 – Tela principal do Microsoft Project

Enfim preconiza-se a adoção 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 solução hermética, é ergonômico e favorece a

administração desde a concepção da ideia até a consumação e finalização do desígnio.

Concisamente, por suportar e incluir os dados básicos requeridos às mensurações indispensáveis aos processos de governança e por engendrar relatórios de equiparação, ele ajuda os gestores de projeto a manterem o alinhamento do executado com as estimativas primordiais e de interesse da organização e do cliente, positivando uma ufania global e garantindo um resultado

auspicioso, consonante com a figura 16.

Execução Alinhamento

Estimativa de tempo e custos; definição do escopo; entre outros.

Fase de planejamento

Relatórios

Definição 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 através dos relatórios sumariados e dependendo da magnitude da anomalia, o plano de contingência pode ser aplicado para a normalização e realinhamento do foco.

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 transformação da ideia principal em algo sólido e utilizável ou comercializável.

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 confecção do sistema ou módulo. Provavelmente os testes são insuficientes ou nem estão 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 desígnio precisa compreender as fases de estipulação dos requisitos, planejamento e construção de um arquétipo. Para executar vários testes em busca de erros, após a conclusão do protótipo. Solecismos vão aparecer

sempre, caso contrário os experimentos são ineficientes. Veja a figura 17.

Treinamento

Satisfação

N

S

Qualidade

Instalação

Implantação

Produção

Testes

Definição dos requisitos

Planejamento

Construção de um protótipo

Figura 17 – Modelo de gestão satisfatória para a fase de desenvolvimento

De acordo com a figura 17, o produto só pode ser enviado para produção depois da etapa de testes. Senão 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ó não procuraram a concorrência visto que o software é exclusivo, em virtude da patente auferida.

Em continuação da produção vem o estágio de instalação e capacitação do usuário final.

Dentre os diversos frameworks disponíveis ao desenvolvimento de software, interativo e ágil são dois modelos bastante chamativos e atraentes.

Com o tipo interativo verifica-se constantemente o progresso das atividades executadas, garantindo desta forma o alinhamento contínuo 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

alteração inesperada. Observe o delineado na figura 18.

Validação Encerramento

Desenvolvimento

Definição dos requisitos

Planejamento

Verificação ou alinhamento

Figura 18 – Modelo de desenvolvimento interativo

Porém, ao estágio de desenvolvimento de software da fabricante Software Developer, sugere-se a ferramenta SCRUM. Além de empregar um desenvolvimento ágil, com a resolução rápida de problemas e ciclos curtos às atividades, ela propicia o gerenciamento de projetos, conforme pode ser constatado na figura 19.

Todavia, com a formação de uma equipe enxuta e multidisciplinar, preconiza-

se a otimização 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

Incorporação ao produto final

Reunião diária, teste e correção de erro

De 3 a 30 dias de duração

Execução dos

sprints

Requerimento das funcionalidades

Revisão dos requerimentos

Definição dos sprints

Figura 19 – Ferramenta SCRUM

Sucintamente, tem como vantagem e simplicidade a identificação e revisão das funcionalidades inevitáveis do produto; apuração do tempo irremissível a cada atividade imanente; monitoração, teste e validação das atividades; e identificação

dos atrasos do desígnio.

3500

3000

2500

2000

1500

1000

500

0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Dias

Figura 20 – Gráfico Burndown (esforço versus dia)

Consentâneo com Halla (2010) e conforme o demonstrado na figura 20; a monitoração do incremento de cada sprint ou marco pode ser feita através de um gráfico 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 reuniões diárias de curta duração 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

• Compreensão dos requisitos funcionais tanto do cliente quanto da empresa

• Adoção de metodologia ao desenvolvimento e gerenciamento

Estrutura do sistema da qualidade

Tarefas do ciclo de vida do software

Atividades para suportar

documentação do

• Criação de regras, práticas e convenções

• Escolha das ferramentas e técnicas de operação

• Gestão de aquisições

• Módulos para integração

• Capacitação

Figura 21 – Estrutura básica 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

incorporada pela ABNT (Associação Brasileira de Normas Técnicas), 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 indústrias de software ou fábricas digitais, abrangendo as fases de projeto, desenvolvimento, fornecimento, instalação e manutenção. Há também para o processo de desenvolvimento a ISO 12.207, a qual aborda os processos do ciclo de vida de software.

Após arrumar a casa e objetivando em tornar-se cada vez mais competitiva a nível nacional e internacional, a companhia Software Developer poderá aderi-las. Afinal o mercado está demasiadamente acirrado, onde apenas o melhor vencerá e sobreviverá. O próprio mercado nacional está bastante exigente, com a entrada dos concorrentes externos. Pois qualidade é sinônimo de preço baixo e elevação de lucratividade, porque os venábulos serão 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, adoção 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 certificação será protelada ao futuro, este trabalho limitar-se-á ao já mencionado.

2.4. Como obter a certificação CMMI

Baseada numa primeira consultoria, a fabricante Software Developer se organizou implantando as boas práticas da ITIL (Information Technology Infrastructure Library). Embora a ITIL não seja uma metodologia, ela serviu de estrutura para a empresa corrigir seus solecismos, propiciando uma melhoria contínua e subsidiando a implantação da governança de TI para o alinhamento do setor às estratégias organizacionais.

A perfilhação da ITIL levou em consideração a não obrigatoriedade de uma nova forma de agir e pensar, devido à cultura e filosofia de trabalho já difundida ou propalada e aceita pelos colaboradores.

Portanto, boa parte dos problemas foi corrigida. Agora falta garantir a maturidade dos processos de desenvolvimento de software. E isto será alcançado através do gerenciamento e da melhoria contínua da qualidade, com a implantação 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 níveis: inicial, repetível,

definido, gerenciado e otimizado.

5 Otimização

Processo aperfeiçoado continuamente

4 Gerenciando

Processo previsível e controlado

3 Definido

Processo consistente e padronizado

2 Repetível

Processo disciplinado

1 Inicial

Processo imprevisível e sem controle

Figura 22 – Níveis de maturidade CMMI15

A fase inicial já foi superada, porque os processos não são mais improvisados e já podem ser seguidos. A priori o departamento de TI estava totalmente descontrolado. A classificação dos problemas era feita consonante com a visão de mundo peculiar de cada atendente e num bloco de papel, sem nenhum critério aparente. Sendo desprezada, a causa raiz nunca era reconhecida e documentada.

Porém, acatando os conselhos da consultoria anterior, foram criados procedimentos para os gerenciamentos de configuração, incidentes, problemas, mudança, liberação, nível de serviço, capacidade, disponibilidade, continuidade dos

serviços de TI e financeiro. Os quais ficam armazenados no aplicativo Lotus Notes

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

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

Agir de maneira preventiva, sempre identificando

Otimi zado os pontos críticos à melhoria contínua

Estipular metas Medir os processos e

Geren ciado quantitativas produtos para a gestão

Padronizar os processos Assegurar o alinhamento utilizados e estabelecidos dos processos técnicos

Defi nido em toda a organização aos gerenciais

Aplicação obediente das políticas e Criar o planejamento com procedimentos para o gerenciamento do base em experiências de

desenvolvimento de software projetos anteriores

Garantir a utilização de processos definidos, usados, propalados, documentados, mensurados

Rep etível e monitorados para a melhoria contínua

Abolir a improvisação e Realizar estimativas Garantir o criar processos baseadas em cumprimento de

replicáveis planejamentos prazos e custos

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

Ini cial associando-os aos projetos

Figura 23 – Diagrama fundamental de como implantar o modelo CMMI

Conforme o cenário supracitado, a companhia atingiu o segundo nível do CMMI. A fim de ser certificada neste modelo, ela precisa estabelecer e estender a padronização dos seus processos para a organização toda, sempre alinhando os processos técnicos aos gerenciais; estipular metas quantitativas e assegurar a

mensuração dos processos e produtos para a gestão; e melhorar continuamente os processos, sempre agindo de forma preventiva e identificando os pontos críticos, falhos e pechosos. Em conformidade com o assuntado na figura 23.

Após atender plenamente os requisitos de uma das fases do CMMI, a empresa pode ser avaliada e certificada oficialmente pelo Software Engineering Institute (SEI), mesmo não tendo galgado todos os níveis 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 avaliação oficial, que é um profissional outorgado pelo SEI, de acordo com a ISD BRASIL (2010). Veja a figura

24.

Acrisolar o gerenciamento N

dos processos

Aprovado?

S Obtém certificação pelo período de três anos

Reportar os resultados apurados ao SEI

Definir o nível de maturidade atual

Formar uma equipe interna de acompanhamento

Avaliar o cenário com o método SCAMPI

Contratar uma empresa autorizada pelo SEI

Lead

Appraiser

Figura 24 – Procedimento para a obtenção da certificação CMMI

O processo de certificação é subdividido nas fases de planejamento, preparação, condução e reporte. E faz uso do método de avaliação SCAMPI (Standard CMMI® Appraisal Method for Process Improvement) para compreender o atual cenário dos processos da organização. Depois da apuração do nível de maturidade o Lead Appraiser faz a recomendação da certificação, reportando os resultados apurados ao SEI. Obtendo a aprovação da aludida instituição, a empresa passa a ser certificada por um período de três anos. Vencendo o prazo, a companhia precisa ser reavaliada. Se comprovar a evolução dos seus processos,

ela pode auferir um nível superior. Antagonicamente a isto, ela continuará com o nível vigente. Porém necessita atestar a sua manutenção, caso contrário perderá o reconhecimento oficial da maturidade dos seus processos.

Finalmente, a Consulting limita-se a oferecer uma consultoria essencial para a arrumação da casa e ministra auditorias periódicas para o alinhamento indispensável.

3. CONCLUSÃO

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 própria organização; obedecendo as fases de concepção, definição, iniciação, execução e fechamento. Sempre focado no objetivo central do desígnio e controlando e monitorando sistematicamente o planejamento, a programação e o desempenhar das atividades imanentes. Também efetuando os alinhamentos ou ajustes do realizado com as estimativas determinadas primordialmente. Pois a ausência de planejamento põe em risco não apenas o produto ou serviço, mas também a vida da companhia.

O framework adotado para a gestão do empreendimento será o grande responsável pela garantia da qualidade pretendida e pelo amadurecimento dos processos. E, obrigatoriamente, precisa abarcar as etapas de análise de impacto, planejamento e desenvolvimento. Sua excelência depende de informação lítica e acurada. Portanto torna-se imprescindível estipular metas quantitativas e assegurar a medição dos processos e produtos. Ademais só é possível gerir algo mensurável. Inclusive, para a elevação do nível de maturidade, os solecismos devem ser documentados, armazenados e disponibilizados aos funcionários. Desta forma fica descartada a necessidade de repensar uma solução e engendrar retrabalhos.

Para a definição do grau dos riscos e estipulação dos planos de contingência, os colaboradores devem ser ouvidos plena e impreterivelmente, contribuindo com as experiências profissionais ou conhecimentos empíricos e teóricos. Nem todo risco é combatido, porque se ele for desprezível aumentará o custo frivolamente.

Enfim, embasada na consultoria anterior e com a adoção da ITIL à implantação da Governança de TI, a empresa Software Developer alcançou o segundo nível de maturidade do modelo CMMI.

Finalmente, foi possível vislumbrar ao longo da pesquisa que a aquisição da certificação oficial em CMMI fará toda a diferença às fabricantes de software, tanto no mercado nacional quanto internacional, tornando-as bem mais competitivas e lucrativas.

REFERÊNCIAS BIBLIOGRÁFICAS

COSTA, Ivanir. Apostila de Qualidade de Software. UNIP. São Paulo: [s.n.], 2010. HALLA, Victor Barros. Apostila de Gerenciamento de Projetos de TI. UNIP. São

Paulo: [s.n.], 2010.

ISD BRASIL. Site de apresentação da empresa. São Paulo, 2010. Disponível em:

<http://www.isdbrasil.com.br>. Acesso em: 03/12/2010.

KERZNER, Harold. Gestão de Projetos: as melhores práticas. Porto Alegre: Bookman, 2006.

MAGALHÃES, Ivan Luizio; BRITO, Walfrido. Gerenciamento de serviços de TI na prática: uma abordagem com base na ITIL. São Paulo: Novatec Editora, 2007.

MALAGUETA, Lérida. Apostila de Empreendedorismo. UNIP. São Paulo: [s.n.],

2010.

WAGNER, Newton. Utilizando linha de base (baseline) no MS Project. [S.I.],

2010. Disponível em: <http://www.newtonwagner.net>. Acesso em: 29/11/2010.