UNIVERSIDADE FEDERAL DO PAR INSTITUTO DE CINCIAS EXATAS E NATURAIS CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Patrcia Matias Lopes

APOIO NA GERAO DE PLANO DO PROJETO NO AMBIENTE WEBAPSEE

Belm 2008

UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS COLEGIADO DO CURSO DE CINCIA DA COMPUTAO

Patrcia Matias Lopes

APOIO NA GERAO DE PLANO DO PROJETO NO AMBIENTE WEBAPSEE

Trabalho de Concluso de Curso apresentado para a obteno do grau de Bacharel em Cincia da Computao. Orientadora: Profa. Dra. Carla A. Lima Reis

Belm 2008

UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Patrcia Matias Lopes

APOIO NA GERAO DE PLANO DO PROJETO NO AMBIENTE WEBAPSEE

Trabalho de Concluso de Curso apresentado para a obteno do grau de Bacharel em Cincia da Computao

Data da defesa: 19/12/2008 Conceito: EXCELENTE Banca Examinadora

Prof. Dr. Carla Alessandra Lima Reis Faculdade de Computao/UFPA Orientadora Prof. Dr. Rodrigo Quites Reis Faculdade de Computao/UFPA Membro Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computao/UFPA Membro

A Jeov Deus, aos meus pais, Haroldo Pinto Ramos e Ada Matias da Silva e minha irm Clia Maria Silva Ramos.

AGRADECIMENTOS
Agradeo primeiramente a Jeov Deus pela realizao deste trabalho, por sempre mostrar o caminho certo a seguir e me fazer entender que no importa a dificuldade ela pode ser vencida. Aos meus pais Ada Matias da Silva e Haroldo Pinto Ramos pelo apoio incondicional a cada momento da minha vida, participando das minhas escolhas e realizaes. Sem dvida alguma so o meu porto seguro e maiores contribuintes para realizao desta etapa que conquistamos juntos. Obrigado pelo carinho, pela formao de carter e sabedoria repassada. Amo vocs! A minha irm Clia Maria pelo apoio confortante a cada momento de apreenso, pelo incentivo, pelas brincadeiras e pela compreenso das minhas manias perfeccionistas. A Prof Carla Alessandra Lima Reis que apesar das muitas responsabilidades concedeu parte do seu tempo para orientao deste trabalho. Pelo incentivo, pelas oportunidades e pelos ensinamentos repassados. Ao Breno pelo apoio e incentivo durante a realizao deste trabalho, por todas as recomendaes e alertas passados, pelas preocupaes que me ajudaram a concluir este trabalho. A Laudemira por toda sua ajuda na concretizao desta proposta. Ao Marcelo Pereira que desde o incio incentivou e participou na elaborao desde projeto. Aos amigos do LABES (incluindo agregados e ex-membros) pelo apoio durante esse tempo de convivncia e muito compartilhamento de sabedoria que levaram ao desenvolvimento deste trabalho. Ao Liken e Murilo pela diviso das aflies e conquistas muito inspiradoras, pelas muitas conversas via MSN nas madrugadas afim. A todos pela companhia divertidssima nas sesses de CS, as idas ao cinema, churrascos, pizzas enfim pelos muitos momentos de descontrao. Aos amigos do curso pela companhia durante o percurso percorrido na graduao, os trabalhos realizados, as agonias de fim de semestre e todos momentos divertidos. A minha famlia que mesmo de longe sempre repassava incentivo e fora para continuao desta etapa. Em especial ao meu irmo Erlan que sempre me apoiou e compartilhou deste sonho. Aos meus amigos que me deram fora, acreditaram na minha capacidade e me apoiaram das mais diferentes formas para concluir esta etapa. A todos que contriburam para realizao deste trabalho direta ou indiretamente, muito obrigada! Valeu muito :D !!

SUMRIO
LISTA DE TABELAS .............................................................................................................. 8 LISTA DE FIGURAS............................................................................................................... 9 LISTA DE SIGLAS ................................................................................................................ 10 RESUMO................................................................................................................................. 11 ABSTRACT ............................................................................................................................ 12 1 INTRODUO ............................................................................................................... 12 1.1 1.2 1.3 2 2.1 2.1.1 2.1.2 2.2 2.2.1 2.2.2 3 3.1 3.1.1 3.1.2 3.1.3 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 4 4.1 4.2 4.3 Motivaes ............................................................................................................... 13 Objetivos Gerais e Metodologia ............................................................................... 15 Organizao do Texto............................................................................................... 16 Processo de Software ................................................................................................ 17 Modelagem de Processo de Software ................................................................. 18 Execuo de Processo de Software .................................................................... 20 Ambiente WebAPSEE.............................................................................................. 22 Modelagem no Ambiente WebAPSEE............................................................... 23 Execuo no Ambiente WebAPSEE .................................................................. 25 Normas e Modelos de Referncia............................................................................. 29 Norma ISO/IEC 12207 ....................................................................................... 29 CMMI ................................................................................................................. 30 MPS.BR .............................................................................................................. 32 PMBOK .................................................................................................................... 34 Planejamento do Projeto ........................................................................................... 36 Plano de Alocao de Recursos .......................................................................... 37 Plano de Comunicao ....................................................................................... 37 Plano de Custos .................................................................................................. 38 Plano de Gerncia de Documentos ..................................................................... 38 Plano do Processo ............................................................................................... 39 Plano de Recursos Humanos .............................................................................. 39 Plano de Riscos................................................................................................... 40 Plano de Treinamento ......................................................................................... 41 Estao TABA .......................................................................................................... 43 Microsoft Office Project (MS-PROJECT) ............................................................... 45 OpenProj ................................................................................................................... 47

TECNOLOGIA DE PROCESSO DE SOFTWARE .................................................... 17

GERNCIA DE PROJETOS......................................................................................... 28

FERRAMENTAS PARA GERENCIAMENTO DE PROJETOS ............................. 42

PROPOSTA DE GERAO DE PLANO DO PROJETO NO WEBAPSEE .......... 50 5.1 5.2 5.3 5.3.1 5.3.2 5.4 5.4.1 5.4.2 Arquitetura do Ambiente WebAPSEE ..................................................................... 53 WebAPSEE Reports ................................................................................................. 54 Propostas de Adaptaes do Modelo de Dados ........................................................ 57 Pacote Organization ........................................................................................... 58 Modificaes no Pacote Organization Policies ................................................. 60 API Utilizada na Gerao de Plano Do Projeto ........................................................ 61 API RTFTemplate .............................................................................................. 62 Integrao com Relatrios do WebAPSEE ........................................................ 64 Interface Grfica para Cadastro dos Planos .............................................................. 66 Plano do Processo ............................................................................................... 67 Plano de Comunicao ....................................................................................... 71 Plano de Riscos................................................................................................... 72 Plano de Treinamento ......................................................................................... 73 Relatrios do WebAPSEE .................................................................................. 74 Gerao de Plano do Projeto .................................................................................... 75 Modificaes no Plano do Projeto ............................................................................ 76 Exemplo de Uso do Prottipo................................................................................... 76 Aderncia aos Resultados MPS.BR.......................................................................... 81 Contribuies ............................................................................................................ 86 Limitaes do Trabalho ............................................................................................ 86 Trabalhos Futuros ..................................................................................................... 86 Consideraes Finais ................................................................................................ 87

PROTTIPO DO MODELO PROPOSTO PARA O WEBAPSEE .......................... 66 6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.2 6.3 6.4 6.5

CONCLUSES ............................................................................................................... 85 7.1 7.2 7.3 7.4

REFERNCIAS ..................................................................................................................... 88 ANEXO 1 ................................................................................................................................. 93

LISTA DE TABELAS
Tabela 1 - Lista de Requisitos da Proposta .............................................................................. 50 Tabela 2 - Planos Integrados .................................................................................................... 76 Tabela 3 - Resultados esperados contemplados ....................................................................... 82

LISTA DE FIGURAS
Figura 1 - Processo de desenvolvimento de software (REIS, 2002b) ...................................... 18 Figura 2 - Mecanismo de execuo e outros componentes (LIMA REIS, 2003)..................... 21 Figura 3 - TaskAgenda do WebAPSEE .................................................................................... 23 Figura 4 - Notao grfica da WebAPSEE-PML ..................................................................... 24 Figura 5 - Notao para conexes na WebAPSEE-PML ......................................................... 24 Figura 6 - Modelo de processo e as principais notaes da WebAPSEE-PML ....................... 25 Figura 7 - Processo em execuo no WebAPSEE.................................................................... 26 Figura 8 - Atualizao na execuo do processo ...................................................................... 27 Figura 9 - Tela principal da ferramenta AdapPro da Estao TABA....................................... 44 Figura 10 - Tela de avaliao do Plano do Projeto ................................................................... 45 Figura 11 - Tela principal do MS-PROJECT ........................................................................... 46 Figura 12 - Relatrio de viso geral gerado pela ferramenta ................................................... 47 Figura 13 - Tela principal do OpenProj exibindo um grfico de Gantt .................................... 48 Figura 14 - Relatrio de tarefas do projeto do tipo Task Information ...................................... 49 Figura 15 - Diagrama de atividades para gerao de Plano do Projeto .................................... 52 Figura 16 - Camadas que compe a arquitetura do WebAPSSE (LIMA et. al., 2006a) .......... 54 Figura 17 - Formulrio de Relatrios Nvel G MPS.BR .......................................................... 55 Figura 18 - Cronograma de atividades do projeto .................................................................... 56 Figura 19 - Plano de Recursos Humanos do projeto ................................................................ 57 Figura 20 - Componentes do meta modelo do WebAPSEE ..................................................... 58 Figura 21 - Pacote Organization aspectos da estrutura organizacional (LABES, 2008)....... 59 Figura 22 - Variao do Modelo de Classes do pacote OrganizationPolicies ......................... 60 Figura 23 - Gerao do documento usando RTFTemplat (RTTEMPLATE, 2008)................. 62 Figura 24 - trecho de cdigo de uma classe template ............................................................... 63 Figura 25 - Macros no arquivo RTFSource .............................................................................. 64 Figura 26 - Reutilizao de consultas e macros ....................................................................... 65 Figura 27 - Antigo formulrio de Projetos ............................................................................... 67 Figura 28 - Submenu Projetos e os itens para cada plano ........................................................ 67 Figura 29 - Novo formulrio de cadastro de projeto ................................................................ 68 Figura 30 - Importao de Projeto ............................................................................................ 69 Figura 31 - Aba de caractersticas para escolha do processo ................................................... 70 Figura 32 - Aba para avaliao inicial das caractersticas de qualidade do produto ................ 71 Figura 33 - Plano de Comunicao........................................................................................... 72 Figura 34 - Plano de Riscos ...................................................................................................... 73 Figura 35 - Formulrio de Plano de Treinamento .................................................................... 74 Figura 36 - Formulrio para gerao de Plano do Projeto ........................................................ 75 Figura 37 - Exemplo de Plano do Processo .............................................................................. 78 Figura 38 - EAP gerada no Plano do Projeto ........................................................................... 79 Figura 39 - Exemplo de Plano de Treinamento ........................................................................ 79 Figura 40 - Plano de Comunicao........................................................................................... 80 Figura 41 - Plano de riscos e riscos gerenciado........................................................................ 81

LISTA DE SIGLAS

AP - Atributos do Processo API - Application Programming Interface CASE - Computer-Aided Software Enginnering CMMI - Capability Maturity Model Integration COPPE - Instituto Alberto Luiz Coimbra de Ps-Graduao e Pesquisa de Engenharia CTIC - Centro de Tecnologia da Informao e Comunicao. EAP - Estrutura Analtica do Projeto GPR - Gerncia de Projetos GUI - Graphical User Interface IEC - International Electrotechinical Comission IPPD - Integrated Product and Process Development ISO - International Organization for Standardization LABES - Laboratrio de Engenharia de Software MA-MPS - Mtodo de Avaliao para Melhoria de Processo de Software MN-MPS - Modelo de Negcio para Melhoria de Processo de Software. MPP - Arquivo do Microsoft Project MPS.BR - Melhoria do Processo de Software Brasileiro. MR-MPS - Modelo de Referncia para Melhoria de Processo de Software PDF - Portable Document Format PMBOK - Project Management Body of Knowledge PML - Process Modelling Language PSEE - Process-Centered Software Engineering Environments. RAP - Resultado do Atributo de Processo RBS - Risk Breakdown Structure RMI - Remote Method Invocation RTF - Rich Text Format SE - Systems Engineering SEI - Software Engineering Institute SOFTEX - Sociedade para Promoo da Excelncia do Software Brasileiro SS - Supplier Sourcing SW - Software Engineering UFPA - Universidade Federal do Par UML - Unified Modeling Language WBS - Work Breakdown Structure WWW - World Wide Web XLS - Microsoft Excel file format XML - Xtensible Markup Language

RESUMO
O processo utilizado para desenvolver e manter um software afeta diretamente o custo, a qualidade e o prazo de entrega do produto. E uma das reas-chave desse processo que busca a melhoria dos processos a Gerncia de Projetos, considerada como a aplicao de conhecimentos, habilidades, ferramentas e tcnicas das atividades do projeto, a fim de atender os requisitos das partes interessadas. Como forma de auxiliar os gerentes em atividades de monitorao e execuo do processo so realizadas algumas tarefas de planejamento que geram alguns documentos, como o a Estrutura Analtica do Projeto e o Cronograma, necessrios para definio, execuo e acompanhamento de um projeto. O desenvolvimento e gerenciamento desses documentos so fatores que facilitam o entendimento geral do projeto. Alguns documentos gerados com a realizao deste planejamento do projeto so o Plano de Recursos Humanos, o Plano de Riscos, o Plano de Treinamento, entre outros. Atravs da implantao de processos de software em uma organizao do Estado, percebeu-se o quanto a integrao desses planos em um nico documento, o Plano do Projeto, era um fator importante, pois se tornava a principal fonte de informaes de como o projeto havia sido planejado, como estava sendo executado, monitorado e controlado, e seu encerramento. Por tratar-se se um documento de integrao e coordenao, a sua gerao trabalhosa e pode provocar atraso na fase de planejamento do processo. O uso desse documento como referncia nica propicia uma maior visibilidade do projeto facilitando o gerenciamento e a formao de uma base histrica da organizao. A proposta desse trabalho apoiar a gerao e a reviso do Plano do Projeto integrado atravs do ambiente WebAPSEE, permitindo ao gerente um acompanhamento mais preciso das atividades do processo e auxlio em etapas posteriores de melhorias no processo. Para isso, necessria a evoluo do ambiente WebAPSEE, atravs da insero de novos formulrios de cadastramento dos diferentes planos, para dar apoio automatizado, atravs de um guia, gerao e alterao do Plano do Projeto. PALAVRAS-CHAVE: Gerncia de Projetos de Software, Planejamento do Projeto, Tecnologia de Processo de Software.

ABSTRACT
The process used in order to develop and maintain software impacts directly on products costs, quality and schedule. And one of the key process areas that aims to improve them is the Project Management, considered as the application of knowledge, skills, tools and techniques order to supply stakeholders requirements. As a way to help managers on project monitoring and execution, they need to perform some planning activities which generate documents. As an example, there are the Work Breakdown Structure and Chronogram that are necessary to design, implement and monitor a project. The development and management of these documents are factors that facilitate the general understanding of the project. Some documents generated by carrying out this project plan are the Human Resources Plan, the Risks Plan, the Training Plan, and others. Through the use of software processes in a Stateowned organization, it was possible to perceive how important was to integrate those plans into a Project Plan, since a single document became the main source of information on how the project had been planned, was being implemented, monitored and controlled, as well as its conclusion. Considering it is a document for integration and coordination, its generation is a time-consuming activity, what can delay the project planning phase. The use of this document as a unique reference provides a greater project visibility what facilitates the management and the development of a historical basis of the organization. This work aims to support the generation and the revision of the Integrated Project Plan through the environment WebAPSEE, allowing the manager to have a more accurate monitoring of the activities of the process and also providing help at process improvement later stages. This requires an evolution on WebAPSEE environment, in order to create of new forms for registration of the various plans and provide automated support for the Project Plan generation and modification. KEY WORDS: Software Project Management, Project Planning, Software Process Technology.

12

1 INTRODUO

Com a evoluo da tecnologia, o mercado tornou-se cada vez mais dependente e exigente quanto aos softwares que so disponibilizados. A importncia do software, em vrios setores do mercado, torna-se fator crtico para que o investimento em desenvolvimento de aplicaes tenha adquirido propores cada vez maiores, principalmente no que diz respeito qualidade de produto (FUGETTA, 2000). De acordo com a norma ISO/IEC 9126-1 (ISO/IEC 9126-1, 2003), a qualidade do produto de software est fortemente relacionada qualidade do processo utilizado em seu desenvolvimento. Por esta razo, necessrio desenvolver processos cada vez mais completos e aderentes realidade das organizaes que o utilizam. Ambientes de Engenharia de software Centrados em Processos ou PSEEs (ProcessCentered Software Engineering Environments) tm como principal objetivo auxiliar a modelagem e execuo desses processos de desenvolvimento de software. A utilizao de PSEEs auxilia, principalmente, no que diz respeito a forar a definio da execuo do processo e como benefcios traz melhor comunicao entre as pessoas da organizao, consistncia do que est sendo feito e gerncia dos componentes envolvidos contribuindo na coordenao das atividades (DONZELLI, 2006; FUGGETTA, 2000). O uso de PSEEs alm de auxiliar no desenvolvimento de processos de software, tambm auxilia na gerncia de projetos, pois possibilita a coord=00enao de atividades das equipes de desenvolvimento, o acompanhamento de prazos, a alocao e uso de recursos e a reutilizao de processos j existentes na organizao com boas prticas de projetos j finalizados (LIMA REIS, 2003; REIS, 2002). Ferramentas voltadas para o gerenciamento de projetos facilitam a forma com que os gerentes desenvolvem suas atividades. Ou seja, o gerente direciona seu esforo no controle e melhoria do processo utilizado, diminuindo esforos na modelagem e execuo de processos uma vez que essas atividades so auxiliadas pelos PSEEs.

13 O desenvolvimento de PSEEs atualmente requer maior automao das atividades de gerncia atravs do auxlio na modelagem de processo segundo diferentes perspectivas (uso de um editor grfico ou textual), auxlio monitorao da execuo de processos, distribuio das informaes, e tambm a integrao do ambiente com outras ferramentas conforme cita Lima et al (2006a). Inserido nesse contexto de auxlio aos gerentes em atividades de monitorao e execuo do processo, algumas tarefas de planejamento e documentao so necessrias para definio, execuo e acompanhamento de um projeto. O desenvolvimento e gerenciamento destes documentos so fatores que facilitam o entendimento geral do projeto, alm de facilitar a gerncia de conhecimento na organizao atravs de alguns artefatos (RUS e LINDIVALL, 2002). Voltado para a concepo automatizada deste tipo de documentao, o presente trabalho apresenta uma proposta que visa apoiar a gerao e reviso de Plano do Projeto, um dos documentos iniciais da fase de planejamento de um projeto, atravs do ambiente WebAPSEE. WebAPSEE um PSEE desenvolvido como Software Livre pelo Laboratrio de Engenharia de Software (LABES) da Universidade Federal do Par (UFPA) (LIMA et al, 2006b) no qual a sua verso atual baseada em modelos propostos por Lima Reis (2003). Tendo como principal objetivo a modelagem e execuo de processos de software, alm de outras preocupaes como a reutilizao e instanciao de processos e poltica de alocao pessoas (SILVA, 2007; COSTA e SALES, 2007), a ferramenta tambm oferece apoio ao desenvolvimento de documentao para projetos atravs de relatrios organizacionais, cronograma de atividades, alocao de recursos humanos, gerencia de documentos, estrutura analtica de processos. Primeiramente, so apresentadas as motivaes para a realizao deste trabalho na seo 1.1. Os objetivos gerais e especficos pretendidos so apresentados em seguida na seo 1.2. E finalizando este primeiro captulo, apresentada a estrutura do restante do texto.

