ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

Transcrição

1 ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software

2 SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração associados. Documentação do sistema (modelos e projetos). Documentação do usuário (manuais de ajuda). Via de atualização (ex.: site). Código fonte. Arquivos de configuração. Regras de negócio.

3 PRODUTO DE SOFTWARE Software vendido ao a um cliente. Produtos genéricos: desenvolvido por uma organização e vendido a qualquer cliente que queira/possa adquiri-lo. Produtos sob encomenda: desenvolvido sob demanda de encomenda para um cliente específico.

4 ENGENHARIA DE SOFTWARE - ES Disciplina de engenharia relacionada com todos os aspectos da produção de um software, desde os estágios iniciais de especificação do sistema até a sua manutenção, depois que o mesmo entra em operação.

5 CIÊNCIA DA COMPUTAÇÃO X ENGENHARIA DE SOFTWARE Ciência da Computação: teorias e métodos que constituem a base de computadores e sistemas de software (modelos matemáticos, algoritmos, formalização lógica, etc.). Engenharia de Software: problemas práticos da produção de software (produção de software com maior desempenho e produtividade). Engenharia da Computação: desenvolvimento de equipamentos e dispositivos computacionais, mais focada em hardware (aplicações industriais, redes, sistemas embarcados, etc).

6 SISTEMAS DE SOFTWARE Um sistema é o conjunto intencional de componentes inter-relacionados que funcionam juntos para atingir certo objetivo. Sistema de software: sistema computacional (envolve hardware e software).

7 SISTEMAS DE SOFTWARE Técnicos Incluem componentes de hardware e software, mas não incluem operadores e processos operacionais. São usados para algum propósito, mas o conhecimento deste propósito não é parte do sistema. Ex.: MS Word. Sociotécnicos Incluem um (ou mais) sistemas técnicos, mas, decisivamente, incluem operadores (pessoas) e processos operacionais definidos. São instalados dentro de uma organização, projetados para ajudá-la a atingir um objetivo maior.

8 SISTEMAS SOCIOTÉCNICOS Fatores humanos e políticas organizacionais têm um efeito significativo sobre a operação de sistemas sociotécnicos. Caracterizado por: Propriedades emergentes. Não é determinístico. Objetivos organizacionais.

9 SISTEMAS LEGADOS Sistemas sociotécnicos desenvolvidos no passado, frequentemente utilizando tecnologia obsoleta, porém, ainda fornecem serviços essenciais. Processos operacionais legados : mudanças envolvem alterações em diversos componentes; criticidade e custo de modernização. São sistemas críticos de negócios. Mantidos por que é arriscado substituí-los. Ex.: Sistemas bancários, sistemas de controle aéreo, etc.

10 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE No Silver Bullet Essense and Accidents of Software Engineering (Frederick P. Brooks, 1987). Analogia de softwares com a lobisomens. Ente querido = lobisomem. Projeto de software = monstro criado pela tortura de prazos perdidos, orçamentos estourados, produto final imperfeito. Para os lobisomens há uma bala de prata de capaz de matar todos. Para os softwares não há uma solução para todos os problemas.

11 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE Dificuldades em se construir um software: Essenciais: pertinentes à natureza do software, ao modelo conceitual para o sistema (conjunto de dados, relação entre esses itens de dados e a chamadas de funções). Acidentais: dificuldades que se tem na produção do software, mas que não são inerentes às regras de negócio implementadas pelo software (linguagem, tecnologias, etc). Conquistas passadas resolveram as dificuldades acidentais, não essenciais.

12 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE PRINCIPAIS PROBLEMAS Complexidade: entidades de software são mais complexas pelo seu tamanho que qualquer outra construção humana, pois suas partes são desiguais. Software tem um grande número de estados, tornando sua descrição, concepção e teste muito difíceis.

13 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE PRINCIPAIS PROBLEMAS Conformidade: dificuldade em se manter padrões desenvolvidos por pessoas diferentes, em tempos diferentes. Em versões prévias, por exemplo, esta complexidade não pode ser simplificada redesenhando o software sozinho.

14 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE PRINCIPAIS PROBLEMAS Alterabilidade: mudanças constantes são promovidas no software, inclusive após ser desenvolvido (o que é mais complexo). Sistemas incorporam funcionalidades e estas são, na maioria das vezes, os pivôs das mudanças.

15 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE PRINCIPAIS PROBLEMAS Invisibilidade: software possui um aspecto abstrato, imaterial, não pode ser representado por uma baseado em combinações geométricas. Para se construir um software é necessário um conjunto de diagramas (que devem representar fluxo de dados, padrões de dependência, sequência temporal, etc.)

16 DIFICULDADES ESSENCIAIS E ACIDENTAIS DA ENGENHARIA DE SOFTWARE SOLUÇÕES PROMISSORAS Compra x Construir: concepção do software não construindo-o completamente. Refinamento de requisitos e prototipagem rápida: precisão no levantamento de dados é essencial. É necessária uma interação exaustiva entre cliente e desenvolvedor. Grandes projetistas: gerenciamento de pessoal. Qualificação de grandes projetistas.

17 PROCESSO Conjunto de manipulações para obter um resultado. Diretrizes utilizadas para se fazer alguma coisa.

18 PROCESSO DE SOFTWARE Conjunto de atividades relacionadas que levam à produção de um produto de software. Essas atividades podem envolver o desenvolvimento do software a partir do zero em uma linguagem padrão, como C ou Java.

