PUCRS
RECONFIGURAÇÃO DINÂMICA EM PROJETOS DE DESENVOLVIMENTODE SOFTWARE
Doutorando: Daniel Callegari
Orientador: Prof. Dr. Ricardo Bastos
FACIN – Faculdade de Informática
PUC-RS – Pontifícia Universidade
Católica do Rio Grande do Sul
Brasil
Universidade do Porto, junho de 2008
PUCRS
Resumo
Sabe-se que projetos de software costumam sofrer inúmeras modificações durante seus ciclos de vida. Dois exemplos comuns são as freqüentes realocações de recursos e os replanejamentos de atividades. O cenário torna-se ainda mais desafiador quando recursos e atividades são compartilhados por mais de um projeto.
Esta pesquisa (investigação) tem o objetivo de desenvolver uma infra-estrutura computacional que permita a integração de processos de desenvolvimento de software com as melhores práticas de gerenciamento de projetos, com o propósito de lidar com aspetos relacionados à chamada reconfiguração dinâmica de recursos e de atividades em um contexto de múltiplos projetos de software.
Assim, o objetivo final deste trabalho é auxiliar os gerentes de projetosde software a lidar com essas modificações dos planos de projeto, sugerindo – ou até mesmo automatizando – realocações de recursos e de atividades, reduzindo o esforço dos freqüentes replanejamentos, ao mesmo tempo em que se aumentam as chances de sucesso.
PUCRS
Curriculum Vitae
Titulação
- Doutorando em Ciência da Computação (PUCRS, 2005+)
- Mestre em Informática (PUCRS, 2000)
- Bacharel em Informática (PUCRS, 1997)
Atuação
- Professor da Faculdade de Informática da PUCRS - FACIN
- Membro do grupo de pesquisa em Qualidade e Teste de Software - QUATES
- Pesquisador do Centro de Desenvolvimento e Pesquisa Dell / PUC-RS (CDPe)
Experiências Anteriores- Coordenador Técnico do Centro de Inovação da Microsoft de Porto Alegre, TecnoPuc (2005)
- Especialização em Gestão Empresarial (600h) SEBRAE, Ministério do Governo Italiano, ANFE (2000)
- Curso oficial de Gerenciamento de Projetos PMI (2005)
- Microsoft Certified Professional, C# e ASP.Net (MCP) (2005)
- 11 Cursos Oficiais Microsoft concluídos
- Consultor e revisor técnico, Microsoft Press Brasil
- Membro Executivo do Comitê de e-Business da Câmara Americana de Comércio (AMCHAM) (2001)
- Diretor de Tecnologia, Empresa PRIMA Ltda. (1999-2002)
- Concepção técnica e implementacao do produto de gerenciamento de conteúdo Web e CRM, Prima Manager
- Experiência em Automação Industrial (3 anos)
- Experiência com Fuzzy Logic.
Introdução e Motivação
Visão Geral
Reconfiguração Dinâmica
Integração de Modelos
Protótipo
Proposta de Solução
Resultados já alcançados
Conclusões e Trabalhos Futuros
Tópicos da Apresentação
Localização
Centro de Pesquisa DELLPUC-RS
Porto Alegre / Brasil
Introdução
Introdução e Motivação
“Desenvolver um produto de software requer um esforço
singular que envolve lidar, entre outros elementos, com
atividades e recursos para se produzir os resultados
desejados”. (Pfleeger 2003, McConnel 1996)
De uma forma geral, os elementos envolvidos em tal
esforço podem ser vistos sob duas perspectivas: sob a
visão do processo de desenvolvimento de software (PDS)
e sob a visão da gerência de projetos de software (GPS).
É necessário proporcionar uma combinação adequada
dessas duas dimensões.
Introdução e Motivação
Fatos Iniciais:
Atuais PDSs não contemplam adequadamente tal integração.
A complexidade, assim como o número de projetos com os quais um
gerente de projetos tem de lidar de forma concomitante, crescem
diariamente.
Visão de longo prazo:
Fornecer auxilio aos gerentes de projetos de software na tomada de
decisão acerca do planejamento de atividades e dos recursos envolvidos.
Tipos de Problemas
i) problemas que suportam soluções automatizadas;
ii) problemas que suportam soluções semi-automatizadas;
iii) problemas que não suportam qualquer tipo de automação.
Pesquisa: Até 6 projetos por gerente!
Introdução e Motivação
Possíveis respostas para esta questão conduzem à
elaboração de modelos e ferramentas que forneçam
suporte a decisões tanto gerenciais como produtivas no
contexto de uma empresa de software.
- “Um Modelo Universal ?”
“All models are wrong, but some are useful.” George Box (Quality and Statistics Engineer)
Introdução e Motivação
Projetos de qualquer natureza possuem duas fases
bastante distintas (projeto “ideal”):
Projetos de software costumam sofrer inúmeras
modificações durante seus ciclos de vida.
Planejamento Execução
(Pressman, 2001), (Schwalbe, 2002)
Processos “incrementais”,
modelos “evolutivos”.
Qualidade:
ISO/IEC, CMMI...
Tema de Pesquisa (Investigação)
Tratar especificamente dos problemas de
alocação de recursos, e de
seqüenciamento de atividades de projetos de
software
... considerando um cenário multiprojetos,
... no qual reconfigurações freqüentes de atividades e de
recursos devem ser gerenciadas apropriadamente para
que se possam entregar produtos e serviços de todos os
projetos
... considerando um conjunto de restrições de prazo e de
recursos disponíveis.
Reconfiguração Dinâmica
de Projetos de Software
Reconfiguração Dinâmica de Projetos de SW
Configuração de um projeto
“Define-se que uma configuração de projeto envolve não apenas
o planejamento das atividades, mas também os recursos
disponíveis, suas características e como estes são alocados às
atividades. A isso se somam informações no nível do projeto (como
a prioridade frente a outros projetos simultâneos) e as
disponibilidades dos recursos, lembrando que existem tanto
recursos que podem ser compartilhados entre múltiplos projetos,
quanto recursos exclusivos a determinados projetos.”
Primeira versão do Planejamento = Configuração Inicial
Novos e sucessivos (re)planejamentos de um mesmo
projeto, durante a fase de execução, juntamente com o
apoio tecnológico adequado, dão origem à expressão
“Reconfiguração Dinâmica de Projetos”.
Reconfiguração Dinâmica de Projetos de SW
“Todo e qualquer esforço que atue sobre um planejamento preexistente de atividades ou sobre os recursos alocados às mesmas, considerando um ou mais projetos de software simultâneos em execução.”
A acepção da palavra “dinâmica” neste contexto refere-se à habilidade da configuração de um projeto poder ser adequada aos eventos externos que perturbam – ou modificam voluntariamente – o planejamento atual em execução.
Obs.: “reconfiguração dinâmica” em outras áreas
Autonomic Computing
Sistemas Distribuídos
Redes de Computadores
Expressões comuns: “dynamic”, “on-line”, “on-the-fly”
Reconfiguração Dinâmica de Projetos de SW
Outras definições relevantes: Planejamento também envolve
• Escolha
• Definição
• Seqüenciamento (encadeamento, programação ou escalonamento)
• Dependência de atividades
Destaques
• PERT (Program Evaluation and Review Technique)
• CPM (Critical Path Method)
• CCPM (Critical Chain Project Management), Goldratt (ToC)
Uso de sistemas de Workflow
• “Instâncias executáveis” de atividades
• “Fluxos organizacionais”
Reconfiguração Dinâmica de Projetos de SW
Quatro necessidades gerais para melhor gerir os projetos
Ter acesso às informações pertencentes aos outros departamentos
da organização;
Identificar as relações de dependência entre as atividades dos
fluxos de trabalho da empresa e do projeto de software;
Prover a capacidade de evitar distorções no planejamento de
projetos (tais como o aumento dos custos e atrasos nos prazos do
projeto); e
Fornecer auxílio na identificação e mensuração dos custos
indiretos do projeto.
Reconfiguração Dinâmica de Projetos de SW
Reconfiguração Dinâmica
de Projetos de Software
Pool de
Recursos
Seleção de Recursos
Alocação de Recursos
Planejamento de
Atividades
Integração com Fluxos
Organizacionais
Projetos
P1 P2 P3
Quatro principais subáreas:
A) Seleção de Recursos para o(s) projeto(s) (e, conseqüentemente, para as atividades), a partir de um pool compartilhado;
B) Alocação de Recursos (às atividades do(s) projeto(s));
C) Planejamento e Replanejamento de atividades (e recursos associados);
D) Integração do(s) projeto(s) com fluxos organizacionais da empresa.
O que diz a literatura?
Revisão do Estado da Arte
Revisão Sistemática (Conferências e Periódicos de 2004-2008)
242 artigos, dos quais 19 foram selecionados para análise final.
“As incertezas inerentes ao andamento do projeto devem
ser constantemente avaliadas e o planejamento ajustado
de forma correspondente.”(JOSLIN, David; POOLE, William. Agent-Based Simulation For Software Project Planning. In Proceedings of the 37th
Conference on Winter Simulation .)
“Sem um modelo de ciclo de vida geral [para software],
podem-se tomar decisões que são individualmente
corretas, porém coletivamente mal direcionadas.” (MC CONNELL, S. Rapid Development: Taming Wild Software Schedules, Microsoft Press,U.S.,1996.)
Fonte Seleção de
Recur
sos
Alocação de
Recurs
os
Planejamento
atividades
Multi-
projetos
Tipo de Solução Método
[FAN 2004] Sim - por
papéis
Sim - algum
suporte
Não Sim Suporte a decisões Redes Bayesianas
[FEN 2004] Sim -
individ
uais
Sim Não Não Suporte a decisões Redes Bayesianas
[HAR 2007]* - - - - Otimização (revisão sobre “Search Based Software Eng.”)
[JAL 2004] Não Sim Elimina a
necessidade
Não Metodologia Timeboxing, pipelining de atividades e paralelismo
[JOS 2005] Sim -
individ
uais
Sim Sim – dois tipos
de
atividades
Não Suporte a decisões Busca em espaço de estratégias
[KAB 2007] Não Não Diferente Não Workflow Detecta exceções no workflow
[LEE 2004] Não Sim Sim Sim Suporte a decisões Corrente Crítica + Dinâmica de Sistemas + Cenários
[MEL 2008] Não Sim - algum
suporte
Sim Não Suporte a decisões Redes Bayesianas
[PAD 2004] Não Sim Sim Não Otimização Aprendizagem Automática + Simulação + Markov Decision Process
[SHE 2007]* - - - - - -
[YIF 2006] Sim -
individ
uais
Sim Diferente Não Otimização Programação Dinâmica
[LEE 2005] Não Não Sim Não Semi-automatizada Raciocínio Baseado em Casos
[PAD 2005] Não Não Sim Não Otimização Aprendizagem Automática + Simulação + Markov Decision Process
[PES 2006] Sim Não Não Não Estudo Eng. de Software Empírica
[SEN 2007] Não Não Sim Sim Metodologia Estatístico
[SOU 2007] Não Sim – baseado
em
compon
entes
Sim Não Suporte a decisões Grafos de dependências
[TRA 2005]* - - - - - -
[VAH 2005] Não Não Não Sim Metodologia Framework conceitual
[WER 2007]* - - - - - -
Fonte Conhecimento
especialistas
Simulação Solução
dinâmica
Estudo de caso /
Experimento
Possui
ferramenta
[FAN 2004] Sim Não Sim Sim Sim
[FEN 2004] Sim Não Não Sim Sim
[HAR 2007]* - - - - Não
[JAL 2004] Não Não Sim Sim Sim
[JOS 2005] Não Sim Sim Não Não
[KAB 2007] Não Não Sim Não Não
[LEE 2004] Não Sim Provavelmente sim Não Sim
[MEL 2008] Sim Não Sim Não Sim
[PAD 2004] Sim Sim Sim Não Sim
[SHE 2007]* - - - - -
[YIF 2006] Não é claro Não Sim Sim Não
[LEE 2005] Sim Não Não Sim Sim
[PAD 2005] Sim Sim Sim Não Sim
[PES 2006] N.A. N.A. N.A. Sim N.A.
[SEN 2007] Sim Não Sim Sim Não
[SOU 2007] Não Não Não Sim Sim
[TRA 2005]* - - - - -
[VAH 2005] Sim Não Sim Sim Não
[WER 2007]* - - - - -
Subárea A – Seleção de Recursos
De forma homogênea Comum em soluções que usam Simulação
Com base em características individuais Computacionalmente mais caro; melhores resultados.
Habilidades. Níveis de experiência.
Coalizões/afinidades entre recursos.
“Lei de Brooks” / “startup-penalty”“Acrescentar mais pessoas a um projeto atrasado somente o torna mais atrasado”
Questionamentos: verificar em quais casos é mais interessante trabalhar cada recurso
individualmente e em quais casos os recursos podem ser trabalhados como uma coleção ou mesmo em grupos;
verificar quais critérios são os mais importantes (ou relevantes) para distinguir os recursos uns dos outros para efeito de seleção.
Subárea A – Seleção de Recursos
Protótipo MRS – Multicriteria Resource Selector
Subárea B – Alocação de Recursos
Seleção (múltiplos critérios) para determinar qual recurso
atende qual atividade e com que esforço.
Não há consenso sobre a “granularidade” das atividades;
em outras palavras, permitir que uma atividade seja
desmembrada em “tarefas” pode afetar a forma como os
recursos são alocados;
Atividades: prioritárias/opcionais; gerenciais/produtivas.
Questionamentos:
estratégias diferentes para cada tipo ou tamanho de projeto?
até onde se pode automatizar o processo?
Subárea C – Planejamento de Atividades
Arranjar um conjunto de atividades que podem possuir
diversos tipos de dependências considerando o
compartilhamento de recursos.
A subárea mais afetada por incertezas e eventos externos.
Questionamentos:
identificar os tipos de feedback (conforme [PAD 2004]) entre
diferentes tipos de atividades para melhor avaliar o impacto de uma
alteração sobre as demais atividades relacionadas;
identificar quais os eventos que disparam necessidades de
replanejamento das atividades de um ou mais projetos de software;
determinar uma maneira eficiente de codificar ações
preestabelecidas, em decorrência dos eventos disparados.
distinguir os tipos de atividades, conforme já mencionado nos
comentários sobre a subárea B.
Subárea D – Integração com Fluxos Organizacionais
Atividades que pertencem a fluxos comuns e compartilhados da
organização.
Subárea D – Integração com Fluxos Organizacionais
Modelo semântico do RUP
(PEP, 2003)
Metamodelo de gerência de
projetos baseado no PMBOK Guide
(Callegari e Bastos, 2007)
Metamodelo Integrado PMBOK+RUP
Conceitos
provenientes do
PMBOK
Conceitos
provenientes do
RUP
Conceitos
compartilhados
Subárea D – Integração com Fluxos Organizacionais
Subárea D – Integração com Fluxos Organizacionais
Detalhamento e
Proposta de Solução
Visão Inicial do Problema
Detalhamento Técnicas Atuais
CPM e PERT pressupõem uma disponibilidade ilimitada de recursos
para cada atividade do projeto. A análise é baseada unicamente nos
requisitos de tempo das atividades sem considerar a necessidade de
recursos para cada atividade.
Propostas do algoritmo CPM para lidar com recursos:
Duas abordagens:
• Otimização por técnicas de programação matemática, e
• Técnicas heurísticas.
Problema: técnicas de otimização permanecem impraticáveis
computacionalmente para muitos projetos da vida real devido ao enorme
número de variáveis e restrições.
Número de tarefas > 50, problema computacionalmente intratável, sendo
necessário utilizar heurísticas para conseguir respostas aceitáveis (não
necessáriamente ótimas) em um tempo adequado. O problema se agrava
quando partimos para um contexto multi-projeto.
M. Chelaka L. Abeyasinghe; David J. Greenwood; D. Eric Johansen. An efficient method for scheduling construction projects with resource constraints.
International Journal of Project Management, Volume 19, Number 1, January 2001 , pp. 29-45(17).
S.M.T. Fatemi Ghomi; B. Ashjari. A simulation model for multi-project resource allocation. International Journal of Project Management,
Volume 20, Number 2, February 2002, pp. 127-130(4)
Detalhamento Técnicas Atuais
A teoria das restrições (TOC) iniciou-se dentro do domínio da produção
(leia-se manufatura). Método CPM.
“Todo sistema possui uma restrição que limita sua saída (se não
existisse, a saída cresceria para sempre).”
A principal idéia por trás da TOC é continuamente identificar a restrição
(gargalo) do sistema e trabalhar para melhorar a saída do sistema.
Uma solução ótima se deteriora com o tempo quando o ambiente do
sistema muda. Portanto, é necessário atualizar continuamente a forma
de agir.
“The Plan & Control processes defined by the PMBOK do not include a
way to handle decision branches in a project plan” !
O método CCPM reúne a TOC com os conhecimentos do PMBOK.
Consiste-se de uma nova teoria para o sistema de projeto.
Lawrence P. Leach. Critical Chain Project Management, 2005.
Conceitos principais do CCPM
Na manufatura: quando uma máquina atrasa, pode-se usar um pouco do estoque intermediário (menos perda).
Em projetos: Quando alguém atrasa, o tempo é perdido para sempre.
Não usar multitasking, pois isto atrasa qualquer tipo de projeto: trocas de contexto e entregas postergadas de todas as atividades.
O princípio da TOC: em um sistema ótimo, cada parte do sistema não pode desempenhar no nível ótimo (conflito raiz identificado por Deming).
Verificou-se que a ciência não pode fazer previsões sobre uma única instância de um evento estatístico. Isto levou ao seguinte insight: concentrar as incertezas das muitas atividades do projeto no fim do projeto, como um buffer.
Vantagens: (1) caminho menor, (2) estatisticamente, concentrar a contingência no final reduz a probabilidade de ocorrerem atrasos maiores. Tudo decorre da variação. Algumas tarefas terminarão antes e outras depois do previsto. A distribuição da soma não é tão grande quanto a soma das variações individuais porque algumas se cancelam mutuamente.
O Problema
Inputs
Pool de recursos e características individuais
Projetos com conjuntos de atividades distintas / template.
Atividades Gerenciais de Apoio
Regras definidas e parametrizadas pelo gerente de projetos por projeto
Aspectos importantes (inter/intra-projetos):
• Global: Ex. Máximo compartilhamento de recursos entre múltiplos projetos.
• Prioridade/Importância entre os projetos
• Deadlines (start-to-finish / finish-to-start)
• Dependências das atividades de apoio
• Restrições particulares dos recursos / coalizões (afinidade?)
• Atividades do projeto
• Recursos exclusivos
Outputs
Configurações de Projetos / Reconfigurações de Projetos
Com respostas “ont-the-fly”.
Objetivos Específicos
Identificar e formalizar os requisitos para uma solução de
reconfiguração dinâmica de projetos de software, que envolva o uso de
recursos compartilhados e com disponibilidade limitada, múltiplos
projetos simultâneos e a integração com fluxos organizacionais;
Elaborar um modelo que descreva a relação entre os diversos
elementos que compõem a reconfiguração dinâmica de projetos de
software;
Desenvolver uma estratégia para ajustar a alocação de recursos e o
seqüenciamento das atividades dos projetos, considerando um
conjunto de restrições sobre as atividades, os recursos e informações
sobre as variáveis globais de projeto;
Avaliar a proposta de solução, com o apoio de gerentes de projetos,
por meio de um protótipo.
Modelo Evento-Ação (Rev 01)
Solução
Conceitos CCPM
Não-Matemática / Baseada em heurísticas
Descentralizada / Distribuída
Baseada em sistemas de Agentes Inteligentes
Deve suportar coalizões (recursos, atividades)
“The system optimum is not the sum of the local optima”
Etapas
ETAPA 1
ESTUDO EM ABRANGÊNCIA
Qualidade de Software,
PMBOK, RUP, OPEN, MSF,
Outros processos de desenvolvimento.
ETAPA 2
ESTUDO EM PROFUNDIDADE
Modelos PMBOK, PMBOK+RUP,
PMBOK+OPEN e SPIM
Protótipos MRS e SPIT
Revisão Sistemática
ETAPA 3a
DESENVOLVIMENTO I
Estudo das atuais propostas
descentralizadas para o problema
Conceitos TOC, PERT/CPM e CCPM
ETAPA 3b
DESENVOLVIMENTO II
Identificação dos requisitos para
reconfiguração dinâmica
Formalização de um modelo de Eventos
e Ações para reconfiguração dinâmica
ETAPA 3c
DESENVOLVIMENTO III
Modelo Geral de Reconfiguração Dinâmica de Projetos de Desenvolvimento de Software
ETAPA 4
AVALIAÇÃO
Protótipo e Avaliação
ETAPA 5
FECHAMENTO
Redação final da Tese de Doutorado
PUCRS
Muito obrigado.
RECONFIGURAÇÃO DINÂMICA EM PROJETOS DE DESENVOLVIMENTODE SOFTWARE
Daniel Callegari
Estudo desenvolvido pelo Grupo de Pesquisa em Engenharia de Sistemas Inteligentes do PDTI,
financiado pela Dell Computadores do Brasil Ltda., com recursos da Lei 8.248/91.