sauloarruda.eti.br

…revirando até chegar do outro lado…

February 10th, 2010

Venho estudando um framework para Behavioral Driven Development chamado Cucumber e me impressionado com a facilidade e clareza que a atividade de implementar testes automatizados vem se tornando. Para quem quiser saber mais sobre Cucumber, antes mesmo de continuar essa leitura, recomendo consultar esses links:

O foco deste, é apresentar minha experiência em usar o Cucumber integrado com o Selenium e mostrar um exemplo de como é simples implementar testes funcionais. Para começar, leia essa documentação que explica como configurar seu ambiente. Se você usa MacOS Snow Leopard (10.5) deve passar pelos mesmos problemas que eu tive e que encontrei a solução neste link.

A idéia central é escrever estórias para teste de telas (caixa preta). Disponibilizei no github o código-fonte da aplicação em Rails que está sendo testada e de outra aplicação, somente Ruby, usando Cucumber + Selenium. Para demonstrar o uso do Selenium, escolhi um cenário bastante simples, trata-se de um história de autenticação de usuários:

Perceba que nos preocupamos em escrever a história o mais “User Friendly” possível. Isso facilita bastante o entendimento sobre o que você está de fato testando e o que o seu usuário (ou cliente) acha que você deveria testar. E, como você já deve saber, as palavras-chave “dado”, “quando” e “então” representam ações que são implementadas em Ruby. Para começar, configuramos no arquivo support/env.rb o ambiente da API para Selenium em Ruby criando uma instância da classe Selenium::SeleniumDriver

No arquivo support/paths.rb configuramos o mapeamento de nome de páginas para URIs e também de label de campos para o nome do campo no formulário HTML. Os métodos path_to, field_for e button_for fazem essas funções.

OK, concordo com vocês que essas funções não fazem lá muita coisa, mas lembre-se que estamos fazendo o nosso primeiro caso de teste, tenha certeza que serão úteis no futuro próximo. Um exemplo que eu já posso citar foram os testes que implementamos para testar uma aplicação, na verdade um portal, desenvolvido em Drupal, onde o “label” dos campos não era nem um pouco parecido com o nome (do componente HTML) do campo. Lembrando que as histórias tem de ficar o mais próximo possível da taxonomia (ou idioma) do seu usuário.

Agora, vamos à parte que interessa, de fato a implementação dos passos descritos nas estórias. Criei o arquivo step_definitions/common_steps.rb contendo os passos mais comuns que você deverá usar na maioria de suas estórias. Para passos específicos de determinada história, recomenda-se criar um outro arquivo no diretório step_definitions com o nome da estória.

O exemplo é bastante simples, e a aplicação Rails do github contém uma implementação bastante simples do que está sendo testado. Para executar, basta usar o comando “cucumber” na raiz do projeto de testes. Lembrando que você deve iniciar o servidor do Selenium usando o comando “selenium” (isso funcionou pra mim após instalar o Selenium RC).

Se você tiver dúvidas ou problemas na execução do exemplo, fique à vontade de postar nos comentários que farei o possível para tentar ajudar. E, por hora ficamos por aqui. Em breve devo postar alguns exemplos de passos mais complexos como uso de tabelas e/ou editores ricos. Estamos trabalhando nisso agora!

November 4th, 2009

Neste final de semana finalmente participei do segundo encontro presencial na UFLA (Universidade Federal de Lavras) para conclusão do curso de Especialização em MPS (Melhoria do Processo de Software) que iniciei em 2006. O encontro foi extremamente produtivo visto que havia poucos alunos e com isso temos a oportunidade única de ter consultorias ao invés de aulas com professores de altíssimo nível. Fora que com pouca gente a interação entre os alunos foi infinitamente maior o que com certeza vai promover amizades produtivas.

No sábado eu tive a oportunidade de apresentar meu Trabalho de Conclusão de Curso que trata-se de um artigo entitulado: Gerenciando Projetos de Escopo Aberto – Uma Visão Ágil. Ainda tenho alguns ajustes para fazer, mas já disponibilizei uma prévia do trabalho em PDF e depois atualizo esse post com a versão final (para fazer o download clique no link do nome do trabalho).

