View
175
Download
8
Category
Preview:
DESCRIPTION
Apresentação do método RUP.
Citation preview
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃODISCIPLINA: ENGENHARIA DE SOFTWAREDOCENTE: CICÍLIA RAQUEL
MODELOS DE PROCESSO DE SOFTWARE
DISCENTES: FERNANDO NOGUEIRA, GILBERTO MARIANO, PRICILA MELO
RATIONAL UNIFIED PROCESS - RUP
ROTEIRO
Rational Unified
Process - RUPFases 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ÇÃODISCIPLINA: ENGENHARIA DE SOFTWAREDOCENTE: CICÍLIA RAQUEL
FERNANDO NOGUEIRA: fernando.nogueiraq@gmail.com
GILBERTO MARIANO: gilbermariano@gmail.com
PRICILA MELO:
RATIONAL UNIFIED PROCESS - RUP
Recommended