Академический Документы
Профессиональный Документы
Культура Документы
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
rea de Concentrao:
Engenharia de Produo
SO PAULO
2009
Processos e Projetos em uma Fbrica de Software eLab-TI IV
[Ficha catalogrfica]
ERRATA
DEDICATRIA
AGRADECIMENTOS
Aos meus orientados que, sem eles este trabalho no teria contedo. So muitos
mas importante lembrar de cada um.
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
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,
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.
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
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.
SUMRIO
I INTRODUO I1
REFERNCIAS VII-192
LISTA DE ILUSTRAES
LISTA DE QUADROS
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.
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.
rea de Concentrao:
Tecnologia da Informao
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
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).
II ENGENHARIA DE SOFTWARE
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).
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.
finalmente, foi fundada a OMG, que acabou consolidando a UML - Unified Modeling
Language - como uma representao universal para a orientao ao objetos.
Procedimentos e
B mtodos que definem a
relao entre as tarefas
A D
Ferramentas e
C equipamentos
PROCESSO
Pessoas habilitadas,
treinadas, motivadas
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
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.
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
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
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
III.2.3 Implementao
Figura 8 Implementao
Processos e Projetos em uma Fbrica de Software eLab-TI III-25
III.2.4 Repositrio
Figura 9 repositrio
III.2.5 Implantao
III.2.6 Disseminao
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
IV ANLISE DE NEGCIO
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
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
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.
A Informao Ambiental
Informao Interna
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).
Informao Corporativa
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).
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.
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
MTODOS
devidamente organizada e documentada.
So orientaes a respeito da seqncia de atividades a ser
PROCEDIMENTOS
seguida em um processo.
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.
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
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 quinto passo realiza a anlise da eficincia dos sistemas. Caso a eficincia seja
positiva segue-se para os passos 6 e 7 (eficincia adequada).
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
Dado
Informao
Conhecimento
Todas essas atividades acontecem na mente das pessoas e no contato entre elas,
podendo ocorrer com o auxlio de ferramentas de TI.
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.
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
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.
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
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.
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
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
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.
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
Stakeholders
Problema
Requisito
Processos e Projetos em uma Fbrica de Software eLab-TI IV-80
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
Ciclo Extrao-Anlise-Validao
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.
Extrao de requisitos 7
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
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
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
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
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
tenham previsto uma interface entre os sub-processos, no deixam claro como isto
se realiza.
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.
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
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
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.
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.
Pilar da Estratgia
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.
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
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.
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
Outro trabalho sobre Fbrica de Software foi desenvolvido por Jensen (2001)
Foi observado que, apesar de todas afirmarem possuir uma Fbrica de Software,
poucas aplicam esse conceito de forma efetiva.
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.
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:
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
Com relao atividade de reviso de cdigo, apenas uma organizao possui esse
processo (a mesma anterior).
(7) Encerramento
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.
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.
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
sequenciamento de pedidos.
BACKLOG
SCRUM
SPRINT
Equipe de desenvolvimento.
Gerenciamento do BackLog
Processo de desenvolvimento.
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.
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.
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.
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
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.
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.
Homogneo
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
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
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
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
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
O reuso caixa cinza significa que o ativo precisa ser modificado e isso
feito atravs de parmetros e no diretamente no cdigo.
A faceta por produto diz respeito a qual artefato objeto de reuso: cdigo
fonte, design, especificaes, objetos, testes ou arquiteturas.
Linha de Produtos
de Software
Componentes
Objetos
Mdulos
Sub-rotinas tempo (anos)
60 70 80 90 00 10
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.
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)
1: incompleto
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.
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.
VI.7.7.1 Proposio P1
VI.7.7.2 Proposio P2
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
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
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
VI.8 PRODUTIVIDADE EM FS
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.
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:
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.
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.
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.
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)
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.
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
ErrosEmbarcados PF = +28,5
-7,23 TaxaMudana
-22,8 TxEficcia Testes
-25,9 PercentValidao
Figura 83 Percepo da Equipe com relao aos fatores de Produtividade (Moreira, 2007)
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
Outros mtodos
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.
Preparao
Avaliao
Processos e Projetos em uma Fbrica de Software eLab-TI VI-178
Ps-avaliao
Fase 3: ps-avaliao
Mostrar resultados finais
Reunio de encerramento
Armazenar resultados da avaliao
Trueness
Accuracy Repetibilidade
Precision
Reprodutibilidade
Figura 89 Accuracy (Kohan, 2003)
1. Ocasies diferentes
2. Avaliadores diferentes
3. Instrumentos diferentes
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
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.
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.
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.
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.
Um levantamento para identificar o tipo de aluno que foi orientado por este Autor
ofereceu os resultados aqui descritos.
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.
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.
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.
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.
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.
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
REFERNCIAS
BAUER, W.; JUNCOSA, M. ; PERLIS, A.J. ACM Publication Policies and Plans.
Journal of the ACM 6; April, 1959.
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)
LELLO, J; LELLO, E.; Dicionrio Prtico Ilustrado. Porto, Editora Lello &Irmo,
1968.
NOLAN, R.L. Managing the Crisis in Data Processing Harvard Business Review,
v.57, n2, Mar/Apr 1979.
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, 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.
POSTLEY, J.A. Letters to the Editor Communications of the ACM New York, USA.
Volume 3 Issue 1, January 1960.
ROCKART, J.F.. Chief Executives Define Their Own Data Needs. Harvard
Business Review v.57, n2, Mar./Apr. 1979.
INSTRUES
Este questionrio ser preenchido pelo entrevistador quando efetuar visitas nas fbricas de software.
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