Visão Geral RUP (Rational Unified Process) Professor: Tiago Reis RUP 1
RUP 1. Processo de engenharia de software 2. Oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento 3. O RUP tem duas dimensões ƒ o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve ƒ o eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. RUP 1. A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos 2. A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo. 2
RUP Processo de Engenharia de Software 3
Processo de Engenharia de Software 1. Na Engenharia de Software um processo é um conjunto de passos parcialmente ordenados com a intenção de criar um software ou aperfeiçoar um existente 2. O RUP proporciona uma abordagem disciplinada para a atribuição de tarefas e de responsabilidades dentro de uma organização de desenvolvimento. Processo de Engenharia de Software 3. A meta do RUP é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários, dentro de uma programação e um orçamento previsíveis 4. O processo de engenharia de software é o processo de desenvolvimento de um sistema a partir dos requisitos, sejam eles novos (ciclo de desenvolvimento inicial) ou alterados (ciclo de evolução)... 4
RUP Disciplinas 5
Disciplinas 1. Uma disciplina é um conjunto de atividades relacionadas a uma 'área de interesse' importante em todo o projeto 2. O principal objetivo do agrupamento de atividades em disciplinas é ajudar a compreender o projeto a partir de uma perspectiva em cascata 'tradicional 3. Cada disciplina tem, associada a ela, um ou mais 'modelos' que, por sua vez, são compostos por artefatos associados. Disciplinas 1. Cada disciplina está associada a um conjunto específico de modelos 2. Os artefatos mais importantes são os modelos que cada disciplina produz... 6
Disciplinas 1. Para cada disciplina, uma YLVmRJHUDOGD DWLYLGDGH é apresentada, que mostra todas as atividades na disciplina juntamente com o papel que realiza a atividade. Por exemplo, veja a da Implementação... Disciplinas 1. Para cada disciplina, um diagrama de YLVmR JHUDOGHDUWHIDWRV também é apresentado, que mostra todos os artefatos e papéis envolvidos na disciplina. Por exemplo, veja a de Requisitos... 7
RUP Conceitos-chave 1. Alguns dos conceitos-chave do processo, como iteração, fase, risco, teste de desempenho, entre outros, são apresentados em seções separadas do processo, normalmente anexadas à disciplina mais adequada... 8
RUP Fluxo de Trabalho 1. O fluxo de trabalho é uma seqüência das atividades que produzem um resultado de valor observável 2. Em termos de UML, o fluxo de trabalho pode ser expresso como um diagrama de seqüência, de colaboração ou de atividades 3. Para cada disciplina, é apresentado um diagrama de DWLYLGDGHV 9
Fluxo de Trabalho - Ambiente RUP 10
Detalhamento do Fluxo de Trabalho 1. Os diagramas de GHWDOKDPHQWRGRIOX[RGH WUDEDOKR mostram os agrupamentos das atividades que, geralmente, são executadas "em conjunto" 2. Esses diagramas mostram os papéis envolvidos, os artefatos de entrada e de saída e as atividades executadas 3. Existem vários diagramas de detalhamento do fluxo de trabalho para uma disciplina. Detalhamento do Fluxo de Trabalho 1. É complexo mostrar, em um único diagrama, os artefatos de entrada e de saída para todas as atividades de uma disciplina 2. Este diagrama permite mostrar todas as atividades e todos os artefatos de uma parte do fluxo de trabalho de cada vez 3. Além disso, as disciplinas não são completamente independentes entre si 4. Este diagrama pode mostrar um grupo de atividades e de artefatos de mais de uma disciplina. 11
Detalhamento do Fluxo de Trabalho RUP 12
Papel 1. O papel define o comportamento e as responsabilidades de um indivíduo ou de um conjunto de indivíduos que trabalham juntos como uma equipe 2. Observe que os SDSpLVQmRVmRLQGLYtGXRV; em vez disso, são uma descrição do comportamento e das responsabilidades que os indivíduos devem ter no negócio 3. Os papéis não são pessoas; pelo contrário, eles descrevem como as pessoas se comportam no negócio e quais são as responsabilidades que elas têm. Papel 1. Normalmente os papéis são desempenhados por uma pessoa ou um grupo de pessoas que trabalham juntas em equipe 2. Um membro da equipe do projeto geralmente desempenha muitos papéis distintos 3. Cada membro da organização de desenvolvimento de software usa diferentes chapéus, isto é, desempenha papéis diferentes. 13
Papel 1. Apesar de a maioria dos papéis serem desempenhados por pessoas que fazem parte da organização, as pessoas de fora da organização têm um papel importante: por exemplo, o papel do envolvido do projeto ou produto que está sendo desenvolvido 2. Os papéis têm um conjunto de atividades coerentes por eles executadas. Essas atividades são estreitamente relacionadas e combinadas em termos de funcionalidade, e é recomendável que elas sejam executadas pela mesma pessoa. Papéis 14
3DSpLVGRV$QDOLVWDV Analista de Sistemas Designer de Negócios Revisor do Modelo de Negócios Analista do Processo de Negócios Revisor de Requisitos Especificador de Requisitos Analista de Teste Designer de Interface de Usuário 3DSpLVGRV'HVHQYROYHGRUHV Designer de Cápsula Revisor de Código Designer de Banco de Dados Implementador Integrador Arquiteto de Software Revisor de Arquitetura Revisor de Design Designer Designer de Teste Outros Papéis 3DSpLVGR7HVWDGRU Testador 3DSpLVGRV*HUHQWHV Engenheiro de Processo Gerente de Projeto Gerente de Controle de Mudança Gerente de Configuração Gerente de Implantação Revisor do Projeto Gerente de Testes 2XWURV3DSpLV Envolvidos Todos os Papéis Desenvolvedor do Curso Artista Gráfico Especialista em Ferramentas Administrador de Sistema Redator Técnico RUP 15
Atividade 1. Uma atividade é algo que um papel faz e produz um resultado significativo no contexto do projeto 2. Uma atividade é uma unidade de trabalho que um indivíduo, desempenhando o papel descrito, pode ser chamado a realizar 3. Toda atividade é atribuída a um papel específico, logo os papéis possuem atividades que definem o trabalho que executam. Atividade 1. A atividade tem uma finalidade clara, normalmente expressa em termos da criação ou atualização de alguns artefatos como um modelo, uma classe, um plano 2. As atividades estão fortemente relacionadas aos artefatos. Os artefatos fornecem a entrada e a saída para as atividades... 16
RUP Artefato 1. Um DUWHIDWR é um produto de trabalho (final ou intermediário) do processo: os papéis usam os artefatos para executar atividades e produzem artefatos ao executarem as atividades 2. As atividades possuem artefatos de entrada e saída 3. Os artefatos são responsabilidade de um único papel. Correspondem produtos de trabalho ou unidades de trabalho de outros processos 4. Embora um artefato "pertença" a uma pessoa, muitas outras podem utilizá-lo e, talvez, até atualizá-lo se tiverem permissão. 17
Artefato 1. Os artefatos são usados para capturar e transmitir informações do projeto. Um artefato pode ser um dos seguintes elementos: ƒ ƒ ƒ Um GRFXPHQWR, como Caso de Negócio ou Documento de Arquitetura de Software Um PRGHOR, como o Modelo de Casos de Uso ou o Modelo de Design Um HOHPHQWRGRPRGHOR, ou seja, um elemento existente em um modelo, como uma classe ou um subsistema. Artefato 1. Os artefatos estão sujeitos a controle de versão e a gerenciamento de configuração 2. Geralmente, os artefatos não são documentos, principalmente documentos em papel 3. O RUP não recomenda a produção sistemática de documentos em papel, mas que os artefatos fiquem dentro da ferramenta apropriada para criá-lo e gerenciá-lo 4. Os artefatos são organizados em conjuntos que correspondem às disciplinas. Vários artefatos são usados em diversas disciplinas. Esses artefatos pertencem ao conjunto em que foram inicialmente produzidos. 18
Artefato RUP 19
Pontos de Verificação e Diretrizes 1. Apresentam informações sobre como desenvolver, avaliar e utilizar os artefatos 2. Diretrizes do artefato capturam a essência da realização do trabalho 3. Os pontos de verificação fornecem uma referência rápida para ajudar você a avaliar a qualidade do artefato... Templates 1. Templates são "modelos" ou protótipos de artefatos 2. Associados à descrição do artefato estão um ou mais templates que podem ser utilizados para criar os artefatos correspondentes. 20
Relatórios 1. Modelos e elementos do modelo possuem UHODWyULRV associados a eles, que extraem informações sobre os mesmos 2. Diferentemente dos artefatos regulares, os relatórios não estão sujeitos a controle de versão 3. Eles podem ser reproduzidos a qualquer hora, basta retornar aos artefatos que os geraram. RUP 21
Orientações de Trabalho 1. As atividades podem possuir Orientações de Trabalho associadas, que apresentam conselhos práticos e técnicas úteis para o papel que executa a atividade. Mentor de Ferramentas Mentor de Ferramentas 1. Os mentores de ferramentas constituem um meio adicional de orientação, pois eles mostram como executar os passos usando uma ferramenta de software específica 2. Os mentores de ferramentas são fornecidos no RUP, vinculando suas atividades a ferramentas como Rational Rose, Rational RequisitePro, Rational ClearCase, Rational ClearQuest, Rational Suite TestStudio. 22
RUP Fases 1. O ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal 2. Uma passagem pelas quatro fases é um FLFORGH GHVHQYROYLPHQWR 3. Cada passagem pelas quatro fases produz uma JHUDomRdo software 4. Os ciclos subseqüentes são chamados de FLFORV GHHYROXomR. 23
Fases Ciclos de Evolução Ciclos de Evolução 1. Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante... 24
Iniciação ou Concepção 1. A meta dominante da fase de concepção (iniciação) é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto 2. Os objetivos principais da fase de iniciação incluem: ƒ Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto ƒ Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design ƒ Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos. Iniciação ou Concepção 2. Os objetivos principais da fase de iniciação incluem (continuação): ƒ Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração imediatamente a seguir) ƒ Estimar riscos em potencial (as origens de imprevistos) ƒ Preparar o ambiente de suporte para o projeto. 25
Concepção - Marco 1. No fim na fase de iniciação está o primeiro marco mais importante do projeto ou 0DUFRGRV 2EMHWLYRVGR&LFORGH9LGD 2. Neste momento você decide prosseguir com o projeto ou cancelá-lo. Concepção - Marco ƒ ƒ ƒ ƒ &ULWpULRVGH$YDOLDomR Consentimento dos envolvidos sobre a definição do escopo e as estimativas de custo/ programação Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma compreensão compartilhada desses requisitos Consenso de que as estimativas de custo/programação, as prioridades, os riscos e o processo de desenvolvimento são adequados Todos os riscos foram identificados e existe uma estratégia atenuante para cada um 2. O projeto poderá ser anulado ou completamente repensado caso ele não atinja este marco. 26
Fases Elaboração 1. A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção 2. Os objetivos primários da fase de elaboração incluem: ƒ Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento. 27
Elaboração 1. Os objetivos primários da fase de elaboração incluem (continuação): ƒ Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto ƒ Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto. Elaboração 1. Os objetivos primários da fase de elaboração incluem (continuação): ƒ Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos descartados para diminuir riscos específicos como: ƒ trocas de design/ requisitos ƒ reutilização de componentes ƒ possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais ƒ ƒ Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo Estabelecer um ambiente de suporte. 28
Elaboração - Marco 1. No fim na fase de elaboração está o segundo marco mais importante do projeto, o 0DUFRGD $UTXLWHWXUDGR&LFORGH9LGD 2. Nesse momento, você examina os objetivos e o escopo detalhados do sistema, a opção de arquitetura e a resolução dos principais riscos. Elaboração - Marco &ULWpULRVGH$YDOLDomR ƒ A Visão e os requisitos do produto são estáveis ƒ A arquitetura é estável ƒ As abordagens principais a serem usadas no teste e na avaliação foram comprovadas ƒ O teste e a avaliação de protótipos executáveis demonstraram que os principais elementos de risco foram tratados e resolvidos com credibilidade ƒ Os planos de iteração para a fase de construção têm detalhes e fidelidade suficientes para permitir o avanço do trabalho. 29
Elaboração - Marco &ULWpULRVGH$YDOLDomRFRQWLQXDomR ƒ Os planos de iteração para a fase de construção são garantidos por estimativas confiáveis ƒ Todos os envolvidos concordam que a visão atual poderá ser atendida se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual ƒ A despesa real em oposição à despesa planejada com recursos é aceitável. Fases 30
Construção 1. A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline 2. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Construção 1. Os objetivos principais da fase de construção incluem: ƒ Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento e retrabalho desnecessários ƒ Atingir a qualidade adequada com rapidez e eficiência ƒ Atingir as versões úteis (alfa, beta e outros releases de teste) com rapidez e eficiência ƒ Concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades necessárias. 31
Construção 1. Os objetivos principais da fase de construção incluem (continuação): ƒ Desenvolver de modo iterativo e incremental um produto completo que esteja pronto para a transição para a sua comunidade de usuários ƒ Descrever os casos de uso restantes e outros requisitos, incrementar o design, concluir a implementação e testar o software ƒ Decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja implantado. Construção 1. Os objetivos principais da fase de construção incluem (continuação): ƒ Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento 2. Paralelismo: ƒ pode acelerar bastante as atividades de desenvolvimento ƒ mas também aumenta a complexidade do gerenciamento de recursos e da sincronização dos fluxos de trabalho. 32
Construção - Marco 1. No Marco da Capacidade Operacional Inicial, o produto está pronto para ser passado para a Equipe de Transição 2. Toda a funcionalidade já foi desenvolvida e todos os testes DOID (se houver algum) foram concluídos. Construção - Marco 1. Os critérios de avaliação para a fase de construção envolvem as respostas para estas questões: ƒ Este release do produto é estável e desenvolvido o suficiente para ser implantado na comunidade de usuários? ƒ Todos os envolvidos estão prontos para a transição para a comunidade de usuários? ƒ As despesas reais com recursos ainda são aceitáveis se comparadas com as planejadas?. 33
Fases Transição 1. O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais 2. Fase de Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário 3. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade 4. todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto. 34
Transição 5. No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento 6. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Transição 1. Os objetivos principais da Fase de Transição são: ƒ teste beta para validar o novo sistema em confronto com as expectativas do usuário ƒ teste beta e operação paralela relativa a um sistema legado que está sendo substituído ƒ treinamento de usuários e equipe de manutenção ƒ introdução a marketing, distribuição e equipe de vendas ƒ engenharia voltada para implantação, como preparação, empacotamento e produção comercial, introdução a vendas, treinamento de pessoal em campo. 35
Transição 1. Os objetivos principais da Fase de Transição são (continuação): ƒ atividades de ajuste, como correção de erros, melhoria no desempenho e na usabilidade ƒ avaliação das baselines de implantação tendo como base a visão completa e os critérios de aceitação para o produto ƒ obtenção do consentimento dos envolvidos de que as baselines de implantação estão completas ƒ obtenção do consentimento dos envolvidos de que as baselines de implantação são consistentes com os critérios de avaliação da visão. Transição - Marco 1. No fim na fase de transição está o quarto marco mais importante do projeto, o 0DUFRGR5HOHDVH GR3URGXWR 2. Nesse momento, você decide se os objetivos foram atendidos, e se outro ciclo de desenvolvimento deve ser iniciado. 36
Transição - Marco 1. Os critérios básicos de avaliação para a fase de transição envolvem as respostas para estas questões: ƒ O usuário está satisfeito? ƒ As despesas reais com recursos são aceitáveis se comparadas com as planejadas? 2. No Marco do Release do Produto, o produto está em produção e o ciclo de manutenção posterior ao release inicia.! O que é uma Iteração? 1. Cada uma das fases do RUP pode ser dividida em iterações 2. Cada iteração pode dar origem a uma versão de um produto executável, que sofrerá incrementos até a obtenção do produto final 3. Uma iteração abrange as atividades de desenvolvimento que conduzem à liberação de um produto uma versão do produto estável e executável, junto com qualquer outro elemento periférico necessário para usar esse release. " 37
O que é uma Iteração? 4. Portanto, uma iteração de desenvolvimento é de certa forma uma passagem completa por todas as disciplinas 5. Pelo menos Requisitos, Análise & Design, Implementação e Teste 6. É como um pequeno projeto cascata em si mesmo. Observe que os critérios de avaliação são estabelecidos quando cada iteração é planejada 7. A duração de uma iteração varia de acordo com o tamanho e a natureza do projeto. # Por que Iterar? 1. Tradicionalmente, os projetos foram organizados para percorrer cada disciplina em seqüência apenas uma vez. Esse procedimento conduz ao ciclo de vida cascata 2. Freqüentemente, ele resulta em um acúmulo de integração tardia na implementação, quando, pela primeira vez, o produto é criado e o teste começa 3. Aparecem os problemas que permaneceram ocultos por todo o processo de Análise, Design e Implementação, e o projeto é paralisado enquanto começa um longo ciclo de correção de erros... 38
Por que Iterar? 1. Uma maneira mais flexível (e menos arriscada) de continuar é percorrer várias vezes as diversas disciplinas de desenvolvimento 2. Desta forma é possível construir um melhor entendimento dos requisitos, planejar uma arquitetura robusta, e liberar uma série de implementações que são gradualmente mais completas 3. Esse procedimento chama-se ciclo de vida iterativo. A cada passagem, a seqüência de disciplinas do processo chama-se iteração. Por que Iterar? $ 39
Por que Iterar? 1. Portanto, do ponto de vista do desenvolvimento, o ciclo de vida do software é uma sucessão de iterações, por meio das quais o software se desenvolve de maneira incremental 2. A principal conseqüência dessa abordagem iterativa é que os conjuntos de artefatos, descritos anteriormente, crescem e amadurecem o tempo todo, como mostra o diagrama a seguir. Por que Iterar? $ 40
Release 1. Existem dois tipos de release: internos ou externos 2. Um release interno é usado apenas pela organização de desenvolvimento, como parte de um marco, ou para fazer uma demonstração para usuários ou clientes 3. Um release externo é liberado para os usuários finais. Um release não é necessariamente um produto completo, mas pode ser apenas uma etapa ao longo do caminho 4. Uma das funções dos releases é forçar a equipe de desenvolvimento a fazer fechamentos em intervalos regulares. $ Release 5. Iterações e releases permitem um uso contínuo melhor das várias especialidades da equipe: designers, testadores, escritores etc 6. Releases regulares permitem que você fragmente os problemas de integração e teste, e os distribua pelo ciclo de desenvolvimento 7. A cada iteração, os artefatos são atualizados. Dizem que isso se parece um pouco com software "em crescimento". Em vez de desenvolver artefatos uns após os outros, eles são desenvolvidos através do ciclo. $% 41
Release $! 42