0911 Marcelo Pessoa Tesede Livre Docencia

MARCELO SCHNECK DE PAULA PESSA
PROCESSOS E PROJETOS EM UMA FBRICA DE SOFTWARE

eLab-TI
Anlise Crtica da Obra Acadmica

apresentada Escola Politcnica da
Universidade de So Paulo para a
obteno do ttulo de Livre Docente em
Engenharia.
SO PAULO
2009
Processos e Projetos em uma Fbrica de Software eLab-TI II
[Termo de julgamento]
Processos e Projetos em uma Fbrica de Software eLab-TI III
MARCELO SCHNECK DE PAULA PESSA
PROCESSOS E PROJETOS EM UMA FBRICA DE SOFTWARE

eLab-TI
Anlise Crtica da Obra Acadmica

apresentada Escola Politcnica da
Universidade de So Paulo para a
obteno do ttulo de Livre Docente em
Engenharia.
rea de Concentrao:
Engenharia de Produo
SO PAULO
2009
Processos e Projetos em uma Fbrica de Software eLab-TI IV
[Ficha catalogrfica]
Pessoa, Marcelo Schneck de Paula

Processos e projetos em uma fbrica de software eLab-TI
/ M.S.P. Pessoa. -- So Paulo, 2009.
210 p.
Tese (Livre-Docncia) - Escola Politcnica da Universidade

de So Paulo. Departamento de Engenharia de Produo.
1.Fbrica de software 2.Tecnologia da informao 3.Enge -

nharia de software 4.Processo de software 5.Projeto de software
I. Universidade de So Paulo. Escola Politcnica. Departamento

de Engenharia de Produo II. t.
Processos e Projetos em uma Fbrica de Software eLab-TI V
ERRATA
PAULA PESSA, Marcelo Schneck de.
Projetos e Processos de uma Fbrica de Software eLab-TI. (Tese de Livre Docncia)

Escola Politcnica, Universidade de So Paulo, So Paulo, 2009.
Pgina Linha Onde se l Leia-se

Processos e Projetos em uma Fbrica de Software eLab-TI VI
Processos e Projetos em uma Fbrica de Software eLab-TI VII
DEDICATRIA
Dedico este trabalho Mieko, minha

companheira de todos os momentos e
aos meus pais, Eduardo e Susi que me
deram as foras necessrias para
terminar mais esta empreitada.
Fernando Jos Barbin Laurindo e
Mauro de Mesquita Spnola tambm
recebem esta dedicatria pois, sem
eles, este trabalho no existiria.
Processos e Projetos em uma Fbrica de Software eLab-TI VIII
AGRADECIMENTOS
Os primeiros agradecimentos so aos colegas de GTI, professores Fernando Jos

Barbin Laurindo e Mauro de Mesquita Spinola que muito me incentivaram a fazer
esse trabalho. Ao professor Tamio Shimizu que me recebeu no Departamento
quando ainda era um forasteiro proveniente da eltrica. Ao professor Andr Leme
Fleury que foi aluno na graduao, que se apaixonou por nosso tema de TI, e hoje
nosso colega de grupo de pesquisa. Finalmente ao Professor Renato Moraes, recm
chegado ao Departamento, mas que j era colega de pesquisa do projeto Proenge
da Capes por outra universidade.
Aos meus orientados que, sem eles este trabalho no teria contedo. So muitos
mas importante lembrar de cada um.
Jos Francisco de Castilho Filho, meu primeiro orientado. Foi quem me

ensinou a orientar.
Alberto Medeiros, Luciano Raizer Moura, Gerson Prando, Vencio Vilas Boas,
Jos Carlos Jacintho, Hlio Pekelman e Luiz Alberto de Campos Louzada que
formam o primeiro grupo de orientados que ajudou a identificar a necessidade
de se estruturar melhor o grupo de pesquisa.
Luci Vicari que permitiu uma grande participao na primeira fase do projeto
Tidia e me ensinou pedagogia
O grupo que ajudou a pensar a Fbrica de Software e participou das grandes

discusses sobre o modelo de referncia:
Ivanir Costa, Marcos Antonio Rodrigues Silva
O pessoal de Ourinhos e Assis: Andr Luiz Presende Trindade (orientado de

mestrado e doutorado), Jos Augusto Fabri e Alexandre Lrario
PauloMarques, que terminou o mestrado mas infelizmente parou por a.
Rodrigo Franco Gonalves, campeo na captao de bolsas
Kleber Oliveira, orientado de mestrado e que acabou de encerrar o doutorado,

Processos e Projetos em uma Fbrica de Software eLab-TI IX
Maria Alice Frontini que foi uma das primeiras orientadas de trabalho de formatura,
contribuiu chamando ateno para o tema Fbrica de Software e que hoje recm
doutora pelo nosso Departamento,
Fbio Massashi Okumura que, em seu trabalho de formatura, me fez acreditar em

modelos matemticos estatsticos,
Ao Edval da Silva Tavares, Marcelo Marula e Andr Trindade (j citado) que me

ensinaram Gesto do Conhecimento,
Sarah Kohan, a quem conheo desde o tempo em que era estagiria, que nos
acompanha h mais de dez anos mas no se encoraja para o doutorado,
Sheila Reinehr colega de ABNT, que virou orientada e hoje colega de pesquisa,
Ao Paulo Marcelo Lessa Moreira, Valrio del Maschi, Roque Rabechini Jr, Cssio
Sodr Cooke que fizeram contribuies importantes para este trabalho,
Ao Andr Ramos Carrara e Raphael Damini Moreira sempre solcitos para ajudar a
montar este trabalho, o memorial e o que surgir pela frente.
Ao Toms Kameyama e Antonio Carlos Tonini fiis escudeiros do eLab-TI que

sempre esto disposio para enfrentar novos desafios.
No poderia tambm deixar de agradecer Ivelise Moreira que sempre est

organizando a nossa vida, fazendo blindagens para no sermos interrompidos na
elaborao deste trabalho e resolver todos os problemas que aparecem ao longo do
caminho.
Enfim, os demais orientados que de alguma forma contriburam para as pesquisas

realizadas: Luis Ricardo Napolitano Freitas, Arthur Bataglia, Izaias Porfrio Filho,
Luciano Grubba, Srgio dos Santos, Reinaldo Nogueira, Edvaldo Antonio Sartor e
Aurlio Jos Vitorino.
Para encerrar, Carlos Eduardo Salom Pereira (in memorian) no poderia deixar de
ser lembrado tambm pois foi algum que acreditou no projeto da Fbrica de
Software em sua fase inicial e me acompanhou inmeras vezes em diversos rgos
de fomento como Fapesp, BNDES, MCT, Secretaria de Planejamento do Estado de
So Paulo, e at na Alemanha em uma visita Universidade de Hamburgo.
Processos e Projetos em uma Fbrica de Software eLab-TI X
[Epgrafe]
Processos e Projetos em uma Fbrica de Software eLab-TI XI
RESUMO
O eLab-TI um laboratrio de pesquisa, tambm conhecido como Fbrica de

Software, cuja principal finalidade estudar os diversos aspectos da produo de
software aplicando os conceitos da Engenharia de Produo Produo de
Software. Esse laboratrio foi criado como um grande desafio de pesquisa no qual
foram desenvolvidos diversos trabalhos de iniciao cientfica, trabalhos de
formatura, dissertaes de mestrado, teses de doutorado e mais recentemente, de
livre docncia. Este autor orientou um total de 36 dissertaes e teses nos ltimos
dez anos, das quais foram selecionadas 22 para a realizao de uma anlise crtica
da obra acadmica. Inicialmente feito um breve histrico da evoluo da
Engenharia de Software e uma discusso sobre os problemas existentes na
produo de software. A seguir apresentado o modelo de referncia de uma
Fbrica de Software a partir do qual as pesquisas foram desenvolvidas. Cada
pesquisa apresentada resumidamente com seus principais resultados e no final
realizado um balano geral das pesquisas desenvolvidas mostrando que o modelo
de referncia foi muito importante para formar um todo coerente das pesquisas. Foi
mostrado tambm como os mtodos de pesquisa evoluram nesse perodo analisado
e que a produo de conhecimento desses trabalhos foi muito grande mas, a
produo acadmica poderia ter sido maior se tivesse havido maior foco nesse tipo
de resultado. A graduao e a ps-graduao tambm usufruram desses resultados
atravs do oferecimento de novos cursos e da melhoria do contedo dos cursos
oferecidos.
Palavras-chave: software, processo de software, produo de software, definio

de processo de software, melhoria de processo de software, fbrica de software,
estratgia e processo de software, engenharia de software
Processos e Projetos em uma Fbrica de Software eLab-TI XII
Processos e Projetos em uma Fbrica de Software eLab-TI XIII
ABSTRACT
The eLab-TI is a research laboratory, also known as Software Factory, which main
purpose is to study the various aspects of software production using concepts of
Industrial Engineering applied to Software Production. This laboratory was
established as a major challenge of research where several works were developed
from undergraduate researches, final undergraduate works, master's and doctoral
thesis, and more recently, associate professor thesis. This Author oriented (guided) a
total of 36 dissertations and thesis in the last ten years, 22 of these were selected to
undergo a critical analysis of its academic work. Initially it is made a brief Software
Engineering evolution history and a discussion about the existing problems in
software production. After that, it is introduced a reference model of a Software
Factory from which researches were developed. Each research summary is
presented with its main results and, after that, an overall balance is made showing
how important was to have the Software Factory reference model to perform a
coherent set of researches. It was also shown how research methods evolved in the
analyzed period and that the production of knowledge of these works was very great.
Even though the academic production could have been bigger if a major focus in this
type of result was an important goal. Under graduation and graduation also benefit
from those results through the offering of new courses and the improvement of
existing ones.
Keywords: software, software process, software production, software process

definition, software process improvement, software factory, strategy and software
process, software engineering
Processos e Projetos em uma Fbrica de Software eLab-TI XIV
Processos e Projetos em uma Fbrica de Software eLab-TI XV
SUMRIO
I INTRODUO I1
I.1 A QUESTO DA PESQUISA I5
II ENGENHARIA DE SOFTWARE II-7
II.1 ANLISE ESTRUTURADA II-8

II.2 ORIENTAO A OBJETOS II-9
II.3 A VISO DO PROCESSO DE SOFTWARE II-10
II.4 O MOVIMENTO GIL II-11
II.5 ENGENHARIA DA INFORMAO II-12
II.6 A CULTURA DA TOLERNCIA II-15
II.7 O PERFIL DO PROFISSIONAL DE TI II-17
III A CRIAO DO AMBIENTE DE PESQUISA III-18
III.1 A PRIMEIRA VISO DE FBRICA DE SOFTWARE III-18

III.2 O MODELO DE REFERENCIA DE FBRICA DE SOFTWARE DO GTI III-21
IV ANLISE DE NEGCIO IV-30
IV.1 ANALISTA DE NEGCIOS IV-30

IV.2 GESTO INTEGRADA DA INFORMAO IV-40
IV.3 ANLISE DE INVESTIMENTOS EM TI IV-51
IV.4 GESTO DO CONHECIMENTO EM PEQUENAS ORGANIZAES IV-55
IV.5 GESTO DE SERVIOS IV-61
IV.6 NOVAS TECNOLOGIAS DE COMUNICAO IV-64
IV.7 DIRETRIZES ESTRATGICAS PARA EMPRESAS DE SOFTWARE IV-68
IV.8 RASTREAMENTO DE REQUISITOS IV-77
IV.9 ENGENHARIA WEB. IV-87
V ARQUITETURA DA SOLUO V-93

Processos e Projetos em uma Fbrica de Software eLab-TI XVI
V.1 MTRICAS, ORAMENTO E PLANEJAMENTO V-93

V.2 COMPETNCIA E MATURIDADE EM GESTO DE PROJETOS V-96
V.3 GESTO DO CONHECIMENTO EM PROJETOS V-101
VI IMPLEMENTAO DE SISTEMAS DE TI VI-105
VI.1 INSPEO DE RECEBIMENTO EM UMA FS VI-106

VI.2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE VI-112
VI.3 PROCESSO DE DESENVOLVIMENTO PARA UMA FBRICA DE SOFTWARE VI-113
VI.4 ORGANIZAO DOS PROCESSOS DE UMA FS VI-127
VI.5 GESTO DO CONHECIMENTO EM FS VI-136
VI.6 DDS-DESENVOLVIMENTO DISTRIBUIDO DE SOFTWARE VI-140
VI.7 REUSO SISTEMATIZADO DE SOFTWARE VI-145
VI.8 PRODUTIVIDADE EM FS VI-162
VI.9 QUICKLOCUS: AVALIAO DE PROCESSO VI-174
VI.10 CONSIDERAES FINAIS SOBRE PROCESSO DE SOFTWARE VI-182
VII ANLISE CRTICA DA OBRA VII-183
VII.1 O GRUPO DE PESQUISA VII-183

VII.2 CONTEDO DAS PESQUISAS VII-184
VII.3 OS ALUNOS PESQUISADORES VII-186
VII.4 RESULTADOS ACADMICOS VII-187
VII.5 RESULTADOS NO ACADMICOS VII-188
VII.6 CONSIDERAES FINAIS VII-189
REFERNCIAS VII-192
APNDICE A QUESTIONRIO DA PESQUISA DE SILVA (2004) VII-206

Processos e Projetos em uma Fbrica de Software eLab-TI XVII
LISTA DE ILUSTRAES
FIGURA 1 REAS TEMTICAS DO PRO E LINHAS DE PESQUISA DO GTI .................................... I3

FIGURA 2 - PROCESSO E SEUS COMPONENTES (PAUK, 1995) .......................................................... II-10
FIGURA 3 FASES DA ENGENHARIA DA INFORMAO (ADAPTADO DE MARTIN,1991)............ II-13
FIGURA 4 BLOCOS QUE COMPEM A ENGENHARIA DA INFORMAO (MARTIN, 1991). ........ II-14
FIGURA 5 MODELO DE REFERNCIA DA FBRICA DE SOFTWARE (AUTOR: GTI) ...................III-22
FIGURA 6 ANLISE DE NEGCIO ........................................................................................................III-23
FIGURA 7 PROJETO DE ARQUITETURA............................................................................................III-23
FIGURA 8 IMPLEMENTAO .............................................................................................................III-24
FIGURA 9 REPOSITRIO .....................................................................................................................III-25
FIGURA 10 RESIDNCIA EM SOFTWARE .........................................................................................III-26
FIGURA 11 PESQUISAS REALIZADAS EM ANLISE DE NEGCIO ...............................................III-27
FIGURA 12 PESQUISAS REALIZADAS EM GESTO DE PROJETOS ...............................................III-28
FIGURA 13 PESQUISAS REALIZADAS EM PROCESSO DE SOFTWARE ..........................................III-29
FIGURA 14 MODELO BABOK (BABOK , 2008). ................................................................................ IV-31
FIGURA 15 ALINHAMENTO ENTRE OS CURSOS DE NEGCIO E TECNOLOGIA (FABRI ET ALL,
2003). .............................................................................................................................................. IV-34
FIGURA 16 RESULTADO DOS CURSOS DE NEGCIO (FABRI ET AL, 2003). ............................... IV-35
FIGURA 17 RESULTADO DOS CURSOS DE TECNOLOGIA (FABRI ET AL, 2003). ........................ IV-36
FIGURA 18 OS TRS FLUXOS DE INFORMAO NAS EMPRESAS (MOURA, 1999).................... IV-41
FIGURA 19 TIPOS DE INFORMAO: DECISES MTODOS E RESULTADOS (MOURA , 1999)IV-43
FIGURA 20 PIRMIDE DE ANTHONY (MOURA, 1999) .................................................................... IV-44
FIGURA 21 ELEMENTOS DE UM SISTEMA E SUA RELAO COM A EMPRESA (MOURA, 1999). IV-
46
FIGURA 22 IDENTIFICAO DOS PROCESSOS DO FLUXO DO PRODUTO E DA INFORMAO
(MOURA, 1999) .............................................................................................................................. IV-46
FIGURA 23 SISTEMAS DE COORDENAO (MOURA, 1999) ......................................................... IV-47
FIGURA 24 VISO GERAL DOS ELEMENTOS QUE COMPEM O MODELO DE ORGANIZAO
PARA USO DA INFORMAO (MOURA, 1999) .......................................................................... IV-47
FIGURA 25 SISTEMTICA PARA AVALIAO DE PROJETOS DE TI (JACINTHO, 2000) ............ IV-52
FIGURA 26 RELACIONAMENTO ENTRE DADO, INFORMAO E CONHECIMENTO (MARULA,
2001) ............................................................................................................................................... IV-57
FIGURA 27 MODELO SECI NONAKA E TAKEUSHI (1997) ........................................................... IV-58
FIGURA 28 ETAPAS DE IMPLANTAO E MANUTENO DA GESTO DO CONHECIMENTO
(MARULA, 2001) ......................................................................................................................... IV-59
FIGURA 29 DIFERENTES TIPOS DE SERVIOS ............................................................................... IV-61
FIGURA 30 - ENQUADRAMENTO DOS REQUISITOS ......................................................................... IV-63
Processos e Projetos em uma Fbrica de Software eLab-TI XVIII
FIGURA 31-ENQUADRAMENTO DA PROGRAMAO ...................................................................... IV-63

FIGURA 32 CADEIA DE VALOR DE PORTER & MILLAR (1985)..................................................... IV-65
FIGURA 33 SISTEMA DE VALOR DE PORTER & MILLAR (1985)................................................... IV-65
FIGURA 34 MACRO FLUXO DA PESQUISA-AO (DEL MASCHI, 2009) ...................................... IV-68
FIGURA 35 UMA ABORDAGEM DE REQUISITOS (OLIVEIRA, 2002). ............................................ IV-78
FIGURA 36 MODELO PROPOSTO (OLIVEIRA, 2002) ....................................................................... IV-81
FIGURA 37 OBJETIVOS DA EXTRAO DE REQUISITOS (OLIVEIRA, 2002)............................... IV-82
FIGURA 38 PROCESSO DE DESENVOLVIMENTO PARA WEB (GONALVES, 2002) ................... IV-90
FIGURA 39 ABORDAGEM PROPOSTA PARA PROJETOS WEB (GONALVES, 2002).................. IV-91
FIGURA 40 - DIMENSES DO MODELO (GONALVES, 2009) .......................................................... IV-92
FIGURA 41 COMPARAO ENTRE ESTIMATIVAS DO COCOMO E RESULTADOS REAIS
(OKUMURA, 1988)...........................................................................................................................V-94
FIGURA 42 MODELO DE COMPETNCIAS EM GERENCIAMENTO DE PROJETOS (RABECHINI JR.,
2003) .................................................................................................................................................V-98
FIGURA 43 MATRIZ DE MATURIDADE (RABECHINI JR, 2003) ..................................................... V-100
FIGURA 44 PROCESSO DE PROGRAMAO EM UMA FBRICA DE SOFTWARE (COSTA, 2003). VI-
108
FIGURA 45 INTERFACE ENTRE O CLIENTE E A FBRICA DE SOFTWARE (COSTA, 2003) ..... VI-109
FIGURA 46 PROCESSOS PROPOSTOS PARA UMA FBRICA DE SOFTWARE (COSTA, 2003) .. VI-109
FIGURA 47 MODELO IMPLEMENTADO DA FBRICA DE SOFTWARE (COSTA, 2003) ............. VI-110
FIGURA 48 VISO GERAL DO SCRUM (RODRIGUES SILVA, 2005) ............................................ VI-121
FIGURA 49 FBRICA EXPERIMENTAL DE BASILI (FABRI, 2007) ............................................... VI-127
FIGURA 50 FBRICA PROPOSTA POR FERNANDES E TEIXEIRA (2004) .................................... VI-128
FIGURA 51 PROPOSTA DE MODELO PARA O ELAB-TI (FABRI, 2007) ........................................ VI-129
FIGURA 52 PROCESSO FABRIL (FABRI, 2007) ............................................................................... VI-133
FIGURA 53 VISO DE META-PROCESSO (FABRI, 2007) ............................................................... VI-134
FIGURA 54 META-PROCESSO PROPOSTO (FABRI, 2007) ............................................................. VI-135
FIGURA 55 O BINMIO ENSINAGEM-APRENDIZAGEM (TRINDADE, 2006).............................. VI-136
FIGURA 56 A ESCADA DO APRENDIZADO (TRINDADE, 2006) ................................................... VI-137
FIGURA 57 A ESCADA DO APRENDIZADO EM PERSPECTIVA (TRINDADE, 2006) ................... VI-137
FIGURA 58 MODELO FINAL DE ENSINAGEM (TRINDADE, 2006) ............................................... VI-138
FIGURA 59 MODELO DE ENSINAGEM E A ESCADA DE CONHECIMENTO COM EXEMPLO
(TRINDADE, 2006) ....................................................................................................................... VI-139
FIGURA 60 PROPRIEDADES DOS AMBIENTES DDS (LRARIO 2006) ....................................... VI-141
FIGURA 61 GRAU DE COMUNICAO ENTRE OS GRUPOS (BORGHOFF, 2000) ...................... VI-142
FIGURA 62 RELAO ENTRE OS MECANISMOS DE COORDENAO E AS PROPRIEDADES DO
DDS (LRARIO, 2009) ................................................................................................................ VI-142
FIGURA 63 MODELO PROPOSTO M3DS (LRARIO, 2009)........................................................... VI-143
FIGURA 64 CLASSIFICAES DE REUSO DE SOFTWARE ........................................................... VI-146
FIGURA 65 ESTRATGIAS DE REUSO (REINEHR, 2008)............................................................... VI-148
Processos e Projetos em uma Fbrica de Software eLab-TI XIX
FIGURA 66 EVOLUO DO USO SISTEMATIZADO DE SOFTWARE .......................................... VI-148

FIGURA 67 CARACTERSTICAS DE UM SISTEMA DESENVOLVIDO COM BASE EM
COMPONENTES .......................................................................................................................... VI-150
FIGURA 68 NVEIS DE ABSTRAO DE KOMPONENTE ............................................................. VI-151
FIGURA 69 MODELO DE REFERNCIA DO PROCESSO DO ESAPS (REINEHR, 2008)................ VI-153
FIGURA 70 MODELO BAPO (ADAPTADO DE REINEHR, 2008) .................................................... VI-154
FIGURA 71 PROPOSIES DA PESQUISA DE CAMPO (REINEHR, 2008) .................................... VI-156
FIGURA 72 PONTOS DE ANLISE (REINEHR, 2008)...................................................................... VI-157
FIGURA 73 EXEMPLO DE PONTO DE ANLISE PA-10 (REINEHR, 2008) .................................... VI-157
FIGURA 74 PROPOSIO P1 (REINEHR, 2008) ............................................................................ VI-158
FIGURA 79 TAXA DE MUDANA X PRODUTIVIDADE (MOREIRA, 2007).................................. VI-166
FIGURA 80 PRODUTIVIDADE VERSUS TAXA DE ERROS (MOREIRA, 2007) ............................. VI-167
FIGURA 81 MODELO DE PRODUTIVIDADE OBTIDO (MOREIRA, 2007) ..................................... VI-170
FIGURA 82 MODELO DA QUALIDADE OBTIDO (MOREIRA, 2007) ............................................. VI-171
FIGURA 83 PERCEPO DA EQUIPE COM RELAO AOS FATORES DE PRODUTIVIDADE
(MOREIRA, 2007) ......................................................................................................................... VI-172
FIGURA 84 MTODOS DE AVALIAO DO SEI (KOHAN, 2003) ................................................. VI-175
FIGURA 85 MTODOS DE AVALIAO DA ISO (KOHAN, 2003) ................................................. VI-176
FIGURA 86 DIMENSES DAS ESTRATGIAS DE AVALIAO (KOHAN, 2003) ........................ VI-176
FIGURA 87 FASES DO QUICKLOCUS .............................................................................................. VI-178
FIGURA 88 EXEMPLO DE RESULTADO CONSOLIDADO DO QUICKLOCUS ............................. VI-180
FIGURA 89 ACCURACY (KOHAN, 2003) ......................................................................................... VI-180
Processos e Projetos em uma Fbrica de Software eLab-TI XX
LISTA DE QUADROS
QUADRO 1 TIPOS BSICOS DE PRODUO (ADAPTADO DE PESSOA, SPINOLA, 2006) ............III-19

QUADRO 2 CLASSIFICAO DAS INFORMAES USADAS NA GESTO DE EMPRESAS (MOURA,
1999) ............................................................................................................................................... IV-45
QUADRO 3 MOTIVAO PARA IMPLANTAO DE EDI (MEDEIROS JR. 2002) ......................... IV-66
QUADRO 4 PRINCIPAIS DIFICULDADES PARA IMPLANTAO DE EDI (MEDEIROS JR. 2002) IV-66
QUADRO 5 PROTOCOLO DE PESQUISA (DEL MASCHI, 2009) ....................................................... IV-69
QUADRO 6 AES PROPOSTAS PRIORIZADAS (DEL MASCHI, 2009).......................................... IV-74
QUADRO 7 CICLOS DAS AES PROPOSTAS PRIORIZADAS (DEL MASCHI, 2009) .................... IV-75
QUADRO 8 AGRUPAMENTO DAS HIPTESES E QUESTES DA PESQUISA (TAVARES, 2003). V-102
QUADRO 9 MODELO DE TRANSFERNCIA DE CONHECIMENTO PARA PROJETOS DE TI
(TAVARES, 2003) ........................................................................................................................... V-103
QUADRO 10 RESULTADO DA PESQUISA EM 31 FBRICAS DE SOFTWARE (COSTA, 2003) ... VI-107
QUADRO 11- PRODUTIVIDADE X NVEL DE MATURIDADE (MOREIRA, 2007)........................... VI-165
QUADRO 12 RESUMO DOS FATORES CONSIDERADOS NO MODELO (MOREIRA, 2007) ........ VI-169
Processos e Projetos em uma Fbrica de Software eLab-TI XXI
LISTA DE ABREVIATURAS E SIGLAS
ABNT Associao Brasileira de Normas Tcnicas

ACM Association for Computer Machinery
AHP Analytical Hierarchic Process
APF Anlise por Pontos de Funo
BABoK Business Analysis Body of Knowledge
BPMS Business Process Management System
CFA Conselho Federal de Administrao
DDS Desenvolvimento Distribudo de Software
EDI Electronic Data Interchange
EOE Empresa Objeto de Estudo
ESPITI European Software Process Improvement Initiative
GSD Global Software Development
GTI - Gesto da Tecnologia da Informao
IEEE Institute of Electrical and Electronic Engineers
ISO International Organization for Standardization
OMG Object Management Group
OO Orientao a Objetos
PDCA Plan, Do, Check, Act
PF Ponto de Funo
PMBoK Project Management Body of Knowledge
RE Requirements Engineering
SBC Sociedade Brasileira de Computao
SECI Socializao, Externalizao, Combinao, Internalizao
SPE Sistema de Ponto Eletrnico
UML Unified Modeling Language
VAN Value Addes Network
Processos e Projetos em uma Fbrica de Software eLab-TI I1
I INTRODUO
Este documento realiza uma anlise crtica da obra acadmica desenvolvida por
este Autor nesses ltimos 11 anos, ou seja, de 1998 a 2009. Durante esse perodo
houve a coincidncia de diversos fatores que levaram produo acadmica mais
significativa deste Autor : a criao formal do grupo de pesquisa GTI em meados de
1998, o incio das orientaes de mestrado e doutorado e a seguir a criao do
eLab-TI o laboratrio de pesquisas de mtodos e processos de software.
As pesquisas desenvolvidas foram realizadas concentrando-se na rea de

Tecnologia da Informao, abordando aspectos referentes ao Processo de
Software, focando os problemas referentes questo dos mtodos e processos do
fazer software e na rea Sistemas de Informao, onde h mais a preocupao
com o usar software no sentido de utiliz-lo para organizar a informao para uso,
envolvendo, nesse ltimo caso, as questes do alinhamento estratgico, dos
processos de trabalho, de organizao do trabalho, enfim o ambiente mais sistmico
no qual a tecnologia da informao se insere.
H tambm duas outras reas onde foram produzidas pesquisas que so a Gesto
de Projetos e a Gesto do Conhecimento. No entanto tais temas no foram vistos
como tema central das pesquisas em si mas como uma necessidade surgida para
complementar os temas anteriores para melhor compreend-los.
Em 1998 o Departamento de Engenharia de Produo (PRO, 2009) elaborou um

projeto acadmico, reestruturou sua organizao interna e criou cinco reas
temticas:
EPEF - Economia da Produo e Engenharia Financeira
Pesquisa de aspectos ligados modelagem econmico-financeira de

empreendimentos, contabilidade, s metodologias de custos, anlise
de investimentos de sistemas de operaes e aos aspectos econmicos
relacionados s cadeias produtivas e s aglomeraes de empresas

(clusters e arranjos produtivos locais).
GOL - Gesto de Operaes e Logstica
Linha de pesquisa com nfase em gesto fsica de sistemas de

operaes e logsticos com temas em planejamento, programao e
controle da produo e de estoques, logstica e cadeia de suprimentos e
produtividade.
GTI - Gesto da Tecnologia da Informao
Aborda a gesto da Tecnologia da Informao, envolvendo seu

planejamento e implementao, visando o estabelecimento de uma
estratgia integrada (envolvendo a tecnologia, a estratgia de negcios e
os aspectos organizacionais), bem como o projeto, a implantao e a
administrao de Sistemas de Informao, de Gesto do Conhecimento e
de Apoio Deciso.
QEP - Qualidade e Engenharia do Produto
Abrange a discusso de estratgias, polticas, planejamento,

operacionalizao e controle de sistemas, metodologias e tcnicas de
qualidade, visando o aumento da eficcia e/ou competitividade da
organizao, assim como discute mtodos e tcnicas relacionados com a
concepo, desenvolvimento e implantao de produtos, estudando sua
viabilidade tcnica, econmica e logstica.
TTO - Trabalho, Tecnologia e Organizao
Trata da organizao do trabalho em todas as instncias da atividade

produtiva e dedica especial ateno relao dinmica entre trabalho e
tecnologia. Parte da abordagem scio-tcnica para diagnstico, projeto e
gesto dos processos de produo de bens e servios, aplica os
ensinamentos da ergonomia para a o estudo do trabalho humano e busca
o relacionamento entre a Engenharia e as Cincias Sociais Aplicadas.
O GTI organizou suas atividades em duas linhas de pesquisa, conforme ilustrado na

Figura 1: (1) Planejamento e (2) Implementao de Sistemas de Tecnologia da
Informao.
EPEF GOL GTI QEP TTO
rea de Concentrao:
Tecnologia da Informao
Linha de Pesquisa Linha de Pesquisa
1) Planejamento de Sistemas 2) Implementao de Sistemas
de Tecnologia da Informao de Tecnologia da Informao
Projeto 1, 2, 3... Projeto n
(Cada linha possui diversos projetos)
Figura 1 reas temticas do PRO e linhas de pesquisa do GTI
A linha de pesquisa Planejamento de Tecnologia da Informao envolve

planejamento e gesto da tecnologia da informao nas empresas, alinhamento
estratgico da TI com as estratgias de negcio das empresas, a avaliao da
viabilidade econmico-financeira de aplicaes de TI e sistemas integrados de
gesto (ERP).
A linha de pesquisa Implementao de Sistemas de Tecnologia da Informao

envolve essencialmente dois aspectos: o primeiro com relao aos mtodos e
processos para a construo de software e o segundo com relao construo e
definio de algoritmos e outras tcnicas para aplicaes em engenharia de
produo. O primeiro trata de temas como qualidade da informao, qualidade de
software, arquitetura de sistemas de tecnologia da informao, processo de
desenvolvimento de software, segurana e privacidade de sistemas de informao e

de software. O segundo tema trata de metodologias para avaliao quantitativa e
qualitativa das estratgias de deciso, de sistemas flexveis e inteligentes de
informao e sistemas de apoio deciso.
Este Autor desenvolveu projetos de pesquisa em ambas as linhas acima descritas

conforme ser apresentado neste documento. Porm, na segunda linha de pesquisa
Implementao de Sistemas de Tecnologia da Informao, houve uma maior
dedicao em funo da criao do eLab-TI (a ser detalhado neste documento). Nas
discusses sobre processo de software, qualidade de software, enfim, investigaes
sobre como desenvolver software com qualidade e produtividade, foi percebido que
estava faltando alguma coisa para aglutinar as pessoas envolvidas com esse tema.
Esse sentimento de falta era de algo maior, como um grande desafio, semelhana
dos projetos de pesquisa vividos por este Autor no incio de sua carreira: projeto de
um computador, de uma central telefnica digital, de um sistema de controle de
trens, entre outros. Esses temas integravam as atividades dos pesquisadores,
foravam a sua interao e a busca conjunta de soluo de problemas e temas de
investigao. Desses citados projetos foram desenvolvidas muitas pesquisas, cada
uma delas abordando aspectos especficos, todos necessrios para o projeto como
um todo. Surgiu, dessa forma, a idia de se criar a Fbrica de Software este
tornou-se o grande tema a ser estudado. Esse tema j havia sido objeto de um
trabalho de formatura (FRONTINI, 1998) h vrios anos atrs, mas nunca havia
sido levando adiante como objeto de pesquisa.
Vale, por fim, ressaltar que a idia de se caracterizar uma Fbrica de Software como
objeto de pesquisa foi tambm inspirada na forma com que outros grupos de
pesquisa organizam suas atividades. Um exemplo desse tipo que pode ser citado
um grupo de pesquisas em automao que escolheu o rob como tema maior: as
pesquisas variaram de modelar a trajetria da pina do rob, passando pelo estudo
de sensores tteis e acionamento de motores.
Outro aspecto importante na escolha do tema Fbrica de Software o seu carter

prtico, pois o estudo dos aspectos de produo de software, implantao de
sistemas de informao e temas afim, so essencialmente experimentais e
necessitam de situaes reais para serem estudadas.
I.1 A QUESTO DA PESQUISA
Na profisso do engenheiro que trabalha com tecnologias avanadas (que o caso

da Tecnologia da Informao), o limite entre a atividade profissional e a atividade de
pesquisa muito tnue: um pesquisador pode estar desenvolvendo um trabalho
profissional e um profissional pode estar desenvolvendo uma pesquisa.
A primeira diferena entre o pesquisador e o profissional com relao aos

objetivos:
o pesquisador est preocupado com as questes bsicas da pesquisa:

procura identificar se h um padro no fenmeno estudado, se possvel fazer
generalizao, procura demonstrar a validade e a capacidade de repetio do que
foi feito. A pesquisa tem preocupao com a rastreabilidade para permitir que outros
reconstituam a trajetria seguida e examinem o processo de trabalho. O produto, de
certa forma, fica em segundo plano. O objetivo gerar conhecimento inclusive, se
for o caso - demonstrar que algo no d certo.
o profissional tem o objetivo muito claro de resolver o problema que est

sendo enfrentado, no interessando muito o mtodo a ser utilizado. Normalmente a
presso de tempo faz com que no haja reflexes sobre o tema, a pesquisa
bibliogrfica (quando h pesquisa bibliogrfica) resume-se ao encontro de uma e
apenas uma soluo pois este apenas um ponto a ser resolvido dentro de um
contexto com muitos outros problemas a serem resolvidos. Muitas outras coisas
precisam ser feitas e no h tempo para digresses.
Um pesquisador que faz um projeto que no d certo cumpriu seu papel,

demonstrando que no d certo. O profissional que realiza um projeto que no d
certo, precisa consertar e achar outra forma de resolver o problema.
Agora, por outro lado, um profissional que trabalha em uma organizao, na rea de
desenvolvimento de produto, muitas vezes denominada P&D, Pesquisa e
Desenvolvimento, realiza talvez sem saber- atividades muito similares s atividades
de pesquisa acadmica, o que torna importante que ele conhea os mtodos de
pesquisa adequados a serem aplicados e qual sua diferena em relao a projetos
rotineiros, sem nenhum tema desconhecido.
Na realidade, o que foi denominado projeto rotineiro, assim considerado hoje, mas
um dia certamente foi objeto de pesquisa, pois se tratava de um conhecimento novo,
avanado na poca de sua criao. Ao ser tal conhecimento detalhado, desdobrado
em partes fceis de serem manipuladas, de tal forma que o conhecimento de como
fazer torna-se comum, uma commodity, e pode ser encontrado em livros ou
manuais tcnicos. A pesquisa de Trindade (2006) detalha bem a relao entre o
conhecimento que se encontra em qualquer lugar e o conhecimento especfico de
um ambiente de trabalho. Talvez uma evidncia desta evoluo do conhecimento
avanado tornar-se comum, commodity, est nas cincias bsicas: o que
aprendemos nas escolas hoje a condensao, a estruturao de muitas pesquisas
realizadas pela humanidade h muitos anos atrs. Um exemplo que muito
impressionou este Autor foi aprender que a numerao base 10 e a notao
posicional dos nmeros provocaram uma evoluo enorme na forma de realizar
clculos, operaes aritmticas simples, pois, esses mesmos algoritmos (que para
ns hoje so bvios e intuitivos) eram praticamente impossveis de serem
desenvolvidos, por exemplo, com algarismos romanos (Boyer, 1974).
O escopo das pesquisas realizadas por este Autor contribuir para o

desenvolvimento de mtodos e processos para projetos de Tecnologia da
Informao, visando obter sistemas com a qualidade desejada, no preo e no custo
planejados. Este escopo ser justificado adiante.
Processos e Projetos em uma Fbrica de Software eLab-TI II-7
II ENGENHARIA DE SOFTWARE
Os sistemas de computao comearam a existir nos anos 50 e 60 (PRESSMAN,

1987). Nessa poca, a preocupao maior era com o hardware, pois alm de ser
muito mais caro que o software, possua muitas limitaes. A primeira manifestao
da necessidade e de transformar a programao de arte para cincia (ou
engenharia) foi publicada numa carta ao editor por Bauer, Juncosa e Perlis (1959):
"Para que a atividade de processamento eletrnico de dados se torne uma

parte importante da pesquisa e do desenvolvimento, uma mudana no
carter da programao deve ser efetuada no sentido de transform-la de
arte em cincia".
Postley (1960), em sua carta ao editor, tambm reclamou que as publicaes da
ACM1 no estavam atendendo as necessidades desses novos profissionais que
estavam surgindo na rea de processamento de dados comerciais (business data
processing). Relatava que na SAE - Sociedade dos Engenheiros Automotivos -
existia uma representao desses profissionais nos respectivos campos de atuao
e, no entanto, as publicaes da ACM no tinham foco similar, mas sim muito
acadmico. Essa reclamao tratava da falta de pesquisas na rea de
processamento de dados no de como fazer algoritmos para resolver um problema,
mas a falta pesquisas voltadas para responderem a questes do tipo "Quais so os
problemas organizacionais que impedem o progresso da automao no
gerenciamento?" Por que? "O que poderia ser feito sobre isso?" Porque?
Interessante observar que esse espao at hoje no foi ocupado pela ACM, a mais
antiga associao na rea de computao! Foi ocupado pelos pesquisadores da
rea de gesto e portanto quem estuda esses temas so da rea de administrao e
engenharia de produo e no de computao.
A Engenharia de Software a disciplina da engenharia que se ocupa de todos os

aspectos da produo de software (SOMMERVILLE,2003). Foi em uma conferncia
da NATO (North Atlantic Treaty Organization ou OTAN em portugus) em 1968 que
nasceu a Engenharia de Software em virtude dos problemas que estavam ocorrendo
com a proliferao de software pelo mundo (BAUER,1969). A dcada de 70 foi a
transio onde comeou o reconhecimento da importncia do software. Segundo
1
ACM Association for Computer Machimery primeira associao na rea de computao
Knuth (1974) foi em 1970 que foram dados os primeiros passos para "transformar a
arte de programar em uma cincia". A rpida expanso da informtica em aplicaes
comerciais visando automao de tarefas administrativas acabou produzindo uma
srie de pesquisas para avaliao dos efeitos desta expanso nos processos de
produo industrial e no papel do trabalhador e seu processo de trabalho
(TAVARES, 1983).
Pode-se observar como a Engenharia de Software uma disciplina recente pois,

conforme j relatado, em 1960 reclamava-se da falta de pesquisas nessa rea e em
1968 foi formalmente criada ou batizada esta disciplina. Esses 40 anos comparados
com outras reas como a engenharia civil, mecnica, entre outras, mostra quo
"jovem" a Engenharia de Software.
Para a implementao de um sistema de informao necessrio entender o

problema a ser resolvido, o domnio da aplicao. Definida e compreendida a
necessidade do cliente, passa-se a escolher e estruturar uma soluo, ou seja,
definir o sistema de tecnologia da informao a ser construdo. A grande limitao
dos computadores em termos de velocidade de processamento e capacidade de
memria tanto de trabalho como de armazenamento, levaram formao de
profissionais competentes em modelagem e construo de algoritmos, enfim, com
grande conhecimento em computao, mtodos e tcnicas de programao. Isto
deixou em segundo plano a preocupao com o domnio da aplicao, ou seja,
aprofundamento na definio e compreenso da atividade para a qual o sistem a se
destina.
II.1 ANLISE ESTRUTURADA
Os primeiros mtodos de projeto eram centrados em dados e as operaes com

eles realizadas: a anlise estruturada que procura identificar os dados existentes
nas operaes do mundo real, estrutur-los e representar seu fluxo e operaes
(modelo de dados e fluxo de dados). Segundo Pressman (1987), contriburam para a
elaborao dessas metodologias2 autores como Jackson, Trembley, Horowitz,
2
Metodologia era o termo utilizado na poca para designar o mtodo de anlise e de projeto.
Hoje esses mtodos fazem parte do processo de projeto que envolve, alm dessas tcnicas, outros
passos como o gerenciamento de projeto.
Wulf, Guttag, Warnier e Orr. Acrescente-se a estes, autores como Tom deMarco
(1989), Gane e Sarson (1983) que aperfeioaram e disseminaram a anlise
estruturada. Nesse mtodo j havia a preocupao de separar o trabalho de anlise
(definindo o que o sistema far) do trabalho de projeto (definindo como o sistema
far), ou seja, separa a concepo da implementao. Comparando com a
abordagem de hoje, denominada anlise de negcios (a ser discutida mais a frente
nesse trabalho), a anlise ainda estava muito atrelada soluo do problema e no
descrio do domnio da aplicao.
importante lembrar que a anlise estruturada consolidou-se como um bom mtodo

de anlise. Percebeu-se, entretanto, que a utilizao deste nas organizaes e
empresas que desenvolviam as aplicaes reais, era muito baixa. Surgiu a Crise do
Software. A origem desta crise pode ser entendida como uma defasagem entre a
demanda pelo desenvolvimento de novas aplicaes e a respectiva capacidade de
oferta, a falta de uso dos mtodos existentes, somado complexidade de sua
aplicao quando no so usadas ferramentas de apoio (muitos diagramas, muito
detalhe e dificuldade de manter a documentao atualizada) (PRESSMAN, 1987;
PRESSMAN, 2006; SOMMERVILLE,2003).
II.2 ORIENTAO A OBJETOS
A orientao a objetos (OO) o mtodo de anlise que substitui a estruturada. A

origem da orientao a objetos remonta da dcada de 70 quando foram
desenvolvidas pesquisas voltadas a simulao e prototipao como Simula e
Smaltalk (PRESSMANN, 1987). Nessa poca, a pouca capacidade dos sistemas
computacionais, a falta de ferramentas de apoio a projeto e a falta de mtodos mais
operacionais de anlise e projeto, no tornaram a OO uma tcnica utilizada na
prtica. Na dcada de 90, diversos autores procuraram contribuir para um melhor
detalhamento das tcnicas para a anlise e projeto orientados a objetos. Uma srie
de mtodos se sucederam (DeMARCO, Tom, 1989); (SHLAER, S; MELLOR,
Stephen J. 1990); (SHLAER, S; MELLOR, Stephen J. 1992); (COAD, Peter;
YOURDON, Edward, 1992) ; (YOURDON, 1994); (BOOCH, Grady, 1996);
(FOWLER, Martin; SCOTT, Kendall , 1997) e cada autor apontava falhas nos
mtodos e representaes existentes, e propunham novas solues at que,
finalmente, foi fundada a OMG, que acabou consolidando a UML - Unified Modeling
Language - como uma representao universal para a orientao ao objetos.
Diferentemente da anlise estruturada, na orientao a objetos o projetista pensa

em termos de coisas (objetos) ao invs de operaes ou funes. O sistema em
funcionamento constitudo de objetos que interagem entre si e cada um mantm o
controle de seu estado de funcionamento, realizam internamente as funes e
operaes, conforme as solicitaes de outros objetos (SOMMERVILLE, 2003).
II.3 A VISO DO PROCESSO DE SOFTWARE
Na dcada de 80 surgiu, de uma forma mais clara, o conceito de processo de

software proposto por Humprey (1989). A Figura 2 identifica os trs componentes de
um processo: pessoas, ferramentas e procedimentos (PAULK et al., 1995, p. 9). O
SEI Software Engineering Institute - define particularmente processo de software
(HUMPHREY, 1989 e 1995, p. 441-470; PAULK et al., 1995; PESSA e SPINOLA,
1996), aplicando a definio acima para as atividades especficas de
desenvolvimento de software:
O processo de software pode ser definido como um conjunto de

atividades, mtodos, prticas, e transformaes que as pessoas empregam
para desenvolver e manter software e os produtos associados (ex. planos
de projeto, documentos de projeto (design), cdigo, casos de teste, e
manual do usurio). (PAULK et al., 1995, p. 8)
Procedimentos e
B mtodos que definem a
relao entre as tarefas
A D
Ferramentas e
C equipamentos
PROCESSO
Pessoas habilitadas,
treinadas, motivadas
Figura 2 - Processo e seus componentes (PAUK, 1995)

Essa abordagem representa uma viso mais abrangente do que aquela que existia
nos mtodos de anlise (tanto estruturada como OO). Trata de uma viso do
processo do ciclo de vida, onde se estabelecem atividades para cada uma das fases
do projeto de software (PAULK,1995; CMMI,2002). Por exemplo, so estabelecidas
atividades para os processos de gerenciamento de requisitos, planejamento de
projeto, gerenciamento da configurao, entre outros. Esta viso depois foi
consolidada na Norma NBR/ISO 12207 (ABNT,1997; ISO,2008).
Nessa linha de pensamento de se criar processos para cada uma das atividades
pertinentes ao processo de desenvolvimento de software, o IEEE 3 criou uma srie
de Normas. Essa abordagem, entretanto, tornou o processo de desenvolvimento de
software uma tarefa muito pesada, de alto custo de difcil aplicao. Utilizavam tais
processos os grupos voltados elaborao de aplicaes mais crticas, como o caso
da NASA e outras similares mas em mercados de alta concorrncia como a rea
financeira e aplicaes administrativas onde o risco de bugs no to crtico, nunca
chegaram a adotar completamente tais abordagens
II.4 O MOVIMENTO GIL
Conforme relatado por Sommerville (2003) em 2001, Kent Beck e outros 16

especialistas em desenvolvimento de software elaboraram a um documento que
ficou conhecido como o Manifesto para o desenvolvimento gil de software. Foi
declarado:
Estamos descobrindo melhores formas de desenvolvimento de software

fazendo e ajudando outros a faz-lo. Por meio desse trabalho passamos a
valorizar:
Indivduos e interaes ao invs de processos e ferramentas.
Software funcionando ao invs de documentao abrangente.
Colaborao do cliente ao invs de negociao de contratos.
Resposta a modificaes em vez de seguir um plano.
3
IEEE Institute of Electrical and Electronic Engineers associao da rea eltrica (e de
computao) que possui muitas publicaes acadmicas e normas tcnicas
Este documento foi uma "reao" ao movimento que vinha crescendo dos mtodos
orientados a processo como o CMM e o CMMI que exigem, particularmente dos
programadores uma disciplina de trabalho quase Taylorista (os programadores
reclamavam do excesso de rigidez e burocracia desses processos).
Vale lembrar que no final dos anos 70 e incio dos anos 80 os mtodos de anlise e
projeto eram valorizados pelos profissionais devido pouca disponibilidade dos
computadores. Uma submisso do programa para ser rodado no computador
ocorria uma ou poucas vezes ao dia, fato que forava o analista/programador a
preparar muito bem sua tarefa. Portanto era feita uma boa documentao, antes do
programa eram elaborados fluxogramas, entre outras tarefas de verificaes
manuais. A grande disseminao do PC tornou o acesso mquina e,
particularmente ao ambiente de programao, muito fcil, fato que levou aos
profissionais deixarem de lado uma maior preparao dos programas no momento
de codificar passando a realizar a tarefa por tentativa e erro, deixando de lado a
disciplina de fazer certo da primeira vez. Por um lado surgiu o movimento das
empresas criarem processos de trabalho mais rgidos (como o CMMI) o que
provocou esse manifesto.
Desses mtodos, primeira vista antagnicos com os modelos de processo,

surgiram propostas interessantes como o Extreme-Programming, Scrum entre
outros (SOMMERVILLE, 2003; RODRIGUES SILVA, 2005).
II.5 ENGENHARIA DA INFORMAO
Martin (1991) foi o criador do termo Engenharia da Informao. Relata que na

dcada de 70 criou esse termo para ressaltar a importncia de organizar a
informao na empresa como um todo, particularmente no sentido de estrutur-la
com uma abordagem top-down (de cima para baixo), diferente da forma com que
eram realizadas naquele momento com modelos de dados criados isoladamente na
forma bottom-up (de baixo para cima).
A proposta da Engenharia da Informao realizar um levantamento minucioso de

todos os dados e informaes necessrias para a cooperao da empresa,
identificados a partir da alta administrao, seguindo para os nveis operacionais,
elaborando diagramas e fluxos de informaes, at se chegar a um modelo

consolidado (MARTIN, 1991). Cita que a Engenharia da Informao possui 4 fases:
estratgia, anlise, projeto e construo, conforme ilustrado na Figura 3
Martin (1991) estabelece como objetivos da Engenharia da Informao:
investigar como o uso da tecnologia pode proporcionar empresa

vantagens sobre a concorrncia.
estabelecer metas para a empresa e fatores crticos de sucesso.
usar a anlise dos fatores crticos de sucesso para orientar a
empresa sobre como atingir melhor os seus objetivos.
determinar quais informaes podem fazer com que os gerentes
desempenhem melhor o seu trabalho.
priorizar a construo de sistemas de informao em termos de
seus efeitos globais na base.
criar um modelo global da organizao, seus processos e
informaes.
subdividir o modelo global em reas de negcios, formando a base
de anlise das reas de negcio (nvel 2 da pirmide).
determinar quais as reas de negcio a serem analisadas em
primeiro lugar.
permitir alta administrao visualizar a sua empresa em termos
objetivos, funes, informaes, fatores crticos de sucesso e
estrutura organizacional
Observar que esta uma abordagem sistmica de necessidade de informao

vista pelo lado do usurio e, para tanto utiliza o modelo dos Fatores crticos de
Sucesso de Rockart (1979). A definio do modelo de dados somente
estabelecida na fase de anlise onde so consolidadas as necessidades de
informao.
Figura 3 Fases da Engenharia da

Informao (adaptado de Martin,1991)
As 4 fases ocorrem no tempo (Figura 3) e a pirmide de etapas sucessivas top-down

possuem 3 perspectivas a serem trabalhadas: dados, atividades e tecnologia
(MARTIN, 1991; FELICIANO, 1988).
Figura 4 Blocos que compem a Engenharia da Informao (Martin, 1991).
A Figura 4 mostra como est estruturada a Engenharia da Informao. Do lado

esquerdo esto representadas as fases, demonstrando que as atividades iniciam-se
nos blocos 1 e 2 (abaixo) e evoluem para os demais blocos que representam as
diversas tecnologias. Vale observar tambm que a abordagem proposta fazia uso
intensivo de geradores de quarta gerao, prototipao, as tecnologias mais
avanado na poca.
Este mtodo similar ao utilizado nos levantamentos realizados para a implantao

atualmente dos sistemas ERP, com a diferena que hoje o levantamento no
apenas das informaes, mas tambm dos processos de trabalho.
Outro aspecto interessante abordado por Martin (1991) a proposta do uso

intensivo de ferramentas CASE4, por ele chamada de I-CASE (integrada) que
envolve todo o ciclo de vida: para representar o fluxo das informaes, modelo de
dados, dicionrio de dados, diagrama de fluxo de dados, gerao automtica de
cdigo e testes, alm de manter a rastreabilidade da documentao. Afirma
claramente que sem um sistema que automatize o desenvolvimento e a manuteno
dos sistemas de informao muito difcil manter o sistema com qualidade. A
ferramenta apresentada o IEF da Texas 5 que utilizada at os dias de hoje com
outro nome comercial.
A desvantagem da proposta realizada por Martin (1991) a demora no

levantamento e na implantao dos sistemas (a proposta levar aproximadamente
seis meses somente na fase de levantamento de informaes), alm do alto custo
da ferramenta integrada.
A importncia de Martin (1991) foi o fato de ter sido o precursor da Engenharia de

Requisitos e da Anlise de Negcios, utilizadas atualmente.
II.6 A CULTURA DA TOLERNCIA
Nos itens anteriores, foi apresentado de forma resumida o esforo realizado nesses
mais de 40 anos de Engenharia de Software para se conseguir organizar os
processos de trabalho e atender s necessidades dos usurios na construo de
Sistemas de Informao.
Inicialmente havia uma restrio muito grande com relao ao que era possvel ser
automatizado e devido s grandes limitaes do hardware e aproximadamente na
dcada de 80 houve uma queda expressiva no preo do hardware fazendo com que
o software venha se tornando mais caro nos projetos e tenha se transformado no
gargalo para atendimento s demandas das organizaes. Nos dias de hoje, apesar
4
Ferramenta CASE Computer Aided Software Engineering o conjunto de aplicativos que
automatizam a facilitam a atividade de projeto e desenvolvimento de software
5
IEF uma ferramenta CASE desenvolvida por James Martin
do baixo custo do hardware e da disponibilidade de novas tecnologias, o desafio

continua sendo similar ao de sempre: como desenvolver software com a qualidade
necessria, no tempo e no custo adequados?
A proliferao em massa das aplicaes dos anos 70 para c piorou a situao

identificada na crise de software: a alta demanda por novas aplicaes e a rpida
obsolescncia das aplicaes existentes. Portanto o mercado no suportava mais
prazos de desenvolvimento de aplicaes com durao e 2 a 3 anos devido
necessidade de uso do prprio sistema e da dinmica de alteraes dos requisitos
de negcio durante o desenvolvimento do projeto. Isso forou a Engenharia de
Software buscar novas solues como os ciclos de vida no em cascata mas,
incrementais, e evolucionrios (SOMERVILLE, 2003; PRESSMAN, 2006).
Ao mesmo tempo foi criada a cultura da tolerncia com relao qualidade de

software: todos conhecem os defeitos que alguns (ou muitos) aplicativos de software
apresentam e, mesmo assim, as pessoas convivem com a sua utilizao. Weinberg
(1994) cita um caso onde um jogo de xadrez tinha alguns bugs mas era um
excelente jogo e nem por isso era considerado de baixa qualidade.
Evidentemente h situaes de aplicaes crticas onde no h tolerncia a falhas,

ou seja uma falha pode provocar perdas financeiras ou at humanas. Para esses
casos sempre foram seguidas as boas prticas da engenharia de software. No
entanto isso possui um custo que no baixo e talvez o maior deles no seja
financeiro, mas sim de prazo (o concorrente lana um produto pior, mas lana
antes!). Mesmo em mercados onde havia uma preocupao muito grande com
relao qualidade tcnica tambm houve um relaxamento com relao a tolerar
falhas e defeitos de funcionamento. O melhor exemplo o celular: um indicador da
qualidade da comunicao a continuidade (sem interrupo) mesmo com a
movimentao do assinante (chamador ou chamado). Esse conceito definitivamente
no atendido. Os celulares possuem funes cada vez mais sofisticadas mas a
funo bsica de comunicao contnua no atendida! Aparentemente nem a
Anatel considera isso importante pois no h sanes com relao a chamadas
interrompidas! a cultura da tolerncia: o novo modelo desse produto que
apresenta um defeito provavelmente no mais apresentar na prxima verso, o
que pensam os usurios!
II.7 O PERFIL DO PROFISSIONAL DE TI
As mudanas ocorridas nesses 40 anos de Engenharia de Software foram muito

grandes e talvez uma das maiores, conforme j comentado, tenha sido a passagem
de uma situao liderada pela tecnologia para uma situao liderada pelo negcio.
Explicando melhor, nas decises para escolha pela implantao de um sistema de
TI, quem tomava as decises mais importantes era o responsvel pela tecnologia
pois, dadas as grandes limitaes existentes antigamente, somente um tcnico
especialista seria capaz de dizer o que e o que no possvel implementar. Hoje a
situao exatamente inversa pois, em princpio, a tecnologia oferece uma grande
gama de opes e a escolha aquela que d maior retorno para o negcio e no
mais aquela que d para fazer. Isso criou uma gerao de profissionais que tinham,
inclusive uma postura diferenciada dentro das organizaes pois eram pessoas com
poder de deciso e, alm disso, com conhecimento que poucas pessoas tinham na
poca. Evidentemente no h aqui qualquer conotao de atribuir maior ou menor
valor para esse ou aquele profissional, mas apenas tornar claro de quem (ou deve
ser) a liderana dentro de uma equipe.
O fato desse perodo ter sido to curto, de apenas 40 anos, leva a uma questo
interessante a ser investigada. Muitos dos profissionais que vivenciaram essa
primeira fase da TI esto ainda em atividade profissional, muitas vezes ocupando
hoje posies de comando. Se essas pessoas continuam com a mesma postura,
tomando decises sem analisar os impactos na organizao, sem avaliar o retorno
esperado, estaro contribuindo com o paradigma da produtividade, que uma
abordagem questionadora sobre os investimentos em TI sem avaliar os benefcios
diretos para o negcio (LAURINDO, 2002). Um corolrio tambm identificado, que
vai ser detalhado neste documento no captulo referente ao analista de negcio, a
questo da formao do profissional de TI.
Processos e Projetos em uma Fbrica de Software eLab-TI III-18
III A CRIAO DO AMBIENTE DE PESQUISA
Conforme j citado anteriormente, o primeiro trabalho desenvolvido pensando na

aplicao dos conceitos da engenharia de produo engenharia de software foi o
de Frontini (1988).
A idia de Fbrica de Software no nova, pois na conferncia onde foi criada a

Engenharia de Software (BAUER,1969) houve um comentrio de Bennett onde ele
denominou Fabrica de software um ambiente de produo controlado por mquinas.
Na verdade estava se referindo ao que hoje denominado ambiente de
desenvolvimento. Interessante observar que nessa mesma conferncia tambm foi
discutida a questo de reuso e o desenvolvimento de componentes de software. No
sumrio dito:
Eu gostaria de ver catlogos de rotinas, classificados por preciso,

robustez, desempenho tempo-espao, limitaes de tamanho e um roteiro
de parmetros.
a preocupao com a produo de software com qualidade e a minimizao de
retrabalho.
III.1 A PRIMEIRA VISO DE FBRICA DE SOFTWARE
O primeiro passo dado por Frontini (1998) para propor uma Fbrica de Software foi
fazer uma anlise dos diversos tipos bsicos de produo existentes na engenharia
de produo, conforme ilustrado Quadro 1, e procurar compreender como o
processo de produo de software se enquadra nesse contexto (FRONTINI, 1988;
PESSOA, SPINOLA, 2006).
Quadro 1 tipos bsicos de produo (adaptado de Pessoa, Spinola, 2006)
A primeira diviso dos processos discretos e contnuos. O fluxo contnuo trata

da produo de itens como petrleo, energia eltrica, gua para um cidade e no se
enquadram no foco deste estudo.
A produo discreta subdividida em trs categorias: a produo em massa,

produo intermitente e grandes projetos.
A produo em massa caracteriza-se pela produo em grandes

quantidades de um nico produto (em massa pura) ou produtos com
pequenas variaes (em massa com diferenciao).
A produo intermitente caracteriza-se pela produo de uma

quantidade maior de produtos com um volume menor de itens produzidos.
Pode ser intermitente repetitiva quando so produzidos os mesmos
produtos em determinados intervalos ou intermitente por encomenda
quando so elaborados a partir de um projeto de um produto com
posterior fabricao de um ou mais lotes.
Grandes projetos caracterizam por serem de longa durao, so

produtos com atividades bastante diferenciadas. H uma grande variao
na seqncia dos processos ou atividades de produo, e normalmente
existem muitos processos em um projeto. Projetos so considerados

nicos e no se repetem (PMI,2004).
Dentro dessas alternativas, o processo de desenvolvimento de software pode ser

enquadrado no tipo de produo grandes projetos, uma vez que o trabalho
desenvolvido sob encomenda e possui muitas atividades. Alm disso, cada produto
elaborado normalmente diferenciado e com volume de vendas normalmente baixo.
Software vendido em grande volume denominado software produto e no esse o
foco, uma vez que a reproduo do software trivial e o projeto de software produto
similar ao software sob encomenda (FRONTINI, 1988).
O objetivo de se pesquisar Fbrica de Software procurar evoluir do

enquadramento grandes projetos para a categoria intermitente sob encomenda
ou at em massa com diferenciao. Essa evoluo visa identificar novos
recursos, mtodos e processos para que se consiga obter as vantagens da
manufatura, ou seja, ganhar produtividade e reduzir o tempo de passagem. Essa
transformao possvel, pois ao analisar as atividades realizadas em cada um dos
projetos, estas so similares e, em geral, no dependem do software especfico que
est sendo produzido, o que varia o contedo. Portanto a analogia com a fbrica
faz sentido (FRONTINI, 1988).
Frontini (1988) tambm discutiu os aspectos organizacionais em uma fbrica de

software e concluiu que a abordagem de grupos semi-autnomos seria adequada
para esta aplicao, mas considera que a questo fica ainda em aberto.
Frontini (1988) ao discutir sobre produtividade, considera importante o uso de

ferramentas CASE para automatizar ao mximo as atividades.
O processo para produo de software no trabalho de Frontini (1988) envolvia

algumas tcnicas especficas com base na anlise estruturada, o mtodo
consolidado na poca. Tambm utilizava alguns mtodos propostos por empresas
de consultoria e utilizava a infra-estrutura existente na ferramenta CASE. Finaliza o
trabalho concluindo que esta abordagem contribui para a soluo da crise de
software.
Em resumo, os elementos propostos por Frontini (1998) para a Fbrica de Software

so os seguintes:
estabelecimento de um organograma, identificando, segregando e

operacionalizando funes bem definidas (que na empresa estudada
estavam pouco definidas e difusas)
transformao do processo produtivo do tipo grandes projetos em

produo em massa com diferenciao atravs da diviso do trabalho, e
utilizao de ferramenta CASE para permitir integrao entre as tarefas,
padronizao do processo de desenvolvimento e automao das
atividades
considerao dos aspectos humanos na implementao de novas

tcnicas, ferramentas e metodologias.
adoo do grupo semi autnomo como forma de organizao do trabalho
adoo de abordagens distintas na fase de codificao para sistemas

estticos e sistemas que constantemente sofrem alteraes.
III.2 O MODELO DE REFERENCIA DE FBRICA DE SOFTWARE DO GTI
As primeiras discusses sobre Fbrica de Software visavam procurar entender qual

seria o escopo do estudo, qual o objeto de pesquisa. O paradigma tradicional para a
produo de software a viso de projeto, ou seja, cada software a ser criado uma
empreitada nica, com incio, desenvolvimento e trmino, conforme definido no
PMBoK (PMI, 2004). O que o grupo de pesquisa desejava era aplicar os conceitos
da engenharia de produo produo de software, ou seja, transformar uma
atividade vista como nica em uma atividade repetitiva, procurando observar como a
manufatura tratava esse tema e aplicar esses conceitos da melhor maneira possvel.
Muitas iniciativas nesse sentido j existiam, entre as quais pode-se citar o reuso a
definio de processos criada pelo SEI. Dessa discusso foram definidos os
objetivos especficos do eLab-TI (Spinola, 2008):
1. Aplicar modelos de processo e metodologias de desenvolvimento no ambiente de

fbrica e avaliar seus resultados.
2. Descrever um processo padro de desenvolvimento de software para fbricas de

software.
3. Identificar e estabelecer diretrizes para os processos crticos de uma fbrica.

4. Estabelecimento de um processo de medio de processo para fbrica de

software.
5. Desenvolver mtodos e tcnicas prprios para o ambiente de fbrica, fortemente

calcados em automao e reuso.
A partir dessas premissas foi elaborado um modelo de referncia de Fbrica de

Software, representado na Figura 5. Esta figura representa na parte superior o fluxo
do processo de fabricao como um todo. Na parte inferior foi criado o centro de
residncia em software, responsvel pelas questes de treinamento da equipe e
capacitao profissional.
Figura 5 Modelo de referncia da Fbrica de Software (autor: GTI)
O processo da Fbrica foi organizado da seguinte forma:

III.2.1 Anlise de Negcio
Atividade responsvel por entender o ambiente de negcios (Figura 1) e identificar

oportunidades para a TI auxiliar a organizao a melhorar seu negcio, tanto do
ponto de vista de eficcia como de eficincia, usando a abordagem de alinhamento
estratgico proposta por Laurindo (2000; 2002). Essas atividades so realizadas
seguindo os processos estabelecidos no repositrio.
Entradas: necessidade de negcio, mtodos e medies.
Envolvidos com essa atividade esto

an=analista de negcios, as=analista de
sistema, d=projetista de interface e
N=negociador.
Resultado: especificao que descreve a

viso do cliente descrita na linguagem do
cliente (Juran,1991).
Figura 6 Anlise de Negcio
III.2.2 Anlise de Sistemas
Atividade de concepo da soluo para operar no ambiente alvo (Figura 7), ou

seja, considerando os aspectos da realidade da organizao com relao infra-
estrutura existente, tcnica e de processos (i=recebe informaes do repositrio). O
primeiro passo definir a necessidade do cliente na linguagem interna da
organizao (Juran, 1991) e depois estabelecer a arquitetura da soluo.
Entrada: especificao da anlise de negcio
Envolvidos com essa atividade esto as=analista

de sistema, es=engenheiro de software e
d=projetista de interface.
Resultado: arquitetura da soluo e modelagem

do projeto.
Figura 7 Projeto de Arquitetura

III.2.3 Implementao
Trata-se da construo do software, ou seja, a codificao (Figura 8). Na concepo

da Fbrica, como os projetos so altamente baseados em reuso, os novos produtos
so construdos a partir do repositrio existente, ou seja, so montados imagem
e semelhana da indstria automobilstica que monta o veculo (montadora).
Componentes so adquiridos externamente, retirados do repositrio ou construdos
no projeto (bloco componente). Uma linha de atividades realiza os testes (laboratrio
de testes), construo de componentes (C), integrao (I) at chegar ao software (S)
atravs das atividades de montagem do produto final de software. Uma vez obtido o
produto, este est pronto para implantao no ambiente definitivo. H uma troca de
informaes com o repositrio para armazenar as informaes sobre o processo,
medies do projeto e armazenamento de componentes e produtos para a biblioteca
de componentes.
Entrada: of=ordem de fabricao, ou seja a

especificao do produto a ser montado (a
idia da montadora) e dos componentes a
serem construdos (novos)
Envolvidos com essa atividade esto

as=analista de sistema, es=engenheiro de
software, ep=engenheiro de projeto e
p=programador.
Resultado: software pronto para instalar,

informaes sobre o processo e projeto e
componentes para biblioteca.
Figura 8 Implementao
III.2.4 Repositrio
O repositrio o acervo da Fbrica de Software (Figura 9) os ativos da

organizao em linguagem do CMMI). Nele esto armazenadas as informaes
sobre o campo de aplicao, arquiteturas mtodos, tcnicas, ferramentas e dados
histricos dos projetos e rastreabilidade dos produtos.
Alm disso, o repositrio possui a biblioteca de componentes que depositria dos

projetos realizados e dos componentes que
podem ser utilizados para projetos novos.
Esses componentes podero ser tambm
comercializados.
O repositrio no uma etapa do processo,

mas possui um processo interno rgido de
gesto da configurao de todo o acervo.
Figura 9 repositrio
III.2.5 Implantao
A implantao uma atividade realizada fora da Fbrica de Software e trata da

colocao do software em funcionamento em seu ambiente definitivo de produo.
Entrada: software pronto, aps montagem em fbrica.
Envolvidos com essa atividade esto an=analista de negcio, as=analista

de sistema e n=negociador
Resultado: software instalado e operando no ambiente de produo
III.2.6 Disseminao
Os tpicos acima descreveram as atividades e processos diretamente ligados

estrutura de uma Fbrica de Software. H, entretanto, outras atividades que
envolvem mais de uma Fbrica de Software e que foram tema de outras pesquisas.
Uma delas o repasse de uma Fbrica de Software para outra unidade. Isto pode
ocorrer em empresas que abrem filiais em outras localidades e precisam replicar
seus processos de desenvolvimento. Este o tema de uma das pesquisas

realizadas (FABRI, 2007).
O trabalho cooperativo entre Fbricas de Software, partilhando o desenvolvimento

de um mesmo software denominado DDS- Desenvolvimento Distribudo de
Software, tambm tema de pesquisa realizada (LErrio, 2009).
III.2.7 Residncia em Software
A residncia em software surgiu atravs de uma demanda do MCT - Ministrio da

Cincia e Tecnologia. Trata-se de uma necessidade de identificada pelo governo
como uma forma de atender a uma demanda em nvel mundial, de profissionais que
atuam em tecnologia da informao. A proposta deste programa seria a realizao
de atividades profissionais para estudantes de graduao que teriam a oportunidade
de, quando se formarem, j tenham experincia profissional, semelhana do que
ocorre na rea da medicina. Tambm este programa poderia ser utilizado para a
reciclagem de profissionais mais experientes.
Figura 10 Residncia em Software
Dessa forma, foram elaborados algumas propostas de treinamento, para formao

dos diversos tipos de profissionais que atuam na rea. A concepo da estrutura de
treinamento versus atividades dentro da fbrica de software, os aspectos de
aprendizagem e a questo da preservao do conhecimento nesse ambiente que
normalmente de alta rotatividade, motivou o desenvolvimento de pesquisas nessa
rea.
III.2.8 O mapa das pesquisas realizadas
Da Figura 11 at a Figura 13 apresentadas a seguir, pode-se observar um quadro

geral das pesquisas orientadas por este Autor e em que pontos do modelo de
referncia da fbrica de software as mesmas se enquadram. As pesquisas sero
apresentadas conforme o tipo de assunto abordado. importante lembrar que h
diversas outras pesquisas desenvolvidas sob a orientao do Professor Associado
Mauro de Mesquita Spinola. Na classificao feita, essas pesquisas foram
organizadas em trs grupos, a saber:
1-Anlise de negcio, onde foram desenvolvidos nove trabalhos
Figura 11 Pesquisas realizadas em Anlise de Negcio

3-Gesto de projetos, com trs trabalhos. No modelo de referncia, esses

trabalhos podem ser enquadrados na Anlise de Sistemas.
Figura 12 Pesquisas realizadas em Gesto de Projetos

4-Na rea de processo de software, que envolve no modelo de referncia

a anlise de sistemas (arquitetura), repositrio e a produo propriamente
dita, h um total de nove trabalhos desenvolvidos.
Figura 13 Pesquisas realizadas em Processo de Software
Este Autor orientou um total de 36 dissertaes e teses e, no momento do

fechamento deste texto, h em andamento mais seis orientados com pesquisas em
diferentes estgios. Nas apresentaes a seguir h um total de 22 pesquisas
desenvolvidas. Essa diferena refere-se a pesquisas que abordaram outros
assuntos diferentes de processos e projetos em uma Fbrica de Software, o tema
foco desta pesquisa. So eles:
5 pesquisas abordaram aspectos de aplicao de sistemas de tecnologia da

informao
6 pesquisas abordaram sistemas integrados de informao (ERP)
3 pesquisas voltadas educao
Os prximos captulos detalham as 22 pesquisas desenvolvidas.

Processos e Projetos em uma Fbrica de Software eLab-TI IV-30
IV ANLISE DE NEGCIO
Anlise de Negcio Na rea de Anlise de Negcios foram

desenvolvidas 10 pesquisas orientadas por este Autor, a
saber:
Perfil do Analista de Negcio

Gesto Integrada da Informao
Anlise de Investimentos em TI
Gesto do conhecimento
Gesto de Servios
Novas Tecnologias de TI
Diretrizes Estratgicas empresas Sw
Rastreamento de Requisitos
Engenharia Web
IV.1 ANALISTA DE NEGCIOS
A figura do analista de negcios tem tomado importncia

maior nesses ltimos anos, conforme j relatado nesse
documento no item II.7 referente ao perfil do profissional de
TI. Considerando que h, por parte das organizaes, uma
presso cada vez maior por solues tecnolgicas para
atendimento s operaes e estabelecimento de vantagens
competitivas, a capacidade de realizar estas atividades do analista de negcios. O
analista de negcios o profissional que atua como elo de ligao entre os vrios
envolvidos em um projeto dentro de uma organizao, de forma a identificar,
analisar, comunicar e validar requisitos para mudanas em processos de negcio,
polticas e sistemas de informao. O Analista de Negcios deve ser capaz de
entender o problema do negcio, as oportunidades no contexto e recomendar
solues que habilitam a organizao a atingir seus objetivos. (BABoK, 2008;
PESSOA, LAGUNA, MACEDO, 2009).
Em 2002 essa questo havia sido identificada por este Autor como uma das
pesquisas a serem realizadas: qual deve ser o perfil de conhecimento do analista de
negcios? Os profissionais que atuavam no mercado exercendo essa funo haviam
adquirido esse conhecimento na vida profissional e no existia, na poca, uma
clareza com relao a qual seria o corpo de conhecimento necessrio para

desempenhar essa funo. A idia da tese seria, inspirado no PMBoK e no
SwEBoK, criar um corpo de conhecimento para o analista de negcio. O fato do
aluno envolvido com esse tema no ter dado continuidade pesquisa, deixou esse
assunto hibernado. Em 2003, no Canad, foi criada uma entidade similar ao PMI,
que lanou o BABoK Business Analist Body of Knowledge em 2005 um modelo
criado exatamente na linha do que se havia pensado antes. Embora esse tema no
tenha gerado esse fruto acadmico, ao menos demonstrou que o caminho a ser
seguido estava certo. O modelo BABoK foi estudado por este Autor e tem sido
objeto de novas pesquisas. Como esse modelo ficou muito similar ao que se
imaginava desenvolver no contexto do eLabSoft, a seguir feita uma apresentao
resumida do mesmo.
IV.1.1 O modelo BABoK
O BABoK (BABOK , 2008) um modelo similar ao PMBoK (PMI, 2004) que

estabelece o corpo de conhecimento para o analista de negcio e tambm oferece
uma certificao aos profissionais que passarem em um exame de avaliao. O
modelo est organizado em reas de conhecimento, conforme ilustrado na Figura
14. No modelo, cada um dos retngulos corresponde a um captulo do
documento.Portanto o documento possui um captulo introdutrio mais 7 referentes
s reas de conhecimento. So elas:
Figura 14 Modelo BABoK (BABOK , 2008).

Planejamento e Monitoramento da Anlise de Negcio a rea de

conhecimento que determina que atividades so necessrias para realizar
a anlise de negcio. Identifica os stakeholders, seleciona as tcnicas de
anlise de negcio, seleciona o processo de gerenciamento de requisitos
e como vai ser avaliado o progresso do trabalho.
Gesto de Requisitos e Comunicao descreve como gerenciar

conflitos, questes e mudanas para garantir que os stakeholders e a
equipe de projeto se mantenham em acordo com relao ao escopo da
soluo.
Anlise Empresarial descreve como se considera uma necessidade de

negcio, realiza o refinamento e clarifica a definio daquela necessidade
e define o escopo da soluo que pode ser implementada de forma vivel
pelo negcio.
Eliciao6 descreve como trabalhar com os stakeholders para identificar

suas necessidades e garantir que estas foram compreendidas de maneira
correta e completa.
Anlise de Requisitos descreve como a soluo elaborada

progressivamente para garantir que a equipe faa o projeto e construa a
soluo que atenda as necessidades de negcio e dos stakeholders.
Validao e Avaliao da Soluo descreve como devem ser

avaliadas solues propostas para determinar que soluo melhor se
adequa s necessidades do negcio, identifica gaps e aponta caminhos a
serem seguidos e alteraes na soluo.
Moldando Competncias descreve o comportamento, conhecimento e

outras caractersticas que suporta as tarefas de anlise de negcio.
Cada uma das reas de conhecimento descrita em termos de tarefas e tcnicas.

Uma crtica em relao a esse modelo a pouca importncia dada (mesmo na
segunda verso) s questes referentes inovao tecnolgica.
6
No item IV.8.3 ser feita uma discusso sobre o uso desse termo em portugus.
IV.1.2 Pesquisa dos cursos que formam os futuros analistas de negcios
Conforme anteriormente exposto, como os analistas de negcio desenvolveram

suas competncias no exerccio da profisso, foi realizada uma pesquisa para
avaliar o grau de conhecimento adquirido nos cursos de graduao. Foram
estudadas as grades curriculares dos cursos de graduao ligados s reas de
Negcio e de Tecnologia (da Informao) (FABRI, et all, 2003).
O foco da pesquisa foi identificar se os cursos tinham, em sua grade, temas

relacionados ao alinhamento estratgico entre a tecnologia da informao e o
negcio. Esta pesquisa restringiu-se anlise dos documentos disponveis
descritivos dos cursos. Segundo Henderson e Venkatraman (1993) o alinhamento
estratgico corresponde adequao estratgica e integrao funcional entre os
ambientes externos (mercado, poltica, fornecedores, etc.) e internos (estrutura
administrativa e recursos financeiros, tecnolgicos e humanos) para desenvolver
competncias e maximizar o desempenho organizacional. Isto requer para o analista
de negcio conhecimentos no somente nas reas de Negcio das organizaes
mas tambm referentes rea de Tecnologia (FABRI, et all, 2003).
No Brasil, em 2003, foram identificados 23.356 cursos de graduao. Os cursos da

rea de Negcio forma considerados aqueles das mais variadas nfases da
Administrao e Engenharia de Produo. Para a rea de Tecnologia foram
considerados os cursos de Sistemas de Informao, Cincia da Computao,
Tecnologia em Processamento de Dados e Engenharia da Computao, assim
quantificados:
2.421 cursos de Administrao de Empresas
108 cursos de Engenharia de Produo
830 cursos na rea de Tecnologia (os demais citados)
Na anlise foram estudadas as ementas curriculares de 90 cursos na rea de

negcios e 60 cursos na rea de tecnologia. Para que os cursos atendam o conceito
de alinhamento estratgico (ambos os cursos) devem contemplar os conceitos de
Estratgia; Paradoxo da Produtividade; Alinhamento Estratgico; Sistemas de
Informao; Enterprise Resource Systems (ERP); Sistema de Suporte a Deciso; E-

commerce; Ebusiness e Tendncias e novas Tecnologias (FABRI, et all, 2003).
Verifica-se que os conceitos de Estratgia, Paradoxo da Produtividade; Alinhamento

Estratgico so temas da rea de negcios, os demais conceitos so considerados
temas da rea de tecnologia. Na formao do profissional de negcios devem ser
apresentados os temas de tecnologia (o profissional deve ter condies de verificar
as tecnologias emergentes, avaliar sua viabilidade e traar um plano estratgico de
negcio que utilize esta tecnologia da melhor forma possvel). O profissional da rea
de tecnologia deve ter conceitos sobre a rea de negcios para que possa priorizar
determinadas reas da TI afim de atender melhor a estratgia da organizao. A
Figura 15 ilustra alguns conhecimentos de alinhamento estratgico para o
profissional de TI e para o profissional de negcio. Nesta figura, verifica-se a
presena do quadro interdisciplinaridade onde os conceitos de TI ultrapassam a
fronteira do profissional de negcios e os conceitos de negcios ultrapassam a
fronteira do profissional de TI (FABRI, et all, 2003).
Figura 15 Alinhamento entre os cursos de Negcio e tecnologia (Fabri et all, 2003).

IV.1.2.1 Cursos da rea de Negcio
Conforme j explicitado so os cursos da rea de Administrao de Empresas e de

Engenharia de Produo.
Dos 66 cursos de Administrao analisados 72% contemplam o conceito de

Sistemas de Informao, 69% abordam sistemas de suporte deciso, 23% o
conceito de alinhamento e apenas 7,7% aplicam os conceitos de ERP, E-business e
E-commerce. H, entretanto, 27,7% dos cursos analisados que no apresentam
nenhum conceito relacionado rea de TI (FABRI, et all, 2003).
Dos 24 cursos de Engenharia de Produo analisados 100% contemplam Sistemas

de Informao e Sistemas de Suporte Deciso e 40% abordam ERP, E-business e
E-commerce 20% aplica o conceito de Estratgia e Sistemas de Informao,
Paradoxo da Produtividade e Alinhamento (FABRI, et all, 2003).
A Figura 16 apresenta os resultados em formato de grfico de barras.
Figura 16 Resultado dos cursos de negcio (Fabri et al, 2003).
A partir do prximo item so analisadas quantitativamente os levantamentos

realizados.
IV.1.2.2 Cursos da rea de Tecnologia
Os cursos da rea de Tecnologia foram classificados em cursos de Cincia da

Computao, Sistemas de Informao e Engenharia da Computao.
A pesquisa verificou que 58,33% dos cursos da rea de Tecnologia possuem

disciplinas da rea de negcios e contemplam somente o conceito de planejamento
em suas ementas (FABRI, et all, 2003).
O conceito de Estratgia apresentado em 8,33%, o conceito de Alinhamento em

4,17% e o conceito de Paradoxo da Produtividade no apresentado em nenhum
curso da rea de tecnologia (FABRI, et all, 2003).
Os cursos de Sistemas de Informao atingem um percentual de 66,67% na

apresentao dos conceitos de planejamento e 33,33% destes cursos trabalham a
questo de alinhamento (FABRI, et all, 2003).
Foi observado tambm que 41,67% destes cursos no apresentam conceitos

relacionados rea de negcios (FABRI, et all, 2003).
Analisando os nmeros acima, verifica-se que, na amostra pesquisada, os cursos da

rea de tecnologia esto distantes dos conceitos de alinhamento estratgico entre TI
e negcios. Os conceitos de Paradoxo da Produtividade, Alinhamento e Estratgia
devem ser contemplados nos cursos da rea de Tecnologia (FABRI, et all, 2003).
A Figura 17 apresenta os resultados desta pesquisa.
Figura 17 Resultado dos cursos de tecnologia (Fabri et al, 2003).

IV.1.2.3 A proposta dos rgos direcionadores
Outra abordagem dessa pesquisa foi analisar as propostas dos rgos

direcionadores dos cursos de Tecnologia e Negcios: Sociedade Brasileira de
Computao (SBC) e Conselho Federal de Administrao (CFA). importante
deixar claro que essas instituies so classificadas como rgos direcionadores
neste trabalho, pois atuam diretamente junto ao Ministrio de Educao e Cultura
(MEC) (FABRI, et all, 2003).
Sociedade Brasileira de Computao (SBC)
A SBC divide os cursos de rea tecnolgica em duas linhas (pgina 2 do currculo

de referncia de 1999 (CR99)): atividade meio (cursos de Sistemas de Informao
e Informtica); atividade fim (cursos de Cincia da Computao e Engenharia de
Computao). A proposta da SBC para os cursos da rea de tecnologia indica
preocupao com o conceito de alinhamento estratgico entre TI e Negcios, pois
no texto de referncia citada a necessidade de formao em negcios, para ter
uma viso da dinmica organizacional, atendimento s necessidades empresariais,
desenvolver sistemas de informao para soluo de problemas organizacionais,
entre outros (FABRI, et all, 2003).
Disciplinas propostas pelo currculo de referncia para os cursos de tecnologia.
Gesto da Informao que apresenta como ementa: Tecnologia da

informao. Planejamento estratgico da informao. Os papis do
profissional na gesto da informao: infomanagers, knowledge workers,
analistas de negcios. Ferramentas utilizadas na gesto da informao.
Gerncia de Projetos: Gerenciamento de expectadores: superiores,

usurios, membros da equipe e outros membros relacionados ao projeto.
Determinao dos requisitos de habilidade e alocao de equipes ao
projeto. Anlise de custo e eficincia. Tcnicas de apresentao e
comunicao. Gerenciamento efetivo de aspectos tcnicos e
comportamentais do projeto. Gerenciamento das mudanas.
Administrao que apresenta como ementa: Viso de problemas e

ferramentas usadas no processo decisrio do departamento de O&M das
organizaes. Viso sistmica das organizaes.
Analisando a proposta da SBC conclui-se que, nos cursos onde a TI atividade

meio, recomenda-se que seja apresentado o conceito de alinhamento estratgico
atravs de conceitos de planejamento estratgico da informao, gesto da
informao e anlise de negcios. J, nos cursos onde a TI atividade fim, a SBC
sugere que se apresente apenas a disciplina de Administrao (FABRI, et all, 2003).
Conselho Federal de Admnistrao (CFA)
O CFA elenca um conjunto de disciplina de formao bsica e instrumental em seu

currculo, entre estas disciplinas encontra-se a Informtica. Porm informtica um
termo genrico, pode tratar desde os conceitos bsicos de hardware e software at
conceitos de redes de computadores, tecnologia da informao etc. Por meio disto
verifica-se que as instituies de ensino no possuem um norteamento para
implementar seus currculos (FABRI, et all, 2003).
IV.1.2.4 Concluses sobre a pesquisa
Verificou-se que a maioria dos cursos pesquisados no apresenta o conceito de

alinhamento estratgico entre TI e Negcios. Os cursos da rea de negcios
(Administrao e Engenharia da Produo) levam uma vantagem na formao de
profissionais com conceito de alinhamento estratgico se comparados aos cursos de
Tecnologia (demais cursos citados no pargrafo anterior). importante citar que
estas concluses foram extradas, segundo a amostra dos cursos pesquisados
(FABRI, et all, 2003).
Esses resultados demonstram que o perfil do analista de negcios ainda no claro

e que h o que se pesquisar para melhor atender as necessidades de mercado. O
BABoK poder auxiliar nessa atividade pois, se realmente virar uma referncia como
o PMBoK, os cursos de graduao podero us-lo como referncia e os curricula

passaro a dar uma cobertura melhor nesta rea.
Na opinio deste Autor, o curso de Engenharia de Produo da EPUSP hoje cobre

boa parte dos conhecimentos para um analista de negcios pois aos poucos foram
sendo incorporadas disciplinas que atendem a esse corpo de conhecimento. H
entretanto que se fazer um trabalho mais sistemtico de avaliao da cobertura do
BABoK (BABoK , 2008).
IV.2 GESTO INTEGRADA DA INFORMAO
Na pesquisa realizada com Moura (1999) foi levantada a

seguinte questo: qual um modelo de gesto apropriado para
que as empresas possam ser competitivas na era da
informao?
A tecnologia da informao utilizada para acessar, difundir e

memorizar conhecimentos, uma vez que a memria humana limitada e o volume
de informaes necessrio para a gesto das empresas muito grande. Outro uso
importante da TI est na reduo do risco de oportunismo ou problemas nas
transaes entre empresas, face e a falta de confiana existente nas relaes
comerciais, registrando e guardando os dados das transaes (MOURA, 1999,
MAGGIOLINI,1996).
Talvez o uso mais importante da TI seja nas atividades econmicas visando reduzir
os custos de produo, a coordenao e o controle das transaes nas empresas
(MOURA, 1999, MAGGIOLINI,1996). Segundo Moura (1999), o grande desafio das
empresas de atingir os objetivos estabelecidos pela sua misso. No mundo
capitalista, esses objetivos passam pela gerao de resultados financeiros
compatveis com o capital investido, mas tambm, como caracterstica da empresa
moderna nos tempos atuais, o respeito pela sociedade, colaboradores e meio
ambiente. O sucesso do negcio segundo Honda (1998) apud Moura (1999) est
diretamente relacionado capacidade da organizao responder adequadamente ao
seu ambiente e s suas mudanas. A velocidade com que essas mudanas ocorrem
tem sido cada vez maior, obrigando as empresas a terem tambm respostas mais
rpidas. Uma empresa com uma estrutura adequada de tecnologia da informao
pode viabilizar este requisito de agilidade.
IV.2.1 Gesto Integrada da Informao
A informao um recurso, um instrumento de vital importncia para o sucesso da

empresa. Como recurso, a informao usada nos processos e nas atividades da
empresa para agregar valor ao produto. Como instrumento de gesto, utilizada
para controlar e coordenar as atividades visando alcanar os objetivos desejados.

Existem trs fluxos de informaes nas organizaes: ambiental, interna e
corporativa, conforme ilustrado na Figura 18 (MOURA, 1999).
Figura 18 Os trs fluxos de informao nas empresas (Moura, 1999)
A Informao Ambiental
O conjunto de informaes provenientes do ambiente denominado, como

apresentado, por informao ambiental, e se refere aos elementos do ambiente
com as quais as empresas esto relacionadas: clientes, concorrentes, governos,
sociedade, novas tecnologias, entre outros. Essas informaes possibilitam
empresa se posicionar em relao ao ambiente, identificando oportunidades e
ameaas que possam surgir para definio de sua estratgia de negcio. A
informao ambiental , portanto, um recurso estratgico e de grande importncia
para a empresa definir a direo a ser seguida, o mercado como foco de atuao, a
forma de relacionamento com o mercado, como identificar as necessidades dos
clientes, como saber das aes da concorrncia, das restries impostas pelos
governos, das aspiraes e presses da sociedade, entre outras. Esse tipo da
informao o insumo (entrada) do processo de planejamento estratgico e a base
para definio da estratgia de negcio dos objetivos empresariais e das polticas e
diretrizes a serem seguidas (MOURA, 1999).
Informao Interna
Com base na informao ambiental, a informao interna representa o uso da

informao dentro da empresa para gerenciamento de seu negcio, para execuo
dos seus processos e gerao dos produtos. Segundo Itamo, apud Moura (1999)
necessrio que a informao recebida pela empresa seja armazenada e dirigida
rpida e precisamente s pessoas que tomam decises. Sem um fluxo interno, a
informao acumulada no tem muito valor. Quando essa informao usada em
decises estratgicas, passa a agregar valor para a empresa (MOURA, 1999).
Podem ser identificadas duas grandes categorias de informaes internas. Por um

lado, as empresas geram e fazem uso de um grande volume de informaes
operacionais, como catlogo de clientes e fornecedores, resultados de produo,
dados contbeis, mtodos, entre outros. Normalmente essas informaes esto
armazenadas em algum tipo de registro fsico ou meio eletrnico. Por outro lado, as
empresas, notadamente as pessoas que dela fazem parte, geram conhecimento,
como resultado da assimilao e uso da informao e, ainda, advindas de suas
experincias e capacidade criativa (CORNELLA, 1994 apud MOURA, 1999).
A informao interna, seja ela do tipo operacional ou conhecimento das pessoas,

representa a essncia do gerenciamento dos processos e atividades da empresa,
sendo usada para desdobrar os objetivos estratgicos, definir os mais adequados
mtodos de execuo, registrar dados para controle das atividades e promover as
melhorias e soluo de problemas da empresa. A informao em uma organizao
somente tem sentido se utilizada para alguma finalidade (CORNELLA, 1994 apud
MOURA, 1999).
Informao Corporativa
A informao corporativa constitui-se como sendo aquela que deve ser

comunicada aos clientes (mercado) e sociedade em geral com a expectativa de
tornar a empresa e/ ou suas aes conhecidas. Pode ser usada como uma ao de
marketing para divulgar os produtos aos clientes, ou mesmo para ajud-los a
perceber que suas expectativas so atendidas pelas caractersticas dos produtos. A
comunicao com o mercado tambm usada para criar uma imagem positiva e
adequada da empresa, podendo destacar sua identidade e ser feita de acordo com
sua estratgia de negcio (Moura, 1999).
Nesse sentido, pode desejar criar o valor, percebido pelo cliente, de que seus
produtos so diferentes, ou que so mais baratos ou, ainda, que adequado a um
determinado tipo de mercado. Esse tipo de comunicao voltada para o mercado se
constitui como uma ao direta da comunicao sendo, por exemplo, como uma
campanha publicitria. A comunicao da empresa pode ser voltada para dar a ela
uma conotao social, criando uma imagem positiva (Moura, 1999).
IV.2.2 A Informao como Recurso de Gesto
Nesta pesquisa realizada com Moura (1999), foi estudada apenas a informao
interna, ou seja, a informao usada na operao rotineira e na gesto empresarial,
uma vez que seu enfoque a definio de um modelo de gesto baseado no uso da
informao. As informaes internas podem ser classificadas em trs grandes
grupos: decises, mtodos e resultados conforme a Figura 19 e o Quadro 2.
Figura 19 Tipos de Informao: decises mtodos e resultados (Moura , 1999)
As decises representam a definio de uma opo entre alternativas a respeito do

uso de recursos. Deciso o resultado de um processo de planejamento e so
apresentadas em forma de polticas, planos e programas.
Os mtodos so orientaes que definem a forma de execuo dos processos,

indicando s pessoas como executar suas atividades. Esse grupo de informao
constitudo por mtodos, procedimentos e instrues.
Os resultados representam a identificao e a notificao dos fatos ocorridos nos

processos da empresa relacionados ao uso de recursos e resultados alcanados.
constitudo por dados, indicadores e relatrios.
Os exemplos apresentados no Quadro 2 mostram o grau de abstrao dos

diferentes tipos de informao. A pirmide de Anthony (1965 apud MOURA, 1999)
estabelece a relao entre as posies hierrquicas da empresa e as necessidades
de informao. Quanto mais alto o nvel nessa pirmide, conforme ilustrado na
Figura 20, mais agregada e abrangente deve ser a informao e quanto menor o
nvel, mais especfica e detalhada deve ser a informao.
Figura 20 Pirmide de Anthony (Moura, 1999)
Esse modelo de Anthony prope uma estrutura de informaes com base no fluxo
vertical (de baixo para cima e de cima para baixo) que criticado em funo da falta
de rapidez de resposta necessria para as empresas atuais. Segundo Moura (1999),
Marchand props um modelo que evoluiu esse conceito para um fluxo horizontal de
informaes fluindo entre os processos de maneira mais ampla (que o conceito
usado atualmente nas estruturas por processo, segundo Laurindo (2006)). Tapscott
apud Moura (1999) afirma que a estrutura hierrquica com muitas camadas est se
transformando em redes horizontais ou ento negcios relativamente autnomos. A
nova empresa est se baseando na informao. A informao, portanto, um
recurso para a empresa e deve ser gerenciada adequadamente. Dentro desta idia,
surgiu uma nova linha de pensamento, baseada na necessidade de gerenciamento
dos recursos informacionais, denominado IRM Information Resources
Management. Segundo Moura (1999) esse movimento ocorreu nos anos 80
POLTICAS So regras claras a respeito de critrios usados nas decises

da empresa sobre assuntos como: finanas, pessoal,
qualidade, meio ambiente, etc.
DECISES
Contm decises a respeito do uso de recursos definindo os

PLANOS
objetivos, as metas e os meios para obter os resultados
desejados.
So decises executveis, definindo claramente o que ser

PROGRAMAS
feito, quem vai fazer, quanto e quando produzir
Representa a base de conhecimento sob determinado assunto,

MTODOS
MTODOS
devidamente organizada e documentada.
So orientaes a respeito da seqncia de atividades a ser
PROCEDIMENTOS
seguida em um processo.
INSTRUES So orientaes detalhadas de atividades dos processos.
Identificam e quantificam os fatos ocorridos nos processos,

RESULTADOS
DADOS
sendo coletados e documentados de modo adequado.
Expresso da relao de resultados obtidos com os recursos
INDICADORES
necessrios para obt-los.
So documentos que contm dados e indicadores e
RELATRIOS
informaes de anlise sobre fatos, setores e perodos da
empresa.
Quadro 2 Classificao das informaes usadas na gesto de empresas (Moura, 1999)
pesquisado por autores como Cornella, Taylor, Olaisen, Synnott e Gruber. A

proposta estabelecer uma maior preocupao com o contedo da informao e
sua qualidade e entender que os gastos com informao e Tecnologia da
Informao devem ser considerados investimentos.
IV.2.3 Modelo proposto de organizao para uso da informao
Moura (1999) aborda a empresa com um sistema, conforme representado na Figura

21. A viso sistmica aplicada a uma organizao mostra que a empresa possui
recursos de entrada como matria-prima, insumos e informaes e o obtm na sada
produtos e servios que so oferecidos ao mercado. A administrao interna
realizada atravs dos componentes desse sistema, que so os processos internos.
Esses processos precisam ser organizados de forma a atender as diversas

atividades que se integram para a realizao do produto ou servio.
A idia representar a empresa como uma cadeia de processos, conforme est na

Figura 22. Enquanto o fluxo do produto do fornecedor dos insumos, passando
pelas etapas de construo do produto ou realizao do servio na direo do
cliente, o fluxo de informaes ocorre de maneira inversa, ou seja, do cliente,
atravs das pesquisas de mercado ou equivalente, para a necessidade de insumos
e a respectiva compra.
Figura 21 Elementos de um sistema e sua relao com a empresa (Moura, 1999)
Os processos so unidades da rede organizacional da empresa que fazem uso de

recursos para agregar valor ao produto ou servio, e so integrados e coordenados
atravs do recurso informao.
Figura 22 identificao dos processos do fluxo do produto e da informao (Moura, 1999)

O modelo proposto por Moura (1999) considera o fluxo de informaes como um

instrumento de controle e de sincronismo dos processos. Identificando os tipos de
informao usados para a gesto dos processos e o inter-relacionamento dessas
informaes, possvel estabelecer um mecanismo de controle, possibilitando
melhorar o desempenho da empresa. A Figura 23 acrescenta trs sistemas na
Figura 19, j apresentada anteriormente: o sistema da qualidade de que vai criar
os mtodos, o sistema de planejamento, que vai gerar as decises e o sistema de
controle, que vai fechar o ciclo de gesto.
Figura 23 Sistemas de coordenao (Moura, 1999)
Portanto, o modelo de organizao com base na informao composto por seis

elementos: estratgia, produto e processo com base da estrutura da organizao,
sistema de planejamento, sistema da qualidade e sistema de controle como
elementos de coordenao da empresa, conforme representado na Figura 24.
Figura 24 viso geral dos elementos que compem o modelo de organizao para uso da
informao (Moura, 1999)
Aplicao do modelo
O modelo proposto foi aplicado em trs organizaes dentro de um programa de

gesto da qualidade total (TQM), seguindo orientaes dadas por autores da
qualidade tais como Main, Shiba, Deming, entre outros. A orientao utilizada para a
aplicao do modelo foi seguir um processo contendo as seguintes atividades
(MOURA, 1999):
Definio da viso estratgica atividades como definio dos objetivos

da empresa, mercado alvo de sua atuao.
Diagnstico empresarial levantamento das atividades da empresa e

comparao com as melhores prticas (benchmark) e utilizando como
referncia o modelo de excelncia PNQ Prmio Nacional da Qualidade
Conscientizao e mobilizao das pessoas as pessoas que fazem

parte da empresa precisam ser preparadas para atuar de maneira
harmnica e integrada a um novo modelo a ser adotado. Dessa forma so
realizadas diversas atividades com a direo, com as equipes tcnicas e
com as equipes operacionais.
Viso sistmica aps o diagnstico e a conscientizao, a empresa

deve ser vista de uma forma sistmica, por todos, aplicando esse
conceito. Uma representao da empresa modelada com os envolvidos
para identificar como so as relaes externas com fornecedores e
clientes e as relaes internas entre funes e processos.
Modelagem dos processos os processos de negcio so definidos

como a clula da organizao no modelo de gesto baseado no uso da
informao. Aps a viso sistmica, cada processo deve ser analisado,
identificando suas entradas, sadas e atividades de transformao. Isso
possibilita definir responsabilidades, resultados esperados e uma viso
clara do funcionamento da empresa. Deve haver tambm um sincronismo
entre os processos tendo como base a agregao do valor ao produto.
Nessa etapa so identificadas as informaes que so usadas nos
processos do sistema da qualidade, planejamento e controle.
Sistema da qualidade uma vez definida a modelagem dos processos,

iniciado o sistema da qualidade que documenta as informaes usadas
nos processos e orienta como as pessoas devem atuar para que os
resultados esperados sejam alcanados.
Sistema de planejamento representa a organizao para a tomada de

deciso e seu desdobramento na empresa. Baseada na viso estratgica,
devem ser organizados os processos de planejamento ttico e o
operacional, gerando informaes sobre o que, quanto, quando e com que
produzir. Neste item enquadram-se as atividades como programao da
produo e planos anuais, mensais, entre outros.
Sistema de controle os dados gerados nos processos, e registrados,

devem ser tratados como informao para realimentar o processo
decisrio. A empresa deve definir os indicadores que sero usados para
controle dos principais processos, os indicadores gerenciais de cada
funo, e por fim os macro indicadores, ou indicadores estratgicos. Esses
indicadores so apresentados em forma de relatrios que possibilitam a
anlise dos resultados obtidos.
Monitoramento as informaes obtidas, apresentadas em forma de

indicadores e relatrios, sero usadas para comparar os resultados
alcanados com as metas desejadas. Deve haver uma interligao entre
os indicadores para permitir uma anlise global dos resultados, com a
medio da produtividade.
Reviso e Melhorias a partir do monitoramento dos resultados so

identificadas as necessidades de melhoria ou necessidade de ajustes no
modelo de estratgia do negcio. Esta anlise permite a adequao ou
reviso da estratgia, dos produtos e da empresa, sendo reiniciado o ciclo.
Concluses com relao pesquisa.
Os casos estudados permitiram a observao de diversos pontos interessantes aqui

relacionados (MOURA, 1999):
importante a aplicao da viso sistmica a uma empresa para identificar os

elementos internos (processos). As empresas fazem parte de uma cadeia de
valor e devem entender a sua dependncia de fornecedores e clientes.
O investimento em TI para a gesto das empresas uma necessidade

importante, pois permite a agilizao no fluxo das informaes e reduz trabalhos
manuais desnecessrios.
A TI representa um meio, um instrumento para que a empresa possa atingir seus

objetivos e, portanto, deve ser dimensionada e planejada para tanto (alinhamento
estratgico).
A informao o instrumento pelo qual os processos, funes e pessoas podem

ser sincronizados e articulados em direo aos objetivos da empresa.
Os modelos de organizao tradicionais no so adequados ao dinamismo atual.

necessrio que seja adotado um modelo que possibilite um intensivo uso da
informao em todos os nveis da organizao de modo descentralizado e
flexvel, apoiando a atuao das equipes de trabalho.
As pessoas devem ser preparadas para um modelo de organizao baseado no

uso da informao, atuando com agentes de informao, sabendo usar e gerir a
informao.
Antes de investir em tecnologia da informao necessrio que a empresa

possa ser estruturada e adote um modelo de organizao com base na gesto da
informao.
A empresa deve definir e organizar a informao que usa em sua gesto.
O investimento em gesto da informao e tecnologia da informao proporciona

uma descentralizao no uso da informao, fazendo com que as pessoas
tenham grande acesso s informaes necessrias ao seu trabalho. Isso altera a
estrutura do poder das empresas e as chefias, anteriormente donas das
informaes, devem ter o seu papel readequado, sendo mais um apoiador e
orientador do que o elemento de deciso de autorizao.
IV.3 ANLISE DE INVESTIMENTOS EM TI
As organizaes tm tido um investimento cada vez maior em

tecnologia da informao, fato que traz uma preocupao
com as escolhas realizadas, seja na seleo de novos
projetos, seja na implantao de novas tecnologias ou na
determinao de prioridades dos projetos a serem
implantados. As tcnicas clssicas de avaliao econmica mostram ser
inadequadas para justificar por completo desses investimentos e por essa razo so
questionados. A determinao do custo simples, uma vez que se trata do custo de
desenvolvimento e implantao do projeto. O problema determinar o benefcio, ou
seja, quantificar financeiramente qual o benefcio que o novo projeto trar para a
organizao (JACINTHO, 2000).
Em algumas situaes os investimentos em TI so facilmente justificveis pelas

tcnicas clssicas de avaliao econmica, como por exemplo, quando h a
substituio de mo-de-obra onde se sabe o custo atual para a realizao da
atividade e o investimento no novo projeto. Nesse caso, a relao custo/benefcio
pode ser calculada diretamente. H situaes, entretanto, onde no to fcil
avaliar financeiramente o benefcio obtido, como por exemplo, em um sistema de
apoio deciso.
Farbey (1995) prope um modelo, denominado Escada de Farbey, onde o sistema

pretendido primeiramente classificado em um de 8 degraus. Para cada um deles
Farbey faz recomendaes sobre os critrios a serem adotados para a deciso de
implementao ou no do sistema. Quanto mais prximo o sistema estiver da
eficcia (necessidade da organizao), mais difcil ser avaliar financeiramente o
benefcio obtido e critrios alternativos so propostos para a deciso de implementar
ou no o sistema.
H tambm um questionamento com relao aos benefcios que os sistemas de

tecnologia da informao trazem para a organizao, conforme relatado por
Laurindo (2002). A esse fenmeno d-se o nome de Paradoxo da Produtividade.
Este autor relata tambm diversos casos da literatura onde os pesquisadores
procuram estabelecer a relao entre os investimentos em TI e indicadores
financeiros, e a concluso que se chega que no possvel estabelecer uma
relao direta da eficcia da TI usando unicamente os indicadores financeiros. Mais

recentemente Carr (2003) coloca que a TI no mais uma forma da organizao
obter vantagem competitiva pois est se tornando uma commodity.
Esta pesquisa se prope a encontrar uma soluo de compromisso entre as tcnicas

tradicionais de investimentos e o os novos estudos que envolvem uma orientao
integrada para a tomada de deciso sobre investimentos em tecnologia da
informao. O trabalho visa tambm detectar os custos e benefcios intangveis, bem
como identificar os fatores crticos de sucesso, de modo a atender s expectativas
de todos os envolvidos com a empresa.
A sistemtica proposta por Jacintho (2000) est representada na Figura 25 .
Figura 25 Sistemtica para avaliao de projetos de TI (Jacintho, 2000)
O primeiro passo justificar o investimento de TI procurando, a partir do

conhecimento do negcio, estabelecer os benefcios tangveis e intangveis do novo
sistema.
O segundo passo identificar os fatores crticos de sucesso para que se possa

determinar a real necessidade de aquisio do sistema.
No terceiro passo aplica-se o mtodo AHP Anlise Hierrquica de Processo, uma

tcnica estruturada para se lidar com decises complexas. Para o uso do AHP,
primeiramente deve-se decompor o problema decisrio em uma hierarquia de sub-
problemas mais fceis de compreender, cada um dos quais a ser analisado de forma
independente. Os elementos da hierarquia podem estar relacionados com algum
aspecto do problema decisrio (tangvel ou intangvel), cuidadosamente medidos ou
estimados grosseiramente, claramente ou pobremente entendidos, qualquer
elemento que se tiver em mos para ser aplicado deciso.
O quarto passo leva estabelecer uma matriz de pontuao (Score).
O quinto passo realiza a anlise da eficincia dos sistemas. Caso a eficincia seja
positiva segue-se para os passos 6 e 7 (eficincia adequada).
Nesse sexto passo realizada a anlise dos indicadores ou dos processos de

investimento.
O stimo passo avalia se o novo projeto vai levar a uma mudana no

posicionamento estratgico da empresa.
Caso negativo (no leva a mudana no posicionamento estratgico), segue-se para

o passo 10, que realizar o PDCA, retornando para o passo n 2.e refazendo todo
o ciclo.
No caso do projeto estabelecer positivamente mudanas no posicionamento

estratgico, segue-se para o passo 8 onde se analisa a eficcia do sistema.
Caso a eficcia seja positiva, positivo a deciso seria executar o projeto e caso
negativo volta-se ao passo 10 para realizar o ciclo novamente a partir do passo 2.
Este mtodo foi aplicado em duas empresas da rea industrial: a primeira delas
uma empresa montadora multinacional que produz caminhes e nibus e a segunda
uma indstria do ramo de papel e celulose. So empresas que atuam em mercados
diferentes, uma globalmente e a outra apenas no Brasil. O resultado obtido na
aplicao da sistemtica proposta por Jacintho (2000) foi adequado para os dois
casos. Essa sistemtica, aplicada nas duas organizaes, demonstrou que os
projetos analisados visavam uma mudana no posicionamento estratgico de cada
organizao. Cabe salientar que uma avaliao apenas financeira condio
necessria mas no suficiente para a tomada de deciso quanto execuo e
implantao dos projetos de TI. No primeiro caso a viabilidade era evidente e a
sistemtica indicou esse resultado no primeiro ciclo. No segundo caso a avaliao
da eficincia (passo 6) foi negativa por ser este um projeto ruim ou por estar no
limiar dos resultados esperados. Desse modo foi possvel refazer o ciclo PDCA de
forma a abordar a mesma questo sob outra tica e assim, aps pequenos ajustes,
viabilizar o projeto. Esta sistemtica um processo que exige conhecimento poltico
da organizao, do mercado global e da equipe envolvida.
IV.4 GESTO DO CONHECIMENTO EM PEQUENAS ORGANIZAES
Na pesquisa realizada com Marula (2001, 2001a) foi

desenvolvido um modelo para Gesto do Conhecimento em
pequenas organizaes. Entende-se por organizao uma
empresa de pequeno porte, uma seo, ou departamento de
uma grande empresa. O conceito de Conhecimento est
ligado tripla Dado/Informao/ Conhecimento.
Dado
um conjunto de fatos relativos a eventos e esto ligados aos estmulos que as

pessoas recebem pelos seus sentidos. Nas empresas eles so registros
estruturados de transaes, normalmente armazenados em sistemas tecnolgicos.
Os dados possuem pouca relevncia ou propsito, pois dizem pouco sobre as
transaes (por exemplo, porque foram feitas, se vo se repetir, etc.). O mais
importante que os dados no possuem significado inerente, descrevem apenas o
que aconteceu. No servem como base para a tomada de aes, no mximo podem
ser a matria prima. (MARULA, 2001).
Informao
A informao diferente dos dados possui significado, relevncia e propsito.

Apresenta-se na forma de documentos ou de comunicaes sonoras. quem
recebe, no quem emite, que decide se a mensagem passada pelos dados constitui
uma informao. Nas empresas a informao pode movimentar-se por redes hard
(cabos, centrais de correio, caixas postais eletrnicas, Internet, etc.) ou soft (modos
menos formais e visveis, como por exemplo, a cpia de um artigo de jornal com
uma marcao). Para que os dados se transformem em informaes, esses devem
ganhar significados. Alguns mtodos podem ser considerados para isso:
Contextualizao: sabida a finalidade dos dados coletados.
Categorizao: so conhecidos os componentes essenciais dos dados.
Clculo: os dados podem ser analisados matemtica ou estatisticamente.
Correo: os erros so eliminados dos dados.

Condensao: os dados podem ser resumidos para uma forma mais

concisa.
A TI auxilia em todos esses processos de converso, mas no consegue fazer o

trabalho sozinha em vrias situaes.
Conhecimento
O conhecimento mais amplo, profundo e rico do que as informaes e

normalmente quando se fala em conhecimento, refere-se a pessoas e no a
documentos ou sistemas. Em uma empresa o conhecimento pode ser definido como
(MARULA, 2001):
uma mistura fluda de experincia condensada, valores, informao

contextual e insight experimentado, a qual proporciona uma estrutura para a
avaliao de novas experincias e informaes. Ele tem origem na mente
dos conhecedores. Nas organizaes, costuma estar embutido no s em
documentos, mas tambm em rotinas, processos, prticas e normas
organizacionais.
O conhecimento deriva das informaes, e a transformao pode ocorrer atravs de
(MARULA, 2001):
Comparao: comparar informaes sobre uma situao com outras j

conhecidas.
Concluses: que conseqncias estas informaes trazem para as

decises e para realizao de aes?
Conexes: quais as relaes deste novo conhecimento com aqueles j

acumulados?
Conversao: o que as outras pessoas pensam desta informao?
Todas essas atividades acontecem na mente das pessoas e no contato entre elas,
podendo ocorrer com o auxlio de ferramentas de TI.
Aps o processo, surge um novo conhecimento que, armazenado com aqueles

existentes, constitui o Conhecimento Acumulado. Este, por sua vez, usado
novamente nas transformaes de dados em informaes e essas em novos
conhecimentos.
O conhecimento entregue atravs de meios estruturados (livros, documentos, etc.)

e de contatos pessoais (conversas, relaes de aprendizado, etc.).
Um exemplo disso a pessoa que recebe o dado de que hoje a temperatura de

33C. A pessoa compreende e cria a informao de que o dia est muito quente
para essa poca do ano e conclui que o aquecimento global est aumentando
(conhecimento). A Figura 26, baseada em Alter (1992), apresenta essas
transformaes.
Figura 26 Relacionamento entre dado, informao e conhecimento (Marula, 2001)
Nas organizaes, o conhecimento usado como uma ferramenta importante para a

realizao das atividades, sejam elas operacionais, gerenciais ou estratgicas. Para
isso usado o modelo SECI de Nonaka e Takeushi (1997), ilustrado na Figura 27.
Esse modelo SECI: Socializao, Externalizao, Combinao e Internalizao
representa os quatro modos de converso do conhecimento. O conhecimento
explcito aquele que est registrado e organizado de forma que possa facilmente
ser transferido de uma pessoa para outra. O conhecimento tcito aquele intrnseco
s pessoas, resultado de sua educao, experincia de vida e capacidade individual
de elaborao e aprendizado.
Nesse modelo, a primeira fase, de socializao, trata do contato entre duas pessoas
que compartilham e experincias, como por exemplo, um aprendiz que trabalha com
seu mestre, no atravs da linguagem, mas atravs da observao e imitao e
prtica. O segredo para aquisio do conhecimento tcito a experincia.
A segunda fase, de externalizao, a articulao do conhecimento tcito em

conceitos e explcitos. um processo de criao do conhecimento perfeito, na
verdade na medida em que o conhecimento tcito se torna explcito, na forma de

metforas, analogias, conceitos, hipteses ou modelos.
A terceira fase, combinao, um processo de sistematizao de conceitos em um

sistema de conhecimento desse modo de converso envolve a combinao de
conjuntos diferentes de conhecimento explcito.
A quarta fase, internalizao o processo de incorporao do conhecimento

explcito no conhecimento tcito. Est intimamente ligada ao aprender fazendo.
Figura 27 modelo SECI Nonaka e Takeushi (1997)
Com base nesses conceitos, Marula (2001) props um modelo para a gesto do
conhecimento em pequenas organizaes, representado na Figura 28. Nas
organizaes comum encontrar atividades que so realizadas por apenas uma
pessoa. Nesse modelo, a idia fazer (passo A) um estudo preliminar na empresa e
identificar os problemas existentes (passo B), considerando que problema uma
atividade importante para a operao, cujo conhecimento para sua realizao est
em posse de apenas uma pessoa de maneira no formalizada (tcito). Em outras
palavras, a idia perguntar para o gerente ou o responsvel por uma atividade:
qual atividade(s) ficar prejudicada se quais pessoas pararem imediatamente de
trabalhar aqui? Provavelmente, por uma ou outra razo, o domnio sobre a
realizao de algumas atividades est na mo de algumas poucas pessoas e esta
situao precisa ser mudada.
Figura 28 Etapas de Implantao e Manuteno da Gesto do Conhecimento (Marula, 2001)
Devem ser elaborados os procedimentos de apoio, que transformar o

conhecimento em explcito (passo C) e identificar os conhecimentos necessrios
para a realizao das atividades (passo D), pois nem todas as atividades podem ser
transformadas em explcitas com facilidade (MARULA, 2001).
No passo E obtm-se o mapa de conhecimentos necessrio a toda a operao

escopo do trabalho. Analisando o perfil das pessoas que esto nas diversas
posies realizando as atividades, pode-se identificar as lacunas de conhecimento
(passo F). Um trabalho importante a ser realizado a classificao dos
conhecimentos para definir a melhor forma de desenvolve-los (passo G), como um
sistema de informao (ramo esquerdo da Figura 28), ou como um tipo de
conhecimento mais tcito, onde a forma de tratar mais adequada atravs da
socializao (ramo da direita) (MARULA, 2001).
Conforme j explicado, no ramo da esquerda, o conhecimento pode ser tratado

como um sistema de informao atravs da coleta, processamento, armazenamento
e distribuio (passos I at L). Forma similar de tratamento aquele dado pela
implantao da ISO 9001, pois os processos de trabalho so identificados, descritos,

registrados e controlados (MARULA, 2001).
No caso de conhecimento voltado a atividades mais tcitas, como por exemplo,

atendimento a cliente ou mesmo o desenvolvimento de uma habilidade para uma
tarefa mecnica, a melhor forma fazer com que as pessoas trabalhem juntas, uma
o aprendiz outra o mestre (passo H). Observar que isso precisa ser feito de maneira
clara para as partes envolvidas para que haja a postura de ensinamento e de
aprendizagem (MARULA, 2001).
O modelo de Gesto da Qualidade, a Norma ISO 9001 tem a finalidade similar de

garantir que as atividades importantes para a qualidade so realizadas por pessoas
treinadas e capacitadas. Para tanto, os processos so identificados, explicitados,
treinados e controlados. Analisando o modelo proposto por Marula (2001), foi
observado que h uma similaridade com esse modelo, pois em uma pequena
organizao, a gesto do conhecimento implantada para garantir que no h
perda de conhecimento quando h rotatividades das pessoas. Foi realizada uma
pesquisa e identificado que a gesto do conhecimento pode ser um primeiro passo,
anterior implantao de um sistema de gesto da qualidade, conforme publicado
por Hegedus et.al (2002).
IV.5 GESTO DE SERVIOS
Na pesquisa realizada com Cooke (2000) sobre Gesto de

Servios, foi desenvolvido um modelo visando, atravs de
uma srie de tcnicas, fidelizar o cliente. H, nesse trabalho,
um modelo que prope uma taxonomia dos diferentes tipos
de servios, em funo do contato com o consumidor e o
valor agregado, conforme ilustrado na Figura 29. Esse
modelo til para ser analisado do ponto de vista da Fbrica de Software. Nas
colunas est representado o grau de contato com o cliente: esquerda o cliente
possui contato direto com o realizador do servio (pessoas), como por exemplo
assistncia tcnica domiciliar e direita o cliente somente tem contato com os bens
facilitadores como o caso do cinema. A coluna do meio representa uma situao
hbrida. Nas linhas est representado o valor agregado do servio prestado, se na
presena do cliente ou isolado do cliente. H tambm uma situao hbrida. Com
isso configuram-se 9 clulas com as combinaes duas a duas dessas
possibilidades.
Figura 29 Diferentes tipos de servios

Os exemplos facilitam a compreenso Cooke (2000):
Um cinema um servio com valor agregado na presena do cliente

realizado com bens facilitadores (a sala e o projetor de filme)
Uma assistncia tcnica domiciliar realizada na presena do cliente e

realizada por uma pessoa
Um corretor procura os imveis para seu cliente longe do mesmo e esse

trabalho realizado sem bem facilitador
Uma venda pela internet realizada atravs de bens facilitadores (a

internet) e efetivada isolada do cliente.
As demais clulas so casos mistos onde h pessoas e bens facilitadores ou parte

do valor agregado na presena do cliente Cooke (2000).
Esse modelo pode ser observado de duas formas:
sob a tica de analista de negcio, que vai analisar um servio do cliente

para implementar um sistema de tecnologia da informao, ou
sob a tica da prestao de servios de TI.
IV.5.1 A tica do analista de negcio
A TI tem sido muito utilizada como bem facilitador para prestao de servios. Caso
o servio esteja situado na coluna da direita, onde o prestador de servio no tem
pessoas para realizarem o atendimento, necessrio considerar esse fato nos
requisitos do sistema a ser projetado. Quando a situao hbrida, onde o prestador
de servio possui uma pessoa para apoiar ou orientar, isso no to importante pois
o cliente tem algum a quem recorrer se houver algum problema.
IV.5.2 A tica de prestao de servios de TI
Essa tica tem por utilidade organizar o prprio servio prestado.

Dessa forma, o levantamento de requisitos uma atividade realizada na presena

do cliente e o valor agregado est na presena do cliente, ou seja, o cliente percebe
que a rea de TI est interessada nos seus problemas. Nessa mesma clula esto
as atividades de implantao de software (Figura 30).
Figura 30 - enquadramento dos requisitos
A atividade de programao, por outro lado realizada com bens facilitadores e o

valor agregado isolado do cliente e, portanto, encontra-se em outra clula do
modelo (Figura 31).
Figura 31-enquadramento da programao
Esse modelo auxilia no planejamento dos processos de relacionamento com o

cliente. comum encontrar nas organizaes pessoas que tm dificuldade de
realizar um bom atendimento ao cliente, como por exemplo um tcnico de rede de
computador. Para desempenharem bem suas tarefas, fundamental que as
pessoas sejam adequadamente treinadas, principalmente aquelas que tm contato
com o cliente para realizar suas atividades. Se nessas atividades houver a maior
parte do valor agregado isso mais importante ainda.
IV.6 NOVAS TECNOLOGIAS DE COMUNICAO
Foram desenvolvidas duas pesquisas que analisaram a

aplicao da Internet no ambiente corporativo: Castilho
(1998) e Medeiros Jr. (2002). No primeiro trabalho,
desenvolvido por Castilho (1998), foi realizado um
levantamento de alguns casos de aplicao da internet nas
empresas. Naquela poca, a novidade era a utilizao da Intranet e foi identificado
que houve um aumento expressivo dos recrutamentos internos em uma das
organizaes estudadas. Antes do RH disponibilizar na Intranet as vagas para
recrutamento interno, essa informao era colocada em um mural. No entanto, as
pessoas ficavam constrangidas de analisar essas oportunidades na frente dos
colegas. Com a Intranet, essa atividade poderia ser feita de forma discreta no
prprio posto de trabalho, sem a exposio qual ficava o profissional na situao
anterior. Nesse trabalho no foi identificada nenhuma empresa que utilizava o
conceito de Extranet, ou seja, uma Intranet na qual participavam tambm outras
empresas (clientes ou fornecedores).
A segunda pesquisa, desenvolvida por Medeiros Jnior (2002), realizou uma anlise
das novas tecnologias de comunicao de dados utilizadas na cadeia de
suprimentos. Segundo Medeiros (2002) e Porter & Millar (1985), a cadeia de valor
o conjunto das atividades tecnolgicas e economicamente distintas que empresa
utiliza para realizar seus negcios. Cada uma dessas atividades seria uma atividade
de valor. A cadeia de valor compe-se de uma srie de atividades independentes
conectadas atravs das ligaes presentes sempre que uma atividade afetar o custo
ou a eficincia de outras atividades. Agregar valor nessa cadeia de maneira mais
significativa que seus concorrentes torna a empresa mais competitiva. A Figura 32
apresenta a cadeia de valor com as atividades meio e as atividades fim de uma
empresa.
Figura 32 Cadeia de Valor de Porter & Millar (1985)
Em um plano mais macro, onde se observa a cadeia de fornecimento, ou seja, os

diversos clientes e fornecedores que se encadeiam para prestar um servio ou
vender um produto para um usurio final, formado o sistema de valor (Figura 33).
Figura 33 Sistema de valor de Porter & Millar (1985)
A tecnologia da informao altera a execuo das atividades e a natureza das

ligaes entre elas. Isso ocorre tanto na cadeia de valor (dentro da empresa) como
no sistema de valor (na cadeia de fornecimento). O uso da internet tambm permite
mudanas estratgicas em manufaturas descentralizadas (RABECHINI JR, 2001). A
pesquisa realizada por Medeiros Jr. (2002), estudou a aplicao das novas
tecnologias na cadeia de suprimentos, ou seja, no sistema de valor .
A conexo entre as empresas, fornecedores e clientes, na cadeia de suprimentos

feita atravs do uso de EDI (Electronic Data Interchange). Essa tecnologia existe
desde a dcada de 60. Nessa poca utilizavam-se padres proprietrios e foram
criadas organizaes para desenvolver padres intra e inter-empresariais. A ONU
liderou um grupo de trabalho e criou um padro hoje conhecido como EDIFACT.

Os bancos no Brasil criaram, em 1979, um padro denominado CNAB para realizar
as transaes inter-bancrias, alm da criao de uma empresa, na qual diversos
bancos eram scios, para viabilizar tecnicamente essas conexes. O Quadro 3
apresenta a pesquisa realizada pela entidade ECR Brasil em 1998 que apontou as
vantagens de se adotar o EDI (MEDEIROS JR, 2006).
Indstria Atacadista Transportador Varejo

e e
Distribuidor Operador
Logstico
Agilidade na cadeia de suprimentos X
Atendimento a solicitao de parceiro X X
Avano tecnolgico X X
Agilidade nas informaes X X
Reduo de papis X
Qualidade das informaes X X
Reduo de erros operacionais X
Agilidade
embarcadores
no relacionamento com X
Quadro 3 Motivao para implantao de EDI (Medeiros Jr. 2002)
A mesma pesquisa apontou, conforme ilustra o Quadro 4, as dificuldades apontadas

para a implantao do EDI.
Indstria Atacadista Transportador Varejo

e e
Distribuidor Operador
Logstico
Integrao com sistemas internos X X X X
Resistncia de parceiros X
Adequao do layout X X X X
Resistncia interna X X
Dificuldades com o parceiro X X X
Desconhecimento do assunto pelo parceiro X X
Quadro 4 Principais dificuldades para implantao de EDI (Medeiros Jr. 2002)
Pode-se observar que a dificuldade apontada por todos a integrao dos sistemas
internos e a adequao do layout, ou seja, ajuste detalhado das informaes que
circulam entre as empresas.
O problema da utilizao desta tecnologia o alto custo da rede de comunicao de

dados. A Internet fez com que esse custo casse drasticamente, permitindo que os
servios de comunicao de dados ficassem em nveis de preo mais acessveis
(inclusive os anteriormente existentes). Embora tenha a vantagem de custo, a
internet possui uma disponibilidade inferior quela das redes fechadas. Por essa
razo, atividades que exigem grande volume de dados que circulam pela rede,
fazem com que ainda se adote servios especializados denominados VAN (Value
Added Network).
Vale comentar que, decorridos sete anos dessa pesquisa, continuam valendo os
mesmos conceitos e o que h de novidade, que na poca era muito incipiente,
comunicao mvel. Esse fato traz mais um fator positivo para a cadeia de
fornecimento, pois os sistemas de informao aumentam sua abrangncia
geograficamente, ou seja, h a possibilidade de se entrar com os dados em tempo
real, no momento do fato gerador. Isso melhora a questo do apontamento mais
exato (no tempo certo), reduz a possibilidade de erros de digitao (normalmente
so dispositivos de captura de dados como cdigo de barras), melhorando os
sistemas de gerenciamento. Outra tecnologia que evoluiu nesse perodo foi o RFID
(Radio Frequency Identification) que dever substituir o cdigo de barras e facilitar o
acompanhamento de materiais internamente empresa ou na distribuio (Glover,
Himanshu, 2007).
IV.7 DIRETRIZES ESTRATGICAS PARA EMPRESAS DE SOFTWARE
Na pesquisa desenvolvida com Del Maschi (2009), foi

desenvolvido um trabalho de definio de diretrizes
estratgicas para pequenas empresas de software.
O objetivo desta pesquisa foi demonstrar como a reviso da

misso da organizao e a elaborao de um plano
estratgico com abordagem em diferentes perspectivas,
contribuem para o aumento da competitividade no curto prazo. Neste trabalho, as
caractersticas de iteratividade e resoluo de problemas demandada pela
organizao objeto de estudo determinaram a metodologia pesquisa-ao. Esta
tcnica demonstrou-se muito adequada para esta situao onde havia um problema
real a ser resolvido e o aluno teve um papel duplo, como pesquisador e como
consultor. Essa situao obrigou-o a sistematizar melhor o trabalho de consultor,
fazendo com que cada diagnstico, identificao de situaes peculiares, fosse
realizado de forma sistemtica. Antes de propor cada ao a ser tomada, todo o
trabalho foi precedido de cuidadoso estudo, reviso bibliogrfica, enfim todos os
cuidados acadmicos, tornando o trabalho de consultoria mais slido com
embasamento justificado (DEL MASCHI, 2009).
Figura 34 Macro fluxo da Pesquisa-Ao (Del Maschi, 2009)
O roteiro macro da pesquisa est na Figura 34, elaborada a partir de Thiolent (1997)
e outros autores (DELMASCHI, 2009). A primeira fase foi realizar uma pesquisa
exploratria, a segunda fase foi uma pesquisa aprofundada cujo resultado foi a
proposio de aes a serem tomadas na terceira fase. Depois de realizadas essas

aes, a quarta fase avalia os resultados e, se necessrio, feita uma
realimentao, para novas aes (processo convergente). Nas fases anteriores
tambm podem ocorrer realimentaes para correo de eventuais desvios. Todo
este trabalho foi considerado como um projeto gerenciado com dois objetivos
distintos: a pesquisa e o trabalho de consultoria na empresa (DEL MASCHI, 2009).
O Quadro 5 mostra o protocolo de pesquisa elaborado. Na primeira coluna da

esquerda esto as quatro fases j citadas, na segunda coluna foi estabelecido o que
detectar, promover ou apresentar. A terceira coluna mostra base terica utilizada e a
quarta coluna apresenta os pontos de anlise ou os entregveis de cada uma das
fases.
Quadro 5 Protocolo de pesquisa (Del Maschi, 2009)
Na pesquisa exploratria foi selecionada uma empresa (denominada EOE- Empresa

Objeto de Estudo) que, alm de permitir a realizao da pesquisa, fosse de pequeno
porte, que comercializasse produtos de software, que estivesse preocupada com

planejamento de longo prazo, e que necessitasse realizar ou revisar um
planejamento estratgico (DEL MASCHI, 2009).
IV.7.1 Fase 1 Pesquisa Exploratria
IV.7.1.1 A empresa selecionada (entregvel 1)
A empresa selecionada iniciou as atividades em 1985, como uma empresa de

desenvolvimento de software sob demanda. Durante os dez primeiros anos seus
principais clientes foram empresas de consultoria de maior parte que no tinham
mo-de-obra especializada. A partir de 1995, a empresa passou a desenvolver
aplicativos voltados para a rea de recursos humanos particularmente gesto de
freqncia, o ponto eletrnico. O produto comercializado pela empresa tem como
principal caracterstica a automao das marcaes que tradicionalmente eram
realizadas manualmente. O sistema fornecido para os clientes (denominado SPE
Sistema de Ponto Eletrnico) realizado sob encomenda, pois integra-se com os
sistemas existentes (ERP ou outro). Cada sistema vendido, depois de entregue e
instalado, encerra a venda realizada. O interesse da empresa que os clientes
faam contratos de manuteno e suporte tcnico, pois se trata de uma receita
constante (DEL MASCHI, 2009).
A partir de 1996 a empresa decidiu reduzir as atividades com desenvolvimento de

software sob encomenda para investir no produto de ponto eletrnico denominado
SPE. Foi feito um investimento interno para desenvolver esse produto, em 1997 e
1998 o faturamento ficou estabilizado, de 1999 para 2001 houve um crescimento da
empresa em funo da evoluo da qualidade do SPE. A partir de 2002 houve uma
queda no faturamento, que objeto de anlise desta pesquisa (DEL MASCHI,
2009).
IV.7.1.2 Diagnstico inicial (entregvel 2)
Para a a elaborao do diagnstico Del Maschi (2009) utilizou-se de diversos

autores como Porter, Venkatraman, Kaplan & Norton, Zacarelli & Guimares,
Carvalho & Laurindo, conforme apresentado no Quadro 5. No primeiro passo foi
utilizado o modelo SWOT de Porter (1989): pontos fortes, pontos fracos,

oportunidades e ameaas.
Como pontos fortes foram identificados que o produto SPE possui baixo nvel de
defeitos, existe uma receita constante devido aos contratos de manuteno, a
equipe interna motivada e coesa, existe maturidade no gerenciamento dos projetos
internos, a implantao do produto nos clientes hoje requer muito pouco custo, o
treinamento e a implantao do produto podem ser realizados a distncia, o suporte
tcnico tem um nvel baixo de atividade.
Os pontos fracos so a reduo do faturamento, os colaboradores da rea de

desenvolvimento e suporte possuem alto grau de especializao, o que significa
uma ameaa no caso de perda da pessoa, um gerente comercial tem baixo
dinamismo, o produto demanda poucas inovaes, existe uma limitao da receita
devido no participao mais abrangente na cadeia de fornecimento de produtos e
servios de ponto eletrnico.
Oportunidades: o mercado de ponto eletrnico est em crescimento e vrias

opes de equipamentos com tecnologias diferentes para marcao de ponto e
registro de freqncia podem agregar valor ao SPE. Com pouco esforo podem ser
configuradas novas funcionalidades no produto. Os fabricantes de relgio de ponto,
catracas, cancelas de estacionamento e cartes de identificao demonstraram
interesse em realizar parceria com a empresa.
Ameaas: aumento da concorrncia, os fabricantes de equipamentos para ponto

eletrnico comercializam solues a preos inferiores, e as solues ERP possuem
mdulos para gerenciamento de freqncia.
IV.7.1.3 Atores envolvidos (entregvel 3)
O entregvel 3 a descrio dos atores envolvidos. No h interesse de detalhar

nesse texto.
IV.7.1.4 Iniciativas pr-existentes (entregvel 4)
O entregvel 4 o conjunto de iniciativas pr-existentes. A empresa j possua a

definio de misso e viso. Objetivos estratgicos tambm so definidos, mas o
acompanhamento de seu cumprimento no feito de forma sistemtica.
A empresa tambm possui parcerias, porm informais.
IV.7.1.5 Objetivos especficos da pesquisa (entregvel 5)
A caracterstica da pesquisa-ao , em sua primeira fase, realizar uma pesquisa

exploratria ao fim da qual so definidos os objetivos especficos. So eles:
(i) definir a abordagem de negcio,
(ii) identificar e tratar os fatores impeditivos para o posicionamento

estratgico,
(iii) estabelecer critrios para a configurao de novos produtos e servios,
(iv) traduzir a estratgia em termos operacionais.
IV.7.2 Fase 2 pesquisa aprofundada.
IV.7.2.1 Reviso da Viso de Futuro (entregvel 6)
Para se identificar este item foram utilizadas entrevistas semi-estruturadas com os

gerentes da rea da empresa e posterior divulgao a todos os participantes.
IV.7.2.2 Traduzir a estratgia em termos operacionais (entregvel 7)
A traduo para termos operacionais foi feita a partir da elaborao de questes

para os objetivos especficos. Esta abordagem permite melhor direcionamento da
pesquisa alm de favorecer o registro dos resultados.
Objetivo especfico 1 definir a abordagem do negcio
Questo A aumentar a oferta de novos produtos e servios.
Questo B obter dos clientes preferncia na aquisio de produtos

complementares.
Questo C mapear produtos e servios nos principais concorrentes,

buscando um posicionamento estratgico.
IV.7.2.3 Objetivo especfico 2 lidar com fatores impeditivos para o

posicionamento estratgico
Questo D definir a orientao da empresa se diferenciao por custo

ou enfoque. Dada a especializao da empresa, a orientao por
enfoque, particularmente no atendimento a empresas maiores.
Questo E mapear o nvel de dependncia de fornecedores
Questo F criar facilidades exclusivas e outros mecanismos para

garantir a conquista de novos clientes
Questo G estabelecer iniciativas para que produtos dos concorrentes

no sejam produtos substitutos
Objetivo especfico 3 estabelecer critrios para a configurao de novos produtos

e servios
Questo H entender quais fatores podem influenciar positivamente os

clientes na aquisio de novos produtos e servios
Questo I formar parceiros e alianas estratgicas com fornecedores de

produtos complementares
Questo J formar de parcerias ou alianas estratgicas com outras

empresas
Objetivo especfico 4 traduzir a estratgia em termos operacionais (BSC)
Questo K perspectiva financeira
Questo L perspectiva dos clientes
Questo M - perspectiva de processos internos
Questo N perspectiva de aprendizado e crescimento
Nesta etapa definida uma ao para cada uma das questes e com isso fica
encerrado o entregvel 7.
IV.7.3 Fase 3 Ao
Na fase 3, a ao trata da implementao dos itens estabelecidos na fase anterior.

Cada questo foi transformada em aes. Cada uma das aes definidas foi
estruturada na forma de projeto para garantir sua boa implementao. As aes
foram priorizadas de acordo com os critrios: facilidade, urgncia, margem lquida
estimada, o que virou o entregvel 8 (Quadro 6).
Quadro 6 Aes propostas priorizadas (Del Maschi, 2009)
Os projetos foram organizados em trs grupos e implementados com trs ciclos,

apresentado no Quadro 7. O primeiro ciclo tem como principais aes da abordagem
no custo total na diferenciao clara da empresa, cuja implementao de baixa
complexidade, urgente e traz um aumento na margem lquida atual. O segundo ciclo
caracterizado pelo incio da comercializao dos produtos complementares. O

terceiro ciclo marcado pela implementao do BSC (Balanced Scorecard).
Quadro 7 Ciclos das aes propostas priorizadas (Del Maschi, 2009)
No fechamento desta pesquisa j haviam ocorrido importantes resultados prticos.

Esses resultados foram conseqncia da implementao das aes, uma delas foi a
reorganizao do produto, a formao de parcerias estratgicas com outras
empresas para atingir um maior mercado. Os resultados foram o fechamento da
venda de vrios produtos resultado dessas aes e por conseqncia o aumento de
faturamento da empresa.
IV.7.4 Consideraes finais
A redefinio da abordagem de negcio com vistas concorrncia e aos possveis

parceiros e aliados, utilizando critrios para a configurao de produtos
complementares empresa, foram as principais razes para o aumento do
faturamento. A introduo de prticas de planejamento estratgico e suas
ferramentas, em pequenas empresas, ainda recente (DEL MASCHI, 2009).
A principal contribuio oferecida por essa pesquisa o estabelecimento de

diretrizes estratgicas para pequena empresa sempre preocupada com
competitividade, luz de um referencial terico clssico presente somente nas
grandes empresas. Outra contribuio importante foi o processo de conduo da
pesquisa-ao. Este modelo j est contribuindo como um template para novas
pesquisas similares que esto em desenvolvimento.
IV.8 RASTREAMENTO DE REQUISITOS
Na pesquisa desenvolvida com Oliveira (2002), foi

desenvolvido um modelo aplicvel produo de software,
que contempla todas as fases da engenharia de requisitos.
Segundo este autor, em 1996, o projeto ESPITI (European
Software Process Improvement Training Initiative) realizou
uma investigao sobre os principais problemas no desenvolvimento de software na
Europa e identificou que os maiores problemas estavam relacionados com a
especificao, a gesto e a documentao de requisitos. Outro fator importante
que o custo das mudanas de requisitos, uma vez entregue o produto, fica entre 60
e 100 vezes superior ao custo representado a mesma mudana durante as fases
iniciais do desenvolvimento (PRESSMAN, 2002).
O contexto de descrio de requisitos, conforme ilustrado na Figura 35, compreende

a base para o modelo proposto na dissertao. Foram utilizadas figuras geomtricas
para diferenciar a representao e o significado dos elementos (LEITE, apud
OLIVEIRA, 2002):
os octgonos representam os quatro elementos fundamentais, qual seja,

ambiente ou domnio da aplicao, problemas, requisitos e stakeholders;
os retngulos e caixas de dilogos representam as caractersticas

associadas aos elementos do modelo;
o espiral representa os processos da Engenharia de Requisitos e a

aplicao das tcnicas;-
a prancheta representa o produto resultante, o documento de requisitos.

Figura 35 Uma abordagem de Requisitos (OLIVEIRA, 2002).
Na Figura 35 esto representados os principais elementos da abordagem de

requisitos (OLIVEIRA, 2002):
Ambiente ou Domnio da Aplicao onde ocorrem os fenmenos que

caracterizam os problemas referentes aos requisitos particulares do
cliente.
Stakeholders compreende o conjunto de pessoas ou objetos que, direta

ou indiretamente, so afetados pela soluo de sistema a ser construda
Problema a diferena de algo como desejado em relao a algo como

percebido pela fonte de informao.
Requisito uma declarao descritiva de exigncias, escrita do ponto de

vista dos stakeholders, para os quais ser provida a tecnologia da
informao e o compartilhamento de recursos na soluo de problemas.
A seguir so descritas as caractersticas relacionadas com cada elemento:
Ambiente ou Domnio da Aplicao
Cultura Organizacional refere-se s regras e normas que regulamentam

a organizao, comportamentos, hbitos e costumes. Tambm pode ser
entendida como um conjunto de pressuposies bsicas compartilhadas

que o grupo de pessoas nela envolvida aprenderam como resolver seus
problemas de adaptao externa e integrao interna, que tem funcionado
suficientemente bem para ser considerada vlida.
Tecnologias referem-se aos avanos tecnolgicos e aos impactos sobre

o ambiente e a cultura organizacional.
Mudanas refere-se dinmica social e organizacional do elemento

humano como agente de mudana no ambiente.
Stakeholders
Expectativas as expectativas so declaraes do cliente quanto forma

de ver atendida uma demanda. So originadas do conhecimento do
problema e do ambiente, cuja satisfao refere-se soluo.
Preferncias as preferncias so condies desejveis e particulares do

cliente, porm opcionais ao produto de software. So condicionadas
definio prvia dos atributos e das restries dos requisitos. Ou seja, so
circunscritas no espao de soluo do problema.
Prioridades a definio do que prioritrio pelos stakeholders uma

condio essencial no processo de desenvolvimento de software. O
processo essencialmente limitado pela disponibilidade de recursos
(humanos, financeiros, tecnolgicos...) e pelo fator custo de produo.
Problema
Fatos ou Fenmenos um fato uma verdade simples acerca do mundo.

Um fenmeno refere-se forma de ver o mundo, depende de
interpretao do contexto e do impacto que causa, sob o ponto de vista de
quem o interpreta. O conhecimento de ambos e a identificao de quem
os relatam so as bases que permitem o entendimento do problema.
Requisito
Funes as funes so aes nas quais o requisito declarado.

Especificam a produo de algo, a partir de um elemento de entrada e um
resultado como produto. Descrevem o que fazer para atender finalidade
proposta.
Atributos Os atributos so dimenses das caractersticas de

funcionalidade e de qualidade dos requisitos. Estes devem ser
consistentes, confiveis e completos, com representatividade de pontos de
vista das fontes de informao para que se promova a garantia de
qualidade do produto descrito.
Restries as restries so limitaes que delineiam o espao de

soluo do problema. Tornam-se critrios de aprovao ou recusa para
um produto.
Pocessos de Engenharia de Requisitos (RE)
A aplicao dos processos (Figura 35) e a utilizao de tcnicas de Engenharia de

Requisitos (RE) devem iniciar antes da definio do software a ser construdo e
basear-se no conhecimento inicial do problema, fase identificada como de
descobrimento de requisitos. As tcnicas aplicveis referem-se a planejamento,
mtodos, mtricas, normas e padres entre outras (OLIVEIRA, 2002):.
Produto da Abordagem de Descobrimento de Requisitos
O resultado da aplicao dos processos de Engenharia de Requisitos caracteriza-se

pelo documento de requisitos(OLIVEIRA, 2002):.
IV.8.1 Modelo proposto
O modelo proposto foi elaborado a partir dos modelos estudados nesta pesquisa.
Representa uma abordagem para consolidar a idia de orientar o estudo sobre o
foco do problema para o gerenciamento dos requisitos. Nesse modelo so
apresentadas trs possibilidades de iteraes, sendo duas internas e uma externa,
conforme a Figura 36 (OLIVEIRA, 2002):.
Figura 36 Modelo proposto (OLIVEIRA, 2002)
IV.8.1.1 Ciclos de uso do modelo
Ciclo Extrao-Anlise-Validao
O ciclo principal extrao-anlise-validao um ciclo que indica a possibilidade de

que durante o processo de validao dos requisitos por parte dos clientes e
usurios, apaream conflitos ou novos requisitos que at ento estavam ocultos.
Nestas circunstncias, necessrio resolver estes conflitos e validar os novos
requisitos mediante reunies para extrao e negociao, repetindo as atividades de
anlise e validao.
Ciclo da Prxima Iterao
O segundo ciclo, entre o processo de requisito e a prxima iterao, mostra a

possibilidade de que durante o restante do desenvolvimento seja necessrio retornar
a alguma das atividades do processo de requisitos, possivelmente porque
detectada a necessidade de renegociar alguns requisitos de difcil implementao,
ou at mesmo por aparecerem novos requisitos durante o desenvolvimento.
Ciclo da Gesto das Mudanas
O terceiro e ltimo ciclo envolve a gesto de mudanas dos requisitos de software.

Uma das razes para isso que a maioria dos sistemas so geralmente
desenvolvidos para lidar com problemas complexos. Como o problema no pode ser
inteiramente definido, os requisitos de sistemas so necessariamente incompletos.
Durante o processo de software, a compreenso dos desenvolvedores sobre o
problema est constantemente se modificando, e essas mudanas refletem nos
requisitos. Alm disso, mudanas nos requisitos de software so geralmente
necessrios para melhorar o status atual dos sistemas.
IV.8.1.2 Processo da Engenharia de Requisitos
O processo de Engenharia de Requisitos pode ser descrito em quatro passos

distintos (OLIVEIRA, 2002 , SOMMERVILLE, 2003): extrao, anlise, validao e
gerncia de requisitos descritos a seguir.
Extrao de requisitos 7
No modelo proposto a extrao de requisitos a atividade mais importante, pois

mantm uma interao entre clientes e usurios com os engenheiros de requisitos.
A Figura 37 ilustra as principais atividades para a extrao de requisitos.
Figura 37 Objetivos da extrao de requisitos (OLIVEIRA, 2002)
Anlise de requisitos
7
O termo em ingls para essa atividade requirement elicitation que, se traduzido sem o
devido cuidado, ficaria elicitao de requisitos. No item IV.8.3 h um comentrio mais detalhado
sobre esse termo.
Uma vez reunidos, os produtos de trabalho mencionados anteriormente formam a

base para a anlise de requisitos. A anlise categoriza os requisitos e os organiza
em subconjuntos relacionados; explora cada um em relao aos demais; examina-
os quanto consistncia, omisses e ambigidade; e ordena-os com base nas
necessidades dos clientes e usurios.
medida que a atividade de anlise de requisitos comea, as seguintes perguntas

so formuladas e respondidas (OLIVEIRA, 2002, SOMMERVILLE, 2003):
Cada requisito est consistente com o objetivo global do sistema/produto?
Todos os requisitos foram especificados no nvel de abstrao adequado?

Isto , algum requisito fornece um nvel de detalhe tcnico inadequado
neste estgio?
O requisito realmente necessrio ou representa uma caracterstica

adicional que pode no ser essencial para o objetivo do sistema?
Cada requisito limitado e no-ambguo?
Cada requisito tem atribuio? Isto , uma fonte (geralmente um indivduo

especfico) est associada a cada requisito?
Algum requisito conflita com outros requisitos?
Cada requisito realizvel no ambiente tcnico que vai alojar o sistema

ou o produto?
Cada requisito pode ser testado, quando estiver implementado?
No incomum que clientes e usurios peam mais do que pode ser conseguido,
considerando os recursos limitados do negcio. tambm relativamente comum que
diferentes clientes ou usurios proponham requisitos conflitantes. O engenheiro de
requisitos precisa reconciliar esses conflitos por intermdio de um processo de
negociao. Os riscos associados com cada requisito so identificados e analisados.
Validao de requisitos
Os produtos de trabalho produzidos como conseqncia de Engenharia de

Requisitos so avaliados quanto qualidade durante o passo de validao. A
validao de requisitos examina a especificao para garantir que todos os
requisitos do sistema tenham sido declarados de modo no-ambguo; que as
inconsistncias, omisses e erros tenham sido detectados e corrigidos e que os

produtos de trabalho estejam de acordo com as normas estabelecidas para o
processo, projeto e produto.
IV.8.1.3 Gerncia de mudanas de requisitos.
Os requisitos para sistemas baseados em computador mudam e o desejo de mudar

os requisitos persiste ao longo da vida do sistema. Gesto de mudanas de
requisitos um conjunto de atividades que ajuda a equipe de projeto a identificar,
controlar e rastrear requisitos e modificaes de requisitos em qualquer poca,
medida que o projeto prossegue.
Como em qualquer processo de gerncia na Engenharia de Software, a gesto de

requisitos comea com identificao. A cada requisito atribudo um modo nico de
identificar que pode tomar a forma: <tipo de requisito> <requisito>. Em que, tipo de
requisito toma valores tais como F= requisito funcional, N= requisito no-funcional,
T= requisito tcnico.
Uma vez identificados os requisitos, tabelas de rastreamento so desenvolvidas.

Com esse controle pode-se criar um processo para controle dessas alteraes onde
podem ser definidas 4 tarefas: registro da solicitao de alterao, identificao e
seleo dos requisitos, anlise de impacto das mudanas e comunicao das
mudanas ocorridas.
IV.8.1.4 Mtricas de Requisitos
A principal meta da Engenharia de Software produzir um sistema, aplicao ou

produto de alta qualidade. Para atingir essa meta, engenheiros de requisitos devem
aplicar mtodos efetivos combinados com modernas ferramentas dentro do contexto
de um processo de software amadurecido.
IV.8.2 Aplicao do modelo proposto e resultados
O modelo descrito foi aplicado em um caso real. Para a elaborao dos diagramas
como casos de uso, diagramas de seqncia, foi utilizado o produto Rose da IBM.
Para o gerenciamento dos requisitos e suas alteraes, foi desenvolvida uma
ferramenta especfica, onde cada um dos requisitos foi codificado e acompanhado.

(OLIVEIRA, 2001, 2002, 2002a).
O fator mais importante de aplicao do modelo de gerenciamento de requisito foi a

abordagem de tratamento da informao para a compreenso do problema. Define-
se um requisito quando se tem um problema e a vontade de solucion-lo.
A adoo de um formalismo para representao do requisito no processo de

software com uma linguagem natural, apropriada para a fase inicial a que se
prope o modelo, ou seja, de descobrimento e gerncia de requisitos, a partir do
conhecimento de problemas. Sob este ponto de vista, s adotada uma estrutura
formal para descrever o requisito em forma de sentena simples declarando a
funcionalidade, conforme os documentos de descrio de requisitos. As demais
informaes na qual ficam livres de formalismo para representar opinies e
condies, como registro complementar e de possvel reuso posterior.
O processo de gerncia gera um custo adicional de tempo ao trabalho de anlise,

pela exigncia da participao dos stakeholders basicamente em todas as fases do
processo. Mas, sistematizado e bem entendido, o processo pode ser agilizado desde
que o engenheiro de requisitos aproveite a disponibilidade dos stakeholders,
dispense a burocracia de agendar com muita antecedncia e controle o tempo
requerido para as fases repetitivas de reavaliao dos requisitos, utilizando
objetividade sobre o que quer de resposta.
IV.8.3 A questo do termo eliciao de requisitos
Embora este item no esteja exatamente na linha de descrio das pesquisas

realizadas, vale aqui uma observao sobre a displicncia que muitos
pesquisadores tm com a lngua portuguesa. De uma maneira geral, durante o
desenvolvimento das pesquisas, um cuidado que este Autor tem tomado identificar
a correo dos termos tcnicos utilizados, pois muito comum a traduo direta de
termos de outras lnguas e criar neologismos desnecessrios. H muitos termos
utilizados conscientemente pelos pesquisadores e profissionais de computao que
so neologismos e que, depois de muitos anos de uso, passam a incorporar o lxico
brasileiro. Um exemplo inicializao que, embora saibamos que a traduo de
inicialization iniciao, hoje esse termo consta no vocabulrio ortogrfico
brasileiro da Academia Brasileira de Letras (Portella, E. et all, 2004). Os termos

resetar e elicitar, no entanto, ainda no constam desse mesmo vocabulrio.
No trabalho desenvolvido por Kleber (Oliveira, K.R, 2002) houve esse cuidado.
Tanto o texto da dissertao como em todos os artigos escritos nessa poca foram
escritos utilizando o termo eliciao, escolhido como traduo de elicitation.
Eliciao um termo pouco conhecido, mas tem como significado extrair, obter
(Michaelis, 2009) ou o significado expulsar, fazer sair, exconjurar (Ferreira, 1986;
Lello, 1968; Priberam, 2009) em referncias brasileiras, portuguesas, recentes e
antigas. O termo elicitar no consta em nenhum dos dicionrios acima
referenciados. No entanto, em diversas situaes, avaliadores de artigos elaborados
por Oliveira e este Autor apontaram o termo eliciar como errado e houve at um
caso de rejeio de artigo submetido a um congresso.
Oliveira (2009) defendeu sua tese de doutorado que continuou sua linha de pesquisa
no tema Engenharia de Requisitos. Nesta pesquisa o autor passou a utilizar o termo
elicitao alegando que no gostaria mais de arriscar ter problemas de aprovao
de artigos por causa disso. Talvez esta seja apenas uma questo de tempo para que
este termo seja realmente incorporado lngua portuguesa. Talvez no.
IV.9 ENGENHARIA WEB.
Na pesquisa em desenvolvimento com Gonalves (2005), foi

identificado que a produo de aplicaes Web possui
caractersticas peculiares, pois envolve aspectos
multidisciplinares tais como criao de contedo, produo de
mdias, aspectos estticos, tecnolgicos e de
desenvolvimento de software. Os mtodos atuais existentes
na Engenharia de Software no so satisfatrios para esse tipo de projeto, pois os
profissionais envolvidos possuem formaes e caractersticas eclticas, que
precisam ser harmonizadas no processo, para que as atividades possam ser feitas
em paralelo e sem conflito. Alguns autores esto chamando esta rea de
Engenharia Web.
Para Pressman, uma aplicao Web pode ser desde uma simples pgina at um
Web site completo (PRESSMAN, 2006, GONALVES, 2005, 2005 a). Essa gama
to extensa de tipos de stios encontrados na internet levou a uma proposta de
classificao similar que Nolan props (NOLAN, 1979) para aplicaes de
Sistemas de Informao (MEDEIROS JNIOR, 2005). Nessa proposta, foi realizado
um levantamento para identificar que os stios evoluem desde um estgio primitivo
com pginas estticas at stios com aplicaes altamente sofisticadas e complexas
como pode ser observado nos stios das instituies financeiras. Evidentemente o
processo utilizado para o desenvolvimento dos stios em cada um desses estgios
diferente, bem como a qualificao dos profissionais neles envolvidos.
Conallen (1999) apud Gonalves (2005), considera que aplicao Web um Web
Stio no qual implementada uma lgica de negcio e cujo uso altera o estado do
negcio. Segundo Paula Filho (2003), Aplicaes Web so
produtos de software ou sistemas de informtica que utilizam uma

arquitetura distribuda, pelo menos parcialmente sob protocolo http. Em
conseqncia, pelo menos parte das interfaces com o usurio acessvel
atravs de um navegador (browser)
Ambas as definies so adotadas neste trabalho, acrescentando que aplicaes
Web so tambm baseadas em estrutura de hipertexto e/ou hipermdia. Este
trabalho enfoca aplicaes Web interativas e com funcionalidade complexa. Por sua
vez, o termo design entendido aqui no como na acepo da palavra em ingls

projeto ou desenho (nomenclatura normalmente empregada na Engenharia de
Software), mas como a atividade de projeto de um produto que busca conciliar e
integrar os aspectos tcnicos tanto de produo como do produto em si com os
aspectos estticos e socioculturais que o produto deve atender. Web Design o
design de pginas Web e Web Sites. Segundo Hauffe (1996),
o trabalho do designer (profissional de design) tem diversos pontos de foco:

o artstico/esttico, o tcnico/funcional, a orientao mercadolgica
(marketing), o terico/cientfico e o organizacional/ administrativo.
Gonalves (2005, 2005 a) afirma que as aplicaes Web so tipicamente produzidas
em um ambiente de trabalho multidisciplinar. Entretanto, difcil encontrar na
literatura alguma abordagem da produo de aplicaes Web que considere de
forma sistmica o aspecto multidisciplinar do desenvolvimento. Muitos trabalhos
enfocam somente o aspecto de desenvolvimento de software; outros enfocam o
aspecto de design, com foco em esttica e mdia; outros enfocam a produo de
contedo informativo, arquitetura da informao e redao de texto para Web. So
deixados de lado aspectos fundamentais do ponto de vista de processo de produo
de software:
Como equipes multidisciplinares trabalham de forma coordenada?
Quais os papis desempenhados pelos profissionais no desenvolvimento?
Quais so as competncias, tcnicas e ferramentas necessrias? Como

as atividades so organizadas em paralelo?
Qual o processo seguido?
Como o resultado do trabalho de cada profissional integrado em um

nico produto?
Para o desenvolvimento desse trabalho foram estudados diversos aspectos para

compreender melhor a produo de software tanto do ponto de vista do profissional
que produz o software, como do usurio final que vai utilizar esse tipo de aplicao.
Um dos trabalhos desenvolvido foi estudar a criao de um ambiente de engenharia

simultnea aplicado ao projeto de edificaes em engenharia civil, utilizando a web
como suporte ao trabalho colaborativo da equipe geograficamente distribuda. Esse
estudo foi publicado em Gonalves (2008) e discute os desafios referentes a aspetos

ergonmicos desses sistemas.
Em Gonalves (2005b) foram analisados aspectos que so relevantes na

modelagem de processos de negcio e que devem ser contemplados pelos
diferentes instrumentos de modelagem. Como hiptese, foi estabelecido um aspecto
adicional: a importncia de representar, na modelagem, as pessoas envolvidas com
os processos. Para demonstrao da hiptese, feita uma discusso de diferentes
instrumentos de modelagem e da UML, em particular, aplicando-a a reengenharia de
processos de negcio.
Em Gonalves (2005c) proposto o conceito de entropia associada a postos de

trabalho como uma mtrica para avaliao quantitativa e qualitativa do estado de
desordem associado ao posto de trabalho. So identificados fatores para os quais
favorvel o aumento e outros para os quais favorvel a reduo da entropia, para
a melhoria da condio de trabalho, considerando os aspectos de aprendizagem de
tarefas, monotonia, conforto, variabilidade e propenso a problemas msculo-
esquelticos.
O trabalho desenvolvido com Gonalves (2007) discute a abordagem da Engenharia

da Web a partir de fundamentos de Engenharia Simultnea, relacionando o
processo de desenvolvimento com as caractersticas das aplicaes, com atividades
multidisciplinares e com a participao dos usurios no processo. D-se
continuidade a pesquisa anterior, baseada em estudo de caso, com uma abordagem
de pesquisa-ao. Verifica-se que fundamentos de Engenharia Simultnea podem
ser aplicados produo de aplicaes Web, suprindo lacunas ainda imaturas na
Engenharia da Web. Para Rodriguez apud Gonalves (2005), o processo de
desenvolvimento para Web pode ser decomposto em dois sub-processos:
sub-processo de autoria (auth), o qual cria a estrutura de hipermdia
sub-processo de desenvolvimento de infra-estrutura (inf), o qual

providencia a integrao com base de dados, desenvolvimento em
linguagem de programao, integrao com outros sistemas, etc.
As atividades de ambos os processos so realizadas nos fluxos de trabalho do

processo de desenvolvimento de software convencional (requisitos, anlise, projeto,
implementao e testes), conforme representado na Figura 38. Embora os autores
tenham previsto uma interface entre os sub-processos, no deixam claro como isto
se realiza.
Figura 38 Processo de desenvolvimento para Web (Gonalves, 2002)
O termo autoria utilizado para referenciar o trabalho criativo de produo e

organizao do contedo esttico e informativo. Segundo Pressman (2006), as
Aplicaes Web so inerentemente guiadas por contedo. Os provedores de
contedo so projetistas grficos, redatores, produtores de mdia, entre outros. O
termo autoria est relacionado a tudo que pode ser caracterizado como propriedade
intelectual e resultante de trabalho criativo.
Em Laino (2008) estudada a adoo de uma ferramenta do tipo Wiki para Gesto
do Conhecimento em uma grande instituio financeira brasileira. Utiliza-se o
mtodo do Estudo de Caso atravs de analise documental e entrevistas realizadas
com analistas e gestores. A ferramenta Wiki foi adquirida h 3 anos atrs porm seu
uso no to disseminado como esperado. O principal resultado da pesquisa foi
identificar que a contribuio da ferramenta para Gesto do Conhecimento
percebida de forma diferente por analistas e gestores. Os primeiros so unnimes
em afirmar que a ferramenta garante a realizao de todo o ciclo do conhecimento,
enquanto os ltimos so unnimes em afirmar que no, embora possa contribuir.
A pesquisa est em andamento e seu objetivo contribuir com a engenharia Web

propondo um processo de projeto de Sistemas Web que tenha uma abordagem
sistmica top-down (do geral para o particular), permita simultaneidade de tarefas e
atenda os demais requisitos aqui apresentados.
Figura 39 Abordagem proposta para projetos Web (Gonalves, 2002)
As caractersticas gerais desse modelo esto listadas a seguir:
deve incorporar uma viso em alto nvel dos sub-processos de autoria e

de infra-estrutura, conforme modelo de Rodriguez et al. (2002).
deve oferecer uma representao explcita dos papis e atividades,

caracterizando o desenvolvimento multidisciplinar.
deve proporcionar o paralelismo da realizao das atividades de projeto.
deve atender aos diferentes padres de aplicaes Web, conforme o

conceito de padres de projeto para Web pode ser utilizado.
deve permitir que o processo seja instanciado a partir das caractersticas

do padro da aplicao a ser desenvolvida.
deve prover uma interface de integrao entre as atividades

multidisciplinares. O papel do Engenheiro da Web pode realizar esta
funo.
deve permitir a previso das atividades e papis (um dos objetivos

prticos do trabalho) tendo como entrada as caractersticas da aplicao a
ser desenvolvida.
Foi observado nas pesquisas de campo j realizadas que as dimenses para o

projeto de um sistema Web so: Forma, Funo e Informao. A Engenharia de
Software aborda Funo e Informao e no estuda a questo de Forma. Os
profissionais de Design estudam os aspectos referentes a Forma e Funo, mas no
abordam a Informao e os profissionais de Comunicao e Mdia abordam as
questes referentes a Forma e Informao, no abordando a Funo (Figura 40).
Figura 40 - Dimenses do modelo (Gonalves, 2009)
Portanto este o modelo que est se delineando como integrativo das trs
abordagens para a realizao de sistemas Web (Gonalves, 2009).
Processos e Projetos em uma Fbrica de Software eLab-TI V-93
V ARQUITETURA DA SOLUO
Arquitetura da Soluo este tema possui uma abordagem

tcnica, voltada criao da soluo e uma abordagem
gerencial de definio do projeto. As pesquisas desenvolvidas
at o momento esto voltadas s questes de
gerenciamento. Foram desenvolvidos ao todo 4 trabalhos,sendo um trabalho de
formatura, uma dissertao de mestrado e 2 teses de doutroado.
Modelos Matemticos para Planejamento de SI

Mtricas, Oramento e Planejamento
Competncia e Maturidade em gesto de Projetos
Gerncia de Projetos e do Conhecimento
V.1 MTRICAS, ORAMENTO E PLANEJAMENTO
Na pesquisa desenvolvida com Trindade (1999) foi feito um

levantamento dos mtodos existentes para determinao do
tamanho e esforo do software.
A orientao de trabalhos de formatura ofereceu uma

oportunidade interessante para se aprofundar no modelo
COCOMO de Boehm (1981). O trabalho de Okumura (1988) permitiu fazer a
confirmao do funcionamento adequado dos modelos empricos de estimativa de
projeto de software. Bohem (1981) havia publicado o modelo COCOMO cuja
finalidade era, atravs da estimativa do tamanho do software (nmero de linhas de
programao), estimar o esforo necessrio e a equipe (nmero de pessoas). O
modelo possua trs nveis de refinamento: o modelo bsico, o intermedirio e o
avanado. A pergunta colocada na poca foi: ser que um modelo desenvolvido
dentro da realidade americana com condies de trabalho diferentes das existentes
no Brasil, com cultura e mtodos diferentes, seria aplicvel aos nossos projetos?
Nessa poca (1987) software era essencialmente desenvolvido para mainframe e,

portanto, o ambiente era mais uniforme do que hoje. Foram solicitadas para 25
empresas que fornecesse os dados de projetos j encerrados, ou seja, aqueles que
possuam as informaes completas: tamanho (nmero de linhas de cdigo), esforo
(nmero de homens-hora realizados), equipe (nmero de participantes) e prazo de
realizao do projeto. Participaram desta pesquisa 14 respondentes e as

informaes foram tratadas em um software de estatstica Statpac para identificar
se, o modelo daria resultados similares ou divergentes. Tais informaes foram
colocadas no modelo COCOMO (modelo semi-detalhado): dado o tamanho do
software foi calculada o esforo, equipe e prazo. Os resultados foram muito similares
ao dado pelo modelo, demonstrando que tambm para o ambiente brasileiro o
modelo tambm se aplica (embora o aluno tenha cometido alguns deslizes
estatsticos, os resultados foram muito bons). Cabe salientar que foi apenas
comprovado que o modelo se aplicaria no Brasil. No foi verificado se esses projetos
foram realizados dentro dos prazos que cada responsvel planejou, mas ficou
demonstrado que, se cada gerente tivesse condies de estimar corretamente o
tamanho do software a ser construdo e aplicasse o modelo, o planejamento seria
muito prximo do realizado.
Figura 41 Comparao entre estimativas do COCOMO e resultados reais (Okumura, 1988)
Esse trabalho motivou realizar uma outra pesquisa, agora de mestrado, com
Trindade (1999). A idia era identificar quais eram os modelos (conceituais)
existentes para a realizao de oramento e planejamento de projetos de software.
Trindade (1999, 1999 a) identificou (na poca) 16 mtodos diferentes para
estimativas dos quais os mais conhecidos eram o COCOMO, APF (anlise por
pontos de funo) e comeava a se esboar o modelo use case points. Nessa poca
comeava a haver uma proliferao grande de aplicaes para diferentes ambientes

tais como PCs, servidores e mainframe (quase nada para internet ainda). A
complexidade para realizar estimativas estava aumentando muito, fato que motivou
Boehm a iniciar a pesquisa que gerou a atualizao de seu modelo, o COCOMO II.
Mais uma vez ficou concludo, em sua pesquisa, que na prtica esses modelos eram
muito pouco aplicados. Foram contatadas 404 entidades entre empresas,
profissionais, associaes, universidades, institutos de pesquisa dos quais 108
participaram da pesquisa de campo. Dois resultados so interessantes: apenas 25%
dos participantes utilizam mtricas formais no oramento de projeto. De 34
empresas e profissionais consultados, 19 (56%) utilizam modelos cientficos
formalmente publicados para estimativas (ponto de funo, Cocomo, etc) , 2 (0,6%)
possuem um modelo proprietrio e 13 (38%) no utilizam nenhum modelo, mas sim
a experincia dos profissionais. Com relao eficcia, foi obtido um ndice de
satisfao de 69% de respondentes que considera satisfeito com o uso dessas
ferramentas.
Durante o processo de desenvolvimento 43,5% dos participantes fazem o uso de

algum tipo de medio.
Uma concluso importante retirada dessa pesquisa a falta de maturidade das

empresas com relao a utilizao de mtricas para oramentao, particularmente
pelo fato de que poucas empresas possuem um processo para armazenar dados
histricos. A realidade hoje (2009) bem diferente pois mais comum o uso da
tcnica pontos de funo, fato que mereceria realizar uma nova pesquisa similar a j
realizada em 1999.
V.2 COMPETNCIA E MATURIDADE EM GESTO DE PROJETOS
Na pesquisa desenvolvida com Rabechini Jr. (2003) foi

estudada, com uma viso de gerenciamento de projeto, a
questo das competncias e maturidade na execuo de
projeto. Atravs da abordagem de estudo de mltiplos casos,
foram investigadas as prticas de maturidade no
gerenciamento de projetos e os resultados de levantamentos
em trs empresas de setores distintos. Inicialmente so apresentados e discutidos
dois casos para a proposio de um modelo e o terceiro caso utilizado para a
aplicao desse modelo. A principal questo de pesquisa : como as empresas
podem se estruturar para desenvolver competncias, visando a atingir maturidade
em gerenciamento de projetos?
A abordagem terica utilizada partiu da bibliografia sobre projeto, seguindo para o

conceito de gerenciamento de projetos, a identificao de fatores crticos de sucesso
que garantam o bom desempenho dos projetos, a anlise das competncias em
gesto de projetos e finalmente a maturidade em gesto de projetos (RABECHINI
JR, 2003).
Projeto um processo nico, constitudo de um grupo de atividades coordenadas e

controladas com datas para incio e trmino, empreendido para alcanar um objetivo
conforme requisitos especficos, incluindo limitaes de tempo, custos e recursos.
(ISO 1006 apud Rabbechini Jr, 2003).
O Gerenciamento de Projetos inclui o planejamento, a organizao superviso e

controle de todos os aspectos do projeto, em um processo contnuo, para alcanar
seus objetivos (ISO 10.006 apud Rabbechini Jr, 2003). O Gerenciamento de
Projetos a aplicao de conhecimentos, habilidades, ferramentas e tcnicas s
atividades do projeto visando atender ou superar as necessidades e expectativas
que os interessados possuem no projeto (PMBoK, 2000); (Rabbechini Jr, 2003).
Os Fatores Crticos de Sucesso so a identificao dos fatores que implicam em

sucesso ou fracasso de projetos e fornecem uma excelente fonte de ajuda para
identificar competncias e maturidade das empresas.
Para Le Boterf apud Rabechini Jr (2003), competncia saber agir (ou reagir) de
forma responsvel e validada. So trs eixos fundamentais que compem a
competncia: caractersticas pessoais, formao educacional e experincia
profissional. Dessa forma o indivduo competente no aquele que tem
determinados recursos mas sim aquele que consegue mobiliz-los em momento
oportuno, sob a forma de conhecimento, capacidade cognitiva de, capacidade de
relacionamento, entre outros.
Em gerenciamento de projetos podem ser observados trs tipos de competncias:

as individuais, as das equipes e as organizacionais (RABECHINI JR, 2003, 2005).
A competncia individual refere-se s aptides e habilidades dos indivduos na

soluo de problemas.
As competncias de equipe referem-se possibilidade de indivduos trabalharem

em conjunto visando atingir os objetivos do projeto.
As competncias organizacionais referem-se possibilidade de indivduos ou

equipes conduzirem seus projetos de foram alcanarem os objetivos propostos,
dando maior competitividade empresa.
O conceito de Maturidade em Gerenciamento de Projetos surgiu inspirado no

modelo CMM. Uma empresa imatura caracteriza-se pela improvisao do
gerenciamento. Uma empresa madura possui a habilidade gerencial para
desenvolvimento do processo de administrao do projeto. Nesse sentido, a partir
do estabelecimento de um planejamento adequado, as especificaes so
detalhadas, e o projeto executado e controlado devidamente evitando desperdcio
de recursos e prazo.
V.2.1 O modelo proposto
Rabechini Jr (2003, 2005) prope um modelo gerado a partir de tres pilares

conceituais bsicos: estratgia, processos e efetivao da mudana capazes de dar
sustentao s camadas de competncias envolvidas na institucionalizao de
gerenciamento de projetos: indivduo, equipes e organizao (Figura 42).
Figura 42 Modelo de Competncias em gerenciamento de Projetos (Rabechini Jr., 2003)
Estas camadas formam uma base conceitual-terica, apoiada na crena de que a

institucionalizao do gerenciamento de projetos numa empresa s acontece se
forem geradas competncias de forma integrada, consistentemente.
As camadas de competncias apoiam-se em distintos pilares capazes de

viabilizarem seus respectivos desenvolvimentos.
Pilar da Estratgia
O primeiro pilar se refere s questes da estratgia. Nos termos deste modelo, se

refere a definio estratgica de situaes de institucionalizao de gerenciamento
de projetos, considerando-se os indivduos, equipes e organizao.
Este pilar caracteriza-se por apoiar e estabelecer as diretrizes em relao ao

desenvolvimento de gerenciamento de projetos, para todas as competencias. Estas
diretrizes foram criadas para nortear o desenvolvimento das outras dimenses deste
modelo. Entre os aspectos importantes a serem considerados neste pilar, no
exaustivamente, destacam-se:
Desenvolvimento de diretrizes que visa estabelecer um escritrio de

projetos (project office) que, por sua vez dar suporte a toda a
organizao no que se refere a gesto de projetos;
Carreira do gerente de projeto e como consequencia, sua remunerao

profissional;
Carteira de projetos como opo gerencial de organizao e
Priorizao de projetos na organizao
Capacitao das equipes de projetos.
Pilar dos Processos
A abordagem dos processos refere-se a procedimentos ou maneiras especificadas

de se abordar rigidamente situaes definidas. Neste contexto, este pilar visa o
desenvolvimento das funes que integram os requisitos de gerenciamento de
projetos na empresa para as tres camadas propostas. Normalmente este pilar
caracteriza a metodologia de gerenciamento de projetos a ser empreendida na
empresa. Este pilar, na verdade, dar suporte ao conjunto de estratgias definidas
pela organizao com relao a como gerenciar por projetos. O desenvolvimento
dos processos pode levar em conta os processos sugeridos e detalhados no guia de
gerenciamento de projetos proposto pelo PMI Project Management Institute
(PMBOK,2000) para as organizaes, como tambm, os processos referentes a
formao de equipes e desenvolvimento de profissionais.
Pilar Efetivao das Mudanas
O terceiro pilar se refere efetivao da mudana, decorrente das estratgias

configuradas e do desenho dos processos. Este pilar representa os elementos
necessrios para se configurar o entendimento do gerenciamento da mudana
organizacional e de suas barreiras ocasionadas durante implantao da gesto por
projetos. Este pilar, para efeitos de anlise, dever contemplar os indicadores de
desempenho dos projetos e seus respectivos gerenciamentos, considerando-se a
possibilidade de analisar as competncias das trs camadas sugeridas.
As camadas propostas no modelo podem ser enquadradas segundo resultados

estratgicos conseguidos e pelo desenvolvimento de suas competncias em termos
de processos. Desta forma, v-se a maturidade, do indivduo, equipes e
organizao, expressa nos quadrantes, atravs das mudanas efetivas. Assim, foi
possvel planificar o modelo, constituindo a matriz de maturidade, composta de
quatro cenrios distintos conforme se observa na Figura 43.
Figura 43 Matriz de Maturidade (Rabechini Jr, 2003)
V.2.2 Aplicao do modelo
Esse modelo pode ser aplicado nas organizaes para melhorar a maturidade em
gerenciamento de projetos. O primeiro passo identificar os dados gerais da
empresa, a sua misso e estratgia. A seguir, identificadar a estrutura
organizacional e de que forma os recursos humanos so treinados e capacitados. A
seguir, realizar o diagnstico sobre maturidade gerenciamento de projetos, utilizando
o modelo proposto Kerzner. O passo seguinte realizar a avaliao segundo o
modelo OPM3 que considera os seguintes pontos (1) apoio organizacional para
projetos, (2) alinhamento dos projetos com as estratgias de negcio; (3)
aprendizado organizacional; (4) metodologias e processos de gesto de projetos e
(5) fatores de recursos humanos.
Identificar os fatores crticos de sucesso, e mapear na Matriz de maturidade a

situao da empresa. O resultado dessas avaliaes deve apontar lacunas em
gerenciamento de projetos na organizao que precisam ser preenchidas. A anlise
deve ser feita usando o modelo proposto, observando as camadas da organizao e
com isso pode se elaborar um plano de ao para preencher essas lacunas.
Por fim, este autor solicitou recursos Fapesp para que o aluno pudesse publicar
sua tese, o que ocorreu em 2005 (RABECHINI, 2005a).
V.3 GESTO DO CONHECIMENTO EM PROJETOS
Na pesquisa realizada com Tavares (2003), foram estudadas

as questes de gerenciamento de projetos que contm
inovaes tecnolgicas. Este tipo de projeto possui a
particularidade de necessitar gerenciar, alm das atividades
tradicionais de qualquer projeto, o conhecimento da inovao,
uma vez que ela pode ser uma lacuna na organizao que est
implantando esse projeto.
O Quadro 8 apresenta uma viso geral da pesquisa, com as hipteses assumidas e

as questes a serem respondidas. O ponto de partida foi a seguinte proposio: um
projeto de TI sob encomenda com componentes de inovao, em um ambiente
tecnolgico complexo, demanda novos conhecimentos para a equipe do projeto em
tempo de projeto. Existe um gap conhecimento em projetos inovativos.
So duas questes formuladas:
como suprir este gap de conhecimento para a consecuo projeto de TI?
Como garantir a transferncia do conhecimento das empresas

fornecedoras para a empresa cliente durante o projeto?
Foi elaborado um modelo conceitual para a realizao da transferncia de

conhecimento em tempo de projeto, e aps um estudo de mltiplos casos onde
foram estudadas 2 empresas fornecedoras de tecnologia e 3 empresas que
adquirirem a tecnologia e atuam na rea financeira, esse modelo foi refinado,
conforme apresentado no Quadro 9. O modelo opera da forma descrita a seguir.
A empresa cliente necessita implementar projetos de tecnologia da informao que

contenham algum tipo de inovao. Para no fugir do foco de seu negcio (core
business), essa empresa dever fazer a subcontratao de fornecedores de
tecnologia. O que o modelo traz de novidade so os processos referentes gesto
do conhecimento. Isto significa criar um ambiente propcio para essa transferncia,
ou seja, a criao de processo de captura, organizao e uso deste novo
conhecimento. Dever tambm buscar o uso de ferramentas de tecnologia da

informao para armazenamento e distribuio do novo conhecimento.
Quadro 8 Agrupamento das hipteses e questes da pesquisa (Tavares, 2003)

Quadro 9 Modelo de Transferncia de Conhecimento para Projetos de TI (Tavares, 2003)
A empresa fornecedora deve deter o conhecimento a ser transferido, deve ser uma
empresa que j possua produtos e servios que contenham inovao tecnolgica, e
deve ter, na equipe do projeto, profissionais que tenham o conhecimento tcnico
necessrio a ser transferido.
A transferncia do conhecimento dever ser realizada atravs de um processo

definido:
mapeamento do gap de conhecimento,
documentao do novo conhecimento,
treinamento prvio da equipe envolvida,
estabelecimento do processo de mentoring.

No modelo PMBoK (2000), a rea da gesto de projetos que trata desta busca de
solues a Aquisio. Nessa rea, a opo pela subcontratao justifica-se pela
necessidade da empresa focar nas suas competncias essenciais. Esta
subcontratao atender ao desenvolvimento de aplicaes de tecnologia da
informao em projetos complexos, com o alto grau de integrao, feitos sob
encomenda. Quando as empresas buscam os novos conhecimentos atravs dos
fornecedores, deve preocupar-se em atentar para a adequada transferncia desses
conhecimentos.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-105
VI IMPLEMENTAO DE SISTEMAS DE TI
Implementao os temas relacionados implementao so voltados

principalmente aos processos de desenvolvimento de
software. Nessa rea foram desenvolvidas 9 pesquisas:
Inspeo de recebimento em uma FS

Processo de desenvolvimento de Software
Processo para um FS
Organizao dos processos de uma FS
Gesto do Conhecimento em FS
DDS-Desenvolvimento Disitribuido de Software
Reuso sistematizado de Software
Produtividade em FS
QuickLocus: avaliao de processo
Conforme j relatado anteriormente, o tema Fbrica de Software j havia sido

estudado no trabalho de formatura de Frontini (1988). Houve tambm, no mbito do
Departamento de Engenharia de Produo, a tese de doutorado de Fernandes
(2000) versando sobre este mesmo tema, que depois foi transformada em livro
(FERNANDES, TEIXEIRA, 2004). Nesse trabalho, a proposta foi considerar um
ambiente de programao com uma viso de gesto de projetos, embora tivesse
uma estrutura de processos bem definida.
Outro trabalho sobre Fbrica de Software foi desenvolvido por Jensen (2001)
Na elaborao do modelo de referncia, j apresentado, da fbrica de software

eLab-TI, foi discutido exaustivamente o tema produo de software com uma viso
de manufatura. Esta abordagem ficar mais clara nos trabalhos de pesquisa que so
apresentados neste captulo.
VI.1 INSPEO DE RECEBIMENTO EM UMA FS
Costa (2003) desenvolveu uma pesquisa com dois pontos a

serem destacados: levantamento junto a Fbricas de Software
do mercado e a proposta de um processo de inspeo de
recebimento na Fbrica de Software.
VI.1.1 Levantamento junto a Fbricas de Software
Foi realizada uma pesquisa junto s Fbricas de Software existentes no mercado

atravs de visitas e entrevistas com essas empresas. Esta pesquisa foi realizada de
fevereiro a julho de 2002. Existem no Brasil 60 empresas que declararam possuir
Fbricas de Software (MCT, 2001 apud Costa, 2003). Dessas, 29 foram
desconsiderados pelo fato de serem empresas menos conhecidas ou por terem
porte muito pequeno. Por essa razo a pesquisa se concentrou nas 31 maiores
empresas existentes na poca. Foi elaborado um questionrio qualitativo cujo
resultado est tabulado no Quadro 10.
Esse questionrio foi organizado em 3 blocos: (1) recebimento e entrega, (2)

produo (programao) e (3) gerenciamento e equipe, com o seguinte contedo:
No primeiro bloco o levantamento identifica o esquema de recebimento do

servio, como fornecido prazo e preo (se usada mtrica tipo pontos
de funo), como analisado o contedo do servio e se pode ocorrer
devoluo na entrada;
No segundo bloco verificado se existe uma estrutura para cada fase do

ciclo de desenvolvimento, qual o profissional que recebe o servio
(gerente, lder, programador), se existe o conceito de ordem de pedidos ou
so clulas dedicadas, se existe planejamento para alocao de recursos,
se h especializao por tecnologia, quais as tcnicas de verificao
utilizadas e se h um processo definido de testes.
No terceiro bloco verificado se existe registro de histrico de

produtividade e qualidade, se existe algum tipo de certificao, que
ferramentas de produtividades so usadas, se usada tecnologia
orientada a objeto e se processos como RUP e representaes como UML

so utilizados.
Quadro 10 Resultado da pesquisa em 31 Fbricas de Software (Costa, 2003)
Vale observar os seguintes pontos:
42% dizem aplicar o ciclo completo de desenvolvimento em seu processo
45% aplicam metodologias proprietrias baseadas na anlise estruturada

e engenharia da informao, o que denota uma certa defasagem
tecnolgica
Apenas 0,7% afirma trabalhar na fase de construo (que seria o conceito

de fbrica de software)
16% funcionam como clula do cliente.
26% realmente trabalha num conceito de fbrica de software.
Foi observado que, apesar de todas afirmarem possuir uma Fbrica de Software,
poucas aplicam esse conceito de forma efetiva.
O que foi observado foram estruturas organizadas em clulas especficas de

desenvolvimento de software de que se especializam para atender um determinado
cliente. Este modelo no foi considerado, para efeito desse estudo, como fbrica
de software e sim um ambiente tradicional de desenvolvimento com clulas

dedicadas.
VI.1.2 Processo de Inspeo de Recebimento
A proposta realizada para a Fbrica de Software, apresentada na Figura 44, apesar

de se basear em formatos j existentes, tem como diferena fundamental, o fato de
receber qualquer tipo de servio de construo de software, independente do cliente
e do servio solicitado, local ou remotamente, dentro de um padro de especificao
que traz a independncia do tipo de cliente, da plataforma de programao e do tipo
de cdigo a ser gerado (Costa, 2003).
Figura 44 Processo de programao em uma Fbrica de Software (Costa, 2003)
Outro fator importante nesta proposta est embutido no segundo processo

desenvolvimento do projeto. Nesse processo h uma diferena fundamental com
relao s demais fbricas, pois essa atividade no se resume apenas
programao. As atividades desse processo levam em considerao no apenas os
requisitos de software constantes no pedido de servio, mas aplicam tcnicas de
padres e componentes, visando aplicar intensivamente o reuso, atravs de buscas
nas bibliotecas da fbrica. Antes da codificao, o processo exige um trabalho de
montagem de peas existentes na prateleira. Somente sero codificados os cdigos
inexistentes e especficos do servio solicitado. Todo este processo somente
possvel utilizando-se ferramentas que automatizem o processo tais como gerncia
de requisitos, gerncia de configurao e controle de projetos e testes integrados
(Costa, 2003).
As atividades de levantamento de requisitos, modelagem do software no nvel de

negcio e as alternativas de soluo apresentadas ao cliente no fazem parte deste
processo. Caso a fbrica de software receba pedidos em um formato diferente do
padro, necessrio que exista uma rea que faa recepo do pedido no formato
do cliente e passe para o padro da fbrica. A Figura 45 representa em destaque a
proposta da interface entre o cliente e a Fbrica que realiza inspeo e a
equalizao para garantir homogeneidade do nvel de especificao (Costa, 2003).
Figura 45 Interface entre o cliente e a Fbrica de Software (Costa, 2003)
O processo proposto para a Fbrica de Software est a representado na Figura 46.

Esta figura detalha como o processo pode ser implementado. Na parte interna esto
os processos similares queles apresentados na Figura 44, e externamente foram
colocados os processos de gerenciamento: gerenciamento de projetos,
gerenciamento da qualidade, gerenciamento da configurao, e gerenciamento de
riscos (Costa, 2003).
Figura 46 Processos propostos para uma Fbrica de Software (Costa, 2003)

O primeiro processo (Figura 46), de recebimento da solicitao do servio, verifica a

adequao s normas e padres da Fbrica.
Um dos itens a ser verificado tambm a questo do prazo para entrega. A Fbrica,
possuindo dados histricos e utilizando mtodos adequados de estimativas, como
por exemplo, Pontos de Funo ajustados atravs da Curva ABC (Costa, 2003 a),
pode estimar com margem pequena de erro, qual o tempo necessrio para a entrega
da solicitao.
Caso a documentao no esteja adequada, um trabalho de equalizao

realizado. No segundo processo, de construo, conforme j descrito, so
codificados apenas os componentes que no existem e agregados os componentes
existentes anteriormente na biblioteca. Ao final desse processo existem unidades
desenvolvidas e testadas. O terceiro processo, avaliao e testes do software,
uma atividade que realiza a integrao do produto e realiza os testes de integrao.
O quarto e ltimo processo (acrescentado) a liberao para o cliente cujo resultado
o software homologado (Costa, 2003).
Esse processo foi implementado em uma empresa que atua no mercado de

sistemas de superviso de trfego areo. Esse tipo de software crtico e o
processo de desenvolvimento exige diversas etapas de verificao e validao
Figura 47 Modelo implementado da Fbrica de Software (Costa, 2003)
. A empresa possui vrias unidades de negcio com ncleos separados de

desenvolvimento de software e decidiu implementar um NS-Ncleo de Software. As
diferentes unidades de negcio fazem as solicitaes de servio e demandam

servios para a Fbrica de Software, conforme ilustrado na Figura 47 (Costa, 2003).
Na estrutura da Fbrica foram concebidos quatro processos:
Recepo e Entrega responsvel pelo recebimento das demandas das

unidades de negcio UN- e verificao se o material atende aos padres,
se o prazo e custo esto adequados. Esta rea possui engenheiros de
software que fazem a interface com os clientes. Quando o produto fica
pronto, realiza a atividade de entrega.
Projeto responsvel pela arquitetura de implementao do software,

reuso, padres de arquitetura (design patterns), montagem de
componentes e frameworks.
Construo responsvel pela construo de todos os cdigos

demandados pelas UNs. O trabalho executado em bancadas de trabalho
especializadas, ou seja, ambientes de desenvolvimento organizados por
tecnologia. Os programadores podero trabalhar em diversas bancadas
diferentes, dependendo do perfil e do conhecimento das tecnologias
utilizadas. Em casos especiais uma equipe poder ser deslocada para
formar uma clula especfica para atender a um projeto.
Testes responsvel pelos testes de integrao e aceite do software junto

aos clientes e pela homologao dos produtos.
Como pode ser observado, o modelo implementado muito similar ao modelo

conceitual.
VI.2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Lousada (2000) realizou uma pesquisa em empresas que

possuem equipe prpria de desenvolvimento. Foram
entrevistadas 15 empresas. A primeira parte da pesquisa foi
realizada em 1997 e a segunda em 1999. As mesmas
empresas foram entrevistadas. Considerando os
quadrantes de McFarlan (1984), foi identificado que 4 esto
no quadrante estratgico (3 bancos e 1 consultoria), 3 esto no quadrante fbrica e
8 esto no quadrante suporte. Foram feitas perguntas sobre o uso de mtodos de
anlise, formao do pessoal, se existe planejamento na informtica, sobre a
qualidade da documentao e as atividades de testes. Os resultados demonstraram
que o uso de mtodos de anlise muito baixo, que somente em 13% das
empresas h um plano de treinamento. Com relao a planejamento formal da rea
de informtica foi relatado que 20% no tem planejamento e 20% est em fase de
implantao. De 1997 para 1999 houve uma reduo de envolvimento com os
usurios de 80% para 60%. Apenas 27% das empresas citaram o uso de
ferramentas CASE nas duas fases.
VI.3 PROCESSO DE DESENVOLVIMENTO PARA UMA FBRICA DE

SOFTWARE
Rodrigues Silva (2005) desenvolveu uma pesquisa com dois

pontos a serem destacados: levantamento do processo de
desenvolvimento junto a Fbricas de Software e a proposta
de um processo de desenvolvimento para Fbrica de
Software.
VI.3.1 Levantamento do processo de desenvolvimento de Fbricas de Software
Foi realizada uma pesquisa junto a 5 Fbricas de Software de grande porte, atravs
de visitas e entrevistas (RODRIGUES SILVA, 2005). Quatro dessas empresas
utilizam o conceito de fbrica de Software, sendo que duas possuem processo bem
estruturado, duas possuem o processo beirando a desorganizao, e uma que no
utiliza o conceito de Fbrica de Software, pois est organizada para confeco de
software sob encomenda. Foi elaborado um questionrio qualitativo que foi
preenchido pelo prprio pesquisador durante contato com os profissionais
entrevistados. O questionrio possui um total de 64 perguntas e foi organizado em 8
blocos:
(1a) Equipe de desenvolvimento desenvolvedores

(1b) Equipe de desenvolvimento gerenciamento da equipe
(2) Recebimento do Servio e gerenciamento do backlog
(3) Desenvolvimento recebimento do servio
(4) Desenvolvimento entrada na produo
(5) Desenvolvimento implementao (codificao)
(6) Desenvolvimento testes
(7) Encerramento
(8) Desenvolvimento questes gerais
O questionrio completo com as respostas tabuladas est no Apncie A. A seguir

est um resumo dos resultados obtidos (RODRIGUES SILVA, 2005):
(1a) Equipe de desenvolvimento desenvolvedores
Nestas perguntas, o objetivo verificar se as equipes de desenvolvimento trabalham

de maneira fixa, especializados em ambientes ou linguagens, ou se ajustam
caractersticas dos clientes.
Foi observado que as organizaes trabalham com equipes multidisciplinares e os

desenvolvedores possuem mais de uma habilidade (linguagem de programao)
adequando-se s demandas dos clientes. Este procedimento dificulta e encarece a
aquisio de novos elementos para o quadro de desenvolvedores. Na maioria das
organizaes, os servios do cliente so aceitos alocadas diretamente para a equipe
sem realizar nenhum tipo de anlise. Se houvesse um padro de recebimento de
servio, facilitaria a aceitao, o controle e o prprio desenvolvimento.
Foi observado tambm que nenhuma organizao trabalha em pares (pair

programming), salvo em casos especiais. Conforme a pesquisa, esta maneira de
trabalhar proporciona qualidade, produtividade e maior satisfao no trabalho.
(1b) Equipe de desenvolvimento gerenciamento da equipe
O objetivo mostrar como as equipes so gerenciadas, quem efetua a alocao de

recursos e quem realiza o report para controle.
As equipes so gerenciadas por um gerente de produo, que tem sob sua

responsabilidade lderes de produo. Estes lderes so os encarregados de receber
o servio, efetuar o cadastramento, alocar os recursos disponveis e, aps o
encerramento, realizar baixa no sistema de controle. As equipes de produo
efetuam o apontamento de horas trabalhadas, que so utilizados para cobrana e
registro histrico.
(2) Recebimento do Servio e gerenciamento do backlog
A proposta identificar como o pedido do cliente trabalhado dentro da produo

em termos de recebimento, gerenciamento e controle. Tambm verificar como
realizado o controle de produo: as filas de espera e a transio da fila de espera
para a realizao do servio. Um outro ponto importante a ser analisado a maneira
com que so tratadas as interrupes das atividades em andamento para fazer o
atendimento de servios novos com maior prioridade.
O que foi observado que a maioria das organizaes possui uma metodologia de
recebimento, embora no exija um padro de preenchimento de formulrios pois
sempre procura atender todos os servios dos clientes, independente de ambiente
ou linguagem. Para que o servio entre na produo tambm existe, definido no
processo, uma seqncia a ser seguida, mostrando a existncia de um padro de
recebimento. A grande maioria das organizaes efetua o planejamento dos

servios aceitos.
Normalmente os lderes reportam sobre o andamento das atividades. Muitas vezes

os prazos so superados e, nesses casos, so criados tratamentos de emergncia
na tentativa de correo ou renegociao com o cliente para um novo prazo.
Quando ocorrem esses fatos, so efetuados registros dos motivos para futura
melhoria de processo.
A maioria das organizaes no adota um critrio de composio de fila de espera

nem um esquema de transio da fila de espera para a produo. Todos os servios
so passados diretamente para a produo e so executados conforme
disponibilidade, no existindo para os desenvolvedores metas a serem cumpridas.
Quando entra na produo um servio com maior prioridade, normalmente

interrompe-se o servio corrente, realiza-se um novo planejamento de emergncia
que possibilite a execuo dos dois servios. O risco de no cumprimento dos
prazos dos servios muito grande.
(3) Desenvolvimento recebimento do servio
Recebimento do servio (desmembramento em tarefas) o objetivo analisar como a

produo propriamente dita recebe o servio do cliente e efetua a atualizao do
controle. O servio do cliente recebido pelo lder de produo que imediatamente
realiza o registro e entrega para o desenvolvedor que vai implement-lo.
Normalmente o desenvolvedor encarregado de desmembrar o servio em tarefas
menores, para facilitar a implementao e testes. Conforme a metodologia so
alocados recursos para os servios que so identificados por um nmero de ordem
de servio. Em algumas organizaes no h rigor quanto a padres de
implementao por ambiente de desenvolvimento ou por linguagem, pois as equipes
so multidisciplinares e os profissionais so alocados como recursos que se
adaptam ao ambiente ou linguagem conforme exigido pelo servio.
Com relao a reuso de software, o reaproveitamento de cdigo, do prprio cliente

ou existente internamente feito segundo a experincia e conhecimento do lder de
produo, no existindo um processo para tanto. Em algumas organizaes nem
mesmo este procedimento efetuado. Somente uma das organizaes possui o
recurso de framework como ferramenta de auxlio ao cliente.
(4) Desenvolvimento entrada na produo
Este conjunto de questes visa identificar como feita a transio do servio

(tarefas) da fila de espera para a implementao propriamente dita.
As organizaes, como trabalham com equipes multidisciplinares, entregam o

servio para os desenvolvedores conforme disponibilidade. O desenvolvedor,
juntamente com o lder de produo, efetua um planejamento que normalmente
seguido. As organizaes possuem um processo de trabalho definido que seguido
pela equipe. As organizaes que trabalham com CMM realizam o preenchimento
dos formulrios adequados de acompanhamento do processo. Nenhuma das
organizaes trabalha com a Norma ISO 9000 ou com o PSP (processo de software
pessoal) e os processos para a obteno de divulgao de medies referentes a
produtividade praticamente no existem
(5) Desenvolvimento implementao (codificao)
Para este tpico, o objetivo entender como o processo de passagem da fila de

espera para a fila de implementao e se h algum processo para reuso de cdigo.
Foi observado que todas as equipes de desenvolvimento, exceto uma, implementam

o cdigo da forma que o cliente definiu, no realizando nenhuma quebra em tarefas
menores. Esta opo fica a cargo do desenvolvedor e no faz parte do processo.
Com relao atividade de reviso de cdigo, apenas uma organizao possui esse
processo (a mesma anterior).
(6) Desenvolvimento testes
Estas perguntas tm o objetivo de verificar como as organizaes organizam os

processos de teste: quando so planejados, como so realizados.
Quando o desenvolvedor implementa o produto (que pode ser um programa, uma

classe ou um componente), ele prprio realiza os testes unitrios. Aps a confeco
dos produtos que compem um servio do cliente, individualmente so feitos os
testes de integrao. Este estudo visa verificar com as organizaes se comportam
antes dos testes de unidade e de integrao.
Foi observado que praticamente todas as organizaes trabalham com uma

metodologia de testes alinhada com a metodologia de desenvolvimento. Quando
feito o planejamento do projeto, este inclui as atividades de testes. As estratgias de

testes so cumpridas pelas equipes de desenvolvimento. Estas estratgias, visam
normalmente uma massa grande de testes com testes longos. As massas de testes
so criadas no instante do teste, ou seja, aps a implementao do produto.
Geralmente so os prprios desenvolvedores que realizam os testes de unidade.
Como maioria das organizaes trabalha focada no servio do cliente, os testes de
integrao, quando necessrias, so criados no instante da sua execuo e
realizados pelo prprio desenvolvedor.
Os entrevistados questionados no acham que o processo de teste seja eficaz,

apesar de serem demorados. Alguns conheciam e outros ficaram conhecendo a
proposta do XP (extremeprogramming) de criao de testes antes da
implementao e deixaram claro que gostariam que experincias fossem feitas para
identificar novos esquemas que sejam mais eficazes e menos demorados. Uma das
organizaes aplica a prtica de testes da XP parcialmente, a contento, e est
procurando incrementa-la gradativamente.
(7) Encerramento
Nesta etapa o objetivo verificar se no encerramento so tomados alguns cuidados

referentes a controle, qualidade e registro de dados histricos.
Normalmente, aps o encerramento do servio, os desenvolvedores participam da

homologao junto ao cliente e, depois do aceite, os mesmos efetuam a atualizao
do planejamento, baixa no controle e a liberao dos recursos alocados. Para a
maioria das organizaes, neste instante que so efetuados os registros da
qualidade e produtividade.
Os registros para melhoria de processo, exceto em uma organizao, no

normalmente efetuado, ficando para o desenvolvedor apresent-las em reunio.
Tambm no h um esquema de atendimento a estas melhorias, podendo ser
efetuada a qualquer tempo. Geralmente, segundo os entrevistados, a maioria cai no
esquecimento e at pode acontecer novamente. Raramente e somente em algumas
situaes os problemas encontrados e as solues apresentadas so divulgadas
oficialmente entre as diferentes equipes de desenvolvimento. Assim, como no h
divulgao de atividades de melhoria, fica somente para os desenvolvedores
divulgarem entre si, se acharem necessrio.
(8) Desenvolvimento questes gerais
Anlise de algumas questes que no foram abordadas nos tpicos anteriores por
ser tratarem de uso geral tais como mtricas, medio da produtividade, nvel de
retorno de servio, verificao da eficcia das melhorias de processo.
Duas organizaes relataram que o nvel de retorno do cliente relativamente alto, o

que causa insatisfao do cliente.
A maioria das organizaes se preocupa em saber qual o grau de satisfao do

Cliente atravs de um processo de verificao. Em uma das organizaes, at agora
a mais organizada, houve conflito em trs informaes, mas percebe-se que, apesar
de informarem que um nvel de retorno de servios baixo, no possui nenhum
processo de verificao da satisfao do cliente.
Somente uma das organizaes foi clara nas respostas: que efetua uma anlise e
verificao das melhorias aplicadas nos processos produtivos. As demais mostraram
que no possuem nenhum processo de anlise e verificao.
VI.3.2 Proposta de modelo de desenvolvimento para Fbrica de Software.
Nesta seo apresentado o modelo de processo proposto por Rodrigues Silva

(2001, 2005). Este modelo foi construdo a partir do levantamento conceitual sobre
Fbrica de Software e a pesquisa de campo realizada.
VI.3.2.1 Conceitos gerais sobre uma fbrica de software.
Uma fbrica de software caracteriza-se por ter um modelo semelhante a um

processo industrial, baseado na utilizao de um processo de desenvolvimento,
visando a padronizao das atividades fabris, qualidade e produtividade, construindo
produtos e software de maneira artesanal. Conforme Fernandes, Teixeira (2004)
uma fbrica de software deve utilizar entre outros, os seguintes conceitos bsicos
para a produo de software sob encomenda:
Processo padro e definido para a implementao do produto de software;
Uma entrada padronizada do servio do cliente;
Mtodos e padres de estimativas baseados em histricos;

O perfil dos desenvolvedores deve ser controlado e estar alinhado com as

demandas;
A produo deve possuir processos distintos para atendimento de

demandas de natureza diferente;
Possuir melhoria contnua de seus processos.
Outra caracterstica importante da fbrica de software o reuso sistematizado.
VI.3.2.2 Conceitos utilizados no modelo proposto.
Servio do cliente e tarefas
a solicitao demandada pelo cliente que dever ser, pela gerncia de produo,
desmembrada em possveis tarefas para a produo. Deve estar dentro de um
padro de aceitao, com definio clara e objetiva da proposta para o produto final.
O artefato final de cada tarefa ser o cdigo implementado. O cliente receber
juntamente com a solicitao do servio, a composio dos cdigos das tarefas.
Bancada de produo
a parte produtiva que recebe o servio do cliente e o implementa atravs das

linguagens de programao, criando o artefato final: o cdigo.
A bancada de produo composta por equipes para cada ambiente de

desenvolvimento. Os profissionais devem ser habilitados para extrair o melhor de
cada ambiente de produo ou linguagem de programao. No premissa deste
modelo ter um quadro de desenvolvedores multifuncionais (que desenvolvem em
vrios ambientes).
Bancada de produo ambiental
A bancada de produo ambiental o desmembramento da bancada de produo

em bancadas que implementam o servio do cliente em diferentes tipos de
ambientes e de linguagens. Isto requer lderes de produo diferentes para poderem
estar junto ao desenvolvimento nas tarefas de planejamento, acompanhamento e
dando o apoio necessrio. As bancadas ambientais devem ter claramente
especificadas as principais definies para a construo do ambiente, como por
exemplo:
perfis funcionais e atividades que sero desempenhadas;
processo de desenvolvimento de software e os artefatos de entrada, sada

e as medies de avaliao;
material necessrio para a instrumentao;
sequenciamento de pedidos.
Um fator importante para um ambiente de produo a seqncia em que o mesmo

ir atender suas demandas. Trata-se da programao de atividades e a sua
priorizao.
BACKLOG
o nome dado s pendncias de atividades a serem realizadas. a fila de servios

pendentes. Vide Figura 48.
SCRUM
Trata-se de um mtodo gil de desenvolvimento de software (Beedle apud

Rodrigues Silva, 2005). Esse modelo utilizado na ndia. O SCRUM divide um
projeto (ou todas as tarefas do BackLog da organizao) em repeties
denominadas SPRINT com duraes de, normalmente, 30 dias (no modelo proposto
uma semana). Mensalmente define-se a prioridade do BackLog em funo das
demandas e negociaes com clientes, disponibilidade dos recursos (ambientes e
pessoas). Definem-se as entregas durante o perodo. Diariamente so feitas
reunies com as equipes (tipicamente 15 minutos) para posicionamento e reporte
sobre as atividades. Essas reunies so um importante meio de comunicao entre
os membros da equipe. Vide Figura 48.
SPRINT
SPRINT o nome dado a uma programao de atividades de um perodo de

funcionamento da Fbrica. Trata-se da coleo de pedidos pendentes que no deve
ser alterado durante o perodo de programao. O SPRINT o horizonte de
programao de produo. O SPRINT detalhado nas tarefas menores SCRUM-
que so as atividades atomizadas para as pessoas. Vide Figura 48.
Figura 48 Viso Geral do SCRUM (Rodrigues Silva, 2005)
VI.3.2.3 Modelo proposto.
Equipe de desenvolvimento.
A equipe de desenvolvimento dever estar envolvida seguindo o processo de

desenvolvimento definido para a Fbrica. A tecnologia XP dever favorecer,
juntamente com a utilizao do modelo PSP, a montagem de equipes mais
homogneas possibilitando que se organize para um servio do cliente, uma equipe
compatvel com a complexidade apresentada. Seus objetivos so o aproveitamento
dos ndices de produtividade, qualidade e eficincia para a montagem das equipes,
bem como a estrutura de treinamento do pessoal desenvolvedor. A tecnologia XP
possibilita, alm do uso das prticas de implementao, o uso da prtica de
programao em pares, que contempla uma forma de trabalho mais qualitativa e
alinhada com a satisfao e confiana do desenvolvedor.
Gerenciamento do BackLog
O gerenciamento das equipes ser realizada seguindo a tecnologia SCRUM, da

seguinte forma:
Cada novo servio ser incorporado pelo gerente de produo ao Backlog

da bancada ambiental;
Os SPRINTS sero criados em reunies semanais, ao invs de trinta dias

como definido na metodologia SCRUM;
Cada SPRINT resulta na meta da bancada ambiental em um planejamento

para o horizonte que de uma semana;
Diariamente, o lder da equipe faz uma reunio de, no mximo 15 minutos,

com sua bancada ambiental, posicionando o planejamento;
A cada produto terminado ser acionada a integrao instantnea, quando

for o caso;
Sempre que os testes forem terminados deve ser efetuado um aviso ao

lder;
A cada produto terminado, ser efetuada a aplicao atualizao do

planejamento, e como conseqncia, a atualizao das metas da equipe e
do BackLog (Sprint).
Processo de desenvolvimento.
Este processo dever estar definido adequadamente, em um nvel de detalhe

suficiente para homogeneizar as tarefas.Isto dever garantir itens com padres de
programao, como por exemplo critrios para nomear variveis, alm do controle
das tarefas. O processo proposto possui 5 processos que esto divididos em sub-
processos menores detalhando as atividades para melhor compreenso
(1) Processo de recebimento do servio esta atividade dever ser

realizada como um ato formal, seguindo o processo descrito em (Costa
2003).
Disponibilizao do servio para a produo a gerncia de produo

recebe o servio e realiza atividade de desmembramento em tarefas a
serem implementadas nas bancadas de produo.
(2) Processo de entrada das tarefas nas bancadas ambientais de

produo os lderes recebem as tarefas definidas pelos clientes que
so complementadas com os padres da fbrica. Atualiza o recebimento
das tarefas no controle, realiza reunies SCRUM para a criao das metas
da semana, prepara planejamento, plano da qualidade, verifica a
possibilidade de reuso e disponibiliza para os desenvolvedores.
Reunies do SCRUM para a criao do SPRINT os lderes das

bancadas ambientais, juntamente com as suas equipes de
desenvolvimento, separam do BackLog do SPRINT, qual ser a meta
estabelecida para a semana. Nestas reunies devem ser consideradas

as datas de entrega para os clientes.
Pequenas verses a definio do cliente revista, no nvel XP e

verificada a possibilidade de desmembramento tarefas grandes em
pequenas tarefas. Este processo efetuado pelos desenvolvedores da
bancada ambiental, e comunicado ao cliente. A situao atualizada
no controle, cada um gastando seu tempo nas tarefas menores e
liberando a tarefa grande.
Planejamento do desenvolvimento da tarefa de posse do SPRINT

para a bancada, ou seja a meta para a prxima semana, efetua se o
planejamento de cada tarefa. Neste processo objetivo do lder de
produo da bancada ambiental, juntamente com a equipe,
estabelecer o plano detalhado, fazendo com que todos fiquem
comprometidos com as tarefas. Isto deve ser feito considerando os
nveis de produtividade, se possvel, no nvel individual.
Plano da qualidade o plano da qualidade deve ser a base para o

acompanhamento da tarefa atravs de padres mnimos exigidos na
produo.
Verificao do Framework quando cada tarefa do servio do cliente

concluda, ela translada da biblioteca de produtos em
desenvolvimento, para a biblioteca de produtos desenvolvidos. Se
estas tarefas forem componentes, ser tambm registrado no
Framework, para efeito de montagem da estrutura de verificao da
reusabilidade. Quando um novo servio do cliente, nos mesmos
moldes de composio entra para a produo, o objetivo deste
processo verificar atravs de navegadores prprios ou de pastas
descritivas dos padres existentes, se j existe alguma classe, mtodo,
componente, pattern com padres que satisfaam as necessidades da
nova tarefa a ser desenvolvida. Esses padres podem ser gerais (da
prpria produo) ou do cliente (em ambiente restrito).
Distribuio das tarefas para a bancada de produo ambiental as

tarefas, com seu planejamento e relatrio de especificao tcnica, so
entregues aos desenvolvedores.
(3) Processo de produo a tarefa, definida pelo cliente, e pertencente

meta do SPRINT, atualizada no controle e disponibilizada no BackLog
da bancada ambiental, aguardando sua vez na fila de espera, para a
implementao.
Elaborao dos testes seguindo a recomendao do XP, o plano de

testes e os casos de testes devem ser elaborados antes da
programao.
Desenvolvimento das tarefas (implementao ) este desenvolvimento

pode ser para prottipo ou funes do projeto. a produo em si, a
codificao. Para a implementao propriamente dita, deve-se levar
em conta o cdigo recuperado do framework. Atualizar os formulrios
de apontamento das tarefas.
Criao do ambiente e de testes para verificao da exatido dos

cdigos em relao aos requisitos do cliente, necessrio realizar
testes de unidade e de integrao .
Realizao dos testes os testes devem ser realizados seguindo o

plano preparado anteriormente, no ambiente adequado e os resultados
devem ser registrados .
Liberao da tarefa para a homologao com o cliente Uma vez

estando a tarefa codificada e testada deve ser devolvida para a
gerncia de produo. A gerncia de produo, verifica se todas as
tarefas foram concludas com sucesso juntamente com o cliente.
(4) Processos de encerramento aps a entrega ao cliente, so

necessrios alguns processos para encerramento, como por exemplo a
disponibilizao dos recursos tcnicos e tecnolgicos para novos servios.
Liberaes a tarefa que realiza o translado do material de uma

ordem de servio mantido na biblioteca de produto em
desenvolvimento para a biblioteca de produtos desenvolvidos. Liberar
os recursos alocados em equipamentos, ambientes operacionais e

humanos. O lder de produo da bancada ambiental deve
acompanhar e verificar se as configuraes esto sendo mantidas
corretamente.
Melhoria dos processos com o encerramento do servio do cliente,

deve-se efetuar uma reunio entre a gerncia de produo e o lder de
produo e analisar as sugestes de melhoria e verificar se estas
podem ser implementadas imediatamente ou em outra oportunidade.
Estas melhorias devem ser acompanhadas pelo lder de produo da
bancada ambiental onde o processo foi modificado, para verificao,
medio, anlise e acompanhamento da eficcia dessas alteraes. A
gerncia de produo e as equipes de desenvolvimento devem ser
comunicadas sobre a melhoria incorporada ao processo, o seu
sucesso ou fracasso e os possveis refinamentos .
Divulgao a divulgao pode ser em um nico servio do cliente,

um grupo de servios encerrados, uma tarefa ou em um perodo de
tempo. Tambm pode cobrir especificamente uma bancada ambiental
ou para toda a produo. A divulgao visa atingir um certo objetivo de
chamada de ateno, de motivao ou simplesmente informativo.
Fazer a divulgao dos ndices obtidos como por exemplo eficincia,
qualidade e produtividade, divulgar sucesso ou fracasso em
atendimento s metas do SPRINT, mostrar as novas criaes, novos
padres, patterns etc. Tambm importante divulgar as melhorias
sugeridas, quem as sugeriu e quais foram aproveitadas e como esto
sendo aplicadas. Este pode ser utilizado como bom instrumento de
motivao.
(5) Processo de verificao da satisfao do cliente periodicamente

a gerncia de produo encaminha aos principais clientes um questionrio
para verificar o grau de satisfao com relao aos servios realizados. A
tabulao e anlise destas respostas podem facilitar a montagem de
grupos de trabalho entre a gerncia de produo, os lderes das bancadas
ambientais e desenvolvedores alocados. O objetivo desses grupos de
trabalho ser verificar essas reclamaes dos clientes e as possveis

melhorias no processo, necessrias para resolver as questes apontadas.
VI.4 ORGANIZAO DOS PROCESSOS DE UMA FS
A pesquisa desenvolvida com Fabri (2007) tem como objetivo

estabelecer uma forma de replicar o processo de uma
fbrica de software de uma localidade para outra. O problema
colocado ocorre em empresas que possuem mais de um stio
de desenvolvimento, ou quando se deseja criar uma nova
unidade de desenvolvimento de software a partir de
experincias anteriores.
VI.4.1 Consideraes sobre Fbrica de Software
Fabri (2007) identificou vrios trabalhos acadmicos sobre fbrica de software, dos
quais interessante observar o trabalho de Cusumano (1991), que foi um dos
primeiros autores a publicar sobre este tema.
Outro autor estudado foi Basili apud Fabri (2007) que realizou pesquisas sobre
produo de software com um enfoque, entretanto na organizao do processo de
produo. A proposta foi estabelecer uma Fbrica com dois processos: produo de
componentes e produo de software (baseado em componentes). Este processo foi
implementado na Universidade de Maryland, conforme modelo da Figura 49.
Figura 49 Fbrica experimental de Basili (Fabri, 2007)
Fernandes e Teixeira (2004) prope um modelo classificatrio de fbrica de software

cujo objetivo definir qual o escopo de fornecimento de produtos (Figura 50). Este
autor utiliza os termos fbrica de projetos ampliada, fbrica de projetos fsicos,
fbrica de programas, conforme os produtos que so fornecidos para os clientes.
A fbrica de programas executa a atividade de codificao (e testes).

A fbrica de projetos fsicos trata da construo do software a partir de

uma especificao definida, depois de definidas as funcionalidades.
A fbrica de projetos abrange todo o ciclo de vida, desde a anlise at a

implantao.
A fbrica de projeto ampliada abrange o conceito de arquitetura da

soluo.
Figura 50 Fbrica proposta por Fernandes e Teixeira (2004)
Nesse contexto, Fabri (2007) prope um processo para a Fbrica de Software,

conforme representado na Figura 51 . Esse modelo formado por 4 quadrantes
onde so realizadas as atividades relacionadas aos aspectos produtivos de
software.
O primeiro quadrante tem como objetivo estabelecer as negociaes para o

desenvolvimento de um novo software. Efetuadas essas negociaes realizada
modelagem do sistema pelo analista de sistemas e pelo analista de negcios
Tanto o levantamento de requisitos quanto a modelagem de sistema utiliza os

componentes de modelagem (ativos de processos, regras, templates, algoritmos,
caracterizadas como componentes de negcio, armazenados no repositrio). Ao
utilizar os componentes, os envolvidos com primeiro quadrante podem solicitar a
alterao dos mesmos (ou propor novos), conforme sentir necessidade. Essas
alteraes de componentes ou construo de novos componentes, so realizados
no quadrante 2. Por fim, aps a modelagem do sistema de informao, o engenheiro
de software e o engenheiro de produo desenvolvem o projeto do software a ser
fabricado. As atividades relacionadas com o projeto de software estabelecem um elo

entre os quadrantes um e trs.
Figura 51 Proposta de modelo para o eLab-TI (Fabri, 2007)
O segundo quadrante tem como objetivo desenvolver e manter os componentes

de modelagem. As atividades relacionadas a este quadrante so encarregadas do
desenvolvimento (padronizaes, mtodos, processos, tcnicas de gerenciamento)
e do provimento de subsdios para a estruturao da base histrica de projetos (o
documento que relata o histrico de um processo, tambm, armazenado na base
de componentes). O desenvolvimento e a manuteno dos componentes de
modelagem so estimulados pelos envolvidos com o primeiro quadrante. Uma vez
desenvolvidos e aprovados pelos responsveis pelo ambiente organizacional, os
componentes so armazenados na base e disponibilizados para serem utilizados
pelo processo de produo de software.
O terceiro quadrante foca a questo da fabricao dos programas, estes

desenvolvidos com base em especificaes advindas das atividades pertinentes ao
projeto de software, atividades estas que provm o elo entre a anlise de negcio e
a montagem do software. As atividades imersas em tal quadrante so disparadas
pelos analistas de sistemas e engenheiros de software.
O quarto quadrante tem como objetivo desenvolver componentes de cdigo que

comporo as unidades programveis, desenvolvidas no quadrante 3. Encontram-se
no quadrante 4 as atividades pertinentes ao projeto do componente, estas tm como
objetivo desenvolver as especificaes necessrias para que o componente seja
codificado. A completude das especificaes de um determinado componente
estimula a produo do mesmo, e, se aprovado pelos responsveis pelo ambiente
organizacional, este ser armazenado no repositrio.
Outro aspecto interessante que pode ser observado na Figura 51, desenvolvida a
partir da proposta de Basili (Fabri, 2007), verificar as diferentes abordagens do
processo de produo de software.
Os quadrantes 1 e 3 apresentam a questo do negcio do cliente se transformando

em uma proposta de soluo de TI.
Os quadrantes 3 e 4 apresentam a questo tecnolgica, de ferramentas, linguagens

e ambientes.
Os quadrantes 1 e 2 apresentam uma viso metodolgica relacionada com as

definies mais sistmicas para a organizao.
Finalmente, os quadrantes 2 e 4 apresentam a viso da organizao dos

componentes de software.
VI.4.2 Processo fabril
O processo de produo de software com caractersticas fabris denominado por

Fabri et. Al. (2004,2004a,2005,2007,2007a,2007b,2007c) e Pessa, (2004),
simplesmente processo fabril, define que uma fbrica de software possui duas
unidades: produo de software e produo de componentes (Figura 52). A unidade
de produo de componentes possui como ciclo de produo as seguintes
atividades:
Projetar componentes: Atividade que tem como objetivo modelar as

funcionalidades, estrutura de dados e interface de um componente. Tal componente
pode ser solicitado pela unidade de produo de software;
Construir componentes: Atividade que tem como objetivo desenvolver

componentes de cdigo e de infra-estrutura (entende-se por componente
de infra-estrutura, os ativos do processo, templates, formulrios e

algoritmos);
Integrar componentes: Atividade que tem como objetivo verificar a

qualidade funcional dos componentes. Em tal atividade so desenvolvidos
os casos de teste, so preparados os dados de teste, os componentes so
executados e, por fim, os dados resultados so comparados;
Armazenar componentes: Esta atividade prope que o administrador da

base de componentes (data base administrator component (DBCA))
gerencie o armazenamento dos componentes, provendo permisses de
acesso aos envolvidos com o modelo organizacional;
Distribuir componentes: Existem duas formas de distribuio de

componentes, o componente pode ser vendido ou entregue aos
envolvidos com o processo de produo para que unidades de software
sejam manufaturadas.
Fabri et. Al. (2004,2004a,2005,2007,2007a,2007b,2007c) salientam, explicitamente,

que a unidade de produo de componentes alicera a unidade de produo de
software. Esta ltima possui as seguintes atividades:
Anlise de sistemas: Nesta atividade os eventos sistmicos relacionados a

empresa-cliente da fbrica de software so definidos;
Projeto de software: Atividade que tem como objetivo desenvolver o

projeto do software (funcionalidades, estrutura de dados, interface), aps o
desenvolvimento do projeto, o tamanho do software definido;
Construo do software: Objetiva o desenvolvimento das unidades

programveis. Nesta atividade so utilizados os subprocessos de
manufatura;
Integrao: Atividade que tem como objetivo verificar a qualidade funcional

das unidades programveis. Em tal atividade, so desenvolvidos os casos
de teste, so preparados os dados de teste, os componentes so
executados e, por fim, os resultados obtidos so analisados;
Implantao: Atividade que objetiva implantar o software, utilizando

tcnicas de configurao e aspectos relacionados ao treinamento. Na
atividade implantar est embutido o conceito de manuteno do software;
Reviso: Atividade esta que tem como objetivo trocar o componente de

um software que est implantado, por um outro, que provenha maior
otimizao (por exemplo: relao a tempo de reposta). Por meio da Figura
52, possvel verificar ainda, as atividades de gesto. Estas devem
ocorrer em paralelo a cada atividade do processo de produo de software
e de componentes. A concepo global da gesto tambm deve ser
desenvolvida, fato este explicitado por Fabri et. Al. (2004,2004a,2005,
2007,2007a,2007b,2007c ).
Fabri (2007) ainda evolui este modelo para as atividades mais amplas como, por
exemplo, contratao de um projeto e anlise de negcio, porm este modelo no
ser detalhado aqui.
Fabri (2007) relata que o produto gerado pelo META-PROCESSO um processo de

software com caractersticas fabris, fato este explicitado, visualmente, por meio da
Figura 53. Em tal figura, salienta-se a presena do ator engenheiro de processo,
pessoa que percorre, diretamente, a estrutura proposta no META-PROCESSO,
sendo responsvel por todas as definies incorporadas ao processo de produo
de software. Ao analisar a figura em questo, possvel dizer que o META-
PROCESSO possui:
entradas, caracterizadas como requisitos de um processo de software;
processo transformador, responsvel pela criao, organizao,

instanciao e adaptao do processo de software e;
sada: processo de produo de software instanciado, que ser percorrido

quando um projeto for executado.
Figura 52 Processo fabril (Fabri, 2007)
VI.4.3 O modelo proposto de Meta-Processo para a Fbrica de Software
A Figura 54 apresenta o modelo de Meta-Processo proposto por Fabri (2007). Esse

modelo permite que seja criado um processo atravs de utilizao dessa mquina
Um meta-processo possui 6 atividades: modelagem, instanciao, simulao,
execuo, avaliao e armazenamento do processo.
Figura 53 Viso de meta-processo (Fabri, 2007)
Enfim, a Figura 54 apresenta o relacionamento das 6 atividades que compem o

META-PROCESSO. Ao analisar a figura, possvel constatar que o META-
PROCESSO representado por uma moenda, onde os requisitos so despejados,
e as atividades de modelagem, instanciao e simulao so alavancadas,
resultando em um processo executvel, modelado com as perspectivas de fluxo de
trabalho, fluxo de dados, recursos e habilidades. O processo executado sobre um
projeto, avaliado e, posteriormente, armazenado, juntamente, com a mquina de
processo, em uma base de processos.
Outro ponto a ser observado como resultado desta pesquisa foi identificar que, do
ponto de vista de organizao dos processos, as Fbricas de Software brasileiras
estudadas (em 2006 e 2007) pouco ou nada evoluram em relao s empresas
japonesas da dcada de 70.
Figura 54 Meta-processo proposto (Fabri, 2007)

VI.5 GESTO DO CONHECIMENTO EM FS
Na pesquisa desenvolvida com Trindade (2006), o foco foi a

questo da rotatividade da equipe de desenvolvimento e a
perda de qualidade das atividades realizadas na Fbrica de
Software. A pergunta desta pesquisa foi: Como fbricas de
software preservam o conhecimento?
A Figura 55 representa o binmio ensinagem, e aprendizagem. Embora

aprendizagem seja um termo bem conhecido, que significa o ato de aprender,
ensinagem menos conhecido e possui o significado simtrico: o ato de ensinar.
Nesta pesquisa o que interessa o alinhamento entre os dois atos para fazer com
que, no ambiente corporativo, cada pessoa da Fbrica de Software, ao executar
suas atividades, esteja treinada, capacitada e preparada para realiz-la da melhor
forma possvel.
Figura 55 O binmio ensinagem-aprendizagem (Trindade, 2006)
Nesta pesquisa, Trindade (2006) levantou um modelo terico a partir da literatura,

realizou um estudo de campo em quatro Fbricas de Software e props um modelo
para o processo de ensinagem, visando a preservao do conhecimento nesse
ambiente. A Figura 56 expressa o conhecimento de forma simplificada, na qual cada
degrau representa um conhecimento (e com ele uma habilidade) a ser conquistado
em processos de aprendizagem que, com acmulos e sinergias, agregam
competncias.Essa figura no representa todos os degraus em simetria , pois os
nveis de conhecimentos auferidos em cada etapa no so necessariamente iguais.
No h tambm como pensar em tal escada formando uma seqncia simples de
ensinamentos em cadeados
Figura 56 A escada do aprendizado (Trindade, 2006)
Haver, certamente, de acordo com cada ambiente, a poltica produtiva para cada
conjunto de ferramentas, tcnicas e mtodos aplicveis, um modelo diferenciado de
combinaes de conhecimentos que devem ser desenvolvidos por processos
contnuos e contguos de ensinagem. A Figura 57 exemplifica uma situao
hipottica de combinaes mostrando que um aluno pode percorrer um caminho
diferente de outro aluno em funo de sua trajetria, seu interesse e seus
conhecimentos anteriores.
Figura 57 A escada do aprendizado em perspectiva (Trindade, 2006)
A Figura 58 representa o modelo final de ensinagem. O que se admite neste modelo

que, no ambiente da fbrica, existe um certo grau de conhecimento e capacitao
de cada colaborador para realizar um certo conjunto de tarefas.
Do ponto de vista de aprendizado ele entra no processo de ensinagem com

conhecimento (N-1) e, decorrido um certo perodo, vai receber este conhecimento e
vai subir para o degrau (N) de conhecimento.
Figura 58 Modelo final de ensinagem (Trindade, 2006)
Com isso ser capaz de voltar para a fbrica e produzir um pouco melhor, ou uma
outra atividade, em funo deste aprendizado. Teoricamente, este processo
acontece com todos os colaboradores e cada um possui um plano de carreira, o
plano de aprendizado. Observando novamente a figura, no processo de aprendizado
existe um instrutor ou no, conforme o tipo de aprendizado. Alguns instrutores
podem ser as prprias pessoas a fbrica que recebem um treinamento especfico
para poderem ser instrutores. Existe um repositrio onde so armazenadas todas as
documentaes dos materiais para a realizao da ensinagem. Observar que existe
no repositrio, em destaque, a gesto de carreiras e gesto de talentos, envolvendo
uma rede de especialistas que pode ter elementos fora da organizao e um banco
de clientes que forma a rede de aprendizado.
Observe a Figura 59 que mostra a escada do aprendizado juntamente com modelo

de ensinagem. Cada degrau possui um ciclo de aprendizado do modelo (Figura 58.
Em cima, esquerda da Figura 59, pode-se observar que so trs tipos de
aprendizado que um elemento da fbrica deve receber: administrao, processos e
tecnologias.
A Figura 58 representa um exemplo do modelo de ensinagem sendo aplicado na

escada dos conhecimentos.
Figura 59 Modelo de ensinagem e a escada de conhecimento com exemplo (Trindade, 2006)
No desenho est representada uma segunda escada, de tecnologia. Ao entrar na

empresa, o profissional dever ter seus conhecimentos mapeados para permitir e
elaborao de um plano de carreira. Esse elemento dever ter um ponto de insero
na escada devido aos conhecimentos que trouxe do mundo externo (como marcado
no desenho).
Este ponto de insero, e o plano de carreira, vo determinar qual a trajetria que

ser seguida. Pode-se observar que no exemplo da Figura existe um treinamento
em tecnologia sobre orientao objeto, depois dever aprender Java. Para aprender
Java existe uma outra escada com maior detalhamento, e um ponto de insero do
elemento, e assim sucessivamente.
VI.6 DDS-DESENVOLVIMENTO DISTRIBUIDO DE SOFTWARE
Na pesquisa de doutorado em andamento, desenvolvida com

Lrario (2006, 2007, 2008, 2009; PESSOA,2004c) est
sendo explorada a questo do desenvolvimento de software
distribudo, procurando responder a questo: Como as
organizaes desenvolvem software de maneira distribuda?
Esse tema de pesquisa surgiu ao se identificar que nas Fbricas de Software

muito comum a realizao de servios encomendados por terceiros, mostrando que
a cadeia de desenvolvimento de sofwatre maior que uma Fbrica isolada. Alm
disso, em funo da necessidade de reduo do tempo de desenvolvimento (time to
market) est cada vez mais comum a distribuio de uma grande tarefa para vrios
grupos de projeto com o objetivo de paralelizar as atividades.
VI.6.1 Propriedades de um DDS
Segundo Lrario (2006, 2008, 2009), h diversas propriedades que envolvem um

ambiente DDS- Desenvolvimento Distribudo de Software (Figura 60). Cada
propriedade determina o grau de complexidade de trabalho e revela consigo o quo
difcil produzir software em equipes fisicamente dispersas. Alm disso, cada
propriedade agrega consigo uma srie de conceitos que so: quantidade de arcel
(stios), difuso do processo, grau de interao, distncia fsica e granularidade do
repasse.
quantidade de sitios quanto maior o nmero de arcel envolvidos,

maior ser a complexidade e dificuldade de gerenciamento. Para ser
considerado DDS, no mnimo dois arcel precisam estar envolvidos.
difuso do processo esta propriedade trata das diferenas entre o

ambiente de desenvolvimento entre os diversos arcel envolvidos no
projeto. Na parte mais central est um ambiente heterognio onde a
padronizao de artefatos produzidos, ou seja, dos produtos elaborados
no projeto. Na parte mais externa est um ambiente homogneo, ou seja,
os diversos arcel utilizam o mesmo processo de desenvolvimento.
Homogneo
Padronizao dos artefatos e

processos
Difuso do processo
Padronizao dos
artefatos
r
pera
Qua o Coo
ntid ra ento
e inte
Heterogneo
ade lvim
de s au d borar e n vo vo
ites Gr Cola Des operati
ar ento Co
rden lvim o
Coo e n vo v
r Des laborati
a Co
In form
Agrupamento 2
inicial 1
Condies mnimas do DDS
c a d e
o
dig
h
Lin
Di
se
st
n
s
pa
ci
re
a
fs
do
ic
e
a
ad
Fronteira
id
De bal
r
Gl
la
se d e
o
nu
n v So
a
olv ft
Gr
im wa
o
en re
rvi
to
Se
Figura 60 Propriedades dos Ambientes DDS (Lrario 2006)
grau de interao trata da interao que existe entre os grupos dos

diversos arcel envolvidos no processo. Essa dimenso baseou-se em
Borghoff (2000) que classifica o grau de comunicao ente os grupos,
representado na Figura 61. O menor grau de comunicao seria apenas a
ocorrncia de informaes entre os grupos. O DDS comea a ocorrer no
segundo grau denominado Coordenar onde h um mnimo de
organizao entre os grupos para permitir a distribuio do trabalho. No
terceiro grau, denominado Colaborar, as equipes trabalham em uma
mesma obra e, no quarto Cooperar- as equipes interagem com maior
grau de intensidade visando uma associao para o bem comum: o
projeto.
distncia fsica dentro do pas o desenvolvimento denominado

Onshore e fora do pas, denominado Offshore. Quanto maior a
distncia, mais complexo torna-se o projeto em funo de lngua, aspectos
culturais e fuso horrio (Lrario, 2009). O caso de desenvolvimento
distribudo offshore denominado GSD Global Software Development.
Figura 61 Grau de comunicao entre os grupos (Borghoff, 2000)
granularidade do repasse est relacionada com a forma com que cada

sitio entrega seu subproduto na rede. Em um extremo est a construo
de cdigo (mais ao centro), o que leva a uma necessidade de
padronizao de ferramentas. No outro extremo est o repasse do servio
como um todo. Essa granularidade pode tambm estar definida de
maneira diferente entre os arcel (Lrario, 2009).
Outra dimenso da Figura 60 trata da forma de coordenao entre os diversos

arcel envolvidos com o(s) projeto(s), representado na Figura 62.
Superviso
direta
Mecanismos de coordenao
Abrangencia dos mecanismos sobre a DDS
habilidade dos
trabalhadores
processos de Padronizao
trabalho
resultados do
trabalho
relao mecanismo/propriedade
Ajuste Coordenao ad-hoc
mtuo
Nenhuma
coordenao
Figura 62 Relao entre os Mecanismos de Coordenao e as propriedades do DDS

(Lrario, 2009)
O nvel mais pobre de coordenao est representado embaixo e trata de uma

coordenao ad-hoc. Acima disso, h um ajuste mtuo entre os arcel de forma
reativa realizando correes medida que os problemas surgem. Em um grau um
pouco melhor, h os diversos nveis de padronizao, iniciando com a
padronizao dos artefatos produzidos (resultados do trabalho), dos processos
de trabalho (padres de processo) e padronizao de habilidades dos
trabalhadores (padres dos perfis dos profisisonais) at a superviso direta que
corresponde a uma coordenao centralizada.
VI.6.2 Modelo Proposto
Nesta pesquisa foram realizados 6 estudos de caso abrangendo um projeto

estritamente acadmico que deu uma srie de problemas por falta de coordenao,
duas empresas multinacionais com diversos stios em vrias partes do mundo
(ambas CMMI nvel 5), uma multinacional que atua exclusivamente na rea
financeira para um cliente com vrios stios (CMMI nveis 2 e 4), uma multinacional
que desenvolve software embarcado para celulares (CMMI nveis 3, 4 e 5) e uma
empresa nacional qua atua na rea financeira (CMMI nvel 2).
Figura 63 Modelo proposto M3DS (Lrario, 2009)

Lrario (2006, 2007, 2008) props um modelo preliminar que representa o

desenvolvimento de software distribudo sob a tica do distribuidor de tarefas que
coordena as aes entre os stios envolvidos com DDS. Depois de realizados os
estudos de caso, esse modelo evoluiu e foi denominado M3DS, representado na
Figura 63 na forma de mquina de estados (Lrario, 2009).
Na Figura 63 os quadrados azuis representam os stios envolvidos com DDS. Cada

stio pode estar trabalhando com um ou mais projetos. As elipses na cor creme
representam os estados do sitio e as elipses na cor azul representam os estados
de um projeto. Os estados so denominados Pi. As setas representam as
transies Ti que, em determinadas condies, levam de um estado Pj para o
estado Pk.
Os stios possuem transies de estado em linha potilhada. Os estados de um stio

so: novo stio (P8) quando entra no ambiente; desassociado (P12) quando sai do
ambiente; pronto para produzir (P9); produzindo (P10); bloqueado (P11) quando
est em condies de produzir e, por alguma razo, est aguardando algum evento
para retornar produo.
O projeto possui suas mudanas de estado com setas de linha cheia. O estado P0
uma novo projeto a ser iniciado. Estabelecidas as definies iniciais do projeto, ele
estar pronto para ser produzido (P1). Ao existir um sitio em condies de produzir
(P9) e um projeto pronto para ser produzido, criaram-se as condies para o projeto
entrar em produo (P2). Ao terminar uma parte chega-se ao estado P3 de
componente finalizado. H um estado especial onde um sitio fica bloqueado (P11)
e o mdulo do projeto fica em espera de alguma liberao (P7). Os componentes
finalizados entram no estado de integrao (P4) e testes de integrao- (P5). Ao
terminar essa fase, o projeto fica finalizado (P6).
Esse modelo foi desenvolvido de maneira formal utilizando Rede de Petri para
demonstrar de forma mais precisa o seu funcionamento.
VI.7 REUSO SISTEMATIZADO DE SOFTWARE
Repositrio o repositrio da Fbrica de Software pode ser

entendido como uma base de conhecimento onde est todo o
acervo do conhecimento explcito. A esto localizados os
processos de desenvolvimento propriamente ditos bem como
o repositrio dos projetos realizados, lies aprendidas, entre
outros. A biblioteca de componentes tambm faz parte desse
acervo. Nesse escopo foi desenvolvida uma pesquisa com Sheila Reinehr que
selecionou como foco de estudo a rea financeira por ser considerada, no Brasil, um
dos setores que mais investe em TI. A pesquisa avaliou o grau de maturidade com
que feito o reuso de software e se h iniciativas referentes definio de linha de
produto de software.
VI.7.1 Reuso de software
primeira vista, reuso pode ser compreendido como sendo o aproveitamento de um

cdigo de software j desenvolvido anteriormente. No entanto, o termo reuso admite
diversos significados, conforme definido na Norma IEEE (1999): o uso de um ativo
na soluo de diferentes problemas. Essa definio abrangente o suficiente para
admitir reuso de cdigo, estruturas de design, de implementao, especificaes,
transformaes, entre outros. Segundo Basili e Rombach (1991) apud Reinehr
(2008) limitar o reuso a apenas cdigo comete-se o erro de ignorar a importncia de
se reusar toda a experincia adquirida em projetos anteriores, o que inclui, produtos,
processos e outros conhecimentos.
A Figura 64 apresenta um resumo dos diversos autores que estabeleceram

classificaes das diferentes formas de reuso.
Ezram, Morisio e Trully (2002) apud Reinehr (2008) definiram que o reuso pode ser
feito quanto ao domnio ou quanto visibilidade. bom lembrar que o reuso de
qualquer ativo, seja requisito, anlise, design, cdigo ou teste.
Figura 64 Classificaes de reuso de software
Quanto ao domnio, o reuso pode ser vertical, mesmo domnio ou rea de

aplicao ou horizontal (domnios diferentes).
O reuso vertical pode apresentar similaridades tcnicas como

interfaces, drivers ou similaridades funcionais.
O reuso horizontal trata do aproveitamento do mesmo ativo em

diferentes domnios.
Quanto visibilidade os autores classificaram o reuso em caixa preta,

branca, cinza e de vidro.
O reuso caixa preta significa aproveitar o ativo sem alterao. Nesse

caso pode ser reutilizado internamente ou adquirido de terceiros.
O reuso caixa branca significa que o ativo precisa de alteraes.
O reuso caixa cinza significa que o ativo precisa ser modificado e isso
feito atravs de parmetros e no diretamente no cdigo.
O reuso caixa de vidro significa aproveitar o ativo sem alteraes, mas

para compreender suas propriedades necessrio analis-lo
internamente.
Pfleeger (2004) definiu reuso quanto forma de implementao: composio ou

gerao.
O reuso por composio, onde os componentes so vistos como blocos de

construo e o desenvolvimento realizado bottom-up. Normalmente so
utilizadas bibliotecas de componentes que so associados na aplicao nova.
No reuso por gerao os componentes so produzidos para tratar de

necessidades especficas de uma aplicao e depois so disponibilizados
para aplicaes semelhantes.
Prieto-Diaz (1993) apud Reinerhr (2008) elaborou uma classificao por

perspectivas, ou facetas que engloba praticamente as abordagens citadas
anteriormente. Cada faceta trata de um interesse especfico: substncia, escopo,
modo, tcnica, inteno, e produto.
A faceta por substncia significa o reuso de idias, conceitos em uma viso

mais abstrata. Tambm pode ser o reuso de procedimentos e perfis e, em
um nvel mais concreto, de artefatos e componentes.
A faceta por escopo pode ser horizontal ou vertical conforme j descrito

acima.
A faceta por modo o reuso planejado, sistematizado ou oportunista, ad-hoc.
A faceta por tcnica pode ser composicional ou por gerao, conforme j

apresentou Pfleeger (2004).
A faceta por inteno significa caixa preta ou caixa branca em funo da

alterao ou no do ativo.
A faceta por produto diz respeito a qual artefato objeto de reuso: cdigo
fonte, design, especificaes, objetos, testes ou arquiteturas.
Finalmente, com relao s estratgias de reuso, Ravichandran e Rothemberger

(2003) apud Reinehr (2008) apresentaram uma orientao para a definio das
estratgias de reuso a serem adotadas nas organizaes, conforme ilustrado na
Figura 65. estabelecida uma relao entre o custo da aquisio de um ativo, custo
de busca e de customizao.
Figura 65 Estratgias de Reuso (Reinehr, 2008)
VI.7.2 Evoluo do uso sistematizado de software
A Figura 66 ilustra a evoluo do uso sistematizado de software. Na dcada de 60

as primeiras iniciativas tratavam de criar sub-rotinas que ficavam disponibilizadas
Linha de Produtos
de Software
Componentes
Objetos
Mdulos
Sub-rotinas tempo (anos)
60 70 80 90 00 10
Figura 66 Evoluo do uso sistematizado de software
para reuso no ambiente da organizao. Nos anos 70 surgiram os mdulos. Nos

anos 80, com a mudana do mtodo de anlise para orientao a objetos, surgiram
os objetos. Nos anos 90 a orientao a objetos possibilitou o uso dos componentes
de software e nos anos 2000 esto vindo (ainda muito restrito seu uso) as linhas
de produto de software (REINEHR, 2008).
VI.7.3 Desenvolvimento de software baseado em componentes
Componente de software uma implementao em software que pode ser utilizada,

sem modificao, em diferentes aplicaes atravs das interfaces (API-Application
Program Interface).
Bass (2001) apud Reinehr (2008) define tecnologia de componentes como sendo um
ambiente onde os componentes so desenvolvidos, tambm chamado framework de
componentes. Desenvolvimento de Software Baseado em Componentes (CBSD)
constitudo dos passos tcnicos de design e implementao necessrios para
desenvolver componentes, para montar componentes na forma de sistemas e para
entregar os sistemas resultantes. Engenharia de Software Baseada em
Componentes (CBSE) o conjunto de prticas necessrias para executar o
desenvolvimento de software baseado em componentes de forma repetitiva (ou
repetvel) para construir sistemas com propriedades previsveis.
Reinehr (2008) descreve as principais caractersticas de um componente de

software:
uma unidade de instalao independente
uma unidade de composio de terceira parte, ou seja, um componente

pode ser combinado com outros componentes por uma terceira parte (que
no desenvolveu o componente)
no possui um estado externamente observvel, ou seja, no pode ser

distinguido de outras cpias de si mesmo
O desenvolvimento de um sistema com base em componentes , por sua vez, possui

as caractersticas apresentadas na Figura 67:
heterogeneidade permite que um sistema seja construdo a partir de

diferentes componentes, escritos em diferentes linguagens, plataformas e at
locais diferentes.
disponibilidade de cdigo fonte componentes adquiridos de terceiros podem

no oferecer acesso ao cdigo fonte
Figura 67 Caractersticas de um Sistema desenvolvido com base em Componentes
facilidade de evoluo esse tipo de desenvolvimento com o conceito plug

and play facilita o esforo de manuteno de software
distribuio os sistemas baseados em componentes facilitam o processo de

distribuio, particularmente pela internet
reusabilidade esse um dos principais objetivos dos sistemas baseados em

componentes, envolvendo componentes individuais e arquiteturas de
componentes
VI.7.3.1 O mtodo Kobra
O Kobra um mtodo para desenvolvimento de software baseado em componentes

desenvolvido pelo Fraunhofer Institute for Experimental Software Engineering,
baseado no conceito de linha de produtos de software (a ser descrito no prximo
item). Os componentes Kobra so definidos em um grau de abstrao mais alto,
lgico e no no sentido tradicional dos componentes fsicos que descrevem apenas
os aspectos de tecnologia (Corba, DCOM+, J2EE). Representam os blocos de
construo lgicos de um sistema de software. Por essa razo so denominados
Komponentes para identificar que so componentes Kobra, conforme representado
na Figura 68: especificao, realizao e implementao (Reinehr, 2008).
Figura 68 Nveis de abstrao de Komponente
Esses so os nveis de abstrao de um componente Kobra:
Especificao consiste de um conjunto modelos que conjuntamente

descrevem suas caractersticas:
o Modelo Estrutural de Especificao no nvel mais alto, a

especificao do komponente feita com a descrio das classes,
relacionamentos com o ambiente e qualquer estrutura que seja visvel
atravs da interface
o Modelo Comportamental mostra como o komponente se comporta

em resposta a um estmulo externo
o Modelo Funcional descreve os efeitos externamente visveis das

operaes oferecidas pelo komponente
Realizao descreve como uma instncia do componente realiza suas

especificaes em termos de interaes com outras instncias do
komponente. Deve ser especificada utilizando pelo menos os seguintes
componentes:
o Modelo estrutural de realizao - descreve a natureza das classes e

dos relacionamentos a partir dos quais o komponente realizado
o Modelo de atividades descreve os algoritmos atravs dos quais as

operaes so realizadas
o Modelo de interao prov uma informao similar ao modelo de

atividades sob a tica de interao e no de controle de fluxo.
Implementao descreve como o komponente trabalha de forma que

possa ser processado por ferramentas de compilao automatizadas.
Representada pelos seguintes artefatos:
o Cdigo fonte o cdigo propriamente dito
o Modelo estrutural de implementao refinamento do modelo

estrutural de realizao descrito em um nvel de abstrao prximo ao
cdigo fonte
o Modelo fsico de componente - refina o mapeamento dos

komponentes lgicos Kobra em componentes fsicos de acordo com o
meio fsico da implementao (Corba, COM +, JavaBeans, etc.)
o Pseudocdigo descreve a implementao algoritmica do komponente

de forma abstrata e em baixo nvel de abstrao
VI.7.3.2 Tecnologias baseadas em componentes
As tecnologias para desenvolvimento baseadas em componentes so relativamente

novas e so elas que permitiram uma efetiva implementao desses conceitos.
Segundo Reinehr (2008), especialmente no final dos anos 90, proliferaram as
tecnologias que permitem uma utilizao mais massiva do desenvolvimento baseado
em componentes. As principais tecnologias utilizadas so o Corba, EJB e COM+.
O Corba-Common Object Request Borker Architecture um padro que estabelece

a infraestrutura necessria para a interoperabilidade de diferentes implementaes
de objetos.
O EJB-Enterprise Java Beans faz parte do ambiente de desenvolvimento da Sun

Microsystems e so componentes que residem em um servidor de aplicaes. So
classes Java entregues atravs de um container.
O COM+ Common Object Model o modelo de componentes utilizado pela

Microsoft. Estabelece uma infraestrutura para implementao de componentes
normalmente implementados em C++ ou outra linguagem compatvel. Esse modelo
est presente no modelo proprietrio da Microsoft, o .NET (dot net) e nas

linguagens desse ambiente como o Visual Basic e C#.
VI.7.4 Famlia de produtos e linha de produtos de software
Segundo Reinehr (2008), a Europa tem investido em grandes projetos de

desenvolvimento de Linhas de Produto de Software com a participao de
universidades e empresas: Esaps (1999-2001), Caf (2001-2003) e Families (2003-
2005) envolvendo recursos da ordem de 100 milhes.
Empresas como Bosch, Alcatel, Nokia, Siemens e Philips participaram desses

projetos e desenvolveram famlias de produtos de software para seus respectivos
domnios de aplicao. Nesses projetos foram identificadas carncias estruturais
como a falta de uma arquitetura de disseminao de prticas que permitissem a
criao das famlias de produtos de software.
Um conceito importante criado no projeto Esaps foi a identificao da Engenharia de

Domnio e a Engenharia de Aplicao como atividades distintas, conforme
apresentado na Figura 69.
Figura 69 Modelo de Referncia do Processo do Esaps (Reinehr, 2008)
A Engenharia de Domnio aborda um domnio especfico para analisar requisitos,

projetar uma arquitetura adequada e implementar componentes para facilitar as
aplicaes. A Engenharia de Aplicao consiste na implementao de aplicaes a

partir dos requisitos do domnio e da biblioteca de componentes.
Um modelo criado no projeto Caf com o objetivo de definir de forma sistmica as

preocupaes da comunidade envolvida com o projeto foi o BAPO, representado na
Figura 70.
B O
Business Organization
A forma de Tecnologia necessria Estrutura e
obter lucro com para construir Sistemas responsabilidades
os produtos
resultantes
A organizacionais
durante o
desenvolvimento
Architecture
P
Process
Atividades e dependncias
durante o desenvolvimento
Figura 70 Modelo Bapo (adaptado de Reinehr, 2008)
Esse modelo, de alguma forma, cria um alinhamento entre as atividades de projeto

com as necessidades do negcio.
B representa o negcio (business) que orienta para analisar como o lucro

deve ser gerado
A representa a arquitetura, que so as tencologias necessrias para construir

o sistema
P representa o processo com responsabilidades e dependncias

principalmente com relao coordenao e colaborao entre a engenharia
de domnio e engenharia de aplicao
O representa a organizao na qual o software desenvolvido e o seu

preparo para lidar com os papis e responsabilidades referentes separao
da engenharia de domnio e engenharia de aplicao.
Nos Estados Unidos a denominao utilizada para a famlia de produtos SPL-

Software Product Line e foi desenvolvida pelo SEI-Software Engineering Institute
(Reinehr, 2008). Dessa forma foi criado um processo denominado SPLP-Software
Product Line Practice que possui processos com reas prticas de Engenharia de
Software, Gerenciamento Tcnico e Gerenciamento Organizacional. Foi tambm
criado um mtodo (PLTP) para avaliar se uma empresa est pronta para mudar de
paradigma e adotar as Linhas de Produto com sucesso (Reinehr, 2008).
VI.7.5 Maturidade de reuso de software
A adoo de uma abordagem de reuso pode ser avaliada tambm utilizando

modelos de maturidade. Foram desenvolvidos diversos modelos como o FEF-Family
Evaluation Framework. O grupo do C.E.S.A.R. ligado Universidade Federal de
Pernambuco propem um modelo de referncia para maturidade de reuso de
software (RiSE:RM- Reuse in Software Engineering: Reference Model) que contm
4 nveis de maturidade (Reinehr, 2008):
1: incompleto
2: bsico tcnicas e mtodos bsicos
3: definido monitoramento e controle do processo de reuso
4: sistematizado otimizao do processo de reuso, controle de qualidade

dos ativos, etc.
VI.7.6 Estruturao da pesquisa realizada
A pesquisa de campo foi realizada com o objetivo de verificar como o reuso de

software praticado nas organizaes do setor financeiro. Uma segunda questo,
derivada da primeira, saber como se realizam os processos de reuso de software e
como estes contribuem para o sucesso dos projetos. O protocolo de pesquisa foi
elaborado utilizando cinco proposies apresentadas na Figura 71.
Figura 71 Proposies da pesquisa de campo (Reinehr, 2008)
As proposies foram elaboradas a partir da literatura e considerou uma evoluo da

P1 (com pouca ou nenhuma prtica de reuso) at a P5 (eficcia no reuso).
A pesquisa foi realizada em 5 bancos, relatados no prximo item. Cada empresa

estudada recebeu uma carta de apresentao com termo de confidencialidade
assinado pela pesquisadora e pelo orientador, uma descrio geral dos objetivos da
pesquisa e uma descrio dos procedimentos operacionais (o que iria ser
perguntado). Esse cuidado foi tomado para facilitar o acesso s empresas, uma vez
que as informaes necessrias para a pesquisa so, de certa forma, sigilosas. Para
cada uma das proposies foram preparados pontos de anlise que orientaram as
entrevistas semi-estruturadas que foram realizadas nos bancos. Cada um dos
pontos de anlise foi cuidadosamente preparado contendo a origem (referencial
terico), descrio detalhada e quais as proposies relacionadas, conforme
ilustrado na Figura 72.
Figura 72 Pontos de anlise (Reinehr, 2008)
Foram, ao todo, elaborados 20 pontos de anlise. No cabe aqui detalhar tais

pontos mas, a ttulo de exemplo, pode-se observar que o ponto de anlise PA-10 na
Figura 73 refere-se a duas proposies.
Figura 73 Exemplo de Ponto de Anlise PA-10 (Reinehr, 2008)
VI.7.7 Resultados da pesquisa do setor financeiro
A escolha do setor financeiro para realizar a pesquisa sobre reuso de software foi
baseada no fato de que este setor realiza investimentos significativos em Tecnologia
da Informao. Segundo a Febraban (2009), em 2007 foram investidos R$6,2
bilhes nessa rea como um todo, dos quais R$2,26 bilhes referem-se a software
de terceiros, ou seja, software bsico e aplicativos, fbricas de software,
terceirizaes, aquisies de software, desenvolvimento de novas aplicaes e
manuteno de sistemas.
Na pesquisa de Reinehr (2008) foram estudados 5 grandes bancos que, somados,

representam 50% dos ativos totais do setor bancrio, 46% do lucro lquido e 59%
dos depsitos totais e 70% de todas as agncias do pas (dados de 2006). Isto
demonstra a importncia dessas organizaes no cenrio nacional. Todos os cinco
bancos so de grande porte, um de capital estrangeiro e trs de capital privado.
Foi identificado que quatro dos cinco bancos estudados tinham projetos de grande
porte em andamento na rea de TI. Esses projetos eram focados no somente em
tecnologia, mas tambm em metodologias de desenvolvimento de software.
Os resultados so apresentados abaixo, por proposio com comentrios

especficos.
VI.7.7.1 Proposio P1
Figura 74 Proposio P1 (Reinehr, 2008)
Na Figura 74 esto listados os conceitos de apoio identificados na literatura. Foi

observado que em 2 bancos esta proposio verdadeira e nos demais 3 existem
iniciativas mas no esto institucionalizadas por toda a organizao. Tambm foi
observado que os bancos esto em um momento de transio importante onde o
reuso um dos focos dessas mudanas.

Foi observado que existem prticas de uso no sistematizadas, mesmo nos bancos
onde h uma maior institucionalizao dessas prticas.
Foi identificado que existem prticas de linhas de produto de software uma vez que
j podem ser identificadas algumas prticas de engenharia de domnio.
Esta proposio foi considerada verdadeira pois existem fatores favorveis ao uso
de linhas de produto de software com relao a organizao, pessoal, processo e
produto.
Foi identificado que as prticas de reuso, mesmo as no sistematizadas contribuem

positivamente para o sucesso dos projetos de software, embora no tenham sido
encontradas medies sistematizadas em todos os bancos estudados que
evidenciassem quantitativamente esta observao.
Vale notar que, embora em todas as proposies tenham sido encontradas

iniciativas, h muito que caminhar ainda para o aperfeioamento do reuso
sistematizado e caminhar para o conceito de linhas de produto de software. Os
bancos (e foram estudados cinco dos dez maiores) at h pouco tempo atrs,
utilizavam reuso de maneira ad-hoc e oportunista baseado na experincia dos
profissionais ou equipes de projeto. Iniciativas no nvel organizacional existiam
restritos a atividades como administrao de dados, sub-rotinas de uso comum e
algumas iniciativas no sentido de padronizao de arquitetura tecnolgica como
funes de infraestrutura (integridade de transaes, log de aplicaes e
autenticao, por exemplo). Este era o quadro em 2005. Na poca da elaborao
desta pesquisa, conforme j relatado, grandes projetos de evoluo tecnolgica
estavam em andamento, fato que atrapalhou a classificao das prticas como
sistematizadas (a rigor no seriam) , mas claramente esse tema de reuso passou a
fazer parte das preocupaes e estratgia das novas arquiteturas e dos novos
processos.
Finalizando, importante ressaltar que a adoo das Linhas de Produto de Software

na rea financeira constitui uma inovao, pois na literatura, os casos relatados
referem-se principalmente a software embarcado das indstrias automobilstica,
aeronutica, telecomunicaes e equipamentos mdicos de tratamento de imagens.
A rea financeira possui a peculiaridade de tratar sistemas de informaes de forma
centralizada com grande volume de transaes de forma centralizada (em

mainframes) e com grande ndice de integrao entre as empresas do setor, um
perfil muito diferente dos casos acadmicos publicados.
VI.8 PRODUTIVIDADE EM FS
A pesquisa realizada com Moreira (2007) abordou os aspectos

de produtividade na construo de cdigo em uma Fbrica de
Software. Uma das dificuldades para se gerenciar uma Fbrica
de Software a capacidade de realizar estimativas e medidas
nas atividades realizadas. O desenvolvimento de software
intensivo em mo de obra e a produtividade depende dos profissionais envolvidos no
trabalho pois, alm dos aspectos tcnicos, h os aspectos humanos a serem
considerados. Tal fato conhecido na manufatura h muitos anos, conforme relata
Fleury (1983), mas nas atividades de desenvolvimento de software, o estudo desse
tema mais recente. Essa pesquisa teve por objetivo identificar os fatores que
influenciam a produtividade, validar o grau de influncia desses fatores, compar-los
com a percepo das pessoas envolvidas com as atividades na Fbrica de Software,
e propor um modelo de produtividade.
Foi desenvolvida uma pesquisa-ao em uma Fbrica de Software (FS) que estava
implantando o nvel 4 do CMMI. O CMMI, nesse nvel, aborda aspectos de
gerenciamento quantitativo, oportuno para a realizao deste trabalho. Foram
usados mtodos estatsticos para avaliar as medidas realizadas no ambiente da
Fbrica.
VI.8.1 Fatores que influenciam a produtividade em uma FS
Produtividade a razo das unidades de sada produzida pelo esforo das unidades
de entrada (MOREIRA, 2007). Os fatores que influenciam a produtividade na
produo de software podem ser agrupados em trs dimenses:
fatores tecnolgicos como linguagens de programao, ferramentas de

projeto, ambientes de desenvolvimento e capacidade dos equipamentos
utilizados
fatores humanos onde so considerados o perfil, formao, motivao,

comprometimento e capacitao das pessoas, alm do modelo de
gerenciamento utilizado
fatores organizacionais referentes aos processos de trabalho utilizados

como metodologia, prtica gerencial, ambiente fsico referente a
acomodaes, conforto e bem estar dos recursos humanos
Um fator importante na medio das atividades de software est ligado com a

capacidade de realizar estimativas. Entre os principais mtodos existentes h a
abordagem de linhas de cdigo e a abordagem de pontos de funo, j relatadas
neste trabalho no Captulo V.1.
Foram estudados dois modelos para realizar medies nos processos de software:
GQM Gol Question Metric (BERGHOUT, 1999 apud MOREIRA,2007) e PSM
(McGARY, 2000 apud MOREIRA, 2007). Esses mtodos estabelecem tcnicas
sistematizadas para a criao e uso de um sistema integrado de medies no
processo de software a partir de metas e polticas definidas da organizao.
Os fatores analisados da literatura que influenciam a produtividade em uma Fbrica

de Software foram:
Processos
o Maturidade
o Gerenciamento eficaz
o Uso de Mtodos Estruturados
o Documentao (especificao)
o Equipes de Projeto e Estrutura Organizacional
o Capacidade de Anlise de Requisitos
o Prototipao antes do desenvolvimento
o Flexibilidade no desenvolvimento
o Mudana de especificao
o Complexidade do produto
o Tamanho do produto
o Erros
o Custo de reviso
Pessoas
o Treinamento
o Qualificao: competncias e experincia
o Comprometimento (moral e remunerao das equipes)
o Rotatividade e reduo de equipes
Tecnologia
o Ambientes de desenvolvimento
o Existncia de precedentes
o Estratgia de Reuso
o Geradores de Cdigo
Esses foram os fatores analisados nos projetos da Fbrica para identificar que
fatores influenciam ou no na produtividade e servirem de base para elaborao do
modelo.
VI.8.2 A pesquisa realizada
A pesquisa foi realizada em uma Fbrica de Software localizada em Salvador, Bahia.

Esta fbrica possui certificao ISO 9001, o processo de desenvolvimento foi
avaliado no nvel 3 de maturidade do CMMI e no momento da realizao da
pesquisa estava trabalhando na implantao dos nveis 4 e 5.
O ambiente estudado possui cerca de 150 profissionais, 83% da equipe tem at 30

anos, 71% do pessoal possui formao universitria completa. Tempo de casa
mdio da equipe 36 meses e todos so contratados no modelo CLT.
A Fbrica trabalha na construo de cdigo realizando as atividades de codificao

e testes (fases anteriores como requisitos e anlise so realizadas fora da Fbrica)
e utiliza tecnologias Java e .Net da Microsoft (dot net).
Os projetos realizados na Fbrica so classificados por tamanho medidos em pontos

de funo. Projetos com mais de 1.500 PF so considerados grandes e abaixo de
200 PF so pequenos e entre os dois valores, mdios. Nos projetos pequenos foi
identificado que no h escala suficiente para diluir os custos de gerenciamento. Por
essa razo h um processo simplificado para esses casos.
Na pesquisa foi realizada uma anlise de varincia utilizando uma ferramenta de

estatstica. A seguir so apresentados os resultados do levantamento realizado na
Fbrica, organizados nas dimenses processos, pessoas e tecnologia.
VI.8.2.1 Dimenso processos
Foram analisados 33 projetos em um perodo de 30 meses onde a empresa evoluiu

do nvel de maturidade 2 at o 4 e 5. Com isso foi possvel separar os projetos
realizados com processo nvel 2, nvel 3 e nveis 4 e 5 (esses considerados em
conjunto).
A Quadro 11- Produtividade x Nvel de Maturidade mostra que houve uma pequena
evoluo na produtividade quando a Fbrica de Software evoluiu para os nveis mais
altos de maturidade. Vale salientar que a produtividade aumentou, mas a varincia
tambm! Tambm importante lembrar que no momento que foram realizadas as
medidas os nveis 4 e 5 estavam em fase de implantao, ou seja, os processos
ainda em fase de consolidao.
Nvel Qtde projetos Mdia Desvio padro
2 7 0,2395 0,0458
3 19 0,2590 0,0688
4e5 7 0,3687 0,1865
Quadro 11- Produtividade x Nvel de Maturidade (Moreira, 2007)
No foram encontradas correlaes significativas entre o esforo de gesto e a

produtividade dos projetos.
Um processo padro (estruturado) aplicado a todos os projetos realizados.

Praticamente no h variao de processo (tailoring) e portanto sob a tica da
produtividade no h variao significativa.
Todos os projetos possuem especificao documentada. O que varia a qualidade

desse documento. O processo de reviso da especificao filtra possveis erros para
que na Fbrica de Software no entre especificao inadequada. A anlise feita foi a
correlao entre o esforo de equalizao e os erros de especificao detectados.
Foi encontrada correlao significativa e portanto este fator foi considerado no
modelo.
Considerando que todos os projetos so realizados na mesma estrutura

organizacional, o fator Equipes de Projeto e Estrutura Organizacional no foi
considerado como influente na produtividade.
A FS no realiza a identificao e levantamento de requisitos e portanto a

Capacidade de Anlise de Requisitos no um fator de influncia na produtividade.
A anlise realizada no ambiente da Fbrica j foi considerada no fator
documentao.
A prototipao antes do desenvolvimento foi desconsiderada no modelo pois 100%

dos projetos pesquisados realizam esta atividade.
O fator Flexibilidade no Desenvolvimento foi descartado pro se tratar de uma Fbrica

com processo bem definido e com baixa flexibilidade para alteraes.
As Mudanas de especificao foram identificadas que influem negativamente na

produtividade e tambm foram consideradas no modelo.
Figura 79 Taxa de Mudana x Produtividade (Moreira, 2007)
O Grfico de Contorno ilustrado na Figura 79 mostra que, quanto maior a taxa de

mudanas, maior tende a ser o nmero de erros por ponto de funo e menor a
produtividade. No eixo X est representada a taxa de mudanas de um projeto, no
eixo Y est representado o nmero de erros por ponto de funo e na intensidade da
cor verde observa-se a produtividade onde, quanto mais escura a cor, maior a
produtividade. Nesse grfico pode-se interpretar que quando h taxas baixas de
mudanas (at aproximadamente 20%), a produtividade maior. A mancha escura
direita indica que outros fatores influram na produtividade.
Os projetos que fazem parte da amostra coletada possuem classificao por

complexidade. Foi possvel constatar que a Complexidade do Produto influi
negativamente com a produtividade, embora essa relao no seja muito
significativa, e portanto esse fator foi desconsiderado no modelo.
Com relao ao Tamanho do produto versus a produtividade, a relao foi

considerada fraca e portanto no foi includa no modelo.
consenso que os erros podem ser retirados do software. Quanto mais cedo isto
feito, menor seu efeito negativo na produtividade. Foi possvel verificar que a
eficcia dos testes um fator importante para a produtividade, conforme ilustrado no
Grfico de Contorno da Figura 80. Nesta figura, o eixo X representa a produtividade,
o eixo Y representa a eficcia dos testes e na intensidade da cor verde observam-se
os erros embarcados por ponto de funo onde, quanto mais escura a cor, maior o
nmero de erros por Ponto de Funo. Observar tambm que, a partir de uma
eficcia nos testes de 92%, o nmero de erros constante e no varia com a
produtividade. Dessa forma os erros foram considerados no modelo pois implicam
em retrabalho e reduzem a produtividade. Aqui foram considerados os erros
embarcados e erros internos.
Figura 80 Produtividade versus Taxa de Erros (Moreira, 2007)
Do ponto de vista conceitual da qualidade deve-se fazer certo da primeira vez

(Deming, 1990). O Custo de Reviso, ou Retrabalho portanto um fator importante
de reduo da produtividade e foi considerado no modelo.
VI.8.2.2 Dimenso pessoas
A amostra estudada foi em um perodo de 24 meses onde foram analisadas as

horas gastas nos projetos e os treinamentos realizados.
Os treinamentos das pessoas foram considerados eficazes e contribuem para a

qualificao dos profissionais. No estudo foram identificadas 2.214 horas de
treinamento com avaliao positiva da ordem de 92% . Como esse valor

homogneo e eficaz, no foi considerado fator que influa na produtividade.
Foi identificado que a experincia dos profissionais influi na produtividade. No

entanto, as pessoas mais experientes so alocadas para realizar atividades mais
complexas, reduzindo a produtividade. Assim, no global a influncia da competncia
e experincia baixa e esse fator no foi considerado no modelo.
Foram conduzidos dois estudos sobre Comprometimento e Desempenho na Fbrica

e foi identificado que o nvel de comprometimento dos profissionais alto. No
entanto no foi possvel identificar correlao entre esses temas e a produtividade,
razo pela qual no foi considerada no modelo.
Foi calculada a correlao entre a mdia das horas alocadas em codificao e a

produtividade de codificao e o resultado foi negativo. Isto significa que o fator
Rotatividade baixo e no considerado no modelo.
VI.8.2.3 Dimenso tecnologia
A amostra estudada foi de projetos realizados em um perodo de 24 meses.
Ambientes de desenvolvimento foi identificado que as ferramentas do ambiente

Microsoft so mais integradas. Embora na tecnologia Java o ambiente seja menos
integrado, esse fator no foi considerado no modelo pois no foi considerado como
influente na produtividade.
A Existncia de Precedentes verificada pela organizao na sua base de

conhecimento. No foi possvel estabelecer uma relao entre a precedncia e a
produtividade. No foi considerado no modelo.
A Estratgia de Reuso mais significativa o framework que possui utilizao da

ordem de 96%. No foi possvel determinar o ganho obtido com o uso de framework,
mas foi considerado no modelo uma queda de 10% de produtividade se no houver
seu uso.
Uso de Gerador de Cdigo foi comprovado que o gerador de cdigo oferece um

ganho de 45% de produtividade. Esse fator foi considerado no modelo.
VI.8.2.4 Fatores considerados no modelo
A Tabela X apresenta um resumo dos fatores descartados e selecionados para uso

no modelo.
Quadro 12 Resumo dos fatores considerados no modelo (Moreira, 2007)
VI.8.3 Modelo obtido
A Figura 81 apresenta o modelo obtido a partir de uma amostra de 37 projetos 11

desenvolvidos com tecnologia Java e 16 com tecnologia Microsfot.
O modelo de produtividade obtido em Moreira (2007) tem relao negativa com

erros embarcados. Ou seja, quanto maior a quantidade de erros embarcados, que
representa o modelo da qualidade no enfocado por este trabalho, menor ser a
produtividade. Os fatores principais identificados como preditores da produtividade
foram o retrabalho, a instabilidade dos requisitos (caracterizada pela taxa de
mudana dos requisitos, que a razo entre o tamanho total das mudanas e o
tamanho do projeto), e a produtividade de codificao. O retrabalho positivamente
pressionado pelos erros internos, qualidade da especificao e negativamente pelo

esforo de gesto e de codificao. Ou seja, quanto mais se investe em codificao,
menos retrabalho ocorre. Embora isso represente um paradoxo, remete diretamente
qualidade das atividades de codificao e a necessidade de maturar o cdigo
antes de envi-lo para testes. A produtividade de codificao impactada
positivamente pelo uso de geradores de cdigo.
Figura 81 Modelo de Produtividade obtido (Moreira, 2007)
As equaes obtidas servem para estimativa de produtividade e de retrabalho nos

projetos.
Ambiente Microsoft:
Produtividade = +0,230
+0,155 ProdutividadeCodificao
-0,358 PercentRetrabalho
-0,121 Taxa Mudana
PercentRetrabalho = +0,118
+0,0026 Erros Internos PF
-0,00148 Erros especifi PF
-0,0718 Percentual Gesto
Ambiente Java:
Produtividade = +0,0449
+0,024 ProdutividadeCodificao
-0,166 PercentRetrabalho
-0,425 Taxa Mudana
PercentRetrabalho = +0,0645
+0,00281 Erros Internos PF
-0,00377 Erros Especif PF
Observar que h diferenas referentes tecnologia utilizada.
Tambm foi desenvolvido um modelo da qualidade que faz a previso de erros

embarcados, conforme apresentado na Figura 82. Segundo Moreira (2007), o
modelo da qualidade est baseado na eficcia dos testes, de mudana de requisitos
e nos fatores de erros internos e embarcados.
Figura 82 Modelo da Qualidade obtido (Moreira, 2007)
Este modelo contribui para o entendimento da qualidade dos produtos gerados no

ambiente da Fbrica estudada. H uma relao negativa entre esses fatores . O
modelo no estratificado por tecnologia e possui apenas uma equao. Foi um
resultado adicional interessante, pois no era objetivo da pesquisa.
A equao do modelo da qualidade :

ErrosEmbarcados PF = +28,5
-7,23 TaxaMudana
-22,8 TxEficcia Testes
-25,9 PercentValidao
VI.8.4 Percepo dos fatores de produtividade
Um contraponto ao modelo quantitativo foi a identificao das percepes da equipe

com relao aos fatores de produtividade (Moreira, 2007). Para tanto, foi passado
um questionrio para explorar qual a viso que os participantes do processo de
software tinham com relao aos fatores apontados pela literatura, cujos resultados
esto na Figura 83. Foi utilizada uma escala Likert com 7 nveis.
Figura 83 Percepo da Equipe com relao aos fatores de Produtividade (Moreira, 2007)
A assertividade no planejamento das atividades apresenta variao na percepo de

3 a 5. O acompanhamento de projetos percebido de forma clara e com baixa
variao entre 5 e 6. O uso de metodologias e de documentao, a existncia de um
sistema de mtricas e a definio de equipes para projeto so altamente percebidos,
embora haja variao na intensidade de 5 a 7. A qualidade da documentao e a
existncia de precedentes (lies aprendidas) no tm percepo forte e focada. O
uso de prottipos muito percebido. O fator complexidade dos projetos
considerado relevante, embora o tamanho dos projetos no sejam considerados
grandes.
O retrabalho altamente percebido. A prpria metodologia prev 14% de retrabalho

nos projetos, considerando que a Fbrica tambm ambiente de formao de novos
talentos.
VI.8.5 Consideraes sobre a pesquisa de Produtividade em Fbrica
A pesquisa-ao desenvolveu um modelo bastante diferenciado pois na literatura h

poucas publicaes sobre resultados concretos. Particularmente esta pesquisa
cumpriu plenamente seu papel pois, conforme j citado, a Fbrica estava em fase de
implantao do nvel 4 do CMMI que exige abordagem quantitativa e os resultados
obtidos foram adotados para uso. A pesquisa, por sua vez, exigiu um estudo mais
sistemtico da teoria alm de obrigar o domnio das ferramentas estatsticas que o
pesquisador desconhecia antes desse trabalho.
Esta pesquisa foi bastante diferenciada em relao s demais por realizar um estudo
quantitativo em um ambiente onde existem poucos trabalhos similares. O modelo
desenvolvido bem especfico para a Fbrica de Software estudada pois diversos
fatores desprezados so claramente importantes em outros ambientes mas o
importante desse trabalho foi a tcnica desenvolvida para se chegar ao modelo.
VI.9 QUICKLOCUS: AVALIAO DE PROCESSO
Na pesquisa desenvolvida com Kohan (2003) foi identificado

que os processos de desenvolvimento de software so
intensivos em trabalho humano e, alm disso, dependem
fortemente da compreenso clara do processo para que o
mesmo seja realizado pelos profissionais de forma correta,
com qualidade e produtividade. Dessa forma, com essa
pesquisa foi proposto um mtodo de avaliao de processo de desenvolvimento
visando sua aplicao a pequenas organizaes que desenvolvem software. Esse
mtodo foi denominado Quicklocus e largamente utilizado nas atividades de
consultoria em processo de software da Fundao Vanzolini.
VI.9.1 Problemas na avaliao do processo de software
Conforme j citado, o trabalho intensivo em mo de obra torna a sua qualidade

fortemente dependente das pessoas. Considerando que a qualidade nos produtos
de software pode ser obtida atravs de um bom processo, conforme j definido no
captulo II viso do processo de software, surge a necessidade de fazer a
avaliao do processo praticado. Em outras palavras, necessrio saber se as
pessoas esto, no desenvolvimento de seu trabalho, seguindo o processo prescrito.
O foco desta pesquisa foi desenvolver um mtodo adequado de avaliao de

processo que possa oferecer uma viso confivel do processo praticado indicando
os pontos que so atendidos e as divergncias identificadas, especfico para
pequenas organizaes. O foco nas pequenas organizaes foi escolhido por duas
razes:
os mtodos existentes so apropriados para grandes organizaes que

desenvolvem software, tanto pelo custo como pelo tempo necessrio para
realizar uma avaliao (Kohan, 2003);
grande parte das empresas que desenvolvem software so pequenas

organizaes que no tm acesso a mtodos de alto custo (Kohan, 2003).
VI.9.2 Os mtodos de avaliao existentes
Diversos mtodos de avaliao foram estudados, classificados em trs grupos:
Mtodos do SEI Software Engineering Institute
Mtodos da ISO International Organization for Standardization
Outros mtodos
Os mtodos do SEI analisados talvez sejam os mais conhecidos em funo da

disseminao do CMMI. A Figura 84 ilustra os mtodos analisados, mas vale
ressaltar que hoje apenas o SCAMPI utilizado e os demais ficaram obsoletos com
a substituio do CMM pelo CMMI.
Figura 84 Mtodos de avaliao do SEI (Kohan, 2003)
Os mtodos da ISO analisados esto relacionados na Figura 85. As avaliaes para

a ISO 9001 so muito genricas para a finalidade desta pesquisa e vale ressaltar
que a ISO 15504 na poca da pesquisa estava em fase de elaborao, tendo sido
publicada em 2004 (partes 1, 3 e 4) e, no Brasil, a ABNT publicou somente em 2008
(partes 1, 2, 3, 4 e 5).
Figura 85 Mtodos de avaliao da ISO (Kohan, 2003)
Foram tambm analisados outros sete mtodos no to disseminados ou fora do

foco deste trabalho.
VI.9.3 Descrio do QuickLocus
O desenvolvimento de um mtodo para avaliao do processo de software exige

algumas definies conceituais. Nielsen & Pries-Heje apud Kohan (2003)
estabeleceram alguns parmetros para essa finalidade apresentando trs
dimenses para se definir a estratgia de avaliao, conforme a Figura 86.
Figura 86 Dimenses das estratgias de avaliao (Kohan, 2003)

Dimenso Modelo versus Problema, ou seja, utiliza-se como referncia um

modelo de boas prticas (como o CMMI) ou avaliam-se os problemas
existentes.
Dimenso Relevncia versus Rigor, ou seja, so destacadas para anlise

apenas questes mais relevantes ou a avaliao exaustiva.
Interveno versus Gerenciamento Dirio, ou seja, a avaliao realizada

atravs de uma interveno na organizao avaliada ou a avaliao
realizada continuamente durante a operao (por exemplo SQA).
No caso do QuickLocus foi escolhido um mtodo baseado em modelo (podem ser
utilizados diferentes modelos), as anlises so realizadas com base na relevncia

dos itens analisados e a abordagem por interveno, embora esta seja
minimizada.
O mtodo foi desenvolvido abordando aspectos comportamentais e tcnicos. As
principais caractersticas do QuickLocus so (Kohan, 2008):
Avaliao de pequenas organizaes com at cerca de 50 desenvolvedores;
Avaliao com escopo reduzido do modelo 3 reas de processo em um dia;
Avaliao de at 4 diferentes processos existentes na organizao;
Tamanho da equipe de avaliao: 3 pessoas
Duas fontes de dados: questionrios e entrevistas
Durao do trabalho na organizao: um dia
Graduao de prticas do modelo com maior grau de detalhe
Essas caractersticas do uma idia do que seja o mtodo e mostra sua adequao
a pequenas organizaes. A avaliao sempre realizada com pelo menos uma
pessoa da organizao que deslocada para fazer parte da equipe de avaliadores.
O QuickLocus possui 3 fases:
Preparao
Avaliao
Ps-avaliao
A Figura 87 apresenta as 3 fases do QuickLocus com as principais atividades de

cada uma.
Fase 1: preparao Fase 2: avaliao

Definir escopo Colecionar dados fonte 1:
Definir modelo de referncia questionrio
Selecionar processos do modelo Reunio abertura: orientao aos
Planejar a avaliao participantes
Treinar equipe de avaliao Coletar dados fonte 2: entrevistas
Fazer graduao final
Mostrar resultados preliminares
Fase 3: ps-avaliao
Mostrar resultados finais
Reunio de encerramento
Armazenar resultados da avaliao
Figura 87 Fases do QuickLocus
A fase de preparao define o escopo a ser avaliado, que reas e projetos da

organizao sero analisados. O modelo de referncia precisa ser escolhido, como
por exemplo o CMMI ou o MPSBR. As reas de processo precisam ser definidas,
considerando que em um dia possvel avaliar apenas 3 (por exemplo planejamento
de projeto, controle de projeto e garantia da qualidade). Em havendo necessidade
de avaliar mais processos, haver necessidade de mais tempo na organizao. O
tempo de treinamento da equipe de 2 a 4 horas considerando que os participantes
conheam o modelo e tcnicas de melhoria de processo (essa atividade focada no
profissional da empresa avaliada). O planejamento da avaliao deve ser bem
detalhado com dia, horrio e locais bem definidos, em funo do envolvimento de
muitas pessoas. Nesse planejamento recomendado realizar as entrevistas em uma
sequncia top-down, ou seja, da alta administrao, passando pelos gerentes at os
tcnicos visando entender primeiramente o direcionamento estabelecido para em
seguida observar as prticas reais.
A fase de avaliao se inicia com a anlise da fonte 1 de dados, um questionrio

entregue para a empresa responder anteriormente fase de entrevistas.
Normalmente o questionrio respondido pelo responsvel pela melhoria de
processo. Uma reunio de abertura com todos os envolvidos realizada visando

comunicar com clareza os objetivos e orientar o comportamento de todos os
entrevistados. As entrevistas so realizadas na organizao no menor tempo
possvel (minimizar a interveno) e as perguntas so focadas nos quesitos dos
processos escolhidos, procurando objetividade e evidncias nas respostas.
necessrio obter a confirmao nas entrevistas para considerar uma prtica do
modelo atendida. Todas as respostas devem ser registradas em planilhas
adequadas. A equipe de avaliao realiza uma graduao dos resultados utilizando
consenso. Ao final das entrevistas realizada uma reunio de fechamento
apresentado os resultados obtidos.
A fase ps-avaliao consiste na elaborao do relatrio final e uma reunio com a

apresentao dos resultados (que pode ser realizada no final das entrevistas, se
conveniente). Os resultados da avaliao so sigilosos e portanto a documentao
utilizada deve ser inutilizada e armazenados apenas os resultados finais. Este
cuidado importante para evitar o registro de atribuies de declaraes a pessoas
especficas.
Um exemplo de resultado da avaliao mostrado na Figura 88. Para apresentao

desses resultados foi criada a metfora do semforo, com a utilizao das cores:
verde (conforme: E a prtica existe), amarela (parcialmente conforme: M a
prtica existe mas precisa ser melhorada) e vermelha (no conforme: N a prtica
no existe). Pode-se observar que esses grficos do uma boa viso do resultado
da avaliao. O exemplo mostra uma avaliao dos processos referentes ao nvel 2
do CMMI. Foi uma avaliao de 2 dias na organizao. As barras empilhadas da
direita mostram, por exemplo, que o processo de gerenciamento de requisitos
(REQM) est completamente atendido e o processo medies e anlise (MA) no
atendido.
Figura 88 Exemplo de resultado consolidado do QuickLocus
VI.9.4 A medio de um processo de software
Para melhor compreender o ato de medir, interessante verificar os conceitos

utilizados na rea de instrumentao. A ISO 5725-1 (Kohan, 2003; ISO 5725-1,
1994) define o termo accuracy (exatido) como sendo a proximidade dos resultados
com o valor verdadeiro (trueness), bem como sua disperso (precision), conforme
ilustrado na Figura 89. A preciso (precision) do resultado est ligada com a
repetibilidade e reprodutibilidade.
Trueness
Accuracy Repetibilidade
Precision
Reprodutibilidade
Figura 89 Accuracy (Kohan, 2003)
A repetibilidade est ligada com os resultados independentes obtidos atravs da

aplicao do mesmo mtodo, no mesmo laboratrio, sobre os mesmos itens de
teste, pelo mesmo operador, utilizando-se os mesmos equipamentos, dentro de um
curto intervalo de tempo.
A reprodutibilidade so as condies nas quais os resultados de teste so obtidos

com a aplicao do mesmo mtodo, sobre os mesmos tpicos de testes, em
laboratrios diferentes, com diferentes operadores, utilizando-se diferentes
equipamentos.
No caso do QuickLocus essa preocupao importante pois, embora no haja
laboratrio nem instrumentos de medio, h operadores utilizando mtodos de

medida. A troca de operadores (avaliadores) ou mesmo a escolha de diferentes
documentos a serem analisados e diferentes pessoas a serem entrevistadas, devem
levar a resultados se no iguais, ao menos similares.
Esses aspectos foram analisados na pesquisa de Kohan (2003). Goldenson apud

Kohan (2003) identificou que as avaliaes de processo possuem quatro principais
fontes de erro:
1. Ocasies diferentes
2. Avaliadores diferentes
3. Instrumentos diferentes
4. Contedo diferente em um mesmo instrumento
O uso de questionrios padronizados e entrevistas planejadas luz de quesitos de

um modelo selecionado aumenta a reprodutibilidade e reduz o risco do item (2).
A utilizao do consenso entre os avaliadores e a utilizao de mais de um

instrumento de coleta de dados para atribuio da graduao traz duplo benefcio:
as eventuais inconsistncias de respostas se tornam objeto de questionamento
posterior e que so resolvidos por consenso. Este quesito corresponde
repetibilidade da avaliao.
A definio de usar equipes experientes nas avaliaes melhora a preciso

(precision) dos resultados pois favorece as condies de reprodutibilidade e
repetibilidade das avaliaes realizadas.
O mtodo original no utiliza como fonte de dados o exame de documentos,

acarretando na perda de accuracy dos resultados. Essa foi uma deciso tomada
para reduo de custo e tempo de avaliao. Por outro lado, por no ser um mtodo
que leva certificao e sim com o objetivo de realizar planos de melhoria e ou
preparao para a avaliao formal, essa situao, nas entrevistas, leva as pessoas
a terem uma postura mais aberta no sentido de no terem motivos para dissimular
resultados nas entrevistas.
VI.9.5 Resultados
Desde o seu desenvolvimento, o QuickLocus vem sendo utilizado em atividades
de consultoria em atividades de melhoria de processo de software. Esse mtodo foi

aplicado em mais de 40 avaliaes nas mais diversas organizaes, inicialmente
pelas pessoas que desenvolveram o mtodo, mas posteriormente por pessoas que
foram treinadas e passaram a utiliza-lo. Interessante observar que nesses 6 anos de
utilizao, o mtodo continua o mesmo. Para realizar melhoria de processo na
organizao, no h necessidade de alterao do mtodo.
Quando o mtodo aplicado com a finalidade de verificar se a organizao est

pronta para uma avaliao oficial, entretanto, foi identificado que importante
acrescentar uma avaliao documental. A anlise dos documentos importante
nessa situao.
O MPS BR, modelo brasileiro desenvolvido pelo Softex para pequenas empresas de
software, utiliza um mtodo de avaliao que teve como uma das referncias o
QuickLocus.
Essa pesquisa foi um trabalho que trouxe um grande nmero de benefcios prticos
tanto do ponto de vista de melhor compreender o processo de avaliao, como do
ponto de vista de aplicao em situaes reais.
VI.10 CONSIDERAES FINAIS SOBRE PROCESSO DE SOFTWARE
Este captulo encerra a apresentao sobre as pesquisas realizadas sobre o

processo de software. Foram apresentados 9 trabalhos e, no prximo captulo,
realizado uma anlise crtica sobre os resultados obtidos com essas pesquisas
todas, avaliando aspectos positivos e negativos.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-183
VII ANLISE CRTICA DA OBRA
Este captulo tem por objetivo fazer uma anlise crtica da obra, ou seja, um balano
geral sobre a experincia de ter realizado as pesquisas aqui relatadas, e identificar
os pontos positivos e aqueles que poderiam ser melhorados. Dessa forma, esta
anlise ser realizada sob os seguintes aspectos: o grupo de pesquisa, o contedo
das pesquisas, os alunos pesquisadores e os resultados obtidos acadmicos e no
acadmicos.
VII.1 O GRUPO DE PESQUISA
A existncia do grupo de pesquisa GTI Gesto em Tecnologia da Informao foi a

estrutura que facilitou a realizao dos trabalhos aqui apresentados. Este Autor
realizou pesquisas no mestrado e no doutorado em duas reas vinculadas
Engenharia Eltrica, onde a organizao do grupo era natural, pela especialidade
como foi o caso do LSD - Laboratrio de Sistemas Digitais, e do PEA
Departamento de Energia e Automao Eltrica. Na Engenharia de Produo, o
espectro de assuntos to grande que, se no houver uma estruturao, fica difcil
a formao natural de pontos de acumulao em torno dos temas. Antes de 1998,
ano da criao desses grupos por iniciativa da Reitoria, existiam evidentemente as
pesquisas e os grupos, mas estes eram informais. Particularmente a rea de TI onde
este pesquisador se encontra no tinha uma identidade e chegava a ser mal vista
em algumas situaes. Uma das primeiras recomendaes que este Autor recebeu
ao ingressar como docente no Departamento foi para no orientar nenhum trabalho
de formatura onde o aluno fizesse software, pois isso era considerado computao e
no engenharia de produo. Felizmente essa fase j passou e fica muito claro
aps todos esses anos de pesquisa e convivncia que o engenheiro de produo
lida com mtodos e com pessoas e muito disso se concretiza em informao,
tornando necessrio realizar a organizao das informaes e, ainda mais, utilizar a
TI como ferramenta e no como um fim em si mesmo.
Entre todos os grupos de pesquisa talvez o GTI seja um dos que tenha mais
usufrudo dessa sinergia (da existncia dos grupos de pesquisa). A estruturao do
eLab-TI como Fbrica de Software o grande tema de pesquisa foi conseqncia
natural da formao do grupo. Este Autor tambm considera que a oportunidade de
realizao desta tese trouxe, de uma forma sistemtica, um resumo muito claro dos
resultados alcanados.
H, entretanto, correntes de pensamento que consideram os grupos de pesquisa

segregacionistas, que impedem a realizao de pesquisas multidisciplinares.
Analisando a forma organizacional por especialidade, fica evidente que esta uma
estrutura natural em qualquer organizao que congrega os especialistas em um
mesmo grupo. Dentro dessa abordagem, o que falta a montagem de uma estrutura
matricial para a realizao dos projetos multidisciplinares de pesquisa, como ocorre
tambm nas organizaes.
VII.2 CONTEDO DAS PESQUISAS
Com relao ao contedo das pesquisas realizadas, este Autor considera que so
temas bastante atuais, embora tambm tenha sido evidenciado nesse trabalho que a
preocupao com mtodos de anlise e projeto de software seja uma preocupao
antiga. Ocorre entretanto que, de uma maneira geral, os profissionais de TI focam
mais suas preocupaes na tecnologia, deixando em segundo plano os aspectos
organizacionais. Mesmo as pesquisas na rea de computao tm sido, de uma
maneira geral, com foco majoritariamente tecnolgico: em vrias dessas pesquisas
de TI o foco desenvolver uma ferramenta para dar suporte atividade e no
observ-la como um todo (viso sistmica) considerando as pessoas e os processos
de trabalho como parte integrante dessa atividade. Recentemente houve uma
palestra da IBM8 no Departamento de Engenharia de Produo denominada Cincia
de Servios, onde o palestrante, um funcionrio que tem como atividade realizar
pesquisa (e no trabalhos tcnicos profissionais) veio fazer um convite para
participao em pesquisas desta empresa pois haviam descoberto que os sistemas
desenvolvidos precisam ser analisados de uma forma mais abrangente. At
apresentaram um logo human inside parodiando o conhecido Intel inside. Sem
entrar no mrito da questo a engenharia de produo e particularmente GTI faz
isso h muito tempo, como foi demonstrado nesta tese.
8
Palestra ministrada pelo Dr. Cludio Pinhanez em junho de 2009.
Outro aspecto importante foi um claro amadurecimento com relao aos mtodos
utilizados para a realizao das pesquisas. As primeiras pesquisas desenvolvidas
por este Autor tiveram, do ponto de vista metodolgico, alguns pontos que hoje
poderiam ser questionados, pois o principal foco era sobre o tema em si, sem uma
preocupao com a sistemtica de obteno de dados e sua validao. Interessante
observar que esse foi um amadurecimento das pesquisas na rea de gesto de
operaes em geral, tanto que foi criada h alguns anos a disciplina metodologia de
pesquisa e, at os congressos internacionais desenvolvem hoje sees dedicadas a
metodologia de pesquisa nessa rea.
A experincia desse Autor tem sido na utilizao dos mtodos de estudo de caso e,
ultimamente, pesquisa-ao, dependendo do tipo de trabalho desenvolvido.
Analisando a forma com que o mtodo de pesquisa conduzido nos ltimos
trabalhos pode-se identificar claramente a melhoria da qualidade dos mesmos.
O modelo de referncia desenvolvido para a Fbrica de Software atual at hoje,

embora tenha sido concebido por volta de 2001. Esse modelo uma adaptao da
aplicao dos conceitos de produo (manufatura) produo de software e,
conforme detalhado no texto, incorpora processos de trabalho bem definidos e
preocupao com agilidade, produtividade, reuso, famlia de produtos, gesto de
projeto, gesto do conhecimento, treinamento e capacitao estruturados, produo
distribuda, anlise de negcios e alinhamento com as necessidades da
organizao, gesto da informao, gesto de requisitos.
Costa (2003) em 2003 demonstrou em sua pesquisa que poucas Fbricas de

Software utilizam concretamente os conceitos estabelecidos no modelo e, mais
recentemente, Reinehr (2008) em 2008 identificou que a rea financeira,
considerada como uma das mais evoludas na utilizao em grande escala da
Tecnologia da Informao, ainda incorpora poucos conceitos estabelecidos no
modelo de referncia.
O prprio modelo de referncia teve evolues quando Trindade (2006), Fabri

(2007) e LErrio (2009) ao desenvolverem suas pesquisas propuseram um
detalhamento nos respectivos temas: gesto do conhecimento, criao e
organizao dos processos de uma Fbrica de Software e DDS - Desenvolvimento
Distribudo de Software.
VII.3 OS ALUNOS PESQUISADORES
Um levantamento para identificar o tipo de aluno que foi orientado por este Autor
ofereceu os resultados aqui descritos.
A mdia de idade dos alunos que fizeram mestrado ou doutorado cerca de 40

anos, mostrando um valor relativamente elevado. Talvez seja porque nesses ltimos
dez anos ocorreu uma exigncia de titulao de professores das escola particulares
(nas pblicas isso j ocorria), fato que criou uma maior procura. O orientado mais
velho tinha 62 anos na poca da defesa e o mais novo 23 anos na entrada do
programa.
Com relao ao tipo de atividade profissional que os alunos possuem, basicamente

36% professor, 30% analista de sistemas e 27% consultor. Os demais
especializaram-se em educao a distncia. Dos consultores, quase todos so da
rea de TI mas alguns atuavam na rea da qualidade e gesto de operaes.
Com relao a bolsa de pesquisa, apenas 6% dos alunos possui. Este Autor acredita
que esse baixo ndice de bolsistas se deve ao fato do valor ser muito baixo para
sustentar uma pessoa em So Paulo e as diversas oportunidades profissionais que
surgem na rea de TI no a tornarem atraente. A idade mdia de 40 anos mostra
tambm que os valores das bolsas podem no viabilizar financeiramente o
orientado.
Do ponto de vista de quem orienta, interessante possuir orientados com

experincia trabalhando lado a lado com pessoas mais jovens. Existe uma certa
dificuldade com os consultores que muitas vezes tiram concluses sem os
necessrios cuidados acadmicos de embasamento. No entanto, vencida essa
dificuldade, normalmente tornam-se bons pesquisadores. Os mais jovens tm a
vantagem da grande energia que possuem, fato que compensa a falta de
experincia.
De todos os alunos orientados 30% so egressos de graduao da USP e apenas

12% so egressos do Departamento de Engenharia de Produo.
Outro ponto interessante a se observar o fato do aluno no ter dedicao total

pesquisa. Se por um lado ruim em funo da falta de tempo, por outro lado bom
pois as empresas nas quais os alunos trabalham podem se tornar bons objetos de
pesquisa e as portas esto quase que automaticamente abertas.
Vale observar que a escolha do tema de pesquisa muito importante pois necessita
de um casamento entre a oportunidade e o interesse do aluno com as questes de
pesquisa que o grupo est lidando. Antes da criao do GTI esses temas eram
quase que uma espcie de gerao espontnea onde o aluno trazia o seu
cenrio e da se extraia a pesquisa a ser realizada. Hoje, com mais clareza do
objeto de pesquisa ao qual o grupo se dedica, h uma seleo natural pois os
alunos que procuram a equipe j leram e entenderam os temas de interesse do GTI
e a convergncia mais rpida e natural.
VII.4 RESULTADOS ACADMICOS
A avaliao dos resultados acadmicos feita sobretudo atravs das publicaes

realizadas. Isso pode ser visto no memorial circunstanciado que acompanha este
trabalho. Na opinio deste Autor a gerao de conhecimento foi muito maior que as
publicaes realizadas, ou seja, muitas oportunidades de publicao no foram
concretizadas, talvez por uma falta maior de foco nessa atividade. Houve
dissertaes que no geraram nenhuma publicao e so trabalhos de alto nvel.
Uma preocupao mais recente sistematizar melhor esta atividade para que haja
uma maior presena em revistas, particularmente internacionais. Hoje, trata-se de
uma questo de sobrevivncia para quem quer se manter nesse ambiente de
pesquisa.
Por outro lado, h resultados tambm acadmicos, que normalmente no so

considerados nas avaliaes, mas que so muito interessantes e merecem ser
relacionados.
O primeiro deles a formao de uma rede de pesquisadores que acaba se

formando quase que naturalmente a partir de alunos egressos do programa. Assim,
hoje h uma troca de informaes com ex-alunos com os quais so elaborados
artigos de interesse comum e, particularmente no momento da elaborao deste
trabalho, encontra-se em andamento um projeto de pesquisa Proenge financiado
pela Capes.
Outro resultado importante a criao na ps-graduao de disciplinas que

nasceram de pesquisas realizadas ou que incorporam em seu contedo esses
resultados. A disciplina PRO5768 Planejamento, estratgia e gesto da tecnologia
da informao nasceu com a vinda do Professor Piercarlo Maggiolini do Politcnico
de Milano e, ao longo do tempo, foi incorporando diversos temas de pesquisa,
particularmente do Prof. Fernando Laurindo.
A disciplina PRO5846 Gesto da informao e do conhecimento: conceitos e

estratgias nova e tem feito muito sucesso entre os alunos. No ano de 2008 houve
a procura de 50 candidatos. O contedo foi dividido com o Prof Fernando Laurindo e
Davi Nakano e boa parte foi aproveitada das pesquisas desenvolvidas no GTI.
A graduao tambm se beneficiou dessas pesquisas pois hoje a disciplina PRO -

2513 Gesto da tecnologia da informao foi criada a partir da PRO 5846 adaptada
para a graduao, oferecendo aspectos mais prticos e de uso profissional para os
alunos.
Outra disciplina que sempre recebe a incorporao de novos temas a PRO 2511 -
Sistemas de informao, modernizada gradativamente medida que novos
mtodos, processos e tecnologias vo se consolidando.
VII.5 RESULTADOS NO ACADMICOS
O principal resultado no acadmico a canalizao do conhecimento para a

comunidade no acadmica atravs das atividades de extenso. Infelizmente esse
tipo de atividade no valorizada pela comunidade acadmica, mas deveria ser.
Afinal, o conhecimento gerado na academia apenas sendo publicado em artigos
internacionais no traz diretamente benefcios para a comunidade que sustentou
financeiramente o desenvolvimento do trabalho. Particularmente nos Estados Unidos
e na Europa a academia est prxima das empresas na gerao de tecnologia e
conhecimento, conforme pode ser claramente observado no trabalho de Reinehr
(2008).
Este Autor tem tentado aproximar a academia das empresas atravs da Fundao
Vanzolini, entidade que foi criada para essa finalidade. No entanto h problemas
culturais em ambos os lados mas alguns resultados podem ser relacionados. Aqui
sero citados apenas trs resultados que saram diretamente das pesquisas
realizadas.
O primeiro deles o QuickLocus, um mtodo de avaliao de processo de software

que at hoje utilizado para avaliar processo de desenvolvimento de software (j
aplicado em mais de 40 avaliaes). Deu origem a um mtodo de avaliao do
MPSBR, um modelo brasileiro de processo de desenvolvimento de software.
Um outro trabalho de impacto para a sociedade foi a avaliao do processo de

adequao ao ano 2000 que nasceu de uma dissertao de mestrado (no
detalhada nesta tese) (Prando, 1999) mas que gerou uma Norma de adequao
(registrada no escritrio de direitos autorais da Fundao Biblioteca Nacional) e uma
srie de atividades de certificao pela Fundao Vanzolini. Esse foi um caso de
falta de publicao de textos acadmicos sobre o tema.
O Curso de Capacitao em Anlise de Negcio, por sua vez, nasceu a partir da

pesquisa citada nesta tese sobre o analista de negcio. Este curso est em sua
segunda turma e tem sido ministrado com sucesso pois preenche uma lacuna de
conhecimento dos profissionais que exercem esse tipo de atividade.
VII.6 CONSIDERAES FINAIS
Este trabalho procurou apresentar uma anlise crtica da obra acadmica deste
Autor que, embora tenha sido redigida apenas por uma pessoa, o resultado do
trabalho de uma equipe de pelo menos 37 pessoas que atuaram diretamente em
diversas partes do mesmo, sem contar aqueles que tiveram tambm contribuies
annimas.
Foi apresentada a criao do GTI e logo a seguir da Fbrica de Software (eLab-TI) e

mapeadas e apresentadas as pesquisas realizadas.
Neste trabalho no foram abordados aspectos de implantao e de operao da TI,

mas apenas as pesquisas realizadas nas primeiras fases do ciclo de vida: anlise de
negcios, arquitetura da soluo (anlise de sistemas), implementao e aspectos
internos de gesto dos projetos e repositrio. No entanto, foram realizadas diversas
pesquisas referentes a falhas em projetos de TI, sistemas integrados de gesto
ERP, implantao. O que se nota em quase todas as pesquisas, a carncia de

gesto em ambas as reas: h um excesso de tecnologias que no funcionam
direito, projetos que no chegam ao fim e processos de trabalho que no se alinham
com as tecnologias. Esses so portanto os desafios para o futuro que podem ser
divididos em dois grupos: o projeto de operaes integradas e a capacitao das
pessoas.
Com relao ao projeto de operaes integradas o que est faltando uma viso
mais sistmica das operaes que so implementadas nas empresas considerando
as estratgias das organizaes, as necessidades organizacionais em termos de
processos de trabalho, capacitao das pessoas e tecnologias coerentes de forma a
se obter um sistema que opere de forma integrada. Engenharia de Sistemas um
tema que este Autor tem estudado nos ltimos anos, tendo criado e ministrado
diversas vezes uma disicplina com esse nome no curso de Gesto da Tecnologia da
Informao. Pode-se observar que os alunos, na totalidade profisisonais de TI,
pouco conhecem sobre viso sistmica. H tambm pesquisas em andamento sobre
a produo de software sem cdigo (cdigo zero), onde a preocupao maior com
a engenharia de domnio, como o caso da implantao de sistemas BPMS
Business Process Management System. Outro desafio interessante seria a
elaborao de um modelo de referncia equivalente ao do eLab-TI centrado nas
atividades de implantao e operao de Sistemas de TI.
Com relao capacitao das pessoas h muito o que pesquisar pois, conforme
definido no modelo de referncia do eLab-TI pouco foi estudado sobre residncia em
software e capacitao de profissionais. A inovao, a nova palavra de ordem,
sempre foi um problema para os profissionais de Tecnologia da Informao pois a
formao profissional no suficiente devido rpida obsolescncia de tecnologias
e a vinda de novas outras que as integram ou substituem, fato que cria a
obsolescncia do conhecimento. Dessa forma, a manuteno de um profissional
atualizado, a sua requalificao um problema para as organizaes e para os
prprios profissionais, sendo estes temas desafiadores para novas pesquisas. Est
em andamento uma pesquisa que vai analisar o trip empresas, profissionais e
escolas.
O principal resultado de todo esse esforo o conhecimento adquirido e a certeza

de que, quanto mais se aprende, mais h a aprender.
REFERNCIAS
(IEEE 1517) IEEE Computer Society. Standard for Information Technology

Software Life Cycle Processes Reuse Processes. New York. IEEE 1999.
(ISO 12207) INTERNATIONAL ORGANIZATION FOR STANDARDIZATION.

ISO/IEC 12207 Systems and software engineering Software life cycle.
Second Edition. Geneva, 2008.
(ISO 5725-1) INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO

5725-1 Accuracy (trueness and precision) of measurement methods and
results Part 1: General Principles and Definitions. arce, ISO 1994.
ABNT ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO/IEC 12207

Tecnologia de Informao Processos de Ciclo de Vida de Software. Rio de
Janeiro: ABNT, 1997.
ALTER, Steteven Information Systems: a Management Perspective. California:

The Benjamin/Cummings Publishing Company Inc., 1992. Information, Decision
Making and Models.
BABoK The Guide to the Business Analysis Body of Knowledge IIBA

Interntional Institute of Business Analysis Version 2.0 Draft for Public Review 2008.
270p obtido em www.theibba.org/BABOK2 em 10 de abril de 2008.
BAUER, W.; JUNCOSA, M. ; PERLIS, A.J. ACM Publication Policies and Plans.
Journal of the ACM 6; April, 1959.
BAUER,F.L.; BOLLIET, L.; HELMS, H.J Software Engineering Report NATO

Science Committee. Garmisch, Germany. January, 1969. Disponvel em :
http://www.europrog.ru/book/nato1968e.pdf Acesso em 02 fev 2009.
BOEHM, Barry W. Software Engineering Economics Prentice Hall, Inc. 1981.
BOOCH, Grady. Object Solutions Manage the Object-Oriented Project. Addison

Wesley. USA.1996.
BORGHOFF, U., SCHLICHTER, J., Computer-Supported Cooperative Work

Introduction to Distributed Applications. 1. ed. Berlin: Springer, 2000. 529 p.
BOYER, Carl B.. Histria da Matemtica. Edgard Blucher,1974.
CARR, N. G. IT doesnt matter. Harvard Business Review, v81, n.5 , 2003.
CARVALHO, Marly Monteiro de ; PESSA, M. S. P. ; LAURINDO, Fernando Jos

Barbin ; RABECHINI JR, Roque . Equivalncia e completeza: anlise de dois
modelos de maturidade em gesto de projetos. RAUSP. Revista de
Administrao, v. 40, p. 289-300, 2005
CASTILHO FILHO, Antonio Francisco Ferreira de. Avaliao Uso de Novas

Tecnologias de Informao nas Empresas internet, Intranet e Extranet
Estudo de Casos. 1998. 0 f. Dissertao (Mestrado em Engenharia Engenharia de
Produo) Universidade de So Paulo. Orientador: Marcelo Schneck de Paula
Pessa
CMMI Product Team. Capability Maturity Model Integration (CMMI), Version 1.1:
CMMI for Systems Engineering, Software Engineering, Integrated Product and
Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1),
Staged Representation (CMU/SEI-2002-TR-012, ESC-TR-2002-012). Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University, March 2002a.
(Disponvel em
http://www.sei.cmu.edu/publications/documents/02.reports/02tr012.html)
COAD, Peter; YOURDON, Edward. Anlise Baseada em Objetos. Campus. Rio de

Janeiro. 1992
COOKE, Cssio Sodr. Gesto de servios proposio de um mtodo para

obteno de vantagem competitiva atravs da fidelizao do consumidor.
2000. Dissertao (Mestrado em Engenharia de Produo) Universidade de So
Paulo, . Orientador: Marcelo Schneck de Paula Pessoa
COSTA, Ivanir ; PESSA, M. S. P. ; SPINOLA, Mauro de Mesquita . Uso da Curva

ABC na Tcnica de Anlise por Pontos de Funo nas Estimativas de Projetos
de Software. In: XXIII ENEGEP ENCONTRO NACIONAL DE ENGENHARIA DE
PRODUO, 2003, Ouro Preto, MG. Anais do XXIII ENEGEP Encontro Nacional
de Engenharia de Produo, 2003.
COSTA, Ivanir. Contribuio para o Aumento da Qualidade e Produtividade de

uma Fbrica de Software atravs da Padronizao do Processo de
Recebimento de Servios de Construo de Softwares. 2003. Tese (Doutorado
em Engenharia (Engenharia de Produo) Universidade de So Paulo.
CUSUMANO, M.A. Japans Software Factories. New York: Oxford University

Press. 1991
DE MARCO, Tom. Anlise estruturada e especificao de Sistema. Rio de

Janeiro, Campus, 1989.
DEL MASCHI, Valrio Fernandes. Diretrizes Estratgicas para Empresas

Desenvolvedoras de Sofware com Foco em Produtro. So Paulo,
2009.Dissertao (Mestrado em engenharia de produo). Universidade Paulista
UNIP. Orientador: Marcelo Schneck de PaulaPessa.
DEMING, E. W. Qualidade: a Revoluo da Administrao. Rio de Janeiro.

Marques-Saraiva. 1990
FABRI, J. A. ; TRINDADE, A.L.P.; DURSCKI, R. ; SPINOLA,, M. M. ; PESSOA, M. S.

P. . Proposta de um Mecanismo de Desenvolvimento e Customizao de uma
Fbrica de Software Orientada a Domnios. In: XXXI Latin American Computing
Conference, 2005, Cali. Anais do XXXI Latin American Computing Conference, 2005
FABRI, J. A. ; TRINDADE, A.L.P; SILVEIRA, M. ; PESSOA, M. S. P. . O Papel do

CMMI na Configurao de um Meta-Processo de Produo de Software com
Caractersticas Fabris: Um Estudo de Caso. In: VI Jornadas Iberoamericanas de
Ingeniera del Software e Ingeniera del Conocimiento, 2007, Lima Peru. Anais
das VI Jornadas Iberoamericanas de Ingeniera del Software e Ingeniera del
Conocimiento, 2007a. V. 1. p. 375-383
FABRI, J. A.; SCHEIBLE, A. C. F.; MOREIRA, P. M. L., TRINDADE, A. L. P.;

BEGOSSO, L. R.; BRAUN A. P.; PESSA, M S. de P. Meta-Process used for
Production Process Modeling of a Software Factory: the Unitech Case. In:
Managing Worldwide Operations and Communications with Information Technology
IRMA 2007b Proceedings. Vancouver, Canad. 2007b
FABRI, J. A.; TRINDADE, A. L. P.; BEGOSSO, L. R.; PESSOA, M. S.; LERRIO, A.

The Use of the IDEF-0 to Model the Process in a Software Factory. In: Managing
Worldwide Operations and Communications with Information Technology IRMA

2007c Proceedings. Vancouver, Canad. 2007c
FABRI, J. A.; TRINDADE, A.L.P. ; BEGOSSO, L. R. ; LERARIO, Isso ; SILVEIRA, F.

L. F. ; PESSOA, M. S. P. . Techniques for the Development of a Software
Factory: Case CEPEIN-FEMA.. In: 17th International Conference Software &
Systems Engineering and their Applications., 2004, Paris. Annals of 17 th International
Conference Software & Systems Engineering and their Applications, 2004. v. 3
FABRI, J. A.; TRINDADE, A.L.P; LERARIO, Isso ; PESSOA, M. S. P. . A

Organizao de uma Mquina de Processo e a Melhoria do Processo de
Produo de Software em um Ambiente de Fbrica. In: VI Jornadas
Iberoamericanas de Ingeniera del Software e Ingeniera del Conocimento, 2007,
Lima Peru. Anais das
FABRI, Jos Augusto ; LERARIO, Alexandre ; TRINDADE, Andr Luiz Presende ;

PESSA, M. S. P. ; LAURINDO, Fernando Jos Barbin . O Alinhamento
Estratgico de Negcios e Tecnologia da Informao nos Cursos de
Computao, Administrao e Engenharia de Produo. In: In: XI CONGRESSO
CIESC 2003 CONGRESSO IBERO-AMERICANO DE EDUCAO SUPERIOR
EM COMPUTAO, 2003, La Paz. La Paz
FABRI, Jos Augusto ; TRINDADE, Andr Luiz Presende ; LERRIO, Alexandre ;

PESSA, M. S. P. ; SPINOLA, Mauro de Mesquita . Desenvolvimento e
Replicao de uma Fbrica de uma Software. In: VI Simpsio Internacional de
Melhoria de Processo de Software SIMPROS, 2004 a, So Paulo. Anais do VI
Simpsio Internacional de Melhoria de Processo de Software SIMPROS, 2004 a.
FABRI, Jos Augusto. Uma proposta de modelo para a criao e a organizao

de processos de produo em um contexto de fbrica de software.. 2007. Tese
(Doutorado em Engenharia (Engenharia de Produo)) Universidade de So
Paulo, . Orientador: Marcelo Schneck de Paula Pessoa
FARBEY, B.; LAND, F.F.; TARGETT, D. A taxonomy of information systems

applications: the benefits evaluation ladder. European Journal of Information
Systems, v4, n1, 1995.
Febraban. Pesquisa O Setor Bancrio em Nmeros. Acesso em 04/07/2009 a

http://www.febraban.org.br/p5a_52gt34++5cv8_4466+ff145afbb52ffrtg33fe36455li54
11pp+e/sitefebraban/informacoes_do_setor.pdf
FELICIANO Neto, Isso; FURLAN, J. D.; HIGA, W. Engenharia da Informao:

metodologia, tcnicas e ferramentas. 2. ed. McGraw Hill, 1988.
FERNANDES, A.A. ; TEIXEIRA, D.S. Fbrica de Software:Implantao e Gesto

de Operaes. So Paulo, Editora Altas, 2004.
FERNANDES, A.A. O Paradigma da Fbrica de Software: Itens Qualificadores e

Ganhadores de Pedido e Prticas das Empresas de Informtica no Brasil. 2000.
Tese (Doutorado em Engenharia de Produo) Departamento de Engenharia de
Produo EPUSP.
FERREIRA, Aurlio Buarque de Holanda. Dicionrio Aurlio. Rio de Janeiro,

Editora Nova Fronteira, 1986.
FLEURY, Afonso Carlos Corra; VARGAS, Nilton. Organizao do Trabalho: uma

abordagem interdisicplinar. So Paulo, Atlas. 1983;
FOWLER, Martin; SCOTT, Kendall UML Distilled Appplying the Standard

Object Modeling Language. Addison Wesley. USA. 1997.
FREITAS, Lus Ricardo Napolitano. Projetos em Tecnologia da Informao:

Como Acertar Atravs da Anlise dos Erros. 2000. 175 p. Dissertao (Mestrado)
Escola Politcnica, Universidade de So Paulo, So Paulo, 2000.
FRONTINI, Maria Alice Braga. A Fbrica de Software. 1988. 229 p. Trabalho de

Formatura, Escola Politcnica, Universidade de So Paulo, So Paulo, 2000.
GANE, C.;SARSON, T. Anlise Estruturada de Sistemas, Rio de Janeiro, Editora

LTC, 1983.
GLOVER, Bill; HIMANSHU, Bhatt. Fundamentos de RFID, Rio de Janeiro, Alta

Books, 2007.
GONALVES, Rodrigo Franco . Uma abordagem Sistmica para o Processo de

Produo em Engenharia Web, na fase de Concepo. 2009. Qualificao
(Doutorado em Engenharia de Produo) Universidade de So Paulo, . Orientador:
Marcelo Schneck de Paula Pessa
GONALVES, Rodrigo Franco ; GAVA, Vagner Luis ; PESSA, M. S. P. ; SPINOLA,

Mauro de Mesquita . Fundamentos de Engenharia Simultnea na Produo de
Aplicaes Web. In: XXVII ENEGEP ENCONTRO NACIONAL DE ENGENHARIA
DE PRODUO, 2007, Foz do Iguau, Andr197. XXVII ENEGEP ENCONTRO
NACIONAL DE ENGENHARIA DE PRODUO, 2007. p. 414.
GONALVES, Rodrigo Franco ; GAVA, Vagner Luis ; PESSA, M. S. P. ; SPINOLA,

Mauro de Mesquita . Produo de Software para Web: uma proposta de
processo. In: ENEGEP 2005 a XXV ENCONTRO NACIONAL DE ENGENHARIA
DE PRODUO, 2005 a, Porto Alegre. ENEGEP 2005 XXV ENCONTRO
NACIONAL DE ENGENHARIA DE PRODUO, 2005 a.
GONALVES, Rodrigo Franco ; GAVA, Vagner Luiz ; PESSA, M. S. P. ; SPINOLA,

Mauro de Mesquita . Uma proposta de processo de produo de aplicaes
Web. Produo (So Paulo), v. 15, n. 3, p. 376-389, 2005.
GONALVES, Rodrigo Franco ; GAVA, Vagner Luiz ; Rita Cristina Ferreira ;

PESSA, M. S. P. . Ergonomic Challenges in Information System Implantation
for Building Design Support: a Brazilian experience. In: ODAM IX 2008, 2008,
Guaruj, So Paulo. IX Simpsio Internacional em Ergonomia no Projeto
Organizacional e Gesto, 2008.
GONALVES, Rodrigo Franco ; PESSA, M. S. P. . Entropia em Postos de

Trabalho:uma proposta de mtrica para avaliao ergonmica. In: ENEGEP
2005c XXV ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, 2005c,
Porto Alegre.
GONALVES, Rodrigo Franco ; PESSA, M. S. P. ; SPINOLA, Mauro de Mesquita ;

PRADO, Jos Pacheco de Almeida . A Importncia de Representar Pessoas na
Modelagem de Processos de Negcio. In: ENEGEP 2005b XXV ENCONTRO
NACIONAL DE ENGENHARIA DE PRODUO, 2005b, Porto Alegre. ENEGEP
2005b XXV ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, 2005b.
HAUFFE, Thomas. Design: An Illuistrated Historical Overview. Barrons, 1996.
HEGEDUS, C. E. ; TAVARES, E. S. ; WILTEMBURG, C. S. ; PESSA, M. S. P. .

Knowledge Management as a 197ndr197197197s element to implement ISO
9000 program. In: Proceedings of the 7th International Conference on ISO 9000 and
TQM, 2002, Melbourne. Change Management Proceedings of the 7 th International
Conference on Iso 9000 & Tqm (7-ICIT), 2002. p. 55-56.
HENDERSON, J.C.; VENKATRAMAN, M. Strategic Alignment: Leveraging

Information Technology for Transforming Organizations. IBM Systems Journal
vol. 32 , 1993, pp. 4-16.
HUMPHREY, W. S. A discipline for software engineering. Reading, MA: Addison-

Wesley, 1995. (SEI series in software engineering).
HUMPREY, W. Managing the Software Process, Reading, MA: Addison Wesley,

1989
JACINTHO, Jos Carlos. Avaliao econmica dos investimentos em tecnologia

da informao. 2000. Dissertao (Mestrado em Engenharia de Produo)
Universidade de So Paulo, . Orientador: Marcelo Schneck de Paula Pessa
JURAN, J.M.; GRYNA, F.M. Controle da Qualidade Handbook Conceitos,

Polticas e Filosofia da Qualidade. 1 edio, So Paulo, Makron Books do Brasil ,
1991.
KOHAN, Sarah. QuickLocus: Proposta de um Mtodo de Avaliao de Processo

de Desenvolvimento de Sofware em Pequenas Organizaes. 2003. 235p.
Dissertao (Mestrado Profissional) Instituto de Pesquisas Tencolgicas do Estado
de So Paulo, So Paulo, 2003.
KOHAN, Sarah; PESSA, Marcelo S.P.; SPINOLA, Mauro M. QuickLocus: a

Software Development Process Evaluation Method for Small-sized
Organizations. In: Oktaba, Hanna; Piatini, Mario. Software Process Improvement for
Small and Medium Enterprises Techniques and Case Studies Chapter V: pgs
109-139. Ed. IGI Global. Hershey, USA. 2008.
KUNUTH, D.E. Computer Programming as an Art. Communications of the ACM

New York, USA. Volume 17 Issue 12, December, 1974.
LERRIO, Alexandre. M3DS: Um modelo de dinmica de desenvolvimento

distribudo de software. 2009. Tese (doutorado em Engenharia de Produo)
Departamento de Engenharia de Produo (no prelo).
LERARIO, Alexandre ; PESSA, M. S. P. . UM MTODO DE ENSINO E

PRTICAS DE DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE PARA
CURSOS DE GRADUAO. In: COBENGE Congresso Brasileiro de Educao
em Engenharia, 2008, So Paulo. Anais do XXXVI Congresso Brasileiro de

Educao em Engenharia, 2008.
LERARIO, Alexandre ; PESSOA, Marcelo Schneck de Paula . A dinmica e as

suas propriedades dos ambientes de desenvolvimento distribudo de software:
um estudo de caso. In: XII Congreso Argentino de Ciencias de la Computacin,
2006, San Luis. Anais do XII Congreso Argentino de Ciencias de la Computacin,
2006. v. 1. p. 12-22
LERARIO, Alexandre ; PESSOA, Marcelo Schneck de Paula . An Analysis of the

Dynamics and Properties of the Distributed Development of Software
Environments: A Case Study. In: SERP07- The 2007 International Conference on
Software Engineering Research and Practice, 2007, Las Vegas. Software
Engineering Research and Practice, 2007. v. 2. p. 471-477
LAINO, C. P. ; FERNANDES, L. M. M. ; GONALVES, Rodrigo Franco ; COSTA,

Ivanir ; PESSA, M. S. P. . Uso de ferramenta WIKI para gesto do
conhecimento: um estudo de caso em instituio financeira. In: ENEGEP, 2008,
Rio de Janeiro. XVIII Encontro Nacional de Engenharia de Produo, 2008.
LAURINDO, F.J.B.; ROTONDARO, R.G. Gesto Integrada de Processos e da

Tecnologia da Informao. So Paulo: Atlas S.Isso, 2006.
LAURINDO, Fernando Jos Barbin. Tecnologia da Informao Eficcia nas

Organizaes. So Paulo. Editora Futura, 2002.
LAURINDO, Fernando Jos Barbin. Um Estudo Sobre a Avaliao da Eficcia da

Tecnologia da Informao nas Organizaes. 2000. Tese (Doutorado) So Paulo,
2000. Departamento de Engenharia de Produo, Escola Politcnica, Universidade
de So Paulo.
LELLO, J; LELLO, E.; Dicionrio Prtico Ilustrado. Porto, Editora Lello &Irmo,
1968.
LOUZADA, Luiz Alberto de Campos. Contribuio ao Estudo do Processo de

desenvolvimento de Software: A Aplicao dos Mtodos de Engenharia de
Software em empresas que possuem desenvolvimento prprio. 2000.
Dissertao (Mestrado em engenharia de Produo) Universidade Paulista . 2000.
MAGGIOLINI, Piercarlo. Planejamento e Gesto da Tecnologia da Informao.

So Paulo, 1996. Escola Politcnica da USP. Apostila para Disciplina de Ps-
graduao do Departamento de Engenharia de Produo PRO5805
MARULA, M. ; PESSA, M. S. P. ; BENINI FILHO, P. Isso . Metodologia para a

Gesto do Conhecimento em Pequenas e Mdias Empresas. In: VIII SIMPEP
SIMPSIO DE ENGENHARIA DE PRODUO, 2001, Bauru/SP, 2001., 2001.
MARULA, Marcelo. Metodologia para a Gesto do Conhecimento em Pequenas

e Mdias Empresas, apoiada pela Tecnologia da Informao. 2001. 160 f.
Dissertao (Mestrado em Engenharia de Produo) Universidade Paulista, .
Orientador: Marcelo Schneck de Paula 200ndr200
MARTIN, J. Engenharia da Informao: introduo. Trad. Follow UP. Rio de

Janeiro: Campus, 1991.
MC FARLAN, W. Information Technology Changes the Way You Compete.

Harvard Business Review, v62, no 3 May/June, 1984.
MEDEIROS JR, Alberto de, PESSA, M. S. P., LAURINDO, F. J. B. Evolution

Stages in Web Applications In: Encyclopedia of E-Commerce, E-Government,
and Mobile Commerce ed.Hershey : Idea Group Reference, 2006, v.1, p. 1-7.
MEDEIROS JNIOR, Alberto de ; PESSA, M. S. P. ; LAURINDO, Fernando Jos

Barbin . The Web Involved in Nolans Stages. In: 16th International Conference
Information Resources Management Association IRMA, 2005, San Diego,
California. IRMA 16th 16th International Conference Information Resources
Management Association, 2005.
Medeiros Junior, Alberto de. Anlise de Novas Tecnologias de Comunicao de

Dados Utilizadas na Gesto da Cadeia de Suprimentos. 2002. 0 f. Dissertao
(Mestrado em Engenharia (Engenharia de Produo)) Universidade de So Paulo,
. Orientador: Marcelo Schneck de Paula Pessoa.
MICHAELIS Moderno Dicionrio Ingls Michaelis. Editora Melhoramentos.

Acesso em 01/05/2009 a http://michaelis.uol.com.br/moderno/ingles/index.php
MOREIRA, Paulo Marcelo Lessa. Contribuio ao Estudo de Produtividade em

Ambientes de Fbricas de Software. 129p. 2007. Dissertao (Mestrado
Profissional) Instituto de Pesquisas Tecnolgicas do Estado de So Paulo, So

Paulo, 2007.
MOURA, Luciano Raizer. Gesto Integrada da Informao: proposio de um

modelo de organizao baseado no uso da informao como recurso da
gesto empresarial. 117p. Dissertao de Mestrado. Escola Politcnica,
Universidade de So Paulo, So Paulo, 1999.
NOLAN, R.L. Managing the Crisis in Data Processing Harvard Business Review,
v.57, n2, Mar/Apr 1979.
NONAKA, I.; TAKEUSHI, H. Criao do Conhecimento na Empresa como as

empresas japonesas geram a dinmica da inovao. Rio de Janeiro, 1997,
Editora Campus 18 edio.
OKUMURA, Fbio Massashi. Avaliao de Modelos Matemticos de

Dimensionamento no Planejamento de Sistemas de Informao. 1988. Trabalho
de Formatura Departamento de Engenharia de Produo. EPUSP.
OLIVEIRA, K. R. ; PESSA, M. S. P. . Implementando a Linguagem UML como

uma Ferramenta de Definio de Processo do Workflow. In: VIII SIMPEP
Simpsio de engenharia de Produo, 2001, Bauru/SP, 2001, 2001.
OLIVEIRA, K. R.; PESSA, M.S.P. Implementao de Cenrios como

Ferramenta de Elicitao de Requisitos nos processos de Workflow. In: VIII
Simpsio de Engenharia de Produo SIMPEP, 2002 a , Bauru/SP, 2002 a.
Oliveira, Kleber Rocha de. Engenharia de Requisitos: Um Estudo da Aplicao

de Cenrios no Rastreamento e Mudanas de Requisitos. 2002. 0 f. Dissertao
(Mestrado em Engenharia de Produo) Universidade Paulista, 2002 .
PAULA FILHO, Wilson de Pdua. Engenharia de Software. Rio de Janeiro, LTC,

2003.
PAULK, M. et al. The Capability Maturity Model. USA, Addison-Wesley, 1995. (SEI
series in software engineering).
PESSA, M. S. P. ; FABRI, Jos Augusto ; LERARIO, Alexandre ; SPINOLA,

Mauro de Mesquita ; BEGOSSO, A . Desenvolvimento e Replicao de uma
Fbrica de Software. In: IV Jornada Iberoamericanas de Ingenieria del Software e
Ingenieria del Conocimiento, 2004b, Madrid. Actas de Las IV Jornadas
Iberoamericanas de Ingeniera del Software e Ingeniera del Conocimiento, 2004b.
V. 002.
PESSA, M. S. P.; FABRI, J. Isso; SPINOLA, M. M.; PRADO, T.F.; LERARIO, Isso.
Desenvolvimento distribudo de software para sistemas pervasivos: um estudo
de caso. In: I Simpsio Brasileiro de Sistemas de Informao (SBSI), 2004c. Anais-I
SBSI. Porto Alegre. P. 163 170.
PESSOA, M.S.P.; LAGUNA, F. ; MACEDO, G.C. Programa Formao do Analista

de Negcios So Paulo: Fundao Vanzolini, Expertise, 40p; jan 2009.
(apresentao de ementa de curso).
PESSOA, M.S.P; SPINOLA, M.M. Tipos de Produo So Paulo, EPUSP 2006.

material didtico da disicplina de graduao Automao e Controle PRO 2512.
PESSA, Marcelo Schneck de Paula, SPINOLA, Mauro de Mesquita Aprender a

aprender. Boletim Fundao Vanzolini. So Paulo, p.18 18, 1996.
PESSA, Marcelo Schneck de Paula. Fonte de Alimentao Chaveada para um

Minicomputador. Dissertao de Mestrado. So Paulo, 1979. Departamento de
Engenharia Eltrica, Escola Politcnica, Universidade de So Paulo.
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prtica. 2.ed.

Prentice Hall, So Paulo, 2004.
PMBoK Project Management Institute. A Guide to the Project Manager Body of

Knowledge (PMBOK Guide). Upper Darby, PA, 2000.
PMI Project Management Institute A Guide to the Project Management Body of

Knowledge. 2. ed. Newton Square. PMI Publications, 2004.
PORTELLA, E.; Bechara, E.C.; Costa, S.C. Vocabulrio Ortogrfico da Lngua

Portuguesa. Rio de Janeiro, Academia Brasileira de Letras, 4 a. edio, 2004.
Acesso em 01/05/2009 em http://www.academia.org.br
PORTER, M.E. Vantagem Competitiva: criando e sustentando um desempenho

superior. So Paulo, Campus, 1989.
POSTLEY, J.A. Letters to the Editor Communications of the ACM New York, USA.
Volume 3 Issue 1, January 1960.
PRANDO, Gerson. Bug do Milnio - uma viso de engenharia. Dissertao

(Mestrado em Engenharia de Produo) - Universidade de So Paulo, 1999 .
Orientador: Marcelo Schneck de Paula Pessa
PRESSMAN, Roger S. Engenharia de Software. So Paulo, McGraw Hill, 6 a

edio, 2006.
PRESSMAN, Roger S. Engenharia de Software. Traduo M.M.G. Travieso.

Reviso J.C.Maldonado, P.C. Masiero, F.S.R.Germano. 5ed. So Paulo, Makron,
2002.
PRESSMAN, Roger S. Software Engineering: a Practitioners Approach.

Singapore. McGraw Hill International. 3rd. Edition, 1987.
PRIBERAN Dicionrio Priberam da Lngua Portuguesa. Acesso em 01/05/2009 a

http://www.priberam.pt/dlpo/dlpo.aspx?pal=eliciar
PRO. Agrupamentos do Departamento de Engenharia de Produo EPUSP. 2009.

Disponvel em: http://www.pro.poli.usp.br/departamento/agrupamentos Acesso em
14 jan 2009.
RABECHINI JR, Roque ; LAURINDO, Fernando Jos Barbin ; PESSA, M. S. P. .

Web Technology as a Tool for Enabling Strategic Changes in a Decentralized
Manufacturing. In: IV SIMPOI/POMS-IV SIMPSIO DE ADMINISTRAO DA
PRODUO LOGSTICA E OPERAES INTERNACIONAIS- INTERNATIONAL
CONFERENCE OF THE PRODUCTION OPERATIONS MANAGEMENT SOCIETY,
2001, Brazil, Guaruj, 2001., 2001. p. 666-671
RABECHINI Jr, Roque ; PESSA, M. S. P. Um modelo estruturado de

competncias e maturidade em gesto de projetos. Produo (So Paulo), v. 15,
p. 34-43, 2005
RABECHINI Jr, Roque. Competncias e Maturidade em Gesto de Projetos:

uma perspectiva estruturada.So Paulo, Ed. Annablume, Fapesp, 2005.
RABECHINI Jr, Roque. Competncias e Maturidade em Gesto de Projetos: Uma

Perspectiva Estruturada. 2003. Tese (Doutorado em Engenharia (Engenharia de
Produo)) Universidade de So Paulo, . Orientador: Marcelo Schneck de Paula
Pessoa
REINEHR, Sheila dos Santos. Reuso Sistematizado de Software e Linhas de

Produto de Software mo Setor Financeiro: estudos de caso no Brasil. 2008.
Tese (Doutorado em Engenharia de Produo) Departamento de Engenharia de
Produo.
ROCKART, J.F.. Chief Executives Define Their Own Data Needs. Harvard
Business Review v.57, n2, Mar./Apr. 1979.
RODRIGUES SILVA, M.Isso , Marcos. Um Modelo de Produtividade e Qualidade

na Produo Fabril de Software para utilizao em Fbricas de Software por
Encomenda 2005. 157 p. Tese (doutorado) So Paulo, 2005. Departamento de
Engenharia de Produo, Escola Politcnica, Universidade de So Paulo.
RODRIGUES SILVA, Marcos Antonio ; COSTA, Ivanir ; PESSA, M. S. P. .

Qualidade, Como Fator Preponderante para o Desenvolvimento de Software. In:
ENEGEP 2001 XXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO,
2001, Salvador/BA, 2001., 2001.
SHLAER, S; MELLOR, Stephen J. Anlise de Sistemas Orientados para Objetos.

McGraw Hill: Newstec. 1990.
SHLAER, S; MELLOR, Stephen J. Object Lifecycles Modeling the World in

States. Yourdon Press Computing Series. Prentice Hall. New Jersey-USA. 1992.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo. Pearson Education do

Brasil. 6a edio, 2003.
SPINOLA, Mauro de Mesquita. Processos de Produo de Software: da

Definio Gerncia. Tese de Livre Docncia. So Paulo, 2008. Departamento de
Engenharia de Produo, Escola Politcnica, Universidade de So Paulo.
TAVARES, Edval da Silva. Uma Contribuio para o Processo da Gerncia de

Projetos atravs do Conhecimento. 2003. Tese (Doutorado em Engenharia de
Produo) Departamento de Engenharia de Produo.
TAVARES, S.R.S. Da Crise do Software ao Projeto Estruturado: a Submisso

Real do Trabalho em Programao. In: FLEURY, A..C; VARGAS, N. Organizao
do Trabalho, So Paulo, 1983.
THIOLENT, Michel. Pesquisa-Ao nas Organizaes. 1 edio So Paulo, Atlas,

1997.
TRINDADE, Andr Luiz Presende ; PESSA, M. S. P. ; SPINOLA, Mauro de

Mesquita . COCOMO II Uma Compilao de Informaes Sobre a Nova Mtrica.
In: V INTERNATIONAL CONGRESS ON INFORMATION ENGINEERING, 1999a,
Buenos Aires. Anales Proceedings V International Congress on Information
Engineering, Buenos Aires: ICIE99 (University of Buenos Aires)., 1999a. p. 24-38
TRINDADE, Andr Luiz Presende. Mtricas para Oramento e Planejamento da

Produo de Software. Dissertao de Mestrado. So Paulo, 1999. Departamento
de Engenharia de Produo, Escola Politcnica, Universidade de So Paulo.
TRINDADE, Andr Luiz Presende. Uma contribuio para o entendimento do

papel da ensinagem na preservao do conhecimento em ambientes de fbrica
de software. 2006. Tese (Doutorado em Engenharia de Produo) Departamento
de Engenharia de Produo.
WEINBERG, G.M. Software com Qualidade. Makron Books. So Paulo. 1994
YOURDON, Edward. Object-Oriented Systems Design An Integrated

Approach. Prentice Hall. New Jersey-USA. 1994.
APNDICE A QUESTIONRIO DA PESQUISA DE SILVA (2004)
INSTRUES
Este questionrio ser preenchido pelo entrevistador quando efetuar visitas nas fbricas de software.
Marque um X na coluna que mais se adequar situao analisada, sendo:
CF Concordo Fortemente
C Concordo
IN Indiferente
D Discordo
DF Discordo Fortemente
1 Equipe de Desenvolvimento
I As equipes produtivas so fixas, por CF C IN D DF
ambiente (ex: VB, Java, .C#). I 2 I 8 O
2 A organizao possui somente uma equipe CF C IN D DF
que trabalha com todos os ambientes. O 5 I 2 4
3 Todo servio do Cliente aceito, CF C IN D DF
independente se tem uma equipe para 4 4 I I 2
aquele ambiente ou no. Coloque a
soluo no verso (ou em outra folha).
4 As equipes so multidisciplinares, ou seja, CF C IN D DF
trabalham com vrios ambientes ao 1 9 1 O 1
mesmo tempo. Anotar vantagens/
.<;Iesvantagem, em relao a outro tipo de
equipe, no verso (ou em outra folha).
5 O gerenciamento pessoal da(s) equipe(s) CF C IN D DF
feito por um Gerente de Produo. 9 2 I O O
6 O gerenciamento de recursos da(s) CF C IN D DF
equipe(s) feito por Lideres de Produo. 5 4 O 2 I
7 Quando o servio do Cliente entra para a CF C IN D DF
produo ele imediatamente cadastrado, 7 4 I O O
para efeito de controle.
8 Quando o servio do Cliente encerrado CF C IN D DF
a equipe de produo que efetua a baixa no 3 4 1 I 3
controle.
9 A prpria Iistagem do cdigo CF C IN D DF
implementado ser a documentao feita 2 2 3 3 2
pela equipe de produo e entregue ao
Cliente.
10 Normalmente as equipes so interrompidas CF C IN D DF
em suas implementaes, para outros O 4 5 2 I
servios mais ur~entes ..
2 Gerenciamento do Backlo2 e do servio do Cliente
1I Existe uma Metodologia, para recebimento CF C IN D DF
do servio na produo, desmembramento 9 3 O O O
em ambiente, cadastramento no controle e
distribuio para a implementao.
12 A metodologia de desenvolvimento prev CF C IN D DF
um padrlJo de produo por tipo de 5 2 3 2 O
trabalho (conforme a linguagem) ? -
Folha 1 de 5 Questionrio sobre processo de Fbrica de Software
(Silva, 2004)
13 Existe um critrio de formao da fila de CF C lN D DF

espera (ex: primeiro que entra primeiro 2 4 O 5 I
que sai). Se for outro critrio, anote no
verso (ou em outra folha).
14 Existe um esquema automtico para a CF C IN D DF
transio da fila de espera para a O 1 2 8 1
implementao (serviodo Cliente). Anote
no verso (ou em outra folha).
15 Para o servio do Cliente feito um CF C IN D DF
planejamento. Qualquer outra situao, 9 O 2 1 O
anote no verso (ou em outra folha).
16 Quando surge um servio do Cliente com CF C IN D DF
maior prioridade, efetua-se um novo 5 5 I 1 O
planejamento, encaixando-isso
17 Diariamente efetuado um CF C IN D DF
posicionamento com a equipe de produo 6 2 I 3 O
para verificar eventuais discrepncias.
Qualquer outra situao. Anote no verso
(ou em outra folha).
18 Quando um prazo estimado superado, CF C IN D DF
registra-se o porqu e traa-se 6 5 1 O O
imediatamente um plano de emergncia
para recupera-to. Anotar o esquema no
19 Quando h uma superao do prazo CF C lN D DF
estimado, aproveita-se o registro do 4 6 2 O O
motivo e esquematiza-se uma melhoria
nos processos que levaram anomalia.
3 Desenvolvimento Recebimento do Servi o
f---
20 Existe um esquema de recebimento dos CF C -- IN D DF
tipos de servio (programas, classes, 6 4 2 O O
componentes, etc). Anotar o esquema no
21 Quem recebe o servio para CF C IN D DF
implementao o Lider de Produo. Se 3 5 O I 3
houver outra opo anotar no verso (ou em
outra folha).
22 A metodologia de desenvolvimento prev CF C IN D DF
um padro de produo por tipo de servio 4 3 2 3 O
ou tarefa (conforme a lin~ua~em).
23 A metodologia de desenvolvimento ai oca CF C IN D DF
as equipes por servio ou tarefa. 6 5 I O O
24 Um nmero de Ordem de Servio CF C IN D DF
identifica o mesmo na produo (ou as 7 3 2 O O
tarefas desmembradas do servio)
25 Se houver divergncia entre padres e/ou CF C IN D DF
prazo estimado de trmino e planejamento, 7 2 O 3 O
h um esquema para a devoluo do
servio para a renegociao com o Cliente.
Anotar no verso (ou em outra folha) como
feito.

(Silva, 2004)
4 Desenvolvimento Entrada na Produo

26 O servio do Cliente (ou as tarefas) CF C IN D DF
recebido na Produo pelo Lder de cada 4 3 2 1 2
ambiente e entregue aos recursos alocados.
Se houver outra forma, anotar no verso (ou
em outra folha).
27 O servio do Cliente desmembrado na CF C lN D DF
produo, por ambiente (ou linguagem) 4 4 I I 2
para efeito de implementao.
28 Existe uma biblioteca com cdigos CF C IN D DF
genricos para reuso (framework), 5 2 3 I I
facilitando a implementao.
29 O Lder de Produo executa o processo CF C IN D DF
de aproveitamento de cdigo. 4 2 I 2 3
30 O servio, quando entra efetivamente para CF C IN D DF
implementao, devidamente registrado 7 5 O O O
e a sua distribuio se faz segundo um
esquema de disponibilidade (por ambiente
ou lingua~em).
31 Para alocao dos recursos para o servio CF C IN D DF
efetuado um planejamento entre a 8 4 O O O
Produo e o recebimento (Lder,
Gerente ... ).
32 As equipes de produo trabalham por CF C IN D DF
ambiente (ou linguagem) e no pelo 4 I 4 2 I
servio todo do Cliente.
33 A fbrica utiliza uma Metodologia de CF C IN D DF
Desenvolvimento. Anotar no verso (ou em 8 4 O O O
6utra folha) qual a metodologia (prpria
ou outra).
34 Alinhados com a Metodologia de CF C IN D DF
Desenvolvimento, h processos de 8 O 1 2 I
lanamento e controle histrico de
produtividade e qualidade (ex: PSP).
35 Nesse momento so efetuados os CF C IN D DF
lanamentos iniciais de qualidade (ISSO, 7 2 O 3 O
CMM, PSP, etc.). Anotar no verso (ou em
outra folha) quais.
36 A Produo executa um processo de CF C IN D DF
framework (verificao da existncia de 5 4 I 2 O
cdigos reusveis, do prprio Cliente ou
da fbrica) e disponibiJiza-os para
incorporao na implementao ou nos
testes de integrao.
5 Desenvolvimento Implementao
37 Quando a Produo recebe o servio do CF C IN D DF
Cliente, procura dissolver em produtos 4 3 3 I I
menores (rotinas, classes, componentes,
etc.), facilitando a implementao e os
testes.
38 Quando a Produo recebe o servio do CF C IN D DF
Cliente, implementa-o de maneira nica, 4 6 1 O I
conforme a definio do Cliente, ou seja
um produto para cada definio.
39 Os desenvolvedores possuem mais de ~a CF C IN D DF
(Silva, 2004)
habilidade (ambiente ou linguagens). 9 3 O O O

40 Para alavancar a metodologia trabalha-se CF C IN D DF
com alguma ferramenta de produtividade 7 2 I 2 O
(gerador de cdigos, modelos, testes,
biblioteca, etc.). Anotar no verso (ou em
outra folha) quais ferramentas.
41 Alinhados com a Metodologia de CF C lN D DF
Desenvolvimento h processos de reviso 5 I 4 2 O
de cdigo. -
42 Um desenvolvedor pode parar o servio CF C IN D DF
que est implementando substituindo-o por 3 4 3 1 I
outro servio do Cliente, mais prioritrio.
43 Existe uma metodologia de testes alinhada CF C IN D DF
com a Metodologia de Desenvolvimento. 8 I 2 I O
44 O processo de planejamento de testes CF C IN D DF
integrado com o plan~jamento do 7 2 3 O O
desenvolvimento.
45 As estratgias de testes de unidade so CF C IN D DF
efetivamente cumpridas pelas equipes de 5 4 3 O O
Produo.
46 A massa de testes de unidade criada CF C IN D DF
antes da confeco do cdigo, pela equipe I 2 2 3 4
de Produo.
47 Os testes de unidade so executados pelas CF C IN D DF
equipes da Produo aps a confeco do 3 9 O O O
cdigo (do servio do Cliente).
48 O(s) produto(s) do desenvolvimento do CF C IN D DF
servio do Cliente e os testes so 4 3 2 3 O
armazenados para reaproveitamento em
outro servio posterior (framework). Se for
entregue ao Cliente, anotar no verso (ou
em outra folha).
49 Os testes tm sido realmente eficazes, CF C IN D DF
sendo executados a contento para a 3 2 2 4 I
organizao, no havendo necessidade de
estudo de arc-Ios antes do cdigo.
50 Os testes de integrao so feitos pelos CF C IN D DF
prprios desenvolvedores na medida em 3 5 1 3 O
que terminam os produtos e os mesmos
so disponibilizados para as integraes,
no havendo a necessidade do trmino de
todos os produtos.
51 Aps o trmino de cada servio (ou tarefa) CF C IN D DF
o prprio desenvolvedor efetua a liberao O 8 O 1 3
do mesmo (no controle) para a integrao.
Qualquer outra situao, anotar no verso
(ou em outra folha).
6 Desenvolvimento Encerramento
52 O pessoal da produo, que implementou CF C TN D DF
o servio (ou tarefa), participa da 6 4 O 2 O
homologao junto com o cliente.
53 Aps o ltimo servio (011 tarefa) ter CF C IN D DF
terminado a Produo efetua no controle a 4 7 O 1 O
(Silva, 2004)
liberao do servio do Cliente para

homologao.
54 Aps o ltimo servio (ou tarefa) ter CF C IN D DF
terminado a Produo efetua os 7 5 O O O
lanamentos de encerramento do
planejamento e a conseqente liberao
dos recursos alocados.
55 Aps o ltimo servio (ou tarefa) ter CF C IN D DF
terminado a Produo efetua os 5 4 I 2 O
lanamentos de qualidade e
produtividade ..
56 Aps o tmlino do servio (ou tarefas) CF C IN D DF
inicia-se um esquema de melhorias dos 3 I 4 I 3
processos produtivos.
57 Aps o trmino do servio (ou tarefas) CF C IN D DF
feita a divulgao dos problemas 3 3 3 2 I
encontrados e suas possfveis solues e/ou
resultados e/ou relatrio estatfstico e/ou
novas solues,.
7 Conhecimentos Gerais
58 H processos mtricos que avaliam e CF C IN D DF
controlam a produtividade e qualidade do 6 2 O 4 O
pessoal da Produo.
59 Aps a homologao do servio com o CF C IN D DF
Cliente (trmino), o mesmo pode retomar 3 4 3 2 O
fbrica para acertos. Esse nfvel de
retomo muito baixo.
60 H um processo constante de verificao CF C IN D DF
da satisfao do Cliente para com a 5 2 I 4 O
fbrica.
61 Durante os processos de implementao o CF C IN D DF
pessoal produtivo anota as sugestes de 3 4 4 I O
melhorias dos processos e as prope no
final do servio do Cliente.
62 Durante os processos produtivos os CF C IN D DF
desenvolvedores efetuam lanamentos de 4 5 I 2 O
dados do servio (inicio, horas
trabalhadas, trmino, etc.) que serviro de
base para os planejamentos futuros (PSP).
63 Um tempo aps terem sido feitas, so CF C IN D DF
analisadas as melhorias de processos 4 I 3 3 I
efetuadas pela fbrica, participando dessa
avaliao alguns desenvolvedores, os
lideres e a gerncia de produo.
64 Os desenvolvedores trabalham em pares, CF C IN D DF
em cada servio do Cliente. O O 5 2 5
(Silva, 2004)

0911 Marcelo Pessoa Tesede Livre Docencia

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

0911 Marcelo Pessoa Tesede Livre Docencia

Enviado por

Direitos autorais:

Formatos disponíveis

MARCELO SCHNECK DE PAULA PESSA

PROCESSOS E PROJETOS EM UMA FBRICA DE SOFTWARE

Anlise Crtica da Obra Acadmica

MARCELO SCHNECK DE PAULA PESSA

PROCESSOS E PROJETOS EM UMA FBRICA DE SOFTWARE

Anlise Crtica da Obra Acadmica

Pessoa, Marcelo Schneck de Paula

Tese (Livre-Docncia) - Escola Politcnica da Universidade

1.Fbrica de software 2.Tecnologia da informao 3.Enge -

I. Universidade de So Paulo. Escola Politcnica. Departamento

PAULA PESSA, Marcelo Schneck de.

Projetos e Processos de uma Fbrica de Software eLab-TI. (Tese de Livre Docncia)

Pgina Linha Onde se l Leia-se

Dedico este trabalho Mieko, minha

Os primeiros agradecimentos so aos colegas de GTI, professores Fernando Jos

Jos Francisco de Castilho Filho, meu primeiro orientado. Foi quem me

O grupo que ajudou a pensar a Fbrica de Software e participou das grandes

Ivanir Costa, Marcos Antonio Rodrigues Silva

O pessoal de Ourinhos e Assis: Andr Luiz Presende Trindade (orientado de

PauloMarques, que terminou o mestrado mas infelizmente parou por a.

Rodrigo Franco Gonalves, campeo na captao de bolsas

Kleber Oliveira, orientado de mestrado e que acabou de encerrar o doutorado,

Fbio Massashi Okumura que, em seu trabalho de formatura, me fez acreditar em

Ao Edval da Silva Tavares, Marcelo Marula e Andr Trindade (j citado) que me

Ao Toms Kameyama e Antonio Carlos Tonini fiis escudeiros do eLab-TI que

No poderia tambm deixar de agradecer Ivelise Moreira que sempre est

Enfim, os demais orientados que de alguma forma contriburam para as pesquisas

O eLab-TI um laboratrio de pesquisa, tambm conhecido como Fbrica de

Palavras-chave: software, processo de software, produo de software, definio

Keywords: software, software process, software production, software process

I.1 A QUESTO DA PESQUISA I5

II ENGENHARIA DE SOFTWARE II-7

II.1 ANLISE ESTRUTURADA II-8

III A CRIAO DO AMBIENTE DE PESQUISA III-18

III.1 A PRIMEIRA VISO DE FBRICA DE SOFTWARE III-18

IV ANLISE DE NEGCIO IV-30

IV.1 ANALISTA DE NEGCIOS IV-30

V ARQUITETURA DA SOLUO V-93

V.1 MTRICAS, ORAMENTO E PLANEJAMENTO V-93

VI IMPLEMENTAO DE SISTEMAS DE TI VI-105

VI.1 INSPEO DE RECEBIMENTO EM UMA FS VI-106

VII ANLISE CRTICA DA OBRA VII-183

VII.1 O GRUPO DE PESQUISA VII-183

APNDICE A QUESTIONRIO DA PESQUISA DE SILVA (2004) VII-206

FIGURA 1 REAS TEMTICAS DO PRO E LINHAS DE PESQUISA DO GTI .................................... I3

FIGURA 31-ENQUADRAMENTO DA PROGRAMAO ...................................................................... IV-63

FIGURA 66 EVOLUO DO USO SISTEMATIZADO DE SOFTWARE .......................................... VI-148

QUADRO 1 TIPOS BSICOS DE PRODUO (ADAPTADO DE PESSOA, SPINOLA, 2006) ............III-19

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associao Brasileira de Normas Tcnicas

As pesquisas desenvolvidas foram realizadas concentrando-se na rea de

Em 1998 o Departamento de Engenharia de Produo (PRO, 2009) elaborou um

EPEF - Economia da Produo e Engenharia Financeira

Pesquisa de aspectos ligados modelagem econmico-financeira de

relacionados s cadeias produtivas e s aglomeraes de empresas

GOL - Gesto de Operaes e Logstica

Linha de pesquisa com nfase em gesto fsica de sistemas de

GTI - Gesto da Tecnologia da Informao

Aborda a gesto da Tecnologia da Informao, envolvendo seu

QEP - Qualidade e Engenharia do Produto

Abrange a discusso de estratgias, polticas, planejamento,

TTO - Trabalho, Tecnologia e Organizao

Trata da organizao do trabalho em todas as instncias da atividade