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 de computador, 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?
A qualidade total e excelncia so princpios que promovem a criao
de valor e o encantamento dos clientes.
Paulo Eduardo Dubie
Termo 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.
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.
1.3- A Engenharia de Software
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.
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. 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 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 de Software 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.
1.4 - Metodologias de produo de software
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 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.
3. Valores de qualidade
Qualidade de Software segundo A NBR ISO/IEC 9126-1
Funcionalidade (Satisfao das Necessidades)
Confiabilidade (Imunidade a Falhas)
Usabilidade (Facilidade de Uso)
Eficincia (Rpido e "Enxuto")
Manutenibilidade (Facilidade de Manuteno)
Portabilidade (Uso em outros Ambientes)
Custo da Qualidade de SoftwareA 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)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.
2.Custo da No-Conformidade: Por outro lado, o custo da
no-conformidade est relacionado s perdas que o projeto ter, no
optando pela deteco e preveno de defeitos:
''Re-revises'';
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)
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.
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.
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
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.
Modelos de processo de software
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.
Captulo 5
5.Garantia de qualidade de software
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. 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 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.
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. 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)
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 Estima-se
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
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.
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.
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 caixa-branca 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.
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.
Caixa-cinza[editar | editar cdigo-fonte]
A tcnica de teste de caixa-cinza uma mescla do uso das tcnicas
de caixa-preta 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.
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.
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.
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.
Os cinco tipos de reviso
Segue abaixo, a traduo do anexo B do padro, que contm uma tabela
comparativa entre os tipos de reviso (o texto original est numa
linguagem meio chata de entender, e no consegui melhorar muito na
traduo se notarem algum erro ou melhoria, por favor me avisem):
Caracterstica
Reviso gerencial
Reviso tcnica
Inspeo
Walk-through
Auditria
Objetivo
Garantir o progresso; recomendar aes corretivas; garantir alocao
correta dos recursos
Avaliar a conformidade do estado atual com as especificaes e
planos; garantir integridade da mudana
Encontrar anomalias; verificar decises; verificar a qualidade do
produto
Encontrar anomalias; examinar alternativas; melhorar o produto;
frum para aprendizado
Avaliao independente de cumprimento com os objetivos de padres e
regulamentos
Tomada de deciso
A equipe de gerenciamento traa o curso da ao; decises so feitas
na reunio ou como resultado das recomenda-es
A equipe de reviso solicita aos gerentes ou a liderana tcnica
que atuem nas recomendaes
A equipe de reviso escolhe as disposies pr-definidas do produto;
os defeitos devem ser removidos
A equipe concorda com as mudanas para serem feitas pelo
autor
Organizao auditada, iniciador, comprador, cliente ou usurio
Verificao das mudanas
O lder verifica que itens so fechados; a verificao das mudanas
deixada para outros controles do projeto
O lder verifica que itens so fechados; a verificao das mudanas
deixada para outros controles do projeto
O lder verifica que itens so fechados; a verificao das mudanas
deixada para outros controles do projeto
O lder verifica que itens so fechados; a verificao das mudanas
deixada para outros controles do projeto
Responsabili-dade da organizao auditada
Tamanho recomendado do grupo
Duas ou mais pessoas
Trs ou mais pessoas
Trs a seis pessoas
Duas a sete pessoas
Uma a sete pessoas
Quem participa
Gerentes, liderena tcnica e algumas pessoas de outras reas
Liderena tcnica e algumas pessoas de outras reas
Pessoas da rea com acompanhe-mento documen-tado
Liderena tcnica e algumas pessoas de outras reas
Auditores, organizao auditada, pessoal de gerncia e tcnico
Grupo da liderana
Normalmente o gerente responsvel
Normalmente o engenheiro lder
Um facilitador treinado
O facilitador ou o autor
O auditor lder
Volume de materiais
Moderado para muito, depende dos objetivos da reunio
Moderado para muito, depende dos objetivos da reunio
Relativa-mente baixo
Relativa-mente baixo
Moderado para muito, depende dos objetivos da reunio
