Qualidade De Software

INTRODUÇÃO

Na década de 1980, as empresas gastavam muito dinheiro com desenvolvimento de software que nunca eram disponibilizados, ou que eram disponibilizados tarde demais, e com pouco da funcionalidade esperada. Além disso, cada empresa tinha sua própria maneira de desenvolvimento, geralmente com pouca ou nenhuma participação do usuário neste processo, sendo baseado apenas em relações contratuais.

Dessa forma, foi necessário criar modelos de boas práticas para desenvolvimento de software de qualidade, e integralizar todo o processo, de maneira que suas fases não acontecessem de forma independente. Assim, apresentamos aqui dois destes modelos, o CMMI desenvolvido pelo Departamento de Defesa dos Estados Unidos, e o MPS/BR, desenvolvido pela Softex no Brasil. O principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.

CMMI

O CMMI (Capability Maturity Model - Integration ou Modelo de Maturidade em Capacitação - Integração) é um modelo de referência que contém práticas necessárias à maturidade em disciplinas específicas como Engenharia de Software ou de Sistemas. O CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. Segundo a Wikipedia, uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa".

O CMMI surgiu durante a década de 1980 como um modelo para avaliação de risco na contratação de empresas de software pelo Departamento de Defesa dos Estados Unidos que desejava ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados. Para desenvolver esse processo, o DOD constituiu junto a Carnegie-Mellon University o SEI (Software Engineering Institute), o qual além de ser responsável pela evolução da família CMM, realiza diversas outras pesquisas em engenharia de software.

O CMMI está, atualmente, na versão 1.3, mas de acordo com Breno Nunes, fundador do blog TI Inteligente, a sua primeira versão foi criada em 2000 e é uma integração de vários outros modelos que já existiam e que foram lançados desde 1993, como por exemplo:

● SW-CMM – Capability Maturity Model for Software (1993)

● SE – CMM – System Engineering CMM (1995)

● EIA 731 SECM – System Engineering Capability Model (muito utilizado na parte de construção de harwares) (1998).

Ainda segundo Breno, estes modelos, utilizados de forma isolada eram muito úteis, mas a implementação de vários modelos dentro de uma organização gerava um certo descontrole e desequilíbrio, uma vez que as diferenças entre eles limitavam, de forma significativa, a possibilidade das empresas focarem nas melhorias destes modelos. Por isso, um modelo integrado (CMMI) que pudesse abarcar várias disciplinas, com suporte para treinamento, avaliação e medição de resultados, poderia ter um efeito melhor na qualidade dos softwares desenvolvidos nas organizações.

O projeto do CMMI foi criado com dois objetivos distintos. O primeiro, de curto prazo, focava na integração de três modelos específicos: SW-CMM, SE-CMM e IPD-CMM (Integrated Product Development). O segundo objetivo, de mais longo prazo, focava na criação de uma base onde fosse possível agregar novas disciplinas ao CMMI.

O CMMI possui uma série de disciplinas, que vieram da evolução histórica deste modelo. As principais disciplinas são as seguintes:

ENGENHARIA DE SOFTWARE (SW) – Esta disciplina cobre a parte de desenvolvimento de software.

ENGENHARIA DE SISTEMAS (SE) –Esta disciplina cobre o desenvolvimento de sistemas completos, ou seja, a parte de software e hardware. Aliás, na verdade, sob esta ótica, os sistemas podem ou não incluir softwares, uma vez que esta disciplina preza pela transformação das necessidades e expectativas do cliente em soluções de produtos, que não obrigatoriamente são softwares. A engenharia de software é similar à engenharia de sistemas em relação às áreas de processo, apenas com enfoque diferente nos processos. As áreas de processo requeridas para engenharia de sistemas são as mesmas para engenharia de software, mas o nível de maturidade que é diferente.

DESENVOLVIMENTO INTEGRADO DE PRODUTO E PROCESSO (IPPD) – É uma disciplina que preza pela colaboração entre a equipe de desenvolvimento e de produção para satisfazer as expectativas dos clientes.

GESTÃO DE FORNECEDORES (SS) – Disciplina que cobre a parte de contratações críticas para o desenvolvimento de um determinado software.

Breno diz que na versão 1.2 O CMMI foi montado a partir do conceito de “constelação”. Uma constelação, na visão do CMMI, é o conjunto de áreas ou componentes relacionados entre si.

No CMMI versão 1.2 existem três diferentes constelações, a saber:

1 – CMMI PARA DESENVOLVIMENTO (CMMI-DEV) – Conjunto das seguintes disciplinas relacionadas: Engenharia de Software (SW), Engenharia de Sistemas (SE) e Gestão de Fornecedores (SS). Opcionalmente, também teríamos o CMMI-Dev + IPPD.

2 – CMMI PARA AQUISIÇÕES (CMMI-ACQ) – Adaptação do CMMI-Dev para empresas que contratam o desenvolvimento de software.

3 – CMMI PARA SERVIÇOS (CMMI-SVC) – Conjunto de disciplinas que vão além do desenvolvimento, gerenciando o fornecimento de serviços de qualquer natureza e não apenas de TI (por isso, não configura como um concorrente do ITIL).

A Wikipedia nos informa que o CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

REPRESENTAÇÃO CONTÍNUA

Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por: Níveis de Capacidade (Capability Levels):

Nível 0: Incompleto (Ad-hoc)

Nível 1: Executado

Nível 2: Gerenciado / Gerido

Nível 3: Definido