Engenharia de Software

Transcrição

1 Engenharia de Software Introdução Departamento de Matemática Universidade dos Açores Hélia Guerra Engenharia de software A economia de todos os países desenvolvidos depende do software. O número de sistemas controlados por software continua a aumentar A Engenharia de Software é hoje mais importante do que nunca. Os custos com software representam uma fracção significativa na despesa pública dos países desenvolvidos 2

2 Custos com o software Num PC, os custos com o software costumam ser muito maiores do que os custos com o hardware. O software tem mais custos no período de manutenção do que durante o seu desenvolvimento. Para os sistemas com uma longa vida, os custos de manutencão podem ser várias vezes superiores aos custos de desenvolvimento A engenharia de Software preocupa-se com os custos efectivos do desenvolvimento de software 3 o que é software? Programas e respectiva documentação (requisitos, modelos de desenho, manuais de utilização) Os produtos de software podem ser desenvolvidos para um cliente particular ou para serem vendidos no mercado Pode ser Genérico (standard) - desenvolvido para ser vendido a um grupo alargado de clientes (Excel, Word). Específico - desenvolvido para um único cliente de acordo com as suas especificações Pode ser criado novo software a partir do desenvolvimento de novos programas, da configuração de sistemas de software genérico, ou reutilizando 4

3 O que é engenharia de Software? Os produtos de software são grandes e complexos O desenvolvimento requer análise e síntese Análise: decomposição de um problema grande em problemas mais pequeno A abstracção é fundamental Síntese: construção da solução a partir das soluções encontradas para os problemas mais pequenos A composição é um desafio 5 O que é engenharia de Software? O processo de análise 6

4 O que é engenharia de Software? O processo de síntese 7 O que é engenharia de Software? Método: procedimento formal Ferramenta: instrumento ou sistema automático para concluir uma tarefa da melhor forma (mais eficiencia, mais qualidade) Procedimento: combinação de ferramentas e técnicas para produzir um produto Paradigma: Abordagem usada para construir um produto 8

5 O que é engenharia de Software? A Engenharia de Software é a disciplina da engenharia que se preocupa com os aspectos envolvidos na produção de software Engenheiros de Software devem ter uma atitude sistemática e organizada, usar técnicas e ferramentas adequadas ao problema a resolver, atendendo às restrições de desenvolvimento e aos recursos disponíveis para gerar soluções de qualidade 9 Engenharia de software vs. ciência da computação A Ciência da Compução preocupa-se com os aspectos teóricos e com os fundamentos; a Engenharia de Software preocupa-se com os aspectos práticos de desenvolvimento e entrega de software útil e de qualidade Os aspectos téoricos da Ciência da Computação ainda são insuficientes para constituirem uma completa sustentação para a Engenharia de Software (ao contrário e.g. física e engenharia electrónica). 10

6 Engenharia de software vs. ciência da computação Sucesso do software Fazer software é uma ciência e uma arte A execução de tarefas é cada vez mais rápida e efectiva processamento de texto, folha de cálculo, permitiu avanços na Medicina, na Agricultura, nos Transportes, na Educação, etc Contudo, o software ainda tem problemas 12

7 Bugs Falta (fault): ocorre devido a erro (error) humano, na execução de actividades de software Falha (failure): provém do comportamento requirido para o sistema 13 perspectivas de qualidade (Garvin 1984) transcendental: a qualidade é algo que se reconhece mas não se define utilizador: a qualidade é ajustada ao propósito produção: a qualidade está em conformidade com a especificação produto: a qualidade está inerente às próprias caracteristicas do produto baseada no valor: depende do que o cliente está 14 disposto a pagar

8 software de qualidade Uma boa engenharia de software deve incluir uma estratégia para produzir software de qualidade considerar as seguintes prespectivas de qualidade produto processo produto no contexto do ambiente de negócio onde vai ser usado 15 qualidade do produto Utilizadores avaliam um produto pelas características externas (e.g., funcionalidade correcta, numero/tipo de falhas, fiabilidade, eficiência, facilidade de utilização/ manutenção) Desenhadores e equipas de manutenção avaliam a qualidade pelas características internas do (e.g., tipos de faltas) Os critérios dependem de quem está a avaliar Existem modelos de qualidade que relacionam a visão externa do utlizador com a visão interna da equipa de desenvolvimento 16

9 modelo de qualidade de software (McCall 1977) 17 qualidade do processo A qualidade do processo de desenvolvimento e de manutenção é importante para que o produto seja de qualidade O processo de desenvolvimento necessita de ser modelado A modelação de processos é útil para localizar determinado tipo de falta encontrar faltas cedo construir produto seguro 18

