Unidade II - Qualidade de Processos (1)

Prévia do material em texto

*
Unidade 2: Qualidade de Processos
Qualidade de Software
* 
“O gerenciamento de qualidade fornece uma verificação independente sobre o processo de desenvolvimento de software. Ele deve ser separado do gerenciamento de projeto, para que a qualidade não seja comprometida pelas responsabilidades de gerenciamento relacionadas a prazos e orçamentos. A equipe de qualidade não deve ficar associada à um grupo específico de desenvolvimento, mas sim assumir um compromisso pela qualidade na organização. Os procedimento de garantia de qualidade devem ser documentados em um manual que define o processo de qualidade” (SOMMERVILLE, 2008).
Para Sommerville (2008) o gerenciamento de qualidade de software pode ser dividido em ter atividades principais:
	Garantia de qualidade que consiste em estabelecer procedimentos e padrões que conduzam ao desenvolvimento de software de alta qualidade.
	Planejamento de qualidade selecionar os procedimentos e padrões adequados e adaptá-los a um projeto de software específico o que vai de encontro com recomendações do PMBOK (2008).
	Controle de qualidade definir e aprovar processos que garantam que os procedimentos e padrões de qualidade sejam seguidos.
* 
Evidentemente deve haver um esforço para melhorar as especificações, mas devemos aceitar que elas serão imperfeitas. Devem-se reconhecer os problemas com as especificações impostas e adotar técnicas para melhorar sua qualidade dentro das restrições impostas. Atributos de software como facilidade de manutenção, portabilidade ou eficiência podem ser fundamentais, mas que não são especificados explicitamente, entretanto podem afetar a qualidade percebida do sistema (SOMMERVILLE, 2008). Para Bezerra (2006) algumas das formas de se medir a qualidade de um sistema de software é através de seu desempenho, sua confiabilidade e da utilidade do mesmo.
Nesse sentido cabe aos gerentes de projeto garantir que o nível de qualidade seja atingido. Definir procedimentos e padrões, e garantir que eles sejam seguidos, já são um bom começo, mas não é o suficiente. Gerentes de qualidade reconhecem que existem aspectos intangíveis de qualidade que não se encaixam em padrões. Além disso, é importante criar uma “cultura da qualidade” na qual todos se comprometam a atingir um alto nível de qualidade (SOMMERVILLE, 2008).
* 
Garantia e Padrões de Qualidade
As atividades de garantia de qualidade definem uma estrutura para atingir a qualidade de software. O que envolve definir ou selecionar os padrões a serem aplicados no desenvolvimento de um produto de software. Sommerville (2008) estabelece dois tipos de padrões que podem ser estabelecidos como parte do processo de garantia de qualidade:
	Padrões de produto se aplicam ao produto de software em desenvolvimento. Podem incluir padrões de documentos, padrões de documentação e padrões de codificação. Aplicam-se as saídas do processo de software.
	Padrões de processo definem os processos a serem seguidos durante o desenvolvimento do software. Podem incluir definições de especificação, processos de projeto e validação e uma descrição dos documentos a serem gerados no curso de desenvolvimento. Além disso asseguram que os padrões de produto sejam seguidos.
* 
Sommerville (2008) enumera uma série de motivos pelos quais os padrões de software são importantes:
	Envolvem as práticas mais adequadas. Adquire-se mais conhecimento através de erros e acertos o que evita que os erros se repitam no futuro. Registram a sabedoria que tem valor para a organização.
	Fornecem uma infraestrutura em torno da qual o processo de garantia de qualidade pode ser implementado.
	Reduzem o esforço de aprendizados quando um novato entra na equipe e garante que todos adotem as mesmas praticas.
Desenvolver padrões de projeto de Engenharia de Software é difícil e demorado. Equipes de garantia de qualidade que estejam desenvolvendo seus padrões de projeto de Engenharia de Software deverão se basear em padrões nacionais, internacionais e organizacionais. Com base nesses padrões a equipe de garantia de qualidade deve elaborar um manual de padrões, adaptado às necessidades apropriadas a sua organização.
Entretanto, não raramente engenheiros de software julgam esses padrões não são necessariamente apropriados a um projeto em particular. Segundo Sommerville (2008) para evitar esses problemas engenheiros de qualidade que estabelecem os padrões precisam seguir as seguintes etapas:
Envolver os engenheiros de software no desenvolvimento de padrões e fazer com que compreendam e se comprometam com eles. Revisar e modificar regularmente os padrões para que eles reflitam as constantes evoluções tecnológicas. Fornecer ferramentas de software que apoiem a adoção dos padrões. Nesse sentido criar padrões de documentação é uma boa solução e facilita a comunicação entre membros da equipe de desenvolvimento e os clientes.
* 
Qualidade de Produto e Qualidade de Processo
A qualidade do processo de desenvolvimento afeta diretamente a qualidade dos produtos fornecidos. Isto se deve ao fato de a qualidade de produto estar diretamente relacionada ao processo de produção. É difícil medir atributos de software sem utilizá-lo por um longo período. Os processos por sua vez são relativamente simples de monitorar e padronizar. A melhoria de qualidade focaliza então a identificação de produtos de boa qualidade e nos processos utilizados no seu desenvolvimento. Entretanto, devido a complexidade entre produtos de software e os processos de software, uma mudança no processo não necessariamente conduz a melhoria da qualidade.
O software não é um produto manufaturado, mas projetado. Seu desenvolvimento é um processo criativo e não mecânico tornando-o significativamente influenciado por habilidades, experiências individuais e fatores externos que afetam diretamente na sua qualidade (SOMMERVILLE, 2008).
* 
Produto de Software 
Quando entregamos a um cliente um pacote bem delimitado e identificado, podemos dizer que entregamos um produto. 
A definição para produto de software é: “O conjunto completo, ou qualquer dos itens individuais do conjunto, de programas de computador, procedimentos, e documentação associada e dados designados para liberação para um cliente ou usuário final”.
* 
Processo de Software 
O conceito de processo de software se baseia no conceito generalizado de processo, que pode ser definido como uma sequência de estados de um sistema que se transforma.
O SEI (Software Engineering Institute), da Carnegie Melon University propõe o seguinte [SEI]:
“Um processo é uma sequência de passos realizados para um dado propósito. Colocado de maneira mais simples, processo é aquilo que você faz. Processo é aquilo que as pessoas fazem, usando procedimentos, métodos, ferramentas, e equipamentos, para transformar matéria prima (entradas) em produto (saída) que tenha valor para o cliente”.
“O processo de software pode ser definido como um conjunto de atividades, métodos, práticas, e transformações que as pessoas empregam para desenvolver e manter software e os produtos associados (ex. planos de projeto, documentos de projeto (design), código, casos de teste, e manual do usuário)”.
Razões para a definição de um processo padrão:
	Redução dos problemas relacionados a treinamento, revisões e suporte à ferramentas;
	As experiências adquiridas nos projetos são incorporadas ao processo padrão e contribuem para melhorias em todos os processos definidos;
	Economia de tempo e esforço na definição de novos processos adequados a projetos.
* 
As principais fases de um processo de software são :
Especificação de Requisitos: tradução da necessidade ou requisito operacional para uma descrição da funcionalidade a ser executada.
Projeto de Sistema: tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema.
Programação (Codificação): produção do código que controla o sistema e realiza a computação e lógica envolvida.
Verificação e Integração (Verificação): verificação da satisfação dos requisitos iniciaispelo produto produzido.
Ao contrário do que possa parecer não existe uma sequência obrigatória de fases, sendo que diversos autores apontam a natureza não simultânea das fases como uma realidade na aplicação de processos de software, e também defendem que o processo de software é muito mais iterativo e cíclico do que a ideia de fases simples pode sugerir.
* 
Atividades do Processo de Software
Em cada fase de um processo de software definido são executadas as atividades básicas para que sejam atingidos os objetivos propostos. Segundo Pressman estas atividades constituem um conjunto mínimo para se obter um produto de software.
Realizando uma combinação de classificações dadas por Schwartz , Pressman e Sommerville, podemos identificar as seguintes atividades:
* 
 Projeto
Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes.
Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida.
Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudocódigo.
 Implementação
Codificação: a implementação em si do sistema em uma linguagem de computador.
 Validação
Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema.
Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto.
 Manutenção e Evolução
Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.
Desta forma as atividades relacionadas a um processo de software estão diretamente vinculadas com a produção do software como produto final . Afim de especificar quais atividades devem ser executadas e em qual ordem temos diversos modelos de desenvolvimento de software.
* 
A Qualidade dos Processos de Software 
Os resultados obtidos nas pesquisas diretas realizadas revelam um crescente aumento nos níveis de conhecimento e adoção de normas e modelos apropriados à definição, avaliação ou melhoria dos processos de software das organizações, indicando tendência de melhoria contínua na evolução dos indicadores de gestão pela qualidade nas empresas de software no Brasil, que procuram atender exigências cada vez maiores de clientes e usuários
Normas e padrões de qualidade de processo de software foram criados para auxiliar na obtenção de qualidade do produto de software, pois é através da melhoria do processo de software que é obtida a qualidade do produto.
Inicialmente, vamos encontrar um grande problema: 
Muitas pessoas acham que criar programas é uma arte que não pode seguir regras, normas ou padrões. 
Isto acontece principalmente porque: 
Produtos de software são complexos, até mais do que o hardware onde executam; 
Software não tem produção em série. Seu custo está no projeto e desenvolvimento; 
Software não se desgasta e nem de modifica com o uso;
Software é invisível. Sua representação em gráficos e diagramas não é precisa;
A Engenharia de Software ainda não está madura, é uma tecnologia em evolução; 
Não há um acordo entre os profissionais da área sobre o que é Qualidade de Software.
* 
Atualmente, muitas instituições se preocupam em criar normas para permitir a correta avaliação de qualidade tanto de produtos de software quanto de processos de desenvolvimento de software. Apenas para ter uma visão geral, observe o quadro 2, com as principais normas nacionais e internacionais nesta área: 
* 
Qualidade de Produto de software
A incessante busca pela qualidade no desenvolvimento de software não deve ficar restrita a questões de ordem técnica, como prototipagem, realização de testes de estresse ou execução, etc. Embora também envolva esses fatores, alcançar a tão sonhada excelência no desenvolvimento e preencher as necessidades dos clientes envolve assegurar conformidade de processos, utilização de metodologias ágeis de desenvolvimento, cumprimento do escopo, prazo e custos por meio de um fluxo de trabalho integrado e otimizado (contando com o auxílio de automatizações, sempre que possível), além, é claro, da melhoria na qualidade da informação que transita na empresa e do treinamento de pessoal. Tudo isso exige um sólido processo de benchmarking competitivo, mensuração de indicadores e análise de desempenho individual e coletivo.
Quando se pensa em qualidade de um "produto físico", é fácil imaginar padrões de comparação, provavelmente ligado às dimensões do produto ou alguma outra característica física. Quando se trata de software, como podemos definir exatamente o que é a qualidade?
Felizmente, para nós, a ISO (Organização Internacional de Padrões) já pensou bastante sobre o assunto. O suficiente para publicar uma norma que representa a atual padronização mundial para a qualidade de produtos de software. Esta norma chama-se ISO/IEC 9126 e foi publicada em 1991. Ela é uma das mais antigas da área de qualidade de software e já possui sua tradução para o Brasil, publicada em agosto de 1996 como NBR 13596.
IEC significa International Engineering Consortium. É uma organização voltada para o aprimoramento da indústria da informação.
* 
Bem, estas normas listam o conjunto de características que devem ser verificadas em um software para que ele seja considerado um "software de qualidade". São seis grandes grupos de características, cada dividido em algumas subcaracterísticas. Os nomes dados pelo ISO/IEC para as características e subcaracterísticas são um pouco complexos (para dizer a verdade, acho até que os próprios termos "características" e "subcaracterísticas" são mais complexos que o necessário). Entretanto, uma pessoa que trabalha com software não terá dificuldade em entendê-las. Observe no quadro 3 a lista completa: 
* 
* 
A avaliação do produto de software é um dos processos no ciclo de vida de desenvolvimento de software. A qualidade do produto de software pode ser avaliada pela medição dos atributos internos (tipicamente medidas estáticas de produtos intermediários), ou pela medição dos atributos externos (tipicamente medidas do comportamento do código quando executado), ou pela medição dos atributos de qualidade em uso. O objetivo é que o produto tenha o efeito desejado em um contexto particular de uso 
* 
A qualidade do processo contribui para a melhoria da qualidade do produto, que, por sua vez, contribui para a melhoria da qualidade em uso. Então, a avaliação e melhoria de um processo é um meio para melhorar a qualidade do produto, e a avaliação e melhoria da qualidade do produto é um meio de melhorar a qualidade em uso. Similarmente, a avaliação da qualidade em uso pode dar um feedback para melhorar o produto, e a avaliação da qualidade do produto pode dar feedback para melhorar o processo. A qualidade do processo contribui para a melhoria da qualidade do produto, que, por sua vez, contribui para a melhoria da qualidade em uso. Então, a avaliação e melhoria de um processo é um meio para melhorar a qualidade do produto, e a avaliação e melhoria da qualidade do produto é um meio de melhorar a qualidade em uso. Similarmente, a avaliação da qualidade em uso pode dar um feedback para melhorar o produto, e a avaliação da qualidade do produto pode dar feedback para melhorar o processo. 
Atributos internos adequados do software são um pré-requisito para alcançar o comportamento externo desejado, que por sua vez, é um pré-requisito para alcançar a qualidade em uso. Os requisitos de qualidade do produto de software geralmente incluem critérios de avaliação para qualidade interna, qualidade externa e qualidade em uso, para corresponder às necessidades dos desenvolvedores e usuários finais.
As visões de qualidade interna, qualidade externa e qualidade em uso mudam durante o ciclo de vida do software. Como exemplo, os requisitos de qualidade no início do ciclo de vida são normalmente vistos do ponto de vista do usuário (externo), e difere da qualidade do produtointermediário, tal como a qualidade do projeto, que é geralmente vista do ponto de vista do desenvolvedor (interno). As tecnologias usadas para alcançar o nível de qualidade necessário, assim como especificações e avaliações de qualidade, precisam apoiar tanto o ponto de vista dos usuários quanto o dos desenvolvedores. É necessário definir estas perspectivas e as tecnologias associadas à qualidade para gerenciar a qualidade em cada estágio do ciclo de vida. 
* 
Usabilidade segundo a norma ISO 9241 - Ergonomia de software de escritório
Pela definição da International Organization for Standardization, usabilidade é a medida pela qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com efetividade, eficiência e satisfação em um contexto de uso específico (ISO 9241-11).
Medida, aqui, deve ser entendida como valores resultantes de uma medição e os processos utilizados para se obter aqueles valores.
A efetividade permite que o usuário alcance os objetivos iniciais de interação, e tanto é avaliada em termos de finalização de uma tarefa quanto também em termos de qualidade do resultado obtido.
Eficiência se refere à quantidade de esforço e recursos necessários para se chegar a um determinado objetivo. Os desvios que o usuário faz durante a interação e a quantidade de erros cometidos pode servir para avaliar o nível de eficiência do site.
A terceira medida de usabilidade, a satisfação, é a mais difícil de medir e quantificar, pois, está relacionada com fatores subjetivos. De maneira geral, satisfação se refere ao nível de conforto que o usuário sente ao utilizar a interface e qual a aceitação como maneira de alcançar seus objetivos ao navegar no site.
* 
Segundo a norma citada acima (parte 11 da norma ISO 9241) a usabilidade pode ser especificada ou medida segundo outras perspectivas, como por exemplo:
	 Facilidade de aprendizado - o usuário rapidamente consegue explorar o sistema e realizar suas tarefas;
	 Facilidade de memorização - após um certo período sem utilizá-lo, o usuário não frequente é capaz de retornar ao sistema e realizar suas tarefas sem a necessidade de reaprender como interagir com ele;
	 Baixa taxa de erros - o usuário realiza suas tarefas sem maiores transtornos e é capaz de recuperar erros, caso ocorram;
os critérios de medição da característica de usabilidade estabelecidos pela norma ISO 9241 reflete na:
	análise das características requeridas do produto num contexto de uso específico;
	análise do processo de interação entre usuário e produto;
	análise da eficiência (agilidade na viabilização do trabalho), da eficácia (garantia da obtenção dos resultados desejados) e da satisfação resultante do uso desse produto.
* 
Norma ISO 13407 - Projeto centrado no usuário
O paradigma de desenvolvimento de uma interface com o usuário, deve permitir a realização de sucessivos ciclos de "análise/concepção/testes", com a necessária retroalimentação dos resultados dos testes, de um ciclo a outro. A estratégia consiste em, a cada ciclo, identificar e refinar continuamente o conhecimento sobre o contexto de uso do sistema e as exigências em termos de usabilidade da interface. Na sequência dos ciclos se constroem versões intermediárias da interface do sistema que são submetidas a testes de uso, em que os representantes dos usuários simulam a realização de suas tarefas. Inicialmente eles participarão de simulações "grosseiras", usando maquetes, mas, com o avanço do desenvolvimento, eles recorrerão a protótipos e versões acabadas do sistema, em simulações mais e mais fidedignas. O objetivo é avaliar a qualidade das interações e levar em conta os resultados dessas avaliações para a construção de novas versões das interfaces. Se implementada desde cedo no desenvolvimento, tal estratégia pode reduzir o risco de falhas conceituais do projeto, garantindo que, a cada ciclo, o sistema responda cada vez melhor às expectativas e necessidades dos usuários em suas tarefas. (Cybis, Betiol & Faust, 2007).
* 
ISO 9126 e ISO 25010 – Qualidade de produto de software
ISO/IEC 9126 é uma norma ISO para qualidade de produto de software. Ela define um conjunto de parâmetros com o objetivo de padronizar a avaliação da qualidade de software. Ela se enquadra no modelo de qualidade das normas da família 9000. A norma brasileira correspondente é a NBR 13596, que foi substituída pela NBR ISO/IEC 9126-1.
Foi substituída pela Norma ISO/IEC 25010:2011.
A norma ISO/IEC 9126, ou conjunto de normas que tratam deste assunto no âmbito da ISO, estabelece um modelo de qualidade com os seguintes componentes:
 Processo de desenvolvimento, cuja qualidade afeta a qualidade do produto de software gerado e é influenciado pela natureza do produto desenvolvido;
 Produto, compreendendo os atributos de qualidade do produto (sistema) de software. Estes atributos de qualidade podem ser divididos entre atributos internos e externos. Estes se diferenciam pela forma como são aferidos (interna ou externamente ao produto de software) e em conjunto compõem a qualidade do produto de software em si;
 Qualidade em uso que consiste na aferição da qualidade do software em cada contexto específico de usuário. Esta é, também, a qualidade percebida pelo usuário.
* 
A norma ISO 9126 foca na qualidade do produto de software, propondo Atributos de Qualidade, distribuídos em seis características principais, com cada uma delas divididas em sub-características, conforme podemos ver na figura abaixo:
No nível mais alto temos as características de qualidade e nos quadros abaixo as suas sub-características. Cada característica/sub-característica compõe um Atributo de Qualidade do software. Note que em todas as características temos uma subcategoria com o nome de Conformidade. A conformidade é utilizada para avaliar o quanto o software obedece aos requisitos de legislação e todo o tipo de padronização ou normalização aplicável ao contexto.
* 
Funcionalidade
A capacidade de um software prover funcionalidades que satisfaçam o usuário em suas necessidades declaradas e implícitas, dentro de um determinado contexto de uso.
Suas sub-características são:
 Adequação, que mede o quanto o conjunto de funcionalidades é adequado às necessidades do usuário;
 Acurácia (ou precisão) representa a capacidade do software de fornecer resultados precisos ou com a precisão dentro do que foi acordado/solicitado;
 Interoperabilidade que trata da maneira como o software interage com outro(s) sistema(s) especificados;
 Segurança mede a capacidade do sistema de proteger as informações do usuário e fornecê-las apenas (e sempre) às pessoas autorizadas. Segurança também pode estar dirigida em, processar gerar e armazenar as informações;
 Conformidade trata da padronização, políticas e normas de um projeto.
* 
Confiabilidade
O produto se mantém no nível de desempenho nas condições estabelecidas.
Suas sub-características são:
	 Maturidade, entendida como sendo a capacidade do software em evitar falhas decorrentes de defeitos no software;
	 Tolerância a Falhas representando a capacidade do software em manter o funcionamento adequado mesmo quando ocorrem defeitos nele ou nas suas interfaces externas;
	 Recuperabilidade que foca na capacidade de um software se recuperar após uma falha, restabelecendo seus níveis de desempenho e recuperando os seus dados;
	 Conformidade tempo ou utilização de recursos.
* 
Usabilidade
A capacidade do produto de software ser compreendido, seu funcionamento aprendido, ser operado e ser atraente ao usuário.
Note que este conceito é bastante abrangente e se aplica mesmo a programas que não possuem uma interface para o usuário final. Suas sub-características são:
	 Inteligibilidade que representa a facilidade com que o usuário pode compreender as suas funcionalidades e avaliar se o mesmo pode ser usado para satisfazer as suas necessidades específicas;
	 Apreensibilidade identifica a facilidade de aprendizado do sistema para os seus potenciais usuários;
	 Operacionalidade é como o produto facilita a sua operaçãopor parte do usuário, incluindo a maneira como ele tolera erros de operação;
	 Proteção frente a erros de usuários: como produto consegue prevenir erros dos usuários;
	 Estética/Atratividade: envolve características que possam atrair um potencial usuário para o sistema, o que pode incluir desde a adequação das informações prestadas para o usuário até os requintes visuais utilizados na sua interface gráfica;
	 Acessibilidade: refere-se a prática inclusiva de fazer softwares que possam ser utilizados por todas as pessoas que tenham deficiência ou não. Quando os softwares são corretamente concebidos, desenvolvidos e editados, todos os usuários podem ter igual acesso à informação e funcionalidades;
	 Conformidade.
* 
Eficiência
O tempo de execução e os recursos envolvidos são compatíveis com o nível de desempenho do software. Suas sub-características são:
	 Comportamento em Relação ao Tempo que avalia se os tempos de resposta (ou de processamento) estão dentro das especificações;
	 Utilização de Recursos que mede tanto os recursos consumidos quanto a capacidade do sistema em utilizar os recursos disponíveis;
	 Conformidade.
Manutenibilidade
A capacidade (ou facilidade) do produto de software ser modificado, incluindo tanto as melhorias ou extensões de funcionalidade quanto as correções de defeitos, falhas ou erros.
Suas sub-características são:
	Analisabilidade identifica a facilidade em se diagnosticar eventuais problemas e identificar as causas das deficiências ou falhas;
	Modificabilidade caracteriza a facilidade com que o comportamento do software pode ser modificado;
	Estabilidade avalia a capacidade do software de evitar efeitos colaterais decorrentes de modificações introduzidas;
	Testabilidade representa a capacidade de se testar o sistema modificado, tanto quanto as novas funcionalidades quanto as não afetadas diretamente pela modificação;
	Conformidade.
* 
Portabilidade
A capacidade do sistema ser transferido de um ambiente para outro.
Como "ambiente", devemos considerar todo os fatores de adaptação, tais como diferentes condições de infraestrutura (sistemas operacionais, versões de bancos de dados, etc.), diferentes tipos e recursos de hardware (tal como aproveitar um número maior de processadores ou memória). Além destes, fatores como idioma ou a facilidade para se criar ambientes de testes devem ser considerados como características de portabilidade.
Suas sub-características são:
	 Adaptabilidade, representando a capacidade do software se adaptar a diferentes ambientes sem a necessidade de ações adicionais (configurações);
	 Capacidade para ser Instalado identifica a facilidade com que pode se instalar o sistema em um novo ambiente;
	 Coexistência mede o quão facilmente um software convive com outros instalados no mesmo ambiente;
	 Capacidade para Substituir representa a capacidade que o sistema tem de substituir outro sistema especificado, em um contexto de uso e ambiente específicos. Este atributo interage tanto com adaptabilidade quanto com a capacidade para ser instalado;
	 Conformidade.
* 
Alguns padrões ou normas podem ser utilizados para garantir e verificar qualidade do produto de software. Uma delas é o conjunto de normas SQuaRE (ISO, 2005b) - Software Product Quality Requirements and Evaluation. que trata da caracterização e medição de qualidade de produtos de software. Ela tem como objetivo melhorar e unificar os três principais processos pertinentes à qualidade de software, sendo eles a especificação de requisitos, a medição e avaliação de qualidade. As normas SQuaRE são a reformulação das normas ISO/IEC 9126 e ISO/IEC 14598 e possui cinco divisões: requisitos de qualidade, modelo de qualidade, gerenciamento de qualidade, medições e avaliação. 
Já a qualidade do processo diz respeito à adoção de uma abordagem de processo para o desenvolvimento, implementação e melhoria da eficácia de um sistema de gestão da qualidade para aumentar a satisfação do cliente pelo atendimento aos seus requisitos. Abordagem de processo trata da identificação e interações de processos, e da gestão dele para se atingir os resultados desejados (ISO, 2008a).
* 
A ISO/IEC 25010 é uma das normas SQuaRE e define um modelo de qualidade de produto detalhado. Através de um modelo hierárquico de características de qualidade, o qual descreve o que se espera de um produto de software. Nessa norma são definidos os conceitos de qualidade em uso e qualidade do produto. A SQuaRE é dividida em três modelos de qualidade: modelo de qualidade em uso, modelo de qualidade do produto e o modelo de qualidade de dados presente na ISO/IEC 25012 (ISO, 2008b). 
Eles três juntos constituem uma estrutura para garantir que todas as características de qualidade sejam consideradas. É definida na norma SQuaRE uma estrutura de modelo de qualidade, estrutura essa que foi usada nesse trabalho para organizar as características de qualidade de um processo. De acordo com a ISO/IEC 25010 (2011), a qualidade do produto é categorizada em características e subcaracterísticas, como é mostrado na Figura abaixo:
Estrutura do modelo de qualidade. Adaptada da ISO/IEC 25010 (ISO, 2011) 
* 
O modelo de qualidade em uso define cinco características como pode-se observar na próxima figura: efetividade, eficiência, satisfação, ausência de risco e cobertura de contexto. A qualidade em uso caracteriza o impacto que o produto tem sobre o usuário (ISO, 2011). 
Modelo de qualidade em uso. Adaptada da ISO/IEC 25010 (ISO, 2011) 
* 
Já o modelo de qualidade do produto caracteriza as propriedades do produto em oito características: adequabilidade funcional, eficiência do desempenho, compatibilidade, usabilidade, confiabilidade, segurança, manutenabilidade e portabilidade. A Figura abaixo mostra cada característica e subcaracterísticas associadas.
Modelo de qualidade do produto. Adaptada da ISO/IEC 25010 (ISO, 2011)
Cada uma das características e subcaracterísticas de qualidade em uso e qualidade do produto são definidas na norma. Como exemplo dessa definição é apresentado a seguir a descrição do vem a ser compatibilidade, uma das características da qualidade de produto. 
“Compatibilidade: Grau em que um produto, sistema ou componente pode trocar informações com outros produtos, sistemas ou componentes, e/ou realizar as suas funções necessárias, ao compartilhar o mesmo ambiente de hardware ou software” (ISO, 2011).
* 
ISO/IEC 12119
A NBR ISO/IEC 12119 (Atual NBR ISO/IEC 25051) é aplicável a pacotes de software, como por exemplo, pacotes de software voltados para funções administrativas, técnicas ou científicas, comunicação de escritórios e outras finalidades, tal como são produzidos. Aplicável à avaliação de pacotes de software na forma em que são oferecidos e liberados para o uso no mercado e não os processos de desenvolvimento e fornecimentos do software.
A norma estabelece um conjunto de requisitos de qualidade para pacotes de software, instruções em como executar testes em um pacote de software, em destaque para testes realizados por terceiros. Os requisitos de qualidade incluem:
	 cada pacote de software deve ter uma descrição do produto e documentação do usuário.
	 a descrição de produtos deve conter informações que sejam testáveis e corretas.
	 requisitos para a documentação do usuário, programas e dados que façam parte do pacote.
* 
Pré-requisitos para teste:
Deve ser considerada a presença de itens de produto; de sistema necessário e treinamento quando mencionado na descrição do produto
Atividades de teste: 
Testar se estão de acordo com os requisitos de qualidade tais como a descrição do produto, a documentação do usuário, e os programas de dados
Relatório de teste: 
Contém a descrição do produto, o hardware e software usado no teste, os documentos usados, os resultados dos testes (descrições, documentação, programas e dados), a lista de não conformidades dos requisitos, a lista de não conformidades de recomendações e as datas dos inícios e término do teste.
Registro de teste:
Deve conter informações suficientespara permitir a repetição do teste como a elaboração do plano de teste, casos de teste, registros de resultados com falhas e/ou sucessos e por fim, a identificação de pessoas envolvidas
* 
NBR ISO/IEC 14598
Define como serão as avaliações da qualidade de produto de software. Apresenta toda a estrutura de funcionamento da série de normas para avaliação da qualidade dos produtos de software, além de definir os termos técnicos utilizados nesse modelo. 
Fornece os conceitos e o funcionamento do processo de avaliação da qualidade de qualquer tipo de software, para utilização por desenvolvedores. 
Muito utilizada por pessoas envolvidas no desenvolvimento, padronização e uso de tecnologia de avaliação.
* 
Algumas derivações da ISO 14598: 
	ABNT NBR ISO/IEC 14598‐2 – Requisitos, recomendações e orientações, com a função de suporte ao processo de avaliação dos produtos de software. 
	ABNT NBR ISO/IEC 14598‐3 – Destina‐se ao uso durante o processo de desenvolvimento e manutenção de software. 
	ABNT NBR ISO/IEC 14598‐4 – Direcionada para adquirentes de software e estabelece um processo sistemático para avaliação de produtos de software e modificações de produtos existentes.
	 ABNT NBR ISO/IEC 14598‐5 – Fornece orientações para a implementação prática de avaliação de produto de software. 
	ABNT NBR ISO/IEC 14598‐6 – Define a estrutura e o conteúdo da documentação a ser usada na descrição dos Módulos de Avaliação
* 
* 
NBR ISO 9000‐3
Suas diretrizes destinam‐se a descrever os controles e métodos sugeridos para a produção de “software” que atendam aos requisitos do comprador desde o desenvolvimento até a manutenção.
Exemplo: Uma empresa ABC contrata uma empresa XYZ para desenvolver um produto de software.
A ISO 9000‐3 aborda basicamente situações em que um “software” específico é desenvolvido como parte de um contrato, de acordo com as especificações do comprador. 
A aplicação da ISO/IEC 9000-3 independe de tecnologia, modelos de ciclo de vida, processos de desenvolvimento, sequência de atividades ou estrutura organizacional da organização. Nas organizações cuja abrangência de atividades que inclui áreas diferentes de desenvolvimento de software, o relacionamento entre elementos de software do seu sistema de gestão da qualidade e os demais aspectos devem claramente ser documentados no sistema de gestão da qualidade como um todo. 
* 
A ISO/IEC 12207 é a norma ISO/IEC que define processo de Engenharia de Software, atividades e tarefas que são associados com os processos do ciclo de vida do software desde sua concepção até a retirada/descontinuação do software.
A norma internacional ISO/IEC 12207 tem como objetivo principal estabelecer uma estrutura comum para os processos de ciclo de vida e de desenvolvimento de softwares visando ajudar as organizações a compreenderem todos os componentes presentes na aquisição, desenvolvimento e fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma mais eficaz. Para isso é necessário que compradores, fornecedores, desenvolvedores, mantenedores, operadores, gerentes e técnicos envolvidos no desenvolvimento de software usem uma linguagem/framework comum.
Visa ser o padrão que define as tarefas necessárias para o desenvolvimento e manutenção de software.
O padrão ISO/IEC 12207 define ao todo 25 processos, 95 atividades e 325 tarefas.
NBR ISO/IEC 12207
* 
* 
A norma ISO/IEC 12207 estabelece uma arquitetura de alto nível do ciclo de vida de software que é construída a partir de um conjunto de processos e seus inter-relacionamentos. Os processos são descritos tanto em nível de propósito/saídas como em termos de atividades.
A ISO/IEC 12207 não possui nenhuma ligação com métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Esta determinação é útil para permitir que a norma seja utilizada mundialmente e possa acompanhar a evolução da Engenharia de Software nas diversas culturas organizacionais. 
Ela pode ser utilizada com qualquer modelo de ciclo de vida, método ou técnica de Engenharia de Software e linguagem de programação. Sua flexibilidade é uma característica importante, as atividades e tarefas do processo de ciclo de vida do software especificam "o que fazer" e não "como fazer".
Os processos da ISO/IEC 12207 são modulares, ou seja, são fortemente coesos e fracamente acoplados. Isto significa que todas as partes de um processo são fortemente relacionadas, mas a quantidade de interfaces entre os processos é mínima.
* 
Os processos, atividades e tarefas da ISO/IEC 12207 foram projetados para serem adaptados de acordo com cada projeto de software. Essa adaptação consiste no mapeamento de processos/atividades/tarefas relevantes/adequados ao projeto e, ao mesmo tempo, à supressão de processos/atividades/tarefas não aplicáveis.
Os processos são agrupados/categorizados, por uma questão de organização, de acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Esse agrupamento resultou em 4 diferentes classes de processos, que são:
 Processos fundamentais;
 Processo de apoio;
 Processos organizacionais;
 Processos de adaptação.
* 
Processos fundamentais
Os processos fundamentais são necessários para que um software seja executado. Eles iniciam o ciclo de vida e comandam outros processos. São eles:
 Aquisição: obter o produto e/ou serviço que satisfaça suas necessidades;
 Fornecimento: prover um produto e/ou serviço;
 Desenvolvimento: transformar um conjunto de requisitos em um produto ou sistema de software;
 Operação: operar o produto no seu ambiente e prover suporte aos usuários;
 Manutenção: modificar o produto de software e depois liberá-lo para uso.
* 
Processos de apoio
Os processos de apoio auxiliam outro processo. Eles são usados para garantir a qualidade, mas não são fundamentais. São eles:
 Documentação: prover, manter um registro de informações de software;
 Gerência de configuração: estabelecer e manter a integridade de todos os produtos de trabalho (artefato) de um processo do projeto;
 Garantia da qualidade: prover garantia de que os produtos e processos estão em conformidade com o requisitos (padrões/normas) pré-definidos;
 Verificação: confirmar que os produtos e/ou serviços refletem os requisitos especificados;
 Validação: confirmar que os requisitos para o uso específico de um produto e/ou serviço são atendidos;
 Revisão conjunta: manter o entendimento (gerencial comum com os stakeholders);
 Auditoria: determinar independentemente a conformidade dos produtos e processos contra os requisitos definidos;
 Resolução de problema: assegurar que todos os problemas levantados sejam analisados e resolvidos;
 Usabilidade: aumentar a facilidade do uso dos produtos e/ou serviços;
 Gerência de solicitação de mudanças;
 Avaliação do produto: garantir, através de exame e medição sistemáticos, que o produto e/ou serviços atende às necessidades especificadas (explícitas) e implícitas dos usuários.
* 
Processos organizacionais
Os processos organizacionais auxiliam a organização e gerência geral dos processos e podem ser empregados fora do domínio de projetos e contratos específicos, servindo para toda a organização. São eles:
 Gerência: organizar, monitorar e controlar a iniciação e o desempenho dos processos;
 Infraestrutura: manter uma infraestrutura estável e confiável;
 Melhoria: estabelecer, avaliar, controlar e melhorar um processo de ciclo de vida de software;
 Recursos Humanos: prover e manter recursos humanos adequados mantendo as suas capacitações consistentes com o negócio.
Processos de reuso de software
São os processos específicos no desenvolvimento de software, processos estes da atualização da ISO/IEC 12207 - 2008.
 Gestão de ativos: gerenciar a vida dos ativos (reusáveis) desde a concepção até a desativação;
 Gestão de programa de reuso: planejar, estabelecer, controlar, monitorar os programas de reuso;
 Engenharia de domínio: desenvolver e manter modelos, arquiteturas e ativos deste domínio.
* 
Processos de adaptação
Definemas atividades básicas necessárias para executar as adaptações.
Os processos são adaptáveis a:
 Projeto;
 Organização;
 Cultura;
 Modelo de ciclo de vida, métodos e técnicas, e linguagens.
Atividades do desenvolvimento
Algumas atividades importantes para o desenvolvimento de software serão descritas a seguir. São elas:
 Levantamento de requisitos;
 Análise dos requisitos do software;
 Projeto da arquitetura do software;
 Projeto detalhado do software;
 Implementação;
 Codificação e testes do software;
 Integração do software;
 Teste de qualificação do software;
 Instalação do software;
 Testagem e aprovação do software.
Elas foram descritas com base na norma ISO/IEC 12207.
* 
Grupos do Processo de Ciclo de vida
* 
ISO/IEC 15504
Também conhecida como SPICE (Software Process Improvement and Capability Determination - Melhoria no processo de software e determinação da capacidade), define processo de desenvolvimento de software. É uma evolução da ISO/IEC 12207, mas possui níveis de capacidade para cada processo assim como o CMMI. A norma ISO/IEC 15504, fornece um modelo para avaliação de processos de software. Essa norma tem o objetivo de determinar a capacidade dos processos de uma empresa, determinar o estado do processo de uma empresa e orientar uma empresa para melhorias no seu processo.
* 
Ele organiza e classifica as melhores práticas em duas dimensões: 
categorias de processo e níveis de capacidade. 
Atualmente a norma é genérica podendo ser utilizada por diversos tipos de processos, não sendo mais exclusivamente dedicada a software. Contudo seu principal objetivo é a melhoria e a avaliação dos processos, em ambos os casos três elementos básicos devem ser precisamente definidos para que a avaliação de processo seja realizada conforme a 15504, sendo: 
	Os processos: devem ser verificados por um avaliador competente, segundo os requisitos previstos na norma; 
	Uma escala de medida: deve ter como referência um modelo de avaliação de processo compatível; 
	Um método de medição: deve ser realizado seguindo um processo compatível. 
* 
Essa norma é dividida em dez partes:
a parte 1 que apresenta os conceitos e o vocabulário; a parte 2 que apresenta a estrutura do processo de avaliação; a parte 3, a qual apresenta as recomendações para realizar uma avaliação; a parte 4 que apresenta as recomendações para melhoria de processos e determinação de capacidade; a parte 5 apresenta um exemplo de aplicação para software; a parte 6 apresenta uma aplicação para sistemas; a parte 7 apresenta a avaliação de maturidade organizacional; a parte 8 apresenta um exemplo de aplicação para gestão de serviços de TI; a parte 9 apresenta os perfis de processos alvo; e por fim, a parte 10 apresenta a extensão de segurança. A avaliação do processo determina a capacidade do processos de uma organização.
A parte 2 da norma define essas capacidades, são definidos seis níveis de capacidade de processos: 
* 
Nível 0 - Processo Incompleto: Nesse nível existe uma falha na satisfação do propósito do processo. Existem poucos artefatos de trabalho ou resultados de processo. 
Nível 1 - Processo executado: O propósito do processo é geralmente alcançado, pode não ser rigorosamente planejado e monitorado. Nesse nível existem artefatos de trabalho para o processo que evidencie a satisfação do propósito do processo. 
Nível 2 - Processo gerenciado: o processo produz artefatos de acordo com os procedimentos especificados. Nesse nível o processo é planejado e monitorado. A diferença para o nível 2 é que a execução do processo entrega artefatos que cumprem com os requisitos especificados, dentro de um cronograma de tempo. 
Nível 3 - Processo estabelecido: o processo é executado e gerenciado usando um processo definido. A implantação desse processo utiliza versões adaptadas de um processo padrão aprovado. o processo estabelecido utiliza um processo padrão que é capaz de alcançar os resultados definidos. 
Nível 4 - Processo previsível: O processo definido é executado na prática, dentro de limites de controle definidos. São coletadas e analisadas medições do desempenho do processo. Dessa forma, a qualidade do produto é reconhecida de forma quantitativa. O processo passa a ser executado dentro de limites definidos a fim de atingir seus resultados definidos. 
Nível 5 - Processo em otimização: Nesse nível a execução do processo é continuamente melhorada e o processo atinge repetibilidade no cumprimento de suas metas de negócios definidas. A principal diferença para os outro níveis é que os processos definidos e padronizados se adaptam para atender com eficácia os objetivos de negócio, atuais e futuros, de maneira dinâmica.
A norma ISO/IEC 15504 avalia o processo de software em nível de execução do processo
* 
Cada um dos níveis apresentados possui incluídos os atributos de processo que são aplicáveis a todos os processos. Estes atributos são usados para determinar se um processo atingiu uma dada capacidade. Existe um total de nove atributos agrupados em níveis de capacidade, que são aplicáveis a todos os processos. Na Tabela 2 são apresentados os atributos de processo. 
* 
Modelo de referência SPICE
É um conjunto padronizado de processos fundamentais, que orientam para uma boa engenharia de software. O SPICE inclui um modelo de referência, que serve de base para o processo de avaliação. Este modelo define duas dimensões:
	Dimensão de Processo: corresponde à definição de um conjunto de processos considerados universais e fundamentais para a boa prática da engenharia de software; Atualmente, um modelo de referência de processo no domínio de software é a ISO 12207;
	Dimensão de Capacidade: um modelo de avaliação, baseado na ISO 12207, é o definido na ISO 15504; Neste último, os processos são agrupados em cinco grandes categorias de processo:
	Cliente-Fornecedor;
	Engenharia;
	Suporte;
	Gerência;
	Organização.
Além dos processos, o SPICE define também os 6 níveis de capacitação de cada processo, que pode ser incompleto, executado, gerenciado, estabelecido, previsível e otimizado. O resultado de uma avaliação, portanto, um perfil da instituição em forma de matriz, onde temos os processos nas linhas e os níveis nas colunas. 
* 
Uma das contribuições do modelo SPICE é definir em seu modelo de referência todos os processos envolvidos no desenvolvimento de software, agrupados em categorias. A norma define detalhes de cada um dos processos que serão mencionados. Para cada um deles existe uma definição mais detalhada, uma lista dos resultados da sua implementação bem sucedida e uma descrição detalhada de cada uma das práticas básicas. 
Observe no quadro a seguir a estrutura completa das categorias, dos processos de cada categoria: 
* 
* 
Suporte
SUP.1: Documentação - desenvolver e manter documentos que registrem informações produzidas por um outro processo ou atividade. Envolve a produção, controle, manutenção, revisão, aprovação e publicação de documentos e seu acesso.
SUP.2: Gestão de configuração - estabelecer e manter a integridade de todos os produtos de trabalho de algum processo ou do projeto. Envolve a definição de uma estratégia de gestão de configuração, a identificação de itens de configuração, o controle de acesso e de mudanças de itens, o registro da situação de todos os itens e o seu armazenamento e manuseio de forma controlada.
SUP.3: Garantia de qualidade - assegurar que os produtos de trabalho e atividades de um processo ou projeto estão de acordo com os requisitos especificados e satisfazem aos planos e regras estabelecidas. Devem ser estabelecidos os procedimentos para o tratamento de desvios a não-conformidades com relação a regras, procedimentos e padrões.
Deve ser coordenada com os processos de verificação, validação, revisão conjunta, auditoria e resolução de problemas. As pessoas responsáveis pela garantia da qualidade devem ter autonomia organizacional e autoridade para realizarem as suas tarefas sem interferências dos responsáveis pelo desenvolvimento do software.
SUP.4: Verificação - Confirmar quecada produto de trabalho ou serviço resultado de um processo reflete corretamente às especificações de entrada do processo.
Envolve a definição de uma estratégia de verificação, de critérios de verificação para todos os produtos de trabalho e para as atividades de verificação. Deve assegurar que os defeitos encontrados serão removidos dos produtos de trabalho e que os resultados serão disponibilizados para os clientes
* 
SUP.5: Validação - confirmar que estão satisfeitos os requisitos para o uso pretendido de cada produto de trabalho ou serviço resultado de um processo. Envolve a definição de uma estratégia de validação, de critérios de validação para todos os produtos de trabalho e para as atividades de validação. Deve assegurar que os problemas encontrados serão resolvidos, que os resultados serão disponibilizados para os clientes e para outras organizações internas e que os produtos são adequados para o uso pretendido.
SUP.6: Revisão Conjunta - permitir ao cliente a visibilidade do andamento do desenvolvimento quando comparado ao especificado no contrato. As revisões formais dever tratar, ao longo de todo o ciclo de vida de desenvolvimento, tanto dos aspectos técnicos quanto administrativos. Envolve: revisões periódicas em datas preestabelecidas da situação de produtos e atividades por todas as partes interessadas, da solução de todas as pendências, problemas e desvios encontrados.
SUP.7: Auditoria - determinar, de forma independente, a conformidade de produtos identificados e atividades com planos, requisitos e com o contrato. Deve ser definida a estratégia de programação da auditoria, especificando quais itens serão auditados contra quais regras. A auditoria deve ser conduzida por pessoal independente àquele que executa o desenvolvimento e os problemas encontrados deverão ser comunicados aos responsáveis para a devida ação corretiva.
SUP.8: Resolução de Problemas - assegurar que todos os problemas encontrados sejam analisados, resolvidos (ação corretiva) e que tendências sejam observadas visando o planejamento e execução de ações preventivas.
* 
O SPICE, entretanto, não se limita a listar categorias e processos. Seu principal objetivo, na realidade, é avaliar a capacitação da organização em cada processo e permitir a sua melhoria. O modelo de referência do SPICE inclui seis níveis de capacitação. Cada um dos processos mencionados acima deve ser classificado nestes níveis. Os níveis são descritos a seguir: 
* 
CMM / CMMI 
O Modelo de Maturidade da Capacitação para Software chamado CMM – Capability Maturity Model for Software, propõe para as organizações uma evolução através de níveis de maturidade da capacitação, ou seja, a produção de software com a qualidade esperada, prazos e recursos acordados. O modelo CMM enfatiza a documentação dos processos, avaliando que para se obter melhoria no mesmo, é necessário que ele seja adaptado à empresa e aos projetos por ela desenvolvidos, evitando a desorganização dos processos e a inexistência de padrões documentados. 
O CMM é uma estrutura que serve como base ou guia para a melhoria recomendada para organizações de software que desejam aumentar a capacitação ou capacidade de seu processo de desenvolvimento de software. (PESSOA, 2003) 
Alguns objetivos como auxiliar o gerenciamento e mudança de processo, fornecer uma estrutura básica para métodos confiáveis e coerentes de avaliação de organizações de software, auxiliar a melhoria do processo interno do software, fornecer um guia para as empresas implementarem melhorias em seu processo, são fornecidos pelo modelo CMM; porém, não pretende resolver problemas, se propõe a ajudar organizações a encontrarem suas próprias soluções. 
* 
O modelo CMM possui cinco níveis de maturidade onde é estabelecido um conjunto de metas, que buscam melhorar a capacitação da organização no desenvolvimento dos processos contínuos (permitem que as organizações escolham áreas específicas do processo para implementação de melhorias.). Dentre os níveis: inicial, repetitivo, definido, gerenciado e otimizado. Cada nível é composto por várias áreas-chave (é utilizada na acepção: importantíssimo, decisivo, fundamental) de processo que conduzem a metas de melhoria, com exceção do nível 1.
	Nível 1 - Inicial: Pode-se desenvolver software de qualidade, de acordo com o desempenho e capacidade da equipe, ou seja, é uma caixa preta onde apenas as entradas e o produto final podem ser vistos claramente. 
	Nível 2 – Repetível: São estabelecidas políticas para gerenciar os projetos, bem como procedimentos para implementá-los, onde a capacitação do processo é melhorada, projeto a projeto com o estabelecimento de disciplinas de gerência de processo, logo os métodos de gerenciamento são documentados e acompanhados. Diferentemente do nível 1, o processo de desenvolvimento passa a ter uma sequência de caixas pretas, ou seja, tarefas que asseguram a visibilidade em alguns pontos, onde os marcos são identificados e controlados, permitindo verificar se o projeto está conforme o estabelecido. 
	Nível 3 - Definido: O processo de software para as atividades de gerenciamento e de engenharia é documentado, padronizado e integrado em um processo padrão de software para a organização. 
* 
	Nível 4 - Gerenciado: A organização estabelece metas quantitativas de qualidade para os produtos e para os processos de software, onde serão medidas a qualidade e a produtividade para as atividades importantes. É possível prever o desempenho dentro de limites quantitativos. Para este nível a capacitação para as organizações é quantificável e previsível, pois o processo é medido e opera dentro de limites aceitáveis. 
	Nível 5 - Otimizado: A melhoria contínua do processo é feita através do feedback quantitativos dos processos e das aplicações de novas ideias e tecnologias, seguindo que as mudanças no próprio processo sejam regerenciadas de forma a não causarem impacto na qualidade do produto final. 
O Modelo CMMI – Capability Maturity Model Integration, ou seja, Modelo de Maturidade da Capacitação Integrado. Foi desenvolvido pelo SEI – Software Engineering Institute, é uma evolução do CMM, que tem por objetivo suprir os problemas de integração. O CMMI tem como objetivo suprir as limitações do modelo CMM, com a criação de um framework comum, eliminando as inconsistências e permitindo a inclusão de novos modelos, unificando os vários modelos CMM existentes, preservar investimentos e, contudo reduzir custos do treinamento nas implantações de melhorias. O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção. A principal mudança do CMMI para o CMM é a possibilidade de utilização de duas diferentes abordagens para a melhoria do processo – contínua e estagiada. A estagiada divide as áreas de processo em cinco níveis de maturidade, assim como o CMM, no caso da representação contínua define níveis de capacidade para caracterizar melhorias relativas a uma área de processo individual. 
* 
Dentre os principais benefícios da implantação do CMMI, vale a pena destacar:
 Uma maior confiabilidade no que refere ao cumprimento de prazos e custos que foram acordados, inicialmente, perante o cliente que solicitou o desenvolvimento de um sistema. Essa previsibilidade é decorrente do rigor que o CMMI exige quanto à medição dos processos, fato este que conduz à obtenção de uma base histórica realista e confiável para estes fins;
 O gerenciamento das atividades relativas à produção de software aumenta consideravelmente;
 Uma maior qualidade nos softwares criados, já que processos bem definidos e controlados conduzem à produção de produtos mais confiáveis;
 A menor dependência da empresa de desenvolvimento para com seus especialistas. Com um foco voltado para processos e melhoria contínua, além do uso intensivo de informações históricas, a organização deixa de depender única e exclusivamente de profissionaiscom um elevado grau de conhecimento técnico;
 A busca por melhorias contínuas nos processos cotidianos.
A implantação do CMMI é recomendável para grandes fábricas de software. Implementar os diversos estágios é uma tarefa árdua, não só numa fase inicial, mas também quando se leva em conta a migração de um nível para outro. Isto exigirá, invariavelmente, a realização de vultosos investimentos financeiros, assim como uma mudança de postura da organização (principalmente quando a mesma não contava uma experiência anterior bem-sucedida no gerenciamento de processos). Em inúmeras ocasiões, empresas desenvolvedoras de sistemas recorrem a consultorias especializadas, visando apoio na obtenção da certificação CMMI (fato este que inviabiliza a adoção deste mesmo modelo por pequenas companhias).
* 
O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
Representação Continua
Possibilita a organização utilizar a ordem de melhoria que melhor atender os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels). 
A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando já utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo de comparação com outras empresas.
Representação Por Estágios
Disponibiliza uma sequência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels). 
Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível de conhecimento obtido por outros para sua área de atuação.
* 
O nível de maturidade e capacidade está divido em 5 etapas, que são:
* 
As principais características dos níveis contidos no slide anterior são:
 Nível 1 - Inicial: imaturidade organizacional; os processos são improvisados e geralmente não são seguidos; compromissos de prazo e custo não são cumpridos; o planejamento não é feito com base em estimativas; as qualidades, procedimentos e conhecimentos pertencem às pessoas e não aos projetos; as chances de sucesso dependem das habilidades pessoais dos gerentes e desenvolvedores;
 Nível 2 - Gerenciado: políticas e procedimentos para gerenciar o desenvolvimento de software estão definidas e são obedecidas; o planejamento é baseado em estimativas e na experiência anterior de outros projetos; os projetos utilizam processos definidos, usados, disseminados, documentados, medidos e fiscalizados com rotinas de melhoria; os processos afetados são puramente gerenciais (não técnicos) e pertencem aos projetos e não às pessoas;
 Nível 3 - Definido: os processos utilizados são estabelecidos e padronizados em toda a organização; processos técnicos passam a ser considerados ao lado dos processos gerenciais; tanto os processos gerenciais quanto os técnicos passam a ser repetidos; os processos pertencem a organização e não mais aos projetos;
 Nível 4 - Quantitativamente Gerenciado: são estabelecidas metas quantitativas para os processos e produtos, medidas de qualidade e produtividade são coletadas em todos os projetos; é estabelecido controle estatístico de processos; a gestão passa a ser feitas com bases quantitativas;
 Nível 5 - Otimização: a organização está engajada na melhoria contínua de seus processos; identificação de pontos fracos e defeitos; ações preventivas sobre causas; mudanças mais significativas de processos e/ou tecnologias são feitas a partir de análise de custo/benefício com base em dados quantitativos.
* 
A versão atual 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 ao processo 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 modelo CMMI para Desenvolvimento - CMMI-DEV (CMMI for Development ) contém práticas que cobrem Gestão de Projeto, Gestão de Processo, Engenharia de Sistemas, Engenharia de Hardware, Engenharia de Software e outros processos de suporte utilizados em desenvolvimento e manutenção de produtos tecnológicos.
* 
As áreas de Processo do CMMI-DEV v1.3
* 
O CMMI-DEV divide os processos em quatro categorias:
1. Gestão de Processo  1.1 - Foco no Processo Organizacional - (OPF - Organizational Process Focus) - (SE/SW)  1.2 - Definição do Processo Organizacional - (OPD - Organizational Process Definition) - (SE/SW)  1.3 - Treinamento Organizacional - (OT - Organizational Training) - (SE/SW)  1.4 - Desempenho de Processo Organizacional - (OPP - Organizational Process Performance) - (SE/SW)  1.5 - Inovação e Implementação Organizacional - (OID - Organizational Innovation and Deployment) - (SE/SW)
2. Gestão de Projeto   2.1 - Planejamento de Projeto - (PP - Project Planning) - (SE/SW)   2.2 - Monitoramento e Controle de Projeto - (PMC - Project Monitoring and Control) - (SE/SW)   2.3 - Gestão de Acordo com o Fornecedor - (SAM - Supplier Agreement Management) - (SE/SW)   2.4 - Gestão Integrada do Projeto - (IPM - Integrated Project Management) - (SE/SW)   2.5 - Gestão de Risco - (RSKM - Risk Management) - (SE/SW)   2.6 - Integração de Equipes - (IPPD)   2.7 - Gestão Integrada de Fornecedores - (SS)   2.8 -Gestão Quantitativa do Projeto - (QPM - Quantitative Project Management) - (SE/SW)
3. Engenharia   3.1 - Gestão de Requisitos - (REQM - Requirements Management) - (SE/SW)   3.2 - Desenvolvimento de Requisitos - (RD - Requirements Development) - (SE/SW)   3.3 - Solução Técnica - (TS - Technical Solution) - (SE/SW)   3.4 - Integração do Produto - (PI - Product Integration)  - (SE/SW)   3.5 - Verificação - (VER - Verification) - (SE/SW)   3.6 - Validação - (VAL - Validation) - (SE/SW)
4. Suporte   4.1 - Gestão de Configurações (CM - Configuration Management) - (SE/SW)   4.2 - Garantia da Qualidade do Processo e do Produto - (CM - Configuration Management) - (SE/SW)   4.3 - Medição e Análise - (MA - Measurement and Analysis) - (SE/SW)   4.4 - Análise e Solução das Decisões - (DAR - Decision Analysis and Resolution) - (SE/SW)   4.5 - Ambiente Organizacional para Integração - (IPPD)   4.6 - Análise e Solução de Causas - (CAR - Causal Analysis and Resolution) - (SE/SW)
* 
MPS.Br
O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS). Voltado para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil, ele é baseado em normas relacionadas aos processos de Engenharia de Software (ISO/IEC 12207) e de desenvolvimento de software (ISO/IEC 15504) e compatível com o CMMI.
No Brasil há um baixo investimento das empresas na busca por certificações que comprovem a qualidade e a maturidade nos processos de software, isso se deve principalmente pelo alto investimento que deve ser movimentado para essas certificações, deixando de fora médias e pequenas organizações que não possuem recursos suficientes para investir.
Em 2003 surgiu no Brasil o Projeto MPS. BR, coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), que visa tornar os softwares brasileiros compatíveis com os padrões de qualidades que são exigidos internacionalmente, tendo como foco em micro, pequenas e médias empresas contando com o apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI), da Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID/FUMIN).
* 
O MPS.BR temcomo base definir o nível de maturidade e capacidade dos processos de desenvolvimento de software e serviços correlatos. Funciona como uma espécie de selo, indicando o nível de maturidade da empresa. Cada nível possui diversas práticas associadas que medem o nível de qualidade dos processos. A obtenção dessa certificação determina que a organização teoricamente possui capacidade de desenvolver softwares de qualidade, com custos e prazos dentro do estimado, além de auxiliar no reconhecimento da empresa no âmbito nacional e internacional. 
Um dos objetivos do Projeto MPS.BR é determinar e aprimorar um modelo para melhoria e avaliação dos processos e serviços correlatos, tento como preferencia micro, pequenas e médias empresas, com o intuito de tornar essas organizações conhecidas nacional e internacionalmente como sendo um modelo aplicável à indústria de software.
As metas do Programa MPS.BR são:
1. Criação e aprimoramento de um modelo para melhoria e avaliação dos processos e serviços; Capacitação de pessoas através de programas de treinamento, à um custo viável; Credenciamento de Instituições Implementadoras (II) e Avaliadoras (IA);
2. Criação e aprimoramento de um Modelo de Negócio para Melhoria de Processo de Software (MN-MPS); Implementação do modelo MPS em empresas de micro, pequeno e médio porte a um custo viável; Avaliação do modelo nas organizações a um custo viável.
* 
Baseado no CMMI e nas normas ISO – 12207 para desenvolvimento de software, e ISO – 15504 para avaliação de processos de software, o MPS.BR possui a característica mais específica dentro da realidade do mercado brasileiro, com o diferencial focalizado em sua escala de implementação em sete níveis de maturidade, possibilitando assim, uma implementação mais gradual chegando a um nível inicial de maturidade e capacidade, com um grau menor de esforço e de investimento. software, o MPS.BR possui a característica mais específica dentro da realidade do mercado brasileiro, com o diferencial focalizado em sua escala de implementação em sete níveis de maturidade, possibilitando assim, uma implementação mais gradual chegando a um nível inicial de maturidade e capacidade, com um grau menor de esforço e de investimento. 
Descrições do Modelo MPS - O modelo MPS possui três componentes: Modelo de Referência para Melhoria de Processo de Software (MR-MPS), Método de Avaliação para Melhoria de Processo de Software (MA-MPS) e Modelo de Negócio para Melhoria de Processo de Software (MN-MPS).
* 
MR-MPS (Modelo de Referência para Melhoria do Processo de Software)
O Modelo de Referência possui os requisitos que os processos das unidades organizacionais devem atender para está de acordo com o MPS (SOFTEX, 2012). O MR-MPS é definido por níveis de maturidade, sequenciais e acumulativos. Cada um dos níveis de maturidade é composto por um conjunto de processos em um determinado nível de capacidade (WEBER, ARAÚJO, et al., 2006). Um nível de maturidade é atingido quando os seus resultados, propósitos do processo e atributos relacionados aos processos são atendidos.
O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativo), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). O nível G é considerado o mais imaturo entre os demais e o A o mais maduro. 
Em cada nível de maturidade são analisados os processos fundamentais – no qual se refere à aquisição, gerência de requisitos, desenvolvimentos de requisitos, solução técnica, integração, do produto, instalação do produto e liberação do produto. Sendo analisados ainda os processos de apoio – que envolvem a garantia da qualidade, gerência de configuração, validação, medição, verificação e treinamento. Por fim, os processos organizacionais – gerência de projeto, adaptação do processo para gerência de projetos, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo, desempenho, gerência quantitativa, análise e resolução de causas, inovação e implantação na organização. 
* 
Em seguida vem a capacidade, isto é, o grau de refinamento e institucionalização com que o processo é executado na organização.
A capacidade do processo no MPS.BR possui os seguintes atributos de processos:
 AP 1.1 - O processo é executado;
 AP 2.1 - O processo é gerenciado;
 AP 2.2 - Os produtos de trabalho do processo são gerenciados;
 AP 3.1 - O processo é definido;
 AP 3.2 - O processo está implementado;
 AP 4.1 - O processo é medido;
 AP 4.2 - O processo é controlado;
 AP 5.1 - O processo é objeto de inovações;
 AP 5.2 - O processo é otimizado continuamente.
* 
MA-MPS (Método de Avaliação para Melhoria do Processo de Software)
O Método de Avaliação descreve os processos e os métodos de avaliação do MPS, além de características de qualificação dos avaliadores e Instituições Avaliadoras (IA). Esses processos e métodos de avaliação estão de acordo com a norma ISO/IEC 15504-2 [ISO/IEC, 2003] e atende aos requisitos do Programa MPS.
O processo de avaliação é composto por quatro subprocessos (SOARES, TEIXEIRA, et al., 2010):
 Contratar a avaliação;
 Preparar a realização da avaliação;
 Realizar a avaliação;
 Documentar os resultados da avaliação;
* 
MN-MPS (Modelo de Negócio para Melhoria do Processo de Software)
O Modelo de Negócio tem como função descrever as regras de negócio para implementação do Modelo de Referência (MR-MPS) pelas Instituições Implementadoras, avaliação seguindo o Método de Avaliação (MA-MPS) pelas Instituições Avaliadoras, organização de grupos de empresas pelas Instituições Organizadoras de Grupos de Empresas para implementação e avaliação do MR-MPS, certificação de Consultores de Aquisição e programas anuais para treinamento do MPS (SOFTEX, 2012).
O MN-MPS compreende (WEBER, ARAÚJO, et al., 2006):
 Modelo de Negócio Cooperado (MNC-MPS), para micro, pequenas e médias empresas que buscam melhorar seus processos de software;
 Modelo de Negócio Específico (MNE-MP), para empresas de qualquer porte que não querem compartilhar nenhuma de suas melhorias de processos de software.
O modelo MPS.BR tem como objetivo principal implementar o Modelo de Referência para melhoria de processo de software em 120 empresas. E como objetivos secundários, a disseminação em diversos locais do país, capacitação no uso do modelo e o credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente instituições de ensino e centros tecnológicos e também a implementação e avaliação do modelo com foco em grupos de empresas. A avaliação conjunta de grupos empresariais objetiva à redução dos custos, porém, há uma perda de foco, pois não há uma especificidade para cada empresa e sim um mesmo modelo de referência para todas elas.
* 
ANÁLISE COMPARATIVA ENTRE AS NORMAS ISO/IEC 12207, 15504, 9000-3 E OS MODELOS CMM/CMMI E MPS.BR
* 
* 
* 
De acordo com os itens apontados o que se pode observar é que todos os padrões apresentados têm como objetivo em comum a busca pela qualidade do software. Contudo, para cada tipo de empresa existe uma norma ou modelo mais adequado as suas necessidades; como por exemplo, as empresas de grande porte que não necessitem de reconhecimento internacional de qualidade, o mais indicado é o MPS.BR. 
Estes padrões internacionais possuem um alto custo de implantação e requer uma estrutura organizacional maior para que atenda a todos os processos e atividade oferecidos; porém; a norma IEEE 12207 define uma estrutura para os processos de ciclo de vida do software, podendo ser adaptado a qualquer empresa. No entanto para as organizações que tem como objetivo a melhoria de processos a ISO/IEC 15504 define um framework para modelos de avaliação de processos que podem ser utilizados como referência, objetivando garantir aos clientes que ao adotar os requisitos nela contidos, consigam cobrir os pontos vulneráveis do processo produtivo. 
Já o modelo CMMI traz para as micros, pequenas e médias empresas a possibilidade de estaremmelhorando os seus processos de software, tornando-as mais competitivas e oferecendo produtos desenvolvidos com a mesma qualidade de empresas internacionais.
A ISO/IEC 9000-3 caracteriza-se por estabelecer os sistemas de gestão de qualidade e de garantia da qualidade, onde as organizações definem seus próprios modelos de gestão de qualidade dentro de suas características. Por seguinte a norma 9000-3 especifica os requisitos para que as organizações possam assegurar a qualidade de seus produtos e serviços. No entanto, tendo em vista a realidade do mercado brasileiro, aponta-se como mais convencional de acordo com as tabelas a estas organizações, a utilização do modelo MPS.BR, onde se baseia no modelo CMMI e nas normas ISO 12207 e 15504. Trazendo como característica um custo de certificação reduzido e reconhecimento nacional e internacional. 
* 
*