Qualidade de Software

QUALIDADE
DE SOFTWARE
autor do original
MAYB ANDRADE
1 edio
SESES
rio de janeiro 2015
Conselho editorial
fernando fukuda, simone markenson, jeferson ferreira fagundes
Autor do original mayb andrade

Projeto editorial roberto paes
Coordenao de produo rodrigo azevedo de oliveira
Projeto grfico paulo vitor bastos
Diagramao fabrico
Reviso lingustica aderbal torres bezerra
Imagem de capa nome do autor shutterstock
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2015.
Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio
Prefcio 7
1. Viso Geral de Qualidade Software
10
Conceito de Qualidade de Software 10

Fatores de Qualidade de Software 17
Mtricas de Software 18
Revises de Software 21
2. Normas de Qualidade de Software
26
Garantia de Qualidade de Software (Software Quality Assurance SGA)

Princpios e Modelos da Norma ISO 9000
NBR ISO 9126
NBR ISO 12119
3. Modelos da Norma ISO

Norma ISO 9241 Usabilidade do Produto
Norma ISO 9241 parte -11
Norma ISO 14598 (avaliao de produto)
26
29
29
34
44
44
45
50
4. Modelos de Melhoria e Avaliao de Processo de

Software
62
Melhoria de Processo de Software
Modelos de Melhoria de Processo de Software
NBR/ISO 9000-3
NBR/ ISO 12207 - Processos de ciclo de vida do software
63
64
70
72
5. Modelos de Qualidade de Processo de Software 80

SPICE (Software Process Improvement and Capability Determination) 81
Transio para a Norma ISO/IEC 15504
87
Modelo CMMI (Capability Maturity Model) 88
Modelo Mps.Br
89
Gerncia de Riscos na Qualidade de Software
91
Prefcio
Prezado(a) aluno(a)
A qualidade tem sido um fator de diferenciao no mercado atual. A exigncia por qualidade tem aumentado em todas as reas e afetado tambm a indstria de software. Com os computadores, cada vez mais, fazendo parte da vida das
pessoas, a produo de softwares vem aumentando e tornando os clientes mais
exigentes. A grande exigncia dos clientes por melhores softwares tem obrigado os desenvolvedores a aperfeioarem o seu produto final para continuarem
competindo no mercado. Esses clientes deixaram de se preocupar apenas com
o preo e passaram a buscar um produto mais confivel e com mais qualidade.
Aps alguns anos de experincia no desenvolvimento de software, percebeu-se que existem alguns fatores de qualidade, considerados pelos clientes,
no esto relacionados especificamente s caractersticas de qualidade do produto final. Esses fatores relacionam-se mais ao processo de software, forma
como ele gerenciado e controlado.
Ao se melhorar a qualidade do processo de software, tem-se maior probabilidade de se obter um produto final mais adequado s expectativas do cliente,
no entanto, a realizao de uma melhoria do processo de software no uma
tarefa trivial. Para que o processo de software possa cumprir seus objetivos necessrio um planejamento detalhado que mostre a realidade do processo atual,
a meta que se almeja com a melhoria, a estratgia para se atingir essa meta e os
planos de ao.
Para auxiliar a melhoria do processo existem abordagens que descrevem
como a organizao pode avaliar o seu estado atual e a partir dessa avaliao
procurar melhorar o seu processo. A melhoria do processo deve ser consciente
e o grau a ser atingido deve ser bem definido.
Dentro desse contexto, nossa disciplina vem lhe oferecer os conceitos necessrios para compreender o significado da qualidade de software bem como
a forma de alcan-la.
Vamos l que o assunto atual e muito interessante!
Bom estudo !!
1
Viso Geral de
Qualidade Software
1 Viso Geral de Qualidade Software

Neste captulo definiremos o que vem a ser Qualidade de Software, veremos a qualidade pode ter diferentes interpretaes, dependendo de quem a est avaliando.
Comentaremos sobre as diferenas de qualidade de produto e de processo de software e finalizaremos com alguns fatores relacionados Qualidade de
Software.
OBJETIVOS

Compreender as diferentes vises da Qualidade de Software;
Compreender os fatores da qualidade de um software;
Entender o que so mtricas de software e;
A importncia das revises de software.
REFLEXO
Quando apareceram os primeiros computadores e depois com a evoluo dos mesmos, todos ficamos fascinados e tambm curiosos como essas mquinas podiam fazer tantas coisas
em to pouco tempo, como de repente elas comearam a fazer parte das nossas vidas, de tal
maneira que hoje no nos imaginamos sem elas, no ?
Pois bem, agora no tem mais como voltar atrs, no vivemos mais sem nossos amados computadores, que tambm no existem sem um software, no verdade? Mas para que tudo
funciona na mais perfeita ordem no basta simplesmente ter o software, esse precisa ter
qualidade! Vamos l, vamos entender o que vem a ser a Qualidade de Software!
1.1 Conceito de Qualidade de Software

Com a constante demanda gerada pela vida moderna, cada vez mais os computadores passam a integrar a rotina diria e a produo de software vem tendo
um aumento constante. A exigncia por qualidade estende-se tambm rea de
software e pode ser considerada o centro das atenes para o desenvolvimento
de software. Por exemplo, do ponto de vista dos fornecedores de software, qualidade no mais um fator de vantagem no mercado, mas uma condio necessria e pode-se dizer indispensvel para que seja possvel competir com sucesso.
10
captulo 1
Mas vamos parar e analisar, como chegamos a essa era da Qualidade de

Software?
Desde os tempos remotos, muitos problemas no desenvolvimento dos sistemas computacionais j se faziam sentir. Em 1968 o Comit de Cincias da OTAN
reuniu 50 especialistas, cientistas e profissionais da indstria de software para discutir possveis solues para o que passou a ser conhecido como a Crise do Software.
Nesse encontro se firmou o termo Engenharia de Software, e foi definida
formalmente a necessidade da aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e manuteno de
produtos de software.
Vamos relembrar algumas coisas e observar a engenharia de software atravs de uma perspectiva histrica:
Dcada de 60 e os anos que a antecedem: podem ser chamados de Era
Funcional quando aprendeu-se a usar a tecnologia da informao para
suprir as necessidades institucionais e comear a integrar o software nas
operaes dirias das instituies.
Dcada de 70: ficou conhecida como a Era do Mtodo - nessa fase, como as
organizaes de software foram caracterizadas por macios atrasos nos planos e constantes ultrapassagens dos custos planejados, a maior preocupao era planejar e controlar os projetos de software. Foi quando os modelos
de ciclo-de-vida, baseados em vrias fases, foram introduzidos e analisados
Dcada de 80: foi a era do Custo - O custo do hardware comeou a cair e a
tecnologia da informao se tornou acessvel s pessoas, no mais apenas
s instituies. A competio das indstrias tomou um rumo diferente
pois aplicaes de baixo custo puderam ser largamente implementadas.
A importncia da produtividade no desenvolvimento de software aumentou significativamente. Nessa fase, vrios modelos de custo na Engenharia de Software foram implementados e usados. Foi tambm no final dessa dcada que se reconheceu a importncia da Qualidade de Software.
Dcada de 90: Era da Qualidade. A dcada de 90 e os anos que seguem
podem, certamente, ser chamados de Era da Qualidade. Com a tecnologia do estado da arte, espera-se atender a demanda dos clientes com a
crescente exigncia de alta qualidade.
captulo 1
11
Qualidade um termo que pode ter diferentes interpretaes e para se estudar a Qualidade de Software de maneira efetiva necessrio, inicialmente,
obter um consenso em relao definio de Qualidade de Software que est
sendo abordada. Existem muitas definies de Qualidade de Software propostas na literatura, sob diferentes pontos de vistas, vejamos alguns:
Qualidade de Software a conformidade a requisitos funcionais e de
desempenho que foram explicitamente declarados, a padres de desenvolvimento claramente documentados, e a caractersticas implcitas que
so esperadas de todo software desenvolvido por profissionais (Pressman,1994).
Um produto de software apresenta qualidade dependendo do grau de
satisfao das necessidades dos clientes sob todos os aspectos do produto (Sanders, 1994).
Qualidade a totalidade de caractersticas e critrios de um produto ou
servio que exercem suas habilidades para satisfazer as necessidades declaradas ou envolvidas (ISO9126 1994).
Qualidade a totalidade das caractersticas de uma entidade, que lhe
confere a capacidade de satisfazer necessidades explcitas e implcitas
(NBR ISO 8402, 1994).
CONCEITO
Existe, ainda, uma viso de Qualidade de Software do ponto de vista gerencial, que diz que o
software que possa ser desenvolvido dentro do prazo e do oramento especificados pode ser
um software de alta qualidade. Isso demonstra que, ainda dentro da Qualidade de Software,
pode-se definir vrias vises diferentes, como tem sido para a definio da qualidade como
um termo geral.
De um modo geral, Qualidade de Software pode ser definida como:

Um conjunto de atributos de software que devem ser satisfeitos de modo
que o software atenda s necessidades do usurio (seja ele um usurio final, um
desenvolvedor ou uma organizao), onde a determinao dos atributos relevantes para cada software varia em funo:
12
captulo 1
do domnio da aplicao;
das tecnologias utilizadas;
das caractersticas especficas do projeto;
das necessidades do usurio e da organizao;
Podemos dizer ainda que a qualidade depende tambm do ponto de vista de

quem a avalia, onde usurios, desenvolvedores e organizaes podem ter pontos de necessidades diferentes:
Usurio: avalia o software sem conhecer seus aspectos internos, est apenas interessado na facilidade do uso, no desempenho, na confiabilidade
dos resultados e no preo;
Desenvolvedores: avaliam aspectos de conformidade em relao aos requisitos dos clientes e tambm aspectos internos do software;
Organizao: avalia aspectos de conformidade em relao aos requisitos
dos clientes e desenvolvedores e tambm aspectos de custo e cronograma.
1.1.1 Qualidade de Produto X Qualidade de Processo de Software

Qualidade de Software pode ser vista como um conjunto de caractersticas que
devem ser alcanadas em um determinado grau para que o produto atenda as
necessidades de seus usurios (Rocha et al.,2001). A qualidade do produto final
profundamente afetada pela qualidade do processo de desenvolvimento, portanto a qualidade deve ser uma meta a ser alcanada e aprimorada ao longo do
processo de software.
Aqui se faz importante definirmos o que vem a ser um produto de software,
assim como esclarecermos alguns pontos de um processo de software, vamos l?
1.1.2 Produto de Software
Um produto de software compreende os programas e procedimentos de computador e a documentao e dados associados, que foram projetados para serem liberados para o usurio (ISO/IEC 12207-1, 1995).
captulo 1
13
Da mesma forma como existem diversas interpretaes para qualidade de

um modo geral, tambm existem diversas interpretaes para qualidade de um
produto de software, tais como:
Boa fabricao.
Deve durar muito.
Bom desempenho.
Adaptvel s minhas necessidades especficas
Fcil de usar.
Sem defeitos, entre outros.
A especificao de Qualidade de Produto de Software deve ser mais precisa e
detalhada. A formalizao de Qualidade de Produto de Software pode ser feita
usando-se um Modelo de Qualidade de Produto de Software.
CONEXO
Para compreender um pouco mais sobre nosso assunto, veja o link: http://cbsoft2013.unb.
br/wp-content/uploads/2013/10/ST1-2.pdf, um excelente artigo para aumentar nossos
conhecimentos. Boa leitura!
Como mesmo as proposies bem sucedidas trazem dificuldades de aplicao, por causa dos muitos aspectos de qualidade oferecidos, surgiu a necessidade de um modelo padronizado. Por essa razo o comit tcnico da ISO/IEC
comeou a trabalhar para desenvolver o consenso requerido e encorajar a padronizao em nvel mundial. As primeiras tentativas de padronizao surgiram em 1978. Em 1985 foi iniciado o desenvolvimento da Norma Internacional
ISO/IEC 9126 Information Technology Software product evaluation Quality
characteristics and guidelines for thei use - publicada em 1991.
A Norma NBR 13596 uma traduo da Norma ISO/IEC 9126. Foi elaborada
pela comisso de Estudos de Qualidade de Software do Subcomit de Software
do Comit de Informtica da ABNT Associao Brasileira de Normas Tcnicas
e publicada em agosto de 1996. A norma avalia a qualidade de um produto de
software atravs de um conjunto de caractersticas. Essas caractersticas so divididas em seis grandes grupos, os quais sero apresentados detalhadamente
no captulo 2.
14
captulo 1
1.1.3 Processo de Software

Vejamos algumas definies da palavra processo:
Um processo a maneira pela qual se realiza uma operao, segundo
determinadas normas (dicionrio Aurlio)
Um processo uma seqncia de passos realizados para um dado propsito (IEEE)
O processo integra pessoas, ferramentas e procedimentos.
Processo o que as pessoas fazem, usando procedimentos, mtodos, ferramentas e equipamentos, para transformar matria prima (entrada) em
um produto (sada) que tem valor para o cliente.
Um processo de software pode ser definido como um conjunto de atividades, mtodos, prticas e transformaes que as pessoas usam para desenvolver
e manter o software e os produtos associados (por exemplo: planos de projeto,
documentos, cdigo, casos de teste e manuais de usurio) (IEEE-STD-610).
Um processo de software envolve um grande conjunto de elementos, tais
como objetivos organizacionais, polticas, pessoas, comprometimentos, ferramentas, mtodos, atividades de apoio e as tarefas da engenharia de software.
Para que o processo de software seja eficiente ele precisa ser constantemente
avaliado, medido e controlado. Quando as empresas no possuem conhecimento suficiente de todos os elementos do processo, essas atividades de avaliar, medir e controlar ficam difceis de serem realizadas, nesse caso o processo
de software passa a ser descontrolado, sem gerncia e at mesmo catico. Algumas caractersticas de processos de softwares caticos so (Pressman, 2002).
O processo improvisado (profissionais e gerentes);
O processo no rigorosamente seguido e o cumprimento do mesmo
no controlado;
O processo altamente dependente dos profissionais atuais;
A viso do progresso e da qualidade do processo baixa;
captulo 1
15
A qualidade do produto decorrente do processo comprometida em funo de prazos;

Quando so impostas datas urgentes para entrega dos produtos, freqentemente, a funcionalidade e a qualidade dos mesmos so comprometidas para atender o cronograma;
No existe nenhuma base objetiva para julgar a qualidade do produto ou
para resolver problemas de processo ou de produto, portanto, a qualidade do produto difcil de ser prevista;
As atividades ligadas melhoria da qualidade, tais como revises e testes, freqentemente so encurtadas ou eliminadas quando os projetos
ultrapassam o cronograma previsto.
J quando as coisas caminham bem e o processo controlado e gerenciado
com eficincia o processo passa a ser bom, passa a ser maduro e eficiente, gerando resultados positivos, tais como:
O processo continua a despeito de problemas inesperados (Robustez).
Rapidez na produo do sistema (Velocidade).
O processo aceito por todos os envolvidos nele (Aceitabilidade).
Os erros do processo so descobertos antes que resultem em erros no
produto (Confiabilidade).
O processo evolui para atender alteraes de necessidades organizacionais (Manutenibilidade).
O processo compreendido (usualmente atravs de documentao e de
treinamento), utilizado, vivo e ativo.
O processo bem controlado a fidelidade ao processo objeto de auditoria e de controle.
Medidas do produto e do processo so utilizadas.
Os papis e responsabilidades no processo esto claros ao longo de todo
o projeto e por toda a organizao.
16
captulo 1
A produtividade e a qualidade dos produtos de software resultantes podem ser melhoradas com o tempo atravs de ganhos consistentes na disciplina obtida pelo uso do processo de software.
Os gerentes monitoram a qualidade dos produtos de software e a satisfao do cliente.
Existe uma base quantitativa, objetiva para julgar a qualidade dos produtos e analisar problemas com o produto e o processo.
As organizaes com processo de software de alta qualidade tem esse
processo institucionalizado atravs de polticas, padres e estruturas organizacionais.
Bom pessoal, acredito que tenha ficado claro que para se alcanar os objetivos de produtividade e qualidade necessrio que o processo de software seja
eficiente, definido, gerenciado, medido e controlado
1.2 Fatores de Qualidade de Software

Existem dois tipos de Qualidade de Software: umtipodequalidadecomaqual
o usuriodoprograma interage- essa aqualidade externa. E um tipo de qualidade comaqual outros desenvolvedores interagem - essa aqualidade interna, sendo assim podemos dizer te temos os fatores de qualidade interno e os
fatores de qualidade externo (Pressman 2002).
Fatores externos ponto de vista do usurio:
Correo: caracterstica do software que realiza as tarefas como foram
definidas em sua especificao de requisitos.
Robustez: um software robusto se realiza as suas tarefas de forma correta mesmo quando submetido a condies anormais.
Extensibilidade: caracterstica de um software poder ser facilmente
adaptado a incluses e alteraes de requisitos.
Reusabilidade: caracterstica de um software que pode ser reutilizado ao
todo ou em parte por outros softwares.
captulo 1
17
Compatibilidade: facilidade de se combinar o software com outros softwares. Essa caracterstica importante porque raramente um software
construdo sem interao com outros softwares.
Eficincia: refere-se ao bom uso que o software faz dos recursos de hardware, tais como memria e processadores.
Portabilidade: a facilidade de se utilizar o software em diferentes ambientes de hardware e software.
Verificabilidade: a facilidade de se preparar rotinas para se verificar a
conformidade do software com os seus requisitos.
Integridade: uma caracterstica relacionada segurana de dados, programas e documentos. Integridade a habilidade de proteger tais componentes contra acessos no autorizados.
Facilidade de uso: tambm denominada usabilidade, a facilidade com
que o software pode ser aprendido e utilizado.
Fatores internos: ponto de vista estrutural do software. Permitem atingir os
fatores externos:
Modularidade: caracterstica de um software que constitudo por unidades denominadas mdulos.
Legibilidade
Manutenibilidade: facilidade de realizar manuteno em um software.
A forma com um software construdo permite atingir os fatores internos
de qualidade. Os fatores internos de qualidade permitem atingir os fatores externos de qualidade.
1.3 Mtricas de Software

Segundo Tom De Marco, No se pode gerenciar o que no se pode medir.
Roger Pressmas, 2002, considera que Se voc no sabe para onde voc quer ir,
qualquer caminho voc pode seguir. Se voc no sabe onde voc est, um mapa
no vai ajudar!.
18
captulo 1
Ainda, segundo Pressman, uma mtrica a medio de um atributo (propriedades ou caractersticas ) de uma determinada entidade (produto, processo
ou recursos). Exemplos:
Tamanho do produto de software (ex: Nmero de Linhas de cdigo)
Nmero de pessoas necessrias para implementar um caso de uso
Nmero de defeitos encontrados por fase de desenvolvimento
Esforo para a realizao de uma tarefa
Tempo para a realizao de uma tarefa
Custo para a realizao de uma tarefa
Grau de satisfao do cliente (ex: adequao do produto ao propsito,
conformidade do produto com a especificao).
Mas, acho que aqui seria interessante um questionamento que j ouvi muito de meus alunos: Por que devemos medir o software? realmente importante
ou seria uma perda de tempo?
Veremos a seguir algumas vantagens de realizarmos essas medies no
software:
Entender e aperfeioar o processo de desenvolvimento
Melhorar a gerncia de projetos e o relacionamento com clientes
Reduzir frustraes e presses de cronograma
Gerenciar contratos de software
Indicar a qualidade de um produto de software
Avaliar a produtividade do processo
Avaliar os benefcios (em termos de produtividade e qualidade) de novos
mtodos e ferramentas de engenharia de software
Avaliar retorno de investimento
Identificar as melhores prticas de desenvolvimento de software
captulo 1
19
Embasar solicitaes de novas ferramentas e treinamento

Avaliar o impacto da variao de um ou mais atributos do produto ou do
processo na qualidade e/ou produtividade
Formar uma baseline para estimativas
Melhorar a exatido das estimativas
Oferecer dados qualitativos e quantitativos ao gerenciamento de desenvolvimento de software, de forma a realizar melhorias em todo o processo de desenvolvimento de software
Para realizarmos as medies precisamos fazer uso de alguma ou algumas
mtricas, a qual deve ser vlida ( quantifica o que queremos medir), confivel
(produz os mesmos resultados dadas as mesmas condies) e prtica (barata,
fcil de computar e fcil de interpretar).
1.3.1 Categorizao de mtricas:
Mtricas diretas (fundamentais ou bsicas): medida realizada em termos
de atributos observados (usualmente determinada pela contagem). Ex.:
custo, esforo, no. linhas de cdigo, capacidade de memria, no. pginas, no. diagramas, etc.
Mtricas indiretas (derivadas): medidas obtidas a partir de outras mtricas.
Ex.: complexidade, eficincia, confiabilidade, facilidade de manuteno.
Mtricas orientadas a tamanho: so medidas diretas do tamanho dos
artefatos de software associados ao processo por meio do qual o software
desenvolvido. Ex.: esforo, custo, no. KLOC, no. pginas de documentao, no. Erros.
Mtricas orientadas por funo: consiste em um mtodo para medio
de software do ponto de vista do usurio, determinando de forma consistente o tamanho e a complexidade de um software.
Mtricas de produtividade: concentram-se na sada do processo de engenharia de software. Ex.: no. de casos de uso/iterao.
20
captulo 1
LEITURA
Uma boa leitura para aguar nossa curisosidade com relao definio de mtricas de
software seria o material disponvel no link a seguir, aproveitem! http://www.portaisgoverno.
pe.gov.br/web/metricas-de-software/definicoes
Mtricas de qualidade: Oferecem uma indicao de quanto o software

se adequa s exigncias implcitas e explcitas do cliente.Ex.: erros/fase .
Mtricas tcnicas: concentram-se nas caractersticas do software e no
no processo por meio do qual o software foi desenvolvido. Ex.: complexidade lgica e grau de manutenibilidade
1.4 Revises de Software

De acordo com SEI CMM (3-1.5, 1988), um processo de reviso pode ser definido como uma avaliao crtica de um objeto (...) assim walkthroughs, inspees
e auditorias podem ser visualizados como formas de processos de reviso.
As revises so mtodos de validao de qualidade de um processo ou produto amplamente usado pela equipe tcnica do projeto. So consideradas
como verdadeiros filtros de erros e inconsistncias no processo de desenvolvimento de software.
A atividade de reviso comeou como uma ferramenta de controle gerencial
Reviso de progresso, onde o progresso no pode ser avaliado simplesmente contando-se o nmero de tarefas finalizadas.
Era preciso estabelecer um meio de avaliar tambm a qualidade do trabalho
executado, surgiram ento as revises que avaliam aspectos tcnicos do produto.
Qualquer produto pode ser submetido a uma reviso aplicada desde as primeiras fases do ciclo de vida. As revises devem ser fomais e tambem informais.
Deve sempre ser realizado um planejamento para a realizao das revises
de software. Cabe ao engenheiro de software planejar:
o que deve ser revisado
quais os resultados esperados
quem deve fazer a reviso,
determinar checkpoints dentro do ciclo de vida onde a reviso deve ser
aplicada,
determinar resultados esperados.
captulo 1
21
Algumas informaes importantes no planejamento das revises so:

quem participa?
qual informao requerida antes da reviso?
quais pr-condies que devem ser satisfeitas antes que a reviso possa
ser conduzida?
Como Organizar?
Gerar checklists ou outra indicao do que deve ser coberto na reviso;
Determinar as condies de trmino ou critrios que devem ser satisfeitos para que a reviso termine;
Gerar registros e documentos que devem ser produzidos.
As revises so o principal mecanismo para avaliar o progresso do desenvolvimento de maneira confivel, trazendo vrios benefcios para o bom desenvolvimento do software, tais como:
As revises trazem luz as capacidades de cada indivduo envolvido no
desenvolvimento,
revises so capazes de revelar lotes ou classes de erros de uma s vez;
revises proporcionam retorno j nas primeiras fases, prevenindo que
erros mais srios surjam;
revises treinam e educam os participantes e
tm significante efeito positivo na competncia dos desenvolvedores.
Quando se realiza revises e correes desde o incio do ciclo de desenvolvimento de software, um dos grandes ganhos com relao aos custos. Vejamos
o custo da remoo de erros:
Atividades de projeto so responsveis por 50 a 65% dos erros, a reviso pode
revelar at 75% desses erros e, revelar erros cedo diminui o custo de validao
e correo.
Fase de projeto: custo 1
Fase anterior ao teste: custo 6.5
Fase de teste: custo 15
Fase de manuteno: custo 60 a 100
Uma m reviso pode ser pior do que nenhuma reviso , por isso e importante considerar as atividades a seguir:
Determine uma agenda (e mantenha-a)
22
captulo 1
Limite os debates
Levante as reas problemticas no tente resolver todos os problemas
Tome notas
Revise o produto, no o produtor
Limite o nmero de participantes e insista na preparao;
Prepare um checklist, de acordo com o produto a ser revisado;
Reserve recursos do projeto para revises;
Promova treinamento para os revisores;
Revise suas antigas revises
Para fixarmos os conhecimentos apresentados nesse captulo, a seguir, seguem algumas questes a serem respondidas.
ATIVIDADE
1. Defina Qualidade de Software.
2. Defina processo de software e comente as caractersticas de um bom processo de
software.
3. Comente sobre a categorizao das mtricas.
4. Quando falamos de revises de software, o que importante que o engenheiro considere no planejamento?
REFLEXO
Neste captulo pudemos conhecer um pouco mais sobre o assunto Qualidade de Software,
entendendo a sua importncia.
A Qualidade de Software pode ser subdividida em qualidade de produto e qualidade de
processo, sendo as duas extremamente importantes e relacionadas.
Para podermos dizer que um software tem qualidade necessrio que o mesmo seja
avaliado, o que pode ser realizado com o auxlio das mtricas e constantes revises.
captulo 1
23
LEITURA
Introduo a Qualidade de Software http://www.ufpa.br/srbo/Disciplinas/TecnologiaProcessosSoftware/Aulas/Qualidade.pdf
Levantamento de mtricas de avaliao de projetos de software livre
http://ccsl.ime.usp.br/files/relatorioPauloMeirelles_final.pdf
REFERNCIAS BIBLIOGRFICAS
Mtricas e Estimativas de Software O incio de um rally de regularidade. Url: http://
www.apinfo.com/artigo44.htm
PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: MacGraw Hill, 2002.
ROCHA, ANA REGINA CAVALCANTI; MALDONADO, JOS CARLOS; WEBER, KIVAL CHAVES. Qualidade de Software Teoria e Prtica. 1 edio. So Paulo: Prentice Hall, 2001.
SANCHES, ROSELY. Material Didtico: Qualidade de Software. ICMC-USP, 2003.
SANCHES, ROSELY; FABBRI, SANDRA PINTO; MALDONADO, JOS CARLOS. Qualidade de Software: da engenharia de software aos modelos de qualidade. VI Escola Regional
de Informtica, SBC, 2003.
SOMERVILLE, IAN. Engenharia de Software. 6 edio. So Paulo: Addison Wesley,
2003.
NO PRXIMO CAPTULO
Dando continuidade ao nosso estudo, no prximo captulo comentaremos sobre a garantia
da Qualidade de Software (SQA) e discutiremos sobre as normas relacionadas a Qualidade
de Software ISO/NBR 9126 e ISO/NBR 12119.
24
captulo 1
2
Normas de
Qualidade de
Software
2 Normas de Qualidade de Software

No captulo anterior vimos os conceitos de qualidade de software e percebemos
que o mesmo extremamente importante, visto que, com a grande demanda
de software, os clientes encontram-se cada vez mais exigentes e o mercado cada
dia mais competitivo.
Apesar da necessidade da qualidade nos softwares, garantir isso nem sempre uma tarefa fcil para as empresas desenvolvedoras de software, dentro
desse contexto, vamos analisar a atividade SQA garantia de qualidade de software e as normas de qualidade de software ISO/NBR 9126 e ISO/NBR 12119..
OBJETIVOS

Descrever os passos necessrios para realizar a garantia de qualidade de software estatstica.
Discorrer sobre a diferena entre confiabilidade de software e segurana de software.
Abordar os princpios da ISO 9000 e suas vertentes.
Discorrer sobre os modelos ISO 9000 para sistemas de garantia da qualidade.
REFLEXO
Voc se lembra da definio de qualidade de software que vimos no captulo anterior?
Na verdade vimos mais de uma!
A qualidade de software possui vrias definies, porm todas elas possuem em comum a
grande preocupao com o usurio final.
Pensando no usurio final foi que surgiram normas preocupadas em avaliar produtos e pacotes de software, vamos conhec-las nesse captulo!
2.1 Garantia de Qualidade de Software (Software Quality

Assurance SGA)
Segundo Pressman (2002), Software Quality Assurance um padro sistemtico
e planejado de aes que so exigidas para garantir a qualidade de software.
Essas aes englobam:
26
captulo 2
5. Aplicao de Mtodos Tcnicos: ajudam o analista a conseguir uma especificao de elevada qualidade e o projetista a desenvolver um projeto de elevada qualidade.
6. Realizao de Revises Tcnicas Formais: para avaliar a qualidade da
especificao e do projeto.
7. Atividades de Teste de Software: para ajudar a garantir uma deteco de
erros efetiva.
8. Aplicao de Padres e Procedimentos Formais no processo de engenharia de software.
9. Processo de Controle de Mudanas: atividade que faz parte do gerenciamento de configurao de software.
10. Mecanismos de Medio: para ser possvel rastrear a qualidade de software
11. Anotao e Manuteno de Registros: procedimentos para a coleta e
disseminao de informaes de garantia de qualidade de software.
2.1.1 Abordagens Formais Para a Garantia de Qualidade de Software (SGA)

As principais abordagens so comentadas a seguir:
1. Prova de Corretitude se o modelo dos requisitos (especificao) e a linguagem de programao podem ser representadas de uma maneira rigorosa, deveria ser possvel aplicar provas matemticas de corretitude para
demonstrar que o programa atende exatamente suas especificaes.
2. Garantia Estatstica de Qualidade implica coletar e categorizar informaes sobre os defeitos do software; tentar descobrir a causa de cada
defeito; isolar 20% das causas (princpio de Pareto); corrigir os problemas que causaram os defeitos
3. Proesso Sala Limpa (Cleanroom) combina a prova de corretitude e a
Garantia Estatstica de Qualidade para melhorar a qualidade do produto software
captulo 2
27
A necessidade de qualidade de software reconhecida por praticamente todos os gerentes e profissionais da rea, porm muito poucos esto interessados em estabelecer
funes de Garantia de Qualidade de Software Formais. Alguma razes para essa aparente contradio:
1. os gerentes relutam em incorrer em custos extras logo de cara
2.
os profissionais acham que esto fazendo absolutamente tudo o que precisa ser feito
3. ningum sabe onde colocar essa funo organizacionalmente

4. todos querem evitar a burocracia que, segundo entendem, a Garantia de Qualidade
de Software introduzir no processo de engenharia de software.
Alguns aspectos positivos da garantia de qualidade de software que podemos mencionar so:
o software ter menos defeitos latentes resultando em reduo do esforo e do tempo gasto durante as atividades de teste e manuteno
a maior confiabilidade resultar em maior satisfao do cliente
os custos de manuteno podem ser reduzidos
o custo do ciclo de vida global do software reduzido
Pressman (2004), destaca alguns passos necessrios para realizar a SQA estatstica e criar um processo adaptativo de engenharia de software no qual so feitas
modificaes para aprimorar os elementos do processo que promovem erro:
Coletar e categorizar os defeitos de software encontrados.
Rastrear o defeito at sua causa subjacente.
Considerar que 20% do cdigo tm 80% dos defeitos.
Corrigir os problemas que causaram os defeitos.
CONEXO
Para sabermos um pouco mais sobre a garantia de qualidade de software seria interessante
voc ler o artigo: A importncia do processo de garantia de qualidade, disponvel em:
http://www.univicosa.com.br/arquivos_internos/artigos/
AImportanciadoProcessodeGarantiadaQualidadedeSoftware.pdf
28
captulo 2
2.2 Princpios e Modelos da Norma ISO 9000

Conforme j comentamos anteriormente, para se alcanar os objetivos de produtividade e qualidade necessrio que o software seja eficiente, definido, gerenciado, medido e controlado, o que nem sempre uma tarefa fcil.
Para auxiliar nessas tarefas existem norma e modelos padres que possuem
como principal objetivo a obteno da qualidade. O conjunto de Normas da ISO
9000 um exemplo disso.
A seguir comentaremos sobre duas normas de qualidade, sendo uma voltada para produto de software ( voc se lembra o que um produto de software,
no ?) e outra voltada para a avaliao de pacotes de software, ou software de
prateleiras, como alguns preferem chamar.
2.3 NBR ISO 9126

Como j comentamos anteriormente, a qualidade um conceito muito importante para o software. Durante muito tempo, foram propostos modelos de
qualidade, mas a confiabilidade era o nico meio de se avaliar a qualidade de
um software. Surgiu ento a necessidade de um modelo padronizado. Por essa
razo, o comit tcnico da ISO (International Organization for Standardization)
e IEC (International Electrotechnical Comission), iniciaram em 1985 o desenvolvimento da Norma Internacional ISO/IEC 9126, que estabelece caractersticas
baseadas no conceito de qualidade para um produto de software.
A Norma ISO/IEC 9126:1991 ou NBR 13596:1996 apresenta a padronizao mundial do Software como Produto considerado como um Software de
Qualidade.
Esta norma fornece um modelo de propsito geral o qual define 6 categorias de caractersticas de qualidade de software que so, por sua vez, divididas
em subcaractersticas. As subcaractersticas podem ser avaliadas por um conjunto de mtricas.
A ISO/IEC 9126 e foi publicada em 1991, sendo uma das mais antigas da
rea de qualidade de software e j possui sua traduo para o Brasil, publicada
em agosto de 1996 como NBR 13596. Estas normas listam o conjunto de caractersticas que devem ser verificadas em um software para que ele seja considerado um software de qualidade. So seis grandes grupos de caractersticas,
cada um dividido em algumas subcaractersticas, os quais so descritos abaixo:
captulo 2
29
Qualidade de produto
de software
Funcionalidade
Conabilidade
Usabilidade
Adequao
Acurcia
Interoperabilidade
Segurana de
acesso
Conformidade
Maturidade
Tolerncia a falhas
Recuperabilidade
Conformidade
Inteligibilidade
Apreensibilidade
Operacionalidade
Atratividade
Conformidade
Qualidade de produto
de software
Ecincia
Manutenibilidade
Portabilidade
Comportamento em
relao ao tempo
Comportamento em
relao aos recursos
Conformidade
Analisabilidade
Modicabilidade
Estabilidade
testabilidade
Conformidade
Adaptabilidade
Capacidade para
ser instalado
Co-existncia
Capacidade para
substituir
Conformidade
Segundo a ISO/IEC 9126-1, as definies das caractersticas e subcaractersticas de qualidade interna e externa so:
Funcionalidade: capacidade do produto de software de prover funes que
atendam s necessidades explcitas e implcitas, quando o software estiver sendo utilizado sob condies especficas.
Adequao: capacidade do produto de software de prover um conjunto
apropriado de funes para tarefas e objetivos do usurio especificados.
Acurcia: capacidade do produto de software de prover, com o grau de preciso necessrio, resultados ou efeitos corretos ou conforme acordados.
30
captulo 2
Interoperabilidade: capacidade do produto de software de interagir com

um ou mais sistemas especificados.
Segurana de Acesso: capacidade do produto de software de proteger informaes e dados, de forma que pessoas ou sistemas no autorizados
no possam l-los nem modific-los e que no seja negado o acesso s
pessoas ou sistemas autorizados.
Conformidade: capacidade do produto de software de estar de acordo
com normas, convenes ou regulamentaes previstas em leis e prescries similares relacionadas funcionalidade.
Confiabilidade: capacidade do produto de software de manter um nvel de desempenho especificado, quando usado em condies especficas.
Maturidade: capacidade do produto de software de evitar falhas decorrentes de defeitos no software.
Tolerncia a Falhas: capacidade do produto de manter um nvel de desempenho especificado em casos de defeitos no software ou de violao
de sua interface especificada.
Recuperabilidade: capacidade do produto de software de restabelecer
seu nvel de desempenho especificado e recuperar os dados diretamente
afetados no caso de uma falha.
Conformidade: capacidade do produto de software de estar de acordo com
normas, convenes ou regulamentaes relacionadas confiabilidade.
Usabilidade: capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usurio, quando usado sob condies especficas.
Inteligibilidade: capacidade do produto de software de possibilitar ao
usurio compreender se o software apropriado e como ele pode ser usado para tarefas e condies de uso especficas.
Apreensibilidade: capacidade do produto de software de possibilitar ao
usurio aprender sua aplicao.
captulo 2
31
Operacionalidade: capacidade do produto de software de possibilitar ao

usurio oper-lo e control-lo.
Atratividade: capacidade do produto de software de ser atraente ao usurio.
com normas, convenes, guias de estilo ou regulamentaes relacionadas usabilidade.
Eficincia: capacidade do produto de software de apresentar desempenho apropriado, relativo quantidade de recursos usados, sob condies especficas.
Comportamento em relao ao tempo: capacidade do produto de software de fornecer tempos de resposta e de processamento, alm de taxas
de transferncia, apropriados, quando o software executa suas funes,
sob condies estabelecidas.
Comportamento em relao aos recursos: capacidade do produto de software usar tipos e quantidades apropriados de recursos, quando o software executa suas funes, sob condies estabelecidas.
com normas e convenes relacionadas eficincia.
Manutenibilidade: capacidade do produto de software ser modificado. As modificaes podem incluir correes, melhorias ou adaptaes do software devido a mudanas no ambiente e nos seus requisitos ou especificaes funcionais.
Analisabilidade: capacidade do produto de software de permitir o diagnstico de deficincias ou causas de falhas no software, ou a identificao de partes a serem modificadas.
Modificabilidade: capacidade do produto de software que uma modificao especifica seja implementada.
Estabilidade: capacidade do produto de software de evitar efeitos inesperados decorrentes de modificaes no software.
Testabilidade: capacidade do produto de software de permitir que o software, quando modificado, seja validado.
32
captulo 2

