engenharia de software fidedigno qualidade de...

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.


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


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


•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


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


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


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


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


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


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


15


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


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


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


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


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”


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 ��


12


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


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.


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?


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


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


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á


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



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


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


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


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


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


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


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

– . . .


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


21

Retrabalho inútil, evidências

Brykczynski, B.; Meeson, R.; Wheeler, D.A.; “Software Inspection: Eliminating Software Defects”; Sixth

Annual Software Technology Conference; 1994


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


22


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


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


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


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



• 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


25


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


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


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


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)


27

Perguntas?

Arndt von Staa

arndt *at* inf.puc-rio.br

Departamento de Informática, PUC-Rio


engenharia de software fidedigno qualidade de...

Documents