FACULDADE RUY BARBOSA

ALLAN AZEVEDO TEIXEIRA DA ROCHA

UMA ALTERNATIVA PARA A ORGANIZAÇÃO DA PRODUÇÃO EM

FÁBRICAS DE SOFTWARE

SALVADOR
2005
 FACULDADE RUY BARBOSA
ALLAN AZEVEDO TEIXEIRA DA ROCHA

UMA ALTERNATIVA PARA A ORGANIZAÇÃO DA PRODUÇÃO EM

FÁBRICAS DE SOFTWARE

Monografia de conclusão de curso apresentada

para a disciplina Ênfase em Conhecimento
Optativo III, do Curso de Ciência da
Computação, da Faculdade Ruy Barbosa, sob
orientação do Prof. Jaime Gama.

SALVADOR
2005

1
Aos meus avós maternos,
símbolos de compromisso e
dedicação, pelo conjunto de
valores éticos e morais que me
transmitiram ao longo da vida.

2
 AGRADECIMENTOS

A Profª Rita Suzana, pela importante contribuição no direcionamento

metodológico desta pesquisa.

Ao Profº Eduardo Jorge, pelas idéias inovadoras, estímulo e confiança

transmitidos, sem os quais a realização deste trabalho não seria possível.

Ao Profº Jaime Gama, meu orientador e mentor, pelo apoio e dedicação com os
quais sempre pude contar enquanto trabalhamos juntos.

3
Não escolhi ser um homem comum. É
meu direito ser diferente, ser
singular, incomum, desenvolver os
talentos que Deus me deu. Isto é o
que eu sou.
Bertold Brecht

4
 RESUMO

Neste trabalho, foram analisadas duas formas de organização da produção comumente

adotadas em fábricas de software: as organizações por equipes de projeto e por células de
produção. Na elaboração do trabalho, foram confrontados os conceitos das duas organizações
em questão, identificando e analisando suas características, de forma a determinar seus pontos
positivos e negativos, assim como as situações às quais cada modelo está mais adequado. A
pesquisa propõe uma forma alternativa de organização da produção, chamada de
“Organização Híbrida da Produção”, baseada nos dois modelos originais, objetivando
minimizar os pontos negativos e potencializar as vantagens inerentes a cada um deles. A
partir do quadro traçado na fundamentação teórica, a análise concentrou-se em um
experimento prático, cujo objetivo foi verificar a efetividade da formulação proposta, ou seja,
determinar se sua implantação e utilização são factíveis. O interesse em um trabalho desta
natureza foi motivado pela abordagem emergente da aplicação dos conceitos de fábricas de
software pelas empresas desenvolvedoras no Brasil e no mundo. A pesquisa suscita a reflexão
e análise sobre as formas de organização da produção adotadas pelas fábricas de software
atualmente, no sentido de apontar novas soluções que possam ser adotadas na estruturação
dos times de desenvolvimento de software.

5
 LISTA DE ILUSTRAÇÕES

Figura 1 – Organograma estruturado por projetos....................................................................16

Figura 2 – Organograma de uma organização funcional..........................................................17
Figura 3 – Organização da produção da Fábrica de Software ..................................................18
Figura 4 – Organização Híbrida da Produção ..........................................................................31
Figura 5 – Papéis Funcionais em um Processo de Desenvolvimento de Software...................35
Figura 6 – Utilização das células de produção por uma equipe de projeto ..............................37
Figura 7 – Processo de Desenvolvimento Aplicado.................................................................44
Figura 8 – Organização da Produção Adotada .........................................................................46
Figura 9 – Variação do Tamanho do Time de Desenvolvimento.............................................51

6
 LISTA DE TABELAS

Tabela 1 – Comparação entre as Organizações por Células de Produção e por Equipes de

Projeto ................................................................................................................................25
Tabela 2 – Quadro comparativo das estruturas organizacionais ..............................................26
Tabela 3 – Proposta de um Conjunto de Papéis Funcionais.....................................................34
Tabela 4 – Papéis Funcionais dos Colaboradores ....................................................................39
Tabela 5 – Composição das equipes de projeto........................................................................45
Tabela 6 – Composição das Células de Produção ....................................................................45
Tabela 7 – Sazonalidade do Time de Desenvolvimento...........................................................51
Tabela 8 – Síntese dos resultados da análise da OHP ..............................................................55

7
 SUMÁRIO

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

2 ANÁLISE TEÓRICA DOS ARRANJOS PRODUTIVOS PARA A CONSTRUÇÃO

DE SOFTWARE......................................................................................................................13
2.1 Cenário da Engenharia de Software ................................................................................13
2.2 Definição de Fábrica de Software ...................................................................................14
2.2.1 Principais Tipos de Fábricas de Software .................................................................15
2.3 Organização da Produção por Equipes de Projeto e por Células de Produção ...............15
2.4 Análise da Organização da Produção por Células de Produção e por Equipes de Projeto
...............................................................................................................................................18
2.4.1 Aspecto: Definição do Perfil Adequado dos Colaboradores Envolvidos .................20
2.4.2 Aspecto: Tamanho da Equipe Adequado às Necessidades do Projeto .....................21
2.4.3 Aspecto: Nível de Comunicação Entre os Colaboradores Envolvidos.....................22
2.4.4 Aspecto: Comprometimento dos Colaboradores ......................................................23
2.4.5 Aspecto: Eficiência no Uso dos Recursos Humanos e Materiais .............................24
2.5 Estrutura Matriz Balanceada ...........................................................................................25
2.6 Trabalhos Correlatos .......................................................................................................28
3 ORGANIZAÇÃO HÍBRIDA DA PRODUÇÃO...............................................................30
3.1 As Equipes de Projeto .....................................................................................................31
3.2 As Células de Produção...................................................................................................32
3.3 Papéis e Responsabilidades.............................................................................................33
3.4 Processo Produtivo..........................................................................................................35
4 ESTUDO DE CASO ............................................................................................................39
4.1 Cenário ............................................................................................................................39
4.2 Caracterização dos Projetos Desenvolvidos....................................................................40
4.2.1 Projeto 1: Desenvolvimento do Sistema CotaOn......................................................40
4.2.2 Projeto 2: Desenvolvimento do Sistema Rastro........................................................40
4.3 Processo de Desenvolvimento Aplicado .........................................................................42
4.4 Organização da Produção Adotada .................................................................................44
4.5 Atribuições e Responsabilidades Estabelecidas Para os Elementos da OHP..................46
4.5.1 Equipes de Projeto ....................................................................................................47
4.5.2 Célula de Infra-estrutura ...........................................................................................47
4.5.3 Célula de Elementos de Aplicação ...........................................................................48
4.5.4 Célula de Elementos de Interface .............................................................................48
4.5.5 Célula de Testes e Controle de Qualidade ................................................................49
4.6 Resultados Obtidos em Relação aos Aspectos Comparativos Analisados......................49
4.6.1 Aspecto: Definição do Perfil Adequado dos Colaboradores Envolvidos .................49
4.6.2 Aspecto: Tamanho da Equipe Adequado às Necessidades do Projeto .....................50
4.6.3 Aspecto: Nível de Comunicação Entre os Colaboradores Envolvidos.....................52
4.6.4 Aspecto: Comprometimento dos Colaboradores ......................................................53
4.6.5 Aspecto: Eficiência no Uso dos Recursos Humanos e Materiais .............................54
4.7 Análise dos Resultados....................................................................................................55
4.7.1 Considerações Adicionais Sobre os Resultados Obtidos..........................................56
4.8 Limitações do Experimento ............................................................................................56

8
5 CONCLUSÃO......................................................................................................................58

REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................61

9
1 INTRODUÇÃO

Ao longo do tempo, os sistemas informatizados têm conquistado uma importância

cada vez maior no mundo. Soluções de software fazem parte de atividades críticas das mais
diversas áreas da atuação humana, criando, assim, uma dependência cada vez maior do
homem em relação aos sistemas de informática. Contudo, os projetos de software apresentam,
sistematicamente, falhas que não só comprometem a qualidade dos produtos finais, como
reduzem a produtividade das organizações (MACHADO, 2003).
O cenário atual da produção de software está cada vez mais competitivo. Para
garantir participação no mercado, as empresas estão buscando maneiras de solucionar os
problemas que afligem o desenvolvimento de software, com o objetivo de aumentar a
produtividade, reduzir custos, melhorar a qualidade do produto final e fortalecer o grau de
eficiência e controle, tornando-se mais competitivas (BARTIÉ, 2002; FERNANDES, 2004).
Vários padrões, normas e metodologias vêm sendo propostos com o intuito de
tornar o desenvolvimento de software mais produtivo e confiável. No entanto, verifica-se que
a adoção de modelos de gestão da qualidade, a implantação de metodologias de
desenvolvimento e a utilização de práticas de gestão de processos alcançam resultados
limitados se não forem aderentes aos conceitos da engenharia de produção (FERNANDES,
2004). Aspectos de planejamento e controle de produção, inspirados nas experiências da
atividade fabril e industrial, estão sendo aplicados no setor de desenvolvimento de sistemas.
Para resultados efetivos, uma empresa que produz software deve ser encarada como uma
fábrica de serviços, considerando, em suas iniciativas de melhoria e controle dos processos
produtivos, aspectos como a estrutura organizacional, a gestão de múltiplas demandas de
projetos e a produção em larga escala (FERNANDES, 2004).
Em decorrência disso, diversas empresas de software têm-se organizado conforme
os conceitos básicos e consolidados das fábricas e indústrias, em busca de maior controle de
processos, produtos e funções. Estão sendo adaptadas e aplicadas idéias como divisão de
tarefas, padronização de componentes e processos, especialização do trabalho, formalização
de métodos e documentação. Dessa forma, empresas que adotam determinados elementos
provindos da engenharia industrial e de operações e escolhem a produção de software como
atividade fim são chamadas de “fábricas de software” (TARTARELLI; et al., 2003;
FERNANDES, 2004).

10
 O setor produtivo das fábricas de software pode ser organizado de algumas formas
distintas. Duas destas formas são a estruturação por equipes de projetos, onde é montado um
time de desenvolvimento específico para cada projeto; e a organização por células de
produção, baseada em uma linha de produção, onde as células atendem às demandas de
diversos projetos simultaneamente. No entanto, qualquer que seja a organização da produção
adotada, ela apresenta pontos positivos e negativos, que privilegiam ou dificultam cada
aspecto do processo de construção de software (MEDEIROS, 2004).
O objetivo deste trabalho é especificar uma forma alternativa de organização da
produção para fábricas de software, baseada nas estruturações por equipes de projeto e por
células de produção. Esta nova estrutura, chamada de “Organização Híbrida da Produção”,
combina aspectos de cada um dos dois modelos originais, objetivando minimizar os pontos
negativos inerentes a cada um deles isoladamente e potencializar suas vantagens. Esse método
de combinação de características de dois modelos distintos, com o objetivo de propor uma
formulação híbrida, foi inspirado em Magalhães e Maciel (2003), onde as autoras
combinaram elementos de duas metodologias de desenvolvimento de software, gerando,
posteriormente, uma metodologia híbrida, chamada de RUXP1. Neste trabalho esta técnica é
estendida e aplicada para estruturas organizacionais.
A relevância do trabalho está no oferecimento de mais uma forma de organização
da produção que pode ser utilizada pelas empresas de desenvolvimento. A especificação de
uma estrutura produtiva opcional permite que as fábricas de software avaliem suas vantagens
e desvantagens e a adotem, caso a considerem adequada às suas necessidades. Além disso, o
trabalho avalia se é possível combinar aspectos da organização por equipes de projeto e por
células de produção para construtores de software, como forma de obter maior adequação à
realidade da empresa. Por fim, outra contribuição do projeto está na própria natureza do
estudo, que, ao contrário de focar na metodologia de desenvolvimento, constantemente
abordada em vários trabalhos ao longo das últimas décadas, analisa a relevância da
organização da produção da fábrica de software na sua operação e geração dos seus produtos.
Para atingir os resultados esperados, inicialmente são determinados quais aspectos
das formas de organização da produção serão analisados neste trabalho, de maneira a atender
ao objetivo e escopo do projeto. Em seguida, é feita uma análise, baseada no referencial
teórico existente, das formas de organização tradicionais de fábrica de software, com base nos
aspectos escolhidos, identificando suas vantagens, desvantagens e situações às quais mais se
adaptam. Prosseguindo, é especificada uma nova forma de organização, a Organização

