Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina

quinta-feira, 31 de janeiro de 2008

Dicas para ter compatibilidade nos browsers

Estava lendo o artigo do Fugita e pensei comigo mesmo: - Porque todo mundo sempre quer matar o Internet Explorer?
A pergunta não foi difícil de responder: Compatibilidade.

Quando desenvolvemos com Padrões Web, a primeira coisa que aprendemos é a odiar o Internet Explorer. Sei disso porque a frase mais falada nos meus cursos e em algumas palestras é: Não funciona no IE6. Ou: Se funcionasse no IE6.
Grande parte dos problemas de desenvolvimento de um site se deve pela falta de compatibilidade entre browsers.

Infelizmente não posso dizer: - Esqueça o IE6.
Ele é até hoje o browser mais usado, - não por mérito, mas isso é outra história - portanto, viveremos por um tempo com a falta de compatibilidade e alguns bugs não só do IE, mas de todos os browsers. Mesmo assim, há maneiras de minimizar os problemas:
Graceful Degradation

Para quem não sabe, isso é uma premissa do desenvolvimento com Padrões Web. Este assunto é bem interessante. A idéia é a seguinte: existem diversos dispositivos, aparelhos e softwares que podem acessar sua aplicação web ou site. Acontece que cada destes meios tem sua limitação, seja uma limitação de software ou hardware. Mesmo assim, seu site precisa funcionar quando for acessado por eles. Se você faz um site com PNG semi-transparente, que não funciona no IE6, os usuários do IE6, precisam utilizar o site sem problemas. Se você faz seu site em flash e o camarada entra no site com algum SmartPhone que não funciona flash, seu site precisa funcionar de alguma maneira alternativa.

A moral da história é a seguinte: faça o site funcionar da melhor maneira possível para aquele meio de acesso. Você precisa dar a melhor experiência para aquele usuário. Mesmo que tenha que abrir mão de algumas coisas, como design, por exemplo. O importante é que funcione.

Logo, o usuário de desktop terá uma melhor experiência que o usuário de Smartphone. Mesmo assim, o usuário de smartphone terá a melhor experiência que o seu aparelho pode lhe trazer.
Entenda e estude a solução dos bugs

É mentira que apenas o IE6 tem bugs. Mas é fato que o IE6 é campeão em número de bugs. O remédio para contornar os bugs é sempre saber mais de uma técnica para fazer a mesma coisa. Acredite, sempre há mais de uma alternativa com CSS.

O mais importante é conhecer soluções simples, que não lhe tragam trabalho posteriormente. Se você sabe que determinada combinação de propriedades pode gerar algum tipo de bug em determinado browser, tente uma maneira alternativa. Crie, invente, converse com outras pessoas, pesquise. Se mesmo assim não houver jeito, use CSS HACK, mas apenas em ÚLTIMO CASO!
CSS HACKS, use com moderação

Vou ser sincero: CSS HACK pode fazer sua vida virar o inferno. Não estou brincando. Use com moderação. Com cuidado, com inteligência.

Grande parte dos desenvolvedores não gostam de perder seu precioso tempo tentando entender o problema para achar uma solução inteligente. Acabam usando CSS HACK par a resolver um problema imediato e acabam se acostumando mal. Sou a favor de perder tempo procurando a solução, mesmo naquelas horas apertadas e que cliente respira fundo no seu cangote. Você vai trabalhar duro apenas uma vez para nunca mais perder tempo com aquele problema.

Repita comigo: CSS HACK apenas em último caso.

Hoje, felizmente é possível fazer sites complicadíssimos sem utilizar CSS HACKS. Na maioria das vezes o uso do Hack é necessário por causa de um problema anterior: o código complicado.
Seja simples

Pense quantas vezes for necessário. Se você resolveu um problema com 3 divs, tente resolver com apenas 2. Se resolveu com 2, tente resolver com 1. Apenas se não conseguir, volte para 2 divs. E assim você faz com o resto do site. Quanto menos código HTML, melhor. Mas lembre-se, o pouco código HTML que você escrever, precisa ter significado. A semântica ajuda bastante neste sentido. Escrevendo código semântico, você garante que o código escrito será mínimo e significativo para sistemas de busca e outras aplicações que dependam da semântica para funcionar.

Escrever código demais é herança da metodologia antiga, onde nós escrevíamos uma gambiarra atrás de outra. Onde colocávamos tabelas em todos os lugares. Lembre-se que tudo mudou. Você tem que mudar também e o desenvolvimento apenas muda se você mudar sua maneira de pensar. Pense simples. Reaprenda o que puder e esqueça o antigo.
Visualize o resultado no próprio browser.

Outro costume terrível nosso é visualizar o resultado nos previews nojentos dos editores. Geralmente estes previews são baseados em apenas um browser, normalmente o browser padrão. Há uma opção de mudar o preview para o browser que você que quiser. Mesmo assim, pense comigo: Você sabe qual será o browser do visitante? Você sabe, na melhor das hipóteses que ele pode navegar com pelo menos 4 browsers: Firefox, IE, Safari e Opera. Isso se ele usar Windows. Portanto, não tem sentido utilizar o preview do editor.

Minha sugestão é a seguinte: abra os principais browsers e visualize a implementação ao mesmo tempo.
Eu abro Firefox, IE e Safari (de vez em quando). A cada modificação no CSS e no HTML, eu aperto F5 em cada um deles e vejo o resultado. Se percebo algum erro, já corrijo e sigo em frente. Nunca deixo para visualizar em todos os browsers depois que termino a implementação. Esso é um método muito perigoso. Você procrastina todos os problemas que você teve para o final. Isso pode gerar problemas irreversíveis e na maioria das vezes, quando acontece, é mais fácil recomeçar.

Lembre-se de que com Padrões Web ficou tudo mais fácil.
Era tudo muito mais difícil quando tentávamos desenvolver com padrões, mas nenhum browser suportava grane parte dos métodos. Hoje, todos estão interessados em ter suporte com os padrões e felizmente os browsers estão mais espertos.
O jeito é estudar, estudar e estudar. Pelo menos se você quiser ser um bom profissional.

sexta-feira, 25 de janeiro de 2008

“Qualidade”+“Testes de Softwares”=“Qualidade de Software”

Qualidade:
O termo Qualidade vem do latim “Qualitas”, e é utilizado em diversas situações, mas o seu significado nem sempre é de definição clara e objetiva. Há várias definições para qualidade, do ponto de vista de diferentes pessoas, como: "Produto(s) e/ou serviço(s) com constatada efetividade”; "Valor que produtos similares não possuem"; "Fazer correto da primeira vez"; "Maior relação custo versus benefício"; "Em conformidade com as exigências do(s) cliente(s)"; "Adequação ao uso". Enfim, o referido termo é geralmente empregado para significar excelência de um produto e/ou serviço.

A qualidade de um produto pode ser vista por duas ópticas: a do produtor e a do cliente. Do ponto de vista do produtor, a qualidade associa-se à concepção e produção de um produto que vá ao encontro das necessidades do cliente. Do ponto de vista do cliente, a qualidade está associada ao valor e à utilidade reconhecidas ao produto, estando nalguns casos ligada ao preço.

Quando acompanhamos a atual realidade dos textos relacionados à informática em geral, não é difícil nos deparamos com termos como: “Controle da Qualidade”, “Garantia da Qualidade” e “Gerência da Qualidade” e isso porque hoje são considerados conceitos quase que básicos, seja na indústria, comércio e ou serviços. Os conceitos são usados em várias áreas, inclusive e mais fortemente em “Qualidade de Software”. Gerência da qualidade é o processo de controlar e gerenciar o processo da qualidade na fabricação ou manutenção de um produto ou serviço. Garantia da qualidade são as ações tomadas para redução de defeitos. Controle da qualidade são as ações relacionadas à medição da qualidade, para diagnosticar se o resultado está sendo atingido.


Testes de Softwares:
O teste do software é uma das fases do processo de Engenharia de Software que visa atingir um nível de qualidade de produto superior. O objetivo, por paradoxal que pareça, é mesmo o de encontrar defeitos no produto, para que estes possam ser corrigidos pela equipe de analistas/programadores, antes da entrega final. A maioria das pessoas pensa que o teste de software serve para demonstrar o correto funcionamento de um programa, quando na verdade ele é utilizado como um processo da engenharia de software para encontrar defeitos. O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.


Qualidade de Software:
Um desenvolvimento organizado de software tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão definidos os passos necessários para chegar ao produto final esperado.

Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software espera-se um produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.

Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.

Independentemente da metodologia de trabalho empregue para o desenvolvimento de um software, para que se obtenha um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de software.

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes, como por exemplo os ”SW-CMM”, ”SE-CMM”, ”ISO 15504” e o mais conhecido ”CMMI”.

Outro fator com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e/ou financeiros.


Técnicas de Testes:
Atualmente existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje tem grande valia para os sistemas orientados à objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar falhas no software. Abaixo estão descritas as três técnicas mais conhecidas.

Caixa-Branca:
Dentro desta categoria de teste de software o desenvolvedor tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do programa. Dessa maneira, todas as variações originadas por estruturas de condições são testadas.

Caixa-Preta:
Neste tipo de teste de software o desenvolvedor dos testes não possui acesso algum ao código fonte do programa. O objetivo é efetuar operações sobre as diversas funcionalidades e verificar se o resultado gerado por estas está de acordo com o esperado. Para esta categoria podem ser levados em consideração todos os eventos que podem ser disparados pelo usuário, como por exemplo, cada clique de mouse a ser realizado em uma interface.

Caixa-Cinza(Ainda não tão comum quanto os de caixa Branca ou Preta):
Esta categoria de teste de software passou a ser considerada mais recentemente. Uma definição deste tipo de teste seria um ponto de equilíbrio virtual entre o teste de caixa-branca e o caixa-preta. De uma maneira mais clara, o desenvolvedor dos testes não tem acesso ao código fonte da aplicação, porém tem conhecimento dos algoritmos que foram implementados, como também pode efetuar manipulações em arquivos de entrada e saída do tipo XML ou mesmo acessos ao banco de dados da aplicação para simples conferência de dados ou alteração de parâmetros considerados nos casos de teste.

Testes Alpha, Beta e Gama:
No processo de desenvolvimento, os testes preferencialmente devem ser executados antes do produto ser disponibilizado aos usuários. Essa período entre o término do desenvolvimento e da entrega é conhecido como fase alpha(aplicados após ou em paralelo com os chamados unitários) e os testes executados nesse período como testes alpha. No início dos testes da fase alpha são utilizadas técnicas e caixa-branca. Posteriormente, os desenvolvedores dos testes aplicam técnicas de caixa-preta como complemento da primeira parte de testes. Completada a fase alpha de testes, são lançadas a grupos restritos de usuários versões de teste do sistema, denominadas versões beta. Conseqüentemente este período fica denominado como fase beta. Através deste tipo de teste os usuários finais do produto podem encontrar defeitos peculiares de tarefas costumeiramente executadas por eles. Visando um maior retorno de informações sobre o mau funcionamento do sistema algumas empresas distribuem as versões betas para todo o universo de utilizadores.

Paralelamente podem ser executados testes de caixa-preta durante essa fase, dando assim maior eficiência no processo.



Algumas das “Categorias de Testes” mais importantes para se obter
Qualidade de Software:

Teste de Unidade :
Também conhecido como testes unitários. É um tipo de atividade que visa testar pequenas partes ou unidades do sistema. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

Teste de Componente:
Este tipo de teste possui um universo um pouco maior ao teste unitário. Seu propósito é testar o componente como um todo e não apenas as suas funções ou métodos. Mesmo assim, o teste continua a ser executado sem considerar a iteração com outras partes do sistema, ou seja, leva-se apenas em consideração o componente a ser testado e nenhuma outra entidade do sistema.

Teste de Integração:
O teste de integração, como o próprio nome já diz, visa encontrar falhas provenientes da integração dos componentes do sistema. Geralmente os tipos de falhas encontradas são de envio e recebimento de dados. Por exemplo, um objeto A pode estar esperando o retorno de um valor “x” ao executar um método do objeto B, porém este objeto B pode retornar um valor “y”.

Teste de Sistema:
Este é um teste de grande importância. Sua principal filosofia é varrer o sistema em busca de falhas através da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do sistema.

Teste de Aceitação:
São realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.


Gestão da qualidade:


Atualmente a gestão da qualidade está sendo uma das maiores preocupações das empresas, sejam elas voltadas para a qualidade de produtos ou de serviços. A conscientização para a qualidade e o reconhecimento de sua importância, tornou a certificação de sistemas de gestão da qualidade indispensável para as micro e pequenas empresa de todo o mundo.

