E-MARKET AS A COLLABORATIVE VIRTUAL PLACE

O modelo de desenvolvimento escolhido para a parte relativa á criação de aplicações de software é o modelo iterativo.

Figura 3 - Modelo de desenvolvimento Iterativo

4.2.1 Racionalização da escolha

A natureza cíclica e as fases específicas do ciclo de desenvolvimento permitem que não se defina uma fase final específica após uma série contável de passos (ex.: modelo waterfall) nem sequer após um número concreto de iterações cíclicas (ex.: modelo espiral) permitindo que o ciclo de desenvolvimento nem sequer encerre caso seja essa a situação mais vantajosa. E como se aplicam então essas vantagens ao desenvolvimento existente? Veja-se que, o desenvolvimento a efectuar, devido á Ausência de documentação e de referências específicas em relação a que cenário se irá encontrar em termos de “matéria prima”, é de um carácter sobretudo exploratório e consequentemente empírico em relação á experiencia obtida no processo exploratório. Isso condiciona a definição de fases específicas de desenvolvimento pois

não se sabe à priori quais e quantas tarefas intermédias serão necessário efectuar até se atingirem os objectivos propostos .

Outros factores podem ser indicados para dar suporte a esta escolha:

● O escrutínio passo a passo do desenvolvimento necessariamente efectuado pelo quadro superior responsável pelo projecto é facilitado por pequenas fases cíclicas que incluem pequenos testes de funcionamento.

● O carácter exploratório da implementação torna recomendável a simplicidade da implementação passo a passo e a respectiva execução de testes uma vez que não se poderá perder o rumo já que o caminho é feito “ás cegas”, ou seja, de forma simplificada: um passo de desenvolvimento exploratório e pequenos testes subsequentes que permitam avaliar a adaptabilidade e correcção do passo efectuado.

● A mutabilidade de critérios para os outputs necessários é um facto, daí se possa inferir que certos pormenores de mais baixo nível inferidos dos requisitos possam mudar. E porquê? Porque no processo de descoberta do tipo de dados que se tem disponível para trabalhar, o que se encontrar em termos de informação disponível ou usável poderá condicionar ou reorientar de forma ligeira o desenvolvimento. Essas pequenas mudanças são previstas quando no modelo iterativo cada ciclo permite a existência de novos requisitos.

Poder-se-á afirmar também que, qualquer modelo de desenvolvimento que implique um planeamento antecipado bastante completo ou específico não é indicado para este fim (ex.: Qualquer modelo sequencial ou planeado como o modelo Waterfall)., qualquer modelo de desenvolvimento que implique a criação de protótipos periódicos ou de implementações funcionais (software que “funciona”) não é indicado (ex.:modelo espiral, metodologias ágeis).

A implementação não surge em períodos específicos, vai surgindo até atingir um nível de operacionalidade razoável que lhe permita ter utilidade concreta e mesmo aí continuará a ser desenvolvida até á estabilização de requisitos, optimização de processos ou término de funcionalidades requeridas.

Note-se que, existe um plano de implementação a um nível alto de planeamento como está descrito proximamente, mas, dentro desses macro-niveis é que se desenvolverão (possívelmente até em paralelo) várias iterações de desenvolvimento pequenas e testáveis.

Note-se também que o desenvolvimento em espiral ou por metodologias ágeis de desenvolvimento seria possível caso os critérios de desenvolvimento fossem mais orientados á interface e houvesse uma referência documental concreta do conteúdo e estrutura da base da dados existente. Isso permitiria a apresentação de protótipos semi-funcionais periódicos orientados ao interface enquanto se completava a implementação dos processos de suporte a esse mesmo interface. No entanto, neste caso específico, o desenvolvimento tem como prioridade inicial assegurar um bom conhecimento das estruturas subjacentes (exploração) e assegurar uma boa robustez das mesmas (testes) de forma a criar um bom suporte a toda a implementação e a futuras aplicações suplementares.

(Posteriormente um pormenor da implementação a nível de concepção de base de dados dará indícios deste tipo de metodologia pela existência de patches que pretendem servir de suporte definitivo ao fluxo de dados actual mas que por mudanças originadas pelo decorrer dos trabalhos de implementação exploratórios posteriores acabaram por se tornar apenas um suporte temporário da aplicação durante as próximas iterações de desenvolvimento)

4.2.2 Adaptação específica do modelo ao projecto

A adaptação do método de desenvolvimento iterativo a este projecto específico recai na fase de desenvolvimento de software, nomeadamente na Implementação de Sistema de Informação de Bilhética de Suporte á Gestão. Esta fase do projecto tem três módulos de

desenvolvimento de alto nível identificados e que serão posteriormente descritos sendo os mesmos:

● Análise das Bases de Dados Existentes e Origens de Informação

● Concepção da Estrutura de Dados de Suporte á Bilhética

● Concepção de Interfaces

Isto faz com que o modelo de desenvolvimento seja aplicado a duas das três fases tal como é demonstrado na figura seguinte.

Figura 4 - Adaptação do modelo de desenvolvimento Iterativo ás fases da implementação

De notar que a Análise das Bases de Dados Existentes e Origens de Informação não segue o modelo iterativo pois apesar de fazer parte da fase de implementação, não é uma fase de desenvolvimento puro.

Esclarece-se também que, as sobreposições dos módulos de desenvolvimento implicam não só o facto de cada parte ser um processo contínuo e potencialmente inacabado (consoante a s possíveis refinações ou mudanças de requisitos) mas que, por vezes, existem certas tarefas cujo âmbito acaba por se sobrepor e que fazem parte de mais do que um dos módulos de desenvolvimento.