sábado, 25 de dezembro de 2010

Frases espirituosas sobre desenvolvimento de software

  • Há duas formas de construir um projeto de software: Uma maneira de fazer isso deve ser tão simples que, obviamente, não deixe deficiências, e a outra forma é a de torná-lo tão complicado que não percebam as evidentes deficiências. O primeiro método é muito mais difícil. – CAR Hoare
  • Se construtores de edifícios construíssem seus prédios como os programadores escrevem seus programas, o primeiro pica-pau que viesse poderia destruir uma civilização. – Gerald Weinberg
  • Hoje a programação é uma corrida entre os engenheiros de software para tentar construir maiores e melhores programas à prova de idiotas, e o Universo tentando produzir maiores e melhores idiotas. Até agora, o Universo está ganhando. – Rich Cook
  • Java pode ser um bom exemplo do que uma linguagem de programação deve ser. Mas as aplicações escritas em Java são um bom exemplo de como as aplicações não devem ser.
  • Análise de sistemas é como criar uma criança; você pode fazer um estrago imenso, mas não pode garantir sucesso. – Tom DeMarco
  • A maioria dos softwares atuais são como as pirâmides do Egito, com milhões de blocos empilhados uns em cima dos outros, nenhuma integridade estrutural, feita apenas pela força bruta e milhares de escravos. – Alan Kay
  • Andar sobre a água e desenvolver software a partir de uma especificação é fácil. Se ambos estiverem congelados...

quarta-feira, 15 de dezembro de 2010

Avaliação de software de gerenciamento financeiro pessoal

Há muito tempo eu uso um software de gerenciamento financeiro pessoal que é executado no Palm, o Hand Money, este software é excelente e atende todas as minhas necessidades de acompanhamento das finanças, porém, o meu Palm já está muito velho e os Palm's em geral estão praticamente em desuso.

Como o fabricante do Hand Money não desenvolveu outra versão do aplicativo para uma plataforma diferente, eu resolvi pesquisar um novo software de finanças pessoais para adotar. Os meus requisitos para este novo software eram:

  • Permitir a criação de diversas contas (para que eu possa controlar mais de uma conta bancária, cartões, investimentos, etc.);
  • Cadastrar lançamentos previstos para datas futuras com repetições periódicas;
  • Ter uma separação clara entre lançamentos previstos e os efetivamente realizados;
  • Identificar os favorecidos em cada lançamento;
  • Permitir categorizar os lançamentos;
  • Ter consulta aos saldos previstos das contas;
  • Ter consulta de um resumo de lançamentos agrupados por categoria;
  • Importar arquivos de extrato bancário;
  • Além de dar preferência para aplicativos que executem na web, para não me deixar preso a uma plataforma ou hardware específico;
  • E, por último, não ter mensalidade para utilização do software (afinal, eu quero um software de gerenciamento financeiro e não mais um custo fixo no meu orçamento).

Com essas definições, eu testei mais de 20 softwares de gerenciamento financeiro, brasileiros e estrangeiros. Segue abaixo um resumo de cada aplicativo que eu avaliei (começando dos que eu considerei melhor até os piores) e a minha decisão final:

Minhas Economias: http://www.minhaseconomias.com.br

O único requisito que ele não atende é o cadastramento do favorecido, no mais, o aplicativo é excelente. Pode ser cadastrado um orçamento separado e depois compará-lo com o realizado. A importação de arquivos é muito boa, permitindo uma série de ajustes no momento da importação. Os dados também podem ser exportados para planilha ou PDF. As mensagens que eu enviei com dúvidas para o fornecedor foram respondidas prontamente.

O aplicativo é grátis para o usuário final, a proposta do site é obter receita com publicidade, mas até o momento eles não têm nenhum anúncio sendo exibido. Isso me deixa em dúvida com relação à continuidade do serviço em longo prazo.

Contas Online: http://www.contasonline.com.br

Ele atende a todos os requisitos e tem uma interface muito boa. O problema dele, é que a versão gratuita é limitada a 45 lançamentos mensais, acima disso, há cobrança de mensalidade. Os contatos que eu fiz com o fornecedor foram respondidos com presteza. Parece que o fornecedor é uma empresa de pequeno porte do interior.

Debit: http://www.debit.com.br

O único requisito que ele não atende é a importação de arquivos com lançamentos bancários, contudo, ele permite a exportação dos dados para planilhas. O maior problema desse aplicativo, é que ele apresenta alguns pequenos defeitos. Eu mandei um email relatando os problemas que identifiquei e eles responderam prontamente que iriam avaliar os erros, porém, os erros ainda persistem. A usabilidade do aplicativo é um pouco confusa.

O Debit é totalmente gratuito. A empresa possui outros aplicativos pagos que são voltados para empresas.

Minhas Finanças: http://www.bb.com.br

É um aplicativo exclusivo para quem é correntista do Banco do Brasil. Ele é muito bom, mas, os lançamentos futuros não podem ter repetição e as consultas não te deixam ter visão dos saldos futuros das contas. Não permite o cadastramento de favorecido. Tem ainda a desvantagem de te obrigar a permanecer no Banco do Brasil para continuar a utilizá-lo.

Clear Checkbook: http://www.clearcheckbook.com

É uma aplicação em inglês e os relatórios são limitados a 10 meses na versão gratuita, ou seja, você não consegue ter a visão de um ano completo. Só não atende os requisitos de cadastramento do favorecido e de informar o saldo previsto das contas.

Moneytrackin: http://www.moneytrackin.com

Não atende a um requisito importante: a separação do previsto e do realizado. Além disso, não cadastra favorecido e nem informa o saldo previsto das contas.

Spesa: http://spesa.com.br

Só permite o cadastramento de uma conta. O aplicativo é gratuito, mas, passa a impressão de ser amador. A parte de relatórios também é fraca.

Organizze: http://www.organizze.com.br

Muito bom, mas, no plano gratuito só permite o cadastramento de uma conta.

Sr. Dinheiro: http://www.srdinheiro.com.br

Não atende a vários requisitos. Além disso, possui diversas limitações de quantidade de lançamentos na versão gratuita.

gBolso: http://www.gbolso.com.br

Muito citado nos fóruns e avaliações, porém, não atende vários dos requisitos. Possui recursos de controle de contas a pagar, investimentos e lançamentos em lote, porém, só no plano pago.

IExpenseOnline: http://www.iexpenseonline.com

Aplicativo em inglês. Não atende a diversos requisitos. Me pareceu lento.

Meus Gastos: http://www.meusgastos.com.br

Aplicativo totalmente gratuito, porém, muito simples.

Manubia: http://www.manubia.com.br

A versão gratuita é muito limitada, permite a criação de apenas 2 contas.

AltMoney: http://www.altmoney.com.br

Pareceu-me bom, mas, como só tem versão paga, eu nem cheguei a avaliar mais profundamente.

Super Contas: http://www.supercontas.com.br

É um aplicativo muito interessante, voltado para divisão de contas entre um grupo de pessoas, mas, está completamente fora do que eu estou procurando. Totalmente gratuito.

Meu Gerenciamento: http://www.meugerenciamento.com.br

Voltado para empresas. Não existe versão gratuita.

Mônaco Online: http://www.monacoonline.com.br

Não apresenta nenhuma informação sobre a empresa fornecedora ou sobre o produto no site. Ocorre um erro quando se tenta criar um novo usuário, por isso, não foi possível avaliar.

Buxfer: http://www.buxfer.com

Em inglês. No plano básico gratuito podem ser criadas no máximo 5 contas. Há reclamações em fóruns que o serviço está "morto", ou seja, estagnado sem evoluções ou suporte. O saldo das contas e os valores dos lançamentos nas mesmas não conferem.

Mint: http://www.mint.com

Aplicativo em inglês, é o mais popular nos Estados Unidos, porém, para utiliza-lo você tem que vincula-lo à sua conta bancária, passando seus dados de acesso à mesma (login e senha) para que o aplicativo possa recuperar as informações do extrato. Mesmo que você tenha coragem de informar seus dados de login bancário a um aplicativo na internet, o Mint só funciona com bancos americanos.

Finance Desktop: http://www.financedesktop.com.br

Precisa fazer download para ser executado, por isso eu não o avaliei. Pode ser executado a partir de um pendrive.

Grana Forte: http://granaforte.com.br

Precisa de download para ser executado e só tem versão paga, assim sendo, eu não o avaliei.

Depois de todas as avaliações, eu fiquei entre três alternativas:


O “Minhas Economias” acabou sendo a minha escolha final. Eles responderam prontamente os emails que eu mandei. O aplicativo não tem cadastro de favorecido, mas, isso é contornável com o campo "descrição" no lançamento. No mais, ele é excelente: usabilidade muito boa, importação de dados muito bem resolvida e totalmente gratuito. A única dúvida, é sobre a continuidade do serviço a longo prazo.

Com os bugs que o Debit apresenta, é difícil optar por ele. O ponto positivo, é que a empresa por trás do software parece que tem certa solidez.

Eu só não optei pelo “Contas Online” devido ao custo do serviço, já que eu não quero assumir mais um custo fixo.

segunda-feira, 22 de novembro de 2010

Ferramenta gratuita para groupware: Dimdim

Para quem precisa trabalhar em grupo, mas, está fisicamente separado dos seus pares, existe uma excelente ferramenta para ajudar a integrar os parceiros de trabalho. E o melhor, ela é inteiramente grátis: Dimdim.

Você pode compartilhar documentos, a sua tela, conversar com vídeo ou voz e usar muitos outros recursos.

Veja mais em: http://www.dimdim.com/

sexta-feira, 15 de outubro de 2010

Diferença entre iterativo e interativo

Duas palavras muito comuns na área de TI, mas que constantemente são confundidas em seu significado e aplicação: iterativo e interativo.

