UMA PROPOSTA DE INTEGRAÇÃO DOS RESULTADOS ESPERADOS DO NÍVEL F 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 Heresson João Pampolha de Siqueira Mendes José Alberto de Andrade Ávila UMA PROPOSTA DE INTEGRAÇÃO DOS RESULTADOS ESPERADOS DO NÍVEL F 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 Heresson João Pampolha de Siqueira Mendes José Alberto de Andrade Ávila UMA PROPOSTA DE INTEGRAÇÃO DOS RESULTADOS ESPERADOS DO NÍVEL F DO MPS.BR Data da defesa: 17/12/2009 Conceito: Banca Examinadora Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA Orientador Prof. Dr. Dionne Cavalcante Monteiro Faculdade de Computação/UFPA Membro Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA Membro Belém 2009

3 I Ao Pai que está nos céus e aos nossos pais terrenos que tanto nos apoiaram.

4 II AGRADECIMENTOS Primeiramente a Deus por me dar forças para vencer as dificuldades da vida. Agradeço também aos meus pais e familiares por todo o carinho e dedicação, incentivando constantemente para meu crescimento pessoal e profissional. À minha namorada Gabriela por todo amor, apoio incondicional e principalmente pela paciência nos momentos de ausência durante a realização deste trabalho. Aos meus amigos de curso, pelos momentos de descontração nesta jornada ao longo destes cinco anos. Ao professor Sandro, pelo seu profissionalismo, dedicação e paciência, e por sempre apresentar-se disponível durante os momentos de dúvida, e finalmente todos os amigos de trabalho do projeto SPIDER, especialmente ao meu amigo José Alberto, a quem tive o prazer de dividir as atividades deste trabalho. Heresson João Pampolha de Siqueria Mendes À Deus, pela vida e por tudo o que Ele me proporcionou. Aos meus pais que sempre dedicaram seu amor incondicional. Às minhas irmãs por todo o seu afeto e por seu exemplo. À Ana Paula por todo o seu carinho especial durante essa jornada. Meus sinceros agradecimentos aos meus irmãos por escolha: Camila, David, Frederico, Leonardo, Gleicy e Natalia, sem sua amizade tudo isso não seria possível. Aos meus companheiros: Daniele, Larissa, Heresson e Tom, pelo prazer de ter percorrido ao lado de vocês essa longa caminhada e pela grande amizade que criamos. E aos colegas de Projeto, que juntos lutamos para chegarmos até aqui. Em especial ao Prof. Dr. Sandro, por sua dedicação e atenção com nossas pesquisas. José Alberto de Andrade Ávila

5 III E você aprende que realmente pode suportar que realmente é forte, e que pode ir muito mais longe depois de pensar que não se pode mais. E que realmente a vida tem valor e que você tem valor diante da vida! Nossas dúvidas são traidoras e nos fazem perder o bem que poderíamos conquistar se não fosse o medo de tentar. William Shakespeare

6 IV RESUMO Em um ambiente de desenvolvimento de software, a informação correta e consistente é extremamente importante. Inconsistências e erros gerenciados de forma ineficaz durante o desenvolvimento certamente refletirão no produto final. Para evitar ao máximo a corrupção da informação dentro de um ambiente de desenvolvimento foram criados Modelos de Processo de Software. Tendo como principal meta a qualidade do software, estes modelos de processo, tendem a ser o ponto determinante durante a escolha de aquisição de um software. Dentro deste contexto encontra-se o MPS.BR (Melhoria de Processo de Software Brasileiro). Para a implementação deste modelo de maturidade, é necessário que a empresa preencha certos requisitos, chamados no contexto do MPS.BR de Resultados Esperados. Estes resultados são agrupados em processos de acordo com as áreas de conhecimento da engenharia de software. E estas áreas agrupadas e divididas em sete níveis. Este trabalho propõe uma forma de integração entre ferramentas CASE opensource que auxiliem de forma sistematizada a implementação do MPS.BR. PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, Nível de Maturidade F, MPS.BR, Ferramentas de Software.

7 V ABSTRACT In a software development environment, the correct and consistent information is extremely important. Inconsistencies and errors mistreated during the development certainly reflected in the final product. Avoiding any corruption of information within a development environment was created Software Process Models. With the main goal of Software Quality, the model tends to be the determining factor for the choice of purchasing software. Within this context is the MPS.BR (Brazilian Software Process Improvement). Implementing this model, it is necessary that the company meets some requirements, called in MPS.BR of Expected Results. These results are grouped according to the Software Engineering Areas. And these areas grouped and divided into 7 levels. This work proposes a way of integration between open source CASE tools that help a systematic implementation of MPS.BR. KEYWORDS: Process Improvement, Software Quality, F Maturity Level, MPS.BR, Software Tools.

8 VI SUMÁRIO 1. INTRODUÇÃO Contexto do Trabalho Justificativa Motivação Objetivos Metodologia Estrutura UMA VISÃO GERAL DO MPS.BR Histórico da Qualidade de Software Definição e Composição do Modelo de Maturidade Níveis de Maturidade Considerações Finais NÍVEL F DO MPS.BR Objetivos Finalidade Gerência de Configuração Garantia da Qualidade Medição Gerência de Portfólio Aquisição Considerações Finais PROPOSTA DE INTEGRAÇÃO DO NÍVEL F O Projeto SPIDER Mapeamento dos Resultados Esperados Ferramentas Definidas dotproject... 25

9 OPENPROJ OSRMT Mantis Trac Subversion CVS SPIDER-MPlan SPIDER-QA SpiderCL Considerações Finais METODOLOGIA PARA A INTEGRAÇÃO DA IMPLEMENTAÇÃO DOS PROCESSOS Categorias de Integração entre Ferramentas Mapeamento das Ferramentas Integradas GCO1 x GPR GCO1 x GPR GCO2 x GPR GCO4 x GPR GCO5 x GRE GCO5 x GQA GCO6 x GPR GCO6 x MED GCO7 x GPR MED3 x GPR GCO2 x MED MED4 x GPR MED7 x GPR GQA1 x GRE VII

10 GQA4 x GPR GPP1 x GPR GPP3 x GPR GPP4 x GPR Considerações Finais CONCLUSÃO Resumo do Trabalho Resultados Obtidos e Trabalhos Futuros Elaboração de um Artigo Aderência ao Modelo CMMI Implementação das Customizações Sugeridas Estender o Mapeamento para os Níveis Seguintes do MPS.BR Lições Aprendidas Referências Bibliográficas VIII

11 IX LISTA DE FIGURAS Figura 2.1 Estrutura do programa MPS.BR [SOFTEX, 2009a] Figura Propriedades das categorias de integração [OLIVERA, 2001] Figura Menu de Plano de Gerência de Configuração Figura Menu de Auditorias de Gerência de Configuração Figura Protótipo de Medição com a seleção dos itens de configuração Figura Menu de acesso ao plano de medição na ferramenta Openproj Figura Cadastro de procedimentos de coleta da ferramenta SPIDER-Mplan Figura 5.7- Customização da análise de viabilidade na ferramenta OpenProj Figura 5.8 Link para os resultados de avaliação do documento de requisitos Figura Menu para visualização das auditorias de garantia da qualidade Figura Menu para visualização das área de Gerência de Negócios Figura Gráfico de Estatística de Dependências Figura Gráfico de estatística de Tipos de Integração

12 1 1 INTRODUÇÃO Este capítulo apresentará o trabalho de uma forma geral, com suas justificativas, motivações, objetivos e a estrutura do trabalho. É feita também uma breve contextualização do trabalho ao mercado de software brasileiro. 1.1 Contexto do Trabalho Conforme o mercado de software foi crescendo, a necessidade de meios para medir a qualidade de produção e do produto final tornou-se indispensável [SOMMERVILLE, 2007]. Nesta situação surgiram modelos de qualidade de processo de software. Modelos como CMMI, ISO/IEC e ISO/IEC foram criados e internacionalmente reconhecidos, inclusive no Brasil. Mas estes modelos são muito custosos para serem implementados nas empresas brasileiras. Por este motivo, a Associação para Promoção da Excelência do Software Brasileiro SOFTEX, com apoio do Ministério da Ciência e Tecnologia desenvolveram o modelo MPS.BR (Melhoria de Processo de Software Brasileiro), focado na realidade do mercado brasileiro [SOFTEX, 2009a]. Hoje o MPS.BR já é sugerido para ingresso em algumas licitações do Governo Federal. A implementação do MPS.BR é importante principalmente para micros, pequenas e médias empresas, que necessitam estar de acordo com padrões de qualidade, exigidos para realizar atividades referentes à serviços de terceirização solicitados por empresas de grande porte, que possuem padrões internacionais. O modelo de qualidade brasileiro, neste contexto, torna-se uma opção menos custosa que os modelos utilizados internacionalmente. 1.2 Justificativa A implantação do MPS.BR, atualmente, ocorre de forma pouco sistematizada, apesar de existirem várias ferramentas, utilizando-se muitas vezes apenas documentos de textos e planilhas que dificultam a atualização e o controle dos dados sobre o projeto. Neste cenário, surgiu o projeto SPIDER [OLIVEIRA, 2008], que visa estabelecer um SUITE de ferramentas de software livre, que possam atender aos resultados esperados do MPS.BR de forma sistêmica, resultando na entrega de projetos de uma maneira mais ágil e otimizada.

