EngSw 02.1 RUP ConceitosPraticas

WWW.DOMINANDOT I .COM .BR

Engenharia de Software

Rational Unified Process - RUP

Professor Marcio Victorino – [email protected]

Sintomas de Problemas no Desenvolvimento de Software

Necessidades do usuário ou negócio não atendidas

Requisitos Instáveis

Módulos que não se integram

Dificuldades de Manutenção

Descoberta tardia de erros

Qualidade ou experiência do usuário pobres

Performance de carga sofrível

Esforço descoordenado da equipe

Questões de versionamento

2

Desenvolvimento Iterativo

Melhores PráticasMelhores Práticas

Desenvolvimento IterativoGerenciamento de Requisitos

Uso da Arquitetura de ComponentesModelagem Visual (UML)

Contínua Verificação da QualidadeGerenciamento de Mudança




3


Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida

que consiste em várias iterações. Uma iteração incorpora um conjunto

quase seqüencial de atividades em modelagem de negócios, requisitos,

análise e projeto, implementação, teste e implantação, em várias

proporções, dependendo do local em que ela está localizada no ciclo de

desenvolvimento.

4


5


6


Vantagens

Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente.

As táticas e os requisitos variáveis são acomodados.

A melhoria e o refinamento do produto são facilitados, resultando em um produto

mais robusto.

As organizações podem aprender a partir dessa abordagem e melhorar seus processos.

A capacidade de reutilização aumenta.

7

Gerenciamento de Requisitos








8


"uma condição ou uma capacidade com a qual o sistema deverá estar em

conformidade"

O gerenciamento de requisitos é uma abordagem sistemática para localizar,

documentar, organizar e controlar os requisitos variáveis em um sistema.

9


O gerenciamento de requisitos é definido formalmente como uma

abordagem sistemática a identificar, organizar e documentar os requisitos

do sistema, além de firmar e atualizar acordos entre o cliente e a equipe do

projeto sobre os requisitos variáveis do sistema.

As chaves para o gerenciamento eficaz de requisitos incluem manter uma

sentença clara dos requisitos, junto com os atributos aplicáveis e a

rastreabilidade para outros requisitos e outros artefatos do projeto.

10


A coleta de requisitos pode parecer uma tarefa bem precisa. Na realidade, porém, os projetos enfrentam

dificuldades pelos seguintes motivos:

Nem sempre os requisitos são óbvios e podem vir de várias fontes.

Existem diversos tipos de requisitos em diferentes níveis de detalhe.

O número de requisitos pode se tornar impossível de gerenciar se eles não forem controlados.

Os requisitos estão relacionados uns com os outros, e também com o produto liberado do processo de engenharia do

software.

Os requisitos têm propriedades exclusivas ou valores de propriedade. Por exemplo, eles não são necessariamente

igualmente importantes ou igualmente fáceis de se atender.

Há várias partes interessadas, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de

diferentes funções.

Os requisitos são alterados.

11








Uso da Arquitetura de Componentes

12


Os componentes são grupos de código coesos, na forma de código

fonte ou executável, com interfaces bem definidas e

comportamentos que fornecem forte encapsulamento do conteúdo

e são, portanto, substituíveis.

As arquiteturas baseadas em componentes tendem a reduzir o

tamanho efetivo e a complexidade da solução e, portanto, são

mais robustas e flexíveis.

13

Um componente de software pode ser definido como um pedaço não-

trivial de software, um módulo, um pacote ou um subsistema, sendo que

todos desempenham uma função clara, possuem uma fronteira clara e

podem ser integrados em uma arquitetura bem definida. É a realização

física de uma abstração do design.


14

Modelagem Visual (UML)








15


A modelagem visual aumenta o nível de abstração16


A modelagem visual é o uso de notações de design gráficas e textuais,

semanticamente ricas, para capturar designs de software.

Uma notação, como a UML, permite que o nível de abstração seja

aumentado, enquanto mantém sintaxe e semântica rígidas.

