O "Endeusamento" de cronograma em projetos de TI

Fazer cronogramas para software é sem sombra de duvidas um ritual místico e religioso. É macabro ver como são feitos. O ritual começa da seguinte forma: um indivíduo seguindo orientações divínas, coloca em um pedaço de papel, tempos de execução de cada tarefa. Seguindo a numerologia orientada pelo deus Cronos. Somente o deus Cronos e o maluco que fez o cronograma, sabem de onde vieram tais números cabalísticos. Quando alguma coisa sai errada nos cronogramas, algum membro da equipe é oferecido em sacrifício ao deus Cronos, devidamente enfeitado com uma maçã na boca.

 

 

Como (e por quê) criar uma arquitetura executável em sistemas de informação

Uma das maiores falhas de gerentes e líderes técnicos em projetos de software é ignorar os riscos técnicos inerentes em tecnologias como J2EE, .NET, Delphi, VB, SAP/R3, entre tantas outras. Exemplos destes riscos manifestados incluem:

• Sistemas Web ou de banco de dados que não escalam por ausência de testes de desempenho
• Erros em operações financeiras por falhas de precisão em representação numérica
• Alta taxa de erros em sistemas de atendimento (call center) e perda de clientes devido a falta de testes de usabilidade.

Muito dinheiro é perdido anualmente no Brasil devido a estas falhas. Pense por um instante quantas horas de projeto provavelmente voce já precisou gastar devido a falhas desta natureza…
Um forma de dar com este problema é realizar, no começo do projeto, a identificação dos requisitos arquiteturais de um produto. Um requisito arquitetural determina um critério de qualidade a ser observado, como por exemplo o tempo médio de resposta das telas de um sistema, a taxa de crescimento anual em registros de um banco de dados, a precisão numérica de operações financeiras ou os browsers suportados em uma aplicação Web.
Normalmente estes requisitos podem ser avaliados e medidos durante o ciclo de vida de um projeto, o que garante acordos minímos de qualidade do produto em construção. Uma boa equipe deve, portanto, criar um mecanismo de aferição destes requisitos arquiteturais ainda nas fases preliminares do projeto. Chamamos aqui este mecanismo de aferição de uma arquitetura executável, que consiste de código executável que viabilize a construção do sistema como um todo (requisitos funcionais) e sua operação em produção sem contratempos. Metaforicamente, a arquitetura executável é similar a fundação de um prédio de engenharia civil, que consiste de uma estrutura que garanta que todos os andares de prédio sejam montados posteriormente.
Criamos um roteiro abaixo que mostra como criar uma arquitetura executável, em três passos:
1. Identificação dos Requisitos Arquiteturais
2. Criação de uma prova de conceito para cada requisito arquitetural que seja risco técnico alto.
3. Validação da arquitetura executável, que consiste do conjunto de provas de conceito realizadas no item 2.
O passo 1 deve ser realizado a partir de questionários e modelos disponíveis na literatura como a norma ISO 9126 ou o modelo FURPS+ (Usado para coletar requisitos não-funcionais no RUP).
O modelo FURPS+, por exemplo, trabalha os seguintes aspectos de qualidade:

• Funcionabilidade: Estética e consistência na interface com o usuário.
• Confiabilidade: Disponibilidade (a quantidade do sistema “funcionando apropriadamente”), exatidão dos cálculos do sistema e a capacidade de recuperação do sistema após falhas.
• Desempenho: Rendimento do processamento, tempo de resposta, tempo de recuperação, tempo de inicialização e tempo de encerramento.
• Suportabilidade: Possibilidade de teste, adaptabilidade, sustentabilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade e possibilidade de localização.

O problema primário destes modelos é que eles são áridos para iniciantes e pessoas sem background arquitetural. Para ajudar neste problema, colocamos abaixo uma versão mais leve, em formato de questionário, baseado na norma ISO 9126.

1. Precisão
   • O sistema realiza operações financeiras? Se sim, especifique o número de casas de precisão destes cálculos.
   • O sistema é de extração de dados/estatístico/ engenharia e realiza cálculos matemáticos complexos ? Se sim, especifique o número de casas de precisão das regras de transformação/cálculo.
   • O sistema manipula medicamentos, compostos quimícos ou elementos cuja dosagem possam causar danos a seres humanos?
2. Interoperabilidade
   • O sistema se comunica com outros sistemas, hardwares ou bases de dados? Se sim, especifique os sistemas de comunicação, hardwares ou bases de dados.
   • O sistema é de comércio eletrônico (B2C ou B2B)? Se sim, especifique os sistemas de comunicação do B2C ou B2C.
3. Segurança
   • O sistema deve realizar controle de acesso (autenticação e autorização)?
   • O sistema deve garantir o sigilo das informações trafegadas na rede interna ou internet (condidencialidade e integridade)?
   • O sistema deve realizar auditoria (log) das operações?
4. Maturidade
   • O sistema deve funcionar vinte e quatro horas por dia, sete dias por semana (missão crítica)? Se não, especificar o tempo máximo que o sistema pode ficar fora do ar (ou alternativamente porcentagem mínima de operação).
5. Tolerância a Falhas/Recuperação de Falhas
   • Em caso de falha do sistema, existirá algum plano de contingência ou de retomada de operação?
     Se não, especificar o tempo máximo que o sistema pode ficar fora do ar.
6. Facilidade de Entendimento
   • O sistema deve ter help-online ou manual?
   • Deve haver treinamento ou workshops para os usuários do sistema?
7. Operabilidade
   • O sistema usa hardwares específicos (canetas óticas, PDAs, URAs, telefones celulares, plotters ou outros)?
   • O sistema é de pronto atendimento (ex: call-centers)?
   • stema deve operar em browsers outros além do Internet Explorer?
8. Comportamento de Tempo
   • O sistema deve ter funcionalidades que rodem abaixo de seis segundos? (*) Seis segundos é um valor, medido em testes de usabilidade, onde usuários de sistemas computacionais começam a perceber a latência do sistema em uso. Como todo valor, ele deve ser contextualizado à sua realidade.
9. Comportamento de Recursos
   • O sistema irá rodar na Internet ou Intranets de grande porte? Se sim, especificar o número máximo de usuários esperado em horários de pico.
   • O sistema irá manipular bases de dados com muitos registros? Se sim, especificar o número máximo de registros e a taxa de crescimento anual.
10. Conformidade e Facilidade de Troca
    • O sistema deverá rodar em quais sistemas operacionais?
    • O sistema deverá rodar em outros hardwares além dos PCs? Se sim, especificar quais hardwares.
11. Padronização
    • O sistema deve obedecer a alguma lei, norma, regulamentação ou portaria governamental? Se sim, especifique.
    • O sistema deve obedecer a algum padrão definido na organização alvo onde o sistema irá funcionar. Se sim, especifique o padrão.
12. Facilidade de Instalação
    • O sistema deve possuir instalador para usuários finais?

