Click here to load reader
Upload
tiago-gomes
View
168
Download
1
Embed Size (px)
DESCRIPTION
Resumo RUP para concursos
Citation preview
RUP – Rational Unified Process É composto por quatro fases e nove disciplinas (workflow/fluxo de trabalho). É uma
metodologia de desenvolvimento incremental e iterativa. Sua meta é produzir software de alta qualidade que atenda aos requisitos dos usuários dentro de um cronograma e orçamento previsíveis.
Um processo define quem (papel) está fazendo o quê (artefatos), como (atividades) e quando (fluxo) de modo a alcançar determinado objetivo.
• Um papel descreve quem executa as atividades que geram os artefatos. o uma pessoa pode representar diversos papéis
• Artefatos são quaisquer produtos resultantes do processo de software. • Atividade é uma unidade de trabalho que um indivíduo desempenhando um papel
pode ser chamado a realizar.
O RUP possui duas dimensões:
• O eixo horizontal representa o aspecto dinâmico do processo e é expresso em termos de fases, iterações e marcos.
• O eixo vertical representa o aspecto estático do processo, representa as disciplinas.
PRECISA DECORAR ESTE GRÁFICO
1
Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz uma geração do software. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.
Uma passagem pelas nove disciplinas é uma iteração. O número de iterações para completar um projeto depende da complexidade do mesmo.
FASES DO RUP
Iniciação/Concepção
Objetivos • Estabelecer o escopo do software do projeto
• Discriminar os casos de uso críticos do sistema
• Exibir pelo menos uma opção de arquitetura básica
• Estimar o custo geral e a programação para o projeto inteiro
• Estimar riscos
• Preparar o ambiente e dar suporte para o projeto
Atividades Básicas • Formular o escopo do projeto • Planejar e preparar um caso de negócio • Sintetizar uma possível arquitetura
o Arquitetura é a organização lógica do conjunto de classes que vai compor o software
• Preparar o ambiente para o projeto
Marco: Objetivos do Ciclo de vida • Decide se o projeto é financeiramente viável e se vai ou não prosseguir com ele
Artefatos • Visão
• Caso de Negócio o Para determinar se vale ou não a pena investir no projeto
• Plano de Desenvolvimento de Software o Informações necessárias ao desenvolvimento do software
• Modelo de Casos de Uso (20%)
• Glossário o Define os termos importantes usados no projeto
2
Elaboração Criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção
Objetivos • Assegurar que a arquitetura, os requisitos e os planos estejam estáveis o suficiente e
que os riscos sejam suficientemente diminuídos • Tratar os riscos significativos do ponto de vista da arquitetura • Demonstrar que a arquitetura suportará os requisitos do sistema a um custo/tempo
justo • Estabelecer um ambiente de suporte
Atividades • Definir, validar e criar a baseline da arquitetura • Refinar a visão • Criar planos de iteração detalhados • Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento • Refinar a arquitetura e selecionar componentes
Marco: Arquitetura do Ciclo de Vida • Arquitetura estável
o Um dos critérios de avaliação é comparar a despesa real com a planejada
Artefatos • Protótipos • Lista de Riscos • Documento de Arquitetura de Software • Modelo de Projeto • Modelo de Dados • Modelo de Casos de Uso (80%)
Construção A meta é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema
com base na arquitetura da baseline.
Objetivos • Minimizar os custos do desenvolvimento • Atingir a qualidade adequada • Atingir as versões úteis (alfa, beta e etc.) • Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades
necessárias • Decidir se o software, os locais e os usuários estão prontos para a implantação • Atingir um paralelismo entre o trabalho das equipes para acelerar o desenvolvimento do
software
Atividades • Gerenciamento de recursos, otimização de controle e processo • Desenvolvimento completo do componente e teste dos critérios de avaliação definidos • Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão
3
Marco: Capacidade Operacional Inicial • Determina se o produto está pronto para ser implantado num ambiente de teste beta
Artefatos • Manuais de Usuário Completos • Sistema executável para iniciar testes beta • Conjunto de Testes • Plano de Implantação
Transição O objetivo é assegurar que o software esteja disponível para seus usuários finais. Inclui
testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário, que deve priorizar o ajuste fino do produto, a instalação, configuração e problemas de usabilidade. Problemas estruturais mais graves já devem ter sido tratados antes.
Objetivos • Teste beta para validar o novo sistema • Teste beta e operação paralela relativa a um sistema legado que está sendo substituído • Conversão de bancos de dados operacionais • Treinamento de usuários e equipe de manutenção • Atividades de ajuste • Obtenção do consentimento dos envolvidos de que as baselines estão consistentes com
os critérios de avaliação da visão
Atividades • Executar os planos de implantação
• Finalizar o material de suporte para o usuário final
• Testar o produto liberado no local do desenvolvimento
• Criar um release do produto
• Obter feedback do usuário e ajustar o produto com base nele
• Disponibilizar o produto para os usuários finais
Marco: Release do Produto • Você decide se os objetivos foram atendidos e se outro ciclo de desenvolvimento deve
ser iniciado.
Artefatos • Notas de Release
• Artefatos de Instalação
• Materiais de Treinamento e Suporte
• Build do Produto
4
Disciplinas do RUP (Workflow/Fluxo de Trabalho) (MRAITIGGA) Uma disciplina mostra todas as atividades que devem ser realizadas para produzir um determinado conjunto de artefatos. O RUP descreve detalhadamente as suas nove disciplinas.
Modelagem de Negócios • Entender a estrutura e a dinâmica da organização na qual o sistema deve ser
implantado. Entender como funciona a organização. • Entender os problemas atuais da organização-alvo e identificar as possibilidades de
melhoria. • Assegurar que os clientes, usuários e desenvolvedores tenham um entendimento
comum da organização-alvo. • Derivar os requisitos de sistemas necessários para sustentar a organização-alvo
Requisitos • Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o
sistema deve fazer • Oferecer aos desenvolvedores uma compreensão melhor dos requisitos do sistema • Definir as fronteiras do sistema • Base para planejar o conteúdo técnico das iterações • Base para estimar o custo e o tempo de desenvolvimento do sistema • Definir uma interface de usuário para o sistema
5
Análise e Design (Análise e Projeto) • Transformar os requisitos em um design do sistema a ser criado • Desenvolver uma arquitetura sofisticada para o sistema • Adaptar o design para que corresponda ao ambiente de implementação, projetando-o
para fins de desempenho
Implementação • Definir a organização do código em termos de subsistemas de implementação
organizados em camadas • Implementar classes e objetos em termos de componentes • Teste de unidade dos componentes • Integrara os resultados produzidos ao sistema executável
Testes • O teste enfatiza a avaliação da qualidade do produto • Localizar e documentar defeitos na qualidade do software • Avisar de forma geral sobre a qualidade observada no software • Validar as suposições feitas na Análise e Design/Requisitos • Validar as funções do software conforme projetadas • Verificar se os requisitos foram implementados de maneira adequada
6
Implantação • Descrevem as atividades que garantem que o produto de software será disponibilizado a
seus usuários finais. • Existem 3 modos de implantação:
o Caixa comercializável o Download pela web o Ir à empresa e instalar o produto
Gerenciamento de Configuração e Mudança • Controla mudanças feitas nos artefatos de um projeto e mantém a integridade deles • Evita:
o Atualização simultânea o Notificação limitada o Várias versões
7
Gerenciamento de Projetos • Fornecer um framework para gerenciar projetos intensivos de software. • Fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os
projetos. • Fornecer um framework de gerenciamento de risco. • O Gerenciamento de Projetos não cobre:
o Gerenciamento de pessoal o Gerenciamento de custos o Gerenciamento de contratos, entre outros
Ambiente
• Atividades necessárias à configuração do processo para um projeto • Fornece à organização o ambiente de desenvolvimento de software (ferramentas e
processos) que dará suporte à equipe de desenvolvimento • Disciplina ligada a garantia de qualidade de processos
8
Arquitetura 4 + 1
Visão de Arquitetura • Visão de um sistema a partir de uma determinada perspectiva • Foco na estrutura, modularidade, componentes essenciais e nos principais fluxos de
controle • São cinco visões no total (4 + 1)
Visão de Casos de Uso • Descreve como casos de uso críticos são executados no sistema, dando ênfase
principalmente a componentes arquiteturalmente significativos.
Visão de Implantação • Descreve uma ou várias configurações do sistema. É o mapeamento dos componentes
de software para nós de computação nessas configurações.
Visão de Implementação • Descreve a organização dos elementos estáticos do software no ambiente de
desenvolvimento em termos de empacotamento, divisão em camadas e gerenciamento da configuração.
Visão de Processos • Descreve o aspecto simultâneo do sistema, tarefas (processos) e suas interações.
Visão Lógica • Descreve as principais classes no design do sistema: classes relacionadas aos principais
negócios e classes que definem os principais mecanismos estruturais e comportamentais (persistência, comunicações, tolerância e falhas, interface do usuário)
• Endereça as exigências funcionais do sistema, isto é, expressa o que o sistema deveria fazer para os seus usuários finais.
• É uma abstração do modelo de projeto e identifica pacotes de projetos principais, subsistemas e classes.
9