Qualidade de software

Thiago Carlos de Andrade

MBA Profissional em Sistemas de Informao - Prof FBIO LUIZ BIGATI

Resumo
Este artigo visa a anlise das melhores prticas de produo de software em relao
qualidade. Dentro dessa proposta ser estudado os fundamentos da qualidade no processo
e no produto. Esta anlise ser efetivada atravs dade pesquisa qualitativa e bibliogrfica,
com coleta de dados em livros e sites, e posterior anlise dos dados .

Palavras-chave: Qualidade de software, fundamentos da qualidade, produto, processo

ABSTRACT
This article aims to examine the best software production practices in
relation to the quality. Within this proposal will be studied the
fundamentals of quality in the process and the product. This analysis
will be carried through ity qualitative and bibliographic research, with
data collection in books and websites, and subsequent data analysis.

Keywords: software quality, quality fundamentals, product, process

SUMRIO

Captulo 1
1.Fundamentos de qualidade de software
1.1 - Introduo
1.2 -A O que qualidade?
1.3- Engenharia de Software
1.4 - Metodologias de produo de software
Captulo 2
2.Valores e custos de qualidade
Captulo 3
3.Modelos e caractersticas de qualidade
Captulo 4
4.Qualidade do processo versus qualidade da produo
Captulo 5
5.Garantia de qualidade de software
Captulo 5
6.Verificao e validao
Captulo 7
7.Revises e auditorias
Captulo 8
8.Requisitos de qualidade
Captulo 9
9.Medidas de qualidade de software

Consideraes finais
Referncias bibliogrficas

A qualidade de software uma rea de conhecimento da engenharia

de software que objetiva garantir a qualidade do software atravs da
definio e normatizao de processos de desenvolvimento. Apesar
dos modelos aplicados na garantia da qualidade de software atuarem
principalmente no processo, o principal objetivo garantir um produto
final que satisfaa s expectativas do cliente, dentro daquilo que foi
acordado inicialmente.
Segundo a norma ISO 9000 (verso 2000), a qualidade o grau em
que um conjunto de caractersticas inerentes a um produto, processo
ou sistema cumpre os requisitos inicialmente estipulados para estes.

Captulo 1
1.Fundamentos de qualidade de software
1.1 - Introduo
Segundo Pressman (2006), um software um conjunto composto por
instrues decomputador, estruturas de dados e documentos;
Na era atual o software to importante quanto era a geladeira para o
sculo 20.
No vivemos mais sem o uso do mesmo, porm, assim como todo
produto, o software precisa ser utilizvel. Diante do exposto, ser
discorrido nesse artigo a qualidade de softwre.
1.2 - O que qualidade?
Objetivos:
Contextualizar o tema qualidade;
Relatar sucintamente a histria da administrao da qualidade;
Demonstrar as principais eras da evoluo da qualidade.

A qualidade total e excelncia so princpios que promovem a criao

de valor e o encantamento dos clientes.
Paulo Eduardo Dubie
A qualidade relativa. O que qualidade para uma pessoa
pode ser falta de qualidade para outra.
G. Weinberg
Termo fcil de definir, porm de grande abrangncia. A Qualidade a
adequao ao uso. a conformidade s exigncias. Esta a definio
tcnica estabelecida pelo ISO INTERNATIONAL STANDARDIZATION
ORGANIZATION, situado na Sua e responsvel pelas normas de
Qualidade, em diversos setores, no mundo inteiro. Contudo, quando
falamos de Qualidade foroso render-se a definies mais
abrangentes.
Qualidade tem a ver , primordialmente, com o processo pelo qual os
produtos ou servios so materializados. Se o processo for bem
realizado, um bom produto final advir naturalmente.

Qualidade no tema novo. A qualidade sempre esteve presente na

vida do homem. Pela prpria natureza, a busca pela melhoria, pelo
aperfeioamento e pela realizao sempre foi uma constante. No
incio, para sobreviver, j se preparava com a qualidade dos alimentos
que extraa da natureza. Com a utilizao da agricultura, o homem
passou a cuidar da qualidade daquilo que plantava e colhia. Por
questo de segurana e sobrevivncia, preocupava-se tambm com a
qualidade das pedras selecionadas para a fabricao de armas e
ferramentas. Lascas afiadas eram retiradas de pedras e serviam para
cortar carne e retirar polpa de plantas. "Data-se 2,3 milhes de anos,
sendo um trabalho mais complexo do que qualquer outra coisa". O
enfoque na qualidade e da qualidade evolui medida que as relaes
sociais e econmicas do homem se tornam mais complexas
Pode-se dizer que a histria mais recente da qualidade comeou com a
Revoluo Industrial e a disseminao da produo em srie. Mas h
quem viaje um pouco mais e remeta esta preocupao aos tempos
de Hamurabi e seu cdigo que condenava morte qualquer construtor

que construsse uma casa que desmoronasse por no ser slida o

suficiente, matando o morador (falta de qualidade...).

O desenvolvimento histrico que transformou o controle

tradicional na moderna administrao da qualidade total,
chamada a era moderna da qualidade (iniciada no finaldos
anos 20), pode ser dividido em cinco fases (ou perodos ou
eras) distintas: era dainspeo, era do controle estatstico, era
da garantia da qualidade, era da qualidade total (TQC) e era da
gesto estratgica da qualidade - Sistema de qualidade.

1.3- A Engenharia de Software

A Engenharia de Software surgiu aos poucos em respostas crise do
software.
A crise do software foi um termo utilizado nos anos 1970, quando a
engenharia de software era praticamente inexistente. O termo
expressava as dificuldades do desenvolvimento de software frente ao
rpido crescimento da demanda por software, da complexidade dos
problemas a serem resolvidos e da inexistncia de tcnicas
estabelecidas para o desenvolvimento de sistemas que funcionassem
adequadamente ou pudessem ser validados.
A noo da crise do software emergiu no final dos anos 60. Uma das
primeiras e mais conhecidas referncias ao termo foi feita por Edsger
Dijkstra, na apresentao feita em 1972 na Association for Computing
Machinery Prmio Turing, intitulada "The Humble Programmer"
(EWD340), publicada no peridico en:Communications of the ACM.
As causas da crise do software esto ligadas a complexidade do
processo de software e a relativa imaturidade da engenharia de
software como profisso. A crise se manifesta de varias formas:

Projetos estourando o oramento;

Projetos estourando o prazo;

Software de baixa qualidade;
Software muitas vezes no atingiam os requisitos;
Projetos ingerenciaveis e o cdigo difcil de manter.
A maior parte dos projetos continuam com estes problemas ainda na
atualidade, assim pode se dizer que a crise continua vigente ainda na
atualidade.
O objetivo da Engenharia deSoftware Desenvolver Software como
uma Atividade Industrial E inserir as mesmas sistemticas existentes
em outras reas da engenharia:
custos aceitveis;
gerenciamento do processo de desenvolvimento;
garantia do trabalho em equipe e;
desenvolvimento de softwares com qualidade.
A Engenharia de Software pautada no Guide to the SoftWare
Engineering Body of Knowledge (SWEBOK).
O SWEBOK um documento criado sob o patrocnio da IEEE com a
finalidade de servir de referncia em assuntos considerados, de forma
generalizada pela comunidade, como pertinentes a rea de Engenharia
de Software.
O SWEBOK apresenta uma classificao hierrquica dos tpicos
tratados pela Engenharia de Software, onde o nvel mais alto so as
reas do Conhecimento.
Objetivos
Promover uma viso consistente da engenharia de software no mundo
Clarear e marcar as fronteiras entre a engenharia de software e as
outras disciplinas relacionadas
Caracterizar o contedo da disciplina de engenharia de software
Classificar em tpicos a rea de conhecimento da engenharia de

software (programas)
Prover uma fundao para o desenvolvimento do currculo, para
certificao individual e para licenciamento de material
reas do Conhecimento[editar | editar cdigo-fonte]
Requisitos de Software
Projeto de Software
Construo de Software
Teste de Software
Manuteno de Software
Gerncia de Configurao de Software
Gerncia da Engenharia de Software
Processo de Engenharia de Software
Ferramentas e Mtodos da Engenharia de Software
Qualidade de Software

10 reas da Engenharia de
Software
Requisitos de software
Aquisio, anlise, especificao e gesto de
requisitos de software.
Design de software
Transformao de requisitos (de software),
tipicamente estabelecidos em termos
relevantes ao domnio do problema, em uma
descrio explicando como solucionar os

aspectos do problema relacionados com

software
Construo de Software
Construo de programas funcionais e
coerentes atravs da codificao, autovalidao,
e teste unitrio.
Teste de Software
Verificao dinmica do comportamento do
programa atravs do uso de um conjunto finito
de casos de teste - adequadamente
selecionados de um domnio de execues
usualmente infinito - contra o comportamento
esperado deste
Manuteno de Software
Atividades de suporte custo-efetivo a um
sistema de software, que pode ocorrer antes e
aps a entrega do software.
Aps a entrega do software so feitas
modificaes com o objetivo de corrigir falhas,
melhorar seu desempenho ou adapta-lo a um
ambiente modificado.
Antes da entrega do software so feitas
atividades de planejamento.
Gerncia de Configurao de Software
Identifica a configurao do sistema (caractersticas

documentadas do hardware e software que o

compem) em pontos discretos no tempo, de modo a
controlar sistematicamente suas mudanas e manter
sua integridade e rastreabilidade durante o ciclo de
vida do sistema.
Gerncia de Engenharia de Software
Gerencia projetos de desenvolvimento de software.
Processo de Engenharia de Software
Define, implementa, mede, gerencia, modifica e
aperfeioa o processo de desenvolvimento de
software
Ferramentas e Mtodos
Ferramentas de software automatizam o processo
de engenharia de software
Mtodos impem estrutura sobre a atividade de
desenvolvimento e manuteno de software com o
objetivo de torna-la sistemtica e mais propensa ao
sucesso.
Qualidade de Software
Conjunto de atividades relacionadas com garantia
de qualidade de software, entre estas as atividades
de verificao e validao.

1.4 - Metodologias de produo de software

Metodologia versus mtodo[editar | editar cdigo-fonte]

H uma discusso na cincia a respeito das palavras: metodologia e

mtodo. Elas so largamente utilizados como sinnimos, embora
muitos autores acreditem que seja importante destacar a diferena
entre as duas. Uns entendem o mtodo como um processo, e a
metodologia como o estudo de um ou vrios mtodos.

Interessante observar a etimologia destas palavras. Ambas as palavras

derivam do mesmo radical do Grego, mthodos = 'caminho para
chegar a um fim' e logia = 'estudo de'.

Na Engenharia de Software as principais abordagens de Metodologias

de Desenvolvimento de Software so

1. Metodologias Clssicas (Tradicionais)

Tambm conhecidas como Metodologias orientadas a planejamento, as

Metodologias Clssicas dominaram a forma de desenvolvimento de
softwares at o incio da dcada de 90, Entretanto, estas metodologias
devem ser aplicadas apenas em situaes em que os requisitos do
sistema so estveis e os requisitos futuros so previsveis.

Metodologias ou Processos orientados a documentao so, de certa

forma, barreiras impostas ao desenvolvimento, pois muitas
organizaes no possuem recursos para processos pesados de
produo de software. Por esta razo, as organizaes pequenas
acabam por no usar nenhum processo. Isto pode trazer efeitos
negativos no que diz respeito a qualidade do produto final, alm de
dificultar a entrega do software nos prazos, custos e funcionalidades
previamente definidas.

2. Metodologias geis e o Manifesto gil

A expresso Metodologias geis tornou-se conhecida em 2001,

quando especialistas em processos de desenvolvimento de software
representando entre outros, os mtodos Scrum e Extreme
Programming (XP), foram estabelecidos princpios e caractersticas
comuns destes mtodos. Assim foi criada a Aliana gil e efetuou-se
o estabelecimento do Manifesto gil.

2.1 Principais conceitos do Manifesto gil:

- Pessoas e interaes, ao contrrio de processos e ferramentas.

- Software executvel, ao contrrio de documentao extensa e

confusa.

- Colaborao do cliente, ao contrrio de constantes negociaes de

contratos.

- Respostas rpidas para as mudanas, ao contrrio de seguir planos

previamente definidos.

3. Extreme Programming (XP):

A Extreme Programming (XP) uma Metodologia gil para equipes

pequenas e mdias que desenvolvem software baseado em requisitos
vagos e que se modificam rapidamente. Entre as principais diferenas
da XP em relao s Metodologias Clssicas esto o feedback

constante, a abordagem incremental e o encorajamento da

comunicao entre as pessoas.

A maioria das regras da XP causa surpresa no primeiro contato e

muitas no fazem sentido se aplicadas isoladamente. a fora de seu
conjunto que sustenta o sucesso da XP, trazendo uma verdadeira
revoluo no desenvolvimento de software.

O principal objetivo da XP dar agilidade ao desenvolvimento do

projeto e busca garantir a satisfao do cliente. As prticas, regras, e
os valores da XP garantem um agradvel ambiente de
desenvolvimento de software para os seus seguidores, que so
conduzidos por quatro princpios bsicos:

A Princpio da Comunicao - busca manter o melhor relacionamento

possvel entre clientes e desenvolvedores, preferindo conversas
pessoais a outros meios de comunicao.

B Princpio da Simplicidade - entende-se como simplicidade, a busca

do objetivo de implementar o software com o menor nmero possvel
de classes e mtodos. Outra idia importante deste princpio
procurar implementar apenas requisitos atuais, evitando assim
adicionar funcionalidades que podem ser importantes apenas no
futuro. A aposta da XP que melhor fazer algo simples hoje do que
implementar algo complicado hoje que talvez no venha a ser usado.

C Princpio do Feedback - A prtica do feedback constante significa

que o desenvolvedor ter informaes constantes do cdigo e do
cliente. A informao do cdigo dada pelos testes constantes, que
indicam os erros tanto individuais quanto do software integrado.

D Princpio da Coragem - Sabe-se que no so todas as pessoas que

possuem facilidade de comunicao e tm bom relacionamento
interpessoal, este princpio tambm d suporte simplicidade, pois
assim que a oportunidade de simplificar o software percebida, a
equipe pode experimentar e buscar novas solues, alm disso,
preciso coragem para obter e cobrar constantemente um feedback do
cliente.

2. Valores de qualidade
Qualidade de Software segundo o SWEBOK
O SWEBOK (Software Engineering Body of Knowledge) verso 2004 do
IEEE (Institute of Electrical and Electronics Engineers) apresenta em
uma das suas KAs (Knowledge Areas) a KA de Software Quality.
Abaixo na Figura 4, pode-se ver a estrutra da KAs de Software
Quality:

O SWEBOK descreve ainda inmeras maneiras para se atingir a

qualidade sendo que esta KA em especifico cobre as tcnicas estticas
para deteco de defeitos, no sendo requerido que o software esteja
sendo executado, enquanto que as tcnicas dinmicas so cobertas
pela KA de Software Testing. Custo da Qualidade de Software
A qualidade no totalmente algo que podemos obter de forma
gratuita. Para tanto, investimentos financeiros, treinamentos,
softwares e outras iniciativas precisam ser realizadas em adio para a
busca da qualidade de software como um todo.
Segundo Barti (2002), "Um dos maiores desafios a ser considerados
estabelecer um modelo de custos relacionados a implantao de um
processo de garantia da qualidade de software." (BARTI, 2002, p. 29)

A Figura 5 mostra um modelo de custo de qualidade de software

proposto por Barti (2002):

Figura 5 - Modelo de Custo de Qualidade de Software.

No modelo apresentado, Barti (2002) prope a criao de duas
categorias separadas para os custos relacionados a conformidade e o
custo da no-conformidade:
Custo da Deteco de Defeitos: Pode-se aqui fazer claramente
referncias para o termo controle da qualidade, ou seja, o foco est
exatamente no produto. As atividades aqui realizadas so orientadas
ao produto desenvolvido, e estas incluem:
Revises de requisitos;
Revises de Modelagem;
Revises de Planos de Teste;
Inspees de cdigo;
Testes de Software.
1. Custo da Preveno de Defeitos: Assim como deteco de
defeitos est associada ao controle da qualidade, a preveno de
defeitos est associada a garantia da qualidade, ou seja, o foco
est exatamente no processo. As atividades aqui realizadas so
orientadas ao processo, e estas incluem:
Definio de Metodologias;
Treinamentos;
Ferramentas de apoio ao processo de
desenvolvimento;
Definio de Polticas;
Procedimentos;
Padres;
Especificaes e convenes;
Planejamento do SQA;
Relatrios de Qualidade para melhoria de processo.
1. Custo da No-Conformidade: Por outro lado, o custo da noconformidade est relacionado s perdas que o projeto ter, no
optando pela deteco e preveno de defeitos:
Re-revies;
Re-testes;
Correes de cdigo-fonte e documentao muito
constantes;
Reestruturao;
Redistribuio das verses do software;
Atrasos no cronograma;

Falhas na produo.
Com isso, "O modelo apresentado dever ser associado a todas as
atividades de um processo de engenharia de software. Em todos os
projetos a serem construdos ou modificados, todas as atividades
deveriam ter uma poltica de alocao de custos semelhante ao
modelo apresentado." (BARTI, 2002, p. 29)
Qualidade de Software segundo a ISO 9126-1
A ISO tambm apresenta as caractersticas da qualidade de software
atravs da norma NBR ISO/IEC 9126-1. A antiga norma brasileira para
as caractersticas da qualidade de software era a NBR 13.596. No
entanto, a mesma se integrou a ISO, formando a NBR ISO/IEC 9126-1.
Na Figura 6, so mostradas essas caractersticas juntamente com suas
subcaractersticas:

Figura 6 - NBR ISO/IEC 9126-1 - Caractersticas da Qualidade de

Software.
Funcionalidade (Satisfao das Necessidades): a capacidade do
produto de software de prover funcionalidades que satisfao as
necessidades quando o software est em uso dentro das condies
especificadas.
Confiabilidade (Imunidade a Falhas): a capacidade do
produto de software de manter um nvel especificado de
performance quando o software est em uso dentro das
condies especificadas.
Usabilidade (Facilidade de Uso): a capacidade do produto de
software de ser entendido, aprendido, usado e atrativo quando
o software est em uso dentro das condies especificadas.
Eficincia (Rpido e "Enxuto"): a capacidade do produto de
software de prover performance apropriada, relativa ao
conjunto de recursos usados quando o software est em uso
dentro das condies especificadas.
Manutenibilidade (Facilidade de Manuteno): a capacidade
do produto de software de ser mudado. Modificaes incluem
correes, melhorias ou adaptaes do software de mudar em
um ambiente, e em requisitos e especificaes funcionais.
Portabilidade (Uso em outros Ambientes): a capacidade do
produto de software de ser transferido de um ambiente para

outro.
Alm da NBR ISO/IEC 9126-1, existem ainda outras normas da srie
9126, as quais so:
ISO/IEC 9126-2 - Mtricas Externas: Podem ser aplicadas para um
produto no executvel durante os estgios de desenvolvimento.
Medem a qualidade de produtos intermedirios e predizem a
qualidade do produto final.
ISO/IEC 9126-3 - Mtricas Internas: Utilizadas para medir a
qualidade do software atravs do comportamento do sistema
ou de parte dele. S podem ser usadas durante a fase de
testes do ciclo de vida e durante a operao do sistema.
ISO/IEC 9126-4 - Mtricas da Qualidade do Uso: medem se o
produto atende ou no as necessidades dos usurios, fazendoos atingir seus objetivos com efetividade, produtividade,
segurana e satisfao. S podem ser usadas no ambiente
real ou em uma aproximao do ambiente real.
A Qualidade segundo o PMBOK do PMI
O PMBOK (Project Management Body Of knowledge) do PMI (Project
Management Institute), na sua verso 2004 apresenta o
gerenciamento da qualidade do projeto, conforme Figura 7 abaixo:

Figura 7 - Gerenciamento da Qualidade do Projeto segundo o PMBOK

do PMI.
De acordo com o PMBOK (2004), "Os processos de gerenciamento da
qualidade do projeto incluem todas as atividades da organizao
executora que determinam as responsabilidades, os objetivos e as
polticas de qualidade, de modo que o projeto atenda s necessidades
que motivaram sua realizao. Eles implementam o sistema de
gerenciamento da qualidade atravs da poltica, dos procedimentos e
dos processos de planejamento da qualidade, garantia da qualidade e
controle da qualidade, com atividades de melhoria contnua dos
processos conduzidas do incio ao fim, conforme adequado". (PMI,
2004, p.179)
Com isso os trs principais processos so:
Planejamento da Qualidade: "Identificao dos padres de qualidade
relevantes para o projeto e determinao de como satisfaz-los."
(PMI, 2004, p. 179)

Garantia da Qualidade: "Aplicao das atividades de qualidade

planejadas e sistemticas para garantir que o projeto emprega
todos os processos necessrios para atender aos requisitos.".
(PMI, 2004, p. 179)
Controle da Qualidade: "Monitoramento de resultados
especficos do projeto a fim de determinar se eles esto de
acordo com os padres relevantes de qualidade e identificao
de maneiras de eliminar as causas de um desempenho
insatisfatrio." (PMI, 2004, p. 179)
Como se pode notar evidente a semelhana entre os conceitos
usados no PMBOK e os conceitos da prpria ISO. Com isso, possvel
ainda relacionar estes trs processos do PMBOK com as definies de
controle da qualidade e garantia da qualidade de software
apresentados anteriormente.
Modelo de Qualidade da Norma ISO 9126
A norma 9126 se foca na qualidade do produto de software, propondo
Atributos de Qualidade, distribudos em seis caractersticas principais,
com cada uma delas divididas em sub-caractersticas, conforme
podemos ver na figura abaixo:

ISO-9126No nvel mais alto temos as caractersticas de qualidade e nos quadros

abaixo as suas sub-caractersticas. Cada caracterstica/subcaracterstica compe um Atributo de Qualidade do software.

Note que em todas as caractersticas temos uma sub-categoria com o

nome de Conformidade. A conformidade utilizada para avaliar o
quanto o software obedece aos requisitos de legislao e todo o tipo
de padronizao ou normalizao aplicvel ao contexto.

Funcionalidade
A capacidade de um software prover funcionalidades que satisfaam o
usurio em suas necessidades declaradas e implcitas, dentro de um
determinado contexto de uso.

Suas sub-caractersticas so:

Adequao, que mede o quanto o conjunto de funcionalidades
adequado s necessidades do usurio;
Acurcia (ou preciso) representa a capacidade do software de
fornecer resultados precisos ou com a preciso dentro do que foi
acordado/solicitado;
Interoperabilidade que trata da maneira como o software interage com
outro(s) sistema(s) especificados;
Segurana mede a capacidade do sistema de proteger as informaes
do usurio e fornec-las apenas (e sempre) s pessoas autorizadas
,,, Segurana tambm pode estar dirigida em, processar gerar e
armazenar as informaes.
Conformidade trata da padronizao, politicas e normas de um projeto.
Confiabilidade[editar | editar cdigo-fonte]
O produto se mantm no nvel de desempenho nas condies
estabelecidas.
Suas sub-caractersticas so:
Maturidade, entendida como sendo a capacidade do software em
evitar falhas decorrentes de defeitos no software;
Tolerncia a Falhas representando a capacidade do software em
manter o funcionamento adequado mesmo quando ocorrem defeitos
nele ou nas suas interfaces externas;
Recuperabilidade que foca na capacidade de um software se recuperar
aps uma falha, restabelecendo seus nveis de desempenho e
recuperando os seus dados;
Usabilidade
A capacidade do produto de software ser compreendido, seu
funcionamento aprendido, ser operado e ser atraente ao usurio.
Note que este conceito bastante abrangente e se aplica mesmo a
programas que no possuem uma interface para o usurio final. Por
exemplo, um programa batch executado por uma ferramenta de

programao de processos tambm pode ser avaliado quanto a sua

usabilidade, no que diz respeito a ser facilmente compreendido,
aprendido, etc. Alm disto, a operao de um sistema uma interface
Humano-Computador (ver IHC) sujeita s avaliaes de usabilidade.
Suas sub-caractersticas so:
Inteligibilidade que representa a facilidade com que o usurio pode
compreender as suas funcionalidades e avaliar se o mesmo pode ser
usado para satisfazer as suas necessidades especficas;
Apreensibilidade identifica a facilidade de aprendizado do sistema para
os seus potenciais usurios;
Operacionalidade como o produto facilita a sua operao por parte
do usurio, incluindo a maneira como ele tolera erros de operao;
Atratividade envolve caractersticas que possam atrair um potencial
usurio para o sistema, o que pode incluir desde a adequao das
informaes prestadas para o usurio at os requintes visuais
utilizados na sua interface grfica;
Eficincia
O tempo de execuo e os recursos envolvidos so compatveis com o
nvel de desempenho do software.
Suas sub-caractersticas so:

Comportamento em Relao ao Tempo que avalia se os tempos de

resposta (ou de processamento) esto dentro das especificaes;
Utilizao de Recursos que mede tanto os recursos consumidos quanto
a capacidade do sistema em utilizar os recursos disponveis;
Manutenibilidade
A capacidade (ou facilidade) do produto de software ser modificado,
incluindo tanto as melhorias ou extenses de funcionalidade quanto as
correes de defeitos, falhas ou erros.
Suas sub-caractersticas so:
Analisabilidade identifica a facilidade em se diagnosticar eventuais

problemas e identificar as causas das deficincias ou falhas;

Modificabilidade caracteriza a facilidade com que o comportamento do
software pode ser modificado;
Estabilidade avalia a capacidade do software de evitar efeitos
colaterais decorrentes de modificaes introduzidas;
Testabilidade representa a capacidade de se testar o sistema
modificado, tanto quanto as novas funcionalidades quanto as no
afetadas diretamente pela modificao;
Portabilidade
A capacidade do sistema ser transferido de um ambiente para outro.
Como "ambiente", devemos considerar todo os fatores de adaptao,
tais como diferentes condies de infra-estrutura (sistemas
operacionais, verses de bancos de dados, etc.), diferentes tipos e
recursos de hardware (tal como aproveitar um nmero maior de
processadores ou memria). Alm destes, fatores como idioma ou a
facilidade para se criar ambientes de testes devem ser considerados
como caractersticas de portabilidade.

Suas sub-caractersticas so:

Adaptabilidade, representando a capacidade do software se a adaptar
a diferentes ambientes sem a necessidade de aes adicionais
(configuraes);
Capacidade para ser Instalado identifica a facilidade com que pode se
instalar o sistema em um novo ambiente;
Coexistncia mede o quo facilmente um software convive com outros
instalados no mesmo ambiente;
Capacidade para Substituir representa a capacidade que o sistema tem
de substituir outro sistema especificado, em um contexto de uso e
ambiente especficos. Este atributo interage tanto com adaptabilidade
quanto com a capacidade para ser instalado;

Captulo 4
4.Qualidade do processo versus qualidade da produo
Um dos principais motivos para que organizaes de software adotem
uma viso de melhoria contnua de seus processos o fato da
qualidade do produto final depender diretamente da qualidade do
processo de software adotado.
Uma parte importante da melhoria de processos a avaliao de
processos. A avaliao sistemtica da qualidade de um processo, de
seus ativos (atividades, ferramentas, procedimentos etc) e de seus
produtos resultantes essencial para apoiar a implementao de
estratgias de melhoria.
Dada a amplitude e complexidade do processo de Avaliao e Melhoria
do Processo (AMP) e as fortes relaes com outros processos, com
destaque para a medio, prover apoio automatizado a esse processo
requer, geralmente, diversas ferramentas.
A crescente demanda por produtos de software com alto grau de atendimento
aos requisitos do cliente e que apresentem melhores resultados em termos de
prazo, custo e qualidade dos produtos/servios tem motivado organizaes do
mundo inteiro a adotarem modelos de maturidade. Esses modelos tm como
premissa que a qualidade do produto dependente da qualidade do processo no
qual ele desenvolvido, por essa razo o foco desses modelos o processo. A
essncia dos modelos definir uma trilha aonde se estabelecem nveis de
maturidade para que a empresa os percorra rumo a qualidade. Essa trilha passa
de um estado de produo artesanal para o industrial com uma produo
efetiva e profissional.
Um desses modelos de maturidade o MPS.Br que foi criado no Brasil em 2002
com o intuito de melhorar a qualidade dos processos e produtos da indstria
nacional. A realidade de 2002 era que existiam somente 30 empresas
certificadas em modelos de maturidade e que era necessrio aumentar o
nmero de empresas certificados sob pena do Brasil perder espao nessa
indstria. Aps 8 anos de implantao do MPS.BR, temos mais de 360
empresas certificadas e com ganhos significativos de produtividade e qualidade.
Um exemplo da melhoria sentida pelas organizaes que aps 3 anos de
adoo de um modelo de maturidade a reduo de defeitos nos produtos de
software de 39% o que proporciona uma qualidade para o usurio do produto.

O uso de um modelo de maturidade permite que uma organizao tenha seus

mtodos e processos avaliados de acordo com as boas prticas em
gerenciamento e com um conjunto de parmetros externos. A Maturidade
indicada pela atribuio de um Nvel de Maturidade em particular. A avaliao
do nvel de maturidade do gerenciamento de projeto, programa e portflio realizada por um Consultor Registrado pela APMG - beneficiar a organizao
da seguinte forma:
O conhecimento do nvel de maturidade com recomendaes claras sobre
como conduzir melhorias;
Habilidade em comparar-se com outras organizaes, ou ainda com outros
setores dentro da prpria organizao;
Progresso notvel nas autoavaliaes
Um conjunto consistente de questionrios e pontuaes
Verificao e certificao independentes
Um conjunto de parmetros independentes.
Modelos de processo de software[editar | editar cdigo-fonte]
Um modelo de processo de desenvolvimento de software, ou simplesmente
modelo de processo, pode ser visto como uma representao, ou
abstrao dos objetos e atividades envolvidas no processo de software.
Alm disso, oferece uma forma mais abrangente e fcil de representar
o gerenciamento de processo de software e consequentemente o
progresso do projeto.
Exemplos de alguns modelos de processo de software;
Modelos ciclo de vida
Sequencial ou Cascata (do ingls waterfall) - com fases distintas de
especificao, projeto e desenvolvimento.
Desenvolvimento iterativo e incremental - desenvolvimento iniciado
com um subconjunto simples de Requisitos de Software e
iterativamente alcana evolues subsequentes das verses at
o sistema todo estar implementado
Evolucional ou Prototipao - especificao, projeto e
desenvolvimento de prottipos.
V-Model - Parecido com o modelo cascata, mas com uma organizao
melhor, que permite que se compare com outros modelos mais
modernos.
Espiral - evoluo atravs de vrios ciclos completos de

especificao, projeto e desenvolvimento.

Componentizado - reuso atravs de montagem de componentes j
existentes.
Formal - implementao a partir de modelo matemtico formal.
gil
RAD
Quarta gerao.
Modelos de maturidade[editar | editar cdigo-fonte]
Os modelos de maturidade so um metamodelo de processo. Eles surgiram
para avaliar a qualidade dos processos de software aplicados em uma
organizao (empresa ou instituio). O mais conhecido o Capability Maturity
Model Integration (CMMi), do Software Engineering Institute - SEI.
O CMMI pode ser organizado atravs de duas formas: Contnua e estagiada.
Pelo modelo estagiado, mais tradicional e mantendo compatibilidade com o
CMM, uma organizao pode ter sua maturidade medida em 5 nveis:
Nvel 1 - Inicial (Ad hoc): Ambiente instvel. O sucesso depende da
competncia de funcionrios e no no uso de processos estruturados;
Nvel 2 - Gerenciado: Capacidade de repetir sucessos anteriores pelo
acompanhamento de custos, cronogramas e funcionalidades;
Nvel 3 - Definido: O processo de desenvolvimento de software bem
definido, documentado e padronizado a nvel organizacional;
Nvel 4 - Gerenciado quantitativamente: Realiza uma gerncia
quantitativa do processo de software e do produto por meio de mtricas
adequadas;
Nvel 5 - Em otimizao: Usa a informao quantitativa para melhorar
continuamente e gerenciar o processo de desenvolvimento. At
maro/2012, no Brasil, h somente 13 empresas neste nvel. 3
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. O MPS.BR contempla 7 nveis de maturidade, de A a G, sendo a
primeira o mais maduro. At agosto/2012, no Brasil, h somente 2

empresas neste nvel.4

Dentre os principais benefcios da implantao do CMMI, vale a pena destacar:
Uma maior confiabilidade no que refere ao cumprimento de prazos e custos que
foram acordados, inicialmente, perante o cliente que solicitou o desenvolvimento
de um sistema. Essa previsibilidade decorrente do rigor que o CMMI exige
quanto medio dos processos, fato este que conduz obteno de uma base
histrica realista e confivel para estes fins;
O gerenciamento das atividades relativas produo de software aumenta
consideravelmente;
Uma maior qualidade nos softwares criados, j que processos bem definidos e
controlados conduzem produo de produtos mais confiveis;
A menor dependncia da empresa de desenvolvimento para com seus especialistas.
Com um foco voltado para processos e melhoria contnua, alm do uso intensivo
de informaes histricas, a organizao deixa de depender nica e
exclusivamente de profissionais com um elevado grau de conhecimento tcnico;
A busca por melhorias contnuas nos processos cotidianos.
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.
A implantao do CMMI recomendvel para grandes fbricas de software. Implementar
os diversos estgios uma tarefa rdua, no s numa fase inicial, mas tambm quando se
leva em conta a migrao de um nvel para outro. Isto exigir, invariavelmente, a
realizao de vultosos investimentos financeiros, assim como uma mudana de postura da
organizao (principalmente quando a mesma no contava uma experincia anterior bemsucedida no gerenciamento de processos).
Em inmeras ocasies, empresas desenvolvedoras de sistemas recorrem a consultorias
especializadas, visando apoio na obteno da certificao CMMI (fato este que

inviabiliza a adoo deste mesmo modelo por pequenas companhias).

Maiores informaes sobre o modelo CMMI podem ser obtidas atravs do seguinte link:
http://www.sei.cmu.edu/cmmi/

MPS-BR
O MPS-BR (Melhoria do Processo de Software Brasileiro) uma metodologia voltada
rea de desenvolvimento de sistemas e que foi criada por um conjunto de
organizaes ligadas ao desenvolvimento de software. Dentre as
instituies envolvidas pode-se citar: a Softex (SP), a RioSoft (RJ), o
COPPE/UFRJ (RJ) e o CESAR (PE). Na verdade, estas so organizaes
normalmente no-governamentais e muitas vezes de origem
acadmica, possuindo uma atuao de destaque junto comunidade
de software brasileira.
Enfatiza-se, dentro do MPS-BR, o uso das principais abordagens internacionais voltadas
para a definio, a avaliao e a melhoria dos processos de software. Tal fato torna o
MPS-BR compatvel inclusive com as prticas do CMMI. H ainda no MPS-BR uma
estrutura de nveis de maturidade, de forma similar quela existente dentro do CMMI.
Os diferentes nveis de maturidade do MPS-BR constituem um meio para indicar qual o
nvel da empresa que se est considerando. Cada classificao possvel atesta, assim,
diferentes graus no controle de processos e qual a qualidade que se pode esperar da
organizao que a detm.

A seguir esto listados os 7 nveis de maturidade previstos pelo MPS-BR:

A Em Otimizao: h a preocupao com questes como inovao e anlise de
causas.
B Gerenciado Quantitativamente: avalia-se o desempenho dos processos, alm da
gerncia quantitativa dos mesmos.
C Definido: aqui ocorre o gerenciamento de riscos.
D Largamente Definido: envolve verificao, validao, alm da liberao,
instalao e integrao de produtos, dentre outras atividades.
E Parcialmente Definido: considera processos como treinamento, adaptao de
processos para gerncia de projetos, alm da preocupao com a melhoria e o
controle do processo organizacional.
F Gerenciado: introduz controles de medio, gerncia de configurao, conceitos
sobre aquisio e garantia da qualidade.
G Parcialmente Gerenciado: neste ponto inicial deve-se iniciar o gerenciamento de

requisitos e de projetos.
A certificao MPS-BR tambm tem sido solicitada em licitaes governamentais. Logo,
empresas interessadas em participar de projetos conduzidos por rgos do governo
podem se utilizar desta metodologia para ampliar seu ramo de atuao.
Pode-se considerar ainda o MPS-BR como uma importante alternativa ao CMMI em
organizaes de mdio e pequeno porte. Isto se justifica em virtude do alto investimento
financeiro que o CMMI representa, o que torna o mesmo mais indicado s grandes
empresas de desenvolvimento.
Outras informaes sobre o MPS-BR encontram-se no link:
http://www.softex.br/mpsbr/.

Concluso
Este artigo procurou fornecer uma viso geral a respeito dos modelos CMMI e MPS-BR,
discutindo as caractersticas de cada um e de que forma os mesmos podem ser adotados
na otimizao de processos de desenvolvimento de software. Espero que o contedo aqui
apresentado possa lhe ser til em algum momento. At uma prxima oportunidade!

Captulo 5
5.Garantia de qualidade de software
ualidade, Qualidade de Software e Garantia da Qualidade de Software
so as mesmas coisas?
Este artigo tem por objetivo mostrar as diferenas entre os
termos Qualidade, Qualidade de Software e Garantia da
Qualidade de Software. Com esse artigo, podemos esclarecer a
diferena e at mesmo alguns relacionamentos entre estes
trs termos.
Segundo a NBR ISO 9000:2005, "qualidade o grau no qual um
conjunto de caractersticas inerentes satisfaz aos requisitos". Ou seja,
pode-se afirmar que se algum produto ou servio atende aos requisitos
especificados, este mesmo produto ou servio possui a qualidade
desejada.
A qualidade pode ser medida atravs do grau de satisfao em que as
pessoas avaliam determinado produto ou servio. No entanto, esse
produto ou servio pode ter qualidade para algumas pessoas e para
outras nem tanto, ou seja, a qualidade algo subjetivo.

Conceituar desta forma ento o termo qualidade se torna uma tarefa

muito difcil, pois elementos intrnsecos esto enraizados no intelecto
de cada ser.
O termo TQM (Total Quality Management), amplamente usado nas
organizaes, tambm descreve uma abordagem para a melhoria da
qualidade. De acordo com Kan (2002), "O termo tem tomado vrios
significados, dependendo de quem interpreta e como se aplica." (KAN,
2002, p. 30). Independente dos seus vrios tipos de implementao, os
elementos chave do TQM podem ser resumidos conforme Figura 1,
abaixo:

Foco do Cliente (Customer Focus) - O objetivo atingir a satisfao

total do cliente. O foco do cliente inclui o estudo das necessidades e
vontades do cliente, coleta de requisitos do cliente e a medio e
gerenciamento da satisfao do cliente.
Melhoria de Processo (Process Improvement) - O objetivo reduzir
as variaes de processo e atingir a melhoria da qualidade
contnua. Este elemento inclui ambos os processos de negcio e o
processo de desenvolvimento do produto. Atravs da melhoria de
processo, a qualidade do produto ser reforada.
Lado Humano da Qualidade (Human Side of Quality) - O objetivo
criar a cultura de qualidade por toda a empresa. As reas de foco
incluem liderana, apoio da alta gerncia, participao total de
todos os colaboradores da empresa, e outros fatores humanos
como sociais e psicolgicos.
Segundo ainda a NBR ISO 8402, o conceito de qualidade "A
totalidade das caractersticas de uma entidade que lhe confere a
capacidade de satisfazer s necessidades explcitas e implcitas". As
necessidades explcitas so aquelas expressas na definio formal de
requisitos propostos pelo cliente. Esses requisitos definem as
condies em que o produto ou servio devem ser utilizados bem
como seus objetivos, funes e o desempenho esperado. J as
necessidades implcitas so aquelas que, embora no expressas pelo
cliente nos documentos de requisitos, so necessrias para o usurio.
Esto includos nessas classes tanto os requisitos que no precisam ser
declarados por serem bvios como aqueles requisitos que no so
percebidos como necessrios no momento que o produto foi
desenvolvido, mas que pela gravidade de suas conseqncias devem
ser atendidos.

A qualidade, seja ela usada no contexto de software ou de produtos e

servios, hoje no mais uma obrigao e um diferencial das
empresas. A mesma se tornou um padro em qualquer ramo de
atividade e indstria sendo assim necessria para garantir a satisfao
do cliente. Qualidade hoje em dia, no apenas um diferencial de
mercado para as empresas conseguirem vender e lucrar mais, um
pr-requisito que se deve conquistar para conseguir colocar o produto
ou servio no Mercado Global. De acordo com Jack Welch, "A qualidade
a nossa melhor garantia da fidelidade do cliente, a nossa mais forte
defesa contra a competio estrangeira e o nico caminho para o
crescimento e para os lucros."
Qualidade de Software
Diante dessa complexidade na definio da palavra qualidade,
Pressman (2005) sugere que a qualidade de software seja
implementada e no somente uma idia ou desejo que uma
organizao venha a ter. Para tanto, Pressman (2005) faz as seguintes
colocaes sobre qualidade de software:
"Definir explicitamente o termo qualidade de software, quando o
mesmo dito";(PRESSMAN, 2005, p. 193)
"Criar um conjunto de atividades que iro ajudar a garantir que
cada produto de trabalho da engenharia de software exiba alta
qualidade"; (PRESSMAN, 2005, p. 193)
"Realizar atividades de segurana da qualidade em cada projeto
de software";(PRESSMAN, 2005, p. 193)
"Usar mtricas para desenvolver estratgias para a melhoria de
processo de software e, como conseqncia, a qualidade no
produto final"; (PRESSMAN, 2005, p. 193)
Sendo assim, a busca constante pela qualidade no se faz apenas no
comeo do projeto ou no seu final realizando testes, mas sim e um
processo que visa abranger toda a engenharia de software bem como
a colaborao de todos os membros do time do projeto.
Uma possvel definio mais abrangente e completa para qualidade de
software seria a proposta por Barti (2002): "Qualidade de software
um processo sistemtico que focaliza todas as etapas e artefatos
produzidos com o objetivo de garantir a conformidade de processos e
produtos, prevenindo e eliminando defeitos". (BARTI, 2002, p. 16)
Alguns modelos de qualidade de software tambm so citados por
Pressman (2005). H o que McCall e Cavano (1978) sugerem como
mtricas para qualidade de software. Conhecido como Fatores da

Qualidade, estes fatores avaliam o software em trs pontos distintos:

Transio do Produto, Reviso do Produto e Operao do Produto. Na
Figura 2 so mostrados os Fatores da Qualidade de McCall:

Os Fatores da Qualidade de McCall.

Assim como o modelo proposto por McCall e Cavano (1978), "a
Hewlett-Packard desenvolveu tambm um modelo que referencia
fatores da qualidade de software e que primeiramente publicado por
Grady and Caswell (1987), denominado FURPS: Functionality,
Usability, Reliability, Performance e Supportability. Estes fatores
estabelecem as mtricas de qualidade de software para cada fase do
processo de engenharia de software". (PRESSMAN, 2005, p. 539)
Alm desses modelos de mtricas para qualidade de software, nota-se
que a constante busca pela mesma se tornou uma atividade essencial
dentro das empresas. Colocando-se todos esses conceitos dentro do
contexto apresentado, podemos dizer que "qualidade no uma fase
do ciclo de desenvolvimento de software ... parte de todas as fases".
(BARTI, 2002, p. 16)
Portanto, necessrio um planejamento adequado para que a
qualidade de software seja atingida, conforme a definio de qualidade
que dever ser alcanada. Para isso so necessrios modelos, padres,
procedimentos e tcnicas para atingir essas metas de qualidade
propostas. Para tanto, todas as etapas do ciclo de vida de engenharia
de software devem ser contempladas com atividades que visam
garantir a qualidade tanto do processo quanto do produto.
Software Quality Assurance
Segundo Lewis (2004), uma definio formal de Software Quality
Assurance (SQA) "atividades sistemticas fornecendo evidncias
para o uso pretendido para o produto total de software".(LEWIS, 2004,
p. 18)
Sendo assim, podemos ainda definir como Quality Assurance "o
conjunto de atividades de apoio para fornecer confiana de que os
processos esto estabelecidos e esto continuamente melhorados para
produzir produtos que atendam as especificaes e que sejam
adequados para o uso pretendido". (LEWIS, 2004, p. 18)

Com isso, o SQA envolve todo o processo de desenvolvimento de

software fazendo as devidas monitoraes e melhorias de processos
pertinentes, fazendo com que os padres, procedimentos acordados
esto sendo seguidos e garantindo que problemas so encontrados e
aes corretivas so tomadas. Esse tipo de ao orientada a
preveno. O IEEE 610.12-1990 cita qualidade de software como "(1)
Um padro planejado e sistemtico de todas as aes necessrias para
fornecer confiana adequada que um item ou produto est em
conformidade com os requisitos tcnicos estabelecidos. (2) Um
conjunto de atividades projetadas para avaliar o processo pelo qual
produtos so desenvolvidos ou manufaturados".
O SQA tambm entendida e formada por um grupo de pessoas
relacionadas e empregadas atravs de todo o ciclo de vida de
engenharia de software que positivamente influenciam e quantificam a
qualidade do software que est sendo entregue. Como j foi dito, o
SQA no somente uma atividade associada exclusivamente com
atividades de desenvolvimento de software, mas sim atividades que se
expandem durante todo o ciclo de vida de desenvolvimento de
software. Portanto, isso consiste em realizar a qualidade tanto do
processo quanto to produto. No processo, podemos quantificar a sua
qualidade atravs de mtricas para qualidade de software e no produto
com as tcnicas de verificao e validao. Essas atividades podem
ser, por exemplo, avaliaes como as citadas pela ISO 9000,
auditorias, inspees formais, teste de software, revises. Ainda no
processo podemos usar os mtodos de garantia da qualidade no
formato de auditorias e reportes para a alta gerncia, alm de
avaliaes constantes do processo e anlise estatstica de controle do
processo. No produto os mtodos de garantia da qualidade so
revises, inspeo formal e teste de software, alm de reviso dos
resultados do teste de software realizada por experts, auditorias do
produto e testes realizados pelo cliente.
No entanto, empresas que no possuem o grupo ou processos de SQA
tendem a mostrar os seguintes indicadores de falta de qualidade,
conforme Lewis (2004):
O software que foi entregue freqentemente apresenta falhas;
Inaceitveis conseqncias de falhas de sistemas, desde
financeiras at cenrios reais de aplicao;
Sistemas no esto freqentemente disponveis para uso
pretendido;
Sistemas so freqentemente muito caros;

Custo de detectar e remover defeitos so excessivos.

Por outro lado, empresas que possuem o grupo ou processo de SQA
implementados e a sua aplicao de maneira adequada e correta
mostra que:
A remoo de erros acontece no momento em que se barato
corrigir;
Melhoria da qualidade do produto;
O SQA um recurso para a melhoria de processo;
Estabelecimento de um banco de dados de mtricas como:
planejamento, taxas de falhas e outros indicadores da qualidade;
Lewis (2004) cita as atividades mais comuns do SQA, sendo estas
categorizadas como: Teste de Software (Verificao e Validao),
Gerenciamento de Configurao de Software e Controle da Qualidade.
Na Figura 3, podemos ver a relao entre essas trs principais
atividades juntamente com Padres, Procedimentos, Convenes e
Especificaes:

Teste de Software (Software Testing): Conforme Lewis (2004), "

uma estratgia popular para o gerenciamento de risco". (LEWIS,
2004, p. 19)
O teste de software usado para verificar que requisitos funcionais
e no-funcionais foram devidamente implementados. A limitao
dessa abordagem (Teste de Software), entretanto, que na fase em
que ele acontece, muitas vezes difcil de se conseguir alguma
qualidade no produto. Isso porque muitas empresas ainda usam o
modelo Waterfall, ou modelo cascata, que foca justamente a
atividade de teste de software somente no final do modelo, ou seja,
caso algum defeito seja encontrado (erros em requisitos, por
exemplo) todo ciclo dever ser inicializado novamente. O teste de
software na verdade, foca quase que exclusivamente as atividades
de verificao e validao.
Controle da Qualidade (Quality Control): O controle da qualidade
definido como um processo e mtodos usados para monitorar o
trabalho e observar se os requisitos esto sendo satisfeitos. O
foco justamente em revises e remoo de defeitos antes
mesmo do envio dos produtos. O controle da qualidade deve ser
de responsabilidade da unidade organizacional que produz o
produto. No entanto, possvel ter o mesmo grupo que constri o
produto, que realize tambm o controle da qualidade, ou
estabelecer um grupo de controle da qualidade separado ou
departamento dentro da mesma unidade organizacional que

desenvolve o produto.
O controle da qualidade consistem de checklists bem definidos
em um produto que especificado no plano de garantia da
qualidade. Um exemplos clssico de controle da qualidade so as
inspees de software. A inspeo o grau mais maduro e formal
dentro das revises, sendo necessria uma preparao prvia,
participantes definidos adequadamente e critrios de entrado e
sada bem definidos.
O controle da qualidade projetado para detectar defeitos e
corrigir esses defeitos encontrados, enquanto que a garantida da
qualidade orientada atravs da preveno de defeitos.
Gerenciamento de Configurao de Software (SCM - Software
Configuration Management): O SCM responsvel por identificar,
rastrear e controlar mudanas nos elementos do software de um
sistema. O SCM controla a evoluo do sistema de software ,
gerenciando verses dos componentes de software e seus
relacionamentos. O propsito identificar todos os componentes
inter-relacionados do software e para controlar sua evoluo
atravs das vrias fases no ciclo de vida de desenvolvimento de
software.
SCM uma disciplina que pode ser aplicada para atividades
incluindo: desenvolvimento de software, controle de
documentao, problemas de rastreamento, controle de
mudanas e manuteno. O SCM ainda consiste de atividades que
asseguram que arquitetura e codificao so definidas e no
podem ser mudados sem uma reviso dos efeitos da mudana e
sua documentao. Isso porque conforme definio do SCM
controlar o cdigo-fonte e a sua documentao associada fazendo
com que o cdigo-fonte final e suas descries esto consistentes
e representam os itens que estavam revisados e testados.
Para que ainda estes trs principais componentes funcionem
corretamente, o sucesso do programa de garantida da qualidade de
software tambm depende de uma coerente coleo de padres,
procedimentos, convenes e especificaes, conforme Figura 3.
A combinao de todos esses componentes e suas melhores prticas
o que chamamos de Software Quality Assurance, e que por sua vez
todo esse trabalho realizado por pessoas, garantindo ento a
qualidade de software do produto final entregue ao cliente ou usurio
final.

Para que tambm toda essa estrutura esta devidamente documentada

e aceita por todos os membros do time do projeto, necessrio um

planejamento adequado. Esse planejamento feito no Software

Quality Assurance Plan ou Plano de Garantia da Qualidade de
software. Segundo Lewis (2004), "O plano de garantia da qualidade de
software um resumo ou esboo das medidas de qualidade para
garantir nveis de qualidade dentro do esforo do desenvolvimento de
software".(LEWIS, 2004, p. 22)
O plano usado como um baseline para comparar os nveis atuais
de qualidade durante o desenvolvimento com os nveis planejados de
qualidade. "O plano de SQA prov o framework e guias para o
desenvolvimento de um cdigo entendvel e que seja de fcil
manuteno"(LEWIS, 2004, p. 22).

http://www.univicosa.com.br/arquivos_internos/artigos/AImportanciadoProcessod
eGarantiadaQualidadedeSoftware.pdf
more: http://www.linhadecodigo.com.br/artigo/1712/qualidadequalidade-de-software-e-garantia-da-qualidade-de-software-sao-asmesmas-coisas.aspx#ixzz3T0fL9yb3
Captulo 6
6.Verificao e validao
Sistemas possuem restries de qualidade e confiabilidade
Qualidade de sw: satisfao dos requisitos funcionais, de desempenho
e normas explicitamente declarados. Reduo de custos e aumento
da qualidade e confiabilidade nos processo e produto de sw Estimase que 40% a 50% do esforo de desenvolvimento de sistemas so
empregados em atividades de verificao e validao
Em Engenharia de Software (IEEE 1012): Validao: estamos
construindo o produto certo? o software faz o que o usurio
requisitou? Verificao: estamos construindo o produto
corretamente? o software est de acordo com sua especificao?''
Validao: Confirmar por testes e com provas objetivas que
requisitos particulares para um determinado uso foram cumpridos.
Busca provar que o software implementa cada um dos requisitos
corretamente e completamente ou seja, tenta responder pergunta:
O produto correto foi construdo?

Verificao: Confirmar por testes e com provas objetivas que

requisitos especificados foram cumpridos. Visa garantir que os
produtos de uma dada fase implementam em sua totalidade as
entradas para aquela fase, ou seja, tenta responder pergunta: O
produto foi construdo corretamente?

Existem duas tcnicas fundamentais de verificao de software:

Dinmica: implica em execuo do cdigo=> TESTES; Esttica:
anlises e inspees sem execuo do cdigo
Teste de software
Origem: Wikipdia, a enciclopdia livre.
O teste do software a investigao do software a fim de fornecer
informaes sobre sua qualidade em relao ao contexto em que ele deve
operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.
O teste um processo realizado pelo testador de software, que permeia outros
processos da engenharia de software, e que envolve aes que vo do
levantamento de requisitos at a execuo do teste propriamente dito.
ndice
[esconder]
1 Viso geral
2 Princpios
3 Tcnicas
3.1 Caixa-branca
3.2 Caixa-preta
3.3 Caixa-cinza
3.4 Regresso
3.5 Tcnicas no funcionais
4 Fases ou Nveis
4.1 Teste de unidade
4.2 Teste de integrao
4.3 Teste de sistema

4.4 Teste de aceitao

4.5 Teste de operao
4.5.1 Testes alfa e beta
4.5.2 Candidato a lanamento
5 O Ciclo de Vida dos Testes
5.1 Planejamento
5.2 Preparao
5.3 Especificao
5.4 Execuo
5.5 Entrega
6 Papis
7 Artefatos
8 Referncias
9 Bibliografia
10 Ver tambm
11 Ligaes externas
Viso geral[editar | editar cdigo-fonte]
No se pode garantir que todo software funcione corretamente, sem a
presena de erros,1 visto que os mesmos muitas vezes possuem um grande
nmero de estados com frmulas, atividades e algoritmos complexos. O
tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no
processo aumentam ainda mais a complexidade. Idealmente, toda permutao
possvel do software deveria ser testada. Entretanto, isso se torna impossvel
para a ampla maioria dos casos devido quantidade impraticvel de
possibilidades. A qualidade do teste acaba se relacionando qualidade dos
profissionais envolvidos em filtrar as permutaes relevantes. 2
Falhas podem ser originadas por diversos motivos. Por exemplo, a
especificao pode estar errada ou incompleta, ou pode conter requisitos
impossveis de seremimplementados, devido a limitaes de hardware ou
software. A implementao tambm pode estar errada ou incompleta, como um
erro de um algoritmo. Portanto, uma falha o resultado de um ou mais defeitos
em algum aspecto do sistema.
O teste de software pode ser visto como uma parcela do processo de qualidade

de software. A qualidade da aplicao pode e, normalmente, varia

significativamente de sistema para sistema.
Os atributos qualitativos previstos na norma ISO 9126 so:
Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
De forma geral, mensurar o bom funcionamento de um software envolve
compar-lo com elementos como especificaes, outros softwares da mesma
linha, verses anteriores do mesmo produto, inferncias pessoais, expectativas
do cliente, normas relevantes, leis aplicveis, entre outros. Enquanto a
especificao do software diz respeito ao processo de verificao do software, a
expectativa do cliente diz respeito ao processo de validao do software. Por
meio da verificao ser analisado se o produto foi feito corretamente, se ele
est de acordo com os requisitos especificados. Por meio da validao ser
analisado se foi feito o produto correto, se ele est de acordo com as
necessidades e expectativas do cliente.
Um desenvolvimento de software organizado tem como premissa uma
metodologia de trabalho. Esta deve ter como base conceitos que visem a
construo de um produto de software de forma eficaz. Dentro desta
metodologia esto definidos os passos necessrios para chegar ao produto final
esperado.
Assim, quando se segue uma metodologia para o desenvolvimento de um
produto de software, espera-se um produto final que melhor agrade tanto aos
clientes quanto ao prprio fornecedor, ou seja, a empresa de desenvolvimento.
Observando este aspecto, no faz sentido iniciar a construo de um produto de
software sem ter uma metodologia de trabalho bem solidificada e que seja do
conhecimento de todos os envolvidos no processo. Porm, alm de uma
crescente demanda por softwares de qualidade, as empresas de
desenvolvimento de software sofrem cada vez mais presso por parte dos
clientes para que o produto seja entregue num curto perodo de tempo. Este fato
pode fazer com que uma slida metodologia de trabalho acabe por se
desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento
de um software, para que se obtenha um produto final com um certo nvel de
qualidade imprescindvel a melhoria dos processos de engenharia de software.
Uma maneira vivel para se assegurar a melhoria de tais processos seria
tomar como base modelos sugeridos por entidades internacionais respeitadas

no assunto. Dentro de uma gama de modelos, sejam eles para situaes e

ambientes especficos ou para solues genricas, existem alguns que so mais
utilizados e tidos como eficientes, como por exemplo os SW-CMM, SE-CMM,
ISO/IEC 15504 e o mais conhecido CMMI.
Outro fator com grande influncia sobre a qualidade do software a ser produzido
o que diz respeito aos testes que sero executados sobre tal produto. Todas
as metodologias de desenvolvimento de software tm uma disciplina dedicada
aos testes. Atualmente esta uma tarefa indispensvel, porm muitas vezes
efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem,
pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.
De acordo com um estudo conduzido pelo NIST em 2002, os defeitos
resultam num custo anual de 59,5 bilhes de dlares economia dos
Estados Unidos. Mais de um tero do custo poderia ser evitado com
melhorias na infraestrutura do teste de software.3
Princpios[editar | editar cdigo-fonte]
Para Myers (2004), h princpios vitais para o teste de software. O caso de
teste deve definir a sada esperada, de forma a reduzir a interpretao do
critrio de sucesso. A sada da execuo do teste deve ser exaustivamente
analisada. Os casos de teste devem verificar no somente as condies
invlidas de execuo, como tambm as condies vlidas. Outro conceito
apresentado utilizar pessoas e organizaes diferentes para a implementao
e para a verificao. A entidade de teste possui uma viso destrutiva do sistema,
em busca de erros, enquanto a entidade de programao possui uma viso
construtiva, em busca da implementao de uma especificao.
Myers tambm aborda o esforo para se construir casos de teste. Deve-se evitar
testes descartveis, pois a qualidade do teste piora gradualmente com as
iteraes de desenvolvimento. Em contrapartida, h o teste de regresso, que
permite quantificar a evoluo da qualidade de software, mantendo e
executando novamente testes realizados anteriormente.
O mesmo autor afirma que, diferente do que se poderia considerar senso
comum, a probabilidade de existncia de erros num certo trecho de cdigo
proporcional quantidade de erros j encontrada anteriormente. Basicamente,
erros aparecem em grupos. Trechos especficos de cdigo de um software
qualquer esto mais propensos a ter erros que outros.
Tcnicas[editar | editar cdigo-fonte]
Existem muitas maneiras de se testar um software. Mesmo assim, existem as
tcnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre
linguagens estruturadas que ainda hoje tm grande valia para os sistemas
orientados a objeto. Apesar de os paradigmas de desenvolvimento serem
completamente diferentes, o objetivo principal destas tcnicas continua a ser o
mesmo, encontrar falhas no software. Abaixo esto descritas algumas das

tcnicas mais conhecidas.

Caixa-branca[editar | editar cdigo-fonte]
Ver artigo principal: teste de caixa-branca
Tambm chamada de teste estrutural ou orientado lgica, a tcnica de caixabranca avalia o comportamento interno do componente de software. Essa
tcnica trabalha diretamente sobre o cdigo fonte do componente de
software para avaliar aspectos tais como: teste de condio, teste de fluxo de
dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca
executados.
Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da
tecnologia que determinarem a construo do componente de software, cabendo
portanto avaliao de mais aspectos que os citados anteriormente. O testador
tem acesso ao cdigo fonte da aplicao e pode construir cdigos para efetuar a
ligao de bibliotecas e componentes. Este tipo de teste desenvolvido
analisando o cdigo fonte e elaborando casos de teste que cubram todas as
possibilidades do componente de software. Dessa maneira, todas as variaes
relevantes originadas por estruturas de condies so testadas.
Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre
JUnit para desenvolvimento de classes de teste para testar classes ou
mtodos desenvolvidos emJava. Tambm se enquadram nessa tcnica
testes manuais ou testes efetuados com apoio de ferramentas para
verificao de aderncia a boas prticas de codificao reconhecidas
pelo mercado de software. A aderncia a padres e boas prticas visa
principalmente a diminuio da possibilidade de erros de codificao e
a busca de utilizao de comandos que gerem o melhor desempenho
de execuo possvel. Apesar de muitos desenvolvedores alegarem
que no h ganhos perceptveis com essa tcnica de teste aplicada
sobre unidades de software, devemos lembrar que, no ambiente
produtivo, cada programa pode vir a ser executado milhares ou
milhes de vezes em intervalos de tempo pequenos. na realidade de
produo que a soma dos aparentes pequenos tempos de execuo e
consumo de memria de cada programa poder levar o software a
deixar de atender aos objetivos esperados. A tcnica de teste de caixabranca recomendada para as fases de teste de unidade e teste de
integrao, cuja responsabilidade principal fica a cargo dos
desenvolvedores do software, que por sua vez conhecem bem o cdigo
fonte produzido.
Caixa-preta[editar | editar cdigo-fonte]
Ver artigo principal: Teste de caixa-preta
Tambm chamada de teste funcional, teste comportamental, orientado a dado ou
orientado a entrada e sada, a tcnica de caixa-preta avalia o
comportamento externo docomponente de software, sem se considerar o

comportamento interno do mesmo.4 Dados de entrada so fornecidos, o

teste executado e o resultado obtido comparado a um resultado esperado
previamente conhecido. Como detalhes de implementao no so
considerados, os casos de teste so todos derivados da especificao.
Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao
ideal todas as entradas possveis seriam testadas, mas na ampla maioria dos
casos isso impossvel.5 Outro problema que a especificao pode estar
ambgua em relao ao sistema produzido, e como resultado as entradas
especificadas podem no ser as mesmas aceitas para o teste. 6 Uma
abordagem mais realista para o teste de caixa-preta escolher um subconjunto
de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de
entradas possveis que so processadas similarmente, de forma que testar
somente um elemento desse subconjunto serve para averiguar a qualidade de
todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como
entrada, testar todos os casos possveis pode gerar pelo menos dezenas de
milhares de casos de testes distintos. Entretanto, a partir da especificao do
sistema, pode-se encontrar um subconjunto de inteiros que maximizem a
qualidade do teste. Depende do propsito do sistema, mas casos possveis
incluem inteiros pares, inteiros mpares, zero, inteiros positivos, inteiros
negativos, o maior inteiro, o menor inteiro.
Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de
integrao, teste de sistema e teste de aceitao. A aplicao de critrios
de teste leva o testador a produzir um conjunto de casos de teste (ou
situaes de teste). A aplicao do critrio de Particionamento de
Equivalncia (ou uso de classes de equivalncia) permite avaliar se a
quantidade de casos de teste produzida coerente. O Particionamento
de Equivalncia se baseia em testar subconjuntos dos dados e no
todos os dados possveis - o que seria exaustivo e s vezes impossvel
-, pode-se assumir que as classes de equivalncia sero tratadas da
mesma maneira, pois um nico elemento da classe se comporta como
um representante dessa classe. A partir das classes de equivalncia
identificadas pode-se usar a Anlise de Valor Limite, o testador
construir casos de teste que atuem nos limites superiores e inferiores
destas classes, de forma que um nmero mnimo de casos de teste
permita a maior cobertura de teste possvel. Outro critrio o Grafo
Causa-Efeito, que consiste em utilizar a ideia de grafos para
transformar entradas de dados em causas e sadas de dados em
efeitos. Esse grafo posteriormente convertido para tabela de deciso
e este para casos de teste. Por fim, tem-se o critrio de Error-Guessing,
que uma tcnica em que os analistas de teste, por meio da
experincia e intuio, supem tipos provveis de erro.
Uma abordagem no desenvolvimento do teste de caixa-preta o teste baseado
na especificao, de forma que as funcionalidades so testadas de acordo com
os requisitos. Apesar de necessrio, esse tipo de teste insuficiente para

identificar certos riscos num projeto de software.7

Caixa-cinza[editar | editar cdigo-fonte]
A tcnica de teste de caixa-cinza uma mescla do uso das tcnicas de caixapreta e de caixa-branca. Isso envolve ter acesso a estruturas de dados e
algoritmos do componente a fim de desenvolver os casos de teste, que so
executados como na tcnica da caixa-preta. Manipular entradas de dados e
formatar a sada no considerado caixa-cinza pois a entrada e a sada esto
claramente fora da caixa-preta. A caixa-cinza pode incluir tambm o uso de
engenharia reversa para determinar por exemplo os limites superiores e
inferiores das classes, alm de mensagens de erro.
Regresso[editar | editar cdigo-fonte]
Ver artigo principal: teste de regresso
Essa uma tcnica de teste aplicvel a uma nova verso de software ou
necessidade de se executar um novo ciclo de teste durante o processo de
desenvolvimento. Consiste em se aplicar, a cada nova verso do software ou a
cada ciclo, todos os testes que j foram aplicados nas verses ou ciclos de teste
anteriores do sistema. Inclui-se nesse contexto a observao de fases e tcnicas
de teste de acordo com o impacto de alteraes provocado pela nova verso ou
ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos
testes, recomendada a utilizao de ferramentas de automao de teste, de
forma que, sobre a nova verso ou ciclo de teste, todos os testes
anteriores possam ser executados novamente com maior agilidade.
Tcnicas no funcionais[editar | editar cdigo-fonte]
So tcnicas utilizadas para verificar a operao correta do sistema em relao
a casos invlidos ou inesperados de entrada. Outras tcnicas de teste existem
para testar aspectos no-funcionais do software, como por exemplo, a
adequao a restries de negcio, adequao a normas, ou restries
tecnolgicas. Em contraste s tcnicas funcionais mencionadas acima, que
verificam a produo pelo sistema de respostas adequadas de suas operaes,
de acordo com uma especificao, as tcnicas no funcionais verificam atributos
de um componente ou sistema que no se relacionam com a funcionalidade (por
exemplo, confiabilidade, eficincia, usabilidade, manutenibilidade e
portabilidade)8 .
Uma delas o uso conjunto de teste de desempenho e teste de carga, que
verifica se o software consegue processar grandes quantidades de
dados, e nas especificaes de tempo de processamento exigidas, o
que determina a escalabilidade do software. O teste de usabilidade
necessrio para verificar se a interface de usurio fcil de se aprender e
utilizar. Entre verificaes cabveis esto a relao da interface com
conhecimento do usurio, a compreensibilidade das mensagens de erro e a
integridade visual entre diferentes componentes. 9 J o teste de
confiabilidade usado para verificar se o software seguro em assegurar o

sigilo dos dados armazenados e processados. O teste de recuperao

usado para verificar a robustez do software em retornar a um estado estvel de
execuo aps estar em um estado de falha.
Uma prtica comum testar o software aps uma funcionalidade ser
desenvolvida, e antes dela ser implantada no cliente, por um grupo de
profissionais diferente da implementao. Essa prtica pode resultar na
fase de teste ser usada para compensar atrasos do projeto,
comprometendo o tempo devotado ao teste. Outra prtica comear o
teste no mesmo momento que o projeto, num processo contnuo at o
fim do projeto.
Em contrapartida, algumas prticas emergentes como a programao extrema
e o desenvolvimento gil focam o modelo de desenvolvimento orientado ao
teste. Nesse processo, os testes de unidade so escritos primeiro (TDD), por
engenheiros de software. Antes da implementao da unidade em
questo, o teste falha. Ento o cdigo escrito, passando
incrementalmente em pores maiores dos casos de teste. Os testes
so mantidos junto com o resto do cdigo fonte do software, e
geralmente tambm integra o processo de construo do software.
Teste de unidade[editar | editar cdigo-fonte]
Ver artigo principal: teste de unidade
Tambm conhecida como teste unitrio ou teste de mdulo, a fase em que se
testam as menores unidades de software desenvolvidas (pequenas partes ou
unidades do sistema).10 O universo alvo desse tipo de teste so as
subrotinas, mtodos, classes ou mesmo pequenos trechos de cdigo.
Assim, o objetivo o de encontrar falhas de funcionamento dentro de
uma pequena parte do sistema funcionando independentemente do
todo.
Teste de integrao[editar | editar cdigo-fonte]
Ver artigo principal: teste de integrao
Na fase de teste de integrao, o objetivo encontrar falhas provenientes da
integrao interna dos componentes de um sistema. Geralmente os tipos de
falhas encontradas so de transmisso de dados. Por exemplo, um componente
A pode estar aguardando o retorno de um valor X ao executar um mtodo do
componente B; porm, B pode retornar um valor Y, gerando uma falha. O teste
de integrao conduz ao descobrimento de possveis falhas associadas
interface do sistema.No faz parte do escopo dessa fase de teste o tratamento
de interfaces com outros sistemas (integrao entre sistemas). Essas
interfaces so testadas na fase de teste de sistema, apesar de, a critrio do
gerente de projeto, estas interfaces podem ser testadas mesmo antes de o
sistema estar plenamente construdo.
Teste de sistema[editar | editar cdigo-fonte]
Ver artigo principal: teste de sistema

Na fase de teste de sistema, o objetivo executar o sistema sob ponto de vista

de seu usurio final, varrendo as funcionalidades em busca de falhas em relao
aos objetivos originais. Os testes so executados em condies similares de
ambiente, interfaces sistmicas e massas de dados quelas que um usurio
utilizar no seu dia-a-dia de manipulao do sistema. De acordo com a poltica
de uma organizao, podem ser utilizadas condies reais de ambiente,
interfaces sistmicas e massas de dados.
Teste de aceitao[editar | editar cdigo-fonte]
Ver artigo principal: teste de aceitao
Geralmente, os testes de aceitao so realizados por um grupo restrito de
usurios finais do sistema, que simulam operaes de rotina do sistema de
modo a verificar se seu comportamento est de acordo com o solicitado. Teste
formal conduzido para determinar se um sistema satisfaz ou no seus critrios
de aceitao e para permitir ao cliente determinar se aceita ou no o sistema.
Validao de um software pelo comprador, pelo usurio ou por terceira parte,
com o uso de dados ou cenrios especificados ou reais. Pode incluir testes
funcionais, de configurao, de recuperao de falhas, de segurana e de
desempenho.
Teste de operao[editar | editar cdigo-fonte]
Ver artigo principal: teste de operao
Nessa fase o teste conduzido pelos administradores do ambiente final em que
o sistema ou software entrar em ambiente produtivo. Vale ressaltar que essa
fase aplicvel somente a sistemas de informao prprios de uma
organizao, cujo acesso pode ser feito interna ou externamente a essa
organizao. Nessa fase de teste devem ser feitas simulaes para garantir que
a entrada em produo do sistema ser bem sucedida. Envolve testes de
instalao, simulaes com cpia de segurana dos bancos de dados, etc..
Em alguns casos um sistema entrar em produo para substituir
outro e necessrio garantir que o novo sistema continuar
garantindo o suporte ao negcio.
Testes alfa e beta[editar | editar cdigo-fonte]
Ver artigo principal: verso alfa
Ver artigo principal: verso beta
Em casos especiais de processos de desenvolvimento de software sistemas
operacionais, sistemas gerenciadores de bancos de dados e outros softwares
distribudos em escala nacional e internacional os testes requerem fases
tambm especiais antes do produto ser disponibilizado a todos os usurios.
O perodo entre o trmino do desenvolvimento e a entrega conhecido como
fase alfa e os testes executados nesse perodo, como testes alfa.
PRESSMAN11 afirma que o teste alfa conduzido pelo cliente no ambiente do
desenvolvedor, com este "olhando sobre o ombro" do usurio e registrando erros

e problemas de uso.
Completada a fase alfa de testes, so lanadas a grupos restritos de usurios,
verses de teste do sistema denominadas verses beta. Ele tambm um
teste de aceitao voltado para softwares cuja distribuio atingir
grande nmero de usurios de uma ou vrias empresas compradoras.
PRESSMAN afirma que o teste beta conduzido em uma ou mais
instalaes do cliente, pelo usurio final do software. Diferente do
teste alfa, o desenvolvedor geralmente no est presente.
Consequentemente, o teste beta uma aplicao do software num
ambiente que no pode ser controlado pelo desenvolvedor. O cliente
registra todos os problemas (reais ou imaginrios) que so
encontrados durante o teste beta e os relata ao desenvolvedor em
intervalos regulares. Com o resultado dos problemas relatados durante
os testes beta, os engenheiros de software fazem modificaes e
depois se preparam para liberar o produto de software para toda a
base de clientes.
A comunidade do teste de software usa o termo teste gama de forma sarcstica
referindo-se aos produtos que so mal testados e so entregues aos usurios
finais para que estes encontrem os defeitos j em fase de produo.
Candidato a lanamento[editar | editar cdigo-fonte]
Ultimamente, e principalmente na comunidade de software livre, comum
utilizar o termo candidato a lanamento (release candidate) para indicar
uma verso que candidata a ser a verso final, em funo da quantidade de
erros encontrados. Tais verses so um passo alm do teste beta, sendo
divulgadas para toda a comunidade.
O Ciclo de Vida dos Testes[editar | editar cdigo-fonte]
O Ciclo de Vida dos Testes composto de 5 fases: Planejamento, Preparao,
Especificao, Execuo e Entrega.
Planejamento[editar | editar cdigo-fonte]
Nesta fase elaborada a Estratgia de Teste e o Plano de Teste.
Preparao[editar | editar cdigo-fonte]
O objetivo desta fase preparar o Ambiente de Teste (equipamentos, pessoal,
ferramentas de automao, massa de testes) para que os testes sejam
executados conforme planejados.
Especificao[editar | editar cdigo-fonte]
Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e
Elaborar/ Revisar roteiros de testes.
Execuo[editar | editar cdigo-fonte]
Os testes so executados e os resultados obtidos so registrados.

Entrega
Esta a ltima fase do ciclo de vida de testes, onde o projeto finalizado e toda
documentao finalizada e arquivada.
Papis
Segue abaixo alguns dos papis que uma pessoa pode desenvolver num projeto
de teste de software. Uma pessoa pode acumular mais de um dos papis
citados, de acordo com caractersticas e restries de projetos de
desenvolvimento de software nas quais estejam inseridas. Nas fases de teste de
unidade e de integrao, por exemplo, os papis de arquiteto de teste e analista
de teste podem ser assumidos pelo analista de sistemas do projeto; o papel de
testador pode ser assumido pelo programador ou por um segundo programador
que atue num processo de programao em pares. Na fase de teste de sistema,
num contexto em que haja uma equipe de teste independente, pode haver
profissionais acumulando os papis de arquiteto de teste, analista de teste e
testador.
O lder (ou gerente) do projeto de testes a pessoa responsvel pela liderana
de um projeto de teste especfico, normalmente relacionado a um sistema de
desenvolvimento, seja um projeto novo ou uma manuteno. J o engenheiro
(ou arquiteto) de teste o tcnico responsvel pelo levantamento de
necessidades relacionadas montagem da infraestrutura de teste, incluindo-se
o ambiente de teste, a arquitetura de soluo, as restries tecnolgicas, as
ferramentas de teste. tambm responsvel pela liderana tcnica do trabalho
de teste e pela comunicao entre a equipe de teste e a equipe de projeto (ou
equipe de desenvolvimento).
O analista de teste o tcnico responsvel pela operacionalizao do processo
de teste. Deve seguir as orientaes do gerente de teste ou do arquiteto de teste
para detalhar a forma de execuo dos testes e as condies de teste
necessrias. Tambm deve focar seu trabalho nas tcnicas de teste adequadas
fase de teste trabalhada. Tambm no campo de anlise, o analista de
ambiente o tcnico responsvel pela configurao do ambiente de teste e pela
aplicao das ferramentas necessrias para tal. Esse profissional deve ser
especializado em arquiteturas de soluo e nos sistemas operacionais e
softwares de infraestrutura que regem o ambiente. Ele ser responsvel por
tornar disponvel o ambiente de teste.
O testador o tcnico responsvel pela execuo de teste. Ele deve observar as
condies de teste e respectivos passos de teste documentados pelo analista de
teste e evidenciar os resultados de execuo. Em casos de execues de teste
mal-sucedidas, esse profissional pode tambm registrar ocorrncias de teste (na
maioria das vezes,defeitos) em canais atravs dos quais os
desenvolvedores tomaro conhecimento das mesmas e tomaro as
providncias de correo ou de esclarecimentos.
Por fim, o automatizador de teste o tcnico responsvel pela automao de
situaes de teste em ferramentas. Ele deve observar as condies de teste e

respectivos passos de teste documentados pelo analista de teste e automatizar

a execuo desses testes na ferramenta utilizada. Normalmente so gerados
scripts de teste que permitam a execuo de ciclos de teste sempre que se
julgar necessrio, desde claro, que sejam garantidas as mesmas condies
iniciais do ciclo de teste (valores de dados, estados dos dados, estados do
ambiente, etc..)
Artefatos
O processo de teste de software pode produzir diversos artefatos. O caso de
teste geralmente consiste de uma referncia a um identificador ou requisito de
uma especificao, pr-condies, eventos, uma srie de passos a se seguir,
uma entrada de dados, uma sada de dados, resultado esperado e resultado
obtido. A srie de passos (ou parte dela) pode estar contida num procedimento
separado, para que possa ser compartilhada por mais de um caso de teste.
Um script de teste a combinao de um caso de teste, um procedimento de
teste e os dados do teste. Uma coleo de casos de teste chamada de suite
de teste. Geralmente, ela tambm contm instrues detalhadas ou objetivos
para cada coleo de casos de teste, alm de uma seo para descrio da
configurao do sistema usado.
A especificao de teste chamada plano de teste.

Captulo 7
7.Revises e auditorias
O que o IEEE 1028?
Como todo padro elaborado pelo IEEE (l-se I trs E), o 1028 fruto do
trabalho voluntrio de alguns membros do IEEE. E sendo um padro, eles nos
traz algumas importantes e relevantes informaes a respeito de reviso de
software. Mas sempre bom lembrar, que ele deve ser usado com bom senso,
pois o contexto sempre prevalece sob o padro (ou deveria prevalecer).
O IEEE 1028 nos traz cinco tipos de reviso de software, junto com os
procedimento necessrios para a execua de cada tipo. Est fora do escopo do
padro questes como: quando uma reviso se faz necessria? como escolher
qual tipo de reviso deve ser usado?
Os 5 tipos de reviso abordados so:

Revises gerenciais;
Revises tcnicas;
Inspees;
Walk-throughs;
Auditrias.

Planejamento de Garantia de Qualidade de Software

O planejamento das atividades executadas durante a gesto de
qualidade de software fornece um roteiro seguido pela equipe de SQA.
O grupo de garantia de qualidade de software estabelece um
planejamento de gesto de qualidade para cada projeto de software. O
plano de qualidade determinar os padres organizacionais que so
apropriados ao software e processo em desenvolvimento; novos
padres podem ser adotados de acordo com a utilizao dos mtodos,
ferramentas, necessidades do grupo de garantia ou do projeto. De
acordo com Sommerville: Planejamento de qualidade - A seleo de
procedimentos e de padres adequados a partir dessa estrutura e a
adaptao destes para um projeto em especifico de
software.(Sommerville, p. 465, 2004,). Segundo Pdua as principais
atividades de um planejamento de qualidade compreendem:
Determinao de responsabilidades pelas aes relativas qualidade;
Identificao dos padres aplicveis aos artefatos e s atividades;
Planejamento de revises e testes; Planejamento da gesto de
configuraes; 26 Planejamento de ferramentas, tcnicas e mtricas;
(Pdua, 2003, p.277) A IEEE recomenda uma norma para planos de
Garantia de qualidade de Software. Citado por Pressman: A norma
recomenda uma estrutura que identifique (1) o objetivo e o escopo do
plano; (2) uma descrio de todos os produtos de trabalho de
engenharia de software (por exemplo, modelos, documentos, cdigofonte) que ficam no mbito da SQA; (3) todas as normas e prticas
aplicveis que so aplicadas durante o processo de software; (4) aes
e tarefas de SQA (inclusive revises e auditorias) e sua alocao ao
longo do processo de software; (5) as ferramentas e os mtodos que
apiam as aes e tarefas de SQA; (6) procedimentos de gesto de
configurao de software para gesto de modificao; (7) mtodos
para montagem, proteo e manuteno de todos os registros
relacionados a SQA; e (8) papis e responsabilidades organizacionais

relativos qualidade do produto.(Pressman, 2006, p.595) Um plano

de qualidade estabelecer as qualidades requisitadas para um
produto; ele determina como seus atributos sero avaliados e
mensurados. O resultado final do planejamento de qualidade o Plano
de qualidade do Projeto. Os atributos de qualidade de software em
potencial devem ser levados em considerao durante o planejamento
de qualidade. O plano de qualidade deve definir os atributos mais
significativos para o desenvolvimento do software; por esta razo
alguns fatores podem ser priorizados em detrimento de outros devido
a fatores especficos do produto como eficincia, escopo do problema,
pblico alvo, usabilidade, requisitos, arquitetura entre outros. Segundo
Sommerville o planejamento de qualidade de projeto consiste em
selecionar os principais atributos de qualidade e planejar como eles
podem ser obtidos.
Padres de Garantia de Qualidade de Software
A equipe de Gesto de Qualidade de software deve definir e selecionar
os padres e procedimentos que sero utilizados para garantir a
qualidade do software. Estes devem ser aplicados nas atividades e
integrados ao processo de desenvolvimento. Os padres aplicam-se
aos artefatos produzidos durante a execuo do processo de software.
Eles asseguram que sejam seguidos os padres definidos para o
desenvolvimento do produto, da documentao, do cdigo fonte, dos
testes, das revises formais, das atividades de gesto de projeto e de
qualidade. 27 Segundo Sommerville: Existem dois tipos de padres
que podem ser estabelecidos como parte do processo de garantia de
qualidade: 1. Padres de produto So os padres que se aplicam ao
produto de software em desenvolvimento. Eles incluem padres de
documentos, como estrutura do documento de requisitos; padres de
documentao [...], e padres de codificao, que definem como uma
linguagem de programao deve ser utilizada.
2. Padres de Processo So os padres que definem os processos a
serem seguidos durante o desenvolvimento de software. Eles podem
incluir definies de especificao, processos de projeto e validao, e
uma descrio dos documentos que devem ser gerados no curso
desses processos (2004, p.460) Vrias organizaes nacionais e
internacionais trabalham na produo de padres que podem ser
aplicados em uma srie de projetos; entre eles pode-se citar: US DoD
(United States Department of Defense Departamento de Defesa dos

Estados Unidos), ANSI (American National Standards Instituto

Nacional Norte-Americano de Padres), BSI (British Standards
Institution Insituto Britnico de Padres), Otan (Organizao do
Tratado do Atlntico Norte) e IEEE (Insitute of Eletrical and Electronic
Engineers Instituto de Engenheiros Eltricos e Eletrnicos. As equipes
de SQA devem referenciar padres de qualidades definidos por
instituies nacionais ou internacionais para desenvolver seu prprio
conjunto de padres organizacionais, que devem estar descritos em
um manual de padres apropriados para sua organizao; ou utilizar
algum padro de qualidade j institudo. Embora os padres estejam
definidos, um Gerente de Projeto tem autoridade para modific-los de
acordo com as circunstncias especficas de um projeto. O Gerente de
Qualidade e o Gerente de Projeto definiram quais procedimentos e
padres, que constam no manual de padres, devem ser utilizados,
alterados ou ignorados para um projeto em particular.
3.6. Normas e Processo de Gesto de Qualidade O processo de
gerenciamento de qualidade so atividades executadas em fluxo de
precedncia com o objetivo de realizar o controle de qualidade que
garanta a qualidade do software em desenvolvimento.A equipe de
Garantia de Qualidade de Software desenvolve o processo de
gerenciamento de qualidade e utiliza o como um guia das atividades a
serem realizadas durante a Gesto de Qualidade. Segundo
Sommerville: O gerenciamento de qualidade fornece uma verificao
independente sobre o processo de desenvolvimento de software. Os
produtos entregues a partir do processo de software so entradas para
o processo de gerenciamento de qualidade e so verificados para
assegurar que so consistentes com os padres e os objetivos da
organizao. (2004, p.459) 28 A Norma de Qualidade ISO 9001 um
padro internacional de qualidade utilizado em industrias. Este um
modelo genrico de processo de gerenciamento de qualidade que
descreve os elementos de garantia de qualidade utilizados em
qualquer negcio independentemente dos produtos ou servios
fornecidos; nele esto definidos padres, procedimentos e processos
que podem existir em uma organizao. O ISO 9001 no define como
os procedimentos devem ser executados, ele somente descreve quais
diretrizes devem ser seguidas por uma organizao para assegurar a
conformidade com as normas de qualidade. Cada organizao
seleciona um conjunto de procedimentos a serem seguidos de acordo
com sua especificidade. Segundo Sommerville os padres so [...] um

conjunto apropriado de processos de qualidade deve ser definido e

documentado em um manual de qualidade organizacional
(Sommerville, 2004, p.44). Sobre a ISO 9000 Pressman relata: Os
requisitos delineados pela ISO 9001:2000 (especfica para qualidade de
software) tratam de tpicos, tais como responsabilidade de gesto,
sistema de qualidade, reviso de contrato, controle de projeto, controle
de documento e dados, identificao de produtos e rastreabilidade,
controle de processo, inspeo e teste, ao corretiva e preventiva,
registros de controle de qualidade, auditorias de qualidade interna,
treinamento, servio e tcnicas estatsticas. (2006, p.594)
3.6.1.Normas de Qualidade de Processo de Software MPSBR, SPICE e
CMM. Os padres e normas de Qualidade de Processo de Software
possuem como objetivo ser um modelo das melhores prticas de
desenvolvimento a serem aplicadas na produo de um software de
qualidade. Um processo de software influencia fortemente todos os
aspectos do produto desenvolvido, portanto a qualidade de um
software pode ser avaliada pelo nvel de maturidade (qualidade) do
processo executado para desenvolver o produto. Segundo Pressman:
[...] padres de processo nos fornece um gabarito um mtodo
consistente para descrever uma caracterstica importante do processo
de software. Pela combinao de padres, uma equipe de software
pode construir um processo melhor que satisfaa s necessidades de
um projeto (Pressman, 2006, p.24) Institutos de padres
internacionais e nacionais definiram metamodelos de processos de
software que podem ser aplicados em uma organizao. As normas de
qualidade definem caractersticas que devem existir para estabelecer
um processo de qualidade. A ISO (International Standards Organization
Organizao Internacional para definio de normas) oferece a norma
15504 para ser aplicado no desenvolvimento de processos de
software; o Departament of Defense (DoD) (Departamento de Defesa)
dos EUA solicitou a SEI (Software Engineering Institute Instituto de
Engenharia de Software) que desenvolvesse um padro para ser
utilizado na avaliao de maturidade e capacidade de processo de
software de qualidade. A SEI elaborou o CMM (Capability Maturity
Model); no Brasil a Associao para Promoo da Excelncia do
Software Brasileiro (SOFTEX), contando com apoio do Ministrio da
Cincia e Tecnologia (MCT), definiu o MPSBr (Melhoria de Processos do
Software Brasileiro) como referencia de melhoria de qualidade de
processo, voltada para a realidade do mercado de pequenas e mdias
empresas de desenvolvimento de software. Estes modelos sero

referenciados para a elaborao de padres de qualidade na atividade

de Auditoria e Gesto de Qualidade do Processo de Software Informam.

Captulo 8
8.Requisitos de qualidade
A qualidade de software uma rea de conhecimento da engenharia de
software que objetiva garantir a qualidade do software atravs da definio e
normatizao de processos de desenvolvimento. Apesar dos modelos aplicados
na garantia da qualidade de software atuarem principalmente no processo, o
principal objetivo garantir um produto final que satisfaa s expectativas do
cliente, dentro daquilo que foi acordado inicialmente.
Segundo a norma ISO 9000 (verso 2000), a qualidade o grau em que
um conjunto de caractersticas inerentes a um produto, processo ou sistema
cumpre os requisitos inicialmente estipulados para estes.
No desenvolvimento de software, a qualidade do produto est diretamente
relacionada qualidade do processo de desenvolvimento, desta forma,
comum que a busca por um software de maior qualidade passe
necessariamente por uma melhoria no processo de desenvolvimento.
Rodney Brooks, diretor do Laboratrio de Inteligncia Artificial e Cincia
da Computao do MIT, define qualidade como a conformidade aos
requisitos. Essa definio exige determinar dois pontos: I) o que se
entende por conformidade; e II) como so especificados - e por quem os requisitos.

Para um melhor entendimento e estudo, o SWEBOK divide a qualidade de

software em trs tpicos, e cada tpico subdividido em atividades, da seguinte
forma:
Fundamentos de qualidade de software
Cultura e tica de engenharia de software
Valores e custos de qualidade
Modelos e caractersticas de qualidade

Melhoria da qualidade
Gerncia do processo de qualidade de software
Garantia de qualidade de software
Verificao e validao
Revises e auditorias
Consideraes prticas
Requisitos de qualidade para aplicaes
Caracterizao de defeitos
Tcnicas de gerncia de qualidade de software
Medidas de qualidade de software
Ainda segundo o SWEBOK, a qualidade de software um tema to
importante que encontrado, de forma ubqua, em todas as outras
reas de conhecimento envolvidas em um projeto. Alm disso, ele
deixa claro que essa rea, como nele definida, trata dos aspectos
estticos, ou seja, daqueles que no exigem a execuo do software para
avali-lo, em contraposio rea de conhecimento teste de software.
Porm, normal que se encontrem autores e empresas que afirmam serem os
testes de software uma etapa da qualidade de software.
Muita coisa pode ser encontrada no site http://www.ibqts.com.br O IBQTS,
Instituto Brasileiro de Qualidade em Testes de Software.
Podem ser encontradas mais informaes no site
http://www.bstqb.com.br o BSTQB, Brazilian Software Testing Quality
Board
Requisitos de qualidade[editar | editar cdigo-fonte]
Requisitos de qualidade um tpico por si dentro do assunto qualidade.
Dentro da tica desta ltima, espera-se que os requisitos sejam definidos de
maneira a caracterizar completamente o produto a ser construdo. Nesse
aspecto - e em relao definio de Brooks - evidente que as zonas de
sombra dentro de uma especificao abrem margem a todo tipo de problemas
de avaliao de produtos.
Sommerville1 O modelo internacional mais recente Square, estabelecido pela
norma ISO 25000, adota uma classificao um pouco diferente e utiliza uma

descrio hierrquica. Dentro dessa descrio, "funcionalidade" uma das seis

divises iniciais em que se classificam os requisitos de um produto de software.
Idealmente, a especificao de requisitos deve permitir que o processo de
fabricao do software seja controlado. Isso significa que idealmente a qualidade
de produtos intermedirios deve poder ser mensurada e que os dados obtidos
devem trazer informao que possa levar ao controle de desvios, localizao de
defeitos e outras ocorrncias negativas.
O processo de software Cabea de martelo
Nas ltimas dcadas foram propostas dezenas de metodologias e processos
adaptados a diferentes cenrios e produtos. Embora se possa justificar essa
multiplicidade por outra lei de Brooks - a ausncia de "balas de prata", um fato
que a situao se mostra confusa.
H dezenas de trabalhos propostos para casos particulares. Exemplos das
diversas iniciativas para tratar o assunto so metodologias como XP e Scrum; o
modelo CMM, seguido de toda uma srie de adaptaes (como SW-CMM,
people-CMM, etc.), mais tarde substitudo pelo modelo CMMI; e dezenas de
artigos e teses de mestrado e doutorado, abordando tpicos
particulares em um ou mais de tais mtodos, ou propondo ainda novas
adaptaes a casos particulares.
A situao deixa evidente que h um vcuo a ser preenchido - atacar a raiz do
problema e identificar uma estrutura suficientemente geral, capaz de explicar o
problema de qualidade e ser adaptada a todos os cenrios diferentes. Se tal
objetivo possvel resta a ser provado - assunto para novos artigos e teses.
Garantia de qualidade de software
A Garantia da Qualidade de Software (GQS) a rea-chave de processo do
CMM cujo objetivo fornecer aos vrios nveis de gerncia a adequada
visibilidade dos projetos, dos processos de desenvolvimento e dos produtos
gerados. A GQS atua como "guardi", fornecendo um retrato do uso do
Processo e no responsvel por executar testes de software ou inspeo em
artefatos.
Obtendo a visibilidade desejada, a gerncia pode atuar de forma pontual no
sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento
de software, quais sejam, desenvolver software de alta qualidade, ter alta
produtividade da equipe de desenvolvimento, cumprir o cronograma
estabelecido junto ao cliente e no necessitar de recursos adicionais no

previstos.
Para conseguir esses objetivos a rea-chave de processo GQS estimula a
atuao das equipes responsveis pelo desenvolvimento de software em
diversas frentes objetivando internalizar comportamentos e aes, podendo-se
destacar:
o planejamento do projeto e o acompanhamento de resultados;
o uso dos mtodos e ferramentas padronizadas na organizao;
a adoo de Revises Tcnicas Formais;
o estabelecimento e a monitorao de estratgias de testes;
a reviso dos artefatos produzidos pelo processo de desenvolvimento;
a busca de conformidade com os padres de desenvolvimento de software;
a implantao de medies associadas a projeto, processo e produto;
a utilizao de mecanismos adequados de armazenamento e recuperao
de dados relativos a projetos, processos e produtos; e
a busca de uma melhoria contnua no processo de desenvolvimento de
software.
Para facilitar o trabalho dos desenvolvedores e evitar gerao de metodologias
diversas, o Serpro desenvolveu o Processo Serpro de Desenvolvimento de
Solues (PSDS).
O PSDS foi construdo por pessoas das unidades da empresa que procuraram
aproveitar as melhores prticas existentes e consagradas.

O levantamento de Requisitos de Software

O incio para toda a atividade de
o

desenvolvimento de software

levantamento de requisitos, sendo esta atividade repetida em

todas as demais etapas da engenharia de requisitos.

Sommerville (2003) prope um processo genrico de levantamento e
anlise que contm as seguintes atividades:
Compreenso do domnio: Os analistas devem desenvolver sua

compreenso do domnio da aplicao;

Coleta de requisitos: o processo de interagir com os stakeholders
do sistema para descobrir seus requisitos. A compreenso do
domnio se desenvolve mais durante essa atividade;
Classificao: Essa atividade considera o conjunto no estruturado
dos requisitos e os organiza em grupos coerentes;
Resoluo de conflitos: Quando mltiplos stakeholders esto
envolvidos, os requisitos apresentaro conflitos. Essa atividade
tem por objetivo solucionar esses conflitos;
Definio das prioridades: Em qualquer conjunto de requisitos,
alguns sero mais importantes do que outros. Esse estgio
envolve interao com os stakeholders para a definio dos
requisitos mais importantes;
Verificao de requisitos: Os requisitos so verificados para
descobrir se esto completos e consistentes e se esto em
concordncia com o que os stakeholders desejam do sistema.
O

levantamento e anlise de requisitos

um processo iterativo,

com uma contnua validao de uma atividade para outra, conforme

exemplificado pela Figura 1.

Figura 1.

Processo de levantamento e anlise de requisitos

(SOMMERVILLE, 2003)

Dificuldades encontradas
O problema de no saber especificar corretamente o que o sistema
dever fazer muito antigo. Pompilho (1995) cita um exemplo do
relatrio produzido por McKinsey, em 1968, e mencionado por B.
Langefords e B. Sundgren onde se afirmava que dois teros das
empresas ali estudadas estavam desapontadas com o atendimento
recebido em sistemas de informao.
Aps mais de 30 anos da elaborao do relatrio a situao no
muito diferente. Algumas das razes para o baixo grau de satisfao
dos usurios para os sistemas destacam-se:
Na fase de levantamento de requisitos do projeto, onde no
utilizada uma tcnica adequada para extrair os requisitos do
sistema;
A falha do analista em no descrever os requisitos do sistema de
modo claro, sem ambigidades, conciso e consistente com todos
os aspectos significativos do sistema proposto.
Entre as dificuldades encontradas na fase de levantamento de
requisitos esto: o usurio principal do sistema no sabe o que quer

que o sistema faa ou sabe e no consegue transmitir para o analista;

requisitos identificados, mas que no so realistas e no identificam os
requisitos similares informados por pessoas diferentes. Um stakeholder
errado afetar em perda de tempo e dinheiro para ambas as partes
envolvidas no desenvolvimento do sistema.
Identifica-se um levantamento de requisitos adequado atravs da boa
definio do projeto, da efetividade do projeto, de informaes
necessrias a um perfeito diagnstico e de solues inteligentes.
Quanto ao levantamento de requisitos inadequado, o resultado um
diagnstico pobre com concluses comprometidas, no identificao
das causas dos problemas, custos elevados, prazos vencidos ou
comprometedores, omisso de processos fundamentais e descrditos.

Tcnicas de Levantamento de Requisitos

As tcnicas de levantamento de requisitos tm por objetivo superar as
dificuldades relativas a esta fase. Todas as tcnicas possuem um
conceito prprio e suas respectivas vantagens e desvantagens, que
podem ser utilizadas em conjunto pelo analista.
Sero apresentadas de forma resumida nesse artigo algumas tcnicas
de levantamento de requisitos.

Levantamento orientado a pontos de vista

Para qualquer sistema, de tamanho mdio ou grande, normalmente h
diferentes tipos de usurio final. Muitos

stakeholders

tm algum

tipo de interesse nos requisitos do sistema. Por esse motivo, mesmo

para um sistema relativamente simples, existem muitos pontos de

vista diferentes que devem ser considerados. Os diferentes pontos de

vista a respeito de um problema vem o problema de modos
diferentes. Contudo, suas perspectivas no so inteiramente
independentes, mas em geral apresentam alguma duplicidade, de
modo que apresentam requisitos comuns.
As abordagens orientadas a ponto de vista, na engenharia de
requisitos, reconhecem esses diferentes pontos de vista e os utilizam
para estruturar e organizar o processo de levantamento e os prprios
requisitos. Uma importante capacidade da anlise orientada a pontos
de vista que ela reconhece a existncia de vrias perspectivas e
oferece um

framework

propostos por diferentes

O mtodo VORD

para descobrir conflitos nos requisitos

stakeholders.

(viewpoint-oriented requirements definition

definio de requisitos orientada a ponto de vista)

foi projetado como

um framework orientado a servio para o levantamento e anlise de

requisitos.
A primeira etapa da anlise de ponto de vista identificar os possveis
pontos de vista. Nessa etapa os analistas se renem com os
stakeholders

e utilizam a abordagem de

brainstorming

para

identificar os servios em potencial e as entidades que interagem com

o sistema.
A segunda etapa a estruturao de pontos de vista, que envolve
agrupar pontos de vista relacionados, segundo uma hierarquia.
Servios comuns esto localizados nos nveis mais altos da hierarquia
e herdados por pontos de vista de nvel inferior.
A etapa de documentao do ponto de vista tem por objetivo refinar a
descrio dos pontos de vista e servios identificados.

O mapeamento de sistema conforme ponto de vista envolve identificar

objetos em um projeto orientado a objetos, utilizando as informaes
de servio que esto encapsuladas nos pontos de vista.
A Figura 2 exemplifica a tcnica de levantamento orientado a ponto de
vista.

Figura 2.

Mtodo VORD, SOMMERVILLE 2003

Etnografia
A etnografia uma tcnica de observao que pode ser utilizada para
compreender os requisitos sociais e organizacionais, ou seja, entender
a poltica organizacional bem como a cultura de trabalho com objetivo
de familiarizar-se com o sistema e sua histria. Os cientistas sociais e
antroplogos usam tcnicas de observao para desenvolver um
entendimento completo e detalhado de culturas particulares.
Nesta tcnica, o analista se insere no ambiente de trabalho em que o
sistema ser utilizado. O trabalho dirio observado e so anotadas as
tarefas reais em que o sistema ser utilizado. O principal objetivo da
etnografia que ela ajuda a descobrir requisitos de sistema implcitos,
que refletem os processos reais, em vez de os processos formais, onde
as pessoas esto envolvidas.
Etnografia particularmente eficaz na descoberta de dois tipos de
requisitos:

Os requisitos derivados da maneira como as pessoas realmente

trabalham, em vez da maneira pelas quais as definies de
processo dizem como elas deveriam trabalhar;
Os requisitos derivados da cooperao e conscientizao das
atividades de outras pessoas.
Alguns itens importantes que devem ser executados antes, durante e
depois do estudo de observao:
Antes, necessrio identificar as reas de usurio a serem
observadas; obter a aprovao das gerncias apropriadas para
executar as observaes; obter os nomes e funes das pessoas
chave que esto envolvidas no estudo de observao; e explicar
a finalidade do estudo;
Durante, necessrio familiarizar-se com o local de trabalho que
est sendo observado. Para isso preciso observar os
agrupamentos organizacionais atuais; as facilidades manuais e
automatizadas; coletar amostras de documentos e
procedimentos escritos que so usados em cada processo
especfico que est sendo observado; e acumular informaes
estatsticas a respeito das tarefas, como: freqncia que
ocorrem, estimativas de volumes, tempo de durao para cada
pessoa que est sendo observada. Alm de observar as
operaes normais de negcios acima importante observar as
excees;
Depois, necessrio documentar as descobertas resultantes das
observaes feitas. Para consolidar o resultado preciso rever os
resultados com as pessoas observadas e/ou com seus
superiores.
A anlise de observao tem algumas desvantagens como, consumir
bastante tempo e o analista ser induzido a erros em suas observaes.

Mas em geral a tcnica de observao muito til e freqentemente

usada para complementar descobertas obtidas por outras tcnicas.

Workshops
Trata-se de uma tcnica de elicitao em grupo usada em uma reunio
estruturada. Devem fazer parte do grupo uma equipe de analistas e
uma seleo dos

stakeholders

que melhor representam a

organizao e o contexto em que o sistema ser usado, obtendo assim

um conjunto de requisitos bem definidos.
Ao contrrio das reunies, onde existe pouca interao entre todos os
elementos presentes, o

workshop

tem o objetivo de acionar o

trabalho em equipe. H um facilitador neutro cujo papel conduzir a

workshop

e promover a discusso entre os vrios mediadores. As

tomadas de deciso so baseadas em processos bem definidos e com

o objetivo de obter um processo de negociao, mediado pelo
facilitador.
Uma tcnica utilizada em
workshops

workshops

brainstorming. Aps os

sero produzidas documentaes que refletem os

requisitos e decises tomadas sobre o sistema a ser desenvolvido.

Alguns aspectos importantes a serem considerados: a postura do
condutor do seminrio deve ser de mediador e observador; a
convocao deve possuir dia, hora, local, horrio de incio e de
trmino; assunto a ser discutido e a documentao do seminrio.

Prototipagem

Prottipo tem por objetivo explorar aspectos crticos dos requisitos de

um produto, implementando de forma rpida um pequeno subconjunto
de funcionalidades deste produto. O prottipo indicado para estudar
as alternativas de interface do usurio; problemas de comunicao
com outros produtos; e a viabilidade de atendimento dos requisitos de
desempenho. As tcnicas utilizadas na elaborao do prottipo so
vrias: interface de usurio, relatrios textuais, relatrios grficos,
entre outras.
Alguns dos benefcios do prottipo so as redues dos riscos na
construo do sistema, pois o usurio chave j verificou o que o
analista captou nos requisitos do produto. Para ter sucesso na
elaborao dos prottipos necessria a escolha do ambiente de
prototipagem, o entendimento dos objetivos do prottipo por parte de
todos os interessados no projeto, a focalizao em reas menos
compreendidas e a rapidez na construo.

Entrevistas
A entrevista uma das tcnicas tradicionais mais simples de utilizar e
que produz bons resultados na fase inicial de obteno de dados.
Convm que o entrevistador d margem ao entrevistado para expor as
suas idias. necessrio ter um plano de entrevista para que no haja
disperso do assunto principal e a entrevista fique longa, deixando o
entrevistado cansado e no produzindo bons resultados.
As seguintes diretrizes podem ser de grande auxilio na direo de
entrevistas bem sucedidas com o usurio: desenvolver um plano geral
de entrevistas, certificar-se da autorizao para falar com os usurios,
planejar a entrevista para fazer uso eficiente do tempo, utilizar
ferramentas automatizadas que sejam adequadas, tentar descobrir

que informao o usurio est mais interessado e usar um estilo

adequado ao entrevistar.
Para planejar a entrevista necessrio que antes dela sejam coletados
e estudados todos os dados pertinentes discusso, como formulrios,
relatrios, documentos e outros. Dessa forma, o analista estar bem
contextualizado e ter mais produtividade nos assuntos a serem
discutidos na entrevista.
importante determinar um escopo relativamente limitado,
focalizando uma pequena parte do sistema para que a reunio no se
estenda por mais de uma hora. O usurio tem dificuldade de
concentrao em reunies muito longas, por isso importante
focalizar a reunio no escopo definido.
Aps a entrevista necessrio validar se o que foi documentado pelo
analista est de acordo com a necessidade do usurio, que o usurio
no mudou de opinio e que o usurio entende a notao ou
representao grfica de suas informaes.
A atitude do analista em relao entrevista determinar seu
fracasso ou sucesso. Uma entrevista no uma competio, deve-se
evitar o uso excessivo de termos tcnicos e no conduzir a entrevista
em uma tentativa de persuaso. O modo como o analista fala no
deve ser muito alto, nem muito baixo, tampouco indiretamente, ou
seja, utilizar os termos: ele disse isso ou aquilo na reunio para o
outro entrevistado. O modo melhor para agir seria, por exemplo, dizer:
O Joo v a soluo para o projeto dessa forma. E o senhor Andr,
qual a sua opinio? Em uma entrevista o analista nunca deve criticar
a credibilidade do entrevistado. O analista deve ter em mente que o
entrevistado o perito no assunto e fornecer as informaes
necessrias ao sistema.

Para elaborar perguntas detalhadas necessrio solicitar que o

usurio:
Explique o relacionamento entre o que est em discusso e as
demais partes do sistema;
Descreva o ponto de vista de outros usurios em relao ao item
que esteja sendo discutido;
Descreva informalmente a narrativa do item em que o analista
deseja obter informaes;
Perguntar ao usurio se o item em discusso depende para a sua
existncia de alguma outra coisa, para assim poder juntar os
requisitos comuns do sistema, formando assim um escopo
conciso.
Pode-se utilizar a confirmao, para tanto o analista deve dizer ao
usurio o que acha que ouviu ele dizer. Neste caso, o analista deve
utilizar as suas prprias palavras em lugar das do entrevistado e
solicitar ao entrevistado confirmao do que foi dito.

Questionrios
O uso de questionrio indicado, por exemplo, quando h diversos
grupos de usurios que podem estar em diversos locais diferentes do
pas. Neste caso, elaboram-se pesquisas especficas de
acompanhamento com usurios selecionados, que a contribuio em
potencial parea mais importante, pois no seria prtico entrevistar
todas as pessoas em todos os locais.
Existem vrios tipos de questionrios que podem ser utilizados. Entre
estes podemos listar: mltipla escolha, lista de verificao e questes
com espaos em branco. O questionrio deve ser desenvolvido de

forma a minimizar o tempo gasto em sua resposta.

Na fase de preparao do questionrio deve ser indicado o tipo de
informao que se deseja obter. Assim que os requisitos forem
definidos o analista deve elaborar o questionrio com questes de
forma simples, clara e concisa, deixar espao suficiente para as
repostas que forem descritivas e agrupar as questes de tpicos
especficos em um conjunto com um ttulo especial. O questionrio
deve ser acompanhado por uma carta explicativa, redigida por um alto
executivo, para enfatizar a importncia dessa pesquisa para a
organizao.
Deve ser desenvolvido um controle que identifique todas as pessoas
que recebero os questionrios. A distribuio deve ocorrer junto com
instrues detalhadas sobre como preench-lo e ser indicado
claramente o prazo para devoluo do questionrio. Ao analisar as
respostas dos participantes feito uma consolidao das informaes
fornecidas no questionrio, documentando as principais descobertas e
enviando uma cpia com estas informaes para o participante como
forma de considerao pelo tempo dedicado a pesquisa.

Brainstorming
Brainstorming

uma tcnica para gerao de idias. Ela consiste em

uma ou vrias reunies que permitem que as pessoas sugiram e

explorem idias.
As principais etapas necessrias para conduzir uma sesso de
brainstorming

so:

Seleo dos participantes: Os participantes devem ser selecionados

em funo das contribuies diretas que possam dar durante a

sesso. A presena de pessoas bem informadas, vindas de

diferentes grupos garantir uma boa representao;
Explicar a tcnica e as regras a serem seguidas: O lder da sesso
explica os conceitos bsicos de brainstorming e as regras a
serem seguidas durante a sesso;
Produzir uma boa quantidade de idias: Os participantes geram
tantas idias quantas forem exigidas pelos tpicos que esto
sendo o objeto do brainstorming. Os participantes so
convidados, um por vez, a dar uma nica idia. Se algum tiver
problema, passa a vez e espera a prxima rodada.
No

brainstorming

as idias que a princpio paream no

convencionais, so encorajadas, pois elas frequentemente estimulam

os participantes, o que pode levar a solues criativas para o
problema. O nmero de idias geradas deve ser bem grande, pois
quanto mais idias forem propostas, maior ser a chance de
aparecerem boas idias. Os participantes tambm devem ser
encorajados a combinar ou enriquecer as idias de outros e, para isso,
necessrio que todas as idias permaneam visveis a todos os
participantes.
Nesta tcnica designada uma pessoa para registrar todas as idias
em uma lousa branca ou em papel. medida que cada folha de papel
preenchida, ela colocada de forma que todos os participantes
possam v-la.
Analisar as idias a fase final do

brainstorming. Nessa fase

realizada uma reviso das idias, uma de cada vez. As consideradas

valiosas pelo grupo so mantidas e classificadas em ordem de
prioridade.

JAD
JAD

(Joint Application Design)

uma tcnica para promover

cooperao, entendimento e trabalho em grupo entre os usurios

desenvolvedores.
O JAD facilita a criao de uma viso compartilhada do que o produto
de software deve ser. Atravs da sua utilizao os desenvolvedores
ajudam os usurios a formular problemas e explorar solues. Dessa
forma, os usurios ganham um sentimento de envolvimento, posse e
responsabilidade com o sucesso do produto.
A tcnica JAD tem quatro princpios bsicos:
Dinmica de grupo: so realizadas reunies com um lder
experiente, analista, usurios e gerentes, para despertar a fora
e criatividade dos participantes. O resultado final ser a
determinao dos objetivos e requisitos do sistema;
Uso de tcnicas visuais: para aumentar a comunicao e o
entendimento;
Manuteno do processo organizado e racional: o JAD emprega a
anlise top down e atividades bem definidas. Possibilita assim, a
garantia de uma anlise completa reduzindo as chances de
falhas ou lacunas no projeto e cada nvel de detalhe recebe a
devida ateno;
Utilizao de documentao padro: preenchida e assinada por
todos os participantes. Este documento garante a qualidade
esperada do projeto e promove a confiana dos participantes.
A tcnica JAD composta de duas etapas principais: planejamento,
que tem por objetivo elicitar e especificar os requisitos; e projeto, em
que se lida com o projeto de software.

Cada etapa consiste em trs fases: adaptao, sesso e finalizao. A

fase de adaptao consiste na preparao para a sesso, ou seja,
organizar a equipe, adaptar o processo JAD ao produto a ser
construdo e preparar o material. Na fase de sesso realizado um ou
mais encontros estruturados, envolvendo desenvolvedores e usurios
onde os requisitos so desenvolvidos e documentados. A fase de
finalizao tem por objetivo converter a informao da fase de sesso
em sua forma final (um documento de especificao de requisitos).
H seis tipos de participantes, embora nem todos participem de todas
as fases:
Lder da sesso: responsvel pelo sucesso do esforo, sendo o
facilitador dos encontros. Deve ser competente, com bom
relacionamento pessoal e qualidades gerenciais de liderana;
Engenheiro de requisitos: o participante diretamente responsvel
pela produo dos documentos de sada das sesses JAD. Deve
ser um desenvolvedor experiente para entender as questes
tcnicas e detalhes que so discutidos durante as sesses e ter
habilidade de organizar idias e express-las com clareza;
Executor: o responsvel pelo produto sendo construdo. Tem que
fornecer aos participantes uma viso geral dos pontos
estratgicos do produto de software a ser construdo e tomar as
decises executivas, tais como alocao de recursos, que podem
afetar os requisitos e o projeto do novo produto;
Representantes dos usurios: so as pessoas na empresa que iro
utilizar o produto de software. Durante a extrao de requisitos,
os representantes so frequentemente gerentes ou pessoaschave dentro da empresa que tem uma viso melhor do todo e
de como ele ser usado;
Representantes de produtos de software: so pessoas que esto
bastante familiarizadas com as capacidades dos produtos de

software. Seu papel ajudar os usurios a entender o que

razovel ou possvel que o novo produto faa;
Especialista: a pessoa que pode fornecer informaes detalhadas
sobre um tpico especfico.
O conceito do JAD de abordagem e dinmica de grupo poder ser
utilizado para diversas finalidades, como: planejamento de atividades
tcnicas para um grande projeto, discusso do escopo e objetivos de
um projeto e estimativa da quantidade de horas necessrias para
desenvolver sistemas grandes e complexos.
A maioria das tcnicas JAD funciona melhor em projetos pequenos ou
mdios. Para um sistema grande e complexo podem ser usadas
mltiplas sesses JAD para acelerar a definio dos requisitos do
sistema.

Concluso
No existe uma tcnica padro para o processo de levantamento de
requisitos. Para alcanar um levantamento de requisitos mais preciso
importante o conhecimento de diversas tcnicas para saber que
tcnica de levantamento aplicar em cada situao.
primordial que o analista possua perfil adequado. O analista de
sistemas precisa de mais do que apenas a capacidade de desenhar
fluxogramas e outros diagramas tcnicos. O analista de sistemas tem a
funo de projetar e analisar sistemas de timo desempenho. Para que
esse objetivo seja alcanado, necessrio o analista de sistema
possuir a capacidade de:
Compreender conceitos abstratos, reorganiz-los em divises
lgicas e sintetizar solues baseadas em cada diviso;

Absorver fatos pertinentes de fontes conflitantes ou confusas;

Entender os ambientes do usurio/cliente;
Aplicar elementos do sistema de hardware e/ou software aos
elementos do usurio/cliente;
Comunicar bem nas formas escrita e verbal e entender o objetivo
global do software.
A Tabela 1 apresenta os grupos de tcnicas para o levantamento de
requisitos.
Tcnicas
tradicionais

So aplicadas em vrias reas do

conhecimento. Exemplo: questionrios,
entrevistas, observao, e anlise de
documentos.

Tem por objetivo compreender melhor o

Tcnicas de pensamento e comportamento dos grupos e as
elicitao de necessidades dos usurios. Exemplo:
grupo
brainstorming e as sesses JAD (Joint
Application Design).

Prototipao

O uso de prottipo auxilia na elicitao e validao dos

requisitos de sistema.
A prototipao pode ser utilizada para elicitar requisitos
quando h um alto grau de incerteza ou quando
necessrio um rpido feedback dos usurios.

Tcnicas
contextuais

Surgiram como uma alternativa para as

tcnicas tradicionais e cognitivas e inclui
tcnicas de etnografia e anlise social.

Leia mais em: Engenharia de Software 2 - Tcnicas para levantamento

de Requisitos http://www.devmedia.com.br/engenharia-de-software-2tecnicas-para-levantamento-de-requisitos/9151#ixzz3T0nnc3N5
Captulo 9
9.Medidas de qualidade de software
Mtrica de software
A medio algo comum no mundo da engenharia. A engenharia de software
est longe de desenvolver uma medio padro amplamente aceita e com
resultados sem fatores subjetivos. H discordncias sobre o que medir e como
avaliar o resultado obtido das medies.
Mtricas de softwares possibilitam realizar uma das atividades mais
fundamentais do processo de gerenciamento de projetos: o planejamento. A
partir desse, pode-se identificar a quantidade de esforo, de custo e das
atividades que sero necessrias para a realizao do projeto.
As mtricas de software, do ponto de vista de medio, podem ser divididas em
duas categorias: medidas diretas e indiretas. Podemos considerar como
medidas diretas do processo de engenharia de software o custo e o esforo
aplicados ao desenvolvimento e manuteno do software e do produto, a
quantidade de linhas de cdigo produzidas e o total de defeitos registrados
durante um determinado perodo de tempo. Porm, a qualidade e a
funcionalidade do software, ou a sua capacidade de manuteno, so mais
difceis de serem avaliadas e s podem ser medidas de forma indireta.
Tambm podemos dividir as mtricas de software, sob o ponto de vista de
aplicao, em duas categorias: mtricas de produtividade e de qualidade. As
mtricas de produtividade concentram-se na sada do processo de engenharia
de software. As mtricas de qualidade indicam o quanto o software atende aos
requisitos definidos pelo usurio.

Medidas Diretas
Custo
Esforo
Linhas de Cdigo
Velocidade de Execuo
Memria

Nmero de Erros
Complexidade ciclomtica
Medidas Indiretas
Funcionalidade
Qualidade
Complexidade
Eficincia
Confiabilidade
Manutenibilidade
Para uma melhor compreenso sobre medidas de softwares, precisamos
entender algumas informaes:
Medida: uma indicao quantitativa da extenso, quantidade, dimenso,
capacidade ou tamanho do produto ou do processo.
Medio: ato de determinao de uma medida.
Indicador: uma mtrica ou a combinao delas, que fornece compreenso
do processo de software, de um projeto ou do produto
As medies de software podem ser organizadas em outras classes, as quais
sero definidas a seguir:
Mtricas da produtividade, baseadas na sada do processo de
desenvolvimento do software com o objetivo de avaliar o prprio
processo;
Mtricas da qualidade, que permitem indicar o nvel de resposta do software
s exigncias explcitas e implcitas do cliente, com relao ao definido
pela gerncia de qualidade;
Mtricas tcnicas, nas quais encaixam-se aspectos como funcionalidade,
modularidade, manutenibilidade, etc...
Sob uma outra tica, possvel definir uma nova classificao das medies:
Mtricas orientadas ao tamanho, baseadas nas medies diretas da
Engenharia de Software;
Mtricas orientadas funo, que oferecem medidas indiretas;
Mtricas orientadas s pessoas, as quais do indicaes sobre a forma

como as pessoas desenvolvem os programas de computador.

Mtricas Orientadas ao Tamanho[editar | editar cdigo-fonte]
A medida de software mais familiar a contagem de linhas de cdigo. Esta
mtrica pode parecer simples, mas existe discordncia sobre o que constitui
uma linha de cdigo. A medida de linhas de cdigo no deveria contar linhas de
comentrio e linhas em branco, pois no afeta a sua funcionalidade. Est
fortemente ligado linguagem de programao utilizada, impossibilitando a
utilizao de dados histricos para projetos que no utilizam a mesma
linguagem. Um conjunto de mtricas de qualidade e produtividade pode ser
desenvolvido com esta tcnica.
Mtricas Orientadas Funo[editar | editar cdigo-fonte]
Em vez de contar as linhas de cdigo, a mtrica orientada funo concentra-se
na funcionalidade do software. Em 1979, Allan Albrecht, introduziu uma tcnica
de avaliao conhecida como Ponto de Funo.
Baseada na viso de negcio do usurio;
independente da linguagem utilizada e de qualquer tecnologia em geral;
Ela no permite calcular o esforo de desenvolvimento, mas gera uma
varivel que pode permitir seu clculo;
Auxilia o usurio final a melhorar o exame e avaliao de projetos.
Seus objetivos so:
Medir o que foi requisitado e recebido pelo usurio;
Prover uma mtrica de medio para apoiar a anlise de produtividade e
qualidade;
Prover uma forma de estimar o tamanho do software;
Prover um fator de normalizao para comparao de software.
Razes para se medir um software
Indicar a qualidade do produto;
Avaliar a produtividade dos que desenvolvem o produto;
Determinar os benefcios derivados de novos mtodos e ferramentas de
engenharia de software;
Formar uma base para as estimativas;
Buscar oportunidades por refatorao;
Ajudar na justificativa de aquisio de novas ferramentas ou de treinamentos

adicionais;
A medio algo comum no mundo da engenharia. Mas para engenharia de
software est longe se ter uma medio padro amplamente aceita e com
resultados sem nenhum fator subjetivo. Com certeza o aumento de
produtividade mais representativo ser obtido quando conseguirmos estabelecer
uma sistemtica de mtricas significativa para os resultados do desenvolvimento
de software e efetivamente us-la.
Exemplos de mtricas
Nmero de defeitos introduzidos por programador / hora.
Nmero de patches disponibilizados.
Nmero de mudanas no documento de requisitos
Nmero de linhas de cdigo.
Anlise de pontos de funo (APF) : mede o tamanho funcional do
software, subsdios para o clculo da produtividade do processo de
desenvolvimento com base na funcionalidade ou utilidade dos programas.
Esta avaliao realizada sob o ponto de vista do usurio que avalia o
tamanho e a complexidade de um software. Nesta contagem so
consideradas os seguintes itens da aplicao(software):Arquivos Lgicos
Internos, Arquivos de Interface Externa, Entradas Externas, Consultas
Externas e Sadas Externas. Cada item deste define um peso que no final
determina a quantidade de pontos de funo da aplicao, para o
desenvolvimento de um novo sistema ou os pontos necessrios para se
realizar uma manuteno em um sistema j existente. Os pontos
calculados servem para se chegar as horas totais do projeto. 1 .
Objetivos da Medio de Software e utilidade das mtricas
Entender: ajudam a entender o comportamento e o funcionamento de produtos
de software.
Avaliar: utilizadas para determinar padres, metas e critrios de aceitao.
Controlar: utilizadas para controlar processos, produtos e servios de software.
Prever: utilizadas para prever valores de atributos.
Razes para se medir um software
Indicar a qualidade do produto;
Avaliar a produtividade dos que desenvolvem o produto;

Determinar os benefcios derivados de novos mtodos e ferramentas de

engenharia de software;
Formar uma base para as estimativas;
Buscar oportunidades por refatorao;
Ajudar na justificativa de aquisio de novas ferramentas ou de treinamentos
adicionais;
A medio algo comum no mundo da engenharia. Mas para engenharia de
software est longe se ter uma medio padro amplamente aceita e com
resultados sem nenhum fator subjetivo. Com certeza o aumento de
produtividade mais representativo ser obtido quando conseguirmos estabelecer
uma sistemtica de mtricas significativa para os resultados do desenvolvimento
de software e efetivamente us-la.
Exemplos de mtricas
Nmero de defeitos introduzidos por programador / hora.
Nmero de patches disponibilizados.
Nmero de mudanas no documento de requisitos
Nmero de linhas de cdigo.
Anlise de pontos de funo (APF) : mede o tamanho funcional do
software, subsdios para o clculo da produtividade do processo de
desenvolvimento com base na funcionalidade ou utilidade dos programas.
Esta avaliao realizada sob o ponto de vista do usurio que avalia o
tamanho e a complexidade de um software. Nesta contagem so
consideradas os seguintes itens da aplicao(software):Arquivos Lgicos
Internos, Arquivos de Interface Externa, Entradas Externas, Consultas
Externas e Sadas Externas. Cada item deste define um peso que no final
determina a quantidade de pontos de funo da aplicao, para o
desenvolvimento de um novo sistema ou os pontos necessrios para se
realizar uma manuteno em um sistema j existente. Os pontos
calculados servem para se chegar as horas totais do projeto. 1 .
Anlise de pontos de funo
Anlise de Pontos de Funo (APF) uma tcnica para a medio de
projetos de desenvolvimento de software, visando a estabelecer uma
medida de tamanho, em Pontos de Funo (PF), considerando a

funcionalidade implementada, sob o ponto de vista do usurio. A

medida independente da linguagem de programao ou da tecnologia
que ser usada para implementao.
Sob esse contexto, os objetivos da APF so:
medir a funcionalidade solicitada pelo usurio, antes do projeto de software,
de forma a estimar seu tamanho e seu custo;
medir projetos de desenvolvimento e manuteno de software,
independentemente da tecnologia utilizada na implementao, de forma a
acompanhar sua evoluo;
medir a funcionalidade recebida pelo usurio, aps o projeto de software, de
forma a verificar seu tamanho e custo, comparando-os com o que foi
originalmente estimado;
As organizaes podem aplicar a Anlise de Pontos por Funo como:
uma ferramenta para determinar o tamanho de pacotes de software
adquiridos, atravs da contagem de todos os Pontos por Funo
includos no pacote;
uma ferramenta para apoiar a anlise da qualidade e da produtividade;
um mecanismo para estimar custos e recursos envolvidos em projetos de
desenvolvimento e manuteno de software;
um fator de normalizao para comparao de software.
Em resumo, a tcnica de pontos de funo fornece uma medida objetiva e
comparvel que auxilia a avaliao, planejamento, gerncia e controle da
produo de software.
Mtodo COCOMO
Origem: Wikipdia, a enciclopdia livre.
O 'mtodo COCOMO' (ou COnstructive COst MOdel) um modelo de
estimativa do tempo de desenvolvimento de um produto. Criado por Barry
Boehm. baseado no estudo de sessenta e trs projetos. Os programas
examinaram de 2.000 a 100.000 linhas de cdigo em linguagens de
programao de Assembly a PL/I.
COCOMO consiste em trs implementaes:
1 Bsico
2 Intermedirio

3 Avanado

Bsico
um modelo esttico que calcula o esforo de desenvolvimento de software
e seu custo, em funo do tamanho de linhas de cdigos desenvolvidas.
E = ab(KLOC)bb
D = cb(E)db
P=E/D
Onde E o esforo aplicado pela pessoa no ms, D o tempo de
desenvolvimento em meses cronolgicos, KLOC o nmero calculado
de linhas de cdigo para o projeto (expressado em milhares), e P o
nmero das pessoas necessrio. Os coeficientes ab, bb, cb e db so
dados na seguinte tabela:
Projeto de Software

ab

bb

cb

2.4

1.05

2.5

3.0

1.12

2.5

3.6

1.20

2.5

db
Orgnico
0.38
Semi-Destacado
0.35
Embutido
0.32

Cocomo bsico bom por ser rpido em estimativas e custos de software,

mas sua exatido limitada por causa de sua falta de fatores para
explicar as diferenas entre ferramentas, qualidade de pessoal e
experincia, uso de ferramentas modernas e tcnicas, e outros
atributos de projeto que influenciam nos custos de software.
Pode-se conseguir um software interativo auxiliar na estimativa de custos e
prazos de projetos de sistemas. A partir de um conjunto de atributos, premissas
e modos de desenvolvimento o COCOMO estima os prazos, custos e
recursos necessrios para cada etapa do ciclo de vida do produto. [1]
Intermedirio[editar | editar cdigo-fonte]
Calcula o esforo de desenvolvimento de software em funo do tamanho do
programa, que inclui custo, avaliao subjetiva do produto, hardware, pessoal e
atributos de projeto.

E = ai(LOC)(bi).EAF
Onde E o esforo aplicado em pessoas por ms, LOC o nmero
de linhas de cdigo para o projeto e EAF o fator calculado acima. Os
coeficientes ai e o bi so dados na prxima tabela.
Projeto de Software
Incio (orgnico)
Meio
(semidestacado)
Fim
(embutido)

ai
3.2
3.0
2.8

bi
1.05
1.12
1.50

O mtodo intermedirio uma extenso do mtodo bsico, mas com mais

categorias de controle como: Atributos do produto, Atributos de hardware,
Atributos pessoais, Atributos do projeto.
Avanado
So incorporadas caractersticas da verso intermediria com uma avaliao de
impacto de custo em cada passo de todo o projeto.
Linhas de cdigo fonte (SLOC:Source lines of code (em ingls) ou
simplesmente LOC:Lines of (source) code) uma medida de software
usada para medir o tamanho de umprograma de software, atravs da
contagem do nmero de linhas em o texto do cdigo fonte do
programa. A SLOC normalmente usada para prever a quantidade de esforo
que ser necessrio para desenvolver um programa, bem como a estimativa de
produtividade de programao ou do esforo, uma vez que o software
produzido. Tambm so feitas estimativas sobre o custo de desenvolvimento de
um programa em moeda corrente por linha de cdigo.

Objetivos da Medio de Software e utilidade das mtricas

Entender: ajudam a entender o comportamento e o funcionamento de produtos
de software.
Avaliar: utilizadas para determinar padres, metas e critrios de aceitao.
Controlar: utilizadas para controlar processos, produtos e servios de software.
Prever: utilizadas para prever valores de atributos.

Consideraes finais

Qualidade um conceito complexo, porque ela significa diferentes

coisas para diferentes pessoas, ela altamente dependente do
contexto. Ento, no h uma simples medida para qualidade de
software que seja aceitvel para todos os projetos de todas as
empresas. Para estabelecer ou melhorar a qualidade de software, o
que se deve fazer definir os aspectos de qualidade nos quais se est
interessado e, ento, decidir como fazer para med-los. Antes de
projetar a qualidade num software, os desenvolvedores devem
concordar nas caractersticas que denotam a qualidade e nos termos
que vo descrever essas caractersticas. Apesar dos custos elevados
para a introduo de certos sistemas de gerenciamento de qualidade
de software, como o CMM ou o ISO 9001, importante tais mtodos
serem 26 introduzidos, a fim de que uma empresa sobreviva por um
longo tempo e possa estar sempre atualizada, com um nvel de
produo de software de alta qualidade, satisfazendo sempre as
necessidades de seus clientes.
Referncias bibliogrficas

Bilbiografia
PRESSMAN, Roger S.; PENTEADO, Rosngela Delloso (Trad.); GERMANO,
Ferno Stella R. (Trad.). Engenharia de software. 6. ed. So Paulo
(Estado): McGraw-Hill, 2006. Campos, Fabio M.; Qualidade, Qualidade
de Software e Garantia da Qualidade de Software So as Mesmas
Coisas ?. Disponvel em: http://www.testexpert.com.br/?q=node/669.
Acessado em abril 2011. Vasconcelos, Alexandre M. Lins; Rouiller, Ana
Cristina; Machado, Cristina A. Filipark; Medeiros, Teresa, M. Maciel;
Disponvel em: . Acessado em abril de 2011.
Leia mais em: Maturidade no desenvolvimento de software: CMMI e MPS-BR
http://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-e-mpsbr/27010#ixzz3T0e4YbST

http://www.celepar.pr.gov.br/modules/conteudo/conteudo.php?
conteudo=517

http://www.devmedia.com.br/conceitos-basicos-sobre-metodologiasageis-para-desenvolvimento-de-software-metodologias-classicas-xextreme-programming/10596#ixzz3Szre35oI

http://www.anpad.org.br/admin/pdf/ADI-A1410.pdf
http://www.administradores.com.br/artigos/negocios/o-que-equalidade/23926/
http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/24
1804.pdf
http://www.infoescola.com/administracao_/historia-da-qualidade/
ftp://ftp.cefetes.br/cursos/CodigosLinguagens/EAildefonso/HIST%D3RIA
%20DA%20QUALIDADE.pdf
ftp://ftp.cefetes.br/cursos/CodigosLinguagens/EAildefonso/HIST%D3RIA
%20DA%20QUALIDADE.pdf
http://www.inmetro.gov.br/barreirastecnicas/pdf/Livro_Qualidade.pdf
http://www.cic.unb.br/~jhcf/MyBooks/iess/Intro/OQueEhEngenhariaDeS
oftware.pdf
http://inf.ufes.br/~falbo/files/Avaliacao_e_Melhoria_de_Processos_de_So
ftware.pdf
http://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-desoftware-licenciatura-em-informatica/introducao-parte-1
http://www.cic.unb.br/~jhcf/MyBooks/iess/Intro/10AreasDaEngenhariaD
eSoftware.pdf
http://www.di.ubi.pt/~cbarrico/Disciplinas/EngenhariaSoftware/Downloa
ds/Cap%203%20-%20Evolucao%20das%20Metodologias%20de
%20Desenvolvimento%20de%20Software.pdf
http://www.ic.unicamp.br/~ranido/mc626/Qualidade.pdf

Bibliografia[editar | editar cdigo-fonte]

KOSCIANSKI, A., Soares. M. S. Qualidade de Software. [S.l.]: Novatec,
2006.
PRESSMAN, R. S.. Engenharia de Software. [S.l.]: McGraw Hill, 2002.
MYERS, Glenford J.. The Art of Software Testing. 2 ed. Nova Jrsei: John
Wiley & Sons, 2004. ISBN 0-471-46912-2