Qualidade de software

Thiago Carlos de AndradeMBA Profissional em Sistemas de Informao - Prof FBIO LUIZ BIGATI

ResumoEste 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

ABSTRACTThis 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, processSUMRIO

Captulo 11.Fundamentos de qualidade de software1.1 - Introduo1.2 -A O que qualidade?1.3- Engenharia de Software1.4 - Metodologias de produo de softwareCaptulo 22.Valores e custos de qualidadeCaptulo 33.Modelos e caractersticas de qualidadeCaptulo 44.Qualidade do processo versus qualidade da produo Captulo 55.Garantia de qualidade de softwareCaptulo 5 6.Verificao e validaoCaptulo 7 7.Revises e auditoriasCaptulo 88.Requisitos de qualidade Captulo 99.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 11.Fundamentos de qualidade de software1.1 - IntroduoSegundo 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 pessoapode ser falta de qualidade para outra. G. WeinbergTermo 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 complexasPode-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 SoftwareA 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.ObjetivosPromover uma viso consistente da engenharia de software no mundoClarear e marcar as fronteiras entre a engenharia de software e as outras disciplinas relacionadasCaracterizar o contedo da disciplina de engenharia de softwareClassificar 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 materialreas do Conhecimento[editar | editar cdigo-fonte]Requisitos de SoftwareProjeto de SoftwareConstruo de SoftwareTeste de SoftwareManuteno de SoftwareGerncia de Configurao de SoftwareGerncia da Engenharia de SoftwareProcesso de Engenharia de SoftwareFerramentas e Mtodos da Engenharia de SoftwareQualidade de Software

10 reas da Engenharia deSoftwareRequisitos de softwareAquisio, anlise, especificao e gesto derequisitos de software.Design de softwareTransformao de requisitos (de software),tipicamente estabelecidos em termosrelevantes ao domnio do problema, em umadescrio explicando como solucionar osaspectos do problema relacionados comsoftwareConstruo de SoftwareConstruo de programas funcionais ecoerentes atravs da codificao, autovalidao,e teste unitrio.Teste de SoftwareVerificao dinmica do comportamento doprograma atravs do uso de um conjunto finitode casos de teste - adequadamenteselecionados de um domnio de execuesusualmente infinito - contra o comportamentoesperado desteManuteno de SoftwareAtividades de suporte custo-efetivo a umsistema de software, que pode ocorrer antes eaps a entrega do software.Aps a entrega do software so feitasmodificaes com o objetivo de corrigir falhas,melhorar seu desempenho ou adapta-lo a umambiente modificado.Antes da entrega do software so feitasatividades de planejamento.Gerncia de Configurao de SoftwareIdentifica a configurao do sistema (caractersticasdocumentadas do hardware e software que ocompem) em pontos discretos no tempo, de modo acontrolar sistematicamente suas mudanas e mantersua integridade e rastreabilidade durante o ciclo devida do sistema.Gerncia de Engenharia de SoftwareGerencia projetos de desenvolvimento de software.Processo de Engenharia de SoftwareDefine, implementa, mede, gerencia, modifica eaperfeioa o processo de desenvolvimento desoftwareFerramentas e MtodosFerramentas de software automatizam o processode engenharia de softwareMtodos impem estrutura sobre a atividade dedesenvolvimento e manuteno de software com oobjetivo de torna-la sistemtica e mais propensa aosucesso.Qualidade de SoftwareConjunto de atividades relacionadas com garantiade qualidade de software, entre estas as atividadesde verificao e validao.

1.4 - Metodologias de produo de softwareMetodologia 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 qualidadeQualidade 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 no-conformidade 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, fazendo-os 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 9126A 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-9126-No nvel mais alto temos as caractersticas de qualidade e nos quadros abaixo as suas sub-caractersticas. Cada caracterstica/sub-caracterstica 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.

FuncionalidadeA 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;UsabilidadeA 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;EficinciaO 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;ManutenibilidadeA 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;PortabilidadeA 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 44.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 autoavaliaesUm conjunto consistente de questionrios e pontuaesVerificao e certificao independentesUm 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 vidaSequencial 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 implementadoEvolucional 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.gilRADQuarta 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.3O (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 bem-sucedida 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-BRO 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/.ConclusoEste 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 55.Garantia de qualidade de softwareualidade, 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/AImportanciadoProcessodeGarantiadaQualidadedeSoftware.pdfmore: http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx#ixzz3T0fL9yb3Captulo 66.Verificao e validaoSistemas 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 validaoEm 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 cdigoTeste de softwareOrigem: 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 geral2 Princpios3 Tcnicas3.1 Caixa-branca3.2 Caixa-preta3.3 Caixa-cinza3.4 Regresso3.5 Tcnicas no funcionais4 Fases ou Nveis4.1 Teste de unidade4.2 Teste de integrao4.3 Teste de sistema4.4 Teste de aceitao4.5 Teste de operao4.5.1 Testes alfa e beta4.5.2 Candidato a lanamento5 O Ciclo de Vida dos Testes5.1 Planejamento5.2 Preparao5.3 Especificao5.4 Execuo5.5 Entrega6 Papis7 Artefatos8 Referncias9 Bibliografia10 Ver tambm11 Ligaes externasViso 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.2Falhas 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:FuncionalidadeConfiabilidadeUsabilidadeEficinciaManutenibilidadePortabilidadeDe 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.3Princpios[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-brancaTambm 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.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 caixa-branca 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-pretaTambm 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.7Caixa-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.Regresso[editar | editar cdigo-fonte]Ver artigo principal: teste de regressoEssa 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 unidadeTambm 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 integraoNa 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 sistemaNa 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 aceitaoGeralmente, 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 operaoNessa 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 alfaVer artigo principal: verso betaEm 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.EntregaEsta a ltima fase do ciclo de vida de testes, onde o projeto finalizado e toda documentao finalizada e arquivada.PapisSegue 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..)ArtefatosO 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 auditoriasO 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, cdigo-fonte) 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, contro