Engenharia de Software Fidedigno Arndt von Staa Departamento de Informática PUC-Rio Abril 2009.

Apresentação em tema: "Engenharia de Software Fidedigno Arndt von Staa Departamento de Informática PUC-Rio Abril 2009."— Transcrição da apresentação:

1 Engenharia de Software Fidedigno Arndt von Staa Departamento de Informática PUC-Rio Abril 2009

2 Abr 20092 / 25 Arndt von Staa © LES/PUC-Rio Especificação Objetivo –persuadir os participantes que vale a pena estudar assuntos relacionados com prevenção de defeitos, dos pontos de vista: –acadêmico –econômico, ou empresarial –equipe técnica e usuário. Justificativa –desenvolvimento e manutenção de software ainda é intensivo em labor humano. Humanos são falíveis. Logo, é de se esperar que software contenha (muitos?) defeitos. –o que fazer para reduzir o número de defeitos remanescentes ao disponibilizar o software? –o que fazer para que o desenvolvimento de software continue a ser uma atividade motivante? e prazerosa

3 Abr 20093 / 25 Arndt von Staa © LES/PUC-Rio Terminologia

4 Abr 20094 / 25 Arndt von Staa © LES/PUC-Rio Fidedignidade Fidedignidade é definida como sendo a fidelidade de um sistema intensivo em software de modo que se possa justificavelmente depender dele assumindo riscos (de danos) compatíveis com o serviço por ele prestado. fidedigno (Adjetivo) 1.Digno de fé; merecedor de crédito fidelidade (Substantivo feminino) 3.Observância rigorosa da verdade; exatidão. 4.Fís. Propriedade duma balança que assume sempre a mesma posição quando solicitada pelas mesmas forças. Avizienis, A.; Laprie, J-C.; Randell, B.; "Dependability and Its Threats: A Taxonomy"; in: Jacquart, R.; eds.; Proceedings of the IFIP 18th World Computer Congress: Building the Information Society; Dordrecht: Kluwer; 2004; pags 91-120 Weinstock, C.B.; Goodenough, J.B.; Hudak, J.J.; Dependability Cases; CMU/SEI -2004-TN-016, Software Engineering Institute, Carnegie Mellon University; 2004

5 Abr 20095 / 25 Arndt von Staa © LES/PUC-Rio Características da fidedignidade, básicas Disponibilidade:estar pronto para prestar serviço correto sempre que solicitado Confiabilidade:prestar continuamente serviço correto Segurança:(safety) habilidade de evitar conseqüências catastróficas tanto aos usuários como ao ambiente Proteção:habilidade de evitar o sucesso de tentativas de agressão Privacidade:habilidade de proteger dados e código contra acesso (uso) indevido acidental ou deliberada Integridade:habilidade de proteger dados e código contra corrupção (ausência de alterações não permitidas) acidental ou deliberada Escalabilidade:habilidade da capacidade de processamento do software crescer junto com o crescimento da demanda As características são adaptadas de (Avizienis, 2004) e de outros autores. São portanto mais abrangentes do que as do autor citado

6 Abr 20096 / 25 Arndt von Staa © LES/PUC-Rio Características da fidedignidade, tolerância Robustez:habilidade de, em tempo de execução, detectar falhas de modo que as conseqüências (danos) possam ser mantidas em um patamar aceitável (um software robusto não permite lesões) Resiliência: habilidade de, em tempo de execução, amoldar-se a condições anormais de funcionamento (tais como erros endógenos ou exógenos) e recuperar-se delas sem comprometer a sua fidedignidade Recuperabilidade:habilidade em ser rapidamente reposto em operação fidedigna preventivamente ou após a ocorrência de uma falha.

7 Abr 20097 / 25 Arndt von Staa © LES/PUC-Rio Características da fidedignidade, evolução Manutenibilidade:habilidade de ser modificado ou corrigido sem que novos defeitos sejam inseridos –correção e melhorias – corrigibilidade (argh!) –adaptação e evolução – evolutibilidade –habilidade de ser evoluído e corrigido com facilidade – manutenção preventiva Longevidade:habilidade do software e dos dados persistentes por ele utilizados terem vida longa, evoluindo junto com a plata-forma e a tecnologia utilizada para a sua implementação

8 Abr 20098 / 25 Arndt von Staa © LES/PUC-Rio Características da fidedignidade, controle Verificabilidade, Validabilidade, Aprovabilidade habilidade de ter sua qualidade controlada com facilidade e suficiente rigor sempre que desejado Testabilidade habilidade de ser testado com o rigor necessário e sempre que desejado – uma forma de realizar (parcialmente) as três características anteriores Detectabilidadehabilidade do software em execução observar erros, iniciando alguma operação de recuperação ou de prevenção de danos Diagnosticabilidadefacilidade de determinar a causa de uma falha Depurabilidadefacilidade de remover correta e completamente os defeitos diagnosticados Disponibilizabilidade (argh!) facilidade de distribuir e por em uso correto as novas versões

