Marco Mendes´s Blog

A imagem tradicional sobre processos de software é que eles são burocráticos, pesados e só aplicáveis em empresas paquidérmicas. Contrariamente, processos devem ser simples e ajustados como uma roupa feita sob medida em um alfaiate. Observo que a maioria dos projetos do nosso mercado são pequenos (< 1000 horas) e realizados por poucas pessoas (entre 3 e 6 pessoas) e que a maioria dos exemplos colocados em livros, artigos e consultorias são inadequados à estas realidades. Esta dicotomia gera uma sensação de frustração dos leitores destes livros, incapacidade de tangibilizar estes conceitos em suas realidades e consequente volta ao mundo real em processos conserta e remenda.

Mesmo processos como o IBM RUP, por exemplo, podem (e devem) ser adequados sem problemas a projetos de pequeno porte. Infelizmente isso requer expertise em engenharia de processos de software. Uma alternativa a isso é o Open UP-Basic Version (Basic Unified Process), parte do esforço de conhecimento livre compartilhado pela Rational ao projeto Eclipse Beacon. O BUP pode ser entendido como uma personalização muito simples do RUP, ajustado para projetos de pequeno porte e times pequenos co-locados fisicamente.
Recomendo o artigo em anexo acima para desmitificar a visão clássica de processos e melhorar a qualidade dos pequenos projetos, infelizmente carentes de métodos e processos de qualidade.

O projeto Beacon, conhecido oficialmente como Eclipse Process Framework Process, nasceu da doação de parte do IBM RUP (Rational Unified Process), processo unificado da Rational. Este projeto ainda está em fase embrionária, mas já oferta boas idéias e produtos de custo de aquisição zero para quem quer melhorar a qualidade de seus projetos .

Sem comentários »

É possivel hoje realizar o desenvolvimento de software com bastante qualidade e auxílio de ferramentas livres de custo de aquisição. Estas ferramentas, em sua grande maioria, não fornecem toda a robustez e funcionalidades de ferramentas de ciclos de desenvolvimento de software de fornecedores como IBM, Microsoft, Borland e Oracle, mas são um excelente ponto de início e aclimatação em boas práticas de engenharia de software.

A lista seguinte apresenta algumas ferramentas sem custo de licença que podem apoiar neste processo.

É importante lembrar, entretanto, que uma ferramenta freeware não é uma ferramenta sem custo, pois o modelo mental de cada ferramenta exige capacitação, treinamento e personalizações na realidade de cada empresa.

1 comentário »

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 não-funcionais ou suplementares de um produto. Um requisito não-funcional 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 não-funcionais 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 Não-Funcionais
2. Criação de uma prova de conceito para cada requisito não-funcional 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 não-funcionais 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 não-funcional 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 não-funcionais 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!

  1 comentário »

O autor Scott Adams, criador do excelente quadrinho Dilbert, usa exemplos da vida corporativa para seus roteiros e histórias - A arte imita a vida.

Estranhamente, a comunidade J2EE parece copiar as histórias do Dilbert - A vida imita a arte?, com seus erros constantes em garantir compromissos básicos de projetos como custos, qualidade, escopo e prazos. No artigo que apresentamos no ultimo SUN TechDays em Abril deste ano em Belo Horizonte, ressaltamos alguns exemplos de como não gerir projetos J2EE e também um conjunto de boas práticas para evitá-las.

Gerência de Riscos J2EE:Gerência de Riscos J2EE

Sem comentários »

O analista de requisitos é o profissional responsável primário pela identificação, análise, priorização, detalhamento de requisitos e principalmente nos processos de controle de mudanças ao longo do ciclo de vida de um software. Este analista tem papel fundamental para o sucesso dos projetos, no apoio ao controle de escopo, prazo e custo realizado pelo gerente do projeto, na interface com os envolvidos (stakeholders) e na passagem do conhecimento de negócio para os analistas de sistemas, desenvolvedores, testadores, arquitetos de software e outros membros do projeto.

Para realizar bem este papel, é necessário que o analista tenha um perfil dinâmico, investigativo e que fomente uma comunicação franca entre todos os envolvidos no projeto. Tecnicamente, é necessário se atualizar e estudar técnicas modernas de análise de requisitos como a gerência de requisitos, modelagem de domínio, UML 2, modelagem de casos de uso, modelagem de processos de negócio/BPMN, mecanismos de controle de mudanças (Change Control Board), desenvolvimento iterativo, entre outras. Coloco abaixo uma lista primária de recursos comentados para apoio ao analista de requisitos iniciante neste complexo mas importante processo.

• Requirements - An Introduction - Nível: Introdutório - Scott McEwen Metasys Technologies, Inc - Abril 2004
  http://www-128.ibm.com/developerworks/rational/library/4166.html

• The seven habits of effective iterative development - Nível: Introdutório - Eric Lopes Cardozo (eric@empulsys.com), Founder and Director, Empulsys - Junho 2002
  http://www-128.ibm.com/developerworks/rational/rationaledge/

• Diagramação UML 2.0 - Nível: Introdutório - Scott Ambler
  http://www.agilemodeling.com/essays/umlDiagrams.htm

• Modelagem UML - Nível: Introdutório - Scott McEwen Metasys Technologies, Inc. - Abril 2004
  http://www-306.ibm.com/software/rational/uml/

• Ferramentas para Redução de Riscos em Gerência de Requisitos - Nível: Intermediário - IBM - 2004 - Requirements and Analysis Kit
  1 comentário »

A escrita de casos de uso não é um processo simples. Através de um pequeno tutorial de casos de uso descrevemos os cuidados e nuances que um analista de requisitos deve considerar ao escrever um modelo de casos de uso.

4 comentários »