Página 11 de 16

Criando e mantendo senhas seguras

25/11/2013 Assuntos Randômicos 2 Comentários

Muito se discute hoje sobre a segurança da informação. Nós, meros mortais, usuários de um número cada vez maior de serviços online, temos boa parte de nossa segurança à mercê de uma grande variedade de empresas de tecnologia esparramadas mundo afora.

Um problema crescente desde o advento da Internet envolve o gerenciamento de senhas de autenticação para acesso a esses serviços. Do ponto de vista técnico, políticas de segurança devem ser tomadas, tais como impor um tamanho mínimo, exigir caracteres especiais, dígitos numéricos e variação de capitalização (mistura de maiúsculas e minúsculas). Pode-se ainda incluir uma autenticação adicional como um token (chaveiro, cartão, aplicativo para celular) ou dispositivo biométrico. Cada iniciativa para dificultar ações maliciosas tem o potencial de diminuir o número de ocorrências de segurança, mas os riscos nunca serão definitivamente eliminados.

Por outro lado, um peso considerável sobre a segurança recai sobre nós. Mas, como podemos nos proteger? Como criamos senhas seguras? Primeiro, precisamos entender alguns conceitos sobre senhas.

As pessoas usam senhas fáceis e repetidas

Quando a Sony foi invadida em 2011, contas de 77 milhões de usuários foram roubadas, incluindo seus números de cartão de crédito, e-mails, logins e senhas. Pouco tempo depois, mais um milhão de usuários tiveram seus dados capturados e expostos a qualquer interessado através de um arquivo torrent.

Um especialista em segurança analisou os dados disponibilizados e descobriu alguns fatos interessantes:

Mais de 50% dos usuários usam senhas com 7 caracteres ou menos
50% das senhas consistem apenas de letras minúsculas e 45% apenas de letras maiúsculas
Apenas 4% das senhas continham alguma diversidade (números, maiúsculas e minúsculas, caracteres especiais)
1% das senhas continham caracteres especiais
36% das senhas estavam presentes em dicionários de senhas usados por hackers

Na mesma análise, comparando as senhas obtidas em dois serviços diferentes da Sony, verificou-se que 92% dos usuários usavam a mesma senha em ambos. Comparando com senhas obtidas de outro serviço fora da Sony, o reuso foi de 67%.

Definindo uma senha segura

Qualquer especialista em segurança lhe dirá que não existe nada 100% seguro. Para efeito de estudo, vamos considerar que uma senha segura é aquela onde o esforço para obtê-la é mais custoso do que o benefício advindo de tal ato.

Na área de segurança é comum usarmos o conceito de entropia para explicar a dificuldade de descobrir-se uma senha. Este termo é emprestado da física, mais especificamente da Segunda Lei da Termodinâmica, e define o grau de irreversibilidade ou desordem de um sistema. Quanto maior a entropia de uma senha, mais aleatória e complexa ela é, assim como será maior o esforço de alguém para obtê-la.

Fatores que aumentam a entropia de uma senha

A Universidade de Cambridge realizou um estudo empírico sobre segurança de senhas onde 288 estudantes foram divididos em 3 grupos: o primeiro poderia escolher uma senha qualquer, o segundo usaria um método para gerar uma senha aleatória e o terceiro usaria uma senha cujas letras eram as iniciais de uma frase qualquer.

O ataque mais efetivo foi o uso de um dicionário de palavras comuns, que conseguiu descobrir 30% das senhas escolhidas pelos alunos (primeiro grupo), 8% das senhas aleatórias e 6% das senhas com iniciais de uma frase. Em seguida, um ataque de força bruta foi realizado. Neste tipo de ataque, senhas sequenciais são geradas com base num conjunto de caracteres. Quanto menor a senha, mais suscetível ela é a um ataque de força bruta. Todas as senhas com menos de 6 caracteres foram quebradas.

A conclusão que podemos chegar até aqui é que uma senha segura contém 8 ou mais caracteres e deve ter variações de tipos de caracteres (maiúsculas, minúsculas, números e caracteres especiais). Mas senhas precisam ser fáceis de memorizar, e agora?

A questão da memorização

O quadrinho abaixo, em inglês, exemplifica uma ideia criativa para criar senhas seguras e fáceis de memorizar:

Criando uma senha segura

A ideia do autor, também defendida por uma parte da comunidade de segurança, é não usar uma senha complexa cheia variações especiais, pois ela seria de dificílima memorização para humanos, mas fácil de quebrar para computadores. Por outro lado, uma sequência de palavras de fácil memorização para humanos seria mais segura do ponto de vista computacional.

A princípio alguém poderia argumentar que selecionar quatro palavras não é tão diferente de uma senha de 4 dígitos, certo? Errado!

Análise combinatória da entropia das senhas: qual tipo de senha é mais segura?

Uma senha consiste numa combinação de elementos cuja ordem importa e onde existe repetição. Este é o conceito de arranjo com repetição, cuja fórmula é:

T = n^r,sendo:

T = total de combinações (quanto maior, mais difícil de adivinhar)

n = quantidade de elementos (tamanho da senha)

r = número de elementos selecionados (número de possibilidades de cada caractere da senha)

Vamos aplicar esta fórmula a alguns tipos de senhas e obter o número de combinações possíveis:

Senha de 4 caracteres composta apenas de letras maiúsculas ou minúsculas (26 elementos selecionados)
T = 4²⁶
Senha de 8 caracteres composta apenas de letras maiúsculas ou minúsculas (26 elementos selecionados)
T = 8²⁶
Senha de 8 caracteres composta de letras, números e caracteres especiais “!”, “@”, “#”, “$”, “%”, “&”, “*”, “_”, “.” e “-” (72 elementos selecionados)
T = 8⁷²
Senha de 4 palavras, considerando as 3 mil palavras mais comuns de uma língua
T = 4^3.000
Senha de 4 palavras, selecionadas de um mini dicionário (um “mini Aurélio” possui 30 mil verbetes)
T = 4^30.000

Os itens acima estão ordenados, de forma que o primeiro oferece a menor entropia e o último a maior. Portanto, senhas com palavras, ainda que contidas num dicionário, são muito mais seguras do que senhas complicadas que misturam números, letras maiúsculas e minúsculas e alguns caracteres especiais. Além disso, uma sequência de palavras é muito mais fácil de memorizar.