13 2 Para que haja a comunicação entre as ferramentas é necessário realizar um estudo de como ocorrem as dependências entre os resultados esperados do modelo, e como pode ser realizada a implementação conjunta dos mesmos. Assim, estará formado o arcabouço necessário para a integração entre as ferramentas que atenderão aos diversos processos. 1.3 Motivação De todas as áreas de conhecimento estudadas no curso de Ciência da Computação, a que se evidenciou mais atrativa foi a área de Engenharia de Software, mais especificamente a parte que trata de Qualidade de software, sendo que um dos seus tópicos estuda a melhoria de processo de software, que pode ser considerada recente no mercado brasileiro. Portanto, há uma grande necessidade de profissionais nesta área, assim como muito a ser pesquisado. O Projeto SPIDER surgido dentro da UFPA com a proposta de abordar esta área de grande interesse pessoal, através de uma forma inovadora. Possibilitou o estudo em qualidade de software e pesquisa de ferramentas que auxiliem na implementação do processo de desenvolvimento de software. Como finalidade, o projeto propôs a utilização das pesquisas como base para escrever este trabalho e posteriormente um artigo a ser publicado. 1.4 Objetivos Geral Estudar modelos de melhoria de Processo de Software; Aprofundar os conhecimentos em Qualidade de Software; Definir um SUITE de ferramentas de suporte aos processos do nível F do MPS.BR Específicos Analisar detalhadamente o MPS.BR e seus resultados esperados; Propor Integrações entre os Resultados Esperados dos Processos de nível F do MPS.BR;

14 3 Propor Integrações entre ferramentas de apoio a sistematização dos processos de nível F do MPS.BR. 1.5 Metodologia Este trabalho é um sub-projeto dentro do Projeto SPIDER, e foi desenvolvido inicialmente com pesquisa sobre os níveis G e F do modelo de maturidade MPS.BR, de forma exploratória com base bibliográfica em Guias do modelo e em livros da área de Engenharia de Software. Esta pesquisa serviu de base teórica para a análise de dependências dos Resultados Esperados do MPS.BR. Em seguida foram estudadas ferramentas que pudessem auxiliar e sistematizar a implementação dos processos estudados no Projeto SPIDER. Para cada processo do nível F, há um subprojeto com uma equipe designada para definir e customizar as ferramentas que irão compor o SUITE. Ao final desta etapa, a pesquisa passou a ter caráter explicativo, procurando adequar as ferramentas selecionadas na etapa anterior aos resultados esperados dos processos em estudo, bem como a integração entre estes. Os resultados de cada etapa foram expostos a todos no projeto SPIDER através de reuniões semanais. 1.6 Estrutura Este trabalho está estruturado em seis capítulos: Introdução, Uma visão geral do MPS.BR, Nível F do MPS.BR, Proposta de Integração do Nível F, Metodologia Para a Integração da Implementação dos Processos, Conclusão e referências bibliográficas. O capítulo 1 faz uma breve introdução sobre este trabalho, contextualizando-o, expondo sua justificativa, quais os seus objetivos, a sua motivação, a metodologia usada durante todo o processo de escrita deste. Há também esta secção, a estrutura do trabalho. O capítulo 2 apresenta o MPS.BR. O capítulo começa com o histórico de qualidade de software e a definição do modelo de maturidade aqui abordado. Cada nível do modelo é brevemente explanado bem como seus objetivos. No capítulo 3 há o aprofundamento do segundo nível do MPS.BR, o Nível F. Nele é apresentado seus objetivos, finalidades, e os processos de software que compõe este nível. Cada processo é explicado de maneira geral e seus resultados esperado são citados.

15 4 O capítulo 4 apresenta o Projeto SPIDER, base para este trabalho. Nesta sessão é exposto os resultados de pesquisa feitos dentro de um sub-projeto do Projeto SPIDER. As dependências entre resultados esperados dos níveis G e F do MPS.BR são apresentadas. Bem como as ferramentas selecionadas para auxiliar na implementação do modelo. O capítulo 5 descreve o mapeamento da proposta de integração entre as ferramentas selecionadas no Projeto SPIDER e uma forma de categorização de integrações entre ferramentas opensource. O capítulo 6 é a conclusão do trabalho e apresenta os resultados obtidos, lições aprendidas, trabalhos futuros e um resumo do trabalho.

16 5 2 UMA VISÃO GERAL DO MPS.BR Neste Capítulo será apresentado o modelo de qualidade de software MPS.BR, conhecimento necessário para o desenvolvimento do trabalho apresentado. Serão abordados: a origem deste modelo e seu desenvolvimento até o cenário atual, a composição e definições relacionadas ao MPS.BR, e finalmente, uma explanação de seus níveis de maturidade e processos envolvidos em seu processo de melhoria. 2.1 Histórico da Qualidade de Software A informação tornou-se um dos bens mais valiosos para qualquer empresa, tendo como exemplo, o atentado às torres gêmeas em 11 de Setembro de 2001, no qual se percebe a magnitude de tal bem. Executado, provavelmente não apenas com o intuito de ceifar vidas, foi uma forma clara de ataque aos padrões da era moderna. Muitas empresas mantinham sua base de dados em uma das torres do World Trade Center, e seu backup na torre ao lado. Estas empresas ou foram à falência ou chegaram próximo a isso, pois os dados financeiros de cobranças e dívidas foram perdidos. A informação foi perdida. Tratando-se de um ambiente de desenvolvimento de software, a informação também é extremamente importante. Pois uma informação errônea gera inconsistências ao produto final. Com a finalidade de evitar a corrupção ou mesmo a perda da informação durante o desenvolvimento de um projeto de software, criaram-se vários modelos de processos de Software. Estes processos buscam melhorar ao máximo a qualidade do produto final e do desenvolvimento, gerenciando e controlando cada etapa do desenvolvimento, até a entrega do produto ao cliente. Esta qualidade garantida pelo modelo de processo tende a ser o grande diferencial e ponto determinante na hora de tomar decisões ao adquirir um produto ou contratar um serviço. Inserido neste contexto, encontra-se o MPS.BR (Melhoria de Processo de Software Brasileiro), que trata-se de um modelo de maturidade da qualidade de software, baseado em modelos pré-existentes como o CMMI e outros padrões de qualidade como ISO/IEC 12207, ISO/IEC 15504, entre outros [SOFTEX, 2009a], com o diferencial de ser direcionado à realidade brasileira e latino-americana.

17 6 O MPS.BR é mantido pela Associação para Promoção da Excelência do Software Brasileiro SOFTEX, com apoio do Ministério da Ciência e Tecnologia, da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Foi criado para atender a demanda do mercado brasileiro, predominado por micro e pequenas empresas. Com o apoio do Governo Federal, micro e pequenas empresas, conseguem grande esforço, subsídios para a implementação dos primeiros níveis do modelo. Sendo o modelo MPS.BR melhor dividido, a implementação dos primeiros níveis é mais rápida em comparação com a implementação do modelo CMMI, que exige mais em seus primeiros níveis, apesar de adaptado a realidade brasileira, o modelo brasileiro é aderente aos modelos internacionalmente reconhecidos, aos quais baseia-se. 2.2 Definição e Composição do Modelo de Maturidade Este modelo estudado é definido de forma a facilitar para as micro e pequenas empresas a implementação de forma gradual à excelência em qualidade de software. Para isso o modelo de maturidade é composto de sete níveis de maturidade dispostos de G a A, sendo o nível G o mais baixo. De forma que a implementação do nível G não é tão demorada nem possui um alto custo, visto que o Governo Federal dá subsídios para incentivar a adoção do modelo. O modelo de maturidade está dividido em três itens (figura 2.1): O Modelo de Negócio (MN-MPS), voltado para as instituições implementadoras do modelo, o Método de Avaliação (MA-MPS), que especifica os itens a serem avaliados por uma instituição avaliadora, e pelo Modelo de referência (MR-MPS), que apresenta o programa MPS.BR é define boas práticas que devem ser atendidas em uma empresa que queira implementar este modelo de qualidade. O MPS.BR possui quatro guias que são referência para a implementação ou avaliação de um determinado nível dentro da empresa. O Guia Geral é o guia que descreve o modelo em linhas gerais e detalha o Modelo de Referência (MR-MPS). Este modelo de referência é o Modelo de Maturidade em si. Ele define os Resultados Esperados de cada processo que devem ser alcançados para a obtenção do nível pretendido. O segundo guia é o Guia de Implementação. Este guia serve como referência para as Instituições Implementadoras no momento de prestarem consultoria às empresas que pretendem implementar o MPS.BR. Ele mostra o que deve ser feito, mas não o como deve ser

