Introdução à Engenharia de Software

Transcrição

1 Introdução à Engenharia de Software U N I V E R S I D A D E T E C N O L Ó G I C A F E D E R A L D O P A R A N Á D E P A R T A M E N T O A C A D Ê M I C O D E E L E T R Ô N I C A P R O F. V I T O R Y A N O

2 O que é Engenharia de Software? O que é Engenharia? O que é Software? Engenharia de Software Por que Engenharia de Software? Qualidade de software

3 O que é Engenharia? Ciência ou profissão de adquirir e de aplicar os conhecimentos matemáticos, técnicos e científicos na criação, aperfeiçoamento e implementação de utilidades, tais como materiais, estruturas, máquinas, aparelhos, sistemas ou processos, que realizem uma determinada função ou objetivo. Arte de aplicar conhecimentos científicos, conhecimentos empíricos e habilitações específicas para a criação de estruturas, dispositivos e processos que se utilizam para converter recursos naturais em formas adequadas ao atendimento das necessidades humanas.

4 O que é Engenharia? Ramos da engenharia: Elétrica Eletrônica Civil Mecânica Química Agrária Ambiental Genética Tráfego Florestal Naval Aeronáutica Segurança Sanitária Biomédica Alimentos Nuclear Produção Aeroespacial Computação...

5 O que é Engenharia? Características da Engenharia (SWEBOK, 1999): Educação de iniciação profissional validada e legitimada pela sociedade Registro da adequação à prática através de certificação voluntária ou licenciamento compulsório Desenvolvimento de habilidades especializadas e educação profissional continuada Suporte através de sociedades profissionais Compromisso a normas de conduta frequentemente estabelecidas em um código de ética

6 O que é Engenharia? Hoje, Engenharia tornou-se um título profissional, regulamentado, em áreas específicas do conhecimento; A diferença fundamental entre as Engenharias está nos materiais e nas teorias utilizadas; A Engenharia de Software, particularmente, se difere das outras Engenharias por não tratar de materiais concretos nem de teorias da Física.

7 O que é Software? Sentença escrita em uma linguagem computável, para a qual existe uma máquina capaz de interpretála. A sentença é composta por uma sequência de instruções e declarações de dados, armazenável em meio digital. Ao interpretar o software, a máquina computável é direcionada à realização de tarefas especificamente planejadas, para as quais o software foi projetado.

8 O que é Software? (...) o termo Programa significa o programa original e todas as cópias completas ou parciais do mesmo. Um Programa consiste em instruções legíveis por máquina, seus componentes, dados, conteúdo audiovisual (tal como imagens, texto, gravações ou figuras) e materiais licenciados relacionados. (Licença de uso de software da IBM)

9 O que é Software? Sistema é um conjunto de elementos e processos que se relacionam para o desempenho de um objetivo comum; O software afeta e depende do sistema utilizado; Sistema e Software não são a mesma coisa!

10 Engenharia de Software Engenharia de Software é uma área da Ciência da Computação voltada especificamente ao desenvolvimento de software; É a aplicação dos princípios científicos, métodos, modelos, padrões e teorias que possibilitem gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimora um sistema de software

11 Engenharia de Software As técnicas muito se assemelham as utilizadas por engenheiros no projeto e desenvolvimento de equipamentos, automóveis, construções, etc. Alguns conceitos estão mais relacionados à Administração empresarial do que Ciência da Computação.

12 Engenharia de Software Corpo de conhecimentos da Engenharia de Software: Matemática Ciência da Computação Administração de Projetos Ciências Cognitivas e Fatores Humanos Engenharia de Computadores Administração e Ciências Administrativas Engenharia de Sistemas

13 Engenharia de Software Conceitos fundamentais: Abstração Métodos e Notações de Análise e Design Prototipação de Interface com Usuário Modularidade e Arquitetura Ciclo de Vida e Processo de Software Reuso Métricas Suporte Automatizado

14 Engenharia de Software 10 áreas da Engenharia de Software (SWEBOK, 1999): Gerência de Configuração de Software Gerência de Engenharia de Software Processo de Engenharia de Software Ferramentas e Métodos Qualidade de Software Requisitos de software Design de software Construção de Software Teste de Software Manutenção de Software

15 Engenharia de Software Quem é o Engenheiro de Software? Programador / Gerente de projetos / Analista de negócios Contato com o cliente Conhecimento das necessidades do cliente e requisitos para o desenvolvimento do software

16 Por que Engenharia de Software? O processo de desenvolvimento de software não está restrito à programação; Pesquisa do Gartner Group (2002) sobre problemas no desenvolvimento de software: 80% estão relacionados ao levantamento de requisitos 20% erros de implementação

17 Por que Engenharia de Software? Mitos no desenvolvimento de software (Pressman): Mitos administrativos Mitos do cliente Mitos do profissional

