PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 1. VISÃO GERAL 1.1. PROCESSOS EM GERAL Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta. Esta meta geralmente está associada a um ou mais resultados concretos finais, que são os produtos da execução do processo. Um processo é uma receita que é seguida por um projeto; o projeto concretiza uma abstração, que é o processo. Não se deve confundir um processo (digamos, uma receita de risoto de camarão) com o respectivo produto (risoto de camarão) ou com execução do processo através de um projeto (a confecção de um risoto de camarão por determinado cozinheiro, em determinado dia). Um processo é definido quando tem documentação que detalha: o que é feito (produto), quando (passos), por quem (agentes), as coisas que usa (insumos) e as coisas que produz (resultados). Processos podem ser definidos com mais ou menos detalhes, como acontece com qualquer receita. Os passos de um processo podem ter ordenação apenas parcial, o que pode permitir paralelismo entre alguns passos. Por exemplo, na figura acima, um processo é representado na forma de um grafo. Existe paralelismo entre os passos 2a e 2b. Passos, agentes, insumos e resultados estão entre os elementos de um processo. A arquitetura de um processo define um arcabouço conceitual para a organização dos elementos de um processo. 1.2. PROCESSOS DE SOFTWARE Em engenharia de software, processos podem ser definidos para atividades como desenvolvimento, manutenção, aquisição e contratação de software. Pode-se também definir subprocessos para cada um desses; por exemplo, um processo de desenvolvimento abrange subprocessos de determinação dos requisitos, análise, desenho, implementação e testes. Em um processo de desenvolvimento de software, o ponto de partida para a arquitetura de um processo é a escolha de um modelo de ciclo de vida. O ciclo de vida mais caótico é aquele que pode ser chamado de Codifica-remenda. Partindo apenas de uma especificação (ou nem isso), os desenvolvedores começam imediatamente a codificar, remendando à medida que os erros vão sendo descobertos. Nenhum processo definido é seguido. Infelizmente, é provavelmente o ciclo de vida mais usado. Para alguns desenvolvedores, esse modelo é atraente porque não exige nenhuma sofisticação técnica ou gerencial. Por outro lado, é um modelo de alto risco, impossível de gerir e que não permite assumir compromissos confiáveis. No modelo de ciclo de vida em Cascata, os principais subprocessos são executados em estrita seqüência, o que permite demarcá-los com pontos de controle bem-definidos. Esses pontos de controle facilitam muito a gestão dos projetos, o que faz com que esse processo seja, em princípio, confiável e utilizável em projetos de qualquer escala. Por outro lado, se interpretado literalmente, é um processo rígido e burocrático, em que as atividades de requisitos, análise e desenho têm de ser muito bem dominadas, pois
não são permitidos erros. O modelo em cascata puro é de baixa visibilidade para o cliente, que só recebe o resultado final do projeto. Na prática, é sempre necessário permitir que, em fases posteriores, haja revisão e alteração de resultados das fases anteriores. Por exemplo, os modelos e documentos de desenho podem ser alterados durante a implementação, à medida que os problemas vão sendo descobertos. Uma variante que permite superposição entre fases e a realimentação de correções é um modelo mais realista, com realimentação entre as fases. A realimentação entre fases toma difícil gerenciar projetos baseados nesse modelo de ciclo de vida. Um modelo de ciclo de vida radicalmente diferente é o modelo em Espiral. O produto é desenvolvido em uma série de iterações. Cada nova iteração corresponde a uma volta na espiral. Isso permite construir produtos em prazos curtos, com novas características e recursos que são agregados à medida que a experiência descobre sua necessidade. As atividades de manutenção são usadas para identificar problemas; seus registros fornecem dados para definir os requisitos das próximas liberações. O principal problema do ciclo de vida em espiral é que ele requer gestão muito sofisticada para ser previsível e confiável. Quando o modelo em espiral é aplicado a um único projeto, tem-se o modelo de Prototipagem evolutiva. Nesse modelo, a espiral é usada não para desenvolver o produto completo, mas para construir uma série de versões provisórias que são chamadas de protótipos. Os protótipos cobrem cada vez mais requisitos, até que se atinja o produto desejado. A prototipagem evolutiva permite que os requisitos sejam definidos progressivamente, e apresenta alta flexibilidade e visibilidade para os clientes. Entretanto, também requer gestão sofisticada, e o desenho deve ser muito robusto, para que a estrutura do produto não se degenere ao longo dos protótipos. Além disso, requer equipe muito disciplinada e experiente. Esse modelo de ciclo de vida é aplicado em processos recentes que se dizem ágeis, dos quais o XP é o mais conhecido. Uma combinação dos modelos em Cascata e Prototipagem evolutiva forma o modelo de Entrega Evolutiva. Esse modelo permite que, em pontos bem-definidos, os usuários possam avaliar partes do produto e fornecer realimentação quanto às decisões tomadas. Facilita também o acompanhamento do progresso de cada projeto, tanto por parte de seus gerentes como dos clientes. A principal dificuldade é a realização do desenho arquitetônico (isto é, dos aspectos de mais alto nível de abstração): ele deve produzir uma arquitetura de produto robusta, que se mantenha íntegra ao longo dos ciclos de liberações parciais. Em modelos dirigidos por prazo (time-boxed), o produto é aquilo que se consegue fazer dentro de determinado prazo. Esses modelos podem ser razoáveis quando se consegue definir um conjunto de requisitos indispensáveis para os quais se sabe que os prazos estabelecidos são suficientes, e as folgas são usadas apenas para implementar requisitos opcionais. Na prática, os prazos costumam ser definidos de forma política, e o produto que se entrega no final do prazo é apenas um resultado parcial. Este será completado aos trancos e barrancos em desenvolvimento posterior, disfarçado de manutenção. O ciclo de vida pode ser também dirigido por ferramenta (que pode ser chamada, pelos respectivos fabricantes, de ferramenta de CASE ou plataforma de desenvolvimento). Algumas ferramentas impõem processos rígidos, que podem ser adequados para tipos bem específicos de produtos. A qualidade desses processos depende fundamentalmente da qualidade da ferramenta e de que o uso do processo seja restrito ao seu domínio de aplicação. Uma solução tentadora pode ser comprar em vez de desenvolver. Quando se encontra um produto que atende aos requisitos desejados, é uma boa solução. Nesse caso, não há processo de desenvolvimento, mas existirão processos de aquisição, de implantação e, possivelmente, de adaptação e integração com outros sistemas. Dependendo dos casos, esse conjunto de processos pode ser mais sofisticado e caro do que um processo de desenvolvimento.
Muitos outros detalhes podem ser discutidos a respeito dos modelos de ciclo de vida de software.