131

VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
Adequao de Processos para Fbricas de Software
Thayssa guila da Rocha
1
, Sandro Ronaldo Bezerra Oliveira
1, 2
,
Alexandre Marcos Lins de Vasconcelos
1
1
Centro de Informtica Universidade Federal de Pernambuco (UFPE)
Caixa Postal 7851, 50732-970, Recife PE Brasil
Fone/Fax: (+55 81) 2126-8430
2
Centro de Cincias Exatas e Tecnologia Universidade da Amaznia (UNAMA)
Av. Alcindo Cacela, 287, 66060-902, Belm PA Brasil
Fone: (+55 91) 210-3000, Fax: (+55 91) 225-3909
{tar, srbo, amlv}@cin.ufpe.br
Abstract. Each day the research concerning Software Factories has increased,
especially due to recent term growth in the world-wide scene. Indian Factories
had become quality and success reference, making that countries like Brazil
came to pursue a similar model and to search results so positive how much.
However, to reach this standard, it must be clear that factors as processes,
quality standards and manufacture solutions frameworks intervene directly
with the final result. From this point of view, this paper presents a mapping of
the software development process into the different boarding of Software
Factories.
Resumo. A cada dia as pesquisas acerca de Fbricas de Software vm se
intensificando, especialmente devido ao crescimento desta atividade no
cenrio mundial. Fbricas da ndia se tornaram referncia de qualidade e
sucesso, fazendo com que pases como o Brasil viessem a perseguir um
modelo semelhante e buscar resultados to positivos quanto. Porm, para
atingir este padro, devemos estar cientes que fatores como processos,
padres de qualidade e frameworks de solues fabris interferem diretamente
no resultado final. Neste contexto, este artigo apresenta um mapeamento dos
tipos de processo de desenvolvimento s diferentes abordagens de Fbricas de
Software.
1. Introduo
A exemplo do crescimento e amadurecimento das fbricas de software da ndia
[Kripalani 2003], as iniciativas brasileiras tm se multiplicado e apresentado um
crescimento considervel nos ltimos meses [Cesar 2004], especialmente devido a
fatores competitivos, uma vez que o prprio mercado nacional tem se tornado mais
exigente em termos de qualidade do produto e de reduo de custos [Tartarelli 2004].
Desta forma, as iniciativas de organizao do modelo fabril, moldado a partir de
preceitos como o taylorismo e o fordismo, vindos desde o sculo XIX, tm tentado
mapear conceitos de produo em larga escala com qualidade para o mercado de
software, aumentando a produtividade e reduzindo os custos de produo, de forma
132
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
semelhante proposta de Taylor e Ford, no surgimento das fbricas tradicionais
[Tartarelli 2004].
No entanto, o caso especfico de uma fbrica de software requer uma
organizao mais holstica, que leve em considerao vrios fatores como gesto de
pessoas, gesto empresarial, qualidade de software, de processos e de produtos,
utilizao de ferramentas, etc. Dentro deste contexto, este artigo ir focar no fator
processo de desenvolvimento, fornecendo um mapeamento dos tipos de processo -
quanto sua execuo - s diferentes abordagens de Fbricas de Software.
Como referncia para as abordagens, ou classificaes, de Fbrica de Software
ser utilizada a perspectiva de escopo de fornecimento, utilizada por Fernandes (2004).
A importncia da escolha dos processos que melhor se adequem a uma iniciativa
de Fbrica de Software baseada no aumento de destaque que a definio e
padronizao de processos vem sofrendo, especialmente aps a iniciativa do Software
Engineering Institute da Universidade de Carnegie Mellon, quando da criao do CMM
[Paulk 1993] Capability Maturity Model for Software, que define nveis de capacidade
para uma organizao que tem a produo de software como objetivo primeiro.
Segundo Zahran apud Fernandes (2004), o processo funciona como o elo de
ligao entre os outros elementos desta viso holstica que norteia as Fbricas de
Software, e deve interligar a Organizao, o Gerenciamento, as Habilidades e a
Tecnologia utilizada, pois embasa a criao dos papis organizacionais e definio das
responsabilidades, atividades e documentos (artefatos de insumo e produto), assim
como as diretrizes para as prticas gerenciais e para a seleo da tecnologia que ser
utilizada durante a produo, ou seja, dependendo do objetivo da fbrica, a escolha do
processo mais adequado de suma importncia para o sucesso da organizao.
Para obter os resultados esperados, o artigo ser estruturado da seguinte forma:
na seo 2, o conceito de Fbrica de Software ser definido e classificado. Na seo 3,
os processos de desenvolvimento sero tambm conceituados, classificados quanto
execuo e ser detalhado como estes podem ser implementados e definidos em uma
organizao, fornecendo embasamento para a seo 4, onde a adequao destes
processos ser mapeada para os diferentes tipos de fbricas identificados anteriormente,
assim como um breve guia de implementao apresentado. A seo 5 finalmente
apresenta a concluso do artigo, identificando os trabalhos futuros acerca do tema.
2. Fbricas de Software
Segundo Bemer apud Cusumano (1989), o termo Fbrica de Software vem sendo
discutido desde o final dos anos 60, e evoluindo e se refinando at os dias atuais.
Segundo Cusumano (1989) um processo fabril constitui-se na produo de
produtos em massa, incluindo operaes centralizadas de larga escala, tarefas simples e
padronizadas, controles padronizados, trabalhadores especializados, mas com poucas
habilidades, diviso de trabalho, mecanizao e automao do processo. Desta forma, a
associao do termo fbrica ao desenvolvimento de software sugere que se apliquem
tcnicas para produo em larga escala, de forma coordenada e com qualidade.
Desde 1968 alguns estudos publicados associam ainda caractersticas como
reusabilidade, utilizao de ferramentas para suportar o desenvolvimento, sistemas de
133
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
controle e gerenciamento, modularizao e produo de famlias de produtos como
bsicas para uma organizao que se intitula uma Fbrica de Software.
Mais recentemente, Greenfield (2003) nos apresenta uma viso semelhante, onde
o conceito de Fbrica de Software est fundamentado no desenvolvimento baseado em
componentes, direcionado a modelos e a linhas de produto de software que
caracterizariam uma iniciativa de fbrica, visando tornar a montagem de aplicaes mais
barata atravs de reuso sistemtico, possibilitando a formao de cadeias de produo.
J Fernandes (2004) apresenta fbricas de software como Um processo
estruturado, controlado e melhorado de forma contnua, considerando abordagens de
engenharia industrial, orientado para o atendimento a mltiplas demandas de natureza
e escopo distintas, visando gerao de produtos de software, conforme os
requerimentos documentados dos usurios e/ou clientes, da forma mais produtiva e
econmica possvel.
Este conceito baseia-se em alguns atributos bsicos que o autor advoga como
imprescindveis em qualquer Fbrica de Software, seja qual for a sua categorizao.
Alguns destes atributos so: processo definido e padro (desenvolvimento, controle e
planejamento); interao controlada com o cliente (entradas e sadas da fbrica);
solicitaes de servio fbrica devem ser padronizadas; estimativas de custos e prazos
baseadas no conhecimento real da capacidade produtiva com mtodos de obteno
baseados em dados histricos; controle rigoroso dos recursos envolvidos em cada
demanda da fbrica; controle e armazenamento em bibliotecas de itens de software
(documentos, cdigo, mtodos, etc); controle dos status e execuo de todas as
demandas; produtos gerados de acordo com os padres estabelecidos pela organizao;
equipe treinada e capacitada nos processos organizacionais e produtivos; controle da
qualidade do produto; processos de atendimento ao cliente; mtricas definidas e controle
dos acordos de nvel de servio definidos com o cliente.
Uma vez definido o conceito de Fbricas de Software e citadas algumas de suas
caractersticas, as mesmas sero classificadas a fim de que possa ser caracterizado o
mapeamento dos processos.
A classificao adotada ser a de Fernandes (2004), onde, segundo a Figura 1,
so apresentados os quatro tipos de fbricas classificadas de acordo com o seu escopo de
atuao ao longo das fases de desenvolvimento de um projeto de Software.
Figura 1. Classificao de Fbricas de software de acordo com seu escopo de
fornecimento [Fernandes 2004]
134
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
O autor tambm cogita a existncia de uma fbrica de testes, que englobaria
apenas a fase de teste integrado. Porm, para o objetivo desde artigo, a fbrica de testes
se enquadraria na mesma classificao da fbrica de programas que ser definida a
seguir, apesar de geraram um produto final distinto.
A fbrica de programas consiste na menor unidade de fbrica,
conseqentemente a menos complexa. Tem por objetivo principal codificar e testar
programas de computador. No seu processo produtivo engloba praticamente as fases de
construo e testes unitrios.
A fbrica de projetos atua com um pouco mais de abrangncia no processo de
produo, englobando alm das atividades inerentes fbrica de programas, fases como
projeto conceitual, especificao lgica, projeto detalhado da soluo, realizao de
testes de integrao e de aceitao. Dependendo da interface com o cliente, a fbrica
pode se caracterizar por projetos de software ou projetos fsicos, porm, seus
requisitos e caractersticas bsicas so muito semelhantes. No caso das fbricas de
projetos de software, h a necessidade do conhecimento do negcio do cliente. A
fbrica de projetos ampliada no ser tratada neste mapeamento pois engloba
solues mais abrangentes de Tecnologia da Informao fugindo ao escopo do artigo,
podendo ser representada no nvel da fbrica de projetos de software.
Mesmo no estando includa na Figura 1, o modelo de outsourcing de sistemas
citado como uma especializao da fbrica de projetos, onde a mesma dedicada
exclusivamente a um determinado cliente, diferenciando apenas na interface da fbrica
com o cliente, que deve ser adaptada aos critrios e regras estabelecidas previamente
entre ambos, normalmente atravs de um SLA Service Level Agreement que
descreve estes critrios, restries e procedimentos de mudana no escopo e na
avaliao do servio [Assano, 2002]. O modelo de outsourcing apresentado pelo autor
bem mais complexo e envolve outros processos auxiliares, que tornam-se essenciais
para esta modalidade.
Merece destaque ainda a fbrica de componentes, porm, segundo Basili
(1994) os processos de desenvolvimento atuais no suportam diretamente a utilizao de
componentes, uma vez que definem apenas as fases de desenvolvimento do projeto, que
utilizam os componentes j catalogados. Desta forma, o mapeamento no se estender a
esta classe de Fbricas de Software. Entretanto, os processos devem ser escolhidos de
forma a utilizarem e tirarem as vantagens inerentes da reutilizao de artefatos durante
todo o ciclo de vida.
3. Processos de Desenvolvimento
Informalmente, o processo de software pode ser compreendido como o conjunto de
todas as atividades necessrias para transformar os requisitos do usurio em software
[Humphrey 1989]. Um processo de software formado por um conjunto de passos de
processo parcialmente ordenados, relacionados com conjuntos de artefatos, pessoas,
recursos, estruturas organizacionais e restries e tem como objetivo produzir e manter
os produtos de software finais requeridos [Lonchamp 1993].
Os passos de processos so atividades. Uma atividade um passo de processo
que produz mudanas de estado visveis externamente no produto de software. As
135
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
atividades esto associadas a papis, ferramentas e artefatos; incorporam e implementam
procedimentos, regras e polticas; e tm como objetivo gerar ou modificar um dado
conjunto de artefatos.
Uma atividade aloca recursos (por exemplo, mquinas e oramento) e
escalonada, monitorada e atribuda a desenvolvedores (agentes), que podem utilizar
ferramentas para execut-las. Um agente est relacionado com as atividades de um
processo e pode ser uma pessoa ou uma ferramenta automatizada. Diferentes agentes
tero percepes diferentes acerca do que acontece durante o processo de software. Por
sua vez, artefato um produto criado ou modificado durante um processo. Tal produto
resultado de uma atividade e pode ser utilizado posteriormente como matria-prima
para a mesma ou para outra atividade a fim de gerar novos produtos.
A descrio abstrata do processo de software caracteriza um modelo de
processo de software. Vrios tipos de informao devem ser integrados em um modelo
de processo para indicar quem, quando, onde, como e por que os passos so realizados.
Segundo [Conradi 1994], projeto a instncia de um processo, com objetivos e
restries especficos. Pode-se dizer que um projeto um esforo para desenvolver um
produto de software, ou seja, envolve uma estrutura organizacional, prazos, oramentos,
recursos e um processo de desenvolvimento.
3.1. Tipos de Processos de Software quanto execuo
Na literatura especializada pode-se encontrar duas frentes de processo de software no
tocante execuo. A primeira, definida como um processo tradicional, ou tambm
chamada de processo pesado, que caracteriza-se por possuir como foco principal a
previsibilidade dos requisitos do sistema e o comando e o controle destes a partir de um
prvio planejamento antes do incio do desenvolvimento, transformando estas aes em
um processo rigoroso [Pressman 2000]. Rigoroso pois a especificao de requisitos
torna-se a etapa fundamental, onde todas as necessidades do cliente so definidas e
documentadas, sendo que para cada um destes requisitos, so gerados outros
documentos, tornando o processo de anlise e projeto bastante demorado e de difcil
manuteno caso alguma especificao seja alterada. Pode-se, ainda, caracterizar que
este tipo de processo possui uma abordagem voltada para o planejamento detalhado,
fases seqenciais de processo e artefatos de uma fase para a seguinte. Como exemplo
deste tipo de processo tem-se o RUP [Krutchen 2003], o OPEN [Sellers 1997] e o
Catalysis [DSouza 1999].
J a outra frente, chamada de processo gil ou processo leve, possui seu foco na
eficincia, abordando como premissa o compromisso entre nada de processo e
processos rigorosos [Beck 2000]. Esta frente prope que a anlise de requisitos seja
extremamente mutvel, abraando mudanas como principal rea de atuao da
metodologia. Sendo assim, os planejamentos so constantes, no havendo uma etapa
exclusiva para isso, ficando o foco principal com a codificao. Para isso os meios para
estes fins so: adaptabilidade; cada item de processo deve agregar valor; orientao a
pessoas; comunicao; e aprendizado. Para exemplificar esta outra linha de processos
temos o XP [Jefrries 2001], o Crystal [Cockburn 2002] e o SCRUM [Bach 1995].
Desta forma, podemos listar como principais pontos fracos destes tipos de
processo, os listados a seguir:
136
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
Processo Tradicional: a burocracia, uma vez que agrega mais tarefas para as
suas aes; e a no adaptabilidade, onde a realidade (prazo, escopo, processo,
pessoas) difere do planejado / documentado;
Processo gil: a escalabilidade para equipes grandes / dispersas; e a mudana
de cultura de paradigma.
J como pontos fortes, temos:
Processos Tradicionais: baseado em wokflows de processo; orientado a
planejamentos; garantia alta de desenvolvimento; equipes e produtos grandes;
projetado para suportar requisitos correntes e desconhecidos; modelo de
desenvolvimento de software completo incluindo suporte a ferramentas;
atribuies centradas no objetivo das atividades; possibilita ser instanciado e
customizado de acordo com o domnio da aplicao ou da organizao.
Processo gil: revisa-se o cdigo todo o tempo; toda a equipe ir testar o
software inclusive o cliente; toda a equipe torna a atividade de projeto diria;
a arquitetura ser definida e refinada todo o tempo; possui interaes curtas
caracterizadas por minutos e horas; modularidade no nvel de
desenvolvimento do processo; orientado a pessoas.
4. Adequando Processos a Fbricas de Software
A fim de obter um ganho maior de produtividade e facilitar o atendimento dos objetivos
que a fbrica se prope, importante saber escolher o processo de desenvolvimento que
melhor se adeque.
Os objetivos da fbrica podem ser definidos de acordo com vrios fatores,
dependendo do tipo de fbrica. Neste trabalho, estamos classificando as Fbricas de
Software em: fbricas de cdigo, de projetos, de componentes e outsourcing de
sistemas. J os processos de desenvolvimento foram classificados em: geis e
tradicionais. Desta forma, o mapeamento destas classes de processos aos tipos de fbrica
se torna mais simples e baseado no objetivo final da fbrica.
importante salientar que no caso da fbrica em questo possuir meta de adoo
de algum modelo de qualidade, maiores cuidados devem ser tomados acerca da escolha
do processo, e no apenas as caractersticas que estamos levando em considerao, pois
pode ser necessria a formalizao de alguns processos de suporte que podem no ser
definidos, ou ser parcialmente, pelo processo de desenvolvimento adotado, ainda que
este seja um processo classificado como tradicional.
Modelos de qualidade como CMM [Paulk 1993], CMMI [Chrissis 2003] e
SPICE [SPICE 2004] so mais abrangentes que os processos de desenvolvimento mais
conhecidos e usados pelo mercado, pois se estendem a reas como controle de qualidade
e atendimento aos fornecedores, que no fazem parte do processo de produo da
soluo diretamente. Desta forma, mesmo que o processo de desenvolvimento fosse
escolhido corretamente, este no seria suficiente para o sucesso total da fbrica. A
incluso das caractersticas dos modelos de qualidade est prevista como um trabalho
futuro, conforme descrito na seo 5 deste artigo.
137
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
A tabela a seguir (ver Tabela 1) ilustra o mapeamento proposto, que ser descrito
em seguida.
Tabela 1 - Mapeamento de Processos para Fbricas de Software
Para a fbrica de cdigo, que requer maior agilidade e pouco formalismo na
documentao do produto final, os mtodos geis poderiam ser bem utilizados, desde
que respeitando os requisitos mnimos de documentao e gerncia exigidos para uma
fbrica de software institucionalizada. A velocidade e o dinamismo deste tipo de
processo pode dar o ritmo necessrio para o sucesso da operao, entretanto, deve-se
manter em pequenas equipes cujos membros estejam reunidos em um mesmo ambiente
fsico.
A fbrica de componente tambm pode se adaptar ao pouco formalismo dos
mtodos geis, optando por documentar os componentes apenas atravs ferramentas
como JavaDoc [JavaDoc 2004]. Da mesma forma que na fbrica de cdigo, o
dinamismo dos mtodos geis tambm podem ser o diferencial da fbrica, porm, algum
formalismo ou processo auxiliar deve ser definido para a catalogao e distribuio dos
componentes gerados. As restries de pequenas equipes cujos membros estejam
reunidos em um mesmo ambiente fsico tambm devem ser observadas.
Na fbrica de projeto, que se assemelha maioria das fbricas que
desenvolvem aplicaes personalizadas, a necessidade dos mtodos tradicionais ou
aparece em maior destaque, uma vez que se faz necessrio documentar e no raramente,
validar formalmente com o cliente as decises de requisitos e/ou projeto. Estes produtos
tambm possuem um ciclo de vida maior, o que torna comum durante o
desenvolvimento de um determinado projeto a entrada e sada de pessoal, o que
dificultaria a utilizao de um processo orientado a pessoas como os processos geis.
Por fim, o outsourcing de sistemas, que requer alm de maior formalismo,
maior controle por parte do cliente dos ndices gerados pela fbrica a fim de
acompanhar o SLA prtica comum nesta situao, claramente orientado a processos
tradicionais. bastante comum, e muitas vezes requerido pelo prprio cliente, a
certificao da fbrica em um modelo de qualidade reconhecido mundialmente, o que
refora a necessidade da utilizao de processos bem definidos e acima de tudo da
138
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
coleta e acompanhamento de mtricas de produo. Apesar do posicionamento adotado
neste artigo, importante citar a referncia de uma experincia relatada por Fowler
(2004) em uma iniciativa de implantao um processo gil em um outsourcing de
sistemas utilizando processos geis.
4.1. Implementao de um Processo de Software
Mudar ou implantar um processo de desenvolvimento em uma fbrica de software pode
ser uma tarefa difcil de se realizar e, muitas vezes leva-se tempo para ver seus
resultados. Segundo Balduino [Balduino 2002], diferente de se adotar uma nova
ferramenta de desenvolvimento, j que basta instal-la, ler o manual do usurio, seguir
as instrues de um tutorial e talvez fazer um curso sobre ela. Pode-se levar algumas
horas ou dias para fazer isso. Porm, mudar o processo de desenvolvimento de software
de uma empresa afeta a maneira como os indivduos trabalham, como eles vem, e do
valor ao resultado de seu esforo.
Portanto, essa mudana no acontece da noite para o dia, por isso ela deve ser
cuidadosamente planejada e gerenciada. Uma abordagem de adoo gradual do processo
de desenvolvimento e ferramentas de apoio, onde cada passo seja planejado, executado
e avaliado com critrio, d a sensao de se est se fazendo a implementao da maneira
mais adequada.
Falando sob o aspecto da engenharia de processo, implementar um novo
processo em uma empresa de desenvolvimento de software um projeto por si s e que,
por sua vez, pode ser descrito em quatro passos distintos, conforme a Figura 2.
Figura 2. Passos para implementar processo em uma empresa [Balduino 2002]
Os passos definidos na Figura 2 so descritos a seguir:
Avaliar a empresa de desenvolvimento: o intuito coletar informaes das
pessoas-chave internas ou externas empresa para obter uma lista abrangente
dos problemas atualmente encontrados, entender como essas pessoas vem os
problemas e os priorizam;
Planejar a implementao: nesta fase passamos a planejar a forma como ela
vai se mover do seu estado atual para onde se quer chegar. Para isto faz-se
necessrio uma anlise dos objetivos a serem alcanados; identificar, analisar
e priorizar os riscos inerentes implantao do processo; usar um projeto
139
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
piloto para avaliao inicial; estabelecer um plano de treinamento; alocar
mentores como disseminadores do conhecimento;
Executar a implementao: esta fase significa executar os projetos de
software escolhidos para dotar o processo e as ferramentas. Do ponto de vista
organizacional, isso significa: monitorar os projetos de desenvolvimento de
software; gerenciar a adoo de processo nos projetos; monitorar a criao e
uso de um ambiente de desenvolvimento organizacional;
Avaliar o esforo da implementao: aps o processo ter sido
implementado no projeto piloto ou nos demais projetos, precisa-se validar os
resultados contra o plano proposto no passo Planejar a implementao.
Em uma organizao, diferentes processos podem coexistir, adequados a
diferentes projetos. Para organizar e disciplinar o desenvolvimento de software
importante determinar as atividades fundamentais que devero estar presentes em
qualquer processo definido. A definio de um processo padro estabelece uma
estrutura comum a ser utilizada pela organizao nos seus projetos de software e
constitui a base para a definio de todos os processos [Rocha 2001]. Dessa forma,
estabelece-se um processo bsico que servir como ponto de partida para a posterior
definio dos processos de software adequados s diferentes caractersticas de cada
projeto, permitindo economia de tempo e esforo na definio de novos processos.
A definio do processo padro pode ser realizada tendo como base alguma
norma de qualidade de processo de software e as caractersticas do desenvolvimento de
software na organizao. A definio poder considerar um dos modelos de maturidade
atualmente utilizados.
Tendo em vista que tipos de software diferentes possuem caractersticas distintas
e requerem diferentes abordagens de desenvolvimento, o processo de software padro
da organizao dever ser adaptado (especializado) considerando-se as caractersticas
relacionadas ao tipo de software (por exemplo, sistemas de informao) e ao paradigma
de desenvolvimento utilizado (por exemplo, orientao a objetos).
A instanciao para projetos especficos consiste na adaptao de um processo
especializado a um projeto, considerando-se as suas peculiaridades. Nesta etapa, so
definidos o modelo de ciclo de vida, os mtodos e as ferramentas que sero utilizadas no
projeto, os recursos humanos e seus responsabilidades ao longo do processo e os
artefatos (produtos) consumidos e gerados.
5. Consideraes Finais
O conceito de Fbrica de Software est baseado na idia de prover uma linha de
produo de solues que atendam s necessidades especficas de cada cliente. Isto se
d atravs da formalizao de todas as atividades e seus produtos, trabalhando em forma
de linha de produo, com etapas e tarefas bem definidas para cada tipo de profissional,
indo das tarefas bsicas da linha de produo at rotinas de controle de qualidade [Brito
2004].
Assim, com a alta especializao dos profissionais, cada um garante a
produtividade da etapa de produo em que est engajado e a qualidade do artefato
produzido para a etapa seguinte.
140
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
Para o perfeito funcionamento das atividades de uma Fbrica de Software
fundamental a adoo de um processo de desenvolvimento que defina as tarefas,
produtos e responsveis pelas etapas do ciclo de vida do software.
Assim, este trabalho apresentou sugestes de um possvel mapeamento de tipos
de processo de desenvolvimento de software, quanto sua execuo, de acordo com os
tipos de Fbrica de Software, classificadas por [Fernandes 2004].
Como vises de trabalhos futuros pretende-se aprofundar este estudo em uma
pesquisa que dar origem a uma monografia, acrescentando-se mais uma dimenso ao
mapeamento: os modelos de qualidade e suas caractersticas, focando nos modelos mais
utilizados no mercado mundial e comparando realidade brasileira, experimentando tais
modelos e suas variaes tambm no ambiente acadmico.
Este trabalho servir como base para uma dissertao do programa de Mestrado
do CIN/UFPE (Centro de Informtica da Universidade Federal de Pernambuco), que
tem como objetivo propor um modelo de fbrica de software que seja escalvel, de
acordo com a classificao da fbrica que o estar instanciando, e que garanta, em
termos de organograma e atividades bsicas, a execuo de todas as exigncias mnimas
para adequao ao modelo de qualidade escolhido, orientando tambm na definio do
tipo de processo de desenvolvimento a ser adotado.
Referncias
Bach, J. (1995) SCRUM Software Development Process - Building The Best Possible
Software, ADVANCED DEVELOPMENT METHODS.
Balduino, R. (2002) Implementao de um processo de desenvolvimento de software:
uma abordagem passo-a-passo, Rational Software White Paper.
Basili, V.R., (1994) Facts and Myths affecting Software Reuse, IEEE, Maryland.
Beck, K., (2000) Extreme Programming Explained, Addison-Wesley.
Brito, J. A. J. (2004) Metodologia para Gesto do Processo de Qualidade de Software
para Incremento da Competitividade da Mobile, http://www.mct.gov.br/
Temas/info/Dsi/PBQP/Reuniao%20Petropolis/Apresentacao%20Mobile.pdf.
Cesar, R. (2004). Fbrica de Software: Uma vocao nacional?,
http://www.siscorp.com.br/imprensa/computerworld02.htm?documento=24655&Are
a=51, Agosto.
Cockburn, A. (2002) Crystal Clear A human-powered methodology for small teams
including the seven properties of effective software projects, Humans and
Technology.
Conradi, R. et. Al (1994) EPOS: Object-Oriented Cooperative Process Modelling, In:
FINKELSTEIN, Software Process Modelling and Technology, Kauton Research
Studies Press.
Chrissis, Mary Beth; Konrad, Mike; Shrum, Sandy. (2003). CMMI Guidelines for
Process Integration and Product Improvement. Boston.
Cusumano, M. A. (1989) The software factory: a historical interpretation. IEEE
Software, 6(2), p.23-30, Cap. 14.
141
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br
Dsouza, D., Wills, A. (1999) Objects, Components and Frameworks with UML The
Catalysis Approach, Addison-Wesley Publishing Company.
Fernandes, A.A., Teixeira, D. S. (2004). Fbrica de Software: Implantao e gesto de
Operaes, Atlas, So Paulo.
Fowler, M. (2004) Using a Agile Software Process with Offshore Development,
http://www.martinfowler.com/articles/agileOffshore.html, Abril.
Humphrey, W. S. (1989) Managing the Software Process, New York: Addison-
Wesley.
JavaDoc Tool (2004) , http://java.sun.com/j2se/javadoc/, Agosto.
Jefrries, R. (2001) What is Extreme Programming?,
http://www.xprogramming.com/xpmag/whatis.htm, Junho.
Kripalani, M., Engardio P., Hamm, S. (2003) . The Rise of India, http://www.
businessweek.com/magazine/content/03_49/b3861001_mz001.htm, BusinessWeek
Online, Dezembro.
Kruchten, P. (2003) Introduo ao RUP Rational Unified Process, Rio de Janeiro:
Editora Cincia Moderna Ltda.
Lonchamp, J. (1993) A Structured Conceptual and Terminological Framework for the
Software Process Engineering, In: INTERNATIONAL CONFERENCE ON THE
SOFTWARE PROCESS, Berlin, Proceedings.
Paullk, M. C., Curtis, B., Chrissis, M. B., Weber, C. V. (1993) Capability Maturity
Model for Software, Version 1.1, Technical Report CMU/SEI-93-TR-024. Software
Engineering Institute - Carnegie Mellon University.
Pressman, R. S. (2000) Software Engineering: A Practioners Approach, 5th edition.
MacGraw-Hill International Edition.
Rocha, A. R. C., Maldonado, J. C., Weber, K. C. (2001) Qualidade de Software: Teoria
e Prtica, So Paulo: Prentice Hall.
Sellers, B. H. et. Al (1997) The OPEN Process (Tasks, Techniques and Management),
Chapter of Handbook of Object Technology, Centre for Object Technology
Applications and Research School of Information Technology Swinburne
University of Technology, CRC Press.
SPICE- Software Process Improvement and Capability dEtermination (2004),
http://www.sqi.gu.edu.au/spice/, Agosto.
Tartarelli, R.V., Winckler, W. S. (2004) Aprendizagem organizacional em fbricas de
software, http://www.pmirs.org/Estudos/Rubens.pdf, Agosto.
142
VI Simpsio Internacional de
Melhoria de Processos de Software
So Paulo, SP Brasil 24-26/11/2004
www.simpros.com.br