Novidades Tecnológicas

Fiquei abismado com a notícia de desenvolvimento de um cartão de crédito onde passaríamos a simplesmente falar ao invés de digitar senhas de identificação de segurança.

"Engenheiros baseados em Santa Mônica- EUA desenvolveram um protótipo de cartão de crédito que oferece reconhecimento de voz embutido e exige que o usuário que fale uma password antes de desbloquear o cartão.
O protótipo é baseado inicialmente em uma identificação audível codificada que é enviada a um servidor online. A idéia é verificar que o cartão atual está na mão do seu dono, em lugar de qualquer outra pessoa. ( Como isto seria garantido???)

Atualmente, o protótipo é tão pequeno quanto um cartão de crédito, mas tem a espessura três vezes maior que os atuais cartões de crédito.
Os engenheiros esperam realizar o encolhimento do tamanho até as densidades dos atuais cartões de crédito normais, inclusive com uma bateria não-substituível que seria capaz de permitir até dez transações por dia durante dois anos."
Mais detalhes você pode ler na New Scientist

Vocês já imaginaram isto no nosso país? O Caos seria instalado!

O cara quando estiver rouco não tira dinheiro nem faz compra nenhuma, ou alguém com dons de imitação de voz provavelmente conseguiria sacar com seu cartão. Ou um seqüestro relâmpago, bastaria fazer o coitado simplesmente falar a senha, apesar de ter de levar o mesmo para frente do terminal do banco!

Então a gente imagina aqueles que hoje mal conseguem operar uma caixa 24 horas, que passam 5.000 vezes o cartão, erram a senha, e outras coisinhas mais, agora estariam então berrando a sua identificação na frente de um caixa 24 horas com uma fila imensa atrás deles.

Para nós isto não vai dar certo mesmo. Isto mostra que os engenheiros americanos apesar de tecnicamente avançados não conhecem nada sobre as culturas e costumes de outras civilizações, principalmente na América Latina



Posted by Felipe Machado em Quinta-feira, Abril 22, 2004

Comentários:

Metodologias de Desenvolvimento e Gestão Empresarial

Todo profissional da área de desenvolvimento tem pouca em certos casos nenhuma preocupação com a utilização de metodologias, padrões e regras para a realização de um projeto de sistemas. Junte-se a isto o fato de que o empresariado brasileiro, o qual em sua maioria é mais dono de empresa do que empresário e empreendedor e tem como padrão não gostar de abrir a mão, e acredita firmemente que sistemas não agregam valor são simplesmente despesas, continua-se sem investimentos sérios em TI direcionados à busca de qualidade de resultado em que a premissa básica não seja o tempo.

Temos assistido a muitas empresas contratarem fornecedores de consultoria ou equipes de desenvolvimento direcionadas para uma determinada tecnologia, ou para uma realização específica, porém sem a existência de um objetivo de resolver um problema de negócios, o qual tem objetivos e metas a serem atingidas, e que necessitam de um estudo prévio e detalhado das necessidades para que se atinjam estes objetivos com qualidade.

Hoje existe uma cultura de TI em muitas empresas mal direcionada, onde se criam ilusões de que por ter uma página na WEB e um sistema em, por incrível que pareça ainda em Clipper ou FoxPro, que atende às atividades da empresa, independentemente dos remendos, bacalhaus e falhas periódicas, ela tem tudo o que precisa. Embora pareça um exagero, isto existe no Brasil e muito. Somente quando acontece o colapso dos sistemas em uso ou realizados de forma precária é que existe a busca por tecnologia e metodologia, mas de forma desorganizada e pouco objetiva. Então se inicia o desenvolvimento baseado em Tempo, é necessário substituir o velho por novo em curto prazo (e só o tempo interessa) e neste ínterim muita coisa fica para depois (para nunca mais).

Nas empresas de médio porte devido à complexidade de projetos empresariais, muito pouco compreendida pelos ditos empresários a tentativa de economizar dinheiro com pessoal não qualificado só tem um resultado final a médio e curto prazo: acabar dando tudo errado e a criação de limitadores ao crescimento da própria empresa como negócio em si.