É uma pena esse curso ter acabado. Mas já deixo a recomendação de outro curso, na verdade um MBA, que tem como coordenador um dos professores. Trata-se do MBA Gestão da Qualidade em Software com ênfase em CMMI® e MPS.BR da FIAP, e o coordenador é o sensacional Nilson Salvetti.

Como voltei bastante animado do encontro, em breve devo publicar, em parceria com alguns colegas, artigos que estamos preparando sobre teste de integração e gerenciamento de projeto “agile”. Pode me cobrar se eu não enviar! Estou até animado a embarcar em um mestrado na área de Engenharia de Software, e aceito recomendações!

May 28th, 2008

Planejar e controlar projetos de software são atividades que boa parte das empresas tem conseguido desempenhar em seu processo de desenvolvimento. Porém, medir qual desenvolvedor é mais produtivo, re-alimentar o processo de estimativa e coletar informações para tomada de decisão quando o projeto “sai dos trilhos” é uma tarefa bastante complicada.

Neste artigo, vou apresentar a experiência que implantamos na área de Produção de Software da Agence para medição da produtividade.

Primeiro Passo: Estimativa

Qualquer planejamento de projeto de software é elaborado com base em uma estimativa, especialmente em “Fábricas de Software” que muitas vezes trabalham com projetos de escopo fechado e orçamento pré-definido.

Na Agence, usamos basicamente três métodos para estimar o tamanho de um projeto:

Para pequenos projetos, inferiores a 300 horas, usamos uma Planilha de Estimativa onde são estimadas horas de trabalho para cada uma das disciplinas da Engenharia de Software (análise e projeto, requisitos, codificação, testes, implantação, etc.). Este método é bastante simples, mas exige experiência do profissional que faz a estimativa, é bastante suscetível a falhas e é calçado em um histórico de experiências anteriores do mesmo tipo.

Para projetos maiores, usamos contagem de Pontos por Função e/ou de Pontos por Caso de Uso. Esses métodos têm o embasamento científico de várias pesquisas com projetos de empresas diferentes e devem ser calibrados pela complexidade e natureza do projeto e também pela qualidade da equipe.

Segundo Passo: Planejamento

Com a estimativa em mãos, é hora de planejar o projeto. Na Agence trabalhamos com o modelo Iterativo e Incremental de ciclo de vida. Logo, a primeira fase do planejamento é definir as iterações do projeto e quais artefatos serão entregues em cada uma.

Seguindo o princípio do Unified Process (UP), temos quatro fases no ciclo de vida do projeto: Iniciação, Elaboração, Construção e Transição.

A fase de Iniciação na maioria dos casos refere-se à prospecção do projeto junto ao cliente e não possui um planejamento formal. Nesta fase o Consultor de Negócio (figura do Analista de Requisitos) entrevista o cliente, documenta os requisitos e prototipa a solução. Nesta fase o projeto é estimado e uma proposta apresentada ao cliente. Se o cliente aprovar, o projeto continua.

Na fase de Elaboração, o planejamento do projeto como um todo é elaborado. Além disso, o Modelo de Casos de Uso é detalhado e a Arquitetura da Solução é desenvolvida. Nesta fase, existe uma maior participação do Gerente de Projeto, Analista de Requisitos e Arquiteto.

A partir da fase de Construção que o trabalho pesado começa. Nesta fase, há sempre uma versão utilizável do sistema (ou incremento) produzida por mês, independente do tamanho do projeto ou da equipe. Essa entrega da versão formaliza o término de uma iteração e início de outra.

Na fase de Transição, o software é instalado em ambiente de homologação/produção e avaliado pelo cliente e usuários final. Muitas vezes são executados testes de carga e stress, projetos pilotos da operação do sistema e treinamentos.

Terceiro passo: Controle

Diariamente, os profissionais fazem seu trabalho e registram as horas gastas em uma ferramenta de controle de projetos. No final de cada iteração o Gerente de Projeto mede os registros de trabalho dos profissionais e compara com os valores inicialmente estimados.

