O que é Design Patterns ?

Design Patterns

Design Patterns

Os Design Patterns ou Padrões de Projeto, como são conhecidos, são conceitos ou modelos orientados a objetos visando solucionar problemas no desenvolvimento de softwares. Estes padrões possuem finalidades particulares que podem ser aplicadas para controlar a estrutura, a criação e o comportamento das classes e dos objetos em uma aplicação. Dependendo da situação em que esses projetos forem aplicados, é possível notar uma redução considerável na complexidade do software em virtude da reutilização de código-fonte e de componentes.

Apesar de existir 23 padrões de projeto, é praticamente inviável implementar todos eles em uma única solução, afinal, utilizar padrões de projeto sem um propósito é uma má prática. É preciso haver um motivo real para a implementação, ou seja, uma situação em que se pode comprovar de que o padrão de projeto será uma solução adequada para o problema. Caso contrário, a implementação pode aumentar a complexidade do programa e afetar também o desempenho da aplicação.

Uma das dúvidas mais frequentes relacionadas a padrões de projeto é saber onde, quando e como utilizá-los. Em primeiro lugar, o engenheiro de software deve ter sólidos conhecimentos em Programação Orientada a Objetos e um bom nível de abstração, ou seja, a Orientação a Objetos é a base essencial para compreender os padrões de projeto. Em segundo lugar, é necessário conhecer o objetivo principal de cada padrão de projeto para que seja possível fazer um estudo da viabilidade para solucionar um problema no software. No entanto, mesmo com esse conhecimento técnico, é comum alguns engenheiros não conseguirem identificar as situações ou os módulos que devem receber a implementação dos padrões. Portanto, em terceiro lugar, o profissional também deve ter um domínio satisfatório da regra de negócio do cliente. A consolidação de todas essas experiências é o que permite a seleção e a aplicação consciente dos padrões de projeto no desenvolvimento do software.

Fonte: Profissionais TI

Anúncios

Crescimento do Big Data deve incentivar o surgimento de novos negócios

BIG DATAPesquisa realizada pela ABES (Associação Brasileira de Empresas de Software) e pela IDC mostra que o Big Data terá investimento de US$ 426 milhões no Brasil em 2014. O estudo também revela que as empresas estão aprimorando suas estruturas de análise de dados, mas devem enfrentar escassez de mão de obra especializada.

Além disso, o crescimento do Big Data deve incentivar o surgimento de novos negócios referentes à analytics, como empresas Data Brokers ou Analytics Providers.

O levantamento também aponta que os data centers estão em alta. A necessidade de otimização (térmica, elétrica e, principalmente, de gestão) provocará um ciclo de renovação nos data centers mais antigos. Segundo a pesquisa, a busca por Colocation e Hosting continuará, apesar do crescimento na contratação de IaaS nos próximos meses.

Falando em Big Data…

O Big Data ganhou destaque na Copa do Mundo, pois a seleção da Alemanha, campeã da competição, usou a tecnologia para customizar o treinamento de cada jogador.

O resultado inspirou outros clubes. No mês passado, o Grêmio anunciou que também aderiu ao Big Data. O conjunto de soluções tecnológicas, que também estará à disposição do juvenil, deve potencializar a formação dos atletas e da equipe.

O Bayern de Munique também levou o Big Data para os gramados. Com isso, o clube  poderá monitorar, por exemplo, comportamentos que costumam levar a lesões. Dessa forma, será possível focar na saúde e na condição física dos jogadores.

Além disso, o Big Data deverá ajudar na parte tática, mostrando o comportamento de jogadores em treinos e em jogos. Os times de base também serão beneficiados com a análise de dados.

Outras tecnologias

Atual bicampeã do Campeonato Alemão e participante da Champions League, a equipe do Bayern de Munique também usa ferramentas tecnológicas para melhorar a experiência do usuário e ampliar a presença global.

Com a ajuda das tecnologias de CRM (Gestão de Relacionamento com Cliente), o clube alemão pode personalizar a experiência do usuário com dados coletados no site do time, por exemplo, e ficar mais conectado com os milhões de torcedores ao redor do mundo.

Fonte: Stefanini

Introdução a Teste de Software

Teste de Software - IntroduçãoIntrodução a Teste de Software

Teste de software é o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. O seu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final. Por conta dessa característica das atividades de teste, dizemos que sua natureza é “destrutiva”, e não “construtiva”, pois visa ao aumento da confiança de um produto através da exposição de seus problemas, porém antes de sua entrega ao usuário final.

O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é revelar o número máximo de falhas dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.

Ao longo deste artigo, iremos discutir os principais conceitos relacionados às atividades de teste, as principais técnicas e critérios de teste que podem ser utilizados para verificação ou validação de um produto, assim como exemplos práticos da aplicação de cada tipo de técnica ou critério de teste.

Conceitos básicos associados a Teste de Software

Antes de iniciarmos uma discussão sobre teste de software precisamos esclarecer alguns conceitos relacionados a essa atividade. Inicialmente, precisamos conhecer a diferença entre Defeitos, Erros e Falhas. As definições que iremos usar aqui seguem a terminologia padrão para Engenharia de Software do IEEE – Institute of Electrical and Electronics Engineers – (IEEE 610, 1990).

  • Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto.
  • Erro é uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro.
  • Falha é o comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.

Figura 1 expressa a diferença entre esses conceitos. Defeitos fazem parte do universo físico (a aplicação propriamente dita) e são causados por pessoas, por exemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação de erros em um produto, ou seja, a construção de um software de forma diferente ao que foi especificado (universo de informação). Por fim, os erros geram falhas, que são comportamentos inesperados em um software que afetam diretamente o usuário final da aplicação (universo do usuário) e pode inviabilizar a utilização de um software.

Defeito x Erro x Falha

Figura: Defeito x Erro x Falha

Dessa forma, ressaltamos que teste de software revela simplesmente falhas em um produto. Após a execução dos testes é necessária a execução de um processo de depuração para a identificação e correção dos defeitos que originaram essa falha, ou seja, Depurar não é Testar!

A atividade de teste é composta por alguns elementos essenciais que auxiliam na formalização desta atividade. Esses elementos são os seguintes:

  • Caso de Teste: descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e JASKIEL, 2002).
  • Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste (CRAIG e JASKIEL, 2002).
  • Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto (ROCHA et al., 2001). Os critérios de teste podem ser utilizados como:
  • Critério de Cobertura dos Testes: permitem a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS e WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessários por um critério de teste que foram executados pelo conjunto de casos de teste.
  • Critério de Adequação de Casos de Teste: Quando, a partir de um conjunto de casos de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critério. Ou seja, este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função (ROCHA et al., 2001).
  • Critério de Geração de Casos de Teste: quando o critério é utilizado para gerar um conjunto de casos de teste T adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente (ROCHA et al., 2001).

Definidos os elementos básicos associados aos testes de software, iremos a seguir discutir a origem dos defeitos em um software.

Defeitos no desenvolvimento de software

No processo de desenvolvimento de software, todos os defeitos são humanos e, apesar do uso dos melhores métodos de desenvolvimento, ferramentas ou profissionais, permanecem presentes nos produtos, o que torna a atividade de teste fundamental durante o desenvolvimento de um software. Já vimos que esta atividade corresponde ao último recurso para avaliação do produto antes da sua entrega ao usuário final.
O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo são dois possíveis fatores que aumentam a complexidade dessa tarefa, e consequentemente aumentam a probabilidade de defeitos. Assim, a ocorrência de falhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa que o funcionamento do programa não está de acordo com o esperado pelo usuário. Por exemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só a gerência deveria ter acesso. Esse tipo de falha pode ser originado por diversos motivos:

• A especificação pode estar errada ou incompleta;

• A especificação pode conter requisitos impossíveis de serem implementados devido a limitações de hardware ou software;

• A base de dados pode estar organizada de forma que não seja permitido distinguir os tipos de usuário;

• Pode ser que haja um defeito no algoritmo de controle dos usuários.

Os defeitos normalmente são introduzidos na transformação de informações entre as diferentes fases do ciclo de desenvolvimento de um software. Vamos seguir um exemplo simples de ciclo de vida de desenvolvimento de software: os requisitos expressos pelo cliente são relatados textualmente em um documento de especificação de requisitos. Esse documento é então transformado em casos de uso, que por sua vez foi o artefato de entrada para o projeto do software e definição de sua arquitetura utilizando diagramas de classes da UML. Em seguida, esses modelos de projetos foram usados para a construção do software em uma linguagem que não segue o paradigma orientado a objetos. Observe que durante esse período uma série de transformações foi realizada até chegarmos ao produto final. Nesse meio tempo, defeitos podem ter sido inseridos. A Figura 2 expressa exatamente a metáfora discutida nesse parágrafo.

Diferentes Interpretações ao longo do ciclo de desenvolvimento de um software

Figura 2. Diferentes Interpretações ao longo do ciclo de desenvolvimento de um software

Essa série de transformações resultou na necessidade de realizar testes em diferentes níveis, visando avaliar o software em diferentes perspectivas de acordo com o produto gerado em cada fase do ciclo de vida de desenvolvimento de um software.

Níveis de teste de software

O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software (Figura 3). Buscando informação no Livro “Qualidade de Software – Teoria e Prática” (ROCHA et al., 2001), definimos que os principais níveis de teste de software são:

  • Teste de Unidade: também conhecido como testes unitários. Tem por objetivo explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de lógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código.
  • Teste de Integração: visa provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto.
  • Teste de Sistema: avalia o software em busca de falhas por meio da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos.
  • Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.
  • Teste de Regressão: Teste de regressão não corresponde a um nível de teste, mas é uma estratégia importante para redução de “efeitos colaterais”. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Pode ser aplicado em qualquer nível de teste.

Dessa forma, seguindo a Figura 3, o planejamento e projeto dos testes devem ocorrer de cima para baixo, ou seja:

  1. Inicialmente é planejado o teste de aceitação a partir do documento de requisitos;
  2. Após isso é planejado o teste de sistema a partir do projeto de alto nível do software;
  3. Em seguida ocorre o planejamento dos testes de integração a partir o projeto detalhado;
  4. E por fim, o planejamento dos testes a partir da codificação.

Já a execução ocorre no sentido inverso.

Conhecidos os diferentes níveis de teste, a partir da próxima seção descreveremos as principais técnicas de teste de software existentes que podemos aplicar nos diferentes níveis abordados.

Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software

Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software (CRAIG e JASKIEL, 2002)

Técnicas de teste de software

Atualmente existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento serem diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar falhas no software.

As técnicas de teste são classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. Elas contemplam diferentes perspectivas do software e impõe-se a necessidade de se estabelecer uma estratégia de teste que contemple as vantagens e os aspectos complementares dessas técnicas. As técnicas existentes são: técnica funcional e estrutural.

A seguir conheceremos um pouco mais sobre cada técnica, mas iremos enfatizar alguns critérios específicos para a técnica funcional.

Técnica Estrutural (ou teste caixa-branca)

Técnica de teste que avalia o comportamento interno do componente de software (Figura 4). Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos (PRESSMAN, 2005)

Técnica de Teste Estrutural

Figura 4. Técnica de Teste Estrutural.

Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo, portanto, avaliação de outros aspectos além dos citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes.

Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações originadas por estruturas de condições são testadas. A Listagem 1 apresenta um código fonte, extraído de (BARBOSA et al., 2000) que descreve um programa de exemplo que deve validar um identificador digitado como parâmetro, e a Figura 5 apresenta o grafo de programa extraído a partir desse código, também extraído de (BARBOSA et al., 2000). A partir do grafo deve ser escolhido algum critério baseado em algum algoritmo de busca em grafo (exemplo: visitar todos os nós, arcos ou caminhos) para geração dos casos de teste estruturais para o programa (PFLEEGER, 2004).

Listagem 1. Código fonte do programa identifier.c (BARBOSA et al., 2000)

