Baixe o app para aproveitar ainda mais
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
Compartilhar