Thiago Crystyan Soares Macdo

Implantao do Processo de Desenvolvimento para

Reutilizao do MPS.BR nas empresas cearenses: uma
Anlise Qualitativa









Fortaleza
2014


ii




THIAGO CRYSTYAN SOARES MACDO

Implantao do Processo de Desenvolvimento para
Reutilizao do MPS.BR nas empresas cearenses: uma
Anlise Qualitativa




Orientador: Prof. Adriano Bessa Alburquerque, D.Sc.



Fortaleza
2014

Dissertao apresentada ao Curso de Mestrado em
Informtica Aplicada da Universidade de Fortaleza
(UNIFOR), como requisito parcial para obteno do ttulo
de Mestre em Informtica Aplicada.

iii
































_____________________________________________________________________________

M141i Macdo, Thiago Crystyan Soares.
Implantao do processo de desenvolvimento para reutilizao do MPS.BR
nas empresas cearenses: uma anlise qualitativa / Thiago Crystian Soares Macdo.
- 2014.
100 f.

Dissertao (mestrado) Universidade de Fortaleza, 2014.
Orientao: Prof. Adriano Bessa Albuquerque, D.Sc.

1. Desenvolvimento de software. 2. Reutilizao de software. 3. Empresas.
I. Ttulo.
CDU 681.3.06
_____________________________________________________________________________




iv


v




























Aos meus pais, Nonato e Ana,
por todo amor e dedicao.
vi


AGRADECIMENTOS

Primeiramente a Deus, por me conceder sade e fora para correr atrs dos
meus sonhos.
Aos meus pais que estiveram ao meu lado em todos os momentos, tristes e
felizes de minha vida.
minha noiva Carina, por todo seu carinho e ateno nos momentos em que
mais precisei.
Aos profissionais da IVIA, RCN&BS, VTI e Enovar, pelo apoio para
composio e conduo da pesquisa por meio de uma entrevista que qualificou o
Processo Proposto. Ao Grupo Edson Queiroz, na pessoa do Cleidson Pontes pelo
apoio concedido.
Ao meu orientador e amigo Adriano Bessa por todo seu apoio e suporte.
















vii

Sumrio
Lista de Figuras ..................................................................................................................................... xii
Lista de Tabelas ................................................................................................................................... xiii
Captulo 01- Introduo .......................................................................................................................... 1
1.1 Contextualizao ....................................................................................................................... 1
1.2 Motivao ................................................................................................................................... 2
1.3 Objetivo da Pesquisa ................................................................................................................. 2
1.4 Metodologia ............................................................................................................................... 3
1.5 Organizao do Trabalho ................................................................................................................ 4
Captulo 02 - Desenvolvimento de Software para Reutilizao ............................................................. 5
2.1 Histrico da Reutilizao de Software ........................................................................................ 5
2.2 Definies ................................................................................................................................... 6
2.3 Benefcios ................................................................................................................................... 6
2.4 Dificuldades ................................................................................................................................ 9
2.4 Reso Sistemtico ..................................................................................................................... 12
2.5 Componentes de Software Reutilizveis ................................................................................... 13
2.6 Engenharia de Domnio .................................................................................................................. 15
2.6.1 Formas de Representao de um Domnio ou Arquitetura de Domnio ...................................... 16
2.6.2 Modelo de Caracterstica ............................................................................................................. 17
2.6.3 Modelagem de uma Arquitetura de Domnio............................................................................... 19
2.7 Engenharia de Aplicao ................................................................................................................ 21
2.8 Linha de Produo de Software ...................................................................................................... 22
2.9 MPS.BR Programa para Melhoria de Processos do Software Brasileiro .................................... 23
2.9.1 Gerncia de Reutilizao ............................................................................................................. 24
2.9.2 Desenvolvimento para Reutilizao ............................................................................................. 25
2.10 Concluso ...................................................................................................................................... 27
Captulo 03- Abordagem de Desenvolvimento para Reutilizao ........................................................ 29
3.1 Processo .......................................................................................................................................... 29
3.1.1 Planejamento ................................................................................................................................ 30
3.1.1.1 Atividades da Fase de Planejamento ......................................................................................... 31
3.1.1.1.1 Identificar Domnios de Aplicao ........................................................................................ 31
a) Analisar projetos passados ............................................................................................................ 32
b) Identificar objetivos e metas organizacionais ............................................................................... 32
c) Selecionar domnios de aplicao candidatos ............................................................................... 33
3.1.1.1.2 Analisar Domnios com Potencial de Reutilizao ................................................................ 33
a) Analisar Ativos de Domnios pr-existentes ................................................................................. 35
viii

b) Analisar Possibilidade de Compra ................................................................................................ 35
c) Analisar Possibilidade de Modificao de ativos.......................................................................... 35
d) Verificar se o Retorno Vivel ..................................................................................................... 36
e) Definir Domnios de Aplicao .................................................................................................... 36
3.1.1.1.3 Justificar a no Adoo do Processo ...................................................................................... 36
3.1.1.1.4 Avaliar Capacidade de Reutilizao Sistemtica da Organizao .................................... 37
a) Analisar Recursos Humanos ......................................................................................................... 38
b) Analisar Recursos Financeiros ...................................................................................................... 38
c) Analisar Infraestrutura .................................................................................................................. 38
d) Analisar Aspectos Culturais .......................................................................................................... 39
e) Aferir a Capacidade de Reutilizao Sistemtica da Organizao ............................................... 39
3.1.1.1.5 Gerar Plano de Ao ......................................................................................................... 39
3.1.1.1.6 Planejar Programa de Reutilizao ................................................................................... 39
a) Definio de Propsito .................................................................................................................. 40
b) Definio de Escopo (Cenrio) ..................................................................................................... 41
c) Definio de Meta ......................................................................................................................... 41
d) Elaborar o Plano de Reutilizao .................................................................................................. 41
3.1.2 Implantao ........................................................................................................................... 42
3.1.2.1 Atividades da Fase de Implantao ....................................................................................... 42
3.1.2.2 Implantar Programa de Reutilizao ..................................................................................... 43
a) Implantar Infraestrutura Necessria .............................................................................................. 44
b) Identificar Necessidade de realizar treinamento ........................................................................... 44
c) Alocar Equipes .............................................................................................................................. 44
d) Desenvolver ou Adaptar Repositrio de artefatos reutilizveis .................................................... 45
e) Definir domnio piloto .................................................................................................................. 45
3.1.2.3 Selecionar forma de Representao para Modelo de Arquitetura e de Domnio .................. 45
a) Identificar formas de representao .............................................................................................. 46
b) Escolher forma a ser utilizada na organizao .............................................................................. 46
3.1.2.4 Estabelecer e manter o Modelo de Domnio ......................................................................... 47
a) Definir metodologia de apresentao ............................................................................................ 48
3.1.2.5 Estabelecer e manter Modelo de Arquitetura ........................................................................ 48
a) Definir metodologia de apresentao ............................................................................................ 49
3.1.2.6 Monitorar e avaliar o processo .............................................................................................. 49
3.1.3 Execuo ............................................................................................................................... 49
3.1.3.1 Atividades da Fase de Execuo ........................................................................................... 50
3.1.3.2 Elaborar Proposta de Reutilizao ........................................................................................ 50
ix

a) Enviar Proposta de Reso ............................................................................................................. 51
3.1.3.3 Identificar Possveis Ativos de Reutilizao ......................................................................... 52
a) Analisar Proposta dos Usurios .................................................................................................... 53
b) Analisar Proposta da Equipe de Reso ......................................................................................... 54
c) Manter Rastreabilidade ................................................................................................................. 54
d) Aprovar a Deciso ......................................................................................................................... 54
3.2. Concluso do Captulo ................................................................................................................... 54
Captulo 04- Pesquisa Qualitativa utilizando Procedimentos da Grounded Theory ............................. 56
4.1 Introduo ................................................................................................................................. 56
4.2 Metodologia de Pesquisa Grounded Theory ............................................................................. 57
4.3 A Aplicao da Grounded Theory ............................................................................................ 60
4.4 Anlise dos Resultados da Pesquisa Qualitativa ....................................................................... 64
4.4.1 Realidade do reso no CE ..................................................................................................... 65
4.4.2 Processo Proposto ................................................................................................................. 71
4.5 Teorias Encontradas .................................................................................................................. 81
4.6 Concluso do Captulo .............................................................................................................. 84
Captulo 05 - Concluso ........................................................................................................................ 85
5.1 Consideraes Finais ................................................................................................................ 85
5.2 Principais Contribuies ........................................................................................................... 86
5.3 Limitaes ................................................................................................................................. 87
5.4 Trabalhos Futuros ..................................................................................................................... 87
Bibliografia ........................................................................................................................................... 88
Apndice A Questionrio da Entrevista ............................................................................................. 91
Apndice B Cdigos encontrados na Grounded Theory .................................................................... 92












x


Resumo da dissertao apresentada ao Corpo Docente do Curso de Mestrado em
Informtica Aplicada da Universidade de Fortaleza, como parte dos requisitos necessrios para a
obteno do grau de Mestre em Informtica Aplicada.

Implantao do Processo de Desenvolvimento para
Reutilizao do MPS.BR nas empresas cearenses: uma
Anlise Qualitativa


Autor: Thiago Crystyan Soares Macdo
Orientador: Adriano Bessa Albuquerque, D. Sc.





A reutilizao de software a disciplina responsvel pela criao de sistemas
de software a partir de softwares existentes, enquanto a reutilizao ad-hoc
a simples cpia de um trecho de um ativo. A disciplina de reutilizao de
software visa sistematizar essa prtica, aplicando tcnicas de engenharia de
domnio para definir o escopo, especificar a estrutura e construir ativos
reutilizveis. O trabalho em questo teve como um dos objetivos construir um
processo de reutilizao sistemtica, aderente ao processo Desenvolvimento
para Reutilizao (DRU), do modelo de maturidade de software, MPS.BR. O
processo proposto dividido em trs partes: Planejamento, Implantao e
Execuo. Alm disso, identificar junto as empresas cearenses que j haviam
sido avaliadas nos nveis E e C, quais eram os principais dificultadores para
implantar e executar o referido processo.

Palavras-chave:Reso Sistemtico, Desenvolvimento para Reutilizao,
Processo de melhoria de software, MPS.BR.


xi


Abstract of the dissertation presented to the board of faculties of the Master Program in
Applied Informatics at the University of Fortaleza, as partial fulfillment of the requirements for the
Masters degree in Applied Informatics.


Implementation of the MPS.BRs Process Development for
Reuse in Cears companies: A Qualitative Analysis


Autor: Thiago Crystyan Soares Macdo
Orientador: Adriano Bessa Albuquerque, D. Sc.


Software reuse is a discipline responsible for creating software systems from
existing software, while ad hoc reuse is a simply copy of a part from an asset.
The discipline of software reuse aims to systematize this practice, applying
domain engineering techniques to define the scope, specify the structure and
build reusable assets. One of the aims of this paper is to build a process of
systematic reuse, adherent to the process development for reuse, known by
the acronym DRU of the brasilian software maturity model MPS.BR. The
proposed process is divided into three parts: planning, implementation, and
execution.Besides that, indentify with Cearascompanys that had already
been assessed into levels E and C, wich were the main difficulties to
implement and run the procedure referred.

Keywords: Systematic Reuse, Developing for Reuse, Software Process,
MPS.BR.


xii

Lista de Figuras

FIGURA 1 PROCESSO PROPOSTO ......................................................................................................... 29
FIGURA 2 FASE DE PLANEJAMENTO ..................................................................................................... 31
FIGURA 3 FASE DE IMPLANTAO ......................................................................................................... 42
FIGURA 4 FASE DE EXECUO ............................................................................................................... 50
FIGURA 5 PROCESSO DA GROUNDED THEORY (GOULDING, 2002 CITADO POR (SCHOTS,
2010)) .......................................................................................................................................................... 60
FIGURA 6 ASSOCIAO DE CDIGOS S CITAES DAS ENTREVISTAS ................................. 62
FIGURA 7 [CATEGORIA PRINCIPAL] DESENVOLVIMENTO PARA REUTILIZAO ..................... 65
FIGURA 8 [CAT-1] REALIDADE DO RESO NO CE .............................................................................. 65
FIGURA 9 [SS-C1] EQUIPE PARA RESO .............................................................................................. 66
FIGURA 10 [SS-C1] DESENVOLVIMENTO COM RESO ..................................................................... 67
FIGURA 11 [SUB-C1] INSTITUCIONALIZAO E EXECUO DE PROCESSOS DE SOFTWARE
..................................................................................................................................................................... 69
FIGURA 12 [SS-C1] FERRAMENTAS ........................................................................................................ 70
FIGURA 13 [CAT-2] PROCESSO PROPOSTO ........................................................................................ 71
FIGURA 14 [SS-C2] FBRICA DE SOFTWARE ....................................................................................... 74
FIGURA 15 [SS-C2] INFRAESTRUTURA .................................................................................................. 75
FIGURA 16 [SS-C2] FINANCEIRO.............................................................................................................. 77
FIGURA 17 [SS-C2] RH ................................................................................................................................ 78
FIGURA 18 [SS-RH-C2] CULTURA ORGANIZACIONAL ........................................................................ 79
FIGURA 19 ESTRUTURA ORGANIZACIONAL ........................................................................................ 80
FIGURA 20 [SS-C2] ALTA DIREO ......................................................................................................... 81


xiii

Lista de Tabelas

TABELA 1- IDENTIFICAR DOMNIO DE APLICAO ............................................................................... 32
TABELA 2 ANALISAR DOMNIO COM POTENCIAL DE REUTILIZAO .......................................... 34
TABELA 3 AVALIAR CAPACIDADE DE REUTILIZAO SISTEMTICA DA ORGANIZAO ...... 37
TABELA 4 PLANEJAR PROGRAMA DE REUTILIZAO ....................................................................... 40
TABELA 5 IMPLANTAR PROGRAMA DE REUTILIZAO ................................................................... 43
TABELA 6 SELECIONAR FORMA DE REPRESENTAO PARA MODELO DE ARQUITETURA
DE DOMNIO ............................................................................................................................................. 46
TABELA 7 - ESTABELECER E MANTER MODELO DE DOMNIO .......................................................... 48
TABELA 8 ESTABELECER E MANTER MODELO DE ARQUITETURA .............................................. 49
TABELA 9 ELABORAR PROPOSTA DE REUTILIZAO ...................................................................... 51
TABELA 10 IDENTIFICAR POSSVEIS ATIVOS DE REUTILIZAO ................................................. 53
TABELA 11 PERFIL DOS ENTREVISTADOS ........................................................................................... 61
TABELA 12 CONECTORES DE CDIGOS ADAPTADOS DE (BANDEIRA-DE-MELO, ET AL.,
2006) ........................................................................................................................................................... 63
TABELA13 CDIGOS EXTRADOS DA GT .............................................................................................. 92



Captulo1
Introduo


Este captulo apresenta a introduo da pesquisa, com a descrio da
problemtica que motivou e justificou o desenvolvimento deste trabalho. Os
objetivos da dissertao e a metodologia utilizada so tambm apresentados.
Ao final, apresentada a forma de organizao deste trabalho.

1.1 Contextualizao

Com o crescente acesso as novas tecnologias e, uma grande
necessidade de informatizao das empresas, como fator diferencial de
mercado, vrias empresas tm entrado no ramo de desenvolvimento de
software a fim de atender tais necessidades. Porm, um dos fatores
diferenciais dessas empresas, que tem como foco o desenvolvimento de
software, a qualidade do produto desenvolvido e entregue ao cliente final.
Essa qualidade pode ser medida de diversas formas, uma delas sendo a
partir da avaliao dos processos de software, que pode ser realizada
atravs do CMMI ou MPS.BR, que direcionou este trabalho.
Um dos objetivos, das empresas que buscam a qualificao dos
processos de software, alm de dar uma idia ao cliente final sobre a
qualidade dos produtos desenvolvidos pela empresa, melhorar o nvel de
competitividade em licitaes pblicas, pois segundo Braga, et al., (2014) as
empresas que possurem o MPS.BR obtero pontuaes tcnicas favorveis.
Uma dessas tcnicas a Reutilizao de Software. Com ela, a
empresa no precisa mais desenvolver algo que j foi produzido uma vez,
somente adapta o ativo produzido para a nova funcionalidade, se for o caso.
Com isso, ela tende a diminuir o tempo de desenvolvimento e o nmero de
defeitos, pois a cada vez que o artefato reutilizado h probabilidade de ele
ser aperfeioado, garantindo uma melhor qualidade.
2

Na teoria, apesar da reutilizao de software ser uma tcnica de suma
importncia para empresas de software, vrias empresas no aderem a esta
tcnica. Segundo Lucredio, et al., (2008) pequenas empresas tm a
facilidade de ter um escopo de domnio mais restrito, o que facilita o melhor
controle sobre as atividades, porm possui os recursos mais limitados. J nas
grandes organizaes existe o medo da implantao de programa de reso
de software, principalmente por conta do alto investimento e o retorno ser de
longo prazo. Alm disso mais difcil introduzir mudanas em grandes
organizaes, pois envolve mudana no s na estrutura mas na cultura da
organizao.

1.2 Motivao

A busca por tcnicas e ferramentas que permitam uma melhora no
time to market
1
e na qualidade do produto final tem sido uma constante busca
das grandes empresas e pesquisadores da rea da engenharia de software.
Pensando nisso, a utilizao de uma tcnica aprimorada de reutilizao
sistemtica ir auxiliar muito a organizao, tornando-a mais competitiva no
mercado de desenvolvimento de software.
Um processo de reutilizao bem implementado, alm de trazer uma
qualidade maior ao software produzido e fornecer uma reduo no custo do
desenvolvimento Krueger (1992), no deixa a organizao refm de
colaboradores que detm sozinhos o conhecimento do processo. Almeida, et
al., (2010)

1.3 Objetivo da Pesquisa

O objetivo desse trabalho realizar uma anlise qualitativa,
principalmente nas dificuldades encontradas, pelas empresas cearenses que
j so avaliadas nos nveis E e C do modelo de maturidade MPS.BR. para

1
Termo utilizado para o espao de tempo que leva do produto ser produzido at que esteja pronto para ser
vendido.
3

implantar o processo Desenvolvimento para Reutilizao, exigido no nvel C
do referido modelo.
Visto que no foi encontrada nenhuma sugesto de processo definido
que seja aderente aos resultados esperados do processo Desenvolvimento
para Reutilizao (DRU) do MPS.BR nvel C, foi proposto um processo para
auxiliar nas entrevistas realizadas com as empresas. Para validao desse
processo, foi realizada uma reviso em par juntamente com um professor
doutor na rea de reutilizao.
Dessa forma o trabalho visa auxiliar empresas que pretendem
implantar o nvel C do MPS.BR. indicando possveis dificuldades, boas
prticas, dentre outras.

1.4 Metodologia

Para compreender os conceitos relacionados ao reso no contexto de
desenvolvimento de sistemas, bem como conhecer tcnicas de reso
sistemtico, foi efetuada uma pesquisa bibliogrfica em artigos de workshops,
simpsios, e de peridicos, bem como em livros relacionados com o assunto.
Depois, foi definido o Processo de Desenvolvimento para Reutilizao,
aderente aos resultados esperados do DRU do MPS.BR, detalhando cada
uma das atividades necessrias. Aps tal definio, foi realizada uma reviso
por pares no processo definido, com um professor doutor, com conhecimento
e experincia em reso de software. Tal reviso por pares teve o objetivo de
verificar a aderncia ao DRU, bem como identificar defeitos.
Finalizando esse trabalho foram realizadas entrevistas com quatro
empresas cearenses avaliadas nos nveis E e C do MPS.BR, para coletar
dados relacionados dificuldade das empresas em implantar o processo
proposto, considerando a realidade da organizao, bem como, foram
coletados dados referentes ao atual estado de reso de software de cada
uma das empresas. A anlise qualitativa foi realizada utilizando alguns
passos sugeridos por Straus, et al., (1998), da tcnica Grounded Theory
(GT).

4

1.5 Organizao do Trabalho

Este trabalho est organizado em 5 captulos, inclusive a Introduo
como captulo 1. Os demais captulos esto resumidos e descritos a seguir.
Desenvolvimento de Software para Reutilizao temos uma reviso
bibliogrfica sobre a Reutilizao de Software finalizando com o que o
MPS.BR espera da Gerncia de Reutilizao (GRU) e do Desenvolvimento
para Reutilizao (DRU), que o foco do trabalho.
Abordagem de Desenvolvimento para Reutilizao apresentamos
uma proposta de processo de desenvolvimento para reutilizao, para
empresas que desejam ser qualificadas no MPS.BR nvel C.
Pesquisa Qualitativa utilizando Procedimentos da Ground Theory
apresentada a Pesquisa Qualitativa sobre a implantao do processo de
Desenvolvimento para Reutilizao no estado do Cear e seus principais
resultados.
Concluso ser apresentadaa concluso sobre o trabalho.


Captulo2
Desenvolvimento de Software para Reutilizao

Neste captulo, apresentada a reviso bibliogrfica desse trabalho
analisando o histrico do reso no contexto de desenvolvimento de software,
os benefcios e dificuldades envolvidas, bem como os resultados esperados
do processo de Desenvolviemento para Reutilizao (DRU) do MPS.BR.
2.1 Histrico da Reutilizao de Software

Em 1968 a conferncia de Engenharia de Software NATO foi
considerada o bero desse campo da Engenharia de Software NATO (1968).
A conferncia focou na crise do software, no problema de construo em
larga escala, nos sistemas de software confiveis a um custo acessvel. Foi
nessa conferncia que o termo crise de software foi originado, Krueger
(1992). Desde o incio a reutilizao de software foi ensinada como um
mecanismo de soluo para a crise do software. O artigo que falou sobre a
reutilizao do software foi o de Mclroy, (1968), que havia sido convidado
para a conferncia. O seu artigo tornou-se o principal do evento. Mclroy
props uma biblioteca de componentes reutilizveis e uma tcnica
automatizada para edio de componentes em vrios graus de preciso e
robustez. Mclroy afirmou que as bibliotecas de componentes poderiam ser
mais eficientemente utilizadas para clculo numrico, converses de I/O,
processamento de texto e alocaes dinmicas Krueger (1992).
A busca por tcnicas e ferramentas que permitam uma melhora no
time to Market (termo utilizado para o espao de tempo que leva do produto
ser produzido at que esteja pronto para ser vendido) e na qualidade do
produto final tem sido uma constante nas grandes empresas e por
pesquisadores da rea da engenharia de software, podemos confirmar isso
por Netto (2007).

6

De acordo com Almeida, et al., (2010) alguns estudos a respeito da
reutilizao de software comprovam que de 40% a 60% dos cdigos j
desenvolvidos at hoje foram reutilizados de uma aplicao para outra, 60%
dos designs so reutilizados, 75% de todas as funes so comuns em mais
de um programa e apenas 15% dos cdigos encontrados na maioria dos
sistemas so nicos para algumas determinadas aplicaes Ezran, et al.,
(2002). Com o aumento da reutilizao de softwares testados, certificados e
organizados em componentes, as empresas podero obter uma reduo em
seus custos, tempo de desenvolvimento e aumento da qualidade do produto
final.
2.2 Definies

Algumas definies de reutilizao de software j foram apresentadas
na literatura. Foram elas:
a) Reso a utilizao de qualquer informao que o desenvolvedor possa
necessitar no processo de criao de um software Ezran, et al., (2002).
b) Reso o uso de tudo associado com um projeto de software, incluindo
o conhecimento relativo ao negcio. Basili, et al., (1991)
c) Reso de software definido como o uso da engenharia do
conhecimento ou artefatos de outros sistemas existentes para construir
novos sistemas. Frakes, et al., (1994)
d) Reso o processo de criao de sistemas de software a partir de
softwares existentes ao invs de desenvolv-lo do zero Krueger, (1992).
2.3 Benefcios

Quando a empresa faz uso de tcnicas de reutilizao de software, a
mesma pode observar que consegue obter um impacto positivo na qualidade
do produto final, assim como uma economia financeira, caso haja um bom
uso da prtica. Podemos tambm, encontrar benefcios como o aumento da
produtividade Sametinger, (1997). Esses benefcios segundo Almeida, et al.,
7

(2010) podem ser divididos em trs partes: aumento da qualidade, reduo
do esforo e tamanho da equipe.
Para Almeida, et al., (2010) temos:

a) Aumento da Qualidade: A reutilizao de software resulta em um
aumento da qualidade assim como um aumento na produtividade e
maior confiana do produto final.
Qualidade As correes dos erros so acumuladas a cada
vez que o produto reutilizado. Isso traz uma maior
qualidade ao componente reutilizado ao invs de um
componente que foi desenvolvido e utilizado uma nica vez.
Produtividade Um aumento na produtividade alcanado
pelo fato de ter de desenvolver uma quantidade menor de
cdigo. Isso resulta numa massa de testes menor e tambm
reduz o trabalho de anlise e design. Com essas redues
consegue-se alcanar uma reduo no custo de produo.
Confiana O uso de componentes, bem testados,
aumenta a confiana no sistema produzido. Com isso, o uso
desse componente em outros sistemas diminui a
possibilidade de erros serem encontrados.

b) Reduo do esforo: O reso de software prov uma reduo de
trabalhos redundantes e tempo de desenvolvimento, o que propicia
um melhor time to market.
Trabalho redundante e tempo de desenvolvimento
Desenvolver todo o sistema do zero significa uma
redundncia no desenvolvimento de vrias etapas tais como
levantamento de requisitos, construo e definio de casos
de uso, definio de uma arquitetura, definio de um
modelo de dados, entre outros. Isso poderia ser evitado
quando essas partes so disponibilizadas como
componentes reutilizveis e podem ser compartilhadas,
resultando em uma menor quantidade de cdigos
8

desenvolvidos, menor tempo de desenvolvimento,
consequentemente em um menor custo.
Time to Market O sucesso ou falha de um produto de
software frequentemente determinado por seu tempo de
entrega. Com a utilizao de componentes reutilizveis
pode-se obter uma reduo significativa desse tempo, visto
o aumento da produtividade.
Documentao A documentao muito importante para
a manuteno de um sistema, entretanto ela
frequentemente negligenciada. A reutilizao de
componentes de software reduz a quantidade de
documentos que necessitam ser construdos, porm ressalta
a importncia do que est escrito. S os novos componentes
e as alteraes em estruturas que utilizam os componentes
precisam ser documentadas.
Custo de manuteno Com o uso de componentes que
passaram por um padro de qualidade no desenvolvimento
h uma baixa probabilidade de erros serem encontrados e
com isso h uma grande reduo no custo de manuteno
dos sistemas desenvolvidos.

c) Tamanho da equipe: Algumas equipes de desenvolvimento de
grande porte podem encontrar problemas na comunicao. O fato
de se dobrar o tamanho de uma equipe de desenvolvimento no
significa que a produtividade tambm ir ser dobrada. Se muitos
componentes podem ser reutilizados, ento os sistemas de
software podem ser desenvolvidos com equipes menores. Uma
equipe de desenvolvimento que possui uma boa comunicao
entre si tem um grande ganho de produtividade Almeida, et al.,
(2010).

9

2.4 Dificuldades

Ainda segundo Almeida, et al., (2010) podemos verificar que apesar
dos benefcios encontrados com a reutilizao de software ela no to
praticada como j comentaram alguns autores. H alguns fatores que
influenciam direta ou indiretamente em sua adoo. Esses fatores podem ser
gerenciais, organizacionais, econmicos, tcnicos e modificaes.
Sametinger, (1997)
Para Almeida, et al.(2010) temos:

a) Obstculos gerenciais e organizacionais: Reso no somente
um problema tcnico que necessita ser resolvido por engenheiros
de software. Assim, um suporte gerencial e uma estrutura
organizacional adequada so igualmente importantes. Os principais
obstculos so:
Falta de um suporte gerencial Visto que a reutilizao de
software gera um alto custo ela no pode ser implementada
sem um aval da Alta Direo. Os gerentes devem ser bem
informados do alto custo inicial e serem convencidos que
medida que a prtica for sendo utilizada pela organizao,
os lucros iro aparecer. Porm, isso requer um tempo.
Gerenciamento do projeto O gerenciamento de projetos
tradicionais no uma tarefa fcil, principalmente os
projetos relacionados reutilizao de software. Caso a
organizao decida pela reutilizao de software isso ir
gerar um grande impacto em todo o ciclo de vida do
software e a Alta Direo deve estar ciente disso.
Estrutura organizacional inadequada A estrutura
organizacional dever considerar as diferentes
necessidades que surgem quando o reso de software for
adotado em larga escala. Por exemplo, pode ser necessria
a criao de uma nova equipe para dar suporte a construo
e manuteno de componentes reutilizveis.
10

Incentivos gerenciais Por conta dos gestores terem as
suas competncias avaliadas atravs da entrega no prazo
de seus produtos, qualquer atividade que venha a alterar o
prazo estipulado para entrega do mesmo, no visto com
bons olhos por meio desses gestores. H uma grande
necessidade que a alta direo no avalie os seus gestores
somente pela entrega no prazo mas tambm por uma taxa
de adeso ao processo proposto, por isso h essa
necessidade de se ter na equipe gestores comprometidos
com o processo a ser adotado.

b) Obstculos econmicos: O reso de software pode trazer uma
economia financeira para a organizao, em um longo prazo, mas
esse processo no de graa, Almeida, et al., (2010). Segundo
Sametinger, (1997) os custos relacionados ao reso de software
so:
Custo de produzir algo reutilizvel.
Custo de reutiliz-lo.
Custo de definir e implementar um processo de reutilizao.
O reso de software requer alguns investimentos, como em
infraestrutura, que o mais significativo, metodologias e
treinamentos. Como falado anteriormente, o retorno do
investimento s ser percebido aps alguns anos. Segundo
Almeida, et al., (2010) o desenvolvimento de componentes para
reso mais caro que o desenvolvimento de componentes para o
uso individual. Para o caso de desenvolver componentes para
reso necessrio que o mesmo tenha um alto nvel de qualidade,
seja confivel, seja adaptvel, possua um suporte e possua uma
documentao detalhada. Esses fatores so os que acarretam o
encarecimento do componente, coisa que no justificvel para o
caso de ser um componente que seja utilizado em um projeto
individual.
11

c) Obstculos tcnicos e conceituais Os obstculos tcnicos
esto relacionados pesquisa e recuperao de componentes,
componentes legados e alguns aspectos que envolvem a
adaptao dos componentes Sametinger, (1997):
Dificuldade de encontrar software reutilizvel A fim de
reutilizar componentes de software desejvel que hajam
maneiras eficientes de realizar pesquisas e tambm de
recuper-los. Mais importante ainda a necessidade de
haver um repositrio bem organizado contendo todos os
componentes reutilizveis e que hajam vrias formas de
acess-lo. Como por exemplo, um suporte de um framework
no qual haja alm da forma de acess-lo, uma forma de
realizar uma pesquisa onde possa ser informado detalhes do
componente desejado.
A no reutilizao dos softwares encontrados O fato de
haver um fcil acesso ao software no significa que
necessariamente haja um aumento na reutilizao de
software. Componentes reutilizveis devem ser
cuidadosamente especificados, implementados e
documentados. Algumas vezes a modificao e adaptao
de um componente pode ser mais cara do que desenvolver
um componente que atenda a necessidade em questo.
Componentes legados no so adequados ao reso
Uma abordagem conhecida para a reutilizao de software
o uso de software legado. Entretanto, simplesmente
recuperar componentes existentes de sistemas legados e
tentar reutiliz-los em novos sistemas no suficiente para
um reso sistemtico. Uma reengenharia nos sistemas
legados pode ajudar na extrao de componentes
reutilizveis.

d) Modificao muito difcil encontrar um componente que atenda
inteiramente a necessidade requerida. Sabendo disso,
12

modificaes so necessrias e devero existir maneiras de
verificar se a modificao afetou o desempenho do componente e
se com essa modificao pode obter o resultado esperado. Caso a
modificao no atenda ao que foi proposto, a mesma deve ser
retirada do repositrio de ativos reutilizveis.
2.4 Reso Sistemtico

Almeida, et al., (2010) afirmaram que, antes de descrever a
reutilizao sistemtica importante considerar a reutilizao no
sistemtica, que em sua maioria de forma ad-hoc, ou seja, dependente de
iniciativas ou conhecimentos individuais, no difundidos em toda a
organizao, ou mesmo, na equipe em questo.
Segundo Krueger, (1992) o reso de componentes anlogo a
escavao de cdigos, que consiste no programador copiar um artefato de
cdigo existente e o colocar em um novo software. Entretanto, a tecnologia
de componentes reutilizveis, tipicamente utiliza-se mais de tcnicas
sistemticas, tais como catlogos e bibliotecas de componentes. Em adio,
componentes reutilizveis so criados e armazenados especificamente para
o propsito do reso, enquanto na escavao os cdigos so extrados sem
que haja na mente o objetivo do reso.
Segundo Almeida, et al., (2010) se a organizao possuir um processo
maduro de desenvolvimento e for bem gerenciada, possvel que algumas
formas de reutilizao no sistemticas obtenham bons resultados.
Entretanto, mais provvel que o reso no sistemtico seja catico, em
todos os efeitos, alimentando uma cultura organizacional de pessoas que so
tidas como heris na organizao, pois so os tpicos funcionrios que so
chamados para apagar os incndios, amplificando o problema organizacional
ao invs de solucion-lo. Em contra partida o reso sistemtico de software
significa: Almeida, et al., (2010)
a. Entender como o reso pode contribuir para os objetivos de toda
organizao.
b. Definir uma estratgia tcnica e gerencial de como adquirir um
valor mximo do reso.
13

c. Integrar o reso a todo o processo de software e em um programa
de processo de melhoria do software.
d. Garantir que toda a equipe responsvel pelo software tenha uma
competncia e uma motivao necessria.
e. Estabelecer um apropriado suporte organizacional, tcnico e
oramentrio.
f. Usar controles de medio apropriados para controlar a
performance do reso.
2.5 Componentes de Software Reutilizveis

A seguir so apresentadas algumas definies para componentes de
software, encontradas na literatura:
a) Componentes de software encapsulam conhecimentos a cerca do
negocio e so de grande importncia para a organizao. Ezran, et
al., (2002)
b) So geralmente compostos de uma coleo de software que
podem vir a ser utilizados de uma aplicao para outra. Almeida, et
al., (2010)
c) Componentes podem ser definidos como pequenos grupos de
objetos com uma interface bem definida que podem comunicar,
sem restries, com outros componentes. Guerra, et al., (1999)
Do ponto de vista da reutilizao, a adaptabilidade dos
componentes bem como a sua qualidade e confiabilidade so ainda
objetos de estudo. Processos de reutilizao concentram-se no nos
dados, mas nos procedimentos que conduzem reutilizao Guerra,
et al., (1999).
H dois tipos de componentes, so eles:

a) Componentes verticais Que so especficos de um domnio de
aplicao, por exemplo, objetos de modelos financeiros, algoritmos,
frameworks, dentre outros. Segundo Krueger, (1992) para os
componentes verticais so necessrios altos nveis de abstrao.
14

Por exemplo, para a implementao de um pacote de dados
necessrio o uso de um conjunto de abstraes de baixo nvel para
que seja feito um cdigo de alto nvel tal como um algoritmo de
ordenao. Para Guerra, et al., (1999) o objetivo da verticalidade
consiste em obter modelos genricos que possam ser utilizados
como moldes para produzir novos sistemas da mesma famlia.
Ainda segundo Guerra, et al., (1999) embora a reutilizao vertical
tenha tido uma aplicao informal, a sua aplicao tem tido
sucessos em reas como as interfaces grficas e os sistemas
corporativos. A reutilizao vertical tambm conhecida como
cdigo de caixa preta, onde o cdigo fonte relativo
implementao no fica transparente para quem a utiliza.
b) Componentes horizontais Que so mais fceis de serem
identificados e reutilizados por que representam elementos
arquiteturais recorrentes. Componentes horizontais podem ser
reutilizados independentes do domnio de aplicao, tendo como
principal pr-requisito que a arquitetura da aplicao escolhida seja
compatvel ao componente. Segundo Krueger, (1992) os
componentes horizontais so instanciados em algumas
especializaes. Segundo Guerra, et al., (1999) a ateno da
reutilizao horizontal tem-se virado para o desenvolvimento e
acesso a bibliotecas, bem como catalogao e classificao dos
componentes nelas armazenados. Os componentes horizontais
so conhecidos por serem componentes de caixa branca.

Alm desses tipos, os componentes tambm podem ter tamanhos
diferentes e granularidades distintas tais como funes, classes, grupo de
classes, um framework e uma aplicao ou produto. Um componente
reutilizvel potencialmente feito de diversos produtos, aonde o ciclo de vida,
inclui: definio de requisitos e arquitetura, modelo de anlise, modelo de
design, cdigos, casos de teste, cenrios de teste, relatrios de teste, dentre
outros.
H diversas maneiras utilizadas para realizar o reso de software,
nessa parte iremos abordar algumas delas, porm uma metodologia que seja
15

aplicvel para uma organizao no necessariamente ser aplicvel outra.
Segundo Bayer, et al., (1999) as metodologias existentes, ou no tm sido
suficientemente extensveis, a fim de atenderem as necessidades distintas
das organizaes, ou tem sido muito vagas e no so aplicveis sem uma
forte interpretao e um suporte adicional. necessrio que haja uma
metodologia que seja suficientemente abrangente a todas as situaes
apresentadas pelas organizaes.
2.6 Engenharia de Domnio

Algumas definies sobre a engenharia de domnio so:
a) Segundo Almeida, et al., (2010) a engenharia de domnio a atividade
de coletar, organizar e armazenar experincias passadas de
construo de sistemas, ou parte deles, em um domnio particular na
forma de componentes reutilizveis, assim como providenciar uma
forma adequada de reutilizar esses componentes quando estiver
desenvolvendo novos sistemas.
b) o processo de identificar e organizar o conhecimento sobre uma
classe de problemas, o domnio de problema, para dar suporte sua
descrio ou soluo Almeida, et al.,(2010).
c) Uma abordagem baseada em reutilizao para definio do escopo,
especificao da estrutura e construo de recursos para uma classe
de sistemas, subsistemas ou aplicaes. Neighbors, (1980).
Neighbors, (1980) props a primeira abordagem que trata sobre a
engenharia de domnio. Outra abordagem foi a de Prado, (1992), aonde as
principais ideias foram:
Anlise do domnio.
Especificao das linguagens do domnio.
Componentes, como um conjunto de transformaes.

O trabalho de Neighbors, (1980) teve uma grande contribuio ao
campo da engenharia de domnio, apresentando conceitos tais como:
Geradores de programas.
16

Sistemas transformveis.
Componentes.

No entanto, essas abordagens so muito difceis de serem implantadas
em um ambiente industrial, dada a complexidade da implementao. Embora
alguns avanos auxiliem essa abordagem, muitos problemas continuam sem
soluo.
STARS, (1993) auxiliou bastante o processo da engenharia de domnio,
com o STARS (Software Technology for Adaptable, Reliable Systems), que
prope um framework para disponibilizar a interao entre softwares que
utilizam reso e os que no utilizam.
Esta abordagem foi dividida em trs etapas:

a) Gesto organizacional: consiste em um alto nvel de planejamento
organizacional e aprendizado das atividades. nesse momento em
que as atividades do projeto de Engenharia de Domnio, Organizao
dos componentes e Engenharia da Aplicao so desenvolvidas. O
objetivo capturar, organizar e representar o conhecimento sobre um
domnio e produzir componentes reutilizveis que possam ser
reutilizados para construir novos sistemas que abranjam esse domnio.
b) Gesto de componentes: o objetivo adquirir, avaliar e organizar os
componentes produzidos pela engenharia de domnio e garantir que
esses componentes estejam disponveis para o uso.
c) Engenharia de aplicao: o objetivo desenvolver, manter e utilizar
os componentes desenvolvidos nessa fase.
2.6.1 Formas de Representao de um Domnio ou
Arquitetura de Domnio

A principal caracterstica do processo de representao da informao
a substituio de uma entidade lingustica longa e complexa, o texto do
documento, por sua descrio abreviada. O uso de tal sumarizao no
apenas uma consequncia de restries prticas quanto ao volume de
material a ser armazenado e recuperado. Essa sumarizao desejvel, pois
17

sua funo demonstrar a essncia do documento. Ela funciona ento como
um artifcio para enfatizar o que essencial no documento considerando sua
recuperao, sendo a soluo ideal para organizao e uso da informao.
Novellino, (1996)
Ainda segundo Novellino, (1996) o processo de representao da informao
envolve dois passos principais:
a) Anlise de assunto de um documento e a colocao do resultado
desta anlise numa expresso lingustica;
b) Atribuio de conceitos ao documento analisado;
Dentre as principais contribuies da cincia da computao no que
tange representao do conhecimento, destacam-se os modelos de
representao associados modelagem de dados, mais especificamente, o
modelo orientado a objetos, o modelo entidade-relacionamento e a ontologia
formal, campo que repensa as possibilidades representacionais e de
organizao de domnios de conhecimento.
2.6.2 Modelo de Caracterstica

Segundo Kang, et al., (1990) uma caracterstica pode ser entendida
como uma capacidade ou um aspecto visvel ao usurio e distinto de um
sistema (ou sistemas) de software. Essa modelagem pode ser realizada
atravs de diferentes notaes, cuja escolha est relacionada a diferentes
fatores como maior adequao com requisitos que atendam modelagem ou
maior conhecimento de uma equipe de desenvolvimento.
Segundo Kang, et al., (1990) o objetivo da modelagem de
caractersticas capturar e gerenciar as similaridades e diferenas, de forma
a facilitar o entendimento de clientes e desenvolvedores no que se refere s
capacidades gerais de um domnio, que so expressas atravs de
caractersticas (feature).
A modelagem deve ser suportada por um ambiente de
desenvolvimento com suporte reutilizao, a fim de torn-la eficiente e
adequada ao processo de desenvolvimento. Para isso, importante a
flexibilidade de escolha de uma notao dentro do ambiente, que deve
18

suportar a representao de diferentes notaes individualmente e a
possibilidade de transio entre elas.
A notao para modelagem de variabilidade pode ser grfica, textual
ou a combinao de ambas as formas de representao. Esse modelo prov
a base para o desenvolvimento, parametrizao e configurao de artefatos
reutilizveis. Kang, et al., (1990)
Segundo Werner, et al., (2012) para se trabalhar com a modelagem de
caractersticas alguns conceitos devem ser esclarecidos, so eles:

a) Variabilidades
o Ponto de Variao: Caracterstica que reflete a
parametrizao no domnio de uma maneira abstrata. Um
ponto de variao configurvel atravs das variantes.
o Variantes: Caractersticas que atuam como alternativa para
se configurar um ponto de variao.
o Invariantes: Caractersticas fixas, que representam
elementos no configurveis em um domnio.

b) Opcionalidade
o Elementos Opcionais: Podem ou no estar presentes nos
produtos derivados a partir da linha de produtos.
o Elementos Mandatrios: Devem obrigatoriamente estar
presentes em todos os produtos derivados a partir da linha
de produtos.
c) Relaes (Influencia fortemente o recorte para a instanciao de
uma aplicao)
o Dependncia: Relao que representa a necessidade de
seleo de elementos em conjunto.
o Mtua Exclusividade: Relao que representa a
incompatibilidade da seleo conjunto de determinados
elementos.
Como um exemplo da modelagem de caractersticas temos o
representado pela notao FODA Feature Oriented Domain Analysis Kang,
et al., (1990)
19