A certificação da qualidade além de aumentar a satisfação e a confiança dos clientes, reduzir custos internos, aumentar a produtividade, melhorar a imagem e os processos continuamente, possibilita ainda fácil acesso a novos mercados. Esta certificação permite avaliar as conformidades determinadas pela organização através de processos internos, garantindo ao cliente um produto ou serviço concebido conforme padrões, procedimentos e normas.

Entre modelos existentes de sistema da qualidade, destacam-se as normas da série ISO 9000(já comentadas em artigo anterior). Estas se aplicam a qualquer negócio, independentemente do seu tipo ou dimensão. As normas desta série possuem requisitos fundamentais para a obtenção da qualidade dos processos empresariais. A verificação dos mesmos através de auditorias externas garante a continuidade e a melhoria do sistema de gestão da qualidade.

Os requisitos exigidos pela norma ISO 9000 auxiliam numa maior capacitação dos colaboradores, melhoria dos processos internos, monitoramento do ambiente de trabalho, verificação da satisfação dos clientes, colaboradores, fornecedores e entre outros pontos, que proporcionam maior organização e produtividade que podem ser identificados facilmente pelos clientes.

As pessoas e as empresas que buscam qualidade devem criar uma mentalidade positiva de mudança.

Qualquer melhoria, pequena ou grande é bem vinda. Toda inovação deve ser conhecida, testada e se possível aplicada.

Uma organização que se propõe a uma gestão voltada para a "qualidade", tem consciência de que a sua trajetória deve ser reavaliada. As mesmas precisam por em prática as atividades que visam estabelecer e manter um ambiente no qual as pessoas, trabalhando em equipe, consigam um desempenho eficaz na busca das metas e missões da organização.

domingo, 20 de janeiro de 2008

A diferença entre analista de sistemas e de negócios

Negócios e sistemas para desenvolvimento: o trabalho do analista de sistema deve ser em sintonia com o analista de negócios, que possui maior percepção dos processos internos da empresa.
Por Ricardo Veríssimo
Este texto é sobre a diferença entre analista de sistemas e analista de negócios (sem contar com a função analista programador, da qual não concordo).
Ao participar em uma consultoria para melhoria de processos de controle interno e administração em uma empresa da área médica, presenciei um acontecimento muito sintomático para exemplificar as atuações nos campos de análise de negócios e análise de sistemas.
Segue em resumo a conversa entre três atores da vida real: um coordenador de TI (contratante de um sistema), uma analista de sistemas (contratada do sistema a ser desenvolvido) e uma coordenadora de marketing (na baia de trabalho ao lado).
O coordenador e o analista discutem os requisitos e funcionalidades para uma parte de um sistema e repetem:
- Isso! Assim vai ficar ótimo.
A coordenadora, que escutava a conversa na baia ao lado (e que para o bem da empresa era intrometida), disse:
- Assim não vai funcionar, pois os médicos não vão usar desta forma por este e aquele motivo.
Nesta história a coordenadora agiu como a analista do negócio - pois conhece como os processos acontecem realmente e tem o domínio do negócio. Essa é a diferença entre analista de negócios e analista de sistemas.
Sou da área de TI, mas infelizmente é grande o número de profissionais que acreditam saber tudo e não lançam mão de analistas de negócios dentro da própria empresa para conhecimento e melhoria do que está sendo desenvolvido.
Analista de sistemas deve saber as melhores práticas de desenvolvimento, conhecer técnicas de desenvolvimento e levantamento de requisitos, mas não precisa conhecer de todos os ramos e nichos de mercado. Isso é para o (a) analista de negócio.
Na empresa deste caso existe um sistema cheio de problemas nos processos de negócios, pois foi usada a figura do analista programador. O resultado: os erros do programador estão sendo descobertos pelo cliente, pois a análise do criador na criação parece que não foi imparcial. Será que alguém acredita que existe análise imparcial nestes casos?
Será que existe engenheiro pedreiro? Por outro lado, muitos pedreiros chegaram a ser engenheiros.
Um bom programador pode e deve se tornar um analista e vai ajudar muito os programadores. Mas nada garante também que um bom programador será um bom analista e vice-versa, assim como nada garante que um bom vendedor de loja será um bom gerente.
Ricardo Veríssimo (ricardo@rverissimo.com.br) é consultor de tecnologia, sócio gerente da RVeríssimo Consultoria e Tecnologia Ltda e técnico de processamento de auditoria de sistemas e processos da Loudon Blomquist Auditores Independentes.

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina