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

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 131

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 132

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]

133

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 134

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: 135

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.

136

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 137

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 138

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

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

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: AddisonWesley. JavaDoc Tool (2004) , http://java.sun.com/j2se/javadoc/, Agosto. Jefrries, R. (2001) What is Extreme http://www.xprogramming.com/xpmag/whatis.htm, Junho. Programming?,

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.

141

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

142