Post on 12-Nov-2018
1
Engenharia de Software FidedignoQualidade de Software
Arndt von Staa
Departamento de Informática
PUC-Rio
Agosto 2014
Especificação
• Objetivo– Apresentar uma visão geral do que entendemos por qualidade de software• pontos de vista
– satisfação dos diversos interessados (stakeholders)
– das equipes de desenvolvimento e de manutenção
– acadêmico
• Justificativa– conceitos e terminologia básica
– o que entendemos por fidedignidade?
– o que fazer para reduzir o número de defeitos remanescentes ao desenvolver, manter e disponibilizar o software?
– o que fazer para que o desenvolvimento de software continue a ser uma atividade motivante?
• e prazerosa ☺☺☺☺
Ago 2014 2Arndt von Staa © LES/DI/PUC-Rio
2
Artefato
• Artefato é qualquer resultado tangível do desenvolvimento ou da manutenção. São exemplos:
• sistema
• programas (.exe, .class)
• bibliotecas
• serviços na nuvem
• módulos fonte (.c, .cpp, .java, .py, .lua)
• documentos (.doc, documentos em papel)
• diagramas
• scripts (.make, .comp, .test, .script)
• Artefato é um conceito recursivo, ou seja artefatos podem conter artefatos.
• Artefatos devem passar sempre por alguma forma de controle de qualidade.
Ago 2014 3Arndt von Staa © LES/DI/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
Bases de dados
Processo daorganização 1
Processo daorganização 2
Artefato
Outrosartefatos
Controlese dados
Resultados Dadospersistentes
Interação com outros artefatos
Foco de interesse ConsequênciaUsuário
Outrasorganizações
Ago 2014 4Arndt von Staa © LES/DI/PUC-Rio
3
Sistema intensivo em software
Dados Criar / manterelemento
Erro
?
?
?
Observadorde erros
Defeito
Elemento
Sistema
a
b
c
d
e
f
g
h
i
j
k
Controles
Lesão(consequêncianão observada
de um erro)
Falha(erro observado)
Resultados
Engano do produtorou erro de ferramenta
introduz defeito
Engano do produtor
introduz vulnerabilidadeou erro de ferramenta
Causaendógenaprovocaum erro
Causaexógenaprovocaum erro
Vulnera-bilidade
Dano(consequência
observadade um erro)
Erro humanoexplora
vulnerabilidade
Falha internaexplora
vulnerabilidade
Agressãoexplora
vulnerabilidade
Benefícios
Inter-dependência
Ago 2014 5Arndt von Staa © LES/DI/PUC-Rio
•Defeito (falta) é um fragmento de um artefato que, se utilizado, pode levar a um erro
– qualquer artefato pode conter um defeito
– exemplo: uma especificação ou um projeto contendo defeito leva a artefatos derivados defeituosos
• Erro é um desvio entre o que é desejado ou intencionado e o que é gerado ou derivado
– um erro pode existir sem que se saiba disso
• Falha é um erro observado
• Latência do erro é o tempo decorrido entre o momento em que o erro é gerado e o momento em que é observado
– quanto maior a latência significativamente maior é o custo da remoção da causa, i.e. o defeito
Definições
Ago 2014 6Arndt von Staa © LES/DI/PUC-Rio
4
Generalização de defeito
• Defeitos podem ocorrer nas especificações, na arquitetura, nos projetos, no código, nas suítes de teste, ...
• Um defeito na especificação leva a um erro na arquitetura, o que, em última análise, é um defeito na arquitetura
– exemplos de defeitos na especificação:
• esquecer requisitos relevantes
• estabelecer requisitos conflitantes
• redigir requisitos de forma incorreta, ou ambígua
– exemplos de defeitos na arquitetura• não prever controles visando segurança e privacidade
• não antever crescimento da demanda
• não considerar o nível de formação dos usuários
• ser composta por modelos inadequados
– Quanto mais cedo os defeitos forem observados, menor será o retrabalho inútil e menor será o risco de existirem defeitos remanescentes
7 Arndt von Staa © LES/DI/PUC-
Ago 2014
•Vulnerabilidade é um fragmento de um artefato que, quando elaborado ou usado em condições peculiares, podegerar um erro
• ex. 1. sincronização mal feita pode levar a uma condição de corrida
• ex. 2. proteção mal feita permite acesso a pessoa não autorizada
• ex. 3. interface do usuário mal organizada induz erros humanos
• ex. 4. código mal planejado que permite injetar fragmentos de SQL
• ex. 5. dados confidenciais armazenados de forma legível por terceiros permitem não autorizados utilizar dados críticos
– na realidade uma vulnerabilidade é um defeito
• nem sempre perceptível ao revisar ou inspecionar artefatos
• precisa-se procurar explicitamente por eles
Vulnerabilidade
Ago 2014 8Arndt von Staa © LES/DI/PUC-Rio
5
Outros tipos de problemas
• Inadequação ex.
– não atende às necessidades de usuários ou de outros artefatos
– ter desempenho insatisfatório
– ser não escalável (scalability)
– não satisfaz propriedades não funcionais necessárias
• Deficiência ex.
– ser difícil de utilizar
– induzir erro de uso
• Anomalia (bad smell) ex.
– o artefato está correto (funcional e não funcional), mas pode:
• ser desnecessariamente complexo
• ser difícil de manter
• ser difícil de entender
• conter fragmentos ou mesmo artefatos inúteis
Ago 2014 Arndt von Staa © LES/DI/PUC-
9
Erro
• Erro: é um estado ou comportamento diferente do esperado ou desejado.
– estado: os valores contidos em espaços de dados (variáveis, estruturas de dados, arquivos, bases de dados) de interesse, ou os estados de processamento (o que se vê no monitor, arquivo aberto ou fechado, bloqueios de regiões críticas) de interesse
– comportamento: sequência de ações de interesse
• quase sempre o comportamento pode ser descrito como uma sequência de estados (máquina de estados generalizada)
• As causas de um erro podem ser
– endógenas: erros gerados por defeitos em artefatos sob controle da equipe
– exógenas: erros gerados por artefatos e serviços não controláveis pela equipe
Ago 2014 10Arndt von Staa © LES/DI/PUC-Rio
6
• É desejável poder eliminar o defeito quando a falha for observada pela primeira vez quando em uso
– não requer replicação da falha
– torna necessário associar informação adequada e suficiente para poder diagnosticar a causa da falha
• ex. logs contendo anotações
Defeito, remoção
Skwire, D.; Cline, R.; Skwire, N.; First Fault Software Problem Solving: A Guide for Engineers, Managers
and Users; Opentask; Kindle Edition; 2009 ISBN 1906717427
Ago 2014 11Arndt von Staa © LES/DI/PUC-Rio
Arndt von Staa © LES/DI/PUC-
Fidedignidade de software
Um sistema intensivo em software é fidedigno caso atenda satisfatoriamente um conjunto de propriedades de modo que se possa justificavelmente depender dele assumindo
riscos compatíveis com o serviço por ele prestado.
Qual é a diferença entre qualidade e fidedignidade?
• risco depende de: – probabilidade do evento, – impacto (custo) do evento, – relevância, para a organização, do serviço que provoca o evento
• fidedigno (Adjetivo) 1.Digno de fé; merecedor de crédito (Aurélio)
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
Ago 201412
7
Fatores da fidedignidade, básicas
Adequação: prestar o serviço que interessa ao usuário
usuário pode ser: pessoa; outro artefato; outro sistema; sensores e/ou atuadores; mantenedores; operadores; programadores clientes; ...
Confiabilidade: habilidade de, sempre que solicitado, prestar serviço fidedigno
Disponibilidade: estar pronto para prestar serviço fidedigno sempre que necessitado
Utilizabilidade: habilidade de interagir com o usuário sem induzi-lo a erro, nem permitir que erros de uso (observáveis) fiquem despercebidos; dito de outra forma: habilidade do software poder ser entendido, aprendido, corretamente utilizado e ser atraente ao usuário
Clemência: habilidade do software perdoar erros de uso
As características são adaptadas de (Avizienis, 2004) e de outros autores,
são mais abrangentes do que as do autor citado
Ago 2014 Arndt von Staa © LES/DI/PUC-
13
Fatores da fidedignidade, básicas
Interoperabilidade: habilidade do software poder ser corretamente conectado com outros sistemas
Escalabilidade: habilidade da capacidade de processamento do software crescer junto com o crescimento da demanda
Durabilidade: habilidade do software operar fidedignamente por períodos de duração indefinida (longa duração, e.g. 24/7)
Economia: habilidade de produzir resultados necessitando de poucos recursos (ex. computacionais, humanos, financeiros)
Desempenho: habilidade de atender à demanda consumindo recursos (ex. tempo, memória) dentro do limite estipulado
Ago 2014 Arndt von Staa © LES/DI/PUC-
14
8
Fatores da fidedignidade, segurança
Segurança: (safety) habilidade de evitar consequências catastróficas aos usuários, à organização, ou ao ambiente (risco baixo)
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 deliberado
Integridade: habilidade de evitar a corrupção (adulteração) intencional ou acidental de elementos
Ago 2014 Arndt von Staa © LES/DI/PUC-
15
Arndt von Staa © LES/DI/PUC-
Fatores da fidedignidade, tolerância
Robustez: habilidade de, em tempo de execução, detectar erros (reportar falhas) de modo que os possíveis danos ou lesões possam ser mantidos em um patamar aceitável
– um software robusto não provoca lesões• lesão: “prejuízo” não conhecido
– pode gerar danos, desde que controlados
• dano: “prejuízo” conhecido
Recuperabilidade: habilidade de ser rapidamente reposto em operação fidedigna, preventivamente ou após a ocorrência de uma falha
Corrigibilidade: habilidade de ser fácil e rapidamente corrigido quando da ocorrência de uma falha
Resiliência: habilidade de amoldar-se a condições anormais de funcionamento sem comprometer a fidedignidade
Ago 201416
9
Arndt von Staa © LES/DI/PUC-
Fatores da fidedignidade, evolução
Manutenibilidade: habilidade de poder ser modificado ou corrigidocom facilidade e sem que novos defeitos sejam inseridos– manutenção preventiva – refactoring– correção – corrigibilidade (argh!)– melhorias, adaptação e evolução – evolutibilidade
Longevidade: habilidade do software e dos dados persistentes por ele utilizados terem vida longa, evoluindo junto com as necessidades do usuário, com a plataforma, ou com a tecnologia utilizada para a sua implementação– engenharia reversa– reengenharia– rejuvenescimento
Co-evolutibilidade: facilidade de manter a coerência entre todos os artefatos que constituem o software.
Disponibilizabilidade: facilidade de distribuir e por em uso correto as novas versões.
Ago 201417
Arndt von Staa © LES/DI/PUC-
Fatores da fidedignidade, controle
Controlabilidade (Verificabilidade , Validabilidade , Aprovabilidade):
habilidade de ter sua qualidade controlada com facilidade, baixo custo e suficiente rigor sempre que desejado
Testabilidade: habilidade de ser testado com o rigor necessário, a um custo baixo e sempre que desejado
– uma forma de realizar (parcialmente) as três características anteriores
Mensurabilidade: habilidade do software medir seu desempenho
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 ou identificar os pontos de alteração
Depurabilidade: facilidade de remover correta e completamente os defeitos diagnosticados, ou de realizar a alteração
Ago 201418
10
Arndt von Staa © LES/DI/PUC-
Fatores do controle da qualidade
Sensitividade se um controle da qualidade (e.g. caso de teste) observa uma falha, esta será sempre observada ao repetir o controle enquanto o artefato não for alterado
Redundância as diferentes formas de dizer ou observar a mesma coisa são coerentes
Particionamento (modularidade) quebrar um problema em n > 1 subproblemas, cada qual bem definido, bem delimitado e autocontido
• cada módulo, componente ou programa visa um único propósito
• o propósito pode ser estabelecido em níveis de abstração elevados (programas, componentes), ou baixos (módulos)
Visibilidade progresso, especificações e design são observáveis
Feedback (retroalimentação) sempre manter todos os interessados informados
Ago 201419
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
Contribuições e empecilhos para fidedignidade
Iterações
Melhoria
contínua
Interação ativa
com os usuários
Aprovação a
cada iteração
IndividualismoInstitucionalizado
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
Só no
final
incompleto
Ago 2014 20Arndt von Staa © LES/DI/PUC-Rio
11
• Crosby qualidade é a conformidade com os requisitosse os requisitos estiverem errados ter-se-á uma solução correta do problema errado !
• Deming qualidade é a satisfação total do consumidor
• Juran qualidade é a adequação ao uso
• Falconi qualidade é a preferência do consumidor
• ABNT NBR ISO 9000:2005 Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas
Definições de “qualidade”
Ago 2014 21Arndt von Staa © LES/DI/PUC-Rio
Definição que eu uso
A qualidade de um artefato é um conjunto de propriedades a serem satisfeitas em determinado grau, de modo que o artefato satisfaça
as necessidades explícitas e implícitasde todos os seus usuários e demais
interessados (stakeholders)
O problema está no implícito: isso não necessariamente é conhecido pelos desenvolvedores ����
Ago 2014 22Arndt von Staa © LES/DI/PUC-Rio
12
Arndt von Staa © LES/DI/PUC-
O que queremos?
Ter a certeza de que estamos desenvolvendo economicamente software possuindo qualidade de serviço asseguradae capaz de operar em ambientes reais
O que é Engenharia de Software?
• qualidade de serviço - qualidade observada pelos usuários
• qualidade de engenharia - qualidade requerida para assegurar a qualidade de serviço
Ago 201423
Arndt von Staa © LES/DI/PUC-Rio
Qualidade dos artefatos
Duas visões da qualidade:
• qualidade do serviço– é a qualidade do artefato tal como observada pelo usuário
• pessoas – usuário propriamente dito
• operadores
• outros artefatos
• desenvolvedores cliente
• qualidade da engenharia– é a qualidade requerida pela implementação do artefato, necessária para atingir a qualidade de serviço desejada
– é observada pelos desenvolvedores• desenvolvedores de artefatos
• mantenedores
• testadores, auditores
Ago 2014 24
13
Objetivos a alcançar
• 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 vulnerabilidades nem 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 (também é um ideal, no entanto menos difícil de alcançar)
• podem sobrar vulnerabilidades e 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 vulnerabilidades ou defeitos não conhecidos!
isto é um ideal, devemos
tentar nos aproximar dele
Ago 2014 25Arndt von Staa © LES/DI/PUC-Rio
Evidências de defeitos remanescentes
• Defeitos remanescentes [Bao, 2007] :• defeitos observados após entrega e existentes no que foi entregue no primeiro release
– INTEL: no more than 80-90 defects in Pentium (em 2012: +- 3*10**9 transistores no chip; existem GPU’s com +- 7*10**9 transistores [Wikipedia])
– Standard Software: 25 defects / 1000 lines of program
– Good Software: 2 defects / 1,000 lines
– Space Shuttle Software: < 1 defect / 10,000 lines
– Cellular Phone: 3 defects / 1000 lines
– Windows95: 20 defects / 1000 lines
Xinlong Bao; Software Engineering Failures: A Survey; School of EECS, Oregon State University, Corvallis,
OR, U.S.A; apud Huckle, T.; Collection of Software Bugs; http://www5.in.tum.de/~huckle/bugse.html; last
update October 5, 2007.
Ago 2014 26Arndt von Staa © LES/DI/PUC-Rio
14
Custo do software
• Custo do desenvolvimento
– usual: todas as despesas realizadas desde o início do desenvolvimento até a entrega, em geral restritas à mão de obra técnica
• Custo total
– mão de obra, local de trabalho, equipamento, ferramentas de software, bibliotecas, rede, energia, treinamento, ...
– gastos para operar, usar, espaço em servidores, energia, ...
– gastos com registro e acompanhamento de incidentes, ...
– gastos com falhas: danos, diagnóstico das falhas, remoção dos defeitos causadores, reinstalação, ...
• Pergunta: como medir e reduzir o custo total?
– 80% é manutenção, disso 40% é entender o sistema...
– quanto custa um sistema de vendas parado?
Ago 2014 27Arndt von Staa © LES/DI/PUC-Rio
Modelo da economia da qualidade
Custo decorrente de falhas
Custo total
Valor do serviço
Custo do desenvolvimento
Valor líqüido
Qualidade assegurada
Custo
Perda por faltade qualidade
Perda por excessode qualidade
Ago 2014 28Arndt von Staa © LES/DI/PUC-Rio
15
Efeito do processo sobre o custo
Qualidade
Custo
Processo ruim mediano bom
Risco e valormantidos iguais
Processo: a grosso modo é a forma de organizar o
trabalho; conjunto de práticas
Ago 2014 29Arndt von Staa © LES/DI/PUC-Rio
Qualidade satisfatória
• Qualidade satisfatória – é um conceito relativo ao observador – um artefato de qualidade satisfatória assegura satisfação aos diferentes interessados (pessoas, desenvolvedores, outro software) em todas as condições de uso (uso normal, desenvolvimento, integração, manutenção, evolução)
– um artefato de qualidade satisfatória não possui defeitos ou vulnerabilidades que comprometam seu uso, tampouco possui um excesso de qualidade do ponto de vista do conjunto de interessados• é excesso de qualidade quando encarece desnecessariamente o artefato – ninguém precisa do grau de qualidade com que o atributo existe, portanto gastou-se a mais para chegar lá
Ago 2014 30Arndt von Staa © LES/DI/PUC-Rio
16
Qualidade satisfatória
• Qualidade além do necessário (além do desejado) não necessariamente encarece
– a adoção de boas práticas pode produzir qualidade além do necessário e ao mesmo tempo reduzir os custos exemplo:
• ao reduzir o retrabalho inútil mesmo que às custas de pouco mais de esforço pode-se reduzir sensivelmente o custo total
• desenvolver usando teste automatizado custa mais, porém a repetição e o rigor assegurado pelo teste reduzem os custos– custo de repetição do teste é muito baixo
– lesão ou dano decorrente de defeitos remanescentes é menos provável
– desenvolvimento dirigido por testes tende a reduzir o número de defeitos injetados
• utilizar instrumentação baseada em técnicas formais leves aumenta um pouco o esforço (desenvolvimento de código redundante), mas o uso dessas técnicas reduz significativamente a densidade de defeitos injetados, e reduz o custo da diagnose das falhas
Ago 2014 31Arndt von Staa © LES/DI/PUC-Rio
Arndt von Staa © LES/DI/PUC-
Dizer romano há bem mais de 2000 anos
• Errare humanum est– errar é inerente ao ser humano
– Corolário 1: como somos falíveis e o desenvolvimento de software é intensivo em esforço humano, é utópico esperar que software não contenha defeitos.
• Sed in errore perseverare dementis – mas perseverar no erro é próprio do louco
– Corolário 2: é frequente não aprendermos com os nossos erros de modo que possamos reduzir a frequência de defeitos em novo software
não querermos aprender ...
Ago 201432
17
Crenças
• Pode-se sempre esperar que sistemas contenham defeitos– silogismo :
• sistemas são desenvolvidos por humanos. • humanos são falíveis, consequentemente podem injetar defeitos • logo sistemas poderão conter defeitos
– mesmo se desenvolvidos cuidadosamente
– o controle da qualidade procura defeitos e erros• se não achar, isto não quer dizer que não existam• na realidade dever-se-ia preocupar com a prevenção de defeitos
– a probabilidade de que existam mais defeitos em uma seção de programa é proporcional ao número de defeitos encontrados nessa seção [Myers, 2004] (existe controvérsia quanto a isso)
– caso um sistema não contenha defeitos não o saberemos• algumas vezes podemos saber que determinados módulos não têm mais defeitos– cautela: a composição de módulos perfeitos pode gerar um todo imperfeito
Ago 2014 33Arndt von Staa © LES/DI/PUC-Rio
Crenças
• Mesmo sistemas perfeitos podem errar se observado � falhar
– erros provocados por causas exógenas• mau uso, deliberado ou não
– exploração “bem sucedida” de vulnerabilidades
• erros de uso induzidos por má interface humano-computador• erros de hardware• erros da plataforma de software usada• erros de bibliotecas ou de serviços de terceiros• erros de comunicação entre processadores, nuvem, ...
– erros provocados por defeitos na especificação• especificações incorretas ou incompletas• injetadas por ignorância (no bom sentido)• 70% (?) dos defeitos em sistemas entregues são decorrentes de especificações incorretas
• Brown, A.; et alii; Recovery-Oriented Computing (ROC): Motivation, Definition, Techniques, and Case
Studies; Technical Report UCB/CSD-02-1175, Computer Science, University of California Berkeley; 2002
Buscado em: 7/8/2004; URL: http://roc.cs.berkeley.edu/papers/ROC_TR02-1175.pdf
Ago 2014 34Arndt von Staa © LES/DI/PUC-Rio
18
Crenças
• Fidedignidade custa muito se adicionada a posteriori
– a relevância de cada requisito não funcional e requisito inverso precisa ser especificada, arquitetada, projetada etc. junto com os requisitos funcionais
– para atingir bons níveis de fidedignidade deve-se
• evitar a inserção de defeitos e vulnerabilidades
• controlar as vulnerabilidades que podem dar margem a erros gerados por causas exógenas
– encapsular e monitorar as vulnerabilidades de modo que se observem os erros provocados (falhas) por causas exógenas
Ago 2014 35Arndt von Staa © LES/DI/PUC-Rio
Conclusão intermediária
• As important as trying to avoid defects is to write software that can coexist with them.
• It is not a matter of “if your software will err”, but “how to detect that it erred” and “what happens when it fails”.
• Brown, A.; et alii; Recovery-Oriented Computing (ROC): Motivation, Definition, Techniques, and Case
Studies; Technical Report UCB/CSD-02-1175, Computer Science, University of California Berkeley; 2002
Buscado em: 7/8/2004; URL: http://roc.cs.berkeley.edu/papers/ROC_TR02-1175.pdf
Ago 2014 36Arndt von Staa © LES/DI/PUC-Rio
19
Observações sobre o estado da prática
• 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?
– quais?
• O emprego de ferramentas adequadas e coerentes entre si reduz o número de defeitos inseridos
– observam a introdução de defeitos no momento do engano
• 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
• Huizinga, D.; Kolawa, A.; Automated Defect Prevention: Best Practices in Software Management;
Hoboken, New Jersey: John Wiley & Sons; 2007
Ago 2014 37Arndt von Staa © LES/DI/PUC-Rio
Observações sobre o estado da prática
• Custos estimados decorrentes da falta de qualidade (EEUU)
– Baseado em surveys envolvendo desenvolvedores e usuários, o custo anual decorrente de uma infra estrutura inadequada para o teste é estimada estar entre US$ 22.2 (12%) e US$ 59.5 (33%) bilhões.
– Estatísticas EUA (2000)
• mercado de total aproximadamente US$180 bilhões
• 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
Ago 2014 38Arndt von Staa © LES/DI/PUC-Rio
20
Retrabalho inútil
• Exemplos de retrabalho inútil:– desenvolver algo e descobrir que não era isso que se queria ou que se precisava• defeitos na especificação, ou inexistência explícita dela
– desenvolver algo e descobrir que está eivado de defeitos, alguns deles de difícil diagnóstico e depuração• falta de disciplina
• não utilizar boas práticas consagradas
• falta de conhecimento de como raciocinar sobre programas, módulos e código
– trabalhar sem foco• falta de método de trabalho (processo de desenvolvimento)
– perfeccionismo patológico • melhorar, melhorar e melhorar mais ainda algo que já está satisfatório
– . . .
Ago 2014 39Arndt von Staa © LES/DI/PUC-Rio
Retrabalho inútil
• Exemplos de causas para retrabalho inútil– Mudanças nos requisitos, não entender o que o usuário quer
– Não satisfazer requisitos
– Não identificar e resolver riscos antes da ocorrência dos correspondentes eventos
– Arquitetura inexistente ou feita sem cuidado
– Planejamento inadequado
– Falta de coordenação entre grupos• integration hell
– Alterações não controladas ou não coordenadas • ausência de gerência de configuração
– Sequências de trabalho inadequadas
– Falta de proficiência – trabalho mal realizado
– Falta de prevenção de defeitos
Clark, B.K.; The Effects of Software Process Maturity on Software Development Effort; Doctoral
Dissertation; University of Southern California, Faculty of the Graduate School, Computer Science; 1997
Ago 2014 40Arndt von Staa © LES/DI/PUC-Rio
21
Retrabalho inútil, evidências
Brykczynski, B.; Meeson, R.; Wheeler, D.A.; “Software Inspection: Eliminating Software Defects”; Sixth
Annual Software Technology Conference; 1994
Ago 2014 41Arndt von Staa © LES/DI/PUC-Rio
Os desafios do desenvolvimento de software
• Desenvolvimento ainda é muito intensivo em pessoal
– suscetível a falhas humanas
– variação da competência: 1 para 20, há quem diga 1 para 35
• Alternativas
– Reduzir a falibilidade humana através da formação e capacitação de pessoal
• aumentar a proficiência
• procurar aproximar-se do nível 35 ☺☺☺☺
– Reduzir a necessidade de pessoal
• tornar o desenvolvimento intensivo em capital, exemplos– robotizar � geradores, transformadores, analisadores estáticos
– uso de componentes � compositores, meta-artefatos, arcabouços, bibliotecas, linhas de produto
– Antecipar e melhorar a eficácia do controle da qualidade
Ago 2014 42Arndt von Staa © LES/DI/PUC-Rio
22
Ago 2014 43Arndt von Staa © LES/DI/PUC-Rio
Evitar a injeção de defeitos no software
• Algumas propostas:– melhorar a formação e o treinamento do pessoal envolvido
– uso de processos definidos• estabelecimento e adoção de padrões de desenvolvimento
– controle da qualidade anterior aos testes• leitura controlada, revisões, inspeções
• verificação estática
• medição e avaliação estatística
• modelagem e verificação de modelos
• desenvolvimento e testes dirigidos por modelos
• desenvolvimento dirigido por testes
• desenvolvimento dirigido por contratos (contract driven design)– interfaces especificadas através de assertivas
– técnicas formais leves
– argumentação da corretude
Desafio: aumentar a proficiência
• Exemplos de sugestões
– ensinar a produzir software com muito menos defeitos
• disciplina, padrões, boas práticas
– 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 disciplinadamente
• segundo alguns manutenção consome cerca de 80% dos recursos de “desenvolvimento” considerando o custo total
– ensinar a organizar o trabalho
• planejamento, processos definidos?
Como e o que ensinar? O SWEBOK realmente ajuda a definir isso?
Holloway, C.M.; “Why Engineers Should Consider
Formal Methods”; Volume 1; 16th Digital Avionics
Systems Conference, 1997; IEEE Computer Society;
1997; pags 16-22
Ago 2014 44Arndt von Staa © LES/DI/PUC-Rio
23
Desafio: controle da qualidade contínuo
• O controle da qualidade deve ser realizado continuamenteao longo de todo o processo de desenvolvimento
• inspeção, medição, verificação estática, controle de modelos, testes, instrumentação
– precisa ser muito mais eficaz
• ter uma taxa muito maior de detecção de defeitos e de vulnerabilidades– hoje está em torno de 60 a 70%
– precisa ser muito mais eficiente
• necessitar de muito menos recursos (tempo, labor humano, custo) para realizar o controle
• hoje 35% - 50% convencional, 15% - 30% técnicas formais leves
– o conjunto de artefatos precisa ser capaz de co-evoluirfidedigna e economicamente junto com a evolução ou correção do software
Ago 2014 45Arndt von Staa © LES/DI/PUC-Rio
Desafio: controle da qualidade contínuo
• Na realidade o controle da qualidade deveria ajudar a evitar a injeção de defeitos
– técnicas formais leves � especificação e inclusão de assertivas executáveis
• dirige o raciocínio ao desenvolver – redundância de raciocínio
• desenvolvimento dirigido por contratos– contract driven design
– desenvolvimento dirigido por testes• test driven development
• acceptance test driven development
– desenvolvimento dirigido por comportamento• behaviour driven development
• feature driven development
Ago 2014 46Arndt von Staa © LES/DI/PUC-Rio
24
Desafio: manter sem deteriorar
• Uma parte substancial (80% ?) do esforço total é despendido ao manter o software
– ensinar como manter de forma eficaz
– habilitar o software a ser manutenível
• como realizar isso de forma sistemática?
– desenvolver um subsistema de manutenção junto com o desenvolvimento do software
– facilitar a co-evolução
Tamai, T.; Torimitsu, Y.; “Software lifetime and its evolution process over generations”; ICMS International Conference on
Software Maintenance, Orlando, FL, 1992; Los Alamitos, CA: IEEE Computer Society; 1992; pags 63-69
Ago 2014 47Arndt von Staa © LES/DI/PUC-Rio
Desafio: manter sem deteriorar
• Visão de software como um ente vivo
– sistemas de software nascem, crescem, atingem maturidade, evoluem em habilidade (proficiência?), envelhecem, ficam decrépitos e morrem
• podem evoluir para a obsolescência
– mas a necessidade do serviço persiste!
– devem ter vida longa – longevidade
• independentemente da evolução da tecnologia
Ago 2014 48Arndt von Staa © LES/DI/PUC-Rio
25
Desafio: manter sem deteriorar
• Alguns exemplos de atividades relacionados com manutenção
– engenharia reversa e reengenharia
– rejuvenescimento de sistemas legados
• transferir sistemas para novas plataformas ou tecnologias de implementação
• o sistema entregue hoje, amanhã já é um sistema legado ����
– redesenvolvimento sem perda da continuidade do serviço prestado pelo sistema existente
• sistemas essenciais que precisam mudar de tecnologia
Outra definição de reengenharia: engenharia reversa para determinar o que existe e engenharia para
frente para melhorar o que existe.
Ago 2014 49Arndt von Staa © LES/DI/PUC-Rio
Melhoria contínua ���� feedback, aprendizado
DesenvolveEvolui
AvaliaMede
Atua sobrepessoas
Atua sobreferramentas
Atua sobreprocesso
Especificação
Artefatoaceito
Defeito noprocesso
Ferramentasinadequadas
Falta dehabilitação
Artefato
Atua sobreespecificação
Processo
Ferramentas
Pessoas
Laudo
Defeito naespecificação
Pesquisa precisa criar
não somente uma
proposta ou inovação,
precisa também mostrar
de forma convincente
(achologia não vale...) por
que 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, ...
Ago 2014 50Arndt von Staa © LES/DI/PUC-Rio
26
Melhoria contínua
• Para podermos melhorar precisamos:
– saber medir e experimentar de forma confiável
– saber como formular modelos válidos e confiáveis
• as relações (hipóteses) de causa e efeito precisam estar claramente estabelecidas
• as propriedades descartadas pela abstração de fato não têm influência na relação causa e efeito
– formular hipóteses e verificar experimentalmente se valem
– efetuar mudanças e verificar experimentalmente em que grau as melhorias esperadas ocorreram
• comparar “como era antes” com “o que é” depois da mudança
Ago 2014 51Arndt von Staa © LES/DI/PUC-Rio
Conclusão
• Promover boa formação e adequado treinamento
– continuamente � os estados da arte e da prática evoluem muito rapidamente
• Desenvolver, avaliar e aplicar boas práticas de desenvolvimento
• Desenvolver, avaliar e aplicar continuamente práticas de controle da qualidade
• Desenvolver, avaliar e utilizar ferramentas e artefatos adequados, integrados e coerentes com as práticas
• Desenvolver e avaliar sistematicamente modelos, processos, ferramentas, tecnologias, ...
• Institucionalizar adequada organização do trabalho(e.g. processo ágil definido)
Ago 2014 52Arndt von Staa © LES/DI/PUC-Rio