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