11
Híbrida da Produção, baseada nos modelos analisados, de forma a minimizar os problemas
identificados e potencializar as vantagens. Após essa etapa, é realizado um estudo de caso que
visa verificar se sua utilização é factível de implantação e utilização.
O trabalho está organizado conforme descrito a seguir. O capítulo 2 apresenta
uma análise dos modelos de organização por células de produção e por equipes de projeto,
com base nos critérios considerados relevantes para este trabalho. O capítulo 3 traz a
especificação da organização proposta, a Organização Híbrida da Produção. O capítulo 4
descreve o estudo de caso realizado em um centro de pesquisa que atua com desenvolvimento
de software. E, por fim, o capítulo 5 representa a seção destinada às conclusões do trabalho.

1
Rational Unified eXtreme Process (MAGALHÃES; MACIEL, 2003)

12
2 ANÁLISE TEÓRICA DOS ARRANJOS PRODUTIVOS PARA A
CONSTRUÇÃO DE SOFTWARE

2.1 Cenário da Engenharia de Software

Os sistemas informatizados têm tido cada vez mais importância na sociedade

atual. É possível encontrar soluções de software em quase todas as áreas de domínio do
conhecimento humano, seja como elemento principal ou como componente secundário de
uma estrutura maior. Estima-se que, se os principais sistemas de uso global deixarem de
funcionar, 40% de toda a população mundial poderá sofrer as conseqüências. Em
contrapartida, apesar de sua fundamental importância, os sistemas informatizados apresentam,
sistematicamente, falhas em seus projetos, que afetam não só a produtividade dos
desenvolvedores, como o atendimento aos requisitos, custos e prazos estabelecidos (CURTIS;
STATZ, 1996; PRESSMAN, 1997).
Nos anos de 1992 e 1993, mais de 50% dos projetos de software nos Estados
Unidos estouraram em mais de 50% o cronograma previsto, e mais de 60% dos projetos
pesquisados já estavam atrasados (CURTIS; STATZ, 1996). Em 1995, as empresas
americanas gastaram mais de 81 milhões de dólares em projetos que foram cancelados. Dos
projetos estudados, 31% sofreram cancelamento antes de serem finalizados e 53%
ultrapassaram em mais da metade os custos previstos (STANDISH GROUP, 1995).
Durante as duas últimas décadas, estudos em todo o mundo têm abordado os
principais problemas nos projetos de desenvolvimento de software (CURTIS; STATZ, 1996).
Na tentativa de melhorar esse processo, vários padrões, modelos e normas têm sido propostos
por universidades, institutos de padronização e centros de pesquisa em todo o mundo. Ao
longo dos anos, esses modelos vêm sendo adotados pelas empresas de software, como uma
tentativa de melhorar o seu processo produtivo (CMU-SEI, 1993).
Podem-se citar as Normas ISO/IEC 9000-3:1993 – Normas de Gestão da
Qualidade e Garantia da Qualidade – Parte 3: Diretrizes para aplicação da NBR 9001 ao
desenvolvimento, fornecimento e manutenção de software, que propõem uma interpretação da
Norma ISO 9001 para a aplicação no processo de software; ISO/IEC 12.207 – Tecnologia de
Informação – Processos de ciclo de vida de software, que estabelece um conjunto de diretrizes
para os processos de ciclo de vida de software; ISO/IEC 15.504 – Software Process (SPICE),

13
que propõe um modelo de avaliação de melhoria do processo de software; os Modelos CMM
(Capability Maturity Model)2; CMMI (Capability Maturity Model Integration)3 etc.
Modelos não ligados diretamente ao processo de software também têm sido
utilizados na gerência de projetos de desenvolvimento, como a Norma ISO/IEC 9001:2000 –
Sistemas de Gestão da Qualidade – Requisitos, que apresenta um modelo descritivo para a
montagem de um Sistema de Gestão da Qualidade para a organização; o PMBOK 2000
(Project Management Body of Knowledge) do PMI (Project Management Institute)4, que
propõe um modelo para a gerência de projetos de qualquer natureza, dentre outros.
Atualmente, o IEEE (Institute of Electrical and Electronics Engineers)5
disponibilizou o SWEBOK (Software Engineering Body of Knowledge) (SWEBOK, 2004),
que está em sua terceira versão, Ironman Version, e tem o objetivo de ser um guia genérico
para práticas da Engenharia de Software.

2.2 Definição de Fábrica de Software

De acordo com Fernandes (2004), a expressão “fábrica de software” se difundiu

pelo mundo em meados da década de 80. Já no Brasil, esse termo começou a ser aplicado a
partir da década de 90, por empresas de prestação de serviços em tecnologia da informação.
Apesar do conceito de fábrica de software ter diferentes conotações, neste
trabalho será seguida a definição proposta por Fernandes (2004). Segundo o autor, “um
núcleo de desenvolvimento tradicional sem determinados tipos de atributos, oriundos da
engenharia industrial e de operações, não se configura com uma fábrica de software”. Para
ser considerada como tal, a empresa de desenvolvimento deve ter o seu processo de
construção de software baseado nos conceitos de uma fábrica industrial, como a existência de
um processo definido e padrão para a realização do seu produto; utilização de ordem de
serviço padronizada; existência de um processo para o planejamento e controle da produção;
construção dos produtos utilizando métodos, técnicas e ferramentas padronizadas; existência
de processo de garantia da qualidade etc.

2
www.sei.cmu.edu/cmm/
3
www.sei.cmu.edu/cmmi/
4
www.pmi.org
5
www.ieee.org

14
 Em resumo, Fernandes (2004) define fábrica de software da seguinte forma:
Um processo estruturado, controlado e melhorado de forma contínua,
considerando abordagens de engenharia industrial, orientado para o
atendimento a múltiplas demandas de natureza e escopo distintas, visando à
geração de produtos de software, conforme os requerimentos documentados
dos usuários e/ou clientes, da forma mais produtiva e econômica possível.

2.2.1 Principais Tipos de Fábricas de Software

As fábricas de software podem se dividir, basicamente, em dois tipos distintos:

fábrica de programas e fábrica de sistemas (FERNANDES, 2004). A diferença fundamental
entre eles reside no escopo de atuação de cada um.
As fábricas de programas caracterizam-se por atuarem em apenas uma porção do
processo produtivo do software. Nesse caso, o insumo inicial é uma ordem de serviço
acompanhada de toda a especificação do programa a ser desenvolvido. Sendo assim, as etapas
de modelagem do negócio, análise e projeto do sistema já foram feitas, cabendo à fábrica a
execução das etapas de construção, testes e ajustes.
As fábricas de sistemas, também conhecidas por “fábricas de projetos”, por sua
vez, têm como entrada uma ordem de serviço acompanhada apenas da declaração de escopo
do sistema a ser produzido. Nesta situação, a fábrica deve realizar todas as etapas que
compõem o desenvolvimento do produto: análise, elaboração do projeto, construção, testes,
instalação, implantação e ajustes. Nota-se que a fábrica de sistemas representa uma solução
mais ampla do que a fábrica de programas, estando esta contida naquela.

2.3 Organização da Produção por Equipes de Projeto e por Células de

Produção

Dentre as formas de organização da produção que as empresas desenvolvedoras

de software podem adotar, estão a estruturação por equipes de projetos e por células de
produção.

15
 A organização da produção por equipes de projeto caracteriza-se pelo
agrupamento dos colaboradores em função de um determinado objetivo. Cada projeto6 possui
metas bem definidas, assim como o seu responsável, o Gerente de Projeto, e sua equipe
executora. Essa estrutura é mantida desde o início até o fim (ou interrupção) do
empreendimento7. É possível, porém não muito comum, que, ao longo das fases do projeto,
alguns colaboradores entrem ou saiam da equipe, de acordo com a demanda de trabalho.
Existe a possibilidade, também, de que um colaborador atue em mais de uma equipe de
projeto, se assim permitir a sua disponibilidade (VASCONCELLOS; HEMSLEY, 1997).
A Figura 1 apresenta um típico organograma de uma organização estruturada por
projetos. É possível verificar que cada equipe de projetos possui seu próprio Gerente de
Projeto. Eles estão no mesmo nível hierárquico entre si, e todos estão subordinados,
diretamente, à alta Direção Executiva (CEO – Chief Executive Officer) (HELDMAN, 2005).

CEO

Gerente de Gerente de Gerente de Gerente de Gerente de

Projeto Projeto Projeto Projeto Projeto

Membros/ Membros/ Membros/ Membros/ Membros/

funcionários funcionários funcionários funcionários funcionários
da equipe da equipe da equipe da equipe da equipe
do projeto do projeto do projeto do projeto do projeto

Figura 1 – Organograma estruturado por projetos

Fonte: HELDMAN, 2005, p. 16

A organização por células é mais comum em fábricas de software (FERNANDES,

2004). Neste arranjo, cada célula de produção é montada de acordo com as características das
atividades a serem executadas e com o tipo de serviço a ser realizado (FERNANDES, 2000).
Como exemplo, podem-se citar os seguintes tipos de células: célula de testes, célula de
componentes web, célula de infra-estrutura, célula de banco de dados, célula de componentes
de interface. Abstraindo-se a disposição física desta estruturação, e considerando a forma de
realização dos serviços, o arranjo celular guarda forte semelhança com a tradicional

6
“Um projeto é um empreendimento temporário com o objetivo de criar um produto ou serviço único”.
(PMBOK 2000)
7
Ao longo do trabalho o termo “empreendimento” será utilizado como sinônimo da expressão “projeto”.

16
departamentalização funcional. Esse tipo de organização caracteriza-se, também, pelo
agrupamento das pessoas de acordo com a área de conhecimento e as atividades a serem
realizadas (VASCONCELLOS; HEMSLEY, 1997). As características ligadas à organização
do trabalho da estruturação por células de produção, portanto, podem ser, na sua maioria,
mapeadas a partir do estudo dos aspectos da departamentalização funcional. Para evitar
equívocos, é importante ressaltar que organização da produção em células de produção não
guarda relação direta com a Estrutura Organizacional Celular8, cujo estudo foge ao escopo
deste trabalho.
A Figura 2 apresenta um típico organograma de uma organização estruturada por
departamentalização funcional. É possível verificar que cada unidade foi concebida conforme
a similaridade dos seus processos e área de atuação. As áreas possuem o mesmo nível
hierárquico entre si, e todas estão subordinados, diretamente, à alta Direção Executiva (CEO –
Chief Executive Officer) (HELDMAN, 2005).

CEO

Recursos Finanças Marketing Tecnologia Produção

Humanos Informação

Pessoal Pessoal Pessoal Pessoal Pessoal

Efetivo Efetivo Efetivo Efetivo Efetivo

Figura 2 – Organograma de uma organização funcional

Fonte: HELDMAN, 2005, p. 13

Estendendo-se esta estruturação para o ambiente de uma fábrica de software,

pode-se verificar, na Figura 3, a existência de células de produção dedicadas a determinadas
etapas do processo produtivo ou área de domínio do desenvolvimento de sistemas, seguindo,
portanto, as premissas da departamentalização funcional.

8
A Estrutura Organizacional Celular é uma forma de organização empresarial, proposta por Shannon, tem como
principais características a ausência quase que completa de uma estruturação formalizada e grande flexibilidade
de comunicação. Esta estruturação só é recomendável em pequenas empresas, devido à alta informalidade do
modelo (Vasconcellos; Hemsley, 1997).

17
 Figura 3 – Organização da produção da Fábrica de Software
Fonte: UNITECH, 2004

2.4 Análise da Organização da Produção por Células de Produção e por

Equipes de Projeto

Diversos teóricos têm estudado a influência da organização da produção e seus

