O desenvolvimento de software não é algo trivial como muitos imaginam. Gerenciamento, métodos, técnicas, processos, testes, testes e mais testes e inúmeras ferramentas existentes, ajudam a aumentar a qualidade e a minimizar a quantidade de bugs, contudo, não existe uma solução perfeita, dada à complexidade do desenvolvimento de muitos sistemas. Em sistemas de missão crítica, uma falha (bug) pode provocar paralisações ou desastres com conseqüências terríveis. Diante de tamanha complexidade, ainda existe a pressão da administração e a interminável lista de pedidos de novos recursos e modificações.

Alan Joch, editor sênior da revista BYTE (em 1995), descreve a complexidade do desenvolvimento de software e casos célebres, como o do Irix da SGI, do software de controle de vôo do ônibus espacial e do Boeing 777, entre outros.

 “Um dos casos mais célebres de “recursite” ocorreu em 1993, quando a Silicon Graphics, Inc (SGI) lançou a versão 5.1 do Irix com mais de 500 bugs sérios. A administração tinha pressionado por um novo sistema operacional, uma nova interface com o usuário, melhores compiladores e ferramentas e novos recursos multimídia. Tudo na versão 5.1 deveria ser melhor. Nenhum sacrifício foi feito. Mas nove meses antes do lançamento, quando o moral estava baixo e a contagem de bugs alta, dois engenheiros seniores apontaram à impossibilidade da tarefa. A administração respondeu contratando dois empreiteiros que eram estranhos ao software e à organização da SGI."

“A tentativa desesperada de inovar fez com que os programadores reduzissem o caminho, com efeitos desastrosos sobre o número de bugs”, afirmou Tom Davis, o cientista chefe, em um memorando interno da companhia. Ele descreveu a luta e lamentou o código obeso do SO, a performance lerda e os requisitos de memória fora da realidade.”

"Para aumentar os problemas da SGI, o memorando vazou para a Internet. A resposta foi sintomática: um correio de fãs. Davis recebeu pilhas de mensagens de desenvolvedores igualmente pressionados e a comunidade do mundo de software tacitamente adotou o problema. Essa reação ajudou o pessoal de vendas dos concorrentes da SGI a lembrar que eles não estavam imunes a erros desse tipo."

Este artigo, originalmente publicado na revista BYTE em dezembro de 1995 , irá conduzi-lo ao mundo do desenvolvimento de software, monstrando-o como é difícil criar software confiável, principalmente os softwares de missão crítica. Você irá obter informações úteis que irão ajudá-lo no desenvolvimento de seu sofware, melhorando a qualidade do seu código.

Na sua próxima viagem de avião, tente não pensar nisso: o Flight Simulator que roda em seu notebook pode ser mais confiável que o software desenvolvido para evitar a colisão de aviões no ar. Isso porque o sistema de controle de tráfego aéreo da FAA (Federal Aviation Authority) ainda utiliza programas dos anos 70, rodando em um mainframe IBM 9020 com data da década anterior. Esse sistema contribuiu para quase uma dúzia de falhas em centros de controle de tráfego aéreo no ano passado, incluindo irritantes colapsos nos dias 23 e 24 de julho em Chicago, na “pista” aérea de Santa Mônica. Há mais de uma década a FAA tenta substituir esse antiquado sistema. Infelizmente, a alternativa, o Advanced Automation System, com suas mais de um milhão de linhas de código, está cheia de bugs. E seis anos atrasada. Cientistas de computação de duas importantes universidades estão tendo que passar um pente fino nele para ver se algum código pode ser aproveitado. Diante de um software muito pouco confiável para utilizar em situações de vida ou morte, a FAA está nas mãos do seu velho e capenga –mas bem compreendido – sistema de controle de tráfego aéreo

Infelizmente, esse não é o único exemplo de software não confiável. No verão de 1991, ocorreram colapsos telefônicos nos sistemas locais da Califórnia e ao logo da Costa Leste. Todos por culpa de um erro no software de sinalização. A DSC Communications havia introduzido um bug pouco antes, ao alterar três linhas de código num programa de sinalização composto por vários milhões de linhas. Após essa mudança mínima, ninguém achou que fosse necessário testar novamente o programa. Um prisioneiro de New Jersey escapou da prisão domiciliar monitorada por computador, em 1992. Ele simplesmente removeu os rebites que seguravam seu bracelete eletrônico e saiu para cometer um assassinato. O computador detectou o golpe. Contudo, ao chamar um segundo computador para relatar o incidente, o primeiro recebeu sinal de ocupado e não voltou a ligar.

Já faz muito tempo que se sabe que o desenvolvimento de software é muito complexo para dispensar um controle de qualidade adequado. Livros, conferências e métodos formais prescrevem formas de lidar com a produção de software. Planeje, sue em cima da especificação do projeto. Isole funções críticas. Documente o processo de desenvolvimento. Comente código. Teste extensivamente tanto os componentes individuais quanto as interligações do sistema como um todo. Valide o produto independentemente. Inclua sistemas de backup. Coma o que plantou.

Por que não fazemos tudo isso? Porque é caro. Cada linha no código do software de controle de vôo do ônibus espacial custa à Loral, uma contratada da NASA, US$ 1.000 ou dez vezes mais do que custaria em um software comercial convencional. Você compraria um processador de textos ou uma planilha por US$ 5.000? Ou preferiria pagar 90% a menos e conviver com os bugs?

Há três batalhas importantes que os desenvolvedores precisarem encarar. Uma delas: os gerentes e clientes muitas vezes acham difícil especificar como um programa deverá funcionar. Segunda: pressões comerciais e prazos apertados praticamente implantam o caos durante o processo de desenvolvimento. E, finalmente, nenhum programa é imune a doença da “recursite”. Mesmo que a busca da alta qualidade seja a motivação para gerentes e programadores, uma lista de recursos que não para de inchar mantém fluidas as especificações do programa e aumenta as chances de introdução de bugs.

Frequentemente, a primeira ruptura no controle de qualidade ocorre antes de os desenvolvedores escreverem a primeira linha de código.

Um dos casos mais célebres de recursite ocorreu em 1993, quando a Silicon Graphics, Inc (SGI) lançou a versão 5.1 do Irix com mais de 500 bugs sérios. A administração tinha pressionado por um novo sistema operacional, uma nova interface com o usuário, melhores compiladores e ferramentas e novos recursos multimídia. Tudo na versão 5.1 deveria ser melhor. Nenhum sacrifício foi feito. Mas nove meses antes do lançamento, quando o moral estava baixo e a contagem de bugs alta, dois engenheiros seniores apontaram a impossibilidade da tarefa. A administração respondeu contratando dois empreiteiros que eram estranhos ao software e à organização da SGI.

“A tentativa desesperada de inovar fez com que os programadores reduzissem o caminho, com efeitos desastrosos sobre o número de bugs”, afirmou Tom Davis, o cientista chefe, em um memorando interno da companhia. Ele descreveu a luta e lamentou o código obeso do SO, a performance lerda e os requisitos de memória fora da realidade.

Por uma questão de agenda, a SGI impôs o congelamento do código antes que ele estivesse estável, o que resultou em um problema conhecido. “Estamos tentanto fechar a caixa antes de colocar o material pronto dentro dela, para depois tentar consertar as coisas dentro da caixa, sem desfazer o pacote”. Dizia o memorando.

Outro dos casos que conduz a uma crise conhecida: uma união na qual se retiram recursos da versão anterior. No caso da SGI, a companhia baniu aplicativos inteiros, mas era tarde demais para que isso tivesse algum efeito. “Nós mordemos mais do que podíamos mastigar”, concluiu Davis. “Como empresa, ainda não compreendemos como o software é difícil.”

Para aumentar os problemas da SGI, o memorando vazou para a Internet. A resposta foi sintomática: um correio de fãs. Davis recebeu pilhas de mensagens de desenvolvedores igualmente pressionados e a comunidade do mundo de software tacitamente adotou o problema. Essa reação ajudou o pessoal de vendas dos concorrentes da SGI a lembrar que eles não estavam imunes a erros desse tipo.

A despeito do constrangimento, o memorando pode em última análise revelar-se positivo para a SGI, porque o autor falou de forma apaixonada sobre a qualidade. E o apoio veio de um ponto chave. “No momento em que [o software] chegou às ruas, os clientes começaram a reclamar... Isso ajudou os administradores a ler o memorando com a mente aberta”, conta Davis.

A SGI respondeu com um simpósio de seis semanas sobre software para todos os departamentos: engenharia, gerenciamento, testes, marketing, manufatura, documentação e serviço de campo. A empresa investiu em ferramentas de medição integradas certificou-se de que elas sejam documentadas e estejam sempre disponíveis. A companhia identificou gargalos e atualizou o equipamento.

Bibliotecários entraram em cena para assegurar que a documentação dos projetos estivesse sempre atualizada. Os gerentes receberam livros sobre desenvolvimento de software. A SGI procurou formas de integrar certificação de qualidade de todo o processo de desenvolvimento. Os custos diretos: dezenas de milhares de dólares em novas ferramentas, centenas de milhares de dólares anuais com o novo pessoal e inestimáveis milhões de dólares em tempo adicional de engenharia.

O que a SGI não fez depois disso também é interessante. Ela não impôs nenhum tipo de processo de desenvolvimento específico. Ao invés disso, os grupos escolheram as ferramentas e métodos que consideraram melhores. Resultado: a versão 5.2 solucionou os bus, melhorou a performance e não acrescentou nenhum novo recurso. A versão 5.2 acrescentou alguns novos recursos estrategicamente escolhidos.

Gerenciando o caos
Enquanto a SGI aprendeu a lição da forma mais difícil, outras companhias procuram uma variedade de técnicas e ferramentas para salvá-la de pesadelos infestados de bugs. A maior parte do software comercial não é tão crítico em relação a vidas humanas quanto o sistema digital de controle de vôo do Boeing 777. Entretanto, o processo de desenvolvimento da Boeing ilustra como um braço administrativo firme pode ajudar a combater a doença da recursite.

Cerca de 400 pessoas passaram cinco anos trabalhando no software de controle de vôo do Boeing 777. Jim McWha, engenheiro chefe do Boeing Commercial Airplane Group para sistemas de controle de vôo trabalhou duro para certificar-se de que a equipe do 777 correspondesse aos requisitos. Para assegurar que os erros fossem detectados prematuramente, quando são mais baratos de corrigir, a equipe do 777 pediu opiniões a todo o pessoal-chave ma vida de um jato. De pilotos a pessoal de manufatura. Eles avaliaram os resultados de simulações em laboratório durante um ano e mais um ano no “pássaro de ferro” ( um modelo do avião em tamanho real). O objetivo da Boeing era ter uma especificação completa antes de os desenvolvedores escreverem qualquer código.

McWha também resistiu ao canceroso crescimento da lista de pedidos depois que a codificação começou. Para manter a linha, a Boeing criou quadros de revisão para avaliar cada pedido de mudança: recusou a metade, mas o crédito sem dúvida vai para o ar autoritário de McWha.

O enfoque que foi abandonado também é muito educativo. A Boeing contratou a GEC Marconi Avianics para escrever três versões do software de controle de vôo, cada uma a ser executada independentemente. Trabalhando a partir dos mesmos requisitos, três grupos (que não deveriam se comunicar entre si) codificaram em Ada, C e PL/M.

Métodos formais
Alguns desenvolvedores tratam da confiabilidade com o Capability Maturity Model (CMM), do software Engineering Institute da Carnegie Mellon University. O CMM classifica os processo de desenvolvimento de software em uma escala de cinco níveis. Os itens considerados no CMM variam desde quão livres de ambigüidades são as especificações até se a confiabilidade de um programa é verificada independentemente. A classificação no nível 1 significa que a organização pratica um caos coerente; o nível 5 indica uma disciplina em grau superlativo no gerenciamento e na engenharia. <!--[if !vml]--><!--[endif]-->

“É difícil discutir com o CMM”, afirma Roger Blais, gerente de melhoramento e processos de software da Tasc, uma integradora de sistemas para os setores governamental e privado. A companhia usou o método durante cinco anos e está em processo de receber a certificação CMM de uma avaliador acreditado junto ao software Engineering Institure. Blais acredita que o CMM é valioso porque transfere importância ao processo de desenvolvimento. “As ferramentas são muito voláteis e as plataformas estão em mudança o tempo todo”, diz ele. “Mas quem tem um processo montado, conta sempre com uma base sólida.”

Mas nada é perfeito. Os desenvolvedores de software do ônibus espacial afirmam estar fazendo tudo que é recomendado pelo CMM. Mesmo assim, o programa teve numerosos problemas de software, inclusive erros no Discovery que o fizeram posicionar-se inadequadamente sobre um observatório do Havaí para um experimento com raios laser.

Uma ajuda adicional contra o caos vem de métodos formais, projetados para trazer princípios científicos a um processo amplamente criativo. Blais diz que metodologias formais desempenham papel-chave ao ajudar a Tasc no desenvolvimento de produtos que variam do gerenciamento de documentos a sistemas aeronáuticos. A companhia constrói a maior parte de seus aplicativos para Windows e Unix usando C, C++ ou Visual Basic.

As vezes, os clientes especificam o uso de uma metodologia formal. Noutras ocasiões, a Tasc utiliza uma variação de metodologia de desenvolvimento em espiral do ciclo de vida, um modelo para a combinação iterativa das partes de um projeto à medida que elas evoluem. Blais afirma que o desenvolvimento em espiral por sua capacidade de oferecer um framework para cada projeto. O framework ajuda em eventuais requisições por mudança na especificação do projeto.

A Tasc utiliza também o ClearCase, da Atria, uma ferramenta de gerenciamento de configuração de software que Blais diz ser o coração dos trabalhos de desenvolvimento da Tasc. Ela faz o acompanhamento das mudanças no código, registra quais programadores fizeram as mudanças e analisa o impacto dessas sobre outras áreas do programa. Estas informações ajudam a comparar e gerenciar versões e “mantém todo mundo honesto”.

Teste é tudo

Milkowski exige reviso do cdigo a cada mudana

Milkowski ajuda a gerenciar 35 desenvolvedores que constroem um sistema de tempo real baseado em HP-UX, para levar informações financeiras aos clientes da companhia através de uma WAN corporativa. Nos últimos 18 meses, a equipe de desenvolvimento escreveu cerca de 800 mil linhas de código C e C++. Na disponibilização do sistema, prevista para abril próximo, o programa consistirá de cerca de um milhão de linhas de código.

Quando os desenvolvedores da Telerate concluem cada componente do programa, eles devem revisar o trabalho a busca de erros. A seguir, cada módulo passa por uma revisão de código, outra fase em que outros desenvolvedores avaliam. Milkowski exige revisões contínuas do código, em qualquer caso de mudança. “As mudanças mínimas são as que nos pegam pelo contrapé”, diz ele.

A complexidade do sistema de informações financeiras da Telerate, fazem os testes um desafio. A empresa projeta por exemplo, um dos quatro servidores para lidar com 120 ou mais clientes, a uma taxa de mil transações por segundo. Alguns dos servidores têm 1 GB de RAM. Os desenvolvedores podem escrever código que acessa a memória em qualquer ponto desse gigabyte de espaço. “Tudo está potencialmente tão interconectado atraves da RAM, que há chances quase ilimitadas para problemas”. Diz Milkowski.

Ele depende de seu “saco de ferramentas” para reduzir essas oportunidades. O SoftBench, da Hewlett-Packad, e o Discover Development Information System, da Software Emancipation Technology, analisam código legado para construir diagramas de estruturas e ajudar a equipe a decidir qual código é reutilizável. Se as funções que podem ser chamadas em um módulo são mais longas que uma ou duas páginas, os desenvolvedores da Telerate começam a se preocupar. Quanto mais complexo é o código, maior a probabilidade de um defeito. “As ferramentas nos ajudam a focalizar nossa atenção nos módulos apropriados durante a revisão do código”, explica Milkowski.

Para encontrar vazamentos de memória e de recursos, a equipe usa o Purity, da Pure Software, e o Sentinel, da AIB Software. Também são importantes os analisadores de cobertura de testes, que ajudam a ter certeza de que os testes que a Telerate cria estimulam todo o código. Testes interativos de cada componente do programa dão um feedback útil sobre a qualidade do código, mas os desenvolvedores ainda desconhecem se o sistema inteiro funcionará bem, ou não, sob as condições de pressão do mundo real. Quando chega a hora de simular condições de carga pesada, a Telerate utiliza ferramentas de carga de clientes como o Empower, da Performix, e o LoadRuner, da Mercury Interactive, para rodar múltiplos clientes e processos segundo agendas predeterminadas.

Ferramentas como essas viabilizam o teste de programas complexos, mas não estão imunes a problemas. É preciso muito trabalho para colocá-las em funcionamento corretamente, admite Milkowski. Além disso, os gerentes devem fazer previsão orçamentária para custos adicionais de suporte, na forma de pessoal de administração de sistemas e treinamento para o pessoal que utiliza as ferramentas.

A Adobe Systems também utilzia testes como sistema de alerta prévio. Marc Aronson, o diretor do software Productivity Group da Adobe, estabeleceu uma estratégia que constrói o interpretador todas as noites e roda-o em diversos núcleos de impressão, que a Adobe projetou. O sistema utiliza um subconjunto de suítes padrão de testes QA e registra os erros. Como o ambiente de programação faz o acompanhamento das mudanças no código ocorridas no dia anterior, os programadores sabem procurar quando surge um novo problema.

Embora os testes internos sejam a primeira linha de defesa, a adoção de beta testes pode ser de grande valia. Alguns programas, como o Windows 95, atraem interesse suficiente para que não faltem testadores.

A América Online também acha fácil conseguir voluntários. Mike Fairbarns coordenou o processo de beta teste da versão para Macintosh. A companhia avaliou a resposta de cada usuário, por categoria de sugestão de melhoramento ou indicação de bug. Ela subdividiu ainda os bugs por tipos de definiu prioridades para identificar aqueles a serem tratados com mais urgência.

O custo da complexidade
Nenhuma ferramenta ou metodologia oferece a resposta perfeita para a criação de excelente código num mundo imperfeito. Mas, considerações legais e éticas à parte, fazer software o mais confiável possível desde o início virou um mantra entre os desenvolvedores. É um bom negócio. Milkowski da Dow Jones Telerate, lembra que se um bug custa um dólar para ser corrigido, se for descoberto por um programador durante a geração do código, não custará menos de US$ 1.000 se ninguém o encontrar até o programa ser enviado para o usuário final.

Ainda não está claro, contudo, se a programação com qualidade desde o início significa que o software se tornará mais confiável ou se os desenvolvedores simplesmente cairão duros diante uma complexidade cada vez mais labiríntica.

Como construir código confiável

Por Oliver Sharp

9 Maneiras de Escrever Software mais Confiável:

1. Batalhe por um projeto estável

2. Divida as tarefas com clareza

3. Evite atalhos

4. Use assertivas generosamente

5. Utilize as ferramentas com bom senso

6. Dependa de menos programadores

7. Lute diligentemente conta a “doença da recursite”

8. Utilize métodos formais sempre que sejam apropriados

9. Comece a testar no momento em que escrever a primeira linha de código

Primeira lição a ser aprendida: é difícil construir software complexo que funcione bem. Na busca da salvação, ou do que o engenheiro de software e escritor Frederick Brooks chama de “a bala de prata”, muitas pessoas procuram modelos, técnicas e ferramentas. As soluções já foram programação estruturada e linguagens de alto nível; agora, são os construtores de aplicativos, o componenteware e as técnicas OPP (Object-Oriented Programming – Programação orientada a objetos). Contudo, os pregadores de todas essas soluções ignoram uma verdade que incomoda; software confiável pode ser escrito usando “go to” e linguagem assembly. Muito código imprestável já foi produzido em ferramentas e técnicas impecavelmente modernas.

A realidade é que um fator predomina sobre qualquer outro na determinação da qualidade do software; o nível de gerenciamento do projeto. A equipe de desenvolvimento deve saber qual código se espera que ele construa, deve testar o software constantemente à medida que ele evolui e deve estar disposta a sacrificar parte da velocidade de desenvolvimento no altar da confiabilidade. Os líderes da equipe precisam estabelecer uma política de como o código é construído e testado. As ferramentas são valiosas pois facilitam a implementação de uma política, mas não podem defini-la. Esse é o trabalho dos líderes da equipe. Se eles fracassarem ao fazê-lo, não haverá ferramenta ou software que os salve.

Um dos motivos pelos quais a qualidade muitas vezes e deixada em segundo plano é porque ela não vem de graça. Software confiável frequentemente tem menos recursos e leva mais tempo para ser produzido. Não há truques ou técnicas que elimine a complexidade de um aplicativo moderno, mas algumas idéias podem ajudar:

Batalhe por um projeto estável
Um dos piores obstáculos para a construção de um bom sistema é um projeto que fica mudando. Cada mudança significa reconstrução de código que já foi escrito, alterando planos no meio do caminho e corrompendo a consistência interna do sistema.

O problema é que muitas vezes ninguém sabe o que o programa deve fazer até que haja uma versão preliminar rodando. Uma excelente estratégia é construir bonecos e protótipos que os usuários em potencial possam começar a experimentar cedo, de modo que o projeto fique definido o mais rapidamente possível. Uma vez que os projetistas tenham alinhado a estrutura básica do sistema, quaisquer alterações que não sejam críticas devem esperar até a próxima versão. É difícil manter essa linha dura, mas quanto mais perto os desenvolvedores conseguem chegar dela, melhor será o código.

Divida claramente as tarefas
Ao projetar um sistema complexo, divida o trabalho em partes menores que tenhas boas interfaces e compartilhem as estruturas de dados apropriadas. Se você conseguir fazer isso corretamente, poderá tomar muitas decisões erradas de implementação sem arruinar o projeto geral e a performance.

Linguagens de programação orientadas a objetos podem fornecer uma forma útil de expressar e forçar a estratégia de decomposição, mas não dizem aos projetistas como fazer esse trabalho. É infinitamente melhor ter um bom projeto implementado em C do que um projeto fracassado em C++.

Evite atalhos
Os programadores muitas vezes não reservam tempo para corrigir um erro no projeto quando já estão trabalhando no código. Essas decisões voltam para tirar o sono de todo o mundo. Evite atalhos, insistindo que cada mudança seja cuidadosamente documentada. O trabalho de escrever mais tarde pode ser usado como um importante argumento convincente.

Use generosamente as assertivas
Uma assertiva (assertion) é simplesmente uma linha de código que diz “Eu acho que isso é verdade. Se não for, aldo deu errado; portando, pare a execução e informe-me imediatamente”. Se um valor deve estar dentro de uma certa faixa, verifique antes. Certifique-se que ponteiros apontam para algum lugar e que as estruturar internas de dados são consistentes.

Tal como outras partes do código de depuração (debugging), é possível compilar deixando as assertivas fora do código de produção antes que ele entre nos estágios finais de produção. Há todos os motivos do mundo para poluir o código com assertivas. Os problemas são encontrados com rapidez, ficando muito mais fácil mantê-los sob controle.

Utilize as ferramentas com bom senso
Ferramentas não são uma panacéia. Elas não podem ajudar a consertas um projeto que está sendo mal administrado. Mas as ferramentas podem tornar mais fácil para as equipes de desenvolvimento a efetivação de políticas. Ferramentas de gerenciamento de código fonte, como o RCS, de domínio público, ou o PVCS, da Intersolv, ajudam a coordenar módulos usados por múltiplos desenvolvedores.

Há também algumas ferramentas que podem localizar certos erros no código, ao invés de forçar o programador a fazer isso. O utilitário Unix lint (ou a versão turbinada oferecida no Code Center, da Centerline) encontra erros de sintaxe e incoerências entre diferentes arquivos de código fonte. O Punfy, da NuMega Technologies, detectam uma variedade de erros de memória quando eles ocorrem e não quando se manifestam mais tarde. Outras ferramentas executam testes de regressão ou fazem análises de cobertura de código, para ver se há algum canto empoeirado no programa que não está sendo excitado.

Dependa de menos programadores
Uma forma fácil de reduzir o número de bugs num projeto é diminuir o número de pessoas envolvidas nele. As vantagens: menor sobrecarga de gerenciamento, menor necessidade de coordenaçAao e mais contato enre os membros da equipe que constrói o sistema.

É possível reduzir o número de pessoas fazendo com que os programadores individuais produzam código mais rapidamente ou diminuindo a quantidade de código que precisa ser escrito. Ferramentas CASE, construtores de aplicativos e reutilização de código são as formas de tentar satisfazer um desses ou ambos os objetivos. Embora esses produtos nem sempre cumpram o que prometem, pode simplificar um projeto, de modo que uma equipe menor seja capaz de lidar com eles.

Comentrios

DhYyysnNi Por Elisangela em 20/02/2012 01:39:55

Comente!*
Nome:
E-mail
Homepage
Ttulo:
Comentrio:
Cdigo:*