Evidentemente é vital para o sucesso e crescimento de uma organização empresarial, que ela tenha pelo menos uma equipe central formada de profissionais altamente qualificados.
E isto vale mais ainda para a área crítica de apoio à gestão de negócios e de gestão do conhecimento que é o novo papel de TI nos dias de hoje.
A execução de projetos de sistemas urge em adoção e aplicação de metodologia para o desenvolvimento dos mesmos, mas urge também investimentos na pesquisa e estudo destas mesmas metodologias e não o pensamento de que se contratando profissionais recém saídos das fraldas (universidade), entregando-se a eles uma metodologia recomendada seja suficiente para a eficiência de resolução de um projeto.
Quando se fala em documentação de projetos de sistemas, o som das palavras parece que causa imediatas reações de repulsa nos gestores, não tão alta nos de TI (que ainda não aprenderam justificar custos e gastos com documentação de sistemas), mas nos gestores administrativos do negócio, porque significa tempo gasto, gasto com o que eles acham não agrega nada a não ser tempo de projeto, e acaba levando à famosa customização da metodologia, com eliminação de documentação não tão importante. Já começa um projeto de forma errada e sem visão de futuro, manutenção evolução e etc.
A existência de equipes de profissionais com experiência em utilização de metodologias é útil, mas não garante por si a eficácia da execução de um projeto, pois é necessário existir uma base de conhecimentos do negócio em si que não é passada através de simples entrevistas de levantamento, pois os detalhes importantes muitas vezes se perdem nestas.
Entretanto se a esta equipe forem agregados desenvolvedores iniciantes (recém-formados) diminui-se consideravelmente a necessidade de investimento em cursos e treinamentos.

Quando este pessoal qualificado não existir disponível dentro da própria empresa, vale a pena considerar a contratação de uma consultoria de curto prazo no início do projeto, de empresas ou indivíduos com experiência comprovada, e com bagagem de análise de negócios (indústria, varejo, atacado, distribuição, financeira, contábil etc) porque isto não se ensina em poucos meses de empresa.
Esta consultoria pode ser relativamente cara, mas pode resultar num investimento prudente, que evitará futuros problemas e poderá dar um grau de excelência e resultado ao projeto considerável.

Frisando, é importante que um projeto inicie bem. A qualidade do pessoal envolvido no design e na elaboração do projeto será especialmente importante.
Estas fases estabelecem a arquitetura de informação do negócio e estabelece práticas que garantirão que o projeto siga sem problemas até o final, lembrando que podem, se mal realizadas, resultar em problemas persistentes que não podem ser resolvidos com a simples inclusão de mais pessoal à medida que o projeto vai atrasando ou enfrenta problemas de satisfação.

Estes conselhos simplesmente essenciais devem ser conhecimento primário de qualquer gerente de projeto, mas principalmente deveriam fazer parte do processo de gestão de qualquer empresa, e não somente limitados à área de TI e seus gestores. Porém o que vemos em nosso país seja no Sul, Sudeste ou qualquer outra região que nada disto acontece, a exceção de grandes organizações, mas estas são caso a parte de discutirmos, pois muito se fala nelas, mas pouco também se faz.

O que acontece no país é que em um projeto interno, onde o resultado do projeto é um sistema que seria usado apenas dentro da empresa a equipe é formada por seja lá quem esteja relativamente disponível e tem que resolver todos os problemas sozinho e nunca tem a regalia de um treinamento, pesquisa ou de uma consultoria externa seja para auxiliar e orientar na arquitetura do projeto ou para auxílio em uma tecnologia nova ainda sem domínio, logo desconhecida. Procura-se normalmente um curso rápido, e barato, ou abre-se a mão um pouco e o desenvolvedor compra livros (mais de um é difícil) e estuda a nova tecnologia ou metodologia.

O problema é que a simples existência de uma consultoria também não é fator de nenhuma garantia, pois basta estar no mercado para conhecer o perfil de atuação da grande maioria, as quais alocam aos seus clientes (também por questão de custo e lucro) equipe composta de pessoas que se muito fizeram, fizeram um projeto de faculdade envolvendo esta tecnologia, e para completar sem nenhuma vivência na área de negócios.

Não que eu queira ser o profeta do apocalipse, porém não vejo fora dos livros e das universidades nenhuma preocupação com a correta utilização de tecnologias e metodologias no desenvolvimento de sistemas, e ainda com um fato mais preocupante, estamos vendo uma busca sempre desenfreada por novas metodologias.

A pergunta que eu gostaria de ver respondida com sinceridade é:

Você já realizou um projeto em que foi realmente utilizada uma metodologia e a documentação do mesmo está completa e teve resultado? Nos prazos?

Qual a solução para este paradoxo de tempo e técnica?


Treinar não somente os desenvolvedores nas metodologias, mas apresentá-las, discipliná-las para os gestores de negócios e de TI, pois somente assim teremos um caminho para resultados em que não conte somente o prazo dado à primeira versão do sistema e sim ao ciclo de vida do mesmo, produzindo resultado para o negócio e não para a área de TI.

Com a compra da Metodologia, pela inserção sanguínea da mesma nos gestores, provocando que estes troquem a sua participação meramente hierárquica por um efetivo comprometimento com o cumprimento de metas de negócios, sim porque o projeto de um sistema nada mais é do que uma meta de negócio, e não uma tarefa simples da organização


Posted by Felipe Machado em Quarta-feira, Abril 21, 2004

Comentários:

Classes Objetos X ER

Para permitir um processo de mapeamento entre sistemas baseados em objetos e bases de dados relacionais, foram propostas diversas idéias que convergiram para o conceito de Camada de Persistência.

