Open Unified Process Open UP Flvia Falco fmcf

  • Slides: 34
Download presentation
Open Unified Process (Open. UP) Flávia Falcão (fmcf 2@cin. ufpe. br)

Open Unified Process (Open. UP) Flávia Falcão (fmcf 2@cin. ufpe. br)

O que é um “processo de desenvolvimento open source” ? 1. Um processo de

O que é um “processo de desenvolvimento open source” ? 1. Um processo de desenvolvimento livremente disponível 2. Um processo de desenvolvimento usado por projetos open source “How has open source development impacted your internal application development efforts? ” (2004) Open source software development has had no impact on our development organization 42 We have adopted some techniques used by open source projects. 17 17 We have adopted some open source tools We have changed our organization/roles in response to the examples of open source Don't know 8 6 Base: 83 companies Source : Forrester

Alguns Processos de desenvolvimento livremente disponiveis • • • MSF ( Microsoft Solutions Framework)

Alguns Processos de desenvolvimento livremente disponiveis • • • MSF ( Microsoft Solutions Framework) Open. UP e. Xtreme Programming Scrum DSDM (Dynamic Systems Development Methodology)

Um exemplo de processo usado por um projeto open source: “The Eclipse Way” •

Um exemplo de processo usado por um projeto open source: “The Eclipse Way” • As práticas de desenvolvimento Eclipse enfatizam feedback e ritmo de projeto: • Testes contínuos, integração continua, consumir suas próprias saídas, envolvimento da comunidade, milestones cedo, planejamento incremental , ter sempre o cliente, centrado em componente, times dinâmicos, API primeiro • As práticas de desenvolvimento do Eclipse são práticas de desenvolvimento Ageis • O comportamento de Projetos open source e projetos ágeis são bastante similares • O Eclipse é justamente um exemplo da implementação dessas praticas em larga escala

Muitas empresas não usam um unico padrão de metodologia “Is a standard methodology —

Muitas empresas não usam um unico padrão de metodologia “Is a standard methodology — or set of methodologies — used by all of the development organizations in your company (e. g. , each business unit’s IT department)? ” (2004) Base: 83 companies Source : Forrester

Eclipse Process Framework -EPF • Objetivos : • Promover uma linguagem comum - ou

Eclipse Process Framework -EPF • Objetivos : • Promover uma linguagem comum - ou meta – modelo – para processos de software • Prover ferramentas que facilitem a criação e disponibilização de conteúdo e conhecimento • Prover práticas de desenvolvimento iterativo e ágil • Um dos objetivos-chave do projeto EPF é prover práticas de desenvolvimento de software que possam ser facilmente adotadas e montadas em uma série de processos que se aplicam a diferentes necessidades dos projetos

Eclipse Process Framework Co-desenvolvedores Patrocinadores

Eclipse Process Framework Co-desenvolvedores Patrocinadores

Open. UP

Open. UP

O que é Open. UP? • É um processo de desenvolvimento de software ágil

O que é Open. UP? • É um processo de desenvolvimento de software ágil e iterativo e segue as seguintes caracteristicas: • Mínimo -> Apenas o conteúdo fundamental para o desenvolvimento de software faz parte de sua estrutura • Completo ->Pode ser utilizado diretamente como definido • Extensível -> A partir dele outros processos podem ser montados adequando-se as necessidades de projetos mais formais e complexos

Quatro Principios Essenciais • Colaboração : alinhar os interesses e compartilhar o entendimento •

Quatro Principios Essenciais • Colaboração : alinhar os interesses e compartilhar o entendimento • Envolvimento : obter um continuo feedback e para melhorar o processo • Balanciar prioridades : concorrentes para maximizar o valor do stakeholder • Foco na arquitetura

Colaboração • Manter o entendimento comum • Principais artefatos: visão, requisito, arquitetura, plano de

Colaboração • Manter o entendimento comum • Principais artefatos: visão, requisito, arquitetura, plano de iteração • Promover um ambiente verdadeiro • Gerenciamento por objetivo, entender as perspectivas do outro • Dividir responsabilidades • Todos são donos do produto, “ajudar uns aos outros” • Aprender contiuamente • Desenvolver habilidades técnicas e interpessoais, ser o estudante e o professor • Organização baseada na arquitetura

Envolvimento • • • Desenvolver o projeto em iterações Gerenciar riscos Adotar e Gerenciar

Envolvimento • • • Desenvolver o projeto em iterações Gerenciar riscos Adotar e Gerenciar mudanças Mensurar o progresso objetivamente Reavaliação continua

Balanceamento • • Conhecer os stakeholders Separar o problema da solução Criar um entendimento

Balanceamento • • Conhecer os stakeholders Separar o problema da solução Criar um entendimento comum do domínio Usar cenários e use cases para capturar requisitos Estabilizar e manter contrato em prioridades Fazer o trade off para maximizar valor Gerenciar escopo Saber quando parar

Arquitetura • Criar uma arquitetura o quanto antes • Lidar complexidade através de abstrações

Arquitetura • Criar uma arquitetura o quanto antes • Lidar complexidade através de abstrações • Organizar a arquitetura com baixo acoplamento e alta coesão dos componentes • Reusar componentes existentes • Tratar a arquitetura como uma ferramenta colaborativa

3+1 Sub. Processos Foco na visão do usuario e negociar com os stakeholders as

3+1 Sub. Processos Foco na visão do usuario e negociar com os stakeholders as metas Meta Gerenciamento Foco na visão do pagante pelo projeto e lida com o monitoramento, direção e redução dos riscos Solução Colaboração Tratar como os membros trabalham juntos Foco no ponto de vista do time de desenvolvimento e negocia com criação e verificação de builds

Principios x Sub. Processos Cada Sub. Processo é guiado por um principio : •

Principios x Sub. Processos Cada Sub. Processo é guiado por um principio : • • Meta – Balanceamento Gerenciamento – Envolvimento Solução – foco na arquitetura Colaboração - alinhamento

Ciclo de Vida

Ciclo de Vida

Fase de Concepção Objetivos Atividades Entender o que vai ser construído Identificar funcionalidades chaves

Fase de Concepção Objetivos Atividades Entender o que vai ser construído Identificar funcionalidades chaves do sistema Gerenciamento de Requisitos Iniciar projeto Gerenciamento de requisitos Determinar uma arquitetura flexível Iniciar Projeto Gerenciar Iteração Determinar uma possível solução Estimar custo, cronograma, riscos associados com o projeto

Fase de Elaboração Objetivos Atividades Obter mais detalhes dos requisitos Gerenciamento de Requisitos Projetar,

Fase de Elaboração Objetivos Atividades Obter mais detalhes dos requisitos Gerenciamento de Requisitos Projetar, implementar, va Definir arquitetura lidar, e ter uma baseline Desenvolver Solução da arquitetura Validar build Mitigar riscos, produzir Gerenciar Iteração um cronograma e estimativa de custos precisos

Fase de Construção Objetivos Atividades Desenvolver Iterativamente um produto. Gerenciamento de Requisitos Desenvolver Solução

Fase de Construção Objetivos Atividades Desenvolver Iterativamente um produto. Gerenciamento de Requisitos Desenvolver Solução Validar Build Gerenciar iteracão Desenvolver Solução Validar Build Minimizar custos de desenvolvimento e alcançar algum paralelismo

Fase de Transição Objetivos Atividades Testes Beta para validar as expectativas dos usuários Andamento

Fase de Transição Objetivos Atividades Testes Beta para validar as expectativas dos usuários Andamento das Atividades Desenvolvimento da solução Validar Build Gerenciar Iteração Validar Build Concordância com o stakeholder que o deployment está completo Melhorar futuros projetos através das lições aprendidas Gerenciamento de Iteração

Disciplinas • • • Requisitos Analise e Projeto Implementação Testes Gestão de Projetos Gestão

Disciplinas • • • Requisitos Analise e Projeto Implementação Testes Gestão de Projetos Gestão de Configuração e Mudança

