Como avaliar a segurança do seu sistema com testes ?

             Recentemente temos visto diversos tipos de ataques hackers a sites e sistemas de governo e até em sistemas de umas das mais renomadas instituição de investigação do mundo, FBI.  Lulzsec, um grupo ativista de hackers que, apesar do curto período de 50 dias de existência,  conseguiu cumprir o seu principal objetivo: Mostrar o quão vulnerável são os sistemas ao nosso redor, inclusive sistemas de pagamentos digitais bastante usados pelo mundo.

Após ler várias reportagens sobre ataques hackers pelo mundo, fiquei curioso sobre o estado da arte de teste na área de segurança e encontrei um organização chamada OWASP, que tem a missão de fazer com que aplicações de segurança sejam visíveis para que pessoas e organizações possam tomar decisões sobre os verdadeiros riscos de segurança de uma aplicação.  A OWASP é uma organização, que qualquer pessoa pode participar e todo material disponibilizado pela mesma esta sob a licença de software aberta.

Como todo bom engenheiro de teste, sabemos que para garantir a qualidade do software, temos que nos preocupar  e procurar se envolver em todas as fases do desenvolvimento do software. Por isso apesar de muitos princípios definidos pela OWASP estarem voltados para as fase iniciais do desenvolvimento dos sistemas, os considero também relevantes para os engenheiros de testes. Estes princípios recomendados pelas OWASP são coleções de propriedades, comportamentos, design e práticas de implementação para reduzir a probabilidade de ataques e também minimizar os impactos quando os ataques acontecem. São eles:

  1. Aplique a defesa-em-profundidade – Este princípio significa a definição de mecanismos de segurança em camadas, ou seja, se em caso de ataque causar uma falha em um mecanismo de segurança, outros mecanismos devem prover a segurança necessária para proteger o sistema.
  2. Utilizar o modelo de segurança positiva – Comumente conhecida com lista branca, pode ser aplicada em diversas áreas de segurança. Em vez de definir uma lista do que é proibido e permitir o resto, o modelo de segurança positiva consiste em definir uma lista do que é permitido e rejeitar qualquer outra coisa.
  3. Falhar com segurança – Como desenvolvedor, você deve considerar que há apenas 3 possibilidades de saídas em um mecanismos de segurança: Permitir a operação;  Não permitir a operação e exceção. E quando um mecanismos de segurança gerar uma exceção, você deve garantir que ela deve seguir o caminho de não permitir a operação, ou seja, métodos comuns como isAutorized(), isAutenticated, e validate() devem retornar sempre falso caso ocorra alguma exceção.
  4. Rodar com privilegio mínimo – Este princípio recomenda que cada conta tenha o mínimo privilegio necessário para realizar seus processos dentro do sistema.
  5. Evitar a segurança por obscuridade – Segurança através da obscuridade é a confiança no sigilo da implementação de um sistema ou componentes de um sistema para mantê-lo seguro.  Um exemplo seria um sistema de criptografia, apenas a chave precisa continuar em segredo, o algoritmo não precisa ficar em segredo.
  6. Mantenha a segurança simples – Modismos de engenharia de software preferem certas abordagens excessivamente complexas para o que seria relativamente simples. Os desenvolvedores devem evitar o uso de negativos duplos e arquiteturas complexas quando uma abordagem mais simples seria mais rápida.
  7. Detecte intrusões – Detectar intrusões requer 3 elementos básicos: Capacidade de registrar eventos relevantes de segurança em logs; Procedimentos que garantem que os logs são monitorados regularmente; Procedimentos para responder adequadamente quando uma intrusão for detectada;
  8. Não confie na infraestrutura – Este principio reforça o primeiro da lista. Cada mecanismo de segurança está sujeito a falhas e por isso não se deve confiar plenamente em alguns desses mecanismos, incluindo os de infraestrutura.
  9. Não confie em serviços – Muitas organizações utilizam capacidade de processamento  de terceiros, que na maioria das vezes possuem políticas de segurança diferentes. Por isso todos os sistemas externos devem ser tratados de forma semelhantes.
  10. Estabeleça padrões de segurança – Há muitas maneiras de entregar uma experiência “fora do comum” para os usuários. No entanto esta experiência deve ser segura, e deve esta nas mãos do usuário decisão de reduzir sua segurança. Por padrão a expiração e complexidade da senha deve estar habilitada. Os usuários poderão ser autorizados a desabilitar estas duas características para simplificar o uso da aplicação e aumentar o seu risco
             Além dos princípios recomendados, a OWASP também desenvolveu um guia de testes de segurança, neste documento ele ensina algumas técnicas e ferramentas mais usadas por hackers para ataques em sistemas web e que devem ser usadas para avaliar a segurança do sistema web em desenvolvimento.  Espero que gostem e aproveitem !!!

#TGIF – iPads e o combate ao autismo

Há algum tempo atrás li algumas matérias a respeito da utilização do wii na recuperação de pacientes,  fazendo uma nova busca encontrei um vídeo, que mostra o mesmo sendo utilizado em hospitais. Esse tipo de notícia parece cada vez mais frequente,  apresentando tecnologias diferentes, sendo aplicadas nos mais diversos tratamentos.

O vídeo de hoje do #TGIF, mostra a utilização de aplicativos para iPad, como ferramenta de apoio na evolução de pessoas com autismo. Impossível não imaginar a quantidade de possibilidades, que ainda podemos desenvolver e o número de pessoas, que podem ser beneficiadas por equipamentos e aplicativos desse tipo.

Clique na imagem para assistir ao vídeo no youtube.

— Update —

Link para matéria do Jornal Hoje com tecnologia desenvolvida no CIN para auxilio em tratamentos de fisioterapia.

…………………………………………………………………………………………………………………………………………..

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Criando Oportunidades

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

#TGIF – A era da revolução científica

Na seção de comentários do meu penúltimo TGIF que fala sobre conceitos, protótipos e ficção científica, recomendei um livro chamado Visões do futuro do fisíco teórico americano Michio Kaku, e no momento que estava procurando informações na internet sobre este autor, encontrei no youtube um vídeo muito interessante da BBC na qual Drº Michio participa como locutor principal, esta matéria é chamada Revolução da inteligência, e parte de uma série da BBC na qual tenho certeza que é baseado nesse livro de Visões do Futuro do Drº Michio Kaku, as outras matérias da série chamam-se respectivamente de revolução biotecnológica e revolução quântica .

Para não estender o post vamos apenas falar sobre a primeira matéria da série (Revolução da inteligência), que já levanta diversos pontos de discussão. Nesta primeira parte, Drº Michio explica como a ciência está avançando tão rapidamente a partir do momento que descobrimos o segredo da matéria (Átomo), revelamos a molécula da vida (DNA) e criamos uma forma de inteligência artificial (Computador). Ele argumenta que a descoberta das leis fundamentais da natureza no século 20, abre portas para um número imensurável de possibilidades no século 21 no qual nós estamos fazendo parte desta transição histórica de uma era de descobertas científicas para uma era de domínio científico.

Inicialmente esta revolução que estar por vir parece um pouco assustadora, mas se pararmos um pouco e voltarmos para mais de 70 anos atrás quando tivemos umas das primeiras cirurgias cardíacas de sucesso feitas pelo Dr. Alfred Blalock em parceria com Vivien Thomas, muito bem contada no filme Quase Deuses, percebemos que todos nós naturalmente resistimos um pouco à uma revolução desse tipo e sempre questionamos qual será o limite para isso tudo.

Para se ter uma idéia do tamanho do impacto social que esta revolução está por fazer, posso destacar alguns questionamentos que os cientistas estão imaginando que possam vir junto com esta revolução:

– Na evolução da realidade virtual e redes sociais virtuais, surge a questão de o que acontecerá se nós começarmos a preferir nossa redes sociais virtuais do que a nossa rede social real ? Isso surge porque hoje já temos mais de 30 milhões de pessoas no mundo que passa em média 20 horas por semana no mundo virtual, por exemplo World of Warcraft.

– Na área de inteligência artificial, onde teremos um evolução tão grande que as máquinas cada vez mais terão a capacidade de agir como a inteligência humana, surge a questão de como nós vamos nos relacionar com estas máquinas ?

– Uma última e intrigante pergunta surge com o avanço das tecnologias biológicas e eletrônicas na qual nos próximos 50 anos poderemos ter máquinas com mais componentes biológicos e pessoas com mais componentes eletrônicos. Daí surge a questão de como vamos categorizar o que é pessoa e o que  é máquina ?

Assistam o vídeo abaixo, tem quase uma hora de duração e infelizmente não está com legendas, e vamos discutir o que vocês que podem acontecer quando esta nova realidade estiver mais próxima ao nosso cotidiano.

No futuro conversaremos sobre as outras matérias da série bastante interessante da BBC.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Steve Jobs e seu legado

– “Tudo” sobre o iPhone 5

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Imagine um mundo SEM bugs no software

Na indústria de software estamos habituados a ideia de que todo software possui defeitos e que pouco podemos fazer para mudar isso. No vídeo a seguir, de apenas 9 minutos, Jeff McKenna, co-fundador do Scrum apresenta uma visão radical: um mundo sem bugs no software. O vídeo foi extraído de seu próximo livro “Conscious Software Development.”

O vídeo é excelente e nos faz pensar principalmente na atitude em relação aos bugs que temos em nossos projetos. Segundo Jeff, não basta corrigirmos os defeitos encontrados precisamos entendê-los e aprender com eles, só assim construiremos sistemas SEM defeitos.

Assista ao vídeo. Em seguida, destaco os principais pontos abordados por McKenna.

 

Temos sistemas de gerenciamento de defeitos, realizamos triagens, mas será que em algum momento pensamos sobre o que eles são? ou como surgiram? como fazer para não surgirem mais?”

Segundo Jeff, temos sido muito complacentes com os defeitos, acreditamos que existem muitos, e que os mesmo são parte de todos os sistemas. Porém, o autor não acredita nisso e nos convida a imaginar um mundo SEM bugs de software.

“Podemos atingir números bem menores do que as pessoas consideram razoável, e isso pode ser feito de maneira simples”

McKenna indica que, a simples conscientização a respeito dos bugs já possibilita imensos ganhos. Precisamos entender porquê eles estão presentes e agir para evitar novas falhas.

Como diminuir a quantidade de bugs?

– Reduzir o tempo entre a introdução de um bug e sua correção

A medida leva em conta o momento no qual o bug foi introduzido no sistema e não o momento em que o mesmo foi detectado. Para isso é necessário utilizar as ferramentas de controle de código, assim, após identificado o motivo do defeito podermos voltar versões do código e identificar o momento em que ele ocorreu.

Olhando para o exato momento em que o erro aconteceu podemos aprender a escrever menos bugs. Porque esse é o verdadeiro objetivo.”

O objetivo não é encontrar mais bugs e a função dos analistas de qualidade não se resume a isso.

“Classificação e triagem de feitos são uma perda de tempo, em termos de aprendizado sobre como escrever menos bugs”

Segundo McKenna, pouco importa a severidade do defeito e suas características, pois geralmente o critério de correção está diretamente ligado a questões de negócio, como a importância de um determinado cliente. Logo, se estamos tentando aprender a escrever menos bugs, não há diferença entre os mesmos, sejam eles de alta ou baixa prioridade todos são comportamentos não esperados do sistema.

“Corrigir os defeitos era a atividade de maior prioridade”

Jeff, exemplificou suas recomendações com as seguintes práticas executada em um de seus projetos:

1- Sempre que um bug surgisse, a primeira pessoa que estivesse livre passaria a trabalhar no defeito. Onde, um profissional era considerado livre quando terminava a tarefa que estava executando no momento. Bugs possuem prioridade mais alta, que todas as demais tarefas ainda não realizadas. Desse modo, no máximo em alguns dias o defeito era analisado.

2 – Corrigir e entender o problema. A mais alta prioridade era a correção do defeito, associado a criação de novos testes automáticos. Porém, o mais importante é você falar porquê aquele bug estava lá, a razão do mesmo ter ocorrido.

“O que queremos fazer é encontrar o bug o quanto antes para que possamos consertá-lo o mais cedo possível e provar o aprendizado”

Para McKenna, temos o prazo máximo de até 6 meses da introdução de um defeito, para podermos aprender algo através de sua correção, após isso a oportunidade de aprendizado terá sido desperdiçada.

“O objetivo real é escrever software SEM defeitos.”

E para atingir esse objetivo, a principal característica que temos que desenvolver é a de olhar sempre para frente. Se ficamos sempre olhando para trás 6 meses, 1 ano, analisando um código que não vemos a muito tempo, isso literalmente é perda de tempo. Então, o que queremos fazer é olhar para frente a todo o momento e ter a atitude de ZERO defeitos.

“Um bug é algo que você esmaga imediatamente.”

Ao eliminar rapidamente os bugs encontrados acabaremos com tarefas, como a priorização de defeitos. Afinal, a quantidade de bugs pendentes será sempre pequena e desse modo o foco poderá ser maior no que está sendo construído.

Este é um vídeo para ser visto diversas vezes, e se conseguirmos absorver sua ideia central, penso que, poderemos melhorar ainda mais nossos processos e principalmente nossa atitude.

Conheci esse vídeo primeiramente no Software Testing Club, uma excelente fonte de informações para testadores, com bons textos e vídeos sobre a área. Espero que tenham gostado.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

#TGIF – Se os problemas de computador fossem reais

Chegou a sexta-feira e com ela mais um #TGIF para relaxarmos um pouco. No post de hoje trazemos um vídeo curtinho do youtube, que satiriza como seriam na vida real os problemas enfrentados frequentemente pelos usuários de computador.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– “Tudo” sobre o iPhone 5

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Cobertura de código, como ?

No meu ultimo post falei sobre a importância da cobertura de código e o quanto ele é comumente utilizado com critério de saída nas primeiras fases de um projeto de software. Lá eu falei das duas técnicas de medição de cobertura de código mais usadas, são elas a Statement Coverage e Decision Coverage. Agora venho escrever este post para cumprir a promessa que deixei no ultimo post, que é mostrar na prática como utilizar uma ferramenta para fazer a medição da cobertura dos testes, neste exemplo, unitários.

A ferramenta que utilizei para exemplificar as duas técnicas acima foi um plugin para o Eclipse chamada CodeCover.
CodeCover é uma ferramenta de teste glass-box grátis e desenvolvido em 2007 na Universidade do Stuttgart.

Para iniciarmos o exemplo, vou mostrar uma classe (Example.java) com dois métodos bastante simples para facilitar o entendimento das técnicas utilizadas.

public class Example {

	public void firstExample(int a, int b) {
		int c =  a + (2*b);
		if (c>50){
			System.out.println(c);
		}
		System.out.println("Fim 1");
	}
}

Abaixo temos os primeiros testes unitários escritos na classe ExampleTest.java para verificar o funcionamento do método firstExample(int a, int b).

	@Test
	public void testFirstExample() {
		try {
			ex.firstExample(20, 15);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

	@Test
	public void testFirstExample1() {
		try {
			ex.firstExample(20, 25);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

Para medir a cobertura dos testes acima apenas precisamos marcar as classes Example e ExampleTest para ser usado pela ferramenta de Medição de Cobertura ( Figura 1)

Tela 1 - Clique para ampliar

Após marcar as classes envolvidas (classe de teste e classe a ser testada), iniciamos a execução dos testes no modo CodeCover para JUnit. Ao finalizar a execução dos testes, aparecerá uma aba chamada Test Sessions, no qual podemos marcar os teste unitários executados e visualizar as linhas de código da classe testada que foram exercitado pelo teste. Na tela 2 abaixo podemos ver que o teste testFirstExample exercitou apenas 3 linhas de código de um método que possue 4 linhas de código.

Tela 2 – Clique para ampliar
Tela 3 – Clique para ampliar

Na tela 3, quando marcamos apenas o teste testFirstExample1, verificamos que o mesmo possui uma cobertura completa do método firtExample(int a, int b). Isso quer dizer que apenas o segundo teste (testFirstExample1) é suficiente para se ter 100% de Statement Coverage, ou seja todas as linhas de código foram exercitadas.

Mas se prestar atenção na tela 3 a linha de código numero 8 da classe: if (c>50) {”  está pintada de amarelo, isto quer dizer que essa linha de código não está completamente exercitada, ou seja, esta estrutura condicional ainda precisa ser estimulada por mais teste para que outro fluxo seja tomado, e isso a gente consegue garantir quando testamos esse método com os dois teste anteriores. Olhando para tela 4 abaixo, percebemos que quando marcamos os dois testes (testFirstExample e testFirstExample1), temos 100% de cobertura  de Decision Coverage, pois ambos os teste exercitaram a linha 8 para que o fluxo fosse tomado tando para que C fosse maior que 50 e C fosse menor que 50, exercitando assim a estrutura condicional (if) pode completo.

Tela 4 – Clique para ampliar

Analisando direitinho, podemos perceber que toda suíte de teste que cobre 100% de decision coverage, também cobre 100% de statement coverage, no entanto o inverso nem sempre  é verdade.

Espero ter esclarecido melhor o conceito de Statement e Decision coverage com os exemplos acima. O que vocês acharam ? Caso tenham dúvidas relacionadas a este tema, por favor utilizem o espaço de comentário para que possamos discutir mais sobre o assunto.

Obrigado e até breve !!!

#TGIF – Steve Jobs e seu legado

O TGIF de hoje não poderia ser indiferente ao triste acontecimento que ocorreu essa semana. O mundo perdeu um dos maiores visionários da história, muitos já o comparam com da Vinci, Henry Ford, Thomas Edison entre outras personalidades importantes da história da humanidade.

Para conhecer um pouco mais desse cara que foi um ícone de algumas gerações, existem alguns livros e filme que de um forma ou de outra falam de sua vida e sua personalidade. São eles:

A segunda vinda de Steve Jobs – Sinopse: Baseado em dezenas de relatos de pessoas que conviveram com o executivo nas últimas três décadas, este livro é a biografia do personagem que melhor representa o sonho americano de Silicon Valley. Autor de perfis para as revistas Vanity Fair e GQ e correspondente da Fortune, o jornalista Alan Deutschman inicia a narrativa em 1985, no momento em que Jobs sai da Apple acusado de roubar segredos da   empresa. Seguem-se a ascensão e queda de sua própria empresa, a Next, o enorme sucesso de seu estúdio de animação, a Pixar, produtor dos filmes Toy Story e Vida de inseto, e, no final dos anos 90, seu retorno triunfal à empresa que o    havia demitido. O livro tem como fio condutor os altos e baixos da vida profissional de Jobs, mas mostra também o          lado reservado do empresário – a relação de amor e ódio com Bill Gates, as negociações com Michael Eisner e Jeffrey Katzenberg, da  Disney, seus métodos de administração e seu contato com a imprensa.

A Cabeça de Steve Jobs – Sinopse: É difícil acreditar que um homem revolucionou os computadores nos anos 1970 e 1980, o cinema deanimação e a música digital nos anos 1990. Por outro lado, são lendárias as histórias de seus repentinos acessos de raiva, revelando o verdadeiro Steve Jobs. Então, o que há, realmente, dentro do cérebro de Steve? Segundo o autor, é um feixe de contradições. O autor destila os princípios que guiam Jobs ao lançar produtos arrasadores, ao atrair compradores fiéis e ao administrar a sua empresa. O resultado é este livro sobre Steve Jobs que é, ao mesmo tempo, uma biografia e um guia sobre liderança.

Steve Jobs – Sinopse: Este livro, baseado em mais de quarenta entrevistas com Steve Jobs e entrevistas com familiares, amigos, colegas, adversários e concorrentes -, narra a vida deste empresário, cuja paixão pela perfeição e cuja energia contribuíram para seis indústrias – a computação pessoal, o cinema de animação, a música, a telefonia celular, a computação em tablet e a edição digital.

Também existe um filme clássico chamado Piratas do Vale do Silício, que fala basicamente sobre a história dos dois principais personagens da tecnologia do mundo: Bill Gates e Steve Jobs na década de 70 e início da década de 80.

Vamos deixar aqui um vídeo nesse post, que com certeza esta sendo visto milhares de vezes nos últimos dias, uma palesta famosa que o próprio fala um pouco de sua vida na formatura de uma turma da universidade de Standford. Isto é para deixar registrado em mais um lugar na grande rede a importância que esse cara representa para toda a nossa geração.  Descanse em paz Steve.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– “Tudo” sobre o iPhone 5

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Os bugs também têm sentimentos

Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.

A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.

Se você encontrar um bug:

1 – Reporte-o, bugs não gostam de ser esquecidos.

Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.

Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.

Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.

Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.

5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.

Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.

Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.

Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.

Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.

Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

#TGIF – “Tudo” sobre o iPhone 5

Está marcado para o dia 04 de outubro mais um evento da apple, onde já foi confirmado o lançamento do iPhone 5. Fãs da apple aguardam ansiosamente por mais uma versão do produto, que já há alguns meses é assunto por toda web.

Diversos são os rumores sobre as novas características do produto, enquanto outro assunto recorrente são os casos envolvendo supostos protótipos do aparelho “esquecidos” em bares e restaurantes por funcionários.

O #TGIF dessa semana selecionou alguns desses links para você se inspirar e rir um pouco nessa sexta-feira.

Primeiro, um dos muitos vídeos que mostra as supostas funcionalidades do iPhone 5, entre elas teclado laser e display holográfico.

Em seguida, mesmo que você seja um fã de carteirinha da apple, não há como não rir com as brincadeiras, que parecem sem fim, sobre o problema com a antena do iPhone 4.

Fonte: Macstories.net

Por fim, vídeo divertidíssimo ilustrando a reação dos diretores da apple com a perda dos protótipos do iPhone 5.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– A brilhante [última] palestra de Randy Pausch

– Por que você deve investir em UX

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

A Metáfora da Dívida Técnica: O preço das gambiarras

O XP (eXtreme Programming) tenta se utilizar de metáforas no desenvolvimento de software para trazer o entendimento de todos para mais próximo do mundo real. Metáforas são um instrumento poderoso.

Recentemente compareci na QConSP, e no meio de tantas palestras uma me chamou a atenção em particular, e se tratava justamente da explicação de uma metáfora (que acredito ser maravilhosa para se comunicar com a gerência ou clientes).

Todos nós sabemos o que é uma dívida no mundo real, e todos nós eventualmente entramos em dívidas, seja um financiamento de um imóvel que você vai pagar por 300 meses, ou um carro que você vai ficar endividado por 60 vezes. O pior de tudo é que além da dívida normal, você irá pagar um montante de juros absurso dependendo do tamanho da dívida que você está assumindo.

Existem as dívidas responsáveis ou conscientes como as citadas acima mas também existem dívidas inconscientes ou não responsáveis que são piores, pois surgem de uma hora para a outra sem te dar tempo para pensar se desejava assumir essa dívida ou não (ex: alguém gastando desordenadamente no cartão de crédito e quando vai ver a fatura fica surpreso).

Pois bem, no desenvolvimento de software é a mesma coisa!

Você tem que adicionar uma funcionalidade no seu sistema. Nesse momento  você enxerga duas formas de fazer isso: Uma forma é rápida de fazer, mas é meio bagunçada e com certeza você iria ter mais trabalho ainda no futuro para modificar aquilo. A outra forma é mais elegante e organizada, porém vai demorar mais. Isso lhe parece familiar?! Esse trade-off acontece o tempo todo no desenvolvimento de sistemas, mas o que esquecemos é das dívidas que assumimos quando escolhemos a forma mais rápida e mais bagunçada (ex.: gambiarras)!

Parece que não temos ciência que todas as vezes que assumimos uma dívidas técnicas no sistema, mais lento o desenvolvimento se torna, mais difícil de modificar as funcionalidades existentes, mais difícil adicionar funcionalidades novas (como mostra o primeiro gráfico) e muito mais provável que uma mudança qualquer tenha impactos indesejados e desconhecidos. Temos que estar cientes das dívidas que assumimos no dia-a-dia do desenvolvimento de software.

Ah, então é por isso que não conseguimos aumentar a velocidade do time depois de tantas sprints??

Talvez! Aí nasce a  questão importante que é o momento que iremos pagar nossas dívidas, ou ao menos parte delas. A grande maioria dos times conhecem os lugares no sistemas que estão com dívidas, e é preciso separar um tempo para PAGAR essas dívidas caso contrário os juros só fazem aumentar. Enquanto as dívidas não são pagas, nós nos deparamos com o cenário onde sprint após sprint, vamos fazer menos coisas (vide o segundo gráfico) pois agora é muito mais difícil modificar o sistema com tantas dívidas do que era no início do desenvolvimento quando não tínhamos dívida ou as poucas dívidas que tínhamos eram controláveis.

Cuidado com suas dívidas técnicas ou elas vão afundar você e seu projeto!