2.6.3 Modelagem de uma Arquitetura de Domnio

O resultado esperado DRU08 do MPS.BR fala sobre a necessidade de
uma arquitetura de domnio, cujo o objetivo central representar uma famlia
de aplicaes, onde temos que uma aplicao seria um domnio, com isso
podemos identificar quais so os ativos de domnios e como eles se
relacionam entre si, ou seja, fornecendo uma rastreabilidade.
A viso predominante neste enfoque a de que a arquitetura de
domnio a conexo entre a arquitetura da aplicao e a anlise de domnio
CZARNECKI, (1997). Assim, a arquitetura de um domnio consiste de um
modelo do domnio, incluindo uma descrio dos requisitos genricos, e de
uma arquitetura de referncia.
As organizaes reconhecem a gesto de componentes como um
processo estratgico, mas elas enfrentam alguns problemas devido
globalizao do mercado e a falta de regulamentao tanto da indstria de
software em geral como no que se refere ESBC (Engenharia de Software
Baseada em Componente). Alm disso, geralmente as arquiteturas de TI
(Tecnologia da Informao) intraorganizacionais so heterogneas e
complexas, afetando as atividades de gesto, uma vez que so compostas
por sistemas legados, plataformas de middleware, linguagens de
programao, sistemas operacionais e canais de distribuio diferentes
Hammer, (2003). De acordo com Becker, et al., (2003) a flexibilidade uma
caracterstica de sobrevivncia e o suporte arquitetura de TI requer a
integrao de sistemas legados (internos) e servios de parceiros atravs de
uma arquitetura orientada a servios (SOA). Apesar de favorecer a agilidade
nos negcios, SOA apresenta alguns desafios, como a agregao de:
a) Vrios artefatos novos.
b) Papis e responsabilidades, nas reas organizacionais.
c) Normas e custos do ciclo de vida.
A abordagem da governana SOA visa homogenizao deste
cenrio atravs do desenvolvimento de um quadro de gesto holstica
baseada em polticas de governana Niemann, et al.,(2008).
Um servio uma atividade ou conjunto de atividades de natureza
intangvel que o relacionamento entre o provedor e um consumidor. A
20

interao acontece em respostas sncronas ou assncronas Gronroos, (2006).
Na prestao de servios, existe um fornecedor que fornece algum tipo de
servio e o consumidor que consome o servio fornecido.
Um exemplo de servio seria a energia eltrica que chega nossa
casa. H a gerao, depois tem transmisso e por ltimo tem distribuio.
Para o usurio final no importa todas essas etapas, o que importa so os
benefcios que geram o servio. Com isso podemos dizer que uma das
vantagens do uso de servio seria que algo reutilizvel, que so
autnomos, abstraem de lgica, dentre outros.
O reso de servios a grande vantagem da arquitetura orientada a
servios, pois prov um aumento de produtividade, alinhamento com negcio,
melhorias para a corporao e facilidade na gerncia da tecnologia da
informao, focando em melhorias continuas e automatizando os processos,
disponibilizando qualidade nas informaes trafegadas na empresa Sobrinho,
(2013).
As vantagens oferecidas por essa arquitetura atendem as expectativas
do DRU08, so elas:
a) Reutilizao: O servio pode ser reutilizado para outras
aplicaes.
b) Produtividade: Com o reso, a equipe de desenvolvimento pode
reutilizar servios em outros projetos, diminuindo o tempo de
desenvolvimento.
c) Flexibilidade: Isolando a estrutura de um servio as mudanas
so feitas com maior facilidade.
d) Manutenibilidade: Com baixo acoplamento, facilita a
manuteno dos servios.
e) Alinhamento com o Negcio: A rea de negcio visualiza os
processos alinhados com a tecnologia.
f) Interoperabilidade: Disponibilizar servios independentemente
da plataforma e tecnologia.
g) Integrao: A integrao com outros servios, aplicativos e
sistemas legados.
h) Governana: Gerenciamento nos processos de negcio.
i) Padronizado: baseado no uso de padres.
21

j) Abstrao: Servio totalmente abstrado da sua implementao.
2.7 Engenharia de Aplicao

A Engenharia de Aplicao se dedica ao estudo das melhores tcnicas,
processos e mtodos para a produo de aplicaes, no contexto do
desenvolvimento baseado em reutilizao GRISS, (1998). Este processo de
reutilizao feito sobre produtos de uma rea de conhecimento especfica,
denominada domnio de aplicao. Um domnio de aplicao um contexto
de desenvolvimento, com escopo bem definido, para o qual sero
desenvolvidos componentes reutilizveis, atravs de um processo conhecido
como Engenharia de Domnio.
Segundo Army Reuse Center SIMOS, (1998), a Engenharia de Domnio
o processo de busca, anlise, manipulao e formalizao das informaes
do domnio relevantes para a implementao de um Programa de
Reutilizao, que promova o desenvolvimento de aplicaes do domnio a um
custo reduzido. Os modelos de domnio so o resultado final de uma
atividade de Engenharia de Domnio BRAGA, (1999) e servem de referncia
para a construo de componentes reutilizveis e de aplicaes a partir
destes mesmos componentes. Um modelo de domnio captura caractersticas
comuns e variveis dentro de uma famlia de produtos de software numa rea
especfica de aplicao GRISS, (1998).
Para o modelo de arquitetura a Instituio Implementadora ir sugerir
alguns modelos. A arquitetura tambm define padres para a utilizao eficaz
dos recursos investidos ou disponveis a fim de promover o reso e as
inovaes de forma a reduzir custos e aumentar a produtividade na TI e no
negcio. Em algumas empresas h a formao de um comit de arquitetura
que integrado por especialistas tcnicos e tem a responsabilidade de definir
os padres ou conceder excees alm de aconselhar equipes sobre
questes de arquitetura. Em alguns casos este comit se torna o principal
tomador de decises da governana de TI. Weill, et al.,( 2006).
O ideal seria que a Organizao continuasse a utilizar a arquitetura na
qual ela est mais adaptada, porm dentre os vrios modelos de arquitetura
22

a Arquitetura Orientada a Servios (SOA Service-Oriented Architecture)
uma abordagem arquitetural corporativa que permite a criao de servios de
negcio interoperveis que podem facilmente ser reutilizados e
compartilhados entre aplicaes e empresas.
Geralmente as arquiteturas de TI (Tecnologia da Informao)
intraorganizacionais so heterogneas e complexas, afetando as atividades
de gesto, uma vez que so compostas por sistemas legados, sistemas
operacionais e canais de distribuio diferentes Hammer, (2003). De acordo
com Becker, et al., (2003), a flexibilidade uma caracterstica de
sobrevivncia e o suporte arquitetura de TI requer a integrao de sistemas
legados (internos) e servios de parceiros atravs de uma arquitetura
orientada a servio (SOA) Papazoglou, (2003). Apesar de favorecer, com a
agregao de: (i) artefatos novos, (ii) papis e responsabilidades, nas reas
organizacionais, (iii) normas e custos do ciclo de vida.
2.8 Linha de Produo de Software

O conceito de Linha de Produo originado do processo
desenvolvido por Henry Ford que foi iniciado em 1913 na sua fbrica em
Highland Park. Este sistema foi idealizado aps Henry Ford ter analisado
experincias bem sucedidas como: o moinho automatizado desenvolvido por
Oliver Evans, a montagem de espingardas desenvolvida por Eli Whitney ou a
produo de revlver de Samuel Colt, entre outras experincias.
Com essa observao do mundo Henry Ford props um processo que
pode ser entendido como uma forma de produo em srie, onde vrios
operrios, com ajuda de mquinas especializadas em diversas funes
especficas e repetitivas, trabalhando de forma sequencial, chegam a um
produto semiacabado ou acabado. Graas a esse processo a Ford conseguiu
produzir em massa seu famoso carro Ford T. Ford, (2012)
Alguns autores afirmam que o principal ponto de discusso entre a
engenharia de linha de produo e a engenharia de software convencional
a presena das variaes em alguns ou todos os componentes de software.
Nos novos cenrios que abordam o ciclo de vida da linha de produo de
23

software, para os componentes de software h algumas opinies diversas a
respeito de como o software ir se comportar. Em alguns momentos durante
o processo de produo necessrio que sejam tomadas algumas decises
a respeito de qual variao ser aplicada no software e esse momento
chamado de o momento crtico ou Binding Time, pois um erro de deciso
nesse momento ir afetar toda a produo do componente. Alguns exemplos
so:
a) Reutilizao do cdigo: quando reutilizar um artefato
configurvel.
b) Desenvolvimento: durante a definio, codificao e modelagem
da arquitetura.
c) Customizao de clientes: no momento em que se customiza
algum componente para um determinado cliente.

J na produo os componentes entram na linha de produo e para
cada parte do mesmo realizada a devida modificao, de acordo como
determinado com as decises tomadas. O processo de produo o que de
fato diferencia como o produto ser entregue.
2.9 MPS.BR Programa para Melhoria de Processos do
Software Brasileiro

O MPS.BR , como a prpria sigla diz, um programa pensado para
trazer melhoria aos softwares desenvolvidos no Brasil. Esse programa teve
incio em 2003, sob a coordenao da Associao para Promoo da
Excelncia do Software Brasileiro (Softex).
O MPS.BR, composto por um modelo de referncia (MR-MPS), um
processo e um mtodo de avaliao de processos (MA-MPS) que assegura
que o MPS.BR est sendo utilizado de maneira coerente com as suas
definies. O MPS.BR tambm define um modelo de negcio (MN-MPS) para
apoiar a sua adoo pelas organizaes brasileiras. A base tcnica para
construo e aprimoramento deste modelo de melhoria e avaliao de
processos de software abrange a Norma ISO/IEC (1995) Processos de
Ciclo de Vida de Software. A definio do MPS.BR Softex (2007) tambm
24

teve a preocupao de assegurar a compatibilidade com o CMMI Chrissis, et
al., (2006).
2.9.1 Gerncia de Reutilizao

O modelo de referncia MPS.BR define o processo Gerncia de
Reutilizao (GRU) no nvel E (Parcialmente Definido) do MR-MPS-SW que
tem como propsito gerenciar o ciclo de vida de ativos reutilizveis.
O processo Gerncia de Reutilizao tem como objetivo definir
procedimentos tanto administrativos quanto tcnicos para utilizao de ativos
reutilizveis em uma organizao, estabelecendo e controlando uma
biblioteca para o armazenamento e recuperao destes ativos.
No contexto do processo de GRU, alguns papis so definidos: o
produtor o responsvel por desenvolver os ativos reutilizveis; o
consumidor quem utiliza os ativos catalogados na biblioteca de ativos
reutilizveis; e o gerente o responsvel pela gerncia da biblioteca.
Entende-se como a gerncia da biblioteca de ativos reutilizveis a superviso
de todos os passos de utilizao da biblioteca, bem como o cadastro e
controle do armazenamento dos ativos reutilizveis Softex (2007).
O processo Gerncia de Reutilizao no tem como propsito definir o
momento e a maneira que os ativos reutilizveis sero utilizados, apenas se
apresenta como um conjunto de prticas e procedimentos que viabilize a
seleo e recuperao de ativos para um dado fim. Cabe aos processos
definidos na organizao contemplar o modo como estes ativos devem ser
utilizados Softex (2007).
importante ressaltar que em um contexto onde os processos
Gerncia de Configurao e Gerncia de Reutilizao so executados
simultaneamente, a biblioteca de ativos reutilizveis cataloga e disponibiliza o
uso das liberaes (releases) de ativos sob gerncia de configurao. Sendo
assim, somente o ativo contido em uma biblioteca de ativos reutilizveis pode
ser reutilizado, pois est atrelada a ele uma liberao do repositrio de
gerncia de configurao.
Os resultados esperados de uma implantao adequada do processo
de Gerncia de Reutilizao do MR-MPS-SW em uma organizao so:
25

a) GRU1 Uma estratgia de gerenciamento de ativos documentada,
contemplando a definio de ativo reutilizvel, alm dos critrios para
aceitao, certificao, classificao, descontinuidade e avaliao de
ativos reutilizveis.
b) GRU2 Um mecanismo de armazenamento e recuperao de ativos
reutilizveis implantado.
c) GRU3 Os dados de utilizao dos ativos reutilizveis so
registrados.
d) GRU4 Os ativos reutilizveis so periodicamente mantidos, segundo
os critrios definidos, e suas modificaes so controladas ao longo do
seu ciclo de vida.
e) GRU5 Os usurios de ativos reutilizveis so notificados sobre
problemas detectados, modificaes realizadas, novas verses
disponibilizadas e descontinuidade de ativos.
2.9.2 Desenvolvimento para Reutilizao

O modelo de referncia MPS.BR define tambm um processo de
Desenvolvimento para Reutilizao (DRU) no Nvel C (Definido) do MR-MPS-
SW que tem o propsito de identificar oportunidades de reutilizao
sistemtica de ativos na organizao e, se possvel, estabelecer um
Programa de Reutilizao para desenvolver ativos a partir de engenharia de
domnios de aplicao. De todos os processos sugeridos no Nvel C do
MPS.BR somente para o (DRU) que so permitidas excluses de
resultados esperados, ou seja, a organizao pode ser avaliada na primeira
vez sem possuir esse processo, porm quando for feita a sua reavaliao o
processo j deve estar sendo executado pela organizao.
A Reutilizao de Software a disciplina responsvel pela criao de
sistemas de software a partir de software preexistente Krueger, (1992).
Diferente de reutilizao ad-hoc, que usualmente se concretiza com cpia de
trechos de artefatos preexistentes, a disciplina de Reutilizao de Software
visa sistematizar e difundir prticas de reutilizao na organizao. O
processo Desenvolvimento para Reutilizao um dos mecanismos
utilizados pela disciplina de Reutilizao de Software para esse fim.
26

Sob a dimenso de processos, o processo de Reutilizao de
Software pode ser decomposto em dois processos principais Krueger, (1992):
Desenvolvimento para Reutilizao e Desenvolvimento com Reutilizao. O
processo Desenvolvimento para Reutilizao utiliza tcnicas de engenharia
de domnio na criao de ativos reutilizveis para um domnio especfico. O
processo Desenvolvimento com Reutilizao utiliza tcnicas de engenharia
de aplicao para a incorporao de ativos reutilizveis preexistentes em
novas aplicaes.
O Desenvolvimento para Reutilizao visa aplicar tcnicas de
Engenharia de Domnio (ED) para definir o escopo, especificar a estrutura e
construir ativos reutilizveis para uma classe de sistemas, subsistemas ou
aplicaes. Esses ativos reutilizveis, por serem produzidos a partir da
Engenharia de Domnio, so denominados ativos de domnio. Os mtodos
propostos na literatura concordam que existem basicamente trs etapas
principais:
a) Anlise do domnio: determina os requisitos comuns de uma famlia
de aplicaes com o objetivo de identificar as oportunidades de
reutilizao.
b) Projeto do domnio: utiliza os resultados da anlise do domnio para
identificar e generalizar solues para os requisitos comuns, por meio
da especificao de uma arquitetura de software do domnio.
c) Implementao do domnio: transforma as oportunidades de
reutilizao e solues do projeto em um modelo de implementao,
que inclui servios tais como: a identificao, a reengenharia e/ou
construo e manuteno de ativos reutilizveis que suportem esses
requisitos e solues de projeto.
O Desenvolvimento para Reutilizao no se prope a definir quando e
como os ativos de domnio so reutilizados, papel este reservado ao prprio
processo de desenvolvimento de software. A sua atuao ocorre na criao e
evoluo desses ativos de domnio, levando em considerao a demanda
existente nos diversos projetos da organizao. Desta forma, possvel
perceber que o processo Desenvolvimento para Reutilizao atua tanto no
nvel organizacional, no que se refere criao dos ativos de domnio,
27

quanto em projetos especficos, no que se refere a solicitaes de
reutilizao dos ativos de domnio Softex, (2007).
Os resultados esperados de uma implantao adequada do processo
de Desenvolvimento para Reutilizao do MR-MPS-SW em uma organizao
so:
a) DRU1 Domnios de aplicao em que sero investigadas
oportunidades de reutilizao de ativos ou nos quais se pretende
praticar reutilizao so identificados, detectando os respectivos
potenciais de reutilizao.
b) DRU2 A capacidade de reutilizao sistemtica da organizao
avaliada e aes corretivas so tomadas, caso necessrio.
c) DRU3 Um programa de reutilizao, envolvendo propsitos, escopo,
metas e objetivos, planejado com a finalidade de atender s
necessidades de reutilizao de domnios.
d) DRU4 O programa de reutilizao implantado, monitorado e
avaliado.
e) DRU5 Propostas de reutilizao so avaliadas de forma a garantir
que o resultado da reutilizao seja apropriado para a aplicao alvo.
f) DRU6 Formas de representao para modelos de domnio e
arquitetura de domnio so selecionadas.
g) DRU7 Um modelo de domnio que capture caractersticas,
capacidades, conceitos e funes comuns, variantes, opcionais e
obrigatrios desenvolvido e seus limites e relaes com outros
domnios so estabelecidos e mantidos.
h) DRU8 Uma arquitetura de domnio descrevendo uma famlia de
aplicaes para o domnio desenvolvida e mantida por todo o seu
ciclo de vida.
i) DRU9 Ativos de domnio so especificados; adquiridos ou
desenvolvidos, e mantidos por todo o seu ciclo de vida.
2.10 Concluso

Este captulo apresentou uma anlise da bibliografia, conceituando o
termo reso em um contexto de desenvolvimento de software, apresentando
28

alguns benefcios e dificuldades relacionadas adeso do mesmo. Tambm
foi relatado o que diz o modelo de maturidade do MPS.BR nos nveis em que
o reso abordado. O prximo captulo descreve um processo para
implantao do processo de Desenvolvimento para reutilizao (DRU),
aderente a atividade do nvel C do MPS.BR.

Captulo3
Abordagem de Desenvolvimento para Reutilizao


Nesse captulo apresentada a definio de uma abordagem aderente
ao desenvolvimento para reutilizao (DRU), do nvel C do MPS.BR.
3.1 Processo

O processo proposto foi dividido em trs partes: planejamento,
implantao e execuo, conforme representado na Figura 1.


Figura 1 Processo Proposto
30

Nesse processo apresentamos os passos a serem seguidos, os
benefcios obtidos com o processo implantado e as dificuldades na
implantao do mesmo.
O objetivo de se criar um processo e no somente utilizar um j
existente, foi o fato de no ter sido encontrado, na literatura, um processo
que fosse aderente ao objetivo proposto. Por tanto, tambm no tivemos
como objetivo a execuo do mesmo. Para que seja feita a sua validao a
partir disso, somente utilizamos como base uma avaliao em pares com um
professor doutor na rea de reuso de software para chegarmos a um
processo mais maduro.
Nos tpicos a seguir iremos detalhar todas as fases do processo
proposto.
3.1.1 Planejamento

O primeiro momento quando a organizao, em busca de uma
melhoria no seu processo de construo de software, a fim de se tornar mais
competitiva no mercado, em um mdio ou longo prazo, decide por adotar
tcnicas de desenvolvimento de software que possibilitem um melhor tempo
de resposta no desenvolvimento para atender o chamado Time to Market.
Uma delas a implantao de um processo de Reutilizao de Software.
Geralmente, nesse caso, pensando nos processos do MPS.BR, a
empresa busca no mercado alguma Instituio Implementadora do MPS.BR
oficial.
Nesse momento a Instituio Implementadora ir organizao que
busca tal melhoria, a fim de observar a realidade da empresa, buscando
conhecer toda cultura organizacional, a infraestrutura, as condies
financeiras, o seu portflio de projetos passados e futuros e o grau de
importncia dos projetos para a empresa, a mdio e longo prazo. Neste
momento a Instituio Implementadora informa a necessidade de serem
realizadas algumas mudanas organizacionais como, por exemplo, a criao
de novos papis. O processo de execuo dessas atividades ser de
responsabilidade da Instituio Implementadora.
31

3.1.1.1 Atividades da Fase de Planejamento

As atividades envolvidas nessa fase esto representadas na Figura 2.

Figura 2 Fase de Planejamento
A seguir sero detalhadas as atividades desta fase:
3.1.1.1.1 Identificar Domnios de Aplicao

Nessa atividade a organizao ir mostrar Instituio
Implementadora o portflio com todos os seus domnios
2
e para cada um
deles informar a importncia organizacional do mesmo e se para esse
domnio a organizao tem alguma pretenso de futuro, ou seja, se o projeto
do referido domnio ir ser utilizado no futuro.
Um domnio tambm pode ser entendido como o projeto no qual a
organizao trabalha, por exemplo, uma empresa que possui dois grandes
projetos, um voltado para a rea acadmica e outro voltado para a rea da
sade, um desses projetos pode ser visto como domnio a ser adotado.
Analisando o MPS.BR, essa atividade est englobada na fase do
DRU01.
Para executar esta atividade necessria a participao de alguns
atores para desempenhar tal atividade, tais como: Equipe de Reutilizao,
Participantes da Organizao, Lder de Reso e a Alta Direo. Essa
atividade, por sua vez, dividida nas seguintes subatividades, conforme
apresentado na Tabela 1:

2
Domnio Conjunto de aplicaes de software que partilham de uma caracterstica em comum.
32

Tabela 1- Identificar Domnio de Aplicao
Identificar Domnios de Aplicao
Atividade Descrio
Artefato de
Entrada
Artefato de
Sada Responsvel Atores
Analisar Projetos
Passados
Identificar possveis domnios
de aplicao que podero
fazer parte do Programa de
Reutilizao
Base histrica
de projetos da
Organizao
Anlise de
Domnios de
aplicao
candidatos
Lder de
Reso
01. Equipe de
Reutilizao
02. Participantes da
Organizao
Identificar
Objetivos e Metas
Organizacionais
Para cada domnio
selecionado, verifica-se se
esto em consonncia com os
objetivos e metas de mdio e
longo prazo.
Planejamento
Estratgico
da Organizao
Anlise de
Domnios da
Aplicao
Candidatos
Lder de
Reso
01. Lder de Reso
02. Alta Direo
Selecionar
Domnios de
aplicao
candidatos
Domnios que tm uma
importncia significativa para
a empresa e possuem ativos
de domnio que possam ser
reutilizados so selecionados.
Anlise de
Domnio de
Aplicao
Candidatos
Domnios
selecionados e
matriz de
rastreabilidade
Lder de
Reso
01. Lder de Reso
02. Alta Direo

a) Analisar projetos passados

Identificar possveis domnios de aplicao que podero vir a fazer parte do
Programa de Reutilizao. Nesse momento, a empresa juntamente com a
Instituio Implementadora iro analisar a base histrica da Organizao
avaliando projetos passados para decidirem quais domnios de aplicao
devero fazer parte do Programa de Reutilizao.
b) Identificar objetivos e metas organizacionais

Ser um papel da Instituio Implementadora, conhecer os objetivos e metas
organizacionais, como por exemplo: aumentar a competitividade, diminuir o
custo no desenvolvimento, aumentar a satisfao do cliente final, dentre
33

outros. Esta identificao ir auxiliar na seleo dos domnios de aplicao
que faro parte do Programa de Reutilizao.
c) Selecionar domnios de aplicao candidatos

Aps serem executadas as subatividades anteriores, os domnios que tm
uma importncia significativa para a empresa e possuem ativos de domnio
que possam ser reutilizados so selecionados. importante ressaltar que
pode haver um domnio dentre os listados que no tenha tanta importncia
para o futuro da organizao, porm possua artefatos que podem vir a ser
reutilizados. Neste caso, esse domnio poder tambm ser selecionado.
3.1.1.1.2 Analisar Domnios com Potencial de Reutilizao

Para cada domnio selecionado observada a pretenso de futuro do
mesmo para a organizao, pois caso se trate de um domnio estratgico,
ento esse ser muito propcio de ser reutilizado. Domnios no qual a sua
importncia muito baixa ou que a dificuldade de manter seus ativos
reutilizveis sejam muito grande, no so candidatos a serem reutilizados,
passando eles a serem tratados como domnios excludos do Programa de
Reutilizao. Tais domnios sero analisados na fase de justificativa da no
adoo do processo.
Pode ocorrer tambm nessa fase, que nenhum domnio com potencial
de reutilizao seja encontrado. Nesse caso, o Programa de Reutilizao
adiado por tempo indeterminado e ser feita uma anlise peridica no mesmo
a fim de avaliar se j existe algum domnio que possa dar sequncia ao
Programa. Pensando no MPS.BR essa fase tambm engloba o DRU01.
Nessa atividade ser necessria a presena de alguns atores: Lder
Tcnico de Reso, Lder de Reso, Arquiteto da Organizao e a Alta
Direo.
Essa atividade dividida nas seguintes subatividades, conforme
apresentada na Tabela 2.

34

Tabela 2 Analisar Domnio com Potencial de Reutilizao
Analisar Domnio com Potencial de Reutilizao
Atividades Descrio
Artefato de
Entrada
Artefato de
Sada Responsvel Atores
Analisar ativos
de Domnio
pr-existentes
Para cada domnio listado nessa
fase ser feito um trabalho de
checagem dos cdigos, casos de
usos, enfim todos os artefatos
existentes nesse domnio que
podem vir a ser convertido em ativo
reutilizvel.
Domnios
selecionados
Lista de ativos
reutilizveis
Lder Tcnico
de Reso
01. Lder de Reso
02. Alta Direo
Analisar
possibilidade de
compra
Ser verificado, com a organizao
o quanto ela estaria disposta a
investir no processo, se ir comprar
componentes do mercado ou ir
desenvolv-los.
Lista de ativos
reutilizveis
- Lder de Reso
01. Lder de Reso
02. Alta Direo
Analisar
possibilidade de
modificao
Verificar qual seria a complexidade
de uma possvel modificao,
analisando a rastreabilidade e
criando um log detalhado com a
complexidade de cada ativo.
Lista de ativos
reutilizveis
Relatrio com
Informativo
dos Ativos
Lder Tcnico
de Reso
01. Lder Tcnico
de Reso
02. Arquiteto da
Organizao
Verificar se o
retorno vivel
Essa fase responsvel por analisar
se o custo que a organizao ir ter
com a implantao e manuteno
do Programa de Reutilizao ser
inferior aos ganhos estimados.
Lista com
domnios
selecionados
na fase
anterior
Anlise custo/
benfcio dos
domnios
selecionados
Lder de Reso
01. Lder de Reso
02. Alta Direo
Definir
domnios de
aplicao
Lista os domnios que foram
aprovados e os domnios que foram
reprovados.
Anlise custo/
benfcio dos
domnios
selecionados
Lista de
Domnios
Aprovados e
Reprovados
Lder de Reso
01. Lder de Reso
02. Alta Direo

35

a) Analisar Ativos de Domnios pr-existentes

Para cada domnio listado nessa fase ser feito um trabalho de checagem
dos cdigos, casos de usos, ou seja, de todos os artefatos existentes nesse
domnio que podem vir a ser convertido em ativo reutilizvel. Caso seja
identificado que no possvel ou vivel ter algum ativo reutilizvel, o
Programa ser suspenso e ser agendada uma nova verificao nos
domnios da organizao a fim de encontrar um ambiente propcio a
implantao do Processo de Reutilizao.
b) Analisar Possibilidade de Compra

Deve ser verificado junto organizao o quanto a mesma est disposta a
investir na compra de ativos no mercado ou se ir desenvolver os prprios
ativos ou somente adapt-los.
Caso a empresa opte por comprar, dever ser informado alta direo o
possvel impacto cultural, visto que o desenvolvedor no mais ir construir
um componente, mas somente utiliz-lo.
c) Analisar Possibilidade de Modificao de ativos

Verificar qual a complexidade de uma possvel modificao no ativo
reutilizvel, analisando a rastreabilidade e elaborando informaes para cada
possvel ativo. Essas informaes podem ser criadas da forma que mais se
adqe organizao. Uma possvel sugesto informar a data de criao
do ativo, a data de modificao, os pontos em que o ativo est sendo
utilizado no projeto (nesse caso pode ser o nome das classes que o
chamam), a descrio do ativo, a descrio da modificao, dentre outros.
Nesse ponto no deve ser analisado somente a complexidade de
modificao do ativo, porm a existncia de recurso disponvel para o
desenvolvimento ou modificao de um ativo. Caso os recursos sejam
escassos, a organizao dever implantar uma poltica que no venha a
prejudicar o desempenho do projeto, sendo uma opo estabelecer um prazo
mnimo de solicitao de um ativo.
36

d) Verificar se o Retorno Vivel

Essa fase responsvel por analisar se o custo que a organizao ir ter
com a implantao e manuteno do Programa de Reutilizao ser inferior
ao lucro estimado. A Alta Direo deve ficar ciente de que o retorno s ser
observado na prtica em mdio ou longo prazo, influenciando neste prazo a
curva de aprendizagem da equipe em manter o processo na prtica.
e) Definir Domnios de Aplicao

Nessa subatividade uma equipe da Organizao, juntamente com a
Instituio Implementadora listaro os domnios que faro parte do processo
de reutilizao e os domnios que foram reprovados. Os domnios reprovados
podero vir a fazer parte do processo no futuro, caso futuramente atendam
aos requisitos necessrios para que um domnio de aplicao faa parte do
Programa de Reutilizao.
3.1.1.1.3 Justificar a no Adoo do Processo

Para cada domnio reprovado ser necessrio justificar o motivo da
sua no aprovao e isso dever ser armazenado para que no final do
processo seja feita uma auditoria. A deciso de reprovao dever ser
tomada a partir da utilizao de uma abordagem para tomada de deciso,
podendo ser orientada pelo processo do MPS.BR Gerncia de Deciso
Esta atividade atende o DRU01. Tal atividade possui como artefato de
entrada os Domnios Reprovados e ter como artefato de sada um
Documento de Reprovao do Domnio.
O responsvel por esse processo o Lder Tcnico de Reso e o
Lder de Reso. Os atores envolvidos so: Arquiteto da Organizao, Lder
Tcnico de Reso e o Lder de Reso.

37

3.1.1.1.4 Avaliar Capacidade de Reutilizao Sistemtica
da Organizao

Segundo Almeida, et al.,(2010) a reutilizao de software depende de
processos sistemticos, em outras palavras o reso no acontece por
acidente.
Nessa atividade a empresa e a Instituio Implementadora iro
analisar as caractersticas da organizao para ver sua capacidade para
reutilizao sistemtica de software. Alm disso, identificar os pontos fortes e
as dificuldades da empresa para sistematizar o reso de software. Esta
atividade atende ao DRU02 do MPS.BR e composta pelas subatividades
que esto apresentadas na Tabela 3.

Tabela 3 Avaliar Capacidade de Reutilizao Sistemtica da Organizao
Avaliar Capacidade de Reutilizao Sistemtica da Organizao
Atividade Descrio
Artefato de
Entrada
Artefato de
Sada Responsvel Atores
Analisar
Recursos
Humanos
Analisar a possibilidade de
criao de uma nova equipe
que trabalhe com o reso ou a
incluso de novas atividades
na equipe.
Lista de
colaboradores
responsveis por
essa atividade
Tabela
relacionando o
colaborador a
sua funo
Alta Direo
01. Lder de Reso
02. Lder Tcnico de
Reso
03. Arquiteto da
Organizao
Analisar
Recursos
Financeiros
Verificar a disponibilidade
para compra de ativos no
mercado e adaptao do
processo para a realidade da
organizao.
Lista de objetivos
de cada projeto
Estimativa de
Oramento
Lder Tcnico
de Reso
01. Lder Tcnico de
Reso
02. Lder de Reso
03. Alta Direo
Analisar
Infraestrutura
Analisar se a infraestrutura
disponibilizada pela
organizao est apta para o
recebimento do processo a ser
implantado.
Lista de
equipamentos e
Infraestrutura da
Organizao
Checklist de
Melhorias
Lder Tcnico
de Reso
01. Lder Tcnico de
Reso
02. Responsvel pela
Infraestrutura da
Organizao
Analisar
Aspectos
Culturais
Verificar o impacto cultural
com a equipe que ser afetada
com o Projeto Proposto.
-
Relatrio com
as expectativas
dos membros
Membro da
Equipe
de Reso
01. Equipe da
Organizao
02. Membro da
38

da organizao
e
pontosnegativo
s culturais
Equipe de Reso
Aferir
capacidade de
Reutilizao
Sistemtica da
Organizao
Realizar julgamento em
relao a capacidade de
Reutilizao Sistemtica da
Organizao.
Todos os
resultados
dessa fase
Relatrio de
Aprovao
Lder de
Reso
Lder de Reso

a) Analisar Recursos Humanos

Nesta subatividade a empresa e a Instituio Implementadora iro analisar se
a Organizao dispe de uma equipe que venha a dar suporte ao Processo
de Reutilizao. A inexistncia de uma equipe qualificada pode ser um fator
para um possvel cancelamento do Processo.
b) Analisar Recursos Financeiros

Nesta subatividade, a empresa e a Instituio Implementadora iro analisar
se a organizao possui recursos financeiros necessrios para implantar o
Programa de Reutilizao. de extrema importncia informar para a Alta
Direo que o retorno do investimento no ser imediato. Caso a
organizao tenha decidido comprar ativos no mercado, importante calcular
o quanto ser necessrio disponibilizar para esse fim.
c) Analisar Infraestrutura

Nesta subatividade, a empresa e a Instituio Implementadora analisaro se
a infraestrutura disponibilizada pela organizao est apta para o
recebimento do processo a ser implantado.

39

d) Analisar Aspectos Culturais

Nesta subatividade a empresa juntamente com a Instituio Implementadora
devero identificar aspectos culturais, como por exemplo: crenas, valores,
hbitos, dentre outros que podem influenciar positivamente ou negativamente
a implantao do Processo de Reutilizao.
e) Aferir a Capacidade de Reutilizao Sistemtica da Organizao

Realizar julgamento em relao capacidade de Reutilizao Sistemtica da
Organizao. Nessa subatividade o Lder Tcnico ir analisar todos os
resultados e ir informar o estado real da organizao para a Alta Direo.
Com isso, ser decidido se o processo de reutilizao ser ou no adiado e
se houver motivo para ser adiado quais os motivos que levaram a isso. A
Instituio Implementadora dever, de forma clara, apresentar um raio-X da
Organizao do ponto de vista da Capacidade de Reutilizao Sistemtica.
3.1.1.1.5 Gerar Plano de Ao

Nessa atividade a empresa em conjunto com a Instituio
Implementadora ir, elaborar um plano de ao que contemple aes que
venham solucionar os pontos fracos encontrados na organizao, como por
exemplo: realizao de treinamentos, aquisio de novos equipamentos ou
uma mudana na estrutura organizacional.
3.1.1.1.6 Planejar Programa de Reutilizao

Esta atividade pode ser executada em paralelo ao plano de ao,
porm a implantao s ser iniciada quando todas as aes definidas forem
finalizadas. Neste momento ser informada organizao como ser
realmente executado o processo, definindo marcos, metas a serem atingidas,
dentre outros. Essa fase atende ao DRU03 do MPS.BR.
Alm disso, esta atividade dividida nas subatividades apresentadas
na Tabela 4.
40

Tabela 4 Planejar Programa de Reutilizao
Planejar Programa de Reutilizao
Atividade Descrio
Artefato de
Entrada
Artefato de
Sada Responsvel Atores
Definio de
Propsito
Definir o propsito do
Programa de Reutilizao
Objetivos
organizacionais
Propsito do
Programa de
Reutilizao
Lder Tcnico
de Reso e o
Lder de
Reso
01. Lder de Reso
02. Lder Tcnico
de Reso e Alta
Direo
Definio de
Escopo
(Cenrio)
Definir as unidades
organizacionais, os domnios
de aplicao e os tipos de
ativos de domnio que faro
parte do Programa de
Reutilizao
Propsito do
Programa de
Reutilizao
Escopo do
Programa de
Reutilizao
Lder Tcnico
de Reso
01. Lder Tcnico
de
Reso
02. Arquiteto da
Organizao
Definio de
Metas
Definir as metas do
Programa de Reutilizao
Propsito do
Programa
de
Desenvolvimento
para Reutilizao
Metas do
Programa de
Reutilizao
Lder de
Reso
01. Lder de Reso
02. Alta Direo
Planejar o
Programa de
Reutilizao
Elaborar o Plano do Projeto
de Desenvolvimento para
Reutilizao
Propsito, Escopo
e Metas do
Programa de
Reutilizao
Plano de
Projeto do
Programa de
Reutilizao
Lder de
Reso
01. Lder de Reso
02. Alta Direo

a) Definio de Propsito

Nessa subatividade sero definidos todos os marcos de todas as
subatividades de implantao. Tambm ser definido o propsito da
Organizao em relao ao Programa de Reutilizao, aonde sero
especificadas algumas mtricas que iro auxiliar a Organizao a visualizar
se o processo est caminhando rumo ao propsito traado.
41

Com o uso de mtricas a organizao poder avaliar o retorno do
investimento (ROI) e tambm poder avaliar o que est sendo reutilizado e
como est sendo reutilizado.
b) Definio de Escopo (Cenrio)

Para essa fase sero listados os domnios aprovados e para cada um deles
ser definido quais so as unidades organizacionais afetadas, quais ativos
fazem parte desse domnio, quais processos sero afetados. O objetivo
dessa anlise definir as fronteiras entre os domnios de aplicao
existentes na organizao. Com a classificao desses domnios a
organizao ir ser beneficiada, pois trar um maior conhecimento a respeito
de seus ativos. Salientando que no somente cdigo que considerado um
ativo reutilizvel.
c) Definio de Meta

Para cada domnio sero definidas algumas metas de curto, mdio e longo
prazo. Essas metas podem contemplar etapas a serem cumpridas para que o
objetivo organizacional seja atingido.
d) Elaborar o Plano de Reutilizao

Nessa fase ser elaborado o Plano de Reutilizao em si, ou seja, a empresa
juntamente com a Instituio Implementadora iro planejar o processo de
desenvolvimento para reutilizao. Esse processo ser definido de acordo
com a realidade da empresa.
Este processo pretende definir as tarefas do administrador do Processo de
Reutilizao que utilizado para planejar, estabelecer, gerenciar, controlar e
monitorar o Programa de Reutilizao da Organizao.
O que se observa nas experincias com implantaes de reso que, no
somente os benefcios aumentam com o nvel de reso, mas tambm os
riscos e custos envolvidos JACOBSON, (1997). Este o motivo de vrios
autores sugerirem que um Programa de Reutilizao deva ser introduzido
42

atravs de projetos piloto e crescer medida que a organizao se torne
mais madura.
3.1.2 Implantao

Nesse momento a organizao j est comprometida com o processo
e j definiu qual ser o seu projeto piloto, o objetivo a ser atingido com o
mesmo, as suas metas de curto, mdio e longo prazo e definiu algumas
mtricas para acompanhar o andamento do processo.
Tendo tudo isso, a Empresa Implementadora, com base no Processo
de Reutilizao que foi definido comea a implantao do processo, para isso
necessrio que todos os pontos de melhoria definidos na fase anterior
tenham sido atendidos, tais como infraestrutura necessria, recursos
humanos, recursos financeiros e outros, que por ventura, a Instituio
Implementadora tenha sugerido. Caso esses pontos de melhoria no tenham
sido atendidos o processo ser adiado por um tempo indeterminado at que
todos eles j estejam devidamente implementados.
Um ponto importante dessa fase que todas as atividades so
monitoradas e avaliadas tentando manter uma melhoria constante do
processo.
3.1.2.1 Atividades da Fase de Implantao

As atividades envolvidas nessa fase esto descritas na Figura 3.


Figura 3 Fase de Implantao
43

3.1.2.2 Implantar Programa de Reutilizao

Parte mais tcnica, onde a equipe de reutilizao ir decidir se a
organizao j tem todos os pr-requisitos bsicos necessrios para a
implantao do processo, caso a resposta da avaliao seja negativa, o
processo ser adiado por tempo indeterminado e periodicamente ser
analisada a possibilidade do incio do projeto. Essa atividade atende o
DRU04 do MPS.BR.
No caso de o processo vir de fato a ser implantado, essa fase, por sua
vez, ser dividida nas subatividades da Tabela 5.

Tabela 5 Implantar Programa de Reutilizao
Implantar Programa de Reutilizao
Atividade Descrio
Artefato de
Entrada
Artefato de
Sada Responsvel Atores
Implantar
infraestrutura
necessria
Implantar infraestrutura
necessria para que o Programa
de Reutilizao possa ser
implantado, executado e
mantido.
Plano de Projeto
do Programa de
Reutilizao
Relatrio de
aprovao de
infraestrutura
Lder tcnico
de reso
01. Lder Tcnico de
Reso
02. Responsvel pela
Infra da Organizao
Identificar e
realizar
treinamento
Identificar e realizar
treinamentos necessrios para a
implantao e manuteno do
Programa de Reutilizao.
Plano de Projeto
do Programa de
Reutilizao
Lista de
treinamentos
necessrios e
realizados
Lder tcnico
de reso
01. Lder Tcnico de
Reso
02. Gerncia da
Organizao.
Alocar equipes
Identificar e alocar os
profissionais mais adequados no
Programa de Reutilizao.
Matriz de
competncias
Lista de
funcionrios
responsveis
por cada
atividade
Lder tcnico
de reso
01. Lder Tcnico de
Reso
02. Gerncia da
Organizao.
Desenvolver
ou Adaptar
repositrio
Desenvolver ou adaptar um
repositrio para os ativos
reutilizveis dos domnios que
-
Repositrio de
ativos
reutilizveis
Lder tcnico
de reso
01. Lder Tcnico de
Reso
02. Arquiteto da
44

com artefatos
existentes
fazem parte do Programa de
Reutilizao.
Organizao
03. Gerente de
Configurao
Definir
domnio piloto
Escolher um domnio de
aplicao para ser utilizado como
piloto, de forma que se possa
avaliar os pontos fortes e fracos
do que foi planejado e
disponibilizado.
Lista de domnios
de aplicao que
faro parte do
Programa de
Reutilizao
Domnio piloto Lder de reso
01. Lder de Reso
02. Lder Tcnico de
Reso
03. Arquiteto da
Organizao
04. Alta Direo

a) Implantar Infraestrutura Necessria

Sabendo qual o objetivo da organizao a empresa, juntamente com a
Instituio Implementadora, ir prover a infraestrutura necessria para o
desenvolvimento do Programa de Reutilizao. A implantao da
infraestrutura pode ser feita em partes, ou seja, na medida em que o
processo de reutilizao for sendo implantado.
b) Identificar Necessidade de realizar treinamento

Para o processo a ser implantado ser necessria a identificao dos
treinamentos que auxiliaro na implantao e execuo do processo de
reutilizao.
c) Alocar Equipes

Nesta subatividade, a empresa identifica os profissionais que tm perfil mais
adequado para trabalhar no Programa de Reutilizao. Tais colaboradores
podero trabalhar exclusivamente neste programa ou desempenhar outros
papis na empresa.

45

d) Desenvolver ou Adaptar Repositrio de artefatos reutilizveis

Nesse momento a organizao ir decidir por desenvolver ou adaptar um
repositrio de ativos reutilizveis j existentes ou que ser adquirido.
Normalmente, tal repositrio oferece as seguintes funcionalidades: (i)
Pesquisar (por texto livre, palavra-chave, caracterstica); (ii) gerar relatrios;
(iii) disponibilizar espao para notificaes dos usurios; (iv) prover servio de
manuteno; (v) permitir o versionamento do ativo; (vi) possibilitar o
gerenciamento de dependncias; dentre outros.
e) Definir domnio piloto

Nesta subatividade, a empresa seleciona um domnio para ser o domnio
piloto do Programa de Reutilizao.
Essa fase segundo JACOBSON, (1992) muito importante, pois o mesmo
sugere que se comece pequeno e que cresa de acordo com a aprovao da
tecnologia, ou seja, ir adaptando o processo em outros domnios na medida
em que a organizao fique mais madura em relao ao seu processo. Ainda
segundo JACOBSON, (1992) o primeiro projeto utilizando uma nova
tecnologia , frequentemente, uma avaliao desta tecnologia. Portanto a
organizao, tendo a lista de seus domnios aprovados, ir selecionar qual
ser o menos critico para ser colocado como projeto piloto, onde ser
implantado inicialmente um mdulo do projeto, para que no haja um impacto
muito grande na produo do mesmo. A medida que as alteraes forem
sendo aprovadas, outros mdulos sero implantados at que o Processo de
Reutilizao seja implementado em todos os mdulos do projeto piloto.
3.1.2.3 Selecionar forma de Representao para Modelo de
Arquitetura e de Domnio

Essa atividade apresenta alguns aspectos importantes para um
processo de Engenharia de Aplicao e Engenharia de Domnio,
consequentemente, identificando os requisitos necessrios para que este tipo
de abordagem possa ser utilizado num processo efetivo de construo de
46

aplicaes com reutilizao. Por meio da Engenharia de Domnio so
elaborados um modelo arquitetural e um modelo de domnio.
O objetivo desta atividade selecionar a forma como o Modelo de
Domnio e o Modelo de Arquitetura sero apresentados.
Essa atividade engloba o DRU06 do MPS.BR. As subatividades
relacionadas com essa fase esto resumidas na Tabela 6 abaixo e descritas
a seguir:

Tabela 6 Selecionar forma de Representao para Modelo de Arquitetura de
Domnio
Selecionar forma de Representao para Modelo de Arquitetura de Domnio
Atividade Descrio
Artefato de
Entrada
Artefato de
Sada Responsvel Atores
Identificar
formas de
representao
Identificar possveis formas de
representao para Modelo de
Arquitetura e de Domnio.
-
Lista com
possveis
formas de
representao
01. Responsvel
tcnico;
02. Arquiteto;
01. Responsvel
tcnico;
02. Arquiteto;
Escolher forma
a ser
representada
na organizao
Selecionar a melhor forma para a
empresa representar o Modelo de
Arquitetura e de Domnio.
Lista com
possveis formas
de representao
Modelos de
representao
selecionados
Responsvel
Tcnico
Responsvel
Tcnico

a) Identificar formas de representao

O objetivo desta subatividade pesquisar as formas de representao para
Modelos de Domnio e Modelos de Arquitetura, identificando os pontos fortes
e fracos de cada abordagem.
b) Escolher forma a ser utilizada na organizao

O objetivo desta subatividade escolher a melhor forma de representao
para os Modelos de Domnio da Organizao, considerando as
caractersticas da organizao, dos domnios de aplicao e dos projetos de
47

software. O modelo a ser adotado ir utilizar os princpios do modelo de
caracterstica.
3.1.2.4 Estabelecer e manter o Modelo de Domnio

Nesta atividade, a empresa estabelece e mantm os seus modelos de
domnio. Para cada domnio que possui potencial de reutilizao,
necessrio que se estabelea as suas fronteiras com domnios correlatos,
isso auxilia na identificao do contexto do domnio.
O modelo que ser definido dever ser utilizado por todos os domnios
da aplicao, ou seja, os modelos de domnio devero estar sob Gerncia de
Configurao. Visto que os ativos de domnios construdos a partir deles
sero utilizados por diferentes projetos da organizao, qualquer modificao
no modelo de domnio que no for controlada poder trazer graves
consequncias para o projeto.
O Modelo de Domnio a representao visual das classes
conceituais ou objetos do mundo real em um domnio de problema e, deve
representar a compreenso da informao que o sistema vai gerenciar. Por
sua vez o Modelo de Domnio identifica os conceitos relacionados a
requisitos do sistema e auxilia a analisar o problema sob a perspectiva
conceitual. um artefato que representa o domnio do problema, portanto,
no utilizado para modelar a arquitetura de software (diagrama de classes
de projeto), pois esta, embora inicialmente derivada do modelo conceitual
pertence ao domnio da soluo.
Assim, o Modelo de Domnio deve ser independente da soluo fsica
que vir a ser adotada e deve conter apenas elementos referentes ao
domnio do problema em questo, ficando para a fase de projeto os
elementos da soluo, como por exemplo: interfaces, formas de
armazenamento (banco de dados), segurana de acesso, comunicao,
dentre outros.
Essa atividade atende ao DRU07 do MPS.BR.
A Tabela 7 apresenta mais informaes sobre esta atividade.

48

Tabela 7 - Estabelecer e Manter Modelo de Domnio
Estabelecer e Manter Modelo de Domnio
Atividade Descrio
Artefato de
Entrada Artefato de Sada Responsvel Atores
Definir
metodologia de
apresentao
Definir uma forma na qual o
modelo ser apresentado para
a organizao.
Modelos de
representao
selecionados
Institucionalizao do
Modelo de Domnio
de cada domnio de
aplicao
Lder tcnico
de reso
01. Lder Tcnico
de Reso;
02. Equipe de
reutilizao da
organizao;

a) Definir metodologia de apresentao

Para a apresentao do modelo, o mesmo ser colocado em um local de
destaque para que toda a equipe tenha acesso ao Modelo de Domnio que
ser adotado pela Organizao e em um outro momento ser apresentado de
forma mais sistemtica para a equipe envolvida.
3.1.2.5 Estabelecer e manter Modelo de Arquitetura

Sabendo qual o modelo de arquitetura adotado pela Organizao, a
Instituio Implementadora ir definir melhorias na arquitetura de modo que a
mesma fique aderente ao Processo Proposto.
Tais melhorias visam a fazer que a arquitetura de domnio proposta
possa fazer uma perfeita conexo entre a arquitetura da aplicao e o
modelo de domnio proposto.
A Tabela 8 apresenta informaes adicionais sobre a atividade.





49


Tabela 8 Estabelecer e Manter Modelo de Arquitetura
Estabelecer e Manter Modelo de Arquitetura
Atividade Descrio
Artefato de
Entrada Artefato de Sada Responsvel Atores
Estabelecer e
Manter Modelo
de Arquitetura
Estabelecer, institucionalizar
e manter o Modelo de
Arquitetura de cada um dos
domnios de aplicao.
Modelos de
representao
selecionados
Institucionalizao
do Modelo de
Domnio de cada
domnio de
aplicao
Lder tcnico
01. Lder tcnico
da organizao;
02. Arquiteto da
organizao;

a) Definir metodologia de apresentao

Para a apresentao ser feito um sistema teste demonstrando a forma que
a arquitetura ser utilizada, com seus benefcios e resultados esperados.
Alm de construir um quadro demonstrando um passo a passo de utilizao
da arquitetura definida, que estar disponvel no wiki da empresa ou em
quadros espalhados pela organizao.
3.1.2.6 Monitorar e avaliar o processo

Esta atividade tem como principal objetivo, monitorar e avaliar a
execuo do Processo, de maneira que se possa identificar oportunidades de
melhoria que venham evoluir a abordagem proposta.
3.1.3 Execuo

Nesse momento o Processo j foi implantado na organizao e o
projeto piloto j est sendo executado.
Processos de solicitao de ativos so implantados e um responsvel
da equipe de reutilizao ir definir uma prioridade de implementao para
cada uma das solicitaes e tambm ir definir se o ativo ser implementado
50

ou adquirido do mercado. Aps essa anlise o solicitante ir receber um
retorno informando o prazo de entrega do mesmo.
A equipe de reutilizao da organizao ir atuar no desenvolvimento
dos ativos e na identificao contnua de possveis novos ativos a serem
implementados ou adaptados. A rastreabilidade dos ativos ser mantida de
forma integral, informando qualquer mudana e verificando se h algum ativo
que no est sendo utilizado por um perodo a ser definido pelo administrador
dos ativos. Se houver algum ativo que se enquadre nesse perfil o mesmo
ser descontinuado e essa ao ser documentada.
3.1.3.1 Atividades da Fase de Execuo

As atividades envolvidas nessa fase esto apresentadas na Figura 4.


Figura 4 Fase de Execuo
3.1.3.2 Elaborar Proposta de Reutilizao

Inicialmente, aps a definio do projeto o responsvel tcnico da
equipe, sabendo o escopo a ser desenvolvido, identifica os possveis pontos
de implementao que podero ter a necessidade de criao de novos ativos
reutilizveis. Identificando isso o mesmo ir pesquisar na base de ativos se
h algum ativo que atenda a sua necessidade integralmente, parcialmente ou
que no atenda. Se houver um ativo que atenda a sua necessidade
integralmente o responsvel pela equipe s ir informar, nos comentrios do
51

ativo, o local onde o mesmo est sendo utilizado para que a sua base de
rastreabilidade seja atualizada.
Caso o mesmo atenda s em parte ou no haja nenhum ativo que
atenda a essa necessidade, o responsvel tcnico dever informar a equipe
de reutilizao a sua necessidade, por meio de um relatrio de proposta de
reso. E este documento dever ser bem tcnico, porm com um
embasamento relacionado ao negcio em questo. No caso de atender em
parte, o ativo poder ser adaptado para a nova realidade, contanto que seja
garantida a sua rastreabilidade.
Essa atividade possui uma nica subatividade que est apresentada
na Tabela 9:

Tabela 9 Elaborar Proposta de Reutilizao
Elaborar Proposta de Reutilizao
Atividade Descrio
Artefato
de Entrada Artefato de Sada Responsvel Atores
Enviar Proposta
de Reso
Enviar uma proposta
de reso, para que a
sua viabilidade seja
avaliada.
-
Sugesto de melhoria ou
necessidade de
desenvolvimento de um
novo ativo reutilizvel
Lder tcnico
de reso
01. Lder tcnico de
reso;
02. Responsvel
tcnico por projeto;

a) Enviar Proposta de Reso

O objetivo desta subatividade enviar uma proposta de reso, que um
documento onde ser formalizada a solicitao de criao de um ativo de
domnio. Esta proposta, poder ter os seguintes retornos:
a) Ser acatada, ou seja, o ativo ser desenvolvido conforme solicitado.
b) Atendida parcialmente, onde cabe ao responsvel pela equipe de
reutilizao avaliar o pedido e conforme o seu conhecimento dos
domnios identificar outra soluo que tambm atenda ao pedido
solicitado. Como tambm desenvolver uma parte do que foi
solicitado e reprovar outra parte, fundamentando tal reprovao.
52

c) Reprovada, onde a solicitao no ser atendida e a reprovao
dever ser justificada.
O relatrio dever conter as seguintes informaes:
a) Motivao, onde dever ser informado o real motivo da
necessidade.
b) Projeto(s) que a solicitao est(o) associado(s).
c) Importncia Organizacional, onde ser informado qual o nvel de
importncia do ativo para o projeto e qual o nvel de importncia do
projeto para a organizao.
d) Detalhe Tcnico, onde podem ser registradas dicas para o
desenvolvimento, como por exemplo, um possvel padro de
projeto a ser utilizado.
e) Prazo do Projeto, onde o responsvel tcnico informar qual o
deadline do projeto e nesse ponto o mesmo poder sugerir a
compra do ativo no mercado.
f) Observaes Gerais, campo de livre preenchimento onde o
responsvel tcnico poder informar os benefcios que o ativo ir
trazer para projetos futuros ou ressaltar a importncia que o projeto
tem para a organizao e o ganho que o ativo ir proporcionar ao
mesmo.
3.1.3.3 Identificar Possveis Ativos de Reutilizao

Nessa atividade a equipe responsvel pela Gerncia de Reutilizao e
a equipe de desenvolvimento da organizao, que utilizam os ativos
desenvolvidos ou comprados, podero sugerir melhorias ou novos ativos
para serem desenvolvidos. Neste caso, a solicitao do ativo no precisa
estar diretamente relacionada a um projeto que a organizao esteja
implementando ou ir implementar. Esta atividade composta das
subatividades, que esto apresentadas na Tabela 10.



53

Tabela 10 Identificar Possveis Ativos de Reutilizao
Identificar Possveis Ativos de Reutilizao
Atividade Descrio Artefato de Entrada
Artefato de
Sada Responsvel Atores
Analisar
Proposta dos
Usurios
Analisar as propostas de reso
que foram encaminhadas
pelos usurios dos ativos
reutilizveis.
Sugesto de melhoria
ou necessidade de
desenvolvimento de um
novo ativo reutilizvel
Laudo de
avaliao
Lder tcnico
01. Lder tcnico
de reso;
02. Membro da
equipe de
desenvolvimento;
Analisar
Proposta da
Equipe de Reso
Analisar as propostas de reso
que foram encaminhadas
pelos membros da equipe de
reso.
Sugesto de melhoria
ou necessidade de
desenvolvimento de um
novo ativo reutilizvel
Laudo de
avaliao
Lder tcnico
01. Lder tcnico
de reso;
02. Membro da
equipe de
desenvolvimento;
Manter
Rastreabilidade
Armazenar os ativos
reutilizveis na Biblioteca de
Ativos Reutilizveis e garantir
que esto sob a Gerncia de
Configurao.
-
Histrico de
Configurao
dos ativos
reutilizveis
Membro da
equipe de
reso
Membro da equipe
de reso
Tomar Deciso
em Relao s
Propostas
Decidir, aps a anlise, se a
proposta de reso ser aceita
ou no. Caso seja aceita,
deve-se decidir sobre a
compra ou desenvolvimento
do ativo reutilizvel.
Laudo de avaliao
Termo de
aceite
Lder tcnico Lder tcnico

a) Analisar Proposta dos Usurios

O objetivo desta subatividade analisar as propostas que os usurios dos
ativos reutilizveis enviaram para a Equipe de reso. Dentre as solicitaes
podem haver tambm o pedido de adaptao de um ativo j existente ou a
criao de um ativo novo.
Para o caso de a sugesto ser a adaptao de um determinado ativo, o
usurio dever informar detalhadamente o ponto onde o ativo se encontra,
justificando o motivo da alterao.
54

Ao final de toda anlise gerado, pela equipe de reso, um parecer positivo
ou negativo.
b) Analisar Proposta da Equipe de Reso

O objetivo desta subatividade analisar as propostas de adaptao de um
ativo de reso j existente ou a criao de um novo ativo, que vieram da
prpria equipe de reso. Ao final gerado um parecer, que elaborado pela
equipe de reso.
c) Manter Rastreabilidade

O objetivo desta subatividade garantir a rastreabilidade e o devido controle
de verses dos ativos que foram modificados ou dos novos ativos. Para isso,
necessrio seguir o fluxo do controle de verso, onde o usurio
responsvel pela atualizao ou modificao do ativo dever descrever o
ponto onde esse ativo ser utilizado, bem como fornecer um comentrio
relativo a melhoria proporcionada.
d) Aprovar a Deciso

Aps a anlise das solicitaes, o ativo ser aprovado ou reprovado e o
responsvel pela equipe de reutilizao ir entrar em contato com o
solicitante do ativo, informando o estado do seu pedido e a data prevista para
a entrega do mesmo. Alm disso, dever informar onde o ativo ir ficar
disponvel e se o ativo foi desenvolvido pela equipe de reso ou se o mesmo
foi adquirido no mercado. Para o caso de aquisio, dever informar se um
ativo caixa branca ou no, ou seja, se o cdigo est disponvel para futuras
alteraes.
3.2. Concluso do Captulo

Este caputlo apresentou o Processo de Desenvolvimento para
Reutilizao proposto nesta dissertao. Aps o processo ter sido definido,
55

foi submetido anlise de um professor doutor na rea de reso de software,
tendo sido avaliado com sucesso. Aps isso, este processo foi apresentado a
quatro empresas cearenses que possuam os nveis E e C no MPS.BR. O
prximo captulo apresentar o resultado da anlise qualitativa realizada, a
partir dos dados coletados das empresas que conheceram a proposta do
processo e foram entrevistadas.

Captulo4
Pesquisa Qualitativa utilizando Procedimentos da Grounded
Theory


Este captulo apresenta a abordagem utilizada na pesquisa qualitativa,
conhecida como Grounded Theory, e os resultados obtidos, mostrando o
relacionamento dos fatores relevantes para a adoo do processo de
Desenvolvimento para Reutilizao.
4.1 Introduo

Creswell,(1997) aponta cinco tipos de mtodos qualitativos: pesquisa
narrativa, pesquisa fenomenolgica, pesquisa com Grounded Theory,
pesquisa etnogrfica e pesquisa baseada em estudo de caso. O tipo de
pesquisa que tem sido adotada em estudos na rea de Engenharia de
Software e obtido bons resultados o mtodo Grounded Theory ou Teoria
Fundamentada em Dados (TFD) Adolph, et al., (2008)
A Teoria Fundamentada em Dados ou TFD foi criada por Glaser e
Strauss em 1967 com o intuito de obter uma teoria por meio da coleta e
sucessivas anlises (saturao terica) dos dados.
Dessa forma, para capturar e representar melhor os conhecimentos
sobre os fatores que influenciam positivamente e negativamente na adoo
do Desenvolvimento para Reutilizao por parte de algumas empresas
cearenses qualificadas no MPS.BR nveis E e C, realizou-se uma pesquisa
qualitativa, que se baseia nos processos sugeridos por Straus, et al., (1998)
para o mtodo Grounded Theory (GT). Visando facilitar o entendimento de
como se desenvolveram os estudos, a seo 4.2 busca mostrar os principais
conceitos da GT, a seo 4.3 disserta sobre a aplicao desses conceitos
nesta pesquisa e a seo 4.4 mostra os resultados obtidos com esta
pesquisa.
57

4.2 Metodologia de Pesquisa Grounded Theory

A Grounded Theory Straus, et al., (1998) visa originar, a partir dos
dados coletados, uma ou mais teorias que expliquem o que foi observado
nesses dados. Isso feito atravs da criao de categorias e
relacionamentos entre as mesmas e permite extrair informaes teis de
dados que a princpio formavam um grande volume de dados
desestruturados. Dessa forma, a teoria que resulta desta abordagem se
parece mais com a realidade do que uma teoria derivada de maneira
diferente, como a partir da reunio de uma srie de conceitos baseados em
experincia ou somente por meio de especulao. Teorias fundamentadas,
por serem baseadas em dados, tendem a melhorar o entendimento de um
contexto e fornecer um guia importante para ao Straus, et al., (1998).
Apesar de ter sido originada nos anos 60 e ter sido extensivamente
aplicada nas reas de cincias sociais, o uso da Grounded Theory (GT) em
estudos na rea de desenvolvimento de software no muito comum, sendo
geralmente restrita a investigar questes tecnolgicas na rea de Sistemas
de Informao Montoni, et al., (2010). A aplicao da GT nas reas de
engenharia de software e melhoria de processo ainda mais escassa, como
em Montoni, et al., (2010). No Brasil, temos alguns trabalhos de Engenharia
de Software que utilizaram GT, como por exemplo, Conte, (2001),Schots,
(2010), Montoni, (2010) e Almeida, (2011).
Como os criadores da GT divergiram sobre alguns pontos, logo o
mtodo dividiu-se em duas vertentes. Uma delas defendida por Glaser,
(1992) e enfatiza a caracterstica emergente do mtodo e os processos
indutivos desenvolvidos pioneiramente pelo Departamento de Sociologia da
Universidade de Columbia nos anos 50 e 60. A outra linha foi desenvolvida
por Strauss, (1987) e consolidada em Straus, et al., (1998), com o objetivo de
sistematizar o mtodo de coleta e anlise de dados.
A caracterstica prescritiva da linha defendida por Strauss tida como
uma das razes pelas quais essa linha tem sido mais amplamente adotada
em estudos qualitativos na rea de Engenharia de Software. Portanto, no
contexto dessa dissertao, a linha de pesquisa adotada ser baseada em
alguns procedimentos sugeridos por Straus, et al., (1998).
58

Segundo a linha proposta por Strauss, (1987), GT baseada na ideia
de codificao (coding), que o processo de analisar os dados. Durante a
codificao, so identificados conceitos (ou cdigos) e categorias. Um
conceito (ou cdigo) atribui nome a um fenmeno de interesse para o
pesquisador e abstrai um evento, objeto, ao, ou interao que tem um
significado para o pesquisador Straus, et al., (1998). Categorias so
agrupamentos de conceitos unidos em um grau de abstrao mais alto.
O processo de codificao pode ser dividido em trs fases: codificao
aberta, axial e seletiva. A codificao aberta envolve a quebra, a anlise, a
comparao, a conceituao e a categorizao dos dados. Segundo
Bandeira-de-melo, et al., (2006), nas fases iniciais da codificao aberta, o
pesquisador explora os dados examinados, minuciosamente, aquilo que lhe
parece relevante, devido leitura dos textos. Na fase de codificao aberta,
os incidentes ou eventos so agrupados em cdigos atravs da comparao
incidente-incidente.
Os cdigos gerados podem ser classificados como: cdigos de
primeira ordem, diretamente associados s citaes (chamadas cdigos in
vivo); e cdigos abstratos ou tericos, associados a outros cdigos, sem,
necessariamente, estarem ligados a alguma citao. Tambm na codificao
aberta, realizada a criao de categorias que agregam os cdigos para
reduzir o nmero de unidades com as quais o pesquisador ir trabalhar
Montoni, et al., (2010).
Aps a identificao de categorias conceituais pela codificao aberta,
a codificao axial examina as relaes entre as categorias que formam as
proposies da teoria substantiva Bandeira-de-melo, et al., (2006).
Explicitam-se causas e efeitos, condies intervenientes e estratgias de
ao em proposio que devem ser testadas novamente nos dados.
Para facilitar a codificao axial, deve ser utilizado um modelo que
defina como uma categoria se relaciona com suas subcategorias. Esse
modelo ajuda a integrar a estrutura (o contexto condicional no qual um
fenmeno ocorre) com o processo (sequncias de aes/interaes
pertencentes ao fenmeno) Straus, et al., (1998). O modelo de paradigma
sugerido por Straus, et al., (1998) tem a seguinte estrutura: dado um
determinado fenmeno (categoria principal), a realizao de aes/interaes
59

resulta em determinadas consequncias; condies causais so as
categorias que exercem algum tipo de influncia no apenas no fenmeno,
mas tambm nas aes/interaes dos atores, enquanto que condies
intervenientes limitam o impacto causado pelas condies causais no
fenmeno. No entanto, o pesquisador pode definir os prprios conectores
entre os cdigos, utilizando-os para examinar as relaes entre as categorias
que formam as proposies da teoria substantiva Bandeira-de-melo, et al.,
(2006).
Por fim, a codificao seletiva refina todo o processo, identificando a
categoria central da teoria, com a qual todas as outras esto relacionadas. A
categoria central (core category) deve ser capaz de integrar todas as outras e
expressar essncia do processo social que ocorre entre os envolvidos. Esta
categoria central pode ser uma j existente, ou uma nova Bandeira-de-melo,
et al., (2006).
Esse refino tambm deve envolver o preenchimento de categorias
pouco desenvolvidas, alm da remoo de categorias em excesso. A teoria
final pode, ento, ser representada na forma de um conjunto de proposies
ou uma narrao da discusso terica Straus, et al., (1998). A Figura 5 ilustra
o processo citado acima.

60


Figura 5 Processo da Grounded Theory (Goulding, 2002 citado por (Schots, 2010))
4.3 A Aplicao da Grounded Theory

Nesta pesquisa qualitativa, foram executadas as duas fases do
processo de codificao proposto pela Grounded Theory, para que fosse
possvel encontrar o conjunto de teorias que respondessem a questo do
estudo: qual a dificuldade para a adeso do desenvolvimento para
reutilizao por parte das empresas que desenvolvem software no estado do
Cear?
Para a pesquisa, foi elaborado um questionrio (Apndice A) contendo
oito questes, que foi aplicado a quatro empresas situadas no estado do
Cear, que j foram avaliadas satisfatoriamente nos nveis E e C do MPS.BR.
Para identificar os entrevistados, utilizaremos os seguintes cdigos abaixo
identificados na Tabela 11.


61



Tabela 11 Perfil dos Entrevistados
Nvel da Empresa Cdigo Papel
E Entrevistado 01 Gerente
C Entrevistado 02 Scio e Gerente
E Entrevistado 03 Supervisor
E Entrevistado 04 Gerente e Analista

Quanto ao perfil das empresas temos:
a. Entrevistado 01 est alocado em uma empresa com 18 anos de
mercado e que tem como um de seus principais focos o
desenvolvimento de produtos, servios e solues de tecnologia da
informao. Embora possua uma fbrica interna e tenha outros tipos
de servios, alm do desenvolvimento, possui a maioria de seus
colaboradores alocados em clientes externos.
b. Entrevistado 02 est alocado em uma empresa com 20 anos de
mercado e que possui o foco em um produto especfico.
c. Entrevistado 03 est alocado em uma empresa com 22 anos de
mercado e que possui foco em um produto especfico, alm de uma
fbrica de software e desenvolvimento outsourcing.
d. Entrevistado 04 est alocado em uma empresa com 8 anos de
mercado que possui solues prprias alm de uma fbrica de
software.

Sobre as questes do questionrio, tratavam a respeito da
implantao de um processo de Desenvolvimento para Reutilizao e foi
utilizado o processo proposto nesta dissertao para auxili-las a
compreender o que estava envolvido em tal abordagem.
Para facilitar o entendimento dos entrevistados a respeito do processo
proposto, foi apresentado aos mesmos o processo, dividido em suas fases,
atividades e subatividade.
62

A partir das entrevistas realizadas, as respostas obtidas pelos
entrevistados foram transcritas para documentos que colecionavam as
citaes de cada entrevistado. No utilizou-se categorias-sementes
(seedcategories um conjunto inicial de cdigos para comear a
codificao), e foram sendo criados cdigos in vivo, a partir do texto dos
questionrios. Com o desenvolvimento da fase de codificao alguns cdigos
tiveram seus textos alterados para que pudessem facilitar a leitura e para que
colecionassem mais citaes.
Foram feitas, inicialmente, as codificaes aberta e axial, para as
citaes das quatro entrevistas realizadas. Essas foram revisadas, discutidas
e reestruturadas. Principalmente a codificao axial, que sofreu maiores
alteraes, aumentando o nmero de conexes e cdigos.
Os cdigos encontrados nessas entrevistas foram agrupados de
acordo com as suas propriedades, formando assim conceitos que
representam categorias. Estas foram analisadas e subcategorias foram
identificadas, com o objetivo de proporcionar uma maior clareza sobre o
fenmeno em questo. Finalmente, as categorias e subcategorias foram
relacionadas entre si, na etapa de codificao axial. A Figura 6 mostra parte
dos cdigos associados s citaes em um dos questionrios analisados.


Figura 6 Associao de cdigos s citaes das entrevistas

Na codificao axial, foi utilizada uma sugesto de conectores, com
base na linha proposta por Straus, et al., (1998), apresentada na Tabela 12,
63

onde para a mesma, a fim de facilitar a interpretao dos cdigos criados,
foram acrescentados alguns novos conectores.

Tabela 12 Conectores de cdigos adaptados de (Bandeira-de-melo, et al., 2006)
Smbolo Rtulo Descrio das Relaes
== associado com Relata conceitos correlatos
[] parte de A parte de uma relao, diferente de um conceito
=> causa de Usado para representar links causais
CsqNeg Consq. Neg. Relata que se aplicar uma atividade ir acarretar o
seguinte efeito colateral negativo
FAC um facilitador Relata que se aplicar uma atividade ir acarretar o
seguinte efeito colateral positivo
<> contradiz Quando duas atividades afirmam coisas distintas
DNEG um dificultador Declarao negativa sobre entrevistados
EVD evidncia Registra que h evidncia do fato ocorrido
isa um Liga conceitos especficos a conceitos gerais
PF um ponto forte Quando uma afirmao um qualificador positivo
PN um ponto fraco Quando uma afirmao um qualificador negativo
*} propriedade de Uma meta relao entre um conceito e seus atributos

Durante a codificao, foram encontradas muitas citaes que
relatavam os resultados de uma empresa com a presena e com ausncia de
um mesmo fator. Dessa forma, para no criar dois cdigos que denotassem a
presena e ausncia dos mesmos nas realidades das empresas, foi decidido
agregar essas citaes em apenas um fator, que ficaria com o nome
referente presena do mesmo, mas agregaria as citaes que relatassem
tambm a sua ausncia.
Para o processo de codificao axial, o relacionamento e a
proximidade temtica de alguns fatores permitiram a emerso e a criao de
duas categorias e de subcategorias em algumas dessas.
Tomando como base a pesquisa qualitativa como um todo, os cdigos
e categorias identificados passaram por sucessivas revises, sendo
produzido 174 cdigos, 2 categorias e 16 subcategorias.
64

Os cdigos, nas figuras, sero apresentados seguidos de dois
nmeros que representam, respectivamente, o grau de fundamentao
(groundedness) e o grau de densidade terica (density) do cdigo. O de
fundamentao mostra o nmero de citaes com as quais o cdigo est
associado. O grau de densidade terica mostra o nmero de relacionamentos
do cdigo com outros cdigos.
Para facilitar a compreenso, a visualizao e a documentao da
pesquisa foi feita a seguinte distino:
a. [Categoria Principal] xxxx Representa a categoria principal.
b. [Cat-num] xxx Representa a categoria.
c. [SS-Cnum] xxx Representa a subcategoria da categoria citada.
d. [SS-xx-Cnum] xxx Representa uma subcategoria mais abaixo.
e. Cnum. Xxx Representa um cdigo.
4.4 Anlise dos Resultados da Pesquisa Qualitativa

Na seo anterior descrevemos o processo de como obtivemos os
cdigos, as categorias e seus relacionamentos, at a criao das teorias.
Para analisarmos os resultados obtidos, com essa pesquisa qualitativa, sero
analisadas as categorias (Realidade do reso no CE e Processo Proposto)
com suas subcategorias e cdigos associados, tambm comentando os
relacionamentos (conexes) entre essas codificaes. Por fim, sero
analisadas as conexes entre cdigos de categorias diferentes. Os cdigos a
serem detalhados sero somente aqueles que tiveram um maior grau de
relevncia.
A categoria principal possui 2 cdigos relacionados, conforme Figura
7.
65


Figura 7 [Categoria Principal] Desenvolvimento para Reutilizao

O processo, portanto, foi dividido nas seguintes categorias, conforme
visto na Figura 7, [Cat-1] Realidade do reso no CE e [Cat-2] Processo
Proposto.
4.4.1 Realidade do reso no CE

Para a categoria [Cat-1] Realidade do reso no CE, a Figura 8,
apresenta como est a realidade do reso de software no estado do Cear,
segundo a tica das empresas entrevistadas. A categoria possui 4
subcategorias que so relacionadas diretamente a ela.


Figura 8 [Cat-1] Realidade do reso no CE
66

As subcategorias apresentadas na Figura 8 so: [SS-C1] Equipe para
Reso, [SS-C1] Ferramentas, [SS-C1] Desenvolvimento com Reso e
[SS-C1] Institucionalizao e execuo de processos de Software.
A subcategoria [SS-C1] Equipe para Reso, conforme pode ser vista
na Figura 9, visa tratar como a realidade das equipes que gerenciam a
reutilizao de software nas organizaes. Essa subcategoria, por sua vez,
possui 10 cdigos relacionados, dentre eles 4 ligados diretamente a ela.

Figura 9 [SS-C1] Equipe para Reso

Para os cdigos vistos na Figura 9, iremos analisar os seguintes
cdigos Possuir uma equipe s para reso, Aumento de custo e Lder de
reso conhecer o domnio da empresa.
Para o cdigo Possuir uma equipe s para reso esse cdigo foi
extrado da pergunta realizada no questionrio Quais as principais
dificuldades relacionadas com a estrutura organizacional?, Esta pergunta
est num contexto onde a literatura afirma que o ideal seria ter uma equipe
exclusiva para reso, pois assim os membros dessa equipe no iriam se
envolver com outra parte do processo e pensariam somente em reso. O
entrevistado 01 comentou no vejo a possibilidade de se ter uma outra
equipe para tratar exclusivamente da parte de reutilizao por que isso no
67

funciona. O entrevistado 03 citou eu acho que ter uma equipe s para
reso, s se a empresa for muito grande.
Para o cdigo Aumento de custo o entrevistado 01 comentou que
essas pessoas que fazem parte da equipe de reso, em algum momento,
sero julgadas como um peso financeiro pela empresa. O entrevistado 04
disse que a dificuldade se montar essa equipe sem trazer tantos custos
para a empresa, pois a gente no tem um retorno imediato.
O cdigo Lder de reso conhecer o domnio da empresa est
relacionado com o fato de que se a organizao decidir implantar essa
equipe, para diminuir a curva de aprendizado o ideal seria colocar como o
lder dessa equipe, algum que seja capacitado tecnicamente para o cargo e
que tambm possua uma certa experincia no domnio em que os
componentes sero desenvolvidos.
A subcategoria [SS-C1] Desenvolvimento com Reso, conforme
pode ser vista na Figura 10, visa conhecer o nvel de reso existente nas
organizaes entrevistadas. Essa subcategoria por sua vez, possui 11
cdigos relacionados, aonde dentre eles 6 relacionam-se diretamente a ela.


Figura 10 [SS-C1] Desenvolvimento com Reso

68

Na Figura 10 iremos analisar os cdigos No sistematizao do reso
de software, Desenvolver um produto para si e Ter algum tipo de reso
mesmo que informal.
Para o cdigo No sistematizao do reso de software o
entrevistado 01 comentou na prtica temos um projeto novo e tem um
arquiteto, ele sabe que um outro projeto utilizou algo do tipo, ento ele vai
conversar com o outro arquiteto ou um gerente,ento tem essa coisa informal
do dia-a-dia. O entrevistado 03 citou que eu tenho uma biblioteca de reso
porque eu sei que a gente tem um indicezinho aqui em uma planilha Excel e,
por exemplo, um ativo qualquer que eu queira est em um determinado local
no servidor, pronto vai l e pega. Complementando o comentrio, o
entrevistado afirmou que a pesquisa feita de forma mais precisa por quem
desenvolveu o ativo em questo, ou seja, no h algo que defina o tipo de
ativo que foi implementado, tornando assim uma busca ad-hoc.
Referente ao cdigo Desenvolver um produto para si foi visto que as
bibliotecas de ativos reutilizveis so mais eficazes nas organizaes que
trabalham com um nico produto do que em uma fbrica de software, que
possui N produtos distintos. Nesse contexto, foi observado que h uma
barreira para compra de ativos reutilizveis em organizaes que
desenvolvem o seu prprio produto, podendo-se justificar pelo comentrio do
entrevistado 01: no desenvolvimento de software, existe uma tendncia
muito grande em desenvolver os ativos que sero utilizados, creio que v
existir uma barreira de compra. Entretanto a compra de ativos no barrada
caso seja algo muito especfico, conforme citado pelo entrevistado 04 a
compra de ativo justificvel caso seja uma tecnologia, framework ou algo
muito especifico que no d tempo de ser implementado.
Referente ao cdigo Ter algum tipo de reso mesmo que informal o
entrevistado 02 comentou que a realidade que as pessoas precisam
reutilizar, ningum vai estar inventando tanta coisa o tempo todo. O
entrevistado 04 citou: o reso que a gente tem totalmente informal, apenas
armazenamos os ativos e quando precisamos de algo pesquisamos no
repositrio por pastas.
A subcategoria [Sub-C1] Institucionalizao e execuo de processos
de Software, conforme pode ser vista na Figura 11, relata a dificuldade em
69

que as empresas de software tm em seguir um processo definido. Essa
subcategoria possui um total de 8 cdigos onde 5 deles esto relacionados
diretamente com a subcategoria em questo.

Figura 11[Sub-C1] Institucionalizao e execuo de processos de Software
Para a Figura 11, temos os seguintes cdigos Ter sido avaliada
satisfatoriamente em um modelo de maturidade de software e Empresas
no executam plenamente os processos de software definidos.
O cdigo Ter sido avaliada satisfatoriamente em um modelo de
maturidade de software afirma que o fato de uma organizao j ter sido
avaliada em algum modelo de maturidade de software mostra de alguma
forma que a empresa capaz de trabalhar de forma sistemtica, entretanto
isso no a exime das complicaes referentes ao processo de reutilizao de
software, conforme comentrio do entrevistado 02: para ns que somos
avaliados nvel C do MPS.BR e utilizamos esse processo de forma integral,
julgamos ser complicado trabalhar de uma forma sistemtica, imagine voc
chegando numa empresa que no tem processo nenhum.
Referente ao cdigo Empresas no executam plenamente os
processos de software definidos o entrevistado 04 comentou: a gente faz
um reso aqui mais ligth, onde no existe toda aquela necessidade de um
70

acompanhamento do processo definido. O entrevistado 03 citou: a empresa
s quer saber de rodar.
A subcategoria [SS-C1] Ferramentas conforme pode ser vista na
Figura 12, evidencia a necessidade de um bom apoio ferramental para que o
processo de reso possa fluir de forma mais satisfatria para a organizao.
Essa subcategoria possui 5 cdigos relacionados, dentre eles 4 esto ligados
diretamente a ela.

Figura 12 [SS-C1] Ferramentas

De acordo com a Figura 12, temos os seguintes cdigos Necessidade
de adequar as ferramentas de GC e Falta de ferramenta que auxilie na
busca de ativos.
O cdigo Necessidade de adequar as ferramentas de GC est
relacionado ao fato de que em cada organizao h uma forma distinta de se
trabalhar, onde a forma de se trabalhar com uma determinada ferramenta,
talvez no seja satisfatria para outra organizao. A questo identificar a
sua forma de trabalho e adequar essa ferramenta para que o seu processo
seja otimizado, usando a ferramenta em seu favor. Alm disso, ainda h a
dificuldade de adequar a ferramenta de GC para as necessidades inerentes
ao processo de Desenvolvimento para Reutilizao. Podemos confirmar isso
pelo comentrio do entrevistado 03: utilizamos o Teamfoundation, porm
fizemos as nossas adequaes ao mesmo.
Para o cdigo Falta de ferramenta que auxiliem na busca de ativos, o
entrevistado 02 comentou se eu tenho um ativo para busca de CPF, mas
para encontrar esse ativo vou ter de ir buscando na mo, ativo por ativo,
71

tenho certeza que o desenvolvedor ou qualquer analista vai desistir e vai
refazer essa funcionalidade.
Finalizada a anlise da categoria [Cat-1] Realidade do reso no CE
iremos analisar a categoria [Cat-2] Processo Proposto onde no final iremos
fazer uma sntese dos resultados encontrados.
4.4.2 Processo Proposto

A categoria que possui mais conexes a categoria de Processo
Proposto. Essa possui um total de 17 relaes que esto ligadas categoria
em questo, se somarmos com as ligaes de suas 5 subcategorias mais as
outras conexes teremos um total de 53 relaes com essa categoria em
questo. A Figura 13 mostra os 17 cdigos que esto ligados diretamente,
sem intermdio de subcategorias ou de cdigos intermedirios. A referida
categoria utiliza as conexes Evidncia, um dificultador, um
facilitador, parte de ou causa de.


Figura 13 [Cat-2] Processo Proposto
72

Dos cdigos vistos na Figura 13, iremos analisar os cdigos
Incompatibilidade com a realidade das empresas cearenses, Investimento
com retorno a longo prazo, Baixa adeso ao nvel C do MPS.BR,
Atividades possveis de serem implementadas, Fase de Planejamento,
Fase de Implantao, Fase de Execuo e Dependncia de uma
consultoria.
Em relao ao cdigo Incompatibilidade com a realidade das
empresas cearenses o entrevistado 02 comentou: Eu acho que o reso
uma ideia longe para muita gente. O entrevistado 04 disse: uma distncia
muito grande, pois estamos falando num contexto de pequenas e micro
empresas, se referindo pergunta do questionrio que cita a distncia do
processo apresentado para a realidade das empresas desenvolvedoras de
software situadas no estado do Cear. Porm, isso tambm pode ser devido
ao fato de o processo que foi proposto ser falho.
Para esse cdigo o fato importante a ser citado que o MPS.BR tem
como um de seus principais focos trazer uma maturidade e qualidade no
desenvolvimento de software para micro, pequenas e mdias empresas e
segundo o relato dos profissionais entrevistados, todos foram unnimes em
atestar que o processo de Desenvolvimento Para Reutilizao, segundo os
padres exigidos pelo MPS.BR, est muito longe da realidade de empresas
de micro e pequeno porte, referindo-se as demais empresas situadas no
estado do Cear.
Os cdigos Atividades possveis de serem implementadas e
Dependncia de uma consultoria se complementam, no sentido de que,
embora sejam atividades complexas, com um apoio aplicado de uma
consultoria, essas atividades so possveis de serem implementadas. Isso
podemos confirmar atravs do seguinte comentrio do entrevistado 02:
Particularmente no julgo que no tenhamos capacidade de adotar uma
atividade dessa, uma vez que o processo j esteja todo desenhado e a gente
sabendo exatamente o que que precisa ser feito eu no vejo que tenhamos
maiores dificuldades.
Outros cdigos que foram citados so os que esto relacionados com
as fases do processo proposto. O cdigo Fase de Planejamento teve como
um de seus comentrios: conhecer bem a empresa para depois implantar,
73

essa citao relacionada ao cdigo Necessidade de avaliao da
viabilidade de se implantar o desenvolvimento para reutilizao, onde no
processo proposto a empresa em conjunto com a Instituio Implementadora
verificam se a organizao possui um domnio com potencial de reso e se
tem capacidade para implantar e executar o desenvolvimento para
reutilizao.
O cdigo Fase de Implantao tem como principal dificultador o
cdigo Inexistncia de colaborador, da prpria organizao, que seja
capacitado para ministrar os treinamentos. Tal afirmativa pode ser verificada
por meio do comentrio do entrevistado 03: A equipe que hoje eu tenho, no
qualificada para isso, no teria um recurso capaz de tocar esse processo.
se referindo a pergunta Para as atividades do processo apresentado, qual
voc julga no ter capacidade de adotar?.
O cdigo Fase de Execuo tem como principal dificultador o cdigo
Aumento da burocratizao do processo de reso, onde podemos confirmar
por meio do comentrio do entrevistado 01 um processo muito formal,
onde tenho de ter uma aprovao de uma outra pessoa, uma avaliao
financeira, isso que eu julgo ser mais complexo pois burocratiza um pouco
mais.
O cdigo Baixa adeso ao nvel C do MPS.BR tem um ponto
importante a ser comentado, visto que a baixa adeso ao nvel C no tem
como causa as dificuldades de implantar e executar o processo de
Desenvolvimento para Reutilizao, visto que este processo no precisa ser
avaliado na primeira avaliao nvel C, caso a empresa justifique que no
tenha ainda a capacidade de instituicionaliz-lo.
A categoria [Cat-2] Processo Proposto, conforme dito anteriormente
possui 5 subcategorias, que so elas: [SS-C2] Fbrica de Software, [SS-
C2] Alta Direo, [SS-C2] RH, [SS-C2] Financeiro e [SS-C2]
Infraestrutura.
A subcateria [SS-C2] Fbrica de Software trata das consideraes de
o processo de Desenvolvimento para Reutilizao ser aplicado a uma fbrica
de software. A Figura 14 mostra essa subcategoria com os seus 11 cdigos
relacionados, onde 5 deles so ligados diretamente e os demais utilizando-se
cdigos intermedirios.
74



Figura 14[SS-C2] Fbrica de Software
Para a Figura 14 iremos analisar os cdigos: Manuteno do modelo
de domnio, Necessidade de implantar o processo sem afetar a produo e
Existncia da cultura de trabalhar com processos.
O cdigo Manuteno do modelo de domnio est relacionado com a
subcategoria [SS-C2] Fbrica de Software como um dificultador. Podemos
confirmar essa relao por meio do comentrio: A gente na fbrica de
software, temos diversos clientes, diversas tecnologias, diversas
necessidades diferentes. Com isso, no contexto de uma fbrica, com muitos
clientes e projetos com caractersticas muito diferentes, fica muito mais
complexo de se criar um modelo de domnio, diferente da realidade de uma
empresa que desenvolve produtos. O seguinte cdigo fala das dificuldades
das fbricas de software com a questo do desenvolvimento para
reutilizao: Possibilidade de nunca mais fechar um contrato com domnio
similar j modelado. Ou seja, pode ser que a fbrica realize um alto
investimento para modelar um domnio que julgue ser importante e nunca
mais tenha outro cliente ou projeto com um domnio similar, para consumir os
ativos criados.
75

O cdigo Necessidade de implantar o processo sem afetar a
produo considerado um dificultador, onde podemos confirmar por meio
do comentrio do entrevistado 02: no tem como parar a fbrica para
implantar esse processo e depois voltar a produzir. Nesse caso necessrio
que a definio e implantao do processo sejam realizadas em paralelo,
porque tem que se considerar, tambm, a curva de aprendizado que ir
afetar a produo. Isto pode ser evidenciado pelo seguinte cdigo: Elevado
tempo para o aprendizado do processo.
O cdigo Existncia da cultura de trabalhar com processos
considerado um ponto positivo por relatar que j faz parte da cultura de uma
fbrica de software trabalhar com vrios processos. Caso seja implantado um
processo em paralelo, como por exemplo, o de desenvolvimento para
reutilizao, haveria uma facilidade para as fbricas.
A subcategoria [SS-C2] Infraestrutura aborda a importncia de um
bom apoio ferramental e dependendo da realidade da organizao, da
necessidade de uma reestruturao para a perfeita absoro do processo. A
Figura 15 mostra essa subcategoria com os seus 6 cdigos relacionados,
onde somente 1 est relacionado diretamente.

Figura 15 [SS-C2] Infraestrutura

76

De acordo com a Figura 15, iremos analisar os cdigos Dependncia
do apoio ferramental para implantao de um processo de reso, Falta de
conhecimento por parte da equipe das ferramentas que deveriam apoiar o
processo e Existncia de cdigos duplicados.
O cdigo Dependncia do apoio ferramental para implantao de um
processo de reso pode ser confirmado pelo comentrio do entrevistado 01:
qualquer empresa que queira implantar o processo de reso teria que ter
uma adaptao em relao a isso e no vejo como implementaramos um
reso sem uma ferramenta para dar suporte. O entrevistado 03 disse: O
processo de reso, para ser bem implementado, necessrio que haja um
controle de fluxo, repositrio de ativos reutilizveis, gerao de demandas de
ativos e ferramenta de busca de ativos reutilizveis. Complementando o
comentrio, foi observado que na realidade nas empresas cearenses, que
foram entrevistadas, nenhuma delas possuiam uma ferramenta que
possibilitasse a busca de ativos reutilizveis de forma fcil e sistemtica.
Somente em uma delas havia uma ferramenta que gerenciava a demanda
por ativos reutilizveis.
O cdigo Falta de conhecimento por parte da equipe das ferramentas
que deveriam apoiar o processo, mostra que o processo de reso ainda no
uma realidade muito disseminada, como vemos no comentrio do
entrevistado 02: As ferramentas que ns temos hoje so essas, dai elas do
apoio ao processo? Elas do suporte em parte ou integralmente?. Como
tambm citado pelo entrevistado 04: Existe alguma ferramenta para auxiliar
isso ou no?, se referindo pergunta: Como feita a pesquisa dos ativos
reutilizveis na organizao?. Como evidncia da no sistematizao da
pesquisa dos ativos reutilizveis temos o cdigo Existncia de cdigos
duplicados, que foi relatado por trs dos entrevistados como um dos maiores
dificultadores de manter consistente a biblioteca de ativos.
A subcategoria [SS-C2] Financeiro trata das questes financeiras
relacionadas instituio do processo de desenvolvimento para reutilizao.
A Figura 16 mostra a subcategoria com os seus sete cdigos, que so
ligados diretamente a ela e tambm se relacionam entre si.

77


Figura 16 [SS-C2] Financeiro

De acordo com a Figura 16 iremos analisar os cdigos: Apresentao
de um estudo de viabilidade do investimento no processo alta direo e
Possibilidade de um ativo nunca ser reutilizado.
O cdigo Apresentao de um estudo de viabilidade do investimento
no processo alta direo considerado um facilitador, pois esse estudo
tem como foco mostrar que apesar do retorno do investimento ser em
mdio/longo prazo, uma vez o processo implantado a organizao ir
melhorar a produtividade e qualidade de desenvolvimento.
O cdigo Possibilidade de um ativo nunca ser reutilizado
considerado um dificultador e pode ser justificado pelo comentrio do
entrevistado 01 No ponto de vista financeiro, acho que para a compra de
ativos a serem reutilizados, vai existir uma barreira grande porque at que se
tenha uma certeza a respeito do retorno. Porque eu posso comprar o ativo,
colocar na biblioteca de ativos e o retorno no ser o esperado ou nunca nem
trazer retorno por no ser utilizado.
A subcategoria [SS-C2] RH est relacionada s questes de
Recursos Humanos. A Figura 17 mostra a subcategoria com os seus 6
cdigos, sendo 5 ligados diretamente a subcategoria em questo.
78



Figura 17 [SS-C2] RH

De acordo com a Figura 17, temos os cdigos Recurso humano com
bom desempenho tcnico e que valorize o processo, [SS-RH-C2] Cultura
Organizacional e [SS-RH-C2] Estrutura Organizacional.
O cdigo Recurso humano com bom desempenho tcnico e que
valorize o processo tido como um grande facilitador para o processo.
Podemos confirmar pelo comentrio do entrevistado 02: no adianta o cara
ser muito tcnico mas gostar de fazer de qualquer jeito. Tem de ser tcnico e
disciplinado.
A subcategoria [SS-RH-C2] Cultura Organizacional est bastante
relacionada subcategoria [SS-C2] RH e trata diretamente sobre questes
culturais que podem facilitar ou dificultar a implantao do processo de
Desenvolvimento para Reutilizao. A Figura 18 mostra a subcategoria e os
seus 4 cdigos, onde 3 deles so ligados diretamente e um indiretamente.

79


Figura 18 [SS-RH-C2] Cultura Organizacional

De acordo com a Figura 18, temos os cdigos Falta de
desenvolvimento da cultura organizacional para trabalhar com reso e
Priorizao do reso.
O cdigo Falta de desenvolvimento da cultura organizacional para
trabalhar com reso ressalta a falta de cultura de reso, considerando os
valores e hbitos, das empresas de software do estado de Cear. Esta falta
de valor do reso e de pensar a longo prazo est evidenciada na seguinte
afirmao do entrevistado 03: Existe uma necessidade muito grande da
equipe j querer colocar a mo na massa, produzir, desenvolver de qualquer
forma.
Para o cdigo Priorizao do reso, pode-se ver que ele
dependente de um trabalho motivacional com os desenvolvedores, que so
os consumidores dos ativos reutilizveis. O seguinte comentrio do
entrevistado 03 fala da importncia de conscientizar a equipe sobre a
importncia da reutilizao de software temos de trabalhar bem o fator
comportamental, para que a equipe esteja internalizando dentro deles que
antes de sair para desenvolver algo, verificar se pode ser reutilizado, no s
cdigo, mas um componente j pronto, qualquer artefato.
80

A subcategoria [SS-RH-C2] Estrutura Organizacional, que tambm
est ligada subcategoria [SS-C2] RH trata mais o fato de como compor a
equipe que ir ficar responsvel pelo processo de reso na organizao. A
Figura 19 mostra subcategoria e os seus quatro cdigos que so todos
ligados diretamente a mesma. As conexes envolvidas so do tipo um
dificultador e um facilitador.

Figura 19 Estrutura Organizacional

De acordo com a Figura 19, temos os cdigos: Possibilidade de
pessoas ficarem ociosas e Composio da equipe de reso a partir de
membros de diferentes projetos.
O cdigo Possibilidade de pessoas ficarem ociosas pode ser
justificado como um dificultador, de acordo com o comentrio do entrevistado
01: ficar com pessoas ociosas um grande problema, isso no ponto de vista
de qualquer processo da empresa. Outro comentrio do entrevistado 03 que
tambm refora esse termo Ningum fica inventando coisa nova o tempo
todo se referindo ao fato de que a equipe no iria ter demanda suficiente
para alocar todos os que fizessem parte da Equipe de reso.
O cdigo Composio da equipe de reso a partir de membros de
diferentes projetos considerado um facilitador dessa atividade e pode ser
justificado pelo comentrio do entrevistado 01 quando a gente comeou a
81

fazer o processo de reso aqui, a gente pde pinar pessoas de vrios
projetos, como desenvolvedores e analistas que pudessem fazer parte dessa
equipe.
Por fim, temos a subcategoria [SS-C2] Alta Direo, que est
relacionada com a viso estratgica da organizao, principalmente da Alta
Direo. A Figura 20 mostra a subcategoria e os seus 3 cdigos onde 1 se
relaciona diretamente a ela e os outros 2 indiretamente.

Figura 20 [SS-C2] Alta Direo

De acordo com a Figura 20, temos o cdigo: Pouca viso de longo
prazo. Esse cdigo pode ser justificado pelo comentrio do entrevistado 04
eu vou plantar para colher l na frente. Os entrevistados falavam que uma
grande dificuldade seria convencer a alta direo a realizar um investimento
sem uma data certa para que o retorno seja observado.
No (Apndice B) encontrada a lista de todos os cdigos gerados pela
Grounded Theory indicando o seu grau de fundamentao e seu grau de
densidade terica.
4.5 Teorias Encontradas

Vrias teorias podem ser criadas a partir dos cdigos, citaes e
relacionamentos encontrados. Abaixo listamos as teorias, para a realidade do
Desenvolvimento para Reutilizao nas empresas de desenvolvimento de
software do estado do Cear, bem como a realidade em que as empresas se
82

encontram no que diz respeito reutilizao de software, elaboradas a partir
da pesquisa:
A Instituio Implementadora deve compreender bem o domnio
da empresa.
H uma grande dependncia de uma Instituio
Implementadora para a implantao do processo de
Desenvolvimento para Reutilizao.
A necessidade de um apoio ferramental foi evidente, tanto na
realidade de um desenvolvimento com reutilizao (GRU),
quanto, na realidade de um desenvolvimento para reutilizao
(DRU).
No suficiente ter apenas uma ferramenta que apie o
processo, necessrio tambm que a mesma seja adaptada
para a realidade da organizao.
Embora sejam consideradas complexas, as atividades do
Desenvolvimento para Reutilizao so possveis de serem
implementadas.
A inexistncia de uma ferramenta de busca de ativos
reutilizveis, de forma sistemtica, considerada um fator para
a existncia de cdigos duplicados na organizao.
O produto gerado pelo estudo de viabilidade de implantao do
processo proposto na organizao pode ser um grande aliado
para o convencimento da Alta Direo.
A Alta Direo deve estar ciente de que os benefcios
financeiros para a organizao viro em mdio/longo prazo.
importante o desenvolvimento de uma cultura organizacional
de priorizao do reso, no aplicado somente a produtos de
software.
necessrio qualificar a equipe que ir trabalhar com o
processo de reutilizao.
As fbricas de software tm mais dificuldades de aderir o
processo, pois possui vrios clientes, com domnios distintos.
83

difcil que uma fbrica de software mantenha o modelo de
domnio, dado o fato possuir vrios clientes.
importante implantar o processo sem afetar a produo da
fbrica de software.
Empresas que desenvolvem produtos de software, ou seja, no
so fbricas, podem obter grandes benefcios caso o processo
seja adotado.
necessria uma viso estratgica por parte da Alta Direo, a
fim de realizar um investimento sem pretenso de obter o
retorno em um curto prazo.
Para a realidade das empresas cearenses, difcil a
implantao de uma equipe s para reso.
As empresas cearenses podem montar a equipe de reso
atribuindo novas atividades para alguns membros de outras
equipes, porm torna-se um dificultador para as organizaes
que possuem um quadro reduzido.
A Inexistncia de um colaborador da organizao que seja
capacitado para ministrar os treinamentos a respeito do
processo de reso um dificultador.
H uma forte barreira, por parte da equipe de desenvolvimento,
no que diz respeito compra de ativos do mercado, que na
literatura conhecida como a sindrome do no foi feito aqui.
sempre necessria a validao dos ativos, produzidos ou
comprados, para que os mesmos no sejam desenvolvidos ou
adquiridos e nunca utilizados.
A dificuldade do processo de desenvolvimento para reutilizao
pode ser uma dificuldade para que as empresas no continuem
no nvel C do MPS.BR. Fato esse que justificado pelo fato de
que a empresa pode ser avaliada na primeira vez no nvel C
somente justificando a no adoo do processo, porm na
segunda avaliao o mesmo obrigatrio.
84

4.6 Concluso do Captulo

Neste captulo foi apresentada a Pesquisa Qualitativa, utilizando
procedimentos da Grounded Theory, para obteno de informaes sobre a
realidade do Desenvolvimento para Reutilizao no estado do Cear. Os
dados foram obtidos em entrevistas estruturadas que foram aplicadas a
algumas empresas avaliadas nos nveis E e C do MPS.BR.
A pesquisa capturou dados sobre as dificuldades do Desenvolvimento
para Reutilizao, utilizando como base o Processo Proposto. Com isso,
foram pontuadas teorias sobre quais so os principais fatores para a no
adoo do Processo por parte dessas empresas, possveis melhorias e
prticas que, caso adotadas, facilitam a implantao do referido processo.
No prximo captulo, ser apresentada a concluso do trabalho bem
como as consideraes finais.





Captulo5
Concluso


Neste captulo so apresentadas as concluses finais do trabalho,
focando nas contribuies, limitaes e trabalhos futuros.
5.1 Consideraes Finais

A primeira afirmativa que deve ser feita nesta seo que das
empresas de desenvolvimento de software no Cear que foram
entrevistadas, nenhuma delas possui um processo de reutilizao de
software sistemtico, nem mesmo a empresa que avaliada nvel C do
MPS.BR. dado nfase a essa afirmativa exatamente pela dificuldade,
vivenciada nesse trabalho, em encontrar algum trabalho que comentasse
sobre esse assunto principalmente de uma forma direta e objetiva.Schots, et
al., (2013)
Esse trabalho apresentou resultados de uma reviso da literatura, uma
pesquisa qualitativa, referente s dificuldades que as empresas de software
encontram em aderir um processo de desenvolvimento para reutilizao, ou
mesmo, em aderir a um reso sistemtico.
Conforme observado nos resultados das pesquisas, se pode observar
que as dificuldades se confirmam e essas podem ser distribuidas em
dificuldades causadas por:
Fatores tcnicos, que envolvem tanto as dificuldades de
entendimento dos termos adotados pelo MPS.BR, como
inexistncia de uma equipe capacitada para adeso do
processo.
Fatores socioculturais, que dependem das pessoas envolvidas
no processo, no que diz respeito a ter uma viso voltada ao
reso.
86

Fatores de recursos financeiros, sendo um dos mais
importantes, devido ao investimento no processo ser alto e o
retorno do mesmo ser em mdio/longo prazo.
Fatores de comprometimento, que evidencia a no adeso ao
processo por parte da equipe, principalmente dos gestores, que
no liberam membros de sua equipe para implantao do
processo.

Tendo esses resultados, o processo desenvolvido, bem como os
resultados da anlise qualitativa, podem servir como um apoio s empresas
que queiram implantar o processo de desenvolvimento para reutilizao,
assim como s Instituies Implementadoras do MPS.BR, pois essas
podero dar uma ateno maior aos fatores.
5.2 Principais Contribuies

Umas das contribuies desse trabalho poder ser utilizado por
empresas de software e Instituies Implementadoras do MPS.BR, para guiar
suas aes relacionadas implantao do processo de Desenvolvimento
para Reutilizao (DRU).
Alm disso, podemos destacar que:
Foi realizada uma reviso bibliogrfica no tema de
desenvolvimento para reutilizao, considerando os principais
conceitos envolvidos, bem como, a maneira do MPS.BR lidar
com o assunto.
Foi definida uma abordagem de Desenvolvimento para
Reutilizao (DRU) aderente ao MPS.BR.
Foram construdas algumas teorias relacionadas com a
implantao do DRU em empresas de desenvolvimento de
software no Cear, utilizando-se de procedimentos da
Grounded Theory.
87

5.3 Limitaes

Uma das limitaes deste trabalho foi a existncia de poucos trabalhos
que comentem sobre o Desenvolvimento para Reutilizao (DRU), havendo
bastante literatura que trata a respeito do nvel inicial do reso, que o
Gerenciamento com Reso (GRU), conforme podemos verificar em Schots,
et al., (2013),Silva Filho, et al., (2008) e Lucrdio, et al., (2008).
Esse trabalho no abordou relatos de empresas que utilizam o
desenvolvimento para reutilizao de forma sistemtica.
Outra limitao da pesquisa foi a pouca quantidade de empresas
cearenses avaliadas nos nveis E, D e C do MPS.BR.
5.4 Trabalhos Futuros

Durante o desenvolvimento dessa dissertao, algumas possibilidades
de trabalhos futuros foram identificadas:
Expandir a pesquisa para empresas em todo o Brasil, podendo
assim identificar a realidade do reso de software nas diversas
regies do pas.
Definir um tipo de abordagem, bem como, melhores prticas,
prprias para o desenvolvimento para reutilizao em fbricas
de software, mesmo que haja clientes com domnios distintos.
Definir um Guia de Adaptao da abordagem proposta,
considerando as caractersticas das empresas, dos seus
projetos e dos domnios.






88

Bibliografia
(Adolph, et al., 2008)

Adolph, S., Hall, W. and Kruchten, P. 2008. A methodological leg to stand on:
Lessons learned using grounded theory to study software development. IBM
Toronto Software Lab., 2008.
(Almeida, 2011)
Almeida, Carlos Diego Andrade. 2011. Continuidade da Execuo dos
Processos de Software em Empresas Avaliadas no MPS.BR. 2011.
(Almeida, et al., 2010)
Almeida, Eduardo Santana, Alvaro, Alexandre and Garcia, Vinicius
Cardoso. 2010.CRUISE - Component Reuse in Software Engineering. 1- Edio.
Recife : Livraria Cultura, 2010.
(Almeida, et al., 2010)
Almeida, Eduardo Santana, et al. 2010.Component Reuse in Software
Engineering - CRUISE. Recife : s.n., 2010.
(Braga, 1999)
Braga, R., Werner, C.,. 1999. X Conferncia Internacional em Tecnologia de
Software (X CITS). Odyssey-DE: Um Processo para Desenvolvimento de
Componentes Reutilizveis. Maio 1999.
(Bandeira-de-melo, et
al., 2006)
Bandeira-de-melo, R and Cunha, C. 2006. Grounded Theory. Pesquisa
Qualitativa em Estudos Organizacionais: Paradigmas, Estratgias e Mtodos.
So Paulo : Saraiva, 2006, p. Chapter 8.
(Basili, et al., 1991)
Basili, V. R and Rombach, H. D. 1991.Support for Comprehensive Reuse.
Software Engineering Journal, Special issue on software process and its support.
Abril 05, 1991, pp. 306-316.
(Bayer, et al., 1999)
Bayer, J., et al. 1999. PuLSE: A Methodology to Develop Software Product
Lines. 1999, pp. 122-131.
(Becker, et al., 2003)
Becker, J., Kugeler, M. and Rosemann, M. 2003. Process Managenent. A
Guide for Design of Business Process. Berlin : Springer, 2003.
(Becker, 2003)
Becker, M. 2003. Towards a general model of variability in product families.
Proceedings of the 1st Workshop on Software Variability Management. Fevereiro
2003, pp. 19-27.
(Biggerstaff, et al.,
1989)
Biggerstaff, T. J. and Perlis, A. J. 1989.Frontier Series: Software Reusability:
Volume I - Concepts and Models. New York : ACM, 1989.
(Bosh, 2004)
Bosh, J. 2004. Software Variability Management. Proceedings of 26th
International Conference on Software Engineering. 2004, pp. 720-721.
(Chrissis, et al., 2006)
Chrissis, M. B., Konrad, M. and Shrum, S. 2006.CMMI: Guidelines for
Process Integration and Product Improvement. s.l. : Addision Wesley
Professional, 2006.
(Conte, 2001)
Conte, Tayana Ucha. 2001. Traduo de Diagramas de Estado UML para um
Modelo de Verificao Formal. 2001.
(Creswell, 1997)
Creswell, J. W. 1997.Qualitative inquiry and research design - choosing among
five traditions. s.l. : Thousand Oaks: Sage Publications, 1997.
(Czarnecki, 1997)
Czarnecki, K. 1997. Leveraging Reuse Through Domain-Specific Software
Architectures. Columbus : s.n., 1997.
(Ezran, et al., 2002)
Ezran, M., Morisio, M. and Tully, C. 2002.Practical Software Reuse. Springer :
s.n., 2002.
(Ford, 2012)
Ford. 2012. http://www.ford.com.br/sobre-a-ford/historia. www.ford.com.br.
[Online] Ford, 2012. [Cited: Novembro 10, 2013.] http://www.ford.com.br/sobre-
a-ford/historia.
(Frakes, et al., 1994)
Frakes, W. B. and Isoda, S. 1994. Sucess Factors of Systematic Software Reuse.
IEEE Software, vol.12. Setembro 01, 1994, pp. 15-19.
(Glaser, 1992)
Glaser, B. 1992.Basics of grounded theory analysis. CA : The Sociology, 1992.
(Glaser, et al., 1967)
Glaser, B and Strauss, A. 1967.The discovery of grounded theory: Strategies for
Qualitative Research. New York : Aldine Transaction, 1967.