com normas ou convenes relacionadas manutenibilidade.
Portabilidade: capacidade do produto de software de ser transferido de
um ambiente para outro.
Adaptabilidade: capacidade do produto de software de ser adaptado
para diferentes ambientes especificados, sem necessidade de aplicao
de outras aes ou meios alm daqueles fornecidos para essa finalidade
pelo software considerado.
Capacidade de ser instalado: capacidade do produto de software ser instalado em um ambiente especificado.
Coexistncia: capacidade do produto de software de coexistir com outros
produtos de software independentes, em um ambiente comum, compartilhando recursos comuns.
Capacidade para substituir: capacidade do produto de software de ser
usado em substituio a outro produto de software especificado, com o
mesmo propsito e no mesmo ambiente.
com normas ou convenes relacionadas portabilidade.
Na norma cada caracterstica refinada em um conjunto de subcaractersticas

e cada subcaracterstica avaliada por um conjunto de mtricas. A norma no
fornece mtricas e nem mtodos para medio, pontuao ou julgamento.
Cada organizao pode estabelecer seus prprios modelos de processo
de avaliao e mtodos para a criao e validao de mtricas relacionadas com as caractersticas.
Tambm necessrio estabelecer nveis de pontuao e critrios especficos para a organizao ou para a aplicao.
captulo 2
33
2.4 NBR ISO 12119

A Norma NBR 12119 foi publicada em 1996 com o objetivo de fornecer subsdios para a avaliao de pacotes de software.
O escopo da norma NBR 12119 refere-se a pacotes de software, na forma
oferecida no mercado, e no aos processos de desenvolvimento e fornecimento
de software.
Vamos definir o que considerado um pacote de software:
Pacote de Software: trata-se de um produto de software que envolve um conjunto completo e documentado de programas fornecidos a diversos usurios
para uma aplicao ou funo genrica.
Tambm conhecido como software de prateleira.
Um Pacote de Software envolve todos os componentes do produto disponveis aos usurios, tais como documentao, manual de instrues e guia para
instalao.
Exemplos:
Processadores de Texto
Planilhas Eletrnicas
Gerenciadores de Banco de Dados
Software Grficos
Programas para Funes Tcnicas ou Cientficas
Programas Utilitrios
Os usurios dessa norma so normalmente fornecedores, orgos de certificao, laboratrios de teste, auditores e compradores/usurios
LEITURA
Como vocs esto podendo perceber, essa norma bastante extensa.
Para ajud-los no entendimento da mesma seria interessante a leitura de uma artigo que
apresenta um estudo de caso dessa norma.
O artigo - Avaliao da Qualidade de Um Pacote de Software Utilizando a
Norma ISO/IEC 12119: Um Estudo de Caso encontra-se disponvel em:
file:///C:/Users/Mayb/Downloads/exemplo-avaliacaopacoteuml.pdf
34
captulo 2
A norma de avaliao de pacote de software NBR ISO 12119 faz a avaliao

do pacote de software como um todo, ou seja, deve ser avaliado a parte externa
da caixa do pacote de software e tambm a parte interna que nesse caso seria
o software em si. A avaliao externa tambm de supra importncia, uma vez
que na caixa do software deve conter todas as informaes que o cliente necessita saber antes de executar a compra do software.
A norma dividida em duas partes:
Requisitos de Qualidade, onde apresenta a descrio do produto, manual
do usurio e programas e dados (que o software propriamente dito) e,
Instrues para teste, onde apresenta as principais atividades de teste a
serem realizadas, como deve ser feito o registro destes testes e como deve
ser elaborado o relatrio final dos testes.
A seguir, apresentamos detalhadamente cada uma das etapas da Norma

NBR ISO 12119.
Requisitos de qualidade:
Descrio do Produto: Documento expondo as propriedades de um pacote de software, com o principal objetivo de auxiliar os potenciais compradores na avaliao da adequao do produto antes de sua aquisio.
A descrio do produto fornece informaes sobre a documentao do
usurio, programas e, se existirem, sobre os dados.
A descrio do produto inclui as principais propriedades do pacote e um
documento disponvel ao usurio, independente da aquisio do produto.
A descrio do produto dividida em: Requisitos gerais, identificaes e
indicaes, e declaraes sobre as caractersticas de funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade.
importante ressaltar aqui que a avaliao sobre essas caractersticas
feita com base no contedo externo da caixa do pacote do software,
quando o cliente ainda no comprou o software. Vamos detalhar com
mais cuidado cada uma das partes da Descrio do produto:
captulo 2
35
Requisitos gerais
A descrio deve ser inteligvel, completa, bem organizada e bem apresentada
para auxiliar os compradores em potencial na avaliao da adequao do produto s suas necessidades, antes de compr-lo.
Deve ser livre de inconsistncias internas e interessante que cada termo tenha
um nico significado.
Identificaes e Indicaes
O documento de descrio de produto deve possuir uma nica identificao, essa
indicao do produto deve ter no mnimo o nome do produto e uma verso ou data.
A identificao do fornecedor deve conter o nome e o endereo de, no mnimo,
um fornecedor.
As tarefas que podem ser realizadas utilizando o produto devem ser identificadas. A descrio do produto pode fazer referncia aos documentos de requisitos com os quais o produto est em conformidade. Nesse caso as edies relevantes devem ser identificadas.
Os requisitos de hardware e software para colocar o produto em uso devem ser
especificados, incluindo nomes de fabricantes e identificao do tipo de todos
os componentes. Se a descrio do produto faz referncias a interfaces com outros produtos, as interfaces ou produtos devem ser identificados.
Todo os itens a serem entregues (componentes fsico do produto) devem ser
identificados, incluindo todos os documentos impressos e todos os meios de
armazenamento de dados. Deve ser declarado se a instalao do produto pode
ou no ser conduzida pelo usurio.
Deve ser declarado se o suporte para operao do produto oferecido ou no.
Deve ser declarado se a manuteno oferecida ou no. Em caso afirmativo
deve ser declarado especificamente o que includo
Declaraes sobre Funcionalidade
A descrio do produto deve fornecer uma viso geral das funes disponveis
para o usurio do produto, os dados necessrios e as facilidades oferecidas.
Nem toda funo disponvel para o usurio necessita ser mencionada, e nem
todos os detalhes de como uma funo chamada necessitam ser descritos.
36
captulo 2
Declaraes sobre Confiabilidade

A descrio do produto deve incluir informaes sobre procedimentos para
preservao de dados. Uma declarao do tipo: possvel fazer backup atravs
de funes do sistema operacional suficiente na descrio do produto.
Declaraes sobre Confiabilidade
Convm que propriedades adicionais do produto sejam descritas para assegurar
sua capacidade funcional. Exemplo: verificar se a entrada aceitvel; proteger
contra conseqncias danosas decorrentes de erro de usurio; recuperar erro.
Declaraes sobre Usabilidade
Deve ser especificado o tipo de interface com o usurio, como por exemplo, linha de comando, menu, janelas, teclas de funo e funo de auxlio. Deve ser
descrito o conhecimento especfico requerido para a aplicao do produto.
Se a proteo tcnica contra infraes a direitos autorais pode dificultar a usabilidade, ento essa proteo deve ser declarada.
Exemplos: proteo tcnica contra cpias, datas programadas de expirao de
uso, lembretes interativos para pagamento por cpia.
A descrio do produto deve incluir dados sobre a eficincia de uso e satisfao
de usurio.
Declaraes sobre Eficincia
Na descrio do produto podem ser includos dados sobre o comportamento
do produto em relao ao tempo, tais como tempo de resposta para uma dada
funo sob condies estabelecidas. Por exemplo, a configurao do sistema
Declaraes sobre Manutenibilidade
A descrio do produto pode conter declaraes sobre a manutenibilidade do
produto.
captulo 2
37
Declaraes sobre Portabilidade

A descrio do produto pode conter declaraes sobre a portabilidade do produto.
Manual do usurio: um conjunto completo de documentos, disponvel na forma impressa ou no, que fornecido para a utilizao de um produto, sendo
tambm uma parte integrante do produto. Deve incluir todos os dados necessrios para a instalao, para o uso da aplicao e para a manuteno do software
produto. Deve-se observar o manual do usurio com relao completitude,
correo, consistncia, inteligibilidade, apresentao e organizao:
Completitude: O manual deve conter todas as informaes necessrias para o
uso do produto, tais como estabelecer todas as funes do pacote e procedimentos de instalao.
Correo: A informao apresentada no manual deve estar correta e sem ambigidade.
Consistncia: Deve haver plena coerncia entre a documentao no manual e a
descrio do produto. Cada termo deve ter um nico significado.
Inteligibilidade: A documentao deve ser compreensvel pela classe de usurios que desenvolve atividades com o produto, utilizando termos apropriados,
exibies grficas e explicaes detalhadas.
Apresentao e Organizao: O manual deve ser apresentado de uma forma que
facilite uma viso geral de ndices e tabelas de contedo. Se o documento no
est na forma impressa, deve haver indicao de como efetuar a impresso.
ATENO
importante ressaltar que ass caractersticas de Funcionalidade, Confiabilidade e Usabilidade
so destacadas e devem ser verificadas atravs do uso do produto. No h requisitos especficos para os aspectos de Eficincia, Manutenibilidade e Portabilidade, porm se algum desses
requisitos estiver declarado na documentao do pacote, eles devem estar em conformidade.
38
captulo 2
Programas e Dados: so os requisitos de programas e dados que devem estar

descritos, caso existam, para o funcionamento do produto. Os requisitos de
qualidade para Programas e Dados utilizam as mesmas definies das caractersticas de qualidade da norma ISO/IEC 9126.
Funcionalidade: Devem ser verificados os procedimentos para instalao do
produto; a presena de todas as funes mencionadas; a execuo correta dessas funes; a ausncia de contradies entre a descrio do produto e a documentao do usurio.
Confiabilidade: O usurio deve manter o controle do produto, sem corromper
ou perder dados, mesmo que a capacidade declarada seja explorada at os limites ou fora deles, se uma entrada incorreta for efetuada, ou ainda se instrues
explcitas na documentao forem violadas.
Usabilidade: A comunicao entre o programa e o usurio deve ser de fcil entendimento, atravs das entradas de dados, mensagens e apresentao dos resultados, utilizando um vocabulrio apropriado, representaes grficas e funes de auxlio (help), entre outras
Usabilidade: O programa tambm deve proporcionar apresentao e organizao que facilitem uma viso geral das informaes, alm de procedimentos
operacionais que o auxiliem, por exemplo, a reverso de uma funo executada.
Vamos agora analisar a segunda parte da Norma, a parte que se refere s
Instrues para teste. Ns j comentamos no incio desse tpico, mas como a
estrutura dessa norma bastante extensa, vale a pena relembrar que a parte da
Norma de Instrues para testes dividida em: pr-requisitos de teste, atividades de teste, registro de teste e relatrio de teste:
Os pr-requisitos de teste so:
Presena de itens de produto,
Presena do sistema necessrio e,
Treinamento (se mencionado na descrio do produto).
captulo 2
39
As atividades de teste consistem em testar se esto de acordo com os requisitos de qualidade:

Descrio do produto
Documentao do usurio
Programas e dados
Os registros de teste devem conter informaes suficientes para permitir a
repetio do teste:
plano de teste
casos de teste
registrar resultados (falhas/sucessos)
identificar pessoas envolvidas
O Relatrio de testes deve abordar:
1. Produto
2. Hw/Sw utilizado no teste
3. Documentos usados
4. Resultados dos testes (descries, documentao, programas e dados)
5. Lista de no conformidades dos requisitos
6. Lista de no conformidade de recomendaes
7. Data do trmino do teste
Para fixarmos melhor os conhecimentos adquiridos at aqui, seguem abaixo algumas questes para serem refletidas.
ATIVIDADE
1. Comente algumas vantagens da realizao da garantia de qualidade de software.
2. Explique as subcaractersticas da caracterstica funcionalidade da norma ISO 9126.
3. O que um pacote de software? D alguns exemplos.
40
captulo 2
4. Quais so os pr-requisitos de testes da norma ISO 12119?

5. O que deve ser testado de acordo com a norma ISO 12119?
REFLEXO
O esforo para a elaborao conjunto de normas do Modelo ISO 9000 foi uma grande
colaborao para o auxilio na obteno da qualidade.
As normas vistas nesse captulo (ISO 9126 para avaliao de produto de software e a
ISO 12119 para avaliao de pacote de software). so amplamente reconhecidas e, cada vez
mais utilizadas pelas empresas.
Voc, como profissional da rea de informtica, muito provavelmente ir se deparar cem
seu ambiente de trabalho com termos e assuntos abordados por essas normas. Espero que
os esclarecimentos desse captulo 2 sejam teis na sua vida profissional!
LEITURA
Qualidade de software: viso geral
file:///C:/Users/Mayb/Downloads/Aula03_QualidadeSoftware.pdf
Estudo da garantia da qualidade de software utilizando a metodologia de desenvolvimento de
sistemas criada por uma instituio financeira
http://www.fatecsp.br/dti/tcc/tcc0034.pdf
Um modelo para avaliao de produtos de software
http://www.cin.ufpe.br/hermano/laps/download/laps-um-modelo-para-avaliacao-de-produtos-de-software.pdf
captulo 2
41
CARPINETTI, Luiz Cesar Ribeiro, et al. Gesto da Qualidade ISO 9001:2008 Princpios
e Requisitos. Editora Atlas. 3ed 2010.
ISO/IEC 9126. International Standard. Information Technology. Software Product
Evaluation. Quality characteristics and guidelines for their use. Geneve, 1991.
ISO/IEC 12119. International Standard. Information Technology Software Packages
Quality Requirements and testing. 1994.
NBR ISO/IEC 9126-1: Engenharia de Software Qualidade de produto Parte 1:
Modelo de qualidade. Rio de Janeiro: ABNT, 2003.
2003.
NO PRXIMO CAPTULO
Dando continuidade ao nosso estudo das normas de qualidade de software, no prximo captulo estaremos analisando a Norma ISO Norma ISO 9241, que diz respeito da Usabilidade
do Produto e a Norma ISO 14598 que trata da avaliao do produto de Software.
42
captulo 2
3
Modelos da
Norma ISO
3 Modelos da Norma ISO

A qualidade de software pode ser avaliada por diferentes vises, ou seja, pode
ser avaliada do ponto de vista do usurio, do desenvolvedor e tambm da empresa que o comercializa.
Independente da viso, todos concordam que a usabilidade de um software
um fator extremamente importante, um software difcil de usar dificilmente
ser considerado com qualidade por nenhuma das vises citadas acima.
Nesse captulo estaremos dando nfase para a ISO 9241-11 a qual comenta
os benefcios de se medir a usabilidade de um produto de software
OBJETIVOS

Entender a norma ISO/IEC 9241 com foco na parte que destaca as orientaes para
usabilidade de software.
Entender o processo de avaliao de produto de software segundo a norma ISO/IEC

14598.
REFLEXO
Comentamos no captulo anterior sobre a qualidade de produto de software e, falando desse
assunto, vimos que a usabilidade uma caracterstica extremamente importante para que um
software tenha qualidade.
Ningum fica satisfeito com um software o qual no consegue usar, o qual possui dificuldades de uso. Devido a sua grande importncia, a caracterstica usabilidade tratada na Norma
ISO 9241-11, a qual veremos a seguir.
3.1 Norma ISO 9241 Usabilidade do Produto

A grande quantidade de computadores que fazem parte do nosso cotidiano no
possuem muita razo de existirem se no forem para nos auxiliar, para tornar
nossa vida mais fcil, no verdade?
De nada nos serve um software se tivermos grandes dificuldades de us-lo,
se tivermos grandes dificuldades de oper-lo e tirarmos proveito dele em sua
aplicao.
44
captulo 3
Desta forma, a ISO/IEC 9241-11 esclarece os benefcios de medir usabilidade em termos de desempenho e satisfao do usurio, a usabilidade dos
computadores depende do contexto de uso e afirma que o nvel de usabilidade
alcanado depender das circunstncias especficas nas quais o produto usado (NBR 9241-11, 1998).
Na avaliao de usabilidade de sistemas interativos, o padro internacional
mais comum a norma ISO 9241. Ela considera mais o ponto de vista do usurio e seu contexto de uso do que as caractersticas ergonmicas do produto.
A ISO/IEC 9241 dividida em 14 partes, a saber:
Parte 1: Introduo Geral
Parte 2: Orientaes sobre requisitos da tarefa
Parte 3: Requisitos para apresentao visual
Parte 4: Requisitos para teclado
Parte 5: Requisitos posturais e de layout para posto de trabalho
Parte 6: Requisitos para ambiente
Parte 7: Requisitos para monitores quanto reflexo
Parte 8: Requisitos para apresentao de cores
Parte 9: Requisitos para outros dispositivos de entrada que no o teclado
Parte 10: Princpios de dilogo
Parte 11: Orientaes sobre usabilidade
Parte 12: Apresentao da informao
Parte 13: Orientaes ao usurio
Parte 14: Dilogos por menu
CONEXO
Um contexto interessante da usabilidade com relao web. Veja isso no artigo Teste
de usabilidade no website da UniversidadeFederal do Maranho disponvel em http://www.
academia.edu/2064036/Teste_de_usabilidade_no_website_da_Universidade_Federal_do_
Maranh%C3%A3o
3.2 Norma ISO 9241 parte -11

A parte 11 (1998) desta norma redefine usabilidade como a capacidade de um
produto ser usado por usurios especficos para atingir objetivos especficos
com eficcia, eficincia e satisfao em um contexto especfico de uso.
captulo 3
45
Para melhor compreenso desse enunciado, a norma ISO 9241-11 (1998)

tambm esclareceu outros conceitos:
Usurio - pessoa que interage com o produto.
Contexto de uso - usurios, tarefas, equipamentos (hardware, software e
materiais), ambiente fsico e social em que o produto usado.
Eficcia - preciso e completeza com que os usurios atingem objetivos
especficos, acessando a informao correta ou gerando os resultados
esperados.
Eficincia - preciso e completeza com que os usurios atingem seus objetivos, em relao quantidade de recursos gastos.
Satisfao - conforto e aceitabilidade do produto, medidos por meio de
mtodos subjetivos e/ou objetivos.
A ISO 9241-11 enfatiza que a usabilidade dos computadores dependente

do contexto de uso e que o nvel de usabilidade alcanado depender das circunstncias especficas nas quais o produto usado. O contexto de uso consiste de usurios, tarefas, equipamentos (hardware, software e materiais), e do
ambiente fsico e social, pois todos esses podem influenciar a usabilidade de
um produto dentro de um sistema de trabalho. As medidas de desempenho e
satisfao do usurio avaliam o sistema de trabalho como um todo, e, quando
um produto o foco de interesse, estas medidas fornecem informaes sobre
a usabilidade daquele produto no contexto particular de uso proporcionado
pelo restante do sistema de trabalho. Os efeitos das mudanas em outros componentes do sistema de trabalho, tal como: tempo de treinamento do usurio
ou melhoria de iluminao, podem tambm ser medidos pelo desempenho e
satisfao do usurio.
A abordagem adotada na NBR 9241-11 tem benefcios que incluem:
A estrutura pode ser usada para identificar os aspectos de usabilidade e
os componentes do contexto de uso aserem considerados no momento
da especificao, projeto ou avaliao de usabilidade de um produto.
O desempenho (eficcia e eficincia) e a satisfao dos usurios podem
ser usados para medir o grau em que umproduto usvel em um contexto particular.
46
captulo 3
Medidas de desempenho e satisfao dos usurios podem fornecer uma

