MODELOS DE PROCESSO DE SOFTWARE

Apresentação em tema: "MODELOS DE PROCESSO DE SOFTWARE"— Transcrição da apresentação:

1 MODELOS DE PROCESSO DE SOFTWARE
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA GOIANO CAMPUS IPORÁ MODELOS DE PROCESSO DE SOFTWARE Tecnologia em Análise e Desenvolvimento de Sistemas Luciana Recart Cardoso –

2 O que é um processo? Um processo pode ser entendido como um conjunto de atividades Interdependentes Com responsáveis Com entradas e saídas definidas

3 O que é um processo? “Possui uma sequência de etapas a fim de completar um conjunto de tarefas” As tarefas são executadas na mesma ordem todas as vezes Um pedreiro não reboca uma parede antes de passar a tubulação Um padeiro não leva um bolo para assar antes de misturar os ingredientes Um processo é uma série de etapas que envolvem atividades, restrições e recursos para alcançar a saída desejada “Um processo define quem está fazendo o quê, quando e como para alcançar um certo objetivo” (Ivar Jacobson, Grad Booch e James Rumbaugh)

4 Elementos de um processo
Tem uma documentação que detalha os elementos (unidade fundamental de um processo) O que será feito (produto) Quando (etapas) Por quem (papéis) As coisas que usa (insumos) Documentos que gera (artefatos) As coisas que produz (resultados)

5 Produto Um objeto produzido, quantificável, e que pode ser um item final ou um item componente Resultado que se pretende entregar a um cliente ou usuário

6 Etapas ou Atividades Termo genérico para uma divisão temporal de um processo

7 Papéis (responsáveis e participantes)
Conjunto correspondente de habilidades, competências e responsabilidades, desempenhado por uma ou mais pessoas Refletem as responsabilidades das pessoas envolvidas no processo Exemplos: gerente de projeto, programador, testador

8 Insumos Coisas consumidas em um processo

9 Artefato Qualquer documento que puder ser produzido durante um projeto de desenvolvimento de software (diagramas, programas, documentos, desenhos, contratos, etc.)

10 Resultados Uma saída dos processos e atividades de um projeto

11 Características de processo
Prescreve todas as suas principais atividades Utiliza recursos, está sujeito a um conjunto de restrições (como cronograma) e gera produtos intermediários e finais Composto por subprocessos que estão de algum modo relacionados Cada atividade tem critérios de entrada e saída As atividades são organizadas em uma sequência Apresenta um conjunto de diretrizes que explicam os objetivos de cada atividade Possui restrições e controles que podem ser aplicados a uma atividade, recurso ou produto

12 Modelos de processo Modelos genéricos que especificam a forma geral de processos, também chamado de modelo de ciclo de vida, permite a definição de projetos específicos a partir da estrutura base

13 Atividades fundamentais dos modelos de processos de software
Existem modelos de processos de software diferentes, mas todos devem incluir as atividades fundamentais Especificação de software Definição da funcionalidade e restrições do software Projeto e implementação de software Construção do software para atender às especificações Validação de software Verificação para garantir que atenda às demandas do cliente Evolução de software Evolução para atender às necessidades de mudança dos clientes

14 O que é um processo de software?
Um conjunto de atividades cujo objetivo é o desenvolvimento ou evolução do software. Especificação Implementação Validação Evolução

15 Modelos de processos Quando se escolhe um modelo de processo DEFINE­- SE um: Modelo de Ciclo de Vida (ou modelo de processo). É uma representação abstrata da estrutura (“ESQUELETO“) de processo. Inclui algumas atividades principais. A ordem de precedência entre elas. Opcionalmente, artefatos requeridos e produzidos. Podem ser decompostas em subatividades!

16 Três abordagens principais
Modelos de processo Três abordagens principais

17 Modelo cascata Também conhecido como ciclo de vida clássico, tem como principal característica a sequencia de atividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para uma nova fase. Análise Projeto Implementação Testes Requisitos

18 Modelo Cascata Atividades sequenciais
Uma fase deve ser terminada para a outra começar Raramente ocorre na prática

19 Etapas do modelo Cascata
Requisitos: Envolve a elicitação de requisitos do sistema, com uma análise de alto nível e modelo conceitual Análise: Os requisitos (para o sistema e para o software) são documentados e revistos com o cliente Desenho: Tradução dos requisitos para um conjunto de representações que podem ser avaliadas, antes da codificação Implementação: Codificação em linguagem “artificial” resultando em instruções executáveis pelo computador Testes: Concentra-se nos aspectos lógicos internos do software e nos aspectos funcionais externos de modo a descobrir erros e garantir que a entrada definida produza os resultados esperados

20 Modelo cascata A ideia principal é que as diferentes etapas de desenvolvimento seguem uma sequência. As atividades são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. É normal que as novas ideias sobre o sistema não sejam aproveitadas.

21 Contribuições do modelo Cascata
Imposição de disciplina, planejamento e gerenciamento A implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos Permite gerenciar o roteiro que identifica um conjunto fixo de documentos produzidos ao longo do processo de desenvolvimento

22 Problemas do modelo Cascata
Projetos reais raramente seguem o fluxo sequencial da forma que o modelo propõe Exige requisitos “congelados” É um processo rígido e burocrático, em que as atividades de análise e desenho tem que ser muito bem especificadas, pois não prevê correções em fases posteriores Logo no início é difícil estabelecer explicitamente todos os requisitos, pois sempre existe uma incerteza natural Baixa visibilidade para o cliente já que uma versão executável do software só fica disponível no final do projeto

23 Modelo cascata revisto
Trata-se de uma expansão do modelo em cascata Na prática, é comum ter que voltar para etapas anteriores Por causa de revisões, alterações, descoberta de erros Execução é sequencial, mas é possível voltar para etapas anteriores a fim revisar ou alterar Apresenta pontos de controle bem definidos Fácil gerenciamento

24 Modelo cascata revisto
A principal diferença consiste na possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que tenham surgido. Análise Projeto Implementação Testes Requisitos

25 Quando aplicar o modelo cascata?
Sistemas críticos Quando os requisitos são bem compreendidos Quando há pouca probabilidade dos requisitos mudarem

26 Modelo de Prototipagem
A Prototipagem é um processo no qual o desenvolvedor tem a capacidade de criar um modelo do software que será implementado. O modelo pode assumir uma das três formas: 1. Um modelo em papel para que o usuário tenha a visão da interação homem-máquina e quantas interações ocorrerá. 2. Um protótipo de trabalho que implementa algumas funcionalidades exigidas pelo software. 3. Um programa existente que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas posteriormente.

27 Sequência de eventos da prototipação
Coleta de requisitos Refinamento protótipo Projeto Avaliação do protótipo Construção do protótipo

28 Problemas da Prototipação
Cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo Equipe de desenvolvimento frequentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo O cliente muitas vezes quer ficar utilizando o protótipo O protótipo apresenta melhor performance do que o sistema em ambiente real

29 Vantagens da Prototipação
Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente. A chave é definir as regras do jogo logo no começo. O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo para definir os requisitos

30 Modelo incremental Foi desenvolvido através da combinação entre os modelos linear e prototipação. O desenvolvimento é dividido em etapas, “incrementos”, que produzirão acréscimos ao sistema, até a sua versão final. A cada incremento é realizado todo o ciclo do desenvolvimento de software. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos. Vantajoso especialmente se os requisitos não estão claros inicialmente.

31 Modelo incremental 3º Incremento 2º Incremento 1º Incremento
Análise Projeto Implementação Testes Requisitos 3º Incremento 1º Incremento 2º Incremento

32 Modelo incremental O sistema como está documentado na especificação de requisitos é dividido em subsistemas por funcionalidades O primeiro incremento geralmente é chamado de núcleo do produto (compreende os requisitos básicos 1º Incremento 2º Incremento 3º Incremento

33 Vantagens do Desenvolvimento Incremental
Permite trabalhar com o cliente o entendimento dos requisitos Pode-se começar o sistema pelas partes melhor entendidas Feedback rápido ao cliente

34 Desvantagens do Desenvolvimento Incremental
O processo pode não ser muito claro A gerência do software é complicada O sistema não é completamente especificado à priori O produto final é frequentemente mal estruturado A mudança contínua tende a corromper a modularidade do sistema Os problemas do desenvolvimento incremental se tornam mais graves em sistemas críticos.

35 Modelo Iterativo Com base nas limitações do modelo em cascata, combinando suas vantagens com as do modelo Prototipação. Desenvolvido de forma incremental, a cada incremento são adicionadas novas capacidades funcionais, até o sistema final. Uma implementação inicial do sistema é obtida da solução do problema global deve contemplar os principais aspectos a serem resolvidos. A lista de controle contem todos os passos a serem realizados para a obtenção do sistema final definindo quais tarefas devem ser realizadas .

36 Modelo Iterativo É gerenciado para se medir em o quão distante se está da última iteração. Cada iteração do modelo consiste em retirar um passo da lista de controle de projeto através da realização de três etapas (projeto, implementação e análise) até que a lista esteja vazia.

37 Diferença entre o modelo iterativo e o modelo Incremental
Facilmente confundidos, mas profundamente diferentes. Incremental, desenvolve-se uma primeira versão, sem se preocupar muito com o todo. Se inicia sem que haja um conhecimento amplo dos requisitos do sistema. Através do feedback do usuário, os requisitos vão sendo elicitados e implementados nas versões seguintes do sistema. Iterativo, tem-se uma visão inicial de todos (ou quase todos) os requisitos, mas não se implementam todos de uma vez: a cada iteração é implementado um subconjunto de requisitos. Estes requisitos são então apresentados ao usuário. O levantamento inicial registra 80% dos requisitos do sistema. Os outros surgem durante o desenvolvimento.

38 Comparativo entre os modelos incremental e iterativo

39 Modelo Espiral Combina a natureza iterativa (em fases) da prototipagem com aspectos controlados e sistemáticos do modelo em cascata A ideia é o desenvolvimento rápido de versões de software cada vez mais completas Abordagem cíclica: para aumentar incrementalmente o grau de definição e implementação de um sistema enquanto diminui seu grau de risco Marcos de ancoragem: para garantir o comprometimento dos interessados com soluções satisfatórias para o sistema

40 Modelo Espiral

41 Modelo Espiral Cada volta da espiral é dividida em 4 setores:
Definição de objetivos; Avaliação e redução de riscos; Desenvolvimento e validação; Planejamento.

42 Modelo Espiral Definição de objetivos
São definidos os objetivos específicos para essa fase do projeto; Restrições ao processo e ao produto são identificadas e é elaborado um plano de gerenciamento detalhado; São identificados os riscos do projeto e, dependendo dos riscos poderão ser planejadas estratégias alternativas

43 Modelo Espiral

44 Modelo Espiral 2. Avaliação e redução de riscos
Para cada um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas providências para reduzir esses riscos; Por exemplo, se houver um risco de os requisitos serem inadequados, poderá ser desenvolvido um protótipo

45 Modelo Espiral

46 Modelo Espiral 3. Desenvolvimento e validação
Depois da avaliação dos riscos, é escolhido um modelo de desenvolvimento para o software Por exemplo, se forem dominantes os riscos relacionados à interface com o usuário, pode ser utilizado o modelo de desenvolvimento evolucionário (prototipação)

47 Modelo Espiral

48 Modelo Espiral 4. Planejamento
O projeto é revisto e é tomada a decisão sobre continuar com o próximo loop da espiral Se a decisão for continuar, serão traçados os planos para a próxima fase do projeto

49 Modelo Espiral

50 Modelo Espiral Não há fases fixas, como especificação ou projeto, no modelo em espiral O modelo em espiral abrange outros modelos de processo, como por exemplo, prototipação Diferença do modelo em espiral em relação a outros modelos de processo de software → explícita consideração dos riscos no modelo em espiral

51 Equívoco Iterativo X Interativo
Duas palavras muito comuns na área de informática, mas que constantemente são confundidas em seu significado e aplicação: iterativo e interativo. Iterativo se refere a ciclo, repetição. Uma iteração é um ciclo ou uma etapa de uma rotina maior. Interativo, se refere a relacionamento, comunicação. Uma interação é uma ação mútua, uma entidade agindo sobre a outra ou vice-versa.