efeitos na produtividade das empresas e efetividade dos grupos (GHEZZI, 1991). A vasta
literatura acerca do assunto, apresentando estudos teóricos e experimentos práticos, oferece
embasamento para que empresas em todo o mundo busquem alternativas de aumento de
produtividade através de reorganizações em seus arranjos produtivos.
Considerando-se que apenas as estruturações por equipes de projetos e por células
de produção são englobadas pelo escopo do presente trabalho, é feita uma análise comparativa
entre estes dois modelos, baseada em referencial teórico, de modo a determinar suas
vantagens, desvantagens e situações às quais cada modelo está mais adequado.
Para uma análise desta natureza, é necessário que sejam delimitados os aspectos
que serão levados em consideração, tendo em vista que é possível estabelecer uma abordagem
comparativa sob diversas óticas, como otimização da mão-de-obra, otimização dos
equipamentos, satisfação dos colaboradores, cumprimento dos termos acordados com o
cliente etc (VASCONCELLOS; HEMSLEY, 1997).

18
 Vasconcellos e Hemsley (1997) elegem alguns fatores de comparação9 entre a
organização por equipes de projetos e a estruturação funcional – mapeada na organização por
células de produção, conforme proposto na seção anterior. Os aspectos apontados são:
abrangência, capacitação técnica da instituição, qualidade dos projetos, cumprimento dos
prazos dos projetos, satisfação do colaborador, atendimento ao cliente, uso de recursos,
existência de um único responsável pelo projeto e esforço de administração.
O interesse do presente trabalho, no entanto, restringe-se à organização da
produção em empresas de desenvolvimento de sistemas. As características peculiares do
software, que o distinguem dos demais artefatos industrializados e manufaturados produzidos
pelo homem, geram a necessidade de uma análise diferenciada para as organizações deste
ramo (GHEZZI, 1991).
Dessa forma, o estudo realizado concentrou-se nos aspectos apontados, em
concordância, por Ghezzi (1991) e Sommerville (2000), como relevantes para a análise da
organização da produção em empresas de desenvolvimento.
Os aspectos ressaltados por ambos os autores são os seguintes:

a) definição do perfil adequado dos colaboradores envolvidos;

b) tamanho da equipe adequado às necessidades do projeto;
c) nível de comunicação entre os colaboradores envolvidos;
d) comprometimento dos colaboradores.

Por ser um elemento de alta criticidade para qualquer tipo de organização, é

analisado também, juntamente com os fatores supracitados, um aspecto apontado por
Vasconcellos e Hemsley (1997):

e) eficiência no uso dos recursos humanos e materiais.

A partir dos aspectos apontados pelos três autores, é feita uma análise da
efetividade das formas de organização da produção por células (através do mapeamento na
departamentalização funcional, proposto na seção anterior) e por projetos, em relação ao

9
Os motivadores que levaram a Vasconcellos e Hemsley (1997) a elegerem estes fatores de comparação, bem
como os aspectos que compõem cada um deles, podem ser encontrados em (Vasconcellos; Hemsley, 1997, p. 30-
41).

19
desenvolvimento de software, observando as vantagens e desvantagens de cada modelo para
cada aspecto considerado.

2.4.1 Aspecto: Definição do Perfil Adequado dos Colaboradores Envolvidos

A forma de organização da produção deve ser flexível o suficiente para permitir

que os funcionários que irão atuar no projeto tenham o perfil profissional adequado às
necessidades do empreendimento. É importante que os colaboradores selecionados tenham as
habilidades técnicas requeridas para a realização das atividades e que tenham, também, estilos
de personalidade diversificados e complementares, como a combinação de pessoas
comunicativas e introvertidas, tecnicamente habilidosas e com perfil gerencial etc
(SOMMERVILLE, 2000).
O arranjo por células de produção permite que o coordenador possa alocar as
pessoas e distribuir as atividades de acordo com as diferentes capacidades, perfil profissional,
interesses individuais e necessidades do projeto. Isso garante maior flexibilidade na seleção
dos colaboradores que irão atuar em cada projeto (VASCONCELLOS; HEMSLEY, 1997).
A estruturação em equipes de projeto, por sua vez, não possibilita que isso seja
feito com grande intensidade, pois manter todos profissionais necessários, com os diversos
perfis demandados pelas necessidades do projeto, geraria uma capacidade ociosa
insustentável. Sendo assim, o gerente de projeto tem tendência a montar a equipe com um
número reduzido de profissionais, porém com perfis generalistas e diversificados
(VASCONCELLOS; HEMSLEY, 1997), o que não garante que as necessidades do projeto
em relação aos perfis dos profissionais sejam atendidas na sua plenitude.
É possível concluir, portanto, que o arranjo por células de produção é mais
adequado à definição dos perfis dos colaboradores que atuarão no desenvolvimento de um
projeto de software.

20
2.4.2 Aspecto: Tamanho da Equipe Adequado às Necessidades do Projeto

O tamanho ideal que um grupo deve ter para realizar um determinado processo
depende, diretamente, do volume e complexidade das atividades envolvidas. Tarefas
volumosas e complexas geralmente demandam grande força de trabalho e troca de
experiências entre os colaboradores. Neste caso, um grupo de funcionários numeroso é mais
adequado à realização do processo. Em contrapartida, times grandes geram uma sobrecarga
significativa de atividades de gerenciamento e controle das pessoas e tarefas. Os processos
pequenos e simples, por sua vez, são bem atendidos por um grupo reduzido de pessoas, capaz
de promover maior coesão na equipe e menor sobrecarga de gerenciamento e comunicação. A
solução ideal, portanto, é possuir uma forma de organização da produção que possa adequar-
se à necessidade momentânea de cada processo, de utilizar um grupo grande de pessoas ou
um time reduzido (GHEZZI, 1991).
A estruturação por células promove flexibilidade suficiente para ajustar o tamanho
do grupo de colaboradores que está desenvolvendo uma determinada atividade, de acordo
com as necessidades do momento. Essa estrutura, cujas células são compostas por um número
variado de funcionários, permite que, dentro de uma mesma célula, a quantidade de pessoas
alocadas em uma determinada tarefa possa ser ajustada pelo coordenador. Isso é possível
porque como os perfis dos membros de uma célula são parecidos, assim como as atividades
desenvolvidas por eles, a migração de colaboradores entre as atividades pode ser feita com
baixas demandas de treinamento e adaptação. Sendo assim, é possível envolver a quantidade
adequada de colaboradores, de acordo com as necessidades momentâneas do projeto
(VASCONCELLOS; HEMSLEY, 1997).
Contrapondo-se a este fato, o arranjo por equipes de projeto apresenta menor
flexibilidade de ajuste do tamanho do grupo. A equipe, na maioria das vezes, é montada nas
fases iniciais do projeto. Nessas circunstâncias, o ato de alocar pessoas extras em um
determinado período do projeto, ou migrar os colaboradores para outro projeto distinto é de
impacto significativo na organização, pois depende da disponibilidade dos recursos de outros
projetos e entendimento entre gerentes e coordenadores de área. O tamanho do time, portanto,
é, geralmente, mantido constante ao longo de todo o projeto, independente das demandas e
necessidades das atividades momentâneas. (VASCONCELLOS; HEMSLEY, 1997).

21
 Dessa forma, percebe-se que a estruturação por células de produção garante maior
adequação na determinação do tamanho dos grupos de trabalho do que o arranjo por equipes
de projeto.

2.4.3 Aspecto: Nível de Comunicação Entre os Colaboradores Envolvidos

A depender do processo que esteja sendo executado, o nível ideal de comunicação

entre os funcionários que estão trabalhando nele pode variar bastante. Processos comuns,
compostos por atividades conhecidas ou rotineiras (como a implementação de interfaces de
cadastro, por exemplo), demandam um baixo nível de interação entre os funcionários
envolvidos. Em casos como esse, um alto nível de interação entre os colaboradores é
indesejado, podendo até gerar atrasos na realização das atividades. Por outro lado, tarefas que
não estejam bem especificadas ou não sejam rotineiras, como a implementação de uma regra
específica do negócio do cliente, demandam uma grande interação entre os envolvidos, pois
as informações necessárias à realização da atividade precisam ser coletadas (GHEZZI, 1991).
De qualquer sorte, seja qual for o nível ideal de comunicação, ela deve garantir a troca de
informações acerca da situação atual do trabalho de cada membro do grupo, das decisões do
projeto e das mudanças de plano ocorridas (SOMMERVILLE, 2000).
Na organização por células de produção, a comunicação entre colaboradores de
diferentes células é dificultada. Isso ocorre porque, como cada célula possui seu próprio
coordenador, a transferência de informações entre células se dá, geralmente, através dele, o
que dificulta o processo. Além disso, este arranjo não garante a existência de um responsável
que tenha a visão completa e panorâmica do projeto, capaz de prover informações precisas a
quem quer que seja, acerca da situação exata do projeto (VASCONCELLOS; HEMSLEY,
1997). Considerando a proposta de Ghezzi (1991) para a garantia do nível adequado da
comunicação, verifica-se que essa organização é mais indicada às atividades que demandam
baixa comunicação entre os executantes.
A estruturação por equipes de projetos, por sua vez, permite que as decisões do
projeto sejam rapidamente divulgadas a todos os colaboradores, independente de sua área de
atuação, sem a necessidade de reuniões com coordenadores de células. A comunicação entre
todos os colaboradores é direta. Além disso, nessa estruturação, na qual a equipe e o projeto

22
estão sob a coordenação de um único responsável, é possível obter-se informações acerca da
situação atual do projeto com uma única pessoa (VASCONCELLOS; HEMSLEY, 1997).
Considerando a proposta de Ghezzi (1991) para a garantia do nível adequado da
comunicação, verifica-se que essa organização é mais indicada às atividades que demandam
alta comunicação entre os executantes.
Com base na análise, é possível concluir que a organização por equipes de projeto
promove uma comunicação mais efetiva entre os colaboradores. No entanto, observa-se que
cada uma das formas de organização da produção em estudo é mais adequada ao nível de
comunicação e interação requerido no momento. Para atividades que demandam baixa
comunicação, o arranjo por células é mais efetivo. Por outro lado, para os processos que
necessitam alta interação entre os funcionários, a estruturação por equipes de projetos é
preferível.

2.4.4 Aspecto: Comprometimento dos Colaboradores

Um importante objetivo da organização da produção é facilitar a cooperação dos

funcionários para alcançar as metas previstas. Ela deve estimular o envolvimento dos
funcionários de tal forma que eles se sintam responsáveis pelo sucesso ou fracasso de todo o
time no alcance dos objetivos e metas traçados. Os funcionários devem entender que
resultados podem ser potencializados se houver esforço e comprometimento de toda a equipe
(GHEZZI, 1991; SOMMERVILLE, 2000).
A estruturação por células de produção deixa a desejar neste critério, já que as
células são compartilhadas por projetos de toda a empresa e a aproximação de cada
funcionário com um projeto específico é menor. Nesse tipo de arranjo é mais difícil de
conseguir um entendimento da responsabilidade de cada colaborador por um determinado
processo, já que sua contribuição acontece em apenas uma parcela dele (VASCONCELLOS;
HEMSLEY, 1997).
Já na organização por equipes de projeto, o comprometimento dos funcionários
em relação aos resultados é mais evidente. Isso ocorre porque os colaboradores estão
diretamente ligados a determinados projetos e são considerados os responsáveis diretos por
eles desde a montagem da equipe até o fim do projeto. Dessa forma, a intensidade e

23
importância da contribuição do funcionário tornam-se mais evidentes. Considerando-se o
aspecto em questão, portanto, entende-se que esta forma de organização da produção garante
resultados mais efetivos (VASCONCELLOS; HEMSLEY, 1997).

2.4.5 Aspecto: Eficiência no Uso dos Recursos Humanos e Materiais

A otimização do uso dos recursos (humanos e materiais) disponíveis é

fundamental para qualquer tipo de organização. Empresas que desenvolvem sistemas,
portanto, também precisam maximizar o aproveitamento dos seus recursos, em especial, dos
recursos humanos. Isso ocorre porque, neste ramo de atividade, os recursos humanos
representam, na maioria das vezes, um montante significativo de todo o custo de um projeto
de software.
Na estruturação por células, o tempo e habilidades dos colaboradores podem ser
aproveitados de forma efetiva. O fato de uma célula ser compartilhada por vários projetos,
permite que cada colaborador seja alocado nos empreendimentos de acordo com as
necessidades. Dessa forma, o coordenador da célula pode otimizar o tempo de cada
funcionário e maximizar o aproveitamento das capacidades individuais. Grandes demandas de
trabalho, assim como a capacidade ociosa, podem ser tratadas através da realocação de
pessoal dos projetos que têm folga para os que estão em atraso e vice-versa
(VASCONCELLOS; HEMSLEY, 1997).
Na organização por equipes de projeto, essa flexibilidade é bastante reduzida. O
grupo de colaboradores é determinado, geralmente, no início do projeto, permanecendo o
mesmo até o final do empreendimento. Sendo assim, as habilidades e competências de
determinados colaboradores só são aproveitadas nos projetos nos quais eles estão alocados.
Além disso, pouco se pode fazer para tratar os momentos de altas ou baixas demandas de
trabalho, já que a equipe é, geralmente, mantida constante durante todo o tempo. Nos períodos
de pouca atividade, existe tendência de haver capacidade ociosa, enquanto que os momentos
de alta demanda geralmente são assolados por atrasos e queda na qualidade do produto
(VASCONCELLOS; HEMSLEY, 1997).
A Tabela 1 apresenta uma síntese da análise comparativa realizada nesta seção,
referente às organizações por células de produção e por equipes de projetos.

24
 Tabela 1 – Comparação entre as Organizações por Células de Produção e por Equipes de Projeto

Estruturação Estruturação
Aspectos
por Células por Projetos
Definição do perfil adequado dos colaboradores envolvidos Melhor Pior
Tamanho da equipe adequado às necessidades do projeto Melhor Pior
Nível de comunicação entre os colaboradores envolvidos Menor Maior
Comprometimento dos colaboradores Pior Melhor
Eficiência no uso dos recursos humanos e materiais Melhor Pior

A partir da análise comparativa dos aspectos relacionados à organização da

produção por células e por equipes de projeto, observa-se que nenhum dos dois modelos é
plenamente adequado ao desenvolvimento de software. Ambos apresentam vantagens e
desvantagens que podem, inclusive, variar de acordo com o projeto em questão e suas
características. Dessa forma, é identificada a necessidade de uma investigação mais criteriosa
acerca da combinação da organização por células e por projetos no desenvolvimento de
sistemas.

2.5 Estrutura Matriz Balanceada

A estrutura funcional apresenta uma forte limitação para a realização de

atividades que demandam integração entre áreas funcionais diferentes (VASCONCELLOS;
HEMSLEY, 1997), no entanto esta estrutura possui uma série de pontos fortes10 que são do
interesse da organização. Sendo assim, com o objetivo de superar as limitações da estrutura
funcional e, ao mesmo tempo, manter suas vantagens, foi desenvolvida a estrutura matricial.
A estrutura matricial é um modelo híbrido que, de acordo com Vasconcellos
(1982 apud Vasconcellos e Hemsley, 1997), consiste na utilização simultânea de duas ou
mais estruturas organizacionais, sobre os mesmos membros da organização.
Existem diversos modelos de estrutura matricial11, no entanto o modelo que
interessa ao escopo deste trabalho é a “matriz balanceada”. De acordo com Galbraith (1973
apud Vasconcellos e Hemsley, 1997), esta estrutura combina os aspectos da

10
Os aspectos vantajosos da estrutura funcional podem ser encontrados em (Vasconcellos; Hemsley, 1997, p.
30-36).

25
departamentalização funcional, com a organização por projetos. Nesse modelo, o autor propõe
uma divisão igualitária de autoridade para os gerentes funcionais (mapeados nos
coordenadores de célula de produção, conforme apresentado na seção 1.3) e gerentes de
projetos, garantindo um poder de decisão igual para estes dois elementos. Vasconcellos (1977
apud Vasconcellos e Hemsley, 1997), por sua vez, acrescenta mais duas variáveis adicionais a
serem consideradas na matriz balanceada: “a forma de comunicação entre o gerente do projeto
e a equipe de projeto e a porcentagem de gerentes de projeto que não acumulam cargos
funcionais”. Sendo assim, com base em Galbraith (1973) e em Vasconcellos (1977),
Vasconcellos e Hemsley (1997) definem como matriz balanceada a estrutura que apresenta as
seguintes características.

a) Os gerentes de projetos e gerentes funcionais têm o mesmo nível hierárquico e

graus de autoridade semelhantes, embora em áreas diferentes.
b) Todos os gerentes de projetos interdisciplinares somente gerenciam projetos,
não ocupando simultaneamente cargos funcionais.
c) A comunicação entre o gerente de projeto e a equipe técnica do projeto é
sempre direta, sem passar pelos gerentes funcionais.
A Tabela 2 apresenta um quadro comparativo entre a Organização Funcional, a
Matriz Balanceada e a Organização por Projetos. A comparação é feita a partir de um
conjunto de Fatores considerados por Vasconcellos e Hemsley (1997) como relevantes para a
avaliação da eficiência da estrutura organizacional adotada.
Tabela 2 – Quadro comparativo das estruturas organizacionais

Fatores Organização Matriz Organização

Funcional Balanceada por Projetos
Cumprimento dos prazos Fraco Bom Muito Bom
Qualidade técnica do projeto Muito Bom Bom Fraco
Eficiência no uso de recursos humanos e Muito Bom Bom Fraco
materiais
Controle do orçamento do projeto Fraco Bom Muito Bom
Satisfação no trabalho para especialistas Muito Bom Bom Fraco
Satisfação no trabalho para não-especialistas Fraco Bom Muito Bom
Desenvolvimento da capacidade técnica na Muito Bom Bom Fraco
organização
Nível de conflitos Baixo Alto Baixo

Fonte: Vasconcellos e Hemsley, 1981 apud Vasconcellos e Hemsley, 1997, p. 88 (com ajustes)
11
Os diferentes modelos de estrutura matricial podem ser encontrados em (Vasconcellos; Hemsley, 1997, p. 51-
68).

26
 A partir da análise da Tabela 2, verifica-se que a matriz balanceada mantém um
certo equilíbrio entre as vantagens e desvantagens da organização funcional e da organização
por projetos. Esse fato estimularia a utilização deste tipo de organização, como forma de
potencializar as vantagens e minimizar as desvantagens de cada modelo original no
desenvolvimento de sistemas, proposta deste trabalho. No entanto, os aspectos relacionados
por Ghezzi (1991) e Sommerville (2000)12 como relevantes para uma empresa
desenvolvedora de software não foram analisados, o que gera a necessidade de uma
investigação mais criteriosa neste sentido. Além disso, a organização matricial tem como
desvantagem exclusiva o critério “Nível de conflitos”, situação inexistente nos modelos
originais quando aplicados individualmente. Conclui-se, portanto, que a estrutura matricial
possui aspectos importantes para a combinação das duas estruturas organizacionais em
questão, no entanto, a efetividade de sua aplicação de forma íntegra e original, no escopo da
produção de software, deve ser investigada.
Além de considerar os aspectos relativos à organização matricial, é relevante
observar que diversos experimentos têm sido feitos com o objetivo de medir a efetividade das
formas de organização da produção e montagem dos times de desenvolvimento nas empresas
de software. Com base neles consegue-se chegar às considerações abaixo (GHEZZI, 1991).

a) Não existe um ciclo de vida apropriado para todos os tipos de projeto, assim
como não existe uma organização de time de desenvolvimento ideal para
todos os tipos de projeto.
b) O controle descentralizado do time de desenvolvimento é mais adequado
quando o projeto demanda soluções complexas e ainda desconhecidas,
necessitando alto grau de comunicação e interação entre os colaboradores.
c) O controle centralizado do time de desenvolvimento é mais adequado quando
o projeto pode ser atendido por soluções conhecidas e dominadas pela equipe
de desenvolvimento, dispensando grande interação e troca de experiência
entre os colaboradores.
d) Uma boa organização da produção deve ter flexibilidade para garantir o nível
adequado de comunicação entre os desenvolvedores, de acordo com as
necessidades e tipo do projeto.

12
Os aspectos relacionados por Ghezzi (1991) e Sommerville (2000) podem ser encontrados na seção 2.4 deste
trabalho.

27
 Nestes termos, devido à inexistência de um modelo que seja, notoriamente, plena
e perfeitamente adequado ao desenvolvimento de sistemas, aliado às características peculiares
da produção de software, o estudo suscita a necessidade da definição de uma forma de
organização da produção que permita minimizar os problemas e maximizar as vantagens de
cada um dos modelos abordados, no âmbito de uma organização de desenvolvimento de
sistemas.

2.6 Trabalhos Correlatos

De acordo com relato de Parris (1996 apud Pfleeger, 2001) a Força Aérea Norte-
Americana, em parceria com a Lockheed Martin, formaram o Time de Desenvolvimento de
Produto Integrado (Integrated Product Development Team). O objetivo da coalizão foi o
desenvolvimento de um sistema modularizado destinado a aumentar a capacidade, prover
funcionalidades e reduzir o custo e o tempo de manutenção dos sistemas utilizados no caça F-
16 Fighting Falcon.
Os programas que deveriam ser desenvolvidos eram de altíssima criticidade,
incluindo funcionalidades de tempo real e recursos que eram utilizados durante o vôo e
situações de combate. O projeto incluía o desenvolvimento de drivers de dispositivos, funções
de tempo real em linguagem Ada, um compilador Ada para o computador de bordo da
aeronave, ferramentas de gerência de configuração, programas de simulação e de testes e
interfaces para carregar os programas nos dispositivos da aeronave. Os requisitos do sistema
eram bem compreendidos e estáveis, e a equipe de desenvolvimento era composta por 250
programadores divididos em 8 times distintos.
O cenário descrito anteriormente apresenta um projeto de grande porte e de alta
criticidade. O orçamento reduzido para realização do projeto, assim como as limitações de
prazo, forçaram a alta administração a buscar formas alternativas de aumento de
produtividade e otimização dos recursos disponíveis. Nesse contexto, a organização da
produção foi estabelecida na forma matricial, conforme apresentado na seção anterior.
Nessa estruturação, cada engenheiro de software foi alocado em uma unidade
funcional (célula de produção), com base na área de conhecimento e serviço a ser executado
pela célula, como célula de arquitetura, célula de testes etc. No entanto, o mesmo engenheiro

28
era designado a atuar em um ou mais módulos (projetos) do sistema, de acordo com suas
habilidades e com as necessidades do projeto. Nesse modelo, as decisões eram tomadas pelas
unidades funcionais, apesar do empreendimento demandar integração total entre os módulos.
A estrutura matricial aplicada, que combinou aspectos da organização por células
e por equipes de projetos, proveu resultados satisfatórios em relação à produtividade da
equipe e cumprimento dos termos acordados.
A utilização da estrutura matricial, porém, ocorreu na situação de um projeto
único, onde as prioridades e requisitos já estavam claramente estabelecidos. Além disso, os
objetivos das equipes de projetos e das unidades funcionais convergiam para um mesmo
ponto: sucesso global do empreendimento. Dessa forma, fica a necessidade da análise do
comportamento dessa estrutura em um ambiente de uma fábrica de software, que atravessa
situações de sazonalidade de projetos e múltiplas demandas por células de produção.

29
3 ORGANIZAÇÃO HÍBRIDA DA PRODUÇÃO

Segundo Ghezzi (1991), ao invés de uma organização da produção rígida para o

desenvolvimento de software, uma empresa deve dispor de flexibilidade para a montagem dos
seus times de desenvolvimento, de acordo com as necessidades de cada projeto. O autor
reforça, também, que não é conhecida uma forma de organização genérica capaz de atender
de maneira ideal às demandas específicas de cada tipo de projeto de software.
Considerando o posicionamento do autor e a partir da análise do referencial
teórico do capítulo 2, observa-se que as duas formas estudadas de estruturação da produção –
as organizações por células e por equipes de projetos – apresentam pontos positivos e
negativos, que privilegiam ou dificultam cada aspecto do processo de produção de sistemas, a
depender, inclusive, do tipo de projeto de software em questão. Como a complexidade e o tipo
de sistema a ser desenvolvido pela fábrica de software não depende dela, mas sim do seu
cliente, existe a necessidade de uma opção flexível, porém estruturada e institucionalizada, de
organização dos times de desenvolvimento, de maneira a permitir melhor adequação às
peculiaridades de cada projeto de sistema desenvolvido pela organização.
Este cenário motiva a definição da Organização Híbrida da Produção (OHP), que
tem o objetivo de combinar as características das organizações por equipes de projetos e por
células de produção. Desse modo, busca-se potencializar os pontos positivos de cada uma,
minimizar as desvantagens de cada modelo e aumentar a flexibilidade da organização dos
times de desenvolvimento em uma fábrica de software, garantindo maior adequação da
empresa às peculiaridades de cada projeto de sistema.
A OHP é composta por dois elementos principais, as equipes de projetos e as
células de produção (herdados dos dois modelos originais), que interagem entre si de forma a
cumprir as atividades de produção do software.
A Figura 4 apresenta o arranjo produtivo da OHP. Neste, cada equipe de projeto
requisita os serviços das células disponíveis da organização. A depender do projeto em
questão, as células utilizadas pelas equipes de projeto variam de acordo com os serviços
prestados por cada uma delas e as necessidades do empreendimento. Nesta estrutura, é
colocado um conjunto de células de produção disponível para toda a empresa, e que pode ser
utilizado por qualquer projeto da organização.

