Post on 21-Apr-2015
Engenharia de Software Fidedigno
Arndt von Staa
Departamento de Informática
PUC-Rio
Abril 2009
Abr 2009 2 / 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
Abr 2009 3 / 25 Arndt von Staa © LES/PUC-Rio
Terminologia
Dados Produtorcria e lem ento
Erro
?
?
?
?
O bservadorde erros
Defeito
E lem ento
S istem a
a
b
c
d
e
f
g
h
i
j
k
Usuário
Lesão(conseqüência
de erro nãoobservado)
Falha
Resultados
Engano do produtorin troduz defe ito Causa exógena
provoca um erro
Causaendógenaprovocaum erro
Abr 2009 4 / 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
Abr 2009 5 / 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 corretoSegurança: (safety) habilidade de evitar conseqüências
catastróficas tanto aos usuários como ao ambienteProteção: habilidade de evitar o sucesso de tentativas de
agressãoPrivacidade: habilidade de proteger dados e código contra
acesso (uso) indevido acidental ou deliberadaIntegridade: 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
Abr 2009 6 / 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.
Abr 2009 7 / 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
Abr 2009 8 / 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
Detectabilidade habilidade do software em execução observar erros, iniciando alguma operação de recuperação ou de prevenção de danos
Diagnosticabilidade facilidade de determinar a causa de uma falha
Depurabilidade facilidade de remover correta e completamente os defeitos diagnosticados
Disponibilizabilidade (argh!) facilidade de distribuir e por em uso correto as novas versões
Abr 2009 9 / 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
Abr 2009 10 / 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
Abr 2009 11 / 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
Processo daorganização 1
Processo daorganização 2
Artefato
O utrosartefatos
C ontro lese dados
R esultados D adospersistentes
Interação com outros artefatos
Foco de interesse ConseqüênciaU suário
Abr 2009 12 / 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
Abr 2009 13 / 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
Abr 2009 14 / 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
C usto decorrente de fa lhas
C usto to ta l
Valor do serviço
C usto do desenvolvim ento
Valor líqü ido
Q ualidade assegurada
Custo
Perda por fa ltade qualidade
Perda por excessode qualidade
Abr 2009 15 / 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
Abr 2009 16 / 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çãoestática
Testes
Automação
Shelfware
Burocraciainduzida
Proficiência
Especificação
Complexidade
Inadequaçãodo instrumento
Causa e efeito para software fidedigno
Iterações
Melhoriacontínua
Interação ativa com os usuários
Aprovação a cada iteração
IndividualismoInstitucionalizado
Formalizaçãoleve
Alteraçõescontroladas
Especificaçõescontroladas
Informais
Não registradas
“Deixa comigo”
Contribui
Atrapalha
Nãoverificável
Volatilidade
Agilidade Desinteresseda direção
Complexidadedo processo
Adaptação de diagramasde Ishikawa
Satisfaçãoprofissional
Abr 2009 17 / 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
Abr 2009 18 / 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?
Abr 2009 19 / 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
Abr 2009 20 / 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
Abr 2009 21 / 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
Abr 2009 22 / 25 Arndt von Staa © LES/PUC-Rio
Melhoria contínua feedback
D esenvolveEvolu i
AvaliaM ede
Atua sobrepessoas
A tua sobreferram entas
A tua sobreprocesso
Especificação
Artefatoaceito
D efe ito noprocesso
Ferram entasinadequadas
Falta dehabilitação
Artefato
A tua sobreespecificação
Processo
Ferram entas
Pessoas
Laudo
D efe ito naespecificação
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 estadoda arte
No sentindo mais amplo: técnicas, métodos, metodologias, novas formas arquiteturais, ferramentas ppd, ...
Abr 2009 23 / 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?
Abr 2009 24 / 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 aindanão foram satisfatoriamente resolvidos
Abr 2009 25 / 25 Arndt von Staa © LES/PUC-Rio
Perguntas?
Arndt von Staa
arndt@inf.puc-rio.br
Departamento de Informática
PUC-Rio
Abril 2009