Rational Unified Process

(1)

Engenharia de Software

Prof. Flávio de Oliveira Silva, Ph.D.

Rational Unified Process

Processo



Define quem irá fazer o que, quando, e como a fim de alcançar um objetivo.

Requisitos novos Sistema novo

Processo de Engenharia

(2)

Engenharia de Software

Detalhamento de Processos



Objetivos



Prover um guia para as atividades



Especificar que artefatos e quando devem ser desenvolvidos



Direcionar as tarefas dos grupos e indivíduos



Oferecer um critério para monitorar e medir o processo

Melhores Práticas

 Desenvolver software iterativamente

 Gerenciar requisitos

 Usar arquiteturas baseadas em componentes

 Modelar o software visualmente

 Verificar continuamente a qualidade do software

 Controlar as alterações no software

(3)

Engenharia de Software

RUP

 Um processo de engenharia de software

 Um framework para outros processos

 Utiliza as melhores práticas de desenvolvimento de software

RUP x Casos de Uso

 RUP é dirigido por caso de uso (use-case driven)

 Casos de uso dirigem numerosas atividades



Criação e validação dos modelos de projeto



Definição dos casos de teste

(4)

Engenharia de Software

RUP x Arquitetura

 RUP é centrado na arquitetura

 A arquitetura é central em relação aos esforços



Os requisitos são analisados para montar uma arquitetura



A arquitetura orienta a implementação e mudanças

RUP

Logical View

Implemation View

Process View

Deployment View Use-Case

View Usuário Final

Funcionalidade

Analistas/Testadores Comportamento

Integradores de Sistema

Programadores

Gerenciamento de Software

Engenharia de Sistemas

(5)

Engenharia de Software

RUP

estabelecidos lógica do domínio

da aplicação e escopo do projeto

RUP

coleta de requisitos mais detalhados,

análise e plano para construção do sistema

(6)

Engenharia de Software

RUP

Várias iterações para

produção do sistema

RUP

Várias iterações para

produção do sistema

(7)

Engenharia de Software

RUP

^teste,ajuste de performance e

treinamento de usuário

RUP

(8)

Engenharia de Software

RUP

Desenvolvimento Iterativo



Análise do Risco

Desenvolvimento em

Cascata Desenvolvimento

Iterativo

(9)

Engenharia de Software

Desenvolvimento Iterativo

Teste Modelagem

de Negócio

Requisitos

Análise & Projeto

Deployment

Avaliação

Implementação

Desenvolvimento Iterativo



Vantagens



Os riscos são atacados mais cedo



Mudanças nos requisitos são absorvidas mais rapidamente



Refinamento de arquitetura



Aprendizado e aprimoramento



Aumento do reuso

(10)

Engenharia de Software

Gerência de Requisitos



Dificuldades



Requisitos não são óbvios



Requisitos não são sempre facilmente expressos em palavras



Existem vários tipos de requisitos em diferentes níveis de detalhes



O número de requisitos pode explodir



Requisitos estão interligados



Existem várias pessoas interessadas nos requisitos



Requisitos mudam.



Atacando



Analisando o problema



Entendendo as necessidades dos

“stakeholders”



Definindo o sistema



Gerenciando o escopo do projeto



Refinando a definição do sistema



Gerenciando mudança de requisitos

Arquitetura Baseada em Componentes



Suporte ao Desenvolvimento Baseado em Componentes



Com o processo iterativo



Baseado na arquitetura



Através da UML - com pacotes, camadas e subsistemas



Testes graduais

(11)

Engenharia de Software

Gerência de Mudanças

Conceitos Chave

(12)

Engenharia de Software

Elementos do RUP



Workflow



Workers ou Papel



Atividades



Artefatos

Elementos do RUP

Descrever um Caso de Uso Responsável por

Analista

Artefato Worker

Papel

desempenhado por um indivíduo ou

grupo Atividade

Unidade de trabalho

(13)

Engenharia de Software

Disciplinas



Workflow de atividades correlatas



Alguns elementos, como risco e testes, são introduzidos em diferentes disciplinas



Relação entre disciplina e modelos

Disciplinas

(14)

Engenharia de Software

Workflow



Sequência de atividades que

produzem um resultado de valor observável



Geralmente expresso em um diagrama de atividade



Organização



Cada disciplina tem seu Workflow

Workflow

Modelo de Projeto realizado pelo

implementado pelo

Requisitos

Implementação

Modelo de Caso de Uso

Modelagem de Negócio

verificado pelo Modelo de Negócio

Análise &

Projeto

(15)

Engenharia de Software

Detalhes de Workflow



As atividades não são feitas em sequência



Mostra os

artefatos

necessários

e os

(16)

Engenharia de Software

Workers - Papel

Workers – Aparecem em Detalhes

de Workflow

(17)

Engenharia de Software

Atividade



Unidade de trabalho com um propósito claro



Utilizado para planejamento e verificação de progresso



Passos



Planejando



Executando



Revisando

Atividade

 Exemplos:



Identificar casos de uso e atores

 Worker: Analista de Sistemas



Revisar o projeto

 Worker: Revisor de Projeto



Executar teste de desempenho

 Worker: Testador de desempenho

(18)

Engenharia de Software

Atividade



A atividade Find use case and actors se decompõe nos passos:



Identificar os atores



Identificar os casos de uso



Descrever a interação entre os atores e uc



Organizar em pacotes



Apresentar o modelo em um diagrama



Avaliar os resultados

(19)

Engenharia de Software

Artefatos



Unidade produzida por uma atividade



Pode assumir as formas:



Modelo (UML Model)



Elemento de Modelo (Ator)



Documento (Visão)



Código (Componente)

Artefatos

(20)

Engenharia de Software

Artefatos



Mantidos por controle de versão



Artefatos não são somente documentos



Guias e checkpoints



Fornecem uma referência de como fazer



Permitem verificar a qualidade do artefato

Artefatos

 Templates



Documento de visão (MS Word)

 Exemplos



Modelo (Modelo de Caso de Uso, de Projeto, etc)



Documento (Documento da Arquitetura do Software)



Código-Fonte



Executáveis

(21)

Engenharia de Software

Documentos



Documentos de Visão



Documentos de Risco



Documentos de Análise de Negócio (Processo)

Tool Mentors



Guiam a execução das atividades em uma ferramenta



Ex:

Documenting the Deployment

Model Using Rational Rose

(22)

Engenharia de Software

Fundamentos

Visão

 Concordar com o problema a ser resolvido

 Identificar os stakeholders

 Definir os limites do sistema

 Identificar as restrições



Políticas



Econômicas



Ambientais



Praticabilidade



Sistema

(23)

Engenharia de Software

Visão



Formular a expressão do problema



O problema <descrição do problema>



Afeta <os stakeholders afetados>



O impacto deste é <qual é o impacto do problema>



Uma solução adequada poderia <lista de beneficios>

Planejamento



Plano de desenvolvimento de software



Bom entendimento do que vai ser criado



Plano da Fase: granularidade alta



Plano de Iteração: granularidade baixa

(24)

Engenharia de Software

Riscos

 Definição: é uma variável que pode obter um valor que dificulte ou até mesmo torne o desenvolvimento inviável

 Tipos



Risco direto



Risco indireto

 Atributos



Probabilidade de ocorrência



Impacto no projeto

Riscos

 Investigando e avaliando riscos



Identificar os riscos



Analisar e priorizar os riscos



Definir estratégias de evasão



Definir estratégias de ataque



Definir estratégias de contingência



Indicadores



“Plano B”



Rever os riscos durante a iteração



Rever os riscos no final da iteração

(25)

Engenharia de Software

Tipos de Riscos



Riscos de Requisitos



Riscos Tecnológicos



Riscos de Habilidades



Riscos Políticos

Riscos de Requisitos



Ponto inicial do processo de desenvolvimento: Casos de Uso (interação típica que o usuário tem com o sistema)



Esboçar esqueleto do modelo conceitual do domínio – Modelo de domínio.



Fornece muita compreensão. Ponto inicial para construção de classes



Encontrar detalhes importantes e se concentrar neles



Construção de Protótipo

(26)

Engenharia de Software

Riscos Tecnológicos



Construir um protótipo que experimente as partes da tecnologia que você está pensando em utilizar



Como os componentes do projeto se encaixam



Dificuldade de serem modificados

Riscos de Habilidades

 Treinamento é um bom modo de evitar erros

 Bom instrutor

 Treinamento em pequenas porções

 Se não puder ter consultores, faça revisões de tempo em tempo

 Leitura e grupos de estudo

(27)

Engenharia de Software

Riscos Políticos



Política Corporativa



Planos de governo

Riscos

“Quem estiver primeiro no campo de batalha e

esperar a aparição do inimigo estará descansado para o combate; quem vier depois e tiver de apressar-se, chegará exausto.”

Sun Tzu

(28)

Engenharia de Software

Business Case



Plano econômico para realizar a Visão, isto é, saber se o projeto vale a pena.



Avaliação do ROI (Return On Investment)

Arquitetura



Artefato: Software Architecture Document



Quais são os componentes?



Como os componentes se encaixam?



Existe algum framework?



Visões arquiteturais

(29)

Engenharia de Software

Arquitetura

Visão Lógica

Usuário final Funcionalidade

Visão de Processo

Visão de Implementação

Visão de

“Deployment”

Visão de Casos de Uso

Integradores Performance Escalabilidade

Engenharia Topologia Instalação Programadores

Gerenciamento de Software

Prototipagem



Iterativamente e incrementalmente criar versões do sistema.



Verificação dos requisitos



Redução de riscos

(30)

Engenharia de Software

Avaliação Regular



Foco nos problemas no processo e os problemas no produto

Mudanças



Artefato: Change Request



Provê um histórico das mudanças e das decisões tomadas



Gerenciar o escopo do projeto



Avaliar o impacto das decisões

(31)

Engenharia de Software

Suporte do Usuário



Criar um produto utilizável



Manuais, ajuda e treinamento

Processo



Adotar um processo que se encaixa ao projeto



A produção de artefatos varia de projeto a projeto

(32)

Engenharia de Software

Conclusões

 Sem visão?



O projeto pode perder escopo ou desviar do propósito

 Sem processo?



A equipe pode perder a visão de quem esta fazendo o que e quando

 Sem planejamento?



Você perde a capacidade de rastrear o progresso

Conclusões

 Sem controle de riscos?



Você pode focar no ponto errado e pisar em “minas”

 Sem Business Case?



Você corre-se o risco de jogar tempo e investimento fora

 Sem arquitetura?



Podem ocorrer problemas com escalabilidade, falso reuso

e performance

(33)

Engenharia de Software

Conclusões

 Sem prototipagem?



Como você e o usuário saberão que o sistema funciona?

 Sem avaliação?



Tenha coragem e enfrente a verdade!

 Sem Change Request?



Como rastrear, priorizar os pedidos do cliente

 Sem suporte do usuário?



Como o usuário vai obter informação sobre o sistema?

Estrutura de processo: Duas Dimensões



A primeira dimensão representa o aspecto dinâmico do processo como é ordenado, e é expresso em termos de ciclo, fases, iterações e marcos.



A segunda dimensão representa o aspecto estático do processo:

sua descrição em

termos de

(34)

Engenharia de Software

tempo

Inception Elaboration Construction Transition

Fases

Inception Elaboration Construction Transition

Iteração

#1 … Iteração … …

#n

Iteração

#n+1 Iteração

#m

Iteração

#m+1 Iteração

Prelim.

Fases e Iterações

(35)

Engenharia de Software

Estrutura dinâmica



Desenvolvimento Iterativo

R D

C T

Uma Iteração

R D

C T

R D

C T

R D

C T

R: Análise de exigências

D: Projeto C: Código, Teste de unidade D: Integração

Lifecycle Objectives

Lifecycle

Architecture Initial Operational Capability tempo

Inception Elaboration Construction Transition

Milestone (Marco)

(36)

Engenharia de Software

Inception (Iniciação )

 Estabelecer o escopo e os limites, com critérios de aceitação bem definidos

 Discriminar os casos de usos críticos

 Exibir uma arquitetura candidata

 “Adivinhar” o custo e o calendário

 Preparar o ambiente do projeto

Iniciação - Milestone



Examina os objetivos e decide seguir ou cancelar o projeto - Viabilidade



Critério de avaliação



Entendimento e acordo com os requisitos



Credibilidade do custo/tempo



Acerto das prioridades

(37)

Engenharia de Software

Iniciação - Milestone



Produtos:



Visão geral dos requisitos do projeto:

 Modelo de Caso de Uso inicial (10-20%)



Estimativa dos recursos necessários



Mini Mundo

Elaboração

 Assegurar que os requisitos e planos estão estáveis

 Estabelecer uma arquitetura

 Provar que a arquitetura funciona

(38)

Engenharia de Software

Elaboração



Deve terminar em torno de um quinto do tempo do projeto



Desenvolvedores já sentem a vontade para dar estimativas de tempo



Todos os riscos significativos foram identificados

Elaboração - Milestone

 Examina os objetivos, arquitetura e riscos do projeto

 Critério de avaliação



Requisitos, visão e arquitetura estáveis



Verificar que, com os protótipos, todos os riscos

(39)

Engenharia de Software

Elaboração - Milestone



Todos o Stakeholders concordam que a visão atual pode ser alcançada se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual ?



Produtos:



Modelo de Caso de Uso (80%)



Plano de desenvolvimento



Avaliação revisada dos riscos



Protótipo da arquitetura

Construção



Atingir qualidade o mais breve possível



Desenvolver incrementalmente e lançar as versões de teste (alpha, beta)



Completar o desenvolvimento de todos os Casos de Uso

(40)

Engenharia de Software

Construção



Estabelecer(detalhar) as iterações e definir que funcionalidades entregar em cada uma delas



Casos de Uso com maior prioridade e/ou risco de desenvolvimento primeiro



Cada iteração é um mini-projeto: Análise, projeto,codificação, teste e integração



As iterações são incrementais na função Integração contínua

Construção - Milestone

 Sistema e manual

 Critério de avaliação



O sistema já esta maduro o suficiente pra ser entregue?



Os stakeholders estão prontos para usá-lo?

(41)

Engenharia de Software

Construção - Milestone

 Produtos:



Modelo de Caso de Uso e de Projeto completos



Manual do usuário



O software integrado e pronto para a utilização dos usuários

Transição



Teste de validação



Conversão do ambiente para produção



Treinamento de usuários e manutenção



Otimização



Alcançando auto-suporte do usuário

(42)

Engenharia de Software

Transição - Milestone

 Os objetivos foram cumpridos

 Coincide com o fim da fase de concepção de outro ciclo

 Critério de avaliação



O usuário está satisfeito



Despesas reais versus planejadas continuam aceitaveis?

Transição - Milestone



Produtos:



Versão final do produto



Manual do usuário atualizado



Modelos atualizados

(43)

Engenharia de Software

RUP – Detalhando os Workflows

Gerência do Projeto Ambiente Modelagem do Negócio

Implementação Teste Análise & Projeto

Preliminary Iteration(s)

Iter.

#1

Fases Core Workflows

Iterações Workflows de Suporte

Iter.

#2 Iter.

#n Iter.

#n+1 Iter.

#n+2 Iter.

#m Iter.

#m+1

Deployment

Ger. de Configuração Requisitos

