Adélia Barros (adelia_nassau@yahoo.com.br) Introdução à Engenharia de Software Modelos de Processo Adélia Barros (adelia_nassau@yahoo.com.br)

Apresentação em tema: "Adélia Barros (adelia_nassau@yahoo.com.br) Introdução à Engenharia de Software Modelos de Processo Adélia Barros (adelia_nassau@yahoo.com.br)"— Transcrição da apresentação:

1 Adélia Barros (adelia_nassau@yahoo.com.br)
Introdução à Engenharia de Software Modelos de Processo Adélia Barros

2 Revisando... Processo de Software
O que é processo de software: É um conjunto de todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software; Objetivos de um processo de desenvolvimento: Definir quais as atividades a serem executadas; Quando, como e por quem as atividades serão executadas; Prover pontos de controle para verificar o andamento do desenvolvimento; Padronizar a forma de desenvolver software em uma organização.

3 Revisando... Processo de Software
Através de uma visão geral um processo de software pode ser considerado assim (Uma Visão Genérica: 3 Fases): Definição - “o que” Levantamento de Requisitos; Análise de Sistemas. Desenvolvimento - “como” Projeto; Geração do Código; Teste. Implantação e Manutenção

4 Modelo de Processo de Software
A escolha de um modelo determina as técnicas e os agentes envolvidos em cada fase; depende do tipo de projeto.

5 Modelo de Processo de Software
Principais modelos ou processos: Modelo clássico (ou em cascata); Modelos Evolucionários Modelo de Prototipação ( Descartáveis ); Incremental ( Exploratório ); Espiral ( Exploratório ).

6 Processo de Software – Modelo Cascata
Também conhecido como ciclo de vida clássico ou Modelo Cascata: Modelo mais antigo e mais usado; Modelado em função do ciclo de engenharia convencional; Requer uma abordagem sistemática e seqüencial para o desenvolvimento de um software;

7 Processo de Software – Modelo Cascata
Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

8 Processo de Software – Modelo Cascata
ANÁLISE E ENGENHARIA DE SISTEMAS Envolve a coleta de requisitos de todos os elementos do sistema; Essa visão de sistema é essencial quando o software faz interface com outros elementos como HW, pessoas e BD; Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

9 Processo de Software – Modelo Cascata
ANÁLISE DE REQUISITOS DE SOFTWARE processo de coleta dos requisitos é intensificado e concentrado especificamente no software deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos os requisitos (para o sistema e para o software) são documentados e revistos com o cliente Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

10 Processo de Software – Modelo Cascata
PROJETO tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie se concentra em 4 atributos do programa: Estrutura de Dados, Arquitetura de Software, Detalhes Procedimentais e Caracterização de Interfaces Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

11 Processo de Software – Modelo Cascata
CODIFICAÇÃO tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

12 Processo de Software – Modelo Cascata
TESTES Concentram-se: nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados. Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

13 Processo de Software – Modelo Cascata
MANUTENÇÃO o software deverá sofrer mudanças depois que for entregue ao cliente Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

14 Modelo Cascata: vantagens
Os gerentes de projetos de software aceitaram o modelo entusiasticamente porque: Oferece uma maneira de tornar o processo mais visível. Facilita o planejamento. Fixa pontos específicos para a escrita de relatórios.

15 Modelo Cascata: vantagens
Apropriado para projetos que possuem uma definição estável do produto e tecnologia bastante conhecida Ex. porte de algum produto existente para uma nova plataforma. Apropriado também para projetos com requisitos estáveis e bem entendidos mas de realização complexa. Minimiza sobrecarga de planejamento, uma vez que todo o planejamento é feito no início.

16 Modelo Cascata: Problemas
Projetos reais raramente seguem o fluxo de seqüencial proposto; É difícil estabelecer todos os requisitos no começo do projeto na qual existe uma incerteza natural quanto a esses requisitos; Uma versão do software só vai ficar pronto em um ponto tardio do desenvolvimento; Assim se houver algum erro crasso não detectado na análise ou projeto o resultado pode ser desastroso; Há muitos estágios bloqueantes que permitem a ociosidade dos desenvolvedores em alguns momentos.

17 Modelo Cascata Embora o Modelo Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual (ad-hoc) ao desenvolvimento de software

18 Modelo ad-hoc

19 Desenvolvimento evolucionário

20 Desenvolvimento evolucionário
Idéia geral: Desenvolvimento da primeira versão do sistema o mais rápido possível; Modificações sucessivas até que o sistema seja considerado adequado; Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários. Adequado para o desenvolvimento de sistemas onde é difícil ou impossível de se fazer uma especificação detalhada do sistema;

21 Desenvolvimento evolucionário
Modelos Evolucionários Incremental ( Exploratório ); Modelo de Prototipação ( Descartáveis ); Espiral ( Exploratório ).

22 Modelo Incremental Os requisitos são primeiramente identificados e ,em seguida, as demais atividades do desenvolvimento são repetidas (nova versão do software). Exploração de Conceitos Requisitos Projeto Implementação Instalação Manutenção Versão 1..n

23 Modelo Incremental Surgiu para remediar a deficiência do modelo em cascata Cascata parte do princípio irreal de que os requisitos permanecem estáveis

24 Desenvolvimento Evolucionário: Prototipação descartável
O objetivo é entender os objetivos do sistema. Começa com requisitos vagamente entendidos. A primeira fase prevê o desenvolvimento de um programa para o usuário experimentar. No entanto, o objetivo aqui é estabelecer os requisitos do sistema. O software deve ser reimplementado na fase seguinte.

25 Desenvolvimento Evolucionário: Prototipação descartável
A construção de protótipos com os quais os usuários possam brincar é uma idéia bastante atrativa: Para sistemas grandes e complicados. Quando não existe um sistema anterior ou um sistema manual que ajude a especificar os requisitos. Os objetivos do protótipo devem estar bem claros antes do início da codificação. Possíveis objetivos: Entender os requisitos dos usuários. Definir a interface com os usuários. Demonstrar a viabilidade do sistema para os gerentes.

26 Desenvolvimento Evolucionário: Prototipação descartável
Uma decisão importante a ser tomada é escolher o que será e o que não será parte do protótipo. Não é economicamente viável implementar todo o sistema! Os objetivos do protótipo são o ponto de partida.

27 Prototipagem: o que incluir no protótipo?
Algumas possibilidades: Implementar todas as funções do sistema mas com um número reduzido de detalhes. Implementar um subconjunto das funções, possivelmente com um número maior de detalhes. Desconsiderar requisitos associados a velocidade, espaço, confiabilidade, etc. A menos que o objetivo do protótipo seja definir a interface com o usuário, desconsiderar a parte de manipulação de erros.

28 Refinamento dos requisitos obtenção dos requisitos
Prototipação fim início construção produto Refinamento dos requisitos avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos

29 Prototipação: possíveis vantagens
Protótipos contribuem para melhorar a qualidade da especificação dos futuros programas, o que leva à diminuição dos gastos com manutenção. O treinamento dos usuários pode ser feito antes do produto ficar pronto. Partes do protótipo podem ser usadas no desenvolvimento do sistema final.

30 Prototipação: possíveis desvantagens
Em geral o grande argumento contra a construção de protótipos é o custo. A construção do protótipo atrasa o início da implementação do sistema final. Atrasos são um dos maiores problemas dos projetos de software. Construir um protótipo pode não ser tão mais rápido assim do que construir o sistema final.

31 Prototipação: possíveis desvantagens
O cliente vê algo que parece ser uma versão do software desejado e não entende porque o produto precisa ser reconstruído. A tendência é o cliente exigir que pequenos acertos sejam feitos para que o protótipo se transforme no sistema final. Freqüentemente a gerência cede ... Muitas das concessões feitas na implementação do protótipo visando a construção rápida podem vir a fazer parte do sistema final. Utilização de linguagens, ferramentas, algoritmos, etc. que sejam inadequados e/ou ineficientes.

32 O Modelo Espiral Foi criado visando abranger as melhores características do modelo clássico e da prototipagem. Acrescenta aspectos gerenciais ao processo de desenvolvimento de software. análise de riscos em intervalos regulares do processo de desenvolvimento de software; planejamento; controle; tomada de decisão.

33 Fases do modelo espiral
Planejamento: determinação dos objetivos, alternativas e restrições; Análise de riscos: análise de alternativas e identificação / resolução dos riscos; Engenharia: desenvolvimento do produto no “nível seguinte”; Avaliação feita pelo cliente: avaliação dos resultados da engenharia.

34 O Modelo Espiral

35 O Modelo Espiral Observações:
A cada ciclo da espiral, versões progressivamente mais completas do software são construídas; Antes de cada ciclo, uma análise de riscos é feita; Ao fim de cada ciclo é feita uma avaliação se deve-se prosseguir para o próximo ciclo.

36 O Modelo Espiral:risco
O que é risco? Difícil de se definir precisamente! Qualquer coisa que possa sair errado; Conseqüência de informação inadequada; O risco de uma atividade é a medida de incerteza do resultado desta atividade; O risco está associado com a quantidade de informação disponível: quanto menos informação, maior o risco; Riscos são resolvidos por ações que descubram ou gerem informações que reduzam o grau de incerteza. Há quem defenda que a tarefa principal dos gerentes de projetos de software é a minimização dos riscos.

37 “Execução” padrão de uma volta na espiral
Objetivos Restrições Alternativas Riscos Resolução do risco Resultados Planos Compromisso

38 Ex: Melhoria da Qualidade
Objetivos Melhoria significativa da qualidade do software Limitações No prazo de três anos Sem grande investimento de capital Sem mudanças radicais nos padrões da companhia Alternativas Reuso de software certificado existente Introduzir especificação e verificação formal Investir em ferramentas de teste e validação

39 Ex: Melhoria da Qualidade (cont)
Riscos Não ser possível alcançar uma melhoria de qualidade com custo apropriado; Melhoria de qualidade poder aumentar o custo de forma excessiva; Novos métodos podem causar a saída de funcionários. Resolução de risco Pesquisa na literatura existente; Projeto piloto; Levantamento de componentes potencialmente reutilizáveis; Avaliação das ferramentas de suporte disponíveis; Treinamento de funcionários e seminários de motivação.

40 Ex: Melhoria da Qualidade (cont)
Resultados Dificuldade de quantificar melhorias; Pouca disponibilidade de ferramentas de suporte para os padrões de desenvolvimento da empresa; Disponibilidade de componentes para reuso, porém poucas ferramentas para suporta reutilização. Planejamento Explorar em mais detalhes a opção de reuso; Desenvolver protótipos de ferramentas de suporte de reuso; Explorar o esquema de certificação de componentes. Compromisso Patrocinar uma fase de estudo com duração de 18- meses.

41 Vantagem do modelo espiral
Introduz a análise de riscos; Foca atenção em eliminação precoce de erros; Iterativo e incremental, a cada iteração, versões mais completas do software são progressivamente construídas; Acomoda mudanças nos requisitos; Diminui os riscos em projetos de grande escala.

42 Problemas do modelo espiral
Gerenciamento mais complexo; Cliente deve estar disponível a cada ciclo; Nem todo cliente aceita a abordagem do modelo; É difícil convencer gerentes de que todo este processo é controlável; Requer experiência em avaliação de risco.

43 Pontos principais A engenharia de software trata de teorias, métodos e ferramentas para o desenvolvimento, gerenciamento e evolução de produtos de software Produtos de software incluem programas e documentação. Atributos do produto: manutenabilidade, dependabilidade, eficiência e usabilidade O processo de software consiste daquelas atividades envolvidas no desenvolvimento de software

44 Pontos principais O modelo cascata considera cada atividade do processo uma fase distinta Desenvolvimento evolucionário considera as atividades do processo concorrentemente O modelo espiral é baseado em riscos A visibilidade do processo envolve a criação de produtos associados às atividades

45 Processo de Software – Conclusão
ENGENHARIA DE SOFTWARE pode ser vista como uma abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos. .....“a construção por múltiplas pessoas de um software de múltiplas versões” [Parnas 1987]

46 Introdução à Engenharia de Software
DÚVIDAS ?