1 ESCOPO E COMPLEXIDADE DOS COMPONENTES

DA FBRICA DE SOFTWARE
A complexidade e a profundidade dos componentes da Fbrica de Software variam
conforme seu escopo.
Por exemplo, o controle de requisitos de um escopo de Fbrica de Projetos bem
mais complexo do que o de um escopo de uma Fbrica de Programas.
H alguns casos em que determinados processos aparecem no escopo de Projetos e
no aparecem no escopo de Programas.
A Figura 8.1 apresenta esse entendimento.
Para a aplicao dos componentes do modelo genrico, importante levar em
considerao essa matriz de complexidade de processo.

2 FBRICA DE PROGRAMAS
O objetivo da Fbrica de Programas codificar e testar programas conforme um
acordo de nveis de servios com o cliente ou usurio, considerando especificao padro
de programas, critrios de qualidade e tempo de entrega.
A seguir, apresentado um modelo de Fbrica de Software, considerando o
Framework Geral do Processo de Software proposto pelos autores no Captulo 5 deste livro.
Esse modelo apresenta os componentes requeridos para uma Fbrica de Programas.

2.1

Viso geral do modelo

A Figura 8.2 apresenta o modelo da Fbrica de Programas com seus respectivos

componentes.
Como pode ser observado pelo modelo, os componentes referentes s camadas de
gesto estratgica e da gesto da operao permanecem os mesmos em relao ao modelo
genrico da Fbrica de Software.
Nas camadas de gesto do projeto e do produto, h alteraes.
Na camada de gesto do projeto, os componentes Controle de Risco II, Gesto de
Problemas e Gesto do Teste esto ausentes devido menor complexidade do escopo desse
tipo de fbrica.
Em uma Fbrica de Programas cujo principal insumo uma ordem de servio com
uma especificao de programa (padro), o risco de no atender quase inexistente, j que
trabalhamos com tempos padres calibrados e com consistncia histrica.
J a gesto de problemas (geralmente em funo da ocorrncia de riscos) tambm
no afeta o desempenho. Numa Fbrica de Programas, os eventos que causam interrupo
no atendimento a uma ordem de servio so bem previsveis.
A gesto do teste tambm no preocupante, pois j faz parte da tarefa de
programador, e geralmente somente ele a executa. Praticamente, no h necessidade de
gesto do teste.
A camada de construo alterada por motivos bvios, devido ao escopo da fbrica.

Como j discutimos anteriormente, uma Fbrica de Programas pode trabalhar com

vrias linhas de processos, cada uma correspondendo a um tipo de linguagem de
programao.
A Figura 8.3 faz essa representao.
Cada linha de processo tem suas peculiaridades em termos de perfil da mo-de-obra,
software de apoio, mtodos e tcnicas de construo, padres de programao, nvel de
reutilizao de componentes ou rotinas, mtodos de estimativas de tempo, esforo e custo, e
assim sucessivamente.
Veremos alguns requisitos considerados fundamentais para uma Fbrica de
Programas.

2.2

Requisitos da fbrica de programas

Para a Fbrica de Programas ser uma operao bem-sucedida em termos de ter

consistncia no atendimento s ordens de servio, ser lucrativa ou ter uma operao de
baixo custo para a organizao, alguns fatores-chaves de sucesso devem ser entendidos. A
seguir, discutimos sobre os que consideramos principais.

2.2.1 Demanda
O volume de demanda para uma Fbrica de Software crtico para seu sucesso.
Ao negociarmos com nossos clientes externos ou internos, imprescindvel que
haja uma demanda mnima mensal para ser atendida pela Fbrica (se no h essa demanda
mnima, o prejuzo na operao muito provvel).
Essa demanda pode ser negociada em nvel de homens/hora ou em nmero de
pontos de funo, por exemplo.
Quando do planejamento da capacidade da fbrica, importante tambm saber os
picos da demanda, pois isso pode influenciar negativamente nos acordos de nveis de
servio.
O compromisso de demanda mnima deve ser negociado e colocado em contrato,
assim como o tempo necessrio para ajustes na fbrica que visam ao atendimento de uma
nova linguagem de programao.
Grandes flutuaes de demanda devem ser informadas com antecedncia pelo
cliente. Quando ocorrem grandes flutuaes temporrias, deve ser previsto em contrato
acordo de nveis de servios flexveis. Por exemplo, vai-se gastar mais tempo para atender a
uma ordem de servio.

2.2.2 Ordens de Servio

Podemos trabalhar de acordo com as premissas do cliente? Nem sempre.
A Fbrica de Programas deve ter, independentemente do padro do cliente, seu
padro de ordens de servio e seu padro de especificao de programas (para cada tipo de
linguagem de programao utilizada pela fbrica).
Numa negociao, o importante comearmos a impor nosso padro, j que
qualquer alterao pode acarretar custos de ajustes internos nos processos da fbrica.
Por isso, importante o planejamento da introduo de um novo cliente na fbrica.

Caso o cliente queira usar o padro dele, devemos analis-lo e, se for o caso, sugerir
melhorias que visam garantir a qualidade da operao da Fbrica de Software.
De qualquer forma, deve haver um padro (podemos ter tantos quantos forem os
clientes da fbrica) que garanta a execuo das tarefas com a qualidade requerida.
Devemos incluir em contrato o padro a ser seguido.

2.2.3 Regras de Comunicao e de Interfaces com

o Cliente
Para um relacionamento bem-sucedido entre o cliente e a Fbrica de Programas,
prefervel que haja somente um ponto de contato entre ambos.
Do lado do cliente, deve haver um responsvel por organizar a demanda e envi-la
para a fbrica, gerenciar os nveis de servio, as questes contratuais e demais negociaes
do dia-a-dia.
Do lado da fbrica, um responsvel pelo recebimento das ordens de servio e pela
expedio do produto para o cliente.
Algumas regras devem estar claras, e de preferncia colocadas em contrato,
prevendo alguns tipos de eventos, tais como:

uma ordem de servio pode ser recusada se no estiver no padro

estabelecido;

caso uma ordem de servio no esteja completa, a fbrica pode

solicitar complemento;

cliente pode enviar complemento a qualquer momento para a fbrica:

os prazos de atendimento s ordens de servio devem ser, de

preferncia, padres e do conhecimento prvio do cliente;

o cliente deve ter acesso a informaes sobre o progresso da

execuo de sua ordem de servio;

a fbrica pode solicitar tempos de tolerncia (inclusive em nvel da

acordo de servio) para atendimento s ordens de servio;

o cliente pode substituir uma ordem de servio por outra de mesma

complexidade;

servio;

o cliente pode solicitar o cancelamento e a suspenso de ordens de

uma ordem de servio pode retornar para a Fbrica de Programas

para ser consertada;

o cliente deve fornecer feedback para a fbrica sobre a qualidade dos

programas, quando os mesmos so consertados por ele prprio (ou seja, no
retornam);

o cliente pode pedir auxlio fbrica, em termos de pessoal, que

elabore especificaes de programas (nesse caso, pense em criar uma Fbrica de

Projetos Fsicos e agregue mais valor ao "negcio").

2.2.4 Estimativas
A fbrica tem que ter tabelas padres de estimativas de tempo de atendimento de
uma ordem de servio (o que chamamos de lead time) e tempos padres de esforo efetivo
de programao (esta para uso interno).
As tabelas padres devem ser construdas para cada linguagem de programao. No
princpio, so baseadas na experincia do prprio pessoal.
Uma alternativa de construo de uma tabela desse tipo fazer uma comparao
com outras fbricas existentes no mercado.
O cliente deve usar as tabelas de estimativa quando enviar as ordens de servio para
a Fbrica de Programas, ou seja, ele j sabe quanto tempo vai ser despendido para receber
os programas codificados.
Casos em que no se devem usar tabelas padres: quando a tecnologia nova,
emergente, ningum ainda conhece. Nesse caso, a estimativa feita ordem por ordem.
As tabelas padres de tempos de atendimento geralmente fazem parte do acordo de
nvel de servio.
Essas regras devem estar claras no contrato de prestao de servios.

2.2.5 Novos Servios e Novas Linhas

Toda introduo de nova linha de programao na fbrica deve ser planejada para
no causar grande ruptura em seu padro de desempenho.
Portanto, alguns cuidados devem ser levados em considerao:

criar um "laboratrio" para experimentar a nova tecnologia ou o

novo servio, separado das linhas de produo de servios que j estejam bastante
padronizadas;

