Tem muita gente que gosta da informação completa e iniciaria este relato em 3500 aC com a invenção do Ábaco, não deixaria de comentar as invenções de 1600 (Réguas de Cálculos, Calculadora de Páscal) e algumas outras que não serão comentadas a fundo aqui, porque não pretendo comentar as invenções precursoras ou mesmo a chamada geração 0.
A primeira geração de computadores, propriamente dita, existiu dos anos 30 até o final da década de 50. Estas máquinas construídas com relés e válvulas eletrônicas chegavam a fantástica velocidade de cálculos em milésimos de segundos. Tinham dispositivos de entrada e saída primitivos e cartões perfurados eram o melhor meio encontrado na época para fazer o armazenamento de informações.
De curiosidade, o ENIAC que foi concluído em 1946 pesava 30 toneladas e ocupava 180 metros quadrados, havia sido projetado para fazer complexos cálculos estratégicos para o exército americano, mas ficou pronto apenas depois da guerra. Ele não tinha sistema operacional e funcionava de forma muito semelhante a uma calculadora dos tempos de hoje.
Depois, com a invenção dos transistores em 1948 muitos novos projetos foram levados adiante na área da computação. Além dos transistores (que também fizeram os computadores serem menos suscetíveis a temperatura) também surgiu as memórias de anéis ferromagnéticos (fita magnética) que se tornou a forma de armazenamento comum da época.
Com esta tecnologia, surge a IBM na década de 60, que conseguiu lançar um computador incrivelmente barato perto do ENIAC chamado de IBM 7090 que custava "apenas" 3 milhões de dólares que é um dos maiores exemplos da chamada segunda geração. E a própria IBM lançou ainda no início dos anos 60 o IBM 7040 que era inferior em processamento, mas com um custo ainda menor que o IBM 7090.
Dos transistores, passamos as pastilhas de silício de circuitos integrados (chips), que conseguiam substituir cerca de mil transistores com uma única pastilha através da técnica de SSI (Small Scale Integration). Com isso os computadores diminuiram de tamanho e preço ainda mais. E pouco depois, em 1964, surgiu o IBM 360 que é um clássico da terceira geração de computadores. Eram chamados de Minicomputadores, também conhecidos como MainFrames, que forneciam processamento aos chamados "terminais burros". Pontos de acesso que apenas serviam de interface para o computador de verdade graças a tecnologias de multi-processamento. Ele era capaz de realizar 2 milhões de adições ou 500 mil multiplicações por segundo.
Durante a década de 70 foi que começaram duas grandes tecnologias para os dias de hoje. A primeira foi uma rede criada para ligar 4 minicomputadores, chamada de ARPANET, que era a semente da Internet que conhecemos hoje.
A segunda tecnologia foi a técnica LSI (Large Scale Integration), que conseguiu combinar até 65 mil componentes em uma única pastilha de silício. Que culminou com a Intel criando o primeiro microprocessador, Intel 4004 em 1971. E começaram a surgir os microcomputadores e computadores pessoais em 1975 com o Altair 8800. Depois em 76 uma empresa de garagem, chefiada por Sthephen Wozniak e Steve Jobs criou o Apple I que serviu de base para o Apple II, apenas um ano mais tarde, que foi o primeiro grande sucesso comercial de computadores pessoais. E ainda nos anos 70 a VLSI (Very Large Scale Integration) foi desenvolvida conseguindo colocar milhões de componentes em uma única pastilha de silício.
Em 1981 a IBM também entrou no mercado dos microcomputadores com o PC que em pouco tempo se tornou um padrão de mercado. E por volta de 1983 a ARPANET evoluiu para uma rede militar chamada MILNET nos EUA e MINET na Europa utilizando-se da mesma tecnologia. Além disso, eles conectaram as duas redes à ARPANET (que passou a ser utilizada por universidades e empreiteiras americanas) e ligaram as redes americanas e européias com links limitados via satélite. Em pouco tempo se tinha mais de 100 mil usuários.
A década de 90 não foi marcada por uma evolução do hardware do computador, mesmo tendo os computadores avançado incrivelmente em velocidade neste período. 1990 marcou o lançamento do WWW, que havia sido proposto um ano antes. Ou seja, o lançamento da internet como conhecemos hoje. Em 92 já havia mais de 1 milhão de servidores na internet. Em 1995 é que é feito o lançamento do Internet Explorer do Windows e provedores de BBS (com conexão discada) passam a oferecer a conexão com a internet realmente. Em 97 se alcança a marca de 19 milhões de servidores no mundo todo. A banda larga também começou a surgir no fim desta década.
Mas foi só no início da década seguinte que nos EUA a banda larga começou a crescer mais rápido que a conexão discada, em 2001. Redes de distribuição Peer to Peer que começaram com o Napster no final da década anterior cresceram bastante, mesmo com seu precursor tendo falhado, tornando a distribuição pirata de softwares, filmes e músicas bastante comum. E em fevereiro de 2005 o site YouTube foi criado, mostrando que a capacidade da internet para videos já começava a ser aceitável e promissora. Hoje em dia, é possível fazermos video chamadas de telefones celulares, GPS portáteis e muitas outras tecnologias.
sábado, 8 de agosto de 2009
quarta-feira, 5 de agosto de 2009
Técnicas e Estratégias de Validação de Software
O principal para uma boa estratégia de validação é minimizar os problemas o mais cedo possível. Mas nem sempre isso é possível, então
O que um bom plano deveria conter:
1-) Testes Unitários (desenvolvedor);
De preferência automáticos, para garantir que serão bons testes (testes unitários manuais tendem a fazer o "caminho feliz").
Os testes podem ser estruturais (caixa branca), funcionais (caixa preta) ou de regressão (testes que verificam que o resultado final não mudou), mas para ajudar com o desenvolvimento dos testes unitários existem algumas técnicas de cobertura de código:
- Partição em classes de equivalência (Equivalence class partitioning) - usar amostragem de cada possível valor que os parâmetros de entrada podem assumir
- Análise de valores limite (Boundary Value Analysis) - nestes testes deve-se conferir os valores limites do software, onde há alterações de decisão
- Transição de estados (State Transition Testing) - utilizado para testar as chamadas máquinas de estados e conferir que as transições estão acontecendo corretamente;
- Tabela de decisão (Decision Table) - tabela com as variáveis como condições e quais ações tomar baseando-se em seus resultados, para verificar que estas sequências funcionam;
- Testes Empareados (Pairwise Testing) - para cada par de parâmetros de entrada de um sistema, testa-se todas as combinações destes parâmetros;
2-) Testes de Sistemas (desenvolvedor);
Verificações com o sistema funcionando ou testes de partes integradas e não mais de funções individuais. Pode-se fazer uma integração incremental ou total em cada etapa de testes.
Já para os testes de integração, é bom contar com algumas técnicas um pouco mais amplas:
Integração Não-Incremental que usa a abordagem Big-Bang - já integra todo o software e testa ele todo integrado;
Integração Incremental onde o programa é construído e testado em pequenos segmentos e cada vez se agrega uma parte maior do software;
Integração Top-Down - integra e testa de cima para baixo;
Integração Botton-Up - integra e testa de baixo para cima;
3-) Validação (testador independente);
Execução de roteiros de validação mesmo. E como chegamos na hora de validar o sistema como um todo, é necessário conhecermos um pouco mais do que é necessário se considerar para garantir a qualidade do software. Segundo a ISO/IEC 9126 temos as seguintes características gerais para levar em consideração:
- Funcionalidade (satisfaz as necessidades?);
- Confiabilidade (é imune a falhas e estável?);
- Usabilidade (é fácil de usar?);
- Eficiência (é rápido e eficiente?);
- Manutenibilidade (é fácil de alterar e de manter?);
- Portabilidade (é fácil de ser utilizado em outro ambiente?);
4-) Testes de Aceitação (usuário final/gerente de produto);
Deixar o produto nas mãos deste usuário para validar as funcionalidades novas, pode encontrar outros problemas, mas não há roteiro envolvido.
Já escrevi sobre este assunto algumas vezes e podem encontrar outras matérias sobre testes no meu blog.
O que um bom plano deveria conter:
1-) Testes Unitários (desenvolvedor);
De preferência automáticos, para garantir que serão bons testes (testes unitários manuais tendem a fazer o "caminho feliz").
Os testes podem ser estruturais (caixa branca), funcionais (caixa preta) ou de regressão (testes que verificam que o resultado final não mudou), mas para ajudar com o desenvolvimento dos testes unitários existem algumas técnicas de cobertura de código:
- Partição em classes de equivalência (Equivalence class partitioning) - usar amostragem de cada possível valor que os parâmetros de entrada podem assumir
- Análise de valores limite (Boundary Value Analysis) - nestes testes deve-se conferir os valores limites do software, onde há alterações de decisão
- Transição de estados (State Transition Testing) - utilizado para testar as chamadas máquinas de estados e conferir que as transições estão acontecendo corretamente;
- Tabela de decisão (Decision Table) - tabela com as variáveis como condições e quais ações tomar baseando-se em seus resultados, para verificar que estas sequências funcionam;
- Testes Empareados (Pairwise Testing) - para cada par de parâmetros de entrada de um sistema, testa-se todas as combinações destes parâmetros;
2-) Testes de Sistemas (desenvolvedor);
Verificações com o sistema funcionando ou testes de partes integradas e não mais de funções individuais. Pode-se fazer uma integração incremental ou total em cada etapa de testes.
Já para os testes de integração, é bom contar com algumas técnicas um pouco mais amplas:
Integração Não-Incremental que usa a abordagem Big-Bang - já integra todo o software e testa ele todo integrado;
Integração Incremental onde o programa é construído e testado em pequenos segmentos e cada vez se agrega uma parte maior do software;
Integração Top-Down - integra e testa de cima para baixo;
Integração Botton-Up - integra e testa de baixo para cima;
3-) Validação (testador independente);
Execução de roteiros de validação mesmo. E como chegamos na hora de validar o sistema como um todo, é necessário conhecermos um pouco mais do que é necessário se considerar para garantir a qualidade do software. Segundo a ISO/IEC 9126 temos as seguintes características gerais para levar em consideração:
- Funcionalidade (satisfaz as necessidades?);
- Confiabilidade (é imune a falhas e estável?);
- Usabilidade (é fácil de usar?);
- Eficiência (é rápido e eficiente?);
- Manutenibilidade (é fácil de alterar e de manter?);
- Portabilidade (é fácil de ser utilizado em outro ambiente?);
4-) Testes de Aceitação (usuário final/gerente de produto);
Deixar o produto nas mãos deste usuário para validar as funcionalidades novas, pode encontrar outros problemas, mas não há roteiro envolvido.
Já escrevi sobre este assunto algumas vezes e podem encontrar outras matérias sobre testes no meu blog.
domingo, 2 de agosto de 2009
Análise de Requisitos
Já houve um tempo em que os usuários não entendiam a magia que acontecia por trás dos sistemas de software. Eles podiam não entender como se dava o desenvolvimento do software, não conseguem especificar muito bem o que desejam do software e era muito dificil desenvolver algo sem saber exatamente o que deveria ser feito.
Então muitas técnicas surgiram e atualmente as principais técnicas de análise de requisitos consistem em fazer entrevistas com os stakeholders para se melhorar todos os requisitos, procurando remover contradições, priorizar os requisitos, permitir que eles façam a escolha também do que pode ser feito com relação aos custos.
Em alguns casos, se for julgado necessário, é possível se fazer uma reunião com todos os interessados para se definir o escopo/custo geral, principalmente quando cada uma das partes deseja algo diferente e precisam entrar em um acordo.
A forma comum de se documentar isso é por meio de contrato. E mais do que a lista de funcionalidades que pode ser muito longa, se propõe uma lista de objetivos mensuráveis que deve ser alcançada com protótipos o quanto antes, para que estes objetivos maiores possam ser atingidos.
Outras duas técnicas muito conhecidas para ajudar a exemplificar e facilitar a visualisação deste software final são a prototipação e os casos de uso para ajudar na especificação dos requisitos.
O problema é que a prototipação acabava gerando uma certa ansiedade e sensação de que o software seria mais fácil de implementar do que seria de verdade e acabava gerando bastante desgaste. Também acabavasse recorrendo ao uso do protótipo como produto final, o que poderia implicar em diversos outros riscos e também poderiam passar muito tempo apenas desenvolvendo um protótipo que poderia ser descartado.
Quanto aos casos de uso, é uma técnica que acaba simplificando muito o software para mostrar um cenário de como seria as interações do usuário com o sistema. Mas como também não diz nada sobre a lógica que deve andar por trás do software, pode ser mal interpretado nas estimativas de prazos e esforço.
Agora que o sistema está melhor especificado, acabou-se, certo? Não, claro que não. É importante também se poder acompanhar com os stakeholders se o projeto está indo na direção correta, mais um ponto para metodologias ágeis de desenvolvimento, que acabam gerando mais versões que podem voltar a ser discutidas e revisadas...
Então muitas técnicas surgiram e atualmente as principais técnicas de análise de requisitos consistem em fazer entrevistas com os stakeholders para se melhorar todos os requisitos, procurando remover contradições, priorizar os requisitos, permitir que eles façam a escolha também do que pode ser feito com relação aos custos.
Em alguns casos, se for julgado necessário, é possível se fazer uma reunião com todos os interessados para se definir o escopo/custo geral, principalmente quando cada uma das partes deseja algo diferente e precisam entrar em um acordo.
A forma comum de se documentar isso é por meio de contrato. E mais do que a lista de funcionalidades que pode ser muito longa, se propõe uma lista de objetivos mensuráveis que deve ser alcançada com protótipos o quanto antes, para que estes objetivos maiores possam ser atingidos.
Outras duas técnicas muito conhecidas para ajudar a exemplificar e facilitar a visualisação deste software final são a prototipação e os casos de uso para ajudar na especificação dos requisitos.
O problema é que a prototipação acabava gerando uma certa ansiedade e sensação de que o software seria mais fácil de implementar do que seria de verdade e acabava gerando bastante desgaste. Também acabavasse recorrendo ao uso do protótipo como produto final, o que poderia implicar em diversos outros riscos e também poderiam passar muito tempo apenas desenvolvendo um protótipo que poderia ser descartado.
Quanto aos casos de uso, é uma técnica que acaba simplificando muito o software para mostrar um cenário de como seria as interações do usuário com o sistema. Mas como também não diz nada sobre a lógica que deve andar por trás do software, pode ser mal interpretado nas estimativas de prazos e esforço.
Agora que o sistema está melhor especificado, acabou-se, certo? Não, claro que não. É importante também se poder acompanhar com os stakeholders se o projeto está indo na direção correta, mais um ponto para metodologias ágeis de desenvolvimento, que acabam gerando mais versões que podem voltar a ser discutidas e revisadas...
sexta-feira, 5 de junho de 2009
Engenharia de Software
A ES é toda uma área do conhecimento da computação. A intenção é conseguir especificar, desenvolver e manter software com a melhor relação de custo e qualidade possível com todas as técnicas que temos disponíveis, se focando em aspectos práticos. Por isso ela engloba todas estas partes do software:
- Requisitos;
- Design;
- Implementação;
- Testes;
- Manutenção;
- Gerência de configuração;
- Gerência de engenharia;
- Processos de engenharia;
- Ferramentas e métodos de engenharia;
- Qualidade;
Para nos ajudar a entender tudo isso, vamos começar com a definição de ciclo de vida do produto (software). A idéia destes modelos é detalhar como deve ser o passo a passo do desenvolvimento do software até que se tenha o produto final.
No processo em Cascata temos um processo linear, na base de muitos processos de ciclo de vida ainda hoje. Completa-se a engenharia de requisitos para só depois fazer o design do software. E só depois deste é que se inicia a implementação e os testes. Depois se testa o sistema e finalmente se entra na etapa de manutenção do software. Costuma funcionar melhor para equipes tecnicamente mais fracas e minimiza o tempo de planejamento. Porém é mais inflexível e só produz um software realmente no final do processo.
O modelo em espiral tenta dar maior importância a duas partes deste ciclo: a análise de risco e a prototipagem. Procura-se definir e especificar partes menores, produzindo protótipos e cada iteração pode voltar a qualquer etapa (mais comum de se voltar ao desenvolvimento ou especificação) e gerar outro protótipo até que se chegue ao final do produto. E este acaba sendo um modelo complexo de se planejar e utilizar, mas pode-se diminuir muito o risco dos projetos. Uma variação parecida é a Prototipagem Evolucionária, que também faz ciclos de protótipos, mas não chega a fazer um planejamento geral porque se planeja apenas versões curtas, o que é muito útil quando os requisitos ainda não estão bem definidos, mas tem a desvantagem de que é impossível de prever quanto tempo ou quantas iterações serão necessárias até o final do projeto.
Entre outros modelos utilizados estão: Codificação e Correção, Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools e Off-the-Shelf.
Quanto as metodologias de desenvolvimento, também temos diversas delas para escolher. O RUP (Rational Unified Process) foi criado por uma empresa adquirida pela IBM e virou IRUP (IBM RUP). Eles fornecem técnicas de desenvolvimento de software visando o aumento de produtividade. Ele faz uso da Orientação a Objetos e da linguagem UML para definir e ilustrar os seus processos. Ele divide o processo em quatro fases essenciais:
Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.
É um modelo considerado pesado, mas que é muito útil com um grande número de pessoas na equipe, no caso de projetos muito grandes. Mas é suficientemente simples para que possamos trabalhar com ele em processos menores.
De qualquer forma, muitas metodologias surgiram exatamente por esta razão, com o nome de métodos ágeis. Eles procuravam uma forma de se conseguir um resultado semelhante sem gerar tantos documentos durante o processo e procuram minimizar o risco com curtos períodos de desenvolvimento. No início a "programação extrema" causou muito reboliço com suas idéias de programação em pares e projeto contínuo e hoje em dia sofre críticas mesmo daqueles que acreditam nas metodologias ágeis, como depender de desenvolvedores muito bem preparados, falta de estrutura e documentação, requerer uma mudança cultural muito grande, etc. Mais recentemente a metodologia ágil que mais ouço falar é a Scrum que procura percorrer todo o processo de desenvolvimento de software em "sprints" curtos, geralmente de 15-30 dias, gerando versões funcionais de software regularmente.
Basicamente, no Scrum se faz um planejamento geral que gera a lista completa de requisitos de software (o que é chamado de "product backlog"). Então se faz reuniões periódicas chamadas de "Sprint Planning Meetings" onde se acorda o escopo do próximo "sprint", montando o "sprint backlog". Diariamente durante o sprint, se faz uma reunião rápida para verificar se o andamento do sprint está comprometido (Daily Scrum). No final do sprint, se faz uma apresentação as "clientes" da versão, mostrando as funcionalidades implementadas e as anomalias que foram encontradas, para atualizarem o "product backlog" e se prepararem para o novo "sprint". Também deve ser realizada uma reunião de "Sprint Restrospective" para darem feedback sobre o processo e melhorarem o que for possível para o próximo "sprint". Devem, então, acontecer tantos "sprints" quanto forem necessários para que o produto seja dado como concluído.
Ultimamente tenho começado a acreditar que esta metodologia funciona muito bem com o tipo de estrutura que temos aqui na empresa que trabalho e estou estudando mais a respeito para utilizarmos o que for possível/benéfico.
- Requisitos;
- Design;
- Implementação;
- Testes;
- Manutenção;
- Gerência de configuração;
- Gerência de engenharia;
- Processos de engenharia;
- Ferramentas e métodos de engenharia;
- Qualidade;
Para nos ajudar a entender tudo isso, vamos começar com a definição de ciclo de vida do produto (software). A idéia destes modelos é detalhar como deve ser o passo a passo do desenvolvimento do software até que se tenha o produto final.
No processo em Cascata temos um processo linear, na base de muitos processos de ciclo de vida ainda hoje. Completa-se a engenharia de requisitos para só depois fazer o design do software. E só depois deste é que se inicia a implementação e os testes. Depois se testa o sistema e finalmente se entra na etapa de manutenção do software. Costuma funcionar melhor para equipes tecnicamente mais fracas e minimiza o tempo de planejamento. Porém é mais inflexível e só produz um software realmente no final do processo.
O modelo em espiral tenta dar maior importância a duas partes deste ciclo: a análise de risco e a prototipagem. Procura-se definir e especificar partes menores, produzindo protótipos e cada iteração pode voltar a qualquer etapa (mais comum de se voltar ao desenvolvimento ou especificação) e gerar outro protótipo até que se chegue ao final do produto. E este acaba sendo um modelo complexo de se planejar e utilizar, mas pode-se diminuir muito o risco dos projetos. Uma variação parecida é a Prototipagem Evolucionária, que também faz ciclos de protótipos, mas não chega a fazer um planejamento geral porque se planeja apenas versões curtas, o que é muito útil quando os requisitos ainda não estão bem definidos, mas tem a desvantagem de que é impossível de prever quanto tempo ou quantas iterações serão necessárias até o final do projeto.
Entre outros modelos utilizados estão: Codificação e Correção, Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools e Off-the-Shelf.
Quanto as metodologias de desenvolvimento, também temos diversas delas para escolher. O RUP (Rational Unified Process) foi criado por uma empresa adquirida pela IBM e virou IRUP (IBM RUP). Eles fornecem técnicas de desenvolvimento de software visando o aumento de produtividade. Ele faz uso da Orientação a Objetos e da linguagem UML para definir e ilustrar os seus processos. Ele divide o processo em quatro fases essenciais:
Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.
É um modelo considerado pesado, mas que é muito útil com um grande número de pessoas na equipe, no caso de projetos muito grandes. Mas é suficientemente simples para que possamos trabalhar com ele em processos menores.
De qualquer forma, muitas metodologias surgiram exatamente por esta razão, com o nome de métodos ágeis. Eles procuravam uma forma de se conseguir um resultado semelhante sem gerar tantos documentos durante o processo e procuram minimizar o risco com curtos períodos de desenvolvimento. No início a "programação extrema" causou muito reboliço com suas idéias de programação em pares e projeto contínuo e hoje em dia sofre críticas mesmo daqueles que acreditam nas metodologias ágeis, como depender de desenvolvedores muito bem preparados, falta de estrutura e documentação, requerer uma mudança cultural muito grande, etc. Mais recentemente a metodologia ágil que mais ouço falar é a Scrum que procura percorrer todo o processo de desenvolvimento de software em "sprints" curtos, geralmente de 15-30 dias, gerando versões funcionais de software regularmente.
Basicamente, no Scrum se faz um planejamento geral que gera a lista completa de requisitos de software (o que é chamado de "product backlog"). Então se faz reuniões periódicas chamadas de "Sprint Planning Meetings" onde se acorda o escopo do próximo "sprint", montando o "sprint backlog". Diariamente durante o sprint, se faz uma reunião rápida para verificar se o andamento do sprint está comprometido (Daily Scrum). No final do sprint, se faz uma apresentação as "clientes" da versão, mostrando as funcionalidades implementadas e as anomalias que foram encontradas, para atualizarem o "product backlog" e se prepararem para o novo "sprint". Também deve ser realizada uma reunião de "Sprint Restrospective" para darem feedback sobre o processo e melhorarem o que for possível para o próximo "sprint". Devem, então, acontecer tantos "sprints" quanto forem necessários para que o produto seja dado como concluído.
Ultimamente tenho começado a acreditar que esta metodologia funciona muito bem com o tipo de estrutura que temos aqui na empresa que trabalho e estou estudando mais a respeito para utilizarmos o que for possível/benéfico.
quarta-feira, 3 de junho de 2009
Redes de Computadores
Quando dois ou mais computadores trocam serviços, se tem uma rede de computadores. Pode ser impressoras, dados, mensagens (de texto instantâneas ou emails), etc. A internet já é uma rede com muitos serviços disponíveis e por isso, é tão útil nos dias de hoje. A idéia deste post é comentar algumas destas teorias de redes.
Topologias
A topologia da rede define por onde esta troca de informações acontece e por isso, vou descrever um pouco destas topologias para podermos compreender melhor como estas redes funcionam.
Uma topologia em barramento é quando todos os computadores estão ligados ao mesmo barramento, que já não é muito utilizada nos dias de hoje, já que era feita com cabos coaxiais, ligando um computador ao outro com um único cabo e utilizando o "T" para fazer a extensão para o próximo computador. E as redes em árvore são essencialmente uma série de redes de barramento, fazendo uma máquina conversar com outras duas.
Quando os computadores estão ligados em anel, um computador só conversa com o seu vizinho diretamente. Então quando ele quer falar com outra máquina ele envia a mensagem e o vizinho passa para o próximo até que ou a mensagem chegue ao seu destino ou retorne ao computador que a enviou (que então tira a mensagem do círculo).
As topologias em estrela, hoje em dia, são as mais comuns. Tem um centralizador da rede (hub, switch) e todos os computadores da rede ligados a ele, funcionando para pequenas redes, já que estes centralizadores raramente possuem muitas portas. Mesmo assim, é um dos tipos mais comuns de redes atualmente.
Por fim, a topologia híbrida que é também muito utilizada hoje em dia. Cada ambiente seleciona a rede que é mais adequada para ele e conversa com outras redes de topologias diferentes.
Ligação ao Meio
Além das topologias, ainda há mais uma forma de se classificar estas ligações.
Ponto a ponto é uma forma de ligar dois equipamentos. Serve para as topologias de anel (ligando um computador ao outro), estrela (ligando um computador ao centralizador) e é bem mais simples de implementar porque não possui os problemas de múltiplas reflexões nem de transmissões simultâneas.
No caso da ligação multiponto, há algumas precauções que deve-se tomar com reflexões e ter a certeza de qual computador está tentando falar com ele. Pode-se utilizar este tipo de ligação em qualquer uma das topologias.
Meios de Transmissão
Agora vamos falar dos cabos e outros meios onde esta informação pode trafegar. É parte vital da montagem de uma boa rede a definição de qual meio de transmissão será utilizado.
O cabo de par trançado foi criado para se tentar diminuir o ruído e manter as propriedades elétricas do meio. Ele tem esse nome porque é composto por dois pares de cabos de cobre trançados um no outro. Em baixas frequências ele apresenta uma boa resistência a ruídos, porém em altas frequências o cabo coaxial é melhor.
Como acabamos de dizer, o cabo coaxial é mais resistente a ruídos, independentemente do tamanho do cabo, mas é mais caro. Ele é feito com dois condutores, um interno e um externo, separados por um dielétrico e possuindo uma camada isolante circundando o condutor externo.
Já as fibras óticas, ainda mais caras, são imunes a ruídos eletromagnéticos e permitem um isolamento completo entre o transmissor e o receptor. Sua transmissão é realizada por um sinal de luz codificado que trafega dentro do domínio de frequência infravermelho.
Fora isso temos os meios de transmissão wireless. Ou que não precisam de cabos. Ondas de rádio são utilizadas para longo alcance, mas podem ser bloqueadas por obstáculos físicos nestas frequências, ou em frequências mais baixas podem atravessar paredes, mas não ficam com um alcance muito grande. De qualquer forma, para o curto alcance, geralmente se utiliza as ondas milimétricas ou infravermelhas (utilizadas em controles remotos, por exemplo). Neste caso elas não atravessam objetos sólidos, o que é uma vantagem para este tipo de equipamento. E por fim, temos a transmissão por microondas, que foi muito utilizada para transmissões de longo alcance antes da fibra ótica e ainda hoje em tecnologias de celulares, possuem a desvantagem de precisar de muitos repetidores.
Transmissão e Banda Passante
Agora podemos conversar sobre como a transmissão dos dados será realizada. A origem primeiro gera a informação, depois monta uma tabela de símbolos e monta um pacote com os dados que será transmitido. Depois é feita a transmissão deste pacote da origem ao destino seguindo a topologia certa e no destino se faz a decodificação desta informação e se recria a informação. Para determinar a banda passante de uma rede é necessário saber com que frequência o sinal pode ocilar da origem até o destino, pelo ruído que pode ser gerado no canal, pela atenuação e pelos ecos. Em um meio sem ruído, o máximo que pode ser transmitido de dados com uma frequência de "X" Hz é 2 "X", porque você pode mandar um bit na subida e outro na decida da oscilação do sinal. Por isso, duas fórmulas bastante comuns na ausência de ruído:
C = 2 W baunds.
Se não forem apenas dois níveis de tensão (alto e baixo) transmitidos, na verdade a fórmula passa a poder transportar log2(L) bits, onde L é a quantidade de níveis de tensão, transformando a fórmula em:
C = 2 W log2(L) bps (se L = 2, log2(2) = 1 e ficamos exatamente com a fórmula anterior).
Para aqueles que não se lembram, uma regrinha fácil para o cálculo do logarítimo é com 2 elevado a "X" é igual a L. Quanto é "X"? Além disso os sinais vão sofrendo atenuação com a distância da origem (a fibra ótica permite uma atenuação menor que 1dB por km), por isso há um limite de uso diferente para cada tipo de cabeamento/meio de trasmissão e o ruído é geralmente medido em decibéis. Se quisermos levar em consideração o sinal sobre o ruído, podemos dividir a fórmula acima por:
C = ( 2 W log2(L) ) / (1 + S/R) (onde S = Sinal e R = Ruído, ambos em potência ou decibéis)
Assim é possível se determinar com mais precisão a banda passante máxima.
Protocolos de Rede
O modelo ISO/OSI é um bom modelo de arquitetura de redes que deve ser seguido nos projetos de protocolos de redes, com o objetivo de permitir a troca de informações entre computadores de fabricantes distintos. Para reduzir a complexidade, o modelo dividiu a arquitetura em camadas, sendo que há uma hierarquia entre elas. Cada camada fornece serviços para a camada superior e usa serviços da camada inferior. São elas:
- Aplicação -
Aplicação (fornecer aos processos de uma aplicação os meios para utilizar os meios de comunicação disponiveis)
Apresentação (realizar as conversões necessárias para que a comunicação seja realizada)
Sessão (estruturar os circuitos fornecidos pela camada de transporte para fazer o controle do token ou do diálogo - ver que estão se entendendo ou voltar até o último ponto de onde iniciaram)
Transporte (definir um meio confiável fim-a-fim de transmissão, garantir que os pacotes sejam interpretados na ordem correta e que cheguem do outro lado corretamente)
Rede (trata dos problemas de roteamento e chaveamento de pacotes)
Enlace (transforma um meio de comunicação não confiável em confiável, colocando a informação em quadros com redundância para detecção de erros, por exemplo)
Físico (define como representar os bits no meio físico, se a comunicação será half-duplex ou duplex, como a conexão será estabelecida e desfeita)
- meio físico -
Já a arquitetura TCP/IP é muito semelhante a esta, mas possui menos camadas definidas.
- Aplicação -
Aplicação (soma das camadas de sessão, apresentação e aplicação, tem como exemplos: http, dns, ftp, telnet)
Transporte (exemplos: TCP e UDP)
Rede (exemplos: IP)
Intra-Rede (corresponde as camadas físico e enlace, com exemplos: ethernet, slip, PPP)
- meio físico -
Montando a Rede
Agora que temos todo estes conhecimentos sobre redes podemos determinar qual a rede que precisamos para nossa aplicação. Podendo escolher como será feita a ligação dos computadores, quais protocolos utilizar, determinar a banda que será conquistada com a rede. Mais do que isso, talvez se quiser saber o quanto divide a banda ao se utilizar hubs ou switches, mas isto poderá ser matéria de um outro post...
Topologias
A topologia da rede define por onde esta troca de informações acontece e por isso, vou descrever um pouco destas topologias para podermos compreender melhor como estas redes funcionam.
Uma topologia em barramento é quando todos os computadores estão ligados ao mesmo barramento, que já não é muito utilizada nos dias de hoje, já que era feita com cabos coaxiais, ligando um computador ao outro com um único cabo e utilizando o "T" para fazer a extensão para o próximo computador. E as redes em árvore são essencialmente uma série de redes de barramento, fazendo uma máquina conversar com outras duas.
Quando os computadores estão ligados em anel, um computador só conversa com o seu vizinho diretamente. Então quando ele quer falar com outra máquina ele envia a mensagem e o vizinho passa para o próximo até que ou a mensagem chegue ao seu destino ou retorne ao computador que a enviou (que então tira a mensagem do círculo).
As topologias em estrela, hoje em dia, são as mais comuns. Tem um centralizador da rede (hub, switch) e todos os computadores da rede ligados a ele, funcionando para pequenas redes, já que estes centralizadores raramente possuem muitas portas. Mesmo assim, é um dos tipos mais comuns de redes atualmente.
Por fim, a topologia híbrida que é também muito utilizada hoje em dia. Cada ambiente seleciona a rede que é mais adequada para ele e conversa com outras redes de topologias diferentes.
Ligação ao Meio
Além das topologias, ainda há mais uma forma de se classificar estas ligações.
Ponto a ponto é uma forma de ligar dois equipamentos. Serve para as topologias de anel (ligando um computador ao outro), estrela (ligando um computador ao centralizador) e é bem mais simples de implementar porque não possui os problemas de múltiplas reflexões nem de transmissões simultâneas.
No caso da ligação multiponto, há algumas precauções que deve-se tomar com reflexões e ter a certeza de qual computador está tentando falar com ele. Pode-se utilizar este tipo de ligação em qualquer uma das topologias.
Meios de Transmissão
Agora vamos falar dos cabos e outros meios onde esta informação pode trafegar. É parte vital da montagem de uma boa rede a definição de qual meio de transmissão será utilizado.
O cabo de par trançado foi criado para se tentar diminuir o ruído e manter as propriedades elétricas do meio. Ele tem esse nome porque é composto por dois pares de cabos de cobre trançados um no outro. Em baixas frequências ele apresenta uma boa resistência a ruídos, porém em altas frequências o cabo coaxial é melhor.
Como acabamos de dizer, o cabo coaxial é mais resistente a ruídos, independentemente do tamanho do cabo, mas é mais caro. Ele é feito com dois condutores, um interno e um externo, separados por um dielétrico e possuindo uma camada isolante circundando o condutor externo.
Já as fibras óticas, ainda mais caras, são imunes a ruídos eletromagnéticos e permitem um isolamento completo entre o transmissor e o receptor. Sua transmissão é realizada por um sinal de luz codificado que trafega dentro do domínio de frequência infravermelho.
Fora isso temos os meios de transmissão wireless. Ou que não precisam de cabos. Ondas de rádio são utilizadas para longo alcance, mas podem ser bloqueadas por obstáculos físicos nestas frequências, ou em frequências mais baixas podem atravessar paredes, mas não ficam com um alcance muito grande. De qualquer forma, para o curto alcance, geralmente se utiliza as ondas milimétricas ou infravermelhas (utilizadas em controles remotos, por exemplo). Neste caso elas não atravessam objetos sólidos, o que é uma vantagem para este tipo de equipamento. E por fim, temos a transmissão por microondas, que foi muito utilizada para transmissões de longo alcance antes da fibra ótica e ainda hoje em tecnologias de celulares, possuem a desvantagem de precisar de muitos repetidores.
Transmissão e Banda Passante
Agora podemos conversar sobre como a transmissão dos dados será realizada. A origem primeiro gera a informação, depois monta uma tabela de símbolos e monta um pacote com os dados que será transmitido. Depois é feita a transmissão deste pacote da origem ao destino seguindo a topologia certa e no destino se faz a decodificação desta informação e se recria a informação. Para determinar a banda passante de uma rede é necessário saber com que frequência o sinal pode ocilar da origem até o destino, pelo ruído que pode ser gerado no canal, pela atenuação e pelos ecos. Em um meio sem ruído, o máximo que pode ser transmitido de dados com uma frequência de "X" Hz é 2 "X", porque você pode mandar um bit na subida e outro na decida da oscilação do sinal. Por isso, duas fórmulas bastante comuns na ausência de ruído:
C = 2 W baunds.
Se não forem apenas dois níveis de tensão (alto e baixo) transmitidos, na verdade a fórmula passa a poder transportar log2(L) bits, onde L é a quantidade de níveis de tensão, transformando a fórmula em:
C = 2 W log2(L) bps (se L = 2, log2(2) = 1 e ficamos exatamente com a fórmula anterior).
Para aqueles que não se lembram, uma regrinha fácil para o cálculo do logarítimo é com 2 elevado a "X" é igual a L. Quanto é "X"? Além disso os sinais vão sofrendo atenuação com a distância da origem (a fibra ótica permite uma atenuação menor que 1dB por km), por isso há um limite de uso diferente para cada tipo de cabeamento/meio de trasmissão e o ruído é geralmente medido em decibéis. Se quisermos levar em consideração o sinal sobre o ruído, podemos dividir a fórmula acima por:
C = ( 2 W log2(L) ) / (1 + S/R) (onde S = Sinal e R = Ruído, ambos em potência ou decibéis)
Assim é possível se determinar com mais precisão a banda passante máxima.
Protocolos de Rede
O modelo ISO/OSI é um bom modelo de arquitetura de redes que deve ser seguido nos projetos de protocolos de redes, com o objetivo de permitir a troca de informações entre computadores de fabricantes distintos. Para reduzir a complexidade, o modelo dividiu a arquitetura em camadas, sendo que há uma hierarquia entre elas. Cada camada fornece serviços para a camada superior e usa serviços da camada inferior. São elas:
- Aplicação -
Aplicação (fornecer aos processos de uma aplicação os meios para utilizar os meios de comunicação disponiveis)
Apresentação (realizar as conversões necessárias para que a comunicação seja realizada)
Sessão (estruturar os circuitos fornecidos pela camada de transporte para fazer o controle do token ou do diálogo - ver que estão se entendendo ou voltar até o último ponto de onde iniciaram)
Transporte (definir um meio confiável fim-a-fim de transmissão, garantir que os pacotes sejam interpretados na ordem correta e que cheguem do outro lado corretamente)
Rede (trata dos problemas de roteamento e chaveamento de pacotes)
Enlace (transforma um meio de comunicação não confiável em confiável, colocando a informação em quadros com redundância para detecção de erros, por exemplo)
Físico (define como representar os bits no meio físico, se a comunicação será half-duplex ou duplex, como a conexão será estabelecida e desfeita)
- meio físico -
Já a arquitetura TCP/IP é muito semelhante a esta, mas possui menos camadas definidas.
- Aplicação -
Aplicação (soma das camadas de sessão, apresentação e aplicação, tem como exemplos: http, dns, ftp, telnet)
Transporte (exemplos: TCP e UDP)
Rede (exemplos: IP)
Intra-Rede (corresponde as camadas físico e enlace, com exemplos: ethernet, slip, PPP)
- meio físico -
Montando a Rede
Agora que temos todo estes conhecimentos sobre redes podemos determinar qual a rede que precisamos para nossa aplicação. Podendo escolher como será feita a ligação dos computadores, quais protocolos utilizar, determinar a banda que será conquistada com a rede. Mais do que isso, talvez se quiser saber o quanto divide a banda ao se utilizar hubs ou switches, mas isto poderá ser matéria de um outro post...
terça-feira, 2 de junho de 2009
Comunicação de Dados
As teorias filosóficas a respeito da comunicação em geral avançaram muito desde a primeira, que dizia que tudo o que se precisava era um emissor (o falante) e um receptor (o ouvinte). Porque se entendeu que nem sempre o que é dito ao ouvinte é compreendido, aceito ou entendido.
Os componentes da comunicação são: o emissor, o receptor, a mensagem, o canal de propagação, o meio de comunicação, a resposta (feedback) e o ambiente onde o processo comunicativo se realiza. No caso das redes de computadores, também temos todas estas variáveis. Mas nem todas elas são tão importantes assim para os computadores.
Para facilitar esta comunicação foram criados diversos protocolos diferentes (TCP e UDP, por exemplo). Eles cuidavam do que deveria ter a mensagem e a resposta para que houvesse comunicação.
O meio, o canal e o ambiente de comunicação também variam bastante. Do cabo coaxial até a fibra ótica existem diversas opções de onde trafegarão os dados. Inclusive rede elétrica nos dias de hoje. Podemos trocar informações através de cabos seriais ou seguindo o padrão ethernet. São inúmeras opções.
Mas no caso dos computadores, algumas teorias adicionais básicas foram criadas para simplificar e possibilitar a comunicação. Foram criadas regras básicas para os protocolos/meios serem comunicações de dados aceitáveis.
Temos três fatores básicos para que uma comunicação de dados seja eficiente: entrega (quem fala consegue falar com todos e apenas os que deseja falar), confiabilidade (precisa chegar do outro lado) e o tempo de atraso tem que ser aceitável e pré-definido.
Além disso, temos uma variável importante que precisava ser levada em consideração: o sentido da comunicação e o tipo de conexão.
No sentido, se definiu a comunicação simplex (só um fala e o outro escuta), duplex (um fala e o outro escuta, mas podem revesar quem fala ou escuta) e a full duplex (ambos podem falar e escutar ao mesmo tempo).
Já no tipo de conexão, temos comunicações ponto a ponto (de uma máquina a outra apenas, com um cabo direto, por exemplo) e multi-ponto (onde as máquinas compartilham um único link).
Os componentes da comunicação são: o emissor, o receptor, a mensagem, o canal de propagação, o meio de comunicação, a resposta (feedback) e o ambiente onde o processo comunicativo se realiza. No caso das redes de computadores, também temos todas estas variáveis. Mas nem todas elas são tão importantes assim para os computadores.
Para facilitar esta comunicação foram criados diversos protocolos diferentes (TCP e UDP, por exemplo). Eles cuidavam do que deveria ter a mensagem e a resposta para que houvesse comunicação.
O meio, o canal e o ambiente de comunicação também variam bastante. Do cabo coaxial até a fibra ótica existem diversas opções de onde trafegarão os dados. Inclusive rede elétrica nos dias de hoje. Podemos trocar informações através de cabos seriais ou seguindo o padrão ethernet. São inúmeras opções.
Mas no caso dos computadores, algumas teorias adicionais básicas foram criadas para simplificar e possibilitar a comunicação. Foram criadas regras básicas para os protocolos/meios serem comunicações de dados aceitáveis.
Temos três fatores básicos para que uma comunicação de dados seja eficiente: entrega (quem fala consegue falar com todos e apenas os que deseja falar), confiabilidade (precisa chegar do outro lado) e o tempo de atraso tem que ser aceitável e pré-definido.
Além disso, temos uma variável importante que precisava ser levada em consideração: o sentido da comunicação e o tipo de conexão.
No sentido, se definiu a comunicação simplex (só um fala e o outro escuta), duplex (um fala e o outro escuta, mas podem revesar quem fala ou escuta) e a full duplex (ambos podem falar e escutar ao mesmo tempo).
Já no tipo de conexão, temos comunicações ponto a ponto (de uma máquina a outra apenas, com um cabo direto, por exemplo) e multi-ponto (onde as máquinas compartilham um único link).
segunda-feira, 1 de junho de 2009
Gerenciamento de Projetos
A sigla que vou falar desta vez é PMI (Project Management Institute). Eles criaram um excelente manual sobre gerenciamento de projetos e a primeira coisa que eles fazem é exatamente definir o que são os projetos. Projetos são temporários, envolvem o desenvolvimento de algo único e realizado em etapas.
Hoje em dia, muitas empresas trabalham desta forma, considerando cada produto novo é um projeto. Seja um prédio, um remédio, um celular, uma televisão, um computador, um software, praticamente qualquer coisa. E durante o desenvolvimento, há uma concorrência de prioridades que variam entre: escopo, tempo, risco e qualidade. Além de uma possibilidade de expectativas e necessidades diferentes para todos que esperam o desenvolvimento de determinado projeto. Por isso, o gerenciamento de projetos é uma atividade que tem o dever de analisar os requisitos e trabalhar com as demandas, expectativas e necessidades dos clientes daquele projeto.
Para ajudar nesta tarefa, o PMBOK dividiu os conhecimentos necessários para uma boa gestão de projetos em nove áreas diferentes. São elas:
1-) Integração (desenvolvimento, execução e controle do planejamento do projeto como um todo);
2-) Escopo (iniciação, planejamento, detalhamento e verificação de escopo, além de controle de mudanças nele);
3-) Tempo (definição, sequenciamento e estimativa de duração das atividades além de desenvolvimento e controle do cronograma);
4-) Custo (planejamento dos recursos e estimativa, orçamento e controle de custos);
5-) Qualidade (planejamento, controle e garantia da qualidade);
6-) Recursos Humanos (planejamento organizacional, montagem e desenvolvimento da equipe);
7-) Comunicações (planejamento das comunicações, distribuição das informações, relato de desempenho e encerramento administrativo);
8-) Riscos (planejamento e identificação dos riscos, análise qualitativa e quantitativa dos riscos, desenvolvimento de respostas, controle e monitoração dos riscos);
9-) Aquisições (planejamento e preparação das aquisições, obtenção de propostas e seleção de fornecedores, administração e encerramento de contratos);
Eu devo escrever com mais detalhes de cada uma destas áreas no futuro próximo. Já que como eu disse, atualmente estou estudando muito processos para mudarmos os processos de desenvolvimento de software e a gestão de projetos tem muita relação com isso.
Hoje em dia, muitas empresas trabalham desta forma, considerando cada produto novo é um projeto. Seja um prédio, um remédio, um celular, uma televisão, um computador, um software, praticamente qualquer coisa. E durante o desenvolvimento, há uma concorrência de prioridades que variam entre: escopo, tempo, risco e qualidade. Além de uma possibilidade de expectativas e necessidades diferentes para todos que esperam o desenvolvimento de determinado projeto. Por isso, o gerenciamento de projetos é uma atividade que tem o dever de analisar os requisitos e trabalhar com as demandas, expectativas e necessidades dos clientes daquele projeto.
Para ajudar nesta tarefa, o PMBOK dividiu os conhecimentos necessários para uma boa gestão de projetos em nove áreas diferentes. São elas:
1-) Integração (desenvolvimento, execução e controle do planejamento do projeto como um todo);
2-) Escopo (iniciação, planejamento, detalhamento e verificação de escopo, além de controle de mudanças nele);
3-) Tempo (definição, sequenciamento e estimativa de duração das atividades além de desenvolvimento e controle do cronograma);
4-) Custo (planejamento dos recursos e estimativa, orçamento e controle de custos);
5-) Qualidade (planejamento, controle e garantia da qualidade);
6-) Recursos Humanos (planejamento organizacional, montagem e desenvolvimento da equipe);
7-) Comunicações (planejamento das comunicações, distribuição das informações, relato de desempenho e encerramento administrativo);
8-) Riscos (planejamento e identificação dos riscos, análise qualitativa e quantitativa dos riscos, desenvolvimento de respostas, controle e monitoração dos riscos);
9-) Aquisições (planejamento e preparação das aquisições, obtenção de propostas e seleção de fornecedores, administração e encerramento de contratos);
Eu devo escrever com mais detalhes de cada uma destas áreas no futuro próximo. Já que como eu disse, atualmente estou estudando muito processos para mudarmos os processos de desenvolvimento de software e a gestão de projetos tem muita relação com isso.
domingo, 31 de maio de 2009
Governança de TI
Quais são as melhores práticas nos dias de hoje? Acredito que sejam as três siglas que devo comentar hoje: COBIT, ITIL e BSC.
O BSC não é algo específico de TI, mas o Balance Scorecard já é utilizado por muitas empresas brasileiras. Ele ajuda a montar um plano estratégico (em quatro áreas - financeira, clientes, processos internos e aprendizado/crescimento) e de como acompanhar isto, com uma ferramenta bem prática conhecida como mapa estratégico. Com a criação do mapa é possível se visualizar pelo que da estratégia geral cada funcionário é responsável e o principal é que deve-se criar indicadores para cada um destes objetivos e acompanhar a evolução de cada meta com base nestes indicadores selecionados.
O termo de indicadores balanceados é exatamente porque lança mão de outros indicadores que não apenas os financeiros. Portanto, nada impede de se criar objetivos estratégicos no mapa que correspondam a TI. Inclusive, considero isso muito recomendável. E para ajudar com estas metas, objetivos e indicadores de TI existem outras soluções complementares.
ITIL, a primeira outra solução que vou comentar, é a biblioteca ("IT Infrastructure Library" com 7 livros) para se fazer a gestão de serviços desta área. Ela possui um conjunto bastante abrangente de processos e procedimentos para se selecionar e investir nos que trouxerem maior benefício para o negócio. Para dar um exemplo, um dos livros é o "Service Delivery", que versa sobre gerenciamento do nível de serviços, gerenciamento financeiro para TI, gerenciamento da disponibilidade e capacidade adequada dos serviços.
Já o COBIT (Control Objectives for Information and Related Technology), a segunda e última outra solução que vou descrever um pouco, é uma ferramenta para gestão de TI mesmo, dividido em quatro domínios: Planejamento e Organização, Aquisição e Implementação, Entrega e Suporte e por fim Monitoração. Com estas práticas, se consegue diversos indicadores úteis para a gestão. Com a versão 4.0 lançada em dezembro de 2005 o COBIT virou uma coleção de 34 processos bastante modernos e integrados ao ITIL e ao BSC. Com gerenciamento de projetos, de riscos, de mudanças, etc. E quanto maior o número de processos que a empresa seguir, mais controlado é o ambiente. Pena que como qualquer grande mudança, não é trivial se adotar estes processos. É necessário comparar os processos da empresa com os do COBIT, analisar a maturidade deles e ir fazendo progressos até que esta adaptação esteja concluída, porque ele dá o diagnóstico do que deve ser feito, mas não o como deve ser feito (por isso ele combina tanto com o ITIL que ajuda neste como).
O BSC não é algo específico de TI, mas o Balance Scorecard já é utilizado por muitas empresas brasileiras. Ele ajuda a montar um plano estratégico (em quatro áreas - financeira, clientes, processos internos e aprendizado/crescimento) e de como acompanhar isto, com uma ferramenta bem prática conhecida como mapa estratégico. Com a criação do mapa é possível se visualizar pelo que da estratégia geral cada funcionário é responsável e o principal é que deve-se criar indicadores para cada um destes objetivos e acompanhar a evolução de cada meta com base nestes indicadores selecionados.
O termo de indicadores balanceados é exatamente porque lança mão de outros indicadores que não apenas os financeiros. Portanto, nada impede de se criar objetivos estratégicos no mapa que correspondam a TI. Inclusive, considero isso muito recomendável. E para ajudar com estas metas, objetivos e indicadores de TI existem outras soluções complementares.
ITIL, a primeira outra solução que vou comentar, é a biblioteca ("IT Infrastructure Library" com 7 livros) para se fazer a gestão de serviços desta área. Ela possui um conjunto bastante abrangente de processos e procedimentos para se selecionar e investir nos que trouxerem maior benefício para o negócio. Para dar um exemplo, um dos livros é o "Service Delivery", que versa sobre gerenciamento do nível de serviços, gerenciamento financeiro para TI, gerenciamento da disponibilidade e capacidade adequada dos serviços.
Já o COBIT (Control Objectives for Information and Related Technology), a segunda e última outra solução que vou descrever um pouco, é uma ferramenta para gestão de TI mesmo, dividido em quatro domínios: Planejamento e Organização, Aquisição e Implementação, Entrega e Suporte e por fim Monitoração. Com estas práticas, se consegue diversos indicadores úteis para a gestão. Com a versão 4.0 lançada em dezembro de 2005 o COBIT virou uma coleção de 34 processos bastante modernos e integrados ao ITIL e ao BSC. Com gerenciamento de projetos, de riscos, de mudanças, etc. E quanto maior o número de processos que a empresa seguir, mais controlado é o ambiente. Pena que como qualquer grande mudança, não é trivial se adotar estes processos. É necessário comparar os processos da empresa com os do COBIT, analisar a maturidade deles e ir fazendo progressos até que esta adaptação esteja concluída, porque ele dá o diagnóstico do que deve ser feito, mas não o como deve ser feito (por isso ele combina tanto com o ITIL que ajuda neste como).
sábado, 30 de maio de 2009
Processos de Desenvolvimento de Software
Graças a uma norma da comunidade européia de desenvolvimento de software para equipamentos médicos (ANSI/AAMI/IEC 62304:2006) estamos revendo o processo de desenvolvimento de software na empresa que eu trabalho atualmente (Dixtal Biomédica).
Esta norma define um processo de desenvolvimento de software muito bem, inclusive teremos que levantar algumas evidências a mais do que fazemos atualmente pelo que estudei da norma. Com as etapas passando por planejamento, depois análise de requisitos, design de arquitetura, design detalhado, implementação, integração e verificações, validação do sistema e liberação. Todas estas etapas, necessariamente nesta ordem.
Mas a minha intenção ao escrever era de comparar este processo com outros padrões bem estabelecidos de desenvolvimento de software que existem por ai, como o CMMI e o MPS-BR. O CMMI tem níveis de maturidade que variam do nível 1 (menos maduro) até o 5 (mais maduro). Estes estágios ficam bem diferenciados assim:
- Realização – Estágio inicial;
- Gerenciado – Gerenciamento de requisitos, planejamento de projeto, monitoramento e controle de projeto, gerenciamento de fornecedores, medição e análise, garantia da qualidade do processo e do produto, gerenciamento de configuração;
- Definido – Desenvolvimento de requisitos, solução técnica, integração do produto, verificação e validação, foco no processo organizacional, definição do processo organizacional, treinamento organizacional, gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução;
- Quantitativamente – Gerenciamento quantitativo do projeto, performance do processo organizacional;
- Otimização – Análise causal e resolução, inovação organizacional e implantação.
Comparando estes níveis de maturidade com o nível mínimo de processo que a norma IEC 62304 exige, acredito que sairemos no fim deste ano com uma equivalência de processos muito próxima ao que é exigido no nível 3, porque não fazemos uso de métricas detalhadas e a parte quantitativa é um pouco pior que o exigido neste nível de maturidade realmente. Também acredito que o nível 5 de otimização não é algo tão distante do que o que procuramos fazer aqui. Mas como não fazemos isso com a quantidade de evidências e mensurações necessárias para o CMMI, mesmo que pudesse atingir o nível 5 pulando o nível 4 (não pode fazer isso, você só pode alcançar um nível de maturidade maior se tiver os anteriores) não atingiríamos este estado de processos em melhoria contínua.
Mas não estou dizendo que se pagarmos o preço, qualquer auditoria já nos promoveria automaticamente. Provavelmente há algum rigor extra em alguns dos quesitos que acredito que cumprimos, como o fato de a empresa que trabalho não ter uma equipe dedicada a testes. Mesmo assim, acabamos fazendo validação com equipes trocadas que acaba ajudando a cumprir esta parte da norma também, de que quem desenvolve o produto não pode atestar que está funcionando.
Para não ficarmos só com o utópico, porque não vejo muitas necessidades de a Dixtal pagar para ter uma certificação destas atualmente, resolvi também comparar com o MPS-BR. Que foi criado exatamente por isso. Algumas empresas brasileiras precisavam exigir um nível mínimo de qualidade (é pra isso que serve ser atestado como um nível de maturidade de desenvolvimento maior no CMMI) e para empresas menores este custo de implantar o CMMI era bastante proibitivo. A última vez que conferi os valores, ele circulava na faixa de R$ 300 mil a R$ 400 mil por ter que importar auditores. Então o modelo brasileiro, com certificação emitida por auditorias nacionais acaba tendo um preço mais acessível e foi definido de forma muito parecida que o primo rico. Mas ele conta com 7 níveis de maturidade e os níveis são decrescentes no lugar de crescentes. Vai do nível G (pior) para o nível A (melhor). Então se precisarmos criar um outro nível depois do estado de otimização contínua, acho que vamos ter que deslocar os rankings de todas as empresas... De qualquer forma, eles significam:
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.
Neste processo eu confesso que tive um pouco de dificuldades de fazer a conversão do nível de maturidade que imagino para a Dixtal. Se no CMMI eu a considerei com processos definidos, tenho praticamente 3 níves (de E até C) que são mais ou menos a mesma correspondência. Precisei recorrer a um nível de detalhamento maior dos níveis de maturidade.
Nível G - Parcialmente Gerenciado
Processo: Gerência do Projeto - GPR
Processo: Gerência de Requisitos - GRE Nível
F – Gerenciado
Processo: Aquisição - AQU
Processo: Gerência de Configuração - GCO
Processo: Garantia da Qualidade - GQA
Processo: Medição - MED
Nivel E - Parcialmente Definido
Processo: Adaptação do Processo para Gerência do Projeto - APG
Processo: Avaliação e Melhoria do Processo Organizacional - AMP
Processo: Definição do Processo Organizacional - DFP
Processo: Treinamento - TRE
Nível D - Largamente Definido
Processo: Desenvolvimento de Requisitos - DRE
Processo: Integração do Produto - ITP
Processo: Solução Técnica - STE
Processo: Validação - VAL
Processo: Verificação - VER
Nível C – Definido
Processo: Análise de Decisão e Resolução - ADR
Processo: Gerência de Riscos - GRI
Nível B - Gerenciado Quantitativamente
Processo: Desempenho do Processo Organizacional - DEP
Processo: Gerência Quantitativa do Projeto - GQP
Nível A - Em Otimização
Processo: Implantação de Inovações na Organização - IIO
Processo: Análise de Causas e Resolução- ARC
Neste caso, acho que fico com o nível G! Brincadeira. É que a gerência de Requisitos é uma das coisas que estamos melhorando muito agora e é um pré-requisito para se começar a brincar nos níveis de maturidade do MPS-BR. Mas voltando a diferenciação dos três níveis de maturidade que eu queria separar, acredito que já chegaremos ao "nível C - Definido" até o fim do ano, realmente. É muito complicado um setor de equipamentos hospitalares não cuidar da Gestão de Risco...
Esta norma define um processo de desenvolvimento de software muito bem, inclusive teremos que levantar algumas evidências a mais do que fazemos atualmente pelo que estudei da norma. Com as etapas passando por planejamento, depois análise de requisitos, design de arquitetura, design detalhado, implementação, integração e verificações, validação do sistema e liberação. Todas estas etapas, necessariamente nesta ordem.
Mas a minha intenção ao escrever era de comparar este processo com outros padrões bem estabelecidos de desenvolvimento de software que existem por ai, como o CMMI e o MPS-BR. O CMMI tem níveis de maturidade que variam do nível 1 (menos maduro) até o 5 (mais maduro). Estes estágios ficam bem diferenciados assim:
- Realização – Estágio inicial;
- Gerenciado – Gerenciamento de requisitos, planejamento de projeto, monitoramento e controle de projeto, gerenciamento de fornecedores, medição e análise, garantia da qualidade do processo e do produto, gerenciamento de configuração;
- Definido – Desenvolvimento de requisitos, solução técnica, integração do produto, verificação e validação, foco no processo organizacional, definição do processo organizacional, treinamento organizacional, gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução;
- Quantitativamente – Gerenciamento quantitativo do projeto, performance do processo organizacional;
- Otimização – Análise causal e resolução, inovação organizacional e implantação.
Comparando estes níveis de maturidade com o nível mínimo de processo que a norma IEC 62304 exige, acredito que sairemos no fim deste ano com uma equivalência de processos muito próxima ao que é exigido no nível 3, porque não fazemos uso de métricas detalhadas e a parte quantitativa é um pouco pior que o exigido neste nível de maturidade realmente. Também acredito que o nível 5 de otimização não é algo tão distante do que o que procuramos fazer aqui. Mas como não fazemos isso com a quantidade de evidências e mensurações necessárias para o CMMI, mesmo que pudesse atingir o nível 5 pulando o nível 4 (não pode fazer isso, você só pode alcançar um nível de maturidade maior se tiver os anteriores) não atingiríamos este estado de processos em melhoria contínua.
Mas não estou dizendo que se pagarmos o preço, qualquer auditoria já nos promoveria automaticamente. Provavelmente há algum rigor extra em alguns dos quesitos que acredito que cumprimos, como o fato de a empresa que trabalho não ter uma equipe dedicada a testes. Mesmo assim, acabamos fazendo validação com equipes trocadas que acaba ajudando a cumprir esta parte da norma também, de que quem desenvolve o produto não pode atestar que está funcionando.
Para não ficarmos só com o utópico, porque não vejo muitas necessidades de a Dixtal pagar para ter uma certificação destas atualmente, resolvi também comparar com o MPS-BR. Que foi criado exatamente por isso. Algumas empresas brasileiras precisavam exigir um nível mínimo de qualidade (é pra isso que serve ser atestado como um nível de maturidade de desenvolvimento maior no CMMI) e para empresas menores este custo de implantar o CMMI era bastante proibitivo. A última vez que conferi os valores, ele circulava na faixa de R$ 300 mil a R$ 400 mil por ter que importar auditores. Então o modelo brasileiro, com certificação emitida por auditorias nacionais acaba tendo um preço mais acessível e foi definido de forma muito parecida que o primo rico. Mas ele conta com 7 níveis de maturidade e os níveis são decrescentes no lugar de crescentes. Vai do nível G (pior) para o nível A (melhor). Então se precisarmos criar um outro nível depois do estado de otimização contínua, acho que vamos ter que deslocar os rankings de todas as empresas... De qualquer forma, eles significam:
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.
Neste processo eu confesso que tive um pouco de dificuldades de fazer a conversão do nível de maturidade que imagino para a Dixtal. Se no CMMI eu a considerei com processos definidos, tenho praticamente 3 níves (de E até C) que são mais ou menos a mesma correspondência. Precisei recorrer a um nível de detalhamento maior dos níveis de maturidade.
Nível G - Parcialmente Gerenciado
Processo: Gerência do Projeto - GPR
Processo: Gerência de Requisitos - GRE Nível
F – Gerenciado
Processo: Aquisição - AQU
Processo: Gerência de Configuração - GCO
Processo: Garantia da Qualidade - GQA
Processo: Medição - MED
Nivel E - Parcialmente Definido
Processo: Adaptação do Processo para Gerência do Projeto - APG
Processo: Avaliação e Melhoria do Processo Organizacional - AMP
Processo: Definição do Processo Organizacional - DFP
Processo: Treinamento - TRE
Nível D - Largamente Definido
Processo: Desenvolvimento de Requisitos - DRE
Processo: Integração do Produto - ITP
Processo: Solução Técnica - STE
Processo: Validação - VAL
Processo: Verificação - VER
Nível C – Definido
Processo: Análise de Decisão e Resolução - ADR
Processo: Gerência de Riscos - GRI
Nível B - Gerenciado Quantitativamente
Processo: Desempenho do Processo Organizacional - DEP
Processo: Gerência Quantitativa do Projeto - GQP
Nível A - Em Otimização
Processo: Implantação de Inovações na Organização - IIO
Processo: Análise de Causas e Resolução- ARC
Neste caso, acho que fico com o nível G! Brincadeira. É que a gerência de Requisitos é uma das coisas que estamos melhorando muito agora e é um pré-requisito para se começar a brincar nos níveis de maturidade do MPS-BR. Mas voltando a diferenciação dos três níveis de maturidade que eu queria separar, acredito que já chegaremos ao "nível C - Definido" até o fim do ano, realmente. É muito complicado um setor de equipamentos hospitalares não cuidar da Gestão de Risco...
sexta-feira, 29 de maio de 2009
Análise de Pontos de Função (APF)
O gerenciamento de projetos de software não é algo completamente novo, já amadureceu muito, aproveitando idéias de diversas ciências e engenharias já existentes para que pudesse se tornar um projeto gerenciável.
Mas uma das dificuldades que este tipo de projeto encontrou foi o de gerenciamento de prazos. É razoavelmente conhecido como devemos proceder para estimar quanto tempo levaremos para produzir um prédio sabendo sua metragem, andares, planta, etc. Mas das métricas que foram criadas para medir o tamanho de um software, pontos de função é uma das mais bem aceitas.
Claro que não é qualquer projeto que precisa desta solução, mas consultorias são um bom exemplo de onde uma técnica como esta pode trazer resultados muito bons. Estimar errado o tamanho de um software para menos, pode gerar prejuízo (pagando por funcionários por mais tempo do que foi cobrado do cliente) e insatisfação (pelo atraso em si). Estimar o tamanho errado para o outro lado, também é um problema.
Afinal, você não quer ter que cobrar o dobro do estimado inicial só por segurança, quer? Não acha que é provável que outra consultoria consiga fazer um preço menor e mais justo? Pois é...
A IBM acabou criando e deixando em domínio público esta técnica que é aprimorada hoje em dia pela IFPUG, que nada mais é que transformar todas as funcionalidades que um software precisa fazer em um número (chamado de Pontos de Função). Uma descrição um pouco melhor de como é feita esta contagem pode ser vista neste artigo da presidente da Quality Plus Technologies em 1998, Carol A. Dekkers: http://www.bfpug.com.br/Artigos/Dekkers-PontosDeFuncaoEMedidas.htm. Mas não se preocupe, já existem até freewares que ajudam nesta contagem de pontos de função, como a APFPlus que pode ser encontrada no dia deste post pelo link http://www.bsb.netium.com.br/mecenas/apf.htm.
Baseado neste número, histórico da empresa, baseando-se no nível dos profissionais que vão implementar o software, nível de conhecimento deles na linguagem escolhida, quantidade de documentos que precisam ser gerados (variam de empresa para empresa, pode ter certeza) e inúmeras outras variáveis, é que se define quanto tempo levaria-se para produzir o software em questão.
Isto quer dizer que o sistema já é perfeito? Não. Certamente há muito o que melhorar neste cálculo e é até por isso que IFPUG continua desenvolvendo este padrão, conforme nossa maturidade com projetos de software aumente. Mas certamente é uma das melhores soluções que temos hoje em dia.
Mas uma das dificuldades que este tipo de projeto encontrou foi o de gerenciamento de prazos. É razoavelmente conhecido como devemos proceder para estimar quanto tempo levaremos para produzir um prédio sabendo sua metragem, andares, planta, etc. Mas das métricas que foram criadas para medir o tamanho de um software, pontos de função é uma das mais bem aceitas.
Claro que não é qualquer projeto que precisa desta solução, mas consultorias são um bom exemplo de onde uma técnica como esta pode trazer resultados muito bons. Estimar errado o tamanho de um software para menos, pode gerar prejuízo (pagando por funcionários por mais tempo do que foi cobrado do cliente) e insatisfação (pelo atraso em si). Estimar o tamanho errado para o outro lado, também é um problema.
Afinal, você não quer ter que cobrar o dobro do estimado inicial só por segurança, quer? Não acha que é provável que outra consultoria consiga fazer um preço menor e mais justo? Pois é...
A IBM acabou criando e deixando em domínio público esta técnica que é aprimorada hoje em dia pela IFPUG, que nada mais é que transformar todas as funcionalidades que um software precisa fazer em um número (chamado de Pontos de Função). Uma descrição um pouco melhor de como é feita esta contagem pode ser vista neste artigo da presidente da Quality Plus Technologies em 1998, Carol A. Dekkers: http://www.bfpug.com.br/Artigos/Dekkers-PontosDeFuncaoEMedidas.htm. Mas não se preocupe, já existem até freewares que ajudam nesta contagem de pontos de função, como a APFPlus que pode ser encontrada no dia deste post pelo link http://www.bsb.netium.com.br/mecenas/apf.htm.
Baseado neste número, histórico da empresa, baseando-se no nível dos profissionais que vão implementar o software, nível de conhecimento deles na linguagem escolhida, quantidade de documentos que precisam ser gerados (variam de empresa para empresa, pode ter certeza) e inúmeras outras variáveis, é que se define quanto tempo levaria-se para produzir o software em questão.
Isto quer dizer que o sistema já é perfeito? Não. Certamente há muito o que melhorar neste cálculo e é até por isso que IFPUG continua desenvolvendo este padrão, conforme nossa maturidade com projetos de software aumente. Mas certamente é uma das melhores soluções que temos hoje em dia.
quinta-feira, 28 de maio de 2009
Inteligência de Negócios
Ou, como é mais conhecido por aqui, BI (Business Intelligence). Ele
serve para definir um objetivo, mais do que uma forma. Ele tem este nome
porque é um desejo antigo que agora, com a tecnologia que temos
disponível está se tornando realidade. Podemos armazenar inúmeros dados
diferentes, cadastros de clientes e o que mais desejarmos em um banco de
dados. O conceito de hoje de BI é muito difundido pela possibilidade de
transformação destes dados perdidos em uma informação útil e em tempo
hábil para uma tomada de decisão melhor.
Existem diversas softwares que facilitam e muito qualquer tomada de
decisão já prontos. Microsoft, Oracle, IBM e SAP oferecem soluções
bastante sólidas, mas ainda assim as pessoas precisam trabalhar as
soluções para cada caso. Porque apesar de a infra-estrutura de
armazenamento, acesso e análise dos dados ser sempre semelhante, a
informação que realmente importa para cada parte do negócio é diferente.
Neste momento é bom que cada empresa tenha conhecimento suficiente para
poder escolher entre as soluções disponíveis e como proceder para se
obter as informações que deseja. Um bom método de implantação segue a
seguinte fórmula:
1-) Definição de metas e planejamento do BI.
2-) Definições de base de dados. Onde estamos e que dados extras
precisaremos.
3-) Definições de custos e riscos, já tendo uma boa base de qual solução
se deseja adotar ou desenvolver para satisfazer as metas.
4-) Desenvolvimento e/ou implatação das soluções selecionadas. Pode ser
tão simples quanto utilizar uma planilha do excel e preencherem ela
sempre, quanto ser necessário um Gestor de Mudança para a implantação de
softwares de CRM, ERP, supply chain management, etc.
serve para definir um objetivo, mais do que uma forma. Ele tem este nome
porque é um desejo antigo que agora, com a tecnologia que temos
disponível está se tornando realidade. Podemos armazenar inúmeros dados
diferentes, cadastros de clientes e o que mais desejarmos em um banco de
dados. O conceito de hoje de BI é muito difundido pela possibilidade de
transformação destes dados perdidos em uma informação útil e em tempo
hábil para uma tomada de decisão melhor.
Existem diversas softwares que facilitam e muito qualquer tomada de
decisão já prontos. Microsoft, Oracle, IBM e SAP oferecem soluções
bastante sólidas, mas ainda assim as pessoas precisam trabalhar as
soluções para cada caso. Porque apesar de a infra-estrutura de
armazenamento, acesso e análise dos dados ser sempre semelhante, a
informação que realmente importa para cada parte do negócio é diferente.
Neste momento é bom que cada empresa tenha conhecimento suficiente para
poder escolher entre as soluções disponíveis e como proceder para se
obter as informações que deseja. Um bom método de implantação segue a
seguinte fórmula:
1-) Definição de metas e planejamento do BI.
2-) Definições de base de dados. Onde estamos e que dados extras
precisaremos.
3-) Definições de custos e riscos, já tendo uma boa base de qual solução
se deseja adotar ou desenvolver para satisfazer as metas.
4-) Desenvolvimento e/ou implatação das soluções selecionadas. Pode ser
tão simples quanto utilizar uma planilha do excel e preencherem ela
sempre, quanto ser necessário um Gestor de Mudança para a implantação de
softwares de CRM, ERP, supply chain management, etc.
quarta-feira, 27 de maio de 2009
Segurança da Informação
A norma ISO 27001 especifica requisitos de um sistema de gerenciamento das informações da empresa. Não chega a dizer como fazer, mas o processo que deve ser seguido para se minimizar os riscos de segurança de toda a informação da organização.
Este processo proposto pela norma ISO/IEC 27001 contém muitos ciclos de PDCA (sigla do inglês para Planejar-Fazer-Verificar-Agir). Os controles de segurança da informação, por exemplo, devem ser criados e implementados, mas também precisam passar por revisões e serem ajustados para refletir todas as novas ameaças, vulnerabilidades e impactos que a segurança da informação possa sofrer.
A idéia desta norma é auxiliar com muitos objetivos. Entre eles o de formular requisitos e objetivos de segurança e garantir que os riscos de segurança estão financeiramente controlados. Para conseguir todos estes objetivos eles propõe a criação de um documento (e possivelmente outros menores que são referenciados deste) chamado de ISMS (Information Security Management System).
O ISMS deve ser criado e analisado na empresa. O processo que deve ser criado deve prever uma revisão no mínimo anual deste documento e também devem ser feitas auditorias internas periódicas para verificar que o ISMS está sendo cumprido.
Na figura (tirada do toolkit da norma ISO27K) dá uma idéia melhor de como este procedimento deveria funcionar e em que momento devem ser geradas evidências de que o ISMS está sendo seguido.
Este processo proposto pela norma ISO/IEC 27001 contém muitos ciclos de PDCA (sigla do inglês para Planejar-Fazer-Verificar-Agir). Os controles de segurança da informação, por exemplo, devem ser criados e implementados, mas também precisam passar por revisões e serem ajustados para refletir todas as novas ameaças, vulnerabilidades e impactos que a segurança da informação possa sofrer.
A idéia desta norma é auxiliar com muitos objetivos. Entre eles o de formular requisitos e objetivos de segurança e garantir que os riscos de segurança estão financeiramente controlados. Para conseguir todos estes objetivos eles propõe a criação de um documento (e possivelmente outros menores que são referenciados deste) chamado de ISMS (Information Security Management System).
O ISMS deve ser criado e analisado na empresa. O processo que deve ser criado deve prever uma revisão no mínimo anual deste documento e também devem ser feitas auditorias internas periódicas para verificar que o ISMS está sendo cumprido.
Na figura (tirada do toolkit da norma ISO27K) dá uma idéia melhor de como este procedimento deveria funcionar e em que momento devem ser geradas evidências de que o ISMS está sendo seguido.
terça-feira, 26 de maio de 2009
Conceitos de Software Livre
Software Livre, Software Grátis, Código Aberto, Software em Domínio Público e outros conceitos novos se misturam por ai hoje em dia.
Mas a idéia do software livre (free software) é até bastante simples. A idéia é que o usuário possa usar, estudar, copiar, modificar e redistribuir o software como e quando quiser.
Por isto, ele, usuário, seria livre para fazer o que quisesse com o software. A "Free Software Foundation" (www.fsf.org), inclusive, chega a se posicionar eticamente sobre o problema, defendendo que com software livre, nenhum usuário precisaria ficar preso ou dependente a uma empresa. Comemoram inclusive que em 1992, com o GNU e o kernel do Linux eles conseguiram criar um sistema operacional completo sem fazer uso de qualquer software proprietário.
Em inglês, a confusão com Software grátis é um pouco maior. Já que a palavra "free" também tem este significado. Mas o fato de o software ser livre, não tem nada a ver com o preço do software. Empresas e pessoas podem desenvolver software livre cobrando pelos seus serviços ou pelo software. Por exemplo, é possível contratar uma empresa para criar um software para fazer o que você precisa no linux. E mesmo que este
software venha a ter seu código aberto e atender todos os requisitos de um software livre, o serviço para que a alteração fosse realizada teria sido pago.
Agora, que definimos que não é o preço, vamos dizer quais as quatro condições que o software deve seguir para ser livre, segundo a FSF (Free Software Foundation). Você deve ser livre para:
- Utilizar o programa, para qualquer fim.
- Entender e alterar o programa para suas necessidades.
- Distribuir o programa para seu vizinho se quiser.
- Melhorar o programa e distribuir estas melhorias para toda a comunidade.
Então nós chegamos a um outro conceito, muito parecido com o de software livre. O de código aberto. O código do programa ser aberto ao usuário é condição necessária para a segunda (entender e alterar) e quarta (melhorar) liberdades, mas não significa que os dois conceitos são iguais. O usuário precisa poder acessar o código fonte dos programas para poder entender, alterar e melhorar ele. Mas existem algumas diferenças, por causa das licenças utilizadas em cada software, que permitem uma variação grande na forma como este código é distruído, por exemplo. Mesmo uma empresa que queira distribuir um programa de propriedade dela e não livre, poderia entregar o código fonte, sem lhe dar autorização para alterar ou distribuir (pelo menos até o software deixar de ser protegido pelas leis de direitos autorais e cair no
chamado domínio público)... De qualquer forma, existem principalmente dois tipos de licenças que permitem que o software com código aberto seja livre.
Licenças do tipo "copyleft", por exemplo, exigem que qualquer um que faça uma melhoria no software que funciona com esta licença, que mantenha o software livre depois com as suas alterações. Existem algumas licenças padrões já prontas, com a mais famosa sendo a licença GPL (General Public License), que é a licença que a própria fundação de software livre utiliza.
Mas mesmo sendo livre, o software pode seguir algumas regras na sua forma de distribuição ou utilização, se estas regras não entrarem em conflito com as quatro liberdades essenciais. Você pode até vender cópias de um software livre, só que não deve demorar até alguém resolver vender mais barato ou dar o seu software... Então é bom ter uma estratégia sólida para ganhar dinheiro com ele. O lado bom é que você
não vai nem ouvir falar de piratas, já que sua estratégia de negócios já teria que levar esta distribuição de terceiros em consideração.
Já o tipo de licença "non-copylefted free software" se refere ao software que é livre para as versões em que foi criado, mas é possível que outras versões sejam ou não livres. Ficando a critério de seus autores. E por esta razão não é muito recomendado pelos aficionados por software livre que se utilize este tipo de licença. Mas existem
softwares deste tipo e é possível se "apropriar" de software alheio e torná-lo proprietário (poder cobrar pela distribuição, alterações e não disponibilizar o código fonte).
Mas a idéia do software livre (free software) é até bastante simples. A idéia é que o usuário possa usar, estudar, copiar, modificar e redistribuir o software como e quando quiser.
Por isto, ele, usuário, seria livre para fazer o que quisesse com o software. A "Free Software Foundation" (www.fsf.org), inclusive, chega a se posicionar eticamente sobre o problema, defendendo que com software livre, nenhum usuário precisaria ficar preso ou dependente a uma empresa. Comemoram inclusive que em 1992, com o GNU e o kernel do Linux eles conseguiram criar um sistema operacional completo sem fazer uso de qualquer software proprietário.
Em inglês, a confusão com Software grátis é um pouco maior. Já que a palavra "free" também tem este significado. Mas o fato de o software ser livre, não tem nada a ver com o preço do software. Empresas e pessoas podem desenvolver software livre cobrando pelos seus serviços ou pelo software. Por exemplo, é possível contratar uma empresa para criar um software para fazer o que você precisa no linux. E mesmo que este
software venha a ter seu código aberto e atender todos os requisitos de um software livre, o serviço para que a alteração fosse realizada teria sido pago.
Agora, que definimos que não é o preço, vamos dizer quais as quatro condições que o software deve seguir para ser livre, segundo a FSF (Free Software Foundation). Você deve ser livre para:
- Utilizar o programa, para qualquer fim.
- Entender e alterar o programa para suas necessidades.
- Distribuir o programa para seu vizinho se quiser.
- Melhorar o programa e distribuir estas melhorias para toda a comunidade.
Então nós chegamos a um outro conceito, muito parecido com o de software livre. O de código aberto. O código do programa ser aberto ao usuário é condição necessária para a segunda (entender e alterar) e quarta (melhorar) liberdades, mas não significa que os dois conceitos são iguais. O usuário precisa poder acessar o código fonte dos programas para poder entender, alterar e melhorar ele. Mas existem algumas diferenças, por causa das licenças utilizadas em cada software, que permitem uma variação grande na forma como este código é distruído, por exemplo. Mesmo uma empresa que queira distribuir um programa de propriedade dela e não livre, poderia entregar o código fonte, sem lhe dar autorização para alterar ou distribuir (pelo menos até o software deixar de ser protegido pelas leis de direitos autorais e cair no
chamado domínio público)... De qualquer forma, existem principalmente dois tipos de licenças que permitem que o software com código aberto seja livre.
Licenças do tipo "copyleft", por exemplo, exigem que qualquer um que faça uma melhoria no software que funciona com esta licença, que mantenha o software livre depois com as suas alterações. Existem algumas licenças padrões já prontas, com a mais famosa sendo a licença GPL (General Public License), que é a licença que a própria fundação de software livre utiliza.
Mas mesmo sendo livre, o software pode seguir algumas regras na sua forma de distribuição ou utilização, se estas regras não entrarem em conflito com as quatro liberdades essenciais. Você pode até vender cópias de um software livre, só que não deve demorar até alguém resolver vender mais barato ou dar o seu software... Então é bom ter uma estratégia sólida para ganhar dinheiro com ele. O lado bom é que você
não vai nem ouvir falar de piratas, já que sua estratégia de negócios já teria que levar esta distribuição de terceiros em consideração.
Já o tipo de licença "non-copylefted free software" se refere ao software que é livre para as versões em que foi criado, mas é possível que outras versões sejam ou não livres. Ficando a critério de seus autores. E por esta razão não é muito recomendado pelos aficionados por software livre que se utilize este tipo de licença. Mas existem
softwares deste tipo e é possível se "apropriar" de software alheio e torná-lo proprietário (poder cobrar pela distribuição, alterações e não disponibilizar o código fonte).
Assinar:
Postagens (Atom)