Segurança aplicada no desenvolvimento de Software

Prévia do material em texto

Indaial – 2020
Segurança aplicada 
no deSenvolvimento 
de Software
Adriana de Souza Vettorazzo 
Aline Zanin 
Evandro Manara Miletto 
Silvia de Castro Bertagnolli
1a Edição
2020
Elaboração:
Adriana de Souza Vettorazzo 
Aline Zanin 
Evandro Manara Miletto 
Silvia de Castro Bertagnolli
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Conteúdo produzido
Copyright © Sagah Educação S.A.
Impresso por:
III
apreSentação
Caro acadêmico! Estamos iniciando o estudo da disciplina Segurança 
aplicada no desenvolvimento de Software. Esta disciplina objetiva conhecer 
os conceitos básicos e fundamentos do segurança e sua aplicação no processo 
de desenvolvimento de Software, abordando valor da informação e qualidade 
no processo da construção de Software. Além disso serão destacados os 
fatores envolvidos na confiabilidade de Software e política de segurança. 
Recomendamos fortemente que você realize todos os exemplos e 
exercícios resolvidos para um aproveitamento excepcional da disciplina. 
Neste contexto, o livro de estudos de Segurança aplicada no 
desenvolvimento de Software está dividido em três unidades de estudo: 
Unidade 1 – Valor da Informação e Confiabilidade de Software; Unidade 2 – 
Segurança e Vulnerabilidades; Unidade 3 – Qualidade de software e política 
de segurança.
Aproveitamos a oportunidade para destacar a importância de 
desenvolver as autoatividades, lembrando que essas atividades não são 
opcionais. Elas objetivam a fixação dos conceitos apresentados. Em caso de 
dúvida na realização das atividades, sugiro que você entre em contato com 
o seu tutor externo ou com a tutoria da UNIASSELVI, não prosseguindo as 
atividades sem ter sanado todas as suas dúvidas.
Sucesso na sua trajetória acadêmica e profissional! Bons estudos! 
 
 Prof. Nader Ghoddosi
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há 
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova 
diagramação no texto, aproveitando ao máximo o espaço da página, o que também 
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela 
um novo conhecimento. 
Com o objetivo de enriquecer seu conhecimento, construímos, além do livro 
que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você terá 
contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complementares, 
entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento.
Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo.
Conte conosco, estaremos juntos nesta caminhada!
LEMBRETE
VII
UNIDADE 1 - VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE .................1
TÓPICO 1 - CONCEITO E VALOR DA INFORMAÇÃO..................................................................3
1 INTRODUÇÃO .......................................................................................................................................3
2 A INFORMAÇÃO NO CONTEXTO ORGANIZACIONAL ..........................................................3
3 CICLO DE VIDA DA INFORMAÇÃO ..............................................................................................5
4 CLASSIFICAÇÃO DAS INFORMAÇÕES ........................................................................................6
RESUMO DO TÓPICO 1..........................................................................................................................8
AUTOATIVIDADE ...................................................................................................................................9
TÓPICO 2 - QUALIDADE DE SOFTWARE – MÉTODOS
 DE DESENVOLVIMENTO SEGUROS .........................................................................11
1 INTRODUÇÃO .....................................................................................................................................11
2 CONCEITOS ..........................................................................................................................................11
3 BENEFÍCIOS ..........................................................................................................................................14
4 APLICANDO A QUALIDADE DE SOFTWARE ............................................................................16
RESUMO DO TÓPICO 2........................................................................................................................19
AUTOATIVIDADE .................................................................................................................................20
TÓPICO 3 - QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE ...............................25
1 INTRODUÇÃO .....................................................................................................................................25
2 QUALIDADE DE PROCESSO E QUALIDADE DE PRODUTO ................................................25
3 GARANTIA DA QUALIDADE DE SOFTWARE ...........................................................................27
4 REVISÕES E INSPEÇÕES EM SOFTWARE ...................................................................................28
5 REVISÕES TÉCNICAS FORMAIS ..................................................................................................30
6 DIRETRIZES DE REVISÃO ...............................................................................................................30
7 O CHECKLIST.......................................................................................................................................31
RESUMO DO TÓPICO 3........................................................................................................................33
AUTOATIVIDADE .................................................................................................................................34
TÓPICO 4 - CONFIABILIDADE DE SOFTWARE ............................................................................37
1 INTRODUÇÃO .....................................................................................................................................37
2 CONFIABILIDADE DE SOFTWARE ...............................................................................................37
3 DIMENSÃO CONFIANÇA ................................................................................................................40
4 APLICAÇÃO DA DIMENSÃO CONFIANÇA ...............................................................................44
LEITURA COMPLEMENTAR ...............................................................................................................46
RESUMO DO TÓPICO 4........................................................................................................................48AUTOATIVIDADE .................................................................................................................................49
UNIDADE 2 - SEGURANÇA E VULNERABILIDADES .................................................................51
TÓPICO 1 - INTRODUÇÃO À SEGURANÇA EM SISTEMAS WEB ..........................................53
1 INTRODUÇÃO .....................................................................................................................................53
2 ATRIBUTOS DE SEGURANÇA ........................................................................................................55
Sumário
VIII
2.1 AUTENTICIDADE .........................................................................................................................55
2.2 CONFIDENCIALIDADE ................................................................................................................55
2.3 INTEGRIDADE ................................................................................................................................55
2.4 DISPONIBILIDADE ........................................................................................................................55
3 MANUTENÇÃO DA SEGURANÇA ................................................................................................56
3.1 POLÍTICA DE SEGURANÇA DA INFORMAÇÃO (PSI) ..........................................................56
3.2 MECANISMOS ................................................................................................................................56
3.3 CULTURA .........................................................................................................................................56
4 COMPROMETIMENTO DE SEGURANÇA EM SISTEMAS WEB ...........................................57
RESUMO DO TÓPICO 1........................................................................................................................58
AUTOATIVIDADE .................................................................................................................................59
TÓPICO 2 - TIPOS COMUNS DE INVASÃO....................................................................................61
1 INTRODUÇÃO .....................................................................................................................................61
2 INVASÕES COMUNS E PRINCIPAIS TÉCNICAS ......................................................................61
3 ATAQUES DE NEGAÇÃO DE SERVIÇOS .....................................................................................65
3.1 ATAQUE ICMP (INTERNET CONTROL MESSAGE PROTOCOL) ........................................66
3.2 OUTROS ATAQUES DE NEGAÇÃO DE SERVIÇO ...................................................................66
3.3 NEGAÇÃO DE SERVIÇO DISTRIBUÍDA ...................................................................................67
3.4 BUGS EM SERVIÇOS E SISTEMAS OPERACIONAIS ..............................................................68
3.5 FRAGMENTAÇÃO DE PACOTES DE IP ....................................................................................69
4 ATAQUES NA WEB (CLIENTES E SERVIDORES) .......................................................................70
5 ATAQUES A CLIENTES ......................................................................................................................74
6 ATAQUES A SERVIDORES ...............................................................................................................75
RESUMO DO TÓPICO 2........................................................................................................................78
AUTOATIVIDADE .................................................................................................................................79
TÓPICO 3 - CONCEITOS DE SEGURANÇA LÓGICA FÍSICA ...................................................81
1 INTRODUÇÃO .....................................................................................................................................81
2 ELEMENTOS DE SEGURANÇA LÓGICA FÍSICA ......................................................................81
3 MECANISMOS DE DETECÇÃO DE INTRUSÃO FÍSICA .........................................................84
4 FATOR HUMANO E ENGENHARIA SOCIAL ..............................................................................85
5 FATOR HUMANO E ENGENHARIA SOCIALTECNOLOGIAS PARA A .................................. 
 IMPLEMENTAÇÃO DE SEGURANÇA LÓGICA FÍSICA ..........................................................87
5.1 FECHADURAS DE PINOS.............................................................................................................88
5.2 FECHADURAS TUBULARES........................................................................................................88
5.3 FECHADURAS DE COMBINAÇÃO ............................................................................................89
5.4 FECHADURAS DE COMBINAÇÃO ELETRÔNICA .................................................................89
5.5 COFRES .............................................................................................................................................90
5.6 CÓDIGO DE BARRAS ....................................................................................................................90
5.7 CARTÕES COM TARJA MAGNÉTICA .......................................................................................90
5.8 SMARTCARDS.................................................................................................................................91
5.9 RFID ...................................................................................................................................................91
 5.10 BIOMETRIA ....................................................................................................................................91