Iterativo se refere a ciclo, repetição.

Uma Iteração é um ciclo ou uma etapa de uma rotina maior.

Interativo, se refere a relacionamento, comunicação.

Uma interação é uma ação mútua, uma entidade agindo sobre a outra ou vice-versa.

Por exemplo, no desenvolvimento de software o correto é se falar em desenvolvimento iterativo e incremental.

Desenvolvimento incremental é uma estratégia de planejamento estagiado, em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas.

Desenvolvimento iterativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. A saída de uma iteração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas.

Muitas vezes as pessoas se enganam e falam em desenvolvimento "interativo" e incremental, o que não está correto.

quarta-feira, 29 de setembro de 2010

Como funcionam os projetos de software

Os projetos de software nem sempre atingem os seus objetivos. Para mostrar como estes projetos funcionam, existe um exemplo bem humorado que é usado há muito tempo:

01 - Como o cliente descreveu a sua necessidade:
02 - Como o analista de requisitos entendeu:
03 - O que o gerente de conta vendeu para o cliente:
04 - Como o analista especificou:
05 - O que o programador construiu:
06 - O que a equipe de testes recebeu:
07 - Como o projeto foi documentado:
08 - Qual é o plano de recuperação de desastre:
09 - Como o marketing anunciou:
10 - O que a operação instalou:
11 - Como é suportado:
12 - Quando foi entregue:
13 - Quanto foi cobrado do cliente:
14 - O que o cliente realmente queria:

Veja mais exemplos em: http://www.projectcartoon.com

terça-feira, 14 de setembro de 2010

Como programadores matam dragões e salvam princesas

Vejam um texto divertido sobre programadores e suas características, que circula pela web (eu não sei qual é a origem dele):


Java - Chega, encontra o dragão, desenvolve um framework para aniquilamento de dragões em múltiplas camadas, escreve vários artigos sobre o framework, mas não mata o dragão.

.NET - Chega, olha a ideia do Javanês e a copia. Tenta matar o dragão, mas é comido pelo réptil.

C - Chega, olha para o dragão com olhar de desprezo, puxa seu canivete, degola o dragão, encontra a princesa, mas a ignora para ver os últimos checkins no cvs do kernel do Linux.

C++ - Cria um canivete básico e vai juntando funcionalidades até ter uma espada complexa que apenas ele consegue entender. Mata o dragão, mas trava no meio da ponte por causa dos memory leaks.

COBOL - Chega, olha o dragão, pensa que ta velho demais para conseguir matar um bicho daquele tamanho e pegar a princesa e, então, vai embora.

Pascal - Se prepara durante 10 anos para criar um sistema de aniquilamento de dragão... Chegando lá, descobre que o programa só aceita lagartixas como entrada.

VB - Monta uma arma de destruição de dragões a partir de vários componentes, parte pro pau pra cima do dragão e, na hora H, descobre que a espada só funciona durante noites chuvosas...

PL/SQL - Coleta dados de outros matadores de dragão, cria tabelas com N relacionamentos, complexidade ternária, dados em 3 dimensões, OLAP e demora 15 anos para processar a informação. Enquanto isso a princesa virou lésbica.

Ruby - Chega com uma baita fama, falando que é o melhor faz tudo, quando vai enfrentar o dragão mostra um videozinho dele matando um dragão... O dragão come ele de tédio.

Smalltalk - Chega, analisa o dragão e a princesa, vira as costas e vai embora, pois eles são muito inferiores.

shell - Cria uma arma poderosa para matar os dragões, mas, na hora H, não se lembra como usá-la.

shell(2) - O cara chega ao dragão com um script de 2 linhas que mata, corta, estripa, empala, pica em pedacinhos e empalha o bicho, mas na hora que ele roda o script, aumenta, engorda, enfurece e coloca álcool no fogo do dragão.

Assembly - Acha que ta fazendo o mais certo e enxuto, porém troca um A por D, mata a princesa e transa com o dragão.

Fortran - Chega, desenvolve uma solução com 45000 linhas de código, mata o dragão, vai ao encontro da princesa... Mas esta o chama de tiozinho e sai correndo atrás do programador Java que era elegante e ficou rico.

Fox Pro - Desenvolve um sistema para matar o dragão, por fora é bonitinho e funciona, mas por dentro está tudo remendado, quando ele vai executar o aniquilador de dragões lembra que se esqueceu de indexar os DBFs.

Analista de Processos - Chega ao dragão com duas toneladas de documentação desenvolvida sobre o processo de se matar um dragão genérico, desenvolve um fluxograma super complexo para libertar a princesa e se casar com ela, convence o dragão que aquilo vai ser bom pra ele e que não será doloroso. Ao executar o processo ele estima o esforço e o tamanho do estrago que isso vai causar, pede a assinatura do papa, do Buda e do Raul Seixas para o plano e, então, compra 2 bombas nucleares, 45 canhões, 1 porta aviões, contrata 300 homens armados até os dentes, quando na verdade necessitaria apenas da espada que estava na sua mão o tempo todo.

Clipper - Monta uma rotina que carrega um array de codeblocks para insultar o dragão, cantar a princesa, carregar a espada para memória, moer o dragão, limpar a sujeira, lascar leite condensado com morangos na princesa gostosa, transar com a princesa, tomar banho, ligar o carro, colocar gasolina e voltar pra casa. Na hora de rodar recebe um "Bound Error: Array Access" e o dragão o come com farinha.

Perl - Chega, olha o dragão de cima a baixo, monta um programinha mixuruca com três linhas, mas com uma puta expressão regular (que ninguém entende, nem o cara que fez) que simplesmente oblitera o dragão e as roupas da princesa, deixando-a no jeito pro programador terminar o serviço. Mas aí, ele vai fazer outra coisa e a princesa fica a ver navios...

HTML - Monta um monte de telinha bonitinha, cheia de gifs animadas, música, botõezinhos, applets que mostram uma foto sobre um lago espelhado, applets que colocam cobrinhas atrás do cursor do mouse e flashes lindíssimos que em teoria iriam deixar tanto o dragão quanto a princesa maravilhados e assim poderia escolher quem ele vai matar e quem vai resgatar. Na hora de rodar, a página demora tanto a entrar e o Internet Explorer trava tantas vezes que mata o dragão e a princesa de tédio e velhice. Nesse meio tempo, a princesa já tinha descoberto que o programador HTML (eles gostam de se chamar de "Uebidizzzaiguinersss") era gay e que estava de olho mesmo era no dragão. Nooofffaaa!!!

sexta-feira, 3 de setembro de 2010

Classificação dos testes de software

Na fase de construção dos softwares, os testes podem ter classificações diferentes, dependendo do enfoque que se pretende dar. Eles podem ser classificados quanto ao Nível, o Tipo e a Técnica. Veja abaixo mais detalhes de cada classificação:

Classificação quanto ao Nível do teste

  • Teste Unitário

Testa apenas o componente (ou a menor unidade de software) que o desenvolvedor construiu. Exemplo de ferramenta para auxiliar nos testes: JUnit.

  • Teste de Integração

Testa as integrações entre os diversos componentes construídos.

Normalmente, o Teste Unitário e o Teste de Integração são realizados pela própria equipe de desenvolvimento.

  • Teste de Sistema

Verifica a boa execução dos componentes do aplicativo inteiro, incluindo as interfaces com outras aplicações.

Geralmente é realizado pela equipe de testes funcionais.

  • Teste de Aceitação

Verifica se o sistema atende aos requisitos do usuário, conforme especificado. Exemplo de ferramenta para automação: Selenium.

Normalmente é realizado pela equipe de projeto do sistema. A partir deste teste é gerada a "Versão 1.0" do sistema.

Classificação quanto ao Tipo do teste

  • Teste Funcional

São testes que verificam a operação correta do sistema em relação a sua especificação.

Geralmente é realizado pela equipe de testes.

  • Teste Não Funcional

É realizado por uma equipe de testes mais especializada, porém, com foco em aspectos não funcionais como: desempenho, carga, estresse, usabilidade, segurança, etc. É feito em cima da versão 1.0 do sistema.

O teste de desempenho busca extrair informações sobre o desempenho do sistema em cenários normais de uso; o teste de carga busca extrair informações sobre o volume de usuários, transações, etc. que o sistema suporta; o teste de estresse busca extrair informações sobre quando o sistema não suporta a carga aplicada, sendo muito importante para saber estruturar e dimensionar a arquitetura do sistema e prover informações para escalar o sistema; o de usabilidade procura verificar se a interface de usuário é fácil de aprender e utilizar; o teste de segurança visa verificar se o software é seguro em garantir o sigilo dos dados armazenados e processados.

Exemplo de ferramenta para testes não funcionais: JMeter.

Classificação quanto à Técnica de teste

  • Testes Caixa Preta

Estes testes buscam verificar se as saídas do sistema estão coerentes com as entradas, sem se preocupar como elas são tratadas internamente. As principais técnicas são:

Partição de equivalência;
Análise de Valores Limites;
Derivados de especificação;
Baseado em estado-transição.

  • Testes Caixa Branca

Estes testes, chamados também de Testes Estruturais, se preocupam em avaliar aspectos internos do sistema. Para isso, utilizam técnicas de inspeção de código tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

Existem várias ferramentas para ajudar a aplicar estas técnicas de testes: FindBugs, PMD, Lapse, etc.

quarta-feira, 18 de agosto de 2010

Os tipos de empresas que prestam serviços de TIC

A oferta de serviços de TIC (Tecnologia da Informação e Comunicação) é muito diversificada e existem empresas oferecendo serviços com características bastante peculiares. Contudo, podemos tentar organizar um pouco as ofertas do mercado, agrupando as empresas de TIC nos principais tipos existentes e definindo as principais características de cada uma deles.

Software House

