Erros a evitar na interface com o usuário de aplicações web para smartphones e tablets

Está cada vez mais complicado projetar e implementar sistemas para a Web. Já era problemático por causa da infinidade de versões de navegadores, cada um com sua visão particular de como representar os padrões definidos por HTML e CSS. Agora, a popularização de smartphones e tablets vem acrescentar ainda mais variáveis à equação pois esses aparelhos estão chegando ao mercado com uma imensa variedade de resoluções de tela - além, claro, de muitos fabricantes terem suas próprias versões de navegadores exclusívas para dispositivos móveis.

Outro fator introduzido por esses dispositivos é a forma de interagir com o usuário. Eles normalmente são touch screen, o que significa que não há um ponteiro de mouse para nortear a navegação - ela é feita através de toques com os dedos e o usuário é livre pra tocar onde bem entender. Isso certamente traz novas preocupações aos desenvolvedores.

Mesmo assim, desenvolver com HTML e CSS ainda é a melhor opção se você quer que seu sistema possa ser utilizado em uma gama mais ampla de dispositivos. A alternativa seria criar aplicações exclusivas para um determinado aparelho mas aí seu sistema ficará restrito a ele já que cada fabricante tem um SDK próprio.

Segue abaixo a tradução de parte de uma matéria publicada no site Infoworld.com sobre os erros mais comuns cometidos por quem desenvolve para Web focando esse cenário caótico de dispositivos. A matéria original completa em inglês pode ser acessada neste link.

Erro de interface Web 1: Uso de efeitos em elementos sob o cursor do mouse
Em algum momento, desenvolvedores web se apaixonaram pela ideia de destacar áreas da página ou só exibir uma conteúdo quando o usuário passar com o cursor do mouse sobre um componente específico. O problema para smartphones e tablets deveria ser óbvio: quando não há um cursor de mouse, não há forma de se passá-lo sobre as tais áreas.

Isso não significa que você deva evitar o uso desses efeitos. Mas, para cada efeito de destaque ou de exibição de conteúdo associado à posição do cursor do mouse, deveria haver um outro evento acionado pelo toque e que fizesse essencialmente a mesma coisa para aqueles usuários que dispõe de telas sensíveis ao toque. Usuários de smartphones não deveriam ser penalizados com uma nova carga da página para cada nível de navegação só por que você projetou seus menus para funcionarem exclusivamente com um mouse.

Erro de interface Web 2: Usar widgets e controles customizados
Projetistas adoram dar uma aparência exclusiva aos seus botões e outros widgets. Mas, padrões de interface gráfica diferem de uma plataforma para outra, e, quando controles não são prontamente identificáveis e acessíveis em cada dispositivo, a usabilidade fica sofrível.

Barras de rolagem customizadas são um exemplo particularmente notável. Ocasionalmente, os projetistas sobrepõem os controles padrões usando JavaScript, substituindo-os por outros widgets mais elegantes, leves e visualmente mais atraentes. O problema para usuários de tablets é duplo: não só widgets minúsculos são mais difíceis de se alcançar com o dedo como também usuários de tablets não usam as barras para produzir uma rolagem; eles simplesmente arrastam o dedo pela tela. Forçá-los a usar seu controle customizado só deixa sua interface capenga.

De modo similar, não dê como certa a presença de qualquer dispositivo de entrada. Caixas de diálogo, por exemplo, deveriam ter sempre algum controle visualmente identificável para fechá-las. Smartphones e tablets até podem tecnicamente possuir um teclado mas raramente vêm com uma tecla Escape.

Erro de interface Web 3: Ter muitas áreas com rolagem
Visualizar websites em telas pequenas frequentemente significa ter que fazer alguma rolagem para vê-la por inteiro. Como mencionado antes, entretanto, lembre-se que usuários de tablets fazem a rolagem arrastando o dedo pela tela. e não através de um componente visual em particular. Quando você divide a página em múltiplos painéis, cada um podendo ser rolado de forma independente, sua interface gráfica pode rapidamente se tornar um campo minado. Uma parte do conteúdo pode rolar num arrastar de dedo e outra parte rolar em sequência, dependendo de onde o dedo do usuário tocou primeiro na tela. Melhor manter o layout o mais simples possível ou, no mínimo, ter certeza de que há margens de um bom tamanho para garantir que o usuário possa escolher com segurança qual painel deve ser rolado ou, ainda, se quer rolar a página toda.

Erro de interface Web 4: Ter um layout de texto inflexível.
Inúmeros projetistas já me explicaram o layout de seus websites em termos precisos das medidas em pixels e regras de tipografia suiças. Se isto nunca foi boa prática para a web - onde usuários podem ajustar a janela do navegador e até mesmo trocar o tamanho das fontes à vontade -, é especialmente uma péssima ideia se você quer que seu site seja visualizado em smartphones.

O navegador Android, por exemplo, tem por padrão um modo em que tentará adequar o comprimento de uma coluna de texto para que caiba no comprimento de tela do aparelho, independente de quaisquer especificações CSS existentes na página web. Se você não levar isso em conta e esperar que todos os elementos visuais se alinhem exatamente do mesmo jeito que num navegador no desktop, você acabará deixando os usuários de smartphones com grandes áreas contendo apenas espaços em branco, o que efetivamente poderá esconder alguns controles e tornar a interface obscura.

Erro de interface Web 5: Fazer assunções sobre o formato da tela.
Um web designer se vangloriou para mim de que ele gosta de estar na vanguarda da tecnologia, sendo esta a razão para que ele projetasse sites que ficam com a melhor aparência nos mais modernos monitores widescreen de LCD. Mas, mesmo que você desconsidere as pessoas que usam monitores mais antigos, você não pode estar na vanguarda da tecnologia se ignorar usuários de dispositivos móveis.

Muitos smartphones podem automaticamente intercambiar entre os modos porta-retrato (vertical) e paisagem (horizontal), dependendo de como o usuário está segurando o aparelho. Além disso, alguns usuários odeiam a função de intercambiar e a desabilitam - caso no qual é melhor você esperar que eles tenham escolhido o mesmo modo para o qual seu site foi desenhado. Fazer assunções sobre o formato de uma página funciona bem no mundo da impressão, mas é uma péssima ideia na web, onde você não sabe o tamanho do papel.

Erro de interface Web 6: Carregar muitas imagens de antemão
Que dó dos pobres usuários de smartphone: não só o acesso deles à internet não é tão rápido quanto a conectividade terrestre como cada vez mais operadoras de celular estão limitando o uso de dados e também impondo taxas extras para o acesso excedente. Smartphones também têm limitação na capacidade de memória. Enquanto faz sentido usar JavaScript para carregar antecipadamente uma sequência de imagens para um slideshow em navegadores no desktop, isso é um tanto quanto grosseiro para com usuários de dispositivos móveis - mais ainda se as imagens são projetadas para aparecer somente quando o usuário passa o ponteiro do mouse sobre um determinado componente - o que, é claro, usuários de tablets não poderão fazer de qualquer maneira.

Erro de interface Web 7: Usar Flash
Odeio dizer isto, mas Flash ainda não tem lugar em dispositivos móveis. Notadamente, o iOS dos aparelhos da Apple não suporta conteúdo em Flash, mas mesmo os aparelhos Android que realmentes suportam Flash oferecem um desempenho apenas medíocre. Pior, aplicações Flash apresentam os problemas de interface expostos anteriormente com mais frequência do que os sites HTML puros. Sinto muito, fãs da Adobe: com o advento do HTML 5, os dias do Flash na web estão contados.

Mais Informações
7 Web UI mistakes to avoid for smartphones and tablets

Sua solução SaaS é multi-tenant ?

A ABC71 está finalizando uma versão SaaS de seu ERP e um parceiro interessado nos perguntou se tínhamos estruturado uma solução multi-tenant já que para ele esta era uma questão importante. No contexto de aplicações publicadas como serviço na internet - o SaaS - "tenant" diz respeito a infraestrutura alocada num servidor e que é destinada a suprir a demanda de cada Cliente da aplicação web.

