Framework de controle gerencial para projetos de desenvolvimento de software

Framework de controle gerencial para projetos de desenvolvimento de software RESUMO Este artigo apresenta um framework gerencial para planejamento, acompanhamento e controle de projetos de desenvolvimento de software para organizações que trabalham fornecendo soluções de tecnologia baseadas em software sob encomenda e administram as atividades do ciclo de desenvolvimento sob a forma de projetos. Palavras-chave: gerência de projeto, melhoria de processo, qualidade de software. ABSTRACT This article presents a management framework to plan, follow and control software development projects to organizations that work providing technological solutions based on software on demand and administrate activities of the development cycle established on projects. Keywords: project management, process improvement and software quality. Tipo de Artigo: Trabalho Técnico

1. INTRODUÇÃO Os principais problemas, que afetam os projetos de desenvolvimento de software, são em sua maioria problemas de ordem gerencial e não técnicos. Esta afirmação vem de encontro ao mito de que os problemas, que causam falhas e atrasos no processo de produção de software, são de natureza técnica [6]. Na tentativa de estabelecer uma estratégia de controle de processos gerenciais, este artigo propõe a criação de um conjunto de documentos baseados nos processos consagrados pelo PMBOK-Project Management Body of Knowledge, para formar um planejamento eficaz de projetos de software. A figura 1 exibe a representação gráfica da camada gerencial proposta, que geram esses documentos e se superpõe às fases do ciclo de vida de desenvolvimento de software. RECURSOS HUMANOS AQUISIÇÕES _ QUALIDADE RISCOS COMUNICAÇÕES ESCOPO PRAZO CUSTO INTEGRAÇÃO PROCESSOS GERENCIAIS ANÁLISE PROJETO CODIFICAÇÃO TESTES IMPLANTA- ÇÃO PROCESSOS FUNDAMENTAIS Figura 1 Estrutura de processos gerenciais de apoio ao Ciclo de Vida de desenvolvimento de software Este trabalho está organizado da seguinte forma: a sessão 2 apresenta a motivação para realização deste trabalho. A sessão 3 apresenta a descrição do ambiente adequado para aplicação do framework A sessão 4 apresenta os processos gerenciais baseados no PMBOK- Project Management Body of Knowledge. A sessão 5 descreve os documentos construídos como saída da execução dos processos. A sessão 6 apresenta as principais conclusões do trabalho. 2. MOTIVAÇÃO Existem duas grandes motivações por parte das organizações para o investimento de tempo e recursos na melhoria da gerência de projetos de desenvolvimento de software. A