Elaboration Transition

Inception Construction

Tempo Workflows de Engenharia

O Fluxo de Modelagem de Negócios

Proposta



Entender a estrutura dinâmica da organização na qual um sistema será distribuído.



Entender os problemas atuais na organização alvo e identificar potenciais melhorias



Derivar exigências de sistema necessárias para o suporte da

organização alvo.

(44)

Engenharia de Software

Notação para a modelagem do negócio



Usuários empresariais.



Os processos empresariais são representados por casos de uso de negócio e realizações de caso de uso empresarial.



O papel que as pessoas exercem numa organização é representado por trabalhadores empresariais.



As “coisas” que uma organização administra ou produz são representadas através de entidades empresariais.

O Fluxo de Modelagem de Negócios

Cenários de Modelagem de Negócios



Organograma



Modelagem de domínio



Um negócio, muitos sistemas



Modelo de negócio genérico



Negócio novo

O Fluxo de Modelagem de Negócios

(45)

Engenharia de Software

Trabalhadores



Analista de Processo de Negócio



Projetista de negócio

Artefatos



O documento de visão empresarial



Um modelo de casos de uso empresarial



Um modelo de objeto empresarial

O Fluxo de Modelagem de Negócios

Modelagem de

Negócios

(46)

Engenharia de Software

RUP – Detalhando os Workflows

Iter.

#1

Fases Core Workflows

Iterações Workflows de Suporte

Iter.

#2 Iter.

#n Iter.

#n+1 Iter.

#n+2 Iter.

#m Iter.

#m+1

Deployment

Tempo Workflows de Engenharia

O Fluxo de Requisitos

 Proposta



Estabelecer e manter acordo com os clientes e outros interessados no que o sistema deveria fazer



Definir os limites do sistema



Fornecer base para cálculo do custo e tempo para desenvolver o sistema

(47)

Engenharia de Software

O Fluxo de Requisitos Requisitos

 Funcionais

 Não-funcionais



Utilidade



Robustez



Desempenho



Suporte



Segurança

O Fluxo de

Requisitos

(48)

Engenharia de Software

O Fluxo de Requisitos

Trabalhadores em Requisitos



Analista de Sistema



Especificador do Caso de Uso

RUP – Detalhando os Workflows

Modelagem do Negócio

Fases Core Workflows

Workflows de Suporte

Deployment

Workflows de Engenharia

(49)

Engenharia de Software

Projeto

Trabalhadores



Arquiteto



Projetista

Artefatos



O modelo de Projeto

O Fluxo de

Análise e Projeto

(50)

Engenharia de Software

RUP – Detalhando os Workflows

Iter.

#1

Fases Core Workflows

Iterações Workflows de Suporte

Iter.

#2 Iter.

#n Iter.

#n+1 Iter.

#n+2 Iter.

#m Iter.

#m+1

Deployment

Tempo Workflows de Engenharia

Fluxo de

Implementação

Proposta:



Implementar classes e objetos em temos de componentes;



Testar os componentes desenvolvidos como unidades;



Integrar em sistema executável os resultados produzidos por

implementadores individuais ou equipes.

(51)

Engenharia de Software

Implementação

Implementação no RUP:



Construções



Integração



Protótipos

Fluxo de

Implementação

Tipos de protótipos:

 Comportamental

 Estrutural

(52)

Engenharia de Software

Implementação



Trabalhadores



Implementador



Integrador do sistema



Arquiteto



Revisor de Código

Fluxo de

Implementação

 Artefatos

 Subsistema de implementação

 Componente

 Plano de construção de integração

(53)

Engenharia de Software

Implementação

RUP – Detalhando os Workflows

Fases Core Workflows

Workflows de Suporte

Deployment Requisitos

Workflows de Engenharia

(54)

Engenharia de Software

Fluxo de Teste

Proposta:



Verificar as interações de componentes;



Verificar a própria integração de componentes;



Verificar que todas as exigências tenham sido implementadas corretamente;



Identificar e assegurar que todos os defeitos descobertos estejam corrigidos antes do software ser distribuído.

 Qualidade

 Dimensões de teste



Dimensão da qualidade



Confiabilidade



Funcionalidade



Desempenho



Estágios do teste



Teste de unidade



Teste de integração

Fluxo de Teste

(55)

Engenharia de Software

Tipos de testes



Padrão



Configurações



Função



Instalação



Integridade



Carregamento



Desempenho



Stress

Fluxo de Teste

 Trabalhadores

 Projetista de teste

 Testador

Fluxo de Teste

(56)

Engenharia de Software

 Artefatos

 Plano de teste

 Resultados de testes Fluxo de Teste

Fluxo

de

Teste

(57)

Engenharia de Software

Proposta:

 Testar o software em seu ambiente operacional final;

 Empacotar o software para entrega;

 Distribuir o software;

 Instalar o software;

 Treinar os usuários finais;

Fluxo de Implantação

Modos de distribuição

 Software em sistemas feitos sobre encomenda

 Software pronto

 Software descarregável pela internet

Fluxo de Implantação

(58)

Engenharia de Software

 Trabalhadores

 Gerente de distribuição

 Gerente de projeto

 Escritor técnico

 Desenvolvedor de curso

 Provador

 Implementador

Fluxo de Implantação

 Artefatos fundamentais

 Software executável

 Artefatos de instalação

 Material de suporte

 Material de treinamento

Fluxo de Implantação

(59)

Engenharia de Software

Implantação

RUP – Detalhando os Workflows

Fases Core Workflows

Workflows de Suporte

Workflows de Engenharia

(60)

Engenharia de Software

Proposta:



Localizar e manter a integridade dos recursos de evolução do projeto;



Os membros da equipe de projeto devem poder identificar e localizar a versão apropriada do artefato;

configuração

 Gerenciamento de configuração

 Gerenciamento de solicitação de mudança

Fluxo de Gerenciamento de

configuração

(61)

Engenharia de Software

 Trabalhadores

 Gerente de configuração

 Gerente de controle de mudança

 Implementadores

 Integradores configuração

 Artefatos

 Planos de gerenciamento de configuração

 Solicitações de mudança

Fluxo de Gerenciamento de

configuração

(62)

Engenharia de Software

RUP – Detalhando os Workflows

Fases Core Workflows

Workflows de Suporte

Deployment

Workflows de Engenharia

(63)

Engenharia de Software

Projeto

Propostas

 Fornecer uma estrutura para gerenciar projetos de software intensivos.

 Fornecer diretrizes práticas para planejar, prover pessoal, executar e monitorar projetos.

 Fornecer uma estrutura para gerenciar risco.

Propostas fora do RUP



Administrar pessoal.



Administrar orçamentos.



Administrar contratos com os provedores e clientes.

O Fluxo de Gerenciamento de

Projeto

(64)

Engenharia de Software

O Fluxo de Gerenciamento de Projeto

Propostas RUP



Planejamento de um projeto iterativo pelo ciclo de vida e planejamento de uma iteração em particular.



Administração de risco.



Monitoramento de progresso de um projeto iterativo e medidas.

Como planejar um processo iterativo?

 De quantas iterações eu preciso?

 Quanto tempo elas deveriam ter?

 Como determinar o conteúdo e objetivos de uma iteração?

O Fluxo de Gerenciamento de

Projeto

(65)

Engenharia de Software

Objetivos:



Alocar tarefas e responsabilidades a uma equipe de pessoas.



Monitorar o progresso relativo para o plano e descobrir problemas potenciais conforme o projeto é desenvolvido.

Projeto

Dois níveis de planos



Plano de fase



Datas dos fatos principais



Perfil da provisão de pessoal



Datas dos fatos secundários



Plano de iteração



Datas importantes

O Fluxo de Gerenciamento de

Projeto

(66)