RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

Transcrição

1 RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS Prof. Fabiano Papaiz IFRN

2 O RUP recomenda as seguintes práticas que devem ser utilizadas no desenvolvimento de um software: 1. Desenvolver de forma iterativa e incremental 2. Gerenciar os requisitos 3. Utilizar arquitetura de componentes 4. Modelar visualmente 5. Verificar continuamente a qualidade do software 6. Gerenciar as mudanças

3 1ª Desenvolver de forma Iterativa e Incremental

4 Desenvolver de forma iterativa e incremental permite: Que qualquer mudança seja acomodada mais facilmente durante o desenvolvimento do projeto A cada incremento gerado, podemos adaptar os requisitos a quaisquer mudanças que possam ocorrer nesse meio tempo Na pior dos casos, a equipe perderia o trabalho realizado em uma ou duas iterações, em vez do trabalho do projeto inteiro Que os riscos sejam diminuídos progressivamente A cada release do software, os riscos são diminuídos pois os requisitos são validados pelo cliente e as novas funcionalidades são integradas na arquitetura, permitindo que esta se torne cada vez mais confiável e robusta A cada iteração são realizados refinamentos sucessivos para melhorar o entendimento do problema

5 Desenvolver de forma iterativa e incremental permite: Melhorar o nosso processo à medida que o software vai sendo desenvolvido, fazendo os ajustes necessários e servindo como base para os futuros projetos Aumentar o reuso, pois conforme os componentes vão sendo implementados podemos identificar partes comuns entre eles, como também identificar componentes que já foram desenvolvidos e que podem ser reutilizados

6

7

8

9 2ª Gerenciar os Requisitos

10 Segundo o RUP, um requisito é uma condição ou uma restrição com a qual o sistema deverá estar em conformidade Os requisitos devem ser definidos de forma clara e objetiva, sem que haja ambiguidade de entendimento O gerenciamento de requisitos é uma abordagem sistemática para: Identificar os requisitos, Documentar os requisitos, Organizar e Controlar os requisitos Não basta apenas identificar e documentar os requisitos, temos que garantir que a documentação esteja sempre atualizada à medida que as mudanças ocorrerem

11 Devemos gerenciar os requisitos porque nem todos são simples ou óbvios, como um cadastro de cliente (CRUD) Podem haver requisitos mais complexos, onde suas definições venham de várias partes interessadas de dentro do projeto, podendo haver conflitos entre as partes Seu projeto pode possuir um número muito grande de requisitos, os quais podem se tornar impossíveis de se controlar se não forem gerenciados da forma correta As mudanças nos requisitos devem ser rastreadas, para podermos analisar o seu impacto nos demais requisitos Viabilidade, custo, prazo etc

12 O RUP recomenda a utilização de Casos de Uso como método para a organização dos requisitos funcionais do software projetado Diagramas de Casos de Uso Especificações de Casos de Uso O RUP é Guiado por Casos de Uso e estes serão utilizados em todas as suas fases e disciplinas

13 Os Casos de Uso serão utilizados por diversas partes interessadas no projeto, como por exemplo: Clientes Para terem uma visão geral das funcionalidades do sistema Arquitetos de Software Para identificarem as características da arquitetura Analistas, Projetistas, Desenvolvedores Para entenderem o comportamento do sistema, analisá-lo, projetá-lo e implementá-lo Testadores Para definirem os casos de testes do sistema Gerentes de Projeto Para planejarem e acompanharem o progresso do projeto

14 3ª Utilizar Arquitetura de Componentes

15 Segundo o RUP, a arquitetura de um sistema é a sua organização (ou estrutura) de componentes significativos que interagem entre si trocando mensagens através de suas interfaces Uma arquitetura não se preocupa apenas com os requisitos funcionais do software, preocupando-se também com os requisitos não-funcionais Desempenho Segurança Reuso Manutenibilidade Decisões tecnológicas etc

16 O RUP define os componentes como sendo grupos coesos de código fonte ou executável com interfaces e comportamentos bem definidos Possuem responsabilidades e funções claras e bem definidas Devem fornecer forte encapsulamento de conteúdo Outros componentes não precisam saber seus detalhes internos de funcionamento. Precisam conhecer apenas sua interface para poderem trocar mensagens com ele Podem ser substituídos sem causar impacto na arquitetura Exemplo: no caso onde seja necessário mudar a tecnologia de acessos aos dados de SQL puro para o Entity Framework

17 Os tamanhos dos componentes podem variar muito Podem ser desde uma classe apenas até uma biblioteca (ou API) contendo diversas classes Podem existir componentes terceirizados, de prateleira (OTS: Off-The-Shelf) Um módulo de comunicação com operadoras de cartões de crédito Servidores de banco de dados Servidores de aplicações web etc

18 Exemplo-01:

19 Exemplo-02:

20 No RUP a arquitetura é representada por uma série de visões diferentes, conhecida como Modelo de Visão 4+1. Analogia com Engª Civil: plantas baixa, hidráulica, elétrica etc

21 4ª Modelar Visualmente

22 O RUP utiliza a UML (Unified Modeling Language) como notação padrão para modelagem de software Com a padronização da linguagem de modelagem visual, podemos capturar requisitos com maior precisão, melhorando assim a comunicação entre as partes interessadas, visando diminuir a ambiguidade no entendimento do problema Com a UML, o software pode ser representado em um nível de abstração mais alto, para ser entendido de forma mais fácil pelo cliente e usuários, como também em níveis mais baixos, para entendimento entre a equipe técnica (analistas, programadores, arquitetos, DBA s etc)

23 5ª Verificar Continuamente a Qualidade do Software

24 Por que verificar a qualidade?

25 O RUP define qualidade como sendo: a característica de ter demonstrado a criação de um produto que atende ou excede os requisitos acordados, sendo esse avaliado por medidas e critérios acordados, utilizando-se um processo acordado

26 No RUP, podemos buscar a qualidade do software através de atividades de controle e garantia da qualidade Controle da Qualidade Possui foco no PRODUTO e em encontrar seus defeitos específicos Garantia da Qualidade Possui foco nos PROCESSOS e em como estes estão sendo executados Visa garantir que as coisas estão sendo feitas seguindo corretamente a metodologia empregada

27 A qualidade pode ser medida segundo vários critérios, como por exemplo: Andamento: progresso do projeto Variação: diferença entre planejado e executado Confiabilidade: robustez Funcionalidade: casos de uso implementados Desempenho: tempo de execução em diversas situações reais É muito importante que os critérios de qualidade sejam definidos e acordados pelas partes interessadas no início do projeto

28 6ª Gerenciar as Mudanças

29 Gerenciamento de mudanças é o processo de avaliar, coordenar e decidir sobre a realização das mudanças propostas no software projetado Podem ser solicitadas mudanças em diversos itens, como: Funcionalidades, Arquitetura, Código-Fonte, Banco de Dados, Metodologia, Ferramentas etc Somente as mudanças aprovadas deverão ser implementadas Implica em um processo formal de aprovação de mudanças Tolerância zero com as mudanças não aprovadas, principalmente em artefatos que fazem parte da iteração atual

30 No RUP, o gerenciamento de mudanças abrange as seguintes atividades: Coordenação de Atividades e Artefatos Definir procedimentos padronizados para gerenciar mudanças sobre os artefatos Coordenação de Iterações e Releases Manter o controle sobre os releases ao final de cada iteração Controle de Mudanças no Software Manter uma estrutura bem definida para gerenciar mudanças no software entregue

31 FIM