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).
domingo, 31 de maio de 2009
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)