LEITURA COMPLEMENTAR ...............................................................................................................93
RESUMO DO TÓPICO 3........................................................................................................................97
AUTOATIVIDADE .................................................................................................................................98
UNIDADE 3 - QUALIDADE DE SOFTWARE E POLÍTICA DE SEGURANÇA ......................101
TÓPICO 1 - MODELOS DE QUALIDADE DE SOFTWARE ........................................................103
1 INTRODUÇÃO ...................................................................................................................................103
IX
2 GERENCIAMENTO DA QUALIDADE DE SOFTWARE ..........................................................103
3 PLANEJAMENTO DA QUALIDADE DE SOFTWARE ..............................................................104
4 QUALIDADE DE SOFTWARE ........................................................................................................105
5 PADRÕES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE ..............................106
RESUMO DO TÓPICO 1......................................................................................................................108
AUTOATIVIDADE ...............................................................................................................................109
TÓPICO 2 - POLÍTICA DE SEGURANÇA DA INFORMAÇÃO
 NA ADMINISTRAÇÃO DE USUÁRIOS E GRUPOS .............................................111
1 INTRODUÇÃO ...................................................................................................................................111
2 O QUE É A POLÍTICA DE SEGURANÇA DA INFORMAÇÃO ..............................................111
3 ESTRUTURA DA POLÍTICA DE SEGURANÇA DA INFORMAÇÃO ..................................114
3.1 ESTABELECER OS RESPONSÁVEIS..........................................................................................1143.2 TIPO DE INFORMAÇÃO .............................................................................................................115
3.3 NÍVEIS DE ACESSO ......................................................................................................................116
3.4 INDICAR OS PADRÕES MÍNIMOS DE QUALIDADE ..........................................................117
3.5 EVIDENCIAR AS CONSEQUÊNCIAS DA VIOLAÇÃO DAS NORMAS ............................117
4 ITENS DA ESTRUTURA POLÍTICA DE SEGURANÇA DA INFORMAÇÃO .....................117
4.1 OBJETIVOS .....................................................................................................................................117
4.2 GERAL .............................................................................................................................................118
4.3 ESPECÍFICO ...................................................................................................................................118
4.4 APLICAÇÕES .................................................................................................................................118
4.5 TIPOS ...............................................................................................................................................118
4.6 NÍVEIS ............................................................................................................................................119
4.7 RESPONSABILIDADES ................................................................................................................119
4.8 CUSTÓDIA .....................................................................................................................................119
4.9 MONITORAMENTO E AUDITORIA .........................................................................................120
4.10 USO DA REDE .............................................................................................................................120
4.11 USO DE EQUIPAMENTOS ........................................................................................................120
4.12 SEGURANÇA ...............................................................................................................................121
4.13 DISPOSIÇÕES FINAIS ................................................................................................................121
5 ESTRUTURA POLÍTICA DE SEGURANÇA DA INFORMAÇÃO – EXEMPLO ..................121
RESUMO DO TÓPICO 2......................................................................................................................125
AUTOATIVIDADE ...............................................................................................................................126
TÓPICO 3 - PLANO DE CONTINGÊNCIA .....................................................................................129
1 INTRODUÇÃO ...................................................................................................................................129
2 CARACTERÍSTICAS DE PLANOS DE CONTINGÊNCIA
 PARA INCIDENTES DE SEGURANÇA ........................................................................................129
3 CONSTRUÇÃO DE PLANOS DE CONTINGÊNCIA
 PARA INCIDENTES DE SEGURANÇA .......................................................................................132
4 ORGANIZAÇÃO DE PROCESSOS DE MANUTENÇÃO
 PARA PLANOS DE CONTINGÊNCIA ..........................................................................................135
LEITURA COMPLEMENTAR .............................................................................................................140
RESUMO DO TÓPICO 3......................................................................................................................142
AUTOATIVIDADE ...............................................................................................................................143
REFERÊNCIAS .......................................................................................................................................145
X
1
UNIDADE 1
VALOR DA INFORMAÇÃO E 
CONFIABILIDADE DE SOFTWARE
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• entender o valor da informação;
• identificar os benefícios da qualidade de software;
• compreender os conceitos básicos de segurança;
• entender e conceituar a confiabilidade de software.
 Esta unidade está dividida em quatro tópicos. No decorrer da 
unidade você encontrará autoatividades com o objetivo de reforçar o 
conteúdo apresentado.
TÓPICO 1 – CONCEITO E VALOR DA INFORMAÇÃO
TÓPICO 2 – QUALIDADE DE SOFTWARE – MÉTODOS DE 
 DESENVOLVIMENTO SEGUROS