(Griss, 1998)
Griss, M., Favaro, J., D'Alessandro, M., 1998. 1998. 5- International
Conference on Software Reuse. Integrating Feature Modeling with RSEB. 1998.
89

(Guerra, et al., 1999)
Guerra, P. M. and Santos, S. R. 1999.Reutilizao de Componentes de Software
com Base em Identificadores Hierrquicos. Universidade Tcnica de Lisboa, s.l. :
1999.
(Hammer, 2003)
Hammer, M. 2003. Reengineering the Corporation: A Manifesto for Business
Revolution. New York : HarperBusiness, 2003.
(ISO/IEC, 1995)
ISO/IEC, 12207. 1995.Information Technology - Software Life Cycle Processes.
s.l. : The International Electrotechnical for the Standardization and the
International Electrotechinical Commission, 1995.
(Jacobson, 1997)
Jacobison, I. Griss, Martin, Jonsson, Patrik. 1997.Software Reuse: architecture,
process and organization for business success. NEW YORK : ACM PRESS, 1997.
(Jacobson, 1992)
Jacobson, I. 1992.Object-oriented software engineering: a use case driven
approach. Boston : Addison-Wesley Publishing Company, 1992.
(Kang, et al., 1990)
Kang, K.C., Cohen, S.G. and Hess, J. A. 1990.Feature-Oriented Domain Analysis
(FODA) - Feasibility Study. s.l. : Software Engineering Institute (SEI), 1990.
(Krueger, 1992)
Krueger, Charles W. 1992.Software Reuse. New York : ACM, 1992.
(Lucrdio, et al.,
2008)
Lucrdio, D., et al. 2008. Software reuse: The Brazilian industry scenario. Journal
of Systems and Software. v.81, 2008, Vol. 6.
(Mclroy, 1968)
Mclroy, M. D. 1968. Mass produced software components. In Software
Engineering; Report on a conference by the NATO Science Committee (Garmisch,
Germany, Oct.). Naur, P., and Randell, B., Eds. NATO Scientific Affairs Division,
Brussels, Belgium, pp. 138-150. ACM Computing Surveys, Vol. 24, No.2
(Montoni, et al., 2010)
Montoni, M and Rocha, A.R. 2010.Aplicao de Grounded Theory para
Investigar Iniciativas de Implementao de Melhorias em Processos de Software.
2010.
(Montoni, 2010)
Montoni, M. 2010. Uma Investigao sobre os Fatores Crticos de Sucesso em
Iniciativas de Melhoria de Processo de Software. 2010.
(Nato, 1968)
Nato. Nauer, P. and Randeli, B. 1968. Brussels : Report on a Conference by the
NATO Science Committee. NATO Scientific Affairs Division, 1968.
(Neighbors, 1980)
Neighbors, J. M. 1980. Software Construction Using Components. 1980, p. 75.
(Niazi, et al., 2003)
Niazi, M, Wilson, D and Zowghi, D. 2003. A Model for the Implementation of
Software Process Improvement: A Pilot Study. 2003.
(Novellino, 1996)
Novellino, Marial Salet Ferreira. 1996. Tools and Methodologies for Information
Representation. 1996.
(Oslem, 1998)
Oslem, M. R. 1998. An Incremental approach to software system rengineering.
Journal of Software Maintenance. May/June 1998, pp. 181-202.
(Papazoglou, 2003)
Papazoglou, M. P. 2003. Service-Oriented Computing: Concepts, Characteristcs
and Directions. Rome : International Conference on Web Information, 2003.
(Pietro-Diaz, et al.,
1987)
Pietro-Diaz, R and Freeman, P. 1987. Classifying Software for Reusability. 1987,
pp. 6-16.
(Prado, 1992)
Prado, A. F. 1992.Estratgia de Engenharia de Software Orientada a Domnios.
Tese de Doutorado. Pontifica Universidade Catlica, p.333, s.l. : 1992.
(Rocha, et al., 2005)
Rocha, A.R, Montoni, M and Santos, G. 2005. Fatores de Sucesso e Dificuldades
na Implementao de Processos de Software Utilizando o MR-MPS e o CMMI.
2005.
(Sametinger, 1997)
Sametinger, J. 1997.Software Engineering with Reusable Components. Verlag :
s.n., 1997.
(Schots, et al., 2013)
Schots, Marcelo and Werner, Cludia. 2013. Caracterizando a implementao
de Processos de Reutilizao do MR-MPS-SW: Resultados Preliminares. Wamps.
2013.
(Schots, 2010)
Schots, Natlia Chaves Lessa. 2010. Uma Abordagem para a Identificao de
Causas de Problemas Utilizando Grounded Theory. 2010.
90

(Silva Filho, et al.,
2008)
Silva Filho, R. C. and Katsurayama, A. E., Santos, G., Murta, L., Rocha, A. R.
2008. Experincia na Implantao do Processo de Gerncia de Reutilizao no
Laboratrio de Engenharia de Software da COPPE/UFRJ. ProQuality. 4, 2008.
(Simos, 1998)
Simos, M., Anthony, J.,. 1998. 5- International Conference on Software Reuse
(ICSR - 5). Weaving the Model Web: A Multi-Modeling Approach to Concepts and
Features in Domain Engineering. Junho 1998, pp. 94-102.
(Sobrinho, 2013)
Sobrinho, Romeu. 2013.O que SOA (Arquitetura Orientada a Servios). 2013.
(Softex, 2007)
Softex. 2007. MPS.BR: Melhoria do Processo do Software Brasileiro. Guia Geral
v.1.2. [Online] 2007. [Cited: Junho 13, 2013.] http://www.softex.br/mpsbr.
(STARS, 1993)
STARS. 1993.Software Technology for Adaptable, Reliable Systems (STARS), The
Reuse-Oriented Software Evolution (ROSE) Process Model. 1993.
(Straus, et al., 1998)
Straus, A. and Corbin, J. 1998.Basics of Qualitative Research: Techniques and
Procedures for Developing Grounded Theory. London : SAGE Publications, 1998.
(Strauss, 1987)
Strauss, A. 1987.Qualitative analysis for social scientist. New York : Cambridge
University, 1987.
(Takara, et al., 2007)
Takara, A, Bettin, A and Toledo, C.M. 2007. Problems and Pitfalls in a CMMI
level 3 to level 4 Migration Process. 2007.
(Troy, 1994)
Troy, R. 1994. Software Reuse: Making the concept work. Engineering Software.
1994, pp. 16-20.
(Weill, et al., 2006)
Weill, Peter and Ross, Jeanne. 2006.Governana de TI: Tecnologia da
Informao. So Paulo : M. Books, 2006.
(Werner, et al., 2012)
Werner, Cludia Maria Lima and Teixeira, Eldnea Nogueira. 2012.Processo de
Desenvolvimento para Reutilizao (DRU) - Workshop Anual MPS.Br. Rio de
Janeiro : s.n., 2012.
(Wiegers, 1999)
Wiegers, K. 1999. Software Process Improvement: Ten Traps to Avoid. 1999, pp.
51-58.



Apndice A Questionrio da Entrevista


Este apndice contm o guia para as entrevistas realizadas para a
pesquisa qualitativa.

Questionrio que tem como foco validar um processo de
implantao do desenvolvimento para reutilizao nas empresas do
estado do Cear, tomando como pblico alvo, empresas que j foram
validadas no MPS.BR. nveis E e C.

1. Dificuldades para implementar o processo?
2. Quais as principais dificuldades relacionadas com recursos
humanos?
3. Quais as principais dificuldades relacionadas com a rea
financeira?
4. Quais as principais dificuldades relacionadas com a
infraestrutura?
5. Quais as principais dificuldades relacionadas com a estrutura
organizacional?
6. Para as atividades do processo apresentado, quais voc julga
no ter capacidade de adotar e por qu?
7. Qual a distncia entre o processo apresentado e a verdadeira
realidade em que as microempresas de TI esto inseridas?
8. Se for fbrica de software, qual a dificuldade desse processo?



Apndice B Cdigos encontrados na Grounded Theory


Este apndice contm a Tabela 13 que lista todos os cdigos
encontrados e utilizados na Grounded Theory do Captulo 4, com a sua
quantidade de referncias (Groundedness) e sua quantidade de relaes
(Density).

Tabela13 Cdigos extrados da GT
Cdigo Groundedness Density
[Categoria Principal] Desenvolvimento para Reutilizao 0 2
[Cat-1] Realidade do reso no CE 0 5
[Cat-2] Processo Proposto 0 14
[SS-C1] Desenvolver um produto para si 3 3
[SS-C1] Desenvolvimento com Reso 0 7
[SS-C1] Equipe para Reso 0 5
[SS-C1] Ferramentas 0 4
[SS-FS-C1] Biblioteca de ativos reutilizveis 0 3
[Sub-C1] Institucionalizao e execuo de processos
de Software
0 6
[SS-C2] Alta Direo 0 2
[SS-AG-C2] Viso Estratgica 0 3
[SS-C2] Desenvolvimento para reutilizao 0 7
[SS-C2] Fbrica de Software 0 7
[SS-C2] Financeiro 0 4
[SS-C2] Infra 0 3
[SS-C2] RH 0 7
[SS-INF-C2] Ferramentas 0 6
[SS-RH-C2] Cultura Organizacional 0 6
[SS-RH-C2] Estrutura Organizacional 0 5
C001. H dificuldades para implantar o processo DRU 1 0
C002. Ficar com pessoas ociosas 1 1
93

C003. Aproveitar membros de outras equipes para
montar a equipe de reso
1 0
C004. Ter uma equipe s para reso 1 1
C005. Aumento de custo 2 2
C006. Retorno no imediato. 2 1
C007. O retorno do investimento no reso diferente
de em um outro projeto
1 0
C008. No h dificuldades tcnicas da pessoa, para o
reso, pois somos da tecnologia e o reso faz parte
1 0
C009. Compartilhar recursos com outros projetos 4 4
C010. Alocar uma equipe nica para o reso um peso
financeiro.
1 0
C011. Comprar ativos no mercado 2 3
C012. Desenvolver seus prprios componentes e no
comprar do mercado.
2 2
C013. Aquisio de componentes muito especficos 1 1
C014. Ativo comprado e nunca utilizado 1 0
C015. No h poucas dificuldades ou quase nenhuma,
relacionada a infra-estrutura
1 0
C016. Variedade de ferramentas que apoiam o
processo
1 1
C017. No tivemos problema de mquina e nem de
servidor.
1 0
C018. Utilizamos a ferramenta do Team Foundation
com algumas adaptaes.
1 0
C019. controle de verso. 1 0
C020. Fundamental para implantao de um processo
de reso
4 1
C021. A rea de desenvolvimento se adapta mais
rpido ao reso
1 1
C022. rea administrativa possui bloqueio cultural
quanto ao reso
1 1
C023. A parte comercial e administrativa sempre 1 0
94

tiveram uma grande dificuldade cultural em se adaptar a
novos processos
C024. equipe com dedicao exclusiva. 1 0
C025. IVIA nvel E do MPS.BR 1 0
C026. utilizar plenamente o MPS.BR nvel E 1 0
C027. Fator impeditrio da adeso ao nvel C do
MPS.BR
2 1
C028. Deixamos todo o processo do nvel C pronto mas
no rodamos.
1 0
C029. Processo muito burocrtico 4 2
C030. O acrescimo de trabalho para sistematizar o
reso
1 0
C031. No vejo nenhum problema na fase de
Planejamento com o apoio da consultoria.
2 0
C032. Treinamento. 3 2
C033. Dependncia de uma consultoria 3 2
C034. Alto investimento na cultura organizacional 2 1
C035. Submeter a anlise de uma outra pessoa se o
ativo solicitado vlido ou no.
1 1
C036. Burocratiza muito o processo de reso. 2 1
C037. Ter algum tipo de reso, mesmo que informal 3 1
C038. Uma empresa de TI que no utiliza reso est
muito para trs.
2 1
C039. As empresas possuem um controle de verso,
mas no h um processo mais cuidadoso e sistemtico.
1 0
C040. preciso reutilizar, ningum vai ficar inventando
tanta coisa o tempo todo
1 0
C041. No necessrio reinventar a roda 1 0
C042. Na prtica o reso feito de forma que um
arquiteto sabe que outro projeto utilizou algo parecido
ento ele vai atrs de quem o fez.
1 0
C043. No h uma ferramenta de busca de ativos
reutilizveis
1 0
95

C044. Se o reso que tenho hoje est servindo para
que gastar mais?
1 0
C045. Processo muito sistemtico para a realidade do
CE.
4 3
C046. Mais complexo se for fbrica de software 1 0
C047. Desenvolver um produto para si 1 0
C048. Possuir vrios clientes e vrias tecnologias 4 3
C049. Um ativo NUNCA ser reutilizado 2 2
C050.Clientes com diferentes necessidades especficas 1 1
C051. Manter vrios ativos que no so utilizados 3 2
C052. Dependendo da empresa esse processo de
reso sistemtico se torna algo muito pesado
2 0
C053. Houve dificuldades tanto que adotamos ao nvel
C do MPS.BR justificando a no adoo do processo
2 0
C054. Definir o que um ativo reutilizvel. 1 0
C055. A gente no tinha noo de quanto tempo seria
necessrio para implementar esse processo
1 0
C056. A abstrao dos termos utilizados no MPS.BR 1 2
C057. Exemplos prticos 1 1
C058. Ter uma equipe enxuta. 1 1
C059. Recurso com bom desempenho tcnico e ligado
a processo
1 2
C060. No executar as atividades definidas 2 3
C061. (Fin) Se for provado que o processo ir trazer
benefcios para a organizao ele no ter problema
em ser financiado
1 0
C062. Sou gerente do setor e tambm sou acionista da
empresa
1 0
C063. Eu no tenho a menor condio de estimar o
custo da implantao do processo
1 0
C064. Quanto tempo demora para implantar esse
processo?
1 0
C065. Falta de conhecimento por parte da equipe das 2 1
96

ferramentas que apoiam ao processo
C066. Falta de conhecimento sobre o processo de
reso de software
1 0
C067. Team fundation, ferramenta utilizada para
controle do repositrio
1 0
C068. O que precisamos para implantar o processo? 1 0
C069. Fica difcil listar uma dificuldade de uma coisa
que no conhecemos.
1 0
C070. Recurso capacitado para realizar os
treinamentos
4 3
C071. As ferramentas que possuo hoje, do suporte ao
processo?
1 0
C072. Todas as pessoas que esto nesse processo
elas executam mais de uma funo
1 0
C073. Lder de reso conhecer o domnio da empresa 1 1
C074. Dividir o tempo dos colaboradores com suas
atividades normais e as do processo de reso
1 1
C075. uma vez o processo todo desenhado, creio que
no tenhamos dificuldades em adotar tais atividades.
1 1
C076. A parte que julgo ser mais complexa seria a de
identificar ativos reutilizveis. (RCN)
1 0
C077. Acredito que um processo sistemtico de reso
est anos-luz da realidade das empresas cearenses.
1 0
C078. Utilizamos o MPS.BR nvel C integralmente. 1 0
C079. Seguir um processo de maturidade de software
no uma regra geral
1 0
C080. Fora da realidade das empresas no CE 1 0
C081. Empresa no possuir processos de software
definidos formalmente
4 1
C082. No executar as atividades definidas 2 0
C083. Fluxo de recebe, testa e entrega, no tem um
cuidado a respeito do produto que est sendo entregue.
1 0
C084. Ter sido avaliada satisfatoriamente em um 4 1
97

modelo de maturidade de software
C085. Acompanhar o dinmismo do processo de
desenvolvimento
1 2
C086. Manter o repositrio Consistente 1 2
C087. Manter atualizado o modelo de domnio 2 6
C088. Implantar um processo sem afetar a produo 3 2
C089. Parar o processo e depois voltar a produzir. 1 1
C090. (RH) dificuldade cultural em relao as
competncias da equipe.
1 0
C091. Entender o que reso, no contexto de software 3 1
C092. Desenvolver trabalho motivacional na equipe 1 1
C093. Qualquer artefato pode ser reutilizado 2 1
C094. Verificar a possibilidade de reso antes de
desenvolver algo
3 1
C095. Trabalhar a parte cultural da equipe para pensar
no reso antes de tudo
1 0
C096. Vender a ideia na organizao 1 1
C097. (FIN) como justificar o alto investimento? 1 0
C098. O reso ganha em produtividade e reduz o custo 1 2
C099. Desenvolver um estudo que justifique o alto
investimento no processo
4 3
C100. Investir em consultoria, infraestrutura e
treinamento
2 1
C101. Na VTI a infraestrutura no foi o nosso ponto
crtico
1 0
C102. Ferramentas para repositrio, gerar demandas
de ativo, proposta de reso e fazer rastreabilidade
4 1
C103. (Fer) ferramenta para controle de repsitrio 1 0
C104. (Fer) ferramenta para registrar a demanda de um
ativo
1 0
C105. (Fer) ferramenta para gerar proposta de
reutilizao
1 0
C106. (Fer) ferramenta para fazer a rastreabilidade do 1 0
98

ativo reutilizado.
C107. MANTIS para gerar a demanda de reutilizao 1 0
C108. SVN para controlar o repositrio 1 0
C109. A equipe que for montada para o processo de
reso ter sua dedicao varivel
1 0
C110. A organizao dever separar uma equipe que
esteja determinada a realizar o processo de reso.
1 0
C111. A organizao tem de saber que ter de
desalocar e realocar recursos e isso impacta o
investimento
1 0
C112. Papeis da equipe e processos que sero
impactados bem definidos
1 1
C113. A atividade de validar a complexidade de uma
modificao a que julgo ser a mais difcil
1 0
C114. Atividades possveis de serem implementadas 2 2
C115. a distncia do processo para a realidade das
micro e pequenas empresas muito grande
1 0
C116. Empresas que trabalham com CMS 1 0
C117. Utilizar o BPMS sem uma sistemtica de reso 1 1
C118. Utilizar muitos processos 2 2
C119. Cultura, recursos financeiros e mudana nos
processos e estrutura organizacional
1 0
C120. Forte ligao com a Gerncia de Configurao 2 1
C121. A Alta Direo precisa ter uma viso bem
frente, no pensar em querer o resultado agora.
1 0
C122. viso de longo prazo 3 2
C123. No ir colher o resultado do investimento rpido 1 0
C124. Haver uma dificuldade cultural por parte dos
envolvidos na equipe
1 0
C125. Bloqueio Cultural 4 2
C126. Falta de uma equipe especializada para realizar
o treinamento no processo de reso
1 0
C127. A equipe dever ter uma viso voltada para o 1 0
99

reso antes de desenvolver qualquer coisa.
C128. Entender o paradgima de o que o reso prega 1 0
C129. A rea financeira est bem ligada ao RH 1 0
C130. A empresa dever reservar um bolso para
realizar o investimento sem esperar um retorno
imediato
1 0
C131. Estou tendo a tirada do dinheiro mas no vou ter
a coleta imediata
1 0
C132. A maior dificuldade para mim modelagem da
infraestrutura
1 0
C133. Se no houver uma sistemtica na busca de
ativos reutilizveis os mesmos sero duplicados
1 0
C134. Cdigos duplicados 3 1
C135. Ser uma empresa de pequeno porte 1 1
C136. No h uma equipe s para reso 1 0
C137. Seria invivel ter uma equipe s para reso aqui
na Enovar
1 0
C138. Equipe ter pouca visibilidade do processo 1 1
C139. Gerar diviso na organizao 1 1
C140. No s a equipe de reso que realiza o reso,
somos todos ns que reutilizamos
1 0
C141. A equipe que possuo hoje ela no qualificada
para o reso sistemtico
1 0
C142. As atividades da fase de anlise, fazer uma
anlise detalhada do processo muito trabalhoso.
1 0
C143. Adaptao da infraestrutura 2 1
C144. O reso que possuo muito informal 1 0
C145. Pesquisa de ativos reutilizveis de forma adhoc 1 2
C146. Teramos uma grande dificuldade em construir
um modelo de domnio e um modelo de arquitetura
2 0
C147. Compreenso dos benefcios do reso 1 2
C148. Viso de futuro, estou fazendo aqui para colher
depois
1 0
100

C149. As pequenas empresas precisam de um fluxo de
caixa rpido
1 0
C150. Difcil ter um processo de reutilizao nas
microempresas
1 1
C151. As microempresas em So Paulo, j querem ter
o processo mais estruturado possvel
1 0
C152. Empresas no executam plenamente os
processos de software definidos.
4 4
C153. microempresas no fazem nenhum
planejamento.
1 1
C154. Curva de aprendizado 3 1
C155. Clientes com domnios diferentes 1 1
C156. NUNCA mais encontrar outro domnio similar 1 1
C157. Clientes com domnios similares 1 1
C158. Eu vejo o processo de reso como uma ideia
muito longe para muita gente
1 0
C159. Vivel de ser implementado 2 2
C160. Investimento com retorno a longo prazo 4 1
C161. verifica viabilidade de implantao 3 1
C162. Processo fora da realidade das empresas
cearenses
4 1
C163. O reso apoiado por softwares de G.C. 3 3
C164. Necessidade de adequar ferramenta de G.C. 2 1
C165. Gerao de demanda de reso apoiada por
ferramentas
2 1
C166. Controle do repositrio de ativos reutilizveis 3 1
C167. Falta de ferramenta que auxiliem na busca de
ativos
2 1
C168. Possuir uma equipe s para reso 3 8
C169. Equipe de reso possuir dedicao exclusiva 3 1
C170. No sistematizao do reso de software 3 1
C171. Fase de Execuo 2 3
C172. Fbrica de Software 0 0
101

C173. Fase de implantao 3 3
C174. Fase de planejamento 2 2