Análise Conclusiva

Considerando que a fase de monitoramento e controle permanece durante toda a execução do projeto, a última fase do processo de gerenciamento (segundo a visão de

Jalote, 1997) é executada quando o processo de desenvolvimento termina. A razão básica para realizar a análise conclusiva é prover informação sobre o processo de desenvolvimento. Esta informação se faz necessária para compreender as características do processo, pois as informações retiradas desta análise darão suporte e estimativas para futuros projetos. Além disso, esta fase prevê realizar uma análise sobre o próprio processo utilizado.

3.5 Projetos de Pesquisa

Esta seção apresenta alguns modelos e ferramentas desenvolvidos recentemente, como resultado de projetos de pesquisa, para atuarem no âmbito do gerenciamento de projetos de software.

3.5.1 Prompter

Uma pesquisa apresentada por O’Connor & Jenkins (1999) e que resultou em uma tese de PhD (O’Connor, 2000) inclui agentes inteligentes para auxiliar no processo de tomada de decisão, sendo desenvolvido utilizando arquitetura cliente-servidor de natureza distribuída e multi-plataforma. O objetivo desta pesquisa vai de encontro a carência no suporte ao processo de tomada de decisão nas ferramentas de gerenciamento de projeto, desenvolvendo um modelo que encapsula o conhecimento do especialista e torna-o disponível para todos os usuários.

Os autores acreditam que os benefícios desta abordagem aplicada no processo de tomada de decisão no domínio do gerenciamento de projeto de software são: (i) as sugestões auxiliam o usuário a balancear custo, qualidade e tempo nas tomadas de decisão sobre os recursos utilizados no projeto; (ii) o conhecimento é adequado para diferentes ciclos de vida e (iii) medições são sugeridas de forma que possibilitarão ao usuário verificar se o projeto está atingindo os objetivos e replanejar os caminhos para atingi-los se necessário.

Uma visão de alto nível da arquitetura proposta nesta pesquisa pode ser visualizada na Figura 12. A arquitetura possui uma interface com o usuário,um sistema de apoio a decisão e uma base de conhecimento.

Figura 12: Arquitetura do Sistema

Fonte: O’Connor & Jenkins (1999)

Um protótipo desta ferramenta, denominada Prompter, foi desenvolvido em Java utilizando a linguagem JESS (Java Expert System Shell) para implementação do agente. (O’Connor & Jenkins, 1999; O’Connor, 2000)

3.5.2 CSCW e Gerenciamento de projetos

Knotts et al. (1998) apresenta uma abordagem conceitual para o gerenciamento de projetos o qual inclui CSCW (Computer-Supported Cooperative Work) durante o planejamento de projetos. Os autores propõem uma ferramenta a qual o planejamento de projeto seria inicialmente decomposto e distribuído para a equipe de trabalho que trabalharia independentemente e em paralelo, para determinar os requisitos das atividades que lhes foram designadas. Com relação a isto, a ferramenta seria usada para simular o projeto em grupo definindo quais planos seriam revistos, modificados e aperfeiçoados.

A ferramenta representaria o projeto como um processo dinâmico e distribuído de múltiplos agentes interagindo independentemente em busca de um objetivo comum. O propósito desta ferramenta, segundo Knotts et al. (1998), foi aplicado no campo de projeto de circuitos eletrônicos.

Considerando que o projeto tenha todas as atividades já completadas o passo seguinte iniciaria desenvolvendo uma simulação do projeto completo. Durante a simulação, agentes autônomos baseados em computador dariam a sequencia das atividades do projeto automaticamente. Para isto, a ferramenta prove um agente para cada atividade. Cada agente seria projetado para se comportar como sendo o responsável pela atividade a qual foi designado. Os agentes operariam em um ambiente blackboard onde todos os recursos seriam listados no quadro-negro e, desta forma, visível por todos os agentes. A simulação do projeto inteiro seria também observada pelo usuário em tempo real, pois a ferramenta executa e mostra em uma animação a representação do progresso.

3.5.3 DSPMtool

O DSPMtool, desenvolvido na School of Computer Science and Engineering da University of New South Wales, é um sistema de gerenciamento de projeto de software distribuído (cliente/servidor) que consiste de ferramentas e técnicas usadas para coletar, analisar, integrar e disseminar as saídas dos vários processos de gerenciamento de projeto de software. (Surjaputra & Maheshwari 1999)

A idéia central do DSPMtool é gerenciar projetos de software considerando os produtos do processo de desenvolvimento de software, tais como projeto, especificação de requisitos, componentes de software. Para o DSPMtool os documentos podem ser, por exemplo, arquivos multimídia, código fonte, executáveis, documentos texto, dentre outros. As características de gerenciamento de configuração do DSPMtool fornecem a infraestrutura para gerenciar os vários elementos produzidos durante o desenvolvimento de um projeto de software distribuído. Surjaputra & Maheshwari (1999) acreditam que com esta característica, o gerente de projeto controla como os documentos são distribuídos para os membros da equipe tornando-se uma maneira de planejar e controlar atividades, cronograma, recursos e custos envolvidos no desenvolvimento de projeto de software.

3.5.4 SPPA

O SPPA (Software Project Planning Associate), desenvolvido na linguagem de programação Java e acesso através dos browsers, é projetado para auxiliar ao gerente de

projeto de software a inicializar o planejamento de projeto, refinar o planejamento, organizar a equipe, definir o cronograma, medir, visualizar, monitorar e controlar, prognosticar e coletar informaçãoes. (Wu & Simmons, 2000)

Os recursos, tarefas, cronograma e milestones do projeto são descritos no planejamento. Conforme o processo de desenvolvimento evolui medidas do projeto do software são reunidas e reportadas. Prognósticos do processo de software são efetuados e recomendações são dinamicamente reportados sugerindo o desenvolvimento de software que deve ser executado para cumprir com o planejado.

O SPPA, segundo Wu & Simmons (2000), foi desenvolvido de acordo com um modelo de Planejamento Baseado em Conhecimento que permite ao gerente acompanhar o projeto. Um agente de planejamento de projeto que reporta problemas e sugestões para o gerente auxiliando na garantia que o projeto satisfaz o orçamento e o tempo previsto.

A arquitetura do SPPA consiste em uma arquitetura de 3 camadas, conforme visualizado na Figura 13.

Figura 13: Arquitetura 3 camadas

A primeira camada contém o “thin client” que é a interface com o gerente e desenvolvedores. Nesta camada faz-se necessário somente um browser web e a máquina virtual Java. A comunicação com a segunda camada dá-se através de Remote Method Invocation (RMI).

A segunda camada abriga o Middleware serve onde está operando PAMPA 2 (ambiente que utiliza um sistema especialista para criar agentes inteligentes), JESS (linguagem para programação de agentes) e SPPA. O SPPA é um subsistema que permite: (i) planejamento (definição de atividades, ciclo de vida, milestones, gráfico de Gantt,...); (ii) agentes inteligentes de planejamento (auxilia o gerente a acompanhar o status do projeto); (iii) base de conhecimento (contém as regras e fatos para os agentes inteligenes operarem); (iv) informação do grupo (mantém informações referentes aos custos de pessoal, que constitui a maior despesa de um projeto). A comunicação com a terceira camada ocorre através de JDBC (Java Database Connectivity). (Wu & Simmons 2000)

A terceira camada, servidora de banco de dados, utiliza o sistema de gerenciamento de banco de dados relacional IBM DB2.