TÓPICO 3 – QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE
TÓPICO 4 – CONFIABILIDADE DE SOFTWARE
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
2
3
TÓPICO 1
UNIDADE 1
CONCEITO E VALOR DA INFORMAÇÃO
1 INTRODUÇÃO
As informações têm importância significativa para as empresas, estando 
relacionadas a aspectos estratégicos, de fidelização e atração de clientes e de orga-
nização interna. Devido a essa relevância, as informações estão sujeitas a ameaças 
como perda ou roubo, que podem gerar grandes transtornos para as empresas. 
Assim, torna-se importante compreender em quais momentos as 
informações estão sob maior risco e quais os tipos de informação que exigem 
maiores esforços de segurança da informação. 
Neste tópico, você estudará os conceitos fundamentais de segurança da 
informação, sendo eles o valor da informação para as organizações, o ciclo de 
vida da informação e a classificação da informação.
2 A INFORMAÇÃO NO CONTEXTO ORGANIZACIONAL
Para definirmos a importância da informação para as organizações, 
primeiramente é necessário entender o seu conceito. Distinguiremos dados e 
informação: dados são fatos brutos que não receberam tratamento; já informações 
são o resultado dos dados já tratados e organizados de uma forma lógica, conforme 
lecionam Laudon e Laudon (2007). A Figura 1 traz um esquema desses conceitos.
FIGURA 1 – CONCEITOS DE CONHECIMENTO, INFORMAÇÃO E DADOS
FONTE: Adaptado de Oliveira (2014)
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
4
Em uma empresa, a informação é uma ferramenta-chave que está 
diretamente associada ao seu sucesso ou insucesso. Uma informação ou um 
conjunto de informações pode representar uma parte ou o todo do negócio de 
uma empresa. Por exemplo: uma determinada marca de refrigerantes tem um 
grande faturamento e uma grande quantidade de vendas e tem como diferencial 
a fórmula utilizada para a produção do refrigerante da marca. Nesse contexto, a 
fórmula de produção da bebida é a informação principal da empresa, e a perda ou 
a divulgação dessa informação para a concorrência pode representar o fracasso 
da organização. As empresas também se utilizam da informação para conquistar 
novos clientes e fidelizar clientes antigos, uma vez que, por meio da análise de 
dados e informações, é possível construir o perfil consumidor e habitual dos 
clientes. Assim, uma empresa pode, por exemplo, posicionar produtos em um 
supermercado de acordo com as possibilidades de compra do público que 
frequenta o local. Outro exemplo similar é a oferta de produtos em lojas virtuais 
ou o anúncio de produtos em sites em geral: ao analisar as informações de 
pesquisas recentes e acessos a páginas web feitos pelo cliente, é possível ofertar 
anúncios que sejam atraentes para ele.
Assim, existem diversos aspectos que tornam a informação de grande 
importância para as empresas. Dentre eles, podemos citar:
• o impacto no negócio da empresa;
• a fidelização de clientes;
• a conquista de novos clientes;
• a organização dos processos internos; e
• o estabelecimento de uma cultura organizacional.
Com o crescimento da ofertade tecnologia da informação e a consequente 
necessidade das empresas de se reinventarem e de inovarem em seus processos e 
produtos para se manterem competitivas, as informações empresariais passaram 
a ser armazenadas e manipuladas, em sua maioria, por meio de softwares e 
bancos de dados. 
O uso das informações diminui as incertezas na tomada de decisões e 
garante a competitividade dos negócios. Atualmente, em muitas empresas, a 
informação é tratada como ativo de informação e, como todo ativo, faz parte do 
patrimônio da empresa; como tal, tem valor próprio, conforme leciona Cunha 
(2012). 
O valor da informação para as organizações está descrito nas chamadas 
sete leis da informação, organizadas por Moody e Walsh e abordadas por Beal 
(2004, p. 21-24):
TÓPICO 1 | CONCEITO E VALOR DA INFORMAÇÃO
5
• 1º Lei – A informação é infinitamente compartilhável: diferentemente 
de ativos comuns, como equipamentos, móveis etc., a informação pode 
ser compartilhada infinitamente e simultaneamente por inúmeras 
pessoas, aumentado cada vez mais o seu valor, à medida que mais 
pessoas forem usando. Assim como o compartilhamento aumenta o 
valor, a replicação da informação, através da reinserção de dados não 
agrega valor algum, só tende a aumentar os custos da organização.
• 2º Lei – O valor da informação aumenta com o uso: diferente dos 
ativos comuns da organização que quanto mais usam mais perdem 
valor, a informação quanto mais usada, maior o valor a ela associado. 
Mas para ser bem utilizada, para que seu uso seja efetivo todos da 
organização devem saber que ela existe, saber onde ela está organizada, 
ter acesso a ela e saber como utilizá-la. Além disso essas informações 
devem estar adequadas às necessidades de seus usuários.
• 3º Lei – A informação é perecível: a informação perde parte do seu 
valor à medida que o tempo for passando. Ela deve ser utilizada na 
hora correta, pois corre o risco de perder o valor da descoberta.
• 4º Lei – O valor da informação aumenta com a precisão: quanto 
mais precisa for à informação, mais valor ela terá. O contrário, ou seja, 
a utilização da informação imprecisa, inexatas, pode levar a tomadas 
de decisões equivocadas ou provocar graves erros prejudicando seu 
usuário.
• 5º Lei – O valor da informação aumenta quando há combinação de 
informações: a integração das informações permite uma visão sistêmica 
da organização em substituição à visão setorial, fragmentada. Quando 
mais integrada estiver, maior potencial de valor.
• 6º Lei – Mais informação não é necessariamente melhor: assim como 
a insuficiência de informação, a sobrecarga dela também é prejudicial. 
Muitas vezes o excesso de informação, ultrapassa a capacidade humana 
de processamento. Para ser útil, a informação precisa ser filtrada, usando 
critérios de relevância, quantidade e qualidade de seu conteúdo.
• 7º Lei – A informação se multiplica: a informação é autogenerativa, 
pois ela possui a capacidade de se multiplicar através de novas 
operações de síntese, análise e combinações, podendo ser reciclada e 
reutilizada.
Conforme leciona Gurgel (2006), citando os ensinamentos de Drott (2001), 
“o fato de informações poderem ser estruturadas não quer dizer que o seu valor possa 
ser medido. As tomadas de decisões em uma organização são realizadas com base no 
conhecimento pessoal de seus colaboradores, bem como das informações corporativas 
existentes”.
NOTA
3 CICLO DE VIDA DA INFORMAÇÃO
O ciclo de vida da informação representa todo o “histórico” dessa informação, 
desde o momento de sua criação. O ciclo de vida descreve, inclusive, as mudanças 
na criticidade da informação, isto é, as variações quanto à relevância da informação 
para a empresa: uma informação que, em um dado período, era extremamente 
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
6
importante para uma empresa, pode hoje não ter mais valor de negócio, ou vice-
versa. Por exemplo: há cinco anos, uma marca criou um smartphone com uma 
funcionalidade inovadora; até o lançamento deste, o processo de fabricação e a 
ideia de negócio eram informações de alta criticidade. Após o lançamento, essas 
informações passaram a ser insignificantes para o negócio da empresa.
O ciclo de vida da informação se divide nas seguintes fases, segundo Sêmola 
(2003):
• Manuseio: trata-se do momento da criação e da manipulação da informação, 
seja esta física ou virtual.
• Armazenamento: trata-se do armazenamento da informação, seja ele em 
arquivos físicos ou em bancos de dados de sistemas computadorizados.
• Transporte: momento em que a informação é transportada, seja ao encaminhar 
informações por e-mail, via correspondência ou via telefone, por exemplo.
• Descarte: ato de descartar a informação, quando esta deixa de ser relevante; 
por exemplo: apagar informações de computadores ou depositar documentos 
na lixeira.
As etapas do ciclo de vida da informação representam os momentos em que 
a informação pode estar sob ameaça e, por isso, sua segurança demanda maior atenção. 
Segundo Sêmola (2003), na etapa de manuseio, a informação está sob ameaça, por 
exemplo, ao se fazer anotações em uma reunião e não zelar pelo sigilo das anotações.
NOTA
4 CLASSIFICAÇÃO DAS INFORMAÇÕES
Conforme destacado anteriormente, a informação tem um valor 
fundamental em todas ou, pelo menos, na maioria das empresas. Ela pode ser 
representada de diversas maneiras, por exemplo, digitalizada, em banco de dados, 
ou física, em arquivos de papel. Além da forma de representação, as informações 
também se diferenciam pelas suas restrições de acesso, isto é, as definições de 
quem pode acessar e do nível de segurança demandado. 
Uma vez que uma política de classificação é elaborada pela empresa, 
torna-se possível tomar decisões adequadas para a avaliação e o tratamento de 
riscos. Com isso, segundo Palma (2018), podem ser adotadas medidas preventivas, 
visando, por exemplo, a:
• reduzir o risco de que informações classificadas como sensíveis sejam 
acessadas por pessoas não autorizadas;
• garantir a divulgação adequada para informações públicas;
TÓPICO 1 | CONCEITO E VALOR DA INFORMAÇÃO
7
• reduzir o risco de perda de integridade das informações que criam maior 
valor para o negócio; entre outras.
Nesse contexto, é pertinente que as empresas categorizem as informações 
conforme suas necessidades e prioridades, classificando-as como informações 
públicas, internas, confidenciais e secretas, conforme leciona Laureano (2005 apud 
CUNHA, 2012).
1. Pública: é o tipo de informação que demanda menos trabalho de segurança; 
isso porque uma informação pública é aquela cuja integridade não é vital e que 
pode ser de senso comum, dentro e fora da empresa, sem prejudicar o negócio.
2. Interna: é o segundo tipo de informação que exige menos trabalho de segurança. 
Para informações internas, o sigilo deve ser mantido, e devem ser impostas 
restrições de acesso; contudo, os danos causados por um acesso não autorizado 
não são demasiadamente sérios. A integridade da informação interna é 
importante, mesmo que não seja vital.
3. Confidencial: esse tipo de informação deve ser mantido nos limites da empresa; 
por isso, devem ser investidos esforços de segurança nessas informações. O 
acesso não autorizado, o dano ou a perda desse tipo de informação pode 
trazer prejuízos e levar ao desequilíbrio operacional. Além disso, pode ocorrer 
uma quebra de confiabilidade perante o cliente, além de permitir vantagem 
expressiva ao concorrente.
4. Secreta: essas informações são críticas para a empresa; elas devem ser 
preservadas, e deve ser investido nelas o maior esforço possível para a 
sua segurança. O acesso a esse tipo de informações deve ser restrito, e sua 
manipulação deve ser extremamente cuidadosa.
De acordo com a ISO 27001, essa classificação deve ser feita em um 
contexto organizacional, e não setorial. Portanto, ao classificar uma informação, 
devem ser levados em conta todos os setores da empresa, e não apenas o setor ao 
qual, a princípio,essa informação pertence. No entanto, muito frequentemente, 
uma organização pode ter dois esquemas de classificação diferentes, no caso de 
trabalhar tanto com o setor governamental quanto com o privado.
A norma ISO 27001 fala sobre a gestão da segurança da informação. Nessa 
norma estão descritos conceitos, práticas e informações sobre segurança da informação e, 
inclusive, sobre a classificação da informação. Saiba mais sobre a ISO 27001 acessando o 
link ou código a seguir: https://goo.gl/2qnTiB.
 
NOTA
https://goo.gl/2qnTiB
8
Neste tópico, você aprendeu que:
RESUMO DO TÓPICO 1
• É possível identificar a importância e o valor da informação no contexto 
organizacional e sua importância para os profissionais que desejam trabalhar 
na área de segurança, bem como para as equipes gestoras das empresas. 
• Existem conceitos sobre o valor da informação no contexto organizacional.
• As fases do ciclo de vida da informação representam os momentos em que a 
informação pode estar sob ameaça e, por isso, sua segurança demanda maior 
atenção.
• É possível descrever a classificação das informações (pública, interna, 
confidencial, secreta).
9
1 Em uma empresa, a informação é uma ferramenta-chave que está diretamente 
associada ao seu sucesso ou insucesso. Você é gestor de uma grande empresa 
do setor calçadista e precisa preocupar-se em garantir a manutenção e a 
rentabilidade de seu negócio. Assim, analise as seguintes informações e 
classifique-as de acordo com o seu grau de criticidade, justificando a sua 
resposta:
a) Design de novos sapatos. 
b) Código utilizado para formulação da tinta que colore uma 
 determinada linha de sapatos. 
c) Número de funcionários da empresa. 
d) CNPJ da empresa. 
e) Tecnologia inovadora que está sendo inserida para melhorar o 
 amortecimento de sapatos da linha esportiva. 
