SlideShare uma empresa Scribd logo
1 de 49
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO 
DISCIPLINA: ENGENHARIA DE SOFTWARE 
DOCENTE: CICÍLIA RAQUEL 
RATIONAL UNIFIED PROCESS - RUP 
MODELOS DE PROCESSO DE SOFTWARE 
DISCENTES: FERNANDO NOGUEIRA, GILBERTO MARIANO, PRICILA 
MELO
ROTEIRO 
Rational 
Unified 
Process - RUP 
Fases do RUP Workflows 
Pontos 
importantes 
RUP - IBM
RATIONAL UNIFIED PROCESS - RUP
RATIONAL UNIFIED PROCESS - RUP 
• Modelo de processo moderno, derivado do trabalho sobre a UML e do 
Processo Unificado de Desenvolvimento de Software. 
• Criado pela Rational Software Corporation, adquirida pela IBM. 
• Usa uma abordagem da orientação a objetos; é projetado e documentado 
utilizando a notação UML (Unified Modeling Language). 
• Produzir software de qualidade, atendendo aos requisitos estabelecidos pelo 
cliente, e respeitando um orçamento e cronograma previamente definidos.
RATIONAL UNIFIED PROCESS - RUP 
FIGURA 1 – FINALIDADE RUP
RATIONAL UNIFIED PROCESS - RUP 
• RUP ≠ Processo Unificado. 
• Processo considerado pesado e preferencialmente aplicável a grandes 
equipes e a grandes projetos. 
• O planejamento é baseado num conjunto de processos, que buscam atingir 
certos objetivos no tempo. 
• Projeto é abordado de forma dinâmica e iterativa.
RATIONAL UNIFIED PROCESS - RUP 
• RUP é, por si só, um produto de software. É modular e automatizado. 
• Bom exemplo de modelo híbrido de processo. 
• Cleanroom, XP(Extreme Programming), Scrum, FDD (Feature Driven 
Development). 
• Geralmente descrito a partir de três perspectivas: 
• Perspectiva dinâmica; 
• Perspectiva estática; 
• Perspectiva prática.
RATIONAL UNIFIED PROCESS - RUP 
FIGURA 2 – MAPA DE PROCESSOS
FASES DO RUP
FASES DO RUP 
• Divisão do projeto em fases. 
• Cada fase precede um marco no projeto. 
• Série de artefatos e critérios de avaliação de sucesso são pré-estabelecidos. 
• Processo de software é tratado em fases que, quando finalizadas, atingem 
marcos, que serão validados através de diretivas, e trarão uma série de 
produtos necessários para a próxima etapa.
CONCEPÇÃO 
• Estabelecer um business case para o sistema; 
• Identificar todas as entidades externas, e definir suas interações. 
• Contribuição do sistema com o negócio é avaliada; 
• Dependendo da contribuição, o projeto pode até ser cancelado.
LCO - ARTEFATOS 
• Visão: documentação dos requisitos, restrições e elementos chave do 
projeto; 
• Riscos: identificar os riscos do projeto; 
• Caso de negócio: documento que contém as informações e suposições sobre 
o retorno do investimento; 
• Plano de desenvolvimento de software: Fases iniciais, duração e objetivo;
LCO - ARTEFATOS 
• Plano de iteração: Atividades e tarefas divididas, com recursos e 
dependência; 
• Caso de desenvolvimento: descrição do processo de desenvolvimento para 
servir de guia; 
• Ferramentas: tudo que será necessário para o desenvolvimento do software; 
• Glossário: termos importantes no projeto.
CONCEPÇÃO - PERGUNTAS 
• Os stakeholders estão confiantes de que a equipe do projeto entendeu o 
problema a ser resolvido? 
• Os stakeholders estão confiantes de que os riscos mais críticos foram 
identificados? 
• As estimativas iniciais foram refinadas com base no conhecimento 
adquirido? 
• As estimativas de custo e prazo são aceitáveis para os stakeholders?
ELABORAÇÃO 
• Desenvolver um entendimento do domínio do problema; 
• Estabelecer um framework de arquitetura para o sistema; 
• Desenvolver o plano de projeto; 
• Identificar os principais riscos do projeto.
ELABORAÇÃO 
• Modelo de requisitos para o sistema (os casos de uso da UML são 
especificados); 
• Uma descrição de arquitetura; 
• Um plano de desenvolvimento para o software.
LCA - ARTEFATOS 
• Protótipos: explorar a funcionalidade crítica e os cenários significativos; 
• Lista de riscos: atualização e revisão dos riscos identificados na fase anterior; 
• Caso de desenvolvimento: atualização do artefato já elaborado; 
• Ferramentas: ferramentas pertinentes ao trabalho de elaboração são 
instaladas;
LCA - ARTEFATOS 
• Documento de arquitetura de software: visão geral de arquitetura 
abrangente do sistema; 
• Modelo de design: realização dos casos de uso; guia para o modelo de 
implementação; 
• Modelo de dados: descreve a representação lógica e física dos dados 
persistentes no sistema; 
• Modelo de implementação: conjunto de componentes;
LCA - ARTEFATOS 
• Visão: compreensão sólida dos casos de uso mais críticos; 
• Plano de desenvolvimento de software: atualizar o plano existente com 
objetivo de abranger as próximas fases; 
• Modelo de casos de uso: um modelo de casos de uso praticamente 
concluído; 
• Especificações suplementares: Os requisitos suplementares são 
documentados e analisados;
LCA - ARTEFATOS 
• Conjunto de testes: validar a estabilidade do build para cada release 
executável; 
• Arquitetura para automatização de testes: composição de diversos 
elementos de automatização de testes e suas especificações.
ELABORAÇÃO - PERGUNTAS 
• Os stakeholders tem confiança de que a equipe do projeto tem capacidade 
de implementar a solução proposta? 
• A arquitetura reflete os requisitos funcionais? 
• Todos os riscos foram eliminados ou mitigados? 
• As variações de custo e prazo são aceitáveis para os stakeholders?
CONSTRUÇÃO 
• Fase essencialmente relacionada ao projeto, programação e teste de 
sistema. 
• As partes do sistema são desenvolvidas paralelamente e integradas. 
• Ao término dessa fase deve-se ter: 
• Um sistema de software em funcionamento; 
• Documentação associada pronta para ser liberada para os usuários.
IOC - ARTEFATOS 
• Sistema: sistema executável pronto para começar o teste beta; 
• Plano de implantação: coordena e lista as atividades envolvidas na 
transferência do sistema da comunidade de desenvolvimento para a 
comunidade de usuários; 
• Conjunto de testes: testes implementados e executados de cada release; 
• Materiais de treinamento: manuais do usuário e outros materiais de 
treinamento;
IOC - ARTEFATOS 
• Plano de iteração: Plano de iteração para a próxima fase, concluído e 
analisado; 
• Modelo de design: atualizado com novos elementos de design; 
• Caso de desenvolvimento: refinamento do ambiente de desenvolvimento; 
• Ferramentas: ferramentas da fase de construção;
IOC - ARTEFATOS 
• Modelo de dados: Atualizado com a experiência adquirida no processo de 
construção.
CONSTRUÇÃO - PERGUNTAS 
• O produto está completo o suficiente e com a qualidade mínima aceitável 
para iniciar o teste de aceitação? 
• O usuário e a organização estão preparados para o início da implementação 
(transição do sistema)? 
• As variações de custo e prazo são aceitáveis para os stakeholders?
TRANSIÇÃO 
• Transferência do sistema da comunidade de desenvolvimento para a 
comunidade de usuários. 
• Entrada do sistema em funcionamento no ambiente real. 
• Atividade onerosa e, às vezes, problemática. 
• Sistema de software documentado e funcionando corretamente em seu 
ambiente operacional.
PR - ARTEFATOS 
• Build do produto: sistema concluído; 
• Notas de release: identificam mudanças e erros; 
• Artefatos de instalação: elementos de instalação do software, como também 
a documentação associada; 
• Material de treinamento: a partir dele o cliente poderá utilizar o sistema;
PR - ARTEFATOS 
• Material de suporte para o usuário final: aprendizagem, manutenção e 
utilização do sistema.
TRANSIÇÃO - PERGUNTAS 
• Os objetivos do projeto foram atingidos de acordo com os critérios de 
medição? 
• As variações de custo e prazo são aceitáveis pelos stakeholders? 
• Os usuários estão satisfeitos?
RELAÇÃO RECURSO X TEMPO 
FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP
WORKFLOWS
WORKFLOWS 
• São atividades que ocorrem durante o processo de desenvolvimento; 
• Também chamado de disciplina; 
• Um workflow mostra todas as atividades que deverá realizar para 
construir um artefato. 
• Não são temporais ou fixos nas fases.
WORKFLOWS 
• Há 9 Workflows 
• 6 principais 
• 3 de apoio
WORKFLOWS PRINCIPAIS 
 Modelagem de Negócios 
 Casos de uso. Identificação dos processos. 
 Requisitos 
 Identificar indivíduos, restrições, fronteiras. 
 Análise e Design 
 Arquitetura, componentes, BD. 
 Implementação 
 Teste 
 Implantação 
 Aceitação, suporte.
