padroes de qualidade esperados

Upload: naldo-silva

Post on 05-Jul-2018

218 views

Category:

Documents


0 download

TRANSCRIPT

  • 8/16/2019 Padroes de Qualidade Esperados

    1/23

    Padrões esperados Qualidade de Software

    O principal objetivo da engenharia de software é ajudar a produzir software de qualidade.Conceitos de qualidade são imprecisos e difíceis de serem aceitos por todas as pessoas, no

    entanto, métricas de qualidade de software surgem desde a década de ! e v"m se desenvolvendode forma a ajudar no processo de desenvolvimento de software.

    # garantia de controle de qualidade de software est$ intimamente relacionada a atividadesde verifica%ão e valida%ão e estão presentes em todo o ciclo de vida do software. &m algumasorganiza%'es não e(iste distin%ão entre essas atividades. &ntretanto, a garantia de qualidade e os processos de verifica%ão e valida%ão de software devem ser atividades distintas. # garantia dequalidade é uma fun%ão gerencial, enquanto que a valida%ão e a verifica%ão são processostécnicos no desenvolvimento de software.

    )entre os modelos de gerenciamento de controle de qualidade de software mais

    conhecidos estão o Capabilit* +aturit* +odel C++- e o /O 0!!!12, que foram motivados pelas falhas nos processos de ger"ncia e manuten%ão durante o desenvolvimento de software3C&/#405.

    )efinir qualidade de software é uma tarefa difícil. +uitas defini%'es t"m sido propostas euma defini%ão decisiva poderia ser debatida interminavelmente.

     

    Controle de Qualidade

    6ela defini%ão da /O, controle de qualidade é 7a atividade e técnica operacionalque é utilizada para satisfazer os requisitos de qualidade8 3+c)ermid095.

    O controle de qualidade é feito através de uma série de inspe%'es, revis'es e testes,

    usados através do ciclo de desenvolvimento para garantir que cada trabalho produzido est$ deacordo com sua especifica%ão:requerimento. 6ortanto, o controle de qualidade é parte do processo de desenvolvimento e, como é um processo de  feedback , ele é essencial para minimizar os defeitos produzidos.

    Garantia de Qualidade

    # garantia de qualidade de software não é algo com o qual se come%a a pensar depois que o c;digo é gerado. #

    • métodos e ferramentas de an$lise, projeto, codifica%ão e teste?

    • revis'es técnicas formais que são aplicadas durante cada fase da engenharia desoftware?

    • uma estratégia de teste de m@ltiplas fases?• controle da documenta%ão do software e das mudan%as feitas nela?• um procedimento para garantir a adequa%ão aos padr'es de desenvolvimento

    de software, se eles forem aplicados?• mecanismos de medi%ão e divulga%ão.

  • 8/16/2019 Padroes de Qualidade Esperados

    2/23

  • 8/16/2019 Padroes de Qualidade Esperados

    3/23

    Custo relativo do conserto de um erro

      D!!! 9!1D!!! vezes

      D!! 2!1! vezes 

    DF19! vezes

      D! vezes  D!

      21G vezes

      D vez  D

     requisitos projeto codifica%ão desenv. teste sistema de teste manuten%ão

    Higura D

    Atributos de Qualidade de Software

    # qualidade de software não é uma idéia tão simples. I mais f$cil descrev"1la através deum conjunto de atributos ou fatores requeridos que variam de acordo com as diferentesaplica%'es e os clientes que as solicitam.

    &(istem v$rias formas de se classificar os fatores de qualidade. Jma delas é classific$1loscomo fatores e(ternos e fatores internos. Hatores e(ternos são aqueles cuja presen%a ou falta num produto de software pode ser detectada pelos usu$rios do produto velocidade, facilidade de uso-.Hatores internos são aqueles que são perceptíveis apenas por profissionais de computa%ãomodularidade-. #pesar de apenas os fatores e(ternos terem importKncia no final, a chave paraassegurar que eles são satisfeitos são os fatores internos, ou seja, as técnicas internas são um meio para atingir qualidade de software e(terna. #lguns atributos e(ternos são> corretude, robustez,e(tensibilidade, reusabilidade, compatibilidade, efici"ncia, portabilidade, verificabilidade,

    integridade e facilidade de uso 3+e*er5.Outra maneira de se classificar os atributos de qualidade é dividí1los em atributos

    funcionais e atributos não funcionais. Os atributos funcionais tipicamente se aplicam a peda%osdo software, m;dulos do sistema como um todo e estão mais relacionados com o qu" deve ser feito. L$ os atributos não funcionais podem se aplicar a qualquer produto do processo dedesenvolvimento> especifica%'es, c;digo, manuais, etc., e estão mais relacionados com o quão bem deve ser feito 3+c)ermid095.

  • 8/16/2019 Padroes de Qualidade Esperados

    4/23

    Métricas de Qualidade de Software

    Jm elemento chave de qualquer processo de engenharia é a medi%ão. M;s usamosmedidas para melhor entendermos os atributos dos modelos que criamos e, o mais importante éque n;s usamos medidas para avaliarmos a qualidade dos produtos de engenharia ou sistemas que

    n;s construímos.#o contr$rio de outras engenharias, a engenharia de software não é baseada emleis quantitativas b$sicas, medidas absolutas não são comuns no mundo do software. #o invésdisso, n;s tentamos derivar um conjunto de medidas indiretas que levam a métricas que fornecemuma indica%ão de qualidade de alguma representa%ão do software.

    &mbora as métricas para software não sejam absolutas, elas fornecem umamaneira de avaliar qualidade através de um conjunto de regras definidas.

    Boehm, Brown e Lipow

    6ara medir qualidade de software deve1se determinar quais característicasmedir e como medir. Boehm, Brown e Nipow D0- definem uma $rvore de atributos de

    qualidade de software bem definidos e bem diferenciados figura - 3/hn!5, onde as dire%'esdas setas indicam implica%'es l;gicas. 6or e(emplo, um programa que é f$cil de ser mantidodeve também ser facilmente testado, entendido e modificado.

    6ortabilidade ndependente )evice

    #uto Contido

    6recisão

    Confiabilidade Completude

    Jsabilidade 4obustez:ntegridade

    Consist"ncia&fici"ncia Hacilidade de +edi%ão

    &fici"ncia de )eviceJtilidade portabilidade, confiabilidade,efici"ncia, engenharia humana e facilidades de teste, uso e modifica%ão.

    #s características de mais bai(o nível são primitivas que podem ser combinadas para formar características de nível médio. #s características primitivas são

  • 8/16/2019 Padroes de Qualidade Esperados

    5/23

    recomendadas como métricas quantitativas delas pr;prias e das características de mais alto nível3/hn!5.

    Jma característica primitiva pode ser definida ou medida através de umachecklist . Ralores numéricos podem ser dados aos atributos de qualidade, em alguns casos isso

     pode ser apropriado, como por e(emplo, nos atributos de performance, e em outros pode e(istir um certo grau de subjetividade.Qais checklists  podem ser @teis, mas tendem a crescer e se tornarem

    incEmodas, surgindo a necessidade de uma organiza%ão específica e tornando1se específica parauma linguagem:sistema.

    Métricas para o Código Fonte !alstead"

    # ci"ncia de software de Palstead D0- prop'e as primeiras leis analíticas para o software de computador. &la usa um conjunto de medidas primitivas que pode ser derivadodepois que o c;digo é gerado, ou estimado assim que o projeto est$ 7completo8 3/hn!5.

    O método de Palstead é baseado na habilidade de se obter as seguintes

    medidas primitivas num programa>• n1 S o n@mero de operadores distintos que aparecem num programa?• n2 S o n@mero de operandos distintos que aparecem num programa?•  N1 S o n@mero total de ocorr"ncias de operadores?•  N2 S o n@mero total de ocorr"ncias de operandos.

    &ssas medidas podem ser melhor ilustradas através da seguinte subrotina emHO4Q4#M>

    /JB4OJQM& /O4Q T, M-)+&M/OM TM-H M .NQ. - 4&QJ4M

    )O ! S ,M  )O D! L S D,  H T- .

  • 8/16/2019 Padroes de Qualidade Esperados

    6/23

  • 8/16/2019 Padroes de Qualidade Esperados

    7/23

    6ara determinar a falta de ambigUidade dos requisitos, )avis e seus colegassugerem uma métrica que é baseada na consist"ncia da interpreta%ão dos revisores de cadarequisito> Q1 = nui%nr , onde nui é o n@mero de requisitos para os quais todos os revisores tiverama mesma interpreta%ão. =uanto mais perto de D esteja o valor de Q1, menos ambígua é a

    especifica%ão. # completude dos requisitos funcionais pode ser computada por Q2 = nu% (ni ns-, onde nu é o n@mero de requisitos de fun%ão @nicos, ni é o n@mero de entradas definidasou implicadas pela especifica%ão e  ns  é o n@mero de estados especificados. = mede a percentagem de fun%'es necess$rias que tenham sido especificadas para um sistema. 6arainserirmos os requisitos não funcionais nesta métrica, devemos considerar o grau de valida%ãodos requisitos> Q) = nc%(nc + nn*"# onde nc é o n@mero de requisitos que foram validados e nn* éo n@mero de requisitos que ainda não foram validados.

    Métricas para Sistemas (rientados a ()*etos

    /oftware orientado a objetos OO- é fundamentalmente diferente do

    software desenvolvido usando métodos convencionais. 6or esta razão, métricas usadas parasistemas OO devem focalizar as características que distinguem software OO de softwareconvencional 36ressman05.

    Berard 3Ber0F5 define cinco características que tratam métricasespecializadas> localiza%ão, encapsulamento, inforation hiding , heran%a e técnicas de abstra%ãode objetos.

    Nocaliza%ão é uma característica de software que indica a maneira na qualas informa%'es são concentradas dentro de um programa.

    &ncapsulamento é o empacotamento de uma cole%ão de itens. ,nforation hiding  esconde os detalhes operacionais de um componente de

     programa.

    Peran%a é um mecanismo que capacita a responsabilidade de um objeto ser  propagada para outros objetos.#bstra%ão é um mecanismo que capacita o projetista a focar nos detalhes

    essenciais de um componente de programa sem se preocupar com detalhes de bai(o nível.

    Métricas (rientadas a Classes# classe é a unidade fundamental de um sistema OO. Classes freqUentemente são

    superclasses de outras classes, as quais herdam seus atributos e suas opera%'es. #s classestambém colaboram com outras classes. Cada uma dessas características pode ser usada como base para uma métrica.

    Métricas C+ Chidamber e Vemerer 3Chi095 prop'em seis métricas de projeto baseadas em

    classes para sistemas OO>  1 6esos dos +étodos por Classe W+C-> assume que n métodos de comple(idade

    CD, C, ..., Cn são definidos para uma classe C. # específica métrica de comple(idade que éescolhida deve ser normalizada, tal que a comple(idade nominal para um método resulte novalor D.!.

    W+C S ΣCi, para i S D a n.

  • 8/16/2019 Padroes de Qualidade Esperados

    8/23

    O n@mero de métodos e suas comple(idades- é um indicador razo$vel paraimplementar e testar uma classe. /e o n@mero de métodos para uma dada classe e a $rvore deheran%a crescem, ela se torna mais e mais específica, limitando seu potencial de reuso. 6or todas essas raz'es, W+C deve ser conservado tão bai(o quanto possível.

    1 6rofundidade da Xrvore de Peran%a )Q-> &sta métrica é definida como otamanho m$(imo do n; A raiz da $rvore. Ma figura 2, o valor de )Q para a hierarquia declasse é 9.

    Com o crescimento do )Q, fica claro que classes de mais bai(o nível irão herdar muitos métodos. Jm problema com um valor alto para )Q é que e(iste uma potencialdificuldade de determinar o comportamento das classes de níveis mais bai(os, por outro lado,isso implica que muito métodos podem ser reusados.

    étricas Propostas por Loren e +iddNorenz e Vidd 3Nor095 dividem métricas baseadas em classes em quatro

    categorias> orientadas ao tamanho, baseadas na heran%a, internas e e(ternas. +étricasorientadas a tamanho em classes OO enfocam a contagem dos atributos e opera%'es para umaclasse individual e os valores médios para sistemas OO como um todo. +étricas baseadas emheran%a enfocam a maneira na qual opera%'es são reusadas através da hierarquia de classes.+étricas internas verificam a coesão e as características do c;digo, e métricas e(ternase(aminam o acoplamento e o reuso.

      1 Qamanho da Classe C/-> o tamanho total de uma classe pode ser determinadousando as medidas do n@mero total de opera%'es tanto opera%'es de instKncia privadas comoopera%'es de instKncia herdadas- que são encapsuladas dentro da classe e do n@mero deatributos tanto atributos de instKncia privados como atributos de instKncia herdados- que sãoencapsulados por uma classe.

    Como pode1se notar, grandes valores para C/ indicam que a classe pode ter muitaresponsabilidade, o que pode reduzir a reusabilidade da classe e tornar difícil a implementa%ãoe os testes. &m geral, opera%'es e atributos p@blicos ou herdados deveriam ter um peso maior na determina%ão do tamanho da classe. Opera%'es e atributos privados tornam possível aespecializa%ão e são mais localizados dentro do projeto.

    1 +édias para o n@mero das opera%'es e dos atributos de uma classe também podem ser computadas. =uanto menor esse n@mero médio, mais as classes podem ser reusadas.

    C

    CD

    CDD

    C

    CD C C2

    CDD

  • 8/16/2019 Padroes de Qualidade Esperados

    9/23

    1 M@mero de Opera%'es /obrescritas *erridden- por uma /ubclasse MOO->quando uma subclasse redefine uma opera%ão herdada isso é caracterizado um o*erriding .Ralores grandes para MOO geralmente indicam um problema de projeto.

    /e MOO é grande, o projetista violou a abstra%ão da superclasse, se isso acontecer 

    em alguns pontos do projeto, problemas de teste e manuten%ão podem surgir.1 M@mero de Opera%'es #dicionadas a uma Classe MO#-> /ubclasses sãoespecializadas pela adi%ão de atributos e opera%'es privadas. =uanto maior o n@mero MO#,mais específica se torna a classe, ficando longe do nível de abstra%ão proposto pelas suassuperclasses. &m geral, quanto maior o )Q menor os valores para MO# nas classes de nívelmais bai(o da hierarquia.

    1 Yndice de &specializa%ão /-> o índice de especializa%ão fornece uma indica%ãodo grau de especializa%ão para cada subclasse em um sistema OO. # especializa%ão pode ser alcan%ada adicionando:retirando opera%'es ou por o*erriding .

    / S 3MOO ( Mível5 : +total?onde Mível é o nível na hierarquia de classes na qual a classe reside e + total é o n@mero total de

    métodos da classe. Ralores altos para / indicam que na hierarquia de classes e(iste uma oualgumas- classe que não est$ de acordo com a abstra%ão da superclasse.

    Métricas para -estes em ((#s técnicas descritas até agora fornecem uma indica%ão da qualidade do projeto.

    &las também fornecem uma indica%ão geral da quantidade de esfor%o de testes requerido parasistemas OO. +étricas para teste são organizadas em categorias que refletem importantescaracterísticas de projeto>

    1 &ncapsulamento>Halta de Coesão nos +étodos NCO+-> valores altos para NCO+ implicam

    que mais estados deveriam ser testados para garantir que os métodos não geram efeitoscolaterais.

    6ercentagem 6@blica e 6rotegida 6#6-> atributos p@blicos são herdados deoutras classes e, por isso são visíveis para essas classes. #tributos protegidos são umaespecializa%ão e são privados para uma específica subclasse. &sta métrica indica a percentagem de atributos de classe que são p@blicos. #ltos valores para 6#6 aumentam a possibilidade de efeitos colaterais entre classes. Qestes devem ser projetados para garantir quetais problemas não venham a ocorrer.

    #cesso 6@blico para )ados 6#)-> esta métrica indica o n@mero de classesou métodos- que podem acessar outro atributo de uma outra classe uma viola%ão deencapsulamento-. Ralores altos para 6#) aumentam a possibilidade de efeitos colaterais entreclasses. Qestes devem ser projetados para garantir que tais problemas não venham a ocorrer.

    1 Peran%a> M@mero de Classes 4aiz MO4-> esta métrica é um contador do n@mero de

    hierarquias distintas de classes que são descritas no projeto do modelo. =uando MO4 éaumentado, o esfor%o para o teste também é.

    Han in HM-> =uando usado no conte(to OO, fan-in é uma indica%ão deheran%a m@ltipla. HM Z D indica que uma classe herda seus atributos e opera%'es de mais deuma classe raiz. HM Z D deveria ser evitado quando possível.

     M@mero de Hilhos MOC- e 6rofundidade na Xrvore de Peran%a )Q->métodos da superclasse devem ser retestados para subclasses.

  • 8/16/2019 Padroes de Qualidade Esperados

    10/23

    Métricas para Pro*eto ((Como sabemos, o trabalho de um gerente de projeto é planejar, coordenar,

    verificar a evolu%ão e controlar o projeto de software. Jm dos pontos chave para um gerentede projeto durante a fase de planejamento é uma estimativa do tamanho do software. Qamanho

    é diretamente proporcional ao esfor%o e dura%ão. #s seguintes métricas OO 3Nor095 podemfornecer uma idéia do tamanho do software>1 M@mero de /cripts de Cen$rio M//-> o n@mero de scripts de cen$rio, ou casos

    de uso, é diretamente proporcional ao n@mero de classes requeridas para encontrar osrequisitos, o n@mero de estados para cada classe e o n@mero de métodos, atributos ecolabora%'es. O M// é um forte indicador do tamanho do programa.

    1 M@mero de Classes Chaves MVC-> Jma classe chave enfoca diretamente odomínio do neg;cio para um determinado problema e ter$ uma probabilidade bai(a de ser implementada via reuso. 6or esta razão, valores altos para MVC indicam um substancialtrabalho de desenvolvimento. Norenz e Vidd 3Nor095 sugerem que entre ![ e 9![ de todasas classes em um típico sistema OO são classes chaves.

    1 M@mero de /ubsistemas M/JB-> o n@mero de subsistemas fornecem umentendimento da aloca%ão de recursos, do cronograma e do esfor%o total de integra%ão.

    Motivação para o uso de Métricas de Qualidade

    ndependentemente da métrica usada, elas buscam sempre os mesmos objetivos>• melhorar o entendimento da qualidade do produto?• atestar a efetividade do processo?• melhorar a qualidade do trabalho realizado a nível de projeto.

    Garantia de Qualidade de Software (SQA)

    Jm dos desafios críticos para qualquer programa de qualidade é tornar possível quequalquer pessoa possa fazer revis'es no trabalho de pessoas e(perientes.

  • 8/16/2019 Padroes de Qualidade Esperados

    11/23

    O nstituto de &ngenharia de /oftware /&- recomenda as seguintes atividades aserem realizadas por um grupo de /=#>

    • 6reparar um plano de /=# ver se%ão G.2- para o projeto. O plano édesenvolvido durante o planejamento do projeto e é revisado por todas as partes

    interessadas.• 6articipar do desenvolvimento da descri%ão do processo do projeto do software.

    O time de engenharia de software seleciona um processo para o trabalho a ser realizado. O grupo de /=# revisa a descri%ão do processo, verificando se omesmo est$ de acordo com a política organizacional, aos padr'es internos parao software, aos padr'es impostos e(ternamente e a outras partes do plano de projeto de software.

    • 4evisar as atividades dos engenheiros de software para verificar se o processode software definido est$ sendo seguido. O grupo de /=# identifica, documentae trilha os desvios do processo e verifica quais corre%'es devem ser realizadas.

    • corretude,habilidade para cumprir cronogramas, adaptabilidade, efici"ncia e, por fim aus"ncia de erros. &leadmite que e(istem controvérsias em rela%ão a quais vari$veis deveriam ser medidas e que efeitoelas podem ter na produtividade. \a] d$ a seguinte métrica para ta(a de programa%ão>

    4 S N:/Q-?

    onde 4 é a ta(a de programa%ão em linhas de c;digo fonte por pessoas1m"s? N é o n@mero delinhas de c;digo fonte do produto final? / é o nível do  staffing  e Q é o cronograma em meses-.&(iste um certo consenso em rela%ão aos critérios mais importantes de produtividade> qualidadeda documenta%ão e(terna, linguagem de programa%ão, disponibilidade de ferramentas,e(peri"ncia do programador no processamento dos dados, e(peri"ncia do programador na $reafuncional, comunica%ão no projeto, m;dulos independentes e pr$ticas de programa%ão bemdefinidas.

    Revisões de Software

    4evis'es de software são um filtro no processo de engenharia de software. sto é,revis'es são aplicadas a v$rios pontos durante o desenvolvimento de software e serve para

    descobrir erros que podem ser removidos. 4evis'es não são limitadas a especifica%ão, projeto ec;digo. )ocumentos, tais como, plano de teste, procedimentos de gerenciamento deconfigura%ão, padr'es e normas de usu$rio deveriam também ser revisados 3/ommerville05.

    &(istem v$rios tipos de revisão>• nspe%'es no projeto e no c;digo> t"m a finalidade de detectar erros no projeto

    ou c;digo e checar quando padr'es t"m sido seguidos.• 4evis'es gerenciais> esse tipo de revisão é feita para fornecer informa%'es aos

    gerentes sobre todo o processo no desenvolvimento do projeto de software.

  • 8/16/2019 Padroes de Qualidade Esperados

    12/23

    • 4evis'es de qualidade> o trabalho de um indivíduo ou de um time é revisado por um grupo composto por membros do projeto e gerentes técnicos.

    O dicion$rio de padr'es do &&& define defeito como uma 7anomalia do produto8.Jm defeito implica em um problema na qualidade que é descoberto depois que o software foi

    entregue ao usu$rio final.O objetivo prim$rio de revis'es técnicas formais é encontrar erros durante o processo antes que eles se tornem defeitos ap;s o release do software. Jm benefício ;bvio derevis'es técnicas formais é a descoberta de erros antes que eles se propaguem para as pr;(imasfases do processo de software.

    &studos de algumas ind@strias indicam que as atividades de projeto introduzementre F![ e G![ de todos os erros durante o processo de software. &ntretanto, técnicas derevis'es formais t"m atingido um percentual de F[ na descoberta desses erros, reduzindo ocusto dos passos subsequentes.

    Confiailidade

     Mão h$ d@vidas de que a confiabilidade de um programa de computador é umelemento importante para sua qualidade. /e um programa falha freqUentemente e repetidamente,não importa muito se outros fatores de qualidade são aceit$veis.

    Confiabilidade de software pode ser medida, direcionada e estimada usando dadoshist;ricos e de desenvolvimento. &la é definida em termos estatísticos como a 7probabilidade deuma opera%ão de programa de computador ser livre de falha8. 6ara ilustrar isto, digamos que um programa T é estimado ter uma confiabilidade de !.0G em oito horas de processamento, ou seja,se o programa T fosse e(ecutado D!! vezes em oito horas de processamento tempo dee(ecu%ão-, é prov$vel que ele opere corretamente sem falhas- em 0G das D!! vezes36ressman05.

    Jma questão que surge ao se discutir sobre qualidade é o que significa o termofalha. Mo conte(to de qualquer discussão sobre qualidade e confiabilidade de software, falha é anão conformidade com os requisitos de software. #inda e(istem grada%'es nesta defini%ão.Halhas podem ser apenas incEmodas ou catastr;ficas. Jma falha pode ser corrigida dentro desegundos, enquanto uma outra pode requerer semanas ou até mesmo meses para ser corrigida.#lém disso, a corre%ão de uma falha pode resultar na introdu%ão de outros erros que no finalresultam em outras falhas.

    Medidas de Confia)ilidade e &isponi)ilidade

    Os primeiros trabalhos em confiabilidade de software tentaram e(trapolar amatem$tica da teoria de confiabilidade de hardware para a previsão de confiabilidade desoftware. # maioria dos modelos relacionados A confiabilidade de hardware são estabelecidos emfalhas devido ao uso desgaste-, ao invés de falhas devido a defeitos de projeto, porque as falhasde desgaste físico são mais prov$veis de acontecer. nfelizmente, o oposto disto é verdade parasoftware.

    #inda e(iste debate sobre os relacionamentos entre os conceitos chave deconfiabilidade de hardware e sua aplicabilidade a software. &mbora e(ista uma liga%ão, éimportante considerar poucos conceitos simples que se aplicam a ambos.

    Considerando um sistema baseado em computador, uma simples medida deconfiabilidade é o tempo médio entre falhas +QBH-, onde>

  • 8/16/2019 Padroes de Qualidade Esperados

    13/23

    +QBH S +QQH ^ +QQ4,+QQH S tempo médio para a falha e +QQ4 S tempo médio para o reparo.

    +uitos pesquisadores argumentam que +QBH é uma medida mais @til do que defeitos:VNOC, pois um usu$rio final preocupa1se com falhas, e não com o n@mero total de defeitos. O n@mero

    total de defeitos fornece pouca indica%ão da confiabilidade de um sistema porque cada defeitodentro de um programa não tem a mesma ta(a de falha. +uitos defeitos num programa podem permanecer sem ser detectados por décadas +QBH longo- e, se eles são removidos, o impacto naqualidade de software é imperceptível 36ressman05.

    #lém da medida de confiabilidade, deve1se desenvolver uma medidade dedisponibilidade, a qual é a probabilidade de que um programa esteja operando de acordo com osrequisitos num dado ponto no tempo, e é definida como>

    )isponibilidade S +QQH:+QQH ^ +QQ4- T D!![.# medida de disponibilidade é mais sensível ao +QQ4, uma medida

    indireta da manutenibilidade de software.

    Seguran$a . Confia)ilidade

     Ma se%ão anterior, foi discutido o papel da an$lise da confiabilidade desoftware. Mão obstante, a confiabilidade e a seguran%a de software estejam estreitamenterelacionadas, é importante compreender a sutil diferen%a entre elas. # confiabilidade de softwareusa a an$lise estatística para determinar a probabilidade de que uma falha de software venha aocorrer. &ntretanto, a ocorr"ncia de uma falha não necessariamente resulta num risco oudeforma%ão. # seguran%a de software e(amina as maneiras segundo as quais as falhas resultamem condi%'es que podem levar a uma deforma%ão. Ou seja, as falhas não são consideradas novazio, mas são avaliadas no conte(to de um sistema inteiro computadorizado.

    /eguran%a de software é um atividade de garantia de qualidade de softwareque se concentra na identifica%ão e avalia%ão de casualidades em potencial que possam e(ercer 

    um impacto negativo sobre o software e fazer com que todo o sistema falhe.Nogo que as casualidades a nível de sistema são identificadas, técnicas dean$lise são usadas para definir a gravidade e a probabilidade de ocorr"ncia, tais como, an$lise em$rvore, l;gica de tempo real ou modelos de rede de 6etri. #p;s as casualidades seremidentificadas e analisadas, os requisitos relacionados A seguran%a podem ser especificados para osoftware.

    Controle de Qualidade

    Como fa!er Controle de Qualidade

    I possível observar que o controle de qualidade é algo que consome tempo no

    desenvolvimento de sistemas de software, e, é claro, vai além da entrega do sistema e entra nafase de manuten%ão. 6oderíamos generalizar dizendo que deveríamos identificar controle dequalidade sobre todos os produtos em cada est$gio. Qoda atividade deve culminar em umaatividade de controle de qualidade desejada.

    )esde que desejamos ser capazes de definir atividades de controle de qualidade para toda atividade durante o desenvolvimento, faz sentido verificar como as técnicas usadas paracada atividade podem contribuir para o controle de qualidade delas. #lgumas técnicas são boas,t"m controle de qualidade embutido, outras não t"m, e deve1se, então, aplicar a%'es de controlede qualidade gerais para fazer o controle eficientemente.

  • 8/16/2019 Padroes de Qualidade Esperados

    14/23

    Plano de SQA

    Cada projeto de desenvolvimento e manuten%ão deveria ter um 6lano de Controlede =ualidade /=#6- que especifica seus objetivos, as tarefas de /=# a serem realizadas, os padr'es contra os quais o trabalho de desenvolvimento é para ser medido e os procedimentos e a

    estrutura organizacional. O 6lano de /=# constitui um mapa rodovi$rio para a institui%ão dagarantia de qualidade de software.O padrão &&& 6adrão #M/:&&& 2!1D09 e 021D0G- para a prepara%ão do

    /=#6 contém os seguintes t;picos 3Pumphre*05>. 6rop;sito do plano. )ocumentos de refer"ncia. #dministra%ão

    #. Organiza%ãoB. QarefasC. 4esponsabilidades

    R. )ocumenta%ão

    #. 6rop;sitoB. )ocumentos de engenharia de software e(igidosC. Outros documentos

    R. 6adr'es, pr$ticas e conven%'es#. 6rop;sitoB. Conven%'es

    R. 4evis'es auditoriais#. 6rop;sitoB. 4equisitos de revisão

    1. 4evisão dos requisitos de software2. 4evis'es de projeto

    ). Rerifica%ão de software e revis'es de valida%ão/. #uditoria funcional0. #uditoria física. #uditorias in-process. 4evis'es administrativas

    R.

  • 8/16/2019 Padroes de Qualidade Esperados

    15/23

    # se%ão de padr'es, pr$ticas e conven%'es especifica um conte@do mínimo de>•  padr'es de documenta%ão?•  padr'es de estrutura l;gica?•  padr'es de codifica%ão?

    •  padr'es de coment$rios.# auditoria funcional é uma auditoria feita antes da entrega do sistema para

    verificar se os requisitos foram encontrados. # auditoria física também é feita antes da entrega dosistema para verificar se o software e a documenta%ão estão consistentes com o projeto e prontos para serem entregues. # auditoria in-process  é uma amostra estatística do processo dedesenvolvimento que é feita para verificar a consist"ncia do o c;digo versus as especifica%'es de projeto e interface, do projeto versus os requisitos e os planos de testes versus os requisitos. #srevis'es administrativas são revis'es independentes, conduzidas para a verifica%ão da e(ecu%ãodo plano de qualidade.

    +uitos dos padr'es são requeridos para definir apropriadamente a opera%ão deuma organiza%ão de software.

    Pessoas de SQA

    #locar pessoas para trabalhar com /=# é uma tarefa difícil dos gerentes desoftware. # pr$tica de iniciar novas contrata%'es em /=# é uma solu%ão parcial que pode ser efetiva apenas se e(istem pessoas e(perientes no mercado. 4ecrutar pessoas para trabalhar em/=# é difícil também porque os profissionais de software geralmente preferem atribui%'es dedesenvolvimento e a ger"ncia certamente quer atribuir aos melhores projetistas o trabalho de projeto. O esquema de rotatividade também pode ser efetivo, mas infelizmente, odesenvolvimento de software geralmente é adepto a transferir pessoas para trabalhar em /=# enão 7peg$1las8 de volta.

    Jma solu%ão efetiva é requerer que todos os novos gerentes de desenvolvimento

    sejam promovidos para trabalharem em /=#. sso poderia significar que potenciais gerentes poderiam passar entre seis meses e um ano em /=#, antes de serem promovidos A ger"ncia. &ssaé uma medida e(trema, mas pode ser efetiva 3Pumphre*05.

    6ara o trabalho de /=# ser efetivo, deve haver bons profissionais na equipe e umcompleto apoio da ger"ncia, no sentido de investimento mesmo.

    Sistemas de Gerenciamento de Qualidade

    Personal Software Process "PSP#

    O estímulo original para desenvolver o 6/6 surgiu de quest'es sobre o Capabilit*+aturit* +odel C++- do /oftware &ngineering nstitute /&-. +uitos viam o C++ como projetado para grandes organiza%'es e não entendiam como ele poderia ser aplicado a trabalhosindividuais e em times pequenos de projeto. #pesar do C++ poder ser aplicado para ambas, pequenas e grandes organiza%'es, uma orienta%ão mais específica se tornava claramentenecess$ria. #p;s alguns anos de pesquisa, D das D $reas1chave de processo do C++ ver se%ão .- foram adaptadas para o trabalho de engenheiros de software individuais.

    O principal objetivo do 6/6 é fazer com que os engenheiros de software fiquematentos no processo que eles usam para fazer seus trabalhos e estejam sempre verificando suas performances no processo. &ngenheiros de software são treinados individualmente para umconjunto de objetivos pessoais, definindo os métodos a serem usados, medindo seus trabalhos,

  • 8/16/2019 Padroes de Qualidade Esperados

    16/23

    analisando os resultados, e ajustando os métodos para atingir seus objetivos. O 6/6 é umaestratégia para o desenvolvimento pessoal com o objetivo de aumento de produtividade.

    Qrabalhos e(perimentais foram iniciados em algumas corpora%'es para verificar como engenheiros e(perientes poderiam reagir ao 6/6 e e(plorar a introdu%ão de seus métodos.

    Hoi verificado que os engenheiros de software geralmente são atraídos pela estratégia do 6/6 eencontram métodos que ajudam em seus trabalhos. Mas palavras de um engenheiro, 7sto não é para a empresa, é para mim8. O leitor interessado pode obter informa%'es adicionais em 3/&5 e3Pumphre*5.

    O 6/6 aplica princípios de processo para o trabalho do engenheiro de software por>

    • Hornecer um padrão de processo pessoal definido.• ntroduzir uma família de medidas de processo.• Jsar essas medidas para trilhar e avaliar a performance.• /e esfor%ar para obter critérios de qualidade e melhorar os objetivos.Jsando o 6/6, engenheiros>

    • )esenvolvem um plano para todo projeto.• 4egistram seu tempo de desenvolvimento.• Qrilham seus defeitos.• +ant"m dados de um projeto em relat;rios resumidos.• Jsam esses dados para planos de projetos futuros.• #nalisam dados que envolvem seus processos a fim de aumentar suas

     performances.

    Capailit$ Maturit$ Model "CMM#

    O +odelo de +aturidade de Capacidade para /oftware C++- foi desenvolvido

     pelo nstituto de &ngenharia de /oftware /&-. &le descreve os princípios e pr$ticas relacionadosA maturidade do processo de software, e seu objetivo é ajudar as organiza%'es a melhorarem seus processos de software em termos de um caminho evolutivo que vai de ad hoc  e processosca;ticos a processos de software maduros e disciplinados.

    O C++ é organizado em cinco níveis de maturidade. Jm nível de maturidade éuma base evolucion$ria bem definida direcionada a obter um processo de software maduro. Cadanível de maturidade fornece uma camada como base para um processo de melhora contínuo.

    (s Cinco /0'eis de Maturidade

    #s seguintes caracteriza%'es dos cinco níveis de maturidade destacam asmudan%as do processo prim$rio feitas em cada nível 36aul]095>

    D. nicial> O processo de software é caracterizado como ad hoc  e,ocasionalmente ca;tico mesmo. 6oucos processos são definidos e osucesso depende de esfor%os individuais e her;icos.

    . 4eproduzível> Os processos de administra%ão do projeto b$sico sãoestabelecidos para trilhar custo, cronograma e funcionalidade. #disciplina de processo necess$ria é estabelecida para se repetir sucessosanteriores em projetos com aplica%'es similares.

    2. )efinido> O processo de software para as atividades de administra%ão eengenharia é documentado, padronizado e integrado num processo de

  • 8/16/2019 Padroes de Qualidade Esperados

    17/23

    software padrão para a organiza%ão. Qodos os projetos usam umaversão aprovada e feita sob medida do processo de software padrão daorganiza%ão para desenvolvimento e manuten%ão de software.

    9. +edidas detalhadas do processo de software e da

    qualidade do produto são coletadas. #mbos, o processo de software e o produto, são entendidos e controlados quantitativamente.F. Otimizado> Jm processo de melhora contínuo é capacitado por retorno

    quantitativo do processo e das idéias e tecnologias inovadoras.

    1reas2Cha'e de Processo

    &(ceto para o nível D, cada nível de maturidade é decomposto em v$rias$reas1chave de processo que indicam as $reas que uma organiza%ão deveria enfocar paramelhorar seu processo de software. Cada $rea1chave de processo V6#- identifica um grupo deatividades relacionadas que, quando realizadas coletivamente, atingem um conjunto de objetivosconsiderados importantes para a melhoria da capacidade do processo.

    6or defini%ão, não e(istem $reas1chaves de processo para o nível D.#s $reas1chave de processo para o nível enfocam os interesses

    relacionados ao estabelecimento de controle b$sico de administra%ão de projeto.#s $reas1chave de processo para o nível 2 enfocam os problemas

    organizacionais e de projeto, como a organiza%ão estabelece uma infra1estrutura queinstitucionaliza uma engenharia de software efetiva e uma administra%ão de processos em todosos projetos.

    #s $reas1chave de processo para o nível 9 enfocam em estabelecer umentendimento quantitativo de ambos, o processo de software e o produto sendo construído.

    #s $reas1chave de processo para o nível F cobrem os problemas queambos, organiza%ão e projetos, devem endere%ar para implementar uma melhora contínua emensur$vel do processo de software.

  • 8/16/2019 Padroes de Qualidade Esperados

    18/23

    #tabela

    abai(omostratodasas$reas1chavede

     processo para cada nível de maturidade>

    6or conveni"ncia, cada uma dessas $reas1chave de processo é organizada por característicascomuns, que são atributos que indicam quando a implementa%ão e institucionaliza%ão de uma$rea1chave de processo é efetiva, reproduzível e dur$vel. /ão elas> Compromisso a 4ealizar,Pabilidade para 4ealizar, #tividades 4ealizadas, +edi%ão e #n$lise e Rerifica%ão damplementa%ão 36aul]095.

    Cada $rea1chave de processo é descrita em termos de pr$ticas chave quecontribuem para satisfazer seus objetivos. #s pr$ticas chave descrevem a infra1estrutura e asatividades que contribuem para a implementa%ão e institucionaliza%ão efetiva da $rea1chave de

     processo.%S& '(()

    Jm sistema de controle de qualidade pode ser definido em termos de estruturaorganizacional, responsabilidades, procedimentos, processos e recursos para implementar gerenciamento de qualidade. # série de padr'es /O 0!!! é um conjunto de documentos quetrabalham com sistemas de qualidade que podem ser usados para propostas de garantia dequalidade e(terna. O /O 0!!! 76adr'es de

  • 8/16/2019 Padroes de Qualidade Esperados

    19/23

    )iretrizes para /ele%ão e Jso8- descreve elementos de garantia de qualidade em termos genéricosque podem ser aplicados para qualquer empresa de produtos ou servi%os oferecidos.

    6ara uma empresa ser registrada com o certificado /O 0!!!, o sistema dequalidade da empresa e as opera%'es são investigadas por tr"s auditores para verificar se o padrão

    e as opera%'es estão de acordo com as normas estabelecidas. Rerifica%'es peri;dicas sãoefetuadas para verificar se os padr'es estão sendo mantidos.O modelo de garantia de qualidade /O 0!!! trata uma empresa como uma rede de

     processos interconectados. 6ara um sistema de qualidade estar de acordo com a /O, esses processos devem endere%ar as $reas identificadas no padrão e devem ser documentados e praticados como desejado. )ocumentar um processo ajuda uma organiza%ão a entender, controlar e melhorar o mesmo.

    O /O 0!!! descreve os elementos de sistemas de garantia de qualidade emtermos gerais. &sses elementos incluem a estrutura organizacional, procedimentos, processos erecursos necess$rios para implementar o plano de qualidade, o controle de qualidade, a garantiade qualidade e o melhoramento da qualidade. &ntretanto, o /O 0!!! não descreve como uma

    organiza%ão poderia implementar esses elementos de sistemas de qualidade.O /O 0!!D 7/istemas de =ualidade 1 +odelo para

    D.

  • 8/16/2019 Padroes de Qualidade Esperados

    20/23

    . dentifica%ão do produto e traceability. &ste tem sido um importante procedimento para desenvolvedores de software os quais, como outrosengenheiros, constr;em suas aplica%'es a partir de muitos componentes pequenos.

    0. Controle do processo. sto é um requerimento geral em que o processo de produ%ão ele mesmo deve ser planejado e monitorado.D!. nspe%'es e testes. O padrão requer que inspe%'es e testes devem ser feitos

    durante o processo de desenvolvimento. 4egistros dos testes devem ser conservados.

    DD. nspe%'es, medidas e testes de equipamentos. 6oderíamos considerar equipamentos como ferramentas de software, que devem ser controladas comrela%ão A qualidade, versão, etc.

    D. nspe%'es e  status do teste. # qualidade de todos os itens em todos osest$gios de seu desenvolvimento deve ser claramente conhecida e o status deteste deve ser conhecido de alguma forma todo o tempo.

    D2. Controle dos produtos que não estão em conformidade com o padrão.6rodutos que não estão enquadrados aos padr'es não devem ser usados.D9. #%ão corretiva. /e um erro é encontrado em um item quando uma

    checagem de controle é feita sobre ele e(istem duas coisas que devem ser feitas.6rimeiro, o erro deve ser removido do item? segundo, o processo envolvido nasua produ%ão necessita ser checado para verificar se ele deve ser trocado paraevitar que tal erro volte a acontecer.

    DF. +anuseio, armazenamento, empacotamento e entrega do produto. Jmaorganiza%ão que faz e vende um produto de software necessita considerar queseus produtos devem ser replicados de forma confi$vel, para garantir quevers'es corretas do software sejam entregues aos clientes corretos.

    DG. 4egistros de qualidade. O padrão requer que o desenvolvedor garanta queregistros suficientes são mantidos para demonstrar que a qualidade requeridatem sido alcan%ada e que o sistema de gerenciamento de qualidade est$operando eficientemente.

    D. #uditoria de qualidade interna.D. Qreinamento. /e a equipe não é adequadamente treinada para fazer seu

    trabalho é claro que o trabalho das pessoas da equipe não ir$ atingir o grau dequalidade desejado.

    D0. Ser*icing .!. Qécnicas estatísticas. /ão usadas para verificar a aceita%ão das

    características do produto.

    Comparação entre %S& '(() * CMM 

    O C++ e o /O 0!!D compartilham interesses comuns com qualidade egerenciamento de processo. #lém de possuírem interesses similares, eles são intuitivamentecorrelacionados.

    =uest'es que podem surgir quando comparando os dois são>• &m que nível do C++ poderia se encai(ar uma organiza%ão em conformidade

    com o /O 0!!D_

  • 8/16/2019 Padroes de Qualidade Esperados

    21/23

    • Jma organiza%ão de nível ou 2- no C++ poderia ser considerada emconformidade com o /O 0!!D_

    • +eus esfor%os na melhoria do processo e no gerenciamento de qualidadedeveriam ser baseados no /O 0!!D ou no C++_

    Jma an$lise feita das diferen%as e similaridades entre o C++ e o /O 0!!D indicaque, embora uma organiza%ão em conformidade com o /O 0!!D não necessariamente satisfariatodas as $reas1chave de processo do nível do C++, ela satisfaria a maioria dos objetivos donível e muitos dos objetivos do nível 2. )evido A e(ist"ncia de pr$ticas no C++ que não sãoendere%adas no /O 0!!D, é possível para uma organiza%ão no nível D receber um certificado /O0!!D? similarmente, e(istem $reas endere%adas pelo /O 0!!D que não são endere%adas no C++.Jma organiza%ão no nível 2 poderia ter pouca dificuldade em obter um certificado /O 0!!D, euma organiza%ão no nível poderia ter vantagens significativas em obter o mesmo certificado36aul]095.

    # maior diferen%a, contudo, entre esses dois documentos é a "nfase do C++ nocontínuo processo de melhora. O /O 0!!D enfoca o critério mínimo para um sistema de

    qualidade aceit$vel. #lém disso, o C++ enfoca estritamente o software, enquanto que o /O0!!D tem um escopo mais abrangente> software, hardware, materiais processados e servi%os.# maior similaridade é que para ambos, o C++ e o /O 0!!D, a linha base é

    7dizer o que fazer e fazer o que diz8. # premissa fundamental do /O 0!!D é que todo processoimportante deveria ser documentado e tudo que é entregue deveria ter sua qualidade testadaatravés de uma atividade de controle de qualidade. O /O 0!!D requer uma documenta%ão quecontém instru%'es ou um guia do que deveria ser feito ou como deveria ser feito. O C++compartilha essa "nfase em processos que são documentados. Risão Crítica sobre Controle de=ualidade de /oftware

    O grande problema no controle de qualidade de software é ainda a falta de consci"ncia demuitas empresas e profissionais que lidam com sistemas comple(os em adotarem uma política de

    qualidade nos trabalhos a serem desenvolvidos.Como prova disso, recorremos a uma pesquisa realizada em D00F pelo /ubprograma/etorial da =ualidade e 6rodutividade em /oftware //=6:/W-, onde foi indicado que3C&/#405>

    • apenas 2,0[ das empresas incluem sistematicamente metas ou diretrizes paraqualidade em seus planos?

    • F,D[ delas coletam sistematicamente indicadores de qualidade de seus produtos eservi%os?

    • apenas DD,F[ t"m um programa de qualidade total implantado?• a grande maioria F,0[- não conhece o modelo C++?• GG,G[ não adota nenhum procedimento específico de garantia da qualidade do

     produto de software?• a avalia%ão de desempenho dos funcion$rios é feita periodicamente em apenas DG,9[

    das empresas. F9,D[ delas disseram faz"1la informalmente.O importante não é o modelo a ser seguido. =uando o objetivo é otimizar a qualidade do

    software, deve1se ter cuidado, porém, em definir certos limites para os resultados a seremalcan%ados. # cria%ão de software com qualidade requer um esfor%o tanto a nível financeiroquanto a nível de conscientiza%ão das pessoas envolvidas no processo, sem, no entanto, saírmosda ;rbita em que o cliente é o termEmetro da qualidade de um determinado produto. +esmo se o produto software- alcan%ar grande parte dos requisitos de qualidade, mas ultrapassar uma data

  • 8/16/2019 Padroes de Qualidade Esperados

    22/23

    que seja de vital importKncia para o cliente, o produto não ter$ qualquer serventia e, por isso,deve1se ter um compromisso, com prazos e outras coisas mais e, em certos casos, é desej$velrestringir o escopo da qualidade partindo do m$(imo da qualidade para uma qualidade muito boa- a ser atingida, a fim de satisfazer as necessidades do cliente. &sta é uma visão realística de

    encarar qualidade de software nos sistemas a serem desenvolvidos.

    Notas

    =ualidade é um conceito comple(o, porque ela significa diferentes coisas para diferentes pessoas, ela é altamente dependente do conte(to. &ntão, não h$ uma simples medida paraqualidade de software que seja aceit$vel para todos os projetos de todas as empresas.

    6ara estabelecer ou melhorar a qualidade de software, o que se deve fazer é definir osaspectos de qualidade nos quais se est$ interessado e, então, decidir como fazer para medí1los.

    #ntes de projetar a qualidade num software, os desenvolvedores devem concordar nascaracterísticas que denotam a qualidade e nos termos que vão descrever essas características.#pesar dos custos elevados para a introdu%ão de certos sistemas de gerenciamento de

    qualidade de software, como o C++ ou o /O 0!!D, é importante tais métodos seremintroduzidos, a fim de que uma empresa sobreviva por um longo tempo e possa estar sempreatualizada, com um nível de produ%ão de software de alta qualidade, satisfazendo sempre asnecessidades de seus clientes.

  • 8/16/2019 Padroes de Qualidade Esperados

    23/23