Desenvolvimento de fábrica de software

VI Simpósio Internacional de Melhoria de São Paulo, SP – Brasil 24-26/11/2004
Processos de Software www.simpros.com.br
Desenvolvimento e Replicação de Uma

Fábrica de Software
José Augusto Fabri Alexandre L’Erário

André Luiz Presende Trindade Marcelo S. de Paula Pessôa
Mauro de Mesquita Spínola
Eng. de Produção
Tópicos desse Tutorial

• Envolvidos
• Introdução ao Tema
• O Processo Fabril
• Fábricas de Software (Definições)
• Implementando uma Fábrica de Software
• Replicando uma Fábrica de Software
• Conclusão
• Referências bibliográficas
3-1
Envolvidos
• Fundação Educacional do Município de Assis.
– Objetivos: Formar mão de obra qualificada nas mais variadas áreas do

conhecimento.
– Conta com 09 cursos superiores, entre eles o curso de Ciência da

Computação e Tecnologia em Processamento de Dados.
• Área de Computação:
– 15 professores.
– 300 alunos.
– Pesquisa (curso de graduação e pós-graduação)
• Engenharia de Software, Teoria da Computação, Informática Aplicada
ao Ensino e Inteligência Artificial
Envolvidos
• Centro de Pesquisas em Informática (CEPEIN)
– Unidade de opera junto a FEMA.
– Objetivo:
• Agregar as atividade de pesquisas na área de computação em
informática.
• Prestar serviço de desenvolvimento software e projetos de TI junto ao
poder público.
3-2
Envolvidos
• Departamento de Engenharia de Produção da Escola Politécnica da

Universidade de São Paulo.
• Primeiro Departamento de Engenharia de Produção do País.
– 45 professores.
– 450 alunos de graduação.
– 200 alunos de pós graduação
Envolvidos
• Grupos de Pesquisas:
– GOL: Grupo de Gestão de Operações Logísticas
– TTO: Tecnologia Trabalho e Organização
– QEP: Qualidade em Engenharia do Produto
– EPEF: Economia da Produção e Engenharia Financeira
– GTI: Gestão em Tecnologia da Informação
3-3
Envolvidos
• GTI:
– Objetivos: Planejar o desenvolvimento e implantação de Sistemas e

ativos relacionados a TI.
– Atualmente conta com 30 alunos de pós-graduação.
– Destaque para área de qualidade de software com mais de 15

dissertações e teses concluídas
Envolvidos
• Fundação Vanzolini:
– Formada em 1967 pelos professores do Departamento de Engenharia de

Produção da Escola Politécnica.
– Entidades sem fins lucrativos que opera em convênio com a universidade

de São Paulo.
– Objetivos: Divulgar conhecimento científicos e tecnológicos inerentes à

área de Engenharia de Produção e à Administração Industrial.
– Produtos:
• Treinamento; Certificações; Assessoria; Projeto
3-4
Introdução ao Tema
• Fábrica de Software: Utilizado pela primeira vez no Japão em 1969.
Várias empresas associam o termo

FÁBRICA DE SOFTWARE
ao mero desenvolvimento
de software
• Características fabris para software (Segundo Cusumano):
– Produção de Software em Massa e em Larga Escala.
– Padronização e controle de tarefas.
– Divisão do Trabalho
– Mecanização e Automatização
– Desenvolvimento de software baseados em Componentes.
– Gerenciamento das atividades por projeto e por processo.
3-5
• Pesquisa:
– 31 Fábricas
– Empresas Nacionais e Multinacionais.
• Resultados:
– Certificação (ISO ou CMM): 14%
– Opera como célula do cliente: 16%
– Ciclo de vida definido: 42%
– Metodologia própria: 45%
– Usa software de controle de projetos: 16%
– Usa ferramentas CASE (automação): 13%
– Aplica métricas de qualidade: 10%
Fonte (Ivanir Costa)
• Relatório do MCT (2001)
– Desenvolvedores com ferramentas de automação: 30%

– Processo formal documentado: 30%
– Certificado ISO : 29%
– Avaliação CMM: 02%
– Uso de gerência da configuração: 10%
– Brasil importa dez vezes o que exporta em Software

gerando assim um déficit de 1 BiUS$
Gazeta Mercantil (ago2002)
3-6
• Modelos tradicionais de desenvolvimento de software se auto-
denominam fábrica. Puro marketing.
• Enfim, há muito o que fazer para solucionar esse problema e alavancar

as exportações no mercado internacional de software.
O que fazer então?
Formalizar o
Conscientizar conceito de FS
o mercado para realidade
brasileira
Prover técnicas de
replicação
de FS para o mercado
Quem pode fazer isso?
Universidades
Governo empresas
3-7
Como fazer?
Desenvolvendo um
mecanismo de replicação
de técnicas fabris
Medida adotada pelos envolvidos no projeto

eLabTI – Um ambiente replicável de FS
O Processo Fabril
• Henry Ford
“Construirei um carro para as grandes massas, feito com os melhores

