Processos de software Leitura: Cap3 Sommerville / Cap1: Pressman - Ariadne

Transcrição

1 Processos de software Leitura: Cap3 Sommerville / Cap1: Pressman - Ariadne Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 1

2 Processos de software Atividades para especificar, projetar, implementar e testar sistemas de software Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 2

3 Objetivos Compreender o conceito de um processo de software Descrever vários modelos de processo diferentes e quando eles podem ser usados Descrever modelos de processo para a engenharia de requisitos de software, desenvolvimento de software, teste e evolução. Conhecer a tecnologia de CASE para apoio ao processo de software. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 3

4 Processo de software Um processo de software é um método para desenvolver ou produzir software. A pesquisa em processo de software lida com métodos e tecnologias estimativas, suporte e melhoria das atividades de desenvolvimento de software. Define quem faz o que, quando e como. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 4

5 Modelagem Modelagem é uma técnica de engenharia aprovada e bem aceita modelos de arquitetura de casas e de grandes prédios modelos matemáticos a fim de analisar os efeitos de ventos e tremores de terra --> causas O que é um MODELO? Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 5

6 Modelos Um modelo é uma simplificação da realidade. Planos de detalhes, podem ser estruturais (organização do sistema) ou comportamentais (dinâmica do sistema) Modelos são construídos para permitir um melhor entendimento sobre o sistema que está sendo construído. especificar a estrutura e comportamento guia para construção do sistema documentam as decisões tomadas Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 6

7 Modelos Modelos de sistemas complexos são importantes porque não temos capacidade de compreendê-los inteiramente Os melhores modelos estão relacionados à realidade (modelos simplificam a realidade) Nenhum modelo único é suficiente. Conjunto de modelos independentes Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 7

8 Modelagem na Engenharia Civil Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 8

9 Objetivos da Modelagem Auxiliar no processo de produção produtos de alta qualidade, produzidos mais rapidamente e a um custo cada vez menor. Atributos: abstração, visibilidade, especificação, construção, confiabilidade, manutenibilidade, segurança, documentação. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 9

10 Objetivos da Modelagem Possibilitam: Ao gerente: controlar o processo de desenvolvimento de sistemas de software. Ao desenvolvedor: obter a base para produzir, de maneira eficiente, software que satisfaça os requisitos pré-estabelecidos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 10

11 Objetivos da Modelagem Abstração Melhor entendimento e maior compreensão Visualização Visualização antecipada antes da implementação Visões complementares do software Especificação Descrição precisa do que deve ser feito Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 11

12 Objetivos da Modelagem Construção Geração automática com ferramentas baseadas em modelos Documentação Comunicação entre equipes na diferentes fases do ciclo de vida Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 12

13 Modelo X Processo Um modelo é algo teórico, um conjunto de possíveis ações. O processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos e métricas para se avaliar como elas estão sendo realizadas Modelo + Planejamento = Processo Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 13

14 Modelos de processo de software Um conjunto de atividades fundamentais exigida para desenvolver um sistema de software Especificação. Projeto e implementação. Validação. Evolução. Um modelo de processo de software é uma representação abstrata de um processo. Representa uma descrição de um processo a partir de uma perspectiva particular. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 14

15 As exigências que criam processo Estudo de viabilidade Relatório de viabilidade Levantamento e análise de requisitos Modelos de sistemas Especificação de requisitos Validação de requisitos Requisitos do usuário e do sistema Documentação de requisitos Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 15

16 Modelos de processo de software Processo de Engenharia de Requisitos Estudo de viabilidade» Econômica relação custo/benefício;» Técnica tecnologia e capacitação;» Jurídica aspectos legais. Levantamento e análise de requisitos» Entrevista, observação, reuniões Especificação de requisitos» Documento contendo os requisitos do usuário e do sistema funcionais e não-funcionais Validação de requisitos» Avaliação do documento de requisitos pertinência, consistência e integralidade. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 16

17 Modelos de processo de software Uma representação simplificada de um processo de software, apresentada de uma perspectiva específica Exemplos de modelos de processo são: Workflow - sucessão de atividades Fluxo de Dados - fluxo de informação Papel/ação representa os papéis das pessoas e as atividades pelas quais elas são responsáveis. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 17

18 Modelos de processo de software - paradigmas Uma estratégia de desenvolvimento que englobe processos, métodos e ferramentas, e as fases de desenvolvimento... Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 18

19 Modelos de processo de 1. Modelo Seqüencial encial (ciclo de vida clássico) 2. Modelo de Prototipação 3. Modelos Evolutivos 1. Modelo Incremental e Espiral 4. Técnicas de 4a geração 5. Modelo de Métodos M Formais 6. Orientado a reuso 7. etc software - paradigmas Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 19

