Modelo Cascata

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CURSO DE SISTEMAS DE INFORMAÇÃO

Aluno: Wanderlei Passos

Resumo do Artigo 1

Uma Visão de Abordagem de Desenvolvimento de Software do Rational Unified Process

Autores: Antônio Roberto Albuquerque

Luciano Schiavo

UNIP, Universidade Paulista

Resumo

O Rational Unified Process (RUP), segundo um dos seus criadores, pode ser visto como um produto processo, um processo de engenharia ou uma abordagem de desenvolvimento de software. Uma visão um pouco mais profunda mostra que a abordagem de desenvolvimento de software utilizada pelo RUP está baseada em conceitos organizados e aplicados durante todo o avanço da engenharia de software. A idéia é apresentar a evolução existente em engenharia de software até o momento e confronta-la com o que é apresentado pelo RUP.

1. Introdução

Engenharia de Software é uma ciência relativamente nova que foi definida inicialmente, segundo (Pressman, 2002), em 1969 em uma conferência dedicada ao assunto. Nesta conferência Fritz Bauer a definiu como “a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais”.

2. Conceitos básicos

Apesar dos vários conceitos e visões disponíveis na engenharia de software é necessário o desenvolvimento de alguns conceitos básicos que consolidem o conhecimento dentro desse trabalho. A definição dos seguintes termos é necessária:

2.1. Engenharia de Software

Hoje, ainda não temos um consenso nesse assunto. O Institute of Electrical and Eletrônics Engenineers (IEEE) apresenta a seguinte definição: “engenharia de software é (1) a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software; isto è, a aplicação de engenharia de software; (2) o estudo das abordagens como de (1)”.

2.2. Produto

Falando-se de software, ainda há dúvidas sobre o que necessariamente deve ser considerado como produto: o que foi entregue ao cliente ou o que foi criado e utilizado na confecção do software?

Spinosa em sua tese de doutorado (Spinosa, ????), aborda a diferenciação entre produto de software e produto de desenvolvimento de software.

Como Produto de Software Spinosa utiliza a definição estabelecida pela norma IEEE STD-610: produto de software é o “...conjunto completo, ou qualquer dos itens individuais do conjunto, de programas de computador, procedimentos, e documentação associada e dados designados para liberação para um cliente ou usuário final.

Como Produto de Desenvolvimento de Software, Spinosa cita a mesma definição encontrada na obra (CMM, 1995), é a seguinte: “...qualquer artefato criado como parte da definição, manutenção ou uso do processo de desenvolvimento de software, que podem ser ou não destinados a liberação para um cliente ou usuário final”.

2.3. Processo

Para (Jacobson, 1992) o processo é a forma natural de escalar um método, que é fácil de entender através do exemplo: “ Produzir uma nova substância química no laboratório difere grandemente de produzir a nova substância em escala industrial. No laboratório o objetivo é encontrar um método para produzir a substância. Para fazer este método apropriado para o uso industrial em larga escala, um processo deve ser definido ”.

(Presman, 2002) discorre sobre a seguinte pergunta: Processo é sinônimo de engenharia de software? Estranhamente o autor aceita a comparação e indica também que a negação também ocorre por entender que um processo de desenvolvimento de software é parte da engenharia de software.

Para (Silva, 2001) “ o processo de desenvolvimento de software é um conceito de âmbito muito vasto e pretende designar uma seqüência de atividades , normalmente agrupadas em fases e tarefas, que são executadas de forma sistemática e uniformizada, que são realizadas por pessoas com responsabilidades bem definidas, e que a partir de um conjunto de inputs produzem um conjunto de outputs.

2.4. Modelo de Processo de Software

Segundo (Pressman, 2002) o trabalho associado a engenharia de software pode ser categorizado em fases genéricas independente da área de aplicação, tamanho do projeto e complexidade. A fases necessariamente focam no que(definição), como(desenvolvimento) e modificções(manutenção).

As camadas de processo, os métodos (conjunto de tarefas que abrange análise de requisitos, projeto, construção de programas, testes e manutenção) e ferramentas em conjunto com as fases formam o modelo de processo de software.

Esse e outros modelos eram chamados de ciclo de vida de software na década de 80 e buscam maximizar o desenvolvimento de software.

2.4.1 Cascata, Linear ou Clássico.

O modelo cascata descreve um método de desenvolvimento que é linear e seqüencial. O desenvolvimento move do conceito, através do projeto, implementação, teste, instalação, descoberta de defeitos e termia com a operação e manutenção. Cada fase de desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposição ou passos iterativos. Ou seja, cada vez que uma fase é completada, o desenvolvimento prossegue para a próxima fase e não há retorno.

2.4.2. Prototipação

“Durante a década de 80, as experiências práticas negativas com o modelo cascata levaram a um modelo completamente diferente: o modelo iterativo (também chamado como abordagem de prototipação). Esta estratégia alternativa começa com a premissa que o desenvolvimento de sistema pode começar com informação incompleta e que equisitos completos são obtidos através de um processo cíclico e dialético de reações do usuário no protótipo. O importante nesta abordagem é que o ponto de vista orientado a projeto é enriquecido com o aumento de interesse da participação do usuário final” (IBM, 2001).

2.5. Modelo