UMA PROPOSTA DE INTEGRAÇÃO DO APOIO SISTEMATIZADO AOS RESULTADOS ESPERADOS DO NÍVEL G DO MPS.BR

Transcrição

1 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Paulo Rudolph da Silva Nascimento Wallace Michel Pinto Lira UMA PROPOSTA DE INTEGRAÇÃO DO APOIO SISTEMATIZADO AOS RESULTADOS ESPERADOS DO NÍVEL G DO MPS.BR Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Ciência da Computação Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira Belém 2009

2 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Paulo Rudolph da Silva Nascimento Wallace Michel Pinto Lira UMA PROPOSTA DE INTEGRAÇÃO DO APOIO SISTEMATIZADO AOS RESULTADOS ESPERADOS DO NÍVEL G DO MPS.BR Data da defesa:16 de dezembro de 2009 Conceito: Excelente Banca Examinadora Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA Orientador Prof. MSc. Alfredo Braga Furtado Faculdade de Computação/UFPA Membro Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA Membro Belém 2009

3 Tudo o que temos que decidir é o que fazer com o tempo que nos é dado. Gandalf em o Senhor dos Anéis: A Sociedade do Anel

4 AGRADECIMENTOS Agradeço primeiramente à Deus, pelas graças alcançadas, vitórias conquistadas e pelo fato deste trabalho estar sendo concluído. Agradeço à minha mãe (Ana Luiza) que com muito esforço e sozinha nos criou com muitas dificuldades, porém, nunca desistiu de mim. Ao meu irmão (Paulo Raphael) que me fez homem pelos seus ensinamentos passados e, pela sua força e apoio tanto pessoal como financeiro. E minha mulher (Nathalia Saint-Clair) pela sua compreensão e apoio. Bem como aos meus amigos que sempre me apoiaram e que, graças a eles também, estou onde estou. E, por fim, porém não menos importante, agradeço ao Prof. Dr. Sandro Bezerra pela sua orientação, paciência e dedicação na concepção de nosso trabalho de conclusão de curso, pois poucos são aqueles que amam o que fazem. Paulo Rudolph da Silva Nascimento Primeiramente, agradeço aos meus pais, Wagner e Marta, os quais sempre deram todo o suporte de que precisei, muitas vezes mais. Agradeço também à minha família: meus irmãos, avó e tia. Vocês são o fundamento da minha vida. Aos meus amigos Maurício, Paulo Rudolph, Vítor e Yoshio, os quais foram companheiros indispensáveis na minha jornada pela graduação. Ao nosso orientador Prof. Dr. Sandro o qual sempre teve paciência e competência para nos suportar durante todo o desenvolvimento deste trabalho. Finalmente, aos companheiros do Projeto SPIDER, por ajudar a tornar este trabalho possível. Wallace Michel Pinto Lira

5 As pessoas esquecem quão rapidamente você fez um trabalho, mas elas sempre se lembram de quão bem você o fez. Howard Newton

6 RESUMO As mudanças que estão ocorrendo nos ambientes de negócios têm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da visão tradicional baseada em áreas funcionais em direção a redes de processos centrados no cliente. A utilização de ferramentas CASE neste cenário é uma forte tendência do mercado. Neste contexto, este trabalho visa propor soluções para a integração do apoio sistematizado aos processos de Gerência de Projetos e Gerência de Requisitos definidos no MPS.BR utilizando software livre. PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, MPS.BR, Nível de Maturidade G, Ferramentas de Software Livre.

7 ABSTRACT The changes taking place in business environments motivated companies to change their paradigm and processes, replacing the traditional view based on functional areas for customer-centered processes. The use of CASE tools in this scenario is a strong market trend. In this context, this work aims in proposing solutions to support the integration of systematic procedures for Project Management and Requirements Management defined in MPS.BR using free software. KEYWORDS: Process Improvement, Software Quality, MPS.BR, G Maturity Level, Free Software Tools.

8 SUMÁRIO 1 Introdução Contexto do Trabalho Justificativa Motivação Objetivos Metodologia Estrutura Uma Visão Geral do MPS.BR Histórico Definição e Composição do Modelo MPS.BR Guias do MPS.BR Níveis de Maturidade do MPS.BR Considerações Finais Nível G do MPS.BR: Uma Visão Geral Objetivos Gerência de Projetos no MPS.BR Resultados Esperados de Gerência de Projetos Gerência de Requisitos no MPS.BR Resultados Esperados de Gerência de Requisitos Considerações Finais Proposta de Integração dos Processos do Nível G Projeto SPIDER Mapeamento dos Resultados Esperados GPR 1 x MED GPR 5 x GCO GPR 6 x GQA GPR 9 x GCO

9 4.2.5 GPR 10 x GPP GPR 11 x GPP GPR 11 x GPP GPR 17 x GQA GPR 17 x GPP GRE 1 x GPR GRE 1 x GPR GRE 1 x GPR GRE 1 x GPR GRE 1 x GPR GRE 1 x GCO GRE 2 x GPR GRE 3 x GPR GRE 3 x GPR GRE 4 x GPR Relações Resultantes entre os Processos oriundas dos Mapeamentos entre Resultados Esperados Definição das Ferramentas Ferramentas de Software Livre para Apoio aos Processos do Nível F e G do MPS.BR Considerações Finais Metodologia Para Integração da Implementação dos Processos Categorias de Integração entre Ferramentas Case Integração de Apresentação Integração de Dados Integração de Controle Integração de Processo Proposta de Integração Ferramental GPR 1 x MED

10 5.2.2 GPR 5 x GCO GPR 6 x GQA GPR 9 x GCO GPR 10 x GPP GPR 11 x GPP GPR 11 x GPP GPR 17 x GQA GPR 17 x GPP GRE 1 x GPR GRE 1 x GPR GRE 1 x GPR GRE 1 x GPR GRE 1 x GPR GRE 1 x GCO GRE 2 x GPR GRE 3 x GPR GRE 3 x GPR GRE 4 x GPR Considerações Finais Conclusão Resumo do Trabalho Resultados Obtidos Trabalhos Futuros Lições Aprendidas Referências Bibliográficas... 72

11 LISTA DE FIGURAS Figura 2.1: Componentes do MPS-BR (SOFTEX, 2009a) Figura 2.2: Níveis de maturidade do MPS.BR (SOFTEX, 2009a) Figura 4.1: Visão Geral dos Relacionamentos entre Processos do Nível F do MPS.BR.. 37 Figura 5.1: Alocar Objetivos para o Projeto na Ferramenta MPLAN Figura 5.2: Escopo Disponibilizado pela Ferramenta OpenProj Figura 5.3: Cadastro de Projetos da Organização na ferramenta MPLAN Figura 5.4: Tarefa instanciada no OpenProj Figura 5.5: Task finalizada no dotproject: repositório de baselines Figura 5.6: Análise de Riscos Disponibilizada pela Ferramenta OpenProj Figura 5.7: Dados Relevantes do Projeto na Ferramenta OpenProj Figura 5.8: Recursos da Organização, na Ferramenta dotproject Figura 5.9: Recursos do Projeto, na Ferramenta OpenProj Figura 5.10: Análise de Viabilidade do Projeto no dotproject Figura 5.11: Verificar Alocação de Recursos na Ferramenta dotproject Figura 5.12: Ticket Criado na Ferramenta Trac Figura 5.13: Detalhes dos Requisitos no OSRM Figura 5.14: Aba na Ferramenta OpenProj para Exibir Dados dos Requisitos Aceitos Figura 5.15: Requisitos Aceitos do Projeto na Ferramenta OSRMT Figura 5.16: Confirmação de Viabilidade do Projeto na Ferramenta OpenProj Figura 5.17: Criação de um checklist na Ferramenta SPIDER-CL Figura 5.18: Obtenção do Comprometimento dos Envolvidos ao Plano do Projeto na Ferramenta OpenProj Figura 5.19: Aba na Ferramenta OpenProj para Direcionar para a Rastreabilidade Bidirecional Figura 5.20: Rastreabilidade Bidirecional de Requisitos e Produtos de Trabalho na Ferramenta OSRMT Figura 5.21: Quantidade dos Tipos de Integrações Definidas... 66

12 12 1 INTRODUÇÃO Neste capítulo será apresentado o contexto do trabalho, sua justificativa, motivação e objetivos. A metodologia utilizada para o atendimento aos objetivos traçados também é apresentada. 1.1 Contexto do Trabalho Modelos de qualidade de software vêm sendo utilizados de forma a conferir às organizações que os adotam vantagens competitivas no mercado que vão além da publicidade associada. Um modelo de qualidade implantado tem o objetivo de melhorar os processos organizacionais e atestar a capacidade da organização em gerenciar o desenvolvimento, aquisição e manutenção dos produtos e serviços. Neste contexto foi concebido o MPS.BR, o qual é um programa para Melhoria de Processo do Software Brasileiro com o objetivo de promover a Excelência do Software Brasileiro (SOFTEX, 2009a). O modelo constitui em alternativa economicamente viável para as médias, pequenas e microempresas brasileiras ao modelo de qualidade CMMI, acrônimo para Capability Maturity Model Integration (AHERN et al, 2001), e à certificação ISO (ISO/IEC, 2006) para qualidade de processo de software. O MPS.BR estabelece sete níveis de maturidade: do nível G, menos maduro, até o nível A, mais maduro. 1.2 Justificativa As empresas têm buscado alternativas financeiramente mais acessíveis para a implantação do MPS.BR. Foi neste sentido que surgiu o Projeto SPIDER (OLIVEIRA, 2001). A proposta do referido projeto é criar um suíte de aplicativos de software aderente ao MPS- BR para diminuir os custos de implementação deste modelo. O projeto foca, inicialmente, nos níveis de maturidade F e G. Este trabalho, inserido no contexto do projeto SPIDER, apresenta uma abordagem para a implementação do processo de Gerência de Projetos e Gerência de Requisitos do padrão, utilizando-se de ferramentas de software livre, customizadas e integradas para que sejam capazes de fornecer aderência integral aos resultados esperados do MPS.BR. O objetivo de utilizar soluções ferramentais integradas é obter redução no tempo e custo de implementação do referido padrão, facilitar o treinamento dos recursos humanos e minimizar a ocorrência de não-conformidades no processo.