Senhas diferentes para sites diferentes

Você usa a mesma senha de outros sites quando faz um novo cadastro em um site qualquer? Já pensou que, se apenas uma das contas que você possui for comprometida, o hacker terá acesso a todas as suas outras contas? Voltamos ao problema da memorização: se devemos usar senhas diferentes para cada site, como poderemos lembrar-nos de cada uma delas?

Os simplistas dizem: simplesmente anote suas senhas num papel e guarde na carteira. Bem, se você já perdeu a carteira ou foi roubado, isso soa um tanto absurdo, não é mesmo?

A primeira solução apontada pelos especialistas é usar um aplicativo gerenciador de senhas. Você memoriza uma senha mestra e a usa para acessar as demais senhas. Porém, é ruim ficar dependente de um aplicativo. Se for um aplicativo para desktop você nem sempre vai estar com sua máquina ao seu lado, se for mobile alguém pode roubar seu celular e se for na nuvem (web) existem outras questões de segurança a serem consideradas.

Outra sugestão apontada em fóruns de segurança é criar um “algoritmo pessoal” baseado no site. Suponha que sua senha do Facebook seja “Eu amo o Facebook!”, então sua senha do Gmail é “Eu amo o Gmail!”. Bem, o problema com essa abordagem é óbvio: qualquer um poderia adivinhar sua senha em outro site. Soluções paliativas consistem em criar um algoritmo mais difícil do que simplesmente usar o nome do site, mas isso sempre irá cair na categoria de segurança por obscuridade, o que não é nada bom do ponto de vista da Segurança da Informação.

Uma abordagem usada por muitos, às vezes inconscientemente, é adotar três senhas principais. A primeira é uma senha com baixa entropia, usada em cadastros diversos na internet que não trazem grande risco. A segunda é de média entropia usada em serviços mais importantes e pessoais, como a conta do Facebook, blog pessoal, e-commerce, etc. A última é uma senha de alta entropia usada em serviços críticos e essenciais, como o e-mail pessoal, bancos, etc. Porém esta solução ainda não é a ideal, pois um vazamento de informação levaria a uma brecha de segurança em serviços do mesmo nível.

Além das senhas

Se você conseguiu acompanhar as informações até aqui, deve ter percebido o tamanho da dificuldade por parte dos provedores de serviços e dos usuários em gerenciar senhas. Mas, existe alguma alternativa? Felizmente, sim! Inclusive alguns acreditam que o uso de senhas é algo que deva ser abandonado.

Uma das opções que temos é o uso de certificados digitais. Por exemplo, em alguns acessos SSH e VPN configura-se o servidor para aceitar um determinado certificado e o usuário que possui esse certificado em seu sistema poderá acessar o serviço. Porém, o uso de certificados por usuários hoje é um tanto restrito a administradores de serviços e redes ou a serviços importantes como a emissão de notas fiscais online. Isso ocorre, em parte, pelo esforço que seria necessário para gerenciar os certificados por parte dos administradores de rede e, em parte, pelo custo junto às autoridades certificadoras. Além disso, certificados só funcionam bem se o computador ou dispositivo for usado somente por uma pessoa, já que eles ficam armazenados no disco.

Dispositivos biométricos são outra alternativa. Eu, que sou cliente do banco Itaú, já utilizo a autenticação por impressão digital há alguns meses no caixa eletrônico, entretanto ainda estamos um pouco longe de ter tal tecnologia disponível em todos os serviços do dia-a-dia.

Outra solução mais recente é a autenticação colaborativa, cujos exemplos mais conhecidos são OpenID e OAuth. Nesse sistema, você usa uma conta única em diferentes serviços. É o caso do “Login com Facebook” ou “Login com Google”. Ao se cadastrar em um site com suporte a essas tecnologias, você não precisa criar um novo cadastro e fornecer a senha para aquele site, apenas autoriza o Facebook, Google ou outro serviço onde você possui uma conta a compartilhar algumas de suas informações. Este mecanismo é muito interessante, pois você precisa gerenciar apenas uma senha “forte” e os demais serviços nunca chegam a processar sua senha. Num caso de invasão a um deles, um hacker não terá a menor chance de invadir outros serviços. O risco verdadeiro está em sua conta principal, mas pelo menos você sabe em quem está confiando. Porém, existe uma dificuldade em usar o OpenID de forma abrangente, pois as intranets não irão querer depender de um serviço externo para autenticarem seus usuários.

Conclusões

A criação de senhas seguras, usando diversidade de caracteres e um comprimento razoável, é importante para a segurança de nossas contas. Uma senha composta de quatro ou mais palavras é mais segura que uma senha complexa e aleatória de oito dígitos.

Mas o problema está mais embaixo. Deveríamos criar senhas diferentes para cada serviço, o que, por sua vez, dificulta a memorização. Uma solução é usarmos grupos de senhas, isto é, uma senha simples para serviços de pouca importância, outra mais segura para serviços essenciais e uma senha complexa para serviços críticos.

Existem alternativas melhores ao uso de senhas, como certificados, dispositivos biométricos e os padrões OpenID e OAuth. Infelizmente o uso desses mecanismos de autenticação é limitado por diversos fatores no mundo atual.

Enfim, não há uma solução fácil disponível hoje. Aliás, se você tiver uma, me conte e vamos ficar bilionários! 😉

segurança

Instalando e Configurando o Java Development Kit 7 para Desenvolvimento

21/11/2013 Java 13 Comentários

Nota: Este artigo faz parte de uma série de tutoriais que estou preparando. O primeiro passo, obviamente, é configurar um ambiente de desenvolvimento completo. Meu objetivo é permitir que você tenha um ambiente funcional para então acompanhar sem dificuldades tutoriais sobre tecnologias específicas como JAX-RS, JSF, JPA, etc., evitando assim confusões sobre aspectos secundários.

Antes de pensar em desenvolver algo em Java, precisamos instalar a versão Java para desenvolvimento, isto é o JDK. Diferente do JRE (Java Runtime Environment),que geralmente instalamos para usar aplicativos, bancos, e outros, o JDK vem com várias ferramentas e o compilador javac.

