Visão Geral do RUP (Rational Unified Process). Desenvolvimento de software com UML2 Objetivos deste...

Visão Geral do RUP (Rational Unified Process)

Desenvolvimento de software com UML 2

Objetivos deste módulo Apresentar as características do RUP Discutir os conceitos que existem no

RUP: fases, fluxos de atividades (worklows), iterações, responsáveis, atividades e artefatos

Apresentar os fluxos do RUP


RUP e UML O que é o RUP?

Processo Unificado de desenvolvimento de software Diz o quê, quando e por quem, mas não explica como Necessidade a partir do sucesso da UML como padrão

de fato para especificação de software

E UML? Unified Modeling Language Linguagem padrão para modelagem OO Usada para modelar e documentar os artefatos do

desenvolvimento Foi proposta somente como uma linguagem, sem

orientação de uso (i.e., sem um processo)


Alguns diagramas de UML

Diagrama de casos de uso Diagrama de classes

Diagrama de sequência Diagrama de colaboração


Apenas a linguagem não basta

+

++

+


O que é um Processo? Conjunto de atividades a serem realizadas

para construir software ou evoluir um sistema já existente

Define Quem faz O quê, Quando e Como


Processos de Software Definição: “Todos os elementos do mundo

real envolvidos no desenvolvimento e manutenção de um produto de software”

Processos vem sendo propostos pela indústria, países e academia Análise Estruturada (Yourdon, Gane) Método de Jackson Objectory (Jacobson) V-Model (Alemanha) Catalysis Rational Unified Process - RUP XP - eXtreme Programming


Características de um Processo Eficiente

Orienta o desenvolvimento, operação e manutenção de software

Reduz risco e aumenta previsibilidade Utiliza boas práticas de desenvolvimento

de software Permite controle sobre o

desenvolvimento - dentro de custos, prazos e níveis de qualidade desejados

Qualidade x produtividade


Processo Unificado (RUP) Bases históricas:

Processo Espiral Iteratividade Gerência de riscos

Processo Objectory Proposto por Jacobson et al Processo direcionado por Casos de Uso


O que é Processo Unificado Modelo de Processo Padrão

Descrição de atividades que compõem um processo que adota UML Mais simples que a proposta da Rational

Produto comercial Desenvolvido e mantido pela Rational Integrado a uma suíte de produtos Disponível em CD-ROM / Internet

http://psds.portalcorporativo.serpro/rup_portugues/index.htm http://www.labes.ufpa.br/quites/rup/

Conhecido como Rational Unified Process E-coach: treinamento a distância

http://www.rational.com/rup Para o treinamento online, clicar em “Trials & Betas”


Características do RUP

Usa UML Baseado em componentes Framework para processos

Orientado a casos de uso Iterativo e incremental Centrado na arquitetura


Orientado a Casos de uso

O que é um caso de uso? Usados para capturar os requisitos funcionais

do sistema “Falam” a “linguagem do usuário” Estão sempre associados a um ator

Representação de uma funcionalidade do sistema, que fornece um resultado de

valor para um usuário


Orientado a Casos de uso

Por que o RUP é orientado a casos de uso? Casos de uso são usados para especificar requisitos Durante a análise, projeto e implementação os

casos de uso são “realizados” Durante os testes, verifica-se se o sistema realiza o

que está descrito no Modelo de Casos de Uso Casos de uso são usados no planejamento e

acompanhamento das iterações


Iterativo e Incremental

Tempo

RA/P

I/TI

R RA/P A/P

I/T I/TI I

R A/P I/T I

Fonte: Rational


Iterativo e Incremental

Dividir para conquistar! O desenvolvimento ocorre em várias

iterações, cada uma delas resultando em extensão de funcionalidade e/ou maior conhecimento do sistema

Os maiores riscos devem ser tratados nas primeiras iterações


Centrado na Arquitetura Estimula a definição de

uma arquitetura robusta nas fases iniciais do desenvolvimento

A arquitetura guia o projeto e implementação das diversas partes do sistema Os casos de uso dizem o que deve ser feito e a arquitetura descreve como


Visão de Distribuição

Visão Lógica

Visão de Implementação

Visão de Processo

Visão 4+1VISÃO LÓGICA

Descreve as principais classes no projeto do sistema: classes relacionadas aos principais negócios e classes que definem os principais mecanismos estruturais e comportamentais (persistência, comunicações, tolerância a falhas, interface do usuário).

VISÃO DE IMPLEMENTAÇÃODescreve a organização dos elementos estáticos do software (código, dados e outros artefatos que os acompanham) no ambiente de desenvolvimento em termos de empacotamento, divisão em camadas e gerenciamento de configuração (propriedade, estratégia de release e assim por diante).

VISÃO DE IMPLANTAÇÃODescreve uma ou várias configurações do sistema. É o mapeamento de componentes de software (tarefas, módulos) para os nós de computação nessas configurações.

VISÃO DE PROCESSODescreve o aspecto simultâneo do sistema: tarefas (processos) e suas interações

Casos de Uso


“Espírito” do RUP O gerenciamento de Riscos deve

ser feito continuamente A cada iteração (novos) riscos devem

ser identificados e tratados; Isto “garante” que o desenvolvimento

terá sucesso;


“Espírito” do RUP Foco em Funcionalidades para o

Cliente Especificação, organização e

documentação dos requisitos é facilitada através dos diagramas de casos de uso;

Casos de uso guiam todo o processo de desenvolvimento

O que desenvolver, testar e validar em cada iteração;

Casos de uso são funcionalidades para o cliente;


“Espírito” do RUP

Foco em Software Executável Artefatos são construídos para facilitar e

documentar o processo de desenvolvimento;

Mas, não é necessário construir todos os artefatos indicados pelo RUP;



Aprenda a lidar com Mudanças Mudanças são inevitáveis no processo de

desenvolvimento; Adote estratégias para gerenciar

mudanças Tomada de decisão sobre uma mudança; Impacto desta mudança no sistema; Minimizar o custo desta mudança;



Defina uma Arquitetura estável cedo Uma arquitetura do sistema é definida,

implementada e testada no início do processo (Elaboração) para garantir que o sistema atenderá aos requisitos funcionais e não-funcionais;

Com a arquitetura definida, o processo de construção é mais simples;



Considere continuamente a Qualidade O controle de qualidade deve ser feito

desde o início do processo de desenvolvimento

Inspeção de software; Teste dos casos de uso implementados; Definição de casos de teste a partir dos casos

de uso;



Desenvolvimento Iterativo “Impossível” desenvolver o sistema em

uma única iteração; A cada iteração mais detalhes são

adicionados; Diversas vantagens:

Redução da Complexidade; Facilidade para lidar com mudanças nos

requisitos, cronograma, etc.


Conceitos do RUP

Fases e Iterações Fluxos de Atividades Atividades Artefatos Responsáveis


Estrutura do RUP Processo Iterativo, baseado no modelo

Espiral Iterativo: baseado em sucessivas versões Espiral


Fases do RUP

Concepção Elaboração Construção Transição Estabelecer o

escopo e viabilidade

econômica do projeto

Eliminar principais

riscos e definir arquitetura

estável

Desenvolver o produto até

que ele esteja pronto para beta testes

Entrar no ambiente do

usuário


Fases e Iterações

Cada fase pode comportar diversas iterações

Concepção Elaboração Construção Transição

tempo

Iteração preliminar 1 2 i i+2 i+3 ... j j+1 ...

grandes marcos


Concepção Elaboração Construção Transição

Marco dos objetivos

do ciclo de vida

Marco da arquitetura do ciclo de

vida

Marco da capacidade operacional

inicial

Marco de lançamento do produto

tempo

Marcos

O projeto poderá ser anulado ou completamente repensado caso o marco

não seja atingido.


Fluxos de Atividades do RUP Agrupam atividades correlacionadas Fluxos de atividades básicos:

modelagem do negócio requisitos análise e projeto implementação testes distribuição

Fluxos de atividades de suporte: gerência de configuração e mudanças gerência do projeto configuração do ambiente


Fases, Iterações e Fluxos de Atividades

Fonte: Rational


Responsáveis, Atividades e Artefatos

Os fluxos de atividades do RUP são descritos através de responsáveis, atividades e artefatos

Fonte: Rational


Conceitos-chave


Modelagem do Negócio

Objetivos: descobrir “o problema por trás do

problema” entender a estrutura e dinâmica da

organização assegurar que os clientes, usuários e

desenvolvedores têm a mesma visão do negócio

descobrir os requisitos do sistema necessários para suportar o negócioDesenvolver um modelo do negócioDesenvolver um modelo do negócio


Modelagem do Negócio

Glossário Modelo de

Casos de Uso do Negócio

Modelo de Objetos do Negócio

Fonte: Rational


Requisitos

Objetivos: descrever o quê o sistema deve fazer, em

acordo com o cliente e usuários definição de como gerenciar escopo e

mudanças de requisitos delimitar o escopo do sistema e prover uma

base para o planejamento das iterações definir a interface com o usuário


Requisitos

Glossário Documento de

Visão Especificações

Suplementares Modelo de

Casos de Uso Protótipo da

Interface com o Usuário


Análise e Projeto

Objetivos: transformar os requisitos em um modelo para

implementação do sistema encontrar uma arquitetura robusta para o

sistema

Análise: assegura que os requisitos funcionais são

tratados

Projeto: adapta os resultados da análise aos requisitos

não funcionais e ambiente de implementação


Análise e Projeto

Fonte: Rational


Implementação Objetivos:

implementar os componentes necessários testar os componentes implementados

como unidades integrar os componentes implementados

em um sistema executável


Implementação

Modelo de Implementação

Componentes implementados

Subsistemas implementados

Fonte: Rational


Testes

Objetivos: verificar a interação e integração dos

componentes verificar se todos os requisitos foram

