Prof. Geraldo Braz Junior Processo Unificado Referncias: Medeiros, E. Desenvolvendo Software com UML 2.0: Definitivo, Makron Books, 2006. Pressman, R. S. Engenharia de Software, McGraw-Hill, 6. Edio, 2006 Sommerville, I. Engenharia de Software, 8 edio, 2007. Sumrio Breve Histrico Caractersticas Ciclo de Vida Fluxos de Trabalho Os artefatos do PU RUP 2 Introduo O processo unificado encaixa-se na definio de processo: Um conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de software. O PU tambm uma estrutura genrica de processo que pode ser customizado adicionando-se ou removendo-se atividades com base nas necessidades especficas e nos recursos disponveis para o projeto. 3 Histrico O PU tem suas razes no trabalho feito por Ivar Jacobson na decada de 60; Em 87 Jacobson deixou a empresa Ericsson, em que trabalhava, iniciando uma companhia chamada Objectory AB; Desenvolveram o Objectory, que era semelhante em estrutura com(Processo e Protudo) ao que hoje o RUP; Seu livro Object-Oriented Software Engineering foi um marco na comunidade OO; 4 Histrico Alguns anos apos a Rational comprou a Objectory AB; Em 94 foi construido o Processo Objectory da Rational (ROP) em paralelo com o Mtodo Unificado, que depois foi chamado de UML; Em 98 a Rational mudou o nome do produto-processo para RUP. 5 Histrico Apesar do PU utilizar a UML para atividades de modelagem, eles so intrinsecamente separados A UML independente de processo. Qualquer que seja o processo usado no desenvolvimento de um projeto, a UML poder ser utilizada para registrar as decises de anlise e de projeto resultantes 6 Caractersticas do PU um framework genrico de um processo de desenvolvimento baseado em componentes que realizam as interfaces Utiliza toda a definio da UML Alicerces: Dirigido por Casos de Uso Centrado na Arquitetura Desenvolvimento iterativo e incremental os 4 Ps:pessoa, projeto, produto e processo 7 P4 = Pessoa, Projeto, Produto, Processo PESSOAS financiam, escolhem, desenvolvem, gerenciam, testam, usam e so beneficiadas por produtos PROJETOS sofrem alteraes. Determinam os tipos de pessoas que iro trabalhar no projeto e os artefatos que sero usados ARTEFATO qualquer tipo de informao criada por uma pessoa (diagramas UML, textos, modelos de interfaces) 8 P4 = Pessoa, Projeto, Produto, Processo PRODUTO cdigo fonte, cdigo de mquina, subsistemas, classes, diagramas: interao, de estados e outros artefatos PROCESSO define quem (papel/pessoa/ trabalhadores) faz o que (artefato), quando (disciplina) e como (atividades) PU um processo. Considera fatores organizacionais, do domnio, ciclo de vida e tcnicos 9 Trabalhadores e Atividades Trabalhadores: Um trabalhador algum que desempenha um papel e responsvel pela realizao de atividades para produzir ou modificar um artefato. Exemplos: analista de sistemas, programador, testador etc. Atividades: tarefa que um trabalhador executa a fim de produzir ou modificar um artefato. 10 Disciplinas Descreve as seqncias das atividades que produzem algum resultado significativo e mostra as interaes entre os participantes So realizadas a qualquer momento durante o ciclo de desenvolvimento (Fases do PU) Ex. Requisitos, Anlise, Projeto, Implementao e Teste 11 Dirigido por Casos de Uso Um caso de uso uma seqncia de aes, executadas por um ou mais atores, que produz um ou mais resultados de valor para um ou mais atores. Um ator uma pessoa ou outro sistema. Os casos de uso possibilitam que os requisitos funcionais possam ser capturados na perspectiva de cada um dos usurios do sistema Definir comportamento, validao 12 Casos de Uso Arquitetura do sistema dirige influi Por que Casos de Uso? Os requisitos funcionais so registrados preferencialmente por meio deles Eles ajudam a planejar as iteraes Eles podem conduzir o projeto O teste baseado neles. Modelo casos de uso = casos de uso = funcionalidade do sistema 13 Dirigido a Casos de Uso - Ilustrao 14 <arquivo> Classe de fronteira Classe de controle Classe de entidades Modelo USE-CASE Modelo ANLISE Modelo PROJETO Classe Modelo IMPLEMENT <executvel> <arquivo> relacionamento Centrado na arquitetura Uma arquitetura um mapa do sistema: Define partes do mesmo Relacionamentos Interaes Mecanismos de interconexo, Por isso, importante definir uma arquitetura cedo e refin-la com o tempo. 15 Centrado na arquitetura O Processo Unificado centrado na arquitetura e esta descrita como diferentes vises do sistema, sendo influenciada pelos casos de uso, sistemas existentes, plataforma de desenvolvimento, framework, etc. A arquitetura importante porque: Ajuda a entender a viso global Ajuda a organizar o esforo de desenvolvimento Facilita as possibilidades de reuso Facilita a evoluo do sistema Tem base nos casos de uso especificados. 16 Centrado na arquitetura Casos de Uso Plataforma de software Disponibilidade de blocos reusveis Sistemas existentes Hardware existente Requisitos no-funcionais (performance, segurana) Arquitetura influem 17 Desenvolvimento Iterativo e Incremental O PU basicamente um processo de desenvolvimento iterativo e incremental, no qual o software no implementado a partir de um instante no fim do projeto, mas ao contrrio, o ciclo de vida no PU desenvolvido e implementado em iteraes. Uma iterao um miniprojeto que resulta em uma verso do sistema liberada interna ou extermamente; Essa verso oferece uma melhora incremental sobre a iterao anterior. 18 Desenvolvimento Iterativo e Incremental Para cada iterao os desenvolvedores tero que identificar e especificar os casos de usos relevantes, desenvolver a atividade usando a arquitetura escolhida como guia, implementar o modelo de design em componentes e verificar se estes satisfazem os casos de uso. Benefcios: Identificao de riscos adiantada Preparao do sistema para requisitos que mudam Integrao contnua (facilita testes) e aprendizado facilitado Resultado de uma iterao: incremento. 19 Incremento 20 Sistema(i) Sistema(i)+1 ciclo fase iterao Ciclo de Vida O Processo Unificado consiste de vrias interaes no ciclo de vida de um sistema. O ciclo formado por quatro fases: Concepo Elaborao Construo Transio Cada fase, por sua vez, subdivida em iteraes que passam por todos os cincos fluxos do trabalho do processo: Requisitos, Anlise, Projeto, Implementao e Teste. 21 Ciclo de Vida 22 Concepo O objetivo estabelecer a viabilidade do sistema proposto. Nessa fase se faz: Definio do escopo do sistema. Estimativas de custos e cronograma Identificao dos potenciais riscos que devem ser gerenciados ao longo do projeto Esboo da arquitetura do sistema, que servir como alicerce para a sua construo. Cada iterao est voltada para a produo de casos de uso de negcio e da arquitetura preliminar 23 Elaborao O objetivo capturar o que pode ser feito no sistema com as restries financeiras e outras questes levantadas. Nessa fase se faz: Captura dos requisitos funcionais da aplicao (que no foram capturados na fase de concepo). Expanso do esboo da arquitetura para uma arquitetura base para o desenvolvimento do sistema. Abordagem dos riscos significativos. Elaborao de um plano com questes econmicas indicando como o projeto vai evoluir na fase de construo. 24 Elaborao Vrios dos casos de uso so especificados com detalhes; a arquitetura do sistema projetada A arquitetura expressa em vises dos modelos do sistema: modelo de casos de uso modelo de anlise modelo de projeto modelo de implementao modelo de distribuio O resultado da fase o conjunto dos modelos acrescidos de elementos de implementao 25 Construo Nesta fase, as iteraes esto voltadas para a produo de mdulos executveis, culminando com o desenvolvimento de um produto pronto para entrega comunidade de usurios Durante esta fase o produto construdo O sistema torna-se um produto pronto para ser posto disposio da comunidade de usurios 26 Construo A arquitetura estvel, ainda que possa ser aperfeioada Ao final da fase, o sistema conter todos os casos de uso que gernciam e usurios concordaram em desenvolver para esta verso do produto Erros podero ser encontrados e sero corrigidos 27 Transio Compreende o perodo em que o produto passa para beta-teste; a primeira verso entregue aos usurios A fase envolve atividades de treinamento de usurios, assistncia de uso do produto e correo de defeitos encontrados aps a entrega Um pequeno nmero de usurios experientes utiliza o produto e reporta os erros e inadequaes encontradas Os desenvolvedores corrigem os erros e incorporam melhorias 28 Ciclo de Vida 29 Fluxos de Trabalho Avaliando-se as fases do PU, pode-se ter a impresso de que cada ciclo de iterao comporta-se como o modelo em cascata. Mas isso no verdade: paralelamente s fases do PU, os fluxos de trabalho (requisitos, anlise, projeto, implementao, testes), denominados disciplinas do PU, so realizados a qualquer momento durante o ciclo de desenvolvimento. Disciplinas podem ter maior nfase durante certas fases e menor nfase em outras 30 Fluxo: Requisitos Durante o fluxo de trabalho, os requisitos do sistema so especificados atravs da identificao das necessidades de usurios e clientes Estes requisitos funcionais so expressos em casos de uso atravs do modelo de casos de uso O modelo de casos de uso desenvolvido em vrios incrementos, onde as iteraes iro adicionar novos casos de uso e/ou adicionar detalhes as descries dos casos de uso existentes. 31 Requisitos Durante a fase de concepo, os casos de uso mais importantes so identificados, delimitando o domnio do sistema. Durante a fase de elaborao, a maioria dos requisitos remanescentes capturada, assim desenvolvedores podero saber o quo devero se empenhar para desenvolver o sistema 32 Requisitos Ao final da fase de elaborao, devem ter sido capturados e descritos cerca de 80% dos requisitos do sistema Porm, apenas 5% a 10% destes requisitos so implementados nesta fase Os requisitos que sobram so capturados e implementados durante a fase de construo. Na fase de transio quase no h requisitos a serem capturados, a menos que ocorram mudanas nos mesmos. 33 Anlise O produto do fluxo de anlise o modelo de anlise. O modelo tem a funo de refinar os requisitos especificados no fluxo anterior (fluxo de requisitos) atravs da construo de diagramas de classes conceituais permitindo, desta forma, argumentao a respeito do funcionamento interno do sistema. 34 Anlise O modelo de anlise fornece mais poder expressivo e formalismo como diagramas de interaes (Sequncia ou Comunicao)e diagrama de estados que representam a dinmica do sistema. O fluxo de anlise tem maior importncia durante fase de elaborao Isso contribui para a definio de uma arquitetura estvel e facilita o entendimento detalhado dos requisitos. 35 Projeto No fluxo de projeto o sistema moldado e sua forma definida de maneira a suprir as necessidades especificadas pelos requisitos. Define um modelo de projeto que construdo com base no modelo de anlise definido no fluxo anterior. O fluxo de projeto desenvolve o modelo de projeto que descreve o sistema em um nvel fsico. 36 Projeto A funo principal deste fluxo obter uma compreenso detalhada dos requisitos do sistema, levando em considerao fatores como linguagens de programao, SO, tecnologias de banco de dados, interface com o usurio, etc. O fluxo de projeto possui seu enfoque entre o fim da fase de elaborao e o incio da fase de construo. Este fluxo serve de base para o fluxo de implementao 37 Projeto Os mesmos diagramas citados nos fluxos anteriores so construdos em um nvel mais fsico que conceitual O fluxo de projeto tambm podem utilizar o diagrama de objetos Enquanto que o fluxo de anlise se interessa por o que o sistema de fazer, o fluxo de projeto diz respeito a como os requisitos sero implementados 38 Implementao O fluxo de implementao baseado no modelo de projeto Implementa o sistema em termos de componentes (cdigo fonte, executvel, etc). A maior parte da arquitetura do sistema definida durante o projeto. 39 Implementao O modelo de implementao se limita: 1. Planejar as integraes do sistema em cada iterao. O resultado um sistema que implementado como uma sucesso de etapas pequenas e gerenciveis 2. Implementar os subsistemas encontrados durante o projeto 3. Testar as implementaes e integr-los, compilando-as em um ou mais arquivos executveis, antes de envia-los ao fluxo de teste. 40 Implementao Este fluxo tem maior importncia na fase de construo e apesar de ter suas caractersticas prprias, a maior parte de suas atividades realizada de forma quase mecnica, pelo fato das decises mais difceis terem sido tomadas durante o fluxo de projeto. O cdigo gerado durantes a implementao, deve ser uma simples traduo das decises de projeto em uma linguagem especfica. 41 Teste O fluxo de teste desenvolvido com base no produto do fluxo de implementao. Os componentes executveis so testados exaustivamente no fluxo de teste para ento ser disponibilizados aos usurios finais. O principal propsito do fluxo de teste realizar vrios testes e sistematicamente analisar os resultados de cada teste. 42 Teste Componentes que possurem defeitos retornaro a fluxos anteriores como os fluxos de projeto e implementao, onde os problemas encontrados podero ser corrigidos. Um planejamento inicial de testes pode ser feito j na fase concepo. 43 Teste A maior parte dos testes so feitos durante a fase de elaborao, quando a arquitetura do sistema definida, e durante a fase de construo quando o sistema implementado. Na fase de transio, o fluxo de testes se limita a correo de defeitos encontrados durante a utilizao inicial do sistema. 44 Teste O produto do fluxo de teste o modelo de teste O modelo de teste pode descrever: como componentes executveis, provenientes do fluxo de implementao, so testados. como aspectos especficos do sistema testados, como por exemplo, se a interface do usurio til e consistente ou se o manual do usurio cumpre seu objetivo. 45 Os Artefatos Cada uma das disciplinas do PU pode gerar um ou mais artefatos, que devem ser controlados e administrados corretamente durante o desenvolvimento do sistema. Artefatos so quaisquer dos documentos produzidos durante o desenvolvimento, tais como modelos, diagramas, documentos de especificao de requisitos, cdigo fonte ou executvel, planos de teste, etc. 46 Os Artefatos Muitos dos artefatos so opcionais, produzidos de acordo com as necessidades especficas de cada projeto. Exemplos: Diagrama de casos de uso Diagrama de Classes Diagrama de Sequncia Cdigo fonte Etc. 47 RUP Rational Unified Process uma instncia especfica e detalhada do Processo Unificado. Processo proprietrio de Engenharia de Software criado pela da RationalSoftware Corporation, adquirida pela IBM (atualmente IRUP) Fornece tcnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade 48 RUP Rational Unified Process um processo considerado pesado e preferencialmente aplicvel a grandes projetos. O fato de ser amplamente customizvel torna possvel que seja adaptado para projetos de qualquer escala O RUP , por si s, um produto de software. modular e automatizado, e toda a sua metodologia apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM atravs de seus "RationalSuites". 49 RUP Rational Unified Process Princpios e melhores prticas Gesto e Controle de Mudanas do Software Gerenciar requisitos Usar arquiteturas baseada em componentes Modelar o software visualmente (diagramas) Verificar a qualidade do software. 50 RUP Caratersticas Semelhante ao PU: Baseado em casos de uso Orientado a arquitetura Iterativo e incremental Etc. 51 RUP Fases Semelhante ao PU: Concepo Elaborao Construo Transio 52 RUP Disciplinas Gerencia de Projeto Modelagem de Negcio Requisitos Anlise e Projeto (unio de A/P do PU) Teste Configurao e gerncia de alteraes Ambiente Instalao 53 RUP Artefatos Conjunto de Gerncia Conjunto de Requisitos Conjunto de Projeto Conjunto de implementao Conjunto de Instalao 54 RUP Mtodos Concorrentes Cleanroom (considerado pesado) E os Metodosgeis (leves) como a Programao Extrema(XP-ExtremeProgramming), e outros 55 Concluso 56 O PU um processo de desenvolvimento dirigido por casos de uso, centrado na arquitetura e iterativo e incremental composto por 5 fluxos de trabalho Produz um conjunto de Artefatos O RUP uma instncia do PU voltado para projetos mais complexos.