planejar os ajustes que devem ser feitos em mtodos de estimativas,

software, treinamento de pessoal, mtodos de programao, expanso de hardware
etc.;

elaborar uma anlise de custo-benefcio; s vezes, o tamanho da

demanda e o tempo do contrato no compensam o investimento nos ajustes;

implantar a nova linha como se fosse um projeto, com um gerente

designado, com um plano bem elaborado e os controles tpicos de prazo. custo,
escopo e qualidade.
Em certas ocasies, o investimento feito com base nos planos estratgicos da
empresa para a operao ou, na existncia de um mercado promissor, para a nova linha de
servio. Mesmo assim, deve-se fazer uma anlise de retorno do investimento.
Sempre que possvel, negociar a amortizao total ou parcial do investimento com o
cliente atravs de acrscimos no preo da unidade de venda da fbrica (horas ou grau de
complexidade do programa ou unidades de programao).
Quando a instalao da fbrica for dedicada para um cliente, sua amortizao deve

ser paga pelo cliente.

2.2.6 Acordos de Nveis de Servios

Os acordos de nveis de servios so atributos de desempenho requeridos do cliente
e geralmente so objetos de clusulas contratuais.
O acordo de nvel de servio tambm baliza o faturamento (ou transferncia de
custo) para a fbrica.
prtica de mercado penalizar o faturamento da fbrica caso os nveis de servios
no sejam atendidos e dar um bnus sobre o faturamento se forem ultrapassados.
Os principais acordos de nveis de servios so:

atendimento aos tempos padres de processamento das ordens de

servio, ou seja, percentual das ordens que so completadas no tempo prometido;

atendimento no prazo prometido para a entrega da ordem de servio

completada (quando tabelas de tempos padres no so usadas);

ordens de servio que retornaram com problemas de qualidade;

percentual das ordens de servio com problemas da qualidade;

percentual de ordens de servio que usaram o tempo padro de

tolerncia (tempo adicional de tolerncia em relao ao tempo padro);

tempo para que a fbrica instale uma nova linha de servio

(programao);

ordens de servio recebidas pela fbrica com especificaes

incompletas (esta da fbrica com o cliente).
Os nveis de servios so representados por valores. Por exemplo, 95% de taxa de
entrega no prazo padro ou 10% do uso do tempo de tolerncia.
Os responsveis pela Fbrica de Software devem ter muito cuidado ao negociar os
nveis de servio.
Algumas "dicas" importantes:

os nveis de servios requeridos pelos clientes podem estar baseados

em uma histria junto a outros prestadores de servios que com o tempo j
chegaram a um alto nvel de consistncia no atendimento dos prazos; negociar,
portanto, valores abaixo do requerido por um prazo determinado de acomodao,
digamos trs meses;

o acordo de nvel de servio de qualidade deve ter avaliao objetiva

por parte do cliente ou do usurio quanto aos defeitos encontrados na ordem de
servio que deve retornar para a fbrica (no pode ter subjetividade na avaliao);

em situaes de grande flutuao de demanda, rever os valores dos

nveis de servio para baixo;

dados e informaes de incremento de produtividade so

extremamente sensveis e confidenciais da fbrica; se forem de conhecimento do
cliente, ele ir requerer aumento nos valores dos nveis de servio, o que pode

diminuir a margem de rentabilidade das operaes da fbrica;

evite a avaliao dos nveis de servio mensalmente; avali-los em

intervalos maiores do que um ms, para dar tempo de recuperao do padro de
desempenho sem grandes presses de prazo, pois a presso pode prejudicar a
produtividade da operao;

todo acordo de nvel de servio e suas respectivas regras, inclusive

frmulas matemticas de medio, devem estar presentes no contrato de prestao
de servios.

2.2.7 Mtricas
Independentemente dos acordos dos nveis de servio, a Fbrica de Programas deve
implementar outras mtricas para sua gesto.
Nesse contexto, as principais mtricas referem-se a:

exatido das estimativas (da tabela padro de tempo e esforo) e dos

prazos comprometidos com o cliente, visando calibrao contnua das estimativas;

produtividade da Fbrica de Programas por linhas de servio (cliente,

linguagem e plataforma) e no tempo;

produtividade de cada um dos programadores no tempo;

taxa de entrega das ordens de servio no prazo;

taxa de uso dos tempos de tolerncia;

taxa de ordens de servio com problemas de qualidade;

freqncia dos tipos de defeitos em ordens de servio com problemas

de qualidade;

custo mdio de uma ordem de servio (estratificado por cliente,

plataforma e linguagem de programao);

capacidade da fbrica em termos do nmero de ordens de servio

com possibilidade de serem atendidas no perodo de um ms.
Adicionalmente, a administrao da fbrica deve ter uma viso das tendncias dos
indicadores e conhecimento da mudana brusca de seu comportamento, visando subsidiar
rpidas aes gerenciais de melhoria de aspectos da operao.

2.2.8 Flexibilidade
Uma Fbrica de Programas tem que ter flexibilidade de atendimento demanda.
A flexibilidade somente conseguida atravs dos programadores e do programa de
parceria que a fbrica venha a ter.
Cada programador deve ser expert em mais de uma linguagem de programao. Por
exemplo, ter domnio sobre uma linguagem de plataforma distribuda e duas de mainframe
ou vice-versa. Portanto, o treinamento contnuo e monitorado crtico.
A alternativa de usar parceiros, principalmente aqueles que tm flexibilidade de
atender a flutuaes da demanda da fbrica, uma boa opo quando a capacidade da

fbrica j est esgotada no perodo.

Se isso ocorrer com freqncia, ver a possibilidade de expandir a capacidade da
Fbrica de Software.
Para fins de segurana, trabalhar com mais de um parceiro.

2.2.9

Suprimento de Recursos Humanos

Em perodos normais de demanda de programao, o suprimento contnuo de

recursos humanos para a fbrica crtico.
H naturalmente rotatividade de pessoal em Fbricas de Programas. O motivo que
o programador quer ser analista algum dia. Mesmo que haja mobilidade dentro da
organizao, a fbrica, na maioria das vezes, acaba perdendo o recurso.
H tambm a necessidade de a fbrica liberar recursos humanos com maior
experincia, visando reduo de custos da operao.
Geralmente, o percentual de programas que exige programadores experientes
muito pequeno se comparado ao que exige programadores iniciantes ou juniores.
A fbrica deve montar algum esquema de formao e preparao contnua de mode-obra, ou por conta prpria ou atravs de convnios com escolas tcnicas ou faculdades.

2.2.10 Controle da Produtividade

O controle da produtividade primordial para a fbrica, alm da composio do
custo da mo-de-obra.
Nveis de servio com pouca margem de manobra exigem um controle rigoroso da
produtividade individual de cada um dos programadores.
A produtividade individual pode ser medida pelo nmero de linhas de cdigo geradas (descontando cdigo reutilizado) pelo esforo de homens-hora para produzi-las.
O aumento da produtividade pode ser incrementado atravs da reutilizao, de
treinamento e de padronizao de tcnicas de programao e do feedback de qualidade ao
pessoal da produo.
O controle da produtividade tambm pode ser usado para se descobrirem prticas
melhores de se fazer a tarefa, a partir do entendimento dos motivos das maiores
produtividades individuais registradas.

2.2.11 Uso de Padres Internos

Toda a Fbrica de Programas deve ter seus padres de especificao, de tcnicas de
programao, de estrutura de programas, de plano de teste unitrio e de teste unitrio.
Todo programador da fbrica deve trabalhar da mesma forma.
Esses padres devem ser diariamente reforados e disseminados.

2.2.12 Questo dos Riscos e da Segurana

Este um item de grande importncia para quem est comprando servios de
Fbrica de Software.
O cliente quer saber como suas especificaes e seus programas sero protegidos

para que no sejam usados por terceiros ou por concorrentes, que se utilizam da mesma
Fbrica de Programas.
Outra questo freqentemente levantada pelos clientes quanto ao Plano de
Contingncia (ou de risco) para a operao, visto que pode afetar seu prprio negcio.
Nesse item, a fbrica deve demonstrar capacidade de garantir esses requisitos.
Alternativas freqentemente usadas pelas fbricas so:

criar ambiente distinto dos demais considerando pessoas, servidores,

controle de configurao etc.;

instalar um site especfico para o cliente, prximo casa do cliente e

totalmente dedicado e segregado dos demais processos, com exceo dos
instrumentos de gesto da fbrica, que devem ser os mesmos;

utilizar um Internet data center com equipamentos totalmente dedicados a cada cliente.
Outra questo que est vindo tona quanto implementao de normas de
segurana da informao, como a BS7799 (British Standard) ou ISO 17799.
Podemos dizer que a fbrica certificada nessa norma um item ganhador pedido,
principalmente para clientes internacionais.

2.2.13 Certificaes de Qualidade

Os modelos de qualidade de software ou aplicveis, tais como o CMM, ISSO e
PMI, por exemplo, implementados e usados de fato, podem trazer grande diferenciao
para a Fbrica de Software tanto do ponto de vista da excelncia da operao, como do
ponto de vista de marketing.
Em licitaes governamentais, o CMM e a ISO so itens qualificadores, ou seja,
quem tem j sai com vantagem.
No caso de estabelecimento de plataformas offshore, o CMM um item qualificador.
A mais nova vedete no cenrio de certificao o modelo CMMI, que est
substituindo o CMM.
No Brasil, grandes compradores de servios de Fbrica de Software comeam a
selecionar o fornecedor com base em sua qualificao e certificao em modelos da
qualidade.
preciso estar atento a esse item, pois comeamos a entrar na onda das
certificaes. J existem vrias Fbricas de Programa no Brasil certificadas em nvel 2 e at
3 do CMM e algumas j partindo para o CMMI nvel 3.
Se os investimentos para essa empreitada so altos, procure montar consrcios
(grupos de empresas) para compartilhar custos da equipe de implementao de um modelo
desse tipo.

2.2.14 Compartilhamento de Recursos

Devemos estar atentos para a forma como organizamos a Fbrica de Software. Ela
deve privilegiar o compartilhamento dinmico de recursos humanos para atender

demanda.
Isso significa dizer que um recurso humano da fbrica e no de uma clula de
produo. A clula "lgica". Podemos estabelecer a organizao por clula, porm sempre
tendo em mente que um recurso pertence temporariamente clula. Com isso, evitamos
que uma clula esteja sobrecarregada e outra ociosa.
O compartilhamento dinmico de recursos humanos vital para o atendimento aos
acordos de nveis de servios e para manter a produtividade da fbrica.

2.2.15 Busca por Locais de Baixo Custo

No Brasil, h cidades de tamanho mdio, prximas de centros de formao de
primeira linha, e de custo bastante razovel em termos de instalaes e mo-de-obra.
Os custos da mo-de-obra em grandes cidades esto ficando proibitivos.
Uma soluo para reduzir o custo da operao instalar a fbrica em cidades de
baixo custo de mo-de-obra.

2.2.16 Automao da Fbrica de Software

Voc no vai conseguir controlar uma fbrica na mo.
Procure as solues existentes no mercado para automatizar o controle das ordens
de servios e estabelecer um workflow.
O cliente atualmente presta muita ateno nas ferramentas de gesto da Fbrica de
Software.
O sonho de todo cliente ter acesso aos dados de suas ordens de servio a qualquer
momento, de qualquer lugar. Em tese, a fbrica poderia passar para o cliente a
responsabilidade por fazer o PCP de sua operao dedicada.
Lembramos que, sem automao, os nveis de servios so difceis de ser medidos,
podendo acarretar perdas bastante grandes para a operao.

2.3

Alternativa de estrutura organizacional

A estrutura organizacional de uma Fbrica de Programas deve ser construda com

base em seus componentes e nas tecnologias de processo escolhidas.
A Figura 8.4 apresenta uma alternativa de estrutura organizacional para a Fbrica de
Programas, considerando o agrupamento dos componentes do modelo genrico. Logo aps,
apresentada o Quadro 8.1, que mostra os relacionamentos entre os componentes da
fbrica e unidades da estrutura organizacional proposta.

2.4

Organizao da produo

Alm da estrutura organizacional, outro aspecto importante da Fbrica de

Programas a forma de organizar a produo.
A forma mais comum a da organizao por clulas de produo, geralmente
condicionada pela linha de servio (linguagem de programao).
Os elementos que devem ser considerados para a organizao da produo so,
basicamente, as linhas de servios, clientes, tipos de sites (dedicados a clientes ou no) e
distribuio geogrfica dos sites.

A Figura 8.5 mostra o esquema da organizao da produo e exemplifica um

cenrio em que:

h sites da Fbrica de Programas dispersos geograficamente;

h sites de produo dedicados e no dedicados a clientes;

as funes de gesto da operao podem estar centralizadas em

relao a todos os sites;

os processos de construo esto sempre ocorrendo ao nvel de cada

site;

o processo de controle da qualidade pode estar distribudo conforme

for o tamanho da operao.
Uma coisa que devemos observar que, com as facilidades da Internet, podemos
literalmente distribuir somente a camada de construo do software; o restante mantido de
forma central. Elimina-se a possibilidade de duplicao de esforos.

2.5

Fluxo operacional principal do modelo

Uma Fbrica de Programas apresenta vrios fluxos de produto e informao. Esses

fluxos fazem a interao entre as camadas do framework proposto. Por exemplo, h fluxos
para a gesto da qualidade, compliance etc. A Figura 8.6 ilustra um exemplo de um fluxo
bsico operacional da Fbrica de Programas e a participao de unidades da estrutura da
Fbrica no mesmo.

2.6
O que vital para comear a Fbrica de
Programas
A Figura 8.7 apresenta, em nosso entender, o que preciso no primero minuto de
jogo para comear a operar uma Fbrica de Programas, alm, claro de instalaes e
recursos computacionais adequados.
Em um primeiro momento, a Fbrica de Programas pode comear a usar o prprio
pessoal da produo para o suporte de software e em engenharia de software. Para tanto,
no necessita de uma equipe voltada para o suporte em engenharia de software e outra para
o suporte tcnico.
A camada de gesto da operao e do projeto deve ter um nvel adequado de
automao, que visa implementar controles de demanda, tracking das ordens de servio e
controle de recursos.
Algumas fbricas no mercado comeam com um conjunto de planilhas para fazer
esse trabalho. Quando uma coisa muito pequena e no h grande visibilidade junto ao
cliente, at passa. Se, porm, a operao j tiver mais de 20 a 30 profissionais e
visibilidade, ento recomendvel que existam aparatos mais slidos de controle.

2.7
O que pode ser terceirizado pela Fbrica
de Programas
Para manter o custo da fbrica em um patamar competitivo, devemos definir o que
se pode constituir em custo varivel.

Algumas atividades candidatas so:

auditorias de compliance;

auditorias nos sistemas de qualidade;

suporte em engenharia de software;

estratgico;

suporte na elaborao de planejamentos de tecnologia, de riscos e

execuo de treinamentos;

servios de suporte em infra-estrutura;

demanda).

eventualmente, execuo de ordens de servio (quando h excesso de

3 FBRICA DE PROJETOS
O objetivo da Fbrica de Projetos o de desenvolver e manter softwares conforme
um acordo de nveis de servios com o cliente ou usurio, considerando requisitos de prazo,
custo, qualidade e escopo.
A seguir, apresentado um modelo de Fbrica de Projetos, considerando o
"Framework Geral do Processo de Software", proposto pelos autores no Captulo 5 deste
livro.
Esse modelo apresenta os componentes requeridos para uma Fbrica de Projetos.

3.1

Viso geral do modelo

A Figura 8.8 apresenta o modelo da Fbrica de Projetos com seus respectivos

componentes.
Como pode ser observado na Figura 8.8, todos os componentes do modelo genrico
esto presentes na Fbrica de Projetos.
A Fbrica de Projetos tanto trabalha com novos desenvolvimentos, como manutenes evolutivas, legais e de otimizao, como pode acolher atendimento a projetos
fsicos somente.
Tudo depende do nvel da interface com o cliente, ou seja, h situaes em que o
cliente que faz a parte de especificao do software e a fbrica executa somente da parte
fsica para a frente.
Outra diferenciao que a Fbrica de Programas pode fazer parte da Fbrica de
Projetos.
Podemos imaginar tambm uma "Fbrica de Testes" fazendo parte da Fbrica de
Projetos, principalmente se a misso da empresa for o desenvolvimento de softwares
produtos (pacotes de gesto etc.).
A Fbrica de Projetos de Software mais simples aquela que focaliza somente
novos desenvolvimentos ou projetos fsicos.
A Fbrica de Projetos mais complexa medida que comea a atender clientes de

indstrias diferentes. Quando a fbrica focaliza poucos clientes do mesmo ramo de negcio,
ela pode ganhar escala em funo da especialidade.
Outros trs fatores de aumento de complexidade so o desenvolvimento de projetos
de software aplicativos em mltiplas plataformas, sua manuteno posterior e o nvel de
integrao entre os aplicativos.
As linhas de processo da Fbrica de Projetos tambm apresentam diferenciao,
medida que avanamos no ciclo de vida do desenvolvimento do software.
Por exemplo, em nvel de especificao de requisitos, o conhecimento requerido
do negcio; portanto, a organizao da linha deve ser por negcio. Imagine uma Fbrica de
Projetos atendendo a um banco comercial; teramos uma linha para aplicativos de
vanguarda (caixa e auto-atendimento), para a gesto (administrao de risco) e para as
aplicaes (poupana), e assim sucessivamente.
Entretanto, em relao ao desenvolvimento do projeto, o conhecimento requerido
sobre a arquitetura dos softwares que do sustentao ao negcio e tecnologia especfica
de projeto detalhado, de construo e das ferramentas que apiam o ambiente. muito
comum encontrarmos ambientes de testes automatizados para a plataforma distribuda
distintos dos ambientes de testes para a plataforma Mainframe.

3.2

Requisitos da Fbrica de Projetos

Para a Fbrica de Projetos ser uma operao bem-sucedida e ter consistncia no

atendimento s ordens de servio, ser lucrativa ou uma operao de baixo custo para a
organizao, alguns fatores-chaves de sucesso devem ser entendidos. A seguir, discutimos
sobre os que consideramos principais.

3.2.1 Demanda
Uma Fbrica de Projetos pode apresentar basicamente trs grandes tipos de
demandas, quais sejam: novos desenvolvimentos, manuteno de sistemas e projetos fsicos
(que geralmente fazem parte da manuteno, mas podem ser considerados separadamente).
Por manuteno tambm podemos entender "customizaes" de softwares, como
software de Enterprise Resource Planning, Customer Relationship Management, Billing
etc.
Geralmente, a demanda de novos projetos no apresenta escala. Cada projeto uma
equipe diferente.
O mesmo no ocorre com a manuteno e os projetos fsicos. Ambos tm o mesmo
comportamento da Fbrica de Programas, ou seja, podem ter escala.
O principal tipo de demanda que a Fbrica de Projetos deve negociar a de
manuteno e projetos fsicos, que pode ser negociada em termos de volume de homenshora ou pontos de funo.
Acordos de nveis de servio podem ser estabelecidos para cada tipo de demanda;
entretanto, tratando-se de novos projetos os acordos so individuais, por projeto.
Aqui tambm compromissos de demanda mnimos devem ser negociados com o
cliente, principalmente em termos de manuteno e projetos fsicos.
Em relao a novos projetos, a negociao deve ser em funo dos tipos de

plataforma de desenvolvimento que a fbrica deve possuir para atender ao cliente;

mudanas previstas nas plataformas devem ser informadas para a Fbrica de Projetos com
bastante antecedncia.
Todos os compromissos devem ser colocados em contrato.
Previso de flutuao da demanda deve ser informada com antecedncia pelo
cliente. Quando ocorrem grandes flutuaes temporrias, deve ser previsto em contrato
acordo de nveis de servios flexveis.

3.2.2 Ordens de Servio

Aqui as ordens de servio j so bem mais complexas, pois tratam dos requisitos
preliminares do cliente ou usurio.
A principal entrada para a Fbrica de Projetos a especificao preliminar do
software (ou declarao do escopo), que deve conter, no mnimo:

funcionalidades esperadas para o software;

onde o software vai ser usado;

por quem vai ser usado;

quando vai ser usado;

restries de uso do software;

legislao que o software deve seguir;

o desenho da arquitetura preliminar do software;

normas internacionais ou outras que deve seguir;

requisitos no funcionais que o software deve atender em termos de

desempenho, esttica, usabilidade, facilidade de manuteno etc.;

requisitos no tcnicos, como prazo do projeto e outras restries.

Podemos trabalhar de acordo com as premissas do cliente? Nem sempre.

Quanto melhor definido estiver o escopo do "projeto", maiores so as chances de
seu sucesso em termos de atendimento ao prazo, custo, escopo e qualidade.
A Fbrica de Projetos tambm deve ter seu padro e ter a capacidade de absorver
rapidamente os padres dos clientes ou usurios.
Como na Fbrica de Programas, o importante a Fbrica de Projetos impor seu
padro. Se for invivel o padro do cliente ou usurio, o mesmo deve ser analisado visando
a sua adequao e possibilidade de melhoria.
De qualquer forma, deve haver um padro (podemos ter vrios quantos forem os
clientes da fbrica) que garanta a execuo das tarefas com a qualidade requerida.
O padro de ordem de servio deve ser fruto do acordo da fbrica com o cliente ou
usurio e estar estabelecido em contrato.

3.2.3 Regras de Comunicao e de Interfaces com

o Cliente
Na Fbrica de Projetos, as regras de comunicao e interfaces com o cliente so
igualmente importantes.
Para um relacionamento bem-sucedido entre o cliente e a Fbrica de Projetos,
prefervel que haja somente um ponto de contato entre ambos.
Aqui, aplicam-se as mesmas regras sugeridas para a Fbrica de Programas.

3.2.4 Estimativas
No caso da Fbrica de Projetos, a questo estimativa mais complexa.
Estimativa aqui se refere a: estimativa de tamanho do software, prazo, esfOro e
custo, principalmente. A estimativa deve ser feita com base na definio do escopo do
projeto.
Quando no temos uma fbrica dedicada, a estimativa no tem como ser feita com
base em dados histricos; quando temos uma fbrica dedicada, possvel construir
estimativas com base em histricos.
Em termos de novos projetos em fbricas no dedicadas, uma alternativa o uso de
tcnicas de estimativa de tamanho de software, como a Anlise por Pontos de Funo
apoiada pelo uso de ferramentas de estimativas de software, tais como a KnowledgePlan,
Slim, COCOMO, Estimate Professional, Costexpert etc.
No caso de novos projetos em fbricas dedicadas, podemos usar uma base de dados
de histricos de projetos no mesmo "negcio" e mesmas caractersticas em termos de
plataforma tecnolgica. Tambm no se pode descartar o uso de tcnicas de estimativa,
como o Ponto de Funo, nem deixar de calibrar ferramentas de estimativas de software
com dados do realizado da fbrica.
No caso de manutenes e projetos fsicos, podemos usar a mesma abordagem
utilizada na Fbrica de Programas, atravs da criao de tabelas padres de estimativa
baseadas em atributos de complexidade da ordem de servio.
Uma forma de construir essas tabelas olhar para trs com base em uma amostra de
ordens de servio, agrupando-as conforme critrios de complexidade e determinando
intervalos de valores para prazo, esforo e custo, considerando valores mdios e desvios
padres.
Para manutenes evolutivas, uma vez que tenhamos o inventrio dos pontos de
funo dos aplicativos em termos de entradas, sadas, interfaces, arquivos lgicos internos
(mantidos pela aplicao) e consultas, tambm podemos empregar a tcnica de Anlise por
Pontos de Funo.
Para manutenes e projetos fsicos (que no sejam corretivas), o cliente j poderia
usar as tabelas de estimativa quando enviar as ordens de servio para a Fbrica de Projetos,
ou seja, ele j sabe quanto tempo vai ser despendido para receber a manuteno
completada.
As tabelas padres de tempos de atendimento geralmente fazem parte do acordo de
nvel de servio.

Essas regras para a Fbrica de Projetos tambm devem estar claras no contrato de
prestao de servios.

3.2.5 Novos Servios e Novas Linhas

Aqui, cabem as mesmas regras aplicadas para a Fbrica de Programao, s que no
caso da Fbrica de Projetos o investimento de introduo de uma nova linha de servio
substancial, uma vez que deve considerar novos mtodos de engenharia de software, novas
ferramentas de apoio, mudanas em sistemas da qualidade, expanso da arquitetura de
hardware da Fbrica, treinamento do pessoal nas novas tcnicas e ferramentas, em novos
mtodos de gesto etc.
Portanto, alguns cuidados devem ser levados em considerao:

criar um "laboratrio" para experimentar a nova tecnologia ou o

novo servio, separado das linhas de produo que j esto bastante padronizadas;

planejar os ajustes que devem ser feitos em mtodos de estimativas,

tcnicas de engenharia de software, treinamento de pessoal, mtodos de
programao, expanso de hardware etc.;

elaborar uma anlise de custo-benefcio; s vezes, o tamanho da

demanda e o tempo do contrato no compensam o investimento nos ajustes;

implantar a nova linha como se fosse um projeto, com um gerente

designado, com um plano bem elaborado e os controles tpicos de prazo, custo,
escopo e qualidade.
Sempre que possvel, negociar a amortizao total ou parcial do investimento com o
cliente atravs de acrscimos no preo da unidade de venda da fbrica (homem-hora).
Quando a instalao da fbrica for dedicada para um cliente, a amortizao deve ser
paga pelo cliente.

3.2.6 Acordos de Nveis de Servios

No caso da Fbrica de Projetos, os acordos de nveis de servios so genricos para
as demandas de manuteno de sistemas e para projetos fsicos e especficos para cada
novo projeto de desenvolvimento.
Como j vimos anteriormente, o acordo de nvel de servio tambm baliza o
faturamento (ou transferncia de custo) da fbrica.
Os acordos de nveis de servios so similares aos da Fbrica de Programas, quais
sejam:

atendimento aos tempos padres de processamento das ordens de

servio; ou seja, percentual das ordens que so completadas no tempo prometido;

atendimento ao prazo prometido para a entrega da ordem de servio

completada (quando tabelas de tempos padres no so usadas);

ordens de servio que retornaram com problemas de qualidade;

percentual das ordens de servio com problemas da qualidade;

percentual de ordens de servio que usaram o tempo padro de

tolerncia (tempo adicional de tolerncia em relao ao tempo padro);

tempo para que a fbrica instale uma nova linha de servio

(desenvolvimento);

ordens de servio recebidas pela fbrica com especificaes

incompletas (esta da fbrica com o cliente);

prazo de entrega do projeto (exemplo de nvel de servio, tolerncia

de 10% de atraso);

densidade de defeitos do software (nmero de defeitos encontrados

no teste de aceitao dividido pelo tamanho do software em pontos de funo). Essa
uma medida da qualidade;

percentual dos requisitos atendidos (nmero de requisitos atendidos

no prazo do projeto sobre o total dos requisitos especificados). Medida de
atendimento do escopo;

desempenho do software em tempo de resposta (um a quatro

segundos) etc.
Os responsveis pela Fbrica de Software devem ter muito cuidado ao negociar os
nveis de servio.
Sugere-se que a Fbrica de Projetos primeiro conhea seus nveis de servio para
depois negociar os acordos.
Os acordos de nveis de servios para as ordens referentes s manutenes de
sistemas e de projetos fsicos podem ser avaliadas em perodos bimensais ou trimestrais.
Os acordos de nveis de servios de projetos podem ser avaliados ao final do projeto
ou tambm a perodos regulares, se houver muitos projetos desenvolvidos simultaneamente.
Por fim, todo acordo de nvel de servio deve ser negociado com o cliente e
colocado dentro do contrato.

3.2.7 Mtricas
Independentemente dos acordos dos nveis de servio, a Fbrica de Projetos deve
implementar outras mtricas para sua gesto.
Nesse contexto, as principais mtricas referem-se a:

exatido das estimativas (realizado em termos de tamanho, prazo, esforo e custo versus estimativas respectivas, apresentando variaes em
percentuais);

produtividade da fbrica em termos de pontos de funo por homemms (produtividade da manuteno e de novos projetos de desenvolvimento);

taxa de entrega das ordens de servio no prazo;

taxa de uso dos tempos de tolerncia;

taxa de ordens de servio com problemas de qualidade;

freqncia dos tipos de defeitos em ordens de servio com problemas

de qualidade;

custo mdio de uma ordem de servio (estratificado por cliente,

plataforma e ambiente de desenvolvimento);

densidade de defeitos padro do software;

taxa mdia de atendimento ao escopo dos projetos;

tempos mdios de desenvolvimento;

distribuio do esforo pelas fases do projeto.

Adicionalmente a administrao da fbrica deve ter viso das tendncias dos

indicadores e conhecimento da mudana brusca de seu comportamento, visando subsidiar
rpidas aes gerenciais de melhoria de aspectos da operao.

3.2.8 Flexibilidade
A flexibilidade a marca da fbrica genrica. Ela tem que ter a capacidade de
implementar uma nova linha de servio rapidamente. Uma das estratgias para a fbrica
genrica ser flexvel atravs do uso de parceiros especialistas. Nesse caso, a fbrica entra
com a expertise em gerenciamento e testes, por exemplo, e o parceiro com o domnio da
tecnologia de desenvolvimento.
J a fbrica dedicada pode ser menos flexvel, pois depende de um nico cliente
para determinar seu direcionamento tecnolgico e as mudanas so feitas com bastante
antecedncia.
De qualquer forma, as pessoas tambm fazem diferena na Fbrica de Projetos. Elas
deveriam estar aptas a trabalhar com metodologias de desenvolvimento tradicionais, como
a Anlise Essencial, e tambm com a Unified Modeling Language (UML). Essa
flexibilidade reduz custo, pois possibilita o intercmbio de profissionais de uma linha de
servio para outra.
Portanto, treinamento contnuo a chave.

3.2.9 Gesto do Conhecimento

Para uma Fbrica de Projetos, a gesto do conhecimento crtica.
Por gesto do conhecimento entendemos: a gesto das habilidades dos
colaboradores da fbrica, dos parceiros, a gesto da documentao e informaes relativas a
tcnicas de gesto de projetos, tcnicas de engenharia de software, documentao dos
processos da fbrica, documentao de sistemas da qualidade, componentes reutilizveis,
informaes bibliogrficas, metodologias, e outras informaes disseminadas pela WEB,
por exemplo.
A gesto do conhecimento acaba com a reinveno da roda e um fator de impulso
da produtividade.
Portanto, deve haver mecanismos para a criao de conhecimento (explcito),
armazenamento, referenciamento e disseminao, conforme privilgios de acesso.

3.2.10 Processo Definido de Desenvolvimento de

Software
A Fbrica de Projetos deve possuir um processo definido de desenvolvimento de
software, considerando fases, etapas, atividades, tcnicas de engenharia de software etc.
A fbrica deve perseguir a implementao de um processo maduro, em que todas as
equipes trabalham da mesma forma. Isso significa ter padres documentados, dentro da
concepo da gesto do conhecimento, disseminados e de fcil acesso.
Alm do mais, esse processo deve ter a habilidade de ser "customizado" para
atender a particularidades de cada projeto.
Esse um fator de aumento de produtividade do desenvolvimento do software.

3.2.11 Questo dos Riscos e da Segurana

Da mesma forma que a Fbrica de Programas, a importncia desse item persiste
com mais fora ainda, pois estaremos lidando com o desenvolvimento de software por
inteiro.
Devemos ter rigorosa poltica de segurana praticada na Fbrica de Projetos, que
garanta de forma transparente a inviolabilidade de especificaes lgicas e fsicas,
especificaes de programas, cdigo gerado e dados de teste.
O Plano de Contingncia tambm uma condio que deve ser satisfeita para a
tranqilidade do cliente e dos usurios.
No caso da Fbrica de Projetos, devemos pensar, seriamente, em adotar sistemas de
segurana como a BS 7799.

3.2.12 Controles da Execuo da Ordem de Servio

Controlar a execuo de uma ordem de servio da Fbrica de Projetos equivale ao
controle de projetos.
Dessa forma, a fbrica deve ter mecanismos e ser capaz de controlar as mudanas
no escopo, no cronograma, no custo, e controlar o risco do projeto, principalmente.
A falta de consistncia no atendimento aos nveis de servio acordados com os
clientes geralmente se refere a um pobre controle de mudanas no escopo.
Esse o principal fator do no-atendimento aos prazos e custos do projeto (ordem
de servio).

3.2.13 Certificaes de Qualidade

No caso da Fbrica de Projetos, certificaes como ISO e at mesmo CMM so
itens qualificados, ou seja, no so maiores elementos de diferenciao.
Se voc ainda no tem um plano a esse respeito, comece a pensar seriamente em ter
um o quanto antes.

3.2.14 Reutilizao de Componentes

Este um fator-chave para a qualidade e a produtividade da Fbrica de Projetos.
Quanto maior a reutilizao, maior a produtividade.
Portanto, e principalmente para as fbricas dedicadas, um fator crtico de sucesso.

Produtividade por meio da reutilizao representa uma operao de custo

competitiva, maior margem de rentabilidade e maior satisfao do cliente ou usurio pelos
tempos menores de entrega.
O pr-requisito instalar um processo de gesto de componentes que deve comear
pela Gesto da Configurao.

3.2.15 Gesto e Controle da Qualidade

A gesto da qualidade em uma Fbrica de Projetos bem mais complexa do que na
Fbrica de Programas e comea desde o recebimento da ordem de servio, passando pelo
controle da qualidade de cada produto gerado ao longo do ciclo de desenvolvimento, assim
como pela garantia de que os processos esto sendo empregados.
A gesto da qualidade urna atividade bsica no mbito da Fbrica de Projetos.

3.2.16 Automao da Fbrica de Projetos

Voc no vai conseguir controlar uma fbrica na mo, muito menos a de Projetos.
A automao no somente da gesto. da gesto e da produo.
Aqui, devemos pensar, alm da automao da gesto da demanda, em ferramentas
de gesto da configurao, controle de requisitos, modelagem de software, automao do
teste de software etc.
, talvez, um dos maiores itens de investimento no mbito de uma Fbrica de
Projetos.

3.3

Alternativas de estrutura organizacional

A estrutura organizacional de uma Fbrica de Projetos deve ser construda com base
em seus componentes e de seu foco, assim como nas tecnologias de processo escolhidas.
As Figuras 8.9 e 8.10 apresentam alternativas de estrutura organizacional para a
Fbrica de Projetos, considerando a dicotomia das fbricas no dedicadas e dedicadas.
Um aspecto a considerar acerca da Fbrica de Projetos que aglutinamos em uma
rea nica o controle da qualidade com os testes. Portanto, essa rea responsvel pelas
inspees e gesto dos testes de todos os produtos de software gerados pelos projetos. A
rea tambm pode ser a responsvel por autorizar a implantao do software no cliente ou
usurio.

3.4

Organizao da produo

Alm da estrutura organizacional, outro aspecto importante da Fbrica de Projetos

a forma de organizar a produo.
Podemos vislumbrar vrias alternativas de organizao da produo. Entretanto,
vamos focar uma fbrica genrica e uma dedicada a um cliente.

3.4.1 Cenrio da fbrica genrica no dedicada

fbrica genrica: aceita qualquer tipo de projeto em determinadas

plataformas e no se especializa no domnio das respectivas aplicaes; pode,
entretanto, atuar em mercados verticais;

atende prioritariamente a novos projetos de desenvolvimento;

pode ter centros de desenvolvimento dispersos geograficamente ou

no;

a produo organizada conforme as fases do ciclo de vida em

equipes diferentes, em equipes dedicadas especificao e em equipes dedicadas
por plataformas tecnolgicas (mainframe e plataforma distribuda);

pode possuir um Project Management Office (PMO) para o suporte a

todo o gerenciamento dos projetos, fazendo a integrao;

a Fbrica de Projetos pode (no necessariamente) fazer uso da

Fbrica de Programas e de uma Fbrica de Testes;

os centros de "produo" distribudos, quando houver, tm a camada

de gesto da operao e de gesto do projeto local, assim como projees do QA e
Testes tambm locais;

a Fbrica de Programas usada pela de Projetos pode estar

centralizada atendendo a todos os centros de produo;

todos os centros de produo utilizam as mesmas ferramentas de

gesto, ferramentas de apoio ao desenvolvimento, mtodos e procedimentos;

operaes em incio e de pequeno porte necessitam pelo menos da

camada de gesto e de construo do produto, podendo usar QA e Testes de outro
centro de produo.
A Figura 8.11 representa esse cenrio.

3.4.2 Cenrio da fbrica dedicada

aceita qualquer tipo de projeto em determinadas plataformas e

especializa-se no domnio das respectivas aplicaes;

pode ter centros de desenvolvimento dispersos geograficamente ou

a produo organizada por cliente e por negcio;

no;

dentro de cada rea de negcio, h novos projetos de

desenvolvimento, manutenes de software e projetos fsicos;

as reas de negcio so centros de produo dedicados e tm equipes

separadas para a fase de especificao e para as fases subseqentes do ciclo de vida,
em que as equipes so organizadas por plataforma de desenvolvimento;

pode haver equipes dedicadas aos aplicativos que atendem a novos

projetos de desenvolvimento, projetos fsicos e manutenes;

as equipes de especificao devem ter domnio de vrias tcnicas de

engenharia de software, por exemplo, anlise essencial e orientao para objeto;

pode possuir um Project Management Office (PMO) para o suporte

ao gerenciamento de todos os projetos, fazendo a integrao;

a gesto da configurao preferencialmente por cliente;


a Fbrica de Projetos pode (no necessariamente) fazer uso da
Fbrica de Programas e de uma Fbrica de Testes;

os centros de produo distribudos tm a camada de gesto local,

assim como projees do QA e Testes tambm locais;

todos os centros de produo utilizam as mesmas ferramentas de

gesto, ferramentas de apoio ao desenvolvimento, mtodos e procedimentos.
A Figura 8.12 apresenta o esquema desse cenrio.

3.5

Fluxo operacional principal do modelo

Da mesma forma que a Fbrica de Programas, a Fbrica de Projetos tem vrios

fluxos de produtos e informao.
As Figuras 8.13 e 8.14 apresentam exemplos de fluxos, compreendendo desde a
interao com o cliente at a entrega do produto final.

3.6
O que vital para comear a Fbrica de
Software
A Figura 8.15 apresenta, em nosso entender, o que preciso no primeiro minuto de
jogo para comear a operar uma Fbrica de Projetos, considerando instalaes de
automao de suporte.
O nvel de exigncia da Fbrica de Projetos em termos de componentes bem maior
do que o da Fbrica de Programas.
Dependendo do porte da Fbrica de Projetos, ela deve comear j com alguns dos
componentes automatizados, principalmente:

gesto da demanda;

workflow do processo (recebimento, planejamento, PCP, execuo);

controle de recursos;

controle de custos;

controle do prazo;

controle de requisitos;

modelagem de software;

ferramentas de produtividade, como o software Computer Aided

Software Engineering (CASE);

Gesto da Configurao.

3.7
O que pode ser terceirizado pela Fbrica
de Projetos
Para manter o custo da fbrica em um patamar competitivo, devemos definir o que
pode constituir-se em custo varivel.
Algumas atividades candidatas so:

auditorias de compliance;

auditorias nos sistemas da qualidade;

suporte em engenharia de software;

suporte na elaborao de planejamentos de tecnologia, riscos e estra-

execuo de treinamentos;

servios de suporte em infra-estrutura;

desenvolvimento de projetos especficos;

testes de alguns sistemas especficos;

servios de suporte administrativo.

tgico;

4 MODELO DE OUTSOURCING DE SISTEMAS

O outsourcing de sistemas um processo de absoro, por parte de um terceiro, de
parte ou todos os sistemas aplicativos de uma organizao com a finalidade de desenvolver
novos sistemas e manter os j existentes.
O outsourcing de sistemas geralmente regido por um contrato que estipula a forma
e prazo para a absoro dos sistemas, dos recursos humanos da operao, acordos de nveis
de servios, forma de operao e interfaces da organizao com a operao terceirizada.
O outsourcing , na realidade, uma Fbrica de Projetos dedicada exclusivamente a
um cliente.
O que diferencia o outsourcing de sistemas de uma Fbrica de Projetos, conforme
nosso conceito, que a operao deve ser absorvida por um terceiro de acordo com um
conjunto de critrios e regras previamente estabelecidas.
Absorver implica documentar sistemas existentes, absorver sistemas e o pessoal da
organizao que j mantinha o sistema e deve operar estritamente sob acordos de nveis de
servios.

4.1

Requisitos da operao de outsourcing

4.1.1 Um modelo de outsourcing

Do ponto de vista de uma empresa de prestao de servios, um dos requisitos
bsicos para ela competir ter previamente seu modelo de outsourcing de sistemas, o qual
pode basear-se no modelo genrico de Fbrica de Software apresentado anteriormente ou
em um modelo que seja um subset do modelo maior proposto.
A Figura 8.16 mostra um modelo de outsourcing derivado do modelo de Fbrica
Genrico dentro de nosso framework de operaes de software.

4.1.2 Planejamento da Operao de Outsourcing

Uma operao de outsourcing geralmente planejada em funo dos requisitos do
cliente. Ou seja, grande parte do design da operao determinada pelo cliente. No a
prestadora de servios que determina as regras. Pode apenas influenci-las.

Para a elaborao do planejamento da implantao de uma operao dessa natureza,

os seguintes itens devem ser levantados:

o volume da demanda de servios;

o tipo da demanda de servios (novos projetos, manutenes

evolutivas, adaptativas e legais, de otimizaes, corretivas e emergenciais);

mantidos;

quais os processos de gesto do cliente que devem ser absorvidos e

quais os novos processos de gesto que devem ser implementados;

quais as metodologias de desenvolvimento de sistemas do cliente que

devem ser absorvidas e mantidas;

quais as melhorias nas metodologias do cliente que devem ser

implementadas;

quais as novas metodologias de desenvolvimento que devem ser

implementadas;

quais as normas e os padres aplicveis (segurana, compliance,

testes, produo, etc.);

qual o ambiente tecnolgico do cliente;

o que fica e sai do ambiente;

instalados;

quais os novos equipamentos e dispositivos que devem ser

quantidade de recursos humanos que devero ser absorvidos;

quantidade de recursos humanos que devero ser contratados

adicionalmente para a operao;

absorvidos;

qual o perfil e a qualificao dos recursos humanos que devero ser

contratados;

qual o perfil e a qualificao dos recursos humanos que devero ser

quais os indicadores de desempenho atuais da operao;

quais sistemas devero ser absorvidos;

quais as plataformas tecnolgicas dos sistemas;

qual a situao de cada sistema em termos de demanda (qual a maior

freqncia), idade do sistema, equipe que mantm, nvel de atualizao da
documentao;

qual o processo e ambiente de teste requerido;

quais as instalaes a serem usadas;

quais os investimentos para pr a operao para funcionar;

quais os nveis de servios a serem exigidos pelo cliente.

Uma vez que esses dados so coletados, devemos planejar a operao. Para tal
importante a elaborao de um planejamento, seguindo os moldes preconizados pelo
PMBOK, com o plano do projeto, cronograma, oramento de custo, plano de risco, da
qualidade etc.

4.1.3 Estratgia de Implantao do Outsourcing

A implantao da operao do outsourcing deve ser feita seguindo uma estratgia
bem definida.
A Figura 8.7 apresenta um exemplo de estratgia de implantao.
Uma estratgia de implantao deve prever as seguintes fases:

avaliao do ambiente, que tem por objetivo a coleta de informaes

para o planejamento do projeto de implantao;

planejamento da implantao da operao;

adaptao dos componentes da Fbrica de Software Genrica ou

componentes que a empresa j tenha, visando atender aos requisitos acordados com
o cliente; eventualmente nessa fase os sistemas a serem absorvidos so
documentados;

fase de transio ocorre quando o novo modelo comea a ser

implantado, as equipes de sistemas comeam a ser absorvidas, treinadas, e os sistemas comeam a ser absorvidos;

por fim, chega-se fase de operao contnua, quando h o roll-out

da operao e os nveis de servios podem ser cobrados.
Algumas empresas, para gerar antecipao de receita, j absorvem a mo-de-obra
imediatamente, bem antes da fase de transio.
Alternativa cobrar do cliente o novo modelo de operao que ser entregue
documentado pela empresa prestadora de servios, pois at a operao contnua h
substancial investimento em esforo de pessoas e em instalaes.

4.1.4 Implantao da Operao um Projeto

Devemos sempre ter em mente que a implantao de uma operao dessa natureza
um projeto; portanto, deve ter um gerente, um plano, controles de cronograma, custo,
qualidade e escopo, matrizes de responsabilidades, processos de controle da mudana e de
risco.
Lembramos que, ao se planejar uma operao de outsourcing, imprescindvel fazer
uma anlise do retorno do investimento, para saber quando o fluxo de caixa ficar no azul
(perodo de payback).

4.1.5 Desempenho da Organizao Orientado

pelos Nveis de Servios
Em uma operao de outsourcing, praticamente todo o desempenho orientado

pelos nveis de servio.

Sugere-se que a gesto do desempenho da operao seja feita em conjunto com o
cliente, conforme mostra a Figura 8.18.
Essa estratgia fornece maior credibilidade operao e, portanto, maior
longevidade do contrato.
Geralmente, os principais indicadores de nveis de servios so os referentes
confiabilidade de entrega das ordens de servio (entrega na data prometida) e qualidade
(refere-se quantidade de ordens de servio retornadas por problemas da qualidade).
Outro indicador muito usado o tempo de atendimento a situaes emergenciais;
pode haver valores diferentes de nveis de servio conforme a severidade da emergncia.

4.1.6 A
Distribuda

Operao

de

Outsourcing

Pode

Ser

A operao de outsourcing pode ser distribuda em vrios locais e para clientes

diferentes, conforme mostra a Figura 8.19.

4.2

Organizao da produo

Como vimos na seo anterior, a operao de outsourcing pode atender a vrios

clientes simultaneamente.
Cada operao distribuda deve ter sua prpria gesto; entretanto, os processos de
gesto e controle e operao devem ser os mesmos. Tambm devem ser as mesmas as
ferramentas de apoio gesto e ao desenvolvimento.
A Figura 8.20 mostra a organizao da produo tpica para uma operao
outsourcing.

4.3
Fatores crticos
operao de outsourcing

de

sucesso

para

De acordo com Fernandes, a escolha de uma operao de outsourcing pelas

empresas depende fundamentalmente dos seguintes fatores:

imagem do fornecedor junto ao mercado, considerando integridade e

histrico de sucessos;

processos operacionais e de gesto consistentes que sejam

demonstrveis;

resultados de operaes similares em termos de atendimento aos

acordos de nveis de servio;

flexibilidade de adaptao da operao s necessidades dos clientes.

Entretanto, para o fornecedor importantssimo fazer um acordo de nvel de servio

que possa ser efetivamente atendido.
Temos observado que a maior fonte de conflito entre empresas e fornecedores de
servios em operaes de outsourcing tem sido a questo do no-atendimento a acordos de
nveis de servio ou de interpretaes diversas para esses acordos.

Portanto, quando os acordos so estabelecidos, devem ser medidos de forma

objetiva sem dar margens a interpretaes subjetivas e qualitativas.
Outra fonte de conflito ocorre quanto a preos, pois atualmente os servios de
desenvolvimento de sistemas so considerados commodities.
A remunerao de um outsourcing deve levar em considerao a margem necessria
para novos investimentos na melhoria da operao. Portanto, isso deve ser negociado
detidamente.
Alm do mais, devem ser considerados quando da negociao contratual os
seguintes itens:

que mudanas no volume da demanda obrigar, com base em

critrios objetivos, o aumento no nmero de pessoas na operao;

fazer um contrato de time & material, ou seja, que garanta o

pagamento das horas totais consumidas a partir de um mnimo; por exemplo, pagamento de horas extras;

pagamentos diferenciados para trabalhos emergenciais em feriados,

fins de semana, noite e de madrugada;

o que no far parte dos servios de outsourcing, isso para evitar a

solicitao de recursos humanos mais caros no preo de mais baratos;

qualquer solicitao que extrapolar o que est em contrato como

finalidade do outsourcing dever ser objeto de aditivo contratual;

o outsourcing pode excluir novos desenvolvimentos de sistemas,

ficando somente com as manutenes; nesse caso, pode-se praticar uma poltica
diferente de preos para novos desenvolvimentos;

quando a empresa prestadora de servios for usar instalaes

prprias, deve empregar um fator de housing no preo, visando ressarcir custos
prprios de instalao; esse fator o custo equivalente instalao requerida por
um profissional da operao;

repassar custos de atualizaes de documentao de sistemas, j que

essas documentaes sero de propriedade do cliente.

5 MODELO DA FBRICA DE COMPONENTES

A Fbrica de Componentes totalmente baseada nos conceitos de "linha de
produtos de software" discutidos anteriormente.
uma forte quebra de paradigma e tambm uma busca pela real manufatura do
software em termos de produo "customizada" de massa, que significa produzir softwares
com alta qualidade e produtividade em virtude da intensa reutilizao de componentes.
A fbrica dentro do presente conceito orientada para o desenvolvimento de novos
softwares e evoluo dos que esto em manuteno.
A Figura 8.21 mostra o modelo bsico da Fbrica de Componentes.
A Fbrica de Componentes parte da engenharia da aplicao, quando os requisitos

so estabelecidos e decide-se o que ser reutilizado e desenvolvido de acordo com a

arquitetura do software. A engenharia da aplicao tem domnio completo da rea de
negcio atendida pelo software, assim como controla o mapa de todas as arquiteturas de
software mantidas pela fbrica.
De acordo com Bass et al, a arquitetura de software de um programa ou de um
sistema de computao a estrutura das estruturas do sistema, a qual compreende
componentes de software, as propriedades externas desses componentes e os
relacionamentos entre si.
A gesto de componentes informa a existncia ou no dos componentes requeridos
pela engenharia.
Conforme essa informao e levando em considerao a arquitetura do software,
elaborado um Plano de Produo que indica onde cada componente ser colocado na
arquitetura. Esse plano emite ordens para a construo de novos componentes e
disponibilizao dos componentes j existentes.
A gesto de componentes disponibiliza componentes existentes em sua biblioteca
para a linha de integrao de componentes e autoriza a construo de novos componentes.
Os novos componentes so construdos e testados e disponibilizados para a etapa de
integrao. Todos esses eventos foram previstos pelo Plano de Produo.
Uma vez que todos os componentes so integrados conforme a arquitetura do
software, parte-se para o teste do software (sistemas e de aceitao). Dessa forma, o
produto liberado para o cliente.
A gesto do produto fica com o encargo de fazer evoluir o produto de software,
reiniciando o ciclo do processo de software atravs da engenharia da aplicao.
Os benefcios desse "modelo de fbrica" a velocidade de construo de softwares
inteiros e a qualidade associada, visto que os componentes reutilizados j foram testados e
so praticamente isentos de defeitos.
Outro aspecto desse modelo que podemos construir novos componentes para
"estocagem", prevendo seu uso futuro por um software aplicativo.
A construo de componentes, ou criao de novas verses, pode ser feita em
Fbricas de Programas tradicionais.
Outra vantagem que a Fbrica de Componentes pode fazer uso de componentes
disponveis no mercado que podem ser adicionados na biblioteca e usados para a gerao
do produto de software.
Entretanto, outras habilidades so requeridas dos profissionais que trabalham na
fbrica, que so o conhecimento sobre os domnios das reas de negcio das aplicaes,
como projetar uma arquitetura de software, como especificar um componente, como
gerenciar a biblioteca de componentes, como fazer a integrao dos componentes conforme
a arquitetura, como avaliar sistemas legados. "desenhar" sua arquitetura, e como definir o
que ser um componente reutilizado.
Esse modelo o "Nirvana" do desenvolvimento do software e, embora a teoria j
esteja bastante avanada, ainda h poucos casos no mundo de uso consistente dessa
abordagem. Contudo, achamos que o caminho natural da evoluo dos processos e da

Fbrica de Software.

6 VIRTUALIZANDO A FBRICA DE SOFTWARE

Como veremos a seguir, a Fbrica Virtual ainda um conceito totalmente
exploratrio.
Esse conceito nasceu da necessidade de baratear o custo de uma Fbrica de
Programas, principalmente com foco na plataforma distribuda.
Um movimento de barateamento do custo foi feito por algumas Fbricas de
Programas brasileiras que se mudam para locais onde os custos de pessoal mais baixo do
que nos grandes centros, tais como So Paulo, Rio de Janeiro e Braslia, para citar somente
alguns.
Entretanto, ningum pensou em baratear ainda mais, atravs do uso da mo-de-obra
sob demanda, passando o pagamento dessa fora de trabalho a ser feito por tarefa, e o mais
radical dessa proposio que ela independente de onde os programadores estejam
localizados (eles so virtuais mesmo). Nesse conceito, no pagamos mais a ociosidade da
mo-de-obra, frias, fim de semana remunerado, demais obrigaes trabalhistas e grandes
instalaes.
Imagine agora usar esses profissionais no somente no Brasil, mas tambm pelo
mundo afora, principalmente em pases onde h mo-de-obra de qualidade, mas de baixo
custo.
Uma fbrica, de acordo com essa idia, precisa ter fortssimo apoio da Internet e
resolver algumas questes jurdicas.
A Internet deve ser o canal de recrutamento e comunicao entre a fbrica e os
profissionais.
A questo jurdica como fazer com que profissionais sejam "contratados" e
cumpram com suas obrigaes e sejam pagos (aqui ou em outros pases).
Os processos mais crticos passam a ser o "recrutamento de programadores", a
formalizao jurdica do relacionamento, o PCP da Fbrica, o controle da qualidade dos
programas recebidos, o Plano de Contingncias para atender a falhas na produo e a
segurana da informao.
O processo de recrutamento imaginado teria as seguintes caractersticas:

divulgao, por meios profissionais especializados, da nova forma de

trabalho (deve-se identificar o melhor canal de comunicao);

existncia de um site (em pelo menos trs idiomas portugus,

espanhol e ingls) para a atrao de profissionais e com todo o explicativo de como
participar na fbrica como programador;

nesse site todo o profissional que se candidatar deve fazer um teste

on Tine, de forma que possa ser qualificado em termos de habilidades de
programao e nvel de senioridade;

criar um cadastro dos profissionais com suas respectivas habilidades

e domnios de linguagem;


o processo de emprego dessa fora de trabalho conforme a
distribuio da tarefa, que deve seguir acordos de nveis de servios;

profissionais devem ser maiores de idade ou representados por pre-

postos.
O processo jurdico teria as seguintes caractersticas:

profissionais no Brasil poderiam baixar um arquivo que contm o

contrato de prestao de servios do site da fbrica, assin-lo e envi-lo para a
fbrica; podemos pensar tambm em usar identificao digital para fins de
formalizao de contratos;

profissionais de fora do Brasil fariam o mesmo, mas a partir de

escritrios credenciados (atravs, possivelmente, de convnio com um escritrio
brasileiro); o escritrio local receberia os contratos de prestao de servios e
administraria questes legais pertinentes;

os pagamentos seriam feitos com remessas para contas no Brasil e

para contas no exterior (devem ser celebrados contratos de cmbio especficos);

os contratos devem obedecer s legislaes de cada pas.

O PCP trabalharia numa filosofia de recursos infinitos, ou seja, toda ordem de

servio seria encaminhada para profissionais com a habilidade requerida e disponvel. A
ordem enviada atravs de uma chave ou senha que o programador vai usar para ter acesso
especificao da tarefa no site da fbrica. Esse processo poderia ser totalmente
automatizado e transmitir mensagens por e-mail e para telefones celulares. Caso no haja
acesso ao site pelo programador em um tempo predeterminado, emitido para outro
programador, e assim sucessivamente.
Para a produo, ele usar um ambiente em um Internet Data Center (no Brasil,
claro) com todo o ambiente e ferramentas necessrias para realizar seu trabalho. Fica
entendido aqui que uma fbrica virtual como essa trabalha com recursos tecnolgicos
compatveis com o ambiente do cliente, mas fora da casa do cliente.
Nesse ambiente, encontraramos todos os padres documentados e necessrios para
que o programador execute sua tarefa (em vrios idiomas).
Os programadores seriam incentivados a manter certo padro de qualidade. Seu
desempenho teria que ser controlado freneticamente. Mas, dentro de nosso Plano de
Contingncia, devemos ter um buffer de recursos se ocorrer o recebimento de um programa
com muitos defeitos e no houver tempo para devolver para o programador consertar.
Programadores que no cumprissem, de forma sistemtica, com o atendimento aos
tempos das ordens de servio e a qualidade seriam automaticamente eliminados dos
recursos disponveis para a produo. Fariam parte de uma "lista negra".
Devemos controlar a qualidade dos programas com base em amostras depois que os
programadores demonstraram que mantm certo padro de qualidade.
Os programadores iniciantes so controlados programa a programa por determinado
perodo at que se verifique a manuteno da consistncia do trabalho do profissional.
Por fim, temos que ter uma poltica e instrumentos de segurana contra invases ao

ambiente de relacionamento com os programadores e de produo. A segurana tem que ser

monitorada em tempo real a todo momento.
A estrutura da Fbrica Virtual seria extremamente enxuta, operacionalmente
falando. O que fica nesse modelo o pessoal responsvel pelo recebimento e anlise das
ordens de servio, o PCP (que pode ser quase totalmente automatizado), o pessoal
responsvel pelo recebimento e controle da qualidade, o pessoal de segurana e o buffer de
recursos.
Entretanto, caro leitor, o investimento nesse modelo de fbrica bastante
significativo, e o pioneiro, como sempre, o que corre mais risco.
Esperamos ento pelos candidatos a ser o pioneiro.