visão geral do rup (rational unified process) - …bacala/mds2011/mds3.pdf · apresentar as...

Visão Geral do RUP (Rational Unified Process)

Desenvolvimento de software com UML2

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 Proc esso Padrão

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

Produt o c om erc ia l 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”

http://psds.portalcorporativo.serpro/rup_portugues/index.htm















http://www.labes.ufpa.br/quites/rup/











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;


“Espírito” do 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;


“Espírito” do RUP 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;


“Espírito” do RUP 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;


“Espírito” do RUP 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ócio

Desenvolver 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

TestesFonte: 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) - …bacala/mds2011/mds3.pdf · apresentar as...

Documents