O processo estruturado de desenvolvimento de software não apresenta soluções adequadas para a construção de grandes sistemas computacionais. Os sistemas construídos sob as regras deste paradigma, quase sempre, apresentam problemas graves logo que são implantados. Este fato decorre, principalmente, da ausência de respostas no processo para a dinâmica própria dos requisitos de software: os requisitos de software mudam rápida e constantemente. Diante deste cenário os produtores de software passaram a buscar alternativas àquela forma de desenvolver sistemas computacionais; e é basicamente neste contexto que surgiu o conceito de desenvolvimento de software orientado a objetos.
Os processos que usam a abordagem orientada a objetos, ou simplesmente OO, além de outras facilidades, oferecem soluções para o problema da dinâmica dos requisitos de software que é, sem dúvida, o mais importante. Entre estes processos o RUP (Rational Unified Process) é o mais disseminado e, embora seja um processo pesado e complexo, encontra mais adeptos a cada dia. O RUP apresenta soluções para o ciclo completo de desenvolvimento de software: da análise de requisitos à implantação do sistema. No entanto, para que possa ser utilizado em sua plenitude, requer que seja empregada uma linguagem de programação também orientada a objetos, Java, por exemplo, e isso nem sempre é conveniente ou mesmo, possível.
A essência do Processo Híbrido (HUP) consiste na realização de um projeto de software pelo uso de elementos do RUP e do Processo Estruturado. Isso visa permitir que um sistema a ser construído
No HUP as atividades iniciais devem ser as mesmas propostas pelo RUP, no entanto, na medida em que se aproxima da fase de construção, os trabalhos devem ser direcionados para a consecução de artefatos que conduzam às especificações de programas que serão codificados numa linguagem estruturada. O momento e o meio pelo qual se dará a interface entre as duas abordagens devem ser planejados antes do início do projeto. E é importante sublinhar que, para cada projeto, concretamente, pode haver um momento e uma forma diferente de se realizar a transição entre uma abordagem e outra. Normalmente esta transição acontece após a especificação dos casos de uso. Nesta hipótese, tomam-se como base os cenários ou os próprios casos de uso para se desenvolver as especificações. A meu ver é interessante que se construa um artefato que apresente o relacionamento entre os programas que constituirão um determinado caso de uso (ou cenário, se tiver sido essa a escolha) e, somente depois disso, iniciar as especificações propriamente ditas. Participei de projetos em que se optou por desenvolver um diagrama de classes (com certas adaptações, é claro) para se representar o relacionamento entre os programas, no entanto os resultados não foram bons: o diagrama de classes é complexo e, ainda que adaptado, apresentou uma rigidez incompatível com as necessidades. Penso que o mais apropriado seja um diagrama como o DHS (Diagrama Hierárquico do Sistema) que é extremamente simples e atende às necessidades.
Finalmente, é importante enfatizar que, não obstante considerar elementos da abordagem estruturada de desenvolvimento de software, o HUP deve ser conduzido iterativamente e não no estilo “cascata”, como acontece normalmente no processo estruturado.
