LCIA NORIE MATSUEDA ENAMI

UM MODELO DE GERENCIAMENTO DE PROJETOS PARA UM AMBIENTE DE DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE

MARING 2006

LCIA NORIE MATSUEDA ENAMI

UM MODELO DE GERENCIAMENTO DE PROJETOS PARA UM AMBIENTE DE DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE

Dissertao apresentada ao Programa de PsGraduao em Cincia da Computao da Universidade Estadual de Maring, como requisito parcial para a obteno do grau de Mestre em Cincia da Computao. Orientadora: Prof. Dr. Tania Fatima Calvi Tait.

MARING 2006

Dados Internacionais de Catalogao-na-Publicao (CIP) (Biblioteca Central - UEM, Maring PR., Brasil)
E56m Enami, Lcia Norie Matsueda Um modelo de gerenciamento de projetos para um ambiente de desenvolvimento distribudo de software / Lcia Norie Matsueda Enami. -- Maring : [s.n.], 2006. 215 f. : il. color., figs., tabs. Orientador : Prof. Dr. Tania Fatima Calvi Tait. Dissertao (mestrado) - Universidade Estadual de Maring. Programa de Ps-graduao em Cincia da Computao, 2006. 1. Software - Gerenciamento de projetos. 2. Ambiente de desenvolvimento distribudo de software. 3. Gerenciamento de projetos - Software. 4. Projetos - Software. I. Universidade Estadual de Maring. Programa de Ps-graduao em Cincia da Computao. II. Ttulo.

CDD 21.ed. 003.068

LCIA NORIE MATSUEDA ENAMI

UM MODELO DE GERENCIAMENTO DE PROJETOS PARA UM AMBIENTE DE DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE

Dissertao apresentada ao Programa de Ps-Graduao em Cincia da Computao da Universidade Estadual de Maring, como requisito parcial para obteno do grau de Mestre em Cincia da Computao.

Aprovado em 19/07/2006.

BANCA EXAMINADORA

Prof. Dr. Tania Fatima Calvi Tait Universidade Estadual de Maring DIN/UEM

Prof. Dr. Elisa Hatsue Moriya Huzita Universidade Estadual de Maring DIN/UEM

Prof. Dr. Roberto Carlos dos Santos Pacheco Universidade Federal de Santa Catarina - CTC/UFSC

DEDICATRIA

Dedico este trabalho

Ao meu esposo Widmark, e aos meus pais, Tutae e Tomoe, pelo incentivo, carinho e amor.

AGRADECIMENTOS

A Deus acima de tudo. Ao meu querido esposo Widmark pelo apoio e pacincia. Ao meus pais que sempre me incentivaram a estudar e forneceram a estrutura familiar para que eu pudesse realizar meus empreendimentos. A amiga e Professora orientadora Tania Fatima Calvi Tait que confiou sempre no meu trabalho e me deu a motivao para continuar estudando sempre. Aos meus amigos do Ncleo de Processamento de Dados: Agnes Munhoz Rubira, Andrea Emi Nagai, Antonio da Silva Martins Jnior, Daniel Martins Barbosa, Denerval Mendez Batista, Dilvo Palpitz, Elias Csar Arajo de Carvalho, Fbio Yoshiharu Umada, Gilmar Antonio Beal, Lidia Terumi Yamagata Kakitani, Luis Cesar de Mello, Shyrlei Mitsue Sica de Toledo, Toshie Kinoshita Kume e Vilma Yatsuda Ferreira pelas conversas e pela ajuda nas questes burocrticas, de trabalho e do mestrado. A Profa Dra Elisa Hatsue Moriya Huzita que permitiu a participao no projeto DiSEN. A todos os amigos do Projeto DiSEN em especial: Csar Alberto da Silva, derson Fernando Amorim, Edna Tomie Takano Yanaga, Fabiana Lima, Flvio Luiz Schiavoni, Gustavo Sato, Igos Steinmacher, Igor Wiese e Rafael Gatto. Ao amigo Lcio Gernimo Valentin pelas conversas estimulantes. A Maria Ins Davano pelas conversas e prontido em resolver os problemas. A todos os que participaram da avaliao do trabalho. A Universidade Estadual de Maring, Pr-Reitoria de Administrao e ao Ncleo de Processamento de Dados que permitiram o meu afastamento para cursar o Mestrado. A todos que torceram para o sucesso nesta empreitada.

S sei que nada sei (Scrates)

Estudar, criar e aperfeioar-se constantemente (Funakoshi Gichin)

RESUMO
O desenvolvimento distribudo de software (DDS), o qual permite a cooperao de equipes oriundas de qualquer parte do mundo, tem sido uma das opes para as grandes organizaes desenvolvedoras de software. Trata-se de um fator de alto impacto no desenvolvimento de software que evita a comunicao informal e obriga os membros das equipes a um maior formalismo no desenvolvimento como um todo alm de motivar os membros das equipes pela busca da inovao. Porm, o DDS traz tambm dificuldades de comunicao devido s diferenas culturais e s distncias geogrficas. Este trabalho, ao apresentar um Modelo de Gerenciamento de Projetos (MGP) para o DDS, visa contribuir para a melhoria do controle gerencial em busca de solues para os problemas que este tipo de desenvolvimento pode trazer. Para isso, foram usados como referncia os seguintes MGPs: Project Management Body of Knowledge (PMBOK), Capability Maturity Model Integration (CMMI), Modelo de Gerncia de Projeto Baseado no Project Management Institute (PMI) para Ambiente de Desenvolvimento de Software Fisicamente Distribudo, o Modelo de Maturidade no DDS (MuNDDoS) e tambm outros trabalhos relacionados. Elaborou-se tambm um prottipo do MGP e realizou-se uma avaliao por meio da aplicao de um questionrio com a apresentao do mesmo. O MGP faz parte do Projeto Distributed Software Engineering Environment (DiSEN) e apresenta os seguintes elementos: os usurios de um projeto de DDS, a gerncia de stakeholders ou interessados no projeto, a gerncia do conhecimento, a orientao para minimizar ou eliminar os problemas advindos de diferenas culturais e disperso geogrfica em um ambiente de DDS, a propriedade intelectual, uma ferramenta de apoio ao gerenciamento de projeto, as mtricas e estimativas, a gerncia de riscos, o gerenciamento de requisitos e modelos de documentos.

Palavras-Chave: gerenciamento de projeto, desenvolvimento distribudo de software, modelo de gerenciamento de projeto.

ABSTRACT
The distributed software development (DSD), which permits the cooperation of teams everywhere has been one of the options for the greatest organizations of software development. This kind of development has an influential factor on the software development avoiding the informal communication and it obliges the communication become more formal between staffs members, also it motivates the staffs members by using brand-new technologies. However, the DSD increases communication problems due to the cultural differences and the geographic distances. This work presents a Project Management Model (PMM) for the DSD, and it aims to contribute for the improvement of managing projects by looking for solutions to the problems caused by DSD. In this project, the following PMMs were used: Project Management Body of Knowledge (PMBOK), Capability Maturity Model Integration (CMMI), Project Management Model Based on Project Management Institute (PMI) for the Physically Distributed Software Development Environment, the Maturity Model in the DSD (MuNDDoS) and other related works. A PMMs prototype and a questionnaire were developed to present and evaluate the PMM. The PMM is part of Distributed Software Engineering Environment (DiSEN) Project and it presents the following elements: the users of a DSD project, the stakeholders management, the knowledge management, the training for reducing or eliminating the problems caused by cultural differences and geographic dispersion in a DSD Environment, the intellectual property, a tool to support the Project Management, the metrics and estimations, the risk management, the requirements management and document models.

Keywords: project management, distributed software development, project management model.

LISTA DE FIGURAS
Figura 1. reas da Gerncia de Projetos Relacionadas ao Modelo Proposto......................... 21 Figura 2. GP como uma das reas que Compem um ADDS............................................... 22 Figura 3. Metodologia de Desenvolvimento do Modelo de Gerncia de Projetos Proposto.. 24 Figura 4. Arquitetura do DiSEN (PASCUTTI, 2002) ............................................................ 29 Figura 5. Modelo de Domnio da DIMANAGER (PEDRAS, 2003) ..................................... 31 Figura 6. Funcionamento do Mecanismo de Apoio ao Gerenciamento de RH (LIMA,2004)36 Figura 7. Modelo para Planejamento Organizacional (CLELAND e IRELAND, 2002)....... 47 Figura 8. Processos Principais no GP (SHTUB, BARD e GLOBERSON, 1994) ................. 52 Figura 9. Processos da Administrao de um Projeto (MAXIMIANO, 2002) ...................... 53 Figura 10. Ciclo de Vida do MGP Baseado no PMI para ADDS (ZANONI, 2002) ............. 64 Figura 11. CMMI Staged - Nvel 2 (SEI, 2002) ..................................................................... 67 Figura 12. Modelo de Referncia Proposto (PRIKLADNICKI, 2003).................................. 68 Figura 13. Utilizao de Outros Modelos............................................................................... 77 Figura 14. Componentes do MGP Proposto........................................................................... 78 Figura 15. Elementos do MGP para um ADDS ..................................................................... 79 Figura 16. Exemplo de Classificao de Riscos (CLELAND e IRELAND, 2002) ............... 90 Figura 17. Exemplo de Rastreamento de Requisitos.............................................................. 93 Figura 18. Relao entre uma Ferramenta de Apoio ao GP e o GP da Organizao ............. 95 Figura 19. Hierarquia das Necessidades de Maslow Adaptado (CLELAND e IRELAND, 2002) ...................................................................................................................108 Figura 20. Diviso de Projetos nos Locais ............................................................................111 Figura 21. Janela para Consulta e Alterao de Dados do Local...........................................122 Figura 22. Janela para Cadastramento de Processo...............................................................123 Figura 23. Janela para Cadastramento de Mtricas................................................................124 Figura 24. Janela para Cadastramento de Perfil............................................................................. 124 Figura 25. Janela para Cadastramento do Recurso Material..................................................125 Figura 26. Janela para Cadastramento de Fornecedores........................................................126 Figura 27. Janela para Cadastrar Mtricas para Avaliar o Fornecedor................................ .126 Figura 28. Janela para Cadastramento do Usurio......................................................................... 127 Figura 29. Janela para Definir os Participantes do Projeto....................................................129 Figura 30. Janela para Cadastramento de Projeto..................................................................130 Figura 31. Janela para Cadastramento de Risco do Projeto...................................................131 Figura 32. Janela para preenchimento dos dados do projeto......................................................... 132 Figura 33. Janela para Preenchimento dos Dados da Atividade do Projeto........................... ..........133 Figura 34. Janela para Definir qual Participante ir Executar a Atividade............................. ..........134 Figura 35. Janela para Cadastro de Conhecimento........................................................................ 135 Figura 36. Janela para Associao do Conhecimento com Palavras-Chave. ......................... .........135 Figura 37. Janela com Informaes da Agenda do Engenheiro de Software ........................136 Figura 38. Janela para Cadastramento do Problema..............................................................137 Figura 39. Janela para Associao do Problema com a Tarefa..............................................137 Figura 40. Janela para Cadastramento de Fase do Processo..................................................190 Figura 41. Janela para Cadastramento de Atividade do Processo......................................... 190 Figura 42. Janela para Cadastramento da Dependncia entre Atividades.........................................191 Figura 43. Janela para Cadastramento de Perfil da Atividade do Processo ..........................191 Figura 44. Janela para Cadastramento do Tipo de Recurso Material Necessrio para Executar a Atividade do Processo................................................................................................. 192 Figura 45. Janela para Cadastrar Dependncia entre as Fases do Processo ..........................192 viii

Figura 46. Janela para Associar Mtrica a Atividade do Processo........................................193 Figura 47. Janela para Cadastramento do Tipo de Artefato ..................................................193 Figura 48. Janela para Cadastramento das Aptides do Usurio............................................... 194 Figura 49. Janela para Cadastrar Nvel do Perfil................................................................... ...194 Figura 50. Janela para Definir Participantes do Projeto............................................................195 Figura 51. Janela com Parmetros para Obter os Participantes mais Aptos para Executar a Tarefa....................................................................................................................................... 195 Figura 52. Resultado da Consulta dos Participantes Mais Aptos para Executar a Atividade... 196 Figura 53. Janela para Cadastro de Palavras-Chave.............................................................. ...196 Figura 54. Janela para Consulta do Conhecimento...................................................................197

ix

LISTA DE TABELAS
Tabela 01. Mapeamento entre os processos de GP e os grupos de processos de GP e as reas de conhecimento (PMI, 2004a) ........................................................................... 62 Tabela 02. Aspectos relacionados distribuio fsica dos participantes do projeto no modelo processual do PMI (2004).................................................................................... 71 Tabela 03. Comparao entre os Modelos de Gerncia (ENAMI et al., 2006)...................... 73 Tabela 04. Mapa de Responsabilidade Linear.......................................................................110 Tabela 05. Requisitos e a Correspondncia com os MGP estudados....................................113 Tabela 06. Experincia em GP dos Respondentes................................................................ 143 Tabela 07. Total de Respostas sobre a Resoluo de Problemas. .........................................144 Tabela 08. Totais de No Concordncia com os Riscos na Seleo de Projetos...................146 Tabela 09. Totais de No Concordncia com os Riscos no Planejamento de Projetos.........146 Tabela 10. Totais de No Concordncia dos Respondentes com as Mtricas do MGP ........147 Tabela 11. Totais de No Concordncia com os Modelos de Documentos ..........................147

LISTA DE QUADROS
Quadro 01. Plano do Projeto................................................................................................ .. 99 Quadro 02. Plano de Gerenciamento de Riscos................................................................... .100 Quadro 03. Plano de Gerenciamento de Dados.....................................................................101 Quadro 04. Plano de Gerenciamento de Stakeholders......................................................... .101 Quadro 05. Habilidades/Conhecimentos/Treinamentos dos Membros da Organizao.... ...102 Quadro 06. Documento de Compromisso com os Requisitos.............................................. .102 Quadro 07. Documento para Solicitao de Mudana nos Requisitos..................................103 Quadro 08. Relatrio de Inconsistncias dos Requisitos.......................................................103 Quadro 09. Documento para Recebimento de Propostas de Fornecedores...........................104 Quadro 10. Avaliao dos Produtos Recebidos.................................................................... 104 Quadro 11. Avaliao da Organizao.................................................................................. 104 Quadro 12. Relatrio de Lies Aprendidas......................................................................... 105

LISTA DE ABREVIATURAS
ADDS ADS CMMI DDS DiSEN EAP ES GP MGP MDSODI MOOPP MRL OPM3 PCMM PMI PSP RH SEI SIGP TSP UML UP WBS Ambiente de Desenvolvimento Distribudo de Software Ambiente de Desenvolvimento de Software Capability Maturity Model Integration Desenvolvimento Distribudo de Software Distributed Software Engineering Environment Estrutura Analtica de Projeto Engenharia de Software Gerenciamento de Projeto Modelo de Gerenciamento de Projeto Metodologia de Desenvolvimento de Software Distribudo Metodologia Orientada a Objetos para Processamento Paralelo Mapa de Responsabilidade Linear Organizational Project Management Maturity Model People Capability Maturity Model Project Management Institute Personal Software Process Recursos Humanos Software Engineering Institute Sistema de Informaes da Gerncia de Projetos Team Software Process Unified Modeling Language Unified Process Work Breakdown Structure

xi

SUMRIO
LISTA DE FIGURAS................................................................................................ ............ viii LISTA DE TABELAS............................... ............................................................................ x LISTA DE QUADROS ......................................................................................................... x LISTA DE ABREVIATURAS............................................................................................... xi CAPTULO I Introduo........................................................................................................ 15 1.1 Consideraes Iniciais ..................................................................................................... 15 1.2 Definio do Problema ..................................................................................................... 17 1.3. Objetivos.......................................................................................................................... 17 1.3.1.Objetivo Geral......................................................................................................... 17 1.3.2. Objetivos Especficos ............................................................................................ l7 1.4. Justificativa...................................................................................................................... 17 1.5. Importncia do Tema....................................................................................................... 19 1.6. Referencial Conceitual................... ................................................................................. 19 1.6.1 Ambiente de Desenvolvimento Distribudo de Software ....................................... 20 1.6.2 Projetos ................................................................................................................... 20 1.6.3 Gerenciamento de Projeto....................................................................................... 21 1.6.4 MGP ....................................................................................................................... 22 1.6.5 Mtricas................................................................................................................... 22 1.7 Delimitaes da Pesquisa ................................................................................................. 23 CAPTULO II Metodologia e Desenvolvimento da Pesquisa. .............................................. 24 2.1 Introduo......................................................................................................................... 24 2.2 Fundamentao Terica.................................................................................................... 25 2.3 Elaborao do Modelo...................................................................................................... 25 2.4 Construo do Prottipo ................................................................................................... 25 2.5 Validao e Avaliao do Modelo.................................................................................... 26 2.6 Consideraes Finais ........................................................................................................ 26 CAPTULO III Trabalhos Relacionados ao DDS .................................................................. 27 3.1 Introduo ........................................................................................................................ 27 3.2 Trabalhos Relacionados no Projeto DiSEN ...................................................................... 27 3.2.1 Arquitetura DISEN.................................................................................................. 28 3.2.2 Ferramenta DIMANAGER..................................................................................... 30 3.2.3 Gerao de Informaes Gerenciais a partir da DIMANAGER............................. 32 3.2.4 Componente Estimativa de Custos para a DIMANAGER ..................................... 33 3.2.5 Mecanismo de Apoio ao Gerenciamento de RH..................................................... 34 3.2.6 Aspectos Psicolgicos e Administrativos no Mecanismo de Apoio ao Gerenciamento de RH ............................................................................................ 36 3.2.7 MDSODI................................................................................................................. 37 3.3 Temas Relacionados ao DDS ........................................................................................... 40 3.3.1 Equipes Virtuais...................................................................................................... 40 3.3.2 Diferenas Culturais................................................................................................ 41 3.3.3 Follow-the-Sun........................................................................................................ 42 3.3.4 Nveis de Disperso ................................................................................................ 43 3.3.5 Armazenamento do Conhecimento dos Projetos Distribudos ............................... 43 3.4 Consideraes Finais......................................................................................................................45 xii

CAPTULO IV Gerenciamento de Projetos de Software....................................................... 46 4.1 Introduo......................................................................................................................... 46 4.2 Projetos ............................................................................................................................ 46 4.2.1 Projetos e Planejamento Estratgico....................................................................... 46 4.2.2 Ciclo de Vida de Projetos ....................................................................................... 47 4.2.3 Estrutura Analtica de Projeto.................................................................................... 49 4.3 Gerenciamento de Projeto ................................................................................................ 49 4.3.1 Benefcios do Gerenciamento de Projeto ......................................................................50 4.3.2 Funes da Gerncia de Projetos ...................................................................................51 4.3.3 Principais Processos da Gerncia de Projetos ..............................................................51 4.3.4 Caractersticas do Moderno GP ............................................................................................. 54 4.4 Gerenciamento de Projetos de Software .......................................................................... 55 4.4.1 Processo de Desenvolvimento de Software...................................................................56 4.4.2 Mtricas para o GP de Software .....................................................................................57 4.5 Consideraes Finais........................................................................................................ 59 CAPTULO V Modelos de Gerenciamento de Projetos...............................................................60 5.1 Introduo......................................................................................................................... 60 5.2 Modelo Processual do PMI .............................................................................................. 60 5.3 MGP Baseado no PMI para ADDS .................................................................................. 63 5.4 Modelo CMMI (Capability Maturity Model Integration) ................................................ 65 5.5 MuNDDoS - Modelo de Referncia para o DDS ............................................................. 68 5.6 Comparao entre os Modelos de Gerncia de Projetos .................................................. 70 5.7 Consideraes Finais ....................................................................................................... 74 CAPTULO VI Modelo de Gerenciamento de Projeto Proposto .......................................... 75 6.1 Introduo......................................................................................................................... 75 6.2 Premissas Para o Modelo Proposto .................................................................................. 76 6.3 Composio do MGP Proposto ........................................................................................ 77 6.3.1 Gerncia de Stakeholders........................................................................................ 79 6.3.1.1 Usurios e Informaes Necessrias para o DDS .......................................... 81 6.3.2 Gerncia do Conhecimento..................................................................................... 83 6.3.2.1 Orientao para Minimizar ou Eliminar Problemas Advindos de Diferenas Culturais e Disperso Geogrfica em ADDS.................................................. 86 6.3.2.2 Propriedade intelectual................................................................................... 87 6.3.3 Gerncia de Riscos.................................................................................................. 89 6.3.4 Gerenciamento de Requisitos ................................................................................. 91 6.3.5 Ferramenta de apoio ao GP..................................................................................... 93 6.3.5.1 Mtricas do MGP Proposto ............................................................................ 95 6.3.5.2 Estimativas do MGP Proposto ....................................................................... 98 6.3.6 Modelos de Documentos......................................................................................... 99 6.4 Funes de Gerncia de Projetos no MGP Proposto.......................................................105 6.4.1 Planejamento e Controle ........................................................................................106 6.4.2 Organizao ...........................................................................................................106 6.4.3 Motivao ..............................................................................................................107 6.4.4 Direo...................................................................................................................110 6.5 O MGP Proposto no DiSEN ............................................................................................111 6.5.1 Atores.....................................................................................................................111 6.5.2 Funcionalidades .....................................................................................................112 6.5.3 Ferramenta de Apoio ao GP...................................................................................112 xiii

6.5.4 Workflow das Atividades do MGP no DiSEN........................................................116 6.6 Consideraes Finais .......................................................................................................118 CAPTULO VII Prottipo do MGP para o DiSEN ...............................................................119 7.1 Introduo........................................................................................................................119 7.2 Construo do Prottipo ..................................................................................................120 7.3 Funcionamento do Prottipo.......................................................................................... .121 7.3.1 Menu para o Gerente Geral....................................................................................121 7.3.2 Menu para o Gerente Local ...................................................................................127 7.3.3 Menu para o Gerente de Projeto ............................................................................131 7.3.4 Menu para o Engenheiro de Software ...................................................................136 7.4 Estados Utilizados no MGP.............................................................................................138 7.5 Consideraes Finais .......................................................................................................141 CAPTULO VIII Validao do MGP....................................................................................142 8.1 Introduo........................................................................................................................142 8.2 Elaborao do Questionrio......................................................................................142 8.3 Dados sobre as Empresas e sobre os Respondentes..................................................142 8.4 Aceitao do MGP Apresentado...............................................................................145 8.5 Aceitao do Prottipo Apresentado ...............................................................................148 8.6 Consideraes Finais .......................................................................................................151 CAPTULO IX Consideraes Finais ...................................................................................152 9.1 Aspectos sobre o MGP ....................................................................................................152 9.1.1 Contribuies do MGP ..........................................................................................152 9.1.2 Aprimoramento da DIMANAGER no DISEN ......................................................153 9.2 Restries do MGP..........................................................................................................154 9.3 Sobre a Validao do MGP .............................................................................................154 9.4 Pesquisas Futuras.............................................................................................................155 REFERNCIAS BIBLIOGRFICAS ..................................................................................159 APNDICE A QUESTIONRIO PARA UMA AVALIAO DAS NECESSIDADES DOS PARTICIPANTES DO PROJETO........................................................................................164 APNDICE B FUNCIONALIDADES E RELATRIOS NECESSRIOS PARA O GP ..165 APNDICE C USE-CASES E DESCRIO DOS USE-CASES DO GERENCIAR PROJETO ..............................................................................................................................172 APNDICE D DIAGRAMA DE CLASSES ATUALIZADO .............................................183 APNDICE E JANELAS DO PROTTIPO........................................................................190 APNDICE F QUESTIONRIO APLICADO AOS GERENTES DE PROJETO .............198 ANEXO A DESCRIO DOS PERFIS ..............................................................................207 ANEXO B QUESTIONRIO PARA IDENTIFICAO DAS APTIDES DOMINANTES ...............................................................................................................................................210 ANEXO C APURAO DAS APTIDES CEREBRAIS DOMINANTES.......................214

xiv

CAPTULO I Introduo 1.1 Consideraes Iniciais

No cenrio atual, em busca de maior competitividade, cada vez mais empresas optam pelo desenvolvimento de software onde os participantes do projeto encontram-se geograficamente separados. A inovao tecnolgica e a massificao do uso da Internet tornaram isso possvel. Porm, os problemas advindos deste tipo de desenvolvimento requerem uma ateno redobrada por parte dos gerentes de projeto. Uma soluo encontrada para que o gerente de projetos tenha uma forma sistemtica para executar as funes de gerenciamento de projeto (GP) a criao de um modelo de gerenciamento de projeto (MGP) para um ambiente de desenvolvimento distribudo de software (ADDS). No ambiente DiSEN
1

(Distributed Software Engineering Environment), a

preocupao com o gerenciamento do desenvolvimento de software distribudo foi formalizada pela construo da ferramenta DIMANAGER (PEDRAS, 2003). Esta ferramenta considera funcionalidades de planejamento de projeto e controle de projeto em um ambiente distribudo. J o trabalho intitulado Mecanismo de Apoio ao Gerenciamento de RH (Recursos Humanos) no Contexto de um Ambiente Distribudo de Software (LIMA, 2004) apresentou um mecanismo para ajudar o gerente de projeto a selecionar as pessoas mais adequadas para realizar as atividades na produo de software. O trabalho Gerao de Informaes Gerenciais para a Tomada de Deciso com a Utilizao da Ferramenta DIMANAGER (SANTIAGO, 2004), criou um componente para gerao de informaes gerenciais que foi integrada ferramenta DIMANAGER. A dificuldade inerente ao desenvolvimento de software se torna mais crtica ainda em um ambiente onde existe o desenvolvimento distribudo de software (DDS). O GP em ADDS ainda no foi abordado de forma mais ampla para ser utilizada como modelo para o DiSEN. Dessa forma, este trabalho apresenta um MGP para um ADDS integrado ao ambiente DiSEN. O desenvolvimento deste modelo preencher uma lacuna relativa gerncia de projeto dentro do DiSEN, onde devem ser levados em conta aspectos gerenciais importantes para que o desenvolvimento do software seja realizado com sucesso e tambm aspectos relativos distribuio fsica dos participantes do projeto. Alm disso, o modelo a ser
DiSEN = projeto em execuo do Departamento de Informtica da Universidade Estadual de Maring. (Huzita et al 2004), realizado com apoio financeiro da CNPQ.
1

15

elaborado dever fazer a integrao dos trabalhos j realizados e levantar quais sero os usurios do ambiente e o tipo de informao necessria para cada um. No Captulo 1, so apresentados os objetivos, a justificativa, a importncia do tema e os conceitos que so importantes para a compreenso do que est sendo proposto. No Captulo 2, so apresentados a metodologia e como a pesquisa foi desenvolvida. No Captulo 3, so apresentados os trabalhos relacionados ao DDS que incluem os trabalhos j realizados dentro do Ambiente DiSEN que devem ser integrados neste modelo: MDSODI (GRAVENA, 2000), Arquitetura do DiSEN (PASCUTTI, 2002), Ferramenta DIMANAGER (PEDRAS, 2003), Mecanismo de Apoio ao Gerenciamento de RH (LIMA, 2004), Gerao de Informaes Gerenciais atravs da DIMANAGER (SANTIAGO, 2004), Componente Estimativa de Custo para a DIMANAGER (NITTA, 2005) e, Aspectos

Psicolgicos e Administrativos no Mecanismo de Gerenciamento de RH (CURIONI, 2005). Alm disso, alguns temas relevantes para a construo do MGP tambm so apresentados: equipes virtuais, diferenas culturais, follow- the-sun, nveis de disperso e armazenamento do conhecimento dos projetos distribudos. No Captulo 4, o projeto, o GP e o GP de software so apresentados em maior detalhe. O projeto apresentado dentro do contexto da organizao, o GP e o GP de software so apresentados conforme compreendidos dentro do escopo deste trabalho. No Captulo 5, so apresentados os MGPs que serviro como base para a construo do MGP do DiSEN. So eles: o modelo processual do PMI (PMI, 2004a), o Capability Maturity Model Integration (CMMI) (SEI, 2002), o Modelo baseado no Project Management Institute (PMI) para ambientes de desenvolvimento de software fisicamente distribudo (ZANONI, 2002) e o Modelo de Maturidade no Desenvolvimento Distribudo de Software (MuNDDoS) (PRIKLADNICKI, 2003). Foi realizada tambm uma anlise comparativa entre os modelos apresentados. No Captulo 6 est descrito o MGP que trata as questes relacionadas ao GP com DDS. No Captulo 7 apresenta-se o prottipo desenvolvido para o MGP no DiSEN. No Captulo 8, a validao realizada por meio da aplicao de questionrios apresentada. Por fim, no Captulo 9 so tecidas consideraes finais sobre o MGP apresentado e trabalhos futuros.

16

1.2 Definio do Problema

Com a possibilidade do DDS onde pessoas em locais geograficamente distantes podem cooperar na construo de um determinado software e at mesmo na construo de um nico artefato, torna-se necessrio um controle efetivo das atividades relacionadas ao desenvolvimento de software, as quais se enquadram nas atividades do GP. Vrias pesquisas foram realizadas (PRIKLADNICKI, 2003; SMITE, 2004; BEISE, 2004) para determinar como as dificuldades relacionadas a um ADDS podem ser controladas permitindo que as organizaes garantam o sucesso em seus projetos com DDS. No DiSEN, um MGP especfico para o DDS a forma encontrada para trilhar o caminho para alcanar o sucesso nos projetos. Dentre as dificuldades encontradas para o GP no ADDS, podemos citar: as diferenas culturais e de lngua, que tornam a comunicao mais difcil criando situaes onde existe a competio por liderana, a falta de confiana, dificuldade de integrao dos componentes e distribuio de tarefas, falta de motivao e liderana e dificuldades de coordenao.

1.3. Objetivos
1.3.1. Objetivo Geral
O objetivo geral apresentar um MGP para um ADDS.

1.3.2. Objetivos Especficos

Os objetivos especficos so: Estudar MGPs de software para o ambiente DiSEN; Contribuir para o aperfeioamento do ambiente DiSEN; Elaborar um prottipo do MGP proposto; Validar o MGP proposto.

1.4. Justificativa
No cenrio mundial, o GP proposto pelo Modelo Processual do PMI (PMI, 2004a) bem aceito e bastante divulgado e contm as boas prticas do GP. Porm, o desenvolvimento de software possui particularidades que devem ser levadas em conta para um efetivo GP. Neste contexto, o CMMI (SEI, 2002) bastante conhecido e

17

possui objetivos a serem alcanados para que as organizaes atinjam os nveis de maturidade e capacidade. Ainda, na rea de GP existe a possibilidade de se desenvolver produtos de forma distribuda. O produto aqui em questo o software. O DDS apresenta problemas adicionais a serem tratados para que o GP seja realizado. Os modelos de Prikladnicki (2003) e Zanoni (2002) esto voltados ao GP em ADDS. Porm, para o DiSEN, necessrio um enfoque mais abrangente que apresente solues para lidar com os problemas de um ADDS e ao mesmo tempo mais detalhado para a implementao em um ADDS. Os modelos estudados sero apresentados mais detalhadamente no Captulo 5. Alm disso, tambm no Captulo 5, uma comparao entre os modelos foi realizada para identificar caractersticas comuns e qual o tratamento dado com relao aos problemas de um ADDS. As organizaes que desenvolvem software com os membros da equipe separados geograficamente, necessitam de um MGP que aborde as questes do GP em geral, de desenvolvimento de software e de desenvolvimento distribudo de uma forma unificada que evidencie solues para os problemas relativos ao GP em um ADDS. Justifica-se a pesquisa pelo seguinte: Necessidade de solues para gerenciar projetos em ADDS; Aprimoramento do conhecimento em GP para que as organizaes atinjam sucesso em seus projetos em um ADDS; Necessidade de um MGP que integre os aspectos tcnicos e organizacionais de um ADDS para um efetivo GP; Necessidade que foi evidenciada dentro do DiSEN para o aprimoramento do ambiente no que se refere ao controle gerencial do projeto. Existe a necessidade de solues para gerenciar projetos em ADDS, pois este tipo de ambiente traz uma srie de problemas a serem tratados, tais como: a comunicao entre os participantes do projeto, limitao do acesso s informaes por questes de segurana, diferenas culturais, etc. Percebe-se a necessidade de armazenar novas informaes em ADDS para se manter um efetivo GP e algumas destas informaes so: o local que cada participante est situado, o perodo de disponibilidade de cada membro da organizao, a autoridade e responsabilidade dentro do projeto, o perfil e a aptido de cada membro da organizao, a lngua e o pas de origem.

18

O aprimoramento do conhecimento em GP em ADDS ocorre medida que o estudo realizado neste trabalho colhe e apresenta informaes sobre GP. O estudo foi realizado por meio de pesquisas e pela busca de novas formas de lidar com este tipo de ambiente. Um ADDS necessita de um GP que integre aspectos tcnicos e organizacionais. Dentre os aspectos tcnicos esto: a estrutura adequada, o treinamento tcnico adequado e os recursos materiais necessrios para que as tarefas sejam executadas. E, dentre os aspectos organizacionais, esto: a cultura organizacional, as diferentes culturas envolvidas e a comunicao face a face. No DiSEN, j foram realizados trabalhos relativos ao GP e que tratam questes relativas ao DDS, porm, necessrio um MGP que integre os trabalhos desenvolvidos e que permita uma viso mais detalhada do GP em um ADDS.

1.5. Importncia do Tema

O uso da gerncia de projetos tem como objetivo garantir o sucesso esperado nos projetos das organizaes. Jones (1996 apud Royce, 1998), Standish Group (1995 apud Royce, 1998) e Defense Science Board (1998 apud Royce, 1998) revelaram em pesquisas que a maior parte dos projetos fracassam por problemas em questes gerenciais. O uso de gerncia de projetos no garante o sucesso, pois necessrio que a GP seja efetiva, alinhada com a organizao e com o projeto , mas, a sua falta aumenta o fracasso em seus projetos. Em um ADDS surgem questes que complicam ainda mais o gerenciamento do projeto e que devem ser tratadas. Uma organizao que pretenda utilizar um ADDS certamente necessitar de um GP efetivo que contemple os problemas advindos da distribuio fsica dos participantes do projeto. Partindo-se do pressuposto que as organizaes no sobrevivem sem o uso de tecnologia de informao (TI) (TAIT, 2000), um ADDS fornecer um ambiente com uma estrutura adequada para o trabalho cooperativo. A elaborao de um MGP para um ADDS ajudar as organizaes a gerenciar as questes crticas neste tipo de ambiente.

1.6. Referencial Conceitual

Para fins de entendimento do trabalho, importante apresentar alguns conceitos utilizados, que so: ADDS, projeto, gerenciamento ou gerncia de projetos, MGP e mtricas.

19

1.6.1 Ambiente de Desenvolvimento Distribudo de Software

Segundo Moura (1992 apud Pascutti 2002), um Ambiente de Desenvolvimento de Software (ADS) definido como sendo um sistema computacional que prov suporte para o desenvolvimento, reparo e melhorias em software e para o gerenciamento e controle dessas atividades. Para Rabello et al. (2001), um ADS definido como um ambiente para modelagem, execuo, simulao e evoluo de processos de desenvolvimento de software. E, ainda, um ADS deve se preocupar com o apoio s atividades individuais e ao trabalho em grupo, o gerenciamento do projeto, o aumento da qualidade geral dos produtos e o aumento da produtividade, permitindo ao engenheiro de software acompanhar o projeto e medir, por meio de informaes obtidas ao longo do desenvolvimento, a evoluo dos trabalhos (TRAVASSOS, 1994 apud PASCUTTI, 2002). J um ADDS pode ser entendido como um ADS onde existe o suporte para o DDS onde os membros da equipe de desenvolvimento esto separados geograficamente. Esta separao pode ser regional, continental ou global. O regional se refere ao desenvolvimento distribudo em regies diferentes, o continental se refere ao desenvolvimento distribudo em pases diferentes mas em um nico continente e o global se refere ao desenvolvimento distribudo em vrios pases (PRIKLADNICKI, 2003).

1.6.2 Projetos
Algumas definies de projeto: Projeto um empreendimento temporrio realizado para criar um produto, um servio ou um resultado singular (SABATO, 1975 apud VALERIANO, 2005). Temporrio significa que todos os projetos possuem incio e fim definidos. Projeto um empreendimento com comeo e fim definidos, dirigido por pessoas, para cumprir metas estabelecidas dentro de parmetros de custo, tempo e qualidade (DINSMORE, 1992). Projeto um empenho onde RH, materiais e financeiros so organizados em uma forma moderna para empreender um escopo de trabalho, para uma dada especificao, dentro de restries de custo e tempo para alcanar mudanas benficas definidas por objetivos quantitativos e qualitativos (DESOUSA e EVARISTO, 2004). Um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo (PMI, 2004a).

20

Projeto um processo nico, consistindo de um grupo de atividades coordenadas e controladas com datas para incio e trmino, empreendido para alcance de um objetivo conforme requisitos especficos, incluindo limitaes de tempo, custo e recursos (CAUPIN, 1999 apud VALERIANO, 1999). Ento, para a presente pesquisa, um projeto pode ser definido como um esforo temporrio para criar um produto, servio ou resultado nico onde existe o empenho de RH, materiais e financeiros com restries de custo e tempo.

1.6.3 Gerenciamento de Projeto

Gerenciamento de projeto ou gerncia de projeto, segundo a PMI (Project Management Institute), associao profissional desta rea mais conhecida e respeitada atualmente, : a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto para atender aos seus requisitos (PMI, 2004a). Uma outra definio coloca que o gerenciamento de projeto a melhor aplice de seguro que se pode ter contra falhas (COREY et al., 2001). A rea do GP que pretendemos tratar mais especificamente a rea de GP de software onde existe DDS. Podemos visualizar melhor na Figura 1.

Figura 1. reas da Gerncia de Projetos Relacionadas ao Modelo Proposto.

Nessa viso, o GP de software onde existe desenvolvimento distribudo uma parte do GP que trata somente da rea de DDS. 21

Na viso proposta neste trabalho, como mostra a Figura 2, o GP uma das reas que compem um ADDS. Pois o GP como um sistema computacional, dar suporte ao gerenciamento e controle das atividades de um ADDS.

Figura 2. GP como uma das reas que Compem um ADDS.

1.6.4 MGP
Um modelo uma representao simplificada do mundo (SEI 2002). No caso especfico do GP, um MGP permite a utilizao de uma abordagem sistmica para que a gerncia de projeto seja executada de forma eficaz. Permite que a gerncia seja feita com passos organizados, evitando o esquecimento de qualquer item relevante para a gerncia de projetos (CLELAND e IRELAND, 2002). Resumindo, um MGP uma viso que se tem sobre o GP.

1.6.5 Mtricas
Uma mtrica uma medida do grau que um processo ou produto possui de um atributo (THAYER, 1997). Inicialmente, podemos acreditar que medidas ou mtricas de software e de processo no devem ser realizadas pela inexistncia de valores ou atributos claros a serem aplicados, mas medir fundamental em qualquer disciplina de engenharia e a engenharia de software no exceo (PRESSMAN, 1995) e at mesmo para um projeto que no tenha problemas, a medio no somente til mas necessria, pois, como poderemos saber que ele no tem problemas se no se tem indicadores que confirmem isso (FENTON e PFLEEGER, 1997). 22

1.7 Delimitaes da Pesquisa

As delimitaes da pesquisa so: (1) a falta de MGPs, na literatura, que estejam voltados para um ADDS; (2) falta de discusses e pesquisas a respeito dos temas relacionados ao DDS; (2) a dificuldade de avaliar o modelo proposto de uma forma mais genrica, pois a avaliao do MGP proposto est vinculado ao ambiente DiSEN. A falta de modelos na literatura que estejam voltados para um ADDS dificulta um levantamento mais embasado das questes relativas distribuio fsica dos participantes no desenvolvimento de software. A falta de pesquisas com maior abrangncia dos temas relativos ao DDS nos leva construo do modelo com o material disponvel, e que ainda no foi pesquisado em profundidade. A avaliao do modelo foi realizada por meio de questionrios aplicados para gerentes de projetos que podem avaliar questes gerais do modelo, mas que no conhecem o ambiente para o qual o MGP foi desenvolvido. Contudo, apesar de no permitir a generalizao, haver contribuies com relao a aspectos relevantes para o estudo. Houve tambm a apresentao do trabalho para os integrantes do DiSEN para que pudessem avaliar melhor a viabilidade do MGP proposto para o ambiente em questo. Para aplicar o MGP proposto em algo efetivo para o DiSEN, foram incorporadas novas funcionalidades na ferramenta DIMANAGER para atender mais especificamente ao gerente de projetos. Porm, no foi possvel um estudo de caso com o uso do modelo, pois o ambiente ainda est em desenvolvimento.

23

CAPTULO II Metodologia e Desenvolvimento da Pesquisa 2.1 Introduo

A metodologia envolveu as seguintes etapas: 1) Fundamentao terica com estudo de temas relacionados ao modelo proposto; 2) Elaborao do Modelo utilizando elementos dos modelos estudados; 3) Validao do Modelo por meio de estudo de caso com a aplicao de questionrios; 4) Construo do Prottipo do Modelo com a utilizao de tecnologias como Rational Rose e Linguagem Java; e, 5) Apresentao do Modelo. A Figura 3 mostra mais detalhadamente os itens de cada uma das etapas.

Fundamentao Terica

- Software Distribudo - Processo de Gerenciamento de Projetos - Perfil do Gerente de Projetos - Modelos de Gerncia de Projetos Existentes - Trabalhos Relacionados dentro do DiSEN - Ambiente de Desenvolvimento Distribudo de Software - Utilizao do CMMI-StagedNvel 2 - Incorpora o Modelo Processual da PMI - Apresenta Arquitetura da DIMANAGER dentro do DISEN - Apresenta o Gerenciamento de Projetos Integrado - Apresenta Mtricas para as Atividades de Gerenciamento de Projetos

Elaborao do Modelo Construo do Prottipo do Modelo Validao e Avaliao do Modelo Apresentao do Modelo

- Rational Rose - Linguagem Java - Poseidon - Postgres

- Questionrio com Gerentes de Projetos de Software - Questionrio com Participantes do Projeto DiSEN

- Apresentao Final - Apresentao em Forma de Artigo

Figura 3. Metodologia de Desenvolvimento do Modelo de Gerncia de Projetos Proposto.

24

2.2 Fundamentao Terica

Para fundamentao terica, foram realizados estudos sobre: 1) Software distribudo pois os componentes do DiSEN componentes estaro distribudos; 2) Processo de GP para identificar quais as funes a serem executadas dentro do mesmo; 3) O perfil do gerente de projetos um fator importante de se considerar, pois em se conhecendo o perfil do gerente de projetos, possvel fornecer as informaes que ele deseja para se exercer um efetivo GP, levando o projeto a alcanar o sucesso esperado; 4) Os trabalhos relacionados dentro do DiSEN que possuem relao com GP foram estudados para que o MGP proposto pudesse integr-los; 5) Alguns MGPs encontrados na literatura foram estudados para abstrair os pontos importantes a serem considerados no MGP proposto para o DiSEN; 6) O ADDS foi estudado para obter a compreenso da organizao para este tipo de ambiente; Houve tambm um estudo sobre metodologia de pesquisa (YIN, 2000) e (BOOTH, COLOMB e WILLIAMS, 2000) para estruturar a pesquisa e tambm sobre a aplicao de questionrios (MUCCHIELLI, 1978).

2.3 Elaborao do Modelo

Para a elaborao do MGP foram utilizados elementos dos modelos encontrados na literatura e que se enquadram dentro da necessidade do DiSEN. Dentre estes elementos, podem ser citados: os processos e as ferramentas e tcnicas fornecidas pelo modelo processual do PMI (PMI, 2004a), as prticas e subprticas para alcanar os objetivos do CMMI Staged para se alcanar o nvel 2-Definido (SEI 2002), e solues encontradas na literatura para os problemas relacionados ao DDS.

2.4 Construo do Prottipo

A construo do prottipo levou em considerao os trabalhos j realizados relativos gerncia de projetos e que j haviam sido desenvolvidos para o ambiente DiSEN, principalmente: a ferramenta DIMANAGER (PEDRAS, 2003), o mecanismo de apoio ao gerenciamento de RH (LIMA, 2004) e o componente de gerao de informaes gerenciais a partir da DIMANAGER (SANTIAGO, 2004). Estes trabalhos so apresentados mais detalhadamente no Captulo 3. O prottipo pode mostrar de forma mais efetiva como ser realizado na prtica o GP de software.

25

2.5 Validao e Avaliao do Modelo

A construo e o teste do prottipo permitiram validar o MGP proposto. Esta validao foi realizada conjuntamente com os participantes do projeto o que permitiu a construo com a autorizao ou consenso dentro da equipe de desenvolvimento do ambiente como um todo. A avaliao uma etapa fundamental para se validar o MGP e o prottipo e, alm disso, permite o aprimoramento dos mesmos. A avaliao do MGP foi realizada por meio de questionrios aplicados a gerentes de projeto. O uso de questionrios foi considerado o mais adequado dentre os mtodos de avaliao encontrados, pois permite a avaliao qualitativa do MGP proposto. O questionrio aplicado se encontra no Apndice E. Aps a avaliao dos questionrios procedeu-se anlise dos mesmos que indicou a validade com relao ao modelo conceitual. As sugestes pertinentes dos gerentes de projeto foram avaliadas e acatadas para serem incorporadas no DiSEN.

2.6 Consideraes Finais

Foram apresentados neste captulo: (1) A metodologia a ser utilizada para a construo do MGP para um ADDS para que se possa observar o rigor com que o assunto foi tratado; e, (2) O roteiro do trabalho realizado. A construo do prottipo e os questionrios aplicados aos membros do DiSEN mostram a preocupao com a integrao com o DiSEN e os questionrios aplicados aos gerentes de projeto foi a forma encontrada para que o trabalho fosse avaliado sob a perspectiva dos gerentes de projeto.

26

CAPTULO III Trabalhos Relacionados ao DDS 3.1 Introduo

O MGP proposto deve atender ao DiSEN, que, por sua vez, um ADDS que d suporte para o desenvolvimento onde existe a distribuio fsica dos participantes do projeto. Foi necessrio estudar os trabalhos realizados dentro do DiSEN que possuem relao com o GP para que a proposta pudesse incorporar os elementos j identificados. A seguir uma descrio dos trabalhos realizados dentro do DiSEN.. Os trabalhos j desenvolvidos dentro do ADDS DiSEN que possuem relao com gerenciamento de projeto so: Uma Proposta de Arquitetura de um Ambiente de Desenvolvimento de Software Distribudo Baseada em Agentes (PASCUTTI, 2002); Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de Software Distribudo: DIMANAGER (PEDRAS, 2003); Gerao de Informaes Gerenciais para a Tomada de Deciso com a Utilizao da Ferramenta DIMANAGER (SANTIAGO, 2004); Componente Estimativa de Custo para a DIMANAGER (NITTA, 2005); Mecanismo de Apoio ao Gerenciamento de RH no Contexto de um Ambiente de Software Distribudo (LIMA, 2004); Aspectos Psicolgicos e Administrativos no Mecanismo de Gerenciamento de RH (CURIONI, 2005); e Metodologia de Desenvolvimento de Software Distribudo (GRAVENA, 2000). Tambm foi realizado um estudo geral na rea de GP e de engenharia de software (ES) para identificar temas que so objeto de estudo quando se trabalha com DDS. Esses temas so: equipes virtuais, diferenas culturais, follow-the-sun, nveis de disperso e armazenamento do conhecimento dos projetos distribudos.

3.2 Trabalhos Relacionados no Projeto DiSEN

O DiSEN um projeto em execuo no Departamento de Informtica da Universidade Estadual de Maring (HUZITA et al., 2004) realizado com apoio financeiro do CNPQ (Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico) e visa a construo de um ADDS. Iniciou-se em 1999, o projeto de pesquisa Uma Metodologia para o Desenvolvimento Baseado em Objetos Distribudos Inteligentes (HUZITA, 1999) e teve 2 objetivos principais. Como primeiro objetivo: a especificao de uma metodologia para desenvolvimento de software distribudo que foi denominada MDSODI e est apresentada no item 3.2.7; e, como

27

segundo objetivo do projeto: a construo de um ambiente integrado para o desenvolvimento de software distribudo que foi denominado DiSEN. Aps isso, um novo projeto foi iniciado para dar continuidade ao trabalho (HUZITA, 2004).

3.2.1 Arquitetura DISEN

A arquitetura DiSEN foi o primeiro trabalho realizado dentro do projeto para a criao do ADDS onde foram identificados os principais componentes do ADDS a serem desenvolvidos e as suas ligaes e, tambm levou-se em considerao: o suporte MDSODI, o trabalho cooperativo e a tecnologia de agentes. Trata-se de uma arquitetura dividida em camadas: dinmica, aplicao e infraestrutura, conforme apresentado na Figura 4 (PASCUTTI, 2002). A camada Dinmica permite a manuteno dos componentes de software e servios de forma dinmica, em tempo de execuo. A camada de Aplicao dar suporte MDSODI, gerenciamento de workspace e gerenciamento de agentes1 de software. A camada de Aplicao tambm conter: o(s) banco(s) de dados necessrio(s) para armazenamento dos dados sobre o ambiente (todas as informaes geradas durante o desenvolvimento de software e as informaes da aplicao), a base de conhecimento e as ontologias. A camada de infra-estrutura dar o suporte s tarefas de persistncia, nomeao e concorrncia e conter tambm o canal de comunicao. Dando suporte a tudo isso, est o software bsico do sistema com as interfaces para o hardware, sistema operacional, memria compartilhada e comunicao. O canal de comunicao constitudo pelo middeware e pelo middle-agent. O middeware ser o responsvel quando a comunicao ocorrer unicamente por meio de objetos e, quando ela envolver agentes, a comunicao ser gerenciada pelo middle-agent. O Supervisor de Configurao Dinmica responsvel pelo controle e gerenciamento da configurao do ambiente e pelos servios que podem ter atualizao em tempo de execuo. O Gerenciador de Objetos responsvel pelo controle e gerenciamento do ciclo de vida dos artefatos (diagramas, modelos, manuais, cdigos fonte, cdigos objeto, etc.). O Gerenciador de Workspace responsvel pelo controle e gerenciamento da edio cooperativa de documentos e itens de software. O Gerenciador de Agentes responsvel pela criao, registro, localizao, migrao e destruio de agentes. O repositrio o responsvel pelo armazenamento dos artefatos, dados das aplicaes geradas pelo Ambiente de
Agente: Segundo a OMG (Object Management Group) (2000) apud Pascutti (2002), uma entidade de software autnoma que tem capacidades, interage com seu ambiente e adapta seu estado e comportamento com base nesta interao. Este ambiente de interao pode ser constitudo de mquinas, de humanos e de outros agentes de software em vrios ambientes e pelo uso de vrias plataformas.
1

28

Desenvolvimento de Software e, tambm, do conhecimento necessrio para a comunicao dos agentes. O Canal de Comunicao responsvel pela comunicao entre os elementos da arquitetura.

Figura 4. Arquitetura do DiSEN (PASCUTTI, 2002).

De acordo com Pascutti (2002), o gerente de projetos ser responsvel por: (1) Gerenciar Workspace: o que envolve definir os workspaces de cada local e os atores que trabalharo em cada workspace; (2) Gerenciar Processo de Desenvolvimento: o que envolve gerenciar todas as etapas de um processo de desenvolvimento de software; (3) Gerenciar Configurao Dinmica: o que envolve gerenciar a (re)configurao do ambiente e incluso/modificao/excluso de servios em tempo de execuo; O item (2) Gerenciar Processo de Desenvolvimento envolve outras atividades sob a responsabilidade do gerente de projeto, que so: (a) Gerenciar Execuo do Projeto: que envolve gerenciar todas as tarefas necessrias para a realizao de um projeto; (b) Definir Mtrica: inserir uma nova mtrica; (c) Definir Estimativa dos Custos: inserir uma nova estimativa de custo; (d) Gerenciar Profissionais Envolvidos no Projeto: o que envolve gerenciar os passos necessrios para tornar mais efetivo o uso dos RH envolvidos no projeto; (e) Gerenciar Qualidade do Projeto: o que envolve gerenciar os passos necessrios para garantir que o projeto ir satisfazer as necessidades para as quais ele foi elaborado; (f) Definir Processo: definir processo a ser utilizado no projeto; (g) Definir Cargo: inserir um novo cargo; (h) Definir Tipos de Acesso: inserir um novo tipo de acesso; (i) Definir Recurso: inserir um novo recurso que pode ser uma ferramenta ou um material; (j) Definir 29

Ferramenta: inserir uma nova ferramenta; (k) Definir Material: inserir um novo material. O item (a) Gerenciar Execuo do Projeto envolve outras atividades sob a responsabilidade do gerente de projeto, que so: (i) Definir Projeto: inserir um novo projeto; (ii) Definir Atividade: inserir uma nova atividade; (iii) Definir Permisso de Acesso: inserir uma nova permisso de acesso; (iv) Definir Artefato: inserir um novo artefato; (v) Definir Agenda do Ator: agendar uma atividade para um determinado ator; (vi) Elaborar Relatrios de Desempenho e Cumprimento das Atividades: elaborar relatrios que descrevam a situao atual do projeto e o que a equipe j realizou; (vii) Gerenciar Cronograma do Projeto: envolve definir a data de incio prevista e a data de trmino prevista para cada atividade relacionada ao projeto, e envolve tambm o controle das mudanas no cronograma do projeto. As informaes necessrias para auxiliar o gerente na execuo das funes devero estar no gerenciador de objeto. O gerenciador de objeto est dividido em: gerenciador de acesso, gerenciador de projeto, gerenciador de processo, gerenciador de atividade, gerenciador de recurso, gerenciador de artefato e, gerenciador de verso e configurao. O gerenciador de objeto dever fornecer uma interface para acesso a todas as informaes sobre: ator, acesso, cargo, projeto, mtrica, estimativa, recurso, atividade, artefato, processo e agenda do ator.

3.2.2 Ferramenta DIMANAGER

DIMANAGER (PEDRAS, 2003) uma ferramenta de apoio ao GP que foi construda considerando conceitos relativos s ferramentas CASE (Computer Aided Software Engineering), aspectos relevantes ao GP e caractersticas de software distribudo no processo de desenvolvimento. Ela faz parte do ambiente DiSEN e oferece ao gerente de projetos informaes tcnicas e organizacionais dando suporte s decises dentro do processo de desenvolvimento distribudo de software. Como o DiSEN um ambiente distribudo, podem existir vrios workspaces ativos. A troca de informaes, quando necessria, entre os vrios workspaces, dever ser realizada com a utilizao do repositrio. As informaes relevantes que podem ser armazenadas no repositrio so: a atividade executada em cada fase, as equipes e seus participantes, o cronograma, a performance dos participantes e os problemas encontrados em cada atividade (HUZITA et al, 2004). Para a construo da ferramenta foram considerados importantes indicadores gerenciais (SANTIAGO, 2004): 30

(1)Cronograma: proporciona ao usurio uma viso do projeto com relao ao que foi planejado. Pode ser consultado de 3 maneiras: Geral, Detalhado e Especfico; (2)Grupos: identifica os grupos existentes no projeto. Como no cronograma, podem ser obtidas informaes de 3 maneiras; (3)Participantes: identifica todos os participantes do projeto e a situao de cada participao dentro do projeto; (4)Problemas: identifica os problemas que ocorrem na execuo do projeto. Assim, possvel us-los para identificar os riscos e tambm para consultas quando ocorrer novamente o mesmo problema, possibilitando a resoluo mais rpida do problema. Podem ser divididos em: tcnicos e organizacionais. Os tcnicos esto associados tecnologia de informao. Os organizacionais podem ser internos ou externos. Os internos esto relacionados s questes de RH, negcios e metas e os externos aos contratos com terceiros, distribuio, governos, etc. Suas funes principais permitem ao gerente de projetos: criar atividades, alocar pessoas para as atividades, atualizar a situao da atividade (andamento, suspenso, parado, em planejamento e encerrado), cadastrar problemas tcnicos ou organizacionais relacionados com a atividade, cadastrar usurios com respectivas senhas e alter-las, criar o cronograma do projeto, criar grupos para os participantes (pode ser por localizao geogrfica ou pela atividade). Como mtrica, esta ferramenta utiliza a de esforo-hora armazenando-a para posteriores estimativas (PEDRAS, 2003). Esta ferramenta est focada no planejamento e controle do projeto como mostra a Figura 5. O gerente de Projeto dever realizar o planejamento e depois o acompanhamento do projeto. Para executar a funo planejar projeto, ele dever: (1) identificar as atividades juntamente com o Coordenador de Atividades; (2) definir participantes junto com o Coordenador de Participantes; e, (3) elaborar o cronograma juntamente com o Coordenador de Cronograma (PEDRAS, 2003).

31

Figura 5. Modelo de Domnio da DIMANAGER (PEDRAS, 2003).

Para acompanhar o projeto, o gerente de projeto dever: (1) acompanhar as atividades juntamente com o Coordenador de Atividades; e, (2) acompanhar os participantes juntamente com o Coordenador de Participantes (PEDRAS, 2003). Muitas vezes, as funes de Coordenador de: Atividades, Participantes e Cronograma so executadas pelo prprio gerente de projetos.

3.2.3 Gerao de Informaes Gerenciais a partir da DIMANAGER

O desenvolvimento do componente Gerao de informaes gerenciais a partir da DIMANAGER realizado por Santiago (2004) permite a criao de relatrios e grficos a partir dos dados gerados pela ferramenta DIMANAGER servindo como um complemento mesma. Esses relatrios e grficos podero ser usados pelo gerente de projetos para a tomada de decises tais como: alterao do cronograma, remanejamento de pessoal e/ou substituio de participantes do projeto. Os relatrios gerados em 2 nveis: Geral e de Projeto. O primeiro se divide em mais dois nveis: Resumido e Detalhado (SANTIAGO, 2004). O sub-nvel Geral Resumido apresenta informaes que permitem ao gerente a identificao rpida das dimenses do projeto como complexidade, extenso e quantidade de recursos alocados. As informaes fornecidas por este nvel so: nome do projeto, gerente, data de incio e fim do projeto, quantidade de horas previstas, de participantes, de grupos, de atividades e de problemas. O sub-nvel Geral Detalhado apresenta informaes para uma visualizao rpida sobre a situao atual do projeto e contm as informaes apresentadas no sub-nvel resumido e tambm informaes mais detalhadas como: quantidade total de horas trabalhadas, quantidade de atividades atrasadas ou em qualquer outro estado, quantidade de horas previstas, de horas trabalhadas e de atividades por participante e grupo, quantidade de problemas e quantidade de horas gastas em problemas. 32

O Nvel de Projeto apresenta informaes completas sobre a situao de um projeto. Alm das informaes contidas no Nvel Geral Detalhado, apresenta outras informaes: datas incio e fim de cada uma das fases, quantidade de atividades e problemas de cada uma das fases e informaes completas acerca dos problemas encontrados no projeto, classificando-os pelo seu tipo (tcnico ou organizacional). Os grficos foram divididos em 4 grupos: participantes, grupos, atividades e problemas. Os grficos relativos aos participantes contm informaes da quantidade de participantes, quantidade de atividades e quantidade de atividades atrasadas evoluindo ao longo do tempo. Os grficos relativos aos grupos contm informaes da quantidade de grupos, quantidade de atividades, quantidade de atividades atrasadas ao longo do tempo. Os grficos relativos s atividades contm a quantidade de atividades e a quantidade de atividades atrasadas ao longo do tempo e os grficos relativos aos problemas contm a quantidade de horas gastas em problemas ao longo do tempo (SANTIAGO, 2004).

3.2.4 Componente Estimativa de Custos para a DIMANAGER

Este item trata do trabalho realizado por Nitta (2005) entitulado Componente Estimativa de Custos para a DIMANAGER. Em seu estudo, Nitta (2005) considera que a estimativa de custos deve fornecer informaes para estimar o tamanho do projeto, o esforo humano, a produtividade, o custo e o tempo. Estas estimativas devem servir como um subsistema para dar suporte ao gerente de projeto. Desta forma, Nitta (2005) idealizou um componente para ser integrado ferramenta DIMANAGER. Como as mtricas servem como uma base para se realizar as estimativas, foram estudadas as mtricas orientadas: ao tamanho, funo e a objetos. As mtricas orientadas ao tamanho so as realizadas sobre as linhas de cdigo e so bastante controversas, pois dependem muito da linguagem de programao, da quantidade de reuso de cdigo, da forma que cada desenvolvedor escreve o cdigo usando mais ou menos funes e tambm depende do ambiente em que se desenvolve o cdigo. J, as mtricas orientadas funo so

independentes de tecnologia fornecendo um mtodo simples para fornecer medidas e permitir a quantificao de custo, tempo e esforo, mas, no fornece uma boa base para se realizar estimativas para o paradigma de orientao a objetos. As mtricas orientadas a objetos fornecem uma boa estimativa, sendo fceis de realizar, pois determinam os pontos por objeto de cada uma das telas, relatrios e mdulos de acordo com a dificuldade de desenvolvimento de cada um. 33

As mtricas auxiliam na determinao do volume de trabalho a ser realizado. A partir disso, deve-se determinar a extenso do tempo que o trabalho exigir, fazendo-se uma estimativa de esforo em homens/hora para se realizar a estimativa de tempo. A estimativa de esforo em homens/hora foi a que mostrou ser mais adequada ao ambiente DiSEN, pois: (1) pode ser coletada automaticamente pelo ambiente; (2) possui uma unidade mdia em horas ao invs de minutos ou dias, o que permite visualizao facilitada para o gerente de projetos; e, (3) a ferramenta DIMANAGER (PEDRAS, 2003) j realiza a coleta desta mtrica que pode ser utilizada para estimativas futuras. Para realizar esta estimativa deve-se lembrar sempre que o aumento de nmero de pessoas no leva necessariamente diminuio do tempo na mesma proporo, pois perde-se tempo em comunicao e treinamento. Aps a estimativa de esforo necessrio para executar o trabalho, so determinados os custos em termos de horas para saber qual o custo de cada tarefa a ser realizada. Apesar das controvrsias das mtricas de tamanho e pontos por funo, foram criados mdulos para se realizar estimativas por meio destas mtricas. Justifica-se a utilizao para se realizar estas estimativas nas ocorrncias de projetos similares. Os mdulos apresentados so: mdulo de estimativa por linhas de cdigo, mdulo de estimativas por pontos de funo, mdulo COCOMO, modulo produtividade da equipe por fase do projeto, mdulo mudana de requisito e mdulo bugs. O mdulo de estimativa por linhas de cdigo e o mdulo pontos por funo permitem a incluso de valores para o projeto como um todo e por atividade. O mdulo COCOMO permite a digitao do total de mil linhas de cdigo e resulta no clculo da durao e de pessoas necessrias para realizar o projeto. O mdulo de produtividade da equipe por fase do projeto permite o cadastramento do nmero de participantes e as horas trabalhadas em cada atividade do projeto. O mdulo de mudana de requisito permite o cadastramento do nmero de mudanas de requisitos em cada fase do projeto. O mdulo bugs permite o cadastramento do nmero de bugs encontrados na construo de cada mdulo do projeto. Ainda, no trabalho de Nitta (2005), levantou-se a utilizao do indicador de riscos para se realizar as estimativas.

3.2.5 Mecanismo de Apoio ao Gerenciamento de RH

O Mecanismo de Apoio ao Gerenciamento de RH foi elaborado por Lima (2004) para ser integrado ferramenta DIMANAGER e leva em considerao caractersticas pertinentes ao ambiente DiSEN. Ele auxiliar o gerente de projetos a selecionar o participante mais apto para desenvolver cada atividade relacionada com o projeto, pois a melhoria da qualidade de 34

produtos e processos inicia-se com a escolha do indivduo mais capacitado para a execuo das atividades (LIMA, 2004). Este mecanismo foi construdo com base em: - PSP (Personal Software Process): objetiva a melhoria contnua do trabalho individual onde cada indivduo gerencia as suas prprias atividades fazendo medies e melhorando a qualidade do seu trabalho; - TSP (Team Software Process): estabelece as diretrizes para se alcanar a disciplina necessria na realizao do trabalho em grupo e do gerenciamento do mesmo; e, - PCMM (People Capability Maturity Model): visa a melhoria da capacitao do indivduo pertencente organizao em que o modelo aplicado. composto de 5 nveis: Inicial, Gerenciado, Definido, Previsvel, e Melhoria Contnua. O mecanismo criado concentra-se no nvel 2-Gerenciado, atendendo maioria das metas estabelecidas para esse nvel, no que diz respeito ao gerenciamento de RH. O mecanismo permite que o gerente selecione as pessoas com o perfil mais adequado para realizar determinada tarefa em determinados ns da rede, onde esto localizados os repositrios de dados. A Figura 6 mostra o seu funcionamento: a partir da interface o gerente tem opes para escolher a atividade. Aps a escolha da atividade, um agente de seleo disparado e recebe como entradas a atividade escolhida e as especificaes referentes aos conhecimentos e habilidades presentes na regra (1). O agente de seleo, a partir do conjunto de atividades que ele possui, seleciona qual a regra fuzzy2 que ser executada (2). Essa regra enviada (3) para um mdulo de estruturao do mecanismo, que dispara os agentes de busca necessrios (dependendo das configuraes (4) e (5) de ns estabelecidos). Cada agente de busca recebe a regra fuzzy (6), enviada para o executor de regra (7), e o n onde est contido o repositrio (central/local) a partir do qual realizada a seleo. A regra ento aplicada (8) e os indivduos selecionados (9), juntamente com as suas informaes so retornados para o agente de seleo, especificamente para o mdulo de estruturao do mecanismo (10). Neste mdulo chegam informaes de todos os agentes de busca disparados. Verifica-se a replicao dos dados, sendo elaborado o relatrio final que enviado para a interface (11), a partir do qual ele apresentado ao gerente de projetos (LIMA, 2004).
Fuzzy: A Teoria da lgica Fuzzy permite que se possam estabelecer valores computacionais mais aproximados da realidade e no somente uma diferenciao entre /no ou possui/no possui. So definidos valores intermedirios entre o completamente verdadeiro (ex: possui) e o completamente falso (ex: no possui) (ORTEGA apud LIMA, 2001).
2

35

Figura 6. Funcionamento do Mecanismo de Apoio ao Gerenciamento de RH (LIMA, 2004).

Para o funcionamento do mecanismo, necessrio o cadastramento de informaes que permitam identificar as aptides dos RH da organizao, tais como: habilidades da pessoa, conhecimentos da pessoa, disponibilidade, treinamentos realizados pelo participante e as afinidades de um determinado participante com outro.

3.2.6 Aspectos Psicolgicos e Administrativos no Mecanismo de Apoio ao Gerenciamento de RH

Este trabalho desenvolvido por Curioni (2005), mostra a relevncia dos aspectos psicolgicos e administrativos no gerenciamento de RH e props a integrao dos mesmos no processo de gerenciamento de RH e no mecanismo de apoio ao gerenciamento de RH descrito no item 3.2.5. Sabe-se que a diversidade nos grupos de trabalho, onde existe o incentivo para a gerao de novas idias tem mais chance de gerar resultados positivos, pois, permite a

36

visualizao do problema sob vrios ngulos, fazendo uma leitura do mundo mais abrangente e apresentando idias originais e referncias pouco comuns (CURIONI, 2005). Os aspectos psicolgicos e administrativos j so levados em conta em vrias organizaes no processo de: recrutamento e seleo de funcionrios e remunerao por competncia e habilidade. A seleo do candidato dentro do processo de recrutamento e seleo de funcionrios identifica os indivduos cujas caractersticas mostrem uma grande probabilidade de que se tornem colaboradores satisfatrios. No processo de remunerao por competncia e habilidade, a competncia tida como um conjunto de conhecimentos, habilidades, comportamentos e motivaes e medida segundo padres pr-estabelecidos e pode ser alterada por meio de treinamento e desenvolvimento pessoal. Ainda, as aptides dos indivduos devem ser levadas em conta para determinar qual indivduo ir executar melhor cada tarefa do projeto. Cada indivduo pode ser enquadrado em oito tipos diferentes de perfis: quatro monodominantes e quatro bidominantes. Dentro dos perfis monodominantes temos: raciocnio lgico (NO), criatividade (NE), organizao (SO) e comunicao (SE) e como perfis monodominantes temos: intelectual (NONE), operacional (SOSE), tcnico/organizacional (NOSO) e criativo/interpessoal (NESE). Enquadra-se o indivduo em um perfil monodominante e um bidominante (os com maior percentual) para obter um perfil mais completo de cada indivduo. Estes perfis podem ser obtidos por meio da anlise de um questionrio aplicado aos funcionrios e o ideal que seja aplicado a cada novo projeto, pois os indivduos tendem a mudar a sua viso do mundo adquirindo experincia. O questionrio est no Anexo B e a frmula para apurao dos resultados est no Anexo C. A integrao com o ambiente DiSEN deve incluir a criao de uma nova classe onde cada usurio ter a sua aptido cadastrada com os dados percentuais de cada um dos oito perfis citados anteriormente.

3.2.7 MDSODI
A metodologia desenvolvida por Gravena (2000), MDSODI-Metodologia para Desenvolvimento de Software Distribudo, considera aspectos prprios de sistemas distribudos, tais como: paralelismo, concorrncia, sincronizao e distribuio. Possui as caractersticas do UP (JACOBSON et al., 1999): dirigida a use-case, centrada na arquitetura e

37

de desenvolvimento iterativo e incremental e tambm representaes grficas de objetos, classes e operaes baseadas na MOOPP3 (HUZITA, 1995) mostrando paralelismo. As fases definidas para a MDSODI so: requisitos, anlise, projeto, implementao e teste (GRAVENA, 2000). Na fase de requisitos so levantadas, junto com os usurios, as funcionalidades do sistema a ser desenvolvido. Esta fase inclui o seguinte: 1) Obter informaes sobre as funcionalidades desejadas junto ao solicitante do sistema, o que pode ser realizado utilizandose de entrevistas e questionrios aos usurios do sistema e identificar os requisitos (funcionalidades); 2) Elaborar o modelo de domnio; 3) Enumerar as funcionalidades e as pessoas ou grupos que iro se utilizar do sistema; 4) Listar os candidatos a use-cases e atores; 5) Elaborar a primeira verso de use-cases com os dados obtidos sem considerar requisitos no-funcionais; 6) Identificar os requisitos no-funcionais, tais como:

paralelismo/concorrncia e distribuio; e, 7) Identificar os atores e relacionamentos entre use-cases considerando os aspectos funcionais e no funcionais, os quais podem ser dos seguintes tipos: Use-cases seqenciais: agrupam um conjunto de funcionalidades que devem ser executadas sequencialmente; Use-cases distribudos: agrupam um conjunto de funcionalidades que devem ser executadas em paralelo; Atores exclusivos: esto envolvidos em use cases seqenciais; Atores paralelos: esto envolvidos em use cases paralelos; Atores distribudos: esto em diferentes locais no sistema; Atores paralelos e distribudos: so ao mesmo tempo paralelos e distribudos; Relacionamentos entre use-cases: seqenciais e paralelos. Seqenciais so aqueles nos quais os use-cases so executados seqencialmente e deve-se enumerar qual a seqncia a ser realizada. Use-cases paralelos so os relacionamentos entre use-cases que so executados paralelamente. Depois, deve-se 8) Avaliar e alterar se necessrio os use-cases elaborados; e, 9) Elaborar o diagrama de colaborao. Na fase de Anlise, deve-se analisar o que foi feito na fase anterior e refinar a estrutura do sistema. Esta fase inclui: 1) Analisar os requisitos da fase anterior e verificar o que deve
MOOPP (Metodologia Orientada a Objetos para Processamento Paralelo): uma metodologia orientada a objetos para desenvolvimento de software para processamento paralelo que trata aspectos estticos e dinmicos do sistema e o paralelismo j nas fases iniciais do desenvolvimento de software. Permite a representao de classes e objetos paralelos assim como operaes paralelas entre elas (HUZITA, 1995).
3

38

ser mantido ou acrescentado; 2) Definir as classes e objetos do sistema; 3) Identificar as redundncias e inconsistncias dos requisitos da fase anterior; 4) Definir os atributos e operaes das classes; 5) Elaborar o diagrama de classes; 6) Identificar os aspectos de paralelismo/concorrncia, distribuio e comunicao das classes que podem ser dos seguintes tipos: Classes e objetos exclusivos: todos os mtodos so executados sequencialmente; Classes e objetos parcialmente paralelos: alguns mtodos so executados seqencialmente e outros concorrentemente; Classes e objetos totalmente paralelos: todos os mtodos so executados paralelamente; Classes e objetos distribudos: classes e objetos localizados em diferentes ns do sistema; Depois, deve-se: 7) Reavaliar o diagrama de use-cases; 8) Alterar o diagrama de classes inicial de acordo com os novos aspectos identificados no item 6); e, 9) Identificar textualmente aspectos de paralelismo/distribuio e sincronizao entre os pacotes e elaborar o diagrama de pacotes. Na fase de projeto so feitas consideraes sobre: a linguagem de programao, interface com o usurio, reuso de componentes, etc. Esta fase inclui os seguintes passos: 1) Identificar a linguagem de programao adequada; 2) Identificar componentes para reuso; 3) Analisar o diagrama de classes verificando questes de concorrncia e distribuio de classes, mtodos e objetos; 4) Elaborar o diagrama de seqncia observando a comunicao, paralelismo e sincronizao; 5) Dividir o sistema em camadas para melhor gerenciamento. A diviso pode ser realizada desta forma: Camada de aplicao especfica, camada de aplicao genrica, camada de middleware, camada de sistema de software; e, 6) Detalhar os algoritmos de acordo com os mtodos definidos. Na fase de Implementao o sistema construdo/implementado. Esta fase inclui: 1) Verificar aspectos de implementao como gerao de cdigo; 2) Identificar as interfaces e dependncias entre os subsistemas; 3) Detalhar e implementar os mtodos das classes, 4) Identificar mecanismos de sincronizao (excluso mtua, monitores); e, 5) Identificar mecanismos para balanceamento de carga entre os ns de processamento, considerando os requisitos de distribuio, paralelismo, sincronizao e comunicao do projeto. A fase de testes, de acordo com o adotado por Lima (2004), tem-se as seguintes atividades: planejamento de verificao e validao do sistema (plano de teste), execuo da inspeo do sistema (inspeo de programa e anlise de cdigo-fonte automatizados) e 39

execuo de testes no sistema (deteco de defeitos, testes de integrao e testes orientados a objetos).

3.3 Temas Relacionados ao DDS

O DDS tem levantado questes prprias sobre como: controlar os participantes que se encontram em outros locais; lidar com as diferenas culturais; fazer melhor uso do trabalho cooperativo; e otimizar a distribuio das informaes dos projetos para futuras consultas. Novos termos so usados para descrever o desenvolvimento distribudo, como equipes virtuais, diferenas culturais, follow-the-sun, centralizao ou descentralizao de poder, nveis de disperso, armazenamento de conhecimento. Estes termos ou itens so alvos de pesquisas e esto descritos a seguir.

3.3.1 Equipes Virtuais

De acordo com McMahon (2001), equipes virtuais so aquelas onde existem integrao e cooperao para o desenvolvimento de um projeto de software com a utilizao de processos comuns e fortemente ligados por um canal de gerenciamento. Uma reviso da literatura mais recente define equipes virtuais como: grupos de trabalhadores dispersos geograficamente e/ou organizacionalmente reunidos por tecnologias de informao e telecomunicao para executar uma ou mais tarefas organizacionais (ALAVI e YOO, 1997; DESANCTIS e POOLE, 1997; JARVENPAA e LEIDNER, 1999 apud POWEEL, PICCOLI e IVES, 2004). Outro tipo de equipe virtual existente a equipe virtual global na qual existem membros que trabalham e vivem em diferentes pases com culturas diversas (MAZNEVSKI E CHUDOBA, 2001 apud POWEEL, PICCOLI e IVES, 2004) Este termo pode ser encontrado na literatura como cooperao virtual,

desenvolvimento virtual, desenvolvimento distribudo e trabalho cooperativo distribudo. O uso de equipes virtuais cria novas possibilidades durante a contratao ou a criao de equipes (PMI, 2004a), tais como: - Formar equipes de pessoas da mesma empresa, distantes geograficamente; - Adicionar um especialista fisicamente distante da equipe do projeto; - Incorporar funcionrios que trabalham em escritrios domsticos; - Formar equipes que trabalham em diferentes turnos ou horas; - Avanar em projetos que antes eram ignorados devido a despesas com viagens.

40

3.3.2 Diferenas Culturais

Cultura segundo Samovar e Porter (2004) a aquisio de um conjunto de conhecimento, experincia, crenas, valores, atitudes, sentidos, hierarquias, religio, noes de tempo, funes, relaes espaciais, conceitos do universo por um grupo de pessoas atravs das geraes. A cultura se reflete em diversos fatores que incluem: normas, crenas, expectativas e valores compartilhados; polticas e procedimentos; viso das relaes de autoridade; e, tica do trabalho e horas de trabalho (PMI, 2004a). Existem vrios tipos de cultura: nacional, regional, organizacional, ocupacional, etc. As diferenas culturais mais crticas so as encontradas nas culturas nacionais por se tratar de culturas de diferentes pases. A cultura no percebida pela pessoa que a carrega e pode trazer problemas srios na comunicao com pessoas de outras nacionalidades. Alguns exemplos so citados por Hostfede (1984 apud OLSON e OLSON, 2004) que identificou diferenas culturais com respeito hierarquia, preocupao com o individual ou o coletivo, foco no trabalho ou no relacionamento, permissividade ao risco, flexibilidade ao reagir ao risco e planejamento a longo prazo. Outros exemplos encontrados por (HALL, 1999 apud OLSON e OLSON , 2004) foram: distncia para conversao, situaes que indicam hierarquia, bens materiais que indicam poder, tempo para considerao de amizade e confiana, seriedade com relao aos prazos finais e maneira com que firmam contratos. Tudo isso gera problemas na comunicao. Como citado no PMIa (2004), a cultura organizacional possui uma influncia direta no projeto. Por exemplo uma equipe que prope uma abordagem pouco usual ou de alto risco ter maior aprovao em uma organizao agressiva e empreendedora e um gerente de projetos com estilo altamente participativo, provavelmente, encontrar problemas em uma organizao com hierarquia rgida e vice-versa. De acordo com Olson e Olson (2004), a motivao dos indivduos tambm difere de pas para pas dependendo das suas culturas. Em pases onde existe a valorizao do individualismo, as pessoas buscam ganho material e reconhecimento pessoal. J, em outros, onde a nfase est voltada ao coletivo, buscam-se relacionamentos pessoais e famlia. Os sistemas de recompensa devem levar em conta esses valores, recompensando cada grupo com valores monetrios ou dias de folga de acordo com seus valores. O tipo de tecnologia usado na comunicao pelos participantes que se encontram fisicamente distantes tambm exerce impacto sobre o projeto devido s diferenas culturais. Por exemplo, em alguns pases, a consumao de um negcio deve ser realizada face-a-face enquanto que em outros, pode-se faz-lo por carta ou telefone. A utilizao de vdeo41

conferncia ou udio-conferncia deve levar em conta que alguns pases valorizam os gestos e a entonao da voz e para eles, o vdeo importante. O brainstorming annimo permite que as pessoas ofeream idias sem medo de serem impopulares ou consideradas estpidas, fazendo com que mais idias sejam geradas, mas no indicado para culturas onde existe a valorizao da autoridade e da hierarquia (OLSON E OLSON, 2004). As diferenas relacionadas com o horrio do dia tambm afetam o trabalho em ADDS, pois, se houver a necessidade de comunicao em tempo real, podem no haver horrios adequados devido ao fuso horrio. A hora do dia em que ocorrer a comunicao pode gerar fadiga, fome e indisposio. Tambm existe a diferena de horrio e dias de trabalho, e de dias de feriado de pas para pas e de quantidade de horas semanais trabalhadas. Com o aumento da participao em equipes distribudas, as diferenas culturais ficam mais evidentes e h tambm a necessidade de aumentar a habilidade em lidar com elas. Muitas empresas j treinam os empregados para lidar com as diferenas culturais mas, apesar da sensibilidade adquirida, em momentos de stress, elas podem gerar problemas no desenvolvimento do projeto (OLSON E OLSON, 2004).

3.3.3 Follow-the-Sun
Este termo utilizado para mostrar que as organizaes que trabalham com equipes onde existe diferena de fuso horrio podem seguir o sol fazendo com que o trabalho tenha continuidade e possibilitando um trabalho de 24 x 7, o que significa 24 horas por 7 dias da semana. A idia da utilizao de diferenas de horrio ao redor do mundo para fornecer ajuda on-line aos usurios est sendo usado por algumas multi-nacionais que possuem escritrios em vrias partes do mundo e por universidades espalhadas nos continentes que formam uma associao e fornecem solues a qualquer hora do dia (SYKES, 2002). Os benefcios da utilizao do folow the sun so: reduo do cronograma/tempo, possibilidade de acesso a recursos globais, facilitao de associao e incio de relacionamento com organizaes internacionais, possibilidade da utilizao de uma srie de habilidades e experincia disponibilizada nos locais distribudos, maior conferncia dos assuntos que consequentemente leva a um aumento de eficincia (GKN AEROSPACE, 2005). Se houver a utilizao do follow-the-sun , a comunicao entre as equipes no pode falhar, pois caso haja alguma falha na comunicao, a equipe seguinte no ciclo de trabalho no receber as informaes necessrias para a continuidade do trabalho.

42

3.3.4 Nveis de Disperso

Uma classificao feita por Prikladnicki (2003) define bem o nvel de disperso em DDS considerando trs atores principais: a equipe do projeto (P), o cliente (C) e o usurio (U). A classificao foi dividida em inter-atores e intra-atores. A inter-atores no considera a disperso dentro do grupo P, C ou U e definida da seguinte forma: Mesma localizao fsica: os trs atores esto em um mesmo local e podem se reunir sem dificuldades. Distncia nacional: os atores esto localizados dentro de um mesmo pas podendo se reunir em curtos intervalos de tempo e dependendo do pas pode haver diferenas de fusohorrio e as diferenas culturais podem ser maiores. Distncia continental: os atores esto localizados dentro de um mesmo continente e as reunies se tornam mais difceis de serem realizadas face a face. A diferena de fuso-horrio pode dificultar as interaes. Distncia global: os atores esto em continentes diferentes formando muitas vezes uma distribuio global. As reunies face a face ocorrem geralmente no incio dos projetos e a comunicao e as diferenas culturais so complicadores potenciais. O fuso-horrio pode atrapalhar as interaes entre as equipes. Na distribuio intra-atores, o autor considerou a distribuio onde existe disperso entre atores do mesmo tipo: a equipe pode ter vrios de seus membros dispersos fisicamente, os usurios tambm podem estar separados fisicamente tanto quanto os clientes. A disperso pode ter diferentes nveis dentro de cada grupo de atores, similarmente disperso interatores: mesma localizao fsica, distncia nacional, distncia continental e distncia global.

3.3.5 Armazenamento do Conhecimento dos Projetos Distribudos

De acordo com Desousa e Evaristo (2004), existem 3 tipos de conhecimentos gerados por projetos: (1) conhecimento interno aos projetos; (2) conhecimento sobre projetos; e (3) conhecimentos originados por projetos. O conhecimento interno aos projetos se refere aos conhecimentos mais aprofundados sobre os projetos, tais como: cronogramas, marcos, minutas de reunies, manuais de treinamento. Os participantes do projeto precisam saber quando, o que, onde, por que algo est sendo feito e por quem est sendo feito com o objetivo de promover uma coordenao eficiente e efetiva.

43

O conhecimento sobre projetos se refere aos conhecimentos gerais sobre os projetos, tais como: participantes ligados aos projetos, retorno sobre investimento, anlise de custo e benefcio, prazos finais, compromissos e expectativas dos clientes. O conhecimento originado por projetos se refere aos conhecimentos obtidos de uma anlise posterior ao trmino dos projetos. Este tipo de conhecimento conduzir a organizao para um aumento das chances de sucesso em projetos futuros por meio das lies aprendidas. Existem duas formas bastante difundidas para o armazenamento destas informaes: cliente-servidor e ponto a ponto. O paradigma cliente-servidor est relacionado com a centralizao do conhecimento e o paradigma ponto a ponto com a descentralizao. As 2 formas de armazenamento possuem pontos positivos e negativos e esto detalhados a seguir, de acordo com uma anlise realizada em 3 dimenses: compartilhamento, controle e estruturao do conhecimento. Compartilhamento: (1) Centralizado: traz uma sensao de menos valor aos membros da equipe que sentem receio em compartilhar seu conhecimento com uma comunidade grande. Tambm ocorrem atrasos entre o momento em que o conhecimento criado pelas mentes dos indivduos at ser armazenada no repositrio, o que vai contra o conceito de disponibilidade de conhecimento em tempo real. E, alm disso, os indivduos preferem armazenar seus documentos de trabalho e anotaes ainda no terminadas nos repositrios locais. (2) Descentralizado: promove o dilogo entre os vrios membros da equipe e desenvolve um esprito de comunidade, com cada um interagindo com o outro ponto para adquirir conhecimento. Controle: (1) Centralizado: desliga o controle do criador do conhecimento, pois, uma vez que o conhecimento armazenado, o autor perde o controle de acesso e uso do conhecimento. (2) Descentralizado: cada membro da equipe retm o seu conhecimento e o controle sobre a sua visibilidade fazendo com que cada um sinta mais segurana com relao ao seu valor para a organizao. Estruturao: (1) Centralizado: o conhecimento estruturado em dimenses, tais como: equipes, produtos, divises, o que possibilita um acesso mais rpido aos elementos. Isso facilita o uso de filtros e mecanismos de categorizao para seleo. Entretanto, a natureza das chamadas centralizadas exige a utilizao de filtros e mecanismos de categorizao globais que fixam limites para relevncia, preciso e outros atributos de conhecimento, podendo levar perda de conhecimentos considerados importantes para o projeto. O esforo para que os fornecedores do conhecimento categorizem a informao com o uso de palavras chave e metadados antes de coloc-los no repositrio torna este tipo de 44

armazenamento pouco atrativo. (2) Descentralizado: cada um pode escolher o seu esquema de categorizao para armazenar o conhecimento. Apesar de ser mais flexvel, isso torna o acesso e a disponibilidade das informaes bastante difcil por ter uma estruturao muito pobre do conhecimento. Ainda, segundo Desousa e Evaristo (2004), armazenar o conhecimento interno aos projetos de forma centralizada no trar benefcios para a organizao, pois este conhecimento no de interesse da maioria dos membros da organizao e, alm disso, a constante atualizao, que em muitos casos realizada diariamente para registrar detalhes, tais como: cronogramas, marcos, minutas de encontros e manuais de treinamento causaria um trfego muito alto na rede, alm da necessidade de um repositrio com grande capacidade de armazenamento. Por outro lado, usar o paradigma centralizado para armazenar o conhecimento sobre os projetos e originado pelos projetos mais recomendado, pois as informaes gerais dos projetos no so modificadas constantemente e, alm disso, usar o paradigma descentralizado traria dificuldades de categorizao e filtro. Para o conhecimento originado pelos projetos a centralizao do conhecimento tambm ajudar a manter um histrico de lies aprendidas disponvel para toda a organizao. Portanto, uma estrutura hbrida onde existe a centralizao das informaes genricas e a descentralizao das informaes detalhadas dos projetos a mais indicada. Um repositrio central com o conhecimento sobre projetos e originado pelos projetos serve de ndice para um outro repositrio disponvel de forma descentralizada com o conhecimento interno aos projetos (DESOUSA E EVARISTO, 2004).

3.4 Consideraes Finais

Este captulo apresentou os trabalhos j realizados dentro do DiSEN que foram integrados ao MGP construdo. Existem ainda outros trabalhos sendo desenvolvidos dentro do DiSEN que possuem uma estreita relao com todos os trabalhos realizados, pois correspondem estrutura que dar suporte ao MGP como o detalhamento do canal de comunicao, workspace e persistncia. Tambm outro trabalho que est sendo executado em paralelo para o DiSEN o de interoperabilidade entre ferramentas que abrir um caminho para que seja possvel a interoperabilidade com ferramentas de gerenciamento de requisitos e de estimativas de tempo e custo. Alm disso, este captulo tambm apresentou os temas relacionados ao DDS de forma resumida para melhor entendimento do trabalho. 45

CAPTULO IV Gerenciamento de Projetos de Software 4.1 Introduo

O GP de software surgiu com base no GP de outras reas e realiza o gerenciamento utilizando-se de uma estrutura denominada projeto. Para um entendimento melhor do que trata um MGP preciso entender primeiramente do que se tratam: Projetos, GP e GP de software.

4.2 Projetos
A definio de projeto foi dada no Item 1.6.2. e, dentro de uma organizao, o projeto uma estratgia para se alcanar os seus objetivos. Alm disso, todo desenvolvimento de software se constitui em um projeto. Para uma compreenso mais detalhada apresenta-se o contexto dos projetos dentro de uma organizao, o ciclo de vida de um projeto e como se cria uma estrutura analtica de projeto (EAP).

4.2.1 Projetos e Planejamento Estratgico

Um projeto uma forma de organizar as atividades envolvendo todos os nveis da organizao, sua durao pode variar de poucas semanas a vrios anos e podem incluir vrias unidades organizacionais por meio de parcerias (PMI, 2004a). De acordo com o modelo processual do PMI (PMI, 2004a), os projetos so utilizados como um meio de atingir o plano estratgico de uma organizao. Sendo assim, o projeto est dentro de um contexto estratgico da organizao. A Figura 7 mostra o modelo conceitual para o planejamento estratgico de uma organizao (CLELAND e IRELAND, 2002). Para um entendimento dos conceitos utilizados na Figura 7, tem-se que: Viso: a imagem das expectativas futuras da empresa. Misso organizacional: a declarao do negcio da organizao. Objetivo: a declarao dos fins que devem ser atingidos para que a misso seja cumprida. Meta: o marco a ser alcanado. Estratgia organizacional: a definio dos meios que sero usados para se atingir os objetivos. Os projetos constituem a pea fundamental no desenho e na implantao das estratgias.

46

Figura 7. Modelo para Planejamento Organizacional (CLELAND e IRELAND, 2002).

Estrutura organizacional: a forma pela qual os recursos esto dispostos dentro dos nveis da organizao. Papis organizacionais: so as funes desempenhadas pelos membros da organizao. Estilo do gerente e do seguidor: a maneira pela qual os conhecimentos, habilidades e atitudes so expressas em comunicaes. Sistemas: so um conjunto de elementos que do suporte s atividades organizacionais. Recursos organizacionais: so os RH e materiais que a organizao pode utilizar para cumprir sua misso, seus objetivos e metas.

4.2.2 Ciclo de Vida de Projetos

O ciclo de vida de um projeto possui caractersticas comuns, que so (PMI, 2004a):

47

Diviso em fases que variam muito de acordo com a rea de aplicao; As fases geralmente so seqenciais e definidas por algum formulrio de transferncia de informaes tcnicas ou de entrega de componentes tcnicos; Dentro de cada fase temos: a) a definio do trabalho tcnico a ser realizado; b) quando as entregas devem ser geradas e como elas sero revisadas, verificadas e validadas; c) quem est envolvido em cada fase; e d) como cada fase ser controlada e aprovada;

Os nveis de custos e de pessoal so baixos no incio, atingem o valor mximo nas fases intermedirias e diminuem rapidamente na fase final; Os riscos so mais altos no incio do projeto e diminuem medida que o projeto progride; A capacidade das partes interessadas de influenciarem as caractersticas finais do produto do projeto e o custo final do projeto mais alta no incio e diminui conforme o projeto continua.

E, podemos ter ainda (MAXIMIANO, 2002): A sobreposio de fases possvel em todos os tipos de projeto. Uma fase pode se iniciada antes que a fase anterior esteja terminada. O processo de sobrepor fases do projeto chamado de fast-tracking (ritmo acelerado); Detalhamento progressivo dos planos medida que novas fases se aproximam. Isso conhecido como rolling wave planning (planejamento em ciclos). De acordo com Cleland e Ireland (2002), o ciclo de vida de um projeto possui 5 fases: conceituao, definio, produo, operacional e desinvestimento (CLELAND e IRELAND, 2002). Na fase de conceituao uma avaliao inicial e um exame inicial dos objetivos, alternativas, desempenho tcnico, custos e aspectos do cronograma, so realizados. Na fase de definio, determina-se o custo, a programao, as expectativas de desempenho tcnico, os recursos necessrios e os ajustes operacionais e estratgicos necessrios. Na fase de produo os resultados do projeto so produzidos e apresentados como um produto, um servio ou um processo organizacional eficiente, econmico e sustentvel. Na fase operacional os resultados so comprovados pelo usurio e na fase de desinvestimento, a empresa sai do negcio diminuindo os recursos empregados no projeto. O ciclo de vida de um projeto varia de poucas semanas ou meses at vrios anos.

48

J em projetos de software, temos uma diviso de fases que varia de acordo com o processo escolhido: em cascata (requisitos, anlise, implementao e testes), Rational Unified Process (inception, elaboration, construction, transition).

4.2.3 Estrutura Analtica de Projeto

Uma EAP, tambm conhecida como Work Breakdown Structure (WBS), uma forma de dividir o projeto em partes gerenciveis. Para criar uma EAP, o projeto dividido em tarefas maiores que depois so divididas novamente at atingir o melhor nvel para gerenciamento. Um exemplo a identificao de cada tarefa como abaixo: 1 1.1 1.1.1 1.1.2 1.2 2 Para a criao da EAP importante o envolvimento dos integrantes da equipe e pessoas com experincia. A EAP um veculo para se realizar o oramento e avaliar custos. Uma EAP bem estruturada um fator crtico para o sucesso do projeto e depende principalmente: do estilo do gerenciamento de projeto, da cultura organizacional, da preferncia do cliente e das restries financeiras. Uma EAP uma hierarquia de elementos que decompem o plano do projeto em tarefas e fornece informaes sobre: o delineamento de todo o trabalho significativo, uma decomposio de tarefas clara para possibilitar a associao com as pessoas que realizaro as tarefas, uma estrutura para o cronograma, oramento e para monitoramento de gastos (ROYCE, 1998).

4.3 Gerenciamento de Projeto

O GP era usado de maneira informal em construes remotas como na Grande Pirmide do Egito, nas antigas catedrais da Europa, em aquedutos, estradas e castelos. A disciplina surgiu na dcada de 50 e foi utilizada primeiramente na indstria de construo e, hoje, a sua utilizao abrange a rea de materiais blicos, medicina, farmcia e desenvolvimento de sistemas de software entre outras.

49

Os benefcios da utilizao do GP tm levado as organizaes a, cada vez mais, aprimorarem seus sistemas de gerncia valendo-se dos mesmos como um diferencial competitivo. O uso da gerncia de projetos supera de forma consistente o desempenho das funes sem o seu uso. importante que a organizao entenda que o GP deve ser aplicado formando um sistema que dar suporte implementao estratgica e, tambm, o GP no deve esquecer que uma organizao composta de tarefas, pessoas, tecnologia, estrutura (LEAVITT, 1965 apud TAIT, 2000) e cultura organizacional (KEEN, 1981 apud TAIT, 2000). A qualidade do GP depende da qualidade do sistema de informaes em GP (SIGP), que: fornecer informaes aos stakeholders do projeto utilizando-se de fontes formais e informais; ir cobrir o ciclo de vida do desenvolvimento; ir apoiar o SI da organizao interagindo com os SIs de outras reas da organizao; facilitar a tomada de deciso; reduzir as surpresas ao longo do projeto; e, estar focado nas reas crticas do projeto. Para maior entendimento do tema, foram acrescentadas explicaes sobre: benefcios do GP, funes do GP, principais processos do GP e caractersticas do moderno GP.

4.3.1 Benefcios do Gerenciamento de Projeto

O GP empregado como um processo para que a estratgia de utilizao de projetos leve ao alcance das metas, objetivos e misso da organizao e traz benefcios organizao, aos administradores, aos lderes e membros das equipes de projetos e aos clientes. Dentre eles, podem ser destacados: a melhoria da produtividade, o aumento dos lucros, a maior capacidade e maturidade nas solues de negcios, melhor confiana e previsibilidade da fora da organizao e maior satisfao no trabalho (CLELAND e IRELAND, 2002). Para que esses benefcios sejam alcanados, o GP deve ser executado atentando para os fatores que dificultam o gerenciamento, tais como: a cultura organizacional, o surgimento de conflitos, a falta de comunicao e a necessidade de habilidade do gerente de projetos. J para Pressman (2001) o GP deve estar focado nos 4 ps: Pessoas, produto, processo e projeto. O cultivo de pessoas altamente habilidosas e motivadas de extrema importncia para o sucesso do projeto, tanto que o SEI (Software Engineering Institute) indica um modelo para a avaliao da maturidade e capacidade das organizaes relativo ao gerenciamento de RH denominado People Capability Maturity Model (PCMM) (CURTIS, REFLEY e MILLER, 2001). Com relao ao produto, que neste caso o software, a definio dos objetivos e escopo, alm das restries tcnicas e de gerenciamento so imprescindveis para definir estimativas de custo, avaliar os riscos, definir a EAP e o cronograma do projeto. J, o 50

processo do software fornece um framework para o estabelecimento do plano do projeto onde j podemos identificar: tarefas, marcos, produtos desenvolvidos, e pontos de garantia de qualidade e, por fim, o projeto a nica forma conhecida para o desenvolvimento de software planejado e controlado.

4.3.2 Funes da Gerncia de Projetos

Segundo Cleland e Ireland (2002), as principais funes da gerncia de projetos so: planejamento, organizao, motivao, direo e controle. A seguir, uma breve descrio de cada uma delas: Planejamento: Qual o alvo e por qu? A misso da organizao usada para determinar os objetivos, as metas e estratgias do projeto. So estabelecidas as polticas, procedimentos, tcnicas e documentaes necessrias para a utilizao prevista de recursos e que levaro ao alcance dos objetivos. Organizao: O que est envolvido e por qu? Determinam-se os RH e materiais e estabelecem-se os modelos de autoridade e responsabilidade. Motivao: O que traz tona o que h de melhor nas pessoas? Identificam-se as necessidades, os fatores que motivam os membros da equipe e o estilo de liderana mais adequado para aumentar a satisfao e a produtividade. Os aconselhamentos e assessorias adequados so fornecidos e um programa de recompensas estabelecido. Direo: Quem decide o qu e quando? Desenvolve-se o estilo de liderana e as tcnicas de tomadas de deciso em consenso para a equipe. Controle: Quem julga os resultados e mediante quais padres? Estabelecem-se padres de custos, programa e desempenho tcnico para o projeto, o sistema de informao de gerncia para obter o feedback do projeto e fazer a avaliao do andamento do projeto. Segundo Dinsmore (1992), o planejamento a funo que exerce maior impacto dentro do projeto, pois inclui: a fixao dos objetivos, previso de recursos, preveno de dificuldades e esboo de solues.

4.3.3 Principais Processos da Gerncia de Projetos

Um processo composto de atividades e o GP, normalmente, apresentado na forma de processos para uma visualizao mais detalhada de como e onde executar cada conjunto de atividades. A diviso dos processos pode variar bastante de acordo com o nvel de detalhe considerado. Apresentam-se duas figuras (Figura 8 e 9) em nvel no muito detalhado para melhor compreenso dos processos que envolvem o GP. 51

Na Figura 8 apresentada por Shtub, Bard e Globerson (1994) os projetos so iniciados por uma necessidade que pode ser identificada por um cliente, um departamento ou um membro da organizao.
Identificar uma necessidade de produto ou servio

Definir os objetivos do projeto e as prioridades

Selecionar as medidas apropriadas de desempenho

Desenvolver o cronograma

Desenvolver o oramento

Desenvolver o projeto inicial

Integrar em um plano do projeto

Implementar o plano

Monitorar e controlar o projeto

Avaliar o sucesso do projeto

Figura 8. Processos Principais no GP (SHTUB, BARD e GLOBERSON, 1994).

52

Quando se est convencido de que a necessidade genuna, os objetivos podem ser definidos e os primeiros passos so dados para se estruturar a equipe do projeto. A maioria dos projetos possui vrios objetivos que englobam aspectos de requisitos tcnicos e operacionais, datas de entrega e custo. Estes objetivos podem ser priorizados em uma hierarquia de acordo com a relevncia de cada um. Baseado na hierarquia, um conjunto de medidas de desempenho para cada objetivo pode ser desenvolvido. Pode-se, ento, desenvolver o projeto inicial juntamente com o cronograma e o oramento. O prximo passo integr-los em um plano de projeto especificando quem, com que custo e quando cada atividade dever ser desenvolvida. Conforme o plano implementado, os acompanhamentos so realizados para monitorar e registrar os acontecimentos. Ajustes so feitos e as medidas corretivas necessrias so feitas caso haja desvio com relao ao plano. E, quando o projeto termina, seu sucesso avaliado com base nos objetivos e medidas de desempenho pr-determinados.

Preparao

Estruturao

Execuo

Concluso

Idia inicial

Montagem da equipe

Realizao das atividades

Apresentao do produto

Definio do produto

Detalhamento dos planos

Controle do progresso

Aprovao do cliente

Definio de atividades, prazos e custos

Aprovao

Administrao de mudanas no escopo, prazo e custo

Fechamento administrativo (relatrios, balanos)

Proposta bsica

Mobilizao dos recursos

Concluso do produto

Desmobiliza o dos recursos

Aprovao

Incio do projeto

Incio de novo ciclo de vida

Figura 9. Processos da Administrao de um Projeto (MAXIMIANO, 2002).

53

Na viso de Maximiano (2002), os processos para administrar um projeto podem ser realizados em quatro processos: preparao, estruturao, execuo e concluso. A Figura 9 apresenta estes processos. A preparao compreende: a definio do produto e das estimativas iniciais de prazo e custo e vrias anlises antes que o projeto seja aprovado. Na fase de estruturao, os recursos so mobilizados e um plano mais detalhado desenvolvido. A fase de execuo consiste na realizao dos planos e na fase de concluso o produto apresentado e as atividades administrativas so encerradas.

4.3.4 Caractersticas do Moderno GP

O enfoque no moderno GP : o conhecimento, as experincias e habilidades que so requeridos dos membros das equipes de projeto e, tambm, o conhecimento gerado pela equipe. Uma forma de polarizar estes conhecimentos o escritrio de projetos (VALERIANO, 2005). As caractersticas encontradas no moderno GP so: Descentralizao: Devido ao volume e variedade dos assuntos envolvidos no GP, e considerando a constante urgncia do fator tempo. A delegao de responsabilidade e autoridade divide o trabalho ao longo da EAP do projeto. Cada participante do projeto um pequeno gerente da parte que lhe foi atribuda. Trabalho em equipe: Cada grupo constitudo assume a misso da organizao e trabalha tendo por objetivo comum o resultado do projeto tendo como estmulo a evoluo profissional e a consecuo das metas estabelecidas. Conhecimento da organizao responsvel pelo projeto e de sua administrao geral: O projeto est inserido na organizao e deve-se, portanto, conhecer o contexto da organizao, sua misso, estratgias, polticas e o ambiente que a envolve. Todos os participantes do projeto devem possuir conhecimentos bsicos para que a descentralizao seja efetiva e para que o trabalho em equipe flua normalmente com eficincia na organizao. Dentre os conhecimentos bsicos encontrados, foram citados por Valeriano (2005): Conhecimento geral do moderno GP: para trabalhar de forma descentralizada, em pequenos grupos ou individualmente necessrio ter um conhecimento geral do MGP, de seus mecanismos, mtodos e processos, ferramentas, etc. Conhecimento das gestes: cada parte do projeto pode ser considerada uma miniatura de projeto com sua estrutura, oramento e cronograma prprios e cada participante fornece

54

dados para a elaborao de documentos de planejamento e deve conhecer a gesto envolvida para contribuir com o fornecimento de dados, informaes, conhecimentos e experincias. Formao de equipe: todos devem conhecer as tcnicas de formao e de conduo de equipes. Relacionamento: como o nmero de pessoas e grupos que fazem parte do projeto grande, existe a necessidade de conhecimentos de processos referentes a relacionamentos interpessoais ou intergrupais. Normas, regulamentos e padres: com a globalizao e a exigncia do mercado surgiu a necessidade de observar normas, regulamentos e padres internacionais. Propriedade intelectual: a criao em um projeto precisa ser protegida mas no deve usurpar o direito de outros. Escritrio de projetos: o escritrio de projetos centraliza informaes e a coleta, classificao, guarda e disseminao de dados, informaes e conhecimentos de interesse sobre os projetos da organizao.

4.4 Gerenciamento de Projetos de Software

O GP a primeira camada do processo de desenvolvimento do software, pois abrange todo o processo de desenvolvimento, do comeo ao fim (PRESSMAN, 1995). Segundo Teixeira (2001) o GP de software abrange desde o planejamento at a fase de teste, documentao e implantao do sistema. E, ainda, de acordo com Nienaber e Cloete (2003), o GP de software envolve todos os aspectos e questes envolvidas no desenvolvimento de um projeto de software, que so: escopo, objetivo, planejamento, avaliao, tcnicas de desenvolvimento do projeto, estimativa de custo e esforo, planejamento de atividades, monitorao e controle, planejamento de riscos, alocao e controle de recursos, gerenciamento de contratos, equipes e qualidade. Para que um projeto de software seja bem-sucedido deve-se compreender o escopo do trabalho a ser realizado, os riscos que o envolvem, os RH e materiais necessrios, as tarefas a serem executadas, os pontos de monitoramento e controle, o esforo necessrio para executar cada tarefa e o custo necessrio para realizar cada tarefa e, o GP fornece essa compreenso. Especificamente, a rea de gerncia de projetos de software possui particularidades que dificultam ainda mais o gerenciamento, tais como: mudana da tecnologia, rodzio de pessoal que possui conhecimento especfico sobre a tecnologia e a intangibilidade do software. Este ltimo, torna necessrio a criao de artefatos e

55

documentaes para avaliar o software e, que, muitas vezes, no corresponde ao software realmente implementado. A seguir uma compreenso mais detalhada sobre: (a) os processos de desenvolvimento de software que foram definidos com a finalidade de se obter uma receita de sucesso; e, (b) as mtricas para o GP de software para melhor-lo. Com a distribuio fsica das pessoas, o GP se torna ainda mais complicado, pois existem dificuldades maiores de comunicao e diferenas culturais.

4.4.1 Processo de Desenvolvimento de Software

Um processo composto de fases e atividades com marcos entre as fases. Os marcos representam os pontos onde deve haver uma verificao dos artefatos construdos na fase que terminou para que a fase seguinte possa ser iniciada. Esses marcos so os pontos onde o gerente de projetos pode fazer a avaliao do projeto de forma mais incisiva. Existem vrios tipos de processo: linear ou seqencial, prototipao, incremental, espiral, formal (THAYER, 1997). A seguir uma breve descrio sobre cada um deles. Processo linear ou seqencial: o mais antigo e conhecido tambm como clssico ou waterfall. Mantm uma abordagem seqencial que possui fases. As fases devem ser executadas em seqncia e de uma nica vez: anlise, projeto, implementao e teste. Prototipao: comea com a obteno de requisitos e aps isso, desenvolve-se um projeto rpido. O projeto se foca na representao de aspectos visveis ao cliente/usurio. Aps a avaliao do prottipo pelo cliente/usurio, os requisitos so refinados e o prottipo melhorado. As duas etapas so realizadas at que o software esteja finalizado. Processo incremental: parecido com o de prototipao, mas usado quando os requisitos no esto bem definidos e quando os riscos do projeto, tais como: disponibilidade de equipe e data de entrega criam problemas potenciais para o gerenciamento. Este modelo define uma srie de incrementos e cada um deles apresenta um produto. A cada incremento ou iterao o plano do projeto refeito. A diferena com a prototipao que o incremental no fornece uma viso do produto para que o cliente/usurio possa avali-lo. Processo espiral: uma juno da iterao com a prototipao usando aspectos sistemticos e controlados do linear. O software produzido em incrementos. Nas fases iniciais o incremento pode ser um prottipo. Nas fases posteriores vises mais completas so produzidas. Normalmente, em cada incremento da espiral so realizados seis grupos de tarefas: comunicao com o cliente, planejamento, avaliao de riscos, engenharia (representao da aplicao), construo e verso e avaliao do cliente. 56

Processo formal: exige atividades de especificao matemtica formal do software. Permite que o engenheiro de software desenvolva e verifique um sistema baseado em computadores usando notaes matemticas rigorosas. bastante apropriado para construir softwares crticos.

4.4.2 Mtricas para o GP de Software

Tudo pode ser medido e segundo a lei de Tom Gilb Qualquer coisa que voc precise quantificar pode ser de algum modo superior a no medir nada (MARCO e LISTER, 1990). O software medido para: 1) indicar a qualidade do produto; 2) avaliar a produtividade das pessoas que produzem o produto; 3) avaliar os benefcios (em termos de produtividade e qualidade) derivados de novos mtodos e ferramentas de software; 4) formar uma base line para estimativas; 5) ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional (PRESSMAN, 1995). O processo de medio aquele, no qual, nmeros ou smbolos so atribudos para atributos de entidades no mundo real de uma forma que as descreve, mas, de acordo com regras claramente definidas. No podemos simplesmente dizer equipe que o software deve ser fcil de usar sem colocar em atributos bem claros o que isso significa. Na rea de engenharia de software muitas promessas so feitas com relao facilidade de uso, confiana e facilidade de manuteno do software, mas sem especificar claramente e objetivamente o que significa isso. Sendo assim, no podemos afirmar que atingimos os objetivos quando o projeto est concludo (FENTON e PFLEEGER, 1997). Existem vrias tipos de mtricas e que podem ser classificadas em diversos grupos. A seguir, so mostradas algumas classificaes encontradas na literatura: As mtricas podem ser classificadas como: a) Mtrica qualitativa de software: medida que afeta a qualidade do software. Ex.: confiabilidade, manutenibilidade, portabilidade, usabilidade, integridade; b) Mtrica quantitativa de software: medida quantitativa de algum atributo fsico do software. Ex.: linhas de cdigo, pontos por funo e pginas de documentao; e, c) Mtrica de gerenciamento: indicador que pode ser usado para medir atividades de gerenciamento. Ex.: oramento gasto, lucro, custos, atrasos no cronograma. As mtricas tambm podem ser classificadas como (SEI, 2002): a) Bsicas: medidas obtidas diretamente sobre o processo, produto ou pessoas. Ex.: nmero de pginas de documentao, nmero de pessoas hora, qualidade (nmero de defeitos); e, 57

b) Derivadas: medidas obtidas pelas medidas bsicas. Ex.: valor agregado, ndice de desempenho do cronograma, percentual de defeito, tempo para ocorrer uma falha, nmero de defeitos por grau sobre o nmero total de defeitos. Tambm existem mtricas: a) Manuais: Obtidas manualmente. Ex.: satisfao do cliente; e, b) Automticas. Obtidas automaticamente pela utilizao de ferramentas que fazem o clculo. Ex.: linhas de cdigo. Outras mtricas de software se tornaram comuns com o uso da Internet, tais como as realizadas por Zhu e Gauch (2000): 1) Atualizao: a freqncia de atualizao de uma pgina Web; 2) Disponibilidade: o nmero de links no disponveis; 3) Respeitabilidade: a reputao da organizao que produziu a pgina; e, 4) Popularidade: quantas outras pginas citaram uma determinada pgina. O desenvolvimento de software pode ser medido como qualquer outra atividade ou objeto. Para o GP, as medidas so extremamente importantes para que se calcular a eficcia do processo que levar melhoria do software e tambm para medir o prprio software que deve estar de acordo com seus requisitos ou necessidades do cliente. Se o custo dos componentes do projeto no for armazenado, no se pode control-lo. Se a qualidade do software no for quantificada, no se pode garantir que est livre de falhas, ou que o software mais confivel, ou que melhora a produtividade. Segundo DeMarco (1982 apud Fenton e Pfleeger, 1997), voc no pode controlar o que no pode medir. Existem trs conjuntos fundamentais de mtricas de gerenciamento: progresso tcnico, status financeiro e progresso da equipe (ROYCE, 1998). Com esses trs conjuntos o gerente de projeto pode avaliar se o projeto est dentro do cronograma e oramento. O trabalho e o progresso devem ser avaliados pelo trabalho completado ao longo do tempo. Uma medida de progresso para o gerente de projetos so os marcos completados. O gerente do projeto sabe exatamente quanto j foi gasto em termos financeiros e quanto tempo j foi gasto no desenvolvimento do projeto, o que ele no conhece quanto j foi realizado do trabalho que est planejado. A mtrica de produtividade uma das mais importantes para o GP, pois determina o tempo que um participante demorar para terminar uma atividade do projeto. De acordo com Basili e Zelkowitz (1978 apud PRESSMAN, 1995), existem cinco fatores que influenciam a mtrica de produtividade: 1) Fatores humanos: O tamanho e a experincia da organizao de desenvolvimento; 58

2) Fatores do problema: a complexidade do problema a ser resolvido e o nmero de mudanas nos requisitos; 3) Fatores do processo: tcnicas de anlise e projeto usadas, linguagens e ferramentas CASE (Computer-Aided Software Engineering) disponveis e tcnicas de reviso; 4) Fatores do produto: confiabilidade e desempenho do sistema baseado em computador; e 5) Fatores de recursos: disponibilidade de ferramentas CASE, recursos de hardware e software.

4.5 Consideraes Finais

Neste captulo procurou-se identificar os principais elementos e caractersticas dos projetos, do GP e do GP de software para que o MGP desenvolvido seja compreendido dentro do seu contexto. A viso apresentada aqui est no nvel mais geral e no apresenta detalhes do GP. J o captulo seguinte apresenta MGPs que contm mais elementos que esclarecem mais o GP.

59

CAPTULO V Modelos de Gerenciamento de Projetos 5.1 Introduo

Dentre os modelos estudados, destacam-se: o Modelo Processual do PMI (PMI, 2004a), o CMMI (SEI, 2002), o MGP baseado no PMI para ADDS (ZANONI, 2002) e o Modelo MuNDDoS (PRIKLADNICKI, 2003). A seguir, uma breve descrio de cada um deles. Por fim, um quadro comparativo entre os modelos apresentado.

5.2 Modelo Processual do PMI

Este modelo divide a gerncia de projetos em nove reas de conhecimento (PMI, 2004a): 1. Gerncia de Integrao do Projeto: possui processos necessrios para garantir que as diversas partes esto sendo coordenadas adequadamente. Consiste nos processos: Desenvolver o termo de abertura do projeto, Desenvolver a declarao do escopo preliminar do projeto, Desenvolver o plano de gerenciamento do projeto, Orientar e gerenciar a execuo do projeto, Monitorar e controlar o trabalho do projeto, Controle integrado de mudanas e Encerrar o projeto. 2. Gerncia do Escopo: possui processos para delimitar o projeto. Consiste nos

processos: Planejamento do escopo, Definio do escopo, Criar EAP (Estrutura Analtica de Projeto), Verificao do escopo e Controle do escopo. 3. Gerncia do Tempo: possui processos para assegurar que o projeto ser implementado dentro do prazo previsto. Consiste nos processos: Definio das atividades, Definio da seqncia das atividades, Estimativa de recursos das atividades, Estimativa de durao das atividades, Desenvolvimento do cronograma e Controle do cronograma. 4. Gerncia de Custos: consiste basicamente nos custos associados ao projeto. Consiste nos processos: Estimativa de custos, Definio do Oramento e Controle de custos. 5. Gerncia da Qualidade: possui os processos necessrios para garantir e satisfazer as necessidades definidas no escopo. Consiste nos processos: Planejamento da qualidade, Realizao da garantia da qualidade e Realizao do controle da qualidade. 6. Gerncia dos RH: possui os processos para o uso mais efetivo das pessoas envolvidas no projeto. Consiste nos processos: Planejamento de RH, Contratao ou mobilizao da equipe do projeto, Desenvolvimento da equipe do projeto e Gerenciamento da equipe do projeto. 60

7. Gerncia de Comunicaes: possui os processos requeridos para garantir a gerao, coleta, distribuio, armazenamento e o controle das informaes do projeto. Fornece ligaes entre pessoas, idias e informaes que so necessrias para o sucesso do projeto. Consiste nos processos: Planejamento das comunicaes, Distribuio das informaes, Relatrio de desempenho e Gerncia das partes interessadas. 8. Gerncia de Riscos: possui processos para identificao, anlise e resposta aos riscos do projeto. Consiste nos processos: Planejamento do gerenciamento de riscos, Identificao de riscos, Anlise qualitativa de riscos, Anlise quantitativa de riscos, Planejamento a respostas a riscos e Monitoramento e controle de riscos. 9. Gerncia de Aquisio: possui os processos necessrios para a obteno de bens e servios externos. Consiste nos processos: Planejamento de compras e aquisies, Planejamento de contrataes, Solicitao de respostas de fornecedores, Seleo de fornecedores, Administrao de contrato e Encerramento do contrato. Cada um dos quarenta e quatro processos que compem as gerncias, possui entradas e sadas. As entradas so informaes necessrias para se executar o processo e as sadas normalmente so entradas para o processo seguinte. Os processos dentro de cada uma das reas de conhecimento foram agrupados em cinco grupos pelo seu desempenho e visando um objetivo integrado. A Tabela 01 apresenta uma visualizao dos processos nos grupos e nas reas de conhecimento. E, a seguir, uma breve descrio de cada um dos grupos de processos. 1. Grupo de processos de iniciao: define e autoriza o projeto ou uma fase do projeto; 2. Grupo de processos de planejamento: define e refina os objetivos e planeja a ao necessria para alcanar os objetivos e o escopo do projeto; 3. Grupo de processos de execuo: integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto; 4. Grupo de processos de monitoramento e controle: mede e monitora o progresso para identificar variaes com o que foi planejado de forma que aes corretivas possam ser tomadas quando necessrio; 5. Grupo de processos de encerramento: formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

61

Grupo de Processos rea de Conhecimento Integrao do GP

Grupo de processos de iniciao Desenvolver termo abertura projeto, Desenvolver declarao escopo preliminar projeto o de do a do do

Grupo de processos de planejamento

Grupo de processos de execuo Orientao e gerenciamento da execuo do projeto

Desenvolver o plano de gerenciamento do projeto

Grupo de processos de monitoramento e controle Monitoramento e controle do trabalho do projeto, Controle integrado de mudanas

Grupo de processos de encerramento Encerrar projeto o

Gerenciamento do escopo do projeto Gerenciamento do tempo do projeto

Gerenciamento de custos do projeto Gerenciamento da qualidade do projeto Gerenciamento de RH do projeto

Planejamento do escopo, Definio do escopo, Criar EAP Definio da atividade, Sequenciamento de atividades, Estimativa de recursos da atividade, Estimativa de durao da atividade, Desenvolvimento do cronograma Estimativa de custos, Oramentao Planejamento qualidade da Realizao da garantia da qualidade Contratao ou mobilizao da equipe do projeto, Desenvolvimento da equipe do projeto Distribuio das informaes

Verificao do escopo, Controle do escopo Controle do cronograma

Controle custos

de

Planejamento de RH

Realizao do controle da qualidade Gerenciamento da equipe do projeto

Gerenciamento das comunicaes do projeto Gerenciamento de riscos do projeto

Planejamento comunicaes

das

Gerenciamento de aquisies do projeto

Planejamento do gerenciamento de riscos, Identificao de riscos, Anlise qualitativa de riscos, Anlise quantitativa de riscos, Planejamento de respostas a riscos Planejamento de compras e aquisies, Planejamento de contrataes

Relatrio de desempenho, Gerenciamento das partes interessadas Monitoramento e controle de riscos

Solicitao respostas fornecedores, Seleo fornecedores

de de de

Administrao de contrato

Encerramento do contrato

Tabela 01. Mapeamento entre os processos de GP e os grupos de processos de GP e as reas de conhecimento (PMI, 2004a).

62

O Modelo Processual do PMI o padro mundial para gerncia de projetos. Por ser genrico, este modelo pode ser utilizado para todos os tipos de projetos e no somente para os projetos de software.

5.3 MGP Baseado no PMI para ADDS

Este modelo um modelo voltado ao gerenciamento de software para ambientes de desenvolvimento fisicamente distribudos, e leva em considerao questes que envolvem a distribuio geogrfica das pessoas (ZANONI, 2002). As caractersticas principais deste modelo so: (1) Possui ciclo de vida do tipo espiral; (2) Utiliza o processo de desenvolvimento de sistemas OO, com linguagem de especificao UML (Unified Modeling Language) e processo UP (Unified Process); e, (3) Incorpora a abordagem processual do PMI expandindo as reas de gesto indicadas. Este modelo possui seis fases, como mostra a Figura 10, e cada uma possui processos e condies de sada. 1. Fase de Anlise de Requisitos: inicia aps a escrita do plano de desenvolvimento do software. So realizadas nesta ordem: a anlise dos requisitos do negcio e depois a anlise do sistema, do subsistema e da unidade. So gerados cenrios nesta fase e o marco para passar para a prxima fase a aprovao dos estudos conceituais. 2. Fase de Projeto (Explorao e Definio): a primeira etapa o delineamento do projeto conceitual, na qual a equipe deve compreender o sistema. Outros trs projetos so envolvidos nesta fase: o lgico, o fsico e o final. So elaborados diagramas de caso de uso e o marco para passar para a fase 3 a aprovao para o desenvolvimento. 3. Fase de Processos de Produo: inicia com a construo de conceitos do projeto. Esta fase composta por trs produes que so repassadas para a fase seguinte. So elaborados diagramas de caso de uso, diagramas de classe, diagramas de atividades, diagramas de colaborao, diagramas de pacotes e diagramas de arquitetura. O marco aps esta fase a aprovao da produo. 4. Fase de Avaliao (Desdobramento e Testes): realizada a anlise de risco aps a prova de conceitos. Depois disso, so realizados o teste de componentes, teste de subsistema aps a primeira e segunda produo, respectivamente, e a avaliao de aceitao e aderncia aps a produo final. O plano de teste elaborado e o marco para a fase seguinte a aprovao das principais modificaes ou o aceite do usurio na ltima produo. 5. Fase de Processos de Transio: onde o software liberado. necessria a aprovao do sistema por meio da realizao de testes, e a aceitao do sistema pelo cliente 63

nesta fase. O software ajustado ao processo de negcio que ele suporta para torn-lo operacional. O instalador desenvolvido e realizada a instalao do software. 6. Fase de Processos de Integrao: feita a integrao confirmando a confiabilidade, integridade dos dados e o desempenho do projeto e depois disso existe a liberao para operao e suporte produo.

Figura 10. Ciclo de Vida do MGP Baseado no PMI para ADDS (ZANONI, 2002).

Este modelo prope tambm a expanso do Modelo Processual do PMI (PMI, 2004a) em mais quatro reas de conhecimento: 1. Gerncia do Planejamento: dividido em planejamento estratgico que dever conduzir os negcios com uma viso do futuro e o planejamento operacional que ser responsvel pela execuo dos objetivos. 2. Gerncia da Propriedade Intelectual: preocupada em legalizar os direitos autorais das partes desenvolvidas por diferentes atores em diferentes pases, com vrias empresas atuando em ambientes culturais diferentes.

64

3. Gerncia da Aprendizagem: preocupada em criar um ambiente global com a criao de mecanismos onde o conhecimento individual seja transformado em uma aprendizagem coletiva, em nvel coorporativo. 4. Gerncia de Conflitos: para resolver conflitos gerados principalmente em razo das diferenas culturais e da distncia fsica entre os atores participantes do projeto. Alm disso, nas outras nove reas de conhecimento do Modelo Processual do PMI (PMI, 2004a) descritas no item 5.2, o autor prope maior rigor nos processos devido s dificuldades inerentes a um ambiente de desenvolvimento fisicamente distribudo.

5.4 Modelo CMMI (Capability Maturity Model Integration)

O CMMI (SEI, 2002) est sendo considerado como um MGP por conter prticas da engenharia de software relacionadas com aspectos gerenciais, organizacionais e tcnicos. A execuo dessas prticas capacita as organizaes a atingir as metas de custo, cronograma e produtividade e portanto tem uma estreita ligao com o GP. Este modelo avalia a capacidade e a maturidade das organizaes desenvolvedoras de software e possui duas representaes: continuous e staged. Para melhoria de processo ou avaliaes as duas representaes oferecem resultados equivalentes. A representao staged permite uma fcil migrao do modelo Capability Maturity Model para software (SW-CMM) para o CMMI e tambm prov uma sequncia de passos progressivos e comprovados para melhoria do processo para a organizao em todas as suas reas e por estes fatores foi escolhido para este trabalho. O nvel staged composto por 5 nveis de Maturidade (SEI, 2002). Cada um destes nveis possui reas de processo que contm: objetivos especficos com as respectivas prticas especficas, e objetivos genricos com as respectivas prticas genricas. Os objetivos genricos so assim denominados, pois fazem parte de todas as reas de processo. Cada nvel serve de base para o prximo nvel e as organizaes no devem pular nveis. A seguir uma breve descrio de cada um dos nveis: Nvel 1-Inicial: Os processos neste tipo de organizao so normalmente ad hoc e caticos. O sucesso depende da competncia e herosmo das pessoas. Essas organizaes produzem produtos e servios que funcionam, mas excedem o oramento e o cronograma de seus projetos. Nvel 2-Gerenciado: Os projetos neste tipo de organizao tm seus requisitos gerenciados e seus processos planejados, executados, medidos e controlados. Neste nvel, os 65

requisitos, processos, produtos de trabalho e servios so gerenciados. O estado dos produtos visvel nos pontos definidos (marcos mais importantes) e os produtos e servios de trabalho satisfazem os requisitos, padres e objetivos especificados para eles. Nvel 3-Definido: A organizao que se enquadra neste nvel alcanou os objetivos das reas de processo assinaladas para os nveis 2 e 3. Os processos so bem caracterizados e definidos e so descritos em padres, procedimentos, ferramentas e mtodos. Um conjunto de processos padro estabelecido e melhorado sempre. As diferenas entre o nvel 2 e 3 so: delimitao dos padres, descries de processo e procedimentos. No nvel 2, cada instncia do processo possui procedimentos diferentes. No nvel 3, os procedimentos so iguais com exceo de diferenas permitidas para a organizao em questo. Processos so descritos em mais detalhe e mais rigorosamente no nvel 3. No nvel 3, os processos so gerenciados mais pr-ativamente usando os inter-relacionamentos das atividades do processo e medidas detalhadas do: processo, produtos e servios. Nvel 4-Quantitativamente Gerenciado: A organizao neste nvel alcanou os objetivos especficos das reas de processo assinaladas para os nveis 2, 3 e 4 e os objetivos genricos dos nveis 2 e 3. So estabelecidos processos para obter medies quantitativas. As medidas detalhadas de desempenho do processo so coletadas, estatisticamente analisadas e armazenadas no repositrio de medidas da organizao para dar suporte, futuramente, a decises baseadas em fatos. Diferenas entre o nvel 3 e 4: no nvel 4, o desempenho dos processos controlado usando tcnicas quantitativas e estatsticas. No nvel 3, os processos so previsveis qualitativamente. Nvel 5-Otimizado: A organizao que se encaixa neste nvel alcanou os objetivos especficos das reas de processo assinaladas para os nveis 2, 3, 4 e 5 e os objetivos genricos dos nveis 2 e 3. Os processos so continuamente melhorados com a compreenso quantitativa de causas comuns de variao. Para melhor compreenso de como o modelo est estruturado, apresenta-se a Figura 11 com o nvel 2-Gerenciado do modelo CMMI Staged.

66

Nvel de Maturidade 2

Gerenciamento de Requisitos

Planejamento de Projeto

Monitorao e Controle do Projeto

Gerenciamento de Contrato do Fornecedor

Medio e Anlise

Garantia da Qualidade do Processo e do Produto

Gerenciamento de Configurao

SG 1: Gerenciar Requisitos GG 2: Institucionalizar um Processo Gerenciado

SG 1: Estabelecer Estimativas SG 2: Desenvolver um Plano do Projeto SG 3: Obter Compromisso com o Plano GG 2: Institucionalizar um Processo Gerenciado

SG 1: Monitorar o Projeto utilizando o Plano SG 2: Gerenciar Ao Corretiva para Alinhamento GG 2: Institucionalizar um Processo Gerenciado

SG 1: Estabelecer Acordos com o Fornecedor SG 2: Satisfazer os Acordos com o Fornecedor GG 2: Institucionalizar um Processo Gerenciado

SG 1: Alinhar as Atividades de Medio e Anlise SG 2: Fornecer Resultados de Medio GG 2: Institucionalizar um Processo Gerenciado

SG 1: Objetivamente Avaliar Processos e Produtos SG 2: Fornecer Revelao Objetiva GG 2: Institucionalizar um Processo Gerenciado

SG 1: Estabelecer Linhas Base SG 2: Localizar e Controlar Mudanas SG 3: Estabelecer Integridade GG 2: Institucionalizar um Processo Gerenciado

Figura 11. CMMI Staged Nvel 2 (SEI, 2002).

67

5.5 MuNDDoS Modelo de Referncia para o DDS

O modelo MuNDDoS (Maturidade No Desenvolvimento Distribudo de Software) proposto por Prikladnicki (2003) para facilitar o DDS permitindo tambm a identificao de fraquezas e oportunidades de melhorias nos projetos. Sugere duas dimenses: organizacional e de projetos. A Figura 12 mostra o modelo de referncia proposto.

Figura 12. Modelo de Referncia Proposto (PRIKLADNICKI, 2003).

A composio dividida em trs partes: 1) planejamento estratgico; 2) planejamento ttico e operacional; e, 3) aprendizado. No planejamento estratgico busca-se uma viso estratgica realizada pela matriz que identifica e prioriza os projetos a serem desenvolvidos. O planejamento ttico-operacional realizado para definir quais as unidades distribudas que iro desenvolver cada projeto. No aprendizado so coletados dados para uma avaliao das atividades realizadas e estratgias adotadas. No planejamento estratgico so levados em conta para a alocao de projetos: restries de exportao das unidades que desenvolvero os componentes, privacidade dos

68

dados, propriedade intelectual, disponibilidade de ambiente fsico, restries de segurana e tipo de engagement1. Alm disso, sugere-se fazer a anlise do risco e custo-benefcio da distribuio considerando-se: nvel de documentao existente e grau de interao necessria com os atores para elaborar a documentao do projeto, clareza e estabilidade dos requisitos, riscos de tecnologia, experincia dos atores em projetos distribudos, capacidade de controle por parte da gerncia de projetos, complexidade e durao do trabalho e tamanho do projeto. O custobenefcio deve considerar critrios, tais como: o percentual de esforo necessrio pelas unidades fisicamente dispersas e a necessidade de RH junto do cliente e/ou usurio. O benefcio obtido comparando-se o custo de desenvolver de forma centralizada e distribuda. Um critrio a ser considerado o de overhead gerencial que poder existir com a distribuio. Finalmente, para a seleo da unidade que desenvolver o projeto, sugere-se quantificar um fator de risco para cada unidade existente considerando: capacidade e experincia da unidade em projetos similares, existncia de algum centro de competncia na tecnologia requerida, disponibilidade de RH, tempo necessrio para treinar novos colaboradores, espao fsico disponvel, fator de turn-over que avalia o risco de colaboradores sarem no meio do projeto, barreiras de idioma, barreiras de fuso-horrio e risco de concentrao de projetos. No planejamento ttico-operacional, o desenvolvimento de projetos envolve a identificao de fatores que podem dificultar o desenvolvimento. Os fatores esto divididos em cinco grupos. A seguir os grupos e os fatores que os compem: Organizao: (1) Coordenao e controle: dizem respeito forma como as equipes, artefatos e projetos so controlados; (2) Poder: pode interferir dependendo dos impactos dentro da organizao; e, (3) Polticas: so responsveis por definir a forma como os valores da organizao so mantidos. Processo de desenvolvimento: (1) Anlise e projeto: exigem foco na arquitetura e modularizao.; (2) Engenharia de requisitos: considerada uma rea chave para os projetos de DDS; (3) Qualidade de software: uma atividade essencial e deve manter os padres das equipes sempre de acordo com os da organizao; e, (4) Procedimentos e padres: devem ser mantidos apesar de presses que podem existir por parte dos stakeholders.

Tipo de engagement: este termo usado pelo autor para identificar qual o tipo de trabalho que se ter com o projeto (manuteno, novo projeto, alteraes e/ou melhorias em projetos existentes, suporte, entre outros) e se as unidades distribudas esto em condies de realizar este tipo de trabalho (PRIKLADNICKI, 2003).

69

Disperso: (1) Geogrfica: diz respeito distncia fsica entre os stakeholders principais e suas conseqncias para o desenvolvimento do projeto; e, (2) Temporal: caracterizada pelas diferenas de fuso-horrio existentes e suas conseqncias para o desenvolvimento do projeto; Stakeholders: (1) Capacitao; (2) Conhecimento e experincia. Os itens (1) e (2) so balizadores de algumas das dificuldades existentes; (3) Esprito de equipe; (4) Diferenas culturais; (5) Contexto; (6) Confiana; (7) Comunicao; (8) Idioma; e, (9) Relacionamento interpessoal. Projetos: (1) Complexidade; (2) Tipo; (3) Tamanho; (4) Infra-estrutura; (5) Tecnologia; (6) Gerncia de projeto: existncia de modelos para um efetivo GP; e, (7) Gerncia de risco. Faz parte do GP e sua influncia grande sobre o sucesso ou fracasso do projeto; e, (8) Engagement: considerado como marco do incio dos projetos de DDS, pois o momento onde as equipes so integradas e padronizaes e formas de trabalho nicas so incorporadas. Os itens (1), (2) e (3) so aspectos importantes do projeto; Os itens (4) e (5) podem ser um diferencial em projetos de DDS principalmente no que se diz respeito s tecnologias de colaborao como groupware. No aprendizado, realizado o processo de avaliao e feedback buscando a melhoria do processo de desenvolvimento. Nesta etapa so realizadas avaliaes: das estratgias adotadas, das alocaes dos projetos, do processo de desenvolvimento, do produto gerado. A avaliao e anlise das estratgias e processo adotado so muito importantes no DDS e deve contar com a participao de todos os envolvidos. Da consolidao das lies aprendidas eliminam-se as informaes irrelevantes e armazenam-se as relevantes. As trs partes que compem o modelo tambm fazem parte do modelo de capacidade proposto pelo autor que possui 4 estgios: Inicial, Bsico, Planejado e Otimizado. No inicial, existe o processo de captao de novos projetos. No bsico, existe o processo de novos projetos e o desenvolvimento de projetos. No planejado, existe o planejamento estratgico e o planejamento ttico-operacional e no estgio otimizado, o modelo por completo.

5.6 Comparao entre os Modelos de Gerncia de Projetos

O modelo processual do PMI (PMI, 2004a) possui as ferramentas e tcnicas que so um consenso para a gerncia de projetos e possui as informaes necessrias para se realizar o GP de uma forma genrica. As ferramentas e tcnicas so usadas para solucionar ou encaminhar cada um dos processos sugeridos. O gerente de projetos deve identificar qual 70

ferramenta ou tcnica dever ser utilizada. Em se tratando do DDS, este modelo apresenta alguns aspectos e tratamentos como mostra a Tabela 02.
Modelo Processual do PMI Integrao Escopo Tempo Custos Qualidade RH Levanta questes sobre a Distribuio Fsica? No trata especificamente No trata especificamente No trata especificamente No trata especificamente No trata especificamente Para o planejamento de RH: como entrada, tem-se os fatores ambientais da empresa nos quais devem ser levantados fatores interpessoais e logsticos. Os fatores interepessoais podem ser obtidos respondendo quais diferenas culturais ou de idioma afetaro as relaes de trabalho entre os membros da equipe. E, os fatores da parte logstica podem ser obtidos respondendo qual a distncia fsica que separa as pessoas e as unidades que faro parte do projeto e, se existem pessoas em diferentes prdios, fusos horrios ou pases. No item contratar ou mobilizar a equipe do projeto, o uso de equipes virtuais como ferramentas e tcnicas est descrito resumidamente. Apresenta as novas possibilidades criadas pela disponibilidade de comunicao eletrnica. Tambm faz uma observao de que o planejamento das comunicaes mais importante no caso do uso de equipes virtuais. No item reconhecimento e premiaes tambm deve-se considerar as diferenas culturais. Comunicao No item planejamento das comunicaes: como entrada, tem-se as restries includas no plano de GP e, deve-se considerar como restrio o fato de existirem membros da equipe em locais geogrficos diferentes. No item planejamento das comunicaes: em ferramentas e tcnicas, tem-se a tecnologia das comunicaes que conforme est descrito, pode ser afetado se a equipe se rene e opera com a presena fsica dos membros ou em um ambiente virtual. No item gerenciar as partes interessadas: como ferramentas tcnicas, e em mtodos de comunicao, quando no se justifica reunio com a presena fsica dos membros ou quando isto impraticvel (como em projetos internacionais), telefonemas, e-mails outras ferramentas eletrnicas so teis para trocar informaes estabelecer contatos. Riscos Aquisio No trata especificamente No item Planejar contrataes: como sada e em critrios de avaliao, para pontuar e classificar as propostas, a reivindicao do fornecedor por direitos de propriedade intelectual nos servios, processos de trabalho que utilizar ou produtos deve ser levada em conta. e a e e

Tabela 02. Aspectos relacionados distribuio fsica dos participantes do projeto no modelo processual do PMI (2004).

Ainda, no modelo processual do PMI (PMI, 2004a), no item entendimento do ambiente do projeto apresenta-se de forma resumida que deve haver o entendimento do: (1) ambiente cultural e social: procurando o entendimento de aspectos das caractersticas econmicas, demogrficas, educacionais, ticas, tnicas e religiosas e de outras caractersticas 71

das pessoas afetadas pelo projeto ou que tenham interesse no projeto. Tambm deve ser realizado um exame do ambiente organizacional para determinar se o GP reconhecido como uma funo vlida com responsabilidade e autoridade para gerenciar o projeto; (2) ambiente internacional e poltico: verificar a possvel necessidade de alguns membros da equipe estarem familiarizados com as leis e costumes internacionais, regionais e locais aplicveis, alm do clima poltico que poderia afetar o projeto. Outros fatores internacionais a serem considerados so as diferenas de fuso horrio, feriados nacionais e regionais, a necessidade de viagens para reunies com a presena fsica dos membros e a logstica de teleconferncia. A questo de como alcanar este entendimento, no foi apresentada. O CMMI (SEI, 2002) um modelo que permite a avaliao da capacidade e maturidade de organizaes que prestam servios de software e serve como um guia para que as organizaes alcancem os nveis gradativamente desde o nvel 1 at o nvel 5. Contm os objetivos e prticas para que a organizao consiga atingir cada nvel. Algumas prticas possuem ferramentas e tcnicas para exemplificar como se pode atingir o objetivo. Porm, na maioria das vezes no mostra como atingir esses objetivos. O MGP Baseado no PMI para ADDS elaborado por Zanoni (2002) um modelo que trata da distribuio fsica dos participantes do projeto, isso pode ser notado principalmente pela proposta de extenso das quatro gerncias. Porm, no apresenta os processos para cada uma dessas gerncias e est voltado ao DDS que utilize a UML e a UP. O Modelo MuNDDoS, tambm como o CMMI, est voltado avaliao das organizaes no DDS e serve como um guia para que as organizaes alcancem os seus nveis de maturidade e capacidade. Contm importantes elementos para a realizao da anlise estratgica e tambm para avaliao final do projeto. A Tabela 03 (ENAMI et al., 2006) mostra uma comparao entre os modelos de gerncia apresentados: o modelo processual do PMI (PMIa, 2000), o CMMI (SEI, 2002), o MGP Baseado no PMI para ADDS (ZANONI, 2002) e o Modelo MuNDDoS (PRIKLADNICKI, 2003). Os quatro modelos apresentados podem ser usados em projetos de qualquer porte. O modelo processual do PMI ainda mais genrico, pois pode ser utilizado para projetos de qualquer rea e, no somente de software. J o modelo CMMI e o MGP Baseado no PMI para ADDS apresentam caractersticas especficas da rea de desenvolvimento de software. Entretanto, nenhum dos quatro modelos atua especificamente no ADDS de maneira mais detalhada, conforme abordado no projeto DiSEN, o qual envolve a gerncia de projetos, inclusive com informaes para tomada de deciso. 72

Modelo Elementos Objetivos

Modelo Processual do PMI Apresentar as boas prticas em Gerncia de Projetos

CMMI

Proposto por Zanoni Apresentar uma viso de gerncia de projeto para um ambiente de desenvolvimento de software fisicamente distribudo 6 fases: Anlise de Requisitos, Projeto (Explorao e Definio), Produo, Avaliao (Desdobramento e Testes), Transio e Integrao Prope a utilizao das 9 gerncias do modelo processual do PMI e mais 4 gerncias: Planejamento, Propriedade Intelectual, Conhecimento e Conflitos Ciclo de vida em espiral, UML(Unified Modeling Language), e UP (Unified Process) Artefatos especificados em UML e UP

MuNDDoS

Avaliar a capacidade e maturidade das organizaes

Apresentar um modelo de referncia para o DDS

Componentes

Possui 9 Gerncias: 1. Integrao, 2. Escopo, 3. Tempo, 4. Custos, 5. Qualidade, 6. RH, 7. Comunica-es, 8. Riscos e 9. Aquisio. Possui 5 Grupos: 1. Iniciao, 2. Planejamento, 3. Execuo, 4. Monitoramento e controle e 5.Encerramento. As das 9 gerncias e os 5 grupos so constitudos pelos mesmos processos.

5 nveis: Inicial, Gerenciado, Definido, Quantitativamente Gerenciado e Otimizado Cada nvel possui reas de processo com objetivos especficos com prticas especficas e objetivos genricos com prticas genricas

3 ciclos: Planejamento Estratgico, Planejamento Ttico/Operacional e Aprendizado. 4 nveis: inicial, bsico, planejado, otimizado. Os 3 ciclos e os 4 nveis so compostos pelos mesmos processos.

Ferramentas, Tcnicas e Metodologias

Cada processo possui ferramentas e tcnicas que podem ser utilizadas

Em algumas prticas, so sugeridas ferramentas e tcnicas Cada rea de processo possui uma lista dos produtos a serem entregues

Sadas

Cada processo possui sadas. As sadas normalmente so entradas para outros processos

3 listas: projetos a serem desenvolvidos; projetos candidatos distribuio; e, projetos que podem ser distribudos Locais que podem desenvolver cada projeto Trabalho de Mestrado da PUC (Pontifcia Universidade Catlica) do Rio Grande do Sul Para projetos com DDS

Criado meio de:

por

Consenso da comunidade da rea de gerncia de projetos

Trabalho de Organizaes da Indstria, Governo e da SEI (Software Engineering Institute) Para projetos software de

Trabalho de Mestrado da PUC (Pontifcia Universidade Catlica) do Rio Grande do Sul

Alcance

Para todos os projetos

Para projetos de software que utilizem a UML e UP e nos quais exista distribuio fsica dos participantes

Tabela 03. Comparao entre os Modelos de Gerncia (ENAMI et al., 2006).

73

5.7 Consideraes Finais

Os MGPs apresentados tiveram destaque pois contm elementos que fazem parte do MGP proposto para o DiSEN. O Captulo 6 mostrar onde cada um deles pode ser usado. A comparao realizada entre os MGPs mostra de maneira geral quais os pontos fortes de cada um. Podemos concluir que os modelos no so exclusivos, desta forma, uma organizao pode fazer uso de todos eles para o desenvolvimento de projetos de software.

74

CAPTULO VI Modelo de Gerenciamento de Projeto Proposto 6.1 Introduo

Um ADDS possibilita a participao de equipes de alto desempenho para se desenvolver as tarefas de um projeto, pois pode-se busc-la em locais geograficamente dispersos, porm, existem obstculos como as diferenas culturais e a distncia geogrfica que devem ser devidamente tratados para que o saldo final seja positivo. Um MGP para um ADDS deve tratar de aspectos relacionados ao desenvolvimento de software com a formao de equipes virtuais. Estes aspectos incluem: planejamento de acordo com os objetivos da organizao, integrao das partes desenvolvidas, delimitao do escopo, estimativa do tempo, estimativa de custo, garantia de qualidade, garantia dos RH e materiais necessrios, fornecimento de meios de comunicao adequados, gerenciamento de riscos, contratao de servios ou produtos externos, gerenciamento dos stakeholders1, definio do processo de desenvolvimento de software, propriedade intelectual, resoluo de conflitos, criao de um ambiente de aprendizagem mtua e cultura organizacional. Ainda, dentro do contexto da gerncia de projetos, outro item importante a ser analisado para que um projeto alcance sucesso a seleo de projetos. O sucesso se inicia na seleo dos projetos que possuem maior probabilidade para alcan-lo. Uma anlise do portfolio de projetos leva a organizao a realizar os projetos certos e de forma correta. O portfolio de projetos est relacionado a uma rea que pode ser considerada parte como apresentado pela Project Management Institute em seu guia denominado Organizational Project Management Maturity Model (OPM3) (PMI, 2004b). importante fornecer as informaes necessrias aos gerentes do portfolio de projetos para que os mesmos possam avaliar os projetos em desenvolvimento e tomar as decises relativas priorizao, cancelamento ou suspenso dos projetos (FERREIRA, 2004). Em um ADDS cada stakeholder deve saber qual a autoridade-responsabilidade dentro do projeto para a qual se reportar ou cobrar decises. Para isso, o mapa de

Stakeholders=todos os interessados no projeto. Incluem os stakeholders primrios e secundrios. Nos primrios encontram-se: gerentes, clientes, usurios, fornecedores, sindicatos, acionistas, credores, funcionrios, rgos locais, estaduais e federais e nos secundrios qualquer um que acredite ter interesses ou direitos no projeto: famlia, mdia, instituies diversas, organizaes profissionais, turistas, comunidades locais, ambientalistas, concorrentes, organizaes polticas e sociais, etc. (CLELAND e IRELAND, 2002).

75

responsabilidade linear (MRL) deve ser divulgado para conhecimento de todos os participantes do projeto. Um bom canal de comunicao entre os participantes do projeto imprescindvel em um ADDS, pois as diferenas culturais e as distncias geogrficas tornam a comunicao mais difcil. O MGP proposto apresenta elementos a serem tratados em um ADDS para evitar ou minimizar os problemas advindos deste tipo de ambiente. Em projetos onde existe a distribuio fsica dos participantes, existem fatores extras que influenciam o andamento do projeto, tais como: diferenas nas organizaes dos grupos, diviso de responsabilidades da gerncia, dificuldade de liderana e motivao, diferenas culturais, diferenas de lngua, RH e materiais compartilhados e dificuldade de comunicao.

6.2 Premissas Para o Modelo Proposto

O modelo dever auxiliar os gerentes na execuo das funes de gerncia de projetos dentro de um ADDS e considera as seguintes premissas: O ambiente no qual estar integrado o DiSEN; O ciclo de vida do software considera a MDSODI; O modelo considera os trabalhos j realizados para o ambiente DiSEN, que possuem relao com gerncia de projetos, apresentados no Item 3.2; A integrao dos outros trabalhos no modelo poder ser vista por meio das janelas do prottipo e pela dissertao; No prottipo apresentado no Captulo 7, possvel identificar quais janelas fazem parte de cada um dos trabalhos realizados; A distribuio de dados entre as diversas instncias DiSEN ser realizada atravs do repositrio de dados, ficando transparente para os desenvolvedores, gerentes e outros interessados onde ocorrer a persistncia dos dados; A integrao de ferramentas externas ao DiSEN, ir depender da converso dos dados para a estrutura do DiSEN. Est sendo desenvolvido, paralelamente, um trabalho de mestrado em cincia da computao na Universidade Estadual de Maring para resolver a questo da interoperabilidade entre as ferramentas.

76

6.3 Composio do MGP Proposto

Para a composio do MGP, alm das premissas colocadas no item anterior, utilizam-se aspectos relevantes do modelo MuNDDoS (PRIKLADNICKI, 2003), do modelo processual do PMI(PMI, 2004a) e do CMMI (SEI, 2002), conforme pode ser observado na Figura 13. Os aspectos destacados so: (1) A utilizao das atividades do ciclo estratgico e de aprendizado do MuNDDoS (PRIKLADNICKI, 2003), onde tem-se: 1) Captao de projetos: so realizadas a identificao e a captao de novos projetos; 2) Anlise estratgica dos projetos: verifica-se a vantagem em desenvolver cada projeto para os negcios da organizao; 3) Anlise da viabilidade de distribuio do desenvolvimento de cada projeto: realiza-se a anlise de risco da distribuio e do custo-benefcio da distribuio; 4) Definio das unidades que desenvolvero cada projeto: so escolhidas as unidades que possuem melhores condies de desenvolver cada projeto; e 5) avaliao e feedback ao final do projeto. As atividades do ciclo estratgico so realizadas no planejamento estratgico do DDS e as atividades do ciclo de aprendizado no final dos projetos;

Figura 13. Utilizao de Outros Modelos.

(2) A utilizao do modelo processual do PMI (PMI, 2004a), com a consulta dos aspectos que podem prejudicar o projeto se no forem devidamente tratados em um ADDS. A ateno deve ser dada respondendo seguinte pergunta: Estes aspectos afetaro negativamente o projeto de alguma forma? Estes aspectos so: propriedade intelectual, diferenas culturais (lngua, idioma, feriados, forma de fazer negcio), distncia geogrfica (disperso entre usurios, clientes, fornecedores e equipe de desenvolvimento). (3) A utilizao do CMMI-Nvel 2 Staged (SEI, 2002) no que se refere ao alcance dos objetivos atravs das prticas e subprticas apresentadas no mesmo, pois apresenta uma viso mais detalhada e focada no desenvolvimento de software. Tambm para que uma organizao que faa uso do ambiente DiSEN possa de forma mais fcil atingir o nvel 2 do CMMI Staged. O estudo procurou identificar os objetivos ou prticas adequados ao ambiente DiSEN. 77

A partir desses elementos apresentado um esquema com os componentes do MGP proposto, na Figura 14. O MGP proposto trata os trs nveis organizacionais (estratgico, ttico e operacional) vinculando-os aos nveis gerenciais e operacionais estabelecidos para o ambiente DiSEN, a saber: gerente geral, gerente local, gerente de projetos e engenheiro de software.

Figura 14. Componentes do MGP proposto.

A Figura 14 mostra os usurios do MGP proposto nos diferentes nveis da organizao. No nvel estratgico, o gerente geral ir executar as atividades propostas por Prikladnicki (2003) relativas ao planejamento estratgico. No nvel ttico tem-se os gerentes locais que cuidam das unidades distribudas e os gerentes de projeto que cuidam dos projetos sob sua responsabilidade e, no nvel operacional tem-se os engenheiros de software que sero responsveis por executar as tarefas. Convm lembrar que a estrutura organizacional para os projetos flexvel possibilitando a troca de papis dentro de cada projeto. Por exemplo, um gerente de projeto pode ser um engenheiro de software em outro projeto. Um gerente local pode ser um gerente de projeto e, um gerente local pode ser o gerente geral. O MGP est mais focado no nvel ttico para dar apoio ao gerente de projeto na execuo de suas funes e permite o cadastramento, recuperao e armazenamento de informaes em um repositrio. Isso pode ser feito tambm com o uso de outras ferramentas caso seja possvel a interoperabilidade com outras ferramentas. O MGP tambm apresenta: (1) Orientao para minimizar os problemas advindos de diferenas culturais e disperso geogrfica; (2) Comunicao entre os 78

stakeholders; (3) Obteno do comprometimento dos stakeholders primrios; (4) Necessidade de transporte de artefatos entre os participantes do projeto; e, (5) Padronizao de documentos e procedimentos. Uma ferramenta de apoio ao GP um dos elementos do MGP que dar suporte aos itens (2), (3), (4) e (5). Os elementos que compem o MGP so: gerncia de stakeholders, gerncia do conhecimento, gerncia de riscos, gerncia de requisitos e uma ferramenta de apoio ao GP. A Figura 15 representa os elementos do MGP para um ADDS.

Figura 15. Elementos do MGP para um ADDS.

A seguir, uma descrio de cada um dos elementos.

6.3.1 Gerncia de Stakeholders

Os stakeholders do projeto so os interessados no projeto e podem ser categorizados em stakeholders primrios e stakeholders secundrios. Os stakeholders primrios so aqueles que tm uma obrigao contratual ou legal com a equipe do projeto e os stakeholders secundrios so os que normalmente no tm relao contratual formal alguma com a equipe

79

do projeto mas possuem algum interesse no projeto ou no resultado deste (CLELAND e IRELAND, 2002). Dentre os stakeholders primrios os mais comuns para a rea de desenvolvimento de sistemas so: gerentes, clientes, fornecedores e funcionrios e, dentre os stakeholders secundrios temos: famlias, mdia, organizaes profissionais, grupos de consumidores, concorrentes e organizaes no governamentais. O modelo para gerenciar os stakeholders de um projeto, desenvolvido por Cleland (CLELAND E IRELAND, 2002), envolve a identificao dos stakeholders, a coleta de informaes sobre eles incluindo a misso, a determinao dos pontos fortes e fracos dos stakeholders, a identificao da estratgia dos stakeholders, a previso do comportamento dos stakeholders e a implementao da estratgia de gerncias dos stakeholders. Os stakeholders primrios devem ser gerenciados pelo uso de: liderana, organizao, construo e manuteno de relacionamento, ambiente cultural adequado, fornecimento de recursos, fornecimento de treinamento, controle do progresso do projeto e verificao da eficincia e eficcia da equipe do projeto. J os stakeholders secundrios podem ser difceis de gerenciar por falta de autoridade ou influncia sobre eles. Para efetuar o gerenciamento dos stakeholders, membros da equipe, deve-se fornecer o devido treinamento e tambm para identificar a pessoa mais apta para executar cada atividade do projeto. Para isso, o gerente de projetos precisa conhecer os perfis dos usurios e as afinidades entre eles (LIMA, 2004). O perfil engloba a habilidade, o conhecimento e o treinamento que cada um possui. Um modelo de documento para apresentar os perfis da organizao est apresentado no Item 6.3.6 - Quadro 05. J as afinidades devem ser identificadas para aumentar a produtividade considerando-se que uma pessoa pode gostar mais de trabalhar com um membro da equipe do que com outro. Outro fator a ser considerado para que o gerente de projetos escolha quem ir executar cada atividade do projeto so as aptides de cada um (CURIONI, 2005). Um modelo de documento para o plano de gerenciamento de stakeholders est apresentado no Item 6.3.6 Quadro 04. Para o controle dos fornecedores, temos: documento com fornecedores candidatos, avaliao do fornecedor. Uma avaliao feita pelo cliente tambm importante e um documento deve fornecer o feedback para a equipe do projeto e a organizao. Os clientes devem ser constantemente informados sobre o andamento do projeto. importante que o gerente geral mantenha um bom relacionamento com os mesmos. Uma avaliao realizada pelos clientes tambm importante, pois, da satisfao do cliente depende 80

o surgimento de novos trabalhos, consolidando a organizao como produtora de software de qualidade. O modelo de documento apresentado no Item 6.3.6 Quadro 11 dever ser preenchido pelos clientes do projeto. Os fornecedores devem ser gerenciados por meio de contratos e pelo monitoramento e controle dos servios ou produtos que esto sendo desenvolvidos pelos mesmos. Inicialmente, no projeto, deve haver uma seleo dos melhores fornecedores de produtos e servios para a organizao pelo recebimento de propostas dos fornecedores. O modelo de documento para o recebimento de propostas de fornecedores do Item 6.3.6 Quadro 09 mostra informaes sumarizadas para que o gerente geral possa fazer a seleo. Uma avaliao dos fornecedores realizada pelos que mantm o contato com os mesmos e recebem os produtos indicada para que o gerente geral que poder estar em um local geograficamente distante possa ter informaes sobre a qualidade dos servios ou produtos prestados. O modelo de documento apresentado no Item 6.3.6 Quadro 10 dever ser preenchido pelos avaliadores. A seguir, no item 6.3.1.1, esto apresentados os usurios e as informaes necessrias para o GP em um ADDS.

6.3.1.1 Usurios e Informaes Necessrias para o DDS

Para que o GP seja realizado de forma eficiente e eficaz, necessrio produzir e deixar disponvel as informaes relevantes para que cada um dos tipos de usurios do projeto possa tomar as decises e realizar o seu trabalho. Dentre os tipos de usurios de um projeto de DDS, foram levantados (ENAMI et al., 2006): (a) os clientes que devem receber informaes sobre o projeto para acompanhamento; (b) os gerentes gerais que cuidam da parte contratual com os clientes, supervisionam os gerentes de projeto e precisam de informaes sobre contratos com os clientes, fornecedores, e de informaes sobre o andamento dos projetos da organizao para fazer a seleo dos projetos, avaliao e distribuio para as unidades geograficamente distribudas, definindo tambm quais projetos devem ser priorizados, cancelados ou suspensos dentro da organizao; (c) os gerentes locais que so os gerentes de cada unidade distribuda e que precisam de informaes para gerenciar os RH e materiais disponveis para a sua unidade determinando quais recursos da sua unidade esto disponveis para cada projeto, supervisionando os projetos alocados em sua unidade e se preocupando em motivar

81

as pessoas, pois, so os que mantm maior relacionamento face a face com os participantes do local; (d) os gerentes de projeto que necessitam de informaes para o planejamento e controle dos projetos sob sua responsabilidade; (e) os engenheiros de software que precisam de informaes sobre sua agenda para executar as atividades do projeto; Os clientes devem acompanhar o andamento do projeto e realizar avaliaes dos produtos desenvolvidos. Os clientes devem receber informaes sobre o cronograma do projeto, o contrato realizado com a organizao, as solicitaes de mudana nos requisitos. Os gerentes gerais so os responsveis pela anlise estratgica para o DDS e cuidam das atividades estratgicas e devem: gerenciar o relacionamento com parceiros de negcios, definir os gerentes locais, escolher os projetos que devero ser desenvolvidos em cada unidade fazendo uma anlise dos riscos estratgicos, estabelecer as polticas para resolver os conflitos entre os projetos da organizao, gerenciar os conflitos que podem ocorrer entre gerentes de projetos e/ou gerentes locais, definir os tipos de recursos e a quantidade de recursos necessrios para cada unidade e quais so os melhores fornecedores dos recursos materiais e servios, gerenciar os processos que compreendem fases, atividades e a seqncia das atividades, gerenciar as mtricas associadas ao processo, realizar avaliaes sobre os fornecedores e fornecer idias para melhoria do processo e do produto. O gerente geral tambm ser responsvel por informar os padres para realizao dos trabalhos na organizao. Os gerentes gerais precisam de informaes sobre o desempenho dos gerentes e informaes sobre a satisfao dos clientes, de informaes resumidas de todos os projetos da organizao: os que esto em andamento, os que ainda esto esperando para serem iniciados para que possam tomar decises de priorizao, suspenso ou cancelamento de um projeto. Eles devem obter informaes sobre a anlise econmica e financeira dos projetos e tambm informaes pessoais que iro fazer a diferena na tomada de deciso, pois, priorizar ou cancelar um projeto pode desmotivar a equipe de desenvolvimento. Isso ocorre quando um patrocinador pode possuir mais influncia que outro e levar realizao do projeto que est patrocinando em detrimento de outro. Os gerentes locais devem: gerenciar os RH e materiais existentes nos locais e quais recursos podero ser liberados a cada um dos projetos, supervisionar os projetos existentes em seu local, definir os gerentes de projeto do local, gerenciar os riscos preliminares que esto associados a no disponibilidade de recursos, auxiliar a superviso dos participantes de outros 82

projetos mas que esto no local de sua responsabilidade, gerenciar os conflitos entre os usurios de seu local, realizar avaliaes sobre os fornecedores e fornecer idias para melhoria do processo e do produto. Os gerentes de projeto devem: desenvolver as estimativas do projeto, escolher qual dentre os processos da organizao que melhor se adequa ao desenvolvimento do projeto, definir, se necessrio, quais outras atividades devem ser desenvolvidas no projeto alm das j definidas pelo processo, definir juntamente com o gerente geral quais mtricas alm das que j existem para o processo devem ser realizadas, definir quem dentre os participantes do projeto dever desenvolver cada atividade do projeto, gerenciar os conflitos que surgirem entre os membros da equipe, realizar avaliaes sobre os fornecedores e fornecer idias para melhoria do processo e do produto. Os gerentes de projeto, necessitam de informaes para o planejamento e controle do projeto. Estas informaes incluem: a EAP, o custo associado a cada atividade, o esforo necessrio para executar cada atividade, os RH, materiais e financeiros disponveis para o projeto, o tempo exigido pelo cliente ou pela administrao superior para concluir o projeto, quais os riscos envolvidos, quais os stakeholders do projeto. Para o controle, o gerente precisar saber: como est o desempenho dos desenvolvedores; se o cronograma real est de acordo com o planejado para tomar as aes corretivas, se necessrio; e, qual o estado do projeto, isto , se est em planejamento, em andamento, suspenso, cancelado ou concludo. Os engenheiros de software incluem os analistas de sistemas, os programadores, os tcnicos, entre outros e devem: gerenciar as tarefas sob sua responsabilidade, comunicar a situao das tarefas sob sua responsabilidade, realizar avaliaes sobre o projeto e fornecer idias para melhoria do processo e do produto. Eles precisam de informaes das tarefas que estaro sob a sua responsabilidade.

6.3.2 Gerncia do Conhecimento

As organizaes, na primeira dcada do sculo vinte e um, esto cada vez mais interessadas em identificar as melhores prticas no seu contexto social e econmico. A gerncia ou gerenciamento do conhecimento cobre processos e prticas intencionais e sistemticas para adquirir, capturar, compartilhar e usar conhecimento produtivo, onde quer que ela esteja para melhorar o conhecimento e o desempenho da organizao (SCARBROUGH, SWAN E PRESTON, 1999 apud FORAY e GAULT, 2003). Algumas prticas usadas para isso so: recompensar pelo compartilhamento do conhecimento e alocar pessoas para capturar conhecimento externo. 83

De acordo com Foray e Gault (2003), as organizaes sempre gerenciaram conhecimento, evitando a sada de pessoas capacitadas da organizao e fornecendo educao e treinamento para os membros da organizao. Mas, a necessidade de gerenciamento do conhecimento usado como uma estratgia sistemtica se torna cada vez mais urgente devido a trs razes que esto citadas abaixo. Primeiro, a transmisso de conhecimento entre o funcionrio mais antigo que possui o conhecimento para o funcionrio mais novo funciona parcialmente, pois o conhecimento transmitido parcial devido aos elementos tcitos. E, o conhecimento de um indivduo uma parte integrante do conhecimento da organizao. Novas formas para tratar o rodzio, mobilidade e flexibilidade so necessrias, ou pelo uso de mecanismos para proteger o conhecimento da organizao ou pela manuteno dos RH da organizao. Segundo, a necessidade de inovao como condio para a sobrevivncia fora a introduo de formas explcitas de gerenciamento do conhecimento. O custo de perder uma boa idia muito alto. preciso coletar e documentar idias e sugestes dos empregados e promover a criatividade. Terceiro, o mercado externo, a disseminao de tecnologia e o surgimento de novos mtodos torna necessrio processos explcitos de gerenciamento do conhecimento. importante manter o controle sobre o conhecimento da organizao. Percebe-se ento uma ligao com o gerenciamento da propriedade intelectual que faz parte do processo de gerenciamento do conhecimento e deve manter o conhecimento da organizao considerada secreta sob os devidos cuidados. Uma memria da organizao um fator crtico para inovao e aprendizado. Pode ser desenvolvido por meio de mtodos de documentao, codificao, armazenamento e pesquisa ou por meio da implementao de fortes redes de conhecimento entre pessoas (HANSEN et al., 1999 apud FORAY e GAULT, 2003) (STEINMUELLER apud FORAY e GAULT, 2003) buscando estar sempre a par do contexto em que a organizao est inserida. Tambm, redes externas de conhecimento devem ser mantidas com clientes, fornecedores, usurios, cincia e tecnologia (COCKBURN e HENDERSON, 1994 apud FORAY e GAULT, 2003) (HICKS, 1995 apud FORAY e GAULT, 2003). As razes pelas quais as organizaes procuram gerenciar o conhecimento so: Melhorar o uso do que j existe dentro e fora da organizao. No reinventar a roda, melhorar o compartilhamento da informao e a memria corporativa, avaliar as competncias para criar melhores prticas e capturar o conhecimento externo;

84

Resolver problemas de coordenao que surgem devido ao aumento da complexidade e modularidade de produtos e sistemas; Aumentar as oportunidades de inovao pela sinergia e transferncia; Transformar o conhecimento em valor monetrio pelo uso do gerenciamento de propriedade intelectual, licenciamento ou outros meios de transferncia; Atrair talentos. Existem duas formas usadas para manter o gerenciamento do conhecimento, que so: (1) Criar uma rede de contatos entre as pessoas promovendo a mobilidade e uma

cultura de interao bilateral. Esse mecanismo poderoso para capitalizar, transferir e compartilhar o conhecimento; (2) Transformar o conhecimento e armazen-lo em bancos de dados para que possam ser facilmente acessados e usados por qualquer pessoa da organizao, o que bastante til em casos onde os problemas que surgem so similares. O reuso do conhecimento evita o retrabalho e reduz custos de comunicao. As duas formas devem ser usadas no MGP proposto. Portanto, o conhecimento deve ser levado a todos os participantes para que possam realizar as suas atividades. Aps o encerramento do projeto, deve ser realizada uma anlise para disseminar o conhecimento adquirido para todos aqueles que fazem parte da organizao (PEREIRA et al., 2004) transformando o conhecimento individual ou setorial em conhecimento global (ZANONI, 2002). Deve-se incluir no repositrio os conhecimentos adquiridos que so relevantes para todos na organizao. Esta informao deve ser devidamente cadastrada em uma ferramenta de apoio ao GP pelo responsvel pelo armazenamento e a distribuio ser propagada a todos. Isso vai ao encontro do proposto por Prikladinicki (2003) no estgio de avaliao e feedback. Alm disso, como vimos no item 1 citado anteriormente, deve-se manter uma rede entre as pessoas para o compartilhamento de conhecimento e promover a criatividade e o surgimento de novas idias. Isso pode ser feito atravs de um bom sistema de recompensa. Um modelo de documento para que os participantes do projeto possam avali-lo e fornecer um feedback est apresentado no Item 6.3.6 Quadro 12. Dentro da gerncia de conhecimento, temos a preocupao com o repasse de conhecimento aos participantes dos projetos no incio de suas atividades. Alm disso, a gerncia do conhecimento est bastante ligada propriedade intelectual. Os itens 6.3.2.1 e 6.3.2.2 esclarecem estes dois temas. Apresenta-se a seguir, o item 6.3.2.1 que descreve uma

85

orientao onde sero passados conhecimentos para minimizar ou eliminar os problemas advindos das diferenas culturais e disperso geogrfica em ADDS.

6.3.2.1 Orientao para Minimizar ou Eliminar Problemas Advindos de Diferenas Culturais e Disperso Geogrfica em ADDS
Uma soluo encontrada para minimizar ou eliminar os problemas advindos das diferenas culturais fornecer uma orientao no incio do projeto com o objetivo de fazer com que os demais participantes da equipe localizados em um pas entendam melhor os outros participantes localizados em outro pas. O entendimento evita problemas de comunicao e tambm uma forma de solucionar os vrios problemas que podem ocorrer advindos das diferenas culturais apresentadas no Item 3.3. De acordo com Olson e Olson (2004) importante definir como o trabalho ser feito e para isso, necessrio criar um padro de trabalho. O velho ditado quando em Roma, faa como os romanos no pode ser aplicado no DDS, pois, onde Roma?. Este padro deve ser desenvolvido pela organizao e apresentado aos participantes da equipe. Isto tambm se aplica aos executivos da empresa, pois cada um possui uma viso diferente do projeto. importante fornecer uma linguagem comum entre todos os participantes do projeto (COREY et al., 2001). O MGP proposto refora a necessidade, de forma enftica, do estudo do ambiente cultural e social e do ambiente internacional e poltico para fornecer informaes aos membros das equipes nesta orientao que dar a sensibilidade necessria no tratamento com os outros membros dispersos geograficamente. Um formato padro para se efetuar a comunicao em reunies, vdeo-conferncia, udio-conferncia e e-mails dever orientar os participantes para eliminar ou minimizar os problemas com a comunicao. Os temas sugeridos para a orientao so: Cultura dos pases envolvidos; Responsabilidade e Autoridade dentro do projeto; Padro de comportamento esperado; Comunicao entre os membros da equipe. Conhecimento geral de GP, formao de equipe, relacionamento, normas, regulamentos, padres, propriedade intelectual, escritrio de projetos. Forma de realizar o trabalho (para os participantes como devero utilizar o ambiente, registrar mtricas). Todos os participantes do processo de coleta, armazenamento e recuperao das mtricas devem entender a importncia das mtricas. 86

6.3.2.2 Propriedade intelectual

Este tema foi abordado tambm por Zanoni (2002), que props uma gerncia de propriedade intelectual. Em um ambiente onde existem diversos atores, trabalhando em diversos pases fundamental que o gerente de projetos se preocupe com a questo dos direitos autorais e a propriedade intelectual de cada componente e parte da soluo que est sendo desenvolvida globalmente. O software que compreende o cdigo e a sua documentao uma criao intelectual que deve receber a tutela do ordenamento jurdico. Como a criao que deve ser protegida, trata-se de um bem imaterial cujo titular tem direito de propriedade sobre ela e portanto um direito de propriedade intelectual (LUPI, 1997). Os bens imateriais, frutos da criao intelectual tm alta relevncia econmica e a proteo jurdica visa garantir a criatividade, proteger e incentivar o trabalho intelectual criativo e salvaguardar os direitos do criador contra a explorao econmica. No Brasil, a propriedade intelectual pode ser garantida pelo direito autoral. O direito autoral garante a proteo uma vez lanada a obra e exteriorizada a idia. Ela no necessita de registro mas ele traz maiores garantias. Porm, o direito autoral no permanente, sendo vitalcio para o autor, pais, filhos e cnjuge e para os demais herdeiros dura at 60 anos. A cpia para fins de comentrios, crtica, pesquisa e didtica permitida mas, na Europa, a maioria dos pases reconhece o carter moral dos direitos autorais enquanto que nos EUA isso no ocorre. Para que haja proteo em outros pases necessrio que o pas em que ela buscada seja signatrio de uma conveno sobre o assunto e que preveja e efetive esses direitos. E, para que seja feita a defesa dos direitos autorais com penalizao, necessrio que sejam apresentadas provas de que o acusado teve acesso ao software para que seja possvel a condenao. Outro importante aspecto que se o software foi desenvolvido na empresa ele pertence ao empregador. Portanto, o acesso aos produtos desenvolvidos deve ser resguardado somente queles que necessitem dos mesmos para executar suas tarefas. Outro ramo da propriedade intelectual a propriedade industrial onde a proteo efetuada pela concesso de patentes e registro de marca entre outros. A patente garante o monoplio sobre a criao porm, no reconhecida sobre o software no Brasil. Ainda dentro da propriedade industrial tem-se o registro de marcas que protege os bens do comerciante distinguindo-os dos demais. Neste caso s existe a proteo ao ttulo do programa. 87

A concorrncia desleal pode ser usada quando existe a usurpao de clientela mas no existe muita utilidade devido pena branda. Os contratos so outra forma de manter a propriedade intelectual porm, tm eficcia somente entre as partes. O segredo de negcio usado para se proteger contra concorrentes que queiram descobrir ou adquirir a tecnologia. colocada uma clusula no contrato de trabalho dos empregados com acesso tecnologia. De novo, se algum quiser alegar violao contratual por descumprimento de segredo de negcio, precisa provar que a tecnologia e a informao no eram de conhecimento geral e que estavam sob o esforo para manuteno de segredo. A proteo jurdica varia de pas para pas, ainda, de acordo com Lupi (1997), em um quadro publicado na Internet, datado de 1996, dos 72 pases listados, 60 seguramente admitem proteo de software pelos direitos de autor e 19 aceitam tambm a proteo patenteria. Como as leis que regulamentam a propriedade intelectual so diferentes em cada pas e mudam at mesmo no mesmo pas, importante uma anlise das leis sobre a propriedade intelectual dos pases envolvidos na construo do software. Isso est de acordo com o proposto tambm por Karolak (1998 apud Prikladnicki 2003): levar em conta as leis e restries do local onde o projeto est sendo desenvolvido. Esta anlise deve ser realizada antecipadamente com a ajuda de uma assessoria jurdica devido s particularidades e detalhes que s os especialistas podem tratar. Essas informaes so importantes para que o gerente geral faa a avaliao estratgica para a distribuio dos projetos nos locais geograficamente dispersos e tambm defina os processos administrativos que sero necessrios para resguardar a propriedade intelectual do software ou componente desenvolvido. Como j concludo anteriormente, preciso manter um contrato com os fornecedores e clientes para resguardar a propriedade intelectual contra o cliente e fornecedor. Tambm necessrio formalizar o segredo de negcio e liberar o acesso do software ou partes dele somente s pessoas que precisem do mesmo para realizar suas tarefas. A questo da propriedade intelectual pode ser de difcil resoluo em se tratando de contratos entre organizaes privadas e universidades pblicas, onde a idia em si foi desenvolvida pela universidade que reivindica a propriedade intelectual e a execuo propriamente dita realizada pela organizao privada que contesta essa propriedade para poder comercializar o produto desenvolvido. A mesma situao pode ocorrer entre

88

organizaes desenvolvedoras do software ou partes do software e as organizaes contratantes.

6.3.3 Gerncia de Riscos

O risco em um projeto a probabilidade de que ocorra algum evento adverso que impacte negativamente as metas do projeto. Todo projeto possui algum risco e a incerteza contribui bastante para o risco do projeto. Quanto maior a incerteza, maior o risco do projeto. Calcula-se que um gerente de projetos trabalha com 40% a 80% das informaes necessrias durante a fase de planejamento na maioria dos projetos (CLELAND e IRELAND, 2002). Os riscos podem ser divididos em duas categorias: interno e externo. O risco interno inerente ao projeto e controlado pelo gerente de projeto que pode reduz-lo aplicando aes diretas como o desenvolvimento de planos de contingncia. Os planos de contingncia so as medidas necessrias que devem ser aplicadas caso o risco se concretize. J, os riscos externos encontram-se fora do controle dos gerentes de projeto e apesar da possibilidade de previso, o gerente de projetos no pode aplicar um plano de contingncia. Outro tipo de categorizao foi realizado por Karolak (1998 apud Prikladnicki et al., 2005) que divide os riscos em 3 categorias: organizacional, tcnico e comunicao. Se o risco estiver classificado em mais de uma categoria dever ser colocado no topo da lista de prioridades. A seguir uma breve descrio das categorias: Organizacional: envolve os papis e responsabilidades dos integrantes da equipes dos projetos (tarefas e limitaes associadas). Um exemplo seria o no entendimento de quem pode tomar certas decises; Tcnico: envolve mtodos e ferramentas para solucionar problemas tcnicos, tais como melhorar o desempenho do produto, desenvolvimento, arquitetura apropriada e impossibilidade de integrao entre mdulos; Comunicao: envolve a infra-estrutura que os integrantes das equipes utilizam para se comunicar. Exemplos: discusses mal interpretadas, idias mal formuladas, comunicao inadequada. Gerenciamento de risco um processo pr-ativo para tentar eliminar problemas potenciais ou incertezas no projeto antes que eles ocorram (BOEHM, 1991 apud PRIKLADNICKI et al., 2005). Um gerenciamento de riscos formal recomendado para gerenciar problemas complexos associados com projetos de desenvolvimento de software (KWAK e STODDARD, 2003 apud PRIKLADNICKI et al., 2005). Por meio de um estudo realizado, Prikladnicki 89

(2003) levantou as diferenas entre desenvolver um software de forma centralizada ou em um DDS e tambm identificou a gerncia de riscos como uma das formas de solucionar os problemas existentes em projetos com DDS. O gerenciamento dos riscos de um projeto envolve a identificao dos riscos, a quantificao dos riscos, a eliminao ou reduo dos riscos e um plano de contingncia (CLELAND e IRELAND, 2002). A identificao dos riscos para o desenvolvimento do projeto deve ser realizada no incio do projeto por meio da anlise: das interfaces do projeto e a dificuldade em alcan-la; da tecnologia necessria; novas foras de trabalho para realizar as atividades; disponibilidade de recursos materiais; custo para obter os materiais e RH necessrios; e, disponibilidade de fluxo de caixa. A quantificao dos riscos um meio de analisar a probabilidade de ocorrncia e a conseqncia de sua ocorrncia em termos de custo e tempo. Para facilitar a quantificao de cada risco, pode-se usar uma classificao por interseco como apresentado na Figura 16.
Probabilidade Muito alta (81 a 100%) Alta (61 a 80%) Moderada (41 a 60%) Baixa (21 a 40%) Muito Baixa (0 a 20%) Legenda: Verde: 1,2,3 Amarelo: 4,5,6 Vermelho: 7,8,9 Peso do risco em termos de custo ou tempo 5 4 3 2 1 6 5 4 3 2 7 6 5 4 3 8 7 6 5 4 9 8 7 6 5

Figura 16. Exemplo de Classificao de Riscos (CLELAND e IRELAND, 2002).

O gerenciamento de riscos realizado de acordo com o efeito sobre o projeto. A cor verde requer apenas o controle do risco para que no aumente. O amarelo indica a necessidade de monitorao ativa e reduo do risco se possvel e um aumento exigiria uma resposta. O vermelho indica ser necessrio algum tipo de ao para diminuir a ocorrncia do risco ou adotar uma nova abordagem. A eliminao ou reduo de riscos obtida com a mudana dos planos que poderia ser realizada com o aumento de RH ou materiais, contratao de uma organizao mais

90

qualificada para fazer parte do trabalho, reduo do escopo do trabalho ou o uso de uma tecnologia diferente. A gerncia de riscos deve ser considerada em nvel organizacional e de projeto avaliando-se as vantagens de um projeto ser desenvolvido de forma distribuda e os riscos envolvidos. E, ainda, os riscos da organizao que foram identificados devem ser repassados ao gerente do projeto para que sejam agregados aos riscos do projeto (PRIKLADNICKI, 2003). Como extenso do gerenciamento de riscos proposto por Prikladnicki (2003), necessrio verificar questes do ambiente poltico em que o software est sendo desenvolvido. A poltica do pas entre outras questes externas s unidades distribudas tambm deve ser avaliadas como anlise preliminar. Outros riscos a serem considerados podem ser: rotatividade de pessoal, mudana de gerenciamento, indisponibilidade de hardware, alterao nos requisitos, baixo desempenho de ferramentas CASE, mudanas na tecnologia e concorrncia com outro produto (SOMMERVILLE, 2003). O devido armazenamento dos riscos fornecer uma base de dados para a organizao que facilitar a identificao dos riscos e quantificao dos riscos. De acordo com o estudo de Prikladnicki (2005), muitos projetos apresentaram caractersticas parecidas com alguns riscos iguais. Para um efetivo GP, uma ferramenta de apoio deve permitir o cadastramento dos riscos e das caractersticas do projeto que podem afet-los e a emisso de relatrios gerenciais peridicos. As caractersticas podem ser obtidas pelas mtricas (quantidade de atividades, durao do projeto, etc.). Um modelo de documento para o plano de gerenciamento de riscos est apresentado no Item 6.3.6 Quadro 02.

6.3.4 Gerenciamento de Requisitos

Algumas observaes quanto aos requisitos foram encontradas em Jiludwig (2005) para entender o seu significado: 1) Os requisitos so necessidades ou desejos. Se o requisito no uma necessidade ou desejo, no mais um requisito; 2) Nem todos os requisitos so implementados. Depende da priorizao, pode-se deixar para implement-los futuramente; 3) Os requisitos podem ser classificados em: requisitos do usurio ou negcio e requisitos do sistema. Os requisitos do usurio so colocados sobre o ponto de vista do usurio e descrevem o que necessrio para que ele realize o trabalho. 91

Requisitos do sistema descrevem o que o sistema deve fornecer para satisfazer ou ajudar a satisfazer o requisito do usurio; 4) Os requisitos possuem um complemento que o categoriza. Pode ser um produto, processos manuais, atividades de projeto ou contrato. Se o requisito reportar mensalmente o progresso do projeto, o complemento gerenciamento do projeto; 5) O escopo do requisito determina seu nvel. Os requisitos que afetam o sistema todo so denominados padro da indstria, os requisitos que afetam todos os sistemas da organizao esto no nvel da empresa, os requisitos que afetam um sistema inteiro ou partes dele so requisitos do sistema e os requisitos que afetam somente um subsistema so requisitos do subsistema. O gerenciamento de requisitos envolve a identificao de inconsistncias entre os requisitos, o plano do projeto e os produtos desenvolvidos. Para que seja realizado, deve-se garantir que os requisitos tenham sido bem identificados, tomando-se o cuidado de obt-los com os melhores fornecedores de requisitos e que eles tenham sido bem entendidos. As mudanas de requisitos so normais e devem ser documentadas. Uma avaliao do impacto da mudana para o projeto deve determinar se o projeto deve absorver as mudanas e deve-se manter o rastreamento bi-direcional dos requisitos e identificar as inconsistncias entre os requisitos e o que est sendo desenvolvido (SEI, 2002). O rastreamento dos requisitos definido como a habilidade para descrever e seguir a vida do requisito, do incio ao fim e vice-versa (da sua origem, passando pelo seu desenvolvimento e especificao at a sua entrega e uso e tambm atravs dos perodos de refinamento e iterao de qualquer uma das fases) (GOTEL, 1995). Para realizar o rastreamento de requisitos pode-se: 1) manter uma matriz de rastreamento, o que seria bastante oneroso em termos de trabalho ou 2) usar uma ferramenta que proporcione uma matriz de rastreamento por meio dos artefatos criados. A consulta da matriz de rastreamento de requisitos garante que os requisitos foram alcanados e identifica o impacto da modificao de requisitos pela visualizao de quais componentes sofrero mudanas facilitando a determinao do custo, benefcio, cronograma e planejamento de testes. Nela, os requisitos esto ligados inicialmente aos objetivos de negcio. medida que so realizados refinamentos nos requisitos, a matriz de rastreamento de requisitos vai sendo atualizada. Uma forma de manter o controle pela manuteno de um cadastro de requisitos como no exemplo da Figura 17. 92

Identificador do Requisito R1 R10 R11 R12 R100

Tipo do Requisito Usurio Sistema Funcional Sistema Funcional Sistema Funcional Sistema NoFuncional

Descrio do Requisito Criao de controle de frias Cadastramento de frias Clculo de frias Emisso escala de frias Garantir tempo de execuo de 1 minuto no mximo

Requisito Gerado ou Posterior R10, R11, R12 R100 R100

Figura 17. Exemplo de Rastreamento de Requisitos.

A matriz pode fornecer as seguintes mtricas: estado de cada requisito e o nmero de mudanas. Uma reviso dos requisitos do projeto deve ser realizada para identificar inconsistncias em qualquer momento do projeto. Caso seja identificada qualquer inconsistncia, deve-se identificar a fonte da inconsistncia, condies em que ocorre e qual a justificativa para que a inconsistncia tenha ocorrido. Alguns modelos de documentos para se fazer o gerenciamento de requisitos foram desenvolvidos e esto apresentados no Item 6.3.6 no Quadro 06 - compromisso com os requisitos, Quadro 07 - solicitao de mudana nos requisitos e Quadro 08 - relatrio de inconsistncias dos requisitos.

6.3.5 Ferramenta de apoio ao GP

Para ser efetivo, um MGP para o DDS deve ter o suporte de uma ferramenta de apoio ao GP, portanto, deve fazer parte do mesmo. Uma ferramenta de apoio ao GP j foi identificada por Pedras (2003) como sendo um dos itens necessrios para dar suporte ao gerente de projetos na execuo de suas funes em um ADDS, pois, se no desenvolvimento de software existe a necessidade de se ter um gerenciamento com o uso de uma ferramenta de apoio, ela se torna ainda maior no DDS. sabido que, para melhorar o processo e consequentemente o produto, necessrio armazenar informaes sobre o que foi realizado no projeto para repetir o sucesso alcanado e para tirar as lies aprendidas e no cometer os mesmos erros novamente. Essa necessidade pode ser suprida por uma ferramenta de apoio ao GP que fornecer o devido armazenamento e recuperao das informaes. O uso de uma ferramenta de apoio ao GP auxilia todo o processo de GP armazenando dados do planejamento e os dados reais obtidos quando da execuo do projeto e tambm possibilitar um padro no cadastramento, armazenamento, e obteno de informaes. A padronizao importante em um ADDS, pois todos os membros da organizao que faro 93

uso da ferramenta tero uma forma nica para lidar com as informaes, evitando problemas de comunicao e conflitos. Dentre as solues encontradas por Prikladnicki (2003) para as dificuldades do DDS podemos citar: a definio de padres, a gerncia de riscos, a avaliao constante da produtividade das equipes e a documentao das atividades e dos problemas. Para todas estas solues, e tambm para manter um controle sobre os stakeholders e possibilitar a distribuio do conhecimento, uma ferramenta de apoio ao GP de grande valia. Desta forma, o gerente de projetos em um ADDS certamente necessitar de uma ferramenta de apoio para executar as suas funes, dando suporte para a realizao das atividades: de estimativas de custo, esforo e durao do projeto de software; de definio das atividades; do planejamento como um todo; e, do controle do projeto. Alm disso, no DDS, uma ferramenta deve possibilitar a utilizao de processos de desenvolvimento de software, armazenamento do conhecimento adquirido no projeto, cadastramento e controle dos riscos do projeto, cadastramento de mtricas para utilizao posterior, acesso das informaes do projeto somente s pessoas que participam do projeto, controle de fornecedores e clientes e, o cadastramento de informaes pessoais que podem ajudar a evitar os problemas das diferenas culturais. Portanto, em um ADDS, uma ferramenta de apoio ao GP se faz necessria para dar suporte s atividades gerenciais da organizao permitindo o cadastro para o planejamento e controle das informaes em um ADDS. O GP da organizao deve englobar todos os aspectos considerados neste trabalho, e em um ADDS, o GP automatizado ser um subconjunto do gerenciamento de projeto da organizao, e, a ferramenta servir como um apoio s atividades gerenciais, pois, existem questes puramente gerenciais, tais como: estrutura organizacional, informaes a serem cadastradas, criao de um ambiente organizacional adequado, que esto fora do escopo da ferramenta. Como exemplo temos que para o DiSEN, existe a ferramenta DIMANAGER (PEDRAS, 2003) como apresentado na Figura 18.

94

Figura 18. Relao Entre uma Ferramenta de Apoio ao GP e o GP da Organizao.

Os itens 6.3.5.1 e 6.3.5.2 que dizem respeito s mtricas e estimativas para o GP tambm so contemplados pela ferramenta de GP.

6.3.5.1 Mtricas do MGP Proposto

Para que haja o devido monitoramento e controle do projeto, torna-se necessrio que sejam utilizadas mtricas que forneam informaes sobre o estado do projeto e uma visibilidade do projeto (THAYER, 1997). importante lembrar que a medio deve apresentar dados aos tomadores de deciso para que entendam o contexto e tomem decises objetivas. Devido dinmica dos projetos necessrio que as mtricas estejam disponveis todo o tempo e tenham seu histrico mantido. Para tornar isso possvel, na prtica, necessrio que elas sejam mantidas on-line por uma ferramenta automatizada (ROYCE, 1998). Para um ADDS, a pesquisa de Smite (2004) mostra o interesse em medir a quantidade de comunicao realizada pelas diversas ferramentas (e-mail, voice-mail, grupos de discusso on-line, telefone, conferncias de udio, vdeo conferencias, encontros pessoais) so utilizadas em um ADDS. A classificao das mtricas permite uma melhor visualizao do escopo de sua utilizao e na busca por mtricas adequadas ao DiSEN, encontramos uma variedade de mtricas e uma srie de classificaes. Fica evidente dentro de um ADDS a necessidade de fornecer medidas para apoiar o GP. Foram, ento, sugeridas algumas mtricas encontradas na literatura considerando as caractersticas de uma boa mtrica que de acordo com Royce (1998) so: 1) So consideradas importantes para todos que participam do processo de coleta, armazenamento e recuperao; 95

2) Esto alinhadas com os negcios da organizao; 3) objetiva e no possui ambigidades; 4) Apresenta tendncias para aqueles de possuem a autoridade para interpretar e decidir que ao tomar; 5) obtida facilmente pelo produto ou processo sem a necessidade de introduo de novos artefatos ou atividades no processo; 6) Possui suporte automatizado. As mtricas consideradas adequadas ao ADDS e apresentadas no MGP so divididas em trs tipos: relacionadas ao software, relacionadas aos RH, relacionadas ao processo e relacionadas ao projeto. Assim, temos: Relacionadas ao software: 1) Pontos por Funo: para cada parte do software implementado e para o software como um todo; Em alguns projetos, para estimar, o gerente de projeto poder fazer um controle de maior nvel, estimando somente as atividades maiores. Com o armazenamento das mtricas pode-se ter uma anlise futura de qual gerente de projetos possui maior habilidade em estimar melhor um projeto. 2) Qualidade: a medio da qualidade pode se referir ao software produzido onde haver a medio da: confiana no software, a portabilidade, a facilidade de manuteno. Tambm a qualidade do processo utilizado para desenvolver o software pode ser medida em termos de adaptabilidade ao processo, facilidade de utilizao, etc. Relacionadas aos RH: 1) Produtividade: o esforo-hora que foi necessrio para executar cada tarefa de desenvolvimento. O armazenamento de informaes sobre a tarefa (local onde foi executada, fase do processo a que pertence) permitir a obteno de informaes sobre a produtividade por grupo (participantes do local) e por fase do processo. 2) Rodzio de participantes do projeto: essa medida obtida pela anlise da variao dos RH associados ao projeto. 3) O tempo que um participante fica ocioso quando alocado para um projeto; 4) O tempo que um participante aguarda recursos ou artefatos necessrios execuo da mesma; Relacionadas ao processo: 1) Facilidade de utilizao do processo: medida subjetiva sobre o que se sente com relao ao processo. fcil de ser utilizado? Relacionado ao projeto: 96

1) Ocorrncias do projeto: com o armazenamento das ocorrncias do projeto podemos calcular o nmero de ocorrncias negativas dentro do projeto. 2) Volatilidade dos requisitos: a medida da quantidade de requisitos modificados no decorrer do projeto tem grande impacto nos custos do projeto. normal termos mudanas nos requisitos medida que o projeto progride mas devemos ter um controle para justificarmos a diferena nos custos. O gerente de projetos pode incluir o valor de mudana de requisitos por fase do projeto (NITTA, 2005). O gerente de projeto deve ter um relatrio que indique possveis erros em digitaes e deve estar sempre atento, verificando se o valor cadastrado est condizente com o trabalho do projeto. Quando houver atividades que existem somente devido alterao nos requisitos, isso deve tambm ser informado. importante um armazenamento que fornea a diferena entre o estimado/planejado e o real de cada uma das mtricas e tambm outras informaes que incluem: nome, objetivo, justificativa, unidade de medida, forma de anlise e aes a serem tomadas, interessados, (quem, quando, como, qual a freqncia) de coleta, armazenamento e recuperao. O armazenamento dessas informaes possibilita que os participantes geograficamente distribudos conheam o processo de medio e a sua importncia. Tambm com relao s ocorrncias do projeto, importante armazenar: o tipo de ocorrncia (tcnica, organizacional) (PEDRAS, 2003), a soluo dada ao problema ocorrido, a data e hora que ocorreu o problema e a data e hora de resoluo do problema. Com essas informaes possvel manter um histrico com as solues encontradas para os problemas do projeto facilitando assim o trabalho do gerente de projeto. O gerente de projetos pode desejar saber quais atividades foram desenvolvidas por cada participante dentro do projeto. Por isso importante o registro de todas as atividades realizadas por participante e geral para o projeto. Uma outra forma de obter essa informao confrontar o que foi feito anteriormente com a verso mais nova (MENS e DEMEYER, 2001). Podemos obter vrias mtricas como: o nmero de artefatos criados/modificados por perodo, o nmero de arquivos criados/modificados por perodo ou classes

criadas/modificadas por perodo. Como visto anteriormente no Item 3.2.4, as mtricas esto intimamente ligadas s estimativas pois elas permitem o entendimento do processo e facilitam a estimativa. Alm disso, so imprescindveis para melhoria do processo e do software.

97

O modelo de documento plano de gerenciamento de dados do Item 6.3.6 Quadro 03, til para explicar como as mtricas sero armazenadas, recuperadas, reproduzidas e distribudas e quem ir realizar estas atividades.

6.3.5.2 Estimativas do MGP Proposto

Uma das maiores dificuldades para o gerente de projetos de software realizar as estimativas de tempo e custo pela quantidade de variveis humanas, tcnicas, ambientais e polticas envolvidas. As estimativas de tempo e custo nunca sero uma cincia exata, entretanto, elas podem ser realizadas em passos sistemticos que oferecem riscos aceitveis (PRESSMAN, 1995). Quanto menos viso se tem do escopo do projeto, maior ser o risco envolvido nas estimativas de custo e tempo, pois o escopo determina o tempo e o custo do projeto. As mtricas, vistas anteriormente serviro como uma base para se realizar as estimativas pois possuem valores do esforo-hora real das tarefas do projeto. Podemos ento obter o custo da tarefa pelo clculo do custo do participante por hora e do custo por hora de uso dos recursos utilizados para executar a tarefa. Porm, como o esforo-hora varia de pessoa para pessoa, a estimativa deve ser realizada com a consulta s pessoas que realizaro as tarefas. Muitas vezes, isso no possvel pois a seleo da pessoa para realizar a tarefa ainda no foi feita, ento, a nica soluo definir o perodo para iniciar a tarefa mais cedo, o perodo mdio para iniciar a tarefa e o perodo para iniciar a tarefa mais tarde e definir o esforo-hora mdio para executar a atividade pela soma das horas do perodo. Para a realizao das estimativas, o treinamento, viagens e comunicao devem ser levados em conta pois so fatores que exercem impacto sobre as estimativas em um DDS. Este impacto varia conforme o nvel de disperso entre as unidades envolvidas sendo que, quanto maior o nvel de disperso, maior o custo relacionado. Os treinamentos, as viagens inevitveis realizadas para o devido acompanhamento do projeto e a comunicao por meio da utilizao de ferramentas traro custos adicionais para o DDS. De acordo com Pressman (1995), existem vrias ferramentas que permitem a realizao de estimativas e importante que o gerente de projetos realize pelo menos trs estimativas diferentes para ter uma garantia maior de que a estimativa est correta. Podem ser usadas a estimativa de pontos por funo, de esforo humano e o Constructive Cost Model (COCOMO) (PRESSMAN, 1995). Por existirem ferramentas que do suporte estimativa tempo e custo ao gerente de projetos, interessante a sua utilizao e a sua integrao com o MGP proposto permitindo a interoperabilidade com elas. 98

6.3.6 Modelos de Documentos

Estes modelos de documentos devem ser utilizados no processo de GP. Devem ser devidamente armazenados pois contm os compromissos da equipe do projeto e dos clientes com relao ao projeto. O principal documento relativo gerncia de projetos o plano do projeto e importante a participao das partes interessadas no desenvolvimento do mesmo pois, ser o plano de todos. As informaes contidas no plano apresentado no Quadro 01 foram

baseadas no plano de projeto de software apresentado por Pressman (1995).

Quadro 01. Plano do Projeto.
Empresa ABC Plano do Projeto P I. Introduo 1. Escopo e propsito do documento 2. Objetivos do projeto a. Objetivos b. Funes principais c. Questes de desempenho d. Restries tcnicas e administrativas 3. Definies e Acrnimos II. Organizao do projeto 1. Limites e Interfaces da Organizao 2. Estrutura Organizacional para o projeto 3. Mapa de Responsabilidade Linear (MRL) III. Estimativas de projeto 1. Dados histricos usados nas estimativas 2. Tcnicas de estimativa 3. Estimativas IV. Plano de Gerenciamento de Riscos V. Cronograma e Oramento 1. WBS com todas as tarefas do projeto (suporte, treinamento, documentao, gerenciamento de configurao, garantia de qualidade, tarefas que podero ter reuso de componentes, aquisio de bens e servios, integrao, instalao, monitoramento e controle de riscos, monitoramento e controle da qualidade, monitoramento e controle de stakeholders) 2. Grfico de timeline (Grfico de Gantt) 3. Definio dos RH e materiais necessrios para cada uma das tarefas 4. Definio dos custos relacionados a cada uma das atividades e materiais utilizados VI. Recursos do projeto 1. Pessoal - Qtde de cada Habilidade/Treinamento/Conhecimento Necessrios 2. Hardware e software - Qtde de cada tipo de Material Necessrio 3. Recursos especiais - Qtde de cada tipo de Recurso Especial VII. Mecanismos de rastreamento e controle 1. Relatrios a serem entregues e destinatrios VIII. Apndices

O plano de projeto deve conter: (a) A estrutura de diviso de trabalho com a descrio de todas as atividades do projeto, incluindo: as atividades referentes documentao do projeto que ir fazer 99

parte do help do software e, as atividades de GP que devem ser explicitamente colocadas pois consomem at 25% do oramento total do projeto (COREY et al., 2001); (b) O cronograma do projeto com o tempo, o responsvel e o custo de cada atividade; (c) O plano para gerenciamento dos riscos. Em um projeto realmente grande, o plano deve estabelecer procedimentos para lidar com as situaes difceis, pois elas certamente ocorrero ao longo dos meses em que o projeto estar em execuo (COREY et al., 2001). Por isso, necessrio fazer um planejamento dos riscos no qual teremos um plano de contingncia para cada um deles caso ocorram; (d) Os produtos a serem entregues, relatrios semanais e reunies (COREY et al., 2001); (e) O plano de entrega/instalao do software que, dependendo do contrato, poder envolver atividades para a instalao de um conjunto de softwares bsicos necessrios para que o software desenvolvido seja instalado e executado com boa performance. Alm disso, so necessrias atividades de treinamento do usurio e de instalao do banco de dados.

O Plano de Gerenciamento de Riscos faz parte do Plano do Projeto e est apresentado no Quadro 02. Este plano foi baseado nas informaes necessrias para o devido gerenciamento de riscos apresentado por Cleland e Ireland (2002), no qual, necessrio a identificao dos riscos, a quantificao dos riscos, a eliminao ou reduo dos riscos e o planejamento de contingncia de cada risco.
Quadro 02. Plano de Gerenciamento de Riscos.
Empresa: ABC Plano de Gerenciamento de Riscos Projeto: Data Inicio: Descrio do Risco Probabilidade de ocorrer Conseqncia Custo e Tempo Plano de contingncia

Para os dados mais importantes ou sigilosos que no tem uma definio de responsabilidade/autoridade bem definida, para evitar confuses, um Plano de Gerenciamento de Dados bem til para se mostrar o devido cuidado que se deve ter com relao a eles. Manter as informaes apresentadas no Quadro 03 est em conformidade com o estabelecido no CMMI Staged-Nvel 2. Os dados contidos neste plano, podem ser as mtricas para o GP. 100

Quadro 03. Plano de Gerenciamento de Dados.

Empresa: ABC Plano de Gerenciamento de Dados Dados/Informaes: a) Quem e Quando Armazenar b) Quem e Quando Recuperar c) Quem e Quando Reproduzir d) Quem e Quando Distribuir

O Plano de Gerenciamento de Stakeholders apresentado no Quando 04 importante nos casos onde eles podem impactar o projeto exercendo qualquer tipo de influncia nos resultados do projeto. Alguns projetos foram comprometidos por ambientalistas que atrasaram a elaborao e construo de usinas nucleares e comunidades que impediram a construo de rodovias para preservar patrimnios histricos, entre outros. Nos projetos de software, podemos ter um ambiente no favorvel implantao do software, por exemplo quando este software trar conseqncias de demisso de funcionrios. Para um ADDS deve-se formalizar a questo do gerenciamento de stakeholders que deve focar principalmente os stakeholders da organizao na qual se pretende instalar o software. O gerenciamento deve ser iniciado o mais cedo possvel para evitar barreiras de implantao e utilizao do software.
Quadro 04. Plano de Gerenciamento de Stakeholders.
Empresa: ABC Plano de Gerenciamento de Stakeholders Projeto: Data Incio: Nome Responsvel: Stakeholder Objetivo Interesse no Projeto Quando Contatar Por que contatar

Para fornecer o treinamento que a organizao necessita, preciso conhecer o perfil dos usurios dentro da organizao. Para isso, necessrio que se mantenha um controle sobre os perfis (conhecimentos, habilidades e treinamentos) j existentes dentro da organizao. Uma viso resumida como apresentada no Quadro 05. J a necessidade de documentos para realizar o gerenciamento de requisitos foi identificada e apresentada no MGP para realizar as prticas e subprticas sugeridas pelo CMMI Staged Nvel 2. Os modelos de documentos necessrios para o gerenciamento de requisitos so: compromisso com os requisitos, solicitao de mudana nos requisitos e inconsistncias nos requisitos. 101

Quadro 05. Habilidades/Conhecimentos/Treinamentos dos Membros da Organizao.

Empresa ABC Habilidades/Conhecimentos/Treinamentos dos Membros da Organizao

Habilidades: Descrio da Habilidade Conhecimentos: Descrio do Conhecimento Treinamentos: Descrio do Treinamento

Nvel Nvel Nvel

Qtde de Membros que Possui em Cada Local Qtde de Membros que Possui em Cada Local Qtde de Membros que Possui em Cada Local

Para entender os requisitos, um documento como o do Quadro 06 necessrio. As informaes neste documento compreendem uma lista dos requisitos, seus fornecedores e o tipo do fornecedor de requisito que pode ser o usurio ou o cliente. Deve-se tomar o cuidado para identificar os melhores fornecedores de requisitos. Uma avaliao do fornecedor do requisito deve ser realizada para verificar se ele est em condies de fornecer o requisito (possui experincia necessria, conhece o domnio do requisito envolvido) e, depois, caso o fornecedor seja aprovado, o requisito verificado na sua completude e entendimento. A concordncia dos Stakeholders, principalmente dos clientes e ,do responsvel pela obteno dos requisitos fornecer o compromisso ou responsabilidade sobre os requisitos.
Quadro 06. Documento de Compromisso com os Requisitos.
Empresa: ABC Compromisso com os Requisitos ou DRS (Documento de Requisito de Software) Projeto: Cliente: Nome do Fornecedor do Requisito, Tipo do Fornecedor do Requisito, Avaliao do Fornecedor do Requisito (Aprovado ou No), Requisito, Avaliao do Requisito (Completo, Incompleto), Concordncia dos Stakeholders Local, data e hora Assinatura dos Stakeholders: Glossrio em anexo

Quando houver alterao nos requisitos deve-se refazer o Documento de Compromisso com os Requisitos para mant-lo completo e atualizado. O documento completo deve ser revisado pois um requisito pode alterar outro (Ex.: se tivermos 2 requisitos, cadastramento de fornecedores, e emisso de relao de fornecedores e se o primeiro for eliminado ou tiver seus atributos alterados, o segundo tambm dever ser eliminado ou 102

alterado). Para manter o documento atualizado, pode-se utilizar uma matriz de rastreamento de requisitos deve ser criada para manter o estado dos requisitos, e armazenar um histrico de mudanas de requisitos juntamente com a justificativa para as mudanas e o impacto das mudanas.
Quadro 07. Documento para Solicitao de Mudana nos Requisitos.
Empresa: ABC Documento para Solicitao de Mudana nos Requisitos Projeto: Cliente: Data Solicitao: Hora Solicitao: Tipo de Fornecedor Requisito

Fornecedor da Mudana nos Requisitos Assinatura do Cliente: Data Recebimento da Solicitao:

Hora Recebimento da Solicitao:

O documento para solicitao de mudana nos requisitos, como mostra o Quadro 07, ser usado quando o cliente quiser fazer uma alterao ou incluso de um requisito. Quando do recebimento do documento pela organizao, deve-se preencher a data e hora do recebimento para que a alterao seja devidamente cadastrada no repositrio. Nos marcos determinados pelo processo utilizado, ser realizada a verificao de inconsistncias nos requisitos para monitorar e controlar os requisitos e caso seja identificada alguma inconsistncia, isso dever ser registrado no modelo de documento apresentado no Quadro 08. Isso feito pelo confronto dos mesmos com os produtos desenvolvidos.
Quadro 08. Relatrio de Inconsistncias dos Requisitos.
Empresa: ABC Relatrio de Inconsistncias dos Requisitos Projeto: Identificador Requisito Descrio Qual a condio para ocorrer Justificativa

Quando houver a necessidade de aquisio de recursos materiais ou servios, o modelo de documento com os fornecedores candidatos deve ser preenchido e apresentado com as informaes resumidas sobre as vantagens e desvantagens de cada um (melhor custo, prazo, servio) para que o gerente geral possa fazer uma anlise de qual fornecedor mais vantajoso para a organizao em termos estratgicos. 103

Quadro 09. Documento para Recebimento de Propostas de Fornecedores.

Empresa: ABC Documento para Recebimento de Propostas de Fornecedores Produto a ser adquirido: Qtde: Fornecedor: Nome Tipo de Fornecimento Vantagens/Desvantagens

Uma avaliao dos produtos recebidos ser realizada pelo gerente local, usando o modelo do Quadro 10. O gerente local e o gerente de projeto podero realizar uma avaliao mais confivel por manter contato com o fornecedor e por estarem a par dos problemas ocorridos no fornecimento de recursos materiais e servios.
Quadro 10. Avaliao dos Produtos Recebidos

Empresa ABC
Avaliao dos Produtos Recebidos Fornecedor: Produto: Itens a serem Avaliados

Data: Pontuao (1-Ruim a 10-Excelente)

Outra avaliao realizada pelos clientes poder ser realizada pelos membros da organizao contratante para obter dados da satisfao do cliente com relao aos produtos e servios fornecidos que podem ser: treinamentos, software, artefatos, instalao, etc. O modelo a ser usado o do Quadro 11.
Quadro 11. Avaliao da Organizao
Empresa ABC Avaliao dos Produtos e Servios Fornecidos Avaliao realizada pelo Cliente C Produto: Itens a serem Avaliados Data: Pontuao (1-Ruim a 10-Excelente)

Uma avaliao realizada pelos participantes do projeto, utilizando o modelo do Quadro 121, trar um feedback para que toda a organizao possa ganhar conhecimento e

Baseado no relatrio de lies aprendidas de Kathy Schwalbe (http://www.augsburg.edu/ppages/~schwalbe/).

104

melhorar a qualidade do processo e do produto fazendo com que o aprendizado individual se torne coletivo em nvel corporativo.
Quadro 12. Relatrio de Lies Aprendidas.
Empresa ABC Relatrio de Lies Aprendidas Nome: Funo: Projeto:

Data:

1.

O projeto terminou dentro do escopo, tempo e prazo pr-definidos?

2.

Descreva as principais questes positivas do projeto.

3.

Descreva as principais questes negativas no projeto.

4.

O que voc faria diferente no prximo projeto aps a experincia de ter participado deste projeto?

6.4 Funes de Gerncia de Projetos no MGP Proposto

O MGP proposto dever auxiliar o gerente a executar as funes de planejamento, organizao, motivao, direo e controle. Com relao ao planejamento e controle, o MGP proposto fornece modelos de planos a serem desenvolvidos e prope a utilizao dos processos de planejamento e monitorao e controle do modelo processual do PMI (PMI, 2004a). Para executar a funo de organizao a empresa/instituio dever fornecer uma estrutura organizacional para a execuo do projeto. A motivao entendida como uma hierarquia de necessidades e, portanto, o gerente deve compreender qual a motivao de cada membro da equipe para trazer tona o melhor de cada um. A funo de direo executada determinando-se as autoridades-responsabilidades dentro da organizao definindo: quem far o que dentro do projeto. Isso permite tambm a liderana correta, evita omisses e previne recriminaes.

105

6.4.1 Planejamento e Controle

O planejamento e controle ser realizado com o apoio de uma ferramenta como a DIMANAGER (PEDRAS, 2003). No planejamento, o gerente de projeto deve desenvolver o plano do projeto (Ver Quadro 01), que um documento que dever ser apresentado a vrios tipos de usurios e deve comunicar o escopo e os recursos para a administrao, equipe tcnica e cliente (PRESSMAN, 2001). Este documento deve estabelecer a viabilidade do esforo de desenvolvimento e se concentra na declarao geral do o que e na declarao especfica de quanto e por quanto tempo. Neste documento, devem ser especificados quais so os objetivos e como alcan-los. As informaes que devero fazer parte do plano do projeto podem ser visualizadas no modelo de documento apresentado no Quadro 01. No planejamento, o gerente de projetos deve planejar o desenvolvimento dos componentes que estaro sendo desenvolvidos, analisando a dificuldade de integrao dos mesmos. Se for usar follow-the-sun, verificar qual o desempenho e a confiabilidade que existe na passagem de artefatos de um local para outro. Posteriormente, para realizar o controle do projeto, ser feita uma comparao do que foi planejado com o que est sendo realizado para se tomar as devidas aes corretivas, se necessrio.

6.4.2 Organizao
O organizao do projeto sugerida pelo MGP apresenta a figura do gerente local que o responsvel pelos participantes do projeto de um mesmo local. Este gerente surge como gerente ad hoc em organizaes com ADDS com a responsabilidade informal de criar e disciplinar o comportamento, compartilhar informao do cronograma e dos trabalhos desenvolvidos nos locais distribudos (SNOW et al., 1992 apud POWELL, PICCOLI e IVES, 2004). A idia da criao desta funo pode ser estendida para o gerenciamento de equipes, tendo a responsabilidade de assegurar que: as informaes crticas so compartilhadas no tempo certo; que os esforos dos membros da equipe virtual esto coordenados apropriadamente; e, que existe uma definio clara das funes sem duplicao de esforo levando as contribuies de cada membro da equipe para o alcance dos objetivos (POWELL, PICCOLI e IVES, 2004). Outros trabalhos, (KAYWORTH E LEIDNER, 2001-2002; VOGEL et al., 2001) citados por Powell, Piccoli e Ives (2004) sugerem que as equipes virtuais se beneficiam com a presena destes gerentes cuja contribuio equipe fornecer

106

um suporte detalhado, regular, manter uma comunicao direta e identificar as funes e responsabilidades de cada membro da equipe. Para o MGP, este gerente denominado gerente local e, responsvel por: exercer a liderana, resolver os conflitos, dirigir a equipe, informar outros grupos e o gerente de projetos sobre as atividades sob responsabilidade do grupo e motivar a equipe. Outra sugesto o desenvolvimento de um Mapa de Responsabilidade Linear (MRL), o qual importante para a definio das responsabilidades onde devem constar: a atividade a ser desenvolvida e quem o responsvel pela atividade. importante que isso seja feito com a compreenso e aceitao de todos os membros da equipe para que trabalhem em harmonia. Os gerentes envolvidos devem elaborar o MRL. Dentro do MRL, o responsvel por fazer a documentao do help do software dever participar de todas as reunies do projeto para evitar perda de tempo. Fornecer assistncia online para o usurio pode reduzir o custo evitando o desperdcio de suporte tcnico alm de tornar mais fcil para o usurio solucionar problemas comuns (JOHNSTON, 2005).

6.4.3 Motivao
Para que o gerente possa motivar os participantes de um projeto com uma equipe tradicional, precisa compreender o que motiva cada um dos participantes e possuir habilidades interpessoais. A motivao pode se originar de dentro e fora do indivduo, influenciando o seu desempenho dentro do projeto. A hierarquia das necessidades de Maslow (CLELAND e IRELAND, 2002) fornece uma base para o entendimento da motivao das pessoas dependendo do nvel em que se encontra dentro desta estrutura. A Figura 19 apresenta esta estrutura. De acordo com a hierarquia das necessidades de Maslow, tem-se: (1) Necessidades Fisiolgicas Bsicas: A satisfao dessas necessidades gua, comida e abrigo essencial vida. (2) Necessidades de Segurana: Dizem respeito proteo da vida e do bem-estar contra os elementos e ambientes prejudiciais que incluem a liberdade sobre aes arbitrrias da alta administrao. (3) Necessidades Sociais: Dizem respeito satisfao do convvio social, o afeto, a integrao, a participao e a aceitao pela equipe do projeto. (4) Necessidades de Auto-estima e Status: Motivam as pessoas busca por participao ativa, influenciando e contribuindo de alguma forma para a cultura da organizao a que pertencem. 107

(5) Necessidades de auto-realizao: Explicam a fora contnua que impulsiona as pessoas para obteno de resultados, criatividade e auto-realizao apesar de j terem honras e bens.

Figura 19. Hierarquia das Necessidades de Maslow Adaptado (CLELAND e IRELAND, 2002).

A Hierarquia da Figura 19 mostra que a questo salarial importante e bsica mas no a nica questo a ser considerada para motivar pessoas. Pela da anlise de um questionrio aplicado em milhares de tcnicos por Cleland e Kocaoglu (1981 apud Cleland e Ireland, 2002), as respostas mais freqentes sobre os fatores motivacionais do trabalho so: oportunidades de promoo, oportunidades para mostrar um trabalho de qualidade, importncia do trabalho que est realizando, bom relacionamento interpessoal, bom salrio, muita liberdade no trabalho, oportunidades de auto-desenvolvimento e aperfeioamento, oportunidades para desenvolver um trabalho interessante, satisfao pessoal, reconhecimento por parte dos colegas, respeito obtido como pessoa. Existem ainda, outros fatores que influenciam o desempenho no trabalho, tais como: condio fisiolgica, atitudes psicolgicas, crenas polticas, padres morais e profissionais, preconceitos e hbitos. 108

Para entender melhor tambm as atitudes e motivao no trabalho, Frederick Herzberg estudou os fatores que causam satisfao ou insatisfao. Herzbert publicou seus resultados em 1959 no livro The Motivation to Work e identificou que os fatores encontrados para a satisfao so diferentes dos fatores para a insatisfao e tambm desenvolveu a teoria de motivao-higiene para explicar seus resultados. Os fatores para satisfao so os motivadores e os de insatisfao so os de higiene ou manuteno que so necessrios para evitar a insatisfao e que por si s no promovem satisfao (TWO... ,2006). Os 6 principais fatores de insatisfao so: poltica da companhia, superviso, relacionamento com chefia, condies de trabalho, salrio, e, relacionamento com colegas de trabalho. E, os 6 principais fatores de satisfao so: realizao, reconhecimento, trabalho individual, responsabilidade, promoo, crescimento. Apesar da identificao dos fatores de satisfao e insatisfao a satisfao no implica necessariamente em um alto nvel de motivao ou produtividade (HERZBERGS..., 2006). As sugestes de Herzberg (TWO... ,2006) para motivar os funcionrios so: (1) Aumentar o escopo do trabalho dando ao empregado um maior alcance no seu trabalho; (2) Enriquecer o trabalho dando mais responsabilidade e permitindo a tomada de decises; e, (3) Realizar a rotatividade no trabalho fazendo com que os empregados trabalhem em diferentes tarefas. A teoria de Herzberg tem sido amplamente lida apesar das controvrsias, pois, reconhece que a verdadeira motivao vem de dentro das pessoas e no por fatores externos, no importando os fatores que levam a satisfao ou insatisfao (HERZBERGS..., 2006). Portanto, importante criar uma atmosfera cultural que proporcione o melhor desempenho dos participantes. Isso depende muito da habilidade do responsvel por esta motivao. Com relao s condies fisiolgicas, a organizao deve fornecer uma estrutura fsica adequada. A questo : como o gerente obter essas informaes com a dificuldade da distncia fsica entre os participantes? A figura do gerente local, dever exercer a responsabilidade pela motivao da equipe e para isso deve obter informaes pessoais sobre cada um dos participantes. Para auxiliar a execuo da funo de motivao, sugerimos a aplicao de um questionrio, que est no ANEXO A, aos funcionrios na fase de inicializao do projeto que, ajudar a obter estas informaes. A motivao tambm influenciada pela estrutura fsica da organizao, e pela cultura organizacional e de equipes praticadas. Uma prtica para conduzir uma cultura organizacional 109

e de equipes adequada fornecer o treinamento e conhecimento aos participantes do projeto para que sigam o padro da organizao e promover um ambiente que fornea uma rpida soluo aos problemas, evitando o stress. O reconhecimento e a recompensa fornecidos queles com maior iniciativa tambm melhoram a produtividade (PRESSMAN, 2001). Para isso, a obteno dos dados do questionrio aplicado ajudar a dar o reconhecimento e a recompensa adequados para cada um.

6.4.4 Direo
Dirigir proporcionar a competncia necessria de liderana para garantir a tomada e execuo de decises que envolvem o projeto (CLELAND e IRELAND, 2002). A direo ser fornecida pelos gerentes: geral, local e de projeto e, baseado na autoridade/responsabilidade definida no MRL do projeto. Um exemplo de MRL pode ser visto pela Tabela 04. A identificao do tipo de liderana poder ser realizada tambm com a aplicao do questionrio do Apndice A que identifica se melhor um tipo de liderana com mais liberdade e maior delegao de responsabilidades ou uma liderana mais rgida.
Atividades Estabelecer Padres da Organizao Cuidar Relacionamento com parceiros de negcios Resoluo de conflitos entre projetos e locais Resoluo de conflitos internos do projeto Resoluo de conflitos locais Planejamento do Projeto Monitoramento e Controle do Projeto Planejamento Estratgico Priorizar, suspender, cancelar o projeto Legenda: 1 Responsabilidade Atual 2 Deve ser consultado 3 Pode ser consultado 4 Deve ser notificado 6 Autoridade de Aprovao Gerente Geral 1 1 1 3 3 6 3 1 6 Gerente Local 2 2 2 1 3 1 1 3 4 Gerente de Projeto 2 2 2 3 1 2 2 3 4

Tabela 04. Mapa de Responsabilidade Linear.

110

6.5 O MGP Proposto no DiSEN

Para realizar a implementao do MGP proposto no DiSEN, foram identificados os atores responsveis pelo GP definindo suas funes dentro do ambiente, depois foram levantados os requisitos para a ferramenta DIMANAGER e apresentado o workflow das atividades do MGP no DiSEN.

6.5.1 Atores
De acordo com Fowler e Scott (2000), inicialmente, devemos identificar os atores para o sistema a ser desenvolvido, que so os mesmos identificados no Item 6.3.1.1: o gerente geral, o gerente local, o gerente de projetos e o engenheiro de software. O gerente geral um dos gerentes locais, conforme pode ser visto na Figura 19. S pode haver um gerente geral que possui privilgios de consultar todas as informaes sobre todos os projetos da organizao. O gerente local o responsvel por cada local ou unidade administrativa geograficamente dispersa. O gerente de projetos o responsvel por um projeto especfico e o engenheiro de software aquele que ir desenvolver as tarefas do projeto.

Projeto A = participantes nos locais 1, 2 e 3 denominados A1, A2 e A3 Projeto B = participantes nos locais 1, 2 e 3 denominados B1, B2 e B3
Figura 20. Diviso de Projetos nos Locais

A Figura 20 mostra como se d a liberao dos usurios do projeto. Cada projeto pode ter participantes em vrios locais. Os usurios devem ser cadastrados pelos gerentes locais (usurios do local 1, sero cadastrados pelo gerente local 1, usurios do local 2 sero cadastrados pelo gerente local 2...) e, aps o cadastramento, cada um deles poder liberar os usurios que cadastrou para um projeto em particular. Para o projeto A, foram liberados os

111

usurios A1, A2 e A3. Para o projeto B foram liberados o B1, B2 e o B3. O gerente do projeto A o A1 e o gerente do projeto B o B1. O gerente geral o gerente do local 2.

6.5.2 Funcionalidades
As funcionalidades de cada ator dentro do MGP foram divididas em gerenciadores: Gerenciar Local, Gerenciar Recursos, Gerenciar Processo, Gerenciar Projeto, Gerenciar Tarefa, e Gerenciar Artefato, como mostrado a seguir: (1) Gerenciar Locais: Definir Gerente do Local. (2) Gerenciar Recursos: Cadastrar perfil, cadastrar usurio, associar perfil ao usurio, cadastrar recurso material, cadastrar tipo de recurso material, cadastrar fornecedores. (3) Gerenciar Processo: Cadastrar processo, cadastrar fase do processo, definir seqncia das fases do processo, cadastrar atividade do processo, definir sequncia das atividades do processo, associar tipo de recurso atividade do processo, associar tipo de artefato atividade do processo, associar perfil atividade do processo, associar mtricas ao processo, cadastrar mtricas. (4) Gerenciar Projeto: Cadastrar projeto, selecionar processo para o projeto, cadastrar atividade do projeto, definir seqncia das atividades do projeto, associar perfil atividade do projeto, cadastrar estimativas do projeto, cadastrar conhecimentos, cadastrar riscos, associar participante atividade, associar recurso material tarefa, associar usurio ao projeto, associar recurso material ao projeto, associar fornecedor ao projeto , cadastrar clientes, definir valor das mtricas. (5) Gerenciar Tarefa: Consultar tarefas do participante, atualizar situao da tarefa e gerar problema tarefa. (6) Gerenciar Artefato: Listar artefatos, gerar artefato, recuperar artefato, cadastrar tipo artefato. O diagrama de use-cases, apresentado no Apndice C mostra uma viso geral do nvel de acesso por ator/funo e, para melhor entendimento, pode-se consultar o prottipo descrito no Captulo 7.

6.5.3 Ferramenta de Apoio ao GP

Apresenta-se aqui, a origem dos requisitos identificados pelo trabalho realizado e um detalhamento dos mesmos. Como visto anteriormente, a ferramenta DIMANAGER (PEDRAS, 2003) j possui funcionalidades bsicas para o GP, algumas das quais esto em conformidade com o CMMI 112

Staged Nvel 2 (SEI, 2002) e o Modelo Processual do PMI (PMI, 2004a). Aps o estudo dos modelos de GP apresentados no Captulo 5 e das discusses e reunies do grupo DiSEN, novos requisitos foram identificados para serem incorporados ferramenta. O exposto aqui pode ser visto na Tabela 05.
Elementos Identificados Diviso do trabalho em EAP Estimativa das tarefas e produtos Medio e anlise Gerenciamento dos requisitos Gerenciamento de acordo com o fornecedor Identificao de riscos e gerenciamento de riscos Medio e anlise Estimativa das tarefas e produtos Definio do ciclo de vida do projeto Oramento Cronograma Gerenciamento de stakeholder Lies aprendidas e gerncia de aprendizagem Conflitos Propriedade intelectual Origem CMMI Staged Nvel 2 e Modelo Processual do PMI CMMI Staged Nvel 2 e Modelo Processual do PMI CMMI Staged Nvel 2 CMMI Staged Nvel 2 CMMI Staged Nvel 2 CMMI Staged Nvel 2, Modelo Processual do PMI e MuNDDoS CMMI Staged Nvel 2 CMMI Staged Nvel 2 e Modelo Processual do PMI CMMI Staged Nvel 2 e Modelo Processual do PMI CMMI Staged Nvel 2 e Modelo Processual do PMI CMMI Staged Nvel 2 e Modelo Processual do PMI Modelo Processual do PMI MuNDDoS e MGP Baseado no PMI para ADDS MGP Baseado no PMI para ADDS MuNDDoS e MGP Baseado no PMI para ADDS Funcionalidades para a Ferramenta Cadastro de atividades e sequenciamento de atividades Cadastro da estimativa de esforohora Cadastro de problemas tcnicos e organizacionais ocorridos no projeto Rastreamento de requisitos e mtrica de volatilidade de requisitos Cadastro de fornecedores para avaliao de fornecedores Cadastro de riscos J Existe? Sim Sim Sim No No No

Cadastro das mtricas e atualizao dos valores das mtricas Consulta da estimativa de esforohora e de custo dos RH de uma tarefa ou projeto. Cadastro de processos de desenvolvimento de software e seleo do processo para o projeto Consulta e/ou relatrio do oramento dos RH do projeto Consulta e/ou relatrio do cronograma do projeto Cadastro de fornecedores e clientes Cadastro de conhecimentos

No No

No

No No No No

Visualizao imediata do problema pelo gerente de projeto Restrio de acesso s informaes dos projetos para os participantes

No Parte

Tabela 05. Requisitos e a Correspondncia com os MGP estudados.

113

Ao todo foram identificados 12 novos requisitos, que so: 1) Rastreamento de requisitos e mtrica de volatilidade de requisitos; 2) Cadastramento dos fornecedores para avaliao dos mesmos; 3) Cadastramento dos riscos; 4) Cadastramento das mtricas e atualizao dos valores das mtricas; 5) Consulta das estimativas de esforo-hora e custo dos RH de uma tarefa ou projeto; 6) Cadastro de processos e definio do processo para o projeto; 7) Consulta e/ou relatrio do oramento; 8) Consulta e/ou relatrio do cronograma; 9) Cadastramento de fornecedores e clientes; 10) Cadastramento de conhecimentos; 11) Visualizao imediata do problema pelo gerente do projeto; 12) Restrio de acesso s informaes dos projetos para os participantes. A seguir, uma explicao sobre como ser disponibilizado na ferramenta. O Item 1) no ser tratado pela ferramenta de apoio ao GP no que se refere ao rastreamento de requisitos, pois isso dever ser tratado em trabalhos futuros, devido complexidade. Seria necessrio um estudo mais aprofundado sobre o assunto e, tambm, haveria necessidade de fornecer interoperabilidade entre ferramentas de requisitos, anlise, projeto, implementao, testes com a ferramenta de apoio ao GP. Por exemplo, a utilizao da ferramenta REQUISITE (BATISTA, 2003) poder fornecer de forma automatizada, por meio da interoperabilidade com outras ferramentas para as demais fases da MDSODI(), as informaes das mtricas sobre o impacto nas alteraes dos requisitos e sobre a volatilidade dos requisitos para a ferramenta de apoio ao GP. No Item 2), para realizar a avaliao dos fornecedores, primeiro foi criado um cadastro para os mesmos, podendo associ-los a um recurso material ou somente a um projeto. Aps isso, os gerentes locais que so os responsveis por definir um fornecedor para o recurso material e para os servios do projeto podero avaliar os fornecedores de acordo com as mtricas associadas a eles. Um relatrio com a avaliao dos fornecedores ser emitido para selecionar fornecedores. O cadastro de riscos do Item 3) permitir o acompanhamento dos principais riscos do projeto. Neste cadastro, os riscos considerados na seleo de projetos para as unidades administrativas, os riscos relacionados aos RH e materiais e os demais riscos so includos e depois atualizados. Os principais riscos podero ser visualizados por um relatrio de riscos que est descrito no Apndice B. Com relao ao Item 4), o cadastro de mtricas permite visualizar qual o objetivo, a descrio de como ser obtida a mtrica e qual a justificativa para se realiz-la. Aps o cadastramento, elas podem ser associadas ao processo, fase do processo, atividade do 114

processo, fornecedor, projeto, fase do projeto, atividade do projeto, tarefa. Podemos visualizar as associaes pelo diagrama de classes apresentado no Apndice D. Algumas mtricas so consideradas essenciais e podem ser coletadas automaticamente como por exemplo o esforohora. Outras podem ser obtidas pela totalizao das informaes, tais como: quantidade de projetos, quantidade de processos, quantidade de projetos que utilizam determinado processo, nmero de participantes do projeto, etc. No Item 5), pode-se consultar o esforo-hora gasto em uma tarefa e a estimativa do projeto em termos de esforo-hora total e custo total dos RH do projeto. O esforo-hora, j foi identificado como mtrica para o GP na DIMANAGER (PEDRAS, 2003), portanto, foi selecionada tambm como elemento para realizar a estimativa de custos com RH. Sendo assim, esto sendo armazenadas as seguintes informaes: estimativas de esforo-hora para cada tarefa do projeto, esforo-hora gasto para executar a tarefa e custo-hora do participante do projeto. Aqui, tambm podemos observar que a informao do custo/hora poderia ser obtida pelo salrio do participante, por meio da interoperabilidade com uma ferramenta para o clculo da folha de pagamento dos funcionrios da organizao. O cadastro de processos do Item 6) permite o cadastramento dos processos utilizados pela organizao para o desenvolvimento de software na organizao. Esse cadastro inclui as fases, atividades, recursos necessrios para executar as atividades, perfil do usurio necessrio para executar a atividade e mtricas a serem obtidas no processo. Aps o cadastramento dos processos, o gerente de projeto definir qual o processo a ser usado no projeto. Os Itens 7) e 8) permitem a consulta ou impresso de relatrios para o acompanhamento do oramento e do cronograma. A descrio dos mesmos est no Apndice B. No Item 9) temos novamente o cadastro de fornecedores j detalhado no Item 2) e o cadastro de clientes que ser til para contato e identificao dos clientes do projeto. O Item 10) permitir o cadastro de conhecimentos que ser til para armazenar: conhecimentos, forma de realizar atividades e lies aprendidas sobre o ocorrido nos projetos para consultas posteriores. O cadastro de problemas do Item 11) j existia na DIMANAGER, porm, ainda no havia sido implementada a comunicao imediata do problema ao gerente de projeto utilizando-se da mesma. Isso bastante til para todo desenvolvimento de software, exigindo a formalizao na solicitao de solues e evitando problemas de falta de comunicao. O Item 12) se refere restrio de acesso das informaes que impede que pessoas no autorizadas acessem dados que no fazem parte do seu contexto de trabalho. Com a 115

utilizao de uma senha para cada usurio do DiSEN, possvel trazer informaes pertinentes a cada um de forma que cada usurio tenha em sua rea de trabalho somente o necessrio para executar suas atividades. Isso ser garantido pelo gerenciador de acesso do DiSEN e pelo gerenciador de configurao dinmica, que no so o escopo deste trabalho. Neste trabalho, houve a identificao dos atores no MGP e a definio do acesso para os mesmos. Espera-se que o gerenciador de acesso possibilite que o gerente de projeto delegue responsabilidades a outras pessoas. Ser disponibilizado ao gerente de projetos os mdulos correspondentes s funcionalidades que ele poder delegar a outras pessoas. Ainda com relao restrio de acesso, a identificao sobre qual a organizao responsvel por cada local importante para restringir o acesso dos dados dos locais somente organizao a qual pertencem, pois, existe a possibilidade de vrias organizaes estarem usando o DiSEN. J, com relao configurao dinmica de servios, que est sob responsabilidade do gerente de projetos na arquitetura DiSEN (PASCUTTI, 2002), a automatizao deste processo seria bem til, pois, medida que o gerente de projetos define o participante responsvel por uma atividade do projeto, fica implcito quais ferramentas podero ser liberadas para cada usurio. O prottipo apresentado no Captulo 7, apresenta as janelas para mostrar como ser, de forma geral, o funcionamento da ferramenta.

6.5.4 Workflow das Atividades do MGP no DiSEN

Ao identificar os atores e funcionalidades, que esto no Apndice C, definiu-se a seqncia de trabalho dos atores de acordo com as funcionalidades para uma visualizao melhor de como sero conduzidas as atividades de GP. Esta seqncia de trabalho est apresentada como o workflow das atividades do MGP no DiSEN. A seguir, a descrio do mesmo: 1) O gerente geral define os locais/unidades distribudas e as informaes gerais (processos, fases do processo, atividades do processo, seqncia das fases do processo, sequncia das atividades do processo, perfil e nvel de perfil para associar s atividades e aos usurios, perfil associado a cada atividade do processo, tipos de recursos materiais, mtricas, tipos de artefatos gerados) a serem utilizados na organizao, os fornecedores aprovados pela organizao e os gerentes locais; 2) A instalao do DiSEN nos diferentes locais realizada, incluindo informaes como: nome, localizao, gerente do local. Aps a instalao, o gerente geral pode consultar os locais; 116

3) O gerente local cadastra os usurios do local, o perfil de cada usurio, a aptido de cada usurio, a disponibilidade de cada usurio e os recursos materiais do local. Tambm pode cadastrar informaes gerais do item 1); 4) O gerente geral define os projetos que sero desenvolvidos em cada local e os riscos existentes em nvel estratgico que esto associados a cada projeto. Estes riscos esto descritos no trabalho de Prikladnicki (2003); 5) O gerente local cadastra os projetos, os riscos preliminares do projeto (associados aos recursos materiais e humanos do local), define quais usurios esto liberados para cada projeto (estes projetos podem estar alocados em outro local), define o gerente do projeto, define os recursos materiais liberados para cada projeto, cadastra os clientes do projeto e cadastra os fornecedores dos recursos materiais e os fornecedores de servio para cada projeto. O usurio que foi alocado para um projeto passa a ser considerado um participante do projeto. Fornecedores incluem empresas ou organizaes que fornecem treinamento, hardware, software, material de consumo e, at mesmo, uma parte do projeto. 6) O gerente de projeto altera dados (nome, descrio, objetivos, data de incio e fim previstos, cliente) do projeto, define o processo a ser utilizado para desenvolver o projeto, define novas mtricas que podem ser usadas no projeto, cadastra novas atividades do projeto se houver necessidade e redefine a seqncia das atividades, cadastra as estimativas do projeto em esforo-hora, define quais participantes executaro cada tarefa do projeto (uma atividade composta de uma ou mais tarefas) podendo tambm ativar o mecanismo de gerenciamento de RH, resolve problemas na execuo de uma tarefa do projeto, define quais os recursos materiais que sero usados para executar cada tarefa, cadastra os riscos do projeto (relativos mudana de tecnologia, tempo para trmino do projeto e oramento menor que o esperado); 7) O engenheiro de software consulta as tarefas sob sua responsabilidade, atualiza a situao da tarefa, cadastra os problemas encontrados na execuo da tarefa, gera os arquivos relativos sua tarefa. 8) O gerente de projeto avalia o artefato criado pelas tarefas concludas e mantm a situao como concluda ou solicita alterao/correo no artefato alterando o estado da tarefa para Em planejamento ou Em andamento comunicando diretamente ao(s) engenheiro(s) de software. 9) O gerente de projeto monitora a execuo do projeto pela consulta: das tarefas e sua situao e, principalmente do cronograma. Quando surgem novas informaes para se 117

refazer o cronograma e o oramento do projeto, as informaes devem ser atualizadas nos cadastros e isso se estende at mais da metade do tempo de desenvolvimento do projeto, de acordo com o modelo processual do PMI (PMI, 2004a). 10) O gerente de projeto pode suspender, cancelar ou concluir o projeto atualizando a situao do projeto a qualquer momento. (Essa deciso tomada juntamente com o gerente geral da organizao). 11) Quando houver a finalizao de qualquer projeto (cancelado ou concludo), o gerente geral cadastra as lies aprendidas ou conhecimentos aps o recebimento de informaes dos participantes do projeto.

O workflow apresentado aqui, mostra como se prev o desenvolvimento das atividades do GP em uma organizao com o uso do DiSEN.

6.6 Consideraes Finais

O MGP apresentado possui elementos para efetuar o GP em um ADDS. Alguns dos elementos podem ter uma ferramenta de suporte dentro do ADDS que, no caso deste trabalho, o DiSEN. Os elementos aqui apresentados fazem parte do prottipo apresentado no captulo seguinte. Entende-se que o GP possui partes que correspondem s atividades exclusivamente gerenciais e outra parte que pode ser implementada em uma ferramenta. O MGP apresentado atende a estas duas partes fornecendo ao gerente de projetos os elementos para o controle efetivo do GP em um ADDS. O prottipo apresentado no Captulo 7, permite uma visualizao melhor do funcionamento da DIMANAGER como o exposto aqui.

118

CAPTULO VII Prottipo do MGP para o DiSEN 7.1 Introduo

Os mesmos aspectos relevantes utilizados na construo da ferramenta DIMANAGER (PEDRAS, 2003), citados abaixo, foram usados para construir o prottipo do MGP para o DiSEN. Planejar, fixando objetivos e as alternativas para ating-los, inclusive o provimento de recursos humanos e materiais necessrios; Organizar as atividades necessrias para atingir os objetivos fixados; Controlar, verificando se as atividades realizadas esto sendo executadas de acordo com o planejamento estabelecido; Alocar pessoal, distribuindo as equipes de trabalho para cada atividade estabelecida; Coordenar, relacionando convenientemente as atividades s equipes de trabalho envolvidas em cada processo, assegurando a cooperao de todas as equipes envolvidas em uma atividade (PEDRAS, 2003). Alm das funcionalidades apresentadas pela DIMANAGER para tratar dos aspectos relevantes, novas funcionalidades foram apresentadas, tais como: planejamento e controle de riscos do projeto; informaes para seleo dos RH mais aptos para a realizao das tarefas; manuteno do conhecimento dentro da organizao; armazenamento de mtricas para melhoria da qualidade do processo e do produto; estimativa de esforo-hora e custo dos participantes; cadastramento e avaliao de fornecedores; cadastramento dos clientes; cadastramento de processos com fases e atividades; cadastramento dos RH e materiais; cadastramento do perfil das atividades; cadastramento dos recursos materiais necessrios para executar as atividades; cadastramento dos tipos de artefatos que as atividades podem gerar; apresentao da agenda do engenheiro de software; e, cadastro de problemas pelo engenheiro de software. Foi realizado um levantamento das funcionalidades necessrias segundo o MGP e ento elaborado o documento apresentado no Apndice B.

119

7.2 Construo do Prottipo

Quando a ferramenta DIMANAGER (PEDRAS, 2003) foi construda, ainda no havia a infra-estrutura para a implementao da mesma de forma distribuda por isso foi construda para ser utilizada localmente. Apesar de ter sido construda com a linguagem de programao JAVA, no foi possvel fazer reuso da implementao j realizada mas, as idias utilizadas para a construo da ferramenta DIMANAGER continuam a fazer parte do prottipo construdo o qual dever ser incorporado ao DiSEN. Aps a construo da DIMANAGER, ficou claro que era necessrio um MGP que apresentasse tambm solues em nvel exclusivamente gerencial. Desta forma, foi idealizado o modelo aqui apresentado no Captulo 6. Com o desenvolvimento do MGP, foram trazidas novas idias para a ferramenta DIMANAGER que culminaram com o aprimoramento da mesma e do ambiente DiSEN. Foi utilizada a linguagem UML (FOWLER e SCOTT, 2000) para descrever o prottipo. Para a elaborao do prottipo, foram revistos os trabalhos de: Gravena (2000), Pascutti (2002), Pedras(2003), Lima (2004), Santiago (2005), Curioni (2005) e Nitta (2005) e, que esto apresentados no item 3.2. Os elementos que j faziam parte da ferramenta DIMANAGER, que so: cronograma, participantes, atividades e problemas so tratados pelo prottipo. Tambm os seguintes elementos do trabalho de Pascutti (2002) foram considerados: recursos materiais utilizados nas atividades e no projeto, mtricas e estimativas. E, os demais trabalhos foram agregados ao prottipo de forma a permitir o entendimento das funcionalidades como um todo. O documento apresentado no Apndice B mostra as funcionalidades desejadas para o GP no DiSEN. Tambm, apresentou-se no mesmo, um glossrio para unificar os termos que poderiam gerar dvidas. No incio dos trabalhos o vocabulrio diferenciado utilizado por cada um dos trabalhos foi um dos fatores que dificultou o entendimento dos mesmos para o levantamento dos dados. Foram apresentadas aos integrantes do projeto DiSEN, as inconsistncias de vocabulrio e com relao ao diagrama de classes desenvolvido por Pascutti (2002), Pedras (2003) e Lima (2004), o que resultou na elaborao: do documento citado no pargrafo anterior, do diagrama de use-cases e da descrio dos use-cases apresentados no Apndice C e, do diagrama de classes atualizado apresentado no Apndice D. O prottipo do MGP est apresentado no item 7.3 e foi construdo utilizando-se da linguagem de programao JAVA e o banco de dados Postgres. A base de dados contm 120

aproximadamente 50 tabelas que permitem a implementao de acordo com o diagrama de classes projetado. Deve ser ressaltado aqui que o prottipo est focado nas atividades do gerente de projeto.

7.3 Funcionamento do Prottipo

Tomando como base a definio dos atores dentro do MGP, identificou-se 4 menus distintos de acordo com as suas funes. Abaixo esto os atores e os itens do menu disponibilizados para cada um. (1) Gerente geral: Local, processo, mtrica, perfil, recurso material, tipo de artefato; (2) Gerente local: Usurio, processo, mtrica, perfil, recurso material, tipo de artefato; (3) Gerente de projeto: Projeto, mtrica, perfil, recurso material, tipo de artefato, conhecimento; (4) Engenheiro de Software: rea de trabalho com a Agenda e ferramentas para realizar o trabalho. Inicialmente, deve-se digitar o usurio e a senha para entrar no sistema e, aps isso, so apresentadas as opes para cada um. Se o usurio tiver mais de uma funo dentro do sistema, ele deve escolher com que funo deseja trabalhar. Um usurio pode ser um gerente local e um gerente geral, acumulando funes. Cada ator, possui um tipo de acesso diferente, e, quando so apresentadas as informaes, elas so filtradas para mostrar somente as informaes pertinentes. Por exemplo, quando o gerente local acessar a janela de projeto, sero mostrados todos os projetos que esto relacionados com o seu local. Quando o gerente de projeto acessar a janela de projeto, sero mostrados todos os projetos dos quais ele gerente. O acesso a cada janela est descrito no Apndice C. As janelas no apresentadas nos Itens 7.4.1 a 7.4.4, esto no Apndice E.

7.3.1 Menu para o Gerente Geral

O menu para o gerente geral contm as seguintes opes: local, processo, mtrica, perfil, recurso material e tipo de artefato. Primeiramente, o local instalado fazendo com que as informaes apaream na janela como mostra a Figura 21. Por isso, no momento da instalao, deve-se cadastrar o usurio que ser o gerente do local e o local. O gerente geral pode ento alterar quem o gerente do local.

121

As demais janelas disponibilizadas para o gerente geral possibilitam ao gerente geral cadastrar: a) os processos da organizao, com suas fases, atividades, seqncia de fases, seqncia de atividades, recurso material necessrio para executar a atividade, perfil necessrio para executar a atividade; b) as mtricas que sero associadas ao processo, s fases do processo, s atividades do processo, etc.; c) o perfil que ser associado atividade e que tambm ser associado ao usurio; d) os recursos materiais com seus tipos e fornecedores. Podendo tambm associar o recurso material ao local, considerando que cada local ir trabalhar com uma determinada srie de recursos materiais; e, e) os tipos de artefato que podem ser gerados com a execuo das atividades.

Figura 21. Janela para Consulta e Alterao de Dados do Local.

A janela para cadastramento de processos est apresentada na Figura 22. Desta janela podemos ir para a janela de cadastramento de fases (2) como est descrito no Apndice C. Temos os dados para identificao dos processos que so nome e verso apresentados e os botes que podem ser pressionados de acordo com o desejado pelo usurio. Todas as janelas de cadastro possuem este formato.

122

Figura 22. Janela para Cadastramento de Processo.

Como visto no Item 4.4.1, todo processo de desenvolvimento de software possui fases, dependncia entre as fases, atividades e dependncia de atividades dentro das mesmas. As fases do processo podem ser cadastradas da mesma forma com a digitao do nome e descrio, e para cadastrar as atividades, escolhe-se a fase qual pertencem. Para definir a dependncia entre as fases, seleciona-se uma das fases e a fase dependente. Alm disso, em outra janela possvel determinar a dependncia existente entre as fases. J a dependncia entre as atividades pode ser uma dependncia de dados ou somente de seqncia. E, ainda, para cada atividade pode-se associar o perfil e o recurso material necessrios para execut-la, informando o nvel e a quantidade necessria do recurso respectivamente. As janelas nas quais possvel fazer o descrito aqui esto no Apndice E (Figuras 40 a 45). Tambm est disponvel ao gerente geral o cadastramento das mtricas como mostra a janela da Figura 23 e, aps isso, sero associadas ao processo, fase do processo, atividade do processo, projeto, fase do projeto, atividade do projeto, tarefa, fornecedor, cliente. Algumas mtricas so coletadas automaticamente como por ex.: o esforo-hora gasto para executar a atividade que vai coletar essa informao toda vez que o engenheiro de software estiver trabalhando na tarefa. O engenheiro deve, toda vez que entrar no sistema, informar em qual tarefa est trabalhando. A Figura 46 mostra como pode ser realizada a associao da mtrica com uma atividade do processo. Algumas das associaes das mtricas j esto cadastradas, como por exemplo, a mudana de requisitos nas fases, que est prevista no trabalho de Nitta (2005). Outro tipo de coleta automtica de mtrica o esforo-hora que est associado 123

tarefa e ser armazenado sempre que o engenheiro de software estiver trabalhando em uma tarefa.

Figura 23. Janela para Cadastramento de Mtricas.

Figura 24. Janela para Cadastramento de Perfil.

124

Outra opo para o gerente geral o cadastramento do perfil de atividade ou usurio temos a Figura 24. O perfil pode ser um treinamento, conhecimento ou habilidade e o nvel que cada perfil pode ter tambm deve ser cadastrado (Figura 49 do Apndice E). importante manter um controle sobre os recursos materiais da organizao. Inicialmente, para realiz-lo, deve-se manter um cadastro dos recursos materiais como mostra a Figura 25. Cada local poder ter recursos materiais disponveis. O estado do recurso material pode ser disponvel e no disponvel. Este controle deve ser realizado para licenas de software. A quantidade a existente no momento do cadastramento e a quantidade utilizada deve ser atualizada sempre que houver consumo do recurso. Por exemplo, podemos ter uma compra de 10 computadores e aps a alocao do recurso para um projeto a quantidade utilizada seja 4. Essa quantidade utilizada para se manter um controle quando da associao do recurso para um determinado projeto.

Figura 25. Janela para Cadastramento do Recurso Material.

J, os fornecedores podem ser cadastrados pela janela da Figura 26. Caso o fornecedor fornea apenas servios, basta o seu cadastro sem associ-lo a um recurso material.

125

Figura 26. Janela para Cadastramento de Fornecedores.

Tambm podem ser associadas mtricas ao fornecedor (Figura 27), o que est de acordo com a avaliao de fornecedores descrita no CMMI (SEI, 2002). As mtricas de avaliao dos fornecedores devero ter seus valores informados por aqueles que mantm contato direto com o fornecedor. A avaliao dever ento, ser realizada pelo gerente de projeto e gerentes locais. Essa avaliao ser usada para futuras contrataes.

Figura 27. Janela para Cadastrar Mtricas para Avaliar o Fornecedor.

As mtricas associadas aos fornecedores podem avaliar a pontualidade e a qualidade dos produtos e servios e, podem ser definidas com pontuao (1 a 10) dada a cada item. Se 126

um recurso ou servio no estiver de acordo, ou houver qualquer reclamao sobre o mesmo, o gerente de projeto saber imediatamente pois receber esta informao como um problema na execuo da tarefa e, essa informao deve ser repassada ao gerente local, que ir realizar a avaliao do fornecedor. Tudo que o gerente de projeto recebeu como problema e quiser repassar ao gerente local, pode ser repassado pelo cadastro de problemas. A ltima opo permite o cadastramento do tipo de artefato que cada atividade gera, como mostra a Figura 47 no Apndice E. O tipo de artefato pode ser um: diagrama de usecase, um diagrama de seqncia, documento, etc.

7.3.2 Menu para o Gerente Local

O menu para o gerente local contm as seguintes opes: usurio, processo, mtrica, perfil, recurso material, tipo de artefato e projeto. Como na ferramenta DIMANAGER, os usurios devem ser cadastrados (Figura 28).

Figura 28. Janela para Cadastramento do Usurio.

O gerente local dever cadastrar os usurios do local. Cada usurio ter um local ao qual pertence dentro da organizao, que dever ser o local onde estar trabalhando ou o local 127

mais prximo de onde ir trabalhar, pois, pode ser um usurio que deseje trabalhar em sua prpria residncia. Quando o gerente local cadastra o usurio este, estar automaticamente ligado ao mesmo local do gerente local. Aps o cadastramento do usurio, possvel associar o perfil com o usurio, para isso basta selecionar o perfil que deseja associar e definir o nvel e a data que adquiriu o perfil ou a data de referncia de quando foram levantados os dados. Lembrando que o perfil pode ser um conhecimento, habilidade ou treinamento. Outra possibilidade o cadastramento da aptido do usurio que est relacionada ao trabalho descrito no item 3.2.6 (CURIONI, 2005) e, permite cadastrar os percentuais obtidos pela aplicao do questionrio sugerido (MIRANDA,1997 apud CURIONI, 2005). Este questionrio se encontra no ANEXO B. Outro cadastro importante para o DDS o dos perodos de disponibilidade de cada usurio, isso permite que o gerente de projeto possa fazer o melhor uso dos participantes distribudos geograficamente, possibilitando o follow-the-sun descrito no item 3.3.3. Os dados relativos disponibilidade do usurio podem ser cadastrados com o preenchimento dos atributos: dia da semana, hora de incio e hora fim onde: 1=Domingo, 2=Segunda, 3=Tera, 4=Quarta, 5=Quinta, 6=Sexta e 7=Sbado. Deve-se usar sempre um local de referncia para determinar estes dados devido variao de fuso horrio. As informaes anteriores do perfil, da aptido e da disponibilidade devero ser armazenadas para o uso do mecanismo de apoio ao gerenciamento de RH criado por Lima (2004). Depois do cadastramento do usurio possvel associ-lo a um projeto, deve-se utilizar a janela apresentada na Figura 29 e partir dessa associao, o usurio considerado um participante do projeto. Tambm esto disponveis as opes de cadastramento de processos, mtricas, perfil e tipo de artefato, pois, o gerente local poder ter autonomia para tambm realizar o cadastramento. O recurso material poder ser cadastrado da mesma forma que foi apresentado no item 7.3.1. com a possibilidade de associao do recurso material ao projeto para determinar quais recursos materiais o projeto poder utilizar. Como o custo de um recurso humano pode variar de um projeto para outro, podemos cadastrar essa informao.

128

Figura 29. Janela para Definir os Participantes do Projeto.

Na opo projeto para o gerente local, temos tambm a janela da Figura 30, que permite a criao do projeto e, onde o gerente local deve definir quem o gerente do projeto que, por sua vez, dever ser um usurio do local e um participante do projeto. Para poder definir o gerente do projeto, o gerente local dever ter cadastrado o projeto e associado os usurios do projeto. Na Figura 30 temos o boto cliente que mostrar a janela para cadastramento dos mesmos mantendo um arquivo da mesma forma que os fornecedores. Os clientes devem realizar uma avaliao com relao ao software produzido, principalmente na fase de teste e, sendo assim, importante manter um canal de comunicao mediante contrato eletrnico, pois, o cliente normalmente estar em local disperso geograficamente. Se o cliente no estiver satisfeito com qualquer item do software, os documentos de compromisso com os requisitos e solicitao de alterao nos requisitos devem ser consultados para resolver os conflitos.

129

Figura 30. Janela para Cadastramento de Projeto.

Na Figura 30, temos o boto participante, onde podemos navegar para a janela de cadastro de participantes do projeto, possibilitando ao gerente local determinar quais os RH que faro parte de um determinado projeto de forma idntica Figura 29. (Figura 50). Ainda na Figura 30, o boto riscos, permite navegar para a janela apresentada na Figura 31 onde os riscos relacionados ao projeto podem ser cadastrados. Devem ser informados: nome do risco, descrio do risco, a probabilidade do risco ocorrer, a conseqncia em termos de tempo (horas), a conseqncia em termos de custo, o plano de contingncia (o que ser realizado no caso do risco ocorrer), o tipo do risco (organizacional, tcnico ou comunicao) e o estado do risco. Essas informaes so relevantes conforme descrito no Item 6.3.3.

130

Figura 31. Janela para Cadastramento de Risco do Projeto.

7.3.3 Menu para o Gerente de Projeto

O menu para o gerente de projeto contm as seguintes opes: projeto, mtrica, perfil, recurso material, tipo de artefato, conhecimento. O gerente de projeto poder cadastrar os dados do projeto apresentados na Figura 32 e pode selecionar qualquer um dos processos cadastrados. A partir do momento em que o gerente de projeto escolhe o processo a ser utilizado no desenvolvimento do projeto, o processo com suas fases, atividades, dependncias e mtricas so criados para o projeto. Fazendo isso, possvel ao gerente do projeto incluir novas fases e novas atividades para o projeto, pois, o gerente de projeto pode querer criar uma nova fase que envolva atividades de avaliao do local e de treinamento dos participantes. Tambm podem ser includas atividades como reunies e viagens que so tpicas onde existe o DDS. O gerente de projeto no poder alterar o processo mas poder excluir uma fase ou atividade do processo quando esta for 131

terceirizada, por isso, esto disponibilizadas as opes de fases, seqncia, mtricas, atividades, seqncia das atividades, perfil, tipo de recurso material.

Figura 32. Janela para preenchimento dos dados do projeto.

A janela de cadastramento da fase do projeto ter o checkbox ligado quando fizer parte de um processo. Da mesma forma, a janela de cadastramento das atividades do projeto que pode ser vista na Figura 33, ter o checkbox ligado quando a atividade for uma atividade do processo. Este checkbox informa que existe a ligao com uma fase ou atividade do processo ser mantida mesmo com a alterao do nome da fase ou atividade do projeto.

132

Figura 33. Janela para Preenchimento dos Dados da Atividade do Projeto.

O gerente de projeto pode utilizar somente os RH liberados para o projeto, que so os participantes do projeto. Ento, para definir qual dos participantes ir realizar cada atividade do projeto, deve fazer uso da janela apresentada na Figura 34. A partir disso, a atividade associada ao participante, doravante denominada de tarefa do projeto, dever aparecer na agenda do participante. At mesmo no caso da atividade ainda estar com estado = Em planejamento pois isso pode permitir um melhor planejamento pelo participante que no caso de haver qualquer problema no agendamento da tarefa, poder informar ao gerente do projeto.

133

Figura 34. Janela para Definir qual Participante ir Executar a Atividade.

Ainda, o gerente de projeto poder utilizar o mecanismo de apoio ao gerenciamento de RH (LIMA, 2004) para selecionar o participante para realizar a atividade. A Figura 51 do Apndice E mostra a janela para informar os parmetros para a consulta e o resultado da consulta (Figura 52). Outra opo para o gerente de projetos o cadastro de conhecimentos que est relacionado ao Item 6.3.2 onde constatou-se que uma das formas para realizar a gerncia do conhecimento realizando o seu armazenamento. Portanto, quando um conhecimento deve ser dividido entre todos na organizao, ele pode ser cadastrado na janela da Figura 35. O conhecimento pode ser sobre: como so realizadas as tarefas dentro da organizao, os temas que esto ligados orientao inicial proposta, a utilizao de ferramentas, cdigo de implementao, etc.

134

Figura 35. Janela para Cadastro de Conhecimento.

Para que o conhecimento possa ser consultado mais facilmente, conveniente definir as palavras-chaves do conhecimento (Figura 36). Essas palavras-chave devem ser cadastradas e permitem um filtro na busca pelo conhecimento (Figuras 53 e 54).

Figura 36. Janela para Associao do Conhecimento com Palavras-Chave.

135

7.3.4 Menu para o Engenheiro de Software

O menu para o engenheiro de software contm as seguintes opes na sua rea de trabalho: Agenda (Figura 37) e problemas (Figura 38). Alm disso, tambm ter ferramentas de desenvolvimento de software, como por exemplo a REQUISITE (BATISTA, 2003) para realizar o trabalho. Quando o engenheiro de software inicia seu trabalho, ele dever informar em qual tarefa agendada est trabalhando. A janela que possibilita isso deve apresentar todas as tarefas do engenheiro de software, de forma idntica a agenda apresentada, para que o mesmo selecione uma delas. A partir disso, os arquivos em que est trabalhando sero gravados no repositrio, sendo sempre confirmada a ligao entre o arquivo gerado e a tarefa que est ligada ao mesmo. Quando uma tarefa for concluda basta alterar o estado da mesma para concluda.

Figura 37. Janela com Informaes da Agenda do Engenheiro de Software.

Com relao aos problemas, os mesmos sero cadastrados pelo engenheiro de software quando estiver executando uma tarefa, se o problema for novo, isto , no estiver cadastrado.

136

Figura 38. Janela para Cadastramento do Problema.

A associao do problema com uma tarefa da sua agenda (Figura 39) automaticamente enviar uma mensagem ao gerente de projeto para que o problema seja resolvido. Sendo assim, quem possui acesso para cadastrar a soluo o gerente de projeto e, o engenheiro de software poder consultar a soluo ou as solues dadas ao problema.

Figura 39. Janela para Associao do Problema com a Tarefa.

137

O cadastro de problemas pode gerar um conhecimento para a organizao, o gerente do projeto quando acreditar ser conveniente, poder levantar os dados para cadastrar o conhecimento que foi gerado pela resoluo de um problema. Nem todo problema ser um conhecimento pois existem problemas que no devem ser repassados a todos os membros da organizao e somente para o gerente do projeto devido ao sigilo exigido. Est previsto que o engenheiro de software dever responder a 3 questionrios dentro do MGP, que so: 1) Questionrio para Coletar as Informaes para Utilizar o Mecanismo de Apoio ao Gerenciamento de RH (LIMA, 2004); 2) Questionrio para Coletar as Informaes para o Cadastramento da Aptido do Usurio (MIRANDA,1997 apud CURIONI, 2005); e, 3) Questionrio para Avaliao das Necessidades Individuais; Estes questionrios no foram implementados como parte do prottipo mas, podem fazer parte do workspace do engenheiro de software inclusive sendo disponibilizados pela Internet.

7.4 Estados Utilizados no MGP

Dentro do projeto DiSEN so tratados os estados de acordo com cada objeto existente no ambiente (HUZITA, 2004)1. A seguir so descritos os objetos e seus estados correspondentes:

Recurso Material: 1. Disponvel: se for software, est com a licena para utilizao e se for hardware ou material de consumo, existe dentro da organizao e pode ser utilizado; 2. No disponvel: se for software, no possui licena para utilizao e se for hardware ou material de consumo, acabou, foi emprestado ou no serve mais para utilizao. Quando o gerente de projeto escolhe um processo e define as atividades do projeto, ele associa tipos de recurso material necessrios para o projeto. O gerente local dever ento observar os tipos de recurso material necessrios para fazer a devida associao ao projeto. Se a quantidade liberada no estiver de acordo com o necessrio ao projeto, o gerente de projeto deve solicitar mais recursos ao gerente local.

Steinmacher, Igor. Relatrio de Pesquisa do Projeto DiSEN.

138

O gerente local dever saber se o recurso material est ou no disponvel para proceder com o licenseamento ou a compra de mais recursos materiais.

Usurio: 1. Disponvel: est trabalhando para a organizao; 2. No Disponvel: no est trabalhando para a organizao por motivos pessoais ou falecimento.

Quem libera os participantes para o projeto o gerente local e o gerente de projeto pode solicitar a liberao de pessoas para trabalhar no projeto. O gerente local dever saber se o usurio est ou no disponvel para trabalhar na organizao pois o responsvel pelo local no qual o usurio est ligado.

Projeto: 1. Em Planejamento. Quando o gerente de projeto lana as informaes do projeto, este o estado inicial. O plano seguido pelo gerente do projeto deve estar programado por meses para que os participantes possam comunicar caso haja algum problema. 2. Em Andamento. Quando o gerente de projeto termina o planejamento, ele altera o estado para em andamento e isso altera o estado das atividades do projeto para em andamento. 3. Suspenso. O gerente de projeto suspende o projeto. Isso repercute no estado das tarefas que compem a atividade. 4. Cancelado. O gerente de projeto cancela o projeto isso deve alterar o estado de todas as atividades do projeto para cancelada. Isso repercute no estado das tarefas que compem a atividade. 5. Concludo. O gerente de projeto conclui o projeto.

Em todos estes casos, os participantes devem receber um comunicado.

AtividadeProjeto: 1. Em Planejamento. O gerente de projeto mantm este estado da atividade at que ela esteja planejada (instanciada). o estado inicial quando se cria a atividadeProjeto. 2. Em Andamento. Quando o gerente de projeto finaliza o planejamento da atividade. (atribuda, paraAntecipar, paraExecutar, Antecipando, executando, abortada). O atribuda ocorre quando o gerente de projeto atribui recursos materiais e usurios para as tarefas que 139

compe a atividade. O paraAntecipar ocorre quando os recursos materiais e usurios esto no estado disponvel e os artefatos necessrios para executar a atividade ainda no esto com estado = resultado final. O paraExecutar ocorre quando os recursos materiais e usurios esto no estado disponvel e os artefatos necessrios para executar a atividade esto com estado = resultado final. O antecipando quando o engenheiro de software inicia uma das tarefas que compe a atividade, quando os recursos materiais e usurios esto no estado disponvel e os artefatos necessrios para executar a atividade ainda no esto com estado = resultado final. O executando quando os engenheiros de software iniciam as tarefas que compe a atividade e todas elas possuem os recursos materiais e usurios no estado disponvel e os artefatos necessrios para executar a atividade esto com estado = resultado final. O abortado existe quando ocorre qualquer problema sem soluo depois dela estar em andamento. 3. Suspenso. O gerente de projeto suspende a atividade. Isso repercute no estado das tarefas que compem a atividade. 4. Cancelado. O gerente de projeto cancela a atividade. Isso repercute no estado das tarefas que compem a atividade. 5. Concludo. O estado automaticamente atualizado quando os engenheiros de software atualizam o estado das tarefas que compem a atividade como concluda. Se ocorrer algum problema em alguma das tarefas (estado=abortada), o gerente de projeto ter de concluir manualmente a atividade.

Tarefa: 1. Aguardando recursos. O estado inicial da tarefa. Fica neste estado enquanto os recursos materiais e os participantes ainda no esto disponveis para executar a tarefa. 2. Em Andamento. (paraAntecipar, paraExecutar, antecipando, executando, abortado). Em todos estes casos, os recursos materiais e usurios esto disponveis. paraAntecipar significa que os artefatos necessrios ainda no esto com estado = resultado final. ParaExecutar significa que os artefatos necessrios esto com estado = resultado final. Antecipando significa que o engenheiro de software iniciou a atividade com um dos estados dos artefatos <> resultado final e Executando significa que ele iniciou a atividade com os estados dos artefatos = resultado final. O abortado existe quando ocorre qualquer problema sem soluo depois dela estar em andamento. 3. Suspenso. O gerente de projeto suspende a atividade. Isso repercute no estado das tarefas que compem a atividade.

140

4. Cancelado. O gerente de projeto cancela a atividade. Isso repercute no estado das tarefas que compem a atividade. 5. Concludo. O Engenheiro de Software conclui a tarefa e disponibiliza o artefato gerado com estado = resultado final.

Participante: 1. Disponvel: est pronto para trabalhar para o projeto; 2. No Disponvel: no est trabalhando para o projeto em particular.

RecursoMaterialTarefa: 1. No definido: a tarefa ainda no possui recursos materiais definidos para sua execuo. 2. Definido: a tarefa j possui recursos materiais definidos para sua execuo. 3. Em uso: a tarefa est fazendo uso do recurso material. 4. Ocioso: a tarefa no est fazendo uso do recurso material. Para saber se o recurso est sendo utilizado basta verificar se a tarefa est sendo executada.

7.5 Consideraes Finais

Neste captulo justificou-se a construo do prottipo e a sua apresentao. O prottipo construdo permitiu validar o MGP proposto por meio da sua apresentao no questionrio aplicado. O captulo 8 descreve mais detalhadamente como foi realizada a validao do MGP. Um framework est sendo construdo pelos integrantes do Projeto DiSEN, o prottipo do MGP aqui apresentado dever ser integrado ao DiSEN utilizando-se do mesmo. J foram criados vrios mdulos que tratam de algumas das classes do diagrama de classes que se encontra no Apndice D. Ao fazer a integrao, todas as funcionalidades devero ser implementadas. O prottipo utilizou a base de dados j existente, criada no banco de dados Postgres, porm, houve necessidade de alteraes e criao de novas tabelas para a apresentao das funcionalidades.

141

CAPTULO VIII Validao do MGP 8.1 Introduo

Apresentam-se neste captulo algumas consideraes sobre a elaborao e aplicao dos questionrios e a sntese dos dados coletados. Trabalho que foi realizado para validar o MGP em questo.

8.2 Elaborao do Questionrio

O questionrio aplicado aos gerentes de projeto foi elaborado para avaliar o MGP apresentado no Captulo 6 e para avaliar o prottipo construdo e que foi apresentado no Captulo 7. O questionrio passou por um pr-teste onde se pde constatar a clareza e objetividade do mesmo. Depois ele pde ser aplicado aos gerentes de projeto. Como j havia sido

realizado um questionrio quando da apresentao da ferramenta DIMANAGER (Pedras, 2003), as mesmas questes puderam ser integradas ao questionrio elaborado para avaliar o prottipo desenvolvido. Como pode ser constatado no Apndice E, no questionrio apresentou-se um resumo do MGP e depois as questes foram divididas em: dados pessoais, dados da organizao e sobre o MGP. Os dados pessoais so importantes para confirmar o universo dos respondentes e, os dados da organizao solicitados deram subsdio para melhorar o MGP pois as questes esclareceram pontos ainda obscuros relativos resoluo de conflitos, a forma como se realiza a distribuio do conhecimento, como um problema resolvido, etc. Foram utilizadas questes do tipo cafeteria que possibilitam que se responda questo com outra resposta eventual, ao contrrio das questes fechadas que apesar de facilitarem a anlise no permitem possveis complementos (MUCCHIELLI, 1978). Tambm foram utilizadas questes abertas para obter informaes adicionais ou complementares.

8.3 Dados sobre as Empresas e sobre os Respondentes

O questionrio foi aplicado em seis instituies, da regio de Maring, sendo: duas pblicas e quatro privadas. O nmero de colaboradores nas instituies est entre 5 e 4500, porm o nmero de colaboradores no desenvolvimento de software est entre 5 e 80. O total 142

de respondentes foi 16. Os questionrios foram respondidos por gerentes ou ex-gerentes da rea de desenvolvimento de software e a Tabela 06 mostra a experincia dos mesmos e a quantidade de projetos gerenciados de cada um. Foi considerado como projeto, cada sistema ou parte de sistema desenvolvido que teve como incio o levantamento de requisitos e a finalizao com a implantao.
Gerentes 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 Experincia em Anos no Desenvolvimento de Sistemas 7 12 5 18 15 8 28 28 28 20 14 20 13 15 25 17 Experincia em Anos em GP 3 5 5 4 3 1 23 28 22 15 14 15 3 5 20 6 Qtde de Projetos Gerenciados 7 7 +10 8 2 2 +10 17 12 10 +10 5 20 12

Tabela 06. Experincia em GP dos Respondentes.

Tivemos 16 respondentes sendo 7 respondentes com experincia em GP entre 1 e 5 anos, 5 respondentes com experincia entre 14 e 17 anos e 4 respondentes com experincia entre 23 e 28 anos. A formao acadmica dos respondentes est distribuda desta forma: onze graduaes em Tecnlogo de Processamento de Dados, uma graduao em Engenharia Civil, duas graduaes em Administrao de Empresas, uma graduao em Informtica, duas graduaes em Cincia da Computao. O total foi 17 pois um deles possui 2 graduaes. A maioria dentre eles possui ps-graduao dividida em: trs especializaes em Gesto Pblica, uma especializao em SI, uma especializao em Anlise de Sistemas, quatro mestrados em Cincia da computao, um mestrado em Engenharia de Produo, dois mestrados em Informtica, um mestrado em Engenharia Eltrica, um mestrado em Gesto de Negcios e dois Masters of Business Administration (MBA) em GP. 143

A experincia e a formao acadmica mostram que os mesmos possuem o conhecimento necessrio para avaliar o MGP proposto. Algumas das questes foram inseridas para entender melhor como as organizaes lidam com o conhecimento, motivao e conflitos e, se utilizam um processo formal de desenvolvimento. As respostas foram teis para o aprimoramento do MGP proposto. Constatou-se que: Trs pessoas trabalham com processo formal de desenvolvimento de software; Quatro pessoas que j trabalharam com DDS; Quatorze pessoas informaram que a organizao resolve seus conflitos com reunies e conversas com os envolvidos e a chefia. Ainda, de acordo com um dos respondentes, os conflitos so resolvidos na seleo dos candidatos para a organizao, com a avaliao do relacionamento pessoal. Esta qualidade est acima do conhecimento tcnico, uma vez que o conhecimento facilmente adquirido, j as questes pessoais so mais difceis. Onze pessoas informaram que os conflitos so resolvidos segundo a hierarquia da organizao. As alternativas que foram apresentadas atenderam aos respondentes nos itens de repasse de conhecimento e resoluo de problemas, nas quais tivemos a seguinte proporo: nove pessoas informaram que o repasse de conhecimento realizado com a utilizao de documentos e manuais e onze pessoas informaram que o repasse do conhecimento realizado por meio da explicao oral dos procedimentos. Um dos respondentes complementou que o repasse de conhecimento realizado pela insero da pessoa nos pares de desenvolvimento. Houve uma boa distribuio sobre como os problemas so resolvidos. A seguir, a Tabela 07 mostra as respostas com o nmero de assinalamentos de cada uma:

Resoluo de Problemas Consulta histrico de projetos passados Busca orientao dos gerentes mais experientes Pesquisa em acervo bibliogrfico Sua experincia Busca orientao de especialistas

Gerentes 07 09 09 11 14

Tabela 07. Total de Respostas sobre a Resoluo de Problemas.

144

Observa-se, pelas respostas obtidas, que: A maioria das organizaes no possui um processo formal de

desenvolvimento, no utilizam DDS; As organizaes resolvem seus conflitos com reunies e conversas com os envolvidos e segundo a hierarquia da organizao; Pode-se realizar a preveno para o rodzio de pessoal possibilitando o trabalho em pares de desenvolvimento; e, Pode-se haver uma seleo de candidatos com a avaliao do nvel de relacionamento pessoal, que vai de encontro ao perfil que a organizao deseja.

8.4 Aceitao do MGP Apresentado

A avaliao do MGP pelos integrantes do DiSEN foi realizada em uma reunio com o grupo diferentemente do que foi inicialmente proposto. A proposta inicial era a aplicao de um questionrio. Acreditamos que a reunio pde avaliar o MGP onde houve a sugesto da incluso das estimativas do projeto por meio da interoperabilidade entre outras ferramentas de estimativas de tempo e custo com a DIMANAGER e tambm o questionamento sobre o cadastro de fornecedores. A sugesto foi aceita e, tambm defendeu-se a utilizao do cadastro de fornecedores para que possamos realizar a avaliao dos mesmos como est descrito no CMMI Staged Nvel 2 (SEI, 2002). Com relao aos dados sobre o MGP proposto no questionrio, obteve-se um retorno bastante positivo e a aceitao dos itens apresentados. A no concordncia de alguns dos respondentes do questionrio aplicado nas empresas se limitou s seguintes questes: Na questo 5 do questionrio onde se prope que o conhecimento adquirido seja distribudo para toda a organizao, 2 dos 16 respondentes acreditam que o repasse do conhecimento deve ocorrer somente nas reas correlatas ou afins. Na questo 7 do questionrio foram apresentados riscos a serem considerados na seleo de projetos a serem desenvolvidos nas unidades distribudas, os quais foram sugeridos por Prikladnicki (2003). A maioria dos riscos considerada importante para os respondentes como se pode ver na Tabela 08. As sugestes dos respondentes de incluso nos riscos a serem considerados na seleo de projetos para as unidades distribudas so: riscos de sincronizao e integrao dos trabalhos distribudos, comunicao entre as equipes, capacidade de comunicao e, custos com viagens. 145

Riscos a serem considerados na seleo de Projetos para as Unidades Administrativas Documentao existente e interao necessria para elaborar a documentao do projeto Clareza e estabilidade dos requisitos Riscos de tecnologia Capacidade de controle gerencial Experincia dos clientes e usurios em projetos distribudos Complexidade e durao (existncia de RH disponveis para integrar a equipe) Tamanho do projeto com relao quantidade de membros na equipe Concentrao de projetos (Sobrecarga de projetos)

Total de Respondentes que no Concordam 1 1 1 0 5 0 0 0

Tabela 08. Totais de No Concordncia com os Riscos na Seleo de Projetos.

Na questo 8 do questionrio, onde so apresentados os riscos para o planejamento de projetos, tambm houve uma grande aceitao como mostra a Tabela 09.
Riscos a serem considerados no Planejamento de Projetos Rotatividade de pessoal Mudana de tecnologia Incerteza nos Custos Incerteza no cronograma Clareza e estabilidade dos requisitos Mudana de gerenciamento Indisponibilidade de hardware Existncia de produto concorrente Treinamento no disponvel Ferramentas CASE inadequadas Total de Respondentes que no Concordam 1 0 2 1 0 2 0 6 2 3

Tabela 09. Totais de No Concordncia com os Riscos no Planejamento de Projetos.

As sugestes dos respondentes para incluso na lista de riscos no planejamento de projetos so: falta de conhecimento do cliente sobre o que deseja no software, falta de especialistas para a elaborao do planejamento e incompatibilidade entre os membros da equipe. Este ltimo deve ser considerado de acordo com o respondente, pois, uma equipe dividida produz menos e com menor eficincia. Na questo 12 do questionrio onde o MGP prope a avaliao das necessidades individuais para se recompensar adequadamente cada participante, um dos respondentes acredita que para se recompensar adequadamente cada um deve-se avaliar somente a competncia e a produtividade. Outro concordou com a avaliao das necessidades

146

individuais mas dentro de um certo limite. E, outro ainda no acredita ser vivel a avaliao pois tornaria a questo complexa demais. Na questo 14 do questionrio, foram apresentadas as mtricas para o MGP e a no concordncia se limitou ao apresentado na Tabela 10.
Mtricas do MGP Pontos por funo Qualidade Produtividade Rodzio de participantes no projeto Tempo ocioso do participante Tempo de espera do participante aguardando recursos e artefatos Facilidade de utilizao do processo de desenvolvimento Ocorrncias do projeto (problemas) Volatilidade dos requisitos Total de Respondentes que no Concordam 0 0 0 3 2 2 0 0 1

Tabela 10. Totais de No Concordncia dos Respondentes com as Mtricas do MGP.

Outras mtricas que os respondentes acreditam ser importantes so: complexidade da tarefa e capacidade de viso do participante para resolver problemas, nmero de atividades ou horas dispensadas para descontrair a equipe ou melhor integr-la, cobertura de casos de teste e, quantidade de use-cases. Na questo 16 do questionrio so apresentados os modelos de documentos presentes no MGP para constatar a adequao dos mesmos para o GP e as respostas mostram o apresentado na Tabela 11. Um dos respondentes ressaltou que cada projeto pode no necessitar de todos os documentos e sim de uma configurao particular e mais adequada.
Modelos de Documentos do MGP Plano do projeto Plano de gerenciamento de riscos Plano de gerenciamento de dados Plano de gerenciamento de stakeholders Habilidades/Conhecimentos/Treinamento dos indivduos Compromisso com os requisitos Solicitao de mudana nos requisitos Relatrio de inconsistncia nos requisitos Recebimento de propostas de fornecedores Avaliao de produtos recebidos e fornecedores Avaliao da organizao Relatrio de lies aprendidas Total de Respondentes que no Concordam 0 0 3 1 3 0 0 0 2 0 2 2

Tabela 11. Totais de No Concordncia com os Modelos de Documentos.

147

A seguir, alguns comentrios dos respondentes sobre as perguntas do questionrio: a) Seria melhor obter a satisfao dos clientes e usurios de forma iterativa e incremental; b) A fase de avaliao e feedback importante durante todo o processo e no s ao final do projeto; c) Em uma das organizaes, dentre as mtricas para avaliar os fornecedores, so usados o bom atendimento e a confiabilidade; d) A criatividade para realizar uma tarefa um fator a ser considerado na seleo da pessoa mais apta a realiz-la; e) A avaliao dos fornecedores deve ser realizada mesmo sem histrico.

Observa-se, pelo apresentado, uma pequena variao em relao s seguintes questes: 1) Os riscos a serem considerados na seleo dos projetos para as unidades distribudas; 2) Os riscos considerados no planejamento dos projetos; 3) As mtricas consideradas; 4) Os modelos de documentos para o GP. Contudo, o MGP apenas sugere o uso dos riscos, mtricas e documentos para a organizao. Cada organizao pode adaptar-se da melhor forma, realizando o cadastro das informaes que deseja controlar como pode ser constatado pelo prottipo apresentado.

8.5 Aceitao do Prottipo Apresentado

Os itens avaliados com relao ao prottipo foram os seguintes: visualizao da ferramenta; utilidade para o GP; manuseio da Ferramenta; e, utilidade para projetos desenvolvidos em locais dispersos geograficamente. Tambm foram feitas sugestes e alguns comentrios foram tecidos durante a apresentao do prottipo. Os itens avaliados, as sugestes e os comentrios esto apresentados a seguir:

Itens Avaliados: 1. Visualizao da Ferramenta: O prottipo foi considerado interessante e bom para uma rpida tomada de deciso e para controlar projetos e a interface foi considerada simples e objetiva. O prottipo foi desenvolvido com clareza e funcionalidade permitindo visualizar bem os mdulos e, alm disso, apresenta um grau de funcionalidade bastante avanado. 148

2. Utilidade para o GP. O prottipo foi considerado de muita utilidade para o GP por: controlar todas as fases do projeto; possibilitar a consulta do andamento do projeto, selecionar as pessoas de acordo com a exigncia dos conhecimentos; reunir os dados necessrios propostos pela metodologia permitindo que o gerente de projeto controle o processo e os integrantes do desenvolvimento do software; apresentar os controles para um projeto ser bem executado; e, interligar as informaes para o gerenciamento. Porm necessita de novas funcionalidades para os nveis superiores, tais como: relatrios de progresso de projetos e anlise de impacto nas alteraes antes da execuo.

3. Manuseio da Ferramenta: O manuseio do prottipo facilita o GP principalmente nas tomadas de deciso por apresentar as funcionalidades reunidas em uma nica ferramenta e pela proposta de integrao com outras ferramentas. O prottipo evita problemas de comunicao entre os membros da equipe, facilita a tomada de deciso e permite o compartilhamento do conhecimento englobando todas as etapas de um GP para desenvolvimento de softwares. Porm, o prottipo exige um trabalho considervel at se iniciar o projeto, por causa da interface que dificulta uma anlise visual imediata e toma tempo para o preenchimento. Portanto, uma interface grfica mais amigvel ser mais objetiva no acompanhamento dos projetos.

4. Utilidade para Projetos Desenvolvidos em Locais Dispersos Geograficamente. O prottipo foi considerado mais til dentro deste contexto por disponibilizar as informaes em todos os locais distribudos, por apresentar o gerenciamento de equipes distribudas e os gerentes locais e, permitir que pessoas participem do projeto independente do local onde estejam. Contudo, como o processo geograficamente distribudo, uma interface web tornaria o acesso muito mais simples e mais fcil para implantao.

Sugestes: 1. A ferramenta foi considerada interessante por trazer benefcios para a organizao que fizer uso da mesma, pois, nesse ambiente onde vivemos, o compartilhamento de processos e solues essencial para a inovao e a competitividade. Porm, a ferramenta deveria usar mais recursos grficos para fornecer informaes consolidadas e objetivas aos nveis superiores pois entendemos que uma ferramenta para GP necessita interfaces para o

149

acompanhamento entre o planejado e o executado e que poderia explorar recursos grficos para isso; 2. Seria interessante implementar o MGP para ser utilizado no ambiente Eclipse que j possui outras ferramentas desenvolvidas, tais como: diagramas UML, ferramentas de codificao e compilao, controladores de repositrios, entre outros. Assim, o grupo poderia se concentrar na evoluo do MGP e menos no desenvolvimento de ferramentas secundrias; 3. Ao ser cadastrado o problema que ocorreu na tarefa, importante informar tambm qual o grau que o problema afeta na produtividade, pois, um problema pode afetar de forma total, parcial ou pode no afetar diretamente a execuo da tarefa. E, ainda com relao ao cadastro de problemas, permitir que o engenheiro de software informe o gerente de projeto mesmo quando ocorre um problema que no est diretamente ligado sua tarefa, mas que poder afetar futuramente outras tarefas. Tambm foi sugerido que ao cadastrar o problema, uma mensagem possa ser disparada para outros dispositivos eletrnicos: e-mail, celular ou outra ferramenta de comunicao; 4. Para o gerente local seria interessante um relatrio que mostre a situao geral do local com base na situao dos projetos e para o gerente local um relatrio com a situao geral da organizao com base na situao de todos os projetos. E, a sinalizao para os gerentes por meio de cores, usando o verde quando est tudo dentro do planejado e vermelho quando se tem um problema grave tornaria mais fcil a visualizao; 5. Testar a ferramenta em ambientes reais de desenvolvimento com caractersticas diferentes como por exemplo em empresas de pequeno, mdio e grande porte e, desenvolvimento centralizado e distribudo.

Comentrios: Apesar das conversas no terem sido gravadas, alguns comentrios feitos pelos respondentes foram muito proveitosos, confirmando a validade do MGP e do prottipo apresentados. Dentre elas podemos citar: O cadastro de problemas pelo desenvolvedor com a imediata cincia do gerente do projeto extremamente til e torna o trabalho mais tcnico evitando que o desenvolvedor precise ligar para o gerente do projeto; O prottipo construdo est de acordo com o controle gerencial em ADDS; Os relatrios gerenciais permitem uma visualizao rpida ao gerente local e ao gerente geral como est o andamento do projeto;

150

A resoluo de problemas onde existe uma diferena de fuso horrio que permita 24 horas de atendimento bastante til; As mtricas so muito importantes para um efetivo GP; A questo da escolha dos participantes para realizar uma determinada atividade realmente um diferencial do MGP apresentado; e, Ter conhecimento sobre o que j foi desenvolvido em termos de implementao evita o re-trabalho, pois, muitas vezes, a pesquisa em busca de solues demorada e, a troca de informaes bastante proveitosa para a organizao em termos de tempo despendido.

8.6 Consideraes Finais

Neste captulo apresentou-se a forma como foi validado o MGP proposto. O retorno obtido com a aplicao do questionrio foi importante para permitir a confirmao da validade do trabalho realizado. Os comentrios tecidos aps a apresentao do prottipo pelos respondentes foram construtivos e bastante estimuladores pois consideraram que ser bastante til para empresas que trabalhem com DDS. Algumas das sugestes dos respondentes contriburam bastante e devem ser incorporadas no ambiente DiSEN. Uma questo a ser considerada a visualizao por uma interface web que, de acordo com 3 dos 16 respondentes, seria melhor permitindo maior facilidade de implantao. Apesar do prottipo desenvolvido no conter todas as funcionalidades no que diz respeito aos relatrios e grficos que podem fornecer mais informaes aos usurios identificados, foi possvel descrever quais os possveis relatrios que poderiam ser implementados com as informaes cadastradas. E, alm disso, alguns deles j foram validados por meio do trabalho desenvolvido por Santiago (2005).

151

CAPTULO IX Consideraes Finais

A presente pesquisa possibilitou elaborar um MGP como contribuio para a melhoria do controle gerencial em ADDS, o qual resultado das reflexes e avaliaes realizadas nos modelos existentes e, de questes ligadas ao DDS. E, tambm possibilitou apresentar material organizado e resumido sobre GP na reviso bibliogrfica. Tambm permitiu algumas reflexes com respeito validao do trabalho realizado. Notadamente, o GP engloba fatores tcnicos e humanos. Um bom gerente de projetos deve considerar estes fatores, conhecer as ferramentas e tcnicas que podem ser utilizadas para planejar e controlar o projeto e motivar e direcionar a equipe do projeto e, ainda, cabe a ele solucionar os problemas e utilizar a ferramenta e tcnica mais adequada para cada ocasio. No desenvolvimento de software onde no existe distribuio fsica dos membros da equipe a preocupao em cadastrar informaes para a comunicao entre os participantes do projeto menor, pois, os membros se encontram no mesmo local e esta questo pode ser resolvida com o contato direto com o gerente do projeto. J, no DDS, existe a necessidade da formalizao do processo e na comunicao entre os membros da equipe para conseguir gerenciar o projeto, sendo que, o ideal ter um ambiente de desenvolvimento que permita o GP. Este trabalho apresenta um MGP e por estar inserido no projeto DiSEN, culminou com a construo de um prottipo que dever ser integrado ao mesmo proporcionando uma viso geral dos fatores que devem ser levados em conta para gerenciar o DDS.

9.1 Aspectos sobre o MGP

9.1.1 Contribuies do MGP
A pesquisa realizada buscou atingir os objetivos do Item 1.3.2. e como principal contribuio deste trabalho tem-se a criao de um MGP para DDS e como contribuio adicional tem-se o aprimoramento da ferramenta DIMANAGER para o DiSEN. O MGP desenvolvido apresenta um prottipo e informaes a serem cadastradas para um controle gerencial em ADDS que complementa a ferramenta j existente, trazendo novas funcionalidades que foram baseadas em modelos consagrados como o modelo processual do PMI e o CMMI , o que aumenta a probabilidade de se realizar um efetivo GP.

152

Outra contribuio, para a comunidade cientfica a consolidao das questes ligadas ao DDS no MGP, o que permite aos interessados em DDS um material organizado para pesquisa. E, ainda, aps a integrao do prottipo e outros trabalhos no DiSEN, o ambiente como um todo, servir como apoio no controle gerencial do DDS das organizaes que optarem pela sua utilizao, pois, com a crescente necessidade das empresas de ganhar competitividade no mercado, preciso utilizar todos os recursos existentes para obter maiores lucros e utilizar melhor os RH e materiais. Durante o trabalho realizado para o DiSEN, foi possvel uniformizar os termos utilizados em vrios trabalhos onde existiam diferentes termos com igual significado melhorando assim a comunicao entre os membros da equipe. A pesquisa realizada permitiu apresentar de forma mais detalhada as questes de DDS j levantadas anteriormente por outros trabalhos, possibilitando assim um progresso de forma geral nos trabalhos realizados. Resumindo, as contribuies do trabalho so: Indicao de um caminho a seguir para as empresas que optem pelo DDS, focando-se nos problemas que surgem neste tipo de desenvolvimento de software; Aprimoramento do DiSEN com a incluso de novas funcionalidades na DIMANAGER; Material organizado relativo ao GP em ADDS para os interessados nesta rea.

9.1.2 Aprimoramento da DIMANAGER no DISEN

medida que o projeto DiSEN est sendo executado e cada novo trabalho dentro do projeto finalizado, caminha-se para o aprimoramento do ambiente que est sendo construdo. Particularmente, o presente trabalho contribui com os seguintes elementos na ferramenta DIMANAGER: Gerenciamento dos Stakeholders: no qual existe a avaliao de fornecedores e dos clientes; Gerncia do Conhecimento: no qual existe a preocupao com compartilhar o conhecimento e mant-lo na organizao fazendo-se o devido armazenamento para posteriores consultas; Propriedade Intelectual: no qual existe a preocupao em restringir o acesso dos dados somente aos interessados; 153

Mtricas: no qual existe o armazenamento das mtricas que so essenciais para conhecer os projetos e a organizao; Estimativas: no qual existe a estimativa de esforo-hora e de custo do participante; Gerncia de Riscos: no qual existe o cadastramento dos riscos para seu acompanhamento; Avaliao das Necessidades Individuais: no qual est previsto o uso de um questionrio para avaliao das necessidades individuais para melhor conhecer o participante. O uso de questionrios j est previsto no trabalho de Lima (2004) e de Curioni (2005).

9.2 Restries do MGP

As restries sobre o MGP proposto envolvem questes relativas interdisciplinaridade com reas afins. O GP com DDS uma rea de interseco entre vrias disciplinas e, em especial, da disciplina de Cincia da Computao com a disciplina de Administrao, Psicologia e Direito. Sem dvida, gerenciar um projeto administr-lo. O MGP depende de profissionais ligados a estas reas para: fornecer assistncia jurdica no caso da disciplina de Direito e para a aplicao de questionrios que viabilizem o estudo psicolgico das pessoas da organizao, no caso da disciplina de Psicologia. E, como observado por Tait et al (1997A apud Tait ,2000) e Zago (2000 apud Tait, 2000), a rea de administrao e de psicologia possuem estudos sobre a cultura organizacional e, podem contribuir com suas reflexes para o sucesso dos projetos.

9.3 Sobre a Validao do MGP

Uma das limitaes da validao refere-se ao nmero de questionrios respondidos pelos gerentes de projeto. Porm, os mesmos possuem larga experincia em GP o que proporciona uma segurana a respeito da qualidade das informaes recebidas. Os problemas encontrados na aplicao dos questionrios se resumem a: Falta de locais onde aplicar os questionrios; e, Falta de tempo dos respondentes.

A seleo dos locais ficou restrita regio de Maring onde no se encontrou empresas que trabalhem com DDS. A falta de tempo dos respondentes prejudicou em parte a validao, pois, apesar da apresentao do prottipo, alguns dos gerentes no tiveram tempo para responder o questionrio at o prazo estipulado para a entrega deste. 154

Futuramente, um estudo de caso com a utilizao do DiSEN para captar as lies aprendidas tornaria a validao mais completa.

9.4 Pesquisas Futuras

Os itens colocados a seguir so viveis para aprimorar o DiSEN:

Implementao da Ferramenta de Apoio ao GP no DiSEN A arquitetura do DiSEN (PASCUTTI, 2002) j prev a utilizao de agentes. Especificamente, para a ferramenta de GP, percebe-se a viabilidade na utilizao de agentes de software para a coleta das mtricas apresentadas no MGP proposto para auxiliar o GP (PAES e ALMEIDA, 2005). Na implementao de uma ferramenta desse tipo, alm do apresentado no Captulo 7, deve-se considerar: (1) A possibilidade de incluso de problemas no projeto que no esto ligados a uma tarefa. Muitas vezes, os desenvolvedores verificam a necessidade de resolver um problema que no est afetando diretamente a sua tarefa mas, que se no for resolvido afetar futuramente a sua tarefa ou de outro participante; (2) A confeco de relatrios para os gerentes locais e para o gerente geral para uma visualizao rpida do andamento dos projetos sob a responsabilidade de cada um. Um grfico de gantt com a substituio das atividades pelos projetos seria interessante; De forma geral, buscar outros relatrios focados no gerente local e gerente geral como por exemplo um relatrio com informaes dos RH e materiais existentes em cada local distribudo o que importante para se tomar a deciso de qual unidade est melhor preparada para o desenvolvimento de determinado software ou componente.

Mecanismo de Apoio ao Gerenciamento de RH Com relao ao mecanismo de apoio ao gerenciamento de RH (LIMA, 2004), que auxilia o gerente de projeto a selecionar a pessoa mais apta para executar uma atividade do projeto, aps uma anlise do trabalho de Barreto (2004), prope-se incluir opes que possibilitem ao gerente de projeto: (1) Buscar a pessoa mais apta para realizar o trabalho e que esteja dentro do oramento, colocando-se prioridades nas funes em que deseje mais aptido; (2) Realizar uma pesquisa no repositrio de RH para saber se necessrio um determinado treinamento para realizar um projeto especfico; 155

(3) Selecionar atividades para as pessoas que desejam trabalhar com atividades diferentes da que esto acostumadas a realizar. Muitas vezes, as pessoas esto cansadas de executar as mesmas atividades e precisam de novos desafios. Alm disso, para a escolha do gerente de projetos e gerente local, tambm necessrio fazer uma anlise de quais conhecimentos e habilidades eles devem possuir para exercer essas funes. Por exemplo, o gerente local deve ter habilidade e conhecimento em liderana, lngua e cultura dos participantes do local e dos demais gerentes locais do projeto e dos gerentes de projeto para obter uma boa comunicao entre os mesmos.

Processo de Avaliao Pessoal A apresentao de uma avaliao realizada automaticamente pela ferramenta DIMANAGER relacionada s tarefas que cada participante realizou permite que cada indivduo avalie a sua prpria performance podendo melhor-la por meio do recebimento de informaes relevantes. Isso estaria em conformidade com o apresentado no PSP. Outro item que pode ser trabalhado permitir que cada participante indique em sua rea de trabalho, qual a sua disposio respondendo a pergunta: Como se sente hoje? Para que os participantes tenham uma idia da melhor forma de se comunicar com o mesmo. Isso pode ser usado pela organizao para identificar se os funcionrios, de forma geral, esto satisfeitos, ou precisa de atividades de relaxamento ou atividades fsicas para melhorar o seu estado e consequentemente o seu desempenho. Tambm, o prprio funcionrio pode pela consulta dos seus estados, conhecer a si mesmo sabendo que em determinado horrio est mais bem humorado e mais comunicativo.

Gesto por Competncia Atualmente, as organizaes esto passando por transformaes na gesto de RH para incorporar o conceito de gesto por competncia, pois, as pessoas com suas habilidades, aptides, conhecimentos e atitudes so o alicerce da organizao. O foco dessa gesto a competncia que mostra o quanto cada indivduo consegue colocar em prtica sobre determinado contexto. Para que seja possvel medir objetivamente o desempenho so realizadas avaliaes de desempenho. A gesto por competncia uma rea bastante ampla para estudo, e, existe uma forte interdisciplinaridade com a rea de psicologia. A psicologia possui estudos sobre vrios mtodos de avaliao de desempenho que so importantes para que as organizaes desenvolvam os recursos humanos da organizao. 156

Distribuio dos Dados dos Projetos Verificao da necessidade de manter os dados detalhados dos projetos separados dos dados gerais do projeto, como proposto por Desouza e Evaristo (2004). Os dados gerais de cada projeto estariam armazenados em um nico local e serviriam como um ndice para acessar os dados detalhados de um projeto que estariam no local mais apropriado para que o trfego de informaes entre os participantes do projeto seja minimizado.

Aprimoramento do Gerenciamento de Riscos Seria bastante til o aprimoramento do gerenciamento de riscos, fornecendo uma ferramenta automatizada para realizar clculos como o de sobrecarga de projetos do Modelo MuNDDoS e tambm para atender ao nvel 3 do CMMI que possui objetivos e prticas para o gerenciamento de riscos. Tambm, o estabelecimento dos riscos pode ajudar na estimativa de custos do projeto (NITTA, 2005).

Matriz de Rastreamento de Requisitos A anlise e incluso da matriz de rastreamento de requisitos e do clculo da mtrica de volatilidade nos requisitos no ambiente DiSEN utilizando-se dos diagramas e documentao da ferramenta REQUISITE (BATISTA, 2003) e/ou a interoperabilidade com outra ferramenta que j fornea esse servio conforme mencionado no Item 6.5.

Outros Nveis do CMMI Staged no DiSEN Neste trabalho estudou-se o nvel 2 do CMMI Staged para o aprimoramento do DiSEN. Restam, ainda, outros 3 nveis: nvel 3-Definido, nvel 4-Quantitativamente Gerenciado e nvel 5-Otimizado para serem estudados trazendo melhorias para o controle gerencial no DiSEN, criando-se uma verso do ambiente para cada nvel tratado.

Sistema de Conhecimento em GP Um trabalho interessante seria criar um banco de dados para coletar os dados histricos dos projetos com o objetivo de criar um sistema de conhecimento em GP. Inicialmente, poderia ser realizado um trabalho como o de Strafacci (2001), no qual so definidos: valores para os vrios estados no projeto (inicial, intermedirios e final); valores de impacto que cada natureza de ocorrncia (tcnica, administrativa, financeira ou humana) pode causar nas outras; e, valores para as informaes recebidas (correta, boa ou ruim). Na medida 157

em que as ocorrncias so registradas, o sistema gera automaticamente os valores de estado atualizados para o dia em que houve a ocorrncia. O gerente pode ento analisar a variao que ocorreu sobre o que foi planejado (estado anterior) e o que foi executado (estado atual) e tomar as devidas aes corretivas, se necessrio. Uma ao corretiva cadastrada como uma nova ocorrncia, mas, com impacto positivo. O armazenamento de mtricas como as utilizadas nesta metodologia, permite a visualizao do histrico do projeto e futuramente, pode gerar um sistema de conhecimento em gerncia de projetos que auxiliar o gerente a tomar decises nos projetos.

158

REFERNCIAS BIBLIOGRFICAS
BARRETO, A. S. Apoio Deciso Gerencial na Alocao de RH em Projetos de Software. In: Simpsio Brasileiro de Qualidade de Software, 3, 2004, Braslia. Anais... Braslia:Universidade Catlica de Braslia, 2004. 1 CD-ROM. BATISTA, S. M. Uma Ferramenta de Apoio Fase de Requisitos da MDSODI no Contexto do Ambiente DiSEN. 2003. 93 f. Dissertao (Mestrado em Informtica) - Departamento de Informtica. Maring-Pr: Universidade Estadual de Maring/Universidade Federal do Paran, Maring, 2003. BOOTH, W.C.; COLOMB, G.G.; WILLIAMS J.M.; A Arte da Pesquisa. So Paulo: Editora Martins Fontes, 2000. 351 p. CLELAND D. I.; IRELAND L. R. Gerncia de Projetos. 2.ed. Rio de Janeiro: Reichmann & Affonso Editores, 2002. 324 p. COREY, M. et al. Oracle 8i Data Warehouse. So Paulo: Editora Campus, 2001. p.87-116. CURIONI, S. R. Aspectos Psicolgicos e Administrativos no Mecanismo de Apoio ao Gerenciamento de RH 2005. 48 f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) - Departamento de Informtica. Universidade Estadual de Maring, Maring, 2005. CURTIS, B; REFLEY, B.; MILLER, S. People Capability Maturity Model. Version 2.0. Technical Report CMU/SEI-2001-MM-01. Carnegie Mellon University, 2001. Disponvel em <http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01mm001.pdf>. Acesso em: 30 jan. 2005. DESOUZA, K. C.; EVARISTO, J.R. Managing Knowledge in Distributed Projects. Communications of the ACM, New York, v. 47, n. 4, p. 87-91, abr. 2004. DINSMORE, P. C. Gerncia de Programas e Projetos. So Paulo: Editora Pini, 1992. 176 p. ENAMI, L.N.M; HUZITA E.H.M; TAIT T.F.C. Um Modelo de Gerenciamento de Projeto para um Ambiente de Desenvolvimento Distribudo de Software. In: INTERNATIONAL CONFERENCE ON ENTERPRISE INFORMATION SYSTEMS, 8., 2006, Paphos-Cyprus. Proceedings... Porto-Portugal: ICEIS Press, 2006. p.382-387. FENTON N.E., PFLEEGER S.L. Software Metrics: A Rigorous & Practical Approach. 2 ed. Boston-EUA: PWS Publishing Company, 1997. 638 p. FERREIRA, A.G.G. Gesto de Portfolio de Projetos de TI - Conceitos, Dinmica & Recomendaes na sua Implantao. In: CONGRESSO INTERNACIONAL DE GESTO DE TECNOLOGIA E SISTEMAS DE INFORMAO, 1, 2004, So Paulo. Anais...So Paulo:Editora Pearson, 2004. FORAY, D.; GAULT F. Measurement of Knowledge Management Practices. Paris: OECD Publications Service, 2003. 224 p. 159

FOWLER, M.; SCOTT, K. UML Distilled. 2.ed., New Jersey: Addison Wesley, 2000. 185 p. GOTEL, O. C. Z. Contribution Structures for Requirements Traceability. 1995. 354 f. Tese (Doutorado em Filosofia) Faculty of Engineering of the Department of Computing. University of London, London, 1995. GKN AEROSPACE. Follow-the-sun Engineering. Disponvel em http://www.ukes.aerospace.gknplc.com/aesinternet/follow_the_sun_engineering.html>. Acesso em 10/01/2006. <

GRAVENA, J. P. Aspectos Importantes de uma Metodologia para Desenvolvimento de Software com Objetos Distribudos. 2000. 79 f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) - Departamento de Informtica. Universidade Estadual de Maring, Maring, 2000. HERZBERGS Motivation-Hygiene Theory. Disponvel <http://www.netmba.com/mgmt/ob/motivation/herzberg/>. Acesso em 04/08/2006. em

NIENABER, R.; CLOETE, E. A software Agent Framework for the Support of Software Project Management. In: ACM INTERNATIONAL CONFERENCE PROCEEDING SERIES, 2003, South Africa. Procedings..., South Africa, South African Institute for Computer Scientists and Information Technologists, 2003. p.11-23. HUZITA, E.H.M. MOOPP - Uma Metodologia para Auxiliar o Desenvolvimento de Aplicaes para Processamento Paralelo. 1995. Tese (Doutorado) - Escola Politcnica. Universidade de So Paulo, So Paulo, 1995. HUZITA. E.H.M. Uma Metodologia para o Desenvolvimento Baseado em Objetos Distribudos Inteligentes. Projeto de pesquisa (CNPq), Universidade Estadual de Maring. Departamento de Informtica, 1999. HUZITA. E.H.M. Suporte Reutilizao em Ambientes Distribudos de Desenvolvimento de Software. Projeto de pesquisa em desenvolvimento (CNPq), Universidade Estadual de Maring. Departamento de Informtica, 2004. HUZITA, E.H.M. et al. DIMANAGER: A Tool for Distributed Software Development Management. In: INTERNATIONAL CONFERENCE ON ENTERPRISE INFORMATION SYSTEMS, 6., 2004, Portugal. Anais... Porto-Portugal: Kluwer, 2004, p.659-662. JACOBSON, I; BOOCH, G.; RUMBAUGH, J. The Unified Software Development Process, New Jersey-EUA: Addison Wesley, 1999. 463 p. JILUDWIG. Disponvel em: <http://www.jiludwig.com/ Traceability_Matrix_Structure. html>. Acesso em 15/09/2005. JOHNSTON C. P. Planning User Documentation A Guide for Software Project Managers. Disponvel em http://www.cherryleaf.com . Acesso em 15/08/2005.

160

LIMA, F. Mecanismo de Apoio ao Gerenciamento de RH no Contexto de um Ambiente Distribudo de Software. 2004. 115 f. Dissertao (Mestrado em Cincia da Computao). Universidade Estadual de Maring, Maring , 2004. LUPI, A. L. P. B. Proteo Jurdica dos Direitos de Propriedade Intelectual sobre Softwares: Eficcia e Adequao. 1997. 57f. Trabalho de Concluso de Curso (Graduao em Direito) Departamento de Direito. Universidade Federal de Santa Catarina, Florianpolis,1997. MAXIMIANO, A.C.A. Administrao de Projetos: Como Transformar Idias em Resultados. 2.ed. So Paulo: Atlas, 2002. 281 p. MCMAHON P. E. Distributed Development: Insights, Challenges, and Solutions. Crosstalk: The Journal of Defense Software Engineering, p. 4-9, nov. 2001. MENS, T.; DEMEYER, S. Future Trends in Software Evolution Metrics. In: INTERNATIONAL WORKSHOP ON PRINCIPLES OF SOFTWARE EVOLUTION, 4, 2001, Vienna-Austria. Procedings..., New York, ACM Press, 2001. p. 83-86. MUCCHIELLI, R. O Questionrio na Pesquisa Psicossocial. So Paulo: Martins Fontes, 1978. 176 p. NIENABER, R.; CLOETE, E. A Software Agent Framework for the Support of Software Project Management. In: ACM INTERNATIONAL CONFERENCE PROCEEDING SERIES, 2003, South Africa. Procedings..., South Africa, Meghan-Kifer Press, 2003. p.1623. NITTA, C. Desenvolvimento de Um Componente de Estimativa de Custos para a Ferramenta DIMANAGER. 2005. 47 f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) - Departamento de Informtica. Universidade Estadual de Maring, Maring, 2005. OLSON J.S.; OLSON, G.M. Culture Surprises in Remote Software Development Teams. ACM Queue, New York, v. 1, n. 9, p. 52-59, dec./jan. 2003-2004. PAES, R. B., ALMEIDA, H. O. Agentes e Mtricas no Processo de Desenvolvimento de Software em Equipes Distribudas. Journal of Computer Science, Universidade Federal de Lavras, v.4, n.2, p. 53-62, jun. 2005. PASCUTTI, M.C.D. Uma Proposta de Arquitetura de um Ambiente de Desenvolvimento de Software Distribudo Baseado em Agentes. 2002. 102 f. Dissertao (Mestrado em Cincia da Computao) - Instituto de Informtica. Universidade do Rio Grande do Sul, Porto Alegre, 2002. PEDRAS, M. E. V. Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de Software Distribudo. 2003. 91 f. Dissertao (Mestrado em Informtica) - Departamento de Informtica. Maring-Pr: Universidade Estadual de Maring/Universidade Federal do Paran, Maring, 2003.

161

PEREIRA D.W.S. et al. Anlise Postmortem em Projetos de Software. In: SIMPSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 3., 2004, Braslia. Anais... Braslia:Universidade Catlica de Braslia, 2004. 1 CD-ROM. PMIa. Conjunto de Conhecimentos em GP, 3.ed., Pennsylvania: Project Management Institute Publications, 2004. 388 p. PMIb. Organizational Project Management Maturity Model. Pennsylvania: Project Management Institute Publications, 2004. POWELL, A.; PICCOLI G.; IVES, B. Virtual Teams: A Review of Current Literature and Directions for Future Research. ACM SIGMIS Database, New York, v. 35, n.1, p. 6-36, fev. 2004. PRESSMAN, R. S. Engenharia de Software. So Paulo: Makron Books, 1995. 1056 p. PRESSMAN, R. S. Software Engineering: A Practtioners Approach. 5. ed. New York: McGraw-Hill, 2001. 860 p. PRIKLADNICKI, R. MunDDoS: Um Modelo de Referncia para Desenvolvimento Distribudo de Software. 2003. 143 f. Dissertao (Mestrado em Cincia da Computao) Faculdade de Informtica. Pontifcia Universidade Catlica do Rio Grande do Sul, Porto Alegre, 2003. PRIKLADNICKI et al. Um Caso Prtico de Implantao da Gerncia de Risco em ADDS baseado no Modelo CMMI. In: SIMPSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 4., 2005, Porto Alegre-RS. Anais... Pontifcia Universidade Catlica do Rio Grande do Sul, 2005. p.95-102. RABELLO, A. et al. Analisando a Interao entre Desenvolvedores em Ambientes de Processo de Software: Classificao e Exemplos. VII Semana Acadmica, Universidade Federal do Rio Grande do Sul, 2001. ROYCE, W. Software Project Management: A Unified Framework. Massachusetts: Addison Wesley, 1998, 406 p. SANTIAGO, G. P. Gerao de Informaes Gerenciais para a Tomada de Deciso com a Utilizao da Ferramenta DIMANAGER. 2004, Trabalho de Concluso de Curso (Graduao em Cincia da Computao?) - Departamento de Informtica. Maring-Pr: Universidade Estadual de Maring, 2004. SEI. Software Engineering Institute. CMU/SEI-2002-TR-011-Capability Maturity Model Integration, version 1.1, Staged Representation. Disponvel em <http://www.sei.cmu.edu/>. Acesso em 15/04/2005. SHTUB, A.; BARD, J.F.; GLOBERSON, S. Project Management: Engineering, Technology and Implementation. Englewood Cliffs-New Jersey-EUA, Prentice-Hall, 1994, p. 41-58.

162

SMITE, D. Global Software Development Project Management Distance Overcoming. In: EUROPEAN CONFERENCE, 11., 2004, Trondheim-Noruega. Procedings..., Trondheim, EUROSPI Springer, 2004, p.23-33. SOMMERVILLE, I. Engenharia de Software. So Paulo-SP, Addison Wesley, 2003. STRAFACCI, V. J. Uma Metodologia de Gesto para o Desenvolvimento de Software. 2001. 348 f. Tese (Doutorado em Cincia de Engenharia Eletrnica e Computao). Instituto Tecnolgico de Aeronutica, So Jos dos Campos, 2001. SYKES, J. The Three-Continent: 24 hour help-desk: An Academic First? Disponvel em <http://www.educause.edu/ir/library/pdf/eqm0219.pdf> , 2002. Acesso em 10/01/2006. TAIT, T. F. C. et al. Um Modelo de Arquitetura de Sistemas de Informao para o Setor Pblico: Estudo em Empresas Estatais Prestadoras de Servios de Informtica. 2000. 263 f. Tese (Doutorado em Engenharia de Produo). Universidade Federal de Santa Catarina, Santa Catarina, 2000. THAYER, R. H. Software Engineering Project Management. 2. ed. California: IEEE Computer Society Press, 1997. 531 p. TWO Factor Theory. In: Wikipdia: a enciclopdia livre. Disponvel <http://en.wikipedia.org/wiki/Two_factor_theory >. Acesso em: 04 ago 2006. VALERIANO, D. Moderno GP. So Paulo-SP, Prentice Hall, 2005. 254 p. YIN, R. K. Estudo de Caso: Planejamento e Mtodos. 3. ed., Porto Alegre, Bookman, 2005. 212 p. ZANONI, R. Modelo de Gerncia de Projeto baseado no PMI para Ambiente de Desenvolvimento de Software Fisicamente Distribudo. 2002. 131 f. Dissertao (Mestrado em Cincia da Computao) - Faculdade de Informtica. Pontifcia Universidade Catlica do Rio Grande do Sul, Porto Alegre, 2002. ZHU X., GAUCH S. Incorporating Quality Metrics in Centralized/Distributed Information Retrieval on the World Wide Web. In: International ACM SIGIR Conference on Research and Development in Information Retrieval, 23., 2000, Athens-Greece. Proceedings..., New York, ACM Press, 2000. p. 288-295. em:

163

APNDICE A QUESTIONRIO PARA UMA AVALIAO DAS NECESSIDADES DOS PARTICIPANTES DO PROJETO
Nome: Cargo: Data Admisso: Dependentes: Nome

Parentesco

Data Nascimento

1. Assinale qual o tipo de bens que possui. ( ) Casa/Apartamento prpria(o) ( ) Carro ( ) Moto 2. Assinale onde realiza a maior parte de suas refeies? ( ) Casa/Apartamento prpria(o) ( ) Restaurante ( ) Refeitrio 3. Acredita que sua alimentao adequada conforme a tabela apresentada? ( ) Sim, sempre ( ) A maioria das vezes ( ) No 4. Possui plano de sade? ( ) Sim ( ) No

5. O seu salrio est condizente com o mercado de trabalho em sua cidade? ( ) Sim ( ) No 6. Enumere os fatores que motivam voc a trabalhar nesta organizao em ordem de prioridade. ( ) Salrio bom ( ) Possibilidade de crescimento profissional ( ) Treinamento e desenvolvimento ( ) Estabilidade ( ) Liberdade no trabalho com relao ao horrio e a forma de realizar o trabalho ( ) Status 7. Enumere os itens por ordem de prioridade determinando qual o tipo de recompensa preferiria. ( ) Valor Monetrio ( ) Dias de Folga ( ) Viagens pagas ( ) Subir Nvel de Cargo 8. Qual o tipo de liderana prefere? ( ) Mais Flexvel ( ) Mais Autoritria ( ) Mais Participativa 164

APNDICE B FUNCIONALIDADES NECESSRIOS PARA O GP

I. REQUISITOS FUNCIONAIS

RELATRIOS

De acordo com os trabalhos de Pascutti (2002), Pedras (2003) e Lima(2004), o sistema de GP deve permitir: 1. O Gerenciamento do Workspace (Pascutti, 2002). 2. O Gerenciamento da Configurao Dinmica, o Gerenciamento de Agentes e a Definio da Regio de Agente (Pascutti, 2002). Ver trabalho da Fabiana parte de agentes. 3. O Cadastramento de Recursos contendo os seguintes atributos: Identificao do Recurso, Nome do Recurso. Para recursos materiais, ainda sero necessrios os seguintes atributos: Descrio, Verso, Fabricante, Configurao, Custo, Estado e Tipo do Recurso (Ferramenta de Modelagem de Requisitos, Servidor de Banco de Dados, etc. Ex.: O Rational Rose um recurso do tipo Ferramenta de Modelagem de Requisitos). Para RH ou Usurios, ainda sero necessrios os seguintes atributos: Identificao do Usurio, Login, Senha, Endereo eletrnico, Custo por Hora de Trabalho, Disponibilidade (Quantidade de horas que vai estar disponvel para trabalhar), Estado (Ver diagrama de estado do recurso), Nvel de Afinidade que o usurio tem com relao a outros usurios, Identificao do Local do Usurio, Funo dentro da hierarquia do projeto. Obs: Os atributos: Funo e Setor que foram propostos por Pedras (2003) para RH no sero criados pois ser utilizado o perfil do usurio para selecionar a pessoa que ir executar a atividade ao invs da funo e, o setor no ser necessrio para as atividades de gerenciamento pois existe a informao do local do usurio. 4. O Cadastramento de Locais contendo os seguintes atributos: Identificao do Local, Nome do Local, Localizao, Identificao dos Recursos Materiais do Local e Quantidade e Quantidade Utilizada dos Recursos Materiais existentes no Local. 5. O Cadastramento de Perfis contendo os seguintes atributos: Identificao do Perfil, Nome do Perfil, Descrio do Perfil, Tipo do Perfil (Habilidade, Treinamento ou Conhecimento) e qual o nvel do Perfil. 165

6. O Cadastramento do Perfil do Usurio contendo os seguintes atributos: Identificao do Usurio, Identificao do Perfil , Data e Nvel (0:No tem Afinidade a 5:bastante Afinidade). 7. O Cadastramento de Processos contendo os seguintes atributos: Identificao do Processo, Nome do Processo, Verso do Processo e Descrio do Processo. Neste item deve-se permitir o cadastramento da MDSODI (Metodologia de Desenvolvimento de Software Distribudo) que o processo desenvolvido por Gravena (2000). 8. O Cadastramento das Fases do Processo contendo os seguintes atributos: Identificao da Fase, Nome da Fase e Descrio da Fase. 9. O Cadastramento das Atividades das Fases do Processo contendo os seguintes atributos: Identificao da Atividade, Nome da Atividade, Descrio da Atividade, Perfil para executar a Atividade (Ex.: 0=pouco conhecimento e 5=expert sobre o assunto), Seqncia das Atividades mostrando a dependncia de artefatos e do workflow e o Tipo de Artefato gerado pela Atividade. 10. O Cadastramento dos Recursos Necessrios para executar a Atividade contendo os seguintes atributos: Identificao da Atividade, Identificao do Recurso, Quantidade Necessria do Recurso para Executar a Atividade. 11. O Cadastramento de Mtricas do Processo e do Produto contendo os seguintes atributos: Identificao da Mtrica, Nome, Objetivo, Justificativa, Unidade de Medida (horas, qtde, pontos de 1 a 10), valor da mtrica, tipo de coleta (manual, automtica) e descrio contendo informaes de quem, quando, como, qual a freqncia de coleta, armazenamento e recuperao e ainda a forma de anlise e aes a serem tomadas. Essas mtricas possuem ligao com processo, fase do processo, atividade do processo, tarefa, projeto, fase do projeto e atividade do projeto. 12. O Cadastramento de Tipos de Artefatos contendo os seguintes atributos: Identificao do Tipo do Artefato, Nome do Tipo do Artefato, Descrio do Tipo do Artefato. 13. O Cadastramento de Arquivos que Compem o Artefato contendo os seguintes atributos: Identificao do Artefato, Identificao dos Arquivos que Compem o Artefato, Nome dos Arquivos que Compem o Artefato, Descrio dos Arquivos que Compem o Artefato, Verso e Estado dos Arquivos que Compem o Artefato. 166

14. O Cadastramento de Artefatos contendo os seguintes atributos: Identificao do Artefato, Nome do Artefato, Descrio do Artefato, Estado do Artefato, o Tipo do Artefato. 15. O Cadastramento de Projetos contendo os seguintes atributos: Identificao do Projeto, Nome do Projeto, Descrio do Projeto, Objetivos do Projeto, Gerente do Projeto, Data Incio Prevista e Fim Prevista do Projeto, Data Incio e Fim do Projeto, Processo Selecionado para o Projeto. 16. O Cadastramento das Atividades do Projeto contendo os seguintes atributos: Identificao da Atividade do Projeto, Data Incio e Fim Prevista da Atividade do Projeto, Data Incio e Fim da Atividade do Projeto. 17. O Cadastramento dos Participantes do Projeto contendo os seguintes atributos: Identificao do Projeto, Identificao do Usurio, Custo por Hora no Projeto. 18. O Cadastramento de Logs (Inicialmente sero considerados como problemas) contendo os seguintes atributos: Identificao do Problema, Tipo do Problema (Tcnico ou Organizacional), Descrio do Problema, Soluo Dada ao Problema. 19. O Cadastramento de Logs(Problemas) que Ocorreram no Projeto contendo os seguintes atributos: Identificao do Projeto, Identificao do Problema, Data em que ocorreu o Problema, Contexto do problema. 20. O Atualizao da Situao do Projeto contendo os seguintes atributos: Identificao do Projeto e Situao do Projeto. 21. O Atualizao da Situao da Atividade do Projeto contendo os seguintes atributos: Identificao do Projeto, Identificao da Atividade e o Estado da Atividade. O estado pode ser visualizado no Item 7.4 (HUZITA, 2004)1. 22. O Agendamento das Atividades do Projeto contendo os seguintes atributos: Identificao da Agenda, Identificao da Atividade do Projeto e Esforo hora Necessrio para Executar a Atividade.

Steinmacher, Igor. Relatrio de Pesquisa do Projeto DiSEN.

167

23. O Agendamento dos Recursos Materiais contendo os seguintes atributos: Identificao da Agenda, Identificao do Recurso Material, Data de Incio e Fim Previstas do Agendamento, Data Incio de Fim do Agendamento. 24. O Agendamento dos RH contendo os seguintes atributos: Identificao da Agenda, Identificao do Usurio, Datas de Incio e Fim Previstas do Agendamento, Datas de Incio e Fim do Agendamento. 25. O Cadastramento de Riscos do Projeto contendo os seguintes atributos: Identificao do Risco, Descrio do Risco, Tipo do Risco (Organizacional, Tcnico, Comunicao), Probabilidade do Risco Ocorrer, Conseqncia em termos de Custo (1 a 10), Conseqncia em termos de Tempo (1 a 10), Descrio do Plano de Contingncia (Aes a serem tomadas caso o risco ocorra), Estado do Risco (pode ocorrer, ocorreu, no ocorreu, eliminado). Obs: Os riscos organizacionais so relacionados s limitaes de pessoal, de entendimento. Os riscos tcnicos so relativos ao mau uso da metodologia de desenvolvimento, falha na integrao pela definio errada da arquitetura. Os riscos de comunicao envolvem problemas com a infra-estrutura usada na comunicao entre os integrantes da equipe, discusses mal interpretadas, idias mal formuladas. 26. O Cadastramento de Fornecedores contendo os seguintes atributos: Identificao do Fornecedor, Nome do Fornecedor, Localizao Geogrfica, Observao (Descontos, Habilidades especiais, fornecedor desde quando, etc.). 27. O Cadastramento de Clientes contendo os seguintes atributos: Identificao do Cliente, Nome do Cliente, Localizao Geogrfica, Produto Fornecido, Nmero de Contratos realizados com o Cliente, Observao (cliente desde quando). 28. O Cadastramento de Conhecimentos contendo os seguintes atributos: Identificao do Conhecimento, Data Cadastramento, Palavras-chave, Descrio do conhecimento. 29. O Cadastramento das Aptides dos Usurios contendo os seguintes atributos: percentagemNO, percentagemSO, percentagemNE, percentagemSE,

percentagemNONE, percentagemSOSE, percentagemNOSO, percentagemNESE. Isso permite a identificao de fatores para promover a diversidade da equipe do projeto e a escolha dos indivduos mais aptos a executar as atividades. 168

30. A Interoperabilidade entre Ferramentas Externas e Internas. Isso deve ser realizado pela adequao das ferramentas externas estrutura do DiSEN.

Gerao de diversos tipos de relatrios, grficos e consultas

De acordo com Pedras (2003) e Santiago (2004), o sistema de GP deve permitir a impresso ou consulta: 31. Dos participantes de um projeto, contendo as seguintes informaes: Fase do Processo, Atividade, Participante responsvel pela Atividade. 32. Dos Logs (Problemas), contendo as seguintes informaes: Identificao do Problema, Tipo do Problema, Descrio do problema e Soluo dada ao Problema. O sistema tambm deve permitir a impresso ou consulta de Problemas de um Projeto Especfico, contendo os dados gerais do projeto alm das informaes anteriores. 33. Do Cronograma de um Projeto Especfico, contendo as seguintes informaes: Dados Gerais do Projeto, Fase do Processo, Descrio da Atividade, Data de Inicio e Fim da Atividade, Situao da Atividade e Artefatos gerados pela Atividade. 34. Do Oramento de um Projeto Especfico, contendo as seguintes informaes: Dados Gerais do Projeto, Fase do Processo, Descrio da Atividade, Data de Inicio e Fim da Atividade, Situao da Atividade e Artefatos gerados pela Atividade, Esforo Horas necessrio para executar a Atividade e Custo para executar a Atividade. 35. De um Relatrio Geral Resumido que permita ao gerente a identificao rpida das dimenses do projeto como complexidade, extenso e quantidade de recursos humanos alocados. As informaes contidas neste relatrio so: nome do Projeto, gerente, data de incio e fim do projeto, quantidade de horas previstas, de participantes, de grupos, de atividades e de problemas. 36. De um Relatrio Geral Detalhado que apresente informaes para uma visualizao rpida sobre a situao atual do projeto e contm as informaes apresentadas no Relatrio Geral Resumido e tambm informaes mais detalhadas como a quantidade de horas trabalhadas, quantidade de atividades atrasadas ou em qualquer outro estado, quantidade de horas previstas, de horas trabalhadas e de atividades em relao aos participantes e grupos, quantidade de problemas e quantidade de horas gastas em problemas. 169

37. De um Relatrio de Projeto que apresente informaes completas sobre a situao de um projeto. Alm das informaes contidas no Relatrio Geral Detalhado, apresenta outras informaes: datas incio e fim de cada uma das fases, quantidade de atividades e problemas de cada uma das fases e informaes completas acerca dos problemas encontrados no projeto, classificando-os pelo seu tipo (tcnico ou organizacional). 38. De grficos que apresentem informaes sobre: participantes, grupos, atividades e problemas, cada um deles separadamente. Os grficos relativos aos participantes contm informaes da quantidade de participantes, quantidade de atividades e quantidade de atividades atrasadas evoluindo ao longo do tempo. Os grficos relativos aos grupos contm informaes da quantidade de grupos, quantidade de atividades, quantidade de atividades atrasadas ao longo do tempo. Os grficos relativos s atividades contm a quantidade de atividades e a quantidade de atividades atrasadas ao longo do tempo e os grficos relativos aos problemas contm a quantidade de horas gastas em problemas ao longo do tempo. E, ainda, para o presente trabalho, ser necessrio que o sistema permita a impresso ou consulta: 39. De um Relatrio de Riscos que apresente todas as informaes sobre os riscos do projeto para uma melhor avaliao dos riscos em ordem de relevncia. Deve-se permitir que se escolha a impresso por classificao: da probabilidade de ocorrer, conseqncia de tempo ou conseqncia de custo, maior probabilidade de ocorrer e maior conseqncia de tempo, maior probabilidade de ocorrer e maior conseqncia de custo. 40. De um Relatrio de Fornecedores com todos os dados permitindo a escolha do servio ou recurso material para impresso ou consulta. 41. De um Relatrio com as Habilidades/Conhecimentos/Treinamentos dos membros da organizao como o do Quadro 05. 42. De um Relatrio com data, horas disponveis e horas planejadas de trabalho de cada participante .

170

TERMO

SIGNIFICADO

Alocar Recurso Artefato Atividade

Determinar data e hora incio e data e hora fim nos quais o recurso estar sendo utilizado. Produto gerado pela execuo de uma atividade. Uma atividade pode gerar um artefato que pode ser composto por vrios arquivos. Atividade que faz parte de um processo. Um projeto ter uma instncia de processo que j ter atividades padro mas caso haja alguma atividade extra, ser adicionada para o processo instanciado para o projeto em questo. Deixar o recurso disponvel para o projeto. O gerente do projeto poder ento buscar os recursos disponveis para o projeto e aloc-los. Conceitos sobre determinado assunto. Representao da previso de execuo das atividades com os prazos de incio e trmino em que devero ser executadas as atividades. Fases referentes ao Processo utilizado para o desenvolvimento do projeto. Gerente responsvel por todos os projetos da organizao. Gerente responsvel por cadastrar os recursos materiais do local, os usurios do local e os processos de desenvolvimento. Gerente responsvel pelo projeto. Capacidade de utilizar um conhecimento. Regio ou unidade administrativa a que pertence o usurio. Qualquer ocorrncia adversa na tarefa do projeto. Todo usurio que faz parte de uma equipe de projeto. Uma habilidades, treinamentos ou conhecimentos do usurio. Problema que ocorreu no projeto. Pode ser de natureza tcnica como uma queda na rede ou de natureza organizacional como a demisso de um participante do projeto. Processo utilizado para o desenvolvimento do projeto (Ex.: RUP, CATALYSIS). Foi utilizado como sinnimo de usurio pois todo recurso humano dentro de um projeto ser um usurio e no teremos usurios que no faam parte dos RH do projeto. Bens que ocupam lugar no espao. Podem ser ferramentas, hardware, software, papel, etc. Estado da atividade ou do projeto. Interessado no projeto que podem ser primrios ou secundrios. Dentre os primrios temos: clientes, fornecedores, membros da equipe do projeto; e, dentre os secundrios temos: famlia, mdia, organizaes profissionais. Aptido adquirida pela participao de curso de aprendizagem. Toda pessoa que ir fazer uso ou fez uso do ambiente DiSEN. rea de trabalho dos participantes do desenvolvimento do software

Atribuir Recurso Conhecimento Cronograma Fase Gerente Geral Gerente Local Gerente de Projeto Habilidade Local Log Participante Perfil Problema

Processo Recurso Humano

Recurso Material Situao Stakeholder

Treinamento Usurio Workspace

171

APNDICE C USE-CASES E DESCRIO DOS USE-CASES DO GERENCIAR PROJETO

Use-Cases

172

173

Descrio dos Use-Cases do Gerenciar Projeto

Caso de Uso: Cadastrar Projeto Gerente Local Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Ps Condies: Quando um projeto for excludo, todos os participantes e recursos relacionados a ele devem ser liberados. Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso de projetos. Curso Normal: Restries de Insero: O nome do projeto deve ser nico. Restries de alterao: O nome do projeto deve ser nico. O Gerente Local deve fornecer um Gerente para o projeto. Restries de excluso: O Projeto s poder ser excludo se ainda nenhum participante iniciou uma atividade do projeto. Se o projeto j foi iniciado ele dever ser cancelado. Cursos Alternativos: A partir deste ponto, com um projeto sendo inserido ou alterado, um Gerente Local pode ativar os casos de uso: Associar Recurso Material Projeto, Associar Participante Projeto, Cadastrar Riscos do Projeto. J um Gerente de Projeto poder, caso o projeto esteja sendo alterado: Definir Processo do Projeto, Definir Valor Mtrica Projeto, Cadastrar Atividades Projeto, Definir Sequncia Projeto, Cadastrar Estimativas Projeto, Associar Participante a Atividade.

Caso de Uso: Cadastrar Projeto Gerente Projeto Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Ps Condies: Resumo: Este caso de uso permite alterao, consulta e impresso de projetos. Curso Normal: Restries de alterao: O nome do projeto deve ser nico. Cursos Alternativos: A partir deste ponto, com um projeto sendo inserido ou alterado, um Gerente Local pode ativar os casos de uso: Cadastrar Fases do Projeto, Associar Mtricas ao Projeto, Cadastrar Riscos do Projeto, Consultar Estimativa do Projeto.

174

Caso de Uso: Definir Processo do Projeto Caso de Uso Geral: Ator Principal: Gerente de Projeto Atores Secundrios: Pr Condies: O projeto est sendo alterado e no tenha sido iniciado. Ps Condies: Resumo: Este caso de uso permite definir o processo (RUP, CATALYSIS) a ser utilizado para a execuo do projeto. Curso Normal: 1. O ator deve informar se deseja inserir ou remover o processo. 2 2.1 Caso a opo seja inserir, o projeto no pode ter nenhum processo associado. 2.1.1 O ator ir selecionar um dos processos j cadastrados e solicitar a criao do relacionamento. 2.1.2 O sistema criar automaticamente as fases do projeto, as seqncias das fases do projeto, as atividades do projeto, as seqncias das atividades do projeto e as mtricas do projeto trazendo as j cadastradas como fases do processo, seqncia das fases do processo, atividades do processo, seqncia das atividades do processo e mtricas do processo. 2.2 Caso a opo seja remover, o projeto deve ter um processo associado, mas no pode ter sido iniciado, isto , qualquer tarefa com ligao ao processo ter sido iniciada. 2.2.1 O sistema remover automaticamente tudo o que foi criado para o projeto e que est associada ao processo. Cursos Alternativos:

Caso de Uso: Cadastrar Fase do Projeto Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente do Projeto Atores Secundrios: Pr Condies: O projeto est selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso de fases do projeto. A incluso de fases permitida para que o gerente de projeto possa incluir fases tais como: treinamentos e anlise local. O gerente de projeto poder cadastrar o esforo-hora estimado para a atividade. Curso Normal: Restries para insero e alterao: O nome das fases deve ser nico em cada projeto. Cursos Alternativos: O ator poder chamar o caso de uso: Cadastrar Atividade do Projeto, Definir Seqncia Fase do Projeto, Associar Mtrica Fase do Projeto.

175

Caso de Uso: Cadastrar Atividade do Projeto Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente do Projeto Atores Secundrios: Pr Condies: O projeto est selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso de atividades do projeto. A incluso de atividades permitida para que o gerente de projeto possa incluir atividades tais como: viagens e reunies. O gerente de projeto poder cadastrar o esforo-hora estimado para a atividade. Curso Normal: Restries para insero e alterao: O nome das atividades deve ser nico em cada projeto. Cursos Alternativos: O ator poder chamar o use case Definir Sequncia Projeto, Associar Perfil Atividade, Associar Tipo de Recurso Material Atividade, Associar Participante Atividade, Associar Mtrica Atividade.

Caso de Uso: Definir Sequncia Fases do Projeto Caso de Uso Geral: Ator Principal: Gerente de Projeto Atores Secundrios: Pr Condies: Projeto deve estar selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite definir a sequncia de execuo das fases de um determinado projeto. Curso Normal: 1. O ator pode alterar a sequncia das fases do projeto e solicitar que isto seja salvo. Cursos Alternativos:

Caso de Uso: Definir Sequncia das Atividades do Projeto Caso de Uso Geral: Ator Principal: Gerente de Projeto Atores Secundrios: Pr Condies: Projeto deve estar selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite definir a sequncia de execuo das atividades de um determinado projeto. Curso Normal: 1. O ator pode alterar a sequncia das atividades do projeto e solicitar que isto seja salvo. Cursos Alternativos: O ator poder chamar o use case Cadastrar Atividade do Projeto.

176

Caso de Uso: Associar Mtrica ao Projeto Caso de Uso Geral: Ator Principal: Gerente do Projeto Atores Secundrios: Pr Condies: Projeto deve estar selecionado Ps Condies: Resumo: Este caso de uso permite definir as mtricas utilizadas em cada projeto. Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar uma mtrica e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar uma associao e solicitar que esta seja removida. Cursos Alternativos: O ator poder chamar o caso de uso Cadastrar Mtricas.

Caso de Uso: Associar Usurio ao Projeto Caso de Uso Geral: Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Projeto deve estar selecionado. Usurio deve estar cadastrado. Ps Condies: Resumo: Este caso de uso permite definir os participantes do projeto. Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar um usurio e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar um participante e solicitar que este seja removido. Cursos Alternativos: O ator poder chamar o caso de uso Cadastrar Usurio.

Caso de Uso: Associar Recurso Material ao Projeto Caso de Uso Geral: Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Projeto deve estar selecionado. Recurso Material deve estar cadastrado.

177

Ps Condies: Resumo: Este caso de uso permite definir os recursos materiais do projeto.

Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar um recurso material e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar um recurso material e solicitar que este seja removido. Cursos Alternativos: O ator poder chamar o caso de uso Cadastrar Recurso Material.

Caso de Uso: Associar Participante Atividade Caso de Uso Geral: Ator Principal: Gerente do Projeto Atores Secundrios: Pr Condies: Projeto deve estar selecionado. Ps Condies: Resumo: Este caso de uso permite associar o participante do projeto com uma atividade do projeto e definir a estimativa de esforo-hora do participante para executar a atividade. Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar um participante do projeto e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar um participante do projeto e solicitar que este seja removido. Cursos Alternativos: O gerente do projeto pode acionar o mecanismo de apoio seleo de RH para efetuar a busca dos participantes mais aptos a executar a atividade para depois disso, fazer a seleo de um deles.

Caso de Uso: Associar Recurso Material Tarefa Caso de Uso Geral: Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Tarefa deve estar selecionada. Recurso Material deve estar cadastrado. Ps Condies: Resumo: Este caso de uso permite definir os recursos materiais da tarefa.

178

Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar um recurso material e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar um recurso material e solicitar que este seja removido. Cursos Alternativos:

Caso de Uso: Definir Valor Mtrica do Projeto Caso de Uso Geral: Ator Principal: Gerente de Projeto Atores Secundrios: DIMANAGER Pr Condies: O projeto est sendo alterado e no tenha sido iniciado. Ps Condies: Resumo: Este caso de uso permite definir o valor da mtrica do projeto. Curso Normal: 1. Se ator for o gerente de projeto ele dever informar o valor da mtrica do projeto. Este valor foi criado quando foi includa a associao da mtrica ao projeto. Se ator for a DIMANAGER, a insero ser automtica. Cursos Alternativos:

Caso de Uso: Cadastrar Riscos do Projeto Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente Geral, Gerente Local, Gerente do Projeto Atores Secundrios: Pr Condies: O projeto est selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso dos riscos do Projeto. No incio do projeto o gerente geral far o cadastramento dos riscos em nvel estratgico, aps isso o gerente local far o cadastramento dos riscos preliminares e o gerente de projetos far o cadastramento dos riscos do projeto. Curso Normal: Restries para insero e alterao: O nome do risco deve ser nico. Cursos Alternativos:

Caso de Uso: Cadastrar Fornecedores Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente Geral, Gerente Local Atores Secundrios:

179

Pr Condies: O projeto est selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso dos fornecedores de recursos materiais para a organizao. Curso Normal: Restries para insero e alterao: O nome do fornecedor deve ser nico. Cursos Alternativos:

Caso de Uso: Associar Fornecedor ao Projeto Caso de Uso Geral: Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Projeto deve estar selecionado. Fornecedor deve estar cadastrado. Ps Condies: Resumo: Este caso de uso permite definir os fornecedores de servio para o projeto.

Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar um fornecedor e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar um fornecedor e solicitar que este seja removido.

Cursos Alternativos: O ator poder chamar o caso de uso Cadastrar Fornecedor.

Caso de Uso: Cadastrar Clientes do Projeto Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente Local, Gerente de Projeto Atores Secundrios: Pr Condies: O projeto est selecionado e sendo inserido ou alterado. Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso dos clientes do projeto. Curso Normal: Restries para insero e alterao: O nome do fornecedor deve ser nico. Cursos Alternativos:

180

Caso de Uso: Cadastrar Conhecimentos sobre o Projeto Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente de Projeto Atores Secundrios: Pr Condies: Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso de conhecimentos adquiridos com o projeto. Curso Normal: A consulta de todos os conhecimentos adquiridos em todos os projetos da organizao estar disponvel a todos da organizao. Cursos Alternativos:

Caso de Uso: Cadastrar Palavra-Chave Caso de Uso Geral: Cadastrar Item Ator Principal: Gerente de Projeto Atores Secundrios: Pr Condies: Ps Condies: Resumo: Este caso de uso permite insero, alterao, excluso, consulta e impresso de palavras-chave. Curso Normal:

Cursos Alternativos:

Caso de Uso: Associar Palavra-Chave ao Conhecimento Caso de Uso Geral: Ator Principal: Gerente de Projeto Atores Secundrios: Pr Condies: Conhecimento deve estar selecionado. Palavra-chave deve estar cadastrada. Ps Condies: Resumo: Este caso de uso permite definir as palavras-chave do conhecimento para facilitar a consulta posterior. Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar uma palavra-chave e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar uma palavra-chave e solicitar que este seja removido.

181

Cursos Alternativos: O ator poder chamar o caso de uso Cadastrar Palavra-Chave.

Caso de Uso: Associar Mtrica ao Fornecedor Caso de Uso Geral: Ator Principal: Gerente Local Atores Secundrios: Pr Condies: Fornecedor deve estar selecionado. Mtrica deve estar cadastrada. Ps Condies: Resumo: Este caso de uso permite definir mtricas de avaliao do fornecedor. Curso Normal: 1. O ator deve informar se deseja inserir ou remover uma associao. 2. 2.1 Caso a opo seja inserir o ator dever selecionar uma mtrica e confirmar a insero. 2.2 Caso a opo seja remover, o ator ir selecionar uma mtrica e solicitar que este seja removido.

Cursos Alternativos: O ator poder chamar o caso de uso Cadastrar Mtrica.

182

APNDICE D DIAGRAMA DE CLASSES ATUALIZADO

183

184

185

186

187

188

189

APNDICE E JANELAS DO PROTTIPO

Figura 40. Janela para Cadastramento de Fase do Processo.

Figura 41. Janela para Cadastramento de Atividade do Processo.

190

Figura 42. Janela para Cadastramento da Dependncia entre Atividades.

Figura 43. Janela para Cadastramento de Perfil da Atividade do Processo.

191

Figura 44. Janela para Cadastramento do Tipo de Recurso Material Necessrio para Executar a Atividade do Processo.

Figura 45. Janela para Cadastrar Dependncia entre as Fases do Processo.

192

Figura 46. Janela para Associar Mtrica a Atividade do Processo.

Figura 47. Janela para Cadastramento do Tipo de Artefato.

193

Figura 48. Janela para Cadastramento das Aptides do Usurio.

Figura 49. Janela para Cadastrar Nvel do Perfil.

194

Figura 50. Janela para Definir Participantes do Projeto.

Figura 51. Janela com Parmetros para Obter os Participantes mais Aptos para Executar a Tarefa.

195

Figura 52. Resultado da Consulta dos Participantes Mais Aptos para Executar a Atividade.

Figura 53. Janela para Cadastro de Palavras-Chave.

196

Figura 54. Janela para Consulta do Conhecimento.

197

APNDICE F QUESTIONRIO APLICADO AOS GERENTES DE PROJETO

O Modelo de Gerenciamento de Projeto (MGP) para um ambiente de desenvolvimento distribudo de software (ADDS) ao qual se faz referncia neste questionrio est representado pela Figura 1 abaixo e os seus componentes esto listados a seguir:

Figura 1. Componentes do MGP proposto. 1) Os usurios de um projeto de desenvolvimento distribudo de software (DDS): a) os clientes: que devem receber informaes sobre o andamento do projeto; b) os gerentes gerais que cuidam da parte contratual com os clientes, supervisionam os gerentes de projeto e realizam a seleo dos projetos a serem desenvolvidos e qual a unidade distribuda que ir desenvolv-lo; c) os gerentes locais que so os gerentes de cada unidade distribuda e que precisam de informaes para gerenciar sua unidade; d) os gerentes de projeto que necessitam de informaes para o planejamento e controle dos projetos; e) os engenheiros de software que precisam de informaes sobre a sua agenda de trabalho; 2) Gerncia de stakeholders ou interessados no projeto: importante gerenciar a equipe do projeto identificando a pessoa mais apta a realizar cada tarefa. E, para isso preciso conhecer o treinamento, conhecimento, habilidade, afinidade e aptido de cada um. Tambm uma ateno especial deve ser dada aos fornecedores possibilitando uma avaliao dos mesmos e permitindo assim, a seleo dos melhores fornecedores para a organizao e para o projeto. E, com relao aos clientes, importante manter um cadastro dos mesmos e permitir que avaliem o projeto, o software ou componentes do software; 3) Gerncia do conhecimento: o conhecimento da organizao deve ser difundido por toda a organizao. O conhecimento que cada um possui parte do conhecimento da organizao e portanto deve-se: evitar a sada de pessoas; estimular a exteriorizao de idias; criar uma rede de contatos entre as pessoas para capitalizar, transferir e compartilhar o conhecimento; e, transformar o conhecimento e armazen-lo em um banco de dados para que possam ser facilmente acessados e usados por qualquer pessoa da organizao; 198

4) Orientao para minimizar ou eliminar problemas advindos de diferenas culturais e disperso geogrfica em ambiente de desenvolvimento distribudo de software (ADDS): uma orientao inicial importante para que os membros da equipe se entendam melhor evitando problemas de comunicao. Devem ser abordados temas como: a cultura dos pases envolvidos; responsabilidade e autoridade dentro do projeto; padro de comportamento esperado; comunicao entre os membros da equipe; e, forma de realizar o trabalho; 5) Propriedade intelectual: em um ambiente onde existem diversos participantes trabalhando em diversos pases fundamental que o gerente de projetos se preocupe com a questo dos direitos autorais e a propriedade intelectual do software ou parte dele. Cada pas possui uma legislao diferente e que pode comprometer o desenvolvimento do software. Deve-se procurar assessoria jurdica e estar sempre atento s modificaes nas legislaes dos locais envolvidos na construo do software. Deve-se cuidar tambm do acesso as informaes privadas do projeto pois alguns projetos exigem sigilo; 6) Ferramenta de apoio ao gerenciamento de projeto: indispensvel o uso de uma ferramenta de apoio ao gerenciamento de projeto em um ADDS que permita armazenar os dados dos projetos para auxiliar o gerente de projetos na execuo de suas funes e para estudo ou consulta posteriores; 7) Mtricas: para que haja o devido monitoramento e controle do projeto, preciso medir o projeto. As mtricas a serem coletadas devem ser consideradas importantes para todos na organizao e devem ser analisadas quanto ao custo-benefcio. As mtricas propostas so: pontos por funo, qualidade, produtividade, rodzio de participantes do projeto, tempo em que o participante fica ocioso, tempo que o participante aguarda para obter os recursos materiais ou artefatos necessrios para executar uma atividade; facilidade de utilizao do processo, ocorrncia do projeto e volatilidade dos requisitos; 8) Estimativas: as estimativas de tempo e custo so um desafio para o gerente de projetos pois dependem de variveis humanas, tcnicas, ambientais e polticas. Deve-se possibilitar a realizao de pelo menos trs estimativas para que se possa ter uma garantia maior de que a estimativa est correta. Devido existncia de ferramentas para estimativas, deve-se permitir a interoperabilidade da ferramenta de apoio ao gerenciamento de projeto com a mesma; 9) Gerncia de riscos: deve-se identificar, quantificar e eliminar ou reduzir a probabilidade dos riscos ocorrerem e ter um plano de contingncia no caso de ocorrerem; 10) Gerenciamento de requisitos: envolve a identificao de inconsistncias entre os requisitos, o plano do projeto e os produtos desenvolvidos. Uma matriz de rastreamento de requisitos pode ser fornecida para se descrever e seguir a vida do requisito desde a sua origem at a sua entrega e uso; 11) Modelos de documentos: devem ser utilizados para manter registros dos compromissos da equipe do projeto e dos clientes com relao ao projeto e tambm para manter um padro de controle gerencial dentro da organizao lembrando a todos da importncia de se manter documentos, tais como: plano do projeto, plano de gerenciamento de risco, plano de gerenciamento de stakeholders, plano de instalao do software, etc; Por fim, o modelo apresenta um questionrio para avaliar as necessidades de cada indivduo na organizao permitindo recompensar adequadamente cada um.

199

O Questionrio a seguir dividido em 3 partes. 1) Sobre o respondente; 2) Sobre a empresa; 3) Sobre o modelo apresentado.

1 Parte: Sobre o Respondente Escolaridade (informe somente o maior grau) ( ) 1 Grau ( ) 2 Grau ( ) Superior Incompleto ( ) Superior Completo Curso:______________________________________________________________________ Ano de Concluso: _________ Ps-Graduao (Especializao, Mestrado, Doutorado e Ps-doutorado): ( ) Especializao ( ) Mestrado ( ) Doutorado ( ) Ps-Doutorado Curso:______________________________________________________________________ Ano de Concluso: _________ Tempo de experincia em desenvolvimento de sistemas:____________________________ Tempo de experincia em gerenciamento de projeto: _______________________________ Tempo de experincia em gerenciamento de projeto com desenvolvimento distribudo: _______________________________ Quantidade de projetos gerenciados: _________ 2 Parte: Sobre a Empresa Quantidade de funcionrios da organizao na qual trabalha: ________ Quantidade de funcionrios no desenvolvimento de software: ________ Assinale a(s) funo(es) exercida(s) na organizao atualmente: ( ) Gerente Geral da Organizao ( ) Gerente de uma Unidade Distribuda ( ) Gerente do setor de desenvolvimento de software ( ) Gerente de Projeto ( ) Desenvolvedor ( ) Outro: __________________________________________ Tipo de vnculo: ( ) Contratado ( ) Terceirizado

Tempo na Organizao: _____________ anos. 1) Assinale as funes existentes na sua organizao para executar o gerenciamento do projeto? ( ) Gerente Geral da Organizao ( ) Gerente de uma Unidade Distribuda ( ) Gerente do setor de desenvolvimento de software ( ) Gerente de Projeto ( ) Outros: __________________________________________ 2) Existe algum processo formal de desenvolvimento de software utilizado pela empresa?(mtodos, ferramentas, tcnicas, ciclo de vida, atividades) ( ) Sim ( ) No 200

3) Na sua organizao existe algum processo formal utilizado para o gerenciamento de projeto? E a utilizao de algum MGP? ( ) PSP ( ) SPICE ( ) TSP ( ) Normas ISO ( ) PCMM ( ) Outro: _____________________________ ( ) CMMI 4) A organizao j trabalhou com desenvolvimento distribudo de software (DDS) onde pessoas fisicamente distantes colaboram no desenvolvimento de um software? ( ) Sim ( ) No 5) A organizao j trabalhou com a contratao de colaboradores externos? ( ) Sim ( ) No 6) Quando existe o rodzio de pessoas no desenvolvimento de software, como o conhecimento repassado de um participante para outro? ( ) Por meio de documentos e manuais ( ) Explicao oral dos procedimentos ( ) Outro: _______________________________________ 7) Quando surge um determinado problema, como normalmente voc o resolve? ( ) Busca orientao dos gerentes mais experientes ( ) Consulta histrico de projetos passados ( ) Pesquisa em acervo bibliogrfico ( ) Busca orientao de especialistas ( ) Sua experincia ( ) Outro: _______________________________________ 8) Assinale os itens que indicam como a organizao motiva os funcionrios? ( ) Aumento de salrio ( ) Prmios ( ) Uso de tecnologia de ponta ( ) Ambiente adequado ( ) Treinamento 9) Como so resolvidos os conflitos na sua organizao? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 10) Quem o responsvel pela resoluo dos conflitos na sua organizao? Existe uma hierarquia? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

201

3 Parte: Sobre o Modelo de Gerenciamento de Projeto (MGP) apresentado 1) No MGP os principais stakeholders controlados so os participantes do projeto, os fornecedores e os clientes. Voc acredita que este controle adequado para um ambiente de desenvolvimento distribudo de software? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 2) No MGP a escolha do participante para a execuo de cada atividade do projeto considera os itens abaixo. Voc concorda? a) Conhecimentos dos indivduos ( ) Sim ( ) No b) Habilidades dos indivduos ( ) Sim ( ) No c) Aptides dos indivduos ( ) Sim ( ) No d) Treinamento dos indivduos ( ) Sim ( ) No e) Afinidades dos indivduos. ( ) Sim ( ) No Existem outros itens que voc considera relevantes? Quais? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 3) Para a seleo dos fornecedores, considera-se o histrico de avaliao dos fornecedores. Voc concorda? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 4) O MGP prope a realizao de uma alguma avaliao formal por parte dos clientes/usurios com relao ao software desenvolvido. Voc acredita que isso vlido para obter a satisfao dos mesmos? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 5) Voc concorda que o conhecimento adquirido por uma determinada pessoa seja distribudo para toda a organizao? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

202

6) Na sua opinio, aps o trmino do projeto, importante o processo de avaliao e feedback? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

7) A seguir esto os riscos considerados na seleo de projetos a serem desenvolvidos nas unidades distribudas. Assinale com sim se voc concorda, e no se voc discorda. a) Documentao existente e interao necessria para elaborar a documentao do projeto ( ) Sim ( ) No b) Clareza e estabilidade dos requisitos ( ) Sim ( ) No c) Riscos de tecnologia ( ) Sim ( ) No d) Capacidade de controle gerencial ( ) Sim ( ) No e) Experincia dos clientes e usurios em projetos distribudos ( ) Sim ( ) No f) Complexidade e durao (existncia de recursos humanos disponveis para integrar a equipe) ( ) Sim ( ) No g) Tamanho do projeto com relao a quantidade de membros na equipe ( ) Sim ( ) No h) Concentrao de Projetos (Sobrecarga de projetos) ( ) Sim ( ) No Existem outros riscos a serem considerados na seleo de projetos para as unidades distribudas?Quais? ___________________________________________________________________________ ___________________________________________________________________________

8) A seguir esto os riscos considerados no planejamento dos projetos. voc concorda, e no se voc discorda. a) Rotatividade de pessoal ( ) Sim b) Mudana de tecnologia ( ) Sim c) Incerteza nos custos ( ) Sim d) Incerteza no cronograma ( ) Sim e) Clareza e estabilidade dos requisitos ( ) Sim f) Mudana de gerenciamento ( ) Sim g) Indisponibilidade de hardware ( ) Sim h) Existncia de produto concorrente ( ) Sim i) Treinamento no disponvel ( ) Sim j) Ferramentas CASE inadequadas ( ) Sim

Assinale com sim se ( ( ( ( ( ( ( ( ( ( ) ) ) ) ) ) ) ) ) ) No No No No No No No No No No

Existem outros riscos a serem considerados no planejamento de projetos? Quais? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

203

9) A forma apresentada no modelo para tratar a questo da propriedade intelectual com assessoria jurdica e restrio de acesso s informaes privadas adequada? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 10) Em projetos com desenvolvimento distribudo de software, o gerenciamento de requisitos se torna indispensvel. Concorda? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 11) O rastreamento dos requisitos vivel para projetos com desenvolvimento distribudo de software? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 12) A avaliao das necessidades individuais importante para se recompensar adequadamente cada um? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 13) A orientao inicial proposta vlida para minimizar os conflitos existentes com a comunicao entre os membros da equipe em um projeto com desenvolvimento distribudo de software? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 14) As mtricas propostas so as seguintes. Voc concorda na utilizao das mesmas? a) Pontos por funo ( ) Sim ( ) No b) Qualidade ( ) Sim ( ) No c) Produtividade ( ) Sim ( ) No d) Rodzio de participantes no projeto ( ) Sim ( ) No e) Tempo ocioso do participante ( ) Sim ( ) No f) Tempo de espera do participante aguardando recursos e artefatos ( ) Sim ( ) No g) Facilidade de utilizao do processo de desenvolvimento ( ) Sim ( ) No 204

h) Ocorrncias do projeto (problemas) i) Volatilidade dos requisitos

( ) Sim ( ) Sim

( ) No ( ) No

Existem outras mtricas a serem consideradas? Quais? ___________________________________________________________________________ ___________________________________________________________________________ 15) Acredita na utilidade de uma ferramenta de apoio para realizar estimativas de tempo e custo? ( ) Sim ( ) No, porque ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 16) Os seguintes modelos de documentos so adequados para o GP? Plano do Projeto? ( ) Sim Plano de Gerenciamento de Riscos? ( ) Sim Plano de Gerenciamento de Dados? ( ) Sim Plano de Gerenciamento de Stakeholders? ( ) Sim Habilidades/Conhecimentos/Treinamento dos indivduos? ( ) Sim Compromisso com os Requisitos? ( ) Sim Solicitao de Mudana nos Requisitos? ( ) Sim Relatrio de Inconsistncia nos Requisitos? ( ) Sim Recebimento de Propostas de Fornecedores? ( ) Sim Avaliao de Produtos Recebidos e Fornecedores? ( ) Sim Avaliao da Organizao? ( ) Sim Relatrio de Lies Aprendidas? ( ) Sim

( ( ( ( ( ( ( ( ( ( ( (

) ) ) ) ) ) ) ) ) ) ) )

No No No No No No No No No No No No

Ferramenta de Apoio ao Gerenciamento de Projeto: 1) A apresentao permitiu visualizar a ferramenta e sua utilidade? ( ) Sim ( ) No Justifique ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 2) A ferramenta apresentada tem utilidade para o GP? ( ) Sim ( ) No Justifique ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 205

3) Voc considera que o manuseio da ferramenta facilita o trabalho do gerenciamento? ( ) Sim ( ) No Justifique ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 4) A ferramenta apresenta utilidade para projetos desenvolvidos em locais dispersos geograficamente? ( ) Sim ( ) No Justifique ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 5. Sugestes/opinies/crticas. ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

206

ANEXO A DESCRIO DOS PERFIS

De acordo com Roberto Lira Miranda em seu livro Alm da Inteligncia Emocional aps a realizao de uma pesquisa foram constatados oito tipos diferentes de perfis (CURIONI, 2005):
- Perfil Monodominante "NO " Indivduos que utilizam preferencialmente, gostam mais. sentem-se melhor, trabalhando com as aptides caractersticas do plo neocortical esquerdo. So mais concretos, frios e lgicos. Preocupados com a anlise, avaliao e quantificao dos fenmenos fsicos e seu entendimento pleno. Exibem superiores capacidades para raciocinar e resolver problemas matemticos ou econmicos complexos e do exato valor ao dinheiro. No ligam muito para as pessoas ou para os seus sentimentos. No confiam em suas prprias sensaes ou sentimentos para tomar decises e agir. preferindo avaliar e ponderar as situaes para se apoiar em informaes reais e comprovadas. So, frequentemente, introvertidos e srios, avessos a intimidades com pessoas que no conhecem bem e quase imunes a devaneios romnticos ou poticos. Tendem a menosprezar os sentimentos e preferem trabalhar sozinhos. Aceitam e entendem melhor as informaes baseadas em dados ou que podem ser demonstradas na prtica. Desejam demonstrar e provar quando transmitem informaes. Suas necessidades preponderantes orientam-se para a auto-realizao (maximizao de seu potencial) em termos materiais, concretos e tangveis. Suas condutas transacionais refletem o estado de ego adulto, consequentes de elaboraes intelectuais, com destaque para a evidncia, regras de lgica, coleta objetiva de dados e combinao de informaes para anlise fria e tranquila dos dados da realidade. - Perfil monodominante "NE" Indivduos que utilizam preferencialmente, gostam mais, sentem-se melhor, trabalhando com as aptides caractersticas do plo neocortical direito. So abstratos, artsticos e fantasiosos. Preocupados mais com a fabricao do que com a aquisio de conhecimentos. Exibem superiores capacidades para correlacionar idias e sensaes desenvolvidas intuitivamente margem de dados e fatos. Tendem a ser pouco apegados ao dinheiro e, at, s pessoas das quais raramente esperam ou exigem reciprocidade. No do grande importncia experincia ou ao conhecimento real de fatos passados, preferindo apoiar-se em suas prprias idias e interpretaes dos fatos. Tm gosto pela aventura e pelo risco, tomando decises impetuosas e. no raramente, irresponsveis. Impulsionados por uma imaginao rica e agitada, so, frequentemente, extrovertidos e brincalhes, sagazes e cnicos. Apresentam superior resistncia s frustraes consequentes de seus atos ou de aes de terceiros. Aceitam e entendem melhor as informaes que deixam espao para especulaes e mudanas. Preferem ter uma viso global (holstica) a detalhada das coisas. Fecham os olhos para entender melhor as mensagens transmitidas verbalmente e transmitem atravs do significado das palavras e sons, alm de metforas e alegorias. Suas necessidades preponderantes orientam-se para a auto-realizao espiritual e intelectual, abstrata e intangvel. Suas condutas transacionais refletem o estado de ego criana, pequeno mestre ou adulto da criana, comprometidos com ideias mgicas, sonhos, imaginao e fantasia. - Perfilmunodominante "SO" Indivduos que utilizam preferencialmente, gostam mais, sentem-se melhor, trabalhando com as aptides caractersticas do plo cortical esquerdo. So precavidos, cautelosos, conservadores. Preocupados com a organizao, ordenamento e controle de coisas, informaes e atividades. Estabelecem e adotam aes preventivas e procedimentos e fazem as coisas acontecer. So

207

confiveis, organizados, pontuais e esmerados em seu trabalho. Mobilizam e conservam recursos (poupadores) e empenham-se em cumprir os compromissos que assumem, com pontualidade e rigor. Tm aptides administrativas, disciplinares e burocrticas mais destacadas, incluindo a capacidade e o interesse para trabalhar dentro de normas estabelecidas e planejar para o futuro prximo. No tm grande interesse na criao, inveno ou especulao, preferindo trabalhar com situaes j estabelecidas. Pouco dados a fantasias e avessos a correr riscos. So , frequentemente, severos, desconfiados e espartanos. Tendem a exibir grande energia, tenacidade, persistncia e superior resistncia ao desconforto e ao cansao. Atentos posio de todas as coisas no espao, querem ver quando recebem informaes ou mostrar quando as transmitem. Suas necessidades preponderantes tendem para a segurana (individual e familiar) e status (dominncia sobre os outros). Parametrados por regras e normas aprendidas, suas condutas transacionais reletem o estado de ego pai e criana adaptada: ordens, recriminaes, tradies, conselhos, moral, tica, regras sociais, preconceitos e ensinamentos.
- Perfilmonodominanie "SE" Indivduos que ulilizam preferencialmente, gostam mais, sentem-se melhor, trabalhando com as aptides caractersticas do plo cortical direito. So romnticos, emotivos, afetuosos. Mostram-se preocupados com a organizao social e com o bem-estar e sentimentos das pessoas e indiferentes ou antipticos s cincias exatas. Exibem superiores capacidades de amar e sentir, apoiar seus semelhantes, ensinar, estimular as pessoas e envolver-se com elas. So extrovertidos, falantes, cooperativos, corteses, empticos, conciliadores, humanitrios e prdigos. Gostam de fazer amigos, conviver e conversar com eles, trabalhar e divertir-se em grupos. Gostam, tambm, de cuidar das pessoas e de animais. So os maiores apreciadores de msica, poesia e histrias romnticas, preferindo a interpretao mais do que a criao. Tendem a ser excelentes intrpretes de sentimentos e comportamentos, embora possam ser iludidos pela grande confiana que tm nas pessoas. Magoam-se com mais facilidade quando no conseguem dos outros o nvel de reciprocidade que esperam, desenvolvendo sentimentos de insegurana e medo em relao s pessoas muito frias e materialistas. Sentem-se mais confortveis e aprendem melhor as informaes transmitidas com emoo (tocantes) e transmitem melhor atravs das emoes e sentimentos. Suas necessidades preponderantes tendem para a associao e estima (de terceiros). Parametrados por seus sentimentos em relao s pessoas e coisas, exibem condutas transacionais que refletem o ego do pai protetor (nutritivo) ou da criana social. - Perfil bidominante "NO/NE" Ao representar o perfil intelectual, identifica os indivduos com maiores aptides nos plos neocorticais, capazes de desenvolver, com segurana e conforto, tanto os raciocnios lgicos, quanto os especulativos. Sua menor carga de aptides nos plos cerebrais inferiores indica que eles so mais pensadores do que fazedores. Tero, no entanto, predileo pelos trabalhos executivos que exigem talentos neocorticais tais como as atividades artsticas de diferentes espcies: literatura, msica (inclusive criao), desenho, pintura, escultura e todas as espcies de trabalhos fsicos e manuais delicados ou que exijam habilidade. Em verdade, sua destreza intelectual transfere destreza fsica para movimentos refinados, mais do que para qualquer outra ao corporal. De maneira geral, o intelectual no forte fisicamente, nem hbil em atividades fsico/energticas. Ele tem menor resistncia ao cansao fsico e, na realidade, "no gosta de fazer fora". - Perfil bidominante "NO/SO " O perfil tcnico/organizacional identifica os indivduos com dominncia de aptides mais acentuada no hemisfrio cerebral esquerdo, pendendo mais ou menos para os plos corticais (S...) ou neocorticais (N...). Seu descritivo combina caractersticas desses dois perfis, em diferentes

208

dosagens que enfatizam, sempre, os raciocnios, as atitudes e os comportamentos lgicos, formais e analticos, baseados na razo, sequncia e fatos, com menor participao dos raciocnios, atitudes e comportamentos conceituais, informais e intuitivos, baseados em percepes, possibilidades e especulaes O perfil tcnico/organizacional corresponde, exatamente, ao conceito do hemisfrio cerebral esquerdo na proposta da dualidade cerebral, podendo descrever um indivduo mais intelectual (aptides NO) ou mais operacional (SO).
- Perfil bidominante "NE/SE" Criativo/interpessoal o perfil caracterstico de dominncia no hemisfrio cerebral direito, tambm com diferentes combinaes de aptides corticais (S...) ou neocorticais (N...). "o outro ado da medalha" em relao ao perfil NO/SO, dominado pelos raciocnios, atitudes e comportamentos conceituais, informais e intuitivos, fundamentados em percepes, possibilidades e especulaes. O criativo/interpessoal combina, em menores dosagens, aptides dos plos de dominncia NE e SE, pendendo para um ou outro: mais pensador (N...) do que fazedor (S...) ou vice-versa. As aptides desses plos podem, tambm, ser bastante equilibradas, identificando indivduos de maior versatilidade de aptides nesses dois plos.

- Perfil bidominante "SO/SE^" O perfil operacional de concentrao de aptides nos plos corticais e sistema lmbico (S) o oposto do intelectual por ser muito mais ligado ao do que ao pensamento puro. Isso no significa que ele no pense. Muito pelo contrrio, ele pensa muito e operacionalmente, isto , pensa nas coisas que podem e precisam ser feitas e as faz. Sua inteligncia , por isso, mais prtica e, frequentemente, mais realizadora. Raramente qualquer trabalho de nvel intelectual ou corporal refinado que execute ter o mesmo "acabamento" que aquele produzido por um intelectual. Seu volume de produo ser, no entanto, superior ao do intelectual, principalmente em atividades que exijam esforo fsico mais marcante.

209

ANEXO B QUESTIONRIO PARA IDENTIFICAO DAS APTIDES DOMINANTES

1. Atividades de minha preferncia na infncia (assinale quatro): 1.1 Brinquedos que voavam 1.2 Amarelinha 1.3 Jogos de tabuleiro 1.4 Bonecos/Bonecas 1.5 Bolas de gude 1.6 Ciranda 1.7 Decifrar charadas 1.8 Desenhar 1.9 Desmontar coisas 1.10 Empinar Pipas 1.11 Futebol de boto 1.12 Jogo da Velha 1.13 Jogos de bola 1.14 Mocinho/Bandido 1.15 Quebra cabeas 1.16 Jogo de xadrez

2. Atividades de minha preferncia na escola (assinale quatro): 2.1 Aritmtica/Matemtica 2.2 Cincias fsicas/fsica 2.3 Humanas/Psicologia 2.4 Desenho Artstico 2.5 Engenharia 2.6 Economia 2.7 Geografia 2.8 Geometria 2.9 Histria 2.10 Leitura 2.11 Lnguas 2.12 Msica 2.13 Poesia/Declamao 2.14 Portugus/Gramtica 2.15 Redao /Composio 2.16 Trabalhos Manuais

3. Atividades de minha preferncia no trabalho (assinale quatro): 3.1 Administrao de processos 3.2 Anlise de Problemas 3.3 Assuntos Administrativos 3.4 Assuntos Financeiros 3.5 Assuntos humanos/Sociais 3.6 Assuntos Tcnicos 3.7 Criao/Desenvolvimento 3.9Estruturas/Organizao 3.10 Oramentos 3.11 Planos de ao 3.12 Estratgia Global 3.13 Propaganda 3.14 Relaes Pblicas 3.15 Teste de Mercado

210

3.8 Ensinar/Treinar

3.16 Trabalho em Equipe

4. Atividades de minha preferncia no lazer (assinale quatro): 4.1 Artesanato 4.2 Arrumar coisas 4.3 Assistir corridas 4.4 Campismo 4.5 Colees 4.6 Conhecer Lugares Novos 4.7 Consertar Aparelhos 4.8 Danar 4.9 Desenho/Pintura 4.10 Esportes Coletivos 4.11 Fotografia 4.12 Jogar Xadrez 4.13 Leituras Tcnicas 4.14 Pescar 4.15 Reunies Sociais 4.16 Trabalhar com o Computador

5. Meus descritivos (assinale quatro): 5.1 Afetuoso 5.2 Analtico/Objetivo 5.3 Brincalho 5.4 Cauteloso 5.5 Detalhista 5.6 Emotivo 5.7 Esmerado 5.8 Extrovertido 5.9 Falante 5.10 Fantasiosoo 5.11 Introvertido 5.12 Intuitivo 5.13 Organizado 5.14 Racional 5.15 Subjetivo 5.16 Tcnico/Prtico

6. Minhas Motivaes (assinale uma em cada grupo): Eu trabalho melhor quando: 6.1 Tudo est bem organizado 6.2 Disponho de informaes concretas 6.3 Tenho oportunidade de usar a imaginao 6.4 Posso compartilhar minhas idias com outros Falta-me nimo para empreender uma atividade quando: 6.5 No consigo vislumbrar sua utilidade prtica 6.6 Ela no apresenta desafio para minha inteligncia 6.7 Tenho de trabalhar sozinho 6.8 Tenho de trabalhar com pessoas indisciplinadas 211

Eu me entusiasmo com uma atividade quando: 6.9 Conheo tudo a respeito 6.10 Ela apresenta regras bem definidas 6.11 As pessoas envolvidas trabalham em harmonia 6.12 Posso testar minha capacidade Eu me aborreo quando: 6.13 Vejo as coisas bagunadas 6.14 No posso trabalhar com coisas concretas 6.15 As pessoas discutem e brigam 6.16 Cerceiam minha criatividade 7. Minhas reaes (assinale uma em cada grupo): Quando pedem minha aprovao para uma idia: 7.1 Quero examinar sua lgica e racionalidade 7.2 Preciso ter confiana nas pessoas envolvidas 7.3 Quero saber como ela ser executada na prtica 7.4 Quero descobrir se ela inovadora Quando resistem s minhas idias: 7.5 Explico, passo a passo, sua aplicao 7.6 Demonstro seu valor com dados e fatos 7.7 Trato de granejar a simpatia dos envolvidos 7.8 Procuro estimular a imaginao dos envolvidos Quando no entendo uma instruo: 7.9 porque no me mostraram/explicaram em detalhes 7.10 porque no entendo seus objetivos e coerncia 7.11 porque no gosto da instruo ou do instrutor 7.12 porque ela muito "quadrada" ou conservadora Quando no entendem minhas instrues: 7.13 Reenfatizo utilizando exemplos ilustrativos 7.14 Trato de chegar ao "corao" dos envolvidos 7.15 Fao uma demonstrao organizada de suas etapas 7.16 Apresento todos os dados e fatos que as reforam 212

8. Minhas convices (assinale as quatro frases que voc, com mais entusiasmo, assinaria embaixo: 8.1 S a informao traz o poder (Freud) 8.2 Nunca ande pelo caminho traado, pois ele conduz somente aonde os outros j foram (Graham Bell) 8.3 Se voc quer civilizar um homem, comece pela av dele (Victor Hugo) 8.4 O que mais precisamos de algum que nos obrigue a fazer o que sabemos (Ralph Waldo Emerson) 8.5 Mais vale um pssaro na mo do que dois voando (Popular) 8.6 O futuro pertence queles que acreditam na beleza de seus sonhos (Eleanor Roosevelt) 8.7 Quem sabe mais, chora menos (Popular) 8.8 Um irmo pode no ser um amigo, mas um amigo ser sempre um irmo (Benjamin Franklin) 8.9 O passo mais importante para chegar a concentrar-se aprender a estar sozinho consigo mesmo (Erich Fromm) 8.10 A imaginao mais importante do que o conhecimento (Albert Einstein) 8.11 Uma andorinha s no faz vero (Popular) 8.12 Mais difcil do que levar uma vida organizada imp-la a outros (Marcel Proust) 8.13 Uma alegria compartilhada transforma-se em dupla alegria; uma dor compartilhada transforma-se em meia dor (Popular) 8.14 O humor a quebra da lgica (Henri Bergson) 8.15 Quem no arrisca no petisca (Popular) 8.16 O discernimento consiste em saber at onde se pode ir (Jean Cocteau)

213

ANEXO C APURAO DOMINANTES

1.1 NO 1.2 SO 1.3 NO 1.4 SE 1.5 SO 1.6 SE 1.7 NE 1.8 NE 1.9 NO 1.10 NE 1.11 SO 1.12 SO 1.13 SE 1.14 SE 1.15 NE 1.16 NO 5.1 SE 5.2 NO 5.3 NE 5.4 SO 5.5 SO 5.6 SE 5.7 SO 5.8 SE 5.9 SE 5.10 NE 5.11 NO 5.12 NE 5.13 SO 5.14 NO 5.15 NE 5.16 NO 2.1 NO 2.2 NO 2.3 SE 2.4 NE 2.5 NO 2.6 NO 2.7 SO 2.8 SO 2.9 SE 2.10 SO 2.11 SE 2.12 NE 2.13 SE 2.14 SO 2.15 NE 2.16 NE 6.1 SO 6.2 NO 6.3 NE 6.4 SE 6.5 NO 6.6 NE 6.7 SE 6.8 SO 6.9 NO 6.10 SO 6.11 SE 6.12 NE 6.13 SO 6.14 NO 6.15 SE 6.16 NE

DAS

APTIDES

CEREBRAIS

Transfira para a tabela as respostas que anotou: 3.1 SO 3.2 NO 3.3 SO 3.4 NO 3.5 SE 3.6 NO 3.7 NE 3.8 SE 3.9 SO 3.10 NO 3.11 SO 3.12 NE 3.13 NE 3.14 SE 3.15 NE 3.16 SE 7.1 NO 7.2 SE 7.3 SO 7.4 NE 7.5 SO 7.6 NO 7.7 SE 7.8 NE 7.9 SO 7.10 NO 7.11 SE 7.12 NE 7.13 NE 7.14 SE 7.15 SO 7.16 NO 4.1 NE 4.2 SO 4.3 SE 4.4 NE 4.5 SO 4.6 NE 4.7 NO 4.8 SE 4.9 NE 4.10 SO 4.11 SO 4.12 NO 4.13 NO 4.14 SE 4.15 SE 4.16 - NO 8.1 NO 8.2 NE 8.3 SE 8.4 SO 8.5 SO 8.6 NE 8.7 NO 8.8 SE 8.9 NO 8.10 NE 8.11 SE 8.12 SO 8.13 SE 8.14 NO 8.15 NE 8.16 SO

Some as respostas assinaladas em cada plo: NO = SO = NE = SE = O mximo de pontos que se pode totalizar em um nico plo 32. Nesse caso, teria 0 em todos os demais. A distribuio mais equilibrada de pontos, seria 8 em cada plo. Transforma-se os numero em percentagens, multiplicando por 100 e dividindo por 32. 214

Anota-se os percentuais de cada perfil: NO (Raciocnio lgico) = NE (Criatividade) = SO (Organizao) = SE (Comunicao) = Soma-se os percentuais em pares: NO + NE = SO + SE = NO + SO = NE + SE = Resultado acima de 50% em qualquer plo, isoladamente, sinalizam aptides de alta dominncia, resultados abaixo de 20% sinalizam aptides de baixa dominncia.

215