30
 EQUIPE DE
PROJETO 1

CÉLULAS DE PRODUÇÃO

EQUIPE DE EQUIPE DE
PROJETO N PROJETO 2

EQUIPE DE
PROJETO 3

Figura 4 – Organização Híbrida da Produção

3.1 As Equipes de Projeto

Uma equipe de projeto representa um time de colaboradores, de tamanho variável,

dedicados em tempo integral ou parcial a um único projeto de software. Um mesmo
colaborador pode fazer parte de mais de uma equipe de projeto, desde que tenha
disponibilidade para isso e suas habilidades sejam requeridas. A equipe tem, basicamente,
duas responsabilidades: a produção parcial ou integral do software e o gerenciamento do
projeto.
Sua primeira responsabilidade, a construção parcial ou integral do sistema, tem
como atribuição a realização de cada uma das etapas definidas no projeto do software. Os
colaboradores que compõem a equipe de projeto podem ter, também, se as demandas do
projeto assim determinarem, perfil técnico, estando aptos a atuarem na etapa de codificação
do sistema. A metodologia de desenvolvimento a ser adotada é uma decisão da equipe de

31
projeto. Como a OHP guarda as características individuais das duas formas de organização da
produção em questão, e estas, por sua vez, são amplamente utilizadas pelas empresas de
software, a utilização da OHP, com as metodologias de desenvolvimento e ciclos de vida
tradicionais, pode ser aplicada diretamente e sem necessidade de adaptações significativas.
A segunda responsabilidade da equipe, o gerenciamento, tem como atribuição o
acompanhamento e gestão do projeto. Seu principal objetivo é assegurar o alcance dos
resultados esperados, garantindo que sejam cumpridos os termos e condições acordados com
o cliente. Segundo as diretrizes de gerenciamento do PMBOK 2000 (2000), a equipe é
encarregada por controlar os seguintes aspectos do projeto: a definição do escopo, bem como
suas alterações; o tempo e o cronograma das atividades; o custo de realização; a qualidade dos
processos, subprodutos e produtos gerados; os recursos humanos; a comunicação e interação
dos colaboradores; os riscos envolvidos, bem como estratégias de mitigação; as aquisições de
insumos (produtos e serviços) necessários ao desenvolvimento do sistema; e, por fim, o
equilíbrio e andamento satisfatório de todo o projeto13.
A existência de equipes de projeto no arranjo produtivo, onde cada uma possui um
coordenador, promove definição explícita de quem são os responsáveis por cada projeto da
fábrica de software, estimulando um maio comprometimento de cada colaborador com os
resultados esperados (VASCONCELLOS; HEMSLEY, 1997).

3.2 As Células de Produção

O segundo grupo de elementos que compõem a OHP são as células de produção.

Elas representam um time de colaboradores, de tamanho variável, especialistas em
determinadas áreas ou atividades. Sua responsabilidade é oferecer seus serviços
especializados às equipes de projetos, no prazo estabelecido e com a qualidade esperada.
Fazendo um mapeamento entre as células de produção e a departamentalização
funcional, elas correspondem às áreas ou setores da organização encarregados por executar
atividades específicas e relacionadas entre si, que demandam um perfil profissional
especializado.

13
Os aspectos citados são apresentados em detalhes ao longo das nove Áreas de Conhecimento (Knowledge
Areas) especificadas pelo PMBOK 2000 (2000).

32
 Cada célula possui um coordenador de produção, responsável por gerenciar as
atividades da célula e, juntamente com os coordenadores das equipes de projeto, determinar as
prioridades das atividades, negociar os prazos de entrega e alocar os recursos devidamente.

3.3 Papéis e Responsabilidades

Na OHP, assim como na estruturação por células de produção e por equipes de

projeto, os papéis funcionais existentes em um time de desenvolvimento podem ser definidos
de acordo com as necessidades dos projetos, a metodologia de desenvolvimento adotada e a
cultura da organização. Ressalta-se, no entanto, a necessidade de um coordenador para cada
equipe de projeto, outro para cada célula de produção, assim como, um coordenador geral
para todas as equipes de projeto e outro para todas as células de produção. Nesta seção é
apresentada apenas uma sugestão de distribuição de papéis funcionais, dentre outras
possíveis.
A divisão de papéis e responsabilidades aqui apresentada segue a proposta de
Pfleeger (2001), que recomenda uma estruturação básica de papéis de modo a conseguir um
time de desenvolvimento consistente e que cubra todo o ciclo de vida do processo de
software.
A depender do tamanho do projeto, cada papel funcional pode ser assumido por
um ou mais colaboradores. A proposta do autor consiste em dividir o time de desenvolvedores
nos seguintes papéis:

a) analista de sistema;
b) projetista de sistema;
c) programador;
d) testador;
e) instrutor.

Contextualizando esse conjunto de papéis na OHP, observa-se que eles podem ser
aplicados, livremente, tanto nas equipes de projeto, como nas células de produção. Para isso,
basta determinar se a necessidade do papel é para uma atuação específica em um determinado

33
projeto (neste caso o papel é estabelecido na equipe de projeto), ou para uma ação transversal
a toda organização (neste caso o papel é estabelecido na célula de produção). Os papéis
funcionais podem, também, co-existir nas equipes de projeto e nas células de produção, como
é apresentado no estudo de caso realizado no presente trabalho.
A Tabela 3 apresenta uma breve síntese contendo a descrição e a atuação de cada
papel funcional proposto por Pfleeger (2001), que pode ser utilizado em uma empresa de
desenvolvimento de software.

Tabela 3 – Proposta de um Conjunto de Papéis Funcionais

Papel
Descrição e Atuação
Funcional
Encarregados de identificar as necessidades dos contratantes e usuários e
transpô-las para requisitos documentados do sistema. Nesse processo, é
Analistas de fundamental grande interação e comunicação entre as pessoas envolvidas,
Sistema pois discrepâncias entre as expectativas do cliente e os requisitos
documentados pelo desenvolvedor, podem comprometer seriamente o
projeto.
Encarregados de conceber a arquitetura e projeto do software a ser
Projetistas de
desenvolvido. Para tanto, eles devem ter forte interação com os analistas,
Sistema
pois estes dominam os requisitos que o sistema deve contemplar.
Responsáveis por fazer a codificação propriamente dita do sistema
Programadores
especificado pelos projetistas e analistas.
Responsáveis por executar os testes, de forma a ajudar no controle da
qualidade do sistema. O trabalho realizado por eles tem o objetivo de
Testadores verificar se o software desenvolvido está conforme as especificações e livre
de falhas, assim como determinar se o produto que será entregue atende às
necessidades e expectativas do cliente.
Encarregados de treinar os usuários na utilização do sistema. Os instrutores
devem ter forte interação com os clientes e os desenvolvedores, pois, durante
Instrutores sua atividade de treinamento, eles têm a oportunidade de coletar a impressão
do cliente em relação ao sistema, assim como identificar pontos de correções
e melhorias no software.

Em seguida, ainda considerando a proposta de Pfleeger (2001), a Figura 5 mostra

a atuação de cada papel funcional descrito anteriormente (analyst – analista de sistemas,
designer – projetista de sistema, programmer – programador, tester – testador, trainer –
instrutor), nas etapas básicas de um ciclo de desenvolvimento de software. Pode-se observar
que, de forma matricial, um mesmo papel funcional (developer role) pode atuar em mais de
uma etapa (software development step) do processo de software, assim como uma etapa pode
sofrer a atuação de mais de um papel funcional.

34
 Figura 5 – Papéis Funcionais em um Processo de Desenvolvimento de Software
Fonte: PFLEEGER, 2001, p.26

A proposta do autor representa uma possível distribuição de papéis funcionais que

pode ser adotada na OHP. No entanto, este aspecto deve ser determinado com base nas
necessidades de cada projeto e cultura organizacional.

3.4 Processo Produtivo

O processo produtivo na OHP é administrado pela equipe de projeto. Sobre ela

está a responsabilidade de determinar as etapas do projeto, controlar os prazos, garantir o
atendimento aos requisitos especificados, controlar as entregas aos contratantes, manter o

35
relacionamento com os clientes, enfim, gerenciar todo o projeto, controlar os seus
subprodutos e administrar as atividades.
Além disso, a equipe de projeto é responsável por executar, em parte ou
integralmente, as atividades de realização do projeto, como configurar o ambiente, codificar o
sistema, proceder os testes, realizar a implantação etc. Ao longo do empreendimento, no
entanto, a equipe de projeto, pode requisitar a execução de atividades às células de produção.
Isso é feito, levando-se em consideração o tipo de atividade a ser executada, o perfil do
profissional necessário, as especialidades das células de produção e a disponibilidade destas.
Portanto, diversos fatores podem estimular a utilização das células de produção pelas equipes
de projeto, por exemplo: a existência, nas células de produção, de especialistas capazes de
executar uma atividade com maior qualidade técnica ou rapidez; carência do perfil adequado
na equipe de projeto para executar uma atividade; carência de equipamentos ou ferramental
necessário na equipe de projetos; alta demanda de trabalho na equipe de projeto.
A requisição dos serviços das células de produção deve passar por um processo
estruturado de negociação, envolvendo o coordenador de projeto da equipe solicitante e o
coordenador de produção da célula requisitada. Nesta negociação devem ser determinados os
prazos de entrega dos subprodutos solicitados e quais colaboradores serão alocados para a
realização das atividades. Isso deve ser feito de forma alinhada às prioridades da organização
em relação aos diversos projetos em andamento.
A Figura 6 apresenta a utilização das células de produção por uma das diversas
equipes de projeto da empresa. O diagrama mostra que o processo de software transcorre sob
a responsabilidade da equipe de projeto, no entanto as células de produção são requisitadas a
atuar em algumas das suas etapas.

36
 EQUIPE DE PROJETO

PROCESSO DE SOFTWARE

ETAPA 1 ETAPA 2 ETAPA 3 ETAPA N

CÉLULAS DE PRODUÇÃO

Figura 6 – Utilização das células de produção por uma equipe de projeto

Outro aspecto importante e contemplado pela OHP é que qualquer processo de

ajuste no software, provindo da etapa de testes, homologação ou manutenção, pode requerer a
intervenção de colaboradores em diversos papéis funcionais do time de desenvolvimento,
desde os analistas até os responsáveis pela implantação, de forma transversal a todo o ciclo de
desenvolvimento (PFLEEGER, 2001). Uma solicitação de ajuste de alta prioridade, que
demande pouco tempo de trabalho, mas que necessite de alterações em todas camadas do
sistema (aplicação, interface e persistência), precisaria, na organização por células, atravessar
diversas células de produção, até a sua entrega ao cliente. Por exemplo, a inclusão de um
novo atributo em um formulário, requer atuação do analista, para documentar a nova
necessidade do cliente; do projetista, para avaliar o impacto dessa inclusão no sistema e
determinar como será realizada; do programador, para alterar o banco de dados, a camada de
aplicação e a interface; e do testador, para testar a nova versão do sistema. Numa estruturação
por células de produção pura, seria necessária a atuação de diversas células para a realização
desta atividade de correção. Já na OHP, um processo deste tipo, cuja demanda de trabalho é
pequena, porém transversal a todo o ciclo de desenvolvimento, pode ser realizado pela equipe

37
de projeto individualmente, reduzindo a sobrecarga de gerenciamento e troca de informações
entre pessoas de áreas diferentes.

38
4 ESTUDO DE CASO

Neste capítulo é descrito o estudo de caso realizado em uma organização voltada