Dessa maneira, a comunicação na equipe de design melhora, à medida que

o design é formado e revisado, permitindo ao leitor raciocinar sobre ele e

fornecendo uma base não ambígua para a implementação.

17


Para:

Capturar a estrutura e o comportamento.

Exibir como os elementos do sistema se integram.

Manter projeto e implementação consistentes.

Esconder ou exibir detalhes como for apropriado.

Proporcionar uma comunicação não ambígua.

UML provê uma linguagem comum para todos os técnicos envolvidos no projeto.

18

Verificação da Qualidade








19


Dicionário:

Uma característica inerente ou diferenciada; uma propriedade.

Superioridade de natureza.

Grau ou classificação de excelência.

A qualidade não é uma dimensão única, mas várias. Para usar a definição e aplicá-la ao

desenvolvimento de software, ela precisa ser refinada.

"característica de ter demonstrado a realização da criação de um produto que atende ou excede os

requisitos acordados, conforme avaliado por medidas e critérios acordados, e que é criado em

um processo acordado"

20


A localização e a solução dos problemas de software ficam de 100 a 1.000

vezes mais caros, se realizados após a implantação. A verificação e o

gerenciamento da qualidade durante o ciclo de vida do projeto é essencial

para atingir os objetivos corretos no momento certo.

21


Obter qualidade não é simplesmente "atender a requisitos" ou produzir um

produto que atende às necessidades e expectativas dos usuários. Pelo

contrário, a qualidade também inclui a identificação das medidas e dos

critérios para demonstrar a obtenção da qualidade e a implementação de

um processo para garantir que o produto por ele criado tenha atingido o

grau desejado de qualidade e possa ser repetido e gerenciado.

22

Gerenciamento de Mudanças








23


Um desafio importante quando se está desenvolvendo sistemas intensivos

de software é lidar com vários desenvolvedores, organizados em diferentes

equipes, possivelmente em diferentes locais, trabalhando juntos em várias

iterações, releases, produtos e plataformas.

Na ausência de controle disciplinado, o processo de desenvolvimento

rapidamente se transforma em caos. Gerenciamento de Mudança consiste

de um recurso utilizado para superar esse desafio.

24


Coordenação de Atividades e de Artefatos

Coordenação de Iterações e de Releases

Controle de Mudanças no Software

ALERTARelatório de

Gerenciamento deÁrea de Trabalho

Processo deIntegração

Desenvolvimento Paralelo

Controle de

Versões

GM é mais do que simplesmente

check-in e check-out.

25

Princípios Chave (Key Principles)

Adaptar Processos.

Balancear Prioridades dos Interessados.

Colaboração entre Times.

Demonstrar Valor da Iteratividade.

Elevar o Nível de Abstração.

Foco contínuo na Qualidade.

26

Adaptar Processos.

Ciclo de vida eficiente.

Incrementar a agilidade do projeto.

Planos e estimativas realísticas.

27

Balancear Prioridades dos Interessados

Alinhar aplicativos às necessidades do negócio e dos usuários.

Reduzir desenvolvimento customizado.

Otimizar o valor do negócio.

28

Colaboração entre Times

Incrementar a produtividade do time.

Melhorar o acoplamento entre necessidades do negócio e

desenvolvimento e operação dos aplicativos.

29

Demonstrar Valor da Iteratividade

Redução de risco prematura.

Prognostico ao longo do projeto.

Concordância entre interessados.

30

Elevar o Nível de Abstração.

Produtividade.

Redução da complexidade.

31

Foco contínuo na Qualidade.

Alta qualidade.

Incremento do progresso e da qualidade prematuramente.

32

Processo de Desenvolvimento de Sw

Funções:

Orienta a ordem das atividades de uma equipe.

Especifica quando e quais artefatos devem ser produzidos.

Direciona as tarefas individuais dos desenvolvedores e a equipe como um todo.

Oferece critérios para monitorar e medir os produtos e atividades do projeto.

33

Rational Unified Process (RUP)

