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:
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:
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?
- 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.
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.
- 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?
- 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.
- 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?
- 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).
- 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.
- Em caso de falha do sistema, existirá algum plano de contingência ou de retomada de operação?
- Facilidade de Entendimento
- O sistema deve ter help-online ou manual?
- Deve haver treinamento ou workshops para os usuários do sistema?
- 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?
- 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.
- 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.
- 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.
- 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.
- Facilidade de Instalação
- O sistema deve possuir instalador para usuários finais?
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!
No comments:
Post a Comment