CAPTCHA é um acrônimo da expressão “Completely Automated Public Turing test to tell Computers and Humans Apart” (teste de Turing público completamente automatizado para diferenciação entre computadores e humanos): um teste de desafio cognitivo, utilizado como ferramenta anti-spam, desenvolvido pioneiramente na universidade de Carnegie-Mellon. Como o teste é administrado por um computador, em contraste ao teste de Turing padrão que é administrado por um ser humano, este teste é na realidade corretamente descrito como um teste de Turing reverso.

O consenso geral é que isso seria fácil, mas o problema é conseguir uma solução de quebra de captcha que qualquer um possa fazer download e rodar em seu computador; Então o pessoal da Bonsai criou em alguns minutos um simples script Python que eu testei com vários exemplos de imagens e acabei utilizando o mesmo conceito para outras aplicações. A grande sacada está em utilizar httplib ou urllib para fazer a chamada aos arquivos de imagem. Antes de qualquer coisa tenha em mente: Isso é uma experiência didática. Geralmente não encontramos captchas fracos por ai e neste exemplo trabalharemos exclusivamente com este tipo de catpcha:

• As letras não são rotacionadas
• As letras possuem a mesma largura
• As imagens são do mesmo tamanho
• Não sofrem deformações
• Plano de fundo é o mesmo para toda a imagem

Agora, vamos entender o código que quebra este captcha:

from PIL import Image
#Imagem a ser quebrada, neste ponto você poderia usar urlib, httplib ou curl para carregar esta imagem.
img = Image.open('input.gif')
#convertemos para o padrão RGB
img = img.convert("RGBA")
#damos bind da imagem para a variável pixdata
pixdata = img.load()

# Limpando a sujeira do background, se a cor for != black, então transformamos em branco.
for y in xrange(img.size[1]):
    for x in xrange(img.size[0]):
        if pixdata[x, y] != (0, 0, 0, 255):
            pixdata[x, y] = (255, 255, 255, 255)

#Salvamos a nova imagem com fundo branco
img.save("input-black.gif", "GIF")

#   Aumentamos as dimensões da imagem (requerido pelo OCR)
im_orig = Image.open('input-black.gif')
big = im_orig.resize((116, 56), Image.NEAREST)

#Salvamos a imagem com tamanho maior
ext = ".tif"
big.save("input-NEAREST" + ext)

#   Yeah! Fazemos OCR da imagem usando o Pytesser
from pytesser import *
image = Image.open('input-NEAREST.tif')
#simplesmente imprimimos a imagem em formato de string OCRizado
print image_to_string(image)

resultado:

python ocrcaptcha.py
>>> e4ya
>>> jxt9

Esta simples código, quebra 90% de qualquer captcha que utilize esta implementação. Aconselho fortemente aos programadores Pythonistas, para ficarem de olho no Pytesser, uma biblioteca excelente para OCR, com a qual tenho tido muito sucesso ultimamente!

[0] Bonsai

Aconselho a leitura deste post -> http://under-linux.org/blogs/magnun/brincando-com-python-e-pil-392/

Abraços

O que importa é o código-fonte!

A construção de software é a única coisa que com certeza será feita. Ou seja, o código executável é a única coisa que irá certamente ser produzida, juntamente com os testes para garantir que ele funcione como esperado.

Pronto, terminamos o projeto! Agora é só fazer manutenção!

A construção é uma atividade muito complexa. Ela já toma a maior parte do desenvolvimento de um projeto de software. Segundo McConnel [1], ela pode tomar até 80% de um projeto. Isso é muito, e pode significar que outras atividades serão negligenciadas. Qualquer atividade negligenciada em um projeto de software resulta em problemas futuros de manutenção. E a manutenção é a fase mais longa do ciclo de vida de um software… longa o bastante para durar mais que a vida dos criadores do software. E quando atividades como documentação são negligenciadas para priorizar codificação, o conhecimento acaba ficando na cabeça das pessoas… das pessoas que saem da empresa.

Mais uma noite em claro…

O objetivo desta série de artigos é levantar vários problemas envolvendo a construção de software e quais as melhores práticas que podem ser adotadas para resolvê-los.

Na teoria tudo é bonito…

A ideia não é ficar somente no discurso, mas mostrar, inclusive, exemplos de código, ilustrando soluções arquiteturais e abordagens de reuso de software, que ofereçam maior controle aos projetos e tornem a manutenção mais fácil.

O próximo artigo tratará sobre as tarefas específicas da construção de software e de que outras atividades elas dependem. E como os problemas nessas atividades podem afetar (de forma negativa) a construção. E, finalmente, como os construtores podem se proteger e evitar noites e finais de semana perdidos.