Baixando o Instalador

Acesse http://www.oracle.com/technetwork/java/javase/downloads/index.html e clique no link indicado na imagem:

Na próxima tela, primeiro aceite os termos da licença para liberar os downloads e então escolha a versão do Java compatível com seu ambiente. No meu caso, tenho um Windows 64 bits, então escolhi a versão indicada na figura:

Aguarde o download terminar.

Instalando o Java Development Kit (JDK) e o JRE (Java Runtime Environment)

Execute o instalador que você escolheu. No programa que será aberto, que deve ser algo como a imagem abaixo, simplesmente clique em “Next” na tela inicial e novamente em “Next” na tela seguinte para iniciar a instalação.

No meio da instalação do JDK, será iniciada a instalação do JRE, que é a versão de execução do Java. Clique em “Next” para iniciar a instalação e ser informado de que “mais de 3 bilhões de dispositivos executam Java”.

Ao final, clique em “Close” para finalizar instalação.

Configurando o ambiente

No caso do Windows, precisamos configurar as variáveis de ambiente para que o Java que instalamos fique sempre disponível quando precisarmos.

Acesse as “Configurações Avançadas do Sistema” (Pressione Ctrl+Pause para facilitar) e, na aba Avançado, clique no botão Variáveis de Ambiente.

Verifique, nas Variáveis do sistema, se existe uma variável chamada JAVA_HOME. Certifique-se de que o Valor dessa variável contém o caminho para a pasta do JDK que acabamos de instalar, conforme a imagem:

Note que, no exemplo acima, já havia uma variável da versão anterior, então ela foi atualizada.

Depois disso, edite também a variável Path que está em “Variáveis do sistema” e acrescente o caminho %JAVA_HOME%\bin, se já não houver. Veja o exemplo na imagem abaixo:

Agora teste sua instalação abrindo o Prompt de Comando e digitando java -version. Veja como ficou o resultado:

Pronto! 😀

Agora você já possui a versão mais atualizada de desenvolvimento da plataforma Java.

Não perca as próximas publicações com as demais configurações de um ambiente de desenvolvimento completo!

tutorial

Você tem “o jeito”?

18/11/2013 Carreira Deixe um comentário

Assista aos primeiros dois minutos deste episódio do Dilbert (ative as legendas em português através do botão “Captions”):

É verdade que algumas pessoas nascem com um “jeito” especial para lidar com aspectos técnicos. Posso dizer que, desde o ano de 1997 quando encontrei uma instalação do Visual Basic 4 num CD emprestado, me deparei com algo em que tenho “o jeito”.

Porém, na área de desenvolvimento de software, temos a tendência de supervalorizar o conhecimento técnico em detrimento de áreas humanas e sociais, assim como ocorre por vezes na área de ensino onde um bom aluno em Matemática é mais reconhecido que um bom aluno em Português ou Geografia.

Mas cada indivíduo possui variadas habilidades em diferentes níveis. Por um lado, devemos exercitar nossos talentos para colhermos resultados satisfatórios. Talento sem treino e disciplina é um grande desperdício. Um excelente programador que não procura se aperfeiçoar vai acabar ultrapassado em poucos anos. Além disso, com diligência, um bom vendedor pode ganhar mais que o pessoal técnico. Por outro lado, é importante trabalharmos nossos pontos fracos. Programadores que escarnecem de usuários, mas não sabem se relacionar, dificilmente alcançarão algum sucesso na carreira.

Algo que tenho aprendido em meus poucos anos de experiência é que o empenho consciente em crescer na carreira vale muito mais do que meu talento em criar código. Este blog, assim como tudo o que tenho produzido, não existe apenas devido ao que eu sei, sendo um resultado de um constante investimento de tempo e intelecto.

Existe um conceito que aprendi estudando economia, chamado trade-off. Basicamente isso diz que nossas escolhas tem um custo. Sempre que você escolhe fazer algo, deixa de fazer inúmeras outras coisas. Quando você gasta seu dinheiro em uma coisa, deixa de gastar em inúmeras outras. Aplique isso na sua rotina diária e coloque na balança o custo do tempo que tem investido em atividades supérfluas. Quantas vezes poderíamos estudar, investir na saúde, aprender um idioma, empreender e se preparar para os vários desafios da vida, mas acabamos em frente a uma TV ou vídeo-game?

Em suma, tendo ou não “o jeito”, trabalhe para aperfeiçoar seus talentos e superar suas dificuldades. Não há ganho sem dor.

desenvolvimento profissional

Você reclama do seu chefe e do seu ambiente trabalho?

30/10/2013 Carreira Deixe um comentário

Te peguei, não é? Mas não se preocupe, todos nós reclamamos e criticamos de alguma forma e isso não é necessariamente ruim.

Críticas construtivas ou reclamações fúteis?

Em várias situações, neste blog e mundo afora, costumo criticar como desenvolvemos e gerenciamos projetos de software. Por outro lado, em sombrios cantos de cozinhas e corredores de empresas ouvem-se constantes reclamações despreocupadas que vão desde a cor da cortina do escritório até o aroma do sabão da pia do banheiro. Qual a diferença?

Quando estamos inconformados com uma situação e queremos melhorar, nossa crítica terá o objetivo de gerar mudança e o resultado é positivo. Uma crítica construtiva é aquela que possui um fator motivador e gera ação nas pessoas. Por exemplo, meu objetivo com artigos de auto crítica é levar o leitor a uma reflexão sobre si mesmo e o ambiente ao seu redor, fazendo-o sair da inércia. Meus erros são uma escola para mim e quanto antes os identifico e os supero, mais benefícios colherei mais cedo.

Mas, infelizmente, quantas vezes dizemos coisas que não acrescentam em nada e geram insatisfação em nós e em nossos colegas? Estamos sendo um empecilho para nossas carreiras e para quem nos ouve. Considero vazia e sem sentido a crítica que fica apenas nela mesma. Seria melhor não a termos declarado.