1.1 Motivaes
A busca pela melhoria da qualidade de software vem motivando empresas a adotarem comportamentos diferenciados. Um exemplo desses comportamentos o aumento da maturidade dos seus processos de software, pois se trata de um requisito requerido por modelos de melhoria de processos como o programa para Melhoria do Processo de Software Brasileiro (MPS.BR) (SOFTEX 2006a), que exige profissionais com formao especfica:

14 domnio da tecnologia de desenvolvimento de software, gesto organizacional, alm de conhecimento de processos clssicos e prticas metodolgicas. A melhoria da qualidade de produtos de software passou a ser, alm de um diferencial, um fator crtico para a sobrevivncia das empresas. Buscando alcanar tais nveis de maturidade foi criado um Grupo de Melhoria de Processos de Software no CTIC - UFPA (Centro de Tecnologia da Informao e Comunicao), o grupo MPS/CTIC. Com isso, o grupo se props a ajudar a aumentar a maturidade no desenvolvimento de software da organizao, com possibilidade de efeitos positivos nas outras reas de atuao da mesma (como suporte tcnico, por exemplo) (MPS-CTIC, 2007). Para auxiliar a adoo de uma nova metodologia e implantao de um processo de desenvolvimento de software na organizao, foi utilizada o ambiente WebAPSEE como apoio ferramental metodologia. Este ambiente continua evoluindo, com novas funcionalidades e ferramentas, a fim de atender plenamente s necessidades da gesto do processo de software em todas as suas etapas. Durante a implantao do processo de software na organizao, percebeu-se o quanto a integrao de diferentes documentos, gerados na fase de planejamento do processo, em um nico documento, no caso o Plano do Projeto, era um fator importante, pois este se tornava a principal fonte de informaes de como o projeto havia sido planejado, como estava sendo executado, monitorado e controlado, e seu encerramento. Alm disso, o uso desse documento como referncia nica propiciava uma maior visibilidade do projeto facilitando o gerenciamento e a formao de uma base histrica da organizao. Apesar de o ambiente WebAPSEE possibilitar a gerao automtica de algumas evidncias que faziam parte do Plano do Projeto, como cronograma e estrutura analtica do projeto, a sua gerao era trabalhosa pois se tratava de um documento de integrao e coordenao de diferentes planos. A integrao dos planos em documentos externos ferramenta aumenta o esforo na fase de planejamento do projeto. Baseado nesta experincia, e visando aumentar as funcionalidades oferecidas pelo ambiente WebAPSEE, surgiu a necessidade de apoiar a gerao de Plano do Projeto por meio da ferramenta. Alm de agilizar a maneira como alguns documentos so gerados, a proposta pretende apoiar a gerao de novos planos ainda no oferecidos pelo ambiente como o Plano de Riscos, o Plano de Treinamento, o Plano de Comunicao entre outros. A gerao automatizada desses planos em conformidade com alguns padres de qualidade, tal como

15 MPS.BR, alm de permitir maior organizao do planejamento do projeto, poder otimizar a fase de planejamento do processo.

1.2 Objetivos Gerais e Metodologia

Este trabalho tem como principal objetivo auxiliar a gerao do Plano do Projeto integrado atravs do ambiente WebAPSEE. A proposta baseada no estudo de tcnicas de engenharia de software e gerncia de projetos em ambientes automatizados de processo de software. Entre os objetivos especficos, est a utilizao de um modelo padro de Plano do Projeto para construo do contedo do documento. Este modelo foi elaborado baseado na experincia obtida com a implantao do processo no CTIC - UFPAe integra diferentes planos utilizados durante o projeto, a saber: Plano do Processo, Plano de Treinamento, Plano de Comunicao, Plano de Riscos, Plano de Recursos Humanos, Plano de Alocao de Recursos, Plano de Custos, Plano de Gerncia de Documentos. Estes planos sero detalhados na seo 3.3 (o modelo utilizado na elaborao da proposta est disponvel no Anexo 1). Noutro objetivo especfico, a proposta pretende fazer mudanas no ambiente WebAPSEE como a definio de novas interfaces com o usurio que auxiliem na obteno direta dos dados referentes aos planos citados, a criao de um guia de gerao e reviso de plano do projeto auxiliando desde a definio do escopo do projeto at o gerenciamento de mudanas. A metodologia utilizada para elaborao desta proposta baseada na experincia adquirida com a implantao do processo de desenvolvimento de software no CTIC UFPA. Um acompanhamento da metodologia usada para implantao do processo permitiu o levantamento dos requisitos da proposta Foi realizado um estudo de guias, normas e modelos de referncia que serviram como base para elaborao do template do Plano do Projeto usado na proposta, durante a implantao do processo o template foi adaptado at ser estabelecida a verso utilizada na proposta. Em seguida prottipos das novas interfaces da proposta foram elaborados e validados durante entrevistas com gerentes de projetos do LABES e CTIC UFPA.

16

1.3 Organizao do Texto

Nesta seo foi apresentado o contexto onde o trabalho est inserido, bem com principais motivaes e objetivos. O restante do trabalho proposto est da seguinte forma: Na seo 2 apresentando os conceitos que envolvem a tecnologia de processos de softwares, enfatizando os principais objetivos da modelagem de processos e os seus componentes e apresentando ferramentas utilizadas nessa tarefa, com foco no ambiente WebAPSEE. Na seo 3 descrito a respeito da rea de gerncia de projetos e seu principal objetivo, em seguida as normas e modelos de referncias para embasamento do trabalho so apresentadas. Finalizando a seo contextualizado o planejamento do projeto, como este poder ser desenvolvido e um resumo dos diferenciados planos que compe o plano do projeto. Na seo 4 so apresentadas algumas ferramentas para gerenciamento de projetos, descrevendo suas principais caractersticas e como alguns relatrios so gerados. Na seo 5 descrita a arquitetura do ambiente WebAPSEE e os pacotes que so relevantes para a elaborao da proposta, as adaptaes feitas nestes pacotes e como estas foram implementadas. A API utilizada para gerao do Plano descrita nessa seo. Na seo 6 apresentado aspectos do prottipo implementado no WebAPSEE, como uma implementao simplificada do modelo proposto, dando uma viso geral do prottipo do ponto de vista do usurio, e um exemplo de uso do prottipo. Na seo 7 so apresentadas as consideraes finais a respeito do trabalho, bem como suas contribuies, limitaes e trabalhos futuros.

17

2 TECNOLOGIA DE PROCESSO DE SOFTWARE

O trabalho proposto encontra-se inserido no contexto de tecnologias utilizadas no auxlio gerncia e definio de processos de software, constituindo a rea de pesquisa denominada Tecnologia de Processo de Software (GIMENES, 2002). Para melhor entendimento da proposta e terminologias apresentadas, so descritos, neste captulo, alguns conceitos referentes gesto de processos de software. Primeiramente, apresentada uma descrio sobre o processo de software e suas particularidades. Em seguida, so apresentadas algumas definies e caractersticas da modelagem e execuo de processos de software. Finalizando, o captulo feita uma apresentao a respeito da linguagem de modelagem e do mecanismo de execuo de processos do ambiente no qual a proposta est inserida: o WebAPSEE.

2.1 Processo de Software

A respeito de processo de software, Humphrey (1988) afirma que um processo de software definido como uma seqncia de tarefas que, quando executadas de maneira correta, produzem os resultados esperados. Para melhor definio de um processo de software algumas caractersticas devem ser consideradas, como o inter-relacionamento de fatores organizacionais, a cultura, a tecnologia e fatores econmicos (FUGGETA, 2000). A necessidade de se definir e controlar processos de software ocasionou uma nova viso a respeito dos ADS (Ambiente de Desenvolvimento de Software). Tais ambientes incorporam mecanismos para controle do processo de desenvolvimento de software atravs da automao de processos atravs da coordenao de atividades, colaborao e comunicao dos recursos (humanos, materiais e tecnolgicos) envolvidos durante o ciclo de desenvolvimento, monitorao sobre a execuo do processo e registro de dados da evoluo do processo (DOWNSON, 1993; FEILER e HUMPREY, 1993). Nesses ambientes os

18 requisitos de software podem ser entendidos como parmetros do processo, os objetos de software so vistos como papel de variveis, e as ferramentas do ambiente so tratadas como operadores que trabalham de maneira integrada; ou como processos bem definidos de mais baixo nvel que criam e transformam os objetivos de software (OSTERWEIL, 1987). Essa nova viso de Osterweil culminou na criao dos ambientes de engenharia de software orientados a processos (PSEEs) que tratam do conceito de programao de processos. Os PSEEs so caracterizados principalmente pelo auxlio modelagem e execuo de processos de software, com alvo de contribuir com a gerncia de atividades, pessoas e recursos envolvidos na produo e manuteno de um software (LIMA REIS, 2003). As prximas sees tratam dos principais componentes de um processo de software e sua execuo.

2.1.1 Modelagem de Processo de Software

Segundo Reis (2002a) um processo de software envolve atividades complexas desempenhadas por pessoas (agentes) com as mais diversas capacidades, sendo controladas por gerentes de desenvolvimento e uma forma de auxiliar este gerenciamento atravs da sua descrio formal, ou seja, um modelo de processo. Conforme a Figura 1, a partir dos requisitos iniciais (que envolvem dados iniciais, procedimentos a serem adotadas, algumas premissas e restries) de um problema a ser resolvido, um modelo de processo de software ser adotado para transformar os requisitos em um produto de software. Para planejar o processo de desenvolvimento a ser adotado, alternativas so avaliadas para definir e organizar as atividades relacionadas, perodos devem ser estimados de acordo com os prazos estabelecidos e os recursos e pessoas devem ser alocados dentro das premissas e restries de custos determinadas.

Figura 1 - Processo de desenvolvimento de software (REIS, 2002b)

19

Para definio desses modelos de processo, Falbo (1998) cita alguns conceitos utilizados na modelagem de processo: Atividades: so tarefas que deveram ser realizadas, representam passos relevantes no produto de software. Podem ser classificadas como atividades de gerncia, atividades de construo e atividades de avaliao de qualidade. Em sua realizao podem adotar procedimentos, requerer recursos e consumir ou produzir artefatos. Podem ser decompostas em sub-atividades, e dependentes ou no de outras atividades, as pr-atividades. Artefatos: produtos de software produzidos (artefatos de sada) ou consumidos (artefatos de entrada) durante a realizao das atividades. Podem ser classificados em artefatos de cdigo, componentes de software e documentos. Procedimentos: condutas bem estabelecidas, ordenadas para realizao das atividades. Podem ser classificados como: mtodos, tcnicas e diretrizes. Recursos: fatores necessrios a execuo de uma atividade. So classificados em: recursos humanos, recursos de hardware, recursos de software. Agentes: profissionais relacionados a atividades de um processo. Podem possuir diferentes cargos para determinadas atividades, o que envolve uma percepo diferente dentro de um processo. Os modelos de processo de software geralmente so definidos sobre uma Linguagem de Modelagem de Processo, uma PML (do ingls Process Modelling Language) que contm informaes para descrever e manipular o processo, informaes a respeito de quem, como, onde, quando as atividades sero realizadas. Segundo Fuggetta (2000), PMLs so baseadas em paradigmas lingsticos estendidos conforme a necessidade de aumentar o seu poder de expresso. Atravs dessa expanso, as PMLs so utilizadas em diferentes situaes: entendimento do processo, projeto do processo, treinamento e educao, simulao e otimizao do processo, apoio ao processo (SILVA, 2007). As PMLs fazem parte de uma categoria especfica de linguagens de especificao voltada definio e automao de processos de software. Apesar de herdarem algumas caractersticas sintticas de cunho geral como a abstrao, a modularidade e a generalizao, essas linguagens especficas possuem algumas caractersticas prprias, que a afastam de

20 linguagens de programao de propsito geral. Algumas abordagens de modelagem de processos e suas classificaes podem ser encontradas em Arbaoui et al (2002). Independente do paradigma adotado, a maioria das abordagens existentes centrada na idia de compor processos como atividades. A vantagem disso o fornecimento de um estilo intuitivo na especificao da ordem dos eventos, facilitando a execuo e acompanhamento dos processos. Atualmente abordagens hbridas so as mais usadas, o que promove um maior aprendizado e uso de diferentes elementos sintticos para uma modelagem mais bem estruturada e de fcil entendimento (REIS e NUNES, 1999). A tarefa de modelagem de processos de software diretamente associada a sua execuo, o que ser explicada na seo seguinte.

2.1.2 Execuo de Processo de Software

Para permitir que a gerncia do desenvolvimento seja automatizada preciso que os modelos de processo sejam executados. A fase de execuo de um modelo de processo deve levar em considerao fatores como a coordenao de mltiplos atores envolvidos (agentes do processo) e sua interao com outras ferramentas disponveis (NGUYEN e WANG, 1997). Para isso faz-se necessrio que um modelo seja executvel (ou instanciado), ou seja, o modelo dever fazer uma descrio dos detalhes do processo ao ponto deste ser executado por uma mquina (FRANCH e RIB, 2002). Na literatura so apresentados trs tipos principais de modelos, sendo estes descritos a seguir de acordo com Franch e Rib (2002):

Modelos Abstratos (Process Patterns ou Templates): fornecem um modelo de soluo para problemas semelhantes, onde o processo ainda no tem informaes especficas de uma organizao. Nesse caso o modelo tem um processo de alto nvel, podendo atender a requisitos de um processo especfico ou ser combinado com outros templates. Modelos Instanciados (ou executveis): modelos de processo pronto para serem executados. Estes podem ser adaptados de modelos abstratos. Nesses os objetivos podem ser mais especficos como prazos, oramentos, recursos. Modelos em Execuo (ou executados): modelos instanciados que tem um histrico da execuo de um processo, incluindo eventos e desvios (modificaes feitas no modelo associado).

21 Na fase de execuo de um processo, o mecanismo de execuo controla a interao entre os gerentes e os desenvolvedores, podendo obter respostas sobre o andamento das atividades do processo. Considerando a natureza dinmica e criativa do processo de software, muitas mudanas podem ocorrer durante sua execuo, e segundo Lima Reis (2003) estabelece que o conceito de flexibilidade de execuo de processos usado para definir a propriedade de mecanismos de execuo que toleram a informalidade, o envolvimento humano e processos incompletos sem deixar que os processos tornem-se inconsistentes, assim a mquina de execuo de um PSEE deve ser flexvel o bastante para permitir que alteraes sejam feitas sem perda de dados, ou seja, a consistncia dever ser mantida. O ncleo de um PSEE responsvel pela execuo de um processo de software, para melhor entendimento do seu funcionamento, a Figura 2 apresenta a arquitetura de um PSEE segundo Lima Reis (2000). Nessa figura o mecanismo de execuo o centro que interpreta, de acordo com a linguagem utilizada, o modelo de processo instanciado alm da interao de usurios que fornecem feedback sobre o processo invocando ferramentas e alocao de recursos.

Figura 2 - Mecanismo de execuo e outros componentes (LIMA REIS, 2003)

A execuo de modelos de processo importante para visualizao do andamento do processo de desenvolvimento de software, dessa forma o gerente tem um melhor entendimento do que est ocorrendo na organizao e como andam as atividades. Um

22 acompanhamento do processo permite a organizao relatar suas lies aprendidas para aperfeioamento do processo podendo inferir em histricos organizacionais melhorados.

2.2 Ambiente WebAPSEE

De acordo com Lima et al (2006b), o ambiente WebAPSEE resulta de projetos de pesquisa em andamento. Este ambiente foi originado a partir de um PSEE chamado APSEE, que adota solues inovadoras para problemas crticos quanto gerncia e execuo automatizada de processos de software (LIMA REIS, 2003). O ambiente possui uma arquitetura distribuda e faz uso de Servios Web o que possibilita portabilidade em diferentes plataformas e permite a agregao de novas ferramentas ao ambiente. No ambiente WebAPSEE possvel modelagem de processos de software, para isso utilizada a PML WebAPSEE-PML, essa linguagem foi definida em Lima Reis (2003), e foi evoluda conforme apresentado em (LABES, 2008). Alm de permitir a modelagem de processos o ambiente permite execuo flexvel de processo, faz isso permitindo mudanas dinmicas no processo, ou seja, mudanas em tempo de execuo do processo, isso sem comprometer a consistncia do mesmo a partir de regras de execuo implementadas dentro do sistema (LIMA et al, 2006b). A interao com o ambiente realizada por meio de trs componentes: o WebAPSEE Server, o Manager Console e a TaskAgenda. O componente ManagerConsole permite a interao entre gerente e PSEE. Na TaskAgenda so informados aos agentes informaes quanto a execuo das tarefas ocorridas no ManagerConsole. Atravs da TaskAgenda (Figura 3) possvel a visualizao das tarefas que devem ser realizadas pelos agentes, assim durante a interao com a agenda, o gerente poder ter feedeback quanto ao andamento das atividades do processo. Atravs da agenda tambm possvel fazer download e upload de artefatos, porm a detalhes sobre essas funcionalidades fogem ao escopo desse trabalho e podem ser encontradas no manual de usurio da ferramenta.

23

lista de tarefas

Figura 3 - TaskAgenda do WebAPSEE

2.2.1 Modelagem no Ambiente WebAPSEE

A linguagem de modelagem de processos de software do WebAPSEE baseada em redes de atividades que podem ser decompostas. Neste formalismo, um modelo de processo pode ser construdo a partir de smbolos grficos conectados e o detalhamento do relacionamento com os outros componentes do modelo (como por exemplo, as informaes organizacionais e descrio dos artefatos, entre outros) feito atravs de formulrios especficos, que apiam essa tarefa (LIMA REIS, 2003). Algumas notaes grficas so resumidas na Figura 4 que mostra a notao de atividades, agentes, recursos e artefatos fornecidos no ambiente.

24

Figura 4 - Notao grfica da WebAPSEE-PML

Na Figura 5 so exibidas as notaes de conexes, que facilitam o entendimento da linguagem de modelagem do ambiente. Atravs dessas conexes entre as atividades, a mquina de execuo reconhece a ordem de execuo do processo podendo assim manter a integridade dos dados. Alm disso, atravs dessa visualizao o gerente poder acompanhar qual a dependncia entre as atividades, os agentes alocados para cada uma, os artefatos que esto sendo produzidos ou consumidos e os recursos que so utilizados em cada etapa.

Figura 5 - Notao para conexes na WebAPSEE-PML

Para completar a definio a respeito da WebAPSEE-PML, na Figura 6 apresentado o formalismo de modelagem para o ambiente WebAPSEE que permite representao grfica de processo de software. Nessa figura um modelo de processo apresentado contendo as principais notaes anteriormente mostradas atravs da ilustrao do ManagerConsole.

25

Figura 6 - Modelo de processo e as principais notaes da WebAPSEE-PML

2.2.2 Execuo no Ambiente WebAPSEE

O ambiente WebAPSEE prov um mecanismo de execuo dinmica para processos de software. Essa execuo feita atravs de uma mquina de execuo que recebe como entrada um modelo de processo, formalmente definido pela WebPASEE-PML, que se deseja executar. O mecanismo utilizado no WebPASEE possibilita trs tipos principais de mudanas: (1) em uma parte do processo em execuo, onde o fluxo ainda no alcanou esse parte;(2) em um parte do processo alcanado pelo fluxo,porm a mudana no afetar no estado atual do processo, ou seja, continuar coerente com o modelo de processo original; (3) em uma parte do processo depois ou durante sua execuo, nesse caso ser preciso execut-lo novamente. O uso desse mecanismo dinmico de mudanas contribui bastante no gerenciamento de um projeto. Considerando as diversas mudanas que podem ocorrer durante um projeto, algumas mudanas no processo podem ser necessrias e torna-se invivel a iniciao de uma nova execuo para acomodar essas mudanas. Com esse modelo de mecanismo adotado no WebAPSEE, alteraes podem ser feitas durante a execuo do processo (mudanas das atividades, pessoas ou recursos) mantendo a consistncia no fluxo das atividades e dos dados referentes ao processo (LABES, 2008). O auxlio automtico a esse controle de mudanas

26 prioriza a atuao do gerente de projetos nas questes mais direcionadas a atividade de gerenciar, alm de incentivar melhorias no processo adotado na organizao. Baseado nessas mudanas um exemplo de execuo e modificao dinmica, com auxlio automtico para as modificaes, ser apresentado nas figuras 7 e 8. Na Figura 7 apresentada uma parte de um processo em execuo, onde a atividade Avaliar Viabilidade do Projeto encontra-se no estado finalizado (finish) disparando para que a atividade Solicitao de Mudana do Plano fique no estado pronta para ser iniciada (ready), aguardando o agente iniciar sua atividade na TaskAgenda.

Figura 7 - Processo em execuo no WebAPSEE

Na Figura 8 mostrado uma nova atividade inserida no processo, a atividade Avaliao do Plano. Quando esta nova atividade inserida a atividade Solicitao de Mudana do Plano mudou seu estado de pronta (ready) para esperando (waiting), com a mudana temporal entre as atividades houve uma atualizao na mquina de execuo.

27

Figura 8 - Atualizao na execuo do processo

28

3 GERNCIA DE PROJETOS

De acordo com Thayer (1997), a gerncia de projetos pode ser considerada como um conjunto de procedimentos, prticas, tecnologias, habilidades e experincias que visam a realizao de planejamento, organizao, alocao de recursos, superviso e controle necessrios para uma gerncia de sucesso. Quando o projeto refere-se a desenvolvimento de software chamado de gerncia de projeto de software. Na rea de software e tecnologia da informao (TI), a gerncia de projetos assume uma importncia maior. Isto se deve, em parte, pelo entendimento de que uma parte significativa do insucesso em projetos de software est relacionada a uma gerncia de projetos deficiente ou, algumas vezes, por ausncia completa de gerenciamento (JOHNSON, 2001). A gerncia de projeto de software objetiva a qualidade, produtividade e reduo de riscos atravs de planejamento e execuo do desenvolvimento do produto. Na literatura foram discutidos vrios problemas relacionados ao desenvolvimento de software, muitos destes ocasionados quando h omisso ou mal uso de tcnicas e metodologias adequadas a esta tarefa (ZANONI e AUDY, 2002). A maioria dos problemas decorridos, no que diz respeito aos projetos de software, no esto relacionados diretamente a metodologias e tcnicas de desenvolvimento mais se devem, principalmente, a problemas de administrao ou gerenciamento do desenvolvimento de software. Uma das formas de minimizar os problemas oriundos do desenvolvimento de software focar em uma das funes da gerncia de projetos: a funo de planejamento. O planejamento de um projeto envolve a especificao de metas e objetivos, alm da elaborao de estratgias, polticas, regras e procedimentos a serem adotados para alcan-los (THAYER, 1997; WEIHRICH, 1997). O resultado do planejamento de um projeto evidenciado atravs de documentos, referncias e at mesmo por diagramas, e ao conjunto organizado desses resultados d-se o nome de Plano do Projeto. Considerando-se o foco desse trabalho, a

29 funo de planejamento e a importncia do Plano do Projeto no processo de desenvolvimento do software sero enfatizadas com mais detalhes na seo 3.3.

3.1 Normas e Modelos de Referncia

Estudos recentes mostram que preciso um esforo significativo para aumentar a maturidade dos processos de desenvolvimento de software brasileiro (WEBER et al, 2005). O processo utilizado para desenvolver e manter o software afeta diretamente o seu custo, a qualidade e o prazo de entrega do produto (ISO/IEC 9126-1, 2003). O impacto to expressivo que a melhoria do processo de software vista como uma das formas de melhorar o produto de software. Organizaes que almejam melhorar seus processos buscam fazer uso de normas e modelos que descrevem possveis estratgias para apoiar as organizaes nesse processo de melhoria. A atividade de gerncia de projetos busca fazer escolhas e adaptaes desses modelos e normas visando melhorar os processos da organizao que os adota. De acordo com cada modelo ou norma de referncia, a gerncia de projetos vista de uma maneira em particular, onde a funo de planejamento feita de diferentes formas visando sempre o alcance das metas pr-estabelecidas para cada projeto. Vrios modelos e normas buscando a qualidade de software vm ganhando destaque seja por sua qualidade ou sua aplicao, nas sees seguintes so apresentadas as mais relevantes para realizao desse trabalho.

3.1.1 Norma ISO/IEC 12207

A norma internacional ISO/IEC 12207 (ISO/IEC 12207, 1998) foi criada por esforo da ISO (International Organization for Standardization) e o IEC (International Electrotechinical Comission) tendo como principal objetivo estabelecer uma estrutura comum para os processos de ciclo de vida do software. Visa, principalmente, ajudar as organizaes na compreenso dos componentes presentes na aquisio, no fornecimento, no desenvolvimento, na operao e na manuteno de software. Essa norma estabelece uma arquitetura de alto nvel do ciclo de vida de software, tal estrutura composta de processos, atividades e tarefas. Uma das caractersticas na norma que ela no faz ligao com mtodos, ferramentas, treinamentos, mtricas ou tecnologias empregadas. Com isso, ela permite sua utilizao no mundo todo possibilitando o

30 acompanhamento da evoluo da engenharia de software em diversas culturas organizacionais. Ela pode ser utilizada com qualquer modelo de ciclo de vida, mtodo ou tcnica de engenharia de software e linguagem de programao, tal flexibilidade importante, pois, apesar de descrever uma arquitetura em alto nvel, no especifica detalhes de como implementar ou executar as atividades e tarefas includas no processo (ISO/IEC 12207, 1998). Um dos processos da norma o de gerncia de projetos que contm atividades e tarefas genricas que podem ser empregadas por qualquer parte que queira gerenciar o seu processo. Nesse processo, o gerente responsvel pelo gerenciamento do produto, pelo gerenciamento de projeto e pelo gerenciamento das tarefas dos processos aplicveis. Esse processo de gerncia consiste de cinco atividades: (1) iniciao e definio de escopo; (2) planejamento; (3) execuo e controle; (4) reviso e avaliao; e (5) concluso. Uma das atividades iniciais desse processo a atividade de planejamento que consiste da tarefa onde o gerente deve preparar os planos para execuo do processo. Tais planos devem conter descries das tarefas e atividades associadas e a identificao dos produtos de software que sero produzidos. Nesse mesmo processo est a atividade de execuo e controle que consiste da tarefa de implementao do plano para atender o conjunto de objetivos e critrios. Durante a implantao do plano, o gerente pode identificar problemas. A resoluo desses problemas pode resultar em alteraes do plano, ou seja, re-planejamento do projeto. Tanto as atividades de planejamento como a de implementao do plano podero ser auxiliadas pela proposta do trabalho em questo.

3.1.2 CMMI
O CMMI (Capability Maturity Model Integration) foi desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI uma evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas (SEI 2006). Este modelo de referncia contm prticas, genricas ou especficas, necessrias maturidade em disciplinas especficas como Engenharia de Sistemas (SE), Engenharia de Software (SW), Desenvolvimento Integrado de Produtos e Processos (IPPD) e Cadeia de Fornecedores (SS).

31 No que diz respeito a sua representao ele possui duas formas diferentes por estgios e contnua. A por estgios divide as reas de processo1 em cinco nveis de maturidade maneira do CMM, onde todas as reas de processo de um nvel de maturidade devem ser adotadas para que a organizao seja considerada como em pleno exerccio naquele nvel de maturidade; A representao contnua uma abordagem mais flexvel que define nveis de capacidade2, onde a organizao pode escolher as reas de processo que consistem mais relevantes para seus objetivos e adequar a sua implantao (SEI, 2006). As diferenas entre ambos so de carter mais organizacionais o contedo equivalente. Ambos podem ser usados para conseguir nveis em suas respectivas caracterizaes. Em representaes contnuas, as reas de processo so agrupadas em categorias, sendo uma dessas categorias chamada de Gerenciamento de Projetos que inclui atividades de gerncia de projetos relacionadas ao planejamento, monitoramento e controle do projeto (SEI 2006). Essa categoria inclui as seguintes reas de processo: planejamento de projetos, monitoramento e controle de projetos, gerncia de acordos com fornecedores, gerncia integrada de projetos, gerncia de riscos, integrao de equipes e gerncia quantitativa de projetos. Atravs da identificao das vrias reas de processo desta categoria, possvel perceber que as reas de processo do CMMI possuem interligaes entre si, estando algumas prticas sujeitas implementao em conjunto, de forma a aperfeioar a sua aplicabilidade (AHERN, 2004). Como exemplo, pode-se considerar as prticas das reas monitoramento e controle de projetos e planejamento de projeto. altamente recomendvel que a implementao dessas duas reas de processos seja adotada em conjunto, pois as recomendaes de acompanhamento e controle de projeto perdem grande parte de sua efetividade na melhoria de processos sem que sejam adotadas tambm as recomendaes de planejamento de projeto. Com isso, percebe-se o quanto a categoria gerenciamento de projetos abrange diferentes nveis de maturidade do CMMI, sendo de importncia dado o seu carter de inicializao do projeto fornecendo base para execuo e controle das atividades do projeto que tratam dos comprometimentos com os clientes do projeto (SEI, 2006).

rea de Processo (Process Area PA): prticas relacionadas em uma rea que, quando executadas de forma coletiva, satisfazem um conjunto de metas, prticas especficas e prticas genricas que, na sua adoo devem ser adequadas a realidade da organizao (SEI, 2006). 2 Nveis de capacidade so um plano bem definido que descreve a capacidade de uma rea de processo.

32 A rea de Planejamento do Projeto tem como propsito estabelecer e manter planos que definam as atividades de projeto. O Plano do Projeto elaborado nessa rea onde o planejamento inclui estimativas de atributo dos produtos de trabalho e tarefas, determinando os recursos necessrios, produzindo cronogramas, identificando e analisando os riscos do projeto (SEI, 2006). O Plano do Projeto deve considerar todas as fases do ciclo de vida do projeto, o planejamento deve assegurar que todos os planos que afetam o projeto estejam consistentes com o plano geral. Assim o plano normalmente precisar ser revisado de acordo com o progresso do projeto, sendo utilizado nas prticas genricas e especficas para referenciar todos os planos para controle do projeto.

3.1.3 MPS.BR
O programa MPS.BR Melhoria de Processo de Software Brasileiro uma iniciativa brasileira que envolve universidades, grupos de pesquisas e empresas sob a coordenao da SOFTEX Sociedade para Promoo da Excelncia do Software Brasileiro. Esse programa pretende promover a qualificao de empresas compatvel com os padres de qualidade aceitos internacionalmente pela comunidade de software. Propes custos acessveis sendo adequado ao perfil e cultura da maioria da empresas nacionais (SOFTEX, 2007a). O programa MPS.BR foi baseado nas normas ISO/IEC 12207, ISSO/IEC 15504 e aderente ao CMMI. Para melhor entendimento e aplicao do mesmo foi dividido em trs componentes: o Modelo de Referncia (MR-MPS), o Mtodo de Avaliao (MA-MPS) e o Modelo de Negcios (MN-MPS), definido em sete nveis de maturidade: Parcialmente Gerenciado (G), Gerenciado (F), Parcialmente Definido (E), Largamente Definido (D), Definido (C), Gerenciado Quantitativamente (B) e Em Otimizao (A). Apesar de ser baseada nos nveis de maturidade do CMMI, essa diviso em estgios apresenta um nvel de graduao diferenciado, visto que um programa voltado para a realidade brasileira, onde o objetivo possibilitar uma implantao e avaliao mais gradual e adequada s micros, pequenas e mdias empresas. Com a possibilidade de avaliaes com mais nveis de diviso possibilita a visibilidade dos resultados de melhorias de processos em prazos mais curtos (SOFTEX, 2007a).

33 Cada nvel do MPS.BR composto de processos3 que indicam onde a organizao dever concentrar seus esforos. O alcance de um determinado nvel de maturidade do MRMPS obtido quando a organizao atende os propsitos4 e todos os resultados esperados dos respectivos processos e os atributos de processos5 daquele nvel (SOFTEX, 2007a). Um dos processos do Nvel G o de Gerncia de Projetos (GPR) que tem como propsito estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o andamento do projeto (SOFTEX, 2007b). medida que a organizao cresce em maturidade o propsito deste processo evolui, dessa forma a partir do nvel E alguns resultados evoluem e outros so incorporados, de forma que a gerncia de projetos passe a ser realizada com base no processo definido para o projeto e para os planos integrados. No nvel B, a gerncia passa a ter enfoque quantitativo, o que reflete a alta maturidade esperada para a organizao. A cada mudana de nvel novos resultados so incorporados e outros evoluem, detalhes a respeito dessas mudanas fogem ao escopo deste trabalho e podem ser entendidos no Guia de Implementao do MPS.BR. Vrias atividades esto envolvidas no processo de gerncia, dentre elas a de desenvolver um plano geral de controle do projeto. O desenvolvimento do Plano do Projeto inclui: identificar e estimar o escopo, os produtos de trabalho e as tarefas do projeto; estabelecimento de recursos necessrios; identificao e anlise dos riscos do projeto; definio do cronograma de execuo baseado no ciclo de vida do projeto e estabelecimento de compromissos (SOFTEX, 2007b). O Plano do Projeto estabelece a base de execuo e controle para as atividades do projeto. O plano um dos resultados esperados para o GPR 10, onde planos para a execuo do projeto so estabelecidos e reunidos em um documento, permitindo um alinhamento do que foi estimado, o que est sendo planejado e o que ser acompanhado. O uso de uma mesma referncia proporciona uma maior visibilidade ao projeto, facilitando no s o gerenciamento, como a formao de uma base histrica da organizao.

Os processos do MR-MPS so descritos em termos de propsito e resultados, onde os propsitos descrevem o objetivo geral a ser atingido durante a execuo do processo e os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implantao do processo. 4 Propsito do processo o objetivo geral da execuo do processo. Convm que a implementao do processo fornea benefcios tangveis aos envolvidos. 5 Atributo de Processo uma caracterstica mensurvel da capacidade do processo aplicvel a qualquer processo. A capacidade do processo representada por um conjunto de atributos de processos descrito em termos de resultados esperados. O atendimento aos atributos do processo (AP) pelo atendimento dos resultados esperados dos atributos do processo (RAP) requerido para todos os processos no nvel correspondentes.

34

3.2 PMBOK
O PMBOK6 (Project Management Body of Knowledge) um conjunto de prticas em gerncia de projeto propostas pelo PMI (Project Management Institute) e compe a base da metodologia de gerncia de projetos do PMI. Tais prticas so organizadas na forma de um guia, chamado de PMBOK Guide - A Guide to the Project Management Body of Knowledge. Esse guia descreve a somatria de conhecimento e as melhores prticas dentro da gerncia de projetos (PMBOK, 2004). Na definio do PMBOK (2004), gerenciamento de projetos a aplicao de conhecimentos, habilidades, ferramentas e tcnicas as atividades do projeto, a fim de atender os requisitos das partes interessadas. Como o guia um material genrico que pode ser aplicado a qualquer situao de gerenciamento (inclusive de projetos de software), cabe aos gerentes satisfazer e equilibrar as necessidades que envolvem as vrias demandas em relao ao projeto, determinando os processos adequados e o grau de rigor de cada processo, limitando assim o que deve ou no ser aplicado a cada domnio. O guia PMBOK organiza 44 processos de gerenciamento de projetos, porm o detalhamento a respeito desses processos foge ao escopo deste trabalho e podem ser vistos no guia. Esses processos so divididos nas nove reas de conhecimento, citadas a seguir de acordo com o guia PMBOK (2004) mostrando os principais processos de cada uma: Gerenciamento de Integrao: descreve os processos e as atividades que integram os diversos elementos do gerenciamento de projetos. Um dos seus processos envolve o desenvolvimento do Plano do Projeto e encerramento do projeto; Gerenciamento de Escopo: descreve os processos envolvidos na verificao se o projeto inclui o trabalho necessrio. Tem como processos o planejamento do escopo, criao da EAP7 e controle do escopo; Gerenciamento de Tempo: descreve os processos relativos ao trmino do projeto no prazo correto. Alguns de seus processos so o de definir estimativas de durao das atividades e o desenvolvimento do cronograma.

6 7

A sigla PMBOK uma marca registrada do Project Management Institute. EAP- Estrutura Analtica do Projeto: tambm conhecida como WBS (Work Breakdown Structure), fornece um esquema para identificao e organizao das unidades lgicas de trabalho a serem gerenciadas, que so chamadas de pacotes de trabalho (PMBOK, 2004).

35 Gerenciamento de Custos: descreve os processos envolvidos em

planejamento, oramentos e controle de custos de modo que o projeto termine dentro do oramento aprovado. Consiste dos processos de estimativa de custos, oramento e controle de custos; Gerenciamento de Qualidade: descreve os processos envolvidos na garantia de que o projeto alcanar os objetivos pra os quais foi realizado. Um de seus processos o de fazer o planejamento da qualidade. Gerenciamento de Recursos Humanos: descreve os processos que organizam e gerenciam a equipe do projeto. Dentre os seus processos est o de contratar a equipe do projeto e tambm o de gerenciar a equipe do projeto. Gerenciamento de Comunicaes: descreve processos relativos gerao, coleta, disseminao e armazenamento das informaes do projeto. Consiste dos processos de relatrio de desempenho como de gerenciamento das partes interessadas. Gerenciamento de Riscos: descreve processos relativos realizao do gerenciamento de riscos do projeto. Alguns de seus processos envolvem identificao dos riscos e monitoramento e controle de riscos; Gerenciamento de Aquisio: descreve os processos que compram ou adquirem produtos, servios ou resultados alm de gerenciar os contratos. Envolve processos de planejar contrataes, selecionar fornecedores e encerramento do contrato. Os processos de gerenciamento de projetos so associados entre si por seu desempenho buscando um objetivo integrado de iniciar, planejar, executar, monitorar e controlar, e encerrar um projeto. Cada rea de processo citada anteriormente faz uso de documentos de entradas, utiliza algumas ferramentas e tcnicas, e produz artefatos de sada que compem planos relacionados diretamente a rea de conhecimento em questo. Com objetivo de contriburem para o desenvolvimento do projeto, esses planos precisam ser integrados visto que eles se sobrepem e interagem entre si (PMBOK, 2004). A necessidade de integrao fica evidente em situaes em que os processos individuais interagem como, por exemplo, quando uma estimativa de custo necessria para um plano de contingncia precisa de detalhes do gerenciamento de custos do projeto. Dado esse carter integrativo, no captulo 4 da seo II do PMBOK apresentada a rea de conhecimento em Gerenciamento de Integrao do Projeto que inclui atividades

36 necessrias para o planejamento do projeto. Um dos processos dessa rea o de Desenvolver o Plano de Gerenciamento do Projeto que inclui aes de definio, coordenao e integrao de todos os planos auxiliares em um projeto. A sada desse processo ser o plano de gerenciamento do projeto que defini como o projeto ser executado, monitorado, controlado e encerrado, sendo que este plano revisado e atualizado por meio do processo Controle Integrado de Mudanas. No decorrer destas sees foram apresentadas algumas prticas do PMBOK, normas e modelos de referncia no qual o trabalho est inserido. Em cada uma foi destacada como a gerncia de projetos trabalhada e como a integrao de diversos documentos em um s permite melhor entendimento e acompanhamento do projeto. Buscando o modelo que melhor se adapta a realidade brasileira e a proposta do ambiente WebAPSEE, o MPS.BR serviu como base principal para o desenvolvimento deste trabalho. Alm do que, este modelo compatvel com os outros modelos, prticas e normas internacionais apresentados, tendo aceitao crescente indstria e academia nacional.

3.3 Planejamento do Projeto

Tal como um empreendimento, na gerncia de projetos preciso que as atividades sejam planejadas, programadas e, durante a execuo, precisam ser controladas. Com isso, um dos objetivos iniciais da gerncia de projetos a de planejar o projeto. A partir deste planejamento realizada uma definio e refinamento dos objetivos e seleo dos melhores caminhos para alcanar os objetivos. As informaes definidas e coletadas para um projeto como ciclo de vida, recursos, riscos, alocao e treinamento de pessoas devem ser organizadas de maneira a permitir um gerenciamento adequado do projeto, uma das maneiras de fazer isso reunir essas informaes em um ou mais documentos, os planos (SOFTEX, 2007b). Esses planos devem estar relacionados entre si para que atinjam o seu propsito compondo o planejamento geral do projeto. Ainda segundo SOFTEX (2007b), importante a existncia de uma nica referncia para o alinhamento da documentao para promover uma maior visibilidade do projeto, facilitando o seu gerenciamento. A integrao desses vrios planos em um nico documento chamada de Plano do Projeto. Adicional as informaes dos planos, as tarefas do processo que j foram definidas podem fazer parte do Plano do Projeto.

37 O monitoramento do projeto depende da organizao adequada das informaes de planejamento, essas informaes devem ser comparadas aos dados obtidos com a execuo do projeto e, dependendo da necessidade, o planejamento pode ser revisto gerando uma nova verso do Plano do Projeto (SOFTEX, 2007b). Sendo este documento composto de diferentes planos, nesta seo apresentada uma breve viso do contedo de cada plano que faz parte do Plano do Projeto e a sua importncia.

3.3.1 Plano de Alocao de Recursos

Com base nas atividades do projeto (descritos na EAP) devem ser especificadas as tarefas e previstos os recursos e o ambiente necessrios para o projeto, isso inclui, por exemplo, equipamentos, ferramentas e artefatos. Esses recursos so identificados no Plano de Alocao de Recursos. O plano contm informaes referentes aos recursos do projeto, uma breve descrio sobre os mesmo e as datas iniciais e finais da sua alocao. Esse documento torna-se importante a partir do momento em que os recursos precisam ser explicitamente planejados, mesmo os recursos j considerados existentes e disponveis ou que sero compartilhados na organizao, visto que se trata de uma alocao para uso (SOFTEX, 2007b). Caso no haja necessidade de nenhum recurso em especial (adquirido especificamente para o projeto) o fato de que a questo foi analisada deve ser registrado. O Plano de Alocao de Recursos importante, pois recursos de um projeto precisam de oramento e planejamento de possveis aquisies, o que pode ser um fator crtico em alguns projetos.

3.3.2 Plano de Comunicao

O Plano de Comunicao determina as necessidades de informaes e comunicaes das partes interessadas do projeto, sendo um documento que garante a gerao, coleta, distribuio, armazenamento, recuperao e destino final das informaes do projeto (SOFTEX, 2007b). O seu contedo envolve a identificao dos artefatos que serviram como base de comunicao, as atividades as quais esto envolvidos, os agentes relacionados sua emisso, agentes que receberam esses artefatos e a forma como a comunicao ser realizada. Esse plano torna-se de grande importncia medida que fornece as ligaes crticas entre pessoas e informaes que so necessrias para as comunicaes, alm de conter as necessidades de informaes das partes interessadas e determinar a maneira apropriada de atender essas necessidades (PMBOK, 2004). Como o Plano de Comunicao est muitas

38 vezes relacionado a fatores ambientais e a influncias da organizao, a estrutura organizacional ter efeito importante na sua criao, assim os resultados desses fatores e influncias podem provocar mudanas no plano para garantir que sua aplicao seja vlida.

3.3.3 Plano de Custos

O plano de gerenciamento de custos de um projeto inclui atividades envolvidas em estimativas, oramento e controle dos curtos de modo que seja possvel terminar o projeto dentro do oramento aprovado. O Plano de Custos contm valores financeiros alocados ao projeto, tanto em utilizao de recursos de apoio diversos quanto em horas de trabalho. O contedo desse documento contm informaes referentes a descrio do recurso (dependendo do tipo de recurso definida a sua quantidade ou horas trabalhadas para recursos humanos), as datas iniciais e finais de sua alocao e a estimativa dos custos envolvidos para o seu uso. O gerenciamento de custos trata, principalmente, de custo dos recursos precisos para terminar uma atividade, no entanto o gerenciamento de custos deve considerar efeito em decises sobre utilizao, manuteno e suporte do produto, servio ou resultado do projeto. A definio de um Plano de Custos pode aprimorar a tomada de decises e usado para reduzir custos e o tempo de execuo e para melhorar a qualidade e o desempenho de entrega do projeto (PMBOK, 2004).

3.3.4 Plano de Gerncia de Documentos

O Plano de Gerncia de Documentos identifica as vrias formas de documentao necessrias (artefatos) para apoiar o projeto, alm de especificar formatos, mdias, formas de distribuio, pblico-alvo, responsabilidades pelo desenvolvimento e aprovao para todas as formas de documentao. As informaes contidas nesse documento referem s formas de armazenamento dos documentos, questes quanto segurana e confiabilidade dos mesmos e uma listagem com os artefatos que sero gerenciados. Nessa listagem apresentado o nome dos artefatos, a fase em que os artefatos so criados ou alterados, o cargo responsvel pela criao do mesmo e o mtodo de acesso. Os dados de um projeto so as vrias formas de documentao exigidas para sua execuo, e um plano dessa documentao facilita o entendimento de como os dados do projeto so armazenados alm de estabelecer um mecanismo para acess-los (SOFTEX, 2007b). Com essa gerncia, os membros envolvidos tm um melhor direcionamento quanto a

39 onde obter os dados do projeto e como estes so disponibilizados. Atravs desse plano os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio.

3.3.5 Plano do Processo

O Plano do Processo a descrio do ciclo de vida que ser utilizado durante o projeto de acordo com as suas caractersticas. Nesse plano ser apresentada a natureza do projeto que define, de acordo com a organizao, se o software ser de desenvolvimento ou manuteno e a partir dessa definio algumas adaptaes podem ser feitas no processo padro, sendo estas descritas neste plano. Informaes referentes a caractersticas para embasamento da escolha do processo so apresentadas em sete subsees de acordo com seus critrios: (1) relacionados aos usurios; (2) relacionados ao problema; (4) relacionados ao produto; (3) relacionados aos recursos; (5) relacionados equipe de desenvolvimento; (6) relacionados gerncia do projeto; e (7) relacionados ao desenvolvimento. Alguns critrios a respeito das caractersticas de qualidade do produto so apresentados em outra subseo que leva em considerao questes como a funcionalidade, confiabilidade, usabilidade, eficincia, portabilidade e manutenibilidade do produto. As descries desses critrios iniciais do projeto so importantes para definio e execuo das atividades de gerncia do projeto, considerando as caractersticas do produto e da organizao. Alm de informar a temporalidade para estabelecer incio e fim do projeto, a descrio de um ciclo de vida bem definido pra o projeto possibilita a determinao de perodos de avaliao e de tomada de decises, onde alguns compromissos relevantes so realizados com relao aos recursos, abordagem tcnica, reavaliao de escopo e custo do projeto (SOFTEX, 2006b). A descrio do processo a ser seguido poder referenciar aos recursos que sero utilizados no seu desenvolvimento do projeto. Dadas essas descries sobre este plano, percebe-se que o Plano do Processo representa um documento de inicializao do projeto, que contm informaes relevantes para que o restante dos planos possa ser desenvolvido.

3.3.6 Plano de Recursos Humanos

O Plano de Recursos Humanos desenvolvido de acordo com o Plano da Organizao que contm informaes referentes equipe da organizao e suas respectivas responsabilidades e habilidades. Baseado nessa viso geral das competncias e dos recursos

40 humanos da organizao, o Plano de Recursos Humanos feito em trs etapas principais: (1) busca das competncias necessrias; (2) alocao de recursos humanos; (3) desenvolvimento de competncias (avaliao dos recursos humanos para posterior capacitao) (SCHNAIDER, 2003). Levando em considerao o carter dinmico dos recursos humanos de uma organizao, este plano visto em todo o ciclo de vida do projeto de software, desde o planejamento do projeto at a fase final do mesmo. Este plano contm informaes referentes de como e quando os recursos sero contratados ou mobilizados, que tipos de cargos so requeridos e a sua quantidade, exibe as atividades do processo, os papis alocados para a mesma e quais os agentes que ocupam este cargo para aquele projeto. A alocao de recursos humanos prov ao processo de gerncia de projetos um carter pr-ativo, j que busca definir os profissionais que participaro do projeto durante a fase de planejamento, alm de possibilitar, na fase de monitorao, a antecipao de possveis problemas e o planejamento de aes preventivas. A criao desse plano importante, pois deixa claro os recursos humanos e quais os papis que desempenham dentro do projeto, sendo que a existncia de registros das necessidades e disponibilidade evita a alocao com base em critrios mais subjetivos, permitindo ao gerente fazer solicitaes de acordo o cronograma e at definir melhor os riscos envolvidos na alocao desses recursos (SOFTEX, 2006b).

3.3.7 Plano de Riscos

O Plano de Riscos de um projeto identifica, analisa e avalia os riscos do projeto, priorizando-os e estabelecendo os planos de mitigao e de contingncia como parte do controle de riscos do projeto. Nesse plano so encontradas informaes referentes aos riscos identificados, sua probabilidade (com valores baixo, mdio e alto), seu impacto no projeto (com valores baixo, mdio, alto e muito alto) e sua prioridade. Nesse plano destacada uma seo para identificao dos riscos que so gerenciados fornecendo um plano de mitigao, um plano de contingncia, sua possvel causa e a conseqncia gerada. Definir um Plano de Riscos importante para garantir que o nvel, tipo e visibilidade do gerenciamento de riscos estejam em ajuste com os riscos e a importncia do projeto em relao organizao (PMBOK, 2004). A identificao de ricos promove base para tomada de aes corretivas. Quando apropriado, e quando o impacto e os riscos associados so modelados e gerenciados, mudanas para melhoria no projeto podem ser realizadas. O gerenciamento de riscos contribui para que problemas identificados em projetos anteriores sejam j analisados e acompanhados prevenindo sua repetio.

41

3.3.8 Plano de Treinamento

Caso no seja esperado que os membros da equipe tenham as competncias exigidas para aquele projeto, possvel desenvolver um Plano de Treinamento como parte do projeto. Alm de conter novos treinamentos, o plano tambm pode incluir maneiras de ajudar os membros da equipe a obter certificaes que beneficiam o projeto (PMBOK, 2004). O contedo desse documento descreve informaes sobre o nome dos treinamentos, a justificativa pra que o treinamento seja realizado, um escopo que define o que o treinamento deve conter, os participantes envolvidos (sejam os ministrantes ou os alunos), o perodo do treinamento e local. O plano de treinamento inclui atividades criadas para aprimorar as competncias dos membros da equipe do projeto. Por tratar-se de um plano opcional, esse plano tem um carter mais informativo de complementar a comprovao de capacidade da equipe envolvida no projeto. A sua realizao deve ser tratada no desenvolvimento do cronograma, j que os membros da equipe podem estar alocados a este tipo de atividades e no no desenvolvimento do produto.

42

4 FERRAMENTAS PARA GERENCIAMENTO DE PROJETOS

Visando garantir a qualidade do produto de software e a execuo do projeto de maneira mais eficiente, importante um planejamento das atividades a serem executadas para o seu desenvolvimento. A funo de gerenciar um projeto envolve atividades de planejamento, execuo e acompanhamento do processo, atividades vitais pra que o gerente conduza seu projeto com sucesso alcanado o objetivo planejado. A importncia dessas atividades indica a utilizao de ferramenta de gerncia de projetos. Algumas solues voltadas tecnologia de processos de software so apresentadas, desde as tecnologias de ferramentas CASE (Computer-Aided Software Enginnering), que foram precursoras da cultura de construir ferramentas para apoiar o desenvolvimento de software, aos ADSs que incorporam mecanismos para o controle do processo de desenvolvimento atravs da coordenao, colaborao e comunicao de recursos (humanos materiais e tecnolgicos) envolvidos (LIMA REIS, 2003). Apesar da diversidade dessas solues, as ferramentas citadas nessa proposta descrevem o seu carter gerencial. Assim, so apresentadas ferramentas de gerenciamento de propsito geral, como o MS-PROJECT, e as ferramentas mais especficas quanto ao gerenciamento de processo de desenvolvimento de software, como o caso da Estao TABA. Uma descrio mais detalhada quanto s caractersticas tecnolgicas dessas ferramentas foge ao escopo deste trabalho. Vrias ferramentas esto disponveis no mercado, foi realizado um estudo para escolha da ferramenta adequada. Esse estudo buscou aquela que melhor atendesse as especificaes da organizao e do projeto em questo. Guiando este estudo est o MPS.BR, sendo critrio desse trabalho alcanar os resultados esperados para este modelo, mais especificamente ao nvel G do processo Gerncia de Projetos. importante ressaltar que visando a qualidade do software, outros critrios de qualidade, citados em Pressman (2005), foram considerados, alm de fatores comerciais.

43 As sees a seguir apresentam de forma resumida algumas das ferramentas que foram estudadas. Devido diversidade de ferramentas encontradas na literatura, procurou-se fazer uma anlise tomando apenas ferramentas que representem uma classe de ferramentas quanto ao seu propsito de gerenciamento. As ferramentas mais representativas, de fcil acesso e com relao com os conceitos de gerncia de projetos no MPS.BR foram selecionadas, dentre estas: Estao TABA, MS-PROJECT e o OpenProj.

4.1 Estao TABA

A Estao TABA um ADS, desenvolvido pela COPPE-UFRJ, que visa o apoio as atividades de gerncia de projetos, melhoria da qualidade dos produtos de software e aumento da produtividade. Atravs desse ADS pode ser feito um controle do projeto e uma possvel medio da evoluo das atividades baseando-se em informaes coletadas ao longo do desenvolvimento do projeto (ROCHA et al, 2005). A Estao TABA evolui nos ltimos anos para apoiar atividades de gerncia de conhecimento integrados a processos de software com objetivo de preservar o conhecimento na organizao e permitir a institucionalizao de uma organizao de software de aprendizado. Assim os objetivos da Estao TABA so bem definidos por Rocha et al (2005): (1) apoio na configurao do ADS para diferentes organizaes (ADS configurados); (2) apoio a gerao automtica (instanciao) de ADS para projetos especficos (ADS Orientados a Organizao); (3) apoio ao desenvolvimento de software atravs da utilizao de ambientes instanciados; e (4) apoio a gerncia de conhecimento organizacional relacionado a processos de software. A Estao TABA disponibilizada de duas formas: ambiente configurado, onde a ferramenta adaptada cultura da organizao e o ambiente instanciado. Neste caso, ocorre uso de diversas ferramentas de apoio a atividades do projeto podendo instanciar um processo padro pr-definido na Estao TABA. Com um ambiente configurado, cada organizao poder instanciar um ambiente especfico para apoiar a execuo do projeto com uso da ferramenta AdaptPro (BERGER, 2003). Essa ferramenta apia a instanciao de processos de software para projetos especficos a partir dos processos especializados da organizao possibilitando ao engenheiro de software a execuo de algumas atividades: caracterizao do projeto, planejamento do processo guia do projeto atravs da adaptao de um processo padro organizacional de

44 acordo com as caractersticas do projeto e instanciao de um ADS para execuo do processo planejado. A Figura 9 apresenta a tela principal da ferramenta AdaptPro, do lado esquerdo as atividades guias na execuo da ferramenta e do lado direito exibe uma tela de acordo com a atividade selecionada, no exemplo a atividade de planejar o processo onde pode ser definidos informaes sobre o projeto como escopo, paradigma e o tipo de software.

Figura 9 - Tela principal da ferramenta AdapPro da Estao TABA

No website da Estao TABA (TABA, 2008) est disponvel uma verso de demonstrao da ferramenta. Nesta verso um processo padro simplificado de acordo com o MPS.BR Nvel G apresentado. A atividade inicial desse processo padro do TABA a de planejamento do processo (conforme Figura 10), para esta atividade so utilizadas outras ferramentas que compem diferentes documentos que ao final sero integrados para a gerao do plano do projeto. Uma dessas ferramentas o RHPlan, que apia o gerente na alocao de recursos humanos de forma efetiva (SCHNAIDER, 2003). Outra ferramenta o RiscPlan que apia a atividade de identificao, anlise e planejamento da gerencia de riscos definidas no processo (FARIAS, 2002). Na Figura 10 apresentada a tela de consolidao do plano do projeto, do lado esquerdo exibida uma rvore contendo as fases do processo onde cada atividade pode fazer uso de um tipo de ferramenta fornecido pela estao TABA, cada plano produzido pelas atividades consolidado gerando ao final o artefato plano do projeto.