ao desenvolvimento de software, na qual foi aplicada a OHP em dois de seus projetos.

4.1 Cenário

O estudo de caso foi realizado no Instituto Recôncavo de Tecnologia. A

instituição, uma entidade sem fins lucrativos, caracteriza-se por ser um centro de Pesquisa e
Desenvolvimento (P&D) em Tecnologia da Informação e Comunicação (TIC). Sua atividade
fim é a realização de projetos de pesquisa aplicada, na referida área, de forma alinhada aos
interesses estratégicos do país que são refletidos nos normativos e direcionamentos passados e
acompanhados pelo Ministério da Ciência e Tecnologia (MCT).
A instituição, no momento da realização do estudo de caso, contava com um total
de 26 funcionários nas áreas técnica e administrativa. Para o experimento, foram mobilizados
12 colaboradores distribuídos em diferentes papéis funcionais, conforme apresentado na
Tabela 4.
Tabela 4 – Papéis Funcionais dos Colaboradores

Papel Funcional Quantidade

Coordenador de Desenvolvimento 01
Líder de Projeto 01
Engenheiro de Software 06
Diagramador 02
Analista de Suporte 01
Analista de Testes 01
Total de Colaboradores 12

A OHP foi utilizada em dois dos projetos de desenvolvimento software da

instituição. O primeiro deles trata-se de um sistema de cotação de serviços via Web, o
CotaOn, que permite a abertura remota de solicitações de serviço para uma central de
compras; o segundo, o Rastro, refere-se a um sistema de rastreabilidade de componentes de
computadores, para ser utilizado em uma montadora de microcomputadores.

39
4.2 Caracterização dos Projetos Desenvolvidos

4.2.1 Projeto 1: Desenvolvimento do Sistema CotaOn

O domínio do problema do CotaOn englobou uma empresa multinacional de

comércio de vinhos. O alto volume de compras de serviços efetuadas, atrelado ao grande
número de fornecedores utilizados pela empresa, gerou uma necessidade de melhoria no
processo de cotação de serviços. A empresa identificou a necessidade de diminuir o tempo de
execução desta atividade, assim como aumentar a sua eficácia, através da comparação dos
preços de um número maior de fornecedores.
O objetivo do projeto foi o desenvolvimento de um sistema que visa automatizar o
processo de cotação de preços de serviços, aproximando as empresas parceiras, compradores
e fornecedores, com benefícios para ambos. Neste processo, as empresas expõem suas
necessidades de cotação de preços e, automaticamente, seus fornecedores parceiros, com um
perfil adequado, estão aptos a responder a estas solicitações. Ao final do processo, todas as
respostas de cotação são organizadas para auxiliar ao comprador a decidir pela melhor
compra.
O projeto utilizou as seguintes tecnologias:

a) ambiente de desenvolvimento: Eclipse (linguagem de programação Java);

b) persistência: banco de dados Microsoft14 SQL Server;
c) sistema operacional servidor: Microsoft Windows 2000.

4.2.2 Projeto 2: Desenvolvimento do Sistema Rastro

Neste projeto, o domínio do problema envolveu uma fábrica de computadores,

onde as máquinas são montadas, testadas e distribuídas. A montagem das máquinas consiste

40
na agregação de diversos componentes de hardware, como processador, placa-mãe, unidades
de CD-ROM e DVD, disco rígido, memória, placa de rede, modem, fonte, unidade de
disquete etc. Tais componentes não são produzidos na fábrica, sendo adquiridos de diferentes
fornecedores. Eles provêm de fabricantes distintos, gerando uma diversidade de marcas,
modelos e termos de garantia. Desta forma, ao ser montado, um único computador, possui
componentes de fabricantes e condições de garantia diferenciados. Esta situação cria a
necessidade de se manter a rastreabilidade de cada componente desde a sua aquisição, junto
ao fornecedor, até a venda para o usuário final.
O projeto teve por objetivo o desenvolvimento de um software destinado a fazer o
rastreamento dos componentes utilizados na montagem das máquinas. O módulo de Registro
de Números de Série armazena os números das notas fiscais das aquisições, assim como os
números de série de todos os componentes rastreáveis associados a cada nota. Esse registro é
feito de forma automática, através da leitura de arquivos eletrônicos enviados pelos
fornecedores; ou de forma manual, através da leitura de código de barras feita por coletores de
dados.
Em uma outra etapa do processo produtivo da fábrica, após a montagem da
máquina, o Módulo de Inventário atua de forma a identificar e registrar o número de série da
máquina produzida e de cada componente rastreável presente no equipamento. A partir das
informações registradas pelos dois módulos, é possível identificar a Nota Fiscal associada a
cada componente da máquina, garantindo a rastreabilidade desejada.
O projeto utilizou as seguintes tecnologias:

a) ambiente de desenvolvimento: Microsoft Visual Studio .Net, utilizando a

linguagem VB.Net;
b) persistência: banco de dados Microsoft SQL Server;
c) sistema operacional servidor: Microsoft Windows 2000.

14
www.microsoft.com

41
4.3 Processo de Desenvolvimento Aplicado

Para a realização dos dois projetos no estudo de caso, foi aplicado um processo de
desenvolvimento com características iterativas e incrementais. O processo utilizado é
composto por 6 fases principais, conforme apresentado na Figura 7, e descrito a seguir.

a) Levantamento e Análise – Consiste no conhecimento das necessidades do

cliente (domínio do problema) e posterior identificação dos requisitos do sistema. Esta etapa
possui como produtos o Diagrama de Casos de Uso e a Lista de Requisitos.

b) Anteprojeto – Compreende a especificação, em alto nível (pouco

detalhamento), da solução proposta. O produto desta etapa é uma versão preliminar do Projeto
Arquitetural do sistema, contemplando os elementos mais importantes da solução. Neste
ponto é gerado um documento para o cliente, chamado de Anteprojeto de Sistema, contento
todos os produtos gerados até o momento (Diagrama de Casos de Uso, Lista de Requisitos,
Projeto Arquitetural – Versão Preliminar), para a sua verificação de conformidade e
validação. Nesse momento o cliente pode solicitar ajustes no Anteprojeto de Sistema, de
forma que a solução proposta fique mais aderente às suas necessidades. O processo só é
levado à fase seguinte, após aprovação do Anteprojeto de Sistema, feita pelo cliente.

c) Elaboração do Protótipo – Representa a construção de um protótipo de

sistema, contemplando apenas as telas de interface que representam as funcionalidades mais
importantes do programa. Neste ponto, o produto de software desenvolvido não promove
validações de entradas de dados, regras de integridade ou interface amigável. O objetivo desta
etapa é permitir que os requisitos identificados sejam confirmados e que novas necessidades
possam ser identificadas o mais breve possível. Essa estratégia visa mitigar os riscos
envolvidos no projeto, através da minimização da sua probabilidade de ocorrência. Em
seguida, o protótipo é apresentado ao cliente, que pode solicitar ajustes em qualquer dos
componentes do Anteprojeto de Sistema, de forma que a solução proposta fique mais aderente
às suas necessidades. Posteriormente, se aplicável, são feitos ajustes tanto no Anteprojeto de
Sistema, quanto no protótipo gerado. A próxima fase só é iniciada após a aprovação destes
dois elementos, feita pelo cliente.

42
 d) Planejamento das Iterações – Consiste no planejamento das versões de
sistema que serão produzidas. Nesta fase, o conjunto de recursos do software é dividido em
versões que compõem o cronograma de codificação. Esse cronograma é definido juntamente
com o cliente, levando em consideração as suas prioridades, os riscos envolvidos no projeto e
as restrições operacionais relativas ao sequenciamento da implementação das funcionalidades.

e) Disponibilização das Versões – Engloba as etapas que vão desde o

detalhamento do projeto até a correção da versão. Nesta fase, de acordo com o cronograma
estabelecido, cada versão tem seu projeto detalhado, é codificada, testada, implantada,
avaliada pelo cliente e corrigida. Nesse ponto, a metodologia assume uma característica
iterativa e incremental, onde a cada versão disponibilizada o sistema vai agregando um maior
número de recursos e corrigindo as funcionalidades já disponibilizadas. O processo
permanece nesta fase até que todas as versões planejadas tenham sido implantadas.

f) Homologação do Sistema – Essa é a última etapa do processo de

desenvolvimento. Representa a aceitação final do produto e formalização do final do projeto.

43
 PROCESSO DE DESENVOLVIMENTO
Início

Levantamento Disponibilização das Versões

e Análise

Seleção da Projeto
Versão Detalhado
Anteprojeto

Correção Codificação

Elaboração do
Protótipo Avaliação Testes

Implantação
Planejamento
das Iterações

Homologação
do Sistema

Fim

Figura 7 – Processo de Desenvolvimento Aplicado

4.4 Organização da Produção Adotada

Para a realização dos projetos a organização da produção foi feita em duas

equipes de projeto e quatro células de produção, seguindo as especificações da OHP. A
equipe do projeto CotaOn dispunha de um líder de projeto e dois engenheiros de software. A
mesma distribuição foi adotada para a equipe do projeto Rastro. A Tabela 5 apresenta a
composição das duas equipes de projeto.

44
 Tabela 5 – Composição das equipes de projeto

Papel Funcional Qtd. Funcionários

Líder de Projeto 01
Engenheiro de Software 02

As quatro células de produção estabelecidas foram as seguintes: Célula de Infra-

estrutura, Célula de Elementos de Aplicação, Célula de Elementos de Interface e Célula de
Testes e Controle de Qualidade. Elas foram compostas pelos papéis funcionais e quantidade
de funcionários, conforme apresentado na Tabela 6.

Tabela 6 – Composição das Células de Produção

Célula de Produção Qtd. Funcionários Papel Funcional

Célula de Infra-estrutura 01 Analista de Suporte
Célula de Elementos de Aplicação 02 Engenheiro de Software
Célula de Elementos de Interface 02 Diagramador
Célula de Testes e Controle de Qualidade 01 Analista de Testes

A Figura 8 apresenta uma visão completa da organização da produção adotada,

contemplando as equipes de projeto, as células de produção e a quantidade de colaboradores
alocados em cada uma das estruturas.

45
 EQUIPES DE PROJETO

EQUIPE PROJETO CotaOn EQUIPE PROJETO RASTRO

Infra- Interface Testes e

estrutura Aplicação Qualidade

CÉLULAS DE PRODUÇÃO

Figura 8 – Organização da Produção Adotada

De acordo com a especificação da OHP, cada equipe de projeto, assim como cada
célula de produção, deve possuir um coordenador. Da mesma forma que o conjunto das
equipes de projeto, assim como o conjunto das células de produção, devem possuir
coordenadores gerais. Contudo, no estudo de caso em questão, foi designado um único
colaborador que acumulou o papel funcional de coordenador das duas equipes de projeto e
das quatro células de produção. Vale ressaltar, também, que o papel de líder de projeto das
duas equipes foi acumulado em um único funcionário.

4.5 Atribuições e Responsabilidades Estabelecidas Para os Elementos da

OHP

No decorrer do processo de desenvolvimento, apresentado em seção anterior, cada

elemento da OHP, teve atuação em diferentes fases. Não é estabelecido de forma rígida (e
nem é uma premissa da formulação proposta), em quais fases do desenvolvimento cada
elemento deve atuar. Esta é uma decisão que deve ser tomada com base nas demandas de cada
projeto e disponibilidade dos recursos da organização.

46
 Sendo assim, é apresentado a seguir como foi feita a atribuição de tarefas e
delegação de responsabilidades para os dois projetos realizados durante o estudo de caso.

4.5.1 Equipes de Projeto

Cada grupo foi responsável por toda a especificação do sistema, gerenciamento do

projeto e contato com o cliente. Além das atribuições de especificação, as equipes de projeto
atuaram, com seus dois engenheiros de software cada uma, na codificação de parte dos seus
respectivos sistemas. As equipes tiveram como atividades principais:
a) levantamento, definição e análise dos requisitos do sistema junto ao cliente;
b) elaboração plano de projeto do sistema;
c) controle das versões;
d) codificação das regras de negócio de alta complexidade;
e) gerenciamento de todo o projeto (prazos, entregas aos clientes, redefinição de
escopo etc)

4.5.2 Célula de Infra-estrutura

Esta unidade foi a responsável por preparar todo o ambiente de trabalho e infra-
estrutura necessária ao desenvolvimento dos projetos. Suas atividades foram:

a) instalação dos servidores de desenvolvimento, testes e homologação;

b) instalação das ferramentas necessárias ao desenvolvimento;
c) controle das versões e atualização das ferramentas utilizadas;
d) instalação e configuração do Servidor de Controle de Versão (CVS);
e) montagem da estrutura de diretórios dos projetos.

47
4.5.3 Célula de Elementos de Aplicação

Esta célula teve como finalidade o desenvolvimento de elementos de aplicação,

permitindo a reutilização de código, e apoio às equipes de projeto nas decisões técnicas. Suas
atividades foram:

a) desenvolvimento de classes de negócio em Java e .Net;

b) desenvolvimento de classes de persistência;
c) gerenciamento e organização da biblioteca de componentes de aplicação;
c) “refatoramento” (refactoring) de componentes de aplicação;
d) aplicação de padrões de projeto;
e) utilização de geradores de código;
f) apoio às equipes de projeto no desenvolvimento da arquitetura;
g) padronização da arquitetura.

4.5.4 Célula de Elementos de Interface

Esta célula foi encarregada da criação e padronização de componentes de interface

e relatórios. Suas atividades foram:

a) criação de componentes de interface: botões, imagens, tabelas, frames etc;

b) padronização de elementos de interface: tipo e tamanho de fonte, resolução da
tela, disposição dos elementos, mensagens para o usuário, cores etc;
c) diagramação de telas e relatórios.

48
4.5.5 Célula de Testes e Controle de Qualidade

O objetivo desta unidade foi a verificação da conformidade do sistema, antes que

este fosse disponibilizado para o cliente. Suas atividades foram:

a) execução do teste funcional com base no diagrama de casos de uso e lista de

requisitos;
b) correção gramatical da interface do sistema e da documentação (ajuda online,
manual do usuário e relatórios);
d) validação do pacote de instalação que é disponibilizado para o cliente;
e) utilização de ferramentas de automatização de testes.

4.6 Resultados Obtidos em Relação aos Aspectos Comparativos Analisados

Nesta seção são analisados os resultados obtidos em relação a cada um dos

aspectos identificados como relevantes para análise da organização da produção em empresas
de desenvolvimento de sistemas. Tais resultados foram coletados através de observação
direta, considerando-se o fato de que o autor do presente trabalho permaneceu inserido no
cenário do estudo de caso, durante a realização de todo o experimento, atuando no papel de
Líder de Projeto.

4.6.1 Aspecto: Definição do Perfil Adequado dos Colaboradores Envolvidos

A montagem da equipe de colaboradores envolvidos no projeto foi feita com total

flexibilidade, em relação aos colaboradores que estavam disponíveis para o estudo de caso.
Ambos os projetos necessitaram de colaboradores com experiência em infra-estrutura,
diagramação e perfil criterioso para a execução dos testes e correção gramatical da interface

49
do sistema e documentação do cliente. Para a execução destas tarefas, estavam disponíveis os
seguintes profissionais com o perfil adequado: um Analista de Suporte, dois Diagramadores e
uma Analista de Testes.
Caso fosse utilizada, exclusivamente, a estrutura organizacional por equipes de
projetos, estes profissionais teriam que ser alocados no projeto CotaOn ou no Rastro,
atendendo, dessa forma, as necessidades de um dos projetos e deixando o outro com carência
de profissionais.
Da forma como foram distribuídos, utilizando a OHP, estes profissionais foram
alocados em células de produção, podendo assim, compor, temporariamente, a equipe de
desenvolvimento do dois projetos, atendendo, portanto, as necessidades de ambos.
Sendo assim, é possível concluir que a utilização da OHP, a partir de um aspecto
positivo aproveitado da estruturação por células, foi mais efetiva do que teria sido a utilização
da organização por equipes de projetos, se tivesse sido aplicada.

4.6.2 Aspecto: Tamanho da Equipe Adequado às Necessidades do Projeto

Segundo Ghezzi (1991), um time de desenvolvimento deve ser montado de forma

paulatina e incremental, permitindo o atendimento às demandas de trabalho sem o desperdício
de recursos. A organização da produção deve ser flexível o suficiente para permitir a atuação
de um time de desenvolvimento inicialmente pequeno, porém com capacidade de expansão,
de acordo com as necessidades do projeto. Este requisito é garantido de forma natural na
OHP, devido ao fato da utilização das células, poder ser feita em qualquer fase do projeto,
dependendo apenas das suas demandas e da disponibilidade das células requisitadas.
Conforme é possível observar na Tabela 7, ambos os projetos utilizados no
experimento tiveram demandas sazonais onde, a depender da fase em realização no momento,
se fazia necessária uma quantidade maior ou menor de colaboradores atuantes.

50
 Tabela 7 – Sazonalidade do Time de Desenvolvimento
Cod. Quantid.
Nome da Fase Colaboradores Envolvidos
Fase Colaborad.
F01 Levantamento e Análise 3 Equipe de Projeto
F02 Anteprojeto 3 Equipe de Projeto
F03 Elaboração do Protótipo 5 Equipe Projeto + 2 Diagramadores
F04 Planejamento das Iterações 3 Equipe de Projeto
F05 Projeto Detalhado 3 Equipe de Projeto
F06 Codificação 5 Eq. Proj. + 1 Eng. Software + 1 Diagramador
F07 Testes 5 Eq. Proj. + 1 Analista Testes + 1 Eng. Software
Eq. Proj. + 1 Analista Testes + 1 Analista de
F08 Implantação 5 Suporte
F09 Avaliação 4 Equipe de Proj.+ 1 Analista Testes
F10 Correção 5 Eq. Proj. + 1 Analista Testes + 1 Eng. Software

Representando esta variação em um gráfico, conforme apresentado na Figura 9, é

evidenciada a variação de tamanho do time de desenvolvimento ao longo das fases do
processo de software.

Variação do Tamanho do Time de

Desenvolvimento

6
Qtd. Colaboradores

5
4
3
2
1
0
F01 F02 F03 F04 F05 F06 F07 F08 F09 F10
Fases

Figura 9 – Variação do Tamanho do Time de Desenvolvimento

Se fosse aplicada a estruturação por equipes de projeto, puramente, o aumento da

equipe seria dificultado, pois necessitaria deslocar pessoas de outros projetos para atender à
demanda deste. Por outro lado, a partir da utilização da OHP, foi possível, durante o período
necessário, direcionar os esforços de cada uma das células, de modo a atender às necessidades
momentâneas do projeto.

51
 Entende-se, portanto, que a aplicação da OHP, a partir de um ponto de vantagem
herdado da estruturação por células, tende a proporcionar maior flexibilidade quanto ao
número de colaboradores na equipe, do que a organização por projetos, quando aplicada de
forma exclusiva.

4.6.3 Aspecto: Nível de Comunicação Entre os Colaboradores Envolvidos

O nível considerado adequado de comunicação e interação entre os colaboradores

pode sofrer variações significativas a depender da atividade que estiver sendo executada no
momento (PFLEEGER, 2001; GHEZZI, 1991). Segundo Ghezzi (1991), se um grupo de
módulos ou funcionalidades altamente acoplados está sendo desenvolvido por programadores
distintos, é fundamental haver grande interação e comunicação entre eles para garantir bom
resultado. Na OHP, este requisito pode ser conseguido alocando as atividades que demandam
alto nível de comunicação para as equipes de projeto, promovendo a interação desejada entre
os colaboradores.
Em ambos os projetos, a execução de atividades especificamente relacionadas às
regras de negócio do cliente, demandaram alta interação e comunicação entre os envolvidos.
Pode-se citar as atividades de levantamento, especificação e análise de requisitos; elaboração
do projeto arquitetural e codificação de algoritmos e rotinas específicas para atender às
necessidades de cada cliente. Nestas situações, foi fundamental a comunicação dos
desenvolvedores entre si, e entre eles e o cliente, com o objetivo de dirimir dúvidas e
encontrar boas soluções para os projetos.
Neste contexto, a utilização da estruturação por células de produção não seria a
mais adequada, devido ao fato de que esta forma de organização não estimula um bom nível
de comunicação entre os colaboradores de diferentes células (VASCONCELLOS;
HEMSLEY, 1997).
A aplicação da OHP permitiu que estas atividades fossem executadas pelas
respectivas equipes de projeto, aproveitando o aspecto que esta estruturação traz de vantagem
para o processo comunicativo (VASCONCELLOS; HEMSLEY, 1997).

52
 Sendo assim, é possível concluir que, no aspecto em questão, a OHP, mostra
tendência a promover um resultado mais efetivo, através da utilização das equipes de projeto,
do que se fosse utilizada, exclusivamente, a estruturação por células de produção.

4.6.4 Aspecto: Comprometimento dos Colaboradores

De acordo com o referencial teórico estruturado no capítulo 2, é sabido que a

organização por células de produção não estimula um comprometimento significativo dos
colaboradores com os resultados do projeto. Por outro lado, é conhecido, também, que na
estruturação por equipes de projeto, os colaboradores têm tendência a comprometerem-se com
os resultados do empreendimento (VASCONCELLOS; HEMSLEY, 1997).
Durante a execução dos projetos utilizando a OHP, verificou-se que os
colaboradores que pertenciam às células de produção, quando alocados para atuar em parceria
com a equipe de projetos, demonstravam o mesmo nível de comprometimento daqueles. Esta
situação foi evidenciada em duas ocasiões, em períodos próximos a duas entregas
intermediárias do sistema CotaOn, nas quais a equipe de projetos pôde contar com a presença
de dois engenheiros de software da célula de Elementos de Aplicação, para atuar por várias
horas extras, no intuito de solucionar imprevistos operacionais.
Acredita-se que este fato ocorra devido à influência dos membros da equipe de
projetos sobre os colaboradores das células de produção, quando estão engajados em um
objetivo comum.
Outro aspecto que evidencia o comprometimento dos colaboradores é apontado
por Ghezzi (1991) e Sommerville (2000). De acordo com os autores, o alcance das metas e
resultados previstos é um indicador de comprometimento da equipe de desenvolvimento. No
estudo de caso realizado, ambos os projetos foram finalizados dentro do prazo previsto e
atendendo aos requisitos especificados, indicando, portanto, um nível de comprometimento
aceitável do time de desenvolvimento.
Com base nestas observações e no referencial teórico, percebe-se que a OHP
tende a promover resultados mais efetivos neste aspecto do que a estruturação por células de
produção, quando exclusivamente aplicada.

53
4.6.5 Aspecto: Eficiência no Uso dos Recursos Humanos e Materiais

Na execução dos projetos utilizando a OHP, o compartilhamento de recursos

humanos e materiais foi realizado durante todo o empreendimento.
Em termos de recursos humanos, as habilidades dos Diagramadores, foram
aplicadas em ambos os projetos na realização da camada de interface. Da mesma forma, o
perfil criterioso da Analista de Testes, pôde ser aproveitado nos dois empreendimentos para
os testes e revisão gramatical dos artefatos. Semelhantemente, os conhecimentos do Analista
de Suporte foram úteis para os dois projetos no aspecto relativo às configurações dos
ambientes de desenvolvimento e homologação. Verifica-se que as demandas dos projetos por
diferenciados perfis profissionais puderam ser atendidas sem a necessidade de novas
contratações, ou seja, aproveitando a mão-de-obra já disponível na organização.
Considerando os recursos materiais, estes também tiveram um melhor
aproveitamento. Os microcomputadores de alta performance dos diagramadores puderam
servir aos dois projetos; da mesma forma que os programas gráficos tiveram sua utilização
compartilhada; e, por fim, todo o ferramental da célula de infra-estrutura foi útil aos dois
projetos nas atividades ligadas à rede e conectividade.
Outro ganho significativo em relação ao uso eficiente de recursos foi o fato da
capacidade ociosa dos colaboradores ter sido severamente minimizada. O escalonamento do
uso dos diferentes perfis profissionais foi feito de forma a atender, equilibradamente, às
demandas dos dois projetos. O projeto CotaOn, por exemplo, que finalizou antes do projeto
Rastro, consumiu muito mais recursos das células de produção do que o projeto Rastro,
durante suas fases finais. Dessa forma, quando foi necessária uma carga maior de trabalho no
projeto Rastro, os colaboradores já estavam desalocados do projeto CotaOn, podendo atender
às demandas.
Verifica-se, portanto, que a utilização da OHP, tornou mais eficiente o uso dos
recursos, através de suas células de produção, do que se tivesse sido aplicada a organização
por equipes de projeto, exclusivamente.