18 7 feito. O guia não restringe de que modo o resultado esperado deve ser implementado, nem ferramentas a serem utilizadas, mas dá dicas de como alcançar o objetivo. Este Guia é dividido em sete partes, uma para cada nível de maturidade. Figura 2.1 Estrutura do programa MPS.BR [SOFTEX, 2009a]. O Guia de Avaliação é a referência para as Instituições Avaliadoras. Este guia define todo o processo e o método de avaliação que deve ser executado dentro da empresa pretendente ao nível. Além de definir os requisitos para Avaliadores e Instituições Avaliadoras. Há um último guia que é o Guia de Aquisição. Este guia descreve um processo de aquisição de software e serviços correlatos para apoiar o Modelo de Referência (MR- MPS). Para uma empresa tornar-se uma Instituição Implementadora ou Instituição Avaliadora, ela deve seguir um conjunto de requisitos contidos nos guias do modelo, solicitar o credenciamento junto ao Fórum de Credenciamento e Controle (FCC) que irá avaliar a empresa e caso positivo, a SOFTEX assina um Termo de Credenciamento com validade de dois anos [SOFTEX, 2009a]. Para a empresa obter um determinado Nível dentro do modelo, ela deve solicitar a uma das Instituições Implementadoras credenciadas à SOFTEX a consultoria de implementação do nível desejado. Após a implementação, a empresa solicita agora a SOFTEX a avaliação, que então encaminha para outra Instituição, agora a Instituição Avaliadora, que deve ser diferente

19 8 da Instituição Implementadora, para a avaliação. A empresa pode implementar vários níveis ao mesmo tempo, pulando níveis para atingir um outro mais alto. Por exemplo, a Empresa JDLH quer obter a certificação para Nível D, para tal ela deve implementar os Níveis G, F e E junto com o D. Normalmente as empresas implementam nível por nível, pois o custo e o esforço para cada nível são menores. Cada nível é dividido em vários Processos, que atendem a uma determinada área da engenharia de software, e cada processo possui um conjunto de Resultados Esperados, que devem ser contemplados pra a obtenção do nível. 2.3 Níveis de Maturidade Cada nível de maturidade a ser atingido por uma empresa possui uma lista de exigências, que garantem a melhoria na implementação do processo na organização. As exigências são categorizadas em processos, que são divididos em resultados esperados. O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. 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 [SOFTEX, 2009a]. A seguir serão detalhados cada um destes níveis, descrevendo os processos a serem atendidos. O Nível G, inicial, caracteriza-se por ser parcialmente gerenciado, no qual é composto pelos processos de gerência de projetos e gerência de requisitos. A gerência de projetos tem o propósito de 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]. Este processo é evoluído nos níveis de maior maturidade, incorporando novos resultados esperados e otimizando alguns existentes. O processo de gerência de requisitos tem a finalidade de gerenciar os requisitos do produto e de cada componente do produto do projeto, através do entendimento, avaliação e aceitação dos

20 9 requisitos, junto aos fornecedores e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. O Nível F, Gerenciado, é composto do modelo anterior, acrescidos dos processos de aquisição, que objetiva gerenciar todas as atividades relacionadas a aquisição de produtos e serviços entregues como parte do produto final ao cliente, Gerência de configuração que visa estabelecer, manter e controlar a integridade de todos os produtos de trabalho de um projeto disponibilizando aos envolvidos. Também compõem o nível F o processo de Garantia da qualidade que assegura a conformidade entre os produtos de trabalhos e processos entre os planos, procedimentos e padrões estabelecidos. O processo de Gerência de Portfólio de Projeto compromete-se a gerenciar a aderência dos projetos em relação aos objetivos estratégicos da organização, iniciando, mantendo e justificando a continuidade ou descontinuidade dos projetos. Finalmente o processo de medição, que coleta, armazena e analisa os dados relativos aos produtos e processos, a fim de apoiar decisões organizacionais. O Nível E, parcialmente definido, é composto pelos processos anteriores, incluindo a evolução do processo de gerência de projetos e os processos de avaliação e melhoria do processo organizacional, definição do processo organizacional, gerência de recursos humanos e gerência de reutilização. O processo de Avaliação e Melhoria do Processo Organizacional determina o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos. A Definição do Processo Organizacional estabelece e mantém um conjunto de ativos de processo organizacional e padrões do ambiente de trabalho usáveis e aplicáveis às necessidades de negócio da organização. O processo de Gerência de Recursos Humanos tem o propósito de prover a organização e os projetos com os recursos humanos necessários e manter suas competências adequadas às necessidades do negócio. E finalmente o processo de Gerência de Reutilização objetiva gerenciar o ciclo de vida dos ativos. O Nível D, largamente definido, é composto pelos processos dos níveis anteriores, incluindo os processos de Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção do produto, Validação e Verificação. O processo de desenvolvimento de requisitos tem o propósito de definir os requisitos do cliente, do produto e dos componentes do produto, enquanto o processo de integração do produto visa compor os componentes do produto,

21 10 produzindo um produto integrado consistente com seu projeto. O Projeto de construção do produto projeta, desenvolve e implementa soluções para atender aos requisitos, enquanto validar confirma que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido, e Verificação confirma que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados. O Nível C, definido e composto pelos níveis anteriores acrescidos da evolução do processo de gerência de reutilização e dos processos Desenvolvimento para Reutilização, gerência de decisões e gerência de riscos. O processo de desenvolvimento para reutilização tem o propósito de identificar oportunidades de reutilização sistemática de ativos na organização e, se possível, estabelecer um programa de reutilização para desenvolver ativos a partir de engenharia de domínios de aplicação. A gerência de decisões analisa possíveis decisões críticas usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas. A Gerência de Riscos objetiva identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto. O Nível B, Gerenciado Quantitativamente, é composto pelos processos dos níveis de maturidade anteriores, acrescido da segunda evolução do processo de gerencia de projetos, para atender objetivos de gerenciamento quantitativo. O Nível A, em otimização, é composto dos níveis anteriores, acrescido da otimização destes processos por meio de realização de mudanças e adaptações de forma ordenada e intencional para efetivamente atender mudanças nos objetivos de negócio da organização [ISO/IEC, 2004]. 2.4 Considerações Finais Este capítulo nos mostra como o MPS.BR está definido atualmente, seguindo sua última atualização em agosto de O modelo ainda tende a continuar se modificando para cada vez mais melhorar o processo e a qualidade de software brasileiro. Como citado anteriormente, este modelo tem como documentação os seus guias. A idéia de usar Instituições Implementadoras é justificada, além da transmissão da experiência com processos de software, pela dificuldade de entender os guias por profissionais e estudantes sem

22 11 experiência no assunto. Durante o estudo sobre o modelo, ficou claro que o modelo tem a intenção de orientar os seus leitores até os objetivos. No próximo capítulo iremos detalhar mais sobre os estudos realizados no Nível F deste modelo de maturidade, o qual é foco deste trabalho.

23 12 3 NÍVEL F DO MPS.BR Este capítulo irá apresentar o Nível F, segundo estágio de maturidade do modelo MPS.BR. Serão descritos os objetivos, finalidade e cada processo pertencente a este Nível de Maturidade. Lembrando que os outros processos de outros níveis não são o foco deste trabalho e são descritos no capítulo anterior. 3.1 Objetivos O Nível F do MPS.BR, é composto pelos processos de Gerência de Configuração, Garantia da Qualidade, Medição, Gerência de Portfólio de Projeto e Aquisição, além dos processos constantes no nível G do modelo [SOFTEX, 2009a]. Também é chamado de Nível Gerenciado, e tem como seu principal foco agregar processos de apoio à gestão do projeto, no que diz respeito à Garantia da Qualidade e Medição, além de prover gestão à organização dos artefatos de trabalho por meio da Gerência de Configuração [SOFTEX, 2009c]. Este nível possibilita à empresa uma maior visibilidade de como os artefatos são produzidos nas várias etapas do projeto e do processo. Essa visibilidade tem como foco analisar se os artefatos produzidos no processo e no projeto estão de acordo com os padrões e procedimentos estabelecidos, o que ajuda muito na implantação do programa de melhoria de processo sob o ponto de vista de institucionalização [SOFTEX, 2009c]. Nesse nível o papel fundamental para a melhoria de processos é do Gerente de Projeto, pois é ele quem tem a responsabilidade por atender aos objetivos do projeto em relação ao prazo, custo, esforço e requisitos [SOFTEX, 2009c]. Outra atividade importante que é controlada no nível Gerenciado, corresponde à aquisição, no qual muitas organizações subcontratam etapas do processo de desenvolvimento ou componentes específicos do produto. Essa atividade também deverá ser controlada com o mesmo rigor que as questões internas, mas respeitando o modo com que outras organizações trabalham. Os requisitos úteis para que esse controle seja feito de forma adequada é definido no processo Aquisição [SOFTEX, 2009c]. Porém, esta não torna obrigatória a implementação, visto que nem toda empresa faz uso de aquisição de produtos ou serviços. Além disso, a implantação do processo Gerência de Portfólio de Projetos possibilita às organizações uma