18 Mitos administrativos Mito: Se a equipe dispõe de um manual de padrões e procedimentos de desenvolvimento de software, então a equipe está apta a encaminhar bem o desenvolvimento. Realidade: É necessário que o que conste no dado manual reflita a prática de desenvolvimento de software e que esta prática seja verificada com frequência, para confirmar o uso do conhecimento.

19 Mitos administrativos Mito: A equipe tem ferramentas de desenvolvimento de software de última geração, uma vez que eles dispõe de computadores de última geração. Realidade: Mais importante que ter um hardware de última geração é ter ferramentas para a automatização do desenvolvimento de software. As chamadas ferramentas CASE (Computer-Aided Software Engineering).

20 Mitos administrativos Mito: Se o desenvolvimento do software estiver atrasado, basta aumentar a equipe para honrar o prazo de desenvolvimento. Realidade: Quanto mais pessoas pegarem o barco andando, pior. Por que os novos profissionais deverão ser treinados e isto será feito por membros da equipe, o que vai implicar em maiores atrasos no cronograma.

21 Mitos do cliente Mito: Uma descrição breve e geral dos requisitos do software é o suficiente para iniciar o seu projeto. Maiores detalhes podem ser definidos posteriormente. Realidade: Este é um dos problemas que pode levar um projeto ao fracasso. O cliente deve ser questionado a fim de definir o mais precisamente possível os requisitos importantes para o software: funções, desempenho, interfaces, restrições de projeto e critérios de validação. Estes são pontos fundamentais para o sucesso do projeto.

22 Mitos do cliente Mito: Os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isto não representa um problema, uma vez que o software é flexível e poderá suportar facilmente as alterações. Realidade: O software é mais flexível que a maioria dos produtos manufaturados, mas não existe software que suporte uma alteração significativa em seu escopo sem influenciar no custo e no prazo de entrega.

23 Mitos do profissional Mito: Após a edição do programa e a sua colocação em funcionamento, o trabalho está terminado. Realidade: A realidade é justamente o contrário. Segundo estatísticas, após a implantação ocorrerão 50% a 70% do esforço do desenvolvimento de software (manutenção).

24 Mitos do profissional Mito: Enquanto o programa não entrar em funcionamento, é impossível avaliar a sua qualidade. Realidade: A preocupação com a qualidade do software deve ocorrer durante todo o processo de desenvolvimento, ao final de cada etapa deve ser feita uma verificação dos critérios de qualidade.

25 Mitos do profissional Mito: O produto a ser entregue no final do projeto é o programa funcionando. Realidade: O produto final não é apenas o software funcionando, mas também um conjunto importante de documentos, que acompanham o mesmo.

26 Por que Engenharia de Software?

27 Qualidade de software O objetivo da Engenharia de Software é melhorar a qualidade dos produtos desenvolvidos. Mas o que é qualidade de software? Cliente: baixo custo, produtividade, agregação de valor ao negócio; Usuário: facilidade de uso, estabilidade, eficiência; Desenvolvedor: bem documentado, código otimizado, fácil manutenção; Infraestrutura: baixo consumo de recursos, portabilidade.

28 Qualidade de software Qualidade de software, como qualidade de produto, depende do propósito do software; Exemplos: controle de tráfego aéreo / editor de textos, software educacional / venda de passagens aéreas; A qualidade deve ser incorporada ao longo do processo de desenvolvimento; A qualidade do software depende da qualidade dos processos usados para desenvolvê-lo e mantê-lo.

29 Processo de software Processo de software é o conjunto de atividades, métodos, práticas e transformações que guiam a produção de software; A definição do processo envolve análise e especificação de requisitos, projeto, desenvolvimento e testes, mas também escolha de um paradigma, métodos, técnicas e procedimentos; Não existe uma abordagem em particular que seja a melhor para a solução da aflição de software. (Pressman)

30 Processo de software A definição do processo deve levar em conta: Tipo de software (sistema de informação, sistema de tempo real, etc.); Paradigma de programação (estruturado, orientado a objetos); Domínio da aplicação; Tamanho; Complexidade; Características da equipe. Diversas normas já foram propostas: ISO 9001, ISO/IEC 12207, ISO/IEC 15504, CMM e CMMI, porém o objetivo não é apresentar uma receita pronta a ser repetida, mas sim apontar caraterísticas de um bom processo.

31 Ciclo de vida clássico Planejamento/Engenharia de Sistemas: obtenção de dados a nível de sistema, com base em conversas com o usuário. Ter uma visão global do sistema, incluindo hardware, software e as pessoas envolvidas. Também chamado estudo de viabilidade.

32 Ciclo de vida clássico Análise/Especificação de Requisitos: definição dos requisitos de software, com relação a recursos. Devem ser documentados e revistos com o cliente antes de iniciar a execução do projeto.