10 qualidade do produto no contexto de negócio onde vai ser usado o valor comercial é tão importante como o valor técnico o valor comercial tem que ser quantificado Abordagem comum: return on investment (ROI) Há diferentes metodologias de cálculo do ROI 19 quem participa na engenharia de Software? Cliente: quem pede o serviço e irá pagar o produto final Equipa de desenvolvimento: quem constroi o sistema de software Utilizador: quem irá utilizar o produto final 20

11 quem participa na engenharia de Software? 21 Abordagem aos sistemas Um sistema é um conjunto de entidades, actividades e respectivas relações Numa abordagem aos sistemas identificam-se entidades e actividades define-se a fronteira do sistema considera-se subsistemas e sistemas interrelacionados 22

12 Sistemas Actividades e objectos Uma actividade é um evento Objectos ou entidades são os elementos envolvidos nas actividades Relações e fronteiras do sistema Uma relação define a interação entre entidades e e actividades Fronteira do sistema determina a origem do input e o destino do output 23 Exemplo: Sistema respiratório 24

13 Exemplo: sistema de pagamento Um sistema tem que ser descrito com clareza 25 sistemas inter-relacionados Há sistemas que dependem de outros sistemas As interdependencias podem ser complexas É possível um sistema coexistir dentro de outro sistema Se as fronteiras estiverem bem definidas, a construção de um grande sistema a partir de outros mais pequenos, pode não ser difícil. 26

14 Passos a dar para a construção de um sistema definição e análise de requisitos desenho do sistema desenho do programa escrita dos programas testes de módulos testes de integração teste ao sistema entrega do sistema manutenção 27 membros da equipa de desenvolvimento Analista de requisitos: trabalham com os clientes para identificar e documentar os requisitos Desenhadores: fazem o desenho do sistema Programadores: fazem o desenho do programa e escrevem o código Equipa de testes (testers): procura faltas Equipa de treino (trainers): ensina aos utilizadores como devem utilizar o programa Equipa de manutenção: corrigem faltas que surgem depois da entrega; a pedido do cliente, também podem melhorar o sistema ao longo do tempo Livreiros (librarians): preparam e guardam a documentação 28

15 membros da equipa de desenvolvimento Tarefas tipicamente desempenhadas pelos diferentes membros das equipas de desenvolvimento de software 29 Factores que contribuiram para mudanças no desenvolvimento do software (Wassermann 1996) 30

16 noções fundamentais que constituem a base de uma disciplina de engenharia de software (wasserman, 1996) Abstracção Análise e desenho de métodos e notações Prototipagem da interface com o utilizador Arquitectura de software Processo de software Reutilização Medição Ferramentas e ambientes integrados 31 Abstracção Esconde detalhes, concentrando-se no essencial 32

17 Análise métodos de desenho e notações fornecem documentação facilitam a comunicação oferecem multiplas perspectivas do mesmo problema unificam diferentes perspectivas 33 Prototipagem Prototipo: construção de uma versão simplificada do sistema com funcionalidades limitadas Permite demonstrar funcionalidades do sistema sem que este esteja implementado Facilita a identificação dos requisitos por parte dos utilizadores Muito usada para criar boas interfaces com o utilizador 34

18 Arquitectura de software Descreve um sistema como um conjunto de unidades e respectivos relacionamentos Existem diferentes abordagens Modular Orientada aos dados Orientada aos objectos Orientada aos eventos Outside-in-design As abordagens não são mutuamente exclusivas, podendo usar-se várias em diferentes partes do desenho 35 processo de software Diferentes tipos de software necessitam de diferentes tipos de processos grandes aplicações necessitam de grande controlo aplicações pequenas podem tirar partido de RAD 36

19 Processo de software 37 reutlização Aspectos comuns entre diferentes aplicações podem levar a reutilizar componentes previamente criadas melhora a produtividade reduz custos No entanto, pode ser mais rápido construir uma pequena aplicação do que procurar componentes reutilizáveis componentes genéricas demoram mais tempo a serem feitas É preciso clarificar quem é responsável pelo quê. Generalidade vs especificidade: conflito permanente 38

20 medidas 39 ferramentas e ambientes de integração Características: integração em diferentes plataformas integração de interfaces com o utilizador integração de processos (ligar as ferramentas ao desenvolvimento de processos) integração de dados (partilha de dados) integração de controlo (uma ferramenta poder iniciar a actividade de outra) 40

21 Resumo Dado um problema para resolver, deve-se analisá-lo sintetizar uma solução (flexível e bem documentada) Ter noção de que os requisitos podem ser alterados, mesmo depois da solução encontrada A qualidade deve ser vista por diferentes perspectivas Utilizar conceitos fundamentais da engenharia de software(e.g., abstracção e medida) para identificar os aspectos essenciais do problema e da solução Conhecer sempre a fronteira do sistema 41