ModelagemProcessoUML1.2Novo

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Clique para editar o estilo do título mestre
Clique para editar o estilo do subtítulo mestre
*
*
*
IBM-Rational Unified Process
RUP
Gustavo Miranda Araújo
Jefferson de Barros Santos
Clique para editar o estilo do título mestre
Clique para editar o estilo do subtítulo mestre
*
*
*
Entendendo o RUP
*
*
*
Histórico UML
UML 2.0
*
*
*
Histórico RUP
Ericsson Approach
*
*
*
USDP (UP) e RUP
Método Booch
OMT
Rumbaugh
Objectory
(OOSE)
Jacobson
USDP
(UP)
RUP
*
*
*
Arquitetura 4+1
Lógica
Processo
Implementação
Física
Caso de Uso
Usuário-Final
Funcionalidades 
Programadores
Gerência do Software
(Subsistemas e Camadas)
Engenheiro de Sistemas
Topologia e Rede
(Mapeamento Software em Hardware)
Integradores
Performance e Escalabilidade
(Componentes)
*
*
*
Unified Process - Características
Orientado a Caso de Uso
Centrado na Arquitetura
Iterativo e Incremental
*
*
*
Rational Unified Process (RUP)
É um processo de Engenharia de Software
É um produto, um software, disponível através de um conjunto de páginas HTML.
É um framework de processo.
É baseado no USDP. 
Além dos elementos do USDP o RUP descreve:
Técnicas e regras para executar atividades e construir artefatos
Normas e padrões para uso de ferramentas
Guias para utilização e adaptação do framework do processo
*
*
*
Foco nas Melhores Práticas
Desenvolver software iterativamente;
Gerenciar requisitos;
Usar arquiteturas baseadas em componentes;
Modelar o software visualmente;
Verificar a qualidade do software continuamente.
Controlar mudanças no software.
*
*
*
Visão Geral
*
*
*
Dimensões
Dimensão horizontal: Representam as fases do desenvolvimento e mostra os aspectos do ciclo de vida a medida que o tempo passa. Aspectos dinâmicos.
Dimensão vertical: Representa as disciplinas centrais do processo as quais agrupam as atividades de engenharia de software por sua natureza. Aspectos estáticos.
*
*
*
Fases
1- Concepção: Entender o problema e garantir que existe uma solução possível e viável.
	Descriminar os casos de uso críticos do sistema
	Apresentar uma arquitetura candidata
	Fazer uma estimativa geral do custo global do projeto
*
*
*
Fases
1- Concepção – Artefatos iniciados na fase
Documento de visão 
Modelo de Caso de Uso
Especificações suplementares
Glossário
Plano de Desenvolvimento de Software
Pasta de Desenvolvimento
*
*
*
Fases
2 - Elaboração: Definir a arquitetura e riscos de requisitos
Compreensão sólida dos casos de uso mais críticos
Elaborar o processo, a infra-estrutura e o ambiente de desenvolvimento
Elaborar a arquitetura e selecionar os componentes 
	
	
*
*
*
Fases
2 – Elaboração – Artefatos refinados resultantes da fase
Modelo de caso de uso (pelo menos 80% completo)
Visão
Especificações suplementares
Glossário
Plano de Desenvolvimento de Software
Pasta de Desenvolvimento
*
*
*
Fases
2 – Elaboração – Artefatos iniciados resultantes da fase
Modelo de domínio
Modelo de projeto
Documento da arquitetura do software
Modelo de dados
Modelo de implementação
Modelo de testes
	
		
*
*
*
Fases
3 - Construção: Identificar os requisitos restantes e concluir a implementação.
	Minimizar custos de desenvolvimento
	Produzir um produto pronto na plataforma adequada
	
*
*
*
Fases
3 – Construção – Artefatos refinados resultantes da fase
Modelo de Projeto
Modelo de Dados
Modelo de Implementação
Plano de Desenvolvimento de Software
Modelo de Teste
*
*
*
Fases
4 -Transição: assegurar que o software está disponível para os usuários.
	Operação paralela com o sistema legado
	Conversão de banco de dados
	Treinamento dos usuários
