Adélia Barros (adelia_nassau@yahoo.com.br) Introdução à Engenharia de Software 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 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 Adélia Barros

2 Objetivos Definir a engenharia de software e explicar sua importância
Discutir os conceitos de produto de software e processo de software Explicar a importância da visibilidade do processo Introduzir o conceito de software de qualidade

3 Tópicos Contexto e definições Características do (produto) software
Software de Qualidade Crise do software Mitos do software Processo de software Paradigmas de desenvolvimento

4 Contexto A economia de todos os países do mundo depende cada vez mais de software. Existem cada vez mais sistemas controlados por software. Os gastos com desenvolvimento de software representam uma fração significativa do PIB de muitos países.

5 Contexto O desenvolvimento de software é muitas vezes puramente artesanal; As pessoas desenvolvendo sistemas erram constantemente nas suas estimativas de custo e tempo; Vários sistemas contém muitos erros; Consertar erros muitas vezes produz mais erros; O tamanho dos sistemas cresce consideravelmente.

6 Contexto: exemplos interessantes
Estudo feito em 1979 pelo governo dos Estados Unidos em relação ao software produzido: 2% Funcionava; 3% Funcionaria com poucas correções; 45% Entregues mas nunca foram usados com sucesso; 20% Usados, mas tremendamente modificados ou abandonados; 30% Pagos, mas nunca foram terminados e/ou entregues.

7 Contexto: exemplos interessantes
Dados levantados no Chaos Report, estudo clássico feito pelo Standish Group sobre projetos de desenvolvimento (Chaos, 1994): 10% terminam dentro do prazo estimado; 25% são descontinuados antes de chegarem ao fim; 60% dos projetos possuem custo acima do esperado; Atraso médio nos projetos: um ano.

8 Contexto: exemplos interessantes
A proporção dos custos com software e hardware mudou bastante ao longo do tempo: Década de 60: 20% -- 80% Década de 70: 50% -- 50% Década de 90: 80% -- 20% Atualmente: % -- 10%

9 Custo do Software Custo do software geralmente domina o custo do desenvolvimento. Os custos do software de um PC são geralmente maiores do que do hardware. Software custa mais para manter do que para desenvolver! Os custos de manutenção são várias vezes maiores do que o de desenvolvimento

10 Definições de Engenharia de Software
Disciplina que se preocupa com os problemas práticos inerentes ao desenvolvimento de sistemas Não é simplesmente programação; Também não é só ciência da computação; Uso de teorias (resultados), métodos, e ferramentas na resolução de problemas.

11 Definições de Engenharia de Software
É o estabelecimento e uso de sólidos princípios de engenharia visando obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais [Bauer69].

12 Definições de Engenharia de Software
É a aplicação de ciência e matemática visando tornar as capacidades do equipamento úteis para o ser humano através de programas, procedimentos e documentação; É a abordagem sistemática para o desenvolvimento, operação, manutenção, e aposentadoria de Software.

13 Características da Engenharia de Software
Engenharia de Software se refere a software (sistemas) desenvolvidos por grupos ao invés de indivíduos; Engenharia de Software usa princípios de engenharia ao invés de arte, e Engenharia de Software inclui tanto aspectos técnicos quanto não técnicos.

14 Características da Engenharia de Software
O principal objetivo da Engenharia de Software é produzir, a um custo baixo, software de qualidade. Custo é fácil de ser medido; Qualidade não é. O processo de planejamento é crucial na engenharia de software. A implementação é só uma parte do processo.

15 Características da Engenharia de Software
A Engenharia de Software engloba todo o ciclo de vida do software (concepção, implementação, uso e manutenção).

16 O que é Software? Há 20 anos, pouquíssima gente sabia explicar o que é software. Hoje, praticamente todo mundo acha que sabe ... Software não é só programas! A documentação necessária para instalar, usar, e manter os programas é parte integrante do software.

17 O que é Software? Definição - Software é:
Instruções (programas de computador) que, quando executadas, produzem a função e o desempenho desejados; Estruturas de dados que permitem a manipulação das informações; Documentos que descrevem a operação e uso dos programas.

18 Tipos de software

19 Atributos dos produtos de Software
Manutenibilidade Deve ser possível para o software evoluir de forma a atender a requisitos que mudam. Nível de confiança Software não deve causar prejuízo físico ou econômico no caso de uma falha. Eficiência Software não deve desperdiçar recursos do sistema. Usabilidade O software deve ter uma interface de usuário adequada e ser documentado.

