Qualidade interna e externa de um software e seu código: Como garantir a entrega de um projeto de software com um bom nível de manutenibilidade

Na vasta maioria de projetos de software requisitados para fornecedores internos (o próprio departamente de TI) ou externos (consultorias e fábricas de software), podemos notar que os principais itens de performance medidos são o prazo de entrega e o custo. Conforme nos mostra Robert Austin magistralmente, no seu livro “Measuring and Managing Performance in Organizations”, medir um sistema complexo através de poucas métricas o torna disfuncional e gera efeitos contrários aos pretendidos.

Quando se mede a performance de um projeto de software apenas por seu custo e prazo nota-se um comportamento disfuncional clássico: como o gerente de projeto e os membros da equipe só serão medidos pela velocidade de entrega, então tudo é feito às pressas e usualmente sem a atenção devida a um bom design, a testes unitários e funcionais e a refatorações constantes. Sem esses cuidados, o sistema costuma entrar com um número de defeitos acima do desejado e ainda se torna um código legado desde sua entrada em produção. Essa medição de performance também faz com que os níveis gerenciais demandem mais de 40 horas semanais dos profissionais (muitas vezes sem o devido pagamento de horas extras), o que ainda gera uma degradação de moral da equipe e um turn-over mais alto na empresa.

Como então podemos obter um bom código, que não vire legado assim que é entregue para a equipe que irá mantê-lo? Primeiro vamos definir o que é um código legado, o que é um código bom e o que significa o requisito não-funcional de manutenibilidade.

Quando se fala a palavra código legado, na cabeça dos desenvolvedores surge uma visão de código impossível de entender, estruturalmente complexo, cheio de condições encadeadas, código macarrônico e métodos com centenas e até milhares de linhas de código! Segundo Michael Feathers (em seu livro “Working Effectively with Legacy Code”) código legado é aquele difícil de entender e, consequentemente, difícil de alterar para implementar novas funcionalidades ou corrigir defeitos. Mas, segundo ele, a definição mais importante é: código legado é código sem testes unitários automatizados. Essa definição radical e inusitada nos mostra a importância de uma suíte de testes unitários para manter a sanidade do código e nossa coragem de fazer modificações quando necessárias. Sem testes os desenvolvedores adotam a postura de não mexer em código que “não é deles”, por medo de gerar defeitos. Também não fazem modificações estruturais para manter o código coeso e com baixo acoplamento, especialmente quando incluem novas funcionalidade. Portanto, sem testes unitários é difícil dar manutenção evolutiva e corretiva no código e mantê-lo bom, evitando que se torne legado e complexo.

Nossa próxima definição é sobre código bom. Essa é uma definição mais complexa. Gosto muito do termo inventado por Kent Beck: “code smell”. O “mau cheiro” em código é um sintoma de que algo está errado. É uma indicação de que o código precisa ser refatorado ou o design deve ser reexaminado. Alguns “maus cheiros” clássicos são (acesse a taxonomia de maus cheiros, caso queira mais detalhes):

• Métodos longos - esse tamanho pode variar, mas algumas pessoas consideram que um método com mais de 50 linhas de código já é um método longo (alguns mais puristas chegam a dizer que um método deve ter no máximo 10 linhas!). Veremos adiante no artigo que a complexidade ciclomática pode nos ajudar a obter um indicador mais preciso.

• Classes grandes e complexas - normalmente as que não seguiram o princípio de alta coesão
• Classes com intimidade com muitas outras classes - as que não seguiram o princípio de baixo acoplamento
• Classes preguiçosas – que não fazem muita coisa ou são executadas com pouca freqüência
• Código duplicado – essa é uma das maiores pragas que devem ser combatidas... rs.

E o requisito não-funcional da manutenibilidade? Bom, esse é, como qualquer requisito não-funcional, fundamental para uma definição da arquitetura de um software. É a facilidade de manutenção para inclusão de novas funcionalidades, correção de defeitos e alterações de regras de negócio. Esse requisito é fundamental para qualquer sistema que venha a ter uma vida útil longa em produção e que sofrerá contínuas modificações. Clientes e outros stakeholders não costumam falar claramente “esse sistema deve durar 10 anos em nossa empresa, é crítico e terá um número grande de requisitos novos mensalmente”. Por isso a manutenibilidade deve ser questionada claramente para os stakeholders. Alguns dizem que não se deve preocupar com manutenibilidade se o código durar pouco tempo. Tome cuidado, porque a tendência de todo código criado é a de continuar sendo usado por tempos razoáveis. Portanto, desconfie se disserem que o sistema ficará pouco tempo em produção. Nem sempre o cliente sabe tudo (vide o livro “O Dilema da Inovação” de Clayton Christensen para detalhes desse fenômeno no mundo dos negócios) !

Agora o problema: tendo em vista que sabemos a importância de se obter um código bom, não legado e com alta manutenibilidade, como medir isso em um fornecedor (interno e/ou externo) e como garantir que essa qualidade existe? Aí vão algumas dicas.

A primeira parte é a mais fácil: medições de código. Hoje temos várias ferramentas (neste artigo estou focando em ferramentas para Java, mas saibam que também existem similares para .NET e outras plataformas) que ajudam em 80% do esforço de detectar problemas. Vamos a algumas delas para exemplificar:

• Usar JUnit para fazer os testes unitários automatizados e, desse modo, não deixar o código virar legado conforme definição do Feathers. Como um cliente pode medir se os testes unitários estão sendo feitos e se são relevantes? Uma forma muito boa é medir a cobertura de código (de linhas e de desvios) realizada pelos testes unitários. Para isso é possível usar uma ferramenta open source como o Cobertura ou uma ferramenta como a embutida no Rational Application Developer.
• Usar uma ferramenta como o JavaNCSS para contar a quantidade de linhas de código e a complexidade ciclomática por método. Com essas métricas pode-se analisar se o código de cada método está complexo demais e se deve ser quebrado para manter a coesão. É possível usar uma ferramenta como o crap4J para tirar métricas combinadas entre cobertura de código e complexidade ciclomática.
• Usar uma ferramenta de análise estática de código como o PMD ou a embutida no Rational Application Developer para avaliar regras básicas de código. Essa é uma ferramenta essencial e que deve ser utilizada antes de qualquer inspeção formal feita por desenvolvedores. Ela irá pegar erros básicos que forem configurados. Ela detecta falhas como:
• Métodos longos
• Nomes de variáveis e métodos curtos
• Nomes de variáveis que não começam com letra minúscula
• Identação de chaves
• Quantidade excessiva de parâmetros
• Acoplamento entre objetos
• Aninhamentos grandes de ifs e elses
• Densidade de switch
• Código não utilizado (variáveis, parâmetros, métodos, etc)
• Usar a ferramenta CPD (Copy/Paste Detector) para identificar código duplicado e passível de refatoração.
• Usar uma ferramenta de análise de dependências de código orientado a objeto como o JDepend ou o Rational Software Architect (com sua capacidade de descoberta arquitetural e detecção de antipatterns arquiteturais).

Todas as ferramentas acima podem ser executadas através de um simples comando do Ant, após feita a configuração correta. Isso pode ser ainda colocado para executar dentro de um servidor de integração contínua, que pode enviar relatórios diários por email do status das métricas de código.

Além de medir o código usando ferramentas, sempre faça auditorias em cada uma das versões entregues (lembre que ferramentas garantem 80% dos casos, normalmente os mais típicos). As ferramentas não excluem o uso de bons desenvolvedores inspecionando formalmente código. Segundo McConnell, no livro “Code Complete”, de 45 a 70% dos defeitos de um código são removidos quando este passa por uma inspeção formal de desenvolvedores experientes.

Agora vamos à parte que dará mais trabalho (em termos de negociação e possíveis conflitos): como garantir essa qualidade de seu fornecedor? A resposta: estabeleça um SLA (Acordo de nível de serviço) para cada parâmetro importante discutido na primeira parte (métricas). Pode-se definir, por exemplo:

• Uma complexidade ciclomática de até 15 como aceitável, de 16 a 30 como aceitável se o fornecedor justificar de forma admissível ou inaceitável quando maior que 30.
• Uma cobertura de linhas de código de 80% como aceitável. Abaixo disso é inaceitável e acima disso é bônus.
• Regras definidas pelo cliente nas ferramentas de análise estática de código devem ser todas seguidas. Não deve aparecer nenhum erro.

Com base nisso pode-se elaborar penalidades no caso do fornecedor não estar dentro do SLA e bônus por ultrapassar os limites aceitáveis do SLA.

È possível também elaborar SLAs para que o fornecedor realize testes funcionais automatizados e testes de performance automatizados. Testes automatizados são mais garantidos porque podem ser executados para confirmar se foram feitos (diferentemente de casos de testes manuais) e ainda se tornarão um ativo de sua empresa, pois serão usados como testes regressivos. Um mínimo de testes funcionais automatizados (nem que sejam apenas os chamados "smoke tests") deve ser requerido.

Com essas técnicas você pode sair da situação da figura abaixo:

Para entrar numa situação bem melhor como essa:

E uma dica: se o seu fornecedor questionar e dizer que terá que aumentar o custo por causa disso, pergunte a ele: como você fazia então para garantir a qualidade e manutenibilidade de seu código sem essas métricas? Ou não fazia? Provavelmente o fornecedor que faz essa colocação não terá uma boa resposta verdadeira.

Outra dica: se o seu fornecedor se diz “agile”, não aceite apenas que haja entregas durante iterações curtas. Isso é apenas um lado (também importante). Exija a qualidade acima para realmente provar a agilidade do fornecedor. Processos ágeis primam muito pela qualidade interna e externa do código. Esse aviso é importante pois já pode-se notar no mercado o que costumam chamar de empresas “pseudo-agile”. São aquelas que dizem que praticam Scrum e XP, mas na verdade praticam mesmo a codificação caótica e indisciplinada, tudo que processos ágeis não são.

Por que estou dando essas informações valiosas? Porque acredito que, se os clientes foram mais exigentes com seus fornecedores de software, então todo o país terá a ganhar. Formaremos profissionais de maior qualidade, que geram um produto (código) de maior qualidade e aí poderemos competir no mercado externo com outros profissionais não apenas nos termos de custo e sim da qualidade do trabalho. Mudaremos de uma estratégia de oceano vermelho de custo para uma estratégia de oceano azul da diferenciação.

Portanto relembrando para o cliente: elabore contratos que demandem entregas curtas (desenvolvimento iterativo) com qualidade interna e externa medida por ferramentas, pessoas e SLAs. Vamos melhorar juntos o nível de qualidade dos nossos produtos!

Dando uma dica para fornecedores: Sejam pró-ativos e ofereçam esse tipo de contrato para seus clientes. Mudem suas estratégias de desenvolvimento e ofereçam qualidade com agilidade. Gerem benefícios de valor agregado, antes que seus concorrentes o façam!

Aguardo comentários de vocês sobre esse artigo. É sempre bom dialogar com os leitores do meu blog!

Em um próximo artigo vou tratar da situação onde você tem um sistema legado, com código "mal-cheiroso", e quer melhorar sua qualidade interna para continuar incluindo novas funcionalidades. Vamos mostrar técnicas para melhorar a manutenibilidade de sistemas já existentes (um problema que muita gente tem hoje na nossa área!).

ProjectKoach 2008: Gestão de Projetos OpenUP com ferramenta integrada ao Eclipse

Lancei um post há algum tempo falando sobre uma interessante ferramenta para apoiar a gestão de projetos com o OpenUP. A ferramenta se chama ProjectKoach.

Pois uma excelente notícia: a versão 2008 do ProjectKoach agora vêm em dois modelos: standalone e integrada ao Eclipse!

Com a integração há mais facilidades para trabalho colaborativo em equipe. Outra funcionalidade excelente da ferramenta é a integração com o Eclipse Process Framework (EPF). O ProjectKoach consegue importar bibliotecas de métodos instaladas em seu ambiente e gerar sua WBs a partir de sua configuração customizada!

E o melhor de tudo: a ferramenta é gratuita. Faça um test drive indo ao site do ProjectKoach.

Minha dissertação publicada: Uma linguagem de padrões para automação de projetos de desenvolvimento ágil de software com ênfase na plataforma J2EE

Caros,


Acabei de disponibilizar minha dissertação de mestrado, defendida em dezembro de 2007, sob orientação do professor doutor Mauro de Mesquita Spínola. O título é "Uma linguagem de padrões para automação de projetos de desenvolvimento ágil de software com ênfase na plataforma J2EE".

Resumo:

Um dos resultados do Extreme Chaos Report, também analisado por Boehm no
seu modelo de estimativas COCOMOII, mostra que ferramentas de engenharia
de software geram um impacto significativo na probabilidade de sucesso de um
projeto de software e servem como apoio ao aumento de qualidade e produtividade da equipe, quando utilizadas para suportar o processo de desenvolvimento. Ferramentas de engenharia de software são aquelas que suportam o processo e automatizam tarefas feitas pela equipe que desenvolve software. Pode-se considerar também que as empresas que têm se destacado no negócio de software são as que possuem um processo de criação e inovação de produtos ágil e eficaz. Novas técnicas e processos pautados no desenvolvimento ágil surgiram com o objetivo de solucionar os problemas da complexidade do desenvolvimento de novos softwares e para fornecer agilidade no lançamento de novos softwares e produtos. Mesmo assim, percebe-se que poucas empresas desenvolvedoras possuem um ambiente automatizado organizado e que apóie a agilidade. Este trabalho exploratório busca entender como podemos automatizar um ambiente de projeto ágil de desenvolvimento de software. Seu objetivo é propor um conjunto de soluções específicas para a automação de ambientes colaborativos, com ênfase no desenvolvimento ágil de software e foco na plataforma J2EE. A pesquisa bibliográfica é complementada por um Web survey e por um estudo de caso incorporado de casos múltiplos, com o objetivo de avaliar o estado atual da automação em empresas brasileiras e analisar quais atributos de um ambiente de desenvolvimento podem ser considerados importantes. O trabalho utiliza o formato dos padrões (patterns) e da linguagem de padrões (pattern language), já estabelecidos como úteis para documentar soluções dentro da comunidade de desenvolvimento de software,
para fornecer o conjunto organizado de práticas de automação para engenharia de software. A linguagem de padrões resultante traz também recomendações de ferramentas específicas para apoiar a automação de projetos de desenvolvimento de software com base na plataforma J2EE.

PALAVRAS-CHAVE: Padrões, desenvolvimento ágil de software, ambientes
colaborativos de desenvolvimento de software, ferramentas de apoio ao
desenvolvimento de software, automação de fábricas e projetos de software, Java 2 Platform Enterprise Edition, J2EE.

Faça o download para leitura da dissertação de mestrado de José Papo.

Crap4j - Ferramenta de Métrica de qualidade para código Java

Crap4j é um software que auxilia a detectar código Java ruim. O acrônimo crap significa "Change Risk Analysis and Predictions", mas também é uma brincadeira para descrever o naipe de um código ruim :-) .


Como o Crap4j analisa se um código é ruim? Ele faz isso comparando duas métricas de qualidade de código fundamentais: a complexidade ciclomática e a cobertura de caminhos de código.


Pode-se resumir a tabela da ferramenta assim:


Complexidade ciclomática do método - % de cobertura para ficar abaixo do CRAP limite
0 – 5 --> 0%
6 - 10 --> 42%
11-15 --> 57%
16-20 --> 71%
21-25 --> 80%
26-30 --> 100%
31+ --> Hora de refatorar!!!


Isto significa que você pode ter métodos complexos, porém estes devem possuir um mínimo de cobertura de testes para garantir uma melhor manutenção de código.

Abaixo temos um screenshot de um relatório emitido pela ferramenta crap4j. Note que, quanto maior o número CRAP, maior o risco e complexidade de um método. Qualquer método com 30 ou mais de CRAP necessita de atuação (aumento do número de testes unitários para aumentar a cobertura ou refatorar para diminuir a complexidade ciclomática... ou ambas as coisas!).

NetBeans 6 e JBoss Developer Studio - Novidades em IDEs Java para 2008

Começo o ano de 2008 tratando sobre novidades nas IDEs (ambientes integrados de desenvolvimento) Java.

NetBeans 6

Essa IDE gratuita apoiada pela Sun está com diversas novidades e está se tornando uma forte concorrente ao Eclipse no mercado corporativo. As facilidades na construção de aplicações Java Gui e no desenvolvimento de aplicações Web de forma visual impressionam.

Uma coisa chata no NetBeans 5.5 era a dificuldade para conectar os controles visuais Web com componentes EJB e JPA do JEE 5. Agora isso foi melhorado no NetBeans 6! Veja o artigo sobre como usar a API de Persistência Java dentro de uma aplicação Web visual.

Outra boa novidade: suporte a desenvolvimento Ruby on Rails dentro do NetBeans 6!


JBoss Developer Studio

Essa IDE lançada pela RedHat/JBoss é a nova face da antiga ferramenta da empresa Exadel, que foi comprada pela RedHat.

A ferramenta é baseada no Eclipse 3.3 (Europa) e no Web Tools Project 2.0 . Suas funcionalidades mais interessantes são relacionadas ao JBoss Seam e as capacidades AJAX baseadas no JBoss RichFaces. Além, é claro, dos clássicos wizards para Hibernate, JBoss jBPM, Spring, Struts e apadtador otimizado para o JBoss Application Server.

O custo padrão da ferramenta é de 99 dólares.

Gestão de Projetos - Ferramentas livres e gratuitas para o gerenciamento de projetos

Segue uma lista com várias indicações interessantes de ferramentas livres e/ou gratuitas para a gestão de projetos. Algumas dessas ferramentas trabalham no estilo do Microsoft Project, isto é, são feitas para o desktop. Já outras são baseadas na web e centralizam a informação nos servidores web e de banco de dados da empresa.

Muitas dessas ferramentas podem substituir tranquilamente o Project. Outras possuem menos recursos, porém buscam atender a um nicho de pequenos projetos.

Uma importante dica: Não duplique informações. Se você utilizar uma ferramenta baseada na Web, elimine a ferramenta desktop do seu trabalho.

Você também precisa analisar e pensar se e como fará a integração entre a ferramenta de gestão de projetos e uma ferramenta de gestão de incidências. Algumas das ferramentas de gestão de projetos possuem plugins e integrações com ferramentas de gestão de incidências. Algumas ferramentas de gestão de incidências possuem funcionalidades que geram gráficos de Gantt, entre outros. Às vezes, com um uso coerente das funcionalidades disponíveis, é possível substituir a ferramenta de gestão de projetos apenas pela ferramenta de gestão de incidências.

Deixe um comentário, caso queira saber mais sobre alguma ferramenta ou conhecer minha opinião sobre elas. Aproveite também para falar o que achou sobre uma dessas ferramentas, caso já a tenha utilizado. Se há alguma outra ferramenta que não foi citada por mim, deixe sua dica aqui para termos uma relação bem atualizada de opções!!!


Leia sobre o ProjectKoach e Mingle.

Descubra também o Buildix (é mais do que apenas uma ferramenta para gerenciar projetos. É todo um ambiente para automação de desenvolvimento de software).

Veja o que é a ferramenta ScrumWorks, VersionOne e Rally.

Veja também as seguintes ferramentas livres e/ou gratuitas:

GanttProject

Achievo

Open Workbench

Faces

TaskJuggler

OpenProj

DotProject

Note também que algumas das ferramentas citadas disponibilizam funcionalidades para o ciclo de vida completo de um projeto de desenvolvimento de software e, o melhor, integrando com facilidade de uso esses aspectos. Além da gestão de projetos há também: gestão de requisitos, gestão de testes, gestão de incidências, integração com controle de versões. Alguns exemplos dessa categoria: Mingle, Buildix, VersionOne e Rally.

As ferramentas focadas em gestão de projetos e que são instaladas no desktop são: GanttProject, Open Workbench, Faces, TaskJuggler, OpenProj.

As ferramentas com foco no gerenciamento de projetos, porém instaladas em um servidor web e acessadas via browser são: Achievo, DotProject.

Resposta à pergunta do Edigar sobre o grau de importância das ferramentas de gestão no sucesso de um projeto de desenvolvimento de software: Hoje acredito que a ferramenta mais importante para o controle e a gestão de um projeto de software é a ferramenta de gestão de incidências. Se você fizer o controle corretamente e tiver bons fluxos definidos, a base de dados da gestão de incidências se tornará o coração dos seus sistemas e de sua empresa como um todo.

As maiores empresas desenvolvedoras de software no mercado mundial usam como recurso central as ferramentas de gestão de incidências para controlar, monitorar e organizar seus projeto de software. Hoje, na minha opinião, esse é um recurso fundamental para disciplinar, organizar e fazer a governança de sistemas de Tecnologia da Informação.

Já um ferramenta focada em gestão de projetos, que gera gantts, PERTs entre outros vira uma ferramenta acessória. Na minha opinião, ela só será útil se for integrada ao sistema de gestão de incidências e apenas como mais uma forma de monitorar o projeto, além da própria ferramenta de gestão de incidências em si (esta sim o coração e a máquina central do desenvolvimento de sistemas) e outros tipos de visualização úteis como o Release Burdown e o Sprint (Iteration) Burndown do Scrum e do OpenUP.

MaintainJ : Engenharia reversa simples e ágil!

MaintainJ é um plugin para o Eclipse que gera diagramas de sequência e diagramas de classe com base na engenharia reversa.

Qual a sua diferença para outras opções no mercado? A maior de todas é que ela é uma das raras que gera o diagrama de sequência à partir de um cenário de uso da aplicação. De acordo com o RUP seria um diagrama de sequência de um dos fluxos da realização do caso de uso.

Esse processo é feito usando o conceito de engenharia reversa dinâmica. No mercado o mais comum é encontrarmos a engenharia reversa estática. Esta simplesmente lê o código e gera os elementos da UML (normalmente apenas as classes) respectivos. Já a engenharia reversa dinâmica é feita à partir do uso do sistema. Como isso é feito? O código é inicialmente instrumentado (compilado com opções especiais, de forma parecida com a instrumentação feita por ferramentas de cobertura de código). Quando o sistema é executado ele gera logs mostrando o caminho, métodos executados e objetos instanciados. Com base nesses dados é gerado o diagrama de sequência de um cenário.

Essa ferramenta pode ser útil para analisar sistemas em Java sem documentação de design e também em projetos ágeis que necessitam de documentação mas preferem fazer o processo reverso de trnasformação do código para diagramas.

Agora vocês podem imaginar: nossa, quanto custa a facada? Esse é outro ponto positivo do plugin: custa apenas 20 dólares por ano!!!

Novas ferramentas livres para gestão ágil de projetos: Mingle e ProjectKoach

Duas novas ferramentas para gerenciamento ágil de projetos foram lançadas no mercado.

A ferramenta ProjectKoach é uma ferramenta leve e gratuita feita especialmente para gerenciar projetos usando o processo OpenUP 1.0. Com a ferramenta ProjectKoach você pode:

- planejar projetos
- gerenciar iterações
- Medir a velocidade da equipe
- Rastrear itens de trabalho a requisitos e outros itens
- Integração com o processo OpenUP e facilidades de editar o processo e alterar também a ferramenta automaticamente
- Guias de processo para analistas e desenvolvedores, que explicam em detalhes as tarefas alocadas.

A única funcionalidade que eu acho que ainda é necessária na ferramenta é a integração com ferramentas de controle de versões como Subversion, CVS, IBM Rational ClearCase, etc.

Vide abaixo uma figura da tela principal da ferramenta:


Faça o download do ProjectKoach e experimente a ferramenta! Você precisa apenas de um JDK do Java. Ela pode se tornar um excelente apoio ao seu projeto e, ainda melhor, sem custo!!!

A ferramenta Mingle foi desenvolvida pela famosa consultoria de projetos ágeis americana ThoughtWorks. Ela é gratuita para até 5 usuários. A partir do sexto usuário deve ser paga uma taxa de licenciamento conforme a tabela de preços.

A ferramenta Mingle está atualmente bem mais completa que o ProjectKoach, porém tem um custo após o sexto usuário. Ela inclusive possue integração com ferramentas de controle de versões e integração entre requisitos, casos de teste, defeitos e riscos.

Uma outra excelente funcionalidade é a capacidade de visualizar os requisitos e tarefas no Mingle como cartões na tela. Vide a imagem de exemplo abaixo:


Faça o download do Mingle e experimente a ferramenta! Você precisa ter o banco de dados MySQL 5 instalado.

Ebook ( Livro Eletrônico ) sobre Automação e Gerenciamento de Testes

O colega Cristiano Caetano acabou de lançar um ebook ( livro eletrônico ) fornecendo interessantes e importantes contribuições referentes à diversas ferramentas open source e gratuitas disponíveis na rede mundial.

Li a versão beta e a oficial recém-lançada do livro e só posso parabenizar os esforços do Cristiano Caetano pelo excelente trabalho de compilação dessas soluções ( muitas delas eu já vinha também divulgando através de meu blog desde o seu início ).

Cada capítulo do livro se refere a uma categoria de ferramenta. Os capítulos são:

1 - Gestão de Defeitos
2 - Gestão de Testes
3 - Gestão de Projetos
4 - Automação de Testes Funcionais e de Aceitação
5 - Automação de Testes de Performance
6 - Controle de Versões
7 - Ferramentas de Apoio

Recomendo fortemente o livro, pois fornece uma visão abrangente das soluções disponíveis no mercado referentes às categorias de ferramentas citadas e por seu custo bem acessível. O conhecimento compartilhado pelo Cristiano Caetano renderá frutos para um melhor entendimento da engenharia de software. O seu investimento no livro com certeza terá um alto retorno!

Acessem o link de aquisição do livro e também leiam o artigo que o descreve.

Promoção de baselines no Rational ClearCase, CVS e Subversion

Uma pergunta surgiu na lista CMM-Brasil acerca da promoção de linhas de base ( baselines ) em ferramentas de gerência de configuração.

A Pergunta:
Gostaria de saber se algum dos colegas utiliza o CVS em gestão de configuração. A empresa em que trabalho está homologando este sistema para substituir o Rational ClearCase e uma das queixas mais freqüentes diz respeito à promoção de baselines, que não seria facilitada com o CVS. Desta forma, gostaria de saber afinal como fazer promoção de baselines com o CVS.Para constar, há um movimento - apesar de fraco - em prol do Subversion. Entretanto, soube que as tentativas de usá-lo foram frustradas por motivos técnicos, já que aparentemente o sistema não passou nos testes de simulação de carga com uma grande quantidade deusuários em nível nacional. Assim, relatos do uso de Subversion com uma grande quantidade de usuários também são bem-vindos.

A Minha Resposta:
O conceito de baseline do ClearCase na realidade corresponde ao conceito de tag ou label do CVS e do Subversion. O conceito de branches é chamado de branch no ClearCase Base e de Stream no ClearCase UCM.

O conceito de promoção de baseline realmente não existe no CVS. A promoção nada mais é que você definir uma propriedade (ou metadado) descrevendo a estabilidade daquela baseline. Os valores default são: Integration Tested, System Tested, Acceptance Tested, Production.

O Subversion possui uma funcionalidade que pode ser usada para descrever esse conceito de promoção. Essa funcionalidade se chama "Properties". Ela permite que você crie metadados.

De qualquer maneira, há sempre a possibilidade de simular o conceito de promoção de baselines usando a funcionalidade de tags e labels do CVS e do Subversion.

Sobre a questão da performance, existe uma solução (paga) que aumenta radicalmente a performance do Subversion sem afetar a sua forma comum de utilização. Vide: http://www.wandisco.com/php/product_detail.php?lname=subversion

Mas existem muitos relatos no exterior de companhias com equipes distribuídas grandes satisfeitíssimas com o uso do Subversion. Talvez vocês tenham testado a performance com uma versão mais antiga. Na versão mais nova a performance foi melhorada ainda mais. Outras fontes boas de informações são:

http://blogs.open.collab.net/svn/

http://subversionee.blogspot.com/

http://svk.bestpractical.com/view/HomePage

Leituras sobre como implementar RUP e Integração Contínua

Finalizei a leitura de dois excelentes livros que considero importantes para apoiar a entrega e o sucesso de projetos de desenvolvimento de software.

O primeiro livro se chama Continuous Integration: Improving Software Quality and Reducing Risk de Paul Duvall.

Este livro aborda a importância crucial da integração frequente para o sucesso de projetos de desenvolvimento de software. Após definir o conceito de Integração Contínua o autor oferece mais de quarenta práticas para realizar a integração contínua de software, de bancos de dados, de testes, de inspeções, implantação e feedback. Além disso ele explica porque cada uma dessas práticas ajuda a reduzir tempo e custos de desenvolvimento, bem como aumentar a qualidade do produto final com redução de riscos e de processos manuais repetitivos.


O segundo livro se chama Implementing the IBM Rational Unified Process and Solutions: A Guide to Improving Your Software Development Capability and Maturity de Joshua Barnes.

Neste livro o autor apresenta um guia e um roadmap completo de melhores práticas para realizar a implementação de todo o ciclo do RUP, desde projetar o Retorno sobre investimento (ROI) e o business case da solução passando por estratégias de escolha dos membros da equipe, projetos-piloto, customização, mentoring e como realizar a transição para a implementação organizacional do processo e das soluções de ferramentas de automação. Este livro, em conjunto com o livro Adopting the Rational Unified Process: Success with the RUP de Stefan Bergström e Lotta Råberg, é uma referência fundamental para engenheiros de processos de software e todos aqueles interessados em realizar uma implementação do RUP bem sucedida dentro da sua organização.

Ferramenta open source para Refactoring de banco de dados LiquiBase

A equipe LiquiBase anunciou o lançamento da versão 1.0 da ferramenta open source LiquiBase. A ferramenta oferece funcionalidades para gerenciar mudanças e refactorings de bancos de dados.

Parece ser uma interessante e útil ferramenta que pode facilitar o trabalho de desenvolvimento iterativo de um banco de dados, especialmente estando este já em produção e necessitando de manutenções constantes de sua estrutura. A versão contendo a IDE com certeza ajudará a tornar a ferramenta LiquiBase mais popular entre desenvolvedores e DBAs.

A ferramenta suporta diversas funcionalidades, tais como:

- Formato de rastreamento de mudanças que suporta vários desenvolvedores e branches.

- Mais de trinta refactorings já criados, baseados no livro Refactoring Databases. Vide os refactoring suportados na página Supported Refactorings.

- Pode executar as atualizações diretamente, ou salvá-las para revisão dos DBAs.

- Pode fazer um rollback do banco de dados com base em datas, tags ou números de mudanças.

- Suporta os bancos de dados MySQL, PostgreSQL, Oracle e MS SQL Server.

- Pode ser executado como uma tarefa do Ant, um plugin do Maven ou um programa de linha de comando.

- Documentação extensa e completa incluindo um guia para início rápido e um manual.

- Várias funcionalidades estão planejadas para as próximas versões como: suporte a mais bancos de dados (DB2, Sybase, Derby and HSQL), um plugin para IDEs para facilitar graficamente o refactoring, refactoring adicionais e uma ferramenta para diff de bancos de dados entre outras.

JBoss lança versão Alpha da JBoss Tools

JBoss Tools é um conjunto de plugins para a IDE Eclipse.

O conjunto de plugins inclui:

- o produto Exadel Studio
- Ajax4JSF
- RichFaces
- Hibernate Tools
- JBoss jBPM Tools
- Drools IDE
- JBoss Application Server Tools
- JBoss Seam Tools

Algumas das mais interessantes funcionalidades:

- Permite visualização WYSIWYG (What You See Is What You Get) de págins JSF e de Facelets.

- Suporta componentes de frameworks como JBoss Seam, JBoss Ajax4jsf e JBoss RichFaces.

- Capacidades de arrastar e colar entre o navegador de projetos, a palheta de componentes e as janelas de edição visual de páginas.

- Assistência de código extendida para projetos JSF e Seam.

- Suporte para adicionar com facilidade funcionalidades Ajax nos projetos usando JBoss RichFaces e Ajas4JSF.

Mais detalhes podem ser vistos no anúncio feito pela empresa JBoss.

Linha de base de requisitos com o IBM Rational RequisitePro Baseline Manager

O IBM Rational RequisitePro Baseline Manager é parte integrante da ferramenta IBM Rational RequisitePro. O IBM Rational RequisitePro é uma ferramenta de gestão de requisitos que possui um repositório central de requisitos do projeto.

A grande vantagem do Rational RequisitePro é ter embutida a ferramenta IBM Rational RequisitePro Baseline Manager. Esta tira uma "foto" da base dos requisitos do projeto em um ponto particular do ciclo de vida do desenvolvimento. Essa "foto" é conhecida como a linha de base de um determinado momento do projeto e contém requisitos, visões de requisitos, pacotes, documentos Word e a estrutura do projeto ReqPro.

Você pode criar quantas linhas de base de requisitos quiser. Algumas dicas de pontos críticos:

• Depois que os requisitos são revisados e aprovados.
• Ao final de cada iteração do projeto iterativo.
• Quando os requisitos forem disponibilizados em produção.
• Toda vez que você desejar salvar uma cópia do projeto para backup.

O RequisitePro Baseline Manager fornece as seguintes funcionalidades:

• Criar baselines.
• Comparar baselines (ele usa uma ferramenta parecida com o diff visual do ClearCase para comparar duas linhas de base lado a lado).
• Gerar relatórios com os conteúdos de uma linha de base ou com as diferenças entre linhas de base.
• Criar um projeto no Rational RequisitePro a partir de uma linha de base existente.

O Rational RequisitePro Baseline Manager converte todos os requisitos contidos no banco de dados de um projeto RequisitePro para arquivos XML e todos os documentos em documentos Word. Ele coloca todos esses arquivos numa pasta correspondente à linha de base de requisitos gerada.

Há uma vantagem interessante neste processo de linhas de base puramente por arquivos, pois é possível realizar um check-in ou commit dos arquivos XML e Word para um repositório de alguma ferramenta de controle de versões como Subversion, CVS, Rational ClearCase, Microsoft Team Foundation Server, Borland StarTeam, etc. Desse modo, caso seja necessário recriar um projeto a partir de um baseline antigo basta recuperar ( fazer o check-out ) os arquivos da linha de base e pedir para que o Rational RequisitePro Baseline Manager crie um projeto a partir dos arquivos salvos no repositório de controle de versões.

Análise de ROI para projetos de TI

Abaixo segue uma lista de bons livros que li sobre o assunto de retorno de investimento ( ROI ) de projetos de desenvolvimento de software e melhoria de processos. Coloquei aqui após ter respondido a uma pergunta sobre essa bibliografia no fórum do PMI-SP.


Software by Numbers: Low-Risk, High-Return Development

ROI of Software Process Improvement: Metrics for Project Managers and Software Engineers

ROI of Software Process Improvement: Metrics for Project Managers and Software Engineers

Making the Software Business Case: Improvement by the Numbers

Software Estimation: Demystifying the Black Art

Outras ferramentas de integração contínua e automação de builds

Duas novas ferramentas interessantes para integração contínua e automação de builds se encontram no mercado.

A primeira se chama Pulse. Ela possui uma interface gráfica inovadora e diversas facilidades para builds distribuídos.

A segunda se chama Bamboo. O ponto mais interessante da ferramenta é que ela foi construída pela Atlassian, os criadores do famoso sistema de gestão de defeitos e issues chamado JIRA. Desse modo, uma de suas funcionalidades interessantes é a integração bidirecional com o JIRA.

Ambos os produtos possuem um preço acessível para uma categoria de ferramenta (automação de builds e integração contínua) que a cada dia que passa se torna mais essencial em qualquer processo de desenvolvimento de software.

Nova versão de produtos DeskTop da Rational SDP

A versão 7 da nova plataforma de produtos desktop da IBM Rational foi recentemente lançada.

Alguns produtos da linha server como Rational ClearCase, Rational ClearQuest e Rational RequisitePro já estavam na versão 7.

Os produtos atualizados esta semana estavam anteriormente na versão 6.

Veja o anúncio do lançamento.

Para saber as novas funcionalidades incorporadas a cada um dos produtos clique no link correspondente abaixo:

IBM Rational Application Developer for WebSphere® Software

IBM Rational Software Modeler

IBM Rational Software Architect

IBM Rational Functional Tester

Conciliando ferramenta de Gestão de Documentos com Sistema de Controle de Versões

Uma pergunta foi feita no grupo de usuários do CMM-Brasil acerca de como criar baselines de documentos, sendo que uma ferramenta de gestão de documentos (no caso seria o SharePoint Portal Server da Microsoft) estava sendo usada para versionar documentos.

Minha resposta à esta questão seria uma forma possível de integrar o melhor desses dois mundos:

O SharePoint, bem como outros GEDs, permite controlar as versões de artefatos (como um bom sistema de gestão de documentos) mas não baselines. Nesse ponto funciona de maneira similar a wikis empresariais como o Confluence e o TWiki. São soluções excelentes para gestão e difusão de conhecimento.

Para ter baselines(que devem incluir todos os elementos da configuração, inclusive código) você poderia usar sistemas de controle de versão como CVS, Subversion, ClearCase ou o próprio TFS da Microsoft.

Como você faria para ter o melhor de ambos os mundos? Sempre que precisar gerar um baseline faça uma cópia dos documentos que estão no portal e coloque em um diretório dentro da sua estrutura de versionamento, faça o check-in deles e crie um label para identificar o baseline. Essa é uma possível solução. Com um pequeno investimento a mais isso poderia ser feito de forma automatizada através de scripts.

Outra forma mais complicada seria apenas criar uma página no SharePoint (ou Wiki) que teria um identificador com o mesmo nome do label dado no sistema de controle de versões para os artefatos de código e possuiria links para cada documento (a versão específica) do baseline.

Você também poderá fazer da forma contrária. Mantenha os documentos dentro do sistema de controle de versões. Quando tiver uma baseline do seu produto aí você inclui e/ou atualiza os documentos que deseja no portal ou wiki. Acredito que ficaria até mais fácil para controlar e acompanhar :-) ! Se um dia você precisar de um baseline antigo poderá achar facilmente através do seu sistema de controle de versões.

Automação para as massas!!!

Finalmente a IBM DeveloperWorks iniciou uma série de artigos sobre automação para desenvolvimento de software. Seu autor é Paul Duvall, CTO da Stelligent. Interessante que segue os moldes dos meus artigos aqui desse blog :-) !

O primeiro artigo trata da inspeção contínua de código utilizando as ferramentas CPD, CheckStyle e JavaNCSS.

Ele também traz dicas de como integrar as ferramentas de inspeção de código com a ferramenta de integração contínua CruiseControl e como colocar uma lâmpada de ambiente que muda de cores se a complexidade aumenta :-) !!!

No artigo do mês de setembro ele fará uma análise de três ferramentas de Integração Contínua: CruiseControl, LuntBuild(escrevi um artigo em português sobre ela que, inclusive, está como link no site da ferramenta!!!) e Continuum.

A Automação nunca foi tão divertida!!!!!

Buildix - Plataforma para desenvolvimento ágil em um disco

A ThoughtWorks acabou de lançar o que eles chamaram de "Plataforma para desenvolvimento ágil em um disco". O produto se chama Buildix.

Seu objetivo é facilitar projetos baseados em Java a ter uma platagorma de desenvolvimento de software (baseada em paradigmas ágeis) de forma rápida e simples.

Para atingir esse objetivo o pessoal da Thoughtworks montou um ambiente pré-configurado e integrado contendo as seguintes ferramentas:

- Tomcat
- Apache
- Subversion (controle de versões)
- CruiseControl (integração contínua)
- Trac (gestão de incidências integrada com controle de versões e Integração Contínua)
- Ant (build)
- Checkstyle (análise estática de código)
- JUnit (testes de unidade)
- Emma (cobertura de código)

O produto existe em uma versão VMWare e outra ISO. A versão VMWare só necessita do VMWare Workstation para funcionar. A versão ISO pode ser copiada para um CD e depois o boot pode ser realizado pelo próprio CD.

A única desvantagem para quem quer testá-la: o Buildix foi criado sobre uma distribuição Linux chamada Knoppix. Porém o pessoal da Thoughtworks montou uma distribuição bem enxuta e, desse modo, ela não possui interface gráfica e browser. Portato se voce quiser apenas fazer uma demo terá que acessar o servidor através de outra máquina ou então baixar e instalar o servidor gráfico do Linux e um browser.