20 Modelos de processo de software - paradigmas O modelo de cascata Separa em fases distintas as atividades de especificação, projeto, implementação, testes e manutenção. Desenvolvimento evolucionário (prototipação) Especificação e desenvolvimento são intercalados Modelo espiral O desenvolvimento do sistema evolui a partir de um esboço inicial, em direção ao sistema final desenvolvido. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 20

21 Modelos de processo de software - paradigmas Desenvolvimento de sistemas formal Um modelo de sistema matemático é transformado formalmente em uma implementação Desenvolvimento orientado a reuso O sistema é composto de componentes existentes Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 21

22 Modelos cascata Método sistemático e seqüencial O resultado de uma fase se constitui na entrada da outra. Cada fase é estruturada como um conjunto de atividades que podem ser executadas por pessoas diferentes, simultaneamente. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 22

23 Modelo de cascata Definição de requisitos Análise / projeto de sistema e de software Implementação e teste Integração e teste Operação e manutenção Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 23

24 Ciclo de vida Fase de definição Análise e Especificação Estudo de Viabilidade Estimativas Planejamento Fase de desenvolvimento Projeto Implementação e integração Verificação e Validação Fase de operação Atividades que mantém o sistema funcionando Manutenção atividades executadas depois que o produto é entregue aos usuários. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 24

25 Fase de definição Deve-se analisar os requisitos, recursos e restrições para: apresentar soluções, estudar a viabilidade, planejar e gerenciar o desenvolvimento a partir de estimativas e análise de riscos que se utilizam de métricas Definir quais os requisitos do produto de software, sem especificar como esses requisitos serão obtidos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 25

26 Fase de definição Esta fase encerra-se com o contrato de desenvolvimento.»analisado e confirmado pelo usuário para verificar se ele satisfaz todas as suas expectativas.»deve ser usado pelos desenvolvedores de software para obter um produto que satisfaça os requisitos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 26

27 Fase de desenvolvimento Projeto de Software É definida a solução do problema: Decomposição do produto ( sub-sistema, componentes etc). Representação das funções do sistema em uma forma que possa ser transformada em um ou mais programas executáveis. Definição de como o produto deve ser implementado. Dividido em: Projeto de alto nível decomposição lógica Projeto detalhado decomposição física. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 27

28 Fase de desenvolvimento Projeto de Software Projeto conceitual, projeto da interface de usuário, projeto da arquitetura de software, projeto de algoritmos e estruturas e dados. Resultado documentação de especificação de projeto Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 28

29 Fase de desenvolvimento Implementação O projeto é transformado em um programa, ou unidades de programa. Teste unitário cada unidade satisfaz suas especificações ( plano e casos de teste préestabelecidos) Resultado coleção de programas implementados e testados. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 29

30 Fase de desenvolvimento Integração Programas ou unidades de programas são integrados e testados como sistema. Integração incremental programas ou unidades são integradas à medida em que forem sendo desenvolvidos. Resultado produto pronto para ser entregue ao cliente. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 30

31 Fase de Operação / Manutenção Operação Instalação e configuração Utilização inicialmente operado por um grupo de usuário Manutenção Corretiva: correção de erros remanescentes Adaptativa: adaptação dos produtos às mudanças» novas versões» novas situações de operação hardware, sistemas operacionais Evolutiva: alteração dos requisitos e manutenção da qualidade. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 31

32 Atividades complementares Estudo de viabilidade Analisar o problema em nível global Identificar soluções alternativas (custos / benefícios) Simulação do futuro processo de desenvolvimento Resultado documentação contendo: Definição do problema Soluções alternativas, com os benefícios esperados Fontes necessárias, custos e datas de entrega para cada solução proposta. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 32

33 Atividades complementares Gerenciamento Adaptação do ciclo de vida ao processo Definição de políticas:» Como produtos ou resultados intermediários vão ser armazenados acessados e modificados.» Como versões diferentes de sistemas são construídos.» Quais autorizações são necessárias para acessar os componentes de entrada/saída do banco de dados do sistema.» Recursos que afetam o processo de produção, particularmente com os recursos humanos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 33

34 Contribuições e problemas do ciclo de vida clássico Contribuições Processo de desenvolvimento de software deve ser sujeito à disciplina, planejamento e gerenciamento. A implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos. Deve ser utilizado quando os requisitos estão bem claros no inicio do desenvolvimento. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 34

35 Contribuições e problemas do ciclo de vida clássico Problema Rigidez Qualquer desvio é desencorajado Todo o planejamento é orientado para a entrega do produto de software em uma data única. Processo de desenvolvimento pode ser longo e a aplicação pode ser entregue quando as necessidades do usuário já tiverem sido alteradas. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 35

36 Contribuições e problemas do ciclo de vida clássico Problema (cont.) Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe. Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural. O cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 36

