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

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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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?


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


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


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


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, ...


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?


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


Perguntas?

Arndt von Staa

[email protected]

Departamento de Informática

PUC-Rio

Abril 2009

Documents

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