primeira é a melhoria nas estimativas de custo e prazo dos seus projetos na fase inicial de levantamento de requisitos. [1] Atualmente, as organizações têm que estimar o prazo e o custo bem no início do projeto, antes de fazer uma análise detalhada do escopo do sistema a ser desenvolvido, o que acaba causando uma grande margem de erro entre o que foi planejado e os custos e prazos reais. A segunda motivação é a necessidade de fazer adequado acompanhamento dos prazos de entrega dos produtos de software, quando estimados corretamente. A melhoria da qualidade do gerenciamento de projetos de desenvolvimento e manutenção de software e produtos associados é a principal razão do desenvolvimento desse framework. A partir do estudo das gerências do PMBOK desenha-se uma estratégia de acompanhamento e controle gerencial das atividades do projeto, pelo uso de documentos padronizados em processos de trabalho bem definidos. Segundo pesquisa realizada pela KPMG Peat Marwick [7], 42% das causas de falhas em projetos são devidas à administração inexistente ou inadequada. O uso de processos de gerenciamento para a produção de documentos de controle e avaliação do projeto irá contribuir para a redução deste índice. A abordagem do trabalho sobre a qualidade dos processos gerenciais é feita a partir dos documentos gerenciais produzidos durante o ciclo de vida. Esses documentos possibilitam o acompanhamento da evolução dos trabalhos realizados pela equipe do projeto. A existência desses documentos e a qualidade e quantidade de suas informações indicará o nível de maturidade e capacidade da gerência do projeto. Os níveis de maturidade de processo da gerência de projetos, exibidos na tabela 1 são definidos de acordo com a classificação de Ibbs e Kwak [2][3], com padronização semelhante a do CMM (Capability Maturity Model). NÍVEL DE MATURIDADE Tabela 1 - Níveis de Maturidade e Capacidade da Gerência de Projetos DESCRIÇÃO DOS PRINCIPAIS ELEMENTOS DE CARACTERIZAÇÃO DO NÍVEL DE MATURIDADE 5 - MANTIDO Os processos de gerenciamento de projetos são continuamente melhorados. Dados sobre gerenciamento de projetos são coletados de forma automática para identificar os processos que apresentam problemas. 4 INTEGRADO Os processos de gerenciamento de projetos são formais, bem definidos e as informações de saída são totalmente documentadas. Medidas quantitativas para avaliação dos processos são colhidas e armazenadas em bases de dados, visando antecipar e prevenir baixa produtividade ou qualidade. 3 GERENCIADO Os processos de gerenciamento de projetos apresentam características de planejamento e controle sistematizados. Os problemas do projeto são informalmente documentados para fins de controle. Dados são coletados para manter uma base de informações para controle e planejamento de projetos. 2 PLANEJADO Processos informais e incompletos são utilizados para gerenciar o projeto. Problemas gerenciais são identificados, mas não são documentados ou corrigidos. As ferramentas e técnicas de gerenciamento de projetos são utilizadas de forma incompleta. A equipe consegue realizar com sucesso processos similares que se repetem nos projetos, mas enfrentam problemas ao gerenciar projetos que apresentam características diferentes. 1 INICIAL Não há planos formais para a execução do projeto. As atividades de projeto são mal definidas e as estimativas de custo são superficiais. Análise e coleta de dados não são conduzidas de uma maneira sistemática. Em resumo, os processos são imprevisíveis.