20 Importância das características do produto
A importância relativa destas características depende do produto e do ambiente em que ele será usado Em alguns casos, alguns dos atributos podem ser mais importantes Em sistemas de segurança críticos, de tempo- real, os atributos chave podem ser confiança e eficiência

21 O que é software de qualidade ?
É software que “funciona” (é confiável): ele não deve falhar mais do que o especificado na documentação. É software que funciona de acordo com a sua especificação: Mesmo software que aparentemente funciona pode não estar satisfazendo a sua especificação. É software que é fácil de manter. Código bem escrito Documentação apropriada.

22 O que é Software de qualidade?
É software que funciona de maneira eficiente. Software mais eficiente não é necessariamente software que roda mais rápido ou que gasta menos memória/disco; A complexidade do código e o custo também são fatores importantes. É software que possui uma boa interface com o usuário: Muitos softwares não funcionam direito porque são difíceis de usar.

23 A Crise de Software O que é esta crise?
Métodos de desenvolvimento de software existentes não são bons o bastante para o desenvolvimento de software de grande porte.

24 A Crise de Software: crise?
Momento perigoso ou decisivo. Decadência, carência, queda. Mas a chamada crise de software já dura mais de 30 anos. DOENÇA? No momento não se conhece uma cura, apenas paliativos para reduzir a dor.

25 Therac-25 Equipamento de Radioterapia.
Entre 1985 e 1987 se envolveu em 6 acidentes, causando mortes por overdoses de radiação. Software foi adaptado de uma antecessora, Therac-6: falhas por falta de testes integrados falta de documentação

26 Denver International Airport
Custo do projeto: US$ 4.9 bilhões 100 mil passageiros por dia 1,200 vôos 53 milhas quadradas 94 portões de embarque e desembarque 6 pistas de pouso / decolagem

27 Denver International Airport
Erros no sistema automático de transporte de bagagens (misloaded, misrouted, jammed): Atraso na abertura do aeroporto com custo total estimado em US$360 Milhões 86 milhões para consertar o sistema

28 Ariane 5

29 Ariane 5 Projeto da Agência Espacial Européia que custou:
10 anos. US$ 8 Bilhões. Capacidade 6 toneladas. Garante supremacia européia no espaço.

30 Resultado Explosão 40 segundos após a decolagem.
Destruição do foguete e carga avaliada em US$ 500 milhões.

31 O que aconteceu? (I) Fato: o veículo detonou suas cargas explosivas de autodestruição e explodiu no ar. Por que? Porque ele estava se quebrando devido às forças aerodinâmicas. Mas por que? O foguete tinha perdido o controle de direção (atitude). Causa disso? Os computadores principal e back-up deram shut-down ao mesmo tempo.

32 O que aconteceu? (II) Por que o Shut-down? Ocorrera um run time error (out of range, overflow , ou outro) e ambos computadores se desligaram. De onde veio este erro? Um programa que convertia um valor em ponto flutuante para um inteiro de 16 bits recebeu como entrada um valor que estava fora da faixa permitida.

33 A Crise de Software: principais problemas
Os grandes softwares não funcionam adequadamente; Os projetos de software estão sempre atrasados; Os custos dos projetos de desenvolvimento de software são sempre maiores do que o previsto.

34 A Crise de Software: principais problemas
Os computadores estão cada vez mais rápidos, sofisticados, e baratos; Os softwares estão cada vez maiores e mais sofisticados, e a produtividade não acompanha a demanda; Os custos com manutenção são muito altos: para sistemas com uma longa vida, eles são várias vezes maiores do que os custos de desenvolvimento.

35 A Crise de Software: outras dificuldades
Dedica-se pouco tempo à coleta de dados (requisitos dos clientes): Normalmente apenas um subconjunto das necessidades do cliente são levadas em conta ... Os profissionais estão sempre com muita pressa para começar a programar ...

36 A Crise de Software: outras dificuldades
A qualidade geralmente é suspeita ... Testes sistemáticos e tecnicamente completos raramente são feitos; A flexibilidade da maioria dos softwares também é bastante limitada; A concorrência com software barato mas sem qualidade, feito por pessoas sem qualificação adequada, é grande.

37 A Crise de Software: outras dificuldades
Não há muito interesse em se gastar tempo para se entender mais a respeito de estimativas, produtividade, precisão e eficácia de novos métodos e novas ferramentas, etc. A resistência a mudanças é grande ...

38 A Crise de Software: existe solução?
O uso de melhores técnicas, métodos, e ferramentas. Mais treinamento e educação: atualmente se investe muito pouco!

39 Mitos do Software Propagam desinformação e confusão.
No passado eram tomados como verdades absolutas. É difícil mudar hábitos antigos. Existem 3 tipos de mitos: Do cliente; Administrativos, e Do profissional.

40 Mitos do Software: mitos do cliente
Uma declaração geral dos objetivos é suficiente para começar a escrever os programas: podemos preencher os detalhes mais tarde. Uma definição inicial ruim é a principal causa da maioria dos fracassos no desenvolvimento de software. Estudo baseado em 6700 sistemas feito em 1997, mostrou que os custos resultantes de um fraco entendimento do problema podem ser 200 vezes maiores que o necessário (Carper Jones, 1997).

41 Mitos do Software: mitos do cliente
As necessidades do projeto mudam continuamente mas isto não é problema pois o software é flexível. Os requisitos do software podem mudar, mas o custo da mudança varia bastante dependendo da fase em que ela ocorre: Definição x Desenvolvimento x a 1.6x Manutenção x a 100x

42 Mitos do Software: mitos administrativos
Temos um manual de padrões e procedimentos para a construção de software e isto basta! O manual é usado? Os profissionais de software sabem que ele existe? Ele reflete as técnicas mais modernas? Ele é completo?

43 Mitos do Software: mitos administrativos
Temos ferramentas de desenvolvimento de última geração, pois compramos os computadores mais novos! Em geral, ter ferramentas de auxílio ao desenvolvimento de software (ex. CASE) é mais importante do que ter a última geração em termos de hardware.

44 Mitos do Software: mitos administrativos
Estamos atrasados no prazo: podemos tirar o atraso colocando mais programadores no projeto. Normalmente isto não funciona! As novas pessoas precisam se integrar ao projeto ...

45 Mitos do Software: mitos do profissional
Assim que escrevermos o programa e ele funcionar o nosso trabalho está terminado. Em geral, mais de 70% de todo o esforço gasto num programa ou sistema ocorre depois que ele foi entregue ao cliente (manutenção); Na maioria das vezes, quanto mais cedo se começa a escrever o código mais tempo se gastará para terminá- lo.

46 Mitos do Software: mitos do profissional
Enquanto o programa não estiver funcionando não há como avaliar a sua qualidade. Revisões técnicas podem ser feitas desde o começo de um projeto e são uma das formas mais efetivas de garantia de qualidade de software.

47 Mitos do Software: mitos do profissional
A única coisa a ser entregue em um projeto bem sucedido é o programa funcionando. O programa funcionando é só uma parte; Uma boa documentação incluindo os requisitos, projeto das estruturas de dados, especificação de testes, etc. é o alicerce para um projeto bem sucedido e serve como guia de manutenção.

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

49 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

50 Levantamento de Requisitos
Compreensão do problema; Usuários e desenvolvedores devem ter a mesma visão do problema; Definir as necessidades dos futuros usuários; Definição do Escopo; Entender o domínio do negócio que deve ser automatizado.

51 Levantamento de Requisitos
Requisitos Funcionais: Definem as funcionalidades do sistema. Requisitos não-funcionais: Declaração as características de qualidade que o sistema deve possuir; Declaração das restrições sobre o desenvolvimento do sistema. Ordenação dos requisitos.

52 Análise Entendimento geral do problema que se tem para resolver;
Divisão do sistema em módulos; Construção de modelos para representar o sistema; Definir o que o sistema proposto deve fazer; Análise de domínio Modelagem de objetos do mundo real; Análise da aplicação Identificação de objetos que só tem sentido no contexto de um sistema de software; Modelo de análise.

53 Projeto de Sistemas UML Modelar o que e como será implementado;
Definir a arquitetura que será utilizada; Diagramas para facilitar o entendimento; UML Modelo de Dados; Modelo da implementação; Componentes do sistema; Padrões de interface gráfica.

54 Implementação de Sistemas
Tradução da descrição computacional obtida na fase de projeto em código executável; Criar ou adquirir os componentes identificados na fase de projeto; Montar os componentes; Implementar o sistema novo ou modificado; Testes unitários.

55 Testes de Sistemas Realização de Testes Unitários;
Preparação do Projeto de Testes; Módulos da aplicação; Outras aplicações; Relatório de testes.

56 Implantação de Sistemas
Planejamento da Implantação; Treinamento do Usuário Final; Preparação do material para treinamento; Preparação do Ambiente de Produção; Banco de Dados; Versão do Software que será instalada. Plano para atendimento na fase de garantia; Preparação do “HelpDesk”.

57 Manutenção Processo geral de modificação de um sistema depois de ter sido colocado em uso; Tipos de Manutenção Para reparar defeitos; Para adaptar o software a ambiente operacional diferente; Para fazer acréscimo de funcionalidade; Melhorar o desempenho.

58 Processo de Software Atividades de apoio:
Controle e Rastreamento do Projeto; Revisões Técnicas Formais; Garantia de Qualidade; Gerenciamento de Configuração; Produção e Preparação de Documentos; Gerenciamento de Reusabilidade; Gerenciamento de Risco.

59 Papéis no desenvolvimento de um software
Gerente de Projetos Responsabilidades: Planejamento do Projeto Análise dos Riscos Acompanhamento dos Custos do Projeto Acompanhamento do Cronograma de Execução Acompanhamento e Motivação da Equipe Satisfação do cliente Controlar o Escopo do Projeto Entre outras Cronograma Custos (R$) Qualidade Satisfação do Cliente Satisfação da Equipe Gerente de Projetos

60 Papéis no desenvolvimento de um software
Gerente de Projetos Habilidades Liderança Organização Motivação Negociação Educação Conhecimento técnico e do negócio Entre Outras Cronograma Custos (R$) Qualidade Satisfação do Cliente Satisfação da Equipe Gerente de Projetos

61 Gerente de Projetos (Qual o melhor perfil ?)
O projeto envolve tecnologia nova e avançada Uma pessoa do departamento de informática. O impacto do projeto forçará modificações fundamentais numa área funcional da empresa O gerente da área funcional. O projeto é extremamente grande e complexo Um especialista em gerenciamento de projetos. O projeto será um combinação das características acima Deve ser montada uma equipe que inclua pessoas de todas as áreas afetadas.

62 Papéis no desenvolvimento de um software
Analista de Sistemas/Negócios Responsabilidades: Entendimento dos Requisitos de Software Concepção do Modelo de Negócios (Aplicando a Metodologia) Modelagem de Dados e Classes Diagramas da UML Interação com o Cliente (usuários) Documentação da Aplicação Entre outras Requisitos Documentação Aplicar a Metodologia Entender o Cliente !

63 Papéis no desenvolvimento de um software
Analista de Sistemas/Negócios Habilidades Liderança Organização Motivação Negociação Educação Conhecimento Entre Outras Requisitos Documentação Aplicar a Metodologia Entender o Cliente !

64 Papéis no desenvolvimento de um software
Arquiteto/Engenheiro de Software Responsabilidades: Projetar a arquitetura do Software Implementação do sistema Testes da Aplicação (principalmente os requisitos relacionados a performance) Entre outras Habilidades Organização Conhecimentos Técnicos Educação Entre Outras SE (X > 20) Então Y = X Senão X = X + 1 Linguagem OO ou Procedural

65 Papéis no desenvolvimento de um software
Gerente de Configuração Controlar as versões do software disponibilizadas; Garantir a integridade da Documentação com o Código Implementado Engenheiro de Qualidade Garantir a qualidade do produto: documentação e código Engenheiro de Testes Realizar testes no sistema; Administrador de Banco de Dados

66 Processo de Software Processo de Software é diferente de Engenharia de Software: Processo define a abordagem; Engenharia engloba também as tecnologias como métodos e ferramentas.

67 Processo de Software Já vimos que Engenharia de Software é:
Uma disciplina da engenharia que se ocupa de todos os aspectos do desenvolvimento de software. Para o IEEE é: Aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, operação e manutenção de software, ou seja, a aplicação da engenharia ao software.

68 Processo de Software Analisando as definições anteriores podemos encarar a Engenharia de Software como uma tecnologia em camadas: ferramentas métodos processo foco na qualidade

69 Processo de Software ferramentas métodos processo foco na qualidade É o “solo” e o porque de utilizarmos um processo de software; Gerenciamento da Qualidade Total e filosofias similares produzem uma mudança cultural que permite o desenvolvimento crescente de abordagens mais maduras para a Engenharia de Software

70 Processo de Software É a “fundação”;
ferramentas métodos processo foco na qualidade É a “fundação”; É o que intermedeia as camadas de tecnologias e permite um desenvolvimento de software racional e em tempo; Define um conjunto de áreas chave do processo que deve ser estabelecido para um uso efetivo da Engenharia de Software;

71 Processo de Software É o “como fazer”;
ferramentas métodos processo foco na qualidade É o “como fazer”; Englobam um conjunto de tarefas que inclui análise de requisitos, projeto, implementação, teste e manutenção;

72 Processo de Software É o “instrumento apropriado”;
ferramentas métodos processo foco na qualidade É o “instrumento apropriado”; Dão suporte automatizado ou semi-automatizado aos métodos; Quando as ferramentas que apóiam os métodos se integram, forma-se a Engenharia de Software auxiliada por computador – CASE – Computer Aided Software Engineering;

73 Processo de Software Processo de software define uma abordagem;
Modelo é uma descrição simplificada, uma abstração dessa abordagem;

74 Processo de Software Ciclos de vida de software
A principal função de um modelo de ciclo de vida é estabelecer a ordem na qual as atividades de um projeto devem ser realizadas. O ciclo de vida estabelece o critério que deve ser usado para passar de uma atividade a outra.

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

76 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 ).

77 Processo de Software – Modelo Clássico
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;

78 Processo de Software – Modelo Clássico
Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

79 Processo de Software – Modelo Clássico
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

80 Processo de Software – Modelo Clássico
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

81 Processo de Software – Modelo Clássico
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

82 Processo de Software – Modelo Clássico
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

83 Processo de Software – Modelo Clássico
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

84 Processo de Software – Modelo Clássico
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

85 Modelo Clássico: 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.

86 Modelo Clássico: 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.

87 Modelo Clássico: 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.

88 Modelo Clássico Embora o Modelo Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

89 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

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

91 Desenvolvimento evolucionário

92 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; Principal diferença dos outros modelos é a ausência da noção de programa correto.

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

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

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

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

97 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

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

99 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. Se os ambientes utilizados forem diferentes este custo será um custo extra.

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

101 Modelo Iterativo • • • Análise Projeto Codificação 1 N
1 N • • • Combina suas vantagem com o modelo de prototipação; Desenvolvimento incremental até a versão final; Cada passo dado pode ser feitas modificações na versão anterior; A vantagem é a de teste módulo a módulo construído. Desvantagem: alto grau de planejamento.

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

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

104 O Modelo Espiral Planejamento Engenharia Avaliação do cliente
Direção da conclusão do sistema Engenharia Avaliação do cliente Análise de riscos Análise de riscos baseada nos requisitos iniciais Análise de riscos baseada na reação do cliente Decisão de prosseguir ou não. Sistema finalizado Versões intermediárias

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

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

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

108 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

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

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

111 Ex.: Catálogo de Componentes
Objetivo Obter um catálogo de componentes de software. Limitações Dentro de uma ano; Deve suportar os tipos de componentes existentes; Custo total menor que R$ ,00. Alternativas Comprar um software existente para recuperação de informação; Comprar uma banco de dados e desenvolver um catálogo usando o banco de dados da empresa; Desenvolver um catálogo de propósito especial.

112 Ex.: Catálogo de Componentes (cont)
Riscos Pode ser impossível obtê-lo de acordo com as limitações impostas; A funcionalidade do catálogo pode ser inapropriada. Resolução do risco Desenvolver um protótipo do catálogo para clarificar requisitos; Contratar consultores para relatar as capacidades atuais dos sistemas de recuperação de informação; Relaxar as limitações de prazo.

113 Ex.: Catálogo de Componentes (cont)
Resultados Sistemas de recuperação de informação são inflexíveis; Requisitos identificados não podem ser alcançados; Protótipo utilizando o SGBD pode ser estendido para completar o sistema; O desenvolvimento de uma catálogo de propósito especial pode ser muito caro. Planos Desenvolver o catálogo utilizando SGBD existente , estendendo o protótipo e melhorando a interface com o usuário. Compromisso Patrocinar mais 12 meses de desenvolvimento

114 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. Aumenta a visibilidade; Acomoda mudanças nos requisitos; Diminui os riscos em projetos de grande escala.

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

116 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

117 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

118 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]

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