45

Figura 10 - Tela de avaliao do Plano do Projeto

4.2 Microsoft Office Project (MS-PROJECT)

O MS-PROJECT uma ferramenta de gerenciamento de propsito geral, desenvolvida pela Microsoft que possibilita as empresas organizar, coordenar e gerenciar recursos, projetos e Processo (MICROSOFT 2008). Atravs dessa ferramenta possvel manter-se informado e controlar o trabalho, as agendas e finanas do projeto, manter a equipe alinhada por meio da integrao com outros programas da Sute Microsoft Office. O MS-PROJECT cobre vrias fases de um projeto desde o planejamento, acompanhamento da execuo e auxilia o gerenciamento de equipes e materiais. Dispe de um mecanismo de controle de cronogramas e finanas indicando quais os impactos envolvidos em suas alteraes, permitindo um melhor controle financeiro e anlises mais sofisticadas dos riscos, sendo a internet utilizada como ferramenta de comunicao. Algumas funcionalidades so destacadas na ferramenta dentre elas a definio de estimativas e agendamento de tarefas, planejamento e gesto de projetos e sofisticado recursos de criao de relatrios em diferentes formatos de acordo com as necessidades do pblico interessado.

46 Para estudo nesse trabalho foi utilizada a verso MS Office Project Standard 2007 da ferramenta, que inclui todos os recursos da verso Microsoft Office Project Professional, essa verso pode ser encontrada em uma verso demo no site da Microsoft (MICROSOFT, 2008). Para estudo da ferramenta foi criado um projeto base semelhante ao apresentado na Estao TABA (Figura 10). Na Figura 11 apresentada a tela principal da ferramenta com a composio das atividades de acordo com o Grfico de Gantt, do lado esquerdo composta um barra de tarefas com as diversas vises oferecidas, na tela central o nome das atividades e mais a direita ser exibida a tela de acordo com a visualizao escolhida pelo usurio.

Figura 11 - Tela principal do MS-PROJECT

Para auxiliar a integrao da documentao do projeto, a ferramenta possui vrios relatrios definidos que oferecem informaes em seis reas gerais: viso geral, atividades atuais, custos, atribuies, carga e trabalho e uma opo de personalizao onde o usurio pode criar seu prprio relatrio. Na Figura 12 apresentado um relatrio de viso geral, do tipo resumo do projeto, que contm as datas de incio e trmino das tarefas, informando quanto tempo esto atrasadas. O recurso Relatrios Visuais usa o Microsoft Office Excel e o Microsoft Office Visio Professional para produzir modos de exibio de tabela dinmica, grficos e diagramas com base em dados do Project. Um usurio pode definir modelos de relatrios personalizados e compartilh-los com outros usurios do Project.

47

Figura 12 - Relatrio de viso geral gerado pela ferramenta

4.3 OpenProj
OpenProj uma ferramenta livre para gesto de projetos. Desenvolvido pela Projity, que agora faz parte da Serena Software, a ferramenta publicada sob uma licena livre que funciona em diferentes plataformas (Windows, Linux, Unix ou Mac) (PROJITY, 2008). Permite o uso do formato MPP (formato do MS-PROJECT), salva num formato prprio, alm de permitir a exportao no formato XML e PDF. Pode ser utilizada em diferentes tipos de projetos j que uma ferramenta de gerenciamento de propsito geral. Dentre as principais funcionalidades da ferramenta est a gerao do Grfico de Gantt, Diagrama de Redes, criao da WBS (Work Breakdown Structure), grficos RBS (Risk Breakdown Structure), faz a gesto de recursos e anlise do valor agregado. Alm dessas funcionalidades a empresa fornece o cdigo fonte da ferramenta para que modificaes mais especficas possam ser agregadas as funcionalidades bases j fornecidas. A ferramenta oferecida tanto no pacote de escritrio StarOffice da SUN quanto uma verso no website da Projity (PROJITY, 2008). Para estudo deste trabalho, foi utilizada a verso disponvel no website da Projity. Assim como estudo da ferramenta MS-PROJECT, foi criado um projeto base semelhante ao da Estao TABA (Figura 10). Na Figura 13 so apresentadas as atividades do projeto semelhante a um cronograma com as datas iniciais e finais, do lado esquerdo superior exibido uma barra com as diferentes vises oferecidas e de

48 acordo com a viso selecionada do lado direito da tela carregada uma imagem diferenciada de grfico, na parte inferior da tela os recursos so listados e um histograma de seu uso exibido.

Figura 13 - Tela principal do OpenProj exibindo um grfico de Gantt

Para auxiliar na documentao do projeto, a ferramenta dispe de cinco tipos de relatrios onde pode ser feita uma filtragem das colunas que sero exibidas. Na Figura 14 exibido um relatrio do tipo Task Information que contem informaes referentes s atividades do projeto, uma estimativa de durao, as datas de incio e trmino e os recursos humanos envolvidos de cada atividade.

49

Figura 14 - Relatrio de tarefas do projeto do tipo Task Information

As ferramentas apresentadas nesta seo foram estudas buscando um entendimento de como estas podem auxiliar a atividade de gerncia de projetos. As principais caractersticas analisadas dizem respeito aos relatrios que cada uma fornece e como estes esto aderentes a modelos de maturidade como o MPS.BR. A integrao deste tipo de ferramentas ao ambiente WebAPSEE foge ao escopo do projeto, visto que um das principais motivaes do projeto que o gerente no precise fazer uso de uma diversidade de ferramentas em cada etapa de seu gerenciamento para alcanar seus objetivos. O foco do projeto que o ambiente WebAPSEE fornea os subsdios necessrios para uma gerncia de projetos mais adequada, um ambiente completo que auxilie o gerente a desenvolver suas atividades sem necessidade de recorrer a ferramentas de gerenciamento externas.

50

5 PROPOSTA DE GERAO DE PLANO DO PROJETO NO WEBAPSEE

O ambiente WebAPSEE fornece auxlio aos requisitos considerados essenciais para modelagem e execuo de processos de software, incluindo gerncia dos dados da organizao (cargos, habilidades, recursos, estimativas) e modificaes dinmicas de processo em execuo (LIMA REIS, 2003). A proposta desse trabalho consiste na construo de um mecanismo para apoiar a gerao automatizada do Plano do Projeto. Os requisitos elicitados para a proposta foram elaborados baseados no template de Plano do Projeto utilizado pelo Grupo de Melhoria de Processos no CTIC UFPA (Anexo 1). A construo deste template ocorreu durante o processo de implantao de um processo de desenvolvimento de software na organizao, onde a cada melhoria do processo o template tambm era modificado visando melhoria do documento. Alm do uso deste template, algumas entrevistas foram realizadas com gerentes de projetos do LABES e do CTIC UFPA para elaborao dos novos formulrios que foi inserido pela proposta. A listagem dos requisitos apresentada na tabela 1onde os requisitos so identificados como requisitos funcionais (RF) ou no funcionais (RN).
Tabela 1 - Lista de Requisitos da Proposta

REQUISITOS DA PROPOSTA N R 01 Descrio O sistema dever permitir o cadastro/alterao de um projeto que contenha as seguintes informaes: identificao, nome, natureza do projeto, tipo se software, ciclo de vida, descrio do processo, data de incio e fim do projeto. Cada projeto dever ser associado h um processo especfico. Tipo RF

R 02

RF

51 R 03 R 04 R 05 R 06 O sistema dever permitir a importao de dados referentes a outros projetos. O sistema dever permitir uma avaliao inicial das caractersticas de qualidade do projeto. O sistema dever permitir uma avaliao das caractersticas para escolha do processo. O sistema dever permitir o cadastro/alterao de treinamentos com as seguintes informaes: projeto ao qual est associado, identificao do treinamento, ministrante, participantes, justificativa, descrio, data inicial e final, local. O sistema dever permitir o cadastro/alterao de plano de comunicao com as seguintes informaes: projeto ao qual est associado, artefato de comunicao, forma de comunicao, atividades ou fases onde comunicado, agentes emissores e agentes receptores. O sistema dever permitir a identificao dos riscos do projeto com informaes sobre sua probabilidade, o impacto e prioridade. O sistema dever permitir classificar um risco como gerencivel ou no. O sistema dever gerar um relatrio contendo dados referentes ao projeto intitulado Plano do Projeto. O sistema dever permitir a escolha para qual projeto ser gerado um Plano do Projeto. O relatrio Plano do Projeto dever ser editvel. O sistema deve apresentar um alto grau de usabilidade, seguindo padres j existentes na ferramenta WebAPSEE. A gerao de relatrio dever ser feita de maneira eficiente e rpida diminuindo ao mximo o tempo de espera por um relatrio. A manutenibilidade dever alta permitindo que novos formulrios sejam inseridos. RF RF RF RF

R 07

RF

R 08

RF

R 09 R 10 R 11 R 12 R 13 R14

RF RF RF RN RN RN

R15

RN

Uma viso geral do funcionamento desta proposta consiste nos seguintes passos: Cadastro dos planos: cada plano que compe o Plano do Projeto cadastrado em seu respectivo formulrio, as informaes referentes a cada plano so recuperadas de forma integrada no documento final, o Plano do Projeto. No caso de necessidade de mudanas dos dados de um plano j cadastrado, o gerente

52 pode selecionar o projeto ao qual o plano est associado e efetivar as mudanas. Para cadastrar os planos necessrio que um projeto j tenha sido cadastrado, no formulrio Plano do Processo, e tenha sido relacionado um processo ao mesmo. O gerente pode cadastrar vrios projetos e s depois fazer o cadastramento dos planos. Selecionar o projeto para emisso do plano: aps o cadastramento dos planos o gerente seleciona o projeto para o qual o Plano do Projeto ser emitido. Emitir Plano do Projeto: com um projeto selecionado, o gerente define o local onde o arquivo ser salvo e faz a emisso do mesmo. Outra representao do funcionamento desta proposta descrita pela Figura 15 que apresenta o diagrama de atividades para gerao de Plano do Projeto, segundo notaes da UML.

Figura 15 - Diagrama de atividades para gerao de Plano do Projeto

Aps a apresentao dos requisitos e da viso geral do funcionamento da proposta, neste captulo apresentada a arquitetura atual do ambiente WebAPSEE e a estrutura do metamodelo que permitiu que a proposta fosse realizada.Tambm uma breve descrio dos pacotes

53 envolvidos na estrutura da proposta, as modificaes efetuadas no modelo de dados e como a gerao de relatrios feita no ambiente.

5.1 Arquitetura do Ambiente WebAPSEE

O ambiente WebAPSEE foi desenvolvido com uma arquitetura cliente-servidor, o que facilita a implementao de funcionalidades caractersticas de um PSEE, a exemplo: a visualizao do processo em execuo pelo gerente; o envio de instrues ao desenvolver sobre suas atividades, a possibilidade de reutilizao e instanciao de processos e poltica de alocao (SILVA, 2007; COSTA e SALES, 2007). Com uma maior distribuio dos agentes e gerentes de processo indicado que uma arquitetura fornea servios distribudos atravs de uma rede (Intranets e Internet). Para isso necessrio a escolha de um protocolo de distribuio, podendo ser utilizados tanto protocolos de desenvolvimento para a WWW (YAN et. al, 2003) quanto protocolos proprietrios de distribuio dos dados. Essas escolhas so influenciadas pelos requisitos do sistema em questo. Sendo o WebAPSEE um sistema que utiliza abordagem voltada para padres Web, o ambiente utiliza WebServices para prover interoperabilidade8 com ferramentas externas (HAEFEL, 2003) e a linguagem Java RMI (Remote Method Invocation) (RMI, 2008) para distribuio de objetos. A utilizao desses dois protocolos facilita a configurao do WebAPSEE para o ambiente do usurio do sistema. A arquitetura do ambiente WebAPSEE se divide me trs camadas principais, conforme apresentado na Figura 16. (A) Camada Servidora: prov servios de persistncia, checagem de consistncia para modelagem, controle e armazenamento de artefatos e execuo de modelos de processos de software; (B) Camada de Distribuio: oferece uma infra-estrutura para acesso (remoto ou local) aos servios da camada servidora; (C) Camada de Ferramentas Cliente: referente s ferramentas GUI (Graphical User Interface ou Interface Grfica com Usurio) que interagem diretamente com a interface do usurio para entrada de dados, modelagem de processos e visualizaes de informaes obtidas do servidor;
8

Interoperabilidade a capacidade de um sistema se comunicar de maneira transparente com outro sistema

54 Maiores informaes sobre a arquitetura do ambiente WebAPSEE podem ser vistas em (LABES, 2008).

Figura 16 - Camadas que compe a arquitetura do WebAPSSE (LIMA et. al., 2006a)

5.2 WebAPSEE Reports

A arquitetura do ambiente WebAPSEE fornece um mdulo para gerao de relatrios, disponvel na camada A, o Reports Facade (Figura 16). Como descrito em PAXIUBA (2007), alguns acrscimos tiveram que ser feitos para que o ambiente permitisse a gerao de relatrios no formato de planilhas do Microsoft Excel, permitindo a manipulao de dados e a possvel gerao de grficos a partir de planilhas eletrnicas. Esses acrscimos so descritos a seguir: Criao de Servios no Componente ReportsFacade (camada servidora): para implementao de relatrios no formato do Microsoft Excel, foi utilizada a biblioteca jXLS (JXLS, 2008). Utilizando a API jXLS so criados arquivos XLS a partir de templates que definem a formatao, frmulas, macros e a disposio dos dados do relatrio usando uma notao especifica. A cada servio implementado a engine jXLs invocada e passa como parmetro o template e os dados especficos para gerao do relatrio em um formato XLS; Criao de Consultas no Componente DAO (camada servidora): novas consultas as bases de conhecimento precisas para gerao dos relatrios foram incorporadas no mdulo DAO da aplicao;

55 Criao de classes no componente ReportsClients (camada de distribuio): acrscimo de novos mtodos para fazer as chamadas aos novos relatrios disponibilizados pelo mdulo de acompanhamento do projeto; Criao de formulrios de acesso a gerao dos relatrios: formulrios no componente WebAPSEE forms, para o usurio fornecer os parmetros que orientam a gerao dos relatrios. Como citado anteriormente, na seo 3.1 deste trabalho, o modelo MPS.BR foi utilizado como modelo de referncia para o desenvolvimento da proposta. Como forma de evidenciar alguns resultados esperados desse modelo, o ambiente WebAPSEE oferece a funcionalidade de gerao de relatrios especficos para o Nvel G do MPS.BR. Para essa funcionalidade exibido um formulrio direcionado a este tipo propsito exibido na Figura 17.

Figura 17 - Formulrio de Relatrios Nvel G MPS.BR

Os relatrios especficos gerados atravs deste formulrio servem como documentao para gerao dos planos que compe o Plano do Projeto. Nesses relatrios so inseridas informaes referentes tanto a organizao quanto a execuo do processo utilizado no projeto, permitindo ao gerente do projeto um maior acompanhamento da execuo das atividades do processo. Para melhor exemplificar o contedo desses relatrios e a sua importncia na elaborao do plano, a seguir so mostrados dois relatrios gerados atravs do ambiente. Os demais relatrios gerados pela ferramenta podem ser vistos em (WEBAPSEE, 2008).

56 Cronograma: apresenta informaes referentes s atividades do projeto (Figura 18). Para isso faz uma relao de todas as atividades do processo, e para cada uma informa o esforo em horas (contadas desde quando o agente iniciar at finalizar sua atividade atravs da TaskAgenda) direcionado aquela atividade, estado atual da mesma, a data inicial e final estimada, a data inicial real e data final real que as atividades foram realizadas e tambm exibe uma quanto s atividades que fazem parte do caminho crtico do processo. Atravs deste relatrio o gerente pode ter uma viso mais ampla quanto as datas estimadas e reais das atividades do projeto, um progresso da execuo do projeto determinado pela comparao de atributos reais de tarefas, esforo e cronograma com o que foi planejado nos marcos ou em pontos definidos no planejamento (SOFTEX, 2006b).

Figura 18 - Cronograma de atividades do projeto

Plano de Recursos Humanos: informa o agente alocado a cada atividade e qual o papel est exercendo naquela atividade, alm de informar as horas trabalhadas do agente para cada atividade do projeto (Figura 19). O uso desse relatrio contribui para que o gerente tenha informaes mais precisas de como e quando os agentes do projeto esto sendo designados para quais funes na organizao (SOFTEX, 2006b).

57

Figura 19 - Plano de Recursos Humanos do projeto

Com um processo modelado e em execuo no ambiente WebAPSEE possvel a recuperao de diversas informaes necessrias para a elaborao do Plano do Projeto como perodo das atividades, agentes envolvidos, artefatos, recursos, dentre outros. A gerao de relatrios como estes que foram apresentados, permite uma maior automatizao das atividades relacionadas ao planejamento do projeto, e de acordo com a proposta deste trabalho, essa recuperao pode ser feita de maneira integrada, diminuindo a necessidade de integrao dos planos em documentos externos ao ambiente WebAPSEE agilizando a tarefa de documentao do processo.

5.3 Propostas de Adaptaes do Modelo de Dados

O meta-modelo do ambiente WebAPSEE, apresenta um conjunto de componentes desenvolvidos buscando apoiar o gerenciamento do processo de software, aumentando o seu grau de automatizao (LIMA REIS, 2003). A Figura 20 mostra o diagrama de pacotes do meta-modelo WebAPSEE ilustrando os componentes e seus relacionamentos de dependncia, alguns componentes do meta-modelo so refinados em novos pacotes. A discusso desta seo concentrada nas informaes relevantes para gerao do Plano do Projeto, mais especificamente nos pacotes Organization e no subpacote OrganizationPolicies. Maior detalhamento sobre os outros pacotes pode ser vistos em LABES (2008).

58

Figura 20 - Componentes do meta modelo do WebAPSEE

5.3.1 Pacote Organization

O detalhamento do pacote Organization, representado na Figura 21, contm os aspectos relacionados estrutura organizacional envolvida. As informaes sobre a organizao foram divididas em subpacotes e as informaes de cada pacote so destacadas a seguir: Pacote Agents: o diagrama de classes do pacote Agent prope uma definio especfica s pessoas da organizao, facilitando o controle de alocao de pessoas em um processo. O diagrama contm todas as informaes relacionadas s pessoas da organizao, seus grupos, cargos, habilidades e afinidades; Pacote TaskAgenda: a agenda o principal mecanismo de comunicao entre execuo e agentes no WebAPSEE, essa classe possui uma agenda para cada processo que o agente participa, sendo cada processo composto de vrias