24 13 gerência mais efetiva dos recursos disponíveis entre os projetos e investimentos realizados, visando atender os objetivos estratégicos da organização. 3.2 Finalidade Ao implementar o nível F do MPS.BR, a empresa deverá atender a três atributos de processos, definidos no guia geral deste modelo, no qual definem a capacidade do processo, que expressa o grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. No MR-MPS, à medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido [SOFTEX, 2009a]. Os Atributos de Processos, subdivididos em resultados esperados de processo (RAP), que necessitam ser alcançados, são os seguintes: O processo é Executado, que define o quanto o processo atinge seu propósito, representado pelo resultado de atributo de processo RAP 1. O processo atinge seus resultados definidos; O processo é Gerenciado, que mede o quanto a execução do processo é gerenciada, representado pelos resultados de atributo de processo: RAP 2. Existe uma política organizacional estabelecida e mantida para o processo; RAP 3. A execução do processo é planejada; RAP 4. Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados; RAP 5. As informações e os recursos necessários para a execução do processo são identificados e disponibilizados; RAP 6. As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas; RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; RAP 8. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento; RAP 9. Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização; RAP 10. A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades;

25 14 Os Produtos de trabalho dos processos são gerenciados, trata-se de uma medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. É representado pelos resultados de atributo de processo: RAP 11. Os requisitos dos produtos de trabalho do processo são identificados; RAP 12. Requisitos para documentação e controle dos produtos de trabalho são estabelecidos. 3.3 Gerência de Configuração A Gerência de Configuração (GCO) é a área de processo responsável por manter, estabelecer e disponibilizar todos os produtos de trabalho do projeto ou processo, sendo presente em todas as fases do projeto. Esta Gerência é responsável por controlar o progresso do projeto implementando formas sistêmicas de controle de versões, de modificações e acesso a documentos [SOFTEX, 2009c]. Para controlar versões de documentos, a GCO deve armazenar todas as versões de documentos possíveis, mantendo assim um histórico de alterações dos mesmos. Quando há uma solicitação de alteração em um determinado documento, a GCO deve controlar esta solicitação até a sua implementação, caso seja aprovada. Com estes vários documentos, a GCO deve criar grupos de documentos (itens de configuração) que juntos formam uma baseline, ou versão geral do projeto ou protótipo. Para a formação de uma baseline de forma correta, íntegra e consistente, auditorias devem ser feitas verificando se os procedimentos e diretrizes estão sendo seguidos visando o contexto Gerência de Configuração. As auditorias podem ser funcionais ou físicas. Auditoria Funcional verifica se a baseline cumpre com o que foi especificado através de revisão dos seus documentos como resultado de testes e planos. Os Resultados Esperados requeridos para uma implementação de GCO são: GCO1 - Um Sistema de Gerência de Configuração é estabelecido e mantido; GCO2 - Os itens de configuração são identificados; GCO3 - Os itens de configuração sujeitos a um controle formal são colocados sob baseline; GCO4 - A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada; GCO5-Modificações em itens de configuração são controladas e disponibilizadas;

26 15 GCO6 - O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados; GCO7 - Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes. 3.4 Garantia da Qualidade O Processo de Garantia da Qualidade (GQA) é o responsável por verificar se os produtos de trabalho (documentação em geral) gerados estão de acordo os planos e recursos predefinidos e se o seu processo de execução está também de acordo com estas predefinições [SOFTEX, 2009c]. Esta equipe é responsável por apontar as não-conformidades em um projeto e é preferido que seus integrantes não pertençam ao projeto diretamente. Por estes motivos eles são conhecidos como os Olhos e os Ouvidos dos Gerentes. Não-conformidade é um componente, material de fabricação ou produto acabado fora de especificações, antes ou após a sua distribuição. [ANVISA, 2000]. Suas correções não são executadas pela GQA. Ao identificar uma não conformidade, a GQA informa os responsáveis e acompanha até que esta não-conformidade seja resolvida. Caso a não-conformidade não seja resolvida em tempo hábil, níveis superiores na hierarquia da organização são informados sobre esta não-conformidade para que medidas cabíveis sejam feitas. A verificação dos produtos de trabalho e processos aos padrões definidos deve ser feita de forma objetiva e antes destes atingirem seu deadline de entrega, podendo ser feita através de entrevistas e/ou questionários. Os Resultados Esperados para a implementação de GQA dentro do MPS.BR são: GQA1 - A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto. GQA2 - A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente. GQA3 - Os problemas e as não-conformidades são identificados, registrados e comunicados. GQA4 - Ações corretivas para 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.

27 Medição O processo de Medição (MED) tem a finalidade de 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, 2009c]. Medições de processos são dados quantitativos sobre processos de software. Humphrey (2005) sugere que a medição tem importante papel a desempenhar no aprimoramento de processos. A medição tem como principal foco apoiar a tomada de decisão em relação aos projetos, processos e atendimento aos objetivos organizacionais. No nível F, as medições são criadas de forma organizada a partir dos objetivos organizacionais e necessidades estratégicas de informação da organização. As medições cobrem tanto os projetos como os produtos de trabalho. Também deve ser definido um modelo de medição permitindo caracterizar objetivos e necessidades de informação relacionadas com as medidas básicas e indicadores definidos pela organização. Os resultados esperados que correspondem à implementação do processo de medição são: MED1 - 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; MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado; MED3 - Os procedimentos para a coleta e o armazenamento de medidas são especificados; MED4 - Os procedimentos para a análise das medidas são especificados; MED5 - Os dados requeridos são coletados e analisados. 3.6 Gerência de Portfólio Este processo é responsável por iniciar e manter projetos de acordo com os objetivos da organização [SOFTEX, 2009c]. A GPP (Gerência de Portfólio de Projetos) estuda oportunidades de negócios que podem se tornar projetos e vice-versa. Seu foco é na gerência de vários projetos, de forma a fiscalizar constantemente se os projetos em execução ainda

28 17 atendem aos objetivos da organização e se os projetos em análise devem ou não entrar em execução. Além de analisar as oportunidades e acompanhar os projetos em execução, a GPP gerencia os possíveis conflitos entre recursos alocados para os projetos. Os Resultados Esperados para a implementação de GPP dentro do MPS.BR são: GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificadas, qualificados, priorizados e selecionados; GPP2 - Os recursos e orçamentos para cada projeto são identificados e alocados; GPP3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas; GPP4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos; GPP5 - 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. 3.7 Aquisição O processo de Aquisição (AQU) objetiva gerenciar a aquisição de produtos que satisfaçam às necessidades expressas pelo adquirente. No contexto do MR-MPS, considera-se que o termo produto pode incluir também serviços, desde que estes sejam entregue como parte do produto final ao cliente [SOFTEX, 2009c]. Seu foco consiste no planejamento ou preparação para aquisição, desde a seleção do fornecedor até a monitoração do contrato, processos e produtos com a finalidade de assegurar um produto subcontratado de qualidade, principalmente quando este for integrado ao produto que será entregue para o cliente [SOFTEX, 2009c]. Este processo, contudo, não será focado neste trabalho, que tratará como nível F os processos correspondentes, excetuando-se o processo de aquisição, que será integrado em outro trabalho posterior, no qual irá descrever o guia de aquisição que contém o processo em questão. 3.8 Considerações Finais Este capítulo aprofundou os conhecimentos sobre o MPS.BR, mais especificamente, o nível de maturidade em foco: Nível F, Gerenciado. Apresentando seus objetivos, finalidades e processos envolvidos na implementação, demonstrando cada resultado esperado que deverá ser atendido a fim de implantação do nível. Como justificado anteriormente, este trabalho não

