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

2 Introdução Processos de software podem ser melhorados através da padronização dos processos utilizados dentro de uma organização A modelagem de processos torna-se essencial para a definição de processos eficientes, capazes de serem replicados Modelagem de processos inclui responder as seguintes perguntas: O quê? Como? Quem? Quando? Por quê?

3 Modelos de Processo de Software
São representações abstratas de um processo de software das atividades, papéis e artefatos Cada modelo representa um processo a partir de uma perspectiva particular Não são descrições definitivas de processo de software, mas sim abstrações úteis, que podem ser usadas para explicar diferentes abordagens de desenvolvimento de software

4 Modelos de Processo de Software
Descrição simplificada do processo Definem as atividades para o desenvolvimento do software Especificam os produtos de cada atividade Indicam os papéis das pessoas envolvidas

5 Modelos de Processo de Software
Deve ser escolhido com base: Na natureza do projeto e da aplicação Nos métodos e ferramentas a serem utilizados Nos controles e produtos que precisam ser entregues

6 Modelos de Processo de Softwares Vantagens
Oferecem um roteiro útil para o trabalho de engenharia de software Mas, nenhum modelo de processo é perfeito Outras vantagens Padronização dos artefatos Melhor comunicação da equipe Menos treinamento de pessoal

7 Método x Processo de Software
Um método (ou modelo de processo) é algo teórico, um conjunto de possíveis ações – conteúdo do método. – Define o que, como e porque fazer 7

8 Método x Processo de Software
O processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos e métricas para se avaliar como elas estão sendo realizadas. – Define quem e quando fazer. 8

9 O Modelo em “Cascata”

10 O Modelo em “Cascata” Também conhecido como:
Clássico Waterfall Sequencial Linear Primeiro modelo publicado do processo de desenvolvimento de software (Royce, 1970)

11 O Modelo em “Cascata” Originou-se de outros processos de engenharia
Derivado do mundo do hardware (linhas de montagens) Retrata um desenvolvimento gradual Sua estrutura é composta por várias etapas que são executadas de forma sistemática e sequencial

12 O Modelo em “Cascata” Cada fase resulta em um ou mais documentos que deve ser aprovado O resultado de uma fase se constitui na entrada da outra O desenvolvimento de um estágio deve terminar antes do próximo começar

13 O Modelo em “Cascata” 13

14 O Modelo em “Cascata”

15 O Modelo em “Cascata”

16 O Modelo em “Cascata”

17 Pressman x Sommerville
O Modelo em “Cascata” Pressman x Sommerville

18 “Cascata” by Pressman

19 “Cascata” by Pressman– Comunicação
Levantamento de Requisitos: tem por objetivo propiciar que usuários e desenvolvedores tenham a mesma compreensão do problema a ser resolvido.

20 “Cascata” by Pressman– Modelagem
Análise: tem por objetivo construir modelos que determinam qual é o problema para o qual estamos tentando conceber uma solução de software.

21 “Cascata” by Pressman– Modelagem
Projeto: O modelo de análise terá de ser adaptado de tal modo que possa servir como base para implementação no ambiente alvo Traduz os requisitos em um conjunto de representações que podem ser avaliadas quando à qualidade. É avaliado antes de começar a ser implementado Junto com as etapas anteriores torna-se parte da documentação do sistema.

22 “Cascata” by Pressman – Construção
Codificação: a implementação do sistema é efetivamente executada. Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador e implementado num ambiente de trabalho. Projeto traduzido para a linguagem do computador

23 “Cascata” by Pressman – Construção
Teste: consiste na verificação do software. Concentra-se nos aspectos funcionais externos e lógicos internos do software. Garante que “todas as instruções” tenham sido testadas. A entrada definida produz os resultados exigidos?

24 “Cascata” by Pressman - Implantação
Entrada em produção do sistema Manutenção: provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente Causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

25 “Cascata” by Sommerville

26 “Cascata” by Sommerville
Análise e Definição de Requisitos As funções, as restrições e os objetivos do sistema são estabelecidos por meio de consulta aos usuários do sistema. Em seguida, são definidos em detalhes e servem como uma especificação do sistema.

27 “Cascata” by Sommerville
Projeto de Sistemas e Software O processo de projeto de sistemas agrupa os requisitos em sistemas de hardware e software. Envolve a identificação e a descrição das abstrações fundamentais do sistema de software e suas relações.

28 “Cascata” by Sommerville
Implementação e Testes de Unidade O projeto do software é compreendido como um conjunto de programas ou unidades de programa. O teste de unidade envolve verificar se cada uma das unidades atendem à sua especificação.

29 “Cascata” by Sommerville
Integração e Teste de sistemas As unidades de programa ou programas individuais são integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos. Depois do teste, o software é entregue ao cliente.

30 “Cascata” by Sommerville
Operação e manutenção O sistema é instalado e colocado em operação. Envolve corrigir erros que não foram descobertos em estágios anteriores, melhorando a implemen-tação e descobrindo novos requisitos

31 “Cascata” by Sommerville

32 O Modelo em “Cascata” na prática
Existe uma interação entre as etapas Cada etapa pode levar a modificações nas etapas anteriores As vezes o processo atrasa e necessita de uma suspensão dos requisitos

33 O Modelo em “Cascata” na prática
Demandam requisitos bem especificados Recomendado para projetos maiores de sistemas

34 O Modelo em “Cascata” na prática

35 O Modelo em “Cascata” Vantagens
Fases bem definidas Pode ser utilizado quando os requisitos são bem conhecidos e razoavelmente estáveis Recomendado para projetos de sistemas de grande porte Documentação rígida (idealmente completa) em cada atividade

36 O Modelo em “Cascata” Vantagens
Reflete abordagens adotadas em outras engenharias Aderência a outros modelos de processo Pode ser combinado a outros modelos Base para os outros

37 O Modelo em “Cascata” Desvantagens

38 O Modelo em “Cascata” Desvantagens
Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural. Em geral, é difícil para o cliente identificar todas as suas necessidades a prori É difícil para o cliente declarar todas as exigências explicitamente. É difícil acomodar as incertezas naturais que existem no começo de muitos projetos. Uma versão executável do software só fica disponível próximo ao fim do projeto, numa etapa avançada do desenvolvimento

39 O Modelo em “Cascata” Desvantagens
Projetos reais raramente seguem o fluxo sequencial que o modelo propõe Dificuldade de acomodar as mudanças após o processo ter sido iniciado Particionamento inflexível do projeto em fases distintas Dificuldade de responder a requisitos do usuário que mudam

40 O Modelo em “Cascata” Desvantagens
Difícil identificação de sistemas legados (não acomoda a engenharia reversa) Dificulta o gerenciamento de ricos Mudanças invitáveis de requisitos podem causar confusões Desenvolvedores ociosos Portanto, esse modelo mais apropriado quando os requisitos são bem compreendidos

41 O Modelo em “Cascata” - Resumo
Um dos primeiros modelos O mais antigo e amplamente usado Derivado de modelos existentes em outras engenharias Desenvolvimento gradual Fases separadas e distintas de especificação e desenvolvimento Possui uma sequência de passos na ordem em que devem ser seguidos

42 O Modelo em “Cascata” - Resumo
Existe uma consequência nas fases Simples, mas não reflete, efetivamente, o modo como o código é desenvolvido Requer uma abordagem sistemática, sequencial ao desenvolvimento de software Modelado em função do ciclo da engenharia convencional

43 O Modelo em “Cascata” – Quando aplicar?
Sistemas críticos Quando os requisitos são bem compreendidos Quando há pouca probabilidade dos requisitos mudarem

44

45 O Modelo em “Cascata” - Importância
Trouxe contribuições importantes para o processo de desenvolvimento de SW: Imposição de disciplina, planejamento e gerenciamento A implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos Permite gerência do baseline, que identifica um conjunto fixo de documentos produzidos ao longo do processo de desenvolvimento

46 Modelo V Variação do Cascata
Descreve o paralelismo entre as atividades de desenvolvimento e teste de software Modelagem de requisitos Teste de aceitação Projeto da arquitetura Teste do sistema Projeto dos componentes Teste de integração Codificação Teste de Unidades

47 Modelo V

48 Modelos Incrementais

49 Modelos Incrementais Aplicam sequências lineares, de forma iterativa, à medida que o tempo avança Cada sequência linear (cascata) gera “incrementos” (entregáveis) do software Seu foco consiste na entrega de um produto operacional a cada incremento Atividades são intercaladas Objetivo: dar feedback rápido ao cliente

50 Modelos Incrementais

51 Modelos Incrementais

52 Modelos Iterativos

53 Modelos Incrementais - Vantagens
Custo reduzido de acomodar mudanças de requisito Facilita o feedback do cliente Todo incremento gera uma entrega Problemas complexos não são resolvidos de uma única vez Sequência de builds (versões funcionais) Maior controle sobre custos e riscos Melhor gerência da instabilidade da equipe

54 Modelos Incrementais - Desvantagens
Processo não é visível A estrutura do sistema tende a degradar com a adição dos novos incrementos (exige refatoração) O processo pode não ser muito claro A gerência do software é complicada

55 Modelos Incrementais - Desvantagens
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

56 Modelos Evolucionários
Modelos iterativos com características que possibilitam desenvolver versões cada vez mais complexas do software. Obs: Os modelos incrementais e evolucionários são iterativos. A diferença entre os modelos incrementais e evolucionários é que os incrementais tem por objetivo apresentar um produto operacional a cada incremento.

57 Modelos Evolucionários
Base: Desenvolver uma implementação inicial Expor resultado ao comentário do usuário Aprimoramento por meio de muitas versões São modelos evolucionários: Prototipação Espiral Desenvolvimento Concorrente

58 Modelos Evolucionários - Tipos
Desenvolvimento exploratório O objetivo é trabalhar com os clientes e evoluir um sistema final a partir de uma especificação genérica inicial. O desenvolvimento se inicia com as partes do sistema que estão compreendidas. Fazer protótipos descartáveis O objetivo é compreender os requisitos do sistema. O protótipo se concentra em fazer experimentos com partes dos requisitos que estejam mal compreendidas

59 Desenvolvimento Evolucionário [Sommerville]

60 Desenvolvimento Evolucionário
Problemas Falta de visibilidade do processo Os sistemas frequentemente possuem pouca estrutura Podem ser exigidas habilidades especiais Ex.: Em linguagens para desenvolvimento rápido Aplicabilidade Para sistemas interativos pequenos ou de médio porte Para partes de sistemas grandes Ex.: a interface com o usuário Para sistemas de vida curta

61 Prototipação Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos. O protótipo serve como um mecanismo para a identificação dos requisitos de sw Tipos de protótipos: Exploratório: É descartado quando fica pronto, também chamado de protótipo para descarte. Evolutivo: Gradualmente evolui para se tornar um sistema real. Plano Rápido Comunicação (Início) Modelagem Projeto Rápido Implantação Entrega e Feedback Construção do Protótipo

62 Prototipação Desvantagens:
Os interessados enxergam o protótipo como um software operacional. O engenheiro de software se compromete a colocar o software em produção rapida- mente comprometendo a qualidade final do software. Plano Rápido Comunicação (Início) Modelagem Projeto Rápido Implantação Entrega e Feedback Construção do Protótipo

63 Prototipação APROPRIADO QUANDO
O cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes O desenvolvedor não tem certeza da eficiência de um algoritmo, forma da interação homem/máquina

64 Prototipação Permite o refinamento iterativo dos requisitos
A cada iteração é produzido um protótipo do software final Este protótipo pode ser um: Protótipo em Papel: primeiras versões que permitem ao usuário ter uma visão abstrata do sistema; Protótipo incompleto: implementa algum subconjunto de funções exigidas; Protótipo final: um software que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas e ainda não pode ser disponibilizado.

65 Prototipação Coleta e Refinamento dos requisitos Engenharia do Produto
Inicio Fim Coleta e Refinamento dos requisitos Projeto Rápido Construção do Protótipo Avaliação do Protótipo pelo Cliente Refinamento do Protótipo Engenharia do Produto Decide

66 Prototipação Coleta e Refinamento dos Requisitos
O desenvolvedor e o cliente devem Definir os objetivos gerais do software(Protótipo) Identificar quais requisitos são conhecidos e as áreas que necessitam de definição adicional Análise de Sistema Projeto Rápido Representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída)‏

67 Prototipação Construção do Protótipo Implementação rápida do Projeto
Avaliação do Protótipo Cliente e desenvolvedor avaliam o protótipo No caso de sugestão ou mudanças serão trabalhá-das na próxima fase

68 Prototipação Refinamento do Protótipo
São trabalhados os problemas encontrados na fase anterior. Ou seja, são refinados os requisitos. Neste ponto pode ocorrer, no caso de necessidade de alterações, um retorno na fase de projeto Rápido para desenvolver um novo protótipo que incorpora as mudanças. Construção do Produto Identificado todos os requisitos necessários, o protótipo pode ser descartado e a versão final do produto deve ser construída considerando os critérios de qualidade.

69 Prototipação Problemas
O cliente muitas vezes não aceita mais uma iteração, aquela versão mesmo incompleta já serve. Não há necessidade de desenvolver uma versão final, modifica-se o protótipo. O desenvolvedor frequentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Solução Definir as regras do jogo logo no começo, o cliente deve concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos

70 Modelo em Espiral Proposto por Boehm em 1988
Combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo em cascata O software é desenvolvido numa série de versões evolucionárias As primeiras iterações podem gerar modelos em papel ou protótipos

71 Modelo em Espiral Exige a consideração direta dos riscos técnicos em todos os estágios do projeto Pode ser adaptado para aplicação ao longo da vida do software

72 Modelo em Espiral É um modelo incremental
Combina elementos do modelo cascata (aplicado repetidamente) com a filosofia iterativa da prototipação. Acrescenta mais uma atividade: Análise de Risco O objetivo é trabalhar junto do usuário para descobrir seus requisitos, de maneira incremental, até que o produto final seja obtido

73 Modelo em Espiral O processo é representado como uma espiral, em vez de uma sequência de atividades com caminhos de retorno Cada volta na espiral representa uma fase no processo Não há fases fixas, tais como especificação ou projeto As voltas na espiral são escolhidas dependendo do que for exigido

74 Modelo em Espiral O desenvolvimento começa com as partes do produto que são mais bem entendidas A evolução acontece quando novas características são adicionadas à medida que são sugeridas pelo usuário A cada iteração é desenvolvido uma versão usável, não um protótipo

75 Modelo em Espiral planejamento análise dos riscos
decisão de continuar ou não na direção de um sistema concluído avaliação do cliente engenharia análise dos riscos planejamento

76 Modelo em Espiral Fornece o potencial para desenvolvimento rápido de versões incrementais do software Nas primeiras iterações são desenvolvido versões que podem ser protótipos Nas iterações mais adiantadas são produzido versões incrementais mais completas e melhoradas

77 Modelo em Espiral 1- PLANEJAMENTO:
determinação dos objetivos, alternativas e restrições; Comunicação com os clientes; Definição de Recursos. 2- ANÁLISE DE RISCO: análise das alternativas e identificação / resolução dos riscos

78 Modelo em Espiral 3- CONSTRUÇÃO:
desenvolvimento do produto no nível seguinte; Constrói protótipos ou versões mais avançadas do produto. Realiza Testes, implantação, suporte. 4- AVALIAÇÃO DO CLIENTE: Obter um feedBack do cliente baseado na avaliação da versão do software. São levantado as necessidades de mudança para o software

79 Modelo em Espiral - Vantagens
Abordagem realística para o desenvolvimento de software em grande escala Capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva Os riscos são explicitamente avaliados e resolvidos durante todo o processo Mantém o enfoque sistemático do ciclo clássico

80 Modelo em Espiral - Desvantagens
Pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável Requer boa capacidade para Análise de Riscos Exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso

81 Espiral Planejamento Análise dos Riscos Avaliação do Cliente
Engenharia

82 Espiral (Boehm)

83 Espiral (Pressman)

84 Espiral (Pressman)

85 Espiral - Resumo Iterativo Maior custo Muitos estágios intermediários