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

U

NIVERSIDADE

F

EDERAL DO

P

ARÁ

I

NSTITUTO DE

C

IÊNCIAS

E

XATAS E

N

ATURAIS

F

ACULDADE DE

C

OMPUTAÇÃO

C

URSO DE

B

ACHARELADO EM

C

IÊNCIA DA

C

OMPUTAÇÃO

T

RABALHO DE

C

ONCLUSÃO DE

C

URSO

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

U

NIVERSIDADE

F

EDERAL DO

P

ARÁ

I

NSTITUTO DE

C

IÊNCIAS

E

XATAS E

N

ATURAIS

F

ACULDADE DE

C

OMPUTAÇÃO

C

URSO DE

B

ACHARELADO EM

C

IÊNCIA DA

C

OMPUTAÇÃO

T

RABALHO DE

C

ONCLUSÃO DE

C

URSO

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

“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

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.

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

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.

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.

1 Introdução ... 12 1.1 Contexto do Trabalho ... 12 1.2 Justificativa ... 12 1.3 Motivação ... 13 1.4 Objetivos ... 13 1.5 Metodologia ... 13 1.6 Estrutura ... 14

2 Uma Visão Geral do MPS.BR ... 16

2.1 Histórico ... 16

2.2 Definição e Composição do Modelo MPS.BR ... 17

2.3 Guias do MPS.BR ... 19

2.4 Níveis de Maturidade do MPS.BR ... 20

2.5 Considerações Finais ... 22

3 Nível G do MPS.BR: Uma Visão Geral ... 23

3.1 Objetivos ... 23

3.2 Gerência de Projetos no MPS.BR ... 24

3.2.1 Resultados Esperados de Gerência de Projetos ... 26

3.3 Gerência de Requisitos no MPS.BR ... 27

3.3.1 Resultados Esperados de Gerência de Requisitos ... 28

3.4 Considerações Finais ... 33

4 Proposta de Integração dos Processos do Nível G ... 34

4.1 Projeto SPIDER ... 34

4.2 Mapeamento dos Resultados Esperados ... 35

4.2.1 GPR 1 x MED 1 ... 36

4.2.2 GPR 5 x GCO 3 ... 36

4.2.3 GPR 6 x GQA 4 ... 36

4.2.6 GPR 11 x GPP 1 ... 37 4.2.7 GPR 11 x GPP 5 ... 37 4.2.8 GPR 17 x GQA 4 ... 38 4.2.9 GPR 17 x GPP 4 ... 38 4.2.10 GRE 1 x GPR 1 ... 38 4.2.11 GRE 1 x GPR 2 ... 38 4.2.12 GRE 1 x GPR 3 ... 39 4.2.13 GRE 1 x GPR 5 ... 39 4.2.14 GRE 1 x GPR 11 ... 39 4.2.15 GRE 1 x GCO 7... 39 4.2.16 GRE 2 x GPR 12 ... 39 4.2.17 GRE 3 x GPR 5 ... 40 4.2.18 GRE 3 x GPR 6 ... 40 4.2.19 GRE 4 x GPR 10 ... 40

4.3 Relações Resultantes entre os Processos oriundas dos Mapeamentos entre Resultados Esperados ... 40

4.4 Definição das Ferramentas... 41

4.4.1 Ferramentas de Software Livre para Apoio aos Processos do Nível F e G do MPS.BR . 42 4.5 Considerações Finais ... 47

5 Metodologia Para Integração da Implementação dos Processos ... 48

5.1 Categorias de Integração entre Ferramentas Case ... 48

5.1.1 Integração de Apresentação ... 48

5.1.2 Integração de Dados ... 49

5.1.3 Integração de Controle ... 49

5.1.4 Integração de Processo ... 49

5.2 Proposta de Integração Ferramental ... 50

5.2.3 GPR 6 x GQA 4 ... 54 5.2.4 GPR 9 x GCO 2 ... 55 5.2.5 GPR 10 x GPP 2 ... 56 5.2.6 GPR 11 x GPP 1 ... 57 5.2.7 GPR 11 x GPP 5 ... 58 5.2.8 GPR 17 x GQA 4 ... 58 5.2.9 GPR 17 x GPP 4 ... 59 5.2.10 GRE 1 x GPR 1 ... 60 5.2.11 GRE 1 x GPR 2 ... 61 5.2.12 GRE 1 x GPR 3 ... 63 5.2.13 GRE 1 x GPR 5 ... 63 5.2.14 GRE 1 x GPR 11 ... 63 5.2.15 GRE 1 x GCO 7... 64 5.2.16 GRE 2 x GPR 12 ... 65 5.2.17 GRE 3 x GPR 5 ... 66 5.2.18 GRE 3 x GPR 6 ... 68 5.2.19 GRE 4 x GPR 10 ... 68 5.3 Considerações Finais ... 68 6 Conclusão ... 70 6.1 Resumo do Trabalho ... 70 6.2 Resultados Obtidos ... 70 6.3 Trabalhos Futuros... 71 6.4 Lições Aprendidas ... 71 Referências Bibliográficas ... 72

LISTA DE FIGURAS

Figura 2.1: Componentes do MPS-BR (SOFTEX, 2009a)... 19

Figura 2.2: Níveis de maturidade do MPS.BR (SOFTEX, 2009a)... 22

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... 47

Figura 5.2: Escopo Disponibilizado pela Ferramenta OpenProj... 47

Figura 5.3: Cadastro de Projetos da Organização na ferramenta MPLAN... 48

Figura 5.4: Tarefa instanciada no OpenProj... 49

Figura 5.5: Task finalizada no dotProject: repositório de baselines... 49

Figura 5.6: Análise de Riscos Disponibilizada pela Ferramenta OpenProj... 50

Figura 5.7: Dados Relevantes do Projeto na Ferramenta OpenProj... 51

Figura 5.8: Recursos da Organização, na Ferramenta dotProject ... 52

Figura 5.9: Recursos do Projeto, na Ferramenta OpenProj... 53

Figura 5.10: Análise de Viabilidade do Projeto no dotProject... 54

Figura 5.11: Verificar Alocação de Recursos na Ferramenta dotProject... 55

Figura 5.12: Ticket Criado na Ferramenta Trac... 56

Figura 5.13: Detalhes dos Requisitos no OSRM... 57

Figura 5.14: Aba na Ferramenta OpenProj para Exibir Dados dos Requisitos Aceitos.... 58

Figura 5.15: Requisitos Aceitos do Projeto na Ferramenta OSRMT... 59

Figura 5.16: Confirmação de Viabilidade do Projeto na Ferramenta OpenProj... 61

Figura 5.17: Criação de um checklist na Ferramenta SPIDER-CL... 62

Figura 5.18: Obtenção do Comprometimento dos Envolvidos ao Plano do Projeto na Ferramenta OpenProj... 63

Figura 5.19: Aba na Ferramenta OpenProj para Direcionar para a Rastreabilidade Bidirecional... 64

Figura 5.20: Rastreabilidade Bidirecional de Requisitos e Produtos de Trabalho na Ferramenta OSRMT... 64

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 15504 (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.

1.3 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,

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.

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.

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 12207 – Processo de Ciclo de Vida de Software (SOFTEX, 2009a); • ISO/IEC 12207, emendas 1 e 2 da norma internacional (SOFTEX, 2009a);

• ISO/IEC 15504 – 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 2.2.

2.1 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

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 15504 (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.

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 15504-2 (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 15504-2 (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

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:2009 - 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:2009 - 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:2009 - 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,

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.

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

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.

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 3.4.

3.1 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

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: 60 – 100x.

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 3.3.

3.2 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.

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 3.2.1.

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.

3.2.1 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;

• 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

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.

3.3.1 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;

3.3.2 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.

3.3.2.1 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;

• 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.

3.3.2.2 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.

3.3.2.3 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

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.

3.3.2.4 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.

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.

3.3.2.5 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;

• MED 4. Os procedimentos para a análise das medidas são especificados; • 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.

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

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.

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 4.2.1 está contemplado pelo resultado esperado MED1 do processo de Medição.

4.2.1 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.

4.2.2 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. 4.2.3 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).

• Implementação Conjunta: A tomada de decisão para correção de uma não-conformidade 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.

4.2.4 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.

4.2.5 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.

4.2.6 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.

4.2.7 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.

4.2.8 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.

4.2.9 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.

4.2.10 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.

4.2.11 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.

4.2.12 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.

4.2.13 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.

4.2.14 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.

4.2.15 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.

4.2.16 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).

• 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.

4.2.17 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.

4.2.18 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.

4.2.19 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.

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

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 http://www.ufpa.br/SPIDER/index.php?id=resultados.

4.4.1 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.

4.4.1.1 OpenProj

O OpenProj (disponível para download em

http://sourceforge.net/projects/openproj/files/) é 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