Post on 07-Feb-2016
description
WWW.DOMINANDOT I .COM .BR
Engenharia de Software
Rational Unified Process - RUP
Professor Marcio Victorino – mcvictorino@uol.com.br
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
Desenvolvimento IterativoGerenciamento de Requisitos
Uso da Arquitetura de ComponentesModelagem Visual (UML)
Contínua Verificação da QualidadeGerenciamento de Mudança
3
Desenvolvimento Iterativo
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
Desenvolvimento Iterativo
5
Desenvolvimento Iterativo
6
Desenvolvimento Iterativo
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
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
Desenvolvimento IterativoGerenciamento de Requisitos
Uso da Arquitetura de ComponentesModelagem Visual (UML)
Contínua Verificação da QualidadeGerenciamento de Mudança
8
Gerenciamento de Requisitos
"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
Gerenciamento de Requisitos
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
Gerenciamento de Requisitos
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
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
Desenvolvimento IterativoGerenciamento de Requisitos
Uso da Arquitetura de ComponentesModelagem Visual (UML)
Contínua Verificação da QualidadeGerenciamento de Mudança
Uso da Arquitetura de Componentes
12
Uso da Arquitetura de Componentes
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.
Uso da Arquitetura de Componentes
14
Modelagem Visual (UML)
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
Desenvolvimento IterativoGerenciamento de Requisitos
Uso da Arquitetura de ComponentesModelagem Visual (UML)
Contínua Verificação da QualidadeGerenciamento de Mudança
15
Modelagem Visual (UML)
A modelagem visual aumenta o nível de abstração16
Modelagem Visual (UML)
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
Modelagem Visual (UML)
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
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
Desenvolvimento IterativoGerenciamento de Requisitos
Uso da Arquitetura de ComponentesModelagem Visual (UML)
Contínua Verificação da QualidadeGerenciamento de Mudança
19
Verificação da Qualidade
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
Verificação da Qualidade
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
Verificação da Qualidade
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
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
Desenvolvimento IterativoGerenciamento de Requisitos
Uso da Arquitetura de ComponentesModelagem Visual (UML)
Contínua Verificação da QualidadeGerenciamento de Mudança
23
Gerenciamento de Mudanças
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
Gerenciamento de Mudanças
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
Rational Unified Process
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
Rational Unified Process
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
Rational Unified Process
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