apresentação rup

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


• 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.


FIGURA 1 – FINALIDADE 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.


• 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.


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.


• Modelagem de negócio;

• Manutenção;

• Desenvolvimento SOA;

• Desenvolvimento baseado em ativos;


• 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: [email protected]

GILBERTO MARIANO: [email protected]

PRICILA MELO:


apresentação rup

Technology