1.

Introduo
Cotidianamente, qualquer pessoa normal avalia a qualidade de tudo a seu redor, conscientemente ou no, como forma de tomar decises. Desde a escolha da roupa para sair, at a compra de um carro. No to diferente do que acontece em nosso cotidiano, nas indstrias a qualidade passou a ser definida como a busca constante pelo melhor. Acompanhada por tentativas de identificar caractersticas que definam o melhor e mtodos de alcan-lo. Atualmente a qualidade se tornou to importante em mbito comercial, que manifestaes pblicas de preocupao com qualidade passaram a ser utilizadas como marketing por empresas. Isso tudo porque qualidade reflete diversas caractersticas positivas de um produto ou processo, e em geral est relacionada com uma melhor relao custobenefcio. Em um processo de qualidade normalmente no h desperdcio de tempo, h poucos defeitos, no h gastos desnecessrios. Observando todas essas vantagens de se obter qualidade, no poderia ser menor o interesse em se buscar formas de alcan-la tambm para processos e produtos de software. Um setor industrial que vem crescendo bastante nos ltimos tempos. A qualidade de software uma rea relacionada engenharia de software que objetiva identificar atributos em um processo e produto de software que determinem um nvel de qualidade. Ela tambm objetiva utilizar a familiaridade com esses atributos de forma a modific-los e obter um produto final com maior qualidade.

1.1. Movimento pela Qualidade

Atualmente, tcnicas para garantia de qualidade so essenciais para qualquer empresa, mas nem sempre foi assim. Antes do sculo XX, garantia de qualidade era de responsabilidade nica do arteso que criava o produto. A primeira implementao de garantia e controle de qualidade foi realizada no Bell Labs em 1916, e rapidamente se espalhou por outras empresas. Durante os anos 40 surgiram abordagens mais formais no controle de qualidade. Com o advento da Segunda Guerra Mundial, o governo dos Estados Unidos investiu maciamente na melhoria da produo nas indstrias fornecedoras do exrcito norte-americano, aplicando as novas abordagens formais para qualidade. No ps-guerra formas estatsticas de controle de qualidade j estavam implantadas em empresas do mundo todo. Edwards Deming, considerado por muitos o verdadeiro pai da qualidade, desenvolveu diversos trabalhos baseados na idia da melhoria contnua. A partir da dcada de 50, a verdadeira revoluo da qualidade ocorreu no Japo. Deming foi convidado a realizar diversas palestras a empresrios japoneses, tendo seus trabalhos implantados nas industrias japonesas e melhorados por estudiosos locais, como o ilustre Kaoru Ishikawa. Na dcada de 1970 e 1980 eles receberam nomes como Total Quality Management (Gesto de Qualidade Total). Apesar de receber diversos nomes entre companhias e autores, uma progresso bsica em 4 etapas normalmente encontrada em todas as implementaes:

Kaizen Focaliza na constante melhoria no processo, visando torn-lo visvel, mensurvel e possvel de ser repetido; Atarimae Hinshitsu busca otimizar o impacto de fatores que afetam um projeto, para permitir que ele flua da maneira planejada; Kansei observar a forma como o usurio aplica o produto, permite uma melhoria no produto e no processo que o origina; Miryokuteki Hinshitsu atravs da observao do produto no mercado, surge com novas oportunidades relacionadas ao produto que permitam sua melhoria. Atualmente a qualidade encontra-se na fase da gesto de qualidade, com o surgimento de diversas normas que padronizam a implantao de qualidade em diversos ramos empresariais. A histria da garantia de qualidade no desenvolvimento de software similar a da qualidade nas empresas tradicionais. Durante os primrdios da era da computao, a qualidade era preocupao apenas do programador. Padres para qualidade de software apareceram inicialmente nos contratos de desenvolvimento de softwares militares na dcada de 70 e se espalharam rapidamente no mundo comercial.

1.2. Custos da Qualidade

Como se pode imaginar, a implantao de estratgias para melhoria da qualidade em uma empresa tem custos. Estes custos esto relacionados com a preveno e avaliao do processo de forma a garantir sua qualidade. Alguns exemplos desses custos so: Planejamento Revises Testes Treinamento Inspeo do processo e entre processos Os custos da qualidade s vezes podem ser elevados, principalmente devido s dimenses e complexidade do processo. O investimento em qualidade, porm, vale muito apena, pois normalmente os custos obtidos pela falta de qualidade de um produto ou processo so bem maiores que aquele para implantao da qualidade.

2. Fatores da Qualidade de Software

A definio de qualidade que conhecemos em nosso cotidiano est bastante relacionada com caractersticas que nos deleitam em algo tangvel ou no. Pode-nos parecer fcil, s vezes, estabelecer comparaes quanto ao nvel de qualidade entre coisas, porm, pessoas diferentes possuem opinies. Isto acontece porque o conceito de qualidade que utilizamos totalmente subjetivo e baseado em experincias pessoais e gostos particulares. Esta definio no seria suficiente para se avaliar processos e produtos de forma tcnica e imparcial, nunca se chegaria a um acordo. Os esforos da engenharia de software tm como objetivo principal o desenvolvimento de um processo e produto de qualidade. Por isso a necessidade de uma definio formal para qualidade de software. Esta definio de qualidade de software tambm bastante discutida por diversos pontos de vistas, porm, para nosso estudo consideraremos os 3 fatores a seguir como determinantes para a qualidade: Cumprimento com os requisitos, visto que esses definem a funo para a qual ele deve ser desenvolvido e o principal foco da qualidade: o interesse do consumidor Padres de desenvolvimento especificados devem ser seguidos para qualquer projeto. Eles guiam a evoluo do projeto Cumprimento com os requisitos implcitos, a qualquer produto e projeto, por exemplo, usabilidade, bom desempenho, no desperdcio de recursos, otimizao do tempo, etc. Qualidade de software uma mistura complexa de fatores que variam de acordo com cada aplicao e com o consumidor. Os fatores citados acima so termos gerais para auxiliar nossa visualizao da qualidade em alto nvel. Na prtica so definidas caractersticas mais especficas representando esses fatores gerais.

