07 Gerenciamento de Qualidade SI

(1)

Gerenciamento de

Qualidade

Centro de Informá-ca -‐ Universidade Federal de Pernambuco

Sistemas de Informação

Vinicius Cardoso Garcia

vcg@cin.ufpe.br

Slides originais elaborados por Ian Sommerville

(2)

Deﬁnição

• _{Atributo,
condição
natural,
propriedade
pela}

qual algo ou alguém se individualiza,

dis-nguindo-‐se dos demais; maneira de ser,

essência, natureza.

• _{Excelência,
virtude,
talento.}

• _{Grau
de
perfeição,
de
precisão,
de}

conformidade a um certo padrão.

(3)

Uma pergunta polêmica

O Windows é um

produto de soRware

de alta qualidade?

(4)

clipe que corrige

meus e-‐mails!

Não, ele é a causa

do monopólio da

MS e seus prejuízos

à sociedade!

fonte antes de

responder?

Não gosto

desse negócio

de usar

mouse...

(5)

(6)

Qualidade

• _{Altamente
subje-vo}

• _{Muda
de
indivíduo
para
indivíduo}

– 

Percepções/visões/experiências dis-ntas

• _{Di`cil
responder
de
maneira
absoluta}

• _{Como
melhorar
a
qualidade?}

(7)

Reﬁnando a pergunta

• _{O
Windows
7
será
adequado
para
meu}

ambiente?

– 

Preciso que o tempo de inicialização seja no

máximo 70 segundos

– 

Estarei u-lizando uma arquitetura 32 bits

– 

Tenho possibilidade para instalar outros sistemas

operacionais

(8)

Tempo de boot

75

59.8

64

65

70

73

68

68 Se

gundos

(9)

Qualidade

• _{A
pergunta
agora
deﬁne
um
contexto}

– 

Permite ﬁltrar as possibilidades de avaliação

• _{Deﬁne
termos
especíﬁcos
para
o
que
é
bom
e}

o que não é bom

– 

Está falando sobre “tempo de boot”

• _{Deﬁne
valores
que
eliminam
subje-vidade}

– 

Qualquer pessoa chega à mesma conclusão

(10)

Qualidade de so2ware

• _Como

_saber

_{se
um
soRware
tem
qualidade}

alta ou baixa?

• _{O
que
está
envolvido
na
qualidade
de
um}

soRware?

– 

De que maneiras um soRware pode apresentar

qualidade?

• _{Como
garan-r
que
um
soRware
tem
a}

qualidade desejada?

(11)

Visão geral e histórica de qualidade

Código de Hamurabi (1700 a.C.)

-‐

Responsabilidade proﬁssional

: um

arquiteto que construir uma casa que

se desmorone, causando a morte de

seus ocupantes, é condenado à

(12)

O que é Qualidade de So2ware?

• Qualidade, de maneira simplista, signiﬁca que

um

produto deve atender às sua especiﬁcação

• Isso é problemá-co para os sistemas de soRware

– 

Tensão entre os requisitos de qualidade do cliente

(eﬁciência, conﬁabilidade, etc.) e requisitos de

qualidade do desenvolvedor (facilidade de

manutenção, reusabilidade, etc.)

– 

Alguns requisitos de qualidade são di`ceis de

especiﬁcar de uma maneira não-‐ambígua

• Ex.

Facilidade de uso

– 

As especiﬁcações de soRware são, geralmente,

(13)

Gerenciamento de Qualidade de Software

• _{Dedica-‐se
a
assegurar
que
o}

_{nível
requerido}

de qualidade

seja a-ngido

– 

Em um produto de soRware

• Envolve a deﬁnição de padrões e

procedimentos apropriados de qualidade e a

garan-a de que sejam seguidos

• _{Deve
visar
o
desenvolvimento
de
uma
‘cultura}

de qualidade’

– 

Qualidade vista como uma responsabilidade de

todos

(14)

Gerenciamento de qualidade de so2ware

• Preocupados em garan-r que o nível necessário de qualidade seja

alcançado em um produto de soRware.

• Três principais preocupações:

– 

No nível organizacional, o gerenciamento de qualidade se preocupa

em estabelecer um quadro de processos organizacionais e padrões

que irão gerar um soRware de alta qualidade.

– 

No nível de projeto, o gerenciamento de qualidade envolve a

aplicação de processos de qualidade especíﬁcos e a veriﬁcação de que

esses processos planejados sejam seguidos.

– 

No nível de projeto, o gerenciamento de qualidade também está

preocupada com o estabelecimento de um plano de qualidade para

um projeto. O plano de qualidade deve estabelecer as metas de

qualidade para o projeto e deﬁnir os processos e padrões a serem

usados.

(15)

Escopo do Gerenciamento de Qualidade

• _{Gerenciamento
de
qualidade
é}

par-cularmente importante para

sistemas

grandes e complexos

• _{A
documentação
de
qualidade
é
um
registro}

do progresso

– 

Apóia a con-nuidade do desenvolvimento quando

a equipe de desenvolvimento muda

• _{Para
sistemas
menores,
o
gerenciamento
de}

qualidade precisa de menos documentação

(16)

AZvidade de Gerenciamento de Qualidade

• Garan-a de qualidade

– 

Estabelece procedimentos e padrões

organizacionais

para

qualidade

• Planejamento de qualidade

– 

Seleciona procedimentos e padrões aplicáveis para um

projeto especíﬁco

e o modiﬁca quando necessário.

• Controle de qualidade

– 

Assegura que os procedimentos e os padrões sejam

seguidos pela equipe de desenvolvimento de soRware.

• O gerenciamento de qualidade deve ser separado do

gerenciamento de projeto para assegurar

independência

(17)

(18)

Planejamento de qualidade

• Um plano de qualidade deﬁne as qualidades

desejadas do produto e como esses são

avaliados, além de deﬁnir os atributos de

qualidade mais signiﬁca-vos.

• O plano de qualidade deve deﬁnir o processo de

avaliação da qualidade.

• Ele deve estabelecer quais padrões da

organização devem ser aplicadas e, se necessário,

deﬁnir os novos padrões a serem usados.

(19)

Planos de qualidade

• _{Estrutura
do
plano
de
qualidade:}

– 

Introdução ao produto;

– 

Planos de produto;

– 

Descrições de processo;

– 

Metas de qualidade;

– 

Riscos e gerenciamento de riscos.

• _{Os
planos
de
qualidade
devem
ser}

documentos curtos, sucintos.

(20)

Qualidade de so2ware

• De uma maneira simplista, a qualidade signiﬁca que

um produto deve corresponder às suas especiﬁcações.

• O que é problemá-co para os sistemas de soRware.

– 

Existe uma tensão entre os requisitos de qualidade do

cliente (eﬁciência, conﬁabilidade, etc.) e os requisitos de

qualidade do desenvolvedor (reúso, de manutenção, etc.);

– 

Alguns requisitos de qualidade são di`ceis de se

especiﬁcar de forma inequívoca;

– 

Geralmente as especiﬁcações de soRware são incompletas

e muitas vezes inconsistentes.

• O foco pode ser "adequação à ﬁnalidade" em vez de

conformidade à especiﬁcação.

(21)

Adequação do so2ware à ﬁnalidade

• Durante o processo de desenvolvimento os padrões de

programação e documentação foram seguidos?

• O soRware foi devidamente testado?

• O soRware é conﬁável o suﬁciente para ser colocado em

uso?

• O desempenho do soRware é aceitável para uso normal?

• O soRware é usável?

(22)

(23)

Conﬂitos de qualidade

• Não é possível para qualquer sistema ser o-mizado

para todos esses atributos – por exemplo, melhorar a

robustez poderá levar à perda de desempenho.

• Portanto, o plano de qualidade deve deﬁnir os

atributos de qualidade mais importantes para o

soRware que está sendo desenvolvido.

• O plano também deve incluir uma deﬁnição do

processo de avaliação de qualidade, uma forma

acordada de avaliar se alguma qualidade, como a de

manutenção ou robustez, está presente no produto.

(24)

Qualidade de Processo e de Produto

• _{A
qualidade
de
um
produto
é
inﬂuenciada}

pela

qualidade do processo de produção

– 

Alguns modelos de qualidade partem dessa

premissa

• Isso é importante no desenvolvimento de

soRware, visto que os atributos de qualidade

de produtos são di`ceis de avaliar.

• _{Contudo,
existe
uma
relação}

_complexa

_e

pouco compreendida

entre processos de

(25)

Qualidade Baseada em Processo

• Existe uma ligação ní-da entre processo e produto nos

bens manufaturados

• Para o soRware isso é mais complexo porque:

– 

A aplicação de habilidades individuais e a experiência são

muito importantes no desenvolvimento de soRware

– 

Fatores externos, como a novidade de uma aplicação ou a

necessidade de um cronograma de desenvolvimento

acelerado, podem piorar a qualidade do produto.

• Deve-‐se tomar cuidado para não impor padrões de

processo inadequados

– 

Esses padrões poderiam reduzir, ao invés de melhorar a

qualidade do produto

(26)

(27)

Padrões de Processo na PráZca

• Deﬁnir padrões de processo, tais como o modo

como as revisões devem ser conduzidas, o

gerenciamento da conﬁguração, etc

• Monitorar o processo de desenvolvimento para

assegurar que os padrões

estejam sendo

seguidos

• Relatar sobre o processo para a gerência de

projeto e para o comprador do soRware

• Não usar prá-cas inadequadas simplesmente

porque padrões foram estabelecidos

(28)

Padrões de Qualidade

• _{São
a
chave
para
o
gerenciamento
efe-vo
de}

qualidade.

• _{Podem
ser
internacionais,
nacionais,}

organizacionais ou de projeto.

• _{Padrões
de
produto
deﬁnem
caracterís-cas}

que todos os componentes devem exibir

– 

Ex. um es-lo de programação comum.

• _{Padrões
de
processo
deﬁnem
caracterís-cas}

rela-vas aos processos de soRware

(29)

Importância dos Padrões

• _{Englobam
as}

_{melhores
práZcas}

– 

Evitam a repe-ção de erros do passado.

• _{São
um
arcabouço
para
os
processos
de}

garan-a de qualidade

• _{Padrões
fornecem
con-nuidade}

– 

Novos funcionários podem compreender a

organização pela compreensão dos padrões que

são adotados

(30)

(31)

Problemas com Padrões

• _Podem

_{não
ser
vistos
como
relevantes}

_ou

atualizados pelos engenheiros de soRware

• _{Envolvem,
frequentemente,}

_{muita
burocracia}

• _{Di`cil
manter
a
documentação
associada}

–

 

Ferramentas

são fundamentais!

– 

Normalmente,a documentação termina ﬁcando

(32)

Desenvolvimento de padrões

• _{Envolver
os
engenheiros
na
elaboração}

desenvolvimento

– 

Eles devem compreender as razões de um padrão

• Revisar padrões e seu uso regularmente

– 

Padrões podem se tornar rapidamente

desatualizados e isso reduz sua credibilidade

– 

Incorporar novas “melhores prá-cas”

• Padrões devem ter ferramentas de apoio

– 

Trabalho padronizado em excesso é a mais

(33)

O framework de normas ISO 9001

• Um conjunto de padrões internacionais que podem ser

usados como base para o desenvolvimento de sistemas de

gerenciamento de qualidade.

• ISO 9001, a mais geral dessas normas, aplica-‐se a

organizações que projetam, desenvolvem e mantém

produtos, incluindo soRware.

• A norma ISO 9001 é um framework para desenvolvimento

de padrões de soRware.

– 

Estabelece princípios de qualidade geral, descreve os processos

de qualidade em geral e estabelece os padrões de organização e

procedimentos que devem ser deﬁnidos. Esses devem ser

(34)

(35)

(36)

A cerZﬁcação ISO 9001

• Os padrões e os procedimentos de qualidade

devem ser documentados em um manual de

qualidade da organização.

• Um órgão externo pode cer-ﬁcar que um manual

de qualidade da organização está em

conformidade com a norma ISO 9001.

• Alguns clientes exigem que os fornecedores

tenham a cer-ﬁcação ISO 9001, embora a

necessidade de ﬂexibilidade aqui seja cada vez

mais reconhecida.

(37)

Pontos importantes

• O gerenciamento de qualidade de soRware está preocupada com a

garan-a de que o soRware tenha um baixo número de defeitos e

que a-nja os padrões exigidos de manutenção, conﬁabilidade,

portabilidade e, assim por diante.

• O gerenciamento de qualidade de soRware inclui a deﬁnição de

padrões para processos e produtos e o estabelecimento de

processos para veriﬁcar se esses padrões foram seguidos.

• Os padrões de soRware são importantes para garan-a de qualidade

pois representam uma iden-ﬁcação das "melhores prá-cas“.

• Os procedimentos de gerenciamento de qualidade podem ser

documentados em um manual de qualidade da organização, com

base no modelo genérico para um manual de qualidade sugerido na

norma ISO 9001.

(38)

Revisões e inspeções

• Um grupo examina parte ou a totalidade de um processo

ou sistema e sua documentação para encontrar potenciais

problemas.

• SoRwares ou documentos podem ser "assinados" em uma

revisão, o que signiﬁca que o avanço para a fase seguinte

de desenvolvimento foi aprovado pela gerência.

• Existem diferentes -pos de revisão com obje-vos

diferentes

– 

Inspeções para remoção de defeitos (produto);

– 

Comentários para avaliação de progresso (produto e processo);

– 

Avaliações de qualidade (produto e padrões).

(39)

Avaliações de qualidade

• Um grupo de pessoas examinam cuidadosamente

parte ou a totalidade de um sistema de soRware

e sua documentação associada.

• Código, projetos, especiﬁcações, planos de teste,

padrões, etc., todos podem ser revistos.

• SoRwares ou documentos podem ser "assinados"

em uma revisão, o que signiﬁca que o avanço

para a fase seguinte de desenvolvimento foi

aprovado pela gerência.

(40)

(41)

Comentários e métodos ágeis

• Geralmente, o processo de revisão no desenvolvimento ágil

de soRware é informal.

– 

Em Scrum, por exemplo, há uma reunião de avaliação após cada

iteração do soRware ser concluída (uma revisão sprint), na qual

as questões de qualidade e problemas podem ser discu-dos.

• No Extreme Programming (XP), a programação em pares

garante que o código seja constantemente examinado e

revisado por outro membro da equipe.

• XP se baseia em pessoas que tomam a inicia-va de

melhorar e refatorar o código. As abordagens ágeis

geralmente não são orientadas por padrões, para que os

problemas de compa-bilidade com os padrões

(42)

Inspeções de programa

• Essas são avaliações em pares, em que os engenheiros

examinam a fonte de um sistema com o obje-vo de

descobrir anomalias e defeitos.

• As inspeções não exigem a execução de um sistema,

assim podem ser usadas antes da implementação.

• Elas podem ser aplicadas a qualquer representação do

sistema (requisitos, projeto, conﬁguração, dados de

teste, etc.)

• Elas têm se mostrado uma técnica eﬁcaz para

descobrir bugs de programas.

(43)

Checklists de inspeção

• Um checklist de inspeção dos defeitos comuns deve

ser usada para conduzir a inspeção.

• Os checklists de inspeção de defeitos são dependentes

da linguagem de programação e reﬂetem os erros

caracterís-cos que podem surgir na linguagem.

• Em geral, quanto "mais fraca" a veriﬁcação de -pos,

maior o checklist.

• Exemplos: Iniciação, nomeação de constantes,

repe-ção de loop, limites de vetor, etc.

(44)

(45)

(46)

Métodos ágeis e inspeções

• Processos ágeis raramente usam inspeção formal ou processos de

revisão em pares.

• Em vez disso, eles contam com membros da equipe cooperando

para controlar os código uns dos outros, e as orientações informais,

tais como ‘veriﬁque antes do check-‐in', que sugerem que os

programadores devem veriﬁcar o seu próprio código.

• Os adeptos do Extreme Programming argumentam que a

programação em pares é um subs-tuto eﬁcaz para a inspeção, pois

é, com efeito, um processo de inspeção con|nua.

• Duas pessoas olham para cada linha de código e veriﬁcam essa

antes que seja aceita.

(47)

Medições e Métricas de So2ware

• A medição de soRware se dedica a derivar

um

valor numérico

para algum atributo de um

produto ou de processo de soRware

• Permite comparações

objeZvas

entre técnicas e

processos

• Embora algumas empresas tenham introduzido

programas de medição, a maioria das

organizações ainda não as usam de forma

sistemá-ca

(48)

Métricas de So2ware

• Contagem de determinados elementos de um

sistema de soRware, processo ou documento

– 

Linhas de código em um programa, referências a uma

variável global

• Permitem que o soRware e o processo de

soRware sejam

quanZﬁcados

• Podem ser usadas para prever atributos de

produto e para controlar o processo de soRware.

• As métricas de produto podem ser usadas para

previsões gerais

ou para

idenZﬁcar

componentes anômalos

(49)

(50)

Uso de medições

• Para atribuir um valor aos atributos de qualidade de

sistema

– 

Ao medir as caracterís-cas dos componentes do sistema,

tais como a sua complexidade ciclomá-ca, e depois

agregar essas medições, você pode avaliar atributos do

sistema de qualidade, tais como a manutenibilidade.

• Para iden-ﬁcar os componentes de sistema cuja

qualidade não a-ngiu o padrão

– 

As medições podem iden-ﬁcar os componentes

individuais, com caracterís-cas que se desviam do padrão.

Por exemplo, você pode medir componentes para

descobrir aqueles com maior complexidade. Esses são

mais prováveis de conter bugs pois a complexidade

diﬁculta o entendimento.

(51)

(52)

Suposições de Métricas

• Uma propriedade do soRware

pode ser medida

• Existe um

relacionamento

entre o que podemos

medir e o que queremos conhecer

– 

Podemos somente medir atributos

internos

, mas

estamos, muitas vezes, mais interessados em

atributos

externos

de soRware

• Ex. Acoplamento menor => maior manutenibilidade?

• Esse relacionamento foi

formalizado

e

validado

.

– 

Pode ser di`cil, a par-r do que pode ser medido,

inferir as qualidade desejáveis do sistema

(53)

(54)

Problemas com medições na indústria

• É impossível quan-ﬁcar o retorno sobre o inves-mento de

introduzir um programa de métricas organizacionais.

• Não existe um padrão para métricas de soRware ou processos

padronizados para medição e análise.

• Em muitas empresas, os processos de soRware não são

padronizados e estão mal deﬁnidos e controlados.

• A maioria dos trabalhos a respeito da medição de soRware tem se

concentrado em métricas baseadas em códigos e processos de

desenvolvimento dirigidos a planos. No entanto, atualmente mais e

mais soRwares são desenvolvidos pela conﬁguração de sistemas

ERP ou COTS.

(55)

Métricas de Produto

• _{Uma
métrica
deve
ser
um
previsor
de}

qualidade de produto.

• _{Classes
de
métrica
de
produto}

–

 

Dinâmicas

, coletadas em tempo de execução

• Ajudam a avaliar a eﬁciência e a conﬁabilidade

–

 

EstáZcas

, coletadas em tempo de compilação

• Ajudam a avaliar a conﬁabilidade, a facilidade de

compreensão e a facilidade de manutenção.

– 

Algumas métricas são coletadas a par-r de

informações

sobre

o produto

(56)

Métricas EstáZcas e Dinâmicas

• Métricas dinâmicas são

diretamente

relacionadas

aos atribuitos de qualidade de

soRware

– 

É rela-vamente fácil medir o tempo de resposta de

um sistema (atributo de desempenho) ou a

frequência com que ele falha (atributo de

conﬁabilidade).

• Métricas está-cas têm um

relacionamento

indireto

com atributos de qualidade

– 

É necessário estabelecer um relacionamento entre

essas métricas e as propriedades, tais como

complexidade, facilidade de compreensão e de

manutenção.

(57)

(58)

(59)

(60)

(61)

Análise de componentes de so2ware

• Os componentes de sistema podem ser analisados

separadamente, usando uma variedade de métricas.

• Os valores dessas métricas podem, então, ser

comparados com diferentes componentes e, talvez,

com dados históricos de medição coletados em

projetos anteriores.

• Medições anômalas, que se afastem signiﬁca-vamente

do padrão, podem implicar na existência de problemas

com a qualidade desses componentes

(62)

O Processo de Medição

• _{Um
processo
de
medição
de
soRware
pode}

ser parte do controle de qualidade

– 

Algumas métricas são di`ceis de se coletar de

forma automa-zada

• Ex. Separação de interesses

• _{Os
dados
coletados
durante
este
processo}

devem ser

manZdos

como um recurso da

organização.

(63)

(64)

Recomendações para o Processo de Medição

• _{Não
colete
dados
desnecessários}

– 

As questões a ser respondidas devem ser

decididas previamente e os dados necessários

iden-ﬁcados

• Conte às pessoas porque os dados estão

sendo coletados

– 

Não deve ser parte da avaliação de pessoal

• _{Não
dependa
da
memória}

– 

Colete dados quando são gerados, e não depois

que um projeto foi ﬁnalizado

(65)

Análise de Medições

• _{Nem
sempre
é
óbvio
o
que
os
dados}

signiﬁcam

– 

A

análise

de dados coletados é

muito dikcil

• _{Esta|s-cos
proﬁssionais
devem
ser}

consultados, se es-verem disponíveis

• _{É
muito
importante
usar
métricas}

(66)

Pontos importantes

• Revisões dos resultados do processo de soRware envolve uma

equipe de pessoas que veriﬁca se os padrões de qualidade estão

sendo seguidos.

• Em uma inspeção de programa ou revisão por pares, uma pequena

equipe veriﬁca sistema-camente o código. Eles leem o código em

detalhes e procuram por possíveis erros e omissões

• A medição de soRwares pode ser usada para coletar dados sobre o

soRware e sobre os processos de soRware.

• Métricas de qualidade de produto são par-cularmente úteis para

destacar os componentes anômalos que podem ter problemas de

qualidade.

(67)

Leituras recomendadas

• _{SOMMERVILLE,
I.
Engenharia
de
SoRware.
8ª.}

Ed. São Paulo: Pearson Educa-on, 2007

07 Gerenciamento de Qualidade SI

Gerenciamento de

Qualidade

Centro de Informá-ca -­‐ Universidade Federal de Pernambuco

Sistemas de Informação

Vinicius Cardoso Garcia

vcg@cin.ufpe.br

Deﬁnição

•

Atributo, condição natural, propriedade pela

qual algo ou alguém se individualiza,

dis-nguindo-­‐se dos demais; maneira de ser,

essência, natureza.

•

Excelência, virtude, talento.

•

Grau de perfeição, de precisão, de

conformidade a um certo padrão.

Uma pergunta polêmica

O Windows é um

produto de soRware

de alta qualidade?

clipe que corrige

meus e-­‐mails!

Não, ele é a causa

do monopólio da

MS e seus prejuízos

à sociedade!

fonte antes de

responder?

Não gosto

desse negócio

de usar

mouse...

Qualidade

•

Altamente subje-vo

•

Muda de indivíduo para indivíduo

–

Percepções/visões/experiências dis-ntas

•

Di`cil responder de maneira absoluta

•

Como melhorar a qualidade?

Reﬁnando a pergunta

•

O Windows 7 será adequado para meu

ambiente?

–

Preciso que o tempo de inicialização seja no

máximo 70 segundos

–

Estarei u-lizando uma arquitetura 32 bits

–

Tenho possibilidade para instalar outros sistemas

operacionais

Tempo de boot

75

59.8

64

65

70

73

68

68

Se

gundos

Qualidade

•

A pergunta agora deﬁne um contexto

–

Permite ﬁltrar as possibilidades de avaliação

•

Deﬁne termos especíﬁcos para o que é bom e

o que não é bom

–

Está falando sobre “tempo de boot”

•

Deﬁne valores que eliminam subje-vidade

Centro de Informá-ca -‐ Universidade Federal de Pernambuco

• 

_{Atributo,
condição
natural,
propriedade
pela}

dis-nguindo-‐se dos demais; maneira de ser,

• 

_{Excelência,
virtude,
talento.}

• 

_{Grau
de
perfeição,
de
precisão,
de}

meus e-‐mails!

• 

_{Altamente
subje-vo}

• 

_{Muda
de
indivíduo
para
indivíduo}

– 

• 

_{Di`cil
responder
de
maneira
absoluta}

• 

_{Como
melhorar
a
qualidade?}

• 

_{O
Windows
7
será
adequado
para
meu}

– 

– 

– 

• 

_{A
pergunta
agora
deﬁne
um
contexto}

– 

• 

_{Deﬁne
termos
especíﬁcos
para
o
que
é
bom
e}

– 

• 

_{Deﬁne
valores
que
eliminam
subje-vidade}

– 

• 

_Como

_saber

_{se
um
soRware
tem
qualidade}

• 

_{O
que
está
envolvido
na
qualidade
de
um}

– 

• 

_{Como
garan-r
que
um
soRware
tem
a}

-‐

• 

• 

– 

– 

especiﬁcar de uma maneira não-‐ambígua

• 

– 

• 

_{Dedica-‐se
a
assegurar
que
o}

_{nível
requerido}

– 

• 

• 

_{Deve
visar
o
desenvolvimento
de
uma
‘cultura}

– 

• 