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
José Alberto de Andrade Ávila
UMA PROPOSTA DE INTEGRAÇÃO DOS RESULTADOS ESPERADOS DO NÍVEL F DO MPS.BR
Data da defesa: 17/12/2009
Conceito: ____________
Banca Examinadora
Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA – Orientador
Prof. Dr. Dionne Cavalcante Monteiro Faculdade de Computação/UFPA – Membro
Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA – Membro
Belém 2009
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.
José Alberto de Andrade Ávila
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
3.8. Considerações Finais...................................................................................................... 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
4.4. Considerações Finais...................................................................................................... 30
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
5.3. Considerações Finais...................................................................................................... 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.
3.8 Considerações Finais
Este capítulo aprofundou os conhecimentos sobre o MPS.BR, mais especificamente, o
nível de maturidade em foco: Nível F, Gerenciado. Apresentando seus objetivos, finalidades e
processos envolvidos na implementação, demonstrando cada resultado esperado que deverá
ser atendido a fim de implantação do nível. Como justificado anteriormente, este trabalho não
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.
4.4 Considerações Finais
Neste capítulo foi apresentado de forma breve o Projeto SPIDER, as ferramentas
utilizadas para compor sua SUITE e os mapeamentos feitos durante a fase de pesquisa do
projeto quanto à dependência entre Resultados Esperados de diferentes processos.
Estas dependências serão expostas novamente no próximo capítulo analisando agora
uma forma de implementação integrada das ferramentas, quando possível. No próximo
capítulo, também, será proposta uma metodologia de uso das ferramentas apresentadas neste
capítulo de forma a integrar suas operações em um SUITE consistente e flexível, visto que o
Projeto SPIDER não se propõe a mudar os processos nas empresas, mas sim adaptar o uso das
ferramentas ao processo já existente.
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.
5.3 Considerações Finais
Este capítulo apresentou a forma como cada dependência entre resultados esperados
será implementada no projeto SPIDER, identificando customizações em ferramentas e
aplicações de metodologias necessárias. Tais adaptações são essenciais tanto para que a
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, MPS.BR – Melhoria de Processo de Software
Brasileiro, Guia de Implementação – Parte 1, versão 2009.
[SOFTEX, 2009c] SOFTEX - Sociedade para Promoção da Excelência do Software
Brasileiro, MPS.BR – Melhoria de Processo de 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.
Top Related