[1] McConnell, Steve. Code Complete: Um guia prático para a construção de software.

• Discutir os objetivos e importância de temas da Engenharia de Software.
• Possibilitar a seleção e aplicação de técnicas de engenharia e princípios de gestão no contexto de Engenharia de Software adequadamente em ambientes específicos de construção de software.
• Desenvolver um olhar crítico sobre as diversas técnicas e estratégias gerenciais empregadas em Engenharia de Software.

Público Alvo
Desenvolvedores em geral, Gerentes e Coordenadores de Projetos.

Conteúdo

• Modelos e Métodos de Gestão da Qualidade de Software por Renato de la Volpe
• Engenharia de Requisitos por Márcia Ito
• Implantação de Processo de Desenvolvimento de Software por Alvaro D´Alessandro
• Gerenciamento de Projetos no Desenvolvimento de Software por Aldo Andrade
• Gestão de Processos de Negócio (BPM), SOA e Arquitetura Corporativa por Eduardo Endo

Data: 17 de Julho - Sábado: 9h00 às 18h00
Local: Century Flat Paulista - R. Teixeira da Silva, 647 – Paraíso – São Paulo – SP
Mais informações: http://www.temporealeventos.com.br/?area=172

Compre este livro!

Descrição

A cada dia, mais profissionais e empresas estão interessados em desenvolver softwares com qualidade, menores custos de manutenção e dentro dos prazos previstos. Com essa intenção, tais profissionais e empresas necessitam adquirir maturidade no ciclo de desenvolvimento do software e utilizar Engenharia de Software.

Este livro ensina como utilizar disciplinas do CMMi integrado a Engenharia de Software em todo o ciclo de desenvolvimento de software. Por meio de estudo de caso de comércio eletrônico e partindo de solicitação da área de negócio, o leitor será levado por todo o ciclo de vida do projeto, percorrendo vários processos necessários para certificação CMMi. No estudo de caso, apresenta uma série de templates que podem ser utilizados em projetos da vida real.

Destina-se a profissionais, estudantes e professores interessados em aumentar sua competência como profissionais da área de Tecnologia da Informação relacionada ao desenvolvimento de software, aprendendo na prática conceitos prescritos na Engenharia de Software, para produzir soluções elegantes, compartilhar ideias e tomar decisões por meio de um ciclo completo de projeto e desenvolvimento. Pode ser de utilidade às empresas interessadas em implementar em sua metodologia de desenvolvimento de software processos e melhores práticas de mercado, alinhados ao modelo de maturidade CMMi desenvolvido pelo SEI.

O que este livro aborda:

• Processos de desenvolvimento de software
• Gerenciamento e engenharia de requisitos
• Gerenciamento de mudanças
• Gerenciamento de riscos
• Gerenciamento de qualidade
• Gerenciamento de configuração
• Processos de análise, arquitetura e design de software
• Processos de construção, testes de software e implantação
• Tecnologia orientada a objetos
• Templates para utilização em projetos
• Análise e design orientado a objetos com UML

Albert Einstein

Nossa área de desenvolvimento de software é muito nova, e como consequência disso, ainda estamos aprendendo quais são as técnicas que funcionam e quais só atrapalham o dia-a-dia dos nossos projetos. É dever de todo profissional da área buscar meios para melhorar o nosso objetivo principal: Construir softwares que atendam aos clientes, aos usuários e às equipes de desenvolvimento.

Práticas ágeis são um meio e não um fim, não deve-se utilizar as técnias se não é evidente quais problemas elas tentam resolver, usar por usar não melhora em nada o resultado final do seu projeto. Você só deve usar essas práticas se realmente entender porquê elas são necessárias, e não porquê estão na moda.

Vamos observar os benefícios de algumas técnicas utilizadas no meio ágil:

Com TDD o programador cria o hábito de planejar suas tarefas antes de executá-las, isso se deve ao fato de que nessa técnica você começa pela elaboração de uma lista de testes para o artefato que será desenvolvido, e só depois começa a codificá-lo. Outro benefício do TDD é que o programador deve usar o seu código antes de implementá-lo, apesar de parecer estranho é uma quebra de paradigma excelente começar a codificação pelo teste e tomar as decisões de design do código antes de implementá-lo, isso reduz o retrabalho pois o programador percebe no início da codificação como ficará seu código ao final dela.