Na próxima seção serão detalhadas as informações sobre o ambiente organizacional que suporta o framework desenvolvido para a aplicação deste trabalho. 3. DESCRIÇÃO DO AMBIENTE O framework proposto neste trabalho foi desenvolvido para utilização em organizações que funcionam como sistemas abertos, seguindo o paradigma da teoria de sistemas que propõe que as organizações sejam estruturadas dessa forma, mantendo relações de troca de informação e insumos com o seu ambiente. [8] Empresas que prestam serviços de desenvolvimento de software enquadram-se nesse conjunto, pois devem considerar as entradas e saídas envolvidas no processo de construção do software. Os processos de gerenciamento de projeto propostos neste artigo consideram as necessidades de comunicação das partes envolvidas no projeto. A gerência da comunicação tem processos específicos para o planejamento, coleta, arquivamento e distribuição das informações para as pessoas e organizações participantes do projeto. Durante todo o tempo de desenvolvimento do projeto devem existir reuniões periódicas de acompanhamento do progresso do trabalho realizado. Os indicadores de desempenho de custo, prazo e escopo são coletados para indicar se ações corretivas devem ser tomadas nessas reuniões de acompanhamento, que podem envolver a equipe do projeto, o cliente e outros grupos interessados no projeto. Na próxima seção serão detalhadas informações sobre os processos gerenciais utilizados para o planejamento e controle do projeto. 4. PROCESSOS GERENCIAIS Para que se possa gerenciar de forma adequada projetos de software é necessário que se conheça suficientemente seu processo de desenvolvimento em suas mais variadas facetas. Um processo de software pode ser definido como um conjunto de atividades, métodos, práticas e transformações que desenvolvedores utilizam para construir e manter software e produtos associados, tais como planos do projeto, documentação, código fonte e manuais. O desenvolvimento de software é composto pelos processos de produção e gerenciamento, que se influenciam reciprocamente durante todas as fases do ciclo de vida do projeto. Os processos de gerenciamento responsabilizam-se basicamente pelo controle do escopo, prazo, custo e qualidade dos serviços realizados. A norma ISO 12207 classifica o processo de gerenciamento como sendo do tipo de processo organizacional que deve ser utilizado para efetivação dos processos de desenvolvimento e manutenção de software. [4] Os processos de produção são responsáveis pela construção dos produtos de software, desde a fase de análise até a fase de implantação e treinamento dos usuários do sistema. A atribuição de objetivos para a melhoria do processo de gerenciamento de software requer que se compreendam as diferenças entre organizações maduras e imaturas em relação ao gerenciamento de projetos de software. Em uma organização imatura, os produtos de software são geralmente produzidos por especialistas e seu gerenciamento é feito durante o andamento do projeto. Mesmo que uma etapa do processo seja especificada anteriormente, esta não é rigorosamente seguida. Nessas organizações, o gerenciamento está focado na solução de problemas imediatos (conhecido

como apagar incêndios ). Cronogramas e orçamentos são rotineiramente excedidos porque não se baseiam em estimativas realistas. Quando fortes restrições de tempo e recursos são impostas, a funcionalidade e a qualidade do produto são freqüentemente comprometidas, para atender ao cronograma imposto. Não há bases objetivas para o julgamento da qualidade dos produtos gerados ou para a resolução de problemas do processo ou do produto de software. É difícil medir a qualidade de tais produtos, pois as atividades que visam a sua melhoria são muitas vezes eliminadas, para que o projeto não ultrapasse o cronograma previsto. Em uma organização madura, a função do gerente é monitorar a qualidade do produto e do processo de desenvolvimento de software e a satisfação do cliente. Há objetivos definidos, bases quantitativas para julgamento da qualidade dos produtos de software e análise de problemas do processo. Orçamentos e cronogramas são baseados em resultados históricos de atuação; as expectativas de custo, cronograma, funcionalidade e qualidade são usualmente atingidas. Com o objetivo de criar uma metodologia prática para o gerenciamento de projetos para organizações desenvolvedoras de software, este artigo propõe a utilização dos processos do PMBOK (Project Management Body of Knowledge) para organizar as áreas de conhecimento e de processos gerenciais. [5] Esta metodologia decompõe um projeto em processos, que são atividades com entradas, ferramentas, técnicas e saídas bem definidas, que são realizadas para se obter um resultado específico. Os processos são classificados em processos essenciais e processos facilitadores. Os processos essenciais mantêm uma clara dependência entre si, devendo ser executados em uma determinada ordem na maioria dos projetos. Os processos essenciais do PMBOK que devem ser utilizados para a elaboração do plano do projeto são os seguintes: iniciação, planejamento do escopo, detalhamento do escopo, definição das atividades, planejamento dos recursos, seqüenciamento das atividades, estimativa de duração das atividades, estimativa de custos, planejamento da gerência do risco, desenvolvimento do cronograma, orçamentação de custos e desenvolvimento do plano do projeto. Os processos facilitadores são dependentes da natureza do projeto, mantendo entre si uma dependência fraca, ou seja, as entradas desses processos não são saídas de outros processos, por isso, há uma flexibilidade na escolha do momento de sua utilização. Apesar dessa característica flexível, não são opcionais. [7] Os processos facilitadores de planejamento são os seguintes: planejamento da qualidade, planejamento organizacional, montagem da equipe, planejamento das aquisições, preparação das aquisições, planejamento das comunicações, identificação dos riscos, análise qualitativa dos riscos, análise qualitativa dos riscos e planejamento das respostas a riscos. As saídas dos processos são documentos gerenciais que permitem registrar e acompanhar o desenvolvimento das atividades em relação a parâmetros de tempo, custo, qualidade e risco. Os processos do PMBOK estão ligados entre si pelo resultado que produzem. Os documentos de saída de um processo são utilizados como entradas no processo seguinte. Por fim, são estabelecidos em cada processo tarefas de início, planejamento, execução, controle e finalização, com o objetivo de monitoração do processo de melhoria da qualidade, passo a passo. Na seção seguinte, serão descritos os documentos gerenciais produzidos que compõem o framework gerencial para projetos de software.

5. ALINHAMENTO DOS DOCUMENTOS AOS PROCESSOS GERENCIAIS Para aplicação dos processos gerenciais propostos pela metodologia PMBOK dentro da organização, é necessário definir uma seqüência de ações e elaborar um conjunto de documentos para o acompanhamento dessas ações. Essa seqüência de ações é composta por 04 (quatro) principais etapas gerenciais: elaboração do plano do projeto, complemento ao plano do projeto, execução do projeto e finalização do projeto. 5.1 Elaboração do plano do projeto A primeira etapa de desenvolvimento do plano do projeto tem por objetivo produzir os subsídios necessários à elaboração de uma proposta comercial a ser apresentada ao cliente. Essa etapa se inicia através de uma série de reuniões com o cliente onde se coletam as informações para que sejam criados os documentos gerencias descritos a seguir: Iniciação do projeto Registra os dados cadastrais do cliente, informações sobre o projeto como objetivos funcionais, restrições e premissas e definição do gerente do projeto; Planejamento do escopo Relaciona as principais funções a serem desempenhadas pelo software, subprodutos esperados do projeto, objetivos em relação a prazo, custo e qualidade, características do ambiente; Modelo de Estrutura Analítica do Projeto (EAP) A estrutura analítica do projeto apresenta as fases, sub-fases e pacotes de trabalho que deverão ser executados durante o ciclo de vida do projeto. Cada projeto deve customizar a EAP de acordo com os produtos que deverão ser desenvolvidos; Lista de atividades padronizadas Cada pacote de trabalho da EAP é composto por um conjunto de atividades, que devem ser padronizadas de acordo com as competências técnicas e gerencias da equipe do projeto; Plano de gerência do risco Define a forma como o risco será gerenciado durante a execução do projeto, e as pessoas responsáveis pelas tarefas de planejamento, identificação, análise e monitoração dos riscos; Relatório de Identificação dos riscos Relaciona os riscos já identificados e seus gatilhos (eventos que sinalizam a ocorrência do risco); Análise qualitativa e quantitativa dos riscos Este documento registra a análise da probabilidade de ocorrência e do impacto do risco sobre custo, escopo, cronograma e qualidade. Planejamento de recursos Relaciona a estimativa para recursos humanos, software e hardware necessários à execução do projeto. Para a obtenção de maior precisão das estimativas de custos do projeto, devem estar relacionados os custos fixos a serem considerados; Cronograma gerencial e de execução Para acompanhamento dos prazos de execução das atividades do projeto devem ser utilizados dois cronogramas distintos contendo as atividades gerenciais e técnicas a serem realizadas. Esses cronogramas são uma representação temporal das atividades padronizadas, com informações sobre o sequenciamento das atividades, quantidade de recursos humanos previstos para

execução das atividades e com uma estimativa de prazo para cada uma dessas atividades. A seqüência de atividades desses cronogramas tem como base 02 (dois) modelos padronizados, já seqüenciados, que abrangem toda a lista de atividades; Orçamento Apresenta os valores orçados para custos fixos e variáveis de todas as fases da EAP. Durante a execução do projeto, são informados os valores reais para cada uma das fases; Plano de execução Nesse documento é feita a indicação de quais gerências do PMBOK serão realizadas durante o projeto e da metodologia de desenvolvimento de software a ser aplicada. 5.2 Complemento ao plano do projeto Após a aprovação do projeto pelo cliente, tem início a segunda etapa do projeto que tem por objetivo fazer ajustes e complementações aos documentos já criados, decorrentes da negociação do contrato com o cliente; e construir os documentos abaixo: Plano de resposta a riscos Descreve o tratamento a ser dado a cada um dos riscos identificados; Matriz de responsabilidades Relaciona todas as pessoas que irão participar do projeto em cada uma das fases e atividades, e suas respectivas responsabilidades; Organograma do projeto - Exibe graficamente a estrutura hierárquica dos membros da equipe; Plano das aquisições Caso o projeto envolva a aquisição de produtos ou serviços de terceiros, este documento deve conter a descrição do item, informações sobre a forma de contratação, formato de apresentação das propostas, mecanismo de controle de execução, dentre outras informações relevantes; Plano das comunicações Descreve quais tipos de informações serão distribuídas, para quem, formato, responsável pela distribuição e apresenta um cronograma de comunicação dessas informações; Plano da qualidade Relaciona as pessoas responsáveis pelas atividades de coleta das medidas, análise e sugestões de melhoria. Também define as métricas de qualidade relacionadas a prazo, escopo, custo e risco a serem utilizadas no projeto. 5.3 Execução do projeto A terceira etapa é realizada para cada fase das atividades técnicas definidas na EAP. Nessa etapa, são feitos as revisões dos documentos anteriormente construídos e o detalhamento do cronograma das atividades de cada fase. Além disso, são criados ou atualizados os seguintes documentos: Cronograma gerencial e cronograma de execução São realizadas atualizações referentes ao andamento das atividades, como também podem ser incluídas ou retiradas atividades (em caráter excepcional); Acompanhamento do desempenho do projeto Nesse documento, são apresentados os indicadores de execução de cada pacote de trabalho da fase, os subprodutos já concluídos, os atrasos na execução das atividades, possibilitando o acompanhamento

