CloudWare

Virtual Case File: Anatomia de um Projeto Fracassado

Terça, 04 Outubro 2011

Virtual Case File foi um software feito para o FBI que não deu certo. Neste artigo serão abordadas as principais falhas que levaram a suspensão do projeto, deixando claro que desde o inicio do mesmo ele já estava condenado ao fracasso.

virtual case file

O PROJETO

Virtual Case File (VCF) foi um projeto ambicioso idealizado pelo Federal Bureau of Investigation (FBI), o serviço de investigação americano. Como o próprio nome aponta, o Virtual Case File, é um sistema em que todas as informações e dados seriam virtuais, ou seja, elas estariam armazenadas e disponíveis a partir de computadores, não mais em relatórios de papel.

Seu objetivo primário era substituir o Automated Case Support (ACS), software até então utilizado, e o uso do papel nos relatórios por um sistema online, dessa forma seria muito mais eficiente a comunicação entre seus agentes, permitindo que pedaços das informações recolhidas através de canais diferentes, em momentos diferentes, possam ser ligados permitindo investigações mais rápidas e eficazes através de um melhor controle da informação. Desta forma seus agentes poderiam visualizar, inserir, atualizar e compartilhar informações vitais das investigações em qualquer lugar onde haja acesso a internet.

O ACS era o software utilizado naquele tempo, havia sido desenvolvido pelo próprio FBI. Foi feito na linguagem de programação chamada Natural, seu banco de dados era o ADABAS e utilizava os IBM 3270 como terminais. Alguns analistas de TI acreditavam que o ACS já estava obsoleto quando foi implantado em 1995. Segundo Glenn A. Fine (2005), Inspetor Geral do Departamento de Justiça dos EUA, "O arcaico Automated Case Support era pesado, ineficaz e limitado nas suas capacidades, além de não permitir gerenciar, analisar e compartilhar informações de forma tão eficaz e oportuna como necessário”.

O VCF fazia parte de uma grande iniciativa do FBI chamada de “Trilogy” que, como o próprio nome indica, era dividida em três partes:

1 – Atualização do software e hardware para todos os agentes do FBI.

2 – Atualização da sua rede de comunicações.

3 – Atualização do seu sistema de gerenciamento de casos, o Virtual Case File, para permitir melhor acesso e compartilhamento de informações entre seus agentes.

As duas primeiras etapas do projeto “Trilogy” foram concluídas, no entanto, o Virtual Case File teve gastos excessivos, muito além do programado, não cumpriu o prazo de entrega e nunca atingiu os seus reais objetivos, além de ter custado mais de 170 milhões de dólares.

DECADÊNCIA DO PROJETO

Bob E. Dies, Diretor Adjunto do FBI e chefe do projeto “Trilogy”, preparou os planos iniciados deste projeto no ano 2000. Em junho de 2001 a Science Applications International Corporation (SAIC), responsável pela criação do software, e a DynCorp, responsável pela parte do hardware e da rede, foram contratadas para participarem do projeto. O projeto estava previsto para ser entregue em meados de 2004.

Para definir mais precisamente o que o VCF precisaria, o SAIC iniciou diversas sessões de Joint Application Development (JAD), em português, Desenvolvimento Conjunto de Aplicação, onde diversos agentes do FBI se juntaram com engenheiros do SAIC para discutir sobre as necessidades do VCF. Após diversas reuniões, a base dos requerimentos necessários estava formulada permitindo que os designers e programadores do SAIC pudessem trabalhar.

Depois do atentado terrorista em 11 de setembro de 2001, o contra-terrorismo se tornou prioridade máxima. A partir deste dia o FBI passou a ser criticado por não "ligar os pontos" a tempo de impedir o ataque, logo a pressão para que o projeto “Trilogy” terminasse se intensificou.

Em Janeiro de 2002, o FBI pediu 70 milhões de dólares a mais para acelerar o projeto, o Congresso foi mais longe aprovando 78 milhões. O SAIC concordou em entregar a versão inicial do VCF, em dezembro de 2003 em vez de junho de 2004, a data prevista inicialmente.

A partir desta data o FBI e o SAIC se comprometeram em criar um sistema completamente novo em 22 meses, que substituiria o ACS de uma só vez, usando uma manobra arriscada conhecida como flash cutover. Basicamente, as pessoas iriam fazer logoff do ACS na tarde de sexta-feira e na manhã de segunda-feira quanto fizerem logon o VCF já estaria implementado. Uma vez que o flash cutover é implantado não há mais volta, mesmo que o VCF não funcione como esperado. Um “detalhe” muito importante é: não havia plano B.

O SAIC resolveu dividir seu grupo de desenvolvedores em oito equipes, trabalhando em paralelo em diferentes partes do software, com o objetivo de concluir o projeto mais rapidamente. Rick Reynolds, vice-presidente do SAIC, defendeu esta decisão de mudança de tática. Segundo ele "As pessoas esqueceram da urgência do nosso cliente. E nós estávamos do lado dele”.

Em 13 de Dezembro de 2003, o SAIC entregou como prometido a primeira versão “de testes” do VCF, nele foram encontrados 17 "deficiências funcionais".  As reclamações ao SAIC foram feitas para que a correção fosse feita antes que o sistema fosse implementado.

Em 2005, um relatório com base em diversos testes feitos no software foi divulgado revelando mais de 400 irregularidades, grandes e pequenas. Um exemplo das mais graves seria a falta da opção de buscar as pessoas por especialidade e por titulo de trabalho. Das menos graves um exemplo seria um botão na interface gráfica do usuário que foi rotulado como "Estado" mais deveria ser "Estado/Província/Território". O SAIC pediu mais 1 ano e 56 milhões para poder resolver todos estes problemas apontados, mais o FBI rejeitou a proposta.

No dia 3 de fevereiro de 2005 o Senador Judd Gregg revelou algumas linhas deste relatório dizendo: “O VCF foi desenvolvido sem uma avaliação adequada e possuía várias inconformidades com os padrões estabelecidos, além disso, documentos de alto nível, incluindo o conceito de operações, a arquitetura de sistemas e requisitos de sistema foram totalmente inconsistentes, sem uma visão clara das necessidades dos usuários.” Disse também que “os requisitos e a documentação do projeto estavam incompletos e imprecisos, os requisitos e design traçados tinham falhas, e que o software não pode ser mantido sem dificuldades, sendo portanto, impróprio para uso.”

RAZÕES PARA O FRACASSO

Desde o inicio do projeto, houve pequenas e grandes falhas, que somando todas resultaram no fracasso, já esperado por muitos, do software Virtual Case File. A seguir serão comentados os principais erros cometidos durante todo o projeto.

Primeiramente o projeto não teve um BluePrint. Este modelo descreve, de forma bastante detalhada, todo o funcionamento de uma organização e suas operações, também mostra como se organiza e se usa a tecnologia para realizar suas tarefas, como o sistema é estruturado e concebido para atingir aqueles objetivos.  Desta forma é possível perceber que desde o começo não houve um planejamento profundo por parte dos responsáveis pelo projeto, levando a tomada de pobres e imprecisas decisões. Neste caso, as pessoas veem o planejamento como um desperdício de tempo, porque eles acreditam que o tempo é melhor gasto fazendo algo ao invés de somente planejar (Fichter, 2003).

Além de não possuir um planejamento correto houve varias mudanças nas especificações do projeto desde seu inicio. Estima-se que o projeto “Trilogy” cresceu cerca de 80% ao longo do tempo. Devido a essas mudanças repentinas, em um dado momento, o VCF chegou a possuir mais de 700.000 linhas de código.

Outro grave erro cometido foi a pressa para conclusão do projeto. No inicio de 2002, quando o FBI pediu um aumento no orçamento para “acelerar” o desenvolvimento do software, foi quando as coisas começaram a piorar drasticamente, pois passou a estabelecer datas excessivamente ambiciosas. O FBI juntamente com o SAIC desenvolveram planos para acelerar a conclusão do projeto, com o objetivo de terminá-lo antes do esperado. Isso ocasionou graves problemas no software que nunca foram totalmente corrigidos, com mais de 400 irregularidades encontradas o projeto foi definitivamente suspenso.

Devido a falta de planejamento, o FBI não tinha um plano de contingência, popularmente conhecido como “Plano B”, para lidar com as falhas inesperadas, tudo que o FBI queria fazer era substituir o seu sistema de software existente, as consequências nunca foram fortemente planejadas. Outro fator de grande importância que praticamente não existiu foi a fiscalização do projeto.

O gerenciamento do projeto e a falta de conhecimento de muitos também afetaram significamente o desenvolvimento do VCF. O FBI teve cinco diferentes CIOs (Chief Information Officer) e quatorze gestores durante todo o projeto, onde somente o quinto CIO era um gerente de projetos, sendo que a tomada de decisões era feita por um comitê e não por um individuo mais instruído. A falta de um líder fixo e a constante mudança de oficiais e gestores ocasionou em um verdadeiro caos. A inclusão de muito pessoal do FBI que possuía pouco, ou nenhum, conhecimento/treinamento em informática também acabou agravando a situação.

Outro erro cometido foi não seguir a Lei de Brooks, presente no livro Mythical Man-Month. Essa lei se resume na seguinte ideia: colocar mais programadores pra trabalhar em um projeto atrasado vai atrasá-lo mais ainda. Foi feito exatamente isso neste projeto, o que ocasionou em mais problemas, pois quando um programador é recém-introduzido em uma equipe já formada há algum tempo, o mesmo demora para tornar-se produtivo e acaba atrasando os outros membros da equipe.

Além de fatores internos, alguns fatores externos também ajudaram com a decadência do projeto. O atentado terrorista de 11 de setembro de 2001 contra o World Trade Center e o Pentágono, e o caso de espionagem Hanssen em fevereiro do mesmo ano, acabaram influenciando diretamente a aceleração do projeto, pois um dos fatores que permitiram que tais acontecimentos acontecessem foi o uso do arcaico ACS.

SOLUÇÃO

Depois de apontados os principais erros que levaram ao fracasso do Virtual Case File, chegou o momento de apresentar as soluções que poderiam ter levado o mesmo ao sucesso.

O PLANEJAMENTO

Planejamento é fundamental em qualquer projeto de software, desde um claro BluePrint ate a escolha da linguagem no qual o software será desenvolvido. Com um bom planejamento é possível programar o plano de implementação e acompanhar o progresso do projeto. Também permite expor as reais necessidades do cliente, além de deixar claro para o mesmo o que ele pode esperar do software a ser desenvolvido.

Todas as necessidades do cliente devem ser exploradas, através de constantes reuniões, como por exemplo o JAD (Joint Application Development) que foi muito utilizado pelo SAIC no projeto VCF. Se os requisitos e necessidades são bem definidos desde o inicio do projeto, mudanças repentinas ou problemas inesperados irão ocorrer com muito menos frequência.

A METODOLOGIA

Não foi oficialmente divulgado qual o método utilizado no projetos, mas após várias análises foi concluído que o método mais provável seria o Rapid Application Development (RAD). Duas informações liberadas durante o projeto sugeriram essa afirmação, são elas:

  • Em 2002, quando o SAIC resolveu dividir seu grupo de desenvolvedores em oito equipes: Esta é uma prática comum quando se aplica a metodologia RAD, onde diversas equipes são formadas para trabalharem em paralelo permitindo assim, um desenvolvimento ágil do projeto.
  • Em 13 de Dezembro de 2003, quando o SAIC entregou a primeira versão “de testes” do VCF: Esta versão de testes poderia ser considerada como um protótipo, outra prática comum quando se aplica o RAD. Desta forma o cliente pode ver mais cedo como seu software está ficando, permitindo a correção ou aperfeiçoamento do mesmo.

O uso do método RAD somente é aconselhado para curtos prazos (no máximo 90 dias) pois ele não permite que um planejamento profundo seja feito, essencial em projetos de grande porte.

O método mais aconselhável para utilizar no projeto VCF é o Rational Unified Process (RUP). É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos. Ele se baseia em quatro fases:

  • Fase de concepção: Nesta fase o projeto é idealizado, o workflow (fluxo de trabalho) é analisado e blueprints são feitos.
  • Fase de elaboração: Aqui o foco vai para o desenvolvimento do sistema, estando mais voltado para a sua arquitetura. Nesta fase perguntas como “O projeto é confiável?” e “Os custos são aceitáveis?” são feitas para confirmar a qualidade do projeto.
  • Fase de construção: Nesta fase começa o desenvolvimento do software, produção de códigos e testes.
  • Fase de transição: Nesta fase ocorre a entrega do software, bem como o acompanhamento e o teste de qualidade. Nesta fase também é realizada a capacitação dos usuários.

A LIDERANÇA

A liderança é outro fator chave para o sucesso de um projeto. Não é nada saudável para um projeto possuir engenheiros, analistas e/ou gerentes com pouca/nenhuma experiência ou sem habilidade suficiente. O “rodizio” de pessoas com cargos como esse também não é nada recomendado. Foi o que aconteceu no projeto VCF onde houve, no período de 4 anos, 5 diferentes CIOs e 14 gerentes ao longo do projeto. Ações como esta começam a ocasionar confrontos de ideias e metodologias que, por sua vez, acabam atrasando ou até mesmo, como aconteceu com o VCF, cancelando o projeto.

A COMUNICAÇÃO

Projetos às vezes falham devido à comunicação inadequada. Esse foi um dos motivos apontados pelo SAIC em relação ao FBI. Segundo eles a comunicação com os gerentes de TI do FBI era muito difícil de ser feita.

É necessário sempre manter atualizados e bem informados todos os envolvidos com o projeto sobre o que está acontecendo, além de explicar claramente o que os membros da equipe devem fazer.

O TEMPO

O tempo sempre é inimigo nessas horas. O prazo estabelecido sempre torna o trabalho mais difícil e acaba ocasionando na pressa, isso foi o que aconteceu com o VCF, onde pensaram que 3 anos era muito tempo e que o projeto poderia ser “acelerado”.

Segundo Neil McAllister (2008), famoso CIO norte-americano, “quando se planeja projetos de TI, o excesso de confiança e entusiasmo podem ser sua ruína. Uma estimativa de tempo apressada e otimista se transforma facilmente em uma entrega difícil de concretizar. Por isso, sempre é bom reservar um tempo para atingir as metas do projeto, mesmo que elas pareçam simples no começo. Sempre é melhor entregar demais do que deixar a desejar”.

Segundo Fichter (2003), um problema comum na estimativa de tempo de determinado projeto é pensar que o tempo de tarefa é igual a duração. O tempo de tarefa é o tempo que certa tarefa levará para ser concluída sem interrupções, enquanto que a duração é o tempo total que a tarefa precisa para ser completada, incluindo interrupções. Muitos gerentes de projeto acabam tomando como base o tempo de tarefa para estipular prazos, este é um dos erros mais comuns.

OS RISCOS

Todo projeto de TI envolve um certo grau de risco, uma analise profunda de qualquer tipo de risco que possa vir a ocorrer deve ser estudado. Não fazer um cálculo de risco explícito é um dos grandes problemas com o planejamento do projeto (Armour, 2005). Ninguém gosta de discutir os riscos do projeto, é da natureza humana pensar positivo, achar que nada vai dar errado. Às vezes o sucesso ou fracasso é determinado pelo quanto está preparada a equipe quando certo desastre ocorre. Se a equipe do projeto não está preparada, o projeto pode parar inesperadamente até que um novo plano possa ser executado.

Em projetos de TI, gerentes de projeto muitas vezes não sabem qual o nível de risco que eles correm ao fazer um plano, porque eles não criaram os processos necessários para calcular e informar o risco (Armour, 2005). As novas tecnologias que substituem as antigas tecnologias implicam riscos novos e desconhecidos (Kharbanda, 1996).

A DOCUMENTAÇÃO

No dia 3 de fevereiro de 2005 quando o Senador Judd Gregg revelou algumas linhas do relatório expondo os erros cometidos, ele disse que “os requisitos e a documentação do projeto estavam incompletos e imprecisos”. Sem uma documentação clara e precisa, não existe uma base para testar o software e não há maneira de medir os benefícios, e malefícios, da sua implementação. Mesmo as metodologias de teste de software e ferramentas mais sofisticadas, é necessário uma definição detalhada do que é esperado do software para que ele possa ser plenamente explorado.

NOVO PROJETO: “SENTINEL”

Em março de 2006, um ano após o cancelamento do VCF, o FBI divulgou o inicio de um novo projeto, para substituir de vez o ACS, chamado de “Sentinel”.  Desta vez a estimativa de gasto foi de, no máximo, 500 milhões de dólares e seu prazo de entrega foi previsto para o final de 2009.

Em abril de 2010 o diretor do FBI, Robert Mueller, falou sobre o atraso do projeto afirmando que via o atraso como algo menor e afirmou que estava "cautelosamente otimista" com o sucesso do projeto. Agora espera-se que este projeto seja concluído em 2011.

Android

Java

Hibernate

Joomla!

CSS3

HTML5

Saia na Frente

html5 css3

Sobre Mim

sobre-foto-2Adriel Café é Web Master e Desenvolvedor Java. Ele incentiva o uso/estudo de Web Standards, Java e Android.

Saiba Mais

Encontre-me

facebook linkedin