/* 01 */  {

/* 01 */        char  achar;

/* 01 */        int   length, valid_id;

/* 01 */        length = 0;

/* 01 */        printf (“Digite um possível identificador\n”);

/* 01 */        printf (“seguido por <ENTER>: “);

/* 01 */        achar = fgetc (stdin);

/* 01 */        valid_id = valid_starter (achar);

/* 01 */        if (valid_id)

/* 02 */                 length = 1;

/* 03 */        achar = fgetc (stdin);

/* 04 */        while (achar != ‘\n’)

/* 05 */        {

/* 05 */                 if (!(valid_follower (achar)))

/* 06 */                          valid_id = 0;

/* 07 */                 length++;

/* 07 */                 achar = fgetc (stdin);

/* 07 */        }

/* 08 */        if (valid_id && (length >= 1) && (length < 6) )

/* 09 */                 printf (“Valido\n”);

/* 10 */        else

/* 10 */                 printf (“Invalido\n”);

/* 11 */   }

Grafo de Programa

Figura 5. Grafo de Programa

Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de casos de teste para avaliar classes ou métodos desenvolvidos na linguagem Java. A técnica de teste de Estrutural é recomendada para os níveis de Teste da Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que são profissionais que conhecem bem o código-fonte desenvolvido e dessa forma conseguem planejar os casos de teste com maior facilidade. Dessa forma, podemos auxiliar na redução dos problemas existentes nas pequenas funções ou unidades que compõem um software.

Teste Funcional (ou teste caixa-preta)

Técnica de teste em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo (Figura 6). Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Haverá sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste funcional é aplicável a todos os níveis de teste (PRESSMAN, 2005).

Técnica de Teste Funcional

Figura 6. Técnica de Teste Funcional.

Um conjunto de critérios de teste pode ser aplicado aos testes funcionais. A seguir conheceremos alguns deles.

Particionamento em classes de equivalência

Esse critério divide o domínio de entrada de um programa em classes de equivalência, a partir das quais os casos de teste são derivados. Ele tem por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste de cada classe, pois em princípio todos os elementos de uma classe devem se comportar de maneira equivalente. Eventualmente, pode-se também considerar o domínio de saída para a definição das classes de equivalência (ROCHA et al., 2001).

Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica. As seguintes diretrizes podem ser aplicadas:

  • Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, uma classe de equivalência válida (dentro do limite) e duas inválidas (acima e abaixo dos limites) são definidas.
  • Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas.

Devemos seguir tais passos para geração dos testes usando este critério:

1. Identificar classes de equivalência (é um processo heurístico)

  • condição de entrada
  • válidas e inválidas

2. Definir os casos de teste

  • enumeram-se as classes de equivalência
  • casos de teste para as classes válidas
  • casos de teste para as classes inválidas

Em (BARBOSA et al., 2000) é apresentado a aplicação do critério de particionamento por equivalência para o programa identifier.c. Iremos apresentá-lo como exemplo do uso deste critério de teste. Relembrando, o programa deve determinar se um identificador é válido ou não.

“Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo 1 caractere e no máximo 6 caracteres de comprimento. Exemplo: “abc12” (válido), “cont*1” (inválido), “1soma” (inválido) e “a123456” (inválido).”

O primeiro passo é a identificação das classes de equivalência. Isso está descrito na Tabela 1.

 

Condições de Entrada

Classes

Classes

Tamanho t do identificador

(1) 1 ??t???6

(2) t > 6

Primeiro caractere é uma letra

(3) Sim

(4) Não

Só contém caracteres válidos

(5) Sim

(6) Não

Tabela 1. Classes de Equivalência do programa identifier.c.

A partir disso, conseguimos especificar quais serão os casos de teste necessários. Para ser válido, um identificador deve atender às condições (1), (3) e (5), logo é necessário um caso de teste válido que cubra todas essas condições. Alem disso, será necessário um caso de teste para cada classe inválida: (2), (4) e (6). Assim, o conjunto mínimo é composto por quatro casos de teste, sendo uma das opções: T0 = {(a1,Válido), (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido)}.

Análise do valor limite

Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no “centro”. Esse critério de teste explora os limites dos valores de cada classe de equivalência para preparar os casos de teste (Pressman, 2005).

Se uma condição de entrada especifica uma faixa de valores limitada em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b. Exemplo: Intervalo = {1..10}; Casos de Teste à {1, 10, 0,11}.

Como exemplo, extraído de (BARBOSA et al., 2000), iremos considerar a seguinte situação:

“… o cálculo do desconto por dependente é feito da seguinte forma: a entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5% e dos 22 aos 24 de 3%…”

Aplicando o teste de valor limite convencional serão obtidos casos de teste semelhantes a este: {-1,0,12,13,18,19,21,22,24,25}.

Grafo de causa-efeito

Esse critério de teste verifica o efeito combinado de dados de entrada. As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma tabela de decisão, e a partir desta, são derivados os casos de teste e as saídas (ROCHA et al., 2001).

Esse critério é baseado em quatro passos, que exemplificaremos utilizando o exemplo, também extraído de (BARBOSA et al., 2000):

“Em um programa de compras pela Internet, a cobrança ou não do frete é definida seguindo tal regra: Se o valor da compra for maior que R$ 60,00 e foram comprados menos que 3 produtos, o frete é gratuito. Caso contrário, o frete deverá ser cobrado.”

1. Para cada módulo, Causas (condições de entrada) e efeitos (ações realizadas às diferentes condições de entrada) são relacionados, atribuindo-se um identificador para cada um.

  • Causa: valor da compra > 60 e #produtos < 3
  • Efeito: frete grátis

2. Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado (Figura 7).

Árvore de Decisão – Grafo de Causa-Efeito

Figura 7. Árvore de Decisão – Grafo de Causa-Efeito

Neste ponto, transforma-se o grafo numa tabela de decisão (Tabela 2).

Causa

Valor da compra

> 60

> 60

<= 60

#Produtos

< 3

>= 3

Efeito

Cobrar frete

V

V

Frete grátis

V

Tabela 2. Tabela de decisão para o programa de compra pela Internet.

1. As regras da tabela de decisão são, então, convertidas em casos de teste.

Para a elaboração dos casos de teste, devemos seguir todas as regras extraídas da tabela. Esse critério deve ser combinado com os dois outros já apresentados neste artigo para a criação de casos de teste válidos (extraídos das regras) e inválidos (valores foras da faixa definida). Os casos de teste definidos a seguir refletem somente as regras extraídas da tabela de decisão. Fica como exercício pensar nos casos de teste inválidos para este problema.

  • Casos de Teste (valor, qtd produtos, resultado esperado) = {(61,2,“frete grátis”); (61,3,“cobrar frete”); (60, qualquer quantidade,“cobrar frete”)}

Outras técnicas

Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas. Destacam-se as seguintes técnicas: teste de desempenho, teste de usabilidade, teste de carga, teste de stress, teste de confiabilidade e teste de recuperação. Alguns autores chegam a definir uma técnica de teste caixa cinza, que seria um mesclado do uso das técnicas de caixa preta e caixa branca, mas, como toda execução de trabalho relacionado à atividade de teste utilizará simultaneamente mais de uma técnica de teste, é recomendável que se fixem os conceitos primários de cada técnica.

Conclusões

O teste de software é uma das atividades mais custosas do processo de desenvolvimento de software, pois pode envolver uma quantidade significativa dos recursos de um projeto. O rigor e o custo associado a esta atividade dependem principalmente da criticalidade da aplicação a ser desenvolvida. Diferentes categorias de aplicações requerem uma preocupação diferenciada com as atividades de teste.

Um ponto bastante importante para a viabilização da aplicação de teste de software é a utilização de uma infra-estrutura adequada. Realizar testes não consiste simplesmente na geração e execução de casos de teste, mas envolvem também questões de planejamento, gerenciamento e análise de resultados. Apoio ferramental para qualquer atividade do processo de teste é importante como mecanismo para redução de esforço associado à tarefa em questão, seja ela planejamento, projeto ou execução dos testes. Após ter sua estratégia de teste definida, tente buscar por ferramentas que se encaixem na sua estratégia. Isso pode reduzir significantemente o esforço de tal tarefa.

Além disso, é importante ressaltar que diferentes tipos de aplicações possuem diferentes técnicas de teste a serem aplicadas, ou seja, testar uma aplicação web envolve passos diferenciados em comparação aos testes de um sistema embarcado. Cada tipo de aplicação possui características especificas que devem ser consideradas no momento da realização dos testes. O conjunto de técnicas apresentado neste artigo cobre diversas características comuns a muitas categorias de software, mas não é completo.

Fonte: DevMedia

Imagens em alta resolução utilizando SVG

Entenda o que são imagens SVG e como você poderá utilizá-las hoje.

SVGScalable Vector Graphics (SVG)

Uma das grandes tendências do momento quando se fala sobre desenvolvimento web é o formato SVG, principalmente com o advento do design responsivo e a consequente preocupação com dispositivos com densidade de pixel superior (HiDPI) como a tela retina da Apple, utilizada nos modelos mais recentes do iPhone, iPad e do Macbook Pro. Mas o que exatamente é um arquivo SVG? Qual é a diferença entre um vetor e um bitmap? E como e por que utilizar esta tecnologia a nosso favor?

O que é SVG?

SVG é uma sigla para Scalable Vector Graphics ou, em português, Vetor Gráfico Redimensionável. O padrão foi proposto pelo W3C em 1999, inspirado em formatos proprietários como VML da Microsoft e PGML da Adobe. Em 2001 o SVG ganhou sua primeira versão oficial. A vantagem deste formato em relação aos anteriores é ele ser um padrão aberto (open source). Ou seja, todos podem utilizar sem ter que pagar dinheiro para nenhuma empresa…

Um arquivo SVG é basicamente um mapa em XML que descreve matematicamente uma figura gráfica bidimensional. Funciona como um conjunto de instruções numéricas para realizar um desenho, que são convertidas em imagens em um software capaz de interpreta-lo (como um browser, por exemplo). SVG é para uma imagem o que o HTML é para um texto.

Vetor vs Bitmap

Existem dois tipos principais de arquivos de imagens. Vetores e Bitmaps. Os arquivos do tipo vetor (como AI, EPS, CDR e o nosso novo melhor amigo SVG) são linhas, curvas e formas geometricas descritas matematicamente. Já os arquivos bitmaps (como JPG, PNG, GIF etc) são compostos por um grid de pixels.

As vantagens de se utilizar gráficos em vetor são incríveis. Primeiramente por que é possível redimensiona-los infinitamente sem perder qualidade ou nitidez. Na prática isto significa que um ícone, por exemplo, terá a mesma aparência sem distorções em um smartphone ou uma televisão de 42”. Não importa qual é a quantidade de espaço que a imagem ocupa, o arquivo terá o mesmo peso. O que potencialmente economiza a quantidade de banda necessária para realizar o download, minimiza a quantidade de requisições para o servidor já que não são necessárias diversas imagens diferentes para servir todas as necessidades, etc… A possibilidade de uso de medidas relativas também faz dos gráficos em SVG o formato ideal para se trabalhar com design responsivo.

Diferenca entre imagem SVG e  PNG

Diferenca entre imagem SVG e PNG

Onde e quando aplicar

Ultimamente o formato vem sendo utilizado para ícones, mas ele é útil para qualquer elemento gráfico que precisa ser redimensionado como botões, padrões de background, etc… Uma boa dica é utilizar gráficos SVG para logotipos. Desta maneira o logo sempre ficará nítido e com uma boa qualidade em qualquer resolução ou tamanho de tela, deixando seu cliente muito mais feliz…

Existem ainda uma infinidade de outras possibilidades para este tipo de arquivo como filtros, animações, scripts e outros elementos interativos. Até alguns jogos simples, como este clone de Tetris pela Mozilla.

Mas é bom não abusar. Quanto mais complexa a imagem mais tempo levará para o browser renderiza-la. É inviável utilizar o formato para uma fotografia, por exemplo.

Como fazer um arquivo SVG

Bem, se você gosta muito de matemática e hard coding você pode abrir um editor de texto e escrever manualmente. Se você deseja se aventurar existem alguns tutoriais bacanas nesta wiki. Existem ainda algumas bibliotecas de javascript, como aRaphael.js, que facilitam bastante o trabalho.

Mas para quem não é o super-herói da matemática e deseja uma solução mais prática é possível utilizar algumas ferramentas gráficas como o Adobe Illustrator, Corel Draw, Inkscape… e simplesmente exportar outros arquivos vetoriais para o formato. Existe até um editor online chamado SVG Edit. Ele é bem simples, mas quebra um bom galho na falta de um outro software por perto.

É possível encontrar por aí até alguns programas que prometem converter automaticamente bitmap em SVG… Mas isto não é nada recomendável e cria resultados com qualidade desastrosa.

Se você não é um grande designer, sem problemas. Você pode ainda encontrar diversos pacotes de ícones no formato sob licença creative commons. Uma boa fonte para quem gosta do estilo minimalista é o site Noum Project.

Implementação

Uma pequena nota sobre medidas relativas

Lembrando que para esta técnica funcionar corretamente no caso específico de design responsivo é necessário a utilização de medidas relativas como EM e porcentagem. Vamos utilizar para os exemplos práticos um pequeno icone de roldana. O tamanho “padrão” do nosso ícone de exemplo seria equivalente a 32px de altura e largura. Se considerarmos que a medida padrão de texto (1em) de um browser é equivalente a 16px, o tamanho padrão do nosso icone seria portanto 2em (16×2 = 32). Tomar este tipo de preocupação é fundamental para garantir a flexibilidade das imagens e dar ao desenvolvedor um controle muito maior sobre o conteúdo. Não se esqueça que esta medida será afetada de acordo com a porcentagem do font-size, ok? Para fins práticos vamos trabalhar neste artigo com a medida em 100%.

Hora de colocar a mão na massa e conhecer alguns métodos de desenvolvimento. Não existe uma solução perfeita, cada uma é boa para um tipo de situação. Vamos analisar algumas opções, juntamente com seus lados positivos e negativos.

< object >

[cc escaped=”true” lang=”html”]

pró: É o metodo de aplicação mais utilizado, devido a facilidade para criar-se um fallback para as versões mais antigas do Internet Explorer.

contra: Não é a solução mais semântica, já que o W3C não recomenda a utilização desta tag para imagens. Pode gerar ainda alguns problemas de compatibilidade. A engine Safari/Webkit não renderiza corretamente elementos object com transparência, por exemplo.

___

<svg>

<svg xmlns=”http://www.w3.org/2000/svg&#8221; xmlns:xlink=”http://www.w3.org/1999/xlink”&gt;

<path fill=”#231F20″ d=”M32,17.969v-4l-4.781-1.992c-0.133-0.375-0.273-0.737-0.445-1.094l1.93-4.805L25.875,3.25l-4.763,1.961
c-0.362-0.175-0.734-0.323-1.117-0.461L17.969,0h-4l-1.977,4.734c-0.398,0.141-0.781,0.289-1.161,0.469L6.078,3.294L3.25,6.122
l1.938,4.711C5,11.219,4.847,11.614,4.703,12.021L0,14.031v4l4.706,1.961c0.146,0.406,0.302,0.802,0.489,1.188l-1.903,4.742
L6.12,28.75l4.724-1.945c0.378,0.18,0.766,0.325,1.164,0.461L14.031,32h4l1.979-4.758c0.38-0.141,0.755-0.289,1.114-0.461
l4.797,1.922l2.828-2.828l-1.969-4.773c0.167-0.359,0.305-0.722,0.438-1.094L32,17.969z M15.969,22c-3.312,0-6-2.688-6-6
s2.688-6,6-6s6,2.688,6,6S19.281,22,15.969,22z”/>
</svg>
___

pró: Esta tag de HTML5 foi criada especificamente para este fim, portanto esta é a solução mais moderna e semântica. É relativamente simples: basta colar o código SVG inline.

contra: Código muito extenso dificulta a manutenção (já que é preciso editar manualmente e não apenas substituir um arquivo), baixo grau de compatibilidade com browsers antigos.

<img>

<img src=’img/icone.svg’>

pró: Aplicação simples. Melhor opção para imagem sem interação.

contra: Por motivos de segurança, alguns browsers podem desativar scripts em SVG e algumas opções interativas na tag <img>, como links.

Background Images

pró: Esta opção utiliza apenas CSS. Muito útil para algumas combinações mais complexas como sprites responsivos.

contra: Fallback depende de javascript para funcionar corretamente (veja explicação mais detalhada abaixo).

.icone {
background: url(“../img/icone.svg”) no-repeat;
width: 2em;
height: 2em;
}

Suporte

Google Chrome 4+, Firefox 3+, Safari 3.2+, Opera 8+ e IE 9+.

Métodos de Fallback

Background images em CSS

As versões mais antigas do Internet Explorer (8 e anteriores) possuem diversas deficiências, dentre elas a falta de suporte para background em RGBA. Mas alguns males vem para o bem. É possível se aproveitar desta falha em nosso beneficio. Basta preparar duas imagens: uma versão em SVG para os navegadores mais atuais e outra em PNG para os navegadores antigos e, na classe do CSS, declaramos dois backgrouds. Em um chamamos a imagem em SVG e declaramos uma cor para o background dela usando RGBA. Os navegadores mais antigos irão ignorar esta linha pois, para eles, o RGBA é um erro e eles não irão ler este background. Para estes navegadores, colocamos outro background com a imagem em png. O contra é não é a solução mais semântica já que o usuário será obrigado a baixar duas vezes as imagens… Mas existem algumas maneiras de contornar com a utilização de plugins que controlam a requisição de imagens HD do servidor como o Foresight.

body {
font-size:100%;
}.icone {
background: url(“../img/icone.png”) no-repeat;
background: rgba(0,0,0,0) url(“../img/icone.svg”) no-repeat;
width: 2em;
height: 2em;
text-indent: -6000px;
}

____

Comentário condicional para IE

<!–[if lte IE 8]><img src=’img/icone.png’><![endif]–>

<!–[if gt IE 8]><img src=’img/icone.svg’><![endif]–>

<!–[if !IE]> –><img src=’img/icone.svg’><!– <![endif]–>

Fallback utilizando Modernizr

Pode-se utilizar a biblioteca Modernizr para detectar se existe um suporte ao elemento. O script funciona da seguinte maneira: se o navegador suporta o formato a classe .svg é adicionada ao html, em caso negativo a classe anexada é .no-svg. Isto possibilita a inclusão de um css alternativo. Veja o exemplo:

.icone {

width: 2em;
height: 2em;
text-indent: -6000px;
}.icone.svg {
background: url(icone.svg) no-repeat;
}.icone.no-svg { background: url(icone.png) no-repeat;}

Considerações Finais

Fácil, rápido e indolor. Até o momento não existe nenhuma contra-indicação para o formato e os problemas de retro compatibilidade podem ser facilmente contornados com um pouco de criatividade e conhecimento… Quem acha que gráficos em alta resolução são uma preocupação apenas para um futuro distante esta na hora de abrir a janela (do browser) e dizer olá para o presente.

Escrito por: Dani Guerrato

Banco de dados MySQL e PostgreSQL

PostgreSQL VS MYSQLIntrodução

É muito fácil encontrar serviços de hospedagem de sites que oferecem em seus planos os Sistemas Gerenciadores de Banco de Dados (SGDB) MySQL e PostgreSQL, embora isso seja mais comum com o primeiro. Como esses SGBD não são usados apenas na internet, talvez seja de seu interesse utilizá-los em seus projetos de software, uma vez que cada um é dotado de vantagens interessantes, como a gratuidade de uso. Para ajudá-lo a escolher o melhor para sua aplicação, este artigo apresenta as principais características de ambos, começando com o MySQL. Para tanto, é recomendável que você tenha algum conhecimento sobre os conceitos de bancos de dados.

Alguns termos

Mesmo aquelas pessoas que já trabalham com banco de dados podem ficar “perdidas” no meio de tantos nomes de recursos. Assim, para facilitar a compreensão, segue uma lista com uma breve explicação sobre os recursos mais importantes:

– Referential integrity: também conhecido como “integridade referencial”, esse recurso consiste em restrições ou regras existentes para uma correta inserção de dados, por exemplo, para impedir que uma tabela seja preenchida sem que isso ocorra em outra;

– Schemas: recurso que permite cruzar informações em um mesmo banco de dados, mas em estruturas diferentes;

– SQL: sigla para Structured Query Language, é uma linguagem utilizada em bancos de dados relacionais;

– SSL: sigla para Secure Sockets Layer, consiste em um protocolo para a troca segura de informações;

– Stored procedures: esse recurso consiste em comandos SQL “guardados” no servidor para, por exemplo, executar tarefas repetitivas, evitando que um cliente tenha que executá-las constantemente;

– Transactions: também conhecidas como transações, as transactions são instruções executadas em um bloco designado por parâmetros que indicam seu início e seu fim;

– Triggers: também chamados de gatilhos, os triggers são recursos que permitem o acionamento de uma seqüência de comandos logo em seguida ou logo após um evento;

– Views: os views consistem em um tipo de tabela virtual formada por campos extraídos de uma tabela “verdadeira”, facilitando o controle sob os dados acessados.

O banco de dados MySQL

O MySQL é um dos sistemas de gerenciamento de banco de dados mais populares que existe e, por ser otimizado para aplicações Web, é amplamente utilizado na internet (inclusive aqui no InfoWester). É muito comum encontrar serviços de hospedagem de sites que oferecem o MySQL e a linguagem PHP, justamente porque ambos trabalham muito bem em conjunto.

Outro fator que ajuda na popularidade do MySQL é sua disponibilidade para praticamente qualquer sistema operacional, como Linux, FreeBSD (e outros sistemas baseados em Unix), Windows e Mac OS X. Além disso, o MySQL é um software livre (sob licença GPL), o que significa que qualquer um pode estudá-lo ou alterá-lo conforme a necessidade.

Entre as características técnicas do SGBD MySQL, estão:

– Alta compatibilidade com linguagens como PHP, Java, Python, C#, Ruby e C/C++;

– Baixa exigência de processamento (em comparação como outros SGBD);

– Vários sistemas de armazenamento de dados (batabase engine), como MyISAM, MySQL Cluster, CSV, Merge, InnoDB, entre outros;

– Recursos como transactions (transações), conectividade segura, indexação de campos de texto, replicação, etc;

– Instruções em SQL, como indica o nome.

Até o momento em que este artigo era escrito, o MySQL estava na versão 5.0 (mais precisamente, 5.0.26). Em relação à versão 4.0, houve acréscimo de vários recursos e melhorias importantes, como:

– Triggers;
– Stored procedures;
– Sub-selects;
– Suporte total ao Unicode;
– INFORMATION_SCHEMA (para armazenamento do dicionário de dados);
– Server side cursors;
– Suporte a SSL;
– Melhoria no tratamento de erros.

O MySQL surgiu na Suécia pelas mãos de três colegas: Allan Larsson, David Axmark e Michael Monty Widenius. Trabalhando com base de dados, eles sentiram a necessidade de fazer determinadas conexões entre tabelas e usaram o mSQL para isso. Porém, não demorou para perceberem que essa ferramenta não lhes atendia conforme o necessário e passaram a trabalhar em uma solução própria. Surgia então o MySQL, cuja primeira versão foi lançada no ano de 1996.

Um fato importante a ser destacado sobre o MySQL é que esse SGBD também possui uma licença comercial, isto é, paga. Neste caso, é possível obter suporte diferenciado dos desenvolvedores.

Vale ressaltar também que, em fevereiro de 2008, o MySQL foi comprado pela Sun Microsystems, que pagou a quantia de 1 bilhão de dólares pela aquisição. Mais informações sobre essa transação neste link (em inglês).

O banco de dados PostgreSQL

O sistema gerenciador de banco de dados PostgreSQL teve seu início na Universidade de Berkeley, na Califórnia, em 1986. À época, um programador chamado Michael Stonebraker liderou um projeto para a criação de um servidor de banco de dados relacionais chamado Postgres, oriundo de um outro projeto da mesma instituição denominado Ingres. Essa tecnologia foi então comprada pela Illustra, empresa posteriormente adquirida pela Informix. Porém, mesmo diante disso, dois estudantes de Berkeley (Jolly Chen e Andrew Yu) compatibilizaram o Postgres à linguagem SQL. Este projeto recebeu o nome de Postgres95.

Em 1996, quando o projeto estava estável, o banco de dados recebeu o nome de PostgreSQL. No entanto, enquanto ainda possuía o nome Postgres95, o banco de dados teve várias mudanças. O seu código foi totalmente revisado e a linguagem SQL foi definida como padrão.

Tecnicamente falando, o PostgreSQL é um banco de dados relacional e orientado a objetos. Um de seus atrativos é possuir recursos comuns a banco de dados de grande porte, o que o deixa apto a trabalhar, inclusive, com operações de missão crítica. Além disso, trata-se de um banco de dados versátil, seguro, gratuito e de código aberto (disponível sob uma licença BSD).

Entre suas características, tem-se:

– Compatibilidade multi-plataforma, ou seja, executa em vários sistema operacionais, como Windows, Mac OS X, Linux e outras variantes de Unix;

– Compatibilidade com várias linguagens, entre elas, Java, PHP, Python, Ruby, e C/C++;

– Base de dados de tamanho ilimitado;

– Tabelas com tamanho de até 32 TB;

– Quantidade de linhas de até 1.6 TB ilimitada;

– Campos de até 1 GB;

– Suporte a recursos como triggers, views, stored procedures, SSL, MVCC, schemas, transactions, savepoints, referential integrity e expressões regulares;

– Instruções em SQL, como indica o nome.

No momento em que este artigo era escrito, o PostgreSQL estava na versão 8.1.

MySQL x PostgreSQL

MySQL ou PostgreSQL, qual usar? Ambos são muito bons e não fazem feio diante das alternativas pagas. Além disso, possuem recursos e vantagens em comum, o que significa que, para a maioria das aplicações, ambos podem ser usados. Na verdade, o correto não é tentar descobrir qual é o melhor, mas em que situação um ou outro deve ser utilizado.

O PostgreSQL é otimizado para aplicações complexas, isto é, que envolvem grandes volumes de dados ou que tratam de informações críticas. Assim, para um sistema de comércio eletrônico de porte médio/alto, por exemplo, o PostGreSQL é mais interessante, já que esse SGBD é capaz de lidar de maneira satisfatória com o volume de dados gerado pelas operações de consulta e venda.

O MySQL, por sua vez, é focado na agilidade. Assim, se sua aplicação necessita de retornos rápidos e não envolve operações complexas, o MySQL é a opção mais adequada, pois é otimizado para proporcionar processamento rápido dos dados e tempo curto de resposta sem exigir muito do hardware. Se você precisa, por exemplo, de um banco de dados para armazenar o conteúdo do seu site, de seu fórum ou necessita manter um cadastro de usuários de um portal, o MySQL “serve como uma luva”, pois tais aplicações não necessitam dos recursos avançados que o PostgreSQL oferece.

Para escolher um destes dois SGBD, procure entender bem quais recursos sua aplicação precisa. Tente estimar o volume de dados, avalie o hardware disponível, certifique-se das funcionalidades necessárias e, posteriormente, procure por informações mais detalhadas do MySQL e do PostGreSQL. Se sua aplicação for simples – principalmente se for algo ligado à internet -, não é preciso pensar muito: o MySQL é uma escolha satisfatória, pois é facilmente encontrado em serviços de hospedagem.

Livros Sugeridos:

PostgreSQL – Técnicas avançadas

PostgreSQL – Guia do programador

MySQL – Guia programador

Aprendendo MySQL

Finalizando

Um banco de dados pode ser a diferença entre ter e não ter um negócio, seja ele de qualquer porte. Por isso, a escolha deve ser bem feita e aspectos como desempenho, recursos, documentação e suporte devem ser considerados. Em todos esses pontos o MySQL e o PostgreSQL são excelentes, por isso, a escolha entre um deles só depende de sua aplicação.

Para saber mais sobre o PostgreSQL, visite: http://www.postgresql.org (em inglês) e http://www.postgresql.org.br.

Para saber mais sobre o MySQL, visite: http://www.mysql.com (em inglês) e http://www.mysqlbrasil.com.br.

Escrito por Emerson Alecrim – Publicado em 21_11_2006 – Atualizado em 20_04_2008

Fonte: InfoWester

Cinco grandes mentiras sobre Teste de Software

Testadores de SoftwareComo em quase todas as áreas de atuação, o mercado de teste de software é rodeado por mitos quanto a esta atividade. Decidimos listar, então, algumas das mentiras mais ditas sobre testes. Afinal, quem é que nunca foi vítima desses enganos?

1- Teste de software não exige muito intelectualmente

Se você apenas repete ações predefinidas, teste realmente pode não exigir muito do testador nesse aspecto. Mas é importante pensar em testes como uma forma de explorar, coletar informações e encontrar respostas a coisas que ainda não foram questionadas. E para alcançar esse nível de detalhamento é preciso pensar, observar, analisar e usar tudo o que o seu intelecto tem a oferecer.

2- Testadores apenas reclamam

Testadores apenas veem o lado negativo e reclamam de tudo a respeito do software? Não é necessariamente verdade. Se têm pensamento positivo ou negativo com relação à aplicação que estão testando, não importa. A questão é que são sim os melhores pensadores. São os que mais refletem a respeito do que lhes é proposto. E eles não reclamam, eles apresentam a realidade. Com direito a evidências de tudo que encontram.

3- Teste não atribui valor

Impedir que um sistema perca valor ao chegar às mãos do usuário com falhas cruciais ao seu funcionamento não é um trabalho limitado a apenas custos. O bom testador precisa conhecer o software como ninguém e ter alguém demonstrando esse conhecimento e assegurando maior qualidade no produto final é algo que acrescenta valor.

4- A Automação vai tomar o lugar dos testadores

Essa é uma das maiores mentiras que vemos por aí. Testes automatizados só funcionam quando são guiados por regras estabelecidas por humanos. Por si só, a automação não conseguiria ir tão longe. Outro ponto é considerar para quem são feitos os software: pessoas. Pessoas que pensam, têm emoções e curiosidade. E é por isso que os testes também precisam ser feitos por pessoas, acima de tudo e, logo, os testes manuais nunca vão deixar de existir.

