INSTITUTO MILITAR DE ENGENHARIA KLEYNA MOORE ALMEIDA

Transcrição

1 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO SECRETARIA DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA (Real Academia de Artilharia, Fortificação e Deenho 1792) Kleyna Moore Almeida GARANTIA DA QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO BASEADO EM REUSO: UMA ABORDAGEM NO CONTEXTO DO MINISTÉRIO DA DEFESA E DE SEUS COMANDOS SUBORDINADOS Rio de Janeiro 2004

2 INSTITUTO MILITAR DE ENGENHARIA KLEYNA MOORE ALMEIDA GARANTIA DA QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO BASEADO EM REUSO: UMA ABORDAGEM NO CONTEXTO DO MINISTÉRIO DA DEFESA E DE SEUS COMANDOS SUBORDINADOS Diertação de Metrado apreentada ao Curo de Metrado em Engenharia de Software do Intituto Militar de Engenharia, como requiito parcial para a obtenção do título de Metre em Ciência da Computação. Orientador: Ten Cel Ulf Bergmann D.C. Co-orientador: Cel Joé Antônio Moreira Xexéo D.C. Rio de Janeiro 2004

3 c2004 INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80 Praia Vermelha Rio de Janeiro RJ CEP: Ete exemplar é de propriedade do Intituto Militar de Engenharia, que poderá incluí-lo em bae de dado, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a tranmião entre biblioteca dete trabalho, em modificação de eu texto, em qualquer meio que eteja ou venha a er fixado, para pequia acadêmica, comentário e citaçõe, dede que em finalidade comercial e que eja feita a referência bibliográfica completa. O conceito expreo nete trabalho ão de reponabilidade do() autor(e) e do() orientador(e).??? Almeida, Kleyna Moore Garantia da qualidade de oftware no deenvolvimento baeado em reuo: uma abordagem no contexto do Minitério da Defea e de eu comando ubordinado / Kleyna Moore Almeida Rio de Janeiro: Intituto Militar de Engenharia, 2004.??? p.: il., tab. 29,7 cm. Diertação (metrado) Intituto Militar de Engenharia, Proceo de Qualidade. 2. Técnica de Leitura. 3. Revião. 4. Indicadore. I. Intituto Militar de Engenharia. II. Título.???CDD 625.1

4 INSTITUTO MILITAR DE ENGENHARIA KLEYNA MOORE ALMEIDA GARANTIA DA QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO BASEADO EM REUSO: UMA ABORDAGEM DO MINISTÉRIO DA DEFESA E DE SEUS COMANDOS SUBORDINADOS Diertação de Metrado apreentada ao Curo de Metrado em Engenharia de Software do Intituto Militar de Engenharia, como requiito parcial para a obtenção do título de Metre em Ciência da Computação. Orientador: Ten Cel Ulf Bergmann - D. C. Co-orientador: Joé Antônio Moreira Xexéo D. C. Aprovada em 06 de agoto de 2004 pela eguinte Banca Examinadora: Ulf Bergmann D. C. do IME - Preidente Joé Antônio Moreira Xexéo D. C. do IME Soeli Tereinha Fiorini D. C. da e-dablio Conultoria e Projeto Ltda Rio de Janeiro

5 Ao vovô, meu marido e filho pelo apóio e incentivo de meu aprimoramento. Ao meu pai que empre me orientaram e contribuíram para minha formação educacional e profiional. 4

6 AGRADECIMENTO Agradeço a toda a peoa que me incentivaram, apoiaram e poibilitaram eta oportunidade de ampliar meu horizonte, epecialmente: Ao meu orientadore Ulf Bergmann e Joé Antônio Moreira Xexéo, por ua diponibilidade e atençõe; A todo o profeore, pelo conhecimento tranmitido e ao funcionário do Departamento de Engenharia de Sitema do IME pelo apoio e atenção; À amiga Claudia Hazan e Miriam Sayão, e à minha irmã Kenya pelo apoio no momento de dúvida; Ao amigo de turma da PUC-RJ e do IME pelo companheirimo e amizade; À bibliotecária Roane da PUC-RJ pela atenção em toda à veze que preciei de livro e artigo para etudo e deenvolvimento do meu trabalho; Ao Centro de Apóio a Sitema Operativo e à Diretoria de Adminitração da Marinha pelo apoio e incentivo; Ao Intituto Militar de Engenharia (IME) pelo apoio e atenção. 5

7 Quando e pode medir o que etá falando e exprear io em número paa-e a conhecer algo mai obre io; ma quando não e pode exprear em número, eu conhecimento é uperficial e inatifatório. LORD KELVIN 6

8 SUMÁRIO LISTA DE ILUSTRAÇÕES LISTA DE TABELAS LISTA DE ABREVIATURAS E SÍMBOLOS LISTA DE SIGLAS INTRODUÇÃO Motivação Objetivo Vião Geral do Proceo Propoto Organização FUNDAMENTOS TEÓRICOS Engenharia de Qualidade Tete Inpeçõe de Software Reviõe Técnica de Leitura de Software Técnica de Leitura Baeada em Perpectiva Técnica de Leitura Orientada a Objeto Programa de Medição de Software Mediçõe Tática e Hard para Projeto OO Técnica de Avaliação Goal/Quetion/Metric - GQM Practical Software Meaurement - PSM Lidando com Reuo Proceo de Reuo

9 2.2.2 Modelo e Métrica PROCESSO DE GARANTIA DA QUALIDADE DE SOFTWARE BASEADO EM REUSO SISTEMÁTICO DE ASSETS Etrutura Organizacional do Grupo de Garantia da Qualidade de Software Garantindo a Qualidade Proceo de Controle de Qualidade - PCQ Nível de Gerenciamento Nível Técnico Subproceo de Verificação SPV Subproceo de Revião SPR Subproceo de Medição e Avaliação SPM Proceo de Aprovação de Aet ESTUDO DE CASO Planejamento do Etudo de Cao Definição do Contexto do Etudo de Cao Hipótee do Etudo de Cao Condução do Etudo de Cao Duração do Etudo Cao Participante do Etudo Cao Objetivo do Etudo de Cao Monitoração do Etudo de Cao Etapa: Garantindo a Qualidade Etapa: Subproceo de Verificação Planejamento da Verificação Verificação Etapa: Subproceo de Revião Planejamento da Revião Revião Etapa: Subproceo de Medição e Avaliação Planejamento da Medição Indicadore de Qualidade do Proceo de Verificação e Revião (IQPVR)

10 Indicadore de Produtividade do Proceo de Verificação e Revião (IPPVR) Indicadore de Qualidade do Projeto OO Baeado em Reuo (IQPOOR) Medição Avaliação do Etudo de Cao CONCLUSÕES Benefício Trabalho Futuro REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICES APÊNDICE 1: ESTUDO SOBRE OS TIPOS DE REUSO APÊNDICE 2: RESUMO DOS PRINCIPAIS MODELOS E MÉTRICAS APÊNDICE 3: PRINCIPAIS NORMAS Indicadore de produto de oftware Ciclo de Vida do Software no Padrõe da ISO Proceo Voltado a Reuo de Aet pela IEEE APÊNDICE 4: CHECKLISTS E TÉCNICAS DE LEITURA Artefato: Checklit Artefato: Técnica de Leitura Horizontal Artefato: Técnica de Leitura Vertical ANEXOS ANEXO 1: PROPOSTA DO PROCESSO DE CICLO DE VIDA DO SOFTWARE BASEADO EM REUSO NO CONTEXTO DO MD ANEXO 2: ARTEFATOS DOS PROCESSOS DE ENGENHARIA DE DOMÍNIO E DESENVOLVIMENTO BASEADO EM REUSO NO CONTEXTO DO MD GLOSSÁRIO DE TERMOS TÉCNICOS E EXPRESSÕES USADAS

11 LISTA DE ILUSTRAÇÕES FIG (a) Ciclo PDCA de Deming, adaptado de (FALCONI,1999). (b) Epiral de acenão da qualidade FIG : Diagrama de relacionamento da etapa de deenvolvimento de projeto e o tipo de tete aplicado a cada etapa FIG : Comparação de deenvolvimento de oftware com e em inpeçõe FIG : Diagrama de relação do artefato produzido e a inpeçõe de oftware FIG : Conjunto de TLOO FIG : Procedimento para reúo de oftware FIG. 3-1: Ecopo do Proceo de Garantia da Qualidade de Software FIG : Etrutura da área do Grupo da Garantia da Qualidade de Software (GGQS) FIG : Grupo da Garantia da Qualidade de Software (GGQS) no contexto do MD FIG : Proceo de Garantia da Qualidade do Software FIG : Proceo de Controle de Qualidade ao Nível de Gerenciamento FIG : Proceo de Controle de Qualidade ao Nível Técnico FIG : Ampliação do Proceo de Garantia da Qualidade do Software FIG : Diagrama de Contrução do Subproceo de Verificação (SPV) FIG : Diagrama de Contrução do Subproceo de Revião (SPR) FIG : Conjunto da Técnica de Leitura Horizontal e Vertical FIG : Diagrama de Contrução do Subproceo de Medição e Avaliação (SPM) FIG : Proceo de Aprovação de Aet (PAA) FIG : Diagrama de Contrução do Proceo de Aprovação de Aet (PAA) FIG : Cronograma do etudo de cao do protótipo Controlador Tático FIG : Plano de GQS do Projeto (PGQSP)

12 FIG : Hitórico de verõe FIG : Cronograma para a verificaçõe e reviõe de GQS do projeto FIG : Quetionário de Sugetõe para Melhoria da Garantia da Qualidade FIG : (a) PGQSP do projeto Controlador Tático FIG : (b) Cronograma de verificação do artefato Neceidade do Cliente e Gloário FIG : (c) Hitórico de Verõe do checklit para Neceidade do Cliente e Gloário FIG : (d) Parte do checklit do artefato Neceidade do Cliente e Gloário FIG : (e) Relatório de Verificação para Neceidade do Cliente e Gloário FIG : (a) Iten do Checklit de Neceidade do Cliente e Gloário FIG : (b) Comentário do iten do Checklit de Neceidade do Cliente e Gloário que não etão em conformidade FIG : (c) Relatório de Verificação de Neceidade do Cliente e Gloário FIG : (a) Técnica de Leitura Vertical (TLV1) FIG : (b) Relatório da Revião FIG : (a) Tabela de Dicrepância para Técnica de Leitura Vertical FIG : (b) Tabela de Dicrepância para Técnica de Leitura Horizontal FIG : (c) Detalhamento de Dicrepância para Técnica de Leitura FIG : (d) Quetionário de Sugetõe para Melhoria da Garantia da Qualidade (QSMGQ) preenchido pelo revior de TLH FIG : Modelo para definição de proceo de oftware FIG : O nívei de maturidade do CMM FIG : Componente do Modelo CMMI repreentação Organizado FIG : Proceo de ciclo de vida da ABNT com a extenõe para proceo de ciclo de vida de reúo da IEEE

13 LISTA DE TABELAS TAB : Técnica de inpeção de oftware e ua caracterítica TAB : Sei atributo de qualidade de projeto OO TAB : A métrica de projeto para avaliar a propriedade de projeto TAB : Parcela da funçõe de medição de (BANSIYA et al., 2002) TAB : Conjunto de artefato para revião TAB : Tipo de aet produzido pelo Proceo de Deenvolvimento de Software baeado em Reúo na MD TAB : O principai objetivo, pergunta e métrica relativo ao etado da nãoconformidade encontrada durante a verificação e revião do artefato TAB : O principai objetivo, pergunta e métrica relativo à previibilidade de eforço aociado à verificação e revião do artefato TAB : O objetivo, pergunta e métrica relativo à qualidade do projeto OO TAB : Funçõe de cálculo da mediçõe da qualidade do projeto OO com o índice definido por (BANSIYA et al., 2002) TAB : Epecificação do Indicador de Qualidade do Proceo de Verificação e Revião TAB : Formulário aociado ao procedimento de Coleta de Dado TAB : Formulário aociado ao procedimento para Análie do Dado TAB : Reultado da Coleta de Dado do Checklit e Técnica de Leitura TAB : Reultado do dado coletado para o indicadore de IQPOOR TAB : Reultado da mediçõe para o indicadore etabelecido no Planejamento da Medição TAB : Reumo da principai métrica e modelo de reúo de oftware TAB : Indicadore de qualidade do produto da norma ISO/IEC : TAB : Proceo do Ciclo de Vida do Software no padrõe da ISO

14 LISTA DE ABREVIATURAS E SÍMBOLOS ABREVIATURAS ADC Acoplamento Direto da Clae CMC Coeão entre Método na Clae MAD Medida de Aceo ao Dado MAF Medida de Abtração Funcional MAg Medida de Agregação NHq Número de Hierarquia NM Número de Método NMA Número Médio de Anteceore NMP Número de Método Polimorfo TIC Tamanho da Interface da Clae TPC Tamanho do Projeto em Clae SÍMBOLOS Σ Símbolo matemático de omatório 13

15 LISTA DE SIGLAS ABNT Aociação Braileira de Norma Técnica ACM Aociation for Computing Machinery APF Análie por Ponto de Função CGQS Conultor de GQS CMM Capability Maturity Model CMMI Capability Maturity Model Integration COCOMO Contructive Cot Modeling COTS Commercial Off The Shelf GGQS Grupo da Garantia da Qualidade de Software GQS Garantia da Qualidade de Software GQT Gerência pela Qualidade Total GQM Goal/Quetion/Metric ICP Indicador de Compreenibilidade do Projeto IEC International Electro Technical Commiion IEEE Intitute of Electrical and Eletronic Engineer IEfP Indicador de Efetividade do Projeto IEP Indicador de Extenibilidade do Projeto IFPUG International Funcion Point Uer Group IFuP Indicador de Funcionalidade do Projeto IFxP Indicador de Flexibilidade do Projeto IME Intituto Militar de Engenharia IPPVR Indicador de Produtividade do Proceo de Verificação e Revião IPqM Intituto de Pequia da Marinha IQPOOR Indicadore de Qualidade do Projeto OO Baeado em Reúo IQPVR Indicador de Qualidade do Proceo de Verificação e Revião IRP Reuabilidade do Projeto ISO International Organization for Standardization KPA Key Proce Area LOC Line Of Code (linha de código) MD Minitério da Defea NIST National Intitute of Standard and Technology 14

16 OO Orientado a Objeto PAA Proceo de Aprovação de Aet PCQ Proceo de Controle da Qualidade PDCA Plan-Do-Check-Act (Ciclo de Deming) PF Ponto de Função PSM Practical Software Meaurement PGQS Proceo da Garantia de Qualidade de Software PGQSP Plano de Garantia de Qualidade de Software do Projeto QSMGQ Quetionário de Sugetõe para Melhoria da Garantia da Qualidade SADT Structure Analyi and Deign Technique SEI Software Engineering Intitute SEPIN Secretaria da Política de Informática SPICE Software Proce Improvement and Capability determination SPM Subproceo de Medição e Avaliação SPR Subproceo de Revião SPV Subproceo de Verificação TLH Técnica de Leitura Horizontal TLOO Técnica de Leitura Orientada a Objeto TLV Técnica de Leitura Vertical UML Unified Modeling Language 15

17 RESUMO A garantia da qualidade de oftware no deenvolvimento baeado em reuo é um do principai fatore para aegurar e controlar a qualidade do proceo de deenvolvimento de oftware e do artefato gerado, viando poterior reutilização. Um Proceo de Garantia de Qualidade de Software é definido por meio de um conjunto de atividade itemática para aegurar a adequação ao reuo de artefato, viando obter maior produtividade e melhoria da qualidade de um proceo de deenvolvimento de oftware baeado em reuo de aet (artefato criado com o propóito explícito de erem poteriormente reutilizado). Ete proceo promove o deenvolvimento de projeto e de aet de forma eficaz com bae em apecto qualitativo e quantitativo. O indicadore quantitativo aeguram um melhor planejamento e controle de projeto e de aet, do reuo no deenvolvimento de aplicaçõe, utilizando métrica e modelo de oftware, indicadore de qualidade, produtividade e reuabilidade. Ete trabalho etá baeado na definiçõe de padrõe de proceo mai utilizado atualmente pela indutria e organizaçõe, tai como, CMM, CMMI, ISO 9000, ISO e ISO 15504, além da Norma IEEE1517. O proceo etabelecido nete trabalho abrangem diferente nívei de maturidade do CMM, tai como, ponto de revião e checklit na divera fae do proceo de deenvolvimento de oftware (Nível 3 - Definido), e também a definição de um proceo de medição (Nível 4 - Gerenciado). A verificaçõe e reviõe empregam técnica de leitura baeada em perpectiva e técnica de leitura horizontal e vertical repectivamente. A implantação do proceo deenvolvido nete trabalho poui quatro fae: implantação de um proceo de garantia de qualidade no proceo de deenvolvimento de aet; definição do modelo de qualidade do artefato, do objetivo da avaliação e de indicadore; aplicação de técnica de qualidade; e utilização do indicadore para promover a melhoria do proceo. Além dio, é apreentado um etudo de cao aplicando o proceo de garantia de oftware etabelecido em um projeto piloto, Controlador Tático, deenvolvido com bae no proceo de Deenvolvimento de Software Baeado em Reuo no Contexto do Minitério da Defea e de eu Comando Subordinado de GURGEL (2004). Ete etudo de cao aponta que a etratégia utilizada pode proporcionar a melhora da qualidade do modelo conceitual final aim como no proceo de produção de oftware para reuo mai produtivo. 16

18 ABSTRACT The oftware quality warranty in development baed on reue i currently a topic of a great interet, mainly due to the need of auring and controlling the quality of the oftware development proce and of the generated product, under the perpective of ubequent reue. In order to increae productivity and improve the quality of a oftware development proce baed on aet reue (oftware product created with the explicit purpoe of later reue), a Software Quality Warranty Proce i defined by a group of ytematic activitie deigned to aure the adaptation needed to reue oftware product. So, thi proce promote aet and project development in an effective way baed on qualitative and quantitative apect. The quantitative indicator conit on auring a better planning and control of aet and project, a well a the reue on application development, by applying metric, oftware model, quality indicator, productivity and reuability. Thi work i baed on the proce tandard definition more frequently ued preently by indutrie and organization, uch a, CMM, CMMI, ISO 9000, ISO and ISO 15504, and alo the IEEE1517 Standard. The procee etablihed in thi work include different CMM maturity level, uch a, reviion point and checklit in the everal phae of the oftware development proce (Level 3 - Defined), and alo the meaurement proce definition (Level 4 - Managed). The verification and reviion ue reading technique baed on perpective, a well a horizontal and vertical reading technique repectively. The proce implantation developed in thi work i divided into four phae: implantation of quality warranty proce on the aet development proce; definition of the oftware product quality model; definition of the evaluation objective and indicator; uage of quality technique; and uage of the indicator to promote proce improvement. Beide thi, a cae tudy i preented applying the oftware warranty proce defined on a pilot project, a Tactical Controller, developed according to a reue baed Software Development Proce, under the Defene Minitry Context and of their Subordinate Command of GURGEL (2004). Thi cae tudy point out that the ued trategy can increae quality of the final conceptual model a well a of the oftware production proce, focuing on a more productive reue. 17

19 1 INTRODUÇÃO 1.1 MOTIVAÇÃO A era da informática teve início na década de 60 com a difuão do computadore no diferente etore da ociedade atravé da utilização de oftware para o erviço e funçõe. O modelo de ciclo de vida de oftware urgiu para atender a neceidade do mercado no deenvolvimento de oftware de forma planejada, controlada e dentro da etimativa de prazo etabelecido. No ano 80, a redução progreiva do preço do hardware incentivou a buca pelo menor cuto do deenvolvimento de oftware. Neta época, o modelo para etimar cuto e recuro começaram a urgir, aim como a preocupação pela qualidade e produtividade no deenvolvimento de oftware (BASILI et al., 1991). A neceidade de garantir a qualidade no proceo de deenvolvimento do oftware reultou na utilização de proceo criterioo de avaliação de oftware para identificar eu ponto forte e oportunidade de melhoria (SEPIN, 2002). A qualidade do erviço e do produto de oftware etá fortemente relacionada com a qualidade do proceo de deenvolvimento do oftware (CROSBY, 1996; ABNT12207, 1998; HAZAN, 1999; ROCHA et al., 2001). Aim, o número de defeito apreentado no oftware é diretamente proporcional à qualidade do proceo uado para a contrução do oftware (JACOBSON et al., 1997; HENNINGER, 1999; ROCHA et al., 2001). Ito provocou uma grande preocupação com a definição e melhoria de um proceo de oftware, reultando no urgimento de vário modelo e norma para a definição de proceo e garantia de qualidade. O modelo mai utilizado para definir proceo de oftware ão: o Modelo de Maturidade da Capacitação para Software (CMM) (PAULK et al., 1993) e a Norma ISO/IEC (International Organization for Standardization/International Electro Technical Commiion) (ABNT12207, 1998). O CMM claifica a organizaçõe quanto ao nível de maturidade, e a Norma ISO/IEC etá baeada em framework para proceo de ciclo de vida - proceo fundamentai, proceo de apoio e proceo organizacionai (veja APÊNDICE 3). A Norma ISO/IEC e ua verão braileira ão conhecida por 67% da emprea pequiada pela Secretaria da Política de Informática do Minitério da Ciência e Tecnologia (SEPIN, 2002), ma omente 12% da emprea utilizam-na. 18

20 O produto de oftware, comumente denominado de artefato, ão um conjunto de informaçõe em diferente nívei de abtração e um conjunto de tranformaçõe e deciõe. A aplicação de um programa de controle de qualidade na produção de oftware garante maior qualidade no proceo de deenvolvimento do projeto de oftware (HAZAN, 1999; ROCHA et al., 2001). Exitem diferente definiçõe de qualidade e a eguir ão apreentada alguma deta definiçõe pequiada na literatura, a aber: Qualidade é a atifação total do conumidor (DEMING, 1990). Neta definição, a qualidade etá ligada à atifação do uuário interno ou externo, abrangendo ua neceidade e expectativa menurávei, que devem er medida atravé da caracterítica da qualidade do produto 1 ou erviço finai ou intermediário da organização. Eta caracterítica compreendem auência de defeito e preença de atributo que agregam valor ao produto ou erviço de forma confiável, aceível, egura e no tempo certo à neceidade do cliente. Ea caracterítica ão: previibilidade e confiabilidade de toda a operaçõe, treinamento contínuo, objetividade e clareza da informação, gerência por proceo e não por reultado, de forma a ter uma gerência preventiva de problema, não permitindo que o memo problema e repita pela mema caua; Qualidade é a adequação ao uo (JURAN, 1990). Diferente uuário podem uar o memo produto de divera forma, ou eja, o produto devem ter vário atributo de qualidade, tai como, capacidade, uabilidade, deempenho, confiabilidade, intabilidade, manutenibilidade, documentação e diponibilidade; Qualidade é a conformidade com o requiito do cliente (CROSBY, 1996). O requiito 2 devem er claramente epecificado para que, durante o proceo de deenvolvimento do produto, a mediçõe poam er realizada para determinar a conformidade ao requiito epecificado. A não-conformidade detectada é a auência de qualidade, ou eja, o defeito encontrado no produto. Portanto, eta definição etá diretamente relacionada com a falta de defeito no produto; Qualidade é o conjunto de caracterítica incorporada ao produto atravé do projeto e manufatura que determinam o grau de atifação do cliente (FEIGENBAUM, 1991); 1 2 Como o produto e o proceo etão fortemente relacionado e não podem er eparado quando e analia a qualidade (DEMING, 1996; ABNT12207, 1998; ROCHA, 2001), então a qualidade do proceo é fundamental para e ter qualidade do produto oftware. Requiito entendido como neceidade e expectativa do cliente. 19

21 Qualidade é o grau em que um itema pode er artefato ou proceo de oftware atende ao requiito epecificado, como também, à neceidade e expectativa menurávei de todo o uuário (ROCHA et al., 2001). A não-conformidade, no proceo de comunicação e tranformação da informação no deenvolvimento de produto de oftware, ão engano, interpretaçõe errônea, problema de comunicação, evolução de requiito, defeito ou erro que podem ocaionar o mau funcionamento do itema (ROCHA et al., 2001). A não-conformidade pode ocorrer na epecificaçõe de requiito, projeto de itema, cao de tete ou documentação (PFLEEGER, 2001). Aim, a não-conformidade encontrada pela verificaçõe e reviõe de oftware referem-e ao defeito. O defeito varia de acordo com a ituação a que e detina o oftware. Por exemplo, o que é defeito para uma aplicação pode não o er para outra (ROCHA et al., 2001). A clae de defeito não ão ortogonai, ou eja, um defeito pode e enquadrar em mai de uma categoria. Segundo TRAVASSOS et al. (1999), a taxonomia de defeito pode er claificada em: Omião: omião de informaçõe neceária obre o itema no artefato; Fato incorreto: contradição entre a informaçõe do artefato e a epecificação de requiito/conhecimento do domínio; Inconitência: inconitente na informaçõe contida em um artefato; Ambigüidade: ambigüidade na informaçõe do artefato, que pode levar a uma implementação incorreta; Informação etranha: a informaçõe ão verdadeira, ma não e aplicam ao domínio. Na última revião da ISO/IEC 9000:2000 (ABNT9000, 2001) a principal modificação é o objetivo da garantia da qualidade. Na verão anterior, o objetivo ignificava atendimento ao requiito epecificado, que paou neta nova verão para a atifação do cliente. A atifação do cliente envolve tanto o requiito explícito como o implícito, ou eja, a atifação etá diretamente relacionada com a qualidade do produto e erviço fornecido, como, por exemplo, uporte ao uuário final. A emprea têm invetido mai no aumento da eficiência do deenvolvimento de oftware (prazo menore e meno recuro gato) e no reuo de oftware, viando garantir a atifação do cliente em obter um produto de oftware cada vez mai rápido, de qualidade e de baixo cuto de produção. O aumento da eficiência do deenvolvimento de oftware refere-e 20

22 ao deenvolvimento de linguagen mai eficiente e ferramenta de apoio, melhora do proceo produtivo, gerencial e de treinamento do peoal, como também, obtenção de um bom arquivo de dado/informação. O reuo, coniderado como chave da etratégia de alguma organizaçõe, e torna uma ferramenta facilitadora que permite o ganho em qualidade (redução de falha pelo reuo de artefato já tetado e aprovado), redução de cuto de produção (ao médio/longo prazo, com alteração do enfoque organizacional), diminuição de redundância e melhoria no deenvolvimento (aumento da agilidade). Deta forma, o reuo pode er definido como a utilização de um artefato fora de eu contexto de criação, ito é, uma equipe é a reponável pelo deenvolvimento e outra pelo eu emprego apropriado (JACOBSON et al., 1999). Um do ponto crítico da reutilização do produto de oftware é o tempo dependido pelo deenvolvedore para compreender, adaptar e integrar o artefato a er reuado. A compreenão do artefato reutilizável e o momento de integrá-lo no ciclo de vida de deenvolvimento de oftware faz com que a documentação do aet 3 deempenhe um papel vital na viabilização da reutilização. (FAVARO, 1996; FICHMAN, 2001; JACOBSON et al., 1999; POULIN, 1997; SAMETINGER, 1996) A utilização de um proceo definido e gerenciado contitui um elemento fundamental para o deenvolvimento efetivo de aplicaçõe de oftware. Aim, o proceo é o principal fator determinante para cuto, qualidade e reuabilidade. Memo o melhor deenvolvedor não pode ter um bom deempenho e o proceo não for bem compreendido, ou eja, não etiver bem definido (STAA, 2002). O proceo deve aegurar a utilização de procedimento definido de acordo com o critério de qualidade e de reuabilidade requerido pela organização. Deta forma, o proceo deve coniderar a ua adequação à tecnologia envolvida, ao tipo de oftware em quetão, ao domínio de aplicação, ao grau de maturidade (ou capacitação) da equipe em engenharia de oftware, à caracterítica própria da organização, à caracterítica do projeto e da equipe, ao papéi do intereado (takeholder), à principai atividade, ao tipo e ponto de controle da qualidade. Aim, em geral, o problema relativo à qualidade devem reidir na definição do proceo e no controle do artefato produzido durante o proceo (PAULK et al., 1993; PRESSMAN, 2001; SOMMERVILLE, 2000; ABNT12207, 1998). 3 Aet é um artefato ou conjunto de artefato criado com o propóito explícito de er reutilizado em outro eforço de deenvolvimento. 21

23 A Norma IEEE (Intitute of Electrical and Eletronic Engineer) 1517 recomenda que o proceo de oftware 4 devem prover framework para praticar reuo. Nete framework, a atividade de reuo devem etar integrada ao ciclo de vida do oftware, de forma que o reuo e torne um modo natural e normal de trabalhar (veja APÊNDICE 3). Portanto, alguma conideraçõe devem er abordada: como o reuo muda o ciclo de vida do oftware, exatamente onde ajutar reuo no proceo de deenvolvimento de oftware; e, epecificamente, quai ão o proceo, a atividade e a tarefa de reuo que devem er incluído no ciclo de vida do oftware (IEEE1517, 1999). Para viabilizar a reutilização de artefato é neceário contruir uma arquitetura própria (uma arquitetura orientada a reuo), que permita a organização de artefato. Atravé do uo em conjunto da organização e etruturação da informaçõe, procura-e facilitar o aceo e o reaproveitamento efetivo do artefato (JACOBSON et al., 1997). Para eta arquitetura, a definição do requiito de qualidade é uma parte ignificativa no proceo de deenvolvimento de oftware (JACOBSON et al., 1997). Poi, baeado nete requiito, o controle de qualidade deve aegurar ao reutilizadore o nível de qualidade deejada no aet para que ele poam ter confiança em reutilizar. Deta forma, o controle de qualidade deve epecificar um proceo de avaliação adequado ao método de deenvolvimento ecolhido para o domínio da aplicação e a tecnologia adotada para contrução do artefato reutilizávei. 1.2 OBJETIVO O objetivo dete trabalho é propor um proceo de garantia de qualidade aplicado ao Proceo de Deenvolvimento de Software baeado em Reuo no Minitério da Defea (MD) e de eu Comando Subordinado propoto por GURGEL (2004). Ete trabalho deve fornecer ubídio para o Órgão Decentralizado de Fornecimento de Software 5 promoverem o aumento da produtividade e a melhora da qualidade de eu proceo de deenvolvimento de artefato reuávei (aet). Além dio, deve poibilitar um acompanhamento eficaz de projeto de deenvolvimento de oftware com bae em reuo para aegurar melhor planejamento e controle de projeto. 4 5 Proceo de oftware ão mapa ou framework para deenvolver aplicaçõe de oftware (IEEE1517, 1999). Etrutura de organização propota por GURGEL (2004) (veja ANEXO 1). 22

24 Para tal, foram etudado o proceo de garantia de qualidade de oftware exitente na literatura e a particularidade exitente no deenvolvimento baeado em reuo. A definição do proceo foi apoiada pela condução de um etudo de cao que permitiu avaliar a viabilidade de ua aplicação no contexto da propota de GURGEL (2004) para MD. 1.3 VISÃO GERAL DO PROCESSO PROPOSTO Para que o reuo de artefato eteja preente em todo ciclo de vida do itema, proporcionando economia de tempo e recuro, redução no retrabalho e aumento na produtividade, é fundamental que a qualidade do proceo de deenvolvimento dete artefato e o próprio artefato tenham qualidade aegurada (JACOBSON, 1997). Deta forma, é neceário um controle de qualidade para incluir prevenção e remoção de defeito do artefato (JONES, 1994). Nete trabalho, foi adotado como definição de qualidade de oftware um conjunto de propriedade de oftware a erem atifeita em determinado grau, de modo a atifazer a neceidade e expectativa menurávei de todo eu uuário interno e externo (ROCHA et al., 2001; ABNT9000, 2001). Aim, a partir dete conjunto de propriedade, a qualidade do produto de oftware pode er decrita e avaliada de forma objetiva e padronizada. O princípio a erem adotado na implantação do proceo propoto foram: Criação da área de qualidade para melhoria contínua da qualidade, medição e análie de proceo e artefato de forma a aumentar efetivamente a produtividade e a atifação do uuário externo e interno (KAN, 1995; SEI, 2002). Aim, o reultado de cada fae do proceo de deenvolvimento de oftware devem er avaliado para aegurar a qualidade do artefato e garantir um oftware de boa qualidade. Poi, em cada fae do proceo, um artefato é produzido para um uuário da fae eguinte. Portanto, cada artefato poui atributo da qualidade que afetam a qualidade do produto final (HAZAN, 1999); O controle da qualidade deve er exercido de forma itemática (ABNT12207, 1998; ISO15504, 1998; PAULK et al., 1993; SEI, 2002); O oftware deve etar em defeito (auência de não-conformidade), bem documentado 6 e deenvolvido por método eficaze e técnica adequada (KAN, 1995). 6 Um oftware bem documentado ignifica que a documentação exite, além dio, eta documentação etá completa e atualizada de acordo com a alteraçõe realizada no oftware (ROCHA, 2001). 23

25 Além dio, um oftware de qualidade deve produzir reultado relevante e confiávei no tempo certo, ter a funcionalidade neceária e a poívei expectativa deejada ao uo, er menurável, er corrigível, adaptativo e evolutivo, operar com economia de recuro e er deenvolvido economicamente dentro do prazo etipulado (FIORINI et al., 1998; STAA, 2002). Para a qualidade er efetiva dentro do proceo de deenvolvimento de oftware, ela deve reultar na redução ignificativa do retrabalho (CROSBY, 1996). Deta forma, o defeito introduzido ao longo do proceo de deenvolvimento de oftware devem er identificado o quanto ante, e poível na própria fae em que ão cometido, poi o eforço gato e o cuto aociado para corrigir um defeito aumentam proporcionalmente ao tempo entre a ua introdução e excluão, ou eja, quanto mai cedo for decoberto o defeito, menor o eforço para corrigi-lo (JACOBSON et al., 1997; FICHMAN, 2001; ROCHA et al., 2001; JONES, 1997). Portanto, o benefício da qualidade reultante da auência de não-conformidade poibilitam que a organizaçõe minimizem o eforço do retrabalho, reduzindo o tempo de deenvolvimento de oftware e o cuto. Segundo ROSENBERG et al. (1998), o problema que não ão encontrado e corrigido até a fae de tete cutam 14 veze mai do que corrigilo na fae de requiito. A implantação de um programa de qualidade deve começar pela definição e implantação de um proceo de deenvolvimento de oftware. Ete proceo deve er documentado, compreendido e eguido por todo o profiionai nele envolvido. O método utilizado para exercer ação obre o proceo é o ciclo de Deming (DEMING, 1982), conhecido como PDCA (Plan/Do/Check/Act). Na FIG é apreentada um diagrama explicativo do ciclo PDCA de Deming e da epiral de acenão de qualidade. O ciclo de Deming é repreentado por um círculo em rotação no entido horário, demontrando um deenvolvimento iterativo e a neceidade da melhoria contínua. Na epiral de acenão de qualidade, é apreentado o uo itemático do PDCA que poibilita a melhoria da qualidade. 24

26 Qualidade do Produto de Software ATUA NO PROCESSO EM FUNÇÃO DOS RESULTADOS ACTION DEFINE METAS PLAN DETERMINA OS MÉTODOS PARA ATINGIR AS METAS Action Check Plan Do CHECK VERIFICA OS EFEITOS DO TRABALHO EXECUTADO DO EXECUTA O TRABALHO TREINA PARA O TRABALHO Action Check Action Check Action Check Plan Do Plan Do Plan Do FIG (a) Ciclo PDCA de Deming, adaptado de (FALCONI, 1999). (b) Epiral de acenão da qualidade. O PDCA contitui em um proceo que atua obre o demai proceo dividido em 4 etapa, a aber: (FALCONI, 1999) 1 - Pan: etapa de planejamento que conite em etabelecer meta e método para alcançar a meta propota; 2 - Do: etapa de execução que conite na realização da tarefa de acordo com o planejado e na coleta de dado da verificação; 3 - Check: etapa de verificação onde o dado coletado ão comparado com o reultado eperado; 4 - Action: etapa ação onde é exercida uma atuação obre o proceo em i que pode er de dua forma: e a meta foram atingida, então o plano propoto deve er adotado como padrão, ou e a meta não foram alcançada, açõe devem er exercida obre a caua do não alcance da meta. 1.4 ORGANIZAÇÃO Eta diertação é compota por cinco capítulo. No Capítulo 1, Introdução, é apreentada uma breve hitória da informática dede ua criação até o dia atuai para relatar como a qualidade e a reuabilidade de oftware etão inerida dentro do proceo de engenharia de oftware. Também ão abordada alguma definiçõe de qualidade apontada pela literatura e etabelecido o princípio da qualidade adotado para eta diertação. O Capítulo 2, Fundamento Teórico, ão abordado conceito gerai da engenharia de qualidade, garantia da qualidade, técnica aplicada ao controle e melhoria da qualidade do 25

27 proceo de deenvolvimento de oftware. Além dio, ão apreentado conceito e tipo de reuo, problema relacionado a reuo identificado na literatura e o principai modelo e métrica voltado a reuabilidade. A propota da diertação é detalhada no Capítulo 3, Proceo da Garantia da Qualidade de Software baeado em Reuo Sitemático. Nete capítulo, é definida uma metodologia para aegurar a qualidade e validar o aet produzido pelo Órgão Decentralizado de Fornecimento de Software propoto por GURGEL (2004). Para io, é etabelecida uma etrutura organizacional do Grupo de Garantia da Qualidade de Software. No Capítulo 4, Etudo de Cao, é apreentado um etudo de cao realizado para avaliar a viabilidade da propota definida no capítulo anterior, e aplicar a técnica epecificada, definir template e analiar o reultado obtido dete trabalho. No Capítulo 5, Concluõe, ão apreentado a concluõe e o principai benefício deta diertação, aim como, ugere poívei trabalho futuro. 2 FUNDAMENTOS TEÓRICOS 2.1 ENGENHARIA DE QUALIDADE A Engenharia de Qualidade é reponável pela determinação e o planejamento do trabalho. Ela deve zelar pela qualidade em termo de determinar o que fazer para que o todo alcance o reultado propoto (CROSBY, 1996). Para ito, um Comitê de Qualidade deve er formado por conultore da qualidade para apoiar a equipe de deenvolvedore/ montadore de projeto na avaliaçõe da qualidade do artefato produzido durante todo proceo de ciclo de vida do projeto, determinando de que modo o produto deve er verificado, inpecionado, tetado e controlado no decorrer de ua vida dentro e fora da organização (ROCHA et al., 2001). Ete comitê deve, também, ajudar na identificação do atributo de qualidade neceário para que cada um do projeto alcance eu objetivo e a equipe de deenvolvedore/montadore enfoque no deenvolvimento de oftware baeado no reuo (IEEE1517, 1999). A garantia da qualidade omente pode er aegurada e exitir um padrão de epecificação confiável e eguido, e também controlado de forma itemática. O grupo de garantia da qualidade de oftware deve utilizar técnica, ferramenta, método, padrõe, 26

28 norma, proceo e bae de dado para apoiar o divero projeto de oftware. Ele deve apoiar a equipe de deenvolvimento de oftware por meio de verificaçõe e validaçõe, que permitem avaliar o artefato produzido (ABNT12207, 1998; ISO15504, 1998; ROCHA et al., 2001; FIORINI et al., 1998). A avaliação deve er planejada e realizada, conforme o planejamento por reviore, verificadore ou tetadore treinado e em vínculo operativo no artefato examinado (PAULK et al., 1993; CROSBY, 1996; ABNT12207, 1998; ISO15504, 1998; ROCHA et al., 2001; SEI, 2002). A Norma CMM, CMMI, ABNT e ISO recomendam que o executore da atividade de verificação e validação não devem ter participação na elaboração do artefato a er examinado (PAULK et al., 1993; SEI, 2002; ABNT12207, 1998; ISO15504, 1998). A tenõe entre autore e reviore do artefato ão apontada na abordagem da Gerência pela Qualidade Total 7 (GQT) como grande fonte geradora de conflito que comprometem a qualidade do produto (KAN, 1995). Eta fonte geradora de conflito deve er minimizada atravé de eclarecimento durante a etapa de treinamento da revião e, também, com a introdução de um líder que exerce o papel de moderador na reuniõe, de forma a eliminar ou reduzir o número de conflito (WIEGERS, 1995). Cada atividade de verificação e validação deve apreentar doi reultado: produto de oftware é aceito ou rejeitado, e o regitro de não-conformidade e de cálculo (ABNT12207, 1998). Acumulando o reultado do cálculo e analiando-o, o Comitê de Qualidade pode determinar exatamente o etado do produto de oftware. Ele reúne o dado proveniente da atividade de verificação e validação, e o regitra de maneira a er de utilidade prática para todo o intereado. A gerência de reuo e de projeto precia de dado acurado da tendência, para aber quando e onde deve agir (IEEE1517, 1999). O controle da qualidade deve produzir um documento contendo todo o problema identificado, e ete devem er reolvido. Apó a cada alteração, é neceário repetir o controle da qualidade (ABNT12207, 1998; FIORINI et al., 1998). Ihikawa propô ete ferramenta báica de etatítica para controle da qualidade (PALADINI, 1994) que ão útei para o planejamento e controle de projeto de deenvolvimento de oftware. Dentre ela e detacam o Diagrama de Caua-Efeito, o Checklit e o Diagrama de Pareto. 7 GQT é um itema que combina técnica de controle da qualidade e modelo organizacionai, onde a qualidade é reconhecida como uma vantagem etratégica com o apóio total da alta-adminitração. 27

29 O Diagrama de Caua-Efeito, conhecido como Gráfico Epinha-de-Peixe ou Gráfico de Ihikawa, identifica todo o fatore de caua de uma caracterítica da qualidade em um único gráfico. Sua forma é imilar à epinha de peixe, onde o eixo principal motra a caracterítica da qualidade, e a epinha repreentam o fatore que afetam eta caracterítica. (PALADINI, 1994) O Checklit é um formulário que contém iten para erem verificado conforme a neceidade epecífica de eu uuário, e por io, apreentam extrema flexibilidade de elaboração, utilização e interpretação. Seu principal objetivo é facilitar a coleta de dado que vão er analiado poteriormente. (PALADINI, 1994) O Diagrama de Pareto, repreentado por barra de freqüência, é utilizado para claificar a caua de defeito que atuam em um proceo epecífico de acordo com eu grau de importância (PALADINI, 1994). A análie de Pareto retrata o princípio (20% da caua ão reponávei por 80% do defeito). Ete diagrama é batante aplicado na Qualidade de Software, porque o defeito do oftware ou denidade do defeito não eguem uma ditribuição uniforme (HAZAN, 1999) TESTES O tete ão atividade de validação e verificação que conitem na análie dinâmica do oftware, ou eja, na execução do produto de oftware com o objetivo de verificar a preença de não-conformidade cometida ao longo do proceo de deenvolvimento do oftware. Para tal, deve-e contruir e aplicar plano de tete capaze de identificar não-conformidade no artefato (ROCHA et al., 2001). O Plano de Tete é um documento que decreve o planejamento da atividade e tarefa de tete, ou eja, define o objetivo do tete, ecopo, etratégia, procedimento do tete, ambiente de tete, cao de tete, iten a erem tetado, tipo de tete a erem executado, ecala de tete, recuro humano, relato de procedimento, critério de análie, rico e plano de contingência. Ele deve er iniciado logo na fae de elicitação da neceidade do cliente, poi ajuda a melhorar a interaçõe da atividade de análie do domínio, projeto de domínio e codificação ou montagem de componente. Na fae poteriore o plano deve er refinado com mai detalhe (LEWIS, 2000). A falta de um planejamento da atividade de deenvolvimento é uma da caua da crie do oftware (PRESSMAN, 2001). O planejamento da atividade de tete deve etar inerido 28

30 dentro do planejamento do projeto, onde ão etimado o recuro e definido etratégia, método e técnica de tete para formar um critério de aceitação do oftware em deenvolvimento (LEWIS, 2001). Um cao de tete é um conjunto epecífico de dado de tete e cript de tete (ROCHA et al., 2001). O cript de tete é um guia para o tetador na realização do tete e aegura conitência entre a parte de execuçõe do tete. Um tete também inclui reultado eperado para verificar e o tete encontrou o objetivo corretamente. Durante a fae de codificação, o cript de tete e o dado de tete devem er gerado. Na fae de aplicação de tete, o cript de tete devem er executado e o reultado devem er analiado. Um ou mai plano de tete podem er uado para cada tipo de tete (LEWIS, 2000). Segundo HARROLD (2000), a atividade de tete poui alguma limitaçõe: Dado uma eqüência de comando, identificar e é executada ou não; Dado dua eqüência de comando de um programa ou de programa diferente, identificar e a eqüência executam a mema função; O programa pode apreentar um reultado correto para um dado de entrada epecífico, atifazendo um requiito de tete e não revelando a preença de um erro; Inviabilidade de tetar toda a poibilidade, poi o domínio do dado de entrada normalmente é infinito ou muito grande (tete exautivo); Limitação do tempo e recuro; Indiponibilidade de ferramenta adequada para a realização do tete. Uma maneira de minimizar a limitaçõe é etabelecer critério de tete que devem er etabelecido no Plano de Tete. A princípio devem er definido o critério de tete de aceitação, que vão ervir de bae para o critério de tete de itema, integração e de unidade. Na etapa de execução do tete, o proceo deve er invero ao do plano de tete, começando pelo tete de unidade. Na FIG é apreentado um diagrama que relaciona a fae de deenvolvimento de projeto e o tipo de tete correpondente. Ao etruturar o proceo de tete em cada fae do proceo de deenvolvimento do oftware, diferente tipo de defeito e apecto do oftware ão abordado, reultando em maior cobertura e minimizando a complexidade da atividade (MYERS, 1979; MALDONADO, 1991). 29

31 FIG : Diagrama de relacionamento da etapa de deenvolvimento de projeto e o tipo de tete aplicado a cada etapa. A técnica de tete, quanto à origem da informação utilizada para etabelecer o requiito de tete, podem er: funcional ou caixa-preta (PRESSMAN, 2001), etrutural ou caixa-branca (PRESSMAN, 2001), com bae em erro (DEMING, 1990) e com bae em máquina de etado finito (FUJIWARA, 1991). Baicamente há quatro tipo de tete (LEWIS, 2000; ROCHA et al., 2001): tete de unidade, tete de integração, tete de itema e tete de aceitação. O tete de unidade tetam a lógica do código, independentemente do ambiente (tete de caixa branca), e o tete de integração focam na integração deta unidade tetada com ambiente do projeto (ROCHA et al., 2001). Tanto o tete de unidade como de integração devem er ecrito pelo programadore, por ambo requerem conhecimento epecífico da tecnologia envolvida, tai como, linguagen de programa e parâmetro de integração entre a unidade (LEWIS, 2000). O tete de integração deve envolver todo o nívei de detalhe de implementação de bae de dado e linguagen, componente externo ou protocolo de comunicação utilizado para a contrução do itema (LEWIS, 2000). O tete de itema via identificar erro de funçõe e atributo de qualidade que não etejam em conformidade com a epecificação (PRESSMAN, 2001). O itema deve er tetado no ambiente de operação computacional ante da realização do tete de aceitação. O tete de caixa-cinza, que combina a abordagen caixa-branca (tete etrutural) e caixa-preta (tete funcional), é freqüentemente aplicado nete tipo de tete (ROCHA et al., 2001). O tete de aceitação certifica que o itema de oftware atifaz o requiito originai. Ete tete não deve er realizado ante do completo uceo do tete de itema. Nete tipo de tete é empregada a técnica de caixa-preta para tetar o itema contra ua epecificaçõe. Em geral o tete de aceitação é um ubconjunto de um ou mai tete de itema (LEWIS, 2000). 30

32 O cao de tete de aceitação devem incluir tete de deempenho, tete de carga, tete de reuabilidade e tete de compatibilidade de arquitetura de domínio. O tete de reuabilidade, que incluem o tete de generalidade e de adaptabilidade, devem er ecrito pelo engenheiro de domínio, aim como o tete de compatibilidade de arquitetura de domínio. O tete de generalidade conite em validar a modificação do domínio da aplicabilidade do aet, ao pao que o tete de adaptabilidade verifica a facilidade de reuo do aet. O tete de itema devem er ecrito pela equipe de deenvolvimento/ montadore e o tete de aceitação pelo engenheiro de domínio e cliente (IEEE1517, 1999). Em geral o tete devem er executado por uma equipe diferente da que faz a programação, exceto o tete de unidade (CROSBY, 1996; LEWIS, 2000). A equipe de tete (tetadore) é reponável pela execução do tete e deve aegurar que o tete eja executado conforme o plano de tete (ROCHA et al., 2001). Cada não-conformidade detectada durante o tete deve er documentada. Aim, para cada tete deve er gerado um Relatório de Tete e verificado o atendimento ao requiito epecificado no cao de tete (LEWIS, 2000; ROCHA et al., 2001). O Relatório de Tete deve conter local e hora, recuro utilizado (hardware, oftware e peoal), o reultado obtido, problema e não-conformidade detectada, além do nível de adeqüabilidade (aprovado, deaprovado ou aprovado com pendência) (LEWIS, 2000). Atualmente no mercado, exitem muita ferramenta para tete, conforme apreentado em (LEWIS, 2000). Ela provêem rapidez na execução, execução em interferência humana, programável, repetível, reuável e fornece análie de cobertura de código depoi da execução do tete. Ma, o principai fatore que limitam a ferramenta de tete ão (LEWIS, 2000): Se o tete for executado apena uma vez, uma ferramenta de tete pode não valer o tempo exigido e depea; Se exite preão para terminar o tete dentro de um prazo de tempo determinado, uma ferramenta de tete pode não er apropriada, poi demanda tempo para aprender, configurar e integrar uma ferramenta de tete à metodologia de deenvolvimento; Se o itema muda rapidamente a cada iteração do ciclo epiral de tete, mai tempo erá dependido em manter a ferramenta de tete de regreão. Portanto, a eleção da ferramenta de tete mai adequada para o ambiente de deenvolvimento é um fator crítico para o uceo da atividade de tete. Ela deve er empregada quando o proceo manual é inadequado, como por exemplo, uma ferramenta de tete de carga pode imular vário uuário virtuai em condiçõe controlada de etree. 31

33 Para apoiar a eleção de uma ferramenta de tete, já que não é uma tarefa imple, Lewi aborda alguma quetõe por meio de um checklit em (LEWIS, 2000) INSPEÇÕES DE SOFTWARE Embora a aplicação de tete para o controle da qualidade do oftware eja importante, o uo excluivo de tete é pouco produtivo. Memo endo indipenável realizar tete bem feito, a qualidade do oftware não melhora com o aumento do invetimento em tete (LEWIS, 2000). LAITENBERGER (2002) relata que a introdução de inpeção de código reduz 39% do cuto com defeito em relação à realização de tete e a inerção de inpeção de projeto reduz 44% do cuto com defeito comparado ao tete. Aim, o artefato devem ofrer inpeçõe ao longo do proceo de deenvolvimento de oftware para garantir a qualidade interna do artefato produzido. O objetivo da inpeçõe ão: Verificar e o artefato examinado atifaz a ua epecificaçõe e e etá em conformidade com o padrõe aplicávei; Identificar devio de padrõe e epecificaçõe; Coletar dado de engenharia de oftware, como dado de eforço e defeito. A inpeção de oftware poibilita a detecção e a remoção de defeito em artefato aim que ete ão criado (LAITENBERGER, 2002; FAGAN, 1986; DOOLEAN, 1992). Na FIG é apreentada curva de deenvolvimento de oftware em relação a ecala de tempo com e em inpeção (FAGAN, 1986). FIG : Comparação de deenvolvimento de oftware com e em inpeçõe. A inpeçõe de oftware preciam etar integrada ao proceo de deenvolvimento de oftware. Aim, a inpeção deve er adequada para cada etapa de deenvolvimento do 32

34 projeto. Na FIG é apreentado o Modelo V de Vorgehen (Modelo de Produto) que relaciona o produto deenvolvido e a inpeção de oftware (BRÖHL, 1995), aplicável a qualquer tipo de deenvolvimento de oftware (eqüencial, em paralelo ou de modo incremental). FIG : Diagrama de relação do artefato produzido e a inpeçõe de oftware REVISÕES A revião formal é uma técnica de revião do oftware ou de algun de eu artefato, executada, itematicamente, ao final de cada fae do proceo de deenvolvimento de oftware, com o objetivo único de encontrar não-conformidade. Eta técnica é executada por uma equipe na qual cada membro tem papel preetabelecido. O deenvolvedor autor do artefato em inpeção participa, ma não coordena a reunião. (TAVARES, 2002) A reviõe podem er implementada via inpeçõe ou walkthrough (reunião conjunta para litar problema encontrado e açõe decorrente). A inpeção de oftware pode utilizar técnica de avaliação formal onde o artefato ão examinado de maneira criterioa por uma peoa, em a participação do autor, para detectar falta, violaçõe de padrõe de deenvolvimento e outra não-conformidade. A inpeçõe, também, podem er uada para obtenção de conhecimento ou como bae para tomada de deciõe (REGNELL et al., 1999). Muita variaçõe têm ido propota para o proceo de revião dede ua criação, ma toda ão influenciada pela idéia iniciai de Fagan e Gilb (FAGAN, 1986; GILB, 1993): a realização de uma revião criterioa do artefato para identificar a poívei nãoconformidade (defeito). Ea variaçõe incluem a modificação na etrutura da reunião de revião ou do número de reviore que devem participar da reunião, ou na eliminação da reunião de revião (FAGAN, 1986; GILB, 1993; PORTER et al., 1995; VOTTA, 1993). Um exemplo dea variaçõe é a realização da revião por uma equipe na qual cada membro tem 33

35 papel preetabelecido, onde o autor do artefato a er reviado participa, ma não coordena a reunião (LAITENBERGER, 2002). Para Fagan e Gilb (FAGAN, 1986; GILB, 1993), o método de revião identifica a fae de planejamento, detecção, coleta e correção de não-conformidade. Entretanto, ete método não fornece para o revior uma diretriz de como a não-conformidade devem er encontrada na fae de detecção. Ambo, também, admitem que a revião individual de artefato pode er feita atifatória e eficientemente apena com o conhecimento do revior (abordagem ad-hoc). A revião deve er realizada atravé da inpeção individual pelo revior que pode er deenvolvedor/montador dede que não eja o próprio autor do artefato inpecionado, para identificar a poívei não-conformidade (defeito) atravé da técnica de leitura adequada ao artefato em quetão. Ma, a parte principal do proceo de inpeção é a detecção de defeito por técnica de leitura de documento e o regitro de não-conformidade detectada. Todo o material gerado do artefato deve er lido, a não-conformidade anotada e uma etatítica da não-conformidade detectada deve er poteriormente realizada para fin de trabalho futuro da eficácia do procedimento. (ABNT12207, 1998; HAZAN, 1999; LAITENBERGER, 2002) TÉCNICAS DE LEITURA DE SOFTWARE Uma abordagem para identificar defeito em artefato, diferente da abordagem ad-hoc normalmente utilizada na maioria do cao, é fornecida pela técnica de leitura de oftware. Uma técnica de leitura é uma érie de procedimento ou etratégia preparada para análie de um artefato que permite alcançar a compreenão neceária para uma determinada tarefa (BASILI et al.,1996). A técnica de leitura aumentam a eficiência do reviore por fornecerem diretrize do que procurar, já que eta técnica propiciam que o reultado da atividade de detecção de defeito eja meno dependente do fatore humano como a experiência. Em vez do reviore aplicarem apena eu próprio conhecimento e técnica, a técnica de leitura agregam o conhecimento obre a melhore prática para detecção de defeito em um procedimento que pode er eguido e repetido. Ea técnica de leitura auxiliam a identificação de defeito e melhoram o proceo de revião de oftware de outro artefato não código-fonte (BASILI et al., 1996; FUSARO, 1997; PORTER et al., 1995; ZAHRAN, 1998). A principai técnica de leitura e ua caracterítica ão apreentada em (LAITENBERGER, 2002). Na TAB ão apreentada a dua técnica de inpeção 34

36 mai utilizada na indútria (ad-hoc e checklit) e dua variante da técnica de leitura baeada em cenário em atual difuão (Leitura baeada em Defeito e em Perpectiva). TAB : Técnica de inpeção de oftware e ua caracterítica. Técnica de Leitura Ad-Hoc Checklit Leitura baeada em Defeito Leitura baeada em Perpectiva Contexto da aplicação Todo o produto Todo o produto Todo o produto Todo o produto Caracterítica Uabilidade Repetibilidade Adaptabilidade Rico Neceidade de treinamento Validação Não Não Não Não Não Prática indutrial Não Não Sim Depende do cao Sim Depende do cao Não Prática indutrial Sim Alto Sim Validação experimental Sim Sim Sim Alto Sim Validação experimental e iniciado uo indutrial O método ad-hoc é uma técnica não itemática, onde todo o reviore deempenham a mema tarefa utilizando eu próprio conhecimento. O método checklit é imilar ao método ad-hoc, ma uma lita de defeito é fornecida. Já no método cenário, o reviore têm reponabilidade fragmentada e coordenada (LAITENBERGER, 2002). O método ad-hoc e checklit ão o doi método de detecção de defeito mai utilizado (LAITENBERGER, 2002). Entretanto, Cheng identifica algun do principai problema do reviore ao utilizar ee método (CHENG et al., 1996), tai como: O reviore ão obrecarregado com informação exceiva; Deconhecimento do reviore obre o aunto de negócio e detalhe do projeto; Reponabilidade ambígua; Não tem ponto de partida bem definido devido ao iten acima; Interação limitada entre reviore e equipe de projeto; Participação de reviore inexperiente; Procedimento de revião não itemática e conjunto de pergunta depreparada para quetionar obre o projeto. No método de Leitura baeado em Cenário, o cenário é um procedimento que o revior de um documento deve eguir durante a inpeção. O cenário pode er benéfico ao dirigir a atenção do reviore para o defeito mai crítico da organização (LAITENBERGER, 2002). Nete método, o reviore lêem um documento com diferente perpectiva (REGNELL et al., 1999), de forma que diferente reviore tenham diferente 35

37 reponabilidade e ejam direcionado em ua leitura por um cenário epecífico que e agrega ao contruir o modelo invé de uma leitura paiva. Exitem dua variante da técnica de Leitura baeada em Cenário: Leitura baeada em Defeito (PORTER et al., 1995) e Leitura baeada em Perpectiva (BASILI et al., 1996). A Leitura baeada em Defeito concentra-e em epecificar clae de defeito, enquanto que a Leitura baeada em Perpectiva concentra-e na vião do uuário do documento (BASILI et al., 1996) (projetita na fae de projeto, tetadore na fae de tete e uuário na fae de operação). A principal idéia da técnica de Leitura baeada em Perpectiva é que um produto de oftware deve er inpecionado ob a perpectiva de diferente takeholder (BASILI et al., 1996) (BRIAND et al., 1998; LAITENBERGER et al., 1997; LAITENBERGER, 2000; LAITENBERGER, 2002). Para cada perpectiva, tanto um como vário cenário ão definido, conitindo de atividade repetívei que um revior precia executar e de pergunta que um revior deve reponder. A técnica de Leitura baeada em Perpectiva foi aplicada para inpecionar documento de requiito (BASILI et al., 1996), modelo de projeto orientado a objeto (LAITENBERGER et al., 1997) e documento de código (LAITENBERGER, 2000). A principal idéia da Leitura baeada em Defeito é que diferente reviore focalizam diferente clae de defeito enquanto examinam o memo documento (MILLER et al., 1998; PORTER et al., 1998; PORTER et al.,1995; SANDAHL et al.,1998; LAITENBERGER, 2002). Para cada clae de defeito, há um cenário que conite em um conjunto de pergunta que um revior deve reponder enquanto lê. Ao reponder a pergunta, o revior deve etar detectando defeito daquela clae em particular. O método de Leitura baeado em Cenário tem apreentado uma taxa mai alta de detecção de defeito do que ad-hoc e checklit (PORTER et al., 1995) (MILLER et al., 1998) (REGNELL et al., 1999): taxa uperior a 35%. Ito ocorre, porque o cenário ajudam a focar clae epecífica de defeito e independem da habilidade de identificar outra clae de defeito TÉCNICA DE LEITURA BASEADA EM PERSPECTIVA Na Técnica de Leitura baeada em Perpectiva, o revior, ao preencher a lita de conferência, deve aumir uma perpectiva epecífica (revior/avaliador), viando o objetivo de inpecionar e validar o documento. A lita de conferência deve er compota por um conjunto de apecto e cada apecto deve conter uma érie de quetõe relacionada. O 36

38 apecto devem coniderar o tipo de produto a er epecificado e o atributo de qualidade neceário para atender a atifação do cliente. Cada quetão deve ter opçõe de repota e deve er elaborada de forma que a repota poitiva aegura adequação ao objetivo do apecto propoto. Apó a concluão da inpeção, deve er elaborado um documento, onde devem etar regitrado o reultado obtido, comentário e ugetõe de melhoria. (PAGLIUSO et al., 2002) Neta técnica, o reviore ão olicitado a deenvolver abtraçõe do itema pelo requiito, utilizando diferente ponto de vita. Para um projeto OO, a abtraçõe da informaçõe importante já exitem: a informação etá decrita em diferente diagrama e documento, como diagrama de clae e interação, decrição de clae e outro. Ma, apear dio, o defeito ainda exitem e preciam er identificado. (ROCHA et al., 2001) TÉCNICA DE LEITURA ORIENTADA A OBJETO A Técnica de Leitura Orientada a Objeto (TLOO) é um conjunto de ete técnica diferente para leitura de projeto OO. Eta técnica foram deenvolvida para fornecer um procedimento para a inpeçõe individuai do diferente diagrama e documento de projeto OO e identificar a clae de defeito genérico relativo à epecificação de requiito e ao projeto. (TRAVASSOS et al., 2003) O proceo de leitura utilizando TLOO baeia-e em técnica horizontai e verticai para apoiar a reviõe. Na FIG é apreentado o conjunto de TLOO (TRAVASSOS et al., 2003), onde cada linha entre o diferente artefato de oftware repreenta uma técnica de leitura definida para ler um documento comparando-o com outro. FIG : Conjunto de TLOO. 37

39 Atravé da leitura horizontai aegura-e que todo o diagrama de projeto etejam conitente. E, atravé da leitura verticai aegura-e à conitência entre o artefato de projeto e o requiito do itema. (TRAVASSOS et al., 2003) A vantagem em utilizar eta técnica etá na eleção de apena um ubconjunto de técnica correpondente ao artefato que devem er inpecionado ou que ão importante em um determinado momento no proceo de deenvolvimento de projeto OO. (ROCHA et al., 2001) PROGRAMA DE MEDIÇÃO DE SOFTWARE A implantação de um proceo de medição de oftware via fornecer ao Gerente de Reuo um conjunto de dado útei para planejar e controlar o projeto de oftware com rigor e precião (PRESSMAN, 2001). Para ito, é neceária a motivação de todo o profiionai que atuam no proceo de deenvolvimento de oftware. Também é neceário que a gerência de reuo etabeleça um programa de medição corretamente planejado e implementado para avaliar o progreo do programa de qualidade e de reuo, como também aegurar que o objetivo de qualidade e de reuabilidade etão endo cumprido (IEEE1517, 1999). O Gerente de Reuo deve determinar o atributo de qualidade apropriado para a avaliação do projeto de forma a ete atingir eu objetivo. Além dio, o dado obtido da avaliação devem er armazenado de forma conitente para ua utilização em projeto futuro. (JACOBSON et al., 1997; IEEE 1517, 1999) O proceo de coleta de dado deve er imple e ferramenta automática para extração dete dado devem er utilizada, já que a quantidade de dado coletado e o gerenciamento do memo é um apecto crítico. Cao não eja poível a coleta de dado automatizada, a organização deve definir padrõe (template) para obtenção do dado, aegurando aim a melhoria da qualidade do dado obtido (MCGARRY et al., 2001). Dentro do contexto de programa de medição o termo indicadore, medida e métrica ão empregado conforme a definição a eguir (STAA, 2002): Métrica: medida quantitativa de um atributo. A métrica podem er objetiva ou ubjetiva (medida relativa ao alto ou baixo grau de precião repectivamente), direta ou indireta (medida imple ou derivada de outra medida repectivamente) e de produto ou de proceo (medida da qualidade do produto ou da qualidade do proceo repectivamente). Por exemplo, número de defeito por linha de código; 38

40 Medida: avaliação de um reultado perante uma unidade padrão. Por exemplo, 1000 linha de código; Indicador: forma de repreentação quantitativa de caracterítica de produto e de proceo utilizado para acompanhar, avaliar e melhorar o reultado ao longo do tempo. Por exemplo, aumento no número de defeito detectado na nova verão do produto de oftware. O modelo de qualidade elaborado por MCCALL et al. (1977) foi o primeiro do modelo que propô qualidade de produto de oftware como uma hierarquia de fatore, critério e métrica. Eforço internacionai também conduziram ao deenvolvimento de um padrão por medida de qualidade de produto de oftware, a norma ISO/IEC No APÊNDICE 3 é apreentada uma tabela reumida, TAB , do atributo de qualidade do produto da Norma ISO/IEC 9126 (ISO9126, 2000). Baniya e Davi relatam que todo o modelo de qualidade baeado em produto variam na definição hierárquica de qualidade, ma compartilham a eguinte dificuldade (BANSIYA et al., 2002): O modelo ão vago na ua definiçõe e na métrica neceária para atingir uma avaliação quantitativa de qualidade de produto; Falta de um etudo mai detalhado para coniderar a dependência entre atributo de qualidade, poi o atributo nem empre ão independente entre i, podendo um ou um grupo de atributo de qualidade influenciar de forma conflitante na qualidade global. Por exemplo, um objetivo de qualidade para uma alta flexibilidade dificulta a poibilidade de alcançar um objetivo de baixa manutenibilidade; O modelo não incluem como coniderar o grau de influência do atributo individualmente, poi ao avaliar a qualidade do produto como um agregado de um conjunto de atributo de qualidade, o ignificado de todo o atributo para a qualidade do produto não pode er igual e, então, a influência de um atributo pode preciar er mudada por um fator de peo. Por exemplo, para organizaçõe com rede ofiticada e proceamento em tempo real, o atributo de deempenho e de confiabilidade podem er o atributo mai importante (KAN, 1995), ao pao que para a organizaçõe com vária plataforma, o principai atributo ão a portabilidade e extenibilidade. A identificação de um conjunto de atributo de qualidade que completamente repreenta avaliação de qualidade não é uma tarefa trivial. Em geral, ete atributo etão relacionado ao objetivo gerenciai, meta empreariai, competição, economia e tempo alocado para o deenvolvimento do produto. Por io, geralmente a organizaçõe realizam um proceo de 39

41 medição com um alto rico de inuceo. A dificuldade mai comun na implantação de um proceo de mediçõe ão a eguinte (DERBY, 2001; SINGER et al., 2002): Muito programa de medição ão iniciado com a medição de atributo que ão conveniente e fácei de e medir, ao invé de e medir o dado que ão realmente neceário para uma tomada de decião. Como reultado, tem-e uma grande quantidade de dado em utilidade. Coniderando que há uma demanda de eforço para obtenção e conolidação dee dado inútei, o programa de medição acaba tornando-e muito cutoo em relação ao benefício e termina endo decontinuado. É muito comum na organizaçõe, que a métrica e tranforme em um objetivo, ao invé de uma informação útil. O egredo para manter a medição útil é colocar a atenção em eu ignificado; Muita organizaçõe não têm uma clara noção de como analiar e interpretar o dado coletado, deixando de utilizar ua mediçõe. É fundamental que a organização aloque um grupo de métrica com conhecimento etatítico, reponável pela análie do dado coletado. Também é deejável a utilização de ferramenta para apoiar a análie. E ainda, o dado coletado e o reultado de ua análie devem er armazenado em um Banco de Dado Hitórico, o qual deverá er utilizado para o controle da melhoria do proceo; Na maioria da veze, a coleta não pode er completamente automatizada, o que pode viabilizar a coleta de dado irreai e em utilidade. Ete dado podem levar a interpretaçõe errônea, má deciõe e açõe de melhoria inadequada; A peoa envolvida preciam entender por que e etá coletando dado e como o dado erão utilizado. É importante que a peoa conheçam o propóito para o qual o dado etão endo coletado e que o dado realmente ejam utilizado para o propóito informado. É importante que o profiionai entendam que: o uceo do proceo de medição depende da equipe para coletar dado e ete dado devem er acurado; ele não erão avaliado com bae nete dado; e e ele reportarem dado viciado (dado que detorçam o real deempenho para ete parecer melhor) erá obtido um banco de dado baeado em dado ditorcido, e ito pode er pior do que não ter nenhum dado. O Grupo de Métrica epecializado em medida deve er devinculado do projeto, ubordinado à área de gerência de reuo e do projeto, podendo etar ligado ao grupo de definição de padrõe (SEI, 2002). É neceário que todo tenham confiança que o uo do dado não erá feito contra a peoa e para io é precio etabelecer um protocolo claro e público, com o compromio da gerência, que tranqüilize a equipe e a faça colaborar com o coletore de dado (BRIAND et al., 1998). O dado coletado do trabalho de uma peoa ó 40

42 podem er uado em benefício deta peoa. O dado que forem negativo ao deempenho profiional de uma peoa ó poderão er tratado em caráter igiloo com eta peoa. O dado de erro que poderão er divulgado ão excluivamente aquele dado globai conolidado, índice de erro e valore de deperdício da equipe do deenvolvimento ou da organização como um todo. Uma forma de aumentar a egurança do empregado é organizar a coleta de modo que a gerência ó oberve dado agregado, nunca o reultado aociado a um ó empregado (LEWIS, 2000). Segundo Jone e a Norma ISO/IEC , o procedimento de um proceo de medição de oftware ão: (JONES, 1997; PAIVA et al., 2001) 1 - Obter apoio da alta adminitração; 2 - Definir objetivo da medição; 3 - Deenvolver um plano de implantação; 4 - Definir método de medição; 5 - Definir a coleta de dado de medição; 6 - Deignar profiionai que vão atuar no proceo de medição; 7 - Treinar o profiionai envolvido no proceo de medição; 8 - Concientizar, motivar e treinar gerente e equipe de projeto; 9 - Etabelecer uma referência para medição inicial; 10 - Etabelecer o proceo de medição; 11 - Integrar com ciclo de vida e proceo de gerência; 12 - Monitorar e modificar o proceo de medição e neceário. Jone claifica a informaçõe de um proceo de medição em trê tipo (JONES, 1997): hard (quantificada com pouco ou nenhuma ubjetividade, pouindo alto grau de precião), oft (avaliada ubjetivamente, pouindo baixo grau de precião devido à variação de opinião e comportamento comum entre peoa) e de padronização (relativa à mediçõe padrõe uada por propóito corporativo para determinar a poição do projeto em relação ao padrõe definido como meta pela organização, em termo de produtividade ou qualidade). De acordo com a finalidade de uo, a mediçõe de oftware podem er etratégica ou tática. A mediçõe etratégica ão aquela que englobam fatore que influenciam diretamente no uceo da corporação, enquanto que a tática, influenciam no reultado do projeto. Jone ainda relata que um programa completo de mediçõe deve incluir o doi tipo de mediçõe (JONES, 1997). 41

43 MEDIÇÕES TÁTICAS E HARD PARA PROJETOS OO O conceito báico de OO - encapulamento, herança e polimorfimo - requerem métrica diferente da tradicionai de produto - tamanho, complexidade, deempenho e qualidade (CHIDAMBER et al., 1994; HITZ, 1996; LI, 1993). Além dio, muito do modelo de qualidade e de métrica diponívei para análie de oftware OO ó podem er aplicado apó a fae de implementação do produto. Então, com o intuito de melhorar a redução do retrabalho durante e apó a implementação pela detecção e remoção de nãoconformidade, como também, melhorar a elaboração do plano de tete e planejamento do recuro, há uma neceidade por métrica e modelo que poam er aplicado na fae do deenvolvimento de oftware. Baniya e Davi apreentam um Modelo de Hierarquia para Avaliação da Qualidade de Projeto OO (BANSIYA et al., 2002). Nete modelo, a etrutura e o comportamento da clae, objeto e eu relacionamento ão avaliado uando um conjunto de métrica de projeto OO. Ete modelo relaciona a propriedade de projeto com o atributo de qualidade. Baniya fornece uma ferramenta de oftware, QMOOD++, para avaliação de qualidade para vário projeto OO, que permite tratar a avaliação de projeto automaticamente (BANSIYA, 1997). Eta ferramenta facilita a coleta de dado de mediçõe de componente de projeto implementado em C++. Baeado no atributo da ISO 9126, Baniya e Davi elecionam e identificam ei atributo de qualidade, que ão apreentado na TAB (BANSIYA et al., 2002). TAB : Sei atributo de qualidade de projeto OO. Atributo de Qualidade Decrição 1 - Compreenibilidade Evidencia a preença de caracterítica que revelam a facilidade em aprender e compreender. 2 - Efetividade Evidencia a preença de caracterítica para alcançar a funcionalidade e o comportamento deejado uando conceito e técnica de OO. 3 - Extenibilidade Evidencia a preença e o uo de caracterítica que permitem a introdução de novo requiito no projeto. 4 - Flexibilidade Evidencia a preença de caracterítica que permitem a um projeto de er adaptado para fornecer funcionalmente uma capacidade epecífica. 5 - Funcionalidade Evidencia a preença de caracterítica de reponabilidade atribuída à clae de um projeto que etão diponívei atravé de ua interface pública. 6 - Reuabilidade Evidencia a preença de caracterítica de projeto OO que permitem ao projeto er reaplicado para um novo problema em eforço ignificativo. 42

44 A propriedade de projeto 8, tai como, abtração, encapulamento, acoplamento, coeão, complexidade e tamanho de projeto, ão freqüentemente uada como caracterítica de qualidade de projeto tanto para deenvolvimento etrutural como OO. A menagen, compoição, herança, polimorfimo e hierarquia de clae ão conceito do paradigma OO fundamentai para a qualidade de um projeto OO. Ete modelo inclui onze propriedade de projeto identificada e definida na TAB , e a métrica correpondente uada por (BANSIYA et al., 2002). TAB : A métrica de projeto para avaliar a propriedade de projeto. Propriedade de Projeto 1 - Abtração: uma medida do apecto de epecialização / generalização do projeto. 2 - Acoplamento: define a interdependência entre objeto em um projeto. 3 - Coeão: avalia o relacionamento do método e atributo em uma clae. 4 - Complexidade: uma medida do grau de dificuldade no entendimento e compreenão da etrutura interna e externa da clae e de eu relacionamento. 5 - Compoição: medida de relacionamento do tipo parte de, tem, conite de ou parte do todo, que ão o relacionamento de agregaçõe em um projeto OO. 6 - Encapulamento: refere-e à clae que previnem quanto o aceo à declaraçõe de atributo protegendo a repreentaçõe interna do objeto. 7 - Herança: uma medida de relacionamento é uma entre a clae. Ete relacionamento é relativo ao nível da clae quanto a uma hierarquia de herança. 8 - Hierarquia: hierarquia é uada para repreentar diferente conceito de epecializaçõe/ generalizaçõe em um projeto. 9 - Menagem: uma quantia do número de método público que etão diponívei como erviço para outra clae Polimorfimo: a capacidade para ubtituir objeto cuja interface conciliam com outra em tempo de execução Tamanho do Projeto: uma medida do número de clae uada em um projeto. Métrica de Projeto Número Médio de Anteceore: eta métrica conite em contabilizar o número médio da clae que herdam informação. Acoplamento Direto da Clae: eta métrica conite em contabilizar o número de clae que ão diretamente relacionada pela declaraçõe do atributo e paagen de parâmetro do método. Coeão entre Método na Clae: eta métrica calcula a relação entre o método de uma clae baeada por uma lita de parâmetro. Número de Método: eta métrica conite em contabilizar todo o método definido em uma clae. Medida de Agregação: eta medida mede a extenão do relacionamento do tipo parte do todo realizado pelo uo do atributo. Métrica de Aceo ao Dado: eta métrica é a taxa do número de atributo privado (protegido) pelo número total de atributo declarado na clae. Medida de Abtração Funcional: eta media conite na taxa do número de método herdado por uma clae pelo número total do método aceívei por método de membro da clae. Número de Hierarquia: eta métrica conite em contabilizar o número de clae mãe no projeto. Tamanho da Interface da Clae: eta métrica conite em contabilizar o número de método público da clae. Número de Método Polimorfo: eta métrica conite em contabilizar o método que podem ter comportamento polimorfo. Tamanho do Projeto em Clae: eta métrica conite em contabilizar o número total de clae no projeto. 8 São conceito quantificávei que podem er avaliado diretamente ao examinar a etrutura interna e externa, relacionamento e funcionalidade do componente de projeto, atributo, método e clae. 43

45 Baeado na propriedade de projeto (TAB ) para o atributo de qualidade (TAB ), Baniya e Davi elaboram a funçõe de medição para ete atributo (TAB ). O índice da parcela da funçõe de medição apreentada na TAB revelam a influencia poitiva ou negativa relativa à propriedade de projeto no atributo de qualidade de forma que o valore calculado de todo o atributo de qualidade tenham a mema abrangência de 0 a +1 (BANSIYA et al., 2002). TAB : Parcela da funçõe de medição de (BANSIYA et al., 2002). Índice da Parcela da Funçõe de Medição do Atributo de Qualidade Atributo de Qualidade Abtração Acoplamento Coeão Complexidade Compoição Encapulamento Herança Hierarquia Menagem Polimorfimo Tamanho do Projeto Compreenibilidade Efetividade Extenibilidade Flexibilidade Funcionalidade Reuabilidade * (- 0.33)+ * (- 0.33)+ * * (-0.33)+ * * (- 0.33)+ * (- 0.33)+ * * * (- 0.5)+ * * * (- 0.25)+ * * * * (- 0.25)+ * * * * * * * * * * * * TÉCNICAS DE AVALIAÇÃO GOAL/QUESTION/METRIC - GQM A metodologia GQM - Goal/Quetion/Metric (Objetivo/Pergunta/Métrica) de Baili (BASILI et al., 1994) tem ido muito utilizada atualmente para definir um proceo de medição que viabiliza o acompanhamento e a avaliação do proceo de produção de oftware. Baili emprega eta metodologia para definir um proceo de coleta e análie de dado (BASILI et al., 2000). O primeiro pao de um programa de métrica é etabelecer uma referência, de forma que o progreo poa er avaliado em termo do objetivo e atravé de comparação com eta referência. Depoi, executar a metodologia GQM da eguinte forma (ALMEIDA et al., 2003): Primeiro, elecionar algun objetivo do proceo que etejam em conformidade com o objetivo organizacionai e definir ee objetivo de modo que ejam quantificávei e menurávei; 44

46 Para cada objetivo, identificar pergunta para erem repondida com a finalidade de coletar informação obre a ituação do objetivo, e etá endo alcançado ou não; Finalmente, identificar métrica que ajudem a reponder cada pergunta. Alguma dela ão direta, imple iten de dado, por exemplo, o valor total gato em reparo. Outra métrica ão indireta, calculada a partir de um ou mai iten de dado. Segundo MCGARRY (2001), o modelo GQM reolve o problema de definição de métrica, ma não de indicadore. Além dio, a aplicação do GQM pode gerar muita métrica em muita relevância para o reponávei pela deciõe PRACTICAL SOFTWARE MEASUREMENT - PSM O PSM (Practical Software Meaurement) de MCGARRY et al. (2001) é um modelo para a etruturação da medição em um projeto de oftware. Ete modelo é compoto pelo Modelo de Informação de Medição e Modelo de Proceo de Medição. O primeiro é um guia de como epecificar formalmente o indicadore a erem uado, e o egundo é um guia de como conduzir o proceo de medição. O Modelo de Informação de Medição do PSM fornece um apoio para a definição da Neceidade de Informação (o Goal do GQM) e um guia para a partir deta chegar na epecificação da métrica. Aim, ete modelo erve como um guia para o planejamento e implementação da atividade de análie e coleta de dado. O Modelo de Proceo de Medição trabalha em conjunto com o Modelo de Informação de Medição para fornecer um framework para implementação de medição em um projeto. Ete modelo foi automatizado pelo oftware PSM Inight 9. O oftware fornece facilidade para a criação de indicadore, armazenamento de dado hitórico e a geração de gráfico e relatório para a análie. 2.2 LIDANDO COM REUSO Exitem vária abordagen para reuo (veja APÊNDICE 1), dentre ela a dua abordagen técnica que mai tem e detacado na pequia ão: gerador de reuo e reuo baeado em parte. A técnica de gerador requer que um domínio de conhecimento eja 9 Diponível gratuitamente no ite do PSM: 45

47 codificado em um gerador de aplicação ou uma linguagem de programação para que o componente ejam elecionado e integrado automaticamente. O reuo baeado em parte, conhecido também como reuo de componente, requer que um programador humano integre componente de oftware em uma aplicação. Para atender o objetivo dete trabalho, o reuo de oftware abordado é o baeado em parte de acordo com um proceo bem definido e repetível reuo itemático de aet. A abordagem de reuo baeado em parte é mai abrangente do que o gerador (IEEE1517, 1999), poi o artefato ao erem contruído como aet, aumentam a reuabilidade 10. O reuo de oftware pode er aplicado a qualquer produto do ciclo de vida e não apena a fragmento de código-fonte. Deta forma, a equipe de deenvolvimento pode procurar reuo de documento de requiito, epecificaçõe de itema, etrutura de projeto e qualquer outro artefato (BARNES et al., 1991). O fato de etar reutilizando artefato tem todo o benefício conhecido da tecnologia de reutilização, endo poível fazer uo do conhecimento e da experiência adquirido em proceo de projeto da emprea ou etabelecido por outra organizaçõe ou pequiadore (FIORINI et al., 2000; HENNINGER, 1999; RISING, 1999). Entretanto, a reutilização não é trivial, ela apreenta muito problema, o principai ão: A localização e recuperação do componente de oftware a partir de uma grande coleção (GIORARDI, 1998); Auência da prática de reuo no proceo de deenvolvimento de projeto da organizaçõe (FICHMAN, 2001); O reuo requer mudança na forma de penar (IEEE1517, 1999). Ao praticar reuo, epera-e que a equipe de deenvolvimento não e concentrarem em um único produto de oftware, ma em um grupo de produto relacionado pelo requiito, funçõe e apecto comun. Além dio, epera-e que o deenvolvedore contruam aet para erem reuado empre que ocorram o memo repectivo requiito na epecificaçõe 11 ou um ubconjunto de requiito que correpondam ao conjunto de requiito do artefato a er reutilizado. Portanto, ito requer freqüentemente uma generalização do aet, conformidade com padrõe e uma etratégia de projeto para o produto de oftware (ALMEIDA et al., 2003); Para o uceo da prática do reuo de oftware, o eguinte critério devem er eguido: 10 Determina o grau em que um aet pode er uado em mai de um itema de oftware ou contruir outro aet. 11 Epecificaçõe podem ocorrer em vário nívei de abtração dede a epecificação de requiito de um itema até a epecificação de projeto detalhado de módulo ou clae. 46

48 A organizaçõe devem ter um programa de reuo que eja itemático (FRAKES et al., 1994). O reuo deve etar explicitamente definido no proceo de ciclo de vida de oftware para aegurar o reuo repetidamente no divero produto e projeto de oftware da organização (FICHMAN, 2001); A organizaçõe devem etabelecer uma política de reuo: reuo a priori (artefato projetado para reuo) ou a poteriori (artefato tranformado para reuo) (FICHMAN, 2001); A organizaçõe devem ter um programa de reuo que utilize um equema de claificação para catalogar componente em uma bae de oftware. O equema devem epecificar algun atributo, chamado de faceta, para erem utilizado como decritore de um componente de oftware. Em geral, ee atributo devem er relativo à ação que o componente realiza e ao objeto manipulado pelo componente. A claificação e a recuperação devem er realizada ao epecificar termo para cada atributo no equema. O relacionamento com termo ou frae devem er atravé da combinação de atributo, o que poibilita melhor precião na buca (GIORARDI, 1998); A organizaçõe devem ter um programa de reuo onde o reutilizadore tenham conhecimento da exitência do aet, poam er facilmente localizado e entendido, e principalmente tenham ua qualidade aegurada. Portanto, o reuo requer que o projeto de oftware eja examinado quanto à ua qualidade para maximizar oportunidade de reuo de implementação. (JACOBSON et al., 1997) FICHMAN (2001) avaliou no modelo de deenvolvimento de artefato projetado para reuo como um do mai promiore. A vantagem dete é que o deenvolvedore produzem artefato reutilizávei quando ee artefato ainda etão recente em ua mente, e apena uma única biblioteca de artefato de alta qualidade precia er mantida e procurada. Entretanto, um eforço é dependido em aber quando, ou e o artefato erá efetivamente reuado. A vantagem do artefato tranformado para reuo é er um modelo jut in time para a produção de componente, que reulta na neceidade de pelo meno de dua biblioteca: primária, contendo ó artefato aprovado para er reutilizável, e ecundária para artefato não candidato ao reuo ou ao que ainda não foi tranformado. A devantagem dete último etá no eforço extra para fazer artefato reutilizávei a partir de artefato candidato que o deenvolvedor não eteja familiarizado e na buca em mai de uma biblioteca por artefato reuávei ou artefato candidato a erem tranformado para reuo. Também, não há nenhuma garantia que um deenvolvedor execute a buca do artefato ao invé de deenvolver novamente. 47

49 O reuo itemático de oftware requer a incluão de elemento fundamentai de controle de qualidade no proceo de deenvolvimento de aet, tai como: Validação e verificação do aet, ou eja, ete devem er ubmetido a um proceo para aegurar que ele têm o atributo deejado (JACOBSON et al., 1997; FICHMAN, 2001); Medir progreo do reuo baeado em métrica relevante que poam ajudar na otimização do programa de reuo empre que neceário (FRAKESb et al., 1996); Incluir verificaçõe de reuo na reviõe de projeto e inpeçõe (IEEE1517, 1999) PROCESSO DE REUSO O proceo de reuo deve maximizar reuo e minimizar eforço báico de deenvolvimento. Então, o primeiro pao no proceo de reuo é encontrar e elecionar aet adequado. Para efetivo reuo deve er mai fácil achar aet que o deenvolver para único uo (JACOBSON et al., 1997). Ao encontrar o aet adequado não ignifica ter achado exatamente o que precia. Localizar aet emelhante pode er uficiente. Depoi que o aet foram encontrado, ele devem er entendido para erem reuado. Achar e entender etão relacionado, porque para elecionar um aet para reuo, deve-e aber o que ele faz. Entender fica mai importante quando o aet tiver que er modificado. Aim, a documentação adequada é fundamental para ete pao. Naturalmente, retriçõe legai podem proibir a diponibilidade da implementação de um aet e podem permitir eu reuo omente como uma caixa preta. (IEEE1517, 1999) Contruir um itema de oftware em preciar modificar o aet é o ideal. Geralmente, pelo meno algun do aet devem er adaptado à neceidade epecífica do itema de oftware a er contruído. O aet podem er modificado mudando caracterítica interna ou acrecentando nova caracterítica. Quando um aet oferece a funcionalidade exigida, ele deve er incorporado no itema de oftware. Porém, o aet exitente podem não er uficiente para contruir um novo itema. Portanto, algun aet devem er contruído do zero para erem inerido no repoitório de aet reutilizávei, facilitando o eu reuo em projeto futuro. (FICHMAN, 1999) Deta forma, deenvolver para reuo implica em contruir modelo de domínio e arquitetura, contruir novo aet, ou reengenhar aet exitente para melhorar ua reuabilidade. Para apoiar deenvolvimento para reuo, devem er acrecentada ao ciclo de 48

50 vida do oftware a eguinte atividade (IEEE1517, 1999) (veja eção do APÊNDICE 3): Executar análie de domínio; Executar projeto de domínio; Contruir aet reutilizávéi. Na FIG é apreentado um reume da etapa do proceo de reuo. O proceo de reuar um aet exitente requer a eguinte atividade: Buca, Entende e Adapta. A atividade Deenvolve é neceária quando nenhum aet reutilizável pode er identificado. A atividade Integra deve er feita memo que um aet exitente eja reuado ou um novo tenha ido deenvolvido. Finalmente, o novo aet ou o aet modificado deve er generalizado e claificado para er armazenado no repoitório de aet reutilizávei para futuro reuo. (FRAKESb, 1996) FIG : Procedimento para reuo de oftware. É importante que a documentação eja coniderada uma parte eencial do aet, poi em ua própria documentação um aet é inútil. Nem pode er recuperado quando for neceário e nem pode er reuado e adaptado com eforço razoável. Deta forma, a documentação de cada aet deve er clara, concia e auto-uficiente para agilizar e viabilizar o eguinte apecto: a avaliação de aet em um conjunto de poívei candidato, a compreenão da funcionalidade de um aet, o uo de um aet em um certo ambiente e a adaptação de um aet para neceidade epecífica. (SAMETINGER, 1996) 49

51 2.2.2 MODELOS E MÉTRICAS A métrica ão neceária para avaliar a robutez da arquitetura, em termo da mudança de requiito requererem mudança na arquitetura. Também ão neceária métrica para determinar a perda da reutilização em virtude de uceiva manutençõe. A perda de reutilização ocorre quando uma verão de artefato é particionada em vária verõe coexitente, em virtude da neceidade de cada uma dea verõe neceitar de atenção epecífica pela gerência de configuração e ao realizar nova alteraçõe. (ALMEIDA et al., 2003) A literatura detaca alguma métrica importante (veja TAB do APÊNDICE 2): Métrica de proceo: produtividade do trabalhador, eficácia em termo de tempo, cuto de produção, taxa de defeito detectado, volume de mudança de uma verão para outra; Métrica de biblioteca ou repoitório: freqüência de aceo, tamanho do repoitório, cuto de certificação, qualidade e quantidade de componente; Métrica de arquitetura: etabilidade; Métrica do artefato: tamanho do componente, complexidade da interface, coeão do itema de componente e interface, nível de uabilidade do componente e interface, qualidade, cuto do itema padrõe de componente, dificuldade em integrar componente; Métrica da aplicação: volume de reuo, qualidade, volume de defeito e ua caua, perfil da falta. A quantidade de reuo etá relacionada com o volume de reuo ou taxa de reuo (JACOBSON et al., 1997). A taxa de reuo é definida como a razão da oma do tamanho do artefato reutilizado dividido pelo tamanho total da aplicação. A taxa de reuo é uada para monitorar o reuo e, também, para etimar como o reuo vai incidir na medida de qualidade, tempo e cuto. Alguma organizaçõe medem o tamanho do oftware utilizando o método recomendado pela SEI (PARK, 1992): LOC (linha de código). Outra utilizam a técnica de Análie por Ponto de Função (APF) (IFPUG, 2000) ou Análie por Ponto de Cao de Uo 12 (KARNER, 1993). O tamanho do artefato não-código podem er medido em termo de linha equivalente de código ou pelo número de página de documento. 50

