fÁbio pittoli investigando o uso de redes bayesianas como ferramenta de … · 2020-01-15 · os...
TRANSCRIPT
FÁBIO PITTOLI
INVESTIGANDO O USO DE REDES BAYESIANAS COMO FERRAME NTA DE
APOIO À MONITORAÇÃO DE PROJETOS DE SOFTWARE
CANOAS, 2011
FÁBIO PITTOLI
INVESTIGANDO O USO DE REDES BAYESIANAS COMO FERRAME NTA DE
APOIO À MONITORAÇÃO DE PROJETOS DE SOFTWARE
Trabalho de conclusão apresentado para a banca examinadora do Curso de Ciência da Computação do Centro Universitário La Salle – Unilasalle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.
Orientador: Prof. Me. Abraham Lincoln Rabelo de Sousa
CANOAS, 2011
FÁBIO PITTOLI
INVESTIGANDO O USO DE REDES BAYESIANAS COMO FERRAME NTA DE
APOIO À MONITORAÇÃO DE PROJETOS DE SOFTWARE
Trabalho de conclusão aprovado como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação pelo Centro Universitário La Salle – Unilasalle.
Aprovado pela banca examinadora em ___ de _________ de 2011.
BANCA EXAMINADORA:
______________________________________________
Prof. Me. Abraham Lincoln Rabelo de Sousa
Unilasalle
______________________________________________
Prof. Me. Aline Duarte Riva
Unilasalle
______________________________________________
Prof. Me. Eder Stone Fontoura
Unilasalle
AGRADECIMENTOS
Agradeço a todos aqueles que participaram da elaboração deste trabalho, seja através
de ideias, dicas ou materiais. Muito obrigado a todos pelo tempo a mim dedicado e pela
atenção. Em especial, agradeço ao professor Abraham Lincoln Rabelo de Sousa por sua
colaboração, apoio e dedicação ao longo de todo o trabalho. Agradeço também ao colega e
amigo Luiz Felipe Prestes Teixeira pelas trocas de ideias e opiniões que tivemos ao longo do
desenvolvimento dos nossos trabalhos que, de certa forma, são complementares.
RESUMO
Dentro do contexto do gerenciamento de projetos de software o ato de estimar é de
fundamental importância, tanto para mensurar custos quanto para mensurar tempo e esforço.
Porém, mais importante do que estimar é monitorar e controlar as estimativas para que essas
não desviem daquelas mensuradas inicialmente e, caso elas se alterem por alguma razão, que
se possa tomar medidas pró ativas no sentido de evitar situações em que o gerente só tome
noção da real dimensão dos desvios de estimativa quando o projeto já está custando, por
exemplo, o dobro do custo inicial ou o dobro do tempo estimado inicialmente. Sendo assim, é
proposto aqui um modelo para monitoramento de projetos de software que utiliza-se de redes
Bayesianas para auxiliar no monitoramento das estimativas e, mais precisamente, facilitar
predições estatísticas em relação a um processo de software em execução com o objetivo de
indicar possíveis desvios de estimativas antes que esses efetivamente ocorram. Objetivou-se
montar um processo de software seguindo as diretivas básicas da metodologia RUP for Small
Projects. Além disso, utilizou-se de uma base de dados contendo dados de projetos históricos
com o objetivo de treinar as redes Bayesianas utilizadas. A definição das redes Bayesianas
tomou como ponto de partida características já bastante utilizadas em outros projetos que
trabalham com esse tipo de abordagem preditiva na área de desenvolvimento, além disso,
procurou-se demonstrar na rede características que se relacionam e influenciam umas as
outras e que possuem correspondência em um cenário real de desenvolvimento de software.
Palavras-chave: Gerência de projetos. Redes Bayesianas. Monitoração.
ABSTRACT
Within the context of software projects management the act of estimate is of fundamental
importance, both as measure costs to measure time and effort. But, more important than
estimate is to monitor and to control the estimates so they don`t deviate from those initially
measure and, if they are changed for any reason, that one can take proactive measures to
avoid situations where the manager just be aware of the real extent of the estimation
deviations when the project is already costing, for example, double initial cost or double
initial time initially estimated. So, a model is proposed here a model for monitoring software
projects that uses Bayesian networks to assist in monitoring the estimates and, more precisely,
facilitate statistical predictions about a software process running in order to indicate possible
deviations of estimates before they actually occur. The goal was to set up a software process
following the basic guidelines of the RUP for small projects methodology. Furthermore, was
used a database containing data from historical projects in order to train the Bayesian
networks used. The definition of the Bayesian networks had as a starting point characteristics
widely used in other projects that work with this kind of predictive approach in development
area, furthermore, tried to demonstrate in the network characteristics that are related and
influence each other and that have matches in an actual software development.
Keywords: Project management. Bayesian networks. Monitoring.
LISTA DE ILUSTRAÇÕES
Figura 1 - Rede Bayesiana representando um domínio ............................................................ 18
Figura 2 – Rede Bayesiana com as probabilidades condicionais ............................................. 19
Figura 3 - Estrutura de funcionamento de uma rede Bayesiana dinâmica ............................... 25
Figura 4 – Processo modelado no WebAPSEE ........................................................................ 37
Figura 5 – Interface de acesso de um agente do processo no WebAPSEE .............................. 38
Figura 6 – Interface do Netica apresentando uma rede Bayesiana ........................................... 41
Figura 7 – GeNIe demonstrando um modelo de rede Bayesiana ............................................. 42
Figura 8 – Modelo conceitual – configuração .......................................................................... 44
Figura 9 – Modelo conceitual - monitoramento e controle ...................................................... 45
Figura 10 – Cenário 1 – configuração da rede Bayesiana ........................................................ 46
Figura 11 – Cenário 2 – monitoração e controle ...................................................................... 47
Figura 12 – Fragmento do modelo ER da base do WebAPSEE ............................................... 49
Figura 13 – Diagrama de contexto da aplicação....................................................................... 50
Figura 14 – Diagrama de caso de uso Selecionar métricas ...................................................... 51
Figura 15 – Diagrama de caso de uso Gerar arquivo de dados ................................................ 52
Figura 16 – Diagrama de caso de uso Selecionar dados de evidência ..................................... 54
Figura 17 – Diagrama de sequência com as principais funcionalidades .................................. 55
Figura 18 – Diagrama de classes da aplicação ......................................................................... 56
Figura 19 – Interface web desenvolvida ................................................................................... 57
Figura 20 – Exemplo de arquivo de dados gerado com os dados do processo......................... 59
Figura 21– Logs do Windows service de monitoramento ........................................................ 60
Figura 22- Visão macro do processo iterativo modelado no WebAPSEE ............................... 62
Figura 23 – Atividades de requisito .......................................................................................... 63
Figura 24 - Atividades de gerenciamento do projeto ............................................................... 64
Figura 25 – Atividades de análise............................................................................................. 64
Figura 26 – Atividades de implementação ............................................................................... 65
Figura 27 – Disciplina de testes e suas atividades .................................................................... 66
Figura 28 – Disciplina de gerenciamento de mudanças segundo o RUP ................................. 66
Figura 29 - Submodelo de requisitos ........................................................................................ 68
Figura 30 - Rede Bayesiana com as evidências do cenário 1 ................................................... 69
Figura 31 - Rede Bayesiana após a inclusão de profissionais experientes ............................... 70
Figura 32 - Rede Bayesiana demonstrando as evidências do cenário 2 ................................... 71
Figura 33 - Rede Bayesiana após a entrada de profissionais inexperientes ............................. 72
Figura 34 - Rede Bayesiana com as vidências do cenário 3 ..................................................... 73
Figura 35 - Rede Bayesiana com a complexidade ajustada ...................................................... 74
Figura 36 - Rede Bayesiana com as evidências do cenário 4 ................................................... 75
Figura 37 - Rede Bayesiana com equipe inexperiente e complexidade ajustada ..................... 76
Figura 38 - Atividades finalizadas e atividades em atraso ....................................................... 77
Figura 39 - Esforço estimado (em horas) para a conclusão das atividades do processo .......... 78
Figura 40 - Relacionamento entre atividades após a exclusão de uma delas ........................... 79
Figura 41 - Esforço estimado sem alterações ........................................................................... 79
Figura 42 - Relacionamento entre as atividades após a nova exclusão .................................... 80
Figura 43 - Esforço estimado com alterações ........................................................................... 81
LISTA DE TABELAS
Tabela 1 – Probabilidades condicionais do problema .............................................................. 19
Tabela 2 - Resultados obtidos ................................................................................................... 22
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 11
2 GERÊNCIA DE PROJETOS ............................................................................................. 15
2.1 Gerência de Projetos de Software ................................................................................... 15
2.2 Estimativas ........................................................................................................................ 15
3 REDES BAYESIANAS ....................................................................................................... 17
3.1 Tabela de probabilidades condicionais ........................................................................... 21
3.2 Inferência em redes Bayesianas....................................................................................... 22
3.2.1 Inferência exata ............................................................................................................... 23
3.2.2 Inferência aproximada .................................................................................................... 24
3.2.3 Inferência simbólica ........................................................................................................ 24
3.3.1 Modelos Ocultos de Markov ............................................................................................ 26
3.3.2 Modelos de Filtro de Kalman .......................................................................................... 27
4 ESTUDOS RELACIONADOS ........................................................................................... 29
4 ESTUDOS RELACIONADOS ........................................................................................... 29
4.1 Gerenciamento de riscos .................................................................................................. 29
4.2 Melhoria de processos ...................................................................................................... 30
4.3 Predição de falhas ............................................................................................................. 31
4.4 Estimativa de esforço ....................................................................................................... 32
4.5 Estimativa de custos de manutenção .............................................................................. 33
5 REDES BAYESIANAS COMO FERRAMENTA DE APOIO À MONIT ORAÇÃO DE
PROJETOS ............................................................................................................................. 35
5.1 WebAPSEE ....................................................................................................................... 35
5.2 A modelagem das redes Bayesianas ................................................................................ 39
5.2.1 Netica ............................................................................................................................... 40
5.2.2 GeNIe ............................................................................................................................... 41
5.3 Modelo conceitual da solução proposta .......................................................................... 43
5.3.1 Apresentação dos cenários .............................................................................................. 45
5.4 Implementação da solução proposta ............................................................................... 47
5.4.1 Modelo de dados .............................................................................................................. 48
5.4.2 Modelagem da implementação ........................................................................................ 49
5.4.3 Protótipo da solução ....................................................................................................... 57
6 AVALIAÇÃO ...................................................................................................................... 61
6.1 O processo de software ..................................................................................................... 62
6.1.1 Requisitos ........................................................................................................................ 63
6.1.2 Gerenciamento do Projeto .............................................................................................. 63
6.1.3 Análise ............................................................................................................................. 64
6.1.4 Implementação ................................................................................................................ 65
6.1.5 Testes ............................................................................................................................... 65
6.1.6 Gerenciamento de Mudanças .......................................................................................... 66
6.2 Modelo de redes Bayesianas ............................................................................................ 67
6.3 Cenários de avaliação ....................................................................................................... 68
6.3.1 Cenário 1 ......................................................................................................................... 68
6.3.2 Cenário 2 ......................................................................................................................... 70
6.3.3 Cenário 3 ......................................................................................................................... 72
6.3.4 Cenário 4 ......................................................................................................................... 74
6.3.5 Cenário 5 ......................................................................................................................... 76
7 CONCLUSÃO ...................................................................................................................... 82
REFERÊNCIAS ..................................................................................................................... 84
11
1 INTRODUÇÃO
Todo e qualquer projeto desenvolvido, independente da área a qual se destine, necessita
ter dentre suas tarefas principais, mecanismos que objetivem a conclusão do mesmo dentro
dos parâmetros de tempo, custo e qualidade que foram estimados no momento da sua
idealização. Estabelecer tais parâmetros é trabalhar com estimativas que nem sempre serão
precisas, pois não se tem como garantir que durante o decorrer do projeto não irão ocorrer
atrasos, falta de recursos ou até mesmo alteração no escopo. Desta forma, monitorar e
controlar projetos de forma que tenhamos que alterar as previsões iniciais o menos possível e
garantir que se possa detectar tais alterações de estimativas antes que essas efetivamente
ocorram tornou-se um dos principais desafios dos gerentes de projetos. Além disso, os
mecanismos atuais utilizados na etapa de monitoramento e controle de projetos, tais como:
reuniões periódicas, consulta a relatórios técnicos e gerenciais e controle do tempo
(cronograma) acabam não sendo, por si só, muito eficientes para análises relativas ao estado
do projeto à longo prazo, pois não conseguem predizer situações-problema e desvios nas
estimativas do projeto antes que essas ocorram e não trabalham com a incerteza.
Dentro deste contexto de raciocínio sob a incerteza surgem as redes Bayesianas
(CHARNIAK, 1991; FENTON; NEIL, 1999; FIRMINO, 2004) que são utilizadas em
situações em que existem relações de causalidade, porém, nosso entendimento sobre o que
realmente está acontecendo é incompleto, necessitando de uma descrição probabilística para
uma melhor compreensão. Esse tipo de rede pode ser usada para diferentes tipos de
raciocínio, como análises preditivas, para investigar o impacto que mudanças em alguns
fatores (representados por nodos na rede Bayesiana) têm sobre os outros, e consequente apoio
a tomada de decisões. Além disso, uma vez que a rede Bayesiana esteja especificada,
evidências (valores) podem ser colocadas em qualquer nodo da rede e as probabilidades para
os nodos remanescentes serão automaticamente calculadas usando regras Bayesianas. Sendo
assim, dentro deste contexto, o problema de pesquisa apresenta-se da seguinte forma: qual o
potencial de uso de redes Bayesianas como ferramenta de apoio à monitoração e controle de
projetos de software?
Um dos principais objetivos deste trabalho é propor um modelo de ferramenta para
auxiliar no monitoramento e acompanhamento de projetos de software através da utilização
de redes Bayesianas, visando melhorar a questão das estimativas durante o monitoramento do
projeto e dando ao gerente uma visão mais realista em relação ao andamento do mesmo,
podendo assim, utilizar-se das predições feitas pela rede Bayesiana para desenvolver medidas
12
corretivas e preventivas em relação ao andamento do processo de desenvolvimento como um
todo.
Um objetivo secundário almejado ao ter-se optado por redes Bayesianas para conceber o
modelo proposto diz respeito à ideia de colaborar com a divulgação e disseminação do uso de
redes Bayesianas como ferramenta para o monitoramento de estimativas na área da gerência
de projetos, pois sendo esse tipo de técnica já bastante utilizada na área da inteligência
artificial e até mesmo na área de projeto e manutenção de softwares, sua utilização na área de
gerência de projetos ainda é bastante baixa em relação a outras técnicas para utilizadas,
principalmente, para o cálculo e monitoração de estimativas e como instrumento de apoio a
tomada de decisões. É importante mencionar também, que o objetivo aqui não é criar um
conceito novo, mas sim, propor a interação do gerente de projetos com o modelo, com o
intuito de promover e colaborar com a tomada de decisão ao longo do projeto. A ideia não é
definir uma métrica fixa ou uma regra delimitada, mas sim apresentar possíveis
comportamentos futuros do processo monitorado, cabendo sempre ao gerente de projetos a
decisão de promover suas ações futuras de acordo com o comportamento apresentado pelo
modelo.
A justificativa para escolha de redes Bayesianas dentro do contexto de monitoração e
controle de projetos reside no fato de ser uma técnica amplamente conhecida dentro da
computação, ou seja, já foi amplamente testada e teve sua eficiência comprovada,
principalmente na área da inteligência artificial desde meados da década de 80. Além disso,
sua aplicação não implica em agregar grande complexidade adicional ao processo de gerência,
pois atualmente já existem diversas ferramentas para geração de redes Bayesianas que cuidam
de toda parte estatística e probabilística de forma bastante automatizada. Neste caso, caberá ao
gerente de projeto a tarefa de seleção dos dados e validação dos resultados. Sendo assim,
julgou-se oportuno realizar um estudo em relação à eficácia desse tipo de rede em relação a
melhorias no processo de monitoramento de projetos.
Fundamentalmente, se almeja agregar à comunidade científica um estudo que analisa a
viabilidade da união do conhecimento tácito dos gerentes de projetos com a análise
probabilística oferecida pelas redes Bayesianas, visando assim, reduzir a subjetividade e a
incerteza que sempre estão envolvidas quando se trabalha com estimativas em projetos de
software.
Na forma de objetivos específicos (metas) se faz importante salientar os seguintes
pontos:
13
a) caracterizar os aspectos que norteiam o gerenciamento de projetos de software,
tomando como referência fundamental o PMBOK (Project Management Body of
Knowledge), focando, principalmente, no grupo de processos de monitoramento
e controle, bem como nos seus objetivos fundamentais;
b) compilar e categorizar trabalhos semelhantes que se utilizem de redes
Bayesianas como ferramenta de apoio dentro da engenharia de software e da
gerência de projetos;
c) especificar como se dará a interoperabilidade entre a ferramenta de apoio a
gerência de projetos adotada e a ferramenta de geração e manipulação de redes
Bayesianas, que será a parte central do modelo proposto.
d) apresentar o modelo proposto e efetuar o processo de avaliação do mesmo,
mensurando os resultados obtidos durante o processo;
e) efetuar as conclusões quanto à aplicabilidade do modelo e sua eficácia em
relação ao problema o monitoramento e controle de projetos.
Se faz importante mencionar aqui que este trabalho faz parte de um projeto
desenvolvido conjuntamente com o colega Luiz Felipe Prestes Teixeira, cujo trabalho de
conclusão de curso se propõem a identificar dados que são mais relevantes para uma maior
precisão das redes Bayesianas. A base de dados histórica de projetos elaborada por ele foi
utilizada neste trabalho com o intuito de treinar as redes. O professor Abraham Lincoln
Rabelo de Sousa, cujo trabalho desenvolvido no doutorado abrange as áreas contempladas
tanto neste trabalho, quanto no trabalho do Luiz, colaborou largamente com sua experiência e
conhecimento na área.
A monografia se apresentará da seguinte forma:
a) capitulo 2: apresenta as definições de gerência de projetos e gerência de projetos
de software, além de contextualizar a apresentar o problema das estimativas
relacionadas a projetos de software;
b) capitulo 3: define o que são redes Bayesianas, tipos de redes e principais
técnicas de inferência;
c) capítulo 4: apresenta o estudo bibliográfico realizado, onde é demonstrada
através da análise de estudos relacionados, a aplicabilidade de redes Bayesianas
na área de gerenciamento e desenvolvimento de software;
d) capítulo 5: destina-se a apresentar o modelo de monitoração de projetos de
software utilizando redes Bayesianas. Apresenta também a arquitetura
desenvolvida e todas as ferramentas que a compõe.
14
e) capítulo 6: apresenta a metodologia adotada na avaliação do modelo e apresenta
os cenários que serviram de base para a obtenção dos resultados;
f) capítulo 7: apresenta as conclusões obtidas e menciona possibilidades de
aprimoramentos no modelo em trabalhos futuros.
15
2 GERÊNCIA DE PROJETOS
Entende-se por gerenciamento de projetos “[...] a aplicação de conhecimentos,
habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus
requisitos.” (INSTITUTE, 2008, p. 432). O término de um projeto é determinado quando os
objetivos tiverem sido atingidos ou quando se concluir que esses objetivos não serão ou não
poderão ser atingidos e o projeto for encerrado. Pressman (2001) menciona que a gerência de
um projeto representa a primeira camada do processo de engenharia de software, pois abrange
todo o processo de desenvolvimento do começo ao fim.
2.1 Gerência de Projetos de Software
De acordo com Matsueda (2006), para o sucesso de um projeto de software deve-se
entender o escopo do trabalho a realizar, os riscos, os recursos humanos, os materiais
necessários, as tarefas, os pontos de monitoramento e controle, o esforço necessário para
executar cada tarefa e o custo necessário para realizar cada uma dessas tarefas.
Segundo DeMarco (1982, p. 58), “não se pode controlar o que não se pode medir”.
Gerenciar projetos de software implica, invariavelmente, em criar métricas e parâmetros
balizadores e, principalmente, estimar e gerenciar essas estimativas de forma que se possa ter
um feedback constante em relação a situação do projeto e se preparar para eventuais
mudanças.
2.2 Estimativas
O planejamento de um projeto de software requer determinar os recursos que serão
necessários para completar determinado projeto e o desenvolvimento de um cronograma para
ser seguido.
Estimativa de tempo e custo de desenvolvimento é uma atividade que exige atenção e
que exerce grande influência no processo de desenvolvimento de software (TRINDADE,
2007). Principalmente para instituições e organizações privadas, a realização de uma
estimativa correta e precisa é fundamental para a sobrevivência e para a viabilidade das
atividades das organizações.
É a definição das estimativas que garante que um projeto terá ou não sucesso durante
toda sua execução. Estimativas de esforço são úteis tanto para o cliente quanto para o
16
desenvolvedor (STEMALOS et al., 2003). Baseada nessas estimativas, a organização que
pretende contratar o projeto pode avaliar e monitorar os custos de implementação, avaliar
propostas, e desenvolver orçamentos e cronogramas realísticos.
Dados coletados (GROUP, 2009) mostram que apenas 32% dos projetos são entregues
dentro do prazo e do orçamento e que em 44% dos projetos ocorrem atrasos ou estouro de
orçamento. Um dos motivos pelos quais esses problemas acontecem é devido a estimativas
iniciais mal feitas e pouco condizentes com que é efetivamente realizado. Outro motivo é que
na grande maioria das vezes não se tem um conhecimento total sobre o problema a ser tratado,
seja por indecisões do cliente, ou por falhas no levantamento dos requisitos e falta de um
escopo bem definido para o projeto.
Ainda, segundo Stamelos et al. (2003, p. 731), “os três principais métodos para efetuar
estimativas para projetos de software são julgamento de especialista, estimativa de custo
algorítmica e estimativa por analogia”. O julgamento de especialista baseia-se na experiência
acumulada pela equipe de projetos. Estimativa algorítmica envolve a aplicação de modelos e
de fórmulas matemáticas, na maioria das vezes, provenientes de dados estatísticos. Por fim, o
método de estimativa por analogia compara o projeto do software atual com dados históricos
de projetos semelhantes.
Independentemente do método escolhido para efetuar as estimativas é importante
salientar sempre que o processo de estimativa é considerado como um domínio complexo
onde a relação causal entre os fatores são não-determinísticos e com uma natureza
inerentemente incerta (MENDES; MOSLEY, 2008). Por exemplo: assumindo que existe um
claro relacionamento entre esforço de desenvolvimento e a experiência dos desenvolvedores
envolvidos, não existem dados concretos provando que conforme a experiência aumenta a
quantidade de esforço diminui. Porém, à medida que a experiência aumenta a probabilidade
da estimativa de esforço melhora também. Desta forma, é correto afirmar que lidar com
estimativas acarreta, necessariamente, em lidar com incertezas.
Dentro do contexto de análise do raciocínio sob a incerteza, surgem as Redes
Bayesianas, que são utilizadas em situações em que existem relações de causalidade, porém,
nosso entendimento sobre o que realmente está acontecendo é incompleto, necessitando de
uma descrição probabilística para uma melhor compreensão (CHARNIAK, 1991).
17
3 REDES BAYESIANAS
Redes Bayesianas foram desenvolvidas no início dos anos 80 para facilitar a tarefa de
predição e diagnóstico em sistemas de Inteligência Artificial (IA) (CHARNIAK, 1991). O
nome Redes Bayesianas deriva da utilização da fórmula matemática para o cálculo de
probabilidades estabelecido por Thomas Bayes em 1763.
Redes Bayesianas podem ser consideradas como sendo diagramas que organizam o
conhecimento numa dada área através de um mapeamento entre causas e efeitos
(CHARNIAK, 1991).
Para Fenton e Neil (1999, p. 682), “as redes Bayesianas nos permitem expressar
relações complexas dentro de um modelo a um nível de incerteza com base no problema”.
As redes Bayesianas são grafos acíclicos dirigidos, ou seja, os arcos são unidirecionais
de tal forma que, quando uma relação sai de um nodo ela não pode retornar para o mesmo
nodo, em respeito à direção especificada pelas setas. A representação gráfica de uma rede
Bayesiana é composta por nodos que representam variáveis aleatórias, que assumem valores
discretos ou contínuos. Os arcos são responsáveis por relacionar estes nodos, que representam
as conexões ou as dependências diretas. A ideia é representar as relações de causalidade entre
os nodos (FIRMINO, 2004).
Marques e Dutra (2000, p. 7) afirmam que toda rede Bayesiana é composta pelas
seguintes características:
a) um conjunto determinado de variáveis e um conjunto de arcos ligando essas
variáveis;
b) cada uma das variáveis possui um conjunto limitado de estados mutuamente
exclusivos;
c) as variáveis e arcos formam um grafo dirigido e sem ciclos;
d) para cada variável A que tem como pais B1, ..., Bn existirá uma tabela de
probabilidades P(A|B1, ..., Bn).
É importante observar que, caso a variável A não possua pais, a tabela de probabilidades
é reduzida para uma probabilidade incondicional P(A). Estando definida a topologia da rede,
basta especificar as probabilidades dos nós que participam com dependências diretas e utilizar
estas probabilidades para computar as demais probabilidades que se deseje.
Para fins de exemplo, pode-se considerar um caso clássico de redes Bayesianas
apresentado por Russell e Norvig (1995, p. 511).
18
Considere um novo alarme contra ladrões. Tal alarme é muito confiável na detecção de
ladrões, porém, ele também pode disparar caso ocorra um terremoto. Dois vizinhos, João e
Maria, comprometeram em telefonar caso o alarme dispare. João sempre liga quando ouve o
alarme, porém, algumas vezes confunde o alarme com o telefone e também liga nesses casos.
Maria, por outro lado, gosta de ouvir música alta e, às vezes, não escuta o alarme.
Tal domínio poderia ser representado da seguinte forma (Figura 1):
Figura 1 - Rede Bayesiana representando um domínio
Fonte: Russell e Norvig, 1995
Conforme se pode observar a rede não possui nenhum nó que indique que Maria esteja
ouvindo música, ou que o telefone esteja tocando e atrapalhando o entendimento de João.
Estes fatos são implícitos e estão associados à incerteza relacionada pelos arcos
Alarme� JoãoLig e MariaLig, pois seria necessário um tempo muito grande para se obter tais
probabilidades e tais informações poderiam ser irrelevantes. Desta forma, as probabilidades
devem resumir as condições nas quais o alarme pode falhar (falta de bateria, campainha
estragada, etc) e ainda, as condições em que João e Maria podem falhar (não estava presente,
não ouviu o alarme, estava de mau-humor, etc). Após definida a topologia da rede, torna-se
necessário definir a tabela de probabilidades condicionais para cada um dos nós. Cada uma
das linhas na tabela contém a probabilidade condicional para cada caso condicional dos nós
pais. Entende-se por caso condicional uma possível combinação dos valores para os nós pais
(ver Tabela 1). Por exemplo, para a variável aleatória Alarmes temos:
19
Tabela 1 – Probabilidades condicionais do problema
Ladrão Terremoto P(Alarme|Ladrão, Terremoto) Verdadeiro Falso
Verdadeiro Verdadeiro 0.95 0.050 Verdadeiro Falso 0.95 0.050
Falso Verdadeiro 0.29 0.71 Falso Falso 0.001 0.999
Fonte: Marques e Dutra, 2000
A imagem a seguir demonstra a rede Bayesiana para o exemplo citado, onde são mostradas as
probabilidades condicionais (Figura 2):
Figura 2 – Rede Bayesiana com as probabilidades condicionais
Fonte: Russell e Norvig, 1995
Conforme mostrado na figura 2, as distribuições de probabilidades são exibidas na
forma de uma Tabela de Probabilidade Condicional, ou TPC, onde tal forma de representação
pode ser utilizada tanto para representar variáveis discretas como para representar variáveis
contínuas. Cada uma das linhas contém a probabilidade condicional para cada caso
condicional dos nós pais. Um caso condicional (também chamado de caso de
condicionamento) representa uma possível combinação dos valores para os nós pais
(MARQUES; DUTRA, 2000).
Para variáveis booleanas, onde se sabe que a probabilidade de um valor verdadeiro é p, então a probabilidade de um valor falso deve ser 1-p, desta forma frequentemente omite-se o segundo número. Normalmente, uma tabela para uma determinada variável booleana com k pais booleanos contém 2k probabilidades que podem ser especificadas independentemente. Um nó que não possua pais tem apenas uma linha na tabela de probabilidades, representando as probabilidades a priori de cada valor possível da variável. (RUSSELL; NORVIG, 1995, p. 512).
20
Após os cálculos das probabilidades condicionais terem sido efetuados e o grafo já
estando totalmente estruturado é possível calcular as inferências através dos conceitos do
cálculo das probabilidades, tais como a regra da cadeia e o Teorema de Bayes são
demonstrados (LEMOS, 2007, p. 64):
a) Regra de cadeia: seja C um subconjunto de eventos de E, onde:
i. C = {C1, C2, ... Cn}, então: P(C1 ∩ C2 ∩ ... ∩ Cn) = P(C1) P(C2 |
C1)...P(Cn|C1, C2, ..., Cn-1).
b) Teorema de Bayes: sejam dois eventos A e E tais que P(A) > 0 e P(E) > 0, então:
P(A|E) = (P(E| A)P(A)) / P(E)
Onde:
P(A) é a probabilidade a priori do evento A;
P(E|A)P(E) é a verossimilhança relativa da evidência E, assumindo a
ocorrência do evento A;
P(A|E) é a probabilidade a posteriori de A dada a evidência E.
De acordo com essas informações, pode-se concluir que uma rede Bayesiana possui
distribuições condicionadas, ou seja, as probabilidades serão medidas dado que o evento que
influencie o evento atual ocorra ou não. Sendo assim, nota-se uma relação de dependência
nas ocorrências de eventos entre si. Porém, existe uma situação que é de suma importância, a
qual é denominada condição Markoviana e que é também uma característica de redes
Bayesianas.
De acordo com Ross (2000), um processo possui a propriedade Markoviana desde que:
P{Xn+1 = j | X1 = i1, X2 = i2, ..., Xn = in} = P{ X n+1 = j | Xn = in}
Ou seja, a probabilidade da variável X assumir um valor j no momento futuro não
depende do passado, visto que se tenha um conhecimento do comportamento da variável no
presente (ROSS, 2006).
21
3.1 Tabela de probabilidades condicionais
As tabelas de probabilidades condicionais tendem a ter, normalmente, uma quantidade
grande de entradas, mesmo em casos de nós que possuem um número reduzido de país.
Preencher tais valores pode ser algo que necessite de certa experiência, caso a relação entre
nós pais e filhos seja arbitrária. Porém, na maioria dos casos, esta relação pode ser adaptada a
algum padrão, facilitando o restante do trabalho. Tais casos são chamados de Distribuições
Canônicas (MARQUES; DUTRA, 2000).
Um caso bastante conhecido e simples é aquele representado por nós determinísticos.
Tais nós têm o seu valor determinado de forma explícita a partir dos valores dos seus pais. Por
exemplo: uma relação estabelecida entre os nós pais Italiano, Alemão e Grego e o nó filho
Europeu é determinado especificamente pela disjunção dos pais.
Relações onde exista incerteza podem ser chamadas de Relações com Ruídos. Dentro da
lógica proposicional pode-se dizer que o estado Febre, é verdadeiro se e somente se Gripe,
Resfriado ou Malária é verdadeiro. A relação ruído acrescenta um nível de incerteza à relação
(OU), levando em conta três suposições:
a) cada uma das causas possui uma chance independente de causar o efeito;
b) todas as possibilidades estão listadas;
c) o fato de uma das causas ser inibida é independente da inibição das demais.
Considerando o exemplo, P(Febre|Gripe) = 0,4, P(Febre|Resfriado) = 0.8 e
P(Febre|Malaria) = 0.9, para tais valores, os parâmetros de ruídos serão,
respectivamente, 0.6, 0.2, 0.1.
Em ocasiões em que nenhum nó pai é verdadeiro, o nó filho é falso com 100% de
certeza. Se apenas 1 pai é verdadeiro, então a probabilidade do nó filho ser falso será sempre
igual ao valor do ruído daquele pai que for verdadeiro. No caso de existir mas de uma pai
verdadeiro, a probabilidade será o valor resultante do produto do ruído dos pais (MARQUES;
DUTRA, 2000).
A Tabela 2 mostra o resultado obtido para o exemplo apresentado:
22
Tabela 2 - Resultados obtidos
Gripe Resfriado Malária P(Febre) P(¬Febre)
F F F 0.0 1.0
F F V 0.9 0.1
F V F 0.8 0.2
F V V 0.98 0.02 = 0.2 x 0.1
V F F 0.4 0.6
V F V 0.94 0.06 = 0.6 x 0.1
V V F 0.88 0.12 = 0.6 x 0.2
F F F 0.0 1.0
Fonte: Marques e Dutra, 2000
3.2 Inferência em redes Bayesianas
Inferência em redes Bayesianas diz respeito à tarefa de computar a distribuição de
probabilidades a posteriori para um conjunto de variáveis de consulta. É utilizado,
basicamente, quando precisa-se atualizar ou inferir uma probabilidade de determinado evento.
O processo de inferência utiliza-se de informações já existentes na própria rede, porém, para
se calcular as probabilidades, é requerida a avaliação de todos os nós pertencentes a rede.
Sendo assim, um dos principais problemas observados quando fala-se em inferência em redes
Bayesianas reside no tempo elevado necessário para se realizar uma busca exata.
Basicamente, podem ser encontrados três diferentes tipos de algoritmos voltados para
a inferência de redes Bayesianas (CASTILHO et al., 1996):
a) Exatos
Eliminação de Variáveis
Enumeração
Árvore de Junção (Junction Tree)
b) Aproximados
Amostragem Direta
Simulação de Cadeias de Markov
c) Simbólicos
23
3.2.1 Inferência exata
Inferir redes Bayesianas de forma exata consiste em um problema intratável (alta
complexidade) para redes formadas por uma grande quantidade de nodos. São citados como
exemplo de algoritmo que utilizam essa abordagem: Eliminação de Variáveis, Enumeração,
Árvore de Junção (Junction Tree).
3.2.1.1 Eliminação de variáveis
Esse algoritmo se propõe a eliminar as variáveis através da avaliação de expressões
(equações) do lado direito para o esquerdo. Armazena-se os resultados intermediários e os
somatórios são efetuados apenas para determinadas partes da expressão que dependem de
certas variáveis. Aquelas variáveis que não são ancestrais daquelas variáveis consultadas ou
evidenciadas podem ser removidas já que tornam-se irrelevantes para a pesquisa (RUSSELL;
NORVIG, 1995).
3.2.1.2 Enumeração
Nesse tipo de algoritmo parte-se do principio de que uma consulta à uma rede
Bayesiana pode ser respondida calculando-se as somas dos produtos de probabilidades
condicionais na rede (RUSSELL; NORVIG, 1995). Um detalhe importante é o fato de que
esse algoritmo efetua o somatório sobre a distribuição conjunta total sem construí-la de uma
forma explícita, tendo uma complexidade bastante alta para redes com um grande quantidade
de nodos.
3.2.1.3 Árvore de junção (Junction tree)
Tal algoritmo tem como ideia principal a formação de certos agrupamentos formados a
partir da união de nós individuais de tal forma que ao final a rede resultante seja uma
poliárvore (politree). A partir dai aplica-se um algoritmo de inferência que atua com o
objetivo de propagar as restrições. Tais restrições visam garantir que os agrupamentos
vizinhos concordem com a probabilidade a posteriori de quaisquer variáveis que eles tenham
em comum.
24
3.2.2 Inferência aproximada
Visando reduzir o tempo de execução em comparação com o algoritmos de inferência
exata, os algoritmos de inferência aproximada fazem uma aproximação das distribuições
conjuntas de algumas variáveis da rede (KOLLER et al., 2007). Tais instâncias são
denominadas amostras, que representam parte das probabilidades do problema. Esses
algoritmos são também chamados de algoritmos de Monte Carlo, pois fornecem respostas
aproximadas, cuja exatidão dependerá do número de amostras geradas.
3.2.2.1 Amostragem direta
Para uma determinada fonte de números considerados aleatórios no intervalo
compreendido entre [0, 1], acaba tornando-se simples a realização de uma amostragem de
qualquer distribuição sobre uma única variável a cada momento e de forma topológica. A
distribuição das probabilidades através da qual se extrai uma amostra do valor está atrelada
aos valores que já foram atribuídos aos pais diretos dessa variável.
3.2.2.2 Simulação de cadeias de Markov
Este método consiste em designar aos nós de evidência seus respectivos valores e
depois simular de forma estocástica a rede resultante (CASTILHO et al., 1996).
O algoritmo gera cada evento fazendo uma mudança aleatória no evento precedente.
Cada um dos estados da rede acaba sendo gerado for amostragens aleatórias de um valor em
variáveis que não são de evidência. Funciona invertendo uma variável de cada vez, mas
mantendo fixas as variáveis de evidência.
3.2.3 Inferência simbólica
Os algoritmos de inferência anteriormente descritos necessitam que a função de
probabilidade conjunta do modelo seja especificada numericamente, atribuindo-se valores
numéricos a todos os parâmetros (CASTILHO et al., 1996). Porém, nem sempre a
especificação numérica desses parâmetros é possível. Sendo assim, substitui-se os métodos
numéricos por métodos simbólicos, capazes de lidar com os parâmetros sem precisar lhes
atribuir valor.
25
Normalmente, os métodos de inferência simbólica levam a soluções que se expressam
como funções dos parâmetros. As respostas para as questões gerais podem ser dadas na forma
simbólica em função dos parâmetros e as perguntas específicas podem ser obtidas
substituindo-se os valores dos parâmetros na solução simbólica, não necessitando refazer a
propagação.
3.3 Redes Bayesianas Dinâmicas
Da mesma forma que grande parte das técnicas e algoritmos existentes até então, os
modelos de redes Bayesianas convencionais acabam apresentando certas limitações quanto ao
seu uso e aplicabilidade. Como exemplos dessa limitação pode-se citar a falta de associação
das correlações presentes entre as variáveis levando em consideração o fator tempo ou então a
falta de modelos que possibilitem aperfeiçoar o processo de aproveitamento das informações
e dos resultados obtidos (SANTANA et al., 2007).
As redes Bayesianas normais nos possibilitam analisar o comportamento dos seus
itens ao longo do tempo, porém, elas não nos permitem verificar o quanto se esta distante ou
próximo do acontecimento dos eventos previstos, não nos permitindo, dessa forma, apontar
em qual momento no tempo as ocorrências serão inferidas. Existe, porém, um outro tipo de
redes, denominadas redes Bayesianas dinâmicas (DBN), que compreendem redes Bayesianas
que têm como objetivo representar um modelo probabilístico temporal (GHAHRAMANI ,
1998; RUSSELL; NORVIG, 1995; SANTANA et al., 2007).
Na figura 3 é apresentado um modelo probabilístico temporal, onde em cada instante
de tempo (t), St representa um certo conjunto de variáveis de estado não observadas, sendo
elas discretas ou contínuas e Et representa um determinado conjunto que compreende as
variáveis de evidência observadas, sendo discretas ou contínuas.
Figura 3 - Estrutura de funcionamento de uma rede Bayesiana dinâmica
Fonte: Ghahramani, 1998
26
Devido ao fato das redes Bayesianas Dinâmicas serem um subtipo das redes
Bayesianas convencionais, é possível a aplicação dos mesmos métodos de inferência
probabilística. Contudo, por questões relativas à eficiência, utiliza-se, comumente, um
algoritmo de inferência aproximada denominado particle filtering (RUSSELL; NORVIG,
1995), sendo esse uma versão modificada do algoritmo conhecido como likelihood weighting.
Da mesma forma, as distribuições probabilísticas são aprendidas a partir dos dados
disponíveis. Quando se conhece a estrutura da rede e sendo todas as variáveis observáveis, o
aprendizado na rede é feito pela maximização da verossimilhança (Maximum Likelihood)
(RUSSELL; KANAZAWA, 1995). Porém, se a estrutura da rede for conhecida, mas existirem
variáveis não observáveis, opta-se por utilizar o método denominado Expectation
Maximization (MCLACHLAN; KRISHNAN, 2008) para o aprendizado da rede. Tanto um
método quanto o outro utilizam-se internamente de inferência probabilística.
Algo importante a ser mencionado é que o termo “dinâmico” nesse contexto significa
que o processo é gerado por um sistema dinâmico e não, necessariamente, que a rede
Bayesiana sofra qualquer alteração ao longo do tempo.
A seguir são apresentados a seguir dois modelos probabilísticos temporais bastante
comuns quando tratamos de redes Bayesianas dinâmicas.
3.3.1 Modelos Ocultos de Markov
Pode-se definir os Modelos Ocultos de Markov como sendo um processo duplamente
estocástico, com um processo estocástico não visível, o qual não é observável (de onde se
origina o nome Oculto), porém podendo ser observado por meio de outro processo estocástico
que produz sequências de observações (RABINER, 1990).
Um Modelo Oculto de Markov (Hidden Markov Model) diz respeito também à um
modelo probabilístico temporal no qual o estado do processo (St) é descrito através de uma
única variável aleatória discreta, onde os possíveis valores dessa variável são os possíveis
estados do mundo, dado o contexto (RUSSELL; NORVIG, 1995).
Considerando que os dados de St não podem ser visualizados a partir de dados
provenientes de treinamento, ocorre que a estimativa das probabilidades envolvidas P(St+1|St),
P(Et|St) e P(S0) normalmente é obtida através do algoritmo de Expectation Maximization
(GHAHRAMANI , 1998). Se considerarmos tanto St como Et = (Et,1, Et,2, ..., Et,m) como sendo
dados observados durante o treinamento, tais probabilidades poderiam ser calculadas através
de contagem:
27
P(S0) = N(S0) / N
P(St+1 | St) = N(St+1 , St) / N(St) = N(St+1 , St) / (Σst+1 N(st+1 , St))
P(Et,j | St) = N(Et,j , St) / N(St) = N(Et,j , St) / (Σet,j N(et,j , St)) , 1 ≤ j ≤ m
Onde N é descrito como sendo o número total de exemplos utilizados para
treinamento, N(.) é o número de exemplos para treinamento possuindo valores distintos para
uma variável, e N(., .) é o número de exemplos para treinamento com valores distintos para
um determinado conjunto de variáveis.
3.3.2 Modelos de Filtro de Kalman
Modelos de Filtro de Kalman são normalmente utilizados quando se deseja considerar
as dependências entre as variáveis, adicionando também um raciocínio probabilístico
(KALMAN, 1960). Tal método foi desenvolvido por Rudolf Kalman com o propósito
principal de mensurar grandezas realizadas ao longo do tempo, gerando resultados que
buscam se aproximar dos valores reais daquelas grandezas medidas e dos valores associados.
Esse tipo de modelo de filtragem emprega distribuições Gaussianas lineares, sendo o
procedimento de filtragem realizado pelo filtro de Kalman.
Abaixo, um exemplo das equações:
a) equação das observações: Et = FtSt + νt νt ~ N[0, Vt]
b) equação do estado: St = GtSt-1 + ωt ωt ~ N[0, Wt]
Ou de forma análoga:
P(et | st) = N[Ftst, ∑et](et)
P(st | st-1) = N[Gtst-1, ∑st](st)
Onde:
∑et = Ft.Var(St).Ft' + Vt
∑st = Gt.Var(St-1).Gt' + Wt
com a distribuição Gaussiana multivariada dada por ( ) ( )( )µxΣµx
xΣµ−−− −
⋅=1'
2
1
)](,[ eN α sendo α
uma constante de normalização.
28
A transição (St-1 | e1:t-1) → (St | e1:t) representa a atualização das variáveis de estado pelo procedimento de filtragem (neste caso, o filtro de Kalman). Sendo conhecida a distribuição de (St-1 | e1:t-1), a transição inicial:
(St-1 | e1:t-1) → (St | e1:t-1)
é realizada por:
∫−
−−−−− ⋅=1
1111111ts
t:tttt:tt ds)|eP(s)|sP(S)|eP(S
Sendo a transição final (St | e1:t-1) → (St | e1:t) feita por:
)e|P(S)S|P(eα)e|P(S 1:t1ttt:t1t −⋅⋅= onde é α uma constante de normalização.
29
4 ESTUDOS RELACIONADOS
Buscando usufruir da capacidade das redes Bayesianas em fazer análises e efetuar
predições em situações em que a incerteza e a pouca quantidade / qualidade das informações
disponíveis nem sempre é precisa, diversos pesquisadores têm desenvolvido trabalhos
voltados para as mais diversas áreas correlatas ao desenvolvimento de software e gerência de
projetos. Nas subseções seguintes procurou-se dividir as referências que compõem o estado da
arte apresentado dentre as principais áreas da gerência e desenvolvimento de software. Optou-
se por essas referências por se tratarem de periódicos e artigos científicos de autores
amplamente conhecidos em assuntos relacionados ao tema proposto. Além disso, deu-se
preferência por materiais publicados recentemente e que foram publicados em congressos,
seminários e eventos conceituados no meio acadêmico.
4.1 Gerenciamento de riscos
Dentre as áreas de aplicação de redes Bayesianas que vêm sendo estudadas está o
gerenciamento dos riscos em projetos de software (Al-ROUSAN et al., 2008; JEET et al.,
2010; XIAOCONG; LING, 2010) devido ao alto grau de incerteza envolvido neste tipo de
projeto. Al-Rousan et al. (2008) propõe uma arquitetura padrão para a identificação de riscos
denominada RIAP (Risk Identification Pattern model) que visa aprimorar o gerenciamento de
riscos em projetos web, levando em consideração as peculiaridades do desenvolvimento para
este tipo de plataforma.
A utilização de redes Bayesianas como componente principal do modelo proposto fez
com que fosse possível representar todos os relacionamentos entre os fatores de risco
presentes em projetos web, além de identificar a influência direta entre características que são
intrínsecas a aplicações web e os fatores de risco. A utilização do modelo facilitou a
identificação e categorização dos fatores de risco nas respectivas características do domínio
da web, e também possibilitou uma análise detalhada dos fatores de risco obscuros.
Desvios de cronograma em projetos de software ocorrem, principalmente, devido a
uma análise pobre dos fatores de risco e seu gerenciamento. Sendo assim, Jeet et al. (2010)
propõem a criação de uma ferramenta denominada MaSO (Management of Schedule
Overrun), que é baseada na teoria do gerenciamento de risco e utiliza diagramas de influência,
que são representações gráficas que visam demonstrar as relações causais entre os fatores e
que atualmente são utilizadas como reforço para as redes Bayesianas. A abordagem se dá
30
através da integração do impacto dos fatores de risco com opinião de especialista e de base de
dados existentes que armazenam a probabilidade de ocorrência dos fatores de risco.
Já Xiaocong e Ling (2010) demonstram que fatores de risco possuem uma estreita
associação uns com os outros e métodos normais de análise de risco não conseguem
demonstrar esse tipo de associação corretamente. Sendo assim, eles propõem uma abordagem
que combina as vantagens de diferentes métodos, propondo um novo sistema de suporte a
decisão e gerenciamento dos riscos baseado em redes Bayesianas. A rede Bayesiana começa
com a causa dos riscos e decompõem os eventos de riscos etapa por etapa em eventos
elementares chamados fatores de risco, que são simples, probabilísticos, independentes e
facilmente reconhecidos. Esses fatores de risco são conectados em um grafo acíclico dirigido
de acordo com o relacionamento de causa e efeito entre eles, então as probabilidades são
inseridas nos nodos raiz e as probabilidades condicionais dos nodos não-raíz para construir
uma rede Bayesiana. O sistema proposto pode avaliar riscos automaticamente ou reavaliar
riscos em tempo real após inserir novas informações através da mudança de probabilidade dos
fatores de risco que aconteceram.
4.2 Melhoria de processos
Redes Bayesianas podem ser utilizadas também para auxiliar na melhoria de um
determinado processo dada a sua natureza (BIBI et al., 2010; KHOMH et al., 2011). Khomh
et al. (2011) utilizou redes Bayesianas no auxilio da identificação de antipadrões de
desenvolvimento, estendendo-se, assim, para o processo de melhoria da avaliação de
qualidade de um software. A abordagem denominada BDTEX (Bayesian Detection Expert)
utiliza redes Bayesianas ao invés da abordagem adotada pelos modelos clássicos que se
baseiam em regras. Uma das principais vantagens é a capacidade deste tipo de rede lidar com
a incerteza, além do fato de poderem ser calibradas ao longo do tempo através da utilização de
dados históricos ou pela inclusão direta de dados pelos próprios especialistas em qualidade.
Sendo assim, Bibi et al. (2010), dentro da ideia de auxiliar na melhoria dos processos
de desenvolvimento, propõem uma abordagem para aperfeiçoar o processo de
desenvolvimento de software em pequenas e médias empresas (small / medium enterprise)
através de um estudo de caso e da adoção de uma metodologia que se utiliza de redes
Bayesianas para representar os relacionamentos entre implementação, produto e métricas de
processo, além do impacto no esforço de desenvolvimento. Tal metodologia pode ser usada
para análises de post mortem a fim de obter algumas conclusões, como por exemplo: quais
31
projetos demandam maior esforço, tempo ou pessoas para ser completado. Essa informação é
útil para alguém que é forçado a criar predições de estimativas. Tais análises podem oferecer
indicadores do potencial de sucesso ou risco para projetos em andamento.
4.3 Predição de falhas
Outro aspecto bastante importante e que está relacionado diretamente com o
desenvolvimento de software diz respeito à qualidade. Fenton et al. (2007) faz uma revisão
sobre a utilização de redes Bayesianas na predição de defeitos em software e confiabilidade.
É proposta uma abordagem que permite incorporar fatores de processos causais bem como
combinar medidas quantitativas e qualitativas, superando, assim, algumas das bem conhecidas
limitações dos métodos tradicionais de métricas de software. A abordagem proposta foi
utilizada por organizações como Motorola, Siemens e Philips que relataram predições
precisas. Tal abordagem propõe inferência usando discretização, que é o processo de
transformação de uma variável contínua em uma variável discreta, diminuindo a necessidade
de poder computacional de processamento e o tempo necessário para a construção da rede
Bayesiana (CERQUIDES, 1997; WANG, 2000; YING; WEBB, 2009). Previsões
extremamente exatas são agora possíveis com apenas um aumento mínimo de tempo de
computação.
De acordo com Schulz et al. (2010, p. 1) “[...] defeitos em software são provenientes
de diferentes fases do desenvolvimento, tendo diferente impacto no esforço geral de correção
de defeitos”. Para reduzir o esforço de correção de defeitos é importante avaliar cada fase do
desenvolvimento com suas características específicas e foco na mudança de defeitos entre as
fases. É proposto um modelo focado, principalmente, em esforço dinâmico de correção de
esforço, mudando de uma fase de desenvolvimento para a outra. Isso reflete o aumento de
custo de correção de defeitos os quais são introduzidos no início, mas encontrados em fases
tardias do desenvolvimento. A técnica de modelagem utilizada no estudo é uma rede
Bayesiana na qual, conforme visto anteriormente possui três importantes capacidades: reflete
os relacionamentos causais, combina opinião de especialista com dados empíricos e incorpora
a incerteza. O modelo desenvolvido, denominado DCFM (Defect Cost Flow Model), foi
previamente calibrado com dados empíricos provenientes de projetos passados que foram
desenvolvidos na Robert Bosch GmbH. A análise dos cenários de avaliação confirma que o
modelo DCFM incorpora corretamente relacionamentos qualitativos e quantitativos
32
conhecidos. Devido às suas estruturas causais, pode ser usado intuitivamente pelos usuários
finais.
4.4 Estimativa de esforço
Estimar esforço para projetos de software sempre foi uma tarefa bastante complexa
por levar em consideração em sua concepção uma série de fatores, muitos dos quais são
externos ao projeto o qual se deseja efetuar a estimativa. A necessidade de estimativas mais
precisas para projetos de software fez com que diversos pesquisadores passassem a investigar
novas formas de elaborar essas estimativas, sobretudo, levando em consideração as relações
de influências que são exercidas entre fatores que compõem o processo de desenvolvimento
de software, além das particularidades de cada tipo de desenvolvimento.
Dentre os estudos realizados, destaca-se o estudo comparativo entre modelos de redes
Bayesianas voltados para estimativa de esforço em projetos web feito por Mendes e Mosley
(2008), que apresenta os resultados de uma investigação onde oito modelos de redes
Bayesianas foram comparadas quanto a sua precisão em estimar esforço para projetos web.
Quatro modelos foram gerados automaticamente através de ferramentas específicas e os
outros quatro eram modelos híbridos de redes Bayesianas, construídos usando grafos causais
eleitos por especialistas de domínio (um diretor de uma companhia web estabelecida na Nova
Zelândia) com probabilidades “aprendidas” automaticamente a partir de conjuntos de
treinamentos. Os resultados dos testes efetuados mostraram que
construir redes bayesianas orientadas a dados e híbridas que incluem grafos causais complexos podem ser uma abordagem adequada se estivermos usando um grande conjunto de dados, pois fornecerá dados de projetos que representam uma ampla gama de possíveis combinações de estados dos pais e, portanto, probabilidades mais realísticas (MENDES; MOSLEY, 2008, p. 734).
Outro fator observado foi que o tamanho do time de desenvolvimento tem um efeito causal
direto no uso de um processo documentado e estar envolvido em um programa de melhoria de
processos tem um efeito causal direto no uso de métricas ao longo de um projeto, além disso,
o número total de páginas web tem um efeito causal direto no esforço total requerido para
desenvolver uma aplicação web.
As estratégias típicas de otimização de custo em relação ao esforço gasto na medição
da qualidade tendem a ser otimizados localmente. Por exemplo: cada fase do desenvolvimento
é otimizada separadamente no seu próprio domínio. Contrastando com isso, o modelo DCFM
33
demonstra que mesmo os custos onerosos de medidas de qualidade são saldados quando a
estimativa de custo de defeitos de uma funcionalidade específica é considerada.
4.5 Estimativa de custos de manutenção
Além das estimativas de custo do projeto em si, outra dificuldade presente em
praticamente todos os projetos, seja a curto ou à médio prazo, diz respeito ao gerenciamento
de manutenção do software. A tarefa de gerenciar a manutenção raramente é uma tarefa
precisa, devido às incertezas com a descrição dos recursos e serviços. As incertezas presentes
no processo de manutenção são difíceis de serem descobertas durante a execução do projeto.
Além disso, gerentes de projetos precisam decidir como reconfigurar o plano de projeto
quando seu cronograma falha. Questões como: "Quantos recursos devem ser acrescentados a
fim de finalizar um projeto atrasado no prazo?" ou "Nós podemos implementar o sistema em
um curto tempo sem perder seus requisitos de qualidade?" tornam-se corriqueiras quando
ocorrem falhas no cronograma, porém, esse tipo de abordagem é extremamente humana e
baseada, normalmente em experiências pessoais, sendo muito subjetiva.
Para auxiliar gerenciamento dos atrasos em projetos de manutenção, Sanchez (2008)
propõe uma estrutura de representação do conhecimento baseada em redes Bayesianas para
controlar atrasos em projetos de manutenção, através de experiência de especialistas e uma
ferramenta correspondente para ajudar no gerenciamento de projetos de software.
O objetivo principal do modelo é a possibilidade de calcular atrasos em projetos de
manutenção durante sua execução. Uma rede Bayesiana irá associar valores de probabilidades
com os recursos de desenvolvimento do software e seus relacionamentos. A rede Bayesiana
irá então representar o conhecimento de especialistas no domínio da aplicação e poderá ser
utilizada também para armazenar a experiência de desenvolvimento a fim de desenvolver
novos sistemas.
A primeira etapa da construção da rede Bayesiana é o reconhecimento no contexto no
qual o gerenciamento de risco pode ser aplicado no desenvolvimento de software. O conjunto
de fatores que são reconhecidos pelo gerenciamento de riscos pode variar desde um único
elemento, como a complexidade de manutenção, até a um enorme conjunto, incluindo
elementos objetivos e subjetivos. Uma vez definidas as variáveis relevantes para o
gerenciamento dos riscos, pode-se estabelecer como elas são relacionadas, ou seja, como as
variáveis podem influenciar outras quando uma evidência é obtida.
34
Além de uma rede Bayesiana para o gerenciamento e identificação dos riscos, uma
outra rede é gerada para identificar a propagação dos atrasos. Novamente, a primeira etapa é
identificar as variáveis relevantes para atrasos em projetos que possam ter seus valores
medidos. Uma vez que estejamos trabalhando sobre os possíveis atrasos de execução em
projetos, a escolha das variáveis baseia-se em tarefas comuns realizadas no processo de
manutenção. Para os gerentes de projeto, no entanto, usar redes Bayesianas diretamente não é
muito intuitivo, sendo assim, foi proposta uma ferramenta para auxiliar no gerenciamento de
projetos de uma forma mais intuitiva. A ferramenta engloba as redes Bayesianas de riscos de
manutenção e de propagação de atrasos. O usuário primeiro fornece o número de serviços no
projeto de manutenção juntamente com as suas definições, implementações e complexidade
de testes. A partir disso, a ferramenta pode calcular o número de dias para completar cada fase
do projeto. Além disso, a experiência das pessoas envolvidas no sistema e na plataforma deve
ser definida tanto quanto a complexidade de manutenção e se o sistema é bem documentado
ou não. A partir dessas informações reunidas, a manutenção dos riscos poderá ser calculada.
35
5 REDES BAYESIANAS COMO FERRAMENTA DE APOIO À MONIT ORAÇÃO DE
PROJETOS
Monitorar projetos de software utilizando-se de mecanismos para detecção de
mudanças durante o andamento do projeto colabora para que eventos inesperados não
aconteçam sem conhecimento prévio. O objetivo principal de qualquer proposta de
monitoração de projetos é sempre controlar para que o mesmo se mantenha bem próximo da
projeção inicial, sobretudo no que diz respeito às estimativas e planejamento. E que, caso isso
não ocorra, se possa efetuar alterações com o intuito de se adaptar a nova realidade imposta da
forma menos traumática e mais rápida possível.
Conjuntos de software designados para este fim ajudam os gerentes de projetos a
visualizar o andamento do projeto como um todo, verificando, principalmente como anda a
relação entre aquilo que foi efetivamente orçado e prometido e aquilo que está sendo
executado. Porém, se observa atualmente sérios problemas para se monitorar e controlar
projetos de forma correta, mesmo em ocasiões em que se utiliza ferramentas designadas para
este fim.
Se faz importante mencionar aqui que, diferentemente de outras abordagens utilizadas
para efetuar estimativas que utilizam de uma medida paramétrica e única, tais como a
abordagem adotada pelo COCOMO (BOEHM et al., 2000) e a Análise de Pontos de Função
(GARMUS; HERRON, 2001), a utilização de rede Bayesianas nos sugere um valor
estatístico (aproximado) e não definitivo.
Este capítulo visa apresentar cada um dos softwares e tecnologias utilizadas para
compor o modelo de monitoramento e controle proposto, bem como o motivo pelo qual foram
escolhidos. Após isso, é apresentado um modelo conceitual da solução proposta, onde
objetiva-se apresentar como se dará a interação dentre as ferramentas que compõem a
solução, bem como as características e detalhes da implementação.
5.1 WebAPSEE
O WebAPSEE (LIMA et al., 2006a) é um software desenvolvido para auxiliar na
modelagem e execução de processos de software. Seu surgimento foi o resultado de diversos
projetos de pesquisa desenvolvidos pelo LABES-UFPA e que tomou como base principal a
experiência já adquirida no desenvolvimento de soluções voltadas para problemas críticos
relacionados com a gerência e execução de processos de software. Seu objetivo fundamental
36
era prover uma solução flexível, multiplataforma, que se utilizasse de uma arquitetura
facilmente integrável e que pudesse ser atualizada e aperfeiçoada continuamente através da
disponibilização do seu código fonte na forma de software livre.
O WebAPSEE tem, como suas principais características:
a) possibilidade de modelar os processos de forma visual, através de uma
linguagem de modelagem de processos;
b) permite que sejam feitas mudanças dinâmicas no processo, a execução de
processos que ainda estejam incompletos e a alocação de pessoas e recursos
utilizando-se de políticas;
Atualmente, existem duas versões do WebAPSEE: a versão de código aberto, também
chamada de WebAPSEE OPEN e uma versão desenvolvida por uma empresa privada que foi
denominada WebAPSEE PRO. Essa versão possui uma série de novas funcionalidades em
relação à versão de código aberto.
A versão utilizada para a composição do modelo proposto neste trabalho foi a versão
OPEN 1.5, datada de 15/09/2009. Essa era a versão mais recente disponibilizada e
comercializada por uma empresa particular.
A opção por esta ferramenta de modelagem de processos para compor o modelo de
monitoração de projetos aqui proposto deve-se a sua facilidade de uso, o fato dela se utilizar
de tecnologias conhecidas, como banco de dados MySQL e linguagem de programação Java,
além de possuir uma série de funcionalidades adicionais em relação a versão gratuita.
Os requisitos para instalação e funcionamento pleno da ferramenta são os seguintes:
a) o JRE – Java Runtime Environment (Máquina Virtual Java);
b) o MySQL – Sistema de Gerenciamento de Banco de Dados;
c) o CVS – Concurrent Version System (Sistema de Gerenciamento de Versões)
O WebAPSEE utiliza-se de um linguagem visual própria para modelagem de processos,
denominada WebAPSEE-PML (LIMA et al., 2006b). Essa linguagem foi adotada tomando
como base a especificação formal com abordagem de gramáticas de grafos, sendo que o
ambiente como um todo segue o paradigma denominado processo orientado a atividades,
onde cada um dos processos é devidamente descrito como sendo uma coleção de atividades
que seguem uma ordenação parcial.
Dentro da mecânica de modelagem utilizada pelo WebAPSEE, os componentes mais
importantes são as atividades, aqui apresentadas como sendo ações realizadas por
desenvolvedores ou agentes de software, as conexões, que são responsáveis por determinar as
relações temporais e de sincronização entre as atividades, e os artefatos, que são todos
37
aqueles itens de software presentes em sistemas de controle de versão que são utilizados no
decorrer dos processos.
Na figura 4 é mostrado um exemplo de um processo modelado na ferramenta
WebAPSEE. O segmento inicial do processo em questão é aquele que está mais a esquerda da
figura (Elaborar termos de abertura do projeto). Já o segmento final contemplando a última
atividade do processo é aquele que encontra-se mais a direita (Realizar estimativas).
Figura 4 – Processo modelado no WebAPSEE
Fonte: autoria própria, 2011
Conforme mostrado na figura acima, cada um dos elementos que compõem um
processo modelado, possuem uma função distinta. Segue abaixo a legenda com o significado
de cada um dos elementos do processo exemplificado:
a) diz respeito a dependência entre as atividades. A tarefa que está a direita de
end_start só será iniciada após o término da tarefa que está a esquerda;
b) são os agentes que participam do processo. Normalmente diz respeito aos papéis
dentro do projeto, tais como o gerente de projetos, analistas e desenvolvedores.
Indica quais tarefas ficarão sob responsabilidade de cada um;
c) corresponde as atividades propriamente ditas, que são classificadas de acordo
com cada um dos possíveis status. Conforme a figura 4, as atividades com o
status identificado como finished são aquelas que já foram finalizadas, aquelas
identificadas como Paused estão paradas e aguardando sua retomada, as
38
identificadas como Instantiated são aquelas tarefas que já foram instanciadas. E,
finalmente, aquelas que ainda não possuem nenhuma identificação de status são
todas aquelas que ainda não foram iniciadas. Percebe-se que as atividades
possuem também um identificador “N”ou “D”. O identificador “N” significa que
trata-se de uma atividade normal. Já o identificador “D” significa que a atividade
em questão é subdividida em outras atividades.
d) compreende todos os artefatos que serão criados durante o desenrolar do
processo e que servirão como produto de saída de determinadas atividades e, em
alguns casos, servirão de entrada para outras;
e) são os recursos destinados a cada atividade. Como exemplo, pode-se citar a
quantidade de computadores que serão necessários para a execução da tarefa de
gerenciamento.
A figura 5 mostra a visualização que um agente que esteja participando do processo
modelado tem em relação às tarefas que estão sob responsabilidade dele.
Figura 5 – Interface de acesso de um agente do processo no WebAPSEE
Fonte: autoria própria, 2011
Conforme demonstrado na figura acima, a interface disponível para o agente
participante do processo modelado é composta, basicamente, por quatro áreas:
39
a) uma listagem contendo as tarefas que estão sob sua responsabilidade, onde é
possível verificar o status das mesmas, a quantidade de horas trabalhadas em
cada tarefa, a data em que começou a ser executada e a data de finalização, para
aquelas tarefas que já foram finalizadas;
b) detalhamento maior sobre cada uma das tarefas. Nessa área é possível verificar
sobre o que se trata a tarefa, qual foi o inicio estimado, o início efetivamente
realizado, além do término estimado, realizado e quem são os agentes que
participam da tarefa. Nas demais guias dessa área é possível verificar quais são
os artefatos de entrada e saída da tarefa em questão, além dos registros que já
foram feitos nela (logs);
c) nesta área é possível visualizar o processo atual, bem como visualizar todos os
processos os quais o agente em questão está participando e suas respectivas
tarefas em cada um desses processos;
d) são exibidos nessa área os demais agentes que estão participando da mesma
tarefa que está sendo visualizada. Tais agentes terão disponível uma interface
igual a está onde, da mesma forma, poderão acompanhar suas próprias
atividades.
5.2 A modelagem das redes Bayesianas
Construir e modelar redes Bayesianas tornou-se uma tarefa simples atualmente, tendo
em vista a quantidade considerável que se tem disponível de ferramentas com esse objetivo.
Após uma detalhada análise sobre qual seria a ferramenta mais viável para ser utilizada
conjuntamente com o modelo aqui proposto, destacaram-se duas: o Netica1, desenvolvido pela
Norsys Software Corp., e o GeNIe2, desenvolvido pelo Decision Systems Laboratory, da
Universidade de Pittsburgh. A seguir são apresentados alguns dos aspectos mais importantes
em relação a cada uma dessas ferramentas. Aspectos esses que influenciaram na decisão de
optar por elas.
1 http://www.norsys.com/netica.html
2 http://genie.sis.pitt.edu/
40
5.2.1 Netica
O Netica é largamente utilizado em diversas pesquisas e trabalhos acadêmicos e possui
uma API desenvolvida para ser utilizada com diversas linguagens de programação, tais como:
Java, C, C#, Visual Basic, C++, Matlab e CLisp. Oferece suporte aos principais sistemas
operacionais atualmente utilizados, como: Microsoft Windows
95/98/Me/NT4/2000/XP/Vista, Linux, Sun Sparc, Mac OS, Silicon Graphics e DOS
(NETICA, 2003).
Atualmente, o Netica encontra-se disponível em duas versões: uma versão gratuita e
uma versão paga, sendo que o preço dessa versão paga varia de acordo com o ambiente de
utilização, possuindo um preço para uso pessoal ou educacional e outro para uso comercial.
Juntamente com a ferramenta são disponibilizados mais de uma dezena de exemplos
mostrando o funcionando de diferentes tipos de redes Bayesianas. Além disso, o próprio
website do fabricante possui uma vasta documentação que auxilia, principalmente, nos
primeiros passos no uso da ferramenta.
Ao utilizar a versão gratuita da ferramenta, a primeira limitação que se percebe e que
acaba comprometendo sua utilização, dependendo da aplicabilidade, diz respeito à quantidade
de nodos possíveis em uma mesma rede Bayesiana: dependendo do tamanho da rede criada, o
usuário fica impossibilitado de salvá-la ou impossibilitado de abri-la, no caso de uma rede já
existente. Atualmente, a versão gratuita do Netica está limitada a utilização de redes com no
máximo 60 nodos. Trata-se de um mecanismo adotado para fazer com que a versão gratuita
seja utilizada apenas para fins didáticos com exemplos simples. Contudo, apesar desta
limitação, tanto a versão gratuita quanto a versão comercial da ferramenta possuem o mesmo
conjunto de funcionalidades no que diz respeito à montagem e cálculos probabilísticos da
rede.
A figura 6 mostra um exemplo de rede Bayesiana que acompanha o Netica:
41
Figura 6 – Interface do Netica apresentando uma rede Bayesiana
Fonte: autoria própria, 2011
5.2.2 GeNIe
O GeNIe (Graphical Network Interface) é um software utilizado para criar modelos
teóricos de forma intuitiva através de uma interface gráfica (GENIE, 1998).
O papel principal desempenhado pelo GeNIe é atuar como interface gráfica para o
SMILE, que nada mais é que o mecanismo (engine) de inferência Bayesiana desenvolvido
pelo Decision Systems Laboratory, da universidade de Pittsburgh, em meados de 1998.
Também em meados de 1998 foi lançada a versão 1.0 do GeNIe. Algum tempo depois, com a
ajuda de diversos usuários desta primeira versão do programa, que enviaram diversas
sugestões e relataram suas experiências com o uso da ferramenta, foi lançada a versão 2.0 do
GeNIe com uma nova interface gráfica, tornando-se muita mais intuitiva e fácil de usar em
comparação com a antiga versão.
Segundo o site da ferramenta, atualmente as funcionalidades que merecem ser
destacadas, fundamentalmente, são as seguintes:
a) suporte ao gerenciamento de casos de diagnóstico;
b) suporte para lidar com os custos de observação dos nodos;
c) compatibilidade com outros softwares para redes Bayesianas. Oferece suporte
para os principais tipos de arquivos, tais como arquivos gerados pelo Hugin,
Netica e Ergo;
42
d) integração total com o Microsoft Excel: ações como recortar e colar dados de
planilhas e visualizar esses dados no GeNIe são plenamente possíveis;
e) possibilidade de abrir diversas redes e juntar pedaços de uma rede com outra;
f) suporte a nodos probabilísticos com distribuições do tipo General, Noisy
OR/MAX e Noisy AND;
g) utiliza a engine do SMILE. É possível que modelos sejam desenvolvidos no
GeNIe e criar uma interface customizada para elas usando o SMILE;
h) editor gráfico para criar e modificar modelos de rede;
O SMILE (Structural Modeling, Inference, and Learning Engine) é uma biblioteca de
classes desenvolvidas em C++ com o objetivo de implementar modelos probabilísticos de
forma gráfica e modelos de decisão teóricos, como por exemplo: redes Bayesianas, diagramas
de influência e modelos estruturais de equações. A API (Application Programming Interface)
do SMILE nos permite manipular modelos gráficos e utilizá-los para raciocínio probabilístico
e decisão sob a incerteza. O SMILE é distribuído como uma DLL (Dynamic Link Library),
além disso, existem wrappers para .NET (SMILE.NET), SMILEX (Active-X), jSMILE (Java).
Abaixo, na figura 7, é apresentada a interface gráfica do GeNIe:
Figura 7 – GeNIe demonstrando um modelo de rede Bayesiana
Fonte: autoria própria, 2011
Utilizou-se o software GeNIe para modelar as redes Bayesianas utilizadas durante a
avaliação do modelo proposto, devido a sua facilidade de utilização e pelo fato da sua versão
gratuita não possuir restrições em relação ao tamanho máximo possível para uma rede
43
Bayesiana. Contudo, para situações em que se faz necessário trabalhar com equações
matemáticas para verificar o progresso de um determinado componente da rede em relação a
um determinado limite, o software Netica é muito mais eficiente e de fácil entendimento. Tal
funcionalidade existe também no GeNIe, porém, verificou-se que sua documentação a esse
respeito ainda é bastante limitada e, ao que tudo indica, apesar da funcionalidade estar
presente na ferramenta, seu desenvolvimento ainda não foi finalizado devido aos diversos
problemas encontrados durante os testes desta funcionalidade nas avaliações do modelo aqui
apresentado.
5.3 Modelo conceitual da solução proposta
O modelo de solução cuja sua concepção é o objetivo deste trabalho tem como objetivo
principal auxiliar o gerente de projetos durante a fase de monitoramento e controle de
projetos, visando efetuar projeções futuras relativas ao estado do processo desenvolvido
utilizando-se de dados probabilísticos resultantes de informações sobre o próprio processo o
qual se está monitorando e proveniente de dados de projetos anteriores.
Comumente, um processo de software quando modelado adequadamente possui um
conjunto de tarefas a serem executadas, um prazo previamente definido para a finalização de
cada uma dessas tarefas e um agente responsável. A partir disso são definidas determinadas
tarefas que, normalmente, terão como produto resultante de sua finalização um artefato, seja
ele um artefato documental ou de codificação. Alguns artefatos gerados servirão de entrada
para o inicio das tarefas seguintes e, mesmo que não existam artefatos, determinadas tarefas
só poderão ser iniciadas se a tarefa anterior a ela estiver sido finalizada devido a relação de
dependência entre elas.
O modelo aqui proposto é formado, fundamentalmente, pela interação de três
componentes: uma ferramenta de modelagem de processos, uma ferramenta para modelagem,
inferência e visualização de redes Bayesianas e uma base de dados. Na ferramenta de
modelagem de processos será definido o processo o qual se deseja monitorar, com todas as
suas tarefas, pré-requisitos e artefatos. Este processo será modelado de acordo com as
principais tarefas definidas pela metodologia RUP (Rational Unified Process) for Small
Projects. O RUP é um processo de engenharia de software que oferece uma abordagem
disciplinada de atribuição de tarefas e responsabilidades dentro de uma organização que
desenvolve software. Seu principal objetivo é garantir o desenvolvimento de software em alta
qualidade e que atenda as necessidades de todos os seus usuários finais, respeitando sempre o
44
cronograma e o orçamento previsto (JACOBSON et al., 1999; KRUCHTEN, 2003). Na
ferramenta de modelagem de redes Bayesianas será carregado um modelo de rede que tenha
características relativas a um dos aspectos que se deseje monitorar no processo (tempo ou
custo, por exemplo). A base de dados utilizada será composta por dados simulados com o
objetivo de representar projetos anteriores que possuam características semelhantes com o
projeto que está sendo modelado. Tais dados serão utilizados para alimentar as probabilidades
da rede durante seu treinamento.
A figura 8 demonstra a composição do modelo graficamente.
Figura 8 – Modelo conceitual – configuração
Fonte: autoria própria, 2011
Conforme vai se dando a execução do projeto, a rede Bayesiana será atualizada e
utilizada para monitorar aspectos relevantes como tempo, custo e qualidade, de acordo com a
característica selecionada. O estado atual do processo monitorado será informado à rede para
que esta possa identificar as evidências e realizar novas estimativas posteriormente. A
sistemática de funcionamento é demonstrada na figura 9.
45
Figura 9 – Modelo conceitual - monitoramento e controle
Fonte: autoria própria, 2011
A ideia é que seja possível visualizar, através da rede Bayesiana já atualizada com os
dados do estado atual do processo em execução, o impacto que as mudanças até então
ocorridas no processo (alteração no prazo de alguma tarefa e alteração de custo, por exemplo)
terão no restante do andamento do mesmo. Tal observação só é possível graças às predições
probabilísticas efetuadas pela própria rede Bayesiana de acordo com as evidências obtidas do
processo.
5.3.1 Apresentação dos cenários
Para melhor compreensão do modelo de monitoramento e controle proposto, se faz
necessária a apresentação e a análise dos cenários onde o modelo atuará, bem como observar
as pré e pós-condições requeridas para o seu correto funcionamento.
Na figura 10 é exemplificado o cenário 1. Esse cenário trata da configuração da rede
Bayesiana, requerida para o correto funcionamento do modelo como um todo.
Como pré-requisitos, necessita-se que previamente já se tenha um processo
devidamente modelado no WebAPSEE e que este já tenha sido iniciado; além disso, a
topologia da rede já deve estar definida de acordo com o aspecto o qual se deseje monitorar
no processo (tempo, custo, qualidade, dentre outros). A partir disso, apresenta-se o principal
mecanismo do modelo a ser implementado (centro da figura 10): trata-se de uma interface
web através da qual será possível selecionar dados relevantes do processo em execução de
acordo com o aspecto o qual se deseje monitorar. Por exemplo: considerando que se deseje
monitorar o processo sobre o aspecto do tempo, seria possível selecionar itens como
46
“quantidade de agentes envolvidos” e “total de horas restantes” e assim por diante. A partir
disso, os dados selecionados serão extraídos do processo em execução. Após a extração destas
informações é gerada automaticamente uma tabela contendo as informações extraídas do
processo atual. Através da observação desta tabela será possível identificar as informações
que serão utilizadas para configurar as evidências na rede Bayesiana, que é a pós-condição do
cenário 1.
Figura 10 – Cenário 1 – configuração da rede Bayesiana
Fonte: autoria própria, 2011
O cenário 2 diz respeito ao processo de monitoração efetivamente. Como pré-requisito
para o correto funcionamento do cenário 2 se tem o fato do processo estar em execução e a
rede Bayesiana estar configurada. Ou seja, a execução do cenário 2 começa exatamente no
ponto onde o fluxo do cenário 1 é finalizado.
Conforme a figura 11, inicialmente se faz necessário identificar as mudanças de estado
no processo que está em execução. Afinal, conforme o processo vai andando, novas tarefas
vão sendo concluídas, outras vão sendo atrasadas e assim por diante. Logo, o modelo
proposto tem que estar preparado para perceber essas alterações. Sendo assim, foi
desenvolvido um serviço que é instalado no sistema operacional com o objetivo de monitorar
os dados envolvidos no processo e gerar a partir deles novos dados que estarão presentes na
tabela utilizada para configurar as evidências. Este mecanismo de verificação das alterações
no processo é executado em intervalos de tempo previamente estabelecidos. Desta forma,
torna-se possível obter os dados já devidamente atualizados a cada vez que o processo em
47
execução sofre alterações. Posteriormente será explicado de forma mais detalhada o
funcionamento deste serviço.
Após a tabela ter sido atualizada contemplando as últimas alterações nos dados do
processo, torna-se possível atualizar novamente a rede Bayesiana, propagando, assim, o
estado atual do processo para a rede, sendo essa a pós-condição requerida pelo cenário 2.
Figura 11 – Cenário 2 – monitoração e controle
Fonte: autoria própria, 2011
5.4 Implementação da solução proposta
Após a apresentação das ferramentas que foram avaliadas para o desenvolvimento do
modelo e após a definição dos cenários de execução, se faz necessário explicar os critérios
que foram adotados para as respectivas escolhas, bem como a modelagem dos dados e os
diagramas que foram utilizados para o desenvolvimento da interface web para seleção dos
dados e do serviço responsável pela atualização dinâmica dos dados utilizados pelas redes
Bayesianas.
Os seguintes critérios foram adotados para justificar a escolha das tecnologias e
ferramentas utilizadas durante o desenvolvimento:
a) utilização de ferramentas que fossem, preferencialmente, gratuitas e que fossem,
ao mesmo tempo, conhecidas e consolidadas dentro das suas respectivas
categorias;
48
b) ferramentas e tecnologias que tivessem um bom respaldo por parte dos seus
fabricantes, principalmente no que diz respeito à documentação e suporte
técnico no caso do surgimento de eventuais dúvidas e problemas;
c) o domínio e conhecimento prévio em relação a grande maioria das tecnologias
utilizadas, pois desta forma foi possível desenvolver com maior agilidade e
qualidade a solução proposta.
Dentro desse contexto, levando em consideração os critérios acima mencionados e as
avaliações das ferramentas já feitas anteriormente, optou-se pelas seguintes tecnologias:
a) plataforma de desenvolvimento: Microsoft.NET (NORTHRUP et al., 2006),
considerando sua fácil integração com as demais ferramentas, a versatilidade da
plataforma, além do fato de oferecer total suporte à orientação a objetos
(LARMAN, 2008) e programação em múltiplas camadas;
b) linguagem de programação: páginas web codificadas usando a linguagem C#
(SHARP, 2010) e a tecnologia ASP.NET (ESPOSITO, 2011);
c) servidor web: Microsoft IIS (Internet Information Services) (STANEK, 2007),
por ser o mais adequado quando se trabalha com a plataforma .NET e por fazer
parte do próprio sistema operacional Windows, sem acarretar em custos
adicionais;
d) banco de dados: MySQL (ULLMAN, 2006), por ser uma base de dados de
código aberto e gratuita quando utilizada sua versão Community. Além disso, é a
base de dados utilizada pelo WebAPSEE, o que facilita na tarefa de integração
dos dados;
5.4.1 Modelo de dados
Dentro da área de banco de dados, entende-se por Modelo ER (Entidade -
Relacionamento) como sendo a utilização de uma série de tabelas para representar os dados e
as relações entre esses dados, onde cada uma das tabelas possui várias colunas e cada uma das
colunas possui um nome único (KORTH et al., 2006).
Dentro do contexto da implementação do modelo aqui apresentado, a base de dados
que é utilizada é a própria base do WebAPSEE. Esta escolha ocorreu visando facilitar o
processo de monitoração, pois se o objetivo é sempre verificar as alterações ocorridas no
processo em execução o mais simples é consultar diretamente a base do WebAPSEE. Como
o WebAPSEE é composto por, aproximadamente, 170 tabelas, a exibição do modelo ER
49
completo ficaria inviável dadas as limitações de tamanho das páginas. Sendo assim, a figura
12 mostra um fragmento do modelo ER que contempla algumas das principais tabelas
envolvidas na criação de uma atividade.
Figura 12 – Fragmento do modelo ER da base do WebAPSEE
Fonte: autoria própria, 2011
5.4.2 Modelagem da implementação
Com o objetivo de modelar a implementação, são utilizados alguns dos diagramas
oferecidos pela UML. A Linguagem de Modelagem Unificada (UML) diz respeito a um
grupo de notações gráficas que ajuda na descrição e também no projeto de sistemas baseados
em software (FOWLER, 2004).
São apresentados nos tópicos a seguir, com o objetivo de melhor explicar a
implementação da solução proposta e o domínio do problema, alguns dos principais
diagramas da UML utilizados no projeto da implementação.
5.4.2.1 Diagramas de caso de uso
Casos de Uso são definidos como sendo narrativas em texto, sendo amplamente
utilizadas para descobrir e registrar requisitos de software (LARMAN, 2008). Um dos
50
aspectos fundamentais dos Casos de Uso é o fato de servirem de entrada para diversos
artefatos subsequentes nos demais estudos de caso.
A figura 13 apresenta o diagrama de contexto da aplicação desenvolvida, com o
objetivo de demonstrar o escopo e o contexto no qual a aplicação se insere.
Em seguida, são demonstrados três casos de uso explicando de forma mais detalhada
cada um dos componentes principais da implementação.
Figura 13 – Diagrama de contexto da aplicação
Fonte: autoria própria 2011
Como autor principal do sistema temos o Gerente de Projeto, que é o responsável por
utilizar a interface web com o intuito de selecionar o aspecto do projeto monitorado que será
avaliado (tempo, custo, qualidade, etc), bem como as respectivas métricas relacionadas. Estas
opções serão posteriormente utilizadas pelos demais mecanismos que compõem o sistema.
A seguir são apresentados os demais casos de uso descrevendo as outras
funcionalidades representadas no diagrama de contexto.
5.4.2.1.1 Selecionar métricas
Este caso de uso tem como objetivo principal representar a ação de seleção das métricas
e parâmetros que serão avaliados. Esta ação é executada pelo gerente de projetos responsável
pelo processo que está sendo monitorado. A figura 14 ilustra o caso de uso:
51
Figura 14 – Diagrama de caso de uso Selecionar métricas
Fonte: autoria própria, 2011
Descrição do caso de uso (Selecionar métricas): este caso de uso inicia-se quando o
gerente de projetos acessa a interface web.
Atores: Gerente de Projetos
Pré-condições: o processo de software deve estar devidamente configurado no
WebAPSEE e o modelo de rede Bayesiana deve estar carregado no software GeNIe.
Fluxo Básico: selecionar, primeiramente, a métrica a ser monitorada: tempo, custo, etc.
Logo após, serão exibidas as características relativa à métrica selecionada que são passíveis
de seleção. Deve-se, então, selecionar aquelas que se deseja monitorar via rede Bayesiana.
Feito isso, deve-se clicar no botão “Gerar arquivo de dados”. O sistema deverá buscar na base
de dados do processo modelado no WebAPSEE os valores relativos às métricas selecionadas,
gerando um arquivo de dados com essas informações. Este arquivo terá seu conteúdo exibido
em uma tabela. Esses dados serão utilizados no decorrer do processo de monitoração para
auxiliar no processo de identificação das evidências na rede Bayesiana. É exibida uma
mensagem para o usuário informando que o arquivo de dados foi gerado corretamente ao
término da obtenção dos dados do processo.
Fluxo Alternativo 1: o usuário clica no botão “Gerar arquivo de dados” antes de
selecionar uma métrica e/ou uma característica relativa à métrica. Neste caso o sistema exibe
uma mensagem informando que é necessário selecionar os parâmetros antes de que seja
possível gerar o arquivo de dados e o caso de uso reinicia.
52
Fluxo Alternativo 2: o usuário clica no botão “Gerar arquivo de dados” após ter
selecionado a métrica e as respectivas informações relativas, porém ocorreu um erro ao tentar
acessar a base de dados e ao gerar o arquivo de dados. Neste caso o sistema informa ao
usuário que ocorreu um problema ao tentar gerar o arquivo de dados e o caso de uso reinicia-
se.
Pós-condições: é exibida uma mensagem informando ao usuário que o arquivo de dados
foi gerado corretamente e este encontra-se no diretório configurado no momento da instalação
do aplicativo.
5.4.2.1.2 Gerar arquivo de dados
O caso de uso apresenta a ação executada pelo Windows Service que tem como objetivo
gerar novas versões do arquivo de dados visando tornar possível para a rede Bayesiana refletir
a situação atual do processo monitorado no WebAPSEE. Esta ação é executada de forma
automática e inicia-se logo após o gerente de projetos ter selecionado as métricas a serem
monitoradas via a interface web disponível. A figura 15 ilustra o caso de uso:
Figura 15 – Diagrama de caso de uso Gerar arquivo de dados
Fonte: autoria própria, 2011
Descrição do caso de uso (Gerar arquivo de dados): este caso de uso inicia-se logo
após o término com sucesso do caso de uso Selecionar métricas.
53
Atores: Gerente de Projetos.
Pré-condições: o arquivo de dados foi gerado corretamente de acordo com o caso de
uso Selecionar métricas. Desta forma, o Windows Service será inicializado, recebendo como
parâmetro a query gerada na tela de seleção de métricas.
Fluxo Básico: o Windows Service recebe como parâmetro a query que será executada na
base de dados do WebAPSEE e que contém informações relativas ao processo modelado. O
Windows Service irá executar esta consulta na base de dados a cada intervalo de tempo (a
periodicidade de execução é configurada durante a instalação da ferramenta). Ao término de
cada execução o arquivo de dados é atualizado e um log informativo é gravado no arquivo de
logs do sistema operacional.
Fluxo Alternativo: o Windows Service recebe por parâmetro a query relativa às
informações selecionadas pelo gerente de projetos via interface web, porém, ao executar a
query recebida, ocorre um problema referente ao acesso a base de dados ou, posteriormente a
execução da query, ocorre um erro referente a gravação do arquivo no diretório configurado.
Desta forma o Windows Service gravará um log de erro no arquivo de logs do sistema
operacional informando que ocorreu um erro durante a tentativa de geração do arquivo e o
caso de uso reinicia-se.
Pós-condições: arquivos devidamente gerados no diretório configurado, tabela de
visualização dos dados exibindo as novas informações obtidas e mensagens de log
informativas gravadas no arquivo de logs do sistema operacional.
5.4.2.1.3 Selecionar dados de evidência
É apresentado neste caso de uso como funcionará a seleção dos dados de evidência que
serão obtidos a partir da tabela contendo as informações dos arquivos de dados gerados e
como se dará sua integração com o software de modelagem de redes Bayesianas GeNIe. O
caso de uso é apresentado na figura 16:
54
Figura 16 – Diagrama de caso de uso Selecionar dados de evidência
Fonte: autoria própria, 2011
Descrição do caso de uso (Selecionar dados de evidência): este caso de uso inicia-se a
qualquer momento, após a execução com sucesso do caso de uso Selecionar métricas.
Atores: Gerente de Projetos.
Pré-condições: o gerente de projetos precisa ter acesso a interface web onde é exibida a
tabela atualizada contendo as informações obtidas a partir do arquivo de dados gerado pelo
Windows Service. Além disso, o software GeNIe para modelagem de redes Bayesianas deve
estar corretamente instalado e com um modelo de redes Bayesianas previamente carregado e
treinado a partir dos dados da base de histórica.
Fluxo Básico: o gerente de projetos acessa a interface web e visualiza os dados obtidos
do processo na tabela. Após cada atualização dos dados na tabela ele deverá marcar a
respectiva evidência na rede Bayesiana através do software GeNIe. A partir dai a rede
Bayesiana recalcula as probabilidades e faz os prognósticos relativos à situação do processo.
Fluxo Alternativo: o gerente de projetos acessa a interface web e visualiza a tabela
utilizada para a exibição das informações do processo, porém nenhuma informação consta na
tabela. Desta forma se faz necessário aguardar o término da próxima execução do Windows
service ou selecionar novas métricas e aguardar a atualização da tabela para prosseguir com o
monitoramento e o caso de uso reinicia-se.
55
Pós-condições: gerente de projetos consegue configurar as evidências na rede
Bayesiana utilizada a partir da tabela de visualização de dados do processo. A partir disso o
processo de monitoramento do WebAPSEE prossegue.
5.4.2.2 Diagrama de sequência
Diagramas de sequência dizem respeito a um tipo de notação utilizada na UML para
ilustrar as interações de atores e as operações iniciadas por eles (LARMAN, 2008).
O objetivo do diagrama de sequência apresentado na figura 17 é demonstrar de uma
forma mais intuitiva cada uma das principais funcionalidades desenvolvidas pelo modelo de
implementação proposto.
Figura 17 – Diagrama de sequência com as principais funcionalidades
Fonte: autoria própria, 2011
56
5.4.2.3 Diagrama de classes
O diagrama de classes tem como objetivo descrever os tipos de objeto no sistema
visando representar os diversos tipos de relacionamentos estáticos existentes entre eles
(FOWLER, 2004).
O modelo de monitoramento proposto neste trabalho é estruturado sobre quatro classes
principais, pois grande parte do código utilizado diz respeito às classes nativas do próprio
.NET Framework.
Figura 18 – Diagrama de classes da aplicação
Fonte: autoria própria, 2011
Conforme ilustrado no diagrama da figura 18, as duas principais classes são a
QueryBuilderData, que é a responsável pelo acesso a base de dados do WebAPSEE e
responsável pelas tarefas de montagem das consultas de acesso e retorno dos dados. Além
disso, esta classe utiliza-se do padrão de projeto denominado Singleton (LARMAN, 2008),
cujo objetivo é garantir a existência de uma única instância de uma classe, visando otimizar
recursos. A classe FileBuilderData visa tratar da montagem e da gravação dos arquivos de
dados gerados pela interface web. As duas outras classes utilizadas são a
QueryBuilderBusiness e a FileBuilderBusiness. A função dessas duas outras classes é servir
57
de camada de regra de negócios, fazendo a conexão entre a interface da aplicação e as classes
QueryBuilderData e FileBuiderData.
5.4.3 Protótipo da solução
Após a apresentação do modelo conceitual e dos diagramas e fluxos referentes à
modelagem da implementação, se faz necessário apresentar um protótipo funcional do modelo
proposto. Conforme descrito e especificado nos diagramas já apresentados, se faz necessário,
em um primeiro momento, que se tenha um processo de software devidamente modelado e
sendo executado na ferramenta WebAPSEE. Outro aspecto importante diz respeito à seleção
do modelo de rede a ser utilizado pelos software de modelagem de redes Bayesianas GeNIe e
Netica. Por exemplo: se o aspecto o qual se deseja monitorar no processo for o Tempo, é
necessário que o modelo de rede Bayesiana analisado possua algum nodo com características
relativas ao Tempo. A mesma analogia é válida quando se deseja monitorar outros aspectos do
processo, como o Custo, por exemplo. A partir disso torna-se possível começar o processo de
monitoramento e controle e utilizar a interface web desenvolvida.
A figura 19 mostra a interface web desenvolvida.
Figura 19 – Interface web desenvolvida
Fonte: autoria própria, 2011
A interface web desenvolvida está organizada, fundamentalmente, da seguinte forma:
58
a) características do processo: na parte superior da página são disponibilizados diversos
controles HTML do tipo Radio, onde cada um deles identifica e torna passível de
seleção cada um dos aspectos e características relacionadas a um processo de software,
como Tempo, Custo e Qualidade.
b) dados relacionados: após a seleção de uma característica, são exibidos na área logo
abaixo, diversos controles do tipo checkbox onde cada um deles diz respeito a um
dado relacionado com a característica selecionada. É possível a seleção de diversos
dados relacionados a uma mesma característica.
c) gerar arquivo de dados: controle do tipo button cuja função essencial é confirmar a
seleção dos parâmetros de seleção e dar inicio ao processo de geração do arquivo
contendo os dados do processo, posterior exibição dos dados na tabela informativa
contendo os dados de evidência e inicialização do Windows Service responsável pelo
monitoramento da base de dados do processo e por atualizar o arquivo de dados.
d) mensagem informativa: após a seleção dos dados e após clicarmos no botão
responsável por gerar os arquivos de dados, o sistema nos informa sobre o resultado
da execução. Se tudo ocorreu conforme o esperado e sem ocorrência de erros, o
arquivo de dados foi gerado / atualizado corretamente e o Windows Service foi
inicializado com sucesso e, sendo assim, a seguinte mensagem é exibida: “Arquivo
gerado / atualizado com sucesso. Serviço de monitoramento inicializado
corretamente.”. Porém, caso ocorra algum erro durante a geração do arquivo de dados
ou durante a inicialização do Windows Service, a seguinte mensagem é exibida:
“Ocorreu um erro ao tentar gerar o arquivo. O serviço de monitoramento não foi
inicializado.”. Da mesma forma, tendo ocorrido tudo normalmente, a tabela contendo
os dados obtidos é atualizada.
e) tabela contendo os dados do processo monitorado: após a criação / atualização do
arquivo contendo os dados obtidos do processo monitorado, uma tabela presente na
interface web se encarrega de listar esses dados. Essa atualização é feita sempre de
forma periódica e é efetuada logo após cada execução do Windows Service. O objetivo
é garantir que seja possível visualizar sempre os últimos dados obtidos do processo
diretamente na tabela para que, assim, seja possível identificar as evidências e utilizá-
las na respectiva rede Bayesiana utilizada no software GeNIe ou Netica.
A figura 20 mostra um exemplo de arquivo gerado após a seleção dos dados.
59
Figura 20 – Exemplo de arquivo de dados gerado com os dados do processo
Fonte: autoria própria, 2011
Podemos perceber ao visualizarmos o conteúdo de um dos arquivos gerados que tanto
as colunas do cabeçalho (títulos), quanto as colunas dos dados estão cada uma delas separadas
pelo carácter “;” (ponto-e-vírgula), pois optou-se por gerar os arquivos com a extensão “.csv”
já que esta diz respeito a um formato de arquivo bastante conhecido e é facilmente lido tanto
pelo software de modelagem de redes Bayesianas, em caso de necessidade, quanto pela tabela
exibida na interface web. Além disso, a grande maioria dos conjuntos de software de
manipulação de planilhas eletrônicas existentes atualmente trabalham normalmente com este
tipo de arquivo.
Outro aspecto importante que merece ser destacado é a questão do funcionamento do
Windows Service. Por se tratar de um tipo de software cuja execução ocorre de forma
silenciosa (em segundo plano) no sistema operacional, ele, por si só, não exibe mensagens de
alerta explicitas como um software convencional no que diz respeito aos status das suas
execuções. Sendo assim, o Windows Service desenvolvido gera logs (registros) no
visualizador de eventos do Windows contendo informações relativas à execução da última
atividade. Desta forma, caso a geração dos arquivos de dados pare ou caso ocorra algum
problema com algum arquivo gerado, o Windows Service se encarregará de gerar as
informações pertinentes ao problema e gravá-las no log, provendo, assim, uma clara e rápida
descrição. A figura 21 mostra alguns exemplos de logs relativos à execução do Windows
Service.
60
Figura 21– Logs do Windows service de monitoramento
Fonte: autoria própria, 2011
61
6 AVALIAÇÃO
A meta fundamental da avaliação é efetuar um conjunto de testes com o objetivo de
avaliar a viabilidade da solução proposta, sobretudo, avaliar o real ganho em se utilizar redes
Bayesianas em conjunto com ferramentas de gerência e modelagem de processos de software
durante a monitoração. Na avaliação é modelado um processo de desenvolvimento no
software WebAPSEE. A ideia é que este processo seja o mais parecido possível com um
processo montado para modelar o desenvolvimento de um projeto de software real, porém,
por se tratar de um procedimento de avaliação de um modelo criado à titulo de prova de
conceito, o processo utilizado é simplificado, contendo apenas aspectos que sejam
fundamentais para a avaliação proposta e tomando como referência as tarefas definidas pela
metodologia RUP for small projects, conforme já anteriormente mencionado.
A definição do processo de software é peça fundamental no funcionamento do modelo
aqui proposto, pois é a partir das atividades definidas no processo e dos relacionamentos
existentes entre essas atividades em conjunto com as informações disponibilizadas na
literatura é que serão definidas e modeladas as redes Bayesianas utilizadas.
Se utilizou alguns modelos de redes Bayesianas presentes na literatura e adaptados
para que ficassem de acordo com os dados que são extraídos do processo e que estão
presentes no arquivo de dados gerado pela interface web desenvolvida. Desta forma,
independente da característica escolhida para ser monitorada, a rede Bayesiana definida
possibilitará uma representação fiel do processo em execução no WebAPSEE.
Conforme será apresentado posteriormente, a avaliação busca responder a alguns dos
principais questionamentos dos gerentes de projetos referentes à mudanças nas estimativas
que são recorrentes em processos de software. Ao final, objetiva-se identificar as principais
limitações e potencialidades da solução apresentada, sugerindo e/ou efetuando
aprimoramentos no modelo no que diz respeito à desempenho, facilidade de utilização e
novas situações de projeto as quais não foram identificadas no momento da concepção da
proposta inicial. Essas observações e conclusões se fazem importantes não só para melhorias
no modelo atual, mas também para abrir a possibilidade de desenvolvimento de novos
trabalhos relacionados ao tema proposto. Nas subseções a seguir são apresentados tanto o
processo utilizado bem como os modelos de redes Bayesianas adotados para a avaliação.
6.1 O processo de software
Um processo de software compreende o conjunt
para transformar os requisitos do usuário em software (OSTERWEIL apud QUITES REIS et
al., 2002). Com o objetivo de avaliar o modelo aqui proposto, modelou
contemplando algumas das principais atividades de
Unified Process) for Small Projects
de modelagem de processos, procurou
com o que é proposto pela metodologia. A
mostrando as conexões entre as disciplinas que o compõem.
Figura 22- Visão macro do processo iterativo modelado no WebAPSEE
Fonte: autoria própria, 2011
É importante mencionar també
(KRUCHTEN, 2003), ou seja, cada uma das etapas é executada várias vezes ao longo do
processo de desenvolvimento. Isso possibilita que nosso entendimento em relação ao
problema como um todo aumente atrav
solução eficaz seja obtida após inúmeras iterações. Na figura 22 a iteratividade é descrita pela
seta pontilhada que liga a disciplina de Gerenciamento de Mudanças com a disciplina de
Requisitos.
A seguir são apresentadas brevemente cada uma das disciplinas, bem como as
atividades que foram selecionadas em cada uma delas.
6.1 O processo de software
Um processo de software compreende o conjunto de todas as atividades necessárias
para transformar os requisitos do usuário em software (OSTERWEIL apud QUITES REIS et
al., 2002). Com o objetivo de avaliar o modelo aqui proposto, modelou
contemplando algumas das principais atividades definidas na metodologia RUP (
for Small Projects. Utilizando-se do software WebAPSEE como ferramenta
de modelagem de processos, procurou-se organizar as atividades por disciplinas, de acordo
com o que é proposto pela metodologia. A figura 22 mostra uma visão macro do processo,
mostrando as conexões entre as disciplinas que o compõem.
Visão macro do processo iterativo modelado no WebAPSEE
Fonte: autoria própria, 2011
É importante mencionar também que trata-se de um processo iterativo e incremental
), ou seja, cada uma das etapas é executada várias vezes ao longo do
processo de desenvolvimento. Isso possibilita que nosso entendimento em relação ao
problema como um todo aumente através de sucessivos refinamentos, fazendo com que uma
solução eficaz seja obtida após inúmeras iterações. Na figura 22 a iteratividade é descrita pela
seta pontilhada que liga a disciplina de Gerenciamento de Mudanças com a disciplina de
são apresentadas brevemente cada uma das disciplinas, bem como as
atividades que foram selecionadas em cada uma delas.
62
o de todas as atividades necessárias
para transformar os requisitos do usuário em software (OSTERWEIL apud QUITES REIS et
al., 2002). Com o objetivo de avaliar o modelo aqui proposto, modelou-se um processo
finidas na metodologia RUP (Rational
se do software WebAPSEE como ferramenta
se organizar as atividades por disciplinas, de acordo
figura 22 mostra uma visão macro do processo,
Visão macro do processo iterativo modelado no WebAPSEE
se de um processo iterativo e incremental
), ou seja, cada uma das etapas é executada várias vezes ao longo do
processo de desenvolvimento. Isso possibilita que nosso entendimento em relação ao
és de sucessivos refinamentos, fazendo com que uma
solução eficaz seja obtida após inúmeras iterações. Na figura 22 a iteratividade é descrita pela
seta pontilhada que liga a disciplina de Gerenciamento de Mudanças com a disciplina de
são apresentadas brevemente cada uma das disciplinas, bem como as
63
6.1.1 Requisitos
A disciplina de requisitos explica de que forma elencar as solicitações das partes
envolvidas e transformá-las em requisitos de produtos de trabalho. A figura 23 mostra as
tarefas relativas à disciplina de requisitos, bem como descreve a relação de dependência entre
elas e os agentes responsáveis por sua execução.
Figura 23 – Atividades de requisito
Fonte: autoria própria, 2011
6.1.2 Gerenciamento do Projeto
O foco da disciplina de gerenciamento do projeto reside no planejamento do projeto, no
gerenciamento dos riscos, no monitoramento do progresso e nas métricas de controle do
processo. A figura 24 mostra as tarefas desta disciplina, os relacionamentos e os agentes
responsáveis.
64
Figura 24 - Atividades de gerenciamento do projeto
Fonte: autoria própria, 2011
6.1.3 Análise
A disciplina de análise tem por objetivo explicar como transformar os requisitos de
produto de trabalho em produtos de trabalho especificando a arquitetura do software que o
projeto irá desenvolver. Na figura 25 são mostradas as atividades.
Figura 25 – Atividades de análise
Fonte: autoria própria, 2011
65
6.1.4 Implementação
A atividades relativas a manutenção dizem respeito à como desenvolver, organizar,
testes unitários e integração dos componentes implementados baseando-se nas especificações
da arquitetura definida. Na figura 26 é demonstrado o fluxo das atividades desta disciplina no
processo modelado.
Figura 26 – Atividades de implementação
Fonte: autoria própria, 2011
6.1.5 Testes
A disciplina de teste dentro do RUP tem como objetivo principal fornecer orientações
sobre como melhor avaliar e aferir a qualidade do produto de software. A figura 27
demonstra a disciplina.
66
Figura 27 – Disciplina de testes e suas atividades
Fonte: autoria própria, 2011
6.1.6 Gerenciamento de Mudanças
O gerenciamento de mudanças objetiva, fundamentalmente, explicar como controlar e
sincronizar a evolução do conjunto de produtos de trabalho que compõem um sistema de
software. Na figura 28 é exemplificada a disciplina e algumas de suas respectivas tarefas.
Figura 28 – Disciplina de gerenciamento de mudanças segundo o RUP
Fonte: autoria própria, 2011
67
6.2 Modelo de redes Bayesianas
A modelagem das redes Bayesianas utilizadas para a execução e avaliação dos cenários
avaliados foram construídas baseando-se no modelo conhecido como MODIST (MODIST,
2003), que preocupa-se com a qualidade das predições e com o gerenciamento dos riscos em
grandes projetos de software. O projeto MODIST é baseado em redes Bayesianas e tenta
produzir modelos de desenvolvimento de software e processos de teste que levem em conta
conceitos cruciais de estatística faltantes nas abordagens tradicionais de desenvolvimento.
Como o modelo MODIST foi desenvolvido em grande parte por especialistas da área de
desenvolvimento de software e inteligência artificial, ele possui diversas sugestões de
modelos de redes Bayesianas para acompanhamento e controle de projetos de software.
A título de avaliação, optou-se por desenvolver uma rede Bayesiana para monitorar o
conjunto de atividades de Requisitos (Requirements), sobretudo levando em consideração o
aspecto do tempo. Os requisitos nada mais são que os detalhes relativos ao escopo do projeto.
Um dos motivos por ter-se optado pelos requisitos reside no fato de que é neles, que,
normalmente, estão presentes as principais atividades que definem o que será necessário para
que o projeto seja desenvolvido como um todo, principalmente em termos de tempo e esforço.
É importante salientar também que é plenamente viável que novas redes sejam desenvolvidas
para monitorar os demais aspectos e conjuntos de atividades, tais como Testes,
Gerenciamento de Mudanças ou Análise, por exemplo. Além disso, se poderia também
considerar o processo monitorado todo como sendo uma única atividade e, desta forma,
desenvolver uma única rede responsável por cuidar de todos os aspectos.
Como o objetivo é, a partir das redes Bayesianas, conseguir responder a alguns dos
principais questionamentos dos gerentes de projetos em relação a eventuais alterações nas
estimativas, procurou-se dividir a avaliação em cenários, onde cada um deles apresentará uma
diferente situação em relação aos requisitos e, através do resultado apontado pela rede, será
sugerida uma resposta ao questionamento apontado.
Para a concepção do submodelo a ser analisado, foram também levados em
consideração duas premissas:
a) o esforço real tende a se expandir a partir do tempo inicialmente alocado;
b) a experiência da equipe pode mitigar a dificuldade, mas algo que é considerado
difícil continua sendo difícil.
68
A figura 29 mostra os nodos relativos ao submodelo Requirements.
Figura 29 - Submodelo de requisitos
Fonte: autoria própria, 2011
6.3 Cenários de avaliação
Para efetuar a inferência da rede Bayesiana para a posterior definição e identificação das
evidências, em cada um dos cenários avaliados a rede foi inicialmente treinada com dados
históricos de 100 projetos já finalizados e que possuem algum nível de similaridade com o
processo analisado. O objetivo dos cenários é simular situações reais que podem ocorrer
durante o monitoramento de um processo de software.
6.3.1 Cenário 1
Um processo de software que possua as seguintes características:
a) um alto grau de novidade naquilo que será desenvolvido (Novelty);
b) complexidade alta (Complexity);
c) tamanho grande (Size);
d) equipe com baixo grau de experiência (Staff Experience);
e) esforço estimado alto (Estimated Effort);
69
Questionamento:
a) a inclusão de profissionais mais experientes no projeto fará com que o esforço
requerido para a conclusão do mesmo diminua?
Após a configuração das situações mencionadas acima, que na rede Bayesiana
modelada serão as evidências, percebe-se que, quando temos uma situação conforme descrita
acima, existe uma grande probabilidade (neste caso, 51%) de o Esforço Requerido (Required
Effort) efetivo para a conclusão do projeto seja alto (High). A figura 30 demonstra o
comportamento da rede Bayesiana após a configuração das evidências.
Figura 30 - Rede Bayesiana com as evidências do cenário 1
Fonte: autoria própria, 2011
O questionamento feito em relação a este cenário diz respeito à possível diminuição do
esforço requerido caso sejam alocados para o processo novos profissionais que possuam um
grau de experiência maior. A figura 31 ilustra o comportamento da rede Bayesiana após a
inclusão dos novos profissionais.
70
Figura 31 - Rede Bayesiana após a inclusão de profissionais experientes
Fonte: autoria própria, 2011
Conforme é possível visualizar na figura 31, a inclusão de profissionais mais
experientes no processo monitorado em execução fez com que o Esforço Requerido (Required
Effort) continuasse alto, porém, diminuiu de 51% para 47%. Além disso, a acurácia
(Accuracy), que identifica o quão próximas as estimativas estão daquilo que foi efetivamente
requerido, também melhorou, passando de 53% para 54%. Sendo assim, podemos perceber
que em projetos grandes e que possuem um alto grau de complexidade e que sejam também
totalmente novos em termos de tecnologia ou segmento, se considerarmos uma equipe
inicialmente inexperiente, ao incluirmos nessa equipe novos profissionais com um nível de
experiência alto em relação ao problema proposto, o esforço requerido, apesar de continuar
alto, já sofreu diminuição.
6.3.2 Cenário 2
Um processo de software que possua as seguintes características:
b) projeto com baixo grau de novidade (Novelty);
c) complexidade baixa (Complexity);
d) tamanho grande (Size);
e) equipe com alto grau de experiência (Staff Experience);
f) esforço estimado baixo (Estimated Effort);
Questionamento:
71
a) a saída de profissionais experientes do projeto e a entrada de novos profissionais
menos experientes fará com que o esforço requerido aumente em relação à
estimativa efetuada inicialmente?
Configurando na rede Bayesiana as evidências que correspondem ao cenário acima
percebe-se que neste cenário existe uma probabilidade grande (neste caso, 43%) de o Esforço
Requerido (Required Effort) efetivo para a conclusão do projeto seja baixo (Low). A figura 32
demonstra a rede Bayesiana após a configuração das evidências requeridas pelo cenário
proposto.
Figura 32 - Rede Bayesiana demonstrando as evidências do cenário 2
Fonte: autoria própria, 2011
Em relação a este cenário, questiona-se se caso sejam excluídos do processo os
profissionais experientes e, posteriormente, entrem no processo novos profissionais com um
baixo grau de experiência, o esforço requerido efetivamente aumentará em relação ao Esforço
Requerido anteriormente. A figura 33 demonstra o comportamento da rede após a saída dos
profissionais experientes da equipe e a entrada dos profissionais com pouca experiência.
72
Figura 33 - Rede Bayesiana após a entrada de profissionais inexperientes
Fonte: autoria própria, 2011
De acordo com o resultado demonstrado após a execução do cenário acima mencionado
e exibido na figura 33, a saída de profissionais com um alto nível de experiência e a posterior
entrada de novos profissionais com um baixo nível de experiência fez com que o Esforço
Requerido (Req Effort) aumentasse no seu nível mais alto (High) passando de 34% para 53%.
Desta forma, percebe-se que em projetos que possuem um nível baixo de complexidade, e que
não possuem um alto grau de novidade, ou seja, envolvem tecnologias / técnicas conhecidas, a
experiência da equipe de desenvolvimento torna-se um item fundamental para a precisão das
estimativas, pois conforme visto neste cenário, a entrada de profissionais inexperientes
ocasionou uma alteração de quase 20% em relação às estimativas iniciais.
6.3.3 Cenário 3
Um processo de software que possua as seguintes características:
b) projeto com baixo grau de novidade (Novelty);
c) complexidade baixa (Complexity);
d) tamanho grande (Size);
e) equipe com alto grau de experiência (Staff Experience);
f) esforço estimado médio (Estimated Effort);
73
Questionamento:
a) com o decorrer do processo monitorado, foi identificada a necessidade de se
incluir novas tarefas no processo, resultando no aumento do nível de
complexidade, passando de Simples (Simple) para Complexo (Complex). A
equipe continua sendo composta por profissionais com alto nível de experiência.
Dada essa nova alteração no processo, o Esforço Requerido (Required Effort)
sofreria alguma alteração em relação aos valores obtidos inicialmente?
Após a configuração da rede Bayesiana e a identificação das evidências propostas pelo
cenário em questão, identifica-se claramente que o Esforço Requerido (Required Effort) tem
maior chance (45%) de ser Médio (Medium). A figura 34 mostra a rede Bayesiana com as
evidências já devidamente configuradas.
Figura 34 - Rede Bayesiana com as vidências do cenário 3
Fonte: autoria própria, 2011
O questionamento feito diz respeito à mudanças no decorrer do processo monitorado.
Especificamente, neste caso, mudanças no tamanho do processo, ocasionadas pela inclusão de
novas tarefas mais complexas, tendo como consequência, o aumento da Complexidade
(Complexity) global do processo. Pretende-se, fundamentalmente, verificar se a alteração
nessa complexidade, passando de Simples (Simple) para Complexo (Complex), influencia no
Esforço Requerido (Required Effort). A figura 35 demonstra a rede Bayesiana já com a
Complexidade (Complexity) alterada.
74
Figura 35 - Rede Bayesiana com a complexidade ajustada
Fonte: autoria própria, 2011
Como pode-se perceber na figura 35, a inclusão de novas atividades e, neste caso, o
consequente aumento da complexidade, implica no aumento do Esforço Requerido (Required
Effort), mesmo quando se tem uma equipe altamente experiente, como neste caso. O Esforço
Requerido (Required Effort) no nível mais alto (High) passou dos anteriores 34% para 47%.
6.3.4 Cenário 4
Um processo de software com as seguintes características:
b) projeto com baixo grau de novidade (Novelty);
c) complexidade baixa (Complexity);
d) tamanho grande (Size);
e) equipe com baixo grau de experiência (Staff Experience);
f) esforço estimado médio (Estimated Effort);
Questionamento:
a) este cenário é, na verdade, complementar ao Cenário 3. Se anteriormente quando
tínhamos uma equipe com um alto grau de experiência participando do processo
e, quando o projeto teve um acréscimo de tarefas (Size) que resultou no aumento
da sua complexidade (Complexity) passando do nível mais baixo para o mais
alto, o Esforço Requerido (Required Effort) passou de 34% para 47% no nível
Alto (High). O que aconteceria se tivéssemos uma outra situação praticamente
75
idêntica, porém, ao invés de termos uma equipe altamente experiente,
tivéssemos uma equipe totalmente inexperiente?
A rede Bayesiana e suas respectivas evidências são as mesmas do cenário anterior,
alterando apenas, nesse primeiro momento, a Experiência da Equipe (Staff Experience) para
Baixa (Low). A figura 36 mostra a rede Bayesiana já devidamente treinada com os dados
provenientes da base de dados histórica e com as evidências identificadas.
Figura 36 - Rede Bayesiana com as evidências do cenário 4
Fonte: autoria própria, 2011
Conforme é possível perceber, apesar de o processo ter um Tamanho (Size) Alto (High),
e mesmo a Experiência da Equipe (Staff Experience) sendo na sua maior parte Baixa (Low), o
Esforço Requerido (Required Effort) manteve-se em um nível intermediário (Medium) na sua
maioria (43%). O objetivo agora é verificar o comportamento da rede Bayesiana quando, da
mesma forma que ocorre no cenário 3, alterarmos a complexidade, passando de Simples
(Simple) para Complexo (Complex) e, desta vez, ao contrário do cenário anterior, com uma
equipe inexperiente (Staff Experience). A figura 37 mostra o comportamento da rede após a
alteração no nível de tamanho e complexidade do processo.
76
Figura 37 - Rede Bayesiana com equipe inexperiente e complexidade ajustada
Fonte: autoria própria, 2011
A mudança na complexidade nos mostra que após alterarmos a Complexidade do
projeto de Simples (Simple) para Complexo (Complex) o Esforço Requerido (Req Effort) teve
um salto, passando do nível Médio (Medium) com 43% para o nível Alto (High) com 53%.
Mais importante do que observar o cenário 4, é comparar os resultados deste cenário
com os resultados obtidos pelo cenário 3. No cenário 3, quando a Complexidade (Complexity)
foi alterada de Simples (Simple) para Complexa (Complex), o Esforço Requerido (Required
Effort) no seu nível Alto (High) passou dos anteriores 34% para 47%. Ou seja, teve uma
variação de 13%. Após a execução do cenário 4, após a Complexidade ser alterada de Simples
para Complexa, o Esforço Requerido (Required Effort) passou dos anteriores 38% para 53%
no seu nível mais alto (High), tendo, desta forma, uma variação de 15%. Sendo assim,
percebe-se claramente que alterações no tamanho e na complexidade de um projeto possuem
impactos diferentes no esforço total requerido, dependendo do nível de experiência da equipe
envolvida. Quanto maior o nível de experiência da equipe, o impacto que alterações no
tamanho e na complexidade total do projeto geram sobre o esforço total tende a ser menor,
conforme demonstrado.
6.3.5 Cenário 5
O cenário 5 é um pouco mais simples de ser demonstrado em relação aos demais
cenários apresentados anteriormente, porém, apresenta uma das situações mais comuns em se
77
tratando de projetos de software, além de ser um dos principais desafios da atividade de
monitoramento de processos: o atraso. Normalmente, o atraso no término de um projeto tem
origem em diversos fatores, mas, fundamentalmente, o atraso nada mais é que o reflexo de um
projeto que foi mal estimado e/ou mal definido.
A figura 38 mostra as atividades correspondentes a Análise e que foram modeladas no
processo monitorado pelo WebAPSEE.
Figura 38 - Atividades finalizadas e atividades em atraso
Fonte: autoria própria, 2011
Observando a figura 38 percebe-se que as atividades identificadas como “Finalizada”
são aquelas que já foram finalizadas, enquanto aquelas que estão identificadas como “Em
atraso” são as atividades ainda pendentes e que estão atrasadas. Outro aspecto importante a se
observar são as relações de dependência entre as tarefas: a atividade “Design das interfaces de
usuários” só pode ser iniciada após a conclusão da atividade anterior. Neste caso, após o
término da atividade “Estruturar casos de uso” devido a relação de end-start presente entre
essas atividades . Já a atividade “Design da base de dados” pode iniciar simultaneamente com
a atividade “design das interfaces de usuário”, pois entre elas existe uma relação start_start.
Essas relações que estão presentes não só nas atividades de análise, mas entre todas as demais
atividades do processo monitorado são de fundamental importância para o cálculo do esforço
estimado previsto para a conclusão das atividades baseando-se no tempo estimado para cada
uma delas.
78
A figura 39 mostra o esforço estimado necessário para a conclusão de todas as
atividades do processo (não apenas aquelas mostradas na figura 38), baseando-se nos tempos
designados para cada uma delas, bem como nas relações de procedência existentes entre elas.
Figura 39 - Esforço estimado (em horas) para a conclusão das atividades do processo
Fonte: autoria própria, 2011
Segundo as informações obtidas pela interface web desenvolvida, o esforço necessário
(em horas) para a conclusão de todas as atividades do processo é de 516 horas. Conforme
mencionado anteriormente, algumas atividades estão atrasadas. Sendo assim, visando
diminuir o tempo necessário para a conclusão do processo, resolveu-se reduzir o escopo do
projeto, ou seja, algumas das atividades foram excluídas. Inicialmente foi excluída a atividade
“Design da base de dados” que é uma das atividades atrasadas. A figura 40 mostra a relação
das atividades de análise do processo após a exclusão da atividade.
79
Figura 40 - Relacionamento entre atividades após a exclusão de uma delas
Fonte: autoria própria, 2011
Já na figura 41 é exibida novamente a quantidade de esforço estimado em horas após a
exclusão da atividade “Design da base de dados”.
Figura 41 - Esforço estimado sem alterações
Fonte: autoria própria, 2011
Conforme se pode perceber na figura 41, mesmo após a exclusão de uma tarefa o
esforço estimado em horas continua inalterado. Isso se deve a influência exercida pelo tipo de
relacionamento existente entre as atividades. Ou seja: como a atividade que foi excluída
80
(“Design da base de dados”) iniciava-se concomitantemente com a atividade anterior, sua
exclusão do processo não fez com que o tempo necessário para a conclusão das atividades
diminui-se, pois quando se tem atividades que se iniciam de forma simultânea, considera-se a
titulo de soma de esforço, a atividade que necessita de maior tempo para ser concluída. Como
neste caso tanto a atividade “Design da base de dados” quanto à atividade “Design das
interfaces de usuário” iniciavam-se simultaneamente, considerou-se apenas o tempo
necessário para a finalização da atividade “Design das interfaces de usuário” que, dentre as
duas, era a que necessitava de maior tempo para ser concluída.
Efetuando novamente este mesmo teste para que fosse possível efetuar uma
comparação, desta vez, ao invés de excluir do processo a atividade “Design da base de
dados”, optou-se por excluir a atividade “Design das interfaces de usuário”. A figura 42
demonstra o relacionamento entre as atividades após a exclusão dessa atividade.
Figura 42 - Relacionamento entre as atividades após a nova exclusão
Fonte: autoria própria, 2011
Os valores relativos ao esforço estimado em horas são novamente exibidos na interface
web presente na figura 43.
81
Figura 43 - Esforço estimado com alterações
Fonte: autoria própria, 2011
Conforme se pode perceber na figura 43, ao contrário do que ocorreu anteriormente,
quando se exclui do processo a atividade “Design da base de dados” e o esforço estimado em
horas não sofreu alterações, desta vez, ao eliminarmos a atividade “Design das interfaces de
usuário” o esforço estimado passou dos anteriores 516 horas para 498 horas. Isso, conforme
explicado anteriormente, se deve ao fato de que, mesmo as tarefas “Design da base de dados”
e “Design das interfaces de usuário” serem paralelas, uma tem uma duração maior que a
outra, prevalecendo, a titulo de contagem de horas, o tempo daquela que possui maior
duração; neste caso “Design das interfaces de usuário”, que foi a tarefa excluída.
Após a análise deste cenário se pode concluir que levando em consideração a variável
Total de Esforço Estimado, após a remoção de uma ou mais tarefas, o tempo estimado e o
esforço podem ser reduzidos. Porém, se a tarefa removida for uma tarefa que inicia-se de
forma paralela com outra, o esforço pode ser reduzido, porém, o tempo necessário para a
conclusão do projeto pode permanecer o mesmo.
82
7 CONCLUSÃO
O objetivo fundamental desta monografia não foi criar uma abordagem de monitoração
de projetos que nos desse como saída um valor único e definitivo. A ideia fundamental aqui
apresentada foi propor um modelo de monitoramento de projetos que conseguisse juntar a
experiência adquirida pelo gerente de projetos com a inferência estatística provida pelas redes
Bayesianas, resultando em um mecanismo para facilitar a tomada de decisões do gerente
perante as diferentes situações que normalmente encontramos quando lidamos com gerência
de projetos e tratamento de incertezas. Um aspecto favorável ao modelo apresentado é o fato
dele apresentar os resultados de uma forma visual, não necessitando, obrigatoriamente, que os
dados sejam avaliados por alguém fundamentalmente técnico. O aspecto visual vai de
encontro ao dinamismo que envolve o monitoramento de processos, pois sabendo que as
informações variam de acordo com o andamento do projeto, o fato de se poder analisar essas
informações e valores graficamente facilita bastante.
Através da análise dos diversos cenários apresentados foi possível verificar que o
conjunto composto por projetos históricos de uma determinada organização se apresenta
como componente fundamental na busca por resultados preditivos mais precisos durante a
monitoração executada através do modelo proposto. Além disso, o modelo nos possibilita
efetuar simulações com o objetivo de verificar o comportamento futuro do processo sob um
determinado aspecto, como, por exemplo, verificar se quando um projeto está atrasado, a
inclusão de novos profissionais fará com que o esforço necessário para a sua conclusão
diminua.
A partir do modelo que aqui foi apresentado, torna-se possível desenvolver uma série de
outros experimentos e melhorias. Para trabalhos futuros, se pode citar a possibilidade de
verificação e mensuração do impacto que as alterações feitas nas estimativas durante o
andamento do projeto terão sobre a qualidade do produto final. Outro ponto que poderia ser
melhor explorado futuramente diz respeito a possibilidade de centralizar em apenas um local
tanto a obtenção dos dados do processo monitorado, quanto a exibição gráfica das redes
Bayesianas para a posterior configuração das inferências, possibilitando, dessa forma uma
maior facilidade de utilização do modelo. Além disso, novas redes Bayesianas poderão ser
desenvolvidas com o objetivo de monitorar outros grupos de atividades de um determinado
projeto, diferentes daqueles que aqui foram mencionados e apresentados. É importante
comentar que o modelo aqui apresentado está em constante evolução, pois pode ser
melhorado e adaptado conforme o processo de software utilizado e conforme os modelos de
83
redes Bayesianas utilizados, podendo ser mais ou menos complexos dependendo do aspecto
que se desejará avaliar e dependendo da quantidade de variáveis que estarão envolvidas no
processo.
84
REFERÊNCIAS
AL-ROUSAN, T.; SULAIMAN, S.; SALAM, R. A. A risk identification architecture pattern based on Bayesian network. [S.l.]: [s.n.]. 2008. p. 1-10.
BIBI, S. et al. BBN based approach for improving the software development process of an SME — a case study. J. Softw. Maint. Evol., v. 22, p..1--.1, 2010.
BOEHM, B. W. et al. Software Cost Estimation with Cocomo II with Cdrom. 1st. ed. [S.l.]: Prentice Hall PTR, 2000.
CASTILLO, E.; GUTIERREZ, J. M.; HADI, A. S. Expert Systems and Probabilistic Network Models. Erste. ed. [S.l.]: Springer, 1996.
CERQUIDES, J.; DE, R. L. Proposal and empirical comparison of a parallelizable distance-based discretization method. [S.l.]: [s.n.]. 1997. p. 139-142.
CHARNIAK, E. Bayesian Networks Without Tears. AI MAGAZINE , v. 12, n. 4, p. 50-63, 1991.
CORDEIRO, J. C. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML . 4ed. ed. [S.l.]: Brasport, 2007. 325 p.
DEMARCO, T. Controlling software projects: management, measurement & estimation. [S.l.]: Yourdon Press, 1982.
ESPOSITO, D. Programming Microsoft ASP.NET 4. [S.l.]: Microsoft Press, 2011.
FENTON, N. E.; NEIL, M. A Critique of Software Defect Prediction Models. IEEE Transactions on Software Engineering, v. 25, p. 675-689, 1999.
FENTON, N. E.; NEIL, M.; MARQUEZ, D. Using Bayesian Networks to Predict Software Defects and Reliability. [S.l.]: [s.n.]. 2007.
FIRMINO, E. L. Redes Bayesianas para a Parametrização da Confiabilidade em Sistemas Complexos. Universidade Federal de Pernambuco. [S.l.]. 2004.
FOWLER, M. UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRAO. [S.l.]: Bookman, 2004.
GARMUS, D.; HERRON, D. Function point analysis: measurement practices for successful software projects. [S.l.]: Addison-Wesley Longman Publishing Co., Inc., 2001.
GETOOR, L. et al. Probabilistic Relational Models. In: GETOOR, L.; TASKAR, B. Introduction to Statistical Relational Learning. [S.l.]: MIT Press, 2007.
GHAHRAMANI, Z. Learning Dynamic Bayesian Networks. [S.l.]: Springer-Verlag. 1998. p. 168-197.
GROUP, T. S. The Chaos Report. Standish Group International Inc. [S.l.]. 2009.
85
INSTITUTE, P. M. A guide to the project management body of knowledge (PMBOK® Guide). 4th ed.. ed. [S.l.]: Project Management Institute, Inc., Newtown Square, Pa. :, 2008. xxvi, 459 p. : p.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development process. [S.l.]: Addison-Wesley Longman Publishing Co., Inc., 1999.
JEET, K. et al. A Tool for Aiding the Management of Schedule Overrun. IEEE 2nd International Advance Computing Conference, v. 2, p. 416-421, 2010.
KALMAN, R. E. A New Approach to Linear Filtering and Prediction Problems. Transactions of the ASME--Journal of Basic Engineering, v. 82, n. Series D, p. 35-45, 1960.
KHOMH, F. et al. BDTEX: A GQM-based Bayesian approach for the detection of antipatterns. J. Syst. Softw., v. 84, p. 559-572, 2011.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. SISTEMA DE BANCO DE DADOS. [S.l.]: MAKRON, 2006.
KRUCHTEN, P. The Rational Unified Process: An Introduction. 3. ed. [S.l.]: Addison-Wesley Longman Publishing Co., Inc., 2003.
LABORATORY, D. S. GeNIe & SMILE . [S.l.]. 1998. Bayesian network Computer Software.
LARMAN, C. Utilizando UML e Padrões. [S.l.]: BOOKMAN COMPANHIA ED, 2008.
LEMOS, P. E. Aplicação de Redes Bayesianas na Administração Estratégica das Organizações. Universidade Federal de Pernambuco. [S.l.]. 2007.
LIMA, A. et al. Gerência Flexível de Processos de Software com o Ambiente WebAPSEE. Simpósio Brasileiro de Engenharia de Software Florianópolis: Informática-UFSC, v. 1, p. 1-6, 2006.
LIMA, A. et al. WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de Software. VII Workshop de Software Livre, Porto Alegre, v. 1, p. 1-6, 2006.
MARQUES, R. L.; DUTRA, I. Redes Bayesianas: o que são, para que servem, algoritmos e exemplos de aplicações. Universidade Federal do Rio de Janeiro. [S.l.]. 2000.
MATSUEDA, L. N. Um Modelo de Gerenciamento de Projetos para um Ambiente de Desenvolvimento Distribuido de Software. Universidade Estadual de Maringá. [S.l.]. 2006.
MCLACHLAN, G. J.; KRISHNAN, T. The EM Algorithm and Extensions (Wiley Series in Probability and Statistics). 2. ed. [S.l.]: Wiley-Interscience, 2008.
MENDES, E.; MOSLEY, N. Bayesian Network Models for Web Effort Prediction: A Comparative Study. IEEE Transactions on Software Engineering, v. 34, p. 723-737, 2008.
86
MODIST. Models of Uncertainty and Risk for Distributed Software Development. EC Information Society Technologies Project IST-2000-28749. [S.l.]. 2003.
NORSYS, I. Netica. [S.l.]. 2004. Bayesian network Computer Software.
NORTHRUP, T.; WILDERMUTH, S.; RYAN, B. MCTS self-paced training kit (exam 70-536): Microsoft.NET Framework 2.0--application development foundation. [S.l.]: Microsoft Press, 2006.
PRESSMAN, R. S. Software Engineering: A Practitioner's Approach. 5th. ed. [S.l.]: McGraw-Hill Higher Education, 2001.
RABINER, L. R. A tutorial on hidden Markov models and selected applications in speech recognition. In: WAIBEL, A.; LEE, K.-F. Readings in speech recognition. [S.l.]: Morgan Kaufmann Publishers Inc., 1990. Cap. A tutorial on hidden Markov models and selected applications in speech recognition, p. 267-296.
REIS, R. Q.; LIMA, C. A.; NUNES, D. J. Automação no Gerenciamento do Processo de Engenharia de Software. Escola de Informática Norte, v. 1, p. 1-39, 2002.
ROSS, S. M. Introduction to Probability Models, Ninth Edition . [S.l.]: Academic Press, Inc., 2006.
RUSSELL, S. et al. Local learning in probabilistic networks with hidden variables. [S.l.]: Morgan Kaufmann Publishers Inc. 1995. p. 1146-1152.
RUSSELL, S. J.; NORVIG, P. Artificial intelligence: a modern approach. [S.l.]: Prentice-Hall, Inc., 1995. 415-429 p.
SANTANA, A.; FRANCÊS, C.; VIJAYKUMAR, N. L. Aplicação de Modelos Markovianos para a Análise Temporal e Melhoria da Interpretabilidade de Redes Bayesianas. Simpósio Brasileiro de Pesquisa Operacional, v. 1, p. 1-10, 2007.
SCHULZ, T. et al. Defect cost flow model: a Bayesian network for predicting defect correction effort. [S.l.]: ACM. 2010. p. 16:1--16:11.
SEI/CM, U. CMMI for Development (CMMI-DEV), Version 1.2 .
SHARP, J. Microsoft Visual C\# 2010 Step by Step. [S.l.]: Microsoft Press, 2010.
STAMELOS, I. et al. Estimating the development cost of custom software. Inf. Manage., v. 40, p. 729-741, 2003.
STANEK, W. R. Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant. [S.l.]: Microsoft Press, 2007.
TRINDADE, C. C. Estimativa de Software: O estudo de uma Aplicação Prática Utilizando a Técnica de Use Case Points. XIV Escola Regional de Informática, Guarapuava, v. 1, p. 1-12, 2007.
ULLMAN, L. MySQL . [S.l.]: Peachpit Press, 2006.
87
V., A. C.; SANCHEZ, A. J. Software maintenance project delays prediction using Bayesian Networks. Expert Syst. Appl., v. 34, p. 908-919, 2008.
WANG, H. CMP: A Fast Decision Tree Classifier Using Multivariate Predictions. [S.l.]: [s.n.]. 2000. p. 449-460.
XIAOCONG, H.; LING, K. A risk management decision support system for project management based on bayesian network. 2nd IEEE International Conference on Information Management and Engineering, v. 2, p. 308-312, 2010.
YANG, Y.; WEBB, G. I. Discretization for naive-Bayes learning: managing discretization bias and variance. Mach. Learn., v. 74, p. 39-74, 2009.