Unidade VI Engenharia de Software

1. Unidade VI Engenharia de Software

2. HISTÓRICO • A Engenharia de Software (ES) surgiu em meados dos anos 70 numa tentativa de contornar a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software complexos. Um sistema de software complexo se caracteriza por um conjunto de componentes abstratos de software (estruturas de dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos, objetos ou agentes e interconectados entre si, compondo a arquitetura do software, que deverão ser executados em sistemas computacionais. •  Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantido suas qualidades. Além disto, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento.

3. MITOS E REALIDADES • MITOS ADMINISTRATIVOS • Mito: Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber? • Realidade: O manual de padrões pode muito bem existir, mas será que é usado? Os profissionais de software têm conhecimento de sua existência? Ele reflete a moderna prática de desenvolvimento de software? É completo? Em muitos casos a respostas a todas estas perguntas é não.

4. MITOS E REALIDADES . . . • MITOS DO CLIENTE • Mito: Uma declaração geral dos objetivos é suficiente para se começar a escrever programas – podemos preencher os detalhes mais tarde. • Realidade: Uma definição inicial ruim é a principal causa dos fracassos dos esforços de desenvolvimento de software. Uma descrição formal e detalhada do domínio da informação, função, desempenho, interfaces, restrições de projeto e critérios de validação é fundamental.

5. MITOS E REALIDADES . . . • MITOS DO CLIENTE . . . • Mito: Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível. • Realidade: É verdade que os requisitos de software se modificam, mas o impacto da mudança varia de acordo com o tempo em que ela é introduzida.

6. MITOS E REALIDADES . . . • MITOS DO PROFISSIONAL • Mito: Enquanto o programa não estiver funcionando não existirá maneira de avaliar sua qualidade. • Realidade: A revisão técnica formal pode ser aplicada desde o começo de um projeto.

7. MITOS E REALIDADES . . . • MITOS DO PROFISSIONAL . . . • Mito: A única coisa a ser entregue em um projeto bem sucedido é o programa funcionando. • Realidade: O programa funcionando é apenas uma parte de uma configuração de software. A documentação (plano, especificação de requisitos, estrutura de dados, especificação de teste, etc.) fornece um guia para facilitar a manutenção de software.

8. PARADIGMAS DA ENGENHARIA DE SOFTWARE • Não existe uma abordagem em particular que seja a melhor solução para o desenvolvimento de software, no entanto: • a combinação de métodos abrangentes para todas as fases de desenvolvimento; • a utilização de ferramentas para automatizar esses métodos; • a criação de blocos de construção mais consistentes; • a aplicação das melhores técnicas de qualidade; e, • a filosofia de coordenação, controle e administração; darão o encaminhamento das bases da engenharia de software.

9. 1980 1950 1990 1970 1960 2000 EVOLUÇÃO DO SOFTWARE • Os primeiros anos: • orientação batch • distribuição limitada • software customizado • A segunda era: • multiusuário • tempo real • bancos de dados • produto de software • software house • A terceira era: • sistemas distribuídos • “inteligência” embutida • hardware de baixo custo • impacto de consumo • microprocessadores e computadores pessoais • A quarta era: • sistemas de desk-top poderosos • tecnologias orientadas a objeto • sistemas especialistas • computação paralela

10. EVOLUÇÃO DO SOFTWARE . . . • OS PRIMEIROS ANOS: • software projetado sob medida para cada aplicação; • software com distribuição relativamente limitada; • o produto software estava em sua infância; • a maior parte dos softwares era desenvolvida e usada pela própria empresa; • quem escrevia e colocava em funcionamento, também tratava dos defeitos; e, • por causa do ambiente de software personalizado, o projeto era um processo implícito, realizado no cérebro de alguém, e a documentação muitas vezes não existia.

11. EVOLUÇÃO DO SOFTWARE . . . • A SEGUNDA ERA: • multiprogramação e sistemas multiusuários introduziram novos conceitos na interação homem-máquina; • as técnicas interativas abriram um novo mundo de aplicações e novos níveis de sofisticação de software e hardware; • sistemas de tempo real podiam coletar, analisar e transformar dados de múltiplas fontes; • os avanços da armazenagem online levaram à primeira geração de sistemas de gerenciamento de banco de dados; e, • surgimento das “software houses”.

12. EVOLUÇÃO DO SOFTWARE . . . • A TERCEIRA ERA: • os sistemas distribuídos - múltiplos computadores, cada um executando funções concorrentemente e comunicando-se um com o outro – aumentaram a complexidade dos sistemas baseados em computador; • as redes globais e locais, as comunicações digitais e a crescente demanda de acesso “instantâneo” a dados exigem muito dos desenvolvedores de software; • uso generalizado de microprocessadores e computadores pessoais; e, • produtos inteligentes: de automóveis a forno de microondas, de robôs industriais a diagnóstico de soro sangüíneo.

13. EVOLUÇÃO DO SOFTWARE . . . • A QUARTA ERA: • tecnologias orientadas a objetos; • técnicas de quarta geração; • sistemas especialistas; • inteligência artificial; e, • software de rede neural artificial abrindo possibilidades para o reconhecimento de padrões e para capacidades de processamento de informações semelhantes às humanas.

14. EVOLUÇÃO DO SOFTWARE . . . • A QUINTA ERA (?): • a sofisticação do software ultrapassou nossa capacidade de construir um software que extraia o potencial do hardware; • a capacidade de construir programas não acompanha o ritmo da demanda de novos programas; • a capacidade de manter os programas existentes é ameaçada por projetos ruins e recursos inadequados; e, • as práticas de engenharia de software se fortalecem.

15. PERSPECTIVA INDUSTRIAL • Por que demora tanto tempo para que os programas sejam concluídos? • Por que os custos são tão elevados? • Por que não descobrimos todos os erros antes de entregarmos o software aos nossos clientes? • Por que temos dificuldade em medir o progresso enquanto o software está sendo desenvolvido? • Essas e muitas outras perguntas são uma manifestação da preocupação relativa ao software e à maneira pela qual ele é desenvolvido, fortalecendo as práticas de engenharia de software.

16. VISÃO GERAL DA ENGENHARIA DE SOFTWARE • O processo de desenvolvimento de software contém três fases genéricas independente do paradigma de software escolhido. São elas: • definição; • o quê? • desenvolvimento; e, • como? • manutenção. • mudanças (o quê? e como?)

17. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • DEFINIÇÃO • A fase de definição focaliza o quê. Ou seja, durante a fase de definição, o desenvolvedor de software tenta identificar quais informações têm de ser processadas, qual função e desempenho são desejados, quais interfaces devem ser estabelecidas, quais restrições de projeto existem e quais critérios de validação são exigidos para se definir um sistema bem-sucedido. Esta fase apresenta as seguintes etapas: • análise de sistema; • planejamento do projeto de software; e, • análise de requisitos.

18. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • DEFINIÇÃO . . . • Análise de sistema • define o papel de cada elemento num sistema baseado em computador, atribuindo o papel que o software desempenhará. • Planejamento do projeto de software • uma vez definido o escopo do software, os riscos são analisados, as atividades e os recursos são definidos, os prazos são estabelecidos e os custos são estimados.

19. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • DEFINIÇÃO . . . • Análise de requisitos • definição detalhada do domínio da informação e da função do software.

20. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • DESENVOLVIMENTO • A fase de desenvolvimento focaliza o como. Ou seja, o desenvolvedor de software tenta definir como a estrutura de dados e a arquitetura de software têm de ser projetadas, como os detalhes procedimentais têm de ser implementados, como projeto será traduzido numa linguagem de programação e como os testes têm de ser realizados. Esta fase apresenta as seguintes etapas: • projeto de software; • codificação; e, • realização de testes de software.

21. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • DESENVOLVIMENTO . . . • Projeto de software • traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a arquitetura, o procedimento algorítmico e as características de interface. • Codificação • as representações do projeto devem ser convertidas numa linguagem de programação convencional ou numa linguagem não-procedimental usada no contexto do paradigma 4GT (técnicas de quarta geração).

22. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • DESENVOLVIMENTO . . . • Realização de testes do software • O software deve ser testado para que se possa descobrir defeitos de função, de lógica e de implementação.

23. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • MANUTENÇÃO • A fase de manutenção concentra-se nas mudanças que estão associadas à correção de erros, adaptações exigidas à medida que o ambiente do software evolui e ampliações produzidas por exigências variáveis do cliente. Esta fase apresenta as seguintes etapas: • correção; • adaptação; e, • melhoramento funcional.

24. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • MANUTENÇÃO • Correção • A manutenção corretiva muda o software para corrigir defeitos. • Adaptação • A manutenção adaptativa resulta em modificações no software a fim de acomodar mudanças em seu ambiente.

25. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • MANUTENÇÃO • Melhoramento funcional • O melhoramento funcional estende o software para além de suas exigências funcionais originais.

26. VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . . • As fases apresentadas são completadas por uma série de atividades de proteção, conforme a seguir: • revisões (qualidade); • documentação; e, • controle de mudanças.

27. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE • CICLO DE VIDA CLÁSSICO (modelo cascata) • Também conhecido como modelo cascata, o paradigma do ciclo de vida clássico requer uma abordagem sistemática, seqüencial ao desenvolvimento de software, conforme figura a seguir:

28. Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . Ciclo de vida clássico – modelo cascata

29. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • CICLO DE VIDA CLÁSSICO (modelo cascata) . . . • engenharia de sistemas; • análise de requisitos de software; • projeto; • codificação; • teste; e, • manutenção.

30. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • CICLO DE VIDA CLÁSSICO (modelo cascata) . . . • Engenharia de sistemas • Coletar os requisitos em nível de sistema, com uma pequena quantidade de projeto e análise de alto nível. • Análise de requisitos de software • Compreender o domínio da informação para o software, bem como a função, desempenho e interface exigidos. Os requisitos, tanto para o sistema como para o software, são documentados e revistos com o cliente.

31. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • CICLO DE VIDA CLÁSSICO (modelo cascata) . . . • Projeto • Gerar os quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface. • O projeto é documentado e torna-se parte da configuração do software. • Codificação • Traduzir o projeto numa forma legível por máquina.

32. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • CICLO DE VIDA CLÁSSICO (modelo cascata) . . . • Testes • Realizar testes para descobrir erros técnicos e funcionais, buscando fazer com que a entrada definida produza resultados reais compatíveis com os resultados exigidos. • Manutenção • Reaplicar cada uma das etapas precedentes do ciclo de vida a um programa existente, sempre que ocorrerem mudanças (correções, adaptações ou melhoramentos).

33. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • CICLO DE VIDA CLÁSSICO (modelo cascata) . . . • O modelo cascata é o paradigma mais antigo e o mais amplamente usado na engenharia de software. No entanto, os seguintes aspectos devem ser considerados: • raramente seguem o fluxo seqüencial que o modelo propõe; • necessidade de iterações trazem problemas para aplicação do paradigma; • dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos; • erros descobertos tardiamente, podem ser desastrosos ao projeto.

34. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • PROTOTIPAÇÃO • Processo que capacita o desenvolvedor a criar um modelo do software que será implementado. • Pode assumir uma das três formas: • protótipo em papel ou modelo baseado em PC; • protótipo de trabalho; e, • programa existente.

35. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • PROTOTIPAÇÃO . . . • Protótipo em papel ou modelo baseado em PC • Retrata a interação homem-máquina de uma forma que capacita o usuário a entender quanta interação ocorrerá. • Protótipo de trabalho • Implementa algum subconjunto da função exigida do software desejado. • Programa existente • Executa parte ou toda a função desejada, mas tem outras características que serão melhoradas em um novo esforço de desenvolvimento.

36. Início Fim Coleta e refinamento dos requisitos Engenharia do produto Projeto rápido Construção do protótipo Refinamento do protótipo Avaliação do protótipo pelo cliente PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • PROTOTIPAÇÃO . . . Seqüência de eventos do paradigma de prototipação

37. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • PROTOTIPAÇÃO . . . • Ainda que possam ocorrer problemas, a prototipação é um paradigma eficiente da engenharia de software. A chave é definir-se as regras do jogo logo no começo; ou seja, o cliente e o desenvolvedor devem concordar que o protótipo seja construído para servir como um mecanismo de definição dos requisitos. Ele depois será descartado (pelo menos em parte) e o software real será projetado, levando-se em conta a qualidade e a manutenção.

38. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • MODELO ESPIRAL • Desenvolvido para abranger as melhores características tanto do ciclo clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento – a análise de riscos – que falta a esses paradigmas. Coleta inicial dos requisitos e planejamento do projeto Análise dos riscos baseada nos requisitos iniciais Análise dos riscos Planejamento Análise dos riscos baseada na reação do cliente Planejamento baseado nos comentários do cliente Decisão de prosseguir / não prosseguir Na direção de um sistema concluído Avaliação do cliente Protótipo do software inicial Protótipo no nível seguinte Avaliação do cliente Engenharia Sistema construído pela engenharia

39. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • MODELO ESPIRAL . . . • O modelo representado pela espiral define quatro importantes atividades representadas pelos quatro quadrantes da figura: • planejamento; • análise dos riscos; • engenharia; e, • avaliação do cliente.

40. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • MODELO ESPIRAL . . . • Planejamento • Mistura análise com projeto. Nesta fase determina-se os objetivos, restrições e verifica-se alternativas de projeto. • Análise de risco • Nesta fase analisa-se as alternativas e verifica-se os riscos. Decide-se seguir o projeto na mesma linha ou começar de novo. • Engenharia • Nesta fase desenvolve-se o protótipo. A cada nova fase de engenharia o produto aproxima-se mais do produto final. Esta fase pode incluir todo o ciclo de vida clássico. • Avaliação do cliente • O cliente avalia o produto. Os desenvolvedores verificam a necessidade de novas fases.

41. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • MODELO ESPIRAL . . . • O cliente avalia o trabalho de engenharia (o quadrante de avaliação do cliente) e apresenta sugestões para modificações. • Na maioria dos casos, o fluxo ocorre ao redor de uma trajetória espiral contínua, com cada trajetória movimentando os desenvolvedores para fora na direção de um modelo mais completo do sistema. • O paradigma de modelo espiral para a engenharia de software é atualmente a abordagem mais apropriada para o desenvolvimento de sistemas e de software em grande escala.

42. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO • O termo Técnicas de Quarta Geração abrange um amplo conjunto de ferramentas de software que têm uma coisa em comum: cada uma delas possibilita que o desenvolvedor especifique alguma característica do software em alto nível. A ferramenta gera então, automaticamente, o código-fonte, tendo como base a especificação do desenvolvedor. O paradigma da técnica de quarta geração concentra-se na capacidade de se especificar software a uma máquina em um nível que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma função significativa.

43. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO • O usuário realiza a especificação em uma linguagem de 4G, em alto nível. • A codificação propriamente dita é realizada por uma linguagem de 4G. • Uma ferramenta de 4G é responsável por transformar automaticamente a especificação em código executável. • Quanto mais alto o nível da especificação (ou seja, mais próxima da linguagem natural), mais rapidamente é gerado o produto final.

44. O ambiente de desenvolvimento de software que sustenta o ciclo de vida de quarta geração inclui: linguagens não procedimentais para consulta de banco de dados; ferramentas para geração de relatórios; ferramentas para manipulação de dados; ferramentas para definir interação e telas; ferramentas para geração de códigos; capacidade gráfica de alto nível; e, capacidade de planilhas eletrônicas. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO . . .

45. Coleta de Requisitos Estratégia de “Projeto” Implementação Usando 4G Teste PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . Ciclo de vida a partir das Técnicas de Quarta Geração

46. Coleta de requisitos O cliente descreve os requisitos os quais são traduzidos para um protótipo operacional. Problemas: o cliente pode estar inseguro quanto aos requisitos; o cliente pode ser incapaz de especificar as informações de modo que uma ferramenta de 4G possa entender; e, as linguagens de 4G atuais não são sofisticadas suficientemente para acomodar a verdadeira linguagem natural. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO . . .

47. Estratégia de projeto Nesta fase normalmente é projetado como o software será feito, organizado, estruturado, etc.; No entanto, para pequenas aplicações é possível mover-se da fase um direto para a fase três, pulando a fase de projeto. Utilizando linguagens de quarta geração, às vezes esta fase não é necessária; e, Já para grandes projetos é sempre necessário desenvolver uma estratégia de projeto. Caso contrário ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade, manutenção ruim, má aceitação do cliente, etc). PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO . . .

48. Implementação usando linguagem de 4G Os resultados desejados são representados de modo que haja geração automática de código. Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4G. 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. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO . . .

49. Considerações Favoráveis Os defensores das linguagens de 4G argumentam que por meio delas se obtém uma redução dramática no tempo de desenvolvimento do software (aumento de produtividade). Desfavoráveis As linguagens de 4G atuais não são mais fáceis de usar do que as linguagens de programação. O código fonte produzido é ineficiente. A manutenção de sistemas usando técnicas de 4G ainda é questionável. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . • TÉCNICAS DE QUARTA GERAÇÃO . . .

50. Unidade VI Engenharia de Software # F I M #