O SOFTEX divulgou os resultados de desempenho de 2009 das empresas que adotaram o MPS BR.

A síntese do relatório é fornecida abaixo:

“De forma geral, a satisfação das empresas com o modelo MPS é notória, com mais de 98% das empresas se dizendo parcialmente ou totalmente satisfeitas. Além disso, as empresas relataram que o retorno do investimento foi obtido e, principalmente, para aquelas empresas que evoluíram ou internalizaram o modelo MPS em seus processos foi possível observar tendência a melhoria de custo, qualidade, prazo e produtividade, princípios básicos quando se desenvolve software seguindo os preceitos de engenharia.”

Os resultados detalhados do estudo são muito interessantes e destaco neste espaço dois índices: o aumento do faturamento das empresas e o retorno sobre o investimento obtido no esforço da implementação. Com cada vez mais evidências estatísticas, podemos começar a observar dados quantitativos que correlacionam investimento em engenharia de software com melhorias concretas e permanentes nas empresas.

O relatório completo, para os interessados, está disponível aqui.

Todo software instalado possui uma arquitetura que o rege, seja esta tácita ou explicitamente construída por arquitetos de software. Além disso, toda arquitetura tem um estilo associado. Se não pensamos na arquitetura de um software e no estilo desta arquitetura, ela pode ter um estilo diferente do que gostaríamos. Um estilo inadequado pode aumentar sobre-maneira os custos de construção e manutenção de uma aplicação.

Estilo Arquitetural - O padrão primordial para externalização da sua arquitetura

Um estilo arquitetural é um padrão arquitetural primordial que antecede todos os outros padrões arquitetural.Ele define e direciona outros padrões arquiteturais, padrões de desenho e decisões táticas ao longo do projeto. Exemplos de estilos arquiteturais incluem:

• Cliente-Servidor
• Baseado em cadastros Web
• Aplicações Ricas de Internet (RIA)
• Multi-camadas (n-camadas)
• Baseado em integração de aplicações (EAI)
• Baseado em serviços
• Baseado em processos de negócio
• Dirigido por domínio (DDD)
• Baseado em computação em grade (Grid)
• P2P

Normalmente uma aplicação possui apenas um estilo arquitetural, embora em situações incomuns possamos ter estilos combinados ou mesmo um estilo particular. A escolha de um estilo, entretanto, não é escolhida pela conveniência de um arquiteto, mas pelos condutores de negócio do projeto, produto e empresa do contexto onde a arquitetura e o software estejam sendo produzidos.

Se escolhermos um estilo inadequado, o projeto sofrerá sérias dificuldades. Por não pensar no estilo, desenvolvedores são guiados por decisões táticas, o que leva na maioria dos casos a sistemas de informações cadastrais, mesmo quando o estilo tem outra natureza. Acompanhei um colega de profissão que foi comandado a usar um framework de mercado que automatiza padrões cadastrais em um sistema de estilo baseado em fluxos de trabalho. A equipe deste colega de profissão tentou durante alguns meses resolver o projeto, até que o projeto fosse cancelado devido a uma baixíssima produtividade.

Ao começar o seu projeto, então, convoque uma entrevista com os seus usuários e investigue o estilo arquitetural do sistema que você irá construir.

Pensamento do dia: “Bona diagnosis, bona curatio”, (Um bom diagnóstico, uma boa cura)

O termo BPM nos remete a uma ênfase na palavra processos e uma visão de mundo onde uma empresa pode ser vista como uma coleção de processos. Este pensamento, em si, é perigoso e infelizmente enganoso. A palavra processos nos remete ao “como” e nos faz esquecer do entendimento do “quê” deve ser realizado. A consequência prática é que algumas iniciativas BPM de mercado tem falhado ou no máximo obtendo ganhos marginais. Podemos combater este pensamento com o conceito das “capacidades de negócio” como um elemento que precede os processos de negócio.

Repensando o salto em altura
Conforme citado no bom livro Rethink, de Ric Merrifield, os saltos em altura eram realizados com o atleta em direção frontal ou diagonal à barra. Ao tentar melhorar a eficiência destas técnicas, alguns atletas apenas obtinham um ganho marginal na altura transposta. Ao remover o raciocínio limitante e pensar em uma nova forma de saltar, um atleta chamado Dick Fosbury estabeleceu novos patamares para o esporte, ganhou a medalha de ouro no méxico em 1968 e batizou o estilo de salto usado hoje em 2010 com o seu nome. Ele escapou da armadilha do “como” antes do “quê”.

Modelagem de Capacidades de Negócio
O problema do BPM não é o foco em processos, mas o foco prematuro em processos. O atleta Dick Fosbury trabalhou muito na eficiência dos seus processos, mas depois de entender as corretas capacidades a serem realizadas. Estendendo as idéias tradicionais do BPM, destacamos aqui a idéia das capacidades de negócio.

