Topicos Especiais em Engenharia de Software

TÓPICOS
ESPECIAIS EM
ENGENHARIA DE
SOFTWARE I
Professora Esp. Janaina Aparecida de Freitas
GRADUAÇÃO
Unicesumar
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor Executivo de EAD
William Victor Kendrick de Matos Silva
Pró-Reitor de Ensino de EAD
Janes Fidélis Tomelin
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância

Diretoria Executiva
Chrystiano Mincoff
James Prestes
Tiago Stachon
Diretoria de Design Educacional
Débora Leite
Diretoria de Graduação e Pós-graduação
Kátia Coelho
Diretoria de Permanência
Leonardo Spaine
Head de Produção de Conteúdos
Celso Luiz Braga de Souza Filho
Gerência de Produção de Conteúdo
Diogo Ribeiro de
Coordenador Garcia
Conteúdo
Fabiana de Lima
Gerência de Projetos Especiais
Designer Educacional
Daniel Fuverki Hey
Amanda Peçanha Dos Santos
Janaína de SouzaNúcleo
Supervisão do Pontes de Produção
de Materiais
Iconografia
Nádila Toledo
Isabela Soares Silva
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a
Supervisão
Projeto Operacional de Ensino
Gráfico
Distância; FREITAS, Janaina Aparecida de. Luiz Arthur
Jaime Sanglard
de Marchi Junior
José Jhonny Coelho
Tópicos Especiais Em Engenharia de Software I. Janaina Apa-
recida de Freitas. Arte Capa
Maringá-Pr.: UniCesumar, 2018. André Morais de Freitas
222 p.
“Graduação - EaD”.
Editoração
Fernando Henrique Mendes
1. Tópicos 2. Engenharia . 3. Software 4. EaD. I. Título. Qualidade Textual
CDD - 22 ed. 005.1
Cintia Prezoto Ferreira
CIP - NBR 12899 - AACR/2
Ilustração
Marta Kakitani
Ficha catalográfica elaborada pelo bibliotecário

João Vivaldo de Souza - CRB-8 - 6828
Viver e trabalhar em uma sociedade global é um
grande desafio para todos os cidadãos. A busca
por tecnologia, informação, conhecimento de
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a
educação de qualidade nas diferentes áreas do
conhecimento, formando profissionais cidadãos
que contribuam para o desenvolvimento de uma
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais
e sociais; a realização de uma prática acadêmica
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização
do conhecimento acadêmico com a articulação e
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela
qualidade e compromisso do corpo docente;
aquisição de competências institucionais para
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade
da oferta dos ensinos presencial e a distância;
bem-estar e satisfação da comunidade interna;
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de
cooperação e parceria com o mundo do trabalho,
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está
iniciando um processo de transformação, pois quando
investimos em nossa formação, seja ela pessoal ou
profissional, nos transformamos e, consequentemente,
Pró-Reitor de
Ensino de EAD
transformamos também a sociedade na qual estamos
inseridos. De que forma o fazemos? Criando oportu-
nidades e/ou estabelecendo mudanças capazes de
alcançar um nível de desenvolvimento compatível com
os desafios que surgem no mundo contemporâneo.
O Centro Universitário Cesumar mediante o Núcleo de
Educação a Distância, o(a) acompanhará durante todo
Diretoria de Graduação
e Pós-graduação este processo, pois conforme Freire (1996): “Os homens
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialógica
e encontram-se integrados à proposta pedagógica, con-
tribuindo no processo educacional, complementando
sua formação profissional, desenvolvendo competên-
cias e habilidades, e aplicando conceitos teóricos em
situação de realidade, de maneira a inseri-lo no mercado
de trabalho. Ou seja, estes materiais têm como principal
objetivo “provocar uma aproximação entre você e o
conteúdo”, desta forma possibilita o desenvolvimento
da autonomia em busca dos conhecimentos necessá-
rios para a sua formação pessoal e profissional.
Portanto, nossa distância nesse processo de cresci-
mento e construção do conhecimento deve ser apenas
geográfica. Utilize os diversos recursos pedagógicos
que o Centro Universitário Cesumar lhe possibilita. Ou
seja, acesse regularmente o AVA – Ambiente Virtual de
Aprendizagem, interaja nos fóruns e enquetes, assista
às aulas ao vivo e participe das discussões. Além dis-
so, lembre-se que existe uma equipe de professores
e tutores que se encontra disponível para sanar suas
dúvidas e auxiliá-lo(a) em seu processo de aprendiza-
gem, possibilitando-lhe trilhar com tranquilidade e
segurança sua trajetória acadêmica.
AUTORA

Atualmente, cursando o Mestrado em Ciência da Computação, pela
Universidade Estadual de Maringá (UEM) e Licenciatura em Letras - Português/
Inglês, no Centro Universitário Cesumar (UniCesumar). Especialização
(MBA) em Teste de Software, pela Universidade Ceuma (UNICEUMA/2012).
Graduação em Informática, pela Universidade Estadual de Maringá
(UEM/2010). Trabalhou na iniciativa privada, na área de Análise de Sistemas e
Testes de Software. Tem experiência na área de Engenharia de Software, com
ênfase em Análise de Requisitos, Gestão de Projetos de Software, Métricas e
Estimativas, Qualidade e Teste de Software. É professora mediadora dos cursos
de graduação Análise e Desenvolvimento de Sistemas (ADS) e Sistemas para
Internet (SI), na modalidade de Ensino a Distância (EAD), pelo Unicesumar.
Link: http://lattes.cnpq.br/4906244382612830
APRESENTAÇÃO
TÓPICOS ESPECIAIS EM ENGENHARIA

DE SOFTWARE I
SEJA BEM-VINDO(A)!
Prezado(a) aluno(a), seja bem-vindo(a) à disciplina de Tópicos Especiais em Engenharia
de Software I. Nesta disciplina, iremos abordar o conteúdo sobre as Fábricas de Softwa-
re, desde seus conceitos básicos até a sua implantação.
As unidades do livro foram organizadas de forma que estejam vinculadas, ou seja, que
a unidade seguinte sempre esteja vinculada com a unidade anterior. Portanto, é bom
que você leia e entenda todo o conteúdo de uma unidade para passar para a próxima.
Vamos iniciar vendo, na Unidade I, uma apresentação do panorama geral do Paradigma
da Fábrica de Software, conceituar o termo Fábrica de Software e verificar os tipos de
software que podem ser desenvolvidos em uma Fábrica de Software. Também vamos
analisar e entender os Frameworks Organizacionais da Fábrica de Software e apresentar
as decisões e as estratégias acerca da Estrutura da Fábrica de Software.
Seguindo para a Unidade II, vamos apresentar uma visão geral da Fábrica de Software,
entender mais a fundo como funciona a estrutura organizacional de uma Fábrica Orien-
tada a Processos, de uma Fábrica Orientada a Produtos, de uma Fábrica de Projetos e da
Fábrica de Programas.
Depois, seguindo para a Unidade III, vamos conhecer os principais conceitos e princípios
que envolvem a Linha de Produto de Software (LPS). Também iremos conhecer con-
ceitos e funcionamento de uma Fábrica de Testes, entender como funciona a estrutura
organizacional de uma Fábrica de Componentes e compreender o funcionamento e a
estrutura organizacional de um Modelo de Outsourcing de Sistemas.
Na Unidade IV, passaremos a entender como Virtualizar uma Fábrica de Software e va-
mos aprender como aplicar os modelos de Fábrica de Software In-house. Também va-
mos conhecer a Fábrica de Software e os modelos de melhores práticas e certificações,
além de entender como estruturar Operações de Fábrica de Software Offshore e conhe-
cer os seus requisitos técnicos e comerciais que são utilizados.
E, por fim, na Unidade V, vamos conhecer as estratégias de Implantação da Fábrica de
Software, seu planejamento e gerenciamentos. Vamos aprender também sobre WBS do
Projeto de Fábrica de Software e como aplica-lo.
Espero que sua leitura seja agradável e que esse conteúdo possa contribuir para seu
crescimento pessoal e profissional.
Assim, convido você, caro(a) aluno(a), a entrar nessa jornada com empenho, dedicação
e muita sede por conhecimento! Vamos começar nossos estudos?
Boa leitura!
09
SUMÁRIO
UNIDADE I
VISÃO GERAL DA FÁBRICA DE SOFTWARE
15 Introdução
16 Paradigma da Fábrica de Software
21 O Que É Fábrica De Software?
30 Tipos de Softwares Desenvolvidos na Fábrica de Software
33 Frameworks Organizacionais de Fábrica de Software
37 Decisões Acerca da Estrutura Organizacional da Fábrica de Software
43 Considerações Finais
50 Gabarito
UNIDADE II
MODELOS DE FÁBRICAS DE SOFTWARE
53 Introdução
54 Visão Geral da Fábrica de Software
64 Fábrica de Software Baseada em Processos
71 Fábrica de Software Baseada em Produtos
76 Fábrica de Projetos
84 Fábrica de Programas de Software
97 Gabarito
10
SUMÁRIO
UNIDADE III
OUTROS MODELOS DE FÁBRICA DE SOFTWARE
101 Introdução
102 Linha de produtos de software
115 Fábrica De Testes De Software
123 Fábrica de Componentes
126 Modelo de Outsourcing de Sistemas
144 Gabarito
UNIDADE IV
APLICANDO OS MODELOS DE FÁBRICA DE SOFTWARE
147 Introdução
148 Virtualizando a Fábrica de Software
151 Como Aplicar os Modelos de Fábrica de Software In-House
156 Aplicação da Fábrica de Programas In-House
158 Fábrica de Software e Modelos de Melhores Práticas e Certificações
166 Estruturando Operações de Fábrica de Software Offshore
172 Requisitos Técnicos e Comerciais Para Estruturar uma Operação Offshore
183 Gabarito
11
SUMÁRIO
UNIDADE V
IMPLANTANDO A FÁBRICA DE SOFTWARE
187 Introdução
188 Estratégia da Implantação da Fábrica de Software
194 Planejamento da Implantação da Fábrica de Software
196 WBS do Projeto de Fábrica de Software
210 Gerenciamento da Implantação da Fábrica de Software
220 Referências
221 Gabarito
222 CONCLUSÃO
VISÃO GERAL DA FÁBRICA
I
UNIDADE
DE SOFTWARE
Objetivos de Aprendizagem
■■ Apresentar um panorama geral do Paradigma da Fábrica de Software.
■■ Conceituar o termo Fábrica de Software.
■■ Conhecer e entender os tipos de software que podem ser
desenvolvidos em uma Fábrica de Software.
■■ Analisar e entender os Frameworks Organizacionais da Fábrica de
Software.
■■ Apresentar as decisões e estratégias acerca da Estrutura da Fábrica de
Software.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
■■ Paradigma da Fábrica de Software
■■ O que é Fábrica de software?
■■ Tipos de Softwares desenvolvidos na Fábrica de Software
■■ Frameworks Organizacionais de Fábrica de Software
■■ Decisões acerca da Estrutura Organizacional da Fábrica de Software
15
INTRODUÇÃO
Olá, aluno(a)! Esta unidade tem por finalidade apresentar um panorama geral
que envolve a Fábrica de Software. Além de mostrar conceitos e ideias acerca do
termo Fábrica de Software, serão explicados os referenciais teóricos: o fordismo
e o pós-fordismo, e como eles interagem no paradigma da Fábrica de Software.
Hoje, temos um crescente número de empresas que estão no negócio de
software e têm adotado o termo Fábrica de Software, seja em virtude da alta
demanda de software no mercado ou o grande aumento da complexidade dos
Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
softwares, seja como uma solução para produzir seus produtos ou serviços com
maior qualidade, maior produtividade e baixo custo de produção.
Um dado histórico importante: o termo fábrica de software vem desde os
anos 60, nos Estados Unidos, e desde os anos 70, no Japão, evoluindo e se refi-
nando até os dias atuais. Por isso, é importante conhecer o que é uma Fábrica
de Software e os conceitos que norteiam este movimento com uma abordagem
“fabril”. O objetivo é mostrar a situação atual das operações que envolvem uma
Fábrica de Software, compreendendo e entendendo seu processo e suas ideias.
Vamos analisar e entender os Frameworks Organizacionais da Fábrica
de Software a partir de três visões diferentes. Uma visão voltada ao reúso da
experiência e a uma organização orientada ao projeto; outra visão baseada em
componentes; e uma terceira visão que classifica a fábrica de software de acordo
com o seu escopo de fornecimento e que delineia as fases de desenvolvimento
de um projeto de software.
Vamos apresentar, também, as decisões e estratégias que devem ser tomadas
acerca da estrutura da Fábrica de Software, como, por exemplo: decisões sobre
desenvolvimento de linhas de novos serviços, da rede de operações, tecnologias de
processos, recursos humanos, planejamento e controle de qualidade, entre outros.
Preparado(a) para começar? Então, vamos seguir em frente. Boa leitura e
bons estudos!
Introdução
16 UNIDADE I
PARADIGMA DA FÁBRICA DE SOFTWARE
Quando pensamos em tecnologias, é profundamente interessante falar sobre com-

putação quântica, realidade aumentada, veículos autônomos, robôs em todos os
lugares, inteligência baseada em computadores e serviços de entrega de drones,
entre outros. Desde o início dos tempos, os seres humanos são fascinados por
ferramentas que podem melhorar suas vidas.
Contudo, na verdade, a maior história será nos bastidores: a história de como
as empresas vão se transformar para serem capazes de realizar todo o potencial
de todas essas ideias e dispositivos notáveis. A chave para essa transformação
é, naturalmente, o software. Na verdade, o software é cada vez mais a resposta a
todas as perguntas no “guia para a galáxia” ao se pensar em tecnologias.
Uma coisa é certa, as empresas que estão no negócio de software devem ter
todos os olhos na construção e modernização de seus produtos e ferramentas
para estarem conectados ao mundo digitalmente. Uma previsão que já está se
tornando realidade é que as empresas que conseguem mapear suas fábricas de
software, identificar lacunas-chaves e fechá-las, e aprender a automatizar com
êxito para deslocar recursos para a inovação vão liderar o mercado na entrega
de experiências superiores aos seus clientes.

17
Um crescente número de empresas que estão no negócio de software tem

adotado o termo Fábrica de Software, em virtude da alta demanda de software ou
do aumento da complexidade, ou como uma solução para produzir seus produ-
tos ou serviços com qualidade, maior produtividade e baixo custo de produção.
A expressão fábrica de software vem desde os anos 60, nos Estados Unidos, e
desde os anos 70, no Japão, evoluindo e se refinando até os dias atuais. Conforme
Nomura, a distinção feita pelos japoneses para fábrica de software já levava em
conta algumas características que:
[...] ainda são despercebidas por várias empresas que associam o termo
“Fábrica” ao mero desenvolvimento de software, sem a preocupação

com as padronizações que vão além do algoritmo exigido pela lingua-
gem de programação ou com os aspectos associados à produção em
massa e em larga escala, tais como: simplificação, integridade concei-
tual, aderência aos padrões, automação seletiva no processo de desen-
volvimento, padronizações de tarefas e controles, divisão do trabalho,
mecanização e automatização (NOMURA, 2008, p. 28).
Contudo, para falar sobre o paradigma da fábrica de software é preciso conhe-

cer o referencial teórico: o fordismo, o pós-fordismo e como eles interagem no
paradigma da fábrica de software.
FORDISMO E PÓS-FORDISMO
Caracteriza-se o fordismo como sendo um método de organização da produ-

ção e do trabalho complementar ao taylorismo e, conforme Tenório e Valle
(2012), emprega-se mão de obra especializada para a produção de serviços ou
de produtos padronizados e com aplicação de técnicas repetitivas. O pós-for-
dismo caracteriza-se pela diferenciação integrada da organização da produção
de serviços ou produtos e da trajetória de inovações tecnológicas. Estes con-
ceitos – fordismo e pós-fordismo – se interagem à fábrica de software, quando
consideramos um ambiente organizacional no qual os conceitos e suas técnicas
ocorrem na gestão da produção.
O ponto principal, segundo Fernandes e Teixeira (2011), é que há uma asso-
ciação de valor quando pensamos em desenvolvimento de softwares que utilizam
Paradigma da Fábrica de Software

18 UNIDADE I
alguns conceitos de engenharia associados à manufatura. Ainda conforme os

autores, o ambiente de software visualiza o processo de engenharia como uma
linha de montagem, baseada em ciclos de vida do desenvolvimento que se rela-
cionam com os processos de garantia de qualidade do produto.
Porém, conforme Tenório e Valle (2012), o modelo de fábrica clássica de
produção em massa (fordismo e pós-fordismo), na qual as pessoas realizam as
atividades repetitivas como extensões de máquinas, não é o modelo correto e
nem aceito para a fabricação de softwares. Então, porque o uso da expressão
fábrica de software? Principalmente, considerando que o produto de software é
de natureza abstrata e cada software desenvolvido é um produto único.
Há muitas controvérsias e diferentes visões com relação à expressão “fábrica
de software”. Conforme Tenório e Valle (2012), no processo de software, a ana-
logia a essa expressão pode ser aplicada aos objetivos da produção baseada no
estilo industrial e não na sua implementação.
A mudança da forma artesanal para a científica trouxe ao desenvolvimento
de software princípios que agregam valor aos produtos, como a automação e a
padronização, que proporcionaram aumento considerável na produtividade.
(ALMEIDA, 2009, p. 44).
Na visão de Borsoi (2008), existem diferenças entre o desenvolvimento de
software em relação à manufatura industrial, como:
[...] o desenvolvimento de software possui diferenças fundamentais em
relação à produção da manufatura industrial, como, a não produção
em série e o vínculo da realização das atividades de desenvolvimento à
criatividade e ao conhecimento prático e teórico das pessoas. Porém, é
possível encontrar similaridades entre ambos, como: uso de processos
e de modelos de qualidade, reuso de artefatos, linha de produtos e o ob-
jetivo de desenvolver produtos com qualidade, cumprir o cronograma
e corresponder ao orçamento (BORSOI, 2008, p. 23).
O desafio da Engenharia de Software é construir softwares que atendam às neces-

sidades dos usuários, com qualidade, dentro do prazo e custo estimado. No
entanto, com o crescimento da demanda, a complexidade do software aumenta
e esta dificuldade aumenta quando se pretende aumentar a escala de produção.
Para Tenório e Valle (2012), a busca da produtividade faz com o formalismo e o
controle do processo seja mais rigoroso e especializado. Ainda, temos as técnicas

19
estruturadas e a componentização, que equivalem a uma “fordização” da fabri-

cação de software e, neste caso, a diferença agora é que o produto é intangível.
Apesar de todo o sistema ser considerado único, os softwares são compostos por
componentes que são desenvolvidos separadamente ou, ainda, comprados de ter-
ceiros e depois podem ser montados para obter o resultado final.
Conforme Nomura (2008, p. 27), o paradigma da Fábrica de Software busca
a obtenção de qualidade e produtividade no desenvolvimento e manutenção de
software por meio de padronização de processos, reúso de artefatos e controle do
sistema de produção. Para a autora, um framework de fábrica de software pode ser
usado em diferentes óticas com foco em: segmentação das atividades, desenvolvi-
mento baseado em componentes, linha de produção de software e terceirização.
O mercado de desenvolvimento de software cresceu e vai continuar cres-
cendo, pois o software vem sendo incorporado em quase todos os produtos e
serviços que usamos. Com o crescimento desse mercado, tornou-se necessário
que a gestão do processo de desenvolvimento de software viabilize a produção
em larga escala para atender esta demanda de mercado, mas com qualidade e
com um menor custo.
A partir daí, surgiu a iniciativa de organizar a produção de software de acordo
com o modelo fabril taylorista-fordista. Para Tenório e Valle, esta iniciativa é
uma realidade em nossos dias, principalmente pela TQM que:
[...] com a crescente disseminação das práticas de Gestão da Qualidade
(Total Quality Management) nos Estados Unidos nos anos 1980, co-
meçou um forte movimento por parte do governo norte-americano,
mais notadamente do Departamento de Defesa, para introduzir esses
conceitos na gestão da produção de software. Dos trabalhos de Watts
Humphrey junto com o Software Engineering Institute nasceu o modelo
CMM (Capability Maturity Model) que é uma das principais referências
em gestão de processo de software. Tais modelos, ao decompor proces-
sos e colocá-los em sequência, remetem ao modelo fordista. Porém,
diferentemente do modelo fordista, no qual a qualidade do produto era
de responsabilidade do supervisor/gerente, o CMM se baseia no prin-
cípio de que cada empregado é diretamente responsável pelo produto.
Ou seja, a gestão da qualidade do período denominado pós-fordista faz
parte desse novo processo (TENÓRIO; VALLE, 2012, p. 50 e 51).
Paradigma da Fábrica de Software

20 UNIDADE I
Para entendermos as abordagens sobre o conceito de fábrica de software e a sua evolu-

ção com o passar dos anos, o quadro a seguir apresenta o processo evolutivo da fábrica
de software, mostrando que ela ocorre em estágios (FERNANDES; TEIXEIRA, 2011).
Quadro 1 - Evolução da Fábrica de Software
FASES CARACTERÍSTICAS
FASE 1 Organização básica e Gerência da estrutura (meados de 60 e início de 70):
• Objetivos da manufatura de software são estabelecidos.
• Foco no produto é determinado.
• Começa a coleta de dados sobre o processo.
FASE 2 Customização da Tecnologia e Padronização (início de 70):
• Objetivos dos sistemas de controle são estabelecidos.
• Métodos padrões são estabelecidos para desenvolvimento.
• Desenvolvimento em ambiente on-line.
• Treinamento de empregados para padronizar as habilidades.
• Bibliotecas de código-fonte são introduzidas.
• Começam a ser introduzidas metodologias e ferramentas de desenvolvimento.
FASE 3 Mecanização e Suporte ao processo ( final dos anos 70):
• Introdução de ferramentas para apoio ao controle de projetos.
• Introdução de ferramentas para geração de código, teste e documentação.
• Integração de ferramentas com banco de dados e plataformas de desenvolvimento.
FASE 4 Refinamento do Processo e Extensão:
• Revisão dos padrões.
• Introdução de novos métodos e ferramentas.
• Estabelecimento de controle de qualidade e círculos da qualidade.
• Transferência de métodos e ferramenta para subsidiárias e terceiros.
FASE 5 Automação Flexível:
• Aumento da capacidade das ferramentas existentes.
• Introdução de ferramentas de apoio à reutilização.
• Introdução de ferramentas de automação de design.
• Introdução de ferramentas de apoio à análise de requisitos.
• Integração de ferramentas em plataformas de desenvolvimento.
Fonte: Fernandes e Teixeira (2011, p. 30).
Para Tenório e Valle (2012), há uma analogia entre a introdução de processos de

desenvolvimento de software pelo paradigma da fábrica de software e a introdu-
ção da fábrica de manufatura segundo o paradigma taylorista-fordista: ambos
os paradigmas transformam o processo de produção de um esquema artesa-
nal para um esquema baseado em linha de produção, que se apoia em tarefas
repetitivas e padronizadas. Ford criou o conceito de intercambialidade entre as
partes do automóvel; e o conceito de reutilização de componentes de software
tenta aumentar a produtividade e melhorar a qualidade para mais de um projeto.

21
Então, podemos pensar que todo o esforço de implementar uma operação

fabril para o desenvolvimento de software possui suas raízes na engenharia indus-
trial e em muitos conceitos provenientes da gestão da qualidade total, desde a
década de 80.
No entanto, quando falamos em serviços de software, para muitos profissio-
nais da tecnologia da informação isso ainda não está claro. Serviços de software,
em larga escala, como o desenvolvimento simultâneo de vários novos projetos
ou várias solicitações de atendimento de serviços de manutenção, requerem que
seja adotado práticas de produção e gestão de serviços, ou seja, uma fábrica de
serviços.
O QUE É FÁBRICA DE SOFTWARE?
O termo Fábrica de software vem sendo discutido desde o final dos anos 60 e
vem evoluindo até os dias atuais, tendo surgido como uma solução para aumen-
tar a produtividade e diminuir prazos e custos de produção.
O Que É Fábrica de Software?

22 UNIDADE I
O conceito de Fábrica de software, conforme Fernandes e Teixeira (2011, p.

117), é definido como:
[...] um processo estruturado, controlado e melhorado de forma con-
tínua, considerando abordagens de engenharia industrial, orientado
para o atendimento a múltiplas demandas de natureza e escopo distin-
tas, visando à geração de produtos de software, conforme os requeri-
mentos documentados dos usuários e/ou clientes, da forma mais pro-
dutiva e econômica possível (FERNANDES; TEIXEIRA, 2011, p. 117).
Uma das primeiras empresas a adotar o termo fábrica de software foi a japonesa
Hitachi, no ano de 1969, com seus Hitachi Software Works. Depois, em meados dos
anos 70, outras empresas, como a System Development Corporation, NEC, Toshiba e
Fujitsu também começaram a adotar este termo e utilizar seus conceitos e práticas.
Para Nomura (2008, p. 27), “o sucesso das fábricas de software do Japão e nos EUA
deve-se à inclusão de um alto grau de reuso, modularização, uso de ferramentas,
controle e gerenciamento dos sistemas, aumentando a qualidade e a flexibilidade”.
Para Oliveira (2007), essa descoberta como um novo modelo de trabalho
para o desenvolvimento de software fez com que surgissem várias adaptações
do modelo, com diferentes abordagens, foco em ferramentas e em processos.
Podemos citar três modelos em destaque:
Modelo Japonês: foco na alta produtividade e qualidade do software. Objetivo
principal da empresa é tornar a rotina de trabalho simples e repetitiva, e padroni-
zar os processos de trabalho. As experiências das empresas japonesas resultaram
em nove elementos básicos comuns ao desenvolvimento de software. São eles:
1. Comprometimento com a melhoria de processos;
2. Segmentação e foco em produto-processo;
3. Análise e controle da qualidade e do processo;
4. Processo centralizado de pesquisa e desenvolvimento;
5. Nivelamento e padronização do conhecimento;
6. Padronização dinâmica;
7. Reusabilidade sistemática;
8. Integração de ferramentas CASE ao ambiente de fábrica;
9. Melhoria dos processos de maneira incremental.

23
Modelo Europeu: foco na integração de ambientes de desenvolvimento de sof-

tware. Objetivo na criação de uma arquitetura e um framework para um ambiente
de desenvolvimento de software integrado, por meio de um modelo genérico de
fábrica de software, com ferramentas, componentes e ambientes de várias áreas
de negócios. Assim, é possível instanciar um ambiente de fábrica a partir deste
modelo genérico e adaptá-lo a qualquer projeto na empresa. O modelo gené-
rico embutiu o processo de software nas ferramentas de suporte ao ambiente de
fábrica, automatizando a padronização do trabalho. São elementos importantes
deste modelo para o desenvolvimento de software: foco em produto e em pro-
cesso, pesquisa e desenvolvimento centralizados de processo, reusabilidade e

integração de ferramentas automatizadas ao ambiente de fábrica.
Modelo Norte-Americano: foco nas abordagens baseadas na experiência e
na maturidade da empresa. Fundamentado em experiências em que é possível
errar, desde que sejam extraídas lições e melhorias para os próximos projetos. É
conhecido como Fábrica de Experiências; é apoiado pelo paradigma de melho-
ria da qualidade, que podemos resumi-lo nos seguintes passos:
■■ Plan: os projetos são planejados, objetivos estabelecidos utilizando as
experiências anteriores;
■■ Execute: projetos são executados e controlados por meio de medições;
■■ Analyze: as experiências dos projetos são avaliadas e comparadas;
■■ Synthesize: resultados armazenados para serem utilizados em próxi-
mos projetos.
A implementação da melhoria por meio da experiência é intensa, exige que a

fábrica tenha um controle mais preciso e acentuado sobre as suas atividades por
meio da utilização de métricas. Para Oliveira (2007), surge o modelo de uma
organização madura em que:

24 UNIDADE I
[...] associando o conceito de maturidade pregado neste modelo à re-

alidade de uma fábrica de software, isto pode ser entendido como a
possibilidade de a fábrica ter maior controle sobre sua capacidade de
produção. E isso significa realizar planejamentos pouco mutáveis, com
estimativas mais precisas de custo, esforço e tamanho para os projetos,
executar o desenvolvimento de forma monitorada e controlada, sem
desvios significativos do planejamento, ser capaz de corrigir os des-
vios do processo sem comprometer os custos de desenvolvimento, e
por fim, gerar um produto de alta qualidade (OLIVEIRA, 2007, p. 24).
Já segundo Romanha (2016), o termo fábrica de software surgiu para trazer,

ao ambiente de desenvolvimento de aplicativos, conceitos e metodologias do
processo de produção fabril tradicional, baseados em componentes com carac-
terísticas semelhantes e com a mesma qualidade.
O autor ainda coloca que, de maneira semelhante ao processo de fabricação
de produtos em linhas de montagem, temos os atuais padrões de desenvolvi-
mento de software, como, por exemplo, a programação orientada a objetos, em
que os softwares são compostos por módulos ou componentes que são unidos
para a montagem do final do produto, possibilitando que partes individuais pos-
sam ser desenvolvidas independentemente das demais.
Para Fernandes e Teixeira (2011), o objetivo da fábrica de software é gerar
produtos que foram requeridos pelos usuários ou clientes, com um mínimo de
defeitos e a um custo competitivo e compatível.
Para Osias (2008), temos quatro pilares de uma fábrica de software, como
mostra a figura a seguir.
Linhas de produtos de software
Orientação contextual Estruturas da arquitetura
Desenvolvimento orientado a
modelo
Figura 1 - Os quatro pilares de uma fábrica de software

Fonte: Osias (2008, p. 37).

25
Uma Linha de Produto de Software (Software Product Line) é um grupo de sof-

twares ou, ainda, uma família de sistemas que compartilham um conjunto de
características/especificações em comum, ou seja, são sistemas similares ao invés
de um único sistema individual (CÂMARA, 2011). Sua principal característica é
o fato de serem desenvolvidos a partir de um conjunto de artefatos, reutilizando
componentes, especificações de requisitos, casos de teste e outros, que podem ser
utilizados para o desenvolvimento de novas aplicações que possuem um mesmo
domínio (FERREIRA, 2012).
A Estrutura da Arquitetura é descrita como um esquema de processos da
fábrica de software. Ela é usada para orientar o fluxo de trabalho e as tarefas do

projeto até que todas as atividades estejam concluídas.
O Desenvolvimento Orientado a Modelo (MDD) é a uma técnica para usar
metadados que são capturados em modelos e que são usados para automati-
zar as atividades do desenvolvimento de software. A Orientação Contextual é
utilizada para descrever tudo o que é para fazer e usada como ajuda durante o
processo de desenvolvimento.
Segundo Osias (2008, p. 37), “ao combinar os pilares, eles transformam-se
em um todo maior do que a soma de suas partes e nos impulsionam na direção
da industrialização do software”.
ATRIBUTOS BÁSICOS DE UMA FÁBRICA DE SOFTWARE
O que deve ter uma empresa para ela ser considerada uma fábrica de software?
Para ser considerada uma fábrica de software, devemos considerar alguns atribu-
tos oriundos de uma fábrica industrial. Conforme Fernandes e Teixeira (2011),
uma fábrica de software deve possuir os seguintes atributos básicos, indepen-
dentemente de seu escopo:
■■ Deve ter um processo definido e padrão para o desenvolvimento do pro-
duto de software;
■■ Deve ter um gerenciamento de interface forte com o usuário e/ou cliente
(recebimento e entrega);

26 UNIDADE I
■■ Deve padronizar a entrada para a fábrica (serviços);

■■ Deve determinar estimativas de prazo e custo conforme a demanda e
capacidade real;
■■ Deve haver métodos e padrões de estimativas;
■■ Deve haver tempos e padrões de atendimento de acordo com o domí-
nio da aplicação ou tecnologia e do tamanho da demanda (programa e/
ou projeto);
■■ Devem ser controlados, conforme o tipo de demanda, os perfis de recur-
sos humanos;
■■ Deve haver controle de recursos (alocação, disponibilidade, necessida-
des e produtividade);
■■ Deve haver um processo de planejamento e controle da produção;
■■ Deve haver um controle do status das múltiplas demandas;
■■ Deve controlar todos os itens de software (documentos, padrões, proce-
dimentos, ferramentas, códigos, testes) em uma biblioteca;
■■ Deve haver controle absoluto do andamento da execução de cada demanda;
■■ Deve ser construído os produtos de software de acordo com métodos,

técnicas e ferramentas padronizadas;
■■ Deve haver processos distintos para as demandas de naturezas diferentes;
■■ Deve haver treinamento a todos da equipe nos processos organizacio-
nais e produtivos;
■■ Deve haver processos de atendimentos para a resolução de problemas de
usuários e/ou clientes;
■■ Deve haver mecanismos que garantam a qualidade do produto de software;
■■ Deve haver mecanismos de controle de custos;

■■ Deve haver mecanismos de medição e estimativas;
■■ Deve haver controle absoluto sobre os níveis de serviços acordados com
seus usuários e/ou clientes;

27
■■ Deve haver melhoria contínua em seus processos, visando o aumento da

produtividade e a redução de custos;
■■ Deve haver um ambiente de hardware e software estável.
NECESSIDADE
GERENCIAMENTO TECNOLOGIA
FÁBRICA
DE
SOFTWARE
MÉTRICAS E PESSOAS +
ESTIMATIVAS PROCESSOS
RESULTADO +
QUALIDADE
Figura 2 – Os atributos básicos de uma fábrica de software
Fonte: a autora.
Alguns fatores podem interferir no resultado das fábricas de software, como:

gestão de pessoas, gestão empresarial, processos de desenvolvimento de sof-
tware, padrões de qualidade, métricas e estimativas, ferramentas e frameworks.
E para o sucesso de uma fábrica de software? O sucesso depende de vários
fatores, entre eles:
■■ Da utilização de processos de desenvolvimento que ajudem na definição
e na distribuição das tarefas a serem desenvolvidas nas etapas do ciclo
de vida do software;
■■ Uma boa comunicação tanto com o cliente quanto com a equipe;
■■ Na previsão da demanda;
■■ Em fazer uso de mecanismos de controle e melhoria contínua dos pro-
cessos de gestão do conhecimento e de recursos humanos;
■■ Na utilização de bibliotecas para reutilização de código e componentes.

28 UNIDADE I
Segundo Romanha (2016), outro fator que pode determinar o sucesso de uma
fábrica de software é a produtividade, pois ela pode ser influenciada por três
grupos de fatores:
■■ Fatores tecnológicos: linguagens de programação, ferramentas de projeto,
ambientes de desenvolvimento e capacidade dos equipamentos adotados.
■■ Fatores humanos: perfil, formação, motivação, comprometimento e capa-
citação das pessoas.
■■ Fatores organizacionais: processos de trabalho, metodologias, práticas
gerenciais, ambiente físico, conforto e bem-estar dos recursos humanos.
Para o desenvolvimento de tarefas que são pertinentes a uma fábrica de software,

a adoção de ferramentas de apoio é considerada importante e algumas são obri-
gatórias, pois elas ajudam a garantir o aumento na produtividade, redução de
custos e suporte a uma comunicação mais efetiva junto ao cliente e usuário. A
seguir, uma lista com algumas ferramentas de apoio que podem ser utilizadas:
■■ Ferramentas para Desenvolvimento (codificação) e Modelagem;
■■ Ferramentas para Relatar Erros;
■■ Ferramentas para Gerenciamento de Projetos;
■■ Ferramentas para Comunicação;
■■ Ferramentas para Controle de Versão;
■■ Sistema Gerenciador de Banco de Dados (SGDB).
Além das ferramentas de apoio, algumas fábricas de software podem adotar

algumas certificações e boas práticas que ajudam na organização dos processos
e a legitimar a qualidade dos produtos e serviços que são oferecidos, como, por
exemplo: MPS.Br e o CMM/CMMI (ROMANHA, 2016).
Nos resultados das fábricas de software, segundo Tenório e Valle (2012), inter-
ferem diretamente alguns fatores, como: gestão de pessoas, gestão empresarial,
processos de desenvolvimento de software, padrões de qualidade, ferramentas
e frameworks de soluções fabris. Para Nomura (2008), o fundamento para esta-
belecer uma fábrica de software está baseado:

29
[...] na obtenção de benefícios das linhas de produção, na qualidade

de produtos, como na produtividade alcançada. Estas linhas de pro-
dução baseiam-se na definição de um processo e um fluxo que devem
acompanhar cada operação do processo, além de prover as ferramentas
necessárias para se obter a ação necessária. Assim, quanto mais seg-
mentado for o processo, mais simples será cada operação, obtendo com
isto uma divisão do trabalho orientada à especialização (NOMURA,
2008, p. 30).
Modelo SW- CMM

O SW-CMM (Capability Maturity Model) é uma aplicação de conceitos de ges-
tão de processos e de melhoria da qualidade para o desenvolvimento e a
manutenção de software. O modelo descreve como uma organização de
software amadurece à medida que aperfeiçoa seu processo de software. O
SW-CMM pode ser considerado um guia para a melhoria contínua do pro-
cesso de software de uma organização, partindo de um processo imaturo
para um processo maduro e gerenciado efetivamente. O modelo baseia-se
em níveis evolutivos de maturidade do processo de software. O modelo
CMMI (Capability Maturity Model Integration) é uma evolução do conceito
de modelos de capabilidade estabelecido pelo CMM. O CMMI foi projetado
para a melhoria dos processos de desenvolvimento de produtos e serviços,
assim como a aquisição e manutenção. O CMMI tem duas representações,
uma baseada em estágios, similar ao SW-CMMI e outra contínua.
Fonte: Fernandes e Teixeira (2011).

30 UNIDADE I
TIPOS DE SOFTWARES DESENVOLVIDOS NA
FÁBRICA DE SOFTWARE
Falamos em estratégias que devem ser definidas e analisadas para as fábricas de

software. Porém, o mercado de software é considerado complexo e pode abran-
ger serviços e produtos. Assim, temos que analisar e definir que tipo de software
(serviço ou produto) vai ser desenvolvido na fábrica de software.
Podemos classificar o software nas categorias: produtos, serviços e embarca-
dos. Os produtos de software podem ser divididos em: infraestrutura (sistemas
operacionais, servidores, middleware, gerenciador de rede etc.), ferramentas
(linguagens de programação, de gerenciamento, modelagem de dados, BI, data
warehouse etc.) e aplicativos (ERP CRM, SCM etc.).
Outra forma de classificar os produtos de software é em função do mercado:
horizontal (quando se aplica a qualquer tipo de usuário) ou vertical (quando
se aplica a um usuário ou atividade específica). Outra maneira de dividir é em
função da forma como é comercializado, que podem ser: pacotes (produtos
padronizados), customizados (permitem adaptações para cada usuário) e sof-
tware sob encomenda.

31
A classificação para serviços é em função do método de compra. Outsourcing

é definido como o processo em que uma organização contrata outra para desem-
penhar determinada função. O Outsourcing envolve contratos mais longos e.
muitas vezes, com metas de desempenho. As Outsourcing podem ser divididas
em: convencional e BPO (Business Process Outsourcing). O convencional envolve
a terceirização de uma atividade específica da área de TI, e o BPO pode ser defi-
nido como um contrato com uma organização externa, para que seja fornecido
um processo ou função de negócio.
BPO é uma espécie de “terceirização” de todos os processos internos não
ligados diretamente aos negócios da empresa. Isto é, podemos entender que BPO
é como uma entrega de diversos procedimentos da empresa a uma especialista
em processos internos, ligados a outros departamentos variados. Ou para ficar
mais claro, é a contratação de uma empresa que vai prover serviços para a exe-
cução de tarefas específicas dentro da sua empresa.
Segundo Brito et al. (2004), temos, ainda, as Fábricas de Software Livre. Para
entendermos este termo, precisamos conhecer outros conceitos, começando por
software livre.
Software livre é um termo usado, conforme Brito et al. (2004), “para indi-
car que o software é desenvolvido e distribuído sob algum tipo de licença que
garanta ao seu usuário liberdades relacionadas ao uso, alteração e redistribuição”.
Um aspecto fundamental do software livre é que seu código-fonte deve estar dis-
ponível livremente para ser lido, estudado ou alterado por qualquer pessoa que
esteja interessada nele. Outro conceito que devemos conhecer é sobre o projeto
de software livre, que é uma organização composta por um conjunto de pessoas
que usa, desenvolve e estuda um único software livre.
Nos tópicos anteriores, falamos sobre fábrica de software, que é uma orga-
nização que provê serviços de desenvolvimento de sistemas com qualidade,
utilizando um processo de desenvolvimento de software bem definido e com
apoio de tecnologias de mercado. E uma fábrica de software livre? Segundo
Brito et al. (2004), “uma fábrica de software livre desenvolve projetos de software
livre, em sua totalidade ou em parte, e possui um modelo de negócios diferente
do modelo tradicional, onde o código fonte do produto não é disponibilizado”.
Tipos de Softwares Desenvolvidos na Fábrica de Software

32 UNIDADE I
O que devemos ter em mente: que todos os tipos de fábrica de software,

independente da sua classificação (serviços ou produtos), ou estratégia adotada,
possuem processos definidos que devem atender às necessidades de desenvol-
vimento de software.
Um fábrica de software deve ser flexível para desenvolver produtos que sejam
diversificados, implementando em todos os projetos, os conceitos da Engenharia
de Software, como: metodologias, ferramentas, ambientes para a construção de
fábrica de software, e sendo capaz de projetar, implementar, evoluir e melho-
rar os sistemas.
Trindade (2006) comenta que uma fábrica de software deve ter um ambiente
que seja adequado ao desenvolvimento de programas, em que se faz necessário
ter um processo de manufatura, testes, ferramentas automatizadas, ferramentas
de medição de produtividade e qualidade, ferramentas para gerenciar custos e
estimativas gerenciais que ajudem na gestão de projetos ativos e futuros.
O conceito de fordismo poderia ser aplicado de várias formas e profundida-

des, mas [...] o nosso interesse maior será descrever o fordismo mais como
um paradigma de organização da produção e do trabalho do que como
uma referência macroeconômica.
Especificamente, nos interessa no uso da expressão fordismo o nível menos
global do fordismo, que estaria remetido a um princípio de organização da
produção, compreendendo um paradigma tecnológico, forma de organiza-
ção do trabalho e estilo de gestão. O fordismo surgiu primeiro como uma
tecnologia de gestão da produção, transformando-se [...] em um modelo
técnico-econômico. Contudo, como modelo gerencial, o fordismo tem as
suas bases assentadas sobre o taylorismo; sem o taylorismo não haveria
o fordismo, métodos elaborados respectivamente por Frederick Winslow
Taylor (1856-1915) e Henry Ford (1863-1947). Historicamente, em outros
momentos, outros autores, anteriores a Taylor e Ford, contribuíram para o
desenvolvimento do pensamento gerencial.
Fonte: Carvalho Filho (2008).

33
FRAMEWORKS ORGANIZACIONAIS DE FÁBRICA DE

SOFTWARE
No desenvolvimento de software, temos muitos artefatos e relacionamentos que

incorporam um grande volume de experiências e atividades de desenvolvimen-
tos anteriores. E de acordo com Nomura (2008), é este reuso de experiências
anteriores que necessita ser incorporado ao processo de produção de software.
Para isso, temos um framework organizacional orientado ao reuso, e que é
dividido em duas estruturas: uma organizacional, orientada ao projeto, e outra
denominada Fábrica de Experiência, conforme a figura a seguir:
Frameworks Organizacionais de Fábrica de Software

34 UNIDADE I
Fábrica Baseado em Fábrica de Experiência - Fábrica de

Organização Orientada Domínio - Fábrica de Componentes
ao Projeto
Produtos
Planejamento Dados Análise
Ações
do Domínio
Construção
Base
Experiência
Reusáveis
Análise Síntese
Experiência de Domínio
Reuso
Figura 3 – Fábrica de Experiência

Fonte: adaptada de Nomura (2008, p. 18).
Segundo Nomura (2008), a Fábrica de Experiência é uma abordagem para moni-

torar e analisar os projetos desenvolvidos e, partir disso, desenvolver e catalogar
as práticas de reuso de componentes de software de diferentes tipos de experiên-
cias que a empresa possui como conhecimento, por exemplo: processos adotados,
ferramentas automatizadas e produtos.
Na Figura 3, a arquitetura da Fábrica de Experiência é representada em dois
níveis: Fábrica de Domínio e a Fábrica de Componentes. A Fábrica de Domínios
é onde ocorre o gerenciamento do conhecimento do domínio de reuso. A Fábrica
de Componentes é responsável por produzir e manipular os artefatos a serem
fornecidos para a Fábrica, baseada em Organização de Projetos.
A engenharia de software baseada em componentes (CBSE) é, conforme
Pressman e Maxim (2016), considerado um processo que enfatiza o projeto e
a construção de sistemas usando “componentes” de software reutilizáveis. Na
Figura 4, é mostrado um modelo de desenvolvimento de software apresentado
por Pressman e Maxim (2016), que infere no escopo de Fábrica de Componentes
de Software, em que os processos da Fábrica de Domínio correm em paralelo,
reusando os modelos de domínio, os modelos estruturais e os repositórios de
artefatos/componentes.

35
Desenvolvimento Desenvolvimento
Análise do
de arquitetura de componentes
Domínio
de Software reusáveis
Engenharia
de Modelo de Modelo Repositório
Domínio Domínio Estrutural de artefatos/
componentes
Qualificação
Atualização de
Projeto Adaptação Componentes
Análise
Arquitetural Composição de
Componentes
Software de
Desenvolvimento Aplicação
Baseado em
Engenharia de
Componentes
componentes Teste
Figura 4 – Engenharia de Software Baseada em Componentes

Fonte: Pressman e Maxim e Teiceira (2016, p. 52).
Segundo Fernandes (2011), uma fábrica de software tem um framework com

tipos de fábricas que pode ser classificado conforme os possíveis escopos de
fornecimento (Figura 5), que delineia as principais fases de desenvolvimento
de um projeto de software.
Fábrica de
Projetos Fábrica de Projetos
de Software Fábrica de Projetos Físicos
Fábrica de
Programa
Arquitetura Projeto Especificação Projeto Construção Teste Teste de

de Solução Conceitual Lógica Detalhado e Teste Integrado Aceitação
Unitário
Figura 5 - Escopo de Fábrica de Software

Fonte: adaptada Fernandes e Teixeira (2011, p. 118).
Frameworks Organizacionais de Fábrica de Software

36 UNIDADE I
A Fábrica de Programas é a menor unidade de fábrica e seus objetivos principais

são a construção e o Teste Unitário de programas de computador. Na Fábrica
de Projetos Físicos, temos um processo de produção mais amplo, com o Projeto
Detalhado, que engloba as atividades da fábrica de programas e as fases de Testes
de Integração e Teste de Aceitação.
A Fábrica de Projetos de Software inicia o processo produtivo a partir do
Projeto Conceitual do Software e de sua Especificação Lógica. Nesta fase, é essen-
cial que a fábrica de software tenha domínio do conhecimento do negócio do
cliente. Na Fábrica de Projetos, temos a Arquitetura de Solução que segue até
a entrega do software pronto e testado para entrar em produção. Nesta fase, é
necessário ter um conhecimento sólido sobre soluções mais abrangentes na área
de TI, configurações de hardware e software, redes de comunicação, platafor-
mas de desenvolvimento e de produção, soluções de gerenciamento de bases de
dados, entre outros recursos.
Podemos observar que uma fábrica de software, não importando o seu tipo,
quando atende a um único cliente é dita de especializada e, com isso, atende ao
modelo que chamamos de outsourcing de sistemas. Segundo Tenório e Valle
(2012, p. 61), “outsourcing nada mais é do que delegar serviços a terceiros. Em
tecnologia da informação, pode incluir qualquer coisa, até mesmo terceirizar
todo o gerenciamento de TI para uma empresa”.
Para o desenvolvimento de uma fábrica de software considerada adequada
é necessário que se tenha conhecimento profundo dos tipos de modelos exis-
tentes no mercado e quais podem ser adaptados de acordo com a necessidade
da fábrica. Esses tipos de modelos que surgem de fábricas de software são adap-
tações feitas para atender às necessidades do mercado. Um modelo de fábrica
de software pode surgir tanto da exigência de mercado para a produção de um
software quanto da necessidade do cliente para um software específico para a
sua regra de negócio.

37
A finalidade de uma empresa é atingir os objetivos para os quais foi criada,

sejam eles os lucros ou a oferta de bens públicos.
(Fernando Guilherme Tenório e Rogério Valle)
DECISÕES ACERCA DA ESTRUTURA

ORGANIZACIONAL DA FÁBRICA DE SOFTWARE
Para Fernandes e Teixeira (2011), um fra-

mework para o projeto da fábrica de software
baseia-se nas áreas de decisões estratégias
de operações. As decisões a serem tomadas
acerca da estrutura de uma fábrica de sof-
tware devem ser estratégicas e relativas à:
Estratégia de desenvolvimento de
linhas de novos serviços: nesta etapa, a deci-
são é sobre o escopo da fábrica de software:
vai ser uma Fábrica de Projetos Ampliada,
Fábrica de Projetos de Desenvolvimento,
Fábrica de Projetos Físicos ou uma Fábrica de Programas. Após a escolha do
escopo, devemos decidir quais as plataformas tecnológicas da fábrica de sof-
tware e os ambientes (linguagens de programação, banco de dados, pacotes etc.).
A escolha do tipo de plataforma e de ambiente vai influenciar as decisões
sobre a tecnologia do processo, da rede de operações e sobre os recursos huma-
nos. Para Fernandes e Teixeira (2011), a escolha da plataforma e do ambiente
deve considerar alguns fatores importantes, como:
Decisões Acerca da Estrutura Organizacional da Fábrica de Software

38 UNIDADE I
■■ O mercado para a plataforma e o ambiente;

■■ A capacidade da empresa em absorver uma nova tecnologia;
■■ O capital de investimento disponível;
■■ O nível de demanda da fábrica;
■■ Os requisitos dos clientes em relação ao serviço da fábrica;
■■ Os objetivos de desempenho requerido para a fábrica.
Estratégia de Rede de Operações: nesta parte, a decisão envolve o que vai ser
feito pelo cliente, por fornecedores ou terceiros, e pela empresa, dentro do escopo
da fábrica escolhido. Isto é, qual parte da operação a fábrica de software deve pos-
suir? Aqui entra a localização da fábrica de software em função do suprimento e
custos de mão de obra. Compreendem máquinas, equipamentos, softwares, dis-
positivos de redes, entre outros.
Alguns itens que devem ser seguidos com relação à localização da fábrica
de software:
■■ Custos das instalações;
■■ Incidência de impostos;
■■ Imagem do local;
■■ Habilidades da mão de obra nas localidades;
■■ Facilidade de acesso;
■■ Infraestrutura e telecomunicações;
■■ Capacidade de atendimento de uma fábrica de software, pois em longo
prazo, pode fazer a diferença financeiramente.
Estratégia das Instalações e Arranjo Físico: nesta etapa, devemos decidir como
serão as instalações da fábrica de software. A decisão do tipo e tamanho das insta-
lações, segundo Fernandes e Teixeira (2011), vai depender do escopo, da demanda
e da estratégia da empresa. Quanto maior o escopo de atuação, mais importante
são as instalações dela. Itens que devemos considerar ao selecionar a instalação:

39
■■ Aluguel, construir ou comprar a instalação;

■■ Tamanho para atender à demanda da fábrica;
■■ Futuras expansões;
■■ Aspectos ergonômicos da instalação;
■■ Acessibilidade.
Estratégia da Tecnologia do Processo: nesta etapa, a escolha da tecnologia de

processo da fábrica é influenciada pelo escopo e pelas plataformas. A tecnolo-
gia do processo também vai depender da tecnologia ou dos métodos e padrões

adotados para o desenvolvimento do software.
Itens que devemos considerar:
■■ Metodologias de análise de sistemas e de requisitos (análise estruturada,
essencial, modelagem de dados, orientação a objetos, UML);
■■ Padrões de codificação;
■■ Segurança;
■■ Metodologias de testes de software.
Aqui entra o fluxo operacional que diz respeito ao workflow de produtos e infor-
mações no ambiente da fábrica de software, que geralmente é automatizado. Por
meio deste workflow, os produtos circulam no ambiente (solicitações de serviços,
especificações, documentos, códigos, módulos etc.) e com isso as informações
gerenciais e gestão da fábrica circulam também.
Alguns itens a se considerar quando se define o fluxo:
■■ Tipos de interfaces, de comunicação com o cliente e usuário;
■■ Ferramentas e sistemas de controles;
■■ Interação entre os processos de gestão e de operação;
■■ Estrutura organizacional da fábrica de software.
Nesta etapa, também devemos decidir qual o modelo de gestão do processo de sof-
tware a ser adotado, como, por exemplo: gestão da demanda, gestão de recursos,

40 UNIDADE I
gestão de planejamento e controle de produção, gestão da qualidade, gestão da

infraestrutura, gestão de custos, gestão de requisitos, gestão de configuração,
gestão de projetos e serviços, gestão de problemas, gestão de riscos e contin-
gências, gestão da melhoria, gestão de testes e gestão de manutenção e suporte.
E quanto ao nível de automação da fábrica de software? Vai depender dos
processos de gestão selecionados e do nível de investimento. Itens que podemos
decidir automatizar:
■■ Workflow do fluxo operacional;
■■ Ferramentas de gestão de requisitos;
■■ Planejamento;
■■ Métricas;
■■ Gestão da configuração;
■■ Controle de qualidade;
■■ Testes;
■■ Componentes;
■■ Custo de projetos;
■■ Serviços de operação.
Estratégia de Recursos Humanos: nesta etapa, devemos decidir a divisão do

trabalho na fábrica, o grau de autonomia dos gerentes, quais tarefas serão atri-
buídas e a quais áreas de conhecimento. A divisão do trabalho vai depender da
plataforma tecnológica, do escopo da tecnologia do processo e da complexi-
dade da demanda. É importante definir níveis de qualificação desejados para os
recursos humanos (trainee, júnior, pleno e sênior). Deve ser considerado estra-
tégias políticas de desenvolvimento e retenção de talentos bem documentadas.
Estratégia de Planejamento e Controle da Qualidade: nesta etapa, deve-
mos decidir sobre as políticas de qualidade a serem adotadas, quais os pontos de
inspeção da qualidade nas operações e nos produtos da fábrica, quais as técni-
cas e os métodos de planejamento e controle de qualidade. A qualidade em uma
operação de fábrica de software significa que teremos menos retrabalho e com

41
maior produtividade, então devemos decidir também quais as métricas ou pro-

cessos de coleta de medição e geradores de qualidade serão adotados.
Alguns itens a considerar:
■■ Confiabilidade das entregas;
■■ Qualidade dos produtos e serviços;
■■ Atendimentos aos prazos e padrões;
■■ Agilidade na implantação de novas linhas de serviços;
■■ Flexibilidade no atendimento;
■■ Política de melhoria contínua;
■■ Engajamento de pessoas;
■■ Certificações profissionais de qualidade.
Estratégia de Administração da Qualidade e Melhoramento da Produção:
nesta etapa, devemos decidir sobre quais os indicadores de desempenho que
devemos adotar para a gestão da operação da fábrica de software e de sua melho-
ria contínua. Devemos decidir, também, sobre os níveis de serviços que devem
ser adotados e as metas de desempenho. Indicadores a considerar:
■■ Aprendizagem dos colaboradores;
■■ Confiabilidade de entrega de operação;
■■ Qualidade dos produtos;
■■ Atendimento a prazos padrões;
■■ Velocidade de implantação de novas linhas de serviços;
■■ Flexibilidade no atendimento.
Nesta parte, devemos pensar em qual política para a melhoria da operação e

quais os modelos de maturidade ou de qualidade a serem adotados pela fábrica
de software. Itens que devemos considerar:
■■ Política da melhoria contínua;

42 UNIDADE I
■■ Tratamento de projetos internos na melhoria contínua;

■■ Engajamento da equipe;
■■ Modelo de qualidade adotado;
■■ Certificações profissionais;
■■ Estratégias de implementação;
■■ Evolução e manutenção do modelo de qualidade.
Estratégia de Recuperação de Falhas: nesta etapa, devemos decidir qual a polí-
tica de prevenção e tratamento de itens não conformes da fábrica de software;
qual o plano de contingência ou de risco que será adotado para estabelecer polí-
ticas de prevenção; ações de mitigação de riscos; procedimentos de tratamentos
quando as não conformidades ou falhas ocorrerem. Itens a considerar:
■■ Política de prevenção;
■■ Plano de contingência ou de riscos;
■■ Ações de resposta aos riscos;
■■ Responsabilidades quanto aos riscos;
■■ Procedimentos de tratamento de falhas e não conformidades;
■■ Plano de segurança física e lógica;
■■ Políticas e procedimentos de manutenção de equipamentos e redes de
comunicação (manutenções preventivas, corretivas e preditivas);
■■ Procedimentos de recuperação de falhas;
■■ Procedimentos de backup de arquivos e banco de dados.
Para o desenvolvimento de uma fábrica de software considerada adequada é

necessário que se tenha conhecimento profundo das estratégias e decisões que
devem ser tomadas e quais podem ser adaptadas, de acordo com a necessidade
da fábrica.

43
CONSIDERAÇÕES FINAIS
Olá, aluno(a)! Chegamos ao final da nossa primeira Unidade do livro. Nesta

unidade, foi apresentado um panorama geral que envolve a Fábrica de Software,
seus conceitos, suas ideias e um referencial teórico sobre o fordismo e o pós-for-
dismo, além do porquê eles são importantes e como eles interagem no paradigma
da fábrica de software.
Falamos sobre o crescente número de empresas que estão entrando no negócio
de software e quem vem adotando o termo Fábrica de Software, seja em virtude
da alta demanda de software no mercado ou da complexidade dos softwares, ou

como solução para produzir seus produtos ou serviços com maior qualidade e
se destacar da concorrência.
O objetivo desta unidade foi mostrar a situação atual das operações que
envolvem uma Fábrica de Software, compreendendo e entendendo o processo e
as ideias para uma Fábrica de Software. Falamos em tipos de software (serviço
ou produto) que uma Fábrica de software pode desenvolver e que, independen-
temente de sua escolha, devemos pensar em ter processos bem definidos e que
atendam às necessidades de desenvolvimento de software.
Foi falado sobre os Frameworks Organizacionais da Fábrica de Software e
suas três visões diferentes, uma voltadA ao reuso da experiência e a uma orga-
nização orientada ao projeto; uma visão baseada em componentes; e outra visão
que classifica a fábrica de software de acordo com o seu escopo de fornecimento.
E, por fim, apresentamos as decisões e estratégias que devem ser analisadas,
tomadas e pensadas acerca da estrutura que uma Fábrica de Software deve ter,
como um ambiente planejado, processos bem definidos, mão de obra qualifi-
cada, ferramentas automatizadas, tecnologias e gestão de controle e planejamento,
entre outros itens que devem ser considerados.
Preparado(a) para continuar? Então, vamos seguir em frente. Boa leitura e
bons estudos!
Considerações Finais
44
1. Na visão de Borsoi (2008), existem várias diferenças entre o desenvolvimento de

software em relação à manufatura industrial, como a não produção em série e
o vínculo da realização das atividades de desenvolvimento à criatividade e ao
conhecimento prático e teórico das pessoas. Com base nessa informação, as-
sinale as alternativas que mostram as similaridades entre ambos:
I. O uso de processos e de modelos de qualidade e o reuso de artefatos.
II. O reuso de artefatos e linhas de produção.
III. Linha de produtos.
IV. Objetivo de desenvolver produtos com qualidade, cumprir o cronograma e
corresponder ao orçamento.
a) Somente as afirmativas I, II e III estão corretas.
b) Somente as afirmativas I, II e IV estão corretas.
c) Somente as afirmativas I, III e IV estão corretas.
d) Somente a afirmativa I está correta.
e) Todas as afirmativas estão corretas.
2. Um dos desafios da Engenharia de Software é construir softwares que atendam
às necessidades dos usuários, com qualidade, dentro do prazo e custo estimado.
Porém, com o crescimento da demanda, a complexidade do software aumenta,
e esta dificuldade aumenta quando se pretende aumentar a escala de produção.
A partir desta informação, explique: o que o Paradigma de Fábrica de Sof-
tware busca?
3. Conforme Fernandes e Teixeira (2011), para entendermos as abordagens sobre
o conceito de fábrica de software e a sua evolução com o passar dos anos, preci-
samos conhecer os estágios do processo evolutivo da fábrica de software. Com
base nessa informação, enumere as colunas:
1) Fase 1 ( ) Automação flexível e aumento da capacidade das ferramentas.

2) Fase 2 ( ) Refinamento do processo e extensão e revisão dos padrões.
3) Fase 3 ( ) Customização da tecnologia e padronização e métodos padrões
são estabelecidos.
4) Fase 4 ( ) Mecanização e suporte ao processo e introdução de ferramentas.
5) Fase 5 ( ) Organização básica e foco no produto é determinado.
45
a) 1, 2, 3, 4, 5.
b) 1, 3, 2, 4, 5.
c) 4, 2, 3, 1, 5.
d) 5, 4, 2, 3, 1.
e) 2, 1, 3, 4, 5.
4. Conforme Fernandes e Teixeira (2011), Fábrica de Software é um processo estru-
turado, controlado e melhorado de forma contínua, considerando abordagens
de engenharia industrial, orientado para o atendimento a múltiplas demandas
de natureza e escopo distintos, visando a geração de produtos de software,
conforme os requerimentos documentados dos usuários e/ou clientes, da for-
ma mais produtiva e econômica possível. Com base nessas informações, cite
e comente sobre os três modelos de trabalho para o desenvolvimento de
software.
5. Segundo Romanha (2016), outro fator que pode determinar o sucesso de uma
fábrica de software é a produtividade, pois ela pode ser influenciada por três
grupos de fatores. Complete as lacunas com o nome dos fatores:
linguagens de programação, ferramentas de
projeto, ambientes de desenvolvimento e capacidade dos equipamentos ado-
tados.
processos de trabalho, metodologias, práti-
cas gerenciais, ambiente físico, conforto e bem-estar dos recursos humanos.
perfil, formação, motivação, comprometimento
e capacitação das pessoas.
a) Fatores tecnológicos, Fatores organizacionais, Fatores humanos.
b) Fatores humanos, Fatores organizacionais, Fatores tecnológicos.
c) Fatores tecnológicos, Fatores humanos, Fatores organizacionais.
d) Fatores organizacionais, Fatores humano, Fatores tecnológicos.
e) Fatores humano, Fatores tecnológico, Fatores organizacionais.
46
Recursos Humanos em Fábricas de Software

Na produção industrial, os equipamentos interferem diretamente nas medidas de pro-
dutividade, o que requer estratégias que os faça produzir com o mínimo possível de
interrupções. Por outro lado, em uma “linha de produção” de softwares, o elemento
fundamental é o ser humano. Os recursos humanos em uma fábrica de software, assim
como em qualquer outra área, precisam ser planejados e bem treinados para as tarefas
que irão desenvolver sendo alinhados ao tipo de demanda, levando em consideração a
natureza e complexidade do trabalho a ser realizado (PMBOK, 2004).
A partir da década de 90, o profissional de sistemas passou por uma mudança de perfil,
deixando de ser um especialista e passando a atuar como um generalista, de maneira
que hoje em dia, muitas empresas chegam a não utilizar uma definição de cargo deta-
lhada, podendo o profissional assumir diferentes funções, em diferentes projetos, até
mesmo simultaneamente. Dessa maneira, o cargo acaba funcionando como mera refe-
rência para a remuneração. Para entender melhor esse contexto, é preciso deixar claro o
significado de alguns termos [...]:
Habilidades Técnicas – Conhecimento prático e teórico adquirido ao longo da formação
acadêmica, e em cursos complementares. Inclui metodologias, técnicas, ferramentas
metodológicas, linguagens de programação, etc.
Habilidades de Negócio – São adquiridas ao longo do exercício profissional, por meio do
desenvolvimento de soluções efetivas para empresas. Podem ser funções empresariais,
de administração, processos, procedimentos, idiomas, etc.
Habilidades Comportamentais ou Humanas – Ligadas à educação, à cultura, à filosofia
de vida e aos relacionamentos humanos e corporativos. É possível listar como exemplo
destas habilidades, a pró-atividade; a criatividade; a comunicação; a capacidade de ex-
pressão e o relacionamento pessoal; o espírito de equipe; a administração participativa;
o planejamento pessoal; a capacidade de organização, concentração, atenção, disponi-
bilidade e responsabilidade.
Ainda [...], além de habilidades técnicas e comportamentais, é desejável que os funcio-
nários em uma fábrica de software, assim como nas demais modalidades de empresas
que prestam serviços de software, possuam também conhecimentos em outras áreas de
negócio, visto que para resolver problemas é preciso primeiramente entendê-los.
Dentre os principais papéis existentes em uma equipe funcional requerida para uma
fábrica de software e suas respectivas atividades, é possível destacar [...]:
Gerente de Negócios: responsável pela prospecção do mercado e pela venda dos ser-
viços.
Analista de Sistemas: a este, cabe realizar o levantamento de requisitos, a análise, defi-
nição da arquitetura e a elaboração da documentação do sistema a ser desenvolvido.
47
Analista de Qualidade: responsável pela revisão dos artefatos gerados, pelo controle de
mudanças, a definição e a validação da qualidade do processo utilizado.
Engenheiro de Software: garante que o sistema seja implementado de acordo com as
especificações em sua documentação e seguindo o processo de desenvolvimento de-
finido.
Analista de Testes: realiza o desenvolvimento, a validação e a execução de testes de sof-
tware que visam assegurar a qualidade e integridade do software produzido.
Líder de Equipe: faz a coordenação e a atribuição de tarefas entre os membros da equi-
pe, fornecendo relatórios periódicos ao gerente de projetos sobre o andamento das ati-
vidades.
Em cada equipe de uma Fábrica de Software é recomendado que exista também a figu-
ra do Gerente do Projeto, que é um profissional dedicado exclusivamente a este papel,
o que o habilita a atuar fortemente na interface com o cliente do projeto em questão.
Segundo o PMBOK (2004), os processos de iniciação, planejamento, execução, monito-
ramento, controle e encerramento, devem ser integrados e aplicados pelo gerente de
projeto. Também fazem parte das atribuições desse profissional identificar as necessida-
des; estabelecer objetivos; balancear demandas de qualidade, escopo, tempo e custo,
além de adaptar especificações e planos às necessidades das diversas partes interessa-
das. O gerente ainda deverá atuar de maneira a garantir que o produto final atenda aos
requisitos de qualidade previamente estabelecidos, seguindo métodos e padrões de es-
timativas baseados em históricos; utilizar métricas específicas para estimar tempos pa-
drões de atendimento levando em consideração a tecnologia, o tamanho e o domínio
da demanda; possuir e fazer uso de mecanismos de apuração, apropriação e controle de
custos e manter o controle sobre os níveis de serviço.
No que diz respeito ao mercado de trabalho, de acordo com os dados divulgados pela
Brasscom – Associação Brasileira de Empresas de Tecnologia da Informação e Comuni-
cação, o setor de Tecnologia da Informação (TI) possui alta demanda por profissionais
por um conjunto de fatores:
cresce historicamente a taxas superiores ao Produto Interno Bruto (PIB) nacional.
a TI está inserida em todos os setores da economia moderna, ajudando a aumentar a
competitividade e a produtividade das empresas.
a sociedade utiliza tecnologia cada vez mais intensamente no cotidiano.
novas tecnologias – como computação em nuvem, redes sociais, dispositivos móveis e
segurança da informação – demandam profissionais com novas habilidades.
Fonte: Romanha (2016, p. 26-27).
MATERIAL COMPLEMENTAR
Fábrica de Software
Fernando Guilherme Tenório e Rogerio Valle
Editora: FGV
Sinopse: a produção de software começa artesanal, sem
regras, nos anos 1960, e hoje é um trabalho ordenado num
esquema produtivo. Os autores fazem um paralelo entre
a produção industrial tradicional, a complexa organização
produtiva que vemos hoje, e o que se deu, nas fábricas de
software, com o processo de sua produção. Há paralelos
entre um e outro desenvolvimento, e a sua extensão é
descrita em minúcias. Texto necessário e pioneiro, porque
pouco se tem escrito, no Brasil, sobre os sistemas de
organização das indústrias de software.
O que é e como funciona uma fábrica de software

Artigo sobre como e quando surgiu a expressão Fábrica de Software, o que contribui para o seu
crescimento e como alguns fatores contribuíram para o crescimento deste serviço, que surgiu
para atender novas necessidades do mercado de TI. Para saber mais, acesse o link a seguir.
Disponível em: <https://www.profissionaisti.com.br/2011/10/o-que-e-e-como-funciona-uma-
fabrica-de-software/>. Acesso em: 17 ago. 2017.
Fábrica de Software: o que é e como ela pode ajudar sua empresa
Artigo que trata sobre a Fábrica de Software e como cada vez mais a tecnologia disponível no
mercado tem uma demanda de novas soluções em crescimento constante, como Internet das
Coisas. Para atender a essas novas necessidades é que o conceito de fábrica de software se mostra
cada vez mais presente em ambientes de desenvolvimento. Fique por dentro acessando o link a
seguir.
Disponível em: <http://blog.cedrotech.com/fabrica-de-software-o-que-e-e-como-ela-pode-
ajudar-sua-empresa/>. Acesso em: 17 ago. 2017.
49
REFERÊNCIAS
ALMEIDA, Risoleide de Freitas. A Contribuição da Fábrica de Software e de seus

Produtos para o Processo de Flexibilização Organizacional na Empresa Cliente.
Rio de Janeiro: FGV, 2009.
BRITO, Regiane; FERREIRA, Patrícia; SILVA, Kleber; BURÉGIO, Vanilson; LEITE, Ivan.
Uma experiência na implantação de processo em uma fábrica de software li-
vre. VI Simpósio Internacional de Melhoria de Processos de Software – 2004.
BORSOI, Beatriz Terezinha. Arquitetura de Processo Aplicada na Integração de
Fábricas de Software. São Paulo: USP, 2008.
CÂMARA, Heitor Mariano de Aquino. Uma Abordagem Sistemática para Imple-
mentação, Gerenciamento e Customização de Testes de Linhas de Produto de
Software. Programa de Pós-Graduação em Sistemas e Computação do Departa-
mento de Informática e Matemática Aplicada da Universidade Federal do Rio Gran-
de do Norte. Rio Grande do Norte, 2011.
CARVALHO FILHO, Herriot Clovis de. Fábrica de Software: Um Estudo de Caso sob
a Ótica da Flexibilização Organizacional e das Relações de Trabalho. XIII, 196 p. 29,7
cm (COPPE/UFRJ), M.Sc., Engenharia de Produção, Rio de Janeiro, 2008.
FERNANDES, Aguinaldo Aragon; TEIXEIRA, Descartes de Souza. Fábrica de Softwa-
re: implantação e gestão de operações. São Paulo: Atlas, 2011.
FERREIRA, Johnny Maikeo. Teste de Linha de Produto de Software Baseado em Mu-
tação do Diagrama de Características. Dissertação (Programa de Pós-Graduação em
Informática) - Setor de Ciências Exatas, Universidade Federal do Paraná, Curitiba, 2012.
NOMURA, Luzia. Definição e Estabelecimento de Processos de Fábrica de Sof-
tware em uma organização de TI do Setor Público. Tese (Doutorado Engenharia
de Produção) - Escola Politécnica da Universidade de São Paulo, São Paulo, 2008.
OLIVEIRA, Karine Coelho de Amorim. Um processo de Gerência de Configuração
baseado no nível 2 do CMMI estagiado para Fábricas de Software Orientadas a
Produto. Dissertação (Mestrado Pós- graduação em Ciência da Computação) - Uni-
versidade Federal de Pernambuco, Recife, 2007.
OSIAS, Claudio de Souza. Fábrica de Software: um estudo de caso na Dataprev, sob
a ótica da estrutura organizacional. Rio de Janeiro: FGV, 2008.
TENÓRIO, Fernando Guilherme; VALLE, Rogerio. Fábrica de Software. Rio de Janei-
ro: Editora FGV, 2012.
TRINDADE, André Luiz Presende. Uma Contribuição para o Entendimento do Pa-
pel da Ensinagem na preservação do conhecimento em Ambientes de Fábrica
de Software. PoliUSP: São Paulo, 2006.
PRESSMAN, Roger; MAXIM, Bruce R. Engenharia de Software: uma abordagem
profissional. 8. ed. Porto Alegre: AMGH, 2016.
ROMANHA, Silas Dias. Um Modelo de Fábrica de Software em Instituições de En-
sino Superior. Dissertação (Mestrado em Engenharia de Produção) – Faculdade de
Engenharia de Guaratinguetá, Guaratinguetá, 2016.
GABARITO
1. Alternativa C.
2. O paradigma de Fábrica de Software busca a obtenção de qualidade e produtivi-
dade no desenvolvimento e manutenção de software por meio de padronização de
processos, reuso de artefatos e controle do sistema de produção.
3. Alternativa D.
4. Podemos citar três modelos em destaque:
Modelo Japonês: foco na alta produtividade e qualidade do software.
Objetivo principal da empresa é tornar a rotina de trabalho simples e
repetitiva, e padronizar os processos de trabalho.
Modelo Europeu: foco na integração de am-
bientes de desenvolvimento de software.
Objetivo na criação de uma arquitetura e um framework para um
ambiente de desenvolvimento de software integrado, por meio de um modelo
genérico de fábrica de software, com ferramentas, componentes e ambientes de
várias áreas de negócios.
Modelo Norte-Americano: foco nas abordagens baseadas na experiência e na
maturidade da empresa. Baseada em experiências onde é possível errar, desde
que sejam extraídas lições e melhorias para os próximos projetos.
5. Alternativa A.
MODELOS DE FÁBRICAS DE
II
UNIDADE
SOFTWARE
■■ Apresentar uma visão geral da Fábrica de software.
■■ Entender como funciona a estrutura organizacional de uma Fábrica
Orientada a Processos.
■■ Entender como funciona a estrutura organizacional de uma Fábrica
Orientada a Produtos.
■■ Compreender o funcionamento e a estrutura organizacional de uma
Fábrica de Projetos.
■■ Conhecer a visão geral do modelo e a estrutura organizacional de
uma Fábrica de Programas.
Plano de Estudo
■■ Visão Geral da Fábrica de software
■■ Fábrica de software baseada em Processos
■■ Fábrica de software baseada em Produtos
■■ Fábrica de Projetos
■■ Fábrica de Programas de Software
53
INTRODUÇÃO
Na unidade anterior, falamos sobre o framework para o projeto da fábrica de

software, vimos as importantes decisões e estratégias acerca das estruturas orga-
nizacionais relativas ao desenvolvimento de linhas de novos serviços à rede de
operações, instalações, arranjos físicos, tecnologia de processos, aos recursos
humanos de planejamento e controle de qualidade. Também falamos sobre os
tipos de software que podem ser desenvolvidos na fábrica de software.
Nesta unidade, vamos estudar como a estrutura organizacional de uma
fábrica de software pode se dividir em modelos de fábricas que variam conforme

a sua complexidade e a profundidade dos componentes que variam conforme o
seu escopo. Vamos estudar os seguintes modelos de Fábrica de software: Fábrica
Orientada a Processos, Fábrica Orientada a Produtos, Fábrica de Projetos e
Fábrica de Programas.
Na Fábrica Orientada a Processos, vamos ver que para o perfeito funcio-
namento das atividades da fábrica de software é importante a adoção de um
processo de desenvolvimento em que as tarefas e os artefatos gerados estejam
bem definidos.
Na Fábrica Orientada a Produtos, o desenvolvimento funciona em torno dos
produtos de software desenvolvidos, e devemos conciliar a rotina de manuten-
ção de seus produtos, seja ela evolutiva ou corretiva, com as demandas geradas
por diferentes projetos, que resultam no surgimento ou na evolução das funcio-
nalidades do produto que está sendo produzido.
Em uma Fábrica de Projetos, a rotina funciona por meio da execução de
diversos projetos paralelos, que podem ser independentes ou reusar componen-
tes entre si, todos com começo, meio e fim planejados.
E, por fim, na Fábrica de Programas é onde codificamos e testamos os pro-
gramas, seguindo o acordo de níveis de serviços com o cliente, considerando os
requisitos, as especificações de padrões de programas, critérios de qualidade e
tempo de entrega acordados no contrato.
bons estudos!
Introdução
54 UNIDADE II
A Fábrica de software pode ser definida como um conjunto de atividades e recur-

sos materiais ou humanos, com metodologias e processos bem estruturados e
definidos. Faz uso das melhores práticas para o desenvolvimento, as verifica-
ções e as validações, e para a manutenção do software, métricas e indicadores
de qualidade e produtividade para cada etapa do ciclo de vida de desenvolvi-
mento do software.
Na Unidade I, falamos sobre a associação com a manufatura industrial e em
massa e, também, da possibilidade de usar práticas da manufatura, como ter pro-
cessos definidos de maneira a flexibilizar os projetos, usar modelos de qualidade
em processos e reuso no desenvolvimento de software. E apesar dessa associação,
Borsoi (2008, p. 27) ressalta que a “essência do software deve ser o foco técnico
e o gerenciamento, com ênfase em qualidade e reuso e, como base, uma padro-
nização por processos”.
Na fábrica de software, quanto maior for o volume de produção, menor será

55
o custo do produto. Porém, como reduzir esse custo? Uma forma seria utilizar a
programação Orientada a Objeto ou por Componente, que permite criar obje-
tos reutilizáveis e que possam ser usados em diferentes programas, reduzindo
os custos de desenvolvimento.
Algumas fábricas de software possuem necessidades diferentes, mas podem
ter muitos processos adotados similares. Nestes casos, é importante ter vários
componentes disponíveis em estoque ou contar com funções que ajudem a agi-
lizar o tempo de desenvolvimento do software e, assim, reduzir seus custos. E,
para isso, também é importante maximizar os recursos, ter uma visão clara dos
objetivos a serem desenvolvidos, contar com uma equipe disponível e organi-

zada para evitar o desenvolvimento de objetos já criados e avaliados.
No foco técnico, temos ferramentas automatizadas para a interação entre
as pessoas envolvidas no projeto. No foco de gerenciamento, temos modelos de
projetos, de processos, de reuso, artefatos e gestão da qualidade e controle de
processos e produtos.
Assim, definir uma fábrica de software a partir de processos, conforme Borsoi
(2008), pode ajudar na adaptação a mudanças tecnológicas e de mercador e
também na cultura de processos. Conceituando a fábrica de software como um
ambiente de desenvolvimento constituído por processos e que envolve o ciclo de
vida, iniciamos pela etapa de planejamento, depois temos o design/projeto do
software, seguindo para o desenvolvimento/implementação dos códigos. Depois
temos os testes, implantação do sistema e encerrando com o suporte ao cliente/
usuário. Nessas etapas, temos várias atividades que são realizadas durante o pro-
cesso de desenvolvimento, como: gestão da qualidade do processo e do produto,
a estrutura organizacional, que inclui pessoas, recursos como ferramentas, tec-
nologias e procedimentos, e os produtos de software resultantes dos processos
e projetos. Esses elementos são necessários e ajudam a definir e a organizar os
processos que compõem a fábrica de software.
Um ambiente de desenvolvimento de software é composto por um conjunto
de atividades necessárias para desenvolver os projetos de software e essa estru-
tura faz parte de uma organização de negócios. Para Borsoi (2008), ambiente de
desenvolvimento de software abrange todo o ciclo de desenvolvimento de sof-
tware, em que estão inclusas linguagens de programação e modelagem, banco
Visão Geral da Fábrica de Software

56 UNIDADE II
de dados, ferramentas para o gerenciamento de componentes e de artefatos de

software.
A partir dos ambientes de desenvolvimento de software surgiram as deri-
vações para as fábricas de software baseadas em produtos, projetos e processos,
orientadas a domínio, orientadas à organização, à experiência, entre outras.
Conforme Borsoi (2008), um ambiente de desenvolvimento de software permite:
[...] um ADS centrado em processos permite definir e executar proce-
dimentos realizados por grupos de desenvolvedores trabalhando em
um projeto. Para tanto, inclui mecanismos para controlar a sequência
definida das atividades, gerenciar os artefatos, executar as ferramentas
para realizar as atividades, facilitar a comunicação entre os atores, cole-
tar dados automaticamente e prover o controle do projeto. Um ADS é
visto como um meio, uma estrutura, composto por processos integra-
dos que abrangem o ciclo de vida de software, incluindo os atores, os
artefatos produzidos e os recursos utilizados. Ferramentas computa-
cionais e procedimentos são recursos utilizados pelos atores, seja para
a realização de atividades, para controle e gerenciamento dos processos
ou para prover a interação entre os atores. Os procedimentos auxiliam
os atores na realização das atividades e no uso de recursos (BORSOI,
2008, p. 29).
Para entender melhor os modelos de fábrica de software que serão apresentados

nos próximos tópicos, é necessário fazer a apresentação de um modelo genérico
com a relação dos componentes, conforme cada camada do modelo. De acordo
com Fernandes e Teixeira (2011, p. 139), “esse modelo genérico possui compo-
nentes que atendem a todos os modelos de Fábrica de software”.

57
Processo de Gestão Estratégica do Processo de Software

Gestão Gestão
Planejamento Recursos Segurança
Conhecimento da Mudança,
Estratégico Humanos
Gestão Tecnologias e
Processos Treinamento
Melhoria
Planejamento
Tecnológico Gestão Planejamento Compliance Gestão do
Financeira de Riscos Desempenho
Processo de Gestão da Operação

Gestão da Revisão Planejamento e Gestão da Qualidade
Demanda Conjunta Controle da Produção e Produtividade

Recebimento e Gestão de Controle de Projeto de Gestão de
Liberação Problemas Recursos e Custos Implementações Contratos
Planejamento Gestão da Gestão de Controle de Gestão do Aten-
e Aceitação Configuração Subcontratos Recursos dimento ao cliente
Processo de Gestão do Projeto

Controle de
Requisitos Controle de Revisão Homologação da
Construção
Mudanças conjunta Ordem de Serviço
Controle de
Prazos
Controle de Controle de Gestão de Gestão de
Controle de Riscos Subcontratos Testes Problemas
Custos
Processo de Construção do Produto de software

Especificação Teste de Preparação
Requisitos Planejamento Aceitação Teste
Construção
de Testes
Análise da
Implantação Instalação
OS
Desenvolvimento Testes de
Testes de do Projeto Unitário Teste Atendimento a
Sistemas Integrado Ajustes
Processo de Suporte
Serviços de Serviços de Suporte Serviços de Serviços de
Suporte de de Engenharia de Suporte Suporte
Software Software Instraestrutura Administrativo
Figura 1 – Componentes da Fábrica de software

Fonte: adaptada de Fernandes e Teixeira (2011, p. 140).

58 UNIDADE II
Componentes do Processo de Gestão Estratégica do Processo de software:

■■ Planejamento Estratégico: visa estabelecer objetivos de longo prazo
para a operação e deve decidir aspectos estratégicos, como: ampliar ou
criar uma nova linha de serviços, novas tecnologias, ferramentas, estru-
tura de custos etc.
■■ Planejamento de Tecnologia e Processos: define quais tecnologias e pro-
cessos devem ser prospectados e testados, averiguar tendências de mercado,
avaliar o impacto das novas tecnologias e processos sobre a operação.
■■ Planejamento de Riscos: trata do desenvolvimento de Plano de
Contingências e de Riscos para a fábrica de software.
■■ Compliance: trata de assegurar que os padrões estabelecidos pela fábrica
estejam sendo seguidos, auditar processos e a operações, propõe mudan-
ças e sugere novos controles, garantindo que qualquer não conformidade
encontrada seja solucionada.
■■ Gestão Financeira: tem por objetivo a manutenção do equilíbrio finan-
ceiro da fábrica de software e, com isso, garante os investimentos e margens
de lucro do negócio.
■■ Gestão da Mudança em Tecnologia e Processos: trata do planejamento de
mudanças nas tecnologias da fábrica em termos de software, implementa-
ções, dispositivos de segurança, servidores, dispositivos de armazenamento
etc.
■■ Gestão da Melhoria: tem por objetivo promover as melhorias nos proces-
sos em todos os níveis da fábrica, em que cada melhoria é tratada como
um projeto e, assim, identificar as causas de baixo desempenho, elimi-
nando essas causas e avaliando os resultados das ações.
■■ Gestão do Desempenho: preocupa-se com o desempenho da fábrica,
conforme as metas estabelecidas. O objetivo é medir o comportamento
de indicadores, conhecer tendências e avaliar o resultado das ações de
melhorias na operação.
■■ Recursos Humanos: trata da gestão de recursos humanos em todos os
setores da fábrica, como: seleção e contratação, avaliação de desempenho
individual, benefícios e avaliações comportamentais.

59
■■ Treinamento: permite a absorção de novos integrantes, com a formação

requerida e a absorção de novas tecnologias e linguagens.
■■ Segurança: item de maior preocupação, é requerido pelos clientes e
usuários de uma fábrica de software, pois envolve: pessoas, dados, equi-
pamentos, instalações, prevenção contra vírus de computador, invasões
na rede, proteção de documentos dos clientes e usuários, proteção aos
programas dos clientes, proteção aos documentos de processos, métodos
e técnicas da própria fábrica.
■■ Gestão do Conhecimento: tem por objetivo o controle e a disposição
de todo o acervo de conhecimento gerado pela fábrica, como: métodos,

procedimentos documentados, componentes reutilizados, manuais de
produtos, acervo bibliográfico, manuais de usuários etc.
Componentes do Processo de Gestão da Operação:

■■ Gestão da Demanda: objetiva o monitoramento de todas as demandas
que entram na fábrica e o controle da capacidade produtiva, em perspec-
tiva de médio prazo. Acompanha o volume de ordens de serviços, cada
etapa e possibilita o rastreamento ao longo da produção.
■■ Recebimento e Liberação: tem por objetivo a gestão de todo a comuni-
cação operacional da fábrica com os clientes e usuários.
■■ Planejamento e Aceitação: tem por objetivo estabelecer as estimati-
vas relativas à ordem de serviços e, a partir disso, elaborar um Plano
de Atendimento. Este requisito varia conforme o escopo da fábrica de
software.
■■ Gestão de Problemas: tem por objetivo a resolução de problemas que
ocorrem durante o desenvolvimento das operações e na execução das
ordens de serviços. Principais tarefas: capturar a ocorrência dos proble-
mas e do incidente, classificar o tipo de incidente, avaliar o impacto dos
problemas, desenvolver uma solução, garantir recursos para a resolução
do problema e gerar relatórios de exceção.
■■ Gestão da Configuração: é o processo responsável por manter uma
biblioteca de itens de software e demais componentes da fábrica. Este item
deve controlar as versões dos itens de software de cada ordem de serviço
e componente reutilizáveis.

60 UNIDADE II
■■ Planejamento e Controle de Produção: é responsável por colocar a ordem

de serviço no “plano da produção” e encaminhá-la à produção. É o PCP que
informa à produção se a ordem de serviço deve ser: cancelada, suspensa
ou se terá que fazer horas extras para atender à demanda. O PCP deve
ter um rigoroso controle do status da execução de cada ordem de serviço.
■■ Revisões Conjuntas da Operação: são revisões sobre o desempenho da
operação junto aos clientes e usuários para avaliar melhorias e novas dire-
trizes para a operação.
■■ Gestão de Subcontratos: tem por objetivo a gestão de fornecedores da
fábrica. Também tem a responsabilidade da auditar a operação do forne-
cedor, se esta for crítica para a fábrica.
■■ Controle de Riscos: é o controle do risco da operação e é baseado no
Planejamento de Riscos. Este item deve monitorar riscos, atuar nas ocor-
rências dos riscos, verificar a efetividade dos riscos e da execução do Plano
de contingência.
■■ Projetos de Implementação: referem-se aos projetos relativos a novos
clientes e usuários da fábrica, novas linhas de serviços, novas tecnolo-
gias, novos processos e melhorias dos processos já existentes na fábrica.
■■ Gestão de Contratos: é responsável pelos acordos de contratos em níveis
de serviços com os diversos clientes ou usuários.
■■ Gestão da Qualidade e Produtividade: este item trata dos seguintes
aspectos: gestão da qualidade em sistemas, das certificações de qualidade
e novas tendências relativas à qualidade.
■■ Logística de Recursos: trata da seleção, aquisição ou contratação e dis-
posição e controle (disponibilidade e consumo) de recursos humanos e
materiais para o projeto.
■■ Controle de Custos: trata do controle de custos de toda a operação, como:
orçamento da operação, monitoramento dos custos de linhas de serviços,
contratos e contas, e avaliação de tendências de custos.
■■ Gestão do Atendimento ao Cliente: refere-se ao acolhimento de cha-
madas relativas às ordens de serviço, suas soluções e acompanhamento
junto ao cliente.

61
Componentes do Processo de Gestão do Projeto:

■■ Controle de Requisitos: é responsável pelo controle do escopo da ordem
de serviço. Algumas tarefas deste item: controle dos requisitos verificados
por usuários, avaliar o grau de atendimento dos produtos aos requisitos
do cliente, solicitações de mudanças em requisitos, solicitações de corre-
ções, avaliar o desempenho da execução dos requisitos e acompanhar a
implantação das mudanças nos documentos de requisitos.
■■ Controle do Prazo: determina a medição do progresso físico do projeto,
pelas atualizações de cronograma, controle de mudanças no cronograma
e avaliar o desempenho da execução da ordem de serviços conforme o

cronograma.
■■ Controle do Custo: responsável pelas atualizações do orçamento de custo
das ordens de serviços, abrange o controle de mudanças do custo e ava-
lia os impactos das mudanças de requisitos.
■■ Controle de Risco: tratam exclusivamente dos riscos da ordem de ser-
viços que não atendem aos requisitos funcionais, não funcionais e de
negócios, custo, prazos e qualidade.
■■ Controle da Qualidade: tem por objetivo assegurar que o produto que
está sendo desenvolvido esteja de acordo com os padrões estabelecidos
de qualidade e de engenharia de software e esteja aderente aos requisi-
tos solicitados.
■■ Controle da Mudança: processo que trata de todas as mudanças da ordem
de serviços e avalia o impacto destas em todos os aspectos, comanda a
atualização de todos os planos e do escopo. Este item tem como missão:
manter a integridade das linhas de base dos Planos do Projeto.
■■ Gestão de Subcontrato: refere-se ao controle das atividades desenvolvi-
das por terceiros ou parceiros na execução de atividades nas ordens de
serviços.
■■ Gestão de Problemas: trata exclusivamente de problemas relativos à exe-
cução e controle das ordens de serviço da fábrica.
■■ Gestão do Teste: trata do controle do planejamento dos testes e sua exe-
cução, preocupa-se em controlar o cronograma da execução e verificar

62 UNIDADE II
os recursos disponíveis, monitora os defeitos, controla os custos dos tes-

tes e estima o nível de estabilidade do software após a liberação para o
cliente e usuário.
■■ Gestão do Desempenho do Projeto: tem por objetivo permitir avaliar o
desempenho do projeto em termos do atendimento aos objetivos quanto
ao custo, ao prazo, à qualidade e ao escopo.
■■ Revisão Conjunta: seu objetivo é integrar o cliente ou o usuário no
gerenciamento do projeto conforme o plano organizacional, por meio
de reuniões programadas para avaliar e acompanhar o desempenho do
projeto.
■■ Homologação da Ordem de Serviço: tem por objetivo obter o sign-off
da ordem de serviço junto ao cliente. A homologação tem que estar de
acordo para que todos os requisitos da ordem de serviço sejam cumpri-
dos e, assim, o cliente formalize seu recebimento e término. Homologação
significa: encerrar contratos, liberar recursos humanos e demais recur-
sos, arquivos dos documentos e registros, notificar o término da ordem
de serviço e controlar todas as atividades pós-encerramento.
Componentes do Processo de Construção do Produto de software:

■■ Análise das Ordens de Serviço: trata do recebimento da ordem de ser-
viços para execução pela equipe de desenvolvimento.
■■ Especificação de Requisitos: trata da especificação dos requisitos funcio-
nais e não funcionais. Seguintes tarefas: levantamento de requisitos junto
ao cliente, observações, reuniões, entrevistas, identificação de restrições,
projetar a arquitetura do software (em alto nível), diagramas de casos de
uso, diagramas de classe etc.
■■ Desenvolvimento do Projeto: trata do detalhamento das especificações
dos requisitos, como elaborar o modelo físico de dados, criação de banco
de dados, rotinas de apoio, especificação de componentes e aplicações.
■■ Construção: trata da elaboração de códigos, programas e componentes
com base nas especificações de requisitos.
■■ Planejamento do Teste: deve definir quais os objetivos do plano de testes,
quais os testes que serão realizados, quem irá realizar os testes, quando os

63
testes serão realizados, casos de teste a serem realizados e recursos neces-

sários para a realização dos testes.
■■ Preparação do Teste: tem por objetivo disponibilizar todos os recursos
materiais e humanos para a execução dos testes.
■■ Teste Unitário: é o teste que é feito em cada programa ou componente
desenvolvido pela fábrica.
■■ Teste Integrado: teste que faz a integração dos programas em partes
funcionais e verifica se os mesmos se comunicam conforme o projeto de
arquitetura.
■■ Teste de Sistemas: é o teste do software e suas interfaces com outros sis-

temas e dispositivos antes de estar disponível para o cliente.
■■ Instalação: trata do planejamento da instalação, do ambiente onde vai
ser instalado, configurações e compatibilidades de software e hardware.
■■ Teste de Aceitação: teste executado em ambiente controlado de homo-
logação, realizado pelo cliente ou usuário, em que ele aceita, condiciona
ou reprova o software.
■■ Implantação: trata da preparação de documentações para o usuário, guias
de produção e treinamento aos usuários e clientes.
■■ Atendimento a Ajustes: significa a resolução de defeitos e falhas encon-
trados durante a implantação do sistema.
Componentes do Processo de Suporte:

■■ Serviços de Suporte de software e Segurança: referem-se ao suporte em
linguagens de programação, softwares de apoio ao ambiente e de sistemas
de banco de dados. Compreende as atividades de suporte de softwares de
redes, de comunicação, atualizações dos softwares existentes na fábrica,
estudo de novos softwares, instalações de software, implantação de política
de segurança, controle de vírus, controle de licença de software, controle
de privilégios no banco de dados e criação de banco de dados.
■■ Serviços de Suporte em Engenharia de software: referem-se ao suporte
em métodos, processos, técnicas e modelos de engenharia de software às
equipes da fábrica.

64 UNIDADE II
■■ Serviços de Suporte em Infraestrutura: trata de instalações e manuten-

ções de equipamentos computacionais e de redes, controle do acervo de
hardware, operação do Datacenter, rotinas de backup, tarefas de recupe-
ração de dados e configuração dos softwares da fábrica.
■■ Serviços de Suporte Administrativos: contemplam manutenção das
instalações físicas da fábrica, os serviços gerais, controle de compras, esto-
que, atividades de recursos humanos e controle do financeiro da fábrica
de software.
Nos tópicos a seguir, vamos falar sobre os modelos de fábrica de software base-
ados em processos, baseados em produtos, baseados em projetos e baseados em
programas.
A busca pela qualidade, pela produtividade e pelo baixo custo de produção

são requisitos perseguidos pelas Fábricas de software.
(Fernando Guilherme Tenório e Rogério Valle)
FÁBRICA DE SOFTWARE BASEADA EM PROCESSOS
Para Tenório e Valle (2012, p. 63), “o conceito de fábrica de software baseia-se na

ideia de prover uma linha de produção de soluções que atendam às necessidades
específicas de cada cliente”. Em uma fábrica de software podemos ter diferentes
processos, que são adequados a diferentes projetos.
Ter um processo definido é importante para organizar e disciplinar o desen-
volvimento de software, determinando as atividades fundamentais que deverão
ser realizadas. Um processo padrão bem estabelecido deve ser tomado como
referencial no planejamento e definição de estratégias de cada fábrica e deve ser
genérico para atender a maioria dos projetos. Adotando um processo padrão, há
uma economia de tempo, esforço e custo a cada necessidade de customização,
conforme as particularidades de cada projeto a ser desenvolvido.

65
Para um perfeito funcionamento

das atividades da fábrica de software,
de acordo com Tenório e Valle (2012),
é importante a adoção de um processo
de desenvolvimento no qual as tarefas e
os artefatos gerados estejam bem defi-
nidos e com os responsáveis alocados
para cada uma delas.
Um processo de desenvolvimento
de software é um conjunto de ativi-

dades que são necessários para se
transformar os requisitos do cliente
em software. Para Borsoi (2008), “pro-
cesso de software é conceituado como
um conjunto de atividades organizadas
de maneira a alcançar objetivos rela-
cionados ao ciclo de vida de software”. Existem diferenças entre um processo de
desenvolvimento de software e um processo de manufatura, como:
■■ O produto de software é mais complexo do que o produto manufaturado;
■■ No mercado não temos muitos profissionais com conhecimento e experi-
ência para avaliar e calibrar um processo de desenvolvimento de software;
■■ O custo de reproduzir o software leva a descobertas tardias de problemas;
■■ Tangibilidade fica a dever aos produtos manufaturados;
■■ O processo de trabalho é imaterial e não material;
■■ O cliente não consegue visualizar e externalizar com clareza suas
necessidades.
Um processo produtivo está sempre associado a um processo gerencial, que se
traduz na gestão de uma ou várias demandas e na gestão de uma ou várias ope-
rações estratégicas (TENÓRIO; VALLE, 2012).
Fábrica de Software Baseada em Processos

66 UNIDADE II
Processos de Desenvolvimento de software

O conceito de fábrica de software baseia-se na ideia de prover uma linha
de produção de soluções que atendam às necessidades específicas de cada
cliente. Isto se dá através da formalização de todas as atividades e seus pro-
dutos, trabalhando em forma de linha de produção, com etapas e tarefas
bem definidas para cada tipo de profissional, indo das tarefas básicas da
linha de produção até rotinas de controle de qualidade [...]. Em uma fábrica
de software, diferentes processos podem coexistir adequados a diferentes
projetos. A definição de um processo padrão estabelece uma estrutura co-
mum a ser utilizada pela organização nos seus projetos de software e cons-
titui a base para a definição de todos os processos [...]. Assim sendo, o pro-
cesso padrão estabelecido deve ser tomado como referencial no necessário
planejamento e definição das estratégias de cada fábrica e deve ser genéri-
co o suficiente para atender na maioria dos casos.
Fonte: Xavier (2008).
O processo também pode ser considerado um elo entre a equipe, as tecnologias

e as estruturas organizacionais de forma coerente que os objetivos e as metas são
transformados em um negócio. Assim, um processo deve:
■■ Nortear a definição dos papéis organizacionais e suas responsabilidades;
■■ Especificar as funções a serem desempenhadas;
■■ Prover a direção estratégica e gerenciar o desempenho do processo;
■■ Ter técnicos com habilidades e competências nas atividades do processo;
■■ A tecnologia deve automatizá-lo e apoiá-lo.
Para Pressman e Maxim (2016), um processo é formado por um conjunto de

atividades, ações e tarefas realizadas na criação de algum produto de trabalho,
definindo quem está fazendo o quê, quando se está fazendo e como será feito
para atingir o objetivo.

67
Uma atividade esforça-se para atingir um objetivo amplo (por exemplo,

comunicar-se com os interessados) e é utilizada independentemente do
campo de aplicação, do tamanho do projeto, da complexidade de esfor-
ços ou do grau de rigor com que a engenharia de software será aplicada.
Uma ação (por exemplo, projeto de arquitetura) envolve um conjunto de
tarefas que resultam num artefato de software fundamental (por exem-
plo, um modelo de projeto de arquitetura). Uma tarefa se concentra em
um objetivo pequeno, porém, bem definido (por exemplo, realizar um
teste de unidades) e produz um resultado tangível. No contexto da en-
genharia de software, um processo não é uma prescrição rígida de como
desenvolver um software. Ao contrário, é uma abordagem adaptável que
possibilita às pessoas (a equipe de software) realizar o trabalho de sele-
cionar e escolher o conjunto apropriado de ações e tarefas. A intenção é a

de sempre entregar software dentro do prazo e com qualidade suficiente
para satisfazer àqueles que patrocinaram sua criação e àqueles que irão
utilizá-lo (PRESSMAN; MAXIM, 2016, p. 40).
Segundo Pressman e Maxim (2016), quando trabalhamos na elaboração de um

produto ou sistema, é importante tentar seguir uma série de passos previsíveis,
como um roteiro ou guia que ajude a chegar ao resultado esperado e que seja de
alta qualidade e dentro do prazo estabelecido. O autor chama este roteiro de “pro-
cesso de software”.
Um processo de desenvolvimento de software pode ser classificado em dois
tipos, conforme a sua forma de execução:
■■ Tradicionais: processo considerado mais pesado. Levantamento deta-
lhado dos requisitos do sistema antes do início do desenvolvimento.
■■ Ágil: processo considerado mais leve. Trabalha com a premissa de que
mudanças são inevitáveis, que cada atividade deve agregar valor ao pro-
cesso e sua gestão é orientada a pessoas.
Porém, qual deles usar em uma fábrica de software? No processo tradicional, a

burocracia de documentação lhe agrega uma quantidade de tarefas maior e com
um previsível impacto no prazo da execução. Porém, a informalidade do pro-
cesso ágil dificulta o desenvolvimento de software quando este é mais complexo
ou seu escopo é grande, ou a equipe é numerosa.
Para Tenório e Valle (2012), as fábricas de software que atendem ao modelo
outsourcing adotam o processo tradicional, pois o cliente, muitas vezes, exige certifi-
cações da fábrica em um modelo de qualidade que seja reconhecido mundialmente.

68 UNIDADE II
Com isso, força a definição bem clara dos processos bem documentados, das ati-
vidades, metodologias e métricas de produção utilizadas na fábrica de software.
Assim, um processo de desenvolvimento não é genérico para cada fábrica
de software, mas pode ser adequado ao tipo e ao contexto da fábrica, conside-
rando os seguintes fatores:
■■ Finalidade da fábrica de software (pacotes ou software sob encomenda);
■■ Processos básicos de produção de software (desenvolvimento e/ou
manutenção);
■■ Características do cliente;
■■ Perfil da equipe (conhecimento e experiência);
■■ Disponibilidade de recursos;
■■ Paralelismo de projetos na fábrica;
■■ Diversidade das plataformas de desenvolvimento.
Esses fatores são importantes na escolha das ferramentas automatizadas de apoio
que serão usadas nos processos de desenvolvimento e gestão do software, bem
como nos testes e tratamentos a erros e defeitos, na infraestrutura a ser adotada
e na rede necessária para a fábrica de software.
Para a fábrica de software baseada em processos, vamos considerar que os
processos de software são representados por meio de modelos que são organi-
zados em visões. Essas visões são abstrações de processos, definidas de acordo
com os objetivos e requisitos dos processos. Tais visões são referentes a perspec-
tivas e podem ser categorizadas em:
■■ Visão Funcional: contém elementos do processo que estão sendo reali-
zados e seus fluxos de produtos.
■■ Visão Organizacional: representa onde e quem realiza os elementos do
processo.
■■ Visão Comportamental: representa o tempo gasto na realização dos ele-
mentos do processo.
■■ Visão Informacional: contém as informações das representações dos
produtos implementados pelos elementos do processo.

69
As visões de processos também podem ser estabelecidas em função dos seus com-
ponentes. Os componentes indicados são: atividade, recursos e produto. As visões
de atividades e de produtos representam os aspectos dinâmicos do processo, e as
visões de recursos humanos são relacionadas aos aspectos estáticos do processo.
Porém, o que seria um componente de processo? Componente de processo
é como um grupo de atividades ou outros componentes que se relacionam por
dependências lógicas e que quando executados fornecem valor ao projeto da
fábrica de software.
Componentes
Um componente pode ser definido como uma unidade de software inde-
pendente, que encapsula, dentro de si, seu projeto e implementação, e ofe-
rece serviços, por meio de interfaces bem definidas, para o meio externo.
A motivação para componentes não é unicamente relacionada à reutiliza-
ção. As recentes pressões para liberação de produtos no mercado (time-to-
-market), assim como a necessidade de lidar com modificações de maneira
rápida e efetiva, tem contribuído para a relevância de componentes na pro-
dução de software.
Fonte: Gimenes e Huzita (2005).
MODELAGEM DOS PROCESSOS DA FÁBRICA DE SOFTWARE
A modelagem de processos, conforme Borsoi (2008), abrange a abstração do que

será representado. Esta modelagem é usada para criar e gerenciar as instâncias
de processo em uso. A qualidade de software é considerada sistêmica à fábrica
de software e está vinculada aos processos de software. Utilizamos a orientação
a objetos para definir os modelos de processos, e as normas e modelos de qua-
lidade são utilizados na realização das atividades de cada etapa da modelagem
de processos (Figura 2).

70 UNIDADE II
Elicitar os Realizar análise Definir Definir a

requisitos dos requisitos modelo arquitetura de
do processo do processo de processo processo
Modelo do
processo
Figura 2 – Atividades da fase de Modelagem de processos

Fonte: Borsoi (2008, p. 40).
Elicitar os requisitos do processo: nesta atividade, o domínio e o contexto
para os processos são definidos usando abstrações desse domínio em que são
identificados os atributos, o comportamento, os relacionamentos, os componen-
tes, as ações das atividades e os papéis.
Realizar análise dos requisitos do processo: nesta atividade, os objetos
que representam o processo e os seus componentes, os estados do processo e os
seus componentes, são definidos e organizados de acordo com a classificação
da orientação a objetos.
Definir modelo de processo: nesta atividade, o modelo de processo é espe-
cificado ou construído de maneira a atender aos requisitos da visão que o modelo
representa. Para representar os modelos de processos, utiliza-se linguagens de
modelagem, como a UML (Unified Modeling Language).
Definir a arquitetura de processo: nesta atividade, os modelos de proces-
sos podem ser organizados de forma a compor uma estrutura que chamamos
de arquitetura de processo. Esta atividade é realizada em conjunto à definição
do modelo de processo, porque os modelos são utilizados para definir a arqui-
tetura e as visões dessa arquitetura.
Conforme Borsoi (2008, p. 41), “modelos de processos podem ser represen-
tados por meio de representação formal, modelos gráficos ou descrição textual”.
No entanto, independentemente da forma de representação escolhida, a repre-
sentação de processos vai sempre estar vinculada à linguagem escolhida.

71
A UML (Unified Modeling Language) é uma linguagem padrão usada para

especificar, visualizar, construir e documentar os artefatos de sistemas de
software. Ela foi criada em 1997, pelo OMG (Object Management Group).
A UML é considerada um padrão para desenvolvimento de software, que
reúne as melhores práticas de metodologia de sistemas, diversos diagramas
que ajudam na visualização do problema e a concepção da solução para
sistemas orientados a objetos. Ela fornece representação gráfica para os
elementos do paradigma de orientação a objetos, como: classes, atributos,
associação, generalização, diagramas, objetos e troca de mensagens entre
esses objetos.
Fonte: Bezerra (2007, p. 15).
FÁBRICA DE SOFTWARE BASEADA EM PRODUTOS
Em uma Fábrica de Software

Orientada a Produtos, o desen-
volvimento funciona em torno
dos produtos de software produ-
zidos, conforme será mostrado na
Figura 4. A fábrica de software con-
cilia a rotina de manutenção de seus
produtos, seja ela evolutiva ou cor-
retiva, com as demandas geradas
por diferentes projetos, que resul-
tam no surgimento ou na evolução
de funcionalidades do produto.
Assim, o produto é sempre mantido dentro da fábrica, podendo ser customi-
zado ou parametrizado para os clientes dos projetos.
Conforme Oliveira (2007, p. 16), “dentro da estrutura de fábrica orientada
a produtos é importante citar o papel do gerente de produtos, que comanda o
desenvolvimento demandado pelos projetos” e que garante a completude do pro-
duto que sofre modificações constantemente.
Fábrica de Software Baseada em Produtos

72 UNIDADE II
Fábrica
Funcionalidades Erro/Melhorias Funcionalidades
Projeto 1 Manutenção Projeto N
Equipe Equipe Equipe
Funcionalidades Funcionalidades
Erro/Melhorias Erro/Melhorias
Projeto 1 Manutenção Projeto 1 Manutenção Projeto N

Projeto - Versão 1.0 Projeto - Versão 2.0
Figura 4 - Representação do desenvolvimento orientado a produtos

Fonte: adaptada de Oliveira (2007, p. 16).
Vamos avaliar a abordagem orientada a produtos sob três pontos de vista

importantes:
■■ Esforço de gerência;
■■ Produção de informações e dados históricos;
■■ Gerência de configuração.
Há uma preocupação constante na fábrica orientada a produtos em relação aos

impactos gerados por um projeto com muitas mudanças, que é não afetar os
outros projetos em andamento e também o produto existente. O rastreamento
de solicitações de mudanças nas funcionalidades existentes torna-se um fator
crítico de sucesso ou de risco de uma fábrica orientada a produtos.

73
Desta forma, o gerenciamento das atividades de desenvolvimento do produto

torna-se complexo para atender às demandas específicas e, por isso, o gerente
da fábrica deve planejar o alinhamento da entrega dos projetos existentes ao
planejamento de liberação das versões do produto, sem comprometer os clien-
tes que já possuem o mesmo produto em produção ou com versões diferentes.
Com isso, podemos perceber que na fábrica orientada a produtos, o gerente
tem um esforço maior e mais complexo com relação à produção de informações
e dados históricos para a geração de estimativas voltadas a projetos em anda-
mento e projetos futuros.
Já a produção de informações e dados históricos em uma fábrica orientada

a produtos é diferente: mesmo que existam vários projetos paralelos, todos eles
trabalham sob a ótica de um mesmo produto. A partir disso, para Oliveira:
Os dados históricos produzidos ao longo da execução de projetos po-
dem ser realmente utilizados como base para estimativas futuras, pois
o entendimento do domínio não varia a cada novo projeto (já que a
equipe de desenvolvimento passa a ser formulada por especialistas no
negócio). Assim, o fato entendimento do negócio passa a ter um peso
menor quando avaliando os riscos associados aos projetos e ao produto
(OLIVEIRA, 2007, p. 17).
Como o foco da fábrica orientada a produto é o produto, a gerência de configura-

ção está voltada totalmente ao produto. Assim, os projetos que são responsáveis
por gerarem novas funcionalidades ao produto e às manutenções evolutivas e cor-
retivas possuem uma gerência de configuração que complementa a do produto.
O controle da configuração do produto deve ser bem planejado e controlado,
para que os projetos não criem controvérsias no produto que está sendo alte-
rado. Deve haver também um controle de versão rigoroso para que a geração
de versões do produto alcance os resultados dos projetos e das manutenções.

74 UNIDADE II
Controle de Versão
O Controle de Versão combina procedimentos e ferramentas para gerenciar
diferentes versões dos objetos de configuração criados durante o processo
de software. O uso de ferramentas para obter o controle de versão é essen-
cial para uma gestão eficaz de alterações.
Fonte: Pressman e Maxim (2016).
O gerente responsável pela gerência de configuração passa a ter um papel impor-
tante dentro da fábrica de software orientada a produtos. Deve manter o controle
sincronizado das configurações do produto com as configurações de cada pro-
jeto dentro de fábrica.
Com relação à estruturação de uma fábrica de software, o ciclo de vida do
software em desenvolvimento geralmente possuirá como base as seguintes etapas/
fases: planejamento, especificação de requisitos, análise e projeto de requisitos,
construção, implantação e transição. Nas fábricas de software orientadas a pro-
duto, essas etapas/fases deverão tratar o desenvolvimento de novas funcionalidades
para o produto e também controlar as manutenções evolutivas ou corretivas. Isso
significa que na fase de planejamento, por exemplo, devem ser considerados os
projetos de novos produtos em desenvolvimento, como também os pedidos de
mudanças para o produto atual. Para Pressman e Maxim (2016, p. 639), “iden-
tificação, controle de versão e controle de alteração ajudam a manter a ordem
naquilo, de outra forma, seria uma situação caótica”.

75
Gestão de Configuração de software

Durante a criação de software, mudanças acontecem. E, por isso, precisamos
gerenciá-las eficazmente. A gestão de configuração de software (SCM), tam-
bém chamada de gestão de alterações, é um conjunto de atividades des-
tinadas a gerenciar as alterações, identificando artefatos que precisam ser
alterados, estabelecendo relações entre eles, definindo mecanismos para
gerenciar diferentes versões desses artefatos, controlando as alterações im-
postas e auditando e relatando as alterações feitas. Se você não controlar

as alterações, elas controlarão você – e isso nunca é bom. É muito fácil uma
sequência de alterações não controladas transformar um bom software em
um caos. Como consequência, a qualidade do software é prejudicada, e a
entrega atrasa. Por essa razão, a gestão de alterações é parte essencial da
gestão da qualidade.
Fonte: Pressman e Maxim (2016).

76 UNIDADE II
FÁBRICA DE PROJETOS
Em uma Fábrica de Projetos de software, a rotina funciona por meio da exe-

cução de diversos projetos paralelos. Os projetos podem ser independentes ou
reusar componentes entre si, mas todos os projetos possuem um começo, meio
e fim planejados, não havendo um produto que deva ser atualizado pelos proje-
tos que estão sendo executados.
Da mesma forma que avaliamos a abordagem orientada a produtos sob três pon-
tos de vista importantes, vamos também avaliar a abordagem orientada a projetos:
■■ Esforço de gerência;
■■ Produção de informações e dados históricos;
■■ Gerência de configuração.
O resultado da fábrica com o contexto orientado a projetos pode variar conforme

a demanda de projetos existentes. Nesta estrutura, o gerente de projetos pode
ser responsável por cada projeto ou os projetos podem ser distribuídos entre um
grupo de gerentes, dependendo do porte da empresa.

77
Nas fábricas de projeto, não ocorre a preocupação com impactos que possam
ocorrer entre projetos, somente acontece quando os projetos são interdependentes.
Com relação à gerência de configuração e ao controle de versões e plane-
jamento de liberação de versões dos produtos que são gerados pelos projetos
em andamento, independente de sua complexidade, são gerenciados apenas no
domínio de cada projeto. Com isso, cada projeto passa a ter um comportamento
completamente diferente dos outros (Figura 4).
Fábrica
Demanda 1 Demanda 2 Demanda 3
Projeto 1 Projeto 2 Projeto N
Equipe Equipe Equipe
Produto 1 Produto 2 Produto N
Figura 4 - Representação do desenvolvimento orientado a projetos

Fonte: adaptada de Oliveira (2007, p. 17).
No contexto da fábrica orientada a projetos, o esforço gerencial é menor em rela-

ção à produção de informações e dados históricos para geração de estimativas
em projetos futuros, pois os projetos da fábrica de software nem sempre possuem
características comuns entre eles, de modo que o processo de estimativas leva
em consideração quesitos técnicos, como: domínio de linguagem de programa-
ção, arquitetura, produtividade da equipe, entre outros (OLIVEIRA, 2007, p. 18).
Assim, para entendermos o domínio vinculado às regras de negócio no qual
o projeto está inserido, nem sempre é possível realizar estimativas, pois não há
Fábrica de Projetos
78 UNIDADE II
garantia de vínculo da fábrica de software a um único ramo de negócio. Esse

ponto de vista passa a ser um risco embutido nas estimativas da fábrica de sof-
tware, que deve ser bem planejado durante o desenvolvimento do projeto.
A gerência de configuração em uma fábrica de software orientada a proje-
tos pode variar completamente entre os projetos que estão sendo desenvolvidos,
pois cada projeto possui características específicas conforme as regras de negó-
cio dos clientes dos projetos, causando um trabalho adicional para os gerentes
de configuração.
Conforme Oliveira (2007, p. 18), “no entanto, esta característica das fábri-
cas orientadas a projeto possibilita facilmente a paralelização dos recursos de
gerência de configuração”. Como toda as características do projeto interferem
apenas no próprio projeto, é possível ter em cada projeto um gerente de confi-
guração dedicado.
Para a estruturação de uma fábrica de software, o ciclo de vida do software
desenvolvido geralmente possuirá como base as seguintes etapas/fases: plane-
jamento, especificação de requisitos, análise e projeto de requisitos, construção,
implantação e transição. Assim, no contexto de fábricas de software orientadas
a projetos, estas etapas/fases passam a ser distribuídas de acordo com o ciclo
de desenvolvimento adotado pela empresa para cada projeto a ser executado.
Segundo Fernandes e Teixeira (2011, p. 198) “a fábrica de projetos tanto tra-
balha com novos desenvolvimentos, como manutenções evolutivas, legais e de
otimização, como pode acolher atendimento a projetos físicos somente”. Tudo
vai depender do contexto do projeto do cliente e seu nível de interface. Pois há
situações em que o cliente faz as especificações do software e a fábrica de proje-
tos executa a parte física.
Dentro da fábrica de projetos, podemos ter a fábrica de programas e a fábrica
de testes, principalmente se a missão da empresa for de desenvolvimento de
software de produtos (pacotes de gestão, controle etc.). A fábrica de projetos
considerada mais simples é aquela que tem o foco somente em novos desenvol-
vimentos e projetos físicos para clientes do mesmo ramo de negócios, em que ela
pode ganhar em função da especialidade. Porém, ela pode se tornar complexa, à
medida que começa a atender clientes de várias indústrias e de segmentos dife-
rentes. Outro fator que aumenta a complexidade da fábrica de projetos são os

79
desenvolvimentos com aplicativos em múltiplas plataformas, sua manutenção

posterior e o nível de integração entre os aplicativos.
Nas linhas de processos de fábrica de projetos, conforme Fernandes e Teixeira
(2011), também apresentam diferenças à medida que avançamos no ciclo de vida
do desenvolvimento do processo, por exemplo:
Em nível de especificação de requisitos, o conhecimento requerido é do
negócio; portanto, a organização da linha deve ser por negócio. Imagi-
ne uma fábrica de projetos atendendo a um banco comercial; teríamos
uma linha para aplicativos de vanguarda (caixa e autoatendimento),
para gestão (administração de risco) e para as aplicações (poupança) e
assim sucessivamente. Entretanto, em relação ao desenvolvimento do

projeto, o conhecimento requerido é sobre a arquitetura dos softwares
que dão sustentação ao negócio e à tecnologia específica de projeto de-
talhado, de construção e das ferramentas que apoiam o ambiente (FER-
NANDES; TEIXEIRA, 2011, p. 198).
REQUISITOS DA FÁBRICA DE PROJETOS
Para a fábrica de projetos ser considerada bem-sucedida e lucrativa, alguns

fatores-chaves devem ser atendidos. A seguir, discutiremos sobre os que são con-
siderados principais para a obtenção do sucesso.
Demanda: em uma fábrica de projetos podemos ter dois tipos de deman-
das: novos desenvolvimentos e manutenção de sistemas (aqui entre os projetos
físicos). Na manutenção de sistemas podemos ter as customizações de sof-
tware, como ERP (Enterprise Resource Planning), CRM (Customer Relationship
Management) etc. Em novos desenvolvimentos, temos os tipos de plataformas de
desenvolvimento que a fábrica deve possuir para atender o cliente e o seu ramo
de negócio e mudanças previstas, que poderão acontecer ao longo do projeto.
Ordens de Serviço: em uma fábrica de projetos, a principal entrada é a espe-
cificação dos requisitos do software (ou declaração do escopo) que deve conter:
■■ As funcionalidades ou tarefas do software;
■■ Em qual ambiente o software vai ser usado;
■■ Quais os usuários que irão utilizar o software;
80 UNIDADE II
■■ Restrições de uso do software;

■■ Regras de negócio/legislação do software;
■■ Arquitetura preliminar do software;
■■ Equisitos não funcionais que o software deve atender (desempenho, segu-
rança, usabilidade etc.);
■■ Requisitos funcionais;
■■ Prazos e custos do projeto.
Regras de Comunicação e de Interfaces com o cliente: em uma fábrica de
projetos, as regras de comunicação e de interfaces com clientes são importan-
tes para um relacionamento bem-sucedido. Do lado do cliente deve haver um
responsável por organizar as informações e demandas e enviá-las à fábrica. Do
lado da fábrica, deve haver um responsável pelo recebimento das informações e
ordens de serviço e pelo envio do produto para o cliente.
Estimativas: em uma fábrica de projetos, a estimativa é uma questão com-
plexa, pois ela se refere ao tamanho do software, prazo, esforço e custo. A estimativa
deve ser feita com base na definição do escopo do projeto. Podem ser usadas
algumas técnicas para estimativa de tamanho de software, como: Análise por
Pontos de Função apoiados pelas ferramentas de estimativas COCOMO, Slim,
Estimate Professional etc.
Métricas: a fábrica de projetos deve implementar métricas para a sua ges-
tão. As principais são:
■■ Estimativas em termos de tamanho, prazo, esforço e custo;
■■ Estimativas para a produtividade em termos de pontos de função (pro-
dutividade da manutenção e de novos projetos);
■■ Estimativas de taxas de entrega das ordens de serviço no prazo;
■■ Estimativas de ordens de serviço com problemas de qualidade (erros,
defeitos);
■■ Estimativa para custo médio de uma ordem de serviço;
■■ Estimativas de densidade de defeitos padrão do software;

81
■■ Estimativas de taxa média de atendimentos ao escopo dos projetos;

■■ Estimativas de taxa de tempo médio de desenvolvimento;
■■ Estimativa de distribuição do esforço pelas fases do projeto.
Flexibilidade: a fábrica de projetos deve ter a capacidade de implementar

uma nova linha de serviço rapidamente. A equipe deve estar apta a mudanças e
às novas tecnologias, pois esta flexibilidade reduz custo. Portanto, treinamento
contínuo é a chave do sucesso.
Gestão do Conhecimento: para uma fábrica de projetos, a gestão de conhe-
cimento pode ser crítica, pois a gestão do conhecimento envolve: gestão de

habilidades da equipe, dos parceiros, gestão da documentação e informações,
técnicas de engenharia de software, qualidade, componentes reutilizáveis, meto-
dologias e outras informações do sistema. Deve haver mecanismos para a criação,
armazenamento, referenciamento e disseminação do conhecimento, pois ele é
um fator de impulso da produtividade.
Processo definido de Desenvolvimento de software: a fábrica de proje-
tos deve ter um processo definido para o desenvolvimento de software levando
em consideração as técnicas e fases da engenharia de software. Deve pensar em
padrões de documentação e esse processo deve ser customizado para atender às
particularidades de cada projeto.
Questões dos Riscos e da Segurança: em uma fábrica de projetos, devemos
ter uma rigorosa política de segurança e um Plano de Contingência, que garanta
de forma transparente a inviolabilidade de especificações lógicas e físicas, código
gerado, especificações do sistema e dados de teste.
Reutilização de Componentes: em uma fábrica de projetos, este é um fator-
-chave para a qualidade e a produtividade, pois quanto maior a reutilização de
componentes, maior é a produtividade da fábrica. O uso de reutilização de com-
ponentes representa uma operação de custo competitiva, maior margem de lucro,
maior satisfação do cliente, pois a entrega do sistema ocorre em um prazo menor.
Gestão e Controle da Qualidade: em uma fábrica de projetos, a gestão da
qualidade é bem complexa; começa com um controle rígido desde o recebimento
da ordem de serviço, passando ao longo de todo o ciclo de vida do desenvolvi-
mento do sistema, até a sua implantação.
82 UNIDADE II
Automação da Fábrica de Projetos: em uma fábrica de projetos temos a

automação da gestão da demanda, das ferramentas da gestão de configuração,
controle de requisitos, modelagem de software, automação de testes de software,
controle de versão etc.
O QUE É VITAL PARA COMEÇAR A FÁBRICA DE PROJETOS DE

SOFTWARE?
O nível de exigência da fábrica de projetos em termos de componentes é bem
grande em consideração aos demais modelos de fábricas de software. Conforme
o porte da fábrica de projetos, ela deve começar com os seguintes componen-
tes automatizados:
■■ Gestão da demanda;
■■ Workflow do processo (recebimento, planejamento, execução);
■■ Controle de recursos;
■■ Controle de custos e prazos;
■■ Controle dos requisitos;
■■ Modelagem de software;
■■ Ferramentas de produtividade;
■■ Gestão da configuração.

83

Planejamento Gestão Gestão do Recursos Segurança e
de Riscos Financeira Desempenho Humanos Treinamento

Gestão da
Gestão da Gestão de Qualidade e
Demanda Problemas Planejamento e Produtividade
Planejamento e
Controle da
Recebimento e Aceitação Gestão da Controle de Re-
Produção
Liberação Configuração cursos e Custos

Controle de Controle de Controle de Gestão de

Prazos Qualidade Mudanças Testes
Controle de Controle de Gestão de
Riscos Requisitos Contratos

Análise da Ordem Desenvolver Planejamento
Implantação
de Serviço Projetos de Testes
Especificar Testes de Testes Unitários
Construção
Requisitos Sistemas e Aceitação
Processo de Suporte
Serviços de Serviços de Serviços de Serviços de
Suporte de Suporte de Enge- Suporte Suporte
Software nharia Software Instraestrutura Administrativo
Figura 5 – Começo da Fábrica de Projetos

84 UNIDADE II
O QUE PODE SER TERCEIRIZADO PELA FÁBRICA DE PROJETOS?
Algumas atividades podem ser terceirizadas para manter o custo da fábrica de

projetos sob controle, como:
■■ Execução de treinamentos;
■■ Auditorias nos sistemas de qualidade;
■■ Serviços de suporte em infraestruturas;
■■ Testes de alguns sistemas específicos;
■■ Serviços de suporte administrativos.
FÁBRICA DE PROGRAMAS DE SOFTWARE
O objetivo da Fábrica de Programas, conforme Fernandes e Teixeira (2011), é

de codificar e testar os programas, seguindo o
acordo de níveis de serviços com o cliente,
considerando os requisitos, as especifica-
ções de padrões de programas, critérios
de qualidade e tempo de entrega. O
principal insumo em uma fábrica de
programas é a ordem de serviço com
a especificação padrão do programa a
ser desenvolvido em um tempo calculado
e com garantia de qualidade.
Uma fábrica de programas pode tra-
balhar com várias linhas de processos, em
que cada uma corresponde a um tipo de lin-
guagem de programação (Figura 6).

85


Análise da
Construção Planejamento Preparação
Ordem de Testes
do Código de Testes do Teste
Serviço
COBOL
JAVA
DELPHI
Processo de Suporte
Figura 6 - Linhas de Processo na Fábrica de Programas

REQUISITOS DA FÁBRICA DE PROGRAMAS
Para a fábrica de programas ser considerada uma operação bem-sucedida e lucra-

tiva, alguns fatores chaves devem ser atendidos. A seguir, discutiremos sobre os
que são considerados principais para a obtenção do sucesso.
Demanda: este requisito em uma fábrica de programas é crítico para o seu
sucesso. É necessário que haja uma demanda mínima para ser atendida pela
Fábrica de Programas de Software

86 UNIDADE II
fábrica e essa demanda pode ser negociada (nível de colaborador/hora ou pon-

tos de função).
Ordens de Serviço: a fábrica de programas deve ter um padrão de ordens
de serviços e de especificação de programas, para cada linguagem de progra-
mação utilizada pela fábrica, para que seja garantida a execução das tarefas com
qualidade.
Regras de Comunicação e de Interfaces com o Cliente: para uma comu-
nicação bem-sucedida é preferível que haja somente um ponto de contato entre
cliente e a fábrica de programas. Do lado do cliente deve haver um responsá-
vel por organizar as informações e demandas e enviá-las à fábrica. Do lado da
fábrica, deve haver um responsável pelo recebimento das informações e ordens
de serviço e pelo envio do produto para o cliente.
Estimativas: é necessário que a fábrica tenha tabelas padrões de estimativas
de tempo de atendimento de uma ordem de serviço (lead time) e de tempos de
esforço efetivo de programação, neste caso, para cada linguagem de programação.
Métricas: a fábrica deve implantar métricas para a sua gestão e as princi-
pais referem-se à:
■■ Exatidão das estimativas (tabela padrão de tempo e esforço efetivo e
prazos);
■■ Produtividade por linha de serviço e de tempo (cliente, linguagem e
plataforma);
■■ Produtividade de cada programador;
■■ Taxa de entrega das OS no prazo;
■■ Taxa de ordens de serviço com defeitos e problemas.
Flexibilidade: a fábrica de programas deve ter flexibilidade de atendimento

com relação à demanda. Os programadores devem ter conhecimentos sólidos nas
linguagens de programação e devem receber treinamento contínuo e monitorado.
Suprimento de Recursos Humanos: ter recurso humano contínuo na fábrica
de programa é um fator crítico, pois a rotatividade de pessoal é grande. A fábrica
deve ter um projeto de formação e preparação contínua de mão de obra, por
conta própria ou com convênios.

87
Controle da Produtividade: é um requisito primordial para a fábrica de

programas, pois os níveis de serviço exigem um controle rigoroso da produtivi-
dade individual de cada um dos programadores. O aumento da produtividade
da fábrica de programas pode ser aumentada por meio da reutilização de trei-
namentos, processos, padronização de técnicas de programação. O controle da
produtividade, conforme Fernandes e Teixeira (2011, p. 181), “também pode
ser usado para se descobrirem práticas melhores de se fazer a tarefa, a partir do
entendimento dos motivos das maiores produtividades individuais registradas”.
Uso de Padrões Internos: a fábrica de programas deve adotar padrões de
especificação, de técnicas de programação, de projetos, de estrutura de programas,

de arquitetura de software e de planos de teste unitários. Os desenvolvedores da
fábrica de programas devem seguir estes padrões, que devem ser diariamente
reforçados e disseminados junto à equipe.
Questão dos Riscos e da Segurança: este requisito é muito importante para
quem compra os serviços de uma fábrica de programas, pois o cliente quer saber
como seus programas serão protegidos de terceiros e dos concorrentes, que uti-
lizam a mesma fábrica de programas. Em uma fábrica de programas devemos
ter uma rigorosa política de segurança e um Plano de Contingência (ou de ris-
cos) para a operação.
Certificação de Qualidade: a fábrica de programas deve investir em mode-
los de qualidade de softwares, como, por exemplo, o CMMI, ISSO e PMI, que
podem trazer grande diferenciação e excelência na operação e marketing.
Compartilhamento de Recursos: a organização da fábrica de programas
deve privilegiar o compartilhamento dinâmico de recursos humanos para aten-
der a demanda.
Automação da Fábrica de software: em uma fábrica de programas pode-
mos automatizar soluções para controlar as ordens de serviços e estabelecer um
workflow.

88 UNIDADE II
O QUE É VITAL PARA COMEÇAR A FÁBRICA DE PROGRAMAS?
A fábrica de programas pode começar a usar a própria equipe da produção para

o suporte do software e em questões de engenharia de software. A camada de
gestão da operação e do projeto devem ter um nível de automação, que imple-
menta controles de demanda, rastreamento (tracking) das ordens de serviço e
controle de recursos usados pela fábrica de programas.
Gestão Gestão de Recursos
Segurança
Financeira Desempenho Humanos

Gestão da Planejamento Planejamento e Contro-
Demanda e Aceitação le da Produção Gestão da Qualidade e
Recebimento e Revisão Controle de Recursos Produtividade
Liberação Conjunta e Custos

Controle de Controle de Controle de Controle de
Prazos Qualidade Mudanças Requisitos
Homologação da Ordem de Serviço

Análise da Ordem Planejamento Preparação
Construção
de Serviço de Testes Teste
Testes de Atendimento
Unitário à Ajustes
Processo de Suporte
Serviços de Serviços de
Suporte de Suporte
Software Administrativo
Figura 7 - Começo da Fábrica de Programas


89
Escopo e Complexidade dos Componentes da Fábrica de software

A complexidade e a profundidade dos componentes da Fábrica de software
variam conforme seu escopo. Por exemplo, o controle de requisitos de um
escopo de Fábrica de Projetos é bem mais complexo do que o de um esco-
po de uma Fábrica de Programas. Há alguns casos em que determinados
processos aparecem no escopo de Projetos e não aparecem no escopo de
Programas. Para a aplicação dos componentes do modelo genérico, é im-
portante levar em consideração a complexidade de processo.

Fonte: Fernandes e Teixeira (2011).
O QUE PODE SER TERCEIRIZADO PELA FÁBRICA DE

PROGRAMAS?
Algumas atividades podem ser terceirizadas para manter o custo da fábrica de

projetos sob controle e em um patamar competitivo, como:
■■ Auditorias de compliance;
■■ Auditorias nos sistemas de qualidade;
■■ Suporte em engenharia de software;
■■ Suporte para a elaboração dos planejamentos de tecnologia, estratégico
e dos riscos;
■■ Serviços de suporte em infraestrutura.

90 UNIDADE II
Prezado(a) aluno(a), chegamos ao final de mais uma unidade. Tivemos a chance

de conhecer, ao longo desta unidade, uma visão geral da fábrica de software a
partir de um modelo genérico com componentes que atendam a todos os mode-
los de fábrica de software.
Aprendemos que uma fábrica de software pode se dividir em modelos de
fábricas que variam conforme a sua complexidade e a profundidade dos com-
ponentes que variam conforme o seu escopo.
Os modelos de fábrica de software são: Fábrica Orientada a Processos, Fábrica
Orientada a Produtos, Fábrica de Projetos e Fábrica de Programas.
Aprendemos que em uma Fábrica Orientada a Processos, para um funciona-
mento perfeito das atividades da fábrica de software, é importante que se utilize
um processo de desenvolvimento em que as tarefas e os artefatos gerados este-
jam bem definidos.
Vimos que, em uma Fábrica Orientada a Produtos, o desenvolvimento
funciona em torno dos produtos de software, que são desenvolvidos por ela.
Aprendemos também como ela concilia a rotina de manutenção de seus produ-
tos às demandas geradas por diferentes projetos, e como estes resultam em novas
funcionalidades para o produto que está sendo produzido na fábrica.
Depois, aprendemos que, em uma Fábrica de Projetos, temos em funciona-
mento diversos projetos paralelos, todos com começo, meio e fim planejados.
Estes projetos podem ser independentes ou projetos que reutilizem componen-
tes entre si.
E, ao chegar ao fim da unidade, aprendemos sobre a Fábrica de Programas.
Nesta fábrica codificamos e testamos os softwares que são desenvolvidos por ela,
considerando os requisitos e níveis de serviços levantados junto ao cliente, além
das especificações de padrões de programas, critérios de qualidade e tempo de
entrega acordados no contrato.
Na próxima unidade, com o conhecimento que já adquirimos sobre os
modelos de Fábrica de software, vamos nos aprofundar mais em outros mode-
los de fábrica de software. Preparado(a)? Então vamos em frente! Bons estudos!

91
1. Marque com V para a afirmativa verdadeira e com F para a afirmativa falsa, sobre
Fábrica de software baseado em Produtos:
( ) O desenvolvimento funciona em torno dos produtos de software desen-
volvidos.
( ) A fábrica de software concilia a rotina de manutenção de seus produtos,
com as demandas geradas por diferentes projetos, que resultam no surgi-
mento ou na evolução de funcionalidades no produto.
( ) O produto não é sempre mantido dentro da fábrica, podendo ser comer-
cializado ou vendido para os clientes dos projetos.
Assinale a opção com a sequência correta.
a) V, F, V.
b) F, V, V.
c) V, V, F.
d) F, V, F.
e) F, F, F.
2. Na fábrica de software baseada em processos, os processos de software são re-
presentados por meio de modelos que são organizados em visões. Essas visões
são abstrações de processos, definidas de acordo com os objetivos e requisitos
dos processos. Com base nestas informações, assinale a alternativa correta
sobre essas visões.
I) A Visão Funcional contém elementos do processo que estão sendo realizados
e seus fluxos de produtos.
II) A Visão Organizacional representa onde e quem realiza os elementos do pro-
cesso.
III) A Visão Comportamental representa o tempo gasto na realização dos ele-
mentos do processo.
IV) A Visão Informacional contém as informações das representações dos com-
ponentes implementados pelos elementos do projeto.
V) As visões de processos podem ser estabelecidas em função dos seus produ-
tos. As visões de atividades e de produtos representam os aspectos dinâmicos
do artefato. As visões de recursos humanos são relacionados aos aspectos di-
nâmicos do processo.
92

c) Somente as afirmativas I, III e V estão corretas.
d) Somente a afirmativa V está correta.
3. Um processo de desenvolvimento de software é um conjunto de atividades que
são necessárias para transformar os requisitos do cliente em software e, confor-
me Borsoi (2008), são organizadas de maneira a alcançar objetivos relacionados
ao ciclo de vida de software. Existem diferenças entre um processo de desen-
volvimento de software e um processo de manufatura? Quais as diferenças?
4. Podemos terceirizar vários componentes nos modelos de Fábrica de software.
Pensando nisso, identifique o que pode ser terceirizado pela Fábrica de Pro-
jetos e o que pode ser terceirizado pela Fábrica de Programas.
5. Quando pensamos na estruturação de uma fábrica de software, devemos ana-
lisar que o ciclo de vida do software em desenvolvimento geralmente possuirá
algumas fases como base, que são: planejamento, especificação de requisitos,
análise e projeto de requisitos, construção, implantação e transição. Com base
nessas informações, descreva como essas fases devem ser tratadas nas Fá-
bricas de software Orientadas a Produto.
93
Implementação de um Processo de software

Mudar ou implantar um processo de desenvolvimento em uma fábrica de software pode
ser uma tarefa difícil de realizar e, muitas vezes, leva-se tempo para ver seus resultados.
É diferente de se adotar uma nova ferramenta de desenvolvimento, já que basta insta-
lá-la, ler o manual do usuário, seguir as instruções de um tutorial e talvez fazer um curso
sobre ela. Pode-se levar algumas horas ou dias para fazer isso. Porém, mudar o processo
de desenvolvimento de software de uma empresa afeta a maneira como os indivíduos
trabalham, como eles veem, e dão valor ao resultado de seu esforço. Portanto, essa mu-
dança não acontece da noite para o dia, por isso ela deve ser cuidadosamente planejada
e gerenciada. Uma abordagem de adoção gradual do processo de desenvolvimento e
ferramentas de apoio, em que cada passo seja planejado, executado e avaliado com
critério, dá a sensação de está se fazendo a implementação da maneira mais adequada.
Falando sob o aspecto da engenharia de processo, implementar um novo processo em
uma empresa de desenvolvimento de software é um projeto por si só e que, por sua vez,
pode ser descrito em quatro passos distintos.
Os passos para implementar processo em uma empresa são:
Avaliar a empresa de desenvolvimento: o intuito é coletar informações das pessoas cha-
ve internas ou externas à empresa, para obter uma lista abrangente dos problemas atu-
almente encontrados, entender como essas pessoas veem os problemas e os priorizam.
Planejar a implementação: nesta fase, passamos a planejar a forma como ela vai se mo-
ver do seu estado atual para aonde se quer chegar. Para isto, faz-se necessário uma aná-
lise dos objetivos a serem alcançados; identificar, analisar e priorizar os riscos inerentes à
implantação do processo; usar um projeto-piloto para avaliação inicial; estabelecer um
plano de treinamento; alocar mentores como disseminadores do conhecimento.
Executar a implementação: esta fase significa executar os projetos de software esco-
lhidos para dotar o processo e as ferramentas. Do ponto de vista organizacional, isso
significa: monitorar os projetos de desenvolvimento de software; gerenciar a adoção de
processo nos projetos; monitorar a criação e uso de um ambiente de desenvolvimento
organizacional;
Avaliar o esforço da implementação: após o processo ter sido implementado no projeto
piloto ou nos demais projetos, precisa-se validar os resultados contra o plano proposto
no passo “Planejar a implementação”.
Em uma organização, diferentes processos podem coexistir, adequados a diferentes pro-
jetos. Para organizar e disciplinar o desenvolvimento de software é importante deter-
minar as atividades fundamentais, que deverão estar presentes em qualquer processo
definido.
94
A definição de um processo padrão estabelece uma estrutura comum a ser utilizada

pela organização nos seus projetos de software e constitui a base para a definição de to-
dos os processos [...]. Dessa forma, estabelece-se um processo básico que servirá como
ponto de partida para a posterior definição dos processos de software, adequados às
diferentes características de cada projeto, permitindo economia de tempo e esforço na
definição de novos processos. A definição do processo padrão pode ser realizada tendo
como base alguma norma de qualidade de processo de software e as características do
desenvolvimento de software na organização. A definição poderá considerar um dos
modelos de maturidade atualmente utilizados.
Tendo em vista que tipos de software diferentes possuem características distintas e re-
querem diferentes abordagens de desenvolvimento, o processo de software padrão da
organização deverá ser adaptado (especializado) considerando-se as características re-
lacionadas ao tipo de software (por exemplo, sistemas de informação) e ao paradigma
de desenvolvimento utilizado (por exemplo, orientação a objetos).
A instanciação para projetos específicos consiste na adaptação de um processo especia-
lizado a um projeto, considerando-se as suas peculiaridades. Nesta etapa, são definidos
o modelo de ciclo de vida, os métodos e as ferramentas que serão utilizadas no projeto,
os recursos humanos e seus responsabilidades ao longo do processo e os artefatos (pro-
dutos) consumidos e gerados. O conceito de fábrica de software está baseado na ideia
de prover uma linha de produção de soluções que atendam às necessidades específicas
de cada cliente. Isto se dá por meio da formalização de todas as atividades e seus pro-
dutos, trabalhando em forma de linha de produção, com etapas e tarefas bem definidas
para cada tipo de profissional, indo das tarefas básicas da linha de produção até rotinas
de controle de qualidade. Assim, com a alta especialização dos profissionais, cada um
garante a produtividade da etapa de produção em que está engajado e a qualidade do
artefato produzido para a etapa seguinte. Para o perfeito funcionamento das atividades
de uma fábrica de software é fundamental a adoção de um processo de desenvolvimen-
to que define as tarefas, os produtos e os responsáveis pelas etapas do ciclo de vida do
software.
Fonte: Rocha, Oliveira e Vasconcelos (2004)..
Fábrica de software – Implantação e Gestão de

Operações
Aguinaldo Aragon Fernandes, Descartes de Souza Teixeira
Editora: Atlas
Sinopse: esse livro ensina como projetar, implantar e contratar
uma fábrica de software, bem como estruturar uma plataforma de
offshore de desenvolvimento de software. Trata-se de uma obra de
referência para todos os que queiram entender melhor os aspectos
que contornam uma operação de desenvolvimento de software em
larga escala. A experiência vivida pelos autores e o conhecimento
que trazem sobre tecnologia da informação representam
inestimáveis fontes de informação para toda a comunidade
brasileira da área.
Por que contratar uma fábrica de software ágil

O artigo fala das principais vantagens de contratar uma fábrica de software ágil, podendo
concentrar suas energias em suas atividades prioritárias e, ainda assim, contar com programas
que apoiem suas operações ou negócios. Para saber mais, acesse o link:
<http://www.informant.com.br/blog/2013/11/19/por-que-contratar-uma-fabrica-de-software-agil/>.
Fábrica de software é a chave para o sucesso nos negócios

O artigo fala que o sucesso dos negócios na área é com Fábricas de software. O processo de
desenvolvimento e entrega de software deve ser transformado para atingir os objetivos de
qualquer operação de produção atual e que a entrega contínua e a alta qualidade da experiência
digital dos clientes são a base do sucesso de marcas e dos negócios.
Para continuar a leitura, acesse o link:
<http://www.executivosfinanceiros.com.br/especiais/artigo/item/5100-f%C3%A1brica-de-
software-%C3%A9-a-chave-para-o-sucesso-nos-neg%C3%B3cios.html>.
Material Complementar
REFERÊNCIAS
BEZERRA Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio de

Janeiro: Elsevier, 2007.
BORSOI, Beatriz Terezinha. Arquitetura de Processo Aplicada na Integração de
Fábricas de software. São Paulo: USP, 2008.
FERNANDES, Aguinaldo Aragon; TEIXEIRA, Descartes de Souza. Fábrica de softwa-
GIMENES, Itana Maria de Sousa; HUZITA, Elisa Hatsue M. Desenvolvimento Basea-
do em Componentes: Conceitos e Técnicas. Rio de Janeiro: Editora Ciência Moder-
na, 2005.
NOMURA, Luzia. Definição e Estabelecimento de Processos de Fábrica de sof-
tware em uma organização de TI do Setor Público. São Paulo: Escola Politécnica
da Universidade de São Paulo, 2008.
OLIVEIRA, Karine Coelho de Amorim. Um processo de Gerência de Configuração
baseado no nível 2 do CMMI estagiado para Fábricas de software Orientadas a
Produto. Recife: Universidade Federal de Pernambuco, 2007.
PRESSMAN, Roger; MAXIM, Bruce R. Engenharia de software: uma abordagem pro-
fissional. 8. ed. Porto Alegre: AMGH, 2016.
TENÓRIO, Fernando Guilherme; VALLE, Rogério. Fábrica de software. Rio de Janei-
XAVIER, Cristina Deorsola. Fábrica de software: até que ponto fordista? Rio de Ja-
neiro: Fundação Getúlio Vargas, 2008.
ROCHA, Thayssa Águila da; OLIVEIRA, Sandro Ronaldo Bezerra; VASCONCELOS, Ale-
xandre Marcos Lins de. Adequação de Processos para Fábricas de Software. VI
Simpósio Internacional de Melhoria de Processos de Software. São Paulo, 2004.
97
GABARITO
1. Alternativa C.
2. Alternativa A
3. As diferenças entre um processo de desenvolvimento de software e um proces-
so de manufatura são:
O produto de software é mais complexo do que o produto manufaturado. No
mercado não temos muitos profissionais com conhecimento e experiência para
avaliar e calibrar um processo de desenvolvimento de software. O custo de re-
produzir o software leva a descobertas tardias de problemas. Tangibilidade fica
a dever aos produtos manufaturados. O processo de trabalho é imaterial e não
material, e o cliente não consegue visualizar e externalizar com clareza suas ne-
cessidades.
4. Em uma Fábrica de Projetos podemos terceirizar as seguintes atividades: execu-
ção de treinamentos, auditorias nos sistemas de qualidade, serviços de suporte
em infraestruturas, testes de alguns sistemas específicos e serviços de suporte
administrativos. Já em uma Fábrica de Programas, as atividades que podemos
terceirizar são: auditorias de compliance, auditorias nos sistemas de qualidade,
suporte em engenharia de software, suporte para a elaboração dos planeja-
mentos de tecnologia, estratégico e dos riscos e serviços de suporte em infra-
estrutura.
5. Essas fases na Fábrica de software Orientada a Produtos deverão tratar o desen-
volvimento de novas funcionalidades para o produto e também controlar as
manutenções evolutiva ou corretiva. Isso significa que na fase de planejamento,
por exemplo, devem ser considerados os projetos de novos produtos em de-
senvolvimento, como também os pedidos de mudanças para o produto atual.
OUTROS MODELOS DE
III
UNIDADE
FÁBRICA DE SOFTWARE
■■ Apresentar os principais conceitos sobre a linha de produto de
software.
■■ Conhecer o funcionamento de uma fábrica de testes.
■■ Entender como funciona a estrutura organizacional de uma fábrica
de componentes.
■■ Compreender o funcionamento e a estrutura organizacional de um
modelo de outsourcing de sistemas.
Plano de Estudo
■■ Linha de produtos de software
■■ Fábrica de Testes de software
■■ Fábrica de Componentes
■■ Modelo de Outsourcing de Sistemas
101
INTRODUÇÃO
Na unidade anterior, falamos sobre como a estrutura organizacional de uma

fábrica de software pode se dividir em modelos de fábricas que variam conforme
a sua complexidade e a profundidade dos componentes que variam conforme
o seu escopo. Estudamos os modelos de Fábrica de Software principais e, nesta
unidade, vamos seguir conhecendo os outros modelos de Fábrica de Software,
como: Linha de Produto de Software, Fábrica de Testes de Software, Fábrica de
Componentes e o Modelo de Outsourcing de Sistemas.
Vamos iniciar falando sobre Linha de Produto de Software, suas principais

características e abordagens e os benefícios que o seu uso traz na qualidade dos
produtos desenvolvidos pela empresa.
A Fábrica de Testes de Software é uma das formas das empresas buscarem
a melhoria na qualidade do software por elas produzido, pois um dos objetivos
da fábrica de testes é medir e avaliar a qualidade dos sistemas que estão sendo
construídos, modificados ou adaptados pelas diversas Fábricas de Software, ou
por empresas desenvolvedoras de software.
Vamos estudar a Fábrica de Componentes, seus conceitos e benefícios, prin-
cipalmente com relação à velocidade da construção de softwares inteiros e à
qualidade associada a eles, pois os componentes reutilizados já foram testados
e, podemos dizer, isentos de defeitos. Vamos conhecer também outro benefício
que é a fábrica de componentes poder fazer uso de componentes que já estão
disponíveis no mercado, além de saber como eles podem ser usados para a gera-
ção do produto de software da empresa.
E, por fim, vamos conhecer o Modelo de Outsourcing de Sistemas, seus con-
ceitos e seus usos. Vamos ver que ele é definido como o processo em que uma
organização contrata outra para desempenhar determinada função.
Preparado(a) para conhecer os outros modelos de Fábrica de Software?
Então, vamos seguir em frente. Boa leitura e bons estudos!
Introdução
102 UNIDADE III
LINHA DE PRODUTOS DE SOFTWARE
Linha de Produtos de
Software (Software Product
Line) é um conjunto ou
grupo de softwares ou,
ainda, uma família de sis-
temas que compartilham
características ou espe-
cificações comuns que
satisfazem as estratégias
de mercado, um domínio
de aplicação ou missão
(Figura 1), ou seja, são sof-
twares similares, ao invés
de um único software indi-
vidual (CÂMARA, 2011).
Domínio Aplicação/
ma
Estratégia de Mercado
tence
Per É satisfeito por
Compartilham uma
Arquitetura
Produtos
Con
s tru Usada para estrutura
ído
s po
r
Componentes
Figura 1 - Linha de Produtos de Software

Fonte: adaptada de Nunes (2013, p. 08).
Conforme Fernandes e Teixeira (2011, p. 97), “linha de produto é um novo e

emergente paradigma para o desenvolvimento de software”. A principal carac-
terística é o fato de serem desenvolvidos a partir de um conjunto de artefatos,

103
reutilizando componentes, especificações de requisitos, casos de teste e outros,

que podem ser utilizados para o desenvolvimento de novas aplicações que pos-
suem um mesmo domínio (FERREIRA, 2012).
Uso de uma de um conjunto

base comum para de produtos
de assets produção relacionados
Plano de Definição de
Arquitetura
Produção Escopo
Figura 2 - Linha de Produtos de Software

Fonte: adaptada de Nunes (2013, p. 09).
Nesse sentido, segundo Viccari (2009), o propósito da reutilização deter-

mina melhorias de vários aspectos em relação à produção de software em LPS.
Melhorias, como redução de tempo de entrega de produto, ganhos na produti-
vidade, aumento da satisfação com o usuário (SANTOS, 2013), alta qualidade
dos produtos, melhora na análise dos requisitos, melhora no entendimento do
domínio, melhora no controle de qualidade e confiança do cliente.
Segundo o SEI (Software Engineering Institute [2017] on-line)1, empresas
que adotam a LPS podem ter uma melhoria na produtividade em até 10 vezes,
aumento da qualidade em até 10 vezes, 60% na diminuição dos custos, 98% da
diminuição do tempo de entrega e uma capacidade de atingir novos mercados
com maior facilidade e menor tempo; assim, levando empresas a ter uma melhor
competitividade e viabilizando soluções de problemas de falta de recursos.
Sobre o desenvolvimento de um LPS, há três atividades a ser considerada,
como Engenharia de Domínio (Desenvolvimento do Núcleo de Artefatos),
Linha de produtos de software

104 UNIDADE III
Engenharia de Aplicação (Desenvolvimento do Produto) e Gerenciamento da

LPS (Figura 3).
Desenvolvimento de Linhas de Produtos
Desenvolvimento
Desenvolvimento
do Núcleo de
dos Produtos
Artefatos
Gerenciamento
Engenharia de
Engenharia de
Domínio
Aplicações
Figura 3 - As três atividades essenciais para linhas de produtos de software

Fonte: adaptada de SEI ([2017], on-line)1.
A seguir, serão descritos os conceitos de cada uma das três atividades essen-
ciais para a LPS.

105
ENGENHARIA DE DOMÍNIO
A Engenharia de Domínio ou Desenvolvimento do Núcleo de Artefatos caracteri-

za-se como um processo que visa promover o reuso por meio da implementação
de artefatos, realizando análise, projeto e implementação (requisitos, projetos,
testes etc.) (NEVES, 2014). Engloba a análise de domínio, desenvolvimento de
arquitetura e desenvolvimento de componentes reutilizáveis.
Na Engenharia de Domínio temos três aspectos que devem ser considera-
dos: a definição do contexto da linha de produto, o núcleo de artefatos e o plano
de produção. A qualidade dos artefatos criados na engenharia de domínio são

essenciais para o sucesso dos produtos gerados por uma LPS (SANTOS, 2013).
O artefato é um item reutilizável de software, que é utilizado na construção de
uma LPS, podendo ser um componente, um framework, uma arquitetura de sof-
tware ou uma documentação desses componentes ou arquitetura.
Assim, os principais objetivos da Engenharia de Domínio voltados a uma
Linha de Produto de Software são: definir o conjunto de aplicações para o qual
ela foi planejada, definir a variabilidade existente e construir os artefatos para
realizar a variabilidade desejada (SANTOS, 2013).
ENGENHARIA DE APLICAÇÃO
A Engenharia de aplicação ou Desenvolvimento do Produto é responsável pelo

desenvolvimento dos produtos da linha, construindo sistemas da família com
o reuso dos artefatos realizados na engenharia de domínio (CÂMARA, 2011).
Além disso, explora as variabilidades da linha de produto, garantindo o correto
uso, de acordo com o que cada aplicação necessita (VICCARI, 2009).
Na Engenharia de Domínio, os principais objetivos voltados à Linha de
Produto de Software são: alcançar o reúsos dos artefatos, explorar a variabili-
dade, documentar os artefatos da aplicação, vincular a variabilidade de acordo
com o que necessita e estimar as diferenças entre requisitos de aplicação e domí-
nio nos componentes e teste, verificando o impacto causado (SANTOS, 2013).

106 UNIDADE III
GERENCIAMENTO DA LPS
O Gerenciamento da LPS ou Gerenciamento de Produtos busca garantir que as

atividades realizadas estejam de acordo com o que já foi planejado e da melhor
forma possível. Nessa atividade, há o gerenciamento organizacional, tratando da
parte dos recursos organizacionais (definição de responsáveis, parceiros etc.) e
sua estrutura (recursos, ambiente etc.). Já o gerenciamento técnico supervisiona
o desenvolvimento dos artefatos e produtos, decidindo sobre o método de pro-
dução e fornecendo elementos de gerenciamento de projetos (NEVES, 2014).
Engenharia de Domínio
Análise de Arquitetura Implementação Teste de
Domínio de Domínio de Domínio Domínio
potencial reuso
Ativos Base
Análise sobre
• Plano de negócio
• Informações dos
Implemen- Testes
Produtos Requisitos Arquitetura tação Reusáveis
• Novos requisitos
Engenharia de Aplicação
Análise de Arquitetura Implementação Testes de
Produto
Produto de Produto de Produto Produto
Feedback sobre a evolução no desenvolvimento
Rastreabilidade
Fluxo de informações
Atividade de Desenvolvimento
Artefatos Reusáveis
Figura 4 - Dois ciclos de vida que separam Engenharia de Domínio e Aplicação

Fonte: adaptada de Pohl et al. (2005, p. 45).
A Figura 4 mostra como os dois ciclos de vida interagem entre si, mostrando que
tanto na Engenharia de Domínio quanto na Aplicação são realizadas atividades
de: análise (domínio e de produto), arquitetura (domínio e produto), implemen-
tação (domínio e de produto) e testes (domínio e de produto).
A vantagem de ter dois ciclos de vida que separam a Engenharia de Domínio
e de Aplicação é que há uma separação de objetivos que são usados para cons-
truir uma plataforma mais robusta e aplicações específicas em um curto espaço

107
de tempo. Para ser eficaz, a Engenharia de Domínio e de Aplicação devem rela-

cionar-se de uma maneira que uma traga benefícios para a outra.
ABORDAGENS DE CONSTRUÇÃO DE LINHA DE PRODUTOS DE

SOFTWARE
Temos três abordagens principais para a construção de LPS, que são:

Proativa Nesta abordagem, os ativos bases são construídos primeiro. Considera
todos os produtos a serem gerados previamente, fazendo-se um plane-

jamento inicial completo e criando um conjunto completo de artefatos é
desenvolvido para a LPS.
Análise do
domínio Product 1
Arquitetura
Product 2
Projeto
SPL
Product 3
Figura 5 - Abordagem Proativa

Fonte: adaptada de Nunes (2013).

108 UNIDADE III
Reativa Nesta abordagem, os ativos bases já existem e temos uma versão da LPS.
Temos uma evolução desta linha e são realizados incrementos à medida
que novos requisitos aparecem.
Product 1
React
Product 1
Iterate Product 2
Product 2
SPL Product 3
Product 3 SPL
Product 4
Figura 6 - Abordagem Reativa

Extrativa Nesta abordagem, são analisados os produtos existentes, como eles são
estruturados (variabilidades e comunalidades) para derivar uma versão
inicial da LPS.
Product 1 Product 1
Product 2 Product 2
SPL
Product 3 Product 3
Figura 7 - Abordagem Extrativa

109
“Os principais objetivos da LPS são identificar as semelhanças e gerenciar as

variações a fim de obter melhorias na qualidade, tempo e esforço de desen-
volvimento”.
(Luiz José de Brito)
VARIABILIDADES
De acordo com Ferreira (2012), um dos grandes desafios para validar uma LPS
deve-se à relação entre diferentes combinações de características (Feature) no
sistema. Em LPS uma característica consiste de um atributo ou uma funciona-
lidade que será visível ao usuário quando este utilizar o sistema.
Características (Feature) é uma funcionalidade que é comum ou variável na
LPS. As Features variáveis são as que distinguem um produto de outro na LPS.
Feature pode ser um conjunto de diagramas de casos de uso ou de classes, ou,
ainda, apenas um método, ou uma classe, ou um trecho de um método, ou função
que diferencie um produto de outro na LPS. O ponto principal é que as caracte-
rísticas dos produtos que os diferenciam de outros produtos são fundamentais
para a representação de variabilidade (MATNEI FILHO, 2015).
Quando se desenvolve uma LPS, os desenvolvedores devem decidir como
será essas combinações de características no sistema, o que irá definir a linha
de produto de software. Considerando todas as combinações de características
escolhidas para um produto, pode-se ter alguma confiança de que foi exercitada
uma ligação entre estas características, mas caso não seja, não se pode garantir
que defeitos não aparecem nestas ligações (FERREIRA, 2012).
Porém, infelizmente, desenvolvedores de LPS não conseguem validar todas
as combinações de característica possíveis em um sistema. Testes em uma LPS é
uma tarefa complexa e dispendiosa, uma vez que a variedade de produtos deri-
vados a partir da plataforma de produto é enorme.
Como garantir a cobertura de testes em LPS? Ferreira (2012) diz que para
garantir a cobertura de testes em LPS seria necessário gerar instâncias de LPS

110 UNIDADE III
para exercitar melhor todas as possíveis combinações entre as características de

um sistema.
Segundo Santos (2013), em linguagem natural, o termo variabilidade refere-
-se à capacidade ou à tendência de mudar. Podemos entender variabilidade como
sendo a parte que irá diferenciar um produto de outro. A variabilidade fornece a
flexibilidade para diferenciar e diversificar produtos quando usada em uma LPS,
fornecendo a habilidade de um artefato ser configurado, customizado, estendido
ou mudado para um determinado fim (OLIVEIRA, 2011, p. 22).
Segue alguns conceitos relacionados à variabilidade:
Variante: são instâncias em um ponto de variação, representam um objeto
de variabilidade dentro dos artefatos do domínio. Uma variante responde a ques-
tão: Como uma variabilidade ou um ponto de variação varia em uma SPL. As
diferentes possibilidades que existem para se resolver um ponto de variação são
chamadas variantes.
Ponto de variação: representação de um objeto da variabilidade, em que se
decide a escolha entre as variantes. Descrevem pontos nos quais existem dife-
renças nos sistemas finais. Um ponto de variação responde a pergunta: O que
varia em uma SPL? Por exemplo, sistemas podem ser diferentes no que diz res-
peito aos sistemas operacionais que dependem.
Um ponto de variabilidade em uma LPS é um ponto de diferenciação entre
produtos. A Figura 8, a seguir, mostra um exemplo de um ponto de variação e
as variantes que podem ser escolhidas para ele.

111
PV
Tipo de
Câmera
V V
Preto e
Colorido
Branco
Figura 8 - Ponto de variação e suas variantes

Fonte: Oliveira (2011, p. 23).
A variação é a forma como duas variáveis diferem entre si. Para saber como
ocorre essa variação, temos o mecanismo de variabilidade, que é responsável por
implementar a variabilidade. Durante a implementação de uma variabilidade, é
necessário verificar as dependências das variantes, que devem ser utilizadas para
denotar as diferentes escolhas da variante no ponto de variação (OLIVEIRA, 2011).
1 *
Variabilidade Ponto de Variação
1 1
* - Opcional
* - Obrigatória
Variante
- Inclusiva
- Exclusiva
Figura 9 - Relação entre variabilidade, variante e ponto de variação

Fonte: Aleixo (2013).
A Figura 9 ilustra a relação genérica entre variabilidade, variante e ponto de

variação. Uma variabilidade em um processo de software está relacionada com
um ou mais pontos de variação que, por sua vez, estão associados a uma ou mais
variantes. Um ponto de variação corresponde a um ponto na especificação do

112 UNIDADE III
processo de software, e pode sofrer a inserção de novos elementos relacionados

à variabilidade.
Conforme Aleixo (2013), as variantes representam os elementos do pro-
cesso e seus relacionamentos que podem ser inseridos na especificação base do
processo de software.
Tipos de Variabilidade
A variabilidade pode ser dividida em três tipos, conforme (OLIVEIRA, 2011,
p. 23):
■■ Comum: característica (funcional ou não funcional) que pode ser comum
para todos os produtos da LPS e é implementada na plataforma.
■■ Variável: característica que deve ser comum para alguns produtos, mas
não todos.
■■ Específica do produto: característica que deve ser parte de um produto.
Normalmente com especialidades não exigidas pelo domínio, mas por
clientes individuais.
Classificação das Variantes
As Classificações das variantes que serão consideradas estão associadas a um

ponto de variação, de acordo com o que segue:
■■ Mandatória: quando uma variante é obrigatória;
■■ Opcional: quando uma variante pode ser necessária ou não;
■■ Alternativa Inclusiva: quando se deve escolher uma ou mais variantes;
■■ Alternativa Exclusiva: quando somente uma das variantes é necessária;
■■ Alternativa Mutuamente Inclusiva: quando duas ou mais variantes são
sempre necessárias juntas.

113
Office
Escopo Formato
Corretor Ortográfico
Texto Open Office

Microsoft
Planilha
Apresentação PDF
Mandatory Alternative
Optional Or
Figura 10 - Exemplo da classificação das variantes da Linha de produto de software

Fonte: Wikipédia (2017, on-line)2.
Consideramos um produto como sendo a combinação de características comuns

e variáveis em LPS. Normalmente, esse produto é utilizado em testes para verifi-
car as especificações das variabilidades da LPS. A variabilidade tem um impacto
em todos os níveis de teste; e neste sentido, o engenheiro de teste responsável
pela aplicação tem de compreender os pontos de variação e variantes que foram
definidos para este produto.
O teste de variabilidade deve garantir que um sistema não tenha variantes
incluídas que não foram devidamente definidas para serem incluídas na aplicação.

114 UNIDADE III
Parte variável Teste do

Engenharia Sistema
de
Requisitos Derivação de Teste
Caso de
Teste
Projeto de
Derivação de Teste
Sistema Parte
Caso de variável
Teste
Teste de
Implementação unidade
Derivação de Teste Parte

variável
Figura 11 - Níveis de teste e sua crescente complexidade devido à variabilidade

Fonte: adaptada de Pohl et al. (2005, p. 286).
Em seu discurso sobre Teste em Linha de Produto de Software (SPLiT), Grütter

listou alguns desafios para testar a linha de produtos, entre eles: controlar o cres-
cimento de variabilidade (Figura 7).
Conforme Ferreira (2012), o teste de variabilidade e seleção de produtos
oferecem critérios de teste para cobrir uma quantidade de combinações entre
características, mas não é possível garantir que um subconjunto de característi-
cas selecionadas seja capaz de revelar todos os defeitos.

115
A qualidade dos produtos com a LPS é gradativamente alcançada com a

reutilização dos artefatos (componentes, casos de uso, diagramas de classes,
documentos de projeto) produzidos nas fases de desenvolvimento, uma vez
que os artefatos são utilizados e revisados nos diversos sistemas. Em caso
de erros (bugs), estes são corrigidos e propagados para os produtos deriva-
dos. A redução do tempo de desenvolvimento é uma das vantagens mais
esperadas. No início do desenvolvimento da plataforma, o tempo investido
é até maior que das metodologias de desenvolvimento tradicional. Entre-
tanto, tal situação é superada com reutilização dos artefatos nos sistemas
desenvolvidos com as plataformas. A facilidade na manutenção decorre do
fato de que se um artefato é modificado em virtude de uma correção ou
atualização, tal mudança deverá ser propagada para os produtos derivados.
Fonte: Brito (2013).
FÁBRICA DE TESTES DE SOFTWARE
Hoje, existe uma crescente preocupação pela necessidade de melhoria do sof-

tware, percebida pelas próprias empresas, seja por exigência do mercado ou pelos
clientes. Uma das formas das empresas melhorarem a qualidade do software por
elas produzido é por meio da implanta-
ção de fábricas de testes para produzirem
sistemas com um nível de qualidade
aceitável e em um espaço de tempo cada
vez menor (LOPES; FREITAS, 2012).
Entretanto, quando a empresa desen-
volvedora de software busca por essas
qualidades, ela percebe que é necessá-
rio investir pesado em testes de software
e que existem vários tipos de testes no
mercado para atender às suas necessida-
des, podendo ser preciso implantar mais
de um tipo ou investir em métricas de
Fábrica De Testes De Software

116 UNIDADE III
software para garantia da qualidade destes testes. Ganhando espaço na comu-

nidade de software, as métricas de teste de software vêm conquistando e sendo
de grande importância para as empresas que buscam qualidade e eficiência em
seus projetos.
A fábrica de testes é considerada uma estrutura independente com profissio-
nais capacitados e com alta especialização em processos e domínio em ferramentas
de testes de software. Segundo Lopes e Freitas (2012), um dos objetivos da fábrica
de testes é medir e avaliar a qualidade dos sistemas que estão sendo construídos,
modificados ou adaptados pelas diversas Fábricas de Software ou por empresas
desenvolvedoras de software.
Outro objetivo de uma fábrica de testes é tentar aplicar o maior volume de
testes no menor tempo possível, ou seja, tentando simular os principais cenários
da regra de negócio do cliente do sistema e tentando avaliar se o mesmo está em
conformidade com o que foi descrito nos requisitos do sistema.
Em uma fábrica de testes, podemos determinar o nível de garantia de qua-
lidade atual para cada sistema, possibilitando evoluir incrementalmente o nível
de qualidade dos sistemas que apresentarem uma maior volatilidade e um alto
risco para a empresa (LOPES; FREITAS, 2012).
Tem por objetivo aplicar
MÁXIMO MENOR
DE TESTES PRAZO
Figura 12 - Objetivo de uma Fábrica de Testes
Fonte: a autora.

117
Uma Fábrica de Testes é uma estrutura independente de profissionais com

alta especialização e capacitação em processos e ferramentas de testes de
software, com objetivo de aplicar o maior volume de testes no menor espa-
ço de tempo possível, possibilitando simular os principais cenários de negó-
cios, medindo e avaliando o comportamento do sistema em cada situação,
principalmente após serem modificados, adaptados e construídos pelas di-
versas Fábricas de Software contratadas pelos clientes.
Uma Fábrica de Testes deve estabelecer modelos e gerenciar as demandas

de testes tanto manuais quanto automatizados, identificando as transações
de negócios existentes em cada sistema, determinando seu grau de risco
financeiro e operacional, além de acionar e elaborar detalhados planos de
testes com abordagens únicas, a fim de evitar interpretações pessoais que
comprometam a confiabilidade do processo de testes, garantindo a con-
formidade das implementações, preservando as transações de negócio e
buscando conciliar agilidade dos testes com simplicidade operacional.
Fonte: Lopes e Freitas (2012).
FUNCIONAMENTO DE UMA FÁBRICA DE TESTES
A fábrica de testes deve tentar gerenciar as demandas de testes manuais e auto-

matizados estabelecendo modelos, técnicas, estratégias e metodologias de testes,
independente da tecnologia empregada.
Uma fábrica de testes deve ser capaz de identificar todas as transações refe-
rentes às regras de negócios existentes em cada sistema e determinar o grau de
risco operacional e financeiro para as operações e também definir um deta-
lhado plano de testes para cada transação de negócio e seus cenários (LOPES;
FREITAS, 2012).
A cada solicitação de nova funcionalidade ou mudança, a fábrica de testes
deverá acionar os planos de testes para garantir que todas as novas funcionali-
dades ou modificações sejam validadas e que todas as transações de negócios
preservem seu comportamento esperado.

118 UNIDADE III
Especificação
Plano de de Casos
Execução Registro
Testes de Testes de Testes de Testes
Figura 13 - Etapas do processo da Fábrica de Testes

Fonte: a autora.
Continuamente, uma fábrica de testes deve buscar recursos e meios mais sim-
ples, mais econômicos e mais eficientes para suportar o volume de testes, sem
comprometer o cronograma ou o orçamento dos projetos, ou seja, deve buscar
conciliar a simplicidade operacional com a agilidade nos testes.
A fábrica de testes dentro de um projeto deve garantir a qualidade do sof-
tware, verificando toda a cadeia de desenvolvimento do sistema, avaliando todos
os artefatos que são produzidos e que podem vir a interferir na qualidade do sis-
tema. Ela deve estar preparada para evoluir junto com o cliente, à medida que a
empresa consiga mensurar resultados positivos e, a partir disso, decida realizar
mais investimentos no controle da qualidade sobre o processo de desenvolvimento.
Fábrica de Teste Teste

Software Unitário Integrado
Checklist de Elaboração de
Fábrica de
Checklist Casos de Casos de
Teste
Testes Teste
Inspeção de Automação de
Smoke Teste Teste Funcional
Código Fonte Teste
Figura 14 - Funcionamento de uma Fábrica de Teste

Fonte: a autora.
BENEFÍCIOS DE UMA FÁBRICA DE TESTES
Quando uma empresa investe em uma fábrica de testes, o benefício que ela pro-
cura é a Qualidade de Software como meio para minimizar os riscos dos projetos

119
de desenvolvimento, além de procurar meios para controlar a qualidade do sof-

tware que está sendo disponibilizado a seus clientes.
Pensando nisso, a fábrica de testes deve encontrar maneiras de executar o
maior número de testes possíveis no menor prazo, pois o objetivo principal de
uma fábrica de testes é garantir a qualidade do software, sem comprometer o pro-
cesso de desenvolvimento como um todo. Para isso, pode-se utilizar o recurso da
automação de testes para as transações complexas ou com muitas alterações de
regras, que podem trazer um alto risco financeiro caso ocorram falhas ou defei-
tos no processamento (LOPES; FREITAS, 2012).
A fábrica de testes poderá acompanhar continuamente o desempenho dos

fornecedores de software, procurando avaliar o nível de controle operacional
de cada um sobre o próprio processo de desenvolvimento. A fábrica de testes
deverá estar capacitada para certificar os fornecedores, seguindo um rigoroso
padrão de qualidade a ser estabelecido (número de ciclos, volume de defeitos e
reincidência de defeitos). A partir disso, passa a procurar viabilizar ações para
a prevenção de defeitos, segundo as estatísticas coletadas pelo volume de erros
detectados para cada fornecedor.
A fábrica de testes deverá fornecer estimativa e métricas precisas e inques-
tionáveis (todos os testes devem ter evidências/documentação que provem sua
execução e a presença do erro ou defeito relatado), possibilitando que a empresa
direcione os projetos considerados mais críticos para os fornecedores com maior
índice de confiabilidade.
É necessário que a fábrica de testes force uma contínua atualização de todos
os cenários de negócios, pois os casos de testes que foram criados são utilizados
para rastrear os requisitos existentes nos sistemas. Assim, os analistas de testes
procuram manter a documentação atualizada dos sistemas da empresa. A fábrica
de testes tem um impacto radical sobre os índices de produtividade, dos prazos e
custos do projeto, dos testes e da homologação, pois ela reduz os riscos de solu-
ções não padronizadas e na manutenção de sistemas legados.

120 UNIDADE III
Tabela 1 - Benefícios de uma Fábrica de Software
Fonte: adaptada de Bartie (2006, on-line)3.
A fábrica de testes deve:

■ Executar testes de software;
■ Agregar valor a toda cadeia de desenvolvimento;
■ Suportar processos de reestruturação de sistemas;
■ Garantir que as novas funcionalidades implementadas não afetem as anti-
gas já em funcionamento;
■ Compromisso com a qualidade e com os testes de software;
■ Implementar um moderno e ágil processo de teste;
■ Estabelecer um modelo de gestão para as demandas de testes (testes manu-
ais e testes automatizados);
■ Procurar documentar todos os sistemas e seus Planos de Testes;
■ Definir os critérios e indicadores de análise para os fornecedores;

121
■■ Gerenciar a análise dos resultados de testes;

■■ Desenvolver relatórios de qualidade dos sistemas testados.
A fábrica de testes deve fornecer às equipes de gerenciamento de projetos:

■■ Posicionamento real de cada projeto em andamento;
■■ Avaliação da qualidade do fornecimento dos softwares (entregues pelas
Fábricas de Software);
■■ Vincular as entregas aos pagamentos a fornecedores.
Temos fábrica de testes orientada a processos e orientada a serviços.

■■ Fábrica de Testes Orientada a Processos: orientada por um processo de
testes de software moderno, em que é documentado todo o processo para
garantir a alta padronização nos projetos. Faz uso de ferramentas para
uma alta produtividade que acompanham a solução e ajudam na agilidade
e no controle da implementação do processo em ambiente empresarial.
■■ Fábrica de Testes Orientada a Serviços: para haver uma garantia de que
o modelo de Fábrica de Testes seja utilizado pelas empresas é necessário
que os profissionais especializados em testes tenham focos diferencia-
dos, visando a execução dos projetos de testes e a evolução do processo
como um todo. A divisão desses profissionais, em grupos com atuações
diferenciadas possibilita maior eficiência, agilidade e melhorias na qua-
lidade dos projetos de testes de software.

122 UNIDADE III
Gerenciamento da Execução
dos Testes
Líder de Analista de Executor de
Testes Testes Testes
Gerenciamento dos Serviços
de Testes
Gerente de Coordenação Auditor de
Serviços de Teste Testes
Gerenciamento de Inovação
dos Testes
Engenheiro Arquiteto de Automatizador
de Testes Testes de Testes
Figura 15 - Fábrica de Testes Orientada a Serviços

Fonte: a autora.
A Fábrica de Testes deve suportar todos os conceitos de testes de software de

forma totalmente inovadora e, com isso, conciliar o alto volume de testes, pos-
sibilitando a redução dos custos e prazos, gerando, assim, benefícios e trazendo
padronização e qualidade a todos os projetos da empresa.
Durante todo o processo de desenvolvimento, a atuação da Fábrica de Tes-

tes é efetiva a fim de garantir que cada etapa seja sistematicamente veri-
ficada, avaliando os artefatos gerados e que interferem na qualidade e no
entendimento dos projetos de desenvolvimento. Um processo de testes
bem-estruturado permite que as verificações e validações ocorram de for-
ma planejada e consistente, sem comprometer a confiabilidade do processo
de teste e o desenvolvimento, além de prover a execução de inúmeros casos
de testes no menor tempo possível, principalmente com a utilização da au-
tomação de testes em transações complexas.
Fonte: Lopes e Freitas (2012).

123
FÁBRICA DE COMPONENTES
A fábrica de componentes
tem como objetivo produzir
componentes hermetica-
mente fechados, que devem
ser utilizados nas unida-
des de software montadas
pela fábrica de software.
E a fábrica de componen-
tes é baseada totalmente
nos conceitos da LSP
(Software Product Line).
Para Fernandes e Teixeira,
é uma forte quebra de para-
digma porque há:
[...] uma busca pela real ma-
nufatura do software em
termos de produção “custo-
mizada” de massa, que significa produzir software com alta qualidade
e produtividade em virtude da intensa reutilização de componentes.
A fábrica dentro do presente conceito é orientada para o desenvolvi-
mento de novos softwares e evolução dos que estão em manutenção.
A Fábrica de Componentes parte da engenharia da aplicação, quando
os requisitos são estabelecidos e decide-se o que será reutilizado e de-
senvolvido de acordo com a arquitetura do software. A engenharia da
aplicação tem domínio completo da área de negócio atendida pelo sof-
tware, assim como controla o mapa de todas as arquiteturas de software
mantidas pela fábrica (FERNANDES; TEIXEIRA, 2011, p. 227).
Quando desenvolvemos um sistema baseado em componentes, estamos subdi-

vidindo-o em módulos. Esses módulos podem ser entendidos como pequenos
conjuntos de software que, combinados, permitem a construção de softwares
maiores. Uma analogia interessante é comparar os módulos com peças de um
“quebra-cabeça”. Essas peças necessitam ser combinadas para a “montagem final”.
Os componentes podem ser classificados em interno e externo. Um
Fábrica de Componentes
124 UNIDADE III
componente interno é caracterizado pelo desenvolvimento do componente na

própria empresa. Já o componente externo é aquele adquirido de outra empresa.
Definir Especificar Projetar Implementar

Problema Componentes Componentes Componentes
Figura 16 - Desenvolvimento de Componentes
Fonte: a autora.
Existem vantagens na aquisição/construção de cada tipo de componente. Por
exemplo, desenvolver um componente na própria empresa permite organizar
melhor os projetos, a partir da divisão do mesmo em vários componentes, e reu-
tilizá-lo em outros projetos.
Plano de
Produção
Arquitetura Gestão de Linha de

Software Componentes Montagem
Engenharia de Fábrica de
Aplicação Componentes
Teste
Gestão do
Produto Produção
Figura 17 - Fábrica de Componentes


125
Analisando a Figura 17, temos a arquitetura de software, a estrutura do sistema,

que compreende os componentes, as propriedades externas e os relacionamentos.
A gestão de componentes tem a responsabilidade de informar a existência dos
componentes ou não, que foram requeridos pelo sistema. A partir dessa infor-
mação, é elaborado o Plano de Produção que indica onde cada componente será
inserido na arquitetura. O Plano de Produção emite ordens para a construção
de novos componentes e a disponibilização dos componentes já construídos. Os
novos componentes que foram construídos devem ser testados e depois dispo-
nibilizados para a integração.
Segundo Fernandes e Teixeira (2011, p. 227), “uma vez que todos os compo-
nentes são integrados conforme a arquitetura do software, parte-se para o teste
do software (sistemas e de aceitação)”. Depois, o sistema pode ser liberado para
o cliente. Na Gestão do Produto, este vai ser evoluído, reiniciando o ciclo do pro-
cesso de software por meio da Engenharia de Aplicação.
Um dos benefícios desse modelo de fábrica de componentes é com relação
à velocidade da construção de softwares inteiros, qualidade associada, pois os
componentes reutilizados já foram testados e, podemos dizer, isentos de defeitos.
Outro benefício, é que a fábrica de componentes pode fazer uso de componen-
tes que já estão disponíveis no mercado e podem ser usados para a geração do
produto de software.
Fábrica de Componentes
126 UNIDADE III
Reuso de Software
Um dos principais objetivos enfatizados no contexto de uma Fábrica de
Software é o reuso de software, termo abrangente que incorpora uma sé-
rie de disciplinas inter-relacionadas, como: Gestão do Conhecimento; Aná-
lise de Domínio; Linha de Produtos de Software; Arquitetura de Software;
Desenvolvimento Baseado em Componentes (DBC); Orientação a Objetos;
padrões; frameworks e ferramentas para suporte ao reuso. Verifica-se que
existe uma confluência de áreas caminhando em direção à produção em
larga escala e automatizada de software, o que também vai de encontro ao
paradigma de Fábrica de Software.
Fonte: Nomura (2008, p. 50).
MODELO DE OUTSOURCING DE SISTEMAS
Segundo Fernandes e Teixeira (2011, p. 218), “o outsourcing de sistemas é um

processo de absorção, por parte de um terceiro, de parte ou todos os sistemas

127
aplicativos de uma organização” e com o objetivo de desenvolver novos siste-

mas e também manter os atuais.
Vimos, na Unidade I, que Outsourcing é definido como o processo em que
uma organização contrata outra para desempenhar determinada função. O
Outsourcing envolve contratos mais longos e, muitas vezes, com metas de desem-
penho. As Outsourcing podem ser divididas em: convencional e BPO (Business
Process Outsourcing). O convencional envolve a terceirização de uma atividade
específica da área de TI e o BPO pode ser definido como um contrato com uma
organização externa para que seja fornecido um processo ou função de negócio.
BPO é uma espécie de “terceirização” de todos os processos internos não

ligados diretamente aos negócios da empresa. Isto é, podemos entender que BPO
é como uma entrega de diversos procedimentos da empresa a uma especialista
em processos internos, ligados a outros departamentos variados. Ou para ficar
mais claro, é a contratação de uma empresa que vai prover serviços para a exe-
cução de tarefas específicas dentro da sua empresa.
Para Fernandes e Teixeira (2011), o Outsourcing de sistemas em geral é con-
duzido por um contrato que estabelece a forma e o prazo para a assimilação dos
sistemas, dos recursos humanos da operação, acordos de níveis de serviços, ope-
rações e interfaces da empresa com a operação terceirizada. O autor descreve
que, na realidade, um Outsourcing é uma fábrica de projetos dedicada exclusi-
vamente a um cliente:
O que diferencia o Outsourcing de sistemas de uma Fábrica de Projetos,
conforme nosso conceito, é que a operação deve ser absorvida por um
terceiro de acordo com um conjunto de critérios e regras previamente
estabelecidas. Absorver implica documentar sistemas existentes, absor-
ver sistemas e o pessoal da organização que já mantinha o sistema e
deve operar estritamente sob acordos de níveis de serviços (FERNAN-
DES; TEIXEIRA, 2011, p. 219).
REQUISITOS DA OPERAÇÃO DE OUTSOURCING
Para Outsourcing ser bem-sucedida e ter consistência, alguns fatores-chaves de

sucesso devem ser atendidos. A seguir discutiremos alguns.
Modelo de Outsourcing de Sistemas

128 UNIDADE III
■■ Um modelo de Outsourcing: para uma empresa de prestação de ser-

viços, um dos requisitos básicos para ela competir no mercado é ter
seu modelo de outsourcing de sistemas previamente planejado. Este
modelo pode se basear no modelo genérico de Fábrica de Software ou
em um modelo que seja um subset do modelo maior proposto. A Figura
18 mostra um modelo de outsourcing derivado do modelo genérico de
Fábrica de Software.
Gestão Estratégica e Tática
Gestão do
Gestão da Gestão da Gestão da
Desempenho Gestão
Capacidade Qualidade e Segurança e
e Níveis de Financeira
e Demanda Processos Continuidade
Serviços
Gestão da Infraestrutura
Gestão dos Serviços
Solicitação
Planejamento Execução dos Gestão da
de
e Aceitação Serviços Configuração
Serviços
Gestão de Atendimento
Recursos Emergencial
Gestão Operacional
Solicitações Solicitação
Atendidas Emergencial
Figura 18 - Modelo de Outsourcing de Sistemas

■■ Planejamento da Operação de Outsourcing: o planejamento de uma

operação de outsourcing geralmente é em função dos requisitos dos clien-
tes. Grande parte da operação é determinada pelo cliente, ou seja, não
é a prestadora de serviços que determina as regras do que vai ser feito,
apenas a influencia.
Conforme Fernandes e Teixeira (2011), para a elaboração do planejamento da

operação, os seguintes itens devem ser considerados:

129
-- Volume da demanda de serviços;

-- Tipo da demanda de serviços;
-- Os processos de gestão do cliente em andamento;
-- Os novos processos de gestão do cliente;
-- As metodologias de desenvolvimento de sistemas que podem ser usadas;
-- As melhorias nas metodologias do cliente que podem ser adotadas;
-- As novas metodologias de desenvolvimento que podem ser adotadas;
-- As normas e os padrões que podem ser aplicados;

-- O ambiente tecnológico que pode ser adotado;
-- Os equipamentos, os dispositivos, as ferramentas que devem ser usados;
-- A quantidade de recursos humanos que será necessário;
-- O perfil de qualificação dos recursos humanos que será contratado;
-- Os indicadores de desempenho que serão adotados;
-- O processo de teste que será adotado;
-- Os investimentos que serão necessários;
-- Os níveis de serviço que serão desenvolvidos.
Após a coleta desses dados, é feito o planejamento da operação, seguindo os mol-

des preconizados do PMBOK, por exemplo: cronogramas, orçamento, plano de
risco e de qualidade etc.
■■ Estratégia de Implantação do Outsourcing: a estratégia para implantar a ope-
ração do outsourcing deve ser bem definida e deve prever as seguintes fases:
-- Avaliação do ambiente para a coleta de informações;
-- Planejamento da implantação da operação;
-- Adaptação dos componentes da Fábrica de Software genérica ou a de
componentes;
-- Fase de transição para os novos modelos;
-- Fase de operação contínua: níveis de serviço podem ser cobrados.

130 UNIDADE III
Na Figura 19, temos um exemplo de estratégia de implantação.
Etapa de Avaliação Etapa de Planejamento

do Ambiente da Implantação
Etapa da Estruturação
dos Modelos
Etapa de Transição
Operacionais de
e Implantação
Gestão Estratégica e
Tática
Etapa de Transição
e Implantação
Figura 19 - Estratégia de Implantação do Outsourcing

■■ Implantação da Operação é um Projeto: a implantação de uma operação

dessa natureza é considerado um projeto e, assim, devemos ter: gerente,
um plano, controles de custo e prazo, cronograma, qualidade e escopo,
matrizes de responsabilidades e controles de mudança e de riscos.
■■ Desempenho da Organização é Orientado pelos Níveis de Serviços: todo
o desempenho em uma operação de outsourcing é orientado pelos níveis
de serviço. Assim, a gestão de desempenho da operação deve ser feita em
conjunto com o cliente, conforme a Figura 21. De acordo com Fernandes
e Teixeira (2011, p. 222), “essa estratégica fornece maior credibilidade à
operação e, portanto, maior longevidade do contrato”. Os indicadores de
níveis de serviço são os referentes à confiabilidade de entrega das OS e de
qualidade, ou seja, o serviço entregue na data prometida e a quantidade
de OS retornadas por problemas da qualidade. Outro indicador usado é
o tempo de atendimento às situações que são consideradas de emergên-
cia e severidade da emergência.

131
Gestão
Informações Conjunta Diretrizes
Gerenciais de Decisões de Mudanças
Desempenho
Gestão do Gestão da
Desempenho Informações de Qualidade
Desempenho
Dados das Medições

Planos de Ação
Projetos de Melhoria
Ações de Melhoria
Operação de Outsourcing
Figura 20 - Gestão Conjunta

Fonte: adaptada de Fernandes e Teixeira(2011, p. 223).
■■ A Operação de Outsourcing pode ser Distribuída: a operação de

Outsourcing, conforme a Figura 21, pode ser distribuída em vários locais
e para diversos clientes.


132 UNIDADE III
Núcleo de Núcleo de
Outsorcing Outsorcing
B C
Núcleo de Gestão das

Operações de Outsorcing
Núcleo de Gestão da
Infraestrutura
Outsorcing Outsorcing
A N
Executa os Modelos Estratégicos
e Tático e o Processo de Gestão
da Infraestrutura
Figura 21 - Distribuição do Outsourcing

ORGANIZAÇÃO DA PRODUÇÃO
A operação de outsourcing pode atender a uma variedade de clientes e simul-

taneamente, em que cada operação distribuída pode ter a sua própria gestão.
Entretanto, os processos de gestão e de controle devem ser os mesmos, assim
como as ferramentas de apoio ao desenvolvimento e à gestão. Conforme a Figura
22, veja como é a organização da produção do outsourcing.

133
Gestão das Operações Gestão da
de Outsourcing Infraestrutura
Gerência do Núcleo de Outsourcing

Planejamento e
Distribuição Homologação
Aceitação de Células de
das Ordens das Ordens
Ordens de Produção
de Serviços de Serviços
Serviços
Controle da
Qualidade
Células
Organizadas por
Negócio e por
Tecnologia
Figura 22 - Organização da Produção do Outsourcing

FATORES CRÍTICOS DE SUCESSO PARA A OPERAÇÃO DE

OUTSOURCING
Escolher a operação de outsourcing para a empresa depende de alguns fatores

críticos, como:
■■ A imagem do fornecedor junto ao mercado (integridade e histórico);
■■ Os processos operacionais e de gestão;
■■ Os resultados de operações similares (atendimento);
■■ A flexibilidade de adaptação da operação às necessidades dos clientes.

134 UNIDADE III
A maior fonte de conflitos entre empresas e fornecedores de serviços em ope-

rações de outsourcing é com relação à questão do não atendimento a acordos
de níveis de serviços ou às diversas interpretações sobre estes acordos. E para
Fernandes e Teixeira (2011):
Quando os acordos são estabelecidos, devem ser medidos de forma ob-
jetiva sem dar margens a interpretações subjetivas e qualitativas. Outra
fonte de conflito ocorre quanto a preços, pois atualmente os serviços de
desenvolvimento de sistemas são considerados commodities. A remu-
neração de um outsourcing deve levar em consideração a margem ne-
cessária para novos investimentos na melhoria da operação. Portanto,
isso deve ser negociado detidamente (FERNANDES; TEIXEIRA, 2011,
p. 225).
A seguir, alguns itens que devem ser considerados quanto à negociação contratual:
■■ Mudanças no volume da demanda obrigarão o aumento no número de
pessoas na operação;
■■ Contrato time&material para garantir o pagamento das horas extras;
■■ Pagamentos diferenciados para o caso de emergências (feriados, fins de
semana, à noite ou de madrugada);
■■ Lista do que não fará parte dos serviços outsourcing;
■■ Política de preços diferenciados para novos desenvolvimentos e
manutenções;
■■ Solicitações além das que estão no contrato deverão ter um aditivo
contratual;
■■ Repasse de custos de atualizações de documentação de sistemas (docu-
mentos são de propriedade do cliente).
Quando for pensar em outsourcing, pense que ele é muito mais do que uma simples
terceirização. Ele deve ser visto como um processo para a transformação estra-
tégica e tem como vantagens a redução de custos e o aumento da produtividade.

135
Chegamos ao final de mais uma unidade, em que conhecemos outros modelos

de Fábrica de Software, seus conceitos, os principais objetivos e os seus funcio-
namentos. Nesta unidade, estudamos sobre os modelos: Linha de Produto de
Software, Fábrica de Teste de Software, Fábrica de Componentes e sobre o Modelo
de Outsourcing de Sistemas.
Iniciamos a unidade falando sobre o modelo de Linha de Produto de Software,
que é um novo conceito e emergente paradigma para o desenvolvimento de sof-
tware. Sua principal característica é o fato de ser desenvolvido a partir de um

conjunto de artefatos, reutilizando componentes, especificações de requisitos,
casos de teste e outros, que podem ser utilizados para o desenvolvimento de
software.
Sobre a Fábrica de Testes de Software, aprendemos que ela é uma estrutura
independente de profissionais com alta especialização e capacitação em proces-
sos e ferramentas de testes de software, com objetivo de aplicar o maior volume
de testes no menor espaço de tempo possível. Outro objetivo é o de avaliar a
qualidade dos sistemas que estão sendo construídos, modificados ou adaptados
pelas diversas Fábricas de Software ou por empresas desenvolvedoras de software.
Conhecemos também a Fábrica de Componentes, que é orientada para o
desenvolvimento de novos softwares e evolução dos que estão em manutenção.
A Fábrica de Componentes parte da engenharia da aplicação, quando os requisi-
tos são estabelecidos e decide-se o que será reutilizado e desenvolvido de acordo
com a arquitetura do software.
E, por fim, estudamos sobre o Modelo de Outsourcing de Sistemas, que é
um processo de absorção, por parte de um terceiro, de parte ou todos os siste-
mas aplicativos de uma organização e seu objetivo principal é desenvolver novos
sistemas e também manter os atuais. Podemos dizer que ele é um processo em
que uma organização contrata outra para desempenhar determinada função.
Preparado(a) para mais conhecimento? Então, vamos seguir em frente. Boa
leitura e bons estudos!
136
1. Um dos modelos de Fábrica de Software que estudamos foi a Linha de Produto

de Software. A LPS é um novo e emergente paradigma para o desenvolvimento
de software. Com base nesta informação, assinale a alternativa correta com
a principal característica de uma LPS.
a) A principal característica da LPS é o fato de os produtos serem desenvolvidos
a partir de um conjunto de sistemas já em uso, reutilizando seus componen-
tes e especificações de requisitos e seus casos de teste e outros.
b) A principal característica da LPS é o fato de os produtos serem desenvolvidos
a partir de um conjunto de artefatos, reutilizando componentes, especifica-
ções de requisitos, casos de teste e outros, que podem ser reutilizados nas
aplicações que possuem domínios diferentes.
c) A principal característica da LPS é o fato de os produtos serem desenvolvidos
a partir de um conjunto de artefatos, reutilizando componentes, especifica-
ções de requisitos, casos de teste e outros, que podem ser utilizados para o
desenvolvimento de novas aplicações que possuem um mesmo domínio.
d) A principal característica da LPS é o fato de os produtos serem desenvolvidos
a partir de um conjunto de sistemas e reutilizando componentes já existen-
tes, que podem ser utilizados para o desenvolvimento de aplicações que pos-
suem um mesmo nome.
e) A principal característica da LPS é o fato de os produtos serem desenvolvidos
a partir de um conjunto de requisitos, reutilizando artefatos, especificações
de ferramentas, casos de uso e outros, que podem ser utilizados para o desen-
volvimento de novas aplicações que possuem um mesmo domínio.
2. Vimos que o propósito da reutilização determina melhorias de vários aspectos
em relação à produção de software em LPS. Essas melhorias ajudam na redução
de tempo de entrega de produto, na produtividade e no aumento da satisfação
do usuário. O desenvolvimento de um LPS possui três atividades que devem ser
consideradas. Assinale a alternativa correta sobre as três atividades:
a) Engenharia de Domínio, Desenvolvimento do Núcleo de Requisitos, Enge-
nharia de Aplicação.
b) Desenvolvimento do Produto, Gerenciamento da Aplicação e Engenharia de
Domínio.
c) Engenharia de Domínio, Engenharia de Aplicação e Desenvolvimento do Ar-
tefato.
d) Engenharia de Domínio, Engenharia de Aplicação e Gerenciamento da LPS.
e) Engenharia de Requisito, Engenharia de Aplicação e Gerenciamento da LPS.
137
3. O modelo de Linha de Produtos de Software (Software Product Line) é um con-

junto ou grupo de softwares ou, ainda, uma família de sistemas que compar-
tilham características ou especificações comuns, que satisfazem estratégias de
mercado ou a um domínio de aplicação, ou a uma missão. Cite e explique as
três abordagens principais para a construção de LPS.
4. A fábrica de testes deve fornecer estimativas e métricas precisas e inquestioná-
veis (todos os testes devem ter evidências/documentação que provem sua exe-
cução e a presença do erro ou defeito relatado), possibilitando que a empresa
direcione os projetos considerados mais críticos para os fornecedores com maior
índice de confiabilidade. Com base nisso, assinale a alternativa correta:
I. A Fábrica de Testes deve executar testes de software e agregar valor em toda
a cadeia de desenvolvimento.
II. A Fábrica de Testes deve suportar processos de reestruturação de sistemas e
garantir que as novas funcionalidades implementadas não afetem as antigas
já em funcionamento.
III. A Fábrica de Testes deve ter compromisso com a qualidade e com os testes de
software e implementar um moderno e ágil processo de Teste.
IV. A Fábrica de Testes deve estabelecer um modelo de gestão para as demandas
de testes (testes manuais e testes automatizados) e procurar documentar to-
dos os sistemas e seus Planos de Testes.
V. A Fábrica de Testes deve definir os critérios e indicadores de análise para os
fornecedores e gerenciar a análise dos resultados de testes.
a) Somente as afirmativas I, II, III estão corretas.
b) Somente as afirmativas I, II, IV estão corretas.
c) Somente as afirmativas I, III, IV estão corretas.
138
5. A estratégia __________________________________, usada para implantar

a operação do outsourcing, deve ser bem-definida e deve prever as seguintes
fases: ____________________ para a coleta de informações, planejamento da
implantação da operação, adaptação dos componentes da Fábrica de Softwa-
re genérica ou a de componentes, a fase de ___________________ e a fase de
operação contínua: níveis de serviço podem ser cobrados. Complete as lacunas
com o nome dos fatores:
a) Do Planejamento da Operação de Outsourcing, avaliação do ambiente, transi-
ção para os novos modelos.
b) De Implantação da Operação do Outsourcing, avaliação do ambiente, transi-
c) De Implantação do Outsourcing, avaliação do ambiente, transição para os no-
vos modelos.
d) De Operação do Outsourcing, avaliação do ambiente, transição para os novos
modelos.
e) Da Organização da Produção do Outsourcing, avaliação do ambiente, transi-
139
Terceirização no Desenvolvimento de Software

Com o aumento da necessidade de serviços especializados, as empresas estão necessi-
tando cada vez mais de recursos humanos especializados, capazes de atender aos mais
diversos requisitos. Muitas vezes, o investimento que deve ser feito para a especialização
dos recursos internos é muito cara e, em certas situações, não justifica esse investimen-
to. Uma alternativa que está presente cada vez mais nas empresas é o uso de recursos
humanos terceirizados. Dessa forma, é possível utilizar recursos especializados sem a ne-
cessidade de alto investimento. Mesmo para empresas que possuem recursos especiali-
zados para o desenvolvimento de softwares, em certos momentos existe a necessidade
de se terceirizar esse desenvolvimento. É importante decidir em qual momento ou tipo
de software será ou não terceirizado, levando em conta sua abrangência e importância.
Vantagens e Desvantagens na Terceirização de TI

Segundo Faria (2008), uma das vantagens percebidas nas soluções implantadas pelos
provedores de terceirização de TI está focada no suporte técnico especializado, visto
que as empresas de terceirização possuem um cuidado especial com a proteção das
informações de base de dados de seus clientes. As empresas buscam maior qualidade
em suas operações, o que remete a uma busca incessante por parceiros ou empresas
de terceirização que possuem know-how extremamente especializado. Tal situação faz
com que uma grande quantidade de acordos seja fechada em diversos segmentos do
mercado, destacando-se a infraestrutura tecnológica (FARIA, 2008).
Conforme Oliveira (2000), a contratação de serviços de terceiros não é um fenômeno
novo e a novidade está justamente na mudança da estrutura organizacional e operacio-
nal das empresas. Há alguns anos atrás, quando surgiu, a terceirização era considerada
somente uma forma de redução de custos, o que também ocorre nos dias de hoje. Con-
tudo, essa redução nem sempre era materializada, assim como a qualidade e confiabi-
lidade dos serviços. Ainda de acordo com Oliveira (2000), após alguns anos, o processo
de terceirização amadureceu e passou a ser visto pelos administradores das empresas
como uma alternativa estratégica. Tal amadurecimento também ocorreu nas empresas
terceirizadas, o que fez surgir empresas especializadas e uma melhor prestação de ser-
viços e, consequentemente, uma melhora na elaboração de contratos a fim de canalizar
os esforços para que os objetivos estratégicos das empresas contratantes sejam alcan-
çados.
140
Contratos
Uma das formas de possibilitar que uma organização, ao contratar serviços de TI no mo-
delo de terceirização seja capaz de gerenciar tais contratos, é através do uso de SLA
(Acordo de Níveis de Serviços). Esses acordos especificam o desempenho baseado em
componente de hardware e em técnica. Por exemplo, esses contratos descrevem níveis
de serviço por tempo de resposta de um Help Desk ou percentual do tempo disponível
de um serviço. Esses níveis de serviços são utilizados com o intuito de estabelecer puni-
ções ou premiações nas faturas, de acordo com seu cumprimento ou não (CAVALCANTI,
2007). Segundo Torres (2008), um SLA é um contrato que define parâmetros ou suporte
técnico que o contratado deverá fornecer para seu cliente. Ali devem também ser colo-
cadas as consequências por não atingimento ou falhas apuradas no serviço.
Desenvolvimento de Softwares
O desenvolvimento de software no contexto desse trabalho é uma das partes mais im-
portantes, pois localiza todos os esforços no que diz respeito à sua terceirização. Outro
item importante que deve ser destacado é “onde este software será desenvolvido?”. Um
dos locais mais apropriados para esse desenvolvimento é em uma “Fábrica de Software”.
Segundo Aaen et al. (1997), a definição de “Fábrica de Software” acontece em um con-
texto no qual o desenvolvimento de software torna-se uma profissionalização, em que
os clientes solicitam processos de maneira mais transparente, com maior produtivida-
de e qualidade. Dessa maneira, o termo “fábrica” indica um compromisso por parte dos
prestadores de serviços, de longo prazo e com qualidade acima dos projetos individuais.
Quando uma empresa que não atua diretamente com TI necessitar de sistemas, seja
qual for, é muito interessante que a terceirização seja utilizada para o desenvolvimento
desse sistema, pois caso a mesma o desenvolvesse internamente haveria a necessidade
de contratação de pessoal especializado, gerando assim um custo adicional desnecessá-
rio. Diante disso, é possível deixar uma pergunta: “O que será feito com o pessoal contra-
tado para o desenvolvimento desse sistema após o término do desenvolvimento, uma
vez que o core business da empresa não é esse?”.
Fonte: Viotti (2013, P. 38-52).

Linha de Produto de Software

Sobre Linhas de Produto de Software e suas principais características, abordagens e ferramentas
de apoio, este artigo mostra como seu uso traz benefícios significativos na qualidade dos
produtos desenvolvidos ajudando a manter a competitividade de mercado nas organizações.
Para saber mais, acesse o link:
Disponível em: <http://www.devmedia.com.br/linha-de-produto-de-software/33894>. Acesso
em: 29 jun. 2017.
Como uma Fábrica de Testes Funciona?

Uma boa sugestão texto que descreve como uma Fábrica de Testes funciona, como gerenciar
todas as demandas de testes e estabelecer modelos que suportem tanto os testes manuais
quanto os automatizados, estabelecendo uma metodologia única de testes, independente da
tecnologia empregada. Ótimo artigo.
Para saber mais, acesse o link:
Disponível em: <https://imasters.com.br/artigo/4518/software/como-uma-fabrica-de-testes-funci
ona?trace=1519021197&source=single>.
Acesso em: 29 jun. 2017.
Como incrementar a produtividade de uma Fábrica de Testes de Software?

Texto que retrata a busca constante por aprimoramento das Fábricas de Testes de Software.
Apresenta a relação de aspectos para reflexão, sobre como incrementar a produtividade na
operação de uma Fábrica de Testes de Software. Artigo muito bom.
Quer saber mais? Acesse o link:
Disponível em: <https://pt.linkedin.com/pulse/como-incrementar-produtividade-de-uma-
f%C3%A1brica-testes-magalh%C3%A3es>.
Acesso em: 29 jun. 2017.
REFERÊNCIAS
ALEIXO, Fellipe Araújo. Uma Abordagem Anotativa para Gerência de Variabilida-

des em Linhas de Processos de Software: Concepção, Implementação e Validação.
2013. 195 f. Tese (Doutorado em Ciência da Computação) - Universidade Federal do
Rio Grande do Norte. Natal, 2013.
BRITO, Luiz José de. Análise Automática do Modelo de Features em Linha de Pro-
dutos de Software. Brasília: UnB, 2013.
CÂMARA, Heitor Mariano de Aquino. Uma Abordagem Sistemática para Imple-
mentação, Gerenciamento e Customização de Testes de Linhas de Produto de
Software. 2011. 131 f. Dissertação (Mestrado Ciência da Computação) - Universida-
de Federal do Rio Grande do Norte, Natal, 2011.
FERREIRA, Johnny Maikeo. Teste de Linha de Produto de Software Baseado em
Mutação do Diagrama de Características. Dissertação (Programa de Pós-Gradu-
ação em Informática) - Setor de Ciências Exatas, Universidade Federal do Paraná,
Curitiba, 2012.
LOPES, Mateus Bruno Teixeira; FREITAS, Cleiton Eloi de. Fábricas de Teste de Softwa-
re. Revista Científica Univiçosa, Viçosa, v. 3, n. jan. 2012.
MATNEI FILHO, Rui Ângelo. Gerando dados para o teste de mutação de linha de
produto de software com algoritmos de otimização multiobjetivo. Curitiba:
Universidade Federal do Paraná, 2015.
NEVES, Glauco Silva. Uma Abordagem Reativa de Construção de Linhas de Pro-
duto de Software Baseada em TDD e Refatoração. 2014. Dissertação (Mestrado
Ciência da Computação) - Universidade Federal de Santa Catarina, Florianópolis,
2014.
NOMURA, Luzia. Definição e Estabelecimento de Processos de Fábrica de Sof-
tware em uma organização de TI do Setor Público. São Paulo: Escola Politécnica
da Universidade de São Paulo, 2008.
NUNES, Ingrid Oliveira de. Linha de Produtos de Software – Projeto de Sistemas
de Software. Rio de Janeiro: PUC-Rio, Departamento de Informática, LES, 2013.
OLIVEIRA, Diógenes Ricardo Freitas de. Um Estudo Sobre Gerenciamento de Va-
riabilidade de Requisitos em Linha de Produtos de Software. Caruaru: Universi-
dade de Pernambuco, 2011.
POHL, Klaus; BÖCKLE, Günter; LINDEN, Frank J. van der. Software Product Line En-
gineering: Foundations, Principles and Techniques. Springer-Verlag New York,
143
REFERÊNCIAS
Inc., Secaucus, NJ, USA, 2005.

SANTOS, Alcemir Rodrigues. Método de Extração de Linha de Produtos de Sof-
tware Baseado em Testes. 2013. Dissertação (Mestrado em Ciência da Computa-
ção) - Instituto de Ciências Exatas da Universidade Federal de Minas Gerais, Belo
Horizonte, Março, 2013.
VICCARI, Leonardo Davi. Automação de Teste de Software Através de Linhas de
Produtos e Testes Baseados em Modelos. 20009. Dissertação (Mestrado em Ciên-
cia da Computação) - Pontifícia Universidade Católica do Rio Grande do Sul, 2009.
VIOTTI, Flávio. Terceirização no Desenvolvimento de Software. Fasci-Tech, Periódi-
co Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n. 7, mar./set.
2013, p. 38 - 52.
REFERÊNCIAS ON-LINE
Em: <http://www.sei.cmu.edu/productlines/frame_report/PL.essential.act.htm>.
1
Acesso em: 05 dez. 2017.

Em: <https://en.wikipedia.org/wiki/Feature_model>. Acesso em: 05 dez. 2017.
2
3
Em: <https://imasters.com.br/artigo/4632/software/o-que-caracteriza-uma-ver-
dadeira-fabrica-de-testes/?trace=1519021197&source=single>. Acesso em: 05 dez.
2017.
GABARITO
1. Alternativa C.
2. Alternativa D.
3. Proativa: os ativos bases são construídos primeiro. Considera todos os produtos
a serem gerados previamente, fazendo-se um planejamento inicial completo e
criando um conjunto completo de artefatos é desenvolvido para a LPS. Reativa:
os ativos bases já existem e temos uma versão da LPS. Temos uma evolução
desta linha e são realizados incrementos à medida que novos requisitos apa-
recem. Extrativa: são analisados os produtos existentes, como eles são estrutu-
rados (variabilidades e comunalidades) para derivar uma versão inicial da LPS.
4. Alternativa E.
5. Alternativa C.
APLICANDO OS MODELOS
IV
UNIDADE
DE FÁBRICA DE SOFTWARE
■■ Entender como Virtualizar a Fábrica de Software.
■■ Aprender como aplicar os Modelos de Fábrica de Software In-house.
■■ Entender a aplicação da Fábrica de Programas In-house.
■■ Conhecer a Fábrica de Software e os Modelos de Melhores práticas e
certificações.
■■ Entender como estruturar operações de Fábrica de Software Offshore.
■■ Conhecer os requisitos técnicos e comerciais para estruturar uma
Operação Offshore.
Plano de Estudo
■■ Virtualizando a Fábrica de Software
■■ Como Aplicar os Modelos de Fábrica de Software In-house
■■ Aplicação da Fábrica de Programas In-House
■■ Fábrica de Software e Modelos de Melhores práticas e certificações
■■ Estruturando Operações de Fábrica de Software Offshore
■■ Requisitos Técnicos e Comerciais para estruturar uma Operação
Offshore
147
INTRODUÇÃO
Olá, aluno(a)! Esta unidade tem por finalidade mostrar como aplicar os mode-
los de fábrica de software. Além de mostrar conceitos sobre Fábrica Virtual de
Software, como aplicar os Modelos de Fábrica de Software In-house e Fábrica
de Software Offshore.
Vamos iniciar falando sobre como virtualizar a Fábrica de Software. Este é um
conceito novo e totalmente exploratório, que nasceu da necessidade de baratear o
custo de uma Fábrica de Programas, que tem seu foco na plataforma distribuída.
Em seguida, vamos ver como é a aplicação da Fábrica de Programas in-house

e ver que o modelo de Fábrica de Projeto pode ser usado para o desenvolvi-
mento e a manutenção de sistemas, ou um modelo similar ao de outsourcing, e
que implantar um modelo de fábrica para o desenvolvimento e a manutenção
de sistemas em uma empresa não é considerado uma tarefa fácil.
Vamos falar também sobre a abrangência das melhores práticas e as certifica-
ções em uma Fábrica de Software, pois o mercado, tanto governamental como o
privado, tem exigido para as empresas de prestação de serviços em TI estas certifi-
cações e também para os profissionais que trabalham nestas Fábricas de Software.
Também vamos aprender como estruturar as operações de Fábrica de
Software. Os serviços Offshore de desenvolvimento de software sob a análise
da ótica econômica internacional constituem um fenômeno recente. Há pou-
cos anos, passaram a chamar a atenção de empresários e de analistas, devido a
expressivos resultados exibidos pelas fábricas de software.
Vamos apresentar os requisitos técnicos e comerciais para estruturar uma
operação Offshore e ver que o essencial para uma Fábrica de Software parece
ser as condições de qualidade e custos competitivos, mas isso não é tudo neste
mercado atraente.
bons estudos!
Introdução
148 UNIDADE IV
VIRTUALIZANDO A FÁBRICA DE SOFTWARE
Você já ouviu falar em Fábrica Virtual? Conforme Fernandes e Teixeira (2011),

é um conceito totalmente exploratório e que nasceu da necessidade de baratear
o custo de uma Fábrica de Programas, que tem seu foco na plataforma distribu-
ída. Segundo Fernandes e Teixeira, esse movimento de barateamento do custo foi
feito por algumas Fábricas de Programas brasileiras que se mudavam para locais
onde os custos de pessoal são mais baixo do que nos grandes centros, entretanto:
[...] ninguém pensou em baratear ainda mais, através do uso da mão-
-de-obra sob demanda, passando o pagamento dessa força de trabalho
a ser feito por tarefa, e o mais radical dessa proposição é que ela é inde-
pendente de onde os programadores estejam localizados (eles são vir-
tuais mesmos). Nesse conceito, não pagamos mais a ociosidade da mão
de obra, férias, fim de semana remunerado, demais obrigações traba-
lhistas e grandes instalações (FERNANDES; TEIXEIRA, 2011, p. 228).
Agora, imagine usar esses profissionais pelo mundo afora em países onde há mão
de obra de qualidade e de baixo custo. Conforme Fernandes e Teixeira (2011,
p. 228), “uma fábrica, de acordo com essa ideia, precisa ter fortíssimo apoio da
internet e resolver algumas questões jurídicas”. O canal principal de recrutamento
e de comunicação entre a fábrica e os profissionais é a internet. As questões jurí-
dicas tratam de assuntos relacionados aos profissionais contratados e como fazer
para que eles cumpram com suas obrigações e sejam pagos por isso.

149
O processo considerado mais crítico é em relação ao recrutamento de pro-

gramadores, as questões jurídicas da contratação, o PCP da fábrica, o controle
de qualidade dos programas implementados por esses programadores, o Plano
de Contingência para o caso de falhas e riscos na produção e a segurança das
informações (FERNANDES; TEIXEIRA, 2011).
O processo de recrutamento e contratação teria as seguintes caraterísticas:
■■ Divulgação por meio de profissionais especializados (verificar qual o
melhor canal de comunicação);
■■ Presença de um site em inglês, português e espanhol para atrair profis-

sionais para participar da fábrica como programador;
■■ No site deve ter um teste on-line para todo profissional que se cadastrar;
■■ Importante criar um banco de dados com os profissionais cadastrados,
com suas habilidades e linguagens de domínio;
■■ Distribuir as tarefas de acordo com os níveis de serviço.
Para o processo jurídico, as seguintes características seriam necessárias:

■■ Para profissionais no Brasil: arquivo com o contrato de prestação de ser-
viço do site da fábrica, assinar e enviá-lo à fábrica ou identificação digital
para formalização do contrato.
■■ Para profissionais de fora do Brasil: arquivo com o contrato de prestação
de serviço do site da fábrica, assinar e enviá-lo aos escritórios creden-
ciados, e o escritório da fábrica receberia os contratos e administraria as
questões legais.
■■ Os pagamentos dos profissionais seriam por remessas para contas no
Brasil e contas no exterior.
■■ Os contratos de prestação de serviço devem obedecer às legislações tra-
balhistas de cada país.
O PCP (Planejamento e Controle de Produção) da fábrica trabalharia com uma

filosofia de recursos infinitos. Isto é, as ordens de serviço serão repassadas para
os profissionais disponíveis e com habilidade para executar aquela tarefa e, sobre
isso, Fernandes e Teixeira descrevem:
Virtualizando a Fábrica de Software

150 UNIDADE IV
[...] a ordem é enviada através de uma chave ou senha que o programa-

dor vai usar para ter acesso à especificação da tarefa no site da fábrica.
Esse processo poderia ser totalmente automatizado e transmitir men-
sagens por e-mail e para telefones celulares. Caso não haja acesso ao
site pelo programador em um tempo predeterminado, é emitido para
outro programador, e assim sucessivamente. Para a produção, ele usará
um ambiente em um Internet Data Center (no Brasil é claro) com todo
o ambiente e ferramentas necessárias para realizar seu trabalho. Fica
entendido aqui que uma fábrica virtual como essa trabalha com recur-
sos tecnológicos compatíveis com o ambiente do cliente, mas fora da
casa do cliente (FERNANDES; TEIXEIRA, 2011, p. 230).
No ambiente Internet Data Center, encontramos padrões documentados em
vários idiomas e necessários para os programadores executarem suas tarefas.
Os programadores são incentivados a usarem este padrão documentado para
manter a qualidade e o desempenho controlados nos sistemas desenvolvidos.
Porém, deve ser criado um Plano de Contingência para o caso de recebimento
de um sistema com muitos defeitos e que não se tenha tempo hábil para devol-
ver ao programador para consertar.
Caso os programadores não cumprissem com o que era solicitado na tarefa
da ordem de serviço, de forma sistemática, de acordo com o prazo estabelecido
e com qualidade, são automaticamente eliminados dos recursos disponíveis para
a produção e são adicionados à lista negra de profissionais da área.
Para o controle de qualidade é usado uma base com amostras dos progra-
madores, que vão demonstrando certo padrão de qualidade, conforme vão
executando as ordens de serviço. E para os programadores iniciantes, os contro-
les são feitos programas a programas, durante um determinado período, até que
se verifique a consistência e qualidade dos trabalhos do profissional.
É necessário ter um plano de política e instrumentos de segurança para o
caso de invasões ao ambiente de relacionamento com os profissionais. A segu-
rança, nestes casos, deve ser monitorada em tempo real e a todo o momento.
Segundo Fernandes e Teixeira (2011, p. 230), “a estrutura da Fábrica Virtual
seria extremamente enxuta, operacionalmente falando”. Neste modelo, temos:
■■ Pessoal responsável pelo recebimento e análise das ordens de serviço;
■■ O PCP podendo ser totalmente automatizado;

151
■■ Pessoal responsável pelo controle de qualidade;

■■ Pessoal responsável pela segurança;
■■ Buffer de recursos.
O investimento neste modelo de fábrica é bem significativo, por ser pioneiro

nesta área. E o que é pioneiro corre mais riscos no mercado.
COMO APLICAR OS MODELOS DE FÁBRICA DE

SOFTWARE IN-HOUSE
Nas unidades anteriores, discutimos sobre vários modelos de fábrica de software

em empresas de prestação de serviços. E as empresas que fazem seu próprio
desenvolvimento de software? Será que uma empresa que tenha seu próprio
desenvolvimento pode implementar um modelo de fábrica como os que vimos
anteriormente?
Conforme Fernandes e Teixeira, sim para alguns autores e com algumas con-
siderações e particularidades, como:
Como Aplicar os Modelos de Fábrica de Software In-House

152 UNIDADE IV
[...] a primeira é que, numa empresa de prestação de serviços de desen-

volvimento e manutenção, a construção de produtos de software é sua
finalidade principal. Não é o caso de uma empresa de outro ramo. Isso
significa que, dificilmente, uma empresa vai ter todos os componen-
tes dedicados somente ao desenvolvimento do software. Entretanto,
empresas cujo produto é totalmente baseado em software e cujo mau
funcionamento pode causar grandes prejuízos para si podem implantar
um modelo mais robusto (FERNANDES; TEIXEIRA, 2011, p. 231).
O modelo de Fábrica de Projeto pode ser usado para o desenvolvimento e a

manutenção de sistemas ou um modelo similar ao de outsourcing. Implantar
um modelo de fábrica para o desenvolvimento e a manutenção de sistemas em
uma empresa não é considerado uma tarefa fácil.
Contudo, por que não é considerada uma tarefa fácil? Porque alguns usuá-
rios estão acostumados com um atendimento com regalias e, ao implantar um
modelo de fábrica, poderão perder, já que o processo de solicitação de serviços
deverá seguir um padrão disciplinado. E conforme o poder do usuário, o pro-
jeto para implantar este modelo pode sofrer bastante.
Outro caso é o relacionamento dos analistas de sistemas com alguns usuários,
que era bastante informal e, com a implantação do modelo de fábrica, passará
a ser formal e com um único canal de comunicação. Podem ocorrer pequenas
sabotagens e resistência por parte dos usuários.
Outro problema que pode ocorrer é com o tratamento das demandas con-
flitantes entre as áreas da própria empresa. Ao implantar um modelo de fábrica,
temos a fábrica interna, que geralmente sofre com as restrições de crescimento,
como, por exemplo, de contratação de pessoal para certas áreas. Sobre isso,
Fernandes e Teixeira descrevem:
É preciso criar comitês de usuários para que eles decidam sobre as
prioridades. Essas prioridades devem ser comunicadas à fábrica. As de-
mandas devem ser explicadas em termos de benefícios para o negócio,
ou seja, o próprio usuário é que vai dizer qual o benefício, de acordo
com regras claras e objetivas (FERNANDES; TEIXEIRA, 2011, p. 232).
Quando é implantado algum modelo de fábrica, a empresa fica sabendo de tudo

o que acontece, quem usa bem e quem usa mal todos os recursos de tecnolo-
gia da informação e as soluções de desenvolvimento para o negócio. E isso pode
causar alguns constrangimentos.

153
Outro caso, é que em uma empresa pouco estruturada, todo o desenvolvi-

mento e a manutenção são urgentes. Com a implantação do modelo de fábrica,
isso acaba, pois as áreas de desenvolvimento e manutenção na fábrica passam a
ser controladas para atender às prioridades de demandas e do negócio. O custo
de cada demanda passa a ser controlado e apurado.
A implantação de um modelo de fábrica, segundo Fernandes e Teixeira
(2011), requer:
■■ Liderança na administração da empresa;
■■ Estratégias para as mudanças no âmbito da empresa;

■■ Planejamento do projeto de implantação do modelo de fábrica;
■■ Ter um gerente de projetos de implantação;
■■ Envolver os usuários no projeto de implantação;
■■ Controlar o projeto de implantação;
■■ Avaliar os resultados e fazer os ajustes necessários;
■■ Evoluir continuamente com o modelo.
Na implantação de um modelo de fábrica, temos alguns pontos críticos, que

devem ser considerados:
■■ Cada área da empresa deve ter somente um canal de comunicação com
a fábrica;
■■ O usuário deve decidir sobre as prioridades, e não a fábrica;
■■ O atendimento da empresa deve se dividir em: programado e emergen-
cial (extraordinário e corretivo);
■■ O atendimento programado deve ser planejado e executado de acordo
com o plano de atendimento da fábrica;
■■ Cada ordem de serviço emitida pelo usuário deverá ser bem detalhada
(benefício e retorno para o negócio);
■■ Nenhuma demanda será executada se não for emitida uma ordem de ser-
viço padronizada e pelo canal de comunicação estabelecido;
■■ A fábrica poderá trabalhar conforme os níveis de serviço e necessidades
dos negócios.
154 UNIDADE IV
Na Figura 1, temos a apresentação dos componentes da fábrica de software para

o desenvolvimento e para a manutenção interna.

Gestão Gestão Segurança
Planejamento Conhecimento Recursos
da Mudança,
Estratégico Humanos
Gestão Tecnologias e
Processos Treinamento
Melhoria
Planejamento
Planejamento Compliance Gestão do
Tecnologia Gestão
Financeira de Riscos Desempenho
Planejamento e Gestão da Qualidade
Gestão da Demanda
Controle da Produção e Produtividade
Recebimento e Gestão de Projeto de Controle de Controle de
Liberação Problemas Implementações Recursos Custos
Planejamento Gestão da Gestão de Gestão do Atendimento
e Aceitação Configuração Subcontratos ao cliente

Controle de Controle de Controle de
Requisitos Qualidade Mudanças Homologação da
Controle de Controle de Controle de Ordem de Serviço
Prazos Custos Subcontratos

Planejamento Teste de Preparação
Análise da de Testes Aceitação Teste
Construção
OS Testes de Atendimento
Unitário e Ajustes
Processo de Suporte
Serviços de Serviços de Suporte Serviços de Serviços de
Suporte de de Engenharia de Suporte Suporte
Software Software Instraestrutura Administrativo
Figura 1 - Componentes da Fábrica de Software


155
Na figura, temos os processos que são considerados genéricos para a área de

tecnologia da informação e que não pertencem somente à fábrica de projetos
(FERNANDES; TEIXEIRA, 2011). O processo de Planejamento e controle de
Produção é um processo opcional. Os demais processos necessitam existir para
que a fábrica atinja um atendimento efetivo, conforme a demanda e com o menor
custo possível, ou seja, com pouca manutenção corretiva.
A fábrica “in house”

A produção “in house” é definida pela presença física de uma unidade de ne-
gócios do fornecedor, dentro do espaço físico do seu cliente. Desse espaço
ocupado, dentro das fronteiras do seu parceiro de empreendimento, serão
prestados os serviços ou produzidos os itens, objetos do negócio, sendo
essa uma relação de fornecimento com exclusividade. O conceito de pro-
dução “in house” pode ser aplicado tanto ao setor industrial da economia
quanto no setor de serviços. Portanto, o fornecedor ocupará o espaço in-
dustrial de seu cliente, de onde o proverá com os produtos fabricados: uma
fábrica dentro de outra. Esta expressão representa bastante bem a questão:
como é possível existir uma fábrica dentro de outra, que não pertençam
ao mesmo grupo, não são dirigidas pelas mesmas pessoas, nem tampouco
pelos mesmos princípios?
Fonte: Garfinkel (2002).

156 UNIDADE IV
APLICAÇÃO DA FÁBRICA DE PROGRAMAS IN-HOUSE
Na fábrica de programas, a questão mais importante é o padrão da especifica-

ção de programas. Segundo Fernandes e Teixeira (2011, p. 233), “geralmente,
em empresas cuja finalidade não é o desenvolvimento de software, os padrões de
especificação de programas são muito pobres”. Em algumas empresas, há profis-
sionais que fazem a análise e são os mesmos que fazem o programa ou situações
em que o analista passa uma especificação verbal ao programador, mas com a
implantação da fábrica de programas, estas situações acabam. E, neste caso, ter
uma gestão de mudanças é fundamental, juntamente com o envolvimento da
administração e do pessoal da produção. Para Fernandes e Teixeira, nestes casos:
[...] uma fábrica dentro de casa deve trabalhar com custos variáveis, ou
seja, ela não precisa ter a capacidade exata da demanda. Ela pode ter
um pouco mesmo. Quando há picos da demanda, pode transferir parte
da produção para “terceiros” credenciados. Visando à melhoria da qua-
lidade da fábrica, seus profissionais podem, em determinadas circuns-
tâncias, fazer a especificação do programa até que os analistas criem
cultura e habilidade para tal (FERNANDES; TEIXEIRA, 2011, p. 235).

157
Com isso, podemos observar que haverá mudanças nos perfis dos profissionais.
O analista agora só vai fazer análise e apenas especificar programas. E o progra-
mador vai desenvolver o código do programa. Isto é, cada um vai desempenhar
as suas funções de acordo com seus perfis (FERNANDES; TEIXEIRA, 2011).
Outro ponto importante a ser observado é que uma fábrica interna funciona
bem quando ela tem muita demanda programada para ser executada, pois ela
é orientada para trabalhar com lotes de especificações e ordens de serviço. Ela
não funciona muito bem quando temos muitas emergências a serem atendidas,
já que, muitas vezes, a emergência era para ontem e o próprio analista acaba
entrando no código e consertando, pois a fábrica tem um processo para aten-

der esta emergência, que iria demorar a ser corrigida.
Para lidar com isso, podemos usar a estratégia de ter um grupo de buffer
(uma região de memória temporária utilizada para escrita e leitura de dados)
para atender às emergências na fábrica de programas. No entanto, para usar
esta estratégia, a empresa tem que estar ciente de dados quantitativos sobre o
volume e a frequência dessas emergências, para ajustar a equipe para lidar com
estas demandas (FERNANDES; TEIXEIRA, 2011).
Quando pensamos em aplicação em ambientes ERPs, é comum, no mer-
cado, acharem que num ambiente ERP não se use modelos de fábrica de software.
Segundo Fernandes e Teixeira, é um engano, pois:
[...] há uma aderência total a esse ambiente, principalmente quanto à
implementação de novos módulos do ERP e a suas “customizações”.
Todos os ERPs disponíveis no mercado possuem sua linguagem de pro-
gramação para fazer as “customizações” e possuem sua plataforma para
fazer as parametrizações (FERNANDES; TEIXEIRA, 2011, p. 235).
Podemos ter uma fábrica de projetos que implanta novos módulos e uma fábrica
de programas que faz as customizações. Pensando nisso, o que muda em relação
aos modelos? Praticamente, nada, pois as estimativas de prazo, o esforço e custo
dá para executar de acordo com o histórico de atendimentos das customizações.
Aplicação da Fábrica de Programas In-House

158 UNIDADE IV
“A tendência normal de uma produção “In house” será a de tentar captar

mais negócios (se possível todos) do cliente que é seu hospedeiro”.
(Alexandre Garfinkel)
FÁBRICA DE SOFTWARE E MODELOS DE MELHORES

PRÁTICAS E CERTIFICAÇÕES
Neste tópico, vamos falar sobre a abrangência das melhores práticas e as certi-
ficações em uma Fábrica de Software. Conforme Fernandes e Teixeira (2011),
um dos grandes diferenciais atuais para uma Fábrica de Software é a implanta-
ção de certificações que demonstram sua capacidade adicional e sua qualidade.
O mercado, tanto governamental como o privado, tem exigido para as
empresas de prestação de serviços em TI estas certificações. Outro item que

159
está começando a ser exigido também é a certificação dos profissionais que tra-
balham nestas Fábricas de Software.
Porém, empresas cuja a finalidade não é o desenvolvimento de software, mas
que possuem uma Fábrica de Software, também começam a pensar em imple-
mentar melhores práticas, mas sem o objetivo da uma certificação. Segundo
Fernandes e Teixeira, temos que:
[...] os modelos de melhores práticas fornecem um guia seguro para
as iniciativas de melhoria da qualidade das operações de Fábricas de
Software, assim como é um elemento de marketing também. Lembra-
mos que o marketing é decorrente e não pode, jamais, ser o objetivo

principal da empreitada de melhoria das operações de software (FER-
No mercado, os principais modelos de melhoria práticas e certificações são rela-

cionados às organizações e às instituições profissionais e sem fins lucrativos,
fornecedores de softwares, hardware e de rede de comunicação.
O Quadro 1 descreve as principais certificações existentes no mercado.
Quadro 1 - Certificações de Operações e Profissionais de Tecnologia da Informação.
CERTIFICAÇÕES QUEM CERTIFICA RESUMO DE CERTIFICAÇÕES

SW-CMM Empresa (Transi- Avalia a capacidade do processo de sof-
tion Partner do tware da empresa em gerar produtos com
SEI) qualidade.
CMMI Empresa (Tran- Avalia a capacidade do processo de desen-
sition Partner do volvimento e manutenção de produtos de
SEI) software da empresa; é uma evolução dos
demais modelos CMM.
ISO 9001:2000 Empresa Certifica a empresa nos requerimentos do
sistema de gestão de qualidade preco-
nizado pela norma que abrange todo o
processo de desenvolvimento de produtos,
produção, gestão dos processos e melhoria
contínua.
BS7799 ou ISO Empresa Certifica a empresa quanto à segurança da
informação.
Microsoft Solu- Empresa Certificação fornecida pela Microsoft para
tion Provider empresas que demostrarem capacidade
no desenvolvimento de soluções, usando
produtos da Microsoft.
Fábrica de Software e Modelos de Melhores Práticas e Certificações

160 UNIDADE IV

PMP Profissional Certifica o profissional como Project mana-
gement professional pelo Project Manage-
ment Institute.
PRINCE2 Profissional Certifica o profissional pela metodologia
de gerenciamento de projetos PRINCE2,
preconizada pelo Office for Government
Commerce do governo inglês. Certifica em
dois níveis: foundation e practitioner.
CISA Profissional Certifica o profissional como Certified
Information System Auditor; certificado for-
necido pelo Information System Audit and
Control Association & Foundation (Isaca).
CISM Profissional Certifica o profissional como Certified
Information Security Office, também da
Isaca.
Rational Univer- Profissionais A Rational (empresa da IBM) dedica-se
sity de parceiros da ao fornecimento de ferramentas para o
Rational desenvolvimento de software e metodo-
logias. Os certificados são oferecidos tanto
para consultores como para instrutores nas
seguintes áreas: projeto e implementação,
gestão de mudanças e configuração, ges-
tão de requerimentos, processo, teste de
desempenho e teste funcional.
Mercury Interac- Profissionais Mercury Interactive é uma empresa forne-
tive cedora de produtos para teste de softwa-
re e outras em gestão de TI. Possui dois
certificados: O Certified Product Consultant
(CPC) e o Certified Instructor.
Oracle Profissionais A Oracle oferece uma série de certificações
para seus produtos, principalmente no que
tange à administração de banco de dados,
administrador de servidores de aplicações
Web e para o desenvolvimento de aplica-
ções.

161

Sun Microsys- Profissionais A Sun oferece uma série de certificações
tems para seus produtos nas linhas de armaze-
namento, sistema operacional, tecnologias,
programadores, desenvolvedor e arquite-
tos.
IBM Profissionais A IBM oferece várias certificações em seus
produtos nas linhas de CICS, e-business,
DBS, WebSphere, Linux, Lótus, Tivoli e XML.
Linux Professio- Profissional Oferece um certificado de especialista em
nal Institute Linux, considerando três níveis de habilida-
de; o profissional pode certificar-se no nível

1, 2 ou 3.
Microsoft Profissional A Microsoft oferece uma gama de certifica-
dos. Os principais são: Microsoft Certified
Systems Administrators (MCSA), Microsoft
Certified Systems Engineers (MCSE), Mi-
crosoft Certified Database Administrators
(MCDBA).
American Socie- Profissional A ASQ fornece um conjunto de certifica-
ty for Quality ções para profissionais que atuam na área
de gestão da qualidade. Entretanto possui
certificações relativas à área de tecnologia
da informação. Uma delas é o Certified
Software Quality Engineer (CSQE). Caso a
operação tenha um sistema da qualidade
em uso baseado na ISO, há o certificado
Certified Quality Auditor, além de outros.
Temos também os tipos de certificações que são requeridos conforme o tipo de

mercado em que a fábrica de software deseja atuar (Quadro 2). No quadro, a cate-
goria in-house, conforme Fernandes e Teixeira (2011, p. 240), “significa a adoção
das certificações por empresas cuja finalidade não é desenvolver software, mas
desenvolvê-los e mantê-los dentro de casa”.

162 UNIDADE IV
Quadro 2 - Certificações por mercador da Fábrica de Software
CERTIFICAÇÕES MERCADO MERCADO MERCADO IN-HOUSE

PRIVADO GOVERNAMENTAL EXTERNO
SW-CMM Importante Elemento de O CMMI está O uso das
elemento de classificação em substituindo práticas é
diferencia- licitações. o SW-CMM importante.
ção e classifi-
cação
CMMI Diferencial, Diferencial, Grande dife- É um mode-
ainda é novi- mas ainda não rencial, é um lo sofistica-
dade é elemento de item qualifi- do para a
classificação cador. maioria das
empresas.
Aplicável
para quem
tem softwa-
re embutido
nos produ-
tos.
ISO 9001:2000 Não é dife- Elemento de Não é dife- Importante,
rencial classificação em rencial mas pode
licitações ser prescin-
dível.
BS7799 ou ISO Diferencial, Pode ser requeri- Grande dife- Importante
mas não do como elemen- rencial do ponto de
decisivo. to de classifica- vista da área
ção em licitações. de YI em sua
totalidade.
Microsoft Solu- Importante, Pode ser reque- Pode ser Não é im-
tion Provider se uma das rido como item requerido portante.
linhas de de classificação como item
serviço for à habilitação da classificató-
desenvolvi- fábrica nesse -rio para a
men-to para ambiente. habilitação
o ambiente da fábrica
Microsoft. nesse am-
biente.
PMP Diferencial, Elemento de Imprescin- Imprescindí-
decisivo. classificação em dível. vel
licitações.

163

PRINCE2 Não é Não é diferencial. Pode ser Prescindível
diferencial. Os órgãos gover- requisito, (a não ser
O mercado namen- principal- que não haja
não conhece tais ainda não mente na exigência da
a metodolo- conhecem a Europa. empresa).
gia. metodologia.
CISA Diferencial, Pode ser elemen- Pode ser um Importante
mas não to de classifica- diferencial, do ponto de
decisivo. ção em licitações. desde que se vista de área
demonstre de TI, princi-

a aplicação palmen-
desse profis- te em gran-
sional. des organi-
zações.
CISM Diferencial, Pode ser elemen- Pode ser um Importante
mas não to de classifica- diferencial. do ponto de
decisivo. ção em licitações. vista de área
de TI, princi-
palmen-
te em gran-
des organi-
zações.
Rational Uni- Item quali- Pode ser item Somente Somente
versity ficador se o classificatório se houver se a empre-
cliente tem se o órgão do exigência. sa tiver a
a plataforma governo exigir plataforma
de desenvol- compatibilida-de Rational.
vimen- de plataforma.
to Rational.
Mercury Inte- Se a empresa Pode ser exigi- Diferencial Importante
ractive usar essa do como item de capacida- se a empre-
plataforma classificatório de de teste. sa usar essa
de testes e se o órgão do plataforma.
for fábrica de governo exigir
projetos. compatibilida-de
de teste.

164 UNIDADE IV

Oracle Item quali- Pode ser item Diferencial Importante
ficador se o classificatório de capa- se a empre-
cliente tem se o órgão do cidade no sa usar essa
a plataforma governo exigir ambiente. plataforma.
Oracle. compatibilida-de
de plataforma.
ASQ Certificados Não tem sido Pode ser Importante
desconhe- item de classifi- diferencial. se a em-
cidos, a cação. presa usa a
não ser na ISO como
indústria. seu sistema
mestre de
qualidade.
Demais cer- Item quali- Pode ser item Diferencial Importante
tificações de ficador se o classificatório de capa- se a empre-
fornecedores cliente tem se o órgão do cidade na sa usar essa
de software a plataforma governo exigir plataforma plataforma.
de software. compatibili- de desenvol-
dade de desen- vimento.
volvi-
mento.
No Brasil, a grande maioria das empresas de prestação de serviços em TI existentes

competem tanto pelo mercado das empresas privadas como pelo governamen-
tal (FERNANDES; TEIXEIRA, 2011). Geralmente, muitas empresas se deparam
com a exigência das certificações ISO e SW-CMM.
A exigência de ter profissionais certificados pelo PMI (PMP) e pelas metodo-
logias de gerenciamento de programas, e que sejam compatíveis com o PMBOK,
está surgindo com bastante força, principalmente em Fábricas de Projetos. Outra
questão que surge é como modelos de melhores práticas, as vezes complemen-
tares, podem conviver (FERNANDES; TEIXEIRA, 2011).
O foco da Fábrica de Software, seja ela de programas, ou de projetos, ou
de outsourcing etc. é a produção do software. Sobre isso, Fernandes e Teixeira
comentam que:

165
[...] software, geralmente faz parte de projetos nos quais estão envolvi-
dos outros componentes, tais como infraestrutura computacional, mu-
danças organizacionais, rede de comunicação e outras frentes de tra-
balho. Esses demais componentes juntamente com o software, fazem
parte do que denominamos anteriormente Fábrica de Projetos amplia-
da. Projetos dessa natureza geralmente são característicos de empresas
integradoras (FERNANDES; TEIXEIRA, 2011, p. 243).
Todos os modelos de melhores práticas cabem perfeitamente nos ambientes de

integração. A Figura 2 mostra a fábrica de software ampliada operando sob o
sistema de qualidade ISO 9001:2000 e os projetos de integração sendo desenvol-
vidos de acordo com os elementos correspondentes a essa norma.
ISO 90001 : 2000

PMBOK SW-CMM
ou ou
CMMI CMMI
Obras e Contratação
e
Software Interfaces
Instalações URA CTI Servidores Rede
Treinamento de CRM CTI e URA
Outras Frentes do Projeto Frentes do Projeto
Figura 2 - Projeto de integração e melhores práticas

Segundo Fernandes e Teixeira (2011, p. 243), “o SW-CMM é um conjunto de ins-

truções técnicas, conforme estrutura da documentação do sistema da qualidade
ISO (lembramos que esse sistema da qualidade abrange a empresa inteira)”. Já
as práticas do PMBOK ou CMMI podem estar junto como procedimentos nos
elementos da ISO, que são referentes ao planejamento dos produtos, dos pro-
cessos relacionados aos clientes, aos projetos, à aquisição e ao desenvolvimento
(FERNANDES; TEIXEIRA, 2011).
Para a fábrica é muito caro manter esses modelos simultaneamente. Se a
empresa for uma grande integradora e disputa grandes contratos no governo,
vale a pena investir, mas se a empresa se dedica somente ao desenvolvimento de
software, deve investir em SW-CMM ou o CMMI.

166 UNIDADE IV
ESTRUTURANDO OPERAÇÕES DE FÁBRICA DE
SOFTWARE OFFSHORE
Os serviços Offshore de desenvolvimento de software sob a análise da ótica econô-

mica internacional constituem um fenômeno recente. Há poucos anos, passaram
a chamar a atenção de empresários e de analistas, devido a expressivos resulta-
dos exibidos pelas fábricas de software (FERNANDES; TEIXEIRA, 2011).
A expansão de demanda de serviços especializados de desenvolvimen-
to de software offshore obedece à lógica de reestruturação econômica
das corporações, cada vez mais dependentes da tecnologia da informa-
ção, adaptando-se às aceleradas mudanças de paradigmas gerenciais,
operando em ambientes locais de altos custos de mão-de-obra e ce-
nários econômicos internacionais flutuantes e de acirrada competição
(FERNANDES; TEIXEIRA, 2011, p. 246).
Contudo, o que é serviços offshore de desenvolvimento de software? Serviço

offshore é quando o produto de software ou serviço prestado de desenvolvimento
de software é especificamente de fora do país de origem da empresa. Segundo
Costa (2011), “offshoring, portanto, consiste na transferência de funções de negó-
cios para o exterior, particularmente para empresa de países com economias

167
emergentes”. O motivo de muitas empresas contratarem serviços offshore é porque

as empresas desenvolvedoras de TI estão cobrando mais caro para desenvolver
software localmente. O objetivo é buscar condições melhores de prestação de
serviços, independentemente de onde o fornecedor esteja localizado.
Fronteira geográfica
Dentro do país Fora do país

Internamente à
organização
Fornecimento
Interno Offshoring
Fronteira da Organização
Terceirização Offshore
Doméstica outsourcing
Externamente à
organização
Figura 3 - Conceito de offshore outsourcing

Fonte: adaptada de Watanuki (2014, p. 29).
Na Unidade III, falamos sobre o Modelo de Outsourcing de sistemas da fábrica

de software; na Unidade I, vimos que Outsourcing é definido como o processo
em que uma organização contrata outra para desempenhar determinada função.
As Outsourcing podem ser divididas em: convencional e BPO (Business Process
Outsourcing). O convencional envolve a terceirização de uma atividade espe-
cífica da área de TI, já o BPO pode ser definido como um contrato com uma
organização externa para que seja fornecido um processo ou função de negócio.
Para Costa (2011), a terceirização outsourcing pode ser classificada em:
on-site e off-site. Onde:
■■ On-site: quando as tarefas da equipe do fornecedor são executadas den-
tro da empresa dos clientes.
Estruturando Operações de Fábrica de Software Offshore

168 UNIDADE IV
■■ Off-site: define as tarefas da equipe do fornecedor sendo executadas remo-

tamente. Pode ser classificada como onshore, nearshore e offshore. Onshore
é quando a localização do fornecedor é a mesma do cliente; nearshore
quando ocorre a migração de serviços para um fornecedor de país vizi-
nho; e offshore é a migração para um fornecedor de fora do país.
Um dos desafios para os fornecedores ao construir um modelo global de entrega

de serviços está na comunicação e na integração. Segundo Costa (2011, p. 19), “a
comunicação entre os diferentes fusos-horários, línguas e culturas, é complicada”,
exigindo um grande esforço e projetos bem especificados e qualificados para ame-
nizar essas barreiras. Com isso, é importante criar procedimentos, mecanismos
de controle para garantir a qualidade e a eficiência dos processos de trabalho.
Segundo Costa (2011), alguns fatores podem influenciar a tomada de deci-
são, tanto para outsourcing quanto para offshoring. Esses fatores, conforme a
Figura 4, incluem forças econômicas, natureza da atividade a capacidade de ges-
tão da empresa.
Capacidade de gestão:
- Avaliação de risco
- Recursos globais e gestão
de fornecedores
- Pensamento sistêmico
- Agentes de mudança
Natureza da Atividade:
- Complexidade
A Empresa
- Maturidade de processo e produto Decisão por

- Modularidade Outsourcing
- Codificação offshore
- Requisitos de contato
Fatores Econômicos:
Ambiente
Externo
- Custo do Trabalho
- Capital Humano
- Políticas Nacionais e Incentivos
Figura 4 - Fatores que influenciam a decisão de abastecimento via offshoring

Fonte: adaptada de Costa (2011, p. 19).

169
a. Fatores econômicos: são o custo do trabalho, a disponibilidade de tra-

balhadores qualificados e o acesso ao mercado estrangeiro, incentivos
governamentais, barreiras como a propriedade intelectual, proteções
legais, leis de privacidade, pressão de opinião pública com relação à ter-
ceirização e à compatibilidade de culturas.
b. Natureza da Atividade: os fatores são: visão de custos de transação asso-
ciados à interação e à internacionalização de atividades. Envolve analisar
se os processos mais complexos têm menos probabilidade de ser removi-
dos para o exterior ou as atividades consideradas mais maduras, estáveis
e modulares são mais propensas de mover.
c. Capacidade de Gestão: são fatores que envolvem as práticas de gestão.

Essas capacidades são habilidades humanas baseadas em recursos, atitu-
des, orientações, motivações e comportamentos. Outros fatores: avaliação
de riscos, recursos globais e gestão de fornecedores, pensamento sistêmi-
cos e agentes relacionados a mudanças.
Hoje, existem empresas que exploram a capacidade dos profissionais que são
bem qualificados, com uma diversidade de conhecimento e que estejam dispo-
níveis para prestar serviços. Para Costa:
[...] elementos como conhecimento, interação com o cliente, confiança
e capacidade de aprendizagem são recursos capazes de criar capacida-
des. O processo de offshoring de serviços, bem como processos inten-
sivos em conhecimentos, exige o conhecimento do idioma da empresa
contratante, o que fez com que a Índia se tornasse um potencial forne-
cedor de profissionais para realização de serviços offshore, uma vez que
os trabalhadores indianos dominam a língua inglesa (COSTA, 2011,
p. 24).
O conhecimento é um produto fundamental para as empresa de serviços, pois é

difícil de ser compreendido e, portanto, de mensuração complicada. O conhe-
cimento implica interpretação, julgamento, tomada de decisão e experiência
em diversos contextos e na integração da informação com um objetivo clara-
mente definido.

170 UNIDADE IV
Offshore, expressão em inglês já consagrada no jargão de profissionais do

setor, designa os serviços prestados para o cliente fora de suas fronteiras na-
cionais; tem sido a solução encontrada, principalmente pelas nações do G7
(grupo das nações mais desenvolvidas do planeta), para contornar seus pro-
blemas de escassez de mão de obra para o desenvolvimento de software.
ENTENDO O CENÁRIO DAS OPERAÇÕES OFFSHORE
As empresas tendem, segundo Fernandes e Teixeira (2011, p. 245), “a concen-

trar-se em seu próprio negócio, seu core business, transferindo a terceiros as
atividades consideradas meio ou acessórias”. Nesta estratégia, está inserida a ter-
ceirização dos serviços de TI, entre eles os de desenvolvimento de sistemas de
gestão. Essa postura empresarial tem benefícios, como a expressiva redução de
custos, a introdução rápida de novas soluções em TI e com alta qualidade e para
os provedores de serviços offshore, uma perspectiva excelente de negócio. Para
Fernandes e Teixeira, essas estratégias são:
[...] as estratégias de adoção dos serviços offshore, porém, são variáveis.
A contratação de serviços offshore envolve riscos maiores, ainda que
as perspectivas de menores custos sejam reais, e por motivos diversos
algumas organizações são mais ou menos voluntariosas em se lançar
em grandes desenvolvimentos que envolvem trabalhos de fornecedores
extra fronteiras. As empresas, em realidades, estão adotando estraté-
gias de contratação offshore. Acompanhando um processo próprio de
maturidade interna de seus procedimentos de gestão (FERNANDES;
TEIXEIRA, 2011, p. 247).
Os procedimentos de maturação das empresas em direção à aquisição dos ser-

viços offshore podem ser divididas em quatro estágios de maturidade (Figura 5):
Estágio 1 – Observador (espectador) do Offshore: não há projetos offshore e
toda a contratação é realizada domesticamente, sendo o mais primitivo dos está-
gios. Obstáculos: diferenças culturais que podem levar ao mau entendimento e

171
à falta de confiança, fuso-horário, falta de habilidade na língua inglesa, legisla-

ções trabalhistas estrangeiras, alta taxa de rotatividade, problema com visto para
os estrangeiros, falta de conhecimento da regra de negócio e infraestrutura de
telecomunicação não confiável.
Estágio 2 – Offshore Experimental: a empresa está adotando experimental-
mente e de forma ad hoc os serviços de desenvolvimento offshore.
Estágio 3 – Proativo Focado em Custos: neste estágio, as empresas focam a
terceirização das atividades fora do core business, estimuladas pela redução dos
custos e, por isso, buscam os serviços de desenvolvimento de software offshore.
Estágio 4 – Proativo Estrategicamente Focado: neste estágio, a área de TI

é estrategicamente terceirizada offshore. As empresas têm processos gerenciais e
padronização para operar com serviços de TI contratados offshore.
PROATIVO ESTRATÉGICO
Estratégia focada em múltiplas fontes de
vantagens competitivas. Centros de outsourcing
offshore desempenham atividades fora do core
business, incluindo novos sistemas e produtos.
Mecanismos de organização de monitoramento
4 de atividades offshore já estão maduros.
Relacionamento com os princípios parceiros de
suprimento de serviços offshore é bastante
estreito.
3 PROATIVO FOCADO EM CUSTO

Estratégia focada na eficiência de custo em que os
serviços offshore desempenham atividades fora
do core business.
Estruturas organizacionais emergem para a gestão
2 de atividades offshore. A conscientização do
EXPERIMENTADOR
Começa a offshore é difundida. Há incentivos para o uso de
experimentação serviços offshore.
Outsourcing e ad hoc
1 EXPECTADOR
Outsourcing doméstico
Figura 5 - Modelo de Estágio de Adoção de Serviços Offshore


172 UNIDADE IV
REQUISITOS TÉCNICOS E COMERCIAIS PARA
ESTRUTURAR UMA OPERAÇÃO OFFSHORE
O essencial para uma Fábrica de Software parece ser as condições de qualidade

e custos competitivos, mas isso não é tudo neste mercado atraente. Lembrando
como é importante a qualidade dos profissionais, o conhecimento da língua
inglesa, o porte das empresas, a rede de relacionamentos e a fixação da marca e
da sua imagem. Para Fernandes e Teixeira são importante alguns pontos:
[...] sob o ponto de vista gerencial, a crescente sofisticação dos projetos,
incluindo diversos parceiros e dispersão geográfica dos grupos partici-
pantes, introduz novos desafios aos profissionais encarregados da ges-
tão dos projetos. A dispersão geográfica, que envolve países diferentes,
traz novos problemas aos gestores dos projetos offshore. Cada nação
tem suas culturas próprias, além de língua, tem seus usos e costumes
comerciais e profissionais que obrigam o fornecedor a adotar medidas
que contornem dificuldades de relacionamento com o cliente (FER-
É comum para as empresas fornecedores que preferem a abordagem de mercado em

parceria com outros fornecedores do mesmo país do cliente ou que recrutam profis-
sionais do país cliente para incorporar à sua equipe. A interface cliente-fornecedor
constitui, segundo Fernandes e Teixeira (2011, p. 267), “o ponto mais crítico a ser con-
siderado pela empresa que pretende estruturar-se para operar fora de suas fronteiras”,
oferecendo seus serviços de software, independentemente de que natureza forem.

173
Requisitos Técnicos: os principais requisitos, segundo Fernandes e Teixeira

(2011), considerados fundamentais, independentemente dos aspectos do ambiente
de negócio são:
■■ Implementação, manutenção e evolução dos processos de software (robus-
tos e consistentes);
■■ Certificação para esses processos (SW-CMM ou CMMI);
■■ Implementação de modelo de execução da plataforma offshore (Figura 6);
■■ Capacitação no gerenciamento de equipes virtuais;

■■ Capacitação no gerenciamento de equipes com diversidade cultural;

■■ Trabalhar com expatriados (brasileiros que moram no país do cliente a
muito tempo) ou contratar nativos para a célula de ligação;
■■ Domínio do negócio do cliente;
■■ Parceiros tecnológicos no país do cliente;
■■ Criar clusters de empresas no Brasil em áreas de mão de obra qualificada
de baixo custo.
Centro de
Célula
Produção Cliente
de Ligação
offshore
• Desenvolvimento • Análise • Especificação de
• Manutenção • Requerimento Requerimento
• Teste • Gestão do Projeto • Monitoração
• Controle da • Implantação • Controle da
Qualidade Qualidade
Observação: A célula de ligação pode estar na
casa do cliente ou em instalação próximas ao
cliente.
Figura 6 - Modelo de Execução da Plataforma Offshore
Fonte: Fernandes, 2011, p. 268.
Requisitos Técnicos e Comerciais Para Estruturar uma Operação Offshore

174 UNIDADE IV
Requisitos Comerciais: estratégias encontradas pelas empresas para a comer-

cialização de serviços offshore podem ser resumidas em:
1. Ligação com clientes multinacionais (rede de filiais a partir do Brasil) –
estratégia de penetração internacional.
2. Composição (via parceria) com o mercado-alvo ou trabalhando sob a
marca no exterior.
3. Formação de sociedade com parceiro no exterior.
4. Aquisição de empresas de médio porte com reputação no mercado.
5. Forma de trabalho proativa (conquistar clientes no exterior de maneira
independente).
6. Criação de consórcios de exportação (alianças estratégicas com empre-
sas de mercado vertical).
E segundo Fernandes e Teixeira (2011, p. 269), “não esquecer de usar nativos

do país cliente para os esforços de comercialização, em função de network pes-
soal que possa existir”.

175
Olá, aluno(a)! Chegamos ao final de mais uma unidade do livro. Nesta unidade,
aprendemos como aplicar os modelos de fábrica de software e sobre conceitos
importantes, como, por exemplo: Fábrica Virtual de Software, Como Aplicar os
Modelos de Fábrica de Software In-house e Fábrica de Software Offshore.
Iniciamos falando sobre virtualização da Fábrica de Software e como ela
é um conceito novo e totalmente exploratório, e como este conceito surgiu da
necessidade de baratear o custo de uma Fábrica de Programas com foco na pla-
taforma distribuída.
Aprendemos como é a aplicação dos modelos de Fábrica de Programas
in-house e como o modelo de Fábrica de Projeto pode ser usado para o desen-
volvimento e a manutenção de sistemas ou como um modelo similar ao de
outsourcing, e entendemos que não é fácil implantar um modelo de fábrica para
o desenvolvimento e a manutenção de sistemas em uma empresa.
Falamos também sobre a abrangência das melhores práticas e as certifica-
ções em uma Fábrica de Software, além de como o mercado tem exigido que as
empresas de prestação de serviços em TI tenham estas certificações e também
para os profissionais que trabalham nestas Fábricas de Software.
Outro tópico importante que aprendemos foi como estruturar as operações
de uma Fábrica de Software e como os serviços Offshore de desenvolvimento de
software, sob a análise da ótica econômica internacional, constituem um fenô-
meno recente, que há poucos anos passaram a chamar a atenção de empresários
e de analistas, devido a expressivos resultados exibidos pelas fábricas de software.
E por fim, vimos os requisitos técnicos e comerciais considerados mais impor-
tantes para a estruturação de uma operação Offshore, além de como é essencial
para uma Fábrica de Software as condições de qualidade e custos competitivos,
mas que isso não é tudo no mercado, considerado atraente.
Preparado(a) para continuar? Então, vamos seguir para a próxima unidade.
Boa leitura e bons estudos!
176
1. Segundo Fernandes e Teixeira (2011), o processo considerado mais crítico é em

relação ao recrutamento de programadores e às questões jurídicas da contrata-
ção. Com base nestas informações, assinale a alternativa correta sobre o pro-
cesso de recrutamento e contratação e suas caraterísticas.
I. Divulgação por meio de profissionais especializados (verificar qual o melhor
canal de comunicação).
II. Presença em uma única língua para atrair profissionais para participar da fá-
brica como programador.
III. No site deve ter um teste on-line para todo profissional que se cadastrar.
IV. Criar um banco de dados com os profissionais cadastrados, com suas habili-
dades e linguagens de domínio.
V. Distribuir as tarefas de acordo com a ordem de cadastro dos programadores,
independentemente dos níveis de serviço.
c) Somente as afirmativas I, III, IV estão corretas.
2. A ordem é enviada por meio de uma chave ou senha, que o programador vai usar
para ter acesso à especificação da tarefa no site da fábrica. Esse processo poderia
ser totalmente automatizado e transmitir mensagens por e-mail e para telefones
celulares. Com base nesta informação, o que acontece caso os programadores
não cumpram com o que é solicitado na tarefa da ordem de serviço?
3. O modelo de Fábrica de Projeto pode ser usado para o desenvolvimento e a ma-
nutenção de sistemas, ou um modelo similar ao de outsourcing, mas implantar
um modelo de fábrica para o desenvolvimento e a manutenção de sistemas em
uma empresa não é considerado uma tarefa fácil. Por que não é considerada
uma tarefa fácil?
4. Serviço de offshore é quando o produto de software ou serviço prestado de de-
senvolvimento de software é especificamente de fora do país de origem da em-
presa. Consiste na transferência de funções de negócios para o exterior, particu-
larmente para empresa de países com economias emergentes. Pensando nisso,
como pode ser classifica a terceirização outsourcing?
177
5. Alguns fatores podem influenciar a tomada de decisão, tanto para outsourcing

quanto para offshoring. Esses fatores incluem forças econômicas, natureza da
atividade e a capacidade de gestão da empresa. Com base nesta informação,
assinale a alternativa correta.
I) Fatores econômicos são o custo do trabalho, a disponibilidade de trabalhado-
res qualificados e o acesso ao mercado estrangeiro.
II) Capacidade de Gestão são os incentivos governamentais, barreiras como a
propriedade intelectual, proteções legais, leis de privacidade, pressão de opi-
nião pública com relação à terceirização e à compatibilidade de culturas.
III) Natureza da Atividade são a visão de custos de transação associados à intera-
ção e à internacionalização de atividades.
IV) Fatores econômicos envolvem analisar se os processos mais complexos têm
menos probabilidade de ser removidos para o exterior ou se as atividades
consideradas mais maduras, estáveis e modulares são mais propensas de mo-
ver.
V) Capacidade de Gestão: são fatores que envolvem as práticas de gestão. Essas
capacidades são habilidades humanas baseadas em recursos, atitudes, orien-
tações, motivações e comportamentos.
c) Somente as afirmativas I, III, V estão corretas.
178
Offshore Outsourcing em Tecnologia de Informação: Fatores Críticos de Sucesso e

Análise dos principais países provedores de serviço
Com o aumento da competitividade, as corporações convergem para estratégias seme-
lhantes: intensificação do foco na qualidade, nos serviços, na excelência operacional e
na redução de custos. As pressões para que os custos sejam cada vez menores são inten-
sas. As companhias que falharem neste item podem ser simplesmente alijadas do mer-
cado. Para focar no negócio e reduzirem seus custos, as corporações têm terceirizado
suas funções de uma maneira intensa nos últimos anos. Com os avanços da tecnologia
de informação e das telecomunicações, permitiu-se que essa terceirização fosse realiza-
da a distância, até mesmo remotamente em outros países. Assim, nascia a terceirização
offshore, onde o trabalho é realizado em um país diferente de onde a companhia que
está demandando o serviço está situada. Para determinar o nível de competitividade
de um país para ser um provedor de serviços em tecnologia de informação, adotou-se
a medição do seu grau de competitividade baseado em cinco grupo de fatores críticos
de sucesso, que são os da mão de obra, infraestrutura técnica, interface com o cliente,
infraestrutura para os negócios e leis reguladoras.
Offshore outsourcing é a transferência de funções de uma empresa-cliente para um for-
necedor localizado fora do país, onde a empresa está sediada. Esta é uma estratégia co-
mum para as empresas localizadas nos Estados Unidos, Europa e Japão. Diversos setores
se beneficiam com este tipo de serviço; um exemplo é o que ocorre com os Centros de
Atendimento aos Clientes, os chamados call centers. Nos Estados Unidos, é comum que
estes centros de atendimentos estejam localizados em países como a Índia e México,
pois a redução de custos obtidas com este tipo de serviço é significativa. Um dos setores
onde a demanda se apresenta cada vez mais intensa é o da Tecnologia de Informação.
A utilização de provedores de serviços de offshore é recente, iniciou-se com o bug do
milênio, na qual a demanda por profissionais com conhecimentos especializados (main-
frame) foi elevada, e os países que possuíam um grande número de aplicações nesta
plataforma não possuíam profissionais em número suficientes para atender à demanda.
Optou-se por buscar profissionais no exterior ou enviar o trabalho remotamente, sur-
gia assim o offshore outsourcing e os primeiros países provedores de serviços. Um dos
primeiros países a prestar estes serviços foi a Índia, e esta tem-se se destacado como o
principal país provedor de serviços no cenário mundial. Há diversos países provedores
de serviços na atualidade sendo que a Índia, é o principal e maior provedor tendo como
concorrentes a China, o Canadá, México, Rússia e Irlanda do Norte.
Fatores da mão de obra

A língua inglesa não é dominada pela maioria dos universitários que se formam
anualmente no ensino superior, o que dificulta muito a expansão de serviços de
offshore . Porém, a indústria de software no Brasil é bastante significativa, o que
ajuda a formar profissionais competentes e atualizados com o mercado internacional.
179
Infraestrutura técnica
A abertura do mercado de telecomunicações permitiu uma atualização bastante
rápida na infraestrutura de comunicações, permitindo que a comunicação de voz e da-
dos seja feita de forma rápida e eficiente com países que mais necessitam de serviços
de offshore em TI. O hardware e o software utilizados no país possuem o mesmo nível
de atualização que os utilizados nos países de maior demanda por estes serviços, isto
garante um alto grau de compatibilidade técnica com os clientes.
Interface com o cliente

As maiores companhias mundiais possuem filiais no Brasil, e praticamente todas as prin-
cipais empresas de TI possuem filiais no Brasil, empresas como IBM, HP, EDS têm filiais
importantes no país. A familiaridade com a cultura ocidental permite que os brasileiros
se adaptem facilmente ao estilo de trabalho de prestação de serviços de offshore; exis-
tem filiais de companhias multinacionais que enviam serviços para o país, como é o caso
da EDS, onde os clientes do mercado americano podem e são atendidos por profissio-
nais localizados no Brasil.
A Índia continuará dominando o mercado de serviços de offshore em tecnologia de in-

formação durante vários anos, pois suas vantagens estratégicas são difíceis de serem
superadas pelos países concorrentes. Porém, a elevada concentração de serviços em
um único país eleva muito o risco, por isso outros países recebem parte destes serviços,
mesmo tendo uma menor competitividade comparada aos indianos. A atuação do go-
verno neste setor é fundamental, pois existem diversos fatores críticos de sucesso que
dependem de atos governamentais, tais como: políticas educacionais, investimentos
em infra estrutura, leis de proteção à propriedade intelectual.
O Brasil pode se tornar um fornecedor de destaque no cenário mundial, porém é neces-
sário que o governo e a iniciativa privada atuem de uma forma mais concreta nos fatores
críticos de sucesso.
Fonte: Okuyama (2005).

Guia Prático de Terceirização: como elaborar um projeto de

terceirização eficaz
Giuseppe Russo
Editora: Elsevier
Sinopse: cada vez mais as empresas recorrem às terceirizações em
vista de custos mais baixos, com menos preocupações em longo prazo,
tendo em vista a complexidade de alguns serviços. Porém, para que um
serviço terceirizado seja escolhido da forma mais adequada, é necessário
um projeto de planejamento, aquilo que o Giuseppe Russo chama
de mapa, que irá guiar o leitor de forma ordenada e sequencial pelas
diversas etapas de um processo de terceirização. Este livro irá auxiliar na
elaboração de um planejamento de terceirização – ou revisão de um plano –, contendo informações
relevantes para o sucesso de um negócio.
Governança de Tecnologia da Informação e Comunicação

(TIC)
Jenner Souza
Editora: Ciência Moderna
Sinopse: “Governança de Tecnologia da Informação e Comunicação
(TIC) – Gerenciamento de Níveis de Serviços Terceirizados” tem seu
foco principal na implantação e gestão de uma central de serviços, e
apresenta, de forma clara e objetiva, uma sugestão de modelo para o
gerenciamento dos serviços do departamento de TIC ou de uma empresa
de prestação de serviços terceirizada da área. O livro apresenta um
estudo de caso de sucesso da implantação da Governança de TI em uma
multinacional atuando no mercado de papel e celulose no extremo sul
baiano. É ilustrado por modelos de relatórios, fluxo de trabalho, o papel de cada membro da equipe,
entre outros. Também apresenta um embasamento teórico de quando terceirizar os serviços de TIC
de uma organização e o quanto é fundamental planejar-se para isso.
Brasil, Rússia, Índia e China: O Desafio do Offshore Outsourcing

Artigo interessante sobre as Offshore outsourcing e como se tornaram uma tendência muito
viável para as empresas, que estão expandindo ou apenas a tentando reduzir os seus gastos
gerais, inclusive no Brasil. Para saber mais, acesse o link disponível em: <http://quadsys.com.br/
Site/noticias/noticiasDetalhe.aspx?n=3>.
Análise do processo de gestão de contratos em fábrica de software

Artigo sobre a análise do processo de gestão de contratos em fábricas de software, mostrando
que esse processo não é simples e que, além da mudança de cultura para o cliente e os
colaboradores, agrega-se a isto o fato de receber por serviço e não mais por disponibilidade.
Mais informações, acesse o link disponível em: <https://www.tiespecialistas.com.br/2012/02/
analise-do-processo-de-gestao-de-contratos-em-fabrica-de-software/>.
REFERÊNCIAS
COSTA, Rejane Beatriz Godoy da. Uma Análise sobre a Integração de Provedores
Brasileiros em Projetos de Empresa Internacionais na Cadeia de Tecnologia da
Informação. São Leopoldo: UNISINOS, 2011.
GARFINKEL, Alexandre. Análise da Desverticalização e das Condições Favoráveis
À Produção “In House”. Rio de Janeiro: FGV, 2002.
OKUYAMA, Maurício Yoshihiro. Offshore Outsourcing em Tecnologia de Informa-
ção: Fatores Críticos de Sucesso e Análise dos principais países provedores de
serviço - 2. Contecsi – Congresso Internacional de Gestão da Tecnologia e Sistemas
de Informação / Internacional Conference on Information Systems and Technology
Management. São Paulo, Jun. 2005..
WATANUKI, Hugo Martinelli. Desempenho de Equipes Virtuais no Multisourcing
de Serviços de Tecnologia da Informação. São Paulo: USP, 2014.
183
GABARITO
1. Alternativa C.
2. Caso os programadores não cumprissem com o que era solicitado na tarefa da
ordem de serviço, de forma sistemática, de acordo com o prazo estabelecido e
com qualidade, são automaticamente eliminados dos recursos disponíveis para
a produção e são adicionados à lista negra de profissionais da área.
3. Porque alguns usuários estão acostumados com um atendimento com regalias
e, ao implantar um modelo de fábrica, poderão perder, já que o processo de so-
licitação de serviços deverá seguir um padrão disciplinado. E conforme o poder
do usuário, o projeto para implantar este modelo pode sofrer bastante.
4. A terceirização outsourcing pode ser classificada em: on-site e off-site. Onde:
On-site: quando as tarefas da equipe do fornecedor são executadas dentro da
empresa dos clientes. Off-site: define as tarefas da equipe do fornecedor sen-
do executadas remotamente. Pode ser classificada como onshore, nearshore e
offshore. Onshore é quando a localização do fornecedor é a mesma do cliente;
nearshore, quando ocorre a migração de serviços para um fornecedor de país
vizinho; e offshore é a migração para um fornecedor de fora do país.
5. Alternativa C.
IMPLANTANDO A FÁBRICA
V
UNIDADE
DE SOFTWARE
■■ Conhecer as estratégias da implantação da Fábrica de Software.
■■ Entender planejamento da implantação da Fábrica de Software.
■■ Conceituar o WBS do Projeto de Fábrica de Software.
■■ Entender gerenciamento da implantação da Fábrica de Software.
Plano de Estudo
■■ Estratégia da Implantação da Fábrica de Software
■■ Planejamento da Implantação da Fábrica de Software
■■ WBS do Projeto de Fábrica de Software
■■ Gerenciamento da Implantação da Fábrica de Software
187
INTRODUÇÃO
Olá, aluno(a)! Estamos chegamos ao final do nosso livro e, nesta unidade, vamos
aprender sobre a implantação de uma Fábrica de Software, seus conceitos e
estratégias. Nesta unidade, uniremos alguns dos conceitos que foram estudados
durante o livro e aplicaremos na implantação da fábrica.
Vamos iniciar falando sobre as estratégias da implantação da Fábrica de
Software. Ao escolher as estratégias para a implantação, partimos do pressuposto
de que as questões de estrutura e infraestrutura já foram decididas anteriormente.
A estratégia de desenvolvimento do projeto de implementação determina o meio

pelo qual vamos desenvolver o planejamento e a sua execução.
Em seguida, vamos ver o planejamento da implantação da Fábrica de Software.
Vamos aprender que a entrada principal para o planejamento da implementa-
ção da fábrica de software é constituída por suas especificações técnicas e pela
estratégia de desenvolvimento.
Vamos falar também sobre WBS do Projeto de Fábrica de Software. WBS
é um processo de subdivisão das entregas e do trabalho do projeto em compo-
nentes menores e mais facilmente gerenciáveis. O WBS do projeto define os
entregáveis do projeto.
Também vamos aprender como Gerenciar a Implantação da Fábrica de
Software. A base para o gerenciamento da implantação é o plano do projeto e
seus respectivos planos auxiliares. Será apresentado alguns processos de con-
trole, que são requeridos para a execução do gerenciamento do projeto, como:
verificação do escopo, controle da mudança do escopo, controle do cronograma,
controle do custo, quality assurance, controle da qualidade, controle do risco,
controle da mudança e gerenciamento integrado.
Colocando em prática o que aprendemos ao longo do livro, fica a dica: vale
a pena estudar, pesquisar e procurar sempre testar diferentes abordagens, até
encontrar a que funciona melhor para você, sua equipe e seus clientes.
Preparado(a) para continuar? Então, vamos seguir em frente. Ótima leitura
e bons estudos!
Introdução
188 UNIDADE V
ESTRATÉGIA DA IMPLANTAÇÃO DA FÁBRICA DE
SOFTWARE
A implantação da Fábrica de Software, segundo Fernandes e Teixeira (2011, p.

279), “parte do pressuposto de que as questões de sua estrutura e infraestrutura já
estejam decididas”. Planejar o projeto de implementação da Fábrica de Software
é uma tarefa que tem base na sua especificação conceitual, conforme a Figura 1.

189
Identificação dos Itens

Qualificadores e Ganhadores de
Pedido
Determinação dos Objetivos de

Desempenho da Operação
Determinação da
Determinação da Estrutura
infraestrutura da
da Operação
Operação
Especificação da Fábrica
Figura 1 - Passos do Projeto da Operação

Para o sucesso da empresa, é crucial a estratégia de desenvolvimento do projeto

de implementação, pois o detalhamento do planejamento do projeto de imple-
mentação depende da estratégia e, para Fernandes e Teixeira:
Estratégia da Implantação da Fábrica de Software

190 UNIDADE V
[...] a estratégia de desenvolvimento do projeto de implementação de-

termina o meio pelo qual vamos desenvolver o planejamento e sua exe-
cução, considerando alguns aspectos importantes. A estratégia define
como vamos estruturar o Work Breakdown Structure (WBS), do projeto
(os produtos a serem entregues ao longo do projeto), qual vai ser o
ciclo de vida a ser adotado para o projeto, qual a melhor sequência
das atividades, como os fornecedores de opinião vão ser envolvidos, e
assim sucessivamente. A estratégia depende muito da complexidade do
projeto, considerando seu porte e risco. Quanto maior a complexidade
do projeto, mais importante é a definição da estratégia de desenvolvi-
mento do projeto. A estratégia tem como missão principal a redução
da complexidade do projeto (FERNANDES; TEIXEIRA, 2011, p. 280).
Na primeira vez que implantamos uma Fábrica de Software, o processo é con-
siderado complexo e de risco, e a estratégia pode ser documentada ou não. O
ideal é que a estratégia seja formalmente documentada e que tenha um controle
rígido de configuração. Para Fernandes e Teixeira (2011), a estratégia deve con-
siderar os seguintes pontos:
■■ Como será a estruturação dos deliverables do WBS?
■■ A estratégia de desenvolvimento vai ser de toda a fábrica? Ou vai ser
desenvolvida por terceiros (parte ou integralmente)?
■■ Os fornecedores de tecnologia irão participar ativamente do projeto?
■■ Qual será o Ciclo de Vida adotado para o projeto?
■■ Qual a estratégia de entrega dos produtos ou das funcionalidades
requeridas?
■■ Como será o plano de qualidade do projeto?
■■ Como será a estrutura organizacional do projeto?
■■ Como será o plano de risco?
■■ Como será a comunicação do projeto?
■■ Como será o envolvimento das pessoas chaves durante o desenvolvi-
mento do planejamento?

191
A equipe responsável pela execução do projeto se orienta com as respostas dessas

questões para o planejamento das estratégias de desenvolvimento. A estratégia
também ajuda a definir como conduzir a execução do planejamento e do pro-
jeto. De acordo com Fernandes e Teixeira (2011), conforme o porte, o risco e a
complexidade do projeto, é necessário alocar recursos humanos especializados
e/ou contratar serviços externos, para que o planejamento seja coerente e prati-
cável. Ainda segundo os autores, existem alguns passos para o desenvolvimento
da estratégia do projeto, que são:
Quadro 1 - Passos para o desenvolvimento de estratégia do projeto
Analisar a especificação da fábrica de software, visando alinhar a estratégia de

desenvolvimento do projeto.
Verificar experiências de projetos com as mesmas características no mercado
para obter informações sobre as lições aprendidas.
Definir a estrutura básica do WBS, considerando as frentes de trabalho esperadas
para o projeto, que merecem destaque.
Ao definir as “frentes” de trabalho ou conjunto de deliverables, identificar o con-
junto principal de produto (produto final) e os conjuntos de apoio e secundários
que são importantes para a geração do produto final.
Decidir sobre a estratégia de desenvolvimento do produto resultante do proje-
to, considerando as alternativas de desenvolvimento interno, integral e parcial,
contratação de terceiros integral ou parcial, aquisição de pacotes, envolvimento
de fornecedores, contratação de pessoas que já vivenciaram projetos dessa
natureza etc.
Decidir sobre o ciclo de vida a ser adotado para o desenvolvimento do projeto
(podemos utilizar um ciclo de vida para cada tipo de deliverable do projeto, con-
siderando as frentes de trabalho definidas pela estrutura do WBS).
Decidir sobre como os produtos vão ser entregues ao longo do tempo, devido às
restrições de prazo e custo (a entrega dos produtos também está muito associa-
da ao ciclo de vida selecionado para o projeto).
Definir os requisitos do plano da qualidade do projeto, como decidir sobre uso
de revisões, ambientes de testes estruturados, papel do quality assurance, uso
de padrões etc. (esses requisitos servem de guia para a elaboração do Plano de
Qualidade do Projeto).

192 UNIDADE V
Definir os requisitos do Plano Organizacional do Projeto em termos de: uso de

“Comitê de Projeto”, sobre “quem” é imprescindível para participar nesse comitê,
quais formadores de opinião devem ser trabalhados, qual a qualificação dos
recursos humanos requerida etc. (esses requisitos servem de guia para a elabora-
ção do Plano de Organização do Projeto).
Definir os requisitos para o Planejamento da Aquisição do Projeto em termos de
tipo e qualificação de recursos, parceiros e fornecedores, tipos de equipamentos
etc. (também serve de guia para a elaboração do Plano de Aquisição do Projeto).
Definir os requisitos para o Plano de Riscos em termos de pontos de atenção
em função do tipo do projeto, indicar os riscos prováveis do projeto, conforme
conhecimento de práticas do mercado.
Definir os requisitos para o Plano de Comunicação do Projeto, considerando
meios usuais de comunicação e relatórios já empregados pela empresa ou em
função das características da audiência, identificar os meios adequados em vista
da cultura da empresa.
Definir qual a estratégia básica de envolvimento das pessoas-chaves no projeto.
Definir a alocação de recursos para a elaboração do planejamento do projeto.
Definir as datas limites de encerramento das atividades previstas no planejamen-
to do projeto.
Definir os pontos de revisão dos produtos do planejamento do projeto antes das
apresentações para os stakeholders e gestor do projeto.
Definir a estratégia de homologação evolutiva dos produtos do planejamento
junto aos stakeholders e gestor do projeto.
Documentar a estratégia de desenvolvimento.
Fonte: adaptado de Fernandes e Teixeira (2011, p. 281).
Com relação aos itens que a documentação da estratégia conterá e que irá guiar o
planejamento do projeto, conforme Fernandes e Teixeira (2011), pela ordem são:
■■ Estrutura básica do WBS;
■■ Alternativas de aquisição;
■■ Ciclos de vida selecionados;
■■ Estratégia de liberação de produtos;
■■ Requisitos de Plano da Qualidade;
■■ Requisitos para o Plano Organizacional;

193
■■ Requisitos para o Plano de Riscos;

■■ Requisitos para o Plano de Comunicação;
■■ Critérios para as Estimativas;
■■ Estratégia de desenvolvimento;
■■ Necessidade de recursos;
■■ Plano de planejamento;
■■ Pontos de revisão do planejamento;
■■ Estratégia de homologação.
A seguir, algumas sugestões práticas de Fernandes e Teixeira (2011) para a imple-

mentação de um projeto de Fábrica de Software:
■■ Seleção de gerente de projetos com autoridade para ser responsável pelo
projeto.
■■ Adoção de abordagem incremental para a implantação da Fábrica.
■■ Prioridade à gestão da operação, à gestão do projeto e ao processo de
construção.
■■ Ferramentas básicas para a automação da fábrica devem ser implementadas.
■■ Alocar recursos dedicados para o desenvolvimento interno de ferramen-
tas de apoio.
■■ Orçamento específico para o projeto.
■■ Empresa deve se comprometer em seguir o planejamento.

194 UNIDADE V
A representação utilizada para a definição do escopo, que é a saída desse

processo, é a estrutura analítica do projeto (EAP), tradução para o português
de Work Breakdown Structure (WBS). A Estrutura Analítica do Projeto (EAP)
é a base para o detalhamento do trabalho do projeto. Depois de elaborada
e aprovada, ela passa ser a base de referência do escopo do projeto (scope
baseline). O PMI (2001) consolidou esse conceito ao definir a EAP como “um
agrupamento de elementos componentes do projeto, orientado a subpro-
dutos, que organiza e define o escopo de trabalho de um projeto”. A EAP
é uma estrutura hierárquica, podendo ser representada na forma gráfica,
(semelhante a um organograma), ou como uma lista indentada.
Fonte: Siqueira (2007).
PLANEJAMENTO DA IMPLANTAÇÃO DA FÁBRICA DE

SOFTWARE
Para gerar um Plano de

Projeto, o planejamento da
implantação da fábrica deve
seguir alguns passos. Segundo
Fernandes e Teixeira (2011, p.
283), “a entrada principal para
o planejamento da implemen-
tação da Fábrica de Software é
constituída por suas especifica-
ções técnicas e pela estratégia
de desenvolvimento”.
Estas técnicas e estraté-
gias foram vistas na Unidade I do nosso livro, no tópico sobre Decisões acerca
da estrutura organizacional da fábrica de software, em que foi apresentado um
framework para o projeto da fábrica de software, baseado nas áreas de decisões
estratégias de operações.

195
Quadro 2 - Passos para o Planejamento do Projeto
PASSOS PARA O PLANEJAMENTO DO PROJETO

Definição do WBS do projeto.
Definição das atividades para a geração de cada produto previsto para ser entre-
gue pelo projeto.
Definição sobre precedência entre as atividades.
Estimativa de prazos e recursos.
Estimativa de custos.
Elaboração do Plano de Qualidade.
Elaboração do Plano Organizacional.

Elaboração do Plano de Aquisição de Recursos.
Elaboração do Plano de Riscos.
Elaboração do Plano de comunicação.
Elaboração do Cronograma do Projeto.
Elaboração do Orçamento de Custo do Projeto.
Elaboração dos Critérios de Controle do Cronograma, Custo e Escopo.
Consolidação do Plano do Projeto
“A academia forma profissionais adequadamente qualificados para traba-

lhar nas fábricas de software?”
(Fernando Guilherme Tenório)
Planejamento da Implantação da Fábrica de Software

196 UNIDADE V
WBS DO PROJETO DE FÁBRICA DE SOFTWARE
Conforme Fernandes e Teixeira (2011, p. 284), “o WBS do projeto define os entre-

gáveis do projeto”. Um projeto de Fábrica de Software possui algumas frentes de
trabalho, que são agrupamentos de entregáveis (Figura 2):
■■ Instalações: instalações físicas e mobiliário.
■■ Infraestrutura Tecnológica: projeto da rede, servidores, software, cabe-
amento e dispositivos da rede.
■■ Processos e Ferramentas: processos de construção, ferramentas do
processo de construção, processo de gestão do projeto, ferramentas do
processo de gestão do projeto, processo de gestão da operação, ferramen-
tas do processo de gestão da operação, processo de suporte, ferramentas
do processo de suporte, processo de gestão estratégica e ferramentas do
processo de gestão estratégica.
■■ Estrutura Organizacional: estrutura organizacional da fábrica.
■■ Sistemas de Gestão: gestão da demanda, gestão de desempenho, gestão
do projeto, gestão financeira e outras ferramentas.
■■ Treinamento: processos e ferramentas de construção, gestão de projeto,
de gestão da operação, suporte e processos estratégicos.

197
■■ Garantia da Qualidade Externa: plano de garantia da qualidade e rela-

tórios de garantia da qualidade.
■■ Gestão do Projeto: plano do projeto, controle do cronograma, controle
do custo, controle de qualidade e controle do escopo.
Projeto Implementação da
Fábrica de Software
Infraestrutura Processos e Estrutura Sistema Garantia da Gestão do

Instalações Treinamento
Tecnológica Ferramentas Organizacional de Gestão Qualidade Projeto
Figura 2 - WBS da Implantação da Fábrica de Software

DEFINIÇÃO DAS ATIVIDADES E PRECEDÊNCIAS
As atividades requeridas para a geração de cada produto tem base no WBS. Por
exemplo, de acordo com Fernandes e Teixeira (2011), para o treinamento, as
atividades para cada produto são: preparação do programa de treinamento, vali-
dação do programa, desenvolvimento do material de treinamento, validação do
material de treinamento, programação do treinamento e de sua logística, exe-
cução do treinamento e avaliação do treinamento. A precedência vai depender
da estratégia de entrega.
Ao elaborar a lista de atividade, o ideal é determinar quais as atividades serão
consideradas como pontos de controle do projeto. Os pontos de controle, con-
forme Fernandes e Teixeira (2011, p. 286), “são estabelecidos para a avaliação
do progresso do projeto”. As atividades são geralmente de verificação e valida-
ção de produtos considerados críticos para o sucesso do projeto, ou seja, são os
produtos que estão no caminho mais crítico do projeto.
WBS do Projeto de Fábrica de Software

198 UNIDADE V
ESTIMATIVA DE PRAZOS E RECURSOS
Segundo Fernandes e Teixeira (2011, p. 286), “as estimativas de prazos e de recur-

sos para o projeto estão intimamente interligadas”, pois em um projeto, os recursos
utilizados podem, geralmente, alterar os prazos que foram estabelecidos para uma
atividade, e as restrições de prazos podem, também, influenciar na quantidade de
recursos necessários. Conforme Fernandes e Teixeira, as estimativas obtêm e envolvem:
[...] as estimativas de prazo é o processo de obter informação sobre o
escopo e recursos e desenvolver as durações das atividades, visando sub-
sidiar a elaboração do cronograma. As estimativas de recursos, por sua
vez, envolve a determinação de quais recursos (pessoas, equipamentos,
materiais e serviços) e sua respectiva quantidade serão necessários para
o desempenho do projeto. O tempo de uso do recurso ou a quantidade
de consumo de recursos nas atividades do projeto irão determinar a es-
timativa de custo do projeto (FERNANDES; TEIXEIRA, 2011, p. 287).
Alguns aspectos devem ser considerados durante a realização das estimativas, como:
■■ A estimativa deve ser desenvolvida com a equipe do projeto.
■■ Selecionar pessoas certas para participar das estimativas.
■■ Para aprimorar as estimativas, procurar usar conhecimento especialista
interno e/ou externo.
■■ Utilizar o histórico de projetos do mercado para verificar o que dá certo
e o que não dá certo para estimar prazos e recursos.
■■ Não comprometer-se com estimativas instantâneas.
■■ Não fazer estimativas sem as contribuições da Especificação Técnica da
Fábrica.
■■ Levar em considerar os riscos preliminares do projeto nas estimativas.
■■ Levar em consideração as estratégias definidas para o projeto nas estimativas.

■■ Procurar não ter a ocorrência de retrabalhos nas estimativas para que
não atrasem o projeto.
■■ Para avaliar se precisa aprofundar a exatidão da estimativa, faça uso das
estimativas de “chute”.

199
■■ Para a alocação e disponibilidade de recursos, defina premissas sobre a

qualidade dos recursos e dos fornecedores, para não ocorrer diferenças
no momento real do uso.
■■ Analisar na estimativa os recursos necessários: máquinas, ferramentas,
pessoas, software, serviços internos e externos, instalações etc.
■■ Para realizar as estimativas, levar em consideração os fatores de produ-
tividade conhecidos.
■■ Procurar utilizar técnicas para a estimativa de prazos (como, por exemplo:
estimativas análogas se baseiam nas experiências de projetos anterio-
res da empresa ou do próprio mercado em que a empresa está inserida).

■■ Procure realizar simulações em termos de revisão de atividades, estraté-
gias de desenvolvimento e escopo para pensar em novas possibilidades,
caso a estimativa de prazo esteja muito longo da expectativa dos gerentes.
Segundo Fernandes e Teixeira (2011), na Fábrica de Software podemos usar as

seguintes técnicas em projetos integrados:
■■ Uso de Especialistas: importante usar e contar com o conhecimento
externo para a estimativa de prazos, principalmente quando o projeto
envolve novidades para a empresa e para a equipe do projeto.
■■ Técnica Delphi: pode produzir estimativas adequadas quando temos
ausência de conhecimento; especialista externo. Conforme Fernandes e
Teixeira (2011), a técnica de Delphi aplica uma abordagem de brainstor-
ming, em que cada membro da equipe do projeto fornece estimativas a
respeito da duração de uma determinada atividade. Os resultados obti-
dos são tabulados e analisados, e sua frequência e média são calculadas.
Após a aplicação das técnicas, os resultados que estão fora da média podem ser
novamente discutidos para saber a razão das variações. Então, de acordo com
Fernandes e Teixeira (2011, p. 288), “é feita outra rodada de estimativas em
função das observações dos indivíduos que estavam fora da média”. Após os
resultados, novamente são tabulados e as variações discutidas e, assim, sucessi-
vamente, até chegar a uma estimativa final. Outra forma de aplicar esta técnica
é usar o conhecimento dos especialistas e confrontar os resultados tabulados da
equipe, para aprimorar as estimativas.

200 UNIDADE V
A técnica Delphi nasceu dentro dos denominados Métodos de Especialis-

tas, que são aqueles que utilizam como fonte de informação um grupo de
pessoas que se supõe com elevado conhecimento do assunto do qual se
vai tratar. Estes métodos são geralmente empregados em três condições:
quando não há dados históricos com os quais se possa trabalhar; quando o
impacto dos fatores externos tem mais influência na evolução do tema em
questão que o dos internos. Por ser uma técnica que permite trabalhar com
problemas complexos, sua escolha pode ser justificada quando se pretende
que um grupo de especialistas e pesquisadores dê sua contribuição para
algum problema mais complexo de pesquisa.
Fonte: Rozados (2015, p. 64).
■■ Técnica dos Três Pontos: esta técnica supõe que a duração da tarefa é algo
aleatório, mesmo considerando as mesmas condições de projeto. Conforme
Fernandes e Teixeira (2011, p. 288), “reúne-se a equipe do projeto e soli-
cita-se que cada indivíduo faça três estimativas acerca do projeto; uma
otimista, outra pessimista e outra mais provável”. No caso da estimativa
pessimista, esta é dada se tudo ocorrer errado, e a mais provável é gerada
a partir da experiência individual de cada membro da equipe.
Esta técnica emprega a seguinte fórmula para a determinação da duração da tarefa:
onde:
E = estimativa de duração
EO = estimativa otimista
EM = estimativa mais provável
EP = estimativa pessimista

201
■■ Técnica Delphi Ampliada: esta técnica combina a técnica Delphi com a

técnica de Três Pontos. Assim, em vez de uma estimativa, os membros da
equipe fazem três estimativas e, depois, são feitas as médias para as três
estimativas, que são aplicadas na fórmula para a determinação da dura-
ção da atividade.
■■ PERT (Program Evaluation and Review Technique): técnica desen-
volvida para a Marinha dos Estados Unidos, para aplicação no software
Polaris, ou seja, técnica de elaboração e de controle de projetos (também
chamada de representação gráfica PERT). Segundo Fernandes e Teixeira
(2011, p. 289), “o método é uma técnica de redes e consiste em um con-
junto de processos, técnicas para planejamento, programação e controle

de um empreendimento ou operação ou projeto”. Às vezes vem acompa-
nhado do CPM (Critical Path Method – Método do Caminho Crítico),
que é uma técnica usada para gerenciar o calendário de um projeto.
A técnica PERT é composta por alguns elementos e funciona da seguinte maneira

(Figura 3).
O elemento Tarefa é uma atividade ou etapa representada por uma flecha
ou seta, e cada tarefa corresponde a um código com uma duração. O elemento
Etapa corresponde ao início e fim de uma tarefa, e cada etapa de fim é também
etapa de início da tarefa seguinte, sendo elas numeradas e representadas por um
círculo, mas podem ter outras formas, como quadrados, retângulos etc.
40
t=1 mo t=3 mo
D F
t=3 mo t=2 mo
10 30 50
A E
t=4 mo B C t=3 mo
20
Figura 3 - Exemplo Gráfico de rede PERT para um projeto de 7 meses com cinco marcos (10 até 50) e seis
atividades (A até F)
Fonte: Wikipédia ([2017], on-line)1.

202 UNIDADE V
Quando se inicia um projeto, seja ele qual for, pode envolver alguns ritu-
ais pessoais, como uma caminhada, ou algo mais estruturado, como alguns
questionários ou uma entrevista com o cliente. Outros aplicam o Brainstor-
ming (Brainstorming é o nome dado a uma técnica grupal – ou individu-
al – na qual são realizados exercícios mentais com a finalidade de resolver
problemas específicos), na busca incansável de ideias inovadoras, uma for-
ma de melhorar o processo de pensar criativo. O Brainstorming é uma ferra-
menta poderosa, que aborda a criação em grupo para desenvolver ideias e
soluções durante a etapa de geração de ideias e soluções.
Fonte: a autora.
Falamos sobre estimativas de prazos e recursos. Agora vamos falar sobre estima-
tiva de custos. Para Fernandes e Teixeira, a estimativa de custo é:
[...] o processo de desenvolver uma estimativa aproximada de custos
dos recursos necessários para completar o projeto. Para tanto, é neces-
sário quantificar em valores monetários o orçamento de recursos do
projeto, assim como definir alternativas de custo se houver restrições
orçamentárias colocadas para a equipe do projeto (FERNANDES; TEI-
XEIRA, 2011, p. 289).
Contudo, quando usar a estimativa de custo? Ela vai ser usada quando ocorrer
a elaboração do Orçamento de Custo do Projeto, quando for feita a apropriação
dos custos estimados para cada tarefa a ser desenvolvida. Assim, a estimativa de
custo depende da estimativa de prazo e recurso.
ELABORAÇÃO DOS PLANOS AUXILIARES
Durante a implantação, é importante a elaboração de planos auxiliares. Conforme

Fernandes e Teixeira (2011), os planos auxiliares mais importantes são: de qua-
lidade, organizacional, de aquisição, de riscos e comunicação. A seguir, vamos
listar os itens que devem ser considerados em cada um dos planos auxiliares.
Para a elaboração do plano de qualidade, devemos considerar os seguin-
tes requisitos:

203
Quadro 3 – Requisitos para Plano Auxiliar de Qualidade
Definir os objetivos do plano de gerenciamento da qualidade.

Identificar e definir as responsabilidades pela gestão e execução do plano e o
esforço requerido para a operação do plano.
Identificar quais os padrões de qualidade serão seguidos pelo projeto.
Definir critérios de aceitação dos produtos.
Definir as ações de garantia da qualidade em termos de processos a serem verifi-
cados, em quais elementos do WBS, com que frequência e técnicas e métodos a
serem empregados.
Definir ações de controle de qualidade dos produtos em termos de produto a
serem verificados e validados.

Definir como se dará o tratamento de não conformidades (ponto de vista dos
processos e dos produtos).
Definir como se dará o tratamento de requerimentos da prevenção e de melho-
ria.
Definir o processo de monitoramento da resolução de solicitações de ações
corretivas e de solicitações de prevenção e melhorias.
Definir como será a avaliação dos resultados da ação da qualidade sobre os
objetivos do projeto.
Estimar os custos dos recursos humanos necessários e dos demais recursos
requeridos para o gerenciamento de qualidade.
Elaborar o cronograma de execução das ações da qualidade.
Para a elaboração do plano de organizacional, devemos considerar os seguin-

tes requisitos:

204 UNIDADE V
Quadro 4 - Requisitos para Plano Auxiliar Organizacional
Definir e atribuir as responsabilidades pela elaboração, gestão e execução do

plano.
Determinar o objetivo do plano.
Definir a estrutura de gestão do projeto, indicando o organograma, quem parti-
cipará em que nível e instância do organograma.
Definir uma matriz de responsabilidade em relação ao projeto em termos de
quem homologa, participa, valida, verifica e executa.
Definir acordo de nível de serviço com a “logística” do projeto no tocante ao
suprimento de recursos humanos ao projeto.
Determinar o cronograma de alocação e remoção de recursos humanos do
projeto.
Definir o processo de solicitação e movimentação de recursos humanos.
Definir os critérios de liberação dos recursos humanos.
Para a elaboração do plano de aquisição, devemos considerar os seguintes

requisitos:
Quadro 5 - Requisitos para Plano Auxiliar de Aquisição
Designar um responsável pela elaboração do plano.

Envolver o pessoal de suprimentos (compras, comitê de licitações etc.) para par-
ticipar no processo de elaboração do plano.
Determinar o objetivo do plano em função dos riscos e da importância dos
recursos a serem empregados pelo projeto.
Definir e atribuir as responsabilidades pela gestão e execução do plano.
Identificar e definir quais normativos de aquisição da empresa ou instituição
estarão sendo usados para a execução do plano.
Definir o fluxo do processo de aquisição de recursos e serviços para o projeto.
Definir os tipos de contratos mais adequados em função dos tipos de recursos e
objetivos do projeto.
Definir os critérios de elaboração dos documentos de suprimentos.
Definir os critérios de seleção de fornecedores.
Definir os critérios de uso e aceitação dos produtos e serviços dos fornecedores.
Definir os critérios de gestão dos fornecedores.

205
Definir os critérios de aquisição de recursos e serviços internos.

Definir os acordos de níveis de serviços para os suprimentos de recursos para o
projeto.
Definir o cronograma de aquisição e liberação de recursos e serviços para o
projeto.
Especificar os recursos e serviços a serem adquiridos.
Para a elaboração do plano de risco, devemos considerar os seguintes requisitos:

Quadro 6 - Requisitos para Plano Auxiliar de Risco
Estruturar o time que irá desenvolver o Plano de Gerenciamento de Risco.

Identificar os riscos do projeto e tolerância ao risco dos stakeholders.
Determinar os sintomas ou avisos de que um risco pode vir a ocorrer.
Avaliar qualitativamente cada risco identificado em termos da probabilidade de
ocorrência e de seu impacto em custo, prazo, escopo e qualidade.
Organizar o risco pela ordem de importância.
Quantificar os riscos e verificar, no caso de sua ocorrência, seu impacto no atraso
do cronograma e no aumento do custo.
Determinar a probabilidade de atendimento aos objetivos do projeto em termos
de prazo, custo, escopo e qualidade conforme as probabilidades de ocorrência
dos riscos.
Determinar para cada risco identificado, estratégias de resposta ao risco.
Determinar as ações para cada estratégia de resposta ao risco.
Estimar orçamento para a implantação das respostas ao risco.
Identificar o “dono” do risco e atribuir responsabilidades.
Determinar reservas de contingência para o plano do projeto.
Documentar o plano.
Para a elaboração do plano de Comunicação, devemos considerar os seguin-

tes requisitos:

206 UNIDADE V
Quadro 7 - Requisitos para Plano Auxiliar de comunicação
Identificar e designar responsáveis pela elaboração, gestão e execução do plano

da comunicação.
Definir a audiência de recebimento de informação sobre o desempenho do
projeto.
Definir os requisitos de informação da audiência (quais informações, nível de
agregação, tipo do formato da informação etc.).
Consolidar os requisitos de informação da audiência em documentos (relatórios
etc.).
Desenvolver os template dos documentos.
Definir a frequência de distribuição da informação.
Definir como as informações serão obtidas e tratadas.
Definir os métodos de acesso aos documentos.
Definir o método de distribuição da informação.
Definir os privilégios de acesso.
Definir os eventos de disparos dos documentos e da comunicação.
ELABORAÇÃO DO CRONOGRAMA DO PROJETO E ORÇAMENTO

DE CUSTO DO PROJETO
Com base nas estimativas de prazos e recursos, o cronograma do projeto é elabo-

rado e, de acordo com Fernandes e Teixeira (2011), consideram-se os seguintes
pontos:
■■ Utilizar calendário para estabelecer datas de início e fim, considerando
as premissas das estimativas dos prazos;
■■ Para cada atividade devem-se aplicar as datas de início e fim e verificar o
prazo total previsto para o projeto;
■■ Verificar as imposições ao usar os recursos;
■■ Produzir uma nova versão do cronograma ao realizar nivelamentos dos
recursos;

207
■■ Avaliar se o cronograma atende às necessidades e expectativas dos

stakeholders;
■■ Fazer várias simulações (quantas julgar necessárias);
■■ Para o estabelecimento da data de início efetivo do projeto, criar o base-
line do cronograma.
Com relação ao orçamento de custo do projeto, Fernandes e Teixeira argumen-

tam que:
[...] o orçamento de custo envolve a alocação de todos os custos es-
timados a cada uma das atividades ou “pacotes de trabalho”, visando

estabelecer um baseline para a mediação do desempenho do projeto. O
baseline de custo é o custo esperado ou estimado para que o projeto seja
completado. O baseline de custo tem como base o orçamento de recur-
sos atualizado, após a elaboração dos planos auxiliares, pois os mesmos
podem requerer recursos. Um dos aspectos mais importantes para a
elaboração do baseline é considerar também a reserva de contingência
em termos monetários em função dos resultados do plano de riscosd.
(FERNANDES; TEIXEIRA, 2011, p. 293).
O baseline deve fornecer a previsão de despesas do projeto, conforme o tempo

de duração total para o projeto. O Fluxo de Desembolso pode ser usado, neste
caso, para que a gestão do fluxo de caixa do projeto monitore a realização do
retorno do investimento.
CRITÉRIOS PARA O CONTROLE DO CRONOGRAMA, CUSTO E

ESCOPO
Ao planejar o projeto, devemos definir os critérios para o controle das mudanças

relativas ao: cronograma, custo e escopo e, ainda, determinar em quais situações o
baseline do cronograma, do custo e do escopo podem ser alterados (FERNANDES;
TEIXEIRA, 2011). Durante a execução do projeto, alguns eventos devem ser moni-
torados para avaliar a necessidade de mudança dos baselines, como, por exemplo:
■■ Escopo do projeto: os principais eventos que fazem com que o escopo
mude são os riscos que ocorrem. O usuário pode alterar o escopo e pro-
vocar novas restrições ao verificar o escopo.

208 UNIDADE V
■■ Cronograma: os principais eventos que influenciam no cronograma são

os relativos ao monitoramento de riscos, à mudança do escopo, ao con-
trole da qualidade e aos atrasos do projeto.
■■ Custo: os principais eventos que alteram o custo são as mudanças de cro-
nograma, monitoramento do risco, mudanças de escopo e aos atrasos na
entrega do projeto.
■■ Toda e qualquer mudança: deve ser verificada e analisada quanto ao seu
impacto no projeto.
PLANO DO PROJETO DA FÁBRICA DE SOFTWARE
O Plano de Projeto, segundo Fernandes e Teixeira (2011, p. 294), “é a consolida-

ção de todos os documentos gerados no processo de planejamento”. Para isso, é
necessário organizar o plano do projeto conforme o conteúdo e os anexos que
podem ser utilizados (Quadro 8).
Quadro 8 - Conteúdos do Plano de Projeto da Fábrica
CONTEÚDO
Título do projeto
Escopo do projeto
WBS do projeto
Estratégia de desenvolvimento
Cronograma mestre e milestones
Orçamento de custo
Organização da gestão do projeto
Riscos do projeto
Respostas aos riscos
Retornos do investimento

209
ANEXOS
Plano de gerenciamento do escopo
Plano de gerenciamento do cronograma
Plano de gerenciamento do custo
Plano de gerenciamento da qualidade
Plano de gerenciamento da aquisição
Plano de gerenciamento da comunicação
Plano organizacional
Plano de gerenciamento do risco

Plano da configuração
Outros materiais


210 UNIDADE V
GERENCIAMENTO DA IMPLANTAÇÃO DA FÁBRICA
DE SOFTWARE
A base para o gerenciamento da implantação é o plano do projeto e seus respec-

tivos planos auxiliares. Sobre o gerenciamento, Fernandes e Teixeira argumentam
que:
[...] em um projeto de implementação de Fábrica de Software, como em
qualquer projeto, quatro objetivos devem ser perseguidos, quais sejam:
completar o projeto no prazo, no custo, na qualidade e dentro do esco-
po. Esses quatro objetivos são os indicados de sucesso de um projeto.
Geralmente adicionamos mais um, que é a adoção do resultado do pro-
jeto pelos stakeholders que o demandaram (FERNANDES; TEIXEIRA,
2011, p. 295).
Alguns processos de controle são requeridos para a execução do gerenciamento

do projeto: verificação do escopo, controle da mudança do escopo, controle do
cronograma, controle do custo, quality assurance, controle da qualidade, con-
trole do risco, controle da mudança e gerenciamento integrado.

211
Quadro 9 - Processos de controle
VERIFICAÇÃO DO ESCOPO
Obter a aceitação formal do escopo do projeto pelos stakeholders.
Rever os produtos previstos, visando verificar se estão aderentes aos requisitos
funcionais e não funcionais requeridos.
Medir o progresso da entrega do escopo.
Identificar mudanças que devem ser feitas no escopo.
Registrar os defeitos do produto no não atendimento aos requisitos funcionais e
não funcionais do projeto.
CONTROLE DA MUDANÇA DO ESCOPO

Fazer com que os stakeholders estejam de acordo com as mudanças.
Determinar que uma mudança ocorreu.
Gerenciar a mudança quando ela ocorrer.
Acompanhar o processamento da mudança.
Assegurar a atualização do escopo.
CONTROLE DO CRONOGRAMA
Assegurar a atualização do cronograma mestre.
CONTROLE DO CUSTO
Assegurar a atualização do baseline do orçamento de custo.
QUALITY ASSURANCE
Determinar a conformidade dos processos de planejamento do projeto, da ges-
tão do projeto e de sua execução.
Verificar e validar os processos.
Gerar relatórios de não conformidades.
Acompanhar a solução das não conformidades.
CONTROLE DE QUALIDADE
Determinar a conformidade dos produtos previstos pelo projeto às especifica-
ções técnicas do projeto e de engenharia de construção dos produtos.
Verificar e validar produtos intermediários e finais.
Acompanhar a solução das não conformidades.
Gerenciamento da Implantação da Fábrica de Software

212 UNIDADE V
CONTROLE DO RISCO
Determinar se as respostas ao risco foram implementadas.
Determinar se as respostas ao risco são efetivas, ou se novas respostas devem ser
desenvolvidas.
Determinar se as premissas do projeto ainda são válidas.
Determinar se a exposição ao risco mudou.
Determinar se um risco está ocorrendo.
Determinar se a política e os procedimentos estão sendo seguidos.
Determinar novos riscos.
CONTROLE DA MUDANÇA
Acolher solicitações de mudança a serem avaliadas.
Avaliar o impacto das mudanças solicitadas.
Submeter as mudanças para as aprovações.
Efetivar as mudanças aprovadas.
Acompanhar atualizações requeridas no plano do projeto em função das mu-
danças aprovadas.
GERENCIAMENTO INTEGRADO
Prazos.
Custos.
Atendimento ao escopo.
Problemas e incidentes.
Desempenho do plano da qualidade.
Desempenho do plano de aquisição.
Desempenho do plano organizacional.
Desempenho do plano de qualidade.
Desempenho do plano de risco.
Controle de mudanças.

213
Prezado(a) aluno(a)! Chegamos ao final da última unidade do nosso livro.

Aprendemos nesta unidade sobre a implantação de uma Fábrica de Software,
seus conceitos e estratégias.
Esperamos que a partir do conhecimento adquirido nas unidades, você
procure pesquisar mais, estudar mais, além do que foi visto no livro, pois sem-
pre surgem novas estratégias, novos conceitos para uma melhoria contínua do
trabalho.
Aprendemos, também, sobre as Estratégias da Implantação da Fábrica de

Software, como escolher as estratégias para a implantação e como utilizá-las no
desenvolvimento do projeto de implementação e na sua execução.
Conhecemos como fazer e o que usar no Planejamento da Implantação da
Fábrica de Software e como ele é constituído por especificações técnicas e pela
estratégia de desenvolvimento.
Falamos sobre WBS do Projeto de Fábrica de Software, que é um processo
de subdivisão das entregas e do trabalho do projeto em componentes meno-
res e mais facilmente gerenciáveis. Aprendemos também como Gerenciar a
Implantação da Fábrica de Software. A base para o gerenciamento da implanta-
ção é o plano do projeto e seus respectivos planos auxiliares. Aprendemos que
o Plano de Projeto é a consolidação de todos os documentos gerados no pro-
cesso de planejamento da fábrica. Conhecemos os processos de controle que são
requeridos para a execução do gerenciamento do projeto, como: verificação do
escopo, controle da mudança do escopo, controle do cronograma, controle do
custo, quality assurance, controle da qualidade, controle do risco, controle da
mudança e gerenciamento integrado.
Lembre-se: coloque em prática o que aprendeu ao longo do livro, estude,
pratique, pesquise e procure sempre testar diferentes abordagens, até encontrar
a que funciona melhor para você, sua equipe e seus clientes.
Desejo sucesso em todos os seus projetos!
214
1. Vimos que, conforme Fernandes e Teixeira (2011), é crucial para o sucesso da

empresa a estratégia de desenvolvimento do projeto de implementação, pois
o detalhamento do planejamento do projeto de implementação depende da
estratégia. Com base nesta informação, descreva o que a estratégia de de-
senvolvimento do projeto de implementação define e depende.
2. A estratégia de desenvolvimento do projeto de implementação determina o
meio pelo qual vamos desenvolver o planejamento e sua execução, consideran-
do alguns aspectos importantes. Sobre isso, assinale a alternativa correta.
I) Como será a estruturação dos deliverables do WBS e qual será o Ciclo de Vida
adotado para o projeto?
II) A estratégia de desenvolvimento vai ser de toda a fábrica e como será o plano
de qualidade do projeto?
III) Os fornecedores de tecnologia irão participar ativamente do projeto? Como
será o plano de risco?
IV) Qual a estratégia de entrega dos produtos ou das funcionalidades requeri-
das? Como será a construção arquitetônica da Fábrica de Software?
V) Como será a estrutura organizacional do projeto e como será a comunicação
do projeto?
c) Somente as afirmativas I, II e III, V estão corretas.
215
3. Segundo Fernandes e Teixeira (2011), as estimativas de prazos e de recursos para

o projeto estão intimamente interligadas. Com base nesta informação, com-
plete as lacunas corretamente:
As ___________________ é o processo de obter informação sobre o
__________________________e desenvolver as durações das atividades, vi-
sando subsidiar a elaboração do cronograma. As _____________________,
por sua vez, envolve a determinação de quais _______________ (pessoas,
equipamentos, materiais e serviços) e sua respectiva quantidade serão neces-
sários para o desempenho do projeto.
a) Estimativas de recursos, escopo e recursos, estimativas de prazo, recursos.
b) Estimativas de prazo, escopo e recursos, estimativas de recursos, prazos.
c) Estimativas de prazo, escopo e recursos, estimativas de recursos, recursos.
d) Estimativas de recursos, escopo e recursos, estimativas de recursos, recursos.
e) Estimativas de prazo, escopo e prazos, estimativas de recursos, recursos.
4. Aprendemos algumas técnicas para os projetos, como, por exemplo, a Técnica
dos Três Pontos. Esta técnica supõe que a duração da tarefa é algo aleatório,
mesmo considerando as mesmas condições de projeto. Assinale a alternativa
correta que mostra a fórmula correta para a determinação da duração da
tarefa:
a) E = EM + 4EO + EP/6
b) E = EO + 6EM + EP/4
c) E = EO + 4EM - EP/6
d) E = EO - 4EM + EP/6
e) E = EO + 4EM + EP/6
5. Vimos algumas técnicas usadas nos projeto, entre elas a Técnica Delphi e a Téc-
nica de Três Pontos. Analise e descreve a diferença entre estas técnicas e se
entre as demais técnicas estudadas tem alguma que combina estas duas
técnicas.
216
As Fábricas de Software no Mundo

Um dos principais modelos de negócio para uma fábrica de software, principalmente
no exterior, é a exportação. Vários países são considerados grandes exportadores de sof-
tware, e muitos outros tentam alcançar competitividade neste mercado. Carmel (2003)
divide estes países em quatro níveis, levando em consideração três aspectos: maturida-
de da indústria; quantidade de organizações e o total de exportações. Assim, para o país
se enquadrar em cada nível, a indústria de desenvolvimento de software precisa ter:
• Nível 1: mais de 15 anos, centenas de empresas e no mínimo 1 bilhão de dólares em
exportação de software. Exemplo de países neste nível: Estados Unidos, Canadá, Reino
Unido, Alemanha, França, Bélgica, Holanda, Suécia, Finlândia, Japão, Suíça, Austrália, Ir-
landa, Israel e Índia.
• Nível 2: mais de 10 anos, pelo menos 100 empresas e no mínimo 200 milhões de dó-
lares em exportação de software. Exemplo de países neste nível: Apenas a Rússia e a
China.
• Nível 3: mais de 5 anos, algumas dezenas de empresas e no mínimo 25 milhões de dó-
lares exportados. Exemplo de países neste nível: Brasil, Costa Rica, México, Filipinas, Ma-
lásia, Sri-Lanka, Coréia, Paquistão, Romênia, Bulgária, Ucrânia, Polônia, República Tcheca,
Hungria, Estônia, Latvia, Lituânia, Eslovênia, Chile, Argentina, Tailândia e África do Sul.
• Nível 4: países que estão começando a amadurecer sua indústria de desenvolvimento
de software, e possuem alguma exportação. Exemplo de países neste nível: Cuba, El
Salvador, Jordânia, Egito, Bangladesh, Vietnã, Indonésia, Iran e algumas outras nações
que não possuem dados disponíveis. Um exemplo em especial merece ser citado é o da
Índia. Seu sucesso na área de exportação de software a colocou rapidamente no mesmo
patamar dos países mais desenvolvidos neste critério.
Carmel (2003) cita oito fatores para o sucesso nesta área, o que ele chama de “Modelo
Oval”:
1. Visão e políticas governamentais, incluindo benefício em impostos e fundos de de-
senvolvimento.
2. Capital humano, incluindo a orientação e tradição do país, a quantidade, a composi-
ção, o conhecimento de línguas e a capacidade gerencial.
3. Remuneração.
4. Qualidade de vida.
217
5. Afinidades entre indivíduos, grupos de trabalho, entre empresas e entre países, por
razões geográficas, culturais, linguísticas ou étnicas.
6. Infraestrutura tecnológica.
7. Fontes externas ou internas de capital.
8. Características da indústria, incluindo efeitos de clusters, número de empresas, o ta-
manho dessas empresas, as associações que organizam estas firmas, as marcas e os pa-
drões que as empresas buscam alcançar.
Perspectiva para as Fábricas de Software no Brasil.
Grandes empresas de tecnologia têm distribuído seus centros de produção de softwa-
re em países onde seja possível reduzir custos e aumentar a competitividade. Por este
motivo, o Brasil também tem atraído empresas estrangeiras do ramo. O investimento
externo proporciona o surgimento de parques tecnológicos, que surgem por meio de
associações de empresas com universidades e órgãos governamentais. O crescimento
de um ambiente de pesquisa científica e desenvolvimento tecnológico como este é ex-
tremamente benéfico para o país. Bastos (2012) constatou que a isenção fiscal foi o prin-
cipal fator para atrair investimentos de grandes empresas multinacionais de tecnologia
para o país, como a americana IBM, que hoje possui umas das mais modernas fábricas de
software do país. Desta forma, é importante incluir esta estratégia no planejamento que
visa o aumento da competitividade do país, mantendo os investimentos já realizados e
atraindo novos.
Em termos gerais, a Indústria Brasileira de TI está posicionada em 7º lugar no ranking
mundial, com um investimento de US$ 60 bilhões em 2014. O estudo aponta que o
Brasil é o 1º lugar no ranking de investimentos no setor de TI na América Latina, re-
presentando 46% desse mercado que, só em 2014, somou US$ 128 bilhões. Um fato a
se considerar é a ainda baixa representação das exportações no mercado de software
nacional, cerca de 2%, ou US$225 milhões, segundo estudo publicado em 2014, pela
ABES (Associação Brasileira das Empresas de Software), o que pode indicar uma boa
oportunidade para as Fábricas de Software nacionais.
Fonte: Romanha (2016).
Gestão por Processos: Fundamentos, Técnicas e

Modelos de Implementação
Saulo Barbará
Editora: QualityMark
Sinopse: tentar corrigir erros ou solucionar problemas em curto
espaço de tempo é um equívoco muitas vezes cometido. O
livro organizado por Saulo Barbará mostra um caminho em que
a aplicação da Gestão da Qualidade na empresa anda junto à
cadeia produtiva, tendo por objetivo uma melhoria contínua da
qualidade e sua correspondente gestão por processos, a partir
dos processos organizadores e suas formas de modelo e gestão.
Embasada no conceito de administração científica de Taylor, a obra
é uma excelente fonte de consulta para profissionais, professores
e estudantes de administração, gestão de qualidade, engenharia de
produção, engenharia de software e para todos que quiserem se familiarizar com uma maneira mais
eficaz de gerenciar qualquer negócio, além de entender e praticar a gestão por processos.
Tecnologia da Informação Aplicada a Sistemas de

Informação Empresariais
Denis Alcides Rezende, Aline França de Abreu
Editora: Atlas
Sinopse: relata conceitos, metodologias e modelos aplicados
a sistemas de informação (nos níveis operacional, gerencial e
estratégico) que contribuem com as organizações (privadas
e públicas) nas atividades de concepção, desenvolvimento e
implantação de projetos de sistemas, gestão de informações e
gestão de informática. O objetivo principal do livro é descrever
como as informações e os conhecimentos podem contribuir
nos processos decisórios dos gestores e clientes (usuários
de informática) que, para realizar suas atividades, utilizam as
emergentes tecnologias disponíveis no mercado, tais como softwares ERP, BI, SAD e EIS, Banco de
Dados, Data Warehouse, Inteligência Artificial, Data Mining, Sistemas de Telecomunicação, Internet
e outras. Está transcrita nesta obra grande parte da experiência em informática e em gestão da
tecnologia da informação dos autores, adquirida desde 1980 nas pesquisas acadêmicas, em sala de
aula e nos trabalhos de consultoria em diferentes empresas. O livro está dividido em cinco partes:
Empresa e sistemas; Tecnologia da informação; Papel estratégico da informação e dos sistemas de
informação nas empresas; Processo de desenvolvimento e de implantação de sistemas de informação
empresariais; Integração, alinhamento, qualidade e divulgação da informação, do conhecimento e da
inteligência nas organizações.
Implantação de softwares ERP

Artigo que fala sobre a implantação de software. A implementação de softwares nas empresas
pode ser feita por meio de desenvolvimento próprio, pela contratação de terceiros ou pela
compra de pacotes de softwares disponíveis no mercado. Para saber mais, acesse o link disponível
em: <http://www.linhadecodigo.com.br/artigo/2487/implantacao-de-softwares-erp.aspx>.
Desafios na implantação de um software de gestão

Artigo muito interessante que fala dos desafios enfrentados na implantação de
um software de gestão independentemente do porte da empresa. Para saber
mais, acesse o link disponível em: <https://www.ecommercebrasil.com.br/artigos/
desafios-na-implantacao-de-um-software-de-gestao/>.
Para que serve um plano de projeto de implantação de um software ERP

Artigo que fala sobre para que serve um plano de projeto de implantação de um software
ERP e sobre a implantação de um novo sistema em uma fábrica. Fique por dentro do assunto
acessando o link disponível em: <http://www.nomus.com.br/blog-industrial/2016/09/
para-que-serve-um-plano-de-projeto-de-implantacao-de-um-software-erp/>.
Como superar as principais dificuldades na implantação de um sistema de PCP/

ERP em uma fábrica
Artigo interessante que mostra como superar as principais dificuldades
encontradas na implantação de um sistema em uma fábrica. Para saber mais,
acesse o link disponível em: <http://www.nomus.com.br/blog-industrial/2016/03/
principais-dificuldades-na-implantacao-de-um-sistema-de-pcperp/>.
REFERÊNCIAS

ROMANHA, Silas Dias. Um Modelo de Fábrica de Software em Instituições de En-
sino Superior, Guaratinguetá, 2016.
ROZADOS, Helen Beatriz Frota. O uso da técnica Delphi como alternativa metodoló-
gica para a área da Ciência da Informação. Em Questão, Porto Alegre, v. 21, n. 3, p.
64-86, set/dez. 2015.
SIQUEIRA, Rodrigo George Piubello. Planejamento de Escopo de Projetos: o Caso
de uma Consultoria. Juiz de Fora: UFJF, 2007.
TENÓRIO, Fernando Guilherme; VALLE, Rogerio. Fábrica de Software. Rio de Janei-
REFERÊNCIA ON-LINE
Em: <https://pt.wikipedia.org/wiki/PERT#/media/File:Pert_chart_colored.gif>.
1
Acesso em: 07 dez. 2017.

221
GABARITO
1. A estratégia define como vamos estruturar o Work Breakdown Structure (WBS)

do projeto (os produtos a serem entregues ao longo do projeto), qual vai ser o
ciclo de vida a ser adotado para o projeto, qual a melhor sequência das ativi-
dades, como os fornecedores de opinião vão ser envolvidos, e assim sucessiva-
mente. A estratégia depende muito da complexidade do projeto, considerando
seu porte e risco. Quanto maior a complexidade do projeto, mais importante é a
definição da estratégia de desenvolvimento do projeto. A estratégia tem como
missão principal a redução da complexidade do projeto.
2. Alternativa C.
3. Alternativa C.
4. Alternativa E.
5. A Técnica Delphi produz estimativas adequadas quando temos ausência de
conhecimento especialista externo, e a Técnica dos Três Pontos supõe que a
duração da tarefa é algo aleatório, mesmo considerando as mesmas condições
de projeto. A Técnica Delphi Ampliada combina a técnica Delphi com a técnica
de Três Pontos. Assim, em vez de uma estimativa, os membros da equipe fazem
três estimativas e depois são feitas as médias para as três estimativas que são
aplicadas na fórmula para a determinação da duração da atividade.
CONCLUSÃO
Caro(a) aluno(a), assim terminamos nossa jornada. Foram cinco unidades da disci-
plina de Tópicos Especiais em Engenharia de Software I. Espero que sua leitura te-
nha sido agradável e que o conteúdo visto tenha contribuído para seu crescimento
pessoal e profissional.
Inicialmente, na primeira unidade, falamos sobre as Fábricas de Software, apresen-
tamos um panorama geral do paradigma, seus conceitos e tipos de software, que
podem ser desenvolvidos em uma Fábrica de Software.
Na Unidade II, vimos uma visão geral da Fábrica de Software e como funciona a es-
trutura organizacional dos vários modelos, como: a Fábrica Orientada a Processos, a
Fábrica Orientada a Produtos, a Fábrica de Projetos e a Fábrica de Programas.
Na sequência, estudamos, na Unidade III, os outros modelos de Fábrica de Softwa-
re, como: Linha de Produto de Software, Fábrica de Testes de Software, Fábrica de
Componentes e o Modelo de Outsourcing de Sistemas. Apresentamos os conceitos
básicos e os princípios sobre a Linha de Produto de Software (LPS).
A Unidade IV tem por finalidade mostrar como aplicar os modelos de Fábrica de
software. Aprendemos os conceitos sobre Fábrica Virtual de Software, como aplicar
os modelos de Fábrica de Software In-house e Fábrica de Software Offshore e os
modelos de melhores práticas e certificações, além de como estruturar operações
de Fábrica de Software Offshore e conhecemos os principais requisitos técnicos e
comerciais que são utilizados nestes modelos.
E, por fim, na Unidade V aprendemos sobre as estratégias da Implantação da Fábrica
de Software, como escolher as estratégias para a implantação e como utilizá-las no
desenvolvimento do projeto de implementação e na sua execução. Aprendemos
como fazer o Planejamento da Implantação da Fábrica de Software e como ele é
constituído por especificações técnicas e pela estratégia de desenvolvimento.
Espero que você coloque em prática tudo o que aprendeu ao longo das unidades e
continue estudando, praticando e pesquisando. Assim, não pare por aqui! Desejo a
você muito sucesso, sempre!

Topicos Especiais em Engenharia de Software

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Topicos Especiais em Engenharia de Software

Diunggah oleh

Hak Cipta:

Format Tersedia

TÓPICOS

Professora Esp. Janaina Aparecida de Freitas

NEAD - Núcleo de Educação a Distância

Ficha catalográfica elaborada pelo bibliotecário

Professora Esp. Janaina Aparecida de Freitas

TÓPICOS ESPECIAIS EM ENGENHARIA

VISÃO GERAL DA FÁBRICA DE SOFTWARE

16 Paradigma da Fábrica de Software

21 O Que É Fábrica De Software?

30 Tipos de Softwares Desenvolvidos na Fábrica de Software

33 Frameworks Organizacionais de Fábrica de Software

37 Decisões Acerca da Estrutura Organizacional da Fábrica de Software

MODELOS DE FÁBRICAS DE SOFTWARE

54 Visão Geral da Fábrica de Software

64 Fábrica de Software Baseada em Processos

71 Fábrica de Software Baseada em Produtos

84 Fábrica de Programas de Software

OUTROS MODELOS DE FÁBRICA DE SOFTWARE

102 Linha de produtos de software

115 Fábrica De Testes De Software

123 Fábrica de Componentes

126 Modelo de Outsourcing de Sistemas

135 Considerações Finais

APLICANDO OS MODELOS DE FÁBRICA DE SOFTWARE

148 Virtualizando a Fábrica de Software

151 Como Aplicar os Modelos de Fábrica de Software In-House

156 Aplicação da Fábrica de Programas In-House

158 Fábrica de Software e Modelos de Melhores Práticas e Certificações

166 Estruturando Operações de Fábrica de Software Offshore

172 Requisitos Técnicos e Comerciais Para Estruturar uma Operação Offshore

175 Considerações Finais

IMPLANTANDO A FÁBRICA DE SOFTWARE

188 Estratégia da Implantação da Fábrica de Software

194 Planejamento da Implantação da Fábrica de Software

196 WBS do Projeto de Fábrica de Software

210 Gerenciamento da Implantação da Fábrica de Software

213 Considerações Finais

VISÃO GERAL DA FÁBRICA

Quando pensamos em tecnologias, é profundamente interessante falar sobre com-

VISÃO GERAL DA FÁBRICA DE SOFTWARE

Um crescente número de empresas que estão no negócio de software tem

“Fábrica” ao mero desenvolvimento de software, sem a preocupação

Contudo, para falar sobre o paradigma da fábrica de software é preciso conhe-

Caracteriza-se o fordismo como sendo um método de organização da produ-

Paradigma da Fábrica de Software

alguns conceitos de engenharia associados à manufatura. Ainda conforme os

O desafio da Engenharia de Software é construir softwares que atendam às neces-

VISÃO GERAL DA FÁBRICA DE SOFTWARE

estruturadas e a componentização, que equivalem a uma “fordização” da fabri-

Paradigma da Fábrica de Software

Para entendermos as abordagens sobre o conceito de fábrica de software e a sua evolu-

Para Tenório e Valle (2012), há uma analogia entre a introdução de processos de

VISÃO GERAL DA FÁBRICA DE SOFTWARE

Então, podemos pensar que todo o esforço de implementar uma operação

O QUE É FÁBRICA DE SOFTWARE?

O Que É Fábrica de Software?

O conceito de Fábrica de software, conforme Fernandes e Teixeira (2011, p.

VISÃO GERAL DA FÁBRICA DE SOFTWARE

Modelo Europeu: foco na integração de ambientes de desenvolvimento de sof-

cesso, pesquisa e desenvolvimento centralizados de processo, reusabilidade e

A implementação da melhoria por meio da experiência é intensa, exige que a

O Que É Fábrica de Software?

[...] associando o conceito de maturidade pregado neste modelo à re-

16 Paradigma da Fábrica de Software

21 O Que É Fábrica De Software?

30 Tipos de Softwares Desenvolvidos na Fábrica de Software

33 Frameworks Organizacionais de Fábrica de Software

37 Decisões Acerca da Estrutura Organizacional da Fábrica de Software

54 Visão Geral da Fábrica de Software

64 Fábrica de Software Baseada em Processos

71 Fábrica de Software Baseada em Produtos

84 Fábrica de Programas de Software

102 Linha de produtos de software

115 Fábrica De Testes De Software

123 Fábrica de Componentes

126 Modelo de Outsourcing de Sistemas

135 Considerações Finais

148 Virtualizando a Fábrica de Software

151 Como Aplicar os Modelos de Fábrica de Software In-House

156 Aplicação da Fábrica de Programas In-House

158 Fábrica de Software e Modelos de Melhores Práticas e Certificações

166 Estruturando Operações de Fábrica de Software Offshore

172 Requisitos Técnicos e Comerciais Para Estruturar uma Operação Offshore

175 Considerações Finais

188 Estratégia da Implantação da Fábrica de Software

194 Planejamento da Implantação da Fábrica de Software

196 WBS do Projeto de Fábrica de Software

210 Gerenciamento da Implantação da Fábrica de Software

213 Considerações Finais