13 Motivação A decisão de realizar este trabalho veio da afinidade que desenvolvemos, ao longo do curso, pela área de Engenharia de Software, especialmente na área de Modelos de Qualidade. O modelo MPS.BR ser uma adaptação nacional de grandes modelos de qualidade internacionais, voltado para a realidade brasileira, nos motivou a participar deste projeto. Outro incentivo é o grande mercado de trabalho disponível para quem está disposto a seguir a carreira de consultor, implementador e/ou avaliador deste modelo de qualidade de processo. Finalmente, a possibilidade de participar de um projeto inovador, com perspectivas de grande visibilidade nacional, que é o projeto SPIDER, promoveu a motivação para realizar este projeto. 1.4 Objetivos Este trabalho possui, como objetivo geral, propor soluções para a integração do apoio sistematizado de ferramentas de software livre para Gerência de Projetos e a Gerência de Requisitos definidos no MPS.Br. Para alcançar o objetivo geral, será necessário alcançar os objetivos específicos: Estudar os processos definidos nos níveis G e F do MPS.BR; Elencar as ferramentas de software livres para o apoio sistematizado aos processos, no escopo citado, do MPS.BR; Realizar o mapeamento dos resultados esperados dos processos citados do MPS.BR com as funcionalidades de cada ferramenta elencada, escolhendo a que se adapta melhor à proposta do trabalho oferecendo maior suporte ao modelo de qualidade; Analisar e especificar as dependências entre os Resultados Esperados dos processos estudados; Propor soluções no caso de dependências encontradas entre resultados esperados não sejam atendidas pelas ferramentas analisadas. 1.5 Metodologia O desenvolvimento deste trabalho teve início com uma pesquisa do tipo exploratória para levantar todo o referencial teórico sobre o assunto, em seguida uma pesquisa bibliográfica para reunir a base teórica sobre conceitos de qualidade, engenharia de software,

14 14 Gerência de Projetos e Gerência de requisitos e software livre, além de uma análise documental nos guias do modelo MPS.BR, entre elas (SOFTEX, 2009a) e (SOFTEX, 2009b) para o aprofundamento dos conhecimentos sobre o modelo e análise das oportunidades de sistematização dos processos do MPS.BR. O desenvolvimento do trabalho passou a adotar pesquisa de caráter explicativo, analisando e propondo formas de contemplar os resultados esperados dos processos nos níveis G e F do MPS.BR, bem como a integração entre estes, através da sistematização com as ferramentas escolhidas durante a etapa anterior. O Método Científico no qual a pesquisa foi realizada é o Hipotético-dedutivo. Esta classificação decorreu da parte da hipótese dos relacionamentos entres os Resultados Esperados com as funcionalidades das ferramentas elicitadas para apoiar a solução do problema: buscar alternativas eficientes para a implantação do modelo MPS.BR nas instituições. As técnicas aplicadas para atingir os objetivos específicos foram: brainstorms entre as equipes do projeto SPIDER para análise dos mapeamentos; reuniões periódicas para discussão das pesquisas realizadas sobre o assunto abordado; e o gerenciamento do conhecimento gerado através de compartilhamento, disposição e manutenção das pesquisas realizadas. 1.6 Estrutura Este trabalho apresenta seus capítulos organizados sequencialmente da seguinte forma: Capítulo 2 apresentará uma visão geral do modelo MPS.BR, descrevendo um breve histórico, sua composição estrutural, bem como os níveis de maturidade que o constituem. O Capítulo 3, foca, em uma visão geral do nível G deste modelo de qualidade, definindo seu objetivo, além de uma descrição dos processos (Gerência de Projetos e Gerência de Requisitos) e seus respectivos Resultados Esperados. Já o Capítulo 4 apresenta uma proposta de integração dos processos deste nível, contextualizada no projeto SPIDER, isto é, o mapeamento dos Resultados Esperados do nível F no qual os processos de Gerência de Projetos e Gerência de Requisitos fornecem meios para o atendimento a outros resultados esperados. Ainda neste capítulo, são introduzidas as ferramentas de software livre para o apoio ao processo dos níveis G e F.

15 15 Posteriormente, a metodologia para integração da implementação dos processos é proposta, no Capítulo 5, levando em consideração as categorias de integração entre ferramentas CASE, também apresentadas neste capítulo. No Capítulo 6 será realizada a conclusão do trabalho proposto, resumindo-o e destacando os resultados obtidos, lições aprendidas e os trabalhos futuros relacionados.

16 16 2 UMA VISÃO GERAL DO MPS.BR O MPS.BR é o acrônimo para Melhoria de Processo do Software Brasileiro, um programa coordenado pela Associação para Promoção da Excelência do Software Brasileiro. Sua principal meta é definir e aprimorar um modelo de melhoria e avaliação de processo de software, visando preferencialmente as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software (SOFTEX, 2009a). Para atender à sua principal meta, o MPS-BR estrutura-se em um modelo de processos do software, um modelo de avaliação de processos e um modelo de negócio, descritos respectivamente pelos componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Os modelos propostos estão baseados nas normas: NBR ISO/IEC Processo de Ciclo de Vida de Software (SOFTEX, 2009a); ISO/IEC 12207, emendas 1 e 2 da norma internacional (SOFTEX, 2009a); ISO/IEC Avaliação de Processo (SOFTEX, 2009a); MMI-DEV modelo de capacidade (SOFTEX, 2009a). Este modelo de qualidade, portanto, não se propõe a implementar novas diretrizes para a Engenharia de Software (PRESSMAN, 2006). Sua proposta é implementar paradigmas de avaliação diferentes, adaptados à realidade nacional. Mais detalhes sobre a composição do modelo estão descritos na seção Histórico Para que se tenha um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando à oferta de produtos de software e serviços correlatos conforme padrões internacionais de qualidade. Em modelos como CMMI-DEV (SEI, 2006), o custo de implementação e avaliação é muito alto, mesmo em seus níveis mais baixos, como 2 e 3, o que faz com que seja inviável esta avaliação para micro e pequenas empresas, especialmente as brasileiras, as quais

17 17 geralmente não dispõem de recursos suficientes para este finalidade. Certificações ISO/IEC (ISO/IEC, 2003) encontram a mesma barreira no mercado nacional. Neste contexto, foi idealizado o modelo MPS.BR, o qual é um programa mobilizador, de longo prazo, coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), que conta com apoio do Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID). O MPS.BR objetiva ser adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também se espera que o modelo MPS seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis (SOFTEX, 2009a). Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de Engenharia de Software de forma adequada ao contexto das empresas. O modelo de qualidade tem o intuito de ser aderente às principais abordagens internacionais para definição, avaliação e melhoria de processos de software. 2.2 Definição e Composição do Modelo MPS.BR O modelo MPS.BR se baseia nas normas Norma Internacional ISO/IEC 12207:2008 (ISO/IEC, 2008), a Norma Internacional ISO/IEC (ISO/IEC, 2003) e o modelo CMMI- DEV (Capability Maturity Model Integration for Development) (SEI, 2006). A Figura 2.1 ilustra os componentes do programa MPS.BR e os documentos relacionados.

18 18 Figura 2.1 : Componentes do MPS-BR (SOFTEX, 2009a) O Modelo de Referência MR-MPS contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MR-MPS. O MR-MPS está em conformidade com os requisitos de modelos de referência de processo da Norma Internacional ISO/IEC (ISO/IEC, 2003) e é descrito pelos seguintes documentos: Guia Geral, Guia de Aquisição e os sete Guias de Implementação do MPS.BR. O Modelo de Avaliação MA-MPS descreve os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). O processo e o método de avaliação MA-MPS estão em conformidade com a Norma Internacional ISO/IEC (ISO/IEC, 2003). O Modelo de Negócio MN-MPS descreve regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras (II), avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de empresas pelas Instituições Organizadoras de Grupos de Empresas (IOGE) para implementação do MR-MPS e avaliação MA-MPS, certificação de Consultores de Aquisição (CA) e programas anuais de treinamento do MPS.BR por meio de cursos, provas e workshops. A coordenação do MPS-BR se baseia em duas estruturas principais, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). Estas duas estruturas são as bases para a participação de diversas instituições como universidades, centros de pesquisa, organizações privadas, etc. A participação destes grupos permite o

19 19 aumento da qualidade do modelo, através das experiências e discussões dos participantes (SOFTEX, 2009). O FCC tem como principal objetivo controlar o credenciamento das II e IA. Este controle é feito para assegurar a atuação dentro dos limites éticos e de qualidade. O ETM, por sua vez, atua sobre os aspectos técnicos do MR-MPS e do MA-MPS, responsabilizando-se pela evolução do modelo, elaboração e evolução dos guias, preparação de material, elaboração dos treinamentos, publicação de relatórios, entre outras. 2.3 Guias do MPS.BR Os documentos de apoio, cuja responsabilidade de criação e manutenção é da ETM, que compõem a base técnica do MPS.BR são: Guia Geral: descreve de forma detalhada o Modelo de Referência MR-MPS e fornece uma visão geral sobre os demais guias que apóiam a implementação dos diversos níveis do MR-MPS e os processos de avaliação e de aquisição (SOFTEX, 2009a); Guia de Avaliação: descreve o processo e o método de avaliação MA-PS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA) (SOFTEX, 2009a); Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS (SOFTEX, 2009a); Guia de Implementação:2009 Parte 1 descreve as exigências para a implementação da Gerência de Requisitos e Gerência de Projetos (SOFTEX, 2009a); Guia de Implementação:2009 Parte 2 - descreve as exigências para a implementação de dispositivos de Medição, Garantia da Qualidade, Gerência de Configuração, Aquisição de Software e Gerência de Portfólios de Projetos (SOFTEX, 2009a); Guia de Implementação:2009 Parte 3 - descreve as exigências para a implementação de Gerência de Reutilização, Gerência de Recursos Humanos,

20 20 Definição do Processo Organizacional e Avaliação e Melhoria do Processo Organizacional (SOFTEX, 2009a); Guia de Implementação:2009 Parte 4 - descreve as exigências para a implementação da Verificação, Validação, Projeto e Construção do Produto, Integração do Produto e Desenvolvimento de Requisitos (SOFTEX, 2009a); Guia de Implementação:2009 Parte 5 - descreve as exigências para a implementação da Gerência de Riscos, Desenvolvimento para Reutilização, Gerência de Decisões (SOFTEX, 2009a); Guia de Implementação:2009 Parte 6 - descreve as exigências para a implementação da Gerência de Projetos evoluída e controle estatístico de processos padrão (SOFTEX, 2009a); Guia de Implementação:2009 Parte 7 descreve novos RAP que visam a otimização dos processos por meio de alterações e adaptações incrementais e inovadoras para efetivamente atender aos objetivos de negócio atuais e projetados. (SOFTEX, 2009a). 2.4 Níveis de Maturidade do MPS.BR Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos (SOFTEX, 2009a). Existem sete níveis de maturidade no MPS.BR, cada um contém processos e atributos de processo, como mostra a Figura 2.2.

