Qualidade de Software

Instituto Federal Catarinense Campus Videira

Videira SC Brasil
Abstract The quality is perceived in three dimensions: in the project, in the
process and in the product. These three dimensions, when combined,
contribute to the total quality of the product. Several studies have been
accomplished with the purpose of measuring the quality of the final product,
which is easily perceptible by the user. In the software products, when the
clients necessities arent answered, nothing else can be done to keep the users
quality expectation, except for the software repairing, resulting in double work
and consuming extra resources. This way, it becomes natural to focus the
attention on existing aspects during the development process, but precisely in
the project management, seeing its persistence in all phases of software
engineering.
Resumo A qualidade percebida em trs dimenses: no projeto, no processo
e no produto. Estas trs dimenses, quando combinadas, contribuem para a
qualidade total do produto. Vrios estudos tm sido realizados no sentido de
mensurar a qualidade do produto final, que facilmente perceptvel pelo
usurio. Em relao a produtos de software, quando as necessidades do
cliente no so atendidas, nada mais pode ser feito no sentido de manter sua
expectativa com a qualidade, h no ser reparos no software, acarretando
retrabalho e consumo extra de recursos. Neste sentido, torna-se natural focar
a ateno tambm em aspectos existentes durante o processo de
desenvolvimento, mas precisamente na gesto do projeto, visto sua
persistncia em todas as fases da engenharia de software.

1. Introduo
rea de conhecimento da engenharia de software que o seu objetivo garantir a
qualidade do software atravs da definio e normatizao de processos de
desenvolvimento.
A qualidade do ponto de vista do desenvolvedor que o software atenda as
necessidades do cliente; j do ponto de vista do cliente est relacionada ao valor do
software, sua utilidade e se o software cumpre os requisitos solicitados.

2. Padronizao

PMBOK (Project Management Body Of Knowledge) identifica um subconjunto do

conjunto de conhecimentos em gerenciamento de projetos, que amplamente
reconhecido como boa prtica, sendo em razo disso, utilizado como base pelo Project
Management Institute (PMI). Uma boa prtica no significa que o conhecimento e as
prticas devem ser aplicados uniformemente a todos os projetos, sem considerar se so
ou no apropriados.

O Guia PMBOK tambm fornece e promove um vocabulrio comum para se

discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercmbio
eficiente de informaes entre os profissionais de gerncia de projetos.

O guia baseado em processos e subprocessos para descrever de forma

organizada o trabalho a ser realizado durante o projeto. Essa abordagem se assemelha
empregada por outras normas como a ISO 9000 e o Software Engineering Institute's,
CMMI. Os processos descritos se relacionam e interagem durante a conduo do
trabalho e a descrio de cada um deles feita em termos de:
Entradas (documentos, planos, desenhos etc.);
Ferramentas e tcnicas (que se aplicam as entradas);
Sadas (documentos, produtos etc.)
A verso 2008 do guia cita 42 processos agrupados em cinco grupos e nove
reas de conhecimento.
SWEBOK (Software Engineering Body of Knowledge) criado com o patrocnio da
IEEE com a finalidade de servir de referncia sobre assuntos da Engenharia de
Software.

Figura 1 Tpicos do SWEBOK

3. Qualidade
A qualidade segundo a Borland se define Convergncia entre requisitos completos, o
cdigo correto e o mnimo de defeitos todos alinhados para atingir os objetivos do
negocio. [Borland 2006].

Figura 2 Qualidade de Software Segundo a Borland

Segundo a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade :
A totalidade das caractersticas de uma entidade que lhe confere a capacidade de
satisfazer s necessidades explcitas e implcitas. As necessidades explcitas so as
prprias condies e objetivos propostos pelo produtor. As necessidades implcitas
incluem as diferenas entre os usurios, a evoluo no tempo, as implicaes ticas, as
questes de segurana e outras vises subjetivas.

3.1.

Requisitos de Qualidade

Requisito pode ser descrito como uma condio ou capacidade necessitada por um
usurio para resolver um problema ou alcanar um objetivo; o que o sistema deve
fazer para implementar uma necessidade de automao requerida pela soluo. Desde as
necessidades bsicas do cliente premissas e restries obtidas na fase de levantamento
do projeto at as condies de negcio explicitadas no contrato com o fornecedor da
soluo.
Compreende um conjunto de definies que descreve como o sistema deve ser
construdo e testado; Requisitos Funcionais e No Funcionais caractersticas
operacionais e especificaes tcnicas enfim, tudo o que o sistema tem que ter para
atender plenamente ao propsito para o qual foi criado.
Anlise de Requisitos o conjunto de atividades que permite identificar as
necessidades do usurio de modo a obter uma definio clara das caractersticas ou
requisitos de um sistema. Essas caractersticas descrevem o sistema em termos de
funcionalidades, desempenho esperado, restries de projeto, nveis de qualidade
esperado, interface com outros elementos do sistema. Processo de estudar as
necessidades do usurio para chegar a uma definio dos requisitos de sistema,
hardware ou software.
Gerncia de Requisitos a parte que estabelece e mantm um entendimento com
o cliente sobre os requisitos para o projeto de software. Este acordo refere-se aos
requisitos do sistema alocados para o software. O cliente pode ser interpretado como o
grupo de engenharia do sistema, o grupo de marketing, outra organizao interna, ou um
cliente externo. O acordo compreende requisitos tcnicos e no tcnicos. O acordo
forma a base para a estimativa, planejamento, execuo e acompanhamento das
atividades do projeto de software atravs do ciclo de vida do software.
Qualidade dos Requisitos a especificao dos requisitos de software requer
clareza absoluta para minimizar mal-entendidos, para isso preciso ter alguma
qualidades. Em nome da clareza os requisitos devem ser:

Necessrios Se o sistema atende a necessidade sem este requisito ele no necessrio

Completos Todas as condies que se aplicam ao requisito esto descritas e o requisito
expressa uma ideia completa;
Corretos Os fatos relacionados ao requisito esto corretos e so tecnicamente e
legalmente possveis;
No Ambguos O requisito s pode ser interpretado de uma nica forma;
Concisos O requisito formulado de forma simples e direta;
Consistentes - O requisito no conflita ou se sobrepe a outro requisito;
Testveis A implementao do requisito pode ser demonstrada / testada;
Realizveis possvel implement-lo dentro do oramento e prazo estabelecido;
Listados O requisito sempre est explcito e nunca est implcito ou nas entrelinhas
do texto;
Imperativos Cada requisito deve retratar algo que o sistema faz ou alguma qualidade
que possui;

3.2.

Certificao de Qualidade

Um aspecto interessante da qualidade que no basta que ela exista. Ela deve ser
reconhecida pelo cliente por causa disso, necessrio que exista algum tipo de
certificao oficial, emitida com base em um padro.
Esse padro de qualidade nada mais que um padro de qualidade pelo qual a
empresa foi avaliada e julgada. Para que seja possvel realizar uma avaliao e um
julgamento, necessrio haver um padro ou norma.
Existem alguns organismos normalizadores reconhecidos mundialmente:
ISO - International Organization for Standardization
IEEE - Instituto de Engenharia Eltrica e Eletrnica
ABNT - Associao Brasileira de Normas Tcnicas
A norma ISO-9000, por exemplo, foi criada pela ISO (International
Organization for Standardization) para permitir que todas as empresas do mundo
possam avaliar e julgar sua qualidade. Existindo um padro nico mundial, uma
empresa do Brasil, mesmo no tendo nenhum contato com uma empresa na Europa
pode garantir a ela a qualidade de seu trabalho. A certificao em uma norma ou padro
a emisso de um documento oficial indicando a conformidade com esta determinada
norma ou padro. Antes da emisso do certificado, preciso realizar todo um processo
de avaliao e julgamento de acordo com uma determinada norma.
Embora uma empresa possa auto-avaliar-se ou ser avaliada por seus prprios
clientes, o termo Certificao costuma ser aplicado apenas quando efetuado por uma
empresa independente e idnea especializada neste tipo de trabalho. No Brasil, o
INMETRO o rgo do governo responsvel pelo credenciamento destas instituies
que realizam a certificao de sistemas de qualidade.

3.2.1. Qualidade de Produtos de Software - ISO 9126

Embora a atual norma ISO 9126/NBR 13596 enumere as caractersticas e

subcaractersticas de um software, ela ainda no define como dar uma nota a um
software em cada um destes itens.
Algumas caractersticas podem ser realmente medidas, como o tempo de
execuo de um programa, nmero de linhas de cdigo, nmero de erros encontrados
em uma sesso de teste ou o tempo mdio entre falhas. Nestes casos, possvel utilizar
uma tcnica, uma ferramenta ou um software para realizar medies. Em outros casos, a
caracterstica to subjetiva que no existe nenhuma forma bvia de medi-la.
Para avaliar uma determinada subcaracterstica subjetiva de forma simplificada,
por exemplo, voc pode criar uma srie de perguntas do tipo "sim ou no". Depois de
prontas as perguntas, basta avaliar o software, respondendo a cada pergunta. Se voc
conseguir listar 10 perguntas e o software obtiver uma resposta "sim" em 8 delas, ter
obtido um valor de 80% nesta caracterstica.
Alguns estudiosos sugerem formas diferentes de medir uma caracterstica,
baseada em conceitos do tipo "no satisfaz", "satisfaz parcialmente", "satisfaz
totalmente" e "excede os padres". Estes conceitos, embora paream muito subjetivos,
no deixam de ser uma forma eficiente de medir uma caracterstica.
Atualmente, a norma ISO/IEC 9126 est sendo revisada. A reviso, que dever
estar pronta nos prximos anos, no dever modificar nenhuma das caractersticas
bsicas das 9126. A maior modificao ser a incluso de dois documentos adicionais
para descrever mtricas externas (relativas ao uso do produto) e mtricas internas
(relativas arquitetura do produto). Veja algumas das modificaes previstas para esta
reviso:
Algumas novas subcaractersticas. Conformidade far parte de todas as caractersticas.
Atratividade ser uma subcaracterstica de usabilidade. Capacidade de coexistir ser
uma subcaracterstica de portabilidade.
A norma ser dividida em trs partes. A primeira (9126-1) incluir definies e
caractersticas. As duas seguintes descrevero mtricas externas (9126-2) e internas
(9126-3).
A verso brasileira da reviso desta norma dever ser chamada de NBR 9126-1, 91262 e 9126-3, segundo a numerao original da ISO/IEC.

3.2.2. Qualidade de Pacotes de Software - ISO 12119

Esta norma foi publicada em 1994 e trata da avaliao de pacotes de software, tambm
conhecidos como "software de prateleira". Alm de estabelecer os requisitos de
qualidade para este tipo de software, ela tambm destaca a necessidade de instrues
para teste deste pacote, considerando estes requisitos.
Um dos grandes mritos desta norma est na profundidade com que so descritas
cada uma das caractersticas e subcaractersticas mencionadas na norma 9126. A norma
inclui detalhes que devem estar presentes no produto, tais como:
Documentao do usurio de fcil compreenso
Um sumrio e um ndice remissivo na documentao do usurio
Presena de um Manual de instalao com instrues detalhadas

 Possibilidade de verificar se uma instalao foi bem sucedida

Especificao de valores limites para todos os dados de entrada, que devero ser
testados.
Operao normal mesmo quando os dados informados esto fora dos limites
especificados
Consistncia de vocabulrio entre as mensagens e a documentao
Funo de auxlio (help) com recursos de hipertexto
Mensagens de erro com informaes necessrias para a soluo da situao de erro
Diferenciao dos tipos de mensagem: confirmao consulta advertncia e erro.
Clareza nos formatos das telas de entrada e relatrios
Capacidade de reverter funes de efeito drstico
Alertas claros para as consequncias de uma determinada confirmao
Identificao dos arquivos utilizados pelo programa
Identificao da funo do programa que est sendo executada no momento
Capacidade de interromper um processamento demorado
Outras caractersticas importantes so a nfase nos testes e os modelos de
relatrios includos. Tudo isso facilita grandemente o trabalho do avaliador.

3.2.3. Qualidade do Processo de Software

Os estudos sobre qualidade mais recentes so na sua maioria voltados para o
melhoramento do processo de desenvolvimento de software. No que a qualidade do
produto no seja importante, ela . Mas o fato que, ao garantir a qualidade do
processo, j se est dando um grande passo para garantir tambm a qualidade do
produto.
O estudo da Qualidade do Processo de Software uma rea ligada diretamente
Engenharia de Software. O estudo de um ajuda a entender e aprimorar o outro. Em
ambas as disciplinas estudam-se modelos do processo de desenvolvimento de software.
Estes modelos so uma tentativa de explicar em detalhes como se desenvolve um
software, quais so as etapas envolvidas. necessrio compreender cada pequena tarefa
envolvida no desenvolvimento.
Entre os estudos nesta rea de maior importncia, podemos citar:
ISO 9000-3 - Normas para aplicao da srie ISO 9000 em processos de software
ISO 12207 - Processos do Ciclo de Vida do Software
CMM (Capability Maturity Model)
PSP (Personal Software Process)
ISO 15504 - SPICE (Software Process Improvement and Capability determination)
Modelo Trillium
Metodologia Bootstrap

 Engenharia de Software Cleanroom

Dentre os trabalhos na rea de Qualidade de Processo de Software, o nico que
realmente norma oficial o ISO 9000-3, que faz parte da srie ISO 9000. Os demais
modelos so normas no oficiais criados por empresas e institutos ou ento so normas
em estgio de desenvolvimento.

3.2.4. A Srie ISO 9000

Esta srie um conjunto de normas da ISO que define padres para garantia e
gerenciamento da qualidade.
ISO 9001 - Modelo para garantia da qualidade em projeto, desenvolvimento, produo,
instalao e assistncia tcnica.
ISO 9002- Modelo para garantia da qualidade em produo e instalao
ISO 9003 - Modelo para garantia da qualidade em inspeo e ensaios finais
ISO 9000-1- Diretrizes para escolher entre as normas ISO 9001, 9002 e 9003.
ISO 9000-3 - Orientao para a aplicao da ISO 9001 em Software
Entre as normas 9001, 9002 e 9003, a primeira a que mais se adqua ao
desenvolvimento e manuteno de software. Como toda norma deste grupo, ela usada
para garantir que um fornecedor atende aos requisitos especificados nos diversos
estados do desenvolvimento.
Estes estgios incluem projeto, desenvolvimento, produo, instalao e suporte.
A norma ISO 9000-3 (no confundir com a ISO 9003) traz os roteiros para
aplicar a ISSO 9001 especificamente na rea de desenvolvimento, fornecimento e
manuteno de software.
Todas as orientaes giram em torno de uma "situao contratual", onde outra
empresa contrata a empresa em questo para desenvolver um produto de software.
O processo de certificao de uma empresa de software segundo as normas ISO
9001 / 9000-3 segue um conjunto de passos bem definidos:
1. A empresa estabelece o seu sistema de qualidade
2. A empresa faz uma solicitao formal a um rgo certificador, incluindo detalhes do
negcio da empresa, escopo da certificao solicitada e cpia do manual de qualidade.
3. O rgo certificador faz uma visita empresa, colhe mais dado e explica o processo
de certificao.
4. O rgo certificador verifica se a documentao do sistema de qualidade est de
acordo com a norma ISO
5. O rgo certificador envia uma equipe empresa com fins de auditoria. Nesta visita,
ser verificado se todos na empresa cumprem o que est documentado no manual de
qualidade.
6. O rgo certificador emite o certificado de qualidade
7. O rgo certificador realiza visitas peridicas empresa para assegurar que o sistema
continua sendo efetivo

3.2.5. ISO 12207 - Processos do Ciclo de Vida do Software

Este padro formaliza a arquitetura do ciclo de vida do software, que um assunto
bsico em Engenharia de Software e tambm em qualquer estudo sobre Qualidade do
Processo de Software.
A norma detalha cada um dos processos acima. Ela define ainda como eles
podem ser usados de diferentes maneiras por diferentes organizaes (ou parte destas),
representando diversos pontos de vista para esta utilizao. Cada uma destas vises
representa a forma como uma organizao emprega estes processos, agrupando-os de
acordo com suas necessidades e objetivos.
As Vises tm o objetivo de organizar melhor a estrutura de uma empresa, para
definir suas gerncias e atividades alocadas s suas equipes. Existem cinco vises
diferentes: contrato, gerenciamento, operao, engenharia e apoio.
A ISO/IEC 12207 a primeira norma internacional que descreve em detalhes os
processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento,
operao e manuteno de produtos de software. A principal finalidade desta norma
servir de referncia para os demais padres que venham a surgir. Lanada em agosto de
1995, ela citada em quase todos os trabalhos relacionados Engenharia de Software
desde ento, inclusive aqueles relativos qualidade. A futura norma ISO 15504
(SPICE), por exemplo, organiza seu trabalho segundo o que est descrito na ISO/IEC
12207.

3.2.6. CMM (Capability Maturity Model)

Capability Maturity Model (CMM), tambm conhecido como Software CMM (SWCMM) pode ser definido como sendo uma soma de "melhores prticas" para
diagnstico e avaliao de maturidade do desenvolvimento de softwares em uma
organizao. "CMM" no deve ser entendido como sendo uma metodologia, pois o
"CMM" no diz exatamente como fazer, mas sim o que deve ser feito (melhores
prticas).
Ele descreve os principais elementos de um processo de desenvolvimento de
software. O CMM descreve os estgios de maturidade por que passam as organizaes
enquanto evolui no seu ciclo de desenvolvimento de software, atravs de avaliao
contnua, identificao de problemas e aes corretivas, dentro de uma estratgia de
melhoria dos processos. Este caminho de melhoria definido por cinco nveis de
maturidade:
1. Inicial
2. Repetvel
3. Definido
4. Gerenciado
5. Otimizado
O CMM fornece s organizaes orientao sobre como ganhar controle do
processo de desenvolvimento de software e como evoluir para uma cultura de
excelncia na gesto de software. O objetivo principal nas transies atravs desses
nveis de maturidade a realizao de um processo controlado e mensurado que tem

como fundamento a melhoria contnua. A cada nvel de maturidade corresponde um

conjunto de prticas de software e de gesto especficas, denominadas reas-chave do
processo. Estas devem ser implantadas para que a organizao possa atingir o nvel de
maturidade desejado.

3.2.6.1.

Modelo de Maturidade

uma coleo estruturada de elementos que descrevem certos aspectos da maturidade

de uma organizao. Um modelo de maturidade fornece, por exemplo:
um ponto de partida
os benefcios dos usurios em experincias anteriores
um vocabulrio comum e uma viso compartilhada
um framework para priorizar aes
uma forma de definir as melhorias mais significativas para uma organizao
Um modelo de maturidade pode ser usado como base para avaliar diferentes
organizaes e estabelecer comparaes. O modelo descreve a maturidade da empresa
baseado nos projetos que ela est desenvolvendo e nos clientes relacionados.

3.2.6.2.

Os 5 Nveis de Maturidade do CMM

Nvel 1 Inicial: Os processos so geralmente ad hoc e caticos. A organizao

geralmente no dispe de um ambiente estvel. O sucesso nessas organizaes depende
da competncia e herosmo dos seus funcionrios e no no uso de processos
estruturados. Devido ao imediatismo, o nvel 1 de maturidade produz produtos e
servios que em geral funcionam, mas frequentemente excedem o oramento e o prazo
dos projetos.
Nvel 2 Repetvel: O desenvolvimento do software repetido. O processo pode
no se repetir para todos os projetos da organizao. A organizao pode usar
ferramentas de Gerncia de Projetos para mapear os custos e o prazo do projeto.
A adoo de um processo de desenvolvimento ajuda a garantir que prticas
existentes sejam utilizadas em momentos de stress. Quando essas prticas so adotadas,
os projetos decorrem (e so gerenciados) de acordo com o planejamento inicial.
O status do projeto e os servios entregues so visveis ao gerenciamento (por
exemplo: possvel a visualizao de marcos do projeto e o trmino da maioria das
tarefas).
Tcnicas de gerenciamento de projetos so estabelecidas para mapear custos,
prazos, e funcionalidades. Um mnimo de disciplina nos processos estabelecido para
que se possam repetir sucessos anteriores em projetos com escopo e aplicao similares.
Ainda h um risco significante de exceder as estimativas de custos e o prazo de
desenvolvimento.
Este nvel apresenta as seguintes KPAs (reas chave de processo):
Gerenciamento de Requisitos
Planejamento de Projetos

 Acompanhamento e Superviso de Projetos

Gerenciamento de Subcontratao
Garantia de Qualidade de Software
Gerenciamento de Configurao
Nvel 3 Definido: Uma organizao alcanou todas as metas genricas e
especficas das reas de processo designadas como de nveis 2 e 3. No nvel 3 de
maturidade, processos so bem caracterizados e entendidos, e so descritos utilizando
padres, procedimentos, ferramentas e mtodos.
A organizao possui um conjunto de padres de processos, os quais so a base
do nvel 3. Estes esto estabelecidos e so melhorados periodicamente. Estes processos
padres so usados para estabelecer uma consistncia dentro da organizao. Projetos
estabelecem seus processos segundo o conjunto de padres processuais da organizao,
de acordo com guias.
O gerenciamento da organizao estabelece os objetivos dos processos baseado
no conjunto de padres predefinidos e garante que estes objetivos sejam encaminhados
de forma apropriada.
Uma crtica distino entre os nveis 2 e 3 o escopo dos padres e a descrio
dos processos e procedimentos. No nvel 2, os padres e a descrio de processos e
procedimentos podem ser bem diferentes em cada instncia especfica do processo (por
exemplo, em um projeto particular). No nvel 3, os padres e a descrio de processos e
procedimentos para o projeto so guiados pelo conjunto de padres de processos da
organizao. O conjunto de padres de processo da organizao inclui os processos do
nvel 2 e 3. Como resultado, os processos realizados atravs da organizao so
consistentes exceto pelas diferenas permitidas pelos guias.
Outra distino crtica que, no nvel 3, processos so geralmente descritos com
mais detalhes e com mais rigor do que no nvel 2. No nvel 3, processos so gerenciados
mais proativamente. H entendimento acerca das inter-relaes entre as atividades dos
processos. H medidas detalhadas dos processos, produtos e servios.
KPAs deste nvel:
Revises (peer review)
Coordenao de Intergrupos
Engenharia de Produto de Software
Gerenciamento de Software Integrado
Programa de Treinamento
Definio do Processo da Organizao
Foco no Processo da Organizao
Nvel 4 Gerenciado: Utilizando mtricas precisas, o gerenciamento pode
efetivamente controlar os esforos para desenvolvimento de software. Em particular, o
gerenciamento pode identificar caminhos para ajustar e adaptar o processo a projetos
particulares, sem perda de mtricas de qualidade ou desvios das especificaes.

Organizaes neste nvel conseguem metas quantitativas para o processo de

qualitativamente, desenvolvimento de software e de manuteno.
Subprocessos so selecionados conforme a importncia no desempenho total do
processo. Esses subprocessos selecionados so controlados usando tcnicas estatsticas e
quantitativas.
Uma distino crtica entre o nvel de maturidade 3 e 4 a previsibilidade do
desempenho do processo. No nvel 4, o desempenho do processo controlado usando
tcnicas estatsticas e quantitativas, e previsvel quantitativamente. No nvel 3, os
processos so somente previsveis
Nvel 5: Otimizado
No nvel 5, uma organizao adquiriu todas as metas especficas das reas de
processo dos nveis 2, 3, 4, e 5 e as metas genricas dos nveis 2 e 3. Processos so
continuamente melhorados com base no entendimento quantitativo das causas comuns
de variao inerente aos processos.
No nvel de maturidade 5, o foco o contnuo progresso do desempenho dos
processos, atravs da introduo de melhorias de inovao tecnolgica e incremental.
Objetivos de melhoria quantitativa dos processos para a organizao so estabelecidos,
continuamente revisados, refletindo as mudanas nos objetivos da organizao, e
usando critrios de melhoria na gerncia de processos.
Os efeitos da melhoria da reviso dos processos so medidos e acompanhados,
utilizando-se processos de melhoria de qualidade. Os processos definidos e o conjunto
de processos padres da organizao so alvos de melhoria de mtricas.
Uma distino crtica entre os nveis 4 e 5 o tipo de variao do processo. No
nvel 4, o interesse verificar as causas especiais de variao de processo e fornecer
resultados estatsticos. No nvel 5, o foco so as causas comuns de variao de processo
e a introduo de mudanas de modo a melhorar a performance do processo, atingindo
objetivos quantitativos.

3.2.7. CMMI
O CMMI (Capability Maturity Model Integration) um modelo de referncia que
contm prticas (Genricas ou Especficas) necessrias maturidade em disciplinas
especficas (Systems Engineering (SE), Software Engineering (SW), Integrated Product
and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI
(Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI uma
evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria
corporativo, integrando diferentes modelos e disciplinas.
A verso atual do CMMI (verso 1.2) apresenta trs modelos:
CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao
processo de desenvolvimento de produtos e servios.
CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se aos
processos de aquisio e terceirizao de bens e servios.
CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009. Dirige-se aos
processos de empresas prestadoras de servios.

3.2.8. SPICE (Software Process

Determination) -ISO 15504

Improvement

and

Capability

O SPICE uma norma em elaborao conjunta pela ISO e pelo IEC. Ela constitui-se de
um padro para a avaliao do processo de software, visando determinar a capacitao
de uma organizao. A norma visa ainda orientar a organizao para uma melhoria
contnua do processo. Ela cobre todos os aspectos da Qualidade do Processo de
Software e est sendo elaborada num esforo conjunto de cinco centros tcnicos
espalhados pelo mundo (EUA, Canad/Amrica Latina, Europa, Pacfico Norte e
Pacfico Sul).
O SPICE inclui um modelo de referncia, que serve de base para o processo de
avaliao.
Este modelo um conjunto padronizado de processos fundamentais, que
orientam para uma boa engenharia de software. Este modelo dividido em cinco
grandes categorias de processo: Cliente-Fornecedor, Engenharia, Suporte, Gerncia e
Organizao. Cada uma destas categorias detalhada em processos mais especficos.
Tudo isso descrito em detalhes pela norma.
O SPICE inclui um modelo de referncia, que serve de base para o processo de
avaliao.
Este modelo um conjunto padronizado de processos fundamentais, que
orientam para uma boa engenharia de software. Este modelo dividido em cinco
grandes categorias de processo: Cliente-Fornecedor, Engenharia, Suporte, Gerncia e
Organizao. Cada uma destas categorias detalhada em processos mais especficos.
Tudo isso descrito em detalhes pela norma.
Alm dos processos, o SPICE define tambm os 6 nveis de capacitao de cada
processo, que pode ser incompleto, executado, gerenciado, estabelecido, previsvel e
otimizado. O resultado de uma avaliao, portanto, um perfil da instituio em forma de
matriz, onde temos os processos nas linhas e os nveis nas colunas.

3. Metodologia
Para este trabalho foi realizada extensa reviso bibliogrfica em materiais como livros,
artigos e sites da Internet. O passo posterior foi gerado a partir de prottipos integrados
simplificados, ou seja, em partes menores, que ao final, foram unidas para compor o
projeto.

Concluso

Referncias
Koscianski, A. e Soares, S. M. (2007)"Qualidade de Software", Editora Novatec: So
Paulo, Brasil.
Simes, A. (2007) Qualidade de Software.
<http://www.slideshare.net/alsimoes/qualidade-de-software >.
10/10/2012.

Acesso

em

Scaraboto, E. D. (2011) Normas da SBC.

<http://pt.scribd.com/doc/61117531/modelo-de-artigo-de-pesquisaformatado-nas-normas-da-sbc>. Acesso em 09/10/2012.