O Rational Unified Process (também chamado de processo RUP) é um

processo de engenharia de software. Ele oferece uma abordagem baseada

em disciplinas para atribuir tarefas e responsabilidades dentro de uma

organização de desenvolvimento. Sua meta é garantir a produção de

software de alta qualidade que atenda às necessidades dos usuários dentro

de um cronograma e de um orçamento previsíveis.

34

Processo em Equipe

Um processo define quem (papel) está fazendo o quê (produto de

trabalho), como (tarefa) e quando (fluxo) de modo a alcançar

determinado objetivo.

Requisito novo

ou modificado

Sistema novo

ou modificado

Processo deEngenharia de Software

35

Work Product

Work Product é uma abstração geral que representa algum resultado de

um processo.

Pode ser um dos seguintes elementos:

Artifact (Artefato);

Deliverable (Entrega);

Outcome (Resultado).

36

Artefatos

Observações:

O rup desencoraja o uso de artefatos em papel, priorizando o uso de mídia.

Cada artefato deve ter apenas um responsável (na versão 2003, na 7 não existe essarestrição).

Podem ser organizados em cinco conjuntos de informação:

Conjunto de gerenciamento.

Conjunto de requisitos.

Conjunto de projeto.

Conjunto de implementação.

Conjunto de distribuição.

37

Artefatos

Artefatos são produtos de trabalho tangíveis e bem definidos consumidos, produzidos ou

modificados por tarefas. Artefatos podem ser compostos por outros artefatos. São exemplos de

artefatos:

Um modelo, como o Modelo de Casos de Uso ou o Modelo de Design.

Um elemento do modelo, ou seja, um elemento existente em um modelo, como uma classe ou um

subsistema.

O RUP não incentiva a criação de documentos impressos, tendo em vista que o importante é

possuir modelos em ferramentas e gerar relatórios quando necessário.

Um artefato pode ser modificado por vários papéis.

38

Artefatos

39

Entrega

Uma Entrega é um produto de trabalho que provê uma descrição

e definição para o empacotamento de outro produto de trabalho.

Uma Entrega é utilizada para pré-definir um conteúdo típico ou

recomendado da forma que um produto de trabalho deve ser

empacotado para a entrega.

40

Resultado

Um resultado descreve produtos de trabalho intangíveis como um

resultado ou um estado como um servidor instalado ou uma rede

otimizada.

Resultados não possuem templates associados ou exemplos e não

é possível a sua reusabilidade.

41

Papeis (Roles)

O conceito mais central no Processo é o conceito de papel. 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, no contexto de uma organização de

engenharia de software.

42

Papeis (Roles)

Um papel é uma definição abstrata de um conjunto de atividades executadas e dos

respectivos artefatos.

Normalmente os papéis são desempenhados por uma pessoa ou um grupo de

pessoas que trabalham juntas em equipe.

Um membro da equipe do projeto geralmente desempenha muitos papéis

distintos.

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.

43

Tarefa

Os papéis possuem tarefas que definem o trabalho que executam.

Uma tarefa é uma unidade de trabalho que um indivíduo, desempenhando o

papel descrito, pode ser chamado a realizar.

A tarefa tem uma finalidade clara, normalmente expressa em termos da criação

ou atualização de alguns artefatos como um modelo, uma classe, um plano.

Toda tarefa é atribuída a um papel específico.

Em geral, a granularidade de uma tarefa é de duração de algumas horas a

alguns dias e, em geral, envolve um papel e afeta um ou alguns artefatos.

44

Tarefa

As tarefas são divididas em passos. Os passos podem pertencer a três categorias

principais:

Passos de reflexão: nos quais o indivíduo que executa o papel compreende a natureza da

tarefa, reúne e examina os artefatos de entrada e formula a saída.

Passos de execução: nos quais o indivíduo que executa o papel cria ou atualiza alguns

artefatos.

Passos de revisão: nos quais o indivíduo que executa o papel analisa os resultados em

relação a alguns critérios.

45