As software houses são empresas que desenvolvem software para comercialização. O software pode ser desenvolvido sob encomenda ou em forma de pacotes que são vendidos para vários clientes.

O produto oferecido por este tipo de empresa pode ser o serviço de desenvolvimento do software ou o licenciamento do software em si.

ASP - Application Service Provider

As ASP's são empresas que prestam serviços baseado em software, ou seja, elas vendem um serviço a partir de um ou mais softwares de propriedade da ASP, consequentemente, elas não vendem o software como produto por si só.

A partir da forma de atuação destas empresas é que surgiu o conceito de Software como um Serviço: SaaS (Software as a Service).

A vantagem para as empresas que prestam este serviço, é que elas fornecem um serviço continuado que lhes garante faturamento em longo prazo, ao invés de faturar apenas no momento da venda do software. Para os clientes, as vantagens são a redução do investimento inicial e a diminuição das despesas com infra-estrutura e gerenciamento do serviço associado ao software.

A principal diferença das ASP's em relação as software houses, é que o serviço prestado pela software house é o desenvolvimento do software em si e não a administração do serviço associado a este software.

BPO - Business Process Outsourcing

As empresas de BPO, ou terceirização de processos de negócio, vendem, além do software como um serviço, toda a estrutura necessária para que o processo de negócio do cliente, baseado naquele software, seja executado.

Este tipo de empresa fornece software, infra-estrutura, mão de obra e o que mais for necessário. Com isso, desobriga o cliente de se preocupar com assuntos que não estejam relacionados à atividade fim do seu negócio.

Terceirização de mão de obra

Este tipo de empresa simplesmente aluga mão de obra. Ou seja, ela identifica a necessidade do cliente e fornece um funcionário com as qualificações requeridas, que irá trabalhar nas instalações do cliente.

Originalmente, este tipo de contrato deveria ser usado apenas para contratações temporárias. Porém, posteriormente, ele passou a ser usado também para contratar funcionários que teriam menos direitos trabalhistas que os exigidos pelo sindicato de trabalhadores do segmento da empresa contratante. Em função disso, a justiça do trabalho passou a dar equivalência de direitos a vários destes trabalhadores terceirizados e, assim, este tipo de contratação tem caído em desuso.

Data Center

As empresas que prestam serviço de data center, fornecem basicamente a infra-estrutura para quem está interessado em hospedar sistemas que serão utilizados em produção.

Como o custo de montar e manter um data center é muito alto, as empresas especializadas neste serviço permitem que este custo seja diluído entre diversos clientes.

Os tipos de serviço de data Center oferecidos no mercado mais comumente são:

Hosting

Neste caso, a empresa de data center fornece, além da estrutura e da administração, também o servidor onde o sistema ficará hospedado. O hosting pode ser dedicado, onde o sistema fica em um servidor exclusivo para ele, ou pode ser compartilhado, onde o cliente compra espaço em um servidor que hospeda outros sistemas simultaneamente.

Colocation

Em português, "compartilhamento de localização", neste caso, o servidor pertence ao cliente e ele aluga apenas a infra-estrutura oferecida pelo data center. A administração do servidor pode ser feita pela empresa de data center ou pelo próprio cliente, dependendo da modalidade de serviço contratado.

segunda-feira, 26 de julho de 2010

Diferenças entre engenharia de software e engenharias tradicionais

Quem trabalha com desenvolvimento de software está quase sempre envolvido com atrasos na entrega e com problemas de qualidade no produto construído. Quando estes problemas se tornam muito frequentes, inevitavelmente as pessoas começam a comparar a Engenharia de Software com as engenharias tradicionais, pois, é perceptível que nas demais engenharias os problemas de atraso e qualidade são muito menos recorrentes.

Por que ao construir um prédio é possível cumprir o planejamento com muito mais precisão e ter muito menos inconformidades no final do que quando estamos construindo um sistema de informação?

A minha intenção neste post é fazer uma comparação entre os principais aspectos das engenharias tradicionais e de software, para nos ajudar cada vez mais nos aproximarmos das boas práticas de engenharia e a explicar a nossos clientes porque não conseguimos cumprir prazos com a mesma constância que o pessoal das outras engenharias.

Os principais aspectos que diferenciam a engenharia de software das demais são:

Maturidade da área

Existem poucos padrões a serem seguidos quando se executa projetos de software. Na maioria das outras áreas de engenharia já existe uma cultura secular ou até mesmo milenar (lembrando que os egípcios já construíam pirâmides complexas há mais de 5.000 anos), fazendo com que muitos métodos e técnicas sejam extremamente testados e de amplo domínio. Na engenharia de software quase tudo ainda é muito mais experiência de alguns do que conhecimento de todos.

Produto intangível

Os gerentes de projetos de outras áreas, normalmente, trabalham com objetos materiais visíveis e tangíveis. Estes objetos podem ser sentidos, observados, tocados, etc., e mediante o uso das informações obtidas através do uso dos sentidos podem ser melhorados, corrigidos ou modificados. Enquanto isso, a natureza abstrata e intangível do projeto de software limita muito a ação do gerente. É muito mais fácil os envolvidos perceberem e avaliarem o desenvolvimento do projeto de um navio, de uma casa ou de uma máquina do que ver o progresso de um projeto de software cuja visibilidade é meramente conceitual, através de um conjunto de documentos.

A mesma dificuldade de perceber o andamento do trabalho se repete ao tratarmos sobre alterações no produto finalizado. É muito mais fácil para um engenheiro explicar a um cliente o esforço necessário para mudar a janela de uma casa de lugar depois dela pronta, do que um engenheiro de software demonstrar para o seu usuário o esforço para mudar um botão de posição na tela de um sistema. “Mas basta apenas mudar o botão de lugar, não pode demorar esse tempo todo...” é a resposta padrão que os profissionais de software ouvem.

Facilidade para modelagem / prototipação

Quando se trata de projetar objetos tangíveis, é muito mais fácil criar um modelo ou protótipo que represente bem para os interessados aquilo que se pretende construir. Pode-se lançar mão de diversos artifícios: plantas, desenhos, maquetes, modelos computacionais em 3D, etc. Permitindo até mesmo que criemos modelos que simulam o funcionamento do produto depois de pronto. Já para um software, que é intangível, a questão da prototipação é mais complexa, normalmente o que fazemos são os layouts das telas e a simulação da navegação, contudo, isso não basta. Por trás das telas pode haver regras de negócios extremamente complexas que não são representadas no protótipo e, consequentemente, não podem ser validadas pelos interessados.

Falta de padronização nos projetos

Grande parte dos projetos de software são projetos únicos, pois, visam informatizar processos que também são únicos. Existe a experiência anterior com outros projetos, mas ela não se aplica integralmente no novo projeto. Isso torna difícil antecipar problemas, pois, a maioria deles serão problemas novos.

Rápida evolução tecnológica

Como há uma rápida evolução tecnológica na área de TI, nem mesmo a tecnologia usada, os métodos e ferramentas já conhecidas e experimentadas em projetos anteriores servirão de parâmetros para o novo projeto. Muitas ferramentas ou técnicas amplamente utilizadas há pouco mais de uma década, hoje são completamente obsoletas.

Na maioria das áreas a opção mais comumente adotada para acompanhar a evolução tecnológica ou o aperfeiçoamento de métodos e técnicas é projetar novos produtos que englobam os avanços tecnológicos. Em projetos de software, não raro, tenta-se adaptar os produtos existentes às novas tecnologias.

Conhecimento da área de atuação

Os projetistas das demais áreas de engenharia, em geral, gerenciam projetos muito específicos de sua área de conhecimento enquanto os projetistas de software são solicitados a desenvolver os seus projetos nas mais variadas áreas do conhecimento humano, áreas estas que eles não dominam. Isto torna as incertezas de seu sucesso ainda maiores, pois, eles dependem essencialmente do conhecimento de pessoas que por sua vez não dominam as técnicas de desenvolvimento de software.

Identificação das falhas

Enquanto os gerentes de projetos de outras áreas podem orgulhar-se de colocar no mercado produtos sem defeitos, os gerentes de produtos de software, geralmente devem contentar-se em oferecer produtos que sejam confiáveis, não necessariamente sem defeitos. Confiáveis são produtos que podem apresentar defeitos, mas estes não devem ocorrer em situações normais de uso, não podem ser frequentes e nem aparecer nos momentos mais críticos de uso do produto.

Outra consideração significativa diz respeito às indicações de possíveis falhas. Nas demais áreas, as falhas são geralmente antecedidas por ocorrências facilmente percebidas, tais como rachaduras em prédios, barulhos estranhos em máquinas, cheiros incomuns em aparelhos elétricos ou produtos químicos, fumaça em motores, por exemplo. Em produtos de software as possíveis falhas muitas vezes só são percebidas na hora do uso.

Várias formas de se implementar o mesmo produto

Na maioria das áreas o número e a variedade de implementações satisfatórias é, em geral pequeno, isto quando não se reduz a uma só. Em engenharia de software pode haver uma enorme variedade de implementações satisfatórias. Desta forma as especificações de um projeto de produto de software devem incluir diretrizes para se escolher adequadamente uma alternativa correta.

Dependência de outros fatores

Outra dificuldade em projetos de software é que a qualidade dos produtos de outras áreas depende, em geral, somente da qualidade construída no produto. Já na área de produtos de software a qualidade do resultado produzido pelo software depende da qualidade da máquina na qual ele vai ser executado, da qualidade dos outros produtos de software com os quais ele interage (sistema operacional, compilador, servidor de aplicação, gerenciador de Banco de Dados, etc.).

Instabilidade dos requisitos