A boa notícia é que, com um pouco de esforço, podemos transformar nossas reclamações vazias em críticas construtivas. Ao invés de dizer “o processo que usamos é um lixo”, não seria melhor pensar um pouco e mudar para “se ajustássemos a atividade X dessa forma Y, nossa produtividade aumentaria”? Ao invés de reclamar para todos os colegas que “o chefe não reconhece o meu trabalho”, seria melhor eu me esforçar para que o resultado do meu trabalho seja mais tangível de forma que possa frequentemente reportar visivelmente o progresso obtido.

Pense como seu chefe

Isso pode ser ofensivo para alguns, mas tenha paciência e acompanhe meu raciocínio um pouco mais.

Ao fazer uma crítica desdenhosa a um superior, você não ganha nada. Apenas reforça a barreira imaginária entre patrão e empregado. Se você quer crescer profissionalmente, coloque-se no lugar dessa pessoa e tente pensar como ela. Isso não significa se tornar igual a ela. Mesmo não concordando com algumas de suas atitudes, você deve compreender suas motivações. Não há problemas em discordar, mas será que você é capaz de propor uma solução comprovadamente melhor para as dificuldades que surgem sem simplesmente criticar a decisão do chefe ou gerente? Qual seria a reação dele se você propusesse uma boa solução?

A verdade é que na maioria das vezes nossas críticas são ignorantes, pois não temos “conhecimento de causa”. Nós reclamamos do nosso trabalho, não o fazemos direito e ainda assim achamos que podemos ser melhores do que os outros. Seja sincero: você acha que seu chefe vê algum potencial de crescimento em você se nem seu próprio trabalho atual é feito com empenho?

Algumas pessoas vêem o chefe como um tirano (não que alguns não sejam), mas na verdade elas não conseguem enxergar as situações do ponto de vista dele.

Por outro lado, poderíamos alcançar muito mais sucesso profissional se fôssemos capazes de produzir algo de valor para nossa área de negócio do que simplesmente sendo funcionários exemplares que chegam no horário e fazem muitas horas extras. Você é um excelente programador? E daí? Isso não tem a mínima importância se os clientes não estão mais satisfeitos do que com a concorrência. Você sempre fica até mais tarde? Mas se não entregar um produto de qualidade, está apenas desperdiçando energia elétrica. Por que temos essa mentalidade de que somos remunerados pelas oito horas diárias de trabalho? Se o valor do seu trabalho está em passar o tempo dentro da empresa, uma pedra prestaria um melhor serviço.

Diga-me com quem andas…

Um dos conselhos que seguramente daria para qualquer pessoa com relação ao ambiente de trabalho é: sempre ande em boa companhia. Quando passamos muito tempo com as pessoas pegamos o jeito delas. Minha esposa viajou há muito tempo para o nordeste e, em uma semana, ela simplesmente não conseguia mais falar sem o sotaque local.

Fique junto de pessoas descontentes, amarguradas, que sempre arranjam desculpas para não estudar coisas novas, que não se esforçam no trabalho e as chances são de que você, no mínimo, vai ter um rendimento menor do que poderia. Ande com pessoas mais experientes, que gostam de aprender e almejam mais da vida e constantemente você será contagiado pelo desejo de progredir.

Conclusão

Eu poderia escrever uma enciclopédia com exemplos de como nossa mentalidade é deturpada por anos de uma cultura dualista entre burguesia e proletariado, que gera tensão constante entre esses dois “lados”. Ou ainda poderia discorrer sobre uma longa lista de conselhos específicos sobre ética comportamental. Porém, vou concluir desafiando o caro leitor com uma paráfrase de uma expressão que minha esposa usa comigo algumas vezes:

Você acha que tem potencial? Pare de reclamar e mostre o seu valor!

ambiente de trabalho

Então o usuário não sabe o que quer? Conte-me mais sobre o esforço da equipe na elicitação de requisitos e o seu entendimento sobre o domínio da aplicação

25/10/2013 Desenvolvimento Deixe um comentário

Volta e meia um desenvolvedor desabafa: “Usuário não sabe o que quer”. Ou ainda: “Usuário é burro”. Não questionarei a validade dessas afirmações, por vezes elas podem ser verdadeiras.

Por outro lado, devolvo a pergunta: como desenvolvedor, quanto empenho você coloca em entender o que o usuário está realmente precisando?

Usuários, em geral, não sabem nem o que um sistema de software é capaz de fazer, então não espere que lhe digam em detalhes o que você deve implementar. Casos de uso, histórias de usuário, diagramas, desenho das interfaces e outros recursos, por mais simples que sejam, não são suficientes para comunicar tudo o que é necessário.

Os usuários estão preocupados em resolver problemas de negócio e não em verificar uma lista de inputs da especificação de uma tela. Provavelmente eles sentirão falta daquela coluna do relatório somente quando este já estiver concluído. É preciso entender como um usuário utiliza esse relatório para um determinado fim, assim como o seu objeto ao executar uma determinada ação do sistema.

A única forma de entregar software com adequação e acurácia é compreender a necessidade do usuário do ponto de vista dele e do negócio e, independente da forma como uma solicitação chega até nós, traduzir esta necessidade em uma solução concreta. E isso sem esquecer das qualidades técnicas.

meme requisitos

Planejou considerando tempo para refatoração. Nada mal!

18/10/2013 Assuntos Randômicos Deixe um comentário

Os planejamentos de projetos de desenvolvimento de software de maneira geral englobam atividades de especificação, codificação, testes e talvez um tempo para correções. Nós pensamos nas funcionalidades implementadas como blocos de uma construção, sendo colocados uns sobre os outros.

Porém, não é assim que um software funciona. Ao adicionarmos novas funcionalidades no decorrer do projeto, o sistema como um todo pode ser afetado e, por vezes, torna-se necessário adaptar ou reescrever parte do que já estava “pronto”. Por isso, um sistema 90% “pronto” pode levar muito mais que 10% do tempo planejado para ser efetivamente concluído.

Pense nisso!

meme refatoração

Os 10 erros clássicos do desenvolvimento de software

16/10/2013 Processos Deixe um comentário

Com certeza você já se deparou com alguns erros clássicos do desenvolvimento de software. Infelizmente, por diversos motivos, as empresas e os engenheiros de software tem repetidamente falhado em seus projetos por não aprenderem com seus próprios erros. Que tal refletirmos sobre nossos maiores erros para, de alguma forma, evitar repeti-los?