Conceitualmente, uma Camada de Persistência de Objetos é uma biblioteca que permite a realização do processo de persistência (isto é, o armazenamento e manutenção do estado de objetos em algum meio não-volátil, como um banco de dados) de forma transparente.

Graças à independência entre a camada de persistência e o repositório utilizado, também é possível gerenciar a persistência de um modelo de objetos em diversos tipos de repositórios, teoricamente com pouco ou nenhum esforço extra.

A utilização deste conceito permite ao analista trabalhar como se estivesse em um sistema completamente orientado a objetos ¿ utilizando métodos para incluir, alterar e remover objetos e uma linguagem de consulta para SGBDs Orientados a Objetos, comumente a linguagem OQL, para realizar consultas que retornam coleções de objetos instanciados. Mas destaque-se somente em um ambiente de SGBDs Orientados a Objetos e não no ambiente tradicional de SGBDs Relacionais.

As vantagens decorrentes do uso de uma Camada de Persistência no desenvolvimento de aplicações orientadas a objetos são evidentes: a sua utilização isola os acessos realizados diretamente ao banco de dados da aplicação, bem como centraliza os processos de construção de consultas e operações de manipulação de dados em uma camada de objetos inacessível ao programador.
Este encapsulamento de responsabilidades garante maior confiabilidade às aplicações e permite que, em alguns casos, o próprio SGBD ou a estrutura de suas tabelas possam ser modificados, sem trazer impacto à aplicação nem forçar a revisão e recompilação de códigos.

Porém deixar o programador atuar sem acesso a uma camada de objetos pode provocar erros de desconhecimento da estrutura de banco de dados sobre a qual ele opera suas instruções, levando a erros conceituais de projeto de consultas e regras de negócio.

Hoje existem diversos utilitários que permitem uma independência de código SQL nas aplicações orientadas a objetos e escritas em JAVA, por exemplo. Estes aplicativos realizam o acesso e manipulação do banco de dados através da inserção somente das condições de validação e ou seleção de dados, não envolvendo o programador em altos conhecimentos de SQL, por exemplo.
De qualquer maneira existe a necessidade de não simplesmente traduzirmos diretamente em um script SQL de criação de banco de dados, o modelo de classes de um projeto OO, pois não nos permite nenhuma interação do mundo real de negócios com a persistência que iremos utilizar, que é um banco de dados relacional. Isto provoca a existência de mapeamento de objetos em um modelo de dados Entidade Relacionamento.

Para permitir a correta persistência de objetos em um banco de dados relacional, alguma coisa deve ser feita no tocante à forma como os dados serão armazenados.

Ao transpor-se um objeto para uma tabela relacional, os atributos do mesmo a princípio são mapeados em colunas desta tabela.

Também é importante destacar que, em muitas vezes, os atributos de um objeto não devem ser obrigatoriamente uma coluna em uma tabela.

Como exemplo, podemos citar atributos que são o valor total de alguma coisa: pois este dado poderia ser armazenado no objeto para fins de consulta, mas mantê-lo no banco de dados simplesmente não seja interessante, por tratar-se de um valor que pode ser obtido através de processamento de uma consulta.

Além disso, existem casos onde um atributo pode ser mapeado para diversas colunas, pois é definido no modelo de forma genérica sem a preocupação com composição de atributos como é realizado no modelo relacional (exemplos incluem endereços completos, nome dividido em ¿primeiro nome¿ e ¿sobrenome¿ no banco de dados) ou vários atributos que podem ser mapeados para uma mesma coluna (prefixo e número de telefone, por exemplo).

A transposição do modelo de classes para o modelo relacional tem como objetivo final, a criação da base de dados do sistema, coerente com a modelagem da fase de análise e para isto devemos seguir um conjunto de regras que irão permitir a construção ou tranposição do modelo de classes para um modelo lógico e físico entidade-relacionamento coerente e aderente às regras de negócios para as quais foi desenhada e projetada uma aplicação.


Posted by Felipe Machado em Terça-feira, Abril 20, 2004

Comentários:

Lançamento

Amigos a Editora Érica relançou o meu livro sobre Projeto de Data Warehouse , agora em edição totalmente revisada e estendida, com novos capítulos sobre metadados, roteiro de modelagem multidimensional e com maior enfoque nas tecnologias envolvidas no processo de Data Warehousing.

Com nova capa o livro vem a substituir o anterior que já possuia uma didática leve e simples para entendimento dos conceitos ali apresentados.

Neste livro continuo a apresentar a visão conceitual de um star schema, onde podemos dizer que o caminho das pedras está indicado, de forma a quem o ler possa estabelecer os pontos de referência de como realizar o processo de modelagem de fatos, dimensões e métricas, partindo da análise das necessidades executivas dos fatos que são analisados em janelas de tempo.

Boa leitura a todos que desejarem conhecer de forma não acadêmica e sem rebuscados a Tecnologia de Data Warehouse.

Posted by Felipe Machado em Terça-feira, Abril 20, 2004

Comentários: