Processos de Desenvolvimento de Software

Graças a uma norma da comunidade européia de desenvolvimento de software para equipamentos médicos (ANSI/AAMI/IEC 62304:2006) estamos revendo o processo de desenvolvimento de software na empresa que eu trabalho atualmente (Dixtal Biomédica).

Esta norma define um processo de desenvolvimento de software muito bem, inclusive teremos que levantar algumas evidências a mais do que fazemos atualmente pelo que estudei da norma. Com as etapas passando por planejamento, depois análise de requisitos, design de arquitetura, design detalhado, implementação, integração e verificações, validação do sistema e liberação. Todas estas etapas, necessariamente nesta ordem.

Mas a minha intenção ao escrever era de comparar este processo com outros padrões bem estabelecidos de desenvolvimento de software que existem por ai, como o CMMI e o MPS-BR. O CMMI tem níveis de maturidade que variam do nível 1 (menos maduro) até o 5 (mais maduro). Estes estágios ficam bem diferenciados assim:
- Realização – Estágio inicial;
- Gerenciado – Gerenciamento de requisitos, planejamento de projeto, monitoramento e controle de projeto, gerenciamento de fornecedores, medição e análise, garantia da qualidade do processo e do produto, gerenciamento de configuração;
- Definido – Desenvolvimento de requisitos, solução técnica, integração do produto, verificação e validação, foco no processo organizacional, definição do processo organizacional, treinamento organizacional, gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução;
- Quantitativamente – Gerenciamento quantitativo do projeto, performance do processo organizacional;
- Otimização – Análise causal e resolução, inovação organizacional e implantação.
Comparando estes níveis de maturidade com o nível mínimo de processo que a norma IEC 62304 exige, acredito que sairemos no fim deste ano com uma equivalência de processos muito próxima ao que é exigido no nível 3, porque não fazemos uso de métricas detalhadas e a parte quantitativa é um pouco pior que o exigido neste nível de maturidade realmente. Também acredito que o nível 5 de otimização não é algo tão distante do que o que procuramos fazer aqui. Mas como não fazemos isso com a quantidade de evidências e mensurações necessárias para o CMMI, mesmo que pudesse atingir o nível 5 pulando o nível 4 (não pode fazer isso, você só pode alcançar um nível de maturidade maior se tiver os anteriores) não atingiríamos este estado de processos em melhoria contínua.

Mas não estou dizendo que se pagarmos o preço, qualquer auditoria já nos promoveria automaticamente. Provavelmente há algum rigor extra em alguns dos quesitos que acredito que cumprimos, como o fato de a empresa que trabalho não ter uma equipe dedicada a testes. Mesmo assim, acabamos fazendo validação com equipes trocadas que acaba ajudando a cumprir esta parte da norma também, de que quem desenvolve o produto não pode atestar que está funcionando.

Para não ficarmos só com o utópico, porque não vejo muitas necessidades de a Dixtal pagar para ter uma certificação destas atualmente, resolvi também comparar com o MPS-BR. Que foi criado exatamente por isso. Algumas empresas brasileiras precisavam exigir um nível mínimo de qualidade (é pra isso que serve ser atestado como um nível de maturidade de desenvolvimento maior no CMMI) e para empresas menores este custo de implantar o CMMI era bastante proibitivo. A última vez que conferi os valores, ele circulava na faixa de R$ 300 mil a R$ 400 mil por ter que importar auditores. Então o modelo brasileiro, com certificação emitida por auditorias nacionais acaba tendo um preço mais acessível e foi definido de forma muito parecida que o primo rico. Mas ele conta com 7 níveis de maturidade e os níveis são decrescentes no lugar de crescentes. Vai do nível G (pior) para o nível A (melhor). Então se precisarmos criar um outro nível depois do estado de otimização contínua, acho que vamos ter que deslocar os rankings de todas as empresas... De qualquer forma, eles significam:
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.

Neste processo eu confesso que tive um pouco de dificuldades de fazer a conversão do nível de maturidade que imagino para a Dixtal. Se no CMMI eu a considerei com processos definidos, tenho praticamente 3 níves (de E até C) que são mais ou menos a mesma correspondência. Precisei recorrer a um nível de detalhamento maior dos níveis de maturidade.

Nível G - Parcialmente Gerenciado
Processo: Gerência do Projeto - GPR
Processo: Gerência de Requisitos - GRE Nível

F – Gerenciado
Processo: Aquisição - AQU
Processo: Gerência de Configuração - GCO
Processo: Garantia da Qualidade - GQA
Processo: Medição - MED

Nivel E - Parcialmente Definido
Processo: Adaptação do Processo para Gerência do Projeto - APG
Processo: Avaliação e Melhoria do Processo Organizacional - AMP
Processo: Definição do Processo Organizacional - DFP
Processo: Treinamento - TRE

Nível D - Largamente Definido
Processo: Desenvolvimento de Requisitos - DRE
Processo: Integração do Produto - ITP
Processo: Solução Técnica - STE
Processo: Validação - VAL
Processo: Verificação - VER

Nível C – Definido
Processo: Análise de Decisão e Resolução - ADR
Processo: Gerência de Riscos - GRI

Nível B - Gerenciado Quantitativamente
Processo: Desempenho do Processo Organizacional - DEP
Processo: Gerência Quantitativa do Projeto - GQP

Nível A - Em Otimização
Processo: Implantação de Inovações na Organização - IIO
Processo: Análise de Causas e Resolução- ARC

Neste caso, acho que fico com o nível G! Brincadeira. É que a gerência de Requisitos é uma das coisas que estamos melhorando muito agora e é um pré-requisito para se começar a brincar nos níveis de maturidade do MPS-BR. Mas voltando a diferenciação dos três níveis de maturidade que eu queria separar, acredito que já chegaremos ao "nível C - Definido" até o fim do ano, realmente. É muito complicado um setor de equipamentos hospitalares não cuidar da Gestão de Risco...