Naturalmente, o cliente fará uma avaliação da versão entregue no término da iteração e novas pendências podem aparecer. O tempo para os ajustes geralmente está contabilizado na estimativa para o desenvolvimento da funcionalidade.

Mas o ponto é, para medir a produtividade, é necessário dividir a quantidade de horas de trabalho pelo tamanho em pontos (de função ou casos de uso) da funcionalidade. Por exemplo, se o desenvolvedor codificou uma funcionalidade que totaliza 5 pontos de função (PF) em 40 horas (h), sua produtividade é de 40 h / 5 PF = 8 h/PF (lê-se quatro horas por ponto de função). Desta forma é possível obter uma produtividade média da equipe e avaliar os desenvolvedores que têm um desempenho menor ou maior.

É importante salientar que quando a estimativa é feita, é normal que se tenha 12 h para cada PF. Esse tempo, porém, é dividido entre todas as atividades do processo de desenvolvimento: codificação, testes, análise e projeto, requisitos, gerenciamento, implantação, etc. Logo, se for considerado apenas o tempo de codificação, consideramos de 40 a 50% do tempo estimado para cada PF. Assim, uma funcionalidade que tenha 2 PF, com a relação de 12 h por PF na estimativa, não pode gastar mais que 12 horas com codificação, incluindo os ajustes solicitados pelo cliente. Logo, um desenvolvedor com a produtividade de 8 h/PF não é uma boa média, que será, no máximo, 6 h/PF.

De posse dessas informações, é possível, já inicio do projeto, tomar atitudes para evitar atrasos no cronograma ou prejuízos financeiros. No término no projeto, essas informações servem de base para próximas estimativas, definido um fator de horas por ponto de função ou de caso de uso aplicável para a empresa em determinados tipos de projetos.

E na prática?

Em um próximo artigo, vou apresentar uma forma de medir produtividade na prática usando a ferramenta Jira. Para quem não conhece, o Jira é uma ferramenta paga, porém com preço bastante acessível, para controle de pendências e gerenciamento de projetos. Até lá!

May 2nd, 2007

Um cidadão chamado Mateus Velloso resolver falar mal de CMMI. Ele é louco? (Deixo a resposta para vocês…). Leia o artigo na íntegra.

April 24th, 2007

Essa semana trabalhei na integração de um sistema em Delphi com um site em PHP & MySQL e resolvi escrever um artigo relatando os diversos problemas ocorridos e quais soluções optei por utilizar.

O artigo está disponível para download em
http://sauloarruda.eti.br/artigos/sauloarruda-webservice.pdf

March 12th, 2007

Você já praticou Judô? Jigoro Kano idealizou o Judô a partir da combinação dos conceitos do Budismo, Xintoísmo, Confucionismo e Taoísmo – estes, parte da cultura religiosa e filosofia de vida do povo Japonês [1].

Os seus objetivos são fortalecer o físico, a mente e o espírito de forma integrada, além de desenvolver técnicas de defesa pessoal.

Com isso, nove dizeres foram nomeados como princípios do Judô, além de duas máximas – pressuposto básico da prática – sendo [1]:

  • SEIRYOKU-ZENYO, que significa a máxima eficiência com o menor gasto de energia;
  • JITA-KYOEI, que significa bem estar e benefícios mútuos;

Aplicando esses conceitos ao desenvolvimento de software, chegamos a boas práticas como [2]:

  • Desenvolver a menor quantidade de código personalizado possível;
  • Maximizar o reuso;
  • Utilizar com sabedoria o poder de processamento;
  • Minimizar distribuições desnecessárias;
  • Unificar as arquiteturas;
  • Simplificar o processo de desenvolvimento;

Pode parecer um pouco sem contexto, mas quanto mais eu vivo, mas percebo que existe muito desperdício na atividade de desenvolver software. Desperdício de dinheiro, traduzido em: funcionalidades que nunca são usadas, cronogramas irreais obrigando que o famoso banco de horas cresça, desenvolvedores inexperientes (e pior, sem treinamento) assumindo grandes responsabilidades, contratos mal feitos, entre outros fatores.