integrado do escopo, prazo e objetivos de custo, utilizando técnicas de earned value para medição do desempenho durante a execução do projeto. Ocorrências ou gatilhos de risco Registro de ocorrências ou gatilhos de riscos que aconteceram durante o projeto, sendo armazenadas informações como: datas das ocorrências do risco e ação de resposta tomada; Requisições de mudanças do produto Registra as solicitações de alterações para o produto, contendo informações como: solicitante, descrição da mudança, impacto e parecer técnico; Sugestões de melhoria de qualidade do processo Documento contendo a relação dos problemas identificados na execução de um determinado processo, sugestões propostas, seus impactos e benefícios esperados; Estatística para melhoria do processo de construção de software Documento contendo os tipos de problemas encontrados em cada uma das fases, a quantidade de produtos afetados, e o custo de correção; Ações corretivas e lições aprendidas Relaciona as alterações feitas no projeto para corrigir problemas ou dificuldades encontradas e registra as lições aprendidas durante o desenvolvimento do projeto para que sirvam como base de conhecimento para novos projetos; Aceitação dos produtos da fase Documento para formalização junto ao cliente da aceitação dos subprodutos desenvolvidos durante cada uma das fases do projeto; Encerramento de fase Documento que registra o encerramento de cada uma das fases do projeto, sendo registradas as seguintes informações: tipo de produto entregue, ações corretivas e lições aprendidas mais relevantes, e um resumo de informações quantitativas: número de horas consumidas, custo real versus valor orçado e número de alterações do cronograma. 5.4 Finalização do projeto Todas as fases do ciclo de vida do projeto devem ser adequadamente encerradas. Nessa etapa, os seguintes documentos devem ser produzidos: Aceitação do produto final Documento a ser assinado pelo cliente onde é feito o registro da aceitação dos produtos entregues ao cliente; Encerramento do projeto - Documento que registra o encerramento do projeto, sendo registradas as seguintes informações: data de encerramento, lições aprendidas mais relevantes, e um resumo de informações quantitativas: número de horas trabalhadas, custo real versus valor orçado, número de alterações do cronograma, dentre outras. A seguir, a tabela 2 relaciona as gerências do PMBOK, os processos gerenciais e os documentos produzidos como saída dos processos.

