Aulas-Modelos-de-Processo

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Modelos de Processo
Diana Braga
Bibliografia
Roger Pressman
Shari Lawrence
Sommerville
2
Modelo Cascata
3
3
Modelo Cascata
Por que o modelo de cascata freqüentemente falha?
Projetos reais raramente seguem o fluxo seqüencial e modificações podem causar confusão
É difícil para estabelecer todos os requisitos inicialmente
O cliente precisa ter paciência porque uma versão executável do programa só ficará disponível no final do processo
O modelo leva ainda a “estados de bloqueio”, nos quais membros da equipe ficam esperando outros membros terminar a sua parte
O modelo em cascata é adequado quando os requisitos são bem compreendidos e estáveis, como em aperfeiçoamentos de um sistema existente
4
4
Algumas Definições
O que são atividades guarda-chuva?
O que é marco?
5
5
Como funciona este modelo?
6
6
Modelo em Cascata com Prototipação
Protótipo
Produto parcialmente desenvolvido, que possibilita aos clientes e desenvolvedores examinarem certos aspectos do sistema proposto e decidir se eles são ou não apropriados ou adequados para o produto acabado
Ajuda os desenvolvedores a avaliar estratégias alternativas de projeto e decidir qual é a melhor opção 
7
7
Prototipação
Motivação
O cliente frequentemente define um conjunto de objetivos gerais para o software, mas não identifica detalhadamente requisitos de entrada, processamento ou saída
Em outros casos a equipe de desenvolvimento pode estar insegura em relação a eficiência do algoritmo ou da forma de interação com o sistema
A prototipagem pode oferecer a melhor abordagem 
8
8
Modelo em Cascata com Prototipação
9
Prototipação
Problemas em utilizar protótipos descartáveis
Pode haver pressão do cliente para transformar um protótipo malfeito em produto final, resultando em baixa qualidade
Concessões na implementação podem fazer com que o desenvolvedor fique familiarizado com escolhas não ideais
O cliente tem que concordar que o protótipo será usado apenas para levantamento de requisitos, sendo descartado, e o software real será submetido à engenharia com olho na qualidade
10
Prototipação
A Prototipação não precisa ser somente um adjunto do modelo em Cascata, ela mesma pode ser a base de um modelo de processo efetivo
Permite que todo o sistema ou parte dele seja construído rapidamente para que questões sejam entendidas ou esclarecidas
Objetivo geral: Reduzir a incerteza do desenvolvimento e os riscos associados
11
Prototipação
12
12
Modelo em V
Variação do modelo cascata, que demonstra como as atividades de teste estão relacionadas com a análise e o projeto (Ministério de Defesa da Alemanha, 1992)
Modelo em cascata: enfoque nos documentos e artefatos
Modelo em V: enfoque na atividade e correção
Modelo em V torna mais explícita algumas iterações e repetições
13
Modelo em V
14
14
Modelo em V
Richter destacou que para garantir o sucesso da adoção do modelo em ‘V’ de teste de software, é necessário que exista um patrocínio da alta gerência, ou seja, essa iniciativa deve vir de cima para baixo na organização 
15
15
Pergunta...
Você considera que uma organização deve adotar um único modelo de processo para o desenvolvimento de todo o software?
16
Desenvolvimento em Fases
No desenvolvimento em fases, o sistema é projetado de modo que possa ser entregue em partes, possibilitando aos usuários dispor de alguns recursos enquanto o restante do sistema está sendo desenvolvido 
Ênfase
Diminuir o tempo de desenvolvimento, pois o mercado exige agilidade (Time to Market)
Diminuir o tempo realizando o desenvolvimento em fases
17
Desenvolvimento em Fases
18
18
Modelo Incremental
Combina elementos do modelo em cascata aplicado de maneira iterativa
O fluxo do processo para qualquer incremento pode incorporar o paradigma da prototipagem
19
Modelo Incremental
Cada seqüência produz incrementos do software passíveis de serem entregues, que fornecem progressivamente mais funcionalidade
O primeiro incremento é chamado de núcleo do produto
Os requisitos básicos são satisfeitos
Um plano é desenvolvido para o próximo incremento como resultado do seu uso/avaliação
O modelo incremental é particularmente útil quando não há mão-de-obra/recursos disponíveis para uma implementação completa
20
Incrementos e Iterações
No desenvolvimento incremental, o sistema é dividido em subsistemas por funcionalidades
O desenvolvimento iterativo entrega um sistema completo desde o começo e então muda a funcionalidade de cada subsistema a cada nova versão
21
21
Incrementos e Iterações
22
Incremental x Iterativo
O que queremos dizer com o modelo de desenvolvimento Incremental e Iterativo?
23
23
Modelo RAD
(Rapid Application Development)
Modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento curto, com o uso de uma abordagem de construção baseada em componentes
É uma adaptação "de alta velocidade" do modelo em cascata
Fases
Comunicação
Planejamento
Modelagem
Construção
Implantação
24
Modelo RAD
(Rapid Application Development)
A comunicação trabalha para entender as necessidades do negócio
O planejamento é essencial, porque equipes trabalham em paralelo em diferentes funções do sistema
A modelagem estabelece representações de projeto que servem como base para a atividade de construção
A implantação estabelece a base para iterações subsequentes, se necessárias
25
Modelo RAD
(Rapid Application Development)
26
Modelo RAD
(Rapid Application Development)
2 características-chave
Ciclos com tempo limitado de cerca de 6 meses
Um grande projeto é quebrado em projetos menores
Oficinas JAD
Joint Application Development (Desenvolvimento Conjunto de Aplicativos)
Consiste de uma série de reuniões estruturadas entre projetistas e usuários, conduzidas por um “facilitador”, para planejar, projetar ou tomar decisões em conjunto
A técnica proporciona oportunidades para a análise do problema, cria possibilidades de identificação e conciliação de pontos de vista divergentes
Consenso
27
27
Modelo RAD
(Rapid Application Development)
Recomendável quando uma aplicação pode ser modularizada de maneira que a função principal possa ser implementada em menos de 3 meses (3 ~ 6 meses)
Quais são as desvantagens do modelo RAD?
Exige pessoal suficientes para criar um número de equipes RAD (em paralelo)
Desenvolvedores e clientes têm que estar comprometidos com as atividades rápidas
Exige que o sistema seja modularizável
Dificuldade de acompanhamento
Pode levar a práticas caóticas de desenvolvimento
Pode gerar falta de padronização na interface
Se for necessário um alto desempenho e esse desempenho tiver de ser conseguido ajustando as interfaces dos componentes do sistema, a abordagem RAD pode não funcionar
Não é adequado quando os riscos técnicos são altos
28
28
Estudo de Caso
Netpliance
Fornecimento de aparelhos para a Internet
Nome do aparelho: i-opener
Adotou uma abordagem centrada no usuário, com base em RAD
Desenvolvimento de sistemas em 7 meses
Forte abordagem iterativa: arquitetura foi revisada e iterada várias vezes
Sessões semanais de feedback
Componentes revisados
29
Estudo de Caso
Público-alvo
Pessoas que não utilizavam ou não gostavam de utilizar um PC
Sentiam-se desconfortáveis em relação aos computadores
Dessa forma, os designers tiveram que se preocupar em projetar algo bem distante do modelo “tradicional”
Funcionalidades
Enviar e receber e-mails
Acessar Web
30
Estudo de Caso
Desenvolvimento
A interface foi projetada a fim de satisfazer os requisitos dos usuários
Depois foram desenvolvidos o SW e HW adaptados a interface
Prototipação o mais cedo possível
Testes de usabilidade foram realizados durante toda a implementação
Os desenvolvedores e familiares foram estimulados a utilizar o aparelho para que pudessem apreciar a mesma experiência dos usuários
Processo chamado de “prove sua própria comida”
31
Estudo de Caso
Wikipedia: The i-Opener was a low-cost internet appliance produced by Netpliance between the years 1999 and 2002 
32
Qto a empresa vendeu? Faturou?
32
Pergunta...
Para alcançar o desenvolvimento rápido, o modelo RAD supõe a existência de uma determinada característica.
O que é e por que a suposição dessa característica não é sempre verdadeira? 
33
33
Modelo Espiral
Proposto por Boehm (1988)
Combina a natureza iterativa da prototipagem com os aspectos controlados do modelo em cascata
O software é produzido numa série de versões evolucionárias
Primeiras versões só no papel ou protótipo
O modelo pode ser aplicado ao longo de todo ciclo de vida de uma aplicação e não apenas até a entrega do software como os outros modelos
34
Modelo Espiral
Cada loop na espiral representa uma fase do processo de software e é dividido em quatro setores
Definição de objetivos: determinação dos objetivos, alternativas e restrições
Avaliação e redução de riscos: análise de alternativas e identificação/resolução dos riscos
Desenvolvimento e validação: escolha de um modelo de desenvolvimento para o sistema
Planejamento: traçado dos planos para a próxima fase do projeto
35
Modelo Espiral
Definição de Boehm
O modelo espiral de desenvolvimento é um gerador de modelo de processo guiado por risco usado para guiar a engenharia de sistemas intensivos em software com vários interessados concorrentes
Ele tem duas principais características distintas
A primeira é uma abordagem cíclica, para aumentar incrementalmente o grau de definição e implementação de um sistema enquanto diminui seu grau de risco
A outra é um conjunto de marcos de ancoragem, para garantir o comprometimento dos interessados com soluções exeqüíveis e mutuamente satisfatórias para o sistema
36
Modelo Espiral
37
Modelo Espiral
É uma abordagem realista do desenvolvimento de software
Problemas
Pode ser difícil convencer os clientes que a abordagem é controlável
A gerência pode exigir um orçamento fixo, o que não é compatível com o modelo espiral
Exige competência na avaliação de riscos
38
Modelo Espiral
Exige a consideração direta dos riscos técnicos em todos os estágios do projeto
Usa a prototipagem como um mecanismo de redução de risco, porém, mais importante, permite ao desenvolvedor aplicar a abordagem de prototipagem em qualquer estágio da evolução do produto
39
Modelo Espiral WinWIN
Boehm (1998)
Teoria W
Teoria de gerenciamento que estabelece que a condição necessária e suficiente para o sucesso de um projeto é que todos os interessados sejam ganhadores
Modelo espiral WinWin
Extensão do modelo espiral de desenvolvimento de software por adição das atividades da Teoria W ao início de cada ciclo
Incorpora a identificação de stakeholders-chave e suas respectivas condições para “win” (ganhar)
Incluído período de negociação entre stakeholders
40
40
Modelo Espiral WinWin
41
41
Modelo Espiral WinWin
A abordagem de Boehm é, portanto, um instrumento flexível que proporciona oportunidades para
Estabelecimento de pré-condições de ganho para todos
Análise de alternativas
Análise de riscos
Revisão de postura
Negociação e conciliação de interesses conflitantes
42
Pergunta...
É possível combinar modelos de processo? Se for, dê um exemplo.
43
43
Modelo de Desenvolvimento
Concorrente
Pode ser representado esquematicamente com uma série de atividades de arcabouço, ações e tarefas de engenharia de software e seus estados associados
O modelo define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades
Todas as atividades ocorrem em paralelo mas estão em diferentes estados
Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de como está o estado do projeto
44
44
Modelo de Desenvolvimento
Concorrente
45
DESENVOLVIMENTO
REVISÃO
PRONTO
ESTADOS
Modelo de Desenvolvimento
Concorrente
Exemplo: Começo de projeto
A atividade de comunicação completou sua primeira iteração e está no estado aguardando modificações
A atividade de modelagem passa do estado nenhum para o estado em desenvolvimento
Se o cliente requere mudança nos requisitos, a modelagem passa de em desenvolvimento para aguardando modificações e a comunicação passa de aguardando modificações para em revisão
46
Modelo de Desenvolvimento
Concorrente
47
Eventos
Atividade:
Planejamento
Estado:
Pronto
Atividade:
Engenharia
Estado:
Desenvolvimento
Atividade:
Avaliação Cliente
Estado:
Revisão
Gerente
Comentário Final sobre processos Evolutivos
O SW moderno é caracterizado por modificações contínuas, prazos muito curtos e por uma enfática necessidade de satisfação do cliente/usuário
Os modelos evolucionários de processo foram concebidos para resolver esses pontos e, no entanto, eles também têm pontos fracos
Pode trazer problemas para o planejamento do projeto por causa do número incerto de ciclos necessários para construir o produto
Os processos evolucionários de software não estabelecem a velocidade máxima da evolução
48
48
Comentário Final sobre processos Evolutivos
Pontos fracos (continuação)
Os processos de software devem ser focados na flexibilidade e extensibilidade, em vez de na alta qualidade
Devemos priorizar a velocidade de desenvolvimento sobre zero-defeitos
Mas estender o desenvolvimento a fim de conseguir alta qualidade pode resultar em entrega atrasada do produto, quando o nicho de oportunidade tiver desaparecido
A intenção dos modelos evolucionários é desenvolver SW de alta qualidade de maneira iterativa e incremental
O desafio para as equipes de SW e seus gerentes é estabelecer um equilíbrio adequado entre seus parâmetros críticos de projeto e de produto e a satisfação do cliente
49
49
Relembrando os Modelos Vistos...
Cascata
Cascata com Prototipação
Prototipação
Modelo em V
Incremental e Iterativo
Espiral
Espiral WinWin
Modelo de Desenvolvimento
Concorrente
50
Modelos Especializados
Os modelos especializados de processo têm muitas das características de um ou mais dos modelos convencionais apresentados
Exemplos
Desenvolvimento Baseado em Componentes
O Modelo de Métodos Formais
Desenvolvimento de Software Orientado a Aspectos
51
Desenvolvimento Baseado em Componentes
Visa fornecer um conjunto de procedimentos, ferramentas e notações que possibilitem que, ao longo do processo de software, ocorra tanto a produção de novos componentes quanto a reutilização de componentes existentes
Mas o que é um componente?
Unidade de software independente, que encapsula dentro de si seu projeto e implementação, e oferece interfaces bem definidas para o meio externo
Por meio destas interfaces, um componente pode se unir a outros componentes e dar origem aos sistemas baseados em componentes
O importante é O QUE o componente faz e não COMO ele faz 
52
52
Desenvolvimento Baseado em Componentes
Para que a reutilização de componentes seja possível é preciso que estes sejam adaptáveis
O projeto de um componente deve ser conduzido de tal forma que além de tornar a sua execução correta e eficiente, deve ser genérico para que se torne adaptável a vários propósitos e não somente ao propósito ao qual será primeiramente aplicado [D’SO 99]
53
Desenvolvimento Baseado em Componentes
Compõe aplicações a partir de componentes de software previamente preparados
Incorpora muitas das características do modelo espiral
Evolucionário por natureza , demanda uma abordagem iterativa para a criação de softwares
54
Desenvolvimento Baseado em Componentes
Segue os seguintes passos implantados com uma abordagem evolucionária
Pesquisa e avaliação de componentes disponíveis para o domínio em questão
Considerações sobre a integração de componentes
Projeto de arquitetura de software
Integração dos componentes à arquitetura
Testes para garantir a funcionalidade adequada
55
Desenvolvimento Baseado em Componentes
56
Análise
Aquisição de Componentes
Design Orientado a Componentes
Composição de Componentes
Testes de Integracão
Testes de Sistema
Desenvolvimento Baseado em Componentes
Vantagens de construir componentes
Reusabilidade: a reutilização da funcionalidade do componente por toda a aplicação 
Produtividade: com o estabelecimento de uma interface bem definida e a redução da complexidade através do encapsulamento, desenvolver aplicações torna-se mais rápido e simples 
Facilidade de Uso e Aprendizado: Através do modelo fornecedor/consumidor, desenvolvedores
podem rapidamente se tornar produtivos no DBC sem um extenso treinamento 
Mudanças executadas com facilidade e rapidez: O aumento da modularidade e a ausência de dependências permitem os desenvolvedores modificar, adicionar ou substituir componentes tão rapidamente quanto as necessidades de negócio mudam 
Melhor foco de negócios: níveis mais altos de abstração permitem desenvolvedores e gerentes de negócios trabalharem juntos para planejar, projetar e construir a aplicação em termos de negócio em alto nível 
57
??
Proteção dos investimentos: Com a criação de novos padrões de interoperacionalidade entre os componentes (JavaBeans, COM/DCOM e CORBA), desenvolvedores poderão ficar certos de que os componentes baseados nesses padrões além de funcionarem imediatamente também funcionarão no futuro 
57
Desenvolvimento Baseado em
Componentes
Leva ao reuso de software, que segundo estudos tem como conseqüências
Redução significativa do prazo de desenvolvimento
Redução significativa no custo do projeto
Aumento do índice de produtividade
Em que situações o desenvolvimento baseado em componentes não é adequado?
Aquelas em que não existam componentes padrão disponíveis ou em que não se queira pagar pelos componentes
58
Desenvolvimento Baseado em
Componentes
Considerações Finais
A reusabilidade de um componente, apesar de ser sua característica principal, visa sempre a qualidade do processo de software e do produto final
Este é o princípio do Desenvolvimento Baseado em Componentes: obter produtos mais confiáveis e garantidos através da reutilização de componentes já testados no mercado 
59
Modelo de Métodos Formais
Métodos formais permitem ao engenheiro de software especificar, desenvolver e verificar um sistema aplicando uma rigorosa notação matemática
Uma variante chamada sala limpa é aplicada por algumas organizações
Abordagem que enfatiza a necessidade de fazer a correção no software à medida que vai sendo desenvolvido
Remove defeitos antes que eles possam precipitar riscos sérios	
60
Vantagens dos Métodos Formais
Elimina muitos problemas encontrados nos outros modelos: ambigüidade, incompletude e inconsistência
Servem de base para a verificação de programas (análise matemática), oferecendo a promessa de um software livre de defeitos
Apropriado para softwares críticos (por exemplo, de aeronaves e dispositivos médicos)
61
Desvantagens dos Métodos
Formais
O desenvolvimento de modelos formais é atualmente muito lento e dispendioso
Exige treinamento extensivo para dar aos desenvolvedores o preparo necessário
É difícil usar os modelos como um mecanismo de comunicação com a maioria dos clientes
62
Desenvolvimento Orientado a
Aspectos
É um paradigma novo de engenharia de software que fornece mecanismos para definir, especificar, projetar e construir aspectos
Quando as preocupações entrecortam várias funções, características e informações do sistema, elas são freqüentemente referidas como preocupações transversais
Requisitos referentes a aspectos definem essas preocupações transversais, que tem impacto em toda a arquitetura do software
63
63
Desenvolvimento Orientado a
Aspectos
Grundy
O DSOA usa um conceito de fatias horizontais por meio de componentes de software decompostos verticalmente chamados de "aspectos", para caracterizar propriedades de componentes transversais funcionais e não funcionais
64
64
Exemplo
Classe Produto
65
Desenvolvimento Orientado a
Aspectos
66
Desenvolvimento Orientado a
Aspectos
Aspectos - preocupações do cliente que permeiam diversos níveis do sistema, incluindo
Propriedades de alto nível (ex: segurança, tolerância a falha)
Funções (ex: aplicação de regras de negócio)
Sistêmicas (ex: sincronização e gestão de memória)
Um processo orientado a aspectos pode adotar características do modelo espiral e do modelo concorrente
67
Desenvolvimento Orientado a
Aspectos
Código Emaranhado e Espalhado
Código Emaranhado 
Para aproveitar as Classes, desenvolvedores podem até fazer uma relação de herança que não é politicamente correta
Por exemplo, uma classe “X” herda de outra que não tem um relacionamento lógico, porém existe o reaproveitamento de código
Por estes e outros motivos os desenvolvedores podem “sujar” o código, fazendo com que o módulo em questão tenha vários interesses juntos, gerando um código emaranhado, o que é desorganizado e terrível para alguém que for dar suporte posteriormente
68
Desenvolvimento Orientado a
Aspectos
Código Espalhado
Cada barra é um módulo
Cada módulo tem seu interesse, mas em todos os módulos há um controle de auditoria (log), exemplo de um código espalhado - mesmo interesse sendo aplicado em vários pontos diferentes da aplicação
69
69
Desenvolvimento Orientado a
Aspectos
Uma implementação básica de AOP consiste em
Uma linguagem para programar os componentes (por exemplo, Java)
Uma linguagem para programar os aspectos (por exemplo, o AspectJ)
Um weaver para combinar as duas linguagens (ferramenta que também faz parte do AspectJ)
O weaver é uma espécie de montador que tem como entrada um programa de componente e o(s) programa(s) de aspectos e como saída um programa em uma linguagem específica (por exemplo, Java)
70
70
Desenvolvimento Orientado a
Aspectos
public class Principal
{
public static void main(String[] args)
{
Principal hello = new Principal();
hello.Mensagem( ) ;
System.exit(0);
}
public void Mensagem( )
{
System.out.println("Olá mundo !");
}
}
71
Desenvolvimento Orientado a
Aspectos
public aspect Aspectos
{
Pointcut point1( ): execution( * * ( ) ) ;
before(): point1()
{
System.out .p r intln("Join Point: "+ thisJoinPoint );
}
}
72
Desenvolvimento Orientado a
Aspectos
Resultado da execução:
Joinpoint: execution(void Principal.Mensagem())
Olá mundo !
73
Processo Unificado
É uma tentativa de unir os melhores recursos e características dos modelos convencionais
Reconhece a importância da comunicação com o cliente e dos casos de uso para descrever a visão do cliente
Utiliza a UML como a notação para modelagem e análise de projeto
Sugere um fluxo de processo que é iterativo e incremental
RUP (Rational Unified Process) – a Rational construiu ferramentas de apoio ao processo unificado
74
Processo Unificado
Histórico
Década de 1980: popularização dos métodos de programação orientada a objeto (OO) levando a métodos variados de análise e projeto OO
Início da década de 1990: Rumbaugh, Booch e Jacobson começaram a trabalhar em um “método unificado”, que resultou na UML
A UML tornou-se uma norma industrial
Final da década de 1990: Jacobson, Rumbaugh e Booch desenvolvem o Processo Unificado, um arcabouço para engenharia de software OO
Hoje em dia o PU e a UML são amplamente usados em projetos OO de todas as naturezas
75
Processo Unificado
Fases
76
Processo Unificado
Figura Pressman
Principais produtos de trabalho
77
78
Rational Unified Process
IBM
O RUP tem duas dimensões
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
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
79
Rational Unified Process
80
80
Rational Unified Process
Ciclo de Desenvolvimento Completo
81
81
Rational Unified Process
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
82
82
Rational Unified Process
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
83
Rational Unified Process
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
84
84
Exercício
Quantas e quais são as fases e disciplinas do RUP?
85
Exercício
Quantas e quais são as fases e disciplinas do RUP?
Disciplinas
86
Iniciação (ou concepção)
A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto
A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir
Para projetos que visam melhorias em um sistema existente, a fase de iniciação é mais rápida, mas ainda se concentra em assegurar que o projeto seja compensatório e que seja possível fazê-lo
87
87
Iniciação (ou concepção)
Objetivos
Estabelecer o escopo do software do projeto e as condições limite
Discriminar os casos de uso críticos do sistema, os principais cenários de operação
Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos
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
Preparar o ambiente de suporte para o projeto
88
88
Iniciação (ou concepção)
Atividades básicas
Formular o escopo do projeto
Planejar e preparar um caso de negócio
Avaliar alternativas para o gerenciamento de riscos, a organização da equipe, o plano do projeto e as mudanças de custo/programação/lucros
Sintetizar uma possível arquitetura, avaliando as mudanças no design e em fazer/comprar/reutilizar, para que seja possível estimar custo, programação e recursos
Preparar o ambiente para o projeto, avaliando o projeto e a organização, selecionando ferramentas e decidindo quais partes do processo devem ser melhoradas
89
89
Iniciação (ou concepção)
Marco: Objetivos do Ciclo de Vida
Neste momento, você analisa os objetivos do ciclo de vida do projeto e decide prosseguir com o projeto ou cancelá-lo
90
90
Iniciação
Artefatos
Visão  é definida a visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidades e características mais importantes
Caso de Negócio  fornece as informações necessárias do ponto de vista de um negócio, para determinar se vale ou não a pena investir no projeto (ROI)
Plano de Desenvolvimento de Software  reúne todas as informações necessárias ao gerenciamento do projeto
Modelo de Casos de Uso  consiste de um modelo das funções pretendidas do sistema e seu ambiente, e serve como um contrato estabelecido entre o cliente e os desenvolvedores
Glossário  define termos importantes usados pelo projeto
91
91
Elaboração
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
A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco
A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura
92
92
Elaboração
Objetivos
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
Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto
Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo
Estabelecer um ambiente de suporte
93
93
Elaboração
Atividades
Definir, validar e criar a baseline da arquitetura com rapidez e eficiência
Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento
Criar planos de iteração detalhados e baselines para a fase de construção
Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automatização necessários para dar assistência à equipe de construção
Refinar a arquitetura e selecionar componentes
94
94
Elaboração
Marco: Arquitetura do Ciclo de Vida
Neste momento, você examina os objetivos e o escopo detalhados do sistema, a opção de arquitetura e a resolução dos principais riscos
95
95
Elaboração
Artefatos
Protótipos  são usados de uma maneira direta para reduzir o risco
Lista de Riscos  classificada em ordem decrescente de importância e associada a ações específicas de contingência ou diminuição de riscos
Documento de Arquitetura de Software  fornece uma visão geral de arquitetura abrangente do sistema, usando diversas visões de arquitetura para descrever diferentes aspectos do sistema
Modelo de Projeto  é um modelo de objeto que descreve a realização dos casos de uso e serve como uma abstração do modelo de implementação e seu código-fonte
96
96
Construção
A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline
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
Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição
97
97
Construção
Objetivos
Minimizar os custos de desenvolvimento, otimizando recursos e evitando retrabalho
Atingir a qualidade adequada com rapidez e eficiência
Atingir as versões úteis (e.g., alfa, beta) com rapidez e eficiência
Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades necessárias
Decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja implantado
Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento
98
Construção
Atividades
Gerenciamento de recursos, otimização de controle e processo
Desenvolvimento completo do componente e teste dos critérios de avaliação definidos
Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão
99
Construção
Marco: Capacidade Operacional Inicial
Toda a funcionalidade já foi desenvolvida e todos os testes alfa (se houver algum) foram concluídos
Além do software, um manual do usuário foi desenvolvido, e existe uma descrição do release atual
100
100
Construção
Artefatos
O próprio sistema executável, pronto para começar o teste "beta”
Conjunto de Testes  testes implementados e executados para validar a estabilidade da versão de cada release executável criado durante a fase de construção
101
101
Transição
O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais
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; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto
102
102
Transição
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
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
Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado
103
103
Transição
Objetivos
Teste beta para validar o novo sistema em confronto com as expectativas do usuário
Treinamento de usuários e equipe de manutenção
Atividades de ajuste, como correção de erros, melhoria no desempenho e na usabilidade
104
104
Transição
Atividades
Executar planos de implantação
Finalizar o material de suporte para o usuário final
Testar o produto liberado no local do desenvolvimento
Criar um release do produto
Obter feedback do usuário
Ajustar o produto com base em feedback
Disponibilizar o produto para os usuários finais
105
105
Transição
Marco: Release do Produto
Neste momento, você decide se os objetivos foram atendidos, e se outro ciclo de desenvolvimento deve ser iniciado
106
106
Transição
Artefatos
Notas de Release  identificam mudanças e erros conhecidos em uma versão ou em uma unidade de implantação que tenha sido disponibilizada para uso
Artefatos de Instalação  se referem ao software e às instruções documentadas necessárias para instalar o produto
Materiais de Treinamento  referem-se ao material usado nos programas ou cursos de treinamento para ajudar os usuários finais com a utilização, a operação e/ou a manutenção dos produtos
107
107
Disciplinas do RUP
Uma disciplina mostra todas as atividades que você deve realizar para produzir um determinado conjunto de artefatos
Disciplinas RUP
Modelagem de Negócios
Requisitos
Análise e Design
Implementação
Teste
Implantação
Gerenciamento de Projeto
Gerenciamento de Configuração e Mudança
Ambiente
108
108
Algumas Definições
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
Os papéis têm um conjunto de atividades coerentes por eles executadas. 
As atividades estão fortemente relacionadas aos artefatos
Os artefatos fornecem a entrada e a saída para as atividades e o mecanismo pelo qual as informações são transmitidas entre as atividades
109
109
Modelagem de Negócios
Finalidade 
Entender a estrutura e a dinâmica da organização na qual um sistema deve ser implantado
Entender os problemas atuais da organização-alvo e identificar as possibilidades de melhoria
Assegurar que os clientes, usuários e desenvolvedores tenham um entendimento comum da organização-alvo
Derivar os requisitos de sistema necessários para sustentar a organização-alvo
Para atingir essas metas, a disciplina de modelagem de negócios descreve como desenvolver uma visão da nova organização-alvo e, com base nesta visão, definir os processos, os papéis e as responsabilidades dessa organização em um modelo de casos de uso de negócios e em um modelo de objetos de negócios
110
110
Modelagem de Negócios
Fluxo de Trabalho
111
111
Modelagem de Negócios
112
112
Modelagem de Negócios
Artefatos
113
Requisitos
Finalidade
Estabelecer e manter concordância com os clientes eoutros envolvidos sobre o que o sistema deve fazer
Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema
Definir as fronteiras do sistema (ou delimitar o sistema)
Fornecer uma base para planejar o conteúdo técnico das iterações
Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema
Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários
114
114
Modelagem de casos de uso
115
Análise e Projeto
Finalidade
Transformar os requisitos em um projeto do sistema a ser criado
Desenvolver uma arquitetura sofisticada para o sistema
Adaptar o projeto para que corresponda ao ambiente de implementação
116
116
Exemplo: visão lógica em camadas
117
Exemplo: diagrama de classes
118
Implementacão
Finalidade
Definir a organização do código em termos de subsistemas de implementação organizados em camadas
Implementar classes
Testar os componentes desenvolvidos como unidades
Integrar os resultados produzidos por implementadores individuais (ou equipes) ao sistema executável
119
119
Testes
Finalidade
Localizar e documentar defeitos na qualidade do software
Avisar de forma geral sobre a qualidade observada no software
Validar as suposições feitas nas especificações de design e requisito através de demonstração concreta
Validar as funções do software conforme projetadas
Verificar se os requisitos foram implementados de forma adequada
120
120
Implantação
Finalidade
Descrever as atividades que garantem que o produto de software será disponibilizado a seus usuários finais
A instalação personalizada
O produto em uma forma "compacta”
Acesso ao software por meio da Internet
121
121
Gerenciamento de Configuração e Mudança
Gerenciamento de Configuração e de Solicitações de Mudança controla mudanças feitas nos artefatos de um projeto e mantém a integridade deles 
O Gerenciamento de Configuração e de Solicitações de Mudança envolve
a identificação dos itens de configuração
a restrição de mudanças nesses itens
a auditoria das mudanças feitas nesses itens
a definição e o gerenciamento das configurações desses itens
122
122
Gerenciamento de Configuração e Mudança
Finalidade
Controlar os inúmeros artefatos produzidos pelas muitas pessoas que trabalham em um mesmo projeto
Evitar confusões dispendiosas e garantir que os artefatos resultantes não entrem em conflito devido a algum dos seguintes problemas
123
123
Gerenciamento de Projeto
Finalidade
Fornecer um framework para gerenciar projetos de software
Fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os projetos
Fornecer um framework de gerenciamento de risco
Entretanto, essa disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de projeto. Por exemplo, ela não cobre problemas como
Gerenciamento de pessoal: contratação, treinamento
Gerenciamento de orçamento: definição, alocação
Gerenciamento de contratos, com fornecedores e clientes
124
124
Ambiente
Finalidade
A disciplina de Ambiente concentra-se nas atividades necessárias à configuração do processo para um projeto
Oferece à organização o ambiente de desenvolvimento de software — processos e ferramentas — que dará suporte à equipe de desenvolvimento
125
126