Produto de Trabalho x Papel x Tarefa

Papel

Produto de Trabalho

Tarefa

46

Atividade

Uma tarefa descreve uma unidade de trabalho.

Toda tarefa é desempenhada por papéis específicos.

A granularidade de uma tarefa é de duração de algumas horas a alguns dias e, em

geral, envolve um papel e afeta um ou um pequeno número de produtos de

trabalho.

Tarefas não são necessariamente utilizadas como base para o planejamento por

possuirem uma “granulação fina” (muito detalhadas).

Atividades, grupos de tarefas, normalmente são utilizadas para efeito de

planejamento e controle dos projetos.

47

Observações

Riscos no RUP:

Riscos de Integração.

Riscos Arquitetônicos.

Categorias de Mudanças no RUP:

Mudança de Requisitos.

Mudanças Táticas.

Lançar um produto mais cedo com menos funcionalidades.

Mudanças Tecnológicas.48

Rational Unified Process - Características

Iterativo e Incremental

O software é desenvolvido em várias passadas (iterativo), cada passada acrescenta uma parte à

solução (incremental).

Guiado por casos de uso

Os casos de uso definidos para o sistema são a fundação para o resto do processo de

desenvolvimento.

Centrado na arquitetura

Isso significa que, para o RUP, os aspectos mais importantes do desenvolvimento de softwares (ou

seja, os aspectos relacionados aos maiores riscos de um projeto de desenvolvimento) estão

intimamente ligados à arquitetura. Sendo assim, devemos então tratar como centro (core) do nosso

desenvolvimento, nossos requisitos arquiteturais do projeto.

49

Rational Unified Process

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:

representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de

fases, iterações e marcos.

o eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por

natureza:

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 (consulte Conceitos-

chave).

50


Perspectivas do RUP (SOMMERVILLE, 2011, p. 34):

Perspectiva Dinâmica: mostra as fases do modelo ao longo do tempo.

Perspectiva Estática: mostra as atividades realizadas no processo.

Perspectiva Prática: sugere as boas práticas a serem usadas durante o processo.

(SOMMERVILLE, 2011, p. 34)

“... mas eu gostaria de ter lido mais sobre asdificuldades práticas do uso do processo.”

51


52

Observações Tempo médio de uma iteração: 2 à 6 semanas. Número médio de iterações: 6 ± 3. Considerando as fases [I, E, C, T]:

3 iterações: [0, 1, 1, 1]. 6 iterações:[1, 2, 2, 1]. 9 iterações:[1, 3, 3, 2].

Disciplina Modelagem de Negócio é opcional. RUP Small Project Lifecycle Não possui as

disciplinas: Modelagem de Negócio. Implantação.

53


54

Ciclo de Desenvolvimento Completo

MN

R

AD

IM

I

T

MN

R

AD

IM

I

T

MN

R

AD

IM

I

T

MN

R

AD

IM

I

T

MN

R

AD

IM

I

T

MN

R

AD

IM

I

T

MN - Modelagem de NegóciosR - Requisitos

AD - Análise e DesignI - Implementação

T - TestesIM - Implantação

Iniciação

Elaboração

Construção Transição

Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5 Iteração 6

Ciclo de Desenvolvimento Completo

55

Fases do RUP

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software

do RUP é dividido em quatro fases seqüenciais, cada uma concluída por

um marco principal, ou seja, cada fase é basicamente um intervalo de

tempo entre dois marcos principais.

56

Fases do RUP

As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de

acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio

tamanho deve prever a seguinte distribuição de esforço e programação:

57

Fases do RUP

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases produz

uma geração do software. A menos que produto "desapareça", ele irá se desenvolver na próxima geração,

repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase

diferente nas diversas fases. Esses ciclos subseqüentes são chamados de ciclos de evolução. À medida que o

produto atravessa vários ciclos, são produzidas novas gerações.

58

Fim

Professor Marcio Victorino 59

Documents

EngSw 02.1 RUP ConceitosPraticas