IT talks

Em 1937, a explosão de um boiler causou a morte de quase 300 crianças em uma escola de New London, Texas, EUA. A tragédia levou o estado norte-americano a instituir o licenciamento de engenheiros.

Hoje em dia, esta funcionalidade é controlada por software.

Qualidade em software é um assunto cada vez mais importante. Tão importante quanto perigoso e complexo.

Mesmo quando o objetivo é matar, falha de software pode significar morte do lado errado. Na Gerra do Golfo I, os mísseis Patriot ficaram famosos por não achar os Scuds iraquianos. Software bugs levaram o míssil a uma performance miserável e entre 25 e 28 soldados viraram pó em uma das muitas vezes que um Patriot ficou olhando para o lado enquanto o Scud passava assoviando.

Modernamente vemos falhas de software como resultado de falhas no processo de produção de software. Então, a qualificação de tais processos devem levar a erradicação de bugs, certo? Talvez.

Na Guerra do Golfo redux os Patriots agora não tiveram problemas para levantar vôo mas talvez fosse melhor que tivessem pois andaram derrubando aeronaves aliadas.

Incompetência da empresa de desenvolvimento de software? Pode ser, mas convido os leitores a visitarem o website da Raytheon e tomarem conhecimento de quão orgulhosa a empresa está de ter conquistado CMMI Nível 5.

Software é um dos artefatos mais complexos que o homem pode produzir. E gradualmente está tomando contrôle de quase todas as coisas não vivas que nos cercam.

Mesmo quando não mata, impõe custos altíssimos. De acordo com o Department of Commerce's National Institute of Standards and Technology (NIST) erros de software têm o custo de quase $60 bilhões por ano nos EUA.

O estouro do foguete europeu Ariane 5, em 1996, pulverizou aproximadamente $500 milhões. Motivo do desastre: numeric overflow em uma rotina sem error trapping. Como o mesmo bugento software rodava em todos os sistemas redundantes, 40s bastaram para o Ariane 5 virar decoração de festa São João.

Mais um caso de incompetência? Parece que sim, mas a comissão que investigou o vexame constatou o uso de avançadíssimas técnicas de engenharia de software no projeto.

Conclusão: qualidade em software é algo terrívelmente díficil e caro. Por isto mesmo, deveria ser motivo de total atenção dos profissionais da área e seus clientes.

Alguém poderia dizer que infelizmente ainda estamos anos-luz de um momento em que tal cultura de qualidade possa vicejar em nosso país. Eu diria a mesma coisa mas tiraria fora a palavra "infelizemente". Assim, o que é um problema vira na verdade uma oportunidade de mercado.

Outras referências:
Baseline Magazine: Why Software Quality Matters
Yardley, David. Successful IT Project Delivery. Addison Weley, 2002.

Na Califórnia do Governador Arnoldo o Senado aprovou legislação pertinente a scanning de emails. A iniciativa foi inicialmente uma reação ao anúncio do serviço GigaMail do Google mas acabou tomando forma mais abrangente.

De acordo com a resolução, emails podem ser escaneados para fins de marketing mas as companhias não podem armazenar esta informação em um banco de dados (pode ser em flat file?). Proíbe-se, também, o repasse para terceiros dos dados compilados pelo escaneamento.

Uma outra medida é que impõe que mensagens cuja deleção foi requisitada pelo usuário não podem ser mantidas nos bancos de dados.

Este é um interessante debate, com várias questões pipocando em volta:

- escanear uma mensagem de email e atachar mensagem publicitária relacionada ao conteúdo da mensagem é um atentado significativo à sua privacidade?

- se sim, quanto vale isto? Dá para trocar "facinho, facinho" por 1 gigabyte de armazenamento grátis?

Há um tempo atrás, comentando assuntos relacionados a privacidade, um cidadão aqui do Canadá publicou um artigo dizendo que ele tinha "se vendido por alguns bolos inglêses". Referia-se, o dito cujo, ao fato de que certa cadeia canadense de supermercados oferece uma caixa de bolinhos e outros penduricalhos se o cliente preencher uma ficha com dados pessoais.

Outra questão interessante é o armazenamento de emails. Acho até que não entendi bem esta resolução Californiana porque até onde eu sei nos EUA as empresas são obrigadas a armazenar suas correspondências eletrônicas e muito vagabundo de colarinho branco está vendo o sol nascer quadrado devido a picaretagens documentadas no servidor de email corporativo. Bem, talvez isto se aplique apenas ao email de empresas...

De qualquer forma, o debate está aí! 1 giga de email?! Hummm... tentador...

Leia o artigo original na eweek.

Uma ajeitadinha no tempo

Alguns anos atrás, quando eu estava trabalhando como líder técnico e de projeto um gerente tentou me dar alguns conselhos. Ela explicou que tinha observado que as etapas de teste e depuração de meus projetos estavam tomando significativamente menos tempo em comparação a outros projetos liderados por outras pessoas.

Seu argumento era que, apesar de meus projetos estarem sempre sendo concluídos dentro do prazo, eu deveria cortar tempo das etapas de análise de requerimentos e design pela metade, porque isto resultaria em projetos que terminariam bem antes do prazo final - uma grande dica!

Ela inclusive prometeu ao meu time um grande bônus se nós implementássemos a sua sugestão . Era além de sua capacidade entender que significativa redução do tempo gasto em teste e depuração poderia na verdade ser resultado de análise e design de qualidade.


Gilda Pour
Editorial Advisory Board Member
Software Engineering Professor,
San Jose State University
San Jose, Calif.


A versão original em inglês pode ser lida em http://www.sdmagazine.com/documents/s=739/sdm0010a/0010a.htm?temp=zX4IArjcwb

Peer-to-peer networks aparte, alguns bons livros sobre Java e Xml podem ser localizados e baixados de graça na rede.

Confira três bons títulos em The Server Side. Requer registro no site.

Software Development (SD) Times publicou este mês o seu "who's who 2004" da área de software.

Interessantemente, na categoria de banco de dados, MySQL AB leva o troféu.

Para conferir os demais vencedores e competidores clique aqui.

Segundo o Gartner Group, offshore outsourcing vai crescer 65% em 2004! É um impressionante número mas é sempre bom lembrar que isto é só uma previsão...

É importante lembrar, também, que alguns analistas apontam o especial interesse que o Gartner Group tem no assunto, uma vez que parece ser um membro ativo neste mercado.

Cuidado com os profetas que se beneficiam da realização de suas profecias.

Confira o anúncio da previsão no site das StickyMinds.

CA anunciou nesta segunda-feira que vai licenciar seu banco de dados Ingres na modalidade open source. Inicialmente, será um subconjunto do produto mas a lista pode mudar no futuro.

Segundo a companhia, a idéia é recuperar porções da renda perdida no mercado de bd através da oferta de suporte e serviços agregados.

Aquece-se assim o mercado de banco de dados open source, que já contava com contendores de peso como MySql, Postgres e Firebird.

Em especial MySql tem recebido crescente atenção no mundo corporativo. Recentes pesquisas indicam que este banco de dados cresceu 30% no ano passado ao passo que SQL Server e Access ficaram na casa dos 6%.

Clique aqui para ler a reportagem especial da eweek.com sobre open source databases.

Todo mundo conhece um ou outro jeito de subir dados de um arquivo texto para um bd Oracle. Não parece ser algo muito importante de se discutir... a não ser que, por exemplo, você tenha que implementar uma aplicação em que se espere subir entre 10 e 12 milhões de registros por dia!

Neste caso, vale a pena ponderar cuidadosamente as diversas opções disponíveis.

Um bom artigo sobre o assunto pode ser localizado em http://www.dbspecialists.com/presentations/load_faster.html

Também não sei, mas por via das dúvidas vou tirar 5 dias de férias com a família em Harrison Hot Springs, no hotel ao lado, para refletir sobre o assunto.

Deixo aqui 5 novos postings mas IT Talks deve ficar em suspenso por uma semana. Até lá recomendo aos famintos de conhecimento e sedentos de experiência que continuem checando o www.databasedesign.blogger.com.br onde Professor Felipe Machado gratuita e incansavelmente nos brinda com pérolas diárias de boa informação e razoável humor.

Estou no meio da leitura de "Agile Database Techniques", de Scott Ambler e a mesma tem se revelado bastante interessante. Aos poucos pretendo descrever aqui o resumo deste material.

O autor tem uma boa bagagem em projetos de desenvolvimento onde técnicas "agile" e normalmente orientadas a objeto se mesclam - ou melhor, se chocam - com a necessidade de lidar com bancos de dados relacionais e com a abordagem tradicional de modelagem de banco de dados, onde todo (ou praticamente todo) o banco de dados é modelado antes do desenvolvimento entrar na fase de contrução.

Por enquanto, reproduzo aqui apenas a resposta à pergunta-título deste posting:

"Com um terrorista é possível negociar".

Segundo Tom Kyte, não faça isto! De acordo com o guru Oracle, você vai estar bem melhor servido se optar por
- concatenar o nome do usuário com a senha
- aplicar uma função de hash no string resultante
- e armazenar o resultado da função.

Leia porquê (e como) na edição de maio da Oracle Magazine e no asktom.oracle.com.

A eweek.com reporta que o venerável Date andou iluminando platéias no 16o anual DAMA International Symposium.

Aqui vão algumas colocações do mestre Date:

"Entre as barreiras para o modelo relacional está SQL, que não implementa inteiramente este modelo. Em especial, NULLS são um problema."

"XML foi inventado para resolver o problema de troca de dados mas tendo resolvido este problema agora quer conquistar o mundo."

Leia o artigo na íntegra aqui.

Contraponto à Carta dos Direito dos Usuários (Karat)

O usuário pode ter razão, mas frequentemente tem dificuldades em expressar o que quer. A abordagem "quando eu enxergar eu vou reconhecer o que eu quero ou não, agora vai trabalhar!" ainda é prevalente em nossa indústria. Quem quer que tenha passado por experiências de desenvolvimento de requisitos com o usuário sabe o quão frustante e confuso este processo pode ser.

Além disto, identificar quem é o usuário pode ser um sério problema. Algumas empresas investem centenas de milhares de dólares apenas nesta atividade. Por outro lado, usuários são diferentes uns dos outros. Diferentes experiências levam a diferentes expectativas e haverão momentos em que estas expectativas serão irreconciliáveis.

Importante também é o fator custo. Qualidade tem custo e incrementos lineares em qualidade frequentemente significam incrementos exponenciais em termos de custo. O quanto os usuários estão dispostos a pagar por alta qualidade?

Desenvolvimento de software é um dos ramos de uma indústria ainda relativamente jovem e provavelmente tem se aperfeiçoado de maneira muito mais rápida que muitas outras indústrias estabelecidas. No entanto, ainda há um longo caminho a percorrer em direção à qualidade e satisfação dos usuários.

Se fizermos uma analogia com a indústria automotiva poderemos não só ver como a engenharia de sistemas tem avançado nas últimas décadas mas chegaremos, talvez, à conclusão de que assim como diferentes modelos de carro agradam a diferentes clientes, não há porquê se esperar que um mesmo software agrade a todos seus usuários.

(O texto acima é uma livre adaptação/tradução da resposta de Rick Craig à carta de Karat. O artigo original pode ser acessado aqui, no site das Sticky Minds.)

Há algum tempo atrás Clare-Marie Karat - uma pesquisadora da IBM com especialização na interação pessoa/computador - publicou um manifesto que ficou conhecido como a Carta de Direitos do Usuário.

Basicamente, estabelece que o cliente está sempre certo e o que deriva daí.

É uma visão um pouco desbalanceada do assunto mas vale a pena ler para talvez entender um pouco mais como os usuários podem se sentir em relação aos produtos que a área de sistemas cria.

User's Bill of Rights

1. The user is always right. If there is a problem with the use of the system, the system is the problem, not the user.

2. The user has the right to easily install software and hardware systems.

3. The user has the right to a system that performs exactly as promised.

4. The user has the right to easy-to-use instructions for understanding and utilizing a system to achieve desired goals.

5. The user has the right to be in control of the system and to be able to get the system to respond to a request for attention.

6. The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion.

7. The user has the right to be clearly informed about all system requirements for successfully using software or hardware.

8. The user has the right to know the limits of the system's capabilities.

9. The user has the right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns.

10. The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use.

Qual a contribuição deste ponto-de-vista para o aperfeiçoamento do processo de desenvolvimento de software?

Todos nós desejamos criar especificações de requisitos de qualidade. Mas o que significa isto exatamente?

Segundo Karl Wieger, requisitos devem ser completos, consistentes, corretos, viáveis, modificáveis, necessários, priorizados, investigáveis, livres de ambiguidade e verificáveis.

Veja o que isto quer dizer aqui.

O posting de mesmo nome no www.databasedesign.blogger.com.br apresenta um exemplo bem interessante de como coisas aparentemente simples podem de fato se revelar como um complexo conjunto de regras de negócio.

Como contribuição à discussão, meu comentário seria de que possíveis variações do modelo proposto poderiam ser consideradas se levadas em conta outros hipotéticos requisitos da aplicação

- UNIÃO CIVIL: está em consideração no Canadá a adoção do conceito de União Civil entre pessoas do mesmo sexo. O objetivo é regulamentar estes relacionamentos e garantir benefícios usualmente extendidos a pessoas unidas por matrimônio. Na prática, são dois nomes para a mesma coisa. Mas podem levar a diferentes regras de negócio. Assim, dependendo da aplicação, poderíamos imaginar que em vez de matrimônio teríamos uma entidade chamada mais propriamente de ... RELACIONAMENTO CIVIL (?) e uma nova tabela (ou um flag) indicando o tipo de relacionamento.

- Casais do mesmo sexo podem ter filhos, também, por adoção. Neste caso, o conceito de pai ou mãe pode ser difuso e pode até perder o sentido. Precavidamente, em termos de modelagem de banco de dados teríamos aí a coluna father_mother aceitando NULL.