59 tarefas. Instncias de task esto associadas a atividades do processo e guardam o estado e local da execuo da atividade do agente; Pacote Resources: o modelo consiste de tipos e recursos e instncias de recursos relacionados entre os mesmos. Atravs do componente Types definida uma hierarquia de recursos (exclusive, shareable, consumable) em que cada um possui um identificador, um nome e uma descrio; Pacote Planner_Info: possui como classe principal InstantiationPolicyLog, composta de vrios registros de instanciao de atividades (ActivityInstantiated). Para cada atividade instanciada so registradas vrias sugestes de instanciao de agentes (AgentInstantiationSuggestion), cada sugesto referenciando: um ReqAgent (classe que contm informaes de cargo requerido para a atividade, bem como o conjunto de habilidades necessrias para poder realiz-la); a poltica adotada; uma lista de agentes sugeridos e o agente escolhido; Pacote OrganizationPolicies: contm os projetos da organizao e so indicadas as polticas adotadas pela mesma. Os projetos refletem informaes derivadas de processos de software que so executados na organizao. Um projeto refere-se a um processo que ocorre na organizao, indicando a data de incio e fim reais e quais so os artefatos finais, por exemplo, cdigo-fonte e executveis produzidos pelo projeto. A organizao pode ainda habilitar algumas polticas para serem adotadas por todos os seus processos. Os atributos automatic_instantiation e policy_evaluation_priority_local da classe Organization descrevem configuraes necessrias para o mecanismo de instanciao.

Figura 21 - Pacote Organization aspectos da estrutura organizacional (LABES, 2008)

60 5.3.2 Modificaes no Pacote Organization Policies Esta seo apresenta as novas classes que foram acrescentadas ao pacote OrganizationPolicies para garantir a proposta em questo. A especificao feita atravs do diagrama de classes, apresentado na Figura 22. As classes destacadas em verde so as que foram acrescentadas ao modelo para suportar as estruturas de dados relacionadas ao Plano do Projeto.

Figura 22 - Variao do Modelo de Classes do pacote OrganizationPolicies

61 Para cada plano que faz parte do Plano do Projeto e que ainda no gerado no formato de um relatrio, foi acrescentada uma nova classe que associada ao projeto. Cada nova classe possui as informaes necessrias para a gerao do plano especfico. Essas informaes so descritas na seo 3.3. O Plano do Processo, discutido na seo 3.3.5, representado pela classe ProcessPlan e contm dois conjuntos de caractersticas: as caractersticas de qualidade (QualityCharacteristic) e as caracterstica para embasamento de escolha do processo dividida em categorias (CategoryCharacteristic). A classe QualityCharacteristic contm um conjunto de caractersticas de qualidade sendo que cada caracterstica tem uma relevncia, e para cada Plano do Processo existi um conjunto de categorias de caractersticas (CategoryCharacteritics) com vrios critrios cada uma. A classe Risk representa os riscos que esto associados a um projeto e fazem parte do Plano do Projeto. Cada risco tem um plano de gerenciamento, representado pela classe RiskManagementPlan, com um plano de mitigao, plano de contingncia, a causa do risco e a conseqncia. Da mesma forma a classe Training representa os diferentes tipos de treinamentos que um projeto pode realizar e os vrios agentes que fazem parte do treinamento, compondo assim o Plano de Treinamento. Tanto um risco quanto um treinamento, pode ser reutilizado para outros projetos. Essa reutilizao de dados feita quando o gerente seleciona a opo de importar dados de outro projeto recuperando dados j cadastrados na base, na seo 6.1.1 explicado a partir de que momento importa os dados. A classe associativa ComunicationPlan, representa o fato de que cada artefato de um projeto pode ser um artefato de comunicao sem necessariamente ser um artefato final do projeto, como por exemplo atas de reunies que so comunicadas durante o projeto podem no representar artefatos finais. Esse artefato contm caractersticas prprias como as atividades em que comunicado, o emissor e receptor do artefato (representado por agentes do WebAPSEE).

5.4 API Utilizada na Gerao de Plano Do Projeto

A API que foi utilizada para a gerao do Plano do Projeto foi a RTFTemplate. A escolha pelo formato do documento gerado ser de extenso RTF (Rich Text Format) foi pela necessidade de manipulao dos dados depois da gerao deste documento. Alm de gerar um

62 arquivo mais leve, arquivos no formato RTF podem ser abertos com diferentes editores de texto e podem ser criados em diferentes sistemas operacionais e para leitura em diferentes aplicativos. Nas sees a seguir descrito o funcionamento da API RTFTemplate com uma breve descrio do processo de gerao do arquivo, e como atravs dessa API foi possvel realizar a integrao dos relatrios que j eram geradas pelo WebAPSEE.

5.4.1 API RTFTemplate

RTFTemplate uma engine que possibilita a comunicao entre um Modelo RTF (Template) com Java. RTFTemplate pode gerar documentos RTF com objetos Java a partir de um template (RTFTEMPLATE, 2008). Na Figura 23 apresentado um esquema para gerao do documento usando RTFTemplate: (1) Parse RTF model consiste em carregar o RTF model em uma estrutura chamada RTFDocument, (2) Transform RTF Document substitui cdigo RTF com um macro especfico de acordo com o template e com todos os campos que sero substitudos pelos respectivos valores dos objetos Java, o resultado dessa etapa retorna um novo RTFDocument e (3) consiste em unir a transformao RTFDocument com o contexto Java.

Figura 23 - Gerao do documento usando RTFTemplat (RTTEMPLATE, 2008)

63 Para cada RTFSource que ser utilizado na transformao, de acordo com um template, criada uma classe que contm os atributos que sero substitudos. Para cada atributo desta classe criado uma macro especfica que substituir pelos valores do objeto Java no RTFDocument. A Figura 24 apresenta um trecho do cdigo utilizado para gerao de parte do Plano de Treinamento, a parte destacada mostra os macros que foram criados de acordo com os atributos da classe Training e sero substitudos por seus respectivos valores aps a transformao do RTFDocument em um RTF Target.

Figura 24 - Trecho de cdigo de uma classe template

Os macros criados so substitudas no RTFDocument, passando por um merge que une os dados do RTFDocument com dados do contexto Java originando o documento fim, o RTFTarget. A Figura 25 apresenta um trecho do RTFDocument e as macros (destacadas) utilizadas na substituio de acordo com a classe apresentada na figura anterior.

64

Figura 25 - Macros no arquivo RTFSource

A proposta apresentada neste trabalho faz uso de um template pr definido de Plano do Projeto. Em caso de organizaes que j utilizem seu prprio modelo de Plano do Projeto adaptaes podem ser feitas no documento final gerado. Essas adaptaes podem ser feitas diretamente no documento, pois o arquivo final gerado est em um formato editvel, o formato RTF. Alm disto, adaptaes podem ser feitas no template estabelecido com a utilizao de um arquivo de configurao XML. Essa adaptao permitida visto que a API RTFTemplate pode carregar os dados de acordo com objetos Java ou pode fazer o marge dos dados atravs de um arquivo XML.

5.4.2 Integrao com Relatrios do WebAPSEE

Como descrito na seo 5.2, a arquitetura do ambiente WebAPSEE suporta um mdulo para gerao de relatrios. Atravs dessa estrutura, a funcionalidade de gerao de relatrios especficos para o Nvel G do MPS.BR gera planos que fazem parte do Plano do Projeto. Como a proposta deste trabalho apoiar na gerao do Plano do Projeto de forma integrada, foi realizado um aproveitamento dessa estrutura para integrar esses relatrios no Plano do Projeto. Na seo anterior foi descrito como a engine RTFTemplate faz a substituio dos macros, que foram criados na classe template, no RTFDocument. O uso desses macros possibilitou que os relatrios gerados pelo WebAPSEE fossem adicionados ao RTFTarget. Na gerao de relatrios usando a API jXLS tambm so utilizados macros para recuperao dos dados especficos a partir de consultas no componente DAO (camada servidora). Os mesmos macros que foram definidos para esses relatrios foram incorporados

65 na classe template, recuperando assim as mesmas informaes que eram geradas no relatrio XLS. Na Figura 26 exibido um diagrama de seqncia representando como a engine RTFTemplate faz uso das consultas do componente DAO para recuperao das informaes que j eram recuperadas para gerao de relatrios. Primeiramente a engine RTFTemplate envia uma mensagem solicitando a criao de um novo relatrio ao RTFTemplateBuilder que retorna uma mensagem com a aceitao da criao de um novo relatrio, em seguida o RMIQueryDataSource envia uma mensagem ao servidor para recuperao das informaes da classe QueryDao, que retorna uma coleo com os dados referentes ao mtodo para criao da seo correspondente, no exemplo a seo Cronograma. Para todos os relatrios onde j era feita a consulta e utilizao dos macros, so realizadas chamadas desse tipo fazendo a reutilizao dos mtodos j existentes de relatrios.

Figura 26 - Reutilizao de consultas e macros

66

6 PROTTIPO DO MODELO PROPOSTO PARA O WEBAPSEE

Um prottipo foi implementado com base na especificao de diagramas de classes e descries textuais feitas no captulo anterior. Esse prottipo tem como principal objetivo proporcionar uma base para auxiliar na avaliao do modelo proposto e fazer uma anlise de melhorias para trabalhos futuros. As sees a seguir apresentam de forma resumida o funcionamento do prottipo atravs de uma breve apresentao dos formulrios inseridos no menu Organizao do ambiente WebAPSEE.

6.1 Interface Grfica para Cadastro dos Planos

Como descrito na seo 3.3, a fase de planejamento do projeto gera diferentes planos que contm informaes de como o projeto ser executado permitindo um acompanhamento mais preciso das atividades que sero desenvolvidas durante sua execuo. A partir de um processo modelado no ambiente WebAPSEE, muitas informaes sobre o projeto podem ser recuperadas do modelo (estimativas de atividades do processo, agentes e seus papis, recursos, artefatos), no caso das informaes que ainda no eram recuperadas diretamente do modelo, foram inseridos novos formulrios mais direcionados para o armazenamento de informaes como riscos, caractersticas de qualidade, treinamento e comunicao. No menu Organizao j existia um item Projetos que permitia o cadastramento das informaes iniciais de um projeto. Esta estrutura foi reutilizada para inserir os novos formulrios de definio dos planos. No caso o item Projetos foi transformado em um submenu de Organizao que contm os itens referentes a cada Plano. O formulrio Projetos foi reelaborado passando a ser chamado de Plano do Processo. Na aba principal de Projetos foram acrescentados novos campos para definio do processo, e alm das abas existentes (Add Artefato final e Gerentes de Projeto), foram acrescentadas mais duas abas de caractersticas.

67 A Figura 27 apresenta o antigo formulrio Projetos e a Figura 28 apresentada o menu Organizao e o submenu Projetos que lista os itens referentes a cada plano.

Figura 27 - Antigo formulrio de Projetos

Figura 28 - Submenu Projetos e os itens para cada plano

6.1.1 Plano do Processo

O formulrio de cadastramento, mostrado na Figura 29, contm seis abas referentes s informaes iniciais do projeto. A aba principal a de cadastramento de um novo projeto, que

68 associado a um processo modelado no WebAPSEE, onde definido o tipo de software, a natureza do projeto, o tipo de software desenvolvido, a data inicial e final do projeto e uma descrio sobre o processo de desenvolvimento utilizado no projeto. Aps o cadastramento de um projeto nesta aba principal, ou da recuperao de um projeto j existente, as outras abas do formulrio so carregadas com os dados referentes aquele projeto. Caso um projeto no seja selecionado, nenhuma informao carregada nas outras abas, os campos apresentam valores vazios impedindo que informaes sobre o projeto (gerente, artefatos, caractersticas) sejam cadastradas.

Figura 29 - Novo formulrio de cadastro de projeto

Aps o preenchimento do formulrio, quando o boto Add/Atualizar exibido um popup fazendo um questionamento se o gerente deseja importar dados de outro projeto. Caso o gerente selecione a opo de importao dos dados, outro popup exibido para escolha de qual projeto os dados sero importados (Figura 30). Com a escolha do projeto os dados referentes a ele so carregados de acordo com o processo ao qual est relacionado.

69 A importao dos dados feita de maneira seletiva, os dados mais gerais como riscos, treinamentos, avaliao inicial das caractersticas de qualidade, informaes sobre caractersticas de escolha do processo, artefatos de comunicao so importados direto. No caso de informaes mais especficas do projeto, a exemplo do gerente de projetos e datas das atividades, feito um tratamento para que este as informaes importadas estejam de acordo com o processo ao qual o projeto est associado. ambiente WebAPSEE. Apesar de um projeto ter caractersticas nicas (PMBOK, 2004), a possibilidade de reutilizao de dados de outro projeto permite um reaproveitamento de boas prticas aprendidas, alm de agilizar na gerao de planos para projetos semelhantes. O Grfico de Gantt no gerado diretamente no Plano do Projeto. Essa informao dever ser obtida diretamente pelo

Figura 30 - Importao de Projeto

6.1.1.1 Caractersticas Para Escolha do Processo A Figura 31 mostra a aba de caractersticas para embasamento da escolha do processo de desenvolvimento, onde so listadas as sete categorias de critrios para escolha do modelo de ciclo de vida do processo. Essas categorias de critrios esto divididas da seguinte forma: critrios relacionados ao problema, ao produto, aos recursos, equipe de desenvolvimento, gerncia de projeto e ao desenvolvimento. Para cada categoria de critrios selecionados no menu de caractersticas, o painel central do formulrio atualizado carregando novas informaes referentes ao critrio

70 selecionado, como exemplo a figura apresenta os critrios que esto relacionados gerncia de projetos. Os valores de cada critrio podem variar de acordo com a categoria selecionada, no caso dos critrios relacionados gerncia os valores possveis so baixo, mdio e alto, para critrios relacionados ao produto os valores so pequeno, mdio e grande. A cada mudana de categoria tanto os critrios como os valores dos combobox so atualizados.

Figura 31 - Aba de caractersticas para escolha do processo

6.1.1.2 Avaliao Inicial das Caractersticas de Qualidade Uma avaliao inicial das caractersticas de qualidade do produto a ser desenvolvido no projeto pode ser feita atravs da aba Caractersticas de Qualidade, exibida na Figura 32. Nesta aba so listadas as seis principais caractersticas de qualidade do produto, essas caractersticas so retiradas do template de Plano do Projeto definido para o CTIC UFPA e esto baseadas na norma ISO/IEC 9126-1, para cada caracterstica pode ser associado os seguintes valores: irrelevante, pouco relevante, relevante, muito relevante, imprescindvel.

71

Figura 32 - Aba para avaliao inicial das caractersticas de qualidade do produto

6.1.2 Plano de Comunicao

O formulrio Plano de Comunicao (Figura 33) exibe os artefatos da organizao, estes artefatos so cadastrados no formulrio de artefatos do WebASPEE. Para cada artefato utilizado na comunicao so cadastradas novas caractersticas como as atividades onde ele comunicado, os agentes envolvidos na sua emisso e recepo, a forma de comunicao descrita em seguida.

72

Figura 33 - Plano de Comunicao

6.1.3 Plano de Riscos

Na Figura 34 apresentado o formulrio de Plano de Riscos. Neste formulrio so listados os principais riscos que podem ocorrer durante o projeto (retirados do template de Plano do Projeto, visto no Anexo 1), a cada risco so atribudas trs informaes relevantes para sua anlise: a probabilidade para que ocorra, o impacto que este causar caso ocorra e a sua prioridade. Cada risco apresentado neste formulrio tem cadastrado na base de dados um plano de mitigao, um plano de contingncia, a possvel causa do risco e a conseqncia caso o risco ocorra.

73 Um risco caracterizado por ser gerenciado ou no, esta identificao feita pela marcao do checkbox. Caso um risco seja identificado como gerenciado, o seu identificador armazenado e o seu respectivo plano de mitigao cadastrado na base exibido em uma listagem mais refinada que contm somente os riscos caracterizados como gerenciados.

Figura 34 - Plano de Riscos

6.1.4 Plano de Treinamento

A necessidade de treinamento da equipe pode ser cadastrada no formulrio Plano de Treinamento, apresentado na Figura 35. Este formulrio tem a funo de cadastrar os dados referentes aos treinamentos do projeto como o nome do treinamento, o ministrante, os participantes do treinamento (podem ser identificados atravs de uma listagem dos agentes envolvidos no projeto), a data inicial e final do treinamento, a justificativa pra realizao do mesmo e uma breve descrio podem ser feitas nas caixas de texto a direita do formulrio.

74

Figura 35 - Formulrio de Plano de Treinamento

6.1.5 Relatrios do WebAPSEE

Como j foi discutido no incio do captulo, muitas informaes contidas no Plano do Projeto so obtidas atravs de um processo modelado no WebAPSEE. Essas informaes so recuperadas na forma de relatrios especficos do MPS.BR nvel G. Como o cronograma e o plano de recursos humanos j foram descritos na seo 4.2, a seguir so listados os outros relatrios relevantes para a propostas gerados no WebAPSEE e integrados no Plano do Projeto. Estrutura Analtica do Processo: exibe todas as atividades inseridas no processo, atravs de uma subdiviso das principais atividades em componentes menores e mais facilmente gerenciveis; Plano da Organizao: exibe a estrutura organizacional da instituio e ir auxiliar na construo do Plano de Recursos Humanos do Projeto;

75 Plano de Custos: informa os gastos obtidos com os recursos do projeto, contm valores financeiros alocados ao projeto, tanto em utilizao de recursos de apoio diversos, quanto em horas de trabalho; Plano de Gerncia de Documentos: mostra os dados referentes aos documentos (artefatos) de um projeto, identifica as vrias formas de documentao necessrias para apoiar o projeto; Plano de Recursos: informa dados sobre os recursos alocados como custo e perodos de alocaes (data inicial, data final).

6.2 Gerao de Plano do Projeto

O ltimo item do submenu Projetos o Gerar Plano, atravs desse formulrio (Figura 36) o gerente escolhe o projeto para o qual deseja gerar o Plano do Projeto, e em seguida seleciona onde o arquivo gerado ser salvo.

Figura 36 - Formulrio para gerao de Plano do Projeto

Ao gerar um plano, a engine RTFTemplate invocada e passa como parmetro o template e os dados especficos para gerao do relatrio em um formato RTF. As informaes cadastradas em cada formulrio apresentado nesta seo so carregadas da base de dados e substitudas nos macros definidas no template. As informaes que eram obtidas com a gerao dos relatrios separadamente tambm so carregadas de acordo com os macros definidos na classe ReportGenerator (explicado na seo 5.4.2). Desta forma o RTFTarget (arquivo final gerado) contm tanto os dados obtidos pela modelagem do processo como pelo cadastramento nos novos formulrios de maneira integrada gerando o Plano do Projeto.

76 A tabela 2 mostra quais os dados j eram obtidos com a gerao dos relatrios pelo WebAPSEE e quais informaes foram adicionadas pelos novos formulrios inseridos pela proposta. No Anexo 1 so destacadas as sees que j eram atendidas em forma de relatrio e as sees que foram inseridas.
Tabela 2 - Planos Integrados

INTEGRAO DE PLANO DO PROJETO Relatrio WebAPSEE Inserido pela Proposta Plano do Processo X EAP (WBS) Cronograma Plano de Recursos Humanos Plano de Treinamento Plano de Recursos de Apoio Plano de Custos Plano de Comunicao Plano de Riscos Plano do Projeto X X X X X X X X X

6.3 Modificaes no Plano do Projeto

O monitoramento do projeto depende de uma organizao adequada das informaes de planejamento, e no decorrer do projeto elas so comparadas s informaes obtidas durante sua execuo (SOFTEX, 2006b). Buscando uma maior visibilidade do real andamento do projeto, essas informaes iniciais podem ser alteradas e o planejamento dever ser revisto levando a gerao de uma nova verso do Plano do Projeto. O Prottipo no apresenta um esquema para controle de verses do documento que gerado sendo proposto como trabalho futuro deste trabalho.

