Teste de Aceitação

O teste de aceitação é realizado com o propósito de avaliar a qualidade externa do produto e, na medida do possível, também a qualidade em uso. Assim, só é possível quando o software está concluído e pronto para ser implantado. Evidentemente, é um teste com forte relação com o cliente, que participa do planejamento e realização dessa atividade.

O teste de aceitação é geralmente denominado de “alfa” quando realizado no ambiente de desenvolvimento (qualidade externa) e “beta” quando no ambiente do cliente (qualidade de uso). O teste de qualidade externa é com freqüência a única alternativa no caso de aplicações desenvolvidas para mainframes. Uma forma de paliar a impossibilidade de utilizar a plataforma definitiva de execução é simulá-la, por exemplo, utilizando dados reais.

Outro tipo de teste de aceitação possível é o teste de paralelo, quando um sistema é desenvolvido para
substituir outro já em funcionamento. O novo sistema pode funcionar em paralelo ao antigo e o comportamento de ambos é comparado, até que se decida que a substituição é possível. O teste em paralelo é indicado, por exemplo, em sistemas críticos.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Teste Orientado a Objetos

O teste orientado a objetos consiste em realizar seqüências de envios de mensagens. Essas sequências devem ser escolhidas de maneira a explorar o maior número possível de estados que um objeto possa assumir e as transições entre eles.

Para que esse tipo de verificação seja eficiente, é interessante reduzir ao mínimo o número de casos de teste aplicados. Considere estas duas seqüências em C++ usando a biblioteca STL:

Seqüência 1:
v.erase (v.begin() + 3);
v.insert (v.begin() + 3, 100);

Seqüência 2:
v.insert (v.begin() + 3, 100);
v.erase (v.begin() + 4);


As duas seqüências de chamadas provocam exatamente o mesmo efeito: substituir o terceiro elemento de um vetor. É possível criar inúmeros casos de teste diferentes que levam um objeto exatamente ao mesmo estado. Se não for relevante testar diferentes caminhos, isto é, as transições que provocam a mudança, é melhor utilizar um único caso de teste.

Existem ferramentas para geração de casos de teste para orientação a objetos, como JCrasher, gratuita, Jtest e JC++, da Parasoft, que evitam testes redundantes.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Aceitação

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Teste de Integração

Quando todos os componentes de um software foram testados, surge uma pergunta: quando estiverem integrados, continuarão funcionando? O teste de componentes individuais antecede o teste de integração. Contribui para assegurar a correção de componentes individuais, mas não é capaz de garantir que as dependências funcionais entre componentes estejam perfeitamente implementadas. Para isso é preciso uma abordagem diferente.

Com relação a integração de componentes, existem duas vertentes principais para desenvolvimento de software: as abordagens bottom-up e top-down.

Na abordagem bottom-up, o programa é desenvolvido a partir de rotinas básicas que prestam serviços a rotinas de nível mais alto. Por exemplo, uma verificação de validade de CPF pode ser chamada em vários pontos de um programa. Será, então uma das primeiras a serem implementadas.

Na abordagem top-down, faz-se o inverso. O programador trabalha supondo que o código de baixo nível já esteja pronto. Assim, pode-se codificar chamadas à verificação de CPF, mesmo sabendo que ela ainda não existe. Em seu lugar, pode haver uma rotina “fantasma” (stub), que apenas retorna sempre um valor verdadeiro.

Para realizar testes no desenvolvimento bottom-up, deve ser escrito código que invoque as rotinas de baixo nível, testando-as com diversas combinações de parâmetros. As rotinas escritas para tais testes são conhecidas como drivers, pois sua função é acionar o código que deve ser testado. No teste up-down, a função inversa é fornecida pelos stubs que provêem dados para as rotinas de nível superior, permitindo que se realizem os testes.

Quando os dados são oriundos de arquivos, é comum que avaliadores criem bases de dados falsas contendo registros para realizar testes. Quando os dados são oriundos de arquivos, é comum que avaliadores criem bases de dados falsas contendo registros para realizar testes. Tais registros podem inclusive ser inconsistentes, contendo informação defeituosa para verificar o comportamento de rotinas.

Após o teste e correção dos componentes individuais, segue-se uma etapa de construção de novo código. Na abordagem bottom-up, os drivers são substituídos por rotinas “verdadeiras”, enquanto na abordagem top-down o mesmo se faz com os stubs. As novas rotinas devem ser novamente testadas em conjunto e o processo todo se repete até a conclusão do projeto.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Orientado a Objetos
Teste de Aceitação

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Teste de Estresse

É realizado para submeter o software a situações extremas. Basicamente, o teste de estresse baseia-se em testar os limites do software e avaliar seu comportamento. Assim, avalia-se até quando o software pode ser exigido e quais as falhas (se existirem) decorrentes do teste.

Os testes de estresse são fundamentais em aplicações em que a eficiência seja uma característica importante. Por exemplo:
  •  servidores de arquivos e servidores web, que devem atender a solicitações de um
    grande número de clientes;
  •  aplicações industriais, tais como o controle de
    uma refinaria de petróleo;
  •  jogos de computador, que precisam de um desempenho aceitável
    para serem viáveis comercialmente.
Vamos considerar como exemplo a implementação de um servidor web utilizado em e-commerce. Ao estabelecer os requisitos do sistema, fixou-se um máximo de 5000 transações por minuto para uma determinada plataforma de execução. Um teste de estresse pode, então, ser feito para responder a várias perguntas:
  •  o sistema consegue atingir o objetivo?
  •  qual o número máximo de transações realmente possível?
  •  se a plataforma de execução se degradar (por exemplo, uma falha parcial de rede, falta de espaço em disco, etc.), como o sistema se comportará?
Em certos casos é preferível que a execução do programa seja mantida mesmo que se degrade, evitando uma parada completa. Um exemplo típico são sistemas financeiros.

Possibilidades de falhas sob condições de operação difícil, como registrar operações incorretas, devem ser detectadas e evitadas. Um bom teste de estresse deve poder revelar essas informações aos avaliadores.

A grande dificuldade de realizar um teste de estresse é configurar adequadamente a plataforma de execução. Por exemplo: se o avaliador está interessado em saber a quantidade mínima de memória disponível para que um programa funcione, retirar fisicamente chips de RAM é uma solução muito trabalhosa. Além de RAM, há diversos outros parâmetros, como disco, CPU e instalações de rede, e seria inviável montar e desmontar um computador com diferentes configurações para todos os testes. Para isso, utilizam-se ferramentas de estresse.

Um exemplo de ferramenta que pode ser utilizada para um teste de estresse é o WinStress, da Ultra-X. Trata-se de um programa que permite reduzir artificialmente o desempenho de um computador, de acordo com a configuração desejada pelo avaliador. É possível variar parâmetros como carga de CPU, memória disponível, espaço em disco disponível e carga de rede.

Existem também ferramentas específicas para teste de aplicações em rede. Tais ferramentas permitem testar um programa simulando um número arbitrário de conexões. Alguns exemplos são DieselTest e OpenSTA, para aplicações Internet, e DBMonster, para teste de aplicações SQL.

Veja também:

Teste de Caixa-Preta
Teste de Caixa-Branca
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Teste de Caixa-Branca

Também conhecido como teste estrutural. É aquele em que o analista tem total acesso à estrutura interna da entidade sendo analisada e permite, por exemplo, que o analista escolha partes específicas de um componente para serem testadas.

O fato de conhecer o código do programa permite que o avaliador projete testes mais precisos. Por exemplo, se a definição de uma função g(), para um determinado programa, afirma que ela não aceita valores negativos, um avaliador poderia provocar uma chamada fun(-1) e descobrir que um tratamento de exceções não está corretamente implementado.

Esses testes são projetados em função da estrutura do componente e podem permitir verificação mais precisa de comportamento do produto. Ele permite ao avaliador concentrar a atenção nos pontos mais importantes ou “perigosos” do código, de uma maneira mais precisa do que no caso do teste caixa-preta. Tais pontos podem até ser identificados durante o desenvolvimento e cobertos com o uso de assertivas e testes.

Há, entretanto, um elemento comum entre os testes caixa-preta e caixa-branca: em ambos os casos, o avaliador não sabe qual será o comportamento produto em uma determinada situação. Esse fato pode parecer, a princípio, paradoxal para o teste caixa-branca, uma vez que o avaliador tem total acesso aos componentes internos do produto. Contudo, a imprevisibilidade resulta da complexidade combinatória.
Por exemplo:

Seja a linha de código... n = a/(f(i)*(h – g(j)));
Essa linha pode levar a uma divisão por zero em dois casos...

  •  f(i) retorna um valor nulo;
  •  g(j) retorna um valor igual a h.

Sem conhecer a função f(), sabe-se que se o tipo de dado da variável i tiver 32 bits, existirão no total 232 casos a serem testados. Conhecer a estrutura de f() não é suficiente para reduzir a quantidade de testes. Essa estrutura pode ser complexa contendo várias chamadas a outras funções.

Alguns testes caixa-branca podem ser realizados efetuando modificações no programa. Seja a linha...

fun (r1 -> ptr, n, tst.count());

Supondo que o avaliador esteja interessado em saber o que ocorre se o campo ptr contiver um valor nulo, ou, ainda, quando r1 é um ponteiro nulo ou inválido, uma vez que uma falha em fun teria conseqüências desastrosas. Pode ser difícil forçar essa condição dentro do código apenas operando a interface do programa. Uma maneira de fazê-lo é efetuar uma modificação temporária no programa:

fun (NULL, n, tst.count());

A versão de testes resultante deve ser executada e os resultados, observados. Naturalmente, é preciso um cuidado especial com o controle de versões de software: a versão de teste, bem como o executável resultante, não deve jamais ser confundida com a versão correta que será entregue ao cliente.

Veja também:

Teste de Caixa-Preta
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Teste de Caixa-Preta

O Teste de Caixa-Preta ou Teste Funcional, também é usado na engenharia, no problema de identificação de sistemas, e advém do fato de que ao analisar o comportamento de um objeto, ignora-se totalmente sua construção interna.

Nesse tipo de teste, uma determinada função g() que não aceita valores negativos, mas não possui tratamento adequado de exceção, poderia ser testada para cem mil valores diferentes no intervalo [0...106], sem que fosse detectado algum defeito.

O teste de caixa-preta é baseado nos requisitos funcionais do software. Como não há conhecimento sobre a operação interna do programa, o avaliador se concentra nas funções que o software deve desempenhar. A partir da especificação são determinadas as saídas esperadas para certos conjuntos de entrada de dados.

Esse tipo de teste reflete, de certa forma, a óptica do usuário, que está interessado em se servir do programa sem considerar os detalhes de sua construção. Comparando a outros tipos de teste, este é relativamente mais simples.

O teste é particularmente útil para revelar problemas, tais como:
  •  funções incorretas ou omitidas;
  •  erros de interface;
  •  erros de comportamento ou desempenho;
  •  erros de iniciação e término.

Um exemplo simples de aplicação é verificar a consistência de dados de interface. Um exemplo de aplicação do teste é fazer entradas erradas de dados e observar o comportamento do programa.

Ao realizar o teste, o avaliador deve buscar simular erros que um usuário pode cometer e que fogem da especificação do programa:
  •  usar como data de nascimento a data atual ou uma data futura;
  •  preencher campos com um número insuficiente de caracteres (por exemplo, digitar apenas “123” para CPF ou telefone);
  •  códigos de CPF ou de CEP errados;
  •  preencher campos como nome com valores muito grandes (por exemplo, copiar- colar um texto de 10 Kbytes num campo);
  •  deixar campos de entrada vazios ou preenchê-los com espaços brancos ou zeros(sobretudo campos de preenchimento obrigatório);
  •  usar valores negativos para números, como valor a pagar;
  •  não respeitar tipos de dados (por exemplo, digitar letras ou símbolos em um campo “idade”.

Além da interface, pode-se verificar a execução de funções ou tarefas inteiras.

Alguns exemplos de testes são:
  • duplicar informações (por exemplo, tentar cadastrar duas vezes exatamente os mesmos dados);
  • imprimir relatórios para bases de dados vazias;
  • procurar registros inexistentes.

Veja também:

Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Utilizando o CobiT e o Balanced Scorecard como instrumentos para o Gerenciamento de Níveis de Serviço




Introdução

Na economia atual voltada a prestação de serviços, as organizações cada vez mais se apóiam em terceiros para a obtenção de um grande número de serviços na área de Tecnologia da Informação (TI). No entanto, estas organizações não estão normalmente satisfeitas com a qualidade dos serviços recebidos e algumas vezes são dependentes de terceiros cujo futuro é incerto, especialmente neste período caracterizado por economias em declínio.


Este artigo mostra como as organizações podem responder a este problema através de acordos de nível de serviço (SLA – Service Level Agreemet) e gestão de níveis de serviço (SLM – Service Level Management), apoiados por mecanismos tais como o modelo CobiT (Control OBjectives for Information and related Technology) e o Balanced Scorecard (BSC).

A principal conclusão deste artigo é que um processo adequado de SLM deveria ser instalado nas organizações e então, para evitar problemas de recebimento de serviços não satisfatórios, alguns níveis de serviço deveriam ser expressos em termos do negócio. Implementar um processo de SLM não é uma tarefa fácil e rápida. Uma abordagem utilizando mecanismos tais como o CobiT e o BSC podem ajudar na definição ou aprimoramento do SLAs.

Definições 
De acordo com o Foundations of Service Level Management, SLM é “a metodologia disciplinada e pró-ativa e os procedimentos utilizados para garantir que os usuários de TI recebam serviços com nível adequado de qualidade, de acordo com as prioridades do negócio, a um custo aceitável.”

O instrumento principal para o SLM é o acordo de nível de serviço (SLA). “Um acordo de nível de serviço é um contrato escrito entre o fornecedor do serviço e o cliente deste serviço. O objetivo do SLA é estabelecer metas mensuráveis de desempenho a fim de se ter um entendimento comum da natureza e do nível de serviço desejado” de acordo com o International Federation of Accountants.

De forma geral, existem três tipos básicos de SLA: doméstico, externo e interno. As diferenças entre estes tipos estão nas partes envolvidas na definição dos acordos:

  • doméstico: acordo negociado entre, por exemplo, o departamento de TI e os outros departamentos da mesma empresa.
  • externo: acordo entre um fornecedor externo (terceirizado) e a empresa.
  •  interno: acordo utilizado pelo fornecedor para medir o desempenho dos grupos dentro do seu próprio setor.
Independente do tipo de acordo, este deve ser sempre negociado com uma equipe multidisciplinar com representação equilibrada entre o grupo de usuários e o fornecedor do serviço. Muitos entendem que estas negociações devem resultar em acordos “soma-zero”, ou seja, obtenção de serviços com alto nível de qualidade a um custo mínimo (por parte do usuário) e concebidos com um mínimo de esforço e margem de lucro máxima (por parte do fornecedor). Buscar o equilíbrio entre estas duas posições é crucial, mas, ao mesmo tempo, uma tarefa difícil para um SLM e SLAs efetivos.

Um SLA é uma necessidade entre o fornecedor de serviço e o seu usuário já que um serviço pode ser considerado “bom” ou “ruim” apenas se este serviço está claramente descrito. Além disso, o acordo formaliza as necessidades e expectativas da empresa e serve como um tipo de garantiapara ambas às partes. Desta forma, prováveis mal-entendidos são minimizados e é possível uma visão mais clara das prioridades do serviço e da sua disponibilidade.

Alguns componentes essenciais de um acordo são: participantes do acordo, definições da terminologia utilizada, prazos, escopo, assunto, limitações, objetivos dos níveis do serviço (disponibilidade, desempenho, níveis de carga, segurança, manutenção, qualidade), indicadores de níveis de serviço, impactos do mau desempenho, mecanismos de preço, termos de pagamento, procedimentos de segurança, procedimentos de auditoria, funções e responsabilidades, serviços opcionais, relatórios, administração, revisões/atualizações, propriedade, aspectos legais e homologações.

Os indicadores de níveis de serviço especificam as métricas e estatísticas que serão utilizadas para medir os níveis de serviço. Além disso, devemos definir quem exatamente irá executar a atividade de medir e como isto será feito. No registro das métricas, é importante coletar as métricas objetivas (os números) assim como também as métricas subjetivas (tais como a percepção do grupo de usuários finais) que podem ser muito diferentes das estatísticas objetivas.

Da mesma forma, as cláusulas de problemas de desempenho definem o que acontece se o fornecedor do serviço não atender os objetivos do SLA como estabelecidos (avisos, ações corretivas, penalidades financeiras).

Os procedimentos e processos de revisão e atualização deveriam ser incluídos para permitir a identificação e adequada implementação de qualquer mudança solicitada, como, por exemplo, outros indicadores, novas tecnologias, novos requisitos organizacionais ou de serviço e mudanças na estratégia da organização. Revisões periódicas nos acordos são fatores chaves de sucesso já que as organizações e seus serviços são dinâmicos por natureza.

É importante ressaltar que um SLA completo não existe. Sempre existirão certas cláusulas secretas para os fornecedores se apoiarem quando os serviços fornecidos ficarem abaixo dos níveis estipulados. Como conseqüência, muitas organizações se sentem ludibriadas pelo fato de que seus SLA's não os protegem efetivamente contra tudo e então começam a acusar o fornecedor pela qualidade do serviço e SLAs não confiáveis. No entanto, eles esquecem que quanto maior o escopo do SLA, maior o custo da prestação do serviço. Um SLA equilibrado é um compromisso entre as necessidades, expectativas e requisitos da organização (grupo de usuários) e a capacidade de fornecimento do serviço e promessas do fornecedor. Ao mesmo tempo, um SLA precisa proteger o fornecedor limitando suas responsabilidades legais e gerenciando racionalmente as expectativas do usuário.

CobiT, SLM e SLAs
O CobiT, desenvolvido pelo IT Governance Institute, inclui o framework CobiT que define 34 processos de TI, distribuídos em 4 domínios de TI; (1) Planejamento e Organização (PO), (2) Aquisição e Implementação (AI), (3) Delivery e Suporte (DS) e (4) Monitoramento (M) (
http://www.isaca.org). O CobiT define um nível mais alto de objetivos de controle para cada processo e de 3 a 30 objetivos de controle mais detalhados. Os objetivos de controle contém declarações dos resultados desejados ou metas a serem alcançadas na implementação de procedimentos de controle específicos dentro de uma atividade de TI e fornecem uma política clara para o controle de TI na empresa.

Um dos processos de TI identificados no framework é o de “Definição e Gerenciamento de Níveis de serviço” do domínio Delivery e Suporte (DS). Segue-se um resumo dos objetivos de controle deste processo de TI:

Objetivo de controle de alto nível:
Controle sobre os processos de TI, definindo e gerenciando níveis de serviço que satisfaçam os requisitos do negócio para estabelecer um entendimento comum do nível de serviço desejado.Este objetivo é possível pelo estabelecimento de SLAs que formalizam os critérios de desempenho a partir dos quais a quantidade e qualidade do serviço serão medidos.

Devem ser levados em consideração:
  • acordos formais
  • definição de responsabilidades
  • tempos de resposta e volumes
  • garantia de integridade
  • acordos de discrição
  • critérios de satisfação do cliente
  • análise de custo/benefício dos níveis de serviço exigidos
  • monitoramento e notificações
Objetivos de controle detalhados (resumo):

  • Framework de SLA
  • Aspectos de SLAs
  • Procedimentos de desempenho
  • Monitoramento e notificações
  • Revisão de SLAs e contratos
  • Itens contábeis
  • Programas de melhorias de serviço
Estes objetivos de controle dão ênfase à importância de um modelo de SLA e a necessidade deacordo nos componentes de um SLA. Procedimentos de desempenho, monitoramento e controle devem ser estabelecidos e os contratos devem ser revisados regularmente.
Para atender as necessidades gerenciais de controle e medição de TI, o CobiT fornece para os 34 processos de TI, diretrizes contendo ferramentas de avaliação e medição do ambiente de TI da organização. O Management Guidelines inclui modelos de maturidade (MM), fatores críticos de sucesso (CSFs), indicadores chaves de metas (KGIs) e indicadores chaves de desempenho (KPIs) para cada processo.

Um modelo de maturidade é um método de avaliação que permite a uma organização graduar a sua maturidade para um determinado processo, de não-existente (0) até otimizado (5) e assim avaliar-se quanto as melhores práticas e padrões do mercado. Dessa forma, as deficiências podem ser identificadas e ações específicas podem ser definidas para se atingir as posições desejadas.

Pode-se mover para um nível mais alto quando todas as condições descritas em um determinado nível de maturidade são cumpridas.

O modelo de maturidade para o processo “Definição e Gerenciamento de Níveis de serviço” está resumido abaixo:

  • Nível 0: Não existente
    A gerência não reconhece a necessidade de um processo para a definição de SLAs.
  • Nível 1: Inicial/ad hoc
    Existe a conscientização da necessidade de se gerenciar SLAs, mas o processo é informal.
  • Nível 2: Repetitivo e intuitivo
    Existem SLAs acordados, mas são informais e não são revisados. O relatório de nível de serviço é incompleto.
  • Nível 3: Processo definido
    O processo de SLA está instalado com pontos de controle para reavaliação dos níveis de serviço e satisfação do cliente.
  • Nível 4: Gerenciado e medido
    Medidas de desempenho refletem cada vez mais as necessidades do usuário final e não somente os objetivos de TI.
  • Nível 5: Otimizado
    Os níveis de serviço são continuamente reavaliados para garantir alinhamento de TI e os objetivos do negócio.
O Management Guidelines também fornece os fatores críticos de sucesso (FCSs), os KGIs (key goal indicators) e os KPIs (key performance indicators) que podem ser úteis quando do esforço para se alcançar um certo nível de maturidade. Os fatores críticos de sucesso são os elementos mais importantes que uma organização deve ter como meta para contribuir com o processo de TI no cumprimento de seus objetivos. KGIs são elementos de negócios indicando “o quê” deve ser cumprido. Eles representam os objetivos do processo de TI. Os KPIs são orientados a processo, focando no “como”, e indicando quão bem os processos de TI permitem que o objetivo seja alcançado. Os FCSs, KPIs e KGIs para o processo “Definição e Gerenciamento de Níveis de serviço” estão resumidos abaixo:

Fatores Críticos de Sucesso KGIs KPIsKGIsKPIs
- Os níveis de serviço são expressos nos termos de negócio do usuário final, sempre que possível.
- Análise das causas deve ser executada sempre que o nível de serviço acordado não seja atendido.
- Habilidades e ferramentas estão disponíveis para fornecer informações sobre o nível de serviço periodicamente.
- A dependência em TI de processos críticos de negócio está definida e coberta pelas SLAs.
- As responsabilidades de TI estão ligadas aos níveis de serviço.
- A área de TI pode identificar as fontes de variação de custos.
- Esclarecimentos detalhados e consistentes sobre as variações de custo estão disponíveis.
- Um sistema para o acompanhamento de mudanças individuais está disponível.
- Declaração pela unidade estratégica dos negócios que os níveis de serviço estão alinhados com os objetivos de negócio.
- Concordância do cliente que o nível de serviço atende as expectativas.
- Níveis de serviço compatíveis com os custos orçados.
- Porcentagem de todos os processos críticos de negócios dependentes de TI cobertos pelos SLAs.
- Porcentagem de SLAs revistas no período acordado.
- Porcentagem de serviços de TI que atendem SLAs.
- Tempo de tratamento de um pedido de mudança nos níveis de serviço.
- Freqüência de levantamento da satisfação do cliente.
- Tempo de tratamento de assuntos relacionados a níveis de serviço.
- Impacto da quantidade de recursos financeiros adicionais para o atendimento do nível de serviço definido.

Existe um relacionamento de causa-e-efeito importante entre KGIs e KPIs. KGIs, tais como o “Concordância do cliente que o nível de serviço atende as expectativas ”, sem KPIs, tais como o “Tempo de tratamento para um pedido de mudança nos níveis de serviço”, não comunica como o resultado será obtido. E KPIs sem KGIs pode levar a investimentos significativos sem uma medida apropriada indicando se a estratégia SLM escolhida é efetiva. Alguns KPIs terão obviamente um grande impacto em KGIs específicos, comparados com outros. É importante identificar os KGIs mais importantes para um determinado ambiente e monitorar de perto os KPIs que mais contribuem com eles.

SLM através do BSC
Uma maneira de simplificar o processo de SLM é utilizar o BSC. O BSC, desenvolvido por Kaplan e Norton em 1990 é baseado na idéia de que a avaliação de uma organização não deve estar restrita às tradicionais medidas de desempenho financeiro, mas também deveria ser complementada com medidas relativas a satisfação do cliente, processos internos e a habilidade de inovar. Osresultados conseguidos dentro destas perspectivas adicionais devem garantir resultados financeiros futuros.


Kaplan e Norton propõem uma estrutura em 3 camadas para estas perspectivas: missão, objetivos e medidas. Para colocar em ação o BSC, as organizações devem traduzir cada uma das perspectivas nas métricas ou indicadores e medidas correspondentes que avaliem a situação atual.

Estas avaliações devem ser repetidas periodicamente e serem confrontadas com as metas estabelecidas anteriormente.

O framework genérico do BSC pode ser traduzido em necessidades mais específicas de uma função de TI, seus projetos e processos específicos, tais como “Definição e Gerenciamento de Níveis de serviço”. Reconhecendo que TI é um fornecedor de serviço interno, as rerspectivas propostas no BSC genérico devem ser alteradas de acordo com as seguintes perspectivas:
distribuição corporativa, orientação ao cliente, excelência operacional e orientação futura. Um BSC de SLM genérico que pode ser utilizado para medir e gerenciar o processo de SLM é mostrado na tabela abaixo. Na construção do BSC deste SLM genérico, foram utilizadas medidas de desempenho definidas em vários trabalhos do autor e no CobiT Management Guidelines.


BSC genérico para um SLM
Orientação para o Usuário
Como os usuários vêem o processo SLM?
Contribuição para a Organização
Como a gerência vê o processo SLM?

Missão
Atender aos requisitos do usuário e aumentar a sua satisfação
Objetivos
Desempenho de acordo com o nível de serviço acordado Satisfação do usuário
Medidas/indicadores
Porcentagem de aplicações e serviços que atendem os SLAs
Nível de satisfação dos usuários nas pesquisa
Missão
Obter uma contribuição razoável para os negócios a partir do processo SLM
Objetivos
Controle de despesas para o SLM Máximo de impacto nos negócios
Medidas/indicadores
Despesas reais versus as planejadas Porcentagem de processos dependentes de TI cobertos pelos SLAs
Excelência Operacional
O quanto efetivo é o processo SLM?
Orientação para o Futuro
A área de TI está preparada para atender os desafios futuros do processo SLM?
Missão
Processo SLM efetivo
Objetivos
Melhoria no processo SLM
Gerenciamento de contas eficiente
Notificações eficientes de não cumprimento de prazos
Relatórios eficientes de desempenho
Processo de implementação eficiente
Medidas/indicadores
Nível de maturidade do processo SLM
Número de falhas na presença de reuniões
Número de falhas no fornecimento de relatórios de não cumprimento de prazos em “x” horas
Número de falhas no fornecimento de relatórios de desempenho conforme determinado previamente
Número de implementações em atraso
Missão
Desenvolver oportunidades para responder a futuros desafios
Objetivos
Treinamento e educação permanentes em SLM para o pessoal de TI e usuários finais Pesquisa em SLM
Medidas/indicadores
Porcentagem do orçamento total de TI para o processo educacional em SLM
Porcentagem do pessoal de TI e usuários finais com treinamento completo em SLM
Porcentagem da conta de TI gasta com pesquisas em SLM

A perspectiva de Orientação para o Usuário representa a avaliação do usuário do processo SLM e representa a satisfação do usuário baseada em pesquisas e nos níveis de serviço atendidos para as aplicações e operações.

A perspectiva de Excelência Operacional representa os processos SLM empregados para entregar os serviços solicitados incluindo o nível de maturidade do processo SLM como um todo.

A perspectiva de Orientação para o Futuro representa os recursos humanos e tecnológicos necessários para que o processo SLM entregue seus serviços de forma contínua.

A perspectiva da Contribuição para a Organização representa o valor de negócio agregado a partir do processo SLM com a porcentagem dos processos de negócio cobertos pelas SLAs.

Na construção de um SLM utilizando o BSC específico para a organização, várias etapas precisam ser seguidas. Primeiro, o conceito da técnica SLM-BSC precisa ser apresentada à alta administração, a gerência de TI e aos colaboradores envolvidos no processo SLM e então uma equipe do projeto SLM deve ser criada. Em segundo lugar, durante a fase de coleta de dados, as informações são coletadas nas métricas definidas para o SLM. As métricas identificadas devem ser específicas, mensuráveis, aceitáveis, realistas, realizáveis. Desta forma, a organização evita o desenvolvimento ou a aceitação de métricas para as quais informações completas ou acuradas não podem ser coletadas, ou que levam a ações contrárias aos melhores interesses da organização.

Finalmente, baseado nos princípios de Kaplan e Norton e em um modelo genérico, um SLM-BSC específico para a organização, como apresentado aqui, pode ser desenvolvido.

Conclusão
SLAs e SLM são mecanismos efetivos para que uma organização resolva problemas de não conseguir o serviço desejado. Estabelecer um processo eficiente de SLM é uma tarefa complexa e difícil que requer recursos multidisciplinares e experiência. O modelo CobiT é certamente um mecanismo muito útil para a definição e implementação de um processo SLM maduro pela identificação de objetivos de controle, modelos de maturidade, KGIs, KPIs e fatores críticos de sucesso. O modelo genérico do BSC também é um instrumento útil que, através da tradução em um SLM-BSC, pode simplificar o processo SLM. Tanto o CobiT como o BSC podem permitir que uma organização tenha SLAs mais balanceados e um processo SLM mais maduro com o objetivo final de atingir os objetivos de negócio.


Win Van Grembergen, http://www/isaca.org
Tradução de Fátima Pires (fatima@ccuec.unicamp.br)

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

COBIT



COBIT (Control Objectives for Information and related Technology)

INTRODUÇÃO
Atualmente, é impossível imaginar uma empresa sem uma forte área de sistemas de informações (TI), para manipular os dados operacionais e prover informações gerenciais aos executivos para tomadas de decisões. A criação e manutenção de uma infra-estrutura de TI, incluindo profissionais especializados requerem altos investimentos. Algumas vezes a alta direção da empresa coloca restrições aos investimentos de TI por duvidarem dos reais benefícios da tecnologia.
Entretanto, a ausência de investimentos em TI pode ser o fator chave para o fracasso de um empreendimento em mercados cada vez mais competitivos. Por outro lado, alguns gestores de TI não possuem habilidade para demonstrar os riscos associados ao negócio sem os corretos investimentos em TI. Para melhorar o processo de análise de riscos e tomada de decisão é necessário um processo estruturado para gerenciar e controlar as iniciativas de TI nas empresas, para garantir o retorno de investimentos e adição de melhorias nos processos empresariais.
Esse novo movimento é conhecido como Governança em TI, ou "IT Governance".
O termo "IT governance" é definido como uma estrutura de relações e processos que dirige e controla uma organização a fim de atingir seu objetivo de adicionar valor ao negócio através do gerenciamento balanceado do risco com o retorno do investimento de TI.
Para muitas organizações, a informação e a tecnologia que suportam o negócio representa o seu mais valioso recurso. Além disso, num ambiente de negócios altamente competitivo e dinâmico é requerido uma excelente habilidade gerencial, onde TI deve suportar as tomadas de decisão de forma rápida, constante e com custos cada vez mais baixos.
Não existem dúvidas sobre o benefício da tecnologia aplicada aos negócios.
Entretanto, para serem bem sucedidas, as organizações devem compreender e controlar os riscos associados no uso das novas tecnologias. O CobiT (Control Objectives for Information and related Technology) é uma ferramenta eficiente para auxiliar o gerenciamento e controle das iniciativas de TI nas empresas.


DEFINIÇÃO
O CobiT é um guia para a gestão de TI recomendado pelo ISACF (Information Systems Audit and Control Foundation, http://www.isaca.org/). O CobiT inclui recursos tais como um sumário executivo, um framework, controle de objetivos, mapas de auditoria, um conjunto de ferramentas de implementação e um guia com técnicas de gerenciamento.
As práticas de gestão do CobiT são recomendadas pelos peritos em gestão de TI que ajudam a otimizar os investimentos de TI e fornecem métricas para avaliação dos resultados. O CobiT independe das plataformas de TI adotadas nas empresas.
O CobiT é orientado ao negócio. Fornece informações detalhadas para gerenciar processos baseados em objetivos de negócios. O CobiT é projetado para auxiliar três audiências distintas:
  • Gerentes que necessitam avaliar o risco e controlar os investimentos de TI em uma organização.
  • Usuários que precisam ter garantias de que os serviços de TI que dependem os seus produtos e serviços para os clientes internos e externos estão sendo bem gerenciados.
  • Auditores que podem se apoiar nas recomendações do CobiT para avaliar o nível da gestão de TI e aconselhar o controle interno da organização.


O CobiT está dividido em quatro domínios:
  1. Planejamento e organização.
  2. Aquisição e implementação.
  3. Entrega e suporte.
  4. Monitoração.
Os quatro domínios do CobiT

A figura acima ilustra a estrutura do CobiT com os quatro domínios, onde claramente está ligado aos processos de negócio da organização. Os mapas de controle fornecidos pelo CobiT auxiliam os auditores e gerentes a manter controles suficientes para garantir o acompanhamento das iniciativas de TI e recomendar a implementação de novas práticas, se necessário. O ponto central é o gerenciamento da informação com os recursos de TI para garantir o negócio da organização.


DESENVOLVIMENTO DO COBIT
A primeira publicação foi em 1996 enfocando o controle e análise dos sistemas de informação. Sua segunda edição em 1998 ampliou a base de recursos adicionando o guia prático de implementação e execução. A edição atual, já coordenada pelo IT Governance Institute, introduz as recomendações de gerenciamento de ambientes de TI dentro do modelo de maturidade de governança.
O CobiT recebe um conjunto de contribuições de várias empresas e organismos internacionais, entre eles:
  • Padrões técnicos da ISO, EDIFACT, etc.
  • Os códigos de conduta emitidos pelo Conselho de Europa, OECD, ISACA, etc.
  • Critérios de qualificação para TI e processos: ITSEC, TCSEC, ISO 9000, SPICE, TickIT, etc.
  • Padrões profissionais para controle internos e auditoria: COSO, IFAC, AICPA, CICA, ISACA, IIA, PCIE, GAO, etc.
  • Práticas e exigências dos fóruns da indústria (ESF, I4) e das plataformas recomendadas pelos governos (IBAG, NIST, DTI), etc.
  • Exigências das indústrias emergentes como operação bancária, comércio eletrônico e engenharia de software.


DOMÍNIOS DO COBIT
Cada domínio (planejamento, organização, aquisição, implementação, entrega, suporte e monitoração) cobre um conjunto de processos para garantir a completa gestão de TI, somando 34 processos:


Planejamento e Organização
  1. Define o plano estratégico de TI
  2. Define a arquitetura da informação
  3. Determina a direção tecnológica
  4. Define a organização de TI e seus relacionamento
  5. Gerencia os investimento de TI
  6. Gerencia a comunicação das direções de TI
  7. Gerencia os recursos humanos
  8. Assegura o alinhamento de TI com os requerimentos externos
  9. Avalia os riscos
  10. Gerencia os projetos
  11. Gerencia a qualidade


Aquisição e implementação
  1. Identifica as soluções de automação
  2. Adquire e mantém os softwares
  3. Adquire e mantém a infra-estrutura tecnológica
  4. Desenvolve e mantém os procedimentos
  5. Instala e certifica softwares
  6. Gerencia as mudanças


Entrega e suporte
  1. Define e mantém os acordos de níveis de serviços (SLA)
  2. Gerencia os serviços de terceiros
  3. Gerencia a performance e capacidade do ambiente
  4. Assegura a continuidade dos serviços
  5. Assegura a segurança dos serviços
  6. Identifica e aloca custos
  7. Treina os usuários
  8. Assiste e aconselha os usuários
  9. Gerencia a configuração
  10. Gerencia os problemas e incidentes
  11. Gerencia os dados
  12. Gerencia a infra-estrutura
  13. Gerencia as operações


Monitoração
  1. Monitora os processos
  2. Analisa a adequação dos controles internos
  3. Prove auditorias independentes
  4. Prove segurança independente


BENEFÍCIOS
Na era da dependência eletrônica dos negócios e da tecnologia, as organizações devem demonstrar controles crescentes em segurança. Cada organização deve compreender seu próprio desempenho e deve medir seu progresso. O benchmarking com outras organizações deve fazer parte da estratégia da empresa para conseguir a melhor competitividade em TI. As recomendações de gerenciamento do CobiT com orientação no modelo de maturidade em governança auxiliam os gerentes de TI no cumprimento de seus objetivos alinhados com os objetivos da organização.
Os guidelines de gerenciamento do CobiT focam na gerência por desempenho usando os princípios do balanced scorecard. Seus indicadores chaves identificam e medem os resultados dos processos, avaliando seu desempenho e alinhamento com os objetivos dos negócios da organização.


FERRAMENTAS DE GERENCIAMENTO
Os modelos de maturidade de governança são usados para o controle dos processos de TI e fornecem um método eficiente para classificar o estágio da organização de TI. A governança de TI e seus processos com o objetivo de adicionar valor ao negócio através do balanceamento do risco e returno do investimento podem ser classificados da seguinte forma:
  • 0 Inexistente
  • 1 Inicial / Ad Hoc
  • 2 Repetitivo mas intuitivo
  • 3 Processos definidos
  • 4 Processos gerenciáveis e medidos
  • 5 Processo otimizados
Essa abordagem é derivada do modelo de maturidade para desenvolvimento de software, Capability Maturity Model for Software (SW-CMM), proposto pelo Software Engineering Institute (SEI). A partir desses níveis, foi desenvolvido para cada um dos 34 processos do CobiT um roteiro:
Onde a organização está hoje
O atual estágio de desenvolvimento da industria (best-in-class)
O atual estágio dos padrões internacionais
Aonde a organização quer chegar
Os fatores críticos de sucesso definem os desafios mais importantes ou ações de gerenciamento que devem ser adotadas para colocar sobre controle a gestão de TI. São definidas as ações mais importantes do ponto de vista do que fazer a nível estratégico, técnico, organizacional e de processo.
Os indicadores de objetivos definem como serão mensurados os progressos das ações para atingir os objetivos da organização, usualmente expressos nos seguintes termos:
  • Disponibilidade das informações necessárias para suportar as necessidades de negócios
  • Riscos de falta de integridade e confidencialidade das informações
  • Confirmação de confiabilidade, efetividade e conformidade das informações.
  • Eficiência nos custos dos processos e operações


Indicadores de desempenho definem medidas para determinar como os processos de TI estão sendo executados e se eles permitem atingir os objetivos planejados; são os indicadores que definem se os objetivos serão atingidos ou não; são os indicadores que avaliam as boas práticas e habilidades de TI.


BIBLIOGRAFIA RECOMENDADA
http://www.itgovernance.org/ ou no site do Information System Audit & Control Association
http://www.isaca.org/.

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Quanto ganha o profissional de TI em São Paulo?

Seu salário está alinhado com a média do mercado?
Se você trabalha na grande São Paulo, já é possível ter uma idéia de quanto ganham os profissionais da área em diversos cargos e níveis da carreira.
De acordo com um levantamento realizado pela Desix, empresa focada em recrutamento e seleção de profissionais de TI, os maiores salários são de executivos de contas e os menores dos analistas de suporte de vendas.
A tabela da Desix foi composta a partir de uma média simples entre os clientes da empresa e reflete valores pagos apenas na grande São Paulo.
A Fonte não divulgou se o tipo de contratação é CLT ou PJ. Mas há um forte indício de ser CLT.
Em destaque Analista e Arquiteto de Teste.
Confira a tabela de salários de TI para São Paulo
Cargo Salário (R$)
Júnior Pleno Sênior
Administrador de banco de dados (DBA) 3.922,33 5.255,67 8.376,33
Administrador de rede 3.953,71 4.411,43 6.242,86
Analista de dados 3.200,00 4.500,00 6.000,00
Analista de Infra 4.200,00 5.000,00 6.500,00
Analista de microinformática 2.700,00 3.400,00 3.850,00
Analista de negócios 5.096,00 5.675,00 6.033,00
Analista de org. e métodos 2.500,00 4.500,00 5.000,00
Analista de processos 2.500,00 3.200,00 4.500,00
Analista de produção 3.973,00 4.106,67 5.002,33
Analista de projetos de sistemas 3.713,67 5.215,33 7.415,33
Analista de segurança de informações 4.406,00 4.588,00 6.488,33
Analista de sistemas 4.761,33 6.284,33 7.620,33
Analista de sistemas de internet 6.875,00 8.988,00 9.123,00
Analista de suporte de vendas 800,00 1.200,00 1.800,00
Analista de suporte ERP 2.000,00 3.000,00 4.000,00
Analista de suporte Linux 1.700,00 4.500,00 7.500,00
Analista de suporte Mainframe 3.000,00 4.200,00 6.000,00
Analista de suporte Notes 1.800,00 2.800,00 3.700,00
Analista de suporte Redes 2.100,00 3.000,00 4.500,00
Analista de suporte técnico 4.208,00 4.505,00 5.056,00
Analista de suporte Unix 2.500,00 3.200,00 4.500,00
Analista de suporte Windows 1.000,00 1.500,00 2.000,00
Analista de telecomunicações 3.608,00 5.725,33 7.992,33
Analista de testes 2.000,00 3.000,00 4.000,00
Analista programador mainframe 2.200,00 3.800,00 5.800,00
Analista programador .NET 2.600,00 4.000,00 5.500,00
Analista programador Abap 4.200,00 7.200,00 9.500,00
Analista programador ASP 2.500,00 4.000,00 6.500,00
Analista programador C++ 3.000,00 4.200,00 7.000,00
Analista programador Delphi 2.500,00 3.800,00 5.500,00
Analista programador Java 3.000,00 4.500,00 6.000,00
Analista programador jr. - micro 2.759,00 3.432,00 3.824,00
Analista programador PHP 3.000,00 4.500,00 6.000,00
Analista programador progress 4.000,00 6.000,00 7.500,00
Analista programador Visual Basic 2.000,00 3.000,00 4.500,00
Analista segurança de sistemas 4.500,00 6.000,00 7.000,00
Arquiteto de testes 3.000,00 4.200,00 5.500,00
Auditor de sistemas 3.000,00 4.000,00 4.500,00
Chefe de sistemas 7.282,00 8.583,00 11.325,00
Chefe de suporte técnico 6.640,00 8.664,00 12.055,00
Chefe de telecomunicações 6.875,00 11.253,00 12.833,00
Chefe programação de sistemas 7.979,00 8.367,00 10.550,00
Consultor TI especializado 6.057,00 7.725,00 11.034,00
Consultor TI funcional 5.708,00 6.174,00 8.561,00
Coordenador de projetos de sistemas 7.450,00 10.248,00 12.477,00
Coordenador de suporte técnico 4.174,52 5.489,02 7.911,22
Engenheiro de sistemas - software 5.541,00 5.550,00 5.562,00
Engenheiro de telecomunicações 4.485,67 6.421,67 7.934,00
Executivo de contas 20.000,00 23.000,00 26.000,00
Gerente de contas TI 15.000,00 18.000,00 22.000,00
Gerente de e-commerce 13.334,00 15.156,00 20.622,00
Gerente de operação 6.000,00 8.000,00 11.800,00
Gerente de processos 12.000,00 12.500,00 15.000,00
Gerente de produção de operações 6.303,00 8.372,00 12.193,00
Gerente de projetos de sistemas 12.995,00 13.873,00 15.596,00
Gerente de segurança de sistemas sr. 11.060,00 12.192,00 14.333,00
Gerente de sistemas 15.596,00 18.088,00 22.529,00
Gerente de suporte técnico 11.857,00 11.993,00 14.423,00
Gerente de telecomunicações 16.678,00 19.552,00 24.260,00
Operador de computador 1.954,67 2.381,67 2.934,33
Programador .NET 2.500,00 3.500,00 5.000,00
Programador Abap 4.000,00 7.000,00 9.000,00
Programador ASP 1.500,00 2.000,00 3.000,00
Programador Delphi 2.000,00 3.500,00 5.000,00
Programador Java 2.500,00 3.800,00 5.500,00
Programador Mainframe 2.000,00 3.500,00 5.000,00
Programador PHP 2.500,00 3.500,00 5.000,00
Programador Visual Basic 1.800,00 2.800,00 4.000,00
Técnico de celular 900,00 1.200,00 1.800,00
Técnico de hardware 900,00 1.200,00 1.800,00
Técnico de microinformática 900,00 1.200,00 1.800,00
Técnico de suporte 900,00 1.200,00 1.800,00
Técnico de telecomunicações 3.072,33 4.323,67 4.955,00
Webdesigner 3.814,00 4.613,00 5.457,00
Webmaster 6.139,00 6.798,00 8.121,00
Fonte: INFO


QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Como Elaborar Análise de Riscos?

Essa publicação tem por objetivo sanar algumas dúvidas de leitores preocupados em elaborar análise de risco para diferentes escopos.

O primeiro passo é identificar o risco.

Conhecendo o risco a que se expõem as empresas, fica mais fácil para elas aplicar as soluções de segurança. Se não conhecerem o risco, dificilmente saberão que mecanismos devem aplicar. Assim, a primeira coisa que recomendamos é fazer uma análise dos riscos e classificá-los segundo sua prioridade. Dependerá da prioridade e dos recursos exigidos que os riscos sejam atenuados, eliminados ou assumidos, caso o impacto não seja maior. Sempre há uma faixa dentro da qual tenho um risco que é inaceitável e um risco aceitável; tento ficar em uma faixa no meio, que é a "administração do risco".

Há vários tipos de riscos do ponto de vista tecnológico e outros riscos que não são tecnológicos. Um risco tecnológico, por exemplo, é não ter um servidor bem configurado para ter senhas seguras. Em muitos casos, o servidor aceita uma senha que seja simplesmente 123. Se configurar o servidor de forma a me exigir uma senha que contenha números, letras e símbolos, estou automaticamente aumentando a segurança. O risco é que, se não tenho senhas completas, qualquer pessoa pode acessar documentos, informações confidenciais ou e-mails. Os riscos não-tecnológicos são, por exemplo, a fuga das informações. Isso pode ocorrer no simples fato de botar um papel no cesto de lixo ou falar no celular no elevador, divulgando informações da empresa na frente de outras pessoas. Esse é um risco que tem a ver com processos, e não com tecnologias. As pessoas precisam ter incorporado em sua cultura o tema da segurança, para colocar uma senha segura, não falar no elevador sobre qualquer assunto, não atirar papéis importantes no cesto de lixo.

A análise de riscos depende do escopo do projeto, podendo ser: Tecnológico, Humano, Processos e Físico.

Análise de Riscos para o escopo Tecnológico:

Em que devemos pensar?
A análise de riscos realizada no ambiente tecnológico pretende alcançar o conhecimento das configurações e da disposição topológica dos ativos de tecnologia que compõem toda a infra-estrutura de suporte das informações para comunicação, processamento, tráfego e armazenamento.

Que aspectos devemos analisar?
  • Os ativos são do tipo aplicativo e equipamento, sem deixar de considerar também a sensibilidade das informações que são manipuladas por eles.
  • Os usuários que os utilizam.
  • A infra-estrutura que lhes oferece suporte.

Análise de Riscos para o escopo Humano:

Em que devemos pensar?
A análise de riscos também se destina à compreensão da maneira como as pessoas se relacionam com os ativos.
Assim, é possível detectar a quais vulnerabilidades provenientes de ações humanas se encontram submetidos os ativos, sendo igualmente possível fazer recomendações para aumentar a segurança no trabalho humano e garantir a continuidade dos negócios da organização. Essa análise pretende inicialmente identificar vulnerabilidades nos ativos do tipo usuário e organização.

Que aspectos devemos analisar?
  • O nível de acesso que as pessoas têm na rede ou nos aplicativos.
  • As restrições e as permissões que devem ter para realizar suas tarefas com os ativos.
  • O nível de capacitação e a formação educativa a que precisam ter acesso para manipulá-los, etc.

Análise de Riscos para o escopo Processos:

Em que devemos pensar?
A análise dos fluxos de informações da organização e a maneira como elas transitam de um lado para outro, como são administrados os recursos em relação à organização e à manutenção. Dessa forma, será possível identificar os links entre as atividades e os insumos necessários para sua realização com o objetivo de identificar as vulnerabilidades que podem afetar a confidencialidade, a disponibilidade e a integridade das informações e, por conseguinte, do negócio da organização.
Nesse escopo, o ativo de enfoque principal é do tipo usuário e informação.

Que aspectos devemos analisar?
  • Identificar as pessoas envolvidas no fluxo de informações; é possível avaliar a necessidade real de acesso aos ativos que elas têm.
  • Avaliar o impacto proveniente do uso indevido das informações por pessoas não-qualificadas.

Análise de Riscos para o escopo Físico:

Em que devemos pensar?
A análise física de segurança busca identificar, na infra-estrutura física do ambiente em que os ativos se encontram, vulnerabilidades que possam trazer algum prejuízo às informações e a todos os outros ativos. O enfoque principal desse escopo de análise são os ativos do tipo organização, pois são os que fornecem o suporte físico ao ambiente em que estão sendo manipuladas as informações.

Que aspectos devemos analisar?
  • Identificar possíveis falhas na localização física dos ativos tecnológicos.
  • Avaliar o impacto de acessos indevidos às áreas nas quais se encontram os ativos tecnológicos.
  • Avaliar o impacto dos desastres ambientais na infra-estrutura tecnológica da empresa.

A segurança não é somente tecnologia. Vemos a segurança na informática como algo fundamentado sobre três pilares: de um lado, a tecnologia; de outro, todos os processos de administração e operação; e, por último, o treinamento das pessoas, para que conheçam os processos, saibam como implementá-los, conheçam a tecnologia e a configurem, administrem e operem de forma eficiente. Com esses três pilares, acreditamos que se consiga obter uma infra-estrutura muito mais segura do que se contássemos apenas com uma boa tecnologia.

Fonte: FAPI

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Certificação pode fazer diferença no começo da carreira

Investir na formação profissional na área e na hora certas resulta em melhor colocação no mercado e possibilidades de ascensão profissional

Em uma área supercompetitiva como é a de tecnologia da informação, a certificação em determinada plataforma pode determinar, durante um processo seletivo, a contratação. Dentro da empresa, ela ajuda a galgar postos e, é claro, conquistar o desejado aumento salarial.

Uma certificação a mais no currículo não faz mal a ninguém. Mas é preciso tato e uma dose de esperteza para escolher a sua especialização. Boa parte dos cursos que certificam não são baratos e a empresa nem sempre pode ou quer pagar.

Como então escolher, entre as várias opções no mercado? Quando e quanto investir para melhorar a posição profissional? Como se preparar para fazer? Que tipo de curso realmente dá um upgrade na carreira? Quais são as certificações mais procuradas e mais cobiçadas?

Para responder estas e outras perguntas, o IT Web preparou uma série de quatro reportagens. Os textos serão veiculados semanalmente a partir desta segunda-feira (11/01). O objetivo é trazer informações atualizadas para direcionar melhor sua carreira, de forma que você obtenha maior retorno para seus esforços.

O conhecimento adquirido num curso é interessante em qualquer fase. Além de ser inalienável, demonstra aos seus superiores a imagem de pessoa dinâmica e que busca estar sempre atualizada em sua área de atuação. Existem, entretanto, dois períodos da carreira em que a certificação pode ter um peso decisivo: quando ainda não se tem um diploma universitário ou no começo do exercício profissional, após concluir o ensino superior.

"Nunca trabalhei com um profissional certificado que fosse ruim", revela Herbert Moroni, autor de livros sobre C#, VB.NET, AJAX, ASP.NET. O especialista, que já liderou equipe de desenvolvimento de sistemas para a internet utilizando a plataforma .NET da Microsoft em projetos para o Brasil, EUA e Angola, explica que, na maioria dos casos, a certificação comprova o conhecimento do conteúdo exigido na prova. "Isso é decisivo para um recrutador quando ele avalia a capacidade técnica do candidato."

Para escolher a certificação mais adequada, é preciso levar em conta a área de atuação ou aquela em que se deseja trabalhar. Se o candidato já trabalha em desenvolvimento em Java, .NET, Windows Server, Linux, SAP ou Oracle, por exemplo, é recomendável que tente o maior grau de certificação possível nessa área.

Uma dica para quem não tem dinheiro para bancar um curso caro é buscar antes certificações que não exijam grande investimento. Passado um tempo, é possível pleitear com o chefe alguma ajuda de custo para pagamento de parte do estudo. Para isso, o profissional deve dirigir sua especialização para as demandas da empresa.

Mas fique atento. Um currículo recheado de certificados não é garantia de salário maior. Recomenda-se ter fluência no idioma inglês (o espanhol também está cada vez mais requisitado). Além disso, os recrutadores estão de olho em outros atributos: capacidade de comunicação, facilidade para trabalhar em equipe, dinamismo e honestidade, só para citar alguns.

Fique de olho e acompanhe as próximas reportagens da série especial sobre certificações.

Fonte: IT Web

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Certificação - CTAL - Advanced Level

CTAL é a sigla para Certified Tester Advanced Level.

Trata-se da certificação de nível avançado do ISTQB destinado a pessoas que possuam experiência em suas carreiras de teste de software. Isto inclui pessoas em papéis como Testadores, Analistas de Testes, Engenheiros de Testes, Consultores de Teste, Gerentes de Teste, Aceitação do Usuário e Desenvolvedores de Software. Esta certificação também é adequada para quem quer um entendimento mais profundo sobre testes de software, tais como Gerentes de Projeto, Gerentes de Qualidade, Gerentes de Desenvolvimento de Software, Analistas de Negócios, Diretores de TI e Gestores.

Para receber esta certificação os candidatos devem possuir o CTFL e comprovar sua experiência na prática para ser considerado qualificado para o CTAL.

O CTAL é dividido em três tipos:

•CTAL-TA: Advanced Level Test Analyst
•CTAL-TM: Advanced Level Test Manager
•CTAL-TTA: Advanced Level Technical Test Analyst

Objetivo:

Assegurar a compreensão em técnicas de teste, gestão e melhoria do processo de teste.

Pré-Requisitos:

•Comprovar no mínimo 3 anos em tempo integral atuando em Teste de Sistemas, Desenvolvimento, Qualidade ou áreas correlatas.
•Certificação ISTQB Certified Tester, Foundation Level (CTFL)

Leia mais...

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Certificação - CTFL - Foundation Level

Certificação - CTFL - Foundation Level
CTFL é a sigla para Certified Tester Foundation Level.

Trata-se da certificação de nível fundamental destinado a qualquer pessoa envolvida em testes de software. Isto inclui as pessoas em papéis como Testadores, Analistas de Testes, Engenheiros de Testes, Consultores de Teste, Gerentes de Teste, Aceitação e Desenvolvedores de Software.

Esta certificação também é adequada para quem quer um entendimento básico de teste de software, tais como Gerentes de Projeto, Gerentes de Qualidade, Gerentes de Desenvolvimento de Software, Analistas de Negócios, Diretores de TI e Gestores.

Os possuidores da certificação CTFL serão capazes de ascender para níveis mais elevados de qualificação de testes de software pelo ISTQB.

Objetivo:

•Garantir uma ampla compreensão dos fundamentos e conceitos-chave em Teste de Software.

Pré-requisitos:

•Nenhum

Leia mais...

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Sobre a Certificação CTFL - ISTQB

Certified Tester Foundation Level - CTFL

Objetivos da qualificação internacional
(adaptado da reunião do ISTQB em Sollentuna, Novembro de 2001)

•Estar apto a comparar a prática do teste entre os diferentes países
•Capacitar os testadores a trocar conhecimento mais facilmente entre as comissões.
•Permitir com que projetos multi-nacionais / internacionais tenham uma compreensão comum do empreendimento do teste.
•Aumentar o número de testadores qualificados ao redor do mundo.
•Ter mais impacto como uma iniciativa baseada internacionalmente do que qualquer abordagem de um país específico.
•Desenvolver um corpo comum internacional de compreensão e conhecimento sobre teste e terminologias através do syllabus e aumentar o nível de conhecimento sobre teste para todos os participantes.
•Promover o teste como uma profissão em mais países.
•Capacitar testadores a obter qualificação reconhecida na sua linguagem nativa.
•Permitir o compartilhamento de conhecimentos e recursos entre os países.
•Prover o reconhecimento internacional de testadores e desta qualificação junto a participação de muitos países.

Requisitos básicos para esta qualificação
O critério para fazer o exame do ISTQB (Certified Tester Foundation Level - CTFL) é que o candidato tenha um interesse em teste de software. No entanto, é altamente recomendável que o candidato também:

•Tenha um mínimo conhecimento em qualquer desenvolvimento de software ou teste de software, seis meses de experiências em um sistema ou teste de aceite ou desenvolvedor de software.
•Fazer o curso que é autorizado pelos padrões do ISTQB (por uma comissão nacional reconhecida)

Histórico do CTFL
A certificação independente de testadores de software começou no Reino Unido com a British Computer Society´s Information Systems Examination Board (ISEB), quando uma comissão de teste de software surgiu em 1998 (www.bcs.org.uk/iseb). Em 2002, ASQF na Alemanha começou a dar suporte a um esquema de qualificação ao testador (www.asqf.de). Este syllabus é baseado no ISEB e ASQF syllabi; inclui um conteúdo organizado, atualizado e novo, e a ênfase é dada aos tópicos que fornecem ajuda mais prática aos testadores.

Um Certified Tester Foundation Level - CTFL (ex: ISEB, ASQF ou outra organização reconhecida por uma comissão nacional do ISQTB) obtido por alguém, antes que o Certificado Internacional fosse criado, será considerado equivalente ao certificado internacional. Este certificado não expira e não precisa ser renovado.

Com a participação de cada país, aspectos locais são controlados pela comissão nacional reconhecida pelo ISTQB. As responsabilidades da comissão nacional são especificadas pelo ISTQB, mas são implementadas em cada país. Dentre as obrigações das comissões dos países estão a autorização para prover treinamentos e a ministrar os exames.

Leia mais...

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin:

Certificações em Teste de Software

Na disciplina de Teste de Software não existe um padrão único no mercado, existem vários autores e várias instituições que difundem conceitos diferentes. Por este motivo, cada instituição acabou criando sua própria certificação, cada uma adotando os seus critérios e escopo de conhecimento para a prova.

Se você busca uma certificação, é muito importante você obter o Syllabus do exame que você pretende realizar, que é o currículo do conteúdo proposto para a prova. Muitas instituições já fornecem um corpo de conhecimento para a prova, no caso da ALATS existe um livro Base de Conhecimento que é a leitura obrigatória para o exame.

Veja abaixo a lista de instituições que oferecem certificações em testes de software:

ALATS - Certificação Brasileira de Teste de Software (CBTS)

ISEB Foundation Certificate in Software Testing
Este exame tem a vantagem de poder ser feito através da PROMETRIC em
qualquer Centro de Testes no Brasil. Não é necessário esperar a próxima
agenda disponível. Existem kit's com questões em inglês para você se
preparar para este exame.

Certified Tester, Foundation Level - BSTQB Brasil
O BSTQB representa o ISTQB que é um braço da ISEB. O Syllabus da ISEB e do ISTQB são os mesmos. A vantagem de realizar o exame do BSTQB é o idioma português.
Quality Improvement Associate Certification (CQIA)

Certified Software Test Professional (CSTP)

Certified Software Tester - QAI Brasil
Fornece este exame há mais de 10 anos. O nível de complexidade dos exames do QAI é mais alto que os das outras instituições.

QABI Consultoria
Compartilhar no Facebook:
Compartilhar no Linkedin: