A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Adélia Barros Introdução à Engenharia de Software Modelos de Processo.

Apresentações semelhantes


Apresentação em tema: "Adélia Barros Introdução à Engenharia de Software Modelos de Processo."— Transcrição da apresentação:

1 Adélia Barros Introdução à Engenharia de Software Modelos de Processo

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 ProjetoProjeto CodificaçãoCodificação TestesTestes ManutençãoManutenção

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

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

10 Processo de Software – Modelo Cascata Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção PROJETO PROJETO 1. 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 2. se concentra em 4 atributos do programa: Estrutura de Dados, Arquitetura de Software, Detalhes Procedimentais e Caracteriza ç ão de Interfaces

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

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

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

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 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; Desenvolvimento evolucionário

21 Modelos Evolucionários Incremental ( Exploratório ); Modelo de Prototipação ( Descartáveis ); Espiral ( Exploratório ). Desenvolvimento evolucioná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 ProjetoImplementaçãoInstalaçãoManutençã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 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. Desenvolvimento Evolucionário: Prototipação descartável

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 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 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 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. Ex: Melhoria da Qualidade (cont)

40 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. Ex: Melhoria da Qualidade (cont)

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 ?


Carregar ppt "Adélia Barros Introdução à Engenharia de Software Modelos de Processo."

Apresentações semelhantes


Anúncios Google