O autor inicia a crônica afirmando que, apesar dos 50 anos de progresso no desenvolvimento de Software (isto em 1994) a indústria do software estava a décadas de alcançar a maturidade de outras áreas da engenharia, sendo que era preciso mudar rapidamente aquele cenário para suprir as demandas da nova sociedade da era da informação.
Ele cita o exemplo do Aeroporto de Denver, uma obra prima da engenharia (civil) moderna, que simplesmente não pode entrar em funcionamento na data prevista e teve atrasos de vários meses por culpa dos problemas em um software de 193 milhões de dólares, o qual deveria fazer o controle automático das bagagens, chegando no auge da crise a gerar um prejuízo de 1,1 milhão de dólares/dia em juros e custos operacionais.
Naquela época, estudos mostravam que para cada seis grandes sistemas que eram colocados em operação dois outros eram cancelados. Em média, metade dos projetos de desenvolvimento de software estouravam seu cronograma, e, para os considerados grandes projetos, esta média era ainda pior.
Três quartos de todos os grandes sistemas apresentavam falhas de operação, seja por não funcionarem como o inicialmente previsto ou porque sequer eram usados.
O autor mostrou que já na década de 60 (1968) um comitê de 50 especialistas nas diversas áreas de TI, definiu que o desenvolvimento de software deveria seguir uma sistemática disciplinada e quantificável para o seu desenvolvimento, operação e manutenção. Esta sistemática foi cunhada de Engenharia de Software. Porém, em 1994, 25 anos depois, nada havia mudado e o desenvolvimento de software ainda era artesanal.
Em 1994 os cientistas da computação sabiam que haveriam mudanças profundas no uso de computadores pela sociedade, e, para que o software pudesse responder a estas mudanças, seriam necessárias também mudanças profundas. Porém, o que se via era um processo meio sem rumo, como dunas que se movem ao sabor dos ventos e sem direção definida.
As fundações da programação tradicional estavam ruindo enquanto o hardware se desenvolvia cada vez mais rapidamente.
Não se podia mais aceitar software sem qualidade. A afirmação amplamente aceita na época de que todo software terá algum tipo de falha precisava mudar. Imagina a gente aceitar uma afirmação de todo prédio um dia vai ruir, é inimaginável.
A quantidade de código em produtos de consumo de massa como aparelhos eletrônicos, carros, eletrodomésticos, entre outros estva se duplicando a cada dois anos e não se poderiam aceitar falhas.
Por outro lado não era muito fácil desenvolver sistemas sem erros pois esta era e ainda é uma atividade complexa. O autor cita o exemplo de um software de controle do satélite Clementine desenvolvido pelo Departamento de Defesa Americano – DOD. O DOD aplica testes rigorosos e caros para garantir a qualidade e a confiabilidade dos software embarcados, mas, mesmo assim um “bug” no programa fez com que o satélite não conseguisse se fixar na órbita lunar planejada.
O motivo sempre citado era a dificuldade de simulação de todos os cenários operacionais possíveis e isto valia para qualquer aplicação, seja científica ou comercial.
Por outro lado, as novas demandas, principalmente no mundo dos negócios, que exigiam sistemas cada vez mais complexos e versáteis, passaram a ser um desafio ainda maior para os desenvolvedores.
Infelizmente existem relatados mais casos de insucesso que o contrário. Em junho de 1994 a IBM fez uma pesquisa em 24 grandes companhias, líderes nos seus setores, que tinham desenvolvido grandes sistemas distribuídos. O resultado, desanimador, mostrou que 55% dos projetos custaram mais do que o esperado, 68% estouraram o cronograma e 88% tiveram que ser substancialmente redesenhados. Os resultados poderiam ser ainda mais desanimadores se eles estivessem incluído questões sobre a confiabilidade dos sistemas que forma implantados.
A conclusão na época era clara: “É necessário mudar a forma como os programadores trabalham”. As demandas estão cada vez mais complexas, sistemas com mais de 1 milhão de linhas de código, distribuídos sobre centenas de modernas e sofisticadas plataformas de hardware com eventos em tempo real. Num sistema deste porte, para o controle do tráfego aéreo por exemplo, um pequeno erro poderia se tornar uma ameaça à segurança pública.
Por outro lado, os custos para o desenvolvimento de software estavam aumentando de forma estratosférica, beirando o nível proibitivo. Todos estes problemas levaram a conclusão de que era necessária uma mudança de rumo radical ma maneira como o software era desenvolvido, de forma a ficar comptível com as demais áreas da engenharia, ou seja, buscar uma metodologia que permitisse entender como medir consistentemente e qualitativamente o processo de desenvolvimento de software bem como a densidade de erros e a produtividade dos programadores.
Uma das primeiras tentativas na busca da melhoria dos processos de desenvolvimento de software foi a introdução do modelo CMM – “Capability Maturity Model”, o qual buscava excelência e qualidade no processo de desenvolvimento de software.
O modelo é composto de 5 níveis de maturidade, sendo o primeiro deles caracterizado pela ausência de uma metodologia padrão de desenvolvimento e o maior (nível 5) considerado como processo de excelência e melhoria contínua. Pesquisas na época indicaram que aproximadamente 75% das empresas estavam no nível 1, uma clara demosntração do “porquê” da baixa qualidade do software.
É um modelo que no quarto e no quinto nível se preocupa com a avaliação quantitativa do software, ou seja, o uso de métricas para avaliar onde o processo pode ser melhorado.
Por outro lado, mesmo projetos muito bem conduzidos podem levar a erros. A arte de programar também implica em retirar erros dos programas, e, quanto mais cedo estes “bugs” forem tratados, menores as chances de causarem ameaças. Os “bugs” devastadores são aqueles detectados na fase final ou fase de entrega.
Algumas empresas, como a Microsoft, lançavamm versões beta dos seus softwares, distribuindo para milhares de voluntários que os testavamm. Mas isto era e ainda é caro e complicado para a grande maioria dos aplicativos de software.
Pesquisadores formulavam estratégias para descobrir e atacar “bugs” logo no início do projeto evitando assim que se propagassem. Uma maneira prática de fazer isto era através da prototipação, a qual permite aos usuários ou clientes do sistema validarem os processos antes ainda da codificação. Por outro lado, protótipos são somente modelos e a maioria dos “bugs” só é detectada após o processo de codificação.
Outra saída estva surgindo do domínio da matemática, através do conjunto de ferramentas providos pela teoria da matemática e do cálculo de predicados. Eles traduziam especificações e programas para métodos formais que ajudavam a provar a corretude dos algoritmos usados.
Embora estes métodos formais consigam provar que um algoritmo está correto os testes funcionais ainda são necessários pois podem ocorrer erros na modelagem dos métodos formais além do que, estes métodos somente podem garantir que um software está de acordo com a especificação mas ele não pode prever as surpresas que o ambiente operacional pode trazer.
Uma abordagem de sucesso conhecida como “sala limpa” estava sendo analisada. O objetivo era usar técnicas rigorosas de engenharia de software de maneira a garantir que o produto sairia perfeito já na primeira tentativa. O sistema é decomposto em partes menores e estes módulos são testados forma exaustiva antes de integrá-los aos demais. Nenhuma sujeira fica debaixo do tapete.
Isto implica em mudar a cultura em relação a testes. Em vez de ficar testando os módulos da maneira como o programador acha que eles serão usados, deverá ser definido e criado um conjunto de casos de testes muito bem planejados. Estes casos de testes não seriam restritos a funcionalidade do módulo em si, mas se preocupam também com a integração e a dependência entre eles. É um processo que testa, “retesta” e testa novamente. Depois de cada fase de testes existe uma fase de análise e validação dos resultados.
Mas não existe uma solução mágica, ou “bala de prata” na metáfora do autor. Desde a década de 60 tinham surgido dúzias de novas tecnologias desenvolvidas com a intenção de aumentar a produtividade dos programadores. Entre elas se destacavam a programação estruturada, ferramentas CASE, orientação a objetos entre outros.
Mesmo assim alguns cientistas e pesquisadores ainda não enxergavam melhorias na produtividade. Outros, como o professor Richard A De Millo da Universidade de Purdue, tinham uma visão diferente, afirmando que as mudanças estavam acontecendo, mas não existia uma definição clara do que seria este aumento de produtividade e quais métricas deveriam ser usadas.
Em relação a gerar código, a produção em 1994 era no mínimo o dobro da apresentada na década de 70. Por outro lado, menos de 10% das companhias americanas mediam a produtividade dos seus programadores.
Mesmo as que mediam não usavam um padrão útil de medida. A mais usada era o número de linhas de código por programador/mês. O problema é que existiam várias linguagens diferentes e não era possível ou viável comparar a produtividade de dois programadores em termos de linhas de código se um codificava em “C” e o outro em ADA, por exemplo.
O fato era que, naquela época, apesar de se falar muito em engenharia de software, esta estava muito aquém das demais tradicionais e maduras áreas da engenharia. Não existia um “handbook” de engenharia de software padronizado e único, os erros de projetos eram repetidos um após outro.
Os pesquisadores e cientistas pregavam a necessidade do Governo tomar a frente do processo de pesquisa e criação de metodologias padrão pois isto envolvia altos investimentos. Havia também a necessidade de criar grandes laboratórios de experimentação para que os pesquisadores e estudantes das Universidades pudessem testar em bancada estas novas propostas.
A idéia, já naquela época, era criar as linhas de produção de software, desenvolvendo componentes intercambiáveis, independentes de plataforma de hardware ou sistema operacional. Os programadores vinham por décadas tentando criar bibliotecas de componentes desenvolvidos. O problema era que estes ficavam rapidamente obsoletos em relação à rápida evolução do hardware e dos sistemas operacionais. Os investimentos na época eram direcionados no sentido de implementar o processo de componentização de software e estes componentes deveriam ser facilmente intercambiáveis para se adequar às mudanças de plataformas e ambientes de negócio.
Até o início dos anos 90 as empresas americanas, como a Microsoft, dominavam a produção de código. Sozinha, a Microsoft produzia durante um ano mais código de computador do que um conjunto de 100 nações juntas.
As mudanças começaram a acontecer quando vários países, principalmente no lado oriental do globo, como a Índia por exemplo, com o apoio de seus governos entraram firmes na produção de software, tirando a hegemonia dos Estados Unidos.
Muitas grandes companhias abriram subsidiárias na Índia com o objetivo de produzir software a um custo menor. O salário dos programadores indianos chegava a ser 8 vezes menor do que nos EUA e isto não implicava em menor qualidade pois a mão-de-obra indiana era altamente capacitada.
Outra grande vantagem eram os fuso horários pois os trabalhadores indianos poderiam corrigir software enquanto os americanos dormiam. No dia seguinte tudo estava funcionando.
Por fim, o autor esperava que uma combinação entre boas práticas em processos de negócios e ferramentas avançadas de tecnologia e componentização poderiam reverter a situação corrente na época em relação aos softwares ruins, ou seja, resolver a famosa crise do software, pois, se nada fosse feito, o desenvolvimento de software iria dificultar o crescimento da indústria e demais áreas de negócios.
Comentários:
Passados 13 anos desde a publicação do artigo, pode-se dizer que ocorreram melhorias nos processos e nas tecnologias de desenvolvimento de software, inclusive com a consolidação de algumas tecnologias que eram avaliadas na época. Porém, as queixas em relação à baixa produtividade e também sobre projetos que falham, continuam altas.
O Standish Group publicou em 2006 os resultados de uma pesquisa que mostrou que somente 35% dos projetos de desenvolvimento de software que foram iniciados tiveram sucesso, ou seja dois terços de falhas. Números muito parecidos com 1994. Este número muito alto levou Grady Brook, um dos pais da UML, a declarar que “uma doença que dure tanto tempo quanto esta, francamente, deveria ser considerada uma normalidade”.
A Engenharia de Software evoluiu, novas técnicas e processos, comprovados em laboratórios, melhoraram consideravelmente o processo de desenvolvimento de software. Pode-se afirmar que software hoje é desenvolvido ou projetado por engenharia, não mais manufaturado no sentido clássico.
Orientação a Objeto, Inteligência Artificial, Redes Neurais, Computação Paralela, Ferramentas CASE, UML, entre outras, que em 1994 ainda eram promessas, hoje são largamente usadas na prática.
Outro conceito que ainda era pouquíssimo desenvolvido na época e hoje é largamente usado são as Fábricas de Software. A produção de software segue o conceito de linha de produção, com reutilização, componentização entre outros, o que faz diminuir consideravelmente o “lead time” de desenvolvimento de software.
Por outro lado a complexidade dos problemas também cresceu. A Internet e o Comércio Eletrônico, nem citados no artigo, explodiram. Hoje os negócios exigem sistemas distribuídos em larga escala, conectados de forma colaborativa, rodando em plataformas distintas, desenvolvidos com tecnologias distintas, trocando informações em tempo real para mover os negócios e porque não dizer o mundo, tudo isto sobre a Internet, uma rede que conecta milhões de usuários ao redor do Globo e, apesar de versátil, é totalmente insegura. Não é errado dizer que quase nenhum negócio no mundo funciona sem o apoio dos sistemas de informação.
O que se observa hoje é que a baixa produtividade das pessoas que usam sistemas de informação ou mesmo sistemas de informação que não funcionam adequadamente e não dão os resultados esperados, são causados, na sua grande maioria, pela falta de alinhamento dos sistemas às estratégias de negócios das empresas bem como o mau uso das ferramentas disponíveis para o desenvolvimento de sistemas. A tecnologia não deve ser mais considerada a vilã.
Da mesma forma que os especialistas afirmam que o aumento da produtividade relacionada a implantação de sistemas de informação é mais o fruto na mudança e otimização dos processos do que a tecnologia por si só, pois esta produz um aumento marginal, podemos também afirmar que a baixa produtividade não é culpa da tecnologia ou dos sistemas, mas das mudanças inadequadas nos processos de negócio. Os manuais de engenharia estão aí, o problema é que não são corretamente usados pelos desenvolvedores.
Outro problema está relacionado aos famosos e difundidos “softwares de prateleira” para gestão de negócios, os quais são usados pela maioria das empresas.
Eles são bem desenvolvidos, seguem os conceitos da moderna engenharia de software, mas eles acabam engessando os negócios ou mesmo modificando a maneira como as pessoas trabalham. As empresas são obrigadas a se adequarem aos modelos de negócios implementados nestes sistemas, desfigurando seu modelo de atuação e eliminando diferenciais competitivos.
Em muitos casos ocorre a falta de comprometimento dos executivos de negócios com a definição e implantação destes sistemas, fato este que contribui para a implantação de sistemas pouco adequados ao negócio o que acaba causando um impacto negativo na produtividade.
Mas, mesmo em relação aos problemas de falta de gestão estratégica da TI, as mudanças estão ocorrendo. Os modelos de govenança de TI que prometem colocar ordem em todo o processo de definição, modelagem, implantação e operação de sistemas de informação, estão sendo adotados em larga escala pelas empresas, seja por necessidade, seja por força da lei (exemplo da lei SOX).
As empresas estão aprendendo que, seja através de equipes internas de TI, seja através de processos de terceirização, é importante investir em profissionais capacitados a usar estas novas tecnologias na sua plenitude. A informação é hoje um dos principais ativos das empresas e os sistemas que manipulam estas informações não podem ficar sob a responsabilidade de amadores.
A união da governança de TI e das modernas ferramentas de modelagem e desenvolvimento de sistemas com pessoas especializadas e comprometidas com os negócios da empresa, prometem sepultar de vez a famosa crise do software.
Ele cita o exemplo do Aeroporto de Denver, uma obra prima da engenharia (civil) moderna, que simplesmente não pode entrar em funcionamento na data prevista e teve atrasos de vários meses por culpa dos problemas em um software de 193 milhões de dólares, o qual deveria fazer o controle automático das bagagens, chegando no auge da crise a gerar um prejuízo de 1,1 milhão de dólares/dia em juros e custos operacionais.
Naquela época, estudos mostravam que para cada seis grandes sistemas que eram colocados em operação dois outros eram cancelados. Em média, metade dos projetos de desenvolvimento de software estouravam seu cronograma, e, para os considerados grandes projetos, esta média era ainda pior.
Três quartos de todos os grandes sistemas apresentavam falhas de operação, seja por não funcionarem como o inicialmente previsto ou porque sequer eram usados.
O autor mostrou que já na década de 60 (1968) um comitê de 50 especialistas nas diversas áreas de TI, definiu que o desenvolvimento de software deveria seguir uma sistemática disciplinada e quantificável para o seu desenvolvimento, operação e manutenção. Esta sistemática foi cunhada de Engenharia de Software. Porém, em 1994, 25 anos depois, nada havia mudado e o desenvolvimento de software ainda era artesanal.
Em 1994 os cientistas da computação sabiam que haveriam mudanças profundas no uso de computadores pela sociedade, e, para que o software pudesse responder a estas mudanças, seriam necessárias também mudanças profundas. Porém, o que se via era um processo meio sem rumo, como dunas que se movem ao sabor dos ventos e sem direção definida.
As fundações da programação tradicional estavam ruindo enquanto o hardware se desenvolvia cada vez mais rapidamente.
Não se podia mais aceitar software sem qualidade. A afirmação amplamente aceita na época de que todo software terá algum tipo de falha precisava mudar. Imagina a gente aceitar uma afirmação de todo prédio um dia vai ruir, é inimaginável.
A quantidade de código em produtos de consumo de massa como aparelhos eletrônicos, carros, eletrodomésticos, entre outros estva se duplicando a cada dois anos e não se poderiam aceitar falhas.
Por outro lado não era muito fácil desenvolver sistemas sem erros pois esta era e ainda é uma atividade complexa. O autor cita o exemplo de um software de controle do satélite Clementine desenvolvido pelo Departamento de Defesa Americano – DOD. O DOD aplica testes rigorosos e caros para garantir a qualidade e a confiabilidade dos software embarcados, mas, mesmo assim um “bug” no programa fez com que o satélite não conseguisse se fixar na órbita lunar planejada.
O motivo sempre citado era a dificuldade de simulação de todos os cenários operacionais possíveis e isto valia para qualquer aplicação, seja científica ou comercial.
Por outro lado, as novas demandas, principalmente no mundo dos negócios, que exigiam sistemas cada vez mais complexos e versáteis, passaram a ser um desafio ainda maior para os desenvolvedores.
Infelizmente existem relatados mais casos de insucesso que o contrário. Em junho de 1994 a IBM fez uma pesquisa em 24 grandes companhias, líderes nos seus setores, que tinham desenvolvido grandes sistemas distribuídos. O resultado, desanimador, mostrou que 55% dos projetos custaram mais do que o esperado, 68% estouraram o cronograma e 88% tiveram que ser substancialmente redesenhados. Os resultados poderiam ser ainda mais desanimadores se eles estivessem incluído questões sobre a confiabilidade dos sistemas que forma implantados.
A conclusão na época era clara: “É necessário mudar a forma como os programadores trabalham”. As demandas estão cada vez mais complexas, sistemas com mais de 1 milhão de linhas de código, distribuídos sobre centenas de modernas e sofisticadas plataformas de hardware com eventos em tempo real. Num sistema deste porte, para o controle do tráfego aéreo por exemplo, um pequeno erro poderia se tornar uma ameaça à segurança pública.
Por outro lado, os custos para o desenvolvimento de software estavam aumentando de forma estratosférica, beirando o nível proibitivo. Todos estes problemas levaram a conclusão de que era necessária uma mudança de rumo radical ma maneira como o software era desenvolvido, de forma a ficar comptível com as demais áreas da engenharia, ou seja, buscar uma metodologia que permitisse entender como medir consistentemente e qualitativamente o processo de desenvolvimento de software bem como a densidade de erros e a produtividade dos programadores.
Uma das primeiras tentativas na busca da melhoria dos processos de desenvolvimento de software foi a introdução do modelo CMM – “Capability Maturity Model”, o qual buscava excelência e qualidade no processo de desenvolvimento de software.
O modelo é composto de 5 níveis de maturidade, sendo o primeiro deles caracterizado pela ausência de uma metodologia padrão de desenvolvimento e o maior (nível 5) considerado como processo de excelência e melhoria contínua. Pesquisas na época indicaram que aproximadamente 75% das empresas estavam no nível 1, uma clara demosntração do “porquê” da baixa qualidade do software.
É um modelo que no quarto e no quinto nível se preocupa com a avaliação quantitativa do software, ou seja, o uso de métricas para avaliar onde o processo pode ser melhorado.
Por outro lado, mesmo projetos muito bem conduzidos podem levar a erros. A arte de programar também implica em retirar erros dos programas, e, quanto mais cedo estes “bugs” forem tratados, menores as chances de causarem ameaças. Os “bugs” devastadores são aqueles detectados na fase final ou fase de entrega.
Algumas empresas, como a Microsoft, lançavamm versões beta dos seus softwares, distribuindo para milhares de voluntários que os testavamm. Mas isto era e ainda é caro e complicado para a grande maioria dos aplicativos de software.
Pesquisadores formulavam estratégias para descobrir e atacar “bugs” logo no início do projeto evitando assim que se propagassem. Uma maneira prática de fazer isto era através da prototipação, a qual permite aos usuários ou clientes do sistema validarem os processos antes ainda da codificação. Por outro lado, protótipos são somente modelos e a maioria dos “bugs” só é detectada após o processo de codificação.
Outra saída estva surgindo do domínio da matemática, através do conjunto de ferramentas providos pela teoria da matemática e do cálculo de predicados. Eles traduziam especificações e programas para métodos formais que ajudavam a provar a corretude dos algoritmos usados.
Embora estes métodos formais consigam provar que um algoritmo está correto os testes funcionais ainda são necessários pois podem ocorrer erros na modelagem dos métodos formais além do que, estes métodos somente podem garantir que um software está de acordo com a especificação mas ele não pode prever as surpresas que o ambiente operacional pode trazer.
Uma abordagem de sucesso conhecida como “sala limpa” estava sendo analisada. O objetivo era usar técnicas rigorosas de engenharia de software de maneira a garantir que o produto sairia perfeito já na primeira tentativa. O sistema é decomposto em partes menores e estes módulos são testados forma exaustiva antes de integrá-los aos demais. Nenhuma sujeira fica debaixo do tapete.
Isto implica em mudar a cultura em relação a testes. Em vez de ficar testando os módulos da maneira como o programador acha que eles serão usados, deverá ser definido e criado um conjunto de casos de testes muito bem planejados. Estes casos de testes não seriam restritos a funcionalidade do módulo em si, mas se preocupam também com a integração e a dependência entre eles. É um processo que testa, “retesta” e testa novamente. Depois de cada fase de testes existe uma fase de análise e validação dos resultados.
Mas não existe uma solução mágica, ou “bala de prata” na metáfora do autor. Desde a década de 60 tinham surgido dúzias de novas tecnologias desenvolvidas com a intenção de aumentar a produtividade dos programadores. Entre elas se destacavam a programação estruturada, ferramentas CASE, orientação a objetos entre outros.
Mesmo assim alguns cientistas e pesquisadores ainda não enxergavam melhorias na produtividade. Outros, como o professor Richard A De Millo da Universidade de Purdue, tinham uma visão diferente, afirmando que as mudanças estavam acontecendo, mas não existia uma definição clara do que seria este aumento de produtividade e quais métricas deveriam ser usadas.
Em relação a gerar código, a produção em 1994 era no mínimo o dobro da apresentada na década de 70. Por outro lado, menos de 10% das companhias americanas mediam a produtividade dos seus programadores.
Mesmo as que mediam não usavam um padrão útil de medida. A mais usada era o número de linhas de código por programador/mês. O problema é que existiam várias linguagens diferentes e não era possível ou viável comparar a produtividade de dois programadores em termos de linhas de código se um codificava em “C” e o outro em ADA, por exemplo.
O fato era que, naquela época, apesar de se falar muito em engenharia de software, esta estava muito aquém das demais tradicionais e maduras áreas da engenharia. Não existia um “handbook” de engenharia de software padronizado e único, os erros de projetos eram repetidos um após outro.
Os pesquisadores e cientistas pregavam a necessidade do Governo tomar a frente do processo de pesquisa e criação de metodologias padrão pois isto envolvia altos investimentos. Havia também a necessidade de criar grandes laboratórios de experimentação para que os pesquisadores e estudantes das Universidades pudessem testar em bancada estas novas propostas.
A idéia, já naquela época, era criar as linhas de produção de software, desenvolvendo componentes intercambiáveis, independentes de plataforma de hardware ou sistema operacional. Os programadores vinham por décadas tentando criar bibliotecas de componentes desenvolvidos. O problema era que estes ficavam rapidamente obsoletos em relação à rápida evolução do hardware e dos sistemas operacionais. Os investimentos na época eram direcionados no sentido de implementar o processo de componentização de software e estes componentes deveriam ser facilmente intercambiáveis para se adequar às mudanças de plataformas e ambientes de negócio.
Até o início dos anos 90 as empresas americanas, como a Microsoft, dominavam a produção de código. Sozinha, a Microsoft produzia durante um ano mais código de computador do que um conjunto de 100 nações juntas.
As mudanças começaram a acontecer quando vários países, principalmente no lado oriental do globo, como a Índia por exemplo, com o apoio de seus governos entraram firmes na produção de software, tirando a hegemonia dos Estados Unidos.
Muitas grandes companhias abriram subsidiárias na Índia com o objetivo de produzir software a um custo menor. O salário dos programadores indianos chegava a ser 8 vezes menor do que nos EUA e isto não implicava em menor qualidade pois a mão-de-obra indiana era altamente capacitada.
Outra grande vantagem eram os fuso horários pois os trabalhadores indianos poderiam corrigir software enquanto os americanos dormiam. No dia seguinte tudo estava funcionando.
Por fim, o autor esperava que uma combinação entre boas práticas em processos de negócios e ferramentas avançadas de tecnologia e componentização poderiam reverter a situação corrente na época em relação aos softwares ruins, ou seja, resolver a famosa crise do software, pois, se nada fosse feito, o desenvolvimento de software iria dificultar o crescimento da indústria e demais áreas de negócios.
Comentários:
Passados 13 anos desde a publicação do artigo, pode-se dizer que ocorreram melhorias nos processos e nas tecnologias de desenvolvimento de software, inclusive com a consolidação de algumas tecnologias que eram avaliadas na época. Porém, as queixas em relação à baixa produtividade e também sobre projetos que falham, continuam altas.
O Standish Group publicou em 2006 os resultados de uma pesquisa que mostrou que somente 35% dos projetos de desenvolvimento de software que foram iniciados tiveram sucesso, ou seja dois terços de falhas. Números muito parecidos com 1994. Este número muito alto levou Grady Brook, um dos pais da UML, a declarar que “uma doença que dure tanto tempo quanto esta, francamente, deveria ser considerada uma normalidade”.
A Engenharia de Software evoluiu, novas técnicas e processos, comprovados em laboratórios, melhoraram consideravelmente o processo de desenvolvimento de software. Pode-se afirmar que software hoje é desenvolvido ou projetado por engenharia, não mais manufaturado no sentido clássico.
Orientação a Objeto, Inteligência Artificial, Redes Neurais, Computação Paralela, Ferramentas CASE, UML, entre outras, que em 1994 ainda eram promessas, hoje são largamente usadas na prática.
Outro conceito que ainda era pouquíssimo desenvolvido na época e hoje é largamente usado são as Fábricas de Software. A produção de software segue o conceito de linha de produção, com reutilização, componentização entre outros, o que faz diminuir consideravelmente o “lead time” de desenvolvimento de software.
Por outro lado a complexidade dos problemas também cresceu. A Internet e o Comércio Eletrônico, nem citados no artigo, explodiram. Hoje os negócios exigem sistemas distribuídos em larga escala, conectados de forma colaborativa, rodando em plataformas distintas, desenvolvidos com tecnologias distintas, trocando informações em tempo real para mover os negócios e porque não dizer o mundo, tudo isto sobre a Internet, uma rede que conecta milhões de usuários ao redor do Globo e, apesar de versátil, é totalmente insegura. Não é errado dizer que quase nenhum negócio no mundo funciona sem o apoio dos sistemas de informação.
O que se observa hoje é que a baixa produtividade das pessoas que usam sistemas de informação ou mesmo sistemas de informação que não funcionam adequadamente e não dão os resultados esperados, são causados, na sua grande maioria, pela falta de alinhamento dos sistemas às estratégias de negócios das empresas bem como o mau uso das ferramentas disponíveis para o desenvolvimento de sistemas. A tecnologia não deve ser mais considerada a vilã.
Da mesma forma que os especialistas afirmam que o aumento da produtividade relacionada a implantação de sistemas de informação é mais o fruto na mudança e otimização dos processos do que a tecnologia por si só, pois esta produz um aumento marginal, podemos também afirmar que a baixa produtividade não é culpa da tecnologia ou dos sistemas, mas das mudanças inadequadas nos processos de negócio. Os manuais de engenharia estão aí, o problema é que não são corretamente usados pelos desenvolvedores.
Outro problema está relacionado aos famosos e difundidos “softwares de prateleira” para gestão de negócios, os quais são usados pela maioria das empresas.
Eles são bem desenvolvidos, seguem os conceitos da moderna engenharia de software, mas eles acabam engessando os negócios ou mesmo modificando a maneira como as pessoas trabalham. As empresas são obrigadas a se adequarem aos modelos de negócios implementados nestes sistemas, desfigurando seu modelo de atuação e eliminando diferenciais competitivos.
Em muitos casos ocorre a falta de comprometimento dos executivos de negócios com a definição e implantação destes sistemas, fato este que contribui para a implantação de sistemas pouco adequados ao negócio o que acaba causando um impacto negativo na produtividade.
Mas, mesmo em relação aos problemas de falta de gestão estratégica da TI, as mudanças estão ocorrendo. Os modelos de govenança de TI que prometem colocar ordem em todo o processo de definição, modelagem, implantação e operação de sistemas de informação, estão sendo adotados em larga escala pelas empresas, seja por necessidade, seja por força da lei (exemplo da lei SOX).
As empresas estão aprendendo que, seja através de equipes internas de TI, seja através de processos de terceirização, é importante investir em profissionais capacitados a usar estas novas tecnologias na sua plenitude. A informação é hoje um dos principais ativos das empresas e os sistemas que manipulam estas informações não podem ficar sob a responsabilidade de amadores.
A união da governança de TI e das modernas ferramentas de modelagem e desenvolvimento de sistemas com pessoas especializadas e comprometidas com os negócios da empresa, prometem sepultar de vez a famosa crise do software.
Elton Dietrich
Nenhum comentário:
Postar um comentário