base de comparao da usabilidade relativa de produtos, com diferentes
caractersticas tcnicas, que so usados no mesmo contexto.
A usabilidade planejada para um produto pode ser definida, documentada e verificada (p.ex. como parte de um plano de qualidade).
Para especificar ou medir usabilidade, so necessrias as seguintes informaes:
uma descrio dos objetivos pretendidos;
uma descrio dos componentes do contexto de uso incluindo usurios,
tarefas, equipamento e ambientes. Estapode ser uma descrio de um
contexto existente ou uma especificao dos contextos pretendidos. Os
aspectos relevantes do contexto e o nvel de detalhes requeridos iro depender do escopo das questes apresentadas. A descrio do contexto
precisa ser suficientemente detalhada de modo que aqueles aspectos
que possam ter uma influncia significativa sobre a usabilidade possam
ser reproduzidos;
valores reais ou desejados de eficcia, eficincia e satisfao para os contextos pretendidos.
Convm que os objetivos de uso de um produto sejam descritos. Objetivos
podem ser decompostos em sub-objetivos os quais especificam componentes
de um objetivo global e os critrios que iro satisfazer aquele objetivo. Por exemplo, um vendedor de telefones pode ter o objetivo de Manter pedidos do cliente. Este objetivo global pode ento ser decomposto em sub-objetivos como:
Fazer registros exatos de todos os pedidos feitos pelos clientes;
Fornecer rapidamente informaes s dvidas dos clientes sobre pedidos feitos.
O nvel no qual o objetivo global estabelecido uma funo do limite do

sistema de trabalho em considerao e que fornece o contexto de uso. No exemplo acima, o sistema de trabalho em considerao consiste de vendedores recebendo pedidos por telefone.
captulo 3
47
Contexto de uso
Descrio de usurios:
As caractersticas relevantes dos usurios precisam derdescritas. Elas
podem incluir conhecimento, habilidade, experincia, educao, treinamento, atributos fsicos e capacidades sensoriais e motoras. Pode ser
necessrio definir as caractersticas de diferentes tipos de usurios, por
exemplo, usurios com diferentes nveis de experincia ou desempenhando diferentes funes.
Descrio das tarefas:
Tarefas so atividades executadas para alcanar um objetivo. Convm
que sejam descritas as caractersticas das tarefas que podem influenciar
a usabilidade, p.ex. a freqncia e a durao de uma tarefa. Uma descrio detalhada das atividades e processos pode ser requisitada se a descrio do contexto for usada como base para o projeto ou avaliao de
detalhes da interao com o produto. Isto pode incluir a descrio da alocao de atividades e passos entre os recursos humanos e tecnolgicos.
As tarefas no devem ser descritas somente em termos das funes ou
funcionalidades fornecidas por um produto ou sistema.
Convm que qualquer descrio das atividades e passos envolvidos no desempenho da tarefa estejam relacionados aos objetivos a serem alcanados.
Com o propsito de avaliar a usabilidade, um conjunto de tarefas-chave ser tipicamente selecionado para representar aspectos significantes da tarefa global.
Descrio dos equipamentos:
As caractersticas relevantes do equipamento precisam ser descritas. A
descrio do hardware, software e dos materiais associados com o computador podem ser um conjunto de produtos (ou componentes do sistema), um ou mais dos quais podem ser o foco da especificao ou avaliao de usabilidade, ou um conjunto de atributos ou caractersticas de
desempenho do hardware, software ou outros materiais.
Descrio de ambientes:
As caractersticas relevantes do ambiente fsico e social precisam ser
descritas. Os aspectos que podem ser necessrios descrever incluem
48
captulo 3
atributos de um amplo ambiente tcnico (p.ex. a rede de trabalho local)

o ambiente fsico (p.ex. local de trabalho, mobilirio), o ambiente atmosfrico (p.ex. temperatura, umidade) e o ambiente cultural e social (p.ex.
prticas de trabalho, estrutura organizacional e atitudes).
Especificaes de caractersticas das medidas de uso:

Eficcia:
Medidas de eficcia relacionadas aos objetivos ou sub-objetivos do usurio quantoa acurcia e completude com que estesobjetivos podem ser
alcanados.
Por exemplo, se o objetivo desejado for reproduzir com acurcia um documento de duas pginas em um formato especfico, ento a acurcia
pode ser especificada ou medida pelo nmero de erros de ortografia e
pelo nmero de desvios do formato especificado e a completude pelo
nmero de palavras do documento transcrito dividido pelo nmero de
palavras do documento de origem.
Eficincia:
Medidas de eficincia relacionam o nvel de eficcia alcanada ao dispndio de recursos. Recursos relevantes podem incluir esforo mental
ou fsico, tempo, custos materiais ou financeiros. Por exemplo, a eficincia humana pode ser medida como eficcia dividida pelo esforo humano, eficincia temporal como eficcia dividida pelo tempo ou eficincia
econmica como eficcia dividida pelo custo.
Se o objetivo desejado for imprimir cpias de um relatrio, ento a eficincia pode ser especificada ou medida pelo nmero de cpias usveis
do relatrio impresso, dividido pelos recursos gastos na tarefa tal como
horas de trabalho, despesas com o processo e materiais consumidos.
Satisfao:
A satisfao mede a extenso pela qual os usurios esto livres de desconforto e suas atitudes em relao ao uso do produto. A satisfao pode
ser especificada e medida pela avaliao subjetiva em escalas de desconforto experimentado, gosto pelo produto, satisfao com o uso do produto ou aceitao da carga de trabalho quando da realizao de diferentes
captulo 3
49
tarefas ou a extenso com os quais objetivos particulares de usabilidade

(como eficincia ou capacidade de aprendizado) foram alcanados.
Outras medidas de satisfao podem incluir o nmero de comentrios
positivos e negativos registrados durante o uso. Informao adicional
pode ser obtida atravs de medidas de longo-termo como as taxas de absentesmo, observao de sobrecarga ou subcarga de trabalho fsico ou
cognitivo do usurio, ou de problemas de sade relatados, ou a freqncia com que os usurios requerem transferncia para outro trabalho.
3.3 Norma ISO 14598 (avaliao de produto)

De acordo com a ISO 14598, avaliar a qualidade de um produto de software :
Verificar, atravs de tcnicas e atividades operacionais, o quanto os requisitos so atendidos. - Tais requisitos, de uma maneira geral, expressam as necessidades explicitadas em termos quantitativos ou qualitativos e apresentam
como objetivo a definio das caractersticas de um software, a fim de permitir
o exame de seu entendimento.
ATENO
Vale a pena ressaltar que as responsabilidades de avaliao e de garantia da qualidade devem constar em um plano que vise ao uso e melhoria da tecnologia de avaliao, implementao, transferncia e avaliao da tecnologia de avaliao usada e, por fim, o gerenciamento
da experincia de avaliar.
Deve-se avaliar a qualidade do produto liberado por diversas razes, tais como:
Identificar e entender as razes tcnicas para as deficincias e limitaes
do produto, que podem manifestar-se atravs de problemas operacionais e problemas de manuteno;
Comparar um produto com outro, mesmo que indiretamente;
Formular um plano de ao de como fazer o produto de software evoluir.
Um plano de avaliao quantitativa deve conter introduo, objetivos, caractersticas da qualidade aplicveis, lista de prioridades, objetivos da qualida-
50
captulo 3
de, cronograma, definio de responsabilidades, categorias de medio, uso e

anlise de dados, relatrios e demais requisitos de interesse.
3.3.1 Etapas da Norma ISO/IEC 14598
A srie de normas ISO/IEC 14598 descreve um processo para avaliao de produtos de software, que consiste de quatro passos, conforme a Tabela 3.1. O padro definido distingue trs perspectivas de avaliao: desenvolvedor, adquirente e avaliador.
EXECUO
PROCESSO PARA
DESENVOLVEDORES
PROJETO
Definio de
requisitos de
qualidade e
anlise de sua
exequibilidade
Quantificao
dos requisitos
de qualidade
Planejamento da
avaliao durante
o desenvolvimento
Monitoramento
da qualidade e
controle durante o
desenvolvimento
PROCESSO
PARA ADQUIRENTES
ESPECIFICAO
Estabelecimento do propsito
e escopo da
avaliao
Definio de
mtricas externas e medies
correspondentes a serem
realizadas
Planejar, programar e documentar a avaliao
A avaliao deviria
ser realizada,
documentada e
analisada
PROCESSO
PARA AVALIADORES
ANLISE
Descrio dos
objetivos da
avaliao
Definio do
escopo da
avaliao e das
medies
Documentao
dos processos
a serem usados
pelo avaliador
Obteno dos
resultados a partir
da realizao de
aes de medio
e verificao do
produto
Tabela 3.1 Definio do processo de avaliao segundo a ISO/IEC 14598
captulo 3
51
A Norma ISO/IEC 14598 dividida em seis partes, as quais so apresentadas

a seguir:
ISO/IEC 14598-1: (ISO/IEC 14598-1:1999) Viso geral
Nessa primeira parte apresentada uma viso geral do processo de avaliao
da qualidade dos produtos de software e definida tambm toda a estrutura de
funcionamento da srie de normas ISO/IEC 14598.
Fornece-se um estrutura para avaliar a qualidade de quaisquer produtos
de software e estabelece os requisitos para medio e avaliao de produtos
de software.
Para avaliar a qualidade do software, primeiro se estabelecem os requisitos
da avaliao, ento se especifica, projeta e executa a avaliao, como mostra a
Figura 1.
14598-1
Viso Geral
14598-2
Planejamento
e gesto
14598-3
Processo para
desenvolvedores
14598-4
Processo para
adquirentes
14598-6
Documentao de
mdulos de avaliao
Figura 1 Estrutura da srie de normas ISO/IEC 14598
52
captulo 3
14598-5
Processo para
avaliadores
Para avaliar a qualidade do software, primeiro se estabelecem os requisitos

da avaliao, ento se especifica, projeta e executa a avaliao, como mostra a
Figura 2.
Estabelecer
Requisitos de
Avaliao
Estabelecer o propsito da avaliao
Especicar
a Avaliao
Selecionar mtricas
Identicar tipos de produto(s) a serem avaliados

Especicar modelo de qualidade
Estabelecer nveis de pontuao para as mtricas

Estabelecer critrios para julgamento
Estabelecer
Requisitos de
Avaliao
Estabelecer
Requisitos de
Avaliao
9126-1 Caractersticas
de qualidade
9126-2 Mtricas externas

9126-3 Mtricas internas
14598-6 Mdulos de avaliao
Produzir o plano de avaliao
Obter as medidas
Comparar com critrios
Julgar os resultados
Figura 2 Processo de avaliao segundo a ISO/IEC 14598-1
Abaixo sero descritas cada uma das etapas do processo de avaliao segundo a ISO/IEC 14598:
Estabelecer requisitos de avaliao: visa levantar os requisitos gerais da avaliao.
Estabelecer o propsito da avaliao: define quais os objetivos da avaliao. Tais objetivos esto relacionados ao uso pretendido do produto
de software e aos riscos associados. Podem ser definidos pontos de vista
diferentes de vrios usurios do produto, tais como: adquirente, fornecedor, desenvolvedor, operador ou mantenedor do produto.
Identificar tipos de produto(s) a serem avaliados: define o tipo de produto
a ser avaliado, se so um dos produtos intermedirios ou o produto final.
Especificar modelo de qualidade: a primeira etapa na avaliao de software consiste em selecionar as caractersticas de qualidade relevantes, utili-
captulo 3
53
zando um modelo de qualidade que desdobre a qualidade de software em

diferentes caractersticas. Nesta fase da avaliao escolhido o modelo
de qualidade a ser utilizado visando definir os requisitos de qualidade
para o produto de software.
Especificar a avaliao: define a abrangncia da avaliao e das medies a serem realizadas sobre o produto submetido para avaliao.
Selecionar mtricas: a forma pela qual as caractersticas de qualidade
tem sido definidas no permite sua medio direta. necessrio estabelecer mtricas que se correlacionem s caractersticas do produto de
software. Neta fase da avaliao so selecionadas as mtricas a serem utilizadas durante a avaliao.
Estabelecer nveis de pontuao para as mtricas: para cada mtrica selecionada devem ser definidos os nveis de pontuao e uma escala relacionada, onde podero ser representados o nvel planejado, o nvel atual
e o nvel que representa o pior caso para o atributo a ser medido.
Estabelecer critrios para julgamento: para julgar a qualidade do produto, o resultado da avaliao de cada caracterstica precisa ser sintetizado.
aconselhvel que o avaliador prepare um procedimento para isto, onde
cada caracterstica poder ser representada em termos de suas subcaractersticas ou de uma combinao ponderada de suas subcaractersticas.
Projetar a avaliao: deve documentar os procedimentos a serem utilizados
pelo avaliador para realizar as medies contidas na especificao de avaliao.
Produzir plano de avaliao: o avaliador deve produzir um plano de avaliao que descreva os recursos necessrios para realizar a avaliao especificada, bem como a distribuio destes recursos entre as diversas
aes a serem realizadas.
Executar a avaliao: obter os resultados da execuo das aes de medio e verificao do produto de software de acordo com os requisitos de avaliao, como
especificado na especificao de avaliao e planejado no plano de avaliao.
54
captulo 3
Obter as medidas: as mtricas selecionadas so aplicadas ao produto de

software obtendo como resultado valores nas escalas das mtricas.
Comparar com critrios: o valor medido para cada mtrica comparado
com os critrios determinados na especificao da avaliao.
Julgar os resultados: o julgamento a etapa final da avaliao, onde um
conjunto de nveis pontuados resumido. O resultado uma declarao
de quanto o produto de software atende aos requisitos de qualidade.
ISO/IEC 14598-2 (ISO/IEC 14598-2:2000): Planejamento e gesto
Aqui apresenta-se o planejamento e gesto do processo de avaliao apresentando requisitos, recomendaes e orientaes para uma funo de suporte ao
processo.
ISO/IEC 14598-3 (ISO/IEC 14598-3:2000): Processo para desenvolvedores
Na terceira parte da norma definido o processo para desenvolvedores. Destina-se ao uso durante o processo de desenvolvimento e manuteno de software.
ISO/IEC 14598-4 (ISO/IEC 14598-4:1999): Processo para adquirentes:
Nesta parte da norma define-se o processo para adquirentes, estabelecendo
um processo sistemtico para avaliao de produtos de software tipo pacote
(com equivalncia a NBR ISO/IEC 12119) [15], produtos de software sob encomenda, ou ainda modificaes em produtos j existentes.
Ao referenciar o processo de aquisio definido pela Norma ISO/IEC 12119
ressalta a existncia das seguintes atividades:
Iniciao: o adquirente inicia o processo de aquisio ao considerar a
necessidade de obter, desenvolver ou melhorar um sistema, produto ou
servio de software.
Preparao do pedido de proposta: Elaborao dos documentos de requisitos de aquisio bem como determinados os pontos de controle
para reviso e auditoria do progresso do fornecimento.
Preparao e atualizao do controle: Seleo de fornecedores e suas capacidades firmadas em contrato e, negociado o custo, cronograma de execuo. As mudanas no contrato devem ser controladas pelo adquirente.
captulo 3
55
Monitorao do fornecedor: Consiste em atividades de avaliao durante a

execuo do contrato levando aceitao e entrega do produto de software.
Aceitao e concluso: Aceitao e entrega do produto de software final,
obedecidos aos critrios de aceitao previamente definidos durante a
atividade de iniciao.
ISO/IEC 14598-5 (ISO/IEC 14598-5:1998): Processo para avaliadores:
Define o processo para avaliadores, fornecendo orientaes para a implementao prtica de avaliao de produtos de software (quando diversas partes necessitam entender, aceitar e confiar em resultados da avaliao). Conta com a
participao de avaliadores de laboratrio, fornecedores e adquirentes de software, usurios e entidades certificadoras que defendem objetivos diferentes.
Os avaliadores podem ser especificamente os laboratrios de testes, as
equipes de testes integradas de organizaes de produo ou de distribuio
de software, os compradores ou usurios de software ou de integradoras de sistemas ou ainda as organizaes que realizam comparaes de softwares.
Nessa etapa da norma so gerados alguns documentos, os quais passam a
fazer parte do produto de software, tais como documentos de projetos, relatrios de testes e avaliao, cdigo fonte e documentao do usurio.
As atividades do processo de avaliao so as seguintes:
Estabelecimento de requisitos da avaliao: Descrio dos objetivos da
avaliao coerentes com o produto de software e possveis riscos associados. As percepes dos usurios do produto, fornecedores, compradores, desenvolvedores, operadores e mantenedores do produto devem ser
levados em considerao.
Especificao da avaliao: Definio do escopo da avaliao e as medies a que o produto ser submetido. Dependente dos requisitos de avaliao previamente definidos pelo requisitante.
Projeto de avaliao: Preparo de um plano de ao de acordo com a especificao do avaliador e com base nos mtodos a serem usados para a
realizao das medies estabelecidas na especificao. Um documento
guarda, portanto, as especificaes da avaliao, o cronograma, os recursos necessrios e disponveis para realizar a avaliao.
56
captulo 3
Execuo da avaliao: Consiste na inspeo, medio e teste dos produtos e de seus componentes aplicados de acordo com as orientaes do
plano. Aplicadas as aes de medio, segue-se para as interpretaes
dos resultados registrados e depurados durante a avaliao. Ao final da
execuo, uma verso preliminar gerada do relatrio de avaliao.
Concluso da avaliao: Reviso do relatrio de avaliao e liberao dos
dados de avaliao, bem como a devoluo, pelo avaliador, do produto
avaliado e seus componentes.
Ainda na parte 5 da norma, as caractersticas esperadas do processo de avaliao so :
Repetitividade: Avaliao repetida de um mesmo produto, com mesma
especificao de avaliao, realizada pelo mesmo avaliador, deve produzir resultados que podem ser aceitos como idnticos.
Reprodutividade: A avaliao do mesmo produto, com mesma especificao de avaliao, realizada por um avaliador diferente, deve produzir
resultados que podem ser aceitos como idnticos.
Imparcialidade: A avaliao no deve ser influenciada frente a nenhum
resultado particular.
Objetividade: A avaliao no deve ser influenciada frente a nenhum resultado particular.
O processo de avaliao proposto pela norma NBR ISO/IEC 14598-5 semelhante ao da parte 1, incluindo uma etapa a mais para as etapas da avaliao, a
saber: Concluso da avaliao. Esta etapa ser descrita abaixo.
Concluso da avaliao: nesta etapa, deve-se revisar o relatrio da avaliao e
disponibilizar os dados resultantes da mesma para o requisitante da avaliao.
Para uma avaliao profissional, esses dados so sigilosos e exclusivos ao requisitante da avaliao, qualquer publicao deles de sua inteira responsabilidade.
captulo 3
57
CONEXO
O artigo o uso da norma 14598 na avaliao de software com relao qualidade disponvel em http://www.waltenomartins.com.br/intercursos_v8n1.pdf uma leitura interessante
para complementar nossa discusso sobre esse assunto!
ISO/IEC 14598-6 (ISO/IEC 14598-6:2001): Documentao de mdulos para

avaliao:
Fornece orientao para documentao de mdulos de avaliao. Estes
mdulos contm a especificao do modelo de qualidade, as informaes e dados relativos aplicao prevista do modelo e informaes sobre a real aplicao do modelo.
Aps a finalizao das etapas da Norma ISO/IEC 14598 no prximo tpico
seguem algumas atividades sugeridas.
ATIVIDADE
6. Comente uma das vantagens de se usar a Norma ISO 9241?
7. Como a ISO 9241-11 redefine usabilidade?
8. De acordo com a ISO 14598, o que significa avaliar a qualidade de um produto de software?
9. Voc se lembra de quantas e quais so as partes da ISO/IEC 9241? So vrias, mas
faa um esforo.
58
captulo 3
REFLEXO
Com o estudo desse captulo podemos entender a norma ISO/IEC 9241, onde foi dado especial ateno s orientaes para usabilidade de software, devido a sua grande importncia
na qualidade de um software.
Pudemos ver tambm o funcionamento do processo de avaliao de produto de software
segundo a norma ISO/IEC 14598, a qual faz referncia ao processo de aquisio definido
pela ISO/IEC 12207.
A avaliao de um produto de software envolve vrios fatores e caractersticas, aqui
demos nfase a usabilidade, o que fcil de entender, uma vez que ningum quer ter um
software que no consegue usar, no mesmo?!
LEITURA
Guia para utilizao das normas sobre avaliao de qualidade de produto de
software ISO/IEC 9126 e ISO/IEC 14598 disponvel em: http://www2.dem.inpe.br/
ijar/GuiaUtilNormTec.pdfhttp://www2.dem.inpe.br/ijar/
Utilizando a norma IS/IEC 14598-5 na avaliao de qualidade de hiperdocu-mentos web disponvel em: http://www.comp.ita.br/~cunha/download/CES32CE230-2002/Sem11/1_AS3-2%20Utilizando%20a%20Norma%20ISO-IEC%20
14598-5%20na%20Avaliacao%20de%20Qualidade%20de%20Hiperdocumentos%20
Web.pdf
(ISO/IEC 14598-1:1999), International Standard. Information Technology Software Product Evaluation - Part 1: General Overview.
(ISO/IEC 14598-2:2000), International Standard. Information Technology Software Product Evaluation - Part 2: Planning and Management.
(ISO/IEC 14598-3:2000), International Standard. Information Technology Softwa-
captulo 3
59
re Product Evaluation - Part 3: Process for Developers.

(ISO/IEC 14598-4:1999), International Standard. Information Technology Software Product Evaluation - Part 4: Process for Acquirers.
(ISO/IEC 14598-5:1998), International Standard. Information Technology Software Product Evaluation - Part 5: Process for Evaluators.
(ISO/IEC 14598-6:2001), International Standard. Information Technology Software Product Evaluation - Part 6: Evaluation Modules.
NO PRXIMO CAPTULO
Dando continuidade ao nosso estudo sobre qualidade de software, no prximo captulo veremos alguns modelos de melhoria de processo de software.
60
captulo 3
4
Modelos de
Melhoria e Avaliao
de Processo de
Software
4 Modelos de Melhoria e Avaliao de

Processo de Software
Desde o incio desta disciplina estamos falando da grande importncia de se
ter qualidade em um produto de software, falamos tambm que a obteno da
qualidade nem sempre uma tarefa fcil, na verdade ela bem complexa, pois
um envolve uma grande quantidade de fatores a serem avaliados, medidos e
melhorados continuamente.
Nesse captulo iremos comentar sobre modelos que compem a melhoria
do processo de software.
OBJETIVOS

Abordar o modelo de garantia da qualidade em produo e instalao, de acordo com

a ISO 9000-3;
Compreender as etapas dos Modelos PDCA e IDEA;
Descrever os objetivos da Norma NBR ISO/IEC 12207;
Apresentar os critrios para definio dos seguintes processos na Norma NBR ISO/
IEC 12207;
Processos fundamentais;
Processos de apoio;
Processos organizacionais;
Processos de adaptao.
REFLEXO
Voc se lembra o que vem a ser um processo de software?
Bom, vamos relembrar juntos:
Um processo de software pode ser definido como um conjunto de atividades, mtodos, prticas e transformaes que as pessoas usam para desenvolver e manter o software e os
produtos associados (por exemplo: planos de projeto, documentos, cdigo, casos de teste e
manuais de usurio). (IEEE-STD-610).
62
captulo 4
J comentamos que a qualidade de um produto de software est ligada diretamente a qualidade do seu processo de software. Sendo assim, vamos agora ver alguns modelos que nos
ajudam a entender como avaliar e melhorar de forma contnua um processo de software.
4.1 Melhoria de Processo de Software

Para a obteno de um produto de software de qualidade extremamente importante que tomemos cuidado com o processo desse software.
J vimos que um processo de software catico possui muitas caractersticas
ruins e, que podem influenciar diretamente na qualidade do produto final do
software.
CONEXO
Antes de definirmos a melhoria de processo de acordo com a ISO 9000-3 sugiro a vocs
a leitura do artigo Melhoria de processo de software brasileiro disponvel em http://www.
devmedia.com.br/melhoria-do-processo-de-software-brasileiro/29915
Vimos tambm que um processo de software maduro trs muitos benefcios para todos os envolvidos no seu desenvolvimento. Porm, a obteno de
um processo de software maduro nem sempre uma tarefa fcil para as empresas. Para auxili-las nessa funo, temos na literatura vrios modelos que
tem como objetivo avaliar e melhorar continuamente um processo de software.
Vamos comear definindo o que vem a ser melhoria de processo de software.
De acordo com a ISO 9000-3, melhoria de processo consiste a abordagem na
prtica de aes orientadas para a alterao dos processos aplicados para aquisio, fornecimento, desenvolvimento, manuteno e/ou suporte de sistemas
de software.
Vamos relembrar, entende-se por um processo de software maduro, capaz,
aquele que executado de forma eficiente e eficaz, com a presena de alguma
caractersticas importantes, tais como:
Execuo consistente e sempre que necessria.
Flexibilidade no processo de execuo para melhor adaptao das necessidades especficas.
captulo 4
63
Documentao com uma notao representativa de processo identificado por meio de texto, figuras, fluxos, etc.
Deve ser apropriado para que as pessoas possam realizar o trabalho.
Treinamento para as pessoas inseridas nas atividades do processo de
forma a obterem conhecimento, habilidade e experincia.
Manuteno para garantir a evoluo contnua.
Controle de mudanas para garantir a integridade e disponibilidade dos
artefatos.
Apoio de equipes, ferramentas e recursos apropriados para realizao do
processo.
As organizaes com processo de software de alta qualidade tem esse processo institucionalizado atravs de polticas, padres e estruturas organizacionais. A Institucionalizao acarreta construir uma infraestrutura (processos
eficazes, utilizveis e consistentemente aplicados em toda organizao) e uma
cultura corporativa que apia os mtodos, prticas e procedimentos dos negcios para que eles perdurem mesmo depois que aqueles que originariamente
os definiram tenham sado da organizao.
4.2 Modelos de Melhoria de Processo de Software

Um modelo de melhoria deve permitir que se compreenda o estado atual do
processo, que se desenvolva a viso do processo desejado, que se estabelea
uma lista de aes necessrias melhoria do processo, em ordem de prioridade
e que se gere um plano para acompanhar as aes e alocao de recursos para
a execuo do plano.
Os modelos de melhoria de processo de software ajudam a empresa a se
organizar e estabelecer uma ordem de prioridades de tal forma que a qualidade
possa efetivamente ser construda ao longo do processo e fazer parte, inerentemente, do produto gerado.
Em uma melhoria de processo de software, o processo passa por uma avaliao, os resultados dessa avaliao conduzem melhorias, as quais mostram mudanas que devem ser realizados na processo e, isso deve ser feito continuamente.
64
captulo 4
A capacidade dos processos de software de uma organizao influencia na

sua capacidade de atingir metas de custo, qualidade e cronograma.
Os modelos de melhoria de processo de software seguem estratgias de melhoria de processo que ajudam a coordenar os esforos de melhoria contnua.
Uma estratgia de melhoria de processo permite que:
se compreenda o estado atual do processo,
se desenvolva a viso do processo desejado,
se estabelea uma lista de aes necessrias melhoria do processo, em
ordem de prioridade, e
que se gere um plano para acompanhar as aes e alocao de recursos
para a execuo do plano.
Como exemplos de estratgias de melhoria de processo, podemos citar o
ciclo de melhoria PDCA e o modelo IDEAL.
4.2.1 Ciclo de Melhoria PDCA.
O ciclo PDCA um mtodo gerencial de tomada de decises para garantir o
alcance das metas necessrias sobrevivncia de uma organizao. Os conceitos do ciclo PDCA foram originalmente desenvolvidos por Walter Shewart, um
estatstico pioneiro que desenvolveu o controle estatstico nos Laboratrios da
Bell nos Estados Unidos, na dcada de 30. A eficincia do ciclo se tornou famosa, na dcada de 50 quando surgiu, no contexto de Gerenciamento de Qualidade, a grande autoridade, W. Eduard Deming.
O uso do PDCA ajuda a coordenar os esforos de melhoria contnua e demonstra que programas de melhoria devem iniciar sempre com:
um planejamento cuidadoso,
que devem resultar em aes efetivas que, por sua vez,
devem levar ao planejamento,
fechando, assim, um ciclo contnuo.
Etapa de Planejamento (P)
Nessa etapa as metas da organizao so estabelecidas e so desenvolvidos mtodos para alcanar essas metas. Isso significa selecionar as operaes que so
causadoras de problemas e desenvolver idias para resolver esses problemas.
captulo 4
65
Metas para Manter: tambm conhecidas como metas padro- representam

uma faixa aceitvel de valores que devem ser mantidos pelas caractersticas
consideradas importantes no produto.
Metas para Melhorar: tambm conhecidas como metas de melhoria surgem do
fato de que o mercado sempre deseja um produto cada vez melhor, a um custo
cada vez mais baixo e com entrega cada vez mais precisa.
O surgimento de novos concorrentes no mercado, novas tecnologias, novos
materiais tambm levam a necessidade de estabelecer metas de melhoria.
Atingir uma meta de melhoria implica em modificar a atual condio de trabalho.
Etapa de Execuo (Do)
Nessa etapa as tarefas que foram previstas na etapa de planejamento so executadas e coletam-se dados que sero utilizados na prxima etapa de verificao
do processo. importante que as mudanas sejam implementadas em escalas
menores para primeiro testar sua eficincia para que os erros no causem grandes catstrofes ao processo j em andamento. Assim, pode-se verificar se as
mudanas funcionam bem ou no. So abordados a educao (disseminao
de novos conceitos e tecnologia) e o treinamento (aperfeioamento de conceitos j conhecidos).
Etapa de Verificao (Check)
Nessa etapa realizada uma comparao entre os dados coletados na etapa de
Execuo e as metas definidas na etapa de Planejamento. Para isso, verifica-se
se a escala menor de implementao ou mudanas experimentais alcanaram
os resultados esperados
Etapa de Ao (A)
Essa etapa consiste em atuar no processo em funo dos resultados obtidos. Se
o sucesso obtido em uma escala menor, pode significar que a mudana pode
fazer parte das atividades da organizao, envolvendo outras pessoas, outros
departamentos, fornecedores e clientes afetados pelas mudanas.
66
captulo 4
LEITURA
Para mais informaes sobre o Modelo PDCA, leia o artigo PDCA: origem, conceitos e
variantes dessa idia de 70 anos Disponvel em: http://www.qualypro.com.br/artigos/pdcaorigem-conceitos-e-variantes-dessa-ideia-de-70-anos#sthash.m2YGAatn.dpuf
O envolvimento de outras pessoas importante para ajudar na implementao das mudanas numa escala maior, ou mesmo para a conscientizao dos
novos benefcios que podem adquirir com as mudanas. Existem duas formas
de atuao possveis:
adotar o plano como padro, caso a meta tenha sido alcanada
agir sobre as causas que no permitiram que as metas sejam efetivas.
4.2.2 Modelo IDEAL
O Modelo IDEAL foi desenvolvido pela SEI (Software Engineering Institute).
IDEAL um acrnimo que engloba os 5 estgios do ciclo de melhoria de processo de software, o o qual contm as atividades de diagnstico do processo
atual, a elaborao de um plano para melhoria, a implantao deste plano e a
confirmao das atividades implantadas atravs do diagnstico do processo,
iniciando novamente o ciclo. (Gremba, 1997).
( I nitiating) - Inicializao
( D iagnosing)- Diagnstico
( E stablishing) - Estabelecimento
( A cting) - Ao
( L everaging) - Lies
O modelo estabelece um programa de melhoria contnua de processo de
software (Figura 3) que ajuda as organizaes a melhorar o seu processo de
software.
captulo 4
67
s
Li e
Propor
futuras
aes
o
A
Renar
soluo
Testar
soluo
Estmulo para
mudana
Estabelecer
contexto
Analisar
e
Implementar
Validar
soluo
Denir
patrocinador
Inicializao
Fornecer
infra-estrutura
Criar
soluo
Planejar
aes
Caracterizar
estadocorrente
eo
Desenvolver
desejado
Desenvolver Estabelecer abordagem
o
nt
recomendaes prioridades
Di a
me
i
c
gn
el e
s
ti c
tab
o
Es
Figura 3 Abordagem IDEAL (IDEAL, 1998).
Fase de Inicializao: Nessa fase so identificados os motivos e as razes para

mudanas no processo de software, os quais necessitam ser extremamente claros e evidentes.
Essa fase envolve:
Estabelecer o contexto que significa definir, claramente, onde os esforos
vo se enquadrar na estratgia de negcio da organizao, definir quais
metas e objetivos de negcio sero afetados pelas mudanas, definir
como isso vai incidir sobre outras iniciativas e trabalhos futuros e definir
os benefcios esperados.
Definir o patrocinador: um patrocinador efetivo um dos fatores mais
importantes para os esforos de melhoria de processo. O patrocinador
deve ajudar a manter o compromisso nos momentos de dificuldades e
principalmente na situao de caos que a organizao pode se encontrar
no princpio do processo de melhoria. Outra funo do patrocinador
garantir os recursos essenciais utilizados durante a melhoria.
68
captulo 4
Fornecer infra-estrutura: aps definir as razes para mudana, o contexto e o comprometimento dos patrocinadores, importante definir o mecanismo para gerenciar os esforos para os detalhes de implementao:
a infra-estrutura
Fase de Diagnstico: Nessa fase duas caractersticas da organizao so consideradas
Estado atual do processo de software da organizao e o estado futuro
desejado; esses estados sero utilizados para desenvolver as prticas
de melhoria de processo. Caracterizar o estado corrente e o desejado
como identificar o incio e o fim da jornada. Uma vez identificado o estado atual, pode-se usar algum modelo de processo (por exemplo o CMM)
para definir o estado desejado.
Desenvolvimento de recomendaes: nessa atividade, desenvolve-se recomendaes, sugerindo meios de como proceder em atividades subseqentes. As atividades da fase de Diagnstico so desempenhadas pelas
pessoas mais experientes ou por especialistas relevantes na organizao.
Suas recomendaes so baseadas nas decises realizadas pelos gerentes chefes e patrocinadores.
Fase de Estabelecimento: Essa fase possui trs atividade a serem realizadas:
Estabelecer prioridades: essa prioridade deve considerar vrios fatores,
tais como as limitao de recursos, dependncias entre as atividades recomendadas, interveno de fatores externos e as prioridades globais da
organizao.
Desenvolver uma abordagem - envolve o desenvolvimento de uma estratgia de acompanhamento do trabalho considerando o escopo do trabalho, o conjunto de prioridades e a disponibilidade dos recursos
Planejar aes: Com a abordagem definida, pode-se desenvolver um plano detalhado de implementao. Esse plano inclui cronograma, tarefas,
prazos, pontos de deciso, recursos, responsabilidades, medidas, mecanismo de acompanhamento , riscos e mitos, estratgias, outros elementos requeridos pela organizao para o processo de melhoria contnua
captulo 4
69
Fase de Ao: As atividades dessa fase ajudam a organizao a implementar o

trabalho que foi contextualizado e planejado nas trs fases anteriores. Essas atividades tipicamente consomem mais tempo e recursos que todas as outras combinadas. A fase de Ao comea associando todos os elementos chave para criar
a melhor soluo imaginvel destinada s necessidades previamente identificadas da organizao. Uma vez criada a soluo, ela deve ser testada, pois por mais
que a soluo seja bem elaborada ela raramente funciona como o planejado.
Aps a soluo ter sido testada, ela pode ser modificada para refletir o conhecimento, a experincia e as lies que foram obtidos pelos testes. Nessa etapa,
pode-se implementar a soluo por toda a organizao, uma vez que ela j esteja
preparada. Para a implementao podem ser utilizadas as abordagenstop-down
(comeando pela parte superior da organizao) ou a abordagem just-in-time
(implementando projeto por projeto em seu tempo apropriado).
Fase de Lies: Nessa fase as experincias so revisadas, para analisar o que foi
realizado e como a organizao pode implementar mudanas mais efetivamente, no futuro.
As lies so coletadas, analisadas e documentadas, as necessidades identificadas na fase de inicializao so reexaminadas para ver se foram atendidas e so
fornecidas propostas de alteraes para melhoria futura.
Aps nossa discusso sobre os Modelos de Melhoria PDCA e IDEAL, a seguir
vamos nos ater a algumas normas ISO, como a NBR/ISO 9000-3 e a NBR/ISO
12207, sendo a primeira define diretrizes para facilitar a aplicao da norma
ISO 9001 a organizaes que desenvolvem, fornecem e mantm software.por
serem normas voltadas a melhoria de processo e, a segunda estabelece uma
estrutura comum para os processos de ciclo de vida de software como forma de
ajudar as organizaes a compreenderem todos os componentes presentes na
aquisio e fornecimento de software e, assim, conseguirem firmar contratos e
executarem projetos de forma eficaz.
4.3 NBR/ISO 9000-3

A NBR/ISO 9000 foi desenvolvida para ajudar organizaes na implementao e
operao de sistemas da qualidade eficazes. A ISO 9000 uma srie de normas
internacionais para gesto da qualidade e garantia da qualidade. Ela auxilia a empresa na seleo da norma mais apropriada par o seu negcio e a sua utilizao.
70
captulo 4
Ela no destinada a um produto nem para uma alguma empresa especfica. Tem
como objetivo orientar a implantao de sistemas de qualidade nas organizaes.
A srie composta das seguintes normas:
ISO 9000- Fundamentos e vocabulrio
ISO 9001- Sistemas de gerenciamento da qualidade requisitos
ISO 9004 Sistemas de gerenciamento da qualidade guia para melhoria da performance
ISO 19011- Auditorias internas da qualidade e ambiental
Para facilitar a aplicao em desenvolvimento de software a ISO 9000-3, que
so orientaes para a aplicao da ISO 9001 ao projeto, desenvolvimento, fornecimento, instalao e manuteno de software. A norma define diretrizes
para facilitar a aplicao da norma ISO 9001 a organizaes que desenvolvem,
fornecem e mantm software. Destina-se a fornecer orientao quando um
contrato entre duas partes exigir a demonstrao da capacidade do fornecedor
em desenvolver, fornecer e manter produtos de software.
De fato, a ISO 9000-3 um guia para a aplicao da ISO 9001 para o desenvolvimento, fornecimento e manuteno de software. As diretrizes propostas
na ISO 9000-3 cobrem questes como:
Entendimento dos requisitos funcionais entre contratante e contratado;
Uso de metodologias consistentes para o desenvolvimento de software;
Gerenciamento de projeto desde a concepo at a manuteno.
ATENO
importante ressaltar que a ISO 9000-3 considera apenas quais processos a organizao
deve ter e manter, mas no orienta quanto aos passos que devem ser seguidos para chegar
a desenvolv-los e nem de como aperfeio-los. A ISO 9001 baseia-se em 20 diretrizes (ou
critrios) que englobam vrios aspectos da garantia da qualidade.
A ISO 9000-3 engloba somente 12 desses elementos. O ponto central dos

critrios de um sistema de gesto da qualidade baseada nas normas ISO 9000
a apropriada documentao desse sistema. As diretrizes da ISO 9000-3 so:
Estrutura descreve aspectos organizacionais relacionados ao sistema
de qualidade.
captulo 4
71
Atividades do ciclo de vida: descreve atividades de desenvolvimento de

software.
Atividades de suporte: descreve atividades que apoiam as atividades do
ciclo de vida.
4.4 NBR/ ISO 12207 - Processos de ciclo de vida do software

A norma ISO 12207 em como objetivo o estabelecimento de uma estrutura comum para os processos de ciclo de vida de software como forma de ajudar as
organizaes a compreenderem todos os componentes presentes na aquisio
e fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma eficaz.
O gerenciamento por processos trs vrias vantagens para as organizaes,
tais como:
Alinha estrategicamente a organizao.
Foca a organizao no cliente.
Obriga a organizao a prestar contas pelo desempenho dos seus processos.
Alinha a fora de trabalho com os processos.
Evidencia a necessidade de alocao de recursos.
Melhora a eficincia.
ATENO
necessrio deixar claro que segundo a ISO/IEC 12207, cada processo deve ser de responsabilidade de uma parte. A parte que executa tem a responsabilidade por todo o processo, mesmo que tarefas individuais possam ser realizadas por pessoas diferentes.
Os processos da ISO/IEC 12207 so fortemente coesos, ou seja, todas as

partes de um processo so fortemente relacionadas. Porm, os processos so
fracamente acoplados quanto quantidade de interfaces entre os processos.
O escopo da Norma ISO/IEC 12207 abrange todo o ciclo de vida de software, desde a concepo inicial at a descontinuidade do software, e por todos os
envolvidos com produo, manuteno e operao do software. A norma pode
72
captulo 4
ser aplicada para toda empresa desenvolvedora de software, mas existem casos
de aplicao em projetos especficos por imposio contratual ou nas fases iniciais de implantao.
A Norma ISO/IEC 12207 foi a referncia base para a elaborao da Norma
ISO/IEC 15504-5 publicada em 2006 e que define um modelo para a avaliao
de processos de software baseado no framework da Norma ISO/IEC 15504 (ARRUDA, 2006).
Os processos da Norma ISO/IEC 12207 so agrupados de acordo com o seu
objetivo principal no ciclo de vida de software. Estes agrupamentos resultam
em trs classes de processos: Processos Fundamentais, Processos de Apoio e
Processos Organizacionais. Segundo Arruda (2006), a classe dos Processos
Fundamentais so basicamente todas as atividades que a empresa executa nos
servios de desenvolvimento, manuteno ou operao de software. Esses processos comandam a execuo de todos os outros processos. Os cinco processos
fundamentais de ciclo de vida so:
a) Aquisio;
b) Fornecimento;
c) Desenvolvimento;
d) Operao;
e) Manuteno.
A classe dos Processos de Apoio constituda por um conjunto de processos
que esto ligados ao software atravs de aes de produo de Intercursos - V.8 - N.2
- Jul-Dez 2009 ISSN 2179-9059 171documentao, testes e avaliao do produto
desenvolvido.
A classe dos Processos Organizacionais um conjunto de processos que fazem referncias gesto dos processos e dos recursos humanos envolvidos.
Vamos analisar com mais calma a arquitetura dessa norma.
Arquitetura da Norma ISO/NBR 12207
A Norma estabelece uma arquitetura de alto nvel do ciclo de vida de software,
abrangendo desde a concepo at a descontinuidade do software. Esta arquitetura baseada em processos-chave e o inter-relacionamento entre eles.A arquitetura segue dois princpios bsicos:
captulo 4
73
Modularidade: Os processos tm alta coeso e baixo acoplamento, ou

seja, todas as partes de um processo so fortemente relacionadas e o nmero de interfaces entre os processos mantido ao mnimo.
Responsabilidade: Cada processo na Norma de responsabilidade de
uma parte envolvida. Uma parte envolvida pode ser uma organizao ou parte dela. As partes envolvidas podem ser da mesma organizao ou de organizaes diferentes.
Na Norma ISO/IEC 12207, os processos de ciclo de vida so agrupados em quatro classes, que representam a sua natureza, a saber:
Processos Fundamentais: Atendem o incio, contratao entre o adquirente e o fornecedor, e a execuo do desenvolvimento, operao ou manuteno de produtos de software durante o ciclo de vida de software.
Processos de Apoio: Auxiliam e contribuem para o sucesso e qualidade
do projeto de software.
Processos Organizacionais: So empregados por uma organizao para
estabelecer e implementar uma estrutura constituda de processos de ciclo de vida e pessoal associados, melhorando continuamente a estrutura
e os processos.
Processo de Adaptao: O processo de adaptao define as atividades
necessrias para executar a adaptao da Norma para sua aplicao na
organizao ou em projetos.
Norma flexvel para as abordagens de engenharia de software envolvidas, sendo :
Utilizvel com com qualquer modelo de ciclo de vida (cascata, incremental, evolutivo, etc);
Utilizvel com qualquer mtodo ou tcnica de engenharia de software
(projeto orientado a objetos, tcnicas estruturadas, prototipao, etc);
Utilizvel com com quaisquer linguagens de programao
74
captulo 4
A Norma implementa os princpios da gerncia de qualidade. Ela os executa em

trs passos bsicos:
Integrao da Qualidade no Ciclo de Vida
Processo de Garantia da Qualidade
Processo de Melhoria
A Norma prov os requisitos para um conjunto compreensivo e integrado de
processos dentro de todo o ciclo de vida, onde cada processo construdo dentro do ciclo do PDCA (plan-do-check-act).
Trata todas as atividades relacionadas qualidade como uma parte integrante do ciclo de vida de software e tambm apropria essas atividades
para cada processo no ciclo de vida.
Com relao ao Processo de Garantia da Qualidade podemos dizer que:
O processo de garantia da qualidade dedicado a assumir a concordncia dos produtos e servios com seus requisitos contratuais.
Pessoas responsveis por este processo so investidas da necessria liberdade e autoridade organizacional.
Com relao ao Processo de Melhoria podemos afirmar que :
A Norma contm um processo de melhoria, em nvel de organizao e
corporao, para gerenciamento da qualidade de seus prprios processos estabelecidos.
No especifica o como implementar ou executar as atividades e tarefas.
No determina um modelo de ciclo de vida ou mtodo de desenvolvimento.
Deve ser adaptada de acordo com o organizao e projetos especficos.
ATIVIDADE
1. Comente as atividades da etapa de Ao do Ciclo PDCA.
2. Qual a proposta da fase de Estabelecimento do Modelo IDEAL?
captulo 4
75
3. Quais so as diretrizes da ISO 9000-3 ?

4. A Norma ISO 12207 est relacionada ao processo de ciclo de vida do software. Quais
as vantagens para e empresa em gerenciar os processo de software?
5. Em quais princpios se baseia a arquitetura da Norma ISO/IEC 12207?
REFLEXO
Estamos quase chegando ao final do nosso estudo sobre qualidade de sofware e, pudemos
perceber que, apesar da qualidade de software ser uma atividade relativamente nova dentro
do contexto do desenvolvimento de software, ela segue, desde o seu surgimento modelos
que j podemos considerar antigos e consolidados na literatura, como o PDCA e o IDEAL.
Os novos conceitos e normas relacionados qualidade de software caminham juntos e relacionando-se com os modelos de gesto de qualidade mais antigos, nos mostrando que nem
sempre existe um nico modelo ou um nica regra que vai suprir as necessidades de orientaes para a obteno da qualidade, seja de um produto ou de um processo de software.
LEITURA
Ciclo de Deming ou Ciclo PDCA
https://scsampaio.files.wordpress.com/2011/12/ciclo-de-deming-ou-ciclo-pdca.pdf
Processo de Melhoria Contnua de processos para a cmera dos deputados file:///C:/
Users/Mayb/Downloads/processo_melhoria_aires.pdf
Melhoria de Processos de Tecnologia da Informao Multi-Modelo
http://www.inf.ufg.br/mestrado/sites/www.inf.ufg.br.mestrado/files/uploads/Dissertacoes/
FabianaFreitas.pdf
Normas ISO: 12207 15504
http://olaria.ucpel.tche.br/venecian/lib/exe/fetch.php?media=qs_iso12207_15504.pdf
76
captulo 4
ROCHA, ANA REGINA CAVALCANTI; MALDONADO, JOS CARLOS; WEBER, KIVAL CHAVES. Qualidade de Software Teoria e Prtica. 1 edio. So Paulo: Prentice Hall, 2001.
2003.
NO PRXIMO CAPTULO
No ltimo captulo desse material, finalizando nosso assunto abordaremos alguns modelos
de qualidade de software, tais como o CMMI e o MPS. BR
captulo 4
77
5
Modelos de
Qualidade de
Processo de
Software
5 Modelos de Qualidade de Processo

de Software
Neste ltimo captulo da nossa disciplina de qualidade de software, iremos
comentar estrutura do Modelo SPICE, da Norma ISO/IEC 15504 e tambm da
transio do Modelo SPICE para a Norma ISO/IEC 155v04.
Fecharemos esse captulo e tambm nosso livro apresentado dois modelos
de grande importncia para a rea de qualidade de software, que so o CMMI
e o MPS.BR
OBJETIVOS

Conhecer o projeto SPICE (Software Process Improvement and Capability Determination) e a Norma ISO/IEC 15504
Apresentar a definio e estrutura modelos CMMI e MPS.BR
Proporcionar uma viso geral do processo de gerncia de risco
Compreender as atividades da gerncia de risco.
REFLEXO
Voc deve estar lembrado de quando comentamos no incio desse trabalho que a qualidade
de software pode ser analisada do ponto de vista de trs dimenses diferentes?
Pois bem, essas dimenses so a viso do usurio, do desenvolvedor e da empresa que
o comercializa.
Esse conceito nos mostra que a qualidade do software necessita ser bastante abrangente
para poder agradar a estas trs vises, que so sempre to exigentes.
Para sabermos que o software agrada a essas trs vises o mesmo precisa ser medido.
Concordam que eu no posso dizer se o software tem qualidade ou no se eu no realizar
uma avaliao no mesmo?
Nesse nosso ltimo captulo compreenderemos o funcionamento de alguns modelos que
nos ajudam a realizar essa avaliao e consequentemente fazermos as melhorias onde forem
necessrias! So esses, o SPICE, o CMMI e o MPS.BR
80
captulo 5
5.1 SPICE (Software Process Improvement

and Capability Determination)
O projeto SPICE (Software Process Improvement and Capability dEtermination) surgiu quando o grupo ISO se reuniu buscando estabelecer um padro
para a avaliao do processo de software, pois constatou a deficincia da Norma ISO 9001 em relao ao setor de software e a existncia de vrios modelos.
Criado em 1993, o projeto SPICE tinha como objetivo gerar normas que avaliassem os processos de software e, em 1995, o projeto foi concludo gerando a primeira verso. Em 1998, foi publicado o ISO/IEC TR 15504: Information Technology
Software Process Assessment (Tecnologia da Informao Avaliao de Processos
de Softwate), como Relatrio Tcnico, que durante trs anos foi submetido a uma
reviso com o objetivo de se transformar em uma Norma Internacional.
ATENO
importante comentar aqui que o Modelo SPICE pode ser utilizado tanto em organizaes
que desenvolvem software visando melhoria dos processos de produo, como tambm em
organizaes que adquirem esse software visando avaliar seus fornecedores em relao ao
seu perfil de capacidade.
Este modelo constitui de um conjunto padronizado de processos fundamentais e define seis
nveis de capacidade para cada um desses processos, que esto descritos em sua estrutura.
Para gerenciar a utilizao das vrias verses da Norma ISO 15504, foram
realizados os projetos SPICE Trials, que so diversos testes prticos baseados
no modelo com o objetivo de investigar a consistncia do mesmo. Na Fase 1 e
Fase 2 foram acompanhadas 105 avaliaes de processos de software em organizaes de diversas partes do mundo, e na Fase 3, foram acompanhadas outras avaliaes tendo como referncia o Relatrio Tcnico (ISO/IEC TR 15504).
Alm disso, esses testes consolidaram um dos objetivos do projeto SPICE, que
disponibilizar um mtodo de avaliao que possibilitasse a comparao dos
resultados obtidos na avaliao com o uso de outros modelos.
O SPICE um modelo contnuo, ou seja, define nveis de maturidade para
determinados processos de acordo com diferentes caractersticas e o usurio
determina sobre qual nvel de maturidade o processo ser avaliado.
captulo 5
81
A avaliao pode ser realizada no contexto de melhoria contnua, identificando as oportunidades de melhoria dos processos de uma organizao, ou
para determinao da capacidade de processo, determinando a conformidade
dos processos de uma organizao em relao a requisitos ou contratos.
5.1.1 Estrutura do Modelo Spice
O projeto SPICE est organizado em nove partes, onde apenas trs partes so
normativas e as demais so somente informativas, conforme descritas a seguir:
Parte 1 (informativa): Conceitos e Guia Introdutrio
Esta parte descreve como interagem as partes do Modelo SPICE e fornece
orientao para a sua seleo e utilizao.
Parte 2 (normativa): Um Modelo de Referncia para Processos e Capacitao de Processos
A parte 2 define um modelo de referncia bidimensional usado como base
para a avaliao e descreve quais atividades fundamentais so exigidas
para uma boa engenharia de software, mas no descrevem como implement-las. Nessa parte esto descritos quarenta processos e componentes de processos organizados em cinco categorias (Cliente-Fornecedor,
Suporte, Engenharia, Gerncia e Organizao). Esses processos so um
superconjunto dos processos que esto descritos na ISO/IEC 12207. Cada
processo descrito na parte 2 basicamente por um nome, o propsito e
como reconhecer uma implementao com sucesso (Weber,et.al,2001).
O modelo compreende duas dimenses (dimenso de processo e dimenso da capacidade do processo) que admite agregar nveis de maturidade
a qualquer etapa do processo de desenvolvimento de um software.
Dimenso do processo: caracteriza o propsito dos processos relacionados ao conjunto de atividades do ciclo de vida do software e dividida em
trs agrupamentos.
Processos Fundamentais: definem as atividades do ciclo de desenvolvimento do software, composto pelas categorias: Cliente-Fornecedor e
Engenharia;
82
captulo 5
Processos Organizacionais: definem as atividades que a organizao devem executar, composto pelas categorias: Gerncia e Organizao;
Processos de Apoio: definem as atividades para garantir a qualidade do
projeto de software, composto pela categoria: Suporte.
Processos de Engenharia: abrange os processos relacionados ao desenvolvimento e manuteno do software especificando, implementando
ou mantendo o produto de software e a sua documentao para o cliente.
Processos de Suporte: consiste nos processos de apoio ou suporte que
podem ser empregados por qualquer outro processo durante o ciclo de
vida do software.
Processos de Gerncia: consiste em processos que contm prticas que
podem ser utilizadas por quem administra qualquer processo ou projeto
dentro do ciclo de vida de desenvolvimento de software.
Processos Organizacionais: consiste em estabelecer objetivos tanto de
negcio como de recursos humanos da organizao, abrange processos
relacionados s atividades gerais de uma organizao, que ajudam a alcanar esses objetivos.
Dimenso da Capacidade do Processo: define os nveis do processo em
uma escala de medida de seis pontos que podem ser utilizados como
base na avaliao da execuo de um processo de uma organizao, e
como guia para a melhoria da execuo. Cada nvel de capacidade descrito na parte 2 basicamente por um nome, definio e atributos (Weber
et.al,2001). Os nveis so apresentados a seguir:
Nvel 0 Incompleto: processo no implementado ou no atinge
seus objetivos.
Nvel 1 Executado: processo implementado atingindo seus objetivos, mas de forma pouco planejada ou rigorosa, sem padro de qualidade e sem controle de prazo e custo.
captulo 5
83
Nvel 2 Gerenciado: processo anterior executado e gerenciado,

isto , planejado, controlado, acompanhado, verificado e corrigido,
estando em conformidade a padres e requisitos estabelecidos (qualidade, prazo e custo).
Nvel 3 Estabelecido: processo anterior executado e gerenciado
com base nos princpios de uma boa engenharia de software, de forma eficaz e eficiente.
Nvel 4 Previsvel: processo anterior executado dentro dos limites de controle estabelecido para atingir os objetivos definidos do
processo e com medies detalhadas de desempenho, que so analisadas chegando a um entendimento quantitativo da capacidade do
processo e a uma execuo gerenciada quantitativamente.
Nvel 5 - Em otimizao: processo anterior alterado e adaptado continuamente, visando satisfazer os objetivos do negcio da organizao, estabelecendo metas quantitativas de eficincia e eficcia para
o desempenho do processo.
Os atributos do processo so medidos em uma escala de porcentagem que
define o grau de satisfao da capacidade dos mesmos, detalhando os aspectos
de um determinado processo, conforme a apresentado na tabela 5.1
AVALIAO
PORCENTAGEM
DESCRIO
Existe pouca ou nenhuma evidncia que
N: No Realizado
0% a 15%
permite concluir que o processo avaliado

satisfaa os objetivos dos atributos.
P: Parcialmente
Realizado
84
captulo 5
Existem evidncias de uma abordagem

16% a 50%
sistemtica para a realizao do atributo

no processo avaliado.
AVALIAO
L: Largamente
Realizado
F: Totalmente
Realizado
PORCENTAGEM
DESCRIO
51% a 85%
sistemtica para a realizao significativa

do atributo no processo avaliado.
86% a 100%
sistemtica e completa para a realizao

total do atributo no processo avaliado.
Tabela 5.1 Escala de Porcentagem do Atributo (ISO SPICE, 2005)
Para estar em um nvel de capacidade, um processo tem que ter todos os

atributos de processo dos nveis anteriores totalmente atendidos (nota F) e os
atributos do nvel em que ele se encontra tem que ser, no mnimo, largamente
atendidos (notas L ou F) (Crtes & Chiossi, 2001).
Parte 3 (normativa): Executando uma Avaliao
Esta parte descreve os requisitos bsicos para se realizar uma avaliao,
visando atingir resultados repetveis, confiveis e consistentes. Os requisitos para a avaliao so (Sanches, 2003):
Definio da Entrada da Avaliao: definida antes da coleta de dados de uma avaliao e de ser aprovada pelo patrocinador da mesma, esta deve especificar: o patrocinador, o objetivo e as restries
da avaliao, o modelo a ser usado com a avaliao, os assessores, o
pessoal de apoio, os critrios de competncia do avaliador e dados
que possam apoiar a melhoria do processo.
Responsabilidades: do patrocinador, que verificar a competncia
do avaliador, e do assessor, que confirmar o comprometimento do
patrocinador com a avaliao, garantir que os participantes estejam
cientes sobre o objetivo da avaliao e que esta seja conduzida em
conformidade aos requisitos da norma, e documentar os requisitos
encontrados na concluso da avaliao.
captulo 5
85
Processo de Avaliao: a avaliao dever ser conduzida em conformidade com um processo documentado que cumpre o objetivo da avaliao.
Registro de Sada da Avaliao: os dados referentes avaliao, que
auxiliaro na compreenso dos resultados obtidos, devero ser includos no registro de avaliao, guardado pelo patrocinador, e este
deve conter a data e a entrada da avaliao, a identificao dos objetivos e de dados adicionais coletados que foram reconhecidos na
sada da avaliao para melhoria ou determinao da capacidade do
processo, a abordagem de avaliao empregada, e o conjunto de representaes de processo resultante da avaliao.
Parte 4 (informativa): Guia de Orientao para a Conduo de uma Avaliao

A parte 4 descreve orientaes para a realizao de uma avaliao de processo de software, esclarecendo os requisitos da Parte 2 e da Parte 3 para
avaliaes em diferentes contextos. Este guia fornece orientao para seleo e uso de um Modelo Compatvel e de um Processo de Avaliao Documentado, e seleo de instrumentos e ferramentas que auxiliaro no
apoio a coleta, registro, processamento, anlise e apresentao de dados.
Parte 5 (informativa): Um Modelo de Avaliao e Guia de Indicadores
Esta parte descreve um modelo para auxiliar a realizao de uma avaliao de processo de software compatvel ao Modelo de Referncia da Parte
2, e um guia de boas prticas de Engenharia de Software que visam complementar o Modelo.
Parte 6 (informativa): Guia para Competncia de Avaliadores
A parte 6 descreve a competncia, formao, treinamento e experincia
dos avaliadores que so fundamentais para a execuo da avaliao de
processos. Esta parte fornece mecanismos que podem ser utilizados com
o objetivo de comprovar a competncia e validar a formao, treinamento
e experincia dos avaliadores.
Parte 7 (informativa): Guia de Orientao para Melhoria de Processo
Essa parte descreve como definir as entradas para a execuo de uma avaliao e como utilizar os resultados obtidos visando a melhoria do processo.
86
captulo 5
Visando a melhoria do processo, uma organizao define um mtodo

para a escolha dos processos que esto descritos na parte 2 do Modelo
SPICE, que parte de uma abordagem para a melhoria da organizao.
Parte 8 (informativa): Um Modelo de Avaliao e Guia de Indicadores
A parte 8 descreve como definir as entradas para a execuo de uma avaliao e como utilizar os resultados obtidos visando a determinao da
capacidade do processo. Esta parte auxilia a organizao em identificar
os pontos fortes e fracos associados ao desenvolvimento de processos, e
os riscos de firmar um contrato com um fornecedor. A determinao da
capacidade de um processo fundamental por obter informaes que
auxiliam na tomada de decises, e pode ser realizado pelo adquirente (na
seleo do fornecedor) e pelos fornecedores (na deciso de um contrato
avaliando seus prprios processos e analisando seus riscos envolvidos).
Parte 9 (normativa): Vocabulrio
A parte 9 define todos os termos, em ordem alfabtica, usados por todas
as partes que compem o modelo.
5.2 Transio para a Norma ISO/IEC 15504

Publicada em 1998, como um Relatrio Tcnico do Tipo 2, a ISO/IEC TR 15504:
Information Technology Software Process Assessment (Tecnologia da Informao Avaliao de Processos de Softwate) foi submetido a uma reviso durante
trs anos, com o objetivo de se transformar em uma Norma Internacional. Atualmente, tem-se a nova Norma ISO/IEC 15504 como padro para a avaliao
de processos, que visa a melhoria contnua e determinao da capacidade dos
processos de uma organizao.
As principais alteraes que ocorreram do Projeto SPICE para nova estrutura da Norma ISO/IEC 15504 foram:
Reduo do nmero de partes, de nove para cinco partes, sendo apenas as partes 1 e 2 normativas e as demais informativas:
Parte 1: Conceitos e Vocabulrio (baseada nas partes 1 e 9 do SPICE);
Parte 2: Realizao de uma Avaliao (baseada nas partes 2 e 3
do SPICE);
captulo 5
87
Parte 3: Guia para a Realizao de uma Avaliao (baseada nas partes 4 e 6 do SPICE);
Parte 4: Guia para a Utilizao dos Resultados de uma Avaliao
(baseada nas partes 7 e 8 do SPICE);
Parte 5: Um Exemplo de Modelo de Avaliao de Processos (baseada na parte 5 do SPICE).
Compatibilizao com a Norma ISO/IEC 12207, visto que h muita superposio entre a dimenso de processos do ISO/IEC TR 15504 e da ISO/IEC 12207, o
que provoca a duplicao de esforos, inconsistncias e dificuldade na utilizao
da descrio de processos da ISO/IEC 12207 que contm conceito de capacidade
embutido. Para solucionar esses problemas, a dimenso de processos foi removida da ISO/IEC 15504, se tornando um anexo da Norma ISO/IEC 12207 publicada como AMD1 e AMD2, e permitindo a ISO/IEC 15504 utilizar qualquer Modelo
Compatvel de descrio de processo como Modelo de Referncia. Sendo assim,
a ISO/IEC 15504 ser uma Norma para avaliao da capacidade de processos.
O maior benefcio dessas alteraes est na abordagem comum de avaliao,
no sendo mais restringida aos processos do ciclo de vida do software, e sim, podendo ser executada em qualquer tipo de processo em qualquer domnio.
CONCEITO
Atualmente, a Dimenso do Processo definida por um Modelo de Referncia externo
ISO/IEC 15504 e serve como base para o Modelo de Avaliao de Processo.
5.3 Modelo CMMI (Capability Maturity Model)

O CMMI (Capability Maturity Model Integration) foi criado pelo SEI (Software
Engineering Institute), o qual um rgo integrante da universidade norte-americana Carnegie Mellon. Trata-se de um modelo que est atualmente na verso
1.3 (Janeiro/2013), com um enfoque voltado para a capacidade de maturidade
de processos de software.
O CMMI est dividido em 5 nveis de maturidade que atestam, por sua vez,
o grau de evoluo em que uma organizao se encontra num determinado momento. Alm disso, tem por objetivo principal funcionar como um guia para
88
captulo 5
a melhoria dos processos da organizao, considerando para isto atividades

como o gerenciamento do desenvolvimento de software, prazos e custos previamente estabelecidos. O objetivo maior, considerando o CMMI e seus diferentes conceitos, est justamente na produo de software com maior qualidade e
menos propenso a erros. Para se conseguir o que este modelo prope, a organizao interessada na implantao do CMMI dever evoluir progressivamente,
considerando para isto uma sucesso de diferentes de nveis. Cada nvel indica,
por sua vez, o grau de maturidade dos processos num determinado instante:
Nvel 1 - Inicial: os processos normalmente esto envoltos num caos decorrente da no obedincia ou ainda, inexistncia de padres;
Nvel 2 - Gerenciado: os projetos tm seus requisitos gerenciados neste
ponto. Alm disso, h o planejamento, a medio e o controle dos diferentes processos;
Nvel 3 - Definido: os processos j esto claramente definidos e so compreendidos dentro da organizao. Os procedimentos se encontram padronizados, alm de ser preciso prever sua aplicao em diferentes projetos;
Nvel 4 - Gerenciado Quantitativamente: ocorre o aumento da previsibilidade do desempenho de diferentes processos, uma vez que os mesmos
j so controlados quantitativamente;
Nvel 5 - Otimizado: existe uma melhoria contnua dos processos.
CONEXO
Maiores informaes sobre o modelo CMMI podem ser obtidas atravs do seguinte link:
http://www.sei.cmu.edu/cmmi/
5.4 Modelo Mps.Br

O MPS.BR ou Melhoria de Processos do Software Brasileiro, simultaneamente
um movimento para a melhoria e um modelo de qualidade de processo voltada
para a realidade do mercado de pequenas e mdias empresas de desenvolvimento de software no Brasil.
captulo 5
89
Ele baseado noCMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na

realidade do mercado brasileiro. No Brasil, uma das principais vantagens do
modelo seu custo reduzido de certificao em relao s normas estrangeiras,
sendo ideal para micro, pequenas e mdias empresas.
Um dos objetivos do projeto replicar o modelo na Amrica Latina, incluindo o Chile,Argentina, Costa Rica, Peru e Uruguai.
O projeto tem apoio do Ministrio de Cincia e Tecnologia, do FINEP e do
Banco Interamericano de Desenvolvimento. No Brasil o projeto desenvolvido
pelo Softex, pelo governo e por universidades.
Os nveis de maturidade estabelecem patamares de evoluo de processos,caracterizando estgios de melhoria da implementao de processos na organizao.
O MR-MPS define sete nveis de maturidade: A (Em Otimizao),B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado).
O progresso e o alcance de um determinado nvel de maturidade MPS se obtm quando so atendidos os propsitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nvel.
50 A diviso em estgios, embora baseada nos nveis de maturidade do CMMI-SE/
SW tem uma graduao diferente, com o objetivo de possibilitar uma implementao e avaliao mais adequada s micros, pequenas e mdias empresas.
A capacidade do processo representada por um conjunto de atributos de
processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalizao com que o processo
executado na organizao.
O atendimento aos atributos do processo (AP), atravs do atendimento aos
resultados esperados dos atributos do processo (RAP) requerido paratodos
os processos no nvel correspondente ao nvel de maturidade, embora eles no
sejam detalhados dentro de cada processo.
LEITURA
Para saber mais sobre o modelo MPS.BR acesse o artigo: Comparando CMMi x MPS. BR:
As Vantagens e Desvantagens dos Modelos de Qualidade no Brasil. Disponvel em:
http://www.camilaoliveira.net/Arquivos/Comparando%20CMMi%20x%20MPS.pdf
90
captulo 5
Os nveis so acumulativos, ou seja, se a organizao est no nvel F, esta

possui o nvel de capacidade do nvel F que inclui os atributos de processo dos
nveis G e F para todos os processos relacionados no nvel de maturidade F (que
tambm inclui os processos de nvel G). Isto significa que, ao passar do nvel G
para o nvel F,os processos do nvel de maturidade G passam a ser executados
no nvel decapacidade correspondente ao nvel F.
5.5 Gerncia de Riscos na Qualidade de Software

Existem vrias modelos que auxiliam o processo de gerenciamento de riscos.
Alguns desses modelos so PMBOK, RUP, CMMI, ISO, entre outros.
Riscos so eventos que podem ocorrer no futuro e se concretizados, afetam
o projeto de software. Os fatores relacionados ao risco so: o evento ou fato que
caracteriza o risco, a probabilidade de que ele ir ocorrer (possibilidade) e a
perda resultante de sua ocorrncia (conseqncia).
O risco caracteriza-se pela incerteza (o evento que caracteriza o risco pode ou
no ocorrer) e perda (se o evento ocorrer, conseqncias inesperadas ou perdas
iro ocorrer). Ele faz parte de qualquer atividade, no podendo ser eliminado.
Alm disso, no possvel conhecer todos os riscos de um projeto de software.
As atividades associadas ao risco podem ser divididas em: gerenciais e tcnicas. As atividades gerenciais so responsveis peloplanejamento, organizao, seleo de pessoas, controle, direo, garantia da qualidade e gerncia da
configurao. Esta atividade est influencia diretamente o projeto e ao processo. J as atividades tcnicas englobam a anlise de requisitos, projeto, cdigo e
teste. Esta atividade influencia tanto o produto quanto o processo.
Riscos associados ao projeto so problemas relacionados a aspectos operacionais, organizacionais e contratuais do projeto (restries de recursos, interfaces externas, relacionamento com fornecedores, restries de contrato e falta
de suporte organizacional). Os riscos mais significativos em relao ao processo so planejamento (gerencial) e processo de desenvolvimento (tcnico)
O produto est relacionado atividade tcnica atravs da estabilidade dos
requisitos (requisitos so percebidos como flexveis, o que dificulta a gerncia
de riscos), desempenho, complexidade do cdigo, especificao dos testes. Os
riscos mais significativos so ligados aos requisitos.
Para um bom gerenciamento dos riscos de um projeto de software faz-se
necessrio a execuo das seguintes atividades:
captulo 5
91
Identificar: produzir uma lista dos riscos que podem vir a comprometer
o resultado esperado.
Os riscos podem ser genricos (ameaam qualquer projeto) ou especficos
do projeto. Para identificar os riscos especficos necessrio entender a
tecnologia, a equipe e o ambiente do projeto, examinar o plano do projeto
e o escopo do sistema e responder aseguinte pergunta: que caractersticas especiais este sistema possui que podem ameaar o plano do projeto?
Analisar: Avaliar a probabilidade da perda e a magnitude da perda, associada com cada item de risco e com a possvel composio desses riscos.
Planejar: definir aes para enderear cada item de risco, priorizar as
aes e criar um plano integrado de gerncia de riscos. O planejamento
pode ter vrios objetivos:
Atenuar o risco.
Evitar o risco modificando o projeto do produto ou o processo de
desenvolvimento.
Transferir o risco.
Aceitar o risco e as conseqncias, caso o evento ocorra.
Fazer um estudo futuro do risco para obter mais informaes e
compreender melhor as caractersticas do risco.
Monitorar: acompanhar o status do risco e das aes executadas
Resolver: executar as aes planejadas e reportar os resultados da resoluo do risco.
Comunicar: prover informaes para e entre entidades e nveis organizacionais envolvidos no projeto. Inclui nveis dentro do projeto, da organizao, da organizao do cliente e a comunicao entre desenvolvedor,
cliente e usurio.
5.5.1 Um Processo para Gerenciamento de Riscos
O risco nos projetos de software pode ser gerenciado atravs das seguintes atividades:
92
captulo 5
identificao dos riscos,

anlise dos riscos,
planejamento dos riscos,
acompanhamento dos riscos e
resoluo dos riscos.
O processo comea com a identificao dos riscos. Tudo o que se referir a

incerteza, experincias anteriores, preocupaes e questes a resolver pode ser
til na identificao dos riscos. Vrias fontes podem ser utilizadas nesta fase:
pessoas incluem clientes, integrantes da equipe, organizaes
envolvidas, disponibilidade, capacidade, experincia, etc.;
os produtos e processos abrangem requisitos, prazos, estimativas, receitas, despesas, oramento, restries de natureza legal,
estilo de gerenciamento, tamanho e escopo do projeto, etc.;
a tecnologia inclui mudanas, inovao, adoo e uso, integrao
e interfaces, experincia especfica, segurana, arquitetura, escalabilidade, etc.
Uma Avaliao de Riscos (Risk Assessment) deve ser conduzida a fim de identificar e registrar sistematicamente os riscos do projeto. Entrevistas, reunies,
pesquisas e listas de verificao (checklists) so instrumentos teis na conduo de uma Avaliao de Riscos.
O Software Engineering Institute (SEI) oferece uma categorizao de riscos
muito til nesta rea , onde a anlise dos riscos iniciada agrupando-se os riscos de mesma natureza, ou semelhantes.
importante determinar os fatores atuantes sobre os riscos, isto , as variveis que fazem a probabilidade de ocorrncia ou o impacto (valor da perda) dos
riscos flutuarem. Tambm devem ser determinadas as fontes de risco, ou seja,
as respectivas causas, normalmente descobertas respondendo-se pergunta
Por qu? com relao a cada risco identificado.
Em seguida, deve-se calcular a exposio referente a cada risco, definida
como o produto da probabilidade de ocorrncia do risco pelo respectivo impacto. A exposio utilizada na priorizao dos riscos.
captulo 5
93
O planejamento dos riscos inclui a definio de cenrios para os riscos mais

importantes, a definio de alternativas de soluo para esses cenrios, a escolha das alternativas mais adequadas, o desenvolvimento de um Plano de Ao de
Riscos, assim como o estabelecimento de limiares ou disparadores para a ao.
O acompanhamento dos riscos envolve a monitorao dos cenrios de riscos, a verificao de que os limiares foram ou no atingidos, bem como a anlise das medidas e indicadores referentes aos riscos.
A resoluo dos riscos inclui a resposta aos eventos disparadores, a execuo do Plano de Ao de Riscos, o acompanhamento da execuo do plano e as
eventuais correes de desvios.
A seguir apresentamos algumas atividades a serem resolvidas com o intuito
de fixar os conhecimentos aprendidos nesse captulo.
ATIVIDADE
1.
O Modelo SPICE possui 9 partes. Na segunda parte encontra-se o um Um Modelo de Referncia para Processos e Capacitao de Processos e, nesse modelo so definidos quatro
tipos de processos, comente cada uma deles.
2. Explique as principais alteraes que aconteceram na transio do Modelo SPICE para

a Norma ISO/IEC 15504.
3.
As principais alteraes que ocorreram do Projeto SPICE para nova estrutura da Norma
ISO/IEC 15504 foram:
4. O CMMI est dividido em 5 nveis de maturidade que atestam o grau de evoluo em

que uma organizao. Comente o que lembra de cada um desses nveis.
5. Voc se lembra se o MPS.BR possui alguma vantagem para o mercado brasileiro com
relao aos outros modelos vistos?
REFLEXO
Nosso material termina por aqui, apresentando a Norma ISO/IEC 15505, os Modelos SPICE,
CMMI e MPS.BR, mas voc ainda possui um amplo universo de informaes importantes
94
captulo 5
sobre a qualidade de software e seus modelos de melhoria. Espero que tenha apreciado o
assunto e que o mesmo lhe seja til na sua vida profissional!
Continue se atualizando, a qualidade de software ainda uma rea recente e sempre podemos contar com mais informaes e estudos de caso para nossa aprimorar nossa formao.
LEITURA
Padres de Qualidade de Software MPS Br x CMMI e a realidade Brasileira.
http://www.2xt.com.br/gerencia-de-requisitos-em-processos-de-desenvolvimento-desoftware/
Principais diferenas entre o MPS.BR e o CMMI
http://longhigh.wordpress.com/2008/05/15/principais-diferencas-entre-o-mps-br-e-ocmmi/
Projetos da CE-21-007-10 e Novidades da ISO/IEC 15504 (SPICE)
http://www.softwarepublico.gov.br/file/17039869/apresISO-IEC-15504-Clenio-40minv1p2-ABNT2009.pdf
Arquitetura da ISO/IEC 15504
http://www.micpm.com/hdk/manuais/MiCPManuaisManuais_103.html
(CHARETTE,1989) R. N. Software Engineering Risk Analysis and Management, McGraw-Hill/Intertext, 1989.
(CMMI, 2014)CMMI- Capability Maturity Model, disponvel em: http://cmmiinstitute.
com/assets/CMMI-DEV_1-2_Portuguese.pdfISO
(CMMI:2000) CMMI Model Componentes Derived from CMMI SE/SW, Version 1.0
Technical report CMU/SEI-00-TR24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000.
captulo 5
95
(ISO, 2014) International Organization for Standardization. Disponvel em: http://

www.iso.org
(PDUA, 2005) Wilson de Pdua Paula. Engenharia de software: fundamentos, mtodos
e padres. 3 ed. Rio de Janeiro: LTC, 2005.
(PRESSMAN, 1997)Roger S. Pressman, Engenharia de Software, Makron Books, McGraw-Hill, 1997
(Softex, 2012D) Associao Para Promoo Da Excelncia Do Software Brasileiro Softex. MPS.BR Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS-SW:2012 em Conjunto com o CMMI-DEV v1.3, Disponvel em: www.softex.br.
(Wikipdia, 2014) A enciclopdia livre. Disponvel em: http://www.wikipedia.org
EXERCCIO RESOLVIDO
Captulo 1
1. Defina qualidade de software.
Qualidade de software possui vrias definies, vejamos algumas:
Qualidade de software a conformidade a requisitos funcionais e de desempenho
que foram explicitamente declarados, a padres de desenvolvimento claramente documentados, e a caractersticas implcitas que so esperadas de todo software desenvolvido por profissionais.
Um produto de software apresenta qualidade dependendo do grau de satisfao das
necessidades dos clientes sob todos os aspectos do produto.
Qualidade a totalidade de caractersticas e critrios de um produto ou servio que
exercem suas habilidades para satisfazer as necessidades declaradas ou envolvidas.
Qualidade a totalidade das caractersticas de uma entidade, que lhe confere a capa-
96
captulo 5
cidade de satisfazer necessidades explcitas e implcitas.

2. Defina processo de software e comente as caractersticas de um bom processo de software.
Um processo de software pode ser definido como um conjunto de atividades, mtodos,
prticas e transformaes que as pessoas usam para desenvolver e manter o software e
os produtos associados (por exemplo: planos de projeto, documentos, cdigo, casos de
teste e manuais de usurio).
Um processo de software envolve um grande conjunto de elementos, tais como objetivos organizacionais, polticas, pessoas, comprometimentos, ferramentas, mtodos, atividades de apoio e as tarefas da engenharia de software. Para que o processo de software
seja eficiente ele precisa ser constantemente avaliado, medido e controlado. Quando o
processo eficiente ele possui as seguintes caractersticas:
O processo continua a despeito de problemas inesperados (Robustez).
Rapidez na produo do sistema (Velocidade).
O processo aceito por todos os envolvidos nele (Aceitabilidade)
Os erros do processo so descobertos antes que resultem em erros no produto (Confiabilidade)
O processo evolui para atender alteraes de necessidades organizacionais (Manutenibilidade)
O processo compreendido (usualmente atravs de documentao e de treinamento), utilizado, vivo e ativo.
O processo bem controlado a fidelidade ao processo objeto de auditoria e de
controle.
Medidas do produto e do processo so utilizadas,
Os papis e responsabilidades no processo esto claros ao longo de todo o projeto e
por toda a organizao
captulo 5
97
3. Comente sobre a categorizao das mtricas.

Com relao categorizao das mtricas de software podemos citar:
Mtricas diretas (fundamentais ou bsicas): medida realizada em termos de atributos
observados (usualmente determinada pela contagem). Ex.: custo, esforo, n linhas
de cdigo, capacidade de memria, n pginas, n diagramas, etc.
Mtricas indiretas (derivadas): medidas obtidas a partir de outras mtricas. Ex.: complexidade, eficincia, confiabilidade, facilidade de manuteno.
Mtricas orientadas a tamanho: so medidas diretas do tamanho dos artefatos de
software associados ao processo por meio do qual o software desenvolvido. Ex.:
esforo, custo, no. KLOC, n pginas de documentao, no. Erros.
Mtricas orientadas por funo: consiste em um mtodo para medio de software
do ponto de vista do usurio, determinando de forma consistente o tamanho e a
complexidade de um software.
Mtricas de produtividade: concentram-se na sada do processo de engenharia de
software. Ex.: n de casos de uso/iterao.
Mtricas de qualidade: Oferecem uma indicao de quanto o software se adequa s
exigncias implcitas e explcitas do cliente. Ex.: erros/fase.
Mtricas tcnicas: concentram-se nas caractersticas do software e no no processo
por meio do qual o software foi desenvolvido. Ex.: complexidade lgica e grau de
manutenibilidade.
4. Quando falamos de revises de software, o que importante que o engenheiro considere no planejamento?
Devem ser consideradas as seguintes questes:
quem participa?
qual informao requerida antes da reviso?
quais pr-condies que devem ser satisfeitas antes que a reviso possa ser conduzida?
Como Organizar?
Gerar checklists ou outra indicao do que deve ser coberto na reviso;
98
captulo 5
Determinar as condies de trmino ou critrios que devem ser satisfeitos para que
a reviso termine;
Gerar registros e documentos que devem ser produzidos.
Captulo 2
1. Comente algumas vantagens da realizao da garantia de qualidade de
software.
Alguns aspectos positivos da garantia de qualidade de software que podemos mencionar so:
o software ter menos defeitos latentes resultando em reduo do esforo e do tempo gasto durante as atividades de teste e manuteno
a maior confiabilidade resultar em maior satisfao do cliente
os custos de manuteno podem ser reduzidos
o custo do ciclo de vida global do software reduzido
2. Explique as subcaractersticas da caracterstica FUNCIONALIDADE da norma ISO 9126.

Funcionalidade: capacidade do produto de software de prover funes que atendam
s necessidades explcitas e implcitas, quando o software estiver sendo utilizado sob
condies especficas.
Adequao: capacidade do produto de software de prover um conjunto apropriado de
funes para tarefas e objetivos do usurio especificados.
Acurcia: capacidade do produto de software de prover, com o grau de preciso necessrio, resultados ou efeitos corretos ou conforme acordados.
Interoperabilidade: capacidade do produto de software de interagir com um ou mais
sistemas especificados.
Segurana de Acesso: capacidade do produto de software de proteger informaes
e dados, de forma que pessoas ou sistemas no autorizados no possam l-los nem
modific-los e que no seja negado o acesso s pessoas ou sistemas autorizados.
captulo 5
99
Conformidade: capacidade do produto de software de estar de acordo com normas,

convenes ou regulamentaes previstas em leis e prescries similares relacionadas funcionalidade.
3. O que um pacote de software? D alguns exemplos.
Pacote de Software: trata-se de um produto de software que envolve um conjunto completo e documentado de programas fornecidos a diversos usurios para uma aplicao
ou funo genrica.
Um Pacote de Software envolve todos os componentes do produto disponveis aos usurios, tais como documentao, manual de instrues e guia para instalao.
Exemplos: Processadores de Texto, Planilhas Eletrnicas, Gerenciadores de Banco de
Dados, Software Grficos, Programas para Funes Tcnicas ou Cientficas e Programas Utilitrios
4. Quais so os pr-requisitos de testes da norma ISO 12119?
Os pr-requisitos de teste so:
Presena de itens de produto,
Presena do sistema necessrio e,
Treinamento (se mencionado na descrio do produto)
5. O que deve ser testado de acordo com a norma ISO 12119?
As atividades de teste consistem em testar se esto de acordo com os requisitos de
qualidade:
Descrio do produto
Documentao do usurio
Programas e dados
Captulo 3
1. Comente uma das vantagens de se usar a Norma ISO 9241?
Esclarecer os benefcios de medir usabilidade em termos de desempenho e satisfao do usurio, lembrando sempre que a usabilidade dos computadores depende do
contexto de uso e que o nvel de usabilidade alcanado depender das circunstncias
especficas nas quais o produto usado.
100
captulo 5
2. Como a ISO 9241-11 redefine usabilidade?

Como a capacidade de um produto ser usada por usurios especficos para atingir objetivos especficos com eficcia, eficincia e satisfao em um contexto especfico de uso.
3. De acordo com a ISO 14598, o que significa avaliar a qualidade de um produto de software?
Significa verificar, atravs de tcnicas e atividades operacionais, o quanto os requisitos
so atendidos. - Tais requisitos, de uma maneira geral, expressam as necessidades explicitadas em termos quantitativos ou qualitativos e apresentam como objetivo a definio
das caractersticas de um software, a fim de permitir o exame de seu entendimento.
4. Voc se lembra de quantas e quais so as partes da ISO/IEC 9241? So
vrias, mas faa um esforo.
A ISO/IEC 9241 dividida em 14 partes, a saber:
Parte 1: Introduo Geral
Parte 2: Orientaes sobre requisitos da tarefa
Parte 3: Requisitos para apresentao visual
Parte 4: Requisitos para teclado
Parte 5: Requisitos posturais e de layout para posto de trabalho
Parte 6: Requisitos para ambiente
Parte 7: Requisitos para monitores quanto reflexo
Parte 8: Requisitos para apresentao de cores
Parte 9: Requisitos para outros dispositivos de entrada que no o teclado
Parte 10: Princpios de dilogo
Parte 11: Orientaes sobre usabilidade
Parte 12: Apresentao da informao
Parte 13: Orientaes ao usurio
Parte 14: Dilogos por menu
Captulo 4
1. Comente as atividades da etapa de Ao do Ciclo PDCA.
Consiste em atuar no processo em funo dos resultados obtidos. Se o sucesso
obtido em uma escala menor, pode significar que a mudana pode fazer parte das atividades da organizao, envolvendo outras pessoas, outros departamentos, fornecedores
e clientes afetados pelas mudanas. O envolvimento de outras pessoas importante
para ajudar na implementao das mudanas numa escala maior, ou mesmo para a
captulo 5
101
conscientizao dos novos benefcios que podem adquirir com as mudanas. Existem
duas formas de atuao possveis:
adotar o plano como padro, caso a meta tenha sido alcanada
agir sobre as causas que no permitiram que as metas sejam efetivas.
2. Qual a proposta da fase de Estabelecimento do Modelo IDEAL?
A proposta dessa fase definir prioridades para as alteraes, desenvolver uma estratgia para realizao do trabalho, identificar recursos disponveis e desenvolver um
plano de implementao detalhado, o qual contm horrios, tarefas, pontos de deciso,
recursos, responsabilidades, estratgias de risco e qualquer outro elemento requerido
pela organizao.
3. Quais so as diretrizes da ISO 9000-3?
As diretrizes so divididas em 3, a saber:
Estrutura descreve aspectos organizacionais relacionados ao sistema de qualidade.
Atividades do ciclo de vida: descreve atividades de desenvolvimento de software.
Atividades de suporte: descreve atividades que apoiam as atividades do ciclo de vida.
4. A Norma ISO 12207 est relacionada ao processo de ciclo de vida do software.
Quais as vantagens para e empresa em gerenciar os processos de software?
Podemos citar as seguintes vantagens:
Alinha estrategicamente a organizao.
Foca a organizao no cliente.
Obriga a organizao a prestar contas pelo desempenho dos seus processos.
Alinha a fora de trabalho com os processos.
Evidencia a necessidade de alocao de recursos.
Melhora a eficincia.
5. Em quais princpios se baseia a arquitetura da Norma ISO/IEC 12207?
A arquitetura segue dois princpios bsicos:
Modularidade - Os processos tm alta coeso e baixo acoplamento, ou seja, todas
as partes de um processo so fortemente relacionadas e o nmero de interfaces
entre os processos mantido ao mnimo
Responsabilidade - Cada processo na Norma de responsabilidade de uma parte
envolvida. Uma parte envolvida pode ser uma organizao ou parte dela. As
partes envolvidas podem ser da mesma organizao ou de organizaes diferentes.
102
captulo 5
Captulo 5
1. O Modelo SPICE possui 9 partes. Na segunda parte encontra-se o um Um
Modelo de Referncia para Processos e Capacitao de Processos e, nesse
modelo so definidos quatro tipos de processos, comente cada um deles.
Processos de Engenharia: abrange os processos relacionados ao desenvolvimento e
manuteno do software especificando, implementando ou mantendo o produto de
software e a sua documentao para o cliente.
Processos de Suporte: consiste nos processos de apoio ou suporte que podem ser
empregados por qualquer outro processo durante o ciclo de vida do software.
Processos de Gerncia: consiste em processos que contm prticas que podem ser
utilizadas por quem administra qualquer processo ou projeto dentro do ciclo de vida
de desenvolvimento de software.
Processos Organizacionais: consiste em estabelecer objetivos tanto de negcio
como de recursos humanos da organizao, abrange processos relacionados s
atividades gerais de uma organizao, que ajudam a alcanar esses objetivos.
2. Explique as principais alteraes que aconteceram na transio do Modelo

SPICE para a Norma ISO/IEC 15504.
As principais alteraes que ocorreram do Projeto SPICE para nova estrutura da Norma
ISO/IEC 15504 foram:
Reduo do nmero de partes, de nove para cinco partes, sendo apenas as partes 1
e 2 normativas e as demais informativas:
Parte 1: Conceitos e Vocabulrio (baseada nas partes 1 e 9 do SPICE);
Parte 2: Realizao de uma Avaliao (baseada nas partes 2 e 3 do
SPICE);
Parte 3: Guia para a Realizao de uma Avaliao (baseada nas partes 4
e 6 do SPICE);
Parte 4: Guia para a Utilizao dos Resultados de uma Avaliao (baseada
nas partes 7 e 8 do SPICE);
Parte 5: Um Exemplo de Modelo de Avaliao de Processos (baseada na
parte 5 do SPICE).
captulo 5
103
Compatibilizao com a Norma ISO/IEC 12207, visto que h muita superposio entre a dimenso de processos do ISO/IEC TR 15504 e da ISO/IEC 12207, o que provoca a duplicao de esforos, inconsistncias e dificuldade na utilizao da descrio de processos da ISO/IEC 12207 que contm conceito de capacidade embutido.
Para solucionar esses problemas, a dimenso de processos foi removida da ISO/IEC
15504, se tornando um anexo da Norma ISO/IEC 12207 publicada como AMD1 e
AMD2, e permitindo a ISO/IEC 15504 utilizar qualquer Modelo Compatvel de descrio de processo como Modelo de Referncia. Sendo assim, a ISO/IEC 15504 ser
uma Norma para avaliao da capacidade de processos.
O maior benefcio dessas alteraes est na abordagem comum de avaliao, no sendo
mais restringida aos processos do ciclo de vida do software, e sim, podendo ser executada
em qualquer tipo de processo em qualquer domnio.
3. O CMMI est dividido em 5 nveis de maturidade que atestam o grau de
evoluo em que uma organizao. Comente o que lembra de cada um
desses nveis.
Nvel 1 - Inicial: os processos normalmente esto envoltos num caos decorrente da
no obedincia ou ainda, inexistncia de padres;
Nvel 2 - Gerenciado: os projetos tm seus requisitos gerenciados neste ponto.
Alm disso, h o planejamento, a medio e o controle dos diferentes processos;
Nvel 3 - Definido: os processos j esto claramente definidos e so compreendidos
dentro da organizao. Os procedimentos se encontram padronizados, alm de ser
preciso prever sua aplicao em diferentes projetos;
Nvel 4 - Gerenciado Quantitativamente: ocorre o aumento da previsibilidade do
desempenho de diferentes processos, uma vez que os mesmos j so controlados
quantitativamente;
Nvel 5 - Otimizado: existe uma melhoria contnua dos processos.
104
captulo 5
4. Voc se lembra se o MPS.BR possui alguma vantagem para o mercado brasileiro com relao aos outros modelos vistos?
O MPS.BR baseado noCMMI, nas normasISO/IEC 12207eISO/IEC 15504e tambm na realidade do mercado brasileiro.
No Brasil, uma das principais vantagens do modelo seu custo reduzido de certificao
em relao s normas estrangeiras, sendo ideal para micro, pequenas e mdias empresas
captulo 5
105

Qualidade de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Qualidade de Software

Uploaded by

Copyright:

Available Formats

QUALIDADE

fernando fukuda, simone markenson, jeferson ferreira fagundes

Autor do original mayb andrade

Diretoria de Ensino Fbrica de Conhecimento

1. Viso Geral de Qualidade Software

Conceito de Qualidade de Software 10

2. Normas de Qualidade de Software

Garantia de Qualidade de Software (Software Quality Assurance SGA)

3. Modelos da Norma ISO

4. Modelos de Melhoria e Avaliao de Processo de

5. Modelos de Qualidade de Processo de Software 80

1 Viso Geral de Qualidade Software

Compreender as diferentes vises da Qualidade de Software;

Compreender os fatores da qualidade de um software;

Entender o que so mtricas de software e;

A importncia das revises de software.

1.1 Conceito de Qualidade de Software

Mas vamos parar e analisar, como chegamos a essa era da Qualidade de

De um modo geral, Qualidade de Software pode ser definida como:

Podemos dizer ainda que a qualidade depende tambm do ponto de vista de

1.1.1 Qualidade de Produto X Qualidade de Processo de Software

Da mesma forma como existem diversas interpretaes para qualidade de

1.1.3 Processo de Software

A qualidade do produto decorrente do processo comprometida em funo de prazos;

1.2 Fatores de Qualidade de Software

1.3 Mtricas de Software

Embasar solicitaes de novas ferramentas e treinamento

Mtricas de qualidade: Oferecem uma indicao de quanto o software

1.4 Revises de Software

Algumas informaes importantes no planejamento das revises so:

2 Normas de Qualidade de Software

Descrever os passos necessrios para realizar a garantia de qualidade de software estatstica.

Discorrer sobre a diferena entre confiabilidade de software e segurana de software.

Abordar os princpios da ISO 9000 e suas vertentes.

Discorrer sobre os modelos ISO 9000 para sistemas de garantia da qualidade.

2.1 Garantia de Qualidade de Software (Software Quality

2.1.1 Abordagens Formais Para a Garantia de Qualidade de Software (SGA)

3. ningum sabe onde colocar essa funo organizacionalmente

2.2 Princpios e Modelos da Norma ISO 9000

2.3 NBR ISO 9126

Interoperabilidade: capacidade do produto de software de interagir com

Operacionalidade: capacidade do produto de software de possibilitar ao

Conformidade: capacidade do produto de software de estar de acordo

Na norma cada caracterstica refinada em um conjunto de subcaractersticas

2.4 NBR ISO 12119

A norma de avaliao de pacote de software NBR ISO 12119 faz a avaliao

A seguir, apresentamos detalhadamente cada uma das etapas da Norma

Declaraes sobre Confiabilidade

Declaraes sobre Portabilidade

Programas e Dados: so os requisitos de programas e dados que devem estar

As atividades de teste consistem em testar se esto de acordo com os requisitos de qualidade:

4. Quais so os pr-requisitos de testes da norma ISO 12119?

3 Modelos da Norma ISO

Entender o processo de avaliao de produto de software segundo a norma ISO/IEC

3.1 Norma ISO 9241 Usabilidade do Produto

3.2 Norma ISO 9241 parte -11

Para melhor compreenso desse enunciado, a norma ISO 9241-11 (1998)

A ISO 9241-11 enfatiza que a usabilidade dos computadores dependente

Medidas de desempenho e satisfao dos usurios podem fornecer uma

O nvel no qual o objetivo global estabelecido uma funo do limite do

atributos de um amplo ambiente tcnico (p.ex. a rede de trabalho local)

Especificaes de caractersticas das medidas de uso:

tarefas ou a extenso com os quais objetivos particulares de usabilidade

3.3 Norma ISO 14598 (avaliao de produto)