WORKFLOWS DE APOIO 
 Gerenciamento de Configuração e Mudança 
 Gerencia as mudanças e planejamento de controle. 
 Gerenciamento de Projeto 
 Gerencia o desenvolvimento. 
 Ambiente 
 Ferramentas.
FIGURA 4 –Workflows
RUP - IBM
RUP - IBM 
• Aprimora a produtividade com técnicas e práticas configuráveis comprovadas 
no mercado para adaptar as necessidades de projetos individuais; 
• Suporta colaboração de equipe e profissionais individuais com guias de 
contexto através de regiões geográficas e funções; 
• Possibilita facilmente a mitigação de risco usando processos iterativos 
centrados em prioridades de negócios e necessidades dos stakeholders; 
• Promove transformação organizacional com serviços de educação, 
consultoria extensiva e um ecossistema de Parceiros de Negócios IBM.
PRINCÍPIOS - IBM 
• Adaptar o processo; 
• Balancear as prioridades dos stakeholders; 
• Colaboração entre as equipes; 
• Demonstrar valor iterativamente;
BIBLIOTECA RUP - IBM 
• Projetos pequenos, médios e grandes; 
• Desenvolvimento de aplicativos de pacote ou comerciais padrão; 
• Desenvolvimento de aplicativos Mainframe e IBM System Z; 
• Engenharia de sistemas;
PRINCÍPIOS - IBM 
• Elevar o nível de abstração; 
• Foco na qualidade.
BIBLIOTECA RUP - IBM 
• Modelagem de negócio; 
• Manutenção; 
• Desenvolvimento SOA; 
• Desenvolvimento baseado em ativos;
BIBLIOTECA RUP - IBM 
• Gerenciamento de Compliance; 
• The Departament of Defense; 
• Architecture Framework (DoDAF).
PROCESS ADVISOR 
• IBM Rational Team Unifying Platform; 
• IBM Rational Software Architect; 
• IBM Rational Application Developer; 
• IBM Rational Functional Tester; 
• IBM Rational Performance Tester.
PROCESS ADVISOR 
FIGURA N – PROCESS ADVISOR
DÚVIDAS?
OBRIGADO!
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO 
DISCIPLINA: ENGENHARIA DE SOFTWARE 
DOCENTE: CICÍLIA RAQUEL 
RATIONAL UNIFIED PROCESS - RUP 
FERNANDO NOGUEIRA: fernando.nogueiraq@gmail.com 
GILBERTO MARIANO: gilbermariano@gmail.com 
PRICILA MELO:

