Amigos, atualmente estou postando textos próprios sobre tecnologia no meu site pessoal. Anotem ai: http://luizearaujo.com
Nos vemos lá!
segunda-feira, novembro 09, 2009
quinta-feira, setembro 21, 2006
USP lança modelo de fábrica de software para pequena e média empresa
Por Camila Rodrigues
Para quem desenvolve software, uma boa notícia: o Laboratório de Tecnologia de Software (LTS) da Escola Politécnica da USP, lançou esta semana um modelo de fábrica de software voltado para pequenas e médias empresas, baseado em tecnologias que permitem definir processos de desenvolvimento de software, com o objetivo de facilitar a exportação.
O melhor de tudo é que este modelo já está acessível às empresas que se interessarem, conta Jorge Risco, professor do LTS responsável pelo desenvolvimento do modelo. Ele diz que basta mandar um e-mail para ele, jorge.becerra@poli.usp.br, ou para o professor Fabio Levy Siqueira, levy.siqueira@poli.usp.br, que também faz parte do projeto. A aplicação do modelo tem um custo, que varia de acordo com a empresa, sua cultura, maturidade dos processos e até tamanho da equipe, detalha Siqueira.
Jorge Risco explica que, ao definir processos, fica mais fácil controlar, supervisionar e assegurar a qualidade do programa que é desenvolvido. “Também se torna possível integrar estas fábricas com empresas de desenvolvimento de software que atuem em mercados mais exigentes, como a Comunidade Européia”, exemplifica o acadêmico.
Esta idéia era voltada, inicialmente, para utilização em células produtivas que tinham intenção de exportar softwares. Normalmente, estas células são compostas por até três desenvolvedores e consultores que criam softwares para dispositivos móveis,web services e ERPs, por exemplo, detalha o professor. O acadêmico adianta que o LTS já pensa em ampliar esse padrão para o desenvolvimento de games tanto para consoles quanto para celulares, além de um modelo de integração de middleware para SMBs.
Segundo ele, o modelo foi desenvolvido por professores e pesquisadores do LTS a partir de processos modelados em Business Process Modeling (BPM), com arquitetura baseada no padrão Open Distributed Processing (ODP), e configurados em ferramentas de mercado e de código-aberto. A qualidade dos programas é guiada pelo padrão mundial CMMI.
O professor Risco diz que o laboratório já entrou em contato com o Centro Incubador de Empresas Tecnológicas da Universidade de São Paulo (CIETEC) para que suas incubadoras comecem a implantar tal modelo.
Caso você seja um desenvolvedor e queira saber mais sobre este modelo de fábrica de software, também pode contatar o professor Risco pelo telefone 3091-5200 ou 3091-5368.
Publicado originalmente no endereço http://idgnow.uol.com.br
Para quem desenvolve software, uma boa notícia: o Laboratório de Tecnologia de Software (LTS) da Escola Politécnica da USP, lançou esta semana um modelo de fábrica de software voltado para pequenas e médias empresas, baseado em tecnologias que permitem definir processos de desenvolvimento de software, com o objetivo de facilitar a exportação.
O melhor de tudo é que este modelo já está acessível às empresas que se interessarem, conta Jorge Risco, professor do LTS responsável pelo desenvolvimento do modelo. Ele diz que basta mandar um e-mail para ele, jorge.becerra@poli.usp.br, ou para o professor Fabio Levy Siqueira, levy.siqueira@poli.usp.br, que também faz parte do projeto. A aplicação do modelo tem um custo, que varia de acordo com a empresa, sua cultura, maturidade dos processos e até tamanho da equipe, detalha Siqueira.
Jorge Risco explica que, ao definir processos, fica mais fácil controlar, supervisionar e assegurar a qualidade do programa que é desenvolvido. “Também se torna possível integrar estas fábricas com empresas de desenvolvimento de software que atuem em mercados mais exigentes, como a Comunidade Européia”, exemplifica o acadêmico.
Esta idéia era voltada, inicialmente, para utilização em células produtivas que tinham intenção de exportar softwares. Normalmente, estas células são compostas por até três desenvolvedores e consultores que criam softwares para dispositivos móveis,web services e ERPs, por exemplo, detalha o professor. O acadêmico adianta que o LTS já pensa em ampliar esse padrão para o desenvolvimento de games tanto para consoles quanto para celulares, além de um modelo de integração de middleware para SMBs.
Segundo ele, o modelo foi desenvolvido por professores e pesquisadores do LTS a partir de processos modelados em Business Process Modeling (BPM), com arquitetura baseada no padrão Open Distributed Processing (ODP), e configurados em ferramentas de mercado e de código-aberto. A qualidade dos programas é guiada pelo padrão mundial CMMI.
O professor Risco diz que o laboratório já entrou em contato com o Centro Incubador de Empresas Tecnológicas da Universidade de São Paulo (CIETEC) para que suas incubadoras comecem a implantar tal modelo.
Caso você seja um desenvolvedor e queira saber mais sobre este modelo de fábrica de software, também pode contatar o professor Risco pelo telefone 3091-5200 ou 3091-5368.
Publicado originalmente no endereço http://idgnow.uol.com.br
quarta-feira, setembro 20, 2006
Planilha Eletrônica no Google
Por Henrique Meira
Para aqueles que necessitam de uma planilha eletrônica online, para que possa edita-la em qualquer lugar, e compartilha-la, etc. Não pode deixar de visitar o site: http://spreadsheets.google.com.
O Google disponibiliza uma ferramenta muito interessante e funcional: O Google Spreadsheet. Com esta ferramenta você pode criar, salvar, abrir, importar e exportar planilhas. Vale muito à pena.
Você precisa ter uma conta no Google para usar a ferramenta.
Publicado originalmente no endereço http://www.dicas-l.com.br
Para aqueles que necessitam de uma planilha eletrônica online, para que possa edita-la em qualquer lugar, e compartilha-la, etc. Não pode deixar de visitar o site: http://spreadsheets.google.com.
O Google disponibiliza uma ferramenta muito interessante e funcional: O Google Spreadsheet. Com esta ferramenta você pode criar, salvar, abrir, importar e exportar planilhas. Vale muito à pena.
Você precisa ter uma conta no Google para usar a ferramenta.
Publicado originalmente no endereço http://www.dicas-l.com.br
Empresas querem lei para regular profissional de TI
Por Redação da TI Inside
A indústria de TI começa a se movimentar para criação de uma legislação especifica para os profissionais do setor. Um grupo de empresas que desenvolve software e exportam serviços, liderado pelo Instituto Brasil para Convergência Digital (IBCD), já entregou uma proposta ao governo.
Segundo, a advogada Cristina Tosi Inoue, do escritório Tosi Inoue Advogados Associados, o documento foi entregue aos Ministérios do Trabalho e do Desenvolvimento, Indústria e Comércio Exterior. A propostas foram do documento foram debatidas na semana passada durante o seminário "A Indústria de Serviços de TI - Desenvolvimento de Software, Exportação e Competividade", realizado em São Paulo pelp IBCD.
Critina afirma que a realidade dos profissionais de TI é muito diferente dos de outros setores e nem mesmo uma reforma na CLT (Consolidação das Leis do Trabalho), que é uma compilação de 1943 está muito ultrapassada, resolveria a situação. Por isso, ela defende uma lei específica para esse segmento.
A advogada destaca que o sistema de trabalho do profissional de TI tem algumas peculiaridades. A começar pelo local de trabalho, que pode ser em qualquer lugar, já que as tecnologias permitem que as tarefas sejam realizadas remotamente. O horário também segue outro ritmo, com algumas funções que podem ser feitas em qualquer período do dia.
As empresas tentaram criar algumas alternativas para alguns profissionais com contratos terceirizados, que segundo Cristina, não tem embasamento legal e que nada impede que os trabalhadores entrem futuramente na Justiça contra as companhias contratantes, alegando vínculo empregatício. O modelo de cooperativa poderia ser uma saída, mas caiu em descrédito por já ter sido burlado.
Medidas propostas
Como sugestão para criação de uma lei para regular a atividade de TI, a advogada cita reconhecimento da execução de tarefas em home office, criação de um banco de horas, instituição de horário flexível e ampliação do contrato de experiência de três meses para um ano; contratação de profissionais para projetos específicos.
Com essas mudanças, Cristina diz que o setor ganharia mais competitividade para competir, principalmente no mercado externo por dos encargos que encarecem a mão-de-obra brasileira. Ela afirma que 50% dos custos das empresas hoje são impostos trabalhistas.
Publicado originalmente no endereço http://www.tiinside.com.br
A indústria de TI começa a se movimentar para criação de uma legislação especifica para os profissionais do setor. Um grupo de empresas que desenvolve software e exportam serviços, liderado pelo Instituto Brasil para Convergência Digital (IBCD), já entregou uma proposta ao governo.
Segundo, a advogada Cristina Tosi Inoue, do escritório Tosi Inoue Advogados Associados, o documento foi entregue aos Ministérios do Trabalho e do Desenvolvimento, Indústria e Comércio Exterior. A propostas foram do documento foram debatidas na semana passada durante o seminário "A Indústria de Serviços de TI - Desenvolvimento de Software, Exportação e Competividade", realizado em São Paulo pelp IBCD.
Critina afirma que a realidade dos profissionais de TI é muito diferente dos de outros setores e nem mesmo uma reforma na CLT (Consolidação das Leis do Trabalho), que é uma compilação de 1943 está muito ultrapassada, resolveria a situação. Por isso, ela defende uma lei específica para esse segmento.
A advogada destaca que o sistema de trabalho do profissional de TI tem algumas peculiaridades. A começar pelo local de trabalho, que pode ser em qualquer lugar, já que as tecnologias permitem que as tarefas sejam realizadas remotamente. O horário também segue outro ritmo, com algumas funções que podem ser feitas em qualquer período do dia.
As empresas tentaram criar algumas alternativas para alguns profissionais com contratos terceirizados, que segundo Cristina, não tem embasamento legal e que nada impede que os trabalhadores entrem futuramente na Justiça contra as companhias contratantes, alegando vínculo empregatício. O modelo de cooperativa poderia ser uma saída, mas caiu em descrédito por já ter sido burlado.
Medidas propostas
Como sugestão para criação de uma lei para regular a atividade de TI, a advogada cita reconhecimento da execução de tarefas em home office, criação de um banco de horas, instituição de horário flexível e ampliação do contrato de experiência de três meses para um ano; contratação de profissionais para projetos específicos.
Com essas mudanças, Cristina diz que o setor ganharia mais competitividade para competir, principalmente no mercado externo por dos encargos que encarecem a mão-de-obra brasileira. Ela afirma que 50% dos custos das empresas hoje são impostos trabalhistas.
Publicado originalmente no endereço http://www.tiinside.com.br
Projeto de lei exige regulamentação do profissional de tecnologia
Por Redação do Computerworld
As atividades de profissionais das áreas de informática, computação e sistemas de informação, poderão, em breve, ter regras específicas para regulamentação. Trata-se do projeto de lei 7109/06, de autoria do deputado Bonifácio Andrada (PSDB-MG) destinado a regulamentar o trabalho de funcionários desses setores.
Segundo a proposta, poderão exercer essas atividades os portadores de diploma universitário dos cursos de informática ou computação, processamento de dados, sistemas de informação e áreas correlatas reconhecidas pela legislação do ensino. Quem estudou no exterior deverá validar o diploma no Brasil.
Os tecnólogos e os formados em cursos seqüenciais e técnicos da área de informática e computação também poderão exercer a profissão, desde que observem as leis vigentes.
Aqueles que não tiverem formação superior ou técnica, mas que comprovarem por meio de documentos que trabalham na área há pelos cinco anos, poderão continuar trabalhando. No entanto, eles terão que regularizar a sua situação profissional no Ministério do Trabalho.
Caso o projeto seja aprovado, o Executivo deverá enviar ao Congresso Nacional, no prazo de 60 dias, um projeto de lei criando o Conselho Federal de Informação e Computação e os conselhos regionais, estabelecendo as definições legais para a atividade profissional e sindical dessas áreas de trabalho.
Enquanto esses conselhos não forem implantados, o projeto estabelece que os profissionais com formação superior deverão registrar o diploma no Ministério do Trabalho.
O projeto tramita em caráter conclusivo e será analisado pelas comissões de Educação e Cultura; de Trabalho, de Administração e Serviço Público; e de Constituição e Justiça e de Cidadania.
*Com informações da Agência Câmara
Publicado originalmente no endereço http://idgnow.uol.com.br
As atividades de profissionais das áreas de informática, computação e sistemas de informação, poderão, em breve, ter regras específicas para regulamentação. Trata-se do projeto de lei 7109/06, de autoria do deputado Bonifácio Andrada (PSDB-MG) destinado a regulamentar o trabalho de funcionários desses setores.
Segundo a proposta, poderão exercer essas atividades os portadores de diploma universitário dos cursos de informática ou computação, processamento de dados, sistemas de informação e áreas correlatas reconhecidas pela legislação do ensino. Quem estudou no exterior deverá validar o diploma no Brasil.
Os tecnólogos e os formados em cursos seqüenciais e técnicos da área de informática e computação também poderão exercer a profissão, desde que observem as leis vigentes.
Aqueles que não tiverem formação superior ou técnica, mas que comprovarem por meio de documentos que trabalham na área há pelos cinco anos, poderão continuar trabalhando. No entanto, eles terão que regularizar a sua situação profissional no Ministério do Trabalho.
Caso o projeto seja aprovado, o Executivo deverá enviar ao Congresso Nacional, no prazo de 60 dias, um projeto de lei criando o Conselho Federal de Informação e Computação e os conselhos regionais, estabelecendo as definições legais para a atividade profissional e sindical dessas áreas de trabalho.
Enquanto esses conselhos não forem implantados, o projeto estabelece que os profissionais com formação superior deverão registrar o diploma no Ministério do Trabalho.
O projeto tramita em caráter conclusivo e será analisado pelas comissões de Educação e Cultura; de Trabalho, de Administração e Serviço Público; e de Constituição e Justiça e de Cidadania.
*Com informações da Agência Câmara
Publicado originalmente no endereço http://idgnow.uol.com.br
terça-feira, setembro 05, 2006
Google lança pacote de aplicações de colaboração baseadas em web
Por Nancy Weil
O Google lançou o Google Apps for Your Domain, pacote de aplicações de colaboração baseadas em web para empresas de pequeno e médio porte, universidades e grupos, com objetivo de ampliar para companhias de maior porte até o final do ano.
As organizações poderão se inscrever para acessar aversão beta do serviço baseado em web no site do Google, que entra no ar nesta segunda-feira (28/08). O serviço não será gratuito para grandes empresas e o preço deve ser anunciado quando a data de lançamento estiver definida.
A oferta inclui as aplicações Gmail, Google Calendar, Google Talk e Page Creator, programas que a companhia lançou nos últimos meses ou integrou com os outros. Mais softwares serão inclusos no pacote ao longo do tempo, segundo Matthew Glotzbach, chefe da divisão de produtos corporativos do Google.
O executivo não detalhou quais seriam essas aplicações, mas os softwares online de planilhas e processador de texto do Google devem entrar para o pacote de colaboração. O Google não comenta sobre concorrência, mas a suíte parece ser talhada para fazer frente, por exemplo, ao software de colaboração da IBM Lotus Notes.
A companhia aposta, como diferencial, na aparência inovadora das aplicações, que serão customizadas conforme a página da organização.
O objetivo é permitir às companhias acessar aplicações colaborativas mesmo que não tenham equipes de suporte para dedicar a essas tarefas, reduzindo os custos de manutenção, segundo Glotzbach.
A versão premium, para grandes empresas, vai incluir suporte mais avançado, contratos de nível de serviço e “integração mais rica aos domínios”.
*Nancy Weil é editora do IDG News Service, em Boston.
Publicado originalmente no endereço http://idgnow.uol.com.br
O Google lançou o Google Apps for Your Domain, pacote de aplicações de colaboração baseadas em web para empresas de pequeno e médio porte, universidades e grupos, com objetivo de ampliar para companhias de maior porte até o final do ano.
As organizações poderão se inscrever para acessar aversão beta do serviço baseado em web no site do Google, que entra no ar nesta segunda-feira (28/08). O serviço não será gratuito para grandes empresas e o preço deve ser anunciado quando a data de lançamento estiver definida.
A oferta inclui as aplicações Gmail, Google Calendar, Google Talk e Page Creator, programas que a companhia lançou nos últimos meses ou integrou com os outros. Mais softwares serão inclusos no pacote ao longo do tempo, segundo Matthew Glotzbach, chefe da divisão de produtos corporativos do Google.
O executivo não detalhou quais seriam essas aplicações, mas os softwares online de planilhas e processador de texto do Google devem entrar para o pacote de colaboração. O Google não comenta sobre concorrência, mas a suíte parece ser talhada para fazer frente, por exemplo, ao software de colaboração da IBM Lotus Notes.
A companhia aposta, como diferencial, na aparência inovadora das aplicações, que serão customizadas conforme a página da organização.
O objetivo é permitir às companhias acessar aplicações colaborativas mesmo que não tenham equipes de suporte para dedicar a essas tarefas, reduzindo os custos de manutenção, segundo Glotzbach.
A versão premium, para grandes empresas, vai incluir suporte mais avançado, contratos de nível de serviço e “integração mais rica aos domínios”.
*Nancy Weil é editora do IDG News Service, em Boston.
Publicado originalmente no endereço http://idgnow.uol.com.br
SOA: peça básica para integrar o quebra-cabeça tecnológico
Por Daniela Moreira
Ela está na lista das 10 tecnologias mais importantes para o Gartner em 2007, no centro do discurso dos fornecedores de aplicações e nos planos dos principais gestores de tecnolgoa do mundo corporativo. SOA, sigla em inglês para arquitetura orientada a serviços, é o que se conhece por buzzword - a palavra da moda - no mundo da tecnologia.
Na pratica, o que está por trás desta sigla é uma nova abordagem de software dentro das companhias. Na arquitetura orientada a serviços, o objetivo principal é atender necessidades de negócios, agrupando funções em “caixas” ou “módulos” que podem ser copiados e adaptados no futuro para outros fins e integrando, de forma transparente ao usuário, aplicações diversas da empresa, estejam elas espalhadas por departamentos (como um software de leilões usado pela área de compras) ou presentes em toda a organização (como um sistema de gestão empresarial). Os ganhos estão na flexibilidade e na economia com o desenvolvimento e na independência que a área de negócios ganha em relação ao departamento de tecnologia.
SOA, como indica o próprio nome, é uma arquitetura. Logo, envolve alguns elementos. Em uma analogia, é como se dentro de uma sala houvesse especialistas de todo mundo em culinária, e do lado de fora, o dono de um restaurante interessado em montar um cardápio misto.
No mundo da arquitetura de software tradicional, o dono do restaurante teria que ir a cada um desses especialistas - as aplicações isoladas - para pedir as sugestões de pratos, em seu idioma. Na melhor das hipóteses - supondo algum grau de integração - ele poderia pedir ao especialista em culinária italiana uma sugestão de prato que combinasse elementos da cozinha francesa. O chef italiano, por meio de um intérprete, conversaria então com o chef francês para ouvir suas sugestões, e devolveria então uma sugestão de prato ao dono do restaurante.
Trazendo isso para o mundo SOA, nosso dono do restaurante recorria a um único intérprete, capaz de falar o idioma de todos os chefs presentes na sala, e diria a ele: quero um prato franco-italiano. O intérprete responderia com a sugestão de prato pronta, e mais, se o dono do restaurante quisesse no futuro um prato ítalo-germânico, o intérprete aproveitaria o modelo de interação utilizado no primeiro caso adaptando-o ao segundo, para trazer uma resposta similar. Complicado?
Dentro da arquitetura SOA, esse intérprete, que na linguagem tecnológica é chamado de middleware, funciona como um orquestrador dos serviços. Nele estarão determinadas os comandos que serão enviados a cada aplicação, em que ordem, e os outputs que serão retirados de cada uma delas para que os dados e recursos distribuídos em cada aplicação voltem para o usuário como um único serviço.
Para desempenhar esta função de orquestrador, algumas empresas oferecem adaptadores universais, os chamados Enterprise Service Bus (ESB), que já vêm preparados para interagir com algumas aplicações comum dentro de uma empresa, como os bancos de dados, ERP, BI e CRM. “O ESB funciona como uma cola para as aplicações. É uma barra de serviços na qual os softwares vão sendo plugados, sem causar traumas para a empresa”, explica Luiz Cláudio Menezes, diretor geral da Progress Software Brasil.
Outro componente da arquitetura orientada a serviços é o uso de padrões de web services - entre eles Simple Object Access Protocol (SOAP) e Web Services Description Language (WSDL) -, que permitem a comunicação universal entre diferentes sistemas. “A interação entre arquiteturas distintas é fundamental para o SOA”, define Waldir Arevolo, analista do Gartner no Brasil. Se enxergarmos o middleware como maestro destes serviços, os web services são a batuta. Enquanto o middleware é a própria infra-estrutura, os web services são os condutores.
Por fim, na avaliação de Silvio Passos, diretor de soluções da Stefanini, os portais aparecem como um elemento importante - embora não obrigatório - da arquitetura, mostrando-se como a interface ideal - porque é altamente customizável - para a solicitação dos serviços pelos usuários. “É bom que exista, porque funciona como uma interface única e maleável”, opina o executivo.
A combinação dessas características oferece às empresas algumas vantagens, como uma visão mais abrangente dos seus processos de negócio, uma agilidade e uma flexibilidade maiores para fazer mudanças e adaptações aos sistemas de tecnologia que suportam as atividades da companhia - graças à modularidade e à granularidade dos serviços- e a capacidade de reaproveitar os serviços criados para uma área a outras.
“Isto é fundamental, porque não só reduz os custos de administração - já que você não precisa mais de um especialista para cada aplicação que compõe a sua infra-estrutura -, mas também aumenta a capacidade de inovação. Pesquisas mostram que hoje as empresas investem apenas de 5% a 15% da sua verba de tecnologia em novas funcionalidades. Com SOA, essa verba pode ser melhor aproveitada”, explica Passos.
Mas quando o SOA deixará de ser um buzzword para se tornar uma realidade nas empresas? Há apenas um consenso a respeito desta virada: ela não será brusca, mas sim gradual.
Embora o instituto de pesquisa Forrester diga que 67% das empresas com 40 mil ou mais funcionários estejam implementando SOA neste ano, os analistas apontam que as companhias apostarão primeiro em projetos departamentais, restritos a determinados públicos dentro da empresa.
“Na hora que as empresas tiverem que revisitar o seu legado, se abrirá uma oportunidade para apostar na nova arquitetura. É a hora de mexer”, defende Azeredo.
"Como os benefícios do SOA são sentidos no longo prazo, não há uma percepção imediata de retorno, por isso o investimento não deve ser amplo. À medida que os códigos dos módulos de serviço comecem ser reaproveitados é que a empresa vai sentir o efeito positivo”, pondera Passos.
Já para os novos projetos, a arquitetura deve ser utilizada como paradigma, abrindo espaço para a maior penetração do SOA. Segundo o Gartner, em 2008 a arquitetura servirá como base para 80% dos novos desenvolvimentos e permitirá às organizações aumentar em 100% a reutilização de códigos.
Para Passos, a popularização do SOA deve ter um impacto direto na indústria de aplicações. “As empresas deixarão de vender produtos fechados e passarão a vender pacotes de serviços, que serão integrados à arquitetura”, prevê.
Na mesma linha, o Gartner prevê que o SOA vai operar uma transição do desenvolvimento focado em funcionalidades para o desenvolvimento voltado a funções de negócios, transformando a base instalada de software de um inibidor de mudanças para um facilitador.
“SOA nada mais é que um reflexo de uma mudança de cultura que permeia toda a empresa. As companhias cada vez mais enxergam as áreas internas como prestadores de serviços. O departamento de tecnologia já é visto como prestador de serviço. Nada mais natural do que os sistemas passarem a ser vistos como prestadores de serviços também”, conclui.
Publicado originalmente no endereço http://idgnow.uol.com.br
Ela está na lista das 10 tecnologias mais importantes para o Gartner em 2007, no centro do discurso dos fornecedores de aplicações e nos planos dos principais gestores de tecnolgoa do mundo corporativo. SOA, sigla em inglês para arquitetura orientada a serviços, é o que se conhece por buzzword - a palavra da moda - no mundo da tecnologia.
Na pratica, o que está por trás desta sigla é uma nova abordagem de software dentro das companhias. Na arquitetura orientada a serviços, o objetivo principal é atender necessidades de negócios, agrupando funções em “caixas” ou “módulos” que podem ser copiados e adaptados no futuro para outros fins e integrando, de forma transparente ao usuário, aplicações diversas da empresa, estejam elas espalhadas por departamentos (como um software de leilões usado pela área de compras) ou presentes em toda a organização (como um sistema de gestão empresarial). Os ganhos estão na flexibilidade e na economia com o desenvolvimento e na independência que a área de negócios ganha em relação ao departamento de tecnologia.
SOA, como indica o próprio nome, é uma arquitetura. Logo, envolve alguns elementos. Em uma analogia, é como se dentro de uma sala houvesse especialistas de todo mundo em culinária, e do lado de fora, o dono de um restaurante interessado em montar um cardápio misto.
No mundo da arquitetura de software tradicional, o dono do restaurante teria que ir a cada um desses especialistas - as aplicações isoladas - para pedir as sugestões de pratos, em seu idioma. Na melhor das hipóteses - supondo algum grau de integração - ele poderia pedir ao especialista em culinária italiana uma sugestão de prato que combinasse elementos da cozinha francesa. O chef italiano, por meio de um intérprete, conversaria então com o chef francês para ouvir suas sugestões, e devolveria então uma sugestão de prato ao dono do restaurante.
Trazendo isso para o mundo SOA, nosso dono do restaurante recorria a um único intérprete, capaz de falar o idioma de todos os chefs presentes na sala, e diria a ele: quero um prato franco-italiano. O intérprete responderia com a sugestão de prato pronta, e mais, se o dono do restaurante quisesse no futuro um prato ítalo-germânico, o intérprete aproveitaria o modelo de interação utilizado no primeiro caso adaptando-o ao segundo, para trazer uma resposta similar. Complicado?
Dentro da arquitetura SOA, esse intérprete, que na linguagem tecnológica é chamado de middleware, funciona como um orquestrador dos serviços. Nele estarão determinadas os comandos que serão enviados a cada aplicação, em que ordem, e os outputs que serão retirados de cada uma delas para que os dados e recursos distribuídos em cada aplicação voltem para o usuário como um único serviço.
Para desempenhar esta função de orquestrador, algumas empresas oferecem adaptadores universais, os chamados Enterprise Service Bus (ESB), que já vêm preparados para interagir com algumas aplicações comum dentro de uma empresa, como os bancos de dados, ERP, BI e CRM. “O ESB funciona como uma cola para as aplicações. É uma barra de serviços na qual os softwares vão sendo plugados, sem causar traumas para a empresa”, explica Luiz Cláudio Menezes, diretor geral da Progress Software Brasil.
Outro componente da arquitetura orientada a serviços é o uso de padrões de web services - entre eles Simple Object Access Protocol (SOAP) e Web Services Description Language (WSDL) -, que permitem a comunicação universal entre diferentes sistemas. “A interação entre arquiteturas distintas é fundamental para o SOA”, define Waldir Arevolo, analista do Gartner no Brasil. Se enxergarmos o middleware como maestro destes serviços, os web services são a batuta. Enquanto o middleware é a própria infra-estrutura, os web services são os condutores.
Por fim, na avaliação de Silvio Passos, diretor de soluções da Stefanini, os portais aparecem como um elemento importante - embora não obrigatório - da arquitetura, mostrando-se como a interface ideal - porque é altamente customizável - para a solicitação dos serviços pelos usuários. “É bom que exista, porque funciona como uma interface única e maleável”, opina o executivo.
A combinação dessas características oferece às empresas algumas vantagens, como uma visão mais abrangente dos seus processos de negócio, uma agilidade e uma flexibilidade maiores para fazer mudanças e adaptações aos sistemas de tecnologia que suportam as atividades da companhia - graças à modularidade e à granularidade dos serviços- e a capacidade de reaproveitar os serviços criados para uma área a outras.
“Isto é fundamental, porque não só reduz os custos de administração - já que você não precisa mais de um especialista para cada aplicação que compõe a sua infra-estrutura -, mas também aumenta a capacidade de inovação. Pesquisas mostram que hoje as empresas investem apenas de 5% a 15% da sua verba de tecnologia em novas funcionalidades. Com SOA, essa verba pode ser melhor aproveitada”, explica Passos.
Mas quando o SOA deixará de ser um buzzword para se tornar uma realidade nas empresas? Há apenas um consenso a respeito desta virada: ela não será brusca, mas sim gradual.
Embora o instituto de pesquisa Forrester diga que 67% das empresas com 40 mil ou mais funcionários estejam implementando SOA neste ano, os analistas apontam que as companhias apostarão primeiro em projetos departamentais, restritos a determinados públicos dentro da empresa.
“Na hora que as empresas tiverem que revisitar o seu legado, se abrirá uma oportunidade para apostar na nova arquitetura. É a hora de mexer”, defende Azeredo.
"Como os benefícios do SOA são sentidos no longo prazo, não há uma percepção imediata de retorno, por isso o investimento não deve ser amplo. À medida que os códigos dos módulos de serviço comecem ser reaproveitados é que a empresa vai sentir o efeito positivo”, pondera Passos.
Já para os novos projetos, a arquitetura deve ser utilizada como paradigma, abrindo espaço para a maior penetração do SOA. Segundo o Gartner, em 2008 a arquitetura servirá como base para 80% dos novos desenvolvimentos e permitirá às organizações aumentar em 100% a reutilização de códigos.
Para Passos, a popularização do SOA deve ter um impacto direto na indústria de aplicações. “As empresas deixarão de vender produtos fechados e passarão a vender pacotes de serviços, que serão integrados à arquitetura”, prevê.
Na mesma linha, o Gartner prevê que o SOA vai operar uma transição do desenvolvimento focado em funcionalidades para o desenvolvimento voltado a funções de negócios, transformando a base instalada de software de um inibidor de mudanças para um facilitador.
“SOA nada mais é que um reflexo de uma mudança de cultura que permeia toda a empresa. As companhias cada vez mais enxergam as áreas internas como prestadores de serviços. O departamento de tecnologia já é visto como prestador de serviço. Nada mais natural do que os sistemas passarem a ser vistos como prestadores de serviços também”, conclui.
Publicado originalmente no endereço http://idgnow.uol.com.br
quarta-feira, agosto 30, 2006
Livro livre sobre Open Source como estratégia de negócio
Por Henrique Meira
Um livro que descreve o que o open source é, discute razões de negócios para se usar o open source, e descreve como um projeto open source trabalha no dia-a-dia. Ele ajuda a decidir onde o open source é certo para o projeto, e, se for, quais passos devem ser tomados para proceder e alguns erros que devem ser evitados".
O livro está sob a licensa Creative Commons Attribution - NonCommercial. Ainda em inglês, e pode ser acessado pelo link: http://dreamsongs.com
Publicado originalmente no endereço http://www.dicas-l.com.br
Um livro que descreve o que o open source é, discute razões de negócios para se usar o open source, e descreve como um projeto open source trabalha no dia-a-dia. Ele ajuda a decidir onde o open source é certo para o projeto, e, se for, quais passos devem ser tomados para proceder e alguns erros que devem ser evitados".
O livro está sob a licensa Creative Commons Attribution - NonCommercial. Ainda em inglês, e pode ser acessado pelo link: http://dreamsongs.com
Publicado originalmente no endereço http://www.dicas-l.com.br
terça-feira, agosto 29, 2006
As fabricas de Software
Por Farmy Gonçalves Ferreira da Silva.
"Há algum tempo no Brasil temos convivido com as fabricas de software ou software houses como são conhecidas. Mas será que podemos conceitua-las como fabricas? Será que elas estão dentro desse modelo? Bom, novamente vamos ver a figura do engenheiro de sistemas, e de seu papel para que esse conceito seja implantado.
Bom como disse há algum tempo convivemos com as fabricas de software, com as tão famosas software houses, e em muitos casos convivemos com softwares de péssima qualidade.
Não é raro em nosso e-mail solicitarem profissionais com certificados de CMMI, ou com conhecimento de técnicas de qualidade como Scrum ou XP. Essa necessidade é um fator relevante párea este artigo afinal quem nunca viu um software de péssima qualidade, ou uma solução que não atendia as reais necessidades de nossos clientes.
A culpa é o prazo apertado, a analise mal feita, ou o domínio mínimo da linguagem pelo programador. Embora vários pontos podem ser vistos como culpados, toda software house sabe; que ela consome intensivamente a mão-de-obra, consumindo mais capital humano por valor produzido do que deveria se esperar de uma industria moderna.
A tendência é de aumentar a demanda por software, não pela qualidade dos mesmos, ou pela forma que são fornecidos, mas sim pelo valor mínimo que eles possam agregar ao cliente em si. Por isso, muitos deles correm o risco de investirem em uma solução.
Embora essa tendência seja crescente na próxima década, a demanda por software deva crescer exponencialmente, ainda trabalhamos como nos primórdios, técnicas de qualidade e metodologias para isso não foram adotadas pelo mercado de software e talvez por esse fato ainda não se pode chamar as software houses de fabricas de software.
Nesse momento perguntamos, o que vai mudar? E como se preparar para a mudança?
Na verdade eu acho que a pergunta mais pertinente é, como reestruturar as software houses para serem conhecidas como fabricas de software? Nesse momento vamos ver novamente uma figura muito conhecida por vocês em meus artigos, quem projeta uma software house é um engenheiro de software.
Parece absurdo, mas sim, é ele. E muitos vão dizer: “É um absurdo, para ser uma software house você precisa a penas conhecer bem o mercado e criar um software que atenda essa necessidade”. Sim eu direi, mas uma fabrica não funciona assim; para ser uma fabrica de software você precisa antes de tudo possuir a infra-estrutura de uma fabrica essa infra-estrutura pode ser definida como escopo, pois não é apenas especo físico, mas sim o somatório do espaço físico com a qualidade aplicada, é implementar técnicas da ISO9000 na infra-estrutura, utilizar modelos de papeis do RUP na definição dos setores e das equipes, criar a interoperabilidade entre os setores e criar a maturidade dos processos ordenados, documentados e implementados com as técnicas de PMI e CMMI. Mas diante de tantas técnicas o que mais conta é o business plan, e o recovery risk plan ou seja, seu plano de negócios e seu plano de riscos, afinal de contas quem não tem um bom plano de negócios não vai em frente, e quem não sabe os riscos que corre, não conhece o mercado que atua.
Na formação do profissional que quer ser arquiteto de software, ou engenheiro, existe uma diversidade na formação, com no artigo anterior fui questionado sobre como seria a formação desse profissional, deixo aqui a base da sua formação: multidisciplinar.
O Engenheiro deve conhecer, finanças muito bem, administração de empresas, amar, eu disse amar a tecnologia e os padrões de qualidade, conhecer protocolos e infra-estrutura e claro ser um bom analista de sistemas e de negócios.
As disciplinas que você deve cumprir para esta formação ficam a sua escolha. Mas para chegarmos ao patamar onde a produção de software seja vista como uma fabrica precisamos adotar os métodos de qualidade e principalmente a infra-estrutura que deve ser envolvida para atender a cada uma.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
"Há algum tempo no Brasil temos convivido com as fabricas de software ou software houses como são conhecidas. Mas será que podemos conceitua-las como fabricas? Será que elas estão dentro desse modelo? Bom, novamente vamos ver a figura do engenheiro de sistemas, e de seu papel para que esse conceito seja implantado.
Bom como disse há algum tempo convivemos com as fabricas de software, com as tão famosas software houses, e em muitos casos convivemos com softwares de péssima qualidade.
Não é raro em nosso e-mail solicitarem profissionais com certificados de CMMI, ou com conhecimento de técnicas de qualidade como Scrum ou XP. Essa necessidade é um fator relevante párea este artigo afinal quem nunca viu um software de péssima qualidade, ou uma solução que não atendia as reais necessidades de nossos clientes.
A culpa é o prazo apertado, a analise mal feita, ou o domínio mínimo da linguagem pelo programador. Embora vários pontos podem ser vistos como culpados, toda software house sabe; que ela consome intensivamente a mão-de-obra, consumindo mais capital humano por valor produzido do que deveria se esperar de uma industria moderna.
A tendência é de aumentar a demanda por software, não pela qualidade dos mesmos, ou pela forma que são fornecidos, mas sim pelo valor mínimo que eles possam agregar ao cliente em si. Por isso, muitos deles correm o risco de investirem em uma solução.
Embora essa tendência seja crescente na próxima década, a demanda por software deva crescer exponencialmente, ainda trabalhamos como nos primórdios, técnicas de qualidade e metodologias para isso não foram adotadas pelo mercado de software e talvez por esse fato ainda não se pode chamar as software houses de fabricas de software.
Nesse momento perguntamos, o que vai mudar? E como se preparar para a mudança?
Na verdade eu acho que a pergunta mais pertinente é, como reestruturar as software houses para serem conhecidas como fabricas de software? Nesse momento vamos ver novamente uma figura muito conhecida por vocês em meus artigos, quem projeta uma software house é um engenheiro de software.
Parece absurdo, mas sim, é ele. E muitos vão dizer: “É um absurdo, para ser uma software house você precisa a penas conhecer bem o mercado e criar um software que atenda essa necessidade”. Sim eu direi, mas uma fabrica não funciona assim; para ser uma fabrica de software você precisa antes de tudo possuir a infra-estrutura de uma fabrica essa infra-estrutura pode ser definida como escopo, pois não é apenas especo físico, mas sim o somatório do espaço físico com a qualidade aplicada, é implementar técnicas da ISO9000 na infra-estrutura, utilizar modelos de papeis do RUP na definição dos setores e das equipes, criar a interoperabilidade entre os setores e criar a maturidade dos processos ordenados, documentados e implementados com as técnicas de PMI e CMMI. Mas diante de tantas técnicas o que mais conta é o business plan, e o recovery risk plan ou seja, seu plano de negócios e seu plano de riscos, afinal de contas quem não tem um bom plano de negócios não vai em frente, e quem não sabe os riscos que corre, não conhece o mercado que atua.
Na formação do profissional que quer ser arquiteto de software, ou engenheiro, existe uma diversidade na formação, com no artigo anterior fui questionado sobre como seria a formação desse profissional, deixo aqui a base da sua formação: multidisciplinar.
O Engenheiro deve conhecer, finanças muito bem, administração de empresas, amar, eu disse amar a tecnologia e os padrões de qualidade, conhecer protocolos e infra-estrutura e claro ser um bom analista de sistemas e de negócios.
As disciplinas que você deve cumprir para esta formação ficam a sua escolha. Mas para chegarmos ao patamar onde a produção de software seja vista como uma fabrica precisamos adotar os métodos de qualidade e principalmente a infra-estrutura que deve ser envolvida para atender a cada uma.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
O Engenheiro de Software e a Gerencia de Projetos II
Por Farmy Gonçalves Ferreira da Silva.
"Seguindo a linha de raciocínio do artigo anterior, vamos observar que os projetos de TI são muito mais abrangentes do que pode ser percebido, a palavra chave é o “core business” da empresa e dentro de todas as atividades de uma empresa que procura ser líder no seu mercado, ou seja, obter lucro; ele deve implementar, ou ter implementado, dois projetos muito comentados até hoje: o ERP e o CRM. Aplicações desse tipo são tidas como cruciais pois muitas levam tempo, consomem altas cifras e no fim não atende ao objetivo almejado. SAP, IBM e MICROSOFT possuem os grandes medalhões nessa área por serem empresas já consolidadas no mercado de tecnologia, mas existem vários pequenos fornecedores com histórias de sucesso e boas opções.
Mas qual o papel do engenheiro de software num projeto desse porte? O que envolve um projeto dessa magnitude? Essas e outras perguntas precisam antes de alguns alicerces. Os conceitos sobre ERP podem ser lidos no artigo de nosso companheiro André Guedes os conceitos sobre BI podem ser obtidos no artigo da companheira Scheila Mello e do companheiro Ricardo Mansur. Depois de obtido esses conceitos, podemos discutir o que pode ser realizado pelo engenheiro de software, note que não me focarei no CRM pois ainda não existe um artigo sobre esse assunto que possa auxiliar no conceito básico do assunto, quem sabe não seja um próximo.
A primeira coisa a se saber é, as empresas não são criadas com um sistema de ERP em mente, mas sim um negócio, um ramo ou atividade. Dado este fato, os projetos de ERP são alcançados quando uma empresa atinge um determinado nível de vida e maturidade em gestão. Você deve dizer “maturidade nada, necessidade mesmo”, este é outro fator para a implementação de sistemas de ERP, e por estes motivos, vários problemas precisam ser visualizados. Com dissemos no artigo anterior, gerir projetos é um desafio que necessita mais do que o conhecimento de Tecnologia, e que muitos projetos são geridos por excelentes técnicos mais péssimos gerentes. Esse fator num projeto como o ERP e BI podem levar aos já muitos comentados fracassos dessa área.
Com você deve imaginar existe uma forma, ou melhor, metodologia que define como pensar nos passos da implementação de um sistema de ERP; é agora que entre em cena o nosso Engenheiro de software, afinal ele não é um analista de sistema, mas sim um gestor, um gerente de tecnologia. E entre outras responsabilidades ele precisa expor para a alta gerencia que um sistema de ERP, CRM e BI, geram uma mudança na forma de gerir e na filosofia da empresa, para isso precisa entre outras coisas contar com uma consultoria externa que traga experiência de sucesso e fracasso também, afinal ninguém aprende apenas com acertos. E junto com a consultoria realizar algumas fases para a implementação do projeto, sendo elas:
· Fase 1 – Raio-X
Esta é a fase do projeto, em que os processos e as práticas de negócio são analisados. É o momento em que a empresa é profundamente observada e quando é definida a necessidade de uma solução ERP.
· Fase 2 – Desenvolvimento
É nesse momento que uma aplicação é escolhida e configurada para uma empresa. Também são definidos o modelo de funcionamento da solução e outros aspectos do ambiente.
· Fase 3 – Teste
Aqui, a solução de ERP é colocada em ambiente de teste. É quando os erros e as falhas são identificados.
· Fase 4 – Treinamento
Todos os profissionais são treinados no sistema para saber como utilizá-lo antes da implementação ser concluída.
· Fase 5 – Implementação
O software de ERP é finalmente instalado na empresa e torna-se funcional aos usuários.
· Fase 6 – Avaliação
A solução de ERP é avaliada, observando-se o que é necessário melhorar e o que está ou não funcionando adequadamente. Essa é apenas uma avaliação geral do projeto ERP para referências futuras.
Observem que estas fases envolvem outras metodologias, e devem ser adotadas de forma repetitiva durante toda a vida do sistema de ERP, observe que a necessidade da consultoria se faz necessária principalmente na analise da empresa, pois visões diferentes convergem para um sucesso maior. Um ponto critico em todos os sistemas é o nível de conhecimento dos usuários, observe que a fase de treinamento se dá durante o projeto e não depois que ele esta implementado, afinal isso garante que quando concluído seus usuários já estejam capacitados para a sua plena utilização, por outro lado, nesta definição os testes acontecem durante a terceira fase e novamente a equipe de TI deve ser muito bem gerida e o engenheiro deve ter a capacidade de solucionar problemas como vícios da equipe de desenvolvimento e a influencia da consultoria externa. Uma solução adotada por algumas empresas foi utilizar uma segunda consultoria neste momento.
As tarefas que o engenheiro deve ter em mente quando definir um projeto de ERP são:
· Defina, em detalhes, o que será realizado.
· Liste o que se espera dos novos recursos.
· Combine o processo de implementação com a cultura empresarial.
· Defina as responsabilidades do fornecedor e as dos parceiros em contrato.
· Mantenha o gerenciamento da estrutura sob controle e reforce o comprometimento.
· Teste e treine.
Dessa forma, os projetos de ERP podem obter maior chance de sucesso, lembrando que o comprometimento da gerencia é imprescindível neste contexto, por isso n]ao só o Engenheiro de software como também um gerente empresarial deve estar completamente envolvido neste projeto. Afinal após a implementação de um sistema de ERP, a empresa começa a querer sistemas de apoio a decisão empresarial, os chamados BI “Business Inteligence”, neste caso a função maior do engenheiro é traduzir as necessidades da gerencia em softwares, manter a facilidade de uso e a integridade dos dados apresentados. Um sistema de BI não é tão simples como se pensa, envolvem múltiplas tecnologias e um bom projeto de integração entre os sistemas empresarias.
Um projeto de BI envolve a necessidade de demonstrar pra alta gerencia o impacto das relações transacionas ocorridas dentro do ERP, esses sistemas necessitam de interface simples e de disponibilidade imediata para a alta gerencia, é muito comum em um sistema de BI estar inserido um projeto de portal WEB, pois a facilidade de uso e a interface devem ser o mais amigável para o gestor, nessa fase o banco de dados adotado fica a toda a prova e a responsabilidade do engenheiro passa ser a de estar levantando todas as necessidades informacional da gerencia (relatórios, consultas, pesquisas, etc.) e traga a informação desejada pelo gestor para a tomada de decisão, é comum utilizar uma base de casos e trazer para o gestor o impacto da sua decisão anterior, dessa forma refletindo todo o passado da empresa.
Um projeto de BI começa no DW “Data Werehouse” ou nos departamentos da empresa, com DM “Data Marts”, entendem-se pelos sistemas transacionais e armazenam todos os processos do dia-a-dia da empresa, por este motivo o engenheiro de software precisa ter em sua formação o conhecimento empresarial, saber lidar e qual a informação de cada setor da empresa, ter a capacidade de analisar a sua integridade e validade, determinar o valor dessa informação para o sistema e para a empresa. Conhecimentos que precisam de formações não tradicionais, levanto o posicional para a formação multidisciplinar. Conhecimento de RH e psicologia, finanças e economia, tecnologia e empreendedorismo, contabilidade e direito, banco de dados e rede de computadores; das mais diversas áreas e para os mais diversos propósitos, afinal ele precisa compreender a empresa como um todo.
Não existe uma forma de se começar um projeto de BI, como disse acima, ele pode começar diretamente no DW, quando a empresa já possui seus dados consolidados e armazenados em um único lugar, ou pela definição passo a passo das necessidades departamentais de armazenamento histórico sobre suas atividades esses dados dão origem aos DM, que logo serão consolidados em um DW, o valor de cada informação deve ser considerado e analisado de acordo com a finalidade da empresa e sua cultura, por fim as tecnologias de acesso a essa informação devem ser pesquisadas. Aqui o engenheiro começa a trabalhar diretamente com os setores e com a equipe de TI, logo um membro da alta gerência deve estar inserido neste processo para que o valor de cada dado que componha a informação seja mensurado e forme um repositório informacional integro.
Vimos neste artigo, que gerir projetos não é só, definir o que o software deve ou não fazer, mas muitas vezes discutir e implementar novas metodologias na execução de uma função, compreender cada área da empresa, não esquecendo de citar marketing e relacionamento com os clientes, e saber como disponibilizar essa informação para a gerencia. Será que um analista de sistema tem essa capacidade? Será que um Administrador te essa capacidade? Cada um sabe qual o perfil do gerente de projetos que melhor cabe a sua empresa.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
"Seguindo a linha de raciocínio do artigo anterior, vamos observar que os projetos de TI são muito mais abrangentes do que pode ser percebido, a palavra chave é o “core business” da empresa e dentro de todas as atividades de uma empresa que procura ser líder no seu mercado, ou seja, obter lucro; ele deve implementar, ou ter implementado, dois projetos muito comentados até hoje: o ERP e o CRM. Aplicações desse tipo são tidas como cruciais pois muitas levam tempo, consomem altas cifras e no fim não atende ao objetivo almejado. SAP, IBM e MICROSOFT possuem os grandes medalhões nessa área por serem empresas já consolidadas no mercado de tecnologia, mas existem vários pequenos fornecedores com histórias de sucesso e boas opções.
Mas qual o papel do engenheiro de software num projeto desse porte? O que envolve um projeto dessa magnitude? Essas e outras perguntas precisam antes de alguns alicerces. Os conceitos sobre ERP podem ser lidos no artigo de nosso companheiro André Guedes os conceitos sobre BI podem ser obtidos no artigo da companheira Scheila Mello e do companheiro Ricardo Mansur. Depois de obtido esses conceitos, podemos discutir o que pode ser realizado pelo engenheiro de software, note que não me focarei no CRM pois ainda não existe um artigo sobre esse assunto que possa auxiliar no conceito básico do assunto, quem sabe não seja um próximo.
A primeira coisa a se saber é, as empresas não são criadas com um sistema de ERP em mente, mas sim um negócio, um ramo ou atividade. Dado este fato, os projetos de ERP são alcançados quando uma empresa atinge um determinado nível de vida e maturidade em gestão. Você deve dizer “maturidade nada, necessidade mesmo”, este é outro fator para a implementação de sistemas de ERP, e por estes motivos, vários problemas precisam ser visualizados. Com dissemos no artigo anterior, gerir projetos é um desafio que necessita mais do que o conhecimento de Tecnologia, e que muitos projetos são geridos por excelentes técnicos mais péssimos gerentes. Esse fator num projeto como o ERP e BI podem levar aos já muitos comentados fracassos dessa área.
Com você deve imaginar existe uma forma, ou melhor, metodologia que define como pensar nos passos da implementação de um sistema de ERP; é agora que entre em cena o nosso Engenheiro de software, afinal ele não é um analista de sistema, mas sim um gestor, um gerente de tecnologia. E entre outras responsabilidades ele precisa expor para a alta gerencia que um sistema de ERP, CRM e BI, geram uma mudança na forma de gerir e na filosofia da empresa, para isso precisa entre outras coisas contar com uma consultoria externa que traga experiência de sucesso e fracasso também, afinal ninguém aprende apenas com acertos. E junto com a consultoria realizar algumas fases para a implementação do projeto, sendo elas:
· Fase 1 – Raio-X
Esta é a fase do projeto, em que os processos e as práticas de negócio são analisados. É o momento em que a empresa é profundamente observada e quando é definida a necessidade de uma solução ERP.
· Fase 2 – Desenvolvimento
É nesse momento que uma aplicação é escolhida e configurada para uma empresa. Também são definidos o modelo de funcionamento da solução e outros aspectos do ambiente.
· Fase 3 – Teste
Aqui, a solução de ERP é colocada em ambiente de teste. É quando os erros e as falhas são identificados.
· Fase 4 – Treinamento
Todos os profissionais são treinados no sistema para saber como utilizá-lo antes da implementação ser concluída.
· Fase 5 – Implementação
O software de ERP é finalmente instalado na empresa e torna-se funcional aos usuários.
· Fase 6 – Avaliação
A solução de ERP é avaliada, observando-se o que é necessário melhorar e o que está ou não funcionando adequadamente. Essa é apenas uma avaliação geral do projeto ERP para referências futuras.
Observem que estas fases envolvem outras metodologias, e devem ser adotadas de forma repetitiva durante toda a vida do sistema de ERP, observe que a necessidade da consultoria se faz necessária principalmente na analise da empresa, pois visões diferentes convergem para um sucesso maior. Um ponto critico em todos os sistemas é o nível de conhecimento dos usuários, observe que a fase de treinamento se dá durante o projeto e não depois que ele esta implementado, afinal isso garante que quando concluído seus usuários já estejam capacitados para a sua plena utilização, por outro lado, nesta definição os testes acontecem durante a terceira fase e novamente a equipe de TI deve ser muito bem gerida e o engenheiro deve ter a capacidade de solucionar problemas como vícios da equipe de desenvolvimento e a influencia da consultoria externa. Uma solução adotada por algumas empresas foi utilizar uma segunda consultoria neste momento.
As tarefas que o engenheiro deve ter em mente quando definir um projeto de ERP são:
· Defina, em detalhes, o que será realizado.
· Liste o que se espera dos novos recursos.
· Combine o processo de implementação com a cultura empresarial.
· Defina as responsabilidades do fornecedor e as dos parceiros em contrato.
· Mantenha o gerenciamento da estrutura sob controle e reforce o comprometimento.
· Teste e treine.
Dessa forma, os projetos de ERP podem obter maior chance de sucesso, lembrando que o comprometimento da gerencia é imprescindível neste contexto, por isso n]ao só o Engenheiro de software como também um gerente empresarial deve estar completamente envolvido neste projeto. Afinal após a implementação de um sistema de ERP, a empresa começa a querer sistemas de apoio a decisão empresarial, os chamados BI “Business Inteligence”, neste caso a função maior do engenheiro é traduzir as necessidades da gerencia em softwares, manter a facilidade de uso e a integridade dos dados apresentados. Um sistema de BI não é tão simples como se pensa, envolvem múltiplas tecnologias e um bom projeto de integração entre os sistemas empresarias.
Um projeto de BI envolve a necessidade de demonstrar pra alta gerencia o impacto das relações transacionas ocorridas dentro do ERP, esses sistemas necessitam de interface simples e de disponibilidade imediata para a alta gerencia, é muito comum em um sistema de BI estar inserido um projeto de portal WEB, pois a facilidade de uso e a interface devem ser o mais amigável para o gestor, nessa fase o banco de dados adotado fica a toda a prova e a responsabilidade do engenheiro passa ser a de estar levantando todas as necessidades informacional da gerencia (relatórios, consultas, pesquisas, etc.) e traga a informação desejada pelo gestor para a tomada de decisão, é comum utilizar uma base de casos e trazer para o gestor o impacto da sua decisão anterior, dessa forma refletindo todo o passado da empresa.
Um projeto de BI começa no DW “Data Werehouse” ou nos departamentos da empresa, com DM “Data Marts”, entendem-se pelos sistemas transacionais e armazenam todos os processos do dia-a-dia da empresa, por este motivo o engenheiro de software precisa ter em sua formação o conhecimento empresarial, saber lidar e qual a informação de cada setor da empresa, ter a capacidade de analisar a sua integridade e validade, determinar o valor dessa informação para o sistema e para a empresa. Conhecimentos que precisam de formações não tradicionais, levanto o posicional para a formação multidisciplinar. Conhecimento de RH e psicologia, finanças e economia, tecnologia e empreendedorismo, contabilidade e direito, banco de dados e rede de computadores; das mais diversas áreas e para os mais diversos propósitos, afinal ele precisa compreender a empresa como um todo.
Não existe uma forma de se começar um projeto de BI, como disse acima, ele pode começar diretamente no DW, quando a empresa já possui seus dados consolidados e armazenados em um único lugar, ou pela definição passo a passo das necessidades departamentais de armazenamento histórico sobre suas atividades esses dados dão origem aos DM, que logo serão consolidados em um DW, o valor de cada informação deve ser considerado e analisado de acordo com a finalidade da empresa e sua cultura, por fim as tecnologias de acesso a essa informação devem ser pesquisadas. Aqui o engenheiro começa a trabalhar diretamente com os setores e com a equipe de TI, logo um membro da alta gerência deve estar inserido neste processo para que o valor de cada dado que componha a informação seja mensurado e forme um repositório informacional integro.
Vimos neste artigo, que gerir projetos não é só, definir o que o software deve ou não fazer, mas muitas vezes discutir e implementar novas metodologias na execução de uma função, compreender cada área da empresa, não esquecendo de citar marketing e relacionamento com os clientes, e saber como disponibilizar essa informação para a gerencia. Será que um analista de sistema tem essa capacidade? Será que um Administrador te essa capacidade? Cada um sabe qual o perfil do gerente de projetos que melhor cabe a sua empresa.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
O Engenheiro de Software e a Gerencia de Projetos
Por Farmy Gonçalves Ferreira da Silva.
Até o início da década de 90, a modernização do ambiente de tecnologia da informação era argumento suficiente para justificar investimentos em novos equipamentos e sistemas corporativos. Porém, nesses últimos 13 anos, a competição entre as empresas e a necessidade premente de redução de custos, aliada ao aumento de produtividade, derrubou os muros dos departamentos de informática e, com eles, a linguagem técnica dos seus profissionais.
A própria distância entre o mundo informatizado e o dos negócios tornou-se infinitamente menor, eliminando inclusive o termo "informática" do linguajar corporativo e colocando em evidência a Tecnologia da Informação ou TI. Em resumo, a utilização de ferramentas tecnológicas para o aperfeiçoamento da informação circulante dentro das empresas e delas com parceiros, fornecedores e clientes - corporativos ou individuais - tornou-se comum.
Esse movimento permitiu que todos os profissionais - não apenas aqueles mais experientes em TI - tivessem acesso aos novos recursos e também passassem a ser assediados por fornecedores e prestadores de serviços. As decisões de compra deixaram de ser exclusividade do líder de TI, sendo divididas com gerentes e diretores de outras áreas de negócio e justificadas, muitas vezes, perante um conselho executivo.
Se no passado, a TI era inquestionável, porque as corporações tinham mais dinheiro e menos recurso intelectual para por à prova as decisões dessa área, agora é quase que vital re-visitar o departamento e seus gastos, avaliando a importância da Tecnologia da Informação para o negócio. A TI passou a ser empurrada pelo “business” tendo a sua importância discutida com muito mais freqüência e profundidade.
Essa mudança foi a principal responsável pelo aparecimento de termos como o retorno do investimento (ROI), cujo objetivo é facilitar a aprovação de novos projetos, o acompanhamento da sua implementação e a medição dos resultados. Esses recursos permitem identificar, por exemplo, em quanto tempo um novo sistema devolve o seu custo aos cofres da corporação na forma de aumento de produtividade e melhoria de desempenho frente à concorrência.
Essa é uma das novas exigências ao profissional de TI, deixando pra traz o cargo máximo de analista de sistemas e trazendo a função de engenharia, pois neste momento o departamento de TI passa a ser colaborador direto do “core business” da empresa, ou seja, passa a gerir a solução desde o departamento de tecnologia até o caminhão que vai pra rua. Este nova tarefa precisa ser apoiada por ferramentas e metodologias, como a forma mais fácil de falar com a equipe de tecnologia é utilizar a sua linguagem, UML esta presente neste processo, mas como agregar a UML com uma metodologia e linguagem que toda a empresa consiga ler e falar? Bom neste momento tomamos carona na pratica mais adotada no mercado de gestão de projetos o PMI. Veremos neste artigo o que vem a ser PMI, onde ele se estende para a linguagem tecnológica de projetos UML e qual o Papel do “Engenheiro de Software”, ou Engenheiro de TI neste contexto.
Antes de tudo, a equipe de TI e a Alta gerenciam da empresa deveria definir o “business plan” (um plano de negócios), para ser possível identificar onde e quando o valor do investimento planejado será encontrado e o quê é essencialmente necessário para que o projeto obtenha sucesso.
Isso é importante para especificar objetivos, acordos com grandes acionistas da companhia e as pesquisas que se fazem necessárias. O case de negócio baliza inclusive como o escopo do projeto deve ser gerenciado e auxilia o refinamento dos processos que serão melhorados com a tecnologia. Em resumo, ele define como o sucesso acontecerá.
Após essa fase, entramos no processo do PMI, que nos diz que: “Na gerencia de projetos existe uma característica forte de interação”. Essas interações pode ser compreendidas como processos, ou etapas de um projeto, portanto no PMBOK, é descrito uma forma de relação entre estes processos ou etapas. Seguindo a seguinte ordem:
1. Processos de um projeto;
2. Grupos de um processo;
3. Interações entre os processos;
4. Adaptações das Interações entre os processos.
Seguindo essa idéia, podemos observar algumas semelhanças com as nomenclaturas da UML, o que facilita a documentação para a equipe de TI.
Então qual as habilidades para se gerir um projeto?
Muitas empresas colocam como diretores ou gerentes de projetos, seus funcionários mais antigos, especialistas altamente gabaritado em uma atividade fim, existem vários casos de sucesso, na verdade a experiência dentro da empresa conta como fator, mas não podemos garantir que um especialista conseguirá exercer as atribuições de um gerente. Numa grande maioria de casos a empresa perde um excepcional especialista e ganha um péssimo gerente.
O importante é que o papel do gerente de projetos não garante o sucesso do mesmo, mas sim a qualificação do profissional quanto a gerencia, desenvolver bem suas habilidades inerentes a esta tarefa, conhecer e aplicar boas técnicas de gerencia e as habilidades de:
· Comunicação;
· Organização;
· Elaboração de orçamentos;
· Solucionar problemas;
· Negociar e influenciar;
· Liderança;
· Formação de equipes e recursos humanos;
Com essas habilidades básicas, o gerente de projeto começa ser qualificado em sua função.
Agora vem as atribuições de um bom projeto, como vimos a cima, os projetos são formados por processos ou etapas, divididos em grupos, e alocados sob interações e adaptações de interações.
O Plano de negócios dá a base para todos os projetos dentro de uma empresa bem organizada, com base no plano de negocio, o gerente define o escopo do projeto junto com a alta gerencia e as áreas de apoio, define o orçamento e o ROI, aloca pessoas em grupos responsáveis por processos ou etapas, faz um plano de risco, um plano de contingência, e define as métricas a serem utilizadas para manter a qualidade e os prazos do projeto. A partir deste momento o projeto começa a ser gerido de acordo com esses planos.
Com o escopo definido, os analistas começam seus trabalhos, observe que os grupos por etapas são definidos pelo gerente e não pelo analista, se cada etapa do projeto já esta definida, a criação de um modelo de documentação fica muito mais fácil, afinal sabemos de antemão quem são os responsáveis, onde esta etapa será atingida e como deverá ser tratada.
É função do gerente ou engenheiro de sistemas definir nos riscos de cada processos (etapa), o custo e o plano de contingência, note que todas essas funções recaem sobre um individuo só, por isso definimos as atribuições desse papel como básicas afinal um bom gerente é generalista, líder, e tem influencia sobre a equipe. Desta forma, ele deve ser capas de traduzir toda a documentação gerada pela equipe de TI para a alta gerencia, como também traduzir todos os aspectos do projeto para a equipe de TI.
O controle de projetos é incremental e abre portas para diversas metodologias, por exemplo, o RUP, que atende a projetos com diversas equipes, documentando o papel do individuo dentro de cada equipe, suas atribuições, interações e prazos. Isso traz para o gestor de projetos uma gama muito grande de possibilidades de controle sobre o projeto, suas equipes e prazos. Desta forma aplica-se mais uma vez a formação do gerente de projetos, que deve definir também qual a metodologia a ser utilizada.
Por fim, gerir projetos requer do profissional, mais atribuições do que simplesmente o tempo de empresa, ou o conhecimento específico de uma tecnologia envolvida, a documentação e as interações são parte critica neste processo, e a capacidade de negociar e solucionar problemas é o fator que mais pesa na decisão sobre o gerente de projetos, afinal os prazos são diretamente afetados por estes parâmetros. O orçamento e o ROI justificam o projeto, mas não são garantidos, e as metodologias dependem diretamente da capacidade organizacional do gestor. Função fim do engenheiro de sistemas.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
Até o início da década de 90, a modernização do ambiente de tecnologia da informação era argumento suficiente para justificar investimentos em novos equipamentos e sistemas corporativos. Porém, nesses últimos 13 anos, a competição entre as empresas e a necessidade premente de redução de custos, aliada ao aumento de produtividade, derrubou os muros dos departamentos de informática e, com eles, a linguagem técnica dos seus profissionais.
A própria distância entre o mundo informatizado e o dos negócios tornou-se infinitamente menor, eliminando inclusive o termo "informática" do linguajar corporativo e colocando em evidência a Tecnologia da Informação ou TI. Em resumo, a utilização de ferramentas tecnológicas para o aperfeiçoamento da informação circulante dentro das empresas e delas com parceiros, fornecedores e clientes - corporativos ou individuais - tornou-se comum.
Esse movimento permitiu que todos os profissionais - não apenas aqueles mais experientes em TI - tivessem acesso aos novos recursos e também passassem a ser assediados por fornecedores e prestadores de serviços. As decisões de compra deixaram de ser exclusividade do líder de TI, sendo divididas com gerentes e diretores de outras áreas de negócio e justificadas, muitas vezes, perante um conselho executivo.
Se no passado, a TI era inquestionável, porque as corporações tinham mais dinheiro e menos recurso intelectual para por à prova as decisões dessa área, agora é quase que vital re-visitar o departamento e seus gastos, avaliando a importância da Tecnologia da Informação para o negócio. A TI passou a ser empurrada pelo “business” tendo a sua importância discutida com muito mais freqüência e profundidade.
Essa mudança foi a principal responsável pelo aparecimento de termos como o retorno do investimento (ROI), cujo objetivo é facilitar a aprovação de novos projetos, o acompanhamento da sua implementação e a medição dos resultados. Esses recursos permitem identificar, por exemplo, em quanto tempo um novo sistema devolve o seu custo aos cofres da corporação na forma de aumento de produtividade e melhoria de desempenho frente à concorrência.
Essa é uma das novas exigências ao profissional de TI, deixando pra traz o cargo máximo de analista de sistemas e trazendo a função de engenharia, pois neste momento o departamento de TI passa a ser colaborador direto do “core business” da empresa, ou seja, passa a gerir a solução desde o departamento de tecnologia até o caminhão que vai pra rua. Este nova tarefa precisa ser apoiada por ferramentas e metodologias, como a forma mais fácil de falar com a equipe de tecnologia é utilizar a sua linguagem, UML esta presente neste processo, mas como agregar a UML com uma metodologia e linguagem que toda a empresa consiga ler e falar? Bom neste momento tomamos carona na pratica mais adotada no mercado de gestão de projetos o PMI. Veremos neste artigo o que vem a ser PMI, onde ele se estende para a linguagem tecnológica de projetos UML e qual o Papel do “Engenheiro de Software”, ou Engenheiro de TI neste contexto.
Antes de tudo, a equipe de TI e a Alta gerenciam da empresa deveria definir o “business plan” (um plano de negócios), para ser possível identificar onde e quando o valor do investimento planejado será encontrado e o quê é essencialmente necessário para que o projeto obtenha sucesso.
Isso é importante para especificar objetivos, acordos com grandes acionistas da companhia e as pesquisas que se fazem necessárias. O case de negócio baliza inclusive como o escopo do projeto deve ser gerenciado e auxilia o refinamento dos processos que serão melhorados com a tecnologia. Em resumo, ele define como o sucesso acontecerá.
Após essa fase, entramos no processo do PMI, que nos diz que: “Na gerencia de projetos existe uma característica forte de interação”. Essas interações pode ser compreendidas como processos, ou etapas de um projeto, portanto no PMBOK, é descrito uma forma de relação entre estes processos ou etapas. Seguindo a seguinte ordem:
1. Processos de um projeto;
2. Grupos de um processo;
3. Interações entre os processos;
4. Adaptações das Interações entre os processos.
Seguindo essa idéia, podemos observar algumas semelhanças com as nomenclaturas da UML, o que facilita a documentação para a equipe de TI.
Então qual as habilidades para se gerir um projeto?
Muitas empresas colocam como diretores ou gerentes de projetos, seus funcionários mais antigos, especialistas altamente gabaritado em uma atividade fim, existem vários casos de sucesso, na verdade a experiência dentro da empresa conta como fator, mas não podemos garantir que um especialista conseguirá exercer as atribuições de um gerente. Numa grande maioria de casos a empresa perde um excepcional especialista e ganha um péssimo gerente.
O importante é que o papel do gerente de projetos não garante o sucesso do mesmo, mas sim a qualificação do profissional quanto a gerencia, desenvolver bem suas habilidades inerentes a esta tarefa, conhecer e aplicar boas técnicas de gerencia e as habilidades de:
· Comunicação;
· Organização;
· Elaboração de orçamentos;
· Solucionar problemas;
· Negociar e influenciar;
· Liderança;
· Formação de equipes e recursos humanos;
Com essas habilidades básicas, o gerente de projeto começa ser qualificado em sua função.
Agora vem as atribuições de um bom projeto, como vimos a cima, os projetos são formados por processos ou etapas, divididos em grupos, e alocados sob interações e adaptações de interações.
O Plano de negócios dá a base para todos os projetos dentro de uma empresa bem organizada, com base no plano de negocio, o gerente define o escopo do projeto junto com a alta gerencia e as áreas de apoio, define o orçamento e o ROI, aloca pessoas em grupos responsáveis por processos ou etapas, faz um plano de risco, um plano de contingência, e define as métricas a serem utilizadas para manter a qualidade e os prazos do projeto. A partir deste momento o projeto começa a ser gerido de acordo com esses planos.
Com o escopo definido, os analistas começam seus trabalhos, observe que os grupos por etapas são definidos pelo gerente e não pelo analista, se cada etapa do projeto já esta definida, a criação de um modelo de documentação fica muito mais fácil, afinal sabemos de antemão quem são os responsáveis, onde esta etapa será atingida e como deverá ser tratada.
É função do gerente ou engenheiro de sistemas definir nos riscos de cada processos (etapa), o custo e o plano de contingência, note que todas essas funções recaem sobre um individuo só, por isso definimos as atribuições desse papel como básicas afinal um bom gerente é generalista, líder, e tem influencia sobre a equipe. Desta forma, ele deve ser capas de traduzir toda a documentação gerada pela equipe de TI para a alta gerencia, como também traduzir todos os aspectos do projeto para a equipe de TI.
O controle de projetos é incremental e abre portas para diversas metodologias, por exemplo, o RUP, que atende a projetos com diversas equipes, documentando o papel do individuo dentro de cada equipe, suas atribuições, interações e prazos. Isso traz para o gestor de projetos uma gama muito grande de possibilidades de controle sobre o projeto, suas equipes e prazos. Desta forma aplica-se mais uma vez a formação do gerente de projetos, que deve definir também qual a metodologia a ser utilizada.
Por fim, gerir projetos requer do profissional, mais atribuições do que simplesmente o tempo de empresa, ou o conhecimento específico de uma tecnologia envolvida, a documentação e as interações são parte critica neste processo, e a capacidade de negociar e solucionar problemas é o fator que mais pesa na decisão sobre o gerente de projetos, afinal os prazos são diretamente afetados por estes parâmetros. O orçamento e o ROI justificam o projeto, mas não são garantidos, e as metodologias dependem diretamente da capacidade organizacional do gestor. Função fim do engenheiro de sistemas.
Publicado originalmento no endereço: http://www.profissionaisdetecnologia.com.br
segunda-feira, agosto 28, 2006
Construindo On-line sua Distribuição GNU/Linux customizada
Por José Messias Alves da Silva
Muitos já devem ter se deparado ao instalar várias distribuições GNU/Linux que nem todos os pacotes embutidos na distribuição são utilizados ou são necessários, o que normalmente só acarreta um mau uso do espaço em disco, que fica sendo ocupado por softwares que raramente ou nunca serão utilizados.
Seria muito interessante que pudéssemos escolher os pacotes a serem incluídos em uma distribuição GNU/Linux antes que tivéssemos que baixá-la, o que também economizaria tempo e uso de conexão, adaptando a distribuição às nossas reais necessidades.
Pois bem, isso é exatamente o que faz o site Instalinux, que nos fornece opções para criarmos nossa própria distribuição, selecionando apenas o que realmente precisamos. A princípio, podemos criar um perfil de distribuição selecionando os pacotes a serem inseridos, esquema de particionamento e, por fim, incluir um script final de pós-instalação. Para criar a ISO, decide-se qual a distribuição GNU/Linux será utilizada para a construção e, logo em seguida, mais alguns detalhes de configuração da isso. Ao se concluir a seleção, será disponibilizada para o download um imagem ISO da distribuição escolhida. Pode-se escolher entre as várias distribuições GNU/Linux (Fedora Core, Debian, SuSE e Ubuntu Linux).
Este site apresenta-se bastante interessante para aqueles que possuem link pequeno (como conexão discada) e para os que desejam fazer uma remasterização de sua distribuição GNU/Linux predileta.
Publicado originalmento no endereço: http://www.dicas-l.com.br
Muitos já devem ter se deparado ao instalar várias distribuições GNU/Linux que nem todos os pacotes embutidos na distribuição são utilizados ou são necessários, o que normalmente só acarreta um mau uso do espaço em disco, que fica sendo ocupado por softwares que raramente ou nunca serão utilizados.
Seria muito interessante que pudéssemos escolher os pacotes a serem incluídos em uma distribuição GNU/Linux antes que tivéssemos que baixá-la, o que também economizaria tempo e uso de conexão, adaptando a distribuição às nossas reais necessidades.
Pois bem, isso é exatamente o que faz o site Instalinux, que nos fornece opções para criarmos nossa própria distribuição, selecionando apenas o que realmente precisamos. A princípio, podemos criar um perfil de distribuição selecionando os pacotes a serem inseridos, esquema de particionamento e, por fim, incluir um script final de pós-instalação. Para criar a ISO, decide-se qual a distribuição GNU/Linux será utilizada para a construção e, logo em seguida, mais alguns detalhes de configuração da isso. Ao se concluir a seleção, será disponibilizada para o download um imagem ISO da distribuição escolhida. Pode-se escolher entre as várias distribuições GNU/Linux (Fedora Core, Debian, SuSE e Ubuntu Linux).
Este site apresenta-se bastante interessante para aqueles que possuem link pequeno (como conexão discada) e para os que desejam fazer uma remasterização de sua distribuição GNU/Linux predileta.
Publicado originalmento no endereço: http://www.dicas-l.com.br
Assinar:
Postagens (Atom)