29 18 focará no processo de aquisição, visto que há um Guia Específico para tal, que engloba este processo e é parte de um projeto de Mestrado do PPGCC da UFPA. No próximo capítulo será apresentada a proposta de integração entre os resultados esperados de cada processo contidos nos níveis G e F, e explicitado como ocorrem as interdependências entre processos distintos.

30 19 4 PROPOSTA DE INTEGRAÇÃO DO NÍVEL F Neste capitulo será apresentado o projeto SPIDER e seus subprojetos na linha de pesquisa em qualidade de software. Também serão discutidos os resultados de pesquisa, acerca do mapeamento dos resultados esperados, ferramentas definidas para implementação do MPS.BR e o mapeamento destas ferramentas de acordo com as dependências de resultados esperados. 4.1 O Projeto SPIDER A implementação do MPS.BR, atualmente, ocorre de forma pouco sistematizada, utilizando-se muitas vezes, apenas documentos de textos e planilhas, que dificultam a atualização e o controle dos dados sobre o projeto [OLIVEIRA, 2008]. Neste cenário, surgiu o projeto SPIDER [OLIVEIRA, 2008], mantido pelo ICEN Instituto de Ciências Exatas e Naturais da UFPA Universidade Federal do Pará, que visa estabelecer um conjunto de ferramentas de software livre, através de um SUITE, com características adequadas para possibilitar 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 dos processos constantes nos níveis de maturidade do modelo MPS.BR. O SUITE definido durante o projeto, propiciará um uso mais integrado das funções e operações disponíveis em cada uma das ferramentas, de modo a apoiar a implementação dos processos do modelo MPS.BR, obedecendo o fluxo de dependência proposto por este modelo de qualidade de processo, resultando na entrega de projetos de uma maneira mais ágil e otimizada, e consequentemente, na redução de custos de desenvolvimento de cada projeto. Para que haja a comunicação entre as ferramentas, é necessário realizar um estudo inicial de como ocorrem as dependências entre os resultados esperados de cada processo do MPS.BR, e como pode ser realizada a implementação conjunta dos mesmos. Assim, estará formado o arcabouço necessário para a integração entre as ferramentas que atendem aos diversos processos.

31 Mapeamento dos Resultados Esperados Inicialmente, para realizar a integração sistematizada dos processos referentes ao nível F, foi necessário realizar um rastreamento de cada resultado esperado deste nível, identificando onde há dependência entre resultados esperados de processos diferentes. As relações de dependência dão-se entre um resultado esperado denominado base, o qual é caracterizado por fornecer dados necessários para que um resultado esperado dito dependente possa ser completamente atendido durante a implementação do modelo de qualidade. Devido à atenção deste trabalho estar voltada para a integração das ferramentas do nível F às ferramentas anteriormente implementadas (referentes ao nível G), o mapeamento de dependências foi realizado com foco nos resultados esperados do tipo base, referentes aos processos de nível F, relacionando-os com os resultados esperados dependentes tanto dos processos do nível F quanto do nível G. Os processos que compõem o nível G são Gerência de Projetos (GPR) e Gerencia de Requisitos (GRE). O processo GPR, possui dezessete resultados esperados e tem como propósito 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, 2009b]. Enquanto o processo GRE, com cinco resultados esperados, tem enfoque em 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, 2009b]. Relacionamentos de dependência intra-processos, ou seja, entre resultados esperados do mesmo processo de Engenharia de Software, não foram considerados para este trabalho, visto que este tipo de dependência é integrada em outros subprojetos do SPIDER, que objetivam definir ferramentas que atendam a cada processo, individualmente. Este tipo de dependência, considerada indireta, apesar de não ser tratado de forma cuidadosa neste trabalho - pois o interesse é identificar a relação entre processos distintos - são importantes para a implementação fiel do modelo MPS.BR. Analisando os resultados esperados dos processos em estudo, foram identificadas as seguintes dependências, descritas no formato: Resultado Esperado dependente depende de

32 21 Resultado Esperado Base, seguidas de sua justificativa e de uma forma como a dependência pode ser vista em uma possível implementação do MPS.BR: GPR8 depende de GCO1: o resultado esperado de gerência de projetos de número 8 estabelece que deve ocorrer o planejamento dos recursos e ambiente de trabalho (GPR8), logo, depende da definição da Sistematização da Gerência de Configuração (GCO1). Ao se planejar os recursos e o ambiente de trabalho de um projeto que irá implantar o processo de Gerência de Configuração, é necessário que as ferramentas de GCO estejam presentes no planejamento, ainda que elas já estejam em uso na empresa. E para tal devem ser definidas previamente ao fechamento do Plano de Recursos e Ambiente de Trabalho. GPR10 depende de GCO1: o resultado esperado de gerência de projetos de número 10 estabelece que deve ser realizado um controle de dados e documentos do projeto (GPR10), e para isto é necessário estabelecer um Sistema de Configurações (GCO1). As informações relativas ao estabelecimento e manutenção do sistema de configuração (GCO1) devem ser registradas no plano do projeto (GPR10). GPR2 depende de GCO2: o resultado esperado de gerência de projetos de número 2 estabelece que a definição das tarefas e produtos de trabalho (GPR2) deve ser realizada. Este resultado esperado depende da identificação dos itens de configuração definidos em GCO2. Durante o processo de desenvolvimento, a maioria das tarefas gera documentos. Estes documentos podem ou não ser classificados como itens de configuração e estas tarefas dependem dessa definição. GPR11 depende de GCO4: o resultado esperado de gerência de projetos de número 11 estabelece que devem ser realizadas análises de viabilidade do projeto. Os ajustes necessários após estas análises podem ser decididos com base no acompanhamento da situação dos itens de configuração e baselines (GCO4). Quando uma alteração ocorre em um item de configuração, ajustes pertinentes, baseados na rastreabilidade entre artefatos, devem ser realizados e podem gerar inviabilidade de continuidade do projeto, portanto estas alterações devem ser analisadas. GRE5 depende de GCO5: o resultado esperado de gerência de requisitos de número 5 estabelece o acompanhamento das mudanças de requisitos. Uma solicitação de mudança em um documento de requisitos precisa ser aprovada pelo CCC (Comitê de Controle de Configuração) que fará a analise de impacto desta mudança.

33 22 GQA4 depende de GCO5: as ações corretivas estabelecidas para tratar as não conformidades (GQA4) que envolvem mudança dos produtos de trabalho devem ser controladas e disponibilizadas pela (GCO5) Gerência de Configuração. Ao realizar uma ação corretiva para uma não conformidade, e ser realizada a implementação de uma modificação, deve ocorrer uma atualização da baseline. GPR9 depende de GCO6: o controle, manuseio e liberação dos itens de configuração (GCO6) devem estar explicitados na identificação e planejamento quanto à forma de coleta, armazenamento e distribuição dos dados relevantes do projeto (GPR9). O controle dos dados relevantes do projeto descrito no GPR9 deve levar em conta as exigências de controle de itens de configuração descritas no GCO6. MED6 depende de GCO6: para que os dados e os resultados de análises sejam armazenados (MED6) é necessário o controle do sistema de armazenamento (GCO6). O sistema de armazenamento indicará onde e como os artefatos contendo os dados e os resultados de análises deverão ser armazenados. GPR13 depende de GCO7: a auditoria física e funcional (GCO7) devem ser um dos critérios utilizados para verificar a aderência do progresso do projeto ao estabelecido no Plano de Projeto (definido no resultado esperado de gerência de projetos de número 13). As auditorias realizadas para acompanhamento do projeto incluem a auditoria física e funcional da Gerência de Configuração. GPR8 depende de MED3: pois O sistema de armazenamento de medidas (MED3) deve constar no planejamento de recursos e ambiente de trabalho para executar o projeto (GPR8). O planejamento de recursos dependerá do procedimento de coleta e armazenamento de medidas especificado. Ao utilizar uma ferramenta de medição para tal esta escolha deve estar incluída no planejamento. MED3 depende de GCO2: A identificação dos itens de configuração (GCO2) deve ocorrer para que os procedimentos para a coleta e o armazenamento de medidas possam ser especificados (MED3). Antes de definir os procedimentos utilizados na coleta e armazenamento de medidas, é necessário haver uma definição quais são os itens de configuração. GPR10 depende de MED4: Os procedimentos para a análise das medidas especificadas (MED4) devem constar no Plano de Projeto (GPR10). Os procedimentos de análise como a definição da freqüência, responsável, fase, dados

34 23 de origem, ferramenta utilizada e verificações devem estar elicitados no Plano de Projeto GPR11 depende de MED7: As informações geradas no processo de medição (MED7) podem servir de base para a tomada de decisões (GPR11). A gerência de Medição informará as gerências responsáveis sobre análises de medição que sejam relevantes mudanças de decisões. GRE1 depende de GQA1: o resultado esperado de gerência de requisitos de número 1 estabelece que os requisitos devem ser entendidos, avaliados e aceitos. A aceitação de requisitos devem levar em conta a aderência do documento de requisitos em relação aos padrões aplicáveis (GQA1). A aderência do documento de requisitos aos padrões aplicáveis deve ser levada em conta antes mesmo da avaliação e aceitação dos requisitos de software. GPR13 depende de GQA4: O estabelecimento e acompanhamento das ações corretivas para não-conformidades até a sua efetiva conclusão (GQA4) servem como insumo para monitorar o progresso do projeto (GPR13). A execução do projeto é monitorada através do acompanhamento das não conformidades, da ação corretiva determinada, desde à sua requisição até à resolução, incluindo possíveis mudanças de responsáveis e prazos das não conformidades. GPR11 depende de GPP1: A análise da viabilidade do negócio ao longo da execução do projeto (GPR11) recebe subsídios da analise da viabilidade do portfólio (GPP1) existente na organização, no cenário o qual um portfólio é instanciado como um projeto. Durante o processo de seleção de um projeto a ser executado, a Gerência de Portfólio faz uma análise de viabilidade dos projetos pretendidos. Esta análise é utilizada, posteriormente, durante a execução do projeto na análise de viabilidade do Projeto em execução. GPR7 depende de GPP3: É necessário que a responsabilidade e autoridade pelo gerenciamento do projeto sejam estabelecidas (GPP3) para que este recurso seja alocado dentro do planejamento de recursos do projeto (definido no resultado esperado de gerência de projetos número 7). Para cada um dos projetos que tenha sido selecionado e priorizado, deve ser identificado o profissional que será responsável pelas atividades de gerenciamento do projeto, ou seja, que exercerá o papel de Gerente do Projeto.

35 24 GPR10 depende de GPP4: A definição do uso de recursos no Plano de Projeto (GPR10) é feita com base na disponibilidade ou liberação do recurso alocado para diferentes projetos (GPP4). Durante o processo de planejamento do uso de recursos em um projeto, o responsável por este planejamento verifica os recursos disponíveis e o seu uso pelos outros projetos através da Gerência de Portfólio. 4.3 Ferramentas Definidas Para cada processo constante nos níveis de maturidade G e F, foram definidas ferramentas de software livre, sendo ou não open source, para sistematizar sua implementação. Várias ferramentas foram estudadas dentro do projeto SPIDER, e seus estudos aprofundados são tratados em sub-projetos diferentes, classificados em áreas de processo. Neste trabalho será fornecida uma visão geral de cada ferramenta escolhida e que serão usadas no trabalho de integração da SUITE, discutido no Capítulo 5. Na maioria dos processos não foram encontradas ferramentas que atendessem completamente aos resultados esperados do MPS.BR, portanto foi necessário adotar duas ou mais ferramentas em conjunto. Em alguns casos, a escassez de ferramentas de software livre levou os pesquisadores do projeto a criarem ferramentas que atendessem às recomendações do modelo MPS.BR, como é o caso dos processos de Medição e Garantia da Qualidade.

36 dotproject Criado pela dotmarketing.org com o intuito de ser uma alternativa contra ferramentas comerciais como o Project da Microsoft. Ao longo dos anos esta ferramenta evoluiu e sofreu várias mudanças, inclusive na sua administração, que hoje é feita pela SlackHat. Pode ser encontrada em [dotproject, 2009]. Esta ferramenta web de gerenciamento de projetos é independe de plataforma e acessada via browser por mais de um usuário ao mesmo tempo. Foi construída em linguagem PHP e usa base de dados MySQL ou PostGreeSQL. Seus requisitos de instalação são: servidor web APACHE com integração à linguagem de programação PHP e um sistema de banco de dados MySQL ou PostGreeSQL. No site oficial é possível encontrar uma versão de demonstração. Para o projeto SPIDER, esta ferramenta será utilizada principalmente para obter o comprometimento com os usuários através de seus fóruns e dar visibilidade dos ativos constantes no planejamento do projeto. Outras funções/operações vão ser customizadas na ferramenta para que esta possa atender ao modelo, como por exemplo a lista de bugs no Trac. Esta ferramenta, além de ser utilizada para os fins de Gerência de Projetos, será customizada para atender aos objetivos do processo Gerência de Portfólio de Projetos. Esta área de processo não possui ferramentas específicas para prover a sistematização dos seus resultados esperados, então foram feitas adaptações dentro do dotproject para que seus resultados esperados fossem atendidos. Estas customizações são alvo de outro sub-projeto dentro do Projeto SPIDER OPENPROJ O Openproj (disponível em é uma ferramenta de gerenciamento de projeto open source criado pela empresa Serena Software e atualmente mantido pela comunidade de software livre. Desenvolvido na linguagem Java para Desktop, possui uma grande quantidade de funcionalidades, focando todas no papel do gerente de projetos, também é compatível com a ferramenta comercial mais conhecida no mercado, o Microsoft Project.

37 26 Suas principais funções são acompanhamento de projetos em execução, controle de tarefas, visualização de gráficos de Gantt, WBS (Work Breakdown Structure chart), entre outros, calendário, controle de recursos humanos e materiais. Porém possui como ponto fraco, a impossibilidade de ser multiusuário, bem como a capacidade de carregar apenas um projeto por vez, em cada instância de execução da ferramenta. No projeto SPIDER, esta ferramenta foi definida para ser utilizada pelo gerente de projetos, que terá uma visão geral de cada projeto, foi escolhida por atender, sem qualquer customização, grande parte dos resultados esperados do processo de Gerência de Projetos, o restante dos resultados esperados serão atendidos através da customização desta ferramenta, da utilização e customização do dotproject e utilização da ferramenta Trac, que serão apresentados em seguida OSRMT Criado em 2006 por Aron Smith, o OSRMT (Open Source Requirements Management Tool, disponível em é uma ferramenta open source de gerenciamento de requisitos, desenvolvida sob linguagem Java, com suporte a banco de dados. Permite sua utilização em rede ou desktop, entre suas principais funcionalidades destaca-se a possibilidade de categorizar os requisitos, gerar e visualizar matrizes de rastreabilidade e análise gráfica de dependência (impacto) entre requisitos. Entre as ferramentas pesquisadas para atender ao processo de Gerência de Requisitos, o OSRMT foi identificado como a que mais aproximava-se das necessidades deste processo sem grandes customizações, trabalhando em conjunto com outras ferramentas como o dotproject, Mantis, Trac e Spider-CL Mantis O Mantis (disponível em é uma ferramenta de controle de não conformidades, desenvolvido em linguagem PHP, sob licença GPL, para gerenciar as ocorrências de bugs em um software. É executado através de uma página web, com suporte a perfis de usuários, controle de múltiplos projetos, e definições de prioridades, além de ser customizável através da própria aplicação.

38 27 Foi definido para utilização durante a implementação do processo de Gerência de Configuração, atuando como uma ferramenta de controle de mudanças, conduzindo uma modificação da solicitação até a confirmação de sua implementação, mantendo todos os interessados informados sobre o estado de cada solicitação. Também atende aos processos de Gerência de Projetos, Gerência de Requisitos e Garantia da Qualidade, com relação aos resultados esperados que tratem de registro e acompanhamentos de problemas e não conformidades Trac O Trac (disponível em é uma ferramenta open source baseada em wiki desenvolvida em linguagem python, com a função de realizar o gerenciamento de bugs. Seus diferenciais são a utilização de marcos de projeto e a função de roadmap, para verificar o andamento de um projeto, além de permitir referências a arquivos, bugs, tarefas através da formatação wiki. Assim como o Mantis, é uma ferramenta de controle de mudanças que integrará ao projeto como uma possibilidade de escolha, pois possui integração nativa com a ferramenta Subversion, necessária para atender completamente ao processo de Gerência de Configuração, bem como outros sistemas de controle de versões Subversion O Subversion (disponível em é uma ferramenta de controle de versão mantido pela Tigris.org, considerada pela comunidade de software livre uma das melhores soluções para gerenciamento de mudanças de arquivos. Suas principais características são a possibilidade de realizar controle de versão tanto de diretórios, quanto de arquivos dos tipos texto ou binário e permitir a ramificação de projetos, além de um eficiente controle de concorrência. Permite sua utilização através de linha de comando, ambiente gráfico desenvolvido por terceiros ou Ambiente de Desenvolvimento Integrado com suporte a controle de versões. Foi selecionado como uma primeira opção de um sistema de controle de versão para o projeto SPIDER, devido sua robustez no tratamento de concorrência e grande utilização no

39 28 cenário das organizações, atendendo às necessidades do processo de Gerência de Configuração, em conjunto com as ferramentas Trac ou Mantis e Spider-CL CVS O CVS (Control Version System, disponível no endereço: criado em 1986 por Dick Grune, é um sistema de controle de versões atualmente desenvolvido na linguagem C, e mantido sob a licença GPL pela Free Software Foundation. Tem como principais funcionalidades a possibilidade de permitir o controle de acesso aos arquivos e registrar o histórico de modificações, armazenando todas as versões de um produto de trabalho, assim como a data das alterações e o usuário que realizou. Permite seu acesso através de linha de comando, ambiente gráfico ou Ambiente de Desenvolvimento Integrado. No projeto SPIDER, foi definido como uma segunda possibilidade para um sistema de controle de versões, devido sua robustez e grande utilização em inúmeras empresas, evitando possíveis migrações desnecessárias, trabalhando em conjunto com as ferramentas Mantis e Spider-CL SPIDER-MPlan A partir da análise da aderência de diversas ferramentas, que possam ser utilizadas como apoio ao processo medição contido no MPS.BR, foi identificada a necessidade de desenvolvimento de uma nova ferramenta, a qual sistematizasse todo o processo de medição e pudesse atender a todos os resultados esperados do MPS.BR. Outro fator preponderante também percebido foi o alto custo e o baixo (ou quase inexistente) acesso ao código fonte de tais ferramentas existentes, fato este que limita muito a customização e manipulação de alguns aspectos importantes. [ESTACIO, 2009] Desta forma, a ferramenta Spider-MPlan, que trata-se de uma ferramenta em fase de desenvolvimento, que surge como uma proposta de software livre, o qual visa auxiliar de forma promissora a implementação do processo de medição do nível F do modelo do MPS.BR, integrando ao SUITE de ferramentas definidos no projeto SPIDER.

40 SPIDER-QA Tem como objetivo ajudar empresas que fazem uso do processo de garantia de qualidade com uma ferramenta que atenda os resultados esperados do MPS-BR. Atualmente ainda não existem as ferramentas voltadas para este programa de melhoria, sendo, portanto um diferencial da mesma o fato de estar totalmente em conformidade com o processo de garantia de qualidade proposto. A ferramenta Spider QA auxilia na detecção de não conformidades, permitindo que para cada disciplina ou produto de trabalho passível de auditagem, seja cadastrado um checklist com os critérios objetivos que deverão ser usados durante a auditoria. Também permite gerar um plano de ação, para nortear as correções das não conformidades encontradas, bem como, para cada ação do plano, cadastrar o prazo e o responsável. [TELES, 2009] Trata-se de uma ferramenta em fase de desenvolvimento, com uma proposta de ser um software livre, visando auxiliar a implementação do processo de garantia da qualidade do nível F do modelo do MPS.BR, integrando ao SUITE de ferramentas definidos no projeto SPIDER SpiderCL Com a falta de ferramentas que auxiliem a avaliação a partir de critérios objetivos, constantes em checklists, usadas nos processos de Gerência de Requisitos, Gerência de Configuração e Medição, esta ferramenta foi desenvolvida dentro do Projeto SPIDER. Está disponível no seguinte endereço: Seu ambiente é desenvolvido em Java e possui recursos para criação de checklists novos quanto reaproveitamento de outros checklists. Pode imprimir e armazenar os dados na própria ferramenta, além de exportar relatórios no formato PDF [BARROS, 2009].

41 30 Sua aplicação dentro do Projeto SPIDER, após desenvolvida, se estendeu a outras áreas de processo, como Gerência de Portfólio de Projetos e Garantia da Qualidade. 4.4 Considerações Finais Neste capítulo foi apresentado de forma breve o Projeto SPIDER, as ferramentas utilizadas para compor sua SUITE e os mapeamentos feitos durante a fase de pesquisa do projeto quanto à dependência entre Resultados Esperados de diferentes processos. Estas dependências serão expostas novamente no próximo capítulo analisando agora uma forma de implementação integrada das ferramentas, quando possível. No próximo capítulo, também, será proposta uma metodologia de uso das ferramentas apresentadas neste capítulo de forma a integrar suas operações em um SUITE consistente e flexível, visto que o Projeto SPIDER não se propõe a mudar os processos nas empresas, mas sim adaptar o uso das ferramentas ao processo já existente.

42 31 5 METODOLOGIA PARA A INTEGRAÇÃO DA IMPLEMENTAÇÃO DOS PROCESSOS No último capítulo foram abordadas as ferramentas selecionadas para compor a SUITE de Ferramentas do Projeto SPIDER. Neste capítulo será mostrada uma proposta de integração dessas ferramentas. Essa integração é baseada nos mapeamentos de dependências entre os resultados esperados do MPS.BR. Há casos em que não há integração, visto que requer decisões da organização ou fazem parte da metodologia de uso da organização. Como foi dito anteriormente, este trabalho não visa mudar a cultura dentro da organização, e sim auxiliar de forma flexível no processo de implementação do modelo de maturidade estudado. 5.1 Categorias de Integração entre Ferramentas As integrações de ferramentas foram classificadas, como um dos quatro tipos, segundo [JORGENSEN, 1994], mais comumente encontrados na literatura: são elas: dados, apresentação, controle e processo. Cada categoria de integração possui suas próprias características, apresentadas na Figura 5.1.

43 32 Figura Propriedades das categorias de integração [OLIVERA, 2001] A seguir cada uma destas categorias são apresentadas sucintamente segundo [JORGENSEN. 1994]: 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. Para obter a integração de apresentação as ferramentas podem compartilhar a mesma biblioteca de interface com o usuário; 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

44 33 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), ferramenta-serviç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. Esta categoria de integração é encontrada em ambientes de desenvolvimento de software orientados a processos. As integrações identificadas neste trabalho têm por sua maioria a classificação controle, fazendo uso da comunicação entre ferramentas. No trabalho como um todo até o momento integração entre os resultados esperados dos processos constantes nos níveis G e F foram identificadas também integrações do tipo apresentação e dados. Em outros casos, a integração não se faz interessante, visto que poderá automatizar excessivamente a implementação do MPS.BR, desvirtuando o objetivo do projeto de manter a flexibilidade de implementação do processo e de manter o controle de decisões nas pessoas envolvidas e não deixá-las a cargo do sistema. Para tanto foi definido para estas integrações a categorização uso de metodologia, no qual é apresentada uma possível maneira de realizar esta integração, porém ficando a critério da empresa, utilizá-la ou adaptá-la à sua própria metodologia.

45 Mapeamento das Ferramentas Integradas Considerando os mapeamentos levantados e as ferramentas descritas no capítulo anterior, esta seção propõe um conjunto de integrações visando atender da melhor forma possível os resultados esperados do MPS.BR GCO1 x GPR8 Um sistema de Gerência de Configuração é um recurso necessário para o desenvolvimento de software quando o processo de GCO está implantado, logo, este recurso deve constar no plano de recursos. Dentro da proposta do Projeto SPIDER, o planejamento dos recursos e o ambiente de trabalho necessários para executar o projeto (GPR8), é implementado através do OpenProject com o cadastro de recursos. Para alcançar esta integração do tipo Controle, um botão será fornecido com um link dentro do OpenProject para o Plano de Gerência de Configuração na WIKI da ferramenta de Gerência de Configuração, conforme mostra a figura 5.2 abaixo. Quando for utilizado pela primeira vez, o link deve solicitar o caminho para a página da WIKI de Gerência de Configuração, guardando este link para posteriores consultas. Figura Menu de Plano de Gerência de Configuração.

46 GCO1 x GPR10 As informações relativas ao estabelecimento e manutenção do sistema de configuração (GCO1) devem ser registradas no plano do projeto, que reúne todos os planos específicos do projeto (GPR10). O Plano de Projeto é implementado no Openproject, seguindo a proposta do Projeto SPIDER, através de seus relatórios e informações diversas sobre o projeto. Para aderir a essa integração, é necessário apenas um link para o Plano de Gerência de Configuração. A integração para este mapeamento é feita da mesma forma como na seção anterior GCO2 x GPR2 Os produtos de trabalho gerados dependem diretamente da definição do que é tratado como item de configuração. Dentro do Plano de Gerência de Configuração são definidos os Itens de Configuração, que servem de base para definir os produtos de trabalho que serão dimensionados e gerados ao longo do projeto. Para implementar esta integração de Controle será fornecido um link dentro do OpenProject, onde os produtos de trabalho dimensionados são descritos, para os itens de configuração na WIKI, o mesmo link dos itens anteriores é válido para evidenciar a integração destes resultados esperados GCO4 x GPR11 Quando uma alteração ocorre em um item de configuração, ajustes pertinentes, baseados na rastreabilidade entre artefatos, devem ser realizados. As análises de alterações feitas em itens de configuração geram documentos feitos por auditorias físicas do processo de GCO. Estas auditorias servem de base para a análise de viabilidade do projeto. Para esta integração de Controle, um link para o repositório de auditorias do processo de GCO será customizado no Openproject, conforme apresentado na Figura 5.3.

47 36 Figura Menu de Auditorias de Gerência de Configuração GCO5 x GRE5 As alterações de requisitos devem ser monitoradas e acompanhadas ao longo de todo o projeto, e podem impactar de várias formas no mesmo, portanto, estas alterações precisam ser aprovadas pelo Comitê de Controle de Configuração que analisará este impacto e a viabilidade da modificação. As mudanças de requisitos gerenciadas ao longo do projeto (GRE5), seguindo a proposta do Projeto SPIDER, serão implementadas criando tickets ou issues na ferramenta de controle de mudança Mantis ou Trac, dispensando integração com o processo de GCO GCO5 x GQA4 Ao realizar uma ação corretiva para uma não conformidade, e ser realizada a implementação de uma modificação, deve ocorrer uma atualização da baseline. Na proposta do projeto SPIDER, esta integração está sendo feita dentro da ferramenta de apoio ao processo de GQA, em desenvolvimento pelo grupo de alunos do Projeto SPIDER GCO6 x GPR9 A forma como os dados relevantes do projeto devem ser controlados, armazenados e distribuídos, deve considerar o processo descrito pelo processo de GCO, quando este estiver

48 37 implementado, caso contrário, estas formas devem ser definidas pela Gerência de Projetos. Para esta integração de Controle, será fornecido um link dentro do OpenProj para o Plano de Gerência de Configuração na WIKI, conforme apresentado na Figura GCO6 x MED6 O sistema de armazenamento indicará onde e como os artefatos contendo os dados e os resultados de análises deverão ser armazenados. O sistema do processo de GCO tem por objetivo armazenar e disponibilizar, bem como definir políticas de acesso, aos artefatos de medição gerados. Os relatórios de Medição devem ser colocados no sistema de armazenamento do processo de GCO. Para atender a esta integração de controle, um link dentro da ferramenta de apoio ao processo de Medição para o plano de Gerência de Configuração será criado, conforme mostra a figura 5.4. A ferramenta de apoio ao processo de Medição está em construção pelo grupo do projeto SPIDER GCO7 x GPR13 As auditorias realizadas para acompanhamento do projeto incluem as auditorias físicas e funcionais do processo de Gerência de Configuração. Links para as auditorias física e funcional do processo GCO deverão ser disponibilizados na interface da ferramenta OpenProj, a qual já possui o Plano de Projeto. Será acrescido o item Auditorias no menu Exibir, da ferramenta OpenProj, direcionando para o diretório de auditorias no repositório. Será usado para esta integração o mesmo link apresentado na Figura 5.2.

49 38 Figura Protótipo de Medição com a seleção dos itens de configuração MED3 x GPR8 Dentro da proposta do Projeto SPIDER, será utilizada uma ferramenta para a equipe de Medição, onde serão cadastradas as informações sobre os procedimentos de coleta e armazenamento de medidas. Esta ferramenta deve constar no planejamento de recursos e ambiente de trabalho do projeto. Para atender a esta integração do tipo Controle, a ferramenta de apoio ao processo de Gerência de Projetos, OpenProj, deverá ser customizada, adicionando-se no menu Exibir, a opção de acesso ao Plano de Medição, como mostra a Figura 5.5. Esta opção trata-se de um link para a ferramenta de apoio ao processo de Medição SPIDER-Mplan, que será configurado durante a instalação da ferramenta OpenProj GCO2 x MED3 Antes de definir os procedimentos utilizados na coleta e armazenamento de medidas, é necessário haver uma definição de quais são os itens que estarão sob configuração. Esta integração, do tipo Controle, é prevista pela ferramenta SPIDER-Mplan, e será atendida através do acréscimo de um link e um campo do tipo textfield durante o cadastro de um procedimento de coleta, como mostra o a Figura 5.6. O link abrirá o diretório de itens de configurações definidos no repositório, e esta visualização será um consulta para inseri-los juntamente com a versão que será considerada, no cadastro deste procedimento de coleta. Poderão ser incluídos mais de um Item de Configuração neste campo separando-os pelo símbolo ponto e vírgula.

50 39 Figura Menu de acesso ao plano de medição na ferramenta Openproj. Figura Cadastro de procedimentos de coleta da ferramenta SPIDER-Mplan MED4 x GPR10 Os procedimentos de análise do processo de Medição, como a definição da freqüência, responsável, fase, dados de origem, ferramenta utilizada e verificações das coletas devem estar elicitados no Plano de Projeto.

51 40 Esta integração do tipo Controle é atendida, da mesma forma que o descrito na seção , através de um sub-menu na ferramenta OpenProj, chamado Plano de Medição, que executará a ferramenta SPIDER-MPlan, exemplificado na Figura MED7 x GPR11 A gerência do processo de Medição informará às gerências responsáveis sobre análises de medição que sejam relevantes para mudanças de decisões. Esta integração, também do tipo Controle, é atendida através da customização da ferramenta OpenProj, no qual, durante a confirmação da análise de viabilidade de um projeto, será apresentada uma referência para as análises de medições na ferramenta SPIDER-Mplan, mostrado na figura 5.7. Durante o registro do relatório de análise de viabilidade, é importante que o Gerente de Projetos deixe claro, de forma textual, que as análises de medições foram realizadas e que está ciente desta ação. Figura 5.7- Customização da análise de viabilidade na ferramenta OpenProj GQA1 x GRE1 A aderência do documento de requisitos aos padrões aplicáveis deve ser levada em conta antes mesmo da avaliação e aceitação dos requisitos de software. Integração do tipo Controle, ao acessar a tela de avaliação e aceitação de requisitos será disponibilizado um link para acessar os resultados de avaliação do documento de requisitos conforme os padrões estabelecidos.

52 41 Figura 5.8 Link para os resultados de avaliação do documento de requisitos GQA4 x GPR13 A execução do projeto é monitorada através do acompanhamento das não conformidades, e da ação corretiva determinada. Outra integração do tipo Controle, que é atendida, assim como a integração descrita na seção 5.2.4, através do sub-menu Auditorias, no item Garantia da Qualidade, como pode ser visualizado na Figura 5.9. Este item de menu executará a abertura do repositório, mais

53 42 especificamente no diretório dos relatórios de auditorias do processo de GQA, gerados em formato PDF pela ferramenta SPIDER-CL. Figura Menu para visualização das auditorias de garantia da qualidade GPP1 x GPR11 Durante o processo de seleção de portfólio para torná-lo um projeto a ser executada, os responsáveis pelo processo de Gerência de Portfólio fazem uma análise de viabilidade dos projetos pretendidos. Esta análise é utilizada, posteriormente, durante a execução do projeto na análise de viabilidade do projeto em execução. Para atender a este resultado esperado do tipo Controle, foi proposta uma customização do OpenProj semelhante ao descrito na seção , no qual há um link para os relatórios de análises de viabilidade do processo de GPP, no qual o Gerente de Projetos deve manifestar seu acordo na forma textual GPP3 x GPR7 Para cada um dos projetos que tenha sido selecionado e priorizado, deve ser identificado o profissional que será responsável pelas atividades de gerenciamento do projeto, ou seja, que exercerá o papel de Gerente do Projeto.

54 43 Esta integração é atendida através de metodologia, no qual um projeto aprovado em sua primeira avaliação no processo de GPP necessitará de um Gerente de Projetos para iniciar sua execução. Para tanto, serão criadas instâncias deste novo projeto tanto no OpenProj, quanto no DotProject, já relacionando-o ao Gerente de Projeto GPP4 x GPR10 Durante o processo de planejamento do uso de recursos em um projeto, o responsável por este planejamento verifica os recursos disponíveis e o seu uso pelos outros projetos através do processo de Gerência de Portfólio. Esta integração, como as anteriores, do tipo Controle, é atendida ao se disponibilizar uma forma de ligação entre os resultados esperados. Neste caso, deverá ser apresentado na ferramenta OpenProj um sub-menu de Exibir denominado Gerência de Negócios, que executará o DotProject, na tela de Gerência de Recursos entre projetos (figura 5.10). Figura Menu para visualização das área de Gerência de Negócios. 5.3 Considerações Finais Este capítulo apresentou a forma como cada dependência entre resultados esperados será implementada no projeto SPIDER, identificando customizações em ferramentas e aplicações de metodologias necessárias. Tais adaptações são essenciais tanto para que a