RUP

RATIONAL UNIFIED

PROCESS

PRÁTICAS RECOMENDADAS

Prof. Fabiano Papaiz

IFRN

O RUP recomenda as seguintes práticas que devem ser

utilizadas no desenvolvimento de um software:

1. Desenvolver de forma iterativa e incremental

2. Gerenciar os requisitos

3. Utilizar arquitetura de componentes

4. Modelar visualmente

5. Verificar continuamente a qualidade do software

6. Gerenciar as mudanças

RUP – RATIONAL UNIFIED PROCESS

1ª

Desenvolver de forma

Iterativa e Incremental

RUP – RATIONAL UNIFIED PROCESS

Desenvolver de forma iterativa e incremental permite:

Que qualquer mudança seja acomodada mais facilmente durante o desenvolvimento do projeto

A cada incremento gerado, podemos adaptar os requisitos a quaisquer mudanças que possam ocorrer nesse meio tempo

Na pior dos casos, a equipe “perderia” o trabalho realizado em uma ou duas iterações, em vez do trabalho do projeto inteiro

Que os riscos sejam diminuídos progressivamente

A cada release do software, os riscos são diminuídos pois os requisitos são validados pelo cliente e as novas funcionalidades são integradas na arquitetura, permitindo que esta se torne cada vez mais confiável e robusta

A cada iteração são realizados refinamentos sucessivos para melhorar o entendimento do problema

RUP – RATIONAL UNIFIED PROCESS

Desenvolver de forma iterativa e incremental permite:

Melhorar o nosso processo à medida que o software vai

sendo desenvolvido, fazendo os ajustes necessários e

servindo como base para os futuros projetos

Aumentar o reuso, pois conforme os componentes vão

sendo implementados podemos identificar partes comuns

entre eles, como também identificar componentes que já

foram desenvolvidos e que podem ser reutilizados

RUP – RATIONAL UNIFIED PROCESS

RUP – RATIONAL UNIFIED PROCESS

RUP – RATIONAL UNIFIED PROCESS

RUP – RATIONAL UNIFIED PROCESS

2ª

Gerenciar os Requisitos

RUP – RATIONAL UNIFIED PROCESS

Segundo o RUP, um requisito é uma condição ou uma

restrição com a qual o sistema deverá estar em

conformidade

Os requisitos devem ser definidos de forma clara e objetiva,

sem que haja ambiguidade de entendimento

O gerenciamento de requisitos é uma abordagem

sistemática para:

Identificar os requisitos,

Documentar os requisitos,

Organizar e Controlar os requisitos

Não basta apenas identificar e documentar os requisitos, temos que

garantir que a documentação esteja sempre atualizada à medida que

as mudanças ocorrerem

RUP – RATIONAL UNIFIED PROCESS

Devemos gerenciar os requisitos porque nem todos são

simples ou óbvios, como um cadastro de cliente (CRUD)

Podem haver requisitos mais complexos, onde suas

definições venham de várias partes interessadas de

dentro do projeto, podendo haver conflitos entre as partes

Seu projeto pode possuir um número muito grande de

requisitos, os quais podem se tornar impossíveis de se

controlar se não forem gerenciados da forma correta

As mudanças nos requisitos devem ser “rastreadas”, para

podermos analisar o seu impacto nos demais requisitos

Viabilidade, custo, prazo etc

RUP – RATIONAL UNIFIED PROCESS

O RUP recomenda a utilização de Casos de Uso como

método para a organização dos requisitos funcionais do

software projetado

Diagramas de Casos de Uso

Especificações de Casos de Uso

O RUP é Guiado por Casos de Uso e estes serão

utilizados em todas as suas fases e disciplinas

RUP – RATIONAL UNIFIED PROCESS

Os Casos de Uso serão utilizados por diversas partes

interessadas no projeto, como por exemplo:

Clientes

Para terem uma visão geral das funcionalidades do sistema

Arquitetos de Software

Para identificarem as características da arquitetura

Analistas, Projetistas, Desenvolvedores

Para entenderem o comportamento do sistema, analisá-lo,

projetá-lo e implementá-lo

Testadores

Para definirem os casos de testes do sistema

Gerentes de Projeto

Para planejarem e acompanharem o progresso do projeto

RUP – RATIONAL UNIFIED PROCESS

3ª

Utilizar Arquitetura de

Componentes

RUP – RATIONAL UNIFIED PROCESS

Segundo o RUP, a arquitetura de um sistema é a sua

organização (ou estrutura) de componentes significativos

que interagem entre si trocando mensagens através de

suas interfaces

Uma arquitetura não se preocupa apenas com os

requisitos funcionais do software, preocupando-se

também com os requisitos não-funcionais

Desempenho

Segurança

Reuso

Manutenibilidade

Decisões tecnológicas etc

RUP – RATIONAL UNIFIED PROCESS

O RUP define os componentes como sendo grupos

coesos de código fonte ou executável com interfaces e

comportamentos bem definidos

Possuem responsabilidades e funções claras e bem definidas

Devem fornecer forte encapsulamento de conteúdo

Outros componentes não precisam saber seus detalhes

internos de funcionamento. Precisam conhecer apenas sua

interface para poderem trocar mensagens com ele

Podem ser substituídos sem causar impacto na

arquitetura

Exemplo: no caso onde seja necessário mudar a tecnologia de

acessos aos dados de “SQL puro” para o Entity Framework

RUP – RATIONAL UNIFIED PROCESS

Os tamanhos dos componentes podem variar muito

Podem ser desde uma classe apenas até uma biblioteca

(ou API) contendo diversas classes

Podem existir componentes terceirizados, “de prateleira”

(OTS: Off-The-Shelf)

Um módulo de comunicação com operadoras de cartões de

crédito

Servidores de banco de dados

Servidores de aplicações web etc

RUP – RATIONAL UNIFIED PROCESS

Exemplo-01:

RUP – RATIONAL UNIFIED PROCESS

Exemplo-02:

RUP – RATIONAL UNIFIED PROCESS

No RUP a arquitetura é representada por uma série de

visões diferentes, conhecida como Modelo de Visão 4+1. Analogia com Engª Civil: plantas baixa, hidráulica, elétrica etc

RUP – RATIONAL UNIFIED PROCESS

4ª

Modelar Visualmente

RUP – RATIONAL UNIFIED PROCESS

O RUP utiliza a UML (Unified Modeling Language) como

notação padrão para modelagem de software

Com a padronização da linguagem de modelagem visual,

podemos capturar requisitos com maior precisão,

melhorando assim a comunicação entre as partes

interessadas, visando diminuir a ambiguidade no

entendimento do problema

Com a UML, o software pode ser representado em um

nível de abstração mais alto, para ser entendido de forma

mais fácil pelo cliente e usuários, como também em níveis

mais baixos, para entendimento entre a equipe técnica

(analistas, programadores, arquitetos, DBA’s etc)

RUP – RATIONAL UNIFIED PROCESS

5ª

Verificar Continuamente a

Qualidade do Software

RUP – RATIONAL UNIFIED PROCESS

Por que verificar a qualidade?

RUP – RATIONAL UNIFIED PROCESS

O RUP define qualidade como sendo:

“a característica de ter

demonstrado a criação de um produto

que atende ou excede os requisitos

acordados, sendo esse avaliado por

medidas e critérios acordados,

utilizando-se um processo acordado”

RUP – RATIONAL UNIFIED PROCESS

No RUP, podemos buscar a qualidade do software

através de atividades de controle e garantia da qualidade

Controle da Qualidade

Possui foco no PRODUTO e em encontrar seus defeitos

específicos

Garantia da Qualidade

Possui foco nos PROCESSOS e em como estes estão sendo

executados

Visa garantir que as coisas estão sendo feitas seguindo

corretamente a metodologia empregada

RUP – RATIONAL UNIFIED PROCESS

A qualidade pode ser medida segundo vários critérios,

como por exemplo:

Andamento: progresso do projeto

Variação: diferença entre planejado e executado

Confiabilidade: robustez

Funcionalidade: casos de uso implementados

Desempenho: tempo de execução em diversas situações reais

É muito importante que os critérios de qualidade sejam

definidos e acordados pelas partes interessadas no início

do projeto

RUP – RATIONAL UNIFIED PROCESS

6ª

Gerenciar as Mudanças

RUP – RATIONAL UNIFIED PROCESS

Gerenciamento de mudanças é o processo de avaliar,

coordenar e decidir sobre a realização das mudanças

propostas no software projetado

Podem ser solicitadas mudanças em diversos itens,

como:

Funcionalidades, Arquitetura, Código-Fonte, Banco de Dados,

Metodologia, Ferramentas etc

Somente as mudanças aprovadas deverão ser

implementadas

Implica em um processo formal de aprovação de mudanças

Tolerância zero com as mudanças não aprovadas,

principalmente em artefatos que fazem parte da iteração atual

RUP – RATIONAL UNIFIED PROCESS

No RUP, o gerenciamento de mudanças abrange as

seguintes atividades:

Coordenação de Atividades e Artefatos

Definir procedimentos padronizados para gerenciar mudanças

sobre os artefatos

Coordenação de Iterações e Releases

Manter o controle sobre os releases ao final de cada iteração

Controle de Mudanças no Software

Manter uma estrutura bem definida para gerenciar mudanças

no software entregue

RUP – RATIONAL UNIFIED PROCESS

FIM