Home

Visualizar/Abrir

1. Ambiente Figura 3 Vis o geral da arquitetura do RUP JACO1 A dimens o din mica representa o tempo mostrando os aspectos din micos do processo atrav s de ciclos fases itera es e milestones De acordo com Jacobson Booch e Rumbaugh JACO1 o ciclo de vida do software divido em quatro fases concep o elabora o constru o e transi o e atrav s de sua caracter stica iterativa cada fase realizada com base no resultado da fase anterior de maneira a refinar o sistema at o momento em que o produto final esteja completo Cada fase possui um milestone e um conjunto de objetivos que devem ser utilizados para servir como guia no momento de decidir quais atividades desempenhar e quais artefatos devem ser produzidos BENO6 Cada fase no processo RUP atravessar diversas itera es Uma itera o um la o completo do desenvolvimento tendo por resultado uma libera o interna ou externa de um produto execut vel um subconjunto do produto final sob o desenvolvimento que cresce incremental de itera o em itera o at se transformar no sistema final JACO1 A dimens o est tica representa os aspectos est ticos descrevendo como os elementos do processo atividades disciplinas artefatos e pap is s o agrupados em workflows Assim um processo deve ser capaz de descrever quem como e quando uma determinada atividade est sendo desempenhada Desta forma o RUP representado atrav
2. 39 Figura 6 Componentes centrais ao framework do OPEN OPFOD 40 Figura 7 Exemplo de divis o entre Method Content e Process Structure 0MG12 41 Figura 8 Camadas de metamodelagem propostas pela OMG c een 43 Figura 9 Relacionamento entre projetos de software e fluxos organizacionais 45 Figura 10 Hierarquia de metan veis do MOF e eee erre rea 51 Figura 11 Metamodelo de integra o PMBOK RUP ROS08a ec eeee eee eeee es 53 Figura 12 Metamodelo de integra o PMBOK OPEN ROS12b 61 Figura 13 Metamodelo de integra o PMBOK SPEM ROS1 2a cccecceccseeeeeeeeeeees 65 Figura 14 Processo de revis o sistem tica adaptado de BIOO5 88 Figura 15 Sistemas a discretizado b discreto c a eventos discretos CARQ 7 96 Figura 16 Consumo de fichas pela rede de Petri CARQ7 ccccceceeecseeeeeeeeeseeeeeenees 98 Figura 17 Efeitos dos disparos de transi es ci erre rrere near 99 Figura 18 Convers o do diagrama de redes para a TCPN em 104 Figura 19 Representa o de uma atividade do projeto para uma ROP 105 Figura 20 Representa o de converg ncia de lugares em uma RdP 106 Figura 21 Representa o de fluxos paralelos em uma RdP
3. c 106 Figura 22 Representa o de um recurso executor de uma atividade para uma RdP 106 Figura 23 Comunica o entre diferentes formatos de representa o para redes de Petri adaptado Ge WV ED OZ G sinais papai canis tuceu ate Rials Di dean datas ca Sica 108 Figura 24 Duas redes representadas em PNML WEBO2 108 Figura 25 Exemplo de descri o de lugar com PNML eee 109 Figura 26 Exemplo de descri o de transi o com PNML iii in 110 Figura 27 Exemplo de descri o de arco com PNML ccccecseeseeseeseeseeeeeceeeeeeees 110 Figura 28 Exemplo de utiliza o da tagtoolspecific cccccceeccecceecceeceeceeeteeeeeeeeeeeeeaeees 111 Figura 29 Rede de Petri com dois lugares e uma transi o i 111 Figura 30 Resultado ap s disparo da transi o T1 erre 111 Figura 31 Um exemplo simplificado do formato PNML ri 112 Figura 32 Funcionamento geral do modelo de reconfigura o CAL1O 114 Figura 33 Composi o da f rmula padr o do modelo de refer ncia para reconfigura o din mica de projetos de desenvolvimento de software CAL10 cccceccseeeeeeeeenees 115 Figura 34 Processo para gera o de propostas usando arquitetura multiagentes SCH10 Figura 35 Modelo Conceitual de Eventos e elementos associados CAL1O 118 Figura 36
4. cccseeseeeeeseeeeeeeees 165 Tabela 15 Os benef cios percebidos na realiza o do planejamento integrado de atividades gerenciais e DrOGUIIVAS prse r errn an E E ERRE 166 Tabela 16 Recursos e pap is dispon veis para o Projeto 1 170 Tabela 17 Tarefas do Projeto 1 merisik a a ga vs pasa sa von ssa u sp A 170 Tabela 18 Informa es das tarefas para o Projeto 1 eee 171 Tabela 19 Informa es detalhadas das tarefas do Projeto 1 171 Tabela 20 Publica es relacionadas t Se cccccceccecceceeceeceeeeeeeceeteeeeeeeeeeeseeeeaeeaeeees 190 Tabela 20 Palavras chaves e sin nimos e eee ceara re era 217 Tabela 21 Procedimentos para o desenvolvimento do protocolo de avalia o 229 Tabela 22 Escalas das vari veis dependentes e independentes ccccecceeeeeeeees 233 1 SUMARIO INTRODU O aos tare sree oe US Heyer nor og ree mE IST A et ree GR A OSE ee ree A Sa 15 ASD IMORMACHO DA TESE ut seara soa of Pa Si a ENT 18 1 2 OBJETIVO GERAL DA PESQUISA cirein aha estate E aa ea Sabado na ab Resto deb e 21 L21 ODICUVOS espece OS units iate EA E O sida A A duas a ne DD ea AA 21 l o METODOLOGIA DE PE SOUSA saias e a 22 toT AlVIQADES da Pesq s aene E E OR sr aaa 23 TA ORGANIZA O DO MENTOS aa rae rat stunner Haack tala O a a a 25 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE E A GEST O DE PROJETOS 27 2
5. erre 158 Figura 52 Gr fico boxplot sobre o esfor o necess rio para o planejamento dos projetos Figura 53 Histograma sobre o esfor o para fazer o planejamento de atividades utilizando OS QOIS MClO0 OS vtacicccesnciaasennwvesccamnnssannsnaaanaadanschandanndasadentdmasdaund saadaaid sandaans EA 162 Figura 54 Gr fico boxplot em rela o a precis o para o planejamento dos projetos 164 Figura 55 Exemplo de um diagrama de rede de Petri erre 169 Figura 56 Cronograma do Projeto 1 cccccccceccceccceeceeeceseceeceeeceeseeseueseeeseeeseeeseeeseesaees 172 Figura 57 Rede de Petri para o cronograma do Projeto 1 172 Figura 58 Fluxo Organizacional contrata o de PESSOAS cccecceseeeseeeceeeeaeeeneeeeees 173 Figura 59 Interface de cadastro de projetos do BackOffice i 174 Figura 60 Interface de cadastro de pap is do BackOffice im 175 Figura 61 Interface de cadastro de produtos de trabalho do BackOffice 175 Figura 62 Exporta o de Pap is para o Microsoft Project i ii 176 Figura 63 Visualiza o dos campos personalizados para as atividades do projeto 177 Figura 64 Cronograma Parcial do Projeto 1 no Microsoft Project 177 Figura 65 Valida o do Projeto 1 pelo modulo SPIM Validator cceccseeeeeeeeseeeeees 178 Figura 66 Cen rio 1 recurso deixa a EMPSLeSA c
6. Intelligent systems in manufacturing current developments and future prospects Integrated Manufacturing Systems vol 11 4 2000 pp 218 238 MILES M B HUBERMAN A M Qualitative Data Analysis London Sage Publications 2 edition 1994 MILOSEVIC D PATANAKUL P Gerentes de Multiprojetos Quais compet ncias s o necess rias Revista Mundo PM N mero 11 2006 pp 62 68 MIYASHITA K SYCARA K CABINS a framework of Knowledge acquisition and iterative revision for schedule improvement and reactive repair Artificial Intelligence vol 76 1 1995 pp 377 426 MOURA A V Especifica es em Z Uma Introdu o UNICAMP 2001 MUHLEMANN A P LOCKETT G FARN C K Job shop scheduling heuristics and frequency of scheduling nternational Journal of Production Research vol 20 2 1982 pp 227 241 MURATA T Petri Nets Properties Analysis and Applications Proceedings of the IEEE vol 77 4 1989 MYERS B Foundations of WF an introduction to Windows Workflow Foundation Apress 2007 OASIS COMMITEE RELAX NG Specification The Organization for the Advancement of Structured Information Standards 2001 Capturado em http Awww relaxng org spec 20011203 html Maio 2012 OATO6 ODO99 OHA96 OKA00 OMG02 OMG09 OMG 10 0MG11 0MG12 OPE09 OUE03 OVA94 PAR96 PAROO OATES B Researching Inf
7. O cronograma correspondente para o Projeto 1 mostrado na Figura 56 No topo da figura h uma r gua de tempo que facilita visualizar a aloca o de cada tarefa no tempo Percebe se desta forma que o projeto tem dura o total de 21 unidades de tempo e que as tarefas DEV1 e DEV3 n o s o cr ticas possuem folga Assim o projeto inicia com a tarefa INP no tempo 1 depois segue com a tarefa ANR que ocupa os tempos de 3 a 8 com suas 6 unidades de dura o e assim sucessivamente is BARAUA RS RR A a em A TA TATTOO rae a E a E PART TTT TT ee MeO TTT lo Ea LAs ef P tt o pt A P S A a MSS S T T T T f TO o o Ref IL S EMPL TTT TTT tT tet te o Figura 56 Cronograma do Projeto 1 A Figura 5 7 ilustra a rede de Petri gerada pelo prototipo SPIT para representar as atividades do cronograma do Projeto 1 Conforme ilustrado nesta figura a ficha token permanece no lugar que representa a atividade Inicia o do Projeto INP O tempo de execu o de cada atividade est representado nas transa es desta rede de Petri Assim a legenda T1 2 informa que a transa o T1 deve demorar duas unidades de tempo para passar a ficha para o pr ximo lugar An lise de Requisitos ANR IHF T102 ANR TAS DAR TH MED Figura 57 Rede de Petri para o cronograma do Projeto 1 173 O modelo SPIM entretanto foi concebido considerando a complexidade de identificar as rela es de depend ncia entre as
8. SPI M Reconfigura o Din mica de Projetos de Desenvolvimento de Software Usu rios rea Restrita Experimento Seja bem vindo a Teste Usu rio rea restrita deste site Palestras Neste espa o voc poder fazer download de materiais participar de experimentos e ficar atualizado das pesquisas realizadas por este grupo Sair p grup Avenida Ipiranga 6681 Pr dio 32 Sala 110 Bairro Partenon Porto Alegre RS CEP 90619 900 Figura 92 Tela de acesso restrito do portal Neste espa o os usu rios poderiam atualizar seus dados cadastrais obter informa es sobre outras palestras relacionadas a esta rea de estudo e principalmente ter acesso aos formul rios relacionados ao estudo experimental Figura 93 Maiores detalhes sobre os formul rios do estudo experimental s o apresentados no Ap ndiceE Estudo experimental sobre o SPIM Participante Teste Usu rio Orienta es Por favor preencha o question rio de avalia o do perfil dos entrevistados Em seguida preencha os cinco cen rios de avalia o do modelo intrerado SPIM que ir o simular situa es em projetos de desenvolvimento de software Ao final preencha o question rio de avalia o do modelo SPIM Sua colabora o muito importante para o sucesso dessa pesquisa acad mica Por favor complete todos os passos abaixo para efetivar sua participa o neste experimento Passos e Question rio de avalia o do perfil dos entrevistados e
9. apresentando em sua maioria conhecimento pr vio sobre processo de desenvolvimento de software e gest o de projetos al m de experi ncia em ind stria de software Validade de constru o Durante nosso experimento ser o avaliados Inadequada explica o pr operacional consiste na explica o operacional do experimento visando maturar a forma na qual ser definida a extra o dos dados Adivinha o de hip teses devido ao fato dos participantes serem humanos poss vel sua intera o com o experimento sugerindo novas hip teses e exercitando a criatividade importante manter o foco no estudo planejado Expectativas do condutor do experimento ao se conduzir um experimento o respons vel pode exercer influ ncias sobre as vari veis envolvidas e sobre o material elaborado Durante a presente proposta todo o material utilizado ser previamente avaliado por outro respons vel Validade da conclus o Ser o avaliadas as seguintes perspectivas Manipula o dos dados como os dados resultantes do experimento ser o manipulados pelo pesquisador poss vel que os mesmos sofram algumas varia es tal como o coeficiente de signific ncia para valida o dos resultados Confiabilidade das medidas esta perspectiva sugere que medidas subjetivas possam ser influenciadas pelo pesquisador Em nossa proposta as medidas foram objetivamente definidas n o dependendo do crit rio humano Confiabilidade na implem
10. definido pela interface EventSource Qualquer inst ncia de EventSource pode portanto provocar um evento de 118 reconfigura o ReconfigurationEvent Para exemplificar um projeto pode mudar de prioridade um recurso pode se ausentar por um per odo ou uma atividade pode ter suas estimativas revisadas Ainda os eventos de reconfigura o foram classificados como internos ou externos InternalEvent e ExternalEvent raises gt lt lt abhelract gt gt ReconfigurationEvent a 4 composed by gt lt lt interface gt a EventSource InternalEvent ExternalEvent EN i 1 Constraint lt lt abstract gt gt l ProjectElement PN a affects Resource o Activity WorkProduct Ea 4 ActivityDependence ActivityGroup ActivityDependence Resource SkillLevel gt f a a aa Te ResourceSkillLevel ExpectedSkillLevel Figura 35 Modelo Conceitual de Eventos e elementos associados CAL10 responsible B Callegari CAL10 justifica que o modelo conceitual apresentado acima composto apenas pelos elementos considerados essenciais para a reconfigura o de projetos Conforme o autor a inclus o de todos os elementos apenas adicionaria complexidade explica o de forma que muitos elementos foram considerados secund rios Observa se entretanto que este modelo contempla de forma sucinta a integra o das atividades dos projetos de software com os fluxos organizacionais Outro ponto importante
11. o de diferentes recursos TSAO3 No caso de cen rios com multiplos projetos o impacto poder ser ainda maior Em sua pesquisa Engwall e Jerbrant ENGO3 analisaram a chamada sindrome da aloca o de recursos em um contexto de m ltiplos projetos e constataram que os projetos se caracterizam por in meras interdepend ncias justamente porque dependem dos mesmos recursos Assim identificou se o problema de defini o de prioridades e consequentemente de aloca o desses recursos 83 Para se desenvolver o modelo de reconfigura o proposto neste documento foi necess rio identificar quais eventos perturbam o andamento dos projetos Os eventos que demandam a reconfigura o din mica de projetos de software foram extra dos da disserta o de mestrado de Schlosser SCH10 e da tese de doutorado de Callegari CAL10 Estes trabalhos realizaram uma revis o bibliogr fica para a identifica o dos eventos conduzida atrav s de uma revis o sistem tica Ap s aplicaram um surveycom gerentes de projetos de software com o objetivo de avaliar a frequ ncia e o impacto dos eventos identificados A combina o dos valores relativos frequ ncia e ao impacto proporcionou estabelecer uma ordem de prioridade para atacar os tipos de evento Cabe salientar que os motivos originais da ocorr ncia dos eventos n o s o considerados relevantes para a pesquisa Para exemplificar em um evento como a sa da de um recurso do projeto desco
12. Casos representam a es adequadas de reparo O racioc nio baseado em casos permite capturar e reusar desse conhecimento para reparar situa es semelhantes A programa o reparada de forma incremental quando necess rio utilizando os casos armazenados no sistema Redes neurais redes de Petri e l gica fuzzy tamb m foram utilizadas para resolver o problema de programa o din mica Extensas discuss es sobre estas t cnicas podem ser encontrados em Suresh e Chaudhuri SUR93 Szelke e Kerr SZE94 Zweben e Fox ZWE94 Kerr e Szelke KER95 Meziane et al MEZOO Para obter uma melhor programa o de sistemas din micos alguns pesquisadores desenvolveram sistemas h bridos que combinam diversas t cnicas de intelig ncia artificial Schmidt SCH94 usou a l gica fuzzy para diagnosticar trabalhos cr ticos a fim de reprogram los Como resultado o gerente recebe as informa es sobre quais as atividades devem ser reagendadas agora em breve ou mais tarde Garetti e Taisch GAR95 e Garner e Ridley GAR94 usaram sistemas baseados em conhecimento e redes neurais na programa o reativa As redes neurais foram usadas para decidir sobre o melhor conjunto de regras para definir quais atividades realizar quando ocorre um evento em tempo real 4 1 2 4 Compara o entre as T cnicas Pesquisadas A fim de verificar o valor das v rias t cnicas propostas foi verificado que alguns trabalhos foram publicados comparando algumas de
13. O gr fico boxplot foi utilizado para identificar outliers ver Figura 54 de maneira similar an lise da primeira hip tese De acordo com este gr fico observou se que a vari vel de precis o n o tem outliers 164 1 00 a To So Accuracy nd o o T 09 D o U1 0 40 Traditional SPIM Project Planning Method Figura 54 Gr fico boxplot em rela o precis o para o planejamento dos projetos O passo seguinte foi identificar se os dados tem uma distribui o normal Para atingir este objetivo as hip teses seguintes foram definidas Ho uma distribui o normal H n o uma distribui o normal O teste de Shapiro Wilk mostra se o crit rio para o teste T est sendo cumprido ver Tabela 12 Tabela 12 Resultados do teste de Shapiro Wilk para a vari vel precis o Vari vel M todo Estat stica Grau de Signific ncia Liberdade Precis o Tradicional 0 926 18 0 195 SPIM 0 912 18 0 022 Considerando os mesmos pressupostos para a vari vel esfor o comparando diretamente p value com a n vel de signific ncia observa se que p value 0 022 gt 0 05 faz rejeitar Ho quando se considera a utiliza o do modelo SPIM Portanto um teste param trico como o teste T n o poderia ser usado No entanto o teste de Mann Whitney pode ser usado nestes casos Ele teste nao parametrico de amostras independentes an logo ao teste T e pode ser usado quando n o se assume que a vari vel dependente p
14. R Figura 6 Componentes centrais ao framework do OPEN OPF09 is documented using g Um produtor o elemento respons vel por produzir ou modificar direta ou indiretamente os artefatos do processo Os produtores podem ser ferramentas ou pessoas definidas atrav s de pap is A classe WorkUnit consiste de um conjunto de opera es coesas executadas pelo produtor no desenvolvimento seu trabalho e podem ser classificadas como tarefas t cnicas fluxos de trabalho e atividades Finalmente a classe Stage determina as divis es de intervalos de tempo do processo sendo dividida em est gios com dura o fases e instant neos milestones 41 2 4 4 Software amp Systems Process Engineering Meta Model Specification SPEM 2 4 4 1 Defini o e Aspectos Relacionados Nesta pesquisa o Software Process Engineering Metamodel Specification SPEM 0MGO12 foi utilizado como principal processo de desenvolvimento de estudo A escolha do SPEM deve se ao fato deste ser considerado peloObject Management Group OMG OMGO9 o principal template para modelos de processos de desenvolvimento de software Al m disto sua utiliza o torna esta proposta aplic vel a todos os processos de desenvolvimento de software que tiveram sua origem a partir deste metamodelo Nesse sentido esta se o fornece uma vis o geral deste metamodelo O interesse descrever resumidamente como est o organizados seus elementos e relacionamentos O SPEM 2 0
15. reas de apoio durante o planejamento do projeto de software Esta solu o deve considerar a complexidade de identificar a interdepend ncia entre as atividades dos fluxos organizacionais e o fluxo de trabalho do projeto Portanto para conciliar estas duas vis es o gerente de projeto deve lidar com quest es tanto de gest o quanto de produ o durante o planejamento e a execu o de projetos considerando n o apenas as atividades que produzem resultados diretos no projeto de software mas tamb m as atividades que pertencem de forma compartilhada a outros projetos aos fluxos organizacionais da empresa 46 Entretanto os modelos de ger ncia de projetos e os processos de desenvolvimento de software atuais n o apresentam uma solu o que permita o planejamento de projetos de software considerando as intera es do gerente de projetos com outros departamentos da organiza o Esta solu o deve considerar a complexidade de identificar a interdepend ncia entre as atividades dos fluxos organizacionais e dos fluxos dos projetos 3 2 A Necessidade de Integra o A ger ncia de projetos em um ambiente de desenvolvimento de software definida como a ger ncia das pessoas e de outros recursos por um gerente de projetos a fim de planejar analisar projetar construir testar e manter um sistema de informa o SCHO2 Para cumprir estes objetivos um gerente de projetos precisa de algum tipo de suporte geralmente baseado em uma m
16. 1 Para cada arco no conjunto que parte de lugares o primeiro elemento do par adicionado ao conjunto de lugares da rede e o segundo elemento ao seu conjunto de transi es 2 Para cada arco no conjunto que parte de transi es se o primeiro elemento do par ainda n o estiver no conjunto de transi es da rede ele adicionado se o segundo elemento ainda n o fizer parte do conjunto de lugares ele adicionado 3 Todos os arcos s o adicionados ao conjunto de arcos da rede Pode se verificar desta forma que a RdP pode ser recuperada a partir do seu conjunto de arcos Assim o simulador desenvolvido considera apenas os arcos para representar a estrutura da rede Duas tabelas s o preenchidas uma para os arcos que entram em uma transi o tabela de entrada e outra para os que partem da transi o tabela de sa da Por quest es de otimiza o conforme observado na Figura 50 as tabelas de entrada e de sa da foram estruturadas hierarquicamente As tabelas de entrada e saida s o compostas por uma tabela principal e v rias tabelas secund rias Cada tabela principal cont m os identificadores dastransi es como chave Assim cada chave est associada uma tabela secund ria As tabelas secund rias cont m como chave osidentificadores dos lugares que se conectam a transi o relacionada na tabela principal atrav s deum arco Os valores nesta tabela secund ria s o os pesos dos arcos Tabela Hash Secund ria Tabela Hash
17. CAL10 Os quatro elementos normalizados nesta f rmula E a Es sao e E1 o grau de adequabilidade do recurso posi o de trabalho 116 e E2 o ndice Objetivo de Aloca o dos Recursos IOBJALOC e E3 a prioridade do projeto ao qual a tarefa pertence e E4 acriticidade da tarefa se cr tica ou n o Assim esta f rmula compartilhada por todos os recursos e proposta por eles para que o modelo possa decidir a realoca o de recursos A proposta elaborada por Schlosser SCH10 entretanto apresenta um solver baseado na abordagem de sistemas multiagentes Nesta solu o os agentes gerenciam suas agendas e interagem entre si a fim de possibilitar o envio de propostas de aloca o quando ocorre o recebimento de CFP s O modelo de modelo de refer ncia para reconfigura o din mica de projetos de desenvolvimento de software CAL10 permite a adi o de novos solvers de modo que o solver proposto por Schlosser SCH10 detalhado a seguir A arquitetura da solu o proposta por Schlosser SCH10 compreende duas classes internas de agentes Agente Gerenciador de Propostas e Agente Recurso Na classe Agente Gerenciador de Propostas existe apenas uma inst ncia desse agente J na classe Agente Recurso existe o n mero de inst ncias correspondentes aos recursos dispon veis O agente Gerenciador de Propostas tem como atribui o principal receber uma CFP e encaminhar as posi es de trabalho contidas nela aos agentes c
18. Francis 2001 SHUKLA C S CHEN F F The state of the art in intelligent real time FMS control a comprehensive survey Journal of Intelligent Manufacturing vol 7 1996 pp 441 455 SMITH R The Contract Net Protocol High Level Communication andControl in a Distributed Problem Solver EEE Transactions on Computer vol C 29 N 12 1980 pp 1104 1113 SMULLYAN R M First Order Logic Dover Publications Inc New York 1995 157p SODERHOLM A Project Management of Unexpected Events International Journal of Project Management vol 26 2008 pp 80 86 SOLINGEN R BERGHOUT E The Goal Question Metric Method New York McGraw Hill 1999 SOMMERVILLE l edition 2006 STOOP P P M WEIRS V C S The complexity of scheduling in practice nternational Journal of Operations and Production management vol 16 10 1996 pp 37 53 Management Software engineering Addison Wesley 8 SUN J XUE D A dynamic reactive scheduling mechanism for responding to changes of production orders and manufacturing resources Computers in Industry vol 46 2 2001 pp 189 207 SURESH V CHAUDHURI D Dynamilc scheduling a survey of research International Journal of Production Economics vol 32 1 1993 pp 53 63 SZELKE E KERR R M Knowledge based reactive scheduling Amsterdam North Holland 1994 THA97 TRAO2 TSAO3 TYROO UHE
19. atividades e com nfase na integra o da ger ncia de projetos com os fluxos organizacionais das empresas Para avalia o do modelo e materializa o da proposta foi desenvolvido um prot tipo de uma ferramenta de software Inscri o Fa a sua inscri o aqui Figura 88 Tela sobre a inscri o para a palestra Em seguida o usu rio era convidado a preencher o formul rio de inscri o para a palestra uma vez que se tratava de um evento com lugares limitados conforme visto na Figura 89 226 Inscri o Preencha este formul rio para fazer sua pr inscricao nesta palestra Para os Inscritos posteriormente sera enviado por email uma senha para acesso ao material desta apresenta o resultado deste experimento e outros materiais relacionados ao assunto Login Senha s Confirma o de Senha Nome a Email TES EN ENVIAR Figura 89 Formul rio de inscri o para a pilastra C 4 APRESENTA O DO PROJETO A Figura 90 apresenta a p gina que cont m informa es sobre as publica es deste grupo de pesquisa sobre assuntos relacionados rea de gest o de projetos Publica es Nesta se o apresentada a produ o cient fica recente deste grupo de pesquisadores relativo a tem tica desta palestra e CALLEGARI D Reconfigura o Din mica de Projetos de Desenvolvimento de Software Tese de Doutorado PUC RS Porto Alegre 2010 e SCHLOSSER R Gerenciamento Distribu do de
20. independentes se for realizado um teste parametrico ou o teste Mann Whitney se for um teste n o param trico Esta defini o deve ser tomada depois da verifica o se a distribui o normal ou n o pelo teste Shapiro Wilk e da verifica o da varia o dos dados obtidos atrav s da execu o do experimento teste Levene Esta fase tamb m envolve documentar os resultados de modo a permitir a sua replica o em diferentes circunst ncias O desempenho do experimento em diferentes contextos permite a aquisi o de novos conhecimentos sobre os conceitos estudados Na se o seguinte ser detalhada a an lise dos dados obtidos neste experimento 7 1 2 An lise dos Resultados do Experimento A primeira an lise dos dados brutos obtidos no experimento est relacionada com os seus tipos de escala Ao trabalhar com vari veis e m tricas precisa se considerar os diferentes tipos de escala de medi o Os tipos de escala mais comuns s o nominal 160 intervalo ordinal e raz o FEN97 KIT96 O tipo de escala determina o tipo de m todo de an lise dos dados que deve ser aplicado para se obter as respectivas conclus es sobre o experimento Assim a vari vel independente em rela o aos m todos de planeamento de software representada como sendo uma escala nominal e as vari veis dependentes sobre a precis o s o representadas por uma escala de raz o As vari veis dependentes s o caracterizadas pela escala de raz
21. lt graphics gt lt position x 30 y 10 gt lt dimension x 8 y 2 gt lt graphics gt lt name gt lt text gt ti lt text gt lt graphics gt SHELL XT prelo gt lt graphics gt lt name gt lt transition gt Figura 26 Exemplo de descri o de transi o com PNML Os arcos sao definidos atraves de um identificador e dos seus elementos de origem e destino utilizando se a tag lt arc gt AFigura 2 mostra um exemplo de arco Pode se definir um conjunto de pontos pelos quais o desenho do arco deve passar utiliza se o elemento graphics para definir estas informa es Outro atributo importante de um arco a sua inscri o que pode definir o seu peso comoem redes Place Transition ou sua express o como nas redes Coloridas Para oferecer maiorflexibilidade a inscri o definida como um elemento de texto utilizando se por isso a tag text lt arc 1d al source p1 target t1 gt lt graphics gt position x 20 y 10 gt position E 2 y 10 gt lt graphics gt lt inscription gt lt text gt 2 lt text gt lt graphics gt lt OLISCE HS YE J gt lt graphics gt lt inscription gt lt arc gt Figura 27 Exemplo de descri o de arco com PNML Utiliza se a tag lt toolspecific gt para representar informa es especiais que s o dependentes de uma determinada ferramenta Assim o conte do de um elemento toolspecific definido pela ferramenta correspondente confor
22. nuo a fim de manter o controle desses tipos de depend ncias Para este estudo cada fluxo organizacional considerado como um conjunto de atividades que podem ser consumidos por um ou mais projetos de software As atividades gerenciais de apoio fazem parte dos fluxos organizacionais Assim o SPIM permite que cada inst ncia de um fluxo de trabalho organizacional seja registrada como uma atividade gerencial de apoio nos projetos de desenvolvimento de software De acordo com Leymann e Roller LEY00 a tecnologia de workflow uma ferramenta poderosa que 125 pode ser beneficamente utilizada para o gerenciamento de projetos Desta forma um sistema de workflow pode constantemente atualizar e informar os projetos as informa es de cada inst ncia de fluxo organizacional A an lise de como o conhecimento sobre ger ncia de projetos permite aperfei oar os processos de desenvolvimento de software atuais torna poss vel o desenvolvimento de novas ferramentas capazes de suportar diferentes n veis de automatiza o no planejamento e na execu o de atividades num projeto de software Por essa raz o O modelo integrado foi desenvolvido com os seguintes os objetivos e permitir o planejamento de projetos considerando os elementos que comp em a ger ncia de projetos e os processos de desenvolvimento de software e fazer a distin o dos tipos de atividades gerencial ou produtiva e produtos e adicionar a no o de disponibilidade a um rec
23. o executados em paralelo t m seus pr prios recursos e podem influenciar no tempo das atividades e nos custos do projeto O gerente de projeto pode precisar portanto de algum tipo de suporte durante o processo de tomada de decis o levando em conta a integra o dos diferentes conjuntos de atividades durante a execu o simult nea de projetos de software Esta pesquisa considera o uso de redes de Petri RdP para simular o comportamento din mico dos projetos de software A rede de Petri uma ferramenta gr fica e matem tica para a modelagem an lise e verifica o de sistemas MUR89 Assim as redes de Petri podem ser aplicadas em diversas reas tais como a modelagem de sistemas de banco de dados distribu dos projeto e an lise de workflows e processos de neg cios entre muitos outros MU89 ZHO95 A RdP considerada uma importante ferramenta de an lise devido asua capacidade de ser descrita como sendo um conjunto de equa es alg bricas MU89 ZHO95 VAN98 Dessa forma as redes de Petri podem ser utilizadas para auxiliar no projeto an lise e simula o dos v rios cen rios que ocorrem em projetos de software Com base nessas premissas foi realizado um estudo para determinar o estado da arte sobre a reconfigura o din mica de projetos de software com nfase na integra o da gest o de projetos com os fluxos organizacionais a fim de identificar as principais lacunas e desafios de investiga o neste campo Para
24. s de quatro elementos prim rios de modelagem pap is quem atividades como artefatos o qu e fluxos quando Um papel define o comportamento e as responsabilidades de um individuo ou grupo de indiv duos que trabalham juntos como uma equipe JACO1 Os pap is s o respons veis pela execu o das atividades do processo em cada uma das fases Um indiv duo pode executar as tarefas de um ou mais 3 papeis da mesma forma que um grupo de individuos pode executar as atividades de um mesmo papel Uma atividade uma unidade de trabalho que define como tarefas reais atribu das a um papel devem ser executadas no contexto do projeto RATO6 Toda atividade deve ser atribuida a um papel A atividade tem um prop sito claro normalmente expresso em termos de criar ou modificar artefatos Um artefato um peda o de informa o que produzido modificado ou usado por um processo RATO6 Os artefatos s o usados como entradas para executar uma atividade e s o o resultado ou a sa da de tais atividades Os artefatos possuem diferentes formas de apresenta o tais como modelos elementos de modelo documentos c digos fonte e execut veis Deve se ainda considerar que um artefato pode ser composto de outros artefatos Os fluxos s o as sequ ncias de atividades que atrav s das itera es entre os pap is produzem um resultado de valor observ vel RAT06 No RUP pode se dividir os fluxos em dois grupos principais fluxos centrais cor
25. tese de que a esfor o m dio para fazer o planejamento das atividades usando o modelo tradicional igual ao esfor o realizado com o uso do modelo de SPIM Observou se que a m dia de esfor o em minutos para realizar a programa o das atividades usando o modelo de SPIM foi de cerca de 48 minutos enquanto que o uso do modelo tradicional que foi de cerca de 43 minutos a diferen a entre estas duas medidas diferen a m dia de somente 5 minutos Desta forma o pequeno aumento no esfor o ocasionado pelo preenchimento dos campos adicionais propostos pelo modelo SPIM compensado pela quantidade de informa es extras que podem auxiliar o gestor a aumentar a precis o do planejamento dos projetos esta verifica o pode ser observada pela an lise da segunda hip tese precis o Durante a defini o dos objetivos deste experimento item 7 1 1 1 Defini o dos Objetivos do Experimento identificou se como um dos objetivos verificar se o esfor o para realizar o planejamento das atividades do projeto de software usando o modelo integrado SPIM igual ao esfor o para realizar o planejamento das atividades de acordo com o modelo tradicional Conforme os resultados apresentados pode se concluir que estatisticamente n o h diferen a significativa em rela o ao esfor o para se realizar o planeamento de projetos de software utilizando o m todo tradicional em rela o ao m todo SPIM 7 1 2 2 Segunda Hip tese Precis o
26. ticas em duas dimens es l gicas Uma dimens o descreve as reas de conhecimento classe KnowledgeArea enquanto que a outra dimens o descreve os processos gerenciais de um projeto classe Management Process OS quais est o contidos em cinco grupos de processo classe ProcessGroup s reas de conhecimento s o respons veis por descrever as principais compet ncias que os gerentes de projetos devem desenvolver e derivam as reas centrais classe CoreKnowledgeArea e as de apoio classe FacilitatingKnowledgeArea Assim cada atividade gerencial pertence a um processo gerencial sendo tamb m relacionada a uma rea de conhecimento Neste modelo o pacote RUP define uma disciplina classe Discipline como sendo a divis o de elementos de processo em reas de interesse Cada disciplina composta por um ou mais fluxos de trabalho classe WorkflowDetail Os fluxos de 57 trabalho definem como os pap is produtivos devem colaborar entre si atrav s de suas atividades Um produto de trabalho classe workProduct pode ser classificado como um produto gerencial classe Deliverable ou produtivo classe Artifact o qual deve estar associado a um tipo de produto classes DeliverableType e ArtifactType respectivamente Cabe salientar que o modelo faz distin o das poss veis rela es entre uma atividade e um artefato criar atualizar consultar Isto importante para apoiar a consist ncia do modelo a partir de regras tais como as ap
27. todos de busca na vizinhan a baseadas na id ia de procurar seus vizinhos Em busca de vizinhan a local a busca come a a partir de uma determinada solu o e tenta de forma iterativa avan ar para uma solu o melhor em uma determinada vizinhan a da solu o atual usando operadores que se movem O processo de busca encerra quando n o h melhor solu o para ser encontrada na vizinhan a da solu o atual de modo que este considerado o local ideal ou timo Meta heuristicas como a busca tabu simulated annealing e algoritmos geneticos aprimoraram a busca local para escapar dos locais ideais ao aceitar solu es piores ou atrav s da gera o de boas solu es de partida para a busca local de uma forma mais inteligente do que apenas fornecer solu es iniciais aleat rias Busca tabu simulated annealing e algoritmos gen ticos t m sido amplamente utilizados para resolver problemas deterministicos est ticos de programa o de atividades em v rios dom nios No entanto poucas pesquisas abordam o uso de meta heuristicas na programa o din mica 4 1 2 3 3 Programa o Din mica baseada em Ambiente Multiagentes Tradicionalmente os sistemas de controle de cronogramas desenvolvidos em ambientes empresariais t m sido visto como um processo top down de comando onde resposta que depende fortemente de modelos centralizados e hier rquicos PAR96 GOU98 SHE99 BOMOO SHEO1 Para garantir a consist ncia dos dados em toda
28. 1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DEFINI O E ASPECTOS RELACIONADOS 27 2 2 PROCESSO PADR O DE DESENVOLVIMENTO DE SOFTWARE ccccsscsscssceccescescsscsscessessesecseeseensesseeseessessessenes 29 2 3 GESTAO DE PROJETOS DE SOFTWARE psi iai dd A A 30 2 4 METAMODELOS E MODELOS DE GEST O DE PROJETOS E DE PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE nato ao E A a N 31 2 4 1 Project Management Body of Knowledge PMBOK ccccccccccesssscccceesssseecceeessseeceeeessseeeeeenseeeees 32 282 dRational UNINC PROCESS RUP eaan E A E A aa 2 4 3 Object Oriented Process Enviroment and Notation OPEN 38 2 4 4 Software amp Systems Process Engineering Meta Model Specification SPEM 4 2 95 CONSIDERA ES FINAIS DO CAP TULO siinon castensitaeietepeaineibsesach este nth E E ceateele 43 INTEGRA O DOS PROJETOS DE SOFTWARE COM OS FLUXOS ORGANIZACIONAIS 44 3 1 FLUXOS ORGANIZACIONAIS DEFINI O E CONCEITOS RELACIONADOSG cccccscesscesseeeseceseeseeesseeeseeeseeenees 44 3 2 A NECESSIDADE DE INTEGRA CAO saida paia ea n vel tan GE ia asa e EENES 46 3 3 MODELOS INTERMEDI RIOS DE INTEGRA O ccc ccsscssssesssccsscssscesencsnscessceseseenseeseesscscenseesacsscseesseessensaneenees 49 3 3 1 Modelo Integrado para o PMBOK e 0 RUP samicemi a E s 52 3 3 2 Modelo Integrado para o PMBOK e0 OPEN ecitar a e eiii Ea i aia 57 3 3 3 Modelo Integrado para PMBOK e o SPEM ireccio i 63 3 4 C
29. 107 Pode se verificar que cada constru o iniciada com lugar es e terminada com transi o es possibilitando que seja simplificado o arranjo das constru es Desta forma os arcos correspondem diretamente s rela es de preced ncia presentes em um projeto de software O tempo em que cada atividade executada est relacionado ao tempo de espera em cada estado da rede Assim quando uma atividade conclu da a pr xima atividade deve ser executada ap s o tempo de espera determinado pela rede 5 4 Petri Net Markup Language Aus ncia de um padr o para representa o das redes de Petri e a populariza o do uso de ferramentas de modelagem resultou no desenvolvimento de diferentes formatos de representa o destas redes A colabora o entre estas diferentes ferramentas poderia trazer diversos benef cios BILO3 ampliando as possibilidades de simula o e valida o dos modelos desenvolvidos Com base neste cen rio a comunidade acad mica tem realizado esfor os na cria o de um formato de representa o padr o intercambi vel entre ferramentas de modelagem com redes de Petri Uma das propostas que setornou bastante popular a da linguagem PNML Petri Net Markup Language WEBO2 Trata se de um padr o baseado em XML eXtensible Markup Language WCG04 que tem comoobjetivo representar as caracter sticas comuns a todos os tipos de redes de Petri Embora a PNML ainda n o seja aceita por todas as ferramentas exist
30. 2011 12110 2011 20 Elaborar Especi 2 dias 1140 2011 12 10 2011 16 Fulano 6 29 Executar Testes 2 dias 150 2011 14 10 2011 30 Executar Plano 2 dias 1310 2011 14 10 2011 28 Fulano 7 31 Finalizar Fase de Cons 1 dia 24 10 2011 24 10 2011 26 30 J2 Transi o 2 dias 25 10 2011 26 10 2011 33 Integrar Sistema 2 dias 25 10 2011 26 10 2014 Prepara o e W 1 dia 210 2011 2n 10 2011 31 Fulano 2 35 Revisar Projeto 1 dia 26 10 2011 26 10 2011 34 Fulano 2 a6 Disponibiliza o da 2 dias 26 10 2011 27 10 2011 af Acompanhamento t 2 dias 26 10 2011 270201134 Fulano 1 Teste de Aceita o 2 dias 2610 2011 2f 1 02011 34 Fulano 6 39 Fechar Projeto 1 dia 28 10 2011 26 10 2011 40 Reuni o para Ence 1 dia 2810 2011 28 10 2011 37 38 Fulano 1 4 Finalizar Projeto 1 dia 3110 2011 31 10 2011 40 Figura 98 Projeto para o cen rio 4 245 E 5 CEN RIO 5 Veja abaixo a descri o das atividades propostas para o cen rio 5 Cen rio 5 Participante Teste Usu rio Download Clique aqui para fazer download do cen rio 5 Fluxos Organizacionais RH Contratar Fluxo Organizacional respons vel pela contrata o de pessoas RH Treinamento Fluxo Organizacional respons vel pelas atividades de treinamento da equipe Financeiro Comprar Fluxo Organizacional respons vel pela aquisi o de equipamentos Negocios Parceria Fluxo Organizacional respons vel pela realiza o de parcerias e contrata o de empresas terceiriza
31. Agendas de Recursos para Projetos de Desenvolvimento de Software baseado em Sistemas Multiagentes Disserta o de Mestrado PUC RS Porto Alegre 2010 e CALLEGARI Daniel Antonio BASTOS R M A Multi Criteria Resource Selection Method for Software Projects using Fuzzy Logic In ICEIS 2009 11th International Conference on Enterprise Information Systems 2009 Milan Enterprise Information Systems Berlin Springer Verlag 2009 v LNBIP p 376 388 e CALLEGARI Daniel Antonio Foliatti F L BASTOS R M MRES Ferramenta para Sele o de Recursos para Tarefas de Projetos de Software via Abordagem Difusa Multicrit rios In XVI Sess o de Ferramentas SBES 2009 Fortaleza Sess o de Ferramentas 2009 XVI Sess o de Ferramentas SBES 2009 p 61 66 e CALLEGARI D BASTOS R M A Systematic Review of Dynamic Reconfiguration of Software Projects XXII Simp sio Brasileiro de Engenharia de Software SBES 2008 Campinas 2008 227 e CALLEGARI ROSITO BASTOS RIBEIRO An Integrated Model for Managerial and Productive Activities in Software Development ICEIS 2008 Int Conf on Enterprise Information Systems 2008 e M ROSITO D CALLEGARI R BASTOS Ger ncia de Projetos e Processos de Desenvolvimento de Software uma proposta de integra o iSys Revista Brasileira de Sistemas de Informa o PPGI UNIRIO v 1 p 88 115 2008 e ROSITO M CALLEGARI D BASTOS R Ger ncia de Projetos e Process
32. CAL10 e Schlosser SCH10 Dessa maneira foram desenvolvidos projetos de software hipot ticos contendo recursos alocados s tarefas Todos os casos de avalia o foram executados sobre um cen rio composto por dez tarefas sete recursos e seis pap is Apesar do tamanho reduzido poss vel demonstrar as regras propostas pelo modelo SPIM vide Cap tulo 6 Quando uma condi o espec fica necess ria comentam se quais foram as altera es necess rias para demonstrar algum evento Tamb m foram desenvolvidos fluxos organizacionais que ser o associados a estes projetos de software 170 Primeiramente devem se considerar os recursos que estao disponiveis para os cenarios desta pesquisa Os recursos sao identificados com nomes proprios neste caso Mauricio G ssica Enzo Mario Fernando Laura e Jose Os pap is definidos foram Gerente de Projetos Analista de Sistemas Desenvolvedor Testador Integrador e Projetista de Banco de Dados A Tabela 16 reune os recursos e os pap is em que cada integrante do projeto pode assumir tamb m define se um papel possui perfil gerencial ou produtivo Tabela 16 Recursos e pap is dispon veis para o Projeto 1 Recursos Pap is Perfil Mauricio Gerente de Projetos Gerencial Gessica Analista de Sistemas Produtivo Laura Analista de Sistemas Produtivo Mario Desenvolvedor Testador Produtivo Enzo Desenvolvedor Produtivo Fernando Desenvolvedor Integrador Produtivo Jos Projetista de Banco
33. DE SOFTWARE COM OS FLUXOS ORGANIZACIONAIS RESUMO Projetos de software s o muito din micos e requerem recorrentes ajustes de seus planos de projeto Estes ajustes podem ser entendidos como reconfigura es na programa o aloca o de recursos entre outros elementos de design A grande quantidade de informa es que o gerente de projetos deve lidar combinado com as frequentes mudan as no escopo e planejamento torna essa atividade ainda mais desafiadora Al m disso o gerente pode precisar consultar outros departamentos da organiza o durante o planejamento e a execu o de um projeto de software Com base nessas premissas foi realizado um estudo para determinar o estado da arte sobre a reconfigura o din mica de projetos de software com nfase na integra o da ger ncia de projetos e os fluxos organizacionais a fim de identificar as principais lacunas e desafios de investiga o nesta rea Para alcan ar este objetivo foi adotada uma metodologia de revis o sistem tica No entanto conforme an lise dos resultados mesmo os trabalhos mais recentes n o apresentaram uma solu o que atenda todos os problemas da reconfigura o din mica ao mesmo tempo A fim de contribuir para a solu o das dificuldades verificadas esta tese apresenta um modelo computacional para a reconfigura o din mica de projetos de software em tempo de execu o com foco na integra o das atividades espec ficas dos projetos com as atividad
34. ERT GERT as redes de atividades e as abordagens de matriz de influ ncias tamb m n o s o capazes de incorporar esses fatores REDO1 As redes de Petri entretanto podem incorporar esses fatores e apresentar uma metodologia gr fica e anal tica poderosa na gest o de projetos A rede de Petri uma ferramenta de modelagem gr fica e matem tica que tem sido aplicada com sucesso nas reas de sistemas din micos a eventos discretos DEDS tais como na avalia o de desempenho protocolos de comunica oe modelos de decis o YUAO5 A principal diferen a entre as redes de Petri e as outras ferramentas de modelagem a presen a de fichas fokens que s o utilizadas para simular as atividades simult neas din micas e ass ncronas em um sistema O comportamento de um sistema pode ser representado em uma rede de Petri atrav s da cria o de equa es de estado state equations equa es alg bricas e outros modelos matem ticos A gest o de projetos desta forma considerada como uma rea potencial para o uso da modelagem com redes de Petri PE T81 KIM95 KUM98 Esta tese de doutorado parte de um projeto de pesquisa desenvolvido junto a um grupo de professores e alunos participantes do CePES da PUCRS Entre os projetos desenvolvidos neste centro Callegari CAL10 em sua tese de doutorado apresenta um modelo de refer ncia para tratar de eventos que podem alterar o planejamento de projetos de desenvolvimento de software e
35. International Conference on Enterprise Information Systems Spain 2008 8p CALLEGARI D Reconfigura o Din mica de Projetos de Software Um modelo para aloca o de recursos e programa o de atividades em ambientes multiprojetos com recursos compartilhados Tese de Doutorado PUC RS Porto Alegre 2010 CARDOSO J VALETTE R Redes de Petri Florian polis Ed UFSC 1997 CHATFIELD C JOHNSON T Microsoft Office Project 2010 Step by Step Redmond Microsoft Press 2010 CHEN Y FANG M Research on Resource Scheduling for Development Process of Complicated Product In Proceedings of the 9 International Conference on Computer Supported Cooperative Work Coventry University UK vol 1 2005 pp 229 233 CHURCH L K UZSOY R Analysis of periodic and eventdriven rescheduling policies in dynamic shops International Journal of Computer Integrated Manufacturing vol 5 3 1992 pp 153 163 COELHO C Um Modelo para Adapta o de Processos de Software Disserta o de Mestrado Universidade Federal de Pernambuco 2003 COWLING P I OUELHADJ D PETROVIC S Multi agent systems for dynamic scheduling In Proceedings of the nineteenth workshop of planning and scheduling of the UK UK 2000 pp 45 54 COWLING P I JOHANSSON M Using real time information for effective dynamic scheduling European Journal of Operational 193 194 DANQ5 DEBO7 D
36. Local PPGCC Programa de P s Gradua o em Ci ncia da Computa o FACIN PUCRS Data Maio de 2011 C Adequa o do roteiro do experimento com base na valida o de face e conte do Participante Maur cio Covolan Rosito Local PPGCC Programa de P s Gradua o em Ci ncia da Computa o FACIN PUCRS Data Maio de 20011 D Pr Teste Participantes Maur cio Covolan Rosito Msc Rog rio Tessari Local Instituto Federal do Rio Grande do Sul IFRS Data Junho de 2011 230 E Adequa o do roteiro de entrevista com base no pre teste Participante Maur cio Covolan Rosito Local PPGCC Data Junho de 2011 F Aplica o do Instrumento Tipo Experimento Entrevistador Maur cio Covolan Rosito Datas 04 11 2011 e 26 11 2011 Participantes 36 D 3 2 Outros Recursos Utilizados e Sistema Computacional e Estat stico o Statistical Package for Social Sciences SPSS e Recursos Materiais o Um audit rio da PUCRS para a palestra inicial sobre o SPIM o Um audit rio do IBGEN para a palestra inicial sobre o SPIM o Laboratorio com 30 m quinas instaladas com software SPIT na PUCRS o Laboratorio com 30 m quinas instaladas com software SPIT na IBGEN D 4 PLANEJAMENTO DO EXPERIMENTO D 4 1 Levantamento de Objetivos e Hip teses do Experimento Objetivo Global Comparar no Processo Unificado a precis o e o esfor o do modelo de planejamento integrado SPIM Software Planning Integrated Model em rela
37. O metamodelo SPEM 2 0 n o fornece conceitos para modelagem da execu o de processos de software De acordo com a especifica o desse metamodelo ele apenas define a habilidade para que implementadores escolham uma abordagem de modelagem de comportamento que melhor atendam suas necessidades Partindo do contexto que esse pacote n o detalhado no metamodelo SPEM 2 0 e que esta pesquisa n o considera aspectos de execu o de processos o pacote ProcessBehavior n o descrito neste trabalho em termos de suas classes e relacionamentos 211 A 5 PACOTE METHOD CONTENT O pacote MethodContent define os elementos que formam uma base de conte do para ser utilizada em qualquer processo de software Os principais elementos desse pacote s o Pap is Tarefas e Produtos de Trabalho AFigura 78 e a Figura 79exibem respectivamente a taxonomia dos elementos do pacote MethodContent e como as principais metaclasses desse pacote est o relacionadas b Es linkedRoleDefimtion optionality Qptionalitykind sonumera os i ParameterDirectionKind ide Core Figura 79 Metaclasses e associa es do pacote MethodContent Na Figura 78 observa se que todos os elementos definidos nesse pacote s o especializa es da metaclasse MethodContentElement que por sua vez especializa a metaclasse DescribableElement Os elementos introduzidos pelo mecanismo de merge neste pacote s o Step TaskDefinition RoleDefinition WorkProductDe
38. OMG12 e contribuem para o estudo apresentado em ROSO6 No RUP a classe Tool descreve as ferramentas que ajudam a produ o ou modifica o de um artefato O metamodelo OPEN tamb m cont m uma classe chamada Tool que uma subclasse da classe Producer e representa um software usado para 58 criar ou modificar as vers es de produtos de trabalho Neste caso observou se que a classe Tool no RUP equivalente classe Tool no OPEN Tabela 1 An lise Comparativa entre os principais conceitos do RUP e do OPEN RUP OPEN Tool Producer Tool Tool Mentor Work Unit Technique Artifact Work Product Activity Work Unit Task Role Producer Role Discipline Activity Lifecycle Stage Lifecycle Phase Stage Phase Workflow Detail Activity Signature Endeavor Language Existe uma similaridade de conceitos provenientes da classe ToolMentor no RUP e a classe Technique no OPEN A classe ToolMentor respons vel pela orienta o sobre como as atividades s o realizadas utilizando um instrumento particular A classe Technique uma subclasse da classe Work Unit respons vel por determinar como realizar uma ou mais atividades fluxos de trabalho e tarefas por um produtor classe Producer De acordo com o RUP a classe Artifact descreve os tipos de produtos de trabalho que s o produzidos e modificados durante o projeto A classe de Work Product do modelo OPEN representa tudo o que produzido utilizado modificado ou destru do
39. Principal tia Lugares lt Figura 50 Hierarquia em que foram estruturadas as tabelas 146 Esta estrutura mostra se apropriada uma vez que o simulador precisa obter todos OS arcos para uma determinada transi o e em seguida obter o peso de acordo com cada lugar de entrada ou de sa da As informa es das tabelas de entrada e sa da s o carregadas apenas no in cio do processo de simula o mas s o necess rias durante toda a simula o As informa es sobre marca o da rede e estado das transi es entretanto se modificam constantemente durante o processo de simula o Objetivando minimizar os recursos mantidos em mem ria consideram se apenas os lugares que possuem tokens para registrar o estado de marca o da rede Assim os lugares que n o possuem nenhum token podem ser eliminados da tabela de marca es No momento em que o simulador precisar consultar a marca o de um lugar se o lugar n o for encontrado na tabela de marca es ele deduz que o lugar procurado n o possui token Este mesmo crit rio utilizadona tabela de transi es habilitadas ou seja apenas as transi es que est o habilitadas s o mantidas na mem ria Al m de eliminar se da tabela de marca o os lugares que n o possuem tokens estes lugares s o tamb m ignorados no processo de avalia o das transi es que calcula se cada transi o est habilitada ou n o Quando o simulador procura por transi es a serem habilit
40. Reviews of Interventions Version 5 0 1 The Cochrane Collaboration 2008 HUMPHREY W S Managing the Software Process Addison Wesley 1989 HUMPHREY W S SNYDER T R AND WILLIS R R Software Process Improvement at Hughes Aircraft In Institute of Electrical and Electronic Engineers IEEE 1991 pp 11 23 IBM SPSS Statistical Analysis Capturado em http www 01 ibm com software analytics spss products statistics Julho 2011 JACOBSON Il BOOCH G RUMBAUGH J The Unified Software Development Process Upper Saddle River Addison Wesley 2001 JALOTE P PALIT A KURIEN P PEETHAMBER V T Ti pp 117 12 meboxing a process model for iterative software development Journal of Systems and Software vol 70 1 2 2004 JENSEN M T Improving robustness and flexibility of tardiness and total flow time job shops using robustness measures Applied Soft Computing vol 1 1 2001 pp 35 52 JIAMTHUBTHUGSIN W SUTIVONG D Resource Decisions in Software Development Using Risk Assessment Model In 39 Hawaii International Conference on Systems Sciences 2006 8p JOSLIN D POOLE W Agent Based Simulation For Software Project Planning In Proceedings of the 37 Conference on Winter Simulation Orlando Florida 2005 pp 1059 1066 JOZEFOWSKA J MIKA M ROYCKI R WALIGORA G WGLARZ J W Local search meta heuristics for discrete continuous scheduling problems
41. Sim Framework Workflow Sim N o N o Sim AYEO5 Sim N o N o N o Framework Workflow Sim Nao N o Sim DEL99 Sim Sim N o Sim Suporte Toolkit Sim Nao Sim Sim decis o DIWO8S Sim Nao Nao N o Framework Workflow Sim Nao N o N o GRUO4 Sim Sim N o N o Suporte Modelo Sim Nao N o N o decis o HESO9 Sim Nao N o Sim Suporte Algoritmo Sim Sim N o N o decis o HELO3 Sim N o N o Sim Suporte Workflow Sim Sim N o N o decis o Atrav s da an lise da Tabela 6 podem se obter algumas conclus es com base em uma r pida an lise quantitativa Primeiramente todos os trabalhos selecionados apresentam solu es para a programa o e agendamento de atividades do cronograma Quatro dos artigos analisados apresentam uma distin o entre as atividades t cnicas e gerenciais Apenas dois artigos apresentam solu es que propiciam a integra o das atividades do fluxo do projeto com os fluxos organizacionais da empresa Quatro pap is lidar com cen rios multiprojetos interessante notar que todos os resultados mostram solu es que envolvem algum tipo de solu o din mica Quatro estudos apresentaram solu es que envolvem algum tipo de t cnica de simula o Uma observa o importante que mais da metade dos artigos selecionados t m algum tipo de ferramenta ou prot tipo No entanto apenas um estudo inclui resultados de um estudo de caso ou experimento 92 O planejamento das atividades fortement
42. a empresa os sistemas de agendamento centralizado e hier rquico dependem fortemente de bases de dados centrais Sistemas de programa o centralizada e hier rquica apresentam uma s rie de inconvenientes PAR96 THA97 SHE99 BONOO BREO1 A principal desvantagem a exist ncia de um computador central que constitui um ponto de gargalo que pode limitar a capacidade da empresa e um nico ponto de falha Assim apesar do fato de que os sistemas centralizados e hier rquicos de programa o de atividades pode fornecer uma tima solu o para ambientes onde os dist rbios em tempo real s o raros cada vez mais eles tem se mostrado ineficientes em ambientes altamente din micos Portanto a programa o centralizada e hier rquica complexa dif cil de manter e reconfigurar inflex vel onerosa e lenta para satisfazer as necessidades dos ambientes empresariais atuais T Existem evid ncias substanciais de que a abordagem de sistemas multiagentes e uma das mais promissoras para a constru o de sistemas controle de cronograma devido a sua natureza aut noma distribu da e din mica e robustez contra falhas PAR96 PAROO SHEO1 BREO1 A principal motiva o na concep o destes sistemas descentralizar o controle do sistema agendamento reduzindo desse modo a complexidade e os custos aumentando a flexibilidade e aumentar a toler ncia a falhas Um sistema multiagente composto por uma rede de solucionadores de prob
43. a maioria dos projetos nas empresas de software realizada em ambiente multiprojetos Isso significa que os projetos n o est o isolados uns dos outros estes est o ligados atrav s de determinadas rela es tais como a competi o e partilha de recursos conflito de agendas conflito entre os agentes etc Devido a estas rela es m tuas especialmente o conflito de recursos em v rios projetos simult neos o gerenciamento de projetos torna se cada vez mais complexo Observa se desta forma aimport ncia daspesquisas relacionadas resolu odo problema da programa o de m ltiplos projetos com recursos limitados RCMPSP que definido como um problema de otimiza o combinat ria que lida com dois tipos de restri es de preced ncia de atividades e de recursos Do ponto de vista de complexidade este problema pertence a classe NP hard Em vista deste cenario uma serie de pesquisas sobre RCMPSP t m sido relatadas na literatura FRIOO Estes trabalhos t m lidado com diferentes variedades de situa es geralmente com base em projeto nico onde um ou ambos os tipos de restri es s o simplificados Fricke e Shenhar FRIOO consideraram que os fatores de sucesso mais importantespara os ambientesmultiprojetos diferem dos fatores de sucesso da gest o tradicional de um nico projeto e estes foram consistentes com outras pesquisas emergentes relacionadas ao ambiente de desenvolvimento de produtos Lova e Tormos LOVO1 analisaram
44. aqueles publicados nos idiomas ingl s e portugu s e Consideraram se somente as publica es realizadas os anos 2000 e 2011 e A string de pesquisa que foi utilizada na prepara o da revis o sistem tica pode acabar restringindo alguns artigos retornados pelos motores de busca de modo que se acaba assumindo o risco de deixar de fora alguns trabalhos relacionados 94 e Alguns crit rios de inclus o e exclus o de estudos foram adotados na sele o dos estudos Desta forma foram desconsiderados os estudos o Que n o estavam no formato de artigo completo full paper o Cujo conte do n o estava relacionado a rea de reconfigura o de projetos o Trabalhos que citem import ncia da reconfigura o de projetos mas que n o possuam nenhum tipo de solu o para isto e Tamb m foram removidos estudos do tipo roadmaps trabalhos que indicam os desafios e as dire es a serem tomadas em uma rea de pesquisa 4 4 Considera es Finaisdo Cap tulo Este Cap tulo apresentou uma introdu o rea de estudo e tamb m trouxe algumas defini es assumidas no contexto desta pesquisa Em seguida foram apresentados os principais conceitos sobre a reconfigura o din mica no contexto de projetos de software Neste Cap tulo tamb m foram apresentados v rios m todos de programa o din mica incluindo heuristicas meta heuristicas sistemas baseados em conhecimento l gica fuzzy redes neurais redes de Petri e os sistem
45. atividades dos projetos de software e os fluxos organizacionais tais como aquisi o de hardware contrata o de novas pessoas configura o do ambiente de trabalho Cabe lembrar que os outros departamentos da organiza o s o respons veis por atualizar os prazos destes fluxos organizacionais por exemplo o departamento de recursos humanos respons vel pela gest o das atividades do fluxo organizacional contrata o de pessoas Assim um dos objetivos do SPIM auxiliar o gestor na antecipa o das necessidades que surgem de diferentes fontes da organiza o atrav s do envio de alertas que permite o replanejamento das atividades afetadas por esta rela o de depend ncia Para fins de ilustra o a Figura 58 apresenta o fluxo organizacional contrata o de pessoas Cabe relembrar que as atividades dos fluxos organizacionais s o denominadas nesta pesquisa como atividades gerenciais de apoio Neste fluxo organizacional a atividade de identificar as habilidades necess rias representada no lugar F1 a atividade divulgar ofertas de vagas representado pelo lugar F2 a atividade analisar candidatos representado pelo lugar F3 a atividade contatarcandidatos selecionados representado pelo lugar F5 a atividade avisar sindicato representado pelo lugar F4 a atividade selecionar candidato representado pelo lugar F6 e a atividade avisar gestor representado
46. b sicos para a defini o de processos de desenvolvimento de software Os processos de desenvolvimento de software definem como os projetos de software devem ser executados Uma das caracter sticas mais comuns encontradas dentro das diferentes defini es de processo na literatura o sequenciamento de fases e marcos expressando um ciclo de vida de um produto em desenvolvimento Processos tamb m definem como ir de um marco para o pr ximo atrav s da defini o de sequ ncias de trabalho opera es ou eventos que normalmente ocupam o tempo per cia ou outro recurso e que produzem algum resultado O comportamento dos processos pode ser modelado atrav s da fus o merge do pacote Process Structure com o pacote Behavior As descri es textuais para os elementos dos pacote ProcessStructure e Behavior podem ser adicionados pelo m todo de merge destes pacotes com o pacote ManagedContent Conforme este metamodelo vide Figura 13 a classe Activity pertence uma subclasse de WorkBreakdownElement e WorkDefinition do pacote Core Uma atividade define as unidades b sicas de trabalho dentro de um processo Esta classe se relaciona com a classe WorkProductUse atrav s da classe ProcessParameter Alem disso a classe Activity se relaciona com a classe ProductiveRole originalmente chamada de RoleUse pelo SPEM atrav s da classe ProcessPerformer Uma 64 atividade suporta o aninhamento e agrupamento l gico dos elementos contidos na estrut
47. conhecimento relacionado Ger ncia de Projetos _ Nenhum _ Pouco Moderado JAvan ado 10 Como voc qualificaria seu conhecimento relacionado processos de desenvolvimento de software _ Nenhum Pouco Moderado JAvan ado E 2 CEN RIO 1 Veja abaixo a descri o das atividades propostas para o cen rio 1 Cen rio 1 Participante Teste Usu rio Download Clique aqui para fazer download do cen rio 1 Descri o do Cen rio 1 239 O papel do stakeholder envolvido deve ser compativel com o tipo de atividade gerencial ou produtivo Recursos envolvidos neste projeto Carlos Viana Gerente de Sistemas Mario Silva Gerente de Projetos Ana Valente Projetista de Sistemas Joao Souza Analista de Sistema Macio Oliveira Desenvolvedor Senior Daniel Carvalho Desenvolvedor Junior Diego Moraes DBA Senior Samanta Pinheiro Analista de Testes Joana Santos Testadora Sala de Reuni o 1 Sala de Reuni o 2 Orienta es 1 Abra o arquivo Cen rio1 2 Caso voc esteja usando o modelo SPIM associe cada recurso a um papel de acordo com a listagem acima Para realizar este opera o clique no menu Exibir do MS Project e selecione a op o Planilha de Recursos Ao finalizar clique no menu Exibir do MS Project e selecione a op o Gantt de Controle para exibir as atividades do projeto 3 Sem alterar as datas e dados de preced ncia entre as atividades e de a
48. das neste estudo o tempo para planejar as atividades do projeto utilizando o modelo SPIM semelhante ao do modelo tradicional A id ia por tr s do modelo SPIM vem da necessidade de reduzir a complexidade em visualizar as interdepend ncias de ambos os fluxos de trabalho organizacionais e do fluxo de atividades de um projeto individual A maior parte do esfor o em usar o modelo SPIM est relacionada com o preenchimento das informa es extras propostas por este modelo No entanto os resultados da vari vel esfor o n o se tornou favor vel para o m todo tradicional Outra funcionalidade desenvolvida para o prot tipo SPIT a gera o de uma rede de Petri a partir da WBS do projeto pelo m dulo Compiler Rede de Petri uma ferramenta para descrever e estudar sistemas de processamento de informa es que caracterizada como sendo concorrente assincrona distribu da paralela n o determin stica e ou estocastica MUR89 Atrav s do mapeamento do diagrama de rede que representa a WBS para o a rede de Petri foi poss vel simular tr s cen rios de reconfigura o de projetos em resposta a eventos externos O modelo de simula o dos projetos de software desenvolvido nesta pesquisa utilizou como refer ncia o modelo de programa o preditiva reativa Este um processo de programa o e reprograma o do projeto onde as atividades s o revistas em resposta a eventos ocorridos em tempo real Assim considerando as diferentes est
49. de uma atividade pr tica experimento acad mico onde os participantes ter o a oportunidade de realizar um exerc cio baseado em uma situa o t pica para o problema de gest o de projetos envolvendo os fluxos organizacionais unindo teoria e pr tica Tal exerc cio se caracteriza como um estudo experimental cujos resultados permitir o aos pesquisadores a realiza o de uma an lise sobre as dificuldades impostas aos gerentes de projetos na resolu o do problema com e sem o uso do modelo SPIM Os resultados ser o encaminhados aos participantes do evento permitindo lhes uma 224 avalia o sobre os resultados do experimento a partir da experi ncia realizada pelo grupo O evento gratuito e as vagas s o limitadas Est o convidados alunos e professores de gradua o e p s gradua o que tenham interesse na rea de gerenciamento de projetos As informa es fornecidas ser o tratadas de forma absolutamente confidencial Ao participar al m dos resultados do experimento voc ter acesso aos materiais publicados por este grupo de pesquisadores Os resultados devem ser disponibilizados a partir de novembro de 2011 sendo que estaremos lhe enviando uma comunica o por e mail Para participar basta clicar aquie criar uma conta de acesso A data limite para a cadastro e participa o 26 de outubro de 2011 Lembramos que as vagas s o limitadas Cadastre se j Colabore com o desenvolvimento das pesquisas na rea de gere
50. de uma transi o habilitada no qual o lugar p um local de entrada ou de sa da 5 3 Mecanismo de Mapeamento entre o Diagrama de Rede e a Rede de Petri Kim et al KIM95 estudaram uma esp cie de mecanismo de mapeamento entre om todo do caminho cr tico CPM e as redes de Petri com base em redes b sicas de Petri no ambiente de um nico projeto Reddy et al RED01 propuseram outro mecanismo de mapeamento entre PERT e redes b sicas de Petri em situa o de um nico projeto O pontoem comum destas duas pesquisas que as atividades do diagrama de rede foram mapeadas em transi es temporizadas e eles discutiram o mecanismo de mapeamento somente em ambientes de um nico projeto No entanto existe uma lacuna cr tica nestes dois mecanismos Ap s o disparo de umatransi o as fichas s o removidasimediatamente a partir do local de entrada desta transi o Entretanto as fichas n o podem ser depositadas no local de sa dacorrespondente porque estas devem se manter indispon veis at que o intervalo de 104 tempo associado com a transi o encerre Portanto neste intervalo de tempo o estado do sistema de marca es desconhecido e um mecanismo de rastreio adicional deve ser estabelecido para controlar o movimento das marca es o que o torna dif cil de analisar o comportamento din mico do sistema Ainda h necessidade de criar um lugar fict cio de destino para a ltima transi o temporizada que representa o tempo de
51. destes projetos com os fluxos organizacionais das empresas B 1 1 Qualidade e Amplitude da Quest o Esta se o objetiva descrever a sintaxe da quest o de pesquisa atrav s dos itens problema e quest o e a sua sem ntica atrav s dos itens interven o controle efeito medi o dos resultados popula o aplica o e projeto experimental Problema Durante o planejamento e execu o de projetos de software o gerente de projetos pode necessitar interagir com outros departamentos da organiza o a fim de obter informa es relevantes para o projeto Neste instante h uma dissocia o entre o fluxo de atividades de um projeto de software e os demais fluxos de atividades de suporte ao projeto da organiza o Consequentemente observa se a necessidade de identificar os requisitos para uma solu o de reconfigura o din mica de projetos de software que envolva multiplos projetos simult neos e a integra o com os demais fluxos organizacionais considerando o sequenciamento e a rela o de depend ncia entre as atividades pertencentes a estes dois tipos de fluxos de trabalho Quest o de Pesquisa Quais abordagens existentes na literatura permitem a reconfigura o din mica das redes de planejamento de projetos de software que envolva m ltiplos projetos simult neos e a integra o com os demais fluxos organizacionais Tabela 21 Palavras chaves e sin nimos Palavras Chaves Tradu o em portugu s
52. do projeto Alem dos conceitos e objetivos acima importante tamb m que os processos de desenvolvimento de software sejam padronizados de forma a garantir uma maior qualidade dos produtos de software MACOO 2 2 Processo Padr o de Desenvolvimento de Software Um processo padr o de desenvolvimento de software pode ser definido com sendo O processo que deve servir como refer ncia para guiar a execu o de todos os projetos de desenvolvimento dentro de uma organiza o Segundo Ginsberg e Quinn GIN95 o processo padr o o meio pelo qual a organiza o expressa os requisitos que todos os processos de desenvolvimento de software dos projetos devem atender Conforme Humphrey HUM89 apud COE03 e Xu e Runeson XU05 as vantagens da implanta o de um processo padr o de desenvolvimento de software s o as seguintes e Redu o dos problemas relacionados a treinamento revis es e suporte de ferramentas e Experi ncias adquiridas em cada projeto podem ser incorporadas ao processo padr o contribuindo para sua melhoria e Maior facilidade em medi es de processo e qualidade e Maior facilidade de comunica o entre os membros da equipe e Melhor adequa o de novos membros na equipe de projeto e Melhor desempenho previsibilidade e confiabilidade dos processos de trabalho Atualmente devido a import ncia da utiliza o de um processo padr o um esfor o consider vel tem sido devotado para sua elabora o e com
53. dulo Compiler uma ferramenta para modelagem compila o gera o e verifica o de redes de Petri O m dulo Compiler pode fazer a tradu o em ambos os sentidos entre as informa es contidas na estrutura de trabalho do projeto WBS e nas redes de Petri Ele usa a linguagemPetri Net Markup Language PNML JUNOO como um formato de interc mbio baseado em XML para redes de Petri A PNML foi proposta para definir as caracter sticas t picas de todas as redes de Petri Segundo Murata MU89 a maioria dos grupos de pesquisa sobre redes de Petri t m as suas pr prias ferramentas para auxiliar de desenho an lise e ou simula o de v rias aplica es Cada um deles t m suas caracter sticas e pontos fortes espec ficos Mas esta variedade de ferramentas implica a persist ncia de v rios formatos de arquivo Cada ferramenta tem o seu pr prio formato de arquivo de modo que o usu rio que 133 pretende combinar diferentes ferramentas de redes de Petri n o pode usar o mesmo arquivo para analisar simular ou verificar a mesma rede em ferramentas diferentes De acordo com Jungel et al JUNOO a melhor maneira de resolver este problema utilizar um formato de interc mbio que pode ser lido por cada uma das ferramentas utilizadas Estas ferramentas no entanto precisam representar as suas caracter sticas espec ficas neste formato de interc mbio O formato de interc mbio permite a intera o de redes de tipos diferentes mas c
54. durante a realiza o de uma ou mais unidades de trabalho por um ou mais produtores Neste caso existe uma pequena diferen a entre o RUP e o OPEN sobre a rela o destas duas classes com um papel classe Role No RUP um artefato deve ser de responsabilidade de apenas um papel e pode ser modificado por qualquer um ou v rios pap is No OPEN um produto de trabalho deve estar relacionado com um ou mais produtores Assim a classe Artifact do RUP equivalente classe de Work Product do OPEN A defini o da classe Activity no RUP satisfaz a defini o da classe Task no OPEN A classe Activity representa uma unidade de trabalho que produz um resultado significativo para o projeto enquanto a classe Task representa um trabalho espec fico que produz ou modifica um ou mais produtos de trabalho Ambos os modelos RUP e 59 OPEN usam o termo Role para definir quem respons vel pela execu o das atividades e por produzir ou modificar produtos de trabalho No OPEN a classe Role uma subclasse de Producer No RUP a classe Discipline respons vel pela divis o dos elementos do processo em reas de interesse Cada disciplina composta de um ou mais fluxos de trabalho A classe workflow Detail agrupa atividades relacionadas e define como os pap is devem trabalhar em conjunto para alcan ar objetivos espec ficos do processo Esta classe determina a sequ ncia e interdepend ncia entre as atividades pertencentes a uma disciplina No OP
55. entre o gerente de projeto com outros departamentos dentro da organiza o A desconsidera o das depend ncias entre as atividades de diferentes fluxos de trabalho pode resultar em distor es no planejamento de projetos de software Muitas vezes O gerente de projeto somente sente a necessidade de solicitar as informa es de outros departamentos da empresa ao executar uma determinada atividade do projeto que depende destas informa es externas ao projeto por exemplo aquisi o de equipamentos ou a contrata o de um novo desenvolvedor Consequentemente existe a necessidade de uma solu o que permita antecipar as necessidades resultantes destas reas de apoio da empresa durante o planeamento de projetos de software Esta solu o deve considerar a complexidade de identificar a interdepend ncia entre as atividades dos fluxos de trabalho da organiza o e o fluxo de trabalho dos projetos No entanto nenhum dos trabalhos retornados nesta revis o sistem tica fornece algum mecanismo computacional para resolver todos esses problemas relatados nesta pesquisa 4 3 3 Limita es da Revis o Sistem tica Conforme observado no Ap ndice B a execu o desta revis o sistem tica apresentou as seguintes restri es e Consideraram se somente os artigos retornados pelos motores de busca selecionados ou seja IEEE Xplorer digital library ACM digital library Springer Link and Science Direct e Os artigos analisados ficaram restritos
56. humanas Em um Flowchart workflow as diversas atividades que fazem parte de um processo s o agrupadas dentro de uma atividade do tipo Flowchart Nesta tese desenvolveram se fluxos de trabalho deste tipo Flowchart Start Ga GetData Mi TryUpdateDatabase False Decision L CompleteProcessing Figura 40 Exemplo de Flowchart workflow As intera es entre as atividades que comp em um workflow envolver o em grande parte dos casos o fluxo de informa es de um ponto a outro do processo em quest o Assim procurando oferecer suporte ao interc mbio de dados entre as partes que constituem um workflow a tecnologia Workflow Foundation disponibiliza recursos como vari veis argumentos e express es utilizando para isto dos mesmos conceitos presentes numa linguagem de programa o convencional MYE07 Devido a natureza distribu da de um processo de neg cio que considera informa es provenientes de v rios departamentos em uma organiza o um fluxo de trabalho pode ser implementado como sendo uma aplica o distribu da Para suportar esta funcionalidade o uso de servi os web web services foi escolhido como a plataforma para acessar aplica es distribu das de workflow Web services foram 132 projetados para abstrair como os aplicativos se comunicam uns com os outros Estes servi os permitem a separa o da l gica de neg cio com o c digo do aplicativo cliente Ent o utiliza se web services para exp
57. iniciar outra 5 Uma atividade n o pode ter ela mesma como predecessora ou antecessora 6 O fluxo de atividades n o pode resultar em um ciclo por exemplo a atividade A pr requisito para a atividade B e a atividade B pr requisito para a atividade A T Uma mesma atividade n o pode criar modificar ou consultar um mesmo artefato Para realizar tais opera es devem ser criadas atividades distintas 8 Uma atividade gerencial deve ter pelo menos um papel gerencial como um de seus pap is 9 Uma atividade produtiva deve ter pelo menos um papel produtivo como um de seus pap is 10 O stakeholder respons vel por uma atividade gerencial deve possuir um papel 128 gerencial 11 O stakeholder respons vel por uma atividade produtiva deve possuir um papel produtivo 12 Cada atividade do projeto deve ser de responsabilidade de apenas um indiv duo mesmo que muitas pessoas venham a trabalhar naquela atividade 13 Uma atividade gerencial n o pode produzir ou modificar um produto de trabalho produtivo somente um produto de trabalho gerencial Por m esta atividade pode consultar um produto de trabalho produtivo 14 Uma atividade produtiva n o pode produzir ou modificar um produto de trabalho gerencial somente um produto de trabalho produtivo Por m esta atividade pode consultar um produto de trabalho gerencial 15 Para cada associa o entre um papel e uma atividade representado pela classe ActivityStakeholderWork deve haver
58. lewalOflnterast lavalOfinfiuence ActivityPhysicalResourceVork wor kia firma rar a reeporsible 1 0 4 E Deliverable ManagerialRele a a m fT TIREI Te Project ceaberacirs Activity ActivityDetallDapendancy ActivityStakeholderWork scopettalemant indirect osts type workload name fs responsible Purpose assignment objectives lt abstract gt Guidance mare lt abstract abslract gt gt AchvityOetal Role AMBSiInd x int rane fdirectoost double s Gescnpion delirttion String i USacinaby ecabeira ies lt lt enumeration gt mbaseine boolean Li WorkProduet ActivityUseKind Baselinebete Date lt lt abstract gt useking ActivtyUsekind RETIRA WorkProduciType nao int i description eatensian gt int percentage name cal Contribution int Extarna lacalReplapement imt is ustDelierable starteto Date finishDate duration d i namie Siring description Sting SPEM ement WorkBreakdownElement BreskdownElemant dRotalee isRepeatable boolean E E E hat WOceuren es boas E 1 isOmgoing boolean des a Pia e f l Opera E isEventDrivan boolean p a ProductiveRtola 1 ias 1 finkedRolallse drecion ParameterDirectonkind parametar Typa 1 WorkProductUse k 1 ProcessResponsability4ssignment 1 of finkedVorkProductlise e
59. lt merge gt gt ProcessWithMethods lt lt merge gt gt Ps U5 MethodContent lt lt merge gt gt ae eemerges gt ProcessBehavior lt lt merge gt gt lt lt merge gt gt gt ProcessStructure ManagedContent lt emerge gt gt a eemerge gt gt Core Figura 8 Camadas de metamodelagem propostas pela OMG 2 5 Consideracoes Finaisdo Capitulo Este Cap tulo apresentou os conceitos referentes gest o de projetos e aos processos de software objetivando demonstrar a import ncia de seu uso para as organiza es de Tl Inicialmente foi apresentado o ciclo de vida b sico para um processo de software e posteriormente descritos os principais aspectos relacionados gest o de projetos Em seguida foram apresentados os metamodelos estudados nesta pesquisa a saber PMBOK SPEM RUP e OPEN O pr ximo Cap tulo apresenta os modelos de refer ncia que foram usados como base para a elabora o do modelo de reconfigura o proposto nesta tese Os modelos de refer ncia foram comparados e combinados em um modelo integrado chamado SPIM 44 3 INTEGRA O DOS PROJETOS DE SOFTWARE COM OS FLUXOS ORGANIZACIONAIS 3 1 Fluxos Organizacionais Defini o e Conceitos Relacionados Projetos de software s o muito din micos e demandam recorrentes ajustes dos seus planos de projeto Esses ajustes podem ser vistos como reconfigura es no cronograma das tarefas na atribui o de recursos e
60. o o que permite o c lculo da normalidade e homocedasticidade necess rios para definir o tipo de teste das hip teses param trico ou n o param trico Uma distribui o normal uma distribui o sim trica geralmente representada graficamente por uma curva em forma de sino que atinge o pico em torno do seu centro Homocedasticidade refere se suposi o de que a vari vel dependente exibe quantidades semelhantes de vari ncia em toda a gama de valores para uma vari vel independente Inicialmente foi realizada a verifica o de cada hip tese nula A hip tese nula Ho est relacionada com a aleatoriedade dos resultados observados isto se isso for verdade estatisticamente os resultados do experimento evidenciam para serem ocasionais nenhuma conclus o pode ser feita A hip tese alternativa H1 aquela que val ser aceita se a hip tese nula for rejeitada No entanto deve se notar que o nivel de signific ncia do teste foi fixado em 5 Logo o menor n vel de signific ncia que pode rejeitar a hip tese nula p value ou a de 0 05 As an lises apresentadas neste experimento foram realizadas com o software Statistical Package for Social Sciences SPSS IBM11 7 1 2 1 Primeira Hip tese Esfor o Atrav s de uma an lise inicial da distribui o pode se avaliar o comportamento das amostras Inicialmente o conjunto de dados foi analisado para ver se alguma informa o observa o estava demasiadamente longe d
61. permitam prosseguir a execu o do projeto Entretanto esta proposta espec fica n o aborda profundamente problemas relacionados ao sequenciamento das atividades de um projeto de software o prot tipo desenvolvido considera um cronograma fixo ou seja n o h modifica o na ordem de sequ ncia das atividades Ainda considerando este modelo de reconfigura o din mica de projetos Schlosser SCH10 prop s um solver baseado em sistemas multiagentes SMA Esta ltima pesquisa apresenta uma arquitetura baseada em sistemas multiagentes onde os agentes componentes da solu o utilizam o protocolo de rede de contratos SMI80 para coordenar o processo de gera o de propostas Durante a execu o dos projetos o gerente pode ter que interagir com outros departamentos da organiza o a fim de obter informa es relevantes para o projeto tal como contatar o departamento de recursos humanos sobre a necessidade de contratar mais profissionais para o projeto Desta forma pode se observar que existe uma distin o entre as atividades espec ficas em um projeto e as atividades que fazem parte do fluxo comum de trabalho da organiza o aqui chamado de fluxo organizacional Sendo assim o gerente de projetos deve lidar com essa dissocia o entre o fluxo de atividades de um projeto de software e os fluxos organizacionais este ultimo procura oferecer algum tipo de suporte para o projeto de software Ambos os tipos de fluxos de trabalho s
62. personalizados MYEO7 Desta forma o Windows Workflow Foundation uma estrutura extens vel para o desenvolvimento de solu es de fluxo de trabalho na plataforma Windows As solu es baseadas no WWF s o constru das com componentes interconectados que t m o suporte do c digo do Microsoft NET e s o executados em um aplicativo host Ainda o WWF fornece um mecanismo de workflow uma API gerenciada pelo NET Framework servi os de tempo de execu o e um designer e depurador visual integrado ao Microsoft Visual Studio 2012 MYE07 Basicamente workflows criados atrav s deste framework podem ser classificados em dois tipos e Sequential workflow o fluxo de execu o das atividades ocorre passo a passo sendo poss vel ainda o uso de desvios condicionais dentro da l gica que se est elaborando Seu uso recomendado na modelagem de processos mais simplificados e sem interven o humana sendo equivalentes a rotinas escritas de maneira procedural dentro de uma linguagem de programa o 131 e Flowchart workflow permite a modelagem de um processo num padrao grafico similar a um diagrama de atividades UML vide Figura 40 Sao uteis na representa o de processos com uma estrutura sequencial mas que tamb m contam com loops que desviam o fluxo de execu o para estados anteriores Diferentemente de um Sequential workflow este tipo de workflow recomend vel na modelagem de processos que tamb m contem com intera es
63. podem ser vistos como reconfigura es no cronograma de tarefas na atribui o de recursos e de outros elementos do projeto Ainda durante o planejamento e execu o de um projeto de software deve se considerar a integra o das atividades espec ficas dos projetos com as atividades que fazem parte de um fluxo de atividades comum organiza o Neste sentido est sendo proposto um modelo computacional para o suporte a reconfigura o din mica de projetos de software em ambientes multi projetos considerando o planejamento e o replanejamento de suas atividades e com nfase LIMPAR LOGIN na integra o da ger ncia de projetos com os fluxos organizacionais das empresas Para avalia o do modelo e materializa o da proposta foi desenvolvido um prot tipo de uma ferramenta de software Inscri o Fa a sua inscri o aqui Avenida Ipiranga 6681 Pr dio 32 Sala 110 Bairro Partenon Porto Alegre RS CEP 90619 900 Figura 51 Site sobre o experimento do modelo SPIM 7 1 1 4 An lise do Experimento Esta subse o descreve como os dados coletados do experimento foram examinados a fim de auxiliar nas conclus es desta pesquisa Existem diferentes t cnicas de an lise dependendo das caracter sticas dos dados recolhidos e sobre o 159 designaplicado Os metodos de analise podem ser divididos em dois blocos principais m todos param tricos e n o parametricos Testes param tricos requerem uma suposi o param
64. posteriormente executar a integra o entre eles deve se represent los sob estruturas compat veis Dessa forma foi utilizado o metamodelo previamente desenvolvido em CALO7 que utiliza a nota o da linguagem UML para representar seus elementos Como podemos observar na Figura 2 este modelo foi desenvolvido observando OS principais conceitos contidos no PMBOK tais como programa projeto recursos atividades pap is produtos e classes associadas importante salientar que este modelo foi desenvolvido com uma vis o para atender as necessidades exclusivas dos projetos de desenvolvimento de software O PMBOK agrupa conhecimentos relacionados a comprovadas e amplamente aplicadas pr ticas tradicionais de gest o de projetos Um dos principais conceitos de gest o de projetos que as partes interessadas classe stakeholders que correspondem a todos os indiv duos e organiza es que t m qualquer tipo de rela o com um projeto SCHO2 As partes interessadas participam das atividades classe Activity e tarefas classe Task que s o classificadas em um n mero de reas de conhecimento classe KnowledgeArea e que podem ter o apoio de ferramentas classe Tool e t cnicas classe Technique Atividades consomem e produzem produtos de trabalho classe Deliverable utilizando os recursos apropriados Al m disso a classe 34 DeliverableTypedefine o tipo de produto de trabalho tais como um contrato uma proposta comer
65. que acompanhou grande parte dos passos deste trabalho e demonstrou ser um bom conselheiro com suas quest es desafiadoras e provocativas que engrandeceram esta tese Ao Programa de P s Gradua o em Ci ncia da Computa o da PUCRS por proporcionar excelentes disciplinas que contribu ram para minha forma o e servir de refer ncia para meus ideais acad micos A Coordena o de Ensino do Instituto Federal de Educa o Ci ncia e Tecnologia do Rio Grande do Sul por viabilizar minha participa o no doutorado Aos amigos que n o vou enumerar por serem muitos mas que sem eles eu n o teria tido a alegria de concluir esta etapa de minha vida acad mica Ao meu irm o Fernando Covolan Rosito pelo incentivo e apoio no meu trabalho mostrando que a dist ncia f sica nao nos afastou como familia Um agradecimento especial aos meus pais M rio Antonello Rosito e Laura Maria Covolan Rosito por terem entendido a import ncia deste doutoramentoe pelos valores ticos e morais que herdei Um agradecimento mais que especial a minha esposa G ssica Popow Rosito pelas demonstra es de amor e carinho que recebi por ter compartilhado todos os momentos e compreendido as dificuldades do caminho percorrido e ter me proporcionado nossa maior felicidade o nosso querido filho Enzo Popow Rosito A todos voc s dirijo o meu sincero muito obrigado RECONFIGURA O DIN MICA DE PROJETOS DE SOFTWARE UM MODELO PARA INTEGRAR A GER NCIA DE PROJETOS
66. que esta proposta espec fica n o aborda profundamente os problemas relacionados ao sequenciamento das atividades de um projeto de software Finalmente observa se que o modelo original n o considera a simula o de cen rios com o aux lio de um mecanismo de simula o tal como as redes de Petri 119 6 2 Modelo Proposto As empresas de software geralmente fazem uso dos conhecimentos relacionados a gest o de projeto para a constru o de suas solu es objetivando respeitar os crit rios de qualidade acordados e as limita es de tempo escopo e de recursos O gerente geralmente cria um plano de projeto para especificar e limitar o escopo do projeto descrevendo a estrutura anal tica do projeto WBS e o cronograma do projeto Para criar o cronograma do projeto o gerente come a pelo conjunto de tarefas da WBS PREO9 Ent o ele especifica todas as informa es relacionadas ao projeto tais como as tarefas individuais a sequ ncia em que as tarefas precisam ser realizadas quantas tarefas podem ser executadas em paralelo e os recursos para executar essas tarefas Durante o ciclo de vida de um projeto dados atualizados como o tempo ou os recursos que foram gastos para executar uma tarefa espec fica s o coletados e registrados pelo gerente do projeto No entanto o gerente pode n o ter todas as informa es relevantes na sua frente for ando o a interagir com outros departamentos na organiza o como o departamento de r
67. revisar somente parte do cronograma originalmente criado para responder s mudan as no ambiente de produ o sem realizar o reescalonamento a partir do zero Abumaizar e Svestka ABU97 afirmaram que na pr tica o reescalonamento tem sido feito por meio do reparo da programa o enquanto que a reprograma o completa tem sido usada tamb m mas de forma limitada Sabuncuoglu e Bayiz SA00 demonstraram a efic cia potencial da repara o da programa o em termos de estabilidade em compara o com o reescalonamento completo Outro problema de import ncia pr tica em projetos a decis o de reprogramar a partir do zero reescalonamento completo ou a partir da repara o da programa o e qual a estrat gia de reparo da programa o deve se escolher para reagir aos eventos em tempo real Para lidar com esse problema foram utilizadas medidas de simula o e robustez para avaliar o desempenho das estrat gias de reescalonamento e selecionar a melhor estrat gia Wu et al WUS91 WUS93 Daniels e Kouvelis DAN95 Abumaizar e Svestka ABU97 e Jensen JENO1 utilizaram medidas robustez efici ncia e estabilidade para decidir sobre a melhor estrat gia de reescalonamento aplicar Cowling e Johansson COWO02 e Ouelhadj et al OQUEOS3 utilizaram medidas de utilidade e estabilidade para avaliar o desempenho de v rios reparos cronograma e estrat gias de reescalonamento completas e selecionar a melhor estrat gia de reprograma o
68. revistas em resposta a eventos ocorridos em tempo real O modelo de programa o preditiva reativa foi adotado nesta tese para o desenvolvimento da solu o para a reconfigura o din mica de projetos de software A maioria das estrat gias de programa o preditiva reativa s o baseadas em ajustes simples na programa o que consideram apenas a efici ncia do projeto A nova programa o pode divergir significativamente da programa o original o que pode afetar seriamente outras atividades que foram planejadas baseadas no cronograma original e consequentemente pode levar a fraco desempenho da programa o Consequentemente desej vel gerar programa es preditiva reativa robustas A programa o preditiva reativa robusta se concentra na constru o cronogramas 71 preditivos reativos para minimizar os efeitos de poss veis perturba es sobre o desempenho da programa o realizada WUS91 WUS93 LEO94 Uma solu o t pica para gerar uma programa o robusta reprogramar as atividades considerando simultaneamente a efici ncia do projeto e o desvio da programa o original estabilidade A estabilidade mede o desvio da previs o original da programa o das atividades causado pela revis o do cronograma para quantificar a inconveni ncia de se fazer altera es na programa o inicial WUS91 WUS93 COW02 LEUO5 Wu et al WUS91 WUS93 definiu uma medida de robustez baseada em um conjunto de crit rios r
69. suporte automatizado para os processos de software o que considerado de alta import ncia devido a quantidade e complexidade de informa es envolvidas em um processo de software Existem diversos metamodelos de processo tais como Software amp Systems Process Engineering Meta Model Specification SPEM 1 1 OMG02 OPEN Process Framework OPF FIRO2 entre outros Atualmente o metamodelo refer ncia para a defini o de processos de software o SPEM 2 0 que foi publicado pela Object Management Group OMG em 2007 OMG12 Segundo a especifica o do SPEM 2 0 a meta em definir um metamodelo de refer ncia viabilizar a cria o de grande variedade de processos de software para diferentes culturas que utilizam diferentes n veis de formalismo e modelos de ciclo de vida Nas se es seguintes s o apresentados os modelos utilizados como refer ncia nesta pesquisa 2 4 1 Project Management Body of Knowledge PMBOK 2 4 1 1 Defini o e Aspectos Relacionados Reconhecido internacionalmente pelo seu esfor o em definir normas e dar suporte aos profissionais de ger ncia de projetos o Project Management Institute PMI PMI08 publicou um guia geral de ger ncia de projetos o PMBOK Guide O Project Management Body of Knowledge re ne as melhores pr ticas aplic veis maioria dos projetos e sobre as quais h um amplo consenso sobre o seu valor e utilidade De acordo com o Project Management Institute PMIOS o principal obje
70. transition gt transition id t3 gt lt name gt lt text gt t3 lt text gt lt name gt lt graphics gt lt position x 350 y 200 gt lt dimension x 30 y 30 gt lt qraphics gt Figura 48 Trecho do codigo PNML onde est o descritos as transi es da RdP Conforme observado na Figura 49 os arcos descritos no c digo PNML nas etiquetas lt arc gt e lt arc gt s o utilizados para obter a ordem de preced ncia entre as atividades Assim atrav s da descri o dos arcos poss vel identificaas atividades dependentes e as atividades precedentes do projeto As atividades precedentes s o localizadas nos arcos que representam a liga o dos lugares s transi es identificados no c digo PNML pelo trecho source r tulo do lugar etarget r tulo da transicdo As atividades dependentes s o localizadas nos arcos que realizam a liga o das transi es aos lugares identificados no trecho de c digo PNML source r tulo da transi o e target r tulo do lugar 142 are 1d al source pl target t1 gt graphics gt lt arc gt lt arc 1d a2 source tl target p2 gt graphics gt lt arc gt lt arc id a3 source t1 target p3 gt lt graphics gt lt farc gt Figura 49 Trecho do c digo PNML onde est o descritos os arcos da RdP Analisando identificando e processando esses componentes podem se gerar os elementos da WBS para este projeto de sof
71. trica tal como a normalidade e testes n o param tricos s o frequentemente utilizados no lugar dos seus hom logos parametricos quando certas suposi es sobre a popula o subjacente n o s o atendidas A escolha de cada t cnica de an lise a ser aplicada sobre o experimento depende do tipo de escala da vari vel de resposta Assim quando a vari vel de resposta nominal ou ordinal os m todos que devem ser utilizados durante a an lise correspondem aos do grupo dos n o param tricos e quando a vari vel de resposta medida em uma escala de intervalo ou raz o m todos param tricos e n o param tricos devem ser aplicados No entanto os testes param tricos s o estatisticamente mais poderosos do que os m todos n o param tricos MIL94 Assim os testes param tricos devem ser aplicados idealmente para analisar os dados coletados a partir dos experimentos Por m se estes testes parametricos nao s o conclusivos ent o a an lise vai ter que recorrer aplica o de testes n o param tricos embora sejam menos poderosos estatisticamente Considerando estes dois tipos de t cnicas de an lise a elabora o das conclus es foi elaborada atrav s da rejei o das hip teses nulas com testes param tricos e ou atrav s de sua aceita o com os testes n o param tricos Para o teste das hip teses em um contexto de um fator e dois tratamentos a literatura sugere que o teste de signific ncia chamado teste T para duas amostras
72. 1 5000 Cabe relembrar o segundoobjetivo deste experimento listado no item 7 1 1 1 Defini o dos Objetivos do Experimento que trata de verificar se a precis o no planejamento do cronograma de projetos de software relacionado atribui o de prazos e recursos considerando a integra o do projeto com os fluxos organizacionais atrav s do modelo integrado SPIM igual precis o para realizar o planejamento de acordo com o modelo tradicional Desta forma comparando se os valores m dios das duas abordagens pode se concluir que a precis o para realizar o planeamento usando o modelo SPIM foi maior do que usando o modelo tradicional 7 1 2 3 An lise Qualitativa A fim de avaliar os conceitos advindos do modelo integrado SPIM sobre a sua aceita o e aplicabilidade tamb m foi realizada uma avalia o qualitativa explorat ria No final da execu o do experimento cada participante respondeu a um question rio vide Ap ndice E produzido em conformidade com Rea e Parker REA05 Este question rio possui 17 quest es onde as 8 primeiras est o focadas em mapear o conhecimento individual de cada gerente o restante das quest es foi utilizado para coletar contribui es e sugest es dos gerentes considerando o modelo SPIM no processo de planejamento de projetos de software 166 Uma an lise dos resultados obtidos a partir das quest es relacionadas com o perfil dos indiv duos mostra que 52 77 deles possuem uma exp
73. 2 Selecao dos Individuos A popula o definida para o experimento formada por alunos do curso de p s gradua o em gest o de projetos da Faculdade de Inform tica da PUCRS e do IBGEN Ser um total de trinta e seis alunos Ser utilizada uma amostragem n o probabil stica para sele o dos indiv duos e Amostragem por conveni ncia ser o escolhidas as pessoas mais convenientes para o experimento D 5 3 Princ pios Observados para o Projeto do Experimento Dentre os principios gen ricos para o projeto do experimento caracterizamos e Aleatoriedade a aleatoriedade ser utilizada para definir quais participantes ir o executar cada abordagem de planejamento de projetos de software tradicional ou com aux lio do modelo SPIM e Balanceamento este princ pio ser utilizado em nosso experimento para que cada proposta de planejamento de projetos de software seja executada pela mesma quantidade de participantes D 5 4 Tipo de Experimento e Defini o das Unidades Experimentais Para cada hip tese ser o utilizadas as seguintes nota es e Utra Planejamento de atividades de projetos de software tradicional e Uspim Planejamento de atividades de projetos de software com apoio do modelo SPIM O tipo de projeto apresentado procura investigar se Utaapossui o mesmo esfor o e precis o que Uspim Para este fim ser utilizada uma abordagem chamada um fator com dois tratamentos O fator neste experimento consiste na t cnica que s
74. 2 dias 1171072011 1271072011 16 Fulano amp 29 Executar Testes 2 dias 43 10 2014 14 10 2044 30 Executar Plano de Teste 2 dias 131072011 141072011 28 Fulano T 31 Finalizar Fase de Constru o 1 dia 24 10 2011 24 10 2011 25 50 32 Transi o 2 dias 25 10 2014 26 10 2014 5 Integrar Sistema 2 dias 25 10 2071 26 10 2007 34 Prepara o e Valida o do Ambiente 1 dia 2510 2011 25 10 2011 34 Fulano 2 35 Revisar Projeto e Aprova es 1 dia 256 1072011 261072011 34 Fulano 2 36 Disponibiliza o da release 1 0 PRD 2 dias 26 10 2014 27 10 2014 af Acompanhamento do projeto 2 dias 265 1042011 277 102011 34 Fulano 1 a6 Teste de Aceita o 2 dias 2810 2011 TM 02011 34 Fulano amp 39 Fechar Projeto 1 dia 28 10 2011 2810 2011 40 Reuni o para Encerrar Projeto 1 dia 25 10 2011 25102011 37 38 Fulano 1 41 Finalizar Projeto 1 dia S11 0 201 4 31 10 2011 40 E 6 Figura 99 Projeto para o cen rio 5 QUESTION RIO DE AVALIA O DO MODELO SPIM Veja abaixo o question rio de avalia o do modelo SPIM Avalia o do modelo SPIM Resumo sobre os conceitos do modelo integrado Ao realizar planejamento de um projeto o gerente de projetos pode necessitar interagir com outros departamentos da organiza o a fim de obter informa es relevantes sobre as atividades gerenciais de apoio necess rias para a realiza o das atividades produtivas do projeto Por exemplo durante o planejamento de atividades de projeto de software o gerente
75. 3 75 DORN J KERR R M THALHAMMER G Reactive scheduling improving the robustness of schedules and restricting the effects of shop floor disturbances by fuzzy reasoning International Journal of Human Computer Studies vol 42 1995 pp 687 704 DUTTA A Reacting to scheduling exceptions in FMS environments IIE Transactions vol 22 4 1990 pp 33 314 ENGWALL M JERBRANT A The resource allocation syndrome the prime challenge of multi project management International Journal of Project Management vol 21 6 2003 pp 403 409 EVERS J H Multi project support issues cycle time and schedule effects when people support multiple concurrent projects In Proceedings of the 2000 IEEE Engineering Management Society 2000 pp 19 24 FALBO R A Integra o de Conhecimento em um Ambiente de Desenvolvimento Tese de Doutorado COPPE UFRJ 1998 FENTON N PLEEGER S L Software Metrics A rigorous amp Pratical Approach Boston MA PWS Publishing Company ang edition 1997 FIELD A Discovering Statistics Using SPSS Sage Publications 2 edition 2005 FIRO2 FRIOO FUG00 IGAR94 GAR95 GIN95 GLO95 GOU98 IGRAQ7 GRU69 GRUO4 HELO3 HEC00 HENOO HENO1 FIRESMITH D HENDERSON SELLERS B The OPEN Process Framework An Introduction Addison Wesley Harlow 2002 FRICKE S E SHENHAR A J Managing multi
76. 9 pp 293 301 AYE T TUN K A Collaborative Mobile Agent based Workflow System In 6 Asia Pacific Symposium on Information and Telecommunication Technologies 2005 pp 59 65 AYTUG H LAWLEY M A MCKAY K MOHAN S UZSOY R Executing production schedules in the face of uncertainties A review and some future directions European Journal of Operational Research vol 161 1 2005 pp 86 110 BAJEC M VAVPOTIC D KRISPER M Practice Driven Approach for Creating Project Specific Software Development Methods Information and Software Technology 2007 pp 345 365 BECK K Extreme Programming Explained Embrace Change Addison Wesley 1999 BELZ R MERTENS P Combining knowledge based systems and simulation to solve rescheduling problems Decision Support Systems vol 17 2 1996 pp 141 157 BENDOLY E SWINK M Moderating effects of information access on project management behavior performance and perceptions Journal of Operations Management vol 25 3 2007 pp 604 62 BENCOMO A Extending the RUP Capturado em http www ibm com developerworks rational library 05 323 extrup1 ind ex html Novembro 2006 BEZERRA E Princ pios de An lise e Projeto de Sistemas com UML Rio deJaneiro Elsevier 2007 2 Edi o 369p BILLINGTON J CHRISTENSEN S VAN HEE K E KINDLER E KUMMER O PETRUCCI L POST R STEHNO C WEBER M The Petri Net
77. AO REN CHEN QING XIN MAO NIN A heuristic algorithm for resource constrained project scheduling Journal of Industrial Engineering and Engineering Management vol 16 2002 pp 100 103 practices on Process An 197 198 LOVO1 ILYC04 IMAC93 IMAC00 IMCC96 IMEH99 IMEZOO MIL94 MILO6 IMIY95 IMOUO1 MUH82 IMUR89 IMYEO7 OAS01 LOVA A TORMOS P Analysis of scheduling schemes and heuristic rules performance in resourceconstrained multiple project scheduling Annals of Operations Research vol 102 1 4 2001 pp 263 286 LYCETT M RASSAU A DANSON J Programme management a critical review International Journal of Project Management vol 22 4 Maio 2004 pp 289 299 MACCARTHY B L LIU J Addressing the gap in scheduling research a review of optimization and heuristic methods in production scheduling nternational Journal of Production Research vol 31 1 1993 pp 59 79 MACHADO L F C Modelo para Defini o de Processos de Software na Esta o TABA Disserta o de Mestrado COPPE UFRJ 2000 MC CONNELL S Rapid Development Taming Wild Software Schedules Microsoft Press 1996 647p MEHTA S V UZSOY R Predictable scheduling of a single machine subject to breakdowns International Journal of Computer Integrated Manufacturing vol 12 1 1995 pp 15 38 MEZIANE F VADERA S KOBBACY K PROUDLOVE N
78. Cen rios de avalia o do modelo integrado SPIM 1 Cen rio 1 Cen rio 2 Cen rio 3 Cen rio 4 5 Cen rio 5 e Question rio de avalia o do modelo SPIM Observa o Os resultados desta pesquisa ser o disponibilizados para download de materiais em breve Obrigado por sua participa o Figura 93 Tela de apresenta o do estudo experimental 229 AP NDICE D Metodologia de Desenvolvimento do Protocolo de Avalia o do SPIM Este ap ndice cont m a descri o detalhada da metodologia de desenvolvimento do protocolo de avalia o do SPIM D 1 OBJETIVO Avaliar os conceitos advindos do modelo integrado SPIM no que diz respeito a sua aceita o e aplicabilidade de acordo com o ponto de vista dos estudantes de pos gradua o em gest o de projetos de software D 2 CARACTERISTICA CHAVE DO METODO DE PESQUISA Este o roteiro para o desenvolvimento e aplica o de um instrumento de pesquisa baseado em um estudo experimental D 3 ORGANIZA O DESSE PROTOCOLO DE AVALIA O D 3 1 Procedimentos Tabela 22 Procedimentos para o desenvolvimento do protocolo de avalia o A Reuni es para levantamento das questoes e estrutura o do roteiro do estudo Participantes Maur cio Covolan Rosito Prof Dr Ricardo Melo Bastos Local PPGCC Programa de P s Gradua o em Ci ncia da Computa o FACIN PUCRS Datas Abril de 2011 B Valida o de face e conte do Participante Prof Dr Marcelo Blois Ribeiro
79. Com base nestas informa es utiliza se nesta tese a estrat gia de reparo ajuste da programa o do projeto 4 1 2 2 Quando Reprogramar as Atividades do Projeto Quanto a segunda quest o quando reprogramar as atividades do projeto tr s pol ticas s o propostas na literatura SABOO VIE03 peri dico dirigido a eventos e h brido As pol ticas peri dicas e h bridas t m recebido aten o especial sob o nome de rolling time horizon CHU92 OVA94 SAB99 VIE00a AYTO5 Na pol tica de reprograma o peri dica os agendamentos s o gerados em intervalos regulares que re nem todas as informa es dispon veis do projeto at o momento O problema da programa o din mica decomposto em uma s rie de problemas est ticos que podem ser resolvidos por meio de algoritmos de agendamento A programa o das atividades ser executada mas n o ser revisada at que o pr ximo per odo inicie A politica de reprograma o peri dica pode gerar maior estabilidade e 74 menor nervosismo da programa o Entretanto a determina o do periodo de reprograma o uma tarefa dif cil Um importante exemplo sobre a aplica o da abordagem rolling time horizon para a programa o din mica descrito em MUH82 Eles investigaram como a frequ ncia de agendamentos em um ambiente din mico de trabalho afetou o desempenho do projeto onde as varia es de tempo de processamento e quebra de recursos ocorrem aleatoriamente
80. EL99 IDER99 IDEWOS DIWO8 DONO8 DOR95 DUT90 ENGO3 EVE00 FAL98 FEN97 FIE05 Research vol 139 2 2002 pp 230 244 DANIELS R L amp KOUVELIS P Robust scheduling to hedge against processing time uncertainty in single stage production Management Science vol 41 2 1995 pp 363 737 DEBLAERE F DEMEULEMEESTER E HERROELEN W VAN DE VONDER S Robust Resource Allocation Decisions in Resource Constrained Projects Decision Sciences vol 38 2007 pp 5 37 DELEN D BENJAMIN P ERRAGUNTLA M An Integrated Toolkit for Enterprise Modeling and Analysis In Proceedings of the 1999 Winter Simulation Conference 1999 pp 289 297 DERNIAME J C KABA B A WARBOYS B Software Process Principles Methodology and Technology Lecture Notes in Computer science 1500 Springer 1999 DEWSON R Beginning SQL Server 2008 for Developers From Novice to Professional Apress 2008 DIWAKAR D E DIWAKAR S CINWEGS An Integrated Web and Grid Services Framework for Collaborative Solutions In 4 International Conference on Next Generation Web Services Practices 2008 pp 21 27 DONG F LI M ZHAO Y LI J YANG Y Software Multi Project Resource scheduling A Comparative Analysis In Lecture Notes in Computer science Making Globally Distributed Software Development a Success Story Berlin Springer Link 2008 vol 5007 pp 6
81. EN no entanto o conjunto de elementos relacionadoscom uma nica atividade tais como os produtores os produtos de trabalho e unidades de trabalho que s o parte de um nico campo de conhecimento definido pela classe Activity Assim no OPEN uma disciplina est organizada em torno de uma nica atividade que pode conter v rias tarefas Al m disso esta classe composta de um conjunto de tarefas agrupadas de acordo com um objetivo comum e produz um conjunto de produtos interligados onde as rela es de depend ncia entre as atividades podem ser definidas atrav s de pr condi es e p s condi es Consequentemente a classe Activityno OPEN engloba os conceitos de classe Workflow Detaile Discipline do RUP De acordo com o RUP a classe Lifecycle define o ciclo de vida de desenvolvimento do software O OPEN prop e uma divis o entre os ciclos de vida de produtos e processos atrav s das classes Business Engineering Cycle Life Cycle e Development Cycle Assim a classe Life Cycle do OPEN compat vel com a classe de Lifecycle do RUP pois representa o conjunto de fases em que um nico sistema aplicativo ou componente principal que produzido ou utilizado A classe de Signature no RUP cont m dois atributos mutuamente exclusivos que indicam se um atributo usado para entrada ou sa da de uma determinada atividade Neste caso n o foi identificada uma classe semelhante no metamodelo OPEN A classe Endeavor no modeloOPEN repre
82. Em cada per odo de reescalonamento uma programa o est tica gerada para os trabalhos atuais Como antecipado o desempenho deteriora se geralmente quando o per odo de reescalonamento aumenta A politica de reescalonamento orientada a eventos acionada em resposta a um acontecimento inesperado que altera o status atual do projeto A maioria das abordagens de programa o din mica utiliza esta pol tica Nesta tese a solu o proposta tamb m se baseia na pol tica de reescalonamento orientada a eventos Vieira et al VIEQOb mostrou em sua pesquisa que a frequ ncia de reescalonamento pode afetar significativamente o desempenho do projeto Quanto menor for a frequ ncia de reescalonamento menor ser o n mero ajustes na configura o do projeto Uma frequ ncia de reescalonamento maior permite ao projeto reagir mais rapidamente s perturba es mas pode aumentar o n mero de ajustes A pol tica h brida faz o reescalonamento do projeto periodicamente e tamb m quando ocorre uma exce o Os eventos normalmente considerados s o avarias de hardware cancelamento de atividades ou mudan as de prioridade de atividades Church e Uzsoy CHU92 desenvolveram uma pol tica de reescalonamento h brida de reprograma o onde o projeto n o reescalonado periodicamente Eventos classificados como sendo de ocorr ncia regular s o ignorados at o momento seguinte de reescalonamento No entanto quando um evento classificado como urgen
83. European Journal of Operational Research vol 107 2 1998 pp 354 370 JUNGEL M KINDLER E WEBER M Towards a Generic Interchange Format for Petri Nets Position Paper In XML SGML based Interchange Formats for Petri Nets Aarhus Denmark 2000 JURISON J Software Project Management The Manager s View Communications of the Association for Information Systems vol 2 3 Novembro 1999 57p JURISTO N MORENO A Basics of Software Engineering Experimentation Kluwer academic Publishers Pii edition 2003 KER95 KEROO KIM95 KIMO5 KIT96 KITO4 IKRUOO KUM98 LEEO2 LEE04 LEA04 LEEO6 LEO94 LEU05 LEY00 LIAO2 KERR R M SZELKE E Artificial intelligence in reactive scheduling Dordrecht Kluwer Academic 1995 KERZNER H Applied project management best implementation New York Wiley e Sons 2000 534p KIM J W DESROCHERS A A SANDERSON A C Task planning and project management using Petri nets Proceedings of the IEEE International Symposium on Assembly and Task Planning Pittsburgh IEEE 1995 pp 265 270 KIM K W YUN Y S YOON J M ET AL Hybrid genetic algorithm with adaptive abilities for resourceconstrained multiple project scheduling Computers in Industry vol 56 2 2005 pp 143 160 KITCHENHAM B Software Metrics Oxford Blackwell Plublishers Inc 1996 KITCHENHAM B Procedures for per
84. Interdepend ncia entre os fluxos de trabalho organizacionais e o fluxo de projetos de software adaptado de ROS 13 c erre 119 Figura 37 Etapas de desenvolvimento do SPIM eretas 121 Figura 38 Classes do modelo integrado SPIM ROS 13 s nn 122 FOUN Tela do BaCcKOMICO cartas atada e stat ass Sra pd a 129 Figura 40 Exemplo de Flowchart workflow errar era errar nre rrenan 131 Figura 41 Formatos de entrada e sa da do m dulo Compiler ROS12Cc 133 Figura 42 Diagrama de pacotes do M dulo Compiler erre 134 Figura 43 Diagrama de Classes do pacote entities c erre 135 Figura 44 Tradu o dos dados do gr fico de Gantt em elementos da rede de Petri adaptado Ge ROS 12C sais sasasissa Ria sp Eni sdn dada sda do nada dans E Sha sb dn san di ias in sd nina 137 Figura 45 Gera o de redes de Petri NO SPIT eee erre 138 Figura 46 Rede de Petri para um projeto de software fict cio c i iii 139 Figura 47 Trecho do codigo PNML onde est o descritos os lugares da RdP 140 Figura 48 Trecho do c digo PNML onde est o descritos as transi es da RdP 141 Figura 49 Trecho do c digo PNML onde est o descritos os arcos da RdP 142 Figura 50 Hierarquia em que foram estruturadas as tabelas ii 145 Figura 51 Site sobre o experimento do modelo SPIM
85. LEE04 Al m disso ao contr rio do modelo tradicional de gerenciamento de projetos que descreve os projetos individualmente os modelos de gest o multiprojetos devem lidar com as interdepend ncias entre os diferentes projetos com um conjunto de restri es relacionado disponibilidade de tempo e de recursos ADB91 Os gestores tamb m devem considerar que durante o planejamento e execu o de projetos de software diferentes tipos de tarefas s o atribu dos a recursos com caracter sticas diferentes resultando num conjunto complexo de depend ncias entre as atividades a fim de alcan ar as metas relacionadas ao tempo e aos custos desses projetos Assim em resposta s novas informa es ou estimativas os gestores podem precisar fazer altera es no plano de projeto tais como a realoca o de recursos ou cancelamento de tarefas JOSO5 Esses ajustes necess rios para o projeto de acordo com as modifica es que ocorrem durante seu ciclo de vida d o origem ao termoreconfigura o din mica de projetos Pesquisas nesta rea t m tradicionalmente abordado este problema de uma perspectiva est tica com foco em aspectos relacionados ao planejamento inicial dos projetos Mais recentemente este problema tem sido tratado numa perspectiva din mica atrav s do qual os projetos se adaptam durante a sua execu o fato que envolve a adi o exclus o e modifica o de atividades e a realoca o de recursos CALO8 Tais mudan a
86. Markup Language Concepts Technology and Tools In W M P van der Aalst and E Best eds Applications and Theory of Petri Nets 2003 24th International Conference Eindhoven The BIO05 BONOO BOO00 BRAN99 BREO1 CALO7 ICALO8 ICAL10 ICARQ7 CHA10 CHE05 CHU92 COE03 COW00 COW02 Netherlands 2003 BIOLCHINI J MIAN P G NATALI A C C TRAVASSOS G H Systematic review in software engineering Rio de Janeiro 2005 31p BONGAERTS L MONOSTORI L MCFARLANE D KADAR B Hierarchy in distributed shop floor control Computers in Industry vol 43 2 2000 pp 123 137 G BOOCH J RUMBAUGH JACOBSON UML guia do usu rio Rio de Janeiro Elsevier 2000 472 p BRANDIMARTE P VILLA A Modelling manufacturing systems from aggregate planning to real time control Berlin Springer 1999 BRENNAN R W NORRIE D H Evaluating the performance of reactive control architectures for manufacturing production control Computers in Industry vol 46 3 2001 pp 235 245 CALLEGARI D E BASTOS R Project Management and Software Development Processes Integrating RUP and PMBOK In ICSEM International Conference on Systems Engineering and Modeling Haifa Israel 2007 8p CALLEGARI D ROSITO M BLOIS M BASTOS R An Integrated Model for Managerial and Productive Activities in Software Development In ICEIS 10
87. O3 VAN98 VERO5 VIE00a VIEOOb VIEO3 IWAROS IWCG04 WEB02 WER96 THARUMARAJAH A BEMELMAN R Approaches and issues in scheduling a distributed shop floor environment Computers in Industry vol 34 1 1997 pp 95 109 TRAVASSOS G H GUROV D AMARAL G Engenharia deSoftware Experimental 590 02 COPE UFRJ 2002 66 p TSAI H MOSKOWITZ H LEE L Human resource selection for software development projects using taguchis parameter design European Journal of Operational Research vol 151 1 2003 pp 167 180 TYRRELL S The Many Dimensions of the Process Crossroads vol 6 4 2000 pp 22 26 UHER T Programming And Scheduling Techniques University of New South Wales Press Sydney 2003 295p VAN DER AALST W The Application of Petri Nets to Workflow Management The Journal of Circuits Systems and Computers vol 8 1 1998 pp 21 66 VERNER M CERPA N Australian software development what software project management practices leed to success In IEEE Proceedings of ASWEC Ed Paul Strooper Brisbane Australia 2005 pp 70 77 VIEIRA G E HERRMANN J W LIN E Analytical models to predict the performance of a single machine system under periodic and event driven rescheduling strategies International Journal of Production Research vol 38 8 2000 pp 1899 1915 VIEIRA G E HERMANN J W LIN E Predicting the pe
88. ONSIDERA ES FINAIS DO CAP TULO arser eiun ses Cais AD e ade ead ence a a aa 67 RECONFIGURA O DIN MICA DE PROJETOSG c cccscssssssssssssssssssssssssssssssssssssssssssssssessssessssessssessseesees 68 4 1 PROGRAMA O DINAMICA DE SISTEMAS sans EURO Gn taeelleeaaane 69 4 1 1 O Problema da Programa o DINAMICA ccccccccccccscssssscccccsesesssceeccccesssssceeeccccsesessseeeeeeeeesetseeeeeeees 69 4 1 2 Reprograma o das Atividades na Presen a de Eventos em Tempo Real Za 4 2 RECONFIGURAGAO DIN MICA DE PROJETOS DE SOFTWARE DEFINI O E CONCEITOS RELACIONADOS 81 4 2 1 Defini o e Aspectos Relacionados ncs EE TE EEE 81 4 2 2 Eventos que Demandam Reconfigura o Din mica dos Projetos de Software 82 4 3 REVIS O SISTEM TICA SOBRE A RECONFIGURA O DIN MICA DE PROJETOS DE SOFTWARE 86 4 3 1 Planejamento da Revis o Sistem tica cccccccccccccccseesccccccceeessssceeccecesesssceescecesessssseeeecceesssttseeeeeeees 87 Ho Anale OOS RESLNADOS iia es CR RA 89 4 3 3 Limita es da REVISAO SISIOMGL CA isa ssiusia dadas de dadiasinaSaasGaM AL eodaad eas ean onde rine DINDA a Us Danda ensina 93 44 CONSIDERA ES FINAIS DO CAPITULO suarsasstasasdaoando SeSAsUU LINDAS cashback ieee SERA LISA Lab as S d a ideas san ias ad 94 APLICA O DAS REDES DE PETRI NA GEST O DE PROJETOS ssscssscssscssscssscssscssscssscssecesccssecs 95 5 1 VOCABUL RIO E CONCEITOS ASSOCIADOS surdina aa SE gta ee
89. PONTIFICIA UNIVERSIDADE CATOLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMATICA PROGRAMA DE P S GRADUA O EM CI NCIA DA COMPUTA O Reconfigura o Din mica de Projetos de Software Um modelo para integrar a ger ncia de projetos de software com os fluxos organizacionais Maur cio Covolan Rosito Tese de Doutorado apresentada como requisito parcial para obten o do grau de Doutor em Ci ncia da Computa o na Pontif cia Universidade Cat lica do Rio Grande do Sul Orientador Prof Dr Ricardo Melo Bastos PORTO ALEGRE 2014 Dados Internacionais de Catalogacao na Publicacao CIP Rosito Mauricio Covolan Reconfigura o din mica de projetos de software um modelo para integrar a ger ncia de projetos de software com os fluxos organizacionais Mauricio Covolan Rosito Porto Alegre 2014 247 p Tese Doutorado Fac de Informatica PUCRS Orientador Prof Dr Ricardo Melo Bastos 1 Inform tica 2 Engenharia de Software 3 Administra o de Projetos I Bastos Ricardo Melo II Titulo CDD 005 1 Ficha Catalografica elaborada pelo Setor de Tratamento da Informa o da BC PUCRS Pontificia Universidade Catolica do Rio Grande do Sul FACULDADE DE INFORMATICA PROGRAMA DE POS GRADUACAO EM CIENCIA DA COMPUTACAO TERMO DE APRESENTACAO DE TESE DE DOUTORADO Tese intitulada Reconfigura o Din mica de Projetos de Software Um Modelo para Integrar a Ger ncia de Projetos de Software com os Fl
90. Quest o da Pesquisa Como realizar a reconfigura o din mica de projetos de software em tempo de execu o no que concerne programa o das atividades considerando a integra o do fluxo de trabalho de um projeto de software com os demais fluxos de trabalho da organiza o 1 3 Metodologia de Pesquisa Embora alguns trabalhos relacionados com o objetivo desta pesquisa tenham sido encontrados na revis o te rica desenvolvida n o se tem conhecimento de que o problema apresentado tenha sido tratado da mesma maneira em outros estudos Desta forma esta pesquisa se caracteriza como explorat ria sendo o principal m todo de pesquisa utilizado de acordo com a classifica o de Oates OATO6 projeto e cria o do ingl s design and creation Segundo Oates OATO6 a estrat gia de pesquisa chamada projeto e cria o t m como finalidade o desenvolvimento de novos produtos de tecnologia da informa o TI que podem ser constru es modelos m todos ou instancia es Para este ultimo caso considera se como instancia o um trabalho que demonstra que modelos m todos g neros ou teorias podem ser implementados em um sistema de computador Salienta se que para que os projetos que seguem a estrat gia de projeto e cria o possam ser considerados de fato uma pesquisa estes devem demonstrarqualidades acad micas como an lise discuss o justificativa e avalia o cr tica OATO6 23 Nesta pesquisa os no
91. Rede de Petri gerada para o Cen rio 1 Ap s a gera o da rede de Petri o modelo SPIM envia uma mensagem para o modelo de reconfigura o din mica proposto por Callegari CAL10 Este modelo dispara os solvers os quais tentam localizar novos recursos que possam substituir o recurso Fernando Neste cen rio pode se considerar tanto o uso do solver padr o CAL10 quando o uso do solver multiagentes SCH10 uma vez que para esta pesquisa necess rio apenas considerar que o modelo retorne o nome de um recurso dispon vel Infelizmente o modelo de reconfigura o retorna que nenhum recurso no pool possui disponibilidade no momento para assumir as tarefas afetadas Portanto o modelo SPIM instancia um fluxo organizacional para a contrata o de recursos antecipando que s o necess rias em m dia 4 unidades de tempo para que a equipe de recursos humanos da empresa finalize esse processo A pequena folga existente antes do fluxo organizacional considerando que ainda restam 5 unidades de tempo antes que a primeira tarefa alocada para o recurso Fernando seja executada indica que poss vel iniciar o processo de contrata o do novo recurso uma unidade de tempo antes do previsto Atrav s da simula o da rede de Petri o gestor pode avan ar 4 unidades de tempo no cronograma Desta forma o prot tipo SPIT simula uma mensagem de retorno do sistema de workflowresponsavel pela gest o do fluxo organizacional contrata o de pessoas As
92. SCRI O DAS PRINCIPAIS CLASSES DO SPEM 2 0 Este ap ndice apresenta o funcionamento e a descri o das principais classes dos pacotes do SPEM 2 0 A 1 PACOTE CORE O pacote Core o pacote n cleo do SPEM 2 0 Nesse pacote as metaclasses e abstra es que constroem a base para todos os outros pacotes do metamodelo s o definidas Basicamente o pacote Core define duas capacidades para o SPEM 2 0 e A habilidade para usu rios criarem qualifica es para diferentes metaclasses do SPEM 2 0 distinguindo elas com diferentes kinds e Um conjunto de metaclasses abstratas para expressar o trabalho nos processos de software Todas as metaclasses do metamodelo SPEM 2 0 que derivam das metaclasses de trabalho definidas no Core tem como objetivo mapear os modelos de comportamento do processo As metaclasses definidas no pacote Core tem como super classes as metaclasses definidas na UML 2 0 e ser o exibidas nas Figura 73e Figura 74 5 Cass de Constructs applicableMetaClass 1 Applicable MetaClass self conformsTo self lind applicableMetaClass Figura 73 Metaclasses ExtensibleElement e Kind definidas no pacote Core A metaclasse ExtensibleElement vista na Figura 73 uma generaliza o abstrata que representa qualquer metaclasse do metamodelo SPEM 2 0 que pode ter uma qualifica o definida pelo usu rio Cada metaclasse do metamodelo SPEM 2 0 que permite utilizar esta qualifica o deriva direta ou indire
93. Sin nimos emingl s Project Management Gerenciamento de projetos Business Process Processo de Neg cio Business Workflow 218 Managerial Activity Atividade Gerencial Enterprise activity Organizational Activity Productive Activity Atividade Produtiva Dynamic Reconfiguration Reconfigura o Din mica Interven o Identifica o e avalia o das solu es expostas nas pesquisas Controle inexistente Efeito definir o estado da arte sobre aspectos relacionados com a reconfigura o din mica de projetos de desenvolvimento de software Medi o de resultados n mero de trabalhos identificados considerando os crit rios de inclus o e exclus o de trabalhos Popula o artigos publicados em peri dicos e anais de confer ncias relacionados ao tema de pesquisa cuja data de publica o seja posterior a 2000 Aplica o pesquisadores da rea e engenheiros de processo Projeto experimental n o se aplica B 2 Sele o das Fontes B 2 1 Defini o dos Crit rios de Sele o das Fontes Disponibilidade de consulta a artigos completos full papers atrav s da Web pelo conv nio PUCRS CAPES exist ncia de mecanismos de busca com suporte a inser o de operadores booleanos como and e or e base de dados atualizada com publica es dos ltimos 10 anos B 2 2 Idiomas Ingl s A justificativa para esta escolha se deve universalidade do idioma sendo o padr o de confer ncias e peri d
94. Sour oe e prumeralron gt ParameterDirectionkind im WorkProductUseRelationship inout re Figura 13 Metamodelo de integra o PMBOK SPEM ROS12a 66 A rela o nestedBreakdownElement tamb m definida entre as metaclasses Activity e BreakdownElement Ela permite o aninhamento de elementos tal como outras atividades marcos etc dentro de uma atividade A rela o entre a classe Activity e a classe ProcessParameter estabelece atrav s do atributo direction e da metaclasse de enumera o ParameterDirectionKind OS par metros de entrada e ou sa da para as atividades em termos de produtos de trabalho classe WorkProductUse A classe WorkProductUseRelationship estabelece rela es depend ncia composi o e agrega o entre as classes WorkProductUses A rela o de depend ncia citada por v rios estudos tais como Y 0001 BAJO7 OMG12 PAR11 e estabelece que um produto de trabalho source depende de um ou mais produtos de trabalho target para ser produzido em um processo de software J as rela es de agrega o e composi o possuem o mesmo significado de rela es da UML e estabelecem que um produto de trabalho source pode ser composto por um ou mais produtos de trabalho target em um processo de software A diferen a entre as rela es de agrega o e composi o que assim como na UML uma rela o de composi o estabelece uma rela o mais forte entre os produtos de tr
95. TROVIC S Utility and stability measures for agent based dynamic scheduling of steel continuous casting In Proceedings of the IEEE international conference on robotics and automation Taipei Taiwan 2003 pp 175 180 OVACIK M UZSOY R Rolling horizon algorithms for a single machine dynamic scheduling problem with sequencedependent set up times International Journal of Production Research vol 32 6 1994 pp 1243 1263 PARUNAK H V Applicat 1ions of distributed artificial Intelligence in industry In G M P O Hare amp N R Jennings Eds Foundation of distributed artificial intelligence New York Wiley Interscience Chap 4 1996 PARUNAK H V Agents in overalls experiences and issues in the development and deployment of industrial agent based systems International Journal of Cooperative Information Systems vol 9 3 2000 209 227 199 200 PAR11 PEPO9 PERO5 PERO7 PET81 PFLO9 PLE98 PMIOS PRAO4 PRE09 RATOS REAO5 REDO1 REHO7 RIHO1 PARK S BAE D H An Approach to Analysing the Software Process Change Impact Using Process Slicing and Simulation The Journal of Systems and Software 2011 pp 528 543 PROCESS ENGINEERING PROCESS A RUP Adoption Process Capturado em http www 128 ibm com developerworks rational library 6001 html Agosto 2009 GONZALEZ PEREZ C HENDERSON SELLERS B Templates
96. a o na aloca o de recursos e de outros elementos de projeto Um plano de projeto de software especifica e limita o escopo do projeto descreve os poss veis riscos do projeto define os recursos de hardware e software dispon veis descreve a estrutura de divis o de trabalho e o cronograma do projeto LEE06 De acordo com Sommerville SOMO6 o cronograma do projeto especifica rela es de depend ncia o tempo estimado exigido para alcan ar cada etapa do projeto e a aloca o das pessoas envolvidas em cada atividade Neste cen rio uma configura o de projeto envolve n o somente o planejamento das atividades mas tamb m o planejamento dos recursos dispon veis suas caracter sticas e como esses recursos s o alocados s atividades As informa es em n vel de projeto como a prioridade sobre outros projetos e sobre a disponibilidade dos recursos s o adicionados ao plano No entanto devem se considerar as mudan as no plano de projeto especialmente aquelas que ocorrem durante a execu o do projeto Assim a reconfigura o din mica dos projetos envolve sucessivos replanejamentos para 82 o mesmo projeto durante sua execu o O planejamento de um projeto tamb m envolve a sele o e a defini o das atividades necess rias para o cronograma do projeto Desta forma o sequenciamento e a depend ncia das atividades em um projeto determinam a ordem em que estas ser o realizadas e tamb m quais atividades podem ser execut
97. a o do stakeholder com o projeto por exemplo se um stakeholderchave do projeto seu nivel de interesse no projeto e seu n vel de influ ncia no projeto A classe ActivityPhysicalResourceWork associa zero ou mais recursos f sicos para zero ou mais atividades classe Activity Ela estabelece a carga de trabalho f sico recursos atributoworkload nessa atividade Os stakeholders podem desempenhar v rios pap is classe Role durante a execu o das atividades do projeto Assim para cada associa o entre um papel e uma atividade classe ActivityStakeholderWork deve haver uma associa o desta atividade com um stakeholder capaz de desempenhar esse papel Assim as atividades gerenciais s o realizadas por pap is roles de gest o e atividades produtivas s o realizadas por pap is produtivos Conforme mencionado anteriormente o modelo proposto define tr s tipos diferentes de atividades Atividades diretamente relacionadas com a constru o do produto tais como codifica o ou modelagem de banco de dados s o chamadas de atividades produtivas classe ProductiveActivity Atividades gerenciais classe ManagerialActivity no entanto podem pertencer ao fluxo de trabalho de desenvolvimento de software atributo isExternal false ou pertencem ao fluxo organizacional atributo isExternal true Cada atividade pode pertencer a uma ou mais baselines Em cada gera o de baseline uma atividade deve estar relacionada a pap is e prod
98. a o dos dados e dos comportamentos obtidos como resposta Conclus es e demais indica es de trabalhos futuros encontram se no Cap tulo 8 2 2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE E A GESTAO DE PROJETOS Para um bom entendimento do modelo proposto e dos trabalhos relacionados faz se necess rio a compreens o dos fundamentos te ricos e metodologias b sicas nos quais esta pesquisa se baseia Desta forma este cap tulo apresenta uma introdu o sobre os processos de desenvolvimento de software a gest o de projetos e sobre outros conceitos utilizados no contexto desta pesquisa 2 1 Processo de Desenvolvimento de Software Defini o e Aspectos Relacionados De acordo com Jacobson Booch e Rumbaugh JACO1 um processo de desenvolvimento de software o conjunto completo de atividades necess rias para transformar os requisitos dos usu rios em produtos de software Como as organiza es geralmente consideram o desenvolvimento de um produto de software como um projeto ent o um processo pode ser considerado como uma sequ ncia de passos que um projeto pode seguir para desempenhar alguma tarefa Para Sommerville SOMO6 um processo de desenvolvimento de software um conjunto de atividades e resultados associados que levam a produ o de um produto de software Ainda segundo Fuggetta FUGOO o processo de desenvolvimento de software pode ser definido como um conjunto coerente de pol ticas estruturas organizacionais
99. a o e de mudan a de estado do sistema e Atividades s o as caixas pretas utilizadas para recuperar e esconder a evolu o do sistema f sico entre dois eventos Portanto os eventos correspondem em geral ao in cio e ao fim de uma atividade e Processos s o sequ ncias de eventos e de atividades interdependentes Por exemplo um evento provoca uma atividade que provoca um evento de fim de atividade que por sua vez pode provocar outra atividade e assim por diante 5 1 3 Paralelismo Coopera o Competi o A evolu o dos processos num sistema pode ocorrer de forma simult nea ou n o Quando ocorrer de forma simult nea os processos podem ser completamente independentes ou relativamente independentes Esta independ ncia relativa significa que certas atividades s o totalmente independentes entre si enquanto que outras atividades 97 necessitam de pontos de sincroniza o isto de eventos comuns a v rias evolu es De acordo com Murata MUR89 existem diferentes formas de intera o entre processos e Coopera o os processos concorrem a um objetivo comum procura se descrever uma independ ncia de processos antes de um ponto de sincroniza o e Competi o os processos devem ter acesso a um dado recurso para realizar sua tarefa Se existisse um n mero suficiente de recursos os processos seriam completamente independentes Trata se portanto de um partilhamento de recursos resolvido em geral por exclus
100. a WBS gerada atrav s das seguintes regras 1 Cada lugar da rede de Petri transcrita como uma atividade da WBS As informa es sobre o tempo das atividades tamb m s o extra das dos lugares da RdP O ponto de inicio do projeto identificado pelo lugar que cont m uma ficha na RdP As atividades que dependem da execu o de outras atividades predecessoras s o transcritas 144 4 Um ponto no fluxo da rede onde diferentes fluxos paralelos convergem em um unico fluxo representado por uma atividade e n atividades predecessoras o A classe de um lugar que corresponde a um recurso executor transcrito para um objeto de recurso na WBS 6 3 5 Simulator O m dulo Simulator implementa o simulador de redes de Petri do software SPIT Objetivando a otimiza o de desempenho deste m dulo as redes de Petri s o representadas internamente considerando apenas as informa es relevantes para a simula o Desta forma o modelo de representa o de RdP para o m dulo Simulator foi desenvolvido de acordo com os seguintes crit rios e Nao redundancia as informa es redundantes na representa o da RdP foram exclu das Ainda o modelo de representa o da RdP compacto para evitar o desperd cio demem ria e Acesso r pido o simulador precisa obter rapidamente as informa es que procura de modo que o simulador define uma janela de tempo para limitar suas buscas e Relevancia apenas as informa es necess r
101. a as informa es contidas na WBS de um projeto de software foi apresentado na se o 5 3 Mecanismo de Mapeamento entre o 143 Diagrama de Rede e a Rede de Petri Resumidamente a RdP gerada atrav s das seguintes regras 1 Cada atividade do projeto transcrita como um lugar uma transi o e um arco de entrada ligando o lugar transi o O in cio do projeto definido pela aloca o de uma ficha em um lugar da RdP O ponto de converg ncia deatividades executadas em paralelo representado por uma transi o e dois ou mais lugares de entrada Um ponto no projeto onde uma atividade predecessora de duas ou mais atividades representado atrav s de uma transi o imediata considera se nesta tese que o tempo gasto para a realiza o da atividade est registrado no lugar que corresponde a esta atividade Assim ligadas ao lugar de sa da h duas ou mais transi es imediatas respons veis pela representa o de cada fluxo a ser seguido Cada agrupamento de atividades tal como uma fase n o s o considerados na gera o da rede de Petri O recurso alocadoparauma atividade deve ser representado com um objeto em um lugar de recurso o qual deve ser ligado at a transi o que representa a atividade por um arco restaurador 6 3 4 4 2 Gera o da WBS Atrav s das informa es referentes aos projetos de software que est o contidos na rede de Petri contidas em lugares arcos e transi es
102. a estes dois pacotes permaneceram inalterados Desta forma uma vez que o SPEM 2 0 um metamodelo desenvolvido pelo OMG para a defini o de processos de desenvolvimento de software e seus componentes esta pesquisa avan ou para a cria o do modelo PMBOK SPEM Faz se necess rio desta forma tamb m definir os termos utilizados no presente estudo para os principais elementos de um processo de software Isso porque mediante a exist ncia de v rios processos de software na literatura nem sempre o nome dos elementos s o os mesmos sendo comum o fato de termos diferentes terem o mesmo significado Nesta pesquisa assume se a utiliza o dos termos apresentados no metamodelo SPEM na sua vers o 2 0 OMG12 que s o Atividade Artefato Papel e Tarefa Contudo como outros processos de software s o utilizados em alguns pontos deste trabalho a Tabela 7 apresenta a correla o entre os termos utilizados nos processos RUP e OPEN com os termos do metamodelo SPEM Tabela 7 Principais terminologias utilizadas nos processo de software SPEM 2 0 Artefato Papel Atividade Tarefa RUP Artefato Papel Fase Itera o Workflow Detail Atividade OPEN Produto de Produtor Atividade T cnica Workflow Tarefa Trabalho Stage modelo SPIM ver Figura 38 foi concebido considerando a necessidade dos gerentes de projetos em acessar as informa es advindas de outros departamentos da organiza o durante o planejamento de projetos de software Para
103. a linguagem OCL implementa o de algum tipo de valida o l xica e estrutural nos parsers do m dulo Compiler do SPIT desenvolvimento de um protocolo para a avalia o do modelo proposto com empresas de software utilizando o prot tipo em projetos reais integra o com fluxos organizacionais complexos 191 integra o entre as plataformas de desenvolvimento do modelo SPIM com o modelo de refer ncia proposto por Callegari CAL10 e por Schl sser SCH10 A continuidade desta pesquisa indica novas contribui es para engenharia de software melhorando nossa compreens o dos aspectos relacionados reconfigura o din mica de projetos considerando os relacionamentos da ger ncia de projetos com os fluxos organizacionais 192 REFERENCIAS ABU97 ADB91 ARAO9 AYE05 AYTO5 BAJO7 BEC99 BEL96 BENO7 BENO9 BEZO7 BILO3 ABUMAIZAR R J SVESTKA J A Rescheduling job shops under random disruptions International Journal of Production Research vol 35 7 1997 pp 2065 2082 ABDEL HAMID T MADNICK S E Software Project Dynamics An Integrated Approach Englewood Cliffs NJ Ed Prentice Hall 1991 264p ARAUZO J A GALAN J M PAJARES J PAREDES A L Online scheduling in Multi projects Environments A Multi Agent Approach In 7 International Conference on Practical Applications of Agents and Multi Agent Systems PAAMS 200
104. a predecessora Embora o MPD apresente estes quatro tipos de rela es de depend ncias para os prop sitos especificados para o modelo SPIM utiliza se apenas a rela o t rmino para in cio Os demais tipos de depend ncia n o foram incorporados para simplificar o algoritmo CPM implementado O PMBOK Guide entretanto indica que normalmente s o utilizadas rela es de depend ncias t rmino para in cio em projetos desta natureza Ainda para melhor representar a inter rela o dos projetos de software com as atividades pertencentes aos fluxos organizacionais optou se descrever os cen rios utilizando as redes de Petri Conforme salientado anteriormente a rede de Petri uma ferramenta gr fica e matem tica para a modelagem an lise e verifica o de sistemas Assim a principal diferen a entre as redes de Petri e as outras ferramentas de modelagem a presen a de fichas tokens os quais s o utilizados para simular as atividades em um sistema din mico Outra informa o importante consiste no c lculo dos intervalos de in cio e t rmino das tarefas componentes de um projeto o qual realizado atrav s do M todo do Caminho Cr tico Critical Path Method CPM UHEOS Esses intervalos auxiliam na identifica o do conjunto de tarefas que n o podem ser adiadas em fun o do prazo do projeto A esse conjunto de tarefas cr ticas denomina se caminho cr tico o qual constitui o caminho mais longo do projeto UHEO3 As
105. a realiza o de um projeto O desrespeito com as depend ncias entre as atividades desses diferentes fluxos de trabalho podem resultar em distor es no planejamento de projetos de software Cabe lembrar que as atividades referentes aos fluxos de trabalho organizacionais usam recursos que n o s o atribu dos diretamente ao projeto de software No entanto esses recursos podem influenciar tanto em termos de prazos de atividades e custos do projeto de software por exemplo se o m dico respons vel pelo exame de admiss o precisa se afastar da empresa por alguns dias esse atraso pode afetar negativamente o cronograma dos projetos de software desta empresa Conforme observado no item 3 2 Necessidade de Integra o foram identificadas as principais car ncias de integra o dos projetos com os fluxos organizacionais ou seja 1 Acesso s informa es pertencentes aos outros departamentos da organiza o 2 Identifica o das rela es de depend ncia entre as atividades dos fluxos organizacionais e dos projetos de software 3 Capacidade de 187 minimizar distor es no planejamento de projetos tais como o aumento dos custos e atrasos nos prazos do projeto e 4 Aux lio na identifica o e mensura o dos custos indiretos do projeto Assim espera se que uma solu o satisfat ria para o problema deva fornecer algum tipo de suporte para esta integra o das atividades do projeto com os fluxos de trabalho organizacionais
106. a vari ncia ocorrida em um fen meno foi aleat ria e portanto a introdu o de um tratamento novo em um fator n o ocasionou influ ncia significativa Das hip teses foram definidas informalmente 1 necess rio um esfor o para o planejamento de projetos de software Sugere se que o esfor o para realizar o planejamento das atividades do projeto de software utilizando o modelo integrado SPIM igual ao esfor o para realizar o planejamento das atividades segundo o modelo tradicional 2 Sugere se que a precis o no planejamento do cronograma de projetos de software com rela o atribui o de prazos e recursos pensando na integra o com os fluxos organizacionais atrav s do modelo integrado SPIM igual precis o para realizar o planejamento segundo o modelo tradicional D 4 2 Sele o Das Vari veis Vari veis Independentes Assumiram se como vari veis independentes Experi ncia do time de gest o vari vel de bloqueio M todos para o planejamento das atividades de projetos de software Vari veis Dependentes Assumiram se como vari veis dependentes e Esfor o para o planejamento das atividades pertencentes aos projetos de software e Precis o atrav s da raz o entre a pontua o feita pelos participantes utilizando determinada t cnica e a pontua o total poss vel de acordo com um gabarito 233 Experi ncia do time de gestdo Tempo T cnicas para o planejamento das Proc esso atividades de pr
107. abalho Nesse tipo de rela o o s produto s de trabalho que representa m a s parte s na rela o n o faz em sentido sem o produto de trabalho que representa o todo desta rela o A classe ProcessPerformerestabelece a rela o entre as atividades e os pap is no processo de software A classe ProcessResponsabilityAssignment estabelece a rela o de responsabilidade entre os pap is classe ProductiveRole e os produtos de trabalho Originalmente no metamodelo SPEM 2 0 estabelecido que um produto de trabalho pode estar associado a zero ou v rios pap is respons veis em um processo de software o que representado com a multiplicidade 0 no relacionamento entre as metaclasses WorkProductUse e ProcessResponsabilityAssignment Exemplos t picos para a classe ProcessResponsabilityAssignment s o Executor Prim rio Executores adicionais Executor Auxiliar Executor Supervisor etc 67 3 4 Considera es Finaisdo Cap tulo Este Cap tulo apresentou os conceitos relacionados aos fluxos organizacionais objetivando salientar a distin o entre as atividades espec ficas em um projeto e as atividades que fazem parte do fluxo comum de trabalho da organiza o Ambos os tipos de fluxos de trabalho s o executados em paralelo possuem recursos pr prios e podem influenciar nos prazos das atividades e custos do projeto de software Sendo assim o gerente de projetos deve lidar com essa dissocia o entre o fluxo de atividades de
108. aclasses Method Library Method Plugin e Method Configuration 216 Um Method Configuration uma cole o de Method Plugins selecionada e seus subconjuntos de MethodContentPackages e ProcessPackages Esta metaclasse MethodConfiguration utilizada no SPEM 2 0 para definir subconjuntos l gicos dentro de uma biblioteca MethodLibrary A Figura 84 exibe a defini o da metaclasse VariabilityElement no pacote MethodPlugin Essa metaclasse e suas rela es s o considerados como mecanismos de adapta o do metamodelo SPEM 2 0 a Classifier de Constructs bilityType variabilityBasedOnElement Vari E na contributes extends replaces extends replaces vanabilty lType Vanabilty Type vanabilitySpecialElement variabditySpeciaflement type variabiyBasedOnElement typeO varabity can only be defined between ContentElements of the same suppressedMethodContentElement Figura 84 Metaclasse Variability definida no pacote MethodPlugin 217 AP NDICE B PROTOCOLO DA REVIS O SISTEM TICA Este ap ndice cont m a descri o do protocolo da revis o sistem tica desta pesquisa B 1 QUESTAO FOCO O objetivo geral desta revis o encontrar pesquisas interessadas em propor solu es relacionadas com a reconfigura o din mica das redes de planejamento de projetos de software considerando o planejamento e o replanejamento de suas atividades tendo em vista a integra o
109. ada atividade pode pertencer a um ou mais baselines Em cada gera o da baseline uma atividade deve manter os relacionamentos com os pap is e produtos de trabalho Assim objetivando se manter estes relacionamentos das atividades com outras entidades do modelo durante a gera o de baselines decidiu se assumir que a classe Activity conter uma agrega o de uma ou mais inst ncias da classe ActivityDetail Dessa forma foi adicionado ao modelo a classe ActivityDetail objetivando se manter estes relacionamentos das atividades com outras entidades do modelo durante a gera o de baselines Assim a classe ActivityDetail pacote Common foi definida como respons vel por manter estes relacionamentos enquanto que a classe Activity foi definida como sendo uma agrega o de uma ou mais classes ActivityDetail Dessa forma enquanto que o relacionamento denominado Baselines permite que uma atividade perten a a uma ou mais baselines o relacionamento TrackingActivity diferencia a atividade atual daquelas pertencentes as baselines Tambem foi adicionado ao pacote Common a classe RealActivity representa uma atividade que tem tempo de execu o e a classe Milestone uma atividade que n o tem tempo de dura o Tamb m uma atividade pode possuir um 56 tempo de dura o definido e ser atribu da a um papel classe RealActivity ou pode n o ter um tempo de dura o classe Milestone Os stakeholders podem desempenhar diversos pap is c
110. ada para reagir a eventos em tempo real a fim de definir uma programa o robusta A utilidade mede a varia o da programa o ap s uma revis o do cronograma Ela expressa pela diferen a entre a programa o das atividades ap s reagir aos acontecimentos em tempo real e previs o da programa o das atividades desenvolvida antes de levar em conta o acontecimento destes eventos 72 4 1 1 3 Programa o Pro Ativa Robusta As abordagens de programa o pr ativa robusta concentram se na constru o de cronogramas preditivos que satisfa am os requisitos de desempenho previs vel em um ambiente din mico MEH99 VIEO3 A principal dificuldade desta abordagem consiste na determina o das medidas de previsibilidade Mehta e Uzsoy MEH99 prop s um modelo de programa o previs vel com o objetivo de minimizar o atraso m ximo O efeito da perturba o na programa o medido pelo desvio do tempo de conclus o da tarefa realizada em compara o ao tempo de conclus o planejado O desvio reduzido pela inser o um tempo adicional na programa o prevista com o objetivo de alcan ar alta previsibilidade Extensivos experimentos computacionais mostraram que a programa o previs vel proporciona uma melhoria significativa na previsibilidade em consequ ncia de pouca degrada o do atraso m ximo do projeto O Donovan et ai ODO99 ampliou a abordagem de escalonamento previs vel de Mehta e Uzsoy onde a medida de desempen
111. adas ele procura apenas por aquelas que possuem alguma marca o em suas pr condi es O algoritmo de simula o das redes pode ser descrito como a sequ ncia de passos a seguir analisar as transi es com a marca o atual habilitar aquelas que devem ser habilitadas e desabilitar as demais se n o houver transi es habilitadas o processo de simula o finalizado identificar qual is transi o es deve m ser disparada s OF ee 1 IN disparar a transi o escolhida fazendo as mudan as das marca es dos lugares ao enquanto houver transi es dispar veis no tempo atual voltar ao passo 4 avan a o tempo para o menor tempo programado para que uma transi o se torne habilitada para ser disparada analisa as transi es sob a marca o atual as transi es habilitadas s o programadas para se tornarem dispar veis nos seus tempos correspondentes 10 sen o houver transi es dispar veis deve se encerrar a simula o 11 caso contr rio volta para o passo 2 147 O simulador implementado analisa de redes de Petri Temporizadas de modo que foi adotado um metodo de avan o do tempo direcionado a eventos Para ilustrar esta funcionalidade considere que em certo momento o simulador esteja analisando uma rede com tr s transi es habilitadas ou seja existem tr s lugares com tempo de execu o associado Como o modelo considera que o tempo de execu o est associado a um lugar este con
112. adas em paralelo Embora projetos passem por uma fase de planejamento e nessa fase tenha se conhecimento de objetivos a serem atingidos PMI08 nem sempre poss vel prever o que ir ocorrer durante a fase de desenvolvimento De acordo com S derholm SODOS para que os projetos sejam desenvolvidos com sucesso deve ser poss vel gerenciar eventos n o previstos em paralelo com o plano inicial Uma vez que projetos de desenvolvimento de software geralmente s o desenvolvidos em um ambiente com multiprojetos a ocorr ncia de um evento pode impactar diversos projetos simultaneamente A seguir s o apresentados os eventos identificados que demandam a reconfigura o din mica dos projetos de software 4 2 2 Eventos que Demandam Reconfigura o Din mica dos Projetos de Software medida que um projeto avan a no tempo determinadas mudan as no ambiente ocorrem e muitas delas podem afetar o planejamento atual do projeto YU4 SODO8 Exemplos frequentes s o o atraso de uma tarefa em andamento mudan as de prioridades e a modifica o do grupo de pessoas que formam a equipe MCC96 KERO6 LEAO4 Como forma de unificar a nomenclatura nesta tese tais acontecimentos ser o chamados de eventos No caso espec fico de software devido a diversidade de m todos e tecnologias existentes os quais requerem recursos com conhecimento especializado para o desenvolvimento das tarefas os eventos podem causar impactos significativos sobre a aloca
113. adas por essa altera o deve ser reconfigurado Tabela 3 Eventos relacionados s atividades dos projetos ID Eventos Principais Refer ncias EA1 Atraso na execu o de uma atividade do projeto SCHO1 PMI08 EA2 Adiantamento na execu o de uma atividade do LEAO4 projeto EAS Altera o de uma atividade em prazo recursos LEAQ4 PMI08 papeis e ou compet ncias necess rias EA4 Remo o de uma atividade de um projeto MCC96 LEA04 EAS Acr scimo de uma atividade a um projeto MCC96 LEA04 ATabela 4 apresenta os eventos que est o relacionados as vari veis globais dos projetos ou seja que n o s o espec ficos para uma atividade ou para um recurso 85 Tabela 4 Eventos relacionados a caracteristicas globais dos projetos ID Eventos Principais Refer ncias EP1 Mudan as no escopo do produto diminui o SODOS VEROS aumento ou altera o t cnica EP2 Altera o no custo limite do projeto SOD08 EP3 Altera o de milestones do projeto datas PMI08 intermediarias e ou entrega final EP4 Inclus o de um novo projeto no portf lio atual LYC04 EVEOO EP5 Cancelamento de um projeto do portf lio atual LEAO4 EP6 Altera o de prioridade importancia de um BENO 7 ENGO3 projeto quando comparado a outros em andamento Observa se que alguns dos eventos est o diretamente relacionados entre si Para exemplificar quando um projeto tem o seu escopo alterado evento EP1 tipicamen
114. ado SPIM igual ao esfor o de fazer o planejamento de atividades de acordo com o modelo tradicional O esfor o ser medido pelo tempo gasto em minutos com o planejamento das atividades para projetos de desenvolvimento de software em cada abordagem isto a diferen a entre o tempo de in cio e o tempo final de cada abordagem onde e Atspim representa a varia o do tempo gasto em minutos para o planejamento das atividades do projeto usando o modelo SPIM 154 e Attrag representa a varia o do tempo gasto em minutos para o planejamento das atividades do projeto usando o modelo tradicional A f rmula para o c lculo esfor o a seguinte Ho Atspim Attraa Como hip tese alternativa H1 o esfor o envolvido com o planejamento das atividades do projeto usando o modelo SPIM n o igual ao esfor o envolvido na utiliza o do modelo tradicional Isto H1 Atspim a Attrad A segunda hip tese desta pesquisa est relacionada com a precis o dos gestores em planejar as atividades e recursos de projetos de software Ent o a segunda hip tese nula Ho a seguinte a precis o no planeamento do cronograma de projetos de software em rela o atribui o de prazos e recursos considerando a integra o dos projetos com os fluxos organizacionais atrav s do modelo integrado SPIM igual precis o em realizar o planeamento no modelo tradicional A precis o ser avaliada pela rela o de pontua o dos participante
115. ais indica es de trabalhos futuros encontram se no pr ximo Cap tulo 186 8 CONSIDERACOES FINAIS Esta tese de doutorado apresentou um modelo computacional para a reconfigura o din mica de projetos de software considerando a integra o das atividades dos projetos com os fluxos organizacionais Inicialmente realizou se uma an lise do estado da arte das solu es que atacam os problemas relacionados a reconfigura o dos projetos e se prop s uma vez identificadas as atuais lacunas um modelo capaz de suportar a integra o de projetos de software com atividades pertencentes aos fluxos organizacionais Modelos intermedi rios oriundos da revis o da literatura formaram a base conceitual sobre a qual o modelo final foi constru do As caracter sticas do ambiente integrado desenvolvido para o planejamento de projetos de software chamado SPIT tamb m foram descritas neste documento Conforme salientado anteriormente os projetos de software envolvem incertezas e est o sujeitos a frequentes ajustes conforme as atividades sofrem altera es em resposta a muitos eventos internos e externos ao projeto Al m disso as empresas costumam possuir um conjunto de atividades fluxos organizacionais que podem ser compartilhados entre dois ou mais projetos simult neos Alguns exemplos s o o fluxo de trabalho para a requisi o de viagens de trabalho dos empregados ou o fluxo para a aquisi o de hardware e software necess rios para
116. alcan ar este objetivo foi adotadaa metodologia de revis o sistem tica A revis o sistem tica uma pr tica de pesquisa utilizada muitas vezes na rea m dica que foi adaptada para a engenharia de software BIO05 KITO4 Este processo ajuda a estabelecer um rigor cient fico necess rio para definir o estado da arte e para produzir resultados mais confi veis Os resultados deste trabalho mostram que existe uma diversidade de t cnicas e estrat gias para a reconfigura o din mica de projetos de software No entanto os resultados obtidos revelaram que nenhuma pesquisa considera a integra o das atividades dos projetos de software com as atividades que fazem parte de fluxo de trabalho comum da organiza o durante a reconfigura o dos projetos em tempo real Neste sentido esta pesquisa prop e um modelo computacional chamado deSoftware Planning Integrated Model SPIM para fornecer o suporte necess rio para a reconfigura o din mica de projetos de software em 18 ambientes multiprojetos considerando a integra o destes projetos com os fluxos organizacionais A fim de ilustrar a operacionalidade dos conceitos propostos pelo modelo SPIM e o seu conjunto de regras foi desenvolvido um software chamado Software Project Integrated Tool SPIT O SPIT atua como um add in para uma ferramenta comercial de gerenciamento de projetos muito conhecida e utilizada nas empresas de software As se es seguintes apresentam um detalhame
117. algum tipo de sele o aleat ria deve ser usado por exemplo jogando um dado retirando cartas de uma caixa etc Neste caso o experimentador colocou trinta e seis cartas metade preta e metade vermelha em uma caixa as cartas vermelhas corresponderiam a utiliza o do m todo tradicional de planeamento de projeto e as pretas ao uso do m todo SPIM O experimentador embaralhou as cartas e permitiu que cada sujeito retirasse uma carta para cada unidade experimental projeto de desenvolvimento de software Tamb m foi utilizado o princ pio de equil brio balancing principle de modo que cada proposta de planeamento de projetos de software foi realizada pelo mesmo n mero de participantes dezoito participantes para cada proposta o projetar experimentos de engenharia de software algumas considera es espec ficas devem ser levadas em considera o especialmente aquelas relativas s compet ncias habilidades tamb m s circunst ncias psicol gicas e outras caracter sticas dos indiv duos que participam do experimento O design de um fator one factor possui uma limita o uma vez que considera o fato de que o mesmo sujeito aplica o mesmo 157 metodo mais de uma vez o que pode levar os participantes a se tornarem mais familiarizados com o m todo o sujeito pode aprender a aplicar o m todo ao longo do tempo Outra considera o para projetos experimentais chamada de efeito t dio boredom effect que ocorre quando os indi
118. ama X Diagrama Entidade Relacionamento do Banco de Dados Figura 61 Interface de cadastro de produtos de trabalho do BackOffice 176 Uma vez cadastrado no banco de dados do SPIT este tipo de informa o deve ser exportado para um arquivo que possa ser utilizado pelo Microsoft Project O modulo de BackOffice permite ao gestor selecionar quais informa es ser o exportadas para campos personalizados oferecidos por esta ferramenta comercial A Figura 62 mostra o funcionamento da exporta o dos pap is registrados na base de dados do SPIT para os campos personalizados do Microsoft Project E Manuten o do Projeto Integrado o Register Export to MS Project p Pap is Produtos jun Processos Gerenciais o Guias Papel E id de Atividades Integrador Projetista de Banco de Dados Testador Papel k Analista de Sistemas k Desenvolvedor Tapori frum ME Domine Gerente de Projetos Export to MS Project Register Figura 62 Exporta o de Pap is para o Microsoft Project Atrav s da informa o contida nestes campos personalizados ilustrado na Figura 63 o gerente de projetos pode iniciar o registro dos itens do plano do projeto tais como tarefas recursos e outras configura es Durante o registro das atividades do projeto o gestor deve informar atrav s dos campos personalizados as seguintes informa es necess rias para o modelo SPIM identificador da atividade tipo de atividade produtiva gere
119. amente o projeto resultando por exemplo no aumento dos custos em atrasos nos prazos do projeto O modelo SPIM foi concebido considerando a necessidade do gerente de projetos obter acesso as informa es pertencentes aos outros departamentos da organiza o durante o planejamento de projetos de software O evento compreende uma apresenta o do modelo SPIM e a realiza o de uma atividade pr tica experimento acad mico onde os participantes ter o a LIMPAR LOGIN oportunidade de realizar um exerc cio baseado em uma situa o tipica para o problema de gest o de projetos envolvendo os fluxos empresariais unindo teoria e pr tica Tal exerc cio se caracteriza como um estudo experimental cujos resultados permitir o aos pesquisadores a realiza o de uma an lise sobre as dificuldades impostas aos gerentes de projetos na resolu o do problema com e sem o uso do modelo SPIM Os resultados ser o encaminhados aos participantes do evento permitindo lhes uma avalia o sobre os resultados do experimento a partir da experi ncia realizada pelo grupo O evento gratuito e as vagas s o limitadas Est o convidados alunos e professores de gradua o e p s gradua o que tenham interesse na area de gerenciamento de projetos As informa es fornecidas ser o tratadas de forma absolutamente confidencial Ao participar al m dos resultados do experimento voc tera acesso aos materiais publicados por este grupo de pesquisadores Os resulta
120. and Resources in Software Development Methodologies Journal of Object Technology 2005 GONZALEZ PEREZ C HENDERSON SELLERS B Modelling software Development Methodologies A Conceptual Foundation The Journal of Systems and Software 2007 pp 1778 1796 PETERSON J L Petri net theory and the modeling of systems New Jersey USA Prentice Hall 1981 pp 88 95 PFLEEGER S L ATLEE J Software Engineering Theory and Practice Prentice Hall 4 edition 2009 PLEKHANOVA V On Project Management Scheduling where Human Resource is a Critical Variable In 6 European Workshop on Software Process Technology 1998 pp 116 121 PROJECT MANAGEMENT INSTITUTE PMBOK A Guide to the Project Management Body of Knowledge Newtown Square PA Project Management Institute 4 edition 2008 PRADO D Pert CPM Nova Lima INDG 2004 173p PRESSMAN R Software engineering a practitioner s approach McGraw Hill 7 edition 2009 RATIONAL SOFTWARE CORPORATION Rational Unified Process Best Practices for Software Development Teams Capturado em http www rational com products rup whitepapers jsp Novembro 2009 REA L M PARKER R Designing and Conducting Survey Research A Comprehensive Guide Jossey Bass 33 edition 2005 REDDY J P KUMANAN S CHETTY O V K Application of Petri nets and a genetic algorithm to multimode multi resource constrained project sch
121. anejamento do cronograma de projetos de software com rela o atribui o de prazos e recursos pensando na integra o com os fluxos organizacionais atrav s do modelo integrado SPIM igual precis o para realizar o planejamento segundo o modelo tradicional M tricas A m trica associada Quest o 1 corresponde ao esfor o medido pela rela o do tempo gasto em minutos por cada participante durante a realiza o do planejamento das atividades do projeto de software em cada abordagem A m trica relacionada Quest o 2 corresponde precis o com rela o atribui o de prazos e recursos nas atividades do cronograma do projeto utilizando cada uma das abordagens evitando desta forma a ocorr ncia de determinados tipos de riscos no projeto Por precis o foi definido em nosso estudo como sendo a raz o entre a pontua o feita pelos participantes e a pontua o total poss vel de acordo com um gabarito 232 Caracteriza o Formal das Hip teses do Estudo Nesta se o o objetivo associar as hip teses informais feitas anteriormente com as m tricas levantadas formulando as hip teses que guiar o a execu o do experimento As hip teses informais em l ngua natural devem ser traduzidas em indicadores objetivos num ricos para verifica o estat stica da sua validade Devido a natureza dos testes estat sticos formulamos nossas hip teses em fun o de uma hip tese nula que aquela que indica que
122. arantidos Conformese pode observar os dois primeiros passos realizam a busca por conflitos Os passos seguintes constituem a resolu o destes conflitos 6 4 Limita es do Modelo Especificamente sobre o modelo desenvolvido destacam se as seguintes limita es 148 a proposta do modelo integrado SPIM se limita a projetos de desenvolvimento de software com metodologias baseadas no SPEM 9 as rela es de preced ncia entre as tarefas somente podem ser expressas da forma fim in cio Esta decis o teve como objetivo simplificar o algoritmo CPM implementado o modelo SPIM considera a integra o com os conceitos propostos pelo modelo de reconfigura o din mica de projetos de software proposto por Callegari CAL10 o modelo SPIM considera a adequa o dos conceitos propostos pela integra o do modelo SPIM considerando o uso da arquitetura multiagentes proposta por Schl sser SCH10 Os fluxos organizacionais implementados na ferramenta SPIT foram desenvolvidos atrav s do Windows Workflow Foundation Integra es com outros mecanismos de workflow n o est o previstas A ferramenta SPIT foi desenvolvida considerando sua a integragao com o software de gestao Microsoft Project 2013 Nao foram consideradas integra es com outros softwares 6 5 Considera es Finaisdo Cap tulo Este Cap tulo apresentou o modelo computacional para a reconfigura o din mica de projetos de software considerando a i
123. arca o em que em particular os lugares de entrada de t est o marcados A marca o Mim correspondente ao estado E 1 ser atingida ap s o disparo da transi o t Na Figura 17 s o mostrados os efeitos para v rias situa es onde ocorrem disparos e gt 6 gt e o PA oe aie Rm i 3 S 3 0 a antes do disparo b depois do disparo Figura 17 Efeitos dos disparos de transi es O desaparecimento das fichas nos lugares de entrada de t indica que as condi es ou predicados associados queles lugares n o s o mais verdadeiros e o surgimento de 100 fichas nos lugares de saida indica que os predicados associados a estes lugares sao verdadeiros O comportamento din mico do sistema assim traduzido pelo comportamento da rede de Petri 5 2 1 Defini es Formais Ap s a defini o informal de uma rede de Petri apresenta se nesta se o a rede de Petri enquanto um modelo formal que pode ser representada atrav s de tr s vis es MUR39 e um grafo com dois tipos de n s e um comportamento din mico e um conjunto de matrizes de inteiros positivos ou nulos cujo comportamento din mico descrito por um sistema linear e um sistema de regras baseado numa representa o do conhecimento sob a forma condi o a o As vis es gr fica e matricial diferenciam se apenas pela forma de representa o Ambas permitem verificar se as transi es s o paralelas ou em conflit
124. as multiagentes O estudo comparativo apresentou indicativos de que n o h uma solu o tima O pr ximo Cap tulo apresenta o estudo realizado nesta tese sobre a utiliza o de redes de Petri na gest o de projetos 95 5 APLICA O DAS REDES DE PETRI NA GEST O DE PROJETOS 5 1 Vocabul rio e Conceitos Associados A rede de Petri RdP uma ferramenta gr fica capaz de modelar analisar controlar validar e implementar sistemas em especial aqueles que possam ser interpretados como sistemas a eventos discretos Sistema discreto um sistema no qual as mudan as ocorrem em instantes precisos Os sistemas a eventos discretos possuem estados bem definidos e a mudan a de estado acontece quando da ocorr ncia de um evento MUR89 CAR97 Um evento do ponto de vista de sistema de software uma ocorr ncia de origem interna ou externa que altera as caracter sticas do fluxo do projeto provocando mudan as de estado do sistema Na se o seguinte apresentada a caracteriza o de tais sistemas e os conceitos b sicos utilizados na sua modelagem 5 1 1 Sistemas Discretos Um sistema discreto um sistema onde as mudan as de estado ocorrem em instantes bem definidos Costuma se situar os sistemas discretos em oposi o aos sistemas cont nuos Esta classifica o depende do ponto de vista em que se coloca o observador e depende do grau de abstra o desejado Pode se de fato encontrar diversas defini es de tais sistema
125. asa ANETES E TEE sa ESA UC aos aca Un couse 190 6 0 INDICA O DE TRABALHOS FUTUROS sranane od a bia 190 REFERENCIAS passa A TE OnE Ra en Da AE EEUU TE SEATA GA dp DOS An AS RS UOT 192 AP NDICE A DESCRI O DAS PRINCIPAIS CLASSES DO SPEM 2 0 c csscscsssssssssssessssssesessesesssseseees 205 AP NDICE B PROTOCOLO DA REVIS O SISTEMATICA ccccccscscsososssescesesesesesscscsssssasacecesecececececscsaces 217 AP NDICE C INTERFACES DESENVOLVIDAS PARA O ESTUDO EXPERIMENTAL SOBRE O MODELO SPIM ainsi arcadas eina des ass pur as datado CEL pb pa dada La Dad edad datando pb aa da 222 AP NDICE D METODOLOGIA DE DESENVOLVIMENTO DO PROTOCOLO DE AVALIA O DO SPIM 15 1 INTRODU O O aumento do volume e da complexidade dos projetos que um gerente deve lidar ao mesmo tempo contribuem para os crescentes desafios relacionados ao desenvolvimento de projetos KEROO PREO9 Particularmente em projetos de software aspectos como as incertezas na especifica o dos requisitos e sua instabilidade ao longo do desenvolvimento do projeto no uso de tecnologia aplicada e da pr pria natureza humana potencializam essas dificuldades O desenvolvimento de software requer o planejamento e a execu o das atividades definidas de acordo com o escopo do projeto no qual necess rio lidar tanto com quest es t cnicas quanto gerenciais Em geral as empresas est o organizadas de forma a gerenciar m ltiplos projetos simultaneamente
126. asses Method Library Method Plugin e Machos Con ourat lonas lol Sage do dual sisal ua a nai oia 215 Figura 84 Metaclasse Variability definida no pacote MethodPlugin 216 Figura 85 Portal sobre o estudo experimental do SPIM cc ccecccecceeeceeeeeeeaeeeeeeeeees 222 Figura 86 Tela sobre o convite para a palestra do SPIM cc ccccecceccseeceeeeeeeeeeeeeneees 224 Figura 87 Tela sobre de apresenta o da equipe de pesquisadores 220 Figura 88 Tela sobre a inscri o para a palestra erre 225 Figura 89 Figura 90 Figura 91 Figura 92 Figura 93 Figura 94 Figura 95 Figura 96 Figura 97 Figura 98 Figura 99 Formul rio de inscri o para a pilastra serenas 226 Tela sobre as publica es do grupo de PESQUISA cceceecseeeeeeeeseeeeeeeeees 221 Tela para contato com os pesquisadores ccceccececeeeseeeeteeeeeeeceeteeeeeaeseeees 221 Tela de acesso restrito do porital eee 228 Tela de apresenta o do estudo experimental cccecseceeceeeeeseeeeeneeeenes 228 Vari veis independentes e dependentes do estudo experimental 233 Projeto para O cenario T ssveisietsveraietaneiaietazebavebiverdietabeiabetdzelavobdiataboldebaielacebaies 240 Projeto para 0 CENA 2 enere nei beeches ceadcen N dal nais da 241 Prost paad o CON an S qo PR RR EDS RR ee 243 Projeto para o cen rio 4 eee e
127. atribui o de recursos uma grade de fluxos de trabalho de produ o em ingl s manufacturing grid workflow Em HELO3 apresentado um sistema de gest o que foi desenvolvido dar apoio a processos de engenharia de projeto Ainda no mbito da revis o sistem tica os dois nicos estudos que mostram a integra o com os fluxos organizacionais s o CALO7 JOSO5 O primeiro apresenta um modelo de integra o do PMBOK com o RUP conceituando as atividades gerenciais e produtivas e as rela es de interdepend ncia entre estes dois tipos de atividades O segundo somente apresenta um exemplo de contrata o tempor ria de recursos Junto ideia de integrar as atividades de um projeto de software com os fluxos de atividades organizacionais o artigo apresentado por Lee e Miller LEE04 trabalha com o conceito de pol tica policy ou pol ticas Este trabalho apresenta algumas estrat gias que o gestor pode considerar para gerenciar seu projeto por exemplo alocando mais recursos para uma atividade criando marcos internos entre outros Ele admite projetos simult neos 93 mas estes podem ter caracter sticas diferentes por exemplo o primeiro projeto pode ser executado com base em um processo iterativo enquanto que o segundo pode ser baseado no modelo em cascata Atrav s desta an lise observa se que as obras pesquisadas n o fornecem uma solu o que permita o planejamento de projetos de software considerando as intera es
128. canismo package merge da UML Tais pacotes s o Core cont m as metaclasses e abstra es para a constru o da base do metamodelo Process Structure define os conceitos base para modelagem de processos representando sua estrutura est tica Process Behaviour pacote que permite uma extens o do metamodelo do SPEM 2 0 para que a execu o de um processo possa ser acompanhada Managed Content adiciona conceitos para documenta o e descri o textual de um processo Method Content permite que os usu rios do SPEM 2 0 criem uma biblioteca com conhecimento reutiliz vel e independente de processos para uso posterior Process with Methods define novos conceitos e altera outros conceitos j existentes nos pacotes anteriores para integrar processos definidos pelo pacote Process Structure com seus conte dos definidos pelo pacote Method Content Method Plugin define os conceitos necess rios para criar gerenciar e manter bibliotecas e processos de software O funcionamento e descri o das principais classes dos pacotes do SPEM 2 0 entretanto s o apresentados no Ap ndice A Merge um relacionamento entre dois pacotes onde o conte do do pacote de destino combinado com o conte do do pacote de origem atrav s de especializa es e redefini es quando aplic veis OMG11 43 ee MethodPligin 222 222 pena en neen ener ee rens i lt lt merge gt gt lt emerges gt lt
129. ceccseccceeecaeeeseeeceueeseeeseeeeeeeseeeseeesees 179 Figura 67 Comportamento do componente ParserMSProject ccccccccecceeeceeeeeeeseees 179 Figura 68 Rede de Petri gerada para o Cen rio 1 erraram 180 Figura 69 Execu o do fluxo organizacional no Cen rio 2 em 181 Figura 70 Rede de Petri para o Cen rio 2 atraso no fluxo organizacional 182 Figura 71 Cen rio 3 aquisi o de servidor WED cccceccseeceeeeeceeteeeeeeeeeeeeeseeeeeeaees 183 Figura 72 Execu o do fluxo organizacional no Cen rio 3 em 183 Figura 73 Metaclasses ExtensibleElement e Kind definidas no pacote Core 205 Figura 74 Metaclasses do pacote Core eee eee ere era era eee eec arena 206 Figura 75 Taxonomida das metaclasses do pacote ProcessStructure 207 Figura 76 Metaclasses e associa es do pacote ProcessStructure 208 Figura 77 Metaclasses e associa es do pacote ManagedContent ooccecsecsecseceeeeeeeeees 210 Figura 78 Taxonomida das metaclasses do pacote MethodContent 211 Figura 79 Metaclasses e associa es do pacote MethodContent 211 Figura 80 Taxonomida das metaclasses do pacote Process with Methods 213 Figura 81 Metaclasses e associa es do pacote Process withMethods 214 Figura 82 Taxonomida das metaclasses do pacote MethodPlugin 215 Figura 83 Associa es entre as metacl
130. cial e assim por diante Mais do que apenas um conjunto de atividades um projeto definido como sendo um esfor o tempor rio empreendido para criar um produto nico servi o ou resultado Program 1 0 a 1 1 scopeStatement lar ase q H indirectCosts name lifecycle name description purpose objectives 1 o Activity 1 IS demo fo Technigue De 1 milestone oe ActivityDependency duratian Db Us StakeholderRoleActivity timeFrame 4 directCost definition 1 il i ProcessGroup ManagementProcess a EO responsible as AN assignment Organizational Chart Pe 1 KnowledgeArea l i scabstract gt gt inputs k Stakeholder 7 Y o ActivityResourceWork CoreKnowledgeArea FacilitatingknowledgeArea Do workLoad ESSA A timeFrame Deliverable 1 _ 0 lt lt gbstract gt OtherStakeholder RelevantStakeholder Le eee A Figura 2 Metamodelo de ger ncia de projetos baseado no PMBOK Guide CALO7 DeliverableType ET dl responsible Apesar do conceito de pap is classe Role os modelos de processos de desenvolvimento de software geralmente n o abordam explicitamente as no es de recursos humanos e de outros tipos de entidades tal como as partes interessadas em conjunto com outros tipos de recursos equipamentos materiais e instala es de trabalho por exemplo Al m disso es
131. contribui es para a atividade A atrav s da rela o localContribution e localReplacement este permite que substitui es locais sejam feitas em atividades que est o sendo herdadas atrav s do mecanismo de extens o Uma atividade A poderia por exemplo herdar toda estrutura da atividade B pelo mecanismo de extension Contudo poderia ser necess rio fazer substitui es locais para partes da atividade A atrav s da rela o localReplacement A rela o supressedBreakdownElement definida entre as metaclasses Activity e BreakdownElement Essa rela o permite suprimir elementos de uma atividade ap s o mecanismo de extens o extension ter sido realizado Ap s uma atividade A por exemplo ter herdado todo conte do da atividade B fazendo ou n o 65 contribui es e ou substitui es locais poss vel ainda que elementos sejam suprimidos da atividade A PMBOK Resources AvallableTime Organization FrocessGroup stabstract ResourceAvailability startDlate Date _ name String Resource 4 name andate Date percent4Available Double ssabstracl gt PhysicalResource Material Stakeholder description wigqueF acts trent F name siring ai ao qa Fin op description String nen unitCast i Equipment ES Facility KnowledgeA reaa Es EA arganmahoninita String CoreKnowledgeArea FacilitatingknowledgeAren hay stakebolder External
132. cordo com a tabela de recursos acima procure associar a cada atividade um recurso apropriado 1 Deve se procurar respeitar que o papel do stakeholder envolvido deve ser compat vel com o tipo de atividade gerencial ou produtiva 2 Caso voc esteja usando o modelo SPIM associe cada atividade do cronograma como sendo produtiva ou gerencial As atividades consideradas gerenciais para este projeto s o as seguintes Reuni o de Acompanhamento Gerencial Elaborar documento de Avalia o Revis o Organizar e Conduzir a Reuni o de Kick Off Elaborar e Revisar Caso de Desenvolvimento Revis o de estimativas Estimar Custos e Recursos Refinar Planejamento do Projeto Conduzir Reuni o de Avalia o Revis o Encerrar Projeto Todas as outras atividades s o consideradas produtivas Verifique se todas as atividades possuem um recurso associado Caso voc esteja usando o modelo SPIM ative os filtros listados abaixo e fa a a valida o do projeto Tipo de papel gerencial ou produtivo Tipo de atividade gerencial ou produtiva Salve o arquivo com o nome Cenariol SeuNome Respostas l Salvar Arquivo m Veja abaixo uma parte do projeto a ser avaliado no cen rio 1 240 E Nome da tarefa Dura o 1 _ Projeto Cen rio 1 35 25 dias 2 Inicia o 12 dias 3 Monitoramento e Controle 1 dia 4 fd Reuni o de Acompanhamento Gerencial 1 dia D Plano de Projeto 11 dias 5 Elaborar documento de Ava
133. da empresa Dessa forma foram apresentados os resultados de uma revis o sistem tica sobre reconfigura o din mica de projetos de software Nesta etapa da pesquisa foi examinada a capacidade destes trabalhos relacionados em resolver 10 quest es relacionadas com o tema desta pesquisa Devido ao pequeno numero de documentos retornados pelos motores de busca nota se que poss vel realizar alguns coment rios sobre a reconfigura o din mica de projetos considerando a integra o do gerenciamento de projetos com fluxos organizacionais Mesmo os trabalhos mais recentes n o apresentaram uma solu o que atenda todos os problemas ao mesmo tempo Uma raz o pode ser que este seja um assunto que n o tenha sido profundamente abordado por outros pesquisadores Analisando a literatura atual n o foi poss vel identificar estudos que abordam intimamente este assunto nem solu es atuais que forne am algum tipo de integra o entre projetos de software com os fluxos organizacionais A identifica o da interdepend ncia dos fluxos de trabalho da empresa e do projeto de software durante o planejamento do projeto n o uma tarefa f cil De acordo com os resultados nesta revis o sistem tica podemos dizer que o problema apresentado na quest o foco vide item 4 3 1 Planejamento da Revis o Sistem tica ainda n o foi totalmente respondido pelas abordagens atuais As informa esobtidas nesta revis o da literatura entretanto foram
134. das Descri o do Cen rio 5 O pessoal mais qualificado est doente e n o dispon vel nos momentos cr ticos Orienta es 1 Abra o arquivo Cenario5 2 Durante a execu o da atividade Teste da Arquitetura no dia 05 10 2011 voc percebe que os componentes de software adquiridos de uma empresa terceirizada e que seriam reutilizados neste projeto cont m defeitos que limitam sua funcionalidade Entretanto esta atividade necess ria para as atividades abaixo de Especifica o Requisitos Release 1 0 Desta forma voc deve entrar em contato com o setor administrativo informando a necessidade de entrar em contato com a empresa fornecedora do produto O contato com as empresas fornecedoras uma atividade pertencente ao fluxo organizacional do setor administrativo cujo tempo de dura o de 10 dez dias 5 Com base nesta situa o sem alterar a ordem das atividades no projeto defina qual o prazo estimado para que a atividade Especifica o Requisitos Release 1 0 seja iniciada Digite sua resposta 4 Caso voc esteja usando o modelo SPIM Atribua uma rela o de depend ncia entre as atividades do projeto de software e as atividades pertencentes ao fluxo organizacional Clique na atividade que depende do resultado da realiza o do fluxo organizacional para que seja iniciada Ap s selecione a aba Campos Personalizados No campo personalizado chamado Fluxos Organizacionais informe o nome do f
135. das na Figura 82 que exibe a taxonomia de metaclasses para esse pacote Observa se ainda que novas metaclasses s o inclu das nesse metamodelo e tamb m que h novas defini es de especializa o As principais novas metaclasses s o as metaclasses MethodConfiguration MethodPlugin MethodLibrary e VariabilityElement e est o envolvidas na defini o de bibliotecas e tamb m com o mecanismo de adapta o proposto nesse pacote 215 _ E a ide Constructs Figura 82 Taxonomida das metaclasses do pacote MethodPlugin As rela es entre as metaclasses MethodConfiguration MethodPlugin e MethodLibrary podem ser vistas no diagrama de classes exibido na Figura 83 Nessa Figura observa se que uma biblioteca representada pela metaclasse MethodLibrary uma composi o da metaclasse MethodPlugin e da metaclasse MethodConfiguration Um MethodPlugin reprenta um container f sico para Content definido com metaclasses do pacote Methodcontent e ProcessPackages definido com metaclasses do pacote Process Structure usando ou n o as metaclasses do pacote Method Content Na Figura 19 a metaclasse MethodPlugin uma composi o das metaclasses ProcessPackage e MethodContentPackage as quais respectivamente guardam as metaclasses do pacote Process Structure e do pacote Method Contente predefinedC onfiguration fmethodPluginSelection substractedCategory subCategory Figura 83 Associa es entre as met
136. de 2000 at 2011 per odo em que foi realizado esta revis o sistem tica e que foram escritos em ingl s O mesmo protocolo desta revis o sistem tica foi aplicado novamente em junho de 2012 com o objetivo de captar trabalhos relacionados mais recentes Este per odo foi escolhido a fim de realizar um filtro nos trabalhos recentes na rea antes de se aprofundar nesta pesquisa A justificativa para a escolha do idioma ingl s devido sua universalidade mantendo se a linguagem padr o de confer ncias e revistas internacionais Em seguida v rios trabalhos foram analisados nas reas de ci ncia da computa o engenharia de software gerenciamento de projetos sistemas de informa o sistemas de apoio decis o e gest o de processos de neg cio As fontes 89 foram acessadas exclusivamente na Internet a pesquisa de modo manual nao fol considerada nesta tese Inicialmente para a defini o da palavra de pesquisa search string foram julgadas v rias combina es e varia es das seguintes palavras chave em ingl s project management scheduling businessprocess workflow managerialactivity enterpriseactivity organizationalactivity e productiveactivity Depois de observar o comportamento dos motores de busca estas palavras chave foram combinadas atrav s de filtros e operadores booleanos conforme apresentado na Tabela 5 Tabela 5 Strings de pesquisa utilizados ID String de Pe
137. de Dados Produtivo O cen rio representa o Projeto 1 com as seguintes atividades inicia o do projeto INP an lise de requisitos ANR defini o da arquitetura DAR modelagem do banco de dados MBD tr s componentes que s o desenvolvidos em paralelo DEV1 DEV2 e DEV3 integra o dos componentes INT realiza o de testes dos componentes RTC e uma atividade de encerramento do projeto ENP Dessa forma as tarefas receberam nomes curtos para facilitar a sua identifica o A Tabela 1 apresenta as posi es de trabalho das tarefas o nome das tarefas a abrevia o destas tarefas suas respectivas dura es em unidades discretas e tamb m suas depend ncias Conforme nomenclatura adotada pelo modelo SPIM uma atividade de projeto pode ser considerada como sendo gerencial ou produtiva vide Cap tulo 6 Tabela 17 Tarefas do Projeto 1 Pos Tarefa Abrevia o Tipo Dura o Depend ncias 1 Inicia o do Projeto INP Gerencial 2 2 An lise de Requisitos ANR Produtiva 6 1 INP 3 Defini o da Arquitetura DAR Produtiva 2 2 ANR 4 Modelagem do Banco de MBD Produtiva 3 3 ANR Dados o Desenvolvimento do DEV Produtiva 2 4 MDB Componente 1 6 Desenvolvimento do DEV2 Produtiva 4 4 MDB Componente 2 7 Desenvolvimento do DEV3 Produtiva 3 4 MDB Componente 3 171 8 Integra o dos Componentes INT Produtiva 1 5 6 7 DEV1 DEV2 DEV3 9 Realiza o de testes dos RTC Produtiva 2 8 INT componentes 10 Ence
138. de outros elementos do projeto Neste contexto um plano de projeto de software especifica e delimita o escopo do projeto descreve poss veis riscos do projeto define os recursos de hardware e software dispon veis descreve a estrutura anal tica do trabalho e a programa o de projeto LEEO6 Entretanto deve se considerar que o gerente de projetos pode nao possuir todas as informa es relevantes durante o planejamento e ou a execu o de um projeto de software e consequentemente poder o ocorrer intera es com outros departamentos da organiza o essa constata o j foi publicada pelo autor em ROS08a O gerente de projetos por exemplo pode precisar contatar o setor de recursos humanos sobre a necessidade de contrata o de pessoal para um determinado projeto de desenvolvimento de software Percebe se dessa forma que o fluxo de atividades de um projeto de software pode interagir com os demais fluxos de atividades comuns da organiza o denominados aqui como sendo chamados de fluxos organizacionais Conforme ilustrado na Figura 9 ambos os tipos de fluxos de trabalho s o executados em paralelo possuem recursos pr prios e podem influenciar nos prazos das atividades e custos do projeto de software Devido a esta separa o entre o fluxo de trabalho de um projeto de software e dos fluxos organizacionais pode haver uma rela o de depend ncia entre as atividades pertencentes a estes dois tipos de fluxos distintos Por exempl
139. de projetos informa ao setor de recursos humanos sobre a necessidade de contrata o de um administrador de banco de dados Neste caso constata se a exist ncia de uma rela o de depend ncia entre as atividades do projeto de software tais como a modelagem do banco de dados com as atividades pertencentes ao fluxo de trabalho do setor de recursos humanos referentes contrata o do profissional requerido para executar a atividade de produ o Assim percebe se que o fluxo de atividades de um projeto de software pode interagir com os demais fluxos de atividades da organiza o fluxos organizacionais Avalia o do SPIM 1 Com base nas informa es vistas nesta palestra marque abaixo como voc percebe os benef cios em fazer o planejamento integrado de atividades gerenciais e produtivas para projetos de desenvolvimento de software de acordo com a classifica o apresentada abaixo 1 Nenhum 3 M dio 4 Alto 2 Pouco 5 Muito alto 247 Restri es Verificadas pelo Modelo Integrado SPIM OET projeto 1 2 Identifica o das depend ncias entre as atividades gerenciais de ato apoio e de produ o 1 3 Identifica o e mensura o dos custos indiretos do projeto aaa advindos das atividades gerenciais de apoio ee nt matem pertencentes aos outros departamentos da organiza o 1 5 Capacidade de minimizar distor es no planejamento de projetos tais como o aumento dos custos e atra
140. de ser reduzido usando redes de Petri de alto n vel tais como as redes de Petri coloridas CPNs ou as redes de Petri orientadas a objetos OPNs 10 A modelagem de atividades fantasmas nos diagramas de rede do CPM PERT costuma sercomplicada No entanto a representa o das rela es de preced ncia usando as redes de Petri torna esta atividade mais f cil de ser realizada 102 5 2 3 Extens es das Redes de Petri As tentativas de utiliza o das redes de Petri em problemas pr ticos reais mostraram duas desvantagens principais Em primeiro lugar n o existe o conceito de dados e os modelos tornam se excessivamente grandes porque toda a manipula o de dados tem que ser representada atrav s da estrutura da rede isto atrav s de lugares e transi es Em segundo lugar n o existe no o de hierarquia e portanto n o poss vel construir um modelo de grande porte atrav s de um conjunto separado de submodelos com interfaces bem definidas Para resolver estes problemas foram propostas as redes de Petri de alto n vel onde se procura incorporar estruturas de dados e decomposi o hier rquica ao modelo original das redes de Petri Entre as redes de Petri de alto n vel encontram se as redes de Petri Coloridas Temporizadas TCPNs 5 2 3 1 Redes de Petri Coloridas Temporizadas TCPNs Em ambiente de m ltiplos projetos o uso redes de Petri b sicas poder gerar um gr fico muito complexo para o problema da progra
141. de seus projetos KEROO Desta forma muitos pesquisadores trabalham na investiga o dos fatores de sucesso dos projetos tais como a defini o de produto qualidade de execu o e t cnicas de ger ncia de projetos PREO9 Observa se entretanto que alguns fatores s o determinantes para o sucesso do projeto tais como metas claramente definidas compet ncia da ger ncia de projetos adequada aloca o de recursos comunica o eficiente planejamento programa o e controle eficientes capacidade de atualiza o de dados e informa es apropria o de t cnicas e tecnologias PREO9 SOMO6 SCHO2 Os projetos de desenvolvimento de software escopo desta pesquisa possuem peculiaridades devido a propria complexidade inerente ao software Dentre essas peculiaridades citadas por Bezerra BEZO7 Plekhanova PLE98 Schwalbe SCHOZ2 Dong et al DONOS e Jurison JUR99 destacam se a volatilidade dos requisitos fato que incide nas constantes altera es nas especifica es do produto a necessidade de pessoas especializadas para o desenvolvimento das tarefas e a intangibilidade o que torna dif cil medir o progresso de projetos de software Complementar a estas peculiaridades observa se que eventos n o previstos podem ocorrer durante a execu o dos projetos provocando a necessidade de reexaminar e atualizar o seu planejamento DEBOY7 SODOS Para lidar com os obst culos da rea de software de forma a alcan ar com suc
142. delos mostraram se deficientes em reas essenciais de conhecimento da ger ncia de projetos particularmente a ger ncia de aquisi o de comunica o e de pessoas 47 A fim de se obter um processo mais detalhado para o gerenciamento de projetos software necess rio aplicar os conhecimentos de gest o de projetos aos processos de desenvolvimento do software Portanto se por um lado o PMBOK pode fornecer uma perspectiva gerencial da solu o a vis o sobre a produ o deve ser obtida a partir de um modelo de processo de desenvolvimento de software Segundo PERO processos de software definidos a partir de um metamodelo geralmente oferecem um alto grau de formalismo e melhor suporte para consist ncia e customiza o uma vez que os conceitos que formam sua base s o explicitamente definidos Pesquisas anteriores apresentaram resultados interessantes mas uma intima integra o da ger ncia de projetos e dos processos de software com resultados pr ticos ainda uma quest o em aberto HENOO HENO1 REHO SCHO2 Consequentemente faz se necess rio mais estudo para uma solu o que permita um melhor n vel de integra o entre os conceitos e modelos para estas duas reas de conhecimento Dessa forma em seguida s o listadas asnecessidades identificadas a partir da literatura examinada nesta pesquisa 1 Acesso as informa es pertencentes aos outros departamentos da organiza o Ao realizar planejamento de um
143. demais tarefas entretanto possuem folga e 169 disp em de maior flexibilidade no seu agendamento fun o do intervalo proporcionado pela folga Segundo Prado PRAO4 importante observar o caminho cr tico pois as tarefas que o comp em devem ser cumpridas no prazo estabelecido de forma que n o haja atrasos no prazo do projeto As unidades de tempo ser o representadas em unidades discretas Na Figura 55pode ser visto um exemplo gr fico do diagrama de rede Petri que ser utilizado para a descri o dos projetos de software e dos fluxos organizacionais Figura 55 Exemplo de um diagrama de rede de Petri Considera se nesta pesquisa a execu o de v rios projetos simultaneamente de modo que durante a descri o dos cen rios assume se que os projetos est o sendo executados de forma paralela e sem depend ncia entre eles 7 2 1 Descri o dos Cen rios A elabora o de cada cen rio foi realizada da seguinte forma ser o apresentadas configura es de projetos e eventos hipot ticos que ocorrer o sobre estes projetos Assim uma CFP Call For Proposal ser gerada para cada evento hipot tico que ocorrer O processo de gera o das CFP entretanto n o abordado nesta pesquisa Ressalta se dessa forma que n o escopo desta pesquisa apresentar o processo de sele o de um recurso para ser atribu do a uma tarefa bem como a aloca o p s evento Estes mecanismos foram explicados nos trabalhos de Callegari
144. der informa explicitamente qual o stakeholder respons vel por um determinado projeto Tamb m define o n vel de interesse e o n vel de influ ncia deste stakeholder no projeto PMBORK Organization pm ns sai Organization _ re Hy 1 ResourceAvailability 6 startDate Resource DEM E ONN 1 EM 1 ManagementProcess e PhysicalResource E desonpbon ra gY umeli ManagerialActivi i fdirectiost defiran aBaselne Baselnelata f scope Siaiement indirectCosts startDate mahale _ duration Figura 11 Metamodelo de integra o PMBOK RUP ROSO8a 54 Conforme salientado anteriormente os conceitos de ger ncia de projetos que existem no RUP foram atribu dos ao pacote gerencial neste caso o PMBOK a fim permitir uma distin o expl cita entre os conceitos produtivos e gerenciais Por exemplo no RUP um papel interage com ambas as tarefas gerenciais e produtivas mas no metamodelo integrado foram definidas anteriormente as classes especializadas ProductiveRole pacote RUP e ManagerialRole pacote PMBOK Assim a classe Role pertence ao pacote comum Considerando que uma atividade pode ser derivada em atividade gerencial classe ManagerialActivity ou produtiva classe ProductiveActivity foi necess rio duplicar o relacionamento que existia entre as classes Role e Acticity denominado responsible de maneira a respeitar a divis o entre ge
145. dividuais de recursos em tempo real para atender as diferentes requisi es de tarefas de um projeto Assim esta solu o considera o uso de solvers cuja fun o consiste em receber a chamada de propostas analis las e gerar propostas para a realoca o de recursos que possibilitem prosseguir a execu o do projeto Um n mero crescente de organiza es est se voltando para tecnologia de agentes para enfrentar os ambientes complexos e din micos comuns maioria das 78 empresas Duas principais arquiteturas multiagentes para a programa o din mica podem ser consideradas arquiteturas aut nomas e arquiteturas com mediador e Arquiteturas aut nomas agentes que representam entidades da empresa tais como recursos e pessoas t m a capacidade de gerar suas programa es locais reagem localmente para as mudan as e cooperam diretamente uns com os outros para gerar programa es globais timas e robustas e Arquitetura com mediador tem uma estrutura b sica composta de agentes aut nomos locais de coopera o que sejam capazes de negociar uns com os outros a fim de alcan ar as metas de produ o GOU98 SHE99 BONOO SHEO1 Esta estrutura de base estendida com o uso de agentes mediadores para coordenar o comportamento dos agentes locais para fazer uma programa o global din mica Os agentes mediadores operam simultaneamente com os agentes locais no processo de tomada de decis o Eles t m a capacidade de aconselha
146. do projeto Por este motivo um dos documentos principais da gest o de projetos pois fornece a base para o planejamento de cronogramas e para a gest o de custos e recursos o criar um cronograma do projeto o gerente come a com um conjunto de tarefas contido na estrutura anal tica do projeto PREO9 Ent o ele especifica todas as informa es relacionadas ao projeto como as tarefas individuais a sequ ncia em que as tarefas precisam ser realizadas as tarefas que podem ser executadas em paralelo e os recursos para executar essas tarefas Com estas informa es o gestor pode gerar gr ficos apropriados tais como o gr fico de Gantt para refletir a aloca o real de recursos no projeto Durante o tempo de vida de um projeto dados reais como o tempo ou OS recursos que foram gastos para realizar uma determinada tarefa s o coletados e inseridos pelo gerente de projeto Esta informa o faz com que seja poss vel controlar o andamento do projeto e tomar as medidas apropriadas como a aloca o de mais recursos se necess rio Durante o planejamento e execu o de projetos de software os gestores tamb m devem levar em conta os diferentes tipos de tarefas que s o atribu dos a recursos com caracter sticas diferentes Em resposta s novas informa es os gestores podem precisar realizar altera es no plano de projeto tais como a realoca o de recursos ou cancelamento de tarefas JOSO5 Esses ajustes necess rios para os proj
147. dos 132 artigos dos quais 10 foram selecionados Al m disso outros 3 artigos foram inclu dos para extra o de informa es e Vieses identificados o numero de fontes de busca utilizadas quatro a qualidade dos motores de busca das fontes selecionadas e a influ ncia do autor na sele o dos artigos e na extra o das informa es 221 Varia o entre revisores nao se aplica Aplica o dos resultados os resultados servir o de base para conclus o da pesuisa do autor Recomenda es nenhuma 222 AP NDICE C INTERFACES DESENVOLVIDAS PARA O ESTUDO EXPERIMENTAL SOBRE O MODELO SPIM Este ap ndice cont m a descri o detalhada das interfaces desenvolvidas para a realiza o do estudo experimental sobre o modelo integrado SPIM Inicialmente os pesquisadores pensaram em desenvolver um site que pudesse auxiliar na promo o da palestra sobre o modelo SPIM Este site foi desenvolvido em PHP acessando uma base de dados MySQL O site encontra se hospedado em um servidor do Instituto Federal de Educa o Ci ncia e Tecnologia do Rio Grande do Sul C mpus Bento Gon alves Desta forma foi enviado um e mail para as duas turmas de p s gradua o em gest o de projetos informando sobre a palestra sobre o estudo experimental e sobre o link de acesso http napne bento ifrs edu br spim views index php A Figura 85 apresenta a p gina inicial deste portal SPIM Reconfigura o Din mica de Projetos d
148. dos devem ser disponibilizados a partir de novembro de 2011 sendo que estaremos lhe enviando uma comunica o por e mail Para participar basta clicar aqui e criar uma conta de acesso data limite para a cadastro e participa o 18 de outubro de 2011 Lembramos que as vagas s o limitadas Cadastre se j Colabore com o desenvolvimento das pesquisas na area de gerenciamento de projetos no Brasil Participe Em caso de d vidas entre em contato atraves do e mail mauricio rosito acad pucrs br Figura 85 Portal sobre o estudo experimental do SPIM Outro fator importante para o desenvolvimento deste portal foi de oferecer um mecanismo que permitisse maior seguran a e confiabilidade dos dados informados durante o estudo experimental 223 Este portal est divido nas seguintes se es a Pagina inicial b Apresenta o do Projeto c Inscri o no evento d Publica es do grupo de pesquisa e Contato f Formul rios do Estudo Experimental Cada uma destas se es apresentada a seguir C 1 PAGINA INICIAL CONVITE A Figura 86 apresenta a p gina inicial deste portal contendo o convite para o estudo experimental sobre o modelo SPIM Convite Prezado a s Gostar amos de convid lo para conhecer o modelo de planejamento integrado SPIM Software Planning Integrated Model desenvolvido por pesquisadores do Programa de P s Gradua o em Ci ncia da Computa o da PUCRS O SPIM compreende um modelo para supor
149. dos projetos com as atividades que fazem parte dos fluxos organizacionais 1 2 1 Objetivos espec ficos O objetivo geral pode ser desmembrado nos seguintes objetivos espec ficos e Identificar as caracter sticas fundamentais para uma solu o computacional de reconfigura o din mica de projetos de software que envolva o uso de recursos compartilhados a integra o com os fluxos organizacionais e a execu o em um ambiente de multiplos projetos simult neos e Elaborar um modelo que descreva a rela o entre os diversos elementos advindos da gest o de projetos e dos processos de desenvolvimento de software Com rela o vis o sobre o gerenciamento dos projetos optou se por usar como refer ncia o Guia do PMBOK PMI08 Para os processos de desenvolvimento de software foram pesquisados o RUP KRUOO OPEN FIRO2 e SPEM 0MG12 22 e Desenvolver uma estrat gia que permita a reconfigura o da programa o das atividades de projetos de software considerando a integra o das atividades espec ficas dos projetos com as atividades que fazem parte dos fluxos organizacionais e Implementar um prot tipo de ferramenta que possibilite avaliar os conceitos propostos nesta pesquisa e Avaliar a proposta de solu opor meio do prot tipo desenvolvido utilizando a simula o de cen rios com redes de Petri Uma vez apresentado os objetivos geral e espec ficos deste estudo introduz se a quest o de pesquisa utilizada
150. e atividades e tarefas sejam estabelecidas com os conceitos definidos no ProcessStructure jun o desses conceitos realizada justamente no pacote Process withMethods o qual atrav s do mecanismo de merge possui liga es com ambos os pacotes Method Content e Process Structure conforme Figura 5 214 ide MethodContent Definition de MethadContent Wor Produ tUbeRelationship O 1 workProduct a ProcessStructure linked WeorkProductlise Ge ProcessStructure InkadRaleusa de PRP AEE inkedRoleUse 1 1 de FrocessSoucdure ProcessPerformer ET de Process Sucre ownedProcessParaneter inkedTaskLse TaskDefir DM de MethodCorterk Figura 81 Metaclasses e associa es do pacote Process withMethods A 7 PACOTE METHOD PLUGIN O pacote Method Plugin define a capacidade para gerenciar bibliotecas de Method Content Process Esse pacote endere a o interesse de estabelecer grandes bibliotecas por definir Method Plugins and Method Configurations Adicionalmente o pacote Method Plugin define mecanismos de variabilidade e extensibilidade para o Method Content e Process Tais mecanismos s o considerados pelo metamodelo SPEM 2 0 como mecanismos de adapta o os quais permitem que processos sejam criados sobre demanda ou adaptados de acordo com o contexto dos projetos de software As novas metaclasses inclu das no pacote Method Plugin s o mostra
151. e 95 Det Sistemas DISCOS sai sarna cap n de pag E 95 5 1 2 Conceitos Utilizados na Modelagem de Sistemas a Eventos Discretos ittteeees 96 0 1 3 Paralelismo Coopera o Compeli o sarriro E NE A inss Sis nan Adao a Uia assa Tra suga di aa 96 5 2 INFRODUCAO AS REDES DE PETRI a aerea Des aaa TREO E SG GEE A 97 De AQCNMICOSS TOMS miga eA EN EET EE O NE EONA 100 5 2 2 Vantagens da Aplica o de Redes de Petri na Gest o de Projetos erram 101 dio sEXICNSOCS CaS Redes d PO saida oi a aa TAS Sia a ii Da pi ada QT E aU E dg 102 5 3 MECANISMO DE MAPEAMENTO ENTRE O DIAGRAMA DE REDE E A REDE DE PETRI ccsccccssseesseeesseeesees 103 34 PETRINET MARKUP LANGUAGE srt pio a A Reveenieactueat 107 541 Calacierisiicas B sicas ca PNML sissy acne eieidi Se Ra ane 107 942 Estr lura qe um Documento PNML us canspa za Raeagia damas na a RALO Te E 108 5 4 3 Exemplo de uma Rede de Petri representada atrav s da PNML cccccccccccccccccceeeeeeeeeeessnees 111 So CONSIDERA ES FINAIS DO CAPITULO ninan a RN RR a 112 MODELO PARA A RECONFIGURA O DIN MICA DE PROJETOS DE SOFTWARE 113 6 1 MODELO DE REFER NCIA PARA RECONFIGURA O DIN MICA DE PROJETOS DE SOFTWARE 113 BZ MODELO PROPOSTO sa eu SE de a GEO ete esos a eaten es da 119 6 3 IMPEEMENTA O DO MODELO oars sai so Siad a SE E a Sa 125 Odo SSI VON ATOR pasta la E 126 Doo SACK OTIC Sceptre earnest roscee 129 Doo Von
152. e Constru o 1 dia ar Transi o 2 dias 26 Integrar Sistema dias 29 Prepara o e Valida o do Ambiente 1 dia 30 Revizar Projeto e Aprova es 1 dia 31 Disponibiliza o da release 1 0 PRD dias 32 Acompanhamento do projeto 2 dias 33 Teste de Aceita o 3 dias a4 Fechar Projeto dias 35 Reuni o para Encerrar Projeto 1 dia JA Finalizar Prniatn 1 dia In cio SONS 2011 SONS 2011 S0 08V201 1 200S 201 1 04 10 2011 05 10 2011 07 0 2011 10 10 2017 10 10 2011 10 1 0 2011 12M 0 2011 1410 2011 14 10 2011 14 10 2011 20 10 2011 11 10 2011 11M 0 2011 13 10 2011 1310 2011 2510 2011 26 10 2011 26 10 2011 26 10 2011 270 2011 27 10 2011 270 2011 2771072011 01 11 2014 01 11 2011 MIA 112011 Figura 97 Projeto para o cen rio 3 E 4 CEN RIO 4 T rmino 07 10 2011 06 10 2071 04H 0 2011 03 0 2011 04 0 2011 061 0 2011 07H 0 2011 26 10 2011 13102011 10M 0 2011 11004011 24 10 2011 1771072011 19 10 2011 24 10 2011 2 12 10 2014 14 1 0 2011 14 10 2011 14 90 2011 210 2011 27 10 2011 27 10 2011 2610 4011 STM 02011 31 10 2011 2010 2011 31 10 2011 0211 2011 01711 2011 AMAA APSA Veja abaixo a descri o das atividades propostas para o cen rio 4 Cen rio 4 243 Predecessoras 23 19 21 25 JE Sa II amas Participante Teste Usu rio Download Clique aqui para fazer download do cen rio 4 Fluxos Organizacionais RH Contratar Fluxo Organizacional resp
153. e Desenvolvimento de Software Pagina Inicial Convite Apresenta o do Projeto Prezado a s Gostariamos de convida lo para conhecer o modelo de planejamento integrado SPIM Software Planning Integrated Model desenvolvido por pesquisadores do Programa de P s Gradua o em Ci ncia da Computa o da PUCRS O SPIM compreende um modelo para suporte ao gerente de projetos no planejamento e Publica es tratamento das atividades relativas aos demais fluxos de atividades da organiza o aqui denominados fluxos empresarias Inscri o Contato Durante a execu o das atividades de um projeto de software o gerente de projetos pode n o possuir todas as informa es relevantes para o projeto Por exemplo o gerente de projetos pode precisar contatar o setor de recursos humanos sobre a necessidade de contrata o de pessoal para um determinado projeto de desenvolvimento de software A prepara o t cnica e a libera o de uma sala ou equipamento testes s o outros exemplos cujas atividades n o s o exclusivas de um projeto em especial mas de um fluxo comum da empresa compartilhado pelos projetos em andamento e que utiliza recursos n o alocados diretamente ao projeto de software Dessa forma pode haver tamb m uma rela o de depend ncia entre as atividades pertencentes a estes dois tipos de fluxos de trabalho A dificuldade para identificar esta interdepend ncia dos fluxos de trabalho durante o planejamento de atividades pode afetar negativ
154. e Usu rio Download Clique aqui para fazer download do cen rio 3 Fluxos Organizacionais RH Contratar Fluxo Organizacional respons vel pela contrata o de pessoas RH Treinamento Fluxo Organizacional respons vel pelas atividades de treinamento da equipe Financeiro Comprar Fluxo Organizacional respons vel pela aquisi o de equipamentos Negocios Parceria Fluxo Organizacional respons vel pela realiza o de parcerias e contrata o de empresas terceirizadas Descri o do Cen rio 3 O pessoal mais qualificado est doente e n o dispon vel nos momentos cr ticos Orienta es 1 Abra o arquivo Cenario3 2 Durante a execu o da atividade Revis o de estimativas no dia 21 09 2011 voc se depara com um atestado m dico informando que o nico BDA S nior da equipe est doente e deve ficar fora do projeto por 2 meses Desta forma voc deve entrar em contato com o setor recursos humanos informando a necessidade de contratar um novo DBA S nior A contrata o de pessoas uma atividade pertencente ao fluxo organizacional do setor de recursos humanos cujo tempo de dura o de 5 cinco dias de Com base nesta situa o sem alterar a ordem das atividades no projeto defina qual o prazo m ximo limite para fazer esta solicita o ao setor de recursos humanos Digite sua resposta 4 Caso voc esteja usando o modelo SPIM Atribua uma rela o de depend ncia entre as atividades do projeto de sof
155. e afetado por incertezas e eventos externos JOSO5 JALO4 A ideia de usar planos de conting ncia parece ser muito promissora e combate boa parte da subjetividade presente nas decis es di rias feitas por gerentes de projetos de software Os planos de conting ncia s o sequ ncias pr codificadas de a es que devem ser realizadas toda vez que um problema ocorre Portanto esta uma solu o din mica Em outras palavras diante de um problema na configura o atual permitida a ado o de estrat gias de solu o para cada situa o apresentada O trabalho apresentado por Delen et al DEL99 cont m um conjunto de ferramentas integradas para modelagem an lise e gest o de sistemas A ferramenta PROSIM por exemplo fornece mecanismos para modelagem an lise e desenho de processos de neg cios Ela fornece um ambiente gr fico para modelar processos de neg cio e em seguida realizar simula es de cada processo Outra ferramenta o ProjectLINK que um add on para PROSIM permite que as informa es a partir de um modelo de processo sejam transportados para uma ferramenta de gerenciamento de projetos por exemplo o Microsoft Project Em RIHO1 mostrado o ProPlanT uma ferramenta multiagente que permite o planejamento das atividades de produ o e sele o de recursos com base em mecanismos de subscrever anunciar Em HESO9 apresentado um algoritmo de agendamento de recursos formulado para resolver o problema de
156. e as atividades os recursos e as informa es sobre as vari veis globais de projeto Os detalhes sobre esta arquitetura foram publicados em ROS12c A nfase da reconfigura o tratada nessa pesquisa desta forma ocorre sobre as atividades impactando tamb m na aloca o de recursos humanos para tais atividades em um contexto de m ltiplos projetos de software que s o executados de forma concorrente Ainda procurou se desenvolver uma solu o que permitisse a integra o clara e objetiva dos projetos de software com os fluxos organizacionais Depois da defini o deste modelo computacional de reconfigura o din mica desenvolveu se uma nova vers o do prot tipo para oferecer suporte automatizado para o 25 planejamento e replanejamento das atividades de projetos de software Ainda nesta fase foi realizada a consolida o e avalia o dos resultados obtidos permitindo a defini o das conclus es desta pesquisa A Figura 1 resume as principais atividades da pesquisa Atividade 3 Modelo de Integra o Atividade 1 Estudo em Abrang ncia Atividade 2 Estudo em Profundidade Modelos PMBOK Modelos RUP OPEN SPEM e Modelos de Integra o PMBOK RUP OPEN SPEM e An lise comparativa Defini o do SPIM Desenvolvimento do SPIT Atividade 4 An lise do Modelo de Integra o entre a GP e o PDS Realiza o de um estudo experimental An lise dos Resultados At
157. e gt lt graphics gt position x 200 y 100 gt lt dimension x 30 y 30 gt lt qraphics gt lt place gt lt place id p3 gt lt name gt lt text gt Definir Arquitetura lt text gt lt value gt 2 lt value gt lt name gt lt graphics gt lt position x 300 y 150 gt lt dimension x 30 y 30 gt lt qraphics gt lt place gt Figura 47 Trecho do c digo PNML onde est o descritos os lugares da RdP Em seguida sao analisados as transi es da RdP descritos no codigo PNML dentro das etiquetas lt transition gt e lt transition gt Estes elementos auxiliam na identifica o sobre a exist ncia de rela es de depend ncia entre as atividades do projeto Conforme ilustrado na Figura 48 a identifica o de cada transi o representado no codigo PNML pelo trecho lt text gt nome da transi o lt text gt AS informa es contidas na tag lt graphics gt s o utilizadas para representar graficamente estes objetos informando sua posi o e dimens o na tela 141 lt transition id ti gt lt name gt lt text gt ti lt text gt lt name gt lt gqraphics gt lt position x 150 y 100 gt lt dimension x 30 y 30 gt lt graphics gt lt transition gt lt transition id t2 gt name gt lt text gt t2 lt text gt lt name gt lt qraphics gt lt position x 350 y 100 gt lt dimension x 30 y 30 gt lt qraphics gt lt
158. e on System Sciences 2004 pp 1 10 HELLER M WESTFECHTEL B DYnamic Project and Workflow Management for Design Processes in Chemical Engineering Process systems Engineering 2003 HENNING G P CERDA J Knowledge based predictive and reactive scheduling in industrial environments Computers and Chemical Engineering vol 24 9 2000 pp 2315 2338 HENDERSON SELLERS B DUE R GRAHAM l COLLINS G Third generation OO processes a critique of RUP and OPEN from a project management perspective In Seventh Asia Pacific Software Engineering Conference 2000 pp 428 435 HENDERSON SELLERS B COLLINS G DUE R GRAHAM I M A Qualitative Comparison of Two Processes for Object Oriented software Development Information and Software Technology United 195 196 HEROS HES09 HIGO8 HUM89 HUM91 IBM11 JACO1 JALO4 JENO1 JIAO6 J0S05 JOZ98 JUNOO JUR99 JUROS Kingdom Elsevier Science vol 43 November 2001 pp 705 724 HERROELEN W LEUS R Project scheduling under uncertainty Survey and research potentials European Journal of Operational Research vol 165 2 2005 pp 289 306 HU H LI Z Modeling and scheduling for manufacturing grid workflows using timed Petri nets The International Journal of Advanced Manufacturing Technology vol 42 2009 pp 553 568 HIGGINS J P GREEN S Cochrane Handbook for Systematic
159. e pacotes ilustrada na Figura 14 integratedModel compiler core entities cont m as classes que comp em a representa o em C net de um rede de Petri integratedModel compiler core io pnml cont m as classes respons veis por realizar a grava o dos arquivos de sa da no formato PNML integratedModel compiler core io msProject cont m as classes respons veis por realizar a grava o dos arquivos de sa da no formato para o Microsoft Project integratedModel compiler core parser pnml cont m as classes que comp em o parser de arquivos no formato PNML integratedModel compiler core parser msProject cont m as classes que comp em o parser de arquivos no formato para o Microsoft Project integratedModel compiler core util Classes de uso comum a todo o m dulo integratedModel compiler Figura 42 Diagrama de pacotes do M duloCompiler A seguir ser detalhado o pacote entities cujos elementos representam o modelo definido no compilador de uma rede de Petri estoc stica 135 6 3 4 2 Pacote Entities Contem as classes que representam as entidades basicas do sistema Assim cada classe representa uma categoria de elementos que comp em uma rede de Petri gerada pelo SPIT As classes que comp em este pacote ilustradas na Figura 43 s o listadas a seguir e PetriNet representa uma rede de Petri com todos os seus poss veis elementos e Node classe com elementos comuns s classes Transition e Place e Place represe
160. e s o registrados pelo modulo BackOffice do SPIT conforme ilustrado na Figura 60 Conforme definido pelo modelo SPIM os pap is s o divididos em duas categorias gerencial e produtivo E Register Eportto MS Project_Import from MS Project Help Register p Companies fan Programs i o O Projetista de Banco de Dados respons vel pela identifica o dos dados que devem ser armazenados no banco de a Frojects dados escolhendo a estrutura cometa para representar e armazenar dados Projetista de Banco de Dados Process Groups Knowledge Areas Project Phase fo Tasks Roles ren bi Work Products Es Guidance Task Groups Disciplines o Project Workflow Home k Analista de Sistemas Desenvolvedor Gerente de Projetos Integrador Testador DO usa 60 Interface de cadastro de pap is do BackOffice Em seguida o BackOffice apresenta uma interface para cadastrar os principais produtos de trabalho do projeto vide Figura 61 Estes produtos tamb m s o classificados pelo modelo SPIM como gerenciais tais como ata de reuni o e cronograma e produtivos tais como diagramas de casos de uso diagrama ER etc Al m disso pode se informar se este produto de trabalho ser criado ou n o por uma empresa externa ao projeto S Manuten o do Projeto Integrado Manuten o de de Produtos de Trabalho B f a Register Export to MS Project Import from MS Project Help l elx R Produtiva v Diagr
161. e trabalho afins A classe Workflow constitu da por um conjunto de atividades produtivas que produz um nico produto de trabalho ou fornece um nico servi o A classe Technique respons vel pela modelagem formas de executar uma ou mais unidades de trabalho Finalmente a classe ProductiveActivity descreve as atividades produtivas realizadas por pap is produtivos A classe Stage representa os intervalos de tempo que fornecem uma organiza o macro s unidades de trabalho sendo subdividida em est gios com dura o ciclos fases fluxos projeto desenvolvimento vers es de entregas e entregas e milestones Esta classe subdivida em etapas com dura o classe StageWithDuration tais como ciclos fases e builds e est gios sem dura o classe StageWithoutDuration como marcos e inch pebbles A classe Cyclerepresenta um per odo de tempo em que uma ou mais unidades de trabalho pode ser executada Um ciclo consiste em uma ou mais fases classe Build respons vel pela decomposi o das fases em per odos gerenci veis de tempo Estes per odos de tempo devem ter uma dura o curta por exemplo um dia ou um m s A classe InchPebble representa marcos em miniatura A classe WorkProduct representa algo que produzido consumido ou modificado como documentos modelos ou c digos fonte durante a execu o das atividades Um produto de trabalho pode ser subdividido em produtos gerenciais classe Deliverable ou produto
162. e workflows que s o as disciplinas do processo e os detalhes de fluxo workflow detail que s o os fluxos internos de cada disciplina Atrav s da UML um fluxo pode ser expresso como um diagrama de sequ ncia colabora o ou de atividade BOOO0 importante ressaltar que um fluxo n o pode ser interpretado literalmente como sendo um conjunto de passos no qual um indiv duo ir executar de forma autom tica e mec nica Cada disciplina expressa atrav s dos pap is quem executa a tarefa das atividades como executar estas tarefas e dos artefatos o que a atividade consegue Dessa forma uma disciplina apresenta as atividades relacionadas de diferentes pap is em um fluxo de informa o assim definindo como as atividades interagem com os artefatos 2 4 2 2 Modelo de Refer ncia para o RUP De acordo com Jacobson Booch e Rumbaugh JACO1 o RUP utiliza os conceitos da linguagem UML para especificar e documentar os modelos de sistemas de software O RUP apresenta um modelo sem ntico ilustrado na Figura 4 contendo seus principais elementos e relacionamentos PEPO9 Este modelo determina como os elementos do processo s o organizados e quais as rela es v lidas entre estes elementos 38 Figura 4 Modelo sem ntico do RUP PEP09 Na Figura 4 a classe Lifecycle representa o ciclo de vida de desenvolvimento de um software Este conceito particionado em um conjunto de quatro fases classe Phase clas
163. eakdownElement entre as metaclasses Activity e BreakdownElement A rela o nestedBreakdownElement permite o aninhamento de elementos dentro de uma atividade J as rela es usedActivity e suppressedBreakdownElement permitem respectivamente um mecanismo de reuso e supress o de elementos do processo A 3 PACOTE MANAGED CONTENT O pacote ManagedContent define os conceitos fundamentais para gerenciar as descri es textuais para os processos elementos do ProcessStructure e os elementos do MethodContent no SPEM 2 0 Esse pacote introduz a metaclasse abstrata DescribableElement que atrav s do mecanismo de merge serve como uma super classe para elementos de processo definidos no pacote ProcessStructure e tamb m para as metaclasses do pacote MethodContent O elemento DescribableElement composto de uma metaclasse ContentDescription que permite relacionar descri es textuais para os elementos A Figura 77 mostra as metaclasses e rela es do pacote ManagedContent Na Figura 77 poss vel verificar que a metaclasse DescribableElement uma especializa o da metaclasse ExtensibleElement do pacote Core A metaclasse DescribableElement possui uma rela o de composi o com a metaclasse ContentDescription que possui v rios atributos relacionados com descri o textual bem como rela o de composi o com uma metaclasse denominada Section Isso o que permite que todas as especializa es da metaclasse DescribableElement possua
164. ecursos humanos Assim o fluxo de atividades em um projeto individual geralmente est relacionado a outros fluxos comuns de atividades da organiza o chamados de fluxos organizacionais Ambos os tipos de fluxos de trabalho s o executados em paralelo t m seus pr prios recursos e pode influenciar o tempo de atividades e custos do projeto de software ver Figura 36 EVENTOS Fluxo de Projetos Fluxos Organizacionais Oonacama APOIO A DECIS ES Figura 36 Interdepend ncia entre os fluxos de trabalho organizacionais e o fluxo de projetos de software adaptado de ROS 13 120 Considerando esta situa o apresentada acima a fim de contribuir para a solu o das dificuldades apontadas uma primeira vers o de um modelo computacional chamado Software Planning Integrated Model SPIM foi proposta ROSO8a O SPIM foi inicialmente desenvolvido considerando a integra o de conceitos de gerenciamento de projetos previstos no PMBOK com os conceitos de desenvolvimento de software advindos do Rational Unified Process RUP KRUOO e do Object oriented Process Environment and Notation OPEN FIRO2 Entretanto foi poss vel identificar que os metamodelo de integra o PMBOK RUP e PMBOK OPEN apresentavam uma estrutura de classes similar substituindo apenas o pacote referente ao processo de desenvolvimento de software Assim tanto as classes dos pacotes PMBOK e Common como os relacionamentos entre as classes pertencentes
165. eduling International Journal of Advanced Manufacturing Technology vol 17 4 2001 pp 305 314 REHMAN A HUSSAIN R Software Project Management Methodologies Frameworks Dynamics A Comparative Approach In 7 International Conference on Information and Emerging Technologies Karachi Pakistan July 2007 pp 1 5 RIHA A PECHOUCEK M KRAUTWUNNOVA H CHARVA P KOUMPIS A Adoption of an Agent Based Production Planning Technology in the Manufacturing Industry In 12 International Workshop on Database and Expert Systems Applications pp 640 646 2001 ROS06 IROSO08a ROSO8b ROS 12a IROS12b ROS12c IROS12d ROS13 ROS 14 SAB00 SAR90 SCH94 ROSITO M C CALLEGARI D BASTOS R M Metamodelos de processos de desenvolvimento de software Um estudo comparativo In Ill Simp sio Brasileiro de Sistemas de Informa o Curitiba 2006 8p ROSITO M CALLEGARI D BASTOS R Ger ncia de Projetos e Processos de Desenvolvimento de Software uma proposta de integra o In IV Simp sio Brasileiro de Sistemas de Informa o 2008 Rio de Janeiro ROSITO M CALLEGARI D BASTOS R M Ger ncia de Projetos e Processos de Desenvolvimento de Software uma proposta de integra o iSys Revista Brasileira de Sistemas de Informa o PPGI UNIRIO vol 1 Outubro 2008 pp 088 115 ROSITO M BASTOS R A Systematic Review on the In
166. efini o e principais conceitos relacionados com a reconfigura o din mica de projetos de software 81 4 2 Reconfigura o Din mica de Projetos de Software Defini o e Conceitos Relacionados 4 2 1 Defini o e Aspectos Relacionados De acordo com o Project Management Institute PMI08 um projeto um empreendimento tempor rio com o objetivo de produzir um produto ou servi o Normalmente um projeto direcionado para alcan ar um resultado espec fico e envolve a implementa o coordenada de atividades inter relacionadas Mais do que isso os projetos s o planejados executados e controlados por pessoas e s o restringidos por recursos limitados Por sua vez o gerenciamento de projetos respons vel por monitorar o cumprimento dos objetivos do projeto atrav s da aplica o de um conjunto de t cnicas e ferramentas SCHO2 Assim observa se que os gerentes de projetos podem necessitar de algum tipo de apoio geralmente baseado em uma metodologia de gerenciamento de projetos para lidar com as diferentes responsabilidades tarefas e vari veis de projeto Para esse prop sito existem v rias propostas na literatura j aplicadas nas empresas de software Entretanto o gerenciamento de projetos de software n o uma tarefa f cil de ser realizada Projetos de software s o muito din micos e requerem recorrentes ajustes dos seus planos de projeto Essas configura es podem ser entendidas como reconfigura es na program
167. elacionados ao problema de reescalonamento de atividades considerando um recurso m quina com avaria Estes crit rios incluem a minimiza o do tempo total de trabalho efici ncia da programa o e o impacto da mudan a do cronograma estabilidade da programa o Para a estabilidade eles investigaram duas medidas o desvio de tempo de in cio original do trabalho e o desvio da sequ ncia original das atividades Os resultados experimentais mostraram a efic cia desta medida proposta devido ao fato de que a estabilidade da programa o foi aumentada de forma significativa com pouca ou nenhuma redu o no tempo total de trabalho Na mesma linha de racioc nio Abumaizar e Svestka ABU9 usaram duas medidas para definir uma programa o robusta efici ncia makespan e estabilidade desvio do tempo inicial do trabalho e desvios de sequ ncia dos trabalhos O objetivo da programa o de maximizar a efici ncia do projeto e ao mesmo tempo minimizar o impacto no projeto causado por altera es na programa o Jensen JENO1 investigou diferentes medidas de robustez para melhorar a lentid o e o fluxo total de tempo para quebra de equipamentos m quinas Assim extensos resultados computacionais j relataram a efici ncia e a efic cia das medidas robustez propostas acima Cowling e Johansson COW02 e Ouelhadj et al OUEO3 definiram medidas gerais de utilidade e estabilidade para orientar a decis o de qual estrat gia deve ser utiliz
168. elo PMBOK SPEM definido durante esta pesquisa fornece a estrutura conceitual necess ria para o desenvolvimento de um modelo que auxilie o planejamento de projetos considerando os elementos que comp em o processo de desenvolvimento de software Com este objetivo foi desenvolvida a vers o final domodelo computacional SPIM A Figura 37 apresenta as etapas de desenvolvimento deste modelo PMBOK SPEM PMBOK Rup PMBOK OPEN Atividades Atividades Atividades Da Atividades Atividades Gerenciais Lb Produtivas Gerenciais a Produtivas Gerenciais Lb Produtivas Metamodelo Integrado Metamodelo Integrado Metamodelo Integrado PMBOK SPEM PMBOK RUP PMBOK OPEN Modelo Integrado SPIM PA PB PZ co co co co co co co co co co co co aq co co co Co Co Figura 37 Etapas de desenvolvimento do SPIM 122 O modelo integrado SPIM conforme ilustrado na Figura 38 considera a integra o dos conceitos de gest o de projetos advindos do PMBOK com os conceitos de processos de desenvolvimento de software advindos do RUP OPEN e SPEM Ainda este modelo considera a distin o entre as atividades dos projetos de software atividades gerenciais e produtivas das atividades dos fluxos organizacionais atividades gerenciais de apoio 1 lt director 0 name ProjectStakeHolder description iskeyStakeHolder ManagerialActivity ActivityPhysicalResourceWork levelOfinfluence timeFrame Common baselines v scopeStat
169. em objetos Cf No entanto esta tradu o apresenta algumas peculiaridades devido a possibilidade do arquivo de entrada ser gerado por outra ferramenta Para evitar inconsist ncias no processo de tradu o definimos duas regras b sicas para validar o conte do dos arquivos PNML de entrada L a verificar se o elemento ID representado no documento PNML necessariamente inteiro e b verificar se o elemento de nome representado no documento PNML come a com uma letra Visando um melhor desempenho no processo de convers o essas valida es s o implementadas usando o mecanismo de express o regular oferecido pelo Net 139 Framework Durante este processo de valida o os nomes ou identificadores inv lidos s o substitu dos com IDs e nomes v lidos Estas modifica es devem ser mantidas para que durante a leitura de elementos que possuem refer ncias a outros elementos da rede como por exemplo os arcos n o sejam introduzidas inconsist ncias no modelo gerado A Figura 46 apresenta uma RdP utilizada para exemplificar o funcionamento do parsing de arquivos PNML desenvolvido para o prot tipo SPIT Reuni o de Inicio do Projeto Ti Elaborar documento de requisitos T2 Definir Arquitetura Figura 46 Rede de Petri para um projeto de software fict cio Ap s a valida o do arquivo de entrada que cont m a RdP no formato PNML o arquivo analisado Os lugares descritos no c digo PNML dentro das etiquetas lt p
170. ement indirectCosts type workload name lag responsible purpose assignment objectives ANBSIndex directCost r BaselineDate lt lt abstract gt gt Role description M ut creates p isRepeatable boolean hasMultipleOccurences boolean isOptional boolean l Ta ProductiveRole is ngoing boolean isEventDriven byte ProcessResponsabilityAssignment WorkProductUse WorkDefinitionParameter direction ParameterDirectionkind EEE O Le ProcessParameter E Lo Ra 1 i Figura 38 Classes do modelo integrado SPIM ROS13 Neste modelo a classe Organization representa uma empresa que organizada por programas classe Programs Os programas s o grupos de projetos designados para alcan ar um objetivo estrat gico As organiza es normalmente dividem os projetos em v rias fases classe Phase visando um melhor controle gerencial Um recurso necess rio para o projeto tais como pessoas equipamentos ou local representado pela classe Resource Esses recursos s o divididos em recursos ativos Classe Stakeholder e n o ativos classe PhysicalResource Al m disso a classe PhysicalResource representa um recurso f sico num projeto tal como um material 123 necessario para realizar uma atividade um equipamento necessario para realizar uma atividade ou um local fisico A classe ProjectStakeholder representa a rel
171. enta o dos tratamentos consiste no risco em que diferentes participantes possam implementar de forma distinta os processos estabelecidos pelo experimento Este risco n o ser evitado em nosso estudo visto que n o se pode interferir no car ter subjetivo do planejamento de atividades de projetos de software Possivelmente diferentes participantes definir o planejamentos distintos 237 e Configura es do ambiente do experimento consiste nas interfer ncias externas do ambiente que podem influenciar os resultados durante a execu o do experimento O experimento ser executado laborat rios isolados onde ser proibida a intera o externa como celulares sa das etc e Heterogeneidade aleat ria dos participantes a escolha de diferentes participantes com diferentes experi ncias pode exercer um risco na varia o dos resultados D 5 7 Aspectos para a Execu o do Experimento Para preparar a execu o do experimento atentou se para e Consenso com o experimento Durante a experimenta o a prepara o dos participantes dever fomecer o embasamento necess rio sobre o experimento e Resultados sensitivos poss vel que o resultado obtido pelo experimento se influencie por quest es pessoais como a sensibilidade dos participantes por estarem sendo avaliados Ser adotada uma postura de anonimato dos participantes em toda a descri o da experimenta o Com rela o instrumenta o todas as vari veis e
172. ente foram apresentados os conceitos relacionados linguagem PNML Petri Net Markup Language O pr ximo Cap tulo discorre sobre o modelo de reconfigura o din mica de projetos de software desenvolvido nesta tese que considera o uso de redes de Petri para simular diferentes cen rios que ocorrem em decorr ncia de eventos inesperados 113 6 MODELO PARA A RECONFIGURA O DIN MICA DE PROJETOS DE SOFTWARE 6 1 Modelo de Refer ncia para Reconfigura o Din mica de Projetos de Software Considerando a associa o da proposta desta pesquisa com o Modelo de Reconfigura o Din mica para Projetos de Desenvolvimento de Software CAL10 seu funcionamento detalhado a seguir O processo de reconfigura o no modelo proposto por Callegari CAL10 inicia por meio da ocorr ncia de eventos que s o disparados pela cria o altera o ou remo o de um elemento de projeto pelo gerente Como exemplos destes eventos citam se a cria o de uma nova tarefa no projeto o aumento ou decr scimo do prazo em uma tarefa e sa da de um recurso do projeto Assim quando um evento de reconfigura o ocorre v rias tarefas podem ser afetadas Dessa forma o modelo segue um ciclo para chamadas de propostas Call For Proposals CFP onde inicialmente verificam se as posi es de trabalho para as tarefas que foram afetadas em fun o da ocorr ncia do evento Atrav s dessa CFP poss vel identificar os recursos capazes de ocupar cada
173. ente fornecem apenas um conjunto de pr ticas que atendem a determinadas atividades e fluxos de trabalho relacionados ger ncia de projetos HENOO ROSO8a 2 4 Metamodelos e Modelos de Gest o de Projetos e de Processos de Desenvolvimento de Software Um metamodelo um modelo que permite modelar outro modelo conceitual ou seja uma forma de descrever como um modelo deve ser modelado LEEO2 Os processos de software constru dos a partir de um metamodelo geralmente oferecem um alto grau de formalismo e melhor suporte para consist ncia e customiza o uma vez que os conceitos que formam sua base s o explicitamente definidos Segundo Perez e Sellers PERO5 essa a maneira de formalizar as ideias e conceitos subjacentes de um processo de software que s o importantes para sua checagem de consist ncia e tamb m para poss veis extens es ou modifica es do processo Al m disso os metamodelos s o normalmente representados com diagramas de classe da Unified Modeling Language UML OMG10 de modo que eles s o capazes de representar restri es atrav s das multiplicidades entre suas metaclasses Os 32 metamodelos tamb m permitem associar restri es mais complexas atrav s da linguagem natural ou linguagens formais tais como Object Constraint Language OCL WARO3 Z MOU01 L gica de Primeira Ordem em ingl s First order Logic FoL SMU95 entre outras A utiliza o de metamodelos tamb m possibilita o
174. entes observa se um tend ncia para a ado o deste formato Este formato foi utilizado como o padr o pelo prot tipo de ferramenta implementado nesta tese Esta se o apresenta as caracter sticas b sicas da linguagem PNML assim como as extens es que foram adicionadas para representar as redes temporizadas e coloridas 5 4 1 Caracter sticas B sicas da PNML Tr s princ pios foram levados em considera o na defini o do padr o PNML pelos seus autores WEBO2 e Flexibilidade o formato deve ser capaz de representar qualquer tipo de rede de Petri com suas extens es e caracter sticas especificas Na PNML as informa es adicionais podem ser anexadas a rede propriamente dita ou apenas aos elementos relacionados aquela informa o e N o Ambiguidade significa afirmar que a RdP representada e seu respectivo tipo podem ser determinados unicamente pela sua representa o em PNML 108 e Compatibilidade garante que o maximo de informa o poss vel seja compartilhado entre os diferentes tipos de rede de Petri existentes e legibilidade o formato deve permitir a leitura e edi o das redes em qualquer editor de textos A PNML permite que atrav s de programas tradutores a rede possa ser transferida entre as diversas ferramentas vide Figura 23 A PNML aceita desta forma a comunica o entre diferentes formatos de representa o de redes de Petri Logo a PNML disponibiliza mecanismos de valida o de documento
175. envolvimento de software utilizando o paradigma de orienta o a objetos Um processo instanciado e customizado a partir do metamodelo do OPEN atrav s da adi o e remo o dos componentes de processo Esta opera o permite atender melhor as necessidades de uma organiza o em termos de tamanho cultura investimento e outras caracter sticas e envolve a escolha de atividades tarefas t cnicas e configura es espec ficas para o neg cio Uma unidade de processo process unit define um conjunto de atividades relacionadas que s o executadas durante um projeto Tamb m define as entradas necess rias para gerar as sa das deliverables atrav s da execu o uma s rie de atividades OPE02 Al m disso o OPF define que as unidades do trabalho work units s o componentes que modelam as opera es que s o executadas durante uma unidade de processo O OPF considera os seguintes tipos de unidades de trabalho Atividades definem o que precisa ser feito fluxo Tarefas definem o que fazer de forma coesa T cnicas definem como tarefas ser o realizadas O ciclo de vida de desenvolvimento de projetos do OPEN descreve o tempo de dura o em que o projeto constru do FIR02 O ciclo de vida formado por um conjunto de atividades que produzem e consomem produtos de maneira gradativa durante a realiza o de tarefas um processo baseado em entregas onde cada est gio envolve uma ou mais entregas Em todo e
176. er utilizada e os tratamentos consistem no planejamento tradicional e o planejamento integrado de projetos de software Por motivos de projeto e complexidade utilizaremos o tipo de projeto completamente aleat rio onde cada participante executar apenas uma abordagem definida aleatoriamente D 5 5 Instrumenta o Nesta pesquisa a aquisi o dos dados ser realizada por meio de um question rio Ap ndice E elaborado em conformidade com Rea amp Parker 2005 Assim a elabora o do question rio foi realizada de acordo com os seguintes passos e coleta de dados preliminares a respeito do tema e da popula o alvo da pesquisa 235 e discuss o em grupo sobre as quest es e elabora o do rascunho do question rio e realiza o de um pr teste e revis o do instrumento baseado nas observa es obtidas no pr teste e e delineamento do question rio final Na primeira etapa ser realizado o levantamento bibliogr fico e o estudo do referencial te rico que permitir aprofundar os conhecimentos sobre riscos e eventos durante o planejamento em projetos de software e sobre processos de ger ncia de projetos Al m disso ser definida a popula o alvo desta pesquisa estudantes de p s gradua o neste caso Em seguida foram realizadas reuni es entre o pesquisador e o professor orientador para o levantamento das quest es e a estrutura o do roteiro de entrevistas Estas reuni es resultar o na elabora o de
177. erado a literatura fornece algumas abordagens com base em uma estrat gia experimental Pfleeger e Atlee PFLO9 sugerem as seguintes abordagens para avaliar processos produtos e recursos a an lise de funcionalidades feature analysis b estudos de caso case studies c pesquisas surveys e d experimentos experiments A an lise de funcionalidades usada para avaliar e classificar os atributos caracteristicas de um produto de software No entanto esta estrat gia n o avalia o comportamento dos dados em termos de causa e efeito Estudo de caso usado para organizar as informa es sobre um caso situa o espec fico e em seguida analisar estas informa es buscando padr es nestes dados e uma posterior an lise realizada atrav s da compara o com outros casos situa es Survey um estudo retrospectivo para documentar as expectativas e resultados relacionados a determinadas situa es Esta t cnica pode tamb m ser aplicada para realizar uma avalia o emp rica dos resultados atrav s de indicadores qualitativos No entanto n o h manipula o de vari veis de entrada neste estudo Estudos experimentais por outro lado representam um tipo mais controlado de estudo geralmente conduzido em laborat rios Nesta abordagem os valores das vari veis independentes entradas do experimento s o manipulados para observar as altera es nos valores das vari veis dependentes sa das do experimento No final do exper
178. ereree rear rear eee seara renan 244 Projeto parao cenang 6 Joe Ee RE DEE RR O ER 246 LISTA DE TABELAS Tabela 1 An lise Comparativa entre os principais conceitos do RUP e do OPEN 58 Tabela 2 Eventos relacionados aos recursos humanos ccccceecseeceeeeeeeeeeeeeaeeseeeaeeees 83 Tabela 3 Eventos relacionados s atividades dos projetos ccccecseeseeeeeceeeeeeeeeeees 84 Tabela 4 Eventos relacionados a caracteristicas globais dos projetos 85 Tabela 5 Strings de pesquisa utilizados cc cccceccecceecseeceeeeeeeeeteeesseteeeeeeteeteeeeeeeseeeeeeas 89 Tabela 6 Resultado sobre os artigos pesquisados serena 91 Tabela 7 Principais terminologias utilizadas nos processo de software 120 Tabela 8 Conjunto de restri es do modelo integrado SPIM iii ii 127 Tabela 9 Resultados do teste de Shapiro Wilk para a vari vel esfor o 161 Tabela 10 Teste de Levene de igualdade de vari ncias para a vari vel esfor o 162 Tabela 11 Teste T para a vari vel GSfOrGO cccccceccseeceeteeeeeeceeeaeeteeteeceueteeeeeseeseeeaaes 163 Tabela 12 Resultados do teste de Shapiro Wilk para a vari vel precis o 164 Tabela 13 Teste n o parametrico de Mann Whitney para a vari vel de precis o 165 Tabela 14 As estat sticas descritivas para a vari vel precis o
179. eri ncia em gest o de projetos entre dois e cinco anos e 22 22 possuem experi ncia entre cinco e dez anos Al m disso 36 11 da amostra qualificaram se como tendo pouca experi ncia em gerenciar de projetos enquanto que o restante 63 89 qualificou se como tendo conhecimentos entre moderado e avan ado Al m disso 72 22 dos indiv duos classificaram o seu conhecimento com rela o aos processos de desenvolvimento de software como sendo moderado ou avan ado Isso indica um n vel suficiente de experi ncia destes sujeitos relacionado gest o de projetos A an lise do modelo SPIM iniciou com a avalia o dos participantes sobre os benef cios diretos em realizar o planejamento integrado de atividades gerenciais e produtivas em projetos de software Os resultados s o mostrados na Tabela 15 Tabela 15 Os benef cios percebidos na realiza o do planejamento integrado de atividades gerenciais e produtivas Percep o Resp Redu o do tempo durante o processo de elabora o do projeto 19 52 17 Identifica o das depend ncias entre as atividades gerenciais de 36 100 apoio e as atividades produtivas Identifica o e mensura o dos custos indiretos do projeto 22 61 11 devido s atividades gerenciais de apoio Capacidade de acessar informa es dos fluxos de trabalho 21 15 empresa A capacidade de minimizar distor es durante o planejamento 36 100 atraves das atividades gerenciais de apoio Permite que os gerentes de pr
180. es arcos e quaisquer outros objetos relacionados a algum tipo espec fico de rede de Petri Cada objeto possui um identificador nico que o referencia dentro da rede Um lugar definido em PNML pela tag lt place gt A Figura 25 demonstra uma declara o de um lugar na rede Este lugar tem p1 como seu identificador est disposto na posi o x 10 y 10 do ambiente gr fico possui um r tulo Place1 colocado na posi o x 5 y 2 e possui um token como marca o inicial As informa es gr ficas de qualquer objeto em PNML s o fornecidas pelo elemento graphics Seu conte do varia de acordo com o objeto em que est contido Em geral podem ser definidas as informa es sobre a posi o o tamanho e as cores Na Figura 25 definida a posi o do lugar atrav s da tag lt position gt A marca o inicial do lugar definida com a utiliza o da tag lt initialMarking gt place 1d pl gt lt graphics gt lt position x 10 y 10 gt lt qraphics gt lt name gt lt text gt Placel lt text gt lt graphics gt Beiae a q J gt lt graphics gt lt name gt lt initialMarking gt lt text gt 1 lt text gt lt initialMarking gt lt place gt Figura 25 Exemplo de descri o de lugar com PNML As transi es s o identificadas pela tag lt transition gt A Figura 26demonstra a defini o deuma transi o acompanhada de um r tulo t 110 lt transition id t1 gt
181. es de trabalho Ainda em momento posterior composi o da CFP esta proposta enviadaaos solvers presentes no modelo para o envio de propostas de realoca o Neste momento observa se a necessidade de esclarecer como os cen rios foram detalhados e quais s o as conven es adotadas para embas los Cabe salientar que tais conven es s o suportadas pelo modelo de reconfigura o din mica de projetos de 168 software CAL10 Neste modelo cada projeto representado por um diagrama de rede atrav s do M todo do Diagrama de Preced ncia MDP O MDP um m todo usado no M todo do Caminho Cr tico CPM para a constru o de um diagrama de rede do cronograma do projeto PMIO8 Esse m todo utiliza caixas ou ret ngulos tamb m chamados de n s ou blocos para representar as tarefas e as conecta por setas para ilustrar as depend ncias O MDP inclui quatro tipos de rela es de depend ncias PMIOS e T rmino para in cio indica que o in cio de uma tarefa sucessora depende do t rmino de sua predecessora Esse um dos tipos de depend ncia mais utilizado para representar as rela es no MDP e T rmino para t rmino indica que o t rmino de uma tarefa sucessora depende do t rmino de sua predecessora e In cio para in cio indica que o in cio de uma tarefa sucessora depende do in cio de sua tarefa predecessora e In cio para t rmino indica que o t rmino de uma tarefa sucessora depende do inicio de sua taref
182. es m tuas Procura se portanto descrever uma exclus o entre dois processos a partir de um ponto de sincroniza o e Pseudo paralelismo o paralelismo apenas aparente e os eventos mesmo independentes nunca ser o simult neos Eles ser o ordenados por um rel gio comum o caso de v rias tarefas sendo executadas num nico processador Este executa somente uma instru o por vez e Paralelismo verdadeiro os eventos podem ocorrer simultaneamente Isto significa que n o existe uma escala de tempo comum suficientemente precisa para determinar qual evento precedeu o outro Ocorre quando v rias tarefas s o executadas num computador paralelo com um processador alocado para cada tarefa independente 5 2 Introdu o s Redes de Petri A rede de Petri uma ferramenta gr fica e matem tica que se adapta bem a um grande n mero de aplica es em que as no es de eventos e de evolu es simult neas s o importantes MUR89 Entre as suas aplica es pode se citar avalia o de desempenho an lise e verifica o formal em sistemas discretos protocolos de comunica o controle de oficinas de fabrica o concep o de software em tempo real e ou distribu do sistemas de informa o sistemas de transporte log stica gerenciamento de base de dados entre outros Os elementos b sicos que permitem a defini o de uma rede de Petri s o os seguintes e Lugar representado por um c rculo pode ser interpretado como u
183. es que fazem parte dos fluxos organizacionais Uma ferramenta de software foi desenvolvida para demonstrar e avaliar os resultados de um estudo experimental realizado com estudantes de p s gradua o em gest o de projetos Al m disso este modelo considera a possibilidade de simular cen rios de projetos de software utilizando redes de Petri em resposta a eventos de reconfigura o do projeto Palavras Chave Reconfigura o Din mica Fluxos Organizacionais Ger ncia de Projetos de Software Revis o Sistem tica Estudo Experimental DYNAMIC RECONFIGURATION OF SOFTWARE PROJECTS A MODEL TO INTEGRATE SOFTWARE PROJECT MANAGEMENT WITH ORGANIZATIONAL WORKFLOWS ABSTRACT Software projects are very dynamic and require recurring adjustments of their project plans These adjustments can be understood as reconfigurations in the schedule in the resources allocation and other design elements The large amount of information that the project manager must deal combined with the frequent changes in the scope and planning makes this activity more challenging In addition the manager may need to consult other departments in the organization during the execution of a software project Based on these assumptions a study was conducted to determine the state of the art of the dynamic reconfiguration of software projects with emphasis on the integration of project management and organizational workflows in order to identify the main gaps and chal
184. escolhido um contexto que envolve estudantes de duas institui es de ensino superior distintas a saber olnstituto Brasileiro de Gest o de Neg cios IBGEN e a Pontif cia Universidade Cat lica do Rio Grande do Sul PUCRS Assim este estudo envolveu trinta e seis alunos dos cursos de p s gradua o em Gerenciamento de Projetos Foi utilizada uma amostra n o probabil stica para a sele o dos indiv duos de modo que foram escolhidas para o experimento as pessoas mais convenientes convenience sampling e tamb m indiv duos de popula es diferentes nesse caso foram escolhidos alunos de p s gradua o de duas institui es de ensino superior quote sampling Este experimento consiste em uma abordagem in vitro e off line em que os participantes realizaram o experimento em um ambiente controlado e fora do contexto real de projetos de desenvolvimento de software Esta abordagem pode reduzir os riscos e os custos n o abrangidos no mbito desta pesquisa neste momento Al m disso com base na defini o informal pr via das duas quest es desta pesquisa foi poss vel formalizar as duas hip teses e definir suas respectivas medidas de avalia o A primeira hip tese est relacionada com o esfor o dos gestores no planejamento das atividades e recursos para projetos de software Ent o a primeira hip tese nula Ho a seguinte o esfor o envolvido no planejamento das atividades do projeto de software usando o modelo integr
185. esso os objetivos dos projetos faz se necess rio gerenci los A ger ncia de projetos segundo Schwalbe SCHO2 respons vel pelo controle da realiza o dos objetivos do 31 projeto atrav s da aplica o de um conjunto de t cnicas e ferramentas A gest o conforme o Standish Group International SGI10 deve abranger o ciclo de vida completo de um projeto ou seja passando pelas fases de planejamento execu o e controle Para o Project Management Institute PMIO8 um projeto conclu do com sucesso quando as especifica es de escopo tempo e custo est o conforme o planejado Adicionalmente as organiza es que desenvolvem software est o inseridas em ambientes com multiprojetos onde as dificuldades encontradas em um nico projeto intensificam se ARAO9 Observa se desta forma que as dificuldades encontradas no gerenciamento de projetos de desenvolvimento de software est o diretamente relacionadas as caracter sticas intr nsecas do software Para o gerenciamento de projetos de software consequentemente a organiza o precisa de um modelo que descreva a complexidade do projeto envolvendo recursos tempo custos e objetivos Entretanto a maioria dos modelos ou guias voltados para a ger ncia de projetos tal como o Project Management Body of Knowledge Guide PMBOK n o se dirigem especificamente a processos de desenvolvimento de software Al m disso os processos de desenvolvimento de software por sua vez geralm
186. etodologia de ger ncia de projetos que permita lidar com diferentes vari veis de projeto responsabilidades e tarefas Para este fim existem diversas propostas na literatura ou pr ticas j realizadas nas empresas Entretanto a maioria dos modelos ou guias voltados para a ger ncia de projetos tal como o PMBOK Guide n o se dirigem especificamente a processos de desenvolvimento de software Al m disso apesar do processo de desenvolvimento de software ser considerado um dos principais mecanismos respons veis por gerenciar e controlar os projetos e produtos de software muitos destes processos existentes apresentam car ncias no quesito de ger ncia de projetos Tal fato refor ado por Henderson Sellers et al HENOO onde destacado que dois dos mais importantes processos de desenvolvimento de software respectivamente o RUP por sua absor o no mercado e o OPEN por sua contribui o no meio acad mico necessitam de maior suporte no quesito de gest o de projetos Tanto o RUP quanto o OPEN auxiliam na execu o das melhores pr ticas para o desenvolvimento de software No entanto o RUP por exemplo n o cobre assuntos essenciais de gest o de projetos tais como a ger ncia de pessoas e a ger ncia de contratos Em contraste o OPEN apresenta um conjunto de atividades e t cnicas que contemplam diferentes reas da ger ncia de projetos tais como qualidade estimativas de custos e m tricas de gerenciamento Todavia ambos os mo
187. etos de acordo com as modifica es que ocorrem durante seu ciclo de vida s o denominados nesta tese como sendoparte da reconfigura o din mica de projetos Este capitulo apresenta uma introdu o rea de estudo e tamb m traz algumas defini es assumidas no contexto desta pesquisa Em seguida s o apresentados os principais conceitos sobre a reconfigura o din mica no contexto de projetos de software 69 4 1 Programa o Din mica deSistemas A maioria dos sistemas inclusive os de software opera em ambientes din micos onde ocorrem geralmente imprevis veis e inevit veis eventos em tempo real Estes eventos podem causar uma mudan a na programa o dos planos de projeto de modo que um cronograma previamente vi vel pode se transformar em invi vel durante o desenvolvimento do projeto Exemplos de tais eventos em tempo real incluem falhas de hardware mau funcionamento de softwares altera es de data de entrega doen as de funcion rios entre outros MacCarthy e Liu MAC93 abordaram a natureza da lacuna entre a teoria e a pr tica de sobre a programa o de atividades o fracasso da teoria da programa o cl ssica para responder s necessidades de ambientes pr ticos e geis e as tend ncias nas pesquisassobre a programa o de atividades que procuram torn la mais relevante e aplic vel nas empresas Shukla e Chen SHU96 em sua pesquisa sobre o controle inteligente e em tempo real de sistemas flex veis de ma
188. execu o da ultima atividade do projeto Esta pesquisa prop e um novo mecanismo de mapeamento para resolver este problema Neste mecanismo uma atividade num projeto convertida em um lugar cronometrado e um evento convertido em uma transi o instant nea de modo que o mecanismo de rastreio das fichas pode ser omitido Caso contr rio um diagrama de rede de um projeto apenas mapeia uma rede de Petri no ambiente de um unico projeto Entretanto para o ambiente multiprojetos que consiste em diversos projetos executados ao mesmo tempo a convers o para redes de Petri ser extremamente complicada e resultar em um gr ficocomplexo Portanto o conceito de cores adotado nestapesquisa para converter os diagramas de rede de m ltiplos projetos em uma esp cie de TCPN onde projetos diferentes ser o representados por cores diferentes de modo que a complexidade eo tempo de modelagem podem ser reduzidos A Figura 18 mostra o contraste entre o diagrama de rede e a TCPN Eku Exy by pl h v la a Diagrama de redes b Diagrama de redes de Petri coloridas temporizadas Figura 18 Convers o do diagrama de redes para a TCPN Assim a TCPN gerada conforme os seguintes passos 1 Um evento Ee ser mapeado para uma transi o instant nea t que uma transi o sem dura o de tempo onde 1 2 M 2 Uma atividade A Ey Ey ser mapeada para um lugar colorido p Eu Ey cujas cores tamb m podem representar a
189. faz se necessario criar os elementos transitions e arcs correspondentes Caso exista uma rela o de preced ncia com outra atividade j mapeada Cria o elemento transition que representa a rela o de preced ncia entre as atividades Calcula o tempo de dura o desta transi o considerando os finais de semana e feriados Adiciona um elemento arc para conectar o elemento place que corresponde atividade dependente com o elemento transition Adiciona um elemento arc para conectar o elemento transition com o elemento place que corresponde a atividade predecessora Caso represente uma fase do projeto ou um agrupamento de tarefas Segue para a pr xima atividade do projeto Figura 67 Comportamento do componenteParserMSProject Para o cronograma ilustrado no Cen rio 1 o algoritmo executado pelo componente ParserMSProject gera uma rede de Petri contendo 9 lugares 8 transi es e 18 arcos vide Figura 68 Conforme mencionado anteriormente o projeto est em andamento e o gestor se deparou com o evento de sa da de um recurso no tempo 8 do cronograma 180 original vide Figura 56 Desta forma o componente ParserMSProjectconsidera apenas as atividades do cronograma a partir do tempo 8 neste exemplo simplificado apenas a atividade INP n o foi considerada na gera o da rede de Petri fa Pt o a a a a Na AMR T206 DAR TM2 MEBO T43 JAPOAPO INT Tei 1 RTE TH2 EMP DEVS TH Figura 68
190. file CompositeRole MethodContentUse e TaskUse Alem disso as metaclasses RoleUse e WorkProductUse que j haviam sido definidas no pacote ProcessStructure s o agora especializa es da nova metaclasse MethodContentUse 213 ensibleFlement e Core ih MethodContentPackage BreakdownElement A TeamProfile CompositeRole Figura 80 Taxonomida das metaclasses do pacote Process with Methods As principais rela es das metaclasses no pacote Process with Methods s o mostradas na Figura 81 Nesta Figura novamente percebe se que o elemento tarefa o elemento central A metaclasse TaskUse assume praticamente as mesmas rela es daquelas descritas no pacote MethodContent A grande diferen a nesse pacote que a nova metaclasse TaskUse assume rela es com elementos definidos no pacote ProcessStructure Al m disso relacionamentos novos s o estabelecidos no pacote Process with Methods Esses relacionamentos ligam os elementos TaskUse WorkProductUse e RoleUse respectivamente com os elementos TaskDefinition WorkProductDefinition e RoleDefinition do pacote Method Content Atrav s das rela es acima entre as metaclasses do tipo Use e Definition que um processo reutiliza os elementos definidos no MethodContent A id ia do metamodelo SPEM 2 0 que um reposit rio de conte do seja montado atrav s do pacote Method Content e que as estruturas dos processos de software tal como o fluxo d
191. finition ToolDefinition Qualification WorkProductDefinitionRelationship Default TaskDefinitionPerformer 212 Default_TaskDefinitionParameter e Default_ResponsabilityAssignment Ja a Figura 79 exibe como os elementos do pacote MethodContent se relacionam Basicamente a metaclasse TaskDefinition pode ser considerada como elemento central do pacote Essa metaclasse possui rela o com a metaclasse RoleDefinition atrav s das metaclasses Default TaskDefinitionPerformer Qualification rela o com a metaclasse WorkProductDefinition atrav s da metaclasse Default TaskDefinitionParameter rela o com a metaclasse ToolDefinition e rela o de composi o com a metaclasse Step Os outros relacionamentos desse pacote s o o auto relacionamento para a metaclasse WorkProductDefinition representado pela metaclasse WorkProductDefinitionRelationship e o relacionamento entre a metaclasse WorkProductDefinition e RoleDefinition estabelecido pela metaclasse Default ResponsabilityAssignment A 6 PACOTE PROCESS WITH METHODS O pacote Process with Methods liga os conceitos definidos no pacote ProcessStructure com os conceitos definidos no pacote Method Content Assim poss vel que processos de software sejam montados utilizando os conceitos pr definidos no Method Content Figura 80 mostra a taxonomia das metaclasses do pacote Process with Methods Nessa Figura poss vel observar que as novas metaclasses inclu das neste pacote sao TeamPro
192. forming systematic reviews Joint Technical Report Software Engineering Group Department of Computer Science Keele University 2004 33p KRUCHTEN P The Rational Unified Introduction Addison Wesley 2 edition 2000 KUMAR A GANESH L S Use of Petri nets for resource allocation in projects EEE Transaction on Engineering Management vol 45 1 1998 pp 49 56 LEE S SHIM J WU C A metal model approach using uml for task assignment policy in software process In Proceedings of the Ninth Asia Pacific Software Engineering Conference APSEC 2002 LEE B MILLER J Multi Project Management in Software Engineering Using Simulation Modelling Software Quality Journal vol 12 2004 pp 59 82 LEACH L P Critical Chain Project Management Artech House Publishers 2004 2a edi o 263p LEE J LEE N Least modification principle for case based reasoning a software project planning experience Expert Systems with Applications vol 30 2 2006 pp 190 202 LEON V J WU S D STORER R H Robustness measures and robust scheduling for job shops IIE Transactions vol 26 5 1994 pp 32 41 LEUS R HERROELEN W The complexity of machine scheduling for stability with a single disrupted job Operations Research Letters vol 33 2 2005 pp 151 156 LEYMANN F ROLLER D Production workflow concepts and techniques Upper Saddle River Prentice Hall 2000 LI
193. gradua o e p s gradua o da rea da Ci ncia da Computa o Ap s novas funcionalidades foram implementadas no prot tipo e um segundo estudo experimental foi realizado com trinta e seis alunos de cursos de p s gradua o em Gerenciamento de Projetos de duas institui es de ensino superior distintas Os resultados destes experimentos foram publicados em artigos ROS 13 ROS14 Ainda nesta etapa foi realizada a consolida o e a avalia o dos resultados obtidos Em seguida iniciou se um estudo aprofundado sobre o tema principal desta pesquisa Desta forma realizou se uma revis o sistem tica para identificar os requisitos necess rios para o desenvolvimento de uma solu o computacional que permita a reconfigura o din mica da programa o de projetos de software considerando m ltiplos projetos simult neos e a sua integra o com os demais fluxos organizacionais Os resultados desta revis o sistem tica foram publicados em um artigo ROS 12a Ainda objetivou se ampliar o estudo sobre a formaliza o e defini o dos tipos de eventos que podem afetar uma configura o de projeto de software Desse estudo produziu se um modelo computacional sobre a reconfigura o din mica de projetos de software Desta forma objetivou se desenvolver uma estrat gia para a reconfigura o din mica de projetos de software de maneira a ajustar o sequenciamento das atividades dos projetos considerando um conjunto de restri es sobr
194. hes da Revisao Sistematica Ap s a defini o da QF os pr ximos passos s o respectivamente a sele o das fontes de pesquisa a defini o de crit rios de inclus o e exclus o e a sele o dos estudos encontrados Quando esse planejamento for conclu do deve se avaliar o plano de protocolo da revis o sistem tica Se for aprovado a extra o de informa es deve come ar ver Figura 14 Os resultados tamb m devem ser avaliados antes de se realizar a an lise final A fim de manter todas as informa es e documentar as decis es dos pesquisadores deve se fazer o armazenamento dos resultados ao longo deste processo protocolo nao aprovado execu o n o aprovada Y Planei os Analise dos protocolo aprovado execu o aprovada Figura 14 Processo de revis o sistem tica adaptado de BIO05 Esta revis o sistem tica utilizou os motores de busca a seguir IEEE Xplorer digital library ACM digital library Springer Link and Science Direct Os crit rios para tomar a decis o sobre o motor de busca selecionado foram 1 O banco de dados permite motores de busca baseados em palavras chave e express es booleanas e 2 A disponibilidade de artigos atrav s da Internet Uma primeira sele o dos trabalhos ocorreu entre mar o e maio de 2011 cujos resultados foram publicados em ROS12a A popula o definida para esta revis o inclui artigos publicados em revistas e confer ncias sobre o campo de estudo des
195. ho do cronograma o atraso dos trabalhos 4 1 2 Reprograma o das Atividades na Presen a de Eventos em Tempo Real A reprograma o das atividades do projeto na presen a de eventos em tempo real aborda duas quest es como e quando reagir a eventos em tempo real A primeira quest o diz respeito defini o de estrat gias de reescalonamento para reagir a eventos em tempo real e a segunda quest o aborda o problema de quando reagendar 4 1 2 1 Estrat gias de Reprograma o das Atividades Em rela o primeira quest o quais estrat gias utilizar para reprogramar as atividades do projeto a literatura fornece duas estrat gias principais de reescalonamento SABOO COWO02 VIEO3 o reparo ajuste da programa o e o reescalonamento completo O reparo na programa o se refere a algum pequeno ajuste da programa o atual A reprograma o completa entretanto gera uma nova programa o das atividades a partir do zero A reprograma o completa pode em princ pio gerar as melhores solu es mas essas solu es s o raramente poss veis serem implementadas na pr tica uma vez que existem diversas vari veis envolvidas Al m disso a reprograma o completa pode resultar em instabilidade e falta de continuidade do cronograma levando a produ o adicional de custos imput veis ao nervosismo da equipe 73 Sun e Xue SUNO1 e Dorn et al DOR95 relataram que a maioria dos sistemas de programa o reativa tentar
196. i o considere que a unidade de tempo u t que comp e a tarefa receba um valor padr o de custo no valor de 100 00 Logo uma tarefa com a dura o de quatro u t e duas posi es de trabalho teria um custo total para o projeto dada pela express o em 3 CAL10 4x2x 100 00 800 00 3 Callegari CAL10 desta forma sugere que a medida que os recursos preencherem essas posi es o custo total da tarefa deva ser decrementado Assim caso os recursos candidatos a ocuparem as posi es corresponderem exatamente ao perfil pretendido o custo da tarefa se aproximar de zero Uma vez esclarecidos os elementos presentes na f rmula sugerida por Callegari CAL10 e a id ia para o procedimento de c lculo apresenta se na Figura 33 a composi o da f rmula padr o deste modelo de refer ncia para reconfigura o din mica de projetos de desenvolvimento de software ValorFinal ValorInicial Descontos Penalidade sendo que ValorInicial CustoPadr oDe Uma UnidadeDeTempo X Dura oDaTarefa i l Descontos DuracdoDa hrefax ba F xE n n n mero de elementos E neste caso n 4 F fator de importancia relativa para o elemento i E valor normalizado calculado para o elemento i Penalidade F X StartupPenalty recurso posi o F fator de import ncia para a penalidade Figura 33 Composi o da f rmula padr o do modelo de refer ncia para reconfigura o din mica de projetos de desenvolvimento de software
197. i Doutor Professor da Faculdade de Inform tica da PUCRS E mail daniel callegari pucrs br http lattes cnpg br 566 7898309290802 Figura 87 Tela sobre de apresenta o da equipe de pesquisadores C 3 APRESENTA O DA PALESTRA A Figura 88 apresenta a p gina que cont m informa es sobre como realizar a inscri o na palestra e posterior estudo experimental sobre o modelo integrado SPIM Inscri o para a Palestra sobre o mopelo SPIM Palestrante Maur cio Covolan Rosito doutorando em Ci ncia da Computa o da PUCRS Data 26 10 2011 das 08 50hrs at s 12 00hrs Local Laborat rio 411 do Pr dio da Faculdade de Inform tica da PUCRS Porto Alegre RS P blico Alvo Alunos de p s gradua o da PUCRS Lota o At 30 participantes Motiva o Projetos de software s o muito din micos e demandam recorrentes ajustes dos seus planos de projeto Esses ajustes podem ser vistos como reconfigura es no cronograma de tarefas na atribui o de recursos e de outros elementos do projeto Ainda durante o planejamento e execu o de um projeto de software deve se considerar a integra o das atividades espec ficas dos projetos com as atividades que fazem parte de um fluxo de atividades comum organiza o Neste sentido est sendo proposto um modelo computacional para o suporte a reconfigura o din mica de projetos de software em ambientes multiprojetos considerando o planejamento e o replanejamento de suas
198. i Tool Mentor Figura 39 Tela do BackOffice O m dulo de BackOffice oferece duas formas de exportar as informa es contidas em seu banco de dados para o Microsoft Project a atrav s de modelos de projeto e 130 b atraves individuais campos personalizados As informa es necess rias para executar a valida o de acordo com as restri es impostas pelo modelo integrado SPIM devem estar em campos personalizados do Microsoft Project Uma maneira de exportar informa es do SPIT para a ferramenta comercial realizado atrav s de um modelo de projeto Assim um conjunto de tarefas e as suas associa es ser o exportados para o software comercial de uma s vez Tamb m poss vel selecionar individualmente os campos personalizados que ser o exportados para um projeto espec fico Assim o m dulo de BackOffice permite exportar informa es sobre os pap is produtos de trabalho processos gerenciais do PMBOK guias e fluxos de trabalho do RUP e do OPEN 6 3 3 Workflow Integrator O m dulo Workflow Integrator respons vel por sincronizar as informa es contidas nos fluxos de trabalho organizacionais com as atividades contidas em um projeto de software espec fico Atualmente diferentes tecnologias e solu es podem ser encontradas para o desenvolvimento de fluxos de trabalho O Windows Workflow Foundation WWF fornece o Visual Studio Workflow Designer 2010 que permite aos usu rios criar seus pr prios fluxos de trabalho
199. ia o das mesmas A partir disso algumas propostas s o implementadas e outras descartadas Com base nessa implementa o alguns recursos podem ser realocados ou tarefas podem ser reprogramadas Callegari CAL10 salienta que para algumas situa es a implementa o de uma proposta pode incidir na gera o de novos eventos no modelo fato que ocasiona o in cio de um novo ciclo de execu o para buscar novas alternativas de solu o Outro conceito importante que envolve o modelo est relacionado proposta do recurso para ser alocado s tarefas componentes de um projeto Esta proposta calculada atrav s de uma f rmula inclu da no modelo de reconfigura o CAL10 cujo objetivo estabelecer um par metro num rico que traduza as decis es na realoca o dos recursos A assinatura de fun o para a f rmula presente no modelo dada pela express o em 2 CAL10 Valor Proposto Fun o recurso posi o de trabalho dura o proposta 2 A assinatura informa que a proposta calculada em fun o do recurso proponente da posi o de trabalho e da dura o estimada para execu o da tarefa sob a tica de uma representa o de custos onde quanto menor for o custo calculado melhor a 115 proposta O procedimento de calculo das propostas e fazer que as ofertas dos recursos decres am o valor de uma tarefa de forma proporcional as caracter sticas individuais de cada recurso fim de exemplificar tal propos
200. ias para a simula o s o mantidas Por exemplo as informa es gr ficas posicionamento e tamanho foram eliminadas Com base nestes crit rios o modelo de representa o da RdP para o m dulo Simulator foi desenvolvido considerando a utiliza o de tabelas de dispers o do ingl s hash A tabela hash uma estrutura de dados que associa chaves de pesquisa a valores As tabelas hashing s o estruturas de dados que t m alto desempenho na realiza o de buscas pois utilizam um algoritmo de codifica o que permite que os dados sejam encontrados rapidamente independente da quantidade de dados armazenados algoritmo de complexidade constante ou 0 1 A sua vantagem com rela o s outras estruturas associativas como um vetor simples passa a ser maior conforme a quantidade de dados aumenta Uma rede de Petri cont m informa es sobre s o os seus lugares transi es e arcos Estas informa es entretanto representam excessiva redund ncia sob o ponto de vista da simula o Observa se que toda a estrutura da rede pode ser recuperada a partir 145 de seu conjunto de arcos Cabe relembrar que os arcos sao um conjunto de pares origem destino Desta forma o conjunto de arcos foi dividido em dois conjuntos menores um contendo apenas os arcos que tem os lugares como ponto de origem e outro contendo os arcos que tem as transi es como ponto de origem Para que a RdP seja obtida faz se necess rio seguir os passos a seguir
201. ias para a vari vel esfor o Vari vel Crit rio Signific ncia Esfor o Vari ncias iguais 0 271 Variancias diferentes 0 271 De acordo com os resultados da Tabela 10 a signific ncia p value do teste de Levene 0 271 Se este valor for igual ou inferior ao nivel de signific ncia a para o teste neste caso 0 05 ent o a hip tese nula cuja variabilidade dos dois grupos igual pode ser rejeitada o que implica que as vari ncias s o diferentes Se o p value maior do que o nivel a ent o vari ncias iguais s o assumidas Neste caso 0 2 1 maior do que a de modo que se assumiu que as vari ncias s o iguais Uma vez que se identificou que a distribui o era normal e as vari ncias eram iguais foi aplicado o teste T ver resultados da Tabela 11 O teste T para amostras independentes pode ser usado para identificar se duas m dias s o diferentes uma do outra quando as duas amostras as quais as m dias foram calculadas s o compostas de diferentes indiv duos 163 Tabela 11 Teste T para a vari vel esfor o Variavel Criterio T Grau de Significancia Liberdade 2 tailed Esfor o Vari ncias iguais 1 511 34 0 140 Variancias diferentes 1 511 32 699 0 140 Este um teste chamado two sided test em que o valor de p 0 140 diretamente comparado com a 0 05 nivel de signific ncia Uma vez que p value 0 140 gt 0 05 Ho n o rejeitada Assim n o h nenhuma evid ncia estat stica para rejei o da hip
202. iatamente frente a um evento inesperado para que se restabele a o 86 andamento dos projetos o mais rapido poss vel ainda que vari veis de longo prazo possam estar presentes 4 3 Revis o Sistem tica sobre a Reconfigura o Din mica de Projetos de Software Ap s v rios estudos preliminares na literatura para identifica o de pesquisas relacionadas foi realizada uma revis o sistem tica sobre a reconfigura o din mica de projetos de software um resumo do protocolo de pesquisa pode ser encontrado no Ap ndice B A revis o sistem tica uma metodologia de pesquisa que usa m todos sistem ticos para identificar selecionar e avaliar criticamente os estudos cient ficos em um campo espec fico de investiga o uma revis o planejada para responder a uma pergunta espec fica que pode ou n o incluir m todos estat sticos M todos estat sticos utilizados na an lise e sintese dos estudos selecionados s o chamados de meta an lise HIGO8 A revis o sistem tica uma forma de avaliar e interpretar o trabalho relevante para uma quest o de pesquisa espec fica KIT04 BI OS Resumidamente em uma revis o sistem tica realiza se uma busca de informa es relevantes pesquisa definindo palavras de pesquisa search strings a serem executadas em mecanismos de pesquisa tais como os fornecidos pela IEEE e ACM Esta informa o geralmente relatada atrav s de artigos em anais de congressos revistas e relat r
203. icos internacionais B 2 3 Identifica o das Fontes M todo de pesquisa das fontes atrav s dos mecanismos de busca pr prios do IEEE Xplore ACM Digital Library SpringerLink e Science Direct String de busca project management OR scheduling AND business process OR workflow AND managerial activity OR enterprise activity OR organizational activity OR productive activity AND year gt 2000 AND year lt 2011 Lista de fontes vide Tabela 6do Cap tulo 4 219 B 2 4 Sele o das Fontes ap s Avalia o Todas as fontes foram aprovadas pelo doutorando e pelo seu orientador B 2 5 Verifica o de Refer ncias Todas as fontes selecionadas foram aprovadas B 1 3 SELE O DOS ESTUDOS B 1 3 1 Defini o dos Estudos Crit rios de inclus o e exclus o de estudos foram desconsiderados os estudos e C1 Que n o estavam no formato de artigo completo full paper e C2 Cujo conte do n o estava relacionado a rea de reconfigura o de projetos e C3 Trabalhos que citem import ncia da reconfigura o de projetos mas que n o possuam nenhum tipo de solu o para isto Defini o do tipo de estudo foram removidos estudos do tipo roadmaps trabalhos que indicam os desafios e as dire es a serem tomadas em uma rea de pesquisa Procedimentos para a sele o de estudos execu o da string de busca nos mecanismos de busca oferecidos em cada uma das fontes selecionadas A an lise da sele o dos es
204. imento os resultados s o analisados interpretados apresentados e empacotados Nesta pesquisa foram realizados dois tipos distintos de avalia es do modelo O primeiro tipo de avalia o escolhido foi a utiliza o de um m todo formal de experimento Este primeiro tipo de avalia o teve como prop sito de verificar se o modelo SPIM atende as car ncias de integra o identificadas no item 3 2 Necessidade de Integra o ou seja 1 Acesso s informa es pertencentes aos outros departamentos da organiza o 2 ldentificagao das rela es de depend ncia entre as atividades dos fluxos 151 organizacionais e dos projetos de software 3 Capacidade de minimizar distor es no planejamento de projetos tais como o aumento dos custos e atrasos nos prazos do projeto e 4 Aux lio na identifica o e mensura o dos custos indiretos do projeto Desta forma um primeiro estudo experimental usando o modelo SPIM foi conduzido por seis estudantes de gradua o e quatro de p s gradua o de cursos da rea da Ci ncia da Computa o os resultados foram publicados em ROS12d Este primeiro experimento revela que a abordagem proposta pelo modelo SPIM fornece um mecanismo ao gestor para criar e realizar um plano de projeto mais preciso do que o m todo tradicional No entanto foram observadas algumas limita es nesta primeira experi ncia tais como a utiliza o de estudantes de gradua o Desta forma a pesquisa avan o
205. imento deve ser realizado vide Ap ndiceD Este plano decide quais vari veis devem ser examinadas quais dados devem ser coletados quantos 152 experimentos devem ser conduzidos e quantas vezes os experimentos devem ser repetidos Na fase de execu o os experimentos s o executados como indicado pelo modelo de design selecionado Uma vez que os experimentos foram realizados os dados coletados durante os experimentos devem ser analisados Esta an lise visa encontrar rela es entre os resultados do estudo Cada atividade principal do experimento apresentada nas se es seguintes 7 1 1 1 Defini o dos Objetivos do Experimento Esta atividade corresponde defini o das hip teses e objetivos a serem alcan ados quanto solu o do problema A t cnica Goal Question Metric GQM SOL99 foi utilizada neste estudo estabelecendo o objetivo geral e a forma de medi o dos dados Seguindo esta abordagem foi decidido que o objetivo desta pesquisa comparar conforme o RUP a precis o e o esfor o usando o modelo de planejamento integrado SPIM em compara o com o modelo tradicional de planejamento de projeto de software Uma vez definido o objetivo principal o passo seguinte definir as m tricas b sicas que podem representar o valor das entradas e os resultados deste experimento De acordo com a t cnica GQM duas quest es foram identificadas 1 O esfor o para realizar o planejamento das atividades do projeto de s
206. ionados ao trabalho mudan a na prioridade da tarefa cancelamento de tarefas devido a altera es de data das tarefas etc Nesta pesquisa a programa o din mica foi definida em tr s categorias MEH99 VIE0O0a AY TOS HEROS programa o completamente reativa programa o preditiva reativa e programa o pr ativa robusta 4 1 1 1 Programa o Completamente Reativa Na programa o completamente reativa nenhuma programa o do projeto gerada com anteced ncia e as decis es s o tomadas em tempo real Neste modelo s o adotadas regras relacionadas prioriza o de atividades A prioridade de uma atividade determinada com base em diferentes vari veis modelo de desenvolvimento de software tamanho da equipe restri es relacionadas ao tempo e ao custo etc A implementa o da programa o reativa geralmente intuitiva e f cil de se implementar em projetos de software No entanto neste modelo pode ser dif cil para o gerente prever o desempenho global do projeto uma vez que as decis es s o tomadas somente em tempo real 4 1 1 2 Programa o Preditiva Reativa A programa o preditiva reativa a abordagem de programa o din mica de atividades mais utilizada em sistemas de software A maioria das defini es descritas na literatura sobre programa o din mica refere se programa o preditiva reativa Este um processo de programa o e reprograma o do projeto em que as atividades s o
207. ios t cnicos ou mesmo em livros dedicados a cada rea de pesquisa As vantagens de uma revis o sistem tica podem ser resumidas como se segue e Agrupar as evid ncias existentes sobre um determinado assunto na literatura e Identificar as eventuais lacunas que podem apontar para futuras pesquisas e Fornecer uma vis o consistente para propor novas atividades de investiga o A revis o sistem tica fornece um rigor cient fico a um processo de revis o da literatura e como consequ ncia minimiza problemas que podem acontecer durante uma revis o da literatura convencional As diretrizes para conduzir o processo de revis o sistem tica estabelecidas por Biolchini et al BIOOS e Kitchenham KITO4 foram adaptadas de modo a refletir os problemas espec ficos da pesquisa em Engenharia de Software Essas diretrizes s o compostas por tr s fases planejamento da revis o a realiza o da revis o e relato da revis o 8 4 3 1 Planejamento da Revis o Sistem tica Primeiramente uma revis o sistem tica deve come ar com a defini o da quest o de pesquisa Neste trabalho adotamos o termo pergunta foco Question Focus QF como forma de representar a pergunta da pesquisa vide Ap ndiceD Para determinar a QF algumas quest es complementares foram utilizadas As pr ximas subse es resumem a sequ ncia de passos que foram estabelecidas por Biolchini et al BIOO5 e Kitchenham KIT04 Em seguida a terceira fase rep
208. iretos do projeto Cabe refor ar que o SPIT cont m um m dulo chamado SPIM Validator que funciona como um add in da ferramenta comercial Microsoft Project O SPIM Validator respons vel por verificar se o projeto est de acordo com as restri es definidas pelo modelo integrado SPIM Dessa forma a interface de manuten o de projetos do m dulo de BackOffice do SPIT permite associar um projeto cadastrado na base de dados do prot tipo SPIT com o arquivo utilizado por esta ferramenta comercial Esta associa o permite que as informa es adicionais propostas pelo SPIM sejam exportadas para campos customizados da ferramenta comercial de ger ncia de projetos lt Manuten o do Projeto tegrad od Register Export to MS Project Import from M5 Project Help Companies us Programs e Projects Process Groups Desenvolvimento de um software fict cio Knowledge Areas i Project Phase Tasks Roles Work Products a Guidance Task Groups Objetivos Permitir ao leitor maior entendimento do SPIT Disciplines Project Workflow Tool Mentor Custos Ind 5 10 000 00 Arquivo lustrar as funcionalidades do SPIT D Projeto1 mpp ee Ai Export to MS Project Register Figura 59 Interface de cadastro de projetos do BackOffice 175 Conforme observado na Tabela 16 esta reune os recursos e os pap is em que cada integrante do projeto pode assumir Os pap is adotados pela organiza o em seus projetos de softwar
209. ise dos documentos de ERS e Vis o 2 dias 14 Colocar Artefatos sob Rastreabilidade 1 dia 15 Teste da Arquitetura 1 dia 16 Finalizar Vers o 1 dia 17 Constru o 6 dias 16 Arquitetura 3 dias 19 Defini o do processo de implanta o 1 dia 20 Modelar Banco de Dados 2 dias 21 Especifica o de Requisitos 3 dias a2 Desenvolvimento 2 dias 23 Finalizar fase de constru o 1 dia 24 Transi o 2 dias Pi Fechar Projeto 2 dias 26 Reuni o para Encerrar Projeto 1 dia Ini ic io 15 11 2011 15 11 2011 15 11 2011 1511 2011 16 11 2011 21 11 2011 2411 2011 24 11 2014 24 91 2011 24 11 2011 25 11 2011 29 11 2011 2611 2011 29 11 2011 30 11 2011 0512 2011 061 2 2011 061 2 2011 06 12 2011 072 2011 09 2 2011 0512 2011 1312 2011 14 12 2011 14 12 2011 1412 2011 T rmi 15 12 2011 23 11 2014 23 11 2014 15 11 2014 18 11 2011 22 11 2011 23 11 2011 05 12 2011 24 11 2011 24 11 2011 05 12 2011 02 12 2011 28 11 2011 29 11 2011 30 11 2011 05 12 2011 13 12 2011 08 12 2011 06 12 2011 08 12 2011 13 12 2011 12 12 2011 13 12 2011 15 12 2014 15 12 2014 14 12 2011 Figura 96 Projeto para o cen rio 2 Predecessoras Nomes dos recursos Fulanoi 4 Fulanoi 5 Fulano 6 T Fulano 10 Fulano3 10 Fulano4 13 Fulano3 14 FulanoS 12 15 8 Fulano6 19 Fulano 20 Fulanod Ze Zo Fulano 242 E 3 CEN RIO 3 Veja abaixo a descri o das atividades propostas para o cen rio 3 Cen rio 3 Participante Test
210. ividade 6 Atividade 7 Modelo de Reconfigura o Avalia o Atividade 5 Reconfiguracdo Din mica Defini o do Modelo de Reconfigura o Din mica para Projetos de Software Conceitos PERT CPM etc Revis o sistem tica sobre reconfigura o din mica Identifica o dos evento que afetam projetos Atualiza o do SPIT Avalia o Reda o final da Tese Figura 1 Atividades da pesquisa A se o seguinte explica como o texto desta tese de doutorado est organizado 1 4 Organiza o do Texto O texto desta tese est estruturado da seguinte forma o Cap tulo 2 apresenta uma caracteriza o da rea de estudo destacando os termos e defini es utilizados no decorrer do texto O Cap tulo 3 comenta sobre os modelos de refer ncia que foram usados como base para a elabora o do modelo de reconfigura o Os modelos de refer ncia foram comparados e combinados em um modelo integrado Um estudo sobre a reconfigura o din mica de projetos resultado de uma revis o sistem tica apresentado no Cap tulo 4 26 enquanto que o Capitulo 5 apresenta o estudo realizado sobre a utiliza o de redes de Petri na gestao de projetos O Capitulo 6 apresenta o modelo de refer ncia elaborado para reconfigura o din mica propriamente dito al m do prot tipo desenvolvido A avalia o do modelo de reconfigura o comentada no Cap tulo 7 onde tamb m s o detalhados os cen rios usados para a ger
211. jectives lt lt abstract gt gt Role ANBSIndex ene directCost MZ description 0 as RE definition 4 lt lt abstract gt gt isBaseline lt WorkProductType BaselineDate consults B gt creates gt name description Work Product Version startDate Task percentage finishDate isExternal version duration name isCustDeliverable comments description E ProductiveWorkProduct o ProductiveWorProductType 7 Ss name name LL description lt 4 is documented using description Ee __ ees StageWithDuration is timeboxed using DateFinish DateStart 1 Order 1 EEE o name provides ways of performing P description description produces related lt lt abstract gt gt 2 E 5 Endeavor OrganizationTeam EEE x a LR name ProductiveActivity description TER A produces individual Figura 12 Metamodelo de integra o PMBOK OPEN ROS 12b 62 Segundo Firesmith e Henderson Sellers FIRO2 as unidades de trabalho classe WorkUnit modelam as opera es coesas que s o executadas pelos produtores durante o processo de entrega do projeto Estas s o classificadas como tarefas t cnicas fluxos de trabalho e atividades A classe Discipline representa um conjunto de atividades produtivas que possuem um objetivo comum A disciplina produz um conjunto de um ou mais produtos d
212. jeto e entrar em outro se caracteriza como a pr pria defini o de transfer ncia de recursos entre projetos A suspens o tempor ria de um recurso evento ER4 pode ocorrer por motivos como per odo de f rias alguma doen a ou outro motivo similar O evento ER5 refere se s situa es em que um recurso modifica as suas habilidades ou compet ncias Isso tipicamente ocorre quando o recurso recebeu algum treinamento ou ainda quando se verifica que seu conhecimento insuficiente para uma dada tarefa em consequ ncia da diminui o de algum grau de suas caracter sticas Altera o dos pap is de um recurso pode ocorrem em projetos onde a equipe pode desempenhar mais de um papel por exemplo quando uma pessoa desempenha os pap is de analista e desenvolvedor em um mesmo projeto Na Tabela 3 encontram se os eventos que se referem s atividades dos projetos Os eventos EA1 e EA2 s o os mais t picos de qualquer esp cie de projeto pois envolvem estimativas de tempo A especifica o de um novo prazo ou ainda a altera o da composi o dos recursos dos pap is ou das compet ncias necess rias foram mapeadas como o evento EA3 Por fim remover uma atividade ou acrescentar uma nova atividade a um projeto s o eventos distintos e foram identificados como EA4 e EAS respectivamente Ambos os eventos modificam a rede de atividades do projeto incluindo as depend ncias entre as atividades Dessa forma todo o subconjunto de atividades afet
213. lace id r tulo do lugar gt e lt place gt S o OS primeiros componentes analisados pois pela identifica o do valor dos seus nomes encontrado dentro das etiquetas lt value gt e lt value gt poss vel computar as atividades que far o parte da WBS do projeto de software Na Figura 47 ilustrado o trecho do c digo PNML que descreve os lugares da RdP apresentada naFigura 46 Observa se que os lugares Reuni o de In cio do Projeto Elaborar documento de requisitos e Definir Arquitetura representam as atividades do projeto pois os valores atribu dos a esses lugares representam o tempo de execu o destas 1 unidade de tempo para a primeira atividade 3unidades de tempo para a segunda atividade e 2 unidades de tempo para a terceira atividade O n mero atividades calculado dessa forma de acordo com a quantidade de lugares existentes no modelo da RdP As informa es contidas na tag lt graphics gt s o utilizadas para representar graficamente estes objetos informando sua posi o e dimens o na tela 140 lt place id pi gt lt name gt lt text gt Reunia o de Inicio do Projeto lt text gt lt value gt 1 lt value gt lt name gt lt graphics gt lt position x 100 y 100 gt lt dimension x 30 y 30 gt lt qraphics gt lt place gt lt place id p2 gt lt name gt lt text gt Elaborar documento de requisitos lt text gt lt value gt 3 lt value gt lt nam
214. lasse Role durante a execu o das atividades do projeto Assim para cada associa o entre um papel e uma atividade representado pela classe associativa ActivityStakeholderWork deve haver tamb m uma associa o dessa atividade com um stakeholder capaz de desempenhar aquele papel Al m disso como o conceito de pap is classe Role aparece em ambos os modelos estes foram divididos em pap is gerenciais classe ManagerialRole e pap is produtivos classe ProductiveRole tal como ocorreu com as atividades Cabe ressaltar que os conceitos de ger ncia de projetos que existem no RUP foram atribu dos ao pacote gerencial neste caso o PMBOK a fim permitir uma distin o expl cita entre os conceitos produtivos e gerenciais Por exemplo no RUP um papel interage com ambas as tarefas gerenciais e produtivas mas no metamodelo integrado foram definidas anteriormente as classes especializadas ProductiveRole pacote RUP e ManagerialRole pacote PMBOK Assim a classe Role pertence ao pacote comum Considerando que uma atividade pode ser derivada em atividade gerencial classe ManagerialActivity ou produtiva classe ProductiveActivity foi necess rio duplicar o relacionamento que existia entre as classes Role e Acticity denominado responsible de maneira a respeitar a divis o entre ger ncia de projetos e desenvolvimento de software que est sendo proposta nesta pesquisa Em rela o ger ncia de projetos o PMBOK Guide representa suas pr
215. lemas que trabalham em conjunto para resolver problemas que est o al m de suas capacidades individuais OHA96 A utiliza o de sistemas multiagentes para resolver o problema de programa o din mica motivada pelos seguintes pontos chave PAR96 PAROO SHE99 COWOO BREO1 SHEO1 Estes sistemas s o compostos de agentes aut nomos ligados a cada entidade de f sica ou funcional na empresa tais como recursos atividades e pessoas A autonomia local permite que os agentes assumam a responsabilidade de realizar a programa o local para uma ou mais entidades e de responder localmente e eficientemente a varia es locais aumentando a solidez e flexibilidade do sistema Em segundo lugar estes agentes individuais t m liberdade consider vel para responder as condi es locais para interagir e cooperar uns com os outros a fim de alcan ar programa es globais ideais Al m disso poss vel integrar novos recursos ou remover os j existentes com seus agentes ligados ao da empresa A solu o proposta nesta tese de doutorado est associada solu o proposta na disserta o de Schlosser SCH10 Nesta disserta o a autora apresenta uma arquitetura baseada em sistemas multiagentes em resposta aos eventos din micos dos projetos onde os agentes componentes da solu o utilizam o protocolo de rede de contratos SMI80 para coordenar o processo de gera o de propostas Esta pesquisa tem como foco a programa o das agendas in
216. lenges of research in this field To reach this goal a methodology of systematic review was adopted However according to the analysis of the results even the most recent studies did not present a solution that addresses all the problems of dynamic reconfiguration at the same time In order to contribute to the solution of the noted difficulties this thesis presents a computational model for dynamic reconfiguration of software projects at runtime with specific focus on the integration of project activities with activities that are part of the organizational workflows A software tool was developed to demonstrate and evaluate the results of an experimental study withpostgraduate students of project management Moreover this model considers the possibility to simulate software projects scenarios using Petri nets in response to events of project reconfiguration Keywords Dynamic Reconfiguration Organizational Workflows Software Project Management Systematic Review Experimental Study LISTA DE FIGURAS Figura 1 Atividades da DCSOUIS Biss discs since Lonswouis tecdsinniatneiaiasaionduantedaadsosatonsveonsSetevedsendevanmiontnnntaas 25 Figura 2 Metamodelo de ger ncia de projetos baseado no PMBOK Guide CALO 7 34 Figura 3 Vis o geral da arquitetura do RUP JACO1 e ren 36 Figura 4 Modelo sem ntico do RUP PEPOO err 38 Figura 5 Relacionamento entre atividades tarefas e t cnicas OPEOD
217. lia o Revis o 2 dias T Organizar e Conduzir a Reuni o de Kick Off 1 dia B Elaborar e Revisar Caso de Desenvolvimento 3 dias 9 Revis o de estimativas 3 dias 10 Estimar Custos e Recursos Z dias 11 Elabora o 7 dias 12 Revis o do Plano de Projeto 5 dias 13 Refinar Planejamento do Projeto 5 dias 14 Area de Engenharia 6 dias 15 Definir Arquitetura 3 dias 16 Analise dos documentos de ERS e Vis o Ambienta o no projeto 3 dias 17 Colocar Artefatos sob Rastreabilidade 2 dias 18 Teste da Arquitetura 3 dias 19 Revisar Projeto e Aprova es 1 dia 20 Conduzir Reuni o de Avalia o Revis o 1 dia 21 Constru o 10 25 dias ae Arquitetura 3 dias 23 Defini o do processo de implementa o 1 dia 24 Modelar Banco de Dados 2 dias do Especifica o Requisitos Release 1 0 T dias 26 RNF6 Front End em Ingl s DSW 2 dias af RNF amp Constru o do Front End ETR 4 dias 20 RF227 Manter Perfis ERR 3 dias 29 Especificar Teste 2 dias 0 Flahnrar Fenerifirar n de Plann de Teste flniriar o e Flahnrar ni 7 dias Figura 95 Projeto para o cen rio 1 E 2 CENARIO 2 Veja abaixo a descri o das atividades propostas para o cen rio 2 Cen rio 2 Participante Teste Usu rio Download Clique aqui para fazer download do cen rio 2 Gloss rio Fluxos Organizacionais RH Contratar Fluxo Organizacional respons vel pela contrata o de pessoas RH Treinamento Fluxo Organizacional respons vel pelas ati
218. lo Conforme mencionado anteriormente este estudo inicial permitiu o desenvolvimento da metodologia adotada para a integra o de modelos de gest o de projetos com modelos de processos de desenvolvimento de software Desta forma 10 novas regras foram adicionadas quelas desenvolvidas previamente cujos resultados foram publicados em ROS12b Estas restri es n o puderam ser expressas atrav s de diagramas devido s limita es na expressividade do diagrama de classes UML Desta forma aTabela 8 mostra o conjunto de restri es que foram definidas para o modelo integrado SPIM Estas informa es extras propostas pelo SPIM s o armazenadas em um banco de dados externo O m dulo SPIM Validator foi atualizado para acessar um banco de dados Microsoft SQL Server 2008 Express DEWOS atrav s de stored procedures devido sua seguran a e manutenabilidade Tabela 8 Conjunto de restri es do modelo integrado SPIM Restri es do modelo integrado SPIM 1 Um programa deve possuir um diretor Logo um stakeholder que diretor de um programa deve possuir um papel gerencial 2 Um projeto deve ter apenas um stakeholderchave ou seja um recurso respons vel por direcionar e fundamentar o projeto atributo isKeyStakeholder da classe ProjectStakeholder 3 Uma fase n o pode ter ela mesma como predecessora ou antecessora 4 As fases do projeto n o podem ocorrer em paralelo de maneira que uma fase deve ser totalmente finalizada antes de
219. luxo organizacional tenha aten o para que tenha exatamente o mesmo nome definido na tabela acima Ative o filtro listado abaixo e fa a a valida o do projeto Associa o com os Fluxos Organizacionais Salve o arquivo com o nome Cen rio5 SeuNome Respostas S Resposta al Arquivo m saver Veja abaixo uma parte do projeto a ser avaliado no cen rio 5 246 g Nome da tarefa Dura o Inicio T rmino Predecessoras Nomes dos recursos 15 LJ Arquitetura 3 dias 10 10 2044 42 40 2044 16 Defini o do processo de implementa o 1 dia 10 10 2011 1071072011 13 Fulano 2 17 Modelar Banco de Dados 2 dias 11710 2011 1240 2011 16 Fulano 5 18 Especifica o Requisitos Release 1 0 T dias 1310 2041 2110 2011 19 RNF6 Front End em Ingl s DSW 3 dias 1310 2011 171002011 17 Fulano amp 20 RNF8 Constru o do Front End ETR 4 dias 1310 2011 1810 2011 17 Fulano 4 21 RF227 Manter Perfis ERR 3 dias 1810 2011 2010 2011 19 Fulano 3 ae RF259 Cadastro de Pessoas 2 dias 19 10 2011 20 10 2011 20 Fulano amp ao RF300 Pesquisar Produtos 2 dias 19 10 2011 20 10 2011 20 Fulano 4 24 RF312 Implementar Carrinho de Compras 3 dias 131072011 1771072011 17 Fulano 9 Pica RF317 Integrar com sistema de cart o de 2 dias 18 10 2011 1971072011 24 Fulano amp 26 RrF32Z7 Finalizar compra 1 dia 21 10 2011 217102011 21525 Fulano 3 ar Especificar Teste 2 dias 41 10 2011 12 10 2014 26 Elaborar Especifica o de Plano de Teste
220. m descri es textuais e tamb m que se utilizem do conceito de Se o Observa se tamb m que a metaclasse ProcessElement definida no pacote ProcessStrucure aparece como uma especializa o da metaclasse DescribableElement Atrav s dessa rela o que os elementos do pacote ProcessStructure podem possuir descri es textuais 210 deseripiean O 1 ContentDescription prasentationMame Sinng bnaffescnption Sting mainDescnption Sirng purpose Siring subCategory Class aa apemon section E Section secilonhame String sectonDescripion String ownedaAtinoute 1 subsection E raper Ey de Constructs Figura 77 Metaclasses e associa es do pacote ManagedContent Existem tamb m as metaclasses Guidance Category e Metric que especializam a metaclasse DescribableElement A metaclasse Guidance al m de ser uma especializa o de DescribableElement possui rela o com essa metaclasse Isso permite que guias contendo informa o adicional possam ser associados a qualquer elemento DescribableElement As metaclasses Category e Metric igualmente a metaclasse Guidance tamb m possuem rela o com a metaclasse DescribableElement Tais metaclasses podem ser usadas respectivamente para categorizar os elementos DescribableElement e para associar uma ou mais restri es que fornecem medidas para qualquer elemento DescribableElement A 4 PACOTE PROCESS BEHAVIOR
221. m se como principais contribui es desta tese a elabora o de modelos intermedi rios que abordaram a integra o do PMBOK com o os processos de desenvolvimento de software SPEM RUP e OPEN o desenvolvimento do modelo de integra o entre a gest o de projetos e os fluxos organizacionais denominado de modelo SPIM com base nos modelos de refer ncia PMBOK RUP OPEN e SPEM 2 0 a integra o do modelo SPIM com os conceitos propostos pelo modelo de reconfigura o din mica de projetos de software proposto por Callegari CAL10 a adequa o dos conceitos propostos pela integra o do modelo SPIM considerando o uso da arquitetura multiagentes proposta por Schl sser SCH10 o desenvolvimento do prot tipo SPIT visando demonstrar os conceitos propostos pelo modelo integrado SPIM e pelo seu conjunto de restri es a avalia o do modelo atrav s de um estudo experimental com alunos de p s gradua o em gest o de projetos a avalia o da integra o do modelo SPIM com o modelo de reconfigura o atrav s de cen rios de situa es problema t picas 190 8 2 Publica es Relacionadas a Tese Durante o desenvolvimento da tese foram realizadas as seguintes publica es Tabela 20 Publica es relacionadas tese Local ICIS 2012 International Conference on Information Systems International Journal of Computer and Communication Engineering IADIS 2012 International Confe
222. m tempo de execu o em um contexto 21 multiprojetos onde recursos podem estar compartilhados Este modelo de refer ncia apoia se em quatro subareas para dar suporte a reconfigura o de projetos sendo elas 1 Sele o de recursos para participa o de projetos de software a partir de um pool compartilhado li Aloca o de recursos s tarefas componentes de projetos de desenvolvimento de software ili Planejamento e replanejamento de tarefas e recursos associados e iv Integra o dos projetos com fluxos organizacionais da empresa Schl sser SCH10 em sua disserta o de mestrado contribui para o modelo de reconfigura o din mica proposto atrav s de uma arquitetura baseada em sistemas multiagentes para dar suporte ao gerenciamento de agendas dos recursos que desenvolvem os projetos de software A pesquisa aqui apresentada contribui especificamente com a terceira e quarta rea do modelo de refer ncia proposto na tese de Callegari CAL10 ou seja no planejamento e replanejamento de tarefas e recursos associados e na integra o dos projetos com fluxos organizacionais da empresa A presente pesquisa considera tamb m o ambiente multiagentes proposto por Schlosser SCH10 1 2 Objetivo Geral da Pesquisa O objetivo geral desta pesquisa desenvolver e avaliar um modelo computacional para a reconfigura o din mica de projetos de software em tempo de execu o com foco na integra o das atividades espec ficas
223. ma o de m ltiplos projetos com recursos limitados Portanto faz se necess rio utilizar redes de Petri de alto n vel para combinar lugares e transi es semelhantes que s o convertidos a partir do diagrama de redes para as redes de Petri em diferentes projetos concorrentes Assim o tamanho do gr fico gerado pode ser reduzido tornando o mais f cil de ser analisado Entre as v rias extens es para as redes de Petri b sicas a rede de Petri colorida temporizada MUR89 uma das redes de Petri de alto n vel que permitem modelar sistemas din micos a eventos discretos muito mais compactos e concisos Esta vantagem obtida atrav s da introdu o de cores para distinguir as fichas que representam diferentes entidades e usando l gica adicional para controlar os fluxos de destas fichas Assim de acordo com estas vantagens a rede de Petri colorida temporizada foi escolhida nesta pesquisa para modelar o problema da programa o de multiplos projetos com recursos limitados As defini es sobre a redes de Petri coloridas temporizadas foram baseadas nas defini es sem nticas elaboradas por Jensen JENO1 A temporiza o das redes de Petri coloridas CPNs pode ser alcan ada ligando o tempo a um local transi o ou arco Quando uma ficha colocada em um lugar pela ocorr ncia de um passo step esta se 103 mantem indisponivel pelo periodo equivalente ao tempo de atraso desta ficha Apos este per odo a ficha se torna dispo
224. ma cole o de programas relacionados que s o controlados como uma nica unidade Possui as seguintes subclasses Enterprise Program Project A classe Enterprise representa o esfor o de mais alto n vel composto por um conjunto de programas relacionados que s o gerenciados como uma unica unidade A classe Producer descreve um componente central do OPF que fornece servi os e produz direta ou indiretamente as vers es de produtos de trabalho relacionados Subdivide se em produtores diretos pessoas e ferramentas e produtores indiretos organiza o equipe e papel Al m disso os produtores devem cumprir suas responsabilidades pelo desempenho das suas fun es e colaborando com outros produtores 61 description PRE o PMBOK Organization name Resources AvailableTime startDate endDate percentAvailable ManagementProcess o 0 description A director 1 timeUnit 1 uniqueFacts unitCost KnowledgeArea managingRelationship name A name RelevantStakeholder bi q DO E 1 Deliverable responsible for DeliverableType _ ManagerialActivity responsible isKeyStakeHolder levelOfinterest levelOfinfluence ActivityStakeholderWork ActivityDetailDependency type workload IndirectCosts lt a eee name lt lt abstract gt gt purpose Guidance bs WW ob
225. ma condi o um estado parcial uma espera um procedimento um conjunto de recursos um 98 estoque uma posi o geogr fica num sistema de transporte etc Em geral todo lugar tem um predicado associado por exemplo m quina livre pe a em espera vide Figura 16 Transi o representada por barra ou ret ngulo associada a um evento que ocorre no sistema como o evento iniciar a opera o transi o t naFigura 16 Ficha representado por um ponto num lugar um indicador significando que a condi o associada ao lugar verificada Pode representar um objeto recurso ou pe a numa certa posi o geogr fica num determinado estado ou ainda uma estrutura de dados que se manipula Por exemplo uma ficha no lugar m quina livre indica que a m quina est livre predicado verdadeiro Se n o tem fichas neste lugar o predicado falso por conseguinte a m quina n o est livre Se no lugar pe as em espera houvesse tr s fichas indicaria que existem tr s pe as em espera i a Pa m ta E Ea E maquina pe a em maquina peca em livre espera livre espera maquina em maquina em operacao operacao a b Figura 16 Consumo de fichas pela rede de Petri CAR97 O estado do sistema dado pela reparti o de fichas nos lugares da rede de Petri cada lugar representando um estado parcial do sistema A cada evento que ocorre no sistema associada uma transi o no modelo de rede de Petri A
226. maizar e Svestka ABU97 comparam o desempenho da repara o parcial da programa o da reprograma o completa e repara o da programa o de deslocamento para a direita right shift em rela o a medidas de efici ncia makespan e estabilidade desvio da programa o inicial A heur stica da repara o parcial da programa o reagenda apenas as tarefas diretamente e indiretamente afetadas pela perturba o causada por algum evento de modo a minimizar tanto o aumento da efici ncia quanto do desvio da programa o inicial Os resultados demonstraram que a heur stica reduz o desvio e a complexidade computacional associada reprograma o completa e ao deslocamento para a direita O deslocamento para a direita teve o pior desempenho relacionado efici ncia devido ao fato de que o m todo um simples deslocamento da programa o pelo montante da perturba o causado no cronograma Assim quanto mais tempo resultar esta perturba o maior ser o desvio esperado e maior ser o impacto na efici ncia da programa o 4 1 2 3 2 Meta heuristicas Busca Tabu Simulated Annealing e Algoritmos Gen ticos Nos ltimos anos meta heuristicas busca tabu simulated annealing e algoritmos gen ticos t m sido utilizados com sucesso para resolver problemas de programa o de 76 atividades Metaheuristicas sao heuristicas de alto nivel que orientam a heuristica de busca local GLO97 PHAOO Heur sticas de busca local s o m
227. mesuas necessidades Um exemplo de conte do espec fico apresentado na Figura 28 111 transition id t1 gt lt name gt lt Cext gt checkup lt text gt lt graphics gt offset x 5 y 2 gt lt graphics gt lt name gt lt toolspecific tool example version 1 0 gt lt action type human cost 3 gt lt toolspecific gt lt transition gt Figura 28 Exemplo de utiliza o da tagtoolspecific Conforme ilustrado acima uma ferramenta hipot tica chamada example associa a umatransi o informa es sobre a a o que ela representa Neste caso a transi o representa umaa o executada por um agente humano e que tem um certo custo associado igual a 3 Observeque esta informa o associada rede de Petri mas n o de interesse de outras ferramentas Apenas a ferramenta example pode compreender o seu significado 9 4 3 Exemplo de uma Rede de Petri representada atrav s da PNML AFigura 29 representa graficamente uma rede de Petri onde a transi o T1 tem um lugar de entrada P1 e um lugar de sa da P2 Quando T1 dispara ela remove consome um token de todos os seus lugares de entrada e adiciona produz um outro token em todos os seus locais de saida fF O F1 Ti FZ Figura 29 Rede de Petri com dois lugares e uma transi o Na Figura 30 a transi o T1 consumiu um token do lugar P1 e produziu outro no lugar P2 Comportamen
228. mpanhar de maneira integrada o andamento das atividades destes tipos de fluxos de trabalho 7 2 3 Cen rio 2 Supondo que o andamento do Projeto 1 tenha ocorrido conforme o planejado at o tempo 7 Entretanto no tempo 8 o recurso Fernando deixou a empresa gerando o evento ER3 descrito no Cap tulo 4 A Figura 66 ilustra esta situa o e destaca as tarefas queforam afetadas por esse evento estas atividades foram comprometidas porqueo recurso Fernando estava originalmente alocado nelas Consequentemente o gestor deve reconfigurar o projeto de forma a encontrar substitutos para o recurso Fernando nestasposi es de trabalho que ficaram sem recurso alocado 179 Tarefa Tempo Sad dl DADAS a id ct Ri al at tl sc Fl OL o Re TTT ETE PEPE TT PT Py TT TSAA E D D PEEP EEE EEE EE Figura 66 Cenario 1 recurso deixa a empresa Depois de identificar as tarefas comprometidas o modelo SPIM gera a rede de Petri que representa o cronograma do Projeto 1 ilustrado anteriormente na Figura 56 atrav s do parser denominado ParserMSProject O comportamento do parserParserMSProject segue a l gica apresentada na Figura 67 Percorre todas as atividades do projeto Verifica se esta atividade representa uma tarefa simples uma fase do projeto ou um agrupamento de tarefas Caso represente uma tarefa simples Cria um elemento place da rede de Petri Verifica se esta atividade est ligada a outra atividade anterior Neste caso
229. n vel A rede de Petri Colorida Temporizada pode ser formalmente definida como TCPN 2 P T A C G E Mo to 1 onde P pj P2 Pn O conjunto finito de locais n gt O o numero total de locais T t t2 gt tm o conjunto finito de transi es m gt O o numero total de transi es PN T a o conjunto finito de arcos e os elementos de A s o identificados pela express o p t ou t p iEn jem 2 o conjunto finito de cores 2 pi ai 1 ai 2 a Ui 6 1 b 1 bj 2 bj vi u 2 pi denota o n mero de cores sobre p i E n v 2 t denota o numero de cores sobre f jem C P 2 um conjunto de fun es de cores que mapeiam locais para o conjunto de cores eles especificam atributos dasfichas em um lugar especifico G um conjunto de fun es de guarda definido a partir de T em fun es booleanas isto suas avalia es s o verdadeiro ou falso e evitam as fichas de cores especificas de fluir atrav s de uma transi o E um conjunto de fun es de de entrada e sa da dos arcos M um conjunto de marca es iniciais de lugares t o tempo de in cio do modelo A marca o de um lugar p denotado por M p composto por um conjunto de fichas com suas informa es individuais de tempo Ela representa os estados realizados entre os estados poss veis indicados pelas cores do lugar p Esta pode ser alterada pelo disparo
230. nagement Group para a defini o de processos de desenvolvimento de software e seus componentes Esses modelos foram escolhidos porque possuem um bom grau de detalhamento em termos de documenta o inclusive apresentando seus respectivos metamodelos KRUOO GRA97 OMG12 Com rela o vis o sobre o gerenciamento dos projetos optou se por usar como refer ncia o Guia do PMBOK Project Management Body of Knowledge PMI08 Estes modelos encontram se no Cap tulo 2 Em seguida observou se a necessidade de integra o das duas vis es gerencial e t cnica para servir de base aos estudos seguintes Desta forma elaboraram se modelosque proporcionaram a integra o das duas vis es considerando os diferentes processos de desenvolvimento de software estudados Estes modelos de integra o encontram se no Cap tulo 3 Depois da defini o desses modelos de base foi proposto um modelo de integra o entre a ger ncia de projetos e os processos de desenvolvimento de 24 software que auxilia o planejamento integrado das atividades relacionadas a estas duas areas de conhecimento Nesta etapa tambem se desenvolveu um prototipo que possibilita o uso do modelo proposto Os resultados dessa integra o j foram explorados em artigos publicados ROS06 CAL08 ROS08a ROS08b ROS1 2b Ap s o desenvolvimento desta primeira vers o do prot tipo foi realizado dois estudos experimentais O primeiro experimento foi realizado com alunos de
231. ncial ou gerencial de apoio associa o com um ou mais fluxos de trabalho associa o com um processo gerencial do PMBOK associa o com um tipo de guidance e associa o com os produtos de trabalho que s o criados consultados ou modificados pela execu o desta atividade Para o registro dos recursos do projeto o gestor deve informar se este recurso gerencial ou produtivo Nome da tarefa Inicia o do Projeto An lise de Requisitos Defini o da Arquitetura Modelagem do Banco de Da Desenvolvimento do Componente 1 Desenvolvimento do Componente 2 Desenvolvimento do Componente 3 Integra o dos Componente Realiza o de testes dos componentes Encerramento do Projeto v Dura o In cio T rmino Predecessoras v 2dias Qua 18 12 13 Qui 19 12 13 Mauricio Informa es da tarefa Geral Predecessoras Recursos Avan ado Anota es Campos personalizados Nome An lise de Requisitos Campos personalizados Nome do campo personalizado Guidance 4 Texto13 Nomes dos recursos Q 5 177 15 Dez 13 22 De SIDISITIQQ SISID S Mauricio E Dura o 6 dias F Estimada Valor SSS iii CE T Orientar e Gerenciar a Execu o Desenvolver o Termo de Abertura Monitorar o Plano de Gerenciamento do Projeto Desenvolver o Escopo Preliminar Desenvolver a Declara o do Escopo Preliminar do p Criara WBS Produto con
232. nciamento de projetos no Brasil Participe Em caso de d vidas entre em contato atrav s do e mail mauricio rosito acad pucrs br Figura 86 Tela sobre o convite para a palestra do SPIM C 2 APRESENTA O DO PROJETO A Figura 8 apresenta a p gina que cont m a apresenta o dos integrantes do grupo de pesquisa sobre a reconfigura o din mica de projetos de software Apresenta o do Projeto T TULO e Reconfigura o Din mica de Projetos de Desenvolvimento de Software REAS DE PESQUISA e Reconfigura o din mica de projetos de software e Gerenciamento de Projetos de Software e Intelig ncia Artificial Aplicada GRUPOS DE PESQUISA RELACIONADOS e SySModE Grupo de Modelagem e Especifica o de Sistemas e Software e ISEG Intelligent Systems Engineering Group http semanticore pucrs br PARTICIPANTES DO PROJETO Coodenador e Ricardo Melo Bastos Doutor Professor do Programa de P s Gradua o em Ci ncia da Computa o da PUCRS E mail bastos pucrs br http lattes cnpq br 5205533032581356 Equipe e Marcelo Blois Ribeiro Doutor Professor do Programa de P s Gradua o em Ci ncia da Computa o da PUCRS E mail marcelo blois pucrs br http lattes cnpg br 9863163058520891 225 e Mauricio Covolan Rosito Mestre Doutorando do Programa de P s Gradua o em Ci ncia da Computa o da PUCRS E mail mauricio rosito acad pucrs br http lattes cnpg br 33400251 75172044 e Daniel Antonio Callegar
233. nd dnishToStand na inishToFinish aetension Slant ToSiar localConinbusion sjaniToFinish IncalRegtacament Figura 76 Metaclasses e associa es do pacote ProcessStructure As metaclasses Activity RoleUse WorkProductUse e Milestone representam elementos do processo de software J as metaclasses WorkProductUseRelationship ProcessPertormer ProcessResponsabilityAssignment ProcessParameter WorkSequence representam OS relacionamentos entre esses elementos WorkProductUseRelationship estabelece rela es entre WorkProductUses ProcessPerformer estabelece a rela o entre as atividades e os pap is no processo de software ProcessResponsabilityAssignment estabelece a rela o de responsabilidade entre os pap is e os produtos de trabalho ProcessParameter estabelece atrav s do atributo direction e da metaclasse de enumera o ParameterDirectionKind OS par metros de entrada e ou sa da para as atividades em termos de produtos de trabalho 209 A metaclasse WorkSequence permite estabelecer sequenciamento entre as atividades utilizando o atributo linkKind e a metaclasse de enumera o WorkSequencekKind s rela es de sequenciamento permitem estabelecer rela es de depend ncia entre as atividades em que uma atividade depende do in cio ou fim de outra s atividade s para poder iniciar ou terminar Por fim existem o auto relacionamentousedActivity da metaclasse Activity e as rela es suppressedBreakdownElement e nestedBr
234. nejamento integrado SPIM e posteriormente tiveram a oportunidade de testar as principais caracter sticas do m dulo SPIM Validator em um projeto de exemplo Mais tarde eles tiveram a oportunidade de fazer as primeiras perguntas sobre o trabalho proposto O experimento come ou somente depois que se confirmou que todos os participantes entenderam como executar o SPIM Em seguida eles foram apresentados mesma descri o de cada cen rio e foram convidados a realizar o planejamento do projeto correspondente alguns usando o m todo tradicional e outros com a ferramenta SPIT A fim de evitar poss veis distor es nos resultados obtidos tanto na avalia o com o SPIT quanto na fase de resolu o do question rio n o ocorreu qualquer intera o com o entrevistador 158 Inicialmente todos os participantes receberam um e mail convidando os a participar deste estudo experimental Neste convite foi explicado que o evento contaria com a apresenta o do modelo SPIM e a realiza o de uma atividade pr tica onde os participantes teriam a oportunidade de realizar exerc cios com base em situa es t picas de gerenciamento de projetos Refor ou se tamb m que esta atividade pr tica era caracterizada como um estudo experimental cujos resultados permitiriam aos pesquisadores realizar uma an lise das dificuldades impostas aos gerentes de projeto na solu o dos problemas propostos com e sem o uso do modelo SPIM Este foi um evento gratuit
235. nsideram se os reais motivos que o ocasionaram tais como demiss o inadequa o realoca o do recurso ou qualquer outro motivo Para esta tese de doutorado interessa apenas que um evento ocorreu e que devem ser tomadas a es para trat lo 4 2 2 1 Identifica o dos Eventos Para facilitar a identifica o os eventos foram classificados em tr s categorias e Categoria 1 eventos relacionados aos recursos humanos dos projetos de desenvolvimento de software e Categoria 2 eventos relacionados s atividades que comp em os projetos de desenvolvimento de software e Categoria 3 eventos relacionados a vari veis globais de projetos de desenvolvimento de software A Tabela 2 lista os eventos que est o relacionados aos recursos humanos juntamente com as refer ncias de onde foram extra dos Tabela 2 Eventos relacionados aos recursos humanos ID Eventos Principais Refer ncias ER1 Transfer ncia de um recurso de um projeto A para outro BENO1 projeto B ER2 Entrada de um novo recurso em um projeto SOD08 TSA03 ER3 Sa da definitiva de um recurso de um projeto SOD08 ER4 Suspens o ou aus ncia tempor ria de um recurso MILO6 ER5 Altera o de habilidades compet ncias de um recurso SCHO1 ER6 Altera o dos pap is de um recurso JI OO 84 Sobre os eventos relacionados aos recursos humanos percebe se que o eventoER1 pode ser ele pr prio desmembrado nos eventos ER2 e ER3 uma vez que sair de um pro
236. nta um lugar de uma rede de Petri e Transition representa uma transi o de uma rede de Petri e Arc representa um arco de uma rede de Petri e Coordinate representa um conjunto de coordenadas cartesianas x e y places IList xDimension int transitions List Dimension int arcs List id String Value String Source String target String inscription int id String name String xOffsetvalue int YOffsetValue int xPositionvalue int vPositionvalue int xDimension int Dimension int XOffsetValue int YOfsetValue int xSourcePosition int yoourcePosition int xTargetPosition int ral gt yTargetPosition int initialMarking int Tatevalue int isCriticalPath boolean LB BSS Figura 43 Diagrama de Classes do pacote entities Conforme observado neste diagrama a classe PetriNet uma composi o de arcos classe Arc e nodos classe Node Cada arco deve conter basicamente um identificador nico ponto de origem ponto de destino e informa es sobre o tamanho e o posicionamento A classe Nodecont m informa es de identifica o posicionamento e tamanho Esta classe abstrata herdada por duas classes concretas Place e Transition classe Place cont m informa es sobre o n mero de tokens e se faz 136 parte do caminho cr tico A classe Transition cont m o valor sobre o tempo de dura o desta transi o As s
237. ntegra o das atividades dos projetos com os fluxos organizacionais proposto nesta tese de doutorado Inicialmente apresentou se a estrat gia para a reconfigura o din mica de projetos de software utilizada de maneira a ajustar o sequenciamento das atividades dos projetos considerando um conjunto de restri es sobre as atividades os recursos e as informa es sobre as vari veis globais de projeto Ap s a defini o deste modelo computacional de reconfigura o din mica foram apresentadas as funcionalidades desenvolvidas para o prot tipo de ferramenta SPIT que oferece suporte automatizado para o planejamento e replanejamento das atividades de projetos de software O SPIT atualmente tem integrado ao seu ambiente os seguintes m dulos SPIM Validator BackOffice Workflow Integrator Compiler e Simulator Ap s o desenvolvimento deste prot tipo de ferramenta foram desenvolvidos dois tipos de avalia es do modelo SPIM A primeira avalia o foi realizada atrav s de uma compara o em um estudo experimental entre a proposta de planejamento integrado 149 com rela o proposta tradicional de planejamento de projetos de software A segunda avalia o foi realizada de forma anal tica ou seja verificaram se os resultados produzidos pelo modelo em fun o da ocorr ncia de eventos sobre cen rios simulados 150 7 AVALIACAO DO MODELO Para realizar a avalia o de modelos e produtos onde o fator humano consid
238. nto sobre a motiva o seus objetivos e asatividades desta pesquisa 1 1 Motiva o da Tese Projetos de software frequentemente experimentam diferentes altera es durante seus ciclos de vida SCHO2 Dois exemplos comuns s o as frequentes realoca es de recursos e o replanejamento de atividades Este cen rio se torna ainda mais desafiador quando recursos e atividades s o compartilhados por mais de um projeto Como resultado o gerente deve revisar constantemente o plano do projeto ajustando o cronograma e a aloca o dessas atividades a fim de trazer o projeto para um plano exequivel No entanto deve ser considerada a integra o destas atividades espec ficas dos projetos com as atividades que fazem parte do fluxo de atividades comum da organiza o O gerente de projetos por exemplo pode entrar em contato com o departamento financeiro sobre a necessidade de aquisi o de algum equipamento para um determinado projeto de software estas atividades fazem parte de um fluxo organizacional desta empresa As atividades do projeto de software entretanto podem depender da execu o dos fluxos organizacionais resultando em uma rela o de depend ncia entre estes dois fluxos diferentes Pode ser observado portanto que os gestores precisam de algum tipo de apoio para lidar com esta situa o Em um trabalho recente ROS 12 verificou se atrav s de uma revis o sistem tica que existe uma diversidade de t cnicas e estrat gias
239. nufatura afirmaram que existe pouca correspond ncia entre teoria e pr tica em rela o programa o de atividades Cowling and Johansson COW02 abordaram sobre a importante lacuna entre teoria e pr tica da programa o de atividades e afirmaram que os modelos de programa o e os algoritmos atuais s o incapazes de fazer uso de informa es em tempo real O problema da programa o das atividades de projetos considerando a presen a de eventos em tempo real denominada de programa o din mica de grande import ncia para o sucesso da implementa o de sistemas de softwares nas empresas No entanto poucos estudos t m sido publicados nesta rea Esta pesquisa preocupa se com a quest o de como lidar com a ocorr ncia de eventos em tempo real durante a execu o de projetos de software 4 1 1 O Problema da Programa o Din mica A literatura sobre programa o din mica tem considerado um n mero significativo de eventos em tempo real e seus efeitos Estes conceitos embora sejam comumente utilizados em ind strias tamb m podem ser aplicadas em organiza es de software Assim os eventos em tempo real foram classificados em duas categorias STO96 SUR93 COWO3 VIEO3 e Relacionados a recursos quebra de hardware doen a de integrante do projeto indisponibilidade ou falha de software atraso na chegada ou escassez de 70 materiais equipamento defeituoso equipamento com especifica o errada etc e Relac
240. o a atividade de desenvolvimento de um site web parte do fluxo de trabalho de projeto de software pode depender a aquisi o de um servidor web pelo departamento financeiro parte do fluxo organizacional da empresa A viola o das 45 depend ncias entre as atividades de diferentes fluxos de trabalho pode resultar em distor es no planejamento de projetos de software Projetos de Software Figura 9 Relacionamento entre projetos de software e fluxos organizacionais Observar se portanto que alguns tipos de atividades gerenciais sao inerentes ao processo e n o aparecem no momento do planeamento inicial do projeto S o precisamente essas atividades ou suas depend ncias que mais frequentemente causam atrasos no cronograma e n o s o considerados na defini o dos riscos do projeto Muitas vezes o gerente de projetos somente percebe a necessidade de ter solicitado anteriormente uma informa o de outro departamento da empresa no momento de executar uma determinada atividade do projeto que depende deste outro departamento por exemplo contrata o de servi os terceirizados a aquisi o de equipamentos a compra de passagens a reas e reserva de hot is para viagens de neg cios a coordena o logistica para ministrar palestras ao p blico externo a recep o de visitantes viajantes na empresa entre outros exemplos Consequentemente existe a necessidade de uma solu o que permita antecipar as necessidades advindas das
241. o gerencial 25 Um conjunto de equipes da organiza o deve ser uma cole o coesa de equipes Assim este conjunto n o pode conter as equipes que t m apenas fun es gerenciais Neste caso n o haveria produtos de trabalho produtivos 26 Um conjunto de equipes da organiza o deve ser uma cole o coesa de equipes Assim este conjunto n o pode conter as equipes que t m apenas fun es produtivas Neste caso n o haveria produtos de trabalho gerenciais 27 Os produtos de trabalho produtivos devem ser documentados com uma linguagem dita produtiva 28 Os produtos de trabalho produtivos devem ser documentados com uma linguagem dita gerencial 29 A dura o das fases calculada somando se o tempo de suas atividades associadas 30 Os ciclos de um projeto de software n o devem prosseguir em paralelo Este conjunto de restri es est subdividido duas categorias alertas e impeditivas As restri es categorizadas como sendo alertas atuam como instrumento informativo para o gestor de projetos caber ao gestor acatar ou n o s informa es repassadas pelo 129 modelo SPIM As restri es impeditivas entretanto obrigam o gestor a corrigir o plano de projeto Desta forma as seguintes restri es s o consideradas como impeditivas 3 4 5 6 8 9 10 11 13 14 17 19 20 29 e 30 As outras restri es estao categorizadas como sendo alertas do modelo SPIM Cabe salientar ainda que o software Micro
242. o se uma transi o est ou n o sensibilizada bem como disparar uma transi o e fazer evoluir a rede J a representa o sob um sistema de regras tem o objetivo de compatibilizar a representa o da rede de Petri com t cnicas de Intelig ncia Artificial Embora a representa o gr fica seja uma vantagem da rede de Petri a caracter stica mais importante deste modelo o fato de ser formal Sendo formal poss vel obter informa es sobre o comportamento do sistema modelado atrav s da an lise de suas propriedades gerais ou estruturais Desta forma formalmente uma rede de Petri pode ser definida como uma quintupla P T A w Mo onde e P p P2 Pm Um conjunto finito de lugares e T t t th um conjunto finito de transi es e FC PxT U TxpP um conjunto de arcos e w F 1 2 uma fun o que d valor aos arcos e Mo P 0 1 2 a marca o inicial da rede com PN T De PUT 0 Em um modelo de RdP os estados est o associados aos lugares e suas marca es e os eventos s transi es O comportamento de um sistema modelado por RdP descrito em termos de seus estados e suas mudan as 101 5 2 2 Vantagens da Aplica o de Redes de Petri na Gest o de Projetos As redes de Petri oferecem uma s rie de vantagens na gest o de projetos Estas est o descritas abaixo 1 2 4 5 7 9 Uma rede de Petri capaz de modelar um si
243. o IMEJ NO aE stan Since asic E a tae Vesna uns plasaauaneacecaa nae 130 DO COMI remate A pases 132 Di Oo O eps aos toi cd a RS a a a cae 144 6 4 IEIMITA ES DO MODELO assa das e gata EG e a De 147 6 5 GONSIDERAG ES FINAIS DO CAP TULO Ss adra esa adam dedo an do a Da destas dead ap dia dna ode a US ns as 148 AVALIA O DO MODELO az2 canas rens saias asas pa Tp a a Te 150 7 1 AVALIA O ATRAV S DE ESTUDO EXPERIMENTAL ccssccsssessscsssccsseesssccnscesscesneessesseeesncensessceeseeenseeaesens 151 7 1 1 Planejamento e Execu o do Estudo Experimental ccccccccccsessscscccceeccceceeesseesssnsssseeeeeeeeeeees 151 1 1 2 An lise dos Resultados do Experiment ccccccccccccccccccccccccceesssssssssssnceceeessccececeeessesesssssaceeeeeees 159 fio AVALIA O ANAL TICA ATRAV S DE CEN RIOS sussa sutura tend rcetoa a Oates da AD tenant naane 167 TAT Jescncao dos CCI OS ioina sect ee eps TEETE nnn ached alactan sands cod panned OENE 169 pese NCTA OT cari ete aos hace a toiled ecto a o Da S 173 Ee CONAN Zina a a desea as pd 178 Peito ONO arado Digo GET di dd dc a eaeait 182 T gt ILIMINAC ES DO EXPERIMENTO miorina E nese scat eae eeu O etna eeetec 184 TA CONSIDERA ES FINAIS DO CAPITUINO srren ss sis a a indecent 184 8 CONSIDERA ES FINAIS asa n a O a 186 Sa CONTRIBUIC ES A ais see aan ai cana tata ce a gato Ra o ado SO gato aa 189 8 2 PUBLICA ES RELACIONADAS TESE ses asian Datena sai
244. o ao modelo tradicional de planejamento de projetos de software Objetivos do Estudo Experimental 1 Unidade experimental experimental unit Projetos de Desenvolvimento de Software 2 Fatores ou varia es provocadas factors M todos de planejamento de projetos de desenvolvimento de software 3 Tratamentos M todo tradicional de planejamento de atividades M todo de planejamento integrado de atividades com o SPIM 4 Par metros parameters Complexidade da tarefa ilustrada no cen rio Ordem de execu o dos cen rios 231 5 Vari veis de Resposta response variables RVs Esfor o Precis o 6 Sujeitos Experimentais experimental subjects Alunos de p s gradua o com experi ncia anterior em projetos de desenvolvimento de software Objeto Cinco cen rios simulando situa es em projetos de software 8 Vari veis de bloqueio blocking variables Experi ncia em gest o de projetos Objetivo da Medi o Para que as vari veis de resposta sejam medidas necess rio que tenhamos m tricas b sicas que relacionadas possam caracterizar o valor das vari veis de resposta Neste item optamos pelo o uso da t cnica GQM para levantar estas m tricas Quest es 1 O esfor o para realizar o planejamento das atividades de projetos de software utilizando o modelo integrado SPIM igual ao esfor o para realizar o planejamento das atividades segundo o modelo tradicional 2 precis o no pl
245. o e com lugares limitados m ximo de 40 participantes Consequentemente o experimento envolveu apenas os alunos de p s gradua o que tinham algum interesse na rea de gerenciamento de projetos Para participar neste evento os convidados tiveram que acessar o link para o evento e criar uma conta de acesso Assim um site foi desenvolvido para armazenar os question rios deste experimento Figura 51 com o objetivo de manter a integridade dos dados obtidos durante sua execu o vide Ap ndiceC Ainda assim um sistema de controle de acesso assegurado que cada participante tinha acesso apenas s quest es que foram designados por eles diminuindo as chances de interfer ncia em suas respostas amp C O napne bento ifrs edu br spim views inscricao php Prote o contra V ru C Patrocinadores SPI M Reconfigura o Din mica de Projetos de Desenvolvimento de Software P gina Inicial Inscri o para a Palestra sobre o mopelo SPIM Apresenta o do Projeto Palestrante Maur cio Covolan Rosito doutorando em Ci ncia da Computa o da PUCRS Inscri o Data 23 11 2011 das 08 50hrs at s 12 00hrs Publica es Local Laborat rio 411 do Pr dio da Faculdade de Inform tica da PUCRS Porto Alegre RS Contato P blico Alvo Alunos de p s gradua o da PUCRS Lota o At 40 participantes Motiva o Projetos de software s o muito din micos e demandam recorrentes ajustes dos seus planos de projeto Esses ajustes
246. o efeito dos esquemas de gera o da programa o de atividades tais como a execu o em s rie ou em paralelo as regras de prioriza o de atividades e a defini o first come first served em ambientes de um unico projeto e de v rios 20 projetos Liao et al LIAO2 apresentaram um algoritmo heur stico para resolver problema da programa o de multiplos projetos com recursos limitados e discutiram a sua aplica o em uma f brica Kim et al KIMOS propuseram um algoritmo gen tico h brido com controlador de l gica fuzzy para resolver o RCMPSP A abordagem proposta foi baseada no projeto de operadores gen ticos com controlador de l gica fuzzy A revis o bibliogr fica realizada nesta pesquisa revelou quea maioria das solu es propostas ainda se baseia em modelos de gerenciamento de projetos convencionais como o m todo do caminho cr tico CPM ou a t cnica de avalia o e revis o de programas PERT Embora o m todo CPM PERT seja aplicado com sucesso na gest o de um unico projeto este apresenta dificuldades na gest o de v rios projetos simult neos uma vez que este modelo n o considera a restri o de recursos Al m disso uma s rie de fatores como a interdepend ncia criticidade prioridades conflitantes e a substitui o de recursos que afetam o controle sobre a execu o dos projetos n o podem ser representados pelo modelo tradicional CPM PERT Outros modelos de gest o tais como o venture ERT VERT graphical
247. o forma de auxiliar a sua cria o foram desenvolvidos diversos processos tais como Rational Unified Process RUP KRUOO Extreme Programming XP BEC99 e Object oriented Process Environment and Notation OPEN OPEO9 Eles podem ser adotados por completo ou permitem ainda ser adaptados de acordo com as caracter sticas da organiza o poss vel tamb m que uma organiza o se baseie em mais de um desses processos para a defini o de seu processo padr o Entretanto independente da estrat gia escolhida para a ado o do processo padr o de desenvolvimento de software importante considerar que seu uso de suma 30 import ncia j que ele um dos mais importantes mecanismos para gerenciar e controlar projetos e produtos de software HUM91 2 3 Gest o de Projetos de Software Antes de examinar a ger ncia de projetos entretanto importante compreender o conceito de projeto A defini o sobre o termo projeto utilizada nesta pesquisa reune os conceitos proporcionados por Kerzner KEROO Project Management Institute PMI08 e Schwalbe SCHO2 Com base nessas fontes compreende se que um projeto um empreendimento tempor rio com objetivo unico que consome recursos tais como pessoas verbas e materiais necess rios al m de ser desenvolvido no ambiente de organiza es sob press es de prazo custos e qualidade Segundo estudos emp ricos a efic cia de uma organiza o depende em boa parte do sucesso
248. o pela OMG composto de quatro camadas ou n veis conforme ilustrado na Figura 10 Quanto aos sistemas de metadados podem se identificar tr s tipos de modelos OMG11 e Esquemas de Metadados definem os elementos de metadados por exemplo criador assunto trabalho Resumidamente estes elementos podem ser 50 considerados como componentes de um modelo de metadados que descreve um determinado dominio de aplica o Pode se citar como exemplos deste tipo de modelo o Dublin Core DC e a Learning Object Metadata LOM e Linguagens para a defini o de esquemas definem os modelos de metadados mencionados anteriormente Pode se citar como exemplos deste tipo de modelo o XML Schema e OWL Estes fornecem um conjunto de primitivas de linguagem por exemplo complexType Class etc com uma defini o sem ntica precisa e uma nota o sint tica correspondente Uma vez que existe uma correspond ncia rigorosa entre os elementos de um modelo de metadados e as primitivas da linguagem uma linguagem de defini o de esquemas pode ser concebida como um metamodelo de um modelo de metadados Este tipo de modelo pode ser considerado como um metamodelo de metadados e Linguagens de modelagem universais onde as pr prias linguagens de defini o de esquemas s o definidas Este tipo de modelo pode tamb m ser considerado como sendo um meta metamodelo de metadados A especifica o MOF oferece uma defini o para estes tr s tipos de modelo
249. o restante As observa es que se distanciaram do resto s o normalmente chamadas de outliers Um outlier aquela observa o que parece se desviar acentuadamente dos outros membros da amostra em que ela ocorre GRU69 A identifica o destes valores extremos foi obtida pelo grafico boxplot ver Figura 52 Atrav s gr fico boxplot foi poss vel observar a maneira como as vari veis est o distribuidas em rela o homogeneidade dos dados os valores de tend ncia central os valores m ximos e m nimos e os outliers Assim pode se identificar que os valores relacionados ao esfor o em minutos para planejar os projetos do 161 experimento usando o modelo SPIM sao mais heterog neos do que aqueles que utilizaram o modelo tradicional de planejamento Ainda pode se observar a aus ncia de outliers 60 50 40 Effort in minutes 30 Traditional SPIM Project Planning Method Figura 52 Gr fico boxplot sobre o esfor o necess rio para o planejamento dos projetos Ap s esta primeira an lise deve se verificar se os dados t m ou n o uma distribui o normal Para atingir este objetivo uma hip tese nula e uma hip tese alternativa foram definidas como se segue Ho uma distribui o normal H1 n o uma distribui o normal O teste de Shapiro Wilk foi usado para verificar se a distribui o dos dados normal a Tabela 9 apresenta os resultados deste teste Tabela 9 Resultados do teste de Shapiro Wilk
250. ociation COI PMBOK Managment Process Association Validate Proiect Validate Projec O Activity Type Manaregial or Productive vl Guidance Association O Organizational Workflow Association CI RUP Workflow Association Results El Papel Gerencial ou Produtivo oA atividade gerencial Inicia o do Projeto 1 deve ter pelo menos um papel gerencial em um de seus pap is associados oA atividade gerencial Realiza o de testes dos componentes 9 deve ter pelo menos um papel gerencial em um de seus pap is associados E Associa o com Guias Guidances atividade gerencial Encerramento do Projeto 10 n o pode estar associada ao guidance produtivo UML El Associa o com Produtos de Trabalho atividade gerencial Encerramento do Projeto 10 n o pode produzir o produto de trabalho produtivo Diagrama de Classes da UML Figura 65 Valida o do Projeto 1 pelo m dulo SPIM Validator O prot tipo SPIT conforme salientado anteriormente implementa o conjunto de regras do modelo SPIM fornecendo um conjunto de interfaces de suporte ao gerente de projetos durante o planejamento e a execu o de projetos de software Mais uma vez O objetivo facilitar o trabalho do gerente de projetos que tem de levar em conta cada vez mais elementos em suas decis es e com cada vez menos tempo Os pr ximos cen rios ilustram como o SPIM pode fornecer um suporte ao gerente de projetos para obter acesso s informa es dos fluxos organizacionais e aco
251. ocorr ncia de um evento no sistema que faz com que este passe do estado atual ao pr ximo estado representada no modelo pelo disparo da transi o ao qual este est associado O disparo de uma transi o consiste em dois passos retirar as fichas dos lugares de entrada indicando que esta condi o n o mais verdadeira ap s a ocorr ncia do evento e depositar fichas em cada lugar de sa da indicando que estas atividades estar o ap s a ocorr ncia do evento sendo executadas 99 Por exemplo a ocorr ncia do evento iniciar a opera o associado transi o t vide Figura 16a s pode acontecer se houver pelo menos uma ficha no lugar maquina livre e pelo menos uma ficha no lugar pe a em espera A ocorr ncia do evento iniciar a opera o no sistema equivale ao disparo da transi o t na rede de Petri retirada umaficha do lugar m quina livre e uma ficha do lugar pe a em espera e colocada uma ficha no lugar m quina em opera o vide Figura 16b O disparo de t corresponde ocorr ncia do evento e no sistema real que o faz passar de um estado atual E ao pr ximo estado Ej O estado E representado na rede pela distribui o de fichas nos lugares chamada marca o M Do mesmo modo que o sistema s atingir o estado E ap s a ocorr ncia do evento e se estiver no estado E assim tamb m a transi o t s ser disparada se a marca o for M m
252. oftware usando o modelo integrado SPIM igual ao esfor o para realizar o planejamento das atividades de acordo com o modelo tradicional 2 A precis o no planejamento do cronograma de projetos de software relacionado atribui o de prazos e recursos considerando a integra o do projeto com os fluxos organizacionais atrav s do modelo integrado SPIM igual precis o para realizar o planejamento de acordo com o modelo tradicional A m trica associada primeira pergunta corresponde ao esfor o medido pela raz o entre o tempo gasto em minutos por cada participante durante o planeamento das atividades de software em cada abordagem A m trica associada segunda quest o corresponde precis o relacionada atribui o de prazos e recursos sobre a programa o das atividades do projeto utilizando cada uma das abordagens evitando assim a ocorr ncia de certos tipos de riscos no projeto Para este estudo a precis o foi 153 definida como a raz o entre a pontua o feita pelos participantes e da pontua o total poss vel de acordo com um modelo previamente desenvolvido pelos pesquisadores 7 1 1 2 Design do Experimento A atividade de design necess ria para formalizar as hip teses determinar as vari veis independentes e dependentes selecionar dos participantes fazer a prepara o do experimento e validar o experimento Para realizar o experimento sobre o planejamento de projetos de software foi
253. oint USA German conference on new directions for operations research in manufacturing 1991 pp 292 306 WU S D STORER R H CHANG P C One machine rescheduling heuristics with efficiency and stability as criteria Computers Operations Research vol 20 1 1993 pp 1 14 XU P RAMESH B Knowledge Support in Software Process Tailoring In Proceedings of the 38 Hawaii International Conference on System Sciences HICSS 2005 YASPER Yasper User Guide Capturado em http www yasper org Setembro 2011 YOON Il MIN S BAE D Tailoring and Verifying Software Process In Institute of Electrical and Electronic Engineers IEEE 2001 pp 202 209 YOUSSEF H SAIT S M ADICHE H Evolutionary algorithms simulated annealing and tabu search a comparative study Engineering Applications of Artificial Intelligence vol 14 2 2001 pp 167 181 YUAN CHONG YI Petri net theory and its application Beijing Publishing House of Electronics Industry 2005 135 145 ZHOU M C ZURAWSKI R Introduction to Petri Nets in Flexible and Agile Automation Kluwer Academic Publishers Boston MA 1 42 1995 ZHOU H FENG Y HAN L The hybrid heuristic genetic algorithm for job shop scheduling Computers and Industrial Engineering vol 40 3 2001 pp 191 200 ZWEBEN M FOX M S Intelligent scheduling San Mateo Morgan Kaufmann 1994 205 AP NDICE A DE
254. ojeto antecipem as necessidades 32 88 80 decorrentes das areas de suporte da organiza o durante o planejamento do projeto Faz a distin o expl cita entre as atividades de um projeto de 36 100 software e as atividades que pertencem a outros departamentos dentro da organiza o De acordo com a segunda e a ltima linha da Tabela 15 todos os participantes informaram que o planejamento integrado permite a identifica o das depend ncias ocultas entre as atividades gerenciais de apoio e as atividades produtivas evitando frequentes distor es no planejamento dos projetos A visibilidade da integra o das atividades gerenciais de apoio com as atividades do projeto de software seja produtiva ou gerencial tamb m foi identificada como um forte benef cio do SPIM por todos os entrevistados 167 A obscuridade em identificar as atividades gerenciais de apoio durante o planejamento do projeto pode afetar negativamente o projeto Quando questionados se concordavam ou n o sobre a natureza distinta dos tr s tipos de atividades a maioria dos entrevistados 5 respondeu que o modelo SPIM ajuda os gestores a acessar as informa es dos fluxos organizacionais Al m disso 88 80 dos entrevistados concordaram que o modelo SPIM contribui na identifica o das depend ncias das atividades entre o fluxo de trabalho do projeto e o fluxo organizacional permitindo a previs o das necessidades que surgem nas reas de apoio da organiza o duran
255. ojetos de software Precis o gt Vari veis Independentes Vari veis Dependentes Figura 94 Vari veis independentes e dependentes do estudo experimental A Tabela 23 sumariza as escalas para cada vari vel considerada Tabela 23 Escalas das vari veis dependentes e independentes Vari veis Nome Escala Dependentes Tempo Raz o Precis o Raz o Independentes M todos para o Nominal planejamento das atividades de projetos de software D 5 PLANEJAMENTO DO EXPERIMENTO D 5 1 Caracteriza o Detalhada do Contexto Para a condu o do experimento de sobre o planejamento de projetos de software foi escolhido o contexto de duas institui es de ensino superior IBGEN e PUCRS abordagem que permite diminuir riscos e custos n o previstos no escopo da pesquisa neste momento Dentro das dimens es apresentadas caracterizam se Processo ser utilizada abordagem In vitro na qual o conjunto de participantes executar o experimento em um ambiente controlado Este experimento n o se dar durante o planejamento de um projeto de software na ind stria Participantes o experimento ser conduzido por alunos de p s gradua o da Faculdade de Inform tica da PUCRS e do IBGEN Realidade o problema estudado corresponde a diferentes cen rios simulando situa es em projetos de desenvolvimento de software Generalidade o experimento especifico e com validade apenas no escopo do presente estudo 234 D 5
256. ompat veis redes de Petri A arquitetura utilizada para o desenvolvimento do m dulo Compiler no entanto permite a adi o de novos formatos de sa da detalhes sobre esta arquitetura foram publicados em ROS12c Conforme ilustrado na Figura 41 este m dulo est divido em tr s partes e Parser cont m as classes que comp em o analisador para arquivos com extens o pnml e mpp e Translator cont m as classes que comp em a representa o C net da WBS e da rede de Petri no SPIT e Writer cont m as classes respons veis por escrever os arquivos de sa da MICROSOFT PROJECT mpp files pnml files PARSER WRITER pnml files PETRINET TOOL MICROSOFT PROJECT Figura 41 Formatos de entrada e sa da do m dulo Compiler ROS12c mpp files O arquivo de entrada lido e as informa es sobre a rede de Petri e seus elementos s o extra das para cria o de um objeto PetriNet que mantido em mem ria Este objeto encapsula todos os elementos da rede tornando poss vel que a partir dele sejam geradas as sa das para os outros formatos 134 6 3 4 1 Arquitetura do Modulo Compiler O m dulo Compiler divide se basicamente em duas partes o pacote core que cont m as classes relacionadas aos processos de compila o e gera o de arquivos e o pacote ui que trata das interfaces com o usu rio no ambiente SPIT Este m dulo apresenta desta forma a seguinte estrutura d
257. omponentes da classe Agente Recurso e aguardar o recebimento de propostas A execu o deste processo ilustrada na Figura 34 pode ser assim resumida ao receber uma CFP o Agente Gerenciador de Propostas realiza um ordenamento sobre as tarefas nela contidas para que se tenha um controle do recebimento de propostas geradas pelos Agentes Recurso Em seguida durante a fase Gera o de Propostas inicia se um ciclo baseado no Protocolo de Rede de Contratos SMI80 onde o Agente Gerenciador de Propostas encaminha os convites para propostas de agendamento de tarefas aos Agentes Recurso Os Agentes Recurso encaminham respostas a esses convites ao Agente Gerenciador de Propostas A cada itera o o Agente Gerenciador de Propostas verifica a viabilidade das propostas recebidas em fun o das depend ncias das tarefas e da sincroniza o de propostas Ap s completar esse ciclo de execu o o Agente Gerenciador de Propostas analisa as respostas geradas pelos Agentes Recurso IOBJALOC diz respeito ao ndice de aloca o de cadarecurso Procura se manter esse indice de aloca o nafaixa de 90 a 100 de forma a n o sobrealocar orecurso CAL10 117 ajustando as nas prerrogativas do modelo de reconfigura o CAL10 e assim as encaminha para que sejam analisadas neste modelo Solu o proposta CFP Tarefas Modelo de Reconfigura o An lise da CFP Geracao de Propostas Enviar Verificar Enviar Convi
258. ons vel pela contrata o de pessoas RH Treinamento Fluxo Organizacional respons vel pelas atividades de treinamento da equipe Financeiro Comprar Fluxo Organizacional respons vel pela aquisi o de equipamentos Negocios Parceria Fluxo Organizacional respons vel pela realiza o de parcerias e contrata o de empresas terceirizadas Descri o do Cen rio 4 O pessoal mais qualificado est doente e n o dispon vel nos momentos cr ticos Orienta es ip Abra o arquivo Cen rio4 2 Durante a execu o da atividade Start Up do Projeto no dia 20 09 2011 voc recebe a not cia que a empresa contratou dois novos Desenvolvedores Junior para integrarem sua equipe Entretanto eles precisam fazer um treinamento obrigat rio para entrar em seu projeto Desta forma voc deve entrar em contato com o setor de recursos humanos sobre a necessidade de fazer o treinamento para estes 2 novos desenvolvedores coordena o de treinamento de pessoas uma atividade pertencente 244 ao fluxo organizacional do setor de recursos humanos cujo tempo de dura o de 3 tr s dias Se Com base nesta situa o sem alterar a ordem das atividades no projeto defina qual o prazo m ximo para fazer esta solicita o ao setor de recursos humanos Digite sua resposta 4 Caso voc esteja usando o modelo SPIM Atribua uma rela o de depend ncia entre as atividades do projeto de software e as atividades pe
259. ontrata o de um analista de banco de dados Esta empresa possui uma pol tica de admiss o de profissionais que exige a realiza o de exames m dicos antes da contrata o Dessa forma o gerente de projetos faz uma previs o de quando poder utilizar este novo recurso no projeto Entretanto caso o m dico respons vel pelo exame de admiss o precise ficar ausente por alguns dias este atraso poder impactar negativamente no cronograma do projeto de software em quest o Dessa forma o gerente de projetos precisa de um suporte que o auxilie a evitar distor es no planejamento de projetos tais como o aumento dos custos e atrasos nos prazos do projeto pela desconsidera o de que as atividades de apoio pertencentes aos fluxos organizacionais utilizam recursos que n o s o alocados diretamente ao projeto de software 49 4 Aux lio na identifica o e mensura o dos custos indiretos do projeto O gerente de projetos precisa lidar tanto com assuntos gerenciais quanto t cnicos durante o planejamento e a execu o de atividades Ele deve considerar durante o planejamento de projetos de software tanto as atividades que produzem um resultado significativo no contexto de um projeto de software quanto as atividades que pertencem exclusivamente aos demais fluxos de atividades de suporte ao projeto da organiza o Dessa forma a distin o explicita entre as atividades pertencentes aos fluxos organizacionais e as de um projeto de softwa
260. or financeiro 3 Com base nesta situa o sem alterar a ordem das atividades no projeto defina qual o prazo m ximo para fazer esta solicita o ao setor administrativo Digite sua resposta 4 Caso voc esteja usando o modelo SPIM Atribua uma rela o de depend ncia entre as atividades do projeto de software e Fluxos Organizacionais Salve o arquivo com o nome Cen rio SeuNome Respostas Resposta Salvar Arquivo a as atividades pertencentes ao fluxo organizacional Clique na atividade que depende do resultado da realiza o do fluxo organizacional para que seja iniciada Ap s selecione a aba Campos Personalizados No campo personalizado chamado Fluxos Organizacionais informe o nome do fluxo organizacional tenha aten o para que tenha exatamente o mesmo nome definido na tabela acima Ative o filtro listado abaixo e fa a a valida o do projeto Associa o com os Veja abaixo uma parte do projeto a ser avaliado no cen rio 2 Nome da tarefa Dura o 1 Projeto Cen rio 2 23 dias 2 Inicia o 7 dias 3 Revis o do Plano de Projeto T dias 4 fia Elaborar documento de Avalia o 1 dia 5 Revis o de estimativas 3 dias 6 Estimar custos e recursos 2 dias T Finalizar Plano de Projeto 1 dia i Elabora o 6 dias g Revis o do Plano de Projeto 1 dia 10 Refinar Planejamento do Projeto 1 dia 11 Area de Engenharia T dias 12 Definir Arquitetura 4 dias 13 An l
261. or pontos de intera o modelados dentro do fluxo de trabalho como m todos de servi o da web Para melhor ilustrar estes recursos propostos no SPIT ser utilizado um projeto de desenvolvimento de software fict cio Considerando o modelo SPIM em conjunto com as funcionalidades desenvolvidas para o SPIT o gestor de projetos deve iniciar o planejamento realizando a configura o inicial do projeto tais como a definir pap is e produtos de trabalho atrav s do m dulo de BackOffice Uma vez cadastrada no banco de dados do SPIT esse tipo de informa o deve ser exportada para um arquivo que possa ser utilizada pelo Microsoft Project 2013 Cabe relembrar que durante o planejamento e execu o do projeto de software o gerente pode utilizar o m dulo SPIM Validator potencializar as funcionalidades oferecidas pelo software comercial de gest o erealizar valida es no projeto considerando as regras SPIM Para exemplificar esta funcionalidade o SPIM Validador pode informar que uma atividade produtiva tal como desenvolver um componente de software foi erroneamente associada a uma fun o gerencial gerente de sistemas por exemplo Considere tamb m um cen rio para a aquisi o de um novo hardware atividade realizada pelo setor administrativo da empresa nesta situa o o SPIT utiliza o modulo Workflow para consultar o fluxo organizacional correspondentesobreos prazos atualizados para realizar essa aquisi o 6 3 4 Compiler O m
262. ormation Systems and Computing Sage Publications Ltda 2006 341p O DONOVAN R UZSOY R MCKAY K N Predictable scheduling of a single machine with breakdowns and sensitive jobs International Journal of Production Research vol 37 18 1999 pp 4217 4233 O HARE G JENNINGS N Foundations of distributed artificial intelligence New York Wiley 1996 OKANE J F A Knowledge based system for reactive scheduling decision making in FMS Journal of Intelligent Manufacturing vol 11 5 2000 pp 461 474 OBJECT MANAGEMENT GROUP Software amp Systems Process Engineering Metamodel Specification 1 1 Capturado em http www omg org cgi bin doc formal 02 11 14 Mar o 2012 OBJECT MANAGEMENT GROUP Omg unified modeling language omg uml infrastructure v2 1 2 Capturado em http www omg org docs formal 07 11 04 pdf Agosto de 2009 OBJECT MANAGEMENT GROUP Unified modeling language specification v1 5 Capturado em http www omg org docs formal 03 03 01 pdf Novembro 2010 OBJECT MANAGEMENT GROUP Mof 2 0 Facility And Object Lifecycle Capturado em http www omg org spec SPEM 2 0 Mar o 2011 OBJECT MANAGEMENT GROUP Software amp Systems Process Engineering Metamodel Specification 2 0 Capturado em http www omg org spec SPEM 2 0 Mar o 2012 OPEN Consortium Open Web Site Capturado em www open org au Agosto 2009 OUELHADJ D COWLING P I PE
263. ortanto eles t m que ser cuidadosamente considerados durante o design do experimento Nesta pesquisa foi 155 definido que os sujeitos experimentais seriam estudantes de p s gradua o com experi ncia anterior em projetos de desenvolvimento de software O resultado de um experimento chamado de vari vel de resposta ou vari vel dependente Esta vari vel deve ser quantitativa em experimentos realizados em laborat rio As vari veis de resposta deste experimento est o relacionadas com o esfor o e a precis o no planejamento das atividades de projetos de software Cada valor da vari vel de resposta reunido em um experimento chamado de observa o e a an lise de todas as observa es vai decidir se as hip teses a serem testadas podem ser validadas ou n o Al m disso necess ria a defini o de quaisquer caracter sticas chamado de par metros que n o s o desejadas para influenciar o resultado do experimento ou da vari vel de resposta Neste caso a complexidade das tarefas propostas e da ordem de execu o dos projetos deve permanecer inalterada a entre um experimento para o outro Por outro lado as caracter sticas do projeto que variam intencionalmente durante o estudo experimental e que afetam o resultado do experimento s o chamadas de fatores ou vari veis independentes Cada fator tem v rias alternativas poss veis Neste experimento h um fator a ser analisado m todos de planejamento de projetos e duas al
264. os de Desenvolvimento de Software uma proposta de integra o SBSI IV Simp sio Brasileiro de Sistemas de Informa o 2008 e ROSITO M Um modelo de Integra o entre a Ger ncia de Projetos e o Processo de Desenvolvimento de Software Disserta o de Mestrado PUC RS Porto Alegre 2008 e CALLEGARI D BASTOS R Project Management and Software Development Processes Integrating RUP and PMBOK ICSEM International Conference on Systems Engineering and Modeling 2007 e ROSITO Maur cio Covolan CALLEGARI Daniel A BASTOS Ricardo Melo Metamodelos de processos de desenvolvimento de software Um estudo comparativo In III Simp sio Brasileiro de Sistemas de Informa o 2006 e BASTOS R M OLIVEIRA Fl vio Moreira de OLIVEIRA Jos Palazzo Moreira de Autonomic computing approach for resource allocation Expert Systems with Applications Estados Unidos v 28 n 1 p 9 19 2005 Figura 90 Tela sobre as publica es do grupo de pesquisa C 5 APRESENTA O DO PROJETO A Figura 91 apresenta a p gina que para contato com os pesquisadores deste trabalho Contato Em caso de d vidas entre em contato atrav s do e mail mauricio rosito acad pucrs br Figura 91 Tela para contato com os pesquisadores C 6 AREA RESTRITA DO PORTAL Uma vez que os alunos receberam sua confirma o de inscri o no estudo experimental sobre o modelo SPIM eles puderam ter acesso rea restrita do site ver Figura 92 228
265. os de cada metamodelo Atrav s da integra o entre a ger ncia de projetos e os processos de desenvolvimento de software foi poss vel identificar as principais caracter sticas e discrep ncias entre os elementos de tais metamodelos Conforme citado anteriormente o metamodelo de refer ncia do PMBOK CALO7 inclui os elementos necess rios para a ger ncia de projetos de software enquanto que os conceitos de processos de desenvolvimento de software s o obtidos pelo SPEM RUP e OPEN O crit rio de integra o entre estes modelos seguiu um conjunto de regras identificado por Callegari e Bastos CALO7 que afirma que ao se realizar uma integra o entre dois modelos as seguintes situa es podem ocorrer e Uma sobreposi o de conceitos duas classes com o mesmo conceito em cada modelo neste caso pode se transformar e unir estas duas classes em um unico conceito dentro de um pacote comum e Rela o entre conceitos uma classe de um dos modelos se relaciona com alguma outra classe de outro modelo mas estas classes n o representam exatamente o mesmo conceito devem se manter as classes em seus modelos originais e criar uma associa o entre elas e e Conceitos independentes classes com conceitos independentes e distintos deve se deixar cada classe em seu pr prio pacote A proposta de integra o entre a ger ncia de projetos e os processos de desenvolvimento de software apresentada neste trabalho constitu da de tr s
266. os recursos devem ser criteriosamente estabelecidos antes da execu o do experimento Deve ser feito um treinamento espec fico para cada grupo planejamento tradicional e planejamento integrado SPIM em cada local de aplica o PUCRS e IBGEN contextualizando os objetivos a t cnica a motiva o e o procedimento t cnico para condu o do experimento Para coleta de dados ser usado um conjunto de formul rios foram definidos para este fim Ap ndiceE Outro crit rio a ser considerado a quest o do anonimato onde os nomes dos participantes n o ser o registrados 238 AP NDICE E PROTOCOLO DE AVALIA O DO SPIM Este ap ndice cont m a descri o detalhada do protocolo de avalia o do SPIM E 1 QUESTION RIO DE AVALIA O DO PERFIL DOS ENTREVISTADOS Veja abaixo o question rio de avalia o do perfil dos entrevistados Perfil do Entrevistado 1 Nome E mail Idade Grau de Escolaridade Institui o de Ensino Informe seu tempo de experi ncia em atividades relacionadas a gest o de projetos at 1 ano entre 1 e 2 anos entre 2 e 5 anos _ entre 5e 10 anos mais de 10 anos Informe seu tempo de experi ncia em atividades relacionadas a processos de desenvolvimento de software at 1 ano entre 1 e 2 anos _ entre 2 e 5 anos _ entre 5 e 10 anos mais de 10 anos J realizou algum treinamento referente Ger ncia de Projetos Como voc qualificaria seu
267. ositadamente deslocados para o pacote de classes gerenciais pacote PMBOK com o objetivo de deixar mais expl cita a classifica o dos conceitos de ger ncia de projetos e do processo de desenvolvimento de software Tamb m optou se por manter os conceitos na lingua inglesa para facilitar a compara o com os modelos originais Neste modelo vide Figura 11 a classe Organization representa uma empresa que se organiza por programas classe Program Os programas s o grupos de projetos classe Project designados a alcan ar um objetivo estrat gico As organiza es geralmente dividem os projetos em v rias fases classe Phase visando um melhor controle gerencial Os recursos necess rios para um projeto s o explicitamente descritos no subpacote Resources Sendo assim pessoas equipamentos e locais s o representados pela classe Resource Estes recursos s o divididos em recursos ativos classe Stakeholder e nao ativos classe PhysicalResource Os 53 stakeholderscorrespondem s pessoas e organiza es cujos interesses s o afetados pelo projeto PMI08 De acordo com Schwalbe SCH02 um projeto deve ter apenas um recurso respons vel por direcionar e fundamentar o projeto A import ncia da correta identifica o dos principais stakeholders deve se ao fato de que o sucesso do projeto depende entre outros fatores da capacidade de atender as necessidades e expectativas dos stakeholders Dessa forma a classe associativa ProjectStakehol
268. ossui uma distribui o normal somente se assume que a vari vel pelo menos ordinal Assim o teste de Mann Whitney para duas amostras independentes usado para verificar se as diferen as observadas entre as m dias em dois grupos independentes s o estatisticamente significativas Para atingir este objetivo as seguintes hip teses foram definidas Ho N o h diferen a entre a m dia das duas amostras H Ha uma diferen a entre a m dia das duas amostras Os resultados do teste de Mann Whitney podem ser vistos na Tabela 13 165 Tabela 13 Teste nao parametrico de Mann Whitney para a variavel de precisao Variavel Mann Wilcoxon Z Significancia Significancia Whitney U W 2 tailed 2 1 tailed Sig Precis o 66 500 237 500 3 046 0 002 0 002a Uma vez que o grau de signific ncia 0 002 menor do que o nivel de signific ncia dado 0 05 a hip tese Ho foi rejeitada Com base nos resultados apresentados para a vari vel precis o entende se que existe uma diferen a entre o esfor o m dio para realizar o planeamento entre os m todos tradicional e SPIM No entanto com base nos resultados do teste de Mann Whitney apenas a hip tese nula pode ser rejeitada n o foi poss vel avaliar as hip teses alternativas Alternativamente a an lise descritiva das m dias das amostras comparada como mostrado na Tabela 14 Tabela 14 As estat sticas descritivas para a vari vel precis o M todo M dia Tradicional 0 7725 SPIM
269. pacotes um para os conceitos de ger ncia de projetos PMBOK outro para os relacionados aos 52 processos de desenvolvimento de software SPEM RUP e OPEN e finalmente um pacote comum Common que une os conceitos que ocorrem em ambos os modelos 3 3 1 Modelo Integrado para o PMBOK e o RUP O estudo detalhado dos modelos do PMBOK e RUP permitiu dessa forma identificar como s o organizados e quais as rela es v lidas entre os elementos de cada modelo Atrav s da integra o entre o modelo do PMBOK com o modelo do RUP foi poss vel identificar as principais caracter sticas e discrep ncias entre os elementos de tais modelos O conjunto adicional de classes e relacionamentos propostos ao modelo integrado para o PMBOK e o RUP baseou se nos estudos realizados em PMI108 SCH02 BENO9 JAC01 RATO9 e PEP09 Para efeito da discuss o proposta nesta pesquisa observa se que os conceitos do PMBOK s o em sua maioria representados por textos descritivos Entretanto objetivando comparar dois modelos e posteriormente realizar a integra o entre eles deve se represent los sob estruturas compat veis neste documento ser utilizado o metamodelo previamente desenvolvido porCallegari e Bastos CAL07 usando nota o UML importante ressaltar que alguns conceitos relacionados ger ncia de projetos que est o contidos nos processos de desenvolvimento de software estudados foram prop
270. para a vari vel esfor o Vari vel M todo Estat stica Grau de Signific ncia Liberdade Esfor o Tradicional 0 923 18 0 143 SPIM 0 947 18 0 381 Com base na Tabela 9 pode se observar que o n vel de signific ncia em ambas as amostras tradicional e SPIM s o maiores do que o n vel de signific ncia que pode rejeitar a hip tese nula 0 05 ou 5 Com esta informa o n o h nenhuma evid ncia para rejeitar a hip tese nula de maneira que a distribui o normal Este resultado confirmado pela an lise do histograma e do gr fico de probabilidade normal Figura 53 onde os histogramas mostram uma distribui o sim trica quando se utiliza tanto o m todo tradicional de planejamento quanto usando o SPIM 162 G cs 4 i o s Dg F3 gt a Sm 2 q 1 3 cue 5 amp s n nem es s o e 3 co F 2000 3000 40 00 5000 6000 70 00 Figura 53 Histograma sobre o esfor o para fazer o planejamento de atividades utilizando os dois m todos O teste T tamb m assume que a variabilidade de cada grupo aproximadamente igual Desta forma foi necess rio analisar a vari ncia das duas amostras Com este objetivo duas hip teses foram definidas Ho As vari ncias s o iguais Hj As variancias n o s o iguais O teste de Levene para igualdade de vari ncias ver Tabela 10 mostra se os crit rios necess rios para o teste T foram cumpridos Tabela 10 Teste de Levene de igualdade de vari nc
271. para reconfigura o din mica de projetos de software A revis o sistem tica uma metodologia de pesquisa que usa m todos sistem ticos para identificar selecionar e avaliar criticamente os estudos cient ficos em um campo espec fico de investiga o uma revis o planejada para responder a uma pergunta espec fica que pode ou n o incluir m todos estat sticos M todos estat sticos utilizados na an lise e sintese dos estudos selecionados s o chamados de meta an lise HIG08 Como resultado desta pesquisa observou se que poucas abordagens consideram a integra o das atividades dos projetos de software com as atividades que fazem parte de fluxo de trabalho comum da organiza o Entretanto nenhuma abordagem apresentou uma solu o pr tica para este problema Conforme mencionado anteriormente o gerente de projetos precisa lidar tanto com assuntos gerenciais quanto t cnicos durante o planejamento e a execu o das atividades levando em considera o n o s as atividades do projeto de software mas tamb m as atividades que pertencem de forma compartilhada aos demais fluxos de atividades de suporte aos projetos da empresa os fluxos organizacionais Esta solu o de reconfigura o din mica de projetos de software consequentemente deve considerar a complexidade de identificar a interdepend ncia entre as atividades dos fluxos de trabalho da organiza o e o fluxo de trabalho do projeto Deve se considerar ainda que
272. para uma atividade em outra atividade Assim torna se poss vel herdar uma estrutura definida para uma atividade em termos de seus elementos e aproveit los em uma segunda atividade A rela o entre a classe Activity e a classe ProcessParameter estabelece par metros de entrada e ou sa da para as atividades em termos de produtos de trabalho A classe ProcessPerformer estabelece a rela o entre as atividades e os pap is classe ProdutiveRole no projeto A classe ProcessResponsabilityAssignment estabelece a rela o de responsabilidade entre os pap is e produtos de trabalho A distin o proposta entre os tipos de atividades que ocorrem em um projeto de software permite aos gerentes de projeto identificar poss veis rela es de depend ncia entre as atividades dos fluxos organizacionais e as atividades de um fluxo de trabalho de um projeto de software espec fico Por exemplo a atividade de desenvolvimento de um software para dispositivo m vel que se encaixa no fluxo de trabalho do projeto pode depender a aquisi o de um dispositivo port til pelo departamento respons vel da empresa esta atividade se encaixa nos fluxos organizacionais A dificuldade em visualizar esta interdepend ncia entre os fluxos de trabalho durante o planejamento das atividades pode afetar negativamente o projeto resultando por exemplo o aumento dos custos e atrasos no cronograma do projeto Como consequ ncia o gerente de projetos precisa de um suporte cont
273. participaram trinta e seis alunos de p s gradua o em Gest o de Projetos e foram utilizados cinco cen rios simulando situa es que ocorrem em projetos de software O estudo experimental no entanto possui uma abordagem quantitativa de modo que um Survey tamb m foi utilizado para avaliar os dados qualitativos A fim de avaliar os conceitos advindos do modelo integrado SPIM sobre a sua aceita o e aplicabilidade tamb m foi realizada uma avalia o qualitativa explorat ria Os benef cios percebidos na realiza o do planejamento integrado de atividades gerenciais e produtivas podem ser visualizados na Tabela 15 A segunda avalia o foi realizada de forma anal tica ou seja verificando se os resultados produzidos pelo modelo em fun o da ocorr ncia de eventos sobre cen rios simulados O objetivo desta avalia o foi de mostrar a integra o do modelo SPIM com o modelo de refer ncia para reconfigura o din mica de projetos de software proposto em Callegari CAL10 Todos os casos de avalia o foram executados sobre um cen rio composto por dez tarefas sete recursos e seis pap is Apesar do tamanho reduzido foi poss vel demonstrar algumas das principais regras propostas pelo modelo SPIM Atrav s deste tipo de avalia o tamb m foi poss vel demonstrar a integra o proposta entre os projetos de software e os fluxos organizacionais atrav s da gera o de simula es com redes de Petri Finalmente as conclus es e dem
274. pelo lugar F7 TA Figura 58 Fluxo Organizacional contrata o de pessoas A seguir ser o criadas situa es simuladas que geram eventos de reconfigura o sobre o Projeto 1 As consequ ncias e o comportamento do prot tipo para cada evento s o tamb m descritos 7 2 2 Cen rio 1 Para melhor ilustrar o uso das funcionalidades propostas para o SPIT considere que o gestor de projetos deve acompanhar o desenvolvimento do Projeto 1 vide Figura 58 Inicialmente o gestor precisa realizar a configura o inicial do projeto atrav s do 174 modulo de BackOffice do SPIT Atraves desta interface ele pode registrar todas as informa es especificadas no modelo SPIM tal como a defini o de pap is produtos de trabalho e atividades b sicas Para simplificar este exemplo objetivando facilitar o entendimento do SPIT neste cen rio considera se que algumas informa es de apoio ao SPIT j est o cadastradas na base de dados auxiliar tal como o nome das fases do processo de desenvolvimento de projetos adotado pela organiza o os processos gerenciais e reas de conhecimento do PMBOK Considera se desta forma que o gestor de projetos deve cadastrar apenas os dados essenciais para o entendimento deste cen rio Assim aFigura 59 apresenta a interface de manuten o de projetos do m dulo BackOffice Esta interface apresenta campos para selecionar um programa e definir o nome escopo prop sito objetivos e custos ind
275. ple engineering projects in a manufacturing support environment IEEE Transactions on Engineering Management vol 47 2 2000 pp 258 268 FUGGETTA A Software Process A Roadmap In Software engineering Limerick Ireland ACM 2000 GARNER B J RIDLEY G J Application of neuronal network process in reactive scheduling In Knowledge based reactive scheduling 1994 pp 19 28 GARETTI M TAISCH M Using neuronal networks for reactive scheduling In Artificial intelligence in reactive scheduling 1995 pp 146 147 GINSBERG M P QUINN L H PROCESS Tailoring and the software Capability Maturity Model Technical Report November 1995 GLOVER F KELLY J P amp LAGUNA M Genetic algorithms and tabu search hybrids for optimization Computers of Operation Research vol 22 1 1995 pp 111 134 GOU L LUH P B KYOYA Y Holonic manufacturing scheduling architecture cooperation mechanism and implementation Computers in Industry vol 37 3 1998 pp 213 231 GRAHAM l HENDERSON SELLERS B YOUNESSI H The OPEN Process Specification New York ACM Press 1997 314 p GRUBBS F E Procedures for detecting outlying observations in samples Technometrics vol 11 1969 pp 1 21 Future of GRUDIN J Managerial Use and Emerging Norms Effects of Activity Patterns on Software Design and Deployment In Proceedings of the 37 Hawaii International Conferenc
276. posi o de trabalho Uma vez composta a CFP as mesmas s o repassadas aos componentes do modelo denominados solvers os quais t m como fun o gerar propostas para a realoca o de recursos Nesse sentido os solvers recebem a CFP a analisam e assim prop em alternativas de solu o que possibilitem dar continuidade a execu o do projeto O modelo permite a execu o de v rios solvers em paralelo que podem competir entre si durante o processo de submiss o de propostas Desta forma o modelo original limita se a assumir como comportamento padr o o envio de uma proposta pertencente a um recurso para uma posi o de trabalho que esteja aberta A Figura 32 apresenta uma vis o geral do funcionamento do modelo de refer ncia proposto em Callegari CAL10 114 Elemento Ambiente de Avaliador de Propostas Limites do sistema l l Evento de Projeto Projetos cria altera gera afeta remove gt gt lan a EE 4 dd Fa iii A Gerente recursos usu rio do sistema compartilhados l Solvers implementa geradores de l l l l l l l l l l l l l l l l l l l i propostas l l l l l l l l l l l l l l Figura 32 Funcionamento geral do modelo de reconfigura o CAL10 Ap s a etapa de gera o de propostas o modelo segue seu fluxo e parte para a aval
277. presentar uma rede de Petri Simulator Consiste em um ambiente para simula o e an lise de redes de Petri As se es a seguir apresentam o detalhamento das funcionalidades da ferramenta SPIT estando divididas em subse es por grupo de funcionalidades 6 3 1 SPIM Validator O m dulo SPIM Validator age como um add in para o software Microsoft Project 2013 CHA10 e executa as regras de valida o do modelo SPIM sobre projetos de software Esta op o permite ao SPIT tirar proveito dos recursos que j foram implementados em conformidade com o modelo de integra o proposto No entanto SPIM propor certos conceitos e limita es que n o s o implementadas por esta ferramenta comercial Segundo Chatfield e Johnson CHA10 este software comercial tem 127 campos extras que permitem o armazenamento de informa es personalizadas para tarefas e recursos Atrav s deles foi poss vel adicionar informa es extras para as tarefas e recursos do projeto No mbito desta pesquisa foi necess rio adicionar campos personalizados para tarefas e recursos para realizar as valida es especificadas na SPIM modelo Um trabalho anterior CALOY7 desenvolveu um metamodelo integra o entre as classes do PMBOK e RUP chamado PMBOK RUP Inicialmente o estudo sobre a integra o dos conceitos advindos do PMBOK e do RUP produziu um conjunto de 19 regras cujos resultados foram publicados em ROS08a para garantir a consist ncia do mode
278. projeto O terceiro cen rio est relacionado com o risco de identificar que o pessoal mais qualificado n o est dispon vel em momentos cr ticos O quarto cen rio est relacionado com o risco de identificar que a forma o necess ria para o pessoal n o est dispon vel O quinto cen rio est relacionado com o risco de se identificar que os componentes de software que devem ser reutilizados cont m defeitos limitando a sua funcionalidade A valida o externa destes cen rios foi realizada atrav s da realiza o de um pr teste do experimento vide Ap ndice D com um profissional experiente da rea de gest o de projetos Considerando todas as caracter sticas desta pesquisa foi necess rio descobrir qual das duas alternativas do fator tradicional ou SPIM apresentou melhores resultados em rela o a uma dada vari vel de resposta esfor o e precis o Em seguida foi escolhido o design chamado de um fator one factor design Este tipo de design consiste em comparar a vari vel de resposta para cada alternativa de um dado n mero de unidades experimentais Aplicando as duas alternativas para a mesma unidade experimental significa que cada alternativa deve ser aplicada para o mesmo projeto em quest o Se cada alternativa utilizada no mesmo projeto duas equipes semelhantes s o necess rias Al m disso a atribui o das alternativas aos experimentos deve ser rand mica a fim de assegurar a validade das alternativas Portanto
279. projeto de software o gerente de projetos pode necessitar interagir com outros departamentos da organiza o a fim de obter informa es relevantes para o projeto contatar o setor de recursos humanos sobre a necessidade de contrata o de pessoal por exemplo Al m disso estes outros setores da organiza o s o respons veis por atualizar as informa es sobre custos e prazos destas atividades de apoio ao projeto de software Com o objetivo de obter estas informa es percebe se que o fluxo de atividades de um projeto de software poder interagir com os fluxos organizacionais Consequentemente o gerente de projetos precisa de uma solu o que permita o acesso s informa es dos fluxos organizacionais durante a elabora o do planejamento de projetos de software 2 Identifica o das rela es de depend ncia entre as atividades dos fluxos organizacionais e dos projetos de software As atividades pertencentes a um fluxo organizacional n o s o exclusivas de um projeto de software espec fico mas de um fluxo comum da empresa que compartilhado pelos projetos em andamento Neste instante percebe se que h uma dissocia o entre o fluxo de atividades de um projeto de software e os demais fluxos de atividades de suporte 48 ao projeto da organiza o Durante o planejamento de atividades do projeto por exemplo o gerente de projetos informa o setor de recursos humanos sobre a necessidade de contrata o de um analista de te
280. r impor ou atualizar as decis es tomadas pelos agentes locais a fim de satisfazer os objetivos globais da empresa e resolver as situa es de conflito 4 1 2 3 4 Outras T cnicas de Intelig ncia Artificial Uma s rie de problemas de programa o din mica adotaram t cnicas de intelig ncia artificial como em sistemas baseados em conhecimento redes neurais case based reasoning l gica fuzzy redes de Petri entre outras que s o discutidas abaixo A motiva o b sica das abordagens baseadas em conhecimento que h uma grande variedade de conhecimentos t cnicos sobre as a es corretivas em resposta a eventos em tempo real Os sistemas baseados em conhecimento t m como objetivo capturar o conhecimento ou a experi ncia de especialistas em um dominio espec fico e um mecanismo de infer ncia utilizado para tirar conclus es ou recomenda es sobre a a o corretiva Alguns pesquisadores combinaram sistemas baseados em conhecimento e simula o para decidir sobre as melhores a es corretivas em resposta a eventos em tempo real BEL96 Outros sistemas baseados em conhecimento entretanto foram desenvolvidos para auxiliar o usu rio a reagir de forma interativa a eventos em tempo real DUT90 SAR90 HECOO OKA00 19 Miyashita e Sycara MIY95 desenvolveram um framework para auxiliar na repara o da programa o das atividades utilizando o conceito de racioc nio baseado em casos do ingl s casebased reasoning
281. r ncia de projetos e desenvolvimento de software que est sendo proposta nesta pesquisa Al m disso por este mesmo motivo foi necess rio duplicar o relacionamento que existia entre as classes Role e Workproduct denominado responsiblefor Dessa forma foi explicitamente adicionado ao metamodelo o conceito que apenas um papel gerencial respons vel por um produto de trabalho gerencial classe Deliverable e que apenas um papel produtivo respons vel por um produto de trabalho produtivo Artifact O subpacote Resources tamb m cont m informa es sobre a disponibilidade de cada recurso ao atribu lo s atividades mesmo que realizado de forma manual ou autom tica atrav s da classe ResourceAvailability Esta classe permite automatizar os processos de aloca o de recursos em projetos de software Foi adicionado ao modelo a classe AvailableTime que informa quando um recurso est dispon vel Esta classe cont m atributos que informam a data inicial data final e o percentual de aloca o de um recurso a uma determinada atividade importante ressaltar que esta disponibilidade independente do projeto mas n o independente da organiza o em que atua Paralelamente a defini o da carga de trabalho atributo workload dos recursos f sicos ao associar se a diferentes atividades representada pela classe ActivityPhysicalResourceWork Este metamodelo define que a classe Activity pode ser especializada como atividade p
282. rada bem como no ambiente de modelagem SPIT s o tratados como um valor textual sem valor sem ntico Este tipo de valida o e tratamento fazem parte das propostas para trabalhos futuros nesta pesquisa 6 3 4 3 1 Parsing de arquivos MPP As classes utilizadas para o parsing de um arquivo mpp s o agrupadas no pacote integratedModel compiler core parser msProject Incialmente os dados do arquivo de entrada s o agrupados de acordo com seus tipos recursos e tarefas e s o passados para as classes respons veis por traduzir os elementos da WBS em objetos CH Para utilizar os recursos de um aplicativo do Microsoft Office tal como o Microsoft 137 Project deve se usar componente chamado Primary Interop Assembly PIA Em seguida a extra o de informa o ocorre de forma sequencial de acordo com a estrutura do arquivo de entrada Assim o parser cria um objeto que representa a rede de Petri classe petriNet e percorre todas as tarefas do projeto Para cada tarefa deste projeto criado um elemento de lugar desta nova rede de Petri O elemento local armazena as informa es sobre a identifica o e descri o da tarefa se esta faz parte do caminho cr tico do projeto e outros dados como posi o e dimens o necess rios para represent la graficamente na ferramenta SPIT Durante este processo o algoritmo verifica se essa tarefa antecessora de outra tarefa Se isso acontecer o parser ir criar os elementos de arco e tran
283. rat gias de reprograma o das atividades do projeto pesquisadas a solu o proposta utilizou estrat gia de reparo ajuste da programa o do projeto Cabe relembrar que esta estrat gia limita o escopo a pequenos ajustes da programa o atual enquanto que a estrat gia da programa o completa gera uma nova programa o das atividades a partir do zero Conforme observado no Cap tulo 4 a estrat gia da reprograma o completa pode resultar em instabilidade e falta de continuidade do cronograma levando a produ o 189 adicional de custos atribuidos ao nervosismo da equipe Ainda a politica adotada para identificar quando reprogramar as atividades do projeto foi a de reescalonamento orientada a eventos que acionada em resposta a um acontecimento inesperado que altera o status atual do projeto Finalmente o modelo SPIM adota a heur stica de deslocamento para a direita right shift para propor o deslocamento das atividades no cronograma Desta forma a solu o desenvolvida desloca o tempo das tarefas restantes da programa o para frente considerando a quantidade de tempo ocioso dos recursos envolvidos A heur stica da repara o parcial programa o tamb m adotada uma vez que esta reagenda apenas as tarefas diretamente e indiretamente afetadas pela perturba o causada por algum evento de modo a minimizar tanto o aumento da efici ncia quanto do desvio da programa o inicial 8 1 Contribui es Destaca
284. re espec fico permite a identifica o e a mensura o dos custos indiretos do projeto de software advindos das atividades de apoio da organiza o Observa se dessa forma que o gerente de projetos precisa de algum tipo de suporte para lidar tanto com assuntos gerenciais quanto t cnicos durante o planejamento e a execu o de atividades levando em considera o n o s as atividades do projeto de software mas tamb m as atividades que pertencem de forma compartilhada aos demais fluxos de atividades de suporte aos projetos da empresa A se o a seguir apresenta os modelos intermedi rios de integra o entre os aspectos advindos da ger ncia de projetos com aqueles advindos dos modelos de processos de desenvolvimento de software 3 3 Modelos Intermedi rios de Integra o A Meta Object Facility MOF OMG11 uma estrutura padr o de gerenciamento de metadados desenvolvida para permitir a interoperabilidade de modelos e sistemas de metadados 0MG11 O conceito central na arquitetura MOF a no o de um modelo Assim um modelo projetado para um determinado dominio de aplica o e descreve suas entidades e suas rela es entre si Cada modelo tem uma sem ntica de metadados que definida atrav s do significado dos seus elementos em um determinado contexto e uma sintaxe concreta que pode ser simb lica textual ou gr fica A sintaxe abstrata de um modelo descreve a sua estrutura Este modelo de arquitetura propost
285. refas comprometidas o modelo SPIM gera a rede de Petri que representa o cronograma do Projeto 1 vide Figura 57 Conforme salientado anteriormente o modelo SPIM foi desenvolvido considerando a complexidade de identificar as rela es de depend ncia entre os projetos de software e os fluxos organizacionais Assim atrav s de seu conjunto de restri es o modelo SPIM identifica que a configura o atual do projeto resultar em um atraso no prazo do cronograma do Projeto 1 Considerando que o fluxo organizacional adquirir materiais consome 10 unidades de tempo e a atividade Defini o da Arquitetura DAR ocorre no tempo 9 Como resultado a atividade DAR e todas suas atividades dependentes teriam seu tempo de in cio postergado em 1 unidade de tempo A Figura 72 ilustra este atraso em uma unidade de tempo atrav s do caractere Tarefa Tempo SE ee Pp Sense cr and ERR O mt Jo tT O o pote entra oh ls dl O aa et Tt tt aa LS O O o Pl O o PILL II o lo SSS S MEN Tc ERR a ar PSSS tT SS Figura 72 Execu o do fluxo organizacional no Cen rio 3 184 Pode se observar desta forma que a dificuldade de identificar a distin o entre estes dois tipos de fluxos de trabalho pode resultar em distor es no planejamento deste projeto as atividades gerenciais de apoio pertencentes ao fluxo organizacional adquirir materiais est o afetando negativamente no prazo das atividades deste projeto de software Entre
286. rell TYROO define um conjunto de objetivos que os processos de software devem atender Efetividade processos de desenvolvimento de software devem ajudar a determinar as necessidades do cliente e verificar se o que foi produzido satisfaz o cliente Manutenibilidade o processo de desenvolvimento de software deve ser capaz de expor a maneira de pensar de projetistas e programadores de forma que suas inten es sejam claras Assim torna se f cil encontrar e reparar falhas no produto Previsibilidade o processo de desenvolvimento de software deve ajudar a predizer quanto tempo ser necess rio para o desenvolvimento de cada parte do produto Repetivel produzir um processo novo para cada projeto implica em grandes gastos para a organiza o Dessa forma importante que o processo de desenvolvimento de software seja criado de forma a poder ser reutilizado em v rios projetos Qualidade o processo de desenvolvimento de software deve permitir engenheiros de software assegurar um produto de qualidade elevada Para isso O processo deve fornecer uma liga o entre os desejos de um cliente e o produto de um desenvolvedor Melhoria o processo de desenvolvimento de software deve ser constantemente melhorado Dessa forma o pr prio processo deve permitir a identifica o de pontos de melhoria 29 e Rastreabilidade o processo de desenvolvimento de software deve permitir que a ger ncia os desenvolvedores e o cliente sigam o status
287. rence Applied Computing ISDA 2012 International Conference on Intelligent Systems Design and Applications ICEIS 2013 International Conference on Enterprise Information Systems International Journal of Computer Information Systems and Industrial Management Applications Titulo A Systematic Review on the Integration of Project Management with Organizational Flows Project Management and Software Development Processes Integrating PMBOK and OPEN An Integrated Environment for Software Project Planning A Model to Integrate Software Project Management with Organizational Workflows An Experimental Study on the Dynamic Reconfiguration of Software Projects SPIM An Integrated Model of Software Project Management and Organizational Workflows Autores Mauricio Covolan Rosito Ricardo Melo Bastos Mauricio Covolan Rosito Daniel Antonio Callegari Ricardo Melo Bastos Mauricio Covolan Rosito Ricardo Melo Bastos Mauricio Covolan Rosito Ricardo Melo Bastos Mauricio Covolan Rosito Ricardo Melo Bastos Mauricio Covolan Rosito Ricardo Melo Bastos Para auxiliar no avan o da investiga o na rea sugerem se algumas alternativas de continuidade ao trabalho 8 3 Indica o de Trabalhos Futuros Durante a elabora o desta tese algumas id ias adicionais foram identificadas e s o aqui indicadas como sugest o para trabalhos futuros formaliza o das restri es do metamodelo atrav s d
288. resentada atrav s de an lise dos resultados 4 3 1 1 Escopo da Pesquisa Considerando o escopo geral da pesquisa o objetivo encontrar solu es para as seguintes perguntas Q e Q Quais sao as abordagens existentes e solu es relacionadas a reconfigura o din mica da rede de planejamento dos projetos de software e Q2 Como s o preparados os processos de projetos de software para gerenciar m ltiplos projetos ao mesmo tempo e Qs Quais sao as metodologias de gerenciamento de projetos que apoiam a integra o do fluxo de trabalho de projeto de software com outros fluxos organizacionais Estas quest es foram usadas para delimitar o escopo que ser atendido pelo processo de revis o sistem tica estabelecido neste trabalho atrav s da an lise e s ntese dos estudos selecionados Com base nas perguntas pr identificadas a QF foi definida como se segue e QF Quais abordagens existentes na literatura permitem a reconfigura o din mica das redes de planejamento de projetos de software considerando v rios projetos simult neos e a sua integra o com outros fluxos organizacionais A QF essencial para determinar a estrutura da revis o Se a QF n o esta bem definida pode se comprometer substancialmente o resultado da pesquisa Todos os passos da analise sistematica foram guiados pela QF que tambem foi utilizada como uma forma de julgamento da relevancia desta revisao sistematica 88 4 3 1 2 Detal
289. resentadas naTabela 8 que s o detalhadas mais adiante no Cap tulo 6 3 3 2 Modelo Integrado para o PMBOK e o OPEN O desenvolvimento do metamodelo PMBOK RUP ajudou a identificar como as classes est o organizadas e as rela es v lidas entre os elementos de cada modelo Dessa forma considerando a absor o acad mica do modelo OPEN realizou se um estudo de viabilidade para o desenvolvimento de um modelo integrado com este metamodelo Assim o metamodelo de integra o para o PMBOK e o OPEN denominado PMBOK OPEN apresenta uma estrutura similar ao apresentado na se o anterior substituindo apenas o pacote referente ao processo de desenvolvimento de software Assim as classes dos pacotes PMBOK e Common s o as mesmas que as apresentadas no metamodelo PMBOK RUP O resultado desta integra o foi publicado em ROS12b Os dois processos de desenvolvimento de software por m possuem caracter sticas particulares que s o refletidas em classes distintas e em diferentes relacionamentos com os pacotes PMBOK e Common Desta forma faz se necess rio uma an lise comparativa entre as classes dos metamodelos do RUP com o OPEN 3 3 2 1 An lise Comparativa entre os Metamodelos RUP e OPEN A an lise dos metamodelos destes processos de desenvolvimento de software vide Tabela 1 permite identificar os pontos de conformidade entre os elementos centrais do RUP e do OPEN Esta an lise comparativa foi baseada em estudos realizados em FIRO2 e
290. rformance of rescheduling strategies for parallel machine systems Journal of Manufacturing Systems vol 19 4 2000 pp 256 266 VIEIRA G E HERMANN J W LIN E Rescheduling manufacturing systems a framework of strategies policies and methods Journal of Scheduling vol 6 1 2003 pp 36 92 WARMER J KLEPPE A The Object Constraint Language Second Edition Getting Your Models Ready for MDA 2003 W3C XML WORKING GROUP Extensible Markup Language XML 1 1 W3C Recommendation 04 February 2004 Capturado em http www w3 org TR 2004 REC xml1 1 20040204 Maio 2012 Introdu o a Relat rio T cnico PESC Software WEBER M KINDLER E The Petri Net Markup Language In Petri Net Technology for Communication Based Systems 2002 vol 2472 p 124 144 WERNER C M L TRAVASSOS G H ROCHA A R C WERNECK V M Memphis Um Ambiente para Desenvolvimento de Software Baseado em Reutiliza o Relat rio T cnico COPPE UFRJ 1996 203 204 WOHO0 IWUS91 IWUS93 XU05 YAS11 Y0001 YOUO1 YUA05 ZHO95 IZHOO1 ZWE94 WOHLIN C RUNESON P H ST M OHLSSON M REGNELL B WESSLEN A Experimentation in software engineering an introduction Boston Kluwer Academic Publishers 204 p 2000 WU S D STORER R H CHANG P C A rescheduling procedure for manufacturing systems under random disruptions In Proceedings j
291. rodutiva ProductiveActivity ou atividade gerencial ManagerialActivity relacionadas ao pacote relacionado aos processos de desenvolvimento de software RUP neste caso e ao pacote PMBOK respectivamente 55 Uma atividade produtiva representa uma unidade de trabalho desempenhada por um papel produtivo que produz um resultado significativo no contexto de um projeto de software por exemplo a modelagem do banco de dados As atividades gerenciais entretanto podem pertencer tanto ao fluxo de desenvolvimento de software quanto aos fluxos organizacionais Esta distin o poss vel atrav s do atributo denominado isExternal da classe ManagerialActivity de maneira que isExternal false define uma atividade gerencial como sendo pertencente ao projeto de software enquanto que isExternal true refere se a uma atividade gerencial de apoio da organiza o Consequentemente neste modelo identificam se tr s tipos de atividades produtivas gerenciais e gerenciais de apoio Seguindo esta nomenclatura a atividade de organizar e conduzir uma reuni o de acompanhamento do projeto um exemplo de uma atividade gerencial que pertence exclusivamente ao projeto de desenvolvimento de software Em contrapartida a atividade de contratar um administrador de banco de dados um exemplo de uma atividade gerencial que pertence exclusivamente aos fluxos organizacionais neste caso esta atividade realizada pelo setor de recursos humanos Adicionalmente c
292. rojeto onde diferentes fluxos de atividades paralelas convergem em um nico fluxo de atividades para que a execu o do fluxo prossiga necess rio que todos os fluxos paralelos que convergem para a sincroniza o tenham sido completados representado por uma transi o e n lugares de entrada A Figura 20 apresenta esta ocorr ncia 106 Figura 20 Representa o de converg ncia de lugaresem uma RdP Um ponto no projeto onde uma atividade predecessora de duas ou mais atividades representado atrav s de uma transi o imediata relembrando que o tempo gasto para a realiza o da atividade est registrado no lugar que corresponde a esta atividade Assim ligadas ao lugar de sa da h n transi es imediatas respons veis pela representa o de cada fluxo a ser seguido a Figura 21 apresenta esta ocorr ncia Figura 21 Representa o de fluxos paralelos em uma RdP Cada agrupamento de atividades tal como uma fase n o s o considerados na gera o da rede de Petri O recurso alocadoparauma determinada atividade representado por uma ficha em um lugar de recurso o qual deve ser ligado at a transi o que representa a atividade por um arco restaurador Assim o r tulo deste lugar corresponde ao nome do recurso alocado para uma atividade do projeto por exemplo Ana A Figura 22 apresenta esta representa o Ana Figura 22 Representa o de um recurso executor de uma atividade para uma RdP
293. rova o final e Em caso de d vida devido falta de clareza do resumo do artigo uma leitura r pida do texto foi realizada e Os artigos restantes foram selecionados para uma leitura completa 90 A execu o desta sequ ncia de passos resultou na sele o de 24 trabalhos Quatorze deles foram exclu dos mais tarde devido falta de relev ncia m nima esperada Assim a sele o final incluiu 12 artigos 9 09 dos resultados globais dos motores de busca De acordo com Biolchini et al BIOOS e Kitchenham KIT04 esta redu o esperada em uma revis o sistem tica principalmente devido a erros de sele o dos motores de busca O principal crit rio para sele o dos trabalhos pesquisados foi aceitar apenas aqueles que incluiam um bom n vel de descri o sobre a solu o e informa es suficientes sobre os m todos ou estrat gias de qualquer tipo para resolver as quest es relacionadas com o tema de pesquisa deste trabalho Mais especificamente foi procurada a informa o sobre os seguintes itens 1 10 Atividade de agendamento scheduling indica se o artigo apresenta uma solu o para a programa o e agendamento das atividades do cronograma do projeto Conceito de atividades gerenciais de apoio indica se o artigo apresenta uma distin o entre atividades espec ficas do projeto daquelas que s o comuns a toda organiza o A integra o com os fluxos organizacionais indica se a
294. rramento do Projeto ENP Gerencial 1 9 RTC Os pap is relacionados s tarefas do Projeto1 s o apresentados na Tabela 18 Tabela 18 Informa es das tarefas para o Projeto 1 Pos Abrevia o Dura o Depend ncias Papel 1 INP 2 Gerente de Projetos 2 ANR 6 1 INP Analista de Sistemas 3 DAR 2 2 ANR Analista de Sistemas 4 MBD 3 3 ANR Projetista de Banco de Dados 5 DEV1 2 4 MDB Desenvolvedor 6 DEV2 4 4 MDB Desenvolvedor DEV3 3 4 MDB Desenvolvedor 8 INT 1 5 6 7 DEV1 DEV2 Testador DEV3 9 RTC 2 8 INT Integrador 10 ENP 1 9 RTC Gerente de Projetos A Tabela 33 apresenta a configura o inicial das tarefas do Projeto 1 exibindo suas dura es seus tempos de in cio maiscedo IMC in cio mais tarde IMT t rmino mais cedo TMC t rmino mais tarde TMT unidades de folga criticidade ou seja se faz parte do caminho cr tico e tempos atualmente programados para o in cio e fim de cada tarefa Tabela 19 Informa es detalhadas das tarefas do Projeto 1 Pos Tarefa DUR IMC IMT TMC TMT Folga CRIT In cio Fim Dep Rec 1 INP 2 1 1 2 2 0 S 1 2 Maur cio 2 ANR 6 3 3 8 8 0 S 3 8 1 G ssica 3 DAR 2 9 9 10 10 0 S 9 10 2 Laura 4 MBD 3 11 11 13 13 0 S 11 13 3 Jos 5 DEV1 2 14 16 15 17 2 N 14 15 4 Fernando 6 DEV2 4 14 14 17 17 0 S 14 17 4 Enzo 7 DEV3 3 14 15 16 17 1 N 14 16 4 Mario 8 INT 1 18 18 18 18 0 S 18 18 5 6 7 Fernando 9 RTC 2 19 19 20 20 0 S 19 20 8 Mario 10 ENP 1 0 S 21 21 9 Maur cio 21 21 21 21 172
295. rtencentes ao fluxo organizacional Clique na atividade que depende do resultado da realiza o do fluxo organizacional para que seja iniciada Ap s selecione a aba Campos Personalizados No campo personalizado chamado Fluxos Organizacionais informe o nome do fluxo organizacional tenha aten o para que tenha exatamente o mesmo nome definido na tabela acima Ative o filtro listado abaixo e fa a a valida o do projeto Associa o com os Fluxos Organizacionais Salve o arquivo com o nome Cen rio4 SeuNome Respostas Resposta a 1 Arquivo a ever Veja abaixo uma parte do projeto a ser avaliado no cen rio 4 i Nome da tarefa Dura o Inicio T rmino Predecessoras Nomes dos recursos 15 _ Arquitetura 3 dias 40 40 2044 42 40 2014 16 Defini o do pre 1 dia 10 10 2011 10 10 2011 13 Fulano 2 17 Modelar Banco dias 11 10 2011 12 10 2011 16 Fulano 5 18 Especifica o Rei T dias 13 10 2011 21 10 2011 19 RNF6 Front En 3 dias 1310 2011 17 0 2011 17 Fulano amp 20 RNFS Construn 4 dias 13102011 1102011 17 Fulano 4 2 RFZ227 Manter 3 dias 18 10 2011 20 10 2011 19 Fulano 3 de RF299 Cadast 2 dias 19 10 2011 20 10 2011 20 Fulano 8 23 RF300 Pesquis 2 dias 19 10 2011 20 10 2011 20 Fulano 4 24 RF312 Impleme 3 dias 13102011 TAM 0 2011 17 Fulano 9 do RF31 Integral 2 dias 18 10 2011 1910 2011 24 Fulano 9 26 RF32 Finaliza 1 dia 21 10 2011 21 1 072011 21 25 Fulano 3 ar Especificar Teste 2 dias 11 10
296. ructure Na Figura 75 as metaclasses Activity ProcessPerformer ProcessParameter e BreakdownElement especializam respectivamente as metaclasses WorkDerini tion WorkDefinitionPerformer WorkDefinitionParameter e ExtensibleElement do pacote Core As metaclasses abstratas BreakdownElement e WorkBreakdownElement permitem a representa o de um processo atrav s de uma estrutura WBS A ideia que a metaclasse Activity seja utilizada para instanciar os elementos que representam unidades de trabalho nos processos tais como as atividades e tamb m seja utilizada para instanciar os elementos do processo que organizam as unidades de trabalho em defini es de tempo tais como as fases as itera es e o pr prio processo J os outros elementos deste pacote que s o RoleUse WorkProductUse 208 WorkProductUseRelationship WorkSequence Milestone ProcessPerformer e ProcessResponsabilityAssignment podem ser instanciados dentro das atividades para representar as outras informa es do processo de software nastadEreakdoanElamant oie J Hoian false EN i linkedRloleLioe Jt ure 0 W mE de Core finked iokDefinibion i Owned oc a ameater ok helio ame rarmnfer fae E arenar Caramohe Linacre wd ae o foamedP aramee psedAcimy precondition posbeondilian CAMAR O Ri enumerados i nenumereaos ds Constructs ParameteDlrectionKlnd WorkSequenceKind ActhvitylseRKl
297. s e organiza se em tr s n veis M1 o n vel que cont m os elementos do modelo para uma aplica o particular A defini o de um processo de desenvolvimento por exemplo RUP e OPEN aparece no n vel M1 As linguagens de defini o de esquemas residem na camada M2 O metamodelo SPEM 2 0 por exemplo aparece no n vel M2 e serve de template para o n vel M1 No nivel mais alto a M3 pode se encontrar as linguagens universais de modelagem por exemplo defini o de construtores e tipos primitivos em que os sistemas de modelagem s o especificados O n vel MO do MOF descreve os objetos reais de um dom nio por exemplo a cria o de um processo de software para uma determinada empresa baseado no RUP A Figura 10 ilustra as camadas MOF e as correspond ncias entre os modelos de cada camada Segundo esta estrutura um modelo definido em uma camada superior define a linguagem a ser usada na camada inferior seguinte OMG11 Nesta pesquisa realizou se a integra o de modelos que pertencem s camadas M1 e M2 do MOF 51 Metadata Meta Meta Model MG Linguagens de modelagem universais gt instance D Metadata Meta Model Instance of Metadata Model instanceof MO Inst ncias de im Metadados Figura 10 Hierarquia de metaniveis do MOF O estudo detalhado dos modelos do PMBOK SPEM RUP e OPEN permitiu identificar como s o organizados e quais as rela es v lidas entre os element
298. s geralmente determinam o impacto sobre os custos e prazos previamente 16 estabelecidos para o projeto Ainda os gestores devem estar conscientes dos riscos inerentes aos projetos de software Esta tese de doutorado esta inserida dentro do escopo do projeto de pesquisa intitulado Reconfigura o Din mica em Projetos de Desenvolvimento de Software desenvolvido pelo CePES Centro de Pesquisa em Engenharia de Sistemas da PUCRS Neste sentido esta pesquisa contribui no desenvolvimento do modelo de reconfigura o din mica proposto por Callegari CAL10 considerando o uso da arquitetura multiagentes proposta por Schlosser SCH10 Resumidamente Callegari CAL10 prop s um modelo de refer ncia para realizar replanejamentos durante a fase de execu o de projetos de software Nesse modelo Callegari CAL10 sugere que a partir da ocorr ncia de um evento que possa alterar o fluxo de execu o atual do projeto seja realizada uma reconfigura o sobre as atividades do projeto Em fun o disso este modelo segue um ciclo para chamadas de propostas Call For Proposals CFPs onde se verificam as tarefas que foram afetadas em fun o de um determinado evento tal como a sa da de um recurso ou o acr scimo de tempo em uma tarefa Em seguida as CFPs s o repassadas aos componentes do modelo denominados solvers cuja fun o consiste em receber a chamada de propostas analis las e gerar propostas para a realoca o de recursos que
299. s representados na Figura 9 que s o enumerados a seguir e Sistemas discretizados s o sistemas estudados somente em instantes precisos Trata se portanto de sistemas cont nuos observados em instantes discretos sistemas amostrados As vari veis de estado evoluem de maneira cont nua sem mudan a brusca de comportamento mas somente a instantes discretos do tempo que h interesse em conhecer seu valor e Sistemas discretos s o sistemas para os quais os valores das vari veis de estado ou ao menos de algumas delas variam bruscamente a certos instantes Entretanto estes instantes n o podem necessariamente ser previstos e o conhecimento do estado a um instante dado n o permite que sem c lculo se conhe a o estado seguinte 96 e Sistemas a eventos discretos sao sistemas modelados de tal sorte que as variaveis de estado variam bruscamente em instantes determinados e que os valores das variaveis nos estados seguintes podem ser calculados diretamente a partir dos valores precedentes e sem ter que considerar o tempo entre estes dois instantes E esta classe de sistemas que sera estudada nesta tese cl t Figura 15 Sistemas a discretizado b discreto c a eventos discretos CAR97 5 1 2 Conceitos Utilizados na Modelagem de Sistemas a Eventos Discretos Os conceitos b sicos utilizados na modelagem de um sistema baseado numa abordagem por eventos discretos s o os seguintes e Eventos s o os instantes de observ
300. s com a pontua o total poss vel onde e Pspim Precis o associado com o planejamento usando o modelo SPIM e Praa Precis o associado com o planejamento tradicional A f rmula para a precis o do c lculo a seguinte Ho Pispim Pttraa Como hip tese alternativa H1 a precis o no planejamento das atividades do projeto usando o modelo SPIM n o igual precis o realizando o planejamento de acordo com o modelo tradicional Isto H1 Pispim Pitraa Depois de estabelecer as hipoteses foram identificadas algumas caracteristicas importantes para este experimento Consequentemente fundamental estar familiarizado com a terminologia utilizada em experimentos de software Uma unidade experimental a por o do material experimental em que um tratamento aplicado Em outras palavras as unidades experimentais s o os objetos sobre os quais o experimento executado Neste caso cinco projetos de desenvolvimento de software s o as unidades experimentais ou objetos experimentais desta pesquisa Estes cen rios s o apresentados mais adiante no texto A pessoa que aplica as t cnicas de experimenta o nas unidades experimentais chamada de sujeito experimental O resultado de um experimento de engenharia de software pode variar muito dependendo de quem s o os sujeitos em termos de sua experi ncia na aplica o de algumas t cnicas e at mesmo sobre o estado emocional do sujeito no momento de executar o experimento P
301. s de projeto devem desenvolver e derivam as reas centrais classe CoreKnowledgeArea e as de apoio classe FacilitatingKnowledgeArea Assim cada atividade gerencial pertence a um processo gerencial sendo tamb m relacionada a uma rea de conhecimento Finalmente as atividades podem ser subdivididas em tarefas classe Task e tamb m pode depender de outras atividades pela classe ActivityDependency Os conceitos restantes refor am que o ciclo de vida de um projeto composto de fases que por sua vez est o relacionados com as atividades Atividades se relacionam com resultados como entradas e ou sa das e cada produto tem um tipo e uma parte interessada respons vel nica 2 4 2 Rational Unified Process RUP 2 4 2 1 Defini o e Aspectos Relacionados O Rational Unified Process RUP um processo iterativo de desenvolvimento de software desenvolvido pela empresa IBM Rational Software originado a partir do metamodelo SPEM JACO1 BENO9 O RUP atua como um framework que pode ser adaptado e estendido de acordo com as caracteristicas do processo de desenvolvimento de software da organiza o RATO9 Conforme a Figura 3 o RUP cont m seus elementos em duas dimens es distintas din mica e est tica 36 Disciplinas Modelagem do Negocio Requisitos An lise e Projeto Implementa o Testes Implanta o Ger ncia de Config e Mudan as Ger ncia do Projeto
302. s especificadas para o modelo SPIM vide Tabela 8 A fim de ilustra o imagine que o gestor n o informou o seguinte que a atividade Inicia o do Projeto do tipo produtiva e est associada ao recurso Maur cio que possui um papel gerencial e que a atividade Realiza o de testes dos componentes do tipo gerencial e est associada ao recurso M rio que possui um papel produtivo O modelo SPIM atrav s das restri es de n meros 8 e 9 considera que uma atividade gerencial deve ter pelo menos um papel gerencial como um de seus pap is e que uma atividade produtiva 178 deve ter pelo menos um papel produtivo como um de seus papeis Considere tambem que o gestor associou o produto de trabalho produtivo a tarefa gerencial Encerramento do Projeto As restri es 13 e 14 do modelo SPIM consideram que uma atividade gerencial n o pode produzir ou modificar um produto de trabalho produtivo e que uma atividade produtiva n o pode produzir ou modificar um produto de trabalho gerencial Ainda a tarefa gerencial Encerramento do Projeto foi associada a um guia produtivo as restri es 23 e 24 do modelo SPIM tratam sobre esta situa o O SPIT desta forma percorre todas as informa es contidas no projeto e alerta o gestor sobre os problemas encontrados ilustrado na Figura 65 SPIM Validator E SPIM Rules 4 Role Type Managerial or Productive 4 Work Product Association Project Phase Ass
303. s nesse formato utilizando DTDs Document Type Definitions associados a verificadores sint ticos de documentos XML Na PNML estas DTDs s o chamadas de PNTD Petri Net Type Definition e s o definidos atrav s de XML Schemasna linguagem RELAX NG 0AS01 E h Formato dador q su Formato a Compilador Compilador Figura 23 Comunica o entre diferentes formatos de representa o para redes de Petri adaptado de WEBO2 5 4 2 Estrutura de um Documento PNML Um nico arquivo PNML pode conter a descri o de v rias redes de Petri Cada rede de Petri possui um identificador nico dentro do arquivo e um tipo como atributos O tipo fornecido comoatributo deve ser um URI Uniform Resource Identifier para o arquivo de defini o do tipocorrespondente A Figura 24exemplifica a estrutura de um PNML com duas redes chamadas de net1 e net2 lt xml version 1 0 encoding IS0 8859 1 2 gt lt pnml gt net id net1 type http www2 1nformatik hu berlin de ptNetb pntd gt lt net gt lt net id net2 type http www2 informatik hu berlin de ptNetb pntd gt lt net gt lt pnml gt Figura 24 Duas redes representadas em PNML WEBO2 109 As tags lt pnml gt e lt pnmi gt delimitam o conte do do arquivo PNML Cada rede dentro do arquivo delimitada pelas tags lt net gt e lt net gt Uma rede cont m v rios objetos que representam a sua estrutura seus lugares transi
304. s produtivos classe ProdutiveWorkProduct A classe abstrata WorkProductType cont m informa es sobre o tipo de um produto de trabalho em um projeto de software espec fico Assim a classe DeliverableType descreve uma categoria de produto de trabalho gerencial tas como atas de reuni o e a classe ProdutiveWorkProduct descreve uma categoria de produto de trabalho produtivo como o modelo UML ou biblioteca de c digos A classe ProductiveWorkProduct originalmente denominada WorkProduct no metamodelo OPF representa um produto 63 do trabalho que produzido consumido ou modificado durante a execu o de atividades produtivas por pap is produtivos O conjunto de produtos produzidos pelas tarefas de uma ou mais atividades representado pela classe Work Product Set enquanto que a classe Work ProductVersion corresponde a uma vers o espec fica do produto obtido atrav s do processo de desenvolvimento incremental e iterativo Ainda classe Language representa as linguagens utilizadas para documentar produtos de trabalho 3 3 3 Modelo Integrado para o PMBOK e o SPEM O metamodelo do SPEM 2 0 por sua vez separa a engenharia dos processos de desenvolvimento de software em dois momentos principais a cria o de um reposit rio de conte do do processo Method Content e a utiliza o deste conte do Process Structure em um processo de desenvolvimento de software O pacote Process Structure do SPEM cont m os elementos estruturais
305. se Discipline divide os elementos de processo em reas de interesse Um papel classe Role representa o elemento respons vel por desempenhar atividades Activity para produzir ou modificar os artefatos Artifact do processo As informa es de como os pap is devem colaborar entre si atrav s de suas atividades s o definidos pela classe WorkflowDetail classe Artifact descreve os tipos de produtos de trabalho que s o produzidos ou consumidos no desempenho de atividades Assim a classe associativa Signature indica que um artefato utilizado como entrada ou sa da de uma atividade A classe Tool descreve as ferramentas que podem ser utilizadas auxiliando a produ o ou modifica o de um artefato Finalmente a classe ToolMentor descreve o uso de ferramentas no contexto de algumas atividades 2 4 3 Object Oriented Process Enviroment and Notation OPEN 2 4 3 1 Defini o e Aspectos Relacionados O OPEN Object Oriented Process Enviroment and Notation uma metodologia de desenvolvimento de software orientado a objetos mantido pelo OPEN Consortium Group GRA97 OPE09 FIRO2 Ele pode ser definido como um framework denominado OPEN Process Framework OPF que fornece um metamodelo extens vel e que pode ser configurado para processos de desenvolvimento de software distintos GRA97 O OPEN 39 encapsula os conceitos e atividades relacionados ao negocio qualidade analise e reuso e que s o comuns a todo o processo de des
306. senta o esfor o empreendido pelos produtores durante a execu o das unidades de trabalho Este conceito n o foi encontrado no metamodelo RUP Finalmente a classe Language que se refere ao tipo de linguagem utilizada para documentar e produzir o projeto n o demonstra conformidade com qualquer classe do RUP 60 3 3 2 2 Intergrando os metamodelos PMBOK e OPEN A integra o com o OPEN permitiu tanto a confirma o quanto a adequa o dos conceitos propostos no modelo final O conjunto de classes do pacote OPEN apresentado a seguir Cabe salientar que a Figura 12 apresenta apenas os componentes centrais classes Producer WorkUnit WorkProduct Stage e Language do framework do OPEN Estes componentes representam classes abstratas e derivam num conjunto maior de subclasses algumas destas subclasses s o ilustradas no pacote OPEN A an lise das classes e relacionamentos do metamodelo de integra o PMBOK OPEN baseou se nos estudos realizados em PMIO8 SCHO2 OPEO9 FIRO2 e GRA97 e tiveram como objetivo evitar poss veis inconsist ncias no metamodelo Neste modelo vide a Figura 12 a classe Endeavor representa o esfor o empreendido pelos produtores durante o desenvolvimento do projeto Esta classe possui como responsabilidade desenvolver e ou manter um ou mais produtos e servi os relacionados ao esfor o empreendido O OPEN define que a classe Enterprise representa o n vel mais elevado de esfor o consistindo em u
307. separa a engenharia dos processos de desenvolvimento de software em dois momentos principais cria o de uma biblioteca de processos Method Library que armazenar o conte do do processo Method Content e a utiliza o deste conte do Process Structure em um processo de desenvolvimento de software A Figura 7 fornece uma vis o de como os conceitos definidos no SPEM 2 0 s o posicionados para representar o conte do do processo Method Content e sua utiliza o Process Structure Method Framework Method we Process Content a no Task Use Work Product By ted amp Definition F Role Use vire be 5 Work Product Use Definition a gt Task Activity Definition O Process Category Figura 7 Exemplo de divis o entre Method Content e Process Structure OMG12 Method Content formado pelas defini es dos produtos de trabalho dos pap is e das tarefas OProcess Structure a utiliza o do Method Content em um processo de desenvolvimento de software Por fim o elemento Guidancerepresenta os guias 42 checklists exemplos ou roadmaps definidos para os processos de desenvolvimento de software 2 4 4 2 Modelo de Refer ncia para o SPEM O SPEM um metamodelo desenvolvido pelo OMG para a defini o de processos de desenvolvimento de software e seus componentes Esse metamodelo est estruturado em sete pacotes principais conforme mostrado na Figura 8 os quais s o compostos aplicando se o me
308. si o para ligar estes dois elementos lugar O arco liga lugares com transi es de acordo com a rela o de preced ncia entre as tarefas do projeto ver Figura 44 REDE DE PETRI Figura 44 Tradu o dos dados do gr fico de Gantt em elementos da rede de Petri adaptado de ROS 12c A Figura 45 mostra a interface do SPIT para gerar redes de Petri a partir da WBS Na parte superior desta tela o usu rio deve selecionar um dos projetos de software que est o sendo visualizados no Microsoft Project e clicar no bot o Generate Petri Net As mensagens sobre o resultado desta importa o pode ser observado no campo Results A parte esquerda da tela mostra ao usu rio a estrutura da rede de Petri gerada informando os lugares transi es e arcos que fazem parte desta rede Ao selecionar um item da rede um determinado lugar por exemplo esta interface apresenta os detalhes deste item na parte inferior da tela informa es sobre o identificador do item seu nome se pertence ao caminho cr tico entre outras Finalmente a parte esquerda da tela mostra ao usu rio a rede de Petri gerada Aqueles lugares que pertencem ao caminho cr tico est o em vermelho para auxiliar na identifica o pelo gestor do projeto 138 Spit SPIM Validate Manage Configurations About Help Chart viewer p1 Inicia o do Projeto p2 An lise de Requisitos p3 D e p Modelagem do Banco p6 Desenvol
309. siderado o tempo de habilita o para o disparo da transi o que sucede este lugar Considere que destes tr slugareso menor tempo de execu o igual a 4 Utilizando se o avan o de tempo orientado a eventos o simulador verifica qual o menor tempo para que qualquer uma das transi es possa ser disparada e salta para aquele tempo O disparo de um passo entretanto uma da tarefa complexa em uma RdP Temporizada pois o simulador precisa resolver todos os conflitos da rede considerando os tempos limites relacionados aos lugares e transi es envolvidos Entretanto este simulador trata de redes simplificadas cujas informa es foram obtidas a partir da WBS Dessa forma algoritmo utilizado para a resolu o destes conflitos descrito a seguir 1 para cada lugar que habilita uma transi o deve se checar se este lugar habilita mais de uma transi o Se verdadeiro este lugar ser adicionado na tabela de poss veis conflitos 2 para cada lugar em poss vel conflito calcula se o somat rio de todos os pesos dos arcos que partem deste lugar Se o somat rio dos pesos for igual ou inferior ao n mero de tokens presentes no lugar o lugar n o estar em conflito 3 para cada lugar em conflito enquanto ainda houver transi es habilitadas selecionar aleatoriamente uma das transi es para disparar e garantir os seus tokens recalculando a habilita o das restantes 4 disparar todas as transi es que tiveram seus tokens g
310. sim supondo que o fluxo organizacional retorne que o novo recurso Maria tenha sido contratado no tempo 12 para esse papel o modelo SPIM envia uma requisi o para o modelo de reconfigura o que automaticamente verifica a sua disponibilidade e o 181 atribui s tarefas DEV1 e INT Desta forma nao ha necessidade de gerar outras redes de Petri para simular poss veis deslocamentos de atividades no tempo Como observa o final se o fluxo organizacional enviasse uma resposta posterior ao tempo 12 caso tivesse ocorrido apenas no tempo 15 por exemplo o projeto seria atrasado de forma a terminar somente no tempo 23 a Figura 69ilustra essa hip tese Tempo psd ces es O ESSES nm i H wH Figura 69 Execu o do fluxo organizacional no Cen rio 2 Neste caso o prot tipo SPIT tentaria gerar uma solu o para o gestor antecipando as atividades INT e RTC a primeira iniciando no tempo 14 e a segunda iniciando no tempo 15 e postergando as atividades DEV1 DEV2 e DEV3 iniciando ao t rmino da atividade RTC A preced ncia entre as atividades do projeto seria modificada conforme ilustra a Figura 70 Entretanto o gestor dificilmente aceitaria esta solu o visto que necess rio primeiramente desenvolver o produto de software atrav s das atividades DEV1 DEV2 e DEV3 para depoisrealizar a integra o de seus componentes atividade INT e posteriormente realizar ostestes atividade RTC Assim n o seria enviada
311. soft Project oferece suporte para as seguintes restri es propostas no modelo SPIM 3 4 5 6 17 29 e 30 6 3 2 BackOffice O modulo de Backoffice respons vel por registrar as informa es exigidas pelo SPIM modelo tais como defini es de papel tipos de atividades e produtos de trabalho associados em um banco de dados externo Esta informa o exportada para o software Microsoft Project atrav s de campos personalizados para serem usados pelo m dulo SPIM Validator Para realizar essa tarefa o m dulo de BackOffice fornece uma interface ver Figura 39 que permite aos gerentes de projeto associar um projeto de software registrado na base de dados do modelo SPIT com um arquivo usado pelo Microsoft Project mpp a mm e E SE E ol Register Export to MS Project Import from M5 Project Help ie Programs Details Roles Work Products Fredecessors Guidance i Projects Process Groups a Knowledge Areas jm Project Phase Tasks 2 Roles Work Products C Managerial activity nal a LI Milestone ee Managerial Proces s ae Task Groups Disciplines Se ee n E i Project Workflow E me Lom Loe Com Name Managerial Analysis of customer needs Import from MS Project E Analyzing software specifications Export to MS Project Define primary resources a Determine preliminary software specifications aa Determine project scope Ensure key resources Description
312. solu o fornece integra o do fluxo de atividades do projeto com os fluxos organizacionais Suporte a multiprojetos indica se a solu o suporta mais de um projeto simultaneamente Tipo de solu o indica se ele mostra a solu o da categoria geral por exemplo de apoio decis o otimiza o e metodologia M todo o m todo utilizado para a solu o por exemplo redes Bayesianas e programa o din mica Solu o din mica indica se a solu o pode fornecer feedback imediato durante o curso do projeto Uso de simula o indica se a solu o envolve algum tipo de simula o em computador Avalia o pela comunidade cient fica Indica se a pesquisa foi cientificamente avaliada como um estudo de caso ou experimento Ferramenta indica se a solu o inclui uma ferramenta ou um prot tipo 91 A classifica o dos estudos com base nestes crit rios apresentada na Tabela 6 Tabela 6 Resultado sobre os artigos pesquisados Fonte Item Item Item Item Item Item Item Item Item Item 1 2 3 4 5 6 7 8 9 10 CALO7 Sim Sim Sim Sim Suporte Modelo de Sim N o Nao Nao decisao Integra o CHEO5 Sim N o Nao N o Suporte Modelo Sim Nao N o N o decis o Matem tico LEEO4 Sim N o N o Sim Suporte Cen rios Sim Sim N o Sim decis o J0OS05 Sim Sim Sim N o Suportea Estrat gias Sim Sim N o N o decis o RIHO1 Sim N o N o N o Suportea Multiagente Sim Sim Sim Sim decis o ZHAO9 Sim N o N o
313. sos nos prazos do projeto pela desconsidera o de que as atividades gerenciais de apoio utilizam recursos n o alocados diretamente ao projeto de software 1 6 Permite antecipar as necessidades advindas das reas de apoio da organiza o durante o planejamento do projeto 1 7 Distin o expl cita entre as atividades produtivas e gerenciais de um projeto de software com as atividades gerenciais de apoio dos demais departamentos da organiza o 2 Voc percebeu outros benef cios observados no modelo integrado SPIM durante a sua utiliza o neste projeto 3 Voc percebeu algum aspecto que n o favore a a gest o de projetos usando o modelo integrado SPIM durante a sua utiliza o neste projeto
314. squisa S project management OR scheduling AND business process OR workflow AND managerial activity OR enterprise activity OR organizational activity OR productive activity AND year gt 2000 AND year lt 2011 S2 project management AND business process AND managerial activity OR enterprise activity OR organizational activity OR productive activity AND year gt 2000 AND year lt 2011 S3 scheduling AND workflow AND managerial activity OR enterprise activity OR organizational activity OR productive activity AND year gt 2000 AND year lt 2011 S4 dynamic reconfiguration AND business process OR workflow AND year gt 2000 AND year lt 2011 Deve ser observado que algumas strings de pesquisa utilizadas retornam um razo vel numero de documentos Os 132 artigos selecionados foram resultantes da string S4 Esta string seleciona artigos de revistas e confer ncias publicados desde 2000 que lidam com a reconfigura o din mica dos projetos de software com nfase na integra o da ger ncia de projetos com os fluxos organizacionais 4 3 2 An lise dos Resultados Os 132 artigos foram preliminarmente selecionados para uma an lise posterior Assim esta sele o foi baseada na seguinte sequ ncia de passos e A string de pesquisa foi executada em cada um dos motores de busca e O t tulo e o resumo de cada artigo foram lidos e Quando preliminarmente aprovados os textos completos foram lidos para uma ap
315. st gio do ciclo de vida do OPEN muitas tarefas podem ser executadas e para cada tarefa diferentes t cnicas podem ser utilizadas Figura 5 Process Unit Activity 1 Activity 2 E EE E Technique 1 Technique 2 EE Figura 5 Relacionamento entre atividades tarefas e t cnicas OPE09 40 Cada atividade definida como um conjunto de tarefas que s o a menor unidade de trabalho gerenci vel As tarefas s o realizadas atrav s do uso de t cnicas Dessa forma o OPEN inclui os conceitos de atividades com suporte ao ciclo de vida completo al m de tarefas e conjuntos de t cnicas e artefatos 2 4 3 2 Modelo de Refer ncia para o OPEN O framework do OPEN cont m seu foco na intera o cooperativa entre os produtores suas unidades de trabalho e o que produzem OPE09 Dessa forma o OPF reconhece as classes ilustradas na Figura 6 como sendo os componentes centrais de seu framework Neste modelo a classe Endeavor refere se ao componente que modela o esfor o empreendido pelos produtores Producer que executam unidades de trabalho WorkUnit durante um ou mais est gios Stage Os componentes produzidos durante o desenvolvimento do projeto s o definidos pela classe WorkProduct A classe Language modela o tipo de linguagem utilizada para documentar e produzir os produtos do projeto lt j organized and staffed by_ Endeavor aes Producer performs B Work Product
316. stas t cnicas Estas compara es ajudaram na identifica o de quais t cnicas s o mais adequadas para a programa o din mica As heuristicas t m sido amplamente utilizadas para reagir presen a de eventos em tempo real devido a sua simplicidade Entretanto n o garantem encontrar uma programa o ideal mas tem uma razo vel capacidade de encontrar boas solu es em um curto espa o de tempo Para superar isso t m sido propostas meta heuristicas como a busca tabu simulated annealing e algoritmos gen ticos Ao contr rio da simulated annealing e da pesquisa tabu os algoritmos gen ticos manipulam uma popula o de solu es vi veis Os algoritmos gen ticos entretanto n o 80 s o eficientes para encontrar uma solu o perto do ideal em um tempo razo vel em compara o com a busca tabu e simulated annealing GLO95 JOZ98 YOU01 ZHOO1 Sistemas baseados em conhecimento possuem o potencial para automatizar parte do racioc nio humano para executar sistemas de programa o de atividades Em termos de efic cia da sua capacidade de tomada de decis es entretanto eles s o limitados pela qualidade e integridade do seu conhecimento de dominio A l gica fuzzy ainda n o foi explorada em todo seu potencial As redes neurais n o podem garantir fornecer decis es timas mas a sua capacidade de aprendizagem as torna ideal para sistemas din micos Uma poss vel solu o para a programa o din mica talvez seja a in
317. stem for dynamic scheduling nternational Journal of Production Research vol 28 8 1990 pp 1499 1513 SCHMIDT G How to apply fuzzy logic to reactive scheduling In Knowledge based reactive scheduling Amsterdam North Holland 1994 pp 57 67 201 202 SCHO1 SCHO2 SCH10 ISGI10 SHE99 SHE01 SHU96 SMI80 SMU95 SODOS8 SOL99 SOMOS STO96 SUNO1 SUR93 SZE94 SCHIMDT R LYYTINEM K KEIL M CULE P Identifying software project risks an international delphi study Journal of Management Information Systems vol 17 4 2001 pp 5 36 SCHWALBE K Information Technology Project Thomson Learning one edition 2002 SCHLOSSER R Gerenciamento Distribuido de Agendas de Recursos para Projetos de Desenvolvimento de Software baseado em Sistemas Multiagentes Disserta o de Mestrado PUC RS Porto Alegre 2010 STANDISH GROUP INTERNATIONAL Chaos A Recipe for Sucess Artigo desenvolvido pelo Standish Group International Inc Capturado em http Awnww standishgroup com sample research Junho 2010 SHEN W NORRIE D H Agent based systems for intelligent manufacturing a state of the art survey International Journal of Knowledge and Information Systems vol 1 2 1999 pp 129 156 SHEN W NORRIE D H BARTHES J P A Multi agent systems for concurrent intelligent design and manufacturing London Taylor amp
318. stema onde muitas atividades acontecem de forma simult nea e assincrona Ela permite modelar atividades concorrentes e seus conflitos Al m disso pode auxiliar na identifica o de bloqueios deadlocks Ela fornece informa es ao gerente de projetos para ajudar a verificar e raciocinar sobre o progresso tardio das atividades capaz de regenerar e reprogramar as atividades do projeto Uma rede de Petri tamb m uma representa o din mica de um sistema e portanto adequada para o monitoramento em tempo real A l gica expressa em palavras pode ser transferida para uma forma gr fica e uma forma matem tica que s o adequadas para an lise do projeto As redes de Petri fornecem resultados anal ticos em conjunto com a flexibilidade da modelagem advinda da simula o A simula o din mica de um projeto pode ser visualizada graficamente Usando subredes as partes do projeto podem ser facilmente modeladas Assim poss vel simular todo o projeto e manter todas as subredes em primeiro plano e o restante em segundo plano A rede de Petri capaz de representar a interdepend ncia de recursos aloca o parcial substitui o de recursos e exclusividade m tua O planejamento do projeto pode ser melhorado usando algumas propriedades comportamentais das redes de Petri tais como o alcance e a limita o A rede de Petri pode ser simplificada pela combina o de lugares e transi es semelhantes Assim o tamanho da rede po
319. stes Neste caso constata se a exist ncia de uma rela o de depend ncia entre as atividades do projeto tais como a modelagem dos casos de teste com as atividades pertencentes ao fluxo de trabalho do setor de recursos humanos referentes contrata o do profissional requerido para executar a atividade do projeto de software A dificuldade para identificar a interdepend ncia dos fluxos de trabalho da empresa e do projeto de software durante o planejamento do projeto pode resultar por exemplo no aumento dos custos e em atrasos nos prazos do projeto Assim percebe se a necessidade de identifica o das rela es de depend ncia entre as atividades pertencentes a estes dois tipos de fluxos de trabalho permitindo a antecipa o das necessidades advindas das reas de apoio da organiza o durante o planejamento de projetos de software 3 Capacidade de minimizar distor es no planejamento de projetos tais como o aumento dos custos e atrasos nos prazos do projeto Conforme mencionado anteriormente os fluxos organizacionais e do projeto de software s o executados de forma distinta Al m disso as atividades pertencentes aos fluxos organizacionais utilizam recursos n o alocados diretamente ao projeto de software Estes recursos podem influenciar tanto nos prazos das atividades quanto nos custos do projeto de software Ao realizar o planejamento de um projeto de software por exemplo o gerente de projetos identifica a necessidade de c
320. stes entrevistados entretanto apresentaram conhecimentos suficientes em gest o de projetos para que o experimento fosse realizado 7 4 Considera es Finais do Capitulo Este Capitulo apresentou as avalia es do modelo de reconfigura o proposto nesta tese onde tamb m foram detalhados os cen rios usados para a gera o dos dados e dos comportamentos obtidos como resposta Conforme salientado anteriormente foram desenvolvidos nesta tese de doutorado um modelo computacional e um prot tipo de 185 ferramenta Assim as avalia es do modelo SPIM foram realizadas com o aux lio do prot tipo desenvolvido A primeira avalia o foi realizada atrav s em um estudo experimental considerando a proposta de planejamento integrado com o modelo SPIM em rela o proposta tradicional de planejamento de projetos de software Seguindo esta abordagem foi decidido que o objetivo desta pesquisa era de comparar a precis o e o esfor o destes modelos de planejamento de projeto de software Considerando a vari vel esfor o a avalia o mostrou que estatisticamente n o havia diferen a significativa para no planeamento de projetos de software utilizando o m todo tradicional em rela o ao m todo SPIM Entretanto comparando os valores m dios das duas abordagens foi poss vel concluir que a precis o para realizar o planeamento usando o modelo SPIM foi maior do que usando o modelo tradicional Cabe refor ar que para esta avalia o
321. straint da UML 2 0 A metaclasse WorkDefinition tamb m pode possuir O ou v rios par metros representados pela metaclasse ParameterDirectionKind e tamb m pode ser associada a O ou v rias metaclasses WorkDefinitionPerformer A metaclasse WorkDefinitionPerformer uma metaclasse abstrata que representa o relacionamento de um executor de trabalho para uma metaclasse WorkDefinition Essa metaclasse ser especializada em outros pacotes do metamodelo SPEM 2 0 em diferentes tipos de relacionamentos Ela ir ser especializada por exemplo no pacote ProcessStructure em ProcessPerformer 207 A 2 PACOTE PROCESS STRUCTURE O pacote ProcessStructure o pacote que define a base para todos os processos de software no metamodelo SPEM 2 0 Nesse pacote processos s o representados por uma estrutura de Work Breakdown Element WBS que permite o aninhamento de atividades dentro de outras atividades ou ainda o aninhamento de outros elementos dentro de uma atividade Desse modo os elementos que podem ser aninhados em atividades sao papeis produtos de trabalho e tambem varias metaclasses que representam relacionamentos A Figura 75 e a Figura 76 exibem respectivamente a taxonomia de metaclasses do pacote ProcessStructure e as principais associa es definidas nele WorkProductlise ProcessParameter WorkSequence WorkBreakdownE lement cr rod R EaR Milestone a Figura 5 Taxonomida das metaclasses do pacote ProcessSt
322. sual Studio 2012 e a ferramenta de modelagem Jude Community vers o 6 7 0 Esta se o descreve os demais detalhes de implementa o A ferramenta Software Planning Integrated Tool SPIT tem como objetivo oferecer algum tipo de suporte aos gestores no processo decis rio de projetos de software atrav s dos conceitos propostos pelo modelo SPIM e seu conjunto de regras Para atingir este objetivo este software foi desenvolvido de forma modular permitindo que ele absorva novas funcionalidades de forma r pida e sem comprometer sua estrutura Atualmente o SPIT tem integrado ao seu ambiente os seguintes m dulos e SPIM Validator atua como um add in para o Microsoft Project 2013 e executa as regras de valida o do modelo SPIM sobre projetos de software e BackOffice respons vel pela gest o da informa o requerida pelo modelo SPIM como defini o de pap is tipos de atividades e produtos de trabalho associados Esta informa o exportada para o Microsoft Project atrav s de campos personalizados desta ferramenta comercial dados que s o posteriormente utilizados pelo m dulo SPIM Validator e Workflow Integrator m dulo respons vel por sincronizar as informa es contidas nos fluxos de trabalho organizacionais com as informa es contidas em um projeto de software espec fico e Compiler uma ferramenta para modelagem compila o gera o e verifica o de redes de Petri Este m dulo usa internamente o formato PNML para re
323. suficientes para prosseguir com este trabalho uma vez que estes fatos indicaram a necessidade de novas investiga es e novas solu es para esta rea Consequentemente aprofundaram se os estudos sobre o desenvolvimento do modelo integrado SPIM Paralelamente novas funcionalidades foram adicionadas ao software SPIT Em seguida foi apresentado o planejamento e a execu o de dois estudos experimentais realizados com estudantes de gradua o e p s gradua o que analisou dois m todos distintos de gest o de projetos tradicional e SPIM Cinco cen rios foram elaborados com o objetivo de coletar informa es para comparar a precis o e o esfor o utilizando o planejamento tradicional e o planejamento integrado SPIM Este experimento 188 revelou que o uso do modelo SPIM ajudou os gestores na cria o e condu o de um plano de projeto mais preciso do que com uso do m todo tradicional Muitas vezes o gerente de projetossomente percebe a necessidade de entrar em contato com outro departamento para obter alguma informa o apenas no momento em que a equipe deve executar a atividade do projeto A obscuridade em identificar este tipo de relacionamento durante o planejamento e execu o de um projeto de software pode afetar negativamente o cronograma do projeto Esta prova foi claramente observada durante este estudo emp rico ao analisar a vari vel precis o Evid ncias relacionadas com a vari vel esfor o tamb m puderam ser extra
324. sultado 2 Texto26 Ajuda Come Figura 63 Visualiza o dos campos personalizadospara as atividades do projeto Ao finalizar o cadastro das informa es no Microsoft Project o gestor deve obter um cronograma conforme ilustrado na Figura 64 LA tao pa e 10 Modo da E Tarefa Nome da tarefa Dura o Inicia o do Projeto 2 dias An lise de Requisitos 6 dias Defini o da Arquitetura 2 dias Modelagem do Banco de Dados 3 dias Desenvolvimento do 2 dias Componente 1 Desenvolvimento do 4 dias Componente 2 Desenvolvimento do 3 dias Componente 3 Integra o dos Componentes 1 dia Realiza o de testes dos 2 dias componentes Encerramento do Projeto 1dia Inicio Qua 18 12 13 Sex 20 12 13 Seg 30 12 13 Qua 01 01 14 Seg 06 01 14 Seg 06 01 14 Seg 06 01 14 Sex 10 01 14 Seg 13 01 14 Qua 15 01 14 T rmino Qui 19 12 13 Sex 27 12 13 Ter 31 12 13 Sex 03 01 14 Ter 07 01 14 Qui 09 01 14 Qua 08 01 14 Sex 10 01 14 Ter 14 01 14 Qua 15 01 14 Predecessoras E w M Nomes dos recursos Mauricio G ssica Laura Jos Fernando Enzo M rio Fernando M rio Maur cio Figura 64 Cronograma Parcial do Projeto 1 no Microsoft Project Considerando que todas as informa es do Projeto 1 est o cadastradas nesta ferramenta comercial o gestor pode realizar a valida o do projeto em rela o ao conjunto de restri e
325. suportar esta funcionalidade este modelo define tr s diferentes tipos de atividades 1 atividades produtivas atividades diretamente relacionadas com a constru o do produto de software 121 2 atividades gerenciais atividades que s o necess rias somente para coordenar a constru o do produto de software e 3 atividades gerenciais de apoio quaisquer outras atividades que n o pertencem ao fluxo de atividades de um projeto individual e pode ser mais partilhado por outros projetos A modelagem do banco de dados de um aplicativo de software um exemplo de atividade produtiva Organizar e conduzir uma reuni o de acompanhamento do projeto um exemplo de atividade gerencial Esses dois primeiros tipos de atividades fazem parte do fluxo de trabalho do projeto A contrata o de um administrador de banco de dados atividade normalmente realizada pelos departamentos de recursos humanos um exemplo de atividade gerencial de apoio Ap s essa defini o foi poss vel distinguir quais atividades deveriam ser atualizadas por outros setores da organiza o usando um mecanismo como uma ferramenta de workflow e quais deveriam ser atualizadas diretamente pelo gestor do projeto O estudo da integra o dos conceitos gerenciais advindos do PMBOK com o metamodelo do SPEM permitiu elaborar uma vis o mais ampla de como a ger ncia de projetos pode positivamente contribuir no desenvolvimento de um produto de software Assim o metamod
326. tamb m uma associa o dessa atividade com um stakeholder capaz de desempenhar aquele papel 16 Uma atividade somente pode atualizar ou consultar um produto de trabalho que j tenha sido criado por uma atividade antecessora 17 Uma atividade pode ou n o ter baselines Se tiver a atividade original deve ter o atributo IsBaseline false e todas as outras atividades relacionadas via a associa o Baselines devem manter IsBaseline como true 18 Na classe associativa ActivityStakeholderWork o Stakeholder associado deve possuir o papel que se est associando atividade 19 O papel do stakeholder envolvido deve ser compat vel com o tipo de atividade 20 O produto de trabalho envolvido deve ser compat vel com o tipo de atividade 21 Uma disciplina modela apenas uma cole o de atividades produtivas que cont m um objetivo comum 22 Os produtos podem ser documentados utilizando v rias linguagens Entretanto um produto espec fico deve ser documentado somente com uma linguagem espec fica 23 Uma ferramenta gerencial n o pode ser relacionada com atividades que produzem ou modificam um produto de trabalho produtivo apenas com um produto de trabalho gerencial No entanto pode consultar um produto de trabalho produtivo 24 Uma ferramenta produtiva n o pode estar relacionada com atividades que produzem ou modificam um produto de trabalho gerencial apenas com um produto de trabalho produtivo No entanto pode consultar um produto de trabalh
327. tamente da metaclasse 206 ExtensibleElement A metaclasse kind uma especializa o da metaclasse ExtensibleElement Esta metaclasse usada para qualificar outras inst ncias de metaclasse do metamodelo SPEM 2 0 com tipos definidos pelo usu rio Prosseguindo com e explana o sobre as metaclasses do pacote Core t m se as mostradas na Figura 74 Inicialmente a metaclasse ParameterDirectionKind uma enumera o que representa par metros de entrada in sa da out e tamb m de entrada e sa da inout para as inst ncias das metaclasses e subclasses de WorkDefinition Esses par metros s o definidos atrav s do atributo direction definido para a classe WorkDefinitionParameter que uma generaliza o abstrata para elementos do processo e representa os par metros para as metaclasses e subclasses de WorkDefinition BERS de Constructs WorkDefinitionPerformer i jlinkedWorkDefinition postcondition enumera o n ParameterDirectionKind precondition itenstraint de Constructs Figura 4 Metaclasses do pacote Core A metaclasse WorkDefinition uma metaclasse abstrata que generaliza todas as defini es de trabalho no metamodelo SPEM 2 0 Nos pacotes ProcessStructure e MethodContent respectivamente essa metaclasse especializada em atividades e tarefas No pacote Core a metaclasse WorkDefinition pode conter pr e p s condi es que s o representadas pela metaclasse Con
328. tanto o modelo SPIM possui um conjunto de regras apresentadas no Cap tulo 6 que auxilia o gerente de projetos na antecipa o da identifica o das atividades dos fluxos organizacionais consequentemente no replanejamento do projeto de software devido exist ncia de rela es de depend ncia destas atividades com as atividades do projeto Neste exemplo para evitar que o Projeto 1 tenha alguma altera o nos prazos de suas atividades o modelo SPIM informa ao gestor que ele deve entrar em contato com o departamento de compras da organiza o antes do in cio previsto do projeto tempo zero Assim o gestor j deve fazer a solicita o do novo servidor web antes do in cio do projeto 7 3 Limita es do Experimento Especificamente sobre a realiza o do estudo experimental realizado destacam se as seguintes limita es e A primeira limita o deste experimento est relacionado com a quantidade de indiv duos que participaram cerca de 36 pessoas Apesar deste n mero de participantes ser inferior ao desejado ele ainda satisfat rio para fins da pesquisa tendo em vista a avalia o anal tica Outra limita o est relacionada ao perfil dos participantes Apesar dos esfor os dos pesquisadores em aplicar este estudo experimental em empresas inclusive foi realizado uma palestra gratuita nos audit rios da PUCRS somente alunos de p s gradua o em gest o de projetos se prontificaram a participar do experimento E
329. te a reprograma o completa executada imediatamente Os resultados indicam que o desempenho de agendamento peri dico deteriora quando o per odo de reescalonamento aumenta 4 1 2 3 T cnicas de Programa o Din mica A programa o din mica das atividades dos projetos tem sido foi resolvida utilizando uma diversidade de t cnicas SUH93 SHU96 STO96 BRA99 heuristicas 19 meta heuristicas sistemas baseados em conhecimento logica fuzzy redes neurais t cnicas h bridas e os sistemas multiagentes 4 1 2 3 1 Heuristicas Heuristicas neste contexto s o m todos de repara o da programa o para problemas espec ficos que n o garantem encontrar uma programa o ideal mas tem uma razo vel capacidade de encontrar boas solu es em um curto espa o de tempo As heuristicas mais comuns de repara o programa o s o repara o da programa o de deslocamento para a direita right shift repara o da programa o match up e repara o parcial da programa o A heur stica de deslocamento para a direita desloca o tempo das tarefas restantes da programa o para frente considerando a quantidade de tempo ocioso dos recursos envolvidos A estrat gia de repara o da programa o match up faz o reagendamento das atividades para possam corresponder com o calend rio inicial em algum momento no futuro repara o parcial da programa o faz o reagendamento apenas das tarefas em atraso ou fracasso Abu
330. te ocorrem outras modifica es sobre o projeto para de adequ lo nova realidade Assim efetivamente s o provocados outros eventos como consequ ncia tais como os eventos identificados como EA3 EA4 e EAS Dessa forma embora na literatura se tenha identificado explicitamente tal acontecimento como um evento na pr tica isso se traduz como a ocorr ncia de outros eventos diretamente relacionados A inclus o e o cancelamento de um projeto por sua vez tamb m podem ser vistos na pr tica como altera es no pool de recursos e no conjunto de atividades a serem realizadas Sendo assim quando se registram as atividades de um novo projeto ou quando um projeto integralmente removido e por consequ ncia todas as suas atividades tamb m tais altera es afetam tanto os recursos envolvidos quanto as atividades do projeto 4 2 2 2 Resposta aos Eventos em Tempo Real Uma vez identificados os eventos parte se para a defini o de conjuntos de a es que s o executadas sempre que um evento de reconfigura o ocorre Conforme se verificou h a es gerenciais que podem ser tomadas para minimizar o impacto de determinados eventos Tais a es est o geralmente inclu das em planos de riscos PMIO8S No entanto essas s o geralmente a es de longo prazo como manter alguma reserva ou prever a es de recupera o nos planos de risco O interesse desta tese contudo est em a es de curto prazo que devem ser tomadas imed
331. te ao gerente de projetos no planejamento e tratamento das atividades relativas aos demais fluxos de atividades da organiza o aqui denominados fluxos organizacionais Durante a execu o das atividades de um projeto de software o gerente de projetos pode n o possuir todas as informa es relevantes para o projeto Por exemplo o gerente de projetos pode precisar contatar o setor de recursos humanos sobre a necessidade de contrata o de pessoal para um determinado projeto de desenvolvimento de software A prepara o t cnica e a libera o de uma sala ou equipamento testes s o outros exemplos cujas atividades n o s o exclusivas de um projeto em especial mas de um fluxo comum da empresa compartilhado pelos projetos em andamento e que utiliza recursos n o alocados diretamente ao projeto de software Dessa forma pode haver tamb m uma rela o de depend ncia entre as atividades pertencentes a estes dois tipos de fluxos de trabalho A dificuldade para identificar esta interdepend ncia dos fluxos de trabalho durante o planejamento de atividades pode afetar negativamente o projeto resultando por exemplo no aumento dos custose ematrasos nos prazos do projeto O modelo SPIM foi concebido considerando a necessidade do gerente de projetos obter acesso as informa es pertencentes aos outros departamentos da organiza o durante o planejamento de projetos de software O evento compreende uma apresenta o do modelo SPIM e a realiza o
332. te modelo define uma classe chamada RelevantStakeholder que descreve os recursos que de fato atuam no projeto e que pode ser de dentro da empresa classe TeamMember ou de empresas terceirizadas classe TnirdPartyMember Neste modelo Stakeholder uma classe abstrata e um ator n o relevante classificado como uma inst ncia da classe OtherStakeholder Segundo este modelo uma organiza o classe Organization cont m uma cole o de programas classe Program que por sua vez s o conjuntos de projetos classe Project dirigidos por uma dada parte interessada classe Stakeholder Um stakeholder pode assumir uma ou mais pap is classe Role em um projeto Ao definir uma atividade deve se indicar as partes interessadas relacionadas a execu o desta 35 atividade Para cada associa o deve se indicar qual o papel que cada parte interessada est cumprindo bem como sua carga de trabalho atributo workload Pode se tamb m associar um recurso f sico classe PhysicalResource usado para executar essa atividade O PMBOK Guide representa suas pr ticas em duas dimens es l gicas Uma dimens o descreve as reas de conhecimento classe KnowledgeArea enquanto que a outra dimens o descreve os processos gerenciais de um projeto classe ManagementProcess OS quais est o contidos em cinco grupos de processo classe ProcessGroup AS reas de conhecimento s o respons veis por descrever as principais compet ncias que os gerente
333. te o planejamento do projeto Como considera o final a maioria dos entrevistados concluiu que o modelo SPIM contribui na identifica o e mensura o dos custos indiretos do projeto devido ao conceitorelacionado s atividades gerenciais de apoio Al m disso quase 50 dos entrevistados notou uma redu o no tempo durante o processo de elabora o do projeto Os resultados coletados na pesquisa reafirmam os benef cios que o modelo SPIM fornece na resolu o dos problemas relacionados com a defini o inadequada de tarefas devido obscuridade em visualizar a interdepend ncia entre os fluxos organizacionais e os fluxos dos projetos 7 2 Avalia o Anal tica atrav s de Cen rios Esta segunda avalia o foi realizada de forma anal tica ou seja verificando se os resultados produzidos pelo modelo em fun o da ocorr ncia de eventos sobre cen rios simulados O objetivo desta avalia o foi de mostrar a integra o do modelo SPIM com o modelo de refer ncia para reconfigura o din mica de projetos de software proposto em Callegari CAL10 Este modelo de refer ncia sugere tratar as altera es ocorridas durante a execu o dos projetos de software atrav s de um ciclo de chamada de propostas Call For Proposal CFP Resumidamente a CFP composta pelas posi es detrabalhos comprometidas em fun o de um determinado evento Atrav s desta informa o poss vel identificar os recursoscandidatos para estas posi
334. tecnologias procedimentos e artefatos que s o necess rios para compreender desenvolver e manter um produto de software Definir um processo de desenvolvimento de software envolve v rias informa es como atividades a serem desempenhadas recursos utilizados artefatos consumidos e gerados dentre outras FAL98 WER96 apud MACOO Para Derniame Kaba e Warboys DER99 os principais conceitos ligados sua modelagem s o e Atividade opera o at mica ou composta ou uma etapa de um processo As atividades visam gerar ou modificar um conjunto de artefatos incorporando e executando procedimentos regras e pol ticas organizacionais Algumas atividades podem ser decompostas em subatividades embora isso n o seja obrigat rio 28 Artefato informa o desenvolvida e mantida em um projeto de software Alguns artefatos podem ser decompostos em subartefatos embora isso n o seja obrigat rio Dire o s o procedimentos regras e pol ticas organizacionais que dirigem atividades e geralmente est o estruturados na forma de manuais Recurso um fator necess rio na execu o de uma atividade Os recursos devem ser divididos em executores agentes humanos do processo e ferramentas agentes computadorizados que s o usados tradicionalmente no desenvolvimento de software Outra informa o importante ligada defini o de processos de software o que se deseja alcan ar a partir de sua utiliza o Nesse sentido Tyr
335. tegra o de t cnicas tais como redes neurais simula o e sistemas especialistas A maioria dos sistemas de programa o de atividades s o centralizados e hierarquizados Sistemas centralizados proporcionam uma vis o global consistente da situa o da empresa No entanto a experi ncia pr tica tem indicado que esses sistemas tendem a ter problemas com a rea o s perturba es advindas de eventos em tempo real Assim diferentes pesquisas dizem respeito utiliza o de sistemas multiagentes na programa o din mica A Principal motiva o na concep o destes sistemas descentralizar o controle de sistemas de programa o reduzindo a complexidade aumentando a flexibilidade e melhorando a toler ncia a falhas Os agentes possuem a capacidade de observar o ambiente de se comunicar e cooperar uns com os outros Sua autonomia local permite que aos agentes responder a varia es locais localmente aumentando a robustez e da flexibilidade do sistema Neste cap tulo foram apresentados v rios m todos de programa o din mica incluindo heuristicas meta heuristicas sistemas baseados em conhecimento l gica fuzzy redes neurais redes de Petri e os sistemas multiagentes O estudo comparativo apresentou indicativos de que n o h uma solu o tima Entretanto a integra o de conceitos poder resultar em um sistema com flexibilidade e robustez necess ria para a programa o din mica A pr xima se o apresenta a d
336. tegration of Project Management with Organizational Flows In ICIS 2012 International Conference on Information Systems Penang Malaysia 2012 ROSITO M CALLEGARI D BASTOS R Project Management and software Development Processes Integrating PMBOK and OPEN International Journal of Computer and Communication Engineering vol 6 2012 pp 139 147 ROSITO M BASTOS R An Integrated Environment for Software Project Planning In IADIS 2012 International Conference Applied Computing Madrid Spain 2012 ROSITO M BASTOS R A Model to Integrate Software Project Management with Organizational Workflows In ISDA 2012 International Conference on_ Intelligent Systems Design and Applications Kochi India 2012 ROSITO M RIBEIRO M BASTOS R An Experimental Study on the Dynamic Reconfiguration of Software Projects In ICEIS 2013 International Conference on Enterprise Information Systems Angers France 2013 ROSITO M BASTOS R SPIM An Integrated Model of Software Project Management and Organizational Workflows International Journal of Computer Information Systems and Industrial Management Applications vol 6 2014 pp 160 179 SABUNCUOGLU l amp BAYIZ M Analysis of reactive scheduling problems in a job shop environment European Journal of Operational Research vol 126 3 2000 pp 567 586 SARIN S C SALGAME R R Development of a knowledgebased sy
337. ternativas o m todo tradicional de planejamento do projeto e o m todo usando o modelo integrado de planejamento SPIM Portanto o experimento visa examinar a influ ncia destas alternativas sobre o valor da vari vel de resposta Algumas caracter sticas as quais se gostariam que permanecessem invari veis par metros no entanto podem variar durante o experimento Essas varia es indesej veis s o chamadas de vari veis de bloqueio Neste experimento o n vel de experi ncia em planejamento de projetos uma vari vel de bloqueio Depois de estabelecer os par metros fatores vari veis de bloqueio e vari veis de resposta um tipo de design de experimento teve que ser escolhido Existem diferentes designs de experimentos em fun o do objetivo do estudo experimental do n mero de fatores das alternativas desses fatores e do n mero de varia es indesej veis entre outras caracter sticas Para este experimento conforme mencionado anteriormente cinco diferentes cen rios de projeto de desenvolvimento de software foram desenvolvidos com o objetivo de abordar os riscos do projeto de software diferentes vide Ap ndice C O primeiro cen rio diz respeito compatibilidade da atribui o do papel das partes interessadas envolvidas com o tipo de atividade de gest o ou de produ o O segundo 156 cen rio est relacionado com a intera o entre os fluxos organizacionais para a aquisi o de novo hardware ou software durante o
338. tes Agenda a Resposta An lise de Propostas Figura 34 Processo para gera o de propostas usando arquitetura multiagentes SCH10 CFP Tarefas Modelo de Reconfigura o Desta forma ap s completar esse ciclo de execu o o Agente Gerenciador de Propostas analisa as respostas geradas pelos Agentes Recurso ajustando as nas prerrogativas do modelo de reconfigura o CAL10 e assim as encaminha para que sejam analisadas neste modelo Ap s essa vis o geral sobre o funcionamento do modelo de reconfigura o apresenta se a modelagem conceitual correspondente proposto por Callegari CAL10 No modelo vide Figura 35 h um componente fundamental chamado ProjectElement que representa um elemento de projeto Os recursos as atividades os artefatos e at mesmo os pr prios projetos s o tipos especiais de elementos de projeto a saber Resource Activity NorkProduct e Project s atividades possuem restri es de depend ncia entre si definido atrav s da classe ActivityDependence Este modelo segundo o autor est focado nos elementos considerados fundamentais para a especifica o do modelo de reconfigura o Desta forma no modelo destacam se os elementos que representam os pap is desempenhados pelos recursos classe Role e tamb m as suas respectivas habilidades classe Skill Todo elemento de projeto ProjectElement definido como uma poss vel fonte origem de eventos Tal comportamento
339. tividades restri o de recursos e etc 105 3 A restrigao de tempo de uma atividade sera mapeada para o arco de entrada do lugar p 4 O mecanismo de mapeamento da atividade fict cia A Ey Ew o mesmo que a das outras atividades mas n o h nenhuma restri o de tempo no arco de entrada 5 A dire o da seta da TCPN consistente com a do diagrama de rede Para efeito deste conjunto de passos para a gera o da RdP observou se a necessidade das seguintes dedu es e Dedu o 1 A hora de in cio mais cedo EST da atividade A E Ey o momento em que uma ficha depositada para o lugar p E Ey da TCPN e Dedu o 2 O tempo de t rmino mais tarde LFT da atividade A Eu Ey o momento em que umaficha removida do lugar p E Ev Desta forma a rede de Petri que corresponde s informa es contidas na WBS tais como atividades restri es de tempo aloca es de recursos etc gerada atrav s das seguintes regras I Cada atividade do projeto transcrita como um lugar umatransi o e um arco de entrada ligando o lugar transi o esta ocorr ncia ilustrada pelaFigura 19 O lugar que representa a atividade inicial do projeto o lugar Figura 19 Representa o de uma atividade do projeto para uma RdP 2 O ponto de in cio do projeto definido pela aloca o de uma ficha em um lugar da RdP Esta ficha depositada no in cio do fluxo ou seja no lugar i 3 Um ponto no p
340. tivo do PMBOK Guide identificar um subconjunto dos conhecimentos sobre ger ncia de projetos que seja reconhecido genericamente como sendo uma cole o de boas pr ticas Este documento define nove reas de conhecimento da ger ncia de projetos integra o escopo custo qualidade recursos humanos comunica es riscos aquisi es e tempo Destaca se no presente trabalho a ger ncia do tempo do projeto que respons vel por descrever os processos necess rios para assegurar que o projeto termine dentro do prazo previsto Os processos principais da ger ncia do tempo s o os 33 seguintes defini o das atividades sequenciamento das atividades estimativa da dura o das atividades desenvolvimento do cronograma e controle do cronograma Cada um destes processos caracterizado por entradas ferramentas e t cnicas e saidas O PMBOK por m n o um processo em seu sentido estrito pois n o determina quais s o as a es e nem indica como estas devem ser executadas para o correto desenvolvimento de um projeto Al m disso o PMBOK dito mais compat vel com atividades industriais e portanto n o aborda especificamente processos de desenvolvimento de software SCHO2 CALO7 2 4 1 2 Modelo de Refer ncia para o PMBOK Para efeito da discuss o proposta por esta pesquisa observa se que os conceitos do PMBOK s o em sua maioria representados por textos descritivos Entretanto objetivando comparar dois modelos e
341. tos mais complexos podem ser modelados pela adi o de mais locais e transi es no diagrama Transi es tamb m podem ter tempos associados redes de Petri temporizadas e os tokens podem ter diferentes valores e atributos ao longo da rede redes de Petri coloridas Entretanto poss vel simular processos utilizando apenas os elementos b sicos de redes de Petri D e F1 TH P2 Figura 30 Resultado ap s disparo da transi o T1 112 A Figura 31 cont m a descri o em PNML da rede apresentada na Figura 29 As informa esgr ficas n o est o presentes para simplificar o exemplo lt pnml xmlns http www example org pnml gt net id nl gt place id pi gt lt arc id al source pl target t1 gt lt transition id ti gt lt arc id a2 source t1 target p2 gt place id p2 gt lt net gt lt pnml gt Figura 31 Um exemplo simplificado do formato PNML 5 5 Considera es Finaisdo Cap tulo Este Cap tulo apresentou o estudo realizado nesta tese de doutorado sobre a utiliza o de redes de Petri na gest o de projetos Inicialmente foram apresentados o vocabul rio e conceitos utilizados na modelagem de sistemas a eventos discretos Em seguida foram discutidas principais vantagens identificadas na aplica o das redes de Petri na gest o de projetos de software Ap s foi apresentado o mecanismo de mapeamento entre o diagrama de rede e a rede de Petri utilizado nesta tese Finalm
342. tudos foi realizada em 3 passos 1 leitura de t tulos e resumos abstract dos artigos retornados 2 leitura dos artigos completos e 3 sele o dos artigos que traziam solu es relacionadas com a reconfigura o de projetos Nessa ultima etapa alguns artigos que ficaram de fora desse universo foram utilizados como referencial te rico por apresentarem importantes conceitua es B 3 2 Execu o da Sele o Sele o inicial de estudos a busca em todos os mecanismos resultou em 132 artigos Avalia o da qualidade dos estudos 10 estudos ou 7 57 da amostra inicial foram selecionados para a extra o de informa es Revis o da sele o a sele o de estudos foi aprovada 220 B 1 4 EXTRA O DE INFORMA ES B 4 1 Crit rios de Inclus o e Exclus o de Informa es Conforme descrito no Cap tulo 4 B 4 2 Formul rios para Extra o dos Dados Os diferentes aspectos identificados est o descritos no Cap tulo 4 B 4 3 Execu o da Extra o Conforme descrito no Cap tulo 4 B 4 4 Resolu o de Diverg ncias entre os Pesquisadores N o houve diverg ncias B 5 SUMARIZACAO DOS RESULTADOS B 5 1 C lculos Estat sticos sobre os Resultados N o se aplica B 5 2 Apresenta o dos Resultados em Tabelas Vide Tabela 6 do Cap tulo 4 B 5 3 An lise de Sensibilidade N o se aplica B 5 4 Plotagem N o se aplica B5 5 Coment rios Finais e N mero de estudos foram retorna
343. tware e as atividades pertencentes ao fluxo organizacional Clique na atividade que depende do resultado da realiza o do fluxo organizacional para que seja iniciada Ap s selecione a aba Campos Personalizados No campo personalizado chamado Fluxos Organizacionais informe o nome do fluxo organizacional tenha aten o para que tenha exatamente o mesmo nome definido na tabela acima Ative o filtro listado abaixo e fa a a valida o do projeto Associa o com os Fluxos Organizacionais Salve o arquivo com o nome Cen rio3 SeuNome Respostas Resposta a S Arquivo m Sever Veja abaixo uma parte do projeto a ser avaliado no cen rio 3 i Nome da tarefa Dura o T LS Elabora o 6 dias B Area de Engenharia 5 dias 5 Definir Arquitetura 3 dias 10 Analise dos documentos de ERS e Vis o An 2 dias 11 Colocar Artefatos sob Rastreabilidade 1 dia 12 Teste da Arquitetura 2 dias 13 Finalizar Fase de Elabora o 1 dia 14 Constru o 12 dias 15 Arquitetura 4 dias 16 Defini o do processo de implementa o 1 dia 17 IBM Modelar Banco de Dados 2 dias 18 Especifica o Requisitos Release 1 0 T dias 19 RNF6 Front End em Ingl s DSW 2 dias 20 RNFS Constru o do Front End ETR 4 dias z1 RF227 Manter Perfis ERR 3 dias 22 Especificar Teste dias 23 Elaborar Especifica o de Plano de Teste Ini 2 dias 24 Executar Testes 2 dias do Executar Plano de Teste 2 dias 26 Finalizar Fase d
344. tware em mem ria Ap s poss vel exportar estas informa es para um arquivo com extens o mpp A pr xima subse o apresenta maiores detalhes sobre o processo de exporta o das informa es pelo SPIT 6 3 4 4 Pacote IO A partir do momento em que o processo de parsing da entrada se encerra tem se um objeto petriNet pronto para ser persistido seja no formato de arquivo mpp ou pnml As classes envolvidas na grava o de arquivos est o encapsuladas no pacote integratedModel compiler core io Estas classes devem implementar a interface IWriter existente neste pacote A instancia o dessas classes feita de maneira an loga utilizada na etapa de parsing dos arquivos de entrada atrav s da classe WriterFactory classe WriterFactory respons vel por gerar inst ncias das classes de grava o de arquivos de acordo com a extens o do arquivo de sa da desejado mpp ou pnml Esta abordagem trouxe diversas facilidades para o processo de gera o dos arquivos de sa da pois pode se especificar diferentes formatos de arquivos de sa da a partir de um nico modelo mantido na mem ria O writerpara documentoscom extens o pnm foi desenvolvido utilizando o XML DOM API do Framework Net enquanto que o writer para documentos com extens o mpp foi utilizado com apoio da biblioteca Microsoft Project Object Library 6 3 4 4 1 Gera o da Rede de Petri A gera o da rede de Petri que represent
345. u para a realiza o de um segundo estudo experimental agora envolvendo trinta e seis alunos de cursos de p s gradua o em Gerenciamento de Projetos os resultados foram publicados em ROS13 Maiores detalhes sobre este segundo estudo experimental sao apresentados nas se es a seguir Cabe salientar no entanto que o experimento possui uma abordagem quantitativa WOH00 de modo que um Survey tamb m foi utilizado para avaliar os dados qualitativos O segundo tipo de avalia ofoi realizado de forma anal tica ou seja verificando se os resultados produzidos pelo modelo em fun o da ocorr ncia de eventos sobre cen rios simulados 7 1 Avalia o atrav s de Estudo Experimental 1 1 1 Planejamento e Execu o do Estudo Experimental Nesta pesquisa as propostas de Juristo e Moreno JURO3 Field FIE05 e Wohlin et al WOHOO foram utilizados como guias para realizar esta experi ncia Assim O processo de experimenta o adotado inclui as seguintes atividades principais 1 Defini o dos objetivos dos experimentos 2 Design dos experimentos 3 Execu o dos experimentos e 4 A an lise dos resultados dados coletados a partir dos experimentos Experimentos baseiam se na an lise de fen menos Assim durante a defini o dos objetivos a hip tese geral definida em termos de quais vari veis do fen meno v o ser examinados A atividade de design envolve a cria o de uma esp cie de plano segundo o qual o exper
346. ubse es a seguir apresentam as caracter sticas sobre o parsing de arquivos de entrada e a gera o de arquivos de sa da 6 3 4 3 Pacote Parser Um parser foi desenvolvido para cada um dos formatos de entrada um para leitura de arquivos importados do Microsoft Project arquivo mpp e um para o formato PNML arquivo pnml Ambos apresentam duas etapas a primeira consiste em agrupar os elementos de acordo com seu tipo tal como lugares transi es e arcos e a segunda consiste em extrair as informa es de cada um dos elementos As classes envolvidas nos processos de leitura e parsing de arquivos est o encapsuladas no pacote integratedModel compiler core parser vide Figura 42 Todos os parsers criados devem implementar a interface IParser existente neste pacote Utilizou se o padr o de projeto chamado Factory atrav s da classe ParserFactory para instanciar objetos deste pacote O padr o Factory fornece uma abstra o ou uma interface e permite que cada subclasse possa decidir qual classe ou m todo deve ser chamado ou instanciado com base nas condi es ou par metros relatados Logo a classe ParserFactory respons vel por criar inst ncias de classes que implementam a classe IParser de acordo com a extens o do arquivo de entrada mpp ou pnml Entretanto nenhum dos parsers desenvolvidos implementa algum tipo de valida o l xica e estrutural Os valores definidos pelos usu rios em ambos os arquivos de ent
347. um projeto de software e os fluxos organizacionais este ltimo procura oferecer algum tipo de suporte para o projeto de software Ainda neste Cap tulo foram apresentados os modelos de refer ncia que foram usados como base para a elabora o do modelo de reconfigura o proposto nesta tese de doutorado Os modelos de refer ncia foram comparados e combinados em um modelo integrado Com rela o vis o sobre o gerenciamento dos projetos optou se por usar como refer ncia o Guia do PMBOK Para os processos de desenvolvimento de software foram pesquisados o RUP OPEN e SPEM Ap s o entendimento sobre a necessidade de integra o dos conceitos advindos da gest o de projetos com os processos de desenvolvimento de software o pr ximo Cap tulo discorre sobre os resultados do estudo realizado para determinar o estado da arte sobre a reconfigura o din mica de projetos de software 68 4 RECONFIGURACAO DINAMICA DE PROJETOS As empresas de software frequentemente fazem uso de conhecimentos de gestao de projetos para a constru o de suas solu es com qualidade e dentro das restri es de escopo tempo e recursos O gerente geralmente cria um plano de projeto para especificar e limitar o escopo do projeto e descreve a estrutura anal tica do projeto em ingl s work breakdown structure WBS e o cronograma do projeto Segundo Schwalbe SCH02 a WBS cont m o esfor o de trabalho envolvido em um projeto e define o escopo total
348. um rascunho do question rio necess rio para a aquisi o dos dados desta pesquisa Posteriormente sera realizada a valida o de face e conte do do protocolo de avalia o da pesquisa por um pesquisador s nior Com base nesta valida o o protocolo poder sofrer pequenas corre es A seguir ser realizado o pr teste com um pesquisador s nior onde foi poss vel realizar os Ultimos ajustes no roteiro de entrevistas D 5 6 Considera es sobre a Validade do Experimento Validade interna Ser o avaliados alguns crit rios tais como e Hist rico a data de aplica o do experimento ser criteriosamente definida evitando per odos nos quais os participantes possam sofrer influ ncias externas e Matura o durante o treinamento ser o utilizadas t cnicas de motiva o para incentivar positivamente os participantes e Sele o dos grupos ser utilizada uma abordagem para nivelar o conhecimento dos participantes atrav s de um treinamento sobre as t cnicas A execu o das atividades ser individual e Difus o durante o treinamento ser desenvolvida uma motiva o que n o incentive intera o entre os participantes Adicionalmente haver um policiamento durante a experimenta o para evitar este tipo de intera o 236 Validade externa Para esta avalia o sera adotada a intera o da sele o ou seja os participantes que foram selecionados possuem um perfil apto aos tratamentos do experimento
349. uma CFP com esta configura o de atividades para o modelo de reconfigura o 182 Figura 70 Rede de Petri para o Cen rio 2 atraso no fluxo organizacional 7 2 4 Cen rio 3 o realizar o planejamento do Projeto 1 antes de iniciar a execu o deste projeto o gestor identificou a necessidade de aquisi o de um servidor web Assim o gestor planejou entrar em contato com o setor de compras da organiza o no primeiro dia de execu o deste projeto mais especificamente no tempo 1 do cronograma A execu o do fluxo organizacional adquirir materiais em resposta ao evento EA3 descrito no Cap tulo 4 tem a dura o de 10 unidades de tempo Ap s o gestor informa se alguma atividade do projeto depende do t rmino da execu o deste fluxo organizacional Esta rela o de depend ncia poss vel atrav s do campo customizado adicionado ao Microsoft Project chamado Fluxo Organizacional Neste campo personalizado o gestor adiciona uma rela o de preced ncia entre atividades do projeto com atividades dos fluxos organizacionais A Figura 1 ilustra esta situa o e destaca as tarefas que foram afetadas por esse evento estas atividades foram comprometidas porque o recurso servidor webest originalmente alocado nelas Tempo il kd cl dil Ka Ru Dl tel Di Hd d o Gl a E RTT TET ETT ey tt TTIo ENE TTT TT TT Te PT PT EEE Figura 71 Cen rio 3 aquisi o de servidor web Apos identificar as ta
350. ura anal tica do projeto subclasses de BreakdownElements O auto relacionamento definido para o elemento Activity chamado usedActivity permite o reuso do conte do definido para uma atividade em outra atividade Dessa forma torna se poss vel herdar a estrutura definida para uma atividade em termos de seus elementos aninhados em uma segunda atividade O metamodelo SPEM 2 0 define alguns tipos de heran a para o relacionamento usedActivity OS quais s o estabelecidos pelo atributo useKind da metaclasse Activity e pela metaclasse de enumera o ActivityUseKind Esses tipos de heran a s o os seguintes e na este o valor default do atributo useKind de todas as atividades Esse valor usado para atividades que n o instanciam a rela o usedActivity e extension este mecanismo permite reutilizar dinamicamente as subestruturas elementos aninhados pela rela o de composi o de uma atividade em outras atividades Dessa forma a atividade que associada outra pela rela o usedActivity e possui o valor para o atributo useKind igual a extension herda todo conteudo dessa atividade e localContribution este mecanismo permite que adi es locais contribui es sejam feitas em atividades que est o sendo herdadas atrav s do mecanismo de extens o extension Uma atividade A poderia por exemplo herdar toda estrutura da atividade B pelo mecanismo de extens o extension Contudo poderia ser necess rio fazer adi es locais
351. urso de modo que permita automatizar os processos de aloca o de recursos em projetos de software e prever a informa o de carga de trabalho workload para as associa es de um papel atividade e stakeholder preparando para a automatiza o e e distinguir as poss veis rela es entre uma atividade e um artefato criar atualizar consultar e deve permitir a simula o de cen rios em resposta a eventos internos eexternos Durante a defini o do modelo SPIM um conjunto de regras foi estabelecido para garantir a consist ncia do modelo Todas as regras bem como os conceitos por tr s SPIM foram avaliados em uma s rie de entrevistas com experientes gerentes de projeto de software cujos resultados podem ser vistos em ROSO08 Neste sentido foi desenvolvida anteriormente uma primeira vers o de uma ferramenta que atua como um add in para um software comercial de gerenciamento de projetos Esta ferramenta chamada Software Planning Integrated Tool SPIT foi desenvolvida para demonstrar a viabilidade dos conceitos propostos no modelo SPIM Mais detalhes sobre a ferramenta SPIT s o apresentados a seguir 6 3 Implementa o do Modelo Partindo se do modelo SPIM realizou se a implementa o dos conceitos nele presentes A implementa o foi realizada em linguagem C net utilizando o framework net vers o 4 5 com acesso ao banco de dados SQL Server 2008 Foram utilizados o 126 ambiente de programa o Microsoft Vi
352. utos de trabalho classe workProduct Assim a classe ActivityDetail foi definida como respons vel por manter estes relacionamentos enquanto que a classe Activity foi definida como uma agrega o de uma ou mais classes ActivityDetail Al m disso a classe ActivityDetailDependency define se uma ou mais atividades podem ser executadas em paralelo e se duas atividades podem ser sobrepostas O PMBOK Guide representa as suas pr ticas em duas dimens es l gicas Uma dimens o define nove reas de conhecimento classe KnowledgeArea enquanto que a outra dimens o descreve trinta e nove processos de gest o de um projeto classe ManagementProcess que est o organizados em cinco grupos de processos classe ProcessGroup As areas de conhecimento s o classificadas em reas centrais de conhecimento classeCoreKnowledgeArea tais como escopo a equipe custo e 124 qualidade ou reas de facilita o do conhecimento classeFacilitatingKnowledgeArea como recursos humanos comunica es riscos e dos contratos A classe Artifact representa algo que produzido consumido ou modificado como documentos modelos ou c digos fonte durante a execu o das atividades De acordo com o metamodelo SPEM cujos conceitos encontram se no pacote PDS uma atividade suporta o agrupamento de l gico de elementos contidos na WBS classe BreakdownElement O auto relacionamento definido para a classe Activity permite a reutiliza o do conte do definido
353. uxos Organizacionais apresentada por Maur cio Covolan Rosito como parte dos requisitos para obten o do grau de Doutor em Ci ncia da Computa o aprovada em 23 01 2014 pela Comiss o Examinadora Prof Dr Ricafdo Melo Bastos PPGCC PUCRS Prof Dr Rafael Prikladnicki PPGCC PUCRS Profa Dra Edimara Mezzomo Luciano PPGAD PUCRS Homologada em dm Ds P Conforme Ata No pela Comiss o Coordenadora Prof Dr Luiz Gustavo Le o Fernandes Coordenador Campus Central Pl ICRS Av Ipiranga 6681 P 32 sala 507 CEP 90619 900 Fone 51 3320 3611 Fax 51 3320 3621 E mail ppqcc pucrs br www pucrs br facin pos AGRADECIMENTOS 7 A constru o de uma tese de doutorado certamente uma das tarefas mais desafiadoras einteressantes da vida acad mica Devido ao alto grau de dedica o e envolvimento exigidos somente foi poss vel alcan ar este objetivo gra as ao apoio e aparticipa o dos professores colegas familiares e amigos que conviveram comigo nesteperiodo Desta forma gostaria de agradecer as pessoas e as institui es que contribu ram para arealiza o deste trabalho Meu agradecimento especial ao Prof Dr Ricardo Melo Bastos que n o hesitou em dar suas importantes contribui es ao longo de todo o processo indicando novos caminhos e incentivando a continuidade do trabalho al m de contar com sua amizade e disponibilidade Ao Prof Dr Marcelo Blois Ribeiro
354. v duos ficam entediados ou cansados com o experimento ao longo do tempo e colocam menos esfor o para a execu o do experimento com o passar do tempo Por esta raz o este experimento foi realizado durante o tempo de aula dos alunos Finalmente foi considerado o caso oposto ao efeito t dio o efeito entusiasmo enthusiasm effect Este ponto de motiva o pode surgir quando um novo m todo est para ser testado contra um m todo tradicional Os indiv duos que aplicam o m todo tradicional podem n o estar motivados para fazer um bom trabalho enquanto que aqueles que aplicam o novo m todo podem estar mais inspirados e motivados em aprender algo novo Para evitar essa situa o foi realizado um experimento s escuras blind experiment uma t tica em que os sujeitos n o est o familiarizados tanto com as hip teses formuladas ou objetivos do experimento 7 1 1 3 Execu o do Experimento Esta terceira atividade envolve a prepara o implementa o e valida o dos dados obtidos no experimento A realiza o do experimento ocorreu em novembro de 2011 quando um conjunto de participantes realizou o experimento em um ambiente controlado laborat rio de computadores dasinstitui es de ensino superior O problema estudado correspondeu a cinco cen rios que simularam situa es ocorridas em projetos de desenvolvimento de software toy example Inicialmente todos os participantes receberam um breve treinamento sobre o modelo de pla
355. vidades de treinamento da equipe Financeiro Comprar Fluxo Organizacional respons vel pela aquisi o de equipamentos Negocios Parceria Fluxo Organizacional respons vel pela realiza o de parcerias e contrata o de empresas terceirizadas Descri o do Cen rio 2 Necessidade de aquisi o de um novo hardware ou software durante o projeto nici 29 11 2011 29 11 2011 29 11 2011 2911 2011 3011 2011 30 11 2011 0412 2011 0512 2011 0512 2011 1312 2011 15 12 2011 15 12 2011 1512 2011 15 12 2011 1512 2011 1512 2011 20 12 2011 20 12 2011 2 12 2011 on 12 2011 26 12 2011 26 12 2011 Sn 2 2011 2fii2f2011 29 12 2011 2512 2011 29 12 2011 0401 2012 27122011 FANANA T rmi 17 01 2012 14 12 2011 29 11 2011 2911 2011 14 12 2011 01122011 0212 2011 072 2011 1212 2011 1412 2011 2 12 2011 21 12 2011 21 12 2011 22 12 2011 1912 2011 1912 2011 21 12 2011 ee 12 2011 2 12 2011 on 12 2011 09 01 2012 20 12 2011 Sn 2 2011 em 12 2011 06 01 2012 301242011 03701 2012 0801 2012 20 12 2011 RADON 4 Predecesso Do ea dm 18 13 17 74 Orienta es 1 Abra o arquivo Cenario2 2 Durante a execu o da atividade Revis o de estimativas no dia 17 11 2011 voc se depara com a necessidade de comprar um novo servidor para hospedar o c digo fonte cujo tempo de dura o de 4 quatro dias 241 do projeto Esta uma atividade pertencente ao fluxo organizacional do set
356. vimento do Ci p7 Desenvolvimento do Ci p8 Integra o dos Compo p9 Realiza o de testes d p10 Encerramento do Proj H Transactions b Defini o da Arquitetur p5 Desenvolvimento do Ci Project D NCenario2 mpp x Generate Petri net Results The Petri net was successfully generated Petri net details Legend Actions Events E Places Place O Place Critical path O Transaction Arc Timeline Type Activity Id p3 Name Defini o da Arquitetura Time 2d Initial Marking O Critical Path Yes ole sla eles Input HashTables inputs Mauricio ti G ssica nd T Laura p5 Fernando 6 lt Fernando Mario inputs details Output HashTables outputs Figura 45 Gera o de redes de Petri no SPIT 6 3 4 3 2 Parsing de arquivos PNML As classes utilizadas para o parsing de um arquivo com extens o pnml s o agrupadas no pacote integratedModel compiler core parser pnml Conforme salientado anteriormente PNML um formato de interc mbio baseado em XML para representar redes de Petri De maneira an loga utilizada na leitura de arquivos com extens o mpp os elementos da rede de Petri representados no arquivo de entrada s o agrupados de acordo com seus tipos local transi o e arco e em seguida s o passados como par metros para as classes respons veis por traduzir os elementos PNML
357. vos produtos de TI desenvolvidos envolvem um modelo computacional e um prot tipo de ferramenta As avalia es do modelo foram realizadas com o aux lio do prot tipo de ferramenta desenvolvido A primeira avalia ofoi realizada atrav s de uma compara o em um estudo experimental entre a proposta de planejamento integrado e a proposta tradicional de planejamento de projetos de software A segunda avalia o foi realizada de forma anal tica ou seja verificando se os resultados produzidos pelo modelo em fun o da ocorr ncia de eventos sobre cen rios simulados A se o a seguir fornece detalhes sobre a metodologia e a gera o do modelo de reconfigura o din mica de projetos de software 1 3 1 Atividades da Pesquisa A elabora o do modelo de reconfigura o din mica proposto nesta pesquisa passou por um conjunto de etapas preliminares Inicialmente para obter maior conhecimento sobre o assunto de pesquisa realizou se um levantamento bibliogr fico e estudo do referencial te rico que permitiu aprofundar os conhecimentos sobre processos de desenvolvimento e sobre o gerenciamento dos projetos de software O estudo sobre processos de desenvolvimento envolveu o Processo Unificado por sua absor o na ind stria de software o OPEN Process Framework devido o seu destaque na comunidade acad mica e o SPEM 2 0 Software amp Systems Process EngineeringMeta Model Specification que um metamodelo desenvolvido pelo Object Ma

Visualizar/Abrir

Contents

Download Pdf Manuals

Related Search

Related Contents