ABRIL/MAIO DE 2002 NÚMERO 36 ANO 3 Capa | Saúde Geral | Contato >> Seções --------------------------------- Sala de Espera Editorial Saúde Geral Cursos e Congressos Crônicas Médicas

Avaliação de contratação de software com qualidade

O processo de garantia da qualidade no desenvolvimento de software, obtendo elevada produtividade, dentro dos prazos estabelecidos e com os recursos estimados, têm sido o grande desafio dentro das organizações desenvolvedoras de software. Esse assunto teve o início de sua discussão na década de 70. Porém, somente na de 90 é que foi dada a real importância ao assunto e ele se tornou o principal foco da comunidade de desenvolvedores e clientes de produtos de software.

Conhecer os processos de desenvolvimento de software significa conhecer como os produtos serão planejados, produzidos e entregues, ou seja, melhorar o processo de desenvolvimento e de garantia da qualidade. Mas, no caso da área da saúde, que se encontra em franco processo de informatização de suas áreas clínicas e de gestão, tem-se a aplicação na avaliação dos riscos de contratação de projetos de software, que é outra aplicação da metodologia.

O surgimento dessa metodologia de desenvolvimento pode ser utilizada pelos gestores de saúde na busca da avaliação dos produtos de software a serem adquiridos ou, em outras situações, até mesmo dos produtos já contratados. Para tal, conforme será descrito abaixo, existem áreas que devem ser avaliadas no momento do desenvolvimento ou aquisição dos produtos, utilizando-se de entrevistas, visitas e revisões de documentos pertencentes à metodologia. Por meio dessas avaliações temos a verificação da satisfação ou não dos requisitos do modelo associado à metodologia, denominado de laudo.

Esses processos, por sua vez, passam por diversas áreas de uma empresa desenvolvedora ou área de desenvolvimento de software. Para que se tenha assegurado esse desenvolvimento qualitativo é que algumas organizações tiveram a necessidade de desenvolver um processo documentado e formalizado. O SEI (Software Engineering Institute - Carnegie Mellon University - USA) procurou desenvolver uma metodologia que garantisse a qualidade nos processos de produção de softwares. Essa metodologia aplica-se tanto a grandes corporações como em pequenas empresas desenvolvedoras de software. Também preocupado com sua escalabilidade é que o SEI-CMU desenvolveu uma metodologia que fosse o mais abrangente e de fácil adaptação, dependendo da complexidade da organização e do produto a ser gerado.

A maioria dos profissionais das organizações desenvolvedoras de software (gerentes, desenvolvedores, analistas) e das "consumidoras" (gestores, diretores e operacionais) sabem, ou já tiveram a experiência, de que uma das principais causas dos problemas de desenvolvimento de software é a desorganização do processo e a inexistência de padrões documentados, visando o desenvolvimento e a manutenção de software.

Na pretensão de auxiliar as organizações a terem processos devidamente documentados, definidos e sincronizados (dentro do ciclo de desenvolvimento de software) é que o CMM - Capability Maturity Model (Modelo da Maturidade da Capacitação no Desenvolvimento de Software) vem colaborar. O CMM propõe uma evolução da organização por meio de níveis de maturidade da capacitação. E, principalmente sobre estes níveis, podemos obter artefatos de conformidade com a qualidade a ser obtida ou comprovada.

Evolução

A metodologia Capability Maturity Model (CMM) preocupa-se com a qualidade do produto a ser desenvolvido nas organizações produtoras de software. O CMM descreve os estágios através dos quais as organizações de software evoluem quando elas definem, implementam, medem, controlam e melhoram seus processos de software. Essa evolução passa a diferenciar as organizações maduras das demais. A definição do que é "maturidade" pode ser mais bem compreendido pela análise do quadro abaixo:

O CMM provê e descreve um caminho de melhoria evolutiva a partir de um processo ad hoc para um processo maduro e altamente disciplinado. Essa melhoria é definida por um modelo de cinco níveis, priorizando de forma lógica as ações a serem realizadas. Quanto maior o nível, maior a maturidade da organização, o que se traduz em maior qualidade do produto final, prazos e custos mais baixos e maior previsibilidade em cronogramas e orçamentos. Os níveis são:

No nível 1, chamado de Inicial, o desenvolvimento é caótico. O processo de desenvolvimento de software não está documentado, não existem procedimentos padronizados, estimativas de custos, planos de projeto e não há mecanismos de controle que permitam ao gerente saber o que está acontecendo, identificar problemas e riscos e agir de acordo. Esse nível é caracterizado com processo ad hoc.

Para passar ao nível 2, a organização deve instituir controles básicos de projeto, incluindo o Gerenciamento de Requisitos e de Projetos, Controle Gerencial, a instituição de um Grupo de Garantia de Qualidade e de procedimentos básicos de Gerenciamento de Configuração. Ao chegar ao nível 2, chamado Repetível, a organização está em condições de ter maior controle sobre seus projetos, e pode-se esperar que as estimativas sejam mais precisas, visto estarem baseadas em projetos anteriores e a qualidade do software produzido seja maior. Os processos no nível 2 são caracterizados como disciplinados porque o planejamento e acompanhamento do projeto de softwares estão estáveis, permitindo desenvolvimentos bem sucedidos.

Para passar ao nível 3, Definido, é necessário introduzir uma metodologia de desenvolvimento formal padronizada, com um ciclo de vida definido, acompanhado de métodos, técnicas e ferramentas apropriados, como inspeções e técnicas de teste. No nível 3, entretanto, os controles ainda são basicamente qualitativos, não havendo meios de quantificar a qualidade dos produtos e a eficiência do processo. Assim, a empresa deve estabelecer métricas de forma a medir características específicas dos produtos. A forma de coletar, armazenar e analisar esses dados é definida e com base nessa informação pode-se sugerir melhorias específicas nos produtos. Nesse ponto, a empresa estará no nível 4, ou Gerenciado.

Para subir do nível Gerenciado para o último nível, o de Em Otimização, deve-se estabelecer meios para a coleta automática de métricas e para a utilização da informação coletada de forma a prevenir problemas. A idéia é analisar as causas do problema e atacá-las para evitar que voltem a ocorrer. Enquanto os dados coletados no nível 4 podem informar, por exemplo, quantos erros existem em um programa, a preocupação no nível 5 é melhorar o processo para evitar que tais erros aconteçam no próximo projeto. Nesse último nível, a capacitação do processo de software pode ser caracterizada como sendo de melhoria contínua, pois as organizações estão continuamente se empenhando para melhorar a capacitação do processo de desenvolvimento de software.