6.4 Exemplo de Uso do Prottipo

Para uma avaliao inicial do funcionamento do prottipo proposto, um projeto bsico foi criado no ambiente WebAPSEE, o Projeto WebAPSEE. Esse projeto est relacionado ao processo de manuteno do WebAPSEE e contm informaes fictcias a respeito da organizao que o desenvolve.

77 Aps a modelagem do processo, estimativas foram atribudas s atividades e cada plano que compe o Plano do Projeto foi cadastrado em seu respectivo formulrio, simulando a representao do planejamento de um projeto completo. O resultado do arquivo gerado um documento no formato RTF que contm as mesmas caractersticas que foram definidas no template inicial (RTFSource). Devido extenso do documento final (total de 36 pginas), a seguir so apresentados alguns trechos mais relevantes para representar o exemplo de uso do prottipo. Na Figura 37 representado um trecho do plano do processo, com identificao da natureza do projeto, o tipo de software, algumas caractersticas para escolha do processo,uma tabela com a avaliao das caractersticas de qualidade, o ciclo de vida escolhido e uma descrio do processo. vlido ressaltar que com uma extenso de arquivo RTF, a formatao definida no template mantida, possibilitando uma melhor visualizao do documento.

78

Figura 37 - Exemplo de Plano do Processo

A Estrutura analtica do Projeto (Figura 38) j era gerada na forma de um relatrio pelo WebAPSEE que foi integrado do Plano do Projeto

79

Figura 38 - EAP gerada no Plano do Projeto

Na Figura 39 exibido um trecho do Plano de treinamento composto de dois treinamentos aplicados no projeto.

Figura 39 - Exemplo de Plano de Treinamento

O Plano de Comunicao representado na Figura 40 a seguir com a listagem dos artefatos de comunicao selecionados e suas caractersticas.

80

Figura 40 - Plano de Comunicao

O Plano de Riscos e apresentado na Figura 41, com a representao dos riscos e os valores relacionados a ele, em seguida uma listagem dos riscos gerenciados feita. Essa listagem feita atravs da marcao do checkbox que indica se um risco gerenciado ou no no formulrio de Plano de Riscos, como s foram marcados trs riscos como gerenciados somente eles so exibidos no relatrio.

81

Figura 41 - Plano de riscos e riscos gerenciado

6.5

Aderncia aos Resultados MPS.BR O modelo utilizado para gerao do Plano do Projeto foi elaborado visando atender aos

resultados esperados do processo Gerncia de Projetos Nvel G do MR-MPS. Para representar

82 os resultados que so atendidos pelo Plano do Projeto, a tabela 3 composta de duas colunas relacionando os resultados esperados (GPR), a seo do Plano do Projeto que contm as evidncias que atendem aquele resultado e a ultima coluna representando o nvel de atendimento do resultado. Os valores de atendimento so: totalmente atendido quando o resultado gerado diretamente pelo relatrio sem necessidade do gerente inserir novos dados; parcialmente atendido quando parte da evidencia gerada porm algumas informaes precisam ser inseridas aps a gerao do Plano do Projeto; e no atendido quando a informao no gerada com o Plano do Projeto e o gerente precisa preencher os campos diretamente no Plano do Projeto.
Tabela 3 Resultados esperados contemplados

ATENDIMENTO AOS RESULTADOS ESPERADOS Resultado Esperado GPR1 - O escopo do trabalho para o projeto definido GPR2 - As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados GPR3 - O modelo e as classes do ciclo de vida do projeto so definidos GPR4 - O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas Seo do Plano do Projeto Seo 6 Seo 6 Evidncia do resultado EAP EAP Nvel de atendimento Totalmente Atendido Totalmente Atendido Totalmente Atendido No Atendido Totalmente Atendido Totalmente Atendido Totalmente Atendido Totalmente Atendido Totalmente Atendido

Seo 4 Seo 5 Seo 7 Seo 11

Plano do Processo Estimativas do Software Plano de Custos Cronograma Plano de Custos Cronograma (caminho crtico) Plano de Riscos

GPR5 - O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, so estabelecidos e mantidos

Seo 7 Seo 11

GPR6 - Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e

Seo 14

83 prioridade de tratamento so determinados e documentados GPR7 - Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo GPR8 - As tarefas, os recursos e o ambiente de trabalho necessrios para executar o projeto so planejados

Seo 8

Plano de Recursos Humanos Plano de Alocao de Recursos de Apoio Cronograma Plano de Gerncia de Documentos do Projeto

Parcialmente Atendido Totalmente Atendido

Seo 10

Seo 11 GPR9 - Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana GPR10 - Planos para a execuo do projeto so estabelecidos e reunidos no Plano do Projeto GPR11 - A viabilidade de atingir as metas do projeto, considerando as restries e os recursos disponveis, avaliada. Se necessrio, ajustes so realizados GPR12 - O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido GPR13 - O progresso do projeto monitorado com relao ao estabelecido no Plano do Projeto e os resultados so documentados GPR14 - O envolvimento das partes interessadas no projeto gerenciado GPR15 - Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento GPR16 - Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas Seo 12

Totalmente Atendido Parcialmente Atendido

Plano do Projeto integrado No se aplica

Plano do Projeto No se aplica

Parcialmente Atendido No se aplica

Seo 15

Aceitao do Plano do Projeto Grfico de Gantt Plano de Comunicao No se aplica No se aplica

No Atendido

Seo 7

Parcialmente Atendido Totalmente Atendido No se aplica No se aplica

Seo13 No se aplica No se aplica

84 GPR17 - Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso No se aplica No se aplica No se aplica

A GPR 11 no se aplica ao documento de Plano do Projeto, pois faz parte de outro artefato do projeto, o Plano de Viabilidade. No caso das GPR 15, 16 e 17 no se aplicam, pois alm de fazerem parte de outro artefato do projeto, so atividades que ocorrem aps a fase de planejamento do projeto, no fazendo parte do Plano de Projeto. Neste captulo foi apresentado o prottipo para o modelo proposto no trabalho, este prottipo se encontra operacional, porm algumas modificaes quanto a sua estrutura precisam ser melhoradas. O documento final gerado apresenta as informaes de cada plano descrito e a estrutura principal est de acordo com o template estabelecido inicialmente, algumas informaes quanto a imagens e formatao do documento precisam ser adaptadas aps o documento ser gerado para manter a estrutura do documento.

85

7 CONCLUSES

A gerncia de projeto de software objetiva qualidade, produtividade e reduo de riscos atravs de planejamento e execuo do desenvolvimento do produto. O planejamento de um projeto envolve alm da especificao de metas e objetivos a elaborao de estratgias e procedimentos para alcanar o objetivo do processo. O resultado do planejamento de um projeto evidenciado atravs de documentos, referncias e at mesmo por diagramas, e ao conjunto organizado desses resultados d-se o nome de Plano do Projeto (SOFTEX, 2006b). Tanto o PMBOK, que destaca um processo para desenvolvimento do Plano do Projeto, quanto o MPS.BR, onde o plano um dos resultados esperados para nvel G (GPR 10), mostram a importncia da elaborao desse documento. Este trabalho apresentou uma proposta para apoiar a gerao automatiza de Plano do Projeto atravs do ambiente WebAPSEE. Para realizao da proposta houve a preocupao de realizar um estudo a respeito da Gerncia de Projetos, mais especificamente ao Planejamento do Projeto, e como esta feita de acordo com normas e modelos de referncia tais como CMMI e MPS.BR. O estudo de normas e modelos de referncia que se destacam, seja por sua qualidade ou aplicao, permitiu um maior entendimento sobre como a gerncia de projetos ganha destaque quando se pretende aumentar a qualidade do processo de desenvolvimento de software e como, principalmente na fase de planejamento, importante a integrao dos vrios documentos gerados em uma nica referncia, o Plano do Projeto, j que torna-se a principal fonte de informaes e acompanhamento do projeto. Neste captulo so descritas as principais contribuies do trabalho, em seguida so apresentados as limitaes da proposta, os trabalhos futuros que visam complementar a proposta do trabalho e as consideraes finais do trabalho.

86

7.1 Contribuies
Na fase de planejamento de um projeto, diversos documentos (os planos) so gerados e a tarefa de integrao desses planos em um nico documento, o Plano do Projeto, trabalhosa e pode provocar atrasos na fase de planejamento do projeto. A principal contribuio da proposta apresentada o auxilio automatizado a gerao do Plano do Projeto integrado atravs do ambiente WebAPSEE diminuindo o tempo para elaborao do mesmo. Outra contribuio foi permitir a recuperao de dados de outros projetos desenvolvidos pela organizao, se tornando til medida que a organizao desenvolve projetos semelhantes utilizando um processo bsico. Atravs da importao desses dados, a tarefa de elaborao do Plano do Projeto torna-se mais rpida, alm disso, o gerente pode fazer uso de boas prticas aprendidas em outros projetos visando melhorias no processo adotado pela organizao.

7.2 Limitaes do Trabalho

Uma das limitaes do trabalho o uso de um modelo pr-definido de Plano do Projeto. Este modelo foi elaborado baseado na experincia obtida com a implantao de processo de desenvolvimento de software no CTIC - UFPA, e condiciona o gerente a usar um modelo fixo que pode omitir informaes que seriam teis para um projeto especfico. O fato da proposta no fornecer um mecanismo integrado para clculo de estimativas, tambm uma limitao percebida. Devido diversidade de mtodos e heursticas para clculo de estimativas descritos na literatura (pontos por funo, pontos por caso de uso, estimativas Wideband Delphi, dentre outras), um estudo mais especfico necessrio para elaborao de um mecanismo que atenda essa diversidade. Outra limitao o fato de o mecanismo no permitir um controle quanto a verses do Plano do Projeto de forma automatizada. Para cada vez que o Plano gerado no indicada qual a verso do documento, sendo preciso que o gerente cadastre essa informao diretamente no documento gerado.

7.3 Trabalhos Futuros

Entre as atividades futuras previstas para o trabalho est o desenvolvimento de melhorias e evoluo do prottipo que no foram implementadas devido restrio de tempo

87 para concluso deste trabalho, como o cadastramento de novos riscos, um maior tratamento na importao dos dados de outros projetos e melhorias nas interfaces com usurio. Dentre as melhorias est a integrao de mecanismo para clculo de estimativas atravs do ambiente WebAPSEE atendendo as principais tcnicas existentes na literatura. Ainda como trabalho futuro, desenvolver um mecanismo para aceitao do Plano do Projeto atravs da agenda do desenvolvedor. Alm de sua utilizao para a proposta apresentada, essa funcionalidade pode ser utilizada para aceitao de outros artefatos gerados no processo como, por exemplo, ata de reunio. Por fim a experimentao da proposta em um projeto no CTIC- UFPA possibilitando uma avaliao da proposta seja em uma escala maior de complexidade. O objetivo obter um feedback quanto a efetividade no auxlio ao planejamento do projeto, avaliar se com o uso da proposta o tempo decorrido para gerao do Plano do Projeto foi melhorado em comparao com projetos j executados, e em seguida identificar oportunidades e pontos de melhoria.

7.4 Consideraes Finais

Caracterizada como uma das atividades iniciais do projeto, o planejamento do projeto tem como principal resultado o Plano do Projeto. Este documento de grande importncia para o projeto j que se torna a principal referncia de como o projeto ser desenvolvido, permitindo ao gerente um acompanhamento mais preciso das informaes do projeto. O desenvolvido desta proposta facilitou um melhor entendimento como este documento elaborado e sua importncia para o projeto de maneira geral. Como lies aprendidas no decorrer deste trabalho destacado um melhor entendimento a respeito do programa MPS.BR, que foi utilizado como base para elaborao da proposta, e como os resultados esperados deste programa podem ser alcanados atravs dos planos integrados no Plano do Projeto. Outra lio foi perceber o quanto automatizao de atividades agiliza a maneira com que o projeto desenvolvido, no caso desenvolvido na proposta a elaborao de documentos da fase de planejamento poder ser realizada de maneira mais rpida.

88

REFERNCIAS

AHERN, D. M.; CLOUSE, A.; TURNER, R.CMMI Distilled: A Practical Introduction to Integrated Process Improvement. 2ed. Boston: Ed. Addison-Wesley, 2004. ARBAOUI, S.; DERNIAME, J.; OQUENDO, F.; VERJUS, H. A comparative review of Process-Centered Software Engineering Environments. Annals of Software Engineering, The Netherlands, v. 14, p. 311-340, 2002. BERGER, P. M. Instanciao de Processos de Software em Ambientes Configurados na Estao TABA. 2003. 128f. Dissertao (Mestrado em Engenharia de Sistemas e Computao) - Programa de Ps Graduao de Engenharia, Universidade Federal do Rio de janeiro Rio de Janeiro, 2003. COSTA, A. J.; SALES, E. O. Uma Proposta Para Reutilizao De Processos De Software Para O Ambiente WebAPSEE. 2007. 87f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) - Instituto de Cincias Exatas e Naturais, Universidade Federal do Par, Belm, 2007. DONZELLI, P. A Decision support system for software project management. Department of Computer Science. Maryland University, U.S.A., August 2006. DOWNSON, M. Towards requiriments for enactment mechanisms. In: INTERNATIONAL CONFERENCE ON SOFTWRE PROCESS, ICSP, 2. ProceedingsBerlin, Germany: IEEE Computer Society Press, 1993. FALBO, R. A., Integrao de Conhecimento em um Ambiente de Desenvolvimento, Tese de D. Sc. , COPPE/UFRJ, Rio de janeiro, R.J., Brasil,1998. FARIAS, L. L. Planejamento de riscos em ambientes de desenvolvimento de software orientados organizao. 2002 150f. Dissertao (Mestrado em Engenharia de Sistemas e

89 Computao) - Programa de Ps Graduao de Engenharia, Universidade Federal do Rio de janeiro Rio de Janeiro, 2002. FEILER, P.; HUMPHREY, W. Software Process Development and Enactment: Concepts and Definitions. In: INTERNATIONAL CONFERENCE ON THE SOFTWARE PROCESS, ICSP, 2, 1993, Berlin. Proceedings Berlin, Germany: IEEE Computer Society Press, 1993. FRANCH, X.; RIB, J. Supporting Process Reuse in PROMENADE. Research Report n. LSI-02-14-R, Departament de Lenguatges i Sistemes Informtics, Universitat Politcnica de Catalunya, Feb. 2002. FUGGETTA, A. Software Process: A Roadmap. In: PROC. OF THE FUTURE OF SOFTWARE ENGINEERING, ICSE2000, Limerick, Ireland, 2000. GIMENES, Itana. O Processo de Engenharia de Software: Ambientes e Formalismos. In: XIII JAI, XIV Congresso da SBC, Caxambu-MG. AnaisCaxambu: 1994. GRUHN, V. Process-Centered Software Engineering Environments: A brief history and future Challenges. Annals of Software Engineering, Kluwer, v. 14, p. 363-382. 2002. HAEFEL, R. M. J2EE Web Services. Addison-Wesley, 2003. HUMPHREY, W. S. Characterizing the Software Process: A Maturity Framework. Software, IEEE, p73-79, mar. 1988. ISO/IEC 12207. Tecnologia de Informao - Processos de ciclo de vida de Software, ABNT - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS, Rio de Janeiro: ABNT. 1998. ISO/IEC 9126-1. The International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 9126-1: Software Engineering Product Quality Part 1: Quality Model, Geneve: ISO, 2003. JOHNSON, J.Micro Projects Cause Constant Change The Standish Group International, 2001 Disponvel em: <http://www.xp2001.org/xp2001/conference/papers/Chapter30Johnson.pdf>. Acesso em: 27 set. 2008. JXLS. JXLS Project Documentation. Disponvel em: <http://jxls.sourceforge.net> Acesso em: 28 nov. 2008.

90 LABES. Laboratrio de Engenharia de Software da Universidade Federal do Par. Documentao de Referncia do Sistema WebAPSEE 1.3. Belm, 2008. LIMA REIS, C. A. Uma Abordagem Flexvel para Execuo de Processos de Software Evolutivos. 2003. 277f. Tese (Doutorado em Cincia da Computao) - Instituto de Informtica, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2003. LIMA REIS, C. A.; REIS, R. Q.; NUNES, D. J. APSEE: Uma Abordagem Integrada para Automao da Gerncia de Processo de Software. In: Simpsio Brasileiro De Engenharia De Software - Sesso de Ferramentas, 17, 2003, Manaus. LIMA, A. M.; COSTA, A. J. S.; FRANA, B. B. N.; REIS, R. Q.; LIMA REIS C. A. Gerncia Flexvel de Processos de Software com o Ambiente WebAPSEE. In: Simpsio Brasileiro de Engenharia de Software Sesso de Ferramentas, 19, 2006b, Florianpolis. LIMA, M.; LIMA REIS, C. A.; REIS, R. Q. Anlise do Ambiente WebAPSEE no atendimento aos requisitos de Gerncia de Processos de Software. In: Semana Paraense De Informtica, 10, 2006a, Belm. MICROSOFT. Viso geral do produto Microsoft Office Project. Disponvel em:<http://office.microsoft.com/ptr/project/HA101656381046.aspx?pid=CL100627011046> Acesso em: 15 out. 2008. MPS-CTIC. Relatrio Tcnico Levantamento da Situao Atual do CTIC UFPA. 2007. NGUYEN, M.; WANG, A. Total Software Process Model in Epos. In: International Conference on Software Engineering, 19, Boston, Massachusetts, USA, 1997. PAXIUBA, C. M. C. Acompanhamento e Avaliao de Projetos atravs da Monitorao de Eventos em um Ambiente de Gesto de Processos de Software. 2007. 104f. Dissertao (Mestrado em Engenharia Eltrica) Instituto Tecnolgico, Universidade Federal do Par, Belm, 2007. PMBOK, 2004. Project Management Institute PMI. A Guide to the Project Management Body of Knowledge - PMBOK, Syba: PMI Publishing Division, 2004. Disponvel em: <www.pmi.org>. Acesso em: 24 nov. 2008. PRESSMAN, Roger. S. Software Engineering: A practitioners approach. 6.ed. McGraw Hill. 2005.

91 PROJITY. Site Oficial da Ferramenta OpenProj. Disponvel em: <http://openproj.org> Acesso em: 25 out. 2008. REIS, R. Q. APSEE-Reuse: Um Meta-Modelo para Apoiar a Reutilizao de Processos de Software. 2002a. 215f. Tese (Doutorado em Cincia da Computao) Instituto de Informtica, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2002. REIS, R. Q.; LIMA REIS, C. A.; NUNES, D. J. Automao no Gerenciamento do Processo de Engenharia de Software. In: Escola Norte de Informtica, 2006b, Belm. REIS, R. Q.; NUNES, D. J. Uma Avaliao dos Paradigmas de Linguagens de Processo de Software. 1999. Trabalho Individual II, Programa de Ps-Graduao em Computao, Universidade Federal do Rio Grande do Sul, Porto Alegre. RMI. Site oficial de Java RMI - Remote Method Invocation 2008. Disponvel em <http://java.sun.com/products/jdk/rmi/>. Acesso em: 25 nov. 2008. ROCHA, A. R.; MONTONI, M.; SANTOS, G.; MAFRA, S.; FIGUEIREDO, S.; BESSA, A.; MIAN, P. Estao TABA: Uma Infra-estrutura para Implantao do Modelo de Referncia para Melhoria de Processo de Software. In: Simpsio Brasileiro de Qualidade de Software, 4, 2005, Porto Alegre. RTFTEMPLATE. Site oficial da API RTFTemplate. <http://rtftemplate.sourceforge.net/>. Acesso em: 18 nov. 2008. Disponvel em:

RUS, I.; LINDIVAL, M. Knowledge Management in Software Engineering. SCHNAIDER, L. R. C. Planejamento da Alocao de Recursos Humanos em Ambientes de Desenvolvimento de Software Orientados Organizao. 2003. 133f. Dissertao (Mestrado em Cincias em Engenharia de Sistemas e Computao) - Programa de Ps Graduao de Engenharia, Universidade Federal do Rio de janeiro Rio de Janeiro, 2003. SEI, 2006. Capability Maturity Model Integration (CMMI), Version 1.2, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. Disponvel em: <http://www.sei.cmu.edu.> Acesso em: 20 nov. de 2008. SILVA, M. A. WebAPSEE-Planner Auxlio a Alocao de Pessoas em Projetos de Software atravs de Polticas. 2007. 139f. Trabalho de Concluso de Curso (Graduao em Cincia da Computao) - Instituto de Cincias Exatas e Naturais, Universidade Federal do Par, Belm, 2007.

92

SOFTEX. Sociedade para Promoo da Excelncia do Software Brasileiro, MPS.BR Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.2). Disponvel em: <http://www.softex.br/mpsbr/guias/MPS.BR_Guia_Geral_V1.2.pdf>. Acesso em: 15 ago. 2008a. SOFTEX. Sociedade para Promoo da Excelncia do Software Brasileiro, MPS.BR Melhoria de Processo do Software Brasileiro, Guia de Implementao Parte 1 (v. 1.1). Disponvel em: <http://www.softex.br/mpsbr/guias/MPS.BR_Guia_de_Implementacao_Parte_1_V1.1.pdf>. Acesso em: 16 ago. 2008. TABA. Site Oficial da Estao TABA. Disponvel em: < http://ramses.cos.ufrj.br/taba/>. Acesso em: 30 out. 2008. THAYER, R. Software Engineering Project Management. In: THAYER, R. H. Software Engineering Project Management. 2. ed. Los Alamitos: IEEE Computer Society Press,1997. p.72- 104. WEBAPSEE. Manual de Utilizao do Ambiente WebAPSEE. Disponvel em: < http://www3.ufpa.br/webapsee/images/documentacaoWebAPSEE/manual%20webapsee%20u so%201.3_versaofinal.pdf >. Acesso em: 14 nov. 2008. WEBER, K. C.; ARAJO, E.; MACHADO, C. F. M.; SCALET, D.; SALVIANO, C. F.; ROCHA, A. R. C. Modelo de Referncia e Mtodo de Avaliao para Melhoria de Processo de Software verso 1.0 (MR-MPS e MA-MPS). In: Anais do IV Simpsio Brasileiro de Qualidade de Software - Prmio de melhor artigo tcnico, 2005, Porto Alegre. WEIHRICH, H. 1997, Management Science, Theory and Practice. In: THAYER, R. H. Software Engineering Project Management. 2. ed. Los Alamitos: IEEE Computer Society Press, 1997. p.4- 13. YAN, J.; YANG, Y.; RAIKUNDALIA, G. K. Decentralised Coordination for Software Process Enactment. In: Lecture Notes in Computer Science, Springer Berlin / Heidelberg. 2003. ZANONI, R.; AUDY, J. Gerncia de Projeto de Software em Ambiente Fisicamente Distribudo: Um Estudo de Caso. In: Anais Congresso Argentino de Cincia da Computao - Anais, 20, 2002, Buenos Aires.

93

ANEXO 1

PLANO DO PROJETO
rgo: <Nome do rgo> Ttulo do Projeto: <Nome inicial do Projeto> Responsvel: <Elaborador desta proposta> Solicitante: <Nome do Solicitante> Nro. Solicitao: Dt. Solicitao: < Nmero> <Dt solicitao> Unidade Sub-Unidade: Organizacional: <Sigla da Unidade> <Sigla da Sub-Unidade> Cliente: <rgo ou Setor a atender>

Verses e Revises Deste Documento Data Comentrio Autor Verso

1 2 3 4
4.1 4.2 4.3

Escopo do Projeto Plano da Organizao (RELATRIO WEBAPSEE) Requisitos Iniciais Plano do Processo (INSERIDO PELA PROPOSTA)
Natureza do Projeto Tipo de Software Caractersticas para embasamento da escolha do processo
Critrios relacionados aos Usurios <Baixa, Mdia, Alta> <Baixa, Mdia, Alta> <Baixa, Mdia, Alta>

Referncia: Artefato Proposta Tcnica do Projeto

Referncia: Artefato Plano da Organizao

Referncia: Artefato Lista de Requisitos Iniciais

Experincia dos usurios no domnio da aplicao Facilidade dos usurios em expressar requisitos Grau de acesso aos usurios

94 Critrios relacionados ao Problema Grau de maturidade do domnio da aplicao Complexidade do problema Freqncia de mudanas nos requisitos Grau de magnitude das mudanas nos requisitos Grau de modularidade do problema <Baixa, Mdia, Alta> <Baixa, Mdia, Alta> <Baixa, Mdia, Alta> <Baixa, Mdia, Alta> <Baixa, Mdia, Alta>

Critrios relacionados ao Produto Tamanho da aplicao Grau de complexidade da aplicao Restrio de Desempenho ou Tempo de Execuo Restrio de Segurana <Pequeno, Mdio, Grande> <Pequeno, Mdio, Grande> <Sim, No> <Sim, No> Critrios relacionados aos Recursos Disponibilidade de recursos humanos Disponibilidade de recursos financeiros Restrio de Cronograma <Baixa, Adequada, Alta> <Baixa, Adequada, Alta> <Sim, No>

Critrios relacionados Equipe de Desenvolvimento Experincia da equipe de desenvolvimento da aplicao Experincia da equipe de desenvolvimento em Engenharia de Software Experincia da equipe de desenvolvimento com a plataforma de desenvolvimento Experincia da equipe de desenvolvimento com a tecnologia utilizada <Baixa, Mdia, Alta> <Baixa, Mdia, Alta> <Baixa, Mdia, Alta> <Baixa, Mdia, Alta>

Critrios relacionados Gerncia do Projeto Nvel de experincia da gerncia <Baixo, Mdio, Alto> Capacidade de gerenciamento de mltiplas equipes <Sim, No> Experincia da gerncia no domnio da aplicao <Baixa, Mdia, Alta> Experincia da gerncia em Engenharia de Software <Baixa, Mdia, Alta> Experincia da gerncia com a plataforma de <Baixa, Mdia, Alta> desenvolvimento Experincia da gerncia com a tecnologia utilizada <Baixa, Mdia, Alta>

95 Critrios relacionados ao Desenvolvimento H necessidade de entrega de produtos intermedirios <Sim, No> H necessidade do software ser colocado em uso <Sim, No> rapidamente com funcionalidade total ou parcial Grau dos riscos tcnicos <Baixo, Moderado, Alto> Necessidade de interface com sistemas existentes Uso de tecnologia inovadora <Sim, No> <Sim, No>

4.4

Avaliao Inicial das Caractersticas de Qualidade

Descrio Capacidade do produto de software fornecer funes que satisfazem as necessidades explcitas ou implcitas quando o software e usado sob condies especificadas. Relevncia <Irrelevante, Pouco relevante, Relevante, Muito relevante, Imprescindvel>

Caracterstica

Funcionalidade

Confiabilidade

Capacidade do produto de software <Irrelevante, Pouco relevante, manter o nvel de desempenho Relevante, Muito relevante, especificado quando usado sob as Imprescindvel> condies especificadas. Capacidade do produto de software <Irrelevante, Pouco relevante, ser entendido, ser aprendido e ser Relevante, Muito relevante, atraente ao usurio quando usado sob Imprescindvel> as condies especificadas. Capacidade do produto de software <Irrelevante, Pouco relevante, fornecer o desempenho adequado, Relevante, Muito relevante, relacionado quantidade de recursos Imprescindvel> usados, sob condies estabelecidas.

Usabilidade

Eficincia

Capacidade do produto de software de ser modificado. As modificaes podem incluir correes, melhorias <Irrelevante, Pouco relevante, Manutenibilidade ou adaptao do software a Relevante, Muito relevante, mudanas no ambiente, nos Imprescindvel> requisitos e nas especificaes funcionais. Portabilidade Capacidade do produto de software <Irrelevante, Pouco relevante, ser transferido de um ambiente para Relevante, Muito relevante, outro. Imprescindvel>

96

4.5 4.6

Ciclo de Vida Escolhido Descrio do Processo

5
5.1 5.2

Estimativas do software
Clculo da Estimativa Estimativa Total de Esforo
Horas

Tipo de Esforo Horas de desenvolvimento e teste unitrio (vindo da seo 5.1) Adicional para implantao Adicional de documentao Adicional para testes de integrao 25% Adicional para Gerncia 30% Previso de folga para preparao do ambiente e imprevistos - 10% Total de esforo estimado

5.3

Distribuio do Esforo nas fases do Processo

Percentual (%) 5 20 25 40 10 Total (horas)

Fases do Processo Planejamento Anlise de Requisitos Arquitetura e Projeto do Software Construo e Testes do Software Implantao e Encerramento do Projeto

6 7

Estrutura Analtica do Projeto (RELATRIO WEBAPSEE) Cronograma

Esforo Data Inicial Data Final Esforo Data Real Inicial Real Data Final Real Qtd de Pessoas

Atividade

97

7.1 Grfico De Gantt (GERADO PELO WEBAPSEE)

8
8.1

Plano de Recursos Humanos (RELATRIO WEBAPSEE)

Necessidades do Projeto
Quantidade

Cargo Requerido

8.2

Alocao de Colaboradores para o Projeto

Plano de Recursos Humanos Processo: Nome do Processo Atividade do Processo

Papel

Colaborador

Plano de Treinamento (INSERIDO PELA PROPOSTA)

Treinamento Justificativa Escopo Participantes

10

Plano de Alocao de Recursos de Apoio (RELATRIO WEBAPSEE)

Recursos Exclusivos Recursos Recursos Consumveis Recursos

Descrio

Data Incio

Data Fim

Descrio

Data Incio

Data Fim

Recursos Compartilhveis Recursos Descrio

Data Incio

Data Fim

11

Plano de Custos do Projeto (RELATRIO WEBAPSEE)

Data Inicial Data Final Custo Unitrio (R$) Custo Total (R$) R$ -R$ -R$ -

Recursos Exclusivos (alocao temporria)

Custo Total de Recursos

98 Recursos Consumveis (custeio) Quantidade Usada Custo Unitrio (R$) Custo Total (R$) R$ -R$ -R$ Custo Total(R$) R$ Data Final

Custo Total de Recursos Consumveis Recursos Humanos Horas Trabalhadas Custo/Hora (R$)

Recursos Compartilhados

Descrio

Data Inicial

12
12.1 12.2 12.3

Plano de Gerncia de Documentos do Projeto (RELATRIO WEBAPSEE)

Formas de Armazenamento Segurana e Confidencialidade Artefatos Gerenciados
Criao/ Responsvel Mtodo de Acesso

Artefato

13

Plano de Comunicao (INSERIDO PELA PROPOSTA)

Quando comunicado Emissor Receptor Forma de comunicao

Artefato

14
14.1

Plano de Riscos (INSERIDO PELA PROPOSTA)

Probabilidade, Impacto e Prioridades de Riscos
Referncia Grande chance de ocorrer Provavelmente ocorrer Igual chance de ocorrer ou no Baixa chance de ocorrer Pouca chance de ocorrer valor 0.8 0.9 0.5 0.7 0.3 0.4 0.1 0.2 <= 0.09

Critrios de Probabilidade:

99 Critrios para impacto: Objetivos do Projeto Custo Impacto Baixo Aumento de custo < 10% Mdio Aumento de custo de 10% a 20% Aumento de tempo de 5% a 10 % reas importantes do escopo afetadas Reduo da qualidade exige a aprovao do patrocinador Alto Aumento de custo de 20% a 40% Aumento de tempo de 10% a 20 % Reduo do escopo inaceitvel para o patrocinador Reduo da qualidade inaceitvel para o patrocinador Muito Alto Aumento de custo > 40%

Tempo

Aumento de tempo < 5%

Aumento de tempo > 20%

Escopo

reas menos importante do escopo afetadas Somente as aplicaes mais crticas so afetadas

Item final do projeto sem nenhuma utilidade

Qualidade

Item final do projeto sem nenhuma utilidade

Identificador

Risco

Probabilidade
Baixo (0.1 0.2), Mdio (0.3 0.4), Alto (0.5 0.7), Muito Alto (0.8 - 0.9)

Impacto
Baixo (0.1), Mdio (0.4),

Prioridade

(0 9) Alto (0.6), Muito Alto (0.8-1.0)

R01 R02 R03 R04 R05 R06

Cronograma ultrapassado Custos Ultrapassados Cliente Insatisfeito Equipe de desenvolvimento indisponvel Projeto Cancelado Alto ndice de alterao de requisitos

100 R07 Falta de entendimento entre os membros da equipe de desenvolvimento Baixa produtividade Equipe tcnica insatisfeita Especificao de requisitos de baixa qualidade Produto final no corresponde as expectativas dos clientes Re-trabalho Alto grau de rotatividade de pessoal Aprovao inadequada de documentos por parte do cliente Decises tcnicas do projeto afetadas por decises polticas Falta de comprometimento do usurio / cliente Oramento insuficiente Mudana no planejada de Tecnologia

R08 R09 R10 R11 R12 R13 R14 R15 R16 R17 R18

14.2
Risco

Riscos Gerenciados
Plano de Mitigao
Fazer planejamento cuidadoso Fazer reunies semanais de acompanhamento Ter base de projetos anteriores para melhorar as estimativas Ter base de projetos anteriores para melhorar as estimativas Usar ferramentas de apoio a estimativas de custo e de prazo. Solicitar ao cliente a indicao de pessoas conhecedoras do domnio do problema Realizar levantamento de requisitos com usurios indicados pelos clientes Utilizar metodologia adequada de Engenharia de Requisitos Garantir que mltiplos colaboradores esto alocados em partes chave do projeto

Plano de Contingncia

Causa

Conseqncia

Cronograma ultrapassado

Redefinio dos prazos com o cliente

Falta de planejamento adequado

Perda de credibilidade com o cliente e com a equipe

Custos Ultrapassados

Redefinio dos custos do projeto com o cliente

Falta de planejamento adequado

Perda de credibilidade com o cliente

Cliente Insatisfeito

Reunir com o cliente para definir os passos a serem tomados

Falta de ateno aos requisitos do cliente

Perda de credibilidade com o cliente

Equipe de desenvolvimento indisponvel

Definir quais colaboradores tero que ser alocados

Baixa remunerao, falta de motivao, ambiente de trabalho inadequado, falta de controle na alocao de profissionais em

Projeto ter que ser replanejado

101
diversos projetos Acompanhar os riscos ao longo do projeto Convencer o cliente que mudanas nos requisitos afetam cronograma e custos Convencer o cliente que mudanas nos requisitos afetam cronograma e custos Utilizar metodologia adequada de Engenharia de Requisitos Falta de acompanhamento dos riscos do projeto

Projeto Cancelado

Cancelar projeto

Diversas

Alto ndice de alterao de requisitos

Realizar reviso de documentos formal com o cliente

Uso inadequado das tcnicas de engenharia de requisitos

Cliente insatisfeito e projeto em risco

Falta de entendimento entre os membros da equipe de desenvolvimento

Baixa produtividade

Reunies semanais de acompanhamento Incentivar troca de experincia entre os membros da equipe Promover palestras e reunies de integrao da equipe Melhorar interao entre os membros da equipe Promover palestras e reunies de integrao da equipe Realizar treinamentos em mtodos, tcnicas e plataforma de desenvolvimento sempre que necessrio Manter boas condies de trabalho Criar esquemas de premiao para motivar a equipe Utilizar metodologia adequada de Engenharia de Requisitos Ter uma equipe de garantia da qualidade Revisar documento de requisitos com equipe tcnica

Fazer reunies para resolver problemas de desentendimento Adicionar especialistas

Comunicao inadequada Falta de um processo de desenvolvimento definido

Produtos que no atendem as necessidades do cliente

Realizar treinamento se necessrio Alocar pessoal tcnico especializado

Baixa motivao, falta de treinamento

Atraso no projeto

Equipe tcnica insatisfeita

Fazer reunies para resolver problemas de insatisfao da equipe Realizar reviso formal do documento e acompanhar a soluo dos problemas Realizar treinamentos Reunir com o cliente para definir os passos a serem tomados Tentar alocar funcionalidades no essenciais para verses futuras Rever padres de documentao Rever necessidade de treinamento Oferecer boas condies de trabalho Estimular equipe para colaborar no projeto Realizar reunio de aprovao formal de

Baixo estmulo, poucas reunies

Atraso no projeto

Especificao de requisitos de baixa qualidade

Falta de definio de um processo adequado de desenvolvimento, falta de equipe de garantia da qualidade Comunicao inadequada, falha no uso de metodologia de levantamento de requisitos, falta de aprovao formal dos artefatos por parte do cliente

Cliente insatisfeito

Produto final no corresponde s expectativas dos clientes

Realizar levantamento de requisitos com usurios indicados pelos clientes Utilizar metodologia adequada de Engenharia de Requisitos

Cliente insatisfeito

Re-trabalho

Realizar revises peridicas no trabalho sendo feito Adotar padres de documentos Documentar o processo de desenvolvimento de forma a orientar melhor os desenvolvedores Manter equipe satisfeita Garantir que mltiplos colaboradores esto alocados em partes chave do projeto Garantir que as etapas somente avanam com o

Falta de documentao adequada para equipe de desenvolvimento

Atraso no projeto

Alto grau de rotatividade de pessoal

Falta de poltica adequada de recursos humanos

Atraso no projeto

Aprovao inadequada de

Falta de rigor no seguimento do

Produto no atende

102
documentos por parte do cliente comprometimento do cliente em documentos chave. documentos pelo cliente ou seu representante processo expectativas do cliente

Decises tcnicas do projeto afetadas por decises polticas

Documentar todos os produtos de trabalho ao longo do projeto

Expor ao cliente os problemas causados por decises polticas

Falta de padres de desenvolvimento de software (mtodos, tcnicas, ferramentas) bem definidos e aprovados

Insatisfao da equipe

15

Aceitao do Plano de Projeto

Assinatura

Aceitao do Cliente/Representante do Cliente Nome/Setor

Aceitao dos Membros da Equipe alocados no Projeto: Nome/Setor Assinatura