Requisitos • Documento de Visão define o ponto de vista do produto pelo stakeholder

Requisitos • Documento de Visão define o ponto de vista do produto pelo stakeholder • Use Cases definem os cenários e identificam escopo das iteracoes e releases • O gerenciamento dos requisitos é feito através do ciclo de vida

Gerenciamento Your goal is to find a Path from Here to There Project Starting

Gerenciamento Your goal is to find a Path from Here to There Project Starting Point Stakeholder Satisfaction Space

Dividir um grande problema em uma serie se pequenos problemas Planned Completion 1 2

Dividir um grande problema em uma serie se pequenos problemas Planned Completion 1 2 3 4 5 6 Planned Path Initial Project Plan Stakeholder Satisfaction Space

Definir quando o objetivo pode ser alcançado Planned Completion 1 3 2 4 5

Definir quando o objetivo pode ser alcançado Planned Completion 1 3 2 4 5 6 Planned Path Inception Do we understand the problem? Elaboration Do we understand the solution? Construction Transition Release Feature complete? ready? Stakeholder Satisfaction Space

Priorizar e gerenciar trabalho: Lista de tarefas High Priority Each iteration implements the highest-priority

Priorizar e gerenciar trabalho: Lista de tarefas High Priority Each iteration implements the highest-priority work items High-priority work items should be well-defined New work items can be added at any time Work items can be reprioritized at any time Low-priority work items can be vague Work items can be removed at any time Low Priority Work Item List

Estimativa Agil • Tamanho • Cada item da lista de tarefas é estimado •

Estimativa Agil • Tamanho • Cada item da lista de tarefas é estimado • Velocidade • A quantidade de itens que serão entregues é estimada a cada iteração • Esforço • Estimar o esforço atual

Planejar Iteração • Especificar velocidade e objetivos da iteração • Analisar o topo da

Planejar Iteração • Especificar velocidade e objetivos da iteração • Analisar o topo da lista de trabalho • Estimar esforços em horas • Adcionar ao plano de iteração • Especificar testes Estimate and add to iteration plan • Iteration objectives • Iteration Work Item List • Measure / test results Iteration Plan

Projeto • • • Entender requisitos e identificar cenarios Identificar elementos Determinar como elementos

Projeto • • • Entender requisitos e identificar cenarios Identificar elementos Determinar como elementos interagem Refinar decisões Comunicação

Testes Primeiro o projeto dos testes Refine the Architecture Design the Solution Implement Developer

Testes Primeiro o projeto dos testes Refine the Architecture Design the Solution Implement Developer Tests Implement the Solution Run Developer Tests

Conclusões • O Eclipse Process Framework pode ser util para a construção de novos

Conclusões • O Eclipse Process Framework pode ser util para a construção de novos processos e na extensão do open. Up • O Open. Up é um processo que capta boas praticas das abordagens agil e de processo unificado

Referencias • Eclipse Process Framework (EPF )http: //www. eclipse. org/epf/ • Developer. Works: The

Referencias • Eclipse Process Framework (EPF )http: //www. eclipse. org/epf/ • Developer. Works: The Eclipse Process Framework Project, Kroll, http: //www. ibm. com/developerworks/rational/library/05/1011_kroll/ • Eclipse Review: A Development Library at your Fingertips, Kroll and Sand, http: //www. eclipsereview. com/retrieve/er_200609. htm • Rational Edge: Eclipse Process Framework Composer - Part 1: Key Concepts, Haumer, http: //www. eclipse. org/epf/general/EPFComposer. Overview. Part 1. pdf • Rational Edge: Eclipse Process Framework Composer - Part 2: Authoring Method Content and Processes, Haumer, http: //www. eclipse. org/epf/general/EPFComposer. Overview. Part 2. pdf • The Open Unified Process: A Brilliant, Collaborative March into Open Source http: //www. numbersix. com/news/n 6 articles/open. Up. html • Conhecimento ao alcance das mãoshttp: //www-306. ibm. com/ebusiness/br/campaign/rational/columns_articles_new_tech_knowledge. shtml