Você está na página 1de 231

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 75 PROPOSIO P2 (REINEHR, 2008) ............................................................................ VI-158
FIGURA 76 PROPOSIO P3 (REINEHR, 2008) ............................................................................ VI-159
FIGURA 77 PROPOSIO P4 (REINEHR, 2008) ............................................................................ VI-159
FIGURA 78 PROPOSIO P5 (REINEHR, 2008) ............................................................................ VI-160
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
Processos e Projetos em uma Fbrica de Software eLab-TI I2

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.
Processos e Projetos em uma Fbrica de Software eLab-TI I3

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
Processos e Projetos em uma Fbrica de Software eLab-TI I4

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.
Processos e Projetos em uma Fbrica de Software eLab-TI I5

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.
Processos e Projetos em uma Fbrica de Software eLab-TI I6

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
Processos e Projetos em uma Fbrica de Software eLab-TI II-8

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.
Processos e Projetos em uma Fbrica de Software eLab-TI II-9

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,
Processos e Projetos em uma Fbrica de Software eLab-TI II-10

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)


Processos e Projetos em uma Fbrica de Software eLab-TI II-11

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
Processos e Projetos em uma Fbrica de Software eLab-TI II-12

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,
Processos e Projetos em uma Fbrica de Software eLab-TI II-13

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)
Processos e Projetos em uma Fbrica de Software eLab-TI II-14

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.
Processos e Projetos em uma Fbrica de Software eLab-TI II-15

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
Processos e Projetos em uma Fbrica de Software eLab-TI II-16

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!
Processos e Projetos em uma Fbrica de Software eLab-TI II-17

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).
Processos e Projetos em uma Fbrica de Software eLab-TI III-19

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
Processos e Projetos em uma Fbrica de Software eLab-TI III-20

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:
Processos e Projetos em uma Fbrica de Software eLab-TI III-21

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.


Processos e Projetos em uma Fbrica de Software eLab-TI III-22

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:


Processos e Projetos em uma Fbrica de Software eLab-TI III-23

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


Processos e Projetos em uma Fbrica de Software eLab-TI III-24

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
Processos e Projetos em uma Fbrica de Software eLab-TI III-25

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
Processos e Projetos em uma Fbrica de Software eLab-TI III-26

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.
Processos e Projetos em uma Fbrica de Software eLab-TI III-27

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


Processos e Projetos em uma Fbrica de Software eLab-TI III-28

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


Processos e Projetos em uma Fbrica de Software eLab-TI III-29

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-31

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).


Processos e Projetos em uma Fbrica de Software eLab-TI IV-32

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-33

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-34

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).


Processos e Projetos em uma Fbrica de Software eLab-TI IV-35

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-36

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).


Processos e Projetos em uma Fbrica de Software eLab-TI IV-37

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-38

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-39

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).
Processos e Projetos em uma Fbrica de Software eLab-TI IV-40

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-41

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-42

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-43

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-44

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-45

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-46

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)


Processos e Projetos em uma Fbrica de Software eLab-TI IV-47

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)
Processos e Projetos em uma Fbrica de Software eLab-TI IV-48

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-49

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):
Processos e Projetos em uma Fbrica de Software eLab-TI IV-50

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-51

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-52

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-
Processos e Projetos em uma Fbrica de Software eLab-TI IV-53

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-54

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-55

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.


Processos e Projetos em uma Fbrica de Software eLab-TI IV-56

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.).
Processos e Projetos em uma Fbrica de Software eLab-TI IV-57

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-58

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-59

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-60

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).
Processos e Projetos em uma Fbrica de Software eLab-TI IV-61

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


Processos e Projetos em uma Fbrica de Software eLab-TI IV-62

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.


Processos e Projetos em uma Fbrica de Software eLab-TI IV-63

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-64

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-65

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-66

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)
Processos e Projetos em uma Fbrica de Software eLab-TI IV-67

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).
Processos e Projetos em uma Fbrica de Software eLab-TI IV-68

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-69

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-70

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-71

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-72

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-73

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-74

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-75

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-76

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-77

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.


Processos e Projetos em uma Fbrica de Software eLab-TI IV-78

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-79

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-80

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):.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-81

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-82

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-83

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-84

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-85

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-86

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-87

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-88

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-89

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
Processos e Projetos em uma Fbrica de Software eLab-TI IV-90

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-91

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.
Processos e Projetos em uma Fbrica de Software eLab-TI IV-92

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
Processos e Projetos em uma Fbrica de Software eLab-TI V-94

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
Processos e Projetos em uma Fbrica de Software eLab-TI V-95

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.
Processos e Projetos em uma Fbrica de Software eLab-TI V-96

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.
Processos e Projetos em uma Fbrica de Software eLab-TI V-97

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).
Processos e Projetos em uma Fbrica de Software eLab-TI V-98

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;
Processos e Projetos em uma Fbrica de Software eLab-TI V-99

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.
Processos e Projetos em uma Fbrica de Software eLab-TI V-100

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).
Processos e Projetos em uma Fbrica de Software eLab-TI V-101

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
Processos e Projetos em uma Fbrica de Software eLab-TI V-102

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)


Processos e Projetos em uma Fbrica de Software eLab-TI V-103

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.


Processos e Projetos em uma Fbrica de Software eLab-TI V-104

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-106

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-107

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-108

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-109

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)


Processos e Projetos em uma Fbrica de Software eLab-TI VI-110

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-111

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-112

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-113

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-114

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-115

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-116

(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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-117

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-118

(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;


Processos e Projetos em uma Fbrica de Software eLab-TI VI-119

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:
Processos e Projetos em uma Fbrica de Software eLab-TI VI-120

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-121

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;
Processos e Projetos em uma Fbrica de Software eLab-TI VI-122

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-123

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-124

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-125

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-126

trabalho ser verificar essas reclamaes dos clientes e as possveis


melhorias no processo, necessrias para resolver as questes apontadas.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-127

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).


Processos e Projetos em uma Fbrica de Software eLab-TI VI-128

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-129

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-130

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-131

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;
Processos e Projetos em uma Fbrica de Software eLab-TI VI-132

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-133

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-134

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-135

Figura 54 Meta-processo proposto (Fabri, 2007)


Processos e Projetos em uma Fbrica de Software eLab-TI VI-136

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-137

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-138

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-139

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-140

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-141

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-142

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)
Processos e Projetos em uma Fbrica de Software eLab-TI VI-143

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)


Processos e Projetos em uma Fbrica de Software eLab-TI VI-144

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-145

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-146

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-147

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-148

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-149

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-150

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-151

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-152

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-153

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-154

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-155

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-156

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-157

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-158

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.

VI.7.7.2 Proposio P2

Figura 75 Proposio P2 (Reinehr, 2008)


Processos e Projetos em uma Fbrica de Software eLab-TI VI-159

Foi observado que existem prticas de uso no sistematizadas, mesmo nos bancos
onde h uma maior institucionalizao dessas prticas.

VI.7.7.3 Proposio P3

Figura 76 Proposio P3 (Reinehr, 2008)

Foi identificado que existem prticas de linhas de produto de software uma vez que
j podem ser identificadas algumas prticas de engenharia de domnio.

VI.7.7.4 Proposio P4

Figura 77 Proposio P4 (Reinehr, 2008)

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-160

VI.7.7.5 Proposio P5

Figura 78 Proposio P5 (Reinehr, 2008)

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-161

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-162

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-163

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-164

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-165

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-166

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-167

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-168

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-169

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-170

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-171

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 :


Processos e Projetos em uma Fbrica de Software eLab-TI VI-172

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-173

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-174

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-175

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VI-176

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)


Processos e Projetos em uma Fbrica de Software eLab-TI VI-177

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-178

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-179

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-180

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VI-181

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
Processos e Projetos em uma Fbrica de Software eLab-TI VI-182

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-184

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-185

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-186

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-187

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-188

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-189

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-190

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-191

O principal resultado de todo esse esforo o conhecimento adquirido e a certeza


de que, quanto mais se aprende, mais h a aprender.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-192

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-193

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-194

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-195

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-196

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-197

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-198

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-199

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-200

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-201

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).
Processos e Projetos em uma Fbrica de Software eLab-TI VII-202

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-203

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
Processos e Projetos em uma Fbrica de Software eLab-TI VII-204

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-205

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.
Processos e Projetos em uma Fbrica de Software eLab-TI VII-206

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)
Processos e Projetos em uma Fbrica de Software eLab-TI VII-207

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
verso (ou em outra folha).
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
verso (ou em outra folha).
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.

Folha 2 de 5 Questionrio sobre processo de Fbrica de Software


(Silva, 2004)
Processos e Projetos em uma Fbrica de Software eLab-TI VII-208

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
Folha 3 de 5 Questionrio sobre processo de Fbrica de Software
(Silva, 2004)
Processos e Projetos em uma Fbrica de Software eLab-TI VII-209

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
Folha 4 de 5 Questionrio sobre processo de Fbrica de Software
(Silva, 2004)
Processos e Projetos em uma Fbrica de Software eLab-TI VII-210

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
Folha 5 de 5 Questionrio sobre processo de Fbrica de Software
(Silva, 2004)