UM ESTUDO DE CASO COM
UML E O PROCESSO UNIFICADO
VER INTRODUÇÃO AQUI
LEMBRAR A INTRODUÇÃO A PROCESSOS JÁ DADA AQUI
SEÇÕES A SEGUIR:
A UML FOI INVENTADA SEM ASSOCIAÇÃO A UM PROCESSO
PARTICULAR
PORÉM, SEUS INVENTORES TINHAM UM PROCESO EM MENTE
ESTE PROCESSO ERA CHAMADO O RATIONAL
OBJECTORY PROCESS E HOJE É CHAMADO O PROCESSO
UNIFICADO
OS "TRÊS AMIGOS" TINHAM EM MENTE UM
PROCESSO QUE FOSSE:
USE CASE DRIVEN
ARCHITECTURE-CENTRIC
ITERATIVO
INCREMENTAL
USE CASE DRIVEN
NA FASE DE ANÁLISE, OS USE CASES CAPTURAM A
FUNCIONALIDADE NECESSÁRIA E SÃO USADOS PARA
VALIDAR A FUNCIONALIDADE JUNTO AO USUÁRIO
NAS FASES DE PROJETO E IMPLEMENTAÇÃO, OS
USE CASES DEVEM SER "REALIZADOS" NA
CONSTRUÇÃO
NA FASE DE TESTES, OS USE CASES VERIFICAM O
SISTEMA
ELES SÃO A BASE PARA OS "TEST
CASES"
QUANDO UM PROCESSO É DOMINADO POR USE CASES,
É FREQUENTE USAR UMA ORGANIZAÇÃO DE TRABALHO
QUE TAMBÉM SIGA USE CASES
POR EXEMPLO, UMA PESSOA PODE SER
RESPONSÁVEL POR UM USE CASE, SEGUINDO-O
DA ESPECIFICAÇÃO ATÉ O TESTE FINAL
ARCHITECTURE-CENTRIC
É IMPORTANTE DEFINIR UMA ARQUITETURA CEDO E
REFINÁ-LA COM TEMPO
UMA ARQUITETURA É UM "MAPA" DO
SISTEMA QUE DEFINE AS DIFERENTES PARTES DO
SISTEMA, SEUS RELACIONAMENTOS, INTERAÇÕES E
MECANISMOS DE INTERCONEXÃO
A PARTE MAIS IMPORTANTE É A DIVISÃO DO
SISTEMA EM SUB-SISTEMAS (PACKAGES EM
UML) COM DEPENDÊNCIAS SIMPLES E INTERFACES
CLARAS
ITERATIVO
NÃO FAZ TUDO DE UMA VEZ
O DESENVOLVIMENTO É UMA SEQUÊNCIA DE
ETAPAS, CADA ETAPA ADICIONANDO DETALHES NOS
MODELOS, DIAGRAMAS, ETC.
CADA ITERAÇÃO PASSA POR TODAS AS FASES DO
PROCESSO (ANÁLISE, PROJETO, IMPLEMENTAÇÃO,
TESTES)
CADA ITERAÇÃO É AVALIADA (NO PAPEL OU COMO
PROTÓTIPO) E PROVÊ FEEDBACK CONTÍNUO SOBRE
COMO O PROCESSO ESTÁ INDO
COMO ESCOLHER O QUE VAI NUMA ITERAÇÃO?
PRIMEIRA ALTERNATIVA: MAXIMIZAR
"BANG FOR THE BUCK"
MAIS FUNCIONALIDADE NO
INÍCIO SIGNIFICA UM SISTEMA NAS
MÃOS DO USUÁRIO MAIS CEDO
SEGUNDA ALTERNATIVA: ATACAR PROBLEMAS
DA ALTO RISCO (RISK CONFRONTING)
SE FIZER ISSO NO INÍCIO, O
RISCO GLOBAL DO PROJETO SERÁ
MINIMIZADO
É MELHOR DESCOBRIR QUE ALGO
NÃO VAI DAR CEDO PARA
REDIRECIONAR O PROJETO, A
ARQUITETURA, ETC
RESUMINDO: ATAQUE OS GRANDES
PROBLEMAS CEDO: NÃO EMPURRE COM
A BARRIGA
INCREMENTAL
CADA ITERAÇÃO PRODUZ UMA VERSÃO MAIS
FUNCIONAL DO SISTEMA
CADA ITERAÇÃO É "LIBERADA"
(DELIVERED) E AVALIADA
A LIBERAÇÃO NÃO NECESSARIAMENTE É
PARA O CLIENTE
A AVALIAÇÃO DA ITERAÇÃO PODE RESPONDER
ÀS SEGUINTES PERGUNTAS:
FUNCIONALIDADE PREVISTA PARA A ETAPA
FOI INCLUÍDA?
FUNCIONALIDADE PREVISTA FUNCIONA BEM?
ATRIBUTOS NÃO FUNCIONAIS
(DESEMPENHO, CONFIABILIDADE,
AMIGABILIDADE, ...) FORAM SATISFEITOS?
TEMPO DE DESENVOLVIMENTO FOI DE
ACORDO COM CRONOGRAMA?
RECURSOS UTILIZADOS FORAM CONFORME
PREVISTO?
TEM ALGUM PROBLEMA NO PROCESSO
UTILIZADO? ALGO DEVE SER MUDADO?
A IDÉIA É DE VER PROBLEMAS E ATACÁ-LOS
ANTES DE SE TORNAREM GRAVES
ISSO É A CHAVE DO ACOMPANHAMENTO DE
PROJETOS!
ITERATIVO + INCREMENTAL É O CONTRÁRIO DO
MODELO "WATERFALL"
QUEREMOS DETALHAR AS ETAPAS E MODELOS NUM PROCESSO
TRADICIONAL
ETAPAS:
LEVANTAMENTO DE REQUISITOS
ANÁLISE
PROJETO
IMPLEMENTAÇÃO
TESTES
DEPLOYMENT
MODELOS USADOS:
FASE DE LEVANTAMENTO DE REQUISITOS
GERA UM ACORDO ENTRE O CLIENTE E
O FORNECEDOR DO SISTEMA
-
OS DIAGRAMAS UML USADOS AQUI
SÃO:
DIAGRAMAS DE USE CASES
DIAGRAMAS DE ATIVIDADE,
ESTADO, SEQUÊNCIA, MAS APENAS DIAGRAMAS
SIMPLES E APENAS QUANDO AJUDAM O CLIENTE
E O FORNECEDOR A SE ENTENDEREM
FASE DE ANÁLISE
-
ATIVIDADES TÍPICAS
SESSÕES DE BRAINSTORMING PARA ACHAR
CLASSES PARA MODELAR OS BUSINESS OBJECTS
BRAINSTORMING ANOTA TUDO
NO FIM, FAZER UMA ANÁLISE
DAS CLASSES DESCOBERTAS E
ELIMINAR, JUNTAR, ORGANIZAR, ETC.
A LISTA DE CLASSES VAI MUDAR
AO LONGO DO DESENVOLVIMENTO
DEVIDO AO MELHOR INSIGHT QUE SE
GANHA COM TEMPO
RELACIONAMENTOS ESTÁTICOS ENTRE
CLASSES SÃO MODELADOS USANDO
ASSOCIAÇÃO, AGREGAÇÃO,
GENERALIZAÇÃO, DEPENDÊNCIAS.
DIAGRAMAS DE CLASSES SÃO
USADOS PARA DOCUMENTAR AS
CLASSES, SUAS ESZPECIFICAÇÕES E
RELACIONAMENTOS
O COMPORTAMENTO E COLABORAÇÃO ENTRE
OBJETOS DAS CLASSES SÃO DESCRITOS USANDO
DIAGRAMAS DE ESTADO, DE COLABORAÇÃO, DE
SEQUÊNCIA, DE ATIVIDADE
TIPICAMENTE, OS USE CASES (OU
CENÁRIOS DOS USE CASES) SÃO
MODELADOS USANDO DIAGRAMAS DE
SEQUÊNCIA E/OU COLABORAÇÃO
QUANDO TODOS OS DIAGRAMAS ESTÃO
PRONTOS, OS CENÁRIOS SÃO
"SIMULADOS" E OS ESPECIALISTAS
DEVEM OPINAR SOBRE SE OS CENÁRIOS
MODELAM A SOLUÇÃO DO PROBLEMA DE FORMA
NATURAL
A INTERFACE BÁSICA COM O USUÁRIO
(SEM GRANDES DETALHES MAS MOSTRANDO A
NAVEGAÇÃO BÁSICA) PODE SER ELABORADA E
DISCUTIDA COM OS USUÁRIOS
RESULTADO: MODELO DE ANÁLISE
INCLUI DIAGRAMAS DE:
CLASSE
SEQUÊNCIA
COLABORAÇÃO
ESTADO
ATIVIDADE
O FOCO SEMPRE É NO DOMÍNIO DO PROBLEMA E
NÃO SOBRE UMA SOLUÇÃO TÉCNICA ESPECÍFICA
FASE DE PROJETO
VER RESUMO JÁ VISTO AQUI
O RESULTADO:
ESPECIFICAÇÃO DE TODAS AS CLASSES
(COM ATRIBUTOS, INTERFACES, OPERAÇÕES)
DE FORMA A POSSIBILITAR CODIFICAR EM
SEGUIDA
DURANTE ESTA FASE, LEMBRAR DOS SEGUINTES
PONTOS:
RASTREAMENTO: DOCUMENTAR
TODAS AS DECISÕES DE FORMA A RESGATAR
POR QUE ELAS FORAM TOMADAS
INTERFACES: CRIE INTERFACES
SIMPLES, COMPLETAS E CONSISTENTES DE
FORMA A FACILITAR SEU ENTENDIMENTO E USO
DESEMPENHO: NÃO SE PREOCUPE
DEMAIS COM O DESEMPENHO CEDO DEMAIS
É MAIS FÁCIL AUMENTAR O
DESEMPENHO DE UM SISTEMA QUE
FUNCIONA DO QUE MELHORAR UM
SISTEMA RÁPIDO MAS QUE NÃO
FUNCIONA
O DESEMPENHO DEPENDE DE
POUQUÍSSIMOS GARGALOS
SIMPLICIDADE: A PRIMEIRA
REGRA DO DESENVOLVIMENTO: KISS (KEEP IT
SIMPLE, STUPID)
DIAGRAMAS USADOS:
CLASSE
SEQUÊNCIA
COLABORAÇÃO
ESTADO
ATIVIDADE
COMPONENTE
DEPLOYMENT
FASE DE IMPLEMENTAÇÃO
VER RESUMO JÁ VISTO AQUI
NÃO AGARRE O TECLADO CEDO DEMAIS (VIU,
EDEYSON?)
ESTA FASE NÃO PRODUZ NOVOS DIAGRAMAS MAS
SEMPRE MODIFICA DOCUMENTOS DE OUTRAS FASES
FASE DE TESTE
O PROCESSO UNIFICADO USA FASES LIGEIRAMENTE
DIFERENTES DAS CITADAS ACIMA
O PROCESSO UNIFICADO PODE SUPORTAR VÁRIOS PROCESSOS
DIFERENTES (PODE SER CUSTOMIZADO)
O PROCESSO É:
USE CASE DRIVEN
INCREMENTAL E ITERATIVO
RISK-CONFRONTING
ARCHITECTURE CENTRIC
AS FASES
CADA ITERAÇÃO PASSA POR TODAS AS FASES
RELAÇÃO COM O PROCESSO TRADICIONAL
INCEPTION: CONSISTE DE LEVANTAMENTO DE
REQUISITOS, ANÁLISE E PROJETO ARQUITETURA, MAS
NUM NÍVEL MUITO ALTO PARA CRIAR UMA VISÃO DO
PRODUTO DE CRIAR O BUSINESS CASE
ELABORATION: CONSISTE DE ANÁLISE, PROJETO
ARQUITETURAL E DE BAIXO NÍVEL PARA CRIAR UMA
FUNDAÇÃO PARA A CONSTRUÇÃO
CONSTRUCTION: CONSISTE DE PROJETO
ARQUITETURAL, PROJETO DE BAIXO NÍVEL,
IMPLEMENTAÇÃO, INTEGRAÇÃO E TESTES
TRANSITION: ATIVIDADES DE MARKETING,
PACKAGING, INSTALAÇÃO, CONFIGURAÇÃO,
TREINAMENTO, SUPORTE, ETC.
A FIGURA SEGUINTE MOSTRA QUE AS FASES TRADICIONAIS
VIRARAM "WORKFLOWS" NO PROCESSO UNIFICADO E
ITERAÇÕES PODEM OCORRER EM QUALQUER FASE
AMBIENTE DE LINGUAGEM
EDITOR
COMPILADOR
DEPURADOR
CONTROLE DE CONFIGURAÇÃO E DE VERSÃO
PARA CONTROLAR VÁRIAS CONFIGURAÇÕES DO
SISTEMA
MANTER CONTROLE DO CÓDIGO FONTE FACE AO
DESENVOLVIMENTO CONCORRENTE
USA PROCEDIMENTOS DE
CHECK-IN/CHECK-OUT
FERRAMENTAS DE DOCUMENTAÇÃO
PARA PRODUZIR DOCUMENTAÇÃO TÉCNICA E
MANUAIS DO USUÁRIOS DA FORMA MAIS AUTOMÁTICA
POSSÍVEL
FERRAMENTAS DE GERÊNCIA DE PROJETO
PARA AJUDAR O GERENTE A PLANEJAR E ACOMPANHAR
O PROCESSO DE DESENVOLVIMENTO (INCLUINDO
CRONOGRAMAS, DEPENDÊNCIAS, ...)
caso1.htm programa próxima