Processos Iterativos de desenvolvimento de software

Contextualização

A Crise do Software é realidade desde meados da década de 70. Clientes insatisfeitos, atrasos nos prazos, custo infinito e produto final com baixa qualidade são apenas algumas características que marcam esta crise.

Apesar da evolução tecnológica e das iniciativas de intelectuais como Barry Boehm na década de 80 e Gustav Karner na década de 90, que propuseram métodos de estimativas, atualmente permanecem raros os exemplos de projetos de software desenvolvidos fora dos padrões da crise descrita.

No combate ao cenário caótico, tornam-se necessárias a criação e a adoção de metodologias que auxiliem os projetos de desenvolvimento. Desta forma, é possível gerenciar a crise. Algumas tentativas foram propostas.

Na década de 80 surgiu um tipo de processo conhecido como Processo Cascata (do original, em inglês, Waterfall Process). É constituído basicamente por cinco fases seqüenciais: descoberta de requisitos, desenho, implementação, teste e implantação. Com sua utilização, percebeu-se que o processo não atendia completamente as necessidades dos profissionais. A constante mudança de requisitos, a divisão inflexível das atividades e a rigidez imposta colaboraram para o fracasso do processo.

Já no início da década de 90, um tipo de processo conhecido como Processo Espiral surgiu como uma boa solução aos problemas identificados no Processo Cascata, pois protótipos são construídos a cada ciclo e refinados nas fases seguintes. Este processo permite que as fases sejam definidas de acordo com objetivos do projeto. Porém, a má adequação ao paradigma de orientação a objetos determinou o fracasso deste processo. O modo procedimental de criação de software já não era suficiente na resolução de problemas complexos ou, pelo menos, extensos.

A solução definitiva, consolidada no final dos anos 90, foi a criação de um tipo de processo conhecido como Processo Iterativo. Neste, a cada iteração os modelos são refinados e, ao final de cada ciclo, um protótipo é entregue aos stakeholders, os interessados no projeto.

O paradigma do Processo Iterativo e suas realizações

O Processo Iterativo define um paradigma, ou seja, uma forma de pensar. Este não pode ser considerado um processo completo de desenvolvimento de software, pois não discrimina as atividades necessárias para que este objetivo seja alcançado.

Uma realização desta forma de pensar é o Processo Unificado (UP), que se encaixa na definição geral de um processo completo: um conjunto de atividades executadas para transformar um conjunto de requisitos em um sistema de software. Entretanto o Processo Unificado também é uma estrutura genérica de processo que pode ser customizada adicionando-se ou removendo-se atividades com base nas necessidades específicas e nos recursos disponíveis para um projeto. Também pode sofrer alterações de acordo com a filosofia da empresa que o emprega. O Processo Unificado da Rational (RUP), por exemplo, é uma versão especializada do Processo Unificado que adiciona elementos a sua estrutura genérica. Surgiu dos esforços de Ivar Jacobson, Grady Booch e James Rumbaugh em 1998 na Rational, recentemente adquirida pela IBM.

O Microsoft Solutions Framework (MSF), que também se encaixa na definição geral de um processo completo, já é uma outra realização do paradigma do Processo Iterativo. Surgiu da vasta experiência em desenvolvimento de software adquirida pela Microsoft ao longo de sua existência. Uma vantagem evidente na utilização desta metodologia é alcançada para as equipes que utilizam ou utilizarão o Visual Studio 2005 Team System, pois esta ferramenta possui dois methodology templates que podem ser adequados de acordo com as necessidades ou utilizados como fundação na criação de uma versão especializada do processo.

Conclusão

Apesar de existirem esforços e iniciativas na unificação dos processos completos de desenvolvimento de software, o que realmente aconteceu foi o estabelecimento de um paradigma como sendo o mais correto no gerenciamento da crise do software.

Note que eu utilizei a palavra “gerenciamento” e não “solução”. Este tipo de crise não pode ser extinta, ela existe toda a vez que uma equipe não se baseia em uma metodologia comprovadamente eficaz (cenário ainda muito comum no mercado brasileiro). O termo “gerenciamento” refere-se à possibilidade de medir, de forma controlada e adaptativa, o tempo e o custo de um projeto.

Realmente a unificação apenas do paradigma me parece mais correta do que a unificação dos processos completos, dado que cada empresa possui sua filosofia e o processo ocorre internamente. O mesmo não acontece com as linguagens de modelagem, que foram unificadas na UML para que as empresas possam compartilhar modelos e componentes.

Já que a adoção de uma metodologia é necessária, selecione aquela que se encaixe melhor no projeto e nos recursos disponíveis. Considere também a ferramenta de desenvolvimento utilizada como fator de decisão. Por fim, tenha em mente que a criação de uma metodologia também é bem-vinda, contanto que siga o paradigma iterativo.