21 21 Figura 2.2: Níveis de maturidade do MPS.BR (SOFTEX, 2009a) Os sete níveis de maturidade são, portanto: nível G Parcialmente Gerenciado, composto pelos processos: Gerência de Projeto e Gerência de Requisitos; nível F Gerenciado, composto pelos processos do nível anterior e dos processos de Aquisição, Gerência de Configuração, Garantia da Qualidade, Gerência de Portfólio de Projetos e Medição; nível E Parcialmente Definido, composto pelos processos dos níveis anteriores acrescidos de Avaliação e Melhoria do Processo Organizacional, Definição do Processo Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização; nível D Largamente Definido, composto dos processos dos níveis anteriores acrescido dos processos Desenvolvimento de Requisitos, Integração do Produto, Validação, Verificação e Projeto e Construção do Produto; nível C Definido, composto dos processos dos níveis anteriores acrescido dos processos

22 22 Desenvolvimento para Reutilização, Gerência de Risco e Gerência de Reutilização; nível B Gerenciado Quantitativamente, composto pelos processos dos níveis anteriores, sendo que o processo Gerência de Projeto teve novos resultados a serem acrescentados; nível A Em Otimização, composto pelos processos dos níveis anteriores acrescido de Atributos de Processo (APs) que visam à otimização dos processos já estabelecidos. O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível. O propósito descreve o objetivo geral a ser atingido durante a execução do processo, enquanto os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo. A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e avaliação adequada às micros, pequenas e médias empresas pois o modelo de qualidade é implementado de forma gradual, diminuindo o custo de implantação de cada nível de maturidade. A possibilidade de se realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos. 2.5 Considerações Finais Este capítulo forneceu uma visão geral acerca do MPS.BR, descrevendo a base teórica do modelo de qualidade, suas metas e objetivos, bem como sua estrutura e composição. Ficou evidenciado o esforço para adequar o modelo de qualidade à realidade brasileira, com seus novos paradigmas para avaliação e sua divisão em níveis de maturidade de forma mais granular que em modelos de qualidade de processo existentes no mercado internacional. No próximo capítulo será descrito em mais detalhes o nível de maturidade G do MPS.BR, o qual é o foco deste trabalho. Serão apresentados os seus objetivos, sua finalidade, os resultados esperados e atributos de processo dos processos de Gerência de Projetos e Gerência de Requisitos, os quais compõem o escopo do nível G.

23 23 3 NÍVEL G DO MPS.BR: UMA VISÃO GERAL O nível G é o primeiro nível de maturidade do MR-MPS. Ao final da implantação deste nível a organização deve ser capaz de gerenciar parcialmente seus projetos de desenvolvimento de software, do ponto de vista do MPS.BR. A organização é considerada como capaz de gerenciar totalmente os seus projetos ao atingir o nível de maturidade F. Dois pontos são desafiadores na implantação do nível G (SOFTEX, 2009a): mudança de cultura organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software; definição do conceito acerca do que é projeto para a organização. No nível G, o projeto pode usar os seus próprios padrões e procedimentos, não sendo necessário que se tenha padrões em nível organizacional. Mais detalhes sobre o Nível de Maturidade G do MPS.BR estão contidos nas subseções deste capítulo. Serão explanados os seus objetivos na seção 3.1, o processo de Gerência de Projetos e Gerência de Requisitos nas seções 3.2 e 3.3 respectivamente, e, finalmente, as Considerações Finais na seção Objetivos O Nível G, também conhecido como Parcialmente Gerenciado, é o primeiro Nível de Maturidade do MPS-BR e constitui o início das atividades referentes à melhoria dos processos de software de uma organização. Abrange as Áreas de Processo Gerência de Projetos e Gerência de Requisitos. É um desafio manter projetos dentro das estimativas de tempo de orçamento, como se pode observar na citação: Visitei dezenas de instalações comerciais, tanto boas como ruins, e observei um grande número de gerentes de processamento de dados, tanto bons quanto ruins. Freqüentemente, observei como esses gerentes lutavam inutilmente com projetos que constituíam um verdadeiro pesadelo, espremidos por prazos de entrega inexeqüíveis, ou entregavam sistemas que irritavam seus usuários e prosseguiam devorando enormes parcelas de tempo de manutenção (PAGE-JONES, 1985 apud PRESSMAN, 2006). A resposta da

24 24 Engenharia de Software a estes problemas é a implantação de um processo de Gerência de Projetos. A finalidade desta área de processo, bem como a visão do MPS.BR sobre esta, estão na seção 3.2. Com relação à Gerência de Requisitos, são conhecidos os números do impacto de mudanças sobre os custos do projeto, comparando as principais fases do desenvolvimento de sistemas (PRESSMAN, 2006): definição: impacto de 1x; desenvolvimento: impacto de 1,5 6x; manutenção: x. Observa-se, portanto, que quanto mais tarde se detectarem erros ou necessidades de mudanças, maior será o impacto sobre os custos do projeto. Dos totais de erros que ocorrem em projetos, normalmente 40% deles têm sua origem na fase de especificação, 30%, na fase de projeto, e 30%, na fase de codificação (CASTRO, 1995). Além disso, um erro que ocorre na fase de especificação custa muito mais do que um que ocorre na de codificação. A adição de Gerência de Requisitos Nível G do MPS.BR é, portanto, justificada. Mais detalhes sobre a área de processo Gerência de Requisitos estão na seção Gerência de Projetos no MPS.BR O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto (SOFTEX, 2009a). É importante salientar que ocorrem evoluções neste processo, isto é, este evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados. No nível B, a gerência de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da organização, com a conseqüente adição e evolução de Resultados Esperados.

25 25 O processo Gerência de Projetos envolve várias atividades, como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mantê-lo ao longo de toda a execução do projeto; e conhecer o progresso do projeto, de maneira que ações corretivas possam ser tomadas quando a execução do projeto desviar do planejado (SOFTEX, 2009b). O desenvolvimento do plano do projeto inclui: identificar e estimar o escopo, os produtos de trabalho e as tarefas do projeto; estabelecer recursos necessários; identificar e analisar riscos do projeto; estabelecer compromissos; e definir cronograma de execução baseado no ciclo de vida definido para o projeto. O plano do projeto estabelece a base de execução e controle para as atividades do projeto junto aos seus interessados (stakeholders, incluindo os clientes). As atividades citadas são referenciadas por Resultados Esperados da área de Gerência de Projetos, conforme a seção O progresso da execução do projeto é determinado pela comparação dos atributos reais de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado nos marcos ou em pontos de controle predefinidos no planejamento do projeto. Um marco é um ponto de revisão, por exemplo, o início ou o final de cada fase do projeto ou algumas atividades de fundamental importância para o seu sucesso. A revisão de início de fase de projeto tem por objetivo verificar se as condições para que uma fase seja iniciada estão atendidas. Pode ser que, mesmo que a fase anterior não esteja encerrada, seja possível iniciar a nova fase, nas condições atendidas e com prazos para o cumprimento de algumas outras condições. A revisão de fim de fase de projeto tem por objetivo verificar se todos os critérios de encerramento de fase foram cumpridos. As revisões em marcos podem ter um caráter formal, com participação de gerências superiores, representantes do cliente e outras partes interessadas no projeto. Pontos de controle representam pontos entre um marco e outro nos quais revisões são realizadas para avaliar o andamento do projeto, porém, não estão no caminho crítico do projeto, ou seja, o projeto pode prosseguir mesmo que a revisão de um ponto de controle não tenha sido concluída. A visibilidade apropriada possibilita a tomada de ações corretivas quando o status do projeto se desvia significativamente do esperado. Tais ações podem exigir o replanejamento, para incluir a revisão do plano original, o estabelecimento de novos acordos ou atividades adicionais de mitigação de riscos no plano.

26 Resultados Esperados de Gerência de Projetos Os Resultados Esperados são siglas formadas de um acrônimo do nome do processo. Os Resultados Esperados de Gerência de Projetos são denotados, portanto, por GPR N, onde GPR é corresponde à área de processo e o N corresponde ao número do resultado esperado. O processo de Gerência de Projetos do Nível G do MPS.BR consiste nos Resultados Esperados GPR 1 a GPR 17. Estes Resultados Esperados, ao serem satisfeitos segundo os critérios de avaliação (SOFTEX, 2009a), cumprem a finalidade do processo de Gerência de Projeto do modelo de qualidade citado. Para um melhor entendimento dos resultados esperados nesta seção, consultar o Guia de Implementação, Parte 1 (SOFTEX, 2009b), a seção referente à Gerência de Projetos. Os resultados esperados de GPR são: GPR 1. O escopo do trabalho para o projeto é definido; GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados; GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos; GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas; GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos; GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados; GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo; GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados; GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessálos, incluindo, se pertinente, questões de privacidade e segurança;

27 27 GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos; GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados; GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido; GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados; GPR 14. O envolvimento das partes interessadas no projeto é gerenciado; GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento; GPR 16. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas; GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão. 3.3 Gerência de Requisitos no MPS.BR O propósito do processo Gerência de Requisitos (GRE) é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2009a). O principal objetivo da Gerência de Requisitos é controlar a evolução dos requisitos. O processo Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, bem como os requisitos impostos ao projeto pela organização. Para assegurar que o conjunto de requisitos acordados é gerenciado e fornece apoio às necessidades de planejamento e execução do projeto, a organização deve executar um conjunto de passos definidos e apropriados. Quando um projeto recebe requisitos de um fornecedor de requisitos pessoa autorizada a participar de

