| |
| Acadêmico(a): Lindolfo Pereira Junior |
| Título: Protótipo de uma Ferramenta para Gerência de Custos em Projetos de Software Baseada no Modelo PMBOK |
| |
| Introdução: |
A Engenharia de Software tem por finalidade auxiliar na construção de software da melhor maneira possível (Pressman, 1992). Desde os anos 60, quando a frase “The Software Crisis” foi pronunciada, muitos problemas desta área foram identificados, e muitos deles ainda persistem, tais como (Gibbs, 1994):
1. Previsão pobre – desenvolvedores não prevêem adequadamente quanto tempo e esforço serão necessários para produzir um sistema de software que satisfaça as necessidades (requisitos) dos clientes/usuários. Sistemas de software são geralmente entregues muito tempo depois do que fora planejado;
2. Programas de baixa qualidade – programas de software não executam o que o cliente deseja, conseqüência talvez da pressa para se entregar o produto. Os requisitos originais podem não ter sido completamente especificados, ou podem a presentar contradições, e isto pode ser descoberto muito tarde durante o processo de desenvolvimento;
3. Alto custo para manutenção – a manutenção pode ser corretiva, quando ocorrem enganos (erros, falhas) no sistema já entregue, ou evolutiva, quando novas características são adicionadas ao sistema de software. Ambas são caras quando o sistema original foi construído sem uma arquitetura clara e visível;
4. Duplicação de esforços – é difícil compartilhar soluções ou reusar código, em função das características de algumas linguagens adotadas, por falta de confiança no código feito por outra pessoa e até mesmo pela ausência/deficiência de documentação das rotinas e dos procedimentos já construídos.
Para solucionar alguns destes problemas, muitas empresas de desenvolvimento de software têm adotado metodologias de desenvolvimento de software. Os ambientes tradicionais das empresas geralmente têm suportado somente a engenharia do produto, assumindo um processo implícito e tendo como foco principal o produto. Esta visão tem limitado as empresas no que diz respeito à tomada de decisões, ao estabelecimento e arquivamento de metas organizacionais, à determinação de pontos para melhoria, à estipulação de prazos para entrega de produtos e à obtenção de uma certificação.
De acordo com Paulk (1993), alguns estudos e pesquisas que foram realizados nos anos 90 demonstraram que o gerenciamento de projeto é a causa mais evidente das falhas na execução e entrega de produtos e serviços de software. O Software Engineering Institute (SEI) constatou, já em 1993, que o principal problema que aflige as organizações de software é gerencial e preconizou que: “as organizações precisam vencer o seu buraco negro que é o seu estilo de gerenciar de maneira informal, sem métodos e sem técnicas”.
O estudo realizado por Standish (1995), chamado de ”Relatório do Caos”, focou a indústria de software comercial. Esse estudo identificou que: nas empresas dos Estados Unidos, 31% dos projetos estudados foram cancelados antes de estarem concluídos; 53% dos projetos de software que foram concluídos excederam mais do que 50% a sua estimativa de custo; somente 16% dos projetos, em grandes empresas, foram entregues no tempo e orçamento.
Estudos mais recentes realizados por Standish (2000), revelam que: apenas 28% dos projetos de software são completados dentro da sua estimativa de tempo e com todas as características e funções originalmente especificadas; 49% dos projetos são completados acima das estimativas de tempo e orçamento, e ainda com menos características e funções que inicialmente especificados no projeto, 23% dos projetos de software são cancelados antes da conclusão ou nunca são implementados. A evolução dos projetos de software nos Estados Unidos no período de 1994 a 2000 pode ser verificada na tabela 1. Novamente o estudo indicou o gerenciamento do projeto como a principal causa para o sucesso ou fracasso de um projeto de software.
Tabela 1 – Evolução da indústria de software americana desde 1994.
Jones (1999) destaca que a ausência de um processo de gerenciamento apropriado, aliado às estimativas deficientes de custo e de tempo, é uma das principais causas das falhas dos projetos de software.
Apesar disso, o gerenciamento de projetos de software ainda é pouco abordado e praticado nas SDO. Diante disto, a utilização de procedimentos padronizados e de fácil compreensão pode ser de grande valor, fornecendo uma orientação aos gerentes de projeto e dificultando a ocorrência de falhas graves de gerenciamento por falta de experiência.
O objetivo do gerenciamento de projetos é assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessários para um projeto produzir um produto e/ou serviço de acordo com seus requisitos.
Segundo Martins (2002), o Project Management Institute (PMI), entidade internacional sem fins lucrativos que congrega os profissionais que atuam em áreas relacionadas à Gerência de Projetos, é pioneiro na regulamentação e distribuição do conhecimento referente à disciplina de gerência de projetos. O PMI especificou alguns procedimentos que visam padronizar a teoria associada à gerência de projetos. A teoria de gestão definida pelo PMI está registrada em um documento chamado Project Management Body of Knowledge (PMBOK).
O PMBOK define algumas áreas de conhecimento da gerência de projetos, que descrevem os conhecimentos e práticas em gerência de projetos em termos dos processos que as compõe. Uma delas é a Gerência de Custos, que inclui os processos necessários para assegurar que o projeto possa ser executado dentro do orçamento aprovado. Esta área engloba o planejamento de recursos, as estimativas de custos dos recursos, a confecção do orçamento e o controle de custos.
DeMarco (1991) afirma “que não se pode controlar o que não se pode medir” e comenta que, apesar de ser óbvio o forte elo entre medição e controle, é uma idéia nova para a maioria dos gerentes de software que mantém a ilusão de que se consegue levar adiante um projeto, sob total controle, sem nunca terem medido coisa alguma. Segundo Braga (1996), através do uso de métricas, a área de informática passa a ter números para apresentar, seja em resultados seja em metas de desempenho.
De acordo com Silva (2000), um software é desenvolvido para realizar determinadas funções. Determinar estas funções segundo critérios precisos e dar-lhes uma medida é o ponto-chave da Análise de Pontos de Função. A Análise de Pontos de Função pretende fornecer uma unidade de medida para a indústria de software, independente de plataforma ou linguagem. Sendo assim, pode ser facilmente utilizada e compreendida por profissionais de informática, e utilizada para auxiliar no gerenciamento e mensuração do tamanho funcional de um software.
As ferramentas determinam algum apoio automatizado para os procedimentos do processo. Com o intuito de fornecer meios para este apoio automatizado, este trabalho desenvolve um protótipo de ferramenta para o gerenciamento e acompanhamento de projetos de software. Esta ferramenta fornece a estrutura para que uma SDO possa de forma automatizada gerenciar os recursos necessários para que um projeto possa produzir um produto e/ou serviço de acordo com seus requisitos, controlando todos os custos relativos ao desenvolvimento do mesmo.
|
| |
|