Normalmente, quem pretende construir um prédio ou uma máquina tem previamente uma ideia formada do que quer ou, pelo menos, não começa a execução sem ter essa ideia, porém, na engenharia de software não é raro nos deparamos com um cliente que quer um sistema para resolver um problema que ele não sabe exatamente qual é e nós iniciarmos o projeto antes de conhecer o problema a fundo. Como nestes casos começamos a trabalhar sem saber exatamente onde queremos chegar, é normal que ao longo do tempo os requisitos mudem e parte do trabalho tenha que ser refeita, consequentemente, não conseguimos cumprir o planejamento original.

quinta-feira, 24 de junho de 2010

Resenha de livro: A Arte de Enganar - Kevin Mitnick

A Arte De Enganar
Ataques de Hackers: Controlando o Fator Humano na Segurança da Informação
Autor: Kevin Mitnick, William L. Simon
Editora: Pearson Brasil
ISBN: 8534615160

Este livro foi escrito pelo ex-cracker e atual consultor de segurança Kevin Mitnick. No livro ele mostra ataques bem-sucedidos e como eles poderiam ter sido evitados. Além disso, fornece orientações para o desenvolvimento de protocolos, programas de treinamento e manuais para garantir que o investimento em segurança de uma empresa não seja em vão. Ele dá conselhos sobre como evitar vulnerabilidades de segurança e espera que as pessoas estejam preparadas para um ataque vindo do risco mais sério de todos: a natureza humana.

No início do livro, Mitnick afirma que o elo mais fraco em qualquer esquema de segurança, é o fator humano. Não adianta você ou sua empresa ter os melhores e mais modernos equipamentos ou ferramentas de defesa, se um funcionário descuidado ou mal treinado ceder informações indevidas a alguém inescrupuloso. Através de técnicas de engenharia social, os inescrupulosos enganam as pessoas e criam situações fictícias que envolvem as vítimas. Para isso, eles se aproveitam do fato de que a maioria das pessoas confia na boa índole dos outros.

Depois ele mostra alguns exemplos práticos da atuação de engenheiros sociais, como casos em que por telefone eles se passam por funcionários das empresas ou de fornecedores para obter informações aparentemente irrelevantes, tais como, números de telefones internos da empresa, códigos de centros de custo, etc. e a partir delas montam um quebra-cabeça que lhes permitem obter as informações que realmente são importantes para os seus objetivos, como, por exemplo, um código que permite ao mal intencionado consultar a situação bancária de qualquer pessoa junto a um serviço de proteção ao crédito.

Em cada exemplo apresentado, o engenheiro social usa uma técnica diferente de abordagem e tem objetivos diferentes, mas, em comum eles se utilizam da vontade do interlocutor em ajudar uma pessoa que está em dificuldades, ou tentam passar a impressão que estão ajudando a vitima a resolver um problema que ela não tem, ou ainda tentam passar a impressão que tem autoridade para obter aquele tipo de informação, mesmo sem que o interlocutor tenha certeza que a pessoa com quem está interagindo é realmente quem alega ser. O principal recado de Mitnick neste caso é: só dê informações a pessoas das quais que você possa confirmar a identidade.

Muitas vezes, o engenheiro social se aproxima da vitima, faz perguntas sem maiores objetivos ou mantém conversas despretensiosas, apenas com o intuito de ganhar a confiança da outra parte. Somente depois que já se estabeleceu a relação de confiança é que o engenheiro parte para obter as informações que realmente lhe interessam.

Mitnick mostra também que o ataque pode ser feito através do computador, com emails que direcionam a pessoa para sites ou programas maliciosos, ou ainda, através de sites legítimos que são clonados para enganar o usuário. Outra fonte de informação muito utilizada pelos engenheiros sociais é o lixo das empresas, onde podem estar disponíveis informações muito valiosas sobre a organização.

O livro ressalta a importância da empresa ter uma política muito clara sobre quais tipos de informações podem ser divulgadas, para quem elas podem ser divulgadas, quem pode fazer essa divulgação e através de quais meios. Informações aparentemente inofensivas, como ramal e email dos funcionários podem ser muito úteis para que o engenheiro social monte o seu quebra-cabeça. Outro tipo de informação muito cobiçada são os manuais de operação internos da companhia, neles o engenheiro pode aprender como a empresa funciona e qual é o jargão utilizado por seus funcionários e, dessa forma, se passar por uma pessoa de dentro da organização sem levantar suspeitas. E este tipo de manual, muitas vezes está disponível na internet ou no lixo sem maiores proteções.

Os objetivos de uma pessoa que buscam informações confidenciais podem ser os mais diversos, indo desde o simples prazer de burlar o esquema de segurança, até obter vantagens financeiras ou realizar espionagem empresarial. Existem casos documentados de empresas que sofreram prejuízos de milhões de dólares com golpes deste tipo.

Muitas vezes o atacante está dentro da própria empresa, podem ser funcionários insatisfeitos, empregados recém-demitidos, o pessoal de TI que tem acesso privilegiado às bases de dados, ou simples curiosos querendo bisbilhotar o salário dos colegas. Isso mostra que os procedimentos de segurança precisam ser redobrados e muito bem pensados.

O livro mostra que a natureza humana tem seis tendências básicas de colaborar com outras pessoas: por autoridade, afabilidade, reciprocidade, consistência, validação social e escassez. O engenheiro social irá tentar explorar uma ou mais dessas tendências para tentar fazer com que seu interlocutor colabore.

O autor ressalta a importância de treinar constantemente e formalmente todos os funcionários sobre a política de segurança da empresa. O treinamento pode ter conteúdo diferente para cada perfil de funcionário. Além disso, a política de segurança deve ser divulgada constantemente através dos canais de comunicação disponíveis.

É claro que os aspectos físicos e tecnológicos da segurança não podem ser negligenciados, mas, o principal recado do livro é que não adianta investir apenas nesses itens e deixar as pessoas em segundo plano, pois, elas podem ser o elo mais fraco nessa corrente se não forem bem orientadas.

Apesar do livro se concentrar nos ataques da engenharia social sobre as empresas, nós podemos ver vários exemplos de ataque de engenharia social na nossa vida pessoal. O golpe do falso sequestro aplicado pelo celular para extorquir dinheiro de pessoas desavisadas é um exemplo típico. Outro exemplo, é o golpe onde pessoas desconhecidas, pelo telefone, pedem que as vítimas comprem créditos de celular pré-pago e lhes repassem o código de ativação em troca de supostos prêmios .

Em resumo, para quem trabalha com TI, este livro é uma leitura obrigatória.

quarta-feira, 26 de maio de 2010

Proteja sua privacidade na web

Com o uso intensivo da internet e com o advento da computação em nuvem, cada vez mais nós estamos expondo nossas informações pessoais na web. Seja no momento em que navegamos, ou seja quando as deixamos armazenadas em servidores que estão na "nuvem" e não sabemos exatamente como é tratada a sua segurança.

A exposição dessas informações pode ser mais ou menos crítica dependo da sua natureza, por exemplo, dados bancários são extremamente sensíveis para ficarem expostos.

Para quem quiser saber como proteger melhor suas informações pessoais, veja o artigo abaixo, que é um guia voltado principalmente para os serviços do Google, mas, traz conceitos que podem ser aplicados a qualquer serviço online:

IDG Now - O Guia do Paranóico para os Servicos Google

"Navegar é preciso, mas, navegar com segurança é essencial."

segunda-feira, 17 de maio de 2010

POG: a última onda no desenvolvimento de software

A área de tecnologia, de tempos em tempos, é varrida por uma “onda”. Há sempre a “onda do momento”, que destrói tudo que se sabia anteriormente e nos força a enxergar as coisas sob um novo ponto de vista.

Você já ouviu falar de Programação Orientada a Objetos (POO)? A Eventos? Programação Estruturada?

Tudo isso agora é passado!

A nova onda no desenvolvimento de software é POG.

POG pode ser usada em qualquer plataforma, por qualquer profissional, em qualquer tipo de empresa.

É um novo paradigma, independente de tecnologia.

Saiba mais sobre POG - Programação Orientada a Gambiarra:

http://desciclo.pedia.ws/wiki/POG

E para explorar ao máximo o potencial da programação POG, não deixe de usar os "Gambi Design Patterns":

http://desciclo.pedia.ws/wiki/Gambi_Design_Patterns

Nunca antes na história da programação, houve um método de construção tão eficaz.

terça-feira, 4 de maio de 2010

Tipos de correspondências oficiais e empresariais

De maneira geral, existem três macro tipos de correspondências:

  • Particular – se dá entre indivíduos (amigos, familiares e pessoas do convívio social) e pode apresentar diversos graus de formalidade, desde um caráter íntimo até certo grau de formalismo;
  • Empresarial – é trocada entre empresas ou entre estas e pessoas físicas;
  • Oficial – acontece entre órgãos do serviço público ou entre os mesmos e a sociedade.

Com o objetivo de tornar este tipo de comunicação mais organizado e de fácil entendimento para todos os envolvidos, as correspondências oficiais e empresariais seguem determinados padrões de redação e formatação.

Para ajudar quem precisar lançar mão dessa ferramenta, faremos um apanhado geral dos tipos de correspondências oficiais e empresariais existentes e suas principais características.

Ata

A ata é um documento no qual deve constar um resumo por escrito, detalhando os fatos e as soluções a que chegaram as pessoas convocadas a participar de uma assembleia, sessão ou reunião. A expressão correta para a redação de uma ata é "lavrar a ata". Uma das principais funções da ata é historiar, traçar um painel cronológico da vida de uma empresa, associação ou instituição. Serve como documento para consulta posterior, tendo em alguns casos caráter obrigatório pela legislação.

Por tratar-se de um documento formal, a ata deve seguir algumas normas específicas de formatação:

  • Devido a ter como requisito não permitir que haja qualquer modificação posterior, o seu formato renuncia a quebras de linha eletivas, espaçamentos verticais e paragrafação, ocupando virtualmente todo o espaço disponível na página;
  • Números, valores, datas e outras expressões são sempre representados por extenso; 
  • Sem emprego de abreviaturas ou siglas; 
  • Sem emendas, rasuras ou uso de corretivo (quando a ata estiver sendo manuscrita e for necessária alguma correção, usar a expressão "digo" seguida do texto correto); 
  • Todos os verbos descritivos de ações da reunião usados no pretérito perfeito do indicativo (disse, declarou, decidiu…).

A estrutura básica para uma ata pode ser esta:

  • Título da reunião;
  • Cidade, dia, mês, ano, das h:min até h:min;
  • Local da reunião;
  • Introdução (Relatar sobre o título da reunião, local, data, hora e participantes);
  • Participantes da reunião (Nome completo do participante e especificar de qual instituição ele é);
  • Agenda (Relatar sobre a pauta da reunião, os temas a serem tratados e os respectivos responsáveis de cada tema);
  • Desenvolvimento (Descrever sobre os temas principais citados na reunião);
  • Conclusões (Descrever sobre as conclusões atingidas ao final da reunião e suas respectivas decisões);
  • Recomendações (Descrever recomendações e observações feitas no decorrer da reunião);
  • Distribuição (Relatar o nome de quem a ata será enviada).

A ata deverá ser assinada por todos os participantes.

Atestado ou Certificado

É um documento em que se faz fé de algo e que tem valor legal. Pode haver atestados ou certificados de serviços prestados, de estudos realizados, de pagamentos, etc.

Para a sua elaboração, utiliza-se geralmente papel de tamanho A4, escrito em sentido vertical, como se mostra em seguida:

  • Cabeçalho (Coloca-se na parte superior do certificado, com uma margem considerável. É constituído pelo nome da pessoa ou instituição que o envia, acompanhados dos seus dados de identificação. Costuma-se escrever em maiúsculas.);
  • Corpo (Contém texto precedido pelo termo CERTIFICA ou ATESTA, em maiúsculas, seguido de dois pontos, onde se descreve o objeto da certificação.);
  • Local e data;
  • Assinatura e selo.

Bilhete

É um meio rápido e simples de transmitir uma mensagem. Normalmente é dirigido a uma pessoa próxima, com quem se tem intimidade, e por isso mesmo costuma ser escrito em linguagem informal. Isso, contudo, não dispensa a atenção que deve ser dada à qualidade da redação, especialmente considerando que o relacionamento contínua tendo caráter profissional.

O bilhete não requer um tipo específico de papel, muito menos segue um padrão formal. É sempre aconselhável, entretanto, uma boa apresentação.

Mesmo sendo breve e informal, o bilhete apresenta uma forma de organização que deve ser seguida para atender ao seu maior objetivo: comunicar de forma rápida e precisa. Assim, deve conter as seguintes partes:

  • Vocativo (Coloca-se o nome do receptor, sem emprego de tratamento especial);
  • Texto (Deve ser iniciado com marca de parágrafo e conter as informações necessárias à comunicação de forma bem ordenada);
  • Nome do emissor;
  • Data e hora.

Carta comercial

As cartas comerciais, além de diversos destinos, também têm função variada, como a de informar, solicitar ou persuadir. Podem ser cartas de solicitação de emprego, oferta de algum produto de sua empresa, reclamação quanto à má prestação de algum serviço, cobrança de algum débito, enfim, diversas situações que fazem parte do cotidiano empresarial.

Como em qualquer correspondência oficial, o conteúdo da carta deve ser adequadamente normalizado por parágrafos e redigido com clareza e concisão.

A sua estrutura geral é:

  • Cabeçalho ou timbre (Referência da empresa; logotipo, símbolo ou emblema. Em geral, já vêm impressos no papel da carta);
  • Número de controle (Facilita ao destinatário responder sua carta e mencionar a referência. É também uma maneira de garantir o controle da correspondência. A colocação à direita é um destaque que facilita a leitura.);
  • Local e Data (Por extenso. Quando o papel é timbrado, pode-se suprimir o local antes da data, uma vez que o endereçamento completo aparece no pé de página.);
  • Destinatário (Não se deve colocar À/Às ou Ilmos. Senhores antes do nome da empresa ou pessoa a quem a carta se destina. Não é necessário escrever endereço, caixa postal e CEP no papel carta, basta que esses dados apareçam no envelope.);
  • Referência (É o conteúdo da carta sintetizado, facilitando o registro para quem recebe. Não há necessidade de escrever Ref. ou REFERÊNCIA, pois a posição da frase na carta já indica esse elemento.);
  • Invocação ou vocativo (O emprego de palavras como prezado, estimado, caro, amigo deve ser de acordo com o tipo de carta. Pode se tratar de uma carta puramente comercial ou pode envolver também relações de amizade.);
  • Corpo da carta ou conteúdo (Deve estar disposto, geralmente, no centro do papel, em cerca de três parágrafos: a informação inicial, o desenvolvimento do tema e a conclusão. O assunto deve ser tratado em linguagem clara, objetiva e concisa. Deve-se evitar perda de tempo na introdução do assunto, como palavras e expressões desnecessárias.);
  • Saudação final, despedida ou fecho (Modernamente, evitam-se palavras rebuscadas e chavões. Expressões longas, que nada acrescentam de importante, caíram em desuso. Emprega-se Atenciosamente ou Cordialmente, dependendo das relações de negócios.);
  • Assinatura (Deve-se obedecer à seguinte ordem: primeiro, o nome do remetente; depois, seu cargo. Somente as letras iniciais devem ser maiúsculas. Não se deve colocar o título do emissor na frente de seu nome. Para indicar que se trata de médico advogado etc., basta que se coloque o registro do CRM ou da OAB, conforme o caso. Também não é necessário colocar o traço acima do nome datilografado, para a assinatura.);
  • Anexos (Parte destinada à enumeração de papéis ou de documentos que acompanha a carta.).

Circular

Quando, em sua empresa, você deseja dirigir-se a muitas pessoas ao mesmo tempo, para transmitir avisos, ordens ou instruções, deve optar por comunicar-se através de uma circular. Na verdade, a circular pode seguir o modelo de uma carta ou ofício, o que a caracteriza é conter um assunto de interesse geral. Muitas vezes, a circular é utilizada internamente nas empresas, com a finalidade de facilitar a comunicação entre diversas seções e departamentos.

Muitas empresas, hoje em dia, têm preferido não destacar a ementa (assunto). Assim, é preciso verificar o modelo adotado na sua empresa. A linguagem utilizada em uma circular deve ser simples e direta para não dar margem a outras interpretações. Todos devem entender claramente o que está escrito.

Estrutura:

  • Timbre da empresa;
  • Número da circular;
  • Data (por extenso);
  • Assunto;
  • Corpo da mensagem;
  • Identificação / Assinatura do emissor da circular.

Declaração

A declaração é utilizada quando se quer atestar ou confirmar algum fato para garantir um direito a uma determinada pessoa.

Divide-se nas seguintes partes:

  • Timbre (Impresso como cabeçalho, contendo o nome do órgão ou empresa. Atualmente a maioria das empresas possui um impresso com logotipo. Nas declarações particulares usa-se papel sem timbre.);
  • Título (Deve-se colocá-lo no centro da folha, em caixa alta.);
  • Texto (Deve-se iniciá-lo a cerca de quatro linhas do título.). Dele deve constar: 
  • Identificação do emissor. Se houver vários emissores, é aconselhável escrever, para facilitar: os abaixo assinados; 
  • O verbo atestar/declarar deve aparecer no presente do indicativo, terceira pessoa do singular ou do plural; 
  • Finalidade do documento, em geral costuma-se usar o termo “para os devidos fins”, mas também se pode especificar: “para fins de trabalho”, “para fins escolares”, etc.
  • Nome e dados de identificação do interessado. Esse nome pode vir em caixa alta, para facilitar a visualização;
  • Citação do fato a ser atestado.
  • Local e data (Deve-se escrevê-los a cerca de três linhas do texto;
  • Assinatura (Assina-se a cerca de três linhas abaixo do local e data).

Memorando

O memorando, estabelecendo uma comparação, é uma espécie de bilhete comercial de que as empresas ou órgãos oficiais se utilizam para estabelecer a correspondência interna entre seus setores e departamentos. Por ser um tipo de correspondência cotidiana, rápida e objetiva, o memorando segue uma forma fixa, sendo para isso utilizado um papel impresso.

Observe a estrutura de um memorando, atentando para a ausência de saudações e finalizações:

  • Timbre;
  • Número do memorando;
  • Data;
  • De (Órgão e/ou responsável);
  • Para (Órgão e/ou responsável);
  • Corpo do texto;
  • Assinatura.

Ofício

Ofício é a correspondência de caráter oficial, equivalente à carta comercial. É dirigido por um funcionário a outro, da mesma ou de outra categoria, bem como por uma repartição a uma pessoa ou instituição particular, ou, ainda, por instituição particular ou pessoa a uma repartição pública. Por tratar-se, sobretudo, de comunicação de caráter público, o ofício requer certo grau de formalidade.

A redação, tal como no caso da carta comercial, tem de ser breve e concisa.

Procuração

Através da procuração uma pessoa (física ou jurídica) autoriza alguém a agir e realizar negócios em seu nome.

O indivíduo que concede a procuração é chamado de mandante, constituinte ou outorgante. Aquele que recebe a procuração é chamado de mandatário, procurador ou outorgado.

A procuração deve ser lavrada em papel ofício, iniciando o texto com identificação e qualificação do outorgante e do outorgado. Os poderes, a finalidade e o prazo de validade da procuração são expressos de forma precisa. Após o texto, a localidade, a data e a assinatura são expressas.

Há dois tipos de procuração:

  • Pública – aquela que é lavrada por tabelião em Livro de Notas. O translado (cópia autêntica do que consta no livro) fica em poder do procurador. É usada em casos de compra e venda de imóveis, em assuntos de maior peso.
  • Particular – aquela que é datilografada ou manuscrita, sem registro no Livro de Notas. Digamos que você não possa fazer sua matrícula na escola. Então, você poderá passar uma procuração particular para alguém de sua confiança que resolverá esse, e apenas esse, assunto para você.

Requerimento

Se você precisar se dirigir a uma autoridade para fazer um pedido para o qual necessite ter amparo na lei, deve fazê-lo através de um requerimento.

Serve para requerer ou pedir uma coisa específica à Administração ou aos organismos públicos. Os requerimentos recebem nomes diferentes, dependendo do organismo ao qual se dirigem:

  • Conhece-se pelo nome de "Memorial" quando é dirigido a uma autoridade máxima, como, por exemplo, o chefe do Estado ou o papa;
  • Chama-se "Exposição" quando se dirige ao Parlamento da nação ou a um órgão do Governo;
  • Chama-se "Pedido" ao requerimento utilizado para o resto dos casos. 

Em geral, podemos observar as seguintes partes:

  • A autoridade destinatária (usa-se Excelentíssimo "Exmo." para Juiz, Promotor, Senadores, Deputados, Vereadores, Presidente da República, Governador, Prefeito e Ministros de Estado; usa-se Ilustríssimo "Ilmo." para as demais autoridades);
  • Nome e qualificação do requerente;
  • Exposição e solicitação;
  • Pedido de deferimento;
  • Localidade e data;
  • Assinatura.


quinta-feira, 8 de abril de 2010

Call Center ontem e hoje

Atualmente, um call center é, em geral, mais ou menos assim:
Mas, há mais tempo, era bem diferente:
A segunda foto é do início da década de 1970 e na época esse tipo de atendimento telefônico não era conhecido e nem tinha os mesmos conceitos do que chamamos de call center hoje em dia. Na verdade, esse serviço era voltado basicamente para o completamento de ligações interurbanas, já que, praticamente não existia o interurbano automático, ou DDD como é mais conhecido.

Obs: O espaço físico onde foram tiradas as duas fotos é exatamente o mesmo. Elas estão separadas por uns 30 anos aproximadamente.

quinta-feira, 1 de abril de 2010

Análise de Pontos de Função: Glossário em Inglês e Português

Os manuais da técnica de Análise de Pontos de Função (APF) foram desenvolvidos originalmente em inglês, porém, os principais autores brasileiros sobre o assunto acabaram traduzindo os termos e siglas utilizados para o Português, quando escreveram os seus livros.

Assim, nós temos uma pequena confusão de siglas, dependendo se estamos lendo algum material de referência na língua original ou traduzido.

Para tentar dar uma organizada no assunto, estou fazendo um glossário, nas duas línguas, dos principais termos utilizados:

  • FPA - Function Point Analysis;
  • APF - Análise de Pontos de Função;
  • FP - Function Point;
  • PF - Ponto de Função;

Data Functions:
Funções de Dado:

  • ILF - Internal Logical Files;
  • ALI - Arquivo Lógico Interno;
  • EIF - External Interface Files;
  • AIE - Arquivo de Interface Externa;
  • DET - Data Element Type;
  • TD - Tipo de Dado (ou menos usado: DER - Dado Elementar Referenciado);
  • RET - Record Element Type;
  • TR - Tipo de Registro (ou menos usado: RLR - Registro Lógico Referenciado);

Transactional functions:
Funções de Transação:

  • EI - External Inputs;
  • EE - Entrada Externa;
  • EO - External Outputs;
  • SE - Saída Externa;
  • EQ - External Inquiry;
  • CE - Consulta Externa;
  • FTR - File Type Referenced;
  • AR - Arquivo Referenciado (ou menos usado: ALR - Arquivo Lógico Referenciado);
  • RET - Record Element Type;
  • TR - Tipo de Registro (ou menos usado: RLR - Registro Lógico Referenciado);

Fórmula para calcular o valor do fator de ajuste:

VAF = (TDI * 0.01) + 0.65 ; where: TDI = ∑ DI
VAF = (TDI * 0.01) + 0.65 ; onde: TDI = ∑ NI

  • VAF - Value Adjustment Factor;
  • VAF - Valor do Fator de Ajuste;
  • DI - Degree of Influence;
  • NI - Nível de Influência;
  • TDI - Total Degree of Influence;
  • TDI - Nível de Influência Total;

Fórmula para calcular o tamanho do projeto de desenvolvimento:

DFP = (UFP + CFP) * VAF

  • DFP - Development project function point count;
  • DFP - Tamanho do projeto de desenvolvimento;
  • UFP - Unadjusted function point count;
  • UFP - Tamanho das funções entregues;
  • CFP - Unadjusted function points added by the conversion;
  • CFP - Tamanho das funções de conversão;
  • VAF - Value Adjustment Factor;
  • VAF - Valor do Fator de Ajuste;

Fórmula para calcular tamanho de projeto de melhoria:

EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL* VAFB)

  • EFP - Enhancement project function point count;
  • EFP - Tamanho do projeto de melhoria;
  • ADD - Unadjusted function point count of those functions that were or will be added;
  • ADD - Tamanho das novas funções;
  • CHGA - Unadjusted function point count of those functions that were or will be modified by the enhancement project after the modifications;
  • CHGA - Tamanho das funções alteradas, depois da melhoria;
  • CFP - Function point count of those functions added by the conversion;
  • CFP - Tamanho das funções de conversão;
  • VAFA - Value adjustment factor of the application after the enhancement project is complete;
  • VAFA - VAF depois da melhoria;
  • DEL - Unadjusted function point count of those functions that were or will be deleted by the enhancement project;
  • DEL - Tamanho das funções excluídas.
  • VAFB - Value adjustment factor of the application before the enhancement project begins;
  • VAFB - VAF antes da melhoria;

Fórmula para estabelecer o tamanho inicial da aplicação:

AFP = ADD * VAF

  • AFP - Initial application function point count;
  • AFP - Tamanho inicial da aplicação;
  • ADD - Unadjusted function point count of those functions that were installed by the development project;
  • ADD - Tamanho das funções da aplicação;
  • VAF - Value adjustment factor of the application;
  • VAF - Valor do Fator de Ajuste;

Fórmula para calcular o tamanho da aplicação após um projeto de melhoria:

AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA
AFPA = [(AFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA

  • AFP - Application's adjusted function point count;
  • AFPA - Tamanho da aplicação após a melhoria;
  • UFPB - Application's unadjusted function point count before the enhancement project begins;
  • AFPB - Tamanho da aplicação antes da melhoria;
  • ADD - Unadjusted function point count of those functions that were added by the enhancement project;
  • ADD - Tamanho das novas funções;
  • CHGA - Unadjusted function point count of those functions that were changed by the enhancement project, after the changes;
  • CHGA - Tamanho das funções alteradas, depois da melhoria;
  • CHGB - Unadjusted function point count of those functions that were changed by the enhancement project, before the changes were made;
  • CHGB - Tamanho das funções alteradas, antes da melhoria;
  • DEL - Unadjusted function point count of those functions that were deleted by the enhancement project;
  • DEL - Tamanho das funções excluídas;
  • VAFA - Value adjustment factor of the application after the enhancement project is complete;
  • VAFA - VAF depois da melhoria;


sexta-feira, 26 de março de 2010

JAD (Joint Application Design) - Técnica de levantamento interativo

No desenvolvimento de sistemas, uma das tarefas mais difíceis é conseguir extrair do cliente todos os requisitos necessários a fim de retratar fielmente o processo de negócio que será implementado por meio de um sistema informatizado.

Esta dificuldade tem várias causas possíveis: muitas vezes os requisitos não estão suficientemente claros para o próprio cliente do sistema; os processos de negócios passam por áreas e pessoas diferentes e nem sempre elas concordam sobre quais são os requisitos do sistema; outras vezes, o cliente aproveita a oportunidade de informatizar o processo de negócio para rever o próprio processo e essas duas atividades acabam se confundindo; o cliente pode mudar de ideia ao longo do tempo e um requisito definido no início da especificação pode estar diferente no final.

Para minimizar estes problemas, uma solução é reunir todos os envolvidos com a definição dos requisitos e fazer um esforço concentrado para levantar os requisitos do sistema no menor espaço de tempo possível.

Uma boa ferramenta para promover este tipo de dinâmica é o JAD (Joint Application Design). O JAD é uma técnica de levantamento interativo, criada por dois profissionais da IBM do Canadá na década de 1970 onde, em uma ou mais sessões, são reunidos todos os interessados no assunto para tomar as decisões sobre o mesmo. A técnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de solução de problemas baseado em CONSENSO.

A dinâmica do JAD:

São feitas reuniões participativas, chamadas de sessões, envolvendo representantes de todas as áreas relacionadas com os assuntos em discussão.

As regras da sessão:
  • Todos os participantes são iguais. Nas sessões JAD, a estrutura hierárquica e de poder são deixadas do lado de fora. Todas as posições tem o mesmo peso e serão avaliadas pelo grupo sem levar em conta qual é a origem da mesma.
  • Apenas uma pessoa fala de cada vez. Assim todos terão chance de expressar a sua opinião e de ouvir as opiniões do restante do grupo.
  • Todas as opiniões são válidas. É preciso não ter uma posição pré-concebida sobre as opiniões dadas.
  • Hora para começar, interromper e terminar. É necessário definir uma agenda para as sessões e cumpri-la à risca.
  • Celular desligado. Durante a sessão não devem acontecer interrupções externas.
  • Recursos visuais. Utilizar intensivamente recursos visuais para tornar o projeto do sistema mais palpável e permitir que ele seja entendido pelos diversos participantes. Uma fotografia é mais explicativa e rica em detalhes do que 1000 palavras para a descrição de um fato.
Os papeis na sessão:
  • Sponsor (Patrocinador). É o executivo responsável pelo projeto, o dono do sistema. Ele precisa ter autonomia para tomar decisões, definir estratégias e direcionar o trabalho.
  • Facilitador. É o responsável por conduzir a sessão. Ele não precisa ser um especialista no assunto que está sendo tratado. Ele deverá estar focado em organizar a dinâmica, dando a palavra a cada participante, obtendo o consenso sobre os assuntos tratados, organizando o registro das decisões e intermediando os conflitos.
  • Escriba. É a pessoa responsável por registrar todas as discussões e decisões em um local que todos possam visualizar, como um quadro ou flip-chart.
  • Documentador. É o responsável por registrar todas as decisões em um documento formal, como uma ata de reunião ou uma especificação de requisitos, que será assinado por todos ao final das sessões.
  • Especialistas. São as pessoas que tem conhecimento do assunto que está sendo discutido e que podem efetivamente contribuir para a discussão e na tomada de decisões.
  • Observadores. São pessoas que estão na sessão apenas para conhecer mais do assunto que está sendo tratado ou para assimilar a técnica da reunião. Os observadores não podem se manifestar durante a sessão.
Os fatores de sucesso:
  • A sessão precisa ter presente as pessoas que tem poder de decisão sobre o assunto tratado, pois, não adianta tomar decisões durante a reunião que poderão ser contestadas quando todos voltarem para o escritório.
  • As decisões precisam ser tomadas por consenso, pois, todos os participantes da sessão precisam sair de lá comprometidos com as definições registradas.
  • As sessões devem ocorrer fora do ambiente de trabalho dos participantes para evitar interrupções e prevenir que os participantes se vejam tentados a tratar de assuntos ligados a sua rotina diária.
  • Não deixar que os participantes imponham suas opiniões em função do seu nível hierárquico, para evitar que pessoas de nível hierárquico mais baixo fiquem constrangidas em debater ou discordar.
  • Definir claramente qual será o produto gerado no final das sessões.
Os benefícios esperados em relação aos métodos tradicionais:
  • Maior produtividade. Estudos relatam aumentos de 20 a 60% na produtividade, em relação aos métodos tradicionais.
  • Maior qualidade. Usuários e analistas de sistemas costumam citar “projeto de softwares de alta qualidade” como sendo o maior benefício do método.
  • Trabalho em equipe.  Promove o espírito de cooperação, entendimento e trabalho em equipe.
  • Custos mais baixos. O projeto de alta qualidade, obtido através do JAD, possibilita uma grande economia de tempo e dinheiro mesmo após a entrega do sistema.

quarta-feira, 10 de março de 2010

MPT.BR - Modelo de maturidade em teste de software

Assim como existem modelos para medir a maturidade de uma empresa no desenvolvimento de software, tais como MPS.BR e CMMI, existem também modelos para medir a maturidade da organização no processo de teste do software.

Aqui no Brasil está sendo desenvolvido o modelo MPT.BR - Melhoria de Processo de Teste de Software Brasileiro.

Duas entidades trabalham em conjunto no seu desenvolvimento:

  • ALATS – Associação Latino Americana de Teste de Software
  • RIOSOFT – Sociedade Núcleo de Apoio à Produção e a Exportação de Software

O conceito do modelo de maturidade no teste é o mesmo do modelo de maturidade no desenvolvimento de software. Ambos procuram determinar em que estágio de maturidade a organização se encontra naquele assunto e classifica os diversos estágios em diferentes graus de maturidade.

Segundo a ALATS, o MPT.BR foi criado com o objetivo de manter a compatibilidade com o MPS.BR e com o CMMI e permitir que empresas que implementaram um dos dois na sua área de desenvolvimento, possam, com um pequeno esforço adicional, aumentar o nível de maturidade da sua área de teste de software. Entende-se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os resultados melhorem substancialmente. Acredita-se que seja necessária uma melhoria de maturidade também da área de teste de software.

O MPT.BR é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos operacionais.

Os critérios usados pelas duas entidades na estruturação do modelo foram:

  • Definir critérios que garantam a qualidade do processo de teste de software
  • Não criar nada novo, logo a base é um modelo de melhoria do processo de desenvolvimento de software, no caso o MPS.BR (ou CMMI), já existente no mercado
  • Poder ser usado por áreas de teste de software de empresas pequenas, médias e grandes
  • Permitir a evolução das áreas de testes atingindo níveis mais altos de maturidade e, conseqüentemente, níveis mais altos de qualidade

Os níveis de maturidade definidos no modelo são:

  • Nível 1 Gerência de Projetos de Teste - GPT
  • Nível 2 Gerência de Requisitos de Teste - GRT
  • Nível 3 Aquisição – AQU (opcional); Gerência de Configuração – GCO; Garantia da Qualidade - GQA; Medição - MED
  • Nível 4 Gerência de Recursos Humanos - GRH; Gerência de Reutilização - GRU (opcional)
  • Nível 5 Desenvolvimento de Requisitos - DRE; Integração do Produto - ITP; Validação - VAL (opcional); Verificação
  • Nível 6 Análise de Decisão e Resolução - ADR; Desenvolvimento para Reutilização - DRU (opcional); Gerência de Riscos - GRI
  • Nível 7 Análise de Causas e Resolução de Problemas

Abaixo, estão listados alguns outros modelos de maturidade de teste existentes no mercado:

  • Testability Suport Model (TSM)
  • Testing Maturity Model (TMM)
  • Test Process Improvement (TPI)
  • Test Organization Maturity (TOMtm)
  • Testing Assessement Program (TAP)
  • Testing Improvement Model (TIM)
  • Outros (Ex.: MMT)

Porém, os diversos modelos existentes apresentam alguns problemas que acabaram por levar à definição do modelo MPT.BR:

  • Não existe uma entidade no Brasil responsável pela manutenção dos modelos
  • Foram elaborados por entidades privadas
  • Não são fáceis e nem baratos de serem implementados

Comparação entre os níveis de maturidade do CMMI, MPS.BR e MPT.BR:

  • MPT: Nível 1 - MPS: Sem correspondência - CMMI: Sem correspondência
  • MPT: Nível 2 - MPS: Nível G - CMMI: Sem correspondência
  • MPT: Nível 3 - MPS: Nível F - CMMI: Level 2
  • MPT: Nível 4 - MPS: Nível E - CMMI: Sem correspondência
  • MPT: Nível 5 - MPS: Nível D - CMMI: Sem correspondência
  • MPT: Nível 6 - MPS: Nível C - CMMI: Level 3
  • MPT: Nível 7 - MPS: Nível A - CMMI: Level 4, 5


terça-feira, 9 de fevereiro de 2010

Dia Mundial da Internet Segura

9 de fevereiro é o Dia Mundial da Internet Segura.

O Dia da Internet Segura ("Safer Internet Day") é uma iniciativa que mobiliza países de todo o mundo para promover o uso seguro da internet. Essa ideia foi organizada pela Rede Insafe, que agrupa as organizações que trabalham na promoção do uso consciente da internet nos países da União Européia. Este ano, o tema central é "Pense antes de postar". No site do Programa, você encontra cartilhas, jogos, vídeos e muitas atividades voltadas para a conscientização de crianças, jovens e adultos sobre a utilização da internet.

Dia da Internet Segura - 2010

Em sintonia com essa comemoração, o Ministério Público de Minas Gerais lançou hoje a segunda edição da cartilha "Navegar com Segurança". Em breve, o material estará disponível para download no site da Promotoria de Crimes Cibernéticos. Por enquanto, você pode conferir a primeira edição da cartilha:

segunda-feira, 8 de fevereiro de 2010

Virtualização e Computação em nuvem

Na área de TI, de tempos em tempos, alguns termos entram na moda e passam a ser repetidos como um mantra. Atualmente, um dos termos mais citados é a "Computação em nuvem" (*) (ou, em inglês, Cloud computing) que é um conceito que deriva do conceito de "Virtualização", que é outro hit do momento.

Assim sendo, aproveitando a oportunidade, vamos ver do que se tratam estes dois termos e tentar esclarecer um pouco dos conceitos por trás dos mesmos.

Primeiro, é preciso tomar certo cuidado, pois, como todo termo que se torna moda, a "Computação em nuvem" já foi adotada pelo marketing e, dessa forma, qualquer produto que quer se mostrar como moderno e antenado é classificado como "Cloud", o que nem sempre é verdade.

Virtualização de servidores

A virtualização de servidores é a tecnologia capaz de simular ambientes totalmente autônomos em uma mesma máquina física. Ou seja, é a possibilidade de criar maior quantidade de servidores lógicos do que se dispõe de servidores físicos.

Essa é uma tecnologia que não é exatamente recente, ela já é usada nos mainframes desde a década de 1960.

A virtualização de servidores proporciona redução nos custos de aquisição dos servidores físicos, facilita a administração, diminui os recursos de infra-estrutura necessários para hospedar os servidores e o consumo de energia

A virtualização pode ser feita com a instalação de uma camada software desenvolvida especificamente para esta finalidade. Os principais fornecedores são: VMware, Citrix e Microsoft.

Uma infra-estrutura virtual consiste nos seguintes componentes:

- O monitor das máquinas virtuais, conhecido como Hypervisor;
- Os serviços de infra-estrutura virtual, como gerenciamento de recursos e backup consolidado, para otimizar os recursos disponíveis entre as máquinas virtuais;
- Soluções de automação que oferecem recursos especiais para otimizar um processo de TI específico, como provisionamento ou recuperação de desastres.

Você pode virtualizar um servidor físico, transformando-o em vários servidores virtuais, como pode virtualizar vários servidores físicos em conjunto transformando-os em outro conjunto de servidores virtuais.

Principais benefícios da virtualização:

- Diminuição do espaço físico, do cabeamento e do consumo de energia;
- Facilitação do gerenciamento e manutenção;
- Mais facilidade de monitoramento do ambiente, com diversas métricas de medição do consumo de hardware;
- Flexibilidade e escalabilidade;

Principais dificuldades encontradas para implantação:

- Resistência dos fornecedores de software em relação à compatibilidade com os servidores virtuais;
- Nem todos os produtos são suportados pelos fabricantes em ambiente virtual;
- A administração do ambiente fica mais complexa, podendo dificultar que se encontre a causa raiz de um problema. Para minimizar isso, é preciso investir em treinamento e em ferramentas de monitoramento e diagnóstico.

Computação em nuvem (Cloud computing)

Computação em nuvem está intimamente relacionada com a virtualização e pode ser considerada a versão "nas nuvens" dessa tecnologia.

A Computação em nuvem é fruto da convergência de diferentes tecnologias já existentes: Software como serviço (Software as a service - SaaS), Computação em grid (Grid computing) e a própria virtualização.

Ela se apóia principalmente nas possibilidades de conexão e interatividade permitidas pela internet para proporcionar aos usuários acesso a data centers remotos administrados por terceiros.

Trata-se na verdade da transferência dos recursos computacionais antes localizados nas estações de trabalho e servidores locais para estruturas tecnológicas localizadas em local fora do nosso ambiente.

Os exemplos mais comuns são os serviços de webmail e de edição de documentos, que hoje permitem que as mensagens e documentos fiquem armazenados na nuvem e possamos acessá-las de qualquer lugar em que haja conexão com a internet.

Para as empresas, a Computação em nuvem permite a flexibilidade e a elasticidade dos data centers, pois, a contratação dos serviços de processamento, armazenamento, backup, etc. pode ser feita de acordo com a demanda de momento, sendo mais fácil tratar os casos de sazonalidade.

Este conceito, ainda é adotado de forma tímida pelas empresas, em função do receio em relação às questões de segurança, confidencialidade, disponibilidade e responsabilidade legal.

(*) Em português, tem-se adotado outras variações para "Computação em nuvem", como "Computação nas nuvens" ou "Computação na nuvem", mas, eu prefiro adotar a primeira forma, pois, acredito que ele representa melhor o conceito que se deseja transmitir.

quarta-feira, 27 de janeiro de 2010

Contrato CLT X PJ: Planilha com IRPF e INSS 2010

Anteriormente eu comparei o salário com carteira assinada (CLT) e o faturamento necessário como pessoa jurídica (PJ), para que houvesse equivalência entre os dois.

Disponibilizei, ainda, uma planilha para simulações, porém, com a mudança anual das tabelas de desconto do imposto de renda de pessoa física (IRPF) e do INSS, a planilha fica desatualizada. Assim sendo, eu estou disponibilizando uma nova versão da planilha, com as tabelas de desconto do imposto de renda retido na fonte e do INSS configuradas para 2010. A planilha atualizada pode ser encontrada em:

http://guiarapido.tripod.com/arq.html

sexta-feira, 22 de janeiro de 2010

SLA e sua sopa de letras

Eu já falei anteriormente sobre SLA (Service Level Agreement ou Acordo de Nível de Serviço), inclusive, com um exemplo prático.

Porém, existem diversas siglas associadas ao SLA, formando uma verdadeira sopa de letras. Cada uma destas siglas representam conceitos associados ou complementares ao SLA. Assim, para enriquecer o entendimento sobre o assunto, eu vou listar os principais termos usados pelo mercado e conceituá-los.

SLA - inglês: Service Level Agreement - português: Acordo de Nível de Serviço

É um contrato entre um fornecedor de serviços e um cliente, especificando em termos mensuráveis, quais serviços o fornecedor vai prestar. O objetivo principal do SLA é garantir contratualmente, características de qualidade, eficiência e eficácia dos produtos e serviços disponibilizados para os clientes.

O SLA estabelece uma sintonia entre a empresa, o cliente e o fornecedor. Dessa forma, o cliente sabe o que esperar da empresa e a empresa somente irá acertar as entregas conforme o combinado com o cliente e o fornecedor. Alguns resultados viabilizados pelo SLA são a redução de custo, o incremento da satisfação dos usuários e a maior disponibilidade dos serviços de TI.

SLM - inglês: Service Level Management - português: Gerenciamento de Nível de Serviço 

É o processo responsável por monitorar e relatar o cumprimento ou não dos níveis de serviço acordados. É, por isso, uma disciplina extremamente estratégica para as organizações, pois permite também monitorar de forma precisa os serviços prestados, fundamentando iniciativas de melhoria contínua.

OLA - inglês: Operational Level Agreement - português: Acordo de Nível Operacional 

Um ponto muito relevante para estabelecer os SLAs com os clientes, são os OLAs, que são os acordos estabelecidos com os fornecedores internos de serviços e que irão dar o suporte necessário para o cumprimento dos acordos externos.

UC - inglês: Underpinning Contract - português: Contrato de Apoio 

Outro ponto importante para estabelecer os SLAs, são os UCs, estes são acordos estabelecidos com fornecedores externos. Isso porque, para fazer um contrato de nível de serviço com o cliente, é necessário que os responsáveis saibam, antes, os parâmetros que seus fornecedores vão oferecer.

Como diretriz para o gerenciamento de SLA, deve estar previsto que os contratos firmados com os prestadores de serviços devem ter SLA compatível com aquele firmado entre a Companhia e o cliente; da mesma forma, os SLAs devem ter suporte de acordos operacionais internos (OLAs) e externos (UCs) que permitam monitorar e atingir as metas definidas.

sexta-feira, 15 de janeiro de 2010

O que é BPO?

"A contratação de uma empresa para prover serviços para tarefas específicas dentro da sua organização, garantindo o nível de serviço".

Isso é BPO (sigla para Business Process Outsourcing ou, em português, Terceirização de Processos do Negócio). Ele é adotado com o objetivo de diminuir custos em tarefas que não sejam claramente relacionadas ao negócio fim da empresa. Outras metas buscadas com a implantação desse modelo de gestão são o aumento da produtividade, da capacidade de inovação e como vantagem competitiva, tendo em vista que os maiores esforços e o foco da organização ficam direcionados aos seus processos chaves.

Tradicionalmente, o modelo BPO é utilizado por empresas de manufatura. Um exemplo clássico é a Coca-Cola, que terceiriza toda a cadeia de suprimentos e é hoje praticamente uma empresa focada em marketing. Porém, atualmente o BPO está cada vez mais sendo usado por empresas de serviços, notadamente do setor de Tecnologia da Informação.

O BPO é mais específico do que uma simples terceirização (ou outsourcing). É o fornecimento de soluções desenvolvidas após uma análise profunda dos processos da empresa que propõem uma remodelação atrelada a inovações e adoção de tecnologias para melhorar o desempenho e a qualidade.

As fornecedoras de BPO podem assumir todas as operações “meio” das companhias, ou seja, tudo aquilo que não faz parte dos seus negócios principais. São prestadoras de serviços cujas atividades vão desde a gestão informacional por meio de organização, BackOffice, guarda, digitalização e gerenciamento de documentos até a auditoria dos processos e contas, passando pela gestão da cadeia logística e de suprimentos em plataformas integradas de serviços, infra-estrutura e softwares.

Embora o conceito de terceirização ainda seja incipiente no Brasil (contratado só por 15% das empresas), trata-se de uma área que deve movimentar R$ 12 bilhões no País só em 2010, segundo o IDC (International Data Corporation).

No setor, o serviço que mais cresce é o BPO que, segundo o Instituto Gartner, evolui mais de 8% ao ano em função da difusão do conceito de serviços compartilhados. Essa taxa de crescimento deve ser estimulada pela manutenção de segmentos que já são grandes usuários como atendimento ao cliente e finanças, e pela entrada de novos setores como compras - cuja adoção deve crescer 27% e recursos humanos, cerca de 24%.

Os especialistas da IDC Brasil listam alguns passos a serem seguidos antes de adotar o modelo BPO:

  1. Mapear a organização; 
  2. Identificar os parceiros adequados; 
  3. Conquistar o comprometimento da empresa como um todo; 
  4. Definir os indicadores ideais de negócios (que permitam elaborar acordos de níveis de serviço - SLA's); 
  5. Definir bônus e penalidades, representando uma mudança na relação entre fornecedores e clientes. 

Os problemas mais comuns encontrados na adoção prática do BPO são:

  1. Não cumprimento dos níveis de serviço acordados; 
  2. Cláusulas contratuais que não são claras; 
  3. Alteração dos requisitos, gerando despesas imprevistas; 
  4. Dependência do BPO, reduzindo a flexibilidade da organização. 

Um desdobramento de BPO é o KPO (Knowledge Process Outsourcing ou, em português, Terceirização de Processos de Conhecimento), que inclui atividades que exigem maior habilidade e conhecimentos especializados para a execução. Por exemplo, enquanto uma companhia de seguros pode terceirizar a entrada dos dados de seus clientes como parte de uma iniciativa BPO, ela também pode optar por utilizar um prestador de serviços KPO para avalizar novos pedidos de seguro com base em um conjunto de critérios ou regras de negócio. Evidentemente, este trabalho requer os esforços de um conjunto de trabalhadores mais especializados.

Outra tendência que começa a ser difundida também é o termo BTO (Business Transformation Outsourcing ou, em português, Terceirização da Transformação do Negócio), que remete à idéia de criação de prestadores de serviços que contribuam para o esforço de transformar a empresa, torná-la mais dinâmica, ágil e com uma operação mais flexível.