Muitos gestores ainda não acreditam nos benefícios da programação em par, sendo um dos motivos a sensação de perda de produtividade quando dois programadores são alocados para a mesma tarefa, essa sensação é falsa, pois existem uma série de fatores que devem ser levados em consideração quando falamos de produtividade. O ritmo de desenvolvimento da dupla é garantido pela falta de distrações que um programador sozinho teria, dificilmente durante o desenvolvimento em par o “piloto” irá desviar do foco. Outro benefício da programação em par é a revisão que o “co-piloto” faz observando a codificação do piloto, muitos problemas podem ser identificados em tempo de codificação. A comunicação constante entre os programadores faz com que cada decisão seja mais bem pensada, e ainda traz um grande benefício: Dois membros da equipe vão conhecer aquele trecho do código, isso é essencial para contornar problemas de comunicação e troca de membros da equipe durante o desenvolvimento dos projetos. A programação em par protege o investimento do projeto pois reduz a taxa de retrabalho da equipe e gera um código de qualidade superior, afinal, duas cabeças pensam melhor do que uma.

Desenvolver um software de forma iterativa e incremental traz uma série de benefícios, porém, também traz uma série de problemas. Desenvolver software em ciclos de tempo fechados faz com que cada minuto seja precioso, por isso, vários impedimentos são identificados ao longo do desenvolvimento e resolvidos a medida que as entregas são realizadas no final de cada ciclo. Como o desenvolvimento acontece em ciclos, a equipe de desenvolvimento pode aprender com os problemas enfrentados no ciclo anterior, isso permite que o processo de cada equipe possa ser melhorado continuamente, e essas melhorias sempre atacam um grande impedimento do clico anterior, ou seja, não são apenas melhorias por melhorias. Processos iterativos e incrementais também auxiliam a contornar o grande vilão dos projetos de software que é a mudânça de escopo, caso o cliente descubra uma nova necessidade a mesma poderá ser implementada no próximo ciclo, já que o ciclo em desenvolvimento não deve ter seu objetivo alterado. Caso a necessidade do cliente mude (ou melhor, quando a necessidade do cliente mudar) e o ciclo desenvolvido não for mais necessário, o cliente só “perde” aquele ciclo, ou seja, o custo da alteração de escopo fica sendo o custo do desenvolvimento do novo ciclo. Outra característica interessante é que nessa forma de desenvolvimento os feedbacks dos usuários chegam muito mais cedo do que no modelo tradicional, já que no final do ciclo a equipe entrega um parte funcional do software, e já que o software entra em produção mais cedo o cliente também começa a usufruir dos benefícios do sistema mais cedo.

As técnicas ágeis são um meio para solucionar alguns dos problemas mais comuns dos ambientes de desenvolvimento como conhecemos (falta de comunicação, retrabalho, escopos rígidos, custos altos, falta de testes, etc.), elas propõem uma nova forma de trabalho, que tem se mostrado muito eficiente para equipes com o perfil adequado. Essas técnicas influenciam positivamente em todas as vertentes de avaliação da qualidade de um software desde que sejam aplicadas de forma correta.

Quer saber mais sobre as técnicas citadas? Seguem algumas referências:

Sobre TDD:

• TDD no Wikipédia
• Desenvolvimento orientado a teste – Por @viniciusteles
• Portal TDD
• Tudo sobre TDD – Por @victorhg
• Apresentação que utilizo em treinamentos – Por Fabrício Mattos
• Podcast TDD não existe

Sobre Programação em Par:

• Dicas sobre Programação em Par – Por @lucianofelix
• Par Programming no Wikipédia
• Programação em Par – Por @viniciusteles

Sobre desenvolvimento iterativo e incremental:

• Desenvolvimento iterativo e incremental no Wikipédia
• Escopo Iterativo e Incremental para o gerenciamento Ágil de requisitos – Por @visaoagil
• Scrum no Wikipédia
• Scrum - Por @viniciusteles
• Scrum Alliance
• Scrum.org

Qual a sua experiência sobre as técnicas ágeis? Você acha que elas são o caminho para aumentarmos a qualidade dos softwares que desenvolvemos?

Aguardo feedbacks!

Texto originalmente publicado em www.heroisdati.com.

Segundo Gilleanes Guedes, o especialista, o treinamento iniciará com uma breve introdução sobre a UML, explanando rapidamente os objetivos de cada um de seus diagramas. Em seguida será feita uma rápida revisão sobre orientação a objetos, conhecimento imprescindível para a real compreensão da UML.

Para participar é baba, basta tuitar/retuitar a mensagem abaixo:

http://migre.me/yffS Quero ganhar curso e livro de #UML da @treventos e @profissionaisti. RT para participar!

Sorteio acontecerá na quinta (22/04) às 16hrs entre os que tuitaram a mensagem acima. O ganhador será avisado via Twitter e deverá confirmar sua presença no curso para poder ganhar o livro também.

