O conceito de fábrica de software baseia-se na idéia de prover uma linha de produção de soluções que atendam às necessidades específicas de cada cliente. Isto se dá através da
formalização de todas as atividades e seus produtos, trabalhando em forma de linha de produção, com etapas e tarefas bem definidas para cada tipo de profissional, indo das tarefas básicas da linha de produção até rotinas de controle de qualidade (Brito 2004).
Em uma fábrica de software, diferentes processos podem co-existir, adequados a diferentes projetos. Para organizar e disciplinar o desenvolvimento de software é importante determinar as atividades fundamentais que deverão estar presentes em qualquer processo definido. A definição de um processo padrão estabelece uma estrutura comum a ser utilizada pela organização nos seus projetos de software e constitui a base para a definição de todos os processos (Rocha, 2001).
Assim sendo, o processo padrão estabelecido deve ser tomado como referencial no necessário planejamento e definição das estratégias de cada fábrica e deve ser genérico o suficiente para atender na maioria dos casos. A existência desse padrão também proporciona economia de tempo e esforço a cada necessidade de customização do processo de desenvolvimento dadas as particularidades de cada Projeto.
Segundo Humphrey (1989), um processo de desenvolvimento de software pode ser entendido como um conjunto de passos (atividades) necessários para transformar os requisitos do usuário em software. Ele aponta, porém, distinções entre um processo de desenvolvimento de software e um processo de manufatura típico:
• O produto software geralmente é mais complexo que outros produtos manufaturados;
• Em virtude da engenharia de software ser relativamente recente, o mercado não dispõe de muitos gerentes e profissionais com o necessário conhecimento, nem com a devida experiência para avaliar e calibrar um processo de desenvolvimento de software;
• O custo insignificante de reproduzir o software leva à descoberta tardia de problemas.
Fernandes (2004) acrescenta outra importante distinção: embora estejam definidos, em termos de método de construção, forma de apresentação, precedência de construção e agregação, os produtos gerados em cada passo do processo de software, a tangibilidade deles
fica a dever àquela de outros produtos manufaturados. Contribui para isso o fato de, durante as fases que antecedem à codificação dos programas (produto concreto), os artefatos gerados serem representações de idéias, donde com grande cunho subjetivo, cujo nível de detalhe varia conforme a profundidade da análise realizada.
Até então, tratamos o processo de software no nível de “engenharia do produto”, ou “construção do produto”, ou “processo produtivo de operação”, denominações adotadas por Fernandes (2004), que ressalta o fato de um processo produtivo estar sempre associado a um processo gerencial. Esse nível gerencial se traduz na gestão de uma ou de múltiplas demandas, bem como na gestão de uma ou mais operações estratégicas.
Para Zahran (1998), o processo é o elo entre pessoas, equipes, tecnologia, estruturas organizacionais e a gestão em um todo coerente que focaliza os objetivos e as metas de um negócio. Portanto:
• O processo e a forma de apoiá-lo devem nortear a definição dos papéis organizacionais e suas responsabilidades, das práticas gerenciais, das habilidades requeridas e da seleção e instalação da tecnologia;
• A organização deve especificar as funções a desempenhar e monitorar as atividades do processo;
• A gerência deve prover a direção estratégica e gerenciar o desempenho do processo;
• Os técnicos devem ter habilidades para desempenhar com competência as atividades do processo, e a tecnologia automatizá-las e apóia-las.
Para Lonchamp (1993), um processo de software é formado por um conjunto de passos (atividades) parcialmente ordenados, associados a papéis, ferramentas e artefatos, tendo como objetivo produzir e manter os produtos de software requeridos, ou seja, gerar ou modificar um conjunto de artefatos. Atividades incorporam e implementam procedimentos, regras e políticas; podem ser executas por agentes humanos com o apoio de ferramentas, ou executados de forma totalmente automática (sem a intervenção humana).
Uma atividade aloca recursos (por exemplo, máquinas e orçamento), é escalonada, monitorada e atribuída 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 terão percepções diferentes acerca do que acontece durante o processo de software. Por sua vez, cada artefato resulta de uma atividade. (Rocha, 2005).
A descrição abstrata do processo de software caracteriza um modelo de processo de software. Vários tipos de informação devem ser integrados em um modelo de processo para indicar quem, quando, onde, como e por que os passos são realizados.
Segundo Conradi (1994), projeto é a instância de um processo, com objetivos e restrições específicos. Pode-se dizer que um projeto é um esforço para desenvolver um produto de software, ou seja, envolve uma estrutura organizacional, prazos, orçamentos, recursos e um processo de desenvolvimento.
Podemos classificar um processo de desenvolvimento de software em dois tipos, segundo sua forma de sua execução:
• O processo tradicional (ou processo pesado) tem como foco principal o levantamento e o detalhamento rigoroso dos requisitos do sistema, antes do início do desenvolvimento. Nesse levantamento, todas as necessidades do cliente são definidas e documentadas, sendo que para cada um dos requisitos são gerados documentos agregados, tornando o processo de análise e projeto bastante demorados e de difícil manutenção, caso alguma especificação seja alterada. É caracterizado pelo planejamento detalhado das fases seqüenciais de processo, e pela disponibilização de artefatos gerados numa fase para a fase seguinte (Pressman, 2000). Um exemplo de processo tradicional é o RUP – Rational Unified Process (Krutchen, 2003).
• O processo ágil (ou processo leve) tem como foco principal a eficiência, ficando no meio termo entre a inexistência e o rigor de um processo tradicional. Tem como premissa que as mudanças são inevitáveis e propõe que a análise de requisitos seja extremamente mutável (Beck, 2000). Sendo assim, os re-planejamentos são constantes, não havendo uma etapa exclusiva para isso, e o foco está na versatilidade da codificação. Pressupõe que cada atividade deve agregar valor ao processo, comunicação, adaptabilidade e aprendizado constante. Em sendo sua
gestão orientada a pessoas, é esperado um ciclo de vida curto, durante o qual a rotatividade seja mínima. Como exemplo de processo ágil temos o XP (Jeffries, 2001).
Quanto ao processo tradicional, que pode ser instanciado e customizado de acordo com o porte da aplicação ou da Organização, a burocracia lhe agrega uma quantidade de tarefas maior do que aquelas previstas no processo ágil, com previsível impacto no prazo de execução. Porém, a informalidade do processo ágil é um dificultador quando do desenvolvimento de software cujas regras de negócio são complexas, ou cujo escopo é grande, ou que é desenvolvido por equipe numerosa e/ou distribuída geograficamente, uma vez que a arquitetura do software pode ser redefinida e refinada a todo o momento.
Visando um ganho maior de produtividade e o alcance dos objetivos da fábrica, é importante adotar o processo de desenvolvimento mais adequado ao seu perfil, pois a alternância de processos não é recomendada, embora a possibilidade de flexibilização do processo seja desejável e analisada caso a caso.
As fábricas que atendem ao modelo de outsourcing de sistemas são orientadas ao processo tradicional. Em muitos casos, o próprio cliente exige a certificação da fábrica em um modelo de qualidade reconhecido mundialmente, o que reforça a necessidade de clara definição dos processos bem como da metodologia de coleta e acompanhamento das métricas de produção. Cabe fazer referência a uma experiência relatada por Fowler (2004) de implantação de um processo ágil em outsourcing de sistemas.
Assim sendo, a concepção desse processo de desenvolvimento em cada fábrica de software não é genérico, e deve estar adequado ao tipo e ao contexto dessa fábrica, considerando:
• Finalidade da fábrica de software: desenvolver pacotes (tais como sistemas de gestão- ERP) ou software sob encomenda;
• Processos básicos de produção de software: desenvolvimento e/ou manutenção (corretiva, evolutiva ou legal);
• Perfil das equipes, em termos de conhecimento e experiência não apenas nas ferramentas utilizadas na fábrica, mas no negócio do cliente;
• Disponibilidade de recursos x paralelismo de projetos encomendados à fábrica;
• Diversidade das plataformas de desenvolvimento.
Tais fatores também são determinantes na escolha das ferramentas automatizadas de apoio aos processos de construção e gestão de software, do tratamento de defeitos e falhas a ser adotado, da infra-estrutura computacional e de rede necessária.