Uma capacidade de negócio é visão multi-dimensional de uma organização com um objetivo claro de negócio, atividades de negócio (processos), recursos humanos, um modelo de governança e serviços de negócio. Um exemplo no segmento de TELECOM seria a “Ativação de Serviços de Telefonia”. Um outro exemplo, no segmento de aluguéis de carros seria a “Gerência de Frotas”. Neste instante do tempo, ainda não estamos preocupados com os processos necessários para a ativação de telefonia ou os processos para o gerenciamento de frotas.

Técnicas de modelagem de capacidades como o IBM Component Business Model ou o Microsoft Business Capability Mapping podem nos ajudam a modelar todas as capacidades da sua organização e desenvolver visões chamadas de mapas de calor para perceber os elementos disfuncionais em uma organização. Ao saber que disfunções a nossa organização possui, podemos então focar então na modelagem dos seus processos e então nas suas melhorias.

A disciplina de modelagem de capacidades é vista como arquitetura de negócio e deve preceder e guiar as atividades de modelagem de processos de negócio. A modelagem de capacidades é realizada pelo arquiteto de negócio da sua organização e a modelagem de processos pelo analista de processos de negócio.

Para os interessados no tema, coloco aqui algumas referências a respeito:

• Artigo de Ulrich Homann sobre o conceito de capacidades de negócio.
• Artigo de Michael Poulin sobre o IBM Business Component Model.
• Entrevista com Ric Merrifield sobre a modelagem de capacidades de negócio.

Aplicações Java EE impõe fortes desafios aos times de testes, qualidade e arquitetura de aplicações. Além dos inúmeros aspectos funcionais a serem observados, devemos observar também elementos técnicos de qualidade interna e qualidade externa tais como desempenho, usabilidade, segurança ou manutenibilidade.

Sabemos que ferramentas isoladamente não resolvem problemas complexos, mas uma vez que você tenha um método simples e eficaz para endereçar um problema, podemos aumentar a eficiência do método com ferramentas eficientes. Neste contexto, destacamos aqui algumas ferramentas que podem apoiar o seu trabalho em testes técnicos na plataforma Java EE.

• Testes de acessibilidade - O portal DaSilva (http://www.dasilva.org.br) realiza testes de acessibilidade a partir dos padrões WCAG e eGOV. Além disso, o portal também disponibiliza uma ferramenta para download para testes em Intranets.
• Testes de desempenho - O Apache JMeter é uma ferramenta para testes de carga, estresse e maturidade de páginas Web, filas JMS, pool de conexões JDBC e outros objetos Java EE. Robusta e madura, possui diversos tipos de gráficos e análises estatísticas de confiança. Recomendo também uma extensão simples do JUNIT chamada JUNITPerf, para testes de caixa branca de desempenho ou vazão (thoughput).
• Testes de instrumentação de códigos e servidores - O Eclipse TPTP realiza testes de instrumentação de código (profiling), que permite análise em nível de caixa branca (métodos Java) o uso de CPU, consumo de memória, vazamentos de memória e mesmo contenções de threads. Muito robusto ele gera inclusive diagramas UML2 de sequência dinamicamente a partir da interação com o servidor de aplicação alvo.
• Testes de cobertura - Recomendo novamente o Eclipse TPTP, que permite analisar que linhas, métodos e classes foram cobertas durante um determinado tipo de teste. A ferramenta indica linhas virgens e também permite montar histogramas das seções e métodos mais usados durante teste de aceite do usuário.
• Testes de automação Web - A plataforma Selenium realiza a automação de testes na Web através do conceito de gravação automatizada, extensão dos códigos gerados e reprodução. Os scripts gravados podem ser incluídos em suítes do JUNIT e ser também colocados em processos de integração contínua. O TPTP também possui uma ferramenta neste sentido, embora um pouco mais complexa para operação que o Selenium.
• Testes de interoperabilidade - Ferramentas como o jMOCK ou o EasyMock permitem que simulemos recursos como programas de terceiros para que possamos fazer testes fim a fim mesmo antes que estes programas estejam prontos. Estas ferramentas são baseadas no conceito de “dublês” e simulam literalmente o comportamento de um recurso a ser integrado. Este tipo de tecnologia também é util em grandes projetos quando times estejam construindo módulos que requeiram grande integração. e que ainda não estejam prontos.
• Testes de manutenibilidade - O Metrics é um plugin simples para Eclipse que faz análises diversas de código e extrai métricas universais de qualidade como por exemplo a complexidade ciclomática. Em resumo, ela responde a pergunta se o seu código é manutenível ou não. Uma outra ferramenta de livre acesso neste sentido é o SourceMonitor, que também traz gráficos diversos de análise como gráficos de histogramas e diagramas de Kiviat (gráficos polares) para análises executivas de qualidade.

Caso você conheça alguma outra ferramenta de teste técnico para Java EE, deixe aqui a sua opinião ou comentário.

Pensamento do dia: Amplius juvat virtus, quam multitudo (Mais vale a qualidade que a quantidade)