19 PROCESSO DE SOFTWARE ATIVIDADES FUNDAMENTAIS Especificação de software: funcionalidade do software e as restrições a seu funcionamento devem ser definidas. Projeto e implementação do software: produção do software atendendo às especificações. Validação do software: o software deve ser validado para garantir que atenda as solicitações do cliente. Evolução do software: o software deve evoluir para atender às necessidades de mudança dos clientes.

20 ATIVIDADES DO PROCESSO DE SOFTWARE: ESPECIFICAÇÃO DE SOFTWARE Processo de compreensão e definição dos serviços requisitados (requisitos) e identificação das restrições relativas à operação e desenvolvimento. Estudo de viabilidade: rentabilidade. Elicitação e análise de requisitos: entendimento. Especificação de requisitos: documento. Validação de requisitos: consistência e completude.

21 ATIVIDADES DO PROCESSO DE SOFTWARE: PROJETO E IMPLMENTAÇÃO DE SOFTWARE Conversão de uma especificação do sistema em um sistema executável. Projeto de arquitetura: estrutura geral do sistema (componentes e suas relações). Projeto de interface: interfaces entre componentes. Projeto de componente: funcionamento. Projeto de banco de dados: estruturas de dados.

22 ATIVIDADES DO PROCESSO DE SOFTWARE: VALIDAÇÃO DE SOFTWARE Verificação e Validação (V&V). Verificação: Estou construindo o produto certo?. Validação: Estou construindo o produto da forma correta?. Sistemas devem ser testados como uma unidade única. Teste de desenvolvimento: desenvolvedores. Teste de sistemas: integração de componentes. Teste de aceitação: dados do cliente.

23 ATIVIDADES DO PROCESSO DE SOFTWARE: EVOLUÇÃO DE SOFTWARE Desenvolvimento e manutenção devem ser encarados como processos contínuos. O software é constantemente modificado em função do das mudanças de requisitos. Mudanças no software são mais baratas que em projetos de hardware.

24 PARADIGMA Exemplo típico ou modelo de algo. É a representação de um padrão a ser seguido.

25 PARADIGMAS DA ENGENHARIA DE SOFTWARE Escolha de um modelo de processo para Engenharia de Software. Um modelo de processo de software é uma representação simplificada de um processo de software. Cada modelo representa uma perspectiva particular de um projeto e, portanto, fornece informações parciais sobre ele.

26 MODELO EM CASCATA

27 MODELO EM CASCATA Análise e definição de requisitos: estabelecimento de serviços, restrições e metas. Projeto de sistema e software: aloca requisitos tanto de hardware tanto de software. Implementação e teste unitário: conjunto de unidades de programas são testados. Integração e teste de sistema: integração das unidades para um teste do sistema completo. Operação e manutenção: correção de erros não descobertos e inserção de funcionalidades.

28 MODELO EM CASCATA Também chamado de Ciclo de Vida. O resultado de cada estágio é a aprovação de um ou mais documentos assinados. O estágio seguinte não deve ser iniciado antes da conclusão da fase anterior. Na prática, os estágios se sobrepõem e se alimentam, um ao outro, de informações. Uma versão executável só fica disponível quando o projeto é finalizado. Erros iniciais x Evolução.

29 MODELO (DE DESENVOLVIMENTO) INCREMENTAL

30 MODELO (DE DESENVOLVIMENTO) INCREMENTAL Desenvolvimento de uma implementação inicial (núcleo de produto), apresentá-la ao cliente e aplicar as correções solicitadas, resultando em uma nova versão/incremento (até que o sistema adequado seja apresentado). Sequencia linear x incrementos. Promoção de mudanças mais barata e fácil. Invisível ao gerente: rapidez de incrementação x documentação.

31 MODELO RAD RAPID APPLICATION DEVELOPMENT

32 MODELO RAD Processo incremental que enfatiza um ciclo de desenvolvimento extremamente curto. Modularidade x ciclo de desenvolvimento. Projetos grandes envolvem grandes equipes. Exige compromisso de desenvolvedores e clientes com atividades continuamente rápidas. Orientação à reuso diminui necessidades de testes.

33 MODELO DE PROTOTIPAGEM

34 MODELO DE PROTOTIPAGEM Protótipo é uma implementação concreta mas parcial do desenho do sistema. Componente de uma UI User Interface. Físico. Funcional. Auxilia na compreensão do que deve ser construído quando os requisitos estão confusos, possibilitando que seja criado um modelo executável ao invés de descrito. Geralmente o cliente deseja que o protótipo tornese o produto final. Escolhas aquém da necessidade, podem tornar-se parte integrante do sistema.

35 MODELO EM ESPIRAL

36 MODELO EM ESPIRAL Ciclo de vida clássico com prototipagem, porém, com a análise de riscos à medida que, gradativamente, o software vai sendo construído. Este modelo assume que o desenvolvimento ocorre em ciclos. Variações consideram entre 3 e 6 tarefas (setores) de avaliação na espiral: Comunicação com o cliente. Planejamento. Análise de risco. Engenharia. Construção e entrega. Avaliação do cliente.

37 MODELO EM ESPIRAL

38 MODELO EM ESPIRAL Direção radial: custo acumulado. Direção angular: progresso através da espiral. Modelo mais indicado para softwares de grande escala. Permite ao engenheiro de software e ao cliente reagir aos riscos após cada etapa evolutiva.