28 28 sua definição e a solicitar modificação, estes devem ser revisados para resolver questões e prevenir o mau entendimento, antes que os requisitos sejam incorporados ao escopo do projeto. Quando o fornecedor de requisitos e a organização chegam a um acordo, é obtido um compromisso das demais partes interessadas sobre os requisitos. Outras atribuições do processo Gerência de Requisitos são documentar as mudanças nos requisitos e suas justificativas, bem como manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho em geral e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto Resultados Esperados de Gerência de Requisitos Semelhantemente aos resultados de Gerência de Projetos, os resultados esperados de Gerência de Requisitos consistem em um acrônimo denotado por GRE N, sendo GRE a sigla para Gerência de Requisitos e N o número do Resultado Esperado. O processo de Gerência de Requisitos do Nível G do MPS.BR consiste nos Resultados Esperados GRE 1 a GRE 5. Estes resultados esperados, ao serem satisfeitos segundo os critérios de avaliação do MPS.BR (SOFTEX, 2009a), cumprem a finalidade do processo de Gerência de Requisitos do MPS.BR Para um melhor entendimento dos resultados esperados nesta seção, consultar o Guia de Implementação, Parte 1 (SOFTEX, 2009b), a seção referente à Gerência de Requisitos. Os resultados esperados de GRE são: GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

29 Nível F do MPS.BR O nível de maturidade F é composto pelos processos do nível de maturidade G acrescidos dos processos Aquisição, Garantia da Qualidade, Gerência de Configuração, Gerência de Portfólio de Projetos e Medição. Neste nível a implementação dos processos deve satisfazer os atributos de processo AP 1.1, AP 2.1 e AP 2.2. Será apresentado o propósito dos processos acrescidos, acompanhado de seus Resultados Esperados Aquisição O propósito do processo Aquisição é gerenciar a aquisição de produtos que satisfaçam às necessidades expressas pelo adquirente (SOFTEX, 2009a). A implementação deste processo não é obrigatória, desde que a organização não realize a terceirização do desenvolvimento. Neste contexto, o processo de aquisição não está no escopo deste trabalho por não ser um processo crítico em todas as organizações. A sequir, estão listados os Resultados Esperados do Processo de Aquisição: AQU 1. As necessidades de aquisição, as metas, os critérios de aceitação do produto, os tipos e a estratégia de aquisição são definidos; AQU 2. Os critérios de seleção do fornecedor são estabelecidos e usados para avaliar os potenciais fornecedores; AQU 3. O fornecedor é selecionado com base na avaliação das propostas e dos critérios estabelecidos; AQU 4. Um acordo formal que expresse claramente as expectativas, responsabilidades e obrigações de ambas as partes (cliente e fornecedor) é estabelecido e negociado entre elas; AQU 5. Um produto que satisfaça a necessidade expressa pelo cliente é adquirido baseado na análise dos potenciais candidatos; AQU 6. Os processos do fornecedor que são críticos para o sucesso do projeto são identificados e monitorados, gerando ações corretivas, quando necessário;

30 30 AQU 7. A aquisição é monitorada de forma que as condições especificadas sejam atendidas, tais como custo, cronograma e qualidade, gerando ações corretivas quando necessário; AQU 8. O produto é entregue e avaliado em relação ao acordado e os resultados são documentados; AQU 9. O produto adquirido é incorporado ao projeto, caso pertinente Garantia da Qualidade O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos (SOFTEX, 2009a). As atividades de Garantia da Qualidade permitem fornecer visibilidade do projeto para todos da organização por meio de uma visão independente em relação ao processo e ao produto. A sequir, estão listados os Resultados Esperados do Processo de Garantia da Qualidade: GQA 1. A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues e em marcos predefinidos ao longo do ciclo de vida do projeto; GQA 2. A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente; GQA 3. Os problemas e as não-conformidades são identificados, registrados e comunicados; GQA 4. Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalonamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução Gerência de Configuração O propósito do processo Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os

31 31 envolvidos (SOFTEX, 2009a). Durante o desenvolvimento, o sistema de Gerência de Configuração é fundamental para prover controle sobre os produtos de trabalho produzidos e modificados por diferentes engenheiros de software. A sequir, estão listados os Resultados Esperados do Processo de Gerência de Configuração: GCO 1. Um Sistema de Gerência de Configuração é estabelecido e mantido; GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos; GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline; GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada; GCO 5. Modificações em itens de configuração são controladas; GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados; GCO 7. Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes Gerência de Portfólio de Projetos O propósito do processo Gerência de Portfólio de Projetos é iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização (SOFTEX, 2009a). No contexto do MPS.BR, Portfólio é uma coleção de todo o trabalho em andamento na organização relacionado com o alcance dos objetivos do negócio.

32 32 O processo Gerência de Portfólio de Projetos é obrigatório, exceto quando a única atividade da unidade organizacional for evolução de produto. Neste caso, poderá ser considerado fora do escopo da avaliação. Seus resultados esperados são: GPP 1. As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados; GPP 2. Os recursos e orçamentos para cada projeto são identificados e alocados; GPP 3. A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas; GPP 4. Os conflitos sobre recursos entre projetos são tratados e resolvidos; GPP 5. Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados Medição O propósito do processo Medição é coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais (SOFTEX, 2009a). A medição tem como principal foco apoiar a tomada de decisão em relação aos projetos, processos e atendimento aos objetivos organizacionais. A sequir, estão listados os Resultados Esperados do Processo de Medição: MED 1. Objetivos de medição são estabelecidos e mantidos a partir dos objetivos de negócio da organização e das necessidades de informação de processos técnicos e gerenciais; MED 2. Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado; MED 3. Os procedimentos para a coleta e o armazenamento de medidas são especificados;

33 MED 4. Os procedimentos para a análise das medidas são especificados; 33 MED 5. Os dados requeridos são coletados e analisados; MED 6. Os dados e os resultados das análises são armazenados; MED 7. Os dados e os resultados das análises são comunicados aos interessados e são utilizados para apoiar decisões. 3.4 Considerações Finais Este capítulo destinou-se à apresentação de uma visão geral acerca do Nível de Maturidade G do modelo MPS.BR e seus processos, Gerência de Projetos e Gerência de Requisitos, os quais consistem no início das atividades referentes à melhoria dos processos de software de uma organização. Houve a descrição e detalhamento de seu objetivo, bem como as finalidades de cada processo e dos Resultados Esperados que os componham. O capítulo subsequente tratará da proposta de Integração dos Processos do Nível G. Será apresentado o Projeto SPIDER, projeto do qual este trabalho faz parte, apresentando os seus objetivos e metas. Serão apresentados os mapeamentos entre os Resultados Esperados de diferentes áreas de processo contidas nos níveis G e F do MPS.BR. Serão também definidas as ferramentas utilizadas no contexto do Projeto para implementação das áreas de processo do MPS.BR. Finalmente, será apresentado o Mapeamento de Integração entre as ferramentas selecionadas.

34 34 4 PROPOSTA DE INTEGRAÇÃO DOS PROCESSOS DO NÍVEL G Neste capítulo será apresentado o projeto SPIDER, no qual este trabalho de conclusão de curso está inserido. O propósito é definir os relacionamentos entre os elementos dos processos de Gerência de Projetos e Gerência de Requisitos e apresentar as ferramentas já existentes no mercado, escolhidas para o mapeamento da integração. A metodologia para implementação integrada dos processos do MPS.BR, incluindo protótipo, será definida no capítulo posterior. 4.1 Projeto SPIDER Atualmente, existe um movimento crescente onde esforços individuais e coletivos, impulsionados pela massificação da Internet, derivam a criação de softwares não proprietários com o objetivo de atender às necessidades comuns das organizações e de indivíduos. Estes softwares, denominados software livre, são qualquer programa de computador que pode ser usado, copiado, estudado e redistribuído com algumas restrições. Estas liberdades são centrais ao conceito de software livre (Free Software Foundation, 2009). A iniciativa brasileira com mais destaque neste campo atualmente é o Governo Federal, com a implantação de políticas para incentivar o uso de software livre no mercado nacional (CISL, 2009). Pretende-se, no Projeto SPIDER, definir um SUITE de ferramentas com a intenção de fazer uso integrado das funções/operações disponibilizadas pelas ferramentas, realizando a implantação das áreas de processo do modelo MPS.BR, em aderência ao fluxo de dependência proposto por este modelo de qualidade de processo (OLIVEIRA, 2007). O Projeto SPIDER promove a criação de produtos de trabalhos (artefatos que evidenciam a implementação do programa da qualidade organizacional) derivados dos resultados esperados descritos nos objetivos das áreas de processo (Gerência de Projetos, Gerência de Requisitos, Gerência de Configuração, Medição, Garantia da Qualidade, Aquisição e Gerência de Portfólio de Projetos) inicialmente, dos níveis de maturidade G (parcialmente gerenciado) e F (gerenciado) do modelo MPS.BR (OLIVEIRA, 2007). Este projeto visa apresentar alternativas viáveis com relação a ferramentas de software livre para auxiliar a implementação do modelo MPS.BR nas organizações, sem a necessidade de aquisição de softwares proprietários e com a possibilidade da ferramenta ser customizada

35 35 para atender às especificidades da organização, diminuindo os custos e o tempo ao longo da implementação deste programa de maturidade. As ferramentas de software livre utilizadas passam a constituir o SUITE de aplicações do projeto. Estas ferramentas são integradas visando sistematizar o processo respeitando as dependências entre elementos do modelo de qualidade. Este Trabalho de Conclusão de Curso tem como objetivo atender a meta do Projeto SPIDER de integrar as ferramentas que atendem às áreas de processo definidas no nível G do MPS.BR. 4.2 Mapeamento dos Resultados Esperados Os Resultados Esperados do modelo MPS.BR possuem relacionamentos de dependência entre si, uma característica que, apesar de ser intrínseca ao modelo, não é explicitada em sua documentação. Há os relacionamentos intra-processo, isto é, entre Resultados Esperados do mesmo processo, os quais foram considerados implícitos e, também, relacionamentos inter-processo, ou seja, entre Resultados Esperados de processos distintos do modelo de qualidade, relacionamentos nos quais, baseados em análises e discussões, foram propostos pela equipe de integração do Projeto SPIDER. O escopo das relações aqui descritas envolve os Resultados Esperados, oriundos dos processos do nível G do MPS.BR, os quais fornecem base para a implementação de Resultados Esperados dos níveis G e F do modelo. O objetivo é analisar como os processos definidos no Nível G do MPS.BR impacta sobre outros processos dos níveis G e F deste modelo. O impacto dos processos definidos no nível F do MPS.BR é avaliado em outro subprojeto do Projeto SPIDER, assunto do trabalho de conclusão de curso Uma Proposta de Integração do Apoio Sistematizado aos Resultados Esperados do Nível F do MPS.BR (MENDES & ÁVILA, 2009). A estratégia adotada para formalizar os relacionamentos (dependências) entre os Resultados Esperados foi através da criação das seguintes definições: Resultado Esperado Base; Resultado Esperado Dependente; Descrição do Mapeamento e Implementação Conjunta. Um conjunto o qual contenha estes elementos caracteriza uma dependência entre Resultados Esperados.