Mais conteúdo relacionado

Mais procurados

Aula 2 - Projeto de Produto
Aula 2  - Projeto de ProdutoAula 2  - Projeto de Produto
Aula 2 - Projeto de ProdutoTiago Cruz
 
Elaboracao de projetos:ZOPP e Marco Lógico
Elaboracao de projetos:ZOPP e Marco LógicoElaboracao de projetos:ZOPP e Marco Lógico
Elaboracao de projetos:ZOPP e Marco LógicoJackson De Toni
 
Aula 3 - Gestão de Projetos
Aula 3 - Gestão de ProjetosAula 3 - Gestão de Projetos
Aula 3 - Gestão de ProjetosFernando Dantas
 
Gerenciamento de projetos aula 7 (custos)
Gerenciamento de projetos   aula 7 (custos)Gerenciamento de projetos   aula 7 (custos)
Gerenciamento de projetos aula 7 (custos)Paulo Junior
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitosMailson Queiroz
 
Processos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e práticaProcessos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e práticaRalph Rassweiler
 
Gestao Estrategica da Qualidade
Gestao Estrategica da QualidadeGestao Estrategica da Qualidade
Gestao Estrategica da QualidadeJairo Siqueira
 
Estratégia de produção e operações
Estratégia de produção e operaçõesEstratégia de produção e operações
Estratégia de produção e operaçõesdedefs
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de softwareRondinelli Mesquita
 
Conscientização e motivação qualidade
Conscientização e motivação qualidadeConscientização e motivação qualidade
Conscientização e motivação qualidadeSergio Canossa
 

Mais procurados (20)

Aula 2 - Projeto de Produto
Aula 2  - Projeto de ProdutoAula 2  - Projeto de Produto
Aula 2 - Projeto de Produto
 
Manifesto Agil
Manifesto AgilManifesto Agil
Manifesto Agil
 
Elaboracao de projetos:ZOPP e Marco Lógico
Elaboracao de projetos:ZOPP e Marco LógicoElaboracao de projetos:ZOPP e Marco Lógico
Elaboracao de projetos:ZOPP e Marco Lógico
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Aula 3 - Gestão de Projetos
Aula 3 - Gestão de ProjetosAula 3 - Gestão de Projetos
Aula 3 - Gestão de Projetos
 
Gerenciamento de projetos aula 7 (custos)
Gerenciamento de projetos   aula 7 (custos)Gerenciamento de projetos   aula 7 (custos)
Gerenciamento de projetos aula 7 (custos)
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Processos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e práticaProcessos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e prática
 
Gerenciamento de tempo em projetos
Gerenciamento de tempo em projetosGerenciamento de tempo em projetos
Gerenciamento de tempo em projetos
 
Gestão da qualidade
Gestão da qualidadeGestão da qualidade
Gestão da qualidade
 
Gestao Estrategica da Qualidade
Gestao Estrategica da QualidadeGestao Estrategica da Qualidade
Gestao Estrategica da Qualidade
 
PDCA
PDCAPDCA
PDCA
 
Estratégia de produção e operações
Estratégia de produção e operaçõesEstratégia de produção e operações
Estratégia de produção e operações
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
 
