Processo De Software

INTRODUÇÃO

Nesse trabalho destacarei a importância do processo de software e seu modelo mais importante, o modelo em cascata, que também é conhecido por abordagem “top-down”, foi proposto por royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este e mais rígido e menos administrativo.

Objetivo

O objetivo desse trabalho e destacar cada fase do modelo em cascata de forma que, demonstre a importância de cada fase no processo de software, apresentando suas vantagens e desvantagens e destacando a importância do processo de software para os dias atuais.

Desenvolvimento

O processo de software

A utilização de um processo de software têm sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software.

Para poder melhor compreender o assunto é necessário definir o que é um processo de software.

Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. Assim Sommerville[1] traz a seguinte definição:

"[O processo é] um conjunto de atividades e resultados associados que produzem um produto de software".

Jalote[7] conclui que um processo de software é:

"é um conjunto de atividades, ligadas por padrões de relacionamento entre ela, pelas quais se as atividades operarem corretamente e de acordo com os padrões requeridos, o resultado desejado é produzido. O resultado desejado é um software de alta qualidade e baixo custo. Obviamente, um processo que não aumenta a produção (não suporta projetos de software grandes) ou não pode produzir software com boa qualidade não é um processo adequado."

A partir destas definições podemos considerar que de forma geral um processo de software padrão pode ser visto como um conjunto de atividades, métodos, ferramentas e práticas que são utilizadas para construir um produto de software. Na definição de um processo de software devem ser consideradas as seguintes informações: atividades a serem realizadas, recursos necessários, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado [3].

Modelos de Processos de Desenvolvimento de Software

Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às situações a analisar, porque só na altura em que enfrentamos o problema é que podemos escolher o modelo.

Nos modelos de processo de software é dado uma atenção especial à representação abstrata dos elementos do processo e sua dinâmica, não estabelecendo métodos de desenvolvimento, pois este trabalha num nível mais alto de abstração do que os modelos de ciclo de vida.WWW[7]

O modelo em cascata

Modelo idealizado por Royce em 1970, também conhecido como abordagem ‘top-down’, tem como principal característica a sequência de atividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para uma nova fase. Sofreu diversas ajustes e aprimoramentos sendo muito utilizado nos dias atuais.

Descrição Visual do Modelo

A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem uma sequência, ou seja, a saída da primeira etapa "fluí" para a segunda etapa e a saída da segunda etapa "fluí" para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma das vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual.

O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata, designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar. [6]

História do modelo em cascata

Em 1970 royce propôs o que é agora popularmente designado no modelo em cascata como um conceito inicial, um modelo no qual ele argumentava ser defeituoso. Seu trabalho então explorou como o modelo inicial poderia ser desenvolvido em um modelo iterativo, com feedback de cada fase influenciando as próximas, de modo similar a muitos métodos amplamente utilizados hoje. Ironicamente, foi somente o modelo inicial que mereceu destaque, e sua crítica ao modelo inicial sendo amplamente ignorada. O modelo em cascata rapidamente não se tornou o que royse pretendia, um projeto iterativo, mas ao invés disto um modelo puramente sequencial ordenado.

A despeito das intenções de royse para o modelo em cascata ser modificado