Engenharia de Software Fidedigno
Arndt von Staa
Departamento de Informática
PUC-Rio
Abril 2009
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

Arndt von Staa © LES/PUC-Rio
2 / 25
Terminologia
Resultados
Dados
Usuário
Produtor
cria elemento
Elemento
Falha
g
j
e
c
h
a
?
Observador
de erros
?
b
d
f
Defeito
Erro
Causa
endógena
provoca
um erro
?
i
?
Sistema
Engano do produtor
introduz defeito
Abr 2009
k
Lesão
(conseqüência
de erro não
observado)
Causa exógena
provoca um erro
Arndt von Staa © LES/PUC-Rio
3 / 25
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
Arndt von Staa © LES/PUC-Rio
4 / 25
Características da fidedignidade, básicas
Disponibilidade:
Confiabilidade:
Segurança:
Proteção:
Privacidade:
Integridade:
Escalabilidade:
estar pronto para prestar serviço correto sempre
que solicitado
prestar continuamente serviço correto
(safety) habilidade de evitar conseqüências
catastróficas tanto aos usuários como ao ambiente
habilidade de evitar o sucesso de tentativas de
agressão
habilidade de proteger dados e código contra
acesso (uso) indevido acidental ou deliberada
habilidade de proteger dados e código contra
corrupção (ausência de alterações não permitidas)
acidental ou deliberada
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
Arndt von Staa © LES/PUC-Rio
5 / 25
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
Arndt von Staa © LES/PUC-Rio
6 / 25
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:
Abr 2009
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
Arndt von Staa © LES/PUC-Rio
7 / 25
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
Arndt von Staa © LES/PUC-Rio
8 / 25
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
Arndt von Staa © LES/PUC-Rio
9 / 25
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
isto é um ideal, devemos tentar
• não contém defeitos
nos aproximar dele
• 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!
Abr 2009
Arndt von Staa © LES/PUC-Rio
10 / 25
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
Foco de interesse
Conseqüência
Usuário
Processo da
organização 1
Resultados
Dados
persistentes
Artefato
Processo da
organização 2
Controles
e dados
Interação com
outros artefatos
Outros
artefatos
Abr 2009
Arndt von Staa © LES/PUC-Rio
11 / 25
Observações sobre o estado da prática
• Bibliotecas de classes são freqüentemente não confiáveis
Thomas, D.; “The Deplorable State of Class Libaries”; Journal of Object Technology 1(1); Zürich, CH:
ETH Zürich; 2002; pags 21-27
• 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?
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
• Variação de produtividade entre indivíduos: 1:20 a 1:35
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
Arndt von Staa © LES/PUC-Rio
12 / 25
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
Arndt von Staa © LES/PUC-Rio
13 / 25
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
Custo decorrente de falhas
vez que esta tem
impacto direto
Custo total
sobre a economia
do negócio
Valor do serviço
Custo do desenvolvimento
Perda por falta
de qualidade
C
u
s
t
o
Perda por excesso
de qualidade
Valor líqüido
Qualidade assegurada
Abr 2009
Arndt von Staa © LES/PUC-Rio
14 / 25
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
Arndt von Staa © LES/PUC-Rio
15 / 25
Causa e efeito para software fidedigno
Instrumentos
Controle da qualidade
Padrões e
Normas
Revisões
Inadequação
do instrumento
Especificação
Interação ativa
com os usuários
Informais
Inspeções
Aprovação a Não registradas
Verificação
cada iteração
“Deixa comigo”
estática
Não
Complexidade
Formalização
verificável
Metodologias
leve
Testes
Shelfware
Volatilidade
Especificações
Ferramentas
Automação
controladas
Padrões de
referência
Software
fidedigno
Formação
Capacitação
Certificação
Proficiência
Satisfação
profissional
Pessoal
Abr 2009
Baixa atratividade da área
Baixa formação
básica e superior
Agilidade Desinteresse
da direção
Iterações
Burocracia
Melhoria
induzida
contínua
Programas de
ensino inadequados Institucionalizado
Alterações
controladas
Individualismo
Complexidade
do processo
Processos
Arndt von Staa © LES/PUC-Rio
Contribui
Atrapalha
Adaptação de diagramas
de Ishikawa
16 / 25
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
Arndt von Staa © LES/PUC-Rio
17 / 25
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
Arndt von Staa © LES/PUC-Rio
18 / 25
Desafio: reduzir a dependência de humanos
• Desenvolvimento de ferramentas configuráveis (metaferramentas) 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
Arndt von Staa © LES/PUC-Rio
19 / 25
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
Arndt von Staa © LES/PUC-Rio
20 / 25
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
Arndt von Staa © LES/PUC-Rio
21 / 25
Melhoria contínua  feedback
Atua sobre
especificação
Desenvolve
Evolui
Especificação
Artefato
Defeito na
especificação
Laudo
Idéias, estado da arte
Avalia
Mede
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.
Atua sobre
pessoas
Atua sobre
ferramentas
Atua sobre
processo
Processo
Falta de
habilitação
Ferramentas
inadequadas
Defeito no
processo
Artefato
aceito
Evolução do estado
da arte
No sentindo mais
amplo: técnicas,
métodos,
metodologias, novas
formas arquiteturais,
ferramentas ppd, ...
Ferramentas
Pessoas
Abr 2009
Arndt von Staa © LES/PUC-Rio
22 / 25
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
Arndt von Staa © LES/PUC-Rio
23 / 25
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
Abr 2009
Arndt von Staa © LES/PUC-Rio
24 / 25
Perguntas?
Arndt von Staa
[email protected]
Departamento de Informática
PUC-Rio
Abril 2009
Abr 2009
Arndt von Staa © LES/PUC-Rio
25 / 25