Aula Gestão de Projetos Escopo, Tempo e Custo
Aula Gestão de Projetos Escopo, Tempo e CustoAula Gestão de Projetos Escopo, Tempo e Custo
Aula Gestão de Projetos Escopo, Tempo e Custo
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
 
Agile SCRUM
Agile SCRUMAgile SCRUM
Agile SCRUM
 
Conscientização e motivação qualidade
Conscientização e motivação qualidadeConscientização e motivação qualidade
Conscientização e motivação qualidade
 

Destaque

Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software RupFelipe
 
R.U.P. - Razão Unitária de Produção na Construção Civil
R.U.P. - Razão Unitária de Produção na Construção CivilR.U.P. - Razão Unitária de Produção na Construção Civil
R.U.P. - Razão Unitária de Produção na Construção CivilBruno Ferreira
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)elliando dias
 
Controle de qualidade, mão de obra e indicadores de produtividade
Controle de qualidade, mão de obra e indicadores de produtividadeControle de qualidade, mão de obra e indicadores de produtividade
Controle de qualidade, mão de obra e indicadores de produtividadeAlexandre Guimarães
 
Rational Unified Process - RUP
Rational Unified Process - RUPRational Unified Process - RUP
Rational Unified Process - RUPFernando Nogueira
 
Abstração
AbstraçãoAbstração
Abstraçãofkimura
 
Apresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupApresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupJarbas Pereira
 
AGILE UNIFIED PROCESS
AGILE UNIFIED PROCESSAGILE UNIFIED PROCESS
AGILE UNIFIED PROCESSEder Nogueira
 
Neuropedagogia
NeuropedagogiaNeuropedagogia
NeuropedagogiaLilith HD
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Rennan Martini
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - ResumoDaniel Brandão
 
Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)Fabrício Campos
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumMarcos Garrido
 
Matriz do Planejamento Estratégico Pessoal
Matriz do Planejamento Estratégico PessoalMatriz do Planejamento Estratégico Pessoal
Matriz do Planejamento Estratégico PessoalMichel Moreira
 

Destaque (20)

Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
 
Visao Geral Rup
Visao Geral RupVisao Geral Rup
Visao Geral Rup
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
R.U.P. - Razão Unitária de Produção na Construção Civil
R.U.P. - Razão Unitária de Produção na Construção CivilR.U.P. - Razão Unitária de Produção na Construção Civil
R.U.P. - Razão Unitária de Produção na Construção Civil
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
 
Controle de qualidade, mão de obra e indicadores de produtividade
Controle de qualidade, mão de obra e indicadores de produtividadeControle de qualidade, mão de obra e indicadores de produtividade
Controle de qualidade, mão de obra e indicadores de produtividade
 
Rational Unified Process - RUP
Rational Unified Process - RUPRational Unified Process - RUP
Rational Unified Process - RUP
 
Abstração
AbstraçãoAbstração
Abstração
 
Apresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupApresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rup
 
AGILE UNIFIED PROCESS
AGILE UNIFIED PROCESSAGILE UNIFIED PROCESS
AGILE UNIFIED PROCESS
 
Neuropedagogia
NeuropedagogiaNeuropedagogia
Neuropedagogia
 
metodologia rup
metodologia rupmetodologia rup
metodologia rup
 
Neuropedagogia
NeuropedagogiaNeuropedagogia
Neuropedagogia
 
Rup
Rup Rup
Rup
 
Planejamento Niveis
Planejamento NiveisPlanejamento Niveis
Planejamento Niveis
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)Técnicas de modelagem de teste (parte 1)
Técnicas de modelagem de teste (parte 1)
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Matriz do Planejamento Estratégico Pessoal
Matriz do Planejamento Estratégico PessoalMatriz do Planejamento Estratégico Pessoal
Matriz do Planejamento Estratégico Pessoal
 

Semelhante a Apresentação RUP

Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slideshoraciosila
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppCloves da Rocha
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Cloves da Rocha
 
Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Elaine Cecília Gatto
 
aula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptxaula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptxMarcondesTiburcio
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareCursoSENAC
 
Es2 modelo de processo de software
Es2 modelo de processo de softwareEs2 modelo de processo de software
Es2 modelo de processo de softwareluacal
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareCloves da Rocha
 
Aula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdfAula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdfJadna Almeida
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9wilsonguns
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1Tiago Vizoto
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareAragon Vieira
 
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareElaine Cecília Gatto
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de softwareFelipe Bugov
 

Semelhante a Apresentação RUP (20)

Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slides
 
347842.ppt
347842.ppt347842.ppt
347842.ppt
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
 
Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4
 
aula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptxaula projeto e des sistemas 22 03 2021.pptx
aula projeto e des sistemas 22 03 2021.pptx
 
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Es2 modelo de processo de software
Es2 modelo de processo de softwareEs2 modelo de processo de software
Es2 modelo de processo de software
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Aula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdfAula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdf
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de Software
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Áreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de SoftwareÁreas de Conhecimento da Engenharia de Software
Áreas de Conhecimento da Engenharia de Software
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 

Mais de Fernando Nogueira