52 A medida de complexidade de oftware, determinada pela complexidade etrutural e tamanho, podem er uada para etimar denidade de defeito, probabilidade de erro e manutenibilidade. Já a medida de coeão e acoplamento determinam o grau de aderência e independência de um itema de componente ou que um componente tem do outro. Eta medida indicam o cuto de integrar o componente e, também, de ua manutenibilidade (JACOBSON et al., 1997). Frake e Terry claificam a métrica e o modelo de reuo como (FRAKESb et al., 1996): Modelo de Cuto / Benefício de Reuo, Modelo de Avaliação da Maturidade, Métrica de Quantidade de Reuo, Modelo de Fracao, Métrica de Reuabilidade e Métrica de Biblioteca de Reuo. O Modelo de Cuto / Benefício de Reuo incluem a análie econômica de cuto / benéfico aim como o cuto da qualidade e produtividade. O Modelo de Avaliação da Maturidade categoriza programa de reuo pelo quanto à organização etá avançada na implementação do reuo itemático. A Métrica de Quantidade de Reuo ão uada para avaliar e monitorar um eforço de melhoria do reuo pelo acompanhamento do percentual de reuo de objeto do ciclo de vida. O Modelo de Fracao é uado para identificar reuo e impedimento de reuo em uma organização. A Métrica de Reuabilidade indicam a probabilidade que um artefato é reutilizável. A Métrica de Biblioteca de Reuo ão uada para gerenciar e acompanhar o uo de um repoitório de reuo. O critério de avaliação para indexar equema de biblioteca de reuo é: cuto, buca pela efetividade, uporte para entendimento e eficiência A organizaçõe freqüentemente neceitam dee modelo e métrica neta ordem apreentada por Frake e Terry (FRAKESb et al., 1996). A maioria do modelo econômico de engenharia de oftware precia er ajutada para incluir reuo, e cutomizada para cada reuo epecífico. Muito autore têm modificado o modelo de cuto, como COCOMO (BOEHM et al., 1988), que ão uado para etimar tempo e eforço e para o deenvolvimento tanto de componente quanto de aplicaçõe uando componente (POULIN, 1997). Jacobon et al. (JACOBSON et al., 1997) apreentam como uar um modelo de eforço e cuto de reuo implificado, eencialmente reformulando a análie de Gaffney e Durek (GAFFNEY et al., 1989) e aplicando a recomendaçõe de Poulin (POULIN, 1997). Ele também adiciona um fator de utilização de biblioteca, poi em uma biblioteca de itema de 12 A Rational deenvolveu uma Análie por Ponto de Cao de Uo imilar à Análie por Ponto de Função, que pode er utilizada para etimar o tamanho de uma aplicação baeada no número e complexidade de atore e cao de uo. 51

53 componente que contém vário itema de componente, é eperado que ocorra mai reuo para o itema de aplicação. Jacobon ainda relata que algun componente podem er mai reuado do que outro. O APÊNDICE 2 apreenta uma tabela reumida da principai métrica e modelo apontado pela literatura, utilizando a claificação de Frake e Terry (FRAKESb et al., 1996). 3 PROCESSO DE GARANTIA DA QUALIDADE DE SOFTWARE BASEADO EM REUSO SISTEMÁTICO DE ASSETS Com o objetivo de garantir a qualidade do artefato gerado para compor o aet no ciclo de vida do deenvolvimento de projeto baeado em reuo apreentado por (GURGEL, 2004), ete trabalho apreenta uma propota de um Proceo de Garantia de Qualidade de Software (GQS). Ete proceo etabelece um framework para auxiliar no deenvolvimento do ciclo de vida do oftware baeado em reuo itemático de aet com o explícito propóito de contribuir para a qualidade e produtividade do projeto de oftware dentro do contexto do Minitério da Defea e de eu Comando Subordinado (FIG. 3-1). P r o c e o d e G a r a n ti a d a Q u a l i d a d e d e S o f tw a r e P C Q - P r o c e o d e C o n t r o l e d a Q u a l i d a d e P AA - P r o c e o d e Ap r o v a ç ã o d e A e t S P V - S u b p r o c e o d e V e r i fi c a ç ã o S P R - S u b p r o c e o d e R e v i ã o S P M - S u b p r o c e o d e M e d i ç ã o e Av a l i a ç ã o A T U A C o n te x t o d o M i n i t é r i o d a D e fe a e d e e u C o m a n d o S u b o r d i n a d o Ó r g ã o C e n t r a l d e G e r ê n c i a d e R e ú o P r o c e o d e Aq u i i ç ã o Ó r g ã o D e c e n t r a l i z a d o d e F o r n e c i m e n t o d e S o f t w a r e P r o c e o a o L o n g o d o P r o j e t o P r o c e o d e E n g e n h a r i a d e D o m í n i o F o r n e c i m e n t o P r o c e o d e G e r ê n c i a d e A e t P r o c e o d e D e e n v o l v i m e n to P r o c e o d e O p e r a ç ã o FIG. 3-1: Ecopo do Proceo de Garantia da Qualidade de Software. Gurgel decreve obre o contexto do Minitério da Defea dede ua criação em 1999 à formação do Departamento de Ciência e Tecnologia na Força Armada e, também, apreenta a atual etrutura do Comando da Marinha, Exército e Aeronáutica (GURGEL, 52

54 2004). O Minitério da Defea é uma intituição de grande porte, hierarquizada e com núcleo de deenvolvimento decentralizado conforme apreentado em (GURGEL, 2004). O modelo de produção de reuo utilizado por (GURGEL, 2004) para reuo itemático de oftware para o contexto do MD conite na combinação da análie de domínio pre-project 13 e da generalização em in-project 14 (FICHMAN, 2001), de forma a identificar artefato reutilizávei no domínio do projeto ante do deenvolvimento do projeto e empre gerar produto de oftware genérico (o mai poível) e reutilizávei. A propota de (GURGEL, 2004) etá apoiada na arquitetura da Norma ISO/IEC (ABNT12207, 1998) que é etendida pela Norma IEEE 1517 (1999) para atender um modelo de ciclo de vida de oftware com reuabilidade (veja ANEXO 1). Eta arquitetura foi empregada por utilizar uma terminologia bem definida compota de proceo, atividade e tarefa para Aquiição, Fornecimento, Deenvolvimento, Operação, Engenharia de Domínio e Gerência de Aet. O trabalho, aqui propoto, conite em etabelecer um embrião de um proceo etável de garantia da qualidade do oftware dentro deta nova abordagem reuabilidade, aplicado à etrutura organizacional do Minitério da Defea e ao Proceo de Deenvolvimento de Software baeado em Reuo para MD de (GURGEL, 2004). Ete trabalho etá baeado na definiçõe de padrõe de proceo mai utilizado atualmente pela indutria e organizaçõe, tai como, CMM, CMMI, ISO 9000, ISO e ISO 15504, além da Norma IEE1517. O proceo etabelecido nete trabalho abrangem diferente nívei de maturidade do CMM e CMMI. Além dio, ete trabalho e detina a propor um modelo de getão de qualidade baeado na metodologia PDCA - Plan/Do/Check/Action - Ciclo de Deming (DEMING, 1982), que inclui técnica e procedimento que devem er incorporado por toda a peoa do Órgão de Fornecimento de Software. De acordo com o Nível 3 (Definido) do CMM (PAULK et al., 1993) e o proceo de apoio da Norma (ABNT12207, 1998), o Proceo de Garantia da Qualidade de Software (GQS) propoto etabelece ponto de revião e checklit na divera fae do Proceo de Deenvolvimento de Software baeado em Reuo para MD de (GURGEL, 2004), atravé de ubproceo de Revião (SPR) e Verificação (SPV) repectivamente (veja FIG. 3-1). 13 Nete modelo, tenta-e identificar abtraçõe e deenvolver artefato reutilizávéi com grande potencial de aplicação para uma família de projeto que reidem no memo domínio. Em geral, ete artefato ão reutilizado em futuro projeto como a i ou podem er epecializado. 14 Generalização durante o projeto. 53

55 Baeado no Proceo de Apoio da Norma (ABNT12207, 1998) e no Nível 3 (Definido) do Modelo CMM, o proceo propoto conite em prover o gerenciamento, com a adequada viibilidade, do proceo que etá endo utilizado pelo projeto de deenvolvimento de oftware e do artefato que etão endo contruído. Ete proceo inpeciona o produto de oftware e atividade para verificar e etão cumprindo o procedimento e padrõe aplicávei. O objetivo é fornecer o reultado dea reviõe ao Gerente de Reuo e à equipe de deenvolvimento/montadore. Além dio, com o objetivo de deenvolver e utentar uma capacidade de medição uada para uportar gerencialmente a neceidade de informação, no proceo propoto é definido um ubproceo de Medição e Avaliação (SPM) baeado na área de proceo de Medição e Análie do Nível 2 (Gerenciado) do modelo CMMI (SEI, 2002). Eta área envolve o eguinte apecto: Epecificação do objetivo de medição e análie de forma que ete ejam alinhado com o objetivo e a neceidade de informação identificada; Epecificação da medida, mecanimo de coleta de dado e de armazenamento, técnica de análie, e mecanimo de comunicação e de feedback; Implementação da coleta, armazenamento, análie e comunicação do dado; Fornecimento de reultado objetivo que podem er uado na tomada de decião e implementação de açõe corretiva adequada. Nete trabalho, um proceo de Controle da Qualidade (PCQ) é epecificado ao etabelecer o ubproceo de Verificação (SPV), Revião (SPR), e Medição e Avaliação (SPM). Para garantir que o aet definido em (GURGEL, 2004) poam er claificado e gerenciado para reuo, o proceo propoto deve validar o artefato que compõem o aet. Para ito, um proceo de Aprovação de Aet (PAA) é definido, e ete deve etar em intonia com o proceo de Controle da Qualidade (IEEE1517, 1999). Com o objetivo de deenvolver com e para reuo de aet e de produzir aet de qualidade, a gerência de reuo deve implantar e utilizar o proceo abordado nete capítulo. É fundamental que toda a peoa do Órgão envolvido com o deenvolvimento de oftware tenham incorporado a prática dete proceo em ua rotina. 54

56 3.1 ESTRUTURA ORGANIZACIONAL DO GRUPO DE GARANTIA DA QUALIDADE DE SOFTWARE Como o Minitério da Defea é uma intituição centralizadora e hierárquica, que poui Comando Subordinado, e ete comando, por ua vez, contém vário órgão de deenvolvimento com diferente área de atuação, ete trabalho propõe, de acordo com a abordagem etabelecida em (GURGEL, 2004), uma etrutura organizacional para o Grupo da Garantia da Qualidade de Software (GQS). Grupo da Garantia da Qualidade de Software Corporativo (GGQSC) Comitê de Qualidade do Órgão Decentralizado de Fornecimento de Software 1 Legenda Alocado no Órgão Central de Gerência de Reúo Alocado em cada Órgão Decentralizado de Fornecimento de Software Grupo da Garantia da Qualidade de Software (GGQS) 1 Grupo de Métrica 1 Comitê de Qualidade do Órgão Decentralizado de Fornecimento de Software n Grupo da Garantia da Qualidade de Software (GGQS) n Grupo de Métrica n FIG : Etrutura da área do Grupo da Garantia da Qualidade de Software (GGQS). Na FIG etá repreentada uma organização etrutural do Grupo da GQS (Garantia da Qualidade de Software), onde um Grupo de GQS Corporativo deve er centralizador para er o olho e ouvido da Gerência de Reuo, e a ete grupo vário Comitê de Qualidade devem etar ubordinado. O objetivo dete comitê é garantir a reuabilidade e qualidade no deenvolvimento de oftware na divera organizaçõe fornecedora. Para cada comitê devem exitir doi grupo ubordinado: um Grupo de GQS e um Grupo de Métrica. O Grupo de GQS conite na verificação e inpeção de artefato/aet produzido no proceo de deenvolvimento de oftware, ao pao que o Grupo de Métrica deve er reponável por medir e analiar o dado coletado e armazenado para avaliação do proceo de deenvolvimento e do produto de oftware. Eta organização etrutural aplicada ao contexto do Minitério da Defea é apreentada na FIG onde um Grupo de GQS Corporativo deve etar ligado ao Minitério da Defea via Órgão Central de Gerência de Reuo, Departamento de Ciência e Tecnologia. Cada Órgão 55

57 Decentralizado de Fornecimento de Software deve ter eu Comitê de Qualidade formado por Conultore da Qualidade, e um Grupo de GQS e um Grupo de Métrica devem etar ubordinado a ete comitê. Legenda Grupo de GQS Corporativo alocado ao Órgão Central de Gerência de Reúo Comitê de Qualidade com o Grupo de GQS e Grupo de Métrica alocado em cada Órgão Decentralizado de Fornecimento de Software MINISTÉRIO DA DEFESA SECRETARIA DE LOGISTICA E MOBILIZAÇÃO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA Comião Aeora de Ciência e Tecnologia para a Defea COMANDO DA MARINHA COMANDO DO EXÉRCITO COMANDO DA AERONÁUTICA Etado Maior da Armada Centro de Apoio a Sitema Navai Comando de Operaçõe Navai Serviço Geral da Marinha Diretoria Geral de Material da Marinha Diretoria Geral de Navegação Secretaria de Tecnologia da Informação Secretaria de Ciência e Tecnologia Departamento de Controle Aéreo Departamento de Enino Comando em Chefe Diretoria de Adminitração da Marinha Diretoria de Sitema de Arma da Marinha Diretoria de Hidrografia e Navegação Centro de Deenvolvimento de Sitema Centro Tecnológico do Exército Sub-Departamento de Tecnologia da Informação Intituto Tecnológico da Aeronáutica Centro de Apoio a Sitema Operativo Diretoria de Telecomunicação da Marinha Centro Integrado de Telemática do Exército Intituto Militar de Engenharia Centro de Computação da Aeronáutica de Braília Intituto de Pequia da Marinha Centro Integrado de Guerra Eletrônica Intituto de Pequia e Deenvolvimento Centro de Computação da Aeronáutica de São Joé do Campo Diretoria Material de Centro de Diretoria de Serviço Comunicaçõe, Computação da Geográfico Eletrônica e Aeronáutica do Rio Informática de Janeiro FIG : Grupo da Garantia da Qualidade de Software (GGQS) no contexto do MD. O Conultore da Qualidade não devem fazer parte da equipe de deenvolvedore/ montadore. Já o Grupo de GQS deve er formado por deenvolvedore/montadore elecionado pelo Comitê de Qualidade para exercerem o papel de verificadore/reviore de artefato, dede que não tenham vínculo operativo com o artefato em quetão, cujo propóito é de garantir que o proceo de Engenharia de Domínio e de Deenvolvimento etejam endo eguido (atividade, tarefa e artefato). Todo o Comitê de Qualidade do Órgão Decentralizado de Fornecimento de Software devem e reportar ao Grupo da GQS Corporativo de forma que ete poa obter ubídio para verificar a neceidade e oportunidade para realizar a melhoria do proceo de toda a corporação quanto ao proceo de deenvolvimento de oftware. De acordo com o Nível 4 (Gerenciado) do CMM (PAULK et al., 1993) e o Nível 2 (Gerenciado) do CMMI (SEI, 2002), um Grupo de Métrica deve ter epecialita em etatítica para fornecer uporte ao projeto da corporação com finalidade de analiar o dado conolidado do Órgão Decentralizado de Fornecimento de Software. A 56

58 ferramenta etatítica, como Gráfico de Controle, Hitograma e Pareto, devem er uada para análie e melhoria do proceo. É importante realtar que o Comitê da Qualidade não pode er vito como ficalizador. O papel do conultor ou facilitador da qualidade é apoiar a equipe de deenvolvimento para melhoria da qualidade de eu projeto. No entanto, não e pode fugir do papel de ficalizador, cao a equipe eja reitente a trabalhar com bae no proceo. Todo o reultado devem er reportado para a Gerência de Reuo, poi eta precia ter viibilidade do que etá acontecendo. Pode er que o proceo não eteja adequado para a organização. Para tirar o papel de ficalização da qualidade, o dado ão reportado empre de forma conolidada, para não e enfatizar um culpado. 3.2 GARANTINDO A QUALIDADE O proceo de Garantia da Qualidade de Software (GQS) tem como propóito etabelecer um conjunto de diretrize para o planejamento e a execução de um proceo de avaliação de um produto de oftware ao definir a atividade que devem er executada. O proceo de Garantia da Qualidade de Software (GQS) e inicia juntamente com o Plano de Aquiição 15 pelo Grupo de Garantia da Qualidade de Software Corporativo atravé do artefato Neceidade do Cliente e Gloário 16 fornecido pelo Cliente no Proceo de Aquiição (veja FIG ). A partir dete artefato, o Grupo de GQS Corporativo deve criar e documentar um Manual da Qualidade de Projeto, onde devem er epecificado o objetivo para aegurar a qualidade do aet e proceo utilizado para deenvolver o produto de oftware (artefato) que vão compor ete aet, além do objetivo para garantir a atifação do cliente. Nete manual também deve etar epecificado o ecopo da avaliação (da verificaçõe, reviõe e mediçõe a erem realizada no produto), o método utilizado e a reponabilidade de todo envolvido no proceo de avaliação. Na FIG ão apreentada a interaçõe do Proceo de Garantia da Qualidade de Software (PGQS) com o proceo de (GURGEL, 2004), epecificando o artefato de entrada/aída com eu repectivo papéi e o reponávei pelo PGQS. 15 Artefato da atividade Preparação do Plano de Aquiição do Proceo de Aquiição do Proceo de Deenvolvimento de Software baeado em Reuo para MD de (GURGEL, 2004). 16 O artefato Neceidade do Cliente e Gloário defini o domínio do problema, funcionalidade e caracterítica deejada, e gloário de termo do domínio da aplicação. 57

59 Cliente Proceo de Engenharia de Domínio Engenheiro de Domínio Proceo de Deenvolvimento Deenvolvedore /montadore Neceidade do Cliente e Gloário artefato/aet artefato/aet Proceo de Garantia da Qualidade de Software Grupo de GSQ Corporativo / Comitê de Qualidade Manual da Qualidade do Projeto Aet + Documentação Stakeholder Proceo de Gerência de Aet Gerente de Reúo FIG : Proceo de Garantia da Qualidade de Software. O Grupo de GQS Corporativo envia ete manual junto com o Pedido da Propota 13 ao Comitê da Qualidade do Órgão de Fornecimento de Software interno ou externo à organização para que ete comitê poa etabelecer o Grupo de Garantia de Qualidade de Software, e definir um Plano e Cronograma de Garantia da Qualidade para o projeto em quetão. Tanto o plano como o cronograma devem er integrado pelo Plano de Gerência de Projeto 17. Para cada referência etabelecida pelo Plano de Gerência de Projeto, ete proceo deve epecificar o iten a erem verificado, reviado e armazenado de acordo com o Manual da Qualidade do Projeto e o Plano de Garantia da Qualidade do Software do Projeto (PGQSP). Ete plano deve er implementado e mantido durante a vigência do Contrato do Projeto 18 (ABNT12207, 1998; ABNT9000, 2001), e deve etabelecer o eguinte iten: Reponável pela atividade de GQS no projeto: identifica o nome do conultor de GQS alocado ao projeto pelo Comitê de Qualidade; Padrõe e procedimento para a atividade de GQS: o conultor de GQS deve utilizar, na execução da atividade de GQS no projeto de oftware e na realimentação acerca deta atividade, o padrõe e procedimento etabelecido no Plano de Gerência do Projeto verão <X.X>. A reponabilidade e autoridade do grupo de GQS devem etar definida no Documento de Implementação de GQS do Órgão Militar; 17 Ete artefato é produto da atividade Preparação do Plano de Gerência de Projeto do Proceo de Fornecimento propoto por (GURGEL, 2004). (Veja ANEXO 1). 18 Ete artefato é produto do Proceo de Aquiição propoto por (GURGEL, 2004). (Veja ANEXO 1). 58

60 Padrõe e procedimento de projeto: informa o padrõe e procedimento que devem er eguido pelo projeto de oftware a er verificado / reviado pelo verificador / revior no Plano de Gerência do Projeto; Ferramenta: informa a ferramenta, cao haja, que deve er utilizada para regitro e acompanhamento da atividade de GQS. Eta ferramenta deve fornecer o apoio neceário para a documentação e o ratreamento do iten de não-conformidade até ua concluão; Treinamento: neceidade de algum treinamento epecífico em GQS requerido por alguma circuntância no contexto do projeto. Ee item é opcional; Hitórico de verõe: informa dado de hitórico da verõe anteriore e da atual do artefato, tai como data da verão, número eqüencial da verão, breve decrição do motivo da verão, autor reponável pela verão, o nome do revior e por quem foi aprovado; Cronograma de verificaçõe / reviõe: informa o cronograma para a verificaçõe / reviõe de GQS no projeto e o eforço em homen-hora empregado pelo conultor de GQS e pela equipe de deenvolvimento que participam dea atividade. A não-conformidade à neceidade do cliente detectada no Proceo de Controle da Qualidade devem er regitrada no Relatório de Verificação ou Revião para análie e avaliação. Além dio, apó a elaboração de cada relatório, um quetionário de olicitação de ugetõe de melhoria da qualidade deve er repondido e comentado para capturar e aplicar a liçõe aprendida no controle da qualidade de forma a contribuir para melhorar ete proceo. O preenchimento dete quetionário pelo executor da verificação / revião não deve ultrapaar a quinze minuto. Na entrega do Projeto de Software ao Cliente, o Manual da Qualidade do Projeto deve conter todo o artefato produzido para avaliação e o reultado obtido, o problema e a reolução dete problema que urgiram durante todo o ciclo de vida de deenvolvimento do Projeto, incluive o Plano e Cronograma de Garantia da Qualidade. É importante realtar que todo o artefato do Proceo de Garantia da Qualidade de Software devem etar diponívei a toda equipe de deenvolvimento/montadore a qualquer momento para que, aim, ete artefato poam contribuir como uporte na elaboração do produto de oftware da atividade do proceo de Engenharia de Domínio e Deenvolvimento de (GURGEL, 2004). Além dio, o regitro da atividade e da tarefa de Garantia da Qualidade, do problema detectado e da avaliação do problema devem er mantido e diponibilizado a todo intereado (takeholder). 59

61 Na eçõe eguinte, atravé da técnica de modelagem SADT (Structure Analyi and Deign Technique) deenvolvida por Dougla T. Ro (ROSS, 1984) e SOFTech, ão definido por meio do actigrama o Proceo de Controle de Qualidade (PCQ) ao Nível Técnico e eu repectivo ubproceo (veja FIG. 3-1), e o Proceo de Aprovação de Aet (PAA) PROCESSO DE CONTROLE DE QUALIDADE - PCQ O Proceo de Controle de Qualidade conite na identificação de problema com relação ao requiito de qualidade etabelecido ao longo de todo o deenvolvimento do oftware, ou eja, na epecificação da neceidade e requiito, modelagem conceitual, arquitetura de domínio, projeto lógico, implementação, tete e implantação. Deta forma, ete proceo deve avaliar o artefato produzido tanto no nívei de gerenciamento do projeto como no nívei técnico durante a vigência do Contrato do Projeto (ABNT12207, 1998) NÍVEL DE GERENCIAMENTO O Proceo de Controle de Qualidade (PCQ) ao Nível de Gerenciamento conite em exercer avaliaçõe gerenciai. No último dia útil do mê, o Gerente do Projeto deve realizar eta avaliaçõe, verificando o andamento e ituação do projeto conforme cronograma etabelecido no Plano de Gerência do Projeto e o gerenciamento do recuro e treinamento neceário para a equipe de deenvolvimento/ montadore do Projeto de Software. O dado deta avaliaçõe devem er informado formalmente ao Subproceo de Medição e Avaliação por meio de um relatório de avaliação do acompanhamento juntamente com o plano de trabalho atualizado cronograma (veja FIG ). De poe dete relatório e do cronograma atualizado, o Grupo de Métrica deve alimentar ua bae de dado gerencia obre projeto para obtenção de indicadore de produtividade do proceo de deenvolvimento do oftware. Na FIG ão apreenta a interaçõe do Proceo de Controle da Qualidade (PCQ) ao Nível de Gerenciamento com o proceo de (GURGEL, 2004), apreentando o artefato de entrada/aída com eu repectivo papéi e o reponávei pelo PCQ. 60