Logo, existe o grande descrédito da nossa atividade que é “muito cara” e “muito arriscada”. Atualmente tenho estudado muito formas de Desenvolver Software de forma ágil e gostaria de recomendar alguns materiais que ando lendo:

Boa leitura! E deixem seu comentário…

Referências:

[1] DOS SANTOS, Saray Giovana. JUDÔ: ONDE ESTÁ O CAMINHO SUAVE?
[2] BEGOLI, Edmon. Software Judo.

Foto: Is Time Really Money de Ricardo Saffi Marques

February 23rd, 2007

Hoje, enquanto lia o artigo de Luciano Costa no iMasters sobre profissionais de TI e sustentabilidade, me veio algumas antigas questões em mente sobre qual o papel que cada um de nós desempenhamos nas empresas que trabalhamos. Luciano diz:

“… um dos grandes desafios dos profissionais de Tecnologia da Informação é entender a estratégia e a natureza das organizações. Estudos realizados por instituições como o grupo IT Mídia desde 2002 indicam que a maioria dos CIOs prefere ter ao seu lado profissionais que sejam capazes de analisar o desempenho da empresa, avaliar riscos e participar do planejamento estratégico.”

Legal, então profissionais que analisam o desempenho da empresa, avaliam riscos e participam do planejamento são mais “bem cotados”. Porém, o que eu vejo é que muitas vezes a cultura da empresa vê com maus olhos esse tipo de pessoa. Já vi vários casos (e não somente em empresas de TI) de pessoas que são demitidas ou “encostadas” por questionarem atitudes, decisões ou métodos de seus “chefes”.

Este é o ponto onde eu queria chegar: Muitas empresas pecam por nomearem chefes no lugar de formarem líderes. Acredito que todos nós já tivemos (ou ainda temos) péssimos chefes. Assim como todos nós também temos líderes que admiramos.

Logo, devemos sempre refletir com muito carinho sobre qual papel estamos exercendo: o de chefe ou de líder. Agora temos aqueles que dizem: “Mas eu sou apenas um [estagiário, profissional junior, orelha seca, peão, auxiliar, etc.]… Não posso fazer nada…” Eu sempre acho que todos os chefes e líderes que encontramos já foram um dia um [estagiário, junior, orelha seca, ou qualquer coisa do tipo]. Então qual a diferença?

A diferença está na ATITUDE. Um líder é SEMPRE incomodado, preocupado, motivado, um verdadeiro team player. E quando falo de líder, não estou falando de quem dá as ordens, estou falando de quem tem ATITUDE de Líder. Liderança não depende de nível hierárquico, escolaridade, cultura ou salário.

E aí, você é um chefe ou um líder?

… eu quero ser um líder.

Transformando Suor em OuroPS: Este post também serve como indicação de um ótimo livro que terminei de ler essa semana, por indicação do Vítor Pamplona: Transformando Suor em Ouro, do Bernardinho. O livro relata todas as fases da carreira deste grande profissional e explica como se transforma suor em ouro. Este livro, ao contrário do que parece, fala muito sobre ego, vaidade, orgulho, e outras características muito comuns de nós, profissionais de TI. Explica o que é uma equipe, e como formar um time! Recomendo fortemente!

January 30th, 2007

Hoje eu li um relato de experiência muito interessante intitulado “O problema dos CRUDs” de Vitor Fernandes. No artigo, o autor fala sobre uma experiência de re-engenharia de um sistema ERP em cobol para Java usando Swing, Hibernate, EJB 2 e tudo mais que tem direito. Com a boa intenção de melhorar a usabilidade, a interface Windows provê belíssimos recursos como Combo-boxes, tabelas, menus, imagens e tudo mais. Porém, os sistemas da era DOS por não ter tanta beleza acabavam exigindo do usuário uma maior destreza na sua operação, como decorar códigos, preencher campos na ordem, calcular manualmente valores, utilizar atalhos (F2 para pesquisar, por exemplo), entre outros. O resultado disso chama-se produtividade. Se nosso sistema não permite que o usuário “avançado” opere, o ROI (Retorno Sobre Investimento) da solução pode ser negativo, necessitando de muito mais horas para fazer o mesmo trabalho.