Desejo sorte a todos!

Resultado

E quem vai aprender UML com a Tempo Real Eventos di grátis é: @techlivre – http://sorteie.me/faP

E quem vai aprender UML com a Tempo Real Eventos di grátis é: @tonapraia – http://sorteie.me/fXi

E quem vai aprender UML com a Tempo Real Eventos di grátis é: @diogomds – http://sorteie.me/gK9

E quem vai aprender UML com a Tempo Real Eventos di grátis é: @tin13 – http://sorteie.me/h6r

E quem vai aprender UML com a Tempo Real Eventos di grátis é: @lucas_lra – http://sorteie.me/hqy

O ganhador deve confirmar sua presença no curso até quarta (04/05) às 14hrs. Lembrando que só ganha o livro se comparecer ao curso que acontecerá no dia 8 de maio em SP, por isso, é necessário confirmar presença. Caso não tenhamos retorno até a data estabelecida acima, um novo sorteio será realizado.

________________________________________

Mais informações sobre o curso: http://www.profissionaisti.com.br/2010/04/curso-uml-2-uma-abordagem-pratica-de-conhecimentos-essenciais-e-inovadores/

Participe de outras promoções do PTI, aproveite!

A semana continua quente com as discussões sobre usabilidade, interfaces, Windows Client, Silverlight, Win32, experiência do usuário e recursos presentes na plataforma cliente.

Um tempo atrás, vi uma sessão conduzida pelo arquiteto Simon Guest da Microsoft. Ele fez um discurso muito interessante sobre User Interfeace (UI) versus User Experience (UX). Se preferir, UI vs. UX

Imagine que você é chamado para ajudar na arquitetura de uma aplicação, que possui grandes demandas para a interface do usuário. Porém, você é chamado para questões como atualização de dados em certos componentes de tela, melhor comunicação entre projetos da interface, mais animação ou menos animação, tipos de protocolos para tráfego de imagens, streaming de vídeos, etc. Na defesa do Simon, esse tipo de questionamento está mais ligado ao USER INTERFACE e não ao USER EXPERIENCE.

Assim, posicionamos no USER INTERFACE os diversos aspectos de controles gráficos, tipos visuais, imagens, renderização, etc, que formam o resultado final da interface. Quando falamos em UX ou USER EXPERIENCE estamos preocupados com a abordagem escolhida para a interação do usuário com nossa aplicação. Colocar animações diversas no canto superior esquerdo em formulários de dados é bem diferente de escolher uma abordagem MULTI-TOQUE para a navegação pelo menu de opções da aplicação, por exemplo.

Até hoje, vimos muito exemplos de abordagens inovativas e USER EXPERIENCE na Web 2.0, com sites e Web Designers abusando da criatividade e da ousadia, encantando milhares de usuários pela Web. Porém, assim como vimos o conceito de mashup migrar para o mashup corporativo, abordagens criativas e USER EXPERIENCE de fato começa a descer com mais força para o cenário enterprise.

Pensando em plataforma Microsoft, hoje estamos falando de Windows 7, .NET 4.0, WPF 4, mas como desenvolvedores e arquitetos já vimos uma infinidade de tecnologias na plataforma Windows Client. Com certeza você já utilizou ou ainda utiliza uma dessas tecnologias. Alguns exemplos são:

para a User Interface:

• Accessibility
• Gadgets
• International Support
• Microsoft Agent
• Text Services Framework
• Windows Animation Manager
• Windows Controls
• Windows Ribbon Framework
• Windows Shell
• Windows Touch
• Windows User Interface
• Desktop Window Manager
• Resource Compiler
• Windows Help

para Graphics e Multimedia

• Audio e Video
• Direct2D
• DirectWrite
• DirectX
• GDI+
• Monitor Configuration
• OpenGL
• Print Schema
• Picture Acquisition
• Windows Color System
• Windows GDI
• Windows Image Acquisition (WIA)
• Windows Imaging Component (WIC)
• Windows Media Center Software Development Kit
• WPF Bitmap Effects

Sem falar de outros componentes como Data Access, System Services, Storage, Devices, Diagnostics, Messaging e Collaboration, Security, COM+, Transactions, etc. Todas essas tecnologias são nativas do sistema operacional, presentes como recursos do Windows Client. Portanto, são exemplos de funcionalidades que sairam do escopo da aplicação e passaram para o sistema operacional, facilitando o desenvolvimento de aplicações Desktop com grande USER EXPERIENCE e USER INTERFACE.

Entre os vários anúncios feitos durante o último PDC09, vimos que o Visual Studio 2010 seria construído sobre o WPF – Windows Presentation Foundation. Em adição, o VS estaria usando agora o MEF como mecanismo de extensibilidade.

O que é o MEF?

O Managed Extensibility Framework (MEF) é uma biblioteca nova do .NET 4.0 que torna fácil a extensão e o reuso de componentes. Em linhas gerais, o MEF fornece padrões para o host de aplicações, discover, exposição e consumo de componentes de extensão, sem a necessidade de acomplamento entre eles. No coração do MEF encontramos o ComposablePart, que exporta serviços ou consome serviços fornecidos externamente. Isso é feito usando um Contrato, que é referenciado de forma simples, através de Import (para consumo) ou Export (para exposição).

O MEF ainda está em desenvolvimento, mas você encontrará mais material no site do CodePlex, aqui:

Managed Extensibility Framework (MEF)
Ref.: http://www.codeplex.com/MEF

Tem sido interessante resgatar as várias tecnologias presentes no Windows Client e seus recursos. Na velocidade das coisas, nossos usuários corporativos já são tão exigentes em relação a usabilidade quanto nossos usuários de internet mais conectados. Por isso, vale conhecer o SO que você está utilizando no mundo cliente.

Por enquanto é só!

Referência: Blog Waldemir

Um abraço!

Waldemir Cambiucci
Blog: http://blogs.msdn.com/wcamb/
Twitter: http://twitter.com/wcamb/

Um assunto que de tempos em tempos aparece em conversas com arquitetos e empresas do mercado é a Missão Crítica em projetos.  Mas o que você entende por um projeto de Missão Crítica?

Do wikipedia temos que o termo Missão Crítica refere-se a qualquer fator (equipamento, processo, procedimento, software, etc.) que seja crucial para o sucesso ou completude de uma atividade ou projeto. Também pode se referir a um projeto cujo o sucesso é vital para a missão da organização ou negócio da empresa.

Falando em projetos, vejamos alguns exemplos que considero de Missão Crítica:

- Um sistema de controle e coleta de dados de um projeto em Física Experimental para criação de estado de plasma, rodando sobre sistema operacional Debian/Linux, com processos em C, usando pilha TCP, pode ser considerado de missão crítica para o laboratório, devido as restrições e riscos envolvidos na monitoração e controle de equipamentos;

- Um núcleo de negociação para o mercado financeiro, tratando milhões de operações/dia, envolvendo mensageria em banco de dados, cache distribuído, gerenciamento de recursos em memória, etc., com requisitos rígidos de baixa latência, também é um exemplo de missão crítica;

- Um SDCD – Sistema Digital de Controle Distribuído – para monitoração e atuação de bicos de óleo em caldeiras para a geração de vapor num planta industrial, também é um belo exemplo. Vapor é um elemento chave em diversos processos industriais, de petroquímicas a processamento de atum em lata!

- Um monitor transacional de alto desempenho, aplicando conceitos como ACID, MUTEX, CRITICAL SESSIONS, SEMÁFOROS, árvores de falhas, etc, é outro exemplo. Uma leitura obrigatória sobre o assunto é o livro Transaction Processing, confira aqui!

- Um sistema SaaS – Software as a Service – sobre algum provedor em nuvem, para uma solução multi-inquilino com interfaces Web, responsável pelo núcleo de faturamento da empresa, é de missão crítica, com requisitos de disponibilidade, responsividade e desempenho. Imagine um sistema SaaS para a venda de ingressos do show de Eric Clapton ou B.B. King!

- Um sistema de automação para controle de caixas margem de via, por exemplo, para determinação de presença de trens de metrô e vagões em trechos da via, abertura de portas, desvios de ramais, movimento, etc. O próprio controle do carrossel de composições na via também é crítico. Qual é o trem mais seguro? Um trem parado ou um trem na oficinal, fora da via?

- Um sistema para contabilidade e bilhetagem de chamadas em telefonia celular, também é crítico; – Em muitos cenários, até mesmo um sistema de emails é um sistema de missão crítica para a empresa. Algumas corporações simplesmente param ou perdem negócios em casos de falha em suas caixas postais, por mais commodities que possam parecer. Impacto financeiro a vista!;

- Um sistema de controle de equipamentos médicos, como scanners, tomógrafos, dispositivos de ultra-som, leitores dopplers em tempo real (opa!), entre outros mais sofisticados em medicina, são extremamente críticos em seus resultados.

Considero todos os exemplos acima como sistemas de Missão Crítica em diferentes níveis, pois envolvem riscos para o negócio da empresa. Assim, podemos destacar três tipos de riscos envolvidos:

• Riscos Materiais;
• Riscos Financeiros;
• Riscos envolvendo Vidas Humanas;

Alguns sistemas de Missão Crítica podem envolver requisitos de Tempo Real (Real Time), isto é, janelas de atuação e tempos resposta bem definidos, que devem ser respeitados. Nesses casos, o número de processos envolvidos, o volume ou o número de chamadas disparadas não deve interferir no tempo de resposta do sistema.

Qual é o tempo de resposta envolvido no tempo real (em milisegundos, por exemplo)? Dependerá do cenário que estamos tratando, seja um canal de feeders de notícias com filtros sobre política ou mensagens para a abertura de cofres em sistemas de segurança bancário. Normalmente, condições de tempo real estão envolvidas em cenários de missão crítica, mas não são obrigatórias.

Meu ponto aqui é que não podemos considerar como Missão Crítica apenas o aspecto de desempenho e tempo de resposta envolvidos. Para algumas indústrias, outros atributos são tão importantes quanto, como o impacto financeiro, disponibilidade e riscos diversos.

Quão crítico é o sistema em que você está trabalhando hoje? Ele envolve riscos financeiros, riscos humanos ou riscos materiais? Qual é o impacto de uma falha em seu sistema para a execução do negócio de sua empresa? Aspectos como recuperação de falhas, tratamento de exceções, árvore de falhas, etc., tornam-se importantes em muitos casos.

Mais recentemente, tenho acompanhado a plataforma Microsoft e seu suporte para aplicações de missão crítica em diferentes níveis.

Existem diversos recursos que atendem esses cenários, seja sobre a plataforma .NET ou mesmo sobre código não gerenciado, com processos em C++ sobre Windows Server. No ambiente gerenciado, recursos como interfaces de serviços em WCF – Windows Communication Foundation, mensageria com MSMQ, paralelismo, sincronização e sistemas de integração com baixa latência são alguns exemplos. Em todos os casos, o impacto para o negócio da empresa está presente.

Em breve, teremos ainda novos recursos disponíveis na plataforma, como o Dublin (para hospedagem de serviços e processos sobre o Windows Server), o Velocity (para cache distribuído e aplicações de alto desempenho), os novos WCF 4 e WF 4, além da integração com a plataforma de alta escalabilidade e disponibilidade do Windows Azure, que já está em contagem regressiva para seu lançamento, agora em novembro de 2009.

Finalizando, procure identificar em quais cenários de Missão Crítica você está pessoalmente envolvido e como será a evolução destes nos próximos meses. Você vai perceber que sua TI tem um impacto direto para o sucesso de sua empresa!

Um abraço!

Waldemir Cambiucci
Blog: http://blogs.msdn.com/wcamb/
Twitter: http://twitter.com/wcamb/

Para conferir os outros posts da série:
Parte I - http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c/
Parte II - http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c-parte-ii/

Neste artigo abordaremos depósitos.

A primeira coisa que precisamos fazer para realizar nosso depósito é escrever um teste:

[TestMethod]
public void Deve_Realizar_Deposito()

{

    var conta = new ContaBancaria(10);

    conta.Depositar(10);

}

Este método ainda nem compila, afinal precisamos implementar o método Depositar na classe ContaBancaria.
E o resultado deve ser este (lembrando que fazemos o mínimo para o programa compilar e rodarmos o teste):

public void Depositar(decimal valorDoDeposito)

{

}

Agora vamos executar todos os nossos testes. É importante executarmos todos os testes para garantir que tudo funciona:

Percebam também a importância de um nome descritivo para os testes. Desta forma podemos saber exatamente o que está sendo garantido com aquele teste.

Agora conseguimos um verde, afinal nosso teste apenas garante um depósito. Vamos prosseguir criando um teste para verificar se o valor depositado foi somado ao saldo:

[TestMethod]
public void Deve_Realizar_Deposito_de_5_Em_Conta_Com_Saldo_10_E_Saldo_Deve_Ficar_15()

{

    var conta = new ContaBancaria(10);

    conta.Depositar(5);

    Assert.AreEqual(15, conta.SaldoAtual);

}

E ao rodarmos nossos testes temos:

O erro é bem claro: diz que estávamos esperando 15 e o resultado foi 10. Isso por que nosso método de depósito não possui nenhuma implementação.
Agora vamos alterar o código para que consigamos um verde nos testes:

public void Depositar(decimal valorDoDeposito)

{

    this.SaldoAtual = 15;

}

E executando nossos testes:

Agora que conseguimos um verde, devemos escrever mais testes para garantir que tudo funciona:

[TestMethod]
public void Deve_Realizar_Deposito_de_10_Em_Conta_Com_Saldo_10_E_Saldo_Deve_Ficar_20()

{

    var conta = new ContaBancaria(10);

    conta.Depositar(10);

    Assert.AreEqual(20, conta.SaldoAtual);

}

E rodando nossos testes temos:

Isso mostra que o código que escrevemos para o teste anterior passar deve ser alterado para que todos os testes passem. Desta forma obtemos o seguinte código no método Depositar:

public void Depositar(decimal valorDoDeposito)

{

    this.SaldoAtual += valorDoDeposito;

}

Agora precisamos executar todos nossos testes para ver se tudo está ok:

Bom galera, espero ter mostrado mais um pouco de TDD para vocês.

Na próxima parte do artigo abordaremos como testar a interação com um repositório de contas.

Abraços e até a próxima.

Original em: http://www.viniciusquaiato.com

Buscando na web, encontrei um artigo bacana escrito por José Carlos Macoratti no qual estarei abaixo compartilhando com vocês com o consentimento do próprio autor.

Se você é um desenvolvedor de software , quer como consultor independente quer trabalhando em uma empresa de desenvolvimento de software , com certeza já ouviu muitas vezes as seguintes indagações:

Quanto custa o desenvolvimento deste sistema? ou Quanto você cobra para desenvolver este sistema?

Qual o prazo de entrega do sistema? ou Quanto tempo você leva para desenvolver este sistema?

Isto é perfeitamente normal e previsível , afinal um cliente tem o direito de saber quanto vai custar e em quanto tempo vai ficar pronto o produto que ele deseja receber.

O que não é normal é o fato de que mesmo convivendo com estas indagações no seu dia dia a tanto tempo , você , quer como gerente de projeto ou desenvolvedor , não ter condições de responder com segurança a nenhuma delas.

Quando você contrata o serviço de um pedreiro , ele , após saber exatamente o que tem que fazer faz alguns cálculos e lhe da o preço final do seu trabalho. O mesmo ocorre nas áreas de engenharia civil , mecânica , etc.

Por que é tão difícil estimar o valor de um projeto de software ? Por que é tão complexo fazer estimativas nesta área ?

Seria porque software não têm peso , nem cheiro ? ou seria o fato de que não vemos e nem sentimos um software ?

Creio que as respostas a estas indagações seriam feitas se você soubesse responder a seguinte pergunta:

Qual o tamanho do sistema?

Para saber o tamanho do sistema é necessário realizar medições ou medidas. Certo ?

Certo, pois, “não se consegue controlar o que não se consegue medir”. (Tom DeMarco)

A métrica é o número que você vincula a uma idéia. Para o projeto de software comum , os aspectos quantitativos onde mais precisamos usar a métrica são: escopo, tamanho, custo, risco e tempo empregado.[1]

Para que a métrica usada seja útil ela deve possuir as seguintes características: ser mensurável , ser independente, ser explicável e precisa.

Creio que agora você concorda em que há fortes motivos para medir o seu sistema , dentre estes motivos temos:

• Fornecer subsídios para determinar o esforço, os recursos, a duração e os custos de desenvolvimento
• Avaliar a produtividade do processo de desenvolvimento adotado
• Formar uma base histórica para embasar estimativas futuras

• Indicar a qualidade do produto

Então qual a medida que você deve usar para determinar o tamanho do seu sistema ?

Tipos de medidas de tamanho de software

1- SLOC – linhas de código

Medir software contando as linhas de código (SLOC) é uma das medidas mais antigas para determinar o tamanho, esforço e produtividade no desenvolvimento de software.

È muito fácil de usar e aplicar; basta contar a quantidade do número de linhas de código de um programa.

A medida de SLOC é considerada uma medida física do tamanho de software por medir o volume de código-fonte de um programa.

Ela tem no entanto as seguintes desvantagens :

• Depende da linguagem de programação usada (o número de linhas de um programa Cobol é totalmente diferente de um em Java)
• Ausência de padrões de contagem. (Cada linguagem possui suas características de sintaxe e semântica)

• Não pode ser aplicada nas fases iniciais de desenvolvimento (No início o programa ainda não esta escrito)

Nota: No site http://sunset.usc.edu/research/COCOMOII/ você pode fazer o download de um aplicativo demo da Softstar para realizar estimativas de tamanho usando SLOC.

2- APF – Análise de Pontos por função

Podemos dizer que atualmente á a técnica mais usada para medir o tamanho de projetos de software. Foi criada por Alan Albrecht na IBM na década de 70 e consiste em determinar o tamanho funcional (o que é entregue) do sistema através da visão do usuário.

Ela possui as seguintes vantagens:

• Independe da tecnologia utilizada
• É simples de usar e ser entendida pelo usuário e desenvolvedores
• é consistente e intercambiável
• Pode ser utilizada desde o início do sistema.

A APF (Análise de Pontos por Função) pode ser vista como um técnica que permite dimensionar o tamanho de um software a ser desenvolvido , melhorado ou adquirido; e também um técnica para realizar estimativas de custo e recursos para o desenvolvimento e manutenção de software.

A utilização da APF esta normalizada em um manual de contagem de pontos de função da IFPUG (International Function Point Users Group) constituída em 1996.

Obs: O chapter do IFPUG no Brasil é o BFPUG – Brazilian Function Point Users Group. (Constituído em 1998)

O esquema do processo de contagem de pontos por função é dado na figura abaixo:

Para que você tenha uma idéia dos PF como medida de volume de software abaixo é apresentada uma tabela que mostra o tamanho aproximado de algumas aplicações tipos em pontos por função.[2]

Eu não vou dar detalhes sobre como usar o manual de contagem mas vou dar um exemplo de como você pode usar o resultado obtido usando a APF para estimar esforço , prazo e custo de um software.

Vamos supor que você foi consultado sobre o desenvolvimento de um sistema cadastro de clientes onde é possível realizar as seguintes tarefas:

• Listagem por ordem alfabética
• exportar o cadastro para outro sistema via arquivo texto

Usando o manual de contagem da APF teríamos:

ALI – 01 ( o arquivo de clientes )
AIE – 0
EE – 01 ( inclusão de cliente )
SE – 01 ( listagem por ordem alfabética )
CE – 01 ( exportar arquivo texto)

Se considerarmos todos os tipos de função como de complexidade Baixa teremos:

Pontos de função Brutos não ajustados :

PFB = ALI x 7 + AIE x 5 + EE x 3 + SE x 4 + CE x 3 = 1 x 7 + 0 x 5 + 1 x 3 + 1 x 4 + 1 x 3 = 17

Contando os fatores de ajustes teremos um total igual a 45.

Valor de fator de ajuste :

VFA = 0,65 + (0,001 x 45 ) = 1.1

Valor dos pontos de função Ajustados:

PFA = VFA x PFB = 1,1 x 17 = 18,7

Pronto!

Usando APF chegamos ao tamanho do sistema.

O seu tamanho é 18,7 pontos por função.

E agora ?

Nota: Dizer que o tamanho de um projeto é de 1000 PF nada significa. Quando podemos comparar medidas feitas em APF é que as coisas começam a fazer sentido. Assim se temos dois projetos , um com 1000 PF e outro com 2000 PF, podemos concluir que o segundo temo o dobro do tamanho do primeiro.

Assim como dizer que uma construção possui 400 metros quadrados de área construída não nos permite estimar , apenas levando em conta esta medida , valor da mesma; dizer que um projeto possui 3000 PF também não nos dá a idéia do custo do projeto.

Agora podemos estimar esforço , prazo e custo. Para isto iremos usar as seguintes considerações:

1- Considerando que uma produtividade média de 10 hs / PF.

2- Considerando que a média de jornada de trabalho é de 6 horas.

3- Considerando que o valor de uma hora de trabalho é de R$ 25,00.

Concluímos que :

Esforço = 10hs / PF = 10 x 18,7 = 187 horas
Prazo = 187 h / ( 4 x 6 ) = 7,8 dias
Custo = 187 h x R$ 25,00 = R$ 4.675,00

Foram usadas as seguintes fórmulas:

Produtividade no desenvolvimento = Horas por PF
Esforço de desenvolvimento = Produtividade(H/PF) * Tamanho(PF)
Custo de software = Tamanho (PF) * Custo(R$/PF)

Neste artigo procurei abordar de forma simples e objetiva a importância da utilização de métricas no desenvolvimento de projetos software com a finalidade de realizar estimativas.

A métrica de software e suas implicações é um assunto muito vasto que você poderá pesquisar nos links dos sites indicados e também em:

NESMA – http://www.nesma.nl/english/nesma&ifpug.htm
COCOMO – http://www1.jsc.nasa.gov/bu2/COCOMO.html
FATHO – http://www.fattocs.com.br/
Aplicativo para auxiliar na contagem APF – http://www.bsb.netium.com.br/mecenas/apf.htm

Por enquanto lembre-se sempre que :

“Se você não sabe para onde deseja ir , um mapa não vai lhe ajudar.”

Referências

[1] – DeMarco, Tom – Controle de projetos de Software – Editora Campus, 1991.
[2] – Jones, Capers – Estimating Sofware Costs – McGraw-Hill, 1998. Veja também www.spr.com site da empresa do autor.