Há muito tempo o termo qualidade já deixou de ser um fator de competitividade, tornando-se um fator de sobrevivência das corporações, e isto com certeza não é diferente nas área de TI.

  Acontece que algumas organizações ainda não tem bem claro o conceito correto de qualidade em software, associando o termo apenas às faltas de sistemas (erros). A qualidade tem um sentido muito mais amplo, que vai desde a concepção de um sistema de informação até a manutenção do mesmo, durante o seu ciclo de vida.

  Dessa forma, quando se fala em qualidade de software, deve-se levar em conta os seguintes fatores:

§ Software sem falhas: o mais básico dos fatores. Um sistema de informação não deve conter aplicativos que parem de funcionar constantemente, interrompendo o fluxo de atividades da empresa.
§ Prazos: quando é feito um projeto de software, que pode criar ou modificar um sistema de informação, toda empresa traça um plano de adequação a esse projeto, que justamente se concretiza no momento da liberação do mesmo. Essa situação gera uma enorme expectativa dentro da organização. O fato entregar um projeto de software com atraso causa com certeza um desconforto, pois a empresa deverá se replanejar conforme um novo prazo de implantação do projeto. Além disso, esse fato abala o sentimento de confiança que a empresa tem com a equipe de TI, seja ela interna ou um fornecedor de software.

§ Custos: da mesma forma que os prazos, falhas de orçamento causam o mesmo desconforto, falta de confiança e até mesmo cancelamento de projetos.

§ Documentação: um organização pode durar centenas de anos, porém, os seus colaboradores não, pois eles se aposentam, falecem, mudam de empresa, mudam de ramo atividade, enfim, não fazem parte do patrimônio fixo da empresa. Assim sendo, a inteligência de um sistema de informação não deve estar nas cabeças das pessoas que o usam ou mantém, e sim documentadas no próprio sistema. A falta de documentação pode causar um enorme problema na hora de efetuar modificações no sistema.

  Visando adequar esses fatores de qualidade aos projeto de desenvolvimento de software, surge a necessidade de uma Metodologia de Desenvolvimento de Sistemas (MDS), instrumento esse que é tão estratégico para a organização quando o sua forma de atuação. O princípio básico da MDS é normatizar a forma com que são conduzidos os projeto de software. Devido ao fato da MDS ser estratégica para a organização, não existem duas empresas com metodologias idênticas, entretanto, todas seguem uma linha mestre, atuando da seguinte forma:

§ Uniformidade: uma vez implantada uma MDS na organização, ela deve ser única e de conhecimento de todos os envolvidos (Direção, Áreas Usuárias e TI).

§ Independências das pessoas: tanto o conhecimento contido nos sistemas de informação, bem como o próprio processo de desenvolvimento de software devem estar documentados de tal forma que seja possível mudar as pessoas durante qualquer fase de projeto sem interferir na qualidade final do trabalho. Em hipótese alguma a qualidade deve variar em função do responsável pelo projeto. A qualidade do projeto deve ser da empresa e não do indivíduo que conduziu o projeto. Neste ponto é muito importante a padronização das atividades.

§ Formalização: a MDS deve deixar muito claro quais atividades serão feitas durante o projeto de software, quem a fará e quando serão feitas. Dessa forma, a formalização do processo de desenvolvimento de software, através de uma série de documentos gerados em cada fase do projeto, garante que fique evidenciado que o trabalho foi realmente feito. Isso é muito útil em casos de auditoria e certificações (ISO 9000 - por exemplo). Além disso, a formalização gera comprometimento tanto para a área usuária quanto para a área de TI.

§ Gerenciamento: A MDS deve dispor de ferramentas capazes de acompanhar o andamento do projeto, apontar seus desvios e elaborar planos de ação a fim de corrigir tais desvios.
§ Avaliação: todo projeto de software deve ser acrescentado ao histórico da organização, refinando os indicadores de produtividade / lucratividade da empresa.

  Uma MDS moderna transforma o projeto de software em módulos ou fases, sendo que cada uma delas tem seu conjunto de ferramentas e produtos gerados. Existem vários termos diferentes usados para designar essas fases da MDS. Assim sendo, segue abaixo uma das formas de cada uma das fases:

§ Estudo preliminar: cada projeto de software normalmente surge para resolver um determinado problema para a empresa. Assim sendo, a principal tarefa desta fase é mapear o problema e propor alternativas de soluções para o mesmo. Neste ponto do projeto já é possível fazer um orçamento prévio de custo/prazos do projeto, que ajudarão a empresa na decisão de executar ou não o projeto.

§ Modelagem conceitual: uma vez definida a alternativa de solução para o problema proposto, é efetuado um trabalho de detalhamento das atividades que serão feitas no projeto. Neste ponto já será possível definir com clareza o scopo, a visualização de protótipos e planos que homologação, que servirão para confirmar se a alternativa escolhida está coerente. O produto resultante desta fase é o ante-projeto, que servirá de base para mensurar o tamanho correto do projeto (usa-se para isso técnicas de métricas de sistema, FPA, por exemplo), que consequentemente apurará o custo e o prazo do projeto. Neste ponto do projeto fica bastante claro, tanto para a área usuária, quanto para a área de TI, o que será feito, quando será entregue e quanto custará. O risco de um desvio nessas informações é mínimo.

§ Projeto de Implementação: de posse do ante-projeto, que define detalhadamente o que será feito no projeto, é atividade desta fase definir como implementar as novas funcionalidades. Nesta fase o trabalho da área de TI é mais intenso, pois as atividades são puramente técnicas. O resultado desta fase são as definições técnicas de cada aplicativo a ser criado / modificado pelo projeto.

§ Construção: é a fase onde são construídos / testados os novos componentes do sistema de informação. O importante dessa fase é a padronização das formas de programação e aplicação de ferramentas para garantia de qualidade, uma vez que este é um dos pontos onde surgem falhas de aplicativos. O resultado desta fase é a formalização do final da programação de cada aplicativo.

§ Homologação: é o momento em que a área usuária simula a operação da nova versão do sistema de informação, em ambiente similar ao de produção. Esta fase faz o fechamento entre o que foi solicitado e o que está para ser entregue. O produto desta fase é a aceitação formal da área usuária da nova versão do sistema.

§ Implantação: é a fase onde a nova versão do sistema é instalada. O produto desta fase é o termo de entrega do projeto, homologado pela área usuária.

§ Gerenciamento: tão importante quanto construir um sistema é acompanhá-lo em relação aos prazos, custo e atividades que possam ser incluídas ou modificadas durante o andamento do projeto. Os produtos dessa fase são os relatórios de acompanhamento e pedidos de alteração de especificação.

§ Avaliação: após o término do projeto de software, é necessário avaliar o projeto com relação aos prazos, custos e qualidade. Os desvios devem ser analisados de tal forma que promovam ajustes na base histórica da organização e caso necessário, ajustes na própria MDS.

  Por fim, a MDS muitas vezes é encarada como processo burocrático dentro das organizações, entretanto, essa visão logo é revertida quando se avalia os resultados que ela proporciona, garantindo a qualidade de software, aumentando a satisfação do cliente, reduzindo riscos e diminuindo os custos, consequentemente aumentando o lucro.

Fonte: Cacildo Grabowski
Diretor de Tecnologia da HBtec
cacildo@hbtec.com.br