f) Calendário de datas de lançamentos de novos produtos.
2 Os ativos de informação são considerados os meios que a empresa utiliza 
para armazenar, processar e transmitir as informações, incluindo a própria 
informação. Diante disso, analise os itens a seguir:
I- Sistemas operacionais.
II- Sala-cofre.
III- Banco de dados.
IV- Documentação de sistemas.
V- CNPJ da empresa .
Sobre quais opções representam o ativo de informação, assinale a alternativa 
CORRETA:
a) ( ) I e II.
b) ( ) II e II
c) ( ) I, II e III
d) ( ) II e IV.
e) ( ) III e IV.
3 A informação deve ser protegida por todo o seu ciclo de vida, pois ela 
passa por transformações durante este período. Assim, informações que 
eram confidenciais na concepção de um projeto, com o término deste, podem 
ser patenteadas, tornando-se, assim, informações públicas. Desse modo, o 
ciclo de vida das informações é dividido em quatro etapas. Sobre as quatro 
etapas do ciclo de vida da informação, assinale a alternativa CORRETA.
AUTOATIVIDADE
10
a) ( ) Manuseio, armazenamento, transporte e descarte.
b) ( ) Criação, alteração, manutenção e exibição.
c) ( ) Descarte, manutenção, transporte e armazenamento.
d) ( ) Manuseio, armazenamento, descarte e criação.
e) ( ) Manuseio, armazenamento, transporte e descarregamento.
4 A Segurança de Informação protege a informação de diversos tipos de 
ameaças para garantir a continuidade dos negócios, minimizar os danos e 
maximizar o retorno de investimentos e as oportunidades de negócio. A 
Segurança da Informação é composta por três conceitos básicos. Assinale a 
alternativa que indica corretamente esses três conceitos básicos.
a) ( ) Disponibilidade, integração e confidencialidade.
b) ( ) Integridade, disponibilidade e confiança.
c) ( ) Confidencialidade, integridade e disponibilidade.
d) ( ) Confiabilidade, disponibilidade e integridade.
e) ( ) Segurança, integridade e confidencialidade.
5 Existem vários tipos de sistemas de informações e cada um pode atender 
a uma necessidade específica da empresa. Os sistemas de informações 
podem se dividir em quatro grupos. Assinale a alternativa que indica 
corretamente os quatro grupos.
a) ( ) Sistemas de nível operacional, conhecimento, gerencial e estratégico.
b) ( ) Sistemas de nível gestacional, gerencial, conhecimento e estratégico.
c) ( ) Sistemas de nível gerencial, informação, operacional e estratégico.
d) ( ) Sistemas de nível gerencial, conhecimento e operacional e integrador.
e) ( ) Sistemas de nível estratégico, operacional, gerencial e conhecimento.
11
TÓPICO 2
QUALIDADE DE SOFTWARE – MÉTODOS DE 
DESENVOLVIMENTO SEGUROS
UNIDADE 1
1 INTRODUÇÃO
Ao adquirir um produto ou serviço, o cliente deseja que esse produto 
seja entregue em pleno funcionamento, de acordo com aquilo que foi solicitado 
e livre de falhas. No contexto de software, essa realidade é exatamente a mesma: 
quando o cliente solicita um software, cria-se uma expectativa e, por isso, faz-se 
necessário garantir que o software atenda a ela.
O produto deve ser entregue em funcionamento e deve atender aos 
requisitos solicitados pelo cliente. O responsável pela garantia dessa entrega 
eficaz é o setor de qualidade de software. A qualidade de software atua em dois 
segmentos distintos: qualidade de produto e qualidade de processo. 
Neste tópico, você vai estudar os conceitos fundamentais desses dois 
segmentos, bem como conhecer os benefícios da qualidade de software e como 
aplicá-la nos projetos de desenvolvimento de sistemas.
2 CONCEITOS
A palavra qualidade parece ter um significado bastante óbvio, contudo, 
trata-se de um elemento complexo e de difícil mensuração, dado que a qualidade 
é relativa e pode assumir diversos valores, de acordo com a pessoa que a observa. 
Nesse sentido, a qualidade do software pode ser medida de acordo com o 
quanto ele está em conformidade com o que o cliente solicitou, ou seja, mensura-se 
se o software está em conformidade com os requisitos funcionais e não funcionais 
especificados explicitamente pelo cliente, conforme leciona Basu (2015). 
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
12
Façamos uma analogia: suponha que você tenha preferência por chocolate 
do tipo meio amargo, e seu irmão tenha preferência por chocolate ao leite; ao chegar em 
casa, se seu pai trouxer um chocolate ao leite, muito provavelmente seu irmão dirá que 
esse chocolate é de alta qualidade, enquanto você dirá que o chocolate não tem qualidade, 
porque não atende ao seu gosto, a sua expectativa.
NOTA
Embora a qualidade do software seja uma prática recente, que ganhou 
evidência com o advento da tecnologia, a qualidade, no geral, é uma preocupação 
bem antiga. Existem registros de que há mais de quatro mil anos os egípcios 
estabeleceram um padrão de medida para realizar seus trabalhos de forma 
apurada, chamado de cúbito, que equivalia ao tamanho do braço do faraó 
reinante, conforme Koscianski e Soares (2007). 
Entretanto, mesmo a qualidade sendo um conceito tão antigo, os projetos 
de software contam com vários desafios para entregar o software em perfeito 
funcionamento, devido a uma série de fatores — em especial, a complexidade. Isso 
porque construir um sistema envolve diversas habilidades, como comunicação e 
interpretação, para conseguir entender o que o cliente deseja, além de habilidades 
específicas para as etapas de programação, análise da qualidade, entre outras, 
que são de grande complexidade. 
Dada a multidisciplinariedade envolvida no processo de desenvolvimento 
de software e a complexidade de todo o processo, o segmento de qualidade se 
divide em duas áreas relacionadas, porém distintas: qualidade de processos e 
qualidade de produtos. 
A área de qualidade de processos trata da organização sistemática 
dos processos da empresa, visando ao melhor andamento dos projetos de 
desenvolvimento de sistemas, otimizando o tempo, tornando os processos 
repetitivos e evitando problemas em situações críticas para os projetos, por 
exemplo: estimativa, custo, entrada e saída de recursos humanos. 
Ao buscargarantir a qualidade de um software, estamos diante do desafio 
de estabelecer uma cultura de não tolerância a erros, por meio de processos que 
objetivem inibir ou impedir falhas, segundo Bartié (2002). 
É a área de qualidade de processos que se responsabiliza pela definição 
da metodologia ou do ciclo de vida de software que a equipe utilizará, podendo 
optar, por exemplo, por trabalhar com métodos ágeis ou métodos tradicionais. 
Independentemente da metodologia escolhida, o importante é que um processo 
seja seguido, para que a equipe tenha um padrão para se basear. Isso melhora a 
comunicação e influência na qualidade dos produtos desenvolvidos pela equipe.
 
