reconfiguraÇÃo dinÂmica em projetos de … › ~niadr › triad › 2008 ›...

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


“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.


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!


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)


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.


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”.


“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”


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”


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.



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.


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

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

[email protected]

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.

reconfiguraÇÃo dinÂmica em projetos de … › ~niadr › triad › 2008 ›...

Documents