2.1. Fatores de Qualidade de McCall

McCall definiu, em 1977, caractersticas que podem ser utilizadas at hoje como uma boa forma de se observar a qualidade de software:
1.

Eficincia a quantidade de recurso computacional e cdigo necessrio para um software realizar sua funo Integridade nvel de controle sobre o acesso dos dados e procedimentos que fazem parte de um software Confiabilidade a capacidade de o software manter seu funcionamento de forma adequada e com determinada preciso durante determinado tempo Usabilidade esforo necessrio do usurio para aprender e lidar com o aplicativo Exatido conformidade com as especificaes e os objetivos do usurio Sustentabilidade esforo para realizar a manuteno, achar e corrigir erros em um programa Testabilidade custo de teste do programa para garantir que ele esteja cumprindo seus requisitos

2.

3.

4.

5.

6.

7.

8.

Flexibilidade custo da modificao do produto Interoperabilidade custo para que dois produtos passem a interagir Re-usabilidade esforo para se reutilizar um programa ou parte dele Portabilidade esforo para se transferir um programa entre diversas plataformas de hardware ou de software, sobre o qual o mesmo funciona

9.

10.

11.

Esses atributos so bastante subjetivos, para que seja possvel definir um indicador de qualidade necessria a realizao de medies relacionadas a eles. Eles podem ser categorizados em fatores que podem ser medidos diretamente e fatores que s podem ser medidos indiretamente. Por isso foram definidas algumas mtricas que podem ter suas medies relacionadas a algumas dessas caractersticas:
Auditability esta mtrica est relacionada com a facilidade de se verificar se o software apresenta conformidade com determinados padres Preciso preciso dos controles e das funes Comunicabilidade o grau com que so usadas interfaces, protocolos e largura de banda Completeza nvel de totalidade da implementao de uma funo desejada Conciso a solidez, ou seja, realizao dos objetivos de forma mais compacta Consistncia uniformidade nas tcnicas de design e documentao Compartilhamento de dados o uso de estruturas de dados e tipos por todo o programa Tolerncia a erros a medida do dano causado por um erro ao programa Eficincia de execuo o desempenho do programa em execuo Expansibilidade capacidade de expanso de um programa Generalidade a quantidade de aplicaes potenciais para os componentes do programa Independncia de Hardware o grau de independncia entre o software e um hardware especfico Instrumentao o grau com que o programa monitora seu prprio funcionamento e identifica erros ocorridos Modularidade independncia entre os diversos componentes do programa Operabilidade a facilidade na operao do programa; Segurana a presena de mecanismos de proteo dos dados e da execuo do programa Auto-documentao o grau em que o cdigo fonte encontra-se auto-explicativo Simplicidade facilidade de entendimento do funcionamento do programa Independncia de sistemas de software independncia do programa em relao a outros softwares no padres Rastreabilidade capacidade de relacionar uma parte do projeto com o requisito original Treinamento medida com que o software auxilia no entendimento de novos usurios sobre a operao do sistema

A relao dessas mtricas com os fatores de qualidade mostrados anteriormente pode ser visualizada na figura 2.1. Mais mtricas e formas de medio da qualidade de software podem ser encontradas na seo sobre mtricas.

Fig

Ef ic i nc ia

In te gr id a d e

C o nf ia bi li d a d

U sa bi li d a d e

E xa ti d o

S us te nt a bi li d a

T es ta bi li d a d e

Fl ex ib ili d a d e

In te ro p er a bi li d

R eus a bi li d a d

P or ta bi li d a d e

Auditability Preciso Comunicabilidade Completeza Conciso Consistncia Compartilhamento de dados Tolerncia a erros Eficincia de execuo Expansibilidade Generalidade Independncia de Hardware Instrumentao Modularidade Operabilidade Segurana Auto-documentao Simplicidade Independncia de sistemas de software Rastreabilidade Treinamento

Existem ainda outros modelos de qualidade de software muito utilizados atualmente, como o ISO 9126, o FURPS, e o CMMI.

2.2. FURPS
A Hewlett-Packard desenvolveu um conjunto de fatores de qualidade de software que recebeu o acrnimo FURPS relacionado ao que define como os 5 principais fatores de qualidade:
1.

Funcionalidade obtido pelo conjunto das caractersticas e capacidades do programa, a generalidade das funes e a segurana do sistema em geral Usabilidade obtida considerando os fatores humanos: esttica, consistncia e documentao Confiabilidade (Reliability) obtida pela avaliao da freqncia e severidade dos erros, a preciso das sadas, o tempo mdio por falha, a habilidade para se recuperar de falhas e a previsibilidade do programa

2.

3.

4.

Performance medido pela velocidade de processamento, tempo de resposta, consumo de recursos computacionais, rendimento e eficincia Suporte combina a facilidade de realizar manuteno no programa, com a facilidade na realizao de testes, compatibilidade, facilidade de configurao, facilidade de instalao e facilidade em achar problemas

5.

2.3. ISO 9126

1.

O padro ISO 9126 foi desenvolvido em uma tentativa de se identificar os atributos chave de qualidade para um produto de software. Ele identificou 6 atributos: Funcionalidade o grau com que o software satisfaz necessidades definidas indicadas pelos seguintes sub-atributos: compatibilidade, preciso, interoperabilidade, conformidade, e segurana Confiabilidade a quantidade de tempo que o software est disponvel para utilizao, indicada pelos seguintes sub-atributos: maturidade, tolerncia a falhas, e capacidade de se recuperar de erros Usabilidade a medida que o software fcil de utilizar, indicado pelos seguintes subatributos: compreenso, operabilidade, e facilidade no aprendizado Eficincia a medida que o software otimiza a utilizao dos recursos do sistema, indicada pelos seguintes sub-atributos: comportamento no tempo, comportamento com o recurso Sustentabilidade a facilidade de manuteno, indicada pelos seguintes sub-atributos: facilidade de anlise, mutabilidade, estabilidade, e facilidade de teste Portabilidade a facilidade de se transpor um software de um ambiente para o outro, indicada pelos seguintes sub-atributos: adaptabilidade, facilidade de instalao, e facilidade de ser substitudo Como pode ser observado os fatores de qualidade deste padro ISO no proporciona medio diretamente. Porm um conjunto de atributos de software que valem apena se analisar.

2.

3.

4.

5.

6.

2.4. Uma Viso Quantitativa

Nas sees anteriores descrevemos uma srie de atributos relacionados qualidade de software. Uma tendncia atual a tentativa de abordar a qualidade de uma forma mais quantitativa, que garanta avaliar a qualidade de forma numrica. O problema dessa abordagem a impossibilidade de medir os fatores de qualidade diretamente. Por exemplo, o que significaria um nvel de usabilidade de 100 pontos? ou uma portabilidade de 10? As caractersticas da qualidade no podem ser medidas, apenas algumas de suas manifestaes atravs de outras variveis que normalmente no esto diretamente associadas caracterstica. Na seo a seguir falaremos de algumas mtricas que possuem relao com a qualidade de software.

3. Mtricas de Qualidade de Software

As mtricas de software podem ser classificadas em 3 categorias: Mtricas de produto - Descrevem caractersticas do produto como tamanho, complexidade, caractersticas referentes a design, performance e nvel de qualidade. Mtricas de processo - Usadas para melhorar o desenvolvimento e a manuteno do software. As principais medidas envolvem a eficcia na remoo de defeitos detectados durante o desenvolvimento, o tempo de resposta de um determinado processo, dentre outros. Mtricas de projeto - Descrevem as caractersticas do projeto e a execuo dele. Para fazer a medio utilizam-se dados como o nmero de desenvolvedores, o custo, o planejamento feito e a produtividade, por exemplo. De uma forma geral, as mtricas de qualidade de software esto mais focadas nos aspectos qualitativos do produto e do processo do que no projeto. No entanto, devemos analisar a qualidade de software durante todo o ciclo de vida do software incluindo, para tanto, mtricas para medir em nvel de qualidade na manuteno do processo.

3.1.

Meios de avaliao
Embora existam muitas formas de medir a qualidade de um software alguns indicativos merecem destaque, so eles: Conformidade: Um programa precisa operar corretamente ou ter pouco valor para os usurios. Conformidade o medida com que o software se comporta de acordo com a funo desejada. A medida mais usada para conformidade a de defeitos por KLOC (milhares de linhas de cdigo), na qual um defeito definido como sendo uma no de conformidade de requisitos. Um defeito tambm pode ser considerado como um problema reportado pelo usurio depois de o programa ter sido entregue para uso ou, de acordo com o IEE, qualquer anomalia no produto um defeito. Para fins de anlise de qualidade os defeitos so contabilizados em

perodos de por exemplo, um ano. A experiencia diz que mais 95% dos defeitos de um software so encontrados at 4 anos depois da concluso dos trabalhos e liberao do programa. A mtrica LOC (Linhas de cdigo lines of code, no ingls) muito simples, no entanto existem algumas divergncias na contagem das linhas. As principais variaes conhecidas so: Contar apenas linhas executveis; Contar linhas executveis e definies de dados; Contar linhas executveis e definies de dados e comentrios; Contar linhas executveis e definies de dados, comentrios e linhas de controle de linguagem; Contar como linhas fsicas; Contar somente as linhas terminadas em delimitadores (da linguagem). A diferena no tamanho do programa, resultante das diferentes forma de contagem das linhas difcil de mensurar. No se sabe qual mtodo resulta em um nmero maior. Em algumas linguagens como BASIC, PASCAL e C vrias intrues podem ser descritas em uma nica linha (fsica). Por outro lado, declaraes de dados podem requerer vrias linhas. Outras linguagens, como FORTRAN, que tem um formato de colunas fixas podem ter o nmero de linhas fsicas e instrues bem prximos. Manutenibilidade: manutenibilidade a facilidade com a qual um programa pode ser corrigido se ocorrerem erros, adaptado se o meio mudar ou aprimorado se o cliente desejar. No existe uma maneira de medi-la diretamente, no entanto, podemos usar medidas indiretas. Uma mtrica simples, orientada ao tempo a MTTC ( tempo mdio de modificaes, do ingls mean-time-to-change), o tempo mdio que se gasta para analisar a nova modificao solicitada, criar a interface, implementar, testar e distribui-la para todos os usurios. Ou seja, quanto maior a manutenibilidade de um programa, menor ser seu MTTC em relao aos demais, quando comparadas mudanas/implementaes de mesmo tipo. Hitachi usou uma mtrica orientada ao custo chamada spoilage, que indica o custo para corrigir um defeito encontrado depois que o software foi entregue aos usurios finais. Quando a mdia spoilage de um projeto inteiro lotada em funo do tempo, o administrador do projeto pode determinar se a manutenibilidade do software produzido est melhorando ou no e tomar as atitudes cabveis. Integridade: A intergridade do sotware tem se tornado cada vez mais importante nessa poca de hackers e firewalls. Este atributo mede a habilidade de um sistema de resistir a ataques segurana, sejam eles intencionais ou acidentais. Ataques podem ser feitos em qualquer um dos 3 componentes de um software: programa, dados e documentos. Para medir integridade dois atributos adicionais precisam ser definidos: ameaa e segurana: Ameaa a probabilidade de um ataque de um tipo especfico acontecer em um dado momento. Segurana a probabilidade de um ataque de um determinado tipo ser repelido. Portanto, a integridade de um sistema pode ser definida como: Integridade =
1 X 1 ] [ ameaa segurana ,para cada ataque.

Usabilidade: A usabilidade depende de quanto familiarizado com o usurio est o desenvolvedor, e pode ser quantificada em termos de 4 caractersticas: (1) o conhecimento

fsico e intelectual necessrio para estudar o sistema, (2) o tempo requerido para ficar moderadamente eficiente no uso do sistema, (3) o aumento da produtividade quando o sistema usado por algum moderadamente eficiente, (4) uma avaliao subjetiva (alguma vezes conseguida atravs de um questionrio) do usurio.

3.2. Outras abordagens

Uma outra abordagem trata a qualidade de software sob dois aspectos: pela medio dos atributos internos (tipicamente medidas estticas de produtos intermedirios), ou pela medio dos atributos externos (tipicamente medidas do comportamento do cdigo quando executado), ou ainda pela medio dos atributos de qualidade em uso. O objetivo que o produto tenha o efeito desejado em um contexto particular de uso.

A figura acima mostra a relao entre essas especificaes, cujos conceitos veremos a seguir: Qualidade interna a totalidade de caractersticas do produto de software na viso interna. A qualidade interna medida e avaliada em termos dos requisitos de qualidade interna. Detalhes da qualidade do produto de software podem ser melhoradas durante a implementao, reviso e teste do cdigo, mas a natureza fundamental da qualidade do produto de software representada pela qualidade interna permanece inalterada a menos que se planeje novamente. Qualidade externa estimada a qualidade que estimada ou prevista para o produto sinal de software em cada estgio de desenvolvimento para cada caracterstica de qualidade, baseada no conhecimento da qualidade interna. Qualidade externa a totalidade de caractersticas do produto de software do ponto de vista externo. a qualidade quando o software executado, que tipicamente medida e avaliada durante o teste de um ambiente simulado com dados simulados usando mtricas. Durante o teste, a maioria das falhas deveria ser descoberta e eliminada. No entanto, algumas falhas ainda podem permanecer mesmo aps o teste. Como difcil corrigir a arquitetura do software ou outros aspectos fundamentais de projeto do software, o projeto essencial normalmente permanece inalterado por todo o teste.

Qualidade em uso a viso do usurio da qualidade do produto de software quando utilizado em ambiente e contexto de uso estabelecidos. Ela mede o quanto os usurios podem alcanar seus objetivos em um ambiente particular, em vez de medir as propriedades do software propriamente dito.

Uma forma de avaliar essas caractersticas atravs de uma tabela de avaliao respondida pelos usurios, como exemplificada a seguir:

Caracterstica Funcionalidade Satisfaz as Necessidades?

Subcaracterstica Adequao Acurcia (preciso) Interoperabilidade Conformidade Segurana de acesso Maturidade Tolerncia a falhas Recuperabilidade Intelegibilidade Apreensibilidade (Aprendizagem) Operacionalidade Tempo Recursos Analisibilidade (Legibilidade) Modificabilidade

Pergunta-chave 1.1 Faz o que apropriado? 1.2 Faz o que foi proposto da melhor forma? 1.3 Interage com outros sistemas? 1.4 Est de acordo com as normas, leis e etc.? 1.5 Permite o acesso no autorizado aos dados?

Sim X X X

No

X X 3 X X X 3 X X X 3 x 1 2

Total parcial Confiabilidade imune a falhas? Total parcial Usabilidade fcil de usar?

2.1 Apresenta frequentemente falhas? 2.2 Ocorrendo falhas, reage de apropriada? 2.3 Recupera dados em casa de falha?

forma

3.1 fcil entender o conceito e a aplicao? 3.2 fcil aprender a usar? 3.3 fcil de operar e controlar? 4.1 O tempo de resposta rpido? 4.2 Utiliza poucos recursos? 5.1 fcil de encontrar uma falha, quando ocorre? 5.2 fcil modificar e adaptar?

Total parcial Eficincia rpido ? Total parcial Manutenibili_ dade fcil de

0 X 1 X X

Modificar ? Total parcial Portabilidade fcil de usar em outro Ambiente ?

Estabilidade Testabilidade Adaptabilidade Capacidade de ser instalado Conformidade Capacidade para substituir

5.3 H grande risco quando se faz alteraes? 5.4 fcil testar quando se faz alteraes? 6.1 fcil adaptar a outros ambientes? 6.2 fcil instalar em outros ambientes? 6.3 Est de acordo com padres portabilidade? 6.4 fcil usar para substituir outro? de

X X 1 X X X X 4 15 0 6 3

Total Parcial Total Geral

Qualidade em uso
O Modelo de Qualidade em Uso do produto de software se preocupa em conceituar e avaliar a qualidade do produto de software sob o ponto de vista do usurio, dentro de um ambiente e um contexto estabelecido de utilizao. Qualidade em Uso a viso de qualidade que o usurio tem do software e medida em termos do resultado da utilizao do software. a capacidade que o produto de software tem de atender aos anseios e s necessidades dos usurios em seu prprio ambiente de trabalho. Portanto, Qualidade em Uso de um produto depende do tipo de usurio que o est utilizando. Os atributos da qualidade em uso so categorizados em quatro caractersticas: efetividade, produtividade, segurana e satisfao.

Efetividade: definida como sendo a capacidade do produto de software possui de possibilitar ao usurio atingir metas especificadas com acurcia e completeza, em um contexto de uso especificado. Produtividade: definida como sendo capacidade do produto de software possui de possibilitar aos usurios utilizar uma quantidade adequada de recursos em relao efetividade alcanada em um contexto de uso especificado. Segurana: definida como sendo a capacidade do produto de software possui de oferecer nveis aceitveis de risco de danos a pessoas, negcios, software, propriedade ou ao ambiente,

em um contexto de uso especificado. Satisfao: refere-se capacidade do produto de software satisfazer usurios em um contexto de uso especificado. No que se refere satisfao do cliente, podemos ressaltar ainda que segundo a NBR ISO 9001, como uma das medies do desempenho do sistema de gesto da qualidade, a organizao deve monitorar informaes relativas percepo do cliente sobre se a organizao atendeu aos requisitos do cliente. Os mtodos para obteno e uso dessas informaes devem ser determinados. As principais abaixo: mtricas de satisfao constam na tabela

3.3. Modelo de qualidade CMMI

O que CMMI ? CMMI significa Capability Maturity Mode Integration e um modelo de qualidade criado pela SEI (Software Engineering Institute) para ser um guia destinado a melhorar os processos organizacionais e a habilidade desses em gerenciar o desenvolvimento, a aquisio e a manuteno de produtos e servios. O CMMI organiza as prticas, que j so consideradas efetivas, em uma estrutura que visa auxiliar a organizao a estabelecer prioridades para melhoria e tambm fornece um guia para a implementao dessas melhorias. O CMMI uma evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O primeiro passo a ser dado a identificao atravs de um mtodo definido pelo SEI (SCAMPI SEI Members of the Assessment Method Integrated Team, 2001) e conduzido por um avaliador credenciado do estgio em que a empresa se encontra no presente; uma vez que

este denota um nvel de maturidade a ser alcanado pelas empresas, visando ajud-las no desenvolvimento e manuteno dos projetos de software, como tambm melhorar a capacidade de seus processos. Aps a verificao do estgio da empresa, verifica-se qual a prxima etapa a ser alcanada e quais as competncias que devem ser adquiridas neste processo. Esta fase importante, pois permite alcanar o sucesso e, conseqentemente, melhoria na qualidade dos servios e produtos fornecidos pela rea de tecnologia da Empresa. O CMMI est dividido em cinco estgios (nveis de maturidade): Nvel 1: Realizao Estgio inicial; Nvel 2: Gerenciado Gerenciamento de requisitos, planejamento de projeto, monitoramento e controle de projeto, gerenciamento de fornecedores, medio e anlise, garantia da qualidade do processo e do produto, gerenciamento de configurao; Nvel 3: Definido Desenvolvimento de requisitos, soluo tcnica, integrao do produto, verificao e validao, foco no processo organizacional, definio do processo organizacional, treinamento organizacional, gerenciamento de riscos, gerenciamento integrado do projeto, anlise da deciso e resoluo; Nvel 4: Quantitativamente gerenciado Gerenciamento quantitativo do projeto, performance do processo organizacional; Nvel 5: Em otimizao Anlise causal e resoluo, inovao organizacional e implantao. A cada estgio esto associadas certas competncias, como veremos a seguir: 1- REALIZADO Estgio inicial completa falta de planejamento e controle dos processos. Os funcionrios esto focados basicamente em atividades corretivas que surgem a todo momento. 2-GERENCIADO So estabelecidos processos bsicos de gerenciamento de projeto para planejar e acompanhar custos, prazos e funcionalidades. Compromissos so firmados e gerenciados. A disciplina de processo permite repetir sucessos de projetos anteriores em aplicaes similares. Tipicamente, possui gerenciamento de projetos estabelecido; alguns procedimentos tcnicos escritos; acompanhamento de qualidade; gerncia de configurao inicial; atividades bsicas de medio e anlise. O sucesso depende basicamente do gerenciamento do projeto. 3-DEFINIDO Atividades de gerenciamento bsico e as de Engenharia de Software so documentadas, padronizadas e integradas em processos-padro. Todos os projetos de desenvolvimento ou manuteno de softwares utilizam uma verso de um desses processos adaptada s caractersticas especificas de cada projeto. Possui processos gerencias e tcnicos bem definidos, possibilidade de avaliao do processo; ferramentas e metodologias padronizadas; medies iniciais de desempenho; inspees e auditorias rotineiras; testes padronizados; gerncia de configurao; evoluo controlada dos processos tcnicos e gerenciais.

4-QUANTITATIVAMENTE GERENCIADO Mtricas detalhadas do processo de software e da qualidade do produto so coletadas. Tanto o processo como o produto de software so quantitativamente compreendidos, avaliados e controlados. Relatrios estatsticos so gerados. Tipicamente, encontra-se estabelecido e em uso rotineiro um programa de medies, a qualidade planejada por um grupo dedicado, sendo rotineiramente avaliada e aprimorada 5- EM OTIMIZAO A melhoria contnua do processo estabelecida por meio de sua avaliao quantitativa e da implantao planejada e controlada de tecnologias e idias inovadoras. Projetos-piloto so realizados para a absoro e internalizao de novas tecnologias. Tipicamente, um alto nvel de qualidade e de satisfao dos clientes alcanado rotineiramente, com grande foco na melhoria contnua. Deve-se lembrar de que no basta saber onde se deseja chegar; preciso traar o caminho que se ir trilhar para atingir o objetivo. Nesta tarefa, a metodologia CMMI tambm socorre, dividindo cada estgio em reas de processo e para cada uma delas so definidos dois conjuntos de metas: as especficas e as genricas. A essas metas, a definio do modelo recomenda prticas genricas divididas em um conjunto de caractersticas comuns que por sua vez se divide em quatro categorias. So elas: Comprometimento com a execuo Agrupa prticas relacionadas definio de polticas e responsabilidades, descrevendo aes para assegurar que o processo se estabelea e seja duradouro; Habilitao para execuo Agrupa prticas contendo pr-condies para o projeto, de forma a permitir a implementao adequada do processo; Direcionamento a implementao Agrupa prticas relacionadas ao gerenciamento do desempenho do processo; Verificao da implementao Agrupa prticas para reviso junto alta gerncia e avaliao objetiva da conformidade com processos, procedimentos e padres. As metas especficas, na maioria das vezes, esto focadas no negcio da empresa e buscam alinhar a metodologia CMMI s necessidades prprias; por sua vez as metas comuns focam em aspectos inerentes a qualquer empresa e devem ser considerados para a correta implementao da metodologia, de forma a garantir a maximizao dos resultados. As categorias acima descritas devero ser consideradas em qualquer estgio com o qual uma empresa se identifique dentro da metodologia exposta. Elas buscam direcionar as aes de forma a garantir que o ciclo de evoluo seja completado, possibilitando a implementao de uma evoluo contnua dos processos e do produto como um todo.

Histrico de Avaliaes At o ano de 2002, os EUA tinham realizado 1,5 mil avaliaes de CMMI, a ndia feito 153, o Reino Unido 103 e o Brasil apenas 15. Em 2004 a TATA Consultancy Services alcanou o nvel 5 em todas as unidades da empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber o nvel mximo na avaliao). Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliaes em 1377 organizaes. Segue abaixo o resultado obtido pelas empresas na avaliao (resultados encaminhados para o SEI at 30 de junho de 2006): 18,2%: nvel 5 4,4%: nvel 4 33,8%: nvel 3 33,3%: nvel 2 1,9%: nvel 1 8,4%: sem qualificao. No Brasil, so apenas quatro empresas que conseguiram realizar a certificao at o final, ou seja, alcanaram o nvel 5 do CMMI (por ano da certificao): Ano 2004 2005 2006 2007 Empresa TCS (TATA Consultancy Services) Brazil IBM Brazil Politec Ci&T

4. SQA: Garantindo a Qualidade do Software

SQA, referente a Software Quality Assurance ou simplesmente Garantia da Qualidade de Software, o conjunto de atividades realizadas juntamente com o projeto de um software voltadas a garantir que, no final, um produto considerado de qualidade seja entregue ao consumidor. A definio de um software de qualidade j foi abordada neste trabalho, porm, esta tambm sujeita interpretao do chamado grupo de SQA, o conjunto de pessoas responsveis pela implementao da SQA.

4.1. Atividades da SQA

A garantia da qualidade de software apresenta uma variedade de tarefas relacionadas a dois grupos principais de pessoas: os engenheiros de software realizando o trabalho tcnico e o grupo de SQA responsvel pelo planejamento para garantia da qualidade, observao, registro, anlise e prestao de contas. Os engenheiros de software auxiliam o alcance da qualidade atravs da utilizao de mtodos tcnicos slidos e a constante reviso e medio de seus resultados. O grupo de SQA auxilia o time de desenvolvimento a alcanar o produto de qualidade, gerenciando as atividades relacionadas. O Instituto de Engenharia de Software (SEI) recomenda uma srie de atividades de responsabilidade do grupo de SQA que permitem alcanar os objetivos de qualidade: Preparao de um plano de SQA desenvolvido paralelamente ao planejamento do projeto e deve ser revisado por todos os stakeholders. Ele governa as atividades de SQA desenvolvidas pelo time de desenvolvimento e pelo grupo de SQA. O plano identifica: 6. Avaliaes; 7. Auditorias; 8. Padres aplicveis ao projeto; 9. Procedimento para tratamento e comunicao dos erros encontrados; 10. Documentos a serem produzidos pelo grupo de SQA; 11. Informaes que devem ser retornadas pelo time de desenvolvimento; Participao no desenvolvimento do processo de software para o projeto o grupo de SQA deve revisar a descrio do processo de software definido, e verificar conformidade com polticas organizacionais, padres de qualidade internos e externos. Reviso das etapas do processo de software e verificar o cumprimento com o planejado Identificar, rastrear e documentar desvios em relao ao projeto, verificar se as correes foram realizadas. Verificar que todo desvio no processo e no produto esteja documentado, assim como sua soluo, de forma detalhada. Registrar toda desobedincia ao planejado e comunicar ao gerente do projeto resolver todo desvio em uma etapa do processo antes que esta seja considerada finalizada.

4.2. Plano de SQA

O plano de SQA, como foi previamente descrito, serve como um guia para as atividades relacionadas gesto de qualidade em um projeto de software. Um padro muito utilizado para o plano de SQA o desenvolvido pela IEEE desde 1994. Comentaremos aqui as partes constituintes da verso de 2002 deste plano. Na parte inicial do plano so indicados os objetivos e o escopo do plano, assim como as atividades do processo de software que so cobertas pelo SQA. Na parte administrativa, indicado o posicionamento da SQA na estrutura organizacional, as tarefas relacionadas a ela em um processo de software e as responsabilidades relativas a qualidade do produto. A seo de documentao descreve cada um dos tipos de documentos gerados pelo processo de software e define o mnimo desses aceitvel para se alcanar qualidade. Os documentos gerados so: 2. Documentos de projeto 3. Modelos 4. Documentos tcnicos 5. Documentos de usurio A seo de padres, prticas, convenes e mtricas deve identificar os padres, prticas, convenes, tcnicas estatsticas utilizadas, requisitos de qualidade, e mtricas a serem aplicadas. Medies do produto e do processo devem ser includas nesta seo e detalhadas em um plano de medidas separadamente. Na seo de revises de software, devem ser identificada cada reunio de reviso do processo do software. Ela deve conter uma viso geral da abordagem de cada reunio e os participantes (entre desenvolvedores, grupo de SQA e consumidores). A seo de teste referencia ao plano de teste do projeto, que determina tcnicas para obteno dos dados definidos pelas mtricas. Considerando o foco deste trabalho na qualidade do software, descreveremos a seguir apenas o processo utilizado para melhoria contnua da mesma atravs de revises, sem nos aprofundar na descrio formal dos documentos gerados e nos testes.

4.3. Revises do Software

Pode-se dizer que no processo de desenvolvimento de um software as revises em cada etapa agem como um filtro de impurezas. Essa comparao se justifica, pois, nas revises so descobertos diversos erros que, posteriormente, podem ser corrigidos, purificando o produto, que neste caso o software. As revises tm como objetivo principal verificar a necessidade de melhorias no processo, ou confirmar a inexistncia dela. Alm disto, empregar revises de software auxilia a alcanar um trabalho tcnico mais uniforme nos projetos de uma empresa, com nveis de qualidade mais previsveis entre processos. Muitas formas de revises podem ser empregadas. Uma conversa informal no horrio do almoo sobre o servio j considerada uma reviso. Porm, existem tcnicas mais

eficientes que podem ser empregadas como as revises tcnicas formais que descreveremos posteriormente.

Falhas e Custos
Em um processo de software, falhas podem ser encontradas durante o desenvolvimento e aps a entrega do produto ao usurio. O objetivo principal das revises, discutidas anteriormente, o de identificar a maioria dos erros durante a produo do software de forma que poucos ou nenhum deles continuem presentes aps a entrega do produto. A presena de falhas no processo ou no produto normalmente causam nus ao projeto. Esses podem ser custos internos com retrabalho, conserto e busca da falha, ou aps a entrega do produto com resoluo de problemas, devoluo ou substituio do produto, suporte tcnico, e em casos mais graves pode gerar processos jurdicos para indenizaes por parte do cliente. Por isso, em um processo de software, vale a regra quanto mais cedo se descobrir uma falha melhor, e menos onerosa ela se torna. A figura 4.1, baseada em dados coletados do livro Software Engineering Economics (Boehm -1981), compara o custo de correo de erros em etapas diferentes do processo de software.

Fig

Um conjunto de estudos indicou que 50% a 65% de todos os erros de um processo de software so introduzidos na fase de design. Porm, tcnicas formais de reviso mostraram eficincia de 75% em descobrir falhas de design. A remoo dessas falhas antes que se propaguem para etapas posteriores diminui o custo dessas etapas. Em 1981, foi desenvolvido pela IBM um modelo de amplificao de falhas, que pode ser usado para ilustrar a gerao e deteco de erros durante as fases no desenvolvimento de um software. O modelo ilustrado na figura 4.2.

Fig Uma caixa representa uma etapa no processo do software, com os erros gerados nesta etapa. Revises falhariam em identificar erros gerados em etapas anteriores, ento esses se repetiriam, assim como alguns desses erros poderiam ser amplificados pelo trabalho na etapa atual, ambos so tambm representados na caixa. Ela tambm representa a eficincia no processo de deteco dos erros naquela etapa, que pode ser tanto devido s revises quanto pelos testes. A figura 4.3 mostra um exemplo hipottico de um processo de software. Neste exemplo consideramos que nenhum erro gerado nas fases de teste (o que uma estimativa otimista) e que 50% dos erros so detectados por cada fase de teste. No final nos deparamos com 12 falhas existentes na entrega do produto. A figura 4.4 mostra a melhora ocasionada neste processo pela adio de revises desde as primeiras etapas do processo, e a diminuio de falhas existentes na entrega do produto. Usando-se as estimativas de custos mostradas anteriormente pode-se ter uma idia da economia resultante da implantao de revises nos processos de software. Vale ressaltar que a eficincia na deteco de erros no processo de reviso funo da eficcia e do investimento nesta.

Fig

Fig

4.3.1. Revises Tcnicas Formais

Esta atividade de SQA, uma implementao possvel de reviso de software, realizada pelos engenheiros de software do projeto e o grupo de SQA. Os objetivos dessas revises so: Descobrir falhas em funes, lgica ou implementao para qualquer representao do software Verificar se o software cumpre os seus requisitos Garantir que ele seja representado segundo os padres predefinidos Alcanar um desenvolvimento de maneira uniforme Desenvolver projetos mais controlveis Cada sesso de RTF deve focalizar em uma parte bem especfica do processo, quanto menor o foco mais eficiente ela ser em cumprir seus objetivos. Exemplos de possveis focos so uma poro dos requisitos, um componente do design, uma lista de cdigos fontes de um componente, etc. Antes da reunio ocorrer, o produtor (que realiza o trabalho) informa o chefe de projeto que seu produto de trabalho est pronto para reviso. O chefe de projeto informa o chefe de reviso que verifica se o produto de fato est pronto para reviso e distribui copias do material

para revisores se prepararem para a reunio. O chefe de reviso tambm estuda o material e prepara uma agenda para a reunio. A reunio composta de 3 a 5 pessoas: o chefe de reviso, 2 ou 3 revisores e o responsvel pelo produto de reviso. Um dos revisores ficar responsvel por registrar o que foi determinado em cada reunio. O produtor apresentar o material enquanto os revisores o questionam. Ao fim de cada reunio os revisores devem decidir se o produto ser aceito, no ser aceito e ficar sujeito a nova reviso aps correo, ou ser aceito temporariamente visto correo de pequenos erros. Em cada reunio dessas produzido um resumo de reviso que identifica quem foi revisado, o que foi revisado, e as concluses. Esse documento incorporado no histrico do projeto.

4.4. SQA Estatstica

Um seguimento da comunidade de engenheiros de software tem debatido que uma maneira mais formal de garantir a qualidade de software necessria. Eles acreditam que uma abordagem mais matemtica possvel para se medir a qualidade de softwares. As seguintes etapas devem ser seguidas para se obter SQA estatstica: 7. Os erros de software so coletados e divididos em categorias 8. feita uma tentativa de relacionar cada erro com causa 9. Segundo o principio de Pareto (80% dos erros podem ser ligados a 20% das causas), isolar os 20% dos problemas responsveis pela maioria dos erros 10. Corrigir esses problemas Usando essas etapas torna-se possvel a criao de um processo de engenharia de software adaptativo atravs da observao dos erros e causas nos processos de uma empresa durante determinado tempo. Pode-se ento definir estratgias para resolver os problemas que causam os erros, de treinamentos a novas contrataes. As principais causas de erros no desenvolvimento de softwares so: Especificaes erradas ou incompletas (IES) Interpretao errada dos interesses do cliente (MCC) Desvio intencional das especificaes (IDS) Violao dos padres programados (VPS) Erro na representao dos dados (EDR) Interface de componente inconsistente (ICI) Erro na lgica de design (EDL) Teste incompleto ou errneo (IET) Documentao incompleta ou imprecisa (IID) Erro na traduo do modelo de design para a linguagem de programao (PLT) Interface homem/mquina inconsistente ou ambgua (HCI) Outros (MIS) Uma tabela com a relao entre os problemas e o numero de erros mostrada na figura 4.5, e permite avaliar os 20% das causas que devem ser corrigidas inicialmente. Neste caso elas so IES, MCC e EDR. Por exemplo, para se corrigir os erros na representao dos dados, uma empresa poderia investir em treinamento dos profissionais responsveis por essa funo.

Alm das informaes relativas aos problemas, pode-se calcular ndices de erros usando os dados obtidos. O ndice de erro de uma fase obtido como mostrado a seguir:

o ndice de erro so os pesos relacionados aos erros graves, moderados e triviais respectivamente so o numero de erros graves, moderados e triviais respectivamente o numero total de erros em uma etapa Um ndice de erro geral para um processo pode ser obtido atravs da soma ponderada dos ndices de erro de cada etapa, cujos pesos so maiores quanto mais tarde a etapa aparece no processo.

5. Concluso
A importncia da qualidade em qualquer ramo do conhecimento indiscutvel, especialmente na engenharia de software. O desenvolvimento de tcnicas e mtodos que permitam a avaliao do processo durante todo o ciclo de vida do software crucial para que o produto final entregue ao cliente esteja dentro das especificaes desejadas, assegurando a qualidade do produto. Adotando-se essa postura os custos diminuem e a necessidade de manuteno diminui e mesmo quando esta necessria feita de forma mais fcil. A portabilidade do sistema tambm outra caracterstica importante, j que as necessidades dos clientes esto em constante modificao. Esses e outros atributos de um produto aumentam significativamente a competitividade das empresas.

As pessoas esquecem o quo rpido voc fez uma coisa, mas sempre o quo bem ela foi feita. Howard Newton

Demora menos tempo fazer uma coisa direito do que explicar porque voc fez errado. Henry Longeflow

Bibliografia
Pressman, Roger. Software Engineering A practitioner's approach, 5th Edition, McGrawHill, 2005. Machado, Mrcio P. , Souza, Sotrio F., Mtricas e qualidade de software.Departamento de Informtica Universidade Federal do Esprito Santo. Inthurn, Cndida. Qualidade e Testes de Software , 2005. http://www.tiinside.com.br, acessado em 10/05/2008 http://www.wikipedia.org, acessado em 05/05/2008 Kan, Stephen H. ,Metrics and Models in Software Quality Engineering, 2th Edition, Addison Wesley, 2002.