36 36 Resultado Esperado Dependente foi definido como aquele o qual o seu atendimento depende de eventos ou informações oriundos do atendimento do Resultado Esperado Base correspondente. Por conseguinte, a Descrição do Mapeamento é necessária para justificar a associação, bem como fornecer um exemplo de implementação da relação entre Resultados Esperados por meio da Implementação Conjunta para explicitar e melhor esclarecer a dependência. O título das subseções a seguir é denotado com a seguinte sintaxe: Resultado Esperado Base x Resultado Esperado Dependente. A Descrição do Mapeamento e a Implementação Conjunta constam no corpo da subseção. Na Descrição do Mapeamento, ao ser comentado o ponto relevante do Resultado Esperado para o mapeamento, um parêntese é observado contendo a sigla do Resultado Esperado ao qual o elemento citado pertence. Por exemplo, o elemento Objetivos de Medição presente na subseção está contemplado pelo resultado esperado MED1 do processo de Medição GPR 1 x MED 1 Os Objetivos de Medição (MED1) precisam previamente que os objetivos do projeto estejam definidos no seu escopo de projeto (GPR1). Implementação Conjunta: Ao definir o escopo do projeto, os objetivos do mesmo são definidos. Estes Objetivos serão utilizados como base para a definição dos Objetivos de Medição GPR 5 x GCO 3 As baselines são geradas (GCO3) em marcos do projeto e/ou conforme definido no Cronograma (GPR5). Implementação Conjunta: Para cada marco e/ou ponto de controle do projeto, uma baseline deve estar atrelada, conforme definido na metodologia da empresa. Além disso, baselines periódicas podem ser criadas, conforme estabelecido no cronograma GPR 6 x GQA 4 Para efetivar as alterações definidas nas ações corretivas (GQA4) deve-se, previamente, analisar os riscos e seus impactos associados no projeto (GPR6).

37 37 Implementação Conjunta: A tomada de decisão para correção de uma nãoconformidade deve ser realizada, caso seja viável, após análise dos riscos dessa alteração e seus impactos no projeto, verificando suas dependências GPR 9 x GCO 2 A Gerência de Configuração necessita da identificação dos dados relevantes do projeto (GPR9) para a identificação dos itens de configuração (GCO2). Implementação Conjunta: A identificação dos dados relevantes do projeto (artefatos) fornece insumos para a identificação dos itens de configuração GPR 10 x GPP 2 Para cada um dos projetos que tenham sido selecionados e priorizados devem ser provisionados e disponibilizados os recursos e o orçamento necessários (GPP2), incluídos no Plano do Projeto (GPR10). Implementação Conjunta: Determinado recurso humano pode estar alocado a mais de um projeto. É importante analisar se a carga total alocada é compatível com a carga horária disponível do profissional GPR 11 x GPP 1 A transformação de um projeto em execução em um portfólio depende da análise de viabilidade de negócio (GPR11) para atender uma oportunidade de mercado (GPP1). Implementação Conjunta: Quando a Gerência de Portfólio pretende transformar um projeto em execução em um Portfólio, ela deve usar os dados da análise de viabilidade do projeto para a decisão de criação do portfólio GPR 11 x GPP 5 Projetos que atendem aos acordos e requisitos que levaram à sua aprovação (GPP5) dependem da análise da viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis (GPR11). Implementação Conjunta: A análise de viabilidade é executada para que seja decidido quais projetos devem ser redirecionados ou cancelados.

38 GPR 17 x GQA 4 Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados (GPR17) devem estar em sintonia com as ações corretivas para não conformidades estabelecidas na Gerência de Qualidade (GQA4). Implementação Conjunta: As não conformidades devem possuir ações corretivas, que serão gerenciadas até serem concluídas GPR 17 x GPP 4 Uma vez identificado um conflito de recurso entre projetos (GPP4), a gerência de projeto se encarrega de identificar, propor solução e acompanhar a resolução do conflito até a sua conclusão (GPR17). Implementação Conjunta: Um conflito identificado pela Gerência de Portfólio, por exemplo, um programador alocado mais de 100% do seu tempo pra vários projetos, é encaminhado para a Gerência de Projeto para que o conflito seja solucionado GRE 1 x GPR 1 A definição dos requisitos entendidos, avaliados e aceitos (GRE1) impactam diretamente no escopo, caso a modificação não seja aderente aos objetivos e restrições originais do sistema (GPR1). Implementação Conjunta: Uma alteração em um requisito aprovado deve ter sua aderência em relação ao escopo anterior analisada. Caso haja conflito, ações estabelecidas no Plano de Projeto devem indicar o procedimento a ser adotado GRE 1 x GPR 2 O dimensionamento de tarefas e produtos de trabalho utilizando métricas adequadas (GPR2) pode ter como um dos parâmetros o número de requisitos avaliados e aceitos (GRE1). Implementação Conjunta: Os requisitos de software servem como parâmetro para análise de um método apropriado para o dimensionamento das tarefas como pontos por função.

39 GRE 1 x GPR 3 O modelo e o ciclo de vida do projeto (GPR3) devem levar em consideração o escopo dos requisitos (GRE1). Implementação Conjunta: Com a análise das peculiaridades do projeto, tendo em vista o escopo dos requisitos, deve ser realizada para escolher um modelo e fases de ciclo de vida adequadas GRE 1 x GPR 5 As atividades definidas no escopo dependem diretamente dos requisitos avaliados e aceitos (GRE1), impactando definição das tarefas no cronograma (GPR5). Implementação Conjunta: A definição dos requisitos avaliados e aceitos deve ser seguida de uma tarefa constante no Plano do Projeto. Esta nova tarefa deve constar no escopo e deve, por conseguinte, impactar sobre o custo do projeto GRE 1 x GPR 11 Os requisitos entendidos, avaliados e aceitos (GRE1) são um parâmetro necessário para avaliar a viabilidade de atingir as metas do projeto (GPR11). Implementação Conjunta: Em um marco ou ponto de controle onde seja avaliada a viabilidade de se atingir as metas do projeto, os requisitos de software são requeridos para uma análise acurada GRE 1 x GCO 7 As auditorias da gerência de configuração (GCO7) utilizam, entre outros critérios, os requisitos aprovados (GRE1). Implementação Conjunta: Durante as auditorias de configuração, a análise dos requisitos aprovados pode ter impacto significativo GRE 2 x GPR 12 O comprometimento dos envolvidos com plano de projeto (GPR12) necessita do comprometimento da equipe técnica com os requisitos (GRE2).

40 40 Implementação Conjunta: A partir do comprometimento da equipe técnica com os requisitos, o gerente do projeto pode marcar uma reunião para obter o comprometimento no plano de projeto GRE 3 x GPR 5 A rastreabilidade bidirecional (GRE3) permite que seja analisado o impacto de alterações proporcionadas pelos requisitos no cronograma (GPR5). Implementação Conjunta: O impacto no projeto de software de alterações nos requisitos é analisado tendo como base uma tabela de rastreabilidade GRE 3 x GPR 6 A identificação dos riscos (GPR6) é auxiliada pela análise das dependências identificadas na rastreabilidade bidirecional (GRE3). Implementação Conjunta: A análise dos riscos pode levar em conta as alterações em cadeia nos produtos de trabalho, vide a matriz de rastreabilidade, para um resultado mais preciso, pois nesta matriz consta as dependências entre requisitos e produtos de trabalho GRE 4 x GPR 10 Identificar e corrigir inconsistências nos planos e produtos de trabalho (GRE4) implica em alterações no Plano de Projeto (GPR10). Implementação Conjunta: A identificação e correção dos requisitos e produtos de trabalho, caso haja alguma inconsistência, implicará em alterações no plano de projeto como: mudanças de escopo, esforço, custo, cronograma e recursos. 4.3 Relações Resultantes entre os Processos oriundas dos Mapeamentos entre Resultados Esperados Os mapeamentos definidos na subseção 4.2 proporcionaram entendimento de como os processos dentro do escopo deste trabalho dependem entre si. A figura4.1 apresenta a quantidade de resultados esperados cada processo do nível F do MPS.BR possui, a quantidade de relacionamentos onde estes processos são base e, finalmente, a quantidade de relacionamentos onde estes processos são dependentes.

41 41 Estas relações ilustram a medida do quanto cada processo influencia e é influenciado por outros processos do MPS.BR. Esta constatação evidencia que os processos deste modelo de qualidade não podem ser executados isoladamente. O esforço conjunto dos processos é necessário para assegurar a aderência ao modelo de qualidade. Figura 4.1: Visão Geral dos Relacionamentos entre Processos do Nível F do MPS.BR 4.4 Definição das Ferramentas As ferramentas CASE, sigla para Computer-Aided Software Engineering, é uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de Software, desde análise de requisitos e modelagem até programação e testes. Este tipo de ferramenta apóia o desenvolvedor durante a realização de alguma atividade do processo de construção de software e proporcionam uma sólida estrutura às metodologias e métodos de desenvolvimento de software (OLIVEIRA, 2001). As ferramentas CASE analisadas e adotadas para serem utilizadas na pesquisa foram customizadas e metodologias de uso foram definidas para que estas ferramentas aderissem aos Resultados Esperados dos respectivos processos para os quais foram desenvolvidas. Estes