37 Ciclo de Vida Clássico/O Modelo Cascata ETAPA PERGUNTAS-CHAVES CRITÉRIOS DE SAÍDA Definição do problema Estudo de viabilidade Análise Qual é o problema Há uma solução viável O que terá de ser feito para resolver o problema? Declaração da delimitação e objetivos. Análise geral de custo/benefício Alcance e objetivos do sistema. Modelo lógico do sistema: Diagrama de Fluxo de Dados; Diagrama de Entidade e Relacionamento Diagrama de Transição de Estado; Dicionário de Dados; Especificação de Processos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 37

38 Ciclo de Vida Clássico/O Modelo Cascata ETAPA PERGUNTAS-CHAVES CRITÉRIOS DE SAÍDA Projeto Como o problema deve ser Soluções Alternativas resolvido? Especificação de hard/soft; Como o sistema deve ser Plano de implementação; implementado? Plano de teste preliminares; Procedimento de segurança; Procedimento de auditoria. Implementação Faça Programas; Plano de testes; Procedimento de segurança; Procedimento de auditoria. Teste Verificar o sistema Testes do geral do sistema. Manutenção Modificar o sistema conforme necessidade. Apoio continuado. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 38

39 Modelo Evolucionário Abordagem baseada na idéia de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões. As atividade de desenvolvimento e validação são desempenhadas paralelamente, com um rápido feedback entre elas. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 39

40 Modelo Evolucionário Tipos: Desenvolvimento exploratório Protótipo descartável Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 40

41 Modelo evolucionário (Desenvolvimento exploratório ) Trabalhar junto com o cliente, a fim de explorar seus requisitos e entregar um sistema final. O desenvolvimento se inicia com as partes do sistema que são mais bem compreendidas. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 41

42 Modelo evolucionário (Desenvolvimento exploratório ) O sistema evolui com o acréscimo de novas características à medida que elas são propostas pelo cliente. Importante quando é difícil, ou mesmo impossível, estabelecer uma especificação detalhada dos requisitos do sistema a priori. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 42

43 Modelo evolucionário (Desenvolvimento exploratório ) Atividades concorrentes Especificação Versão inicial Descrição do esboço Desenvolvimento Versão intermediárias Validação Versão final Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 43

44 Modelo evolucionário (Protótipo descartável) Obter os requisitos do cliente e, a partir disso, desenvolver uma melhor definição de requisitos para o sistema. Concentra em fazer experimentos com partes dos requisitos que estejam mal entendidos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 44

45 Modelo evolucionário (Protótipo descartável) Usuário define uma série de objetos para o produto de software, mas não consegue identificar detalhes de entrada, processamento ou requisitos de saída. O desenvolvedor está incerto sobre a eficiência de um algoritmo, a adaptação de um sistema operacional ou ainda sobre a forma da interação homem-máquina. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 45

46 Modelo evolucionário (prototipação) Conversar com o Cliente Construir/Revisar protótipo Revisão e Teste pelo Cliente Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 46

47 Fim Modelo evolucionário (prototipação) Início Engenharia do produto Coleta e refinamento dos requisitos Projeto rápido Refinamento do protótipo Avaliação do protótipo pelo cliente Construção do protótipo Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 47

48 Atividades da Prototipação COLETA DOS REQUISITOS: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais PROJETO RÁPIDO: R representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 48

49 Atividades da Prototipação CONSTRUÇÃO PROTÓTIPO: TIPO: Implementação do projeto rápido serve como o primeiro sistema - recomendado que se jogue fora futuramente AVALIAÇÃO DO PROTÓTIPO: TIPO: Cliente e desenvolvedor avaliam o protótipo Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 49

50 Atividades da Prototipação REFINAMENTO DOS REQUISITOS: Cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iteração que pode conduzir a atividade 1 até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 50

51 Atividades da Prototipação CONSTRUÇÃO PRODUTO: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 51

52 Contribuições e problemas do modelo evolutivo Contribuições Sistemas pequenos Útil quando os requisitos estão obscuros Especificação é construída gradativamente Possibilitam um rápido desenvolvimento da aplicação Testes podem ser mais efetivos. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 52

53 Contribuições e problemas do modelo evolutivo Problema O processo não é visível Os sistemas são freqüentemente malestruturados e mal-documentados Pode exigir ferramentas e técnicas especiais. Processo não é claro, dificuldade de planejamento e gerenciamento Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 53

54 Contribuições e problemas do modelo evolutivo Problema (cont) Cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo» Não aceita bem a idéia que a versão final do software vai ser construída e força a utilização do protótipo como produto final. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 54

55 Contribuições e problemas do modelo evolutivo Problema (cont) Desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo.» Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 55

