Análise e Projeto Orientados a Objetos Professora: Elisa Yumi Nakagawa PAE: Cristiane Aparecida Lana 2 semestre de 2015

Transcrição

1 Professora: Elisa Yumi Nakagawa PAE: Cristiane Aparecida Lana 2 semestre de 2015

2 Agenda Modelos de Processos de Software Desenvolvimento Iterativo Incremental Processo Unificado PU Rational Unified Process RUP Processo Unificado Ágil Exemplo de Aplicação do RUP 2

3 Modelos de Processos Desenvolver software é geralmente uma tarefa complexa e sujeita a erros. Sucesso ou fracasso dependem de inúmeros fatores que ocorrem durante todo o processo Necessidade de estabelecer processos sistemáticos para desenvolvimento -> Modelos de Processo de Software. 3

4 Modelos de Processos Representação simplificada do processo de software 4

5 Modelos de Processos Exemplos de Modelos de Processo de Software: Modelo em Cascata Modelo de Prototipagem Modelo Evolucionário Desenvolvimento Baseado em Componentes Modelo de Métodos Formais Processo Unificado Extremme Programming 5

6 Professora: Elisa Yumi Nakagawa PAE: Cristiane Aparecida Lana

7 Desenvolvimento Iterativo Incremental Características: 1. O valor agregado ao Cliente está na entrega em cada incremento de modo que a funcionalidade do sistema estará disponível mais cedo 2. Incrementos iniciais funcionam como protótipos para ajudar a evocar requisitos para incrementos posteriores 3. Menores riscos de falha no projeto em geral 4. Os serviços do sistema de alta prioridade tendem a receber a maioria dos testes 7

8 Desenvolvimento Iterativo Incremental 8

9 Desenvolvimento Iterativo Incremental Porque foi criado: 1. Criado em resposta aos problemas, principalmente do modelo em cascata 2. O desenvolvimento do software é feito em ciclos ou fases. 3. Em cada ciclo é possível ser identificado análise, projeto desenvolvimento e teste. 4. Os requisitos são selecionados por prioridade e importância. 5. A cada iteração é considerado um subconjunto de requisitos. 9

10 Processo Iterativo Busca Melhorar ou refinar pouco-a-pouco o Sistema (iterações) Em cada iteração é feito o ciclo de vida completo do desenvolvimento. Finalidade não é alterada, mas a cada iteração funcionalidades são acrescentadas. 10

11 Processo Incremental Aumentar o sistema pouco-a-pouco. No Início do desenvolvimento uma modificação de documento pode ser considerado um incremento. Nem todo incremento vai gerar um novo executável. 11

13 Processo Unificado Descrição: É um modelo de processo de software baseado no modelo incremental visando a construção de software orientados a objetos Utiliza a UML (Unified Modeling Language) como Linguagem de modelagem, porém pode ser utilizado com outras modelagens. 13

14 Processo Unificado Descrição: É um processo de Software: Conjunto de atividades executadas para transformar um conjunto de requisitos em sistemas de software Foco em qualidade e gerência de projeto 14

15 Breve História: Processo Unificado 15

16 Processo Unificado Princípios oufundamentos: 1. Dirigido por caso de uso 2. Centrado na arquitetura 3. Iterativo e Incremental 4. Orientado a Objetos 5. Tratamento de Risco 16

17 Processo Unificado Caso de uso serve para que? 17

18 Processo Unificado Caso de uso serve para que? 1. Criação de arquitetura 2. Testes 3. Definição das iterações 4. Documentação do usuário 18

19 Processo Unificado Dirigidos por casos de uso: Os requisitos funcionais são registrados preferencialmente por meio deles Eles ajudam a planejar as iterações Eles podem conduzir o projeto O teste é baseado neles 19

20 Processo Unificado Engenharia de Software, Jair C Leite,

21 Processo Unificado Centrado na arquitetura de software? 1. Organização fundamental do sistema como um todo 2. Definição de Componentes 3. Relacionamento entre os componentes 4. Propriedade dos componentes 5. No PU se a arquitetura não for definida e justificada o processo não continua. 6. Fator de sucesso do projeto 21

22 Processo Unificado A arquitetura, juntamente com os casos de uso, deve orientar a exploração de todos os aspectos do sistema 22

23 Processo Unificado A arquitetura desoftware é importante porque? Ajuda a entender a visão global Ajuda a organizar o esforço de desenvolvimento Facilita as possibilidades de reuso Facilita a evolução do sistema Guia a seleção e exploração dos casos de uso. 23

24 Arquitetura de Software Processo Unificado 24

26 RUP 1. Clone do UP 2.Definido pela Rational/IBM, por isso o nome Rational UP 3. Um framework que permite customização de acordo com as necessidades da organização 4. Tem vários Clones: Praxis, Datasus, Praticup 5. São Práticas que favorecem ascensão ao Nível 2 do CMM 6. Visite o site 26

27 RUP Não é suficiente apenas a presença de desenvolvedores altamente treinados: 1. Precisamos de uma linguagem para a equipe poder se comunicar, entre si e com os clientes (UML) 2. Necessitamos de um guia organizacional: Um processo (RUP). 27

28 RUP Utilidade: Servir de Guia Especificar quais artefatos devem ser desenvolvidos Especificar quando os artefatos devem ser desenvolvidos Dirigir as tarefas individuais e da equipe como um todo Oferecer critérios para monitorar e medir os produtos e atividades do projeto. 28

29 Principais Conceitos do RUP 1. Ciclos 2.Fases 1. cada ciclo do desenvolvimento resulta numa nova geração do produto 1. cada ciclo divide-se em fases 2. cada fase divide-se em iterações a definir em cada projeto concreto 29

30 Principais Conceitos do RUP 3. Trabalhadores (workers) 1. são perfis a que correspondem competências para a realização de atividades 4. Atividades 1. são tarefas que podem ser entregues a trabalhadores individuais 30

31 Principais Conceitos do RUP 5. Artefatos 1. são inputs e outputs de atividades 6. Modelos 1. agrupam artefatos desenvolvidos num workflow 31

32 Principais Conceitos do RUP 7. Disciplinas (Workflows) 1. agrupam atividades relacionadas 2. genéricos ou especializados por fases 32

33 Principais Conceitos do RUP 33

34 RUP Descrito, normalmente, em 3 perspectivas: 1. Estática: Mostra as atividades realizadas no processo - Vertical Workers, papéis Who, atividades How, artefatos What, disciplinas When. 2. Dinâmica: Mostra as fases do modelo ao longo do tempo - Horizontal Analisa o esforço dedicado a cada disciplina em relação às fases 3. Prática: Sugere boas práticas a serem usadas durante o processo 34

35 RUP Esforço e Tempo - Estático O esforço e o tempo em cada fase do projeto pode variar mediante ao contexto, nível de entendimento do problema, grau de experiência da equipe, existe uma média para projetos médios: 1. O esforço de cada fase do planejamento pode ser medido por horas de trabalho 2. O cronograma (tempo) pelo total de dias para cada fase 35

36 Elementos do RUP - Estático Estrutura do processo: Intervenientes (Workers) - Quem? (who) Atividades (Activities) - Como? (how) Artefatos (Artifacts) - O Que? (what) Fluxo de Trabalho (Workflows) - Quando? (when) 36

37 Elementos do RUP - Estático 37

38 Elementos do RUP - Estático 38

39 Fases e Iterações - Dinâmico 39

40 Boas Práticas do RUP - Práticas Principais Problemas: 1. Pouco entendimento das necessidades do usuário final 2. Não saber lidar com requisitos mutáveis ou mutantes 3. Módulos que não se falam 4. Software difícil de manter ou adaptar 5. Descoberta tardia de erros sérios nos projetos 6. Qualidade fraca 40

41 Boas Práticas do RUP - Práticas Principais Problemas: 7. Desempenho inaceitável 8. Equipe desencontrada, impossível descobrir quem fez o que, 9. onde, quando e porque 10. Um processo não confiável de construção-e-liberação 41

42 Boas Práticas do RUP - Práticas 42

43 Boas Práticas do RUP - Práticas Principais Causas: 1. Gestão ad-hoc de requisitos 2. Comunicação ambígua e sem precisão 3. Arquitetura mal estruturada 4. Muita complexidade 5. Inconsistências não detectadas em requisitos, projetos e implementações 6. Insuficiência do teste 43

44 Boas Práticas do RUP - Práticas Principais Causas: 7. Avaliação subjetiva do status do projeto 8. Risco não é levado em consideração 9. Propagação de alterações não controlada 10. Nível de automação insuficiente 44

45 Boas Práticas do RUP - Práticas São seis: 1. Desenvolvimento de software interativo 2. Gerenciamento de Requisitos 3. Arquitetura baseada em Componentes 4. Modelo de Software Visual (UML) 5. Verificação contínua da qualidade do Software 6. Gerenciamento e controle de mudanças 45

46 RUP Fases Concepção Estabelece-se a viabilidade de implantação do sistema. Definição do escopo do sistema Estimativas de custos e cronograma Identificação dos potenciais riscos que devem ser gerenciados ao longo do projeto Esboço da arquitetura do sistema, que servirá como alicerce para a sua construção. 46

47 RUP Fases Elaboração Visão refinada do sistema, com a definição dos requisitos funcionais, detalhamento da arquitetura criada na fase anterior e gerenciamento contínuo dos riscos envolvidos. Estimativas realistas feitas nesta fase permitem preparar um plano para orientar a construção do sistema. 47

48 RUP Fases Construção O sistema é efetivamente desenvolvido e, em geral, tem condições de ser operado, mesmo que em ambiente de teste, pelos clientes. 48

49 RUP Fases Construção 49

50 RUP Fases Transição O sistema é entregue ao cliente para uso em produção. Testes são realizados e um ou mais incrementos do sistema são implantados. Defeitos são corrigidos, se necessário. 50

51 RUP Disciplinas Se analisarmos as fases do RUP Impressão de que cada ciclo de iteração Comporta-se como o modelo em Cascata. 51

52 RUP Disciplinas Mas isso não é verdade: Paralelamente às fases do RUP, atividades de trabalho, denominadas disciplinas do RUP, são realizadas a qualquer momento durante o ciclo de desenvolvimento 52

53 RUP Disciplinas As disciplinas entrecortam todas as fases do RUP, podendo ter maior ênfase durante certas fases e menor ênfase em outras, mas podendo ocorrer em qualquer uma delas 53

54 Gráfico de Baleias 54

55 Reflete uma ite fase de Elabo Gráfico de Baleias 55

56 Gráfico de Baleias Foco do Larman,

57 Ênfase de Cada Fase 57

58 RUP Padrão Ciclo de Vida Incremental Para projetos que envolvem problemas familiares à equipe, com riscos bem entendidos e esquipes de trabalho experientes, podese usar um padrão de ciclo incremental, onde são realizadas: - Uma iteração curta de concepção - Uma iteração de elaboração - Várias iterações de construção - Algumas iterações de transição 58

59 RUP Padrão Ciclo de Vida Evolutivo Para projetos de alto risco, com requisitos não familiares à equipe e com equipes de trabalho inexperientes, pode-se usar um padrão de ciclo evolutivo, onde são realizadas: - Uma iteração curta de concepção - Várias iterações de elaboração - Uma iteração de construção - Algumas iterações de transição Padrões de ciclo podem variar entre ciclos de um mesmo projeto (Estratégia Híbrida). 59

60 Fases e Marco (fronteiras) 60

61 Fases, Marcos, Objetivos e Artefatos 61

63 PUA O que é: Simplificação do processo RUP. Descreve uma abordagem de desenvolvimento simples e fácil de entender usando técnicas e conceitos ágeis, mas permanece fiel ao RUP. 63

64 Princípios do PUA 1. Sua equipe sabe o que está fazendo 2. Simplicidade 3. Agilidade (conformidade com os valores e princípios ágil) 4. Foca nas atividades de alto valor 5. Independência de ferramenta 6. Customizável 64

65 Ciclo de Vida PUA 65

66 PUA Concepções e Elaboração O objetivo é identificar o escopo inicial do projeto, uma arquitetura potencial para seu sistema, e obter financiamento inicial do projeto e aceitação das partes interessadas. O objetivo é demonstrar a arquitetura do sistema. 66

67 PUA Construção e Transição O objetivo é construir software de forma incremental, que atenda as necessidades de maior prioridade dos stakeholders do projeto. O objetivo é validar e implantar o sistema em seu ambiente de produção. 67

69 PDS DATASUS Objetivo: Reduzir o backlog (lista de funcionalidade) do PDS com a implementação de melhorias e correções de baixo impacto registradas desde a publicação da versão 2.1. (2008) 69

70 Principais Mudanças: PDS DATASUS Inserção de Documentos de Perfis de Segurança, separados da Matriz de Requisitos Detalhamento de onde e como descrever as Regras de Negócios Disponibilização de artefatos em formatos do BrOffice.org Alteração da imagem dos processos relacionados 70

71 Fluxo de Atividades 71

72 Fluxo de Atividades - Concepção 72

73 Fluxo de Atividades - Elaboração 73

74 Fluxo de Atividades - Construção 74

75 Fluxo de Atividades - Transição 75

76 Referências LARMAN, CRAIG Utilizando UML e Padrões, 2ed, Bookman, WASLAWICK, RAUL Análise e Projeto de sistemas de Informação Orientados a Objetos, Campus, Kendall Scott O Processo Unificado Explicado, Bookman, Ernani Medeiros Desenvolvendo Software com UML 2, Makron Books, SOMMERVILLE, Ian. Engenharia de software. 9ed. São Paulo: Addison Wesley,

77 Professora: Elisa Yumi Nakagawa PAE: Cristiane Aparecida Lana 2 semestre de 2015