RUP Rational Unified Proccess (Processo Unificado da Rational)

RUP
Rational Unified Proccess
(Processo Unificado da
Rational)
Equipe WEB Cercomp
[email protected]
1. Introdução



É um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, então o RUP ganhou o nome de IRUP IBM Rational Unified Software (porém o nome mais conhecido ainda é RUP);
Fornece técnicas às equipes de desenvolvimento de software objetivando o aumento da produtividade seguindo uma abordagem prescritiva (normatização);
O RUP se baseia no paradigma de Orientação a Objetos e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos 2
em ação.
1. Introdução



É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos;
Porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala;
Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.
3
1. Introdução

O RUP se baseia nos 4 “P”s:

Pessoas;

Projeto;

Produto;

Processo.
4
2. Linhas Mestras


O RUP define as seguintes linhas­mestras e esqueletos (templates) para os membros da equipe de um ciclo de produção:

Parte do cliente;

Avaliação do progresso do projeto pela sua gerência.
Ajuda os programadores a manterem­se concentrados no projeto.
5
2.1. Gestão de requisitos


Descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio (Uma documentação apropriada é essencial para qualquer grande projeto).
Os casos de uso (Use Cases) e os cenários são exemplos de artefatos (produtos de trabalho finais ou intermediários produzidos e usados durante os projetos) dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais ­ descrição das diversas funções que clientes e usuários querem ou precisam que o software faça.
6
2.1. Gestão de requisitos
7
2.2. Arquitetura baseada em
componentes

Sistema que pode ser facilmente extensível;

Reutilização de software e um entendimento intuitivo;



Um componente normalmente se relaciona com um objeto na programação orientada a objetos;
Arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala;
Estes componentes são normalmente incluídos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objetos).
8
2.3. Software de modelos
visuais



Elaborar de modo efetivo uma maneira de se ter uma visão geral de uma solução;
Melhor entendimento por parte de pessoas com menor conhecimento técnico (ex: cliente) de um dado problema, e assim se envolvam mais no projeto como um todo;
A linguagem de modelagem UML tornou­se um padrão industrial para representar projetos e é amplamente utilizada pelo RUP.
9
2.4. Verificação da
qualidade do software


Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa­se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento;
O RUP visa auxiliar no controle do planejamento da qualidade, verificando­a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.
10
2.5. Gestão e Controle de
Mudanças do Software


Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto;
O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
11
3. Fases


Indicam a ênfase que é dada ao projeto em um momento específico;
Um projeto é dividido em quatro fases:

1. Concepção: ênfase no escopo do sistema;

2. Elaboração: ênfase na arquitetura;

3. Construção: ênfase no desenvolvimento;

4. Transição: ênfase na implantação.
12
3.1. Fase de concepção

Delimitação do âmbito do projeto e do business case¹, afim de que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto.
[1]. Forma profissional de justificar o investimento para aprovar um projeto estratégico que agrega valor ao negócio da empresa. 13
3.2. Fase de Elaboração



Análise da extensão do sistema (ex: problemas a serem resolvidos);
Definição de uma arquitetura estável e robusta para todo o sistema, tendo em consideração os seus requisitos;
Busca complementar o levantamento/documentação dos casos de uso.
14
3.3. Fase Construção


Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa e beta;
Deve­se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline" ­ imagem de uma versão de cada artefato.
15
3.4. Fase de Transição



Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e entrega, acompanhamento e qualidade do software;
Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do cliente;
Nesta fase também é realizada a capacitação dos usuários.
16
4. Processo RUP - Gráfico
17
Referências

Wthreex ­ RUP 2002.05.00 Portugues


http://www.wthreex.com/
Wikipedia – RUP

http://pt.wikipedia.org/wiki/IBM_Rational_Unified_
Process
18