06/05/2010 01 - Introdução 1 Universidade Federal do Paraná Setor de Ciências Exatas Departamento de Informática ESPECIALIZAÇÃO EM INFORMÁTICA Análise.

Apresentação em tema: "06/05/2010 01 - Introdução 1 Universidade Federal do Paraná Setor de Ciências Exatas Departamento de Informática ESPECIALIZAÇÃO EM INFORMÁTICA Análise."— Transcrição da apresentação:

1 06/05/2010 01 - Introdução 1 Universidade Federal do Paraná Setor de Ciências Exatas Departamento de Informática ESPECIALIZAÇÃO EM INFORMÁTICA Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 01 - Introdução

2 06/05/2010 2 Conteúdos 1. Considerações iniciais 2. Conceitos básicos 3. Engenharia de software 3.1. Princípios 3.2. Paradigmas 3.3. Interação da engenharia de software com outras áreas 4. Considerações finais 5. Exercícios Bibliografia

3 06/05/2010 01 - Introdução 3 1. Considerações iniciais Sistemas (“sistemas de software”) Papel cada vez mais importante Funcionamento correto ou incorreto = vida ou morte Espaçonaves, aeronaves, trens, carros, reatores nucleares, equipamentos hospitalares, contas bancárias (segurança de acesso, movimentação correta),... Aplicações TÊM DE SER totalmente confiáveis! Cumprir requisitos integralmente Requisitos intransigentes Restrições de integridade Vasto conhecimento sobre a aplicação Interações software x ambiente adequadas

4 06/05/2010 01 - Introdução 4 1. Considerações iniciais (cont.) Construir (bons) produtos de software envolve: Compreender a complexidade dos produtos (cresc.) Gerenciar equipes multidisciplinares Obter informações precisas sobre os produtos a serem desenvolvidos Comunicação adequada Sincronizar e controlar atividades Paralelas Diversos profissionais Diversas equipes

5 06/05/2010 01 - Introdução 5 1. Considerações iniciais (cont.) Atividades essenciais (do início do desenvolvimento) : Extração de requisitos (características do produto a ser desenvolvido) Complexa Baseada na comunicação entre equipes Representação adequada de requisitos Abstrações representativas das diferentes propriedades do sistema Notações formais / semiformais Planejamento e acompanhamento de atividades do projeto Controle do processo de desenvolvimento

6 06/05/2010 01 - Introdução 6 2. Conceitos básicos Sistema - do latim systema, reunião, grupo; “Conjunto de princípios reunidos de modo a formar um corpo de doutrina”; “Conjunto de partes coordenadas que concorrem para o atingimento de um resultado (conjunto de objetivos) ou para formar um conjunto”; “Conjunto de elementos, concretos ou abstratos, entre os quais se pode encontrar alguma relação”; “Conjunto, identificável e coerente, de elementos que interagem coesivamente, onde cada elemento pode ser um sistema”; (...)

7 06/05/2010 01 - Introdução 7 2. Conceitos básicos (cont.) Existe uma relação estrutural entre as partes componentes de um sistema Sistema x universo: fronteira conceitual Elementos internos Entidade relativamente autônoma e identificável Fortes interações entre si Elementos externos Fracas interações com elementos internos: devem ser fracas o suficiente para que possamos desprezá-las

8 06/05/2010 01 - Introdução 8 2. Conceitos básicos (cont.) Exemplo 1: Ecossistema de certa espécie de inseto que passa toda a sua vida em uma única árvore de determinada espécie. Fronteira conceitual Inseto (fisiologia, anatomia, hábitos reprodutivos, ciclo de vida, etc.) Árvore Fauna que habita a árvore Caracterização do habitat da árvore (clima, solo, vegetação na vizinhança, etc.)

9 06/05/2010 01 - Introdução 9 2. Conceitos básicos (cont.) Exemplo 2: Ecossistema floresta amazônica. Fronteira conceitual ?

10 06/05/2010 01 - Introdução 10 2. Conceitos básicos (cont.) Exemplo 2: Ecossistema floresta amazônica. Fronteira conceitual ? Flora Fauna Ocupação humana na floresta e em volta dela Utilização humana da floresta Aspectos climáticos, atmosféricos, etc. Etc.

11 06/05/2010 01 - Introdução 11 2. Conceitos básicos (cont.) Em sistemas de software, determinar a fronteira conceitual adequada É um passo decisivo no processo de concepção do sistema Permite separar componentes pertencentes Ao sistema Informações devem ser estudadas em detalhes Ao ambiente externo Interesse: interações com o sistema

12 06/05/2010 01 - Introdução 12 2. Conceitos básicos (cont.) Exemplo 3: Sistema de reservas de passagens aéreas de uma determinada companhia. Fronteira conceitual ?

13 06/05/2010 01 - Introdução 13 2. Conceitos básicos (cont.) Exemplo 3: Sistema de reservas de passagens aéreas de uma determinada companhia. Fronteira conceitual ? Companhia Dados sobre vôos: disponibilidades, reservas, cancelamentos, etc.) Se o sistema de software incluir reservas de hotéis, locação de carros, ofertas de pacotes turísticos, etc., a fronteira conceitual terá de ser ampliada para contemplar informações sobre ? Hotéis, locadoras de carros, agências de turismo, etc.

14 06/05/2010 01 - Introdução 14 2. Conceitos básicos (cont.) Produtos de software Sistemas de software entregues ao usuário com a documentação que descreve como instalá-lo e usá-lo Categorias de produtos de software Sistemas genéricos: produzidos e vendidos no mercado Sistemas específicos: produzidos sob encomenda especialmente para um determinado cliente Composição dos produtos de software Instruções (programas de computador) Estruturas de dados (manipuladas pelas instruções) Documentos (descrevem operações e uso do produto)

15 06/05/2010 01 - Introdução 15 2. Conceitos básicos (cont.) Processo de desenvolvimento de software Conjunto de atividades e resultados associados, com o objetivo de construir um produto de software Desenvolvimento Especificação de funcionalidades e restrições relativas à operacionalidade do software Produção do software conforme as especificações Validação Avaliação da aderência do software às necessidades do usuário Manutenção Correções, adaptações e ampliações para corrigir erros pós- entrega Atender novos requisitos / mudanças na tecnologia

16 06/05/2010 01 - Introdução 16 2. Conceitos básicos (cont.) No processo de desenvolvimento de software, modelos de processos (paradigmas) especificam: Quais atividades devem ser executadas Qual a ordem de execução das atividades Produtos de software podem ser construídos utilizando-se diferentes modelos de processos Alguns modelos são mais adequados que outros = f(tipo da aplicação) A escolha de um determinado modelo deve ser feita = f(produto a desenvolver)

17 06/05/2010 01 - Introdução 17 3. Engenharia de software Décadas de 60 e 70, desafio era desenvolver hardware que reduzisse custos de: Processamento Armazenagem de dados Década de 80, f(avanços na microeletrônica): Aumento do poder computacional Custo cada vez menor Processo de desenvolvimento e software: Cronogramas não eram cumpridos Custos excediam previsões Requisitos não eram cumpridos Etc.

18 06/05/2010 01 - Introdução 18 3. Engenharia de software (cont.) Desafio atual (há ± 3 décadas): Melhorar a qualidade Reduzir o custo do software Introduzir disciplina no desenvolvimento Engenharia de software Uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizadas, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software.

19 06/05/2010 01 - Introdução 19 3. Engenharia de software (cont.) Objetivos da engenharia de software Auxiliar no processo de produção de software Processo para gerar produtos de alta qualidade Mais rapidamente Custo cada vez menor Problemas a tratar, f(atributos do processo e do produto de software) Complexidade, visibilidade, aceitabilidade, confiabilidade, alterabilidade, segurança, etc. Controle de tráfego aéreo / ferroviário: confiabilidade Controladores embutidos em eletrodomésticos (lavadoras de roupas / videocassetes): desempenho

20 06/05/2010 01 - Introdução 20 3. Engenharia de software (cont.) Engenharia de software Herda da engenharia o conceito de disciplina na produção de software Adota metodologias, com métodos que utilizam ferramentas automatizadas Métodos focalizam: Funções do sistema Objetos do sistema Eventos do funcionamento do sistema

21 06/05/2010 01 - Introdução 21 3.1. E. S. - Princípios Referem-se: Ao processo Ao produto final Descrevem propriedades gerais dos processos e produtos Processo correto => produto correto Produto almejado => escolha do processo (~ estratégia estrutura organizacional) Princípios são insuficientes. Há a necessidade de: Metodologias Métodos Ferramentas

22 06/05/2010 01 - Introdução 22 3.1. E. S. - Princípios (cont.) Formalidade Abstração Decomposição Generalização Flexibilização

23 06/05/2010 01 - Introdução 23 3.1. E. S. - Princípios (cont.) Formalidade Desenvolvimento de software = atividade criativa Tende a ser imprecisa (não estruturada) Enfoque formal: produtos mais confiáveis, com custo controlado e melhor desempenho Não deve restringir a criatividade Projeto como seqüência de passos precisos Passos segundo metodologia e algum método formal, informal ou semiformal Adequar formalidade à necessidade (ex.: barco p/ rio x oceano) Efeitos: manutenção, reutilização, portabilidade e entendimento do software

24 06/05/2010 01 - Introdução 24 3.1. E. S. - Princípios (cont.) Abstração Processo de identificação de aspectos importantes de um determinado fenômeno, ignorando-se os detalhes Podem existir diferentes abstrações, f(visões e objetivos diferentes) Ex.: telefone sem fio P/ o usuário: manual c/ efeitos do acionamento dos diversos botões P/ o técnico de manutenção: manual c/ informações de componentes Ex.: programas Abstrações das funcionalidades do sistema Ex.: linguagens de programação Foco do programador no problema, não na máquina

25 06/05/2010 01 - Introdução 25 3.1. E. S. - Princípios (cont.) Decomposição Para lidar com a complexidade: Subdividir atividades do processo Atribuí-las a especialistas de diferentes áreas Várias formas (ex.: tempo) Ex.: controle de qualidade do processo, controle de qualidade do produto, especificação do projeto, implementação e manutenção Decomposição = separação de preocupações Pode-se decompor o produto Permite o trabalho em paralelo Permite a reutilização de componentes por outros componentes ou sistemas

26 06/05/2010 01 - Introdução 26 3.1. E. S. - Princípios (cont.) Generalização Solução de um problema potencialmente pode ser reutilizada Determinado componente pode ser utilizado em diversos pontos do mesmo sistema, ao invés de várias soluções especializadas Solução pode demorar mais (mais custosa) Avaliar custo e eficiência para decidir Conseqüência principal: portabilidade

27 06/05/2010 01 - Introdução 27 3.1. E. S. - Princípios (cont.) Flexibilização Envolve processo e produto Produto se altera = f(entendimento de requisitos) Processo ocorre passo a passo, de forma incremental Princípio necessário ao processo para que o produto possa ser modificado com facilidade Processo deve ter flexibilidade para permitir A reutilização de componentes A portabilidade do produto para diferentes plataformas computacionais

28 06/05/2010 01 - Introdução 28 3.2. E. S. - Paradigmas Modelos de processo de desenvolvimento que proporcionam: Ao gerente: Controle do processo de desenvolvimento de sistemas de software. Ao desenvolvedor: Obtenção de base para produzir, de maneira eficiente e eficaz, software que satisfaça os requisitos preestabelecidos. Objetivo: Diminuir os problemas inerentes ao processo de desenvolvimento de software

29 06/05/2010 01 - Introdução 29 3.2. E. S. - Paradigmas (cont.) Existem vários. Escolha de acordo com: Natureza do projeto e do produto Métodos e ferramentas Controles e produtos intermediários desejados Três mais utilizados: Ciclo de vida clássico Evolutivo Espiral

30 06/05/2010 01 - Introdução 30 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico Método sistemático e seqüencial O resultado de uma fase é entrada de outra Fases se sucedem linearmente (=> “cascata”) Fases estruturadas como um conjunto de atividades que podem ser executadas por pessoas diferentes simultaneamente

31 06/05/2010 01 - Introdução 31 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Análise e Especificação de Requisitos Projeto Implementação e teste unitário Integração e teste do sistema Operação e manutenção Os cinco passos

32 06/05/201001 - Introdução32 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Decomposição = f(complexidade da aplicação) aplicações simples e bem entendidas menos formalidade aplicações maiores e mais complexas maior decomposição do processo melhor controle garantia dos resultados Exemplos - aplicações p/usuários não especialistas: fase p/projetar material especial de treinamento + treinamento p/entrada em operação especialistas: manuais técnicos / telefonemas / S.A.U.

33 06/05/201001 - Introdução33 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Análise e especificação de requisitos Via consultas aos usuários Identificar serviços, metas, restrições qualidade = f(funcionalidade, desempenho, facilidade de uso, portabilidade,...) Especificar quais os requisitos, não como alcançá-los Os requisitos especificados não devem restringir o desenvolvedor no projeto e implementação Resultado da fase: documento de especificação de requisitos, que deve ser analisado e confirmado pelos usuários usado pelos desenvolvedores p/obtenção do produto

34 06/05/201001 - Introdução34 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Análise e especificação de requisitos (cont.) Documento de especificação de requisitos instrumento de comunicação entre muitos indivíduos inteligível, preciso, completo, consistente e s/ambigüidades facilmente modificável = f(natureza evolutiva do software) conciliar interesses dos usuários e do desenvolvedor texto em linguagem natural versão preliminar do manual do usuário

35 06/05/201001 - Introdução35 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Análise e especificação de requisitos (cont.) Outro resultado da fase: plano de projeto usar princípios: abstração, decomposição e generalização Documento de especificação de requisitos funcionais: o que o produto deve fazer não funcionais: confiabilidade - disponibilidade, integridade, segurança acurácia dos resultados desempenho problemas de ihc restrições físicas e operacionais questões de portabilidade...

36 06/05/201001 - Introdução36 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Análise e especificação de requisitos (cont.) Documento de especificação de requisitos de desenvolvimento e manutenção procedimentos de controle de qualidade procedimentos de teste prioridades de funções mudanças prováveis etc.

37 06/05/201001 - Introdução37 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Projeto Representação das funções do sistema em forma que possa ser transformada em um ou mais programas executáveis Produto é decomposto em partes tratáveis: documento de especificação de projeto descrição da arquitetura do software o que cada parte deve fazer relação entre as partes

38 06/05/201001 - Introdução38 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Projeto (cont.) Projeto preliminar x detalhado Preliminar: estrutura de relações: usa, é_composto_de, herda_de,... Detalhado: especificação das interfaces Preliminar: decomposição lógica (alto nível) Detalhado: decomposição física do programa em unidades de programação Preliminar: principais estruturas de dados Detalhado: algoritmos para cada módulo

39 06/05/201001 - Introdução39 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Implementação e teste unitário Transformação do projeto em programas (ou unidades de programas) Resultado: Coleção de programas implementados e testados, conforme os padrões da organização, se houverem comentários nomenclatura número máximo de linhas por componente,... Teste unitário: verifica se cada unidade satisfaz suas especificações, normalmente conforme padrões planos e critérios de testes, critério de completude, gerenciamento de casos de teste, respeito a padrões,...

40 06/05/201001 - Introdução40 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Integração e teste do sistema Programas são integrados e testados como sistema Freqüentemente não é feito de uma só vez, mas progressivamente, em conjuntos cada vez maiores, a partir de pequenos subsistemas, até que o sistema inteiro seja construído

41 06/05/201001 - Introdução41 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Operação e manutenção Fase mais longa do ciclo de vida Entrega em dois estágios grupo selecionado de usuários (feedback / alterações, caso necessário) oficial Manutenção Atividade posterior à entrega do sistema aos usuários Corretiva: correção de erros remanescentes Adaptativa: adaptação a mudanças do ambiente Evolutiva: mudanças nos requisitos, adição de características e qualidades ao software

42 06/05/201001 - Introdução42 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Outras atividades Paradigma clássico dividido em fases Algumas atividades devem ser feitas antes do início do ciclo de vida durante todo o ciclo de vida Estudo de viabilidade Estágio crítico para o sucesso do projeto Envolve custos e benefícios Limitado por tempo (sob pressão) Poucos recursos investidos Identificar soluções alternativas, c/custos e datas de entrega Conteúdo: problema, soluções (c/benef. esp., recursos nec. e datas de entrega

43 06/05/201001 - Introdução43 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Outras atividades (cont.) Documentação Produtos ou resultados da maioria das fases são documentos Mudança de fases depende destes documentos Seguir padrões da organização p/sua elaboração Verificação Ocorre no teste unitário e do sistema Também em outras fases Processo de controle de qualidade via revisões e inspeções Descoberta e remoção de erros deve ocorrer o quanto antes (antes da entrega do produto)

44 06/05/201001 - Introdução44 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Outras atividades (cont.) Gerenciamento Meta: controlar o processo de desenvolvimento Adaptação do ciclo de vida ao processo: rigidez / profundidade variáveis Políticas: armazenagem, acesso e modificação de produtos / resultados intermediários; critérios de construção de versões diferentes e autorizações para acesso aos componentes de entrada e saída do banco de dados

45 06/05/201001 - Introdução45 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) Contribuições geradas Processo sujeito a disciplina, planejamento e gerenciamento Implementações postergadas até o entendimento completo dos objetivos Problemas Rigidez (o desenvolvimento não é linear, é iterativo!) Objetivo continua sendo a linearidade => Previsibilidade Facilidade de monitoramento Planejamento orientado para data de entrega única, que pode ser bastante longa (“congelamento?”)

46 06/05/201001 - Introdução46 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo Base Desenvolvimento e implementação de produto inicial Comentários e críticas dos usuários Refinamento através de múltiplas versões Desenvolvimento e validação paralelas (rápido feedback) Dois tipos Desenvolvimento exploratório Protótipo descartável

47 06/05/201001 - Introdução47 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Desenvolvimento exploratório Objetivo: trabalhar junto do usuário para descobrir os requisitos Incremental, até o produto final ser obtido Adoção: dificuldade (ou impossibilidade) de obter especificação detalhada de requisitos a priori Início Partes mais bem entendidas Evolução Novas características adicionadas (sugeridas pelo usuário)

48 06/05/201001 - Introdução48 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Descrição Atividades Paralelas Desenvolvimento Validação Versão inicial Versão intermediária Versão final Desenvolvimento exploratório

49 06/05/201001 - Introdução49 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Protótipo descartável Objetivo: melhor definir requisitos do usuário/sistema Fazer experimentos c/requisitos não bem entendidos Envolve projeto, implementação e teste (não formais / completos) Adoção Usuário define objetivos / não define E-P-S Desenvolvedor incerto sobre Eficiência de algoritmo Adaptação da aplicação a sistema operacional Forma de IHC

50 06/05/201001 - Introdução50 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Protótipo descartável (cont.) Possibilita criar modelo do software a construir Desenvolvedor pode perceber reações do usuário e obter sugestões para mudança / inovação Usuário pode relacionar protótipo com requisitos Operacionalização Versão preliminar da especificação de requisitos Construção do protótipo descartável Uso pelos usuários => ok’s, alterações, sobras, faltas, etc. Modificação do protótipo / uso pelos usuários Repetir ciclo enquanto novas informações valerem $ e tempo Especificação de requisitos definitiva = f(modificações) Desenvolvimento

51 06/05/201001 - Introdução51 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Protótipo descartável (cont.) Análise de requisitos Projeto Implementação Teste ProjetoImplementaçãoTeste Protótipo descartável

52 06/05/201001 - Introdução52 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Mais efetivo do que o ciclo de vida clássico Problemas ( perspectivas de engenharia e gerenciamento ) Processo não visível, rápido, documentação de cada versão não compensatória, mas necessária para medição de progresso Estruturação de produto pobre (corrompida pelas mudanças) => evolução difícil e custosa Protótipo a descartar construído artificialmente => qualidade e alterabilidade? / Pressão dos usuários p/ transformar protótipo em produto final s/reconstrução Escolhas inapropriadas (dos desenvolvedores) podem tornar-se parte integrante do sistema

53 06/05/201001 - Introdução53 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) Vantagem Abordagem leva a testes mais efetivos “Testar cada versão é mais fácil que o sistema todo ao final do desenvolvimento” Aplicabilidade prática Sistemas pequenos Mudanças = redesenvolvimento total

54 06/05/201001 - Introdução54 3.2. E. S. - Paradigmas (cont.) 3.2.3. O paradigma espiral (ou de BOEHM, 1991) Engloba as melhores características do ciclo de vida clássico e do paradigma evolutivo Inclui análise de risco “Riscos são circunstâncias adversas que podem atrapalhar o processo de desenvolvimento e a qualidade do produto a ser desenvolvido” Prevê a eliminação de problemas de alto risco Planejamento e projeto cuidadosos Tratamento de problemas triviais e não triviais de formas diferentes

55 06/05/201001 - Introdução55 3.2. E. S. - Paradigmas (cont.) 3.2.3. O paradigma espiral (cont.) Atividades organizadas como uma espiral de muitos ciclos (ciclo = fase de desenvolvimento) 1o.: estudo de viabilidade + operacionalidade (funcionalidades e características do sistema e do ambiente em que será desenvolvido) 2o.: definição dos requisitos 3o.: projeto... Não existem fases fixas Durante o planejamento decide-se como estruturar o processo de desenvolvimento em fases

56 06/05/201001 - Introdução56 3.2. E. S. - Paradigmas (cont.) 3.2.3. O paradigma espiral (cont.) Atividades principais Definição dos objetivos, alternativas e restrições Objetivos para a fase de desenvolvimento Ex.: desempenho e funcionalidade Alternativas para atingir os objetivos Restrições do processo e do produto Esboço de plano inicial Identificação de riscos de projeto Planejamento de estratégias alternativas = f(riscos) Ex.: desenvolvimento x compra de produto Análise de risco Análise cuidadosa + atitudes p/ cada risco, visando redução Ex.: requisitos c/problemas => desenvolvimento de protótipo

57 06/05/201001 - Introdução57 3.2. E. S. - Paradigmas (cont.) 3.2.3. O paradigma espiral (cont.) Atividades principais (cont.) Desenvolvimento e validação Avaliados os riscos, escolher um paradigma de desenvolvimento Ex.: Predominância de riscos de interface com o usuário => escolha do paradigma de prototipagem evolutiva Planejamento Revisar o projeto Decidir por percorrer ou não mais um ciclo na espiral Para o caso de decisão positiva Planejar a próxima fase do desenvolvimento do projeto Para o caso de decisão negativa (grandes riscos, p. ex.) Descontinuar o projeto

58 06/05/201001 - Introdução58 3.2. E. S. - Paradigmas (cont.) 3.2.3. O paradigma espiral (cont.) Diferença mais importante dos outros dois Análise de risco Entendimento e reação do desenvolvedor aos riscos a cada ciclo Mecanismo de redução de risco / manutenção do desenvolvimento sistemático = prototipagem Incorporação de componente iterativo => refletir o mundo mais realisticamente Exige especialização em análise de risco Riscos podem ser diminuídos / sanados através de informações que diminuam a incerteza do desenvto.

59 06/05/201001 - Introdução59 3.2. E. S. - Paradigmas (cont.) 3.2.3. O paradigma espiral (cont.) Análise de risco Protótipo 1 Operacionalidade do software Plano de requisitos Plano do ciclo de vida Análise de risco Protótipo 2 Análise de risco Protótipo operacional Protótipo 3 Simulações, modelos Validação dos requisitos Requisitos de software Plano de desenvolvimento Código Projeto detalhado Definição dos objetivos, alternativas e restrições Revisão Planejamento Integração e plano de teste Validação do projeto e verificação Projeto do software Teste unitário Teste de integração Implantação Teste de aceitação Desenvolvimento e validação

60 06/05/201001 - Introdução60 3.3. E. S. - Interações da E. S. com outras áreas Teoria da computação Desenvolvimento de modelos úteis para a E. S. Autômatos de estados finitos: especificação de sistemas operacionais, I. H. C. e processadores p/tais especificações Semântica formal Permite raciocinar sobre as propriedades dos sistemas Importância cresce com o tamanho e a complexidade dos sistemas Ex.: Sistema de controle de linhas de trens determina que deve existir, em qualquer parte dos trilhos de uma linha, no máximo, um trem => semântica formal permite a produção de prova de que o software sempre terá este comportamento

61 06/05/201001 - Introdução61 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Linguagens de programação Grande influência no alcance dos objetivos da E. S. Objetivos da E. S. influenciam o desenvolvimento das L. P. Inclusão de características modulares Compilação independente Separação entre especificação e implementação Desenvolvimento de “pacotes”: separação entre a interface e a implementação Bibliotecas de componentes para o desenvolvimento de sistemas independentes

62 06/05/201001 - Introdução62 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Compiladores Desenvolvimento modular Dois componentes Análise da linguagem Geração do código Decomposição permite a reutilização do segundo componente no desenvolvimento de outros compiladores Técnica usada na construção de compiladores da família GNU Atende a diferentes arquiteturas e L. P. de alto nível Escrita do menor número de linhas de código viável = f(reutilização), conceito da E. S.

63 06/05/201001 - Introdução63 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Sistemas operacionais Ferramentas p/o gerenciamento da configuração Manutenção / controle das relações entre componentes e versões do sistema de software Ex.: UNIX Vantagem sobre antecessores Organização como um conjunto de programas simples Podem ser combinados com grande flexibilidade Interface comum: arquivos texto

64 06/05/201001 - Introdução64 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Bancos de dados Linguagens de consulta permitem o uso dos dados sem se preocupar com sua representação interna B. D. pode ser alterado para melhorar o desempenho do sistema sem mudanças na aplicação Podem ser usados como componentes de sistemas: resolvem muitos problemas de acesso concorrente, por múltiplos usuários, a grandes volumes de dados

65 06/05/201001 - Introdução65 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Sistemas multiagentes Sistemas complexos Desenvolvimento envolve a decomposição do produto / separação de preocupações Ex.: Sistema para o processamento de textos pode ser decomposto em Análise sintática Análise semântica Análise pragmática Etc.

66 06/05/201001 - Introdução66 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Sistemas especialistas Sistemas modulares Dois componentes distintos Fatos conhecidos pelo sistema Regras para processar os fatos Ex.: Regra p/decidir determinada ação Conhecimento é dado pelo usuário Princípios gerais de como aplicar o conhecimento a qualquer problema são fornecidos pelo próprio sistema

67 06/05/201001 - Introdução67 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Ciência do gerenciamento Estimativas de projeto Cronograma Planejamento de recursos humanos Decomposição e atribuição de tarefas Acompanhamento de projetos Contratação e atribuição da tarefa certa à pessoa certa

68 06/05/201001 - Introdução68 3.3. E. S. - Interações da E. S. com outras áreas (cont.) Engenharia de sistemas Estuda sistemas complexos Hipótese: certas leis governam qualquer sistema complexo / composto de componentes com relações complexas Software é componente de um sistema maior => sujeito às técnicas da engenharia de sistemas

69 06/05/201001 - Introdução69 4. Considerações finais Paradigmas podem ser combinados Pontos fortes de cada um utilizados em um único projeto Paradigma espiral faz isso diretamente, combinando Prototipagem + elementos do ciclo de vida clássico Em paradigma evolutivo Qualquer paradigma pode servir como alicerce no qual outros se integram Processo sempre começa com determinação dos objetivos, alternativas e restrições (obtenção de requisitos preliminar) Depois disso, adotar qualquer caminho

70 06/05/201001 - Introdução70 4. Considerações finais (cont.) Ex.: Para sistema completamente especificado no início Ciclo de vida clássico Para sistema com requisitos não muito claros Protótipo para definir requisitos Usado como guia, desenvolvedor pode adotar passos do ciclo de vida clássico (projeto, implementação e teste) ou Alternativamente, protótipo pode evoluir para um sistema, retornando ao paradigma do ciclo de vida clássico para teste A natureza da aplicação é que vai determinar o paradigma a ser utilizado, e a combinação de paradigmas só tende a beneficiar o processo como um todo.

71 06/05/201001 - Introdução71 5. Exercícios 1)O gerente geral de uma cadeia de lojas de presentes acredita que o único objetivo da construção de um protótipo é entender os requisitos do usuário e que depois esse protótipo será descartado. Portanto, ele acha bobagem gastar tempo e recursos em algo que será desprezado mais tarde. Considerando essa relutância, resolva as seguintes questões: (a) Compare brevemente o protótipo descartável com o desenvolvimento evolutivo, de forma que o gerente compreenda o que um protótipo pode significar. (b) O gerente pensa em implementar o sistema, implantá-lo em uma loja e, depois, se obtiver sucesso, instalá-lo nas outras cinco lojas da cadeia. Diga qual método de prototipagem deve ser usado e justifique sua escolha.

72 06/05/201001 - Introdução72 5. Exercícios 2)Qual a importância do software? 3)O que é software legado? 4) Cite 3 (três) tipos de software. Pesquise e descreva cada um deles. 5) Quais as diferenças dos modelos cascata e espiral? 6) Quais as atividades do modelo tradicional? 7) Descreva o modelo de prototipação.

73 06/05/2010 01 - Introdução 73 Bibliografia CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à Engenharia de Software. Campinas: Editora da Unicamp, 2001.