Recomendo a leitura do artigo para mais detalhes!

January 30th, 2007

Hoje, li um depoimento sobre o processo de implantação de um sistema de gestão da qualidade conforme os requisitos da Norma ISO/IEC 9001:2000 em uma empresa que desenvolve software. O autor é Cláudio Testoni Cardozo, responsável pelo setor de desenvolvimento da empresa Constat.

Minha opinião sobre o assunto: Eu acho que a implantação de um sistema de gestão da qualidade é o primeiro passo para uma empresa que deseja melhorar seus processos. Explico: em geral, as empresas que desenvolvem software não têm a cultura de definir seus processos, isto é, nós sabemos fazer software, mas constantemente mudamos nossa forma de trabalho com boas intenções. Logo, quando os desenvolvedores são questionados sobre como as coisas são feitas, geralmente as respostas são contraditórias. Até aí, nada grave, os céticos dizem. O software é “produzido“, o cliente é “atendido“, os desenvolvedores estão “satisfeitos“…

Pouco tempo depois, o gerente de projeto é questionado a respeito da baixa produtividade da equipe. Ok, todos sabemos que a produtividade em software é realmente muito baixa. Mas, alguém sabe dizer o quão baixa? Ou quem sabe estabelecer metas para aumento da produtividade? Que seja, medir a produtividade?

Neste ponto, o sistema de gestão da qualidade apresenta resultados, diferentemente do que várias pessoas pensam – que a certificação ISO 9001 (e isso se aplica a outros modelos como CMMI ou mps.BR) servirá para burocratizar o processo de desenvolvimento de software – quando na verdade a principal função é medir. Medir para Analisar. Analisar para Melhorar. A melhoria de processos se dá com base em números e não com base em fatos.

Logo, a necessidade de padronizar o processo se dá pela necessidade de medir. Não é possível comparar dois produtos produzidos por processos diferentes. OK, temos nosso processo definido. Agora, o que foi definido deve ser aplicado e aí entra o setor de Garantia da Qualidade que nada mais faz do que garantir que as coisas estão sendo feitas como está escrito que elas deveriam ser feitas.

Não estendendo mais o assunto, a empresa que tem interesse em melhorar processos têm na norma ISO/IEC 9001:2000 um grande aliado quanto a requisitos para a implementação de um sistema de gestão da qualidade. A pergunta final é: Porque ISO/IEC 9001:2000? Não poderia usar CMMI ou mps.BR? A resposta é SIM, poderia. Porém a implementação da ISO 9001 é muito mais simples, basta que a empresa documente como ela trabalha (não sendo necessário na maioria das vezes mudar a forma de trabalho) e criar indicadores para medir o desempenho da produção. Enquanto em modelos como o CMMI e mps.BR, várias práticas devem ser implementadas com metas e resultados que devem ser respeitados, o que, na maioria dos casos irá interferir na forma que a empresa trabalha.

A vantagem de implantação de ISO/IEC 9001:2000 ANTES de outros modelos é a criação de uma cultura voltada à qualidade, que é uma das tarefas mais difíceis da implementação de CMMI ou mps.BR.

January 16th, 2007

A Mundo Java deste mês conta com um artigo do nosso conterrâneo Gilliard Cordeiro (membro ativo do JUG-MS) intitulado “Conhecendo JSF e Facelets 1.2“. O artigo apresenta detalhes sobre a nova versão (1.2) do JSF (Java Server Faces) e noções sobre Facelets. Recomendo.

No mais, a revista também tem um artigo muito interessante do Rodrigo Yoshima intitulado “Design Patterns para um mundo real” e outros mais. A matéria de capa é sobre frameworks web Brasileiros citando o SwignBean, VRaptor2, Mentawai e JSenna com artigos escritos pelos seus criadores com vários exemplos e tudo mais que tem direito.