33 Ciclo de vida clássico Projeto: envolve muitos passos, para transformar os requisitos da análise, o modelo lógico em modelo físico. Nesta etapa, definem-se estruturas de dados, arquitetura de software, detalhes procedimentais e interface.

34 Ciclo de vida clássico Construção/Codificação: o projeto é transformado em programa, usando uma linguagem de programação.

35 Ciclo de vida clássico Teste e Integração: realizar os testes no sistema e realizar as integrações com eventuais sistemas atuais.

36 Ciclo de vida clássico Operação e Manutenção: indubitavelmente o software sofrerá mudanças depois que foi entregue ao cliente. A manutenção ocorre basicamente com a correção de erros (manutenção corretiva), adaptação da aplicação a mudanças do ambiente (manutenção adaptativa) e adição de novas características ao software (manutenção evolutiva).

37 Ciclo de vida clássico Planejamento Análise Projeto Codificação Teste Manutenção

38 Gerência de projetos de software A gerência de projetos envolve: Produto: a primeira coisa a se fazer é definir o escopo do projeto. A idéia é decompor o problema. O sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em sub-módulos ou funções, até que se tenha uma visão geral das funcionalidades a serem tratadas no projeto; Processo;

39 Gerência de projetos de software A gerência de projetos envolve: Pessoas: diversas pessoas são envolvidas em diferentes papéis: gerente de projeto, analistas, projetistas, engenheiros de software, programadores, engenheiros de testes, gerente de qualidade, clientes, usuários, etc. Estes papéis e denominações variam bastante dependendo da organização e até mesmo do projeto. As pessoas devem ser organizadas em equipes, o que não é uma tarefa fácil.

40 Gerência de projetos de software Atividades típicas da gerência de projetos: Determinação do Escopo do Software Definição do Processo de Software do Projeto Estimativa de Tamanho Estimativa de Esforço Estimativa (Alocação) de Recursos Estimativa de Tempo (Elaboração do Cronograma do Projeto) Estimativa de Custos Gerência de Riscos Elaboração do Plano de Projeto

41 Gerência de projetos de software Ferramentas CASE auxiliam no gerenciamento de projetos de desenvolvimento de software; A documentação é de vital importância em todas as etapas do desenvolvimento. Sem documentação não há Engenharia de Software; A UML (Unified Modeling Language) é a linguagem padrão para elaboração da estrutura de projetos de software. É empregada para empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software.

42 UML Unified Modeling Language A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos; Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação.

43 Objetivos da UML Ajudar a conceber as ideias, em relação ao sistema projetado; Apresentar as ideias ao grupo de forma que todos possam interagir e discutir; Documentar as ideias quando elas já estiverem bem consolidadas.

44 Conceitos UML Ator Atividade Interface Pacote (Package) Classe Evento

45 Diagramas UML Estrutural: estática Diagrama de Classes Diagrama de Objetos Diagrama de Componentes Diagrama de Implantação Comportamental: dinâmica Diagrama de Casos de Uso Diagrama de Sequência Diagrama de Atividades Diagrama de Estados Diagrama de Colaboração

46 Diagrama de Casos de Uso

47 Diagrama de Casos de Uso

48 Diagrama de Atividades

49 Diagrama de Sequência

50 Diagrama de Estados

51 Diagrama de Pacotes

52 Diagrama de Componentes

53 Diagrama de Implantação

54 Diagrama de Objetos

55 Diagrama de Classes Uma classe é representada por um retângulo. Internamente deve constar seu nome, em negrito com primeira letra em maiúscula; Pessoa Uma classe possui atributos, que são exibidos em sessão inferior ao nome da classe; +nome +idade Pessoa

56 Diagrama de Classes Atributos e operadores possuem uma visibilidade, que pode ser: Public (+): atributos e métodos sempre acessíveis em todos os métodos de todas as classes. É o nível menos rígido de encapsulamento, que equivale a não encapsular; Private ( ): acessíveis somente nos métodos (todos) da própria classe. É o nível mais rígido de encapsulamento; Protected (#): acessíveis no pacote, nos métodos da própria classe e suas subclasses; Package (~): visível no pacote e na classe.

57 Diagrama de Classes Atributos têm um tipo de dado e podem ainda apresentar um valor padrão; Por fim, as operações são representadas em uma terceira sessão do retângulo, abaixo dos atributos: Pessoa +nome: String +idade: int = 18 #posiçãoxy: float[2] = {0,0} +andar(float direcaox, direcaoy): bool +dormir(): bool

58 Diagrama de Classes Relacionamentos: Agregação Associação (bidirecional ou unidirecional) Composição Generalização

59 Conceitual Diagrama de Classes

60 Especificação Diagrama de Classes

61 Implementação Diagrama de Classes