4ª edicao redinfo, a sua revista eletrônica de computação
4ª edicao redinfo, a sua revista eletrônica de computação4ª edicao redinfo, a sua revista eletrônica de computação
4ª edicao redinfo, a sua revista eletrônica de computaçãoFernando Nogueira
 
3ª edicao redinfo, a sua revista eletrônica de computação
3ª edicao redinfo, a sua revista eletrônica de computação3ª edicao redinfo, a sua revista eletrônica de computação
3ª edicao redinfo, a sua revista eletrônica de computaçãoFernando Nogueira
 
2ª edicao redinfo, a sua revista eletrônica de computação
2ª edicao redinfo, a sua revista eletrônica de computação2ª edicao redinfo, a sua revista eletrônica de computação
2ª edicao redinfo, a sua revista eletrônica de computaçãoFernando Nogueira
 
1ª edição redinfo, a sua revista eletrônica de computação
1ª edição redinfo, a sua revista eletrônica de computação1ª edição redinfo, a sua revista eletrônica de computação
1ª edição redinfo, a sua revista eletrônica de computaçãoFernando Nogueira
 

Mais de Fernando Nogueira (7)

4ª edicao redinfo, a sua revista eletrônica de computação
4ª edicao redinfo, a sua revista eletrônica de computação4ª edicao redinfo, a sua revista eletrônica de computação
4ª edicao redinfo, a sua revista eletrônica de computação
 
3ª edicao redinfo, a sua revista eletrônica de computação
3ª edicao redinfo, a sua revista eletrônica de computação3ª edicao redinfo, a sua revista eletrônica de computação
3ª edicao redinfo, a sua revista eletrônica de computação
 
2ª edicao redinfo, a sua revista eletrônica de computação
2ª edicao redinfo, a sua revista eletrônica de computação2ª edicao redinfo, a sua revista eletrônica de computação
2ª edicao redinfo, a sua revista eletrônica de computação
 
1ª edição redinfo, a sua revista eletrônica de computação
1ª edição redinfo, a sua revista eletrônica de computação1ª edição redinfo, a sua revista eletrônica de computação
1ª edição redinfo, a sua revista eletrônica de computação
 
Realidade virtual na saúde
Realidade virtual na saúdeRealidade virtual na saúde
Realidade virtual na saúde
 
Memórias Modernas
Memórias ModernasMemórias Modernas
Memórias Modernas
 
Memórias Modernas
Memórias ModernasMemórias Modernas
Memórias Modernas
 

Último

Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdfConcurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdfGuilhermeRodrigues896381
 
Apresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfApresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfCarlos Gomes
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfRodolpho Concurde
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 
Certificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfCertificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfLarissa Souza
 

Último (6)

Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdfConcurso Caixa TI - Imersão Final - Rogério Araújo.pdf
Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf
 
Apresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfApresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdf
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 
Certificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfCertificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdf
 

