O Processo UnificadoO Processo UnificadoO Processo UnificadoO Processo Unificado
Aula 02Aula 02
Princípios Básicos do PU
• Desenvolvimento iterativo• Baseado em casos de uso• Centrado na arquitetura
As Fases do PU• Cada um dos ciclos de desenvolvimento
do PU é dividido em quatro fases– Concepção– Elaboração– Construção– Transição
As Fases do PU
As disciplinas do PU• Avaliando-se as fases do PU, pode-se ter a
impressão de que cada ciclo de iteração comporta-se como o modelo em cascata.
• Mas isso não é verdade: paralelamente às fases do PU, atividades de trabalho, denominadas disciplinas do PU, são realizadas a qualquer momento durante o ciclo de desenvolvimento.
• As disciplinas entrecortam todas as fases do PU, podendo ter maior ênfase durante certas fases e menor ênfase em outras, mas podendo ocorrer em qualquer uma delas.
As disciplinas do PU
Os Artefatos do PU
• Cada uma das disciplinas do PU pode gerar um ou mais artefatosartefatos, que devem ser controlados e administrados corretamente durante o desenvolvimento do sistema.
• Artefatos são quaisquer dos documentos produzidos durante o desenvolvimento, tais como modelos, diagramas, documentos de especificação de requisitos, código fonte ou executável, planos de teste, etc.
• Muitos dos artefatos são opcionais, produzidos de acordo com as necessidades específicas de cada projeto.
Os Artefatos do PU
p – propor, iniciarr - refinar
RUP – Rational UnifiedProcess
• É uma instância específica e detalhada do Processo unificado. Produto da Rational que contém:– Um grande número de páginas HTML– Tutoriais da ferramenta
RationalSuite(conjunto de ferramentas construídas em torno do RUP)
– Templates para os artefatos principais– Manuais das tarefas e de personalização
dos templates do processo.
RUP – Rational UnifiedProcess
• Visa melhorar a produtividade da equipe.• Elaboração e manutenção de modelos.• Guia para utilizar efetivamente a UML.• Várias ferramentas disponíveis.• Processo configurável.• Incentiva as melhores práticas do
desenvolvimento de software moderno
Melhores Práticas
• 1. Desenvolver software iterativamente
• 2.Gerenciar requisitos• 3.Usar arquiteturas baseada em
componentes• 4.Modelar o software visualmente
(diagramas)• 5.Verificar a qualidade do
software.
RUP - Características
• Semelhante ao PU:– Baseado em casos de uso– Orientado a arquitetura– Iterativo e incremental
RUP - Fases
• Semelhante ao PU:– Concepção– Elaboração– Construção– transição
RUP - Disciplinas
• Gerencia de Projeto • Modelagem de Negócio • Requisitos• Análise e Projeto (união de A/P do PU)• Teste Configuração e gerência de
alterações• Ambiente• Instalação
XP – eXtrem Programming
• Introdução• Valores• Princípios• Práticas• Semelhança entre RUP e XP• Diferença entre RUP e XP
XP - Introdução• “Uma metodologia leve para equipes
pequenas e médias que desenvolvem software com requisitos vagos ou que mudam rapidamente” (KentBeck)
• É um processo ágil:– Incremental: versões pequenas de
software, com ciclos rápidos– Cooperativo: clientes e desenvolvedores
trabalham juntos– Direto: o método é fácil de aprender e
modificar– Adaptativo:capaz de realizar mudanças a
qualquer momento do desenvolvimento do software.
Valores• Comunicação• Simplicidade• Realimentação (feedback)• Coragem
Práticas1. Jogo de
planejamento2. Versões pequenas3. Metáfora4. Projeto simples5. Testes constantes6. Re-fabricação
constante7. Programação em
pares
8. Propriedade coletiva de código
9. Integração contínua10.Stand up meeting11.Cliente presente12.Padrões de
codificação
Semelhança entre RUP e XP
• Procuram facilitar a comunicação entre os vários interessados em um projeto
• RUP -> UML• XP -> modelagem informal• Integração contínua (escalas e ordens
diferentes): “analisar um pouco, projetar um pouco, codificar um pouco, testar um pouco ...”
• Objetivam a simplicidade
Diferença entre RUP e XP
• RUP: enfoque descendente de construção do software.
• XP: enfoque ascendente –“ descobrir o projeto em resposta à codificação e fatoração contínua”
• XP: foge da documentação formal, confia mais na documentação oral.
• XP: concebido para equipes pequenas e médias
• RUP: concebido para grandes projetos.
Obtendo um sistemaObtendo um sistemaObtendo um sistemaObtendo um sistema
Fase de concepção• Viabilidade do projeto
– Exploração dos requisitos
• Estimativa aproximada de custos• Decisão:
– construir ou comprar?– Projeto continua ou para aqui ?
Fase de concepção
• Finalidade– Coletar os requisitos essenciais
suficientes para formar uma opinião– Artefatos
• Escopo• Visão• Caso de negócios
Fase de concepção
• Investigar a estrutura inicial do sistema
• Identificar e categorizar os riscos principiais do projeto
• Mostrar ao usuário que sua empresa é capaz de desenvolver o sistema proposto
Na disciplina de APS II• Concepção será a definição do
sistema e dos requisitos mais importantes
• Maiores riscos serão atacados• Documentos de visão e requisitos
Requisitos• Descrição de necessidades ou desejos para um
produto• Por que levantar requisitos?
– Saber que sistema será construído
• Importância dos requisitos– Sucesso no levantamento de requisitos implica
tranqüilidade na fase de implementação (sem muitas surpresas)
• Desafio: encontrar o que é realmente necessário
• Mudança é algo que deve ser levado em consideração– Não se sabe o que quer– Comunicação é ruim– Muda-se de idéia
Requisitos
• Encontrá-los não é o único problema– Gerenciar os mesmos e seu impacto
sobre o que já foi produzido
• Custos de mudança– Cascata: alto– Iterativo: mudanças e realimentação
minimizam custos
Requisitos• Tipos
– Funcionais– Não Funcionais
• No PU, requisitos são o coração do projeto
Documento de visão• Descreve os objetivos e restrições
de alto nível, além de um resumo que o sistema irá realizar
• Define a “cara” do sistema• Detalha o contexto
– Problema a ser resolvido
Definir o documento de visão
• Analisar os usuários– Perfil
• Listar funcionalidades
Objetivo: auxilia no entendimento do problema e na escolha correta da solução
Formato do Doc. de Visão
• Contexto– Declaração do problema/solução
• Descrição dos possíveis usuários• Visão geral do produto
– Lista das funcionalidades oferecidas
Exemplo• Breve descrição do sistema
– O objetivo do projeto é de criar um sistema para um Terminal Ponto de Venda (TPDV) a ser usado no comércio varejista.
• Cliente– O cliente é PDVs Ltda., que vende
TPDVs a lojas varejistas.
Contexto: PDVO problema Como registrar comprar de
forma automática, atualizando estoque?
afeta Clientes de varejo
Impacto do problema Desistência de comprar por parte dos clientes
Para Clientes, atendentes e gerentes
O produto é Registrador de vendas e controle de pagamento
Que oferece Registro de itens, cálculo de sub-totais,...
Difere de Sistemas difíceis de usas
Descrição do usuário: PDV
• Usuários em Potencial– Clientes (consulta)– Caixas (vendas, pagamentos)– Gerentes (relatórios)
• Perfil dos usuários– Clientes: pouco domínio da informática, precisam
consultar preços em qualquer lugar, etc
• Ambiente do usuário– Clientes: computador, leitor de código de barras
Visão geral do produto: PDV
• Descrição– O PDV é uma aplicação computadorizada
usada para registrar vendas e controlar pagamentos de clientes de uma loja de varejo. Inclui software, hardware,..., conversa com aplicações de cálculo de imposto e controle de estoque...Usará tais tecnologias....
Visão Geral do Produto: PDV
• Lista de funcionalidades– Processar vendas– Incluir produtos– Registrar devoluções– Gerenciar usuários– Relatórios de vendas no trimestre
• Outros requisitos– Tolerância a falhas– Desempenho
Aula Prática IAula Prática IAula Prática IAula Prática I
Documento de visãoDocumento de visão
Objetivos• Discutir o tema e o escopo dos
projetos• Elaboração do documento de
visão, que será a base para o restante do projeto
Documento de visão• Baixar o template em word (doc) a
partir do site: isledna.cjb.net
• Salvar como NomeProjeto-visao.doc
• Discutir e completar as seções