62 Proceo de Fornecimento Gerente do Projeto Plano de Gerência do Projeto Proceo de Controle de Qualidade (PCQ) ao Nível de Gerenciamento Conultor de Qualidade do Projeto / Gerente de Projeto Relatório de Avaliação de Acompanhamento de Projeto Cronograma atualizado + Relatório de Avaliação de Acompanhamento de Projeto Grupo de GQS Corporativo Gerente de Reúo Subproceo de Medição e Avaliação Grupo de Métrica FIG : Proceo de Controle de Qualidade ao Nível de Gerenciamento. A atividade do Proceo de Controle de Qualidade ao Nível de Gerenciamento é a Avaliação de Getão do artefato e recuro. Eta atividade deve er realizada em reunião pelo Conultor de Qualidade do Projeto, exercendo o papel de revior, e o Gerente de Projeto, como autor. A eqüência de tarefa deta atividade conite em: 1 - Avaliar a ituação do projeto em relação ao Plano de Gerência de Projeto e Cronograma; 2 - Regitrar a ituaçõe de rico e problema detectado na tarefa anterior; 3 - Definir um equema para categorizar e priorizar o problema. Cada problema deve er claificado por categoria e prioridade para facilitar a análie à reolução do problema; 4 - Atravé da análie de Pareto (ARTHUR, 1993), o problema devem er claificado por categoria em uma tabela ou utilizando o Diagrama de Pareto (PALMER, 1997) - quadro de barra de categoria de freqüência de ocorrência em cada categoria, com a categoria ordenada da maior para a menor freqüência; 5 - Para cada problema, identificar a caua e analiá-la; 6 - Para cada problema, o regitro do problema, a reolução do problema encontrada e ua aplicação devem er documentada no relatório de acompanhamento, e ete enviado ao Grupo de GQS Corporativo, Gerente de Reuo e Grupo de Métrica. Ao Subproceo de Medição e Avaliação, também é enviado o cronograma atualizado para que o Grupo de Métrica, juntamente com o relatório de acompanhamento, poa alimentar ua bae de dado gerenciai para obtenção de indicadore de produtividade de proceo de deenvolvimento de oftware. O reultado deta atividade deve etar acordado pelo revior e autor de forma a: Fazer com que a atividade de elaboração do artefato progridam de acordo com o Plano de Gerência do Projeto, baeada em uma avaliação da ituação do artefato; Manter o controle geral do projeto atravé da alocação adequada de recuro; 61

63 Redirecionar o projeto ou determinar a neceidade de um planejamento alternativo; Avaliar e gerenciar ituaçõe de rico que poam comprometer o uceo do projeto NÍVEL TÉCNICO O Proceo de Controle de Qualidade (PCQ) ao Nível Técnico conite em exercer avaliaçõe técnica do artefato/aet produzido no proceo de Engenharia de Domínio e de Deenvolvimento, aim como, do documento Neceidade do cliente e Gloário do proceo de Aquiição do Proceo de Deenvolvimento de Software baeado em Reuo para MD (GURGEL, 2004) (veja FIG ). Na FIG ão apreentada a interaçõe do Proceo de Controle da Qualidade (PCQ) ao Nível Técnico com o proceo de (GURGEL, 2004), apreentando o artefato de entrada/aída com eu repectivo papéi e o reponávei pelo PCQ. Ete proceo abrange o ubproceo de Verificação (SPV), Revião (SPR), e Medição e Avaliação (SPM), que erão detalhado na próxima ubeçõe. Proceo de Aquiição Gerente de Reúo Proceo de Engenharia de Domínio Engenheiro de Domínio Proceo de Deenvolvimento Deenvolvedore /montadore Neceidade do Cliente e Gloário artefato/aet artefato/aet Proceo de Controle de Qualidade (PCQ) ao Nível Técnico Conultor de Qualidade do Projeto / GGQS / Grupo de Métrica Relatório de Verificação, Revião e Medição e Avaliação aet + artefato com qualidade aprovada Epecificação de Requiito do Aet Relatório de Verificação do Aet GGQSC Gerente de Reúo Gerente do Projeto Deenvolvedore/ Montadore Proceo de Aprovação de Aet Comitê da Qualidade FIG : Proceo de Controle de Qualidade ao Nível Técnico. Ete proceo inicia com o recebimento de um artefato prontificado pelo engenheiro de domínio ou pela equipe de deenvolvimento/montadore para er inpecionado ou verificado, conforme o PGQSP e cronograma do projeto. No final de cada emana, o Gerente do Projeto deve receber do Comitê de Qualidade o relatório da avaliaçõe técnica realizada (Relatório de Verificação e Revião) na emana. Ete relatório devem conter toda a nãoconformidade detectada e devem er produzido pelo Grupo de GQS e Conultor de Qualidade alocado ao projeto, conforme o PGQSP. 62

64 A cada nova verão do projeto, conforme etipulado no Plano de Gerência do Projeto, o Grupo de Métrica deve medir e analiar o dado coletado no Subproceo de Verificação e Revião, e deve enviar um Relatório de Medição e Avaliação, juntamente com todo o Relatório de Verificaçõe e Reviõe gerado no período de uma verão para a eguinte, ao Gerente de Reuo e do Projeto uma emana apó da prontificação da verão. O Gerente de Projeto juntamente com o Conultor de Qualidade devem determinar quando e quai não-conformidade devem er reolvida pela equipe de deenvolvimento / engenheiro de domínio. Apó a cada alteração ou quando uma nova referência for etabelecida, é neceário repetir o Controle de Qualidade. Na FIG é apreentada a expanão do proceo e ubproceo que compõem o Proceo de Garantia da Qualidade do Software, motrando toda a interaçõe com o proceo do Órgão Central de Gerência de Reuo e do Órgão Decentralizado de Fornecimento de Software de (GURGEL, 2004), além do feedback à equipe de deenvolvimento/montadore e gerência. 63

65 Proceo de Garantia de Qualidade do Aet no Contexto do Minitério da Defea e de eu Com ando Subordinado Órgão Central de Gerência de Reúo Proceo de Aquiição Proceo de Garantia de Qualidade de Software PCQ - Proceo de Controle da Qualidade SPM - Subproceo de Medição e Avaliação Relatório Verif icação aretef ato Relatório de Rev ião artef ato Neceidade do Cliente + Gloário Gerente de Reúo GGQSC Manual da Qualidade Relatório de Verificação, Revião, Medição e Avaliação SPV - Subproceo de Verificação Epecif icação de requiito do aet Relatório Verif icação do aet Relatório de Aprovação do Aet Proceo de Gerência de Aet Aet de Domínio+ documentação Aet de Arquitetura de Domínio + documentação Aet de Componente de Domínio + documentação Aet de Componente + documentação PAA - Proceo de Aprovação de Aet aet + artef ato com qualidade aprov ada SPR - Subproceo de Revião Checklit, TLH,TLV, Relatório de Verif icação, Rev ião, Medição e Av aliação Modelo de Contexto Modelo Conceitual do Domínio Modelo de Cao de Uo do Domínio + Cenário Modelo de Caracterítica Modelo Tipo do Negócio Interface da Camada de Negócio e Tipo de Dado Interface da Camada de Aplicação Diagrama de Interaçõe entre Camada Arquitetura de Domínio Epecificação de Componente do Domínio Proceo ao Longo do Projeto Engenharia de Domínio Interface do Componente do Domínio Arquitetura de Domínio Código-fonte Cao de Tete aet + documentação Relatório de Tete Stakeholder Proceo de Deenvolvimento Manual da Qualidade Equipe de Deenv olv imento/ Montadore Gerente de Projeto Órgão Decentralizado de Fornecimento de Software PGQSP + Cronograma de Qualidade Proceo de Fornecimento Plano de Gerência de Projeto FIG : Ampliação do Proceo de Garantia da Qualidade do Software. O Proceo de Controle de Qualidade (PCQ), atravé da verificaçõe do Subproceo de Verificação, deve garantir que o artefato Neceidade do Cliente e Gloário, a Arquitetura do Domínio, o Código-Fonte e o Tete de Qualificação do Deenvolvimento ejam aceitávei pelo cliente e adequado quanto ao padrõe, ratreabilidade, corretude, completude, recuro e ecalabilidade. Além dio, atravé do Subproceo de Revião, o PCQ deve aegura que o artefato e ua repectiva documentaçõe produzido pela Engenharia de Domínio etejam de acordo com o a neceidade e caracterítica deejada 64

66 epecificada no documento Neceidade do Cliente e Gloário. Pelo Subproceo de Medição e Avaliação, o PCQ deve garantir que a mediçõe do proceo e produto de oftware etejam de acordo com o procedimento etabelecido de reuabilidade e atifação do cliente. No cao de ubcontratação, ete proceo deve garantir que o artefato/aet da ubcontratada atifaçam a neceidade do Contrato original, repaando a neceidade e caracterítica deejávei aplicávei e executando verificaçõe e reviõe durante a fae de deenvolvimento de cada referência fornecida (ABNT12207, 1998) SUBPROCESSO DE VERIFICAÇÃO SPV O Subproceo de Verificação tem o propóito de definir a atividade para verificar artefato/aet, via a Técnica de Checklit baeado em Apecto, a fim de determinar ua conformidade com o requiito e padrõe etabelecido para o projeto (veja FIG ). O artefato e o aet com ua repectiva documentaçõe verificado ão o eguinte produto do Proceo de Deenvolvimento baeado em Reuo para MD de (GURGEL,2004): Neceidade do Cliente e Gloário, Arquitetura de Domínio, Código-fonte, Cao de Tete de Qualificação, Aet de Domínio, Aet de Arquitetura de Domínio, Aet de Componente de Domínio e Aet de Componente. Ete ubproceo abrange dua atividade, que ão apreentada no diagrama da FIG : Planejamento (SPV-A1) e Verificação (SPV-A2). Modelo PGQSP Modelo Checklit SPV - SUBPROCESSO VERIFICAÇÃO Manual da Qualidade Plano de Gerência de Projeto Planejamento SPV-A1 Checklit Cronograma Plano de Verif icação Conultor de Qualidade artef ato / aet Verif icação SPV-A2 Relatório de Verif icação Verif icador FIG : Diagrama de Contrução do Subproceo de Verificação (SPV). 65

67 Ete ubproceo inicia o Planejamento da Verificação (SPV-A1) quando do recebimento da Manual da Qualidade pelo Comitê de Qualidade para obtenção do requiito e objetivo do projeto, com o propóito de produzir um plano de verificação (PGQSP da Verificação), cronograma da atividade de verificação e elaboração da lita de conferência (checklit) adequada ao artefato/aet a erem verificado. O Plano de Gerência do Projeto (artefato do Proceo de Fornecimento de (GURGEL, 2004)) deve er aderente a ete plano e cronograma de verificação. É importante realtar que todo o produto de qualidade gerado nete ubproceo devem er incorporado no Manual da Qualidade. Portanto, o Gerente de Projeto, deve obter o dado do plano de verificação e cronograma da verificação para o Plano de Gerência do Projeto via Manual da Qualidade. A atividade de Verificação (SPV-A2) inicia ao receber um artefato/aet upracitado que foi produzido para uma determinada verão conforme cronograma do projeto definido no Plano de Gerência do Projeto. Apó doi dia útei do recebimento, o verificador deve enviar o Relatório de Verificação ao Conultor de Qualidade alocado ao projeto. Para apoiar o verificadore quanto ao objeto de verificação, o Conultor de Qualidade deve etabelecer lita de conferência (checklit) adequada ao artefato e requiito do projeto, reuando um modelo de checklit aplicável ao artefato e requiito do projeto a er verificado, e exitir. O verificadore devem empregar o método checklit para detecção de defeito, por er itemático ao ajudar a definir reponabilidade ao verificadore, por ugerir um modo ao verificadore para identificar não-conformidade, e principalmente por fornecer um modelo prático em neceitar de treinamento prévio. Laitenberger (LAITENBERGER, 2002) relata que 25 artigo apontam o método checklit como um do método de detecção de defeito mai utilizado na indútria de oftware. O checklit é itemático, poi ajuda definir a reponabilidade do verificadore e ugere um modo ao verificadore para identificar defeito, ou eja, apreenta lita de pergunta (iten do checklit) que devem er repondida durante a leitura do documento. O iten do checklit capturam liçõe importante adquirida de verificaçõe anteriore dentro de um ambiente ou domínio da aplicação. O iten de checklit particularmente podem enumerar caracterítica de defeito, priorizar diferente defeito ou apreentar pergunta que auxiliam o verificadore decobrirem defeito. Entretanto, ete método apreenta alguma dificuldade como (LAITENBERGER, 2002): 66

68 Freqüentemente eta abordagem e tornar não itemática devido à pergunta erem gerai e não adequada uficientemente a um determinado ambiente de deenvolvimento, provendo pouco apoio para o verificador entender o artefato inpecionado; Falta de uma etratégia de como uar o checklit para reponder a uma determinada pergunta. Não fica claro que abordagem o verificadore devem eguir ao uar um checklit e como ele chegam ao eu reultado - defeito detectado. O verificador pode conduzir uma única pergunta por todo o artefato, reponde a pergunta e egue para a próxima pergunta, ou o verificador lê o documento e depoi reponde a pergunta do checklit; A pergunta do checklit ão freqüentemente limitada à detecção de defeito que pertencem a tipo epecífico de defeito. Como o tipo de defeito etão baeado em informação de defeito ocorrido em experiência paada (CHERNAK,1996), o verificadore podem não focalizar no tipo de defeito que não tenham ido anteriormente detectado, ocaionando perda de clae inteira de defeito. Para tratar da dificuldade upracitada, nete ubproceo, a lita de conferência (checklit) deve eguir o eguinte princípio: O comprimento da lita de conferência não deve exceder a uma página ou a trinta e cinco quetõe, ma e for neceário ultrapaar eta medida, então deignar verificadore reponávei por diferente parte da lita; A pergunta da lita de conferência devem er frae tão precia quanto poívei; A lita de conferência deve er etruturada de forma que o requiito de qualidade eteja claro para o verificador e a pergunta forneça ugetõe de como aegurar o requiito de qualidade; A lita de conferência deve er utilizada em artefato que o Comitê de Qualidade tenha conhecimento adequado e experiência uficiente para realização da lita de pergunta de forma a abranger maior número de clae de defeito. Durante o proceo de preenchimento da lita de conferência (checklit), o verificador, embaado pela técnica de Leitura baeada em Perpectiva, deve aumir uma perpectiva epecífica com o objetivo de inpecionar e validar o artefato. O checklit deve er formado por um conjunto de apecto e cada um dete apecto deve er compoto por um conjunto de quetõe que devem obter o maior número poível de repota adequada para aegurar o objetivo propoto de cada apecto. Para obter ee conjunto de apecto, deve er coniderado o tipo de produto a er verificado e a neceidade de e obter um artefato adequado ao objeto de trabalho. 67

69 A dua atividade do Subproceo de Verificação ão detalhada a eguir. SPV-A1 PLANEJAMENTO Na atividade Planejamento, a partir do Plano de Gerência de Projeto, o Conultor de Qualidade alocado ao projeto deve definir um Plano de Verificação conforme o PGQSP, uando um modelo e cronograma adequado ao projeto de deenvolvimento do oftware, cuja verificação deve er realizada pelo Grupo de GQS do Órgão Decentralizado de Fornecimento de Software contratado. A eqüência de tarefa da atividade Planejamento conite em: SPV-A1-1 - Analiar a neceidade e caracterítica deejada do projeto em função do recuro e rico aociado que podem cauar a não atingir o objetivo; SPV-A1-2 - Etabelecer checklit para verificar o artefato baeado em apecto e elecionar reponávei qualificado para realização da verificaçõe. Para cada apecto, um ou mai objetivo ão definido, e um conjunto de pergunta que o verificador deve reponder é etabelecido dentro do contexto do objetivo. Para ete checklit devem er reutilizado modelo aplicávei, e exitirem; SPV-A1-3 - Determinar o recuro, reponávei e cronograma para a verificaçõe do eguinte artefato: Neceidade do Cliente e Gloário (Proceo de Aquiição) para aegurar padronização da documentação, qualidade, completude, ratreabilidade e corretude da neceidade e caracterítica deejada do projeto pelo cliente; Arquitetura (Engenharia de Domínio) para garantir corretude, ratreabilidade, clareza e padrõe de etrutura; códigofonte (Proceo de Deenvolvimento) para garantir codificação adequada ao padrõe e requiito etabelecido no Contrato; e Cao de Tete de Componente e de Sitema para aegurar a padronização da documentação, completude, corretude, ratreabilidade e qualidade do produto final. SPV-A2 VERIFICAÇÃO Na atividade Verificação, a partir da prontificação do artefato/aet pela equipe de deenvolvimento/ engenheiro de domínio, o verificador alocado à verificação do artefato/aet, conforme o cronograma e PGQS, deve realizar uma análie prévia do artefato/aet. Apó a análie, o verificador, embaado pela técnica de Leitura baeada em 68

70 Perpectiva, deve aplicar a lita de conferência (checklit) adequada ao artefato/aet definida na atividade anterior para detecção de não-conformidade. Eta atividade termina com a produção do Relatório de Verificação e o envio dete ao Conultor de Qualidade alocado ao projeto. Toda a não-conformidade detectada no Relatório de Verificação devem er corrigida pelo reponável pela elaboração do artefato verificado e ua correçõe verificada pelo verificador de qualidade reponável. A não-conformidade reolvida e aprovada devem contar no Relatório de Verificação. E, durante a realização da verificação, o problema detectado que fogem ao ecopo do reponável pela elaboração do artefato devem er litado no Relatório de Verificação, aim como a açõe decorrente. O reultado da atividade de verificação devem er diponibilizado para a equipe de deenvolvimento/montadore, engenheiro de domínio, cliente e gerente de projeto SUBPROCESSO DE REVISÃO SPR O Subproceo de Revião tem o propóito de etabelecer a atividade voltada para o Controle da Qualidade que devem er aplicada à medida que um conjunto de artefato de epecificação de requiito e de projeto de arquitetura é produzido na Engenharia de Domínio para avaliar tecnicamente o artefato da atividade de Análie e Projeto de Domínio propoto em (GURGEL, 2004). A atividade dete ubproceo devem implementar reuniõe conjunta com inpeçõe individuai baeada na Técnica de Leitura Horizontal e Vertical. O artefato inpecionado ão: Modelo de Contexto do Domínio, Modelo Conceitual do Domínio, Modelo de Cao de Uo do Domínio e Decrição do Cenário, Modelo de Caracterítica, Modelo de Negócio, Interface da Camada de Negócio, Interface da Camada de Aplicação, Diagrama de Interaçõe, Arquitetura de Domínio e Epecificação de Componente do Domínio. Ete ubproceo abrange quatro atividade, que ão apreentada no diagrama da FIG : Planejamento (SPR-A1), Treinamento para Revião Técnica (SPR-A2), Preparação para Revião Técnica (SPR-A3) e Revião Técnica (SPR-A4). 69

71 Manual da Qualidade Plano de Gerência de Projeto Modelo Modelo PGQSP TLH e TLV Planejamento SPR-A1 Plano de Rev ião Cronograma Técnica de Leitura SPR - SUBPROCESSO REVISÃO Modelo Relatório Não- Conf ormidade da Rev ião Conultor de Qualidade artef ato Treinamento para Rev ião Técnica SPR-A2 Conultor de Qualidade Grupo Rev ior Preparação para Rev ião Técnica SPR-A3 Conultor de Qualidade Grupo Rev ior Relatório de Não- Conf ormidade da Rev ião Modelo Relatório Rev ião Rev ião Técnica SPR-A4 Relatório de Rev ião Líder Grupo Rev ior Grupo Autor Expoitor Secretário FIG : Diagrama de Contrução do Subproceo de Revião (SPR). Ete ubproceo inicia o Planejamento da Revião (SPR-A1) quando do recebimento da Manual da Qualidade pelo Comitê de Qualidade para obtenção do requiito e objetivo do projeto, com o propóito de produzir um plano de revião (PGQSP da Revião), cronograma da atividade de revião e elaboração do procedimento da Técnica de Leitura Vertical (TLV) e Horizontal (TLH) adequado ao artefato a erem inpecionado. O Plano de Gerência do Projeto, também, deve er aderente a ete plano e cronograma de revião. É importante realtar que todo o produto de qualidade gerado nete ubproceo devem er incorporado no Manual da Qualidade. Portanto, o Gerente de Projeto, deve obter o dado do plano de revião e cronograma da revião para o Plano de Gerência do Projeto via Manual da Qualidade. O Conultor de Qualidade alocado ao projeto deve definir o integrante que vão participar da atividade eguinte ao Planejamento (SPR-A1), ou eja, deve etabelecer o eguinte papéi (WIEGERS, 1995) para cada conjunto de artefato a er reviado: Grupo autor: grupo formado por autore do artefato a erem examinado; 70

72 Grupo revior: grupo formado por peoa do Órgão Decentralizado de Fornecimento de Software contratado, e opcionalmente pelo() cliente() ou repreentante() legal(i), que tenham conhecimento e qualificação inerente ao artefato, ma que não atuaram na elaboração do artefato; Um ecretário: um membro do grupo autor do artefato que deve realizar a ata da reunião; Um líder: um conultor de qualidade alocado ao projeto; Um expoitor: um membro do grupo revior que expõe o problema. A atividade de Treinamento (SPR-A2) inicia ao receber um conjunto de artefato que foi produzido para uma determinada verão conforme cronograma do projeto definido no Plano de Gerência do Projeto. Na TAB é epecificado cada conjunto de artefato que deve er enviado ao expoitor e quando do envio pelo Gerente do Projeto. TAB : Conjunto de artefato para revião. Conjunto de Artefato 1 Modelo de Contexto Modelo Conceitual Modelo de Cao de Uo e Cenário Modelo de Caracterítica 2 Modelo de Tipo de Negócio Interface da Camada de Negócio e Tipo de Dado Interface da Camada de Aplicação Arquitetura de Domínio Diagrama de Interaçõe 3 Epecificação de Componente de Domínio Interface do Componente de Domínio Quando Término da atividade Análie do Domínio do Proceo ao Longo do Projeto. Durante a atividade Projeto de Domínio do Proceo ao Longo do Projeto. Término da atividade Projeto de Domínio do Proceo ao Longo do Projeto. Apó um dia útil do recebimento, o expoitor alocado ao conjunto de artefato a er reviado deve treinar o grupo revior. Em eguida, ete grupo juntamente com o grupo autor devem-e preparar para revião técnica, conforme a repectiva atividade SPR-A2 e SPR- A3 epecificada mai adiante. Durante eta preparação, é aplicada a Técnica de Leitura Vertical (TLV) e Horizontal (TLH) para inpecionar o artefato conforme ão apreentado na FIG A inpeção de cada artefato não deve ultrapaar mai de uma hora. A reunião da revião deve er realizada no dia eguinte da execução da inpeçõe do conjunto de artefato recebido para er reviado. Eta reunião não deve demorar mai do que dua hora. A equipe de revião deve er compota pelo grupo revior, grupo autor, um líder, um ecretário e um expoitor, conforme etabelecido na atividade de Planejamento (SPR-A1). 71

73 De cri çã o d a Nece i da d e d o Cli e nte + G l oá ri o A náli e de Domínio TLV1 TLV2 M od e lo d e Con texto do Dom ínio (baeado m étodo F OR M) M od e lo Con ceitu al do Dom ínio (D iagram a de C la e) TLH 1 TLH 2 M od e lo d e Cao d e Uo d o Dom ín i o + Cen á rio (D iagram a de C a o de U o + D e c riç ão do C enário ) M od e l o d e Ca ra cte ríti ca (baeado m étodo F OR M) Projeto de Domínio : E pec if icação da A rquitetura de Domínio TLV3 TLV4 TLV5 M od elo T i p o do Negócio (D iagram a de C la e) Interface da Ca m a da d e Ne gó ci o (D iagram a de C la e) Interface da Ca m a d a d e A p l i caçã o (D iagram a de C la e) Di ag ram a d e In te raçõ e (D iagram a de Seqüênc ia/ C olaboração) A rq uitetu ra d e Dom ínio (D iagram a de C la e) TLH 3 TLH 4 TLH 5 Projeto de Domínio : E pec if icação do Componente de Domínio TLV6 Epecificação de Com ponente do Dom ínio (D iagram a de C la e) FIG : Conjunto da Técnica de Leitura Horizontal e Vertical. Cada inpeção deve empregar a Técnica de Leitura Vertical (TLV) e Horizontal (TLH) baeada em (TRAVASSOS et al., 2003). E, cada revior deve direcionar ua leitura por um cenário epecífico ao invé de uma leitura paiva. O cenário é um procedimento que o revior deve eguir durante a inpeção, conitindo de atividade repetívei que um revior precia executar e de verificaçõe que um revior deve certificar. Deta forma, eta técnica de leitura procura abranger a mai divera clae de defeito. O reultado deta reunião deve er uma lita de não-conformidade, a quai devem er numerada eqüencialmente e anotada no Relatório de Revião pelo ecretário. Nete relatório também deve conter o nome do reviore, data da reunião, material avaliado e açõe decorrente. Ea reviõe devem er realizada no marco do Plano de Gerência do Projeto de acordo com o término da atividade de elaboração do documento acima decrito do Proceo ao Longo do Projeto para avaliação do artefato produzido, de forma a garantir ao uuário (interno e externo) dete artefato uma utilização de produto pelo 72

74 meno com a qualidade mínima epecificada. Eta revião é de reponabilidade do Gerente de Projeto, Engenheiro de Domínio, Conultor da Qualidade e Cliente. Em geral, a reuniõe podem gerar conflito humano, portanto é fundamental que alguma abordagen para melhoria dete confronto ejam tratada (TAVARES, 2002) ante da reunião, principalmente na atividade Treinamento para Revião Técnica (decrita mai adiante), tai como: O grupo revior e grupo autor do artefato devem entender que o objeto da revião é um artefato, etático naquele ponto, e não eu autore; A peoa envolvida em uma revião devem exercer outro papéi na reviõe de outro artefato, havendo um rodízio de papéi, agindo ora como reviore ora como autore ora como moderadore; O grupo autor e revior devem entender que crítica reincidente a algun apecto do artefato examinado não ignifica crítica reincidente ao grupo autor do artefato em inpeção. A quatro atividade do Subproceo de Revião ão detalhada a abaixo. SPR-A1 PLANEJAMENTO O Conultor de Qualidade deve criar e documentar um Plano de Revião para a fae de Análie e Projeto do Domínio da Engenharia de Domínio do Proceo ao Longo do Projeto conforme o PGQSP, uando um modelo e cronograma adequado ao projeto de deenvolvimento do oftware, para definir para cada atividade o recuro, cronograma e procedimento para gerenciar a reviõe do artefato. A eqüência de tarefa da atividade Planejamento conite em: SPR-A1-1 - Agendar a reuniõe da reviõe periódica no marco etabelecido no Plano de Gerência do Projeto conforme o término da atividade Análie de Domínio, Epecificação da Arquitetura de Domínio durante a atividade Projeto de Domínio e Epecificação de Componente do Domínio para avaliação do artefato produzido; SPR-A1-2 - Etabelecer a técnica de leitura para reviõe individuai do artefato que vão compor o aet da Engenharia de Domínio. Para cada técnica de leitura horizontal e vertical, um procedimento é etabelecido para verificação e certificação de um conjunto de informação dentro do contexto do objetivo do tipo da técnica. Para eta técnica devem er reutilizado modelo aplicávei, e exitirem; 73

75 SPR-A1-3 - Selecionar o membro que vão compor a reunião da revião relativa ao artefato a er examinado. Além dio, deve definir local, intalaçõe, hardware, oftware e ferramenta neceário para realização da reviõe acordado pelo grupo (revior e autor); SPR-A1-4 - Para cada revião, acordado pelo grupo revior e autor, agendar a atividade pertinente (treinamento, preparação e revião técnica e de getão). SPR-A2 TREINAMENTO PARA REVISÃO TÉCNICA A atividade Treinamento para Revião Técnica deve er realizada pelo Conultor de Qualidade. Eta atividade conite em capacitar o reviore a inpecionar o conjunto de artefato de acordo com a TLV e TLH. A duração deta atividade não deve ultrapaar à uma hora. Eta atividade é opcional, poi cao o grupo de revior já tenha experiência com ete tipo de revião técnica e não neceite de intruçõe. A eqüência de tarefa deta atividade conite em: SPR-A2-1 - Treinar o grupo revior em que revião de artefato ele vão examinar; SPR-A2-2 - Aociar técnica de leitura horizontal e vertical ao reviore; SPR-A2-3 - Fornecer impreão do documento relativo ao artefato a er examinado para cada revior, que deverá dipor de uma hora para leitura do documento. No cao da não realização deta atividade, a tarefa SPR-A2-2 e SPR-A2-3 devem er executada pela atividade eguinte, ou eja, SPR-A3. SPR-A3 PREPARAÇÃO PARA REVISÃO TÉCNICA A atividade Preparação para Revião Técnica deve er realizada pelo Conultor de Qualidade. Eta atividade conite em preparar o reviore obre o conjunto de artefato a er inpecionado, e a duração deta atividade não deve ultrapaar a dua hora. A eqüência de tarefa da atividade Preparação para Revião Técnica conite em: SPR-A3-1 - O reviore devem aprender obre o artefato a erem examinado e prepararem-e para deempenhar a leitura individualmente, verificando para o tipo de leitura o recuro neceário para execução do procedimento da leitura; SPR-A3-2 - Uma vez que todo o reviore etão preparado, o grupo revior procura não-conformidade, utilizando a Técnica de Leitura Vertical (TLV) e Horizontal (TLH) adequada ao artefato em revião. Em cada leitura, o revior deve procurar evidência de que o 74

76 artefato eteja completo, aderente ao padrõe e epecificaçõe relacionado, como também o artefato eteja implementado adequadamente. A inpeção de cada artefato não deve ultrapaar mai de uma hora; SPR-A3-3 - Cada revior documenta o reultado da revião no Relatório de Não- Conformidade da Revião. SPR-A4 REVISÃO TÉCNICA A atividade Revião Técnica conite na realização da reunião da revião do conjunto de artefato inpecionado individualmente na atividade Preparação para Revião Técnica (SPR- A3). Eta atividade deve er realizada pelo integrante etabelecido na atividade Planejamento (SPR-A1), ou eja, um líder, um grupo de reviore, um grupo de autore do conjunto de artefato inpecionado, um ecretário e um expoitor. O líder deve er o Conultor de Qualidade alocado ao projeto. A duração da reunião não deve ultrapaar a dua hora. A eqüência de tarefa da atividade Revião Técnica conite em: SPR-A4-1 - A reunião e inicia pelo expoitor apreentando o documento a er examinado, e em eguida pela expoição do nível de adeqüabilidade e, e exitir, da nãoconformidade encontrada por cada revior. Durante o debate do grupo revior e autor, pode haver intervençõe do líder como mediador; SPR-A4-2 - Durante toda a reunião o ecretário preenche o Relatório de Revião com o nome do membro da reunião, data-hora, local, recuro utilizado, como também, regitra o problema detectado e a açõe decorrente, inclui o reultado da revião (a nãoconformidade detectada pelo revior atravé da leitura individual) e regitra o nível de adeqüabilidade (aprovado, deaprovado ou aprovado com pendência); SPR-A4-3 - Da não-conformidade detectada, o grupo autor pode apreentar jutificativa do motivo que levam a algun dele não repreentarem problema reai. Eta jutificativa deve contar no Relatório de Revião; SPR-A4-4 - O problema detectado que fogem ao ecopo do reponável pela elaboração do artefato devem er litado no Relatório de Revião, aim como a açõe decorrente. 75

77 O grupo autor deve corrigir a não-conformidade decrita no Relatório da Revião, e o Gerente do Projeto deve atualizar o Plano de Gerência do Projeto conforme o reultado da revião. O Conultor de Qualidade deve acompanhar a correçõe apontada no Relatório de Revião e etão endo realizada eficazmente, e conforme a data etabelecida no Relatório de Revião realizar nova revião, e neceário, para verificar a correçõe e e defeito ecundário não foram introduzido. A não-conformidade reolvida e aprovada devem contar no Relatório de Revião. E, o reultado da atividade de revião devem er diponibilizado para a equipe de deenvolvimento/montadore, engenheiro de domínio, cliente e gerente de projeto SUBPROCESSO DE MEDIÇÃO E AVALIAÇÃO SPM O Proceo de Medição e Avaliação tem o propóito de definir procedimento para medir e julgar, além do nível de reuabilidade, a qualidade do produto ou artefato quanto ao requiito e atifação do cliente. Ete ubproceo abrange cinco atividade, que ão apreentado no diagrama da FIG (ALMEIDA et al., 2003): Análie de Requiito, Epecificação da Avaliação, Planejamento da Avaliação, Execução da Medição e Avaliação. ISO :2000 Critério de reuabilidade SPR - SUBPROCESSO MEDIÇÃO E AVALIAÇÃO Neceidade explícita e implícita Manual da Qualidade Análie de Requiito SPM-A1 objetiv o da av aliação Conultor da Qualidade Gerente do Projeto requiito gerenciai Epecif icação da Av aliação SPM-A2 Modelo PGQSP Métrica Pontuação Critério de av aliação Conultor da Qualidade Ecopo da av aliação, reponabilidade Planejamento da Av aliação SPM-A3 Plano de Medição e Av aliação Cronograma Modelo Relatório Medição e Av aliação Diagrama de Caua- Ef eito Conultor da Qualidade artef ato relatório Execução da Medição SPM-A4 Av aliação com nív el de pontuação Av aliação SPM-A5 Relatório da Medição e Av aliação Grupo de Métrica Grupo de Métrica FIG : Diagrama de Contrução do Subproceo de Medição e Avaliação (SPM). 76

78 Ete ubproceo inicia a Análie de Requiito (SPM-A1) quando do recebimento do Manual da Qualidade pelo Comitê de Qualidade para obtenção do requiito e objetivo do projeto, com o propóito de definir o objetivo da avaliação da medição. Baeado nete manual, o Conultor da Qualidade alocado ao projeto e o Gerente do Projeto devem definir o requiito de qualidade e reuabilidade de acordo com a neceidade explícita ou implícita do projeto. O objetivo da avaliação devem atender a Norma ISO :2000 e o critério de qualidade requerido pelo Contrato. A partir do objetivo etabelecido na atividade SPM-A1, o Conultor da Qualidade alocado ao projeto deve elecionar métrica, definir nível de pontuação e critério de avaliação. A cada nova verão do projeto, conforme o Plano de Gerência do Projeto, o Conultor de Qualidade alocado ao projeto deve enviar todo o relatório de Verificação e Revião realizado no período da verão anterior correpondente para o Grupo de Métrica. Ete grupo deve medir e analiar o dado coletado dete relatório e do artefato produzido, e deve enviar um Relatório de Medição e Avaliação, juntamente com todo o Relatório de Verificaçõe e Reviõe, ao Gerente de Reuo e do Projeto uma emana apó da prontificação da verão. É importante realtar que todo o produto de qualidade gerado nete ubproceo devem er incorporado no Manual da Qualidade. Portanto, o Gerente de Projeto, deve obter o dado do plano de medição e avaliação e cronograma da revião para o Plano de Gerência do Projeto via Manual da Qualidade. Nete proceo, deve er adotada a abordagem GQM (Goal/Quetion/Metric) de (BASILI et al., 1994) para definir um proceo de coleta e análie de dado. Primeiro, deve-e etabelecer uma referência para avaliar o progreo em termo do objetivo e atravé de comparação com eta referência. Aim, apó a cada nova referência no repoitório da biblioteca, deve er avaliada a qualidade e a reuabilidade do produto pelo Grupo de Métrica. O Grupo de Métrica deve er formado por epecialita em etatítica que pertençam ao Órgão Decentralizado de Fornecimento de Software para fornecer uporte na análie do dado conolidado. O regitro de informaçõe (data, hora, uuário requerente, reviore) de entrada e aída do artefato no repoitório da biblioteca e a bae de dado onde ão armazenada informaçõe hitórica e verõe do artefato vão ervir de informação de entrada para o Proceo de Medição e Avaliação, além do Relatório de Tete, Verificação e Revião. 77

79 Eta informaçõe de entrada podem er utilizada para obtenção do tamanho do artefato, quantidade de reuo de aet por domínio, o número de alteraçõe em um projeto, quantidade de defeito detectado, economia de tempo e benefício derivado do reuo de aet. O Gerente do Projeto deve incluir requiito de reuabilidade para aet na epecificaçõe de atributo de qualidade para aegurar a qualidade do aet elecionado para reuo no deenvolvimento do produto. O critério para avaliar a qualidade de reuabilidade ão a confiança obtida com a experiência de aet reuado em projeto emelhante, o defeito detectado como reultado de inpeção do aet e o reultado do tete do componente diante o requiito do componente e do itema (IEEE1517, 1999). O dado coletado e armazenado durante a verificaçõe, tete e reviõe devem promover o acompanhamento da qualidade e da reuabilidade na produção de aet, como também a troca de experiência entre a equipe de deenvolvimento e engenheiro de domínio. O Grupo de Métrica deve fornecer o reultado da análie ao Comitê de Qualidade para divulgação do reultado à gerência do Órgão Decentralizado de Fornecimento de Software e ao Grupo de GQS Corporativo. Ete último deve analiar o ponto forte e fraco do proceo empregado. Eta avaliaçõe devem er utilizada para recomendar alteraçõe na diretrize do futuro projeto e para determinar avanço tecnológico. A cinco atividade do Subproceo de Medição e Avaliação ão detalhada a abaixo. SPM-A1 ANÁLISE DE REQUISITOS A atividade Análie de Requiito deve decrever a epecificaçõe do requiito de qualidade e reuabilidade, definindo o objetivo da avaliação de acordo do ponto de vita do diferente uuário do produto. O requiito a erem avaliado devem etar em conformidade com a norma ISO :2000 e devem atender a neceidade explícita e implícita do uuário. SPM-A2 ESPECIFICAÇÃO DA AVALIAÇÃO A atividade Epecificação da Avaliação etabelece o ecopo da avaliação, a mediçõe a erem realizada no produto / artefato, a definição do nível de pontuação e do critério de avaliação, o método utilizado e a reponabilidade de todo envolvido no proceo de 78

80 avaliação. Eta atividade deve procurar elecionar o objetivo que facilmente podem prover medida mai do tipo hard (meno ubjetiva e mai objetiva) e que melhor atendem à neceidade de verificação. Baeado no modelo de (BASILI et al., 2000) devem er identificado e definido objetivo, quetõe e métrica (Goal/Quetion/Metric) para proceo (por exemplo, tempo de análie, tempo de codificação, tempo de tete) e para produto / artefato (por exemplo, linha de código, número de aet reuávei) de maneira objetiva. SPM-A3 PLANEJAMENTO DA AVALIAÇÃO O Conultor de Qualidade deve criar e documentar um Plano para a Medição e Avaliação da qualidade e reuabilidade adequado ao projeto de deenvolvimento com toda a atividade de implantação e adminitração do proceo, reuando um modelo aplicável de plano de adminitração de medição e avaliação, e exitir, para definir o recuro, cronograma, o procedimento e a metodologia para gerenciar e implementar a medição e avaliação de produto / artefato. O Plano de Medição e Avaliação deve incluir o eguinte apecto: Recuro, cronograma, reponabilidade e procedimento para realização da medição e análie do proceo e produto; Prover infra-etrutura (método, ferramenta, prática, recuro humano, treinamento) para aegurar a execução do proceo. SPM-A4 EXECUÇÃO DA MEDIÇÃO O Grupo de Métrica deve medir o produto / artefato mediante a métrica elecionada na atividade Epecificação da Avaliação (SPM-A2) e o recuro e a metodologia etabelecido conforme o Plano de Medição e Avaliação. O dado obtido da medição devem er coletado e armazenado. O Grupo de Métrica, diante do reultado coletado, deve regitrar no Relatório da Avaliação o nível de pontuação referente a cada métrica de acordo com a pontuação etabelecida na atividade Epecificação da Avaliação (SPM-A2). Além dio, o grupo deve verificar o produto / artefato e etá em conformidade com o requiito, a epecificação e o Plano de Medição e Avaliação. Finalmente, deve gerar o Relatório da 79

81 Avaliação, que deverá er divulgado dentro da organização e, também, para o Grupo de GQS Corporativo. A eqüência de tarefa da atividade Execução da Medição conite em: Coletar dado que medem a métrica identificada na atividade Epecificação da Avaliação; Armazenar o dado; Analiar o dado para fornecer o nível de pontuação; Verificar o produto / artefato etá de acordo com o requiito, epecificaçõe e Planejamento da Avaliação; Pontuar a avaliação. SPM-A5 AVALIAÇÃO O Grupo de Métrica deve analiar o reultado para avaliar o deempenho, a etabilidade e capacidade do proceo, prever cuto e deempenho futuro, identificar tendência, identificar oportunidade de melhoria da qualidade e de reuabilidade do produto / artefato. Ete grupo deve produzir o Relatório de Medição e Avaliação, e diponibilizar o dado reultante da mema, incluive a anomalia do proceo encontrada. Para identificar a caua da anomalia do proceo, o Grupo de Métrica pode utilizar o Diagrama de Caua- Efeito (PALMER, 1997). Uma vez diagnoticada a caua efetiva do problema detectado, ela devem er documentada no Relatório de Medição e Avaliação para que o Gerente de Reuo poa verificar e quantificar a viabilidade da mudança do proceo PROCESSO DE APROVAÇÃO DE ASSETS O Proceo de Aprovação de Aet conite na aprovação do tipo e da documentação do aet para que ete poam er poteriormente claificado e armazenado no repoitório da biblioteca pelo Proceo de Gerência de Aet do Proceo de Deenvolvimento de Software baeado em Reuo na MD de (GURGEL, 2004). A documentação do aet deve propiciar o completo entendimento ao reutilizadore do aet de forma concia e clara. Ete proceo inicia quando do recebimento, apó a cada verão definida do projeto no Plano de Gerência do Projeto, de todo o artefato que compõe o aet com qualidade 80

82 aprovada pelo Proceo de Controle de Qualidade e a documentação do aet (veja FIG ). De poe do aet e de ua documentação, o Comitê de Qualidade deve identificar o tipo de aet de acordo com a TAB e epecificar o requiito do aet para o Subproceo de Verificação (SPV) do Proceo de Controle de Qualidade (PCQ) validar via checklit caracterítica de reuabilidade, compatibilidade, padronização da documentação, ratreabilidade, corretude, facilidade no entendimento da funcionalidade e objetivo do aet. A partir da qualidade aprovada do aet pelo Relatório de Verificação, o Comitê de Qualidade deve enviar o aet aprovado ao Proceo de Gerência de Aet para catalogação, notificação e getão do aet no repoitório de aet reutilizávei e um Relatório de Aprovação do aet ao Grupo de GQS Corporativo e ao Gerente de Reuo. Subproceo de Verif icação Grupo de GQS Proceo de Engenharia de Domínio Engenheiro de Domínio Proceo de Deenv olv imento Deenv olv edore /montadore Epecif icação de Requiito do Aet Relatório de Verif icação do Aet aet + documentação + conjunto de artef ato com qualidade aprov ada aet + documentação + conjunto de artef ato com qualidade aprov ada Proceo de Aprov ação de Aet (PAA) Comitê de Qualidade Aet aprov ado Relatório de Aprov ação de Aet Proceo de Gerência de Aet Gerente de Reúo Grupo de GQS Corporativ o Gerente de Reúo FIG : Proceo de Aprovação de Aet (PAA). Na FIG ão apreentada a interaçõe do Proceo de Aprovação de Aet (PAA) com o proceo de (GURGEL, 2004) e de Controle da Qualidade (PCQ), apreentando o artefato de entrada/aída com eu repectivo papéi e o reponávei pelo PAA. E, na TAB ão apreentado o aet que devem er gerado pelo órgão contratado para fornecimento do oftware com o artefato que o compõe fruto de uma atividade epecífica de um proceo definido de (GURGEL, 2004). Para o aet er aprovado, ele deve atender a um critério de aprovação inerente ao artefato gerado que o compõe. Além dio, a documentação deve er legível, identificável e completa, e também protegida, de acordo com o grau de egurança da informação contida no aet conforme epecificado no Contrato (IEEE1517, 1999). 81

83 TAB : Tipo de aet produzido pelo Proceo de Deenvolvimento de Software baeado em Reuo na MD. Aet Artefato Atividade Proceo Domínio Modelo de Contexto Modelo Conceitual Modelo de Cao de Uo do Domínio e Cenário Modelo de Caracterítica Ontologia Taxonomia Linguagen de Domínio Análie de Domínio Engenharia de Domínio Arquitetura de Domínio Modelo Tipo de Negócio Interface da Camada de Negócio e Tipo de Dado Interface da Camada de Aplicação Arquitetura de Domínio Projeto de Domínio Engenharia de Domínio Componente de Domínio Epecificação de Componente de Domínio Interface de Componente de Domínio Projeto de Domínio Engenharia de Domínio Componente Código de Componente Tete de Componente Contrução do Software Proceo de Deenvolvimento O verificadore devem aplicar a técnica de leitura baeada em perpectiva que poibilita a verificação do aet ob a perpectiva de diferente reutilizadore. Para cada perpectiva, tanto um como vário cenário devem er definido, conitindo de atividade repetívei que um verificador deve executar, e de pergunta que um verificador deve reponder. Para ea verificaçõe devem er reutilizado modelo aplicávei, e exitirem. A documentação de cada aet deve conter a eguinte caracterítica apontada por (BRAUN, 1994; KARLSSON, 1995; KRUEGER, 1992; MEYER, 1994): Geral: contém informação geral obre o aet e a partir deta informação deve er poível decidir e o aet é candidato para um certo cenário. Entretanto, eta documentação não pode er muito detalhada para evitar que o proceo de eleção de candidato eja demorado. Porém, ete proceo de eleção pode requerer buca de mai informação que deve etar documentada em alguma da caracterítica apreentada a eguir; De Reutilização: contém toda a informaçõe neceária de intalação, uo e adaptação do aet; Adminitrativa: contém informaçõe adminitrativa como retriçõe legai e uporte diponível; De Avaliação: contém informaçõe mai detalhe para a avaliação de um aet como problema conhecido, retriçõe e declaraçõe de qualidade. É importante realtar que para 82

84 aumentar o ganho em reuo, o aet deve ter o menor número de retriçõe técnica poívei e a maior abrangência quanto eu ecopo; Complementar: deve conter qualquer detalhe a mai que não foi uprido pela primeira quatro caracterítica. Segundo Sametinger, a documentação de um aet deve conter o eguinte iten de acordo com a cinco caracterítica acima decrita (SAMETINGER, 1996): 1 - Caracterítica Gerai: Nome do aet: nome, dando uma poível ugetão obre a funcionalidade do aet; Identificação: declaração inicial concia e clara obre a funcionalidade do aet para eleção inicial, e incluive com decrição geral de toda a operaçõe externamente viívei, e for um componente; Epecificação: funcionalidade do aet que deve er detalhada; Claificação: claificação do aet como uma lita de palavra chave para habilitar recuperação futura, por exemplo, e aet for um componente, indicar o tipo (clae de C++, funçõe de C, aplicação de OpenDoc). 2 - Caracterítica de Reutilização Uabilidade: decrição de como o aet pode er utilizado corretamente; Intalação: decrição de como adaptar o aet em uma nova aplicação; Adaptação: decrição de como e para que neceidade epecífica pode er adaptado o aet; Implementação: decrição de como o aet etá implementado; Suporte: onde adquirir ajuda, e neceário for, por exemplo, ao adaptar o componente ou o que fazer e um problema ocorrer. 3 - Caracterítica Adminitrativa Hitórico: hitórico de verõe, data de liberaçõe, deenvolvedore reponávei, principai diferença entre a verõe; Retriçõe comerciai e legai: retriçõe comerciai ou legai no uo do componente, por exemplo, aquiição, licença epecial ou permião requerida. 4 - Caracterítica de Avaliação Retriçõe técnica: retriçõe técnica no uo do aet, por exemplo, capacidade, linguagem de programação, dependência de itema operacional; 83

85 Qualidade: indicar a ituação do aet, quanto à qualidade, reviõe, verificaçõe e cao de tete aplicado, incluive o reultado obtido; Performance: recuro do itema neceário para uar o aet, por exemplo, memória, proceador, canai de comunicação; Alternativa: relação de aet emelhante que poderiam er uado no lugar dete; Problema: relato de problema conhecido e cuto requerido; Interdependência: o aet pode er uado tand-alone ou deve er uado junto a outro aet; Cuto recomendado: cuto conhecido para melhorar performance, tornar o aet mai robuto e / ou etender o ecopo de reuo. 5 - Caracterítica Complementare Indexação: provê um índice para aet complexo que requerem documentação extena; Referência: referência para literatura ou outra documentação, por exemplo, documentação de itema. Ete proceo abrange dua atividade, que ão apreentada no diagrama da FIG : Identificação e Avaliação. Critério de Aprov ação PAA - PROCESSO APROVAÇÃO DE ASSETS conjunto de artef ato que compõe o aet com qualidade aprov ada + documentação do aet Identif icação PAA-A1 Epecif icaçõe de requiito do aet Comitê de Qualidade Relatório Verif icação Av aliação PAA-A2 Relatório Aprov ação do Aet Comitê de Qualidade FIG : Diagrama de Contrução do Proceo de Aprovação de Aet (PAA). A dua atividade do Proceo de Aprovação de Aet ão detalhada a abaixo. 84

86 PAA-A1 IDENTIFICAÇÃO A partir do recebimento do aet juntamente com eu repectivo artefato com qualidade aprovada que o compõe, o Comitê de Qualidade deve identificar e epecificar o requiito do aet ubmetido para aprovação, reuando um modelo aplicável de epecificação de requiito para aprovação de aet, e exitir, egundo Critério de Aprovação de aet. Ea epecificaçõe de requiito para aprovação de aet devem er fornecida ao Subproceo de Verificação do Proceo de Controle de Qualidade para que o verificadore poam validar via checklit apecto de reuabilidade e de compatibilidade, dentre outro apecto como padronização da documentação, ratreabilidade, corretude e facilidade no entendimento da funcionalidade e objetivo do aet. Para aprovação de aet, o requiito de aprovação devem er definido, obedecendo, conforme o tipo do aet, ao eguinte Critério de Aprovação: 1 - Utilidade e reuabilidade do requiito de domínio do componente; 2 - Utilidade e reuabilidade da arquitetura de domínio do aet; 3 - Grande potencial de reuo do requiito para erem uado em vário domínio; 4 - Grande potencial de reuo da arquitetura de domínio do aet ou parte dela para er uada em vário domínio; 5 - Compatibilidade da arquitetura de domínio do aet com o modelo de domínio e componente de domínio; 6 - Conformidade com o padrõe de reuo da organização etabelecido no Programa de Reuo 19 (IEEE1517, 1999). A eqüência de tarefa da atividade Planejamento conite em: PAA-A1-1 - Identificar o tipo de aet em função do artefato com qualidade aprovada pelo Proceo de Controle de Qualidade conforme epecificado na TAB e regitrar pedido de avaliação do aet; PAA-A1-2 - Identificar e epecificar o requiito para avaliação do aet, egundo Critério de Aprovação de aet upracitado; PAA-A1-3 - Enviar a epecificaçõe de requiito para avaliação do aet ao Subproceo de Verificação do Proceo de Controle de Qualidade para etabelecer uma lita de conferência para avaliar o aet baeado na perpectiva do reutilizadore e elecionar reponávei qualificado para realização da verificaçõe. Na perpectiva do reutilizadore, 19 Formalização de como o reuo deve er implantado na organização. 85

87 o apecto de reuabilidade e compatibilidade devem er etabelecido com eu objetivo definido e conjunto de pergunta. Eta pergunta, que o verificador deve reponder, devem atender ao objetivo do apecto referente. Para eta lita de conferência devem er reutilizado modelo aplicávei, e exitirem; PAA-A1-4 - Determinar o recuro, reponávei e cronograma para a verificaçõe do eguinte aet: Domínio, Arquitetura de Domínio, Componente de Domínio e Componente. Todo o aet, exceto Componente, ão produzido no Proceo de Engenharia de Domínio e o aet de Componente é gerado no Proceo de Deenvolvimento conforme apreentado na TAB A verificaçõe do aet ão para aegurar padronização da documentação, qualidade, reuabilidade, compatibilidade, completude, ratreabilidade, corretude e facilidade no entendimento do memo. Toda a não-conformidade detectada devem er corrigida pelo reponável pela elaboração do artefato verificado que compõe o aet e ua correçõe verificada pelo verificador reponável. Durante a atividade Verificação o problema detectado que fogem ao ecopo do reponável pela elaboração do artefato devem er litado no Relatório de Verificação, aim como a açõe decorrente. O reultado da verificação devem er diponibilizado para o Gerente de Reuo e ao órgão envolvido. PAA-A2 AVALIAÇÃO A partir da qualidade aprovada do aet pelo Relatório de Verificação correpondente, o Comitê de Qualidade deve etabelecer credencial de proteção de aceo ao aet conforme Contrato e liberar o aet e o Relatório de Aprovação do aet para o Proceo de Gerência de Aet catalogar, armazenar, divulgar e adminitrar o controle de aceo no repoitório de aet reutilizávei. 4 ESTUDO DE CASO Neta diertação, é utilizada a etratégia de um etudo de cao por er um método que conite na obervação de um projeto em andamento, que pode prover ubídio para verificar o pró e contra da implantação de um proceo epecífico em um determinado contexto (WOHLIN et al., 1999). 86

88 Jacobon et al. decrevem cao reai de organizaçõe como AT&T, HP e outra que entiram a neceidade de uma etratégia para implementação de um proceo de reuo (JACOBSON et al., 1997). Eta organizaçõe adotaram uma metodologia incremental: deenvolver a partir de um proceo gradativo, ou eja, a partir de um projeto piloto. Poi, eta etratégia poibilita aumento em experiência e uma migração cultural pao a pao, minimizando rico e reduzindo conflito ociai entre a equipe de deenvolvimento. Deta forma, uma experiência inicial de implantação da propota deta diertação foi realizada com o intuito de viabilizar o proceo de Garantia da Qualidade de Software para o proceo propoto em (GURGEL, 2004). Para tal, foi deenvolvido um projeto piloto - Controlador Tático - para poibilitar, na medida do poível, a avaliação do proceo de deenvolvimento baeado em reuo de (GURGEL, 2004) e o poívei ganho na qualidade e reuabilidade advindo da utilização da etratégia aqui propota. Baeado no guia para etudo de cao de Kitchenham et al., o etudo de cao apreentado nete capítulo egue a etapa de Planejamento, Monitoração e Avaliação (KITCHENHAM et al., 1995). O Planejamento conite na eguinte definiçõe para o etudo de cao: contexto, hipótee, condução, duração, participante e objetivo a erem atingido. Já a Monitoração é o acompanhamento da realização da atividade de cada proceo que compõe o proceo de Garantia da Qualidade de Software propoto. Além de uma breve informação obre o acompanhamento, é apreentado um quadro de monitoração contendo a técnica utilizada, o tempo dependido, o fatore de influência (condiçõe, facilidade, dificuldade e/ou limitaçõe encontrada), e análie do reultado obtido e do tempo. A última etapa, Avaliação, conite na análie e interpretação do reultado obtido na etapa anterior. 4.1 PLANEJAMENTO DO ESTUDO DE CASO DEFINIÇÃO DO CONTEXTO DO ESTUDO DE CASO O projeto piloto Controlador Tático - foi realizado baeado no projeto real TTI (Terminal Tático Inteligente) do IPqM (Intituto de Pequia da Marinha) para aplicação do proceo de deenvolvimento de oftware baeado em reuo de (GURGEL, 2004) e do proceo de Garantia da Qualidade de Software propoto neta diertação, com o objetivo de criar artefato reutilizávei no domínio de controle tático de plataforma e também de 87

89 aegurar a qualidade dete artefato de forma que ete poam er efetivamente reutilizávei pelo montadore Ete projeto piloto é adequado por er típico ao contexto da Trê Força Armada (Marinha, Exército e Aeronáutica) e também por er adequado ao reuo. A reuabilidade dete projeto é relatada em (GURGEL, 2004) devido à etabilidade do domínio e grande aplicabilidade na mai divera plataforma da Trê Força. Nó no apoiamo no produto de oftware de (BRAGA et al., 1999; CHEESMAN et al., 2000) para gerar o artefato do proceo de Engenharia de Domínio e Deenvolvimento do Controlador Tático, que ão o artefato de entrada para o proceo propoto por eta diertação. Ficou etabelecido que toda a fae do proceo de Engenharia de Domínio e de Deenvolvimento da propota de (GURGEL, 2004) eriam realizada de forma a definir primeiramente todo o modelo e diagrama do projeto piloto neceário por cada atividade e, poteriormente, realizaria o artefato de qualidade adequado a ete modelo e diagrama. Eta decião foi tomada por doi motivo: aproximação do término do tempo para o etudo de cao da diertação de (GURGEL, 2004) e mudança contante do artefato a erem produzido. Entretanto, paralelamente, foi etabelecendo a técnica de qualidade apropriada ao projeto piloto, Controlador Tático, deenvolvido ob o paradigma OO grande facilitador ao reuo HIPÓTESE DO ESTUDO DE CASO A hipótee do etudo de cao para eta diertação foi avaliar até que ponto o proceo de Garantia da Qualidade de Software e motrou adequado ao proceo de deenvolvimento baeado em reuo de aet de (GURGEL, 2004) no domínio de controle tático de plataforma de forma a garantir a qualidade do artefato produzido e prover uma referência para a reuabilidade. A avaliação dete proceo deve er verificada atravé de ua implantação ao projeto piloto para obter dado de referência para futuro projeto deenvolvido ob o proceo de (GURGEL, 2004). Ete dado devem ervir de bae para comparar a qualidade e reuabilidade do próximo projeto. Deta forma, o artefato de qualidade definido para o projeto piloto devem er analiado para e verificar a validação da hipótee. 88

90 4.1.3 CONDUÇÃO DO ESTUDO DE CASO O projeto piloto eguiu o proceo de Garantia de Qualidade de Software propoto no capítulo anterior, tendo como ubídio o artefato reuávei definido para o Etudo de Cao de (GURGEL, 2004). Cada ubproceo foi conduzido conforme a etapa Monitoração de (KITCHENHAM et al., 1995) apreentada na eção DURAÇÃO DO ESTUDO CASO Ficou etabelecido o prazo de 4 (quatro) mee para realização do etudo de cao, compreendendo de fevereiro a maio de A ditribuição do tempo e deu conforme apreentado na FIG Medição Planejamento para Medição Revião Planejamento para Revião Cronograma do Etudo de Cao Verificação Planejamento para Verificação Garantindo a Qualidade mee FIG : Cronograma do etudo de cao do protótipo Controlador Tático PARTICIPANTES DO ESTUDO CASO O projeto piloto teve apena um conultor de qualidade e uma equipe acadêmica com 8 (oito) participante para realização da técnica de qualidade. 89

91 4.1.6 OBJETIVO DO ESTUDO DE CASO O objetivo dete cao de uo é a redução de defeito no artefato produzido no proceo de deenvolvimento de oftware baeado em reuo ob a ótica do deenvolvedore e cliente, e o ganho do atributo de qualidade como a reuabilidade, flexibilidade e compreenibilidade. 4.2 MONITORAÇÃO DO ESTUDO DE CASO ETAPA: GARANTINDO A QUALIDADE Para realização do proceo de Garantia da Qualidade de Software, algun modelo foram etabelecido ante da execução da atividade do proceo de Controle de Qualidade, a aber: Plano de Garantia da Qualidade de Software do Projeto (PGQSP), Cronograma para verificaçõe / reviõe de GQS do projeto, Hitórico de Verõe e Quetionário de Sugetõe para Melhoria da Garantia da Qualidade (QSMGQ). O modelo foram realizado da eguinte forma: Técnica Utilizada Conulta a conultore de qualidade de organizaçõe que já têm introdução da prática de qualidade no proceo de deenvolvimento de projeto e pequia na literatura obre modelo de qualidade. Tempo Dependido Dua emana. Fatore de Influência Houve um ponto favorável: facilidade de aceo a conultore de qualidade de dua grande organizaçõe como SERPRO-RJ e SIEMENS-RJ. Avaliação do Reultado e do Tempo Foram realizada no total de trê entrevita com o conultore de qualidade e alguma conulta por telefone. A entrevita duraram em média 2 hora cada. Na entrevita, foram levantado vário tipo de artefato de qualidade apontado pela Norma ISO9000:2000 (ABNT9000, 2001), ma nenhum do conultore relatou obre algum procedimento de avaliação do produto de qualidade. Neta etapa da Monitoração ó foram definido o modelo que na etapa eguinte foram devidamente preenchido. Para o Plano de Garantia de Qualidade de Software do Projeto (PGQSP) foi utilizado um modelo que etá apreentado na FIG

92 PGQSP - Plano de Garantia da Qualidade de Software do Projeto Objetivo: Reponável: Definir a etrutura de GQS adotada para o projeto, a forma de atuação da verificaçõe / reviõe, o cronograma da verificaçõe / reviõe para a atividade elecionada e etimativa de eforço empregada pelo conultor de GQS e equipe de deenvolvimento no proceo de Verificação / Revião. Template: Ferramenta: Exemplo: Lita de Verificação / Revião: Técnica utilizada: Orientaçõe Técnica: Opcionalidade: Entrada para Atividade: Saída da Atividade: FIG : Plano de GQS do Projeto (PGQSP). Na FIG é apreentado um modelo de Hitórico de Verõe para er introduzido em todo artefato produzido com a data da verão, número eqüencial da verão, decrição ucinta da verão, autor reponável pela verão, o nome do revior e por quem foi aprovado. Data Verão Decrição Autor Revior Aprovado por <dd/mm/aaaa> <x.x> <detalhe> <nome> <nome> <nome> FIG : Hitórico de verõe. O cronograma para a verificaçõe / reviõe de GQS do artefato do projeto piloto deve er inerido no cronograma do projeto piloto, obedecendo ao iten apreentado na FIG Nº Verificação /Revião Atividade Tarefa Data de Início Data de Término Eforço (homen/hora) GQS Equipe de Projeto <Número eqüencial de verificaçõe /reviõe do projeto> <Atividade em que e dá a verificação /revião de GQS> <Tarefa da Atividade a er verificada /reviada> <Data de início da verificação /revião> <Data de término da verificação /revião> <quantidade em homenhora gato pelo conultor de GQS> <quantidade em homen-hora gato pelo deenvolvedore> FIG : Cronograma para a verificaçõe e reviõe de GQS do projeto. 91

93 De acordo com a Norma ISO 9000:2000 (ABNT9000, 2001), foi etabelecido o QSMGQ para prover a melhoria do proceo de qualidade de forma que o Comitê de Qualidade poa obter um feedback do grupo de qualidade. O Quetionário de Sugetõe para Melhoria da Garantia da Qualidade é apreentado na FIG Quetionário de Sugetõe para Melhoria da Garantia da Qualidade Quetõe Repota e Sugetõe 1 - A verificação / revião atingiu o objetivo do grupo da qualidade? Se não, por quê? 2 O grupo da qualidade ente que contribuiu para melhorar a qualidade do artefato ou aet pela verificação / revião? 3 - Todo tiveram tempo uficiente para fazer preparação? Se não, quanto tempo precia? 4 - Há neceidade de conhecimento epecífico para utilizar o checklit / técnica de leitura para ete tipo de artefato / aet durante a preparação? 5 - Foi útil para detectar não-conformidade? 6 - O checklit / técnica de leitura pode er melhorado? Cao afirmativo, como? 7 - No ubproceo de Revião, todo o participante etavam preente? Se não, quem etava auente? Indicar e jutificar e não havia neceidade. 8 - O procedimento para a verificaçõe / reviõe foram eguido corretamente? 9 - No ubproceo de Revião, como a reuniõe poderiam melhorar? 10 - Há neceidade de ajuda para realizar efetivamente checklit / técnica de leitura? 11 - Há alguma outra ugetão para melhorar o Proceo de Garantia da Qualidade? Data: / / Nome: Rubrica: FIG : Quetionário de Sugetõe para Melhoria da Garantia da Qualidade ETAPA: SUBPROCESSO DE VERIFICAÇÃO PLANEJAMENTO DA VERIFICAÇÃO O Planejamento do proceo de Verificação foi realizado da eguinte forma: 92

94 Técnica Utilizada - O modelo definido na eção e o procedimento propoto em SPV-A1 da eção , que inclui a definição do checklit baeado em apecto para o artefato Neceidade do Cliente e Gloário, Arquitetura de Domínio, Código-fonte e Cao de Tete de Qualificação e o relatório correpondente. Tempo Dependido - Quatro emana. Fatore de Influência - Foi utilizado uma planilha de texto (Microoft Excel) que atendeu inteiramente ao propóito da lita de conferência (checklit). Avaliação do Reultado e do Tempo - Apear da facilidade da utilização de uma planilha de texto, a elaboração da lita de conferência demandou um tempo acima do etimado (uma emana a mai). Como a lita de conferência eguiram a propota apreentada no Capítulo 3, então foram preenchido para cada artefato a er verificado o modelo PGQSP, Cronograma e Hitórico de Verõe. Além dio, foram elaborado o checklit (veja na eção do APÊNDICE 4) e o modelo de relatório correpondente de acordo com o artefato a er verificado. A eguir na FIG ão apreentado o modelo upracitado em (a) (b) (c), em (d) a lita de conferência e em (e) o Relatório de Verificação para Neceidade do Cliente e Gloário. PGQSP - Plano de Garantia da Qualidade de Software do Projeto Objetivo: Reponável: Template: Ferramenta: Exemplo: Lita de Verificação: Técnica utilizada: Orientaçõe Técnica: Opcionalidade: Definir a etrutura de GQS adotada para o projeto piloto, Controlador Tático. Conultor de GQS (CGQS). VENC001/03..\ESTUDO-Cao\CT_Qualidade\ARTEFATOS- KLEYNA\Modelo_Checklit_v1.5..xl Microoft Excel..\ESTUDO-Cao\CT_Qualidade\ARTEFATOS- KLEYNA\EXEMPLOS\5_Checklit_Neceidade_Cliente_v1.5..xl VENC001/03, VEAR001/03, VEPT001/03, VETU001/03, VETI001/03, VETG001/03, VETV001/03, VECJ001/03 Checklit baeado em apecto. Na própria lita de conferência. Obrigatória. Entrada para Atividade: Verificação Saída da Atividade: Planejamento FIG : (a) PGQSP do projeto Controlador Tático. 93

95 Código da Verificação VENC001/03 Atividade Preparação do Pedido da Propota Tarefa Elaboração da Neceidade do Cliente Cronograma Data de Início Eforço (homen/hora) Data de Término GQS Verificador 09/12/ /12/ h 1 h FIG : (b) Cronograma de verificação do artefato Neceidade do Cliente e Gloário. FIG : (c) Hitórico de Verõe do checklit para Neceidade do Cliente e Gloário. FIG : (d) Parte do checklit do artefato Neceidade do Cliente e Gloário. 94

96 FIG : (e) Relatório de Verificação para Neceidade do Cliente e Gloário VERIFICAÇÃO A Verificação foi realizada da eguinte forma: Técnica Utilizada A lita de conferência (checklit) elaborada no Planejamento da Verificação baeada em apecto para o artefato Neceidade do Cliente e Gloário, Arquitetura de Domínio, Código-fonte e Cao de Tete de Qualificação e o relatório correpondente conforme decrito na eção Tempo Dependido Em média uma hora para cada artefato no decorrer de dua emana. Fatore de Influência A execução da aplicação do checklit foi facilitada pela diponibilidade de um grupo acadêmico de pó-graduação em Ciência da Computação. 95

97 Avaliação do Reultado e do Tempo - Apear da falta de conhecimento por parte do verificadore do domínio do projeto piloto, Controlador Tático, ete não tiveram dificuldade na realização da verificação e exprearam certo conforto quanto à utilização do checklit. Também, foi verificado o grau de conhecimento de cada verificador, por exemplo, conhecimento em OO e deign pattern, para atribuir o artefato apropriado ao conhecimento do verificador. Na FIG (a) é apreentada parte da aplicação do checklit baeado em apecto, em (b) a anotaçõe da não-conformidade detectada para Neceidade do Cliente e Gloário, e em (c) o repectivo Relatório da Verificação. FIG : (a) Iten do Checklit de Neceidade do Cliente e Gloário. 96