TÓPICO 2 | QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS
13
A área de qualidade de produtos tem por objetivo garantir a qualidade 
do produto tecnológico gerado durante o ciclo de desenvolvimento. Para esse 
fim, são realizadas atividades com o objetivo de estressar as funcionalidades do 
sistema, identificando o comportamento dele nesse contexto. 
Essas atividades são chamadas de testes de software. Essa área possui 
algumas divisões, sendo a mais importante a subdivisão entre testes que fazem 
uso do código-fonte do programa, chamados de caixa branca, e testes que não 
fazem uso do código- -fonte do programa, chamados de caixa preta. Além disso, 
os testes podem ser feitos de forma manual ou automatizada e fazendo uso das 
mais diversas técnicas, conforme Bartié (2002). 
A eficiência de um processo de testes é afetada diretamente por alguns 
fatores, que devem ser considerados para evitar problemas nas organizações, 
aponta Bartié (2002): falta de planejamento das atividades de testes, ausência de 
testes que validem funcionalidades antigas e ausência de processos de automação 
de testes. Uma terminologia bastante importante e comum na área de testes de 
qualidade de software é o conceito de bug, que abrange erros, defeitos e falhas.
Por curiosidade, o termo bug corresponde à palavra inseto em inglês e 
começou a ser utilizado justamente quando um inseto causou uma falha em um 
equipamento. É importante entender que os termos erro, defeito e falha se referem 
a coisas distintas. Defeito é um comportamento inesperado de um produto. 
O defeito está em uma parte do produto e, em geral, refere-se a uma 
funcionalidade que está implementado no código de maneira incorreta. Erro é 
aquilo que foi cometido pelo programador e que gerou um código defeituoso, 
enquanto a falha se dá quando o programa defeituoso é executado e interfere no 
funcionamento do sistema para o usuário final. 
Falhas também podem ocorrer por fatores externos ao programa, como 
corrupção de bases de dados ou invasões de memória por outros programas, 
conforme Koscianski e Soares (2007). Considere, por exemplo, o código a seguir, 
conforme Koscianski e Soares (2007):
a = input ();
c = b/a;
d = a ? b/a : 0;
A linha de código que calcula o valor para a variável c pode apresentar 
um problema, dado que não é feita uma verificação para validar se o valor de a é 
0. Dessa forma, pode acontecer um erro ao tentar realizar uma divisão por zero. 
O comportamento anormal do programa, que provavelmente gera um bug ou 
uma interrupção da execução, é provocado pela divisão b/a. Em um primeiro 
momento, podemos dizer que essa linha de código é defeituosa.
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
14
Existe, entretanto, outra hipótese: o defeito pode estar na rotina input 
(). Imagine que a especificação dessa rotina estabeleça que ela não deve jamais 
retornar um valor nulo. Nesse caso, o erro foi cometido pelo programador 
responsável por essa rotina. Essa segunda hipótese é bastante razoável, pois, para 
a maioria dos programas, não é recomendado preceder cada operação de divisão 
com um teste if.
Nesse caso, um erro cometido pelo programador na rotina input fez com 
que o programa apresentasse um defeito ao executar a divisão de a por b.
3 BENEFÍCIOS
Inúmeros são os benefícios que as empresas podem ter ao demandar uma 
atenção especial para a área de qualidade de software. Os benefícios vão muito 
além de valores financeiros, podendo estar relacionados inclusive com evitar 
transtornos legais ou preservar vidas. 
Empresas que desenvolvem sistemas de semáforos têm uma responsabilidade 
muito grande, uma vez que um erro de programação pode causar um grande acidente de 
trânsito ou, na melhor das hipóteses, um transtorno no trânsito
NOTA
É por isso que o controle de qualidade é totalmente importante e benéfico 
nos dias atuais. A qualidade de software possui diversos benefícios que ajudam 
os usuários a não sofrerem com falhas de software e as empresas a oferecerem 
produtos melhores, impedindo até mesmo grandes catástrofes. Vamos verificar 
alguns dos benefícios da qualidade de software, com base em Basu (2015):
1. Economiza dinheiro — quanto dinheiro um projeto de software defeituoso 
lhe custa? Custa usuários e clientes. E é bem sabido que, quanto mais tempo 
leva para um bug ser detectado em seu software, mais difícil e caro é consertá-
lo. Ao empregar testes de controle de qualidade durante o processo de 
desenvolvimento do software, você economizará tempo e dinheiro após a 
implantação. 
2. Impede emergências corporativas catastróficas — com o software corporativo, 
as apostas são ainda maiores. Bugs no software corporativo podem levar a 
blecautes do sistema, falta de dados e falhas de comunicação. Se você estiver 
empregando software em toda a empresa ou lidando com informações 
confidenciais, é melhor ter certeza de que o software funcionará exatamente 
como ele precisa funcionar. Não há margem para erro. 
TÓPICO 2 | QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS
15
3. Inspira a confiança do cliente — ao tornar o teste de software de controle de 
qualidade uma prioridade clara para o desenvolvimento de software, você está 
enviando uma mensagem para seus clientes de que deseja que o software deles 
seja o mais bem-sucedido possível. Isso é extremamente importante quando 
você busca oferecer qualidade e criar relacionamentos de longo prazo. 
4. Mantém o nível de experiência do usuário elevado — está se tornando cada 
vez mais claro hoje em dia que a experiência do usuário pode quebrar ou 
impulsionar um negócio. Se o software estiver com problemas ou estiver lento, 
isso impedirá a experiência do usuário com o produto. Má experiência do 
usuário resulta em insatisfação e frustração. A boa experiência do usuário, que 
você obtém quando testa meticulosamente um produto de software, resulta em 
um usuário satisfeito — que tem muito mais probabilidade de recomendar o 
produto e sua empresa a outras pessoas. 
5. Traz mais lucro — se você está criando um software para comercializar ou 
vender, investir em qualidade de software significa que você pode vender seu 
produto a uma taxa maior. Não há nada pior do que um usuário irritado que 
pagou por um produto que não funciona. 
6. Aumenta a satisfação do cliente — relacionado ao ponto anterior, esse benefício 
está focado na reputação que a satisfação do cliente traz à sua empresa, não 
apenas no lucro. Ao oferecer um software de qualidade, que funciona quando 
e como você quer que ele funcione, você estará aumentando sua reputação, 
produzindo clientes satisfeitos. Não sobrecarregue a paciência dos seus clientes 
com um software defeituoso, que você precisa consertar constantemente. Dê-
lhes qualidade desde o início, e eles lhe recompensarão com lealdade. 
7. Promove organização, produtividade e eficiência — o que você menos deseja 
é o caos de um software defeituoso, uma comunicação frenética e correções 
apressadas. Ser organizado com o teste de controle de qualidade, desde o início 
de sua estratégia de desenvolvimento, permitirá que você trabalhe em paz e 
seja mais produtivo com seu tempo. Ao utilizar metodologias ágeis, nas quais 
os desenvolvedores de software criam e entregam pequenos trechos de um 
produto em uma linha do tempo clara, você podecomeçar a testar o software à 
medida que ele é criado, em vez de sempre esperar até o final.
Existe uma regra que vigora desde os princípios do teste de software, 
chamada regra 10 de Myers. Essa regra estipula que o custo de encontrar um 
defeito no sistema aumenta 10 vezes a cada etapa do processo em que esse 
erro avançar, conforme aponta Myers (1979). Essa regra é mais aplicada para o 
contexto de projetos com ciclo de vida em cascata, em que as etapas são executadas 
sequencialmente, dado que, em equipes ágeis, não existe essa divisão exata de 
etapas. A Gráfico 1 ilustra essa regra.
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
16
GRÁFICO 1 – REGRA 10 DE MYERS
FONTE: Os autores
4 APLICANDO A QUALIDADE DE SOFTWARE
Conforme vimos anteriormente, a área de qualidade de software pode ser 
dividida em qualidade de produtos e qualidade de processos e é uma importante 
área no desenvolvimento de sistemas. Para a garantia da qualidade de processos, 
as empresas podem buscar certificações. Essas certificações fazem com a empresa 
seja, de certa forma, obrigada a seguir um processo que implemente a qualidade 
de processos de forma prática. As principais certificações são CMMI e MPS.BR.
O CMMI, sigla para Capability Maturity Model Integration, é um modelo 
de maturidade utilizado para medir a maturidade dos processos de uma empresa. 
Ele serve também como um guia para a melhoria dos processos das organizações. 
Esse modelo classifica as empresas em cinco níveis, conforme Koscianski e Soares 
(2007), sendo eles:
• Inicial: processos caóticos; em geral, não existe um ambiente propício para o 
desenvolvimento de software.
• Gerenciado: nesse nível, já é perceptível uma melhoria em relação ao nível 
1. Aqui já existem requisitos gerenciados e processos planejados, medidos e 
controlados.
• Definido: nesse nível, a maturidade da empresa já está em um nível 
considerável. Aqui os processos são caracterizados e entendidos.
• Gerenciado quantitativamente: nesse nível, os processos são controlados 
usando métodos estatísticos e outras técnicas quantitativas.
• Otimizado: nesse nível, os processos são continuamente melhorados com 
base em análises feitas pela equipe.
TÓPICO 2 | QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS
17
O MPS.BR — sigla para Melhoria do Processo de Software Brasileiro — 
também é um modelo de maturidade, similar ao CMMI e com o mesmo objetivo. 
O MPS.BR foi proposto no Brasil e é utilizado por empresas brasileiras. Esse 
modelo considera seis níveis, sendo eles:
• A: processo em otimização.
• B: processo gerenciado quantitativamente.
• C: processo definido.
• D: processo largamente definido.
• E: processo parcialmente definido.
• F: processo gerenciado.
• G: processo parcialmente gerenciado.
Já para a qualidade de produto, diversas são as técnicas que podem ser 
empregadas. A área de testes de software é bastante abrangente e completa, 
sendo sempre recomendado que o trabalho de testes seja feito em conjunto com o 
desenvolvedor e durante o desenvolvimento do sistema, isto é, sem esperar que 
o sistema seja concluído para, então, testar. Vamos falar aqui de alguns tipos de 
testes e como aplicá-los, com base em Graham et al. (2008):
Teste unitário — é um tipo de teste realizado diretamente no código fonte 
do programa em teste. Nesse tipo de teste, são criadas funcionalidades de testes 
que validam o comportamento dos métodos ou funções implementadas pelo 
programador. No teste unitário, são identificados os primeiros erros e, quando 
obtido sucesso nos testes (ou seja, quando não forem localizadas falhas), as 
funcionalidades principais do programa devem estar funcionando. Um exemplo 
de técnica para teste unitário é o TDD — test driven development —, que tem 
por objetivo o desenvolvedor criar primeiro o código de teste, para depois criar a 
funcionalidade e, então, executar o teste que valida essa funcionalidade.
Teste funcional — é um tipo de teste realizado após o desenvolvimento 
do sistema ou de um módulo do sistema. O teste funcional pode ser automatizado 
ou manual. No caso de teste automatizado, são utilizados scripts de teste, que 
simulam o comportamento de um usuário no sistema, por exemplo, clicando em 
botões e inserindo valores em campos, e verificam a resposta do sistema para 
esses comportamentos. Para testes automatizados, esses scripts são executados 
automaticamente, e os defeitos localizados são sinalizados também de forma 
automática. No caso de testes manuais, os scripts são substituídos por casos de 
teste. Caso de teste é um documento em que é descrita a ação do usuário e a 
resposta esperada do sistema para ela. Nesse caso, a execução do caso de teste é 
feita manualmente, e o registro dos defeitos também.
Teste de aceitação — esse teste é realizado junto com o cliente e visa 
a verificar se o sistema que foi ou está sendo construído é realmente o que foi 
solicitado.
Teste exploratório — esse tipo de teste é muito comum, mais rápido de 
ser realizado e se torna uma alternativa para projetos com cronograma apertado. 
Nesse tipo de teste, o testador usa a sua experiência para navegar no sistema 
visando a localizar erros. A principal vantagem desse tipo de testes é localizar 
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
18
defeitos que não seriam localizados nos demais testes; por exemplo, casos em que 
o usuário tem um comportamento incomum, como clicar duas vezes em um botão 
de salvar. Para organizar esses testes e garantir que as funcionalidades principais 
sejam testadas, é comum criar um checklist, que nada mais é do que uma lista que 
registra os principais pontos que devem ser testados nas telas do sistema.
Leitura recomendada: LEWIS, W. E. Software testing and continuous quality 
improvement. Boca Raton: CRC Press, 2016. 
DICAS
19
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
• A área de qualidade de software pode ser dividida em qualidade de 
produtos e qualidade de processos e é uma importante área no desenvolvimento 
de sistemas.
• É possível identificar os benefícios da qualidade de software.
• É possível realizar a aplicação dos conceitos de qualidade.
• É importante conhecer alguns tipos de testes e sobre a maneira de aplicá-los.
• Conhecer alguns modelos de maturidade é importante para classificar as 
empresas em níveis.
• Os diversos benefícios da segurança e qualidade de software ajudam os 
usuários a não sofrerem com falhas de software.
20
1 Um dos grandes problemas que traz transtornos para as empresas 
desenvolvedoras de software é a presença de bugs no sistema. Isso porque 
eles afetam a satisfação do cliente com o sistema. Analise as alternativas a 
seguir e assinale a que define corretamente erro, defeito e falha:
a) ( ) João é programador e inseriu por engano uma função infinitamente 
recursiva. João cometeu uma falha que pode prejudicar a empresa.
b) ( ) Por causa da atitude errônea de João (que inseriu por engano uma 
função infinitamente recursiva no programa), quando Ana efetuou 
testes unitários no código fonte, ela identificou um defeito (uma linha 
defeituosa) no código.
c) ( ) Juca é usuário do sistema e, ao cadastrar uma nova nota fiscal, 
deparou-se com um erro no software.
d) ( ) Pedro estava fazendo um teste unitário no sistema e descobriu que 
Antônio cometeu uma falha, efetuou a declaração de uma variável 
com o tipo de dado errado.
e) ( ) Lucas, usuário do sistema, deixou um campo em branco ao cadastrar 
um novo usuário para o sistema e fez com que o sistema travasse. 
Lucas estava diante de um erro de software.
2 A área de qualidade de software é a principal responsável por garantir a 
satisfação do cliente para com o software que foi entregue, desta forma, 
essa área se preocupa não apenas em entregar o software funcionando, mas 
em entregar o software em conformidade com os requisitos estabelecidos 
pelo cliente. Para ajudar nesse processo de garantia da qualidade, a área 
dequalidade de processos norteia a organização da estrutura de trabalho 
da empresa. Sobre qualidade de processos, classifique V para as sentenças 
verdadeiras e F para as falsas:
( ) CMMI e ISO9001 são modelos de maturidade que fornecem informações 
para os funcionários sobre como fazer o seu trabalho de forma eficiente.
( ) Um exemplo de processo que pode ser utilizado para garantia da 
qualidade de processos são as metodologias rápidas.
( ) A utilização de ciclo de desenvolvimento em cascata garante que a 
empresa atingirá o nível máximo de maturidade no CMMI.
( ) Um dos critérios para ser promovido em nível de maturidade é a 
comunicação eficiente e, por isso, o uso de metodologias ágeis é um pré-
requisito.
( ) O nível V do CMMI é o último nível de maturidade, ele considera que 
todos os processos já estão definidos e são seguidos pela empresa, estando 
em constante otimização.
AUTOATIVIDADE
21
Assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) V – F – V – V – F.
b) ( ) V – F – V – F – F.
c) ( ) F – F – V – V – V.
d) ( ) F – F – F – F – V.
3 A regra 10 de Myers estima que o prejuízo causado por um defeito no 
sistema aumenta 10 vezes a cada etapa do processo de desenvolvimento que 
é avançado. Desta forma, é de extrema importância encontrar precocemente 
os defeitos antes que estes se tornem falhas e sejam visíveis para o cliente. 
Esta é uma função do segmento de qualidade de produto. Sobre qualidade de 
produto, analise as alternativas a seguir e assinale a alternativa CORRETA:
a) ( ) É parte da atribuição do segmento de qualidade de produto realizar 
junto ao cliente uma verificação antes da entrega do software para 
garantir que o software entregue está de acordo com o solicitado.
b) ( ) O profissional que trabalha com qualidade de produto, também 
chamado de QP, tem, entre suas funções, que garantir que o 
desenvolvimento do produto seja feito de acordo com uma 
metodologia, como, por exemplo, metodologia ágil Scrum.
c) ( ) A realização de testes de software só é possível após o final do 
desenvolvimento do produto, isto porque é necessário que toda a 
funcionalidade tenha sido desenvolvida para poder testá-la.
d) ( ) A qualidade de produto não interfere na confiança do cliente, esta é 
uma responsabilidade burocrática aliada à qualidade de processos.
e) ( ) O teste exploratório deve ser sempre o primeiro teste a ser realizado, 
ainda durante o processo de desenvolvimento, pelo programador.
4 Os modelos CMMI e MPS-BR têm por objetivo auxiliar as empresas na 
organização de seus processos e avaliar a maturidade a qual os processos 
das empresas se encontram. Sobre esses dois modelos, assinale a alternativa 
CORRETA:
a) ( ) Pode-se dizer que uma empresa que utiliza métodos ágeis de 
desenvolvimento de sistemas é automaticamente mais madura do que 
uma empresa que utiliza métodos tradicionais.
b) ( ) O modelo MPS-BR pode ser considerado uma extensão do CMMI, 
uma vez que ele replica os níveis do CMMI complementando os níveis 
intermediários.
c) ( ) Processo largamente definido é um nível de maturidade do modelo 
CMMI.
d) ( ) O modelo CMMI é utilizado apenas dentro do Brasil, embora tenha 
sido criado fora.
e) ( ) Tanto o CMMI quanto o MPS-BR são ferramentas para organização de 
processos empresariais.
22
5 A qualidade da entrega dos produtos é fundamental para a fidelização do 
cliente e o ganho de confiança. Isso se aplica para software e para qualquer 
outro produto ou serviço que seja fornecido por uma empresa para clientes. 
Diante disso, analise as afirmativas a seguir:
I- Embora conquistar o cliente seja bastante importante para a empresa 
fornecedora de software, caso este cause danos financeiros ao cliente, não 
é responsabilidade da fornecedora.
II- A regra 10 de Myers se aplica ao modelo ágil de desenvolvimento de 
sistemas.
III- A regra 10 de Myers considera que o custo de um defeito localizado 
aumenta 100 vezes a cada etapa avançada no ciclo de desenvolvimento.
IV- Um dos benefícios aliados à qualidade de usuário é melhorar a experiência 
deste.
V- Qualidade de software é útil apenas em momentos de catástrofes.
No que se refere a importância da qualidade de software, assinale a alternativa 
CORRETA:
a) ( ) I e II.
b) ( ) II, III e V.
c) ( ) I e IV.
d) ( ) I, II e III.
e) ( ) Somente opção IV.
 