42 42 resultados de pesquisa, envolvendo áreas de processo específicas, não fazem parte do escopo deste trabalho. Elas estão disponíveis no site do projeto SPIDER, vide o link Ferramentas de Software Livre para Apoio aos Processos do Nível F e G do MPS.BR Existe no mercado um conjunto de alternativas de software livre para apoio aos processos definidos nos níveis G e F do MPS.BR. Não faz parte do escopo deste trabalho, no entanto, detalhar as funcionalidades destas ferramentas. Mais informações a respeito estão disponíveis em outros subprojetos inseridos no Projeto SPIDER, os quais tratam de áreas de processo específicas. No entanto, faz-se necessário apresentar a missão geral das ferramentas que melhor contemplam os processos do modelo e que por esse motivo foram adotadas para integrarem o escopo do Projeto SPIDER. Nas subseções a seguir são listadas as ferramentas elicitadas para integrar Projeto SPIDER, com uma breve descrição, apontando as principais características, fornecedores, versões, suas licenças e a área do MPS.BR à qual atendem. Todas as ferramentas apresentadas a seguir obedecem a requisitos de portabilidade, ou seja, funcionam em sistemas operacionais diversos, sobretudo os ambientes Linux e Windows OpenProj O OpenProj (disponível para download em é uma ferramenta de software livre difundida no mercado para Gerência de Projetos. Foi desenvolvida usando a linguagem Java e, no contexto do Projeto SPIDER, é responsável por gerar e possibilitar a leitura de Planos de Projeto. O seu ponto fraco é não ter recursos para operar em rede. No entanto, isto pode ser contornado gerenciando seus arquivos, ou saves, utilizando um de repositório de dados em conjunto com uma metodologia de acesso e modificação, conforme definido no subprojeto do Projeto SPIDER referente à área de Gerência de Projetos. Encontra-se na versão 1.4, desenvolvida pela empresa Projity Incorporated a qual foi comprada pela Serena Software, atual responsável pelo software. Sua licença de uso é Common Public Attribution License (CPAL, disponível em

43 Esta ferramenta dá apoio à área de Gerência de Projetos DotProject O DotProject (disponível para download em é uma ferramenta desenvolvida em PHP com a finalidade de gerenciar projetos através de uma interface web. É software livre, com código aberto, distribuído sob a licença GNU-GPL (GNU General Public License). Por se tratar de uma ferramenta para Gerência de Projetos, o DotProject é composto por funcionalidades para gerenciamento de tarefas, cronogramas, comunicação e compartilhamento. Sua versão mais atual é a Esta ferramenta CASE não possui uma companhia responsável pelo seu desenvolvimento, em seu lugar há a colaboração de um grupo voluntário e dos próprios usuários. No Projeto SPIDER, foi utilizada para dar suporte às áreas de processo Gerência de Projetos, Gerência de Requisitos e Gerência de Portfólios. Sobretudo para documentar o comprometimento, no caso dos dois primeiros OSRMT O Open Source Requirements Management Tool (OSRMT, disponível em é uma ferramenta de software livre desenvolvida em Java projetada para apoiar o processo de Gerência de Requisitos. As principais características desta ferramenta focam em permitir uma completa rastreabilidade do ciclo de vida de desenvolvimento de software em relação aos requisitos e em gerenciar os requisitos registrados. Entre as funcionalidades da ferramenta, pode-se destacar, segundo (CARDIAS JUNIOR et. al., 2009): (I) registro de autor, (II) origem e motivo da necessidade de cada requisito; (III) registro de casos de uso, (IV) status e origem de cada requisito; (V) rastreabilidade bidirecional; (VI) definição e organização de artefatos e entrada de dados; e geração de relatórios padronizados em formato PDF. Atualmente, encontra-se na versão 1.5. Está licenciada segundo os termos GNU/GPL. No projeto SPIDER, dá suporte à área de Gerência de Requisitos.

44 Trac O Trac (disponível em é uma ferramenta utilizada para auxiliar no processo de desenvolvimento de softwares com o objetivo é gerenciar bugs, sua estrutura é baseada em wiki e executada em browser. Este aplicativo open source é implementado em python e sua versão mais estável é , possuindo integração nativa com o subversion, mas capaz de se integrar com outros sistemas de controle de versão. Como diferencial, sua estrutura é baseada em wiki, o que torna possível a formatação utilizando recursos disponíveis neste tipo de aplicação. Outra funcionalidade presente na ferramenta é a capacidade de verificar o andamento de projetos. É executado através de browsers. É utilizada no Projeto SPIDER para suporte à Gerência de Configuração, sobretudo a subárea Gerência de Mudança. Atende também às áreas de Gerência de Projetos, Gerência de Requisitos, Garantia de Qualidade e Gerência de Portfólio. Possui uma licença BSD modificada, conforme Mantis O Mantis (disponível em é uma ferramenta de bugtracking, sob licença GNU/GPL, desenvolvido utilizando a linguagem PHP para auxiliar o controle de modificações através do gerenciamento das issues, elemento similar ao ticket do Trac, os quais são relatos de problemas identificados nos produtos de trabalho, que terão sua evolução acompanhada desde a solicitação da mudança até seu desfecho. A sua versão mais estável é a Semelhante ao Trac, o Mantis é executado através de browsers e atende às mesmas áreas de processo CVS O CVS (Control Version System, disponível em é um sistema de controle de versões, usado para se registrar o histórico de modificações de arquivos. Inicialmente criado por Dick Grune em 1986 como um conjunto de scripts para facilitar o uso do RCS, o CVS começou a ser reescrito na linguagem C em1989 por Brian Berliner. Hoje o CVS é um software livre, de uso gratuito e mantido pela Free Software Foundation, sob licença GNU General Public License v2.

45 45 A utilização do CVS é feita através de linha de comando, ou através de uma das várias opções de clientes gráficos (TortoiseCVS, por exemplo), e IDE s (Integrated Development Environment Ambiente de Desenvolvimento Integrado) que fornecem integração com a ferramenta (como o caso da IDE Eclipse) Subversion O Subversion, ou SVN, (disponível em é uma ferramenta de controle de versão, projeto da Tigris.org. Além do controle de versão do conteúdo dos arquivos, também permite controle de mudanças sobre diretórios, cópias, renomeações e meta-dados. O SVN não conta com interface gráfica, porém clientes gráficos de terceiros fornecem essa funcionalidade, a exemplo de clientes como o TortoiseSVN e RapidSVN, e conta com clientes e plugins para integração com alguns IDE s como o Subeclipse (plugins para eclipse), AnkhSVN e VisualSVN (ambos para Visual Studio). A ferramenta se encontra na versão e está disponível sob licença GNU GPL Spider-MPLAN Outro subprojeto do Projeto SPIDER prevê o estudo de alternativas de software livre aderentes ao MPS.BR. Este estudo revelou, no entanto, que não existem alternativas deste tipo de software para a implementação do processo de Medição em conformidade com o modelo de qualidade citado. O desenvolvimento de uma solução de uma ferramenta livre que apóie na implementação do este processo, fez-se, portanto, necessário. Sua implementação se propõe a trazer: (I) diminuição de custo, esforço e tempo, pois são não-proprietárias e não pagas (custos); (II) diminuição da ampla necessidade de documentação (esforço), (III) possibilidade de aumento na agilidade do processo (tempo). Neste contexto, foi desenvolvido o Spider-MPLAN, o qual é uma ferramenta, atualmente em desenvolvimento como parte do Projeto SPIDER, com o propósito de fornecer um arcabouço de funcionalidades para o apoio à área de medição da empresa aderente ao processo de Medição do MPS.BR. Será uma ferramenta web, multiusuário a qual será desenvolvida em Java. Até a data de publicação deste trabalho, os protótipos estavam em fase de avaliação pela equipe do

46 Projeto, necessitando de avanços na área de IHC. Quando concluída, terá licença de uso GNU/GPL Spider-QA A gestão de qualidade assegura que os produtos desenvolvidos estão em conformidade com o que foi definido. Essa gestão trabalha ainda com acompanhamento de possíveis não conformidades e com ações corretivas. Para que os gestores de qualidade sejam capazes de fazer a garantia da qualidade de maneira mais objetiva, o acompanhamento das não conformidades automatizado e as devidas anotações e sugestões pode ser utilizada uma ferramenta capaz de atender ao processo de Garantia da Qualidade de forma aderente ao MPS.BR. No contexto do subprojeto do Projeto SPIDER responsável por esta área de processo do MPS.BR, foram pesquisadas várias ferramentas de software livre e sua aderência aos resultados esperados no MPS-BR foram mapeadas. No entanto, dentre as alternativas pesquisadas não foram encontradas ferramentas destinadas para Garantia de Qualidade aderentes ao MPS.BR. Portanto, o subprojeto responsável por esta área possui em desenvolvimento o software Spider-QA, o qual é uma ferramenta a qual tem como proposta conferir apoio integral a esta área em conformidade com as exigências do MPS.BR. Até a data de publicação deste trabalho, a ferramenta está na fase de desenvolvimento. Será, portanto, uma ferramenta web, multiusuário a qual será desenvolvida utilizando a linguagem C#. Encontra-se na mesma fase de desenvolvimento que o Spider-MPLAN. Ao ser concluída, terá licença de uso GNU/GPL Spider-CL O Spider-CL (BARROS, 2009), disponível em é uma ferramenta desenvolvida no Projeto SPIDER da Universidade Federal do Pará, com propósito de criar checklists compostos por critérios objetivos para utilização em diversos contextos, provendo mecanismos para a aplicação destes checklists, mantendo histórico e registrando seus resultados.

47 47 A interface do Spider-CL foi desenvolvida utilizando componentes gráficos convencionais como caixas de textos, tabelas, listas e botões, conforme critérios de usabilidade. Ela foi desenvolvida no contexto do projeto SPIDER para dar suporte às operações de avaliação segundo critérios objetivos, as quais são elementos recorrentes nas áreas de processo do MPS.BR. O fato de não existirem ferramentas livres com este perfil impulsionou o desenvolvimento desta alternativa. De forma semelhante a outras ferramentas desenvolvidas no contexto do Projeto SPIDER, possui licença de uso GNU/GPL. 4.5 Considerações Finais Este capítulo destinou-se a apresentar os relacionamentos entre os processos definidos nos Níveis F e G do MPS.BR onde os Resultados Esperados do Nível G apóiam o atendimento aos Resultados esperados dos processos definidos no nível F. O Projeto SPIDER foi introduzido juntamente com as ferramentas de software livre que integram o escopo do mesmo, também foram apresentadas. Finalmente, as relações entre Resultados Esperados de áreas de processo distintas as quais tinham Resultados Esperados de GPR ou GRE foram apresentadas. O capítulo subsequente tratará da proposta da metodologia de Implementação Integrada dos Processos do Nível G, incluindo propostas de mudanças nas ferramentas apresentadas para aderirem aos mapeamentos expostos na subseção 4.2. Políticas de uso e a evolução da proposta das Ferramentas de Integração serão apresentadas.

48 48 5 METODOLOGIA PARA INTEGRAÇÃO DA IMPLEMENTAÇÃO DOS PROCESSOS A integração é necessária para obter produtividade no desenvolvimento e aumentar a qualidade dos produtos de software, mas os custos associados à construção de ambientes integrados devem ser levados em consideração. A integração pode aumentar a consistência dos dados e reduzir a redundância através do compartilhamento de informações (OLIVEIRA, 2001). No contexto do Projeto SPIDER, houve a classificação da integração entre as ferramentas CASE, acrônimo para Computer Aided Software Engineering, utilizando critérios estabelecidos em bibliografia adequada, conforme descrito a seguir. Neste capítulo há também a apresentação de uma proposta de integração dos mapeamentos com as ferramentas, ambos descritos no capítulo Categorias de Integração entre Ferramentas Case Houve a classificação dos mapeamentos entre as ferramentas CASE com o objetivo de fornecer uma abordagem similar para a integração de ferramentas as quais compartilhem a mesma categoria de integração. Segundo classificação proposta por (JORGENSEN, 1994 apud PRESSMAN, 2006), existem quatro categorias gerais de integração: (I) apresentação, (II) dados, (III) controle e (IV) processo. As categorias de integração descrevem como as ferramentas CASE cooperam entre si Integração de Apresentação Esta categoria impõe consistência nas interfaces das ferramentas. Cada ferramenta possui o mesmo conjunto de construtores na interface com o usuário, ou seja, os usuários interagem com todas as ferramentas do ambiente da mesma forma. Isso reduz a necessidade do usuário aprender novos comandos para uma ferramenta recém integrada e permite que ele se concentre apenas na funcionalidade específica das ferramentas que ele utiliza. Não foram propostas implementações de integração deste tipo, pois não houve situações nas quais isto foi necessário. No entanto, com o avanço do Projeto SPIDER, este tipo de integração pode ocorrer.

49 Integração de Dados As ferramentas compartilham informações através de um mesmo formato de dados. Os usuários podem trabalhar com o mesmo item de dados utilizando múltiplas ferramentas. Os métodos para prover integração de dados são: transferência direta de informação entre duas ferramentas (pipes), transferência baseada em arquivo (as ferramentas compartilham um arquivo), transferência baseada em comunicação (apropriada para sistemas abertos e ambientes distribuídos) e transferência baseada em repositório compartilhado (com serviços de armazenamento e gerência de objetos, controle de versões, configurações, segurança e transações). O repositório é o componente central da abordagem de integração de dados. O compartilhamento de dados é obtido através de esquemas comuns que definem a estrutura e comportamento dos dados Integração de Controle As ferramentas devem ser capazes de notificar eventos para outras ferramentas, ativar outras ferramentas e compartilhar funções de outra ferramenta, ou seja, exercer influência sobre outras. Os mecanismos de integração de controle incluem passagem explícita de mensagens, triggers ativados (por tempo e por acesso) e servidores de mensagens. Para obter integração de controle as ferramentas utilizam serviços de mensagem para prover três tipos de comunicação: ferramenta-ferramenta (entre ferramentas), ferramentaserviço (entre uma ferramenta e o serviço de outra ferramenta) e serviço-serviço (entre serviços de ferramentas). Uma alta integração de controle pode aumentar o grau de automação do processo de desenvolvimento de software no ambiente Integração de Processo As ferramentas do ambiente devem ser utilizadas de acordo com um processo de desenvolvimento descrito formalmente através de uma linguagem de modelagem de processo e executado através de uma máquina de execução do processo. Não é o foco deste trabalho propor integração de processo pois isto não é exigência do nível G e F do MPS.BR. Abordagens de Integração de Processo fornecem, no entanto, possibilidades de melhoria, no futuro, ao Projeto SPIDER.

50 Proposta de Integração Ferramental Considerando os mapeamentos entre Resultados Esperados da Seção 4.2, as ferramentas selecionadas para o Projeto SPIDER da Seção 4.3 e os tipos de integração da Seção 5.1, este trabalho apresenta uma proposta de integração entre as ferramentas CASE aderentes aos processos definidos no Nível G do MPS.BR. Para dar suporte à implementação da integração, é necessário definir um repositório que contenha: (I) os arquivos contendo o Plano de Projeto, oriundos do OpenProj; (II) os relatórios de análise de viabilidade, gerados no Spider-CL e (III) os relatórios de auditoria de Gerência de Configuração, também gerados no Spider-CL. Estes repositórios, no contexto do Projeto SPIDER, podem ser criados nas ferramentas SVN ou CVS, conforme opção da organização. Ambas possuem as mesmas funcionalidades básicas para o funcionamento do sistema de Gerência de Versão. A metodologia para criação de repositórios está descrita no manual para Gerência de Configuração do Projeto SPIDER, disponível em As Subseções a correspondem às propostas de integração aderentes aos mapeamentos encontrados nas Seções a , respectivamente. São descritos, a seguir, o tipo de integração identificado entre ferramentas, acompanhado da descrição da proposta de integração. Modificações propostas nas ferramentas estão circuladas por uma linha vermelha nas figuras desta seção GPR 1 x MED 1 Para definir os Objetivos de Medição para o projeto é necessário ter em vista o escopo do Projeto. Portanto, como proposta de integração, foi definido que ao clicar na funcionalidade de alocação de Objetivos de Medição para o Projeto, a ferramenta Spider- MPLAN deve disponibilizar um link apontando para o repositório contendo os Planos de Projeto, o qual contém o escopo do Projeto. A escolha do Plano de Projeto que será utilizado para definir os Objetivos de Medição para o projeto é feita baseada no contato da área de Medição da organização com o Gerente de Projeto. Este mapeamento é do tipo Controle, pois o evento de clicar no link Escopo, disponível na ferramenta Spider-MPLAN, dispara o evento de exibir o repositório no sistema operacional.

51 51 Figura 5.1: Alocar Objetivos para o Projeto na Ferramenta Spider-MPLAN Figura 5.2: Escopo Disponibilizado pela Ferramenta OpenProj

52 52 A Figura 5.1 corresponde à tela para alocação de Objetivos para o Projeto encontrada na ferramenta Spider-MPLAN. A mudança proposta corresponde à inserção de um link Escopo, o qual direcionará para o repositório de Planos de Projeto, onde está disponível o escopo do projeto obtido da ferramenta OpenProj, como mostrado na Figura 5.2. Para dar suporte a esta abordagem, foi necessário instituir também uma mudança no registro de projetos na ferramenta Spider-MPLAN: incluir, no cadastro de Projetos da Organização, o campo Planos do Projeto. Este campo deve ser preenchido com o caminho para o repositório o qual contém os Planos de Projeto. A mudança é apresentada na Figura 5.3. Figura 5.3: Cadastro de Projetos da Organização na ferramenta Spider-MPLAN GPR 5 x GCO 3 Quando uma tarefa, a qual implique em geração de baseline, for criada, o Gerente de Projeto deve atribuir a tarefa ao responsável pela Gerência de Configuração, conforme exemplo na Figura 5.4. Esta operação ocorre na ferramenta OpenProj. No momento em que as informações forem salvas no OpenProj e, consequentemente, transpostas para o dotproject, passa para o controle desta última ferramenta manter o acompanhamento da tarefa até sua

53 conclusão. É importante que o caminho do repositório contendo a baseline gerada seja informado no ato da execução da tarefa, de acordo com o exemplo presente na Figura Figura 5.4: Tarefa instanciada no OpenProj Figura 5.5: Task finalizada no dotproject: repositório de baselines

54 54 O método para a transferência de informações do OpenProj para o dotproject é especificado no manual para Gerência de Projetos do Projeto SPIDER, disponível em Este mapeamento possui integração de Dados e Controle entre as ferramentas OpenProj e dotproject. A relação entre Resultados Esperados é implementada através do processo da organização em conjunto com o uso das ferramentas OpenProj e dotproject GPR 6 x GQA 4 As não conformidades são solucionadas por meio de medidas, denominadas ações corretivas. Ao se realizar tal ação corretiva, deve-se previamente analisar os riscos implicados em possíveis alterações, impactando diretamente no projeto em questão, isto é, caso a análise de impacto das ações corretivas constatar que são necessárias modificações em cadeia em produtos de trabalho, ações pertinentes às novas modificações devem ser efetivadas. Portanto, como exemplificado, na tela inicial, para criação de ticket da ferramenta de Gerência de Mudança, acessível via wiki, deve ser inserido um link que direciona para o repositório de Planos de Projeto. Neste Plano está contida a análise dos riscos e seus impactos associados ao projeto, conforme protótipo na Figura 5.6, que apresenta a tela de riscos cadastrados pela ferramenta OpenProj. Figura 5.6: Análise de Riscos Disponibilizada pela Ferramenta OpenProj

55 55 Este mapeamento é do tipo Controle, pois o evento de clicar no link direcionando para o repositório de Planos de Projeto, ocorrido na ferramenta de Gerência de Mudança, dispara o evento, no sistema operacional, de exibir o repositório GPR 9 x GCO 2 A seleção do que será considerado um item de configuração é normalmente baseada em critérios previamente estabelecidos, descritos no plano de Gerência de Configuração. A seleção dos dados relevantes do projeto (relatórios, estudos e análises, atas de reunião, entre outros) é um dos insumos levados em consideração para definir o que é um item de configuração. Para garantir o atendimento a este mapeamento entre Resultados Esperados, deve constar na wiki da ferramenta de Gerência de Mudança um link para consultar os dados relevantes do projeto através da ferramenta OpenProj (vide Figura 5.7), contidos no repositório de Planos de Projeto. Figura 5.7: Dados Relevantes do Projeto na Ferramenta OpenProj Este mapeamento é do tipo Controle, de modo semelhante ao mapeamento anterior.

56 GPR 10 x GPP 2 No Plano de Projeto, os recursos devem ser discriminados e alocados. A Gerência de Portfólio de Projetos prevê que os recursos da organização (equipamentos, ferramentas, serviços, componentes, entre outros) sejam provisionados e disponibilizados. Portanto, para alocar os recursos ao projeto, o Gerente de Projetos deve consultar que recursos a organização tem disponível no momento. No contexto do Projeto SPIDER, para implementar este mapeamento, é necessário consultar as informações providas pelo dotprojet acerca dos recursos da empresa, vide Figura 5.8 e atribuir coerentemente os recursos do projeto no OpenProj, conforme Figura 5.9. Figura 5.8: Recursos da Organização, na Ferramenta dotproject

57 57 Figura 5.9: Recursos do Projeto, na Ferramenta OpenProj Este mapeamento não implica em integração entre ferramentas CASE. É suprido através do processo da organização em conjunto com o uso das ferramentas OpenProj e dotproject GPR 11 x GPP 1 Para que ocorra a transformação de um projeto em execução em um Portfólio, a análise de viabilidade do projeto deve ser consultada. Dependendo de seu resultado, o score do projeto pode ser alterado. Para suprir este mapeamento, a ferramenta dotproject deve ser modificada para apresentar um link rotulado Visualizar Análise de Viabilidade, nos detalhes do projeto, conforme a Figura Este link deve redirecionar para o repositório de relatórios de análise da viabilidade do projeto. Os relatórios de análise de viabilidade (considerando escopo do projeto, aspectos técnicos (requisitos e recursos), financeiros (capacidade da organização) e humanos) são, de acordo com a proposta do Projeto SPIDER, arquivos do tipo PDF gerados pela ferramenta Spider-CL.

58 58 Figura 5.10: Análise de Viabilidade do Projeto no dotproject Este mapeamento é do tipo Controle, pois o evento de clicar no link direcionando para o repositório de análise de viabilidade, ocorrido na ferramenta dotproject, dispara o evento de exibir o repositório GPR 11 x GPP 5 A manutenção, ou cancelamento de um projeto em execução, do ponto de vista de Gerência de Portfólio, pode utilizar como um dos parâmetros para apoiar a decisão, a análise de viabilidade do projeto. O link apresentado na Figura 5.10, portanto, também é utilizado neste mapeamento. Os detalhes do projeto estão presentes também na funcionalidade de Avaliar Continuidade do Projeto. Este mapeamento, consequentemente, tem o mesmo tipo de integração entre ferramentas CASE apresentado na subseção 5.2.6, ou seja, é do tipo Controle GPR 17 x GQA 4 Foi analisado, no Projeto SPIDER, que ambos os resultados esperados utilizam a ferramenta de Gerência de Mudança para reportar não conformidades, bem como acompanhar sua resolução, através de uma ou mais ações corretivas, por parte da equipe de projeto encarregada, até a sua conclusão, sendo que o processo de Garantia da Qualidade é somente efetivado quando as não conformidades encontradas forem solucionadas.

59 59 Portanto, o uso da ferramenta Trac ou Mantis pela organização, seguindo as metodologias de uso disponibilizadas em atende à implementação do relacionamento entre Resultados Esperados. Foi constatado, consequentemente, que não há integração entre ferramentas CASE GPR 17 x GPP 4 Podem ser constatados problemas na alocação de recursos (equipamentos, ferramentas, serviços, componentes, entre outros) ao analisar a tabela de disponibilização de recursos da organização. Caso eles sejam encontrados, uma não conformidade é gerada, por conseguinte, ações corretivas devem ser instanciadas. Portanto, ao acessar a tabela que corresponde à disponibilidade de recursos na ferramenta DotProject, conforme a Figura 5.11, é disponibilizado um link para criação de tickets somente quando houver conflito (não conformidade) entre os recursos alocados. Caso o Gerente de Portfólio acesse este link, será redirecionado para a página de criação de ticket, o qual deve ser encaminhado para os Gerentes de Projeto responsáveis pelos recursos envolvidos, vide a Figura 5.12, conforme processo da organização, para dar início à resolução da não conformidade por parte da equipe de projeto. Figura 5.11: Verificar Alocação de Recursos na Ferramenta dotproject

60 60 Figura 5.12: Ticket Criado na Ferramenta Trac Tendo em vista a proposta de integração, este mapeamento é do tipo Integração de Controle, pois um evento de clique na ferramenta dotproject dispara a ferramenta de Gerência de Mudança GRE 1 x GPR 1 Quando novos requisitos são avaliados e aceitos, impactos no escopo podem ser observados, uma vez que o escopo define o que está e o que não está incluído no projeto. É necessário, então, para mantê-lo atualizado, prever ações corretivas caso ocorra este evento, dado que haverá uma não conformidade com o escopo anterior analisado, isto é, uma modificação na documentação representativa do escopo, a EAP (Estrutura Analítica do Projeto), poderá ocorrer. Portanto, na tela de detalhes dos requisitos da ferramenta OSRMT, um link para a criação de ticket na ferramenta de Gerência de Mudança deve ser adicionado, conforme a Figura Este deve reportar a inconsistência entre requisitos aceitos e o escopo do Projeto.

61 61 Figura 5.13: Detalhes dos Requisitos no OSRMT Este mapeamento é do tipo Integração de Controle, pois um evento de clique na ferramenta OSRMT dispara a ferramenta de Gerência de Mudança GRE 1 x GPR 2 A organização necessita dimensionar seus produtos de trabalho. Cada organização normalmente escolhe a forma de dimensionamento mais apropriada para o seu contexto. No entanto, no Projeto SPIDER, a implantação da Gerência de Requisitos implica na definição de requisitos na Ferramenta OSRMT, os quais podem ser utilizados como método de mensuração. Para implementar este mapeamento, foi disponibilizado um link para que, ao se abrir a ferramenta OpenProj, sejam disponibilizados relatórios direcionados para a ferramenta OSRMT, conforme a Figura Neste caso, o mapeamento é suprido ao visualizar os Requisitos Aceitos, vide Figura 5.15.

62 62 Figura 5.14: Aba na Ferramenta OpenProj para Exibir Dados dos Requisitos Aceitos. Figura 5.15: Requisitos Aceitos do Projeto na Ferramenta OSRMT

63 Controle. Como há o disparo de evento do OpenProj para o OSRMT, ocorre a Integração de GRE 1 x GPR 3 O ciclo de vida do projeto consiste de fases e atividades que são definidas de acordo com o escopo dos requisitos. Para tanto, ao se definir o modelo e o ciclo de vida do Projeto, os requisitos aceitos devem ser consultados, tendo-se um maior controle gerencial. Esta definição ocorre na ferramenta OpenProj. Tendo em vista estas considerações, a proposta de integração é utilizar o link apresentado na Figura 5.14, direcionando para os requisitos aceitos apresentados na Figura É importante definir, no processo da organização, que esta consulta deve ocorrer para que o modelo e o ciclo de vida do projeto sejam estabelecidos. Este mapeamento é do tipo Integração de Controle, pois um evento na ferramenta OpenProj dispara a ferramenta OSRMT GRE 1 x GPR 5 Para definir as atividades que serão realizadas no Projeto em execução, o Gerente de Projeto deve consultar os requisitos aceitos. Esta operação é necessária, pois as tarefas instanciadas na ferramenta OpenProj devem ser compatíveis com os requisitos. Para implementar este mapeamento, utiliza-se a mesma interface do mapeamento anterior: o submenu Requisitos Aceitos ficará disponível na ferramenta OpenProj, direcionando para a ferramenta OSRMT, conforme Figura Dessa forma poderá ser analisado, por parte do gerente, o impacto sobre o custo do projeto através do acesso aos requisitos avaliados e aceitos, vide a Figura O processo da organização deve estabelecer que esta consulta ocorra para que as tarefas sejam definidas na organização. A Integração é do tipo Controle semelhante à subseção anterior GRE 1 x GPR 11 A análise de viabilidade do projeto leva em consideração alguns aspectos técnicos, como, por exemplo, os requisitos avaliados e aceitos. Esta operação é necessária pois a aceitação de novos requisitos pode inviabilizar a continuidade do projeto caso estes requisitos

64 64 não sejam compatíveis com o escopo original do Projeto. Portanto, no início de um projeto pode ser conduzida uma avaliação preliminar, a partir de uma visão geral dos requisitos. Outra medida necessária é o acompanhamento da evolução dos requisitos associados ao projeto para reavaliar a viabilidade do projeto. O OpenProj possui uma janela, disponível após definição do Plano de Projeto como sendo uma baseline, onde este relatório de análise de viabilidade é inserido. Portanto foi proposta a inserção de um link nesta janela, vide Figura 5.16, direcionando para os requisitos aceitos da ferramenta OSRMT, vide Figura Figura 5.16: Confirmação de Viabilidade do Projeto na Ferramenta OpenProj. A Integração é do tipo Controle, pois o evento de clicar no link proposto provoca o disparo da ferramenta OSRMT GRE 1 x GCO 7 No ato da realização de auditorias de Gerência de Configuração, a visualização dos requisitos avaliados e aceitos pode ser necessária, conforme definido no Plano de Configuração da organização. Portanto foi definido que, quando o responsável pela área de processo de GCO criar um checklist na ferramenta Spider-CL com o objetivo de realizar uma auditoria, vide Figura 5.17, um campo indicando o path da ferramenta OSRMT poderá ser preenchido.

65 65 Figura 5.17: Criação de um checklist na Ferramenta SPIDER-CL. Este mapeamento contempla a integração do tipo Integração de Controle, pois nota-se a presença de um link na Spider-CL que irá disparar a execução da OSRMT GRE 2 x GPR 12 Estabelecer compromissos é de grande valia para que um projeto possa atingir suas metas definidas, pois serão realizadas revisões nos planejamentos, bem como análises de recursos estimados e disponíveis. Contudo, obter tal compromisso pode englobar todos os interessados internos ou externos ao projeto. Com isso, o comprometimento da equipe técnica com os requisitos (após a aprovação dos mesmos) deve preceder o comprometimento dos stakeholders com o projeto. A equipe do projeto definiu, então, que ao criar um tópico para assegurar comprometimento dos stakeholders com o Plano de Projeto na ferramenta dotproject, vide Figura 5.18, o Gerente de Projeto deve inserir, no corpo deste, o link para o tópico referente

66 66 ao comprometimento da equipe técnica com os requisitos. Este comprometimento com a equipe do projeto deve ser obtido anteriormente, utilizando a mesma ferramenta. O processo da organização, portanto, deve determinar que esta operação seja realizada. Figura 5.18: Obtenção do Comprometimento dos Envolvidos ao Plano do Projeto na Ferramenta OpenProj. Este mapeamento não possui integração de ferramentas CASE, sendo implementado, nesta proposta, através do uso da ferramenta dotproject e de adaptação do processo da organização GRE 3 x GPR 5 A rastreabilidade bidirecional entre requisitos e produtos de trabalho possibilita a análise de possíveis impactos no cronograma, proporcionados por alterações nesses requisitos. Na tela principal do OpenProj deve haver um botão contendo como rótulo rastreabilidade bidirecional, conforme Figura 5.19, que, ao ser clicado, abra uma janela contendo os dados da rastreabilidade bidirecional de requisitos no OSRMT, vide Figura Estes insumos são utilizados na ferramenta OpenProj, neste caso, para determinar o impacto das alterações de requisitos no cronograma.

67 67 Figura 5.19: Aba na Ferramenta OpenProj para Direcionar para a Rastreabilidade Bidirecional Figura 5.20: Rastreabilidade Bidirecional de Requisitos e Produtos de Trabalho na Ferramenta OSRMT