materiais, pelos melhores homens que puderem ser contratados e
seguindo os projetos mais simples que a moderna engenharia pode
conceber [...] de preço tão baixo que qualquer homem que ganhe um
bom salário seja capaz de possuir – e desfrutar com sua família a
bênção das horas de prazer nos grandes espaços abertos da natureza”
– declaração de Henry Ford no início de carreira como produtor de
carros (Tedlow 2002).
3-8
O Processo Fabril
• Adaptação da citação de Henry Ford (Utopia?)
Replicaremos uma série de entidades que produzirá softwares para as “grandes

massas empresariais”, feito com os melhores componentes e seguindo
projetos mais simples que a moderna engenharia de software possa conceber.
O preço do software deve ser baixo que qualquer empresa que tenha um
rendimento condizente com a realidade possa crescer utilizando um software
que supra as suas necessidades e esteja alinhado com a sua estratégia
O Processo Fabril
• Em 1910 foi inaugurada a fábrica de Highlang Park (uma fábrica que produzia
um modelo complexo como Ford T).
• Produção em fluxo sem interrupção (idéia desenvolvida por Henry Ford).
• A decisão de fixar-se num só modelo (T) permitiu que os projetistas

especificassem e produzissem equipamentos dedicados esse tipo de modelo
(Isso não funciona para software)
• 1913 – mudança no processo de produção do Ford T – aumento drástico da

produtividade.
3-9
O Processo Fabril
• Principal mudança:
– os produtos a serem montados agora fluiriam de estação de trabalho em estação de
trabalho, indo ao encontro dos montadores, e não ao contrário. Estava criada a linha
de montagem móvel (Corrêa 2003).
• Henry Ford apresentou ao mundo a união dos princípios da:

– Administração científica -
• Divisão do trabalho;
• Escolha do trabalhador certo para a tarefa certa.
– Intercambialidade de peças (desenvolvida por Eli Whitney (Hounshell

1984)).
– Princípio da Padronização dos Produtos –
• e a idéia de fazer produtos moverem-se enquanto estações de trabalho ficavam
estáticas.
O Processo Fabril
“Antes da implementação da linha de montagem, um chassi levava 12 horas e 28
minutos para ser montado. Na primavera de 1914 a tarefa podia ser feita em 1
hora e 33 minutos.” (Corrêa 2003)
• Em 1926 a Ford produzia sozinha em torno de 2 milhões de carros por ano

(Corrêa 2003).
3 - 10
O Processo Fabril
• Por volta de 1910 surgiu a GM.
• A GM possuia sete linhas veículos.

– Chevrolet
– Oakland
– Olds
– Scripps-Booths
– Sheridam
– Buick
– Cadillac
• Destes carros o Buick tinha preço médio/alto e o Cadillac possuía um conceito luxuoso
e altos preços (Sloan JR. 2001).
O Processo Fabril
• Problema enfrentado pela GM

– O Ford T era 300 US$ mais barato que o GM Chevrolet
– 1920 - GM apenas com 17% do mercado
– 1921 – índice baixou para 12%
• Estratégia da GM para reverter o quadro:

– introduzir uma linha de montagem de veículos para cada segmento da
sociedade, diversificando assim os preços.
– Esta estratégia considerada de longo prazo apostava que o consumidor
norte-americano iria possuir um poder aquisitivo maior e tornar-se mais
exigente.
3 - 11
O Processo Fabril
• Quando a Ford percebeu que estava perdendo mercado resolveu adotar a
mesma estratégia da GM.
• A Ford teve necessidade de mudar toda a sua linha de produção.
• Em 1927 a Fábrica de River Rouge ficou fechada por 06 meses.
• Resultados:
– Isso custou a Ford cerca de 200 a 250 milhões de dólares.
– A mudança repentina a linha de produção da Ford representou muitos
desperdícios, levando a atividades descoordenadas entre a engenharia do
produto e o processo de produção.
O Processo Fabril
• Para software é necessário ter uma linha de produção:
– Dinâmica com conceitos adaptativos.
– Divisão do trabalho.
– Intercambialidade de componentes de software.
• Resultados:
– Produção de software para segmentos diversificados.
– Na produção de software a diversificação é mais volumosa e o conceito de

produção em massa de um único software não constitui uma realidade.
– Por meio deste contexto, verifica-se que não é trivial implementar o conceito de
linha de produção de software ou fábrica de software.
3 - 12
Fábricas de Software (Definições)

• Definições sobre Fábrica de Software:
Fábrica de software é um ambiente no qual se constrói programas e efetua testes.

Neste ambiente devem existir ferramentas para realizar as ações de construir e
testar. Uma fábrica possui medidas de produtividade e qualidade, os registros
financeiros são mantidos por custo da programação e a forma de
gerenciamento deve dar subsídios para prever ou estimar dados de futuros
projetos.
(Berner 1969)

• Uma fábrica de software deve:

– ser flexível, capaz de produzir vários tipos de produtos;
– implementar os conceitos de engenharia de software (metodologia,

ferramental, configuração do ambiente, guia para construção de fábricas
de softwares avançadas) e,
– também, ser capaz de estudar, projetar, implementar, evoluir e melhorar os

sistemas.
Cantone (1992)
3 - 13

Conceitualmente, fábrica de software é definida como uma estrutura de

desenvolvimento que reúne alguns requisitos básicos, como a capacidade de
atender clientes, de projetar o produto, de planejar e controlar a produção, de
produzir e de controlar a qualidade
Fagundes (2004)

• Nosso entendimento sobre o conceito de Fábrica de Software.
• Fábrica de software é uma organização estruturada, voltada para a produção

do produto software, totalmente alicerçada na engenharia e com forte
caracterização pela organização do trabalho, pela capacidade de
modularização de componentes e pela escalabilidade produtiva.
• É com base na engenharia que se pode pensar em produzir software de forma

modular e distribuída, valendo-se da figura de componentes hermeticamente
encapsulados e totalmente reutilizáveis (como futuras partes de composição
na montagem do produto final), por meio de um processo ágil, flexível e de
rápida progressão.
3 - 14
Implementando uma Fábrica de Software

• Seleção de um modelo de fábrica de software, vindo da literatura;
• Adequação do modelo à realidade da Organização (Caso do CEPEIN);
• Desenvolvimento do processo fabril para a área de desenvolvimento de software, este

processo está alicerçado no modelo selecionado;
• Configuração de um conjunto de ferramentas (toolkit) para atender, de forma dinâmica

ao processo fabril.
• Desenvolvimento de um projeto piloto para testar modelo, processo e ferramentas.
• Implantação gradativa do conceito de fábrica de software.
Implementando uma Fábrica de Software (1)
Fábrica de software Fábrica de componentes
produtos
planejar Implementação
dados componentes
planos
construir
componentes
Análise de
Implantar componentes
modelos
Modelo de Basili
3 - 15

Produção de software Produção de componentes
Gerenciamento de projetos
e administração de componentes
Analisar produtos Projetar
Gerenciamento de projetos
Projetar dados implementar
implementar planos testar
testar armazenar
implantar componentes
revisar modelos
distribuir
Padronização de tarefas Automatização Medidas de qualidade

de procedimentos produtividade
Divisão do Trabalho Flexibilidade na Produção



ao processo fabril.
3 - 16

• Orientado a Reuso (desenvolvimento Baseado em Componentes)
• Incremental
• Evolucionário (na Unidade de Produção de Componentes)

analisar
V
GHILQLomR LQWHUDJLU
GRV DJHQWHV FRP R FOLHQWH
H[WHUQRV
GHILQLomR
PRGHODU SUHYLVmR
GR HVFRSR GR
HYHQWRV GR WDPDQKR
VLVWHPD
VLVWrPLFRV GR VRIWZDUH
H GHILQLomR SUHYHU V
GRV HYHQWRV EDVHV
VLVWrPLFR WHFQROyJLFDV
*HUHQFLDU *HUHQFLDU
D DWLYLGDGH GH D DWLYLGDGH GH
DQDOLVH DQDOLVH
3 - 17

projetar
implementar
JHUHQFLDU
DWYLGDGH GH
LPSOHPHQWDomR
H V
PRQWDU
VRIWZDUH
3 - 18

validar: interação com o usuário
estamos aceitação dos espeficificação projeto do
construíndo o requisitos do sistema sistema
produto certo
uma validação pode gerar uma

correção
implementação
métodos de teste
verificar:
estamos testar
construído certo implantar
o produto
software componentes
integração de integração
modelagem implementação
requisitos componentes
aceitação
Processo de Teste
caixa preta caixa branca
forma de teste
testar
V V
WHVWDU
XQLGDGH GH
VRIWZDUH
SURMHWDU SUHSDUDU FRPSDUDU WHVWH GH
FDVRV GH FDVRV GH RV UHVXOWDGRV DFHLWDomR
WHVWH WHVWH
H WHVWDU
FRPSRQHQWHV V
JHUHQFLDU JHUHQFLDU
DWLYLGDGH DWLYLGDGH
GH WHVWH GH WHVWH
3 - 19
implantar
YHULILFDU FRQILJXUDU WUHLQDU

EDVH R VRIWZDUH XVXiULRV
WHFQROyJLFDV
H V
*HUHQFLDU *HUHQFLDU
D DWLYLGDGH GH D DWLYLGDGH
LPSODQWDomR LPSODQWDomR
revisar
H
V
YHULILFDU FRPXQLFDU VXEVWLWXLU

QRYR DR FOLHQWH FRPSRQHQWH
FRPSRQHQWH VREUH
QD EDVH FRPSRQHQWH
H V
*HUHQFLDU *HUHQFLDU
UHYLVmR GH UHYLVmR
3 - 20
armazenar
FRPXQLFDU
GRFXPHQWDU R RV LQWHJUDQWHV
FRPSRQHQWH GR SURFHVVR
H V
*HUHQFLDU *HUHQFLDU
DUPD]HQDU DUPD]HQDU
Distribuir
YHULILFDU VH YHULILFDU
FRPSRQHQWH SHUPLVV}HV GH
DWHQGH DFHVVR
VROLFDomR
H V
*HUHQFLDU *HUHQFLDU
GLVWULEXLomR GH GLVEUXLomR
3 - 21



ao processo fabril.

• Configuração de Conjuntos de Ferramentas para atender o processo
fabril.
– Aderência ao processo fabril.
– Escolha amarrada a questão de qualidade e custo.
– Parte das ferramentas foram desenvolvidas internamente parte

foram compradas e algumas são caracterizadas como Freeware.
3 - 22
• Ferramenta de gerenciamento de projetos de software:
– Destinada ao suporte a gerentes de projeto no desenvolvimento de

software, provendo informações de controle de projetos em
andamento (recursos necessários para seus desenvolvimentos), de
mão de obra (alocação de pessoal por projeto), de fornecedores e
dos riscos do projeto.
– Ferramenta desenvolvida
• Ferramenta de gerenciamento de processos, para um determinado

projeto de software:
– Dá suporte aos engenheiros de software, analistas de sistemas,

desenvolvedores e arquitetos, para controlar as informações dos
agentes externos de um determinado projeto de software e a
relação entre os agentes, as restrições inerentes ao software, o
modelo de dados a ser desenvolvido, as fases do projeto em
relação ao ciclo de vida e o desenvolvimento de componentes
(código, projeto, coleções e documentos).
3 - 23
• Ferramenta para modelagem UML (Unified Modeling Language):
– especificação de diagramas de use cases, de classes, de transição

de estados, de atividades, de seqüências, de colaborações e de
componentes.
– Após a especificação do software, com esta ferramenta é possível

gerar a assinatura das classes e dos métodos para o
desenvolvimento dos componentes de código.
• Ferramenta para desenvolvimento de componentes de código:
– Tecnologia Java.
– IDE: NetBeans (v. 3.5.1)
3 - 24

• Ferramenta para metrificar software:
– Objetivo: automatizar o cálculo do tamanho do software a ser desenvolvido

pelo projeto.
– Esta ferramenta está baseada na teoria de COCOMO 2.

• Estrutura Modular do Conjunto de Ferramentas
conjunto
ferramenta
processo de desenvolvimento de
projeto modelagem visual
software componente de métricas
código
fortemente acoplada
fracamente acoplada
3 - 25

conjunto
ferramenta
projeto
recursos mão de fornecedores

riscos visões
(equipamentos) obra componentes
escopo cronograma especialidades envolvidos

conjunto
ferramenta
dados processo de software
fase agentes modelo de

atividades componentes
externos dados
tempo gasto no relação modelagem implementação

desenvolvimento agentes
3 - 26

implementação
restrições atributos
funcionalidades versões
não funcionais
desenvolvedores
teste da correções da
status da versão envolvidos c/ a
versão versão versão

modelagem
restrições
versões
desenvolvedores
teste da correções da
status da versão envolvidos c/ a
versão versão
versão
3 - 27



ao processo fabril.

• Projeto Piloto:
• Objetivo do software a ser fabricado:
O software de agendamento de consulta tem como objetivos

armazenar os dados dos consultores (neste caso os médicos); os
dados dos pacientes; agendar consultas; prover um mecanismo de
validação das consultas agendadas e emitir relatórios em relação
aos dados armazenados.
3 - 28

• Atividades do ciclo de vida a serem desenvolvidas:
– o levantamento dos requisitos;
– a analise e projeto dos requisitos levantados;
– a implementação e teste das informações inferidas nas atividades de

analise e projeto;
– a implantação do software.

• O levantamento de requisitos é realizado utilizando componentes de infra-
estrutura.
• Os requisitos:
– Principais necessidades:
SURYHU
L QWHUIDFHDPHQWR
SDUD SUHHQFL PHQWR GR
/DQoDU DV Do}HV
DWHQGL PHQWR HP
UHDOL]DGDV
XP FRPSXGDGRU
MXQWR DR FO LHQWH
SRUWDWLO
Sistema de
Atendimento ao
Cliente
HPLWLU UHODWyULRV HVWDWtVWLFRV DJHQGDU

VREUH DWHQGL PHQWR DWHGL PHQWR
3 - 29

• Os objetivos do software, suas principais necessidades e o diagrama
de causa-efeito são capturadas no módulo de gerenciamento de
projetos/gerência de escopo do projeto (uma das ferramentas do
tookit).
conjunto
ferramenta
projeto

riscos visões

• Agentes externos envolvidos no contexto do sistema:
– Os agentes externos (atores e usuários do software) também são mapeados
utilizando componente de infra-estrutura/formulários
– Agente Externo 1: Médico

– Responsabilidade: Atende um paciente e fornece um diagnóstico.
– Uso do Software: Armazena os dados do diagnóstico fornecido ao paciente. Valida o
agendamento de uma consulta, quando este é efetuado por um paciente.
– Ambiente: Pode trabalhar em qualquer ambiente, utilizando a web.
– Agente Externo 2: paciente

– Responsabilidade: Agenda consulta. Pessoa que recebe o atendimento de um médico.
– Uso do Software: O paciente pode agendar um atendimento via web. Nota esse atendimento só é
valido se o médico validá-lo
– Ambiente: Trabalho em qualquer ambiente, o mesmo pode usar a web.
– Relação entre os agentes: Médico atende um paciente
3 - 30

• As informações relativas aos agentes externos são capturadas no módulo de
gerenciamento das informações das atividades de desenvolvimento de
software/agentes externos (uma das ferramentas do tookit).
conjunto
ferramenta

componentes
atividades externos dados

• Mapeadas as informações sobre as principais necessidades do

software e dos agentes externos é possível inferir alguns eventos cuja
as atividades fazem parte do contexto sistêmico no qual o software vai
ser desenvolvido.
– Armazenar e recuperar informações de médicos

– Armazenar e recuperar informações de pacientes
– Agendar consultas
– Validar consultas
– Armazenar informações sobre o atendimento
– Emitir relatório dos dados armazenados
3 - 31

• Representação das atividades Essenciais:
• Desenvolvimento de um cronograma para realização das atividades de

levantamento de requisitos e análise de sistemas.
• Necessidade de realização de uma interação com o cliente para validar o

modelo sistêmico proposto.
3 - 32

• O tempo do projeto é capturado no sub-módulo gerência de tempo de projeto, o custo, no sub-
módulo de gerência de custo de projeto e os recursos, no sub-módulo de gerência de recursos
humanos do projeto.
conjunto
ferramenta
projeto

riscos visões
• Na interação realizada junto ao cliente do software, são priorizadas as

atividades essenciais que devem ser implementadas (processo incremental).
• Atividades Essenciais:
– Armazenar e recuperar informações de médicos.
– Armazenar e recuperar informações de pacientes.
• Surge a questão: Quais são essas informações?
3 - 33

• Para responder essa questão, é necessário realizar consulta ao cliente,
denominado no contexto fabril de levantamento de requisitos de
componentes.

• Levantados os requisitos de um determinado componente, o próximo passo é
estabelecer uma versão para o desenvolvimento do mesmo.
– componente armazenar e recuperar informações de médicos está na versão 001.

– Versão Datada de 21 de maio de 2004.
– Agente Externo: Médico.
– Início do Levantamento de Requisitos: 21 de maio de 2004.
– Término da Atividade de Levantamento de Requisitos: agendada para 22 de maio de
2004.
– Liberação das informações para o desenvolvimento da atividade de projeto: 22 de
maio de 2004.
– Foram gastas 04 horas no Levantamento de Requisitos.
3 - 34

• Com isso é possível concluir que:
FRPSRQHQWH
WHP
UHVWULomR UHVWULomR $W1) $W1) YHUVmR YHUVmR

Q Q Q

WHP
UHTXLVLWRV SURMHWR PRQWDJHP WHVWH LPSODQWDomR
$W1) $WULEXWRV QmR IXQFLRQDLV

• O projeto do componente:
– Desenvolvimento do modelo funcional (Diagramas Use-Case e Seqüência).
– Desenvolvimento do Modelo de Dados (Diagrama de Classes
3 - 35

• Os diagramas de use case (com seus fluxos normal e alternativo) e de seqüências, a
data de início, a previsão para data de termino, a data de liberação e a quantidade de
horas gasta na atividade de projeto de um componente são capturadas pelo módulo de
gerenciamento das informações das atividades de desenvolvimento de software
(Ferramenta).
conjunto
ferramenta

componentes
atividades externos dados


• Ordem Montagem
3 - 36
DUPD]HQDU H UHFXSHUDU LQIRUPDo}HV GH PpGLFRV YDOLGDGR LQtFLR GD

LPSODQWDomR
YHUVmR JHUD XPD QRYD YHUVmR

Q YHUVmR Q
WHP WHP
UHTXLVLWRV SURMHWR PRQWDJHP WHVWH PRQWDJHP WHVWH
,QtFLR ,QtFLR ,QtFLR ,QtFLR ,QtFLR ,QtFLR
7pUPLQR 7pUPLQR 7pUPLQR 7pUPLQR 7pUPLQR 7pUPLQR

/LEHUDomR /LEHUDomR /LEHUDomR /LEHUDomR /LEHUDomR /LEHUDomR

4WGH GH +RUDV 4WGH GH +RUDV 4WGH GH +RUDV 6WDWXV &RP (UUR 4WGH GH +RUDV 6WDWXV 6HP (UUR
&RP (UUR
Q
rastreabilidade
• Informações sobre o Projeto Piloto:
– Uma equipe de desenvolvimento de software foi destacada, especialmente,

para desenvolver este projeto.
– Esta equipe recebeu treinamento e tarefas lhe foram distribuídas (alguns

membros da equipe foram treinados para fabricar componentes, outros
para fabricar software).
3 - 37

• Desenvolvimento de um Projeto Piloto para testar modelo, processo e
ferramentas (Resultados Iniciais).
– Configuração de uma unidade de produção de componentes e uma unidade de

produção de software (divisão do trabalho).
– Introdução de técnicas de gerenciamento de projetos.
– Padronização de tarefas e controles podem ser inferidos.
– Automatização de procedimento, no desenvolvimento de software.
– Adoção de uma linguagem de modelagem comum no desenvolvimento de projetos
de softwares (a linguagem adotada: UML).
– Algumas medidas de produtividade e qualidade já podem ser inferidas.
– Configuração de um ambiente de teste de software.



ao processo fabril.
3 - 38

• Plano para Implantação do conceito fabril.
– Mapeamento de projetos que estão sendo desenvolvidos pelo CEPEIN e os projetos

que estão na fila de espera para iniciar o desenvolvimento.
– Classificação das equipes e dos projetos que irão trabalhar de forma semelhante ao
projeto piloto. O critério utilizado na classificação atenderá, primeiro, os projetos
com maior prioridade.
– Treinamento dos integrantes dos projetos classificados.
– Gerenciamento dos projetos classificados, utilizando os conceitos definidos no

projeto piloto, de forma gradativa (um projeto por vez).
• Análise dos modelos fabris da literatura.

• Seleção de um modelo levando em consideração alguns critérios.
– uma fábrica de software é baseada na produção de software por meio de
componentes.
– a padronização de técnicas e a flexibilidade na produção.
• Adequação do modelo a realidade (customização).

• Desenvolvimento de um processo fabril.
• Institucionalizar o processo desenvolvido (sugestão: desenvolvimento de um
projeto piloto).
• Configurar um conjunto de ferramentas para apoio ao processo.
• Desenvolvimento de um plano de implantação.
3 - 39
Replicando uma Fábrica de Software

• Passos a serem seguidos:
– Definir um macro processo para transferência de conhecimento e

tecnologia.
– Definir passos para customizar e adaptar o conhecimento e a

tecnologia para a organização receptora do processo fabril.
– Criar uma Base de Conhecimento com informações sobre os vários

aspectos do desenvolvimento do software.
Nishiyama, Ikeda e Niwa (2000)
Replicando uma Fábrica de Software (MP)

• Macro processo de transferência:
– Definir o conhecimento que será transferido (já realizado – processo e

tecnologia de suporte)
– Estabelecer o modelo de transferência de conhecimento
S H VV R D V
S U R F HV V R
W UD QV IH Ur QF LD G H IH U U D P H Q W D
F RQ K H F LP H Q WR WH FQ R OR JLD
F R Q IL J X U D o m R G R
D P E LHQ WH
3 - 40

• Formas de transferir conhecimento.
– “learning by doing”;
– treinamento convencional (ensino e aprendizagem – professor e aluno);
– auto aprendizagem: consulta a uma base de conhecimento (livros, cursos

on-line, manuais, formalização de processos).

• Formas de transferir conhecimento.
– “learning by doing”;
RULHQWDU
PRQLWRUDU
DSULPRUDU
3 - 41

• Configuração do ambiente:
– Instalar as ferramentas;
– Iniciar a base de componentes e de conhecimento;

• Configuração do ambiente:
– Definir a planta do ambiente fabril.

,/+$ '( )$%5,&$d2
%&
,/+$ '( )$%5,&$d2 ,/+$ '( )$%5,&$d2 1
3 - 42
Replicando uma Fábrica de Software (CUS)

• Customizar processo e da tecnologia:
– Análise dos modelos fabris.
– Adaptar o modelo a realidade da organização.
– Customizar o conjunto de ferramentas.
– Propor um projeto piloto.
Replicando uma Fábrica de Software (BC)

• Configuração de uma base de conhecimento.
– estrutura do processo (apresentada na seção 2),

– informações que respondem como utilizar o processo;
– tutoriais relacionados às atividades de processo;
– informações que respondem como configurar as ferramentas;
– tutoriais sobre as ferramentas;
– como aplicar as ferramentas em conjunto com o processo;
– informações relativas aos componentes (permissões, regras, autor
do componente)
– informações que respondem como utilizar um determinado
componente na atividade implementação;
– informações relativas a estrutura dos componentes e a biblioteca
de componentes.
3 - 43
Replicando uma Fábrica de Software (Recursos)

• Customizar as ferramentas de gerenciamento de projeto e de
processos de acordo com o processo definido.
• Configurar o ambiente: estabelecer um número x de ilhas de

fabricação de software, x pode variar de acordo com as pretensões da
organização.
• Configurar a base de conhecimento: criar um mecanismo que propicie

a compartilhamento do processo e das ferramentas.
• Estabelecer o número de integrantes que irão participar no processo

de fabricação de software.
Replicando uma Fábrica de Software (Recursos)

• Transferir conhecimento: todos os integrantes que irão participar do
processo de fabricação de software devem ser treinados. Os
treinamentos sugeridos são:
– Treinamento no processo (orientado a processo ou orientado a objetos),

utilizando as ferramentas de gerenciamento de projetos e de processos (60
horas).
– Treinamento em métricas (20 horas).
– Treinamento na tecnologia JAVA (60 horas).
– Treinamento na ferramenta de modelagem do processo fabril (20 horas).
• Desenvolver um projeto piloto para balizar o processo fabril e as

ferramentas.
3 - 44
Conclusão
• Casos de Sucesso de empresas que implementaram o conceito de
Linha de Produto de Software.
• Caso: CelsiusTech (empresa sub-contratada da marinha sueca para o
desenvolvimento de sistemas para embarcações militares).
– A participação do software no custo total dos sistemas caiu de 65% para
20%;
– Redução da mão de obra de desenvolvimento de software (dos projetos de
uma família) de 200 pessoas para menos de 50;
– O tempo de entrega (time-to-market) passou de poucos anos para meses;
– 70% a 80% dos sistemas de software eram compostos de componentes do
repositório de ativos;
– Houve um aumento na qualidade dos sistemas desenvolvidos e na
satisfação dos clientes.
Dusrcki e Spínola 2004
• Outros casos - Nokia, Philips e Avaya Telecom
Conclusão
• Este trabalho apresentou as técnicas utilizadas para o desenvolvimento da
fábrica de software do CEPEIN. Após apresentar tais técnicas o trabalho provê
um modelo genérico para desenvolver e replicar fábricas de software.
• É possível verificar que as técnicas apresentadas necessitam do suporte do

conceito de fábrica de software (amplamente discutido no meio científico).
Tais técnicas estão embasadas nas idéias de padronização de tarefas, divisão
do trabalho, automatização de procedimentos, medidas de qualidade e
produtividade e flexibilidade na produção, propostas por Basili et. al. (1992),
Berner (1969), Cantone (1992) e Cusumano (1989).
3 - 45
Conclusão
• Ao definir as técnicas e aplicá-las no desenvolvimento da fábrica de software
do CEPEIN, houve a tentativa de responder algumas questões, entre elas,
destaca-se: Quais os critérios para selecionar um modelo para implementar
uma fábrica de software?
• Critérios:
– Uma fábrica de software é baseada na produção de software por meio de

componentes, com isso o modelo escolhido deve apresentar este conceito.
– A padronização de técnicas e a flexibilidade na produção
Conclusão
• Com certeza, outros critérios podem surgir e alterar a configuração do modelo utilizado
para implementar uma fábrica de software em outros ambientes, com isso é possível
afirmar que a questão não está totalmente solucionada.
• Outras questões devem ser respondidas pelos autores deste trabalho, entre elas: Como
adequar um modelo selecionado na literatura à realidade de uma organização? Quais
são os passos para desenvolver um processo de desenvolvimento de software aderente
ao modelo selecionado? Como escolher e configurar um conjunto de ferramentas para
desenvolver software em uma fábrica?
• Tais questões merecem grande atenção da comunidade científica e, possivelmente,

quando respondidas de forma definitiva solucionarão muitos problemas da área de
engenharia de software.
3 - 46
Referências bibliográficas
• Basili, V. R.; Caldiera G.; Cantone G. A Reference Archiecture for the Component Factory. ACM
Transaction on Software Engineering and Methodology. Vol 1. nº 1, January 1992. pp 53-80.
• Cusumano, Michael A.. Software Factory: A Historical Interpretation. IEEE Software – March de 1989.
• Cantone, G. Software Factory: Modeling the Improvement. IEEE Software. 1992.
• Li, Chao; Li Huaizhang; Li Mingshu. A Software Factory Modelo Based on ISO 9000 and CMM for
Chinese Small Organizations. IEEE, 2001.
• Fernstrom, C.; Narfelt, Kjell-Hakan; Ohlsson, L. Software Factory Principles, Architecture and
Experiments. IEEE Software, March 1992.
• Bux, G.; Marzano, G. Library of Predefined Software Process Models as Support for Software Factory
Design. The SFINX Proposal Proposal. IEEE, 1992.
• Noboru, Akima; Ooi, Fusatake. Insdustrializing Software Development A Japanese Approach. IEEE
Software, March 1989.
• Humphrey, S. Watts. Software and the Factory Paradigm. Software Engineering Journal, September
1991.
• Cesar, Ricardo. Fábrica de Software uma Vocação Nacional, extraíde de

www.computerworld.terra.com.br em 2003.
• IEEE Std 830-1998 – Recommended Practice for Software Requirements Specifications.
• Bayer, J.; Flege, O.; Laqua, R.; Muthig, D.; Schmid, K.; Widen, T. PulSE: A Methodology to Develop
Software Product Lines. SSR’99 Los Angeles CA USA. ACM.
• Chatters, Brain. Implementing an Experience Factory. Maintenance and Evolution of the Software and
System Developement Process.
3 - 47
• IEEE Std 1016-1998. Recommend Practice For Software Design Descriptions.
• Sommerville, Ian Engenharia de Software. 6ª Edição, Addison Wesley. 2003.
• Fernandes, Agnaldo Aragon; Teixeira, Descartes de Souza. Fábrica de Software: Implantação e

Gestão de Operações. Editora Atlas. 2004.
• Processo RUP.
• PMBOK
• Berner, R. W. Position Papers For Painel Discussion: The Economics of Program Producition. In
Information Processing 68, North-Holland, Amsterdan. 1969.
• Laszlo A. Belady. The Disappearance of the “Pure” Software Industry
• Ivica Crnkovic; Stig Larsson; Judith Stafford. Component-Based Software Engineering:

Building systems from Components at 9th IEEE Conference and Workshops on
Engineering of Computer-Based Systems.
3 - 48
• D. L. Parnas. A Technique for Software Module Specification with Examples.
• Stefano Cinti, Giandomenico Oldano, Elena Orazi Alfonso Fuggetta, Luigi Lavazza,
Sandro Morasca Applying GQM in an Industrial Software Factory.
• Michael A. Cusumano, Richard W. Selby. How Microsoft Biulds Softwares.
• John D. Tvedt, Roseanne Tesoriero, Kevin A. Gary. The Software Factory: Combining
Undergraduate Computer Science and Software Engineering Education.
• Victor Basili, Frank McGarry. The Experience Factory: How to Build and Run One.
• SWEBOK
• Slack, N. Lewis, M. Operations Strategy. Londres: Pitman, 2002.
• Corrêa, Henrique Luiz. Teoria Geral da Administração: Abordagem Histórica da Gestão
de Produção e Operações. São Paulo. Ed. Atlas, 2003.
• Nieto, M.; Arias, D.; Miguela, B; Rodrigues, A. The Evolution of Management Contentes:
An Analysis of th Most Relevant Textbooks. Industrial Management and Data Systems.
99/8 p. 345-352. MCB University Press, 1999.
• Sloan JR., A. E. Meus anos com a General Motors. S. Paulo. Negócio Editora. 2001.
• Hounshell D. From the American System to Mass Production 1800-1934. Johns Hopkins
University-Press, 1984
• Tedlow, R. S. Sete Homens e os Impérios que Construíram. S. Paulo: Futura 2002.
• COSTA, Ivanir; Contribuição para o aumento da qualidade e produtividade de uma Fábrica de
Software através da padronização do processo de recebimento de serviços de construção de
software; exame de qualificação de doutorado Poli Produção; 2003.
• Durskcki, R. C. Linhas de Produto de Software: riscos e vantagens de sua implantação. Simpósio
Brasileiro de Processo de Software. S. Paulo. 2004
3 - 49
Desenvolvimento e Replicação de Uma

Fábrica de Software
Repositório Fabril – CEPEIN e eLabTI

www.femanet.com.br/fs
fabri@femanet.com.br
Eng. de Produção
3 - 50

Desenvolvimento de fábrica de software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de fábrica de software

Enviado por

Direitos autorais:

Formatos disponíveis

VI Simpósio Internacional de Melhoria de São Paulo, SP – Brasil 24-26/11/2004

Processos de Software www.simpros.com.br

Desenvolvimento e Replicação de Uma

José Augusto Fabri Alexandre L’Erário

Tópicos desse Tutorial

• Fábricas de Software (Definições)

• Implementando uma Fábrica de Software

• Replicando uma Fábrica de Software

– Objetivos: Formar mão de obra qualificada nas mais variadas áreas do

– Conta com 09 cursos superiores, entre eles o curso de Ciência da

• Centro de Pesquisas em Informática (CEPEIN)

– Unidade de opera junto a FEMA.

• Departamento de Engenharia de Produção da Escola Politécnica da

• Primeiro Departamento de Engenharia de Produção do País.

– 450 alunos de graduação.

– 200 alunos de pós graduação

– GOL: Grupo de Gestão de Operações Logísticas

– TTO: Tecnologia Trabalho e Organização

– QEP: Qualidade em Engenharia do Produto

– EPEF: Economia da Produção e Engenharia Financeira

– GTI: Gestão em Tecnologia da Informação

– Objetivos: Planejar o desenvolvimento e implantação de Sistemas e

– Atualmente conta com 30 alunos de pós-graduação.

– Destaque para área de qualidade de software com mais de 15

– Formada em 1967 pelos professores do Departamento de Engenharia de

– Entidades sem fins lucrativos que opera em convênio com a universidade

– Objetivos: Divulgar conhecimento científicos e tecnológicos inerentes à

• Fábrica de Software: Utilizado pela primeira vez no Japão em 1969.

Várias empresas associam o termo

– Produção de Software em Massa e em Larga Escala.

– Padronização e controle de tarefas.

– Desenvolvimento de software baseados em Componentes.

– Gerenciamento das atividades por projeto e por processo.

Fonte (Ivanir Costa)

– Desenvolvedores com ferramentas de automação: 30%

– Brasil importa dez vezes o que exporta em Software

Gazeta Mercantil (ago2002)

• Enfim, há muito o que fazer para solucionar esse problema e alavancar

O que fazer então?

Quem pode fazer isso?

Medida adotada pelos envolvidos no projeto

“Construirei um carro para as grandes massas, feito com os melhores

Replicaremos uma série de entidades que produzirá softwares para as “grandes

• Produção em fluxo sem interrupção (idéia desenvolvida por Henry Ford).

• A decisão de fixar-se num só modelo (T) permitiu que os projetistas

• 1913 – mudança no processo de produção do Ford T – aumento drástico da

• Henry Ford apresentou ao mundo a união dos princípios da:

– Intercambialidade de peças (desenvolvida por Eli Whitney (Hounshell

• Em 1926 a Ford produzia sozinha em torno de 2 milhões de carros por ano

• A GM possuia sete linhas veículos.

• Problema enfrentado pela GM

• Estratégia da GM para reverter o quadro:

• A Ford teve necessidade de mudar toda a sua linha de produção.

• Em 1927 a Fábrica de River Rouge ficou fechada por 06 meses.

– Na produção de software a diversificação é mais volumosa e o conceito de

Fábricas de Software (Definições)

Fábrica de software é um ambiente no qual se constrói programas e efetua testes.

Fábricas de Software (Definições)

• Uma fábrica de software deve:

– implementar os conceitos de engenharia de software (metodologia,

– também, ser capaz de estudar, projetar, implementar, evoluir e melhorar os

Fábricas de Software (Definições)

Conceitualmente, fábrica de software é definida como uma estrutura de

YHULILFDU FRQILJXUDU WUHLQDU

YHULILFDU FRPXQLFDU VXEVWLWXLU