6 Testes de software são uma atividade de extrema importância para a garantia 
da qualidade do produto de software. Diversos tipos de testes podem 
ser realizados, sejam estes feitos diretamente no código fonte do software ou 
por meio da execução do software que está sendo testado. 
 Um dos tipos de teste que podem ser executados é o exploratório. Esse tipo 
de teste se baseia no conhecimento do testador do negócio da empresa, de 
forma que o testador irá explorar o sistema buscando por falhas. Para suportar 
esse trabalho de busca exploratório de erros, podem ser criados checklists, 
estes garantem que as principais funcionalidades serão testadas e que todas 
as validações necessárias serão feitas. 
Após ler essas informações, avalie a situação a seguir:
23
FONTE: Os autores
Agora, com base na análise realizada, elabore um checklist que possa ser usado 
para validação dessa tela e reaproveitado para outras telas que você testar no 
futuro.
24
25
TÓPICO 3
QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE
UNIDADE 1
1 INTRODUÇÃO
Não é viável falar de qualidade sem falar de processos. Processos de 
software são complexos e compostos por um número muito grande de atividades 
e características. Esses processos têm sido aliados no desenvolvimento de software 
de qualidade e, além disso, auxiliam na redução de problemas relacionados ao 
suporte, ao treinamento e às revisões, no aprendizado organizacional e, também, 
na economia, pois o esforço e o tempo de projetos podem ser reduzidos. 
Neste tópico, você estudará sobre a qualidade do processo de software, a 
qualidade do produto de software e vai aprender a definir o processo de garantia 
da qualidade e processos como revisões e inspeções em softwares.
2 QUALIDADE DE PROCESSO E QUALIDADE DE PRODUTO
A qualidade de um processo de desenvolvimento está diretamente ligada 
à qualidade de um produto. Com o desenvolvimento de software não é diferente, 
mas esse é um processo mais criativo do que mecânico e ainda é necessário 
contar com as habilidades individuais e fatores externos, como, por exemplo, as 
novidades tecnológicas. Assim, processos de software são complexos e englobam 
um número muito grande de atividades e características (Quadro 1). 
26
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
QUADRO 1 – CARACTERÍSTICAS DOS PROCESSOS
FONTE: Adaptado de Sommerville (2011)
No entanto, manter processos atualizados e revisados pode ser a garantia 
de um produto de qualidade e de satisfação do cliente. Segundo Sommerville 
(2011), para um gerenciamento de qualidade de processo, é necessário envolver:
• definição de padrões de processo, como “quando” e “como” as revisões 
devem ser conduzidas. 
• monitoramento do processo do desenvolvimento para assegurar que os 
padrões estão sendo seguidos. 
• relato do processo de software para a gerência de projeto e para o comprador 
do software.
Para um gerenciamento efetivo, os padrões de qualidade são muito 
importantes e podem ser internacionais, nacionais, organizacionais ou de projeto. 
Os padrões de produto definem as características que os componentes devem ter, 
por exemplo, um estilo de programação. Já os padrões de processos vão definir 
como o processo de software deve ser instituído. A utilização desses padrões 
evita a repetição de erros e, também, auxilia na continuidade, caso a produção 
do produto seja continuada por outros membros da equipe. Veja, na Tabela 1, os 
padrões de produto e de processo.
TÓPICO 3 | QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE
27
TABELA 1 – PADRÕES PARA PRODUTOS E PROCESSOS
FONTE: Adaptado de Sommerville(2011)
A qualidade do processo de software, além do foco no aumento da 
qualidade do produto, visa, também, diminuir o retrabalho e aumentar a 
produtividade.
Para implantar um programa de qualidade, é necessário implantar um 
processo de software que deve ser documentado, compreendido e seguido por 
todos na organização.
3 GARANTIA DA QUALIDADE DE SOFTWARE
A garantia da qualidade de software é um padrão sistemático e planejado 
de ações que são impostas para garantir essa qualidade. Esse padrão busca 
produzir softwares com a menor taxa de defeitos, utilizando procedimentos, 
modelos, padrões e investimento na equipe a garantia tem natureza proativa. 
A garantia visa, também, o gerenciamento e a melhoria dos processos 
existentes por meio do aprendizado em cada projeto realizado. O controle da 
qualidade tem como objetivo evitar que produtos defeituosos sejam entregues aos 
clientes, tem ação reativa e objetiva o monitoramento do processo, a detecção e a 
correção dos defeitos. Para garantir a qualidade, algumas ações são necessárias:
• aplicar modelos técnicos — esses modelos ajudam o analista a adquirir uma 
especificação de qualidade e ajudam o projetista a desenvolver um projeto de 
qualidade;
• aplicar padrões e procedimentos formais — essa etapa se refere à aplicação de 
padrões nos processos de engenharia de software; 
• anotar e manter registros — ações de coleta e disseminação de informações de 
garantia de qualidade de software.
O processo de garantia da qualidade contempla:
28
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
• a revisão dos produtos intermediários em comparação com os requisitos de 
qualidade preestabelecidos; 
• a revisão das atividades comparando com os planos preestabelecidos, que 
podem ser, entre outros: 
 ○ plano de projeto; 
 ○ plano de documentação; 
 ○ plano de monitoração de riscos.