O questionário acima não é completo. Remova, altere e adicione itens ao mesmo, mas não deixe de ter o seu roteiro para entrevistar os seus usuários e coletar estes requisitos suplementares. Temporalmente, você deve terminar esta coleta na fase de iniciação do projeto pois estes requisitos são críticos e normalmente de alto risco. Por exemplo, se o seu projeto tem vinte semanas de duração, você deve ter extraído os requisitos arquiteturais e riscos associados nas duas primeiras semanas do projeto.
Ao terminar este processo, iremos partir para o item 2, que consiste em montar provas de conceito que mitiguem os potenciais riscos destes requisitos. Para isso, iremos trabalhar um exemplo simples. Suponha que coletemos um requisito de desempenho que nos peça para suportar 4.000.000 transações por dia e um máximo de 200 usuários concorrentes no sistema. Um requisito desta natureza impõe um alto risco no produto pois existe uma alta chance de não ser suportado em uma típica configuração PC Intel + windows + Servidor Web. Se existe o risco, devemos mitigá-lo. A mitigação deve ser feita com código executável e não com modelos UML apenas. Criamos então uma primeira versão do produto, que chamamos de Alfa 1, que consiste de um requisito funcional implementado sujeito as condições do requisito arquitetural em análise. Por exemplo, podemos implementar um versão simplificada de um relatório ou página sendo consumida simultaneamente por 200 usuários. A versão Alfa não possui compromissos reais de funcionalidade como por exemplo possuir todos os campos ou realizar todas as consistências de negócio, mas deve ser suficientemente real para mitigar o risco. No nosso exemplo poderíamos ter descoberto que precisaremos de duas máquinas em um cluster para operar com tal carga. O risco foi mitigado e a topologia física agora se baseia em uma decisão técnica e não em uma especulação ou estimativa.
O procedimento exemplificado acima é repetido para cada risco identificado e novas versões (Alfa 2, 3, N) são geradas ao longo de alguns dias ou algumas semanas para projetos de maior porte. Temporalmente, o primeiro terço da vida do projeto deve conseguir gerar uma arquitetura executável que mitigue todos os riscos destes requisitos suplementares. Em um projeto de vinte semanas, este processo deve ser encerrado até a sexta ou sétima semana. O passo 2 (Criação das provas de conceito) se encerra aqui.
Finalmente, temos um conjunto de códigos evolutivos que compreendem alguns requisitos funcionais (normalmente entre 5 e 20% do escopo do sistema), que atendem a todos os requisitos arquiteturais que impõe riscos técnicos alto no sistema. Chamamos isso de uma arquitetura executável, que deve ser então testada e validada por um audiência maior. Eventualmente, ajustes devem ser feitos e novos alfas serão produzidos até que a arquitetura se estabilize. Este produto é chamado de arquitetura executável e serve como linha de base arquitetural do sistema. O passo 3 se encerra aqui.
Quais as vantagens desta abordagem, pode perguntar o leitor mais cético?

• A grande maioria dos riscos técnicos do sistema foram mitigados. As surpresas técnicas em produção nao existem mais, pois foram detectadas, analisadas, implementadas, testadas e homologadas previamente.
• O tempo investido em arquitetura permite agora a paralelização dos recursos o que fornece economia de escala em médio prazo.
• O retrabalho de projeto é reduzido drasticamente. Por exemplo, cito o caso de uma empresa de Belo Horizonte que detectou tardiamente em um projeto que o browser Mozilla precisava ser suportado em sua aplicação Web (Veja novamente o item Operabilidade no item 1 do nosso processo). Após mais de 50 requisitos incorretos, isso gerou um retrabalho de mais de 1000 horas e um custo extra de mais de 50.000 reais! A pergunta que pode ficar é: Quem cria uma arquitetura executável? O arquiteto de sistemas é o papel responsável pela criação de uma arquitetura executável. O arquiteto, entretanto, nào é um super-homem. Ele é muitas vezes composto de um comitê de pessoas que em um trabalho conjunto irão identificar e mitigar riscos técnicos e então criar a arquitetura executável de um sistema.
  Se você está começando um novo projeto agora, pare por cinco minutos e pense. Você quer gastar horas e horas intermináveis em sessões de depuração de código à noite. viver a pressão de atrasos, falta de qualidade no código e ter noites mal dormidas? Se não, invista agora em criar a sua arquitetura executável do seu sistema. O trabalho é desafiante, mas o benefício é garantido!
  

Modelagem de Domínio - Ferramenta Essencial para a Modelagem de Sistemas Computacionais

O termo domínio é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais que exibam funcionalidades similares.

Exemplos de domínio incluem:

• Domínio de Telecomunicações
• Domínio Logístico Atacadista
• Domínio Bancário
• Domínio de Seguros de Saúde
• Domínio Acadêmico Escolar

Podemos então descrever o domínio aplicacional como sendo uma coleção de aplicações de software que partilham um determinado conjunto de características. Da mesma forma, o domínio é definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.

Um modelo de domínio é um artefato comum em várias metodologias (RUP ou escolas ágeis) usado para expressar um determinado domínio, normalmente em linguagem UML.

