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

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!!!

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.

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.

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.

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.

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."

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.

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.

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.