Qualidade de Software PDF

Universidade do Sul de Santa Catarina
Qualidade de Software
Disciplina na modalidade a distância
Palhoça
UnisulVirtual
2007
qualidade_software.indb 1 24/1/2007 13:14:01

Apresentação
Parabéns, você está recebendo o livro didático da disciplina

Qualidade de software.
O processo de ensino e aprendizagem na UnisulVirtual leva

em conta instrumentos que se articulam e se complementam,
portanto, a construção de competências se dá sobre a articulação
de metodologias e por meio das diversas formas de ação/
mediação.
São elementos desse processo:
O Livro didático;
O EVA (Espaço UnisulVirtual de Aprendizagem);
Atividades de avaliação (complementares, a distância e
presenciais).
Os materiais didáticos foram construídos especialmente para

este curso, levando em consideração o seu perfil e as necessidades
da sua formação. Como os materiais estarão, a cada nova
versão, recebendo melhorias, pedimos que você encaminhe suas
sugestões sempre que achar oportuno via professor tutor ou
monitor.
Recomendamos que antes de você começar os seus estudos,

verifique as datas-chave e elabore o seu plano de estudo pessoal,
garantindo assim a boa produtividade no curso. Lembre: você
não está só nos seus estudos. Conte com o Sistema Tutorial
da UnisulVirtual sempre que precisar de ajuda ou alguma
orientação.
Desejamos que você tenha um excelente êxito neste curso!
Equipe UnisulVirtual

Vera Rejane Niedersberg Schuhmacher
Livro didático
3ª edição revista e atualizada
Design instrucional
Dênia Falcão de Bittencourt
Viviane Bastos
Palhoça
UnisulVirtual
2007

Copyright © UnisulVirtual 2007
Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.
005.3
S41 Schuhmacher, Vera Rejane Niedersberg
Qualidade de software : livro didático / Vera Rejane Niedersberg
Schuhmacher ; design instrucional Dênia Falcão de Bittencourt, Viviane Bastos.
- 3 ed. rev. e atual. - Palhoça : UnisulVirtual, 2007.
122 p. : il. ; 28 cm.
Inclui bibliografia.
ISBN 978-85-7817-000-4
1. Software. 2. Sistemas de recuperação da informação. I. Bittencourt, Dênia

Falcão de. II. Bastos, Viviane. III. Título.
Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul
Créditos
Unisul - Universidade do Sul de Santa Catarina
UnisulVirtual - Educação Superior a Distância
Campus UnisulVirtual Bibliotecária Equipe Didático-Pedagógica Monitoria e Suporte Secretária Executiva
Rua João Pereira dos Santos, 303 Soraya Arruda Waltrick Angelita Marçal Flores Rafael da Cunha Lara (coordenador) Viviane Schalata Martins
Palhoça - SC - 88130-475 Carmen Maria Cipriani Pandini Adriana Silveira
Fone/fax: (48) 3279-1541 e Coordenação dos Cursos Caroline Batista Caroline Mendonça Tecnologia
3279-1542 Adriano Sérgio da Cunha Carolina Hoeller da Silva Boeing Dyego Rachadel Osmar de Oliveira Braz Júnior
E-mail: cursovirtual@unisul.br Ana Luisa Mülbert Cristina Klipp de Oliveira Edison Rodrigo Valim (coordenador)
Site: www.virtual.unisul.br Ana Paula Reusing Pacheco Daniela Erani Monteiro Will Francielle Arruda Ricardo Alexandre Bianchini
Cátia Melissa S. Rodrigues (Auxiliar) Dênia Falcão de Bittencourt Gabriela Malinverni Barbieri Rodrigo de Barcelos Martins
Reitor Unisul Charles Cesconetto Enzo de Oliveira Moreira Gislane Frasson de Souza
Gerson Luiz Joner da Silveira Diva Marília Flemming Flávia Lumi Matuzawa Josiane Conceição Leal
Itamar Pedro Bevilaqua Karla Leonora Dahse Nunes Maria Eugênia Ferreira Celeghin Edição – Livro Didático
Vice-Reitor e Pró-Reitor Janete Elza Felisbino Leandro Kingeski Pacheco Simone Andréa de Castilho
Acadêmico Jucimara Roesler Ligia Maria Soufen Tumolo Vinícius Maycot Serafim Professor Conteudista
Sebastião Salésio Heerdt Lilian Cristina Pettres (Auxiliar) Márcia Loch Vera Rejane N. Schuhmacher
Lauro José Ballock Patrícia Meneghel Produção Industrial e Suporte
Chefe de gabinete da Reitoria Luiz Guilherme Buchmann Silvana Denise Guimarães Arthur Emmanuel F. Silveira Design Instrucional
Fabian Martins de Castro Figueiredo Tade-Ane de Amorim (coordenador) Dênia Falcão de Bittencourt
Luiz Otávio Botelho Lento Vanessa de Andrade Manuel Francisco Asp Viviane Bastos
Marcelo Cavalcanti Vanessa Francine Corrêa
Pró-Reitor Administrativo
Mauri Luiz Heerdt Viviane Bastos Projetos Corporativos Projeto Gráfico e Capa
Marcus Vinícius Anátoles da Silva
Mauro Faccioni Filho Viviani Poyer Diane Dal Mago Equipe UnisulVirtual
Ferreira
Michelle Denise Durieux Lopes Destri Vanderlei Brasil
Moacir Heerdt Logística de Encontros Diagramação
Campus Sul
Nélio Herzmann Presenciais Secretaria de Ensino a Distância Vilson Martins Filho
Diretor: Valter Alves Schmitz Neto Evandro Guedes Machado
Onei Tadeu Dutra Marcia Luz de Oliveira Karine Augusta Zanoni
Diretora adjunta: Alexandra Orsoni (3ª edição)
Patrícia Alberton (Coordenadora) (secretária de ensino)
Patrícia Pozza Aracelli Araldi Ana Paula Pereira
Campus Norte Revisão Ortográfica
Raulino Jacó Brüning Graciele Marinês Lindenmayr Djeime Sammer Bortolotti
Diretor: Ailton Nazareno Soares B2B
José Carlos Teixeira Carla Cristina Sbardella
Diretora adjunta: Cibele Schuelter
Design Gráfico Letícia Cristina Barbosa Grasiela Martins
Cristiano Neri Gonçalves Ribeiro Kênia Alexandra Costa Hermann James Marcel Silva Ribeiro
Campus UnisulVirtual Priscila Santos Alves
(coordenador) Lamuniê Souza
Diretor: João Vianney
Adriana Ferreira dos Santos Liana Pamplona
Diretora adjunta: Jucimara Roesler
Alex Sandro Xavier Logística de Materiais Maira Marina Martins Godinho
Evandro Guedes Machado Jeferson Cassiano Almeida da Costa Marcelo Pereira
Fernando Roberto Dias Zimmermann (coordenador) Marcos Alcides Medeiros Junior
Equipe UnisulVirtual Higor Ghisi Luciano Eduardo Kraus Maria Isabel Aragon
Pedro Paulo Alves Teixeira Olavo Lajús
Administração Rafael Pessi Priscilla Geovana Pagani
Renato André Luz Vilson Martins Filho Silvana Henrique Silva
Valmir Venício Inácio
Sumário
Palavras da professora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 09
Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
UNIDADE 1 – O que é qualidade? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

UNIDADE 2 – Qualidade do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
UNIDADE 3 – Qualidade do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
UNIDADE 4 – Métricas de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Sobre a professora conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Respostas e comentários das atividades de auto-avaliação . . . . . . . . . . . . 115

Palavras da professora
Bem-vindo a disciplina Qualidade de software! Nesta

disciplina você vai explorar conceitos e conhecer alguns
padrões de qualidade reconhecidos por empresas
desenvolvedoras de software. Mas você já parou para
pensar sobre o significado da palavra qualidade para
você? Nos dias atuais o termo qualidade está presente
no seu cotidiano, em comerciais de TV, na propaganda
de prefeituras e do governo, no trabalho, em hospitais e
na divulgação dos mais diversos produtos, do iogurte ao
sabão em pó que você compra.
Isto acontece porque as organizações que buscam o

sucesso empresarial devem estar preparadas para aceitar
grandes desafios técnicos e aproveitar as oportunidades
de negócios através da implantação de um processo
contínuo de transformação e melhoria da qualidade de
seus produtos.
Definir qualidade é uma tarefa difícil, a palavra pode

assumir diversos significados, seu conceito varia
conforme os contextos e até conforme as pessoas. Fatores
pessoais (de cada um de nós), condições econômicas e
sociais ajudam o ser humano na definição se um produto
“é ou não é “de qualidade, considerando se pode ou não
adquiri-lo ou mesmo utilizá-lo.
Você, seus amigos e familiares reconhecem na maioria

das vezes a representação da qualidade por selos como
no caso dos selos de certificação autorizadas pela
International Organization for Standardization – ISO não
é mesmo?

Porém, mesmo reconhecendo este símbolo, muitas vezes não
sabemos claramente seu significado em termos de qualidade.
Apesar destas dúvidas sabe-se que a qualidade é uma questão
que começa a se inserir no dia a dia tanto de produtores como
de utilizadores, é tratada como estratégia fundamental para o
sucesso da empresa no mercado.
Nesta disciplina você vai estudar a importância da qualidade do

processo de software e do produto de software e a importância
do uso de medidas para o desenvolvimento de qualidade. Faça
também parte deste universo, ao estudar as quatro unidades
propostas nesta disciplina, você vai entender porque é impossível
produzir software sem pensar em qualidade e quais as normas
que existem para apoiar as empresas neste processo!
Bons estudos!
Profa. Vera Rejane Niedersberg Schuhmacher.

Plano de estudo
O plano de estudos visa orientar você no

desenvolvimento da disciplina. Ele possui elementos
que o ajudarão a conhecer o contexto da disciplina e a
organizar o seu tempo de estudos.
Ementa
Definição da qualidade. Conceitos, políticas e filosofia da
qualidade. Componentes básicos da função de qualidade.
Ciclos dos produtos. Programas da qualidade. Qualidade
de processo e produto. As principais referências
acadêmicas e normativas do Brasil e do mundo.
Créditos: 2
Objetivos da disciplina
Os objetivos definem o conjunto de conhecimentos
que você precisa assimilar para o desenvolvimento de
habilidades e competências necessárias à sua formação.
Sensibilizar o aluno da importância da qualidade

no processo de desenvolvimento de software.
Oferecer ao aluno a possibilidade de reconhecer
diferentes normas, observar as necessidades da
empresa e saber reconhecer a que mais se adapta
as necessidades da empresa desenvolvedora.
Incentivar a curiosidade do aluno para a
continuação e aprofundamento de seus estudos
na área de qualidade.

Conteúdo/ tempo de dedicação/ objetivos
Conheça, a seguir, as unidades que compõem este livro didático
e os seus respectivos objetivos. Atente que estes objetivos se
referem aos resultados que você precisa alcançar ao final de cada
unidade de estudo.
A qualidade nas empresas de software é uma realidade, a

implantação e o alcance de seus objetivos devem ser conhecidos
para o desenvolvedor de projetos. O conhecimento sobre normas
e processos que levem a qualidade do produto ou do processo
devem fazer parte do dia a dia sendo básicas para a formação
completa do aluno. Sendo assim a disciplina é fundamental
para a formação do aluno no sentido de integrá-lo ao processo,
instigá-lo a utilizar-se de seus métodos e padrões promovendo
a discussão e o debate sobre sua importância no contexto de
desenvolvimento.
Unidade 1 - O que é qualidade?

Dedicação prevista para estudo: 5 horas.
Na primeira unidade é você que irá interagir com os conceitos

básicos de qualidade. Sua importância no mercado atual e
possíveis utilizações a partir dos mecanismos certificadores
existentes. Também irá compreender quais são os passos
necessários para a condução de um programa de qualidade, assim
como a proposta de atividades de garantia de qualidade.
Unidade 2 - Qualidade do processo

A unidade 2 levará você a conhecer o conceito de qualidade

no processo de software. A qualidade do processo de software
envolve conceitos relacionados a todas as atividades presentes
no desenvolvimento do software. Também irá entender nesta
unidade normas e padrões reconhecidos internacionalmente
que promovem a qualidade do processo de desenvolvimento de
software.
12

Unidade 3 - Qualidade do produto
Ao estudar a unidade 3 você irá conhecer as normas utilizadas
na avalição da qualidade do produto, bem como, poderá
compreender os objetivos e características das mesmas.
Unidade 4 - Métricas de teste

Ao estudar a unidade 4 você irá perceber a importância do uso

de métricas no processo de desenvolvimento de software e seu
impacto no processo de qualidade. Serão vistas técnicas diretas
como o LOC e o Ponto por Função, assim como o novo modelo
de mensuração existente no mercado o PSM - Practical Software
Measurement.
Agenda de atividades
Verifique com atenção o cronograma no “EVA”, organize-se
para acessar periodicamente o espaço das disciplinas cursadas.
Lembre-se que o sucesso nos seus estudos depende da priorização
do tempo para a leitura, da realização de análises e sínteses do
conteúdo e da interação com os seus colegas e professor tutor.
Não perca os prazos das atividades. Registre no espaço a seguir

as datas-chave com base no cronograma disponibilizado no EVA.
Tenha por hábito, usar o quadro para agendar e programar as
atividades relativas ao desenvolvimento da Disciplina.
13

Atividades
Avaliação a Distância 1
Avaliação Presencial
Avaliação Final
Demais atividades (registro pessoal)
14

1
UNIDADE 1
O que é qualidade?
Objetivos de aprendizagem
Após estudar esta unidade, você terá subsídios para:
Interagir com conceitos fundamentais relacionados à
qualidade.
Perceber a necessidade de qualidade no processo de

trabalho de empresas de desenvolvimento de software.
Entender o conceito de SQA – Software Quality

Assurance.
Seções de estudo
Nesta unidade a proposta é que você realize o estudo

das seguintes seções:
Seção 1 O que é qualidade?
Seção 2 Passos em direção a política de qualidade
Seção 3 Atividades da garantia de qualidade.
Seção 4 Normas e Padrões
Após a leitura dos conteúdos realize as atividades de

auto-avaliação propostas. Encaminhe suas dúvidas ao
professor tutor sempre que julgar necessário.

Para início de estudo

Falar sobre qualidade parece banal, entretanto, é um assunto
que está em nosso dia a dia, é moderno e atual. É certo que você
ao ser questionado sobre qualidade quase que imediatamente
consegue formar uma opinião sobre o assunto. Esta opinião
baseia-se na maioria das vezes, em experiências pessoais
relacionadas ao nosso cotidiano.
Mas o que é qualidade em uma empresa? Quais suas

implicações em uma empresa que desenvolve software? Como
implantar um processo de controle de qualidade em uma
organização?
Difíceis de responder, estas questões nos levam imediatamente

a pensar que qualidade, com certeza é sinônimo de perfeição.
Mas qualidade não é sinônimo de perfeição. Qualidade é algo
relativo, dinâmico por natureza e naturalmente evolutivo.
A qualidade possui uma característica única: o

tratamento de qualidade em uma empresa de
software depende da especificidade dos objetivos
definidos pela empresa e das atividades delineadas
para atingir estes objetivos.
A crescente competitividade do mercado de software impulsiona

as empresas a melhorar a qualidade de seus produtos, processos e
mecanismos. Esta evolução é muitas vezes iniciada sem que para
a organização esteja claro o real significado desta iniciativa e suas
implicações a curto e longo prazo.
Qualidade pode ser o diferencial de uma empresa, pode alavancar

seu sucesso, mas ... sua inexistência ou mau planejamento pode
determinar seu fracasso.
Então ? Está curioso a seguir seus estudos? Siga em frente e dê

início a este assunto tão importante no mercado atual!
16

SEÇÃO 1 – O que é qualidade?

Qualidade é um conceito complexo, porque possui significados
diversos para diferentes pessoas, e se apresenta de forma
altamente dependente, conforme o contexto.
Portanto, não é nada fácil estabelecer a existência de medidas

simples de qualidade aceitáveis para todos.
Para estimar ou melhorar a qualidade de software

numa organização, segundo Kitchenham et
al. (1996), é preciso definir as características de
qualidade que se está interessado e, então, decidir
como serão medidas.
Diferentes conceitos expressam a qualidade de um produto de

software, e estes conceitos baseiam-se em visões diferenciadas
conforme a função do indivíduo ou sua posição no processo de
desenvolvimento.
Você pode dizer que:
qualidade é estar em conformidade com os requisitos

dos clientes, neste caso qualidade se exprime a partir
da satisfação de todas as necessidades expressas pelo
cliente durante a análise de requisitos.
qualidade é antecipar e satisfazer os desejos dos clientes,
neste caso observa-se que a partir de um produto
existente o desenvolvedor procure a evolução do produto,
acrescentando novas funcionalidades ou apropriando o
produto com novas tecnologias, muitas vezes antes do
cliente solicitar uma evolução do produto.
Um exemplo disto é o caso de lançamentos de novos

modelos de celulares. Lembra dos primeiros celulares
que realmente só serviam para você realizar uma
ligação telefônica? Agora com a implementação
de funcionalidades como escutar músicas, e-mail, LG Smart Cam MG200
interatividade, recursos de gravação de áudio, vídeo e GSM Claro com Câmera
fotos, etc... a indústria está antecipando os desejos do Integrada <http://www.
cliente. lge.com.br>
Unidade 1 17

E finalmente, você pode expressar o termo qualidade

simplesmente dizendo que é escrever tudo o que se deve
fazer e fazer tudo o que foi escrito, neste caso, o reflexo
do desenvolvimento precisa assegurar que tudo o que foi
documentado será realizado pelo desenvolvedor.
1.1. E a qualidade de software?

Pressman (1992 p.125) define a qualidade de software como a
“concordância com os Requisitos Funcionais e de

Desempenho claramente colocados, Padrões de
Desenvolvimento explicitamente documentados e
características implícitas que são esperadas de todo
software profissionalmente desenvolvido”.
Onde:
Requisitos de Software - formam a base a partir da qual

a qualidade é avaliada. Representam as necessidades na
forma de funcionalidades solicitadas pelo cliente. Falta
de concordância com os requisitos é falta de qualidade.
Padrões especificados definem um conjunto de critérios
de desenvolvimento que orientam a maneira como o
software é construído. Se o critério não for seguido,
certamente haverá falta de qualidade.
Requisitos Implícitos que na maioria das vezes não
são mencionados, também conhecidos como requisitos
não funcionais. (Ex: a possibilidade de portabilidade
para diferentes sistemas operacionais, a necessidade de
segurança em um site de e-commerce). Se o software
atende aos requisitos explícitos, mas falha nos requisitos
implícitos, a qualidade é suspeita.
Em 1990, Campos descreveu qualidade de software como uma
tríade construída sobre os seguintes fatores:
A qualidade intrínseca do produto ou serviço que pode

ser atestada por sua conformidade com as normas.
O custo que corresponde ao preço pelo qual o usuário se
dispõe a pagar.
18

E o atendimento que pode ser entendido como

a satisfação do usuário quanto a tempo, espaço e
quantidade.
Você percebeu que o conceito de qualidade difere de autor para

autor, mas todos os conceitos apontam para uma mesma direção:
a satisfação das necessidades do usuário. E para se alcançar
esta satisfação é necessário que a empresa desenvolvedora passe
a considerar qualidade como um trabalho contínuo, conquistado
diariamente na busca pela melhoria dos produtos e/ou do
processo de desenvolvimento.
1.2. Por que qualidade ?

Quando se aborda o problema da qualidade, você precisa ter claro
o que se entende por qualidade de software. Mais claro ainda
precisa estar a razão pela qual você deve se preocupar com a
qualidade de software.
Acompanhe a seguir alguns fatores interessantes:
O uso de um software com bugs não é nada agradável,

além de trazer prejuízos para o cliente. (Imagine uma
página de e-commerce com bug no formulário de compras,
muitos clientes deixarão de comprar até que o problema
seja resolvido. Um bug pode fazer um banco perder
milhões e perder a confiança dos correntistas).
O aumento de qualidade sempre é acompanhado
por aumento de produtividade e redução de custos.
Como? Você vai ter menos re-trabalho e menor índice
de refugo. Na terceira via você terá um aumento na
satisfação do cliente o que pode refletir nas vendas do
produto.
Qualidade hoje é sinônimo de competitividade. Em
um mercado tão acirrado o cliente hoje exige do
desenvolvedor a comprovação de que seu produto
realmente apresenta quesitos de qualidade, isto se dá na
maioria das vezes pelo uso de certificações internacionais.
A seguir acompanhe uma reportagem que apresenta bem a
importância da qualidade de software e o mercado brasileiro na
atualidade.
Unidade 1 19

Exportação de Software e o CMMI

Por Plínio Ventura, publicado em 8 de novembro de 2005, disponível em
http://www.timaster.com.br/revista/new_artigos.asp
Atualmente, estamos presenciando a busca das empresas

nacionais pelo aumento na exportação de software. De
acordo com o levantamento da IPSOS (www.ipsos.com.
br), 48% das empresas brasileiras de desenvolvimento
de software pretendem aumentar as exportações nos
próximos cinco anos.
Conforme informado pelo Ministério da Ciência e

Tecnologia (www.mct.gov.br), esse nicho com um enorme
potencial de negócios é hoje liderado pela Índia, China
e Canadá. No Brasil, existe a Softex – Associação para
Promoção da Excelência do Software Brasileiro – que foi
criada com objetivo de gerar exportações na ordem de US$
1 bilhão, mas que atualmente gera exportação na ordem de
US$ 100 milhões.
Das 3.265 empresas de software brasileiras, somente

2,1% exportaram seus produtos ou serviços em 2004,
de acordo com um estudo da consultoria em TI, MBI.
Outro estudo conduzido pelo Massachussets Institute of
Tecnology, posiciona o Brasil como o 7º maior mercado
do mundo em vendas de software, tendo atingido o total
de US$ 7,7 bilhões no ano de 2001. Seguindo essa mesma
pesquisa, a qualidade e o grau de sofisticação dos produtos
desenvolvidos no país são similares aos produzidos na Índia
e China.
Quanto à venda interna, boa parte refere-se à software

desenvolvido externamente, dentre os quais podemos citar
fabricantes como Microsoft, Oracle, SAP entre outros. E
quanto à qualidade, a similaridade datada de 2001 é vaga,
pois não foram apresentados detalhes da conclusão.
20

Imagine sua empresa exportando software para a

Inglaterra. Sua empresa não é conhecida mas precisa
ser apresentada a este mercado internacional, uma
boa carta de referência pode ser uma certificação de
qualidade reconhecida internacionalmente ! (como
uma norma ISO por exemplo).
Quando você inicia um programa de qualidade em

uma empresa, deve ter em mente a necessidade de
estabelecer aspectos técnicos (desenvolvimento de
padrões e técnicas que possibilitem a implementação
de todas as atividades) e culturais (todos na
empresa devem aceitar a prática da qualidade, todos
os funcionários devem estar conscientes de suas
responsabilidades dentro do processo).
A decisão de desenvolver a empresa neste sentido

passa por programas de educação e treinamento
sobre qualidade para todos os membros da equipe.
Quando você dá partida em um processo de qualidade tenha

em mente que a qualidade ocorre pelo elo de pequenas ações,
onde cada uma delas é fundamental para se atingir o objetivo
maior. A qualidade está diretamente ligada ao trabalho de cada
funcionário, do analista de requisitos ao responsável pelo suporte
ao cliente.
Agora que você compreendeu a importância da qualidade de

software, siga para a próxima seção e descubra quais são os passos
a serem seguidos na direção da qualidade.
Unidade 1 21

SEÇÃO 2 – Passos em direção a política de qualidade

Quando a empresa decide por uma política de qualidade, dois
escopos são bem definidos:
aprimorar o processo de desenvolvimento e, em

conseqüência, melhorar a qualidade do produto
resultante;
avaliar a qualidade do produto visando emitir
documento oficial sobre a qualidade de um software e sua
conformidade em relação a uma norma ou padrão;
Definido o escopo que se pretende atingir existem dois passos
importantes para dar partida neste processo:
Preparação de uma política de qualidade – a gerência

da empresa deve formular a política de qualidade
desejada, validando-a para que posteriormente seja
comunicada e implantada em todos os segmentos da
empresa;
Estabelecer uma equipe de suporte em qualidade
– ao implementar uma política de qualidade torna-
se necessário estabelecer um quadro de funcionários
responsáveis pelo aumento da qualidade, esta equipe
será responsável por estabelecer e manter um programa
de qualidade em toda a organização incluindo tarefas
como planejamento, monitoramento e avaliação
dos procedimentos adotados. A gerência deve estar
representada em um comitê de qualidade diretamente
ligado a equipe de execução do projeto de qualidade.
Em uma empresa de software você tem a possibilidade de avaliar

a qualidade do processo de software e a qualidade do produto de
software.
22

Qual a diferença entre qualidade do processo de

software e a qualidade do produto de software?
O processo de software é formado pelo conjunto

de atividades, métodos, práticas e tecnologias
utilizadas para desenvolver e manter
software e produtos relacionados.
Quando é avaliado o processo de
software, avaliam-se todas as etapas do
processo de produção do produto, da
análise do problema a manutenção do
mesmo no cliente. Se a empresa possui um
processo de desenvolvimento imaturo, seu projeto não
é rigorosamente cumprido, o controle da qualidade e as
funcionalidades do produto podem ficar comprometidos
pois os prazos devem ser cumpridos, os custos de
manutenção podem ser elevados. Todo o projeto pode
ficar comprometido.
Quando é avaliada a qualidade do produto de software
você estará avaliando o produto desenvolvido pela
empresa, não se preocupando basicamente com o
processo de desenvolvimento do mesmo, mas sim com
a qualidade externa que deve estar explicitamente
definida na Especificação de Requisitos do Projeto e
pela qualidade interna formada por atributos que são
geralmente acrescentados pela empresa.
Como buscar a qualidade?
Assim como é difícil chegar a um consenso sobre o conceito de

qualidade, também são grandes as diferenças entre técnicas e
métodos para obtê-la.
Os softwares podem ser divididos em dois grandes grupos:
Unidade 1 23

Pacotes ou suítes: compõem a maioria dos programas

aplicativos, programasde aquisição e uso praticamente
imediato que atendem ao grande público em geral.
São programas planejados para um usuário comum,
padrão, logo podem não corresponder a exigências mais
específicas.
Softwares personalizados, são planejados e escritos
geralmente por programadores e consultores para atender
a uma determinada tarefa específica. Na maioria das
vezes, o número de usuários que irá utilizá-lo é restrito.
Quando você fala de qualidade de software para estes dois grupos,

deve lembrar que a estratégia proposta para se alcançar esta meta
passa obrigatoriamente por diferentes fatores.
Um produto de software personalizado tem um público-

alvo conhecido que normalmente possui um vínculo com a
empresa desenvolvedora. No caso dos pacotes, este público é
desconhecido, sendo possível estudá-lo apenas por meio de
amostras e o vínculo com os desenvolvedores, na maioria das
vezes não existe.
SEÇÃO 3 – Atividades da garantia de qualidade

As atividades de garantia de qualidade - SQA – Software Quality
Assurance apontam para atividades que devem apoiar o processo
de desenvolvimento de qualidade. Pressman (1992) descreve as
7 atividades necessárias para que o processo ocorra de forma
eficiente:
I - Aplicação de métodos e ferramentas técnicas pelos

desenvolvedores que apóiem o projeto, especificações e
desenvolvimento de maior qualidade;
II - Realização de revisões técnicas onde o objetivo

deve ser avaliar a qualidade do artefato de software
gerado pela etapa do desenvolvimento (especificação,
modelagem, casos de teste...);
24

III - Atividades de testes que devem complementar as

revisões e outras técnicas ajudando na detecção de erros;
IV - Aplicação de padrões na documentação, no projeto,

no estilo de codificação, na aplicação de testes, no
processo, etc.
A documentação torna o processo de software visível, por

isto deve ser consistente e legível. Os padrões podem ser
determinados por normas internacionais ou pela empresa
por possuir um padrão interno para o processo;
V - Controle de alterações, mudanças no software

tendem a produzir novos erros ou mesmo problemas em
outros módulos do sistema. O controle de mudanças
durante o desenvolvimento e a manutenção é essencial
para garantir a qualidade, pois permite rastrearmos o
problema e também tornar a alteração conhecida por
toda a equipe de desenvolvimento;
VI - Medição, é necessário estabelecer métricas para

rastrear a qualidade do software. Medindo, poderemos
saber se as ações de melhoria deram resultado,
poderemos mostrar à administração que os recursos
destinados às melhorias foram bem empregados.
Medições também são usadas para indicar a qualidade

do produto, a produtividade das pessoas que produzem
o produto, para a avaliar benefícios derivados de novos
métodos e ferramentas e para justificar pedidos de novas
ferramentas ou treinamento. Um exemplo de métrica de
produto são as técnicas que medem o comprimento de
um módulo em linhas de código e o número de módulos
chamados por outro módulo;
VII - Manutenção de registros, manter histórico com

resultados de revisões, auditorias, controle de alterações e
outras atividades de garantia de qualidade, que devem ser
levados ao conhecimento dos desenvolvedores.
O item 2 sobre revisões técnicas é um dos pontos determinantes

do SQA.
Unidade 1 25

As revisões devem ser aplicadas em vários pontos durante o

desenvolvimento do software. Para realizá-las você vai utilizar
a diversidade de um grupo de pessoas para apontar melhorias
necessárias ao produto, confirmar as partes de um produto em
que uma melhoria não é desejada ou não é necessária, realizar um
trabalho técnico com uma qualidade mais uniforme de forma a
tornar este trabalho técnico mais administrável.
As revisões podem ser feitas de diferentes maneiras:
Discussão de um problema técnico na hora do café

(quantas vezes você ficou horas e horas tentando resolver
um problema, e simplesmente não conseguiu?). Durante
um momento informal (tomando um cafezinho com
seu colega) você pode chegar a esta solução, talvez por
sugestão do seu interlocutor ou porque você relaxou e
conseguiu enxergar a famosa “luz no final do túnel”;
Apresentação do projeto de software para uma audiência
de clientes, administradores e pessoal técnico. Imagine
que você vá apresentar a primeira solução de design da
página, uma apresentação perante o cliente vai validar
suas idéias com as exigências do cliente;
Revisões Técnicas Formais inclui avaliações técnicas de
software realizadas em pequenos grupos (walkthrough).
Em uma revisão técnica formal tem-se objetivos claros:
Descobrir erros de função, lógica ou implementação em

qualquer representação do software;
Verificar se o software que se encontra em revisão atende
a seus requisitos;
Garantir que o software tenha sido representado de
acordo com padrões predefinidos;
Obter um software que seja desenvolvido uniformemente;
Tornar os projetos mais administráveis.
Além destes objetivos, você vai ter o ganho de um espaço de

treinamento que possibilita tanto ao bolsista quanto ao gerente de
26

projeto, a observação e interação sobre diferentes abordagens, a

análise, projeto e implementação de software.
Outro ponto forte da revisão formal é a promoção do backup

e continuidade. Várias pessoas se familiarizam com partes do
software que de outro modo, poderiam não conhecer.
Lembre-se: a revisão técnica formal é conduzida em

uma reunião e será bem- sucedida se for planejada,
controlada e cuidada.
Independentemente do formato de revisão técnica, toda reunião

de revisão deve:
Envolver de 3 a 5 pessoas na revisão (se o número de

pessoas for maior será difícil manter uma linha coerente
de discussão).
Preparar previamente a reunião (essa preparação não
deve exigir mais de 2 horas de trabalho de cada pessoa).
Durar menos de 2 horas (um tempo maior torna a
reunião improdutiva pelo cansaço dos temas e mesmo
pela dificuldade de se manter o foco da reunião).
A revisão técnica formal focaliza uma parte específica

(pequena) do software - maior probabilidade de
descobrir erros.
Quando você fizer uma revisão técnica tenha em mente um

conjunto mínimo de diretrizes:
1) Revise o produto, não o produtor (evite revanches entre

colaboradores);
2) Fixe e mantenha uma agenda (refute intervenções de

participantes fora da pauta);
3) Limite o debate e a refutação (evite a formação de polêmicas

durante a revisão);
Unidade 1 27

4) Enuncie as áreas problemáticas, mas não tente resolver cada

problema anotado (as reuniões acontecerão semanalmente, o
problema pode ser pauta da próxima reunião);
5) Faça anotações por escrito;
6) Limite o número de participantes e insista numa preparação

antecipada;
7) Desenvolva uma lista de conferência (checklist) para cada

produto que provavelmente será revisto;
8) Atribua recursos e uma programação de tempo para as revisões

técnicas formais (jamais marque reuniões de revisão para depois
do expediente, isto fará com que a produtividade e a qualidade da
reunião fiquem abaixo do esperado);
9) Realize um treinamento significativo para todos os revisores

(deixe claro a importância da revisão);
10) Reveja suas antigas revisões.
Figura 1. Revisões técnicas formais (Pressman, 1992)
28

SEÇÃO 4 – Normas e Padrões

Um dos pontos mais atuais do controle de qualidade é o uso
de normas e padrões de qualidade para avaliar o processo e o
produto de software.
Quais são as normas e padrões de qualidade?
Quando se iniciaram o desenvolvimento de

normas e padrões, o principal objetivo foi
criar um padrão único mundial de forma
que, mesmo não tendo nenhum contato
entre as empresas, fosse possível garantir a
qualidade de seu trabalho (uma empresa de
desenvolvimento de software educacional da
Tailândia dificilmente conhece uma empresa
de desenvolvimento de software educacional
do Brasil, o cliente na Ásia que irá comprar o
produto, talvez não conheça o histórico das duas
empresas).
Quando você obtém uma certificação segundo uma determinada

norma é emitido um documento oficial que indica que existe
conformidade do produto ou processo com esta determinada
norma ou padrão.
Este documento é emitido a partir de uma avaliação, baseando-

se em critérios unívocos para todas as empresas que fizerem uso
da mesma avaliação. A norma pode ser internacional, regional,
nacional dependendo de sua área de aplicação.
Várias são as empresas de normalização existentes no mundo:
DIN - Deutches Institut für Normung - veja:

<http://www2.din.de>
ISO - International Organization for Standardization,
fundada em 1947, coordena o trabalho de 127 países
membros para promover a padronização de normas
técnicas em âmbito mundial - veja:<http://www.iso.ch>
Unidade 1 29

IEEE - Instituto de Engenharia Elétrica e Eletrônica

- site: <http://www.ieee.org>
IEC - International Electrotechnical Commission (IEC),
fundada em 1906, conta com mais de 50 países e publica
normas internacionais relacionadas com eletricidade,
eletrônica e áreas afins - site: <htp://www.iec.org>
Você pode conhecer os resultados ABNT - Associação Brasileira de Normas Técnicas – a
obtidos pelo PBQP no site http:// ABNT edita as normas nacionais, fundada em 1940 é
www.mct.gov.br/Temas/info/Dsi/ uma entidade privada sem fins lucrativos e representa o
PBQP/PBQP_Software.htm.
Brasil nas entidades de normalização internacional como
a ISO e a IEC- site: <www.abnt.org.br>
A certificação é normalmente restrita a uma linha de produtos ou

serviços. Existem centenas de normas, cada uma delas propõe
padrões e processos sob diferentes aspectos e características. A
empresa que contrata uma certificação deve considerar na escolha
da norma o tipo de produto que desenvolve, seus objetivos com
a aplicação da norma e o reconhecimento de sua clientela em
relação a norma.
Você pode conhecer os

Programa Brasileiro da Qualidade e Produtividade em
resultados obtidos pelo PBQP
Software PBQP Software
no site http://www.mct.gov.
br/Temas/info/Dsi/PBQP/ Em junho de 1993 foi instalado no Brasil o Subcomitê Setorial
PBQP_Software.htm. da Qualidade e Produtividade em Software - SSQP/SW, hoje
PBQP - Software, instituído a partir do Grupo de Trabalho
GT4: Qualidade e Produtividade em Software, da Câmara
Setorial de software, concebido e estruturado no âmbito do
Programa Brasileiro da Qualidade e Produtividade - PBQP.
Este programa se iniciou a partir da preocupação do governo
brasileiro com a globalização do mercado de informática
e a competitividade da indústria de software no mercado
internacional.
O PBQP-Software procura estimular a adoção de normas,

métodos, técnicas e ferramentas da qualidade e da engenharia
de software, promovendo a melhoria da qualidade dos processos,
produtos e serviços de software brasileiros, de modo a tornar
as empresas mais capacitadas a competir em um mercado
30

globalizado (MCT,2005). Além de incentivar a qualidade por

meio de incentivos fiscais às empresas de software, também
promove pesquisas nacionais sobre a aplicação de qualidade
no segmento de desenvolvimento de software. Estes resultados
assim como informações sobre órgãos certificadores são
disponibilizadas ao público em geral.
Chegado ao fim do conteúdo proposto para essa unidade, realize as

atividades propostas para praticar os novos conhecimentos.
Atividades de auto-avaliação
Leia com atenção os enunciados e após, realize as questões propostas:

1) Identifique (V) Verdadeiro ou (F) Falso para as expressões que seguem:
( ) a) A qualidade de software está diretamente ligada a conformidade
com os requisitos do cliente.
( ) b) A qualidade do produto de software independe da qualidade do
processo de software.
( ) c) Os requisitos implícitos do software representam as necessidades do
cliente em termos de funcionalidades.
( ) d) Na avaliação do produto de software a preocupação é com a
qualidade externa do produto, como por exemplo a Interface do
produto.
( ) e) Na avaliação do processo deve-se considerar o conjunto de
atividades, métodos, práticas e tecnologias utilizadas para desenvolver
e manter software e produtos relacionados.
Unidade 1 31

2) Assinale com “X” a(s) expressão(ões) corretas:

( ) a) A avaliação da qualidade apresenta 3 escopos bem definidos:
o aprimoramento do processo de desenvolvimento, a avaliação da
qualidade do produto e avaliação da satisfação do cliente em relação
ao produto de software.
( ) b) As revisões podem ser feitas de três maneiras por discussão:
apresentação e revisões técnicas formais.
( ) c) As revisões devem ser aplicadas em 2 pontos específicos do projeto
como na especificação de requisitos e na análise dos algoritmos.
( ) d) Na apresentação, o projeto ou parte dele é apresentado para os
desenvolvedores.
3) Relacione a 2ª coluna com a 1ª:

a) Métricas ( ) Definem um conjunto de critérios de
desenvolvimento que orientam a maneira como
b) Revisão técnica o software é construído.
formal
( ) Procura descobrir erros de função, lógica ou
c) Padrão implementação em qualquer representação do
d) Organismos software verificando se atende a seus
Normativos requisitos.
( ) Indicam a qualidade do produto, a
produtividade das pessoas que produzem o
produto, avaliam benefícios derivados de novos
métodos e ferramentas.
( ) Criam padrões mundiais garantindo a
qualidade dos produtos, um de seus
representantes é o comitê ISO.
32

Síntese
Nessa unidade você foi apresentado à qualidade de software e

sua importância junto ao cliente e às empresas que desenvolvem
software. Embora muitas empresas iniciem seus investimentos em
qualidade, motivados pela garantia de competitividade ou mesmo
pelas vantagens imediatas de mercado, ao longo da aplicação de
metodologias e padrões, a empresa acaba por perceber o retorno
de sua aplicação em termos de aumento de produtividade e
diminuição de problemas como manutenção e re-trabalhos de
projeto.
A qualidade é inquestionável em sua importância. Isto pode ser

comprovado pela preocupação, cada vez mais contundente, das
empresas e sua corrida em busca de certificações. O controle feito
para a garantia da qualidade de software pode ser realizado em
dois momentos, durante a sua geração (processo de software) e
após estar finalizado (produto de software).
Mas quais os padrões possíveis e disponíveis? Qual escolher?

Qual deles melhor se adapta à necessidade da empresa? Como
escolher entre tantas normas e modelos existentes para a
qualidade do processo e para a qualidade do produto?
Estes temas serão abordados nas próximas unidades, na unidade

2 você irá estudar a qualidade do processo.
Saiba mais
Para aprofundar as questões abordadas nesta unidade, leia o

capítulo 24 - Gerenciamento de Qualidade do livro de Ian
Sommerville, Engenharia de Software, editora Prentice-Hall,
2003.
Veja o artigo “Qualidade? Sim, o sistema está funcionando, não

está?” disponível na midiateca.
Unidade 1 33

2
UNIDADE 2
A qualidade do processo
Após estudar esta unidade você terá subsídios para:
Entender o universo da qualidade no processo das
empresas desenvolvedoras de software.
Conhecer a norma ISO/IEC 12207 relacionada a

qualidade do processo.
Compreender os principais conceitos do modelo CMM

e do modelo CMMI e sua importância no cenário de
desenvolvimento de software.
Seções de estudo
Seção 1 Como se dá o processo de qualidade?
ISO/IEC 12207 Information Technology -

Seção 2
Software Life Cycle Processes.
Seção 3 Capability Maturity Model - CMM.
Seção 4 Capability Maturity Model Integration - CMMI.


Durante a primeira unidade você estudou que a globalização

da economia e do mundo dos negócios, quando relacionadas
às tecnologias e sistemas, impulsionam cada vez mais a
reestruturação das empresas no sentido da promoção da
qualidade. Bem como, você pôde compreender que não basta
apenas querer a qualidade, é necessário reestruturar a empresa
movendo-a neste sentido.
Porém, a reestruturação de um empresa é um processo complexo,

e quando o cenário é uma empresa de desenvolvimento de
produtos de software, o quadro fica ainda mais complicado.
Existem várias estratégias que buscam a promoção da qualidade

como normas e modelos que auxiliam este processo e
encontram-se em franca ascendência no Brasil, entre elas figura a
norma ISO/12207, focada no processo e no cliente, esta norma é
específica para o processo de desenvolvimento de software.
Além da qualidade do processo também surgem no mercado

modelos centrados nos conceitos de maturidade dos processos
e na capacidade dos processos de software. O modelo CMM
(Capability Maturity Model) apresenta uma abordagem que
permite a avaliação dos processos da empresa e enquadramento
da organização em níveis de maturidade. A evolução e a
dificuldade de aplicação do CMM a pequenas empresas, sua
complexidade e seu alto custo de implementação promoveram
e evolução para o projeto CMMI (Capability Maturity Model
Integration). Centenas de organizações do mundo inteiro estão
migrando seus esforços de melhoria de processos para o modelo
integrado CMMI, e até o final de 2002 cerca de 7.000 pessoas
realizaram o curso de Introdução ao CMMI ministrado pelo SEI
(Software Engineering Institute da Carnegie Mellon University) e
pelos seus parceiros autorizados.
Nesta unidade você vai estudar alguns pontos sobre a qualidade

do processo e seus benefícios junto a qualidade do produto final
da organização.
Bons estudos!
36

SEÇÃO 1 – Como se dá o processo de qualidade?

Você certamente ainda lembra do conceito de processo de
software visto na primeira unidade. Mas não custa repetir este
estudo, para você ficar com este conceito bem compreendido.
O processo de software, segundo Humphrey (1995), é uma

seqüência de estágios para desenvolver ou manter o software,
apresentando estruturas técnicas e de gerenciamento para o uso
de métodos e ferramentas e incluindo pessoas para as tarefas do
sistema.
A avaliação de processos de software pretende (Oliveira et al.,

1995):
compreender o estado dos processos de uma

organização, oferecendo a melhoria dos mesmos;
promover a conformidade dos processos em uma
organização com um requisito em particular ou uma
classe de requisitos;
determinar a adequação dos processos de uma
outra organização com um contrato ou uma classe de
contratos.
Quando se fala em qualidade do processo de

, lembre-se que um requisito básico de
um processo de qualidade é o de que todas
as atividades envolvidas sejam sistemáticas e
passíveis de repetição independente de quem
execute.
A qualidade de um produto de software é dependente da

qualidade do processo pelo qual ele é construído e mantido.
Quando você atua sobre o processo de software você pode
defini-lo, gerenciá-lo, medi-lo e melhorá-lo. Mas para definir o
processo de software é necessário conhecer o processo atual, ou
seja: determinar a capacidade do processo , avaliar a proposta de
melhorias e evolução do processo de software.
Unidade 2 37

Além de definir o processo, você precisa descrevê-lo em detalhes

para que todos os seus colaboradores consigam usá-lo de forma
consistente.
O que envolve a realização de um modelo de

processo?
Lembre-se que a implantação de um programa de qualidade

inicia pela definição e implantação de um processo de software.
A partir daí o processo de software deve estar documentado, ser
compreendido e seguido.
Figura 1 - Modelo de Processo
O modelo do processo envolve o uso de métodos,

procedimentos que precisam definir a relação entre os métodos
e as ferramentas utilizadas para simplificar a utilização dos
métodos, automatizando suas tarefas e uma equipe treinada nos
métodos e no uso das ferramentas e todos estes componentes
utilizados em conjunto propiciam um processo de qualidade.
38

Você sabia?
A melhoria da qualidade do processo já não é uma preocupação

isolada de uma ou outra empresa, você já ouviu falar sobre a
sociedade SOFTEX e seu trabalho para a promoção da melhoria
da qualidade do processo de software por meio de um modelo de
referência?
Para conhecer mais sobre a SOFTEX, acompanhe a seguir um

trecho do artigo de Maurício F. Galimberti, disponível em:
<http://www.aepolo.org.br/artigo_7.asp> (último acesso em
fevereiro de 2006). Caso você queria lê-lo integralmente é só
acessar o site.
O site da MPS Br dissemina

informações sobre a
Software: uma abordagem brasileira melhoria do processo de
software no Brasil. Site
Com a missão de “transformar o Brasil em um centro disponível em: http://
de excelência na produção e exportação de software”, a www.softex.br/cgi/cgilua.
Sociedade SOFTEX atua de diversas formas, e em diversas exe/sys/start.htm?sid=194
frentes, para o crescimento e difusão da indústria brasileira
de software.
Um dos últimos empreendimentos da Sociedade SOFTEX
está relacionado à melhoria de processos de software. Em
virtude do cenário mundial de demanda por produtos e
processos de qualidade, a SOFTEX criou o projeto Melhoria
de Processos de Software Brasil (mps BR), que é formado
pelo Modelo de Referência e pelo Modelo de Negócio.
O mps Br “visa a melhoria de processos de software em
empresas brasileiras, a um custo acessível, especialmente
na grande massa de micro, pequenas e médias empresas”.
”O Projeto mps Br tem como objetivo principal definir e
implementar o Modelo de Referência para melhoria de
processo de software (MR mps) em 120 empresas, até junho
de 2006, com perspectiva de mais 160 empresas nos dois
anos subseqüentes.
O projeto tem como objetivos secundários disseminar, em
diversos locais no país: a capacitação no uso do modelo
(cursos de Introdução ao MR mps e cursos e provas para
Consultores de Implementação e Avaliadores do modelo);
Unidade 2 39

o credenciamento de instituições implementadoras

e/ou avaliadoras do modelo, especialmente
instituições de ensino e centros tecnológicos; a
implementação e avaliação do modelo com foco em
grupos de empresas.
Atualmente, são inúmeras as normas e os diferentes modelos

de definição, avaliação e melhoria dos processos. Nas seções
seguintes desta unidade você irá interagir com:
a norma ISO 12207 – Processos do Ciclo de Vida do

Software;
o modelo CMM – Capability Maturity Model ;
o modelo CMMI – Capability Maturity Model
Integration.
Siga em frente com dedicação!
SEÇÃO 2 – ISO 12207 – Processos do Ciclo de Vida do

Software
A norma ISO / IEC 12207 Information Technology – Software
Life Cycle Processes foi aprovada em 1995. Esta norma estabelece
processos, atividades e tarefas a serem aplicados na aquisição,
fornecimento, desenvolvimento, manutenção e operação do
software. Esta norma promove o processo de ciclo de vida bem
definido.
A norma pode ser aplicada para qualquer tipo de atividade, como

por exemplo atividades aeroespaciais, equipamentos médicos,
telecomunicações, comerciais, militares, etc.
Os usuários-alvo da norma são compradores e fornecedores com

conhecimentos técnicos considerados elevados e que estejam
envolvidos em projetos que apresentam riscos em termos de
custos, prazos, qualidade ou técnicos. Ela descreve a arquitetura
40

de processos de ciclo de vida do software, mas não especifica os

detalhes de como implementar ou realizar as atividades e tarefas
incluídas nos processos.
Tratar do processo não significa limitar a empresa em

termos de decisões, em outras palavras, na norma
não são prescritos métodos de desenvolvimento
a serem seguidos ou mesmo definidos modelos
específicos de ciclo de vida que devam ser adotados.
Da mesma forma, não são estabelecidos modelos de
documentação que devam ser seguidos. Na verdade,
ela apenas indica onde a empresa deve chegar para
certificar-se, mas não como deve fazer isto.
A norma é composta por 17 processos do ciclo de vida

organizados em três grandes classes. A seguir, conheça
sinteticamente, quais são as classes e seus processos:
Quadro 1 . Classes e processos da norma ISO/IEC 12207
Classes Processos de inclui

aspectos referentes a definição da necessidade de adquirir um software
1 - Aquisição (produto ou serviço), pedido de resposta, seleção de fornecedor,
A) Processos gerência da aquisição e aceitação do software.
fundamentais se
prolongam do preparar uma proposta, assinatura de contrato, determinação dos
2 - Fornecimento
início a execução do recursos necessários, planos de projeto e entrega de software.
desenvolvimento, análise de requisitos, projeto, codificação, integração, testes, instalação
operação ou manutenção 3 - Desenvolvimento e aceitação do software.
do software durante todo
o seu ciclo de vida. 4 - Operação a operação do software e suporte operacional aos usuários.
5 - Manutenção atividades de quem faz a manutenção do software.
planejamento, projeto, desenvolvimento, produção e manutenção
6 - Documentação dos documentos necessários a gerentes, engenheiros e usuários do
software.
7 - Gerência de Controle de armazenamento, liberações, manipulação, distribuição e
Configuração modificação de cada um dos itens que compõem o software.
B) Processos de apoio garante-se que os processos e produtos de software estejam em

8 - Garantia da Qualidade
auxiliam outros conformidade com os requisitos e os planos estabelecidos.
processos. determina se os produtos de software de uma atividade atendem
9 - Verificação completamente aos requisitos ou condições impostos a eles.
determina se os produtos e o produto final ( sistema ou software)
10 - Validação atendem ao uso específico proposto.
define as atividades para avaliar a situação e os produtos de uma
11 - Revisão Conjunto atividade de um projeto.
Unidade 2 41

determina de forma independente, a conformidade de produtos

12 - Auditoria identificados e atividades com planos, requisitos e com o contrato.
definir a forma para analisar e resolver os problemas de
13 - Resolução do qualquer natureza ou fonte, descobertos durante a execução do
Problema desenvolvimento,operação ou manutenção.
C) Processos 14 - Gerência trata do gerenciamento de processos,
organizacionais
implementam uma hardware, software, ferramentas, técnicas, padrões de
15 - Infra-estrutura
estrutura constituída desenvolvimento, operação ou manutenção.
de processos de ciclo estabelece atividades para estabelecer, avaliar, medir, controlar e
de vida e pessoal 16 - Melhoria melhorar um processo de ciclo de vida de software.
associados, melhorando
continuamente a 17 - Treinamento relaciona atividades para prover e manter o pessoal treinado.
estrutura e os processos.
Observe que cada uma das classes apresenta os seus processos

definidos e os seus usuários potenciais.
No processo de aquisição e fornecimento a visão é de

contrato, os usuários são clientes e fornecedores.
No processo de operação temos a visão operacional onde
os usuários são o operador e o usuário.
Na visão de engenharia temos os processos
de desenvolvimento e manutenção em que os
usuários serão a equipe de manutenção e a equipe de
desenvolvimento.
Todos os processos de apoio fazem parte da visão da
equipe de apoio e são utilizados por elas.
SEÇÃO 3 – Capability Maturity Model - CMM

O CMM, ou modelo para a melhoria da maturidade da
organização, foi desenvolvido pelo Software Engineering
Institute.
O projeto foi inicialmente financiado pelas forças armadas

americanas que queriam que fosse estabelecido um padrão de
qualidade para os softwares desenvolvidos a ela. Deste modo,
um alerta oportuno a fazer, é que como o projeto todo previa
o desenvolvimento de grandes projetos, por isso seu uso para
42

projetos menores deverá ser cuidadoso pois precisa ser adaptado

com a realidade da organização que pretende utilizá-lo.
O CMM pode ser entendido como um modelo para a

melhoria da maturidade da organização. Mas o que é
maturidade de uma organização?
Acompanhe o raciocínio: quando uma empresa é imatura, todo

o processo é improvisado, a empresa não possui base histórica
sobre seu processo de desenvolvimento, logo não há maneira
objetiva de julgar a qualidade do produto. Normalmente em
uma organização imatura a qualidade e a funcionalidade do
produto são sacrificadas, pois não existe um rigor no processo
a ser seguido, sendo que a equipe invariavelmente encontra-se
envolvida na resolução de crises imediatas.
Um exemplo prático é quando o desenvolvimento

encontra-se com um atraso de 60 dias no projeto do
cliente X. Mas na minha empresa tenho 3 equipes,
em diferentes projetos, para compensar este atraso
e atender o cliente X, eu retiro a equipe que está
desenvolvendo para o cliente B (que estava com o
cronograma em dia ) 3 desenvolvedores e os escalo
no projeto procurando colocá-lo em dia. O que você
acha que vai acontecer? Resolverei o problema do
cliente X? Criarei um novo problema para o cliente B?
Resolverei todos os problemas com esta atitude?
É difícil dizer o que irá acontecer, na verdade é pouco previsível

o resultado desta operação, mas o que é certo é a imaturidade do
processo.
A conseqüência da imaturidade é o alto custo de

manutenção de seus produtos, a baixa produtividade,
a qualidade duvidosa e um risco elevado quando se
deseja fazer alguma inovação tecnológica.
Para melhor entender o contexto, imagine ainda, a seguinte

metáfora: você foi convocado para fazer parte de um time de
Unidade 2 43

futebol, mas na verdade não foram definidas as posições pela

competência dos jogadores, alguns jogam, outros olham e a
maioria reclama e ainda por cima tenta impor suas idéias sobre
como melhorar a partida e ganhar o jogo. Apesar da confusão seu
time pode vencer, é bem provável que isto ocorra pela capacidade
pessoal de um ou outro jogador, mas você não pode garantir que
o mesmo se repita ou que o jogo possa ser de alguma maneira
controlado. Moral da história, este time é imaturo.
Na mesma medida, isto ocorre freqüentemente em empresas

desenvolvedoras de software. Mesmo que a empresa seja imatura
não significa que ela não possa produzir um excelente produto.
Mas será que ela conseguirá repetir este sucesso? Talvez todo o
projeto esteja na mão de apenas um desenvolvedor e a saída deste
membro da equipe pode literalmente fechar a empresa!
E agora, você imagina o que é uma organização

considerada madura?
É só imaginar o inverso da anterior!
Na organização madura estão bem claros e definidos

todos os papéis e responsabilidades.
A empresa possui uma base histórica de seus processos
e decisões, a qualidade dos processos e produtos é
completamente monitorada, sendo que seu processo pode
ser constantemente atualizado e melhorado.
Em uma organização madura a comunicação entre
gerências e seus grupos é eficiente e motivada pela
empresa.
Como conseqüência deste processo a empresa tem a
satisfação de cronogramas, funcionalidades, custos e
qualidade do produto.
44

O CMM descreve princípios e práticas dos quais

depende a maturidade do processo de software,
assim permite o apoio as organizações que
pretendem aumentar a maturidade de seu processo
por um caminho evolutivo.
Deste modo, o CMM permite ao cliente e ao empresário medir a

maturidade da empresa segundo princípios/preestabelecidos.
Quais são os níveis de maturidade?
O CMM foi dividido em cinco níveis de maturidade

relacionados ao desenvolvimento do software: inicial, repetitivo,
definido, gerenciado, otimizado.
Figura 2 - Níveis do CMM
Cada um dos níveis possui áreas-chaves que estabelecem temas

que devem ser abordados por meio de metas e que na verdade,
identificam as questões essenciais que caracterizam o nível.
Unidade 2 45

Observe a figura 2, para cada área-chave existem práticas-

chaves. As práticas-chave especificam “o que” deve ser feito
para implementar o modelo como: documentos, treinamentos,
políticas definidas para as atividades, medições e análises.
Mas lembre-se as práticas-chaves nunca estabelecem

“como” elas devem ser implementadas, somente
definem “o que” deve ser realizado.
Observe também na figura 2 que o nível gerenciado possui

duas áreas-chaves: o Gerenciamento de Qualidade e o
Gerenciamento Quantitativo do Processo.
Para você entender melhor as características de cada nível

apresentado na figura 2, leia atentamente o texto que segue.
1º Nível CMM:
No primeiro nível, o inicial, o processo de desenvolvimento é
desorganizado e até caótico. Poucos processos são definidos e o
sucesso no desenvolvimento depende da competência das pessoas.
Grande parte dos problemas para empresas neste nível são de
ordem gerencial e não técnica, o gerente não possui a visibilidade
do processo e de como ele ocorre e com certeza, terá problemas
na definição e cumprimento de cronograma, orçamentos e
manutenção da qualidade.
Você observou que no nível 1 não existem áreas-chave? Por que?
2º Nível CMM:
No segundo nível , o repetitivo, os processos básicos de
gerenciamento de projeto estão estabelecidos e permitem
monitorar custos, cronograma e funcionalidade. A disciplina
necessária ao processo está estabelecida de forma a poder ser
repetida com sucesso em projetos com aplicações semelhantes.
Neste nível já existem padrões na empresa que são seguidos

pela equipe, já é possível acompanhar custos, cronogramas e
planejamento.
46

3º Nível CMM:
O nível definido possui as atividades de gerenciamento e as
de engenharia do processo de desenvolvimento de software
documentadas, padronizadas e integradas em um padrão de
desenvolvimento da organização. Todos os projetos utilizam
uma versão aprovada e adaptada do processo padrão de
desenvolvimento de software da organização.
Sempre que a empresa está neste nível, a evolução do produto é

visível através do processo.
4º Nível CMM:
No nível 4, o nível gerenciado, a gerência consegue tomar
suas decisões sobre bases objetivas, todo o processo é medido
e gerenciado quantitativamente. Produto e processo de
desenvolvimento de software são entendidos e controlados
quantitativamente.
Neste nível medidas de qualidade e produtividade são coletadas

em todos os projetos, ocorre a avaliação e análise contínua do
desempenho. É estabelecido o controle estatístico de processos.
5º Nível CMM:
Quando a empresa chega no nível 5, o melhoramento contínuo
do processo é conseguido pelo “ feedback” quantitativo dos
processos e pelo uso pioneiro de idéias e tecnologias inovadoras.
A melhoria contínua do processo é proporcionada pela
realimentação quantitativa do processo e pela implementação
de novas idéias e tecnologias. Em outras palavras, a empresa
consegue medir quantitativamente o impacto e a eficiência das
mudanças implementadas.
No nível 5 são identificados os pontos fracos e defeitos

promovendo uma ação preventiva sobre causas. Assim como
mudanças mais significativas de processos ou de tecnologias são
feitas, a partir de análises de custo/benefício com base em dados
quantitativos cuja coleta iniciou-se no nível 4.
Unidade 2 47

Como está o Brasil no ranking de qualificação CMM?
Apesar de complexo em sua implantação, o número de adesões de

empresas brasileiras vem crescendo. Para você ter conhecimento
acompanhe o quadro a seguir:
Quadro 2 - Ranking brasileiro de qualificação CMM
O Processo de Avaliação no Brasil

No último relatório do SEI/CMU, publicado em setembro de 2005 com
dados até junho do mesmo ano, o Brasil encontra-se em 14º lugar dentre
os países com maior número de avaliações CMM realizadas por esse
instituto (após ter permanecido na 13ª posição desde dezembro de
2001), sendo o único país da América Sul que aparece com mais de 20
avaliações (29); Chile possui 20 avaliações; Argentina, Colômbia, Peru,
Uruguai e Venezuela aparecem com menos de 10 avaliações.
A Integrated System Diagnostics Brasil - ISD-Brasil [www.isdbrasil.com.
br], subsidiária da norte-americana ISD Inc, conta com as credenciais
do SEI para efetuar avaliações oficiais e com profissionais autorizados a
conduzir avaliações de processos com resultados reconhecidos.
Organizações com Qualificação CMM no Brasil – 1997-20051
Desde Nível Atual No ano Até o ano

2 3 4 5
1997 1 1 1
1998 1 1 2
1999 2
2000 2
2001 4 4 6
2002 3 1 4 10
2003 16 1 17 27
2004 6 3 9 36
16
2005 15 1
52
Total 41 10 1 52
48

Você sabia que no Brasil existe apenas uma empresa classificada

no nível 4 de maturidade ? E que somente 10 empresas possuem
o nível 3?
Conheça no quadro a seguir quem são elas.
Quadro 3 – Empresas brasileiras com nível 3 e 4

CMM - Nível 3
Data da Empresa
Nome da empresa Estado
avaliação avaliadora
1 Accenture Delivery Center São Paulo SP nov/04 Procesix
2 CI&T Software SP mar/04 Synchro PP&T
3 DBA Engenharia de Sistemas RJ jul/01 ISD
4 EDS São Paulo Solution Center SP ago/01 ... (2)
5 Ericsson do Brasil SP mar/01 ... (2)
6 Motorola SP dez/01 ISD
7 Brasília DF 2004 ISD
Politec
8 São Paulo SP mar/05 ISD
9 Stefanini SP out/02 ISD
10 Xerox do Brasil – CDSV (desativada em janeiro/05) ES dez/97 ISD
CMM - Nível 4
1 EDS Rio de Janeiro Solution Center RJ dez/03 ... (2)
Fontes: ISD Brasil, Procesix, empresas qualificadas e imprensa especializada, compilado por
MCT/SEPIN/DIA.
(1) Fonte: ITWeb, 10/10/2005
(2) Fonte: Gazeta Mercantil, fev/04
SEÇÃO 4 – Capability Maturity Model Integration -

CMMI
O modelo CMMI é um modelo que descreve orientações para
a definição e implantação de processos, o modelo não descreve
processos mas orientações definidas por meio de práticas
especificadas.
Unidade 2 49

O modelo foi construído a partir da herança dos modelos

Software CMM – Staged, o SECM – Continuous e o IPD CMM
– Hybrid.
O foco do CMMI baseia-se nas disciplinas de um

desenvolvimento integrado do produto e processo, o
desenvolvimento de sistemas (incluindo software ou não), o
desenvolvimento de software, a subcontratação e a integração dos
modelos e redução dos custos com melhorias de processo.
Fazem parte dos principais objetivos do CMMI:
aumento do foco das atividades;

integração dos processos existentes;
ISO 15504 eliminar inconsistências;
A norma define um modelo
bi-dimensional cujo objetivo reduzir duplicações;
é a realização de avaliações
do processo do software e sua fornecer terminologia comum;
melhoria.
assegurar consistência com a norma ISO 15504;
flexibilidade e extensão para outras disciplinas.
Quais são os níveis no CMMI?
Observe a seguir que no CMMI ocorre uma mudança nos nomes

dos níveis em relação ao CMM:
Quadro 4 - comparação CMM e CMMI
Nível SW-CMM(v 1.1) CMMI
1 Inicial Executado - Inicial
2 Repetível Gerenciado
3 Definido Definido
4 Gerenciado Quantitativamente Gerenciado
5 em Otimização em Otimização
50

1º Nível CMMI:
No nível inicial a organização possui um controle de processos
informal.
2º Nível CMMI:
No nível gerenciado ocorre um gerenciamento básico do projeto.
Os processos são divididos em projetos individuais.
3º Nível CMMI:
O terceiro nível, o definido, caracteriza-se pela padronização do
processo constituído de vários projetos.
4º Nível CMMI:
No nível gerenciado quantitativamente vários processos são
gerenciados mantendo-se a mesma padronização.
5º Nível CMMI:
O quinto nível, otimizado, ocorre a melhoria contínua do
processo.
Como está no Brasil o CMMI?
Organizações com Qualificação CMMI no Brasil – 1997-20051
Fontes: ISD Brasil, Procesix, empresas qualificadas e imprensa especializada, compilado por MCT/
SEPIN/DIA.
(1) Fonte: ITWeb, 10/10/2005
(2) Fonte: Gazeta Mercantil, fev/04
Unidade 2 51

Apesar da autorização para treinamento CMMI ter iniciado no

Brasil em 2003, percebe-se pelos dados da ISD que sua procura
por parte das empresas faz uma curva ascendente passando de 1
para 14 em apenas 2 anos.
No Brasil, o CMMI seduz um grande número de empresas

promovendo a melhoria organizacional e de qualidade, apenas
30 empresas (até final de 2005) no mundo possuem o CMMI
nível 5.
Você sabia...
A Stefanini foi a primeira companhia nacional a
conquistar o nível 5 do CMMI que confere à empresa
um padrão de qualidade internacional na engenharia
de software.
O credenciamento CMMI é considerado hoje por empresas

e pelo governo como fundamental para o processo de
incremento da exportação de software.
52

8 de novembro de 2005
Exportação de Software e o CMMI

Plínio Ventura *
Mas o que é qualidade de software? Como medir a

qualidade de um artefato de software? Como concluir
que um produto tem qualidade inferior a outro? Podemos
tentar responder essas perguntas a partir de vários
argumentos, mas para alcançarmos exatidão, gastaremos
tempo e dinheiro.
Uma das formas de atestar a qualidade de uma empresa
fabricante de software e seus produtos e, ainda, abrir
as portas para a exportação é investir na aquisição de
modelos de qualidade, como o CMMI - Capability Maturity
Model Integration (www.sei.cmu.edu/cmmi).
Nota: CMMI não é uma certificação, é o resultado de uma
avaliação que atesta a maturidade/capacidade de uma
empresa para desenvolver software com qualidade. A
avaliação positiva é concluída a partir da emissão de um
Para finalizar o conteúdo
laudo pelo destaEngineer
SEI – Software unidade, leia a Este
Institute. seguir as
laudo
atesta que a empresa avaliada está em conformidade com
estimativas depráticas
as boas custo edotempo
CMMI.de implementação estimadas por
Plínio Ventura.
O investimento médio para adequação dos processos às
praticas do CMMI é de R$ 250 mil, mas existe variação do
investimento de acordo com os cenários avaliados. No
Brasil, esse valor já oscilou entre R$ 150 mil e R$ 1,5 milhões.
Já o tempo médio para chegar a um nível de maturidade
oscila entre 12 e 45 meses (tanto o investimento quanto o
tempo variam de acordo com o porte da unidade avaliada e
o nível de maturidade almejado).
Nota: Os dados citados não incluem empresas que
possuem o SW/CMM ou o SE/CMM.
Mas por que o número de empresas brasileiras que
possuem CMMI é tão pequeno?. Onde está o fator limitador
para as empresas obterem o CMMI? Cultura, carência
financeira, comodismo, falta de incentivo do governo?
Unidade 2 53

Agora que você chegou ao final do conteúdo proposto para essa

unidade, realize as atividades propostas para praticar os novos
conhecimentos.
Leia com atenção os enunciados e realize as questões propostas:

1) O modelo CMM - Capability Maturity Model avalia a maturidade das
organizações. Relacione suas características corretamente: (atenção
que pode ocorrer repetições)
a) definido ( ) também conhecido como processo previsível.

b) otimizado ( ) ocorrem treinamentos do grupo e a definição do
processo da organização.
c) inicial
( ) resolução de crises imediatas.
d) gerenciado
( ) promove o gerenciamento quantitativo do
e) repetitivo processo.
( ) não existe base histórica.
( ) promove o gerenciamento de requisitos e a
garantia da qualidade.
( ) permite o gerenciamento de mudança do processo
e prevenção de defeitos.
( ) também conhecido como processo disciplinado.
2) Complete as lacunas com as seguintes expressões:

As atividades - os níveis de maturidade – as áreas-chaves do
processo – características comuns – as atividades
No modelo CMM pode-se dizer que:

a) As áreas-chaves do processo são organizadas por _______________
necessárias para a implementação.
b) __________________ são necessárias para atingirmos os objetivos
c) __________________ indicam a capacidade do processo.
d) As características comuns contém práticas base que descrevem ______
____________.
54

3) Descreva a seguir quais são os requisitos necessários para que se inicie

um processo de qualidade?
4) Relate como é organizada a norma ISO/IEC 12207?
Após a realização destas atividades, participe também

das atividades propostas no EVA. Lembre-se que toda
dedicação é premiada com conhecimento.
Unidade 2 55

Síntese
A Software Engineering Institute publicou em estudos recentes,

números que impressionam relacionados à melhoria de
desempenho em empresas que investiram em qualidade. Estas
empresas tiveram um aumento médio de produtividade de 35%
por ano, já o número de bugs encontrados após a entrega foi
reduzido em 39% ao ano. Estes números levaram a um aumento
de produtividade e redução de custos, re-trabalho e manutenção
em uma proporção de 5 para 1, chegando a 9 para 1 em alguns
casos.
Estes números comprovam que a implantação de modelos

(CMM) ou normas (ISO 12207) mesmo com custos
consideráveis de implementação, trazem a longo prazo, retornos
em termos de qualidade que pode ser quantificada no aumento
da produtividade e dos lucros da empresa.
Outro modelo importante o CMMI, construído sobre a estrutura

do CMM procura apresentar-se de uma forma mais abrangente,
englobando diversas disciplinas em um único modelo, com uma
única estrutura, metodologia comum, nomenclatura padrão,
podendo ser utilizado no desenvolvimento de produtos, serviços
e manutenção, reunindo as melhores práticas de outros modelos.
Apesar de recente já possui uma boa representação no Brasil.
A soma destes modelos proporciona um escopo de escolha

razoável para todas as empresas que pretendem promover a
melhoria de suas organizações por meio de processos mais
controláveis e dinâmicos. Na próxima unidade, você vai ser
apresentado a conceitos e normas voltadas a qualidade do produto
que em conjunto com a qualidade do processo aprimoram a
qualidade geral do processo e seu produto final.
Após o estudo desta unidade, a seqüência propõe que você estude

na unidade 3, a qualidade do produto.
56

Saiba mais
Se você quiser saber mais sobre a norma, o site <http://

www.12207.com> oferece templates, checklists, livros e
novidades sobre a utilização da norma ISO / IEC 12207
Information Technology - Software Life Cycle Processes.
Se você deseja saber mais sobre o modelo CMM veja em nossa

midiateca o artigo “Uma experiência prática na implantação do
CMM”de Marcelo Pessoa.
No site <www.mct.gov> você vai encontrar a tradução do CMM

e do CMM nível 2 disponível para download.
Outro site importante na área é o site do SEI - Software

Engineering Institute <http://www.sei.cmu.edu/> que traz
artigos, relatos e atualizações do CMM e do modelo CMMI.
Se você deseja saber mais sobre o modelo CMMI faça uma

visita ao site oficial do Carnegie Mellon <http://www.sei.cmu.
edu/>cmmi/, nele você vai encontrar artigos, produtos, eventos e
relatos de experiência na utilização do CMMI.
Outro site interessante é o da Borland - <http://www.borland.

com/br/services/cmmi.html> que apresenta uma ferramenta on-
line que induz o usuário a explorar e entender o modelo CMMI.
Não podemos encerrar esta unidade sem falarmos da ISO

15504.
A ISO 15504 tem por objetivo a avaliação de processos

propondo a melhoria contínua ou a determinação de seu nível de
capacidade. A ISO 15504 define um framework para avaliação
de processos de software e baseia-se nas melhores características
de vários modelos existentes, tais como: CMM, Trillium e
Bootstrap, além das Normas ISO 9001/9000-3 (interpretação da
ISO9000 para software) e ISO/IEC 12207.
Unidade 2 57

Esta norma tem sido muito bem aceita no mercado, veja na

midiateca a experiência de sua aplicação na empresa InfoGlobo
Comunicações responsável por diversos produtos como o Jornal
O Globo, Jornal Extra, O Diário de São Paulo, Agência O
Globo, O Globo On Line.
Procure sob o título Experiência de Avaliação de Processos e

Desenvolvimento de uma Ferramenta para Apoio Baseado na
ISO/IEC TR 15504.
58

3
UNIDADE 3
Qualidade do produto
Conhecer as normas utilizadas na avaliação da qualidade
do produto.
Compreender os objetivos das normas e suas

características.
Seções de estudo
das seguintes seções
Seção 1 Qualidade do produto de software.
Seção 2 ISO/IEC 9126 – Software Product Quality.
ISO/IEC 14598 – Information Technology

Seção 3
Software Product Evaluation.
Seção 4 ISO/IEC 12113 – Software Packages Quality.


Nos dias atuais, os clientes de software, estão cada vez mais

familiarizados com a tecnologia e mais experientes no processo
de aquisição de seus produtos. A conseqüência imediata é
o aparecimento de clientes cada vez mais exigentes, e para
os desenvolvedores de software, a conseqüência é a busca da
qualidade de seus produtos. O uso de métodos de avaliação
baseados em normas é uma forma eficiente e segura de se atingir
este objetivo.
A Organização Internacional para Padronização – ISO – lançou

um conjunto de normas de qualidade elaboradas especificamente
para a padronização da avaliação da qualidade de produtos de
software. As normas internacionais de avaliação de produto de
software são recentes e a compreensão completa do processo de
avaliação exige a análise de duas normas, a ISO/IEC 9126 e a
ISO/IEC 14598.
A ISO/IEC 9126 descreve um modelo de qualidade e alguns

exemplos de métricas que podem ser utilizadas na avaliação de
produto de software. Já a ISO/IEC 14598, oferece uma visão
geral dos processos de avaliação de produtos de software e fornece
guias de requisitos para avaliação.
Nesta unidade a proposta é que você inicie o estudo sobre

modelos de avaliação do produto e suas principais características.
Sinta-se à vontade para o estudo exploratório sobre a qualidade
do produto de software.
SEÇÃO 1 – Qualidade do produto de software

Você pode entender por qualidade do produto de software como:
Um conjunto de características que devem ser

alcançadas em um determinado grau para que o
produto atenda as necessidades do usuário.
60

O detalhamento destas características chegando ao nível de

atributos e sua avaliação é que determinam a qualidade do
produto de software.
Imagine o seguinte exemplo: você ganha de presente

de aniversário um bolo maravilhoso de seus colegas
de trabalho. Quando você olha ou mesmo come o
bolo só consegue avaliar o produto final, é possível
você avaliar atributos como o sabor e a aparência
(por exemplo), mas torna-se impossível avaliar como
ocorreu o processo de produção, questões como o
padrão de higiene utilizado na confecção do bolo ou
mesmo a qualidade dos ingredientes usados serão
impossíveis de avaliar.
Para se avaliar um produto de software é necessário usar um

modelo que organize os atributos considerados importantes no
processo de avaliação, que possibilite a avaliação do produto de
software e principalmente, que permita o entendimento de como
cada atributo influencia positiva ou negativamente a qualidade do
produto. Estes modelos são expressos e aceitos pelo mercado na
forma de normas técnicas.
Lembre-se: a avaliação de um produto de software requer

planejamento, controle e uso de técnicas adequadas de avaliação.
Quais são os modelos que avaliam a qualidade do

produto de software?
Quando você avalia a qualidade do produto de software

é necessário verificar por meio de técnicas e atividades
operacionais o quanto os requisitos são atendidos. Estes requisitos
são na verdade, as necessidades que são expressas em termos
quantitativos ou qualitativos e que definem as características do
software.
É possível citar três documentos, são elas, a norma:
ISO/IEC 9126 – Qualidade do produto de softwar.e

ISO/IEC 14598 – Avaliação de produtos de software.
ISO 12113 – Testes e requisitos de qualidade em pacotes
de software.
Unidade 3 61

Ao fazer um exame sistemático para avaliar a qualidade do

produto você precisa ter : um processo de avaliação que seja
responsável por fornecer passos a serem seguidos por “quem”
irá avaliar a qualidade do produto.
Como funciona o relacionamento entre as normas?
A norma 14598 oferece um processo de avaliação adaptado para

as três visões:
a visão do desenvolvedor,
a visão do comprador, e
a visão do avaliador.
Neste processo a especificação do modelo de qualidade utilizado

é o da norma ISO/IEC 9126.
Simplificando: a norma ISO/IEC 14598 oferece

os procedimentos para realização do processo de
avaliação e a ISO/IEC 9126 oferece o modelo do que
deve ser avaliado no produto.
Veja na figura 1, a seguir, como se dá este relacionamento entre

as normas.
62

Figura 1 - Relacionamento entre a norma ISO/IEC 9126 e 14598 (ISO9126,1997)
Você observou na figura 1, a abrangência da norma ISO/IEC

14598 sobre o processo de avaliação e o uso da ISO/IEC 9126 na
aplicação das métricas?
Na próxima seção conheça mais detalhes sobre a ISSO/IEC

9126.
SEÇÃO 2 – ISO / IEC 9126 Software Product Quality

A Norma ISO/IEC 9126 é utilizada como referência para o
processo de avaliação do produto de software.
É definida como um conjunto de atributos que

tem impacto na capacidade do software de manter
o seu nível de desempenho dentro de condições
estabelecidas por um dado período de tempo.
Unidade 3 63

Segundo Rocha (2001), esta norma está dividida em duas partes:
o modelo de qualidade para características externas e

internas e
o modelo para qualidade em uso.
A norma NBR 13596, é a tradução oficial para o português,

realizada pela ABNT, da norma ISO/IEC 9126 - Information
Technology- Software Quality Characteristics and Metrics
(Tecnologia da Informação – Características e Métricas de
Qualidade de Software).
Quando a norma ISO/IEC 9126 é utilizada?
Você pode utilizar esta norma:
na avaliação das especificações do software durante

o desenvolvimento para verificar se os requisitos de
qualidade estão sendo atendidos.
Na descrição das características e atributos do software
implementado, por exemplo nos manuais de usuário.
Na avaliação do software desenvolvido antes da entrega
ao cliente.
Na avaliação do software desenvolvido antes da aceitação
pelo cliente.
64

A norma está dividida em 4 grandes partes:
Quadro 1 – Norma ISO/IEC 9126 e suas partes
Norma Parte
1 - modelo de qualidade, fornece características e subcaracterísticas de qualidade,

sendo uma norma essencialmente de definições.
2 - define métricas externas para a medição das características e

subcaracterísticas de qualidade da ISO/IEC 9126-1. Essas métricas referem-
ISO/IEC 9126
se a medições indiretas de um produto de software, a partir da medição do

comportamento do sistema computacional do qual o produto faz parte.
3 - estabelece métricas internas para a avaliação de um produto de software.

Essas métricas referem-se a medições diretas de um produto, a partir de sua
características internas, sem que seja necessária a execução do programa.
4 - estabelece métricas de qualidade em uso.
Como são classificadas os atributos de qualidade no

modelo de qualidade para características externas e
internas?
Este modelo de qualidade classifica os atributos de qualidade em

seis grandes características, as quais são por sua vez, descritas na
forma de subcaracterísticas. Acompanhe a seguir, com atenção,
quais são elas:
Unidade 3 65

Quadro 2 – Classificação dos atributos de qualidade no modelo de qualidade para características exter-
nas e internas
Classificação Subcaracterísticas
1 - Funcionalidade existência de um conjunto de funções apropriadas para as tarefas

Adequação
- as funções e requeridas.
propriedades
específicas do produto Acurácia o produto gera resultados precisos ou dentro do esperado pelo cliente.
que satisfazem as
necessidades do
Interoperabilidade avalia a capacidade de interagir e interoperar com outros sistemas de
usuário, descreve o que acordo com o que foi especificado.
faz o software como e
quando. o produto está de acordo com as convenções, as normas ou os
Conformidade: regulamentos estabelecidos.
Segurança no aptidão para prevenir os acessos não autorizados a programas e dados.
acesso
2 - Confiabilidade estado de maturação do software, detectada por sua baixa freqüência

Maturidade
- conjunto de atributos de falhas.
que evidenciam a
capacidade do software capacidade do produto para manter determinados níveis de desempenho
de manter seu nível Tolerância a falhas mesmo na presença de problemas ou mesmo em caso de violação nas
de desempenho interfaces especificadas.
sob condições
estabelecidas durante atributos do software que evidenciam atributos do software que
um período de tempo Recuperabilidade evidenciam sua capacidade de restabelecer seu nível de desempenho e
estabelecido. recuperar os dados diretamente afetados em caso de falha e o esforço
necessários para que isto aconteça.
facilidade com que o usuário reconhece a lógica de funcionamento de
3 - Usabilidade - a Inteligibilidade um produto e sua aplicação.
usabilidade refere-se
ao esforço necessário medida da facilidade encontrada pelo usuário para aprender a utilizar o
para usar um produto Apreensibilidade produto
de software assim como
o julgamento individual
do uso por um conjunto facilidade oferecida para operar e controlar operações pertinentes ao
explícito ou implícito Operacionalidade software.
de usuários.
6 - Portatilidade - Adaptabilidade faculdade do produto poder ser adaptado a novos ambientes.

facilidade do software
poder ser transferido Instalabilidade facilidade de instalação do produto de software.
de um ambiente para
outro. Conformidade o produto apresenta-se compatível com os padrões ou convenções de
com padrões de portatilidade.
portatilidade
o produto de software pode ser substituído por outro, sem grandes
Substituibilidade esforços.
66

5 - Eficiência - observa-se Comportamento medida do tempo de resposta e de processamento, assim como as taxas
nesta característica o nível no tempo de processamento (throughput), ao executar a funções prescritas.
de desempenho do software
e a quantidade de recursos
utilizados sob condições Comportamento atributos do software que evidenciam seu tempo de resposta, tempo de
estabelecidas. dos recursos processamento e velocidade na execução de suas funções.
Analisabilidade característica de ser possível diagnosticar deficiências e causas de falhas.

6 - Manutenibilidade -
refere-se ao esforço necessário característica que o produto deve ter de forma a facilitar modificações e
para a realização de alterações Modificabilidade remoções de defeitos.
específicas no produto de
software. Estabilidade medida do risco de efeitos inesperados provenientes de modificações.
Testabilidade facilidade do produto ser testado.
A norma ISO/IEC 9126-4 evidencia a qualidade em

uso do produto.
A qualidade em uso refere-se ao alcance pelo usuário de

metas como efetividade, produtividade, segurança e satisfação.
Rocha(2001) descreve as quatro metas:
Efetividade: refere-se a capacidade do produto

de software possibilitar ao usuário atingir metas
especificadas como acurácia (resultados precisos) e
completeza em um contexto especificado de uso.
Produtividade: refere-se a capacidade do produto
de software de possibilitar aos usuários utilizar uma
quantidade adequada de recursos em relação a efetividade
alcançada em um contexto de uso especificado. O
produto de software quando executa ocupa CPU,
memória dentro de um valor adequado para o tipo de
objetivo para o qual foi desenvolvido?
Segurança: refere-se a capacidade do produto de software
oferecer níveis aceitáveis de risco de danos e pessoas,
negócios, software, propriedade ou ambiente em um
contexto de uso especificado.
Unidade 3 67

Satisfação: refere-se a capacidade do produto de software

em satisfazer as necessidades do usuário em um contexto
de uso especificado.
Os requisitos de qualidade não são os mesmos

para todos os softwares?
Cada tipo de software possui seus próprios requisitos de

qualidade, por isto você pode dizer que a importância de cada
uma das características de qualidade varia conforme o tipo de
software desenvolvido.
Observe o exemplo a seguir:

Sistema Sistema
Características
Contabilidade Controle Mísseis
Usabilidade
Funcionalidade
Eficiência
Manutenibilidade ou
Manutenção
Portabilidade
Confiabilidade
Em um sistema de controle de mísseis, por exemplo,

a eficiência do software e sua confiabilidade são mais
importantes do que a portabilidade ou a usabilidade.
68

Quem está no Brasil certificando a norma ISO/IEC

9126?
Temos no Brasil as seguintes empresas certificadoras da norma

ISO/IEC 9126:
CTI, Campinas / SP;

INSOFT, Fortaleza / CE;
Centros SOFTEX Gênesis;
GENE-JF, Juiz de Fora / MG;
GENORP, Londrina / PR;
ICMC/USP, São Carlos / SP;
UNISINOS, São Leopoldo / RS.
Você poderá acessar na página: <http://www.mct.gov.

br> os indicares de qualidade para a norma ISO/IEC
9126 apontados pela Secretaria de Política de Informática do
Ministério de Ciência e Tecnologia no âmbito do Subcomitê
Setorial da Qualidade e Produtividade em Software.
Conhecer as características e subcaracterísticas da

ISO/IEC 9126 apenas inicia o trabalho.
A norma ISO/IEC 9126 nos detalha aspectos que devem ser

avaliados em um produto para ser considerado de qualidade, só
que para fazer a avaliação é necessário a obtenção de maiores
detalhes sobre como fazer uma avaliação da qualidade de um
software.
É neste contexto que entra a ISO/IEC 14598. Esta norma

descreve detalhadamente todos os passos para que se avalie um
software. E esta é a proposta de estudo da próxima seção. Siga em
frente!
Unidade 3 69

SEÇÃO 3 – ISO/IEC 14598 - Information Technology

Software Product Evaluation
A norma ISO/IEC 14598 define um processo de avaliação da
qualidade do software, ela orienta que o seu uso deve ser feito em
conjunto com a norma ISO 9126, já que esta define as métricas
de qualidade de software.
A norma ISO/IEC 14598 inclui modelos para

relatórios de avaliação, técnicas para medição das
características, documentos necessários para avaliação
e fases da avaliação.
No processo de avaliação definido nesta norma, a

identificação das necessidades do usuário é um passo
importante para a qualidade do uso.
Tais requisitos são informais por natureza e

precisam ser formalizados. Eles podem ser
quantificados e a qualidade de uso avaliada em
métricas (ISO/IEC 9126).
A norma leva em consideração três grupos de

avaliadores:
Empresas que desenvolvem software que procuram

melhorar a qualidade de seu próprio produto.
Empresas que adquirem software possibilitando
determinar a qualidade do produto que irão adquirir.
Empresas que fazem certificação apoiando a emissão de
um documento oficial sobre a qualidade de um software.
70

Como a norma é apresentada?
A norma é apresentada no quadro a seguir, na forma de seis

processos, acompanhe:
Quadro 3 – Norma ISO/IEC 14598 e suas partes
Norma Processo
1) Visão Geral - A primeira parte da norma ensina a utilizar as outras normas do grupo. Ela apresenta a estrutura
de funcionamento da série de normas para a avaliação da qualidade do produto de software, assim como apresenta a
definição de termos técnicos utilizados no modelo.
Deve ser usada em conjunto com a ISO/IEC 9126 por todos aqueles que necessitem verificar a qualidade do produto
de software.
2) Planejamento e Gerenciamento - A segunda parte apresenta como fazer uma avaliação, de forma geral.
A norma apresenta requisitos, recomendações e orientações para uma função de suporte ao processo de avaliação
do produto de software. O suporte refere-se ao planejamento e a gestão do processo de avaliação e a tecnologia
necessária para realização da avaliação.
Esta norma apóia o processo de avaliação conforme o público-alvo.
3) Guia para Desenvolvedores - A terceira parte da norma propõe como avaliar sob o ponto do vista de quem
desenvolve, o desenvolvedor deve definir as condições sob as quais as medições devem ser executadas. Isto significa
que deve identificar outros atributos cujos valores influem nas medições.
ISO/IEC 14598
Lembre-se que esta norma pretende a definição e o acompanhamento e controle da qualidade durante o
desenvolvimento do software.
4) Guia para Aquisição - Como avaliar sob o ponto de vista de quem vai adquirir. A norma está dividida em dois
processos distintos um para aquisição de produtos de software de prateleira e outro para aquisição de software sob
encomenda ou modificação em produtos de software existentes.
É muito usada na aceitação ou seleção de um produto de software.
Pense em como esta norma pode ser útil se você for o comprador de softwares aplicativos para sua empresa. De
forma segura você vai poder avaliar qual o melhor produto para sua empresa entre tantos fornecedores!
5) Guia para Avaliação - O guia de avaliação apóia empresas de certificação: como avaliar sob o ponto de vista
de quem certifica. Fornece requisitos e recomendações para implementação prática de avaliação de produto de
software. Deve ser usada para a definição e acompanhamento de um processo de avaliação.
6) Módulos de Avaliação - O módulo de avaliação é uma norma de apoio, oferece detalhes sobre como avaliar
cada característica, definindo a estrutura e o conteúdo da documentação a ser utilizada para descrever um módulo
de avaliação.
Unidade 3 71

Quais características são esperadas no processo

de avaliação da norma?
As características esperadas no processo, segundo Tsukumu

(1997), é que ele seja:
repetitível – se você avaliar repetidamente um mesmo

produto, usando a mesma especificação da avaliação,
realizada por um mesmo avaliador deve produzir
resultados idênticos.
reprodutível - se você avaliar repetidamente um mesmo
produto, usando a mesma especificação da avaliação,
realizada por outro avaliador deve produzir resultados
idênticos.
imparcial – a avaliação não deve ser influenciada frente a
nenhum resultado particular.
objetivo – os resultados da avaliação devem ser factuais,
não devem ser influenciados por sentimentos ou opiniões
do avaliador.
Quais as atividades propostas no processo de

avaliação da norma?
São cinco as atividades propostas:
a análise de requisitos da avaliação – na primeira

atividade você descreve os objetivos da avaliação. Você
pode considerar pontos de vista do fornecedor, do
comprador, de desenvolvedor entre outros.
a especificação da avaliação – nesta segunda atividade
se estabelece o escopo da avaliação e as medidas a serem
executadas no produto submetido a avaliação nos seus
componentes.
o projeto de avaliação – nesta terceira atividade,
documentam-se os procedimentos a serem usados pelo
avaliador para executar as medidas especificadas na etapa
72

anterior. Nesta etapa o avaliador produz um plano de

avaliação, nele está descrito os recursos necessários para
executar a avaliação.
a fase de execução da avaliação – na quarta atividade,
é o momento onde se colhe os resultados da execução
de ações para medir e verificar o produto de software de
acordo com os requisitos da avaliação.
Aqui já se produz um rascunho do relatório de avaliação
e o registro da avaliação.
a conclusão da avaliação - a quinta e última atividade,

é onde deve ser revisado o relatório de avaliação e
disponibilizados os resultados do trabalho.
Seção 4 - ISO/IEC 12113 – Software Packages Quality

A norma ISO/IEC 12113 publicada em 1994 estabelece os
requisitos e instruções a respeito de como testar um pacote de
software, em relação aos requisitos estabelecidos para os pacotes
conhecidos como “software de prateleira”.
O escopo da norma refere-se ao pacote de software, oferecido no

mercado, e não os processos de desenvolvimento e fornecimento
do software.
O que exatamente trata a norma?
Ela trata de todos os componentes do produto disponíveis

ao usuário (documentação, manual de instrução e guia de
instalação) na forma como são oferecidos e liberados para uso.
Unidade 3 73

Os componentes de avaliação da norma são descritos na figura a

seguir:
12113
Figura 2 - Estrutura da Norma ISO/IEC 12113 (Fonte Tsukumo, 1997)
4.1 - Requisitos de Qualidade

São requisitos de qualidade necessários para a realização da
avaliação:
Descrição do produto: é um documento que

descreve as propriedades do produto, este
documento deve orientar compradores potenciais
na avaliação da adequação do produto antes
de comprá-lo. Deve incluir declarações sobre
funcionalidade, confiabilidade, usabilidade,
eficiência, ou manutenção e portabilidade.
Documentação do usuário: é o conjunto de
documentos que podem ser impressos (manuais
do usuário, instalação , etc) ou digitais (Help, site de
ajuda) oferecidos para o usuário visando orientá-lo
na utilização do produto de software.
Programas e dados : conjunto completo de
programas de computador e dados para a aplicação
do produto de software, deve descrever em detalhes
cada uma das funções do software.
74

4.2. Instruções para Teste

São instruções necessárias para a realização da avaliação:
Pré-requisitos de teste - lista de itens necessários

ao teste, incluindo documentos incluídos no pacote,
componentes do sistema e material de treinamento.
Atividades de teste - instruções detalhadas sobre
os procedimentos de teste, inclusive instalação e
execução de cada uma das funções descritas.
Registro de teste - informações sobre como os
testes foram realizados, de tal forma a permitir uma
reprodução destes testes. Deve incluir parâmetros
utilizados, resultados associados, falhas ocorridas e
até a identidade do pessoal envolvido.
Relatório de teste - relatório incluindo:
identificação do produto, hardware e software
utilizados, documentos utilizados, resultados dos
testes, lista de não-conformidade com os requisitos,
lista de não-conformidade com as recomendações,
datas, etc.

conhecimentos.
Unidade 3 75

Leia com atenção os enunciados e, após, realize as questões propostas:

1) Identifique (V) Verdadeiro ou (F) Falso para as expressões que seguem:
( ) a) A norma ISO 12119 é responsável pela avaliação de produtos de
software.
( ) b) A norma NBR 13596 é a tradução para o português da norma ISO/
IEC 14598.
( ) c) A ISO/IEC 9126 pode ser usada na avaliação do software
desenvolvido antes da entrega ao cliente ou antes da aceitação pelo
cliente.
( ) d) A norma 14598 oferece um processo de avaliação adaptado para
as três visões a visão do desenvolvedor, a visão do comprador e a visão
do avaliador.
( ) e) A parte 4 da ISO/IEC 9126 estabelece as métricas para avaliação da
qualidade de uso.
2) Assinale a(s) afirmativa(s) correta(s). É correto afirmar que para

determinar a qualidade do produto:
( ) a) A qualidade do produto pode ser determinada simplesmente pela
satisfação do usuário.
( ) b) A satisfação do cliente pode ser considerada como um atributo
entre outros a ser avaliado.
( ) c) O uso de um modelo organiza os atributos a serem avaliados
determinando claramente sua importância ou influência na qualidade
do produto.
76

3) Relacione a 1ª coluna - as características da ISO/IEC 9126 com a 2ª- suas

subcaracterísticas:
a) Funcionalidade ( ) Inteligibilidade, aprensibilidade,

operacionalidade.
b) Confiabilidade
( ) Maturidade, tolerância a falhas,
c) Usabilidade recuperabilidade.
d) Eficiência ( ) Adequação, acurácia, interoperabilidade,
e) Manutenibilidade conformidade, segurança de acesso.
f) Portabilidade ( ) Comportamento no tempo e recursos.

( ) Analisibilidade, modificabilidade,
estabilidade, testabilidade.
( ) Adaptabilidade, Instabilidade,
substituibilidade.
4) Qual a importância na norma ISO/IEC 14598 da característica do

processo de avaliação ser reprodutível e imparcial?
Unidade 3 77

5) Descreva os requisitos de qualidade necessários para a avaliação da

norma ISO/IEC 12227.

das atividades propostas no EVA.
Lembre-se que sua dedicação aos estudos é
contemplada com o desenvolvimento pessoal e
profissional.
Síntese
A avaliação do produto de software tem sido utilizada por

empresas desenvolvedoras de software para assegurar a qualidade
de seus produtos. Para que esta avaliação ocorra com o sucesso
é necessário o uso de um modelo de qualidade que estabeleça
claramente e permita avaliar os requisitos de qualidade, além
disto o processo de avaliação deve ser claramente definido e
estruturado. A ISO/IEC 9126-1 é um modelo de qualidade
que privilegia a visão do usuário não importando se é usuário
final, programador ou analista. O modelo é hierárquico formado
por níveis. No primeiro nível estão definidas as características
de qualidade do produto e no segundo nível são definidas as
subcaracterísticas relacionadas a cada uma das características do
nível anterior.
A norma ISO/IEC 14598 é usada em conjunto com a ISO/IEC

9126-1 servindo de apoio e completando o processo de avaliação.
78

A ISO/IEC 14598 descreve inclusive modelos para relatórios de

avaliação, técnicas para medição das características, documentos
necessários para avaliação e fases da avaliação. A norma ISO/
IEC 12113 foi concebida para avaliação de softwares de prateleira.
Cada uma das três normas podem ser utilizadas de forma
complementar.
O uso de normas que avaliam o produto de software oferece

respaldo para as empresas de desenvolvimento na forma de
padrão e direcionamento para execução do processo revertendo
em produtos de qualidade para o usuário final.
Após o estudo desta unidade, a seqüência propõe que você estude

na unidade 4, Métricas de software. Até lá!
Saiba mais
Se você se sentir instigado a estudar um pouco mais sobre

a aplicação da norma ISO/IEC 14598 em conjunto com a
ISO/IEC 9126, dê uma olhada em nossa midiateca onde está
disponibilizado um Guia para Utilização das Normas sobre
Avaliação de Qualidade do Produto de Software ISO/IEC
9126 e ISO /IEC 14598 desenvolvido pelo Subcomitê de
Software SC10 da ABNT, veja ele está no link Guia_Aplicacao_
ISO14598.
Para saber mais sobre qualidade do produto leia o livro de Ian

Sommerville, Engenharia de Software, Editora Prentice-Hall ,
2003.
Unidade 3 79

4
UNIDADE 4
Métricas de Software
Conhecer a importância do uso de medidas no processo
de desenvolvimento de software e sua relação direta no
controle do processo de qualidade
Tomar contato com técnicas e métodos de medição
reconhecidos pela comunidade de desenvolvimento de
software.
Seções de estudo
Seção 1 Por que medir?
Seção 2 Quais são os tipos de métricas?
Seção 3 PSM – Practical Software Measurement



Quando você observa uma empresa de desenvolvimento de
software com vários funcionários e logo imagina como o gerente
consegue acompanhar a produtividade de seus funcionários,
como administrar seus clientes e seus problemas, indiretamente
você está pensando no desempenho da empresa. E, é a partir
deste ponto, que se forma a idéia da necessidade de quantificar
fases do processo.
A necessidade de quantificar fases de processo pode ser

viabilizada a partir da utilização de um mecanismo de medição
que forneça um retrato da situação atual, de forma quantitativa.
A busca pela qualidade utilizando métricas de software deve ser

aplicada tanto às pessoas que produzem o produto, quanto para o
processo em que se desenvolve o mesmo produto.
Dificilmente se encontra uma organização de desenvolvimento

de software que não tenha, de alguma forma, uma infra-estrutura
de medição, assim como é impossível imaginar um processo de
qualidade sem que o mesmo faça uso de medidas.
A partir das informações obtidas com a medição, você toma

decisões e estabelece ações de melhoria ou correções necessárias,
mas para medir é necessário definir o que medir, como medir, e
como analisar o que foi medido.
Nesta unidade você vai estudar algumas técnicas utilizadas na

medição de produtos e processos de software e sua relevância para
se obter a qualidade do processo e do produto de software. Bem-
vindo ao estudo da unidade medidas de software!
82

SEÇÃO 1 – Porque medir?

Quando você inicia o estudo de métricas ou
medidas de software vai encontrar nos livros de
engenharia de software uma justificativa que se
repete em todos os autores:
Medições e métricas auxiliam a entender

o processo usado para se desenvolver um
produto.
Mas você pode se perguntar por que medir? A

implantação de um processo de qualidade não é o
suficiente para garantir a qualidade do produto?
A resposta infelizmente é não! Medindo, você pode saber se as

ações de melhoria implementadas no processo deram resultado.
Ao medir, você pode mostrar a administração que os recursos
destinados às melhorias foram bem empregados.
Resumindo: o uso de métricas apóia e valida quantitativamente

a evolução da qualidade do processo e consequentemente do
produto!
E as medições, quando se trata de software?
Medições são necessárias para analisar a qualidade e a

produtividade do processo de desenvolvimento e manutenção,
bem como do produto de software construído.
Assim, você pode justificar a medição do software pensando

em uma forma de indicar a qualidade do produto, avaliar a
produtividade das pessoas que produzem o produto ou mesmo
para avaliar benefícios derivados de novos métodos e ferramentas,
justificando pedidos de novas ferramentas ou treinamento.
Unidade 4 83

Para entender o alcance das métricas é importante

dividi-las em duas categorias: as diretas e as
indiretas.
Se você pensar em termos de medidas diretas no processo de

engenharia de software você deve incluir questões como custo e
esforço aplicados no processo.
Então pense: o que poderia ser uma medida direta? Você poderia
usar como medida direta o número de linhas de código do
programa, o número de erros observados durante os testes, a
quantidade de memória utilizada por um determinado programa
ou mesmo a quantidade de processador necessário para rodar o
programa.
Se você pensar em medidas indiretas do produto, então vai

estar medindo questões como a funcionalidade, a qualidade, a
complexidade, a eficiência, a confiabilidade e a manutenibilidade
do produto.
Imagine que você seja escalado para medir a

manutenibilidade de um web site. Neste caso, você
poderia usar como medida o tempo e o número de
pessoas necessárias para a realização de solicitações
de atualização do cliente, por exemplo.
1.1 O que você acredita ser mais fácil de medir? Medidas

diretas ou indiretas?
As medidas diretas são mais fáceis de serem aplicadas quando
um padrão claro de medição é adotado antecipadamente, já as
medidas indiretas são mais difíceis de serem medidas.
Acredito que a esta altura, você já esteja convencido da

importância das métricas que permitem a melhoria do processo
e o aumento da qualidade do produto. A partir deste ponto, no
entanto você vai se perguntar:
84

1.2 Quais são as métricas apropriadas para o processo e o

produto?
Para chegar a esta resposta e conseqüente implementação de um
programa de métricas é preciso identificar os tipos e categorias de
métricas existentes (métricas de tamanho de software, métricas de
qualidade, métricas de produtividade e outras) e os usuários das
métricas (os que farão uso dos resultados).
Ao iniciar a aplicação de um programa de métricas procure

definir métricas simples de entender e objetivas, a influência de
julgamento pessoal na coleta, cálculo e na análise dos resultados.
As métricas usadas devem ser informativas, seus resultados

devem retornar na forma de informações que possibilitem avaliar
resultados de decisões e ações realizadas no passado (acertadas
ou não ), que evidenciem a ocorrência de eventos presentes, bem
como prever a possibilidade de ocorrências de eventos futuros.
E nunca se esqueça !
- As métricas devem ser efetivas no custo, ou seja, o valor

da informação obtido como resultado das medições deve
compensar o custo de coletar, armazenar e calcular as métricas
(CAMPELO, 2002).
1.3 Quais as características desejáveis em um conjunto de

métricas?
Algumas características desejáveis, segundo Brito e Abreu (1994),
relacionam que as métricas devem:
ser bem definidas;

ser dimensionáveis ou expressas em alguma unidade;
ser obtidas o mais cedo possível no ciclo de vida do
sistema;
ser facilmente calculadas;
Unidade 4 85

estar em uma escala que aumente sua precisão;

ser vistas como probabilidades de forma a permitir a
aplicação de teorias estatísticas sobre as mesmas;
A utilização de métricas quando bem utilizadas, oferecem ao

gerente do projeto estimativas que são usadas para manter o
projeto dentro do cronograma e custo previstos.
O projeto de desenvolvimento de um software se assemelha

em muito a um rally. Muitos são os riscos que podem atrasar
ou comprometer a qualidade do projeto, o uso de estimativas
minimiza e até mesmo apóia o preparo da equipe para estas
situações.
Para ilustrar bem esta comparação, leia com atenção o texto que
segue:
Métricas e estimativas de Software - O início de

um rally de regularidade
Álvaro Eduardo Gomes
Imagine que você faça parte de uma equipe de Rally, e

que você e sua equipe tenham que atravessar um deserto
enorme e cheio de obstáculos e que 50% dos fatores
críticos de sucesso dependam do seu navegador para
estimar o tempo do percurso e a distância. Agora imagine-
se diante de um projeto de Sistemas de Informação onde
50% dos fatores críticos de sucesso estão nos prazos e
custos. Certamente você terá que fazer uma eficiente
métrica e estimativa de software.
As métricas e estimativas de software vêm se tornando um
dos principais tópicos na Engenharia da Informação com a
crescente exigência de seus consumidores pela qualidade,
rapidez, comodidade e baixo custo de implantação e
manutenção, é impossível não enxergar tais técnicas como
alavanca para um produto de melhor qualidade, com
custos adequados.
Mas existem ainda muitas barreiras que impedem os
profissionais da área de utilizarem tais técnicas ou de
o fazerem de maneira errônea, embora a literatura
disponível atualmente sobre engenharia da informação seja
relativamente ampla e variada, o que nos leva a questionar:
86

Tais questões nos levam a crer que algumas métricas

e estimativas de software ficaram obsoletas e outras
ganharam vigor nas épocas atuais, quando a busca da
qualidade de software vem crescendo com grande rapidez.
A métrica de software tem como princípios especificar as
funções de coleta de dados de avaliação e desempenho,
atribuir essas responsabilidades a toda a equipe envolvida
no projeto, reunir dados de desempenho pertencentes à
complementação do software, analisar os históricos dos
projetos anteriores para determinar o efeito desses fatores
e utilizar esses efeitos para pesar as previsões futuras. Estes
princípios nos permite prever o resto do processo, avaliar
o progresso e reduzir a complexidade, como numa prova
de rally, onde a cada corrida ficamos mais esclarecidos da
condições e limites da equipe.
Agora que você compreendeu a importância de medir, conheça

na próxima unidade quais são os tipos de Métricas.
SEÇÃO 2 – Quais são os tipos de métricas?

Pressman (1995), dividiu o domínio das métricas de software sob
o ponto de vista da aplicação em:
a) Métricas de qualidade: oferecem uma indicação de quanto

o software pode adequar-se às exigências implícitas e explícitas
do cliente. Normalmente, a qualidade é medida durante
todo o processo de engenharia de software (complexidade,
modularidade e tamanho do programa) e depois que o produto
é entregue a seu usuário (número de defeitos, manutebilidade do
sistema). Tipicamente empresas desenvolvedoras utilizam-se da
norma ISO/IEC 9126 que possuem um conjunto de métricas
relacionadas às suas características.
Unidade 4 87

b) Métricas de produtividade: concentra-se na saída do

processo de engenharia de software.
c) Métricas técnicas: concentra-se na característica do

software, na sua complexibilidade lógica e grau de
manutenibilidade e não no processo por meio do
qual o software foi desenvolvido.
d) Métricas orientadas ao tamanho: são medidas

diretas do software e do processo por meio do qual
ele é desenvolvido.
e) Métricas orientadas para função: são medidas

indiretas do software e do processo por meio do qual ele
é desenvolvido, determina de forma consistente o tamanho e a
complexidade de um software.
f) Métricas orientadas às pessoas: compilam informações sobre

a maneira segundo a qual as pessoas desenvolvem software de
computador, e as percepções humanas sobre a efetividade das
ferramentas e métodos.
A classificação das métricas não é uma unanimidade, em alguns

casos parecem até redundantes, como no caso das métricas de
produtividade e orientadas ao tamanho. A seguir, acompanhe
mais detalhes sobre as métricas orientadas ao tamanho e a
função:
2.1 Métricas orientadas ao tamanho

As métricas de software orientadas ao tamanho são medidas
diretas do software e do processo de desenvolvimento de software.
88

Imagine a seguinte situação: você tem uma pequena empresa de

desenvolvimento e mantém registros relacionados ao tamanho
destes projetos (em linhas de código) no decorrer dos últimos 5
anos.
Estes dados serão a base para alimentar um conjunto de
métricas de qualidade e de produtividade orientadas ao
tamanho para cada projeto.
Observe a figura a seguir:
Projeto Esforço $ KLOC Pg/Doc Erros Pessoas
Folha de Pagamento 24 168 12.1 365 29 3

Contabilidade 62 440 27.2 1224 86 5
Contas a Pagar 43 314 20.2 1050 64 6
Legenda:
Esforço - número de meses de desenvolvimento

$ - custo em dólares ( X 100 )
KLOC - número de linhas de código ( X 100 )
PG/Doc - refere-se ao número de páginas de documentação
Erros - erros encontradas na fase de testes
Pessoas - número de pessoas envolvidas no desenvolvimento
Observe que as métricas orientadas ao tamanho giram em torno

do número de linhas de código (LOC) como a principal medida.
Veja que a partir do quadro apresentado, torna-se possível
calcular a produtividade, a qualidade, o custo e o nível de
documentação do projeto. Acompanhe:
Produtividade = KLOC/pessoa-mês
Qualidade = erros/KLOC
Custo = $/LOC
Documentação=páginas documentação/KLOC
Contas a Pagar
Produtividade=20200 / 6 = 3366,67
Qualidade = 64/20200 = 0,003168
Custo = 31400/20200 = 1,55
Documentação = 1050/20200 = 0,05198
No sistema de contas a pagar o custo por linha de código do

projeto foi de US$ 1,55, então foram implementadas 20.200 linhas
a um custo de US$ 1,55 por linha de código. Já a produtividade
da equipe foi de 3366,67 linhas de código para cada membro da
equipe de desenvolvimento.
Unidade 4 89

Este tipo de métrica, orientada ao tamanho, possui como grande

vantagem sua fácil obtenção, o grande volume de literatura
e dados históricos disponíveis. Mas seu uso possui muitos
opositores que criticam a dependência da métrica do tipo de
linguagem de programação. Seu uso com linguagens procedurais
é eficiente, mas de difícil utilização em linguagens não-
procedurais como linguagens orientadas a objetos (JAVA), pois
não considera questões como herança por exemplo, penalizando
programas bem escritos. De qualquer maneira, sua aplicação
depende de uma base histórica de projetos anteriores.
2.2 Métricas orientadas à função

A métrica orientada à função, mede o software através da
quantificação de sua funcionalidade fornecida ao usuário.
Consiste em um método para medição de software que

determina de forma consistente, o tamanho e a complexidade de
um software, sob a perspectiva do usuário independentemente da
tecnologia utilizada.
Não são contadas linhas de código, a métrica orientada à função

concentra-se na funcionalidade ou utilidade do programa. Uma
abordagem foi sugerida baseada nesta proposta chamada de
pontos-por-função (function point).
Os pontos-por-função (FPs) são derivados usando-se uma relação

empírica baseada em medidas de informações e complexidade do
software.
90

Pontos de Função e Medidas: O que é um Ponto

de Função?
por Carol A. Dekkers, Quality Plus Technologies, Inc.,
e-mail: dekkers@qualityplustech.com
Publicado no QAI Journal
O que é Tamanho Funcional?

Tamanho funcional é uma medida de tamanho de software,
baseada em uma avaliação padronizada dos requisitos
lógicos dos usuários. Semelhante aos metros quadrados
de uma casa, pontos de função são independentes
dos métodos físicos, ferramentas ou linguagem de
desenvolvimento utilizados para construir o software. O
processo de cálculo de pontos de função está contido
no Manual de Práticas de Contagem (atualmente em sua
versão 4.0) do Grupo Internacional de Usuários de Pontos
de Função (IFPUG).
O que são Pontos de Função?
Da mesma maneira que a medida em metros quadrados
do tamanho de uma casa não permite deduzir a velocidade
com a qual a casa pode ser construída ou o seu tempo de
construção, o tamanho em Pontos de Função NÃO mede
a produtividade ou o esforço de desenvolvimento. Pontos
de função medem o tamanho do QUE o software faz, ao
invés de COMO ele é desenvolvido e implementado. Isto
significa que, dado um conjunto de requisitos de usuário,
o tamanho funcional do software será o mesmo, seja ele
desenvolvido com a utilização de COBOL ou DB2, usando
desenvolvimento rápido de aplicações (RAD), ou métodos
estruturados de desenvolvimento.
Unidade 4 91

Como calcular pontos de função?
O primeiro passo deve ser identificar as funções de negócio, no

cálculo do ponto de função são identificadas 5 funções principais:
Entradas (EE) - são informações fornecidas ao

sistema pelo usuário, ou seja entrada de dados no
sistema feitas pelo usuário, por exemplo a digitação
dos dados cadastrais para fazer sua ficha na locadora,
ou o lançamento dos dados de um DVD recebido pela
locadora.
Saídas (SE) - as saídas são relatórios, mensagens de erro,
telas do sistema. Usando como exemplo, um sistema de
videolocadora uma SE seriam relatórios de clientes, a
impressão do bloqueto de assinatura de retirada de fita.
Consultas (CE) - são perguntas diretas em uma base
de dados ou em um arquivo que buscam por dados
específicos, usam chaves simples, requerem resposta
imediata e não fazem nenhuma atualização (saídas
para as consultas do usuário). Você pode contar aqui
telas de consulta como por exemplo, a tela de consulta
para verificar se o DVD que você deseja alugar está na
locadora ou não, ou mesmo uma tela de consulta do seu
cadastro para verificar pendências de pagamento.
Arquivos (ALI) - cada agrupamento lógico de dados
que pode ser uma parte do banco de dados ou um
arquivo convencional é contado. Um exemplo de ALI
são, o arquivo que armazena as informações de todos os
clientes, de todos os DVDs da locadora.
Interface Externas (AIE) - com outro sistema (todas
as interfaces legíveis por máquina, como arquivos de
dados em fita ou disco que sejam usadas para transmitir
informações a outro sistema são contadas.
92

Imagine um processo que exija a transmissão de

dados como no caso de duplicatas cobradas por um
determinado banco, o seu sistema gera as duplicatas e
posteriormente, estas são transmitidas para o sistema
do banco que irá cobrá-las, este é um exemplo de
interface externa).
Quando as funções (EE, SE, CE, ALI, AIE) são avaliadas,

você vai ponderar a complexidade das funções em baixa, média
ou alta. São atribuídos pesos de acordo com a complexidade de
cada função de negócio. Por exemplo, se você tiver uma entrada
de dados em um dos programas do sistema considerado como
complexa, você vai multiplicar 1 X 6 e o valor da contagem para
este programa será 6.
Parâmetro de Contagem Fator de Ponderação Pontos
medida
Simples Médio Complexo
EE X3 X4 X6
SE X4 X5 X7
CE X3 X4 X6
ALI X7 X 10 X 15
AIE X5 X7 X 10
Unidade 4 93

Veja outro exemplo:

Imagine que você pretenda calcular o ponto por
função de um sistema simples composto apenas de
um cadastro de alunos, cadastro de notas, relatório
em ordem alfabética de aluno e exportação dos dados
do aluno para um arquivo no formato Excel que será
utilizado por outro setor da escola. O primeiro passo
vai ser a identificação das funções do negócio.
Contagem:
ALI = 02 (temos no sistema o arquivo de alunos e o arquivos de notas)
AIE = 0
SE = 01 (como saída só existe uma listagem de alunos em ordem alfabética)
(existem duas entradas de dados, uma para inclusão de dados do aluno

EE = 02 e outra para inclusão de notas)
(os dados do aluno são exportados para que possam ser consultados no
CE = 01 arquivo Excel)
Todos os tipos de função serão considerados de

complexidade SIMPLES nesse exemplo.
Fator de Ponderação
Parâmetro Contagem Pontos
de medida
Simples Médio Complexo
EE 02 X3 06
SE 01 X4 04
CE 01 X3 03
ALI 02 X7 14
AIE X5 0
Total 27
Para calcular os pontos por função, você vai utilizar

esta fórmula:
FP = contagem total x [0,65 + 0,01 x SOMA(Fi)]
94

O que é a SOMA(Fi)?
A Fi representa um fator de ajuste sobre fatores que influenciam a

implantação do software.
Este fator de ajuste é extraído de uma lista de fatores (exemplo:

14 fatores) é adaptada às necessidades da empresa e pode ser
modificada de acordo com suas necessidades.
A tabela apresentada é um exemplo de fatores que

podem ser considerados na avaliação:
01) Comunicação de dados
02) Processamento de dados distribuído (funções
distribuídas)
03) Performance
04) Configuração do equipamento
05) Volume de transações
06) Entrada de dados on-line
07) Interface com o usuário
08) Atualização on-line
09) Processamento complexo
10) Reusabilidade
11) Facilidade de implantação
12) Facilidade operacional
13) Múltiplos locais
14) Facilidade de mudanças.
Cada fator deve ser pontuado com valores de 0 a 5, de acordo

com sua influência sobre o processo de desenvolvimento:
0: Sem influência. 3: Médio

1: Incidental. 4: Significativo.
2: Moderado. 5: Essencial.
Unidade 4 95

Acompanhe que na tabela a seguir, calcula-se o fator de ajuste do

sistema de alunos pela contagem dos fatores (lembre-se que esta
contagem é um exemplo e pode ser diferente de acordo com o
projeto ou mesmo a situação da empresa desenvolvedora):
Fator Contagem
1. Comunicação de dados 0
2. Processamento de dados distribuído (Funções Distribuídas) 0
3. Performance 3
4. Configuração do equipamento 3
5. Volume de transações 2
6. Entrada de dados on-line 3
7. Interface com o usuário 4
8. Atualização on-line 5
9. Processamento complexo 0
10. Reusabilidade? 0
11. Facilidade de implantação 0
12. Facilidade operacional 0
13. Múltiplos locais 0
14. Facilidade de mudanças 0
Total 20
Neste caso, considere que a performance do software tem uma

influência média no projeto, que a atualização on-line de notas é
essencial, que a interface do usuário é um fator significativo para
o sucesso do produto.
Assim, substituindo na fórmula:
FP = contagem total x [0,65 + 0,01 x SOMA(Fi)]

FP= 27 X [ 0,65 + 0,01 X 20 ]
FP = 22,95
96

Ao chegar ao valor do ponto por função (22,95) você pode usar

as seguintes medidas para cálculos de produtividade, qualidade e
custos já utilizados anteriormente usando KLOC:
Calcular a produtividade > Produtividade = FP/pessoa-mês.

Calcular a qualidade > Qualidade = defeitos/FP.
Calcular o custo> Custo = $/FP.
Calcular a documentação > Documentação = páginas de documentação/FP.
Lembre-se: para usar as métricas de ponto por

função para uma proposta orientada a objetos,
é necessário adaptar a contagem dos pontos
considerando o número de classes, número de cases,
número de métodos, médias de métodos, médias de
métodos por classe, linhas de código por método,
profundidade máxima da hierarquia de classes, a
relação existente entre métodos públicos e privados,
entre outros.
Quais são os benefícios das métricas orientadas à

função?
As métricas orientadas à função apresentam vários benefícios

sendo usadas como:
forma de dimensionar aplicações;

veículo para quantificar custo, esforço e tempo;
ferramenta para cálculo de índices de produtividade e
qualidade ou mesmo;
fator de normalização para comparar software.
Hoje ela é usada em conjunto na implantação do modelo CMM

e CMMI como apoio a implantação das áreas-chaves Gerência
de requisitos, Planejamento e Acompanhamento de Software e
Gerência de subcontratação de software.
O uso do ponto por função ultrapassou as barreiras para avaliação

da qualidade e sua quantificação está sendo usada inclusive, para
a aquisição de produtos de software.
Unidade 4 97

Observe o exemplo da Austrália:
A Solução Australiana para os Projetos de

Desenvolvimento de Sistemas
O governo do Estado de Victoria, Austrália, possui um
orçamento anual para software da ordem de US$ 26
milhões. (Cerca de R$ 66 milhões). É líder nacional na
utilização da TI para prover serviços aos cidadãos.
Assim como outras organizações, tem enfrentado
sérios problemas no desenvolvimento de software.
Anteriormente, os preços eram fixos nas contratações de
desenvolvimento. Os fornecedores cotavam preços baixos
nas licitações, a fim de ganhar o contrato, na expectativa de
que o cliente solicitasse muitas alterações no decorrer do
projeto. Essas alterações eram cobradas a um preço alto, de
modo a compensar o preço baixo original.
A solução adotada foi a contratação baseada em um preço
fixo por ponto de função. Com base em uma especificação
preliminar, é licitado o preço por ponto de função.
O fornecedor é escolhido com base no preço oferecido e
na capacitação técnica. O pagamento é efetuado com base
no preço por ponto de função contratado, no tamanho do
software entregue e nas modificações solicitadas ao longo
do projeto.
PMI Information Systems Local Interest Group – Rio
Mauricio Aguiar, CFPS
No Brasil empresas como o Correio, Serpro, Dataprev, Caixa

Econômica Federal selecionam e pagam seus fornecedores
usando pontos por função. Neste caso é utilizado para determinar
o custo, qualidade e produtividade.
Agora que você conhece quais são os tipos de métricas, conheça

na próxima seção um modelo de mensuração que foi desenvolvido
recentemente. Siga em frente!
98

SEÇÃO 3 - PSM – Practical Software Measurement

PSM é um modelo de mensuração patrocinado pelo
Departamento de Defesa Americano (DoD). Este modelo é
bastante recente e foi publicado pela primeira vez em 1997,
apesar de novo, tem sido usado no mundo todo como base para
elaborar a Process Area Measurement and Analysis do CMMI e foi
padronizado pela norma ISO/IEC 15939 Software Engineering
– Software Measurement Process Framework.
Segundo Aguiar (2005), o PSM é adaptado para abordar os

objetivos, questões e requisitos de informação específicos do
sistema e do software, pertinentes a cada programa ou projeto. O
processo de medição do PSM é definido a partir de um conjunto
de 9 melhores práticas, denominadas princípios da medição.
Curiosidade: você sabia que fazem parte do

desenvolvimento do PSM organizações muito
diferentes como a força aérea, a marinha e o exército
americano, a Boeing, o Mitre, GTE entre muitos
outros?
Segundo Aguiar (2002), o modelo de estruturação de atividades

de mensuração em um projeto de software, o PSM deve resolver
alguns problemas básicos:
Como especificar formalmente as medidas que serão

utilizadas no processo.
Como conduzir o processo de medição.
O PSM atinge estes dois problemas fazendo uso de 2 modelos:

o modelo de informação e o modelo de processo. A seguir
conheça mais detalhes sobre cada um destes modelos.
Unidade 4 99

3.1 - Modelo de Informação

No modelo de informação você vai definir a estrutura e as
medidas que serão utilizadas no projeto. Neste modelo existem
alguns conceitos:
Atributo – propriedades consideradas fundamentais sob

o ponto de vista de necessidades da informação ( um
atributo importante pode ser as horas trabalhadas ou
mesmo as funcionalidades que você obtém a partir das
especificações do projeto).
Método – é uma operação que mapeia o atributo para
uma escala (você pode usar o ponto por função para obter
o tamanho do projeto, ou contar o tamanho do projeto
em número de horas ou mesmo linhas de código).
Medida básica – a medida básica é o resultado da
aplicação do método sobre o atributo (se você aplicar o
ponto por função vai ter como medida básica o tamanho
do projeto em pontos por função).
Função – a função é um algoritmo que combina duas ou
mais medidas básicas (se você contou o projeto em pontos
por função, pode dividir estes pontos pelo número de
horas trabalhadas nele, assim terá a medida do esforço
para seu desenvolvimento).
Modelo – o modelo é um algoritmo que combina
medidas e critérios de decisão.
Indicador – o indicador é uma estimativa que promove
uma baseline para tomada de decisões.
100

Figura 1 - Construção Mensurável (AGUIAR, 2005)
3.2 - Modelo de Processo

O modelo de processo é um roteiro que apóia a equipe de
medição na condução das atividades para a execução da mesma.
O modelo é composto de três pontes principais: os processos
técnicos gerencias, os processos centrais de mensuração e a
avaliação da mensuração.
Unidade 4 101

Figura 2. Modelo de Processo Aguiar (2005)
Ao observar a figura 2, você pode verificar que o processo

mais central compreende as atividades centrais de medição.
Neste processo você tem atividades fundamentais como o
planejamento da medição.
Para planejar a medição é necessária a execução de

3 subprocessos, o primeiro deles é a identificação e
priorização das necessidades de informação. Neste
subprocesso, você considera questões como objetivos,
itens críticos, ambiente de execução, melhorias
e mudanças necessárias. O PSM classifica estas
necessidades em categorias como prazo e progresso,
recursos e custo, tamanho e estabilidade do produto,
qualidade do produto, performance do processo, eficácia
da tecnologia e satisfação do usuário.
A segunda atividade deve ser a seleção e especificação
das medidas, nesta etapa você vai selecionar os
indicadores, medidas básicas e derivadas.
102

A terceira atividade é a integração da medição aos

processos de apoio. Nesta atividade você vai analisar
como os dados serão coletados e analisados.
Todos os procedimentos de coleta de dados devem ser

integrados aos processos que fornecem dados. No plano
de medição você vai ter o artefato gerado neste processo,
com toda sua documentação.
Outro processo central é a execução da medição composto por 3

atividades principais.
A primeira atividade é a coleta e o processamento de

dados. Aqui você realiza a coleta de dados considerando
a especificação contida no plano de medição, sua
preparação e armazenamento de forma que a informação
seja facilmente recuperável.
A segunda atividade, a análise dos dados envolve a
transformação das medidas básicas em indicadores e sua
utilização em questões relacionadas ao planejamento e
ações corretivas.
A última atividade do processo de execução é a produção
de recomendações. Nesta etapa são feitas avaliações do
projeto e projeções para o futuro.
Além deste processo central você também tem processos

periféricos como avaliar medição onde são avaliadas as
medidas, o próprio processo de mensuração é avaliado, a
base de experiência é avaliada e melhorias são identificadas e
implementadas.
Outro processo periférico é o estabelecimento e sustentação

de compromissos que propõe obtenção do comprometimento
organizacional, definição de responsabilidades, previsão de
recursos e revisão do progresso do programa de mensuração.
Apesar do PSM ser um modelo relativamente novo, sua

aceitação no mercado tem sido expressiva principalmente ao ser
combinada com modelos como o CMM e o CMMI.
Unidade 4 103


conhecimentos.
Leia com atenção os enunciados e realize as questões propostas:

1) Identifique (D) para as medidas Diretas e (I) para as Indiretas:
( ) a) número de erros ocorridos na fase de testes.
( ) b) confiabilidade no sistema de arquivos do projeto.
( ) c) horas de manutenção do produto
( ) d) número de relatórios de consulta existentes no projeto.
( ) e) portabilidade do produto.
( ) f) usabilidade da interface.
2) Primeiro leia com atenção à afirmações sobre métricas e a seguir

elabore uma justificativa:
a) Métricas devem ser obtidas o mais cedo possível no ciclo de vida do
sistema.
b) Métricas devem ser vistas como probabilidades, de forma a permitir a
aplicação de teorias estatísticas sobre as mesmas.
104

3) Imagine-se na seguinte situação: você desenvolveu um projeto

Contábil com a implementação de 27.200 linhas de código com uma
equipe de 5 pessoas, o projeto teve um custo de U$44.000 em um
período de 62 meses.
A seguir, calcule a produtividade e o custo por linha de código deste
projeto.
4) Identifique (V)Verdadeiro ou (F) Falso para as seguintes afirmativas

sobre ponto por função :
( ) a) Pontos por função medem o que o software faz.
( ) b) Pontos por função medem o esforço de desenvolvimento.
( ) c) As saídas computadas no ponto de função são relatórios e
mensagens de erro do sistema.
( ) d) Bases de dados com informações persistentes como cadastros de
produtos em um sistema de estoque são os arquivos computados no
ponto de função.
( ) e) As funções do ponto de função podem ser avaliadas somente em
alta e baixa.
( ) f) A definição de atributos do que deve ser relevante para considerar
uma função como de complexidade alta, deve ser definido pela
empresa que implanta a métrica.
Unidade 4 105

5) Quais são os dois modelos usados pelo PSM ?
6) Descreva a seguir, quais são as atividades existentes no planejamento

da medição.

das atividades propostas no EVA.
Lembre-se que sua dedicação aos estudos é
contemplada com o desenvolvimento pessoal e
profissional.
106

Síntese
O interesse pelo uso de métricas por empresas desenvolvedoras

de software tem aumentado de forma surpreendente nos últimos
anos. Isto tem ocorrido pelo reconhecimento por parte das
empresas, da necessidade de se estabelecerem métodos e medidas
consistentes que acompanhem a avaliação, o planejamento, o
gerenciamento e a evolução dos processo de produção.
A melhoria do processo acontece pela medição de seus atributos

significativos e pelo desenvolvimento de uma série de métricas
que forneçam indicadores capazes de apontar uma estratégia de
melhoria para este processo.
Medir não traz benefícios relacionados somente ao cumprimento

de prazos ou mesmo à estimativa de custo de um projeto, mas
traz benefícios gerais ao funcionário possibilitando melhoria
no dimensionamento desua carga de trabalho. Possibilitar
cursos e treinamentos, reequilibrar divisões de tarefas, alterar
processos considerados difíceis, readequar equipes, estes são
alguns dos resultados possíveis por meio da análise do processo
de medição. Nesta unidade observou-se que técnicas e métodos
independentes, como o ponto por função e o PSM podem ser
usados isoladamente ou em conjunto com outros modelos, como
no caso do CMM . Verificou-se que fundamental no processo de
medição é a definição do que medir, como medir e como analisar
os resultados desta medição.
Unidade 4 107

Saiba mais
Se você deseja saber mais sobre a análise de ponto de

função acesse o site do BFPUG - Brazilian Function
Point Users Group. O BFPUG é um grupo brasileiro
constituído com o objetivo de estimular e divulgar a
utilização de métricas no desenvolvimento de sistemas,
em particular a Análise de Pontos de Função -
Function Point Analysis, nele você vai encontrar artigos,
certificações, informações e relatos de experiência.
Você também pode acessar o site do FPUG internacional
o IFPUG -International Function Point Users Group
<http://www.ifpug.org/>, ele mantém os registros mais
atualizados sobre o desenvolvimento do método.
O PSM Support Center disponibiliza vários produtos
gratuitos para disseminar o PSM como guias, artigos e
até mesmo livros. Veja o site <http://www.psmsc.com>.
Você sabia que no site <www.psmsc.com>, existe uma
ferramenta baseada nos conceitos do PSM chamada
PSM Insight que você pode utilizar gratuitamente na
implantação do PSM?
108

Para concluir o estudo
Caro(a) aluno(a),
Ao se debruçar sobre as quatro unidades apresentadas

neste livro didático, você teve a oportunidade de interagir
e consolidar alguns conceitos sobre a qualidade do
processo e do produto. Contudo, aqui nestas minhas
últimas palavras, vale ainda destacar mais um ponto: - A
qualidade do processo se faz no dia a dia da empresa, no
comprometimento de toda uma equipe, do gerente ao
estagiário da empresa com a qualidade.
Todavia, também, só comprometimento não é o

suficiente, é necessário o uso de métodos, normas,
padrões que direcionem o esforço da equipe e de
medições que avaliem suas melhorias e possíveis
necessidades de correções, isto é, é necessário
competência.
É importante você observar que cada empresa possui sua

história e não existem modelos miraculosos que resolvam
os problemas de todas as empresas. O bom gerente deve
avaliar, conhecer e adaptar as melhores soluções para
seu contexto. Não existem modelos ou normas ideais,
mas soluções apropriadas construídas pelo uso de seu
conjunto.
Nas unidades, você estudou parcialmente algumas destas

soluções, para colocá-las em prática, será importante
você prosseguir fazendo pesquisas, procure aprofundar-
se sobre as que lhe despertaram interesse ou que sejam
possíveis de serem aplicadas em sua empresa.
Então, bons estudos !
Profa. Vera Rejane Niedersberg Schuhmacher

Referências
AGUIAR, M. Prátical Software Measurement: OCMM da

mensuração. Developers Magazine, Abril, 2002.
AGUIAR, M. Gerenciamento Objetivo de Projetos com PSM.
Disponível em: www.metricas.com.br Ultimo acesso: 2005
BRITO, Abreu F. MOOD – Metrics for Object-Oriented Design.
OOPSLA’94 Workshop on Pragmatic and Theoretical Directions in
Object-Oriented Software Metrics. 1994.
CAMPELO, G. M. C. A utilização de métricas na Gerência de
Projetos de Software Uma abordagem focada no CMM Nível
2. Recife: Universidade Federal de Pernambuco, Centro de
Informática, Recife, 2002
CAMPELO, G. M. C. A utilização de métricas na gerência
de projetos: Uma Abordagem focada no CMM Nível 2; 100
Páginas; Português; Orientador: MOURA, H. P.; ENGENHARIA
DE SOFTWARE. Disponível em: http://orbita.starmedia.com/
~marcos_ae/tacade/metricas.html#_Toc426210920
CHIOSSI, T.C.S. Modelos de qualidade de software. Campinas:
Editora da Unicamp, 2001.
CORDENONZI, Walkiria. Mapeamento de padrões
internacionais de qualidade de produto e de processo
para um modelo conceitual de gerência de processo e
desenvolvimento de software. Dissertação de Mestrado.
UFRGS, 2000.
DEKKERS,C. Desmistificando pontos de função: entendendo a
terminologia. IT Metrics Strategies, October, 1998.
FIORINI, S. T. et al. Engenharia de software com CMM. Rio de
Janeiro: Brasport, 1998.
HUMPHREY, W.S. A discipline for software engineering. Reading
MA: Addison-Wesley Longman, Inc. 1995.
ISO/IEC 9126-1, International Standard Information Technology
– Software Quality characteristics and metrics – Part 1: Quality
characteristics and sub- characteristics. Jan 1997.
KITCHENHAM BA. DESMET. A Method for Evaluating Software
Engineering Methods and Tools, TR96-09. Department of
Computer Science, University of Keele: Staff ordshire UK. 1996.

MCANDREWS D.R., Establishing a Software Measurement Process
Documento No CMU/SEI-93-TR-16, 1993.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books,
1995.
ROCHA, A.R.C, MALDONADO, J.,C., WEBER, K. Qualidade de Software,
Prentice Hall, 2001.
TSUKUMO, A, Rego, C., Azevedo, G. Qualidade de software: Visões de
Produto e Processo de Software, II Escola Regional de Informática, São
Paulo: Sociedade Brasileira de Computação, Piracicaba, São Paulo, 1997.

Sobre a professora conteudista
Vera Rejane Niedersberg Schuhmacher é mestre em

Engenharia de Produção com ênfase em Usabilidade de
Software pela Universidade Federal de Santa Catarina-
UFSC. Professora da Unisul desde 1998 em disciplinas
oferecidas nos cursos de Ciência da Computação e
Sistemas de Informação e Pós-graduação . Pesquisadora
do Núcleo de Computação, atua como Coordenadora do
NPU- Núcleo de Pesquisas em Usabilidade prestando
consultoria em Engenharia de Software e Usabilidade
em empresas de tecnologias e projetos financiados por
órgãos de fomento como Finep, CNPq e Funcitec.

Respostas e comentários das
atividades de auto-avaliação
A seguir acompanhe as respostas sobre as atividades de auto-

avaliação apresentadas ao longo de cada uma das unidades
dessa disciplina. Para o melhor aproveitamento do seu estudo,
confira suas respostas somente depois de realizar as atividades
propostas.
Unidade 1
1) Identifique (V)Verdadeiro ou (F)Falso para as expressões que
seguem:
(V ) a. ; (F ) b.; ( F ) c.; ( V ) d.; ( V ) e.
2) Assinale com “X” a(s) expressão(ões) corretas:

( X ) b.
3) Relacione a 2ª coluna com a 1ª:
( C ) Definem um conjunto de critérios de

desenvolvimento que orientam a maneira como
A) Métricas o software é construído.
B) Revisão técnica formal ( B ) Procura descobrir erros de função, lógica ou

implementação em qualquer representação do
software verificando se atende a seus requisitos.
C) Padrão
(A ) Indicam a qualidade do produto, a produtividade
das pessoas que produzem o produto, avaliam
D) Organismos benefícios derivados de novos métodos e
normativos ferramentas.
(D ) Criam padrões mundiais garantindo a qualidade
dos produtos, um de seus representantes é o
comitê ISO.

Unidade 2
1) O modelo CMM - Capability Maturity Model avalia a maturidade das
organizações. Relacione suas características corretamente: (atenção
que pode ocorrer repetições):
( A) também conhecido como processo previsível.
a) definido ( A) ocorrem treinamentos do grupo e a definição do processo da

organização.
b) otimizado ( C) resolução de crises imediatas.
c) inicial ( D) promove o gerenciamento quantitativo do processo.
d) gerenciado ( C) não existe base histórica.
e) repetitivo ( E) promove o gerenciamento de requisitos e a garantia da qualidade.

( B) permite o gerenciamento de mudança do processo e prevenção de
defeitos.
( E) também conhecido como processo disciplinado.
2) Complete as lacunas com as seguintes expressões:

As atividades - os níveis de maturidade – as áreas-chaves do processo
– características comuns – as atividades
No modelo CMM pode-se dizer que:
a) As áreas-chaves do processo são organizadas por características
comuns necessárias para a implementação.
b) Áreas-chaves são necessárias para atingirmos os objetivos.
c) Níveis de maturidade indicam a capacidade do processo.
d) As características comuns contém práticas base que descrevem as
atividades.
3) Descreva a seguir quais são os requisitos necessários para que se inicie

um processo de qualidade?
Resposta: Para que se inicie um processo de qualidade é necessário
definir o processo de software a partir do reconhecimento do processo
atual, determinar a capacidade do processo, e avaliar a proposta de
melhorias e evolução do processo de software. Definido o processo
ele deve ser descrito em detalhes, de forma a poder ser usado de forma
consistente.

4) Relate como é organizada a norma ISO/IEC 12207?

Resposta: A norma é definida em três grandes classes, os
processos fundamentais que se prolongam do início à execução do
desenvolvimento, operação ou manutenção do software durante
todo o seu ciclo de vida; os processos de apoio que auxiliam
outros processos e os processos organizacionais que implementam
uma estrutura constituída de processos de ciclo de vida e pessoal
associados, melhorando continuamente a estrutura e os processos.
Unidade 3
1) Identifique (V) Verdadeiro ou (F) Falso para as expressões que
seguem:
(F ) a. ; (F ) b. ; (V ) c. ; (V ) d. ; (V ) e.
2) Assinale a(s) afirmativa(s) correta(s). É correto afirmar que para

determinar a qualidade do produto:
(X) b. ; (X) c.
3) Relacione a 1ª coluna - as características da ISO/IEC 9126 com a 2ª-

suas (subcaracterísticas:
a) Funcionalidade (c ) Inteligibilidade, aprensibilidade, operacionalidade.

b) Confiabilidade (b ) Maturidade, tolerância a falhas, recuperabilidade,
c) Usabilidade (a ) Adequação, acurácia, interoperabilidade, conformidade,

segurança de acesso.
d) Eficiência (d ) Comportamento no tempo e recursos.
e) Manutenibilidade (e) Analisibilidade, modificabilidade, estabilidade, testabilidade
f) Portabilidade (f) Adaptabilidade, Instabilidade, substituibilidade
117

4) Qual a importância para a norma ISO/IEC 14598 que a característica do

processo de avaliação seja reprodutível e imparcial?
Resposta: Estas duas características são fundamentais porque deve
ser possívelrepetir uma avaliação por um mesmo avaliador ou mesmo
outro avaliador eproduzir resultados idênticos, se isto não ocorre
a avaliação não foirealizada corretamente e seus resultados são
questionáveis. O fato do processo de avaliação ser reprodutível garante
que seja possível avaliar o produto repetidamente. Desta forma,
você pode garantir a conformidade com a norma. A imparcialidade é
fundamental para garantir a credibilidade da avaliação pois a mesma
não deve ser influenciada frente a nenhum resultado particular. A
imparcialidade garante que nada influencie o processo de avaliação.
5) Descreva, a seguir, os requisitos de qualidade necessários para a
avaliação da norma ISO/IEC 12227.
Resposta: Para a realização da avaliação é necessário que se tenha
em mãos adescrição do produto, documentação do usuário e os
programas e dados.
Unidade 4
1) Identifique (D) para as medidas Diretas e (I) para as Indiretas:
( D) a. ; ( I ) b.; ( D) c. ; ( D) d. ; ( I ) e. ; ( I ) f.
2) Primeiro leia com atenção a afirmação sobre métricas, e a seguir

elabore uma justificativa:
a) Métricas devem ser obtidas o mais cedo possível no ciclo de vida do
sistema.
Resposta: Ao serem estabelecidas as métricas de um projeto em uma
fase inicial do projeto tem-se a chance de aplicá-las de forma efetiva
em todo o processo de desenvolvimento, se isto for realizado de forma
tardia etapas importantes do processo não serão medidas o que pode
comprometer os resultados do projeto.
b) Métricas devem ser vistas como probabilidades de forma a permitir a
aplicação de teorias estatísticas sobre as mesmas.
Resposta: O uso de medidas quantitativas e não-qualitativas deve
permitir o uso de cálculos estatísticos permitindo assim, a possibilidade
de estimarmos questões relacionados ao projeto em andamento ou
mesmo projetos futuros com bases no passado.
118

3) Imagine-se na seguinte situação: você desenvolveu um projeto

Contábil com a implementação de 27.200 linhas de código com uma
equipe de 5 pessoas, o projeto teve um custo de U$ 44.000 em um
período de 62 meses.
A seguir calcule a produtividade e o custo por linha de código deste
projeto.
R. Produtividade = 27.200/5 = 5.500 linhas p/p
Custo = 44.000/27.200 = U$ 1,62 por linha código
4) Identifique (V)Verdadeiro ou (F) Falso para as seguintes afirmativas

sobre ponto por função :
(V) Pontos por função medem o que o software faz.
(F) Pontos por função medem o esforço de desenvolvimento.
(V) As Saídas computadas no ponto de função são relatórios e
mensagens de erro do sistema.
(V) Bases de dados com informações persistentes como cadastros de
produtos em um sistema de estoque são os Arquivos computadas no
ponto de função.
(F) As funções do ponto de função podem ser avaliadas somente em
alta e baixa.
(V) A definição de atributos do que deve ser relevante para considerar
uma função como de complexidade alta deve ser definido pela
empresa que implanta a métrica.
5) Quais são os dois modelos usados pelo PSM ?

Resposta: Os dois modelos usados pelo PSM são o modelo de
informação onde é definida a estrutura e as medidas que serão
utilizadas no projeto e o modelo de processo que estabelece um
roteiro que apóia a equipe de medição na condução das atividades
para a execução da mesma.
6) Descreva, a seguir, quais são as atividades existentes no planejamento

da medição.
Resposta: No planejamento da medição temos a identificação e
priorização das necessidades de informação, a seleção e especificação
das medidas e a integração da medição aos processos de apoio.
119


Qualidade de Software PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Qualidade de Software PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Universidade do Sul de Santa Catarina

qualidade_software.indb 1 24/1/2007 13:14:01

Parabéns, você está recebendo o livro didático da disciplina

O processo de ensino e aprendizagem na UnisulVirtual leva

São elementos desse processo:

Os materiais didáticos foram construídos especialmente para

Recomendamos que antes de você começar os seus estudos,

Desejamos que você tenha um excelente êxito neste curso!

qualidade_software.indb 3 24/1/2007 13:14:07

3ª edição revista e atualizada

qualidade_software.indb 5 24/1/2007 13:14:08

1. Software. 2. Sistemas de recuperação da informação. I. Bittencourt, Dênia

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

UNIDADE 1 – O que é qualidade? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

qualidade_software.indb 7 24/1/2007 13:14:08

Bem-vindo a disciplina Qualidade de software! Nesta

Isto acontece porque as organizações que buscam o

Deﬁnir qualidade é uma tarefa difícil, a palavra pode

Você, seus amigos e familiares reconhecem na maioria

qualidade_software.indb 9 24/1/2007 13:14:09

Nesta disciplina você vai estudar a importância da qualidade do

Profa. Vera Rejane Niedersberg Schuhmacher.

qualidade_software.indb 10 24/1/2007 13:14:09

O plano de estudos visa orientar você no

 Sensibilizar o aluno da importância da qualidade

qualidade_software.indb 11 24/1/2007 13:14:09

A qualidade nas empresas de software é uma realidade, a

Unidade 1 - O que é qualidade?

Na primeira unidade é você que irá interagir com os conceitos

Unidade 2 - Qualidade do processo

A unidade 2 levará você a conhecer o conceito de qualidade

qualidade_software.indb 12 24/1/2007 13:14:09

Unidade 4 - Métricas de teste

Ao estudar a unidade 4 você irá perceber a importância do uso

Não perca os prazos das atividades. Registre no espaço a seguir

qualidade_software.indb 13 24/1/2007 13:14:10

Demais atividades (registro pessoal)

qualidade_software.indb 14 24/1/2007 13:14:10

 Perceber a necessidade de qualidade no processo de

 Entender o conceito de SQA – Software Quality

Nesta unidade a proposta é que você realize o estudo

Seção 1 O que é qualidade?

Seção 2 Passos em direção a política de qualidade

Seção 3 Atividades da garantia de qualidade.

Seção 4 Normas e Padrões

Após a leitura dos conteúdos realize as atividades de

qualidade_software.indb 1 24/1/2007 13:14:10

Para início de estudo

Mas o que é qualidade em uma empresa? Quais suas

Difíceis de responder, estas questões nos levam imediatamente

A qualidade possui uma característica única: o

A crescente competitividade do mercado de software impulsiona

Qualidade pode ser o diferencial de uma empresa, pode alavancar

Então ? Está curioso a seguir seus estudos? Siga em frente e dê

qualidade_software.indb 2 24/1/2007 13:14:10

SEÇÃO 1 – O que é qualidade?

Portanto, não é nada fácil estabelecer a existência de medidas

Para estimar ou melhorar a qualidade de software

Diferentes conceitos expressam a qualidade de um produto de

Você pode dizer que:

 qualidade é estar em conformidade com os requisitos

Um exemplo disto é o caso de lançamentos de novos

Sensibilizar o aluno da importância da qualidade

Perceber a necessidade de qualidade no processo de

Entender o conceito de SQA – Software Quality

qualidade é estar em conformidade com os requisitos

E ﬁnalmente, você pode expressar o termo qualidade

Requisitos de Software - formam a base a partir da qual

A qualidade intrínseca do produto ou serviço que pode

E o atendimento que pode ser entendido como

O uso de um software com bugs não é nada agradável,

aprimorar o processo de desenvolvimento e, em

Preparação de uma política de qualidade – a gerência

O processo de software é formado pelo conjunto

Pacotes ou suítes: compõem a maioria dos programas

Discussão de um problema técnico na hora do café

Descobrir erros de função, lógica ou implementação em

Envolver de 3 a 5 pessoas na revisão (se o número de