Antes de definir este artefato, vamos dizer o que não é este modelo. Um modelo de domínio não é um diagrama de classes em nível de análise, um diagrama de classes em nível de desenho, muito menos um modelo de entidades e relacionamentos (DER). Um modelo de domínio não carrega informaçães técnicas (Java ou C#), que devem estar presentes em um modelo de desenho. Um modelo de domínio também não carrega todo o detalhamento do comportamento e estrutura (operações e atributos), que devem estar presentes em um modelo de análise. Um modelo de domínio também não carrega informações de armazenamento de informações ou normalizações, que devem estar presentes em um DER.

Mas, afinal, o que é um modelo de domínio?

1. Um modelo de domínio é um produto da modelagem de negócios, i.e., ele representa, em certa escala, o negócio sendo modelado e compreendido.

2. Um modelo de domínio deve, por consequência, ser realizado inicialmente pelos analistas de negócios e usuários do projeto, e revisado e complementado pelo máximo de participantes de um projeto. O modelo de domínio deve ser um artefato colaborativo, compartilhado por todo o time do projeto.

3. Um modelo de domínio captura o vocabulário do sistema ou negócio sob modelagem. Como exemplo, um modelo de domínio de um sistema acadêmico de uma faculdade irá possuir os elementos Aluno, Professor, Curso, Disciplina ou Matrícula, entre diversos outros. Podemos perceber, então, que o modelo de domínio expressa o glossário do negócios sob modelagem.

4. Um modelo de domínio é uma representação lógica e estrutural de elementos do domínio e seus relacionamentos. Um diagrama de classes UML possui os elementos necessários para esta estruturação. Normalmente os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. Como consequência, um modelo de domínio não captura interações temporais ou representações físicas de modelagem.

5. Um modelo de domínio expressa uma visão conceitual preliminar acerca de um sistema e é chamado de diagrama de classes conceitual por alguns autores. Um exemplo extraído do excelente site do Scott Ambler (http://www.agilemodeling.com) de modelagem de domínio representa esta idéia.

(c) Scott Ambler, 2003-2006.

6. Um modelo de domínio deve ser feito no começo do projeto. Temporalmente, ele deve ser expresso e ganhar maturidade até o primeiro décimo do projeto. Por exemplo, se você tem na sua mão uma demanda de dois meses, devemos conseguir um modelo de domínio relativamente estável até o fim da primeira semana. Isso requer, como pode ser imaginado, um esforço intenso com os usuários chave para capturar o vocabulário, glossário e representá-lo em UML.

7. Um modelo de domínio (enquanto artefato) não precisa ser evoluído formalmente no restante do projeto. Isto pode parecer estranho, mas o objetivo do modelo de domínio é capturar o negócio e servir de insumo para a geração de modelos mais formais como o diagrama de classes ou o DER e depois o código executável. Em outras palavras, podemos imaginar o modelo de domínio como um estágio evolucionário para gerarmos os diagramas estruturais, comportamentais e o código de um projeto de software. Cabe citar que o modelo de domínio, enquanto conceito, como bem capturado pelas resenhas a este blog, evolui sempre, isto é, o diagramas de classes, o DER e o código também refletem conceitualmente o domínio do problema e por isso podem ser entendidos como “modelos de domínio”.

8. Um modelo de domínio também é um padrão arquitetural para a modelagem de sistemas OO, padrão este que encapsula lógica de negócios e dados em entidades coesas. Uma referência mais densa sobre este aspecto pode ser encontrada no excelente livro Patterns of Enterprise Application Architectures (http://martinfowler.com/books.html#eaa), do autor Martin Fowler. Recomendo também o artigo Anemic Domain Model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) como anti-exemplo do uso deste padrão.

9. Um modelo de domínio pode carregar padrões de análise. Um padrão de análise não é um padrão técnico (desenho ou arquitetura), mas uma representação conveniente para expressar um aspecto de negócio em sistemas de informação. Exemplos de padrões de análise envolvem a representacão de quantidades (monetárias ou medicamentos), a representação de faixas de valores (início/fim), padrões contábeis (parcelamentos de dívidas, contratos) ou representação de papéis (roles). O site sobre Analysis Patterns (http://martinfowler.com/articles.html#ap) do autor Martin Fowler traz informações valiosas sobre este tópico.

Se você não entendeu nada até o momento, um exemplo pode ajudar a colocar alguma luz neste conceito. Vamos assumir que você precise representar o domínio de sistemas de gestão da geração e transmissão de energia elétrica. Um modelo de domínio que mostra este negócio em termos de seus elementos (ex: transformador, consumidor de energia) e relacionamentos é mostrado aqui.

Compilo aqui, para os mais interessados neste artefato e nesta técnica, uma lista de referências mais técnicas de modelagem de domínio de vários especialistas de mercado.

• ICONIX: http://www.ddj.com/architect/184414689 - Fornece uma visão sobre os 10 erros mais comuns na modelagem de domínio de sistemas computacionais.
• Introduction to Class Normalization - http://www.agiledata.org/essays/classNormalization.html - Fornece uma visão evolutiva sobre modelagem de classes em UML.
• Agile Modeling – http://www.agilemodeling.com/essays/amddPresentation.htm - Traz princípios complementares sobre a modelagem ágil de sistemas.
• Análise Robusta – http://www.agilemodeling.com/artifacts/robustnessDiagram.htm e http://www.ddj.com/architect/184414712 - Técnica complementar à modelagem de domínio para capturar entidades, comportamentos e fronteiras de um sistema.

Modelagem de processos de negócio e modelagem de eventos complexos - Quando usar BPM e CEP

A abordagem de modelagem de processos tem sido muito discutida e quase sempre recomendada para iniciativas SOA. A massiva propaganda e momentum BPM parece nos indicar que é sempre interessante modelar processos para resolver um problema. A realidade, entretanto, é diferente da teoria, baseado em um cenário real que discuti hoje no começo da noite em uma empresa que está em uma franca implementação SOA.

Ouvindo John Zachman

A figura abaixo mostra o Zachman Framework. A coluna “How” é o domínio do BPM. A coluna “What” é o domínio das capacidades. A coluna “When” é domínio dos eventos complexos (CEP).

Processos expressam como fazer alguma coisa. Antes de pensar no como, entretanto, devemos pensar no que devemos fazer. Estes quês denotam as capacidades a serem desenvolvidas dentro de uma organização e, surpreendentemente, podem levar a uma abordagem completamente diferente que não implica no como, mas no quando.

Detecção de Fraudes e Processos de Manufatura

Considere uma capacidade de uma seguradora de detectar fraudes. A abordagem tradicional BPM iria buscar modelar os processos que podem detectar uma fraude. Entretanto, modelar a classe de processos que detectam fraudes pode levar uma conjunto extremamente complexo de variações que são muito difíceis de manter na prática. É um caso completamente antagônico ao processo de manufatura fabril, que pode ser classicamente modelado através de um processo discreto com variações conhecidas a priori.

A abordagem de captura de fraudes pode ser endereçada por uma outra dimensão na figura do Zachman Framework, que é a dimensão do quando, ou da modelagem de eventos complexos. A modelagem de eventos complexos nos dá instrumentos matemáticos muito interessantes, que resumo na figura abaixo que retrata as capacidades de um produto open-source popular neste meio, o Drools Fusion.

A figura abaixo mostra padrões intervalares e correlações temporais espaciais que podem ser capturadas através de máquinas de inferência de eventos complexos.

Por exemplo, com eventos complexos, podemos habilitar uma máquina de inferência para monitorar em um cenário de uma seguradora que dispare um alerta na ocorrência de pelo menos três das condições abaixo quando um novo “fato”de Sinisto ocorrer.
- Atraso na denúncia de mais de 72 horas;
- Número excessivo de testemunhas (maior que 3)
- Ausência de testemunhas.
- Sinistro que melhora situação difícil (situação cadastral ruim no SERASA).
- Desproporção entre causas e efeito do sinistro.
- Sinistro acontecido em ambiente familiar ou de amigos.
- Dificuldades ou demora em fornecer os documentos pedidos.
- Excesso de sinistros ou sinistros não compatíveis no período (saúde).

Naturalmente, não advogo que CEP deve ser usado para qualquer cenário. O CEP é indicado para alguns cenários bem específicos e deve ser realizado com bastante cautela.

A regra é que alguns problemas requerem uma abordagem baseada em processos e outros problemas requerem uma abordagem centrada em eventos. Outros problemas requerem as duas abordagens. Entretanto, todos os problemas podem ser modelados dentro do contexto da Arquitetura Corporativa, no contexto do Zachman Framework.

Little Coders

Lideres Técnicos e Gerentes de Projetos - Porque duas cabeças pensam melhor que uma

Vemos muitos projetos que falham por problemas gerenciais. Um destes problemas é a distância entre o gerente de projeto e a sua equipe. Times que não se sentem orientados e aconselhados diariamente perdem o seu foco e se dispersam. Para combater esta distância, devemos fomentar e incentivar a figura do líder técnico de desenvolvimento (que em muitas empresas também é o arquiteto de sistemas).

O líder técnico de desenvolvimento mantém o time unido e coeso. Ele mantém a consistência técnica do produto de software sendo construído e atua como um coach para todo o time para os problemas técnicos e de ausência de motivação, que são comuns em projetos complexos e com prazos desafiadores.

O líder técnico/arquiteto é o contraponto musical do gerente de projeto. O líder técnico e o gerente de projeto atuam como um par-alfa de lobos em uma alcatéia na caçada pelo sucesso do projeto.

As fronteiras entre o Gerente de Projeto e o Líder Técnico de Desenvolvimento

Adapto abaixo um trecho do livro Applied Software Architecture, de Christine Hofmeister, Robert Nord e Dilipe Soni, que explicita a fronteira entre a gerência de projeto e a liderança técnica de projetos.

Atividade	Gerente de Projeto	Líder Técnico
Desenvolvimento de software	Organizar o projeto; gerenciar recursos, orçamentos e cronogramas	Organizar o time em torno do desenho arquitetônico; gerenciar dependências técnicas
Requisitos	Negociar requisitos com áreas clientes	Revisar e negociar requisitos
Questões pessoais	Contratações, avaliações de desempenho; salários; motivação	Entrevistas; fornecer apoio técnico, motivar o time de desenvolvimento
Tecnologia	Introduzir novas tecnologias a partir da recomendação do líder/arquiteto	Recomendar tecnologias, treinamentos e ferramentas
Qualidade	Garantir a qualidade do produto	Rastrear a qualidade do desenho
Métricas	Mede a produtividade, tamanho, qualidade e custo	Garantir objetivos do desenho arquitetural

Motores de Regras - BRMS 101

Com a popularização de projetos SOA, também houve um renascimento do conceito de motores de regras (Rule Engine). Mas o que são motores de regras?

Um motor de regra é um sistema computacional que tem a capacidade de executar um conjunto de regras de negócios em um ambiente de produção. Eles são chamados em inglês de BRMS (Business Rules Management Systems).

Um BRMS não nos é útil se não entendermos o conceitos primário de uma regra de negócio, descrito abaixo.

Regras de Negócio - Átomos de Negócio do Domínio

Uma regra de negócio expressa uma restrição sobre um domínio de negócio. Um exemplo simples é mostrado abaixo:
Se o cliente possuir cadastro de crédito positivo no SERASA, então o desconto sobre o financiamento será de 1%

A premissa de um motor de regras é que as regras podem ser expressas e mantidas em uma linguagem natural (ou uma aproximação) e portanto permitem uma velocidade e responsividade muito maior da TI a alterações regulatórias e de inovação nas áreas de negócio. Em tese, a mudança da regra de desconto de um financiamento de crédito pode ser totalmente implementada por um analista de negócio em um sistema BRMS, sem conhecimentos profundos dos complexos padrões WS-* e de linguagens pouco produtivas como Java, COBOL ou C++.

Regras não são um agrupamento desordenado de textos. Um modelo de regras deve ser identificado e organizado a partir de um conjunto de critérios formais tais como:

• um vocabulário de negócio que exprime a semântica dos conceitos sendo trabalhados em um domínio - Fatos;
• um conjunto de proposições que permitem a geração de conhecimento a partir destes fatos.

No exemplo acima, podemos identificar como fatos primários o CLIENTE e o FINANCIAMENTO. A proposição do exemplo usa o crédito do CLIENTE para estabelecer uma política de desconto sobre o FINANCIAMENTO.

Um modelo formal para compreender como estruturar regras de negócios é o OMG SVBR, cuja versão 1.0 está disponível aqui. Recomendo fortemente que os iniciados em BRMS estudem este documento antes de abrir e trabalhar com uma suíte BRMS. O documento pode parecer tedioso, mas assim como para dirigirmos um carro precisamos de aulas de legislação, precisamos entender que suítes BRMS estão baseados em conceitos não tão populares que precisam ser entendidos. Para os mais apressados, uma boa introdução ao tema está disponível aqui.

Outras especificações relacionadas são o OMG BMM (que motra o papel das regras de negócio dentro da modelagem de negócio) e o OMG PRR (que mostra como um programa computacional pode ativar inferências a partir de um conjunto de regras de negócio e uma memória de trabalho). O PRR é, em termos leigos, o mecanismo de inteligência artificial usado pelos motores de regras. O BMM, por sua vez, permite entender como o BRMS está ligado com o BPM e as estratégias corporativas.

Suítes BRMS

Um BRMS parece ser apenas uma ferramenta, mas como o próprio nome diz ele se refere a um conjunto de ferramentas, onde cada ferramenta tem um propósito. Listo abaixo algumas categorias de ferramentas BRMS:

Sistemas de produção de regras. Sistemas baseados em algoritmos de produção de regras como o RETE. Normalmente permitem que analistas e desenvolvedores expressem regras em uma linguagem natural baseada em critérios IF/THEN. Um exemplo de ferramenta nesta linha é o Drools Expert.

Sistemas de processamento de eventos (CEP). Eventos são regras temporais que podem ser expressas da forma WHEN/DO e permitem a construção de sistemas que reajam a eventos e realizem algum tipo de raciocínio temporal/espacial. Um exemplo de evento seria: Quando houver três transações de débitos no cartão em menos de trinta minutos em três estabelecimentos comerciais diferentes, realizar o bloqueio do cartão e solicitar que um atendente ligue para o proprietário do cartão para confirmar o desbloqueio. Uma ferramenta nesta linha é o Drools Fusion.

Sistemas de governança de regras. É fácil criamos centenas ou milhares de regras em uma implementação BRMS. É mais fácil ainda perdemos a governança sobre estas regras. Regras possuem versões, dependências e impactos sobre outras regras. Portanto, possuir um sistema de governança de regras é fundamental em implementações BRMS. O Drools Guvnor é um exemplo deste tipo de ferramenta.

Um ambiente de desenvolvimento para criarmos regras. Um exemplo nesta linha é o plugin Eclipse JBOSS Tools, que permite a criação e manutenção de regras de negócio no Drools.

A Morte dos Sistemas de Informação de TI

Um velho paradigma de TI é traduzir o conceito da construção de sistemas de informação (da administração) para a construção de grandes sistemas de informação automatizados de TI. É fácil reconhecer este paradigma, que se manifesta pelos seguintes sintomas:

• grandes especificações de requisitos, que consomem meses (ou anos) para a produção de livros (obsoletos no dia D+1);
• projetos com cronogramas gigantes e orçamentos com 6 dígitos;
• grandes equipes;
• sistemas monolíticos baseados na tecnologia da década (Cobol, Pascal, C, Java, C# ou linguagens dinâmicas);
• sistemas incapazes de gerar valor de negócio e obsoletos antes mesmo de entrar em produção;
• prejuízos proporcionais ao tamanho do desafio e um sentimento de incapacidade.

Pense em capacidades de negócio e serviços
Citando um velho ditado latino chamado “Divide et impera”, a chave para sermos efetivos é quebrar o conceito de “sistemas de TI” e pensar em termos do conceito de capacidades de negócio e também em termos de serviços de negócio. Serviços de negócio são pequenos módulos de negócio que geram algum valor de negócio para a organização. A vantagem desta abordagem é que serviços de negócio podem ser colocados rapidamente em produção, gerar valor real de negócio muito mais rapidamente e permitir uma adaptação do negócio a mudanças do mercado.

Dê menos ênfase em arquiteturas de sistemas de software. Dê mais ênfase em arquiteturas de referência de serviços
Se os serviços de negócio forem criados sem uma fundação, a tendência é que eles gerem um tipo de construção arquitetural chamada “puxadinho de software”. Antes que serviços sejam criados, mantidos e evoluídos, uma fundação para estes serviços deve ser estruturada e criada. Esta fundação é chamada de arquitetura de referência de serviços e opera como um elemento que permite acomodar estes serviços ao longo do tempo em termos dos seus elementos técnicos e de seus elementos de governança.

Pense na ótica de negócio
A TI não existe para o seu próprio fim. O fim da TI é potencializar negócios. Permitir aos decisores, através da agilidade e sustentabildiade dos serviços de negócio, uma rápida tomada de decisão pode fazer toda a diferença nas organizações. O pensamento na ótica de negócio requer uma mudança de filosofia na parte de TI. Sistemas monolíticos com ciclo de vida de meses ou anos podem ser “divertidos empreendimentos técnicos” ou “máquinas de faturamento de fábricas de software”, mas tem comprovadamente e repetidamente gerado fracassos retumbantes.

Arquitetura Corporativa para Leigos

O conceito de Arquitetura Corporativa existe já há quase 30 anos na indústria de TI e administração, mas apenas nos últimos anos tem obtido alguma visibilidade no mercado Brasileiro. Mas o que é mesmo uma Arquitetura Corporativa?

Adaptei um meta-modelo de um corpo de conhecimento chave para arquitetura corporativa, o TOGAF, que mostra a visão holística da arquitetura dentro de uma empresa.

Uma arquitetura corporativa tem alguns pontos chave, que destaco aqui:

• ênfase no pensamento estratégico de forma que o time de arquitetura gere uma visão arquitetural para todo projeto, de forma que que todo o esforço do time de arquitetura seja convergente às expectativas de negócio dos gestores;
• a clara necessidade de organizar os requisitos arquiteturais do projeto antes que a solução seja endereçada;
• a decomposição da arquitetura em quatro disciplinas: arquitetura de negócio, arquitetura de aplicações/software, arquitetura de dados e arquitetura tecnológica;
• a governança de todo o esforço arquitetural nos projetos, iniciativas e oportunidades, i.e, um controle dos artefatos arquiteturais gerados, a mensuração do valor gerado por estas iniciativas e o controle dos ciclos de melhoria contínua.

De forma pragmática, a arquitetura corporativa nos ensina que escolher uma tecnologia no primeiro dia do projeto normalmente tende a ser uma má idéia. Isso traz uma profunda implicação para os “arquitetos Java EE” ou os “arquitetos .NET” que usualmente levam a sua tecnologia a tira-colo antes de entender o problema, a estratégia de uma organização e capturar corretamente os requisitos arquiteturais que eles devem endereçar. Em verdade, o próprio termo “arquiteto Java EE” ou “arquiteto .NET” traz uma contradição per se.

O tema arquitetura corporativa é ainda muito vasto e desafiador, mas a internalização dos alguns dos seus princípios fundamentais pode nos ajudar a resolver problemas de TI de forma a gerar maior valor de negócio para as empresas e com soluções mais robustas e assertivas.

Um Pequeno Glossário Para Arquitetos de Software

Compilo aqui um pequeno glossário de termos usados dentro do processo de arquitetar software. Estes termos foram compilados a partir de fontes diversas da literatura de arquitetura, da experiência de colegas de trabalho e também da nossa experiência em projetos. Acredito sinceramente que estes termos podem ajudar arquitetos a comunicar conceitos e remover mal-entendidos comuns em projetos de TI, especialmente com leigos na disciplina de arquitetura de software.

Condutor Arquitetural
Uma importante diretriz, de natureza de negócio ou técnica, que conduz e influencia as decisões arquiteturais primordiais de um projeto. Os condutores arquiteturais expressam os principais elementos da estratégia arquitetural a serem observados pelo time de arquitetura.
Como exemplo, um projeto de um novo portal governamental pode ter como condutores a universalização do acesso (padrão EGov), a confidencialidade dos dados dos contribuintes e não repudiação no acesso das informações.
Condutores são negociáveis e devem ser priorizados conforme a sua importância estratégica ou tática dentro do cronograma de um projeto.
Projetos de complexidade média possuem entre seis e doze condutores. Projetos muito complexos podem ter algumas dezenas de condutores.

Princípio Arquitetural
Um princípio arquitetural é um tipo especial de condutor, que se torna tão importante que passa a ser não negociável. Um princípio arquitetural é também chamado de meta-condutor.
Como exemplo, um projeto de um home-banking pode ter como um dos seus princípios arquiteturais o elemento a segurança dos dados de um correntista, enquanto que um projeto de uma promoção de um feriado comemorativo em uma empresa de TELECOM pode ter como princípio arquitetural o tempo de mercado.
Projetos devem ter poucos princípios arquiteturais (Normalmente um número entre três e seis princípios)

Requisito Arquitetural
Um requisito arquitetural é um requisito de alto valor de negócio, alta complexidade e abrangência técnica e que permite detalhar um condutor arquitetural. Requisitos arquiteturais devem ser específicos, mensuráveis, atingíveis, realizáveis e rastreáveis. Por exemplo, no exemplo anterior da segurança para o sistema de home banking, poderíamos identificar um requisito arquitetural de autenticação que requer que usuários sejam corretamente identificados no primeiro acesso a um portal.

Requisitos arquiteturais não são necessariamente requisitos não-funcionais. Requisitos arquiteturais podem advir de requisitos funcionais, desde que estes gerem impacto para a arquitetura. Por um exemplo, um requisito de cadastro de bilhetes em um sistema de bilhetagem de TELECOM pode gerar impacto para a arquitetura de persistência, dado que as bases de dados podem precisar manter e recuperar quase 1 bilhão de registros em alguns exemplos reais no Mercado Brasileiro.

Visão Arquitetural
A visão arquitetural expressa os objetivos primários do esforço arquitetural dentro de um projeto de TI. A visão arquitetural promove o alinhamento das estratégias técnicas à visão de um produto a à estratégia de uma organização.
A visão arquitetural pode ser complementada com um primeiro rascunho ou desenho chamado de visualização de negócio (esboço arquitetural).

Visualização de Negócio
Também chamada de esboço arquitetural ou marketecture, é um diagrama de forma livre e com formas humanizadas que permite comunicar o propósito da arquitetura a todos os envolvidos de um projeto, inclusive gerentes e leigos.
Muitas vezes esta visualização de negócio é denominada, incorretamente, de arquitetura, por leigos na terminologia técnica de arquiteturas de software.

Estratégia Arquitetural
A estratégia arquitetural define a forma de atuação básica do esforço arquitetural. Advinda da escola do pensamento estratégico (OMG BMM e BSC), a estratégia é composta da visão arquitetural, da visualização de negócio e é baseada também nos princípios e condutores arquiteturais.

Tática Arquitetural
Uma estratégia é composta por um conjunto de táticas. Uma tática arquitetural, também chamada de mecanismo arquitetural por alguns autores, define uma preocupação importante no espaço da solução. Exemplos de táticas podem incluir a persistência de objetos, a interoperabilidade entre aplicações ou a auditoria.
Um tática pode ser expressa em nível de análise, nível de desenho ou nível de implementação, à medida que for refinada dentro de um projeto. Por exemplo, o requisito arquitetural que expressa que usuários sejam corretamente identificados pode ser expresso nas seguintes táticas:
• Tática de análise: Autenticação
• Táticas de desenho: Autenticação com LDAP ou Autenticação com Kerberos
• Tática de implementação: Autenticação com os produtos OpenLDAP ou Microsoft AD com Kerberos.

Plano Arquitetural
Reflete o planejamento do projeto referente às ações do time de arquitetura. Este plano é desenhado a quatro mãos pelo arquiteto de software e o gerente do projeto.

Risco Arquitetural
É um risco que pode afetar a arquitetura do projeto e eventualmente gerar um colapso técnico dentro do produto. Por exemplo, dentro de um projeto que envolva a comunicação em tempo real entre dois sistemas, a latência de disco pode ser um risco arquitetural que deve ser identificado e mitigado.

Arquitetura Candidata
É um primeiro desenho da arquitetura, com as principais decisões e estratégia do projeto. É normalmente usada para gerar um processo de viabilidade técnica do produto nas fases preliminares de um projeto. Em projetos ágeis, deveria ser o produto de um primeiro Sprint. Em projetos baseados no UP, deveria ser produzida no primeiro décimo de um projeto.
Em diversos processos e métodos, é formalizada em um documento chamado de Documento de Arquiteutra de Software (DAS).

Arquitetura Executável
Representa uma arquitetura que contenha fragmentos de códigos executáveis, normalmente produzidos para mitigar riscos arquiteturais de táticas e requisitos arquiteturais complexos. Uma arquitetura executável é refinada ao longo de um projeto, embora deva ser trabalhada com mais ênfase nas fases iniciais de um projeto.
Quando uma arquitetura executável consegue mitigar todos os principais riscos de uma arquitetura, esta é chamada de arquitetura executável estável. Em processos baseados no UP, a arquitetura executável estável é o marco de fim de fase de Elaboração.

PSP (Personal Software Process) com o Eclipse - Parte 1: Tapando os Buracos do Tempo!

Você chega para trabalhar as 8:30. Examina a sua lista de tarefas do seu projeto alvo, cujo número está em cinco tarefas abertas. De forma entusiástica, você começa a examinar a primeira tarefa.

As 8:45, o telefone toca. Você é chamado para uma reunião sobre um problema residual de um outro projeto. Você fica nesta reunião até as 10:00.

Às 10:10, o seu colega do lado o chama para resolver um complicado problema de depuração. Mais vinte minutos se passam sem que você se dê conta.

Você consegue retornar para o seu projeto, mas somente até 11:00. Neste momento um cliente telefona e interage com você por mais quinze minutos.

Às 11:15, você para ler apenas 3 ou 4 emails - afinal, ninguém é de ferro. Infelizmente você precisa responder dois deles e gasta mais vinte minutos.
…
As 18:00, você está estressado e cansado. A sua lista de tarefas ainda está com 4 tarefas em aberto, e o seu tempo foi dragado por vilões invisíveis. Infelizmente você apropria no seu timesheet 8 horas no seu projeto original, vai para casa desaminado e pensa: “Para onde foi o meu tempo?”.

Se você já viveu o sintoma acima, você realmente trabalha com desenvolvimento de software. Neste trabalho, o volume de interrupções é enorme e se não tivermos ferramentas para gerenciar o nosso tempo, não temos ciência sobre a nossa real produtividade.

Um dos objetivos do PSP é aumentar a nossa produtividade. Isso somente é possível através de medição. A primeira lei da gerência é: “Não se gerencia o que não se mede”. O PSP, então, trabalha fortemente a auto-gerência do tempo, i.e, mecanismos onde você irá vigiar o seu tempo rigorosamente para saber o que você faz durante um típico dia de trabalho.

O Mylar, plugin gratuito para o Eclipse, permite que você faça este controle exigido pelo PSP. Isso é realizado através do conceito de tarefas pessoais (Personal Task). Dentro do Eclipse com este plugin já instalado, você tem a possibilidade de criar uma lista de tarefas, como mostrado na figura abaixo:

Um característica interessante deste plugin é que voce pode ativar uma tarefa. Basta clicar com o botão direito em uma tarefa e clicar “Activate”. Ao realizar este processo, o Mylar usa o mecanismo de instrumentação do Eclipse e começa a contar (em minutos e segundos), quanto tempo você está gastando naquela tarefa. Se um telefone tocou, se você parou para lanchar, se você foi interrompido por outro evento, você apenas precisa se lembrar em clicar sobre a tarefa com o botão direito novamente e clicar em “Deactivate”. A contagem é interrompida e você pode retomá-la a qualquer instante ou ativar uma outra tarefa.

Em qualquer instante, você pode examinar quanto tempo você ainda possui em uma tarefa ou quantos minutos já foram decorridos. No exemplo acima, 2:34 minutos já foram gastos da tarefa “Implementar Tela - Cadastro de Correntista”.

Um uso não intrusivo do Mylar, para quem nunca trabalhou com o paradigma de programação focada em tarefas, é usá-lo apenas para os eventos maiores de um dia (ex: Almoços e Reuniões). Um efeito interessante, em médio prazo, é perceber que o seu dia típico de trabalho não possui 8 horas (o que é senso comum). Você talvez descubra que o seu dia típico no seu projeto seja de 7, 6 ou mesmo 5 horas. Este número é rico e deve ser reportado à sua gerência para a criação de cronogramas mais realistas.

Estudiosos de medições de projetos, como por exemplo Capers Jones, já realizaram estatísticas no mercado Brasileiro e constataram que uma pessoa de TI tipicamente trabalha 132 horas por mês. Se considerarmos que temos 22 dias úteis em um mês, chegamos ao valor de 6 horas por dia. Interessantemente, conheço empresas de grande porte no Brasil que tem como norma em seus cronogramas de projeto não alocar pessoas em projetos mais de 6 horas por dia. Sábia decisão!

O efeito subliminar de medir o próprio desempenho é muito interessante. Talvez você descubra na primeira semana que você somente está trabalhando no seu projeto 60% ou 65% do seu tempo útil.
Com esta informação em mãos, você reage quase que por instinto aos vilões de tempo.

Você passa a atuar nas tarefas mais prioritárias. “As coisas mais importantes primeiro”

Voce passa a organizar o seu tempo de forma bem mais rígida e consegue ter mecanismos de comprometimento muito mais fortes.

Você aumenta a sua eficácia e passa a ter mais tempo para realizar o que é realmente importante. Recomendo que você instale o Mylar e passe a organizar as suas tarefas semanais. Na primeira semana, organize apenas 4 ou 5 tarefas. Progressivamente, melhore o seu nível de controle. Os efeitos são mágicos uma vez que você passa a ter controle do seu tempo.
O Mylar pode ser baixado deste site - http://www.eclipse.org/mylar/dl.php.
Obviamente, ser eficaz não é ser eficiente. O fato de você ter 8 horas disponíveis não quer dizer que você não terá retrabalho

O Famoso Gerente de TI: “E aí, tá pronto?”

Projetos de TI (Tecnologia de Informação) impõe desafios únicos, muitas vezes não observáveis em projetos de engenharia, tais como requisitos extremamente variáveis, pressões de tempo muitas vezes não realistas e dificuldades de aferir e medir a qualidade do produto entregue. Neste cenário já conturbado, infelizmente presenciamos mais uma força negativa, que vou apelidar aqui de Gerente: E Aí?.

O que é o Gerente: E Aí?.

É fácil reconhecê-lo pelas seguintes características:

• Possui pouco domínio do contexto e das tecnologias usadas.
• Possui extrema dificuldade de expressar, seja pessoalmente ou por falta de apoio de um líder técnico competente, os entregáveis do projeto em uma lista detalhada de atividades técnicas necessárias para realizar aquele entregável.
• Usa mecanismos de pressão com o time. O paradigma do século XIX “Cenoura e chicote” é bastante usado.
• Não consegue criar um isolamento e ambiente saudável de trabalho para o time.
• Não se comunica com a equipe, a não ser por emails e reuniões formais e impessoais. Fica quase todo o dia na frente do seu computador, em uma sala especial com mobiliário de padrão melhor que seu time. Afinal, precisa demonstrar que é o chefe.
• Abusa da manipulação gerencial. Frases como “Precisamos de mais empenho!”, “Vamos trabalhar este final de semana para o bem do projeto.” e “Vocês precisam ter mais compromisso.” são comuns no vocabulário deste tipo de gerente.
• Abusa das perguntas “E aí, tá pronto?”; “Já terminou?”, “Fica pronto para hoje, ok?”.

Infelizmente, o Gerente: E Aí? o não consegue obter o respeito do time. Normalmente ele é alvo de piadas de todo o time. Um dos maiores malefícios deste tipo de gerente é afetar o moral e motivação do time. Steve McConnell (em seu excelente livro Rapid Development) e Tom de Marco (em seu excelente livro Peopleware) mostram a correlação negativa da taxa de sucesso de projetos e gerentes manipuladores.

Capers Jones, outro excelente estudioso de fatores de sucesso e fracasso de projetos de TI, observa também que times sob pressào extrema introduzem até 40% a mais de defeitos que times similares em um ambiente saudável. Um excelente texto sobre ambientes saudáveis em TI pode ser achado na seção “Hygienic factors”, do livro supra-citado do Steve McConnell.

O novo milênio e os novos paradigmas pedem novos tipos de gerentes. Projetos de complexidade como observados em TI pedem um novo tipo de gerência. Vamos chamar este gerente de Como posso te ajudar.

O Gerente Como posso te ajudar? pode ser reconhecido pelas seguintes características:

• Possui bons ou excelentes conhecimentos do domínio em que atua. Este tipo de gerente não precisa ser certificado Java ou .NET, mas deve conseguir manter um diálogo técnico mínimo com a sua equipe. Por exemplo, você já viu um projeto de um prédio de vinte andares que não tenha sido gerenciado por um Engenheiro?
• Consegue expressar claramente os entregáveis de um projeto em uma lista de atividades precisa, com o apoio de processos como o RUP, EUP ou metodologias ágeis. Conhece bem processos de software.
• Isola, a todo custo, o time das pressões comerciais dos clientes e da alta gerência das empresas do time. Este tipo de gerente sabe que o que não ajuda, pode atrapalhar.
• Usa mecanismos de motivação para fazer o time trabalhar bastante. Como Barry Boehm observa do alto de sua experiência de quase 50 anos em TI e mais de 80 de idade, a motivação é o fator que mais contribui isoladamente para diferenciar times de projeto de mesma capacidade técnica em tecnologias similares.
• Está em constante circulação, fisicamente ou virtualmente, com suas equipes exercendo um papel pró-ativo e removendo os empecilhos encontrados pelo time. Este gerente é um “coach”, na melhor definição do termo.
• Conhece profundamente técnicas de negociação “Ganha Ganha ou Nada feito”. Com isso, consegue um profundo respeito do time e portanto um sentimento de compromisso de toda a equipe para bater as metas de projeto.
• Acima de tudo, reconhece que ele não é chefe, mas um mero servidor. Um gerente “servidor” existe para o bem único e exclusivo de apoiar o time a cumprir as metas do projeto.
  

Um excelente livro que discute este novo paradigma gerencial é o livro “O Oitavo Hábito, do autor Steven Covey”. As claras diferenças entre o gerente clássico e o líder são discutidas à exaustão neste livro. Em resumo, o gerente Como posso te ajudar comunica valores corretos às pessoas e com isso libera o potencial das mesmas.

Um aspecto fundamental nesta diferenciação dos gerentes é a autoridade formal vs autoridade moral. A autoridade formal é imposta através de hierarquias. A autoridade moral é conseguida através de liderança.

Como analistas, arquitetos e desenvolvedores, devemos buscar cada vez mais gerentes líderes para nossos projetos e educar gerentes do século XIX a uma profunda mudança de atitude e comportamento.

Finalmente, como gerentes devemos entender como desenvolver nossas habilidades de liderança. Uma fonte de inspiração e conhecimento é o autor Warren Bennis, que possui excelentes livros e tratados sobre liderança de times.

Fazer Software é Como Construir uma Ponte ou Dirigir um Filme?

Toda a nossa escola de gerência de projetos tradicional vêm da escolha de gerência de projetos da engenharia. Como exemplo, cito o PMI, talvez a escola mais difundida e aceita de gerenciamento de projetos de TI no Brasil e EUA. O PMI foi criado ainda no final dos anos 60 e seus membros iniciais eram pessoas de engenharia civil. Na escola de engenharia, o paradigma de planejamento detalhado e acompanhamento minuncioso deste planejamento é o modelo mental ainda usado no nosso seculo XXI.

Na área de TI, copiamos este modelo e também as ferramentas (como o Project ou o Primavera). Entretanto, algo parece errado. Quantos projetos eu já acompanhei (como participante, observador ou como executor do cronograma) onde a nossa inabilidade de montar e seguir um plano detalhado foi tornada aparente (e frustante). Várias vezes me questionei - “Algo está errado, mas não sei muito bem o quê”.

Felizmente, parecem existir evidências fortes que estamos usando o modelo errado para atacar um problema comum em TI, que é como gerenciar projetos e obter sucesso.

Gostaria de compartilhar um artigo que li na IEEE, de um autor de renome (Walker Royce) na área de gerenciamento de projetos e que lança luz neste tema - Successful software management style: Steering and balance. Embora controverso, devemos realizar algumas análises sobre a essência de projetos de software. Projetos de software, de forma geral, possuem as seguintes características (identificadas por Walker Royce):

• Não existem leis físicas ou de propriedades de materiais para restringir as soluções aos seus problemas. A restrição está na imaginação humana, restrições econômicas e desempenho da plataforma física que hospedará o software. Sistemas embutidos, obviamente, são excecões.
• Tudo pode ser mudado em um projeto de software - planos, pessoas, financiamentos, marcos, requisitos, desenhos e testes. Praticamente tudo é negociável.
• Métricas e medidas para produtos de software normalmente são melhor avaliadas através de modelo de valor percebido pelo usuário do que modelos clássicos de engenharia como custo e produção. Aspectos de qualidade são muitas vezes subjetivos como por exemplo manutenabilidade, confiabilidade e usabilidade.

Concordo em linhas gerais como esta análise. Uma outra força neste aspecto é o tempo de vida de uma arquitetura de software. Em um recente artigo na InfoQ, Sadek Drobi conjectura que uma arquitetura expira em dez anos - “Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture“. Após este período, as manutenções se tornam cada vez mais caras e o sistema deve ser refatorado em uma nova arquitetura, sob o risco de gerar cada vez mais prejuízos para o negócio. Esta força mostra como a inventidade humana e inovações dificultam a aplicação de leis comuns em engenharia civil como por exemplo “Fazer para durar”.

A conclusão, que eu concordo, é que a melhor metáfora para a construção de softwares é a concepção de um filme. Precisamos, como apontado por Walker Royce, de arquitetos qualificados (diretores), analistas (roteiristas), engenheiros de software (equipe de produção, atores, editores, dublês) e gerentes de projeto (produtores). Entretanto, a metáfora técnica é que a disciplina de gerência de projetos é regida pela disciplina software economics ao invés da disciplina de software engineering. As decisões diárias de gerentes de projetos de software são dominadas por julgamentos de valor, relações de custo benefício, fatores humanos, tendências macro-econômicas, forças de mercado e pressões gigantescas de tempo. A escola de Software Economics, que tem como um de seus mentores Barry Boehm, pode ser definida como a escola científica de desenho de software fundamentada em modelos formais de valores e criação de valores em condições de incerteza, informações incompletas e competição.

O planejamento iterativo (ou planejamento em duas fases) no processo unificado é um escolha de gerência de projetos muito mais adaptável a esta realidade. O planejamento iterativo define planos em alto nível para as etapas de um projeto e somente realiza o planejamento detalhado para a etapa atual. Neste contexto, podemos incluir o SCRUM aqui também. O SCRUM nos ajuda a organizar a dinâmica de eventos variáveis e lidar com as exceções (impedimentos) que vivemos (enquanto gerentes de projetos) em uma iteração (etapa) específica de um projeto. Coloco, então, o SCRUM como um complemento natural ao planejamento iterativo do RUP.

A escola de metologias ágeis de gerenciamento de projeto Extreme Project Management (XPM), embora sem menção explícita a metáfora de filmes, usa princípios similares para o planejamento e acompanhamento de tarefas.

Começamos a observar o nascimento de ferramentas mais adequadas a este paradigma. Apesar de considerar ferramentas como o Primavera ou o MS Project excelentes, não as considero adequadas para o gerenciamento de projetos de TI. Estamos usando um martelo para bater em algo que não é um prego!

Uma versão mais leve do artigo do Walker Royce está disponível aqui no portal da DeveloperWorks da IBM. Recomendo fortemente a leitura deste artigo. São idéias valiosas (embora polêmicas), mas que me parecem descrever melhor a nossa realidade de projetos de TI.

Artigos mais detalhados e referências para os interessados nas escolas alternativas de gerência de projeto estão abaixo:

• Planejamento Iterativo - Planning an Iterative Project.
• SCRUM - Scrum it Now na Prática
• XPM - Extreme Project Management

Finalmente, deixo também uma coleção de publicações sobre a escolha chamada Software Economics, referenciada por Walker Royce em seu artigo.

A Relação Tensa entre Gerentes e Arquitetos de Software

Li recentemente um artigo que propõe um tema interessante ao discutir a personalidade de arquitetos de software e gerentes de projeto e a sua relação (normalmente tensa) em projetos de software. (The Tense Relation between Architect and Manager, Gerrit Muller).

Arquitetos e gerentes são peças fundamentais para o sucesso de um projeto e devem interagir fortemente em sinergia, como já apontado por Grady Booch em seu excelente livro Object Solutions, de 1995.

Um aspecto que Gerrit Muller endereça são os comportamentos associados a cada papel. Um resumo destas características é colocado abaixo:

• Arquitetos tem um escopo amplo em projeto e pouca autoridade formal. Gerentes, por sua vez, tem um escopo de atuação mais limitado e possuem muita autoridade formal.
• Arquitetos são independentes, criativos e curiosos. Gerentes são pragmáticos e focados em controles.
• Arquitetos encaram mudanças; vindas dos stakeholders, pressões de tempo e análise de problemas; como fatos da vida. Gerentes encaram mudanças como possíveis fontes de problemas e desvios financeiros.
• Arquitetos são motivados pela busca das melhores soluções. Gerentes são motivados por hierarquias e salários.

O autor coloca, finalmente, que arquitetos e gerentes devem buscar, conjuntamente, as seguintes técnicas para a melhoria do relacionamento e resolução destes problemas:

• Maior delegação de tarefas.
• Liderança ao invés de gerenciamento baseado em tarefas.
• Trabalho em time.
• Respeito mútuo.
• Reconhecimento da diversidade.
• Feedbacks contínuos.
• Estímulo à uma comunicação aberta e franca.

Recentemente, escrevi uma compilação de características de liderança de arquitetos de software, inspirados nos comportamentos de liderança descritos por Stephen Covey. Acredito que estas características podem ajudar a resolver este problema e promover como conseqüência maior sucesso aos projetos.

Creio que o maior valor do interessante artigo do Gerrit Muller é tornar claro que arquitetos e gerentes possuem sistemas de crenças e visões de mundo diferentes. Arquitetos e gerentes não podem cometer o erro de assumir que a outra parte irá pensar e agir como ele. Ao invés, gerentes e arquitetos devem conhecer a natureza da outra parte e desenvolver mecanismos pró-ativos para melhorar a comunicação e alinhamento nos projetos.

O Analista Desenvolvedor “Rambo”

John Rambo é um veterano do exército americano. Inicialmente ignorado pela corporação, ele é sempre chamado para resolver situações fora de contorle. Com uma faca na mão e uma metralhadora na outra, ele mata facilmente todos os inimigos e volta com a missão cumprida para casa. No cinema, pelo menos, é assim.

João Nerd é um veterano Brasileiro em projetos de desenvolvimento de software. Os seus conselhos técnicos são ignorados pela gerência de projeto no começo do projeto. Quando o projeto foge ao controle, entretanto, ele é chamado. Com uma IDE na mão e a especificação de requisitos na outra, ele deve resolver todos os erros complexos, reorganizar a arquitetura interna do sistema, desenvolver os casos de uso atrasados, trabalhar como bombeiro, estar presente nos finais de semana e salvar o projeto. Na vida real de TI, infelizmente, é assim.

Nas empresas de TI, por incrível que pareça, vemos gerentes que tratam seus analistas desenvolvedores como hérois do cinema. Eles os chamam de “Guerreiros” e deles esperam atitudes heróicas para salvar projetos em crises. Exemplos de atitudes heróicas incluem:

• Execução sem planejamento. “Faça de qualquer jeito. Se não funcionar, jogamos o código fora e pensamos em outra forma de resolve o problema.”.
• Internalização dos problemas. Por falta de gestão de riscos e medo de negociar com os clientes, gerentes internalizam os problemas e os deixam a mercê da equipe técnica.
• Horas extras voluntárias.
• Horas extras não pagas. Também conhecidas como “horas bestas”.

O anti-padrão “Heroics” é catalogado como um dos “Classic Mistakes” (Erros Clássicos) no excelente livro Rapid Development”, de Steve McConnell. Em sua análise, McConnell destaca que este padrão é muitas vezes provocado pela atitude gerencial “Pode Fazer”, ao invés da atitude correta “Meça consistente o progresso da equipe através de relatórios de status”. Ao enfatizar demasiadamente a atitude “Pode fazer”, grandes problemas são mascarados até que se tornem desastres. Gerentes perdem, portanto, uma valiosa oportunidade de tomar ações corretivas nas fases iniciais de projeto devido à ênfase em heróismo das equipes de TI.

Outros erros clássicos de TI são enumerados no site de Steve McConneli. O livro citado acima e cuja imagem está abaixo traz excelentes dicas de como evitá-los e bater cronogramas complexos de projetos. Leitura indispensável para líderes técnicos e gerentes de projeto.

Um tutorial para escrita de casos de uso

A modelagem de casos de uso lida com a formalização, documentação e comunicação de partes dos requisitos funcionais de sistemas computacionais e de processos de negócio. Contrariamente ao senso comum, a escrita de um modelo de casos de uso não é uma tarefa trivial e requer muita atenção devido a detalhes que não são óbvios para o analista de requisitos iniciante.

Trabalho aqui um exemplo de como escrever e como não escrever casos de uso, composto de erros comuns a analistas iniciantes e um refinamento sucessivo para a correção destes erros e produção um descritivo maduro de casos de uso. O exemplo é composto de 7 passos, refinados incrementalmente em níveis crescentes de maturidade.

Escolhemos como exemplo um processo didático de saque de dinheiro em uma máquina 24 horas, chamada aqui de máquina ATM (Automatic Teller Machine). Neste processo de negócio, podemos identificar um caso de uso de sistemas chamado “Sacar Dinheiro”, ativado por um ator primário chamado Correntista.

A nossa primeira tentativa de descrever este caso de uso segue abaixo:

Caso de Uso - Sacar Dinheiro - Versão 1

Ator Primário: Correntista
Objetivo: Permitir ao correntista de um banco conveniado ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O correntista insere a senha e o valor a ser retirado.
3. O correntista retira o dinheiro da máquina 24 horas.

Embora este processo atinja o fim esperado (dinheiro em espécie na mão do correntista), ele não descreve a interação entre o ator primário e o sistema sob desenho. O objetivo primário de um caso de uso é descrever a interação entre atores e o sistema sob desenho. Em uma metáfora com um jogo de ping-pong, a bola na versào 1 fica o tempo todo em um lado da mesa. Não existe conversação, não existe diálogo e portanto não existe captura dos processos de negócio que devem ser conduzidos pelo sistema.

A nossa segunda tentativa de descrever este caso de uso corrige este problema.

Caso de Uso - Sacar Dinheiro - Versão 2

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação do cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema valida a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A versão 2 é uma clara evolução. Existe um diálogo entre o ator e o sistema sob desenho. Alguns erros, entretanto, ainda persistem. Observemos, por exemplo, o passo (2). Como estamos projetando o sistema da máquina 24 horas, devemos nos lembrar que está fora do escopo (por pura impossibilidade) do nosso sistema realizar validações como por exemplo “Cartão Bloqueado ou Cancelado”. Isso é realizado pelo sistema do banco real (instituição de crédito), que se apresenta então como um ator secundário no contexto do nosso sistema. Isso seria identificado no mundo real através da definição da fronteira ou limite do nosso desenho. O erro aqui, portanto, foi ignorar a existência do ator secundário Banco Instituição de Crédito na descrição. Isso nos leva a terceira versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 3

Ator Primário: Correntista
Ator Secundário: Instituição de Crédito
Objetivo: Permitir ao correntista de uma instituição de crédito conveniada ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A terceira versão captura nos passos 2 e 6 as interações com atores secundários, ausentes na versão 2. Mais uma vez, entretanto, erros ainda existem na descrição. Um caso de uso deve capturar todos os processos de negócio realizados, sem no entanto entrar no mérito de como estes processos serão implementados. Em outras palavras, os casos de uso capturam as interações (O QUÊ), sem se preocupar com a implementação destas interações (COMO). Na versão 3, não capturamos processos básicos de um saque bancário, como por exemplo a validação da existência de dinheiro disponível na dispensadora de dinheiro, as restrições de saques diários, restrições de horários e o débito em conta corrente ao final da operação. Isso nos leva a uma quarta versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 4

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Embora esta versão 4 seja já razoável, muitos analistas de requisitos terminam o trabalho de escrita de casos de uso neste ponto. Estes analistas se esquecem que a ausência dos fluxos alternativos ou de exceção subestima a complexidades dos sistemas computacionais e gera desvios nos cronogramas de projeto. Portanto, é fundamental identificarmos os pontos de extensão deste fluxo. Não devemos, entretanto, realizar este processo verticalmente, mas primordialmente em amplitude para em um segundo momento realizarmos a escrita de cada ponto de extensão. Isso nos leva a versão 5, agora com os fluxos alternativos/exceção.

Caso de Uso - Sacar Dinheiro - Versão 5

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Ativado do Passo 2 - Cartão Inválido
Ativado do Passo 2 - Cartão Bloqueado ou Expirado
Ativado do Passo 2 - Cartão Não Suportado pela Máquina 24 horas
Ativado do Passo 4 - Senha Inválida
Ativado do Passo 4 - Saldo Insuficiente
Ativado do Passo 4 - Limite Diário na Instituição de Crédito Ultrapassado
Ativado do Passo 5 - Limite de Saque do Banco 24 horas Ultrapassado
Ativado do Passo 5 - Limite de Saque no Horário Ultrapassado
Ativado em Qualquer Passo - Cancelamento da Operação pelo Correntista

Outros pontos de extensão podem existir, naturalmente. O exemplo procura mostrar o fato que um brainstorming destes fluxos alternativos deve ser feito para que estes pontos de extensão sejam capturados.

Dentro da evolução da descrição, devemos também realizar o detalhamento de cada ponto de extensão. Um exemplo para o fluxo Senha Inválida é colocado abaixo.

Caso de Uso - Sacar Dinheiro - Versão 6
…
Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

Este trabalho, como citado, deve ser realizado para cada ponto de extensão da descrição do caso de uso.

Finalmente, devemos lembrar sempre que o modelo de caso de uso captura apenas interações entre os atores primários e o sistema sob desenho. Informações complementares como regras de negócio, interfaces gráficas, desenho detalhado ou persistência não são capturados na descrição. Estas informações podem (e devem complementar) a descrição de um caso de uso, sem entretanto interferir na legiblidade da leitura dos fluxos. A versão 7 (e última) deste artigo mostra como isso poderia ser realizado para regras de negócio simples do nosso exemplo de caso.

Caso de Uso - Sacar Dinheiro - Versão 7 (Final)
…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

… Outros Pontos de Extensão

Regras de Negócio
…
RN006 - Se correntista não possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado.
RN007 - Se correntista possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado mais o valor do limite de crédito.

… Outras regras de negócio

O resumo deste pequeno artigo mostra ao leitor que o processo de escrita de casos de uso é complexo e cheio de nuances. Para os interessados, sugerimos o excelente “Escrevendo Casos de Uso - Allistair Cockburn”, que descreve em bastante profundidade como escrever e como não escrever casos de uso.

A essência de métodos e arquiteturas ágeis - Comunicando Decisões Técnicas

A comunicação talvez seja o princípio mais importante das escolas ágeis mas é infelizmente muito mal compreendido por técnicos de TI. Exploro aqui duas rápidas questões sobre princípios de comunicação efetiva.

O princípio da comunicação quente
A paleta de cores abaixo mostra algumas formas de comunicação em projetos. Quanto mais quente (à direita), mais rico e efetivo é o mecanismo de comunicação.

Surpreendemente, analistas gostam de email e documentação (mesmo com o colega a dez metros de distância), que são formas frias de comunicação. Ao invés, comunicações quentes (conversas) devem ser usadas para estabelecer sinergia e transmitir idéias entre times. Este princípio, explorado anteriormente por Alistair Cockburn e revisitado por Scott Ambler, é descrito em mais detalhes aqui.

O princípio SUCESSO
Idéias que colam e sào lembradas por pessoas são simples, inesperadas, concretas, transmitem crença imediata, remetem a emoções e são baseadas em histórias. Cito como um exemplo um assunto aparentemente árido - a instrumentação de alarmes em sistemas telefônicos, que foi transmitido com sucesso através da metáfora arquitetural Clínica médica por um grupo de técnicos do nosso convívio.

O caso completo é descrito em mais detalhes aqui.

O livro Idéias que Colam, escrito por Chip Heath e Dan Heath, endereça estes princípios e fornece dezenas de exemplos de como comunicar efetivamente idéias para outras pessoas.É um livro brilhante e leitura indispensável a bons comunicadores.

Pensamento do dia: “True interactivity is not about clicking on icons or downloading files, it’s about encouraging communication.”, Edwin Schlossberg.

Ferramentas para testes técnicos em Java EE

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)