Steve McConnell, um profissional experiente e autor de diversos livros e artigos sobre Engenharia Software, identifica em seu artigo Classic Mistakes os erros mais que ocorrem mais frequentemente. Abaixo, vamos analisar os 10 erros clássicos em projetos de software apontados pelo autor, acrescidos de alguns comentários:

10. Motivação

A motivação tem enorme impacto na produtividade e na qualidade, mas são poucos que adotam práticas efetivas para motivar as pessoas.

Salário não é o único nem o principal fator motivador, pois as pessoas tendem a se acostumar com o que ganham não importa o quanto seja. Programadores gostam de trabalhar com novidades tecnológicas, mas a excitação não dura tanto quanto gostaríamos, principalmente em projetos longos. Não existe uma fórmula mágica, o segredo é investir constantemente nas pessoas, financeiramente ou não.

Colegas mais experientes já me disseram que a motivação correta é um fator chave para o sucesso de um negócio.

9. Pessoas problemáticas

Não lidar com pessoas problemáticas, seja qual for o motivo, afeta a motivação de todos os envolvidos.

Soube de um gerente que teve problemas com o melhor desenvolvedor da equipe. Ninguém sabia se era inveja ou simplesmente o comportamento “normal” dele. Esse desenvolvedor constantemente gritava para toda a empresa ouvir a cada pequeno erro que seus colegas cometiam (como um erro de Português num e-mail), agredia verbalmente os outros desenvolvedores quando considerava suas dúvidas simples demais e interrompia deseducadamente seu gerente em reuniões com clientes e com a administração da empresa. O mal-estar foi generalizado e, embora ele fosse um desenvolvedor tecnicamente excelente, toda a equipe foi afetada negativamente.

8. Barulho

Lugares tumultuados e cheios de gente atrapalham muito a produtividade.

No livro Peopleware, o autor nos apresenta um exemplo de uma fábrica onde avisos eram feitos através de um sistema de auto-falantes, similar ao que ocorre em terminais, aeroportos e grandes lojas. Primeiro toca-se uma espécie de campainha e em seguida alguém fala. Todos os funcionários param o que estão fazendo para prestar atenção ao aviso, perdendo a concentração e levando algum tempo até retomar a produtividade anterior. Na maioria das vezes os avisos eram do tipo “fulano, favor comparecer ao…” e direcionados a apenas uma pessoa.

7. Abandonar o planejamento sob pressão

O cronograma ficou para trás e pressões surgem de todos os lados. A primeira reação é “sair correndo atrás do prejuízo”. Jogamos fora todo o planejamento (processo, testes, etc.) e tentamos entregar as funcionalidades como for possível, resultado num caos infinito de “codifica e arruma” (tentativa e erro).

6. Ignorar as atividades básicas de planejamento

“Pular” direto para a codificação aumenta de 10 a 100 vezes o custo de corrigir o código mal feito.

Não queira ser mais ágil que os métodos ágeis, pois até no agile em geral existe um plano detalhado da iteração (uma ou duas semanas, por exemplo) e um planejamento em alto nível até um certo horizonte do projeto.

Evite fazer em sua mente uma associação do ato de planejar com preencher documentos sem sentido. Planejar é pensar antecipadamente. Refletir sobre um problema antes de colocar a mão na massa irá evitar diversos tropeços.

5. Falta de controle de mudanças

Em média, os requisitos mudam 25% desde a fase de “requisitos definidos” até a primeira versão do sistema. Isso causa um aumento superior a 25% no cronograma. Portanto é necessário controlar as mudanças nos requisitos para limitar mudanças desnecessárias.

Controlar mudanças não consiste em limitar a adequação dos requisitos nem deixar de responder às mudanças em regras de negócio, como alguém pode pensar. O problema é que, se não houver controle, a tendência será um loop de alterações, muitas das quais serão feitas diversas vezes (por exemplo: aumenta fonte, diminui fonte, altera descrição, volta descrição anterior).

4. Síndrome da “bala de prata”

Quando as pessoas focam numa única ferramenta, tecnologia ou metodologia esperando que esta seja a solução para tudo, geralmente ocorre o contrário, a produtividade cai com o tempo.

Trabalhei na migração de um sistema feito na ferramenta chamada Genexus. É uma linguagem de quarta geração, tipo um Access um pouco mais evoluído, que se propõe a gerar telas e cadastros. Não vou entrar no mérito se é possível criar uma arquitetura adequada nessa ferramenta, mas no caso que conheço, apesar de ser muito mais fácil criar cadastros e telas do que em Java, com o tempo o código procedural do Genexus ficou tão complexo que alguns bugs simplesmente não podem ser corrigidos.

3. Informações insuficientes dos usuários

Uma pesquisa realizada em 1994 demonstrou que esta é a causa número um de fracassos em projetos de software.

Não adianta construir perfeitamente a coisa errada. Como engenheiros de software, e não como digitadores de código, nós temos a responsabilidade de compreender o suficiente sobre o domínio da aplicação para traduzir corretamente as necessidades de negócio em um sistema de software.

2. Cronogramas muito apertados

A mesma pesquisa também mostrou que a média de atraso dos projetos é de 220%, causados por cronogramas “agressivos”.

Ao permitirmos que a correria tome conta, as atividades que pensamos poder ignorar no princípio acabam sendo feitas com custo até 100 vezes maior em fases posteriores no projeto.

Além disso, a produtividade das pessoas cai devido à pressão. Alguns gerentes podem discordar, principalmente se estão acostumados a lidar com pessoas preguiçosas. Entretanto, os bons desenvolvedores não irão simplesmente produzir mais de uma hora para outra. Ao contrário, eles já dão o melhor e com a pressão passarão a cometer mais erros.

1. Adicionar mais desenvolvedores

Segundo o autor, este é o engano mais comum. A verdade é que, salvo raras exceções, adicionar pessoas à equipe vai gerar mais trabalho para as que já estavam no projeto, pois elas terão que parar a todo momento para explicar detalhes para os novos desenvolvedores. Dificilmente os novatos alcançarão um nível de produtividade recompensador no tempo esperado.

engenharia de software gerenciamento de projetos

Eclipse: acabando com alguns erros de validação desnecessários

08/10/2013 Java 9 Comentários

Erros de sintaxe em bibliotecas Javascript como jQuery e jQuery UI quando estão minimizadas (compactadas)

É uma dor de cabeça ver seu projeto sempre com erro por colocar uma versão minified do jQuery ou jQuery UI. A solução para isso, que aplica-se a qualquer script avaliado incorretamente como tendo um erro, é excluir o arquivo javascript específico da validação do Eclipse.

Em resumo, você precisa excluir os arquivos javascript da sua lista de fontes, conforme as telas abaixo:

: Arquivos de código-fonte javascript

: Excluindo arquivos com falsos-positivos

Abaixo, o passo-a-passo com detalhes:

Clique com o botão direito no projeto e, no menu, escolha a opção Properties.
Navegue até o item JavaScript > Include Path e selecione a aba Source.
Selecione o item Excluded na lista e clique em Edit….
Clique em Add Multiple… e selecione os arquivos com problemas
Clique em Finish e em Ok para confirmar

Observação: restrinja essa configuração para bibliotecas conhecidas e confiáveis, evitando a todo custo fazer isso para seus próprios scripts de modo a ocultar erros no seu código.

Erros de validação e sintaxe em XML

Existem muitos problemas diferentes de validação em XML. Tentarei cobrir os mais comuns:

Eclipse não consegue acessar o arquivo de validação (XSD ou DTD)

Por alguma razão, o Eclipse não consegue acessar o arquivo de definição (XSD ou DTD). Logo no início do XML, provavelmente você vai notar que há uma URL para um arquivo com extensão .dtd ou .xsd. Se o estiver offline, sob um proxy ou por qualquer outro motivo o Eclipse não puder baixar esse arquivo, ocorrerá erro de validação e uma possível lentidão até ocorrer um timeout.

Para resolver isso, baixe manualmente o arquivo de definição a partir da URL, acesse a configuração Windows > Preferences… > XML > XML Catalog no Eclipse, clique em Add… e adicione manualmente o arquivo baixado.

URL de arquivo de validação incorreta

Falhas de validação referentes à sintaxe também ocorrem com frequência. Após certificar-se de que está tudo certo no corpo do XML, verifique se as declarações dos arquivos de validação estão corretos na raiz do arquivo (xmlns e xsi:schemaLocation).

Recentemente tive problemas com um arquivo web.xml que estava com uma URL depreciada:

http://java.sun.com/xml/ns/j2ee

Ao invés da atualizada:

http://java.sun.com/xml/ns/javaee

A mensagem de erro era longa, iniciando com “s4s-elt-character: Non-whitespace characters…“. Bastou trocar j2ee para javaee e o erro de validação desapareceu. Na versão 2.5 da API do Servlet, o conteúdo correto da declaração é:

<?xml version="1.0" encoding="UTF-8"?>
<web-app 
	xmlns="http://java.sun.com/xml/ns/javaee" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
		http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
	version="2.5">
(...)

Versão de arquivo de validação incorreta

Outro problema que já tive algumas vezes foi com o XML de configuração do Spring Framework. Atualizei a versão do framework e o XML de configuração começou apresentar erros somente quando eu estava offline.

Isso ocorre porque, no caso do Spring, o DTD de validação vem empacotado dentro do jar. Com a URL certa, mesmo offline o Eclipse encontra o arquivo de validação. Mas se mudarmos a versão do jar sem refletir a mudança no XML, o Eclipse vai tentar localizar o arquivo na internet.

Foi preciso apenas trocar a versão do caminho do DTD correspondendo à versão do Spring Framework. Exemplo:

<?xml version="1.0" encoding="UTF-8"?> 
<beans
    xmlns="http://www.springframework.org/schema/beans" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
(...)

Nesse exemplo, a versão 3.0 deveria ser atualizada para 3.1, conforme o upgrade do framework:

<?xml version="1.0" encoding="UTF-8"?> 
<beans
    xmlns="http://www.springframework.org/schema/beans" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
    http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
(...)

Erros em projetos Maven com o plugin m2e (Maven to Eclipse)

Antes de mais nada, é importante salientar que o m2e é um plugin do Eclipse que o integra ao Maven. Entretanto, o Maven possui seus próprios plugins. Portanto, não confundamos plugins do Eclipse com plugins do Maven.

Project configuration is not up-to-date with pom.xml

O erro mais comum em projetos com a Maven Nature (Natureza Maven, aqueles que ficam com um pequeno “M” no ícone do projeto) é quando o projeto não está atualizado conforme o arquivo de configuração do Maven (pom.xml). A mensagem é “Project configuration is not up-to-date with pom.xml” e ocorre porque, dependendo das alterações no pom, as configurações de projeto (.project) e do classpath (.classpath), além de outros possíveis plugins do Eclipse, precisam ser atualizadas para refletir o novo pom.

Este é o problema mais simples de resolver, pois basta clicar com o botão direito sobre o projeto, acessar o menu Maven > Update Project… e confirmar.

Plugin execution not covered by lifecycle configuration

Outro erro comum ocorre ao usar um plugin no build do Maven que não seja reconhecido pelo m2e. Aparece a temida mensagem “Plugin execution not covered by lifecycle configuration…“. Isso ocorre porque o m2e não sabe como executar um determinado plugin do Maven dentro do Eclipse.

Anteriormente era necessário acrescentar uma tag um tanto volumosa em nosso pom para informar ao m2e o que ele deve fazer. Já nas versões mais novas do m2e, basta selecionar o erro new view Problems e aplicar um Quick Fix, solicitando ao m2e acrescentar o código necessário automaticamente.

É importante atentar para o fato de que há duas opções de solução: a primeira é acrescentar o código no próprio pom.xml, enquanto a segunda é acrescentar a solução de forma global para os projetos do workspace, o que é bem conveniente no caso de usar um certo plugin em vários projetos.

Para acessar a configuração global de mapeamento de plugins, acesse Window > Preferences… > Maven > Lifecycle Mappings. Nesta tela você pode abrir o arquivo clicando no botão Open workspace lifecycle mappings metadata.

Outros problemas com Maven

Se, ao tentar atualizar o projeto com o Update Project ocorrer algum tipo de exceção, tome as seguintes providências:

Verifique se você está sob um proxy. Se estiver, configure seus dados de acesso no arquivo settings.xml seguindo o modelo existente, recarregue as configurações do Maven através do botão de refresh na view Maven Repositories do Eclipse e faça um novo Update Project.
Verifique também as versões de dependências entre seus projetos. Uma versão errada pode gerar diferentes erros.
Remova do seu arquivo .classpath qualquer entrada que use uma variável, do tipo kind=”var”.
Verifique se existe algum outro erro no classpath, pois, por exemplo, uma entrada apontando para um arquivo jar inexistente impede o Eclipse de compilar o projeto. Faça um novo Update Project.
Quando a compilação do projeto falha mesmo quando o Maven Dependecies está funcionando (isto é, o classpath está sendo gerenciado corretamente pelo Maven), pode ser que algum jar baixado pelo Maven esteja corrompido. Verifique na sua pasta de repositório (geralmente uma pasta chamada “.m2” dentro da sua pasta de usuário) se os jars usados no seu projeto estão íntegros, abrindo-os com alguma ferramenta como o 7-zip.
Verifique na view Problems se existe algum erro no projeto que seja relacionado ao Maven. Procure então na view Error Log por mais detalhes, para tentar encontrar alguma pista sobre a causa. Por fim, se não encontrar a causa, olhe o arquivo de log do m2e no diretório “.metadata\.plugins\org.eclipse.m2e.logback.configuration” do seu workspace.

E você? Tem algum erro/problema misterioso em seus projetos do Eclipse? Comente!

dica eclipse maven

Sempre que um programador concatena um parâmetro da requisição na query, uma fada morre

03/10/2013 Assuntos Randômicos Deixe um comentário

E isso vale para qualquer dado vindo de fora do sistema: banco de dados, arquivos, web services e por aí vai.

meme segurança sql injection

Entendendo o Triângulo de Ferro, porque não podemos ter tudo

30/09/2013 Assuntos Randômicos 1 Comentário

A maioria dos projetos atrasa, estoura o orçamento e ainda fica aquém do esperado. Em geral damos um jeitinho de contornar essas situações, mas sempre há um preço a ser pago: trabalhar até mais tarde, diminuir a qualidade, perder a reputação e a confiança do cliente.

Existem diversas fontes de problemas que afetam um projeto de software, desde a negociação até a entrega. Porém, acredito que a maior contribuição para o constante fracasso do planejamento é oriunda de uma negação interior, lá no fundo, do fato de que…

Não podemos ter tudo

O grande desejo de todo administrador é produzir com o mínimo de recursos, no menor tempo possível, o produto com maior valor e qualidade do mercado. Mas não é assim que as coisas funcionam. Algo deve ser sacrificado.

Irei enfatizar essa verdade, de que não podemos ter tudo, com algumas analogias corriqueiras, pois é um paradigma para todas as esferas da vida. Quando usamos ingredientes baratos e de baixa qualidade em nossa alimentação, aliviamos o bolso mas a saúde vai de mal a pior. Se economizamos no material de construção, logo teremos goteiras e infiltrações. Se contratamos o buffet mais “econômico” para o casamento, os convidados irão, no mínimo, sair reclamando de fome e, no pior caso, acabar no hospital com intoxicação alimentar. Quando aplicarmos esse princípio conscientemente em nosso trabalho teremos menos dificuldades em entender nossos fracassos.

Se montarmos uma equipe somente com programadores juniors, podemos esperar qualidade? Se temos desenvolvedores experientes, mas o tempo é escasso, podemos esperar que todas as funcionalidades sejam entregues?

Perceba que, no contexto de um projeto de software, existem elementos que funcionam como variáveis de uma equação, gerando consequentes restrições. Se mexemos em uma delas, todas as demais são afetadas. Como abstraímos e representamos esse conceito?

O triângulo de ferro

O Triângulo de Ferro ¹

O “triângulo de ferro” (iron triangle), “triângulo do projeto”, “triângulo das compensações”, “triângulo das restrições” ou ainda “restrições triplas” é uma representação do relacionamento entre as principais variáveis de um projeto: recursos, tempo e escopo. Existe ainda um quarto elemento, ou quarta dimensão, que alguns autores acrescentam: a qualidade. Esta seria resultante das decisões tomadas em relação às demais variáveis.

Através do triângulo de ferro conseguimos visualizar certas consequências do *trade-off *das escolhas e restrições de um projeto. Em suma, o que a figura nos ensina é: todos os aspectos do projeto estão interligados. Não é possível alterar um deles sem afetar os demais. Recursos, tempo, escopo e qualidade possuem uma relação implícita.

Na prática: Quer mais qualidade? Aumente os recursos ou o tempo! Quer aumentar o escopo? Aumente o tempo ou os recursos! E assim vai…

Porque nós, desenvolvedores, deveríamos nos preocupar com isso?

Todo gerente de projetos deveria conhecer o triângulo de cor e salteado. Porém, o ideal é que todos os envolvidos em um projeto tenham um grau de consciência dessas restrições. Digo isso porque, falando especificamente da área de TI, a equipe de desenvolvimento sofre uma série de pressões do cliente e da gerência no decorrer do projeto e torna-se essencial equilibrar essas variáveis, reconhecendo aquilo que está dentro das possibilidades e tomando a decisão adequada. Os clientes sempre querem que entreguemos mais funcionalidades, com mais qualidade e mais rapidamente, mas com os mesmo ou até menos recursos. Quando a gerência não trata disso, a corrente arrebenta no elo mais fraco, isto é, os desenvolvedores “pagam” pelos diversos erros em todos os níveis do projeto tendo que fazer inúmeras horas extras.

Em minha experiência, o melhor remédio para o trabalho em excesso é a prevenção. Uma coisa é colaborar para o sucesso do seu empregador, outra é aceitar tudo o que lhe é imposto. Nós, desenvolvedores, devemos aprender a analisar a situação e, ao detectarmos problemas no projeto, negociarmos de antemão. Isso significa que, se sua empresa está prometendo o que você sabe que ela não pode cumprir, é melhor deixar isso claro desde o início para os responsáveis. Não estou dizendo para você desafiá-los ou confrontá-los rudemente, mas sim tentar expor de modo gentil e firme seu ponto de vista. Se eles derem ouvidos, ótimo, de outra forma, ao menos eles perceberão que você é um profissional sério e sabe o que está fazendo.

Entendendo as variáveis do projeto

Recursos

Embora o termo “recurso” seja ofensivo para alguns quando se trata de pessoas, ele é adequado quando falamos do investimento em um projeto. Esse investimento se traduz na contratação ou alocação da equipe, nos equipamentos necessários, espaço físico e outros itens. Embora, devido ao overhead, a quantidade de recursos não seja tão proporcional à produtividade, ainda assim podemos afirmar que, no geral, quanto mais recursos maior é a produtividade.

Tempo

Geralmente existe uma data limite definida pelo negócio, devido à uma janela de oportunidade, onde o software deve ser entregue.

Escopo

Quais funcionalidades serão entregues? Nem todos os requisitos e funcionalidades possuem a mesma prioridade. Num processo iterativo de desenvolvimento, deve-se definir junto ao pessoal de negócios quais funcionalidades trazem mais valor. Nem sempre é possível fazer tudo.

Qualidade

A qualidade é uma quarta dimensão entre as variáveis do projeto, a qual é influenciada pelas demais restrições. Como qualidade não é algo objetivamente mensurável, não há como fixar um valor para essa variável. Entretanto, se existe um padrão mínimo de qualidade para o projeto, devemos ajustar as demais variáveis de modo a atingir esse objetivo.

Conjugando as restrições

A fim de planejar, o gerente do projeto deve considerar as restrições, fixar as variáveis críticas e então estimar as demais. De forma incoerente, alguns tentam fixar todas elas, o que sempre resultará nas falhas descritas no início deste artigo. Quantas e quais variáveis são fixas, depende do projeto e do modelo de desenvolvimento adotado.

Variando o escopo e fixando os recursos e o tempo

Se temos uma equipe e um prazo fixos, então devemos estimar quais funcionalidades poderemos entregar de acordo com a produtividade da equipe dentro do tempo disponível.

Variando os recursos e fixando o tempo e o escopo

Temos um conjunto de funcionalidades a serem implementadas até uma data limite. Podemos então estimar o esforço necessário para completar a tarefa dentro do esperado. Quantas horas e quantos desenvolvedores serão necessários para completar as tarefas?

Variando o tempo e fixando o escopo e os recursos

Contamos com N desenvolvedores para entregar X funcionalidades. Com isso, estimamos em quanto tempo concluiremos o projeto.

Variando a qualidade

O projeto está atrasado. Não há tempo, nem como obter ajuda porque não há mais pessoas com conhecimento do projeto e ninguém quer negociar com o cliente uma entrega parcial, já que o relacionamento com ele está desgastado há meses. Então todos aceleram o passo. Testes? Para quê? As horas extras vão ajudar a pagar aquela fatura do cartão, não é? Será possível fixar tempo, escopo e recursos?

Então, na noite de sexta-feira, todos limpam o suor do rosto e suspiram de aliviados. A release já está no cliente. De alma lavada vão para o seu merecido descanso, pensando em como ultrapassaram as expectativas. Até a segunda de manhã, quando o cliente liga muito bravo devido à quantidade absurda de erros. Parabéns, foi entregue um produto no prazo, no orçamento e completo, mas que não funciona. Um software de péssima qualidade que demandará mais tempo de manutenção que desenvolvimento!

Você conhece algum caso onde o sistema foi enviado ao cliente sem passar por testes porque os desenvolvedores só concluíram o que foi prometido em cima da hora?

A qualidade é influenciada de diversas formas, sendo os principais fatores relacionados às pessoas envolvidas, tais como: equipe inexperiente ou desmotivada, pressão para concluir o projeto, dificuldades de comunicação.

O que vale mais para você?

Variáveis fixas e estimadas conforme o tipo de plano²

A gestão “tradicional” de TI geralmente foca no plano. Por “tradicional”, entenda aquilo que temos feito vez após vez nos últimos anos de forma irrefletida. Planeja-se a implementação sequencial das funcionalidades de acordo com a quantidade de recursos e o tempo disponíveis. “Vamos começar pelos cadastros mais simples, para ir pegando o jeito, depois avançamos para as regras de negócio mais complexas”, é algo comum de ouvir, uma tendência natural que se percebe.

Em contrapartida, processos modernos, principalmente os ágeis, procuram focar em trazer valor ao cliente. Com uma equipe e iterações fixas, priorizam-se as funcionalidades que mais beneficiarão o cliente e, a cada iteração, uma nova versão funcional do sistema é entregue. Ao aplicarmos o Princípio de Pareto (regra do 80-20), em tese, pode-se entregar 80% do valor do sistema nos primeiros 20% do projeto.

Lições e Conclusões

O triângulo de ferro é apenas uma representação, mas nos dá um referencial para entendermos as consequências das escolhas que fazemos. Não podemos ter tudo. Mesmo quando alguém acha que pode, na verdade estará sacrificando algo. No que se refere ao desenvolvimento de software, geralmente é a qualidade.

Um projeto é mais que cronograma, um gráfico ou qualquer documento, não podemos manipular a nosso bel-prazer. Se tentarmos forçar as variáveis do projetos certamente afetaremos algo. Justamente por isso o nome “triângulo de ferro”.

Além da adoção de um processo adequado, de ações preventivas e de boas práticas em todas as fases e áreas do desenvolvimento de software, as melhores formas de lidar com as inevitáveis restrições e dificuldades dos projetos são: aprender a negociar as restrições junto ao cliente e à gerência e priorizar devidamente as funcionalidades de modo a entregar algo de valor ao cliente.

Para concluir, uma citação que usei na minha monografia sobre estimação de software:

Frequentemente falta aos gerentes de software firmeza de fazer o pessoal esperar por um bom produto ³

Referências

1) O Triângulo das Restrições de Gerenciamento de Projetos (acessado em 30/09/2013)

2) Scope, Time & Cost Triangle Balancing To Motivate Team and Satisfy Client (acessado em 30/09/2013)

3) BROOKS, F., The Mythical Man-Month, Addison-Wesley, 1975

gerenciamento de projetos