56 Modelo espiral (Boehm) Desenvolvido pala englobar as melhores características do ciclo de vida clássico e do paradigma evolutivo. São avaliados riscos explicitamente e são solucionados ao longo do processo. Processo é representado como uma espiral em lugar de ser representado como uma seqüência de atividades Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 56

57 Modelo espiral (Boehm) Cada loop na espiral representa uma fase do processo de software. Não existem fases fixas. Engloba as melhores características do ciclo de vida Clássico como o da Prototipação, adicionando um novo elemento: a ANÁLISE DOS RISCOS Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 57

58 Modelo espiral (Boehm) Segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 58

59 Modelo espiral Coleta inicial dos requisitos e planejamento do projeto Planejamento baseado nos comentários do cliente Avaliação do cliente Planejamento Análise de risco Para cada risco do projeto identificado em P é levada a cabo uma análise detalhada. Decisão de prosseguir/não prosseguir Na direção de um sistema concluído Protótipo de software inicial Avaliação do cliente Engenharia Sistema construído pela engenharia Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 59

60 Modelo espirais (Funcionamento) À medida que a volta na espiral acontece, versões mais completas do software vão sendo progressivamente construída. Durante a primeira volta, são definidos objetivos, alternativas e restrições. Se a análise de risco indicar que há incerteza nos requisitos, a prototipação pode ser usada para auxiliar o desenvolvedor e o usuário. O usuário avalia o produto e faz sugestões de modificações. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 60

61 Modelo espirais (Planejamento ) São identificados objetivos específicos, tais como desempenho e funcionalidade. São determinadas alternativas para atingir estes objetivos. São identificadas restrições do processo e do produto e é elaborado um relatório de gestão detalhado. Estratégias alternativas, dependendo dos riscos detectados, podem ser planejados. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 61

62 Modelo espirais (Ánalise de risco ) Avaliação do cliente O projeto é revisado e a próxima fase da espiral é planejada. Toma-se decisão sobre avançar para mais uma volta na espiral. Se for para avançar são desenhados os planos para a próxima fase do projeto. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 62

63 Modelo espirais (Ánalise de risco ) Escolher um modelo de desenvolvimento para o sistema Riscos significativos na interface com o utilizador desenvolvimento evolutivo. Riscos de segurança Desenvolvimento Formal Riscos na integração dos sub-sistemas Modelo Cascata Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 63

64 Técnicas de 4 a Geração Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam que: o sistema seja especificado em uma linguagem de alto níveln e o código fonte seja gerado automaticamente a partir dessas especificações Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 64

65 Técnicas de 4 a Geração O ambiente de desenvolvimento inclui as ferramentas: linguagens não procedimentais para consulta de banco de dados geração de relatórios manipulação de dados interação e definição de telas geração de códigos capacidade gráfica de alto nível capacidade de planilhas eletrônicas Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 65

66 Técnicas de 4 a Geração Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 66

67 Técnicas de 4 a Geração OBTENÇÃO DOS REQUISITOS: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional O cliente pode estar inseguro quanto aos requisitos O cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir As 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 67

68 Técnicas de 4 a Geração ESTRATÉGIA DE "PROJETO": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação Para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade, manutenibilidade ruim, má aceitação do cliente) Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 68

69 Técnicas de 4 a Geração IMPLEMENTAÇÃO USANDO 4GL: os resultados desejados são representados de modo que haja geração automática de código. TESTE: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 69

70 Combinando Paradigmas obtenção preliminar dos requisitos análise dos requisitos prototipação técnicas 4G modelo espiral projeto prototipação enésima interação técnicas 4G codificação técnicas 4G modelo espiral: enésima interação testes Sistema completo manutenção Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 70

71 Métodos Ágeis Métodos Ágeis - Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor. Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 71

72 Métodos Ágeis SCRUM - é um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita freqüência. Crystal/Clear ( Cockburn ) - é permitir que cada organização implemente as atividades que lhe parecem adequadas, fornecendo um mínimo de suporte útil do ponto de vista de comunicação e documentos Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 72

73 Métodos Ágeis Dynamic Systems Development Method - DSDM - (Método Dinâmico de Desenvolvimento de Sistemas) Progenitor do XP. Suporta mudanças nos requisitos durante o ciclo de vida Extreme Programming - é uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança [Kent Beck ] Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 73

74 Métodos Ágeis Feature Driven Development FDD (Desenvolvimento orientado a funcionalidades) Suporta desenvolvimento ágil com rápidas adaptações às mudanças de requisitos e necessidades do mercado. Foco nas fases de desenho e construção. Adaptive Software Development - ASD (Desenvolvimento Adaptável de Software) Sistemas grandes e complexos. Iterativo e incremental. Cliente sempre presente Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 74

75 Prática Considerando os sistemas em funcionamento da sua empresa, responda: Qual o modelo adotado; Qual o paradigma que você escolheria? Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / Ian Sommerville 2000 Slide 75