Assim, uma aplicação multi-tenant é aquela capaz de administrar essa infraestrutura com o menor custo possível, sem que isso afete a performance, a escalabilidade ou a segurança da solução como um todo. Em outras palavras, a aplicação consegue gerenciar a adesão de novos Clientes enquanto garante a segurança dos dados (para que um Cliente não acesse os dados dos outros), a escalabilidade (para que a infraestrutura suporte o aumento de carga inerente a novas adesões) e a responsividade do serviço (para que os acessos dos Clientes ao serviço sejam atendidos num tempo adequado).

Tendo tais considerações em mente, a primeira característica de uma solução SaaS multi-tenant é que ela deve ter um única instalação no servidor, com todos os Clientes compartilhando o mesmo ponto de entrada para a aplicação. Do ponto de visto do fornecedor da aplicação, há uma implicação muito importante para essa decisão: é preciso manter apenas uma instalação, o que reduz custos com espaço (hardware) e simplifica a criação do ambiente inicial para novos Clientes. Do ponto de vista do usuário, a simplificação garante agilidade para que o serviço esteja plenamente disponível logo após a adesão dele ter sido efetivada. Isto é, nenhuma outra providência tem que ser tomada pelo Cliente ou pelo Fornecedor para que todo o ambiente esteja pronto para operação. Esta é uma característica marcante de soluções SaaS.

Isso nos remete à segunda parte da definição: como garantir segurança, escalabilidade e responsividade da solução ? Obviamente, é preciso começar com o planejamento de uma boa infraestrutura de hardware que comporte o movimento esperado para o site. Mas não só. É nescessário ainda ter seu projeto de software preparado adequadamente, mesclando técnicas de programação com uma implementação apropriada do banco de dados. A implementação do banco de dados, aliás, merece uma atenção extra para que se possa equilibrar os requisitos já citados com a facilidade de criação do ambiente para cada novo Cliente.

Uma proposta é manter uma única base de dados que diferencie quais registros pertencem a qual Cliente. Isto pode ser feito através de um código de identificação que seja único por Cliente, o que implica necessariamente que cada tabela do sistema deve guardar essa identificação e que todas as operações devem ser levadas a cabo informando-se esse código. Caso contrário, o sistema teria uma grave falha de segurança, com Clientes enxergando dados uns dos outros. Esse tipo de solução é retratada na figura abaixo:

Porém, esse solução embute algumas restrições. Como todos os Clientes compartilham o mesmo banco de dados, fica difícil entregar uma cópia isolada dos dados de um Cliente caso ele solicite. Pela mesma razão, se torna complexo dispor de ferramentas que deem muita liberdade ao Cliente - como um construtor de relatórios ou algo que permita a ele submeter consultas diretamente ao banco.

Um outro aspecto importante pra se preocupar nesta solução é o modo como as consultas (queries) são montadas. Um sistema como um ERP costuma ter operações que envolvem grande massa de dados - cálculo de custos ou execução do MRP, por exemplo. Dependendo de como as consultas são montadas, a tabela pode entrar em lock, comprometendo a experiência dos demais usuários da aplicação Web. Por isso, para esse cenário a melhor opção é a criação de um banco de dados separado para cada novo Cliente.

Com o banco isolado, podemos facilmente enviar ao Cliente um cópia de backup apenas com os dados específicos dele. Ferramentas mais elaboradas também se tornam mais simples de se implementar pois não precisam embutir inteligência extra para bloquear o acesso a dados de outros Clientes que estejam na mesma tabela. Criar um novo banco para cada Cliente não é um processo complexo, podendo ser executado automaticamente com scripts. Por fim, essa é uma solução escalável pois o próprio gerenciador de banco de dados pode ser preparado para fazer o balanceamento de carga, inclusive alocando novos bancos em locais distintos se isso for necessário.

A imagem abaixo ilustra essa nova abordagem:

Uma vez que o ponto de entrada é o mesmo pra todos os Clientes, um pequeno banco auxiliar (ou outro mecanismo semelhante) tem que ser implementado para direcionar as requisições ao banco de dados correto. Mas isso praticamente não causa impacto na performance da solução.

Após essa discussão, podemos considerar que o contrário de multi-tenant é algo com um multi-instance, onde cada novo Cliente é associado a um ambiente completo exclusivo para si. Isto é, ele acessa sua própria instalação do sistema, com sua própria versão da aplicação, configurações, pastas e banco de dados. Em um ambiente SaaS, este tipo de solução de infraestrutura pode rapidamente tornar o negócio inviável já que ela implica em custo maior para comportar instalações de todos os Clientes. Além disso, o multi-instance não escala tão bem.

Todas as variáveis apresentadas aqui foram levadas em conta quando a ABC71 planejou sua solução SaaS. Os links abaixo nos forneceram outras informações sobre o conceito de multi-tenant e uma visão mais abrangente sobre estratégias de planejamento do banco de dados :

Mais Informações
Architecture Strategies for Catching the Long Tail, Multi-Tenant Data Architecture

Um novo paradigma: Programação Orientada a Aspectos

As ferramentas de modelagem de sistemas disponíveis para os Arquitetos de Software evoluem em paralelo com as técnicas de programação - quando um conceito é introduzido numa ferramenta, linguagens de programação rapidamente o incorporam também. Nos tempos em que o DFD (Diagrama de Fluxo de Dados) reinava, a programação de computadores era majoritariamente procedural. Isto é, os programas eram construídos com instruções sequenciais que emulavam o fluxo de dados definido pelo Diagrama, utilizando linguagens como o COBOL, Clipper ou Pascal. Hoje, as linguagems de programação comerciais mais usadas são calcadas no conceito de classes - Java, .Net, Delphi, etc. - e os sistemas são modelados frequentemente usando Diagramas de Classes e outras ferramentas que constituem a UML (Unified Modeling Language).

Essa forma de trabalho, no entanto, obriga o projetista a estabelecer relações entre certas classes que possuem pouco ou nada em comum, resultando em modelagens por vezes confusas, complicadas de se dar manutenção. Para ilustrar essa questão, imagine que você está modelando um sistema com operações que serão tratadas como transações no banco de dados.

Neste sistema, haverá operações para movimentação de estoque (com saída de quantidade de um depósito e a respectiva entrada no depósito destino), para registrar contabilizações (envolvendo uma ou mais contas contábeis para débito e crédito) e para efetuar pagamentos a fornecedores. Distingue-se neste cenário a necessidade de modelagem de diversas classes de objetos: item de estoque, conta contábil, movimento de estoque, contabilização, fornecedor, entre outros. Há ainda claramente uma entidade que deve controlar as transações no banco de dados para garantir que as alterações comandadas numa operação sejam tratadas como um bloco único. Embora nada tenham em comum, tanto movimentos de estoque quanto pagamentos a fornecedores devem ser contabilizados. Um diagrama de classes que ilustre essas relações ficará confuso por misturar conceitos de movimentação de itens e de pagamentos. A situação tende a piorar se surgirem outras operações que precisem ser contabilizadas. E do ponto de vista da programação, modificações na classe de contabilização afetarão todas as outras classes, exigindo que estas também sejam revisadas.

Recursos que permeiam várias classes de um sistema, vinculando mesmo aquelas que implementam regras conceitualmente distantes, são chamados de cross-cutting. Outros exemplos de recursos assim: criação de logs de operações, auditoria em alteração de dados, níveis de permissão de acesso a dados, autorização para executar operações, tratamento de exceções, etc. Melhorar a solução para esse tipo de recurso é a proposta da Programação Orientada a Aspectos (POA), onde o código que implementa os recursos cross-cutting são retirados das classes de negócio e inseridos em módulos próprios - os Aspectos. O código das regras de negócio fica mais limpo e alterações no funcionamento dos recursos cross-cutting passam a ser centralizadas no Aspecto.

A POA depende ainda de um mecanismo que permita vincular a execução dos códigos do Aspecto à execução das regras de negócio. A solução proposta pela POA é centrado no modelo de pontos de ligação (Join Points). Tal modelo é definido por 3 características: o momento em que o código poderá ser executado - chamado de join point -, uma forma de especificar esses momentos e uma forma de especificar o código que deve ser executado em cada momento.

Um ponto de ligação pode ser encarado como um evento que ocorre no código da regra de negócio - marcado pela execução de um determinado método ou pela alteração no valor de uma propriedade, por exemplo. Criar pontos de ligação significa, portanto, indicar quais desses eventos devem ser monitorados pelo Aspecto, usando para isso estruturas chamadas de pointcuts. Os pointcuts se valem de uma sintaxe especial para possibilitar a indicação de quais métodos e propriedades dispararão a execução do código relativo a um ponto de ligação. Ao código que será executado pelo Aspecto quando um ponto de ligação é encontrado dá-se o nome de Advice.

Assim como as Classes, Aspectos também podem conter variáveis internas (membros) e ter heranças para especializar seu comportamento, adequando-o a uma função mais específica. Voltando ao exemplo das operações dado no início deste post, uma solução usando Aspectos seria criar um Aspecto base para tratar transações com o banco de dados. Isso implica a criação de um ponto de ligação para apontar o início da função que realiza a operação, momento em que o advice desse ponto de ligação deve tomar providências para garantir a existência de uma transação no banco de dados. Outro ponto, ao final da operação, deve encerrar a transação. Para cuidar das transações que precisem ser contabilizadas faríamos uma herança desse Aspecto e introduziríamos o código necessário num dos pontos de ligação já estabelecidos. Nesta herança, indicaríamos como pointcuts apenas as classes expressando regras passíveis de serem contabilizadas.

A experiência mais bem sucedida para popularização da POA por enquanto é uma extensão da linguagem Java criada pelo Centro de Pesquisas da Xerox que tem o nome de AspectJ. Trata-se de um projeto open source disponível na Fundação Eclipse. Há ainda algumas bibliotecas voltadas para C#, disponíveis na forma de frameworks. O Delphi Prism - IDE para programação na plataforma .NET usando a linguagem Delphi - incorporou uma implementação para uso de POA em sua versão 2010 usando para isso recursos do próprio .NET. Veja aqui um exemplo de uso com a sintaxe do Delphi.

Tudo o que foi apresentado aqui não poderia ser resolvido apenas com uso de classes? Sim, poderia. Poderíamos até mesmo implementar tudo em uma solução exclusivamente procedural, se desejássemos. O ponto aqui é que as ferramentas até então existentes podem ser melhoradas para resolverem de forma mais eficiente determinados problemas. Uma nova filosofia está sendo amadurecida no campo da análise de sistemas e da programação e, mais cedo ou mais tarde, as linguagens também terão que evoluir para acompanhá-la consistentemente.

Mais Informações
Aspect Oriented Programning na Wikipedia, Extensão AspectJ, Frameworks AOP para C#, Programação Orientada a Aspectos com Delphi Prism

Os benefícios intangíveis dos cursos de MBA

por Bianca Machado Branco*

A proliferação dos cursos de MBA (Master of Business Administration) é um fato. Porém, o que ocorre, ultimamente, é que o público dessa modalidade de pós-graduação também está se modificando, abrangendo não apenas a alta gerência como também profissionais do nível operacional.

Cada vez mais os cursos de MBA vêm sendo procurados por jovens profissionais, muitos recém-formados, com pouco ou nenhum tempo de carreira, porém com expectativas muito altas em relação ao retorno em termos financeiros que o curso trará para eles. Esses profissionais são a chamada geração Y, aqueles nascidos na década de 80, que possuem uma característica marcante: o imediatismo. Eles iniciam um MBA pouco tempo depois de concluída a graduação e esperam com isso uma inserção imediata no mercado de trabalho ou um reconhecimento rápido das empresas onde atuam - como um aumento salarial significativo, uma promoção de cargo ou outra forma de compensação financeira.

Entretanto, a especialização por si só não oferece garantias de sucesso. A experiência de um MBA pode representar valor agregado sob o ponto de vista das empresas, mas o retorno que o profissional trará à empresa demanda um longo tempo para que se possa medir. A companhia não recompensará um título por si só, mas os resultados que o profissional trouxer após aplicar no seu dia-a-dia o know-how absorvido no curso.

Expectativas financeiras à parte, um MBA também trás benefícios intangíveis, como:

Incremento da bagagem profissional, ampliada por meio de conhecimentos de várias áreas de negócios. Essa bagagem é o que ajudará o profissional a falar a língua do cliente e a se inserir em projetos mais desafiantes;

Aprender a pensar "fora da caixa". O currículo do MBA tradicional ensina a interpretar balanços contábeis, planos de marketing e elaborar um planejamento estratégico. Essas são ferramentas úteis para um entendimento de como se desenvolvem as operações de um departamento ou de uma empresa. Quanto melhor a compreensão por parte do profissional sobre os movimentos da empresa, melhor o seu posicionamento estratégico dentro dela;

Visão de oportunidades de negócios, que pode fazer com que o profissional ajude a alavancar o negócio da empresa (e com isso se destacar), ou até mesmo empreender um negócio por conta própria;

Networking, permitindo a troca de experiências com profissionais de várias áreas, trazendo visibilidade ao profissional no mercado e podendo, até mesmo, gerar futuras indicações;

Valorização do profissional no mercado, o que significa manutenção da empregabilidade.

Os benefícios tangíveis, como crescimento na carreira, serão consequências da experiência prática profissional, que vale mais que qualquer título. O que o MBA fará pelo profissional é muní-lo de um ferramental diferenciado, para que ele possa encontrar soluções que agreguem valor ao negócio da empresa.

*Bianca Machado Branco possui MBA em Gestão Empresarial e formação em Análise de Sistemas. Trabalha com tecnologia da informação desde 1998. Atualmente é coordenadora de projetos na ABC71.

TI Verde e a Educação à Distância

por Bianca Machado Branco*

Tecnologia da Informação ecologicamente correta não é uma onda passageira. A demanda por tecnologia “verde”, ou seja, tecnologia que reduza as emissões de carbono na atmosfera e permita o consumo de energia eficiente, já é uma realidade.

Em 2009 surgiram as primeiras certificações de Gestores de TI com especialização em projetos verdes como a GIM – Green IT Management - ao passo que grandes players adotaram o SAAS (Software como Serviço) como uma estratégia verde. Baseada na tecnologia SOA (Arquitetura Orientada a Serviços), essa modalidade de venda de software reduz os custos fixos para os clientes, na medida em que elimina as licenças de uso e introduz o pagamento de uma taxa que varia conforme a utilização.

As companhias desenvolvedoras de software estão se adaptando às novas exigências do mercado, partindo de atitudes simples como: realização de vídeo conferências a fim de reduzir o uso de meios de transportes poluentes (minimizando o deslocamento de pessoal); desenvolvimento de softwares que exijam menos capacidade do hardware, ou seja, gastem menos energia por demandarem menos tempo de operação e, ainda sejam capazes de configurar impressoras que imprimam folhas em frente e verso, economizando papel.

Outra medida verde que vem tomando corpo e crescendo é o emprego da educação à distância (EAD) para treinamento de funcionários e clientes, permitindo a atualização constante de ambos e uma melhor gestão do tempo de cada um. Para se ter ideia, as possibilidades da EAD nesse sentido vão muito além das usuais. Em uma consultoria de implantação de sistema de gestão, por exemplo, com o uso de EAD, esta atividade pode ser realizada sem a presença física do consultor, o que agiliza as implementações do software e permite a rápida intervenção da empresa desenvolvedora em qualquer eventualidade. Flexibilidade e redução de custos são palavras-chave na modalidade EAD.

Em termos de qualificação de colaboradores, a EAD é uma ferramenta extremamente útil. O segmento de TI sofre com a carência de profissionais e, para suprir a demanda por mão-de-obra qualificada as desenvolvedoras estão criando pólos de tecnologia próximos aos centros de excelência em ensino, muitas vezes distantes de suas matrizes. Nesses casos, a EAD é fundamental para viabilizar o treinamento destes funcionários, sem comprometer as operações atuais.

A EAD também é uma excelente alternativa para estreitar o relacionamento com os clientes, principalmente porque existe uma tendência de migração de empresas da região Sudeste para o Norte, Nordeste ou interior por conta dos incentivos propostos pelo PAC (Programa de Aceleração do Crescimento). A pulverização de clientes atuais e potenciais para regiões mais distantes pode gerar custos de deslocamentos de pessoal e perda de agilidade no atendimento, o que afeta a logística de distribuição dos fornecedores de software e onera a prestação de serviços. Essa situação, entretanto, não representa ameaça para as empresas desenvolvedoras que já empregam a EAD como estratégia de atendimento.

Sendo assim, para pensarmos no desenvolvimento sustentável de uma companhia, é preciso que novas formas de fazer negócio, soluções, treinamentos e relacionamento com os clientes sejam colocados em pauta. Os benefícios que a TI verde e o uso de EAD oferecem às companhias são objetivos e precisos.

Por isso, é fato que em breve, todas as empresas que não aderirem à redução de poluentes e de consumo energético terão que responder aos seus acionistas, parceiros e reguladores, assim como aos clientes e à opinião pública. Porém, com a adoção de algumas das medidas citadas é possível a essas mesmas empresas reduzirem seus custos operacionais,e ainda valorizarem a sua própria imagem no mercado.

*Bianca Machado Branco possui MBA em Gestão Empresarial e formação em Análise de Sistemas. Trabalha com tecnologia da informação desde 1998. Atualmente é coordenadora de projetos na ABC71.

Mais Informações
Green IT Management white papers, SOA, SaaS

Certificados de Qualidade em TI

por Bianca Machado Branco*

O mercado consumidor está começando a exigir dos fornecedores de software e de serviços garantias de desempenho e do nível de serviço na forma de certificações de qualidade como CMMI (Capability Maturity Model Integration), MPS-BR (Melhoria de Processos do Software Brasileiro) e ISO 20000. Essas certificações atestam que o fornecedor utiliza as melhores práticas do mercado.

Segundo o Standish Group, empresa que realiza desde 1994 um levantamento sobre projetos de software, há uma taxa de 77% de fracasso em projetos de desenvolvimento de software. De acordo com a pesquisa, um projeto de software custará em média 45% mais caro do que o contratado, terá um atraso de 63% sobre o prazo previsto para entrega e não terá 33% das funcionalidades encomendadas.

Nesse contexto, surgiram as certificações, uma espécie de selo de qualidade, com o objetivo de descrever as melhores práticas no desenvolvimento de software e também em serviços. Porém, de acordo com o Standish Group, cerca de 2/3 das implementações de certificações não atingem os objetivos, o que explica o ceticismo de muitos diretores de TI, que não acreditam na certificação como modalidade que agrega valor ao produto.

As empresas com CMMI, uma das principais certificações para desenvolvimento de software, são de 30% a 70% mais caras, dependendo do nível da certificação. Porém, muitos clientes não enxergam os benefícios que a certificação traz para suas respectivas instituições, acreditando tratar-se de um modismo de mercado ou um argumento para criar demanda.

Entretanto, já existe um movimento no sentido de exigir que os fornecedores de TI atestem sua competência através dos certificados. Empresas como Coca-Cola, Tetra Pack e Volkswagen já estão exigindo pelo menos o nível 3 do CMMI, que pode chegar até o patamar 5.

O selo CMMI parece estar se consolidando como a principal certificação para as empresas de TI, tendo ganhado popularidade entre os gerentes e diretores de TI das empresas clientes, os principais influenciadores na compra de software.

Outra tendência recente é a ISO 20000, primeiro padrão reconhecido internacionalmente para gerenciamento de serviços de TI. Até o momento, cerca de 100 companhias ao redor do mundo já têm essa certificação, que agora começa a surgir no Brasil. Acredita-se que o conceito vá se popularizar em médio prazo e será considerado um diferencial. Futuramente, acredita-se que a ISO 20000 poderá se tornar um pré-requisito para as empresas de tecnologia.

Além dessas, a MPS-BR, a versão brasileira da CMMI, vem crescendo cada vez mais no mercado e já tem sido exigida pelo governo federal em licitações públicas. O ponto positivo dessa certificação é que ela é mais fácil de ser obtida em virtude do custo ser bem menor que o da CMMI, além de ser menos complexa que esta última. Trata-se de uma boa alternativa para empresas de pequeno e médio porte.

Por fim, as empresas devem pesquisar constantemente quais certificações são mais reconhecidas no mundo corporativo e optar por aquela que seja mais aderente aos processos da empresa e que traga visibilidade junto aos clientes atuais e potenciais. Opções não faltam.

*Bianca Machado Branco possui MBA em Gestão Empresarial e formação em Análise de Sistemas. Trabalha com tecnologia da informação desde 1998. Atualmente é coordenadora de projetos na ABC71.

Mais Informações
CMMI, MPS-BR, ISO 20000

A tecnologia Flash encurralada ?

Desde que foram anunciados os novos recursos que seriam incorporados ao padrão do HTML na sua versão 5, vem aumentando o calor da discussão a respeito de tecnologias para criação de aplicações ricas para Internet (RIA), notadamente o Adobe Flash devido a sua ampla utilização.

O que antes era apenas uma questão de percepção dos especialistas ganhou peso de guerra declarada em abril, quando a Apple modificou o acordo de licenciamento para desenvolvedores de aplicações do IPhone 4.0, incluindo termos que na prática proibem o desenvolvimento em Flash nesse ambiente. Antes desse evento, a Apple já sinalizava descontentamento com o Flash ao não implementá-lo nos navegadores de seus gadgets (IPhones, IPods e o recente IPad).

Algumas das alegações da Apple fazem bastante sentido, como o fato do Flash não ter sido projetado para equipamentos touch screen, cada vez mais comuns hoje. A principal queixa, no entanto, é de que se trata de uma tecnologia proprietária - apesar da Apple não ficar atrás quando o assunto é tecnologia proprietária - e que a internet deveria ser território dominado por padrões abertos (HTML, CSS e JavaScript, por exemplo). Veja aqui reportagem da MacWorld sobre a carta aberta publicada por Steve Jobs.

E a Apple não está sozinha. A Microsoft (que tem um concorrente do Flash, o Silverlight) fez coro com as opiniões da Apple, afirmando que o futuro da internet está no HTML5 e que o Flash é parte da cultura da rede hoje mas não terá necessariamente o mesmo espaço no futuro (veja aqui). Outros fabricantes também estão se posicionando, dando seu apoio ao HTML5 de uma forma ou outra, como é o caso do Scridbd, uma rede social de leitura (aqui).

A Adobe, no entanto, continua acreditando firmemente em sua tecnologia. Além de defendê-la rebatendo as críticas da Apple, a Adobe anunciou que abandonaria o desenvolvimento de uma ferramenta que permitiria aos aparelhos da Apple executarem animações em Flash. Eles também vêm desde o começo do ano lançando novas versões de seus produtos baseados em Flash, como é o caso do Flash Builder 4 lançado em março desse ano. É uma ferramenta visual para desenvolver aplicações ricas para internet usando o Flash; veja uma avaliação da ferramenta neste link (em inglês).

Outra ferramenta, essa voltada para designers, é o Flash Catalyst CS5, no mercado desde abril. Ela proporciona aos designers criarem interfaces gráficas para aplicações Web e projetarem interatividade sem que seja necessário escrever código de programação. Mais informações podem ser encontradas aqui.

Como já disse em outra ocasião, pode até ser que o Flash venha a cair mas isso deve demorar um bocado para acontecer visto que há muitos desenvolvedores que dominam e gostam dele. Também há ainda muita coisa boa feita com essa tecnologia - vídeos, infográficos, animações, aplicações, jogos, etc. - e abandonar isso ou reescrevê-las com outra linguagem custa e leva tempo.

Mais Informações
Plataforma Flash, What to expect from HTML5