U INTEGRAÇÃO DOS R SPERADOS DO ÍVEL DO...

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

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


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

I

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

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.


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

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.

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.

VI

SUMÁRIO

1. INTRODUÇÃO ................................................................................................................... 1

1.1. Contexto do Trabalho ........................................................................................................ 1

1.2. Justificativa .......................................................................................................................... 1

1.3. Motivação ............................................................................................................................. 2

1.4. Objetivos ............................................................................................................................... 2

1.5. Metodologia ......................................................................................................................... 3

1.6. Estrutura ............................................................................................................................... 3

2. UMA VISÃO GERAL DO MPS.BR ....................................................................................... 5

2.1. Histórico da Qualidade de Software .............................................................................. 5

2.2. Definição e Composição do Modelo de Maturidade ................................................. 6

2.3. Níveis de Maturidade ......................................................................................................... 8

2.4. Considerações Finais...................................................................................................... 10

3. NÍVEL F DO MPS.BR ...................................................................................................... 12

3.1. Objetivos ............................................................................................................................. 12

3.2. Finalidade ........................................................................................................................... 13

3.3. Gerência de Configuração ............................................................................................. 14

3.4. Garantia da Qualidade .................................................................................................... 15

3.5. Medição ............................................................................................................................... 16

3.6. Gerência de Portfólio ...................................................................................................... 16

3.7. Aquisição ............................................................................................................................ 17


4. PROPOSTA DE INTEGRAÇÃO DO NÍVEL F .......................................................................... 19

4.1. O Projeto SPIDER ............................................................................................................. 19

4.2. Mapeamento dos Resultados Esperados .................................................................. 20

4.3. Ferramentas Definidas .................................................................................................... 24

4.3.1. dotProject ....................................................................................................................... 25

VII

4.3.2. OPENPROJ ..................................................................................................................... 25

4.3.3. OSRMT ............................................................................................................................ 26

4.3.4. Mantis .............................................................................................................................. 26

4.3.5. Trac .................................................................................................................................. 27

4.3.6. Subversion ..................................................................................................................... 27

4.3.7. CVS ................................................................................................................................... 28

4.3.8. SPIDER-MPlan ............................................................................................................... 28

4.3.9. SPIDER-QA ..................................................................................................................... 29

4.3.10. SpiderCL ..................................................................................................................... 29


5. METODOLOGIA PARA A INTEGRAÇÃO DA IMPLEMENTAÇÃO DOS PROCESSOS .................... 31

5.1. Categorias de Integração entre Ferramentas ........................................................... 31

5.2. Mapeamento das Ferramentas Integradas ................................................................ 34

5.2.1. GCO1 x GPR8 ................................................................................................................ 34

5.2.2. GCO1 x GPR10 .............................................................................................................. 35

5.2.3. GCO2 x GPR2 ................................................................................................................ 35

5.2.4. GCO4 x GPR11 .............................................................................................................. 35

5.2.5. GCO5 x GRE5 ................................................................................................................ 36

5.2.6. GCO5 x GQA4 ................................................................................................................ 36

5.2.7. GCO6 x GPR9 ................................................................................................................ 36

5.2.8. GCO6 x MED6 ................................................................................................................ 37

5.2.9. GCO7 x GPR13 .............................................................................................................. 37

5.2.10. MED3 x GPR8 ............................................................................................................ 38

5.2.11. GCO2 x MED3 ............................................................................................................ 38

5.2.12. MED4 x GPR10 .......................................................................................................... 39

5.2.13. MED7 x GPR11 .......................................................................................................... 40

5.2.14. GQA1 x GRE1 ............................................................................................................ 40

VIII

5.2.15. GQA4 x GPR13 .......................................................................................................... 41

5.2.16. GPP1 x GPR11 ........................................................................................................... 42

5.2.17. GPP3 x GPR7 ............................................................................................................. 42

5.2.18. GPP4 x GPR10 ........................................................................................................... 43


6. CONCLUSÃO .................................................................................................................. 45

6.1. Resumo do Trabalho ....................................................................................................... 45

6.2. Resultados Obtidos e Trabalhos Futuros .................................................................. 45

6.2.1. Elaboração de um Artigo ............................................................................................ 47

6.2.2. Aderência ao Modelo CMMI ....................................................................................... 47

6.2.3. Implementação das Customizações Sugeridas ................................................... 48

6.2.4. Estender o Mapeamento para os Níveis Seguintes do MPS.BR ...................... 48

6.3. Lições Aprendidas ........................................................................................................... 48

Referências Bibliográficas ................................................................................................ 49

IX

LISTA DE FIGURAS

Figura 2.1 – Estrutura do programa MPS.BR [SOFTEX, 2009a]. ....................................... 7

Figura 5.1 - Propriedades das categorias de integração [OLIVERA, 2001] .................... 32

Figura 5.2 - Menu de Plano de Gerência de Configuração. ............................................. 34

Figura 5.3 - Menu de Auditorias de Gerência de Configuração. ..................................... 36

Figura 5.4 - Protótipo de Medição com a seleção dos itens de configuração. .............. 38

Figura 5.5 - Menu de acesso ao plano de medição na ferramenta Openproj................. 39

Figura 5.6 - Cadastro de procedimentos de coleta da ferramenta SPIDER-Mplan. ....... 39

Figura 5.7- Customização da análise de viabilidade na ferramenta OpenProj. ............. 40

Figura 5.8 – Link para os resultados de avaliação do documento de requisitos. ......... 41

Figura 5.9 - Menu para visualização das auditorias de garantia da qualidade. ............. 42

Figura 5.10 - Menu para visualização das área de Gerência de Negócios. .................... 43

Figura 6.1 - Gráfico de Estatística de Dependências. ...................................................... 46

Figura 6.2 - Gráfico de estatística de Tipos de Integração. ............................................. 47

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 15504 e ISO/IEC 12207 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.

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

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

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

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.

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.

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.

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

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

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

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,

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

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.

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

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;

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;

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.

16

3.5 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

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.


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

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.

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.

20

4.2 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

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.

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

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.

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.

25

4.3.1 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 http://www.dotproject.net [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.

4.3.2 OPENPROJ

O Openproj (disponível em http://openproj.org/openproj) é 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.

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.

4.3.3 OSRMT

Criado em 2006 por Aron Smith, o OSRMT (Open Source Requirements Management

Tool, disponível em http://sourceforge.net/projects/osrmt/) é 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.

4.3.4 Mantis

O Mantis (disponível em http://www.mantisbt.org/) é 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.

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.

4.3.5 Trac

O Trac (disponível em http://trac.edgewall.org/) é 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.

4.3.6 Subversion

O Subversion (disponível em http://subversion.tigris.org/) é 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

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.

4.3.7 CVS

O CVS (Control Version System, disponível no endereço:

http://savannah.nongnu.org/projects/cvs), 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.

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

29

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

4.3.10 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: http://www.ufpa.br/spider/projetos/spider_cl/CL.war.

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

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.


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.

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.

32

Figura 5.1 - 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

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.

34

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

5.2.1 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 5.2 - Menu de Plano de Gerência de Configuração.

35

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

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

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

36

Figura 5.3 - Menu de Auditorias de Gerência de Configuração.

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

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

5.2.7 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

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

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

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

38

Figura 5.4 - Protótipo de Medição com a seleção dos itens de configuração.

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

5.2.11 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”.

39

Figura 5.5 - Menu de acesso ao plano de medição na ferramenta Openproj.

Figura 5.6 - Cadastro de procedimentos de coleta da ferramenta SPIDER-Mplan.

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

40

Esta integração do tipo Controle é atendida, da mesma forma que o descrito na seção

5.2.10, através de um sub-menu na ferramenta OpenProj, chamado Plano de Medição, que

executará a ferramenta SPIDER-MPlan, exemplificado na Figura 5.5.

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

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

41

Figura 5.8 – Link para os resultados de avaliação do documento de requisitos.

5.2.15 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

42

especificamente no diretório dos relatórios de auditorias do processo de GQA, gerados em

formato PDF pela ferramenta SPIDER-CL.

Figura 5.9 - Menu para visualização das auditorias de garantia da qualidade.

5.2.16 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 5.2.13, 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.

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

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.

5.2.18 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 5.10 - Menu para visualização das área de Gerência de Negócios.


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

44

implantação do projeto possa estar de acordo com os padrões de qualidades exigidos na

avaliação do MPS.BR, bem como para atingir seu objetivo principal: a sistematização da

implementação do modelo de qualidade brasileiro.

45

6 CONCLUSÃO

Neste capítulo serão explanadas as informações conclusivas deste trabalho, tais como o

resumo das atividades realizadas, apresentação de resultados obtidos, trabalhos futuros e

lições aprendidas.

6.1 Resumo do Trabalho

Para melhor entendimento do escopo da integração realizada, foi inicialmente

apresentado o objeto de estudo deste trabalho, o modelo de maturidade MPS.BR, desde o

histórico dos modelos de maturidades que o influenciaram, até o seu detalhamento com a

descrição de seu funcionamento e apresentação de cada nível de maturidade que compõem

este modelo.

Em seguida, houve um maior detalhamento do Nível F, que é o alvo de estudo deste

trabalho dentro do modelo MPS.BR, explicitando cada processo que compõem este nível e

listando seus resultados esperados.

Por conseguinte, apresentou-se o projeto SPIDER - no qual este trabalho está contido

como um subprojeto - que tem como principal objetivo definir um SUITE de ferramentas de

software livre, que apóiem a sistematização da implementação do MPS.BR. Foram também

apresentados os resultados da pesquisa deste trabalho, obtidos ao longo do seu

desenvolvimento, que consiste no relacionamento de dependências encontradas entre

resultados esperados de processos diferentes, para orientação durante o mapeamento da

integração entre as ferramentas definidas que sistematizarão a implementação dos processos

de níveis G e F no MPS.BR.

Finalmente, foram definidas e apresentadas as customizações necessárias a fazer nas

ferramentas, para que as integrações entre processos possam ser atendidas de forma

sistematizada, e de acordo com a proposta do projeto SPIDER.

6.2 Resultados Obtidos e Trabalhos Futuros

Como conseqüência deste trabalho, obteve-se uma planilha de consulta, com

informações a respeito da listagem do mapeamento de dependências encontradas entre os

46

resultados esperado dos níveis G e F do MPS.BR. A planilha de mapeamento contém, além

dos resultados esperados relacionados, uma justificativa a respeito da ocorrência de cada

dependência, além de uma forma de implementação conjunta dos resultados esperados

envolvidos, para ilustrar a justificativa. Após análise de todas as dependências, chegamos a

um gráfico de estatística da figura 6.1, onde nota-se que o Processo de GPR é o mais

dependente e o de GCO é o menos dependente. Os processos de GPR e GRE possuem zero no

Número de Resultados Esperados Base, pois o foco deste trabalho são os processos do Nível

F. A figura 6.2 ilustra a quantidade de tipos de integrações encontradas neste trabalho. O tipo

de integração de processo não é encontrado neste trabalho pois o Nível F do MPS.BR trata

sobre isso apenas em níveis superiores.

Figura 6.1 - Gráfico de Estatística de Dependências.

47

Figura 6.2 - Gráfico de estatística de Tipos de Integração.

Também, com este trabalho, obteve-se uma listagem das propostas de customizações

necessárias, a serem feitas nas ferramentas definidas, para que possa atender a cada uma das

dependências identificadas anteriormente. Além do que foi realizado neste trabalho, sugere-se

sua continuidade com a realização das seguintes atividades:

6.3 Elaboração de um Artigo

A elaboração do artigo é importante para a divulgação do projeto SPIDER e deste

subprojeto em si, apresentando este trabalho ao cenário nacional, afim de adquirir mais

colaboradores com interesses em comum, para integrar-se ao projeto.

6.4 Aderência ao Modelo CMMI

É relevante a analise de aderência deste trabalho ao modelo CMMI, pois trata-se de um

modelo de qualidade internacional, que apesar de assemelhar-se ao MPS.BR possui suas

particularidades, além de sua importância para instituições que desejem exportar seus

48

produtos ou serviços relacionados ao desenvolvimento de software. Atingindo assim, um

maior número de possíveis utilizadores dos resultados deste trabalho.

6.4.1 Implementação das Customizações Sugeridas

Aplicar, em cada ferramenta definida, todas as customizações sugeridas neste trabalho,

para que o projeto SPIDER possa ser implantado na prática em uma instituição que necessite

desenvolver projetos com um processo aderente aos níveis G e F do MPS.BR.

6.4.2 Estender o Mapeamento para os Níveis Seguintes do MPS.BR

É importante para a continuidade do trabalho, a ampliação do seu escopo, para atender

aos níveis A, B, C, D E, e seus respectivos processos, mapeando as dependências entre todos

os processos que estão contidos no MPS.BR. Com o mapeamento completo para todos os

níveis e a definição de ferramentas para atender a cada um dos seus processos, será possível

realizar a customização destas, para atender a qualquer instituição que queira submeter-se a

uma avaliação para qualquer nível do MPS.BR.

6.5 Lições Aprendidas

Com este trabalho, obteve-se um maior conhecimento em Engenharia de software, mais

especificamente no que diz respeito à área de Melhoria em Processo de Software, através do

estudo de diversos modelos de qualidade existente ao redor do mundo. Também foi

importante participar das reuniões no projeto SPIDER adquirindo um conhecimento sobre

MPS.BR essencial para a realização deste trabalho, aprendendo principalmente sobre os

níveis G e F deste modelo, assim como seus respectivos processos.

Também, pode-se entender o quão é importante para uma instituição que desenvolve

software, ter um processo bem definido, e que a utilização de ferramentas, na implementação

deste processo não é obrigatória, porém é relevante para que haja agilidade durante o

desenvolvimento de produtos, sem a necessidade de retrabalho ou replicação de dados,

podendo entregar um software confiável e usável em tempo, além de ser facilmente

gerenciado, durante todo o seu ciclo de vida.

49

REFERÊNCIAS BIBLIOGRÁFICAS [ANVISA, 2000] ANVISA - Agência Nacional de Vigilância Sanitária, Resolução

da Diretoria Colegiada – RDC, Nº 59, 2000.

[BARROS, 2009] BARROS, Renan. SPIDER CL, Manual do Usuário versão 1.2,

disponível em http://ufpa.br/spider , 2009.

[ESTACIO, 2009] ESTÁCIO, B., CARVALHO, E. R., VALENTE, K. S. M.,

OLIVEIRA, S. R. Uma Proposta de Aderência Ferramental para

Apoio ao Processo de Medição, 2009. Artigo em Submissão.

[HUMPHREY, 1995]. HUMPHREY, W. S., A discipline for software engineering,

Addison-Wesley, 1995.

[ISO/IEC, 2004] The International Organization for Standardization and the

International Electrotechnical Commission. ISO/IEC 15504-3:

Information Technology - Process Assessment - Part 3 -

Guidance on Performing an Assessment, Geneve: ISO, 2004.

[JORGENSEN, 1994] JORGENSEN, Steven A., An Object-Oriented Approach to Tool

Integration in an Integrated CASE Environment, M.S. Thesis

Electrical and Computer Engineering, University of New

Mexico, 1994.

[OLIVEIRA, 2001] OLIVEIRA, Sandro Ronaldo Bezerra. ToolManager: Um

Gerenciador de Ferramentas CASE, Orientador Alexandre

Marcos Lins de Vasconcelos. Dissertação de Mestrado. – CIN –

UFPE, 2001.

[OLIVEIRA, 2008] OLIVEIRA, Sandro Ronaldo Bezerra. SPIDER: Uma Proposta

de uma Solução Sistêmica de Apoio à Implementação do

Modelo MPS.BR. Projeto de Pesquisa submetido ao ICEN,

UFPA, 2008.

50

[SOFTEX, 2009a] SOFTEX - Sociedade para Promoção da Excelência do Software

Brasileiro, MPS.BR – Melhoria de Processo de Software

Brasileiro, Guia Geral, versão 2009.

[SOFTEX, 2009b] SOFTEX - Sociedade para Promoção da Excelência do Software


Brasileiro, Guia de Implementação – Parte 1, versão 2009.

[SOFTEX, 2009c] SOFTEX - Sociedade para Promoção da Excelência do Software


Brasileiro, Guia de Implementação – Parte 2, versão 2009.

[SOMMERVILLE, 2007] SOMMERVILLE, Ian, Engenharia de Software, 8ª Edição.

Pearson – Addison Wesley, 2007.

[TELES, 2009] TELES, Marilia P. & OLIVEIRA, Sandro R. B., Uma Proposta

de Aderência Ferramental para Apoio ao Processo de Garantia

da Qualidade, 2009. Artigo em Submissão.

U INTEGRAÇÃO DOS R SPERADOS DO ÍVEL DO...

Documents

Transcript of U INTEGRAÇÃO DOS R SPERADOS DO ÍVEL DO...