Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil

Análise de Sistemas

Prof. Filipe Arantes Fernandesfilipe.arantes@ifsudestemg.edu.br

2

Vale a pena ver de novo

• Modelo de Processo:

• Modelo em cascata:• Definição:

• Principais atividades:

• Um breve exemplo na prática:

• Vantagens:

• Limitações:

3

Vale a pena ver de novo

• Modelo de Processo:• Modelos são abstrações que podem ser usadas para explicar diferentes

abordagens de desenvolvimento de software.

• Tipos: cascata, iterativo e incremental, ágil, dentre outros.

• Modelo em cascata:• Definição:

• Principais atividades:

• Um breve exemplo na prática:

• Vantagens:

• Limitações:

4

Vale a pena ver de novo

• Modelo de Processo:

• Modelo em cascata:• Definição: é um exemplo de um processo dirigido a planos, ou seja, primeiro

deve-se planejar e programas todas as atividades do processo antes de começar a trabalhar nelas.

• Principais atividades:

• Um breve exemplo na prática:

• Vantagens:

• Limitações:

5

Vale a pena ver de novo

• Modelo de Processo:

• Modelo em cascata:• Definição:• Principais atividades:

• Análise e definição de requisitos• Projeto de sistema e software• Implementação e teste unitário• Integração e teste de sistema• Operação e manutenção

• Um breve exemplo na prática:• Vantagens:• Limitações:

6

Vale a pena ver de novo

• Modelo de Processo:

• Modelo em cascata:• Definição:

• Principais atividades:

• Um breve exemplo na prática:• Contexto: José está encarregado de enfeitar sua enorme casa para o Natal. Devido ao

tamanho da casa, é necessário antecipar os preparativos. Considerando a sustentabilidade, José irá confeccionar grande parte dos enfeites reutilizando papéis.

• Objetivo: O principal objetivo é criar uma estrela de papel.

• Vantagens:

• Limitações:

7

Vale a pena ver de novo

• Modelo de Processo:

• Modelo em cascata:• Definição:

• Principais atividades:

• Um breve exemplo na prática:

• Vantagens: Em princípio, o modelo em cascata deve ser usado apenas quando os requisitos são bem compreendidos e pouco provavelmente venham a ser radicalmente alterados durante o desenvolvimento do sistema;

• Limitações:

8

Vale a pena ver de novo

• Modelo de Processo:

• Modelo em cascata:• Definição:

• Principais atividades:

• Um breve exemplo na prática:

• Vantagens:

• Limitações: Por causa dos custos de produção e aprovação de documentos, as iterações podem ser dispendiosas e envolver significativo retrabalho;

9

Outline

• Modelo Iterativo e Incremental

• Entrega Incremental

• Rational Unified Process (RUP)

10

Modelo Iterativo e Incremental

11

Modelo Iterativo e Incremental

• O desenvolvimento incremental é baseado na ideia de desenvolver uma implementação inicial, expô-la aos comentários dos usuários e continuar por meio da criação de várias versões até que um sistema adequado seja desenvolvido.

12SOMMERVILLE, 2011

Modelo Iterativo e Incremental

13SOMMERVILLE, 2011

Modelo Iterativo e Incremental

• Atividades de especificação, desenvolvimento e validação são intercaladas, e não separadas, com rápido feedback entre todas as atividades.

14SOMMERVILLE, 2011

Modelo Iterativo e Incremental

• Fundamenta as abordagens ágeis;

• Melhor abordagem em relação ao modelo em cascata para a maioria dos sistemas de negócios em e-commerce e sistemas pessoais;

• Reflete a maneira como problemas são resolvidos:• Raramente elabora-se uma completa solução do problema com antecedência;

• Geralmente, passo a passo são realizados em direção a uma solução, recuando quando é perceptível a ocorrência de algum erro.

• É mais barato e mais fácil fazer mudanças no software.

15SOMMERVILLE, 2011

Modelo Iterativo e Incremental

• Cada incremento ou versão do sistema incorpora alguma funcionalidade necessária para o cliente;

• Os incrementos iniciais incluem a funcionalidade mais importante ou mais urgente;

• O cliente pode avaliar o sistema em um estágio relativamente inicial para ver se ele oferece o que foi requisitado;• Caso negativo, só o incremento que estiver em desenvolvimento no momento

precisará ser alterado e, possivelmente, nova funcionalidade deverá ser definida para incrementos posteriores.

16SOMMERVILLE, 2011

Comparações com o cascata

1. O custo de acomodar as mudanças nos requisitos do cliente é reduzido.A quantidade de análise e documentação a ser refeita é muito menor do que o necessário no modelo cascata;

2. É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito.Os clientes podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado.Os clientes têm dificuldade em avaliar a evolução por meio de documentos de projeto de software.

3. É possível obter energia e implementação rápida de um software útil ao cliente, mesmo se toda a funcionalidade não for incluída.Os clientes podem usar e obter ganhos a partir do software inicial antes, do que é possível com um processo em cascata.

17SOMMERVILLE, 2011

Vantagens

• É a abordagem mais comum;

• Pode ser dirigida a planos, ágil ou a mescla destas abordagens;• Dirigida a planos: os incrementos do sistema são identificados previamente;

• Ágil: os incrementos inicias são identificados, mas o desenvolvimento de incrementos posteriores depende do progresso e das prioridades dos clientes.

18SOMMERVILLE, 2011

Limitações (gerenciamento)

1. O processo não é visível.Os gerentes precisam de entregas regulares para mensurar o progresso.Se os sistemas são produzidos com rapidez, não é economicamente viável produzir documentos que reflitam cada uma das versões do sistema.

2. A estrutura do sistema tende a se degradar com a adição dos novos incrementos.A menos que o dinheiro e tempo sejam dispendidos em refatoração para melhoria do software, as constantes mudanças tendem a corromper sua estrutura.Incorporar futuras mudanças do software torna-se cada vez mais difícil e oneroso.

19SOMMERVILLE, 2011

Algumas considerações

• Os problemas do desenvolvimento incremental são particularmente críticos para sistemas de vida-longa, grandes e complexos, nos quais várias equipes desenvolvem diferentes partes do sistema.

• Sistemas de grande porte necessitam de um framework ou arquitetura estável, e as reponsabilidades das diferentes equipes de trabalho do sistema precisam ser claramente definidas, respeitando essa arquitetura.

• Isso deve ser planejado com antecedência, e não desenvolvido de forma incremental.

20SOMMERVILLE, 2011

Algumas considerações

• Pode ser desenvolvido um sistema de forma incremental e expô-lo aos comentários dos clientes, sem entregá-lo e implementá-lo no ambiente do cliente;

• Entrega e implementação incremental significa que o software é usado em processos operacionais reais.

• Isso nem sempre é possível, pois experimentações com o novo software podem interromper os processos normais de negócios.

21SOMMERVILLE, 2011

Entrega Incremental

22

Entrega Incremental

23SOMMERVILLE, 2011

Entrega Incremental

24SOMMERVILLE, 2011

Entrega Incremental

25SOMMERVILLE, 2011

Entrega Incremental

26SOMMERVILLE, 2011

Entrega Incremental

27SOMMERVILLE, 2011

Entrega Incremental

28SOMMERVILLE, 2011

Entrega Incremental

29SOMMERVILLE, 2011

Entrega Incremental

30SOMMERVILLE, 2011

Entrega Incremental

31SOMMERVILLE, 2011

Entrega Incremental

32SOMMERVILLE, 2011

Entrega Incremental

33SOMMERVILLE, 2011

Entrega Incremental

34SOMMERVILLE, 2011

Entrega Incremental

35SOMMERVILLE, 2011

Entrega Incremental

36SOMMERVILLE, 2011

Entrega Incremental

37SOMMERVILLE, 2011

Vantagens versus Desvantagens

38

Vantagens da entrega incremental

1. Clientes podem usar incrementos iniciais como protótipos e ganhar experiência, a qual informa seus requisitos para incrementos posteriores do sistema.

2. Clientes não necessitam esperar até que todo o sistema seja entregue para obter ganhos a partir dele.O primeiro incremento satisfaz os requisitos mais críticos de maneira que eles possam usar o software imediatamente.

3. O processo mantém os benefícios do desenvolvimento incremental, o que deve facilitar a incorporação das mudanças no sistema.

39SOMMERVILLE, 2011

Desvantagens da entrega incremental

1. A maioria dos sistemas exige um conjunto de recursos básicos, usados por diferentes partes do sistema.Pode ser difícil identificar recursos comuns, necessários a todos os incrementos.

2. Quando o sistema irá substituir outro.Usuários querem toda a funcionalidade do sistema antigo, e muitas vezes, ficam relutantes em experimentar um novo sistema incompleto.Portanto, é difícil de obter feedbacks úteis dos clientes.

3. A essência do processo iterativo é a especificação ser desenvolvida em conjunto com o software.Isso, contudo, causa conflitos, pois o sistema é vendido com toda a especificação do sistema.Na abordagem incremental, não há especificação completo até que o último incremento seja especificado, o que requer uma nova forma de contrato.

40SOMMERVILLE, 2011

Rational Unified Process (RUP)

41

RUP

• Que significa Processo Unificado da Rational;

• Rational é uma empresa que lançou o Processo Unificado;

• Atualmente, Rational pertence à IBM.

42

RUP

• Proposto pelos três amigos:

43

Grady Booch James Rumbaugh Ivar Jacobson

WAZLAWICK, 2014

Princípios

• Dirigido por casos de uso:

• Centrado na arquitetura:

• Iterativo e Incremental:

• Orientado a riscos:

44WAZLAWICK, 2014

Princípios

• Dirigido por casos de uso: o desenvolvimento é planejado e organizado sobre uma lista de casos de uso.

• Centrado na arquitetura:

• Iterativo e Incremental:

• Orientado a riscos:

45WAZLAWICK, 2014

Princípios

• Dirigido por casos de uso:

• Centrado na arquitetura: o processo de desenvolvimento leva à construção de uma arquitetura de sistema que permite a implementação dos requisitos.Esta arquitetura é baseada na identificação de uma estrutura que é iterativamente construída a partir de um modelo conceitual.

• Iterativo e Incremental:

• Orientado a riscos:

46WAZLAWICK, 2014

Princípios

• Dirigido por casos de uso:

• Centrado na arquitetura:

• Iterativo e Incremental: o desenvolvimento é dividido em iterações ou ciclos de desenvolvimento.A cada iteração, novas características são adicionadas à arquitetura do sistema, ou corrigidas/refinadas, deixando-as mais completa e mais parecida com a forma final do sistema.

• Orientado a riscos:

47WAZLAWICK, 2014

Princípios

• Dirigido por casos de uso:

• Centrado na arquitetura:

• Iterativo e Incremental:

• Orientado a riscos: os elementos de maior risco para um projeto são tratados o mais cedo possível.Por exemplo, casos de uso críticos são identificados, detalhados e implementados antes dos demais.

48WAZLAWICK, 2014

Perspectivas

1. Perspectiva Dinâmica: mostra as fases do modelo ao longo do tempo;

2. Perspectiva Estática: mostra as atividades realizadas no processo.

3. Perspectiva Prática: sugere boas práticas a serem usadas durante o processo.

49SOMMERVILLE, 2011

Fases do RUP (ConECT)

1. Concepção

2. Elaboração

3. Construção

4. Transição

50SOMMERVILLE, 2011

1. Concepção

• O objetivo é estabelecer o business case para o sistema;

• Deve-se identificar todas as entidades externas (pessoas e sistemas) que vão interagir com o sistema e definir as interações.

• Portanto, deve-se usar essas informações para avaliar a contribuição do sistema para o negócio;

• Se a contribuição for pequena, então o projeto poderá ser cancelado depois dessa fase.

51SOMMERVILLE, 2011

2. Elaboração

• As metas são desenvolver uma compreensão do problema dominante;

• Estabelecer um framework da arquitetura para o sistema;

• Desenvolver o plano do projeto;

• Identificar os maiores riscos do projeto;

• No fim desta fase, deve ter um modelo de requisitos para o sistema, que pode ser um conjunto de casos de uso da UML, uma descrição da arquitetura ou um plano de desenvolvimento de software.

52SOMMERVILLE, 2011

3. Construção

• Envolve projeto, programação e testes do sistema;

• Durante a fase, as partes do sistema são desenvolvidas em paralelo e integradas;

• Ao final, deve-se ter um sistema de software já funcionando, bem como a documentação associada pronta para ser entregue aos usuários.

53SOMMERVILLE, 2011

4. Transição

• A última fase implica transferência do sistema para o usuário e seu funcionamento no ambiente real;

• Isso é ignorado na maioria dos modelos de processo, mas é, de fato, uma atividade cara e, às vezes, problemática;

• Na conclusão desta fase, deve-se ter um sistema de software documentada e funcionando corretamente em seu ambiente operacional.

54SOMMERVILLE, 2011

Leitura recomendada

• SOMMERVILLE, 2011• Desenvolvimento Incremental: páginas de 21 a 23;

• Rational Unified Processo: páginas 34 e 35;

• Desenvolvimento Ágil: páginas de 38 a 51;

• WALAZWICK, 2017• Processo Unificado: páginas de 4 a 7;

55

Referências

• SOMMERVILLE. Engenharia de Software, São Paulo: Addison-Wesley, 9 ed., 2011. ISBN-10: 8579361087 ISBN-13: 9788579361081.

• WAZLAWICK, R. S. Análise e Design Orientados a Objetos para Sistemas de Informação. 3 ed. Rio de Janeiro, Elsevier, 2014. ISBN: 9788535279849.

56