O Processo Unificado

1. O Processo Unificado Aula 02

2. Princípios Básicos do PU • Desenvolvimento iterativo • Baseado em casos de uso • Centrado na arquitetura

3. As Fases do PU • Cada um dos ciclos de desenvolvimento do PU é dividido em quatro fases • Concepção • Elaboração • Construção • Transição

4. As Fases do PU

5. 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.

6. As disciplinas do PU

7. Os Artefatos do PU • Cada uma das disciplinas do PU pode gerar um ou mais artefatos, 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.

8. Os Artefatos do PU p – propor, iniciar r - refinar

9. 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.

10. 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

11. 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.

12. RUP - Características • Semelhante ao PU: • Baseado em casos de uso • Orientado a arquitetura • Iterativo e incremental

13. RUP - Fases • Semelhante ao PU: • Concepção • Elaboração • Construção • transição

14. 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

15. XP – eXtrem Programming • Introdução • Valores • Princípios • Práticas • Semelhança entre RUP e XP • Diferença entre RUP e XP

16. 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.

17. Valores • Comunicação • Simplicidade • Realimentação (feedback) • Coragem

18. Jogo de planejamento Versões pequenas Metáfora Projeto simples Testes constantes Re-fabricação constante Programação em pares Propriedade coletiva de código Integração contínua Stand up meeting Cliente presente Padrões de codificação Práticas

19. 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

20. 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.

21. Obtendo um sistema

22. 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 ?

23. Fase de concepção • Finalidade • Coletar os requisitos essenciais suficientes para formar uma opinião • Artefatos • Escopo • Visão • Caso de negócios

24. 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

25. 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

26. 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

27. 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

28. Requisitos • Tipos • Funcionais • Não Funcionais • No PU, requisitos são o coração do projeto

29. 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

30. 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

31. 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

32. 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.

33. Contexto: PDV

34. 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

35. 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....

36. 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

37. Aula Prática I Documento de visão

38. 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

39. 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