9 Abr 20099 / 25 Arndt von Staa © LES/PUC-Rio Crenças Não se pode esperar que sistemas não contenham defeitos –caso um sistema não contenha defeitos não o saberemos algumas vezes podemos saber se módulos têm defeitos ou não Mesmo sistemas perfeitos podem falhar –falhas provocadas por causas exógenas mau uso, deliberado ou não falhas de hardware falhas da plataforma de software usada As características de fidedignidade não podem ser adicionadas a posteriori –as características precisam ser especificadas, arquitetadas, projetadas etc. junto com os requisitos funcionais –para atingir bons níveis de fidedignidade deve-se prevenir a inserção de defeitos controlar as falhas de causas exógenas

10 Abr 200910 / 25 Arndt von Staa © LES/PUC-Rio Objetivos de qualidade Qualidade por construção –Um artefato possui qualidade por construção caso possua qualidade satisfatória, considerando todas as propriedades relevantes, antes do primeiro teste não contém defeitos Qualidade por desenvolvimento –Um artefato possui qualidade por desenvolvimento caso possua qualidade satisfatória, considerando todas as propriedades relevantes, antes de ser posto em uso podem sobrar defeitos não conhecidos! Qualidade por manutenção –Um artefato possui qualidade por manutenção caso possua qualidade satisfatória, considerando todas as propriedades relevantes, antes de ser reposto em uso podem ser adicionados defeitos não conhecidos! isto é um ideal, devemos tentar nos aproximar dele

11 Abr 200911 / 25 Arndt von Staa © LES/PUC-Rio O que realmente interessa O foco de interesse são as tarefas que o usuário realiza no contexto da organização em que atua –o usuário não quer meramente usar um artefato (sistema) –o usuário quer realizar adequadamente uma tarefa com o apoio do artefato

12 Abr 200912 / 25 Arndt von Staa © LES/PUC-Rio Observações sobre o estado da prática Bibliotecas de classes são freqüentemente não confiáveis Cerca de 50% do software posto em uso contém defeitos não triviais Entre 40 e 50% do esforço de desenvolvimento é gasto em retrabalho inútil Disciplina individual pode reduzir a taxa de introdução de defeitos em cerca de 75% –boas práticas? Variação de produtividade entre indivíduos: 1:20 a 1:35 Boehm, B.W.; Basili, V.R.; “Software Defect Reduction Top 10 List”; IEEE Computer 34(1); Los Alamitos, CA: IEEE Computer Society; 2001; pags 135-137 Thomas, D.; “The Deplorable State of Class Libaries”; Journal of Object Technology 1(1); Zürich, CH: ETH Zürich; 2002; pags 21-27 Glass, R.L.; “A Follow-the-Leader Story with a Strange Ending”; IEEE Software 22(6); Los Alamitos, CA: IEEE Computer Society; 2005; pags 111-112

13 Abr 200913 / 25 Arndt von Staa © LES/PUC-Rio Observações sobre o estado da prática Custos estimados da falta de qualidade (EEUU) –Baseado em surveys envolvendo desenvolvedores e usuários, o custo anual decorrente de um a infra estrutura inadequada para o teste é estimada estar entre US$ 22.2 (12%) e US$ 59.5 (33%) billion. –Estatísticas EUA (2000) mercado de total aproximadamente US$180 billion cerca de 697,000 engenheiros de software mais cerca de 585,000 programadores NIST; The Economic Impacts of Inadequate Infrastructure for Software Testing; Planning Report 02-3; National Institute of Standards & Technology Program Office; Strategic Planning and Economic Analysis Group; May 2002

14 Abr 200914 / 25 Arndt von Staa © LES/PUC-Rio Produtividade Produtividade é medida como o volume (dimensão) de funcionalidade de qualidade satisfatória por unidade de tempo (ou de custo, ou de esforço) Não interessa somente a qualidade, interessa também a produtividade, uma vez que esta tem impacto direto sobre a economia do negócio

15 Abr 200915 / 25 Arndt von Staa © LES/PUC-Rio Produtividade Produtividade é conseqüência da qualidade –Grande parte do esforço de desenvolvimento é perdido em retrabalho inútil –Retrabalho inútil é provocado pelos enganos dos desenvolvedores –Corretude por desenvolvimento aumenta a produtividade automação do controle contínuo da qualidade Produtividade através da redução do trabalho –uso de geradores e transformadores linguagens (gráficas) de nível mais alto do que as que usamos hoje –uso de software parcialmente pronto bibliotecas arcabouços (frameworks) componentes linhas de produto

16 Abr 200916 / 25 Arndt von Staa © LES/PUC-Rio Pessoal Instrumentos Formação Capacitação Certificação Baixa atrati- vidade da área Baixa formação básica e superior Programas de ensino inadequados Padrões e Normas Padrões de referência Processos Metodologias Ferramentas Software fidedigno Controle da qualidade Revisões Inspeções Verificação estática Testes Automação Shelfware Burocracia induzida Proficiência Especificação Complexidade Inadequação do instrumento Causa e efeito para software fidedigno Iterações Melhoria contínua Interação ativa com os usuários Aprovação a cada iteração Individualismo Institucionalizado Formalização leve Alterações controladas Especificações controladas Informais Não registradas “Deixa comigo” Contribui Atrapalha Não verificável Volatilidade Agilidade Desinteresse da direção Complexidade do processo Adaptação de diagramas de Ishikawa Satisfação profissional

17 Abr 200917 / 25 Arndt von Staa © LES/PUC-Rio O grande problema Desenvolvimento hoje é intensivo em pessoal –muito suscetível a falhas humanas –variação da competência: 1 para 20, há quem diga 1 para 35 competência tende a ser medida como produtividade Alternativas –Aumentar competência e reduzir falhas humanas através da formação e capacitação de pessoal aumentar a proficiência aproximar-se dos 35 –Reduzir a necessidade de pessoal tornar o desenvolvimento intensivo em capital, exemplos –robotizar –linhas de produto –Antecipar e melhorar o controle da qualidade

18 Abr 200918 / 25 Arndt von Staa © LES/PUC-Rio Desafio: aumentar a proficiência Exemplos de sugestões –ensinar a empregar sistematicamente técnicas formais leves mostrar como usar em aplicações reais (ou quase reais) não só em toy problems –ensinar a ler software –ensinar a escrever software para que possa ser lido por outros –ensinar e treinar trabalho em grupo (equipe) –ensinar a corrigir e evoluir segundo alguns manutenção consome cerca de 80% dos recursos de “desenvolvimento” –ensinar a organizar o trabalho Como e o que ensinar? O SWEBOK realmente ajuda a definir isso?

19 Abr 200919 / 25 Arndt von Staa © LES/PUC-Rio Desafio: reduzir a dependência de humanos Desenvolvimento de ferramentas configuráveis (meta- ferramentas) que apóiem, de forma integrada, equipes distribuídas, realizando ciclos de desenvolvimento, de manutenção e de engenharia reversa em uma variedade de linguagens de programação, projeto, arquitetura e especificação –análise estática –transformação automática de representações –reflexão automática de representações (engenharia reversa) –geração e realização automática de testes –... MAS os desenvolvedores devem adorar utilizar as ferramentas disponibilizadas

20 Abr 200920 / 25 Arndt von Staa © LES/PUC-Rio Desafio: controle da qualidade contínuo O controle da qualidade deve ser realizado continuamente ao longo de todo o processo de desenvolvimento –precisa ser muito mais eficaz – ter uma taxa muito maior de detecção de defeitos e vulnerabilidades a erros exógenos –precisa ser muito mais eficiente – necessitar de muito menos recursos (tempo, labor humano, custo) para realizar o controle –precisa ser capaz de coevoluir fidedigna e economicamente junto com a evolução ou correção do software

21 Abr 200921 / 25 Arndt von Staa © LES/PUC-Rio Desafio: manter sem deteriorar Uma parte substancial (80%) do esforço é dirigido à manutenção de software –ensinar a fazer isso –habilitar o software a ser manutenível –como realizar isso de forma sistemática? Alguns exemplos –engenharia reversa e reengenharia –rejuvenescimento de sistemas legados o sistema entregue hoje, amanhã já é um sistema legado  –redesenvolvimento sem perda de continuidade do sistema existente sistemas essenciais que precisam mudar de tecnologia

22 Abr 200922 / 25 Arndt von Staa © LES/PUC-Rio Melhoria contínua  feedback Pesquisa precisa mostrar não somente uma proposta ou inovação, precisa também mostrar de forma convincente (achologia não vale...) porque seria melhor do que o que já existe. Idéias, estado da arte Evolução do estado da arte No sentindo mais amplo: técnicas, métodos, metodologias, novas formas arquiteturais, ferramentas ppd,...

23 Abr 200923 / 25 Arndt von Staa © LES/PUC-Rio Exemplos de trabalhos Desenvolvimento / aprimoramento de ferramentas de análise estática Desenvolvimento de ferramenta para a geração e execução automática de casos de teste Utilizando ferramentas disponíveis: –como automatizar e o quanto podemos automatizar o desenvolvimento e a manutenção? –como institucionalizar processos ágeis ou agilizar processos dirigidos por planos para desenvolver e para manter? Desenvolvimento de uma “super meta-ferramenta” Utilizando técnicas formais leves como: –desenvolver sistemas auto-monitorantes, auto-recuperantes? –como gerar casos de teste? Que métricas medem algo que realmente interessa? Como medir, o que medir e como registrar as medições?

24 Abr 200924 / 25 Arndt von Staa © LES/PUC-Rio Conclusão Promover boa formação e adequado treinamento Desenvolver e avaliar boas práticas –documentadas e institucionalizadas Desenvolver ferramentas adequadas, integradas e coerentes com as práticas Desenvolver e avaliar sistematicamente modelos, processos, tecnologias,... Institucionalizar adequada organização do trabalho (processo definido) todos conduzem para o desenvolvimento com qualidade assegurada e produtividade todos representam desafios que ainda não foram satisfatoriamente resolvidos

25 Abr 200925 / 25 Arndt von Staa © LES/PUC-Rio Perguntas? Arndt von Staa arndt@inf.puc-rio.br Departamento de Informática PUC-Rio Abril 2009