- Tipo de filiação: biológica ou adotada. Algumas sociedades implementam severos mecanismos legais para impedir qualquer tipo de discriminação entre tipos de filiação. No Brasil, por exemplo, o filho adotivo é legalmente semelhante ao filho biológico. Isto significa que a certidão de nascimento é exatamente a mesma e não faz referência alguma ao processo de adoção. Provavelmente no Brasil é ilegal apropriar esta informação em um banco de dados. Se isto é verdade, também não faria sentido o atributo begin_date. No Canadá, a abordagem é diferente e bem mais relaxada neste aspecto.

- A necessidade de se colocar dados históricos e atuais na mesa entidade dependerá sempre dos requisitos da aplicação. Assim, uma outra hipótese é que a possibilidade de set ter 2 entidades para modelar a paternidade (corrente e histórica).

Então, um outro esboço do modelo (conceitual) poderia ser



Conclusão: só a detalhada análise dos requisitos da aplicação nos leva ao melhor modelo de dados. Estudos de caso como este são boas oportunidades para nos relembrarmos disto.

A resposta é que isto depende da versão de Oracle que se está utilizando. Até a última versão do 8i o mecanismo que monta o plano de acesso de cada consulta jamais iria se valer de um índice se

- o índice fosse composto por várias colunas

- e se a cláusula WHERE não estivesse referenciando as colunas do índice a partir da primeira delas (a mais da esquerda).

Assim, no caso em estudo, consultas com cláusulas

WHERE a = 1

ou

WHERE a = 1 and b = 1

poderiam levar o otimizador a considerar o uso do índice.

No entanto, consultas com cláusulas como

WHERE b = 1 and c = 1

ou

WHERE c = 1

provavelmente iriam levar o otimizador a se definir por um FULL SCAN (se este fosse o único índice para a tabela).

Isto era um dos conhecimentos básicos para os profissionais Oracle mais voltados à tunning e monitoração de performance, bem como um dos erros mais frequentemente cometidos pelos desenvolvedores.

Estas coisas mudam com Oracle 9i. A partir de então, Oracle passa a implementar o conceito de INDEX-SKIP SCAN que, em certas circunstâncias (como no estudo de caso aqui proposto) vai permitir a utilização do índice mesmo quando as colunas mais à esquerda do índice não são referenciadas.

Mais exatamente, Oracle vai se valer de um index-skip scan quando

- a cláusula WHERE referenciar colunas do "interior do índice"

- e o otimizador souber que a(s) coluna(s) à esquerda apresenta(m) poucos valores discretos.

Este novo recurso torna o otimizador ainda mais flexível e poderoso. No entanto, não significa que não há mais necessidade de que o desenvolvedor entenda o significado de suas consultas em termos do plano de recuperação de dados que vai ser efetivamente aplicado. Pelo, contrário: este é só mais um item de sua caixa de ferramentas.

A sequência de comandos Oracle abaixo cria a tabela t, cria um indice sobre as três colunas e gera estatísticas para a tabela.

create table t as
select mod(rownum, 3) a
rownum b
rownum c
object_name d
all_objects;

create index t_idx on t(a, b, c);

analyze table t compute statistics;

Um comando como

select * from t where b = 1 and c = 1

irá utilizar o índice criado acima?

Resposta em breve...

As melhores coisas na vida são de graça, incluindo uma estupenda ferramenta da Quest chamada Data Dictionary For Oracle.



Trata-se de uma interface gráfica para acesso ao dicionário de dados (DD) do Oracle 9i. Todas as views e colunas do DD estão lá, descritas uma a uma.





Melhor que isto: se desejado, dá para acessar pela própria ferramenta o conteudo atual das views.



Você pode baixar o software de graça dos Pipelines. Ouro puro.

Não estou ganhando nenhuma comissão da Honda, mas que o trabalho foi bem feito, isto foi: http://www.daboyz.org/honda/

Requer Flash 6.

Criar software é uma atividade que pode ser desenvolvida de qualquer maneira. Criar software de qualidade, ao contrário, é uma atividade necessariamente desenvolvida pelo grupo de desenvolvimento e o cliente do mesmo.

Se o grupo de desenvolvimento não trabalha por esta linha quase que fatalmente o projeto vai ser direcionado por aspectos tecnologicos e vai se distanciar do objetivo inicial. Por outro lado, se o cliente - por qualquer razão - não participa das diversas etapas do ciclo de vida do projeto então fica difícil para o grupo de desenvolvimento criar um produto que esteja à altura das suas expectativas.

Karl Wigers resumiu, em sua obra Software Requirements, os direitos e deveres do cliente de software.

Bill of Rights for Software Customers

1. To expect analysts to speak your language


2. To have analysts learn about your business and objectives
   
   
3. To expect analysts to write a software requirements specification


4. To receive explanation of requirements work products


5. To expect analyst and developers to treat you with respect
   


6. To hear ideas and alternatives for requirements and their
   implementation


7. To describe characteristics that make the product easy to use


8. To be given opportunities to adjust requirements to permit reuse


9. To receive good-fait estimates of the costs of changes


10. To receive a system that meets your functional and quality needs
    

Bill of Responsibilities for Software Customers

1. To spend the time to provide and clarifyrequirements


2. To be specific and precise about requirements


3. To make timely decisions


4. To respect a developer's assessment of Cost and Feasibility


5. To set requirements priorities


6. To review requirements documents and evaluate prototypes


7. To promptly communicate changes to the requirements


8. To follow the development organization's change process


9. To respect the requirements engineering processes the analyst use

O amigo javanês anda apostando em Websphere? Pois olhando para o gráfico recentemente publicado pelo Gartner Dataquest parece que foi uma escolha acertada. Há futuro para BEA? Confira em http://sys-con.com/story/?storyid=44801&DE=1

De acordo com The Standish Group, 2 entre 3 projetos de desenvolvimento de software vão fracassar. Mais ou menos 30% deles não vão nem terminar.

Quais as chances de sucesso de seu projeto atual? Como seria bom se houvesse uma maneira de determinar isto... Pois Steve MacConnell acredita que tem. E para tanto, montou um teste para medir a "fitness" de um projeto: o Survival Test.

Em http://www.construx.com/survivalguide/test.htm você vai achar o teste on-line e a sua versão Excel.

Boa sorte!

A modelagem de dados através de diagramas ER tem provado seu valor ao longo de décadas de utilização mas isto não quer dizer que seja imune a críticas ou aperfeiçoamentos.

Mais em voga atualmente, UML tem sido considerada uma excelente ferramenta para modelagem em projetos baseados em princípios OO.

Mas não é a única alternativa que existe. Poucas pessoas (ao menos do meu círculo de relacionamentos profissional) conhecem, mas existe algo chamado Object Role Modeling, ou simplesmente ORM.

Trata-se de uma "metodologia de projeto e query de modelos de banco de dados em nível conceitual".

Seus proponentes consideram ORM semanticamente mais expressiva e sintaticamente mais amigável para o usuário final ou o especialista de domínio - pessoas que geralmente não tem background em técnicas de modelagem de dados.

Afirma-se também que ORM tira do analista a pressão para rapidamente definir que um certo dado será um atributo de uma entidade ou um relacionamento, bem como a cardinalidade dos mesmos. Tal se dá porquê atributos e os relacionamentos de diferente cardinalidade são modelados através das mesmas abstrações.

Na figura abaixo, por exemplo, temos a representação gráfica ORM para do fato de que um empregado ocupa uma sala, uma sala é ocupada por vários empregados e um empregado pode ter uma data de término de contrato. Observe que os recursos gráficos são os mesmos.



Utilizando-se a notação IDEF1X para modelagem ER (nível lógico), o modelo acima poderia ser expresso como



Como se pode ver, ER é uma notação muito mais próxima do modelo físico de banco de dados que ORM.

Um mapeamento da notação básica ORM para o dialeto ER de Barker pode ser visto nas figuras abaixo.




O método de modelagem ORM prevê também um processo de geração do BD a partir de suas abstrações. Para tal, inclui otimizações e transformações que levam a uma "versão ER" do mesmo.

Uma crítica comum à ORM é que gera modelos enormes; por isto mesmo, difícies de entender e gerenciar. Para contrapor este argumento, ORM inclui em sua metodologia recursos para particionar e depois integrar diversos modelos ORM.

Alguns autores entendem ORM como uma boa ferramenta para a etapa inicial de modelagem. Então, quando certo conhecimento do modelo de negócio já foi apropriado gera-se um modelo ER e descarta-se o modelo ORM.

Quem quiser se aprofundar mais no assunto, pode começar por www.orm.net. Vai achar lá uma boa quantidade de material sobre o mesmo, incluindo os pdfs "Entity Relationship modeling from an ORM perspective: Part 3" e "Business Rules and Object Role Modeling", que serviram de suporte para este posting.

O modelo Empregado/Sala/Data de Contrato foi gerado com VisioModeler, uma ferramenta não mais suportada pela MS e que pode ser downloaded aqui.

O exemplo com notação IDEF1X foi elaborado com AllFusion Erwin Data Modeler, cuja versão trial pode ser downloaded aqui.

Se alguém tem experiência com ORM e quer compartilhar a mesma, como sempre, este espaço está aberto aos leitores.

O artigo "A Flexibilidade em modelo de dados ER " no databasedesign blog apresenta didaticamente uma técnica de modelagem de dados que pode ser aplicada

- quando o analista identifica que há uma razovável possibilidade de que certas regras de negócio mudem no futuro

- e quando o perfil desta mudança implicaria em transformação de uma relação 1:N em uma relação N:M entre entidades do modelo lógico.

Como comentários adicionais à útil técnica sugerida eu acrescentaria que a adoção da mesma deve ser avaliada ponderando-se os benefícios e os potenciais problemas que podem advir.

O benefício óbvio é que esta técnica minimiza significativamente o impacto da mudança da regra de negócio no modelo físico do banco de dados e pode tornar as aplicações virtualmente imunes à mesma. Porém, o quanto isto é importante depende de fatores que vão variar de caso para caso.

É necessário primeiro avaliar o impacto da possível mudança da regra de negócio no modelo de negócios mais amplo da empresa. Esta análise vai identificar, entre outras coisas, o custo de não-conformidade à nova regra de negócio bem como a agilidade com que suporte à nova regra deve ser implementado nas aplicações.

É importante envolver ou mesmo delegar esta análise à área de negócios da empresa.

Trabalhando no lado dos sistemas, o analista vai identificar o impacto da mudança nas aplicações. Tal análise vai revelar a quantidade de módulos e aplicações que se baseiam na regra de negócio vigente. Pode revelar que existe apenas um form e um report que consideram as tabelas e constraints físicos derivados da atual cardinalidade. Ou pode revelar que os módulos se contam às dezenas.

A partir deste levantamento, e considerando também o framework adotado pela área de IT para construir, manter e gerenciar suas aplicações - as ferramentas e técnicas de desenvolvimento, o processo de gerenciamento de mudanças e o processo de gerenciamento de configuração de software (SCM) - o analista vai estimar o custo e o tempo de manutenção das aplicações.

Estas análises se dão, é claro, porque construir na aplicação suporte a uma regra de negócio que pode virar realidade ou não no futuro geralmente não de dá sem custo. No caso do exemplo citado no artigo, é o custo de adicional complexidade no modelo de dados e na aplicações, bem como o potencial problema de performance das mesmas.

A complexidade adicional no modelo de dados se dá pela introdução de uma entidade (associativa) a mais. Nas aplicações, se reflete na necessidade de visitar 3 tabelas ao invés de 2 na hora de recuperar algumas informações (o nome do vendedor, por exemplo).

Em termos de performance, o novo modelo físico de bd implica agora em joins entre 3 tabelas na hora de se buscar (no mesmo exemplo) o nome do vendedor.

A potencial pior performance pode implicar em menor escalabilidade do módulo. A medida em que este problema realmente se materializa depende do banco de dados em questão. E a medida em que esta penalização em performance é significativa para a aplicação depende dos requisitos da mesma.

Se isto afeta, por exemplo, um módulo que é acessado 500 mil vêzes por dia então o analista vai desejar devotar um bom tempo tentando identificar o real impacto em performance.

Finalizadas estas análises e tomada a decisão de criar um modelo lógico de bd que mais facilmente aceita uma potencial mudança da regra de negócio, existirão ainda decisões a serem tomadas em nível de projeto físico e estas dependerão uma vez mais dos recursos existentes em cada bd e dos requisitos da aplicação.

No estudo de caso discutido neste artigo, o projetista de bd pode ser informado, por exemplo, que a probabilidade de haver uma mudança de nome de um vendedor é muitas vêzes menor que o número de vezes que a aplicação necessita acessar esta informação a partir da entidade CLIENTE. Neste caso, então, o projetista do bd pode tomar a decisão de implementar técnicas de replicação controlada de dados: no caso de um banco de dados Oracle, isto poderia ser implementado pelas seguintes estratégias

- criar um campo NOME_VENDEDOR na tabela ATENDIMENTO
- criar um database trigger na tabela ATENDIMENTO que busca na tabela VENDEDOR o nome do mesmo em cada operação de criação de um novo registro de atendimento
- criar um database trigger na tabela VENDEDOR que a cada atualização do nome do vendedor irá localizar e atualizar o nome do mesmo na tabela ATENDIMENTO.

Com Oracle, esta não é a única opção. O projetista poderia também considerar a opção de criar clustered tables, de forma que os dados (ou índices) das três tabelas
sejam físicamente armazenados juntos. Algumas desta opções, porém, não são totalmente transparentes à aplicação e podem ter impacto na mesma. Cabe uma análise caso a caso.

Enfim, este é um mundo de opções.

O resultado não inclui o registro criado pela Sessão B.

Isto acontece porquê por default Oracle usa consistência em nível de statement, o que assegura que data visível para um statement (select, neste caso) não muda durante a “vida” deste statement. Este comportamento (ou isolation level, como é mais formalmente conhecido) pode ser explicitamente definido na sessão corrente através do uso do comando SET TRANSACTION ISOLATION LEVEL READ COMMITED.

Consistência pode ser assegurada também em nível de transação. Neste caso, Oracle garante que qualquer comando da transação corrente vai enxergar o banco de dados como ele existia no início da transação. Neste caso, a aplicação deve definir o isolation level com o comando SET TRANSACTION ISOLATION LEVEL SERIALIZABLE.

Consistência em nível de transação também pode ser usado em situações em que apesar de não haver comandos DML (insert, delete, update) há uma sequência de statements read-only que devem enxergar o banco de dados como ele estava no início desta sequência de selects. Oracle chama isto de read-only transactions (mas acho esta nomenclatura particularmente amarga de engolir).

Nestes casos, pode-se usar o comando SET TRANSACTION READ ONLY. Apesar de não haver DML nesta sequência de operações é necessário o uso de um COMMIT ou ROLLBACK ao final da mesma.

Na sequência abaixo, o uso deste isolation level assegura que os dados retornados por ambos selects sejam coerentes entre si em um dado momento no tempo (inÍcio da transação). Em outras, palavras: evita que transações do tipo TT1 sejam também recuperadas pelo segundo select, o que provavelmente é o que o desenvolvedor tinha em mente.



O entendimento dos diferentes níveis de isolamento e dos mecanismos de gerenciamento de transação e concorrência são fundamentais para a construção de aplicações 100% confiáveis. Enganos nesta área podem levar a aplicações que funcionam “quase sempre” mas que são extremamente difíceis de depurar na hora em que resultados incoerentes são detectados.

A table abaixo mostra duas transações concorrentes rodando em um db Oracle. Quando o tempo chega no ponto 16, o resultado retornado pelo select na sessão A inclui o registro criado (e commited) pela sessão B?

Através do www.databasedesign.blogger.com.br acabei chegando em um recente artigo da Computerworld sobre o Programa de Exportação de Software do Brasil.

O artigo é muito bom e vale uma olhada. O pano de fundo do artigo é que a atual onda de offshore outsourcing nos Estados Unidos e Europa oferece oportunidades de mercado para o talento brasileiro. Acredito piamente nisto, e aqui vão algumas outras observações sobre o assunto:

1. É muito difícil enxergar o que realmente está acontecendo e a magnitude dos fatos porque a maioria dos envolvidos nesta discussão sobre offshore outsourcing também tem um interesse comercial no mesmo; o Gartner Group, por exemplo, que está na vanguarda dos grupos que apregoam os benefícios desta prática é dito também estar se beneficiando do mesmo.

2. Tecnicamente falando, o Brasil tem massa crítica de sobra para entrar nesta luta mas capacitação técnica é um fator menor nesta batalha, porquê a verdadeira luta é cultural. Até onde pode ver o indivíduo médio na Norte América, o Brasil ainda é Rio de Janeiro cheio de bunda pelada na praia, mulher pelada no Carnaval, sexo livre, um povo folgazão mas praticamente inútil em termos de capacidade empresarial, completa ausência de ousadia, falta de compromisso com protocolos, ninguém falando inglês, etc, etc.

3. A grande vantagem da Índia vem da grande exposição que este povo teve à cultura e língua britânica. O pessoal da Norte América pode não gostar do sotaque deles mas eles sabem o que o cara no outro lado da linha está pensando e como ele reage. Sabe como se apresentar e o que precisa dizer.

4. Além disto, a India exporta gente pra diabo. Aqui do lado de Vancouver tem uma cidade que eu já ouvi falar que seria a cidade com o maior número de indianos fora da India. Sao 300 mil ou mais. O resultado é que ambas as culturas vão estreitando laços, se conhecendo e acabam por estabelecer vínculos comerciais, também.

5. Se a gente compara isto aos estimados (e minguados) 2000 brasileiros que vivem na mesma região, dá para entender porquê certos países vão ser lembrados mais que outros na hora de fechar contrato com os Estados Unidos.

6. Pessoalmente, os indianos se expõe mais, também. Por exemplo: as listas técnicas que eu assino na web, frequentemente são compostas por norte-americanos, indianos e os outros. As vêzes tem até um argentino.

7. Este tipo de terceirização além-mar está acontecendo em diversas áreas. Há pouco tempo li em um jornal de Vancouver sobre uma firma de radiologia que estava contratando serviços de análise radiológica na ... India. O camarada na norte américa tira uma foto da cabeça do cidadão, digitaliza, manda pela web para a Índia e daqui há pouco recebe o diagnóstico por email. Por que esta imagem não está vindo para o Brasil?

8. O artigo fala em bravos brasileiros desprezando o conceito de fábrica de software e apostando em especificações. Buenas, mais uma vez: tem que ter muito inglês e exposição cultural para gerar especificação que possa ser assinada pelo contratante norte-americano ou europeu. Não é por acaso que até mesmo para o pessoal na Índia é difícil apostar nesta estratégia.

9. O que o artigo não fala é que a China vem aí. São mais de 400 mil engenheiros de software graduados por ano, que vão inundar o mercado como uma praga de gafanhotos e trabalhar por comida. Exageros aparte, a pressão por redução de custos tende a ser ainda maior no futuro e a pseudo vantagem de salário/hora do Brasil pode virar poeira.

10. Isto tudo tem jeito. Contratos não são fechados apenas com base em preço. Diversos fatores objetivos e subjetivos correm em paralelo. Temos produtos bons aqui, mas tem na Índia e na China também. Tem é que saber embalar este produto, expor ele, falar sobre ele. Tem que botar o bloco na rua. O artigo apresenta vários indicativos de que isto começa a ocorrer, mas a estrada ainda e longa. O governo pode ajudar, mas não pode ciceronear.

---

A eweek tem uma excelente reportagem especial sobre o assunto. Bem balanceada, e cobrindo diversos aspectos desta batata quente.

Metric Madness

Certa feita, um gerente da área de desenvolvimento de uma determinada empresa converteu-se subitamente à necessidade de implementar mecanismos de métrica de produtividade em seu grupo de desenvolvimento de sistemas.

Estruturou, então, um processo que definia produtividade do desenvolvedor com base na quantidade de linhas de código produzido. Foi mais adiante: associou o recebimento de bônus e outras gratificações à produtividade dos desenvolvedores.

Para implementar seu plano o gerente mediu por algumas semanas a produtividade individual de cada desenvolvedor e obteve uma média coletiva. Depois, passou a monitorar a produtividade com base no quanto o número de linhas de código produzidas em uma semana (por cada desenvolvedor) era próximo da média.

Imediatamente, um desenvolvedor famoso por seu estilo “copiar-e-colar” passou a figurar entre os mais produtivos. Em outra semana, um desenvolvedor que havia conseguido consolidar uma série de código duplicado em um número muito menor de linhas foi chamado ao escritório do gerente para explicar o porque de tão baixa produtividade.

Temendo perder os bônus e gratificações, o grupo de desnvolvedores tomou uma atitude: passou a usar ponto-e-vírgula duas vêzes no final de cada linha de código, pois era sabido que a ferramenta de medição de produtividade baseava-se neste character para contar as linhas de programa.

Logo, os desenvolvedores estavam incluindo ponto-e-vírgula nos comentários de bloco, como em
/*;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Your comment goes here
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;*/

O gerente estava extasiado e o incremento de produtividade de seu grupo estava virando lenda na empresa.

Buenas, mais tarde, uma auditoria de código descobriu as artimanhas e o esquema todo - junto com a moral do gerente - foi água abaixo.

Que lições tirar deste episódio?

A narração em inglês desta estória, com mais detalhes, pode ser lida na Software Development Magazine, contada por Steve Adolph, Senior Technical Consultant da WSA Consulting Inc., uma empresa aqui de British Columbia, Canadá.

Ler todas as Lendas Corporativas

The Standish Group e diversas outras fontes consistentemente indicam o envolvimento do usuario como um dos três mais importantes fatores que contribuem para o sucesso de um projeto de desenvolvimento de software.

O fato de que isto necessite ser dito pode parecer espantoso para os ainda não iniciados na fascinante vida corporativa. Mas a experiência tem demonstrado que as coisas não funcionam bem assim: desenvolvedores são notórios por tomar tempo da implementação das core features do produto para introduzir “interessantes” e não requeridos recursos; a área de marketing frequentemente trabalha com a filosofia “quanto mais melhor”, onde todas as features têm prioridade 100%.

ler mais...

Lendas, estórias, mitos, contos e causos do IT corporativo

Sobre colchas-de-retalhos e trapos

Na empresa Surreal Inc. uma aplicacação havia sido posta em produção há pouco tempo.

Os clientes desta aplicação eram escritórios da empresa espalhados pelo mundo todo.

Um sistema de help-desk foi montado para atender os usuários. Do feedback proporcionado pelo help-desk apareciam diversas boas sugestões sobre mudanças na aplicação.

No entanto, por questões pessoais, o gerente do projeto não estava interessado no mesmo. Ao mesmo tempo, não foi montado um processo formal para acolher, avaliar e implementar (ou não) estas sugestões. O resultado é que decisões estratégicas sobre o feature set da aplicacação e o planejamento do projeto eram definidos pelo desenvolvedor, com base em seus critérios pessoais.

Por fim. quando uma decisão contrariava específicos interesses, o gerente de projeto era pressionado, intervinha no plano do projeto e nas decisões. E ia embora.

Resultado: usuários insatisfeitos, moral do grupo abalada, uma aplicação virando colcha de retalhos e um desenvolvedor estressado e se sentindo um trapo.

Alguém acredita que algo assim é possível?

Todas as Lendas Corporativas