ads:
Pontifícia Universidade Católica do Rio Grande do Sul
Faculdade de Informática
Programa de Pós-Graduação em Ciência da Computação
Estrutura e Características
para Análise de Ambientes
de Desenvolvimento Global
de Software em Organizações
Offshore Insourcing
Leonardo Santa Maria Pilatti
Dissertação apresentada como
requisito parcial à obtenção do
grau de mestre em Ciência da
computação
Orientador: Prof. Dr. Jorge Luis Nicolas Audy
Porto Alegre
2006
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
2
Dados Internacionais de Catalogação na Publicação (CIP)
P637e Pilatti, Leonardo Santa Maria
Estrutura e características para análise de ambientes de
desenvolvimento global de software em organizações
offshore insourcing / Leonardo Santa Maria Pilatti. – Porto
Alegre, 2006.
136 f. : il.
Dissertação (Mestrado) – Fac. de Informática, PUCRS, 2006.
Orientador: Prof. Dr. Jorge Luis Nicolas Audy.
1. Engenharia de Software. 2. Tecnologia da Informação.
3. Estruturas Offshore. I. Audy, Jorge Luis Nicolas. II. Título.
CDD 005.1
Ficha Catalográfica elaborada pelo
Setor de Processamento Técnico da BC-PUCRS
Pontifícia Universidade Católica do Rio
Grande do Sul
Campus Central
Av. Ipiranga, 6681 – prédio 16 – CEP 90619-900
Porto Alegre – RS – Brasil
Fone: +55 (51) 3320-3544 – Fax: +55 (51) 3320-3548
Email:
www.pucrs.br/biblioteca
ads:
3
4
5
“Dedico este trabalho a meu pai. Por tudo aquilo que representou e representa para
mim”...
6
7
Agradecimentos
Ao Prof. Jorge Audy, pela amizade, orientação e paciência. Você é sem dúvida
um grande professor que mostra como lidar com desafios ainda maiores que escrever
uma dissertação de mestrado.
Ao Prof. Marcelo Blois, pela paciência, compreensão e o acompanhamento
dedicado durante e estágio de docência.
Ao Prof. Michael Mora por ter acreditado, em 2002, que eu poderia fazer um
bom trabalho como aluno de mestrado e funcionário da Dell Inc.
Aos amigos e colegas Sabrina Marczak e Rafael Prikladnicki, pela contribuição
e acompanhamento dado a este trabalho, disponibilidade para discussões, revisões e
sugestões que foram sempre proveitosas.
Ao meu pai em especial (in memoriam) por todo esforço e pela dedicação que
teve, pelo incentivo e maneira de viver.
À minha mãe, tias (Gládis e Lourdes), vó Dalila pelo companheirismo, valores e
o conceito que tenho hoje de família.
Ao meu irmão, pela compreensão e apoio.
Às organizações participantes dos estudos de caso, por acreditar no valor do
trabalho.
Ao Centro de Desenvolvimento e Pesquisa Dell/PUCRS (CDPe), por ter
financiado, parcialmente, esta pesquisa e meu curso de mestrado.
A todos os entrevistados, pelo tempo dispensado e suas contribuições.
8
9
“Não há aprendizagem como a que dá a adversidade.”
Disraeli
“A primeira e a melhor das vitórias é a conquista de si mesmo.”
Platão
10
11
Resumo
Os desafios que a engenharia de software tem enfrentado em termos de distribuição
estão cada vez mais complexos. A crescente globalização do ambiente de negócios tem
afetado diretamente o mercado de desenvolvimento de software. Em busca de vantagens
competitivas, tais como baixos custos, ganho de produtividade e qualidade, as
organizações optam por distribuir o processo de desenvolvimento de software em outros
países com custo de produção mais baixo, como Índia, China e Brasil. Entretanto, os
desafios apresentados pela distribuição da equipe envolvida no processo de
desenvolvimento de software são significativos. Torna-se cada vez mais necessário
organizar e estruturar os processos utilizados de modo a identificar quando uma
organização está madura para trabalhar com abordagens de desenvolvimento distribuído
para suprir demanda interna (offshore insourcing). Nesse contexto, identificar as
características de ambientes offshore insourcing, bem como propor uma estrutura de
modelo de maturidade tornam-se atividades ainda mais desafiadoras. A composição da
estrutura de um modelo deve considerar fatores que devam abranger elementos
organizacionais e técnicos. Nesse sentido, esta dissertação de mestrado tem como
objetivo identificar e descrever uma estrutura de modelo de maturidade e um conjunto
de características associadas para a análise de ambientes de desenvolvimento global de
software offshore insourcing. O método de pesquisa utilizado foi o estudo de caso e a
base empírica da pesquisa envolve duas unidades de desenvolvimento de software de
empresas multinacionais de grande porte localizadas no Brasil e duas unidades de
desenvolvimento de software de empresas multinacionais de grande porte localizadas na
Ásia (China e Cingapura). A pesquisa contribui no sentido de propor uma estrutura de
modelo de maturidade, bem como identificar característica que caracterizem
organizações de desenvolvimento global de software em ambientes offshore insourcing.
Palavras-chave: Engenharia de Software, Processo de Desenvolvimento de Software,
Desenvolvimento Global de Software, Ambientes Offshore Outsourcing e Offshore
Insourcing.
12
13
Abstract
The challenges the software engineering are facing, because the global development,
have became more complex. Crescent globalization in business environments has
affected the software development market. Aiming competitive advantages as low costs,
high productivity and quality in systems development, several organizations decided to
distribute their internal development process outside their countries to reduce their cost,
countries like India, China and Brazil are some examples. However, team dispersion,
even in those environments, introduces several challenges to the process development.
It is even more necessary to organize process used by the organization's units to identify
when the units are mature enough to work with the global development software to
attend the internal demand (offshore insourcing). In this context, the environment
characteristics map is a must task in the process of understanding the needs of the
offshore insourcing as well to compound the structure for the maturity model. The
composition needs to consider social, techniques and organizational factors, showing
how they are connected. In this approach, this research has the objective to identify and
describe a structure for a maturity model in a global software development offshore
insourcing environment context. As well, creating the criteria used to differentiate the
organizational units. The research method used was the case study, conducted in four
offshore insourcing global software development units located in Brazil (2), China (1)
and Singapore (1). This research aims to contribute by proposing a maturity model
structure as well identifying characteristics of offshore insourcing global software
development environments.
Keywords: Software Engineering, Software Process Development, Global Software
Development, Offshore Outsourcing and Offshore Insourcing.
14
15
Lista de Figuras
Figura 1: Motivações para o DGS [LOP03]................................................................... 28
Figura 2: ITIL e a Governança de TI [SUC04] .............................................................. 34
Figura 3: Elementos do CObIT [ISA04b] ...................................................................... 35
Figura 4: O Cubo do Modelo CObIT [ISA04b] ............................................................. 36
Figura 5: Modelo de Custo Conceitual para DGS [SON03] .......................................... 38
Figura 6: Modelo de Referência MuNDDoS [PRI03].................................................... 39
Figura 7: Modelo para Organizações Terceirizadas [LOH02] ....................................... 43
Figura 8: FORT Framework [KIS03]............................................................................. 44
Figura 9: Modelo para Organizações Offshore Outsourcing [KHA03a] ....................... 46
Figura 10: Modelo de Offshore SITO [CAR02]............................................................. 47
Figura 11: Níveis do OMM [MOR03] ........................................................................... 49
Figura 12: Benefícios, Complexidade, Integração e Níveis do OMM [MOR03] .......... 50
Figura 13: Desenho de Pesquisa..................................................................................... 58
Figura 14: Etapas do Estudo de Caso............................................................................. 65
Figura 15: Dimensões e Categorias................................................................................ 87
Figura 16: Componentes da Estrutura ............................................................................ 97
Figura 17: Proposta de Estrutura do Modelo.................................................................. 98
Figura 18: Aspectos pertencentes aos Domínios............................................................ 99
Figura 19: Dimensões e Categorias.............................................................................. 100
Figura 20: Modelo Conceitual da Estrutura Proposta .................................................. 103
16
17
Lista de Tabelas
Tabela 1: Variáveis sociais de DGS [ROC03] ............................................................... 29
Tabela 2: Critérios de Análise para os Modelos DGS e Offshore.................................. 53
Tabela 3: Análise Comparativa dos Modelos................................................................. 54
Tabela 4: Legenda Representativa com o Nome dos Modelos DGS e Offshore............ 54
Tabela 5: Critérios de Análise para os Modelos de Maturidade para DGS.................... 55
Tabela 6: Análise Comparativa dos Modelos de Maturidade......................................... 55
Tabela 7: Unidades do Estudo de Caso .......................................................................... 62
Tabela 8: Tempo de trabalho na unidade ....................................................................... 68
Tabela 9: Análise da dimensão 1, nos centros A e B ..................................................... 68
Tabela 10: Número de pessoas envolvidas por organização.......................................... 69
Tabela 11: Vantagens e desvantagens de ambientes offshore insourcing segundo os
participantes............................................................................................................ 80
Tabela 12: Lições aprendidas dos centros estudados e teoria ........................................ 84
Tabela 13: Categorias dos aspectos técnicos.................................................................. 88
Tabela 14: Categorias dos aspectos sociais .................................................................... 89
Tabela 15: Categorias dos aspectos organizacionais...................................................... 91
Tabela 16: Elementos do modelo proposto e suas origens............................................. 95
18
19
Lista de Abreviaturas e Vocabulário
ACP
Áreas Chaves de Processos
APC
Asia Product Center
ASP
Active Server Provider
CASE
Computer Aided Software Engineering
CObIT
Control Objectives for Information and related Technology
CMM
Capability Maturity Model
CMMI
Capability Maturity Model Integrated
DM
Delivery Managers
DGS
Desenvolvimento Global de Software
EC
Elementos Comuns
FORT
Four Outsourcing Relationship Types
Framework
É a base de sustentação para o desenvolvimento de sistemas segundo um
determinado paradigma
GDC
Global Development Centers
GDSC
Global Development Service Centers
ICEIS
International Conference on Enterprise Information Systems
ISACA
Information Systems Audit and Control Association
ISO
International Standards Organization
IT
Information Technology
MuNDDOS
Maturidade No Desenvolvimento Distribuído de Software
MSF
Microsoft Solutions Framework
NM
Níveis de Maturidade
OMM
Offshore Maturity Model
PC
Práticas-Chaves
PMI
Project Management Institute
PMO
Program Management Officer
RUP
Rational Unified Process
SEI
Software Engineering Institute
SEPG
Software Engineering Process Group
SITO
Source of IT Work Offshore
SW-CMM
Capability Maturity Model for Software
TECNOPUC
-PUCRS
Centro Tecnológico da Pontifícia Universidade Católica do Rio Grande
do Sul
TI
Tecnologia de Informação
UML
Unified Modeling Language
XP
eXtreme Programming
20
21
Sumário
1. Introdução................................................................................................................... 23
1.1 Justificativa........................................................................................................... 24
1.2 Caracterização do Problema................................................................................. 25
1.3 Objetivos............................................................................................................... 26
2. Base Teórica ............................................................................................................... 27
2.1 Desenvolvimento Global de Software (DGS) ...................................................... 27
2.1.1 Forças Atuantes ............................................................................................. 28
2.1.2 Variáveis Sociais no Ambiente de DGS........................................................ 29
2.2 Desenvolvimento Offshore................................................................................... 30
2.2.1 Terceirização entre Diferentes Empresas (Outsourcing)............................... 30
2.2.2 Terceirização dentro da Própria Empresa (Insourcing)................................. 31
2.3 Modelos de Maturidade e de Governança de TI................................................... 31
2.3.1 SW-CMM...................................................................................................... 31
2.3.2 CMMI............................................................................................................ 32
2.3.3 SPICE ............................................................................................................ 33
2.3.4 ITIL................................................................................................................ 34
2.3.5 CObIT............................................................................................................ 35
2.4 Modelos de Referência......................................................................................... 37
2.4.1 Modelo de Custo para DGS (Segundo [SON03]) ......................................... 37
2.4.2 Modelo MuNDDoS (Segundo [PRI03])........................................................ 39
2.4.3 Modelo para Organizações Outsourcing (Segundo [LOH02])...................... 42
2.4.4 Modelo para Organizações Offshore Outsourcing (Segundo [KIS03]) ........ 43
2.4.5 Modelo para Organizações Offshore Outsourcing (Segundo [KHA03a]) .... 45
2.5 Trabalhos Relacionados........................................................................................ 47
2.5.1 Modelo SITO (Segundo [CAR02]) ............................................................... 47
2.5.2 Modelo OMM (Segundo [MOR03]) ............................................................. 48
2.6 Análise Comparativa ............................................................................................ 51
2.6.1 Modelos de Maturidade e de Governança de TI............................................ 51
2.6.2 Modelos de Referência.................................................................................. 52
2.6.3 Modelos de Maturidade Offshore.................................................................. 54
3. Método de Pesquisa.................................................................................................... 57
3.1 Desenho de Pesquisa ............................................................................................ 57
3.2 Estudo de Caso ..................................................................................................... 59
3.2.1 Unidade do Estudo de Caso........................................................................... 59
4. Resultados do Estudo de Caso.................................................................................... 61
4.1 Características das Organizações Analisadas....................................................... 61
4.1.1 Característica da Organização do Centro A e C............................................ 62
4.1.2 Característica da Organização do Centro B................................................... 63
4.1.3 Característica da Organização do Centro D .................................................. 64
4.2 Metodologia do Estudo de Caso........................................................................... 64
4.3 Instrumento de Pesquisa....................................................................................... 66
4.3.1 Caracterização dos Respondentes.................................................................. 67
4.4 Análise de Dados.................................................................................................. 68
4.4.1 Aspectos Organizacionais.............................................................................. 69
4.4.2 Aspectos Sociais............................................................................................ 71
4.4.3 Aspectos Técnicos......................................................................................... 75
4.4.4 Questões Gerais............................................................................................. 79
4.5 Considerações sobre o Estudo de Caso ................................................................ 83
22
5. Estrutura das Características de Ambientes Offshore Insourcing.............................. 87
5.1 Aspectos Técnicos................................................................................................ 88
5.2 Aspectos Sociais................................................................................................... 89
5.3 Aspectos Organizacionais..................................................................................... 90
6 Proposta de Estrutura do Modelo de Maturidade........................................................ 93
6.1 Processo de Escolha e Definição da Estrutura...................................................... 93
6.2 Descrição da Estrutura.......................................................................................... 96
7 Considerações Finais................................................................................................. 105
7.1 Contribuições...................................................................................................... 106
7.2 Limitações do Estudo ......................................................................................... 107
7.3 Trabalhos Futuros............................................................................................... 107
8 Referências Bibliográficas......................................................................................... 109
APÊNDICE A – Instrumento de Pesquisa para o Estudo de Caso............................... 115
APÊNDICE B – Conjunto Total de Características Identificadas no Estudo de Caso. 129
APÊNDICE C – Publicações........................................................................................ 133
23
1. Introdução
Os desafios que a engenharia de software tem enfrentado em termos de
distribuição estão cada vez mais complexos. Dentro desta disciplina, o desenvolvimento
global de software destaca-se como uma alternativa para atender uma demanda cada vez
maior em entregar produtos com alta qualidade e baixo custo [HER01]. Esta alternativa
apresenta uma série de classificações que representam como as unidades de
desenvolvimento estão organizadas em relação à matriz. O desenvolvimento offshore
insourcing é uma destas classificações, onde a empresa passa para um setor
especializado a tarefa de desenvolver e atender a demanda interna por softwares. Nesta
demanda, encontram-se diversos tipos de sistemas, desde o auxílio para criação de
tabelas em planilhas eletrônicas, até o controle sobre máquinas industriais.
A utilização deste tipo de desenvolvimento global, o offshore insourcing, auxilia
as empresas em busca de vantagens competitivas em termos de custos, aumento de
produtividade e qualidade na área de desenvolvimento de sistemas. As organizações
distribuem as operações de desenvolvimento de software em países onde existem
incentivos fiscais e políticos, reduzindo ainda mais o seu custo de construção [MCC96].
Mesmo fazendo parte da mesma empresa, os participantes no processo de
desenvolvimento estão distribuídos, e, todas as dificuldades enfrentadas por times
distribuídos também aparecem nesta estratégia de desenvolvimento global de software
([KHA03a] e [REP02]). Ao optar por criar um ambiente de desenvolvimento global,
além de todas as dificuldades inerentes ao processo de desenvolvimento co-localizado, a
organização começa a enfrentar diversos desafios de adaptação, diferenças culturais,
planejamento do trabalho, comunicação, entre outros. Nos ambientes offshore
insourcing, existem ainda outros fatores que foram mapeados por este trabalho.
Além disso, organizar os processos, as políticas e as estratégias são
fundamentais para o sucesso dos projetos de desenvolvimento que atuam em ambientes
offshore insourcing. Estudos mostram que problemas relativos a definições táticas e
estratégicas correspondem por 45% do sucesso de uma organização [LAC01] em
realizar seus projetos. Uma decisão tomada indevidamente pode exercer um impacto
negativo em vários projetos de software, afetando diretamente os custos e prazos
envolvidos.
24
Conforme proposto por [CAR02] é fundamental para a organização estruturar,
organizar e alinhar suas necessidades de negócio com suas políticas, processos e
metodologias, presentes no processo de desenvolvimento de software. Existir uma
estrutura que suporte estes processos torna-se fundamental quando as equipes estão
globalmente dispersas e em ambientes como o offshore insourcing, onde objetivos
locais da organização podem colidir com os objetivos globais definidos. Esta estrutura
irá refletir no produto gerado, afetando seu custo e qualidade [KHA03a].
1.1 Justificativa
Dentro da engenharia de software, observa-se a crescente adoção do
desenvolvimento global de software e uma de suas principais classificações, o offshore
insourcing. Percebe-se a crescente demanda no setor de tecnologia da informação nesta
área, ainda mais por organizações que estão criando centros de desenvolvimento
localizados em países subdesenvolvidos. Com processos estruturados, podem-se
comparar centros de desenvolvimento, e, identificar quais os que possuem uma
maturidade mais avançada para trabalharem nestes ambientes. Mesmo assim, a
quantidade de estudos existentes abordando a forma de estruturar os processos
utilizando em ambientes offshore insourcing ainda é muito pouca.
Em alguns estudos encontrados, existem modelos que sugerem avaliar uma
organização em níveis de maturidade, como por exemplo, o Capability Maturity Model
(CMM) [SEI95] que procura avaliar a maturidade da organização em seu processo de
desenvolvimento. Em outros, são definidos componentes conceituais que são
interconectados e compõe um modelo de referência que a organização deve seguir,
como por exemplo, o modelo Four Outsourcing Relationship Types (FORT) [KIS03].
A diferença entre os modelos de maturidade e os de referência tem influência
direta sobre a distribuição dos membros da equipe envolvida no processo de
desenvolvimento [LOH02]. Esta distribuição apresenta diversos desafios, comumente
relacionados com as metodologias de desenvolvimento da organização. Um aspecto
positivo da utilização destes modelos é a tendência da diminuição da burocracia e o
comprometimento cada vez mais elevado entre os membros da equipes. Esta tendência é
caracterizada também em [AUD01].
25
Visualiza-se uma direção de pesquisa neste sentido, a fim de identificar uma
estrutura e as características para e de organizações que atuam em ambientes offshore
insourcing. Processos estruturados e políticas estruturadas refletem diretamente na
qualidade do produto gerado [CAR02]. Contribuindo desta forma, com o avanço do
estudo na área de engenharia de software, mas especificamente, na área de
desenvolvimento global de software em ambientes offshore insourcing.
Com base nesta contextualização, o tema escolhido para dissertação de mestrado
é a identificar uma estrutura que componha dos processos, procedimentos e métodos
que podem servir de base para um modelo de maturidade para o desenvolvimento global
de software para organizações offshore insourcing. O desenvolvimento offshore, é
considerado um tema de grande relevância por diversos autores ([EVA04a], [MOR03],
[PRI03], [KHA03a], [LOH02], [CAR02] e [REP02]), fomentando uma grande área para
pesquisa e aplicação. O foco, portanto, esta no desenvolvimento global de software em
ambientes offshore insourcing.
1.2 Caracterização do Problema
Com diversas definições e características, percebe-se o espaço dentro da
engenharia de software para desenvolver pesquisas na área de desenvolvimento global
de software em ambientes offshore insourcing. Desta forma, esta pesquisa tem como
principal problema algumas questões importantes sobre a elaboração da estrutura de
modelo de maturidade e características de organizações offshore insourcing. Tais como,
• Quais são as características do desenvolvimento global de software
em ambientes offshore insourcing?
• Qual a estrutura de modelo que possa abranger estas características
em termos de processos e procedimentos, bem como a evolução
destas práticas e métodos?
É importante para organizações compreenderem e estruturarem seus processos a
fim de terem melhor qualidade de seus produtos. Além disso, garantir a qualidade do
produto torna-se um fator fundamental nos centros de desenvolvimento offshore. Para
que eles continuem existindo, é necessário ganhar maturidade ao longo do tempo. Logo,
é importante trabalhar com um modelo que estruture e organize processos e
26
procedimentos para organizações offshore insourcing. Ele deve possuir informações que
permitam a comparação e acompanhamento ao longo do tempo.
1.3 Objetivos
O objetivo geral desta pesquisa é identificar e descrever uma estrutura de
modelo de maturidade e um conjunto de características associadas para a análise
de ambientes de desenvolvimento global de software offshore insourcing. A fim de
atingir este objetivo, foram definidos os seguintes objetivos específicos:
1. Aprofundar o conhecimento teórico nas áreas de engenharia de software, mais
especificamente, no desenvolvimento global de software em ambientes offshore
insourcing.
2. Identificar as principais características do desenvolvimento global de software
em ambientes offshore insourcing;
3. Descrever uma estrutura de modelo de maturidade, associando-as com as
características estudadas, aplicados à engenharia de software e ao desenvolvimento
offshore insourcing;
27
2. Base Teórica
Neste capítulo são apresentados os principais conceitos envolvidos com o tema
da pesquisa. O referencial teórico foi abordado em detalhe durante o desenvolvimento
dos trabalhos individuais.
2.1 Desenvolvimento Global de Software (DGS)
Atividades de desenvolvimento global de software (DGS) têm crescido
consideravelmente nos últimos anos [SHA03]. Alianças entre empresas, terceirização,
fusões, aquisições e demandas de mercado são algumas das razões do por que as
companhias estão distribuindo suas operações entre regiões e paises. Além disso, a
tecnologia tem possibilitado a construção de equipes que não estão fisicamente no
mesmo lugar [OLS04].
Entretanto, o mercado global de software passou por diversas crises. Por um
lado, um grande número de falhas em projetos. De outro, uma demanda crescente,
atingida pela escassez de recursos capacitados. Nesse contexto, muitas organizações
perceberam o desenvolvimento global de software como uma alternativa,
experimentando-o em seus projetos de software.
Atualmente um grande número de organizações realiza esta prática, e o assunto
está cada vez mais presente em congressos e workshops internacionais, como o
International Workshop on Global Software Development e o International Workshop
on Process Support for Distributed Team-Based Software Development.
Do ponto de vista de alguns autores ([COA04], [BOR03], [PRI02], [CAR99],
[KAR98]), a utilização de técnicas de desenvolvimento global representa uma revolução
na maneira como se desenvolve software. Cada vez mais os gerentes de projetos
deverão considerar as variáveis locais e globais quando planejarem as atividades do
projeto. Fuso horário, diversidades culturais, comunicação, confiança, dentre outros,
deverão estar alinhadas de forma que o foco de trabalho não seja perdido, prejudicando
os resultados. Estes fatores afetam a maneira como a coordenação e a gerência do
projeto é conduzida, pois determinados problemas geram maior complexidade, afetando
outros, como por exemplo, o fuso horário acentua e aumenta os problemas de
comunicação, gerando uma sobrecarga na interação entre os grupos. Percebe-se que o
28
desenvolvimento global é permeado por diversas forças que atuam sobre a estratégia,
que incidem negativamente ou positivamente.
De forma a embasar este estudo, são apresentados logo a seguir, as forças
atuantes e as variáveis sociais envolvidas no DGS.
2.1.1 Forças Atuantes
Diversos autores ([COA04], [ROC03], [BIA02], [PRI02], [SPC01], [CAR99])
caracterizam as vantagens que existem em trabalhar com o DGS. Todos são enfáticos ao
destacar que só é possível tê-las quando o nível de gerência do projeto é alto e
devidamente controlado. Observa-se na verdade que existem fatores que são
potencialmente vantajosos e podem ser caracterizados diferenciais quando se utiliza o
DGS. A figura 1 denota como as forças motivadoras de DGS atuam entre si:
Figura 1: Motivações para o DGS [LOP03]
No entanto, conforme alguns autores ([CRE03], [RAD00], [CAR99], [SAB99]),
existem desafios que atuam contra a utilização do desenvolvimento global. Procura-se
listar as principais desvantagens do DGS logo abaixo, sem limitá-los ou esgotá-los.
a) Problemas Organizacionais: Englobam os problemas nas definições
estratégicas de processos e na gerência da qualidade.
Custos
Globalização
Escala
DGS
Time-to-Market
Experiência em
Desenvolvimento
Sinergia
Cultural
29
b) Problemas Técnicos: Abrangem problemas relativos à gerência de
requisitos, integração, de gerência de configuração, dificuldades no
acompanhamento do projeto e uso de ferramentas;
c) Problemas Sociais: Englobam os problemas culturais, a comunicação
inadequada, as diferenças culturais.
2.1.2 Variáveis Sociais no Ambiente de DGS
Desenvolver um sistema não é uma tarefa totalmente automatizada ([PRI02],
[HER99]). Ainda que existam interfaces e sistemas do tipo Computer Aided Software
Engineering (CASE) que auxiliem sua construção, este necessita do envolvimento de
seres humanos para que as tarefas possam ser executas. Devido a isto uma série de
variáveis sociais está presente nesta interação, e, algumas variáveis tornam-se
discrepantes quando uma análise mais detalhada é realizada. Em DGS, estas variáveis
ficam cada vez mais em evidência. A tabela 1 procura denotar como estes fatores atuam
no âmbito de DGS.
Tabela 1: Variáveis sociais de DGS [ROC03]
Variáveis Sociais Sub-Variáveis envolvidas
Costumes
Estilo de Comunicação
Formação de Grupo
Interpretação
Liderança
Perspectiva de Tempo
Reações e Estilos Individuais e
Grupais
Dispersões e Diferenças Culturais
Resolução de Problemas
Gerenciamento das pessoas
Fusos Horários
Dispersões Geográficas
Legislação
Interdependência
Gerenciamento de Configuração
Cooperação, Coordenação e
Controle
Consciência
Contexto
Comunicação
Meio
Coesão
Confiança
Trabalho de Equipe
Tamanho
30
2.2 Desenvolvimento Offshore
O desenvolvimento offshore de software, ou desenvolvimento fora da matriz da
empresa, é uma estratégia relativamente nova nas organizações [DEL03]. Ela consiste
em enviar serviços e/ou projetos para uma companhia localizada em um país diferente
de onde a matriz esta localizada.
Paises como a Rússia, a Índia, a China e o Brasil têm se destacado neste
contexto por apresentarem baixos custos de desenvolvimento de sistemas, quando
comparados a Estados Unidos e outros da Europa Ocidental, principais geradores deste
tipo de demanda ([GOP03], [KUR96]). Esta estratégia aumenta a capacidade de
desenvolvimento de sistemas, aumentando a capacidade da organização. Sua utilização
é motivada por fatores como a redução de custos, a flexibilidade de ampliar e reduzir a
equipe conforme demanda, e o acesso a profissionais com habilidades específicas.
O termo offshore – pode ser entendido como off: fora, shore: matriz, ou seja,
“fora-da-matriz” e pode ser caracterizado por todo o tipo de atividade que não é
realizada na matriz da organização. De acordo com [KHA03b], este tipo de estratégia
possui atividade onde o fornecedor do serviço esta localizado em um país diferente da
empresa contratante. Alguns autores consideram o offshore como sinônimo de offshore
outsourcing, ou seja, o offshore seria uma evolução da terceirização (outsourcing), para
outros [SUN02] não.
A fim de tornar homogênea a utilização de termos neste trabalho, a seguir são
contextualizadas algumas definições comumente relacionadas com o desenvolvimento
offshore.
2.2.1 Terceirização entre Diferentes Empresas (Outsourcing)
Segundo [KHA03b], a terceirização no setor da tecnologia da informação (TI) é
definida como uma contribuição significativa de fornecedores externos aos recursos
físicos e/ou humanos associados a um componente da infra-estrutura de TI da
organização. Em [KIS03], é definido o termo outsourcing como sendo a contratação de
uma empresa externa que presta e gerencia funções relativas aos ativos de informação,
também conhecidos como active server provider (ASP). Em termos gerais, entende-se
como uma prática de contratar uma organização externa para desenvolver um produto,
ao invés dele ser desenvolvido na própria sede. O objetivo principal em primeiro plano
é a redução de custos.
31
2.2.2 Terceirização dentro da Própria Empresa (Insourcing)
Conceito que surgiu em oposição ao outsourcing e possui dois significados. Por
um lado, ilustra a retenção de um serviço na própria empresa, realizado no setor de
demanda do serviço. Por outro lado, significa estabelecer uma unidade semi-
independente, que presta serviços aos outros departamentos ou unidades de negócio
dentro da própria empresa, onde os preços e as condições são acordados entre os
requisitantes e a unidade prestadora do serviço [GEF03].
O insourcing pode ser considerado como uma variante de terceirização, já que o
serviço pode ser requisitado a outra parte da empresa, e aspectos legais envolvendo
contratos e fornecedores podem ser expandidos. Ainda que o serviço esteja sendo
realizado dentro da empresa, as unidades de negócios prestadoras de serviço podem
estar em outro país, estas unidades de negócio especializadas, são conhecidas como
centros globais de desenvolvimento de produto ou prestação de serviço (Global
Development Service Centers - GDSC) [REP02].
2.3 Modelos de Maturidade e de Governança de TI
Ao estudar os modelos de maturidade, busca-se identificar a forma mais
adequada de estabelecer uma estrutura específica que compreenda a área de DGS. O
estudo abrange modelos de maturidade existentes na área de desenvolvimento de
software e na governança de TI, envolvendo o SW-CMM, o CMMI, o SPICE, o ITL e o
CObIT.
É importante ressaltar que o foco é a estrutura destes modelos, bem como os
elementos que o compõe. Identificando todos os componentes é possível compor um
modelo de maturidade específico, partindo dos elementos genéricos de suas estruturas.
2.3.1 SW-CMM
O CMM (Capability Maturity Model) é um produto para organizações que
desenvolvem software. Produzido pelo Software Engineer Institute (SEI), este modelo
visa fornecer subsídios para uma melhor engenharia e controle de qualidade de produtos
de software. Sua estrutura é composta de 6 (seis) componentes:
32
1. Níveis de Maturidade (NM): Cada nível indica a capacitação de um processo
de software. Ele é composto por 5 níveis de maturidade, sendo:
Nível 1: Inicial: Com processos “ad hoc” e procedimentos imprecisos.
Nível 2: Repetível: Cujo foco é a gerência de projetos.
Nível 3: Definido: O foco é a organização.
Nível 4: Gerenciado: O foco é a produtividade e a qualidade, dirigidos por
métricas dos processos.
Nível 5: Otimizado: O foco é a melhoria continua a nível organizacional.
2. Áreas-Chaves de Processos (ACP): Com exceção do nível 1, cada nível de
maturidade é decomposto em várias áreas chaves, cujo objetivo é organizar os processos
de acordo com sua área de atuação.
3. Práticas-Chaves (PC): cada ACP é descrita em termos de práticas chaves. Elas
descrevem atividades para a implementação e institucionalização das ACP. Cada vez
que a organização atingir níveis maiores de maturidade, mais práticas específicas
estarão sendo executadas. Ela descreve o que deve ser feito sem limitar o como.
4. Elementos Comuns (EC): Por conveniência, as práticas que descrevem as
ACP estão organizadas através de elementos comuns. Eles são atributos que indicam se
a implementação e institucionalização de uma ACP é efetiva, repetível e durável.
5. Objetivos: São definidos dentro de cada ACP.
Os níveis de maturidade são delimitados pelas ACP. Cada área-chave possui
elementos comuns que atendem a PC. As PC atendem a objetivos.
2.3.2 CMMI
O Capability Maturity Model Integrated (CMMI) é uma evolução do modelo
CMM [KUL03]. A principal diferença, em relação a seu antecessor, é a avaliação da
maturidade por chave de processo ao invés de considerar um grupo de áreas-chaves.
Esta forma de avaliação é conhecida como continuous e staged, respectivamente. Ainda
de acordo com [KUL03], é um framework que pode ser utilizado a partir de diversas
representações, composto por uma série de modelos.
O CMMI é composto por níveis de maturidade, áreas comuns de processos,
objetivos (genéricos e específicos), elementos e práticas (genéricas e específicas). Os
níveis representam o desempenho da organização em definir e institucionalizar seus
processos. Os níveis de maturidade são similares ao do CMM, chamados de: Nível 1-
33
Inicial; Nível 2-Gerenciado; Nível 3-Definido; 4-Quantificamente Gerenciado e Nível
5-Otimizado. Na estrutura continuous existe o nível 0 (incompleto), que representa que
a organização não implementa qualquer tipo de processo ou política relacionada a uma
área chave.
2.3.3 SPICE
Segundo [ROC01], SPICE (Software Process Improvement and Capability
dEtermination) foi o projeto da atual norma ISO/IEC 15504 para avaliação de processos
de software. Essa norma foi publicada como relatório técnico da ISO, como um
conjunto de nove documentos. Este modelo define uma abordagem relacionada à
realização de avaliações de processos de software com dois objetivos: a melhoria dos
processos e a determinação da capacidade de processos de uma organização. Se o
objetivo principal de uma empresa for o primeiro, a organização pode realizar a
avaliação gerando um perfil dos processos que serão utilizados para elaborar um plano
de melhorias. Ela deve definir os objetivos e contextos, bem como escolher o modelo e
o método para a avaliação da melhoria.
A norma SPICE aborda o conceito de evolução do nível de capacidade de
qualquer processo, definindo detalhes de cada um dos processos mencionados acima.
Para cada um deles existe uma definição detalhada, uma lista dos resultados da sua
implementação bem sucedida e uma descrição detalhada de cada uma das práticas
básicas. À medida que os objetivos dos processos vão sendo atingidos, ocorre uma
evolução em relação ao modelo SPICE.
Os níveis de maturidade do modelo são conhecidos como: Nível 0: Incompleto:
Não há processos institucionalizados na organização; Nível 1: Executável: A
organização implementa e executa alguns processos; Nível 2: Gerenciado: A
organização executa ajustes em suas normas para atender o modelo; Nível 3: Estável:
As normas e processos já foram executados tantas vezes que são parte do processo de
construção da organização; Nível 4: Previsível: A norma é customizada para a
organização; Nível 5: A organização pode otimizar o processo atual para melhor atender
as novas regras de negócio.
34
2.3.4 ITIL
A biblioteca de ativos de tecnologia de informação, ou ITIL (Information
Technology Infrastructure Library) é um framework de melhores práticas desenvolvido
no final da década de 80 pela British Standard for IT Service Management. Ela tem se
tornado um padrão internacional relativo à governança de TI. São providos conjuntos de
processos que irão controlar o setor de maneira a alinhá-lo às necessidades de negócio
da organização [ITI04a].
Ele é um conjunto de documentos cujo objetivo é implementar um serviço de
gerência de ativos de TI de maneira eficiente [ITI04a]. Este framework é customizável,
e, define como este serviço será realizado dentro da organização. Embora ele tenha sido
originado para utilização em empresas da indústria européia, ele tem sido amplamente
adotado por empresas ao redor do mundo.
Ele contém uma descrição dos processos envolvidos na gerência de TI,
caracterizando-os como serviços prestados. Estes serviços podem ser de natureza intra-
organizacional e inter-organizacional [ITI04b]. Ele possui uma abordagem centrada na
qualidade, em utilizar os ativos de TI de forma eficiente e corretamente. Pode-se
caracterizá-lo como um modelo de maturidade composto por um conjunto de melhores
práticas. A maturidade é regida de acordo com a implementação e implantação destes
processos e documentos na organização. A figura 2 apresenta uma visão geral de seu
objetivo e relacionamento com outros modelos de governança e de gestão de tecnologia
da informação.
Figura 2: ITIL e a Governança de TI [SUC04]
Devido à estratégia de implantar os processos, os níveis de maturidade do ITIL
seguem os mesmos princípios do CMMI, entretanto, sua estrutura não é conectada a um
35
conjunto de práticas ou processos, mas, apresenta como os processos podem ser
implementados na organização. Seus níveis são identificados como: Nível 0:
Inexistente; Nível 1: Inicial; Nível 2: Repetível; Nível 3: Definido; Nível 4: Gerenciado;
Nível 5: Otimizado.
2.3.5 CObIT
Mantido pela ISACA (Information Systems Audit and Control Association), o
CObIT (Control Objectives for Information and related Technology) é um modelo de
referência para a maturidade sob a governança de TI. Segundo [ISA04a] o objetivo do
CObIT é auxiliar na pesquisa, desenvolvimento e publicação de um conjunto
internacional de documentos para o controle de ativos de TI.
O modelo divide o setor de TI em 34 (trinta e quatro) processos de alto nível,
organizados em 4 (quatro) domínios diferentes. Estes domínios são: Planejamento
(Planning & Organization), Implementação (Acquiring & Implementing), Suporte
(Delivery & Support), e Monitoramento (Monitoring). Ao endereçar estes 34 (trinta e
quatro) objetivos, a organização deixa seu setor adequado às necessidades de controle
de ativos do setor [RID04]. A figura 3 apresenta o relacionamento dos domínios com os
outros componentes do modelo.
Figura 3: Elementos do CObIT [ISA04b]
Cada domínio é composto por um conjunto de processos, estes, são compostos
por atividades que necessitam ser realizadas. A correta execução destas atividades
permite que o processo seja executado e a necessidade do domínio, em atingir os
objetivos, seja alcançada.
Desta forma, cada processo é composto da seguinte forma:
36
• Objetivos em alto nível;
• Objetivos detalhados;
• Critérios de informação afetados pelo processo;
• Recursos de TI utilizados pelo processo;
• Características típicas de acordo com o nível de maturidade;
• Fatores críticos de sucesso;
• Indicadores de desempenho;
• Indicadores de objetivos.
A disposição dos domínios é composta em 3 (três) dimensões, são elas:
Processos de TI (são referentes aos processos organizados pelo modelo), Recursos de TI
(referente aos recursos de TI que os processos utilizam) e de Critérios de Informação
(constituem as informações relativas à qualidade, segurança e de ativos que geram
dados para o modelo). Organizado nestas 3 (três) dimensões, sua representação pode ser
exemplificada como mostra a figura 4.
Figura 4: O Cubo do Modelo CObIT [ISA04b]
Esta é a representação estática do modelo. Na medida em que os objetivos dos
processos vão sendo contemplados, a organização avança em maturidade e uso deste
modelo. Esta evolução é representada por uma escala de 0 a 5 que representam os níveis
de maturidade do modelo. Desta forma, podem-se comparar empresas que aplicam o
modelo CObIT e relacioná-las quanto à usabilidade do modelo ([ISA04c], [RID04]).
37
2.4 Modelos de Referência
Autores explicam que não existe um único modelo ou framework que defina
estratégias de desenvolvimento global de software, nem tampouco, para estratégias de
offshore ([KHA03a], [KIS03], [LOH02]). Podem existir diversos modelos que definem
como as equipes do projeto serão elaboradas, que por sua vez podem definir diversos
processos e procedimentos.
Organizações podem utilizar 2 (dois) ou 3 (três) modelos, aproveitando o que
melhor lhe convir. Esta prática comum de utilizar contribuições de um conjunto de
diferentes metodologias e modelos visa aperfeiçoá-los para as reais necessidades da
organização [KIS03]. Os principais modelos de referência para organizações de DGS
que utilizam o offshore são apresentados logo a seguir. Ainda que existam variantes, sua
estrutura principal é a mesma.
2.4.1 Modelo de Custo para DGS (Segundo [SON03])
Em [SON03] é estruturado um modelo de referência para auxiliar a decisão e a
escolha de qual país ou centro de desenvolvimento é mais adequado para atender as
necessidades da organização. Conceitualmente, ele considera como determinantes
elementos econômicos, políticos, gerenciais e técnicos envolvidos entre a contratante e
a contratada (ou subsidiária). O autor considera fatores locais (home factors), relativos
ao país da contratante, e os fatores destinos (host factors), caracterizando os fatores do
país destino onde o software será desenvolvido como fundamentais na tomada desta
decisão.
Os fatores da contratada (host factors) envolvem a disponibilidade – neste caso
é a disponibilidade de profissionais habilitados para trabalharem com as demandas
técnicas e não-técnicas existentes nos projetos; a educação institucional e treinamento
– utilizado para auxiliar no processo de aprendizagem. Envolve questões técnicas e não-
técnicas (por exemplo: treinar os funcionários para falar alemão); o custo – a
quantidade de pessoas que estarão envolvidas no projeto e quanto à contratada poderá
gastar; os riscos – referem-se a diversos fatores que envolvem estabilidade do governo,
interação cultural, burocracia, economia e estabilidade comercial. Os riscos aumentam a
incerteza do investimento. Em alguns casos, a existência de barreiras alfandegárias,
disciplinas anti-trust e protecionismo governamental também devem ser consideradas; a
38
taxa de câmbio – refere-se ao valor monetário exercido no país da contratada em
relação a uma taxa ou moeda base ou relativo ao país da empresa solicitante; e a infra-
estrutura – referem-se aos ativos computacionais existentes na organização contratada,
tais como telecomunicação, energia elétrica. Em alguns casos é interessante avaliar
fatores como distribuição de água e localização do centro da cidade, pois são fatores que
afetam as pessoas na organização. A relação destes fatores é identificada na figura 5.
Figura 5: Modelo de Custo Conceitual para DGS [SON03]
O autor subentende que existem outros elementos envolvidos nesta tomada de
decisão, como a mão-de-obra e o tempo de trabalho com equipes distribuídas. Fatores
deste tipo são agregados como incidentes em infra-estrutura e capacidade técnica.
Este modelo não busca ser absoluto em sua análise em estruturar decisões sobre
melhores localidades, mas sim, auxiliar na estratégia da escolha que deve conter outras
metodologias que dirigem a organização para uma melhor relação de custo-benefício
[SON03]. Neste contexto, é interessante observar que a decisão de enviar o processo de
desenvolvimento de software para qualquer país onde a solicitante desejar possui a
influência de fatores econômicos, políticos, gerenciais e técnicos (que devem estar bem
definidos).
Seleção
do local
para DGS
Educação
institucional e
treinamento
Custo
Disponibilidade
Fatores da Contratada
Risco
Taxa de Câmbio
Infra-estrutura
técnica
Decisão sobre
DGS
Gerentes de IT
Capacidade
Disponibilidade
Fatores da Solicitante
39
2.4.2 Modelo MuNDDoS (Segundo [PRI03])
Em [PRI03] é apresentado um modelo, denominado MuNDDoS – Maturidade
No Desenvolvimento Distribuído de Software, servindo de auxílio para desenvolvedores
que fazem parte de projetos com equipes distribuídas. Ele tem como objetivo, identificar
as características dos projetos em ambientes distribuídos e servir de apoio ao
desenvolvimento de software realizado por equipes de trabalho heterogêneas e
geograficamente dispersas. Estruturado após 2 (dois) estudos de caso e abrangendo 4
(quatro) projetos em duas grandes empresas de TI, este modelo, representado pela figura
6, é composto de fatores críticos. Além disso, ele oferece uma base para a condução de
projetos de DGS, visando: (1) facilitar a identificação de fraquezas e planejar melhorias
para minimizar possíveis problemas; (2) garantir que projetos de DGS sejam viáveis
com grupos de diferentes níveis de capacidade; e (3) aprimorar a capacidade da
organização.
Figura 6: Modelo de Referência MuNDDoS [PRI03]
Elaborado para atuar como facilitador nos projetos de DDS (Desenvolvimento
Distribuído de Software), sua forma permite que sejam identificadas fraquezas e
oportunidades de melhorias em projetos. Para isso, ele sugere a existência de duas
dimensões: organizacional e de projetos. Ampliando a visão relativa ao processo de
Planejamento Tático-Operacional
Aprendizado
Feedback
Novos
Projeto
Alocação
de Projetos
Planejamento Estratégico
Desenvolvimento de
Projetos
Matriz Unidades
Desenvolvimento de
Projetos
Desenvolvimento de
Projetos
40
desenvolvimento de software, buscando adotar uma visão estratégica com relação ao
processo, pode-se identificar a etapa de planejamento como sendo a primeira. Esta etapa
envolve a definição das estratégias que deverão conduzir o processo de
desenvolvimento como um todo, ao longo do tempo (mapeado pela dimensão
organizacional). Pode-se identificar a etapa de planejamento como sendo preliminar a
um conjunto de ciclos de projetos (mapeado pela esfera de projetos) derivados do
processo de planejamento.
Identificam-se 2 (dois) ciclos de planejamento necessários para a gestão de
projetos de DDS. O primeiro envolve o planejamento estratégico. Este ciclo é
conduzido pela matriz e diz respeito à identificação e priorização de novos projetos a
serem desenvolvidos, sejam eles projetos internos (de departamentos internos à
organização) ou externos (terceirizados). Além disso, cabe aos participantes deste nível
de planejamento buscar o alinhamento estratégico entre os objetivos de cada unidade
distribuída e da matriz. O segundo ciclo envolve o planejamento tático-operacional, no
âmbito da unidade de desenvolvimento de software distribuída. A transição entre os
dois ciclos de planejamento ocorre exatamente na alocação dos projetos, envolvendo
atividades de planejamento e definição dos projetos que serão desenvolvidos em cada
unidade distribuída, de acordo com políticas de alocação previamente definidas, análise
de risco e custo-benefício. O planejamento tático é de responsabilidade final dos
responsáveis por cada unidade de desenvolvimento, enquanto que o planejamento
operacional envolve a gestão do projeto (esfera de projetos), sob responsabilidade do
gerente de projeto.
A dimensão de projetos envolve especificamente a gerência do projeto de
desenvolvimento de software, centrada na coordenação geral do trabalho entre os
colaboradores, interfaces entre as equipes, comunicação, contato com os clientes e
resolução de conflitos. A esfera de projetos, caracterizada pelo desenvolvimento dos
mesmos, não estava focada na definição de um processo.
Pode-se ainda avaliar a necessidade de ajustes no desenvolvimento dos projetos,
em decorrência da existência ou da inexistência de algum fator. O último ciclo proposto
no modelo de referência é o de aprendizado, relativo à avaliação das atividades
realizadas, e estratégias adotadas. O modelo sugere a existência de um processo para
suportar a coleta de dados, envolvendo a avaliação dos trabalhos realizados, lições
aprendidas, etc. Desta forma, ele retro-alimenta os ciclos de planejamento.
41
Conforme identificado, estas estruturas compostas identificam e caracterizam a
organização conforme o alinhamento de sua estratégia de gerenciamento de projetos
DDS com as estratégias organizacionais. Esta comparação sofre uma evolução que é
suportada por este modelo. Desta maneira, ele comporta ciclos de capacidades
(compostos por níveis), identificados logo abaixo.
Estágios de Capacidade: Identifica que a capacidade evolui ao longo do tempo, com o
ganho constante de experiência. Nos experimentos, o autor identifica a evidência no
nível de maturidade de atuação em ambientes de DDS, tais como as características do
processo de desenvolvimento e a carga de treinamento existente. Foram identificados 4
(quatro) estágios de capacitação, de acordo com a experiência em projetos de DDS
existente nas organizações. A seguir descreve-se cada estágio e suas características:
Estágio 1: Inicial: Neste estágio os projetos distribuídos são desenvolvidos de uma
forma desorganizada. Os projetos são considerados únicos e não existe uma maior
preocupação em buscar informações sobre projetos similares ou das equipes envolvidas.
Existe apenas o processo de captação de novos projetos para serem desenvolvidos
(Novos Projetos). A decisão de desenvolver o projeto de forma distribuída é por
conveniência. Não existe um planejamento e processo formais, nem uma avaliação das
vantagens do desenvolvimento dos projetos em ambientes de DDS. As ações são
caracterizadas como sendo reativas.
Estágio 2: Básico: Neste estágio os projetos ainda são considerados únicos e apresentam
um nível básico de organização. Os fatores envolvidos na dimensão do projeto
(Desenvolvimento dos Projetos) passam a ser analisados para minimizar dificuldades.
Existe uma tendência para a prevenção de problemas, mas sem consulta a experiências
anteriores. A decisão de desenvolver o projeto de forma distribuída continua sendo por
conveniência. O planejamento e processo formais são realizados somente em nível de
projeto. Não existe um processo estabelecido de avaliação e feedback.
Estágio 3: Planejado: Neste estágio inserem-se os ciclos de planejamento estratégico
(esfera organizacional) e tático-operacional (esfera de projetos). Um projeto não é mais
considerado singular. Além dos fatores envolvidos na dimensão de projetos, existe um
processo formal para analisar e decidir se existe vantagens de desenvolver o projeto de
42
forma distribuída (Alocação de Projetos). Isto faz com que a abordagem preventiva não
seja apenas uma tendência, mas uma realidade. A consulta a experiências anteriores
ocorre apenas internamente a cada processo. Neste sentido, não existe um processo
estabelecido de avaliação e de feedback baseado em conhecimento organizacional.
Estágio 4: Otimizado: Neste estágio, insere-se o processo de Avaliação e de Feedback.
Além do processo de Alocação de Projetos e dos fatores envolvidos na dimensão de
projetos, todos os projetos já desenvolvidos geram uma base de conhecimento que será
utilizada como subsídio para o desenvolvimento de novos projetos, realimentando os
ciclos de planejamento estratégico e tático-operacional.
Este modelo visa identificar a estrutura organizacional relativa ao DGS,
demonstrando fatores que incidem sobre a maturidade da empresa. Por si apenas ele não
caracteriza um modelo de maturidade, para uma organização ser reconhecida em um
estágio de capacidade ela deve satisfazer as atividades envolvidas no respectivo estágio.
Como a capacidade diz respeito à maturidade da organização em projetos distribuídos, e
tendo por base a forma como o estudo foi concebido, o reconhecimento de uma
determinada organização em um estágio específico deve ser realizado através dos
processos existentes dentro da sua realidade [PRI03].
2.4.3 Modelo para Organizações Outsourcing (Segundo [LOH02])
Os autores desenvolveram um modelo conceitual para organizações
terceirizadas, utilizando um conjunto de benefícios e riscos como determinantes do
desempenho (performance) da organização.
Baseado nos estudos da estratégia de outsourcing como redutor de custos, os
autores de [LOH02] procuram traçar uma relação entre benefícios e riscos que existem
quando se estrutura uma organização terceirizada (outsourced). Através de um
questionário enviado para os executivos e gestores das empresas analisadas, eles
estruturaram os fatores que incidem na performance de uma organização terceirizada.
A intenção deste modelo não fica limitada a demonstrar a relação existente entre
risco e benefício como fatores chaves da terceirização, mas demonstrar pontos em que
medições podem ser coletadas, maximizando lucros e minimizando perdas. Baseados
em dados coletados das próprias organizações.
43
Aplicado apenas em organizações com estas características, onde processo e
métricas não dependem de definições da contratante, a figura 7 demonstra como o
modelo foi estruturado. Em seguida, os riscos e benefícios do modelo são apresentados.
Figura 7: Modelo para Organizações Terceirizadas [LOH02]
O modelo é composto por quatro variáveis dispostas ortogonalmente da seguinte
forma: (1) benefício técnico; (2) benefício de negócio; (3) controle de risco e (4)
oportunismo. Estes fatores, alinhados com uma estrutura de custo da organização
terceirizada, implicam diretamente na sua (5) performance. Por conseguinte, este
desempenho reflete-se no trabalho que ela irá desempenhar perante seus clientes e
contratantes.
2.4.4 Modelo para Organizações Offshore Outsourcing (Segundo
[KIS03])
Em [KIS03] é definido um framework para estruturar o relacionamento entre a
contratante e a prestadora do serviço. Conhecido como FORT (Four Outsourcing
Relationship Types), ele procura dimensionar os relacionamentos entre as empresas
envolvidas de forma a estabelecer o impacto estratégico que elas possuem perante o
negócio da contratante. As relações entre as organizações irão variar ao longo do tempo,
sendo interessante denotar os tipos de serviços que poderão caracterizar. Conforme a
IT
Outsourcing
Fatores
Técnicos
Controle
Fatores de
negócio
Benefícios
O
p
ortunismo
Riscos
Performance
Estrutura
de Custo
44
figura 8, ele apresenta duas dimensões principais: O impacto estratégico do negócio
sendo terceirizado e o volume
1
de negócio que está sendo terceirizado.
Figura 8: FORT Framework [KIS03]
A primeira dimensão lida com a transferência de responsabilidade sobre
determinado serviço para outra organização, e, varia conforme o grau de seus ativos e o
impacto no negócio. A segunda dimensão lida com o impacto estratégico deste serviço
perante seu negócio, caracterizando-a perante a terceirizada.
Este modelo visa caracterizar aspectos dinâmicos e estáticos na relação
contratante-contratada e examina este movimento entre as empresas através da análise
dos impactos estratégicos e de extensão do contato existente entre elas. Ele demonstra
onde a organização contratada está posicionada perante a estratégia de negócio da
contratante. O objetivo deste modelo é estabelecer de forma clara o relacionamento que
ambas as organizações estarão criando ao longo do tempo e seu impacto estratégico
para a organização contratante.
Quando o impacto na organização (do que esta sendo terceirizado) é muito
baixo, e o volume de trabalho terceirizado é muito pequeno, entende-se que o tipo de
relacionamento entre a contratada e contratante é caracterizado pelo suporte. Quando o
impacto no negócio é alto e a quantidade é baixa, diz-se que a contratada e a contratante
1
Subentende-se que o volume é o tamanho mínimo necessário de serviço que pode ser terceirizado.
Caracterizando um software ou parte dele [KIS03].
Baixo
Alto
Impacto estratégico do negócio sendo terceirizado
Volume da extensão do negócio a ser terceirizado
Alto Pseudo-Parceria Parceria/Aliança
Baixo Suporte
Alinhamento
de Negócio
45
estabelecem um relacionamento de alinhamento de negócio. Quando a quantidade de
trabalho é alta e o impacto no negócio é baixo, é estabelecido um relacionamento
caracterizado por uma “pseudo-aliança”. Devido à quantidade de tempo e de
envolvimento que ambas estarão gerando, no entanto seu impacto estratégico na
organização contratante é relativamente pequeno. Quando a quantidade é alta e o
impacto no negócio da contrata também, as empresas estão trabalhando em um nível de
parceria ou aliança.
Este último tipo tende a ser o mais complexo existente criado pelas organizações
envolvidas. Ele inicia com o intercâmbio de pequenos projetos e serviços que vão
crescendo ao longo do tempo e vão agregando cada vez mais valor ao negócio da
contratante. Por este motivo, diz-se que o desenvolvimento de um relacionamento do
tipo aliança é um processo dinâmico. Geralmente, neste último estágio, a organização
contratada detém o controle da especificação do software desenvolvido e dos processos
que o gerenciam.
No último estágio, a confiança da equipe de desenvolvimento perante o trabalho
desenvolvido é fator fundamental. Neste contexto, em todas as etapas, fatores sociais
como a comunicação e a cultura são consideradas relevantes no alinhamento entre as
empresas.
Os relacionamentos tendem a evoluir ao longo do tempo devido a modificações
de requisitos e de necessidades das empresas envolvidas. Por este motivo, eles não são
estáticos, neste contexto, é interessante mapear as evoluções de relacionamento que
podem existir entre as empresas e o impacto que elas têm perante as estratégias de cada
uma.
2.4.5 Modelo para Organizações Offshore Outsourcing (Segundo
[KHA03a])
No trabalho realizado por [KHA03a], são identificados organizações que
compõe o offshore outsourcing como sendo de 2 (dois) tipos: as que prestam serviços
offshore e as que fornecem mão de obra (também conhecidas como body-shopping). A
partir desta classificação, os autores estruturaram um modelo que visa identificar
benefícios e riscos de cada abordagem, auxiliando na tomada de decisão.
Este modelo tem como objetivo mapear todas as relações existentes entre as
organizações que utilizam esta estratégia e delimitar uma relação entre valor agregado e
risco, inerentes a processos offshore. Neste contexto, é necessário definir quais os tipos
46
abrangidos por este modelo. Conforme mostra a figura 9, a relação entre valor e risco é
diretamente proporcional ao tipo de serviço em questão. Quanto mais complexo, mais
riscos e maiores benefícios podem ser agregados. Desta forma, os autores estruturaram
o modelo em uma escala de 5 (cinco) níveis, que representam o valor mais baixo, com
menor risco agregado (1) até o valor mais alto valor agregado, com maior risco
envolvido (5).
Figura 9: Modelo para Organizações Offshore Outsourcing [KHA03a]
O autor utilizou este modelo em aproximadamente 25 (vinte e cinco) empresas
do setor de telecomunicações, engenharia e TI, gerando resultados e constituindo o
modelo final para referência. Este modelo pode ser utilizado para qualquer um dos tipos
de organizações relacionados abaixo.
• Empresas prestadoras de serviços de offshore: É caracterizado por empresas que
fornecem ou prestam serviços diretamente para outra empresa. Por exemplo,
subsidiárias proprietárias, joint venture, terceirizadas e quarteirizadas.
• Fornecedoras de mão-de-obra ou body-shoppings: Refere-se a empresas que
fornecem profissionais com determinada qualificação para outras empresas.
Alto Risco
Baixo Risco
Nível 1: Body Shoppping
Nível 2: Offshore services:
development and project execution
Nível 3: Definição de Padrões
Nível 4: Consulta e desenha a
arquitetura do negocio (p. e. IT)
Nível 5: Suprimento total das
necessidades do cliente
Arquiteta e desenvolve o
produto final
Executa o projeto e o
entrega após certo tempo
Produz software de acordo
com padrões pré-definidos
pela contratante e prove
especialização
Constrói relacionamento –
fusões, aliança, aquisições
Prove pessoal capacitado
Alto Valor
Baixo Valor
47
2.5 Trabalhos Relacionados
Existem alguns trabalhos relacionados no sentido de compor um modelo de
maturidade para organizações offshore. Estes modelos se propõem a identificar um
estágio, ou nível, em que a organização ou a equipe se encontra. Eles não mapeiam o
que deve ser feito, mas fornecem um suporte para como deve ser feito [MOR03]. Estes
modelos de maturidade explicam as características existentes em cada e as razões que
diferenciam os níveis – geralmente agrupados por fatores que são evoluídos ao longo do
tempo. Eles podem ser compostos por um ou mais modelos de referência [SEI95].
Neste contexto, existem modelos de maturidade para organizações que utilizam
o DGS e a estratégia de desenvolvimento offshore. Neste contexto, os modelos Source
of IT Work Offshore (SITO) e o Offshore Maturity Model (OMM) são apresentados logo
a seguir.
2.5.1 Modelo SITO (Segundo [CAR02])
Em [CAR02], os autores definem um modelo de maturidade para organizações
de TI offshore sourcing. Conhecido por Source of IT Work Offshore (SITO), ele define
4 (quatro) níveis em que as organizações que trabalham com projetos de TI offshore
podem estar contextualizadas. Em cada nível, existe uma descrição sobre as
características das organizações e o tipo de atividade que elas podem suportar. A figura
10 define este modelo.
Sourcing of IT Work Offshore (SITO) Stage Model
Stage
1
2
3
4
Offshore
Bystander
Domestic sourcing only.
Offshore
Experimenter
Experimentation
begins.
Sourcing is ad hoc.
Proactive
Cost Focus
Sourcing of non-core
work is encouraged
at offshore centers,
with the goal of
cutting costs.
Offshore management
mechanisms emerge.
Proactive
Strategic Focus
Core IT work is
sourced to offshore
centers, with the goal
of achieving
competitive advantage.
Distance management
mechanisms are mature
Figura 10: Modelo de Offshore SITO [CAR02]
48
Estágio 1 (Offshore Bystander): Neste estágio, não há atividades de offshore sourcing,
todo o tipo de demanda relativa a TI é realizada pela própria companhia.
Estágio 2 (Offshore Experimenter): Neste estágio, as organizações começam a
experimentar a estratégia de offshore, no entanto, ainda não possuem um controle muito
ativo do que estão fazendo. Caracteriza uma fase experimental para a organização, além
disso, é comum a existência de projetos pilotos.
Estágio 3 (Proactive Cost Focus): A transição do estágio 2 para o 3 é marcada pela
mudança de comportamento reativo para pró-ativo. Mecanismos de gerência destes
serviços começam a surgir. Logo, é comum que nesta etapa, os gerentes desenvolvam
capacidades e experiência para se relacionarem com a prestadora de serviços offshore.
Estágio 4 (Proactive Strategic Focus): Nesta etapa, as organizações utilizam o offshore
como uma estratégia de negócio, extrapolando necessidades pontuais como redução de
custo apenas. A inovação é notada na cultura e no clima organizacional, atingida
diretamente com a agregação de centros de desenvolvimento, suprimindo necessidades
do setor de TI. Uma grande diferença entre os estágios 3 e 4 é que a organização
offshore, rotineiramente, desenvolve novos produtos de TI, assumindo total
responsabilidade pelos softwares da companhia.
Aumentando o nível de relacionamento com a organização offshore, a empresa
matriz começa a estabelecer métricas relativas a processos e controle de qualidade. A
evolução deste controle, onde a matriz define os padrões e as metas a serem atingidas e
seguidas, define outra grande característica de organizações no nível 4 do modelo SITO,
as que possuem os chamados centros globais de desenvolvimento (GDC) ou de
provedora de serviços globais (ASP – Application Server Providers). A utilização de
centros especializados da própria organização localizadas em outro país caracteriza o
tipo de desenvolvimento distribuído offshore insourcing ou simplesmente offshore
insourcing, novamente, comum de empresas que estão em um nível mais elevado de
desenvolvimento utilizando a estratégia offshore.
O autor caracteriza a tendência de utilizar centros de desenvolvimento globais
envolvendo subsidiárias, ou terceirizadas em outros países.
2.5.2 Modelo OMM (Segundo [MOR03])
Em [MOR03] é apresentado um modelo de maturidade para organizações
offshore. Conhecido por Offshore Maturity Model (OMM), seu objetivo é posicionar a
49
empresa que esta sendo avaliada quanto ao grau de maturidade de seus processos,
métricas, pessoas, tecnologia e relacionamento.
A grande diferença deste modelo é a relação sobre o custo de investimento entre
cada nível de maturidade. Quais os ativos que devem ser priorizados quando a
organização começa a estruturar suas atividades de forma offshore. Não ocorre uma
estimativa em valores, mas uma relação sobre onde o capital deve ser investido para
evoluir no modelo.
O autor ainda explica que o OMM é um modelo para gerenciar os riscos para
redefinir atividades e serviços de TI, com um custo reduzido e com qualidade igual ou
superior da empresa matriz. A figura 11 apresenta os níveis do modelo conceitual.
Figura 11: Níveis do OMM [MOR03]
Level 1: “Staff Augmentation”: Nesta etapa, a organização começa a entrar em contato
com empresas offshore, com o objetivo apenas de aumentar o número de pessoas
envolvidas nas atividades, no entanto, sem aumentar seu custo. Projetos do tipo offshore
não existem.
Level 2: “Turnkey”: A organização caracterizada neste estágio desenvolve projetos
offshore como exercício para envolver e iniciar o trabalho com as equipes distribuídas.
Existe o conceito primário sobre risco que envolve os projetos com esta característica.
Level 3: Integrado
: A organização solicitante começa a delegar atividades de design e
análise dos projetos nesta etapa. Os produtos possuem uma qualidade constante.
Benefícios e Valor Agregado
Level 1: “Staff Augmentation”
Level 2: “Turnkey”
Level 3: Integrado
Level 4: Gerenciado
Level 5: Otimizado
50
Level 4: Gerenciado: Um foco muito grande é dado pelo entendimento e
regulamentação dos processos utilizados dentro e fora da organização contratante.
Level 5: Otimizado: Assume que a organização offshore esta estabelecida e é parte
fundamental dos negócios da matriz, sendo em alguns casos transparente para seus
clientes a utilização de tais práticas Neste estágio, a organização contratante começa a
ter muito mais retorno financeiro e de capacidade, inicialmente buscados com o
desenvolvimento offshore.
O autor explica ainda que o modelo é limitado e imperfeito, pois ele não detalha
processos nem especifica objetivos de atividades em situações cotidianas. Entretanto,
quando utilizado em conjunto com modelos para metodologias de domínio específico,
como o CMM, o OMM prove um guia de observações sobre gerência de risco em
ambientes distribuídos. Ele auxilia também na identificação dos recursos de TI
necessário para estabelecer um relacionamento global entre as organizações envolvidas.
O modelo OMM procura apresentar os melhores caminhos para as empresas
desenvolverem suas atividades de forma distribuída, alinhando custos com métricas, e
prevendo o tipo de qualidade no serviço das empresas offshore. Desta forma, conforme
mostra a figura 12, existe uma relação direta entre os benefícios do modelo, sua
complexidade, seus níveis e a capacidade de trabalho com empresas offshore.
Figura 12: Benefícios, Complexidade, Integração e Níveis do OMM [MOR03]
Nível 5
Nível 4
Nível 3
Nível 2
Nível 1
Níveis OMM
I
N
T
E
G
R
A
Ç
Ã
O
Benefícios
Baixo
Alto Baixo
Complexidade
Nível 1
Nível 2
Nível 3
Nível 5
Nível 4
51
A similaridade de conceitos e definições com o CMM não são acidentais, ele foi
construído com base no modelo do SEI (Software Engineer Institute), tomado como
referência pelo autor como modelo gerencial. Além disso, a adoção de métricas e a
continua otimização dos processos são fundamentais para a evolução da organização.
Apesar disso, os modelos são diferentes. O CMM posiciona a organização
quanto à definição, implementação, mensuração, controle e melhorias nos seus
processos de construção de software. O modelo OMM, no entanto, visa suportar a
organização durante uma curva de aprendizado, em relação ao offshore. Ele foca na
habilidade de distribuir operações para trabalhar eficientemente como parte da mesma
organização ou através de um parceiro ou aliado.
2.6 Análise Comparativa
A seguir serão apresentadas análises comparativas dos modelos de referência e
de maturidade para organizações DGS que utilizam a estratégia de desenvolvimento
offshore. O objetivo é fazer uma análise comparativa destes modelos. Para isto, foi
identificado um conjunto de critérios de comparação.
2.6.1 Modelos de Maturidade e de Governança de TI
Identificaram-se algumas propriedades que são comuns à estrutura dos modelos
analisados. Estas observações são relevantes para compor um modelo de maturidade
para organizações que utilizam estratégias de DGS. São elas:
a) Todos os modelos observados são iterativos, ou seja, é necessário um tempo
até atingir determinado nível de capacitação ou maturidade;
b) São modelos evolucionários, ou seja, crescem em escopo e aumentam a
complexidade dos processos ao longo do tempo;
c) São compostos por um conjunto de processos ou de documentos que o
satisfazem;
d) São geralmente compostos por uma estrutura estática e uma dinâmica
(evolução);
e) A maior parte dos modelos possui um checklist para validar se os objetivos de
cada processo ou norma foram atingidos;
52
f) O modelo de maturidade serve para ter uma impressão, em determinado
momento do tempo, sobre a usabilidade de determinado modelo estático em uma
organização. Sua evolução é sempre referente a si mesmo e não aos ativos de TI
ou a outra variável. Como por exemplo, fatores de clima e cultura
organizacionais – o contrário pode ser verdadeiro;
g) Modelos de maturidade não são restritos a definições de processos e
guidelines;
h) Eles podem ser responsáveis por um escopo estratégico muito maior, como a
governança de TI (CobiT e ITIL).
O CMM possui uma das estruturas mais simples e utilizada dos modelos aqui
apresentados. Além disso, ele foi criado para atender necessidades de organizações que
desenvolvem software. No entanto, uma limitação do modelo é sua falta de abrangência
em relação à governança de TI. Neste aspecto, utilizar as estruturas dos modelos CobiT
e ITIL para complementar esta carência seria uma solução interessante. Entre o ITIL e o
CobiT, o segundo possui um alinhamento mais claro entre as necessidades de negócio,
os recursos e os processos de TI. O ITIL abrange a governança, mas não especializa os
elementos envolvidos, ficando a cargo da organização em defini-los.
Sendo assim, sugere-se a utilização do CMM e do CobiT para compor um
modelo de maturidade para organizações que utilizam DGS. Utilizando a estrutura
estática do CMM no lugar da dimensão de processos de TI do modelo cúbico do CobiT.
Identificando ainda, 5 níveis de maturidade para classificar as organizações. Esta
classificação seguiria os mesmos parâmetros da estipulada pelo CMM.
2.6.2 Modelos de Referência
Foi realizada uma extensa revisão bibliográfica para identificar critérios de
avaliação de modelos de DGS. Devido a ser um assunto recente, nada foi encontrado
2
.
Partiu-se então para uma análise crítica dos modelos existentes na tentativa de estruturar
os critérios que pudessem ser relevantes em modelos DGS e offshore. A tabela 2
apresenta o critério e a descrição dos itens comparativos.
2
É importante salientar que apesar de terem sido estruturados entre 5 e 10 anos atrás, não existem muitos
trabalhos relacionando-os em congressos do tipo ACM e IEEE.
53
Tabela 2: Critérios de Análise para os Modelos DGS e Offshore
Critério Descrição
1- Aplicabilidade Prática
(Existência de Estudos de
Caso/Experimentos/Surveys)
A fim de validar uma determinada solução, é importante que
estudos de caso ou experimentos tenham sido feitos para
comprovar a validade do modelo. Este critério tem como
objetivo diferenciar modelos que foram aplicados em diversas
empresas e que constituem um número significativo de testes
de validações realizados dos que não foram ou não possuem
esta informação;
2- Aspectos Sociais Este critério busca caracterizar se o modelo analisado considera
e/ou suporta fatores sociais na sua estrutura e composição. São
considerados como fatores sociais para esta análise: Aspectos
Culturais, Gestão Organizacional, Comunicação, Confiança e
Controle sobre atividades;
3- Aspectos de Negócio
(alinhamento do objetivo do
modelo e da organização)
Considera aqui se o modelo analisado possui uma conexão
entre os objetivos de negócio e seu objetivo funcional (como
modelo ou framework);
4- Relacionamento entre
contratada e contratante
Este critério considera se o modelo faz algum tipo de referência
ou explica como acontece o relacionamento entre as empresas
envolvidas no desenvolvimento global do software;
5- Diferenciação quanto ao
tipo de serviço
Consideram-se aqui os modelos que fazem distinção entre sua
aplicabilidade a outsourcing, insourcing, ou ambos.
6- Planejamento do processo
de DGS
Este critério verifica se o modelo analisado possui
características que permitam organizar e estruturar processos
de desenvolvimento distribuído;
7- Aspectos Técnicos Este critério procura identificar se o modelo possui algum
suporte para processos de engenharia de software;
8- Suporte para equipes
distribuídas
Este critério procura identificar se o modelo analisado possui
uma estrutura que permita estendê-lo para a concepção de
equipes globais.
Estruturar critérios de análise é uma tarefa difícil e com margem para muitos
questionamentos que podem extrapolar o escopo deste trabalho. Não se busca limitá-los
ou restringir os modelos a este conjunto de critérios de análise. No entanto, esta
formulação preliminar poderá servir de base para estudos futuros envolvendo estes
mesmos modelos.
54
Na tentativa de melhor estruturar a análise dos modelos, a tabela 3 logo abaixo,
foi elaborada. No cabeçalho ela possui a numeração dos respectivos critérios utilizados
nas análises críticas dos modelos. Para representar cada modelo foram utilizadas as
letras de A até E. Baseado na tabela 2, apresentado acima, utilizou-se os números de 1 a
8 para representar os critérios analisados.
Utilizaram-se como base informações fornecidas e pesquisadas, bem como
coletadas pelas análises críticas de cada modelo. A tabela 4 apresenta a legenda com os
nomes utilizados. Quando o modelo contempla o critério, um símbolo (√) é introduzido
na relação modelo e critério. Quando não há o símbolo, o modelo não contempla o
critério analisado.
Tabela 3: Análise Comparativa dos Modelos
12345678
√√√
√√√ √ √
√√
√
√√
√
√√√√
√
√√
√√√
E
Modelo de Refetência
B
Critérios de Análise
A
C
D
Tabela 4: Legenda Representativa com o Nome dos Modelos DGS e Offshore
Legenda: Modelo:
A Modelo de Custo para DGS (Segundo [SON03])
B Modelo MuNDDoS (segundo [PRI03])
C Modelo para Organizações Outsourcing (segundo [LOH02])
D Modelo para Organizações Outsourcing (segundo [KIS03])
E Modelo para Organizações Offshore Outsourcing (segundo [KHA03a])
A análise desenvolvida a partir dos critérios identificados no item anterior
apresenta carências em todos os modelos referentes aos critérios 4 (Relacionamento
entre contratada e contratante), 5 (Diferenciação quanto ao tipo de serviço) e 7
(Aspectos Técnicos). Sendo que este último foi identificado em apenas um dos modelos
apresentados neste trabalho.
2.6.3 Modelos de Maturidade Offshore
Da mesma forma como identificado na seção anterior, realizou-se uma extensa
revisão bibliográfica para identificar critérios de avaliação de modelos de maturidade
para DGS. Apesar desta, nenhum tipo de análise para estes modelos foi encontrada.
55
Criou-se então, critérios relevantes e pertinentes de modelos de maturidade para DGS.
A tabela 5 apresenta o critério e a descrição de sua escolha.
Tabela 5: Critérios de Análise para os Modelos de Maturidade para DGS
Critério Descrição
1- Governança Este item verifica se o modelo de maturidade possui suporte ou
indicativo de governança sobre TI. Principalmente no que se
refere à DGS;
2- Maturidade do Processo Este critério identifica se os modelos descrevem a evolução de
seus processos. Ou seja, se existe a necessidade de maturação
na utilização dos processos;
3- Nível Organizacional Identifica o nível organizacional que o modelo inicialmente foi
concebido. Sendo E (para o nível estratégico), T (para o nível
tático) e O (para o nível operacional);
4- Implementação e
Implantação
Identifica se o modelo traz informações para sua correta
implementação e implantação;
5- Alinhamento com outros
modelos
Verifica se o modelo de maturidade esta alinhado, ou pode ser
alinhado, com outros dos modelos de referencia ou maturidade.
A análise comparativa está relacionada na tabela 6. No cabeçalho ela possui a
numeração dos respectivos critérios utilizados na análise crítica dos modelos. Quando o
modelo contempla o critério, um símbolo (√) é introduzido na relação modelo e critério.
Quando não há o símbolo, o modelo não contempla o critério analisado.
Tabela 6: Análise Comparativa dos Modelos de Maturidade
12345
√
E
√√E,O √
Modelo de Maturidade
SITO
OMM
Critérios de Análise
Conforme analisado, os modelos apresentam carências na questão de
implementação e implantação. Eles não apresentam detalhes sobre como isto pode ser
feito. O modelo OMM possui um forte relacionamento com o CMM, no entanto, não é
apresentando onde ele possui tais dependências.
56
O modelo SITO não especializa as relações de cada nível de maturidade com
dimensões ou áreas chaves de processo que deveriam existir na organização. Desta
forma, não é possível identificar se o modelo atende as necessidades da organização.
O modelo OMM demonstrou ser altamente dependente do CMM, não sendo
possível efetuar uma avaliação apenas em relação à maturidade de empresa em relação
aos serviços offshore insourcing.
57
3. Método de Pesquisa
Esta pesquisa se caracteriza como um estudo exploratório [YIN01]. Ela visa
desenvolver novos conhecimentos sobre o DGS em ambientes offshore insourcing. O
principal método de pesquisa utilizado foi o estudo de caso, conforme proposto por
[YIN01]. Foi desenvolvido um estudo de caso múltiplo, aplicado em 4 (quatro)
organizações que praticam o DGS em ambientes offshore insourcing.
3.1 Desenho de Pesquisa
Este trabalho é parte de uma pesquisa de maior escopo, inserida dentro do grupo
de estudo MuNDDOS, cujo objetivo é definir um modelo de maturidade para
organizações offshore insourcing, conforme definido em [EVA04b]. A figura 14
apresenta o desenho de pesquisa, utilizado para este trabalho.
Esta pesquisa esta organizada em 4 (quatro) fases. A primeira fase constitui de
uma revisão bibliográfica com o objetivo de aumentar o conhecimento sobre a estrutura
de modelos de maturidade de desenvolvimento global de software e a aplicação de
estudos de caso, visando identificar as principais características presentes de centros de
DGS em ambientes offshore insourcing.
A segunda fase consolidou a estrutura do modelo de maturidade, bem como
elaborou e delimitou as características dos centros.
A terceira fase propõe a realização de um estudo quantitativo para avaliar a
aplicação do modelo em uma organização em ambientes offshore insourcing.
A quarta fase propõe a elaboração do modelo de maturidade para organizações
de desenvolvimento global em ambientes offshore insourcing. A terceira e a quarta fase
não foram consideradas no trabalho devido a limitações de tempo e de escopo.
Na fase 1 (um) procurou-se revisar a base teórica existente na disciplina de
engenharia de software, mais especificamente, na área de escopo deste trabalho. Foi
realizado ainda 4 (quatro) estudos de caso em 3 diferentes empresas que trabalham com
o desenvolvimento global de software em ambientes offshore insourcing. As empresas
escolhidas foram a Dell Inc., especificamente sua unidade de desenvolvimento - Global
Development Center Brazil (empresa subsidiária do setor de TI da empresa com sede
58
em Porto Alegre, Brasil) e o Asia Product Center (APC) (empresa subsidiária do setor
de TI da empresa com sede em Xiamen, China), o grupo SONAE, especificamente sua
unidade de estudo foi a Tlantic (empresa subsidiária do setor de TI da empresa com
sede em Porto Alegre, Brasil), e a ComSoft, especificamente sua unidade de
desenvolvimento (empresa de desenvolvimento de software com sede em Cingapura).
Figura 13: Desenho de Pesquisa
A fase 2 (dois) é constituída da elaboração de uma estrutura de modelo de
maturidade para DGS, baseado na bibliografia e nas características identificadas nos
estudos de caso. Ainda na terceira fase, definiu-se a estrutura de organização das
características dos centros e como elas estariam relacionadas para compor o modelo de
maturidade. Elas foram enumeradas baseadas na análise dos resultados do estudo de
caso, bem como seu relacionamento com a estrutura do modelo.
A fase 3 (três) envolve a análise de outros elementos que são necessários para
compor um modelo de maturidade. Estes dados são compostos de críticas, sugestões e
oportunidades de melhoria geradas a partir do resultado de uma análise quantitativa
(survey). Por tratar-se de uma pesquisa qualitativa, devem-se ter claras as limitações
Base
Teórica
Estudo de
Caso 1
Estudo de
Caso 2
Estudo de
Caso 3
Estudo de
Caso 4
Fase 1
Estrutura
Proposta
Fase 2
Análise
Quantitativa
(
Surve
y
)
Modelo
de
Maturidade
Fase 3 Fase 4
59
deste tipo de pesquisa, principalmente no que se refere ao número de estudos de caso,
restringindo a generalização dos resultados obtidos.
A fase 4 (quatro) será a consolidação dos resultados de outras fases a fim de
compor o modelo de maturidade para empresas offshore insourcing. Nesta etapa, poderá
ser feito um estudo de caso para validar o modelo de maturidade proposto.
Este projeto de pesquisa envolve as fases 1 e 2. As fases 3 e 4 inserem-se em
uma pesquisa de maior escopo do grupo MuNDDoS da Faculdade de Informática do
Rio Grande do Sul, em conjunto com a Universidade de Illinois (Chicago – Estados
Unidos) e da Universidade de Victoria (British Columbia – Canadá), envolvendo uma
tese de doutorado e uma dissertação de mestrado.
3.2 Estudo de Caso
De acordo com o desenho de pesquisa, foi conduzido o estudo de caso múltiplo,
visando coletar e identificar as características do ambiente offshore insourcing.
Inicialmente foi desenvolvido um protocolo de estudo de caso, definindo objetivo,
escopo, unidade de análise, procedimento, dimensões e questões (Apêndice A -
Protocolo de estudo de caso - Estudo de caso Múltiplo). As unidades de estudo estão
descritas na seção logo abaixo.
3.2.1 Unidade do Estudo de Caso
A unidade dos estudos foram as unidades de organizações de desenvolvimento
global de software que operam em um ambiente offshore insourcing. A análise dos
resultados dos estudos será apresentada nas seções a seguir.
60
61
4. Resultados do Estudo de Caso
Neste capítulo são apresentados os resultados e análises dos estudos de caso
conduzido nas empresas descritas no capítulo 3. A seção 4.1 apresenta as características
das unidades analisadas. A seção 4.2 apresenta a metodologia específica dos estudos de
casos. A seção 4.3 apresenta o instrumento de pesquisa. A seção 4.4 apresenta a análise
dos resultados do estudo e a seção 4.5 apresenta as considerações do estudo e as
características que serão considerados na estrutura do modelo.
4.1 Características das Organizações Analisadas
A engenharia de software define uma série de elementos que compõe um
processo de desenvolvimento ([AUD01], [MCC96] e [SEI95]). Estes processos guiam
como os sistemas serão construídos. Os passos e fases necessários existentes para
garantir a qualidade do produto gerado que devem ser seguidos. As organizações de
tecnologia da informação aplicam estes conceitos largamente em seus métodos e
procedimentos criados especificamente para atender suas necessidades. As organizações
pertencentes ao estudo são todas da área de TI. Em nenhuma se observou um método
diferente dos existentes apontados por autores clássicos da disciplina.
Neste contexto, serão apresentadas as principais características relativas
engenharia de software, mais especificamente no desenvolvimento global de software
em ambientes offshore insourcing, das unidades de desenvolvimento compreendidas
pelo estudo de caso. Estudaram-se 4 (quatro) centros de desenvolvimento com a
seguinte distribuição geográfica:
• 2 (dois) centros localizados no parque tecnológico da Pontifícia
Universidade Católica do Rio Grande do Sul (TECNOPUC-PUCRS) em
Porto Alegre, Brasil;
• 1 (um) centro de desenvolvimento localizado em Xiamen, China;
• 1 (um) centro de desenvolvimento localizado em Cingapura
3
;
A organização Dell Inc. possui um dos centros localizados no TECNOPUC-
PUCRS e o outro localizado em Xiamen. O grupo SONAE possui seu centro localizado
3
Devido a facilidades geográficas, o estudo foi conduzido com os representantes da empresa de
Cingapura em Xiamen, na China.
62
no TECNOPUC-PUCRS. A ComSoft possui seu centro localizado em Cingapura. A
tabela 7 traça o relacionamento entre o centro, a localização, a organização matriz e
como o centro será referenciado ao longo do relatório.
Tabela 7: Unidades do Estudo de Caso
Centro (ou Unidade) Localização Organização Matriz Referência na
Pesquisa
GDC Porto Alegre, Brasil Dell Inc. Centro A
Tlantic Porto Alegre, Brasil Grupo SONAE Centro B
APC Xiamen, China Dell Inc. Centro C
Unidade ComSoft Cingapura ComSoft Centro D
4.1.1 Característica da Organização do Centro A e C
A organização tem filial em mais de 34 países, com aproximadamente 50 mil
colaboradores e tem sua matriz localizada nos Estados Unidos. No centro A existem,
aproximadamente, 200 colaboradores trabalhando em projetos que atendem as
necessidades tecnologia da informação da organização. Atuando em um ambiente de
desenvolvimento global de software, a maior interação é com a matriz nos Estados
Unidos e com outras unidades de desenvolvimento de software localizadas na Índia e na
Rússia. A unidade foi avaliada no nível dois do SW-CMM em 2003 e utiliza o MSF
como base de seu framework de processos de desenvolvimento.
Esta unidade é coordenada por um diretor. Ele é o responsável pelo contato com
os diretores restantes do resto da organização. Abaixo do diretor existe um
departamento responsável pelo suporte administrativo e um consultor de recursos
humanos, a área de qualidade, coordenada pelo software engineering process group
(SEPG) e três gerentes de desenvolvimento.
A realização dos projetos de desenvolvimento ocorre da seguinte forma: existem
três áreas de desenvolvimento: corporativa, comercial e industrial. Os gerentes de cada
área são chamados de delivery managers (DM), responsáveis pela alocação dos
integrantes das equipes de projetos e responsável também pela gerência da equipe como
um todo. Os gerentes de desenvolvimento devem efetuar a negociação do início dos
projetos e o contato com os clientes contratantes do serviço. Os projetos possuem um
63
gerente de projeto, responsável pela gerência de projeto; analistas; desenvolvedores e
testadores.
No centro C existem, aproximadamente, 500 colaboradores atuando em projetos
que atendem as necessidades tecnologia da informação da organização. Servindo
principalmente as unidades localizadas no sudeste asiático. A unidade é certificada em
ISO 9001 desde 2001 e utiliza o MSF como base de seu framework de processos de
desenvolvimento.
O setor conta com um gerente sênior de desenvolvimento que é responsável pelo
setor. Existem 3 gerentes que estão subordinados a ele, responsáveis por áreas distintas:
suporte, desenvolvimento e manutenção. Estas 3 (três) áreas são de responsabilidade de
cada subgerente, que por sua vez, repassa informações e/ou problemas para o gerente
sênior.
4.1.2 Característica da Organização do Centro B
A organização matriz possui sede em Portugal e atua em mais de 50 países, com
mais de 100 mil colaboradores. O centro B possui, aproximadamente, 150
colaboradores que trabalham em projetos de TI. O relacionamento entre a unidade no
Brasil e a matriz segue os moldes de um relacionamento estilo cliente-fornecedor. A
matriz por sua vez, é encarregada de distribuir o software gerado pela unidade de
desenvolvimento aos clientes.
A unidade é coordenada por um diretor que faz o contato com outros diretores
da organização. Ela possui uma área responsável pela identificação de métricas e pela
definição de processos, abordando o SEPG e 1 gerente de desenvolvimento. A estrutura
organizacional possui similaridades com a organização americana, no entanto, possui
apenas uma 1 (um) gerente de desenvolvimento. Existe a superposição na estrutura
organizacional hierárquica e por projetos.
Este centro foi avaliado no nível 2 (dois) de maturidade de desenvolvimento de
software reconhecido pelo padrão Capability Maturity Model Integrated (CMMI) desde
2005 e utiliza o Rational Unified Process (RUP) como base do framework de processos.
64
4.1.3 Característica da Organização do Centro D
A organização possui sede em Cingapura e atua em mais de 12 países, com mais
de 10 mil colaboradores. A organização tem colaboradores trabalhando em projetos em
diversas organizações ao redor do mundo. No centro D existem, aproximadamente, 300
colaboradores que trabalham em projetos de TI. O relacionamento da matriz com as
unidades segue os moldes de um relacionamento estilo cliente-fornecedor. A matriz por
sua vez, é encarregada de distribuir o software gerado pela unidade de desenvolvimento
aos clientes.
As unidades são coordenadas por vice-presidentes e para cada continente existe
um vice-presidente sênior, que por sua vez, reporta-se para o presidente da organização.
As unidades possuem estrutura similar, compostas de uma área de SEPG, uma área de
gerência de projetos, tipicamente uma área de program management office (PMO) e
áreas de desenvolvimento específicas para o setor financeiro, marketing e de operações.
Existe a superposição na estrutura organizacional hierárquica e por projetos. Ela ainda
adota a estrutura tradicional orientada a projetos. Existe um pool de gerentes de projetos
e de analistas que são alocados para trabalharem em projetos de clientes da empresa.
Todas as unidades foram avaliadas no nível 5 (cinco) de maturidade de
desenvolvimento de software reconhecido pelo padrão CMMI desde 2003 e utilizam o
RUP e uma variância do eXtreme Programming (XP) como base de seu framework de
desenvolvimento de software.
4.2 Metodologia do Estudo de Caso
Baseado no contexto destas empresas de TI procurou-se organizar o método do
estudo de caso de maneira a englobar diversas áreas de cada organização. O estudo de
caso foi composto de 3 (três) etapas: elaboração, execução e análise de resultados. A
figura 14 apresenta as etapas.
65
Figura 14: Etapas do Estudo de Caso
Utilizou-se como instrumento de pesquisa um roteiro para uma entrevista semi-
estruturada, com questões abertas, fechadas e em escala lickert, caracterizando uma
pesquisa de natureza exploratória do tipo transeccional [YIN01].
A etapa 1 (E1) foi a de planejamento, onde foi desenvolvido o protocolo do
estudo de caso e o roteiro de entrevista. Para isto foram realizadas três atividades: A
atividade 1 (A1) foi composta de reuniões entre o pesquisador e professor orientador
para levantamento das questões e estruturação do roteiro; A atividade 2 (A2) consistiu
de validações de face e conteúdo do protocolo de estudo de caso, por 3 pesquisadores
seniores; A atividade 3 (A3) foi a realização do pré-teste, no qual foram entrevistados
alguns funcionários das unidades participantes. Os funcionários entrevistados não
participaram do estudo e suas entrevistas não foram consideradas durante a análise dos
resultados. Com base neste pré-teste foi possível executar os últimos ajustes no roteiro
de entrevistas. A versão final do protocolo de pesquisa contendo o roteiro de entrevistas
e descrevendo todos os procedimentos seguidos encontra-se no Apêndice A.
A etapa 2 (E2) foi a realização das entrevistas. Esta etapa seguiu os
procedimentos definidos durante a etapa anterior. Nas unidades localizadas no Brasil
foram realizadas dez entrevistas ao longo de 19 dias, respeitando-se a disponibilidade de
horários dos entrevistados. O período de realização das entrevistas teve início em 28 de
fevereiro de 2005 e estendeu-se até 18 de março de 2005. As entrevistas envolvendo os
diretores da organização foram gravadas em fita cassete e posteriormente digitalizadas e
armazenadas em mídia digital. Nas unidades localizadas na Ásia foram realizadas 6
entrevistas ao longo de 5 dias. O período de realização teve início em 1 de agosto e
terminou no dia 5 de agosto. As entrevistas envolveram gerentes de desenvolvimento e
de projeto.
E1: Planejamento
E2: Realização
das Entrevistas
E3: Análise de
Resultados
A1: Reuniões
A2: Validações
A3: Pré-teste
A1: Tabulação dos Dados
A2: Análise dos Conteúdos
A3: Geração do Relatório
66
A etapa 3 (E3), composta de 3 (três) atividades, consistiu de uma análise dos
resultados das entrevistas. Na atividade 1 (A1) foram tabulados os dados recolhidos das
entrevistas; Na atividade 2 (A2) estes dados foram analisados; E, finalmente, a atividade
3 (A3) foi a composição dos dados neste relatório.
Assim como apresentado no protocolo deste estudo de caso (Apêndice A), o
questionário foi dividido em 5 dimensões. As dimensões foram extraídas de estudos de
[EVA04a], na qual identificam características de ambientes de desenvolvimento global.
Cada dimensão é composta por categorias. As questões foram organizadas de acordo
com as categorias trabalhadas. Os participantes foram divididos em grupos, conforme o
papel que desempenhavam em suas organizações. Cada grupo de respondentes recebeu
um conjunto de questões. O relacionamento entre o grupo respondente e as questões
esta no Apêndice A.
4.3 Instrumento de Pesquisa
O instrumento de coleta de dados utilizado no estudo é um questionário
composto de cinco dimensões (Apêndice A). O objetivo foi o de identificar
características de organizações de DGS que atuem em ambientes offshore insourcing.
Este instrumento passou por validação de face e conteúdo por dois
pesquisadores. Com base nas considerações foram feitas realizadas alterações no
instrumento. Em seguida, foi conduzido o pré-teste com dois gerentes de projeto das
unidades A e B. Após estabelecimento da versão final do instrumento de coleta de
dados deu-se início às entrevistas.
Os entrevistados, durante o período previamente agendado, respondiam a
questões que abordavam aspectos sociais, organizacionais e técnicos, visando
caracterizar o DGS em ambientes offshore insourcing. Após a conclusão das entrevistas,
foi realizada a análise de resultados, relacionando os dados obtidos com a literatura
pesquisada.
A dimensão 1 (um) abrange os dados demográficos dos entrevistados, e possuem
categorias sobre o indivíduo, a escolaridade, o tempo de experiência e o seu
relacionamento com a empresa. A dimensão 2 (dois) aborda os aspectos organizacionais
e compreende as seguintes categorias: Referenciais Estratégicos, Recursos, Distribuição
das Operações, Estrutura Organizacional, Políticas, Avaliação e Infra-estrutura. A
dimensão 3 (três) abrange os aspectos sociais e compreende as seguintes categorias:
Comunicação, Cultura e Confiança. A dimensão 4 (quatro) abrange os aspectos técnicos
67
e compreende as seguintes categorias: Padrões, Gestão de Conhecimento, Projeto,
Metodologia de Desenvolvimento e Alocação de Recursos. Finalmente, a dimensão 5
(cinco) compreende questões gerias, de formato aberto, onde o entrevistado pode fazer
comentários que não foram abordados em nenhuma dimensão, que ele achasse
relevante. Esta organização visa facilitar a apresentação e análise dos resultados, não
alterando de forma alguma os procedimentos seguidos ou os resultados obtidos. A
relação das dimensões 2, 3 e 4 envolve a coleta de características sob os aspectos
abordados no capítulo anterior.
4.3.1 Caracterização dos Respondentes
Foram entrevistadas 15 pessoas, 5 do centro A, 5 do centro B, 3 do centro C e 2
do centro D. Participaram das entrevistas 5 gerentes de desenvolvimento, 3 diretores, 2
pontos focais da área de SEPG e 5 gerentes de projeto. O tempo médio de resposta foi
de 34 minutos (entre um mínimo de 15 minutos e um máximo de 60 minutos de
duração).
Os participantes inicialmente demonstraram receio em participar da pesquisa,
mas durante a condução do trabalho eles sentiam-se mais a vontade e faziam
comentários pertinentes em cada questão. Os entrevistados do centro C e D declinaram
a participação nas questões relacionadas ao levantamento demográfico. Desta forma, os
dados apresentados nesta seção, consideram apenas os centros A e B. As questões
referentes à dimensão demográfica estão no Apêndice A.
Os entrevistados possuem, no mínimo, 7,2 anos de experiência na área de
informática e, no máximo de 28 anos. O tempo médio é de 16,1 anos de experiência. A
média de idade dos entrevistados é de 36,5 anos, sendo a mínima de 25 anos e a máxima
de 48 anos. Os entrevistados possuem um tempo de atuação na unidade que variam de 8
meses a 6 anos. A tabela 8 apresenta a distribuição do tempo de experiência dos
entrevistados:
68
Tabela 8: Tempo de trabalho na unidade
Anos Nro de
pessoas
%
0-2 3 30
2-4 3 30
4-6 4 40
Com relação ao nível de formação, os respondentes possuem no mínimo o curso
superior completo. A predominância foi de respondentes com mestrado completo
(70%). Dos respondentes, 100% informaram que conhecem a estratégia de offshore
insourcing. Juntamente com a pergunta sobre o conhecimento desta estratégia,
procurou-se saber o tempo em que os respondentes estavam em contato com ela.
Destaca-se que 60% que responderam que conhecem a estratégia, possuem tempo de
contato idêntico ao tempo de experiência na unidade. Isto é, os respondentes só tiveram
contato com a estratégia de offshore insourcing na empresa. O tempo de contato com
empresas inseridas neste ambiente variou entre 0,25 e 4 anos, demonstrando que este
assunto ainda é muito recente. De maneira a organizar os dados apresentados, a tabela 9
apresenta as análises demográficas, separadas por unidade localizadas no Brasil.
Tabela 9: Análise da dimensão 1, nos centros A e B
Centro A Centro B
Min. Idade:
30 25
Max. Idade:
48 38
Média Idade:
40,2 32,2
Tempo Empresa.
Entre 0,25 a 4,5 anos Entre 2,5 a 6 anos
Escolaridade:
80% com Mestr. Completo 60% com Mestr. Completo
Conhecimento
sobre o tema
100% conhecem 100% conhecem
4.4 Análise de Dados
Uma das contribuições deste estudo está na identificação de características do
ambiente offshore insourcing e o relacionamento que pode ter sido traçado com a teoria
existente. A seguir apresentam-se os elementos de análise, bem como elementos e
observações identificados em cada uma das dimensões.
69
4.4.1 Aspectos Organizacionais
Conforme apresentado por [LAC01], a efetiva gerência de unidades de
desenvolvimento offshore depende do entendimento do negócio da organização por
parte dos gestores. Desta forma, procurou-se explorar e verificou-se o entendimento dos
diretores sobre a missão e o negócio da organização a qual prestavam o serviço.
Observou-se que a principal estratégia das organizações em criarem unidades
offshore insourcing esta relacionada com:
a) Redução de custos da matriz;
b) Aumento no foco de operação;
c) Contratação de profissionais globalmente.
As unidades de desenvolvimento possuem alguma dependência das
organizações. Sendo que as unidades não possuem nenhuma autonomia para captar
serviços de outras empresas sem a prévia autorização da matriz.
A criação de uma unidade offshore insourcing também esta relacionada com o
tamanho das organizações. Organizações com mais de 30 mil funcionários devem ter
seus serviços altamente especializados se quiserem ser competitivas [REP02]. A tabela
10 apresenta o tamanho da organização e das unidades analisadas.
Tabela 10: Número de pessoas envolvidas por organização
Centro A e C Centro B Centro D
Número de pessoas
trabalhando na
organização:
Mais de 40 mil Mais de 100
mil
Mais de 50 mil
Número de pessoas
trabalhando na unidade
estudada:
>250 >150 >200
Verificou-se que a organização matricial
4
[SIL01] é característica dos centros
estudados. Segundo os respondentes, elas facilitam a realocação de pessoas em projetos
de acordo com seus conhecimentos.
4
A característica da organização matricial é que tanto a estrutura do produto como a estrutura funcional
são implementadas simultaneamente. Existem duas estruturas de comando, o gerente do projeto e o
gerente da estrutura funcional.
70
Os centros estão hierarquicamente subordinados à matriz das empresas, que são
responsáveis pelos serviços executados. A existência desta subordinação foi explorada
por [CAR02] em seu estudo na concepção de um modelo de maturidade para
organizações offshore.
Existem funcionários de empresas terceiras trabalhando nos centros. Segundo os
respondentes, a existência destes visa resolver problemas de demanda de serviço
localizado. No entanto, a relação entre o número de terceiros é superior a 50% dentro da
unidade. Eles são utilizados como recursos de um projeto, mas pertencem à outra
estrutura funcional, terceirizada.
A relação entre o número de terceiros, tipos de projetos e tamanho são definidos
pela organização em conjunto com a unidade. Elas são controladas por métricas e são
apresentadas em um plano estratégico comum entre a unidade e a organização. Não é
comum a unidade ter um plano estratégico independente. Isto fica evidente e pode ser
comprovado pelas respostas, pelo tipo de relacionamento da organização com a
unidade.
Devido ao relacionamento, percebem-se diferentes graus de autonomia nos
centros. Quando novas decisões são tomadas elas precisam satisfazer uma série de
requisitos e atender estarem alinhadas perante as necessidades da organização.
Conforme estudos de [BOR03] fatores técnicos e culturais podem ter um alto impacto
devido a estas limitações. A limitação da infra-estrutura e usabilidade de ferramentas de
desenvolvimento é um exemplo típico que pode comprometer as necessidades da
unidade. Um trecho de uma das entrevistas procura reforçar esta conclusão:
“.em alguns projetos é importante que possamos definir as
ferramentas e plataformas de desenvolvimento que serão utilizadas.
Apesar da preocupação ma matriz em definir os padrões para nós, é
complicado quando tentamos utilizar ferramentas que não estão
definidas nestes padrões, mesmo com a comprovação que trazem um
benefício, em termos de produtividade, maior.”
Sendo uma unidade especializada, verifica-se que deveria haver mais autonomia
em termos de definições de ferramentas e plataformas de desenvolvimento por parte das
unidades. Percebeu-se um controle extremo da organização, pois se a unidade é
especializada, ela consegue identificar as melhores ferramentas para aumentar a
produtividade de seus desenvolvedores e testadores. No entanto, isto não deveria
71
ocorrer. Apesar de ter um alto grau de dependência da organização, a unidade participa
com freqüência da escolha de contratação de pessoal e definição de objetivos.
4.4.2 Aspectos Sociais
Os aspectos explorados pelo estudo de caso não são específicos de unidades de
desenvolvimento offshore insourcing. Eles foram explorados nos estudo de [EVA04a] e
[PRI03] em organizações offshore e de desenvolvimento global de software
respectivamente. De acordo com [WHI94] os aspectos sociais são fatores chaves para o
sucesso de uma organização de DGS. Os resultados obtidos não foram muito diferentes
do que se esperava. Em ambas as unidades, fatores críticos como a cultura, confiança e
comunicação são trabalhados semanalmente e ajustes nas métricas que os controlam são
efetuados a cada mês. Todos os participantes responderam as questões desta dimensão.
Foi observado que reuniões presenciais com o cliente ou equipes localizadas na
organização matriz também são comuns. Ainda que não seja freqüente para as unidades
localizadas no Brasil (centros A e B), verificou-se que isto traz um grande benefício em
termos de comunicação e confiança para as equipes que irão trabalharem juntas. As
empresas com sede na Ásia (centros C e D) compreendem que o levantamento de
requisitos e a equipe de suporte são os que mais se beneficiam deste tipo de interação.
Os respondentes do centro D informaram que desejariam que houvesse a interações
presenciais com mais freqüência, mas, devido a limitações de capital para estas
atividades, isto não acontece. Por este motivo, observa-se que o principal meio de
comunicação entre a empresa e as unidades é o e-mail. Em parte pelo tipo de trabalho
que esta empresa prove. Já no centro C, percebeu-se que o chat era a principal forma de
comunicação. Relacionou-se, a periodicidade de reuniões presenciais com a maior
utilização de uma ferramenta de comunicação dentro das empresas. O centro C, com
menor freqüência deste tipo de reuniões utiliza o chat com maior periodicidade, já o
centro D, utiliza o e-mail com maior periodicidade.
O trabalho de [CAR99] elucida as dificuldades de trabalhar com equipes
geograficamente dispersas e apresenta algumas soluções, adotadas pelas unidades. A
utilização de ferramentas de comunicação é freqüente nas unidades. No entanto,
verificou-se que não existe treinamento formal para utilizá-las, o que prejudica a
72
produtividade da unidade. Os meios de comunicação mais utilizados são (conforme
prioridade):
1) Correio Eletrônico;
2) Chat Eletrônico;
3) Telefone;
4) Correio de Voz/Áudio conferência
Novamente pode ser observada uma dependência da unidade em relação a sua
matriz. O código de conduta utilizado era o mesmo. Ainda assim, o diretor do centro A
informava que deveria ser possível a inserção de termos para tratar com questões legais
dentro da unidade, que não eram abordadas pelo código. Todos os respondentes
relacionaram a existência de destes manuais com a necessidade de capacitar e treinar o
funcionário para interagir com diversas culturas. Percebe-se que em 90% das situações,
os funcionários acreditam que o código de conduta contribui para ter um ambiente de
trabalho mais agradável de trabalho. Estes códigos de conduta e manuais servem como
pilares para treinamentos mais avançados sobre os objetivos da empresa. Percebeu-se
que eles servem para disseminar o conhecimento básico da empresa, bem como seus
valores.
Através de questões que analisaram a percepção dos respondentes, verificou-se a
importância dos centros em preservar a cultura do país que estão inseridas. É possível
traçar um relacionamento com esta observação e os estudos feito por [CAR99] e
[KAR98], onde se explorou questões de gerenciamento das diferenças culturais. Um
trecho retirado das entrevistas confirma a preocupação com a preservação da cultura
local:
“É importante que tenhamos a visibilidade da maneira como a nossa
matriz trabalha. Desta forma é possível que sincronizemos nosso
trabalho mais precisamente. No entanto temos a liberdade de lidar
com as diferenças locais de maneira saída, que contribua para o
desenvolvimento da unidade e da empresa”.
Verifica-se, através desta categoria, um primeiro indício de autonomia. As
organizações entendem que as unidades possuem o melhor conhecimento para lidar com
as diferenças culturais. A miscigenação da cultura da organização e da cultura existente
na unidade pôde ser observada. O seguinte trecho apresenta como uma diferença é
absorvida e tratada por um gerente de projeto:
73
“O brasileiro de forma geral não esta acostumado a trabalhar em um
ambiente constantemente sob medição (métricas). A empresa (matriz)
estimula a unidade a adotar controles rígidos sobre medidas”.
Ainda de acordo com [WHI94], o envolvimento dos funcionários com uma outra
cultura é fator motivador dentro de uma organização globalizada. Ainda que existam
barreiras como a língua para serem vencidas. Nos estudos de [KAR98] um perfil do
profissional de DGS foi traçado. A pesquisa apontou praticamente as mesmas
características do estudo, demonstrando que elas também estão presentes em
profissionais que trabalham em ambientes offshore insourcing. A lista a seguir foi
elaborada, de acordo com a freqüência de resposta:
1) Criatividade;
2) Flexibilidade;
3) Iniciativa;
Os respondentes afirmaram que os profissionais afetam o trabalho na matriz e
vice-versa. Este fator ocorre devido à interação que ocorre entre os membros da
unidade.
Em relação às unidades na Ásia, percebe-se que o ambiente de confiança é
construído através de interações múltiplas com seus clientes e fornecedores. Isto
também esta relacionado com o código de conduta existente nas empresas e com os
treinamentos constantes sobre trabalho entre equipes. Respondentes do centro D ainda
ressaltaram que a confiança é fortemente construída com as interações face-to-face que
são constantemente realizadas com seus clientes. Neste sentido, é possível traçar um
relacionamento entre a base de treinamentos, o código de conduta, e o tipo de reuniões
que são conduzidas com implicações diretas na confiança dos funcionários. Os
respondentes do centro C indicaram que a confiança existe, mas que poderia ser
trabalhada de maneira mais eficiente com a existência de teleconferências com seus
parceiros de outros países.
Não foi possível traçar um relacionamento entre a confiança existente nos
centros C e D e a existência de terceirizados. Os respondentes preocupam-se com a
qualidade do trabalho apresentado pelos terceirizados, mas isto não afeta a maneira
como o trabalho é conduzido. No entanto, nos centros A e B existe uma perda na
confiança perante a matriz quando o número de funcionários terceirizado atinge 2/3 do
tamanho da unidade.
74
Um relacionamento de confiança interessante pode ser observado entre os níveis
gerenciais. Os respondentes do centro C demonstraram uma integração muito grande ao
explicarem a maneira como trabalham. Os gerentes estão constantemente conversando
sobre prioridades e o impacto de projetos no cronograma do setor. Com uma interação
tão acentuada, e a maneira de trabalho uniformizada, o aumento da confiança é
facilmente identificado nesta situação. Diferentemente, no centro D, os funcionários
acreditam que é possível trabalhar de maneira confiável estando fisicamente distribuído.
Apesar deste comentário, isto não foi observado como um relacionamento positivo.
Como evidência, destaca-se a presença física de ambos entrevistados na participação de
um projeto localizado no centro C, por tempo indeterminado.
Um fator importante ainda a ser observado refere-se à utilização de funcionários
terceirizados. Uma média de 87% dos respondentes dos centros A e B identificaram a
utilização de funcionários terceirizados pode comprometer as atividades da unidade
devido a seu nível de comprometimento. Segundo os respondentes eles não teriam o
mesmo “espírito de equipe” de um funcionário com vínculo direto com a unidade.
Diversos trabalhos já foram feitos para relacionar os funcionários terceirizados e os não
terceirizados em unidades de desenvolvimento de software ([KHA03a] e [LAC01]).
Observa-se, portanto, que o controle exercido sobre o número de funcionários
terceirizados esta, também relacionado, com o nível de comunicação dentro da unidade.
Este controle sobre o tipo de comprometimento dos funcionários tem reflexo
diretamente na confiança que a matriz tem no trabalho da unidade. Para todos os
respondentes, modelos de qualidade, como o SW-CMM e o CMMI são fundamentais
para alterar a o nível de confiança da matriz na unidade.
Verificou-se também a dificuldade de conservar uma relação de confiança com
as equipes globais, visto que a distância e a comunicação acabavam criando uma força
contrária na unidade. Em [LOP03] esta relação também é explorada.
75
4.4.3 Aspectos Técnicos
Os aspectos técnicos estão relacionados na maneira como o trabalho é conduzido
na unidade e quais os procedimentos, ferramentas e processos envolvidos na construção
do software. A relação entre a autonomia da unidade em relação à matriz também pode
ser analisada. É comum a existência de padronização nas unidades. Isto esta relacionado
com o forte relacionamento que elas possuem com suas matrizes. Este relacionamento
mostrou-se ser prejudicial para a produtividade da unidade. A necessidade de poder
utilizar outros padrões fica muito comprometida.
Esta capacidade de gerenciar projetos esta relacionada com a existência de
certificados de qualidade. Em ambas as organizações, que possuem ISO 9001,
observou-se que quanto maior a adoção de padrões e procedimentos, maior a
escalabilidade da unidade em gerenciar projetos. Apesar de não ter sido possível
analisar evidências anteriores à aquisição dos certificados de qualidade, os respondentes
afirmam que era difícil gerenciar os projetos sem a existência de padrões de qualidade.
Observa-se que além de um argumento que reforce a confiança da matriz na
unidade eles também provêm conhecimento para a elaboração de processos e
procedimentos utilizados na construção dos produtos. Assim como enumerado por
[CAR02] e [SIL01] a existência de padrões são determinantes para o gerenciamento de
uma unidade de software offshore. Estes padrões, alavancados por uma busca de
certificados de qualidade, auxiliam as unidades a se organizarem. Contudo, cabe
ressaltar que a obtenção de selos de qualidade para fins meramente comprobatórios
pode deturpar a real aplicabilidade e benefício que os modelos de qualidade podem
agregar. Isto pode ser comprovado em uma das entrevistas, de um dos gerentes de
projeto, conforme demonstrada abaixo:
“Buscamos certificados de qualidade para demonstrar nosso know-
how para a matriz. É uma forma de mostrarmos que sabemos como
deve ser feito o trabalho. Mesmo não aplicado inteiramente coloca-se
a equipe em contato com diferentes formas de se trabalhar, ainda que
não seja muito produtiva”.
É importante ter a visibilidade clara quanto à utilização de modelos como o SW-
CMM e o CMMI. Em [NOL95] modelos de maturidade evolucionários, como os citados
neste parágrafo, são amplamente criticados devido a sua verificabilidade não ser
76
precisa. Ele enumera as conseqüências de se adotar modelos de qualidade apenas para
fins ilustrativos.
Conforme apresentado por ([PRI03], [EVA03] e [AUD01]), a gestão do
conhecimento é um fator fundamental que deve estar presente em áreas de
desenvolvimento de software. Procurou-se explorar como a gestão do conhecimento é
conduzida nas unidades offshore insourcing. Apesar de 70% dos entrevistados saberem
o que é a gerencia de conhecimento, constatou-se que ela não é aplicada na prática
nestas unidades.
Influenciado pelos padrões de qualidade, as organizações adotaram mecanismos
para gerenciar e compartilhar o conhecimento. No entanto, observou-se que o
compartilhamento do conhecimento não é feito de maneira eficaz entre as equipes de
projetos. Erros são repetidos e informações estão redundantes na base de dados. O
centro C apresentou maiores problemas em utilizar a base de conhecimento. A maioria
dos respondentes afirmou que não é comum para os gerentes de projeto ter humildade
em procurarem informações semelhantes em projetos passados. Desta forma foi
possível traçar um relacionamento entre a utilização da base de conhecimento, a cultura
e os padrões na organização. A cultura do centro C, altamente coletiva, apresentou
problemas em utilizar informações existentes, pois acreditavam que não cometeriam
erros já identificados no passado. Segundo eles, com o auxílio dos padrões, não teriam
problemas para seguir os procedimentos e realizar seu trabalho com eficiência. Os
padrões, mesmo, com o objetivo de aumentar a produtividade, não conseguem se
sobrepor à cultura dos executores do processo.
O centro D apresentou uma melhor usabilidade de sua base de conhecimento. Os
respondentes informaram que a base de conhecimento é usada como uma base de
métricas que efetuam indexações e mostram os melhores projetos já realizados e o que
eles fizeram para serem os melhores. A incidência de erros repetidos em projetos
diferentes é relativamente menor do que os identificados nos projetos de outras
empresas, nos centros A, B e C. Novamente é possível traçar o relacionamento da
cultura com a correta adoção de uma base de gerencia de conhecimento. Neste caso, a
cultura do centro C, mais individualista, acredita que se devem procurar os erros em
projetos anteriores para que estes não se repitam nos novos projetos.
Existem diversas dúvidas presentes quanto à adoção de ferramentas e processos
que auxiliem a troca de experiências e gestão de conhecimento. A relação de retorno
sobre o investimento é a principal delas. Os gerentes de desenvolvimento têm
77
trabalhado esta prática com cautela, pois informam não terem precisão de comprovar se
é produtiva.
A metodologia de desenvolvimento é o fator principal analisado nas unidades.
Ela envolve categorias como os métodos de desenvolvimento utilizados e os processos
para a construção de software (dentre eles a gerencia de requisito, a gerencia de
configuração e as práticas de desenvolvimento). As unidades efetuam a manutenção de
aplicativos e o desenvolvimento de novas soluções.
Observa-se que a matriz inicialmente estabeleceu as unidades com o objetivo de
prestarem manutenção nos sistemas já existentes. Com o passar do tempo, as unidades
foram aumentando o escopo e demonstrando capacidade para absorver projetos mais
complexos. Desta forma, projetos de novas soluções são feitos pelas unidades. Isto é
uma característica comum em unidades de desenvolvimento global de software em
ambientes offshore insourcing. Conforme os estudos de [CAR02] na concepção de seu
modelo de maturidade para organizações offshore, este é o primeiro estágio de uma
interação entre a unidade e a matriz. Onde a manutenção de soluções e o baixo custo são
as principais forças atuantes.
Com algumas variações, percebe-se que o desenvolvimento é bem estruturado e
segue um plano rigoroso de atividades. Os modelos de desenvolvimento MSF, com
pequenas variações na fase de Envisioning e Stabilizing são utilizados pelos centros A e
C. No centro B, o desenvolvimento esta baseado no RUP, com pequenas variações na
fase de elicitação de requisitos e de teste. Métodos como XP não são encorajados pelos
gerentes aos desenvolvedores.
Assim como nos centros A e B, os centros C e D alinharam os padrões de
qualidades existentes na organização e o processo de desenvolvimento de sistemas. O
centro C utiliza o MSF. Este padrão, utilizado pela organização no mundo todo, é a base
para a construção de novos projetos e pela constante manutenção de sistemas legados
existentes na empresa. O centro D utiliza outro padrão para seu desenvolvimento,
baseado no RUP. Diferente do centro C existe uma preocupação em entender o processo
de desenvolvimento de seus clientes, pois isto facilita a integração de módulos que
foram desenvolvidos entre diferentes filais.
O centro C não possui autonomia na escolha dos projetos que serão realizados,
diferente do centro D. Evidentemente, isto esta relacionado com a característica das
empresas. O centro D tem a estrutura de uma consultoria de sistemas, enquanto que o
centro C possui a estrutura de um setor especializado de TI.
78
A integração dos processos de desenvolvimento utilizado no centro C é um fator
crítico para o sucesso dos projetos. Isto esta conectada a estrutura do setor. Caso um dos
gerentes se ausente ou não possa trabalhar, a operação do setor fica prejudicada.
Observa-se que este alinhamento entre o processo de desenvolvimento acabou sendo
“moldado” para funcionar com a estrutura existente. Não houve uma reflexão sobre a
eficácia desta abordagem de desenvolvimento. Quando as equipes da empresa
interagem com outras dispersas globalmente, isto se torna mais evidente. O processo
atual não suporta interações deste tipo.
O centro D possui uma maior flexibilidade na estrutura organizacional e em seu
processo de desenvolvimento. Como eles estão desconectados não dependem de
pessoas, a flexibilidade torna-se uma característica chave para a organização. O
processo não se torna um fator chave, mas sua execução e a interação com os outros
elementos – pessoas e estruturas, sim. O mesmo relacionamento pode ser observado em
relação às técnicas e ferramentas utilizadas. A empresa possui uma maior autonomia
para escolher e definir os métodos e ferramentas que serão utilizadas.
É importante ressaltar que esta autonomia na escolha de projetos é mais um fator
de maturidade organizacional, conforme o trabalho de [BOR03], onde a unidade
participa ativamente da escolha dos projetos. Atualmente isto não é uma prática comum
nas unidades.
As empresas são novamente beneficiadas pela adoção de padrões quando tratam
de alocar seus recursos. Existem processos para alocação de recursos, onde existe a
participação da unidade offshore também ocorre. O centro D possui um sistema que
identifica recursos com características específicas e sugere a elaboração de equipes
baseados na melhor combinação possível. Como apresentado por [CAR99], a
elaboração de equipes, mesmo globalmente, é uma atividade crítica para o projeto,
devendo estar bem alinhada com as necessidades do mesmo. Mesmo possuindo um
processo definido, percebe-se que o grau de autonomia do centro C é um delimitador
para a alocação de recursos. A movimentação dos recursos deve ser aprovada pelo
gerente sênior da área, que deve estar em sincronia com as necessidades de outras filiais
na Ásia. Isto não ocorre no centro D.
Mesmo assim, o nível de integração dentro do projeto é maior no centro C. Os
recursos alocados interagem de maneira mais conexa. Os funcionários do centro D são
muitas vezes afastados de suas culturas para atender uma necessidade de projeto. Em
79
algumas situações, citadas pelos respondentes, isto foi um elemento de falta de
motivação para os membros da equipe de projeto.
A falta de autonomia na alocação dos recursos deve-se ao controle que a matriz
deseja ter sobre os projetos da unidade. Este controle é feito por intermédio dos projetos
que são enviados para as unidades pelas matrizes.
4.4.4 Questões Gerais
As questões gerais abrangeram a última dimensão abordada no estudo.
Procurou-se traçar um relacionamento entre as observações de cada respondente e as
dimensões da pesquisa. Quando perguntado sobre as vantagens da existência de uma
unidade de desenvolvimento offshore insourcing, os respondentes dos centros
enumeraram as principais vantagens e desvantagens. A tabela 11 apresenta estes
resultados tabulados de acordo com a maior freqüência.
A percepção dos respondentes coincide com o objetivo da matriz, na redução de
custos e de especialização. Conforme apresentado por [CAR02] e [MOR03], prestar
serviços de desenvolvimento offshore não e uma tarefa simples. Isto pode ser
comprovado na seguinte transcrição de um gerente de desenvolvimento:
“...vender serviço de offshore é complicado. A empresa não tem a
visão de shared services para o desenvolvimento global. Ou seja,
muitas vezes nem ela sabe o que deve ser feito em relação ao produto
fina. Isto é um cuidado que a unidade deve ter, e avisar a matriz.”
A segmentação do trabalho em camadas e a flexibilidade (em temos de processo,
relacionamento e atendimento) foram citadas pelos diretores dos centros como as
principais vantagens da abordagem offshore insourcing. Contudo, foi observado que as
unidades são limitadas em termos de tomada de decisão. A matriz espera que isto
aconteça. A transcrição abaixo também demonstra esta relação.
“..autonomia é contra producente pois a matriz pode ir para uma
direção e a unidade para outra. No mesmo sentido a perda de
autonomia pode estar vinculada somente à padronização. A
existência de uma definição centralizada auxilia em aspectos que não
são o core-business da unidade, como por exemplo, os custos
organizacionais, a gerencia e o controle sobre a infra-estrutura. É
80
claro que perde-se um pouco a flexibilidade, mas é uma relação que
deve ser muito bem balanceada para que ambos os lados saiam
ganhando.”
Tabela 11: Vantagens e desvantagens de ambientes offshore insourcing segundo os
participantes
V
antagens Desvantagens
Centro A
1 Foco em desenvolvimento;
2 Baixo custo;
3 Sinergia com outras áreas da
corporação;
1 Distância do cliente final;
2 Limitação na tomada de decisão;
3 Ferramentas de auxílio a
comunicação podem se tornar
complicadores;
4 Aumento do overhead
(comunicação);
5 Geração de ansiedade na matriz;
Centro B
1 Foco no desenvolvimento de soluções;
2 Baixo custo;
3 Capacidade técnica global;
1 Distância do cliente final;
2 Falta de autonomia para atividades;
3 Problemas de comunicação;
4 Problemas de diferenças culturais;
Centro C
1 Aumento da troca de conhecimento
sobre aplicações;
2 Interação com outras culturas;
3 Adoção de um mesmo processo de
desenvolvimento de software;
4 Utilizar recursos virtualmente ilimitados
nos projetos;
1 Comunicação;
2 Falta de acesso ao código fonte;
3 Gerenciamento de equipe;
Centro D
1 Aumento da especialização de
conhecimento de aplicação;
2 Aumento da escalabilidade de
operações;
1 Comunicação;
2 Gerenciamento de equipe;
O relacionamento entre autonomia de serviços da unidade é muito explorado,
principalmente em relacionamentos do tipo offshore outsourcing.
Os diretores das unidades ainda comentário sobre a decisão da matriz em não
utilizar a estratégia de offshore outsourcing. Aqui, pode-se enumerara algumas
desvantagens desta abordagem, apresentando apenas resultados pontuais, sem esgotá-la,
conforme dito por um diretor.
“Terceirizar pode ser repassar o problema para alguém, sem
entender o que significa isto. Porque outra organização teria uma
margem de lucro em cima de algo que pode não fazer tão bem quanto
a própria unidade? Terceirizar neste sentido pode ser abrir mão do
controle. Como a área de tecnologia da informação é considerada
81
como um diferencial estratégico pela matriz, ela não foi totalmente
terceirizada. A terceirização é muito empregada para atender a
sasonilidade de trabalho existente nos projetos de desenvolvimento, e
apenas isso”.
É interessante este tipo de análise, principalmente se for considerado outras
soluções ao invés da escolha do offshore insourcing. A relação entre falta de controle
com a terceirização também foi relacionada nos trabalhos de ([KHA03a] e [KIS03]).
Os respondentes do centro C informaram que o aumento da troca de
conhecimento sobre aplicações, bem como a disseminação deste, ocorre de uma
maneira mais homogênea. Os funcionários do centro D acreditam que a unidade de
desenvolvimento de software offshore pode ser uma unidade altamente especializada de
conhecimento de aplicação. Não estando relacionada unicamente com o
desenvolvimento.
Tipicamente, este tipo de relacionamento ocorre em níveis mais elevados de
maturidade, conforme estudos de [CAR02]. Como o centro D também é uma empresa
de consultoria, é normal que eles acreditem que as unidades de desenvolvimento
possam estar neste estágio de relacionamento. Uma das outras vantagem citadas, é a alta
escalabilidade que uma unidade pode prover. Trabalhando com unidades espalhadas em
fusos horários estratégicos, é possível aumentar o fluxo de trabalho, sem aumentar o
número de funcionários. Este item relaciona-se com as dimensões sociais, uma vez que
a interação entre as unidades e a matriz deve estar ocorrendo de maneira constante, com
uma cooperação e confiança que permita este tipo de trabalho. O aumento da
especialização da atividade de desenvolvimento e a interação com outras culturas
também foram vantagens citadas pelos entrevistados. O primeiro é diretamente
relacionado com os aspectos técnicos. A capacidade de manter o foco no
desenvolvimento possibilita a unidade um maior entendimento da necessidade do
negócio, uma vez que não precisa envolver-se com problemas de outras áreas da
empresa [REP02]. A interação com outras culturas esta conectada com as dimensões
sociais, onde a existência de diferenças culturais promove a discussão entre as equipes
globais.
A comunicação foi apontada como a principal desvantagem. Mesmo com
interações face-to-face, encontra-se grande dificuldade na resolução de problemas e
ambigüidades entre requisitos.
82
Apesar destes problemas, os gestores do centro D acreditam na utilização de
unidades de desenvolvimento offshore. Segundo eles, a relação entre custo-benefício
(vantagens/desvantagens) justifica, para a empresa, a adoção desta estratégia.
O centro C apresentou características vantajosas para a existência de unidades de
desenvolvimento offshore. A principal delas esta na adoção de um mesmo processo de
desenvolvimento de software. Isto esta relacionado com os aspectos técnicos, onde é
abordados fatores chaves para a melhor utilização destes processos, como a existência
de certificados de qualidade e da existência de técnicas de coordenação entre os times.
Desta forma, observou-se que o controle dos processos pode ser realizado de maneira
mais eficiente, pois isto fica de responsabilidade da unidade.
Alguns respondentes afirmaram que a possibilidade de utilizar recursos
virtualmente ilimitados nos projetos é uma vantagem destas unidades. Alguns gerentes
de projeto esta percepção – de utilizar um número indefinido de recursos. Este aumento
foi apontado por um dos gerentes de suporte. Ele acredita que o número de funcionários
prestando suporte deva ser maior do que o número de funcionário que desenvolveram o
software. Esta limitação ocorre pela empresa contratante, pois ela não tem condições de
liberar capital de forma a terminar o projeto com um número de recursos tão elevado.
Apesar de ter sido apontado pelos respondentes, esta característica não foi abordada
neste estudo.
Entre as desvantagens apontadas estão de que algumas equipes não possuem
acesso ao código fonte e não podem prestar suporte de primeiro nível, que impacta
diretamente o cliente final. Neste sentido não é possível realizar nenhuma atividade sem
o auxílio do pessoal de desenvolvimento. Neste contexto, entende-se que a unidade
offshore devesse possuir uma área especializada em suporte de aplicações desenvolvidas
pelo centro. Problemas de gerenciamento da equipe também foram identificados nos
centro C e D. Alguns gerentes ainda apontaram os problemas de comunicação existentes
entre unidades. Apesar de não serem muitos, percebeu-se uma tendência em ultrapassar
estas barreiras através de treinamentos.
Conforme [CAR02], a unidade offshore inicialmente atua como sendo uma
extensão da matriz (staff augmentation), onde os recursos são alocados pela matriz, de
acordo com as necessidades do projeto. No último estágio, observa-se uma autonomia
da unidade e um valor agregado da unidade no negócio da matriz, contribuindo
diretamente na operação da empresa em seu core-business.
83
4.5 Considerações sobre o Estudo de Caso
A principal contribuição deste estudo está na identificação de características do
ambiente offshore insourcing. Observa-se que as vantagens e desvantagens apontadas
pelos respondentes auxiliam na interpretação dos dados coletados.
Através da análise de conteúdo das entrevistas realizadas durante os estudos
obtiveram-se informações relevantes quanto a aspectos organizacionais, sociais e
técnicos. Além das categorias identificadas durante a análise de cada elemento de
estudo, obteve-se uma visão geral destes elementos nas unidades analisadas. A tabela
completa com todas as características esta no Apêndice B.
Um ponto interessante a ser analisado é que a atividade de sub-contratação
software, no formato de pacotes de projetos, não é adotada por nenhuma das unidades.
Isto vai de encontro com uma das áreas chaves do SW-CMM, onde deve existir uma
definição para a sub-contratação de software [SEI02]. Neste sentido pode-se observar
que o modelo SW-CMM não será aplicado em sua totalidade em uma organização deste
tipo.
Da mesma forma, o autor em ([MOR03] e [CAR02]) ressalta a importância de
iniciar um trabalho de manutenção de software nas unidades offshore, e, logo depois,
partir para um escopo maior das unidades. Isto pode ser verificado através deste mesmo
estudo. Assim como foi claramente identificado um grau de relacionamento entre a
unidade e a matriz, em todas as dimensões, existe um nível de autonomia de
dependência entre as unidades e suas matrizes.
As unidades da organização com sede nos Estados Unidos (centros A e C) são
consideradas como um departamento. Já a unidade da organização com sede em
Portugal (centro B) e a com sede em Cingapura (centro D) são consideradas empresas
diferentes, perante a matriz. Este tipo de relacionamento caracteriza uma diferença que
se reflete na autonomia das unidades. Devido a este fator, verificou-se que os centros B
e D possuem uma autonomia um pouco maior (ainda que pequena) quando comparada
às outras unidades, principalmente no processo de tomada de decisão.
A separação de características que respeitassem estas dimensões e fatores
demonstrou-se de bastante abrangência. Principalmente as que se referiam aos aspectos
organizacionais. Mesmo com a necessidade de padronizar e prover assistência para as
unidades, os aspectos técnicos demonstraram ser um aspecto secundário. A real
necessidade ainda esta em alinhar os entendimentos da cultura e da confiança
84
organizacional globalmente entre a matriz e suas unidades. Trabalhos estão sendo
realizados em ambas as empresas para alinhar técnicas e melhor aproveitar os recursos
que certificados de qualidade provem.
Com a análise das características, sobre o desenvolvimento global de software
em ambientes offshore insourcing, foi possível coletar uma lista de lições aprendidas.
Estas lições foram coletadas a partir da análise do resultado do estudo de caso. A tabela
12 apresenta uma lista destas lições, apresentando também em qual centro foi
identificada e a teoria.
Tabela 12: Lições aprendidas dos centros estudados e teoria
Id. Lição Aprendida Identificada
no(s) centro(s)
Teoria
Relacionada
#1 As características dos centros de desenvolvimento
global de software em ambientes offshore
insourcing podem ser agrupados em
características técnicas, sociais e organizacionais.
A,B,C e D [EVA04a]
[LOH02]
#2 Exite uma relação entre o grau de autonomia entre
as unidades e as matrizes. Esta autonomia foi
classificada como forte, média e baixa. A baixa
autonomia prejudica a tomada de decisão da
unidade.
A,B,C e D [BOR03]
[CAR99]
#3 Manutenção de aplicações é o primeiro estágio de
maturidade das unidades.
A, B e D [CAR02]
#4 Modelos de qualidade auxiliam a
institucionalização de processos e procedimentos
A,B,C e D [KHA03b]
[SEI02]
[SEI95]
#5 Aspectos socias devem ser tratados como
prioridade. Os aspectos técnios são secundarios.
B, e D [KAR98]
[WHI94]
#6 A confiança da matriz em relação a unidade é
afetada quando o número de funcionários
terceirizados atinge 2/3 do tamanho da unidade.
A e C [MOR03]
[LAC01]
Lição Aprendida #1: As características dos centros de desenvolvimento global
de software em ambientes offshore insourcing puderam ser agrupadas conforme o
estudo apresentado em ([EVA04a] e [LOH02]). A divisão destas características facilitou
a organização e serviu para compor também a estrutura do modelo de maturidade
apresentado no capítulo 6.
85
Lição Aprendida #2: O grau de autonomia foi observado em todas as
dimensões analisadas. Este grau foi dividido em alto, médio e baixo e demonstrou ser
um fator crítico na tomada de decisão dos centros. Apresentado em trabalhos de
([BOR03] e [CAR99]) ele procura ser um elemento de análise dos centros, de modo que
possam ser comparados graus de autonomia entre diferentes centros.
Lição Aprendida #3: A manutenção de sistemas foi identificada como sendo a
principal atividade dos centros. Assim como apontado em [CAR02], este é o primeiro
estágio da maturidade de um centro offshore. Este comportamento foi verificado por
este estudo.
Lição Aprendida #4: Os modelos de qualidade são importantes, pois definem
como os processos serão estruturados [SEI95]. Porém, identificou-se uma outra
vantagem na adoção destes modelos. Eles servem como facilitadores para que a
institucionalização ocorra de maneira mais rápida. Processos e iniciativas que não façam
parte dos modelos conseguem ser implantadas mais rapidamente se seguirem o mesmo
processo de institucionalização dos modelos.
Lição Aprendida #5: Problemas de confiança e de comunicação são conhecidos
no ambiente de desenvolvimento global de software. No entanto, pode-se avaliar no
estudo o tamanho do impacto deste problema. Percebeu-ser que eles comprometem os
aspectos técnicos (secundários). Este relacionamento é explorado em [KAR98] e, de
maneira genérica em [WHI94].
Lição Aprendida #6: Em [MOR03] explora-se alguns tipos de relacionamento
entre as organizações matrizes e seus centros de desenvolvimento. Assim como a
confiança é reduzida com um número maior de funcionários terceirizados, o tipo de
relacionamento pode ser classificado de outra forma, passando a ser de offshore
outsourcing. A estratégia deste tipo de desenvolvimento é diferente do desejado pela
matriz.
A possibilidade de trabalhar com fusos horários diferentes e permitir a execução
mais flexível do trabalho esta relacionada com os itens apresentados. A alta
especialização da unidade offshore demonstrou ser um fator considerável, pois evita que
a empresa matriz sobrecarregue-se com atividades que não estão diretamente
relacionadas com seu core-business.
Apesar de favoráveis em relação a operações de unidades offshore, os
respondentes do centro C demonstraram-se favoráveis à utilização da atual estrutura de
gerência existente. Isto compreende três gerentes, para as áreas de suporte,
86
desenvolvimento e manutenção, na qual estariam interagindo constantemente. O
problema existe em como replicar esta mesma abordagem para equipes globais, onde a
mesma estrutura pode existir em centros distribuídos.
O estudo realizado permitiu identificar as características apresentadas por
autores clássicos da bibliografia. No entanto, o relacionamento traçado em relação à
teoria esteve sempre restrito ao desenvolvimento offshore, e não ao seu tipo específico
aqui estudado. Devido a esta limitação, torno-se difícil efetuar um quadro inteiramente
único de características singulares presentes em organizações insourcing. As
características apresentadas são dos componentes offshore e insourcing. Tratá-los
separadamente pode comprometer os resultados. Mesmo com a ampla pesquisa
bibliográfica realizada, não foram encontradas na literatura contribuições relevantes que
permitam mapear de forma eficaz as características destas organizações e como
estruturar o trabalho para que elas sejam mais produtivas. As contribuições deste estudo
visam justamente suprir esta carência. Apresentando novos elementos de pesquisa que
podem ser validados e verificados no futuro.
87
5. Estrutura das Características de Ambientes Offshore
Insourcing
Neste capítulo, é apresentada a estrutura das características do desenvolvimento
global de software em ambientes offshore insourcing que serviu de base para agrupar
categorias e compor os aspectos (dimensões) de análise. Como não foi encontrada
literatura sobre as características deste tipo de ambiente, procurou-se relacioná-lo com
estudos similares. Desta forma, utilizaram-se observações de autores que investigaram o
DGS, partindo assim, de um conjunto inicial de aspectos. Estes aspectos foram os
mesmos que direcionaram os estudos de caso. Segundo [MOR03], o desenvolvimento
offshore é um tipo de desenvolvimento global de software, por este motivo, os fatores
utilizados serão os mesmo apontados por autores clássicos do tema ([EVA04a],
[PRI03], [LOH02] e [CAR02]). O relacionamento destes aspectos, bem como suas
categorias esta representado na figura 15.
Característica do DGS em
ambientes Offshore Insourcing
Aspectos
Técnicos
A
spectos
Organizacionais
Aspectos
Sociais
Comunica
ç
ão
Cultura
Confian
ç
a
Pro
j
eto de
Desenvolvimento
Gestão de
Conhecimento
A
loca
ç
ão de
Recursos em
Projeto
Metodolo
g
ia de
Desenvolvimento
Recursos
Distribuição das
Operações
Estrutura
Organizacional
Políticas
A
valia
ç
ão
Infra-estrutura
Padrões
Referenciais
Estratégicos
Figura 15: Dimensões e Categorias
88
Na análise foram identificadas as dimensões de aspectos sociais, técnicos e
organizacionais. Em cada uma destas dimensões, foram agrupadas as categorias. Este
agrupamento foi modificado de acordo com as observações realizadas nos estudos de
caso. Inicialmente percebeu-ser a falta de categorias para compor os aspectos
organizacionais, desta forma, buscou-se em [EVA03] a contribuição no relacionamento
da dimensão organizacional e os projetos de desenvolvimento globais. Devido a este
relacionamento, seu estudo foi utilizado para compor as categorias desta dimensão. Elas
serviram de base para agrupar os resultados do estudo de caso.
5.1 Aspectos Técnicos
Os aspectos técnicos estão relacionados com o método de trabalho da unidade e
os procedimentos, ferramentas e processos envolvidos na construção do software. Desta
forma, a tabela 13 apresenta as categorias que foram abordadas nos aspectos técnicos,
bem como a teoria base de cada categoria.
Tabela 13: Categorias dos aspectos técnicos
Aspecto Categorias Teoria
Padrões [EVA03]
[YEO01]
Gestão de Conhecimento [EVA03]
Projeto de Desenvolvimento [YEO01]
Metodologia de Desenvolvimento
Técnico
Alocação de Recursos em Projetos
[PRI03]
A existência de padrões tende a ser comum neste tipo de ambiente. A adoção de
modelos de qualidade auxilia na definição de padrões e planos mais consistentes
[PAU95], desta forma, o centro offshore reforça a confiança da matriz. Assim como
enumerado por [CAR02] e [LAC01] a existência de padrões são determinantes para o
gerenciamento de uma unidade de software offshore. Estes padrões, alavancados por
uma busca de certificados de qualidade, auxiliam as unidades a se organizarem.
Contudo, cabe ressaltar que a obtenção de selos de qualidade para fins meramente
comprobatórios pode deturpar a aplicabilidade e benefício que os modelos de qualidade
podem agregar.
89
Assim como apresentado por [EVA03], a gestão do conhecimento em projetos
offshore é fator crítico de sucesso. Torna-se necessário que a organização tenha
agilidade na resolução de um problema. Isto pode só pode ser atingido quando existe
uma cooperação entre os participantes da organização na tentativa de enumerar e
apresentar os problemas e soluções já encontradas.
O projeto de desenvolvimento do produto foi uma categoria identificada por
agrupar todo o processo de desenvolvimento [YEO01]. Além disso, questões como a
gerência de configuração, o planejamento e o controle de qualidade estão no escopo
desta dimensão.
A metodologia de desenvolvimento aborda como os métodos de
desenvolvimento utilizados e os processos para a construção de software (dentre eles as
utilizadas no projeto do software) são organizados. Esta categoria é amplamente
utilizada para avaliar métodos de trabalho no DGS e foi abordada em [PRI03].
A alocação de recursos em projetos é um fator crítico, principalmente quando
existe a possibilidade de trabalhar com pessoas que estão dispersas geograficamente
[PRI03]. A utilização de um processo de alocação, que compreenda as qualificações de
um recurso, bem como o tempo que ele estará disponível para ser alocado em um outro
projeto, soa fundamentais para o sucesso do trabalho.
5.2 Aspectos Sociais
De acordo com [WHI94] os aspectos sociais são fatores chaves para uma
organização de desenvolvimento global. Problemas relacionados com a comunicação,
confiança e cultura atingem proporções maiores quando a equipe esta dispersa. A tabela
14 apresenta as categorias agrupadas nos aspectos sociais.
Tabela 14: Categorias dos aspectos sociais
Aspecto Categorias Teoria
Comunicação
Confiança
Social
Cultura
[CAR99]
[SAB99]
[WHI94]
A comunicação, cultura e confiança são fatores sociais que estão presentes em
qualquer tipo de projeto de desenvolvimento global de software [CAR99]. No entanto,
90
em [CAR99], o relacionamento entre estes fatores e o DGS é abordado mais
profundamente. O trabalho de [SAB99] focam na relação da confiança e do aumento da
produtividade em projetos de desenvolvimento. Em [WHI94] são apresentados fatores
motivacionais que aumentam a confiança das pessoas na execução das tarefas,
independente do tipo de projeto ou atividade.
A comunicação refere-se à troca de informação que ocorre entre os membros do
time, bem como a maneira como este troca acontece. Isto envolve as ferramentas
utilizadas, os procedimentos seguidos e toda a ambigüidade existente durante o processo
de troca de informação. Nos projetos de desenvolvimento global, é comum que as
equipes adotarem uma língua única para se comunicarem, estes jargões também são
utilizados na matriz [CAR99].
A cultura esta diretamente relacionada com o comportamento dos indivíduos,
suas crenças, premissas e a percepção de suas atividades no seu ambiente [CAR99]. A
diversidade cultural em organizações globais pode comprometer um projeto, ainda que
alguns autores considerem-na como um fator positivo.
A confiança refere-se na habilidade de um indivíduo em acreditar e aceitar o
conteúdo da comunicação de outro indivíduo, criando um laço, inicialmente superficial,
de crença [WHI94]. Ela esta relacionada com a capacidade de equipes globais
trabalharem de forma produtiva, em ambientes globais.
5.3 Aspectos Organizacionais
Diversos autores abordam os elementos organizacionais nas unidades de
desenvolvimento offshore. Em [EVA04a], é apresentado como estes elementos estão
relacionados com o sucesso de projetos de desenvolvimento global de software. As
categorias de seu estudo foram utilizadas. A referência teórica de outros autores serviu
de base para validar a usabilidade destas categorias, ainda que eles não tenham
explorado estas características no desenvolvimento global de software em ambientes
offshore insourcing.
Da mesma maneira, conforme apresentado por [LAC01], a efetiva gerência de
unidades de desenvolvimento offshore depende do entendimento do negócio da
organização por parte dos gestores. Desta forma, procurou-se enumerar os elementos
organizacionais característicos de ambientes offshore insourcing. A tabela 15 apresenta
as categorias agrupadas por estes aspectos.
91
Tabela 15: Categorias dos aspectos organizacionais
Aspecto Categorias Teoria
Referenciais Estratégicos [KHA03]
[NOL79]
Recursos [SHA03]
[CAR02]
Distribuição das Operações [KIS03]
[EVA03]
[SHA03]
Estrutura Organizacional
Políticas
[EVA03]
Avaliação [ISA04]
[SPC01]
Organizacional
Infra-estrutura [ISA04]
[KPM04]
[SUC04]
Os referenciais estratégicos referem-se à missão e ao objetivo da organização.
Neste trabalho, eles estão diretamente associados à estratégia da matriz com o offshore
insourcing e o impacto nas suas unidades.
Os recursos visam estabelecer um relacionamento entre o tamanho da
organização e de suas unidades offshore. Existe uma relação entre o número de
funcionários na matriz e na unidade que aumente a produtividade do projeto [SHA03].
A distribuição das operações visa estabelecer a relação de onde esta a matriz e
suas unidades. Esta categoria é afetada pelos referenciais estratégicos da matriz. A
estrutura organizacional foi classificada de acordo com [SIL01], assim como as
variações e classificações.
As políticas estão relacionadas com todas as outras categorias, uma vez que elas
estabelecem o padrão e a forma do trabalho. Quais as ferramentas serão utilizadas, os
responsáveis, etc.
A categoria de avaliação é utilizada para denotar a existência de critérios e
mecanismos de controle perante a unidade. Os resultados de avaliações internas, como
92
as de controle de qualidade, são compartilhados com a matriz, a fim de que elas tenham
a visão sobre o andamento dos projetos.
A categoria de infra-estrutura aborda os elementos físicos que devem estar
presentes para que o projeto global possa ser conduzido. Ela engloba os ativos físicos de
TI, como topologias de rede, armazenamento e capacidades de processamento.
93
6 Proposta de Estrutura do Modelo de Maturidade
Neste capítulo é apresentada a proposta de uma estrutura de modelo de
maturidade para organizações de desenvolvimento global de software em ambientes
offshore insourcing. Verificou-se uma demanda organizacional por este tipo de modelo,
que atenda as necessidades de centros de desenvolvimento.
Como a pesquisa procura complementar um estudo de ambientes offshore
insourcing, procurou-se traçar um relacionamento entre os resultados do estudo de caso
e da teoria. Compondo desta forma uma versão preliminar de estrutura de modelo.
A base teórica pesquisada serviu para a definição da estrutura. No estudo teórico
envolvem-se os principais modelos de maturidade de desenvolvimento de software
(SW-CMM, CMMI e SPICE) e de governança para o setor de tecnologia da informação
(ITIL e CObIT). Partiu-se da análise da estrutura destes modelos, identificando suas
características em comuns. Estas características estão apresentadas na seção 2.6, e
serviram de base para compor o modelo apresentado neste capítulo.
O estudo de caso serviu para validar a organização dos aspectos e das categorias.
Estas categorias forneceram detalhes das características do desenvolvimento global de
software em ambientes offshore insourcing. O mapeamento das características auxiliou
o melhor refinamento do modelo, pois foi possível identificar necessidades antes não
atendidas. Os aspectos estudados (organizacionais, técnicos e sociais) fazem parte da
estrutura do modelo de maturidade, compondo os domínios de cada nível de
maturidade. Os domínios são compostos de processos e serão apresentados na seção 6.2.
As lições aprendidas, identificadas ao final da execução do estudo de caso, serviram
como delimitadores do escopo da estrutura do modelo de maturidade.
6.1 Processo de Escolha e Definição da Estrutura
Após revisão da base teórica e da análise das características dos modelos,
procurou-se compor a estrutura do modelo baseado em elementos já existentes nos
modelos de maturidade estudados. Utilizar estes elementos visa aproveitar todo o
conhecimento já aplicado da comunidade acadêmica e científica. A contribuição
94
específica esta em especializar estes componentes para o desenvolvimento global de
software em ambientes offshore insourcing.
Procurou-se escolher os elementos dos modelos existentes de acordo com seu
propósito. Níveis de maturidade, por exemplo, são os indicadores da maturidade da
organização em realizar determinado conjunto de processos. Neste caso, consideraram-
se os níveis de maturidade para indicar a maturidade do centro de desenvolvimento
offshore insourcing em seus processos e relacionamento com a matriz.
Os níveis de maturidade serão constituídos de capacidades de domínios e estes
níveis de maturidade compostos por domínios. Esta estrutura foi extraída do SW-CMM,
pois o seu relacionamento entre as áreas chaves de processo e os níveis de maturidade
apresentam uma conexão muito forte. O modelo sucessor, o CMMI, não modificou esta
estrutura.
Outros elementos do modelo foram extraídos do CObIT. Onde os domínios são
compostos por processos e os processos possuem um conjunto de atividades e de infra-
estrutura que os suportam. Nota-se que os elementos do CObIT são mais abrangentes do
que as áreas chaves de processo do SW-CMM. Esta abrangência é justificada devido ao
propósito do modelo.
O CObIT é um modelo de governança de TI, seus elementos permitem uma
customização e flexibilidade muito maior do que o modelo SW-CMM. Apesar do
modelo CMMI ser uma evolução do modelo SW-CMM, sua estrutura não sofreu
alteração significativa. A maior mudança foi em termos conceituais e a possibilidade de
evolução em uma área-chave específica ao invés de um conjunto de áreas-chaves. Por
este motivo, o estudo baseou-se na versão antecessora do CMMI, o SW-CMM.
Alguns autores ainda apresentam um relacionamento entre o modelo ITIL e o
CObIT, de forma que eles se complementam. Neste estudo eles foram considerados
modelos distintos, e, optou-se pela estrutura do CobIT, principalmente por sua
abrangência e a existência de guidelines. A tabela 16 apresenta os elementos utilizados
na composição do modelo, bem como de onde eles foram extraídos, o porquê eles foram
retirados do modelo em questão e a referencia teórica de onde foram extraídos.
Os níveis de maturidade definem o nível em que o centro esta em dado momento
do tempo. Ele esta baseado no comprimento de uma série de objetivos, definidos nos
objetivos específicos de cada processo.
As capacidades de domínio apresentam os requisitos que devem ser satisfeitos
para que o centro atinja o próximo nível.
95
Tabela 16: Elementos do modelo proposto e suas origens
Extraído
do Modelo
Níveis de
Maturidade
SW-CMM Descreve a organização de níveis de
maturidade de acordo com o cumprimento de
uma série de requisitos.
[SEI02]
[SEI95]
Capacidades
do Domínio
CObIT Representa as capacidades e restrições que
devem ser atendidas a fim de atingir
determinado nível de maturidade.
[ISA04b]
Domínios CObIT Apresenta uma abrangência maior do que
processos. Um domínio pode ser constituído
por um conjunto de processos.
[ISA04a]
Processos CObIT
SW-CMM
Processos que compõem um ou mais domínios. [ISA04b]
[SEI95]
Objetivos CObIT
SW-CMM
Devem ser atingidos para que um determinado
processo possa ser satisfeito.
[ISA04c]
[SEI95]
Guidelines CObIT Servem para orientar os processos e atividades. [ISA04c]
Infra-estrutura
ou Atividades
CObIT
SW-CMM
Atividades e mecanismos de infra-estrutura
que servem de base para que os objetivos dos
processos sejam atendidos.
[ISA04c]
[SEI95]
Implementação e
Institucionalização
CObIT
SW-CMM
Rotinas de implementação e
institucionalização para que a organização
adote os processos e procedimentos de cada
domínio.
[ISA04b]
[SEI95]
Componente Porquê? Teoria
Os domínios representam um processo ou conjunto de processos que o compõe.
Esta definição segue a mesma estrutura utilizada pelos modelos de governança. Neste
caso, extraído do CObIT devido a maior abrangência organizacional.
Os processos compõem os domínios e são uma seqüência ou mais de atividades
necessárias para atingir um determinado objetivo. Neste caso é um elemento existente
tanto no CObIT quanto no SW-CMM.
Os objetivos são a granularidade mais baixa existente no modelo. Eles devem
ser satisfeitos para que seja possível averiguar se a organização atingiu ou não
determinado nível de maturidade. Extraído do SW-CMM e do CObIT. Neste caso ele
poderia ter sido extraído de qualquer um dos modelos de maturidade que tivessem este
componente.
96
As guidelines servem de base para a execução dos domínios e dos processos.
Elas demonstram-se úteis para realizar a customização de processos ou da utilização de
domínios já existentes pelo centro (tailoring).
A infra-estrutura ou atividades procuram atender um determinado objetivo.
Extraídas do modelo SW-CMM por descreverem o que precisa ser realizado. No
modelo CMMI ela também esta presente.
A implementação e a institucionalização são os mecanismos de disseminação
dos processos e domínios na organização. São elementos do SW-CMM/CObIT/CMMI e
ITIL.
6.2 Descrição da Estrutura
Com base na análise da estrutura dos modelos de maturidade e no
relacionamento entre cada componente, definiu-se que o formato da estrutura do modelo
terá os componentes do SW-CMM e do CObIT. Como descrito anteriormente, o SW-
CMM apresenta uma estrutura adequada à organização e as relações entre os
componentes envolvidos. Sua contribuição principal esta na estrutura, pois seu
relacionamento com os componentes evidencia a grau de maturidade que a organização
ou o processo atinge. Em relação ao CMMI estes elementos foram preservados.
Os componentes agregados do SW-CMM são seguintes:
- Formato da estrutura;
- Composição dos elementos guiados por um nível da maturidade.
Ainda baseado na análise dos modelos, o CObIT apresenta uma estrutura similar
ao SW-CMM, porém, ele não limita sua aplicabilidade no ambiente de desenvolvimento
de sistemas. Sua abrangência é maior, considerando fatores que não são abordados pelo
SW-CMM. O CObIT não é limitado para compor a organização em áreas dos processos,
mas sim em domínios.
A diferença esta em que um determinado processo pode fazer parte de um ou
mais domínios, retirando a unicidade de relacionamento que existe no SW-CMM onde
um processo pertence a apenas uma área chave de processo. Além disso, o CObIT
explora com profundidade o uso de guidelines para orientar como os processos podem
ser executados e institucionalizados. Assim, deste modelo, a estrutura agregará os
seguintes componentes:
97
- Orientação da execução baseada em guidelines;
- Relações no nível de domínio, onde cada domínio pode ser composto por um
ou mais processos;
- Relação do modelo com o tipo de serviço que o setor se considera dar, significa
o alinhamento entre os objetivos da organização e o setor de TI, possível devido a sua
abrangência em relação ao setor.
A fim de demonstrar o relacionamento dos elementos de modelo, utilizou-se a
mesma convenção do modelo SW-CMM para descrever o modelo. Sendo assim, a
estrutura visa seguir as mesmas definições, em termos de representação semântica, do
modelo SW-CMM e do CObIT. Por este motivo, a figura 16 apresenta as definições que
foram tomadas para compor o modelo:
Figura 16: Componentes da Estrutura
A composição do modelo buscou seguir os mesmos princípios na qual o SW-
CMM foi elaborado. Neste sentido, a principal contribuição foi em adicionar a estrutura
principal do CObIT na composição do modelo.
Os níveis de maturidade ainda são os elementos chaves do modelo. A
abrangência de cada domínio irá determinar em que nível esta a empresa, para
determinado domínio. Isto é verificado através do atendimento das capacidades dos
domínios. Os domínios abrangem dimensões separadas de acordo com a bibliografia, e,
que foram constatadas na realização dos estudos de caso. Estas dimensões, sociais,
técnicas e organizacionais, podem ser compostas de mais de um processo. Estes
processos possuem objetivos, que podem atender mais de um tipo de domínio.
Este símbolo representa um componente ou um conjunto de
com
p
onente.
Este símbolo representa a dependência de entre
com
p
onentes.
Este símbolo representa a atividade fim que será realizada
ou executada
,
bem como o ob
j
etivo
p
rinci
p
al atin
g
ido.
Este símbolo representa a existência de um componente
o
p
tativo e customizável no modelo.
Este símbolo representa a dependência entre um
com
p
onente o
p
tativo e outros com
p
onentes da estrutura.
98
Outra principal diferença, esta na existência de mais de um processo por
domínio. E estes processos podem pertencem a mais de um domínio, ou completá-lo.
Um exemplo é um processo sobre a utilização de ferramentas de comunicação. Este
processo abrange objetivos do aspecto social, envolvendo cultura e confiança, e abrange
também objetivos de aspectos técnicos, pois demonstra como utilizar as ferramentas da
organização.
As atividades e a infra-estrutura servem para dar o apoio necessário para que os
processos possam ser realizados. Assim como a implementação e institucionalização
serve de base para que a organização adote e use determinado conjunto de processos.
As guidelines servem para auxiliar a execução dos domínios, bem como para
guiarem como as implementações e institucionalizações poderão ser efetuadas.
Baseado nestes componentes foi possível compor a estrutura apresentada pela
figura 17.
Figura 17: Proposta de Estrutura do Modelo
Níveis de Maturidade
Capacidades
do Domínio
Indicam
Compostos de
Domínios
Consiste de
Processos
Objetivos
Atingem
Im
p
lementam
Atividades ou Infra-
estrutura
Implementações ou
Institucionalizações
Descrevem
Guidelines
Guia
m
Guia
m
99
Os níveis da maturidade são agrupados por domínios. Estes níveis indicam a
capacidade de cada domínio. Estes níveis serão usados avaliar a maturidade da
organização em executar eficazmente o domínio.
As capacidades dos domínios limitam os níveis de maturidade. o escopo e
abrangência são parametrizados por estas capacidades. Por Exemplo, se a organização
estiver no terceiro nível de maturidade, então o escopo de abrangência dos domínios é
mais elevado do que no nível anterior.
Os domínios estão relacionados às dimensões existentes nos projetos de software
no desenvolvimento global, conforme identificado por ([EVA04a], [PRI03], [CAR99] e
[KAR98]). Os domínios considerados nesta estrutura serão as relacionadas com
aspectos sociais, técnicos e organizacionais. A figura 18 apresenta como os domínios
estão agrupados.
Figura 18: Aspectos pertencentes aos Domínios
Apesar destes domínios terem sido identificados em organizações de
desenvolvimento global de software, a realização dos estudos de caso, em organizações
de DGS em ambientes offshore insourcing fornece argumentos para que eles possam ser
considerados parte dos domínios deste tipo de organização também.
Em cada um dos domínios, existirão categorias. Estas categorias descrevem
áreas comuns na organização. Neste sentido, os trabalhos de [EVA04a] e [CAR99]
foram fundamentais, pois como o relacionamento é feito em organizações de
desenvolvimento global de software. Como o offshore insourcing é um tipo de DGS, foi
possível utilizar os trabalhos relacionados e utilizar as características já abordadas. A
figura 19 apresenta como as categorias estão relacionadas entre si.
Domínios
A
spectos
Técnicos
A
spectos
Organizacionais
A
spectos
Sociais
100
Composição dos
Domínios
Aspectos
Técnicos
Aspectos
Organizacionais
Aspectos
Sociais
Figura 19: Dimensões e Categorias
Desta forma, as seguintes categorias foram identificadas:
Aspectos Organizacionais:
• Referenciais Estratégicos: Representam os objetivos da matriz em
distribuir suas operações. Os objetivos do centro offshore são
complementares aos objetivos definidos pela matriz.
• Recursos: Representam a alocação física dos recursos humanos
utilizados pela unidade offshore. A unidade pode utilizar recursos de
outras empresas (outsourcing) sem, necessariamente repassa este
relacionamento para a matriz. Evidentemente, isto depende do grau de
autonomia da unidade.
• Distribuição das Operações: Representa o quão distribuído estão as
operações do centro. Quais são os países envolvidos, questões legais e de
ativos de TI também estão relacionados a esta categoria.
• Estrutura Organizacional: Representa como a unidade offshore esta
organizada e como é a organização entre ela e a matriz.
• Políticas: Representam as estratégias de utilizar padrões de certificação
como diferenciais de qualidade de serviço. Podem estar relacionadas
também com a existência de manuais e guias organizacionais.
101
• Avaliação: Referem-se à existência de métricas e de indicadores que
permitam um acompanhamento organizacional. Estes indicadores podem
servir de base para a organização compor seus referenciais estratégicos,
bem como decidir quais operações serão distribuídas ou não.
• Infra-Estrutura: Definem necessidades básicas para o funcionamento da
operação global, como ativos de rede, armazenamento, etc.
Aspectos Sociais:
• Comunicação: Representa como ocorre a comunicação e as maneiras
existentes para aumentarem a sua eficácia.
• Confiança: Representa o tipo da confiança que existe entre as equipes
distribuídas.
• Cultura: Procura caracterizar como a organização trata das culturas
existentes e os tipos de tarefas e atividades existentes para superá-las. A
cultura pode estar relacionada com o tipo de sociedade em que a
organização offshore está inserida, sendo predominantemente
individualista ou coletivista [MOR03].
Aspectos Técnicos:
• Padrões: Representam à usabilidade de padrões e conceitos de
engenharia de software, como a aplicação de re-engenharia, aplicação de
padrões técnicos de arquitetura, etc.
• Gestão de Conhecimento: Representa parâmetros que definem se a
organização consegue efetuar a gestão de conhecimento de seus
processos e do conteúdo de seus projetos.
• Metodologia de Desenvolvimento: Procura identificar se a organização
possui e implementa um processo do desenvolvimento, tal como RUP,
MSF, Agile.
• Processo de Desenvolvimento: Procura identificar se a organização e/ou
unidade offshore possui um conjunto de atividades que façam a
correspondência entre a metodologia de desenvolvimento e os objetivos
de negócio de cada projeto. O processo de desenvolvimento pode ser
102
representado por um diagrama em que demonstra os atores e as
responsabilidades de cada um dentro do projeto.
• Alocação de Recursos: Representa a organização da matriz e/ou unidade
offshore em gerenciar os recursos disponíveis de forma efetiva nos
projetos da unidade.
A lição aprendida #1 também sugere a divisão dos domínios conforme adotado
no modelo, provendo mais um argumento para a adoção destas dimensões.
Os processos compõem os domínios. Cada processo tem um objetivo que deve
ser alcançado de modo que satisfaça a capacidade do domínio. Os domínios podem ser
compostos para um ou mais processos e devem informar o objetivo a ser atingido.
Assim como descrito em parágrafos anteriores, os processos podem atender mais de um
domínio, dependendo do objetivo a qual estão sendo propostos. A lição aprendida #2
identificou uma classificação para o grau de autonomia dos centros estudados. Esta
autonomia, esta representada no modelo através da realização dos objetivos do
processo. Da mesma forma, as informações sobre o grau de autonomia podem estar
identificadas pelas guidelines. As lições aprendidas #5 e #6 também ressaltam os
problemas de comunicação, confiança e de relacionamento entre equipes dentro dos
centros. É possível observar, que os aspectos sociais devem estar presentes na estrutura
do modelo. Neste caso, fazendo parte de domínios, onde terão processos para atender
dificuldades no alinhamento desta comunicação e confiança.
As guidelines são utilizadas para auxiliar a maneira como os processos devem
ser executados, bem como definir maneiras de institucionalizá-los na organização. Elas
fornecem subsídios para suportar os processos e guiam como a atividade deve ser
conduzida para executar um processo. Dependendo da estrutura de organização, as
guidelines podem ser aplicáveis internamente (para a subsidiária ou os setores da
organização).
As atividades e/ou os infra-estruturas permitem atingir os objetivos de cada
processo. Um conjunto de atividades pode abranger um ou mais processos. As
atividades são introduzidas na organização, se ainda não existirem. A lição aprendida #3
também contribuiu para a agregação deste elemento no modelo, uma vez que é possível
identificar evoluções na maturidade dos centros, partindo de atividades mais simples até
atingir a realização de atividades mais complexas.
As Implementações ou Institucionalizações visam caracterizar a maneira como a
organização está conduzindo a seus domínios. O que teve que ser modificado e o
103
comportamento da organização antes das mudanças. Ela envolve ações que são
realizadas internamente na organização, envolvendo todos os seus participantes. A lição
aprendida #4 demonstra a importância de modelos de qualidade, bem como a
dificuldade de realizar implementações do modelo.
A fim de representar conceitualmente o relacionamento entre os elementos
envolvidos neste modelo, a figura 20 apresenta o modelo conceitual da estrutura do
modelo proposto. Ele utiliza o diagrama de classes da Unified Modeling Language
(UML).
Guidelines
Niveis_de_Maturidade
descricao
id
nome
capacidades_do_dominio
Dominios
descricao
nome
proposito
0..n
1
0..n
1
Processos
descricao
id
praticas
informacoes_complementares
objetivos
n
n
n
n
referencia para
consiste de
n
n
n
referem-se
n
Implementacoes_Institucionalizacoes
ListaAtividades
ListaResponsaveis
Atividades_Infraestrutura
nome
detalhe_atividade
especificacao_tecnica
1
n
1
n
implementam
n
n
n
n
guiam
guiam
Figura 20: Modelo Conceitual da Estrutura Proposta
Assim como outros modelos de maturidade, é necessário que exista um
alinhamento entre os objetivos de negócio e da área de TI, desta forma, os domínios e
guidelines poderão ser mapeados e melhor aproveitados. A estrutura foi criada com o
objetivo de ser o mais flexível possível. Esta customização é possível devido à
existência de guidelines. Elas podem ser definidas pela organização para melhor
acomodarem os processos dentro de seus domínios. Da mesma forma, pode haver
setores na organização que não seja desejável executar um ou mais processos, esta
definição pode estar assinalada na guideline.
104
105
7 Considerações Finais
A engenharia de software tem realizado significativos avanços nos últimos anos.
Modelos de qualidade, processos de desenvolvimento e novas metodologias têm sido
adotados largamente e com sucesso no meio acadêmico e empresarial. Entretanto, em
ambientes cada vez mais globalizados, desenvolver software torna-se uma atividade
cada vez mais complexa [CAR99]. Surge então o desenvolvimento global de software
em ambientes offshore insourcing, como uma estratégia relativamente recente, onde o
principal objetivo esta na organização atender à sua própria demanda criando centros de
desenvolvimento localizados em diferentes países visando a redução de custos.
A utilização desta estratégia de desenvolvimento tende a crescer nos últimos
anos, bem como estratégias similares como, o offshore outsourcing [LAC01], deixando
um canal aberto para uma série de pesquisas sobre as dificuldades desta nova
abordagem. Com material ainda escasso sobre o assunto, este é sem dúvida um tema
pouco explorado por pesquisadores no Brasil e no mundo. Muitas vezes, devido à falta
de contato com este tipo de realidade.
Conforme apresentado no capítulo 3, o objetivo geral desta dissertação foi
atingido, com a proposta de uma estrutura de modelo de maturidade para organizações
de desenvolvimento global de software em ambientes offshore insourcing. Da mesma
forma, enumeraram-se as características identificadas através de estudo de caso nos
centros de desenvolvimento.
O objetivo específico, de aprofundar o conhecimento teórico nas áreas de
pesquisa de desenvolvimento global de software e de modelos de qualidade também foi
atingido, dado o levantamento bibliográfico realizado para compor o modelo, bem como
a análise das características destes modelos, conforme demonstrado pela base teórica
apresentada no capítulo 2. As dimensões que agrupam as características de ambientes
offshore insourcing foram exploradas e 5. Foram apresentados ainda os resultados do
estudo de caso múltiplo aplicado em unidades de desenvolvimento offshore insourcing
localizadas no Brasil, China e Cingapura.
A elaboração da estrutura do modelo e o enquadramento das análises dos
estudos de caso foram descritas no capítulo 6, tendo sido utilizado como base a revisão
teórica dos principais aspectos de ambientes de desenvolvimento global de software.
106
Um dos diferenciais foi propor a análise dos aspectos inseridos como domínios, dentro
do modelo proposto.
7.1 Contribuições
Uma das contribuições desta pesquisa é a proposta de estrutura de um modelo de
maturidade para organizações de DGS em ambientes offshore insourcing, apresentado
no capítulo 6. Na elaboração deste modelo, destaca-se a análise sobre os principais
modelos de maturidade e de governança, bem como uma análise realizada em modelos
de referência de desenvolvimento offshore. A vantagem de utilizar modelos como o
SW-CMM e o CObIT esta em aproveitar os anos de pesquisa que universidades e
empresas investiram por traz deste modelo. A intenção não era apresentar um modelo
sem uma base sustentável.
A enumeração das características de ambientes offshore insourcing também foi
uma das contribuições deste trabalho. A possibilidade de realizar um estudo de caso
múltiplo em unidades localizadas no Brasil, China e Cingapura, foram fatores
importantes para aumentar a abrangência do estudo.
Ainda como resultado do trabalho, destaca-se que a estrutura e as características
enumeradas, servirão de base para a pesquisa que esta sendo desenvolvido como escopo
de um projeto de doutorado. A pesquisa está sendo conduzida nesta mesma
universidade em cooperação com a Universidade de Illinois (Chicago – Estados Unidos)
e a Universidade de Victoria (British Columbia – Canadá).
Ao longo da análise dos resultados do estudo de caso nos centros, novas
observações foram identificadas, apresentadas no capítulo 4. Confirmando teorias já
apresentadas e aumentando a abrangência de resultados encontrados na literatura sobre
o assunto de DGS em ambientes offshore insourcing. Adicionalmente, as características
identificadas servirão de base também para o estudo de doutorado. Estes resultados
adicionais também servirão de entrada para o projeto de elaboração de um modelo de
maturidade para organizações offshore insourcing. Da mesma forma como apresentam
novos dados empíricos relativos à área de engenharia de software, mais
especificamente, na área de desenvolvimento global de software.
Finalmente, este estudo visa contribuir com a prática ao atender uma demanda
organizacional crescente por melhorias nos processos de engenharia de software e
107
organização de processos, bem como, por tratar das dificuldades causadas pela
distribuição das equipes de desenvolvimento, fornecedores e clientes.
7.2 Limitações do Estudo
Uma das limitações da pesquisa refere-se ao número de empresas estudadas, na
parte empírica do estudo, restringindo a generalização dos resultados obtidos. Entretanto
deve-se destacar que os resultados do estudo de caso, principalmente os da
categorização dos elementos, foram sustentados na base teórica estudada, o que permite
um bom grau de segurança nas conclusões obtidas. Isto também é devido ao tipo de
pesquisa desenvolvida, exploratória e de base qualitativa, permitindo o uso de
inferências nas conclusões obtidas.
Outra limitação esta de não ter sido incluído os dados demográficos dos centros
C e D como parte da dimensão 1 do estudo. Estes dados poderiam ampliar conclusões
referentes à população estudada.
Os níveis de maturidade não foram definidos devido à limitação do escopo do
trabalho. Assim sendo, o modelo servirá de base para a composição dos níveis de
maturidade (a ser realizado no projeto maior).
Outra limitação do estudo foi à definição de um modelo de estrutura de alto
nível, sem explorar técnicas matemáticas, formais ou quantitativas específicas a serem
utilizadas em sua composição. A opção por esta abordagem foi feita devido a restrições
de tempo.
7.3 Trabalhos Futuros
Identifica-se grande potencial de crescimento nesta linha de pesquisa, onde os
pontos fortes envolvem uma parceria estável entre a academia e a indústria, criando
condições de experimentação e aprendizagem únicas, decorrentes de uma sinergia
positiva entre os parceiros. Centrando no tema de DGS em ambientes offshore
insourcing, bem como em modelos de qualidade.
Como pesquisas futuras, sugerem-se:
• Continuidade do projeto de acordo com o desenho de pesquisa
apresentado no capítulo 3, avançando nas fases 4 e 5;
108
• Aprofundar o estudo das características das organizações de
desenvolvimento global em ambientes offshore insourcing;
• Abordar detalhadamente as atividades do modelo de processo,
identificando técnicas para utilização de acordo com cada cenário
envolvido;
• Realizar estudos em outras organizações a fim de aumentar o grau de
generalização dos resultados;
109
8 Referências Bibliográficas
[AUD01] Audy, Jorge Luis N. Modelo de Planejamento Estratégico de Sistemas de
Informação: Contribuições do processo decisório e da aprendizagem
organizacional. 195 f. 2001. Tese (Doutorado), PPGA – UFRGS, Porto Alegre, Brasil,
2001.
[BIA02] Bianchi, Alessandro; Caivano, Danilo; Lanubile, Filippo; Rago, Francesco; Visaggio,
Giuseppe. An Empirical Study of Distributed Software Maintenance. In:
International Conference on Software Maintenance (ICSM'02), IEEE Software
Proceedings, 2002, 7pp.
[BOR03] Borchers, Greg. The Software Impacts of Cultural Factors on Multi-cultural
Software Development Teams. IEEE Software Proceedings, 2003, 5pp.
[CAR99] Carmel, Erran. Global Software Teams – Collaborating Across Borders and Time
Zones. Prentice Hall, 1999, 269p.
[CAR02] Carmel, Erran; Agarwal, Ritu. The Maturation of Offshore Sourcing of Information
Technology Work. MIS Quarterly Executive, vol. 1, no. 2, 2002, 12pp (65-77).
[COA04] Coar, Ken. The Sun Never Sets on Distributed Development. ACM, 2003-2004, 6pp.
[CRE03] Creighton, Oliver; Dutoit, Allen H. Brügge, Bernd. Supporting an Explicit
Organizational Model in Global Software Engineering Projects. IEEE Software
Proceedings, 2003, 5pp.
[DEL03] Delmonte, Anthony, J.; McCarthy, Richard V. Offshore Software Development: Is the
benefit worth the risk? In: Ninth Americas conference on Information Systems, vol. 1,
no. 5, 2003, 7pp.
[EVA03] Evaristo, Roberto. The Management of Distributed Projects Across Cultures.
Journal of Global Information Management (JGIM), Nova Zelândia, vol. 11, no. 4, 2003,
8pp.
[EVA04a] Evaristo, R. Scudder, K. Desouza, and O. Sato, A Dimensional Analysis of
Geographically Distributed Project Teams: A Case Study, Journal of Engineering
and Technology Management, vol. 4, no. 3, 2004, 10pp.
[EVA04b] Evaristo, Roberto; Prikladnicki, Rafael; Audy, J. L. ; Avritchir, Jairo. A Maturity Model
for Offshore Insourcing. Technical Report. 6pp. 2004.
[GEF03] Gefen, David; Senn, James A. The Correlation Between Outsourcing and the
Business Value of Information Technology, IEEE Software Proceedings, 2003, 3pp.
[GOP03] Gopalakrishnan, S.; Kochikar, V. P.; Yegneshwar, S. The Offshore Model for
Software Development: The Infosys Experience. ACM Proceedings, 2003, 2pp.
110
[HER99] Herbsleb, James. D; Grinter, Rebecca. Splitting the organization and integrating the
code: Conway's Law revisited. In: ICSE, 1999, Carolina do Norte. Proceedings…
EUA, 1999. 11 p.
[HER01] Herbsleb, James; Mockus, Audris; Finholt, Thomas A.; Grinter, Rebecca E. An
empirical study of Global Software Development: Distance and Speed. IEEE
software Proceedings, 2001, 9pp.
[ISA04a] Information Systems Audit and Control Association (ISACA). CobiT Model. Capturado
em: http://www.isaca.org/Template.cfm? Section=Downloads9&Template=
/TaggedPage/ TaggedPageDisplay.cfm. Agosto de 2004.
[ISA04b] Information Systems Audit and Control Association (ISACA). CobiT Model and
Auditing. Capturado em: http://www.isaca.org/ COBIT_Mapping_Paper_6jan04.pdf.
Agosto de 2004.
[ISA04c] Information Systems Audit and Control Association (ISACA). Control Objectives
Model for IT - Sarbanes-Oxley. Capturado em: http://www.isaca.org/
IT_Control_Objectives _for_Sarbanes-Oxley_7july04.pdf. Agosto de 2004.
[ITI04a] ITIL Service Management. The ITIL Framework. Capturado em: http://www.itil-service-
management-shop.com/ itildefinition.htm. Agosto de 2004.
[ITI04b] ITIL and ITSM Directory. ITIL Definition. Capturado em: http://www.itil-itsm-
world.com/. Agosto de 2004.
[KAR98] Karolak, Dale Walter. Global Software Development, Managing Virtual Teams and
Environments. Califórnia, Los Alamitos: IEEE Computer Society, 1998, 1º Edição.
159pp.
[KHA03a] Khan, Naureen; Currie, Wendy L.; Weerakkody, Vishanth; Desai, Bhavini. Evaluating
Offshore IT Outsourcing in India: Supplier and Customer Scenarios. In:
Proceedings of the 36th Hawaii International Conference on System Sciences, IEEE
Computer, 2003, 10pp.
[KHA03b] Khan, Naureen; Currie, Wendy L.; Ghuah, Mathew. Developing a Model for Offshore
Outsourcing. In: Ninth Americas conference on Information Systems, vol.1 no.4, 2003,
8pp.
[KIS03] Kishore, Rajiv; Rao, H. R.; Nam, K.; Rajagopalan, S.; Chaudhury, A. A Relationship
Perspective on IT Outsourcing, Communications of the ACM, vol. 46 no 12, 2003,
6pp.
[KUL03] Kulpa, Mararet K. Interpreting the CMMI: a process improvement approach.
Estados Unidos: Auerbach, vol. 2, no.4, 2003, 414 pp.
111
[KUR96] Kurokawa, Susumu. A Comparative Analysis of Outsourcing in Medium-Sized
Japanese and American Firms. In: Proceedings of the 29th Hawaii International
Conference on System Sciences, IEEE Computer, Proceedings, 1996, 8pp.
[LAC01] Lacity, Mary C.; Willcocks, Leslie P. Global Information Technology Outsourcing: In
Search of Business Advantage. Hardcover, 2001, 353pp.
[LOH02] Loh, Lawrence; Venkatraman, N. An Empirical Study of Information Technology
Outsourcing: Benefits, Risks and Performance Implications, IEEE Software
Proceedings, 2002, 12pp.
[LOP03] Lopes, Leandro. Engenharia de Requisitos em Ambientes de Desenvolvimento
Distribuído de Software. Trabalho Individual II, Mestrado em Ciência da
Computação, PUCRS, 2003.
[MCC96] McConnell, Steve. Rapid Development. Microsoft Press. 1996. 647pp.
[MOR03] Morstead, Stuart; Blount, Gregory. Offshore Ready Strategies to Plan & Profit from
Offshore IT-Enabled Services. Estados Unidos: ISANI Press, 1º Edição, 2003, 296pp.
[NOL95] Nolan, R. Managing the Crisis in Data Processing. Harvard Business Review, vol 57,
no. 2, 1995, 11pp (115-126).
[OLS04] Olson, Judith S.; Olson, Gary M. Culture Surprise in Remote Software Development
Teams. ACM Proceedings, 2003-2004, 7pp.
[PAU95] Paulk, Mark.. How ISO 9001 Compares with the CMM. IEEE, Janeiro 1995.
[PRI02] Prikladnicki, Rafael. Desenvolvimento Distribuído de Software e Processos de
Desenvolvimento de Software. 2002. 66 f. Trabalho Individual II, FACIN – PPGCC,
PUCRS, Porto Alegre, Ago. 2002.
[PRI03] Prikladnicki, Rafael; Audy, Jorge Luis N. MuNDDoS: Um Modelo de Referência para
Desenvolvimento Distribuído de Software. 12 f. 2003, Seminário de Andamento, FACIN
– PPGCC, PUCRS, Porto Alegre Ago. 2003.
[RAD00] Rada, Roy; Craparo, John. Standardizing Software Projects. Communications of the
ACM, vol 51. no 2, 2000, 5p.
[REP02] Reponen, Tapio. Outsourcing or Insourcing?, Communications of the ACM, vol 57.
no 5, 2002 12pp.
[RID04] Ridley, Gail; Young, Judy; Carroll, Peter. COBIT and its Utilization: A framework
from the literature. In: Proceedings of the 37th Hawaii International Conference on
System Sciences, IEEE Software Proceedings, 2004, 8pp.
112
[ROC01] Rocha, Ana R.; Maldonado, José; Weber, Kival. Qualidade de Software - Teoria e
Prática. São Paulo, Prentice Hall, 2001, 303pp.
[ROC03] Rockenbach, Alex. Troubleshoot Your Way to Success in Remote Team
Management!, ISSIG Review, Project Management Institute – Information Systems
Specific Interest Group, vol. 13 no. 4, fourth quarter 2003, 16pp.
[SAB99] Sabherwal, Rajiv. The role of trust in outsourced development projects.
Communications of ACM. 1999. 8p.
[SEI95] Software Engineering Inst. Carnegie Mellon Univ. The Capability Maturity Model:
Guidelines for Improving the Software Process. Estados Unidos: Addison Wesley,
18º Edição, 1995, 441 pp.
[SEI02] CMMI Product Team. Capability Maturity Model® Integration (CMMI), Version 1.1 -
CMMI for Software Engineering (CMMI-SW, V1.1) Staged Representation. Carnegie
Mellon University, 2002, 639pp.
[SHA03] Sharma, Rajeev. Influence of Geographic Dispersion on Control and Coordination
Approaches for Management of Software Development Projects. In: Ninth
Americas conference on Information Systems, vol 1. no. 2, 2003, 6pp.
[SIL01] Silva, Reginaldo O. Teorias da Administração. São Paulo: Pioneira – Thomson
Learning, 2001, 1ª edição, 523pp.
[SON03] Song, Jaeki; Jain, Hemant K. Cost Model for Global Software Development. ACM
Proceddings, 2003, 3pp.
[SPC01] SPC (Software Productivity Consortium) NFP. Measurement for Distributed Teams.
Guidebook, SPC-2001010-MC, version 01.00.00. Herndon, Virginia: Software
Productivity Consortium.
[SUC04] Scienton User Group Canada . ITIL, CobiT and the IT Governance. Capturado em:
http://www.scienton.com/7799ug/images/Infosecurity/Pez-7799-Cobit-itil-
components.pdf, Agosto de 2004.
[SUN02] Sun, Szu-Yuan; Lin, Tung-Ching; Sun, Pei-Chen. The Factors Influencing
Information Systems Outsourcing Partnership – A Study Integrating Case Study
and Survey research methods. In: Proceedings of the 35th Hawaii International
Conference on System Sciences, IEEE Computer, 2002, 10pp.
[WHI94] Whitney, John O. The Trust Factor: Liberating profits and restoring corporate
vitality. R. R. Donnelley & Sons Company, vol23, no number, 1994, 235pp.
[YEO01] Yeo, Alvin W. Global-software development Lifecycle: An Exploratory Study. In:
Conference on Human Factors in Computing Systems, Proceedings of the SIGCHI
conference on Human factors in computing systems (SIGCHI'01), 2001, 8pp.
113
[YIN01] Yin, Robert. Estudo de Caso: planejamento e métodos. São Paulo: Bookman, 2001,
205 p.
114
115
APÊNDICE A – Instrumento de Pesquisa para o Estudo
de Caso
Protocolo para Estudo de Caso: Identificação de Critérios para Compor um
Modelo de Maturidade para Organizações Offshore Insourcing
Objetivo
Identificar as características de organizações de desenvolvimento de software que atuam em
ambientes offshore insourcing.
Questão de pesquisa
Quais as características que identificam o grau de maturidade de organizações de DGS que
atuam em um ambiente offshore insourcing?
Unidade de estudo
Organizações de desenvolvimento global de software que operem em um ambiente offshore
insourcing.
Característica-chave do método de estudo de caso
Este é um roteiro para o desenvolvimento e aplicação de um instrumento de pesquisa
estruturada com questões em escala Lickert que se caracteriza como uma pesquisa do tipo
transeccional. O objetivo é identificar características de organizações de DGS que atuem em
ambientes offshore insourcing.
Organização desse Protocolo
O protocolo será organizado com o segue:
1. Procedimentos
A. Levantamento das questões e estruturação do guia para a
entrevista
Participantes: Leonardo Pilatti
Local: CDPe – Centro de desenvolvimento e pesquisa
Dell/PUCRS
Datas: De 13/12/2004 a 04/02/2005
B. Reuniões para revisão do guia para a entrevista
Participantes: Jorge Luis Nicolas Audy. Doutor em Sistemas de
Informação – UFRGS - 2001 (Especialista,
Pesquisador Sênior)
Roberto Evaristo
Rafael Prikladnicki - Mestre em Ciência da Computação (PUCRS,
2003)
Local: Pró Reitoria de Pesquisa e Pós Graduação da PUCRS
(Jorge)
Revisões via e-mail (Evaristo)
Datas: 20/08/2004, 03/09/2004, 06/01/2005
116
C. Autorização da empresa participante (Tlantic)
Participantes:
Reginaldo Back
Local: Tlantic, Tecnopuc
Data:
D. Validação de Face e Conteúdo
Participantes:
Marcelo Blois - Doutor em Informática - PUC-Rio (2002).
Toacy Oliveira - Pós Doutorado em Informática - Universidade de
Waterloo (2003)
Michael da Costa Mora – Doutor em Informática
Sabrina dos Santos Marczak - Mestre em Ciência da Computação
(PUCRS, 2003)
Local: PUCRS
Data:
E. Pré-teste
Participantes:
Local:
Data:
F. Formato de Aplicação do Instrumento
Tipo:
Entrevista semi-estruturada com questões abertas e em escala
Licket
Caso 1:
Tlantic
Entrevistado Nome Data Local
Diretor Reginaldo Back
Gerente de
Desenvolvimento
Gerentes de
Projeto
Ponto Focal SEPG
Caso 2:
GDC
Entrevistado Nome Data Local
Director
Jairo Avritchir
Delivery Manager
Project Managers
SEPG Focal Point
117
2. Escolha dos Participantes
Relação respondentes x dimensões
Dimensões
Respondentes
1 2 3 4 5
Diretor (2 da
Tlantic, 1 do
GDC)
X X X X
Gerente de
Desenvolviment
o (1 Tlantic, 2
do GDC)
X X X
Gerente de
Projeto (2 da
Tlantic e GDC)
X X X
Ponto Focal SEPG
(1 da Tlantic e
1 do GDC)
X X X
3. Outros recursos utilizados
A. Recursos materiais
Æ Sistema de gerenciamento de e-mails para envio e recebimento
das entrevistas;
Æ Gravador para entrevistas face a face;
Æ Microcomputador com Windows XP e Microsoft Excel para análise
de dados.
4. Modelo do estudo e Dimensões da Pesquisa
O esquema a seguir representa graficamente os principais aspectos enfocados no
desenvolvimento deste trabalho.
118
Organizações de Desenvolvimento
Offshore Insourcing
Aspectos
Técnicos
Aspectos
Organizacionais
Aspectos
Sociais
Comunicação
Cultura
Confiança
Projeto de
Desenvolvimento
Gestão de
Conhecimento
Alocação de
Recursos em
Projeto
Metodologia de
Desenvolvimento
Recursos
Distribuição das
Operações
Estrutura
Organizacional
Políticas
A
valiação
Infra-estrutura
Padrões
Referenciais
Estratégicos
Figura 1 - Aspectos enfocados no trabalho
5. Análise de dados
A análise de dados utilizará a técnica de análise de conteúdo [YIN01] e para tabulação
dos dados coletados pretende-se utilizar o módulo estatístico, realizado através do
Excel. A coleta de dados envolve fontes primárias (resultado da aplicação do
instrumento) e fontes secundárias (documentação e registros de arquivos). A
triangulação dos dados coletados permitirá maior confiabilidade nos resultados
obtidos. Esta entrevista insere-se em uma pesquisa de base qualitativa, exploratória,
sendo o estudo de caso o principal método de pesquisa, aplicado conforme proposto
por [YIN01].
6. Dimensões e questões do guia para entrevista
Algumas convenções: A empresa matriz é considerada a empresa contratante do serviço
(podendo ser um setor/área/outra empresa ou um cliente), também conhecida por
headquarter, holding ou simplesmente empresa.
A subsidiária que presta o serviço para a matriz é considerada a unidade de
desenvolvimento de software offshore (UDSO).
Dimensão 1 – Dados Demográficos (Todos)
Indivíduo
1. Qual seu nome?
2. Qual sua idade?
Escolaridade
3. Informe sua escolaridade (maior):
( ) – 1º Grau ( ) – Superior Completo ( ) – Mestrado Completo
( ) – 2º Grau ( ) – Especialização ( ) – MBA Incompleto
( ) – Superior Inc. ( ) – Mestrado Incompleto ( ) – MBA Completo
4. Ano de conclusão (último curso):
119
Experiência
5. Tempo de experiência profissional na área de informática: (anos) e (meses)
6. Tempo de experiência profissional trabalhando em organizações de
desenvolvimento offshore insourcing*: (anos) e (meses)
* Offshore insourcing é uma estratégia organizacional que utiliza serviços da própria
empresa (setor) localizada em um país diferente da matriz da organização. As
subsidiárias podem ser chamadas de unidades offshore. O serviço prestado é apenas
para a matriz ou outras filiais da mesma empresa. [CAR02], [PRI02]
7. Qual o seu conhecimento sobre o desenvolvimento offshore de software**?
Nenhum Pouco Já ouviu falar Conhece Conhece bem
** Desenvolvimento Offshore é uma estratégia organizacional na qual determinada
organização subsidia ou terceiriza determinado serviço para unidades (ou
provedores) localizadas em outros países. [CAR02]
Relacionamento com
a Empresa
8. Tempo de empresa: (anos) e (meses)
9. Função:
Diretor Gerente de Desenvolvimento Gerente de Projeto
Ponto Focal SEPG
Dimensão 2 – Aspectos Organizacionais
Referenciais
Estratégicos
[KHA03], [NOL79]
10. Qual a missão e negócio da empresa?
11. Qual a estratégia da matriz com a operação offshore insourcing de
desenvolvimento de software?
12. A empresa tem autonomia para captar outros serviços (desenvolver para outras
empresas)? Caso afirmativo, quais são estes serviços?
13. A UDSO tem autonomia para captar outros serviços? (desenvolver para outras
empresas)? Caso afirmativo, quais são estes serviços?
Recursos
[CAR02], [SHA03]
14. Número de pessoas (aproximado) trabalhando atualmente na corporação
(globalmente):
15. Número de pessoas (aproximado) trabalhando na empresa (no setor/área ou
empresa matriz):
16. Número de pessoas (aproximado) trabalhando atualmente na UDSO:
Distribuição das
Operações
[KIS03], [EVA03],
[SHA03]
17. Onde se localiza a unidade da empresa que contrata os serviços da unidade
offshore?
18. Onde se localiza(m) a(s) unidade(s) da empresa prestadora de serviços? Há
quanto tempo esta unidade esta estabelecida neste(s) local (is)?
19. Onde se localiza os clientes que utilizarão os softwares gerados pelas unidades
offshore?
Estrutura
Organizacional
[EVA03]
20. Qual o tipo de estrutura organizacional predominante na corporação?*
Hierárquica Matricial Estruturada por Projetos Mista
21. Qual a estrutura organizacional da empresa (matriz/holding)?
Hierárquica Matricial Estruturada por Projetos Mista
120
22. Qual a estrutura organizacional da UDSO?
Hierárquica Matricial Estruturada por Projetos Mista
23. Qual a vinculação (estrutura) entre a UDSO com a empresa?
* Tipos de estruturas organizacionais conforme definidos em [SIL01]
Org. Hierárquica: Org. Matricial:
Por Projetos: Não possui uma definição hierárquica nem matricial. Os recursos são
alocados conforme necessidades de composição de projetos
Mista: Compreende a possível combinação entre Hierárquica, Matricial e Por
Projeto.
Políticas
[EVA03]
24. A UDSO contrata serviços de terceiros?
Não Sim
Quais serviços?
25. Existe um plano estratégico claro da UDSO?
Não Sim
26. A UDSO tem autonomia para desenvolver seu plano estratégico?
Não Sim
27. Em caso afirmativo, este plano foi definido em conjunto entre a UDSO e a
empresa?
Não Sim
28. Existem políticas claras da matriz /empresa com relação à atuação esperada da
UDSO?
Não Sim
Cite estas políticas.
29. As políticas existentes na empresa (matriz) dão flexibilidade à atuação da
UDSO.
Discordo totalmente
Concordo Totalmente
30. Os funcionários da UDSO conhecem as políticas da empresa matriz.
Discordo totalmente
Concordo Totalmente
Avaliação
[ISA04], [SPC01]
31. Existem indicadores de desenvolvimento/qualidade periódicos monitorados pela
UDSO?
Não Sim
Se existem, quais são eles?
32. Estes indicadores são acompanhados pela empresa?
Não Sim
33. Existe uma avaliação periódica da UDSO por parte da matriz?
Não Sim
121
34. Os critérios de avaliação da UDSO são de conhecimento de todos os
funcionários envolvidos.
Discordo totalmente
Concordo Totalmente
Infra-estrutura
[ISA04], [KPM04],
[SUC04]
35. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir
sua plataforma de hardware?
Total
Nenhuma
36. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir
suas ferramentas de desenvolvimento (Banco de Dados, Linguagens)?
Total
Nenhuma
37. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir
sua organização funcional (setores; gerencias)?
Total
Nenhuma
38. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir
projetos de pesquisa e desenvolvimento?
Total
Nenhuma
39. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir
seus parceiros de desenvolvimento (terceirização de parte de seus serviços)?
Total
Nenhuma
40. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir e
executar seu orçamento?
Total
Nenhuma
41. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para
contratar pessoal técnico (desenvolvedores; gerentes de projeto)?
Total
Nenhuma
42. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para
contratar pessoal de apoio administrativo (recursos humanos; marketing;
operações)?
Total
Nenhuma
43. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para definir
as ferramentas de desenvolvimento utilizadas pela UDSO?
Total
Nenhuma
Dimensão 3 – Aspectos Sociais
Caracterizam-se como aspectos sociais as dimensões envolvidas na organização que permeiam todo e
qualquer tipo de trabalho.
Comunicação
[CAR99]
44. Existe comunicação “face-to-face” freqüente entre a equipe da empresa e da
UDSO? Caso afirmativo, qual a freqüência (mês)?
45. Assinale abaixo quais meios de comunicação são utilizados entre as equipes
distribuídas da UDSO e a empresa:
Correspondência
Correio eletrônico
Fax
Correio de voz
122
Chat eletrônico
Broadcast de áudio em sentido único
Broadcast de vídeo em sentido único
Telefone
Videoconferência
Reunião em realidade virtual
Reunião face a face
Outra(s):
46. Existe um protocolo único definido na empresa para a utilização de cada meio de
comunicação entre as equipes distribuídas?
Não Sim
Qual?
47. Existem atividades de integração entre as equipes distribuídas?
Não Sim
Quais?
48. Existem treinamentos formais para a utilização dos meios de comunicação?
Como eles são apresentados para os participantes?
49. A existência de ferramentas (net meeting; softwares para conferencia virtual;
etc) que auxiliem a comunicação é fundamental para minimizar ruídos entre as
equipes globais.
Discordo totalmente
Concordo Totalmente
Cultura
[CAR99]
50. Existe um código de conduta profissional claramente definido na empresa?
Não Sim
51. Existe um código de conduta profissional claramente definido na UDSO?
Não Sim
52. Este código de conduta é o mesmo? Em caso negativo, porque eles são
diferentes?
Não Sim
53. Existe um processo formal e periódico de apresentação dos valores, princípios e
planos estratégicos da empresa a todos os funcionários? Como este processo é
apresentado aos funcionários?
54. Existe autonomia total da UDSO para lidar com as diferenças culturais locais?
Porque (não/sim)?
55. Descreva o que você considera fatores culturais chaves na sua organização
(personalidade, criatividade, etc).
56. Como estes fatores são afetados pela influência da empresa na UDSO?
57. A empresa deve fornecer treinamento para a UDSO a respeito das culturas
presentes na organização.
Discordo totalmente
Concordo Totalmente
58. É necessário que a UDSO preserve a cultura do país na qual ela esta inserida,
para um bom resultado operacional.
123
Discordo totalmente Concordo Totalmente
Confiança
[SAB99], [WHI94]
59. Da perspectiva da UDSO, a empresa demonstra confiança no trabalho da
UDSO?
Discordo totalmente
Concordo Totalmente
60. A empresa propicia frequentemente oportunidades para a integração (presencial)
entre os funcionários que atuam na UDSO.
Não Sim
61. A empresa possui funcionários terceirizados?
Não Sim
62. O clima de confiança da UDSO diminui quando o número de terceiros é maior
que o número de funcionários na empresa.
Discordo totalmente
Concordo Totalmente
63. Os funcionários da UDSO sentem confiança plena na interação com seus colegas
na empresa.
Discordo totalmente
Concordo Totalmente
64. Na minha decisão, eu não deixaria que outros membros da equipe tivessem
influência sobre problemas importantes ao projeto.
Discordo totalmente
Concordo Totalmente
65. Seria confortável em entregar para outro membro do time, se ele estivesse
preparado, a completa responsabilidade do projeto.
Discordo totalmente
Concordo Totalmente
66. Seria confortável em entregar para outro membro do time, se ele estivesse
preparado, uma atividade ou tarefa crítica ao projeto, mesmo que eu não pudesse
monitorá-lo.
Discordo totalmente
Concordo Totalmente
67. No geral as pessoas da UDSO são confiáveis.
Discordo totalmente
Concordo Totalmente
Dimensão 4 – Aspectos Técnicos
Caracterizam-se como aspectos técnicos as dimensões envolvidas na construção do produto. Todo e qualquer
trabalho que envolva pessoal altamente treinado e especializado em processos de engenharia e concepção de
produto.
Padrões
[EVA03], [YEO01]
68. Quais as certificações de qualidade que a empresa possui?
SW-CMM CMMI ITIL CobiT ISO 9001 SPICE
Outra:
69. Quais as certificações de qualidade que a UDSO possui?
SW-CMM CMMI ITIL CobiT ISO 9001 SPICE
Outra:
a) Caso o (s) certificado (s) de qualidade sejam os mesmos, eles estão no
mesmo nível entre a matriz e a UDSO?
Não Sim
70. Existe uma área ou atuação conjunta entre a empresa e as UDSOs que definem
os padrões e processos a serem utilizadas?
124
Gestão de
Conhecimento
[EVA03]
71. Existe uma base de dados com informações das competências da UDSO
disponível na empresa?
Não Sim
a) Esta base de dados é utilizada toda a vez que se inicia um novo projeto
de desenvolvimento?
Não Sim
72. A gestão de conhecimento é uma função formalmente definida na UDSO?
Não
Sim
73. A gestão de conhecimento é uma função formalmente definida na empresa?
Não
Sim
74. Existe alguma atividade ou processo para divulgar informações entre as UDSO
que auxiliem em resolução mais precisa ou veloz de problemas?
Não Sim
Projeto de
Desenvolvimento
[YEO01]
75. Quais os tipos de desenvolvimento de software existentes?
Manutenção de Software
Desenvolvimento Completo de Novas Soluções
76. O processo de desenvolvimento de software (ciclo de vida, padronização) é
único (mesmo) na empresa e na UDSO?
Não Sim
77. Qual o modelo de gerencia de projetos utilizado na UDSO?
PMI Outros
78. O padrão de gerenciamento de projetos é o mesmo utilizado na empresa e na
UDSO.
Não Sim
79. Existe um framework organizacional padronizado e formalizado entre a empresa
e UDSO para o desenvolvimento de software? Qual?
COSO ITIL CobiT-3 Próprio Não existe
80. A UDSO participa da escolha dos projetos que irá desenvolver?
Não
Sim
81. É importante a existência de mecanismos de gestão do conhecimento na UDSO.
Discordo totalmente
Concordo Totalmente
82. Deve existir uma base comum de dados entre a UDSO e a empresa, de modo que
elas possam trocar experiências sobre determinado problema, bem como
compartilhar aprendizados.
Discordo totalmente
Concordo Totalmente
Metodologia de
Desenvolvimento
[PRI03]
83. Existe alguma metodologia de desenvolvimento utilizada pela UDSO? Qual?
RUP Agile XP Outro (Qual)
84. A metodologia de desenvolvimento é a mesma em todas as unidades da
empresa?
Não Sim
85. Existe a possibilidade de que a UDSO adote uma metodologia diferente, se achar
conveniente, de acordo com o projeto?
Não Sim
86. Existe uma área ou atuação conjunta entre a empresa e as UDSOs que definem
metodologias e técnicas a serem utilizadas? Qual?
Não Sim
125
Alocação de Recursos
em Projetos
[PRI03]
87. Quem define a alocação de recursos para os projetos de desenvolvimento de
software?
Matriz UDSO Em conjunto
88. Existe um processo de alocação de recursos? Não
Sim
89. O processo de alocação de recursos é formulado com procedimentos pré-
definidos?
Não Sim
90. O processo de alocação de recursos considera outras UDSO (caso existirem)?
Não Sim
91. As UDSO são segmentadas por áreas de negócio (desenvolve sistemas para
outros setores/áreas da organização)?
Não Sim
92. As UDSO são segmentadas por tipo de sistema (manutenção, desenvolvimento
completo)?
Não Sim
Quais?
93. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para
contratar pessoal?
Total
Nenhuma
94. Qual o grau de autonomia (tomada de decisão) que a UDSO possui para
contratar a sub-contratação de terceiros para determinado projeto?
Total
Nenhuma
Dimensão 5 – Questões Gerais
Vantagens
95. Cite quais são, em sua opinião, as principais vantagens de uma UDSO, (em termos
de relacionamento com a empresa), sob os aspectos sociais, técnicos e organizacionais
em relação à empresa.
Desvantagens
96. Cite quais são, em sua opinião, as principais desvantagens de uma UDSO, (em
termos de relacionamento com a empresa), sob os aspectos sociais, técnicos e
organizacionais em relação à empresa.
126
Referências
[CAR99] Carmel, Erran. Global Software Teams – Collaborating Across
Borders and Time Zones. Prentice Hall, 1999, 269pp.
[CAR02] Carmel, Erran; Agarwal, Ritu. The Maturation of Offshore Sourcing
of Information Technology Work. MIS Quarterly Executive, vol. 1,
no. 2, 2002, 12pp (65-77).
[EVA03] Evaristo, J. R., Scudder, R., Desouza, K., Sato, O. A Dimensional
Analysis of Geographically Distributed Project Teams: A Case
Study, Journal of Engineering Technology and Management, 2003.
[ISA04] Information Systems Audit and Control Association (ISACA®).
Metrics and Organizacional Evaluation. Capturado em:
http://www.isaca.org/, Agosto de 2004.
[KHA03] Khan, Naureen; Currie, Wendy L.; Weerakkody, Vishanth; Desai,
Bhavini. Evaluating Offshore IT Outsourcing in India: Supplier
and Customer Scenarios. In: Proceedings of the 36th Hawaii
International Conference on System Sciences, IEEE Computer, 2003,
10pp.
[KIS03] Kishore, Rajiv; Rao, H. R.; Nam, K.; Rajagopalan, S.; Chaudhury, A. A
Relationship Perspective on IT Outsourcing, Communications of the
ACM, vol. 46 no 12, 2003, 6pp.
[KPM04] KPMG. Capturado em: www.kpmg.com, Agosto de 2004.
[NOL79] Nolan, R. Managing the Crisis in Data Processing. Harvard Business
Review, vol 57, no. 2, 1979, 11pp (115-126).
[PRI02] Prikladnicki, Rafael. Desenvolvimento Distribuído de Software e
Processos de Desenvolvimento de Software. Trabalho Individual II,
Mestrado em Ciência da Computação, PUCRS, 2002.
[PRI03] Prikladnicki, Rafael; Audy, Jorge Luis N. Um Modelo de Referência
para Desenvolvimento Distribuído de Software. In: WTES, 2003,
Manaus. Proceedings… Brasil, Out. 2003. 12 pp.
[SAB99] Sabherwal, Rajiv. The role of trust in outsourced development
projects. Communications of ACM. 1999. 8pp.
127
[SHA03] Sharma, Rajeev. Influence of Geographic Dispersion on Control and
Coordination Approaches for Management of Software
Development Projects. In: Ninth Americas Conference on Information
Systems, 2003, 6pp.
[SIL01] Silva, Reginaldo O. Teorias da Administração. São Paulo: Pioneira –
Thomson Learning, 2001, 1ª edição, 523pp.
[SPC01] SPC (Software Productivity Consortium) NFP. Measurement for
Distributed Teams. Guidebook, SPC-2001010-MC, version 01.00.00.
Herndon, Virginia: Software Productivity Consortium.
[SUC04] Scienton User Group Canada . ITIL, CobiT and the IT Governance.
Capturado em:
http://www.scienton.com/7799ug/images/Infosecurity/Pez-7799-Cobit-
itil-components.pdf, Agosto de 2004.
[WHI94] Whitney, John O. The Trust Factor: Liberating profits and restoring
corporate vitality. R. R. Donnelley & Sons Company, 1994, 235pp.
[YEO01] Yeo, Alvin W. Global-software development Lifecycle: An
Exploratory Study. In: Conference on Human Factors in Computing
Systems, Proceedings of the SIGCHI conference on Human factors in
computing systems (SIGCHI'01), 2001, 8pp.
128
129
APÊNDICE B – Conjunto Total de Características
Identificadas no Estudo de Caso
-A estratégia da matriz é diminuir custos e focar no
desenvolvimento;
Referenciais
Estratégicos
-A unidade não tem autonomia para captação de outros
recursos;
-As unidades são compostas por mais de 150 funcionários; Recursos
-O número de funcionários das empresas a qual as unidades
fazem parte é de no mínimo 40.000 pessoas;
-As matrizes estão localizadas em países de 1º mundo;
-As unidades estão localizadas em países em
desenvolvimento;
Distribuição das
Operações
-Os clientes estão localizados globalmente;
-A predominância é a organização por projetos, embora a
organização hierárquica também exista;
-A organização estrutural da unidade é o mesmo da matriz;
Estrutura
Organizacional
-A relação entre a unidade e a matriz é controlada por uma
entidade responsável por regular o trabalho da unidade (setor
agregado);
-Existem terceirizados trabalhando na unidade
-A utilização de terceiros de outras empresas visa suprir uma
demanda temporária de projetos;
-Não existe a sub-contratação inteira de projetos para
terceiros;
Políticas
-As políticas são definidas pelas matrizes. As unidades
podem participar destas definições;
-Existem indicadores de qualidade e de desenvolvimento
controlados pela matriz;
-Os indicadores estão ligados aos objetivos organizacionais
da unidade e da matriz
Avaliação
-Os indicadores são apresentados aos funcionários das
unidades em reuniões periódicas;
-Existe pouca autonomia das unidades para definir sua
plataforma de hardware;
-Existe certa autonomia nas unidades para definir as
linguagens de desenvolvimento;
-Existe certa autonomia nas unidades para definir suas
organizações interna (setores gerenciais);
-Existe pouca autonomia nas unidades para definir projetos
de pesquisa e desenvolvimento;
-Existe pouca autonomia das unidades para definir as
empresas terceirizadas participantes de projetos;
-Existe certa autonomia nas unidades para a contratação de
funcionários;
A
S
P
E
C
T
O
S
O
R
G
A
N
I
Z
A
C
I
O
N
A
I
S
Infra-estrutura
-Existe pouca autonomia das unidades para definirem as
ferramentas de desenvolvimento
A
S
Comunicação -Existe a comunicação face a face geralmente no inicio de
projetos;
130
-O correio eletrônico, o telefone e o chat eletrônico são os
meios de comunicação mais utilizados pelas unidades para
se comunicarem com a matriz;
-Não existe treinamento, nem um protocolo para a utilização
dos meios de comunicação;
-Atividades de integração ainda são muito esporádicas (entre
a unidade e a matriz);
-É comum a existência de um código de conduta único entre
a unidade e a empresa;
-Os funcionários participam nas decisões tomadas na
unidade;
-As unidades têm total autonomia para lidar com as
diferenças culturais;
-Criatividade e Flexibilidade foram as principais
características levantadas no estudo sobre as características
de um profissional da unidade;
-Não é constante treinamentos sobre as diferenças culturais;
Cultura
-A cultura do país onde a unidade esta localizada é
preservada
-O clima de confiança entre a unidade e a empresa é afetado
devido à distância;
-O clima interno da unidade é constantemente medido e
informado para a matriz;
-A matriz confia no trabalho da unidade. Isto é verificado
através de relatórios de indicadores;
P
E
C
T
O
S
S
O
C
I
A
S
Confiança
-Existe uma perda na confiança da unidade perante a matriz
quando o número de funcionários terceirizado atinge 2/3 do
tamanho da unidade;
-Como são unidades com grande relacionamento e
dependência das empresas matrizes, é forte a existência de
padrões;
Padrões
-É comum a existência de certificados de qualidade que criem
um método de trabalho na unidade;
-É comum a existência de uma base de dados de
competências dos funcionários. Esta base é compartilhada
com a matriz;
-Existem iniciativas esporádicas em relação à gestão do
conhecimento;
-As unidades ainda não identificam benefícios na gestão do
conhecimento (não há prática) – pouca troca;
Gestão de
Conhecimento
-A prática de gestão de conhecimento não é bem aplicada
nas unidades;
-Existe a manutenção e o desenvolvimento de aplicações;
-O processo de desenvolvimento é uniforme entre a matriz
e a empresa (quando existente);
-O PMI é amplamente utilizado como o padrão de gerência de
projetos nas unidades;
Projeto
-As unidade possuem uma pequena parcela (~30%) na
escolha dos projetos a serem desenvolvidos;
-A matriz estabeleceu as unidades com o objetivo inicial de
prestarem manutenção nos sistemas já existentes. Ao
adquirirem maior maturidade, as unidades foram aumentando
seu escopo de trabalho;
A
S
P
E
C
T
O
S
T
E
C
N
I
C
O
S
Metodologia de
Desenvolvimento
-Pequena parcela na escolha dos projetos que serão
desenvolvidos;
131
-Adoção de metodologias de desenvolvimento da indústria
(MSF e RUP). Não são utilizadas metodologias próprias;
-A metodologia é a mesma utilizada na matriz;
-A unidade não pode definir a metodologia de
desenvolvimento que melhor lhe convir;
-O trabalho de suporte de um aplicativo é feito sob a
demanda de projetos;
-A utilização de Service Levels Agreements (SLA) ainda é
pouca;
-A definição de recursos a serem utilizados nos projetos é
definida pela unidade em 70% dos projetos;
-Existe um processo formal de alocação de recursos
distribuídos;
Alocação de
Recursos
-As unidades são subdivididas em setores. Estes setores
possuem uma correspondente na matriz (trabalho em
paridade);
132
133
APÊNDICE C – Publicações
Trabalhos em eventos (Completo) – Atualizado até 30 de Junho de
2006:
PILATTI, Leonardo ; PRIKLADNICKI, Rafael ; AUDY, Jorge. Software
Configuration Management over a Global Software Development
Environment: Lessons Learned from a Case Study. In: 28th International
Conference on Software Engineering (ICSE), Shanghai 2006.
PILATTI, Leonardo; PRIKLADNICKI, Rafael; AUDY. Jorge. Global Software
Development: Standardization of the Developing Phase based on the MSF
Framework in a global CMM level 3 context. In: 17th - The Seventeenth
International Conference on Software Engineering and Knowledge Engineering
(SEKE), Taipei-Taiwan, Julho 2005.
PILATTI, Leonardo; AUDY. Jorge. Toward a Global Software Development
Maturity Model. In: 7th International Conference on Enterprise Information
Systems (ICEIS), Miami, Maio 2005.
Artigos publicados em periódicos (Completo) – Atualizado até 30 de
Junho de 2006:
EVARISTO, Roberto; AUDY, Jorge Luis Nicolas; PRIKLADNICKI, R.; PILATTI,
Leonardo; LOPES, Leandro. Innovation in Information Systems Education-
V: The Management of Outsourcing: Development of a Module with
Implications for the IT Curriculum. In: Communications Of The Association
For Information Systems, v. 15, n. 21, p. 357-368, 2005.
134
O Grupo de Pesquisa MuNDDoS na Internet
http://www.inf.pucrs.br/munddos
Esta pesquisa foi parcialmente financiada pelo Convênio Dell/PUCRS, através da Lei de
Informática Brasileira (Lei nº. 8.248/91).
Este trabalho foi digitado conforme o Guia para Apresentação de Trabalhos Acadêmicos,
Teses e Dissertações da Biblioteca Central Irmão José Otão da PUCRS, segundo a
NBR 14724 proposta pela ABNT, atualizado em 14 de setembro de 2005.
135
E
E
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
e
e
C
C
a
a
r
r
a
a
c
c
t
t
e
e
r
r
í
í
s
s
t
t
i
i
c
c
a
a
s
s
p
p
a
a
r
r
a
a
A
A
n
n
á
á
l
l
i
i
s
s
e
e
d
d
e
e
a
a
m
m
b
b
i
i
e
e
n
n
t
t
e
e
s
s
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
G
G
l
l
o
o
b
b
a
a
l
l
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
e
e
m
m
O
O
r
r
g
g
a
a
n
n
i
i
z
z
a
a
ç
ç
õ
õ
e
e
s
s
O
O
f
f
f
f
s
s
h
h
o
o
r
r
e
e
I
I
n
n
s
s
o
o
u
u
r
r
c
c
i
i
n
n
g
g
Espaço reservado para anotações dos membros da Comissão Examinadora
136
E
E
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
e
e
C
C
a
a
r
r
a
a
c
c
t
t
e
e
r
r
í
í
s
s
t
t
i
i
c
c
a
a
s
s
p
p
a
a
r
r
a
a
A
A
n
n
á
á
l
l
i
i
s
s
e
e
d
d
e
e
a
a
m
m
b
b
i
i
e
e
n
n
t
t
e
e
s
s
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
G
G
l
l
o
o
b
b
a
a
l
l
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
e
e
m
m
O
O
r
r
g
g
a
a
n
n
i
i
z
z
a
a
ç
ç
õ
õ
e
e
s
s
O
O
f
f
f
f
s
s
h
h
o
o
r
r
e
e
I
I
n
n
s
s
o
o
u
u
r
r
c
c
i
i
n
n
g
g
Espaço reservado para anotações dos membros da Comissão Examinadora
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