54
4.7 Análise dos Resultados

Fazendo-se uma síntese dos resultados obtidos pela OHP, frente aos aspectos
analisados, conforme apresentado na Tabela 8, verifica-se que a organização proposta obteve
um desempenho satisfatório em todos os aspectos estudados. Verifica-se, também, que as
características da OHP que garantiram o seu bom desempenho, são provindas tanto da
estruturação por células de produção, como da organização por equipes de projetos,
evidenciando que uma estrutura híbrida é, de fato, necessária.

Tabela 8 – Síntese dos resultados da análise da OHP

Aspecto observado Resultado da Característica

OHP estrutural vantajosa
Definição do perfil adequado dos colaboradores Satisfatório Por células
envolvidos
Tamanho da equipe adequado às necessidades do Satisfatório Por células
projeto
Nível de comunicação entre os colaboradores Satisfatório Por projetos
envolvidos
Comprometimento dos colaboradores Satisfatório Por projetos
Eficiência no uso dos recursos humanos e materiais Satisfatório Por células

Considerando-se os resultados apresentados, entende-se que a OHP permite

potencializar os aspectos vantajosos e minimizar os elementos negativos dos dois modelos
originais, conforme sua proposta. Vale ressaltar, também, que o produto final dos projetos,
dois sistemas, foi gerado de acordo com os requisitos especificados, utilizando um time de
desenvolvimento gerenciado a partir das diretrizes da OHP.
Com base nestes resultados, conclui-se que a OHP é efetiva, pois é factível e
possível de ser implantada em uma empresa de desenvolvimento.

55
4.7.1 Considerações Adicionais Sobre os Resultados Obtidos

De acordo com Pfleeger (2001), um mesmo papel funcional pode atuar em mais
de uma etapa (software development step) do processo de software, assim como uma etapa
pode sofrer a atuação de mais de um papel funcional. Verificou-se que essa flexibilidade é
naturalmente garantida pela OHP, já que a equipe de projeto pode atuar livremente em
qualquer etapa do desenvolvimento e as células de produção também podem ser requisitadas
pela equipe de projeto, sempre que necessário, para atuar em alguma etapa do
desenvolvimento.
Após a realização do experimento prático, foi verificado que houve uma
padronização natural, entre os projetos utilizados, dos artefatos, diagramação das telas,
documentos gerados e diretórios de trabalho. Acredita-se que este resultado tenha sido
conseguido devido à incorporação das células de produção na empresa, antes inexistentes. É
inferido que o fato das mesmas pessoas realizarem as mesmas atividades, tenha gerado um
nível natural de reaproveitamento de processos e artefatos, o que pode ter ocasionado a
referida padronização.
Por fim, identificaram-se situações de retrabalho, nas quais algumas rotinas
desenvolvidas pelas células de produção tiveram que ser refeitas pelas equipes de projeto.
Acredita-se que o fato ocorreu devido à falta de um processo consistente de transferência de
informações e comunicação entre as equipes de projeto e as células de produção.

4.8 Limitações do Experimento

O experimento prático realizado sofreu algumas limitações causadas,

basicamente, pelo número restrito de projetos e colaboradores.
No estudo foram utilizados dois projetos, que implicaram na formação de duas
equipes, e doze colaboradores. Essa situação restringiu uma investigação abrangente acerca
do processo de negociação para o uso das células de produção, da determinação de

56
prioridades das atividades das células e da necessidade de institucionalização de um plano de
gerência da comunicação15 específico para tratar a interação entre os elementos da OHP.

15
A definição e requisitos para um Plano de Gerência da Comunicação (Communication Management Plan), são
apresentados no PMBOK 2000, p. 119.

57
5 CONCLUSÃO

O presente trabalho propôs uma estrutura organizacional alternativa para fábricas

de software, baseada em duas formas de organização da produção comumente utilizadas
atualmente: as estruturações por equipes de projeto e por células de produção. A análise
comparativa dessas duas estruturas organizacionais foi feita com base em um conjunto de
aspectos identificados como relevantes para as atividades envolvidas na produção de sistemas.
A pesquisa bibliográfica constatou que cada um dos modelos em questão, quando considerado
isoladamente, revela vantagens e desvantagens inerentes que se evidenciam, inclusive, de
acordo com as características do projeto de software que estiver sendo realizado. Dessa forma,
foi evidenciada a necessidade de um estudo mais criterioso acerca do assunto, que culminou
com a proposta de uma alternativa para a organização da produção em fábricas de software,
chamada de Organização Híbrida da Produção (OHP). A OHP teve como principal objetivo
potencializar as vantagens e minimizar as desvantagens dos aspectos identificados como
relevantes para a organização da produção em empresas de desenvolvimento de sistemas.
Com o objetivo de determinar a efetividade da OHP, foi realizado um estudo de
caso envolvendo dois projetos de desenvolvimento de software. No experimento prático, a
OHP foi analisada frente aos aspectos previamente identificados, de sorte a verificar se sua
utilização é factível. Em consonância com a análise feita no referencial teórico, o estudo de
caso evidenciou que a estrutura proposta obteve resultados satisfatórios em todos os aspectos
analisados; além disso, o produto final dos projetos, dois sistemas, foi completamente gerado,
utilizando um time de desenvolvimento gerenciado de acordo com as premissas da
formulação proposta. Considerando estes resultados, conclui-se que a efetividade da OHP está
comprovada.
O presente trabalho, ao contrário de abordar temas como metodologia de
desenvolvimento, modelo de processo de software, tipos de ciclos de vida ou ferramentas de
automatização, que são comumente tratados nos trabalhos em engenharia de software,
investiga a influência de um fator que, geralmente, deixa de ser analisado com a devida
importância: a estrutura organizacional da empresa. A relevância do estudo se dá pela sua
própria natureza, que suscita a necessidade de uma investigação futura mais efetiva acerca da
influência da organização da produção na qualidade e produtividade das fábricas de software.

58
Sendo assim, são sugeridos trabalhos futuros, com o objetivo de buscar o aperfeiçoamento e
melhor aproveitamento da OHP.
Um fator passível de ser investigado seria o impacto da utilização da OHP na
produtividade e qualidade dos projetos de software. Essa análise poderia ser feita através da
utilização de métricas como pontos por função ou pontos por casos de uso, para análise da
produtividade. Já a investigação do impacto na qualidade dos projetos, poderia ser feita com
base em métricas como o número de erros encontrados nos sistemas, índice de reclamação
dos clientes, categoria das manutenções solicitadas etc.
Outra linha de pesquisa com grande poder elucidativo em relação a OHP seria a
investigação do comportamento da estrutura proposta para uma fábrica de software com um
grande número de colaboradores (por exemplo, superior a 100 funcionários), envolvendo
diversas equipes de projeto e células de produção. Tal estudo poderia se concentrar em
mecanismos de controle e negociação dos prazos e prioridades envolvendo demandas de
diversos projetos simultaneamente. As limitações de recursos do estudo de caso aplicado
neste trabalho impediram que uma análise desta natureza pudesse ter sido realizada.
Outro aspecto passível de ser trabalhado seria a especificação das formas de
comunicação entre as células de produção e as equipes de projeto. Nesta linha de pesquisa,
poderia ser analisada qual a melhor maneira de formalizar a transferência de informações
entre as entidades envolvidas, seja por meio de procedimentos documentados ou sistemas
informatizados. Apesar deste ponto não ter sido abordado no presente trabalho, o experimento
prático realizado, apontou que a utilização com sucesso da OHP, sem uma formalização nos
processos de comunicação específica para a estruturação proposta, só foi possível devido ao
limitado número de pessoas, células de produção e equipes de projeto.
Por fim, uma quarta linha de pesquisa que poderia ser adotada, seria estabelecer
padrões para a delegação de atividades para a célula de produção ou para a equipe de projeto.
O estudo de caso realizado apontou, empiricamente, que alguns tipos de atividade têm um
melhor desempenho quando executadas por uma estrutura ou outra. Nesta linha de pesquisa,
poderiam ser investigados quais tipos de atividades se adequam melhor a cada estrutura, qual
o perfil profissional mais indicado a cada atividade e em quais fases as delegações são mais
vantajosas. Investigações deste tipo, naturalmente, não foram feitas no presente trabalho, pois
fogem ao escopo do projeto.
A OHP vem a ser mais uma alternativa de organização da produção que pode ser
utilizada pelas fábricas de software, no intuito de minimizar os problemas e maximizar as
vantagens das estruturas organizacionais tradicionais. Sua adoção, assim como a utilização de

59
outras formas de organização da produção, é uma decisão a ser tomada pelos administradores
da fábrica de software, levando em consideração as necessidades, cultura organizacional da
empresa e tipos de projetos realizados.

60
 REFERÊNCIAS BIBLIOGRÁFICAS

BARTIÉ, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002.

CMU-SEI, The Capability Maturity Model (CMM) – Guidelines for Improving the Software
Process. Addison-Wesley, 1993.

CURTIS, Bill; STATZ, Joyce. Building the case for software process improvement. In: SEI
NATIONAL CONFERENCE SOFTWARE ENGINEERING PROCESS GROUP, Atlanta,
1996.

GHEZZI, Carlo. Fundamentals of software engineering. Prentice-Hall. New Jersey,1991.

p.441 a p.447.

FERNANDES, Agnaldo. Fábrica de Software: implantação e gestão de operações. São

Paulo: Atlas, 2004.

FERNANDES, Agnaldo. O paradigma da fábrica de software: itens qualificadores e

ganhadores de pedido e práticas das empresas de informática no Brasil. Tese de Doutorado.
Universidade de São Paulo, São Paulo, 2000.

HELDMAN, Kim. Gerência de Projetos. 2ª ed. Elsevier, Rio de Janeiro, 2005.

MACHADO, Cristina. Definindo processos do ciclo de vida de software usando a norma

NBR ISO/IEC 12.207. Lavras: Universidade Federal de Lavras – UFLA, 2003. p. 9-10.

MAGALHÃES, Ana; MACIEL, Rita. RUXP: Integrando o RUP e o XP em uma Metodologia

para o Desenvolvimento de Software. CienteFico. Ano III, v. II, julho-dezembro, Salvador,
2003.

MEDEIROS, Viviane; et al. - Fábrica de Software: da definição às lições aprendidas. XXX

Latin-American Conference on Informatics, Arequipa, Peru, 2004

PFLEEGER, Shari. Software Engineering: theory and practice. Segunda Edição. Prentice-
Hall, Upper Saddle River, 2001.

PMBOK 2000. A Guide to the Project Management Body of Knowledge. 2000 ed. Project
Management Institute. Newtown Square, 2000

PRESSMAN, Roger S. Software Engineering – A Practitioner’s Approach. 4. ed. New York.

McGraw-Hill, 1997

ROCHA, Allan; et al. Estrutura Organizacional Híbrida para Fábrica de Software. SUCESU
2005 – Congresso Nacional de Tecnologia da Informação e Comunicação, Belo Horizonte,
2005.

ROYCE, Walker. Software Project Management: a unified framework. Addison-Wesley,

Indianapolis, 1998.

61
SOMMERVILLE, Ian. Software Engineering. 6th Ed. Pearson Education Limited, 2000.

SWEBOK. A Guide to the Software Engineering Body of Knowledge. 2004 ed. IEEE. USA,
2004

THE STANDISH GROUP. Chaos. 1995. Disponível em: <www.standishgroup.com>. Acesso

em: 01 mai 2004.

TARTARELLI, Rubens, WINCKLER, Walter, KRONMEYER Oscar. Aprendizagem

Organizacional em Fábricas de Software, UNISINOS – Universidade do Vale do Rio dos
Sinos, 2003.

UNITECH – Tecnologia da Informação. Disponível em: <www.unitech.com.br>. Acesso: 24

ago 2004.

VASCONCELLOS, Eduardo, HEMSLEY, James. Estrutura das Organizações: estruturas

tradicionais, estruturas para inovação, estrutura matricial. 3º ed. Editora Pioneira, São Paulo,
1997.

62