Apresentação RUP

  • 1. GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE DOCENTE: CICÍLIA RAQUEL RATIONAL UNIFIED PROCESS - RUP MODELOS DE PROCESSO DE SOFTWARE DISCENTES: FERNANDO NOGUEIRA, GILBERTO MARIANO, PRICILA MELO
  • 2. ROTEIRO Rational Unified Process - RUP Fases do RUP Workflows Pontos importantes RUP - IBM
  • 4. RATIONAL UNIFIED PROCESS - RUP • Modelo de processo moderno, derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software. • Criado pela Rational Software Corporation, adquirida pela IBM. • Usa uma abordagem da orientação a objetos; é projetado e documentado utilizando a notação UML (Unified Modeling Language). • Produzir software de qualidade, atendendo aos requisitos estabelecidos pelo cliente, e respeitando um orçamento e cronograma previamente definidos.
  • 5. RATIONAL UNIFIED PROCESS - RUP FIGURA 1 – FINALIDADE RUP
  • 6. RATIONAL UNIFIED PROCESS - RUP • RUP ≠ Processo Unificado. • Processo considerado pesado e preferencialmente aplicável a grandes equipes e a grandes projetos. • O planejamento é baseado num conjunto de processos, que buscam atingir certos objetivos no tempo. • Projeto é abordado de forma dinâmica e iterativa.
  • 7. RATIONAL UNIFIED PROCESS - RUP • RUP é, por si só, um produto de software. É modular e automatizado. • Bom exemplo de modelo híbrido de processo. • Cleanroom, XP(Extreme Programming), Scrum, FDD (Feature Driven Development). • Geralmente descrito a partir de três perspectivas: • Perspectiva dinâmica; • Perspectiva estática; • Perspectiva prática.
  • 8. RATIONAL UNIFIED PROCESS - RUP FIGURA 2 – MAPA DE PROCESSOS
  • 10. FASES DO RUP • Divisão do projeto em fases. • Cada fase precede um marco no projeto. • Série de artefatos e critérios de avaliação de sucesso são pré-estabelecidos. • Processo de software é tratado em fases que, quando finalizadas, atingem marcos, que serão validados através de diretivas, e trarão uma série de produtos necessários para a próxima etapa.
  • 11. CONCEPÇÃO • Estabelecer um business case para o sistema; • Identificar todas as entidades externas, e definir suas interações. • Contribuição do sistema com o negócio é avaliada; • Dependendo da contribuição, o projeto pode até ser cancelado.
  • 12. LCO - ARTEFATOS • Visão: documentação dos requisitos, restrições e elementos chave do projeto; • Riscos: identificar os riscos do projeto; • Caso de negócio: documento que contém as informações e suposições sobre o retorno do investimento; • Plano de desenvolvimento de software: Fases iniciais, duração e objetivo;
  • 13. LCO - ARTEFATOS • Plano de iteração: Atividades e tarefas divididas, com recursos e dependência; • Caso de desenvolvimento: descrição do processo de desenvolvimento para servir de guia; • Ferramentas: tudo que será necessário para o desenvolvimento do software; • Glossário: termos importantes no projeto.
  • 14. CONCEPÇÃO - PERGUNTAS • Os stakeholders estão confiantes de que a equipe do projeto entendeu o problema a ser resolvido? • Os stakeholders estão confiantes de que os riscos mais críticos foram identificados? • As estimativas iniciais foram refinadas com base no conhecimento adquirido? • As estimativas de custo e prazo são aceitáveis para os stakeholders?
  • 15. ELABORAÇÃO • Desenvolver um entendimento do domínio do problema; • Estabelecer um framework de arquitetura para o sistema; • Desenvolver o plano de projeto; • Identificar os principais riscos do projeto.
  • 16. ELABORAÇÃO • Modelo de requisitos para o sistema (os casos de uso da UML são especificados); • Uma descrição de arquitetura; • Um plano de desenvolvimento para o software.
  • 17. LCA - ARTEFATOS • Protótipos: explorar a funcionalidade crítica e os cenários significativos; • Lista de riscos: atualização e revisão dos riscos identificados na fase anterior; • Caso de desenvolvimento: atualização do artefato já elaborado; • Ferramentas: ferramentas pertinentes ao trabalho de elaboração são instaladas;
  • 18. LCA - ARTEFATOS • Documento de arquitetura de software: visão geral de arquitetura abrangente do sistema; • Modelo de design: realização dos casos de uso; guia para o modelo de implementação; • Modelo de dados: descreve a representação lógica e física dos dados persistentes no sistema; • Modelo de implementação: conjunto de componentes;
  • 19. LCA - ARTEFATOS • Visão: compreensão sólida dos casos de uso mais críticos; • Plano de desenvolvimento de software: atualizar o plano existente com objetivo de abranger as próximas fases; • Modelo de casos de uso: um modelo de casos de uso praticamente concluído; • Especificações suplementares: Os requisitos suplementares são documentados e analisados;
  • 20. LCA - ARTEFATOS • Conjunto de testes: validar a estabilidade do build para cada release executável; • Arquitetura para automatização de testes: composição de diversos elementos de automatização de testes e suas especificações.
  • 21. ELABORAÇÃO - PERGUNTAS • Os stakeholders tem confiança de que a equipe do projeto tem capacidade de implementar a solução proposta? • A arquitetura reflete os requisitos funcionais? • Todos os riscos foram eliminados ou mitigados? • As variações de custo e prazo são aceitáveis para os stakeholders?
  • 22. CONSTRUÇÃO • Fase essencialmente relacionada ao projeto, programação e teste de sistema. • As partes do sistema são desenvolvidas paralelamente e integradas. • Ao término dessa fase deve-se ter: • Um sistema de software em funcionamento; • Documentação associada pronta para ser liberada para os usuários.
  • 23. IOC - ARTEFATOS • Sistema: sistema executável pronto para começar o teste beta; • Plano de implantação: coordena e lista as atividades envolvidas na transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários; • Conjunto de testes: testes implementados e executados de cada release; • Materiais de treinamento: manuais do usuário e outros materiais de treinamento;
  • 24. IOC - ARTEFATOS • Plano de iteração: Plano de iteração para a próxima fase, concluído e analisado; • Modelo de design: atualizado com novos elementos de design; • Caso de desenvolvimento: refinamento do ambiente de desenvolvimento; • Ferramentas: ferramentas da fase de construção;
  • 25. IOC - ARTEFATOS • Modelo de dados: Atualizado com a experiência adquirida no processo de construção.
  • 26. CONSTRUÇÃO - PERGUNTAS • O produto está completo o suficiente e com a qualidade mínima aceitável para iniciar o teste de aceitação? • O usuário e a organização estão preparados para o início da implementação (transição do sistema)? • As variações de custo e prazo são aceitáveis para os stakeholders?
  • 27. TRANSIÇÃO • Transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários. • Entrada do sistema em funcionamento no ambiente real. • Atividade onerosa e, às vezes, problemática. • Sistema de software documentado e funcionando corretamente em seu ambiente operacional.
  • 28. PR - ARTEFATOS • Build do produto: sistema concluído; • Notas de release: identificam mudanças e erros; • Artefatos de instalação: elementos de instalação do software, como também a documentação associada; • Material de treinamento: a partir dele o cliente poderá utilizar o sistema;
  • 29. PR - ARTEFATOS • Material de suporte para o usuário final: aprendizagem, manutenção e utilização do sistema.
  • 30. TRANSIÇÃO - PERGUNTAS • Os objetivos do projeto foram atingidos de acordo com os critérios de medição? • As variações de custo e prazo são aceitáveis pelos stakeholders? • Os usuários estão satisfeitos?
  • 31. RELAÇÃO RECURSO X TEMPO FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP
  • 33. WORKFLOWS • São atividades que ocorrem durante o processo de desenvolvimento; • Também chamado de disciplina; • Um workflow mostra todas as atividades que deverá realizar para construir um artefato. • Não são temporais ou fixos nas fases.
  • 34. WORKFLOWS • Há 9 Workflows • 6 principais • 3 de apoio
  • 35. WORKFLOWS PRINCIPAIS  Modelagem de Negócios  Casos de uso. Identificação dos processos.  Requisitos  Identificar indivíduos, restrições, fronteiras.  Análise e Design  Arquitetura, componentes, BD.  Implementação  Teste  Implantação  Aceitação, suporte.
  • 36. WORKFLOWS DE APOIO  Gerenciamento de Configuração e Mudança  Gerencia as mudanças e planejamento de controle.  Gerenciamento de Projeto  Gerencia o desenvolvimento.  Ambiente  Ferramentas.
  • 39. RUP - IBM • Aprimora a produtividade com técnicas e práticas configuráveis comprovadas no mercado para adaptar as necessidades de projetos individuais; • Suporta colaboração de equipe e profissionais individuais com guias de contexto através de regiões geográficas e funções; • Possibilita facilmente a mitigação de risco usando processos iterativos centrados em prioridades de negócios e necessidades dos stakeholders; • Promove transformação organizacional com serviços de educação, consultoria extensiva e um ecossistema de Parceiros de Negócios IBM.
  • 40. PRINCÍPIOS - IBM • Adaptar o processo; • Balancear as prioridades dos stakeholders; • Colaboração entre as equipes; • Demonstrar valor iterativamente;
  • 41. BIBLIOTECA RUP - IBM • Projetos pequenos, médios e grandes; • Desenvolvimento de aplicativos de pacote ou comerciais padrão; • Desenvolvimento de aplicativos Mainframe e IBM System Z; • Engenharia de sistemas;
  • 42. PRINCÍPIOS - IBM • Elevar o nível de abstração; • Foco na qualidade.
  • 43. BIBLIOTECA RUP - IBM • Modelagem de negócio; • Manutenção; • Desenvolvimento SOA; • Desenvolvimento baseado em ativos;
  • 44. BIBLIOTECA RUP - IBM • Gerenciamento de Compliance; • The Departament of Defense; • Architecture Framework (DoDAF).
  • 45. PROCESS ADVISOR • IBM Rational Team Unifying Platform; • IBM Rational Software Architect; • IBM Rational Application Developer; • IBM Rational Functional Tester; • IBM Rational Performance Tester.
  • 46. PROCESS ADVISOR FIGURA N – PROCESS ADVISOR
  • 49. GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE DOCENTE: CICÍLIA RAQUEL RATIONAL UNIFIED PROCESS - RUP FERNANDO NOGUEIRA: fernando.nogueiraq@gmail.com GILBERTO MARIANO: gilbermariano@gmail.com PRICILA MELO:

Notas do Editor

  1. 1 – O RUP é um... 2 – Foi...; ficando conhecido também por IRUP 3 – O RUP... em sua concepção ... para ilustrar os processos em ação; utilizando técnicas e práticas aprovadas comercialmente 4 – O objetivo do RUP é...
  2. 1 – Apesar de ser um produto comercial com as mesmas raízes que o Processo Unificado, não deve ser confundido com o Processo Unificado: ele tem estrutura diferente, usando as mesmas fases e as mesmas características básicas, mas as coleções de atividades técnicas são diferentes, e são chamadas de disciplina 2 - Porém o fato de ser amplamente costumizável torna possível que seja adaptado para projetos de qualquer escala 4 – Na metodologia RUP, o ... permitindo um melhor balanceamento entre os objetivos a serem alcançados e as necessidades dos clientes. Esta abordagem é adaptativa, pois permite incorporar facilmente as mudanças de requisitos que ocorrem com o passar do tempo
  3. 1 –e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus “Rational Suites” 2 – Traz elementos de todos os modelos genéricos de processo, apóia a iteração e ilustra boas práticas de especificação e projeto 3 – Métodos concorrentes no campo da engenharia de software 4 – Dinâmica: Mostra as fases do modelo ao longo do tempo; Estática: Mostra as atividades realizadas no processo Prática: Sugere as boas práticas a serem usadas durante o processo
  4. As fases e ciclos (iterações), associados à perspectiva dinâmica, estão dispostos horizontalmente, enquanto as atividades estão representadas verticalmente – perspectiva estática. Observe que não existe um critério fixo para a colocação de uma atividade em determinada fase. De espera que, a partir do contexto apresentado na figura, as atividades estejam mais associadas a determinados momentos no projeto, mas nada impede de serem utilizadas em outro instante – outra fase. O gráfico Modelo de Iteração mostra como a ênfase em cada Disciplina varia através do tempo. Nas Iterações iniciais, dedicamos mais tempo aos Requisitos. Já nas Iterações posteriores, gastamos mais tempo com Implementação, por exemplo.
  5. 1 –Divisão do projeto no RUP ao longo do tempo é constituída por fases 2 – ou seja, terminado uma fase, espera-se alcançar alguns objetivos principais – e consequentemente alcançar um importante marco 3 – Além dos objetivos principais, uma série de artefatos é pré-estabelecida juntamente com alguns critérios de avaliação do sucesso da fase 4 – Em resumo, ao se utilizar o RUP, ...
  6. 1 – O objetivo dessa fase é... 2 – (pessoas e sistemas) que irão interagir com o sistema, ... 3 – Com as informações em mãos, a... 4 – ou seja, se ela for de pouca importância; depois dessa fase
  7. Na fase final encontra-se o marco Objetivos do Ciclo de Vida – LCO: Lifecycle Objetive, espera-se conseguir os seguintes artefatos: 1 – Documento de maior importância nesta fase 2 – Pois como em todo gerenciamento, é essencial conhecer a amplitude e gravidade dos riscos 3 – É realizado a pergunta: é válido realizar o projeto? 4 – Documentação que identifica as... Especifica também estimativas do tempo, RH e custos envolvidos. Valores esses que podem ser brutos, já que ao decorrer do projeto, teremos mais informações sobre ele
  8. 1 – Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependência de tarefas, para a iteração. 4 – ou seja, se ela for de pouca importância; depois dessa fase 4 – Uma espécie de índice que será utilizado como referência
  9. Para saber se essa fase foi proveitosa, fazemos as seguintes perguntas:
  10. 1, 2, 3, e 4 – Os objetivos dessa fase são...
  11. 1, 2 e 3 – Ao concluir essa fase deve-se ter...
  12. A fase de elaboração termina com o marco Ciclo de Vida da Arquitetura, LCA: Lifecycle Architecture; onde se deve ter os seguintes artefatos 1 – São criados a fim de... 3 – considerando questões sobre o ambiente de desenvolvimento, ferramentas e processo
  13. 1 - Deve conter uma descrição detalhada para os casos de usos significativos para a arquitetura, e elementos de design (elementos lógicos a serem definidos como linguagem de programação e banco de dados) 2 – Descreve a... e serve como 4 – produtos liberados – executáveis – elementos dos quais os produtos foram criados – código fonte
  14. 1 – Casos de uso que conduzem as decisões de arquitetura e planejamento 3 – Modelo esteja ¾ do modelo conclusivo
  15. 1 – Testes implementados e executados para... criada nesta fase 2 – Especificações que representam as características fundamentais do sistema de software de automatização de testes (Wthreex, em Referências).
  16. Podemos avaliar sua consistência e confiabilidade dessa fase através das seguintes perguntas
  17. 2 – durante esta fase
  18. Ao concluir esta fase, chegamos no marco Capacidade Operacional Inicial, IOC: Initial Operational Capability que deve ter os seguintes artefatos: 1 – Teste geralmente realizado pela comunidade de usuários 3 – construído nessa fase
  19. 1 – A fase de transição 2 – Elementos identificados durante a conclusão de todos os requisitos 3 – processos e ferramentas, com o objetivo de auxiliar a equipe da próxima fase
  20. A maturação da fase de Construção pode ser mensurada pelos critérios de avaliação descritos abaixo. O formato em perguntas persiste:
  21. 1 – Fase relacionada a... 3 – Isso é algo ignorado na maioria dos modelos de processo de software, mas é, de fato, uma... 4 – Ao concluir essa fase, deverá se ter um...
  22. Ao final dessa fase encontra-se o marco Release do Produto, PR: Product Release, que deve ter os seguintes artefatos 1 – de acordo com os requisitos do produto, onde o consumidor final utiliza o sistema 2 - em uma versão de um build ou em uma unidade de implantação que tenha sido disponibilizada para uso
  23. 1 – Material que colabora com a...
  24. Através dos Critérios de Avaliação descritos a seguir, podemos avaliar o andamento da fase de Transição.
  25. Esses princípios ajudam você a melhorar a produtividade individual e a colaboração de equipe para criar software e sistemas de alta qualidade
  26. A solução Rational Unified Process fornece uma coleção de processos inovadores que você pode personalizar para abordar um conjunto diverso de necessidades de projeto e estilos de desenvolvimento.
  27. 1: A função Process Advisor habilita sua equipe de desenvolvimento a trabalhar com um processo de desenvolvimento comum configurado para um ambiente específico para os profissionais que usam o Rational Software Architect mostrado aqui. O resultado é uma instrução sensível ao contexto.