*
*
*
Fases
3 – Transição – Artefatos refinados resultantes da fase
Modelo de Implementação
Plano de Desenvolvimento de Software
*
*
*
Marcos e Pontos de Controle
Correspondem aos pontos de verificação ao final de cada fase
Só deve passar para uma próxima fase se os objetivos da fase anterior forem alcançados
LCO (Life Cicle Objective) – no final da Concepção quando o escopo é conhecido e bem fundamentado.
LCA (Life Cicle Architecture) – no final da Elaboração quando a arquitetura está completa e o conjunto de requisitos foi definido.
IOC (Initial Operational Capability) – no final da Construção e marca a primeira versão beta.
PR (Product Release) – no final da Transição e do ciclo de desenvolvimento
Pontos de controle menores são definidos no final de cada iteração.
*
*
*
Fases e Marcos
As fases indicam a maturidade do sistema. Representa o tempo e mostra os aspectos do ciclo de vida a medida que este tempo passa.
*
*
*
Disciplinas
Principais
Modelagem de Negócio
Requisitos
Análise e Projeto
Implementação
Teste
Implantação (Entrega)
*
*
*
Disciplinas
Suporte
Gerência de Configuração e de Mudanças
Gerência de Projeto
Ambiente
Planejamento de Projeto
*
*
*
Disciplinas
Requisitos
Construir artefatos que descrevem os requisitos do software
Estabelecer formalmente quais os requisitos funcionais e não funcionais que serão atendidos
Para a definição dos requisitos funcionais utiliza-se Caso de Uso
Artefatos: modelo de caso de uso, especificação suplementares, documento de visão
*
*
*
Disciplinas
Análise e Projeto
Transformar os requisitos em projeto de sistemas
Representação visual de todos os elementos necessários para implementação de caso de uso
Artefatos: modelo de projeto, documento de arquitetura de software, modelo de dados
Maior ênfase na fase de Elaboração
*
*
*
Disciplinas
Implementação
Implementar em componentes os elementos de projeto
Testar os componentes como unidades
Integrar os componentes
Artefatos: Modelo de Implementação
			
*
*
*
Disciplinas
Testes
Avaliar se todos os requisitos foram implementados corretamente
Avaliar a interação entre os componentes implementados
Avaliar a integração do software
Assegurar a correção de defeitos
Artefato: Modelo de teste
*
*
*
Disciplinas
Testes (cont.)
Modelo de teste: Casos de testes + Procedimentos de testes
Casos de teste definem o que testar
Procedimento de Teste definem como testar
Um caso de teste é implementado por um ou mais procedimentos de teste
Casos de teste são desenvolvidos a partir dos casos de uso
Além de Script e Carga de Dados
*
*
*
Disciplinas
Implantação
Determina a disponibilidade do sistema nas instalações do usuário
Assegurar que o produto está pronto para utilização
Usuários treinados
Banco de dados populado
Documentação técnica finalizada
*
*
*
Disciplinas
Gerenciamento de Configuração e Mudança
Controlar as versões de alterações
Controlar acesso e alterações aos artefatos
Gerenciamento de Projeto
Planejamento de Projeto
Acompanhamento do Projeto
Artefato: Plano de Desenvolvimento do Software
Ambiente
Suportar o ambiente para o projeto – Processo, metodologia, ferramentas, estrutura organizacional, infra-estrutura de hardware e software
Artefato: Pasta de Desenvolvimento
*
*
*
Disciplinas
Gerenciamento de Projeto - Detalhamento
Planejamento do Ciclo de Vida (Iterativo)
Definir Plano
Fases
Marcos principais
O que fazer e quando fazer (estimativa de datas)
Planejar as Fases
Número de iterações
Objetivos das iterações
Duração das iterações
Planejar as iterações
Plano detalhado da iteração
*
*
*
Modelos e Artefatos
Modelos são abstrações que facilitam a compreensão e a comunicação.
Ex.: Modelo de Análise e Modelo de Projeto.
Baseado no princípio “Dividir para Conquistar”.
Níveis de Abstração: 
Conceitual, Especificação, Implementação
Modelos são formados de Artefatos que são diagramas e os documentos que o descrevem.
Diagramas da UML
*
*
*
Artefatos
Modelo de Domínio : diagrama de classe do negócio
Modelo de Caso de Uso : diagrama de caso de uso 
Especificações Suplementares: requisitos não funcionais
Visão
Glossário
Modelo de Projeto
Documento de arquitetura de software
Modelo de Dados
Modelo de Implementação
Plano de Desenvolvimento de Software
Modelo de Teste
Pasta de Desenvolvimento
*
*
*
Iterações
Corresponde a um ciclo por todas as disciplinas dentro da fase
Deve ter como resultado um produto observável
Deve ter sua duração
fixa
Os Riscos afetam o planejamentos das iterações
Existem diferentes estratégias para Planejamento das Iterações de acordo com cada projeto
*
*
*
Ciclo de Desenvolvimento
Um ciclo corresponde a execução das quatro fases
Cada fase pode ser dividida em iterações
Cada iteração repete as disciplinas do processo
Cada iteração produz um incremento do software (releasable)
Ao final do ciclo temos um produto final de software (release product)
*
*
*
Recomendações
Não se deve planejar todas as iterações de forma detalhada no início do projeto
Não se deve assumir compromissos a longo prazo na fase de concepção
Não se deve selecionar funcionalidades de baixo risco nas primeiras iterações
RUP é um framework não um processo específico. Precisa ser ajustado para cada situação. 
*
*
*
A Essência do RUP
Desenvolva uma visão
Gerencie o plano
Identifique e trate Riscos
Assinale e acompanhe demandas
Examine o business case
Projete uma arquitetura baseada em Componentes
Construa e teste o produto de maneira incremental
Verifique e avalie os resultados
Gerencie e controle mudanças
Forneça suporte ao usuário