Tabela 2 Documentos gerenciais dos processos de gerenciamento do PMBOK Framework de Documentos Gerenciais para Projetos de TI Gerência do PMBOK Processo Documento de Saída do Processo Gerência do Escopo Iniciação Iniciação do projeto Planejamento do escopo Planejamento do escopo Definição do escopo Estrutura Analítica do Projeto Verificação do escopo Aceitação do produto final Verificação do escopo Aceitação dos produtos da fase Controle de mudanças do escopo Ações corretivas e lições aprendidas Gerência do Prazo Definição das atividades Lista de atividades da EAP Desenvolvimento do Cronograma Gerencial cronograma Desenvolvimento do Cronograma de Execução cronograma Controle do cronograma Ações corretivas e lições aprendidas Gerência de Custos Planejamento dos recursos Planejamento de recursos Orçamentação dos custos Orçamento do projeto Controle dos custos Acompanhamento de desempenho do projeto Controle dos custos Ações corretivas e lições aprendidas Gerência do Risco Planejamento da gerência de Plano de gerência do risco risco Identificação dos riscos Identificação dos riscos Análise qualitativa dos riscos / Análise quantitativa dos riscos Análise qualitativa e quantitativa dos riscos Identificação dos riscos Ocorrências ou gatilhos de risco Planejamento de resposta a Plano de resposta a riscos Gerência de Recursos Humanos Gerência comunicações das riscos Planejamento organizacional Planejamento organizacional Planejamento das comunicações Matriz de responsabilidades Organograma do projeto Planejamento de comunicações Relato de desempenho Acompanhamento de desempenho do projeto Encerramento administrativo Encerramento de fase Encerramento administrativo Encerramento de projeto Gerência da Qualidade Planejamento da qualidade Plano de Gerência da Qualidade Garantia da qualidade Sugestões para melhoria da qualidade do processo Controle da qualidade Estatística para melhoria do processo de construção de software Gerência das Aquisições Planejamento das aquisições Planejamento de Aquisições Gerência da Integração Desenvolvimento do plano do Plano de execução do projeto projeto Execução do plano do projeto Requisições de mudanças do produto Execução do plano do projeto Acompanhamento de desempenho do projeto Controle integrado de mudanças Ações corretivas e lições aprendidas Apresentam-se a seguir as principais conclusões deste trabalho.

6. CONCLUSÃO Este artigo apresentou um framework para gerenciamento de projetos de desenvolvimento de software com o objetivo de melhorar a qualidade dos processos de planejamento, controle e execução de projetos, bem como aprimorar as estimativas de prazo e custo. Com a implantação desse framework, pretende-se que a organização atinja o nível 3 GERENCIADO do modelo de maturidade e qualidade de projetos indicado na tabela 1 e uma parte significativa dos requisitos do nível 4 INTEGRADO. O único ponto não atendido no nível 4 é o do estabelecimento de uma base de dados de fácil recuperação das informações dos projetos conduzidos pela organização, pois o foco deste trabalho são as ações realizadas pela equipe nos processos, com o registro das informações em documentos do projeto e não a construção de um modelo de dados gerencial. Estabelecendo-se o nível 3 na organização, os processos gerenciais passam a apresentar características de planejamento e controle sistematizados, melhorando estimativas de custo e prazo e permitindo melhor acompanhamento do projeto. BIBLIOGRAFIA [1] Branco Jr., Eliseu C., Belchior, A. D.,2001, Processos Gerenciais de Projetos de Software, Uma Abordagem Qualitativa, Artigo publicado no Workshop de Qualidade de Software (WQS), XV SBES, Simpósio Brasileiro de Engenharia de Software, Rio de Janeiro. [2] Ibbs, C. W., & Kwak, Young Hoom, 1997, Measuring project management s return on investment, PM Network, pp. 36-38. [3] Ibbs, C. W., & Kwak, Young-Hoon, 1997, Benchmarking project management organizations, PM Network, pp. 49-53. [4] NBR ISO/IEC 12207, 2000, Tecnologia de Informação Processos de ciclo de vida de software. [5] PMI Standards Commitee,2000, A Guide to the Project Management Body of Knowledge (PMBOK), Filadelfia, PA, USA, PMI Publishing Division. [6] Pressman, R. S., 2000, Software Engineering A Practitioner s Approach, Fifth Edition, McGraw-Hill. [7] Site do Project Management Institute - Acesso: Outubro/2001, http://www.pmi.org. [8] INSOFT, 2000, Projeto CONLAQS Consolidação do Laboratório de Avaliação da Qualidade de Software, Fortaleza, projeto aprovado pelo Programa RHAE Programa de Recursos Humanos em Atividades Estratégicas do CNPq.