1. INTRODUÇÃO

Após décadas de incontroláveis promessas sobre como aumentar a produtividade e a qualidade do software, as organizações chegaram à conclusão que o problemas principais eram a incapacidade e a inexperiência para gerenciar os processos de desenvolvimento de software. Em muitas organizações, os projetos não cumpriam os prazos planejados e os custos orçados, afetando os benefícios que o projeto traria. Como resposta para esse ambiente caótico, foram desenvolvidos normas e modelos de qualidade de software, como o propósito de melhorar o desenvolvimento de aplicações em organizações que trabalham com tais tecnologias.

Esse trabalho tem como objetivo mostrar a importância da adoção dessas normas e padrões de software na obtenção da qualidade dos processos e certificações de produtos. Além disso, será considerado as necessidades dos clientes, a qualidade do produto de software, a qualidade do processo de desenvolvimento e o nível de maturidade da organização. Será tomado com destaque os modelos CMM, TMM e TMMI.

2. HISTÓRICO

A Crise do Software foi termo utilizado nos anos de 1970 para expressar as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda do mesmo, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados. Projetos estourando o orçamento e o prazo, a baixa qualidade e o não cumprimento dos requisitos desejados eram problemas frequente dos sistemas encomendados pelo DoD - Departamento de Defesa dos Estados Unidos.

O modelo CMM surgiu durante a década de 1980, produzido pelo SEI (Instituto de Engenharia de Software) da Universidade Carnegie Mellon, em Pittsburgh, EUA, por um grupo de profissionais de software. Foi instituído como um modelo para avaliação de riscos 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. Em junho de 1987, ocorreu a liberação de uma breve descrição do modelo de maturidade de processo de software. Em setembro do mesmo ano, foi lançada uma versão preliminar do questionário de maturidade. Em agosto de 1991, foi entregue a versão 1.0 do SW-CMM, e quase dois anos depois, em fevereiro de 1993 foi divulgada a versão 1.1.

Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para demais áreas, como por exemplo, Gestão de Recursos Humanos (People-CMM), Aquisição de Software (SA-CMM) e Engenharia de Sistemas (SE-CMM). Entretanto, esses diversos modelos apresentavam estruturas, termos e formatos diferentes, dificultando sua aplicação conjunta. Como consequência dessa proliferação de modelos e padrões em diversas áreas, foi criado o CMMI, com a finalidade de integrar os diversos modelos CMM. Em agosto de 2000, foi criada a versão 1.0 e em novembro de 2010, a versão 1.3.

O TMMI nada mais é do que o complemento do CMMI. Seu objetivo deve ser usado de maneira semelhante ao CMM, ou seja, fornecer um quadro para a avaliação da maturidade dos processos de uma organização, e assim, proporcionar melhorias da maturidade. O TMMI veio da necessidade de se ter um processo evolutivo e bem definido de testes para as empresas já possuidoras do certificado CMMI (nível 2 ao 5), focando o objetivo dos testes na prevenção de defeitos e não na detecção deles.

3. PRINCIPAIS NORMAS DA SÉRIE E APLICABILIDADE

Com o objetivo de melhorar o desenvolvimento de aplicações em organizações que trabalham com tecnologias de software, o processo do CMM foi dividido em cinco níveis de desenvolvimento: Inicial, Repetível, Definido, Gerenciado e Otimizado. Esses cinco níveis proveem uma escala mensurável de maturidade, como também a capacidade e desempenho da organização. Como consequência, esses níveis ajudam a definir a prioridade dos esforços de uma organização de software, analisar os problemas dos processos e a qualidade dos produtos.

Conceitos Fundamentais sobre Processos de Maturidade

Um processo de software pode ser definido como um conjunto de atividades, métodos, práticas e mudanças que as pessoas devem utilizar para desenvolver e manter os produtos de software. Existem três tipos de análise sobre os processos de software:

1- Capacidade: analisa os resultados que podem ser atingidos com o uso de processos de software.

2- Desempenho: analisa o estágio atual dos processos de software os resultados obtidos pelo seu uso.

3- Maturidade: analisa como um processo específico está definido, gerenciado, mensurado, controlado e é efetivo, ou seja, implica em ter potencial para um crescimento consistente aplicando os processos de software em projetos na organização (uma organização ganha maturidade se institucionaliza os processos de software através de políticas, padrões e estrutura organizacional).

Características dos Níveis de Maturidade

Os processos devem ser continuamente aperfeiçoados através de evoluções progressivas. O CMM prevê uma estrutura para organizar os passos de melhoria dentro de cinco níveis de maturidade em processos de software dentro de uma organização. Esses cinco níveis definem uma escala para medir o estágio de maturidade de uma organização que utiliza processos de software.

Nível 1 - Inicial:

É o nível base, na qual as aplicações são desenvolvidas com métodos e práticas não consistentes. Os processos de desenvolvimento raramente são definidos e as práticas disponíveis são sacrificadas para atender a prazos e custos incorretamente definidos. Frequentemente, o gerenciamento de projetos é fraco e não protege o projeto de rupturas, carecendo de padrões e comprometimento consistente.

Nível 2 - Repetível:

Nesse nível é importante estabelecer um ambiente estável para se repetir práticas de sucesso. Foca no desenvolvimento de capacidades dos gerentes de projetos para planejar eficazmente e estabelecer um controle dos requisitos para os produtos de software. Para controlar os projetos, deve utilizar diferentes métodos e práticas e o ambiente deve ser estável, dentro de um cronograma.

As áreas de processos do nível 2 objetivam questões relacionadas ao estabelecimento de controles básicos de gerência do projeto. São elas:

- Gerência de Requisitos;

- Acompanhamento do Projeto;

- Gerência de Subcontratos;

- Garantia da Qualidade;

- Gerência de Configuração;

Nível 3 - Definição:

Após atingir o estágio de repetir as práticas de desenvolvimento com sucesso, as organizações de desenvolvimento de aplicações devem identificar as melhores práticas. Em sequência, esses procedimentos são integrados aos padrões de desenvolvimento de toda a organização. Como consequência, todos os projetos utilizam as melhores práticas e compartilham lições de aprendizagem, amadurecendo a organização.

As áreas de processos do nível 3 objetivam tanto questões organizacionais quanto questões de projeto. São elas:

- Foco no Processo da Organização;

- Definição do Processo da Organização;

- Programa de Treinamento;

- Gerenciamento Integrado do Software;

- Engenharia de Produto de Software;

- Coordenação entre Grupos;

- Revisões;

Nível 4 - Gerenciamento:

Após atingir o estágio de utilizar os processos comuns nos projetos de desenvolvimento de software, as organizações estão capacitadas a gerar estatísticas que possam caracterizar o desempenho de seus processos, gerando informações e possíveis variações. Dessa forma, uma organização pode prever e controlar os resultados dos projetos e melhorar a previsão dos resultados pelo gerenciamento de projetos.

No nível 4, são definidas as seguintes áreas de processos:

- Gerenciamento Quantitativo do Processo;

- Gerenciamento Qualitativo do Software;

Nível 5 - Otimização:

Melhorias contínuas podem ser desenvolvidas através das lições de aprendizagem de cada projeto durante a avaliação de novos métodos de desenvolvimento, novos processos ou tecnologias. Ou seja, esse nível estabelece uma infraestrutura para suportar contínuas mudanças no gerenciamento dos processos de desenvolvimento.

No nível 5, são definidas as seguintes áreas de processos:

- Prevenção de Defeitos;

- Gerenciamento de Mudanças Tecnológicas;

- Gerenciamento de Mudanças no Processo;

Assim como o CMMI, o TMMI também utiliza o conceito de níveis de maturidade para avaliação do processo e melhoria. Usando TMMI, as organizações podem melhorar os seus processos de testes e até mesmo ter um processo de teste quando se está em conformidade com os requisitos. As diferenças mais importantes entre TMMI e outros modelos de melhoria de testes são a independência, os cumprimentos das normas internacionais de testes, a orientação para as necessidades de negócio e a relação e complementaridade com o CMMI.

O TMMI tem uma arquitetura voltada para a melhoria dos processos. Ele contém níveis, através do qual uma organização mostra como o seu processo de testes evolui. Cada etapa alcançada garante que uma melhoria tem ocorrido e preparada para as próximas fases.

Há cinco níveis no TMMI que prescrevem uma hierarquia de maturidade e um caminho evolutivo para a melhoria do processo de teste. Cada nível tem um conjunto de áreas de processos que uma organização precisa implementar para alcançar a maturidade desejada.

Nível 1 - Inicial:

Os testes são caóticos, na qual não existe processo definido. O objetivo dos testes é simplesmente mostrar que o software funciona sem maiores falhas.

Nível 2 - Gerenciado:

Neste nível, é definido um processo, podendo haver estratégias de teste, planos de teste, casos de teste com base nos requisitos. O teste não pode começar até que os produtos estejam concluídos, já que o objetivo do teste é comparar produtos em relação aos requisitos.

No nível 2, são definidas as seguintes áreas de processos:

- Política de Teste e Estratégia;

- Planejamento de Teste;

- Acompanhamento e Controle de Teste;

- Teste de Projeto e Execução;

- Ambiente de Teste;

Nível 3 - Definido:

Neste nível, o teste está integrado num ciclo de vida do software. Planejamento dos testes acontece no estágio inicial dos projetos. Estratégias de testes é determinada através de técnicas de gerenciamento de riscos e baseada em requisitos.

No nível 3, são definidas as seguintes áreas de processos:

- Teste de Organização;

- Programa de Treinamento de Teste;

- Teste do Ciclo de Vida e Integração;

- Testes Não-Funcionais;

- Peer Reviews;

Nível 4 - Mensurado:

Os testes são completamente definidos, bem fundamentados e medidos. Revisões e inspeções são incorporadas ao ciclo de vida do desenvolvimento e consideradas parte dos testes. Os produtos de software são avaliados a partir de critérios de qualidade.

No nível 4, são definidas as seguintes áreas de processos:

- Medição Teste;

- Avaliação da Qualidade do Produto;

- Revisão em Pares Avançada;

Nível 5 - Otimizado:

Os resultados são arquivados com o objetivo de melhoramentos em estágios anteriores. Métodos e técnicas são otimizados e estão em melhoramento contínuo. Além disso, testar é um processo com o objetivo de prevenir defeitos

No nível 5, são definidas as seguintes áreas de processos:

- Prevenção de Defeitos;

- Controle de Qualidade;

- Processo de Teste de Otimização;

Em suma, a estrutura do TMMI é, em grande parte, baseada na estrutura do CMMI. Este é um grande benefício às organizações que já estão familiarizadas com a estrutura CMMI. Ambas fazem uma clara distinção entre as práticas que são necessárias (metas) ou recomendadas (práticas específicas) para implementar. Portanto, podemos perceber que assim como o CMMI, o TMM tem uma grande importância dentro da organização, principalmente no ciclo de desenvolvimento, permitindo que processos caóticos passem a serem mais bem gerenciados, contribuam para a prevenção de defeitos e garantam um efetivo e eficiente processo de testes.

4. FUNDAMENTAÇÃO

Criado em 1980, pelo Software Engineering Institute (SEI) à pedido do Governo Americano para avaliar fornecedores de software, o CMM evolui o modelo para englobar outras áreas, eis o CMMI. Atualmente, a SEI faz questão de não se restringir à área de desenvolvimento e, para isso, não menciona em seu modelo a palavra “software”.

O CMM possui uma estrutura que indica o caminho recomendado para as organizações melhorarem seus processos de desenvolvimento de software. Ou seja, foi desenhada para suportar as várias formas de uso. Existem pelo menos quatro usos destacados do CMM:

- Para identificar pontos fortes e fracos das organizações;

- Para identificar os riscos dentro de um processo de seleção de fornecedores e monitorar os resultados;

- Para que o alto nível gerencial de uma organização possa entender as atividades necessárias para o lançamento de um processo de software;

- Para que o pessoal técnico e dos grupos de processos possam melhorar os processos de software em suas organizações;

Em suma, as organizações devem trabalhar pensando em prazos longos para atingir os mais elevados níveis de maturidade, podendo levar muitos anos para construir uma fundação sólida e uma cultura orientada em melhorias contínuas. Porém, o CMM não apresenta todas as soluções para se obter sucesso nos projetos. Por exemplo, não cobre o conhecimento em domínios específicos de negócios, em critérios para definir uma tecnologia específica, em aspectos motivacionais de pessoal e retenção de talentos. Esses aspectos são cruciais para o sucesso de vários projetos, porém não estão integrados ao CMM.

Durante os próximos anos, o CMM continuará a ser desenvolvido e extensivamente testado para provar sua eficiência na melhoria dos processos de desenvolvimento de software.

A última versão do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 e apresenta três modelos:

· CMMI for Development (CMMI-DEV), voltado aos processos de desenvolvimento de produtos e serviços;

· CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização de bens e serviços;

· CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de serviços;

O CMMI é um modelo de maturidade para melhoria de processo, destinado ao desenvolvimento de produtos e serviços, e composto pelas melhores práticas associadas a atividades de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto, desde a concepção até a entrega e manutenção. Além do mais, o CMMI fundamenta-se teoricamente no gerenciamento de configuração (utilização de padrões), gerenciamento de mudança (mudanças de maneira controlada) e requisições de mudanças.

Complementar ao modelo CMMI, surgiu o TMMI, modelo detalhado para melhoria dos processos críticos de um desenvolvimento de software. Aborda especificamente as questões importantes para gerentes de testes, especialistas de testes e pessoal de garantia de qualidade de software.

5. RELAÇÃO COM A GESTÃO DA QUALIDADE

A gestão da qualidade pode ser definida como atividades que dirigem e controlam uma organização visando a melhoria dos produtos e serviços, garantindo, assim, de maneira satisfatória as necessidades dos clientes. A adoção de alguma certificação é o meio mais comum e difundido de comprovar a qualidade das organizações certificadas. Focalização no cliente, abordagem por processos e melhoria contínua são alguns princípios benéficos que as organizações geram para a obtenção dos padrões de desenvolvimento.

A indústria de software tem investido esforços consideráveis para melhorar a qualidade de seus produtos, o que tem sido uma tarefa difícil, já que o tamanho e a complexidade do software aumentam rapidamente, enquanto os clientes e usuários estão se tornando cada vez mais exigente.

Normas e modelos de qualidade de software foram desenvolvidos com o objetivo de melhorar o desenvolvimento de aplicações em organizações. O CMMI e o TMMI estão justamente na produção de software com essas características, maior qualidade e menos propenso a erros.

Essas técnicas focam a gestão da qualidade por meio da definição e normatização dos processos de desenvolvimento. Ou seja, pretendem garantir, através da avaliação de processos e testes, um produto final que satisfaça às expectativas dos clientes dentro daquilo que foi requisitado inicialmente.

6. ASPECTOS POSITIVOS E NEGATIVOS

Atender os objetivos e os propósitos dentro de padrões e parâmetros são necessidades das empresas atualmente. Isso, com o objetivo de que o ciclo de desenvolvimento ocorra de forma segura e conforme os requisitos.

O CMMI é quem dá as diretrizes e orientações para melhorar em todo o conjunto de desenvolvimento de software, desde o processo até a concepção do produto. Apesar do modelo contribuir bastante para o crescimento quantitativo e qualitativo de uma organização, encontra dentro dele diversos fatores que podem interferir ou dificultar a completa adesão ao modelo no desenvolvimento de processos dentro de uma organização.

Aspectos Positivos ou Benefícios:

Dentro dos aspectos positivos, será explorado os benefícios que a implementação do modelo CMM pode aprimorar dentro da empresa.

· Execução: maior excelência na execução de tarefas, melhor distribuição das atividades, melhor alocação dos recursos e, consequentemente, aumento da produtividade.

· Controle: melhor organização e controle dos projetos, maior precisão de custos e prazos, maior facilidade de atingir as metas e cumprimento das obrigações.

· Qualidade no produto: melhoria na qualidade do produto ou sistema, com uma melhor identificação dos requisitos do cliente.

· Relacionamento Interno: diminuição dos conflitos de interesses internos, não dependência ou sobrecarga de funcionários e incentivos financeiros para os envolvidos.

· Relacionamento Externo: maior conhecimento a nível nacional e internacional, ganhos em concorrências e melhor seleção dos fornecedores.

· Conhecimento: todos os envolvidos em projetos sabem exatamente o seu trabalho e como se relacionar com os demais.

· Entendimento: avaliação do trabalho em comparação com seus parceiros e concorrentes, conseguindo detalhar o desempenho dos processos.

· Posicionamento: empresa passa a ser vista como um fornecedor disciplinado, capacitado e confiável.

Aspectos Negativos ou Dificuldades:

Dentro dos aspecto negativos, será explorado os fatores que, de alguma forma, podem interferir na implementação da metodologia dentro da empresa.

· Incentivos: falta de incentivos financeiros, pressão dos clientes, fornecedores e da alta administração e expectativas muito elevadas.

· Estrutural: quanto ao porte da empresa, grau de formalidade e mudanças tecnológicas podem dificultar a adesão do modelo.

· Envolvimento: grau de envolvimento da alta administração e da gerência, comprometimento dos funcionários e rotatividade do pessoal.

· Custos e Prazos: grande orçamento e tempo investidos na implementação contrastam com a realidade das empresas brasileiras.

· Ignorância: respeita processos, porém ignora pessoas e não foca em problemas organizacionais internos.

7. EXEMPLOS DE EMPRESAS QUE FAZEM USO

Há mais de 5000 empresas que utilizam CMMI em mais de 70 países, incluindo os EUA, China, Alemanha, Itália, Chile, Índia, Austrália, Egito, Turquia e Rússia.

Uma visão das empresas que utilizam o CMMI é ilustrada através do perfil de maturidade. Esses perfis são publicados, pelo instituto CMMI, duas vezes por ano desde 2002, constando os resultados das avaliações das empresas que fazem uso da certificação, as tendências de adoção e quanto tempo levam para passar de um nível de maturidade para o outro.

Verificando a lista de todas as empresas certificadas CMMI do Brasil, encontramos 91 empresas, um número 25% menor do que em 2011. Em comparação com anos anteriores, houve uma grande diminuição do número de empresas brasileiras nos níveis 2 e 3, porém um pequeno aumento de empresas certificadas com os níveis 4 e 5.

Essa acentuada redução pode ser atribuída principalmente a 3 fatores: os custos, os prazos e o MPS.BR. O CMMI pode ser considerado caro e lento para pequenas empresas, pois mexe na área de desenvolvimento. Além disso, o MPS.BR (Melhoria de Processos do Software Brasileiro) é um modelo de qualidade de processo compatível com o CMMI, porém com custo reduzido, sendo ideal para micro, pequenas e médias empresas de desenvolvimento de software, a maioria das empresas brasileiras.

Nível de Maturidade das empresas certificadas CMMI no Brasil:

Exemplos de empresas certificadas CMMI no Brasil:

Nível 5:

· Critical Software SA;

· Everis;

· HP Enterprise Services;

· IBM;

· Spread Sistemas e Automação Ltda;

· Synapsis Brasil SA;

· Tata Consultancy Services Limited;

Nível 4:

· CPM Braxis SA;

Nível 3:

· BRQ Soluções em Informática SA;

· E-Governe;

· Geo System Informatica Ltda;

· Hildebrando do Brasil Serviços Tecnológicos;

· Indra Software Labs, SL;

· Softtek Tecnologia da Informação;

· TopDown Consultoria e Projetos Ltda;

Nível 2:

· E-core Treinamento e Consultoria em Informática Ltda;

· GSW Software;

· Kyros Consultoria;

· Neoway Tecnologia Integrada e Negócios Ltda;

· Procenge;

· Teclógica Serviços em Informática;

· Facilit;

8. COMPARATIVO COM NORMAS OU MODELOS SEMELHANTES

Como já comentado no capítulo anterior, houve uma diminuição de empresas brasileiras com certificação CMMI. A principal razão dessa queda foi a adoção do modelo MPS.BR (Melhoria de Processos do Software Brasileiro). Com o MPS.BR, foi possível estabelecer um caminho viável para que as organizações, principalmente as micro, pequenas e médias, alcancem os benefícios da melhoria de processos desenvolvidos no Brasil.

O MPS.BR é um modelo brasileiro como objetivo de impulsionar a capacidade de desenvolvimento de software nas empresas. Considerado um marco na evolução da qualidade de software do país, trouxe ganhos comprovados de competitividade para a indústria nacional. Compatível ao CMMI, leva em consideração normas e modelos internacionais reconhecidos, boas práticas de engenharia de software e as necessidades de negócio da indústria nacional.

As empresas mais bem sucedidas na área de desenvolvimento no mercado mundial possuem certificações CMMI com elevado nível de maturidade, tornando-se empresas altamente competitivas. Perante isso, surgiu o MPS.BR, a partir da necessidade de suprir a demanda das empresas nacionais, de maneira mais barata e rápida, e tornar as empresas brasileiras mais competitivas na área de desenvolvimento de software.

O modelo MPS.BR, diferentemente do modelo CMMI e do TMMI, possui 7 níveis de maturidade onde a implantação é mais gradual e adaptada a realidade das empresas brasileiras. Cada nível de maturidade possui suas áreas, onde são analisados os processos. À medida que a organização evolui nos níveis de maturidade, um nível de capacidade de desempenhar um processo deve ser atingido pela organização.

Vantagens do MPS.BR: O MPS.BR foi criado com o objetivo de ser um modelo de processo, que seja mais rápido e acessível do que os modelos CMMI, além de adequado a realidade brasileira. Além disso, tem uma implantação mais gradual e adequada a pequenas e médias empresas, e compatibilidade com o CMMI, facilitando a obtenção do certificado.

Desvantagens do MPS.BR: Apesar do foco ser um meio das médias e pequenas empresas alcançarem a qualidade nos processos e nos produtos desenvolvidos, servindo como uma alternativa ao CMMI, a certificação não é competitiva o suficiente para tornar a empresa competitiva internacionalmente.

Apesar dos dois modelos de desenvolvimento terem sidos criados com o mesmo propósito, o foco de atuação dos modelos são diferentes. Enquanto o MPS.BR é um modelo criado em função das pequenas e médias empresas, o CMMI tem um foco global, voltado principalmente para as empresas de grande porte. Apesar dessas diferenças, na realidade brasileira, os modelos são complementares, com o objetivo de alcançarem uma padronização e uma qualidade no processo. Uma vez alcançada a padronização, a empresa se encontra qualificada para tentar obter a certificação CMMI.