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

Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil Análise de Sistemas Prof. Filipe Arantes Fernandes filipe.arantes@ifsudestemg.edu.br

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

Modelo Iterativo e Incremental 13

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

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

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

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

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

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

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

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

Entrega Incremental 22

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

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

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: Grady Booch James Rumbaugh Ivar Jacobson WAZLAWICK, 2014 43

Princípios Dirigido por casos de uso: Centrado na arquitetura: Iterativo e Incremental: Orientado a riscos: WAZLAWICK, 2014 44

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: WAZLAWICK, 2014 45

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: WAZLAWICK, 2014 46

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: WAZLAWICK, 2014 47

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. WAZLAWICK, 2014 48

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

Fases do RUP (ConECT) 1. Concepção 2. Elaboração 3. Construção 4. Transição 50

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

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

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

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

Leitura recomendada 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