5- Desenvolvedores e testadores não são amigos

Se desenvolvedores e testers não trabalharem em parceria, o projeto sairá prejudicado. Como já foi dito, o testadores não têm o objetivo de criticar uma aplicação, mas sim de apresentar a sua realidade e, com isso, contribuir para a qualidade do produto. Eles, por sua vez, farão uso de todas as informações fornecidas pelos desenvolvedores para que surjam ideias no momento dos testes. Se todos tiverem o mesmo propósito de garantir qualidade ao software, a chance de sucesso será infinitamente maior.

Fonte: CrowdTest 

Política de Segurança da Informação – NBR ISO/IEC 27002 – Parte 2

NBR ISO/IEC 27002A norma NBR ISO/IEC 27002 está organizada em 11 seções que correspondem a controles de segurança da informação. Na primeira parte do artigo “Conheça a norma NBR ISO/IEC 27002“,  foram abordadas as seções 5. Política de Segurança da Informação, 6. Organizando a Segurança da Informação, 7. Gestão de Ativos, 8. Segurança em Recursos Humanos e 9. Segurança Física e do Ambiente.  A seguir, serão abordadas as seções restantes (10 a 15).

Gestão das Operações e Comunicações

É importante que estejam definidos os procedimentos e responsabilidades pela gestão e operação de todos os recursos de processamento das informações. Além disso, deve-se utilizar sempre que necessária a segregação de funções (recomenda-se que uma pessoa realize uma ou algumas partes de um processo, mas não todas), visando reduzir o risco de mau uso ou uso indevido dos sistemas.

Para o gerenciamento de serviços terceirizados, deve-se implementar e manter o nível apropriado de segurança da informação e em conformidade com acordos de entrega de serviços terceirizados.

É fundamental planejar e preparar a disponibilidade e os recursos do sistemas para minimizar o risco de falhas, bem como prever a capacidade futura dos sistemas, de  forma a reduzir os riscos de sobrecarga. Também deve-se prevenir e detectar a introdução de códigos maliciosos e os usuários devem estar conscientes sobre isso.

Procedimentos para a geração de cópias de segurança e sua recuperação também devem ser estabelecidos.

Deve-se garantir ainda o gerenciamento seguro de redes. Controles adicionais podem até mesmo ser necessários para proteger informações confidenciais que trafegam em redes públicas.

As trocas de informações entre organizações devem ser baseadas em uma política formal específica, devendo ser efetuadas a partir de acordos entre as partes e sempre em conformidade com toda a legislação pertinente.

Deve-se ainda implementar mecanismos de monitoração  de atividades não autorizadas de processamento da informação. Os eventos de segurança da informação devem ser registrados, lembrando que  as organizações devem estar aderentes aos requisitos legais aplicáveis para suas atividades de registro e monitoramento.

Controle de Acesso

O acesso à informação, aos recursos de processamento das informações e aos processos de negócios devem ser controlados com base nos requisitos de negócio e na segurança da informação.  Portanto, deve ser assegurado o acesso de usuário autorizado e prevenido o acesso não autorizado a sistemas de informação. Para isso, deve haver procedimentos que englobem desde o cadastro inicial de um novo usuário até o cancelamento final do seu registro, garantindo assim que já não possuem mais acesso a sistemas de informação e serviços.

Os usuários sempre devem estar conscientes de suas responsabilidades, particularmente no que se refere ao uso de senhas e de segurança dos equipamentos de usuários. Nesse sentido, sugere-se ainda a adoção da “política de mesa e tela limpa”, para reduzir o risco de acessos não autorizados ou danos a documentos, papéis, mídias e recursos de processamento da informação que estejam ao alcance de qualquer um.

Aquisição, Desenvolvimento e Manutenção de Sistemas de Informação

Segundo a norma, “Sistemas de informação incluem sistemas operacionais, infra-estrutura, aplicações de negócios, produtos de prateleira, serviços e aplicações desenvolvidas pelo usuário”. Por essa razão, os requisitos de segurança de sistemas de informação devem ser identificados e acordados antes do seu desenvolvimento e/ou de sua implementação.

As informações devem ser protegidas visando a manutenção de sua confidencialidade, autenticidade ou  integridade por meios criptográficos.

Gestão de Incidentes de Segurança da Informação 

Deve-se assegurar que eventos de segurança da informação sejam o mais rápido possível comunicados, de tal forma que a tomada de ação corretiva ocorra em tempo hábil. Para isso, devem ser estabelecidos procedimentos formais de registro e escalonamento, bem como todos os funcionários, fornecedores e terceiros devem estar conscientes sobre os procedimentos para notificação dos diferentes tipos de eventos.

Gestão da Continuidade do Negócio

Deve-se impedir a interrupção das atividades do negócio e proteger os processos críticos contra efeitos de falhas ou desastres significativos, e assegurar que a sua retomada ocorra em tempo hábil.

Para isso, planos de continuidade do negócio, incluindo controles para identificar e reduzir riscos, devem ser desenvolvidos e implementados, visando assegurar que as operações essenciais sejam rapidamente recuperadas.

Conformidade

Deve-se garantir e evitar a violação de qualquer lei criminal ou civil, estatutos, regulamentações ou obrigações contratuais e de quaisquer requisitos de segurança da informação.

Para isso, é conveniente contratar, caso necessário, consultoria especializada, bem como analisar criticamente a segurança dos sistemas de informação a intervalos regulares, verificando, sobretudo, sua conformidade e aderência a requisitos legais e regulamentares.

Em resumo, nota-se claramente ao longo de toda a norma, que a característica predominante é a prevenção, evitando-se a todo o custo, a adoção de medidas de caráter reativo. Mesmo as que forem reativas, como por exemplo a execução de um plano de continuidade de negócios, são previamente planejadas para que, no momento oportuno e se necessárias, sejam devidamente implementadas.

Referência Bibliográfica:

ABNT – Associação Brasileira de Normas Técnicas. ABNT NBR ISO/IEC 27002 –Tecnologia da informação – Técnicas de segurança – Código de prática para a gestão de segurança da informação. ABNT, 2005.