corretamente implementados identificar defeitos e assegurar as

correções de acordo com as prioridades de entrega de cada componente


Testes

Plano de Teste Modelo de Teste Casos de Teste Procedimentos de

Teste Lista de defeitos Avaliação dos

Testes

Fonte: Rational


Distribuição

Objetivo: entregar o produto aos usuários finais

Muito dependente do contexto do negócio e do projeto => precisa ser configurado


Distribuição Possíveis atividades:

produzir o (que falta do) software scripts de instalação, documentação para o usuário,

programas para conversão de dados, etc. embalar e distribuir o software instalar o software realizar migração

troca de sistema antigo pelo novo, conversão de dados

treinamento do usuário aceitação formal pelo cliente planejamento e condução de beta testes


Gerência de Projeto Objetivos:

prover um framework para gerenciar projetos e riscos

prover orientações para o planejamento de atividades, definição da equipe, execução e monitoração de projetos

Planejamento e monitoração das iterações!Planejamento e monitoração das iterações!


Gerência de Projeto

Plano de Negócios

Plano do Desenv. do Software:

• plano de métricas• lista de riscos• plano do projeto• plano da iteração

Fonte: Rational


Gerência de Configuração e Mudanças

Objetivos: identificar, definir e manipular itens de

software controlar modificações e versões destes

itens reportar e armazenar a situação dos itens e

as solicitações de mudanças garantir a completude, consistência e

corretude dos itens controlar o armazenamento, manipulação e

entrega destes itens


Gerência de Configuração e Mudanças

Plano de gerência de configuração

Fonte: Rational


Configuração do Ambiente Objetivo:

prover o processo e as ferramentas necessárias ao desenvolvimento

Possíveis Atividades: configurar o RUP desenvolver guidelines selecionar e adquirir ferramentas adaptar ou desenvolver ferramentas suportar o ambiente de desenvolvimento

(backups, administração de contas, etc.) treinamento implantação do RUP na organização


Configuração do Processo

Processo para um projeto x Processo para a organização

Processo para um projeto considerar tamanho, reuso, tipo do ciclo

(inicial x de evolução)

Processo para a organização considerar cultura, pessoas, tecnologias e

aplicações chave, ...


Análise Estruturada Proposta por uma diversidade de

autores nas décadas de 1980 e 1990 Fundamentação:

Programação Estruturada Estruturas de repetição, decisão e seqüência

Projeto Estruturado Principal mecanismo de abstração:

decomposição funcional Ciclo de Vida Cascata

Processo Seqüencial Linear


Marco dos Objetivos do Ciclo de Vida

Análise dos objetivos do ciclo de vida do projeto e tomada de decisão de prosseguir com o projeto ou cancelá-loCritérios de Avaliação

Consentimento dos envolvidos sobre a definição do escopo e as estimativas de custo/programação.

Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma compreensão compartilhada desses requisitos.

Consenso de que as estimativas de custo/programação, as prioridades, os riscos e o processo de desenvolvimento são adequados.

Todos os riscos foram identificados e existe uma estratégia atenuante para cada um.


Marco da Arquitetura do Ciclo de Vida

Exame nos objetivos e o escopo do sistema, a opção de arquitetura e a resolução dos principais riscos.Critérios de Avaliação

A Visão e os requisitos do produto são estáveis. A arquitetura é estável. As abordagens principais a serem usadas no teste e na

avaliação foram comprovadas. O teste e a avaliação de protótipos executáveis

demonstraram que os principais elementos de risco foram tratados e resolvidos com credibilidade.

Os planos de iteração para a fase de construção têm detalhes e fidelidade suficientes para permitir o avanço do trabalho. Os planos de iteração para a fase de construção são garantidos por estimativas confiáveis. Todos os envolvidos concordam que a visão atual poderá ser atendida se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual. A despesa real em oposição à despesa planejada com recursos é aceitável.


Marco da capacidade operacional inicial

Produto pronto para ser passado para a Equipe de Transição.

Toda a funcionalidade desenvolvida e os testes alfa (se houver algum) foram concluídos.

Manual do usuário desenvolvido e uma descrição do release atual.Critérios de Avaliação

Envolvem respostas para as questões: Este release do produto é estável e desenvolvido o suficiente

para ser implantado na comunidade de usuários? Todos os envolvidos estão prontos para a transição para a

comunidade de usuários? As despesas reais com recursos ainda são aceitáveis se

comparadas com as planejadas?


Marco do Release do Produto Decisão se os objetivos foram

atendidos e se outro ciclo de desenvolvimento deve ser iniciado.

Pode coincidir com o fim da fase de iniciação do próximo ciclo.

O Marco do Release do Produto é o resultado da conclusão com êxito dos Artefatos

Visão Geral do RUP (Rational Unified Process). Desenvolvimento de software com UML2 Objetivos deste...

Documents

Transcript of Visão Geral do RUP (Rational Unified Process). Desenvolvimento de software com UML2 Objetivos deste...