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