Omissão de fases de um projeto de software – A armadilha

Todo responsável por projetos, gerente ou empresa, deseja que o mesmo atenda as especificações dos requisitos, seja executado no menor tempo e possua o menor custo possível. Neste cenário ideal, precisa-se atentar a qualidade que se pretende obter tanto no produto quanto no ciclo de vida do mesmo, contemplando o período pós-implantação com prováveis manutenções corretivas e evolutivas.

Quem gerencia projetos, ou já contratou empresas para executar projetos, sabe que podemos diminuir custos e diminuir prazos deixando de realizar fases importantes do mesmo, tais como fase de levantamento e análise de requisitos, design e documentação. Outra maneira é a de diminuir a própria qualidade do produto a ser desenvolvido, omitindo ou diminuindo a fase de testes.

É justamente aqui que vai se armando uma grande armadilha. Alguns envolvidos podem não estar cientes das consequências geradas para a empresa que estará recebendo o produto, pela decisão de omitir fases ou deixar de gerar documentação do projeto.

Para ilustração, comento que existem requisitos conhecidos como requisitos não funcionais, relacionados a características do software que estão embarcados na solução mas que não são funcionalidades utilizadas diretamente pelo usuário, descrevendo qualidades do sistema.

Um exemplo de requisito não funcional é o de confiabilidade, garantindo que as informações disponibilizadas pelo sistema a ser desenvolvido sejam fidedignas. Não conseguimos atingir esta meta se não realizarmos a fase de requisitos e de análise em nosso projeto.

Caso o projeto não atinja este quesito, apresentando informações consideradas não fidedignas pelos usuários, nenhum deles se interessará em utilizar o mesmo e o projeto fracassará, e todo o investimento será perdido. Tive a oportunidade de ver funcionários de uma grande empresa comentando justamente isto, que não utilizavam um sistema da mesma por não confiarem nas informações apresentadas.

Isto pode ser evitado caso o projeto utilize uma Metodologia de Desenvolvimento de Sistemas adequada.

Imagine agora um cenário de um sistema de Cobrança bancária, para o qual você poderia estar participando de um processo de manutenção corretiva, sem ter documentação do sistema e sem ter conhecimento das regras de negócio implementadas. Imagine também que esta manutenção está relacionada à correção de informações, que estão sendo geradas incorretamente Agora, para finalizar, imagine que o sistema possui milhares de linhas de código no paradigma procedural e você é novo na equipe e foi contratado recentemente, sendo que os programadores que implementaram o sistema não estão mais na empresa.

Por mais que este cenário seja assustador, podemos encontrá-lo neste exato momento em diversos lugares, enquanto você lê este parágrafo.

O que faltou no projeto de desenvolvimento deste tipo de sistema?

Entre outros, poderia citar:

  • Utilização de Metodologia de Desenvolvimento de Software e os produtos de cada fase.
  • Engenharia de Software e utilização de processos definidos.
  • Utilização de paradigma de desenvolvimento Orientado a Objetos.
  • Utilização de Design Patterns, caso coubesse.
  • Documentação adequada.

Do lado humano, poderia citar:

  • Participação no projeto de profissionais com conhecimento dos itens técnicos acima relacionados.
  • Falta de percepção do sponsor responsável pelo projeto do valor e benefícios de se utilizar os itens acima relacionados.
  • Falta de conhecimento dos envolvidos no projeto, das melhores práticas de mercado para desenvolvimento de software e de seus benefícios.

Já tive a oportunidade de presenciar de empresários e executivos, o seguinte comentário:

“Prefiro o desenvolvimento de software sem utilizar Orientação a Objetos e processos de desenvolvimento, pois é mais barato e mais rápido de se disponibilizar o sistema para os usuários.”

Desenvolver código baseado nesta ideia pode gerar as seguintes consequências:

  • Implantação de sistemas cheios de erros, constantemente entrando em manutenção corretiva.
  • Sistemas que podem não atender às expectativas dos Stakeholders.
  • Softwares com alto custo de manutenção.
  • Softwares difíceis de serem utilizados, não atendendo às necessidades dos StakeHolders.
  • Grande insatisfação dos usuários.
  • Fracasso do projeto.

O desenvolvimento de sistema sem utilizar processos, AD HOC, acaba custando muito mais caro, gerando insatisfação.

Já presenciei várias vezes, pessoas que simplesmente não queriam e não utilizavam sistemas disponibilizados pela empresa, por pelo menos um dos seguintes motivos:

  • Não confiavam nos dados por eles apresentados.
  • Porque não atendiam a suas expectativas e necessidades do dia a dia.
  • Porque tinham usabilidade ruim.
  • Porque viviam apresentando problemas de funcionamento.

O detalhe mais triste é que as empresas onde estas pessoas trabalhavam, investiram dinheiro e tentaram disponibilizar sistema para melhorar a produtividade e diminuir custos das mesmas. O resultado foi exatamente o contrário pois além de não diminuir custos, nem aumentar produtividade, as empresas perderam todo o investimento realizado e o sistema caiu em desuso, literalmente, sendo jogado fora.

Realizar um projeto omitindo fases cria uma grande armadilha, para a empresa que está adquirindo o sistema.

Para saber mais, leia o livro Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1


4 Comentários

Marketing Digital
1

Infelizmente esse é o dia-a-dia de uma empresa. Gerentes estão preocupados e agilizar e cortar custos e negligenciam muitas, muitas coisas.
Resultado? 100% das vezes algo sai errado ou o prazo não é cumprido.
Lamentável.

carlos tadeu
2

Utilização de Design Patterns, caso coube-se. Vc quis dizer caso coubesse?
E é bom saber também que já vi casos de utilizarem todos os passos da metodologia (cascade, por exemplo), mas sem comprometimento nenhum com a “verdade”; as fases eram aprovadas PORQUE os documentos estavam feitos, mas ninguém conseguia “ver” se estavam CERTOS e por isso MESMO aprovavam (os loucos lá devem saber o que estão fazendo!!).
E tudo foi por água abaixo, com metodologia e tudo.
SOMENTE seguir uma metodologia não garante o resultado.
Aliás, vi isso num sistema de cobrança bancária, exatamente o mesmo do seu exemplo. E vivi sistema de cobrança bancária sem metologia nenhuma funcionando e muito bem gerenciado SEM metologia nenhuma e por mais de 20 anos.
Concluo que sem o comprometimento das pessoas com os resultados Não há metodologia nenhuma que resolva (algumas ajudam, outras atrapalham demais).

Alceu Fiuza
3

Como determina a Lei de Murphy : “Se alguma coisa pode dar errado, com certeza dará” .

Diogo
4

Concordo com o Carlos Tadeu.
O mais importante é o comprometimento das pessoas com o projeto. Uma metodologia só irá resolver o “problema”, se houver compromisso por parte dos envolvidos.

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!