Вы находитесь на странице: 1из 5

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CURSO DE SISTEMAS DE INFORMAO


Aluno: Wanderlei Passos

Resumo do Artigo 1
Uma Viso de Abordagem de Desenvolvimento de
Software do Rational Unified Process
Autores: Antnio 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 viso 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 avano da engenharia de software. A
idia apresentar a evoluo existente em engenharia de software at o momento e
confronta-la com o que apresentado pelo RUP.

1. Introduo
Engenharia de Software uma cincia relativamente nova que foi definida inicialmente,
segundo (Pressman, 2002), em 1969 em uma conferncia dedicada ao assunto. Nesta
conferncia Fritz Bauer a definiu como a criao e a utilizao de slidos princpios de
engenharia a fim de obter software de maneira econmica, que seja confivel e que
trabalhe eficientemente em mquinas reais.

2. Conceitos bsicos
Apesar dos vrios conceitos e vises disponveis na engenharia de software necessrio
o desenvolvimento de alguns conceitos bsicos que consolidem o conhecimento dentro
desse trabalho. A definio dos seguintes termos necessria:

2.1. Engenharia de Software


Hoje, ainda no temos um consenso nesse assunto. O Institute of Electrical and
Eletrnics Engenineers (IEEE) apresenta a seguinte definio: engenharia de software
(1) a aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o
desenvolvimento, operao e manuteno de software; isto , a aplicao de engenharia
de software; (2) o estudo das abordagens como de (1).

2.2. Produto
Falando-se de software, ainda h dvidas sobre o que necessariamente deve ser
considerado como produto: o que foi entregue ao cliente ou o que foi criado e utilizado
na confeco do software?
Spinosa em sua tese de doutorado (Spinosa, ????), aborda a diferenciao entre produto
de software e produto de desenvolvimento de software.
Como Produto de Software Spinosa utiliza a definio 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 documentao
associada e dados designados para liberao para um cliente ou usurio final.
Como Produto de Desenvolvimento de Software, Spinosa cita a mesma definio
encontrada na obra (CMM, 1995), a seguinte: ...qualquer artefato criado como parte
da definio, manuteno ou uso do processo de desenvolvimento de software, que
podem ser ou no destinados a liberao para um cliente ou usurio final.

2.3. Processo
Para (Jacobson, 1992) o processo a forma natural de escalar um mtodo, que fcil
de entender atravs do exemplo: Produzir uma nova substncia qumica no laboratrio
difere grandemente de produzir a nova substncia em escala industrial. No laboratrio o
objetivo encontrar um mtodo para produzir a substncia. Para fazer este mtodo
apropriado para o uso industrial em larga escala, um processo deve ser definido .
(Presman, 2002) discorre sobre a seguinte pergunta: Processo sinnimo de engenharia
de software? Estranhamente o autor aceita a comparao e indica tambm que a
negao tambm 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 seqncia de atividades , normalmente
agrupadas em fases e tarefas, que so executadas de forma sistemtica e uniformizada,
que so 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 genricas independente da rea de aplicao, tamanho do projeto

e complexidade. A fases necessariamente focam no


que(definio),
como(desenvolvimento) e modifices(manuteno).
As camadas de processo, os mtodos (conjunto de tarefas que abrange anlise de
requisitos, projeto, construo de programas, testes e manuteno) 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 dcada de 80 e
buscam maximizar o desenvolvimento de software.

2.4.1 Cascata, Linear ou Clssico.


O modelo cascata descreve um mtodo de desenvolvimento que linear e seqencial. O
desenvolvimento move do conceito, atravs do projeto, implementao, teste,
instalao, descoberta de defeitos e termia com a operao e manuteno. Cada fase de
desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposio ou
passos iterativos. Ou seja, cada vez que uma fase completada, o desenvolvimento
prossegue para a prxima fase e no h retorno.

2.4.2. Prototipao
Durante a dcada de 80, as experincias prticas negativas com o modelo cascata
levaram a um modelo completamente diferente: o modelo iterativo (tambm chamado
como abordagem de prototipao). Esta estratgia alternativa comea com a premissa
que o desenvolvimento de sistema pode comear com informao incompleta e que
equisitos completos so obtidos atravs de um processo cclico e dialtico de reaes do
usurio no prottipo. O importante nesta abordagem que o ponto de vista orientado a
projeto enriquecido com o aumento de interesse da participao do usurio final
(IBM, 2001).

2.5. Modelo de Processo de Software Evolucionrio


Estudos mostraram que o software, como todos os sistemas complexos, evoluem
durante um perodo de tempo e os requisitos do negcio e do produto mudam
frequentemente a medida que o desenvolvimento prossegue dificultando um caminho
direto para um produto final (Pressman, 2002).
Os modelos evolucionrios, que sero citados frente, so interativos e caracterizam-se
pela forma como desenvolve-se verses cada vez mais completas do software.

2.5.1. Espiral
O modelo espiral ... foi desenvolvido para abranger as melhores caractersticas tanto do
ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo
elemento a anlise de riscos que falta a esses paradigmas. O modelo (...) define
quatro importantes atividades representadas por quatro quadrantes:
1. Planejamento: determinao dos objetivos, alternativas e restries.
2. Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos.

3. Engenharia: desenvolvimento do produto no nvel seguinte.


4. Atualizao feita pelo cliente: avaliao dos resultados da engenharia.
(...) Ele usa uma abordagem evolucionria engenharia de software, capacitando o
desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O
modelo espiral usa a prototipao como um mecanismo de reduo de riscos, mas, o que
mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipao
em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos
sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura
iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma
considerao direta dos riscos tcnicos em todas as etapas do projeto e, se
adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos
(Pressman, 1995).

2.5.2. Incremental
Peters cita que o modelo de processo de software incremental foi proposto pela
European Space Agency em 1991 e semelhante ao cascata. Os requisitos e conceitos
de software e sistema so primeiramente identificados e, em seguida, as demais
atividades do desenvolvimento de software so repetidas cada vez que h uma nova
verso do software. O modelo incremental parte do pricpio irreal de que o sistema, bem
como os requisitos de software, permanecem estveis. Porm, os requisitos tendem a
evoluir devido a mudanas na tecnologia e experincia (feedback relativo a uma verso
operacional do sistema)(Peters, 2001).

2.5.3 Desenvolvimento baseado em componentes


Pressman (Pressman, 2002) no define o que um componente e restringe-se a dizer
que o modelo de desenvolvimento baseado em componentes utiliza paradigma de
orientao a objetos baseando-se em uma classe como cdigo reutilizvel, ou seja, o
componente.
Em orientao a objetos uma classe encapsula dados e algoritmos e este ltimo tambm
pode ser usado para manipular os dados.
Sua explanao (Pressman, 2002) caracteriza esse modelo como incorporador do
modelo espiral com uma abordagem iterativa para a criao de software. Atravs desta
abordagem uma biblioteca de classes construda com as classes identificadas no
desenvolvimento do software e a partir de ento toda iterao da espiral dever verificar
o contedo da biblioteca que pode ser reutilizado ou identificar se novas classes devem
ser inseridas na biblioteca para posterior reuso.

3. Rational Unified Process (RUP)


Booch, Raumbaugh e Jacobson propuseram a UML como uma notao de modelagem
orientada em objetos, independente de processos de desenvolvimento. Alm disso,
propuseram o Processo Unificado Rational (Rational Unified Process - RUP), que
utiliza a UML como notao de uma srie de modelos que compem os principais

resultados das atividades de uma metodologia. O RUP descente de mtodos anteriores


propostos pelos propositores da UML (Paula, 2001).

3.1 Definio
Krutchen (Krutchen, 2003) afirma que, embora o RUP sugira um processo, ele pode ser
considerado como :
uma abordagem de desenvolvimento de software que interativa, centrada na
arquitetura e dirigida por casos de uso, ou seja, levantamento de requisitos
baseados na viso do usurio.
um processo de engenharia de software bem definido e bem estruturado. Ele
claramente define quem o responsvel pelo que, como as coisas so feitas e
quando faze-las.
um produto processo que fornece um framework de processo customizvel para
a engenharia de software. Essas customizaes podem ser feitas para suportar
pequenas equipes e abordagens disciplinadas ou menos formal para o
desenvolvimento. Esse produto fornecido pela Rational.

3.1.1 Uma abordagem de desenvolvimento


Dentro deste contexto, RUP utiliza pequenos ciclos do projeto (mini-projetos), que
correspondem a uma iterao e resultam em um incremento no software. Iteraes
referem-se a passos, e incrementos a evolues do produto (CITS,2003). Porm seu
ciclo de vida basicamente uma espiral convencional (Graham, 2001) e a abordagem
incremental, conforme definio do prprio RUP, qualifica uma estratgia de
desenvolvimento iterativo na qual um sistema construido adicionando mais e mais
funcionalidade a cada iterao (RUP, 2002).
A abordagem de desenvolvimento dirigida por casos de uso controlados atravs do
gerenciamento de projetos apresenta um importante papel no processo como um todo
pois atravs deles possvel o controle, medio e planejamento das tarefas durante
todo o processo evitando os problemas que ocorriam nos modelos de processo de
prototipao e incremental.

4. Concluso
O Rational Unified Process (RUP) sob o ponto de vista de uma abordagem de
desenvolvimento pode ser considerado como uma unio de vrios conceitos que foram
evoluidos durante toda a histria da engenharia de software. Conceitos estes
organizados e agregados para a viabilidade de produo de software com qualidade,
prazo e custos.

Вам также может понравиться