Baixe o app para aproveitar ainda mais
Prévia do material em texto
ENGENHARIA DE SOFTWARE Professor George Hamilton ENGENHARIA DE SOFTWARE Parte I Engenharia de Software O termo foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO Conference on Software Engineering (Conferência sobre Engenharia de Software da OTAN). Sua criação surgiu 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. Objetivos • Apresentar a engenharia de software e explicar a sua importância; • Dirigir as respostas às questões-chave sobre engenharia de software; • Apresentar questões éticas e profissionais e explicar por que elas são assunto para engenheiros de software Motivação • As economias de maioria das nações são dependentes de software. • Cada vez mais sistemas são controlados por software. • A engenharia de software se dedica às teorias, métodos e ferramentas para desenvolvimento de software profissional • Os dispêndios com software representam uma fração significativa do PIB em todos os países desenvolvidos. Motivação • Os custos de software dominam os custos de sistemas computacionais. • Em um PC, os custos de software são frequentemente maiores que o custo do hardware. • Manter um software custa mais que desenvolvê-lo. • Para sistemas com uma longa vida, os custos de manutenção podem ser muito maiores que os custos de desenvolvimento. Questões • O que é software? • O que é engenharia de software? • Qual é a diferença entre engenharia de software e ciência da computação? • Qual é a diferença entre engenharia de software e engenharia de sistemas? • O que é processo de software? • O que é um modelo de processo de software? • Quais são os custos da engenharia de software? • Quais são os métodos da engenharia de software? • O que é CASE (Computer-Aided Software Engeneering) • Quais são os atributos de um bom software? • Quais são os desafios-chave enfrentados pela engenharia de software? Questões O que é software? • Programas de computador e documentação associada, tais como requisitos, modelos de projetos e manuais de usuário. • Produtos de software podem ser desenvolvidos para um cliente particular ou para um mercado geral. O que é software? • Produtos de software podem ser: – Genéricos – desenvolvidos para serem vendidos para uma grande variedade de clientes, por exemplo, softwares para PC, tais como Excel e Word. – Personalizados – desenvolvidos para um único cliente de acordo com as suas especificações. • Um software novo pode ser criado através do desenvolvimento de novos programas, da configuração de sistemas de software genéricos ou da reutilização de um software existente. O que é Engenharia de Software? • Engenharia de software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software. • Engenheiros de software devem - dependendo do problema a ser resolvido, das restrições de desenvolvimento e dos recursos disponíveis - adotar uma abordagem sistemática e organizada para seu trabalho, além de usar ferramentas e técnicas apropriadas. Qual é a diferença entre Engenharia de Software e Ciência da Computação? • A ciência da computação dedica-se à teoria e aos fundamentos; • já a engenharia de software dedica-se aos aspectos práticos de desenvolvimento e de entrega de software para o uso. Qual é a diferença entre Engenharia de Software e Engenharia de Sistemas? • A engenharia de sistemas dedica-se aos aspectos de desenvolvimento de sistemas baseados em computador, incluindo a engenharia de hardware, de software e de processo. – A engenharia de software é parte desse processo que se dedica ao desenvolvimento da infra- estrutura do software, controle, aplicações e banco de dados no sistema. • Os engenheiros de sistema estão envolvidos na especificação, no projeto de arquitetura e na integração e implantação do sistema. O que é Processo de Software? • É um conjunto de atividades cuja meta é o desenvolvimento ou evolução de software. • As atividades genéricas em todos os processos de software são: – Especificação – o que o sistema deve fazer e suas restrições de desenvolvimento. – Desenvolvimento – produção do sistema de software. – Validação – verificação de que o software é o que o cliente deseja. – Evolução – mudança do software em resposta às demandas de mudança. O que é um modelo de Processo de Software? • Uma representação simplificada de um processo de software, apresentado sob uma perspectiva específica. • Exemplos de modelos de processo são: – Modelo de workflow – sequência de atividades; – Modelo de fluxo de dados – fluxo de informações; – Modelo de papel/ação – quem faz o quê. • Modelos gerais de processo: – Cascata; – Desenvolvimento iterativo; – Engenharia de software baseada em componentes. Quais são normalmente os custos da Engenharia de Software? • Aproximadamente 60% dos custos são custos de desenvolvimento e 40% são custos de testes. – Para software sob encomenda, os custos de evolução normalmente excedem de desenvolvimento. • Os custos variam dependendo do tipo de sistema que está sendo desenvolvido e dos requisitos de atributos de sistema, tais como desempenho e confiabilidade. • A distribuição de custos depende do modelo de desenvolvimento que é usado. Distribuição de custos nas atividades O que é CASE (Computer-Aided Software Engineering) • Sistemas de software que se destinam a fornecer apoio automatizado para as atividades de processo de software. • Sistemas CASE são usados frequentemente para apoio ao método. – Upper-CASE: Ferramentas para apoiar as atividades iniciais de processo de requisitos e de projeto; – Lower-CASE: Ferramentas para apoiar as atividades finais tais como programação, debugging e teste. Quais são os atributos de um bom Software? O software deve fornecer a funcionalidade e o desempenho requeridos para o usuário e deve ser manutenível, confiável e aceitável. • Facilidade de manutenção: O software deve evoluir para atender às necessidades de mudança; • Confiança: O software deve ser confiável; • Eficiência: O software não deve desperdiçar os recursos do sistema; • Aceitabilidade: O software deve ser aceito pelos usuários para o qual foi projetado. Isso significa que ele deve ser compreensível, usável e compatível com outros sistemas. Quais são os desafios-chave enfrentados pela Engenharia de Software? Heterogeneidade, Entrega e Confiança. • Heterogeneidade – Técnicas de desenvolvimento para construção de software que podem lidar com plataformas heterogêneas e ambientes de execução; • Entrega – Técnicas de desenvolvimento para conduzir a entrega mais rápida de software; • Confiança – Técnicas de desenvolvimento que mostram que o software pode ter a confiança dos seus usuários. Responsabilidade profissional e ética • A engenharia de software envolve responsabilidades mais amplas do que simplesmente a aplicação de habilidades técnicas. • Os engenheiros de software devem se comportar de modo honesto e eticamente responsável para serem respeitados como profissionais. • O comportamento ético é mais do que simplesmente a sustentação de leis. Dilemas éticos • Discordância, em princípio, das políticas da gerência sênior. • Seu funcionário age de uma forma não ética e libera um sistema de segurança crítico sem finalizar o teste do sistema. • Participação no desenvolvimento de sistemas de armamentos militares ou de sistemas nucleares. Segundo o SWEBOK (Corpo de Conhecimento da Engenharia deSoftware), versão 2004, as áreas de conhecimento da Engenharia de Software são: •Requisitos (Requirements) de Software •Projeto (Design) de Software •Construção (Construction) de Software •Teste (Testing) de Software •Manutenção (Maintenance) de software •Gerência de Configuração de Software •Gerência de Engenharia de Software •Processos de Engenharia de Software •Ferramentas e Métodos de Engenharia de Software •Qualidade (Quality) de Software ENGENHARIA DE SOFTWARE Parte II Software 1- INSTRUÇÕES que quando executadas produzem a função e o desempenho desejados 2 - ESTRUTURAS DE DADOS que possibilitam que os programas manipulem adequadamente a informação 3 - DOCUMENTOS que descrevem a operação e o uso dos programas Características do Software 1- desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico 2- não se desgasta mas se deteriora 3- a maioria é feita sob medida em vez de ser montada a partir de componentes existentes 28 Curva de falhas para o hardware tempo “desgaste” “mortalidade infantil” índice de falhas 29 Curva de falhas do software índice de falhas mudança curva real curva idealizada tempo Aplicações do software BÁSICO coleção de programas escritos para dar apoio a outros programas DE TEMPO REAL software que monitora, analisa e controla eventos do mundo real COMERCIAL sistemas de operações comerciais e tomadas de decisões administrativas CIENTÍFICO E DE ENGENHARIA caracterizado por algoritmos de processamento de números Aplicações do software EMBUTIDO usado para controlar produtos e sistemas para os mercados industriais e de consumo DE COMPUTADOR PESSOAL envolve processamento de textos, planilhas eletrônicas, diversões, etc. DE INTELIGÊNCIA ARTIFICIAL faz uso de algoritmos não numéricos para resolver problemas que não sejam favoráveis à computação ou à análise direta Evolução do software (1950 - 1965) � O hardware sofreu contínuas mudanças � O software era uma arte "secundária" para a qual havia poucos métodos sistemáticos � O hardware era de propósito geral � O software era específico para cada aplicação � Não havia documentação Evolução do software (1965 - 1975) �Multiprogramação e sistemas multiusuários � Técnicas interativas � Sistemas de tempo real � 1a. geração de SGBD’s � Produto de sofwtare - software houses � Bibliotecas de Software � Cresce nro. de sistemas baseado em computador �Manutenção quase impossível ..... CRISE DE SOFTWARE Evolução do software (1975 - hoje) � Sistemas distribuídos � Redes locais e globais � Uso generalizado de microprocessadores - produtos inteligentes � Hardware de baixo custo � Impacto de consumo Evolução do software (Quarta era do software de computador) � Tecnologias orientadas o objetos � Sistemas especialistas e software de inteligência artificial usados na prática � Software de rede neural artificial � Computação Paralela crise de software Refere-se a um conjunto de problemas encontrados no desenvolvimento e manutenção de softwares. Como o cliente explicou Como o Lider de projeto entendeu Como a equipe de projeto desenvolveu O QUE O CLIENTE QUERIA EXEMPLO DE RETRABALHO crise de software 1- As estimativas de prazo e de custo freqüentemente são imprecisas “Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software” “Sem nenhuma indicação sólida de produtividade, não podemos avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões” crise de software 2- A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços “Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente” crise de software 3- A qualidade de software às vezes é menos que adequada Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software crise de software 4- O software existente é muito difícil de manter A tarefa de manutenção devora o orçamento destinado ao software A facilidade de manutenção não foi enfatizada como um critério importante crise de software � estimativas de prazo e de custo ↑ � produtividade das pessoas ↓ � qualidade de software ↓ � software difícil de manter ↑ Causas dos problemas associados à crise de software 1- PRÓPRIO CARÁTER DO SOFTWARE O software é um elemento de sistema lógico e não físico. Conseqüentemente o sucesso é medido pela qualidade de uma única entidade e não pela qualidade de muitas entidades manufaturadas O software não se desgasta, mas se deteriora Causas dos problemas associados à crise de software 2- FALHAS DAS PESSOAS RESPONSÁVEIS PELO DESENVOLVIMENTO DE SOFTWARE Gerentes sem nenhum background em software Os profissionais da área de software têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software Resistência a mudanças. Causas dos problemas associados à crise de software 3- MITOS DO SOFTWARE Propagaram desinformação e confusão 4administrativos 4cliente 4profissional Mitos do software (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? Mitos do software (ADMINISTRATIVOS) Realidade: Será que o manual é usado? Os profissionais sabem que ele existe? Ele reflete a prática moderna de desenvolvimento de software? Ele é completo? Mitos do software (ADMINISTRATIVOS) Mito: Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal lhes compramos os mais novos computadores. Realidade:É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade. Mitos do software (ADMINISTRATIVOS) Mito: Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso. Realidade:O desenvolvimento de software não é um processo mecânico igual à manufatura. Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas podem ser acrescentadas, mas somente de uma forma planejada. Mitos do software (CLIENTE) Mito: Uma declaração geral dos objetivos é suficiente para se começar a escrever programas - podemos preencher os detalhes mais tarde. Mitos do software (CLIENTE) Realidade: Uma definição inicial ruim é a principal causa de fracassos dos esforços de desenvolvimento de software. É fundamental 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. Mitos do software (CLIENTE) Mito: Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível. Mitos do software (CLIENTE) Realidade:Uma mudança, quando solicitada tardiamente num projeto, pode ser maior do que a ordem de magnitude mais dispendiosa da mesma mudança solicitada nas fases iniciais. Mitos do software (PROFISSIONAL) Mito: Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo. Mitos do software (PROFISSIONAL) Realidade: Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente. Mitos do software (PROFISSIONAL) Mito: Enquanto não tiver o programa "funcionando", eu não terei realmente nenhuma maneira de avaliar sua qualidade. Mitos do software (PROFISSIONAL)Realidade:Um programa funcionando é somente uma parte de uma Configuração de Software que inclui todos os itens de informação produzidos durante a construção e manutenção do software. Abrange um conjunto de três elementos fundamentais: Métodos, Ferramentas e Processos, para projetar, construir e manter grandes sistemas de software de forma profissional. Engenharia de Software � Planejamento e estimativa de projeto � Análise de requisitos de software e de sistemas � Projeto da estrutura de dados � Algoritmo de processamento � Codificação � Teste � Manutenção MÉTODOS: proporcionam os detalhes de como fazer para construir o software Engenharia de Software FERRAMENTAS: dão suporte automatizado aos métodos. �Existem atualmente ferramentas para sustentar cada um dos métodos �Quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering Engenharia de Software PROCESSOS: constituem o elo de ligação entre os métodos e ferramentas � Sequência em que os métodos serão aplicados � Produtos que se exige que sejam entregues � Controles que ajudam assegurar a qualidade e coordenar as alterações � Marcos de referência que possibilitam administrar o progresso do software. ENGENHARIA DE SOFTWARE Conjunto de etapas que envolveMÉTODOS, FERRAMENTAS e PROCESSOS. � Essas etapas são conhecidas como componentes de CICLOS DE VIDA DE SOFTWARE � Alguns ciclos de vida mais conhecidos são: Ciclo de Vida Clássico, Prototipação, Modelo Espiral e Técnicas de 4a Geração Para escolha de um Ciclo de Vida de software: � natureza do projeto e da aplicação �métodos e ferramentas a serem usados � controles e produtos que precisam ser entregues Ciclo de Vida Clássico (Cascata) �modelo mais antigo e o mais amplamente usado da engenharia de software �modelado em função do ciclo da engenharia convencional �requer uma abordagem sistemática, seqüencial ao desenvolvimento de software Lev de Req. Análise de Requisitos Projeto Implementação Testes Implantação Cascata Atividades do Ciclo de Vida Clássico 1- LEVANT. DE REQUISITOS � envolve a coleta de requisitos em nível do sistema, com uma pequena quantidade de projeto e análise de alto nível � esta visão é essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados) Atividades do Ciclo de Vida Clássico 2- ANÁLISE DE REQUISITOS DE SOFTWARE � o processo de coleta dos requisitos é intensificado e concentrado especificamente no software � deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos � os requisitos (para o sistema e para o software) são documentados e revistos com o cliente �Modelagem conceitual Atividades do Ciclo de Vida Clássico 3- PROJETO � tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie � se concentra em 4 atributos do programa: � Estrutura de Dados, � Arquitetura de Software, � Detalhes Procedimentais e � Caracterização de Interfaces Atividades do Ciclo de Vida Clássico 4- IMPLEMENTAÇÃO � tradução das representações do projeto para uma linguagem de programação resultando em instruções executáveis pelo computador Atividades do Ciclo de Vida Clássico 5- TESTES Concentra-se: � nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas � nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados. Atividades do Ciclo de Vida Clássico 6- IMPLANTAÇÃO � Entrega do software ao cliente. � Treinamentos. Problemas com o Ciclo de Vida Clássico � 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 Prototipação �processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. � idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. �apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes. fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos Prototipação Atividades da Prototipação 1- OBTENÇÃO 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. 2- PROJETO RÁPIDO: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) Atividades da Prototipação 3- CONSTRUÇÃO PROTÓTIPO: implementação do projeto rápido 4- AVALIAÇÃO DO PROTÓTIPO: cliente e desenvolvedor avaliam o protótipo Atividades da Prototipação 5- 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. 6- 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. Problemas com a Prototipação �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 �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. �ainda que possam ocorrer problemas, a prototipação é eficiente. �a chave é definir-se as regras do jogo logo no começo. �o cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos. Ciclo de Vida em Espiral – engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco – 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 decisão de continuar ou não na direção de um sistema concluídoavaliação do cliente engenharia análise dos riscos planejamento Espiral Atividades do Ciclo de Vida em Espiral 1- PLANEJAMENTO: determinação dos objetivos, alternativas e restrições 2- ANÁLISE DE RISCO: análise das alternativas e identificação / resolução dos riscos 3- CONSTRUÇÃO: desenvolvimento do produto no nível seguinte 4- AVALIAÇÃO DO CLIENTE: avaliação do produto e planejamento das novas fases Comentários sobre o Ciclo de Vida em Espiral é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva. pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso 90 Técnicas de 4a 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ível e �o código fonte seja gerado automaticamente a partir dessas especificações 91 Obtenção dos Requisitos Estratégia do “Projeto” Implementação usando 4GL Testes 4a Geração 92 Ferramentas do ambiente de desenvolvimento de software de 4a Geração O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4a geração 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 93 Atividades das Técnicas de 4a Geração 1- 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" 94 Atividades das Técnicas de 4a Geração 2- 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 usando uma linguagem de quarta geraçã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) 95 Atividades das Técnicas de 4a Geração 3- IMPLEMENTAÇÃO USANDO 4GL: 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 4GL 4- 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.
Compartilhar