Para avaliar os requisitos de qualidade do produto e se eles estão de 
acordo com os planos, é necessário aplicar as revisões e os testes.
4 REVISÕES E INSPEÇÕES EM SOFTWARE
A inspeção de software é realizada por pessoas que verificam o software 
com o objetivo de descobrir possíveis defeitos. Essas inspeções podem ser feitas, 
por exemplo, nos requisitos, no projeto, nos dados de configuração, nos dados 
de testes e são bastante utilizadas para descobrir erros no programa. Quando o 
software está em fase de teste, um defeito pode ser encoberto por outro e, para 
evitar que isso ocorra, vários testes e execuções são necessários.
Alguns defeitos são recorrentes em software. Nessa hora, o conhecimento 
em programação faz diferença para processos de detecção e correção mais rápidas. 
Durante o processo de validação e verificação, são utilizados as inspeções e os 
testes, que são técnicas complementares. 
As inspeções verificam a conformidade com uma especificação do 
software, mas não verificam a não conformidade com os requisitos reais do 
cliente e nem características não funcionais, como, por exemplo, desempenho, 
usabilidade e adaptabilidade. Para inspeções em programas, é necessária uma 
abordagem mais formalizada, que contenha todas as revisões efetuadas, não só a 
título de controle, mas também para histórico e comprovação. 
Essas estão relacionadas à detecção de defeitos que podem ser erros 
lógicos, erros de sintaxe, erro na lógica de programação e, até mesmo, de não 
conformidade com os padrões definidos, mas não estão relacionadas com a 
correção deles. Para realizar a inspeção, as condições para que esse processo 
ocorra precisam estar disponíveis, bem como os padrões organizacionais que são 
seguidos e utilizados. 
Conforme os erros são encontrados e reparados, deverão ser inseridos 
em um checklist, embora esse não deva ser usado a título de penalidade aos 
que cometeram o erro e nem para avaliação de competência da equipe. Para a 
inspeção, Sommerville (2011) indica o processo demonstrado na Figura 2.
TÓPICO 3 | QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE
29
FIGURA 2 – PROCESSO DE INSPEÇÃO
FONTE: Adaptado de Sommerville (2011)
Nesse processo:
• o planejamento discute como será feita a inspeção; 
• a visão geral apresenta o sistema para a equipe que realizará a inspeção; 
• na preparação, o código e a respectiva documentação são apresentados para 
a equipe que realizará a inspeção; 
• a reunião de inspeção ocorre quando os erros descobertos são anotados no 
checklist; 
• na etapa retrabalho, as modificações são feitas para reparar os erros 
encontrados; 
• na etapa acompanhamento, uma nova inspeção é realizada se for necessário.
Veja, na Tabela 2, os papéis que os participantes da inspeção apresentam 
(SOMMERVILLE, 2011).
TABELA 2 – PAPEIS NA INSPEÇÃO
FONTE: Adaptado de Sommerville (2011)
30
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
5 REVISÕES TÉCNICAS FORMAIS 
As atividades de controle de qualidade de software que são realizadas 
por engenheiros de software são denominadas revisão técnica formal ou RTF. 
Segundo Pressman e Maxim (2016), os objetivos de uma RTF são: 
• descobrir erros na função, na lógica ou na implementação; 
• verificar se o projeto que está sendo revisado atende aos requisitos do cliente; 
• garantir que o software está de acordo com os padrões predefinidos; 
• tornar os projetos mais gerenciáveis
6 DIRETRIZES DE REVISÃO
As revisões devem ter foco no produto, e não nas pessoas. Apontar erros 
não deve ser uma prática dentro das revisões formais; caso contrário, as reuniões 
de revisão podem causar desconforto na equipe, inclusive desmotivando os 
participantes. Manter uma agenda para as revisões também é uma boa prática. 
Além de manter o foco da reunião, a agenda também ajuda a manter os prazos 
estabelecidos. Para as reuniões de revisão, é interessante limitar o número de 
participantes, que devem preparar-se com antecedência. Veja a Tabela 3.
TABELA 3 – ITENS DE REVISÃO VERSUS RESULTADO ESPERADO
FONTE: Os autores
Nesse sentido, é importante destacar a diferença entre revisão, erro e 
defeito: a revisão é o filtro do processo e é utilizada para detectar erros e defeitos; 
o erro é um problema de qualidade que ocorre antes da entrega ao cliente; e o 
defeito é um problema de qualidade constatado depois da entrega ao cliente.
TÓPICO 3 | QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE
31
7 O CHECKLIST
Conforme comentado, durante a inspeção, um checklist deve ser 
alimentado com os erros encontrados. Uma prática utilizada também é um 
checklist com os erros mais comuns encontrados nos projetos anteriores a fim 
de direcionar a inspeção atual. Veja, no Tabela 4, um exemplo de verificação de 
inspeção e, na Tabela 4, um modelo de checklist.
TABELA 4 – EXEMPLO DE VERIFICAÇÃO DE INSPEÇÃO
FONTE: Adaptado de Sommerville (2011)
32
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
FIGURA 3 – MODELO DE CHECKLIST DE VALIDAÇÃO DE REQUISITOS
FONTE: Oliveira (2014, s.p.)
Leitura recomendada: STEFFEN, J. B. O que são essas tais de metodologias 
ágeis? 2012. Disponível em: https://ibm.co/2D8yddW. Acesso em: 1 nov. 2018.
DICAS
33
RESUMO DO TÓPICO 3
 Neste tópico, você aprendeu que:
• A qualidade do processo de software, além do foco no aumento da qualidade 
do produto, visa, também, diminuir o retrabalho e aumentar a produtividade.
• O processo de garantia da qualidade contempla a revisão dos produtos 
intermediários em comparação com os requisitos de qualidade 
preestabelecidos; e a revisão das atividades comparando com os planos 
preestabelecidos.
 
• A inspeção de software é realizada por pessoas que verificam o software com 
o objetivo de descobrir possíveis defeitos. Além disso, também aprendeu a 
definir revisões e inspeções em softwares.
• As atividades de controle de qualidade de software que são realizadas por 
engenheiros de software são denominadas revisão técnica formal ou RTF.
34
1 Analise as alternativas a seguir e assinale a que corresponde a um dos 
objetivos das revisões técnicas formais de software.
a) ( ) Realizar uma única reuniãoao final do projeto para avaliar se 
o software foi bem construído.
b) ( ) Realizar reuniões com os clientes para descobrir o que deve ser feito. 
Senhas complexas e firewall.
c) ( ) Documentar os requisitos solicitados.
d) ( ) Garantir que o software não tenha erros.
e) ( ) Garantir que o software atenda aos requisitos especificados.
2 Analise as alternativas a seguir e assinale a que corresponde a um objetivo 
das inspeções de software.
a) ( ) Revisões de progresso.
b) ( ) Avaliação de metas organizacionais.
c) ( ) Detecção de defeitos.
d) ( ) Revisões de cronograma.
e) ( ) Revisões de custo.
3 No que se refere à qualidade de software, as revisões, as inspeções e os 
testes realizados ao longo do processo de software para garantir que o 
produto satisfaça os requisitos estabelecidos são importantes. Sobre os itens 
mencionados, classifique V para as sentenças verdadeiras e F para as falsas:
( ) Garantia de qualidade.
( ) Custo da qualidade.
( ) Controle de qualidade.
( ) Reengenharia de processos.
Assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) F – V – F – V.
b) ( ) F – F – V – F.
c) ( ) F – F – V – V.
d) ( ) V – V – F – V.
4 No gerenciamento da qualidade, como é conhecido quando são estabelecidos 
padrões organizacionais e uma estrutura de procedimentos para condução 
de um software de qualidade?
AUTOATIVIDADE
35
a) ( ) Planejamento da qualidade.
b) ( ) Garantia da qualidade.
c) ( ) Controle da qualidade.
d) ( ) Gerenciamento da configuração.
e) ( ) Revisões de qualidade.
5 As técnicas de prototipação e de revisão de requisito são as mais utilizadas 
para:
 
a) ( ) o gerenciamento de requisitos.
b) ( ) a validação de requisitos.
c) ( ) o levantamento e a análise de requisitos.
d) ( ) o estudo de viabilidade e o desenvolvimento do sistema.
e) ( ) a especificação de requisitos.
36
37
TÓPICO 4
CONFIABILIDADE DE SOFTWARE
UNIDADE 1
1 INTRODUÇÃO
Pode-se dizer que o ciclo completo de vida de um sistema compreende duas 
fases importantes: o desenvolvimento do sistema e sua operação. A confiabilidade 
de software se refere ao desenvolvimento de um software confiável, ou seja, seus 
conceitos são tratados amplamente na fase de desenvolvimento. 
Neste tópico, você terá a oportunidade de estudar os conceitos que 
permeiam a confiabilidade de software, principalmente no que se refere às 
dimensões de confiança de software.
2 CONFIABILIDADE DE SOFTWARE
O software deve estar disponível sempre que necessário, bem como 
operar adequadamente, com segurança e confiabilidade, sem quaisquer efeitos 
colaterais adversos ou preocupações de segurança. É essencial que o software 
utilizado em sistemas críticos seja confiável, pois a consequência de uma falha 
(por exemplo, a falha em uma usina nuclear) pode resultar em um dano massivo, 
que poderá significar a perda de vidas. 
De acordo com o ANSI (1991), a confiabilidade de software é definida 
como a probabilidade de um software operar sem falhas por um período 
específico em um ambiente específico. Embora a confiabilidade de software 
seja definida como uma função probabilística e venha a sugerir uma noção de 
tempo, devemos observar que, diferentemente da confiabilidade de hardware 
tradicional, a confiabilidade de software não é uma função direta do tempo.
Peças eletrônicas e mecânicas podem se tornar “velhas” e desgastadas com 
o tempo e o uso, mas o software não enferruja ou se desgasta durante seu ciclo 
de vida. O software não será alterado com o tempo, a menos que seja alterado 
ou atualizado intencionalmente. Costumava-se acreditar que o software nunca 
se danificava. Intuitivamente, ao contrário de peças mecânicas, como parafusos, 
alavancas ou peças eletrônicas, como transistores e capacitores, o software 
permanecerá no mesmo estado, a menos que haja problemas no hardware que 
alterem o conteúdo do armazenamento ou o caminho dos dados. 
38
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
O software não envelhece, enferruja, desgasta, deforma ou racha. Além 
disso, o software não tem forma, cor, material ou massa, mas tem um papel crucial 
no funcionamento dos sistemas. A confiabilidade do software é um atributo 
importante para a qualidade do software, com a funcionalidade, a usabilidade, 
o desempenho, a capacidade de manutenção, a instabilidade e a capacidade de 
manutenção e documentação. 
A confiabilidade é difícil de atingir, porque a complexidade do software 
tende a ser alta. Embora em qualquer sistema com alto grau de complexidade 
seja difícil alcançar certo nível de confiabilidade, os desenvolvedores de sistemas 
tendem a empurrar a complexidade para a camada de software. Como exemplos 
de tendências nesse sentido, temos que:
• as aeronaves de última geração terão mais de um milhão de linhas de código-
fonte de software a bordo; 
• os sistemas de controle de tráfego aéreo da próxima geração conterão entre um 
e dois milhões de linhas; 
• a próxima estação espacial internacional terá mais de dois milhões de linhas a 
bordo e mais de dez milhões de linhas de software de suporte terrestre; 
• vários sistemas de defesa críticos terão mais de cinco milhões de linhas de 
software. 
Embora a complexidade do software esteja inversamente relacionada 
à confiabilidade do software, ela está diretamente relacionada a outros fatores 
importantes na qualidade do software, especialmente funcionalidade e capacidade. 
A ênfase nesses recursos tende a adicionar mais complexidade ao software. 
As falhas de software ocorrem devido a erros, ambiguidades, descuidos ou 
interpretações errôneas da especificação do software, descuido ou incompetência 
ao escrever o código, testes inadequados, uso incorreto ou inesperado do software, 
ou outros problemas não previstos.
É comum fazer uma analogia entre confiabilidade de software e 
confiabilidade de hardware, mas software e hardware têm características básicas 
que os tornam diferentes quanto aos mecanismos de falha. As falhas de hardware 
são principalmente falhas físicas, enquanto as falhas de software são falhas de 
projeto, que são mais difíceis de se detectar, classificar e corrigir. As falhas de 
projeto estão intimamente relacionadas a fatores humanos diversos e às fases do 
projeto mais complexas, conforme Lyu (1995). 
Com o passar do tempo, o hardware exibe as características de falha, 
conhecidas como a curva da banheira. Nessa curva, é possível identificar o período 
de vida útil do hardware ao longo do tempo. Já a confiabilidade do software não 
possui as mesmas características; uma curva de software possível é apresentada 
no gráfico a seguir, se projetarmos a confiabilidade do software nos mesmos eixos.
TÓPICO 4 | CONFIABILIDADE DE SOFTWARE
39
Existem duas grandes diferenças entre as curvas de hardware e software. 
Uma diferença é que, na última fase, o software não tem uma taxa de falhas crescente, 
como acontece com o hardware. Nessa fase, o software está se aproximando 
da obsolescência, e não fazem sentido quaisquer atualizações ou alterações no 
software. Portanto, a taxa de falha não será alterada. A segunda diferença é que, na 
fase da vida útil, o software sofrerá um aumento drástico na taxa de falhas cada vez 
que uma atualização for feita. A taxa de falha é desativada gradualmente, em parte 
devido aos defeitos encontrados e corrigidos após as atualizações.
GRÁFICO 2 – TAXA DE FALHAS DE HARDWARE AO LONGO DO TEMPO
FONTE: <https://bit.ly/2VQ6XaJ>. Acesso em: 30 jun. 2020
GRÁFICO 3 – TAXA DE FALHAS DE SOFTWARE AO LONGO DO TEMPO
FONTE: Adaptada de Hartz e Walker (1996)
Segundo Avizienis, Laprie e Randell (2001), são três os fatores que afetam 
a confiabilidade de sistemas: 
1- Falta. 
2- Erro.
3- Falha. 
40
UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE
A falta é conhecida como defeito ou